Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

2014-11-20 Thread Javier Martinez Canillas
Hello Vivek,

On 11/20/2014 08:51 AM, Vivek Gautam wrote:

 I tested linux-next on Exynos5800 peach-pi board with linux-next and and the 
 two
 patches $Subject and [0].

 Below is my git hash:
 4d9e6ee drm/exynos: Move platform drivers registration to module init
 4545ed4 POSTED: arm: dts: Exynos5: Use pmu_system_controller phandle for dp 
 phy
 36391a5 Add linux-next specific files for 20141119
 9b1ced1 Merge branch 'akpm/master'
 282497e mm: add strictlimit knob
 
 used exynos_defconfig


Same here.


 With this display works for me.
 Without $Subject patch i get lookup in drm.


I tested with today linux-next (next-20141120) and display is indeed
working for me. So it seems that whatever caused the error in the
phy-exynos-mipi-video driver reported by Paolo, got fixed recently.

My working git hash is:

65a8d01 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
a9b43cb drm/exynos: Move platform drivers registration to module init
5b83d7a Add linux-next specific files for 20141120
1172916 mm: add strictlimit knob

I did have to disable CONFIG_SND_SOC_SNOW though, otherwise the kernel
did not boot due the issue reported previously by Kevin.

 Javier can you tell me your git hash. Was it on yesterday's linux-next ?
 

In fact, my branch where I could reproduce the phy-exynos-mipi-video issue
was not based on yesterday's next but next-20141117. The git hash is:

9fb5d7c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
f740096 drm/exynos: Move platform drivers registration to module init
efefb5c Add linux-next specific files for 20141117
8c944d7 mm: add strictlimit knob

 With 3.18-rc5 i could see display on Exynos5800 peach-pi with
 following git hash:
 
 b6dca11 drm/exynos: dp: Remove support for unused dptx-phy
 7cc5c2d ARM: exynos_defconfig: Enable options for display panel support
 d0aca5e arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
 fc14f9c Linux 3.18-rc5
 e35c5a2 Merge tag 'armsoc-for-rc5' of
 git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
 
 I don't need this drm lockup patch with 3.18-rc5 (with exynos_defconfig).
 

Yes, that works because the commit that caused the Exynos DRM lockup was:

43c0767 (of/platform: Move platform devices under /sys/devices/platform)

which landed in next-20141105.

Reverting 43c0767 and only applying [0] should have the same effect.

 I am checking further with linux-samsung, coz i could see weird
 behavior as mentioned
 in [1] with linux-samsun/for-next merged with above git hash.


Great, it should be good to know what caused:

exynos-mipi-video-phy 10040714.video-phy: can't request region for resource 
[mem 0x10040714-0x1004071f]

even when I could not reproduce it anymore with today's linux-next.

 [0]: https://lkml.org/lkml/2014/10/30/394
 [1]: http://www.spinics.net/lists/linux-samsung-soc/msg39032.html

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: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

2014-11-20 Thread Vivek Gautam
Hi Javier,


On Thu, Nov 20, 2014 at 2:15 PM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 Hello Vivek,

 On 11/20/2014 08:51 AM, Vivek Gautam wrote:

 I tested linux-next on Exynos5800 peach-pi board with linux-next and and 
 the two
 patches $Subject and [0].

 Below is my git hash:
 4d9e6ee drm/exynos: Move platform drivers registration to module init
 4545ed4 POSTED: arm: dts: Exynos5: Use pmu_system_controller phandle for dp 
 phy
 36391a5 Add linux-next specific files for 20141119
 9b1ced1 Merge branch 'akpm/master'
 282497e mm: add strictlimit knob

 used exynos_defconfig


 Same here.


 With this display works for me.
 Without $Subject patch i get lookup in drm.


 I tested with today linux-next (next-20141120) and display is indeed
 working for me. So it seems that whatever caused the error in the
 phy-exynos-mipi-video driver reported by Paolo, got fixed recently.

 My working git hash is:

 65a8d01 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
 a9b43cb drm/exynos: Move platform drivers registration to module init
 5b83d7a Add linux-next specific files for 20141120
 1172916 mm: add strictlimit knob

 I did have to disable CONFIG_SND_SOC_SNOW though, otherwise the kernel
 did not boot due the issue reported previously by Kevin.

 Javier can you tell me your git hash. Was it on yesterday's linux-next ?


 In fact, my branch where I could reproduce the phy-exynos-mipi-video issue
 was not based on yesterday's next but next-20141117. The git hash is:

 9fb5d7c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
 f740096 drm/exynos: Move platform drivers registration to module init
 efefb5c Add linux-next specific files for 20141117
 8c944d7 mm: add strictlimit knob

 With 3.18-rc5 i could see display on Exynos5800 peach-pi with
 following git hash:

 b6dca11 drm/exynos: dp: Remove support for unused dptx-phy
 7cc5c2d ARM: exynos_defconfig: Enable options for display panel support
 d0aca5e arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
 fc14f9c Linux 3.18-rc5
 e35c5a2 Merge tag 'armsoc-for-rc5' of
 git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

 I don't need this drm lockup patch with 3.18-rc5 (with exynos_defconfig).


 Yes, that works because the commit that caused the Exynos DRM lockup was:

 43c0767 (of/platform: Move platform devices under /sys/devices/platform)

 which landed in next-20141105.

 Reverting 43c0767 and only applying [0] should have the same effect.

 I am checking further with linux-samsung, coz i could see weird
 behavior as mentioned
 in [1] with linux-samsun/for-next merged with above git hash.


 Great, it should be good to know what caused:

On linux-samsung tree the only patch that's missing apart from dptx-phy patches
is the syscon patch from Pankaj Dubey:
b784b98 mfd: syscon: Decouple syscon interface from platform devices

So with below git hash, linux-samsung/for-next display works fine along with
other devices that request PMU system controller :

7bd219e drm/exynos: dp: Remove support for unused dptx-phy
e8f21fd arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
7099bde Revert Revert ARM: exynos_defconfig: Enable options for
display panel support
713a994 mfd: syscon: Decouple syscon interface from platform devices
7552917 Revert ARM: exynos_defconfig: Enable options for display
panel support /* This is Kukjin's for-next today */
ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next
26c6283 Merge branch 'v3.18-samsung-fixes' into for-next
cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next
98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers
839275c ARM: exynos_defconfig: Use 16 minors per MMC block device
0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow
fc14f9c Linux 3.18-rc5



 exynos-mipi-video-phy 10040714.video-phy: can't request region for resource 
 [mem 0x10040714-0x1004071f]

The only reason i see this fails is since PMU is now requesting the
entire memory
region with base 0x1004. We should convert the mipi-phy pmu
register handling
too through syscon.


 even when I could not reproduce it anymore with today's linux-next.

 [0]: https://lkml.org/lkml/2014/10/30/394
 [1]: http://www.spinics.net/lists/linux-samsung-soc/msg39032.html



-- 
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
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] ASoC: samsung: In the i2s_set_sysclk() callback we are currently clearing all bits of the IISMOD register in i2s_set_sysclk. It's due to an incorrect mask used for the AND operation which is i

2014-11-20 Thread Padmavathi Venna
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Padmavathi Venna padm...@samsung.com
---
 sound/soc/samsung/i2s.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index 0df6547..e1ace52 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -494,7 +494,7 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai,
if (dir == SND_SOC_CLOCK_IN)
mod |= 1  i2s_regs-cdclkcon_off;
else
-   mod = 0  i2s_regs-cdclkcon_off;
+   mod = ~(1  i2s_regs-cdclkcon_off);
 
i2s-rfs = rfs;
break;
@@ -551,10 +551,11 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai,
}
 
if (clk_id == 0)
-   mod = 0  i2s_regs-rclksrc_off;
+   mod = ~(1  i2s_regs-rclksrc_off);
else
mod |= 1  i2s_regs-rclksrc_off;
 
+   break;
default:
dev_err(i2s-pdev-dev, We don't serve that!\n);
return -EINVAL;
-- 
1.7.4.4

--
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: [alsa-devel] [PATCH] ASoC: samsung: In the i2s_set_sysclk() callback we are currently clearing all bits of the IISMOD register in i2s_set_sysclk. It's due to an incorrect mask used for the AND ope

2014-11-20 Thread Padma Venkat
Hi,

On 11/20/14, Padmavathi Venna padm...@samsung.com wrote:
 Cc: Sylwester Nawrocki s.nawro...@samsung.com
 Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
 Signed-off-by: Padmavathi Venna padm...@samsung.com
 ---
  sound/soc/samsung/i2s.c |5 +++--
  1 files changed, 3 insertions(+), 2 deletions(-)

 diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
 index 0df6547..e1ace52 100644
 --- a/sound/soc/samsung/i2s.c
 +++ b/sound/soc/samsung/i2s.c
 @@ -494,7 +494,7 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai,
   if (dir == SND_SOC_CLOCK_IN)
   mod |= 1  i2s_regs-cdclkcon_off;
   else
 - mod = 0  i2s_regs-cdclkcon_off;
 + mod = ~(1  i2s_regs-cdclkcon_off);

   i2s-rfs = rfs;
   break;
 @@ -551,10 +551,11 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai,
   }

   if (clk_id == 0)
 - mod = 0  i2s_regs-rclksrc_off;
 + mod = ~(1  i2s_regs-rclksrc_off);
   else
   mod |= 1  i2s_regs-rclksrc_off;

 + break;
   default:
   dev_err(i2s-pdev-dev, We don't serve that!\n);
   return -EINVAL;
 --
 1.7.4.4


Please ignore this patch as subject line is not proper.

Thanks
Padma
 ___
 Alsa-devel mailing list
 alsa-de...@alsa-project.org
 http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

--
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] ASoC: samsung: ASoC: samsung: Fix IISMOD setting in i2s_set_sysclk()

2014-11-20 Thread Padmavathi Venna
In the i2s_set_sysclk() callback we are currently clearing all bits
of the IISMOD register in i2s_set_sysclk. It's due to an incorrect
mask used for the AND operation which is introduced in commit
a5a56871f804edac93a53b5e871c0e9818fb9033 (ASoC: samsung:
add support for exynos7 I2S controller) and also adds the missing
break statement.

Cc: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Padmavathi Venna padm...@samsung.com
---
 sound/soc/samsung/i2s.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
index 0df6547..e1ace52 100644
--- a/sound/soc/samsung/i2s.c
+++ b/sound/soc/samsung/i2s.c
@@ -494,7 +494,7 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai,
if (dir == SND_SOC_CLOCK_IN)
mod |= 1  i2s_regs-cdclkcon_off;
else
-   mod = 0  i2s_regs-cdclkcon_off;
+   mod = ~(1  i2s_regs-cdclkcon_off);
 
i2s-rfs = rfs;
break;
@@ -551,10 +551,11 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai,
}
 
if (clk_id == 0)
-   mod = 0  i2s_regs-rclksrc_off;
+   mod = ~(1  i2s_regs-rclksrc_off);
else
mod |= 1  i2s_regs-rclksrc_off;
 
+   break;
default:
dev_err(i2s-pdev-dev, We don't serve that!\n);
return -EINVAL;
-- 
1.7.4.4

--
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: [alsa-devel] [PATCH] ASoC: samsung: Fix IISMOD setting in i2s_set_sysclk()

2014-11-20 Thread Sylwester Nawrocki
Hi,

On 20/11/14 08:04, Padma Venkat wrote:
 diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
  index 947352d..8db8c66 100644
  --- a/sound/soc/samsung/i2s.c
  +++ b/sound/soc/samsung/i2s.c
  @@ -494,7 +494,7 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai,
 if (dir == SND_SOC_CLOCK_IN)
 mod |= 1  i2s_regs-cdclkcon_off;
 else
  -  mod = 0  i2s_regs-cdclkcon_off;
  +  mod = ~(1  i2s_regs-cdclkcon_off);

 Thanks for pointing this. In my local machine it was properly done but
 while rebasing on linux-next I did some mistake. There is one more
 place in set_sysclk which need to be corrected here
 mod = 0  i2s_regs-rclksrc_off
 can you include this change also in your patch or should I post a new
 patch for all?

OK, I'll also correct this and resend the patch.

-- 
Regards,
Sylwester
--
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 2/5] drivers: soc: Add support for Exynos PMU driver

2014-11-20 Thread Russell King - ARM Linux
On Thu, Nov 20, 2014 at 11:09:25AM +0530, Amit Daniel Kachhap wrote:
 diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
 index 063113d..44d220d 100644
 --- a/drivers/soc/Makefile
 +++ b/drivers/soc/Makefile
 @@ -6,3 +6,4 @@ obj-$(CONFIG_ARCH_QCOM)   += qcom/
  obj-$(CONFIG_ARCH_TEGRA) += tegra/
  obj-$(CONFIG_SOC_TI) += ti/
  obj-$(CONFIG_PLAT_VERSATILE) += versatile/
 +obj-$(CONFIG_ARCH_EXYNOS)+= samsung/

Is ARCH_EXYNOS appropriate here, or is your new SOC_SAMSUNG better?

 diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
 new file mode 100644
 index 000..a424ebc
 --- /dev/null
 +++ b/drivers/soc/samsung/Kconfig
 @@ -0,0 +1,20 @@
 +#
 +# SAMSUNG SOC drivers
 +#
 +menuconfig SOC_SAMSUNG
 + bool Samsung SOC drivers support

If you intend to select SOC_SAMSUNG, is there any point in making this
a user-visible symbol?

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
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] PM / Domains: Power on the PM domain right after attach completes

2014-11-20 Thread Ulf Hansson
On 20 November 2014 01:35, Rafael J. Wysocki r...@rjwysocki.net wrote:
 On Wednesday, November 19, 2014 09:54:00 AM Ulf Hansson wrote:
 [...]

 
  Scenario 5), a platform driver with/without runtime PM callbacks.
  -probe()
  - do some initialization
  - may fetch handles to runtime PM resources
  - pm_runtime_enable()
 
  Well, and now how the driver knows if the device is on before accessing 
  it?

 In this case the driver don't need to access the device during
 -probe(). That's postponed until sometime later.

 If this is a platform driver, it rather does need to access the device,
 precisely because it doesn't know what power state the device is in otherwise.
 See below.

  Note 1)
  Scenario 1) and 2), both relies on the approach to power on the PM
  domain by using pm_runtime_get_sync(). That approach didn't work when
  CONFIG_PM_RUNTIME was unset, but we recently decided to fixed that by
  the below patch, so that's good!
  [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd 
  enabled
 
  Note 2)
  Scenario 3) and 4) use the same principles for managing runtime PM.
  These scenarios needs a way to power on the generic PM domain prior
  probing the device. The call to pm_runtime_set_active(), prevents an
  already powered PM domain from power off until after probe, but that's
  not enough.
 
  Note 3)
  The $subject patch, tried to address the issues for scenario 3) and
  4). It does so, but will affect scenario 5) which was working nicely
  before. In scenario 5), the $subject patch will cause the generic PM
  domain to potentially stay powered after -probe() even if the device
  is runtime PM suspended.
 
  Why would it?  If the device is runtime-suspended, the domain will know
  that, because its callbacks will be used for that.  At least, that's
  what I'd expect to happen, so is there a problem here?

 Genpd do knows about the device but it doesn’t get a notification to
 power off. There are no issues whatsoever for driver.

 Except that the driver is arguably buggy.

 This is a somewhat special case. Let's go through an example.

 1. The PM domain is initially in powered off state.
 2. The bus -probe() invokes dev_pm_domain_attach() and then the PM
 domain gets attached to the device.
 3. $subject patch causes the PM domain to power on.
 4. A driver -probe() sequence start, following the Scenario 5).
 5. The device is initially in runtime PM suspended state and it will
 remain so during -probe().

 But is it physically suspended?

 The runtime PM status of the device after -probe is required to reflect its
 real state if runtime PM is enabled.  If that's not the case, it is a bug.

Agree.

While I was searching for drivers that behave as in scenario 5), they
tend to register some subsystem specific callbacks and don't access
the device until some of those callbacks are invoked.

At least that was my interpretation of their -probe() methods, but
it's not always easy to tell how those callbacks are being used for
each subsystem.


 Now, for platform drivers, the driver can't really assume anything in
 particular about the current power state of the device at -probe time,
 because different platforms including devices handled by that driver may
 behave differently.

 A good example would be two platforms A and B where the same device X is in a
 power domain such that A boots with the domain (physically) on, while B 
 boots
 with the domain off.  If the driver for X assumes anything about the initial
 power state of the device, it may not work on either A or B.

I get your point and agree!


 6. The pm_request_idle() invoked after really_probe() in driver core,
 won't trigger a runtime PM suspend callback to be invoked. In other
 words, genpd don't get a notification that it may power off.

 In this state, genpd will either power off from the late_initcall,
 genpd_poweroff_unused() (depending on when the driver was probed) or
 wait until some device's runtime PM suspend callback is invoked at any
 later point.

 Which sounds OK to me, so why is it a problem?

The late_initcall doesn't work for modules.

Also, suppose the PM domain only holds this inactive device that was
probed as in scenario 5). Then, you could end up having the PM domain
powered, even if it isn't needed.

Anyway, I can live with this. It's likely the driver that behave as in
scenario 5) that should be fixed as you stated.


  I see three options going forward.
 
  Option 1)
  Convert scenario 3) and 4) into using the pm_runtime_get_sync()
  approach. There are no theoretical obstacles to do this, but pure
  practical. There are a lot of drivers that needs to be converted and
  we also need to teach driver authors future wise to not use
  pm_runtime_set_active() in this manner.
 
  I'd say we need to do something like this anyway.  That is, standardize on
  *one* approach.  I'm actually not sure what approach is the most useful,
  but the pm_runtime_get_sync() one seems to be the most popular to me.
 
  Option 2)

Re: [alsa-devel] [PATCH] ASoC: samsung: Fix IISMOD setting in i2s_set_sysclk()

2014-11-20 Thread Padma Venkat
Hi Sylwester,

On 11/20/14, Sylwester Nawrocki s.nawro...@samsung.com wrote:
 Hi,

 On 20/11/14 08:04, Padma Venkat wrote:
 diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
  index 947352d..8db8c66 100644
  --- a/sound/soc/samsung/i2s.c
  +++ b/sound/soc/samsung/i2s.c
  @@ -494,7 +494,7 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai,
if (dir == SND_SOC_CLOCK_IN)
mod |= 1  i2s_regs-cdclkcon_off;
else
  - mod = 0  i2s_regs-cdclkcon_off;
  + mod = ~(1  i2s_regs-cdclkcon_off);

 Thanks for pointing this. In my local machine it was properly done but
 while rebasing on linux-next I did some mistake. There is one more
 place in set_sysclk which need to be corrected here
 mod = 0  i2s_regs-rclksrc_off
 can you include this change also in your patch or should I post a new
 patch for all?

 OK, I'll also correct this and resend the patch.

As I found one more break statement missing. So posted a new patch
with all corrected code with your signed-off. Please do review of the
same.

Thanks for you support.
Padma


 --
 Regards,
 Sylwester

--
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 0/3] PM / Domains: Add initial PM clock support to genpd

2014-11-20 Thread Ulf Hansson
On 20 November 2014 01:33, Kevin Hilman khil...@kernel.org wrote:
 Ulf Hansson ulf.hans...@linaro.org writes:

 It's quite common for PM domains to use PM clocks. Typically from SOC 
 specific
 code, the per device PM clock list is created and pm_clk_suspend|resume() are
 invoked to handle clock gating/ungating.

 A step towards consolidation is to integrate PM clock support into genpd, 
 which
 is what this patchset does.

 In this initial step, the calls to the pm_clk_suspend|resume() are handled
 within genpd, but the per device PM clock list still needs to be created from
 SOC specific code. It seems reasonable to have gendp to handle that as well, 
 but
 that left to future patchsets to address.

 I think we need to get rid of the SoC specific code already.  For
 example, we're already seeing SoCs where the arm32 core is being
 replaced by an arm64 core but the other IPs, and power-domain logic is
 staying more or less the same.

 It's not every users of genpd that are keen on using PM clocks thus we need
 to provide this a configuration option for genpd.

 Or more likely, probably some compatible string, or property in the
 domain node.  Grygorii, Arnd and myself were discussing this elsewhere
 in the context of the TI Keystone2 PM domain support[1].

Thanks for pointing that out. It was actually the reason to why I
posted this patchset now, I have been keeping the patches locally in
my tree for too long. :-)

Let me comment of that thread, instead of here.

Kind regards
Uffe
--
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


[RFC PATCH v3 1/4] drm/exynos: make kms drivers to be independent drivers

2014-11-20 Thread Inki Dae
This patch makes kms drivers to be independent drivers.
For this, it removes all register codes to kms drivers
from exynos_drm_drv module and adds module_init/exit
for each kms driver so that each kms driver can be
called independently.

Changelog v3:
- Use module_platform_driver macro instead module_init/exit.
- Configure all kms drivers to be built in kernel image.

Changelog v2:
- none

Signed-off-by: Inki Dae inki@samsung.com
---
 drivers/gpu/drm/exynos/exynos_dp_core.c  |2 ++
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |   43 +++---
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |5 
 drivers/gpu/drm/exynos/exynos_drm_dsi.c  |2 ++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 ++
 drivers/gpu/drm/exynos/exynos_hdmi.c |2 ++
 drivers/gpu/drm/exynos/exynos_mixer.c|2 ++
 7 files changed, 13 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index ed818b9..30ebf5d 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1408,6 +1408,8 @@ struct platform_driver dp_driver = {
},
 };
 
+module_platform_driver(dp_driver);
+
 MODULE_AUTHOR(Jingoo Han jg1@samsung.com);
 MODULE_DESCRIPTION(Samsung SoC DP Driver);
 MODULE_LICENSE(GPL v2);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index eab12f0..02d4772 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -484,12 +484,6 @@ static struct component_match *exynos_drm_match_add(struct 
device *dev)
 
mutex_lock(drm_component_lock);
 
-   /* Do not retry to probe if there is no any kms driver regitered. */
-   if (list_empty(drm_component_list)) {
-   mutex_unlock(drm_component_lock);
-   return ERR_PTR(-ENODEV);
-   }
-
list_for_each_entry(cdev, drm_component_list, list) {
/*
 * Add components to master only in case that crtc and
@@ -545,22 +539,6 @@ static const struct component_master_ops exynos_drm_ops = {
.unbind = exynos_drm_unbind,
 };
 
-static struct platform_driver *const exynos_drm_kms_drivers[] = {
-#ifdef CONFIG_DRM_EXYNOS_FIMD
-   fimd_driver,
-#endif
-#ifdef CONFIG_DRM_EXYNOS_DP
-   dp_driver,
-#endif
-#ifdef CONFIG_DRM_EXYNOS_DSI
-   dsi_driver,
-#endif
-#ifdef CONFIG_DRM_EXYNOS_HDMI
-   mixer_driver,
-   hdmi_driver,
-#endif
-};
-
 static struct platform_driver *const exynos_drm_non_kms_drivers[] = {
 #ifdef CONFIG_DRM_EXYNOS_G2D
g2d_driver,
@@ -587,22 +565,14 @@ static int exynos_drm_platform_probe(struct 
platform_device *pdev)
pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
 
-   for (i = 0; i  ARRAY_SIZE(exynos_drm_kms_drivers); ++i) {
-   ret = platform_driver_register(exynos_drm_kms_drivers[i]);
-   if (ret  0)
-   goto err_unregister_kms_drivers;
-   }
-
match = exynos_drm_match_add(pdev-dev);
-   if (IS_ERR(match)) {
-   ret = PTR_ERR(match);
-   goto err_unregister_kms_drivers;
-   }
+   if (IS_ERR(match))
+   return PTR_ERR(match);
 
ret = component_master_add_with_match(pdev-dev, exynos_drm_ops,
match);
if (ret  0)
-   goto err_unregister_kms_drivers;
+   return ret;
 
for (j = 0; j  ARRAY_SIZE(exynos_drm_non_kms_drivers); ++j) {
ret = platform_driver_register(exynos_drm_non_kms_drivers[j]);
@@ -632,10 +602,6 @@ err_unregister_non_kms_drivers:
 err_del_component_master:
component_master_del(pdev-dev, exynos_drm_ops);
 
-err_unregister_kms_drivers:
-   while (--i = 0)
-   platform_driver_unregister(exynos_drm_kms_drivers[i]);
-
return ret;
 }
 
@@ -654,9 +620,6 @@ static int exynos_drm_platform_remove(struct 
platform_device *pdev)
 
component_master_del(pdev-dev, exynos_drm_ops);
 
-   for (i = ARRAY_SIZE(exynos_drm_kms_drivers) - 1; i = 0; --i)
-   platform_driver_unregister(exynos_drm_kms_drivers[i]);
-
return 0;
 }
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 262a459..352a9f9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -331,11 +331,6 @@ int exynos_drm_component_add(struct device *dev,
 void exynos_drm_component_del(struct device *dev,
enum exynos_drm_device_type dev_type);
 
-extern struct platform_driver fimd_driver;
-extern struct platform_driver dp_driver;
-extern struct platform_driver dsi_driver;
-extern struct platform_driver mixer_driver;
-extern struct platform_driver hdmi_driver;
 extern struct platform_driver 

[RFC PATCH v3 2/4] drm/exynos: make non kms drivers to be indenpendent drivers

2014-11-20 Thread Inki Dae
This patch makes non kms drivers to be independent drivers.
For this, it removes all register codes to non kms drivers
from exynos_drm_drv module and adds module_init/exit
for each non kms driver so that each non kms driver can be
called independently.

In addition, this patch adds non kms register/unregister functions
to exynos_drm_core module and also modifies existing codes relevant
to sub driver.

The idea is that non kms driver is registered by entry point,
module_init, of each non kms driver and sets its own sub driver
to registered non kms driver object when the sub driver is probed.
For this, this patch adds a new structure, exynos_drm_non_kms_dev,
to exynos_drm_core module.

Changelog v3:
- fix the use of mutex lock.
- fix g2d device node check.
- use module_platform_driver macro instead of module_init/exit.

Changelog v2:
- check if available g2d device node.
- return 0 instead of -EPROBE_DEFER in case of no non kms device
  registered. This case is not error.

Signed-off-by: Inki Dae inki@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_core.c|  164 +++
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   50 +---
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   28 ++---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|1 +
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |   48 
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |1 +
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |   39 ++-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |2 +
 8 files changed, 243 insertions(+), 90 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c 
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 4c9f972..6c38308 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -19,6 +19,13 @@
 #include exynos_drm_fbdev.h
 
 static LIST_HEAD(exynos_drm_subdrv_list);
+DEFINE_MUTEX(list_lock);
+
+struct exynos_drm_non_kms_dev {
+   struct list_head list;
+   struct exynos_drm_subdrv *subdrv;
+   unsigned int device_type;
+};
 
 int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_display *display)
@@ -55,12 +62,66 @@ err_destroy_encoder:
return ret;
 }
 
+int exynos_drm_non_kms_register(unsigned int device_type)
+{
+   struct exynos_drm_non_kms_dev *dev;
+
+   dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+   if (!dev)
+   return -ENOMEM;
+
+   dev-device_type = device_type;
+
+   mutex_lock(list_lock);
+   list_add_tail(dev-list, exynos_drm_subdrv_list);
+   mutex_unlock(list_lock);
+
+   return 0;
+}
+
+void exynos_drm_non_kms_unregister(unsigned int device_type)
+{
+   struct exynos_drm_non_kms_dev *dev, *next;
+
+   mutex_lock(list_lock);
+   list_for_each_entry_safe(dev, next, exynos_drm_subdrv_list, list) {
+   mutex_unlock(list_lock);
+   if (dev-device_type == device_type) {
+   list_del_init(dev-list);
+   kfree(dev);
+   mutex_lock(list_lock);
+   break;
+   }
+   mutex_lock(list_lock);
+   }
+   mutex_unlock(list_lock);
+}
+
 int exynos_drm_subdrv_register(struct exynos_drm_subdrv *subdrv)
 {
+   struct exynos_drm_non_kms_dev *dev;
+
if (!subdrv)
return -EINVAL;
 
-   list_add_tail(subdrv-list, exynos_drm_subdrv_list);
+   mutex_lock(list_lock);
+   if (list_empty(exynos_drm_subdrv_list)) {
+   mutex_unlock(list_lock);
+   return -ENODEV;
+   }
+   mutex_unlock(list_lock);
+
+   mutex_lock(list_lock);
+   list_for_each_entry(dev, exynos_drm_subdrv_list, list) {
+   mutex_unlock(list_lock);
+   if (dev-device_type == subdrv-device_type) {
+   dev-subdrv = subdrv;
+   mutex_lock(list_lock);
+   break;
+   }
+   mutex_lock(list_lock);
+   }
+   mutex_unlock(list_lock);
 
return 0;
 }
@@ -68,94 +129,149 @@ EXPORT_SYMBOL_GPL(exynos_drm_subdrv_register);
 
 int exynos_drm_subdrv_unregister(struct exynos_drm_subdrv *subdrv)
 {
+   struct exynos_drm_non_kms_dev *dev;
+
if (!subdrv)
return -EINVAL;
 
-   list_del(subdrv-list);
+   mutex_lock(list_lock);
+   list_for_each_entry(dev, exynos_drm_subdrv_list, list) {
+   mutex_unlock(list_lock);
+   if (dev-device_type == subdrv-device_type) {
+   dev-subdrv = NULL;
+   break;
+   }
+   mutex_lock(list_lock);
+   }
+   mutex_unlock(list_lock);
 
return 0;
 }
 EXPORT_SYMBOL_GPL(exynos_drm_subdrv_unregister);
 
-int exynos_drm_device_subdrv_probe(struct drm_device *dev)
+int exynos_drm_device_subdrv_probe(struct drm_device *drm_dev)
 {
-   struct exynos_drm_subdrv 

[RFC PATCH v3 0/4] separeate sub drivers into independent drivers

2014-11-20 Thread Inki Dae
Hi all,

   This patch set separeates sub drivers into independent drivers.

   patch 1/4:
   - make all kms drivers - fimd, hdmi, dp and dsi - to be independent
 drivers.

   patch 2/4:
   - make all non kms drivers - g2d and ipp - to be independent drivers.

   patch 3/4:
   - make vidi driver to be independent driver.

   patch 4/4:
   - just clean up codes for checking if it's Exynos SoC.

   This patch series had been posted like below with different subject,
   v1: http://www.spinics.net/lists/linux-samsung-soc/msg39116.html
   v2: http://www.spinics.net/lists/linux-samsung-soc/msg39145.html,
   and only one modified patch was posted.

   DRM driver should be single driver so it's not reasonable for sub
   drivers to be built as independent modules. So I changed previous
   subjects to new ones by reverting existing Kconfig.
   With this change, all sub drivers will be built-in kernel image.

   Thanks,
   Inki Dae

Inki Dae (4):
  drm/exynos: make kms drivers to be independent drivers
  drm/exynos: make non kms drivers to be indenpendent drivers
  drm/exynos: make vidi driver to be independent driver
  drm/exynos: clean up machine compatible string check

 drivers/gpu/drm/exynos/exynos_dp_core.c |2 +
 drivers/gpu/drm/exynos/exynos_drm_core.c|  164 +++
 drivers/gpu/drm/exynos/exynos_drm_drv.c |  125 
 drivers/gpu/drm/exynos/exynos_drm_drv.h |   42 ++-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |2 +
 drivers/gpu/drm/exynos/exynos_drm_fimc.c|1 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|2 +
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |   48 
 drivers/gpu/drm/exynos/exynos_drm_gsc.c |1 +
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |   39 ++-
 drivers/gpu/drm/exynos/exynos_drm_rotator.c |2 +
 drivers/gpu/drm/exynos/exynos_drm_vidi.c|   81 -
 drivers/gpu/drm/exynos/exynos_hdmi.c|2 +
 drivers/gpu/drm/exynos/exynos_mixer.c   |2 +
 14 files changed, 326 insertions(+), 187 deletions(-)

-- 
1.7.9.5

--
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


[RFC PATCH v3 3/4] drm/exynos: make vidi driver to be independent driver

2014-11-20 Thread Inki Dae
This patch makes vidi driver to be independent driver.
For this, it removes register codes to vidi driver
from exynos_drm_drv module and adds module_init/exit
for vidi driver so that this driver can be called
independently.

In addition, this patch adds component support to vidi driver
so that this driver can be bound independently.

Changelog v3:
- none

Changelog v2:
- none

Signed-off-by: Inki Dae inki@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c  |   12 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h  |9 
 drivers/gpu/drm/exynos/exynos_drm_vidi.c |   81 +++---
 3 files changed, 54 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 7f1186e..3ac39b6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -608,19 +608,12 @@ static int exynos_drm_init(void)
if (IS_ERR(exynos_drm_pdev))
return PTR_ERR(exynos_drm_pdev);
 
-   ret = exynos_drm_probe_vidi();
-   if (ret  0)
-   goto err_unregister_pd;
-
ret = platform_driver_register(exynos_drm_platform_driver);
if (ret)
-   goto err_remove_vidi;
+   goto err_unregister_pd;
 
return 0;
 
-err_remove_vidi:
-   exynos_drm_remove_vidi();
-
 err_unregister_pd:
platform_device_unregister(exynos_drm_pdev);
 
@@ -630,9 +623,6 @@ err_unregister_pd:
 static void exynos_drm_exit(void)
 {
platform_driver_unregister(exynos_drm_platform_driver);
-
-   exynos_drm_remove_vidi();
-
platform_device_unregister(exynos_drm_pdev);
 }
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 5b3305c..7c2ba06 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -310,14 +310,6 @@ exynos_dpi_probe(struct device *dev) { return NULL; }
 static inline int exynos_dpi_remove(struct device *dev) { return 0; }
 #endif
 
-#ifdef CONFIG_DRM_EXYNOS_VIDI
-int exynos_drm_probe_vidi(void);
-void exynos_drm_remove_vidi(void);
-#else
-static inline int exynos_drm_probe_vidi(void) { return 0; }
-static inline void exynos_drm_remove_vidi(void) {}
-#endif
-
 /* This function creates a encoder and a connector, and initializes them. */
 int exynos_drm_create_enc_conn(struct drm_device *dev,
struct exynos_drm_display *display);
@@ -333,5 +325,4 @@ extern int exynos_drm_non_kms_register(unsigned int 
device_type);
 extern void exynos_drm_non_kms_unregister(unsigned int device_type);
 
 extern struct platform_driver exynos_drm_common_hdmi_driver;
-extern struct platform_driver vidi_driver;
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 50faf91..e1153aa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -14,6 +14,7 @@
 
 #include linux/kernel.h
 #include linux/platform_device.h
+#include linux/component.h
 
 #include drm/exynos_drm.h
 
@@ -48,10 +49,10 @@ struct vidi_win_data {
 
 struct vidi_context {
struct drm_device   *drm_dev;
+   struct platform_device  *pdev;
struct drm_crtc *crtc;
struct drm_encoder  *encoder;
struct drm_connectorconnector;
-   struct exynos_drm_subdrvsubdrv;
struct vidi_win_datawin_data[WINDOWS_NR];
struct edid *raw_edid;
unsigned intclkdiv;
@@ -561,14 +562,13 @@ static struct exynos_drm_display vidi_display = {
.ops = vidi_display_ops,
 };
 
-static int vidi_subdrv_probe(struct drm_device *drm_dev, struct device *dev)
+static int vidi_bind(struct device *dev, struct device *master, void *data)
 {
-   struct exynos_drm_manager *mgr = get_vidi_mgr(dev);
-   struct vidi_context *ctx = mgr-ctx;
-   struct drm_crtc *crtc = ctx-crtc;
+   struct drm_crtc *crtc = vidi_manager.crtc;
+   struct drm_device *drm_dev = data;
int ret;
 
-   vidi_mgr_initialize(mgr, drm_dev);
+   vidi_mgr_initialize(vidi_manager, drm_dev);
 
ret = exynos_drm_crtc_create(vidi_manager);
if (ret) {
@@ -586,20 +586,42 @@ static int vidi_subdrv_probe(struct drm_device *drm_dev, 
struct device *dev)
return 0;
 }
 
+static void vidi_unbind(struct device *dev, struct device *master,
+   void *data)
+{
+}
+
+static const struct component_ops vidi_component_ops = {
+   .bind   = vidi_bind,
+   .unbind = vidi_unbind,
+};
+
 static int vidi_probe(struct platform_device *pdev)
 {
-   struct exynos_drm_subdrv *subdrv;
struct vidi_context *ctx;
int ret;
 
+   ret = exynos_drm_component_add(pdev-dev, EXYNOS_DEVICE_TYPE_CRTC,
+   vidi_manager.type);
+   if 

[RFC PATCH v3 4/4] drm/exynos: clean up machine compatible string check

2014-11-20 Thread Inki Dae
Use 'for' statemant instead of hard-coded 'if' statement.

Changelog v3:
- none

Changelog v2:
- none

Signed-off-by: Inki Dae inki@samsung.com
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |   20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 3ac39b6..4579186 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -587,9 +587,16 @@ static struct platform_driver exynos_drm_platform_driver = 
{
},
 };
 
+static const char * const strings[] = {
+   samsung,exynos3,
+   samsung,exynos4,
+   samsung,exynos5,
+};
+
 static int exynos_drm_init(void)
 {
-   int ret;
+   bool is_exynos = false;
+   int ret, i;
 
/*
 * Register device object only in case of Exynos SoC.
@@ -598,9 +605,14 @@ static int exynos_drm_init(void)
 * by Exynos drm driver when using multi-platform kernel.
 * So these codes will be replaced with more generic way later.
 */
-   if (!of_machine_is_compatible(samsung,exynos3) 
-   !of_machine_is_compatible(samsung,exynos4) 
-   !of_machine_is_compatible(samsung,exynos5))
+   for (i = 0; i  ARRAY_SIZE(strings); i++) {
+   if (of_machine_is_compatible(strings[i])) {
+   is_exynos = true;
+   break;
+   }
+   }
+
+   if (!is_exynos)
return -ENODEV;
 
exynos_drm_pdev = platform_device_register_simple(exynos-drm, -1,
-- 
1.7.9.5

--
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: [alsa-devel] [PATCH] ASoC: samsung: ASoC: samsung: Fix IISMOD setting in i2s_set_sysclk()

2014-11-20 Thread Sylwester Nawrocki
On 20/11/14 11:03, Padmavathi Venna wrote:
 In the i2s_set_sysclk() callback we are currently clearing all bits
 of the IISMOD register in i2s_set_sysclk. It's due to an incorrect
 mask used for the AND operation which is introduced in commit
 a5a56871f804edac93a53b5e871c0e9818fb9033 (ASoC: samsung:
 add support for exynos7 I2S controller) and also adds the missing

The patch looks good to me, I'd just write about the missing break
in a separate sentence, i.e. s/and also adds/. Also add/

 break statement.
 
 Cc: Sylwester Nawrocki s.nawro...@samsung.com
 Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
 Signed-off-by: Padmavathi Venna padm...@samsung.com
 ---
  sound/soc/samsung/i2s.c |5 +++--
  1 files changed, 3 insertions(+), 2 deletions(-)
 
 diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c
 index 0df6547..e1ace52 100644
 --- a/sound/soc/samsung/i2s.c
 +++ b/sound/soc/samsung/i2s.c
 @@ -494,7 +494,7 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai,
   if (dir == SND_SOC_CLOCK_IN)
   mod |= 1  i2s_regs-cdclkcon_off;
   else
 - mod = 0  i2s_regs-cdclkcon_off;
 + mod = ~(1  i2s_regs-cdclkcon_off);
  
   i2s-rfs = rfs;
   break;
 @@ -551,10 +551,11 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai,
   }
  
   if (clk_id == 0)
 - mod = 0  i2s_regs-rclksrc_off;
 + mod = ~(1  i2s_regs-rclksrc_off);
   else
   mod |= 1  i2s_regs-rclksrc_off;
  
 + break;
   default:
   dev_err(i2s-pdev-dev, We don't serve that!\n);
   return -EINVAL;

--
Regards,
Sylwester
--
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/1] [media] platform: Deletion of unnecessary checks before two function calls

2014-11-20 Thread SF Markus Elfring
From: Markus Elfring elfr...@users.sourceforge.net
Date: Thu, 20 Nov 2014 11:44:20 +0100

The functions i2c_put_adapter() and release_firmware() test whether their
argument is NULL and then return immediately. Thus the test around the call
is not needed.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring elfr...@users.sourceforge.net
---
 drivers/media/platform/exynos4-is/fimc-is.c   | 6 ++
 drivers/media/platform/s3c-camif/camif-core.c | 3 +--
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/exynos4-is/fimc-is.c 
b/drivers/media/platform/exynos4-is/fimc-is.c
index 5476dce..a1db27b 100644
--- a/drivers/media/platform/exynos4-is/fimc-is.c
+++ b/drivers/media/platform/exynos4-is/fimc-is.c
@@ -428,8 +428,7 @@ static void fimc_is_load_firmware(const struct firmware 
*fw, void *context)
 * needed around for copying to the IS working memory every
 * time before the Cortex-A5 is restarted.
 */
-   if (is-fw.f_w)
-   release_firmware(is-fw.f_w);
+   release_firmware(is-fw.f_w);
is-fw.f_w = fw;
 done:
mutex_unlock(is-lock);
@@ -937,8 +936,7 @@ static int fimc_is_remove(struct platform_device *pdev)
vb2_dma_contig_cleanup_ctx(is-alloc_ctx);
fimc_is_put_clocks(is);
fimc_is_debugfs_remove(is);
-   if (is-fw.f_w)
-   release_firmware(is-fw.f_w);
+   release_firmware(is-fw.f_w);
fimc_is_free_cpu_memory(is);
 
return 0;
diff --git a/drivers/media/platform/s3c-camif/camif-core.c 
b/drivers/media/platform/s3c-camif/camif-core.c
index b385747..3b09b5b 100644
--- a/drivers/media/platform/s3c-camif/camif-core.c
+++ b/drivers/media/platform/s3c-camif/camif-core.c
@@ -256,8 +256,7 @@ static void camif_unregister_sensor(struct camif_dev *camif)
v4l2_device_unregister_subdev(sd);
camif-sensor.sd = NULL;
i2c_unregister_device(client);
-   if (adapter)
-   i2c_put_adapter(adapter);
+   i2c_put_adapter(adapter);
 }
 
 static int camif_create_media_links(struct camif_dev *camif)
-- 
2.1.3

--
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 1/3] PM / Domains: Initial PM clock support for genpd

2014-11-20 Thread Ulf Hansson
On 19 November 2014 18:25, Dmitry Torokhov dmitry.torok...@gmail.com wrote:
 On Wed, Nov 19, 2014 at 03:00:36PM +0100, Ulf Hansson wrote:
 It's quite common for PM domains to use PM clocks. Typically from SOC
 specific code, the per device PM clock list is created and
 pm_clk_suspend|resume() are invoked to handle clock gating/ungating.

 A step towards consolidation is to integrate PM clock support into
 genpd, which is what this patch does.

 In this initial step, the calls to the pm_clk_suspend|resume() are
 handled within genpd, but the per device PM clock list still needs to
 be created from SOC specific code. It seems reasonable to have gendp to
 handle that as well, but that left to future patches to address.

 It's not every users of genpd that are keen on using PM clocks thus we
 need to provide this a configuration option for genpd. Therefore let's
 add flag field in the genpd struct to keep this information and define
 a new PM_DOMAIN_PM_CLK bit can then be set at initialization.

 Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
 ---
  drivers/base/power/domain.c | 7 +++
  include/linux/pm_domain.h   | 3 +++
  2 files changed, 10 insertions(+)

 diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
 index 3989eb6..42e328c 100644
 --- a/drivers/base/power/domain.c
 +++ b/drivers/base/power/domain.c
 @@ -12,6 +12,7 @@
  #include linux/pm_runtime.h
  #include linux/pm_domain.h
  #include linux/pm_qos.h
 +#include linux/pm_clock.h
  #include linux/slab.h
  #include linux/err.h
  #include linux/sched.h
 @@ -1948,6 +1949,12 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
   genpd-domain.ops.complete = pm_genpd_complete;
   genpd-dev_ops.save_state = pm_genpd_default_save_state;
   genpd-dev_ops.restore_state = pm_genpd_default_restore_state;
 +
 + if (genpd-flags  PM_DOMAIN_PM_CLK) {
 + genpd-dev_ops.stop = pm_clk_suspend;
 + genpd-dev_ops.start = pm_clk_suspend;

 The 2nd one is wrong.

Huh, thanks for spotting this.


 + }
 +
   mutex_lock(gpd_list_lock);
   list_add(genpd-gpd_list_node, gpd_list);
   mutex_unlock(gpd_list_lock);
 diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
 index 9d254e2..44c6931 100644
 --- a/include/linux/pm_domain.h
 +++ b/include/linux/pm_domain.h
 @@ -14,6 +14,7 @@
  #include linux/pm.h
  #include linux/err.h
  #include linux/of.h
 +#include linux/bitops.h
  #include linux/notifier.h
  #include linux/cpuidle.h

 @@ -76,6 +77,8 @@ struct generic_pm_domain {
 struct device *dev);
   void (*detach_dev)(struct generic_pm_domain *domain,
  struct device *dev);
 + unsigned int flags; /* Bit field of configs for genpd */
 +#define PM_DOMAIN_PM_CLK BIT(0)  /* PM domain use PM clk */

 s/use/uses ?

 Are you planning on adding a separate flag for collecting clocks from OF
 on attach/detach?

Yes, I am thinking on that approach. Do you have any suggestions around this?

Kind regards
Uffe
--
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 00/33] thermal: exynos: convert the driver to use per-SoC type operations

2014-11-20 Thread Lukasz Majewski
Hi Eduardo,

 Hi,
 
 This patch series replaces the hardware registers abstractions in
 the Exynos thermal driver by the usage of per-SoC type operations.
 Such solution provides simpler, easier to understand code and
 allows removal of ~250 LOCs (~11% of the whole source code) from
 the driver.  Some other driver improvements are now also possible
 thanks to these changes but are scheduled at later time (like
 consolidating code for clearing IRQs using INTCLEAR register).
 
 The patchset should not cause any functionality changes.  This
 means that unless there are some bugs in the patches itself there
 should be no behavior changes for the driver (this also includes
 lack of changes in the way hardware is accessed by the driver).
 
 All testing was done on (Exynos4412 SoC based) ODROID U3 board
 (some additional patches are needed to make the Exynos thermal
 driver work on this hardware).

For the whole patch series:

Repository:
kernel_linux-soc-thermal/next
SHA1: 4027494124fd88e5d51127eebba315de5d8d57c8

Test HW:

Trats2 - Exynos4412
Tested-by: Lukasz Majewski l.majew...@samsung.com

Trats - Exynos4210
Tested-by: Lukasz Majewski l.majew...@samsung.com

ARNDALE(SMDK) - Exynos5250
Tested-by: Lukasz Majewski l.majew...@samsung.com

ARNDALE OCTA - Exynos5420
Tested-by: Lukasz Majewski l.majew...@samsung.com


 
 Depends on:
 - 'next' branch of linux-soc-thermal.git kernel tree from Eduardo
 
 Changes since v1 (https://lkml.org/lkml/2014/9/18/305):
 - rebased on top of the current linux-soc-thermal kernel
 
 Best regards,
 --
 Bartlomiej Zolnierkiewicz
 Samsung RD Institute Poland
 Samsung Electronics
 
 
 Bartlomiej Zolnierkiewicz (33):
   thermal: exynos: remove needless triminfo_data abstraction
   thermal: exynos: remove needless tmu_status abstraction
   thermal: exynos: remove needless threshold_temp abstraction
   thermal: exynos: remove needless triminfo_ctrl abstraction
   thermal: exynos: remove needless test_mux_addr_shift abstraction
   thermal: exynos: remove needless therm_trip_[mode,mask]_shift
 abstractions
   thermal: exynos: remove needless therm_trip_en_shift abstraction
   thermal: exynos: remove needless emul_temp_shift abstraction
   thermal: exynos: remove needless emul_time_shift abstraction
   thermal: exynos: replace tmu_irqstatus check by Exynos5440 one
   thermal: exynos: replace tmu_pmin check by Exynos5440 one
   thermal: exynos: simplify HW_TRIP level setting
   thermal: exynos: replace threshold_falling check by Exynos SoC type
 one
   thermal: exynos: remove TMU_SUPPORT_READY_STATUS flag
   thermal: exynos: remove TMU_SUPPORT_TRIM_RELOAD flag
   thermal: exynos: add sanitize_temp_error() helper
   thermal: exynos: add get_th_reg() helper
   thermal: exynos: add -tmu_initialize method
   thermal: exynos: add get_con_reg() helper
   thermal: exynos: add -tmu_control method
   thermal: exynos: add -tmu_read method
   thermal: exynos: add get_emul_con_reg() helper
   thermal: exynos: add -tmu_set_emulation method
   thermal: exynos: add -tmu_clear_irqs method
   thermal: exynos: remove TMU_SUPPORT_FALLING_TRIP flag
   thermal: exynos: remove TMU_SUPPORT_EMUL_TIME flag
   thermal: exynos: remove TMU_SUPPORT_EMULATION flag
   thermal: exynos: remove TMU_SUPPORT_ADDRESS_MULTIPLE flag
   thermal: exynos: remove TMU_SUPPORT_MULTI_INST flag
   thermal: exynos: remove test_mux pdata field
   thermal: exynos: remove SoC type ifdefs
   thermal: exynos: remove __EXYNOS5420_TMU_DATA macro
   thermal: exynos: remove exynos_tmu_data.h include
 
  drivers/thermal/samsung/exynos_thermal_common.h |   1 -
  drivers/thermal/samsung/exynos_tmu.c| 692
 
 drivers/thermal/samsung/exynos_tmu.h| 123 +
 drivers/thermal/samsung/exynos_tmu_data.c   | 239 +---
 drivers/thermal/samsung/exynos_tmu_data.h   | 159 -- 5 files
 changed, 485 insertions(+), 729 deletions(-) delete mode 100644
 drivers/thermal/samsung/exynos_tmu_data.h
 



-- 
Best regards,

Lukasz Majewski

Samsung RD Institute Poland (SRPOL) | Linux Platform Group
--
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] PM / Domains: Power on the PM domain right after attach completes

2014-11-20 Thread Grygorii Strashko
On 11/19/2014 10:54 AM, Ulf Hansson wrote:
 [...]
 

 Scenario 5), a platform driver with/without runtime PM callbacks.
 -probe()
 - do some initialization
 - may fetch handles to runtime PM resources
 - pm_runtime_enable()

 Well, and now how the driver knows if the device is on before accessing it?
 
 In this case the driver don't need to access the device during
 -probe(). That's postponed until sometime later.
 

 Note 1)
 Scenario 1) and 2), both relies on the approach to power on the PM
 domain by using pm_runtime_get_sync(). That approach didn't work when
 CONFIG_PM_RUNTIME was unset, but we recently decided to fixed that by
 the below patch, so that's good!
 [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled

 Note 2)
 Scenario 3) and 4) use the same principles for managing runtime PM.
 These scenarios needs a way to power on the generic PM domain prior
 probing the device. The call to pm_runtime_set_active(), prevents an
 already powered PM domain from power off until after probe, but that's
 not enough.

 Note 3)
 The $subject patch, tried to address the issues for scenario 3) and
 4). It does so, but will affect scenario 5) which was working nicely
 before. In scenario 5), the $subject patch will cause the generic PM
 domain to potentially stay powered after -probe() even if the device
 is runtime PM suspended.

 Why would it?  If the device is runtime-suspended, the domain will know
 that, because its callbacks will be used for that.  At least, that's
 what I'd expect to happen, so is there a problem here?
 
 Genpd do knows about the device but it doesn’t get a notification to
 power off. There are no issues whatsoever for driver.
 
 This is a somewhat special case. Let's go through an example.
 
 1. The PM domain is initially in powered off state.
 2. The bus -probe() invokes dev_pm_domain_attach() and then the PM
 domain gets attached to the device.
 3. $subject patch causes the PM domain to power on.
 4. A driver -probe() sequence start, following the Scenario 5).
 5. The device is initially in runtime PM suspended state and it will
 remain so during -probe().
 6. The pm_request_idle() invoked after really_probe() in driver core,
 won't trigger a runtime PM suspend callback to be invoked. In other
 words, genpd don't get a notification that it may power off.
 
 In this state, genpd will either power off from the late_initcall,
 genpd_poweroff_unused() (depending on when the driver was probed) or
 wait until some device's runtime PM suspend callback is invoked at any
 later point.

if I understand things right (thanks to Russell), the Power domain may not
 be powered off not only in above case, but also in some cases when
driver is unloaded.

AMBA bus for example:
static int amba_remove(struct device *dev)
{
pm_runtime_get_sync(dev); -- GPD=on, dev is active, 
usage_count = 1
ret = drv-remove(pcdev); --- GPD=on, should do balancing 
put() to compensate all get() made by driver, usage_count == 1
  --- GPD=on, should do balancing 
get() to compensate put() in probe, usage_count == 2
pm_runtime_put_noidle(dev); -- GPD=on, dev is active, 
usage_count == 1

/* Undo the runtime PM settings in amba_probe() */
pm_runtime_disable(dev);  -- GPD=on, dev is active, 
usage_count == 1
pm_runtime_set_suspended(dev); -- GPD=on, dev is suspended, 
usage_count == 1
pm_runtime_put_noidle(dev); -- GPD=on, dev is suspended, 
usage_count == 0

amba_put_disable_pclk(pcdev);
dev_pm_domain_detach(dev, true); -- GPD=on, dev is suspended, 
usage_count == 0

also:
 i2c-qup.c
 i2c-hix5hd2.c
 exynos_drm_gsc.c
 exynos_drm_fimc.c
 ab8500-gpadc.c
 ...

Is it?

 

 I see three options going forward.

 Option 1)
 Convert scenario 3) and 4) into using the pm_runtime_get_sync()
 approach. There are no theoretical obstacles to do this, but pure
 practical. There are a lot of drivers that needs to be converted and
 we also need to teach driver authors future wise to not use
 pm_runtime_set_active() in this manner.

 I'd say we need to do something like this anyway.  That is, standardize on
 *one* approach.  I'm actually not sure what approach is the most useful,
 but the pm_runtime_get_sync() one seems to be the most popular to me.

 Option 2)
 Add some kind of get/put API for PM domains. The buses invokes it to
 control the power to the PM domain. From what I understand, that's
 also what Dmitry think is needed!?
 Anyway, that somehow means to proceed with the approach I took in the
 below patchset.
 [PATCH v3 0/9] PM / Domains: Fix race conditions during boot
 http://marc.info/?t=14132090703r=1w=2

 I don't like that.  The API is already quite complicated in my view and
 adding even more complexity to it is not going to help in the long run.
 
 I absolutely agree that we shouldn't add unnecessary APIs and keep
 APIs as simple as 

Re: [PATCH] MAINTAINERS: update email address and cleanup for exynos entry

2014-11-20 Thread Arnd Bergmann
On Monday 17 November 2014, Ben Dooks wrote:
 On 14/11/14 07:54, Kukjin Kim wrote:
  Use kernel.org account instead of samsung.com and cleanup for Samsung
  s3c, s5p and exynos SoCs.
  
  Cc: Ben Dooks ben.do...@codethink.co.uk
 
 I do wish these would be sent to the mail address I use for
 Linux related issues. I only want to see work related Linux
 issues to my ben.do...@codethink.co.uk address.
 
 It is sad to see my entries removed, but I no longer have time
 to maintain these.
 
  Signed-off-by: Kukjin Kim kg...@kernel.org
 Acked-by: Ben Dooks ben-li...@fluff.org

Applied to next/fixes-non-critical, thanks!

Arnd
--
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] PM / Domains: Power on the PM domain right after attach completes

2014-11-20 Thread Ulf Hansson
On 20 November 2014 13:17, Grygorii Strashko grygorii.stras...@ti.com wrote:
 On 11/19/2014 10:54 AM, Ulf Hansson wrote:
 [...]


 Scenario 5), a platform driver with/without runtime PM callbacks.
 -probe()
 - do some initialization
 - may fetch handles to runtime PM resources
 - pm_runtime_enable()

 Well, and now how the driver knows if the device is on before accessing 
 it?

 In this case the driver don't need to access the device during
 -probe(). That's postponed until sometime later.


 Note 1)
 Scenario 1) and 2), both relies on the approach to power on the PM
 domain by using pm_runtime_get_sync(). That approach didn't work when
 CONFIG_PM_RUNTIME was unset, but we recently decided to fixed that by
 the below patch, so that's good!
 [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd 
 enabled

 Note 2)
 Scenario 3) and 4) use the same principles for managing runtime PM.
 These scenarios needs a way to power on the generic PM domain prior
 probing the device. The call to pm_runtime_set_active(), prevents an
 already powered PM domain from power off until after probe, but that's
 not enough.

 Note 3)
 The $subject patch, tried to address the issues for scenario 3) and
 4). It does so, but will affect scenario 5) which was working nicely
 before. In scenario 5), the $subject patch will cause the generic PM
 domain to potentially stay powered after -probe() even if the device
 is runtime PM suspended.

 Why would it?  If the device is runtime-suspended, the domain will know
 that, because its callbacks will be used for that.  At least, that's
 what I'd expect to happen, so is there a problem here?

 Genpd do knows about the device but it doesn’t get a notification to
 power off. There are no issues whatsoever for driver.

 This is a somewhat special case. Let's go through an example.

 1. The PM domain is initially in powered off state.
 2. The bus -probe() invokes dev_pm_domain_attach() and then the PM
 domain gets attached to the device.
 3. $subject patch causes the PM domain to power on.
 4. A driver -probe() sequence start, following the Scenario 5).
 5. The device is initially in runtime PM suspended state and it will
 remain so during -probe().
 6. The pm_request_idle() invoked after really_probe() in driver core,
 won't trigger a runtime PM suspend callback to be invoked. In other
 words, genpd don't get a notification that it may power off.

 In this state, genpd will either power off from the late_initcall,
 genpd_poweroff_unused() (depending on when the driver was probed) or
 wait until some device's runtime PM suspend callback is invoked at any
 later point.

 if I understand things right (thanks to Russell), the Power domain may not
  be powered off not only in above case, but also in some cases when
 driver is unloaded.

 AMBA bus for example:
 static int amba_remove(struct device *dev)
 {
 pm_runtime_get_sync(dev); -- GPD=on, dev is active, 
 usage_count = 1
 ret = drv-remove(pcdev); --- GPD=on, should do balancing 
 put() to compensate all get() made by driver, usage_count == 1
   --- GPD=on, should do balancing 
 get() to compensate put() in probe, usage_count == 2
 pm_runtime_put_noidle(dev); -- GPD=on, dev is active, 
 usage_count == 1

 /* Undo the runtime PM settings in amba_probe() */
 pm_runtime_disable(dev);  -- GPD=on, dev is active, 
 usage_count == 1
 pm_runtime_set_suspended(dev); -- GPD=on, dev is suspended, 
 usage_count == 1
 pm_runtime_put_noidle(dev); -- GPD=on, dev is suspended, 
 usage_count == 0

 amba_put_disable_pclk(pcdev);
 dev_pm_domain_detach(dev, true); -- GPD=on, dev is 
 suspended, usage_count == 0

For the generic OF-based PM domain look-up case:
-dev_pm_domain_detach()
-genpd_dev_pm_detach() - to remove the device from the PM domain.
   -genpd_queue_power_off_work() - to power off unused PM domains.

That does the trick, right!?

Kind regards
Uffe
--
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: [RFC PATCH v3 1/4] drm/exynos: make kms drivers to be independent drivers

2014-11-20 Thread Andrzej Hajda
On 11/20/2014 11:24 AM, Inki Dae wrote:
 This patch makes kms drivers to be independent drivers.
 For this, it removes all register codes to kms drivers
 from exynos_drm_drv module and adds module_init/exit
 for each kms driver so that each kms driver can be
 called independently.
 
 Changelog v3:
 - Use module_platform_driver macro instead module_init/exit.
 - Configure all kms drivers to be built in kernel image.
 
 Changelog v2:
 - none
 
 Signed-off-by: Inki Dae inki@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_dp_core.c  |2 ++
  drivers/gpu/drm/exynos/exynos_drm_drv.c  |   43 
 +++---
  drivers/gpu/drm/exynos/exynos_drm_drv.h  |5 
  drivers/gpu/drm/exynos/exynos_drm_dsi.c  |2 ++
  drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 ++
  drivers/gpu/drm/exynos/exynos_hdmi.c |2 ++
  drivers/gpu/drm/exynos/exynos_mixer.c|2 ++
  7 files changed, 13 insertions(+), 45 deletions(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
 b/drivers/gpu/drm/exynos/exynos_dp_core.c
 index ed818b9..30ebf5d 100644
 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
 +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
 @@ -1408,6 +1408,8 @@ struct platform_driver dp_driver = {
   },
  };
  
 +module_platform_driver(dp_driver);

If you try to build exynosdrm as module you will receive errors due to
multiple definitions of init_module, ie module_init/module_*_driver
macros can be used once per module.

Anyway I am afraid exynosdrm seems to be still fragile to order of
successful probes of their components.
It can be easily observed on the system with two display pipelines with
one of them probe deferring. For example universal with fimd/dpi + vidi:
1. fimd defers probe because panel is not yet probed.
2. vidi probes ok.
3. drmdev is initialized.
4. fimd probes ok, but it is too late!!!

So you can reproduce the scenario on any target when one of the
components defers and vidi is present (vidi never defers I suppose).

Regards
Andrzej

 +
  MODULE_AUTHOR(Jingoo Han jg1@samsung.com);
  MODULE_DESCRIPTION(Samsung SoC DP Driver);
  MODULE_LICENSE(GPL v2);
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 index eab12f0..02d4772 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 @@ -484,12 +484,6 @@ static struct component_match 
 *exynos_drm_match_add(struct device *dev)
  
   mutex_lock(drm_component_lock);
  
 - /* Do not retry to probe if there is no any kms driver regitered. */
 - if (list_empty(drm_component_list)) {
 - mutex_unlock(drm_component_lock);
 - return ERR_PTR(-ENODEV);
 - }
 -
   list_for_each_entry(cdev, drm_component_list, list) {
   /*
* Add components to master only in case that crtc and
 @@ -545,22 +539,6 @@ static const struct component_master_ops exynos_drm_ops 
 = {
   .unbind = exynos_drm_unbind,
  };
  
 -static struct platform_driver *const exynos_drm_kms_drivers[] = {
 -#ifdef CONFIG_DRM_EXYNOS_FIMD
 - fimd_driver,
 -#endif
 -#ifdef CONFIG_DRM_EXYNOS_DP
 - dp_driver,
 -#endif
 -#ifdef CONFIG_DRM_EXYNOS_DSI
 - dsi_driver,
 -#endif
 -#ifdef CONFIG_DRM_EXYNOS_HDMI
 - mixer_driver,
 - hdmi_driver,
 -#endif
 -};
 -
  static struct platform_driver *const exynos_drm_non_kms_drivers[] = {
  #ifdef CONFIG_DRM_EXYNOS_G2D
   g2d_driver,
 @@ -587,22 +565,14 @@ static int exynos_drm_platform_probe(struct 
 platform_device *pdev)
   pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
   exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
  
 - for (i = 0; i  ARRAY_SIZE(exynos_drm_kms_drivers); ++i) {
 - ret = platform_driver_register(exynos_drm_kms_drivers[i]);
 - if (ret  0)
 - goto err_unregister_kms_drivers;
 - }
 -
   match = exynos_drm_match_add(pdev-dev);
 - if (IS_ERR(match)) {
 - ret = PTR_ERR(match);
 - goto err_unregister_kms_drivers;
 - }
 + if (IS_ERR(match))
 + return PTR_ERR(match);
  
   ret = component_master_add_with_match(pdev-dev, exynos_drm_ops,
   match);
   if (ret  0)
 - goto err_unregister_kms_drivers;
 + return ret;
  
   for (j = 0; j  ARRAY_SIZE(exynos_drm_non_kms_drivers); ++j) {
   ret = platform_driver_register(exynos_drm_non_kms_drivers[j]);
 @@ -632,10 +602,6 @@ err_unregister_non_kms_drivers:
  err_del_component_master:
   component_master_del(pdev-dev, exynos_drm_ops);
  
 -err_unregister_kms_drivers:
 - while (--i = 0)
 - platform_driver_unregister(exynos_drm_kms_drivers[i]);
 -
   return ret;
  }
  
 @@ -654,9 +620,6 @@ static int exynos_drm_platform_remove(struct 
 platform_device *pdev)
  
   component_master_del(pdev-dev, exynos_drm_ops);
  
 - for (i = 

[PATCH 0/2] Add regulator-haptic driver

2014-11-20 Thread Jaewon Kim
This patch series adds regulator-haptic driver.
The regulator-haptic has haptic motor and it is controlled by
voltage of regulator via force feedback framework.

Jaewon Kim (2):
  Input: add regulator haptic driver
  ARM: dts: Add regulator-haptic device node for exynos3250-rinato

 .../devicetree/bindings/input/regulator-haptic.txt |   24 ++
 arch/arm/boot/dts/exynos3250-rinato.dts|7 +
 drivers/input/misc/Kconfig |   11 +
 drivers/input/misc/Makefile|1 +
 drivers/input/misc/regulator-haptic.c  |  241 
 5 files changed, 284 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/regulator-haptic.txt
 create mode 100644 drivers/input/misc/regulator-haptic.c

-- 
1.7.9.5

--
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/2] ARM: dts: Add regulator-haptic device node for exynos3250-rinato

2014-11-20 Thread Jaewon Kim
This patch adds regulator-haptic device node controlled by regulator.

Signed-off-by: Jaewon Kim jaewon02@samsung.com
---
 arch/arm/boot/dts/exynos3250-rinato.dts |7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts 
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 84380fa..8172815 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -104,6 +104,13 @@
};
};
};
+
+   regulator-haptic {
+   compatible = regulator-haptic;
+   haptic-supply = motor_reg;
+   min-microvolt = 110;
+   max-microvolt = 270;
+   };
 };
 
 adc {
-- 
1.7.9.5

--
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/2] Input: add regulator haptic driver

2014-11-20 Thread Jaewon Kim
This patch adds support for haptic driver controlled by
voltage of regulator. And this driver support for
Force Feedback interface from input framework

Signed-off-by: Jaewon Kim jaewon02@samsung.com
Signed-off-by: Hyunhee Kim hyunhee@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
 .../devicetree/bindings/input/regulator-haptic.txt |   24 ++
 drivers/input/misc/Kconfig |   11 +
 drivers/input/misc/Makefile|1 +
 drivers/input/misc/regulator-haptic.c  |  241 
 4 files changed, 277 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/regulator-haptic.txt
 create mode 100644 drivers/input/misc/regulator-haptic.c

diff --git a/Documentation/devicetree/bindings/input/regulator-haptic.txt 
b/Documentation/devicetree/bindings/input/regulator-haptic.txt
new file mode 100644
index 000..9f60e17
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/regulator-haptic.txt
@@ -0,0 +1,24 @@
+* Requlator Haptic Device Tree Bindings
+
+The regulator haptic driver controlled by voltage of regulator.
+This driver implemented via Force Feedback interface.
+
+Required Properties:
+ - compatible : Should be regulator-haptic
+ - haptic-supply : Power supply for the haptic motor.
+   [*] refer Documentation/devicetree/bindings/regulator/regulator.txt
+
+ - max-microvolt : The maximum voltage value supplied to haptic motor.
+   [The unit of the voltage is a micro]
+
+ - min-microvolt : The minimum voltage value in which haptic motor reacts.
+   [The unit of the voltage is a micro]
+
+Example:
+
+   regulator-haptic {
+   compatible = regulator-haptic;
+   haptic-supply = motor_regulator;
+   max-microvolt = 270;
+   min-microvolt = 110;
+   };
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 23297ab..e5e556d 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -394,6 +394,17 @@ config INPUT_CM109
  To compile this driver as a module, choose M here: the module will be
  called cm109.
 
+config INPUT_REGULATOR_HAPTIC
+   tristate regulator haptics support
+   select INPUT_FF_MEMLESS
+   help
+ This option enables device driver support for the haptic controlled
+ by regulator. This driver supports ff-memless interface
+ from input framework.
+
+ To compile this driver as a module, choose M here: the
+ module will be called regulator-haptic.
+
 config INPUT_RETU_PWRBUTTON
tristate Retu Power button Driver
depends on MFD_RETU
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 19c7603..1f135af 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY)   += pmic8xxx-pwrkey.o
 obj-$(CONFIG_INPUT_POWERMATE)  += powermate.o
 obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
 obj-$(CONFIG_INPUT_RB532_BUTTON)   += rb532_button.o
+obj-$(CONFIG_INPUT_REGULATOR_HAPTIC)   += regulator-haptic.o
 obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o
 obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER)+= rotary_encoder.o
 obj-$(CONFIG_INPUT_SGI_BTNS)   += sgi_btns.o
diff --git a/drivers/input/misc/regulator-haptic.c 
b/drivers/input/misc/regulator-haptic.c
new file mode 100644
index 000..1a83ecb
--- /dev/null
+++ b/drivers/input/misc/regulator-haptic.c
@@ -0,0 +1,241 @@
+/*
+ * Regulator haptic driver
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Jaewon Kim jaewon02@samsung.com
+ * Author: Hyunhee Kim hyunhee@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/input.h
+#include linux/slab.h
+#include linux/regulator/consumer.h
+#include linux/of.h
+
+#define MAX_MAGNITUDE_SHIFT16
+
+struct regulator_haptic {
+   struct device *dev;
+   struct input_dev *input_dev;
+   struct regulator *regulator;
+   struct work_struct work;
+
+   bool enabled;
+   bool suspend_state;
+   unsigned int max_volt;
+   unsigned int min_volt;
+   unsigned int intensity;
+   unsigned int magnitude;
+};
+
+static void regulator_haptic_enable(struct regulator_haptic *haptic)
+{
+   int error;
+
+   if (haptic-enabled)
+   return;
+
+   error = regulator_enable(haptic-regulator);
+   if (error) {
+   dev_err(haptic-dev, cannot enable regulator\n);
+   return;
+   }
+
+   haptic-enabled = true;
+}
+
+static void regulator_haptic_disable(struct regulator_haptic *haptic)
+{
+   int error;
+
+   if (!haptic-enabled)
+

Re: [RFC PATCH v3 1/4] drm/exynos: make kms drivers to be independent drivers

2014-11-20 Thread Inki Dae
On 2014년 11월 20일 22:19, Andrzej Hajda wrote:
 On 11/20/2014 11:24 AM, Inki Dae wrote:
 This patch makes kms drivers to be independent drivers.
 For this, it removes all register codes to kms drivers
 from exynos_drm_drv module and adds module_init/exit
 for each kms driver so that each kms driver can be
 called independently.

 Changelog v3:
 - Use module_platform_driver macro instead module_init/exit.
 - Configure all kms drivers to be built in kernel image.

 Changelog v2:
 - none

 Signed-off-by: Inki Dae inki@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_dp_core.c  |2 ++
  drivers/gpu/drm/exynos/exynos_drm_drv.c  |   43 
 +++---
  drivers/gpu/drm/exynos/exynos_drm_drv.h  |5 
  drivers/gpu/drm/exynos/exynos_drm_dsi.c  |2 ++
  drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 ++
  drivers/gpu/drm/exynos/exynos_hdmi.c |2 ++
  drivers/gpu/drm/exynos/exynos_mixer.c|2 ++
  7 files changed, 13 insertions(+), 45 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
 b/drivers/gpu/drm/exynos/exynos_dp_core.c
 index ed818b9..30ebf5d 100644
 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
 +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
 @@ -1408,6 +1408,8 @@ struct platform_driver dp_driver = {
  },
  };
  
 +module_platform_driver(dp_driver);
 
 If you try to build exynosdrm as module you will receive errors due to
 multiple definitions of init_module, ie module_init/module_*_driver
 macros can be used once per module.

Ah, right. we had ever tried same way before but failed in same problem.
I didn't realize that. Anyway, I will try to find out a better way. I'd
really like to remove all register codes of sub drivers from
exynos_drm_drv somehow.

 
 Anyway I am afraid exynosdrm seems to be still fragile to order of
 successful probes of their components.
 It can be easily observed on the system with two display pipelines with
 one of them probe deferring. For example universal with fimd/dpi + vidi:
 1. fimd defers probe because panel is not yet probed.
 2. vidi probes ok.
 3. drmdev is initialized.
 4. fimd probes ok, but it is too late!!!
 
 So you can reproduce the scenario on any target when one of the
 components defers and vidi is present (vidi never defers I suppose).

Thanks for checking,
Inki Dae

 
 Regards
 Andrzej
 
 +
  MODULE_AUTHOR(Jingoo Han jg1@samsung.com);
  MODULE_DESCRIPTION(Samsung SoC DP Driver);
  MODULE_LICENSE(GPL v2);
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 index eab12f0..02d4772 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 @@ -484,12 +484,6 @@ static struct component_match 
 *exynos_drm_match_add(struct device *dev)
  
  mutex_lock(drm_component_lock);
  
 -/* Do not retry to probe if there is no any kms driver regitered. */
 -if (list_empty(drm_component_list)) {
 -mutex_unlock(drm_component_lock);
 -return ERR_PTR(-ENODEV);
 -}
 -
  list_for_each_entry(cdev, drm_component_list, list) {
  /*
   * Add components to master only in case that crtc and
 @@ -545,22 +539,6 @@ static const struct component_master_ops exynos_drm_ops 
 = {
  .unbind = exynos_drm_unbind,
  };
  
 -static struct platform_driver *const exynos_drm_kms_drivers[] = {
 -#ifdef CONFIG_DRM_EXYNOS_FIMD
 -fimd_driver,
 -#endif
 -#ifdef CONFIG_DRM_EXYNOS_DP
 -dp_driver,
 -#endif
 -#ifdef CONFIG_DRM_EXYNOS_DSI
 -dsi_driver,
 -#endif
 -#ifdef CONFIG_DRM_EXYNOS_HDMI
 -mixer_driver,
 -hdmi_driver,
 -#endif
 -};
 -
  static struct platform_driver *const exynos_drm_non_kms_drivers[] = {
  #ifdef CONFIG_DRM_EXYNOS_G2D
  g2d_driver,
 @@ -587,22 +565,14 @@ static int exynos_drm_platform_probe(struct 
 platform_device *pdev)
  pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
  exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
  
 -for (i = 0; i  ARRAY_SIZE(exynos_drm_kms_drivers); ++i) {
 -ret = platform_driver_register(exynos_drm_kms_drivers[i]);
 -if (ret  0)
 -goto err_unregister_kms_drivers;
 -}
 -
  match = exynos_drm_match_add(pdev-dev);
 -if (IS_ERR(match)) {
 -ret = PTR_ERR(match);
 -goto err_unregister_kms_drivers;
 -}
 +if (IS_ERR(match))
 +return PTR_ERR(match);
  
  ret = component_master_add_with_match(pdev-dev, exynos_drm_ops,
  match);
  if (ret  0)
 -goto err_unregister_kms_drivers;
 +return ret;
  
  for (j = 0; j  ARRAY_SIZE(exynos_drm_non_kms_drivers); ++j) {
  ret = platform_driver_register(exynos_drm_non_kms_drivers[j]);
 @@ -632,10 +602,6 @@ err_unregister_non_kms_drivers:
  err_del_component_master:
  component_master_del(pdev-dev, exynos_drm_ops);
  
 -err_unregister_kms_drivers:
 -while (--i = 0)
 

Re: [RFC PATCH v3 1/4] drm/exynos: make kms drivers to be independent drivers

2014-11-20 Thread Javier Martinez Canillas
Hello Inki,

On Thu, Nov 20, 2014 at 2:56 PM, Inki Dae inki@samsung.com wrote:
 If you try to build exynosdrm as module you will receive errors due to
 multiple definitions of init_module, ie module_init/module_*_driver
 macros can be used once per module.

 Ah, right. we had ever tried same way before but failed in same problem.
 I didn't realize that. Anyway, I will try to find out a better way. I'd
 really like to remove all register codes of sub drivers from
 exynos_drm_drv somehow.


Maybe as an immediate fix we can move the platform driver registration
out of probe as suggested by Andrzej?

I posted an RFC patch a couple of days ago [0] that fixes both the
deadlock and the infinite loop bug so it would be great if you can
review/test so I can post a proper patch.

And then we can look how to better refactor the exynos drm driver.

Best regards,
Javier

[0]: http://www.spinics.net/lists/linux-samsung-soc/msg39106.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: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

2014-11-20 Thread Inki Dae
Hi Javier,

On 2014년 11월 18일 22:53, Javier Martinez Canillas wrote:
 The Exynos DRM driver register its sub-devices platform drivers in
 the probe function but after commit 43c0767 (of/platform: Move
 platform devices under /sys/devices/platform), this is causing
 a deadlock in __driver_attach(). Fix this by moving the platform
 drivers registration to exynos_drm_init().

Could you re-base this patch on top of exynos-drm-next? I tried to
separate sub drivers into independent drivers but it seems that we need
more times. So I will merge your patch.

Thanks,
Inki Dae

 
 Suggested-by: Andrzej Hajda a.ha...@samsung.com
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
 
 This issue was reported by both Krzysztof Kozlowski [0] and Kevin Hilman [1].
 
 Inki Dae said that he will fix it property by separating the Exynos DRM
 driver in different sub-modules but I post this patch as RFC anyways so
 others can test if this fixes their boot issue.
 
 [0]: https://lkml.org/lkml/2014/11/6/125
 [1]: http://www.spinics.net/lists/linux-samsung-soc/msg39050.html
 
  drivers/gpu/drm/exynos/exynos_drm_drv.c | 163 
 
  1 file changed, 79 insertions(+), 84 deletions(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 index e277d4f..5386fea 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 @@ -559,15 +559,58 @@ static const struct component_master_ops exynos_drm_ops 
 = {
  static int exynos_drm_platform_probe(struct platform_device *pdev)
  {
   struct component_match *match;
 - int ret;
  
   pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
   exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
  
 + match = exynos_drm_match_add(pdev-dev);
 + if (IS_ERR(match))
 + return PTR_ERR(match);
 +
 + return component_master_add_with_match(pdev-dev, exynos_drm_ops,
 +match);
 +}
 +
 +static int exynos_drm_platform_remove(struct platform_device *pdev)
 +{
 + component_master_del(pdev-dev, exynos_drm_ops);
 + return 0;
 +}
 +
 +static struct platform_driver exynos_drm_platform_driver = {
 + .probe  = exynos_drm_platform_probe,
 + .remove = exynos_drm_platform_remove,
 + .driver = {
 + .name   = exynos-drm,
 + .pm = exynos_drm_pm_ops,
 + },
 +};
 +
 +static int exynos_drm_init(void)
 +{
 + int ret;
 +
 + /*
 +  * Register device object only in case of Exynos SoC.
 +  *
 +  * Below codes resolves temporarily infinite loop issue incurred
 +  * by Exynos drm driver when using multi-platform kernel.
 +  * So these codes will be replaced with more generic way later.
 +  */
 + if (!of_machine_is_compatible(samsung,exynos3) 
 + !of_machine_is_compatible(samsung,exynos4) 
 + !of_machine_is_compatible(samsung,exynos5))
 + return -ENODEV;
 +
 + exynos_drm_pdev = platform_device_register_simple(exynos-drm, -1,
 + NULL, 0);
 + if (IS_ERR(exynos_drm_pdev))
 + return PTR_ERR(exynos_drm_pdev);
 +
  #ifdef CONFIG_DRM_EXYNOS_FIMD
   ret = platform_driver_register(fimd_driver);
   if (ret  0)
 - return ret;
 + goto err_unregister_pdev;
  #endif
  
  #ifdef CONFIG_DRM_EXYNOS_DP
 @@ -591,21 +634,10 @@ static int exynos_drm_platform_probe(struct 
 platform_device *pdev)
   goto err_unregister_mixer_drv;
  #endif
  
 - match = exynos_drm_match_add(pdev-dev);
 - if (IS_ERR(match)) {
 - ret = PTR_ERR(match);
 - goto err_unregister_hdmi_drv;
 - }
 -
 - ret = component_master_add_with_match(pdev-dev, exynos_drm_ops,
 - match);
 - if (ret  0)
 - goto err_unregister_hdmi_drv;
 -
  #ifdef CONFIG_DRM_EXYNOS_G2D
   ret = platform_driver_register(g2d_driver);
   if (ret  0)
 - goto err_del_component_master;
 + goto err_unregister_hdmi_drv;
  #endif
  
  #ifdef CONFIG_DRM_EXYNOS_FIMC
 @@ -636,9 +668,27 @@ static int exynos_drm_platform_probe(struct 
 platform_device *pdev)
   goto err_unregister_ipp_drv;
  #endif
  
 - return ret;
 +#ifdef CONFIG_DRM_EXYNOS_VIDI
 + ret = exynos_drm_probe_vidi();
 + if (ret  0)
 + goto err_unregister_ipp_dev;
 +#endif
 +
 + ret = platform_driver_register(exynos_drm_platform_driver);
 + if (ret)
 + goto err_remove_vidi;
 +
 + return 0;
 +
 +err_remove_vidi:
 +#ifdef CONFIG_DRM_EXYNOS_VIDI
 + exynos_drm_remove_vidi();
 +err_unregister_pd:
 +#endif
  
  #ifdef CONFIG_DRM_EXYNOS_IPP
 +err_unregister_ipp_dev:
 + exynos_platform_device_ipp_unregister();
  err_unregister_ipp_drv:
   platform_driver_unregister(ipp_driver);
  

Re: [RFC PATCH v3 1/4] drm/exynos: make kms drivers to be independent drivers

2014-11-20 Thread Inki Dae
Hi Javier,

On 2014년 11월 20일 23:06, Javier Martinez Canillas wrote:
 Hello Inki,
 
 On Thu, Nov 20, 2014 at 2:56 PM, Inki Dae inki@samsung.com wrote:
 If you try to build exynosdrm as module you will receive errors due to
 multiple definitions of init_module, ie module_init/module_*_driver
 macros can be used once per module.

 Ah, right. we had ever tried same way before but failed in same problem.
 I didn't realize that. Anyway, I will try to find out a better way. I'd
 really like to remove all register codes of sub drivers from
 exynos_drm_drv somehow.

 
 Maybe as an immediate fix we can move the platform driver registration
 out of probe as suggested by Andrzej?
 
 I posted an RFC patch a couple of days ago [0] that fixes both the
 deadlock and the infinite loop bug so it would be great if you can
 review/test so I can post a proper patch.

Fantastical timing.:) I gave you a same opinion almost simultaneous.
Check your email thread.

Thanks,
Inki Dae

 
 And then we can look how to better refactor the exynos drm driver.
 
 Best regards,
 Javier
 
 [0]: http://www.spinics.net/lists/linux-samsung-soc/msg39106.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: [RFC PATCH v3 1/4] drm/exynos: make kms drivers to be independent drivers

2014-11-20 Thread Andrzej Hajda
On 11/20/2014 02:56 PM, Inki Dae wrote:
 On 2014년 11월 20일 22:19, Andrzej Hajda wrote:
 On 11/20/2014 11:24 AM, Inki Dae wrote:
 This patch makes kms drivers to be independent drivers.
 For this, it removes all register codes to kms drivers
 from exynos_drm_drv module and adds module_init/exit
 for each kms driver so that each kms driver can be
 called independently.

 Changelog v3:
 - Use module_platform_driver macro instead module_init/exit.
 - Configure all kms drivers to be built in kernel image.

 Changelog v2:
 - none

 Signed-off-by: Inki Dae inki@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_dp_core.c  |2 ++
  drivers/gpu/drm/exynos/exynos_drm_drv.c  |   43 
 +++---
  drivers/gpu/drm/exynos/exynos_drm_drv.h  |5 
  drivers/gpu/drm/exynos/exynos_drm_dsi.c  |2 ++
  drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 ++
  drivers/gpu/drm/exynos/exynos_hdmi.c |2 ++
  drivers/gpu/drm/exynos/exynos_mixer.c|2 ++
  7 files changed, 13 insertions(+), 45 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
 b/drivers/gpu/drm/exynos/exynos_dp_core.c
 index ed818b9..30ebf5d 100644
 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
 +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
 @@ -1408,6 +1408,8 @@ struct platform_driver dp_driver = {
 },
  };
  
 +module_platform_driver(dp_driver);

 If you try to build exynosdrm as module you will receive errors due to
 multiple definitions of init_module, ie module_init/module_*_driver
 macros can be used once per module.
 
 Ah, right. we had ever tried same way before but failed in same problem.
 I didn't realize that. Anyway, I will try to find out a better way. I'd
 really like to remove all register codes of sub drivers from
 exynos_drm_drv somehow.

I have proposed once solution with sparse arrays, using linker scripts
[1]. Something similar is used with clock controllers as I remember.
I do not see other possibilities to fully separate components of
exynos_drm_drv.

[1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/103816

Regards
Andrzej

 

 Anyway I am afraid exynosdrm seems to be still fragile to order of
 successful probes of their components.
 It can be easily observed on the system with two display pipelines with
 one of them probe deferring. For example universal with fimd/dpi + vidi:
 1. fimd defers probe because panel is not yet probed.
 2. vidi probes ok.
 3. drmdev is initialized.
 4. fimd probes ok, but it is too late!!!

 So you can reproduce the scenario on any target when one of the
 components defers and vidi is present (vidi never defers I suppose).
 
 Thanks for checking,
 Inki Dae
 

 Regards
 Andrzej

 +
  MODULE_AUTHOR(Jingoo Han jg1@samsung.com);
  MODULE_DESCRIPTION(Samsung SoC DP Driver);
  MODULE_LICENSE(GPL v2);
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 index eab12f0..02d4772 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 @@ -484,12 +484,6 @@ static struct component_match 
 *exynos_drm_match_add(struct device *dev)
  
 mutex_lock(drm_component_lock);
  
 -   /* Do not retry to probe if there is no any kms driver regitered. */
 -   if (list_empty(drm_component_list)) {
 -   mutex_unlock(drm_component_lock);
 -   return ERR_PTR(-ENODEV);
 -   }
 -
 list_for_each_entry(cdev, drm_component_list, list) {
 /*
  * Add components to master only in case that crtc and
 @@ -545,22 +539,6 @@ static const struct component_master_ops 
 exynos_drm_ops = {
 .unbind = exynos_drm_unbind,
  };
  
 -static struct platform_driver *const exynos_drm_kms_drivers[] = {
 -#ifdef CONFIG_DRM_EXYNOS_FIMD
 -   fimd_driver,
 -#endif
 -#ifdef CONFIG_DRM_EXYNOS_DP
 -   dp_driver,
 -#endif
 -#ifdef CONFIG_DRM_EXYNOS_DSI
 -   dsi_driver,
 -#endif
 -#ifdef CONFIG_DRM_EXYNOS_HDMI
 -   mixer_driver,
 -   hdmi_driver,
 -#endif
 -};
 -
  static struct platform_driver *const exynos_drm_non_kms_drivers[] = {
  #ifdef CONFIG_DRM_EXYNOS_G2D
 g2d_driver,
 @@ -587,22 +565,14 @@ static int exynos_drm_platform_probe(struct 
 platform_device *pdev)
 pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
 exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
  
 -   for (i = 0; i  ARRAY_SIZE(exynos_drm_kms_drivers); ++i) {
 -   ret = platform_driver_register(exynos_drm_kms_drivers[i]);
 -   if (ret  0)
 -   goto err_unregister_kms_drivers;
 -   }
 -
 match = exynos_drm_match_add(pdev-dev);
 -   if (IS_ERR(match)) {
 -   ret = PTR_ERR(match);
 -   goto err_unregister_kms_drivers;
 -   }
 +   if (IS_ERR(match))
 +   return PTR_ERR(match);
  
 ret = component_master_add_with_match(pdev-dev, exynos_drm_ops,
 match);
 if (ret  0)
 -   goto err_unregister_kms_drivers;
 +   return ret;
  
 for (j = 0; j  

Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

2014-11-20 Thread Pankaj Dubey
On 20 November 2014 15:22, Vivek Gautam gautamvivek1...@gmail.com wrote:
 Hi Javier,


 On Thu, Nov 20, 2014 at 2:15 PM, Javier Martinez Canillas
 javier.marti...@collabora.co.uk wrote:
 Hello Vivek,

 On 11/20/2014 08:51 AM, Vivek Gautam wrote:

 I tested linux-next on Exynos5800 peach-pi board with linux-next and and 
 the two
 patches $Subject and [0].

 Below is my git hash:
 4d9e6ee drm/exynos: Move platform drivers registration to module init
 4545ed4 POSTED: arm: dts: Exynos5: Use pmu_system_controller phandle for 
 dp phy
 36391a5 Add linux-next specific files for 20141119
 9b1ced1 Merge branch 'akpm/master'
 282497e mm: add strictlimit knob

 used exynos_defconfig


 Same here.


 With this display works for me.
 Without $Subject patch i get lookup in drm.


 I tested with today linux-next (next-20141120) and display is indeed
 working for me. So it seems that whatever caused the error in the
 phy-exynos-mipi-video driver reported by Paolo, got fixed recently.

 My working git hash is:

 65a8d01 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
 a9b43cb drm/exynos: Move platform drivers registration to module init
 5b83d7a Add linux-next specific files for 20141120
 1172916 mm: add strictlimit knob

 I did have to disable CONFIG_SND_SOC_SNOW though, otherwise the kernel
 did not boot due the issue reported previously by Kevin.

 Javier can you tell me your git hash. Was it on yesterday's linux-next ?


 In fact, my branch where I could reproduce the phy-exynos-mipi-video issue
 was not based on yesterday's next but next-20141117. The git hash is:

 9fb5d7c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
 f740096 drm/exynos: Move platform drivers registration to module init
 efefb5c Add linux-next specific files for 20141117
 8c944d7 mm: add strictlimit knob

 With 3.18-rc5 i could see display on Exynos5800 peach-pi with
 following git hash:

 b6dca11 drm/exynos: dp: Remove support for unused dptx-phy
 7cc5c2d ARM: exynos_defconfig: Enable options for display panel support
 d0aca5e arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
 fc14f9c Linux 3.18-rc5
 e35c5a2 Merge tag 'armsoc-for-rc5' of
 git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

 I don't need this drm lockup patch with 3.18-rc5 (with exynos_defconfig).


 Yes, that works because the commit that caused the Exynos DRM lockup was:

 43c0767 (of/platform: Move platform devices under /sys/devices/platform)

 which landed in next-20141105.

 Reverting 43c0767 and only applying [0] should have the same effect.

 I am checking further with linux-samsung, coz i could see weird
 behavior as mentioned
 in [1] with linux-samsun/for-next merged with above git hash.


 Great, it should be good to know what caused:

 On linux-samsung tree the only patch that's missing apart from dptx-phy 
 patches
 is the syscon patch from Pankaj Dubey:
 b784b98 mfd: syscon: Decouple syscon interface from platform devices


This patch has landed in mfd/for-next and linux-next. Without this on
kgene/for-next, any driver
seeking PMU register via syscon API will fail to get regmap handles.

Thanks,
Pankaj Dubey

 So with below git hash, linux-samsung/for-next display works fine along with
 other devices that request PMU system controller :

 7bd219e drm/exynos: dp: Remove support for unused dptx-phy
 e8f21fd arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
 7099bde Revert Revert ARM: exynos_defconfig: Enable options for
 display panel support
 713a994 mfd: syscon: Decouple syscon interface from platform devices
 7552917 Revert ARM: exynos_defconfig: Enable options for display
 panel support /* This is Kukjin's for-next today */
 ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next
 26c6283 Merge branch 'v3.18-samsung-fixes' into for-next
 cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next
 98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers
 839275c ARM: exynos_defconfig: Use 16 minors per MMC block device
 0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow
 fc14f9c Linux 3.18-rc5



 exynos-mipi-video-phy 10040714.video-phy: can't request region for resource 
 [mem 0x10040714-0x1004071f]

 The only reason i see this fails is since PMU is now requesting the
 entire memory
 region with base 0x1004. We should convert the mipi-phy pmu
 register handling
 too through syscon.


 even when I could not reproduce it anymore with today's linux-next.

 [0]: https://lkml.org/lkml/2014/10/30/394
 [1]: http://www.spinics.net/lists/linux-samsung-soc/msg39032.html



 --
 Best Regards
 Vivek Gautam
 Samsung RD Institute, Bangalore
 India
 --
 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
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord

[PATCH 2/2] ARM: dts: Add max77693-haptic node for exynos4412-trats2

2014-11-20 Thread Jaewon Kim
This patch adds max77693-haptic node to support for haptic motor driver.

Signed-off-by: Jaewon Kim jaewon02@samsung.com
---
 arch/arm/boot/dts/exynos4412-trats2.dts |6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 72462e8..8ddebbc 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -543,6 +543,12 @@
regulator-max-microamp = 258;
};
};
+
+   max77693_haptic {
+   compatible = maxim,max77693-haptic;
+   haptic-supply = ldo26_reg;
+   pwms = pwm 0 38022 0;
+   };
};
};
 
-- 
1.7.9.5

--
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/2] ARM: dts: add pwm node for exynos4412-trats2

2014-11-20 Thread Jaewon Kim
This patch add PWM(Pulse Width Modulation) node and
handle to use pwm property.

Signed-off-by: Jaewon Kim jaewon02@samsung.com
---
 arch/arm/boot/dts/exynos4412-trats2.dts |7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 8ee20bd..72462e8 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -636,6 +636,13 @@
};
};
 
+   pwm: pwm@139D {
+   pinctrl-0 = pwm0_out;
+   pinctrl-names = default;
+   samsung,pwm-outputs = 0;
+   status = okay;
+   };
+
dsi_0: dsi@11C8 {
vddcore-supply = ldo8_reg;
vddio-supply = ldo10_reg;
-- 
1.7.9.5

--
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: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

2014-11-20 Thread Javier Martinez Canillas
Hello Inki,

On 11/20/2014 03:07 PM, Inki Dae wrote:
 Could you re-base this patch on top of exynos-drm-next? I tried to
 separate sub drivers into independent drivers but it seems that we need
 more times. So I will merge your patch.
 

Sure, I'll rebase on top of exynos-drm-next and re-post so you can apply it.

BTW, it would be great if exynos-drm-next is pulled in linux-next. That is
what most people use to test integration issues so you can catch earlier any
regression that may arise.

You have to email Stephen Rothwell s...@canb.auug.org.au and point to your
tree and branch and he will be able to add it to linux-next.

 Thanks,
 Inki Dae
 

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 1/2] Input: add regulator haptic driver

2014-11-20 Thread Pankaj Dubey
Hi Jaewon,

On 20 November 2014 19:01, Jaewon Kim jaewon02@samsung.com wrote:
 This patch adds support for haptic driver controlled by
 voltage of regulator. And this driver support for
 Force Feedback interface from input framework

 Signed-off-by: Jaewon Kim jaewon02@samsung.com
 Signed-off-by: Hyunhee Kim hyunhee@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  .../devicetree/bindings/input/regulator-haptic.txt |   24 ++
  drivers/input/misc/Kconfig |   11 +
  drivers/input/misc/Makefile|1 +
  drivers/input/misc/regulator-haptic.c  |  241 
 
  4 files changed, 277 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/input/regulator-haptic.txt
  create mode 100644 drivers/input/misc/regulator-haptic.c

 diff --git a/Documentation/devicetree/bindings/input/regulator-haptic.txt 
 b/Documentation/devicetree/bindings/input/regulator-haptic.txt
 new file mode 100644
 index 000..9f60e17
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/input/regulator-haptic.txt
 @@ -0,0 +1,24 @@
 +* Requlator Haptic Device Tree Bindings
 +
 +The regulator haptic driver controlled by voltage of regulator.
 +This driver implemented via Force Feedback interface.
 +
 +Required Properties:
 + - compatible : Should be regulator-haptic
 + - haptic-supply : Power supply for the haptic motor.
 +   [*] refer Documentation/devicetree/bindings/regulator/regulator.txt
 +
 + - max-microvolt : The maximum voltage value supplied to haptic motor.
 +   [The unit of the voltage is a micro]
 +
 + - min-microvolt : The minimum voltage value in which haptic motor reacts.
 +   [The unit of the voltage is a micro]
 +
 +Example:
 +
 +   regulator-haptic {
 +   compatible = regulator-haptic;
 +   haptic-supply = motor_regulator;
 +   max-microvolt = 270;
 +   min-microvolt = 110;
 +   };
 diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
 index 23297ab..e5e556d 100644
 --- a/drivers/input/misc/Kconfig
 +++ b/drivers/input/misc/Kconfig
 @@ -394,6 +394,17 @@ config INPUT_CM109
   To compile this driver as a module, choose M here: the module will 
 be
   called cm109.

 +config INPUT_REGULATOR_HAPTIC
 +   tristate regulator haptics support
 +   select INPUT_FF_MEMLESS
 +   help
 + This option enables device driver support for the haptic controlled
 + by regulator. This driver supports ff-memless interface
 + from input framework.
 +
 + To compile this driver as a module, choose M here: the
 + module will be called regulator-haptic.
 +
  config INPUT_RETU_PWRBUTTON
 tristate Retu Power button Driver
 depends on MFD_RETU
 diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
 index 19c7603..1f135af 100644
 --- a/drivers/input/misc/Makefile
 +++ b/drivers/input/misc/Makefile
 @@ -53,6 +53,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY)   += pmic8xxx-pwrkey.o
  obj-$(CONFIG_INPUT_POWERMATE)  += powermate.o
  obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
  obj-$(CONFIG_INPUT_RB532_BUTTON)   += rb532_button.o
 +obj-$(CONFIG_INPUT_REGULATOR_HAPTIC)   += regulator-haptic.o
  obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o
  obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER)+= rotary_encoder.o
  obj-$(CONFIG_INPUT_SGI_BTNS)   += sgi_btns.o
 diff --git a/drivers/input/misc/regulator-haptic.c 
 b/drivers/input/misc/regulator-haptic.c
 new file mode 100644
 index 000..1a83ecb
 --- /dev/null
 +++ b/drivers/input/misc/regulator-haptic.c
 @@ -0,0 +1,241 @@
 +/*
 + * Regulator haptic driver
 + *
 + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
 + * Author: Jaewon Kim jaewon02@samsung.com
 + * Author: Hyunhee Kim hyunhee@samsung.com
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +
 +#include linux/module.h
 +#include linux/platform_device.h
 +#include linux/input.h
 +#include linux/slab.h
 +#include linux/regulator/consumer.h
 +#include linux/of.h
 +
 +#define MAX_MAGNITUDE_SHIFT16
 +
 +struct regulator_haptic {
 +   struct device *dev;
 +   struct input_dev *input_dev;
 +   struct regulator *regulator;
 +   struct work_struct work;
 +
 +   bool enabled;
 +   bool suspend_state;
 +   unsigned int max_volt;
 +   unsigned int min_volt;
 +   unsigned int intensity;
 +   unsigned int magnitude;
 +};
 +
 +static void regulator_haptic_enable(struct regulator_haptic *haptic)
 +{
 +   int error;
 +
 +   if (haptic-enabled)
 +   return;
 +
 +   error = regulator_enable(haptic-regulator);
 +   if (error) {
 +   dev_err(haptic-dev, cannot enable 

Re: [RFC PATCH v3 1/4] drm/exynos: make kms drivers to be independent drivers

2014-11-20 Thread Inki Dae
On 2014년 11월 20일 23:23, Andrzej Hajda wrote:
 On 11/20/2014 02:56 PM, Inki Dae wrote:
 On 2014년 11월 20일 22:19, Andrzej Hajda wrote:
 On 11/20/2014 11:24 AM, Inki Dae wrote:
 This patch makes kms drivers to be independent drivers.
 For this, it removes all register codes to kms drivers
 from exynos_drm_drv module and adds module_init/exit
 for each kms driver so that each kms driver can be
 called independently.

 Changelog v3:
 - Use module_platform_driver macro instead module_init/exit.
 - Configure all kms drivers to be built in kernel image.

 Changelog v2:
 - none

 Signed-off-by: Inki Dae inki@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_dp_core.c  |2 ++
  drivers/gpu/drm/exynos/exynos_drm_drv.c  |   43 
 +++---
  drivers/gpu/drm/exynos/exynos_drm_drv.h  |5 
  drivers/gpu/drm/exynos/exynos_drm_dsi.c  |2 ++
  drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 ++
  drivers/gpu/drm/exynos/exynos_hdmi.c |2 ++
  drivers/gpu/drm/exynos/exynos_mixer.c|2 ++
  7 files changed, 13 insertions(+), 45 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
 b/drivers/gpu/drm/exynos/exynos_dp_core.c
 index ed818b9..30ebf5d 100644
 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
 +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
 @@ -1408,6 +1408,8 @@ struct platform_driver dp_driver = {
},
  };
  
 +module_platform_driver(dp_driver);

 If you try to build exynosdrm as module you will receive errors due to
 multiple definitions of init_module, ie module_init/module_*_driver
 macros can be used once per module.

 Ah, right. we had ever tried same way before but failed in same problem.
 I didn't realize that. Anyway, I will try to find out a better way. I'd
 really like to remove all register codes of sub drivers from
 exynos_drm_drv somehow.
 
 I have proposed once solution with sparse arrays, using linker scripts
 [1]. Something similar is used with clock controllers as I remember.
 I do not see other possibilities to fully separate components of
 exynos_drm_drv.
 
 [1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/103816
 

I know this patch. I wasn't sure that the use of the private linker
section is reasonable and overuse it. Actually, Mr. Park opposed this
way. It might be a good idea if no problem for device drivers use the
private linker section. Is there any device driver using the private
linker section?

Thanks,
Inki Dae

 Regards
 Andrzej
 


 Anyway I am afraid exynosdrm seems to be still fragile to order of
 successful probes of their components.
 It can be easily observed on the system with two display pipelines with
 one of them probe deferring. For example universal with fimd/dpi + vidi:
 1. fimd defers probe because panel is not yet probed.
 2. vidi probes ok.
 3. drmdev is initialized.
 4. fimd probes ok, but it is too late!!!

 So you can reproduce the scenario on any target when one of the
 components defers and vidi is present (vidi never defers I suppose).

 Thanks for checking,
 Inki Dae


 Regards
 Andrzej

 +
  MODULE_AUTHOR(Jingoo Han jg1@samsung.com);
  MODULE_DESCRIPTION(Samsung SoC DP Driver);
  MODULE_LICENSE(GPL v2);
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 index eab12f0..02d4772 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 @@ -484,12 +484,6 @@ static struct component_match 
 *exynos_drm_match_add(struct device *dev)
  
mutex_lock(drm_component_lock);
  
 -  /* Do not retry to probe if there is no any kms driver regitered. */
 -  if (list_empty(drm_component_list)) {
 -  mutex_unlock(drm_component_lock);
 -  return ERR_PTR(-ENODEV);
 -  }
 -
list_for_each_entry(cdev, drm_component_list, list) {
/*
 * Add components to master only in case that crtc and
 @@ -545,22 +539,6 @@ static const struct component_master_ops 
 exynos_drm_ops = {
.unbind = exynos_drm_unbind,
  };
  
 -static struct platform_driver *const exynos_drm_kms_drivers[] = {
 -#ifdef CONFIG_DRM_EXYNOS_FIMD
 -  fimd_driver,
 -#endif
 -#ifdef CONFIG_DRM_EXYNOS_DP
 -  dp_driver,
 -#endif
 -#ifdef CONFIG_DRM_EXYNOS_DSI
 -  dsi_driver,
 -#endif
 -#ifdef CONFIG_DRM_EXYNOS_HDMI
 -  mixer_driver,
 -  hdmi_driver,
 -#endif
 -};
 -
  static struct platform_driver *const exynos_drm_non_kms_drivers[] = {
  #ifdef CONFIG_DRM_EXYNOS_G2D
g2d_driver,
 @@ -587,22 +565,14 @@ static int exynos_drm_platform_probe(struct 
 platform_device *pdev)
pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
  
 -  for (i = 0; i  ARRAY_SIZE(exynos_drm_kms_drivers); ++i) {
 -  ret = platform_driver_register(exynos_drm_kms_drivers[i]);
 -  if (ret  0)
 -  goto err_unregister_kms_drivers;
 -  }
 -
match = exynos_drm_match_add(pdev-dev);
 -  if (IS_ERR(match)) {
 -  ret = PTR_ERR(match);
 - 

Re: [PATCH] PM / Domains: Power on the PM domain right after attach completes

2014-11-20 Thread Grygorii Strashko

On 11/20/2014 03:01 PM, Ulf Hansson wrote:

On 20 November 2014 13:17, Grygorii Strashko grygorii.stras...@ti.com wrote:

On 11/19/2014 10:54 AM, Ulf Hansson wrote:

[...]



Scenario 5), a platform driver with/without runtime PM callbacks.
-probe()
- do some initialization
- may fetch handles to runtime PM resources
- pm_runtime_enable()


Well, and now how the driver knows if the device is on before accessing it?


In this case the driver don't need to access the device during
-probe(). That's postponed until sometime later.




Note 1)
Scenario 1) and 2), both relies on the approach to power on the PM
domain by using pm_runtime_get_sync(). That approach didn't work when
CONFIG_PM_RUNTIME was unset, but we recently decided to fixed that by
the below patch, so that's good!
[PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled

Note 2)
Scenario 3) and 4) use the same principles for managing runtime PM.
These scenarios needs a way to power on the generic PM domain prior
probing the device. The call to pm_runtime_set_active(), prevents an
already powered PM domain from power off until after probe, but that's
not enough.

Note 3)
The $subject patch, tried to address the issues for scenario 3) and
4). It does so, but will affect scenario 5) which was working nicely
before. In scenario 5), the $subject patch will cause the generic PM
domain to potentially stay powered after -probe() even if the device
is runtime PM suspended.


Why would it?  If the device is runtime-suspended, the domain will know
that, because its callbacks will be used for that.  At least, that's
what I'd expect to happen, so is there a problem here?


Genpd do knows about the device but it doesn’t get a notification to
power off. There are no issues whatsoever for driver.

This is a somewhat special case. Let's go through an example.

1. The PM domain is initially in powered off state.
2. The bus -probe() invokes dev_pm_domain_attach() and then the PM
domain gets attached to the device.
3. $subject patch causes the PM domain to power on.
4. A driver -probe() sequence start, following the Scenario 5).
5. The device is initially in runtime PM suspended state and it will
remain so during -probe().
6. The pm_request_idle() invoked after really_probe() in driver core,
won't trigger a runtime PM suspend callback to be invoked. In other
words, genpd don't get a notification that it may power off.

In this state, genpd will either power off from the late_initcall,
genpd_poweroff_unused() (depending on when the driver was probed) or
wait until some device's runtime PM suspend callback is invoked at any
later point.


if I understand things right (thanks to Russell), the Power domain may not
  be powered off not only in above case, but also in some cases when
driver is unloaded.

AMBA bus for example:
static int amba_remove(struct device *dev)
{
 pm_runtime_get_sync(dev); -- GPD=on, dev is active, usage_count 
= 1
 ret = drv-remove(pcdev); --- GPD=on, should do balancing 
put() to compensate all get() made by driver, usage_count == 1
   --- GPD=on, should do balancing 
get() to compensate put() in probe, usage_count == 2
 pm_runtime_put_noidle(dev); -- GPD=on, dev is active, 
usage_count == 1

 /* Undo the runtime PM settings in amba_probe() */
 pm_runtime_disable(dev);  -- GPD=on, dev is active, 
usage_count == 1
 pm_runtime_set_suspended(dev); -- GPD=on, dev is suspended, 
usage_count == 1
 pm_runtime_put_noidle(dev); -- GPD=on, dev is suspended, 
usage_count == 0

 amba_put_disable_pclk(pcdev);
 dev_pm_domain_detach(dev, true); -- GPD=on, dev is suspended, 
usage_count == 0


For the generic OF-based PM domain look-up case:
-dev_pm_domain_detach()
 -genpd_dev_pm_detach() - to remove the device from the PM domain.
-genpd_queue_power_off_work() - to power off unused PM domains.

That does the trick, right!?


True. Thanks a lot for pointing me on right place.

regards,
-grygorii
--
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 1/2] Input: add regulator haptic driver

2014-11-20 Thread Dan Murphy
Hi

On 11/20/2014 08:33 AM, Pankaj Dubey wrote:
 Hi Jaewon,

 On 20 November 2014 19:01, Jaewon Kim jaewon02@samsung.com wrote:
 This patch adds support for haptic driver controlled by
 voltage of regulator. And this driver support for
 Force Feedback interface from input framework

 Signed-off-by: Jaewon Kim jaewon02@samsung.com
 Signed-off-by: Hyunhee Kim hyunhee@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  .../devicetree/bindings/input/regulator-haptic.txt |   24 ++
  drivers/input/misc/Kconfig |   11 +
  drivers/input/misc/Makefile|1 +
  drivers/input/misc/regulator-haptic.c  |  241 
 
  4 files changed, 277 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/input/regulator-haptic.txt
  create mode 100644 drivers/input/misc/regulator-haptic.c

 diff --git a/Documentation/devicetree/bindings/input/regulator-haptic.txt 
 b/Documentation/devicetree/bindings/input/regulator-haptic.txt
 new file mode 100644
 index 000..9f60e17
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/input/regulator-haptic.txt
 @@ -0,0 +1,24 @@
 +* Requlator Haptic Device Tree Bindings
 +
 +The regulator haptic driver controlled by voltage of regulator.
 +This driver implemented via Force Feedback interface.
 +
 +Required Properties:
 + - compatible : Should be regulator-haptic
 + - haptic-supply : Power supply for the haptic motor.
 +   [*] refer Documentation/devicetree/bindings/regulator/regulator.txt
 +
 + - max-microvolt : The maximum voltage value supplied to haptic motor.
 +   [The unit of the voltage is a micro]
 +
 + - min-microvolt : The minimum voltage value in which haptic motor reacts.
 +   [The unit of the voltage is a micro]
 +
 +Example:
 +
 +   regulator-haptic {

Should this be more about the function and not the driver name?
Somehting like

haptics {

 +   compatible = regulator-haptic;
 +   haptic-supply = motor_regulator;
 +   max-microvolt = 270;
 +   min-microvolt = 110;
 +   };
 diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
 index 23297ab..e5e556d 100644
 --- a/drivers/input/misc/Kconfig
 +++ b/drivers/input/misc/Kconfig
 @@ -394,6 +394,17 @@ config INPUT_CM109
   To compile this driver as a module, choose M here: the module will 
 be
   called cm109.

 +config INPUT_REGULATOR_HAPTIC
 +   tristate regulator haptics support
 +   select INPUT_FF_MEMLESS
 +   help
 + This option enables device driver support for the haptic controlled
 + by regulator. This driver supports ff-memless interface
 + from input framework.
 +
 + To compile this driver as a module, choose M here: the
 + module will be called regulator-haptic.
 +
  config INPUT_RETU_PWRBUTTON
 tristate Retu Power button Driver
 depends on MFD_RETU
 diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
 index 19c7603..1f135af 100644
 --- a/drivers/input/misc/Makefile
 +++ b/drivers/input/misc/Makefile
 @@ -53,6 +53,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY)   += pmic8xxx-pwrkey.o
  obj-$(CONFIG_INPUT_POWERMATE)  += powermate.o
  obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
  obj-$(CONFIG_INPUT_RB532_BUTTON)   += rb532_button.o
 +obj-$(CONFIG_INPUT_REGULATOR_HAPTIC)   += regulator-haptic.o
  obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o
  obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER)+= rotary_encoder.o
  obj-$(CONFIG_INPUT_SGI_BTNS)   += sgi_btns.o
 diff --git a/drivers/input/misc/regulator-haptic.c 
 b/drivers/input/misc/regulator-haptic.c
 new file mode 100644
 index 000..1a83ecb
 --- /dev/null
 +++ b/drivers/input/misc/regulator-haptic.c
 @@ -0,0 +1,241 @@
 +/*
 + * Regulator haptic driver
 + *
 + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
 + * Author: Jaewon Kim jaewon02@samsung.com
 + * Author: Hyunhee Kim hyunhee@samsung.com
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +
 +#include linux/module.h
 +#include linux/platform_device.h
 +#include linux/input.h
 +#include linux/slab.h
 +#include linux/regulator/consumer.h
 +#include linux/of.h
 +
 +#define MAX_MAGNITUDE_SHIFT16
 +
 +struct regulator_haptic {
 +   struct device *dev;
 +   struct input_dev *input_dev;
 +   struct regulator *regulator;
 +   struct work_struct work;
 +
 +   bool enabled;
 +   bool suspend_state;

I don't understand what you are tracking here.  You only set it and unset
this value but never do any checking

 +   unsigned int max_volt;
 +   unsigned int min_volt;
 +   unsigned int intensity;
 +   unsigned int magnitude;
 +};
 +
 +static void 

[PATCH 4/4] ARM: EXYNOS: cpuidle: allow driver usage on Exynos3250 SoC

2014-11-20 Thread Bartlomiej Zolnierkiewicz
Register cpuidle platform device on Exynos3250 SoC allowing EXYNOS
cpuidle driver usage on this SoC.

Cc: Daniel Lezcano daniel.lezc...@linaro.org
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/mach-exynos/exynos.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 847cd0a..6efdbbe 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -297,6 +297,7 @@ static void __init exynos_dt_machine_init(void)
of_machine_is_compatible(samsung,exynos4212) ||
(of_machine_is_compatible(samsung,exynos4412) 
 of_machine_is_compatible(samsung,trats2)) ||
+   of_machine_is_compatible(samsung,exynos3250) ||
of_machine_is_compatible(samsung,exynos5250))
platform_device_register(exynos_cpuidle);
 
-- 
1.8.2.3

--
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 3/4] ARM: EXYNOS: cpuidle: add AFTR mode support for Exynos3250

2014-11-20 Thread Bartlomiej Zolnierkiewicz
Cc: Daniel Lezcano daniel.lezc...@linaro.org
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/mach-exynos/firmware.c |  8 +++-
 arch/arm/mach-exynos/pm.c   | 12 +++-
 arch/arm/mach-exynos/regs-pmu.h |  1 +
 arch/arm/mach-exynos/smc.h  |  9 +
 4 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c
index 766f57d..4ceea16 100644
--- a/arch/arm/mach-exynos/firmware.c
+++ b/arch/arm/mach-exynos/firmware.c
@@ -47,7 +47,13 @@ static int exynos_do_idle(unsigned long mode)
__raw_writel(virt_to_phys(exynos_cpu_resume_ns),
 sysram_ns_base_addr + 0x24);
__raw_writel(EXYNOS_AFTR_MAGIC, sysram_ns_base_addr + 0x20);
-   exynos_smc(SMC_CMD_CPU0AFTR, 0, 0, 0);
+   if (soc_is_exynos3250()) {
+   exynos_smc(SMC_CMD_SAVE, OP_TYPE_CORE,
+  SMC_POWERSTATE_IDLE, 0);
+   exynos_smc(SMC_CMD_SHUTDOWN, OP_TYPE_CLUSTER,
+  SMC_POWERSTATE_IDLE, 0);
+   } else
+   exynos_smc(SMC_CMD_CPU0AFTR, 0, 0, 0);
break;
case FW_DO_IDLE_SLEEP:
exynos_smc(SMC_CMD_SLEEP, 0, 0, 0);
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 86f3ecd8..2dec90f 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -130,6 +130,8 @@ int exynos_pm_central_resume(void)
 static void exynos_set_wakeupmask(long mask)
 {
pmu_raw_writel(mask, S5P_WAKEUP_MASK);
+   if (soc_is_exynos3250())
+   pmu_raw_writel(0x0, S5P_WAKEUP_MASK2);
 }
 
 static void exynos_cpu_set_boot_vector(long flags)
@@ -143,7 +145,7 @@ static int exynos_aftr_finisher(unsigned long flags)
 {
int ret;
 
-   exynos_set_wakeupmask(0xff3e);
+   exynos_set_wakeupmask(soc_is_exynos3250() ? 0x40003ffe : 0xff3e);
/* Set value of power down register for aftr mode */
exynos_sys_powerdown_conf(SYS_AFTR);
 
@@ -160,8 +162,13 @@ static int exynos_aftr_finisher(unsigned long flags)
 
 void exynos_enter_aftr(void)
 {
+   unsigned int cpuid = smp_processor_id();
+
cpu_pm_enter();
 
+   if (soc_is_exynos3250())
+   exynos_set_boot_flag(cpuid, C2_STATE);
+
exynos_pm_central_suspend();
 
cpu_suspend(0, exynos_aftr_finisher);
@@ -174,5 +181,8 @@ void exynos_enter_aftr(void)
 
exynos_pm_central_resume();
 
+   if (soc_is_exynos3250())
+   exynos_clear_boot_flag(cpuid, C2_STATE);
+
cpu_pm_exit();
 }
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index 77defeb..b095cce 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -43,6 +43,7 @@
 #define S5P_WAKEUP_STAT0x0600
 #define S5P_EINT_WAKEUP_MASK   0x0604
 #define S5P_WAKEUP_MASK0x0608
+#define S5P_WAKEUP_MASK2   0x0614
 
 #define S5P_INFORM00x0800
 #define S5P_INFORM10x0804
diff --git a/arch/arm/mach-exynos/smc.h b/arch/arm/mach-exynos/smc.h
index f7b82f9..27a976d 100644
--- a/arch/arm/mach-exynos/smc.h
+++ b/arch/arm/mach-exynos/smc.h
@@ -17,6 +17,8 @@
 #define SMC_CMD_SLEEP  (-3)
 #define SMC_CMD_CPU1BOOT   (-4)
 #define SMC_CMD_CPU0AFTR   (-5)
+#define SMC_CMD_SAVE   (-6)
+#define SMC_CMD_SHUTDOWN   (-7)
 /* For CP15 Access */
 #define SMC_CMD_C15RESUME  (-11)
 /* For L2 Cache Access */
@@ -32,4 +34,11 @@ extern void exynos_smc(u32 cmd, u32 arg1, u32 arg2, u32 
arg3);
 
 #endif /* __ASSEMBLY__ */
 
+/* op type for SMC_CMD_SAVE and SMC_CMD_SHUTDOWN */
+#define OP_TYPE_CORE0x0
+#define OP_TYPE_CLUSTER 0x1
+
+/* Power State required for SMC_CMD_SAVE and SMC_CMD_SHUTDOWN */
+#define SMC_POWERSTATE_IDLE 0x1
+
 #endif
-- 
1.8.2.3

--
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/4] ARM: EXYNOS: fix CPU1 hotplug for AFTR mode on Exynos3250

2014-11-20 Thread Bartlomiej Zolnierkiewicz
CPU1 hotplug may hang when AFTR is used.  Fix it by:
- setting AUTOWAKEUP_EN bit in ARM_COREx_CONFIGURATION register in
  exynos_cpu_power_up()
- not clearing reserved bits of ARM_COREx_CONFIGURATION register in
  exynos_cpu_power_down()
- waiting while an undocumented register 0x0908 becomes non-zero in
  exynos_core_restart()

Cc: Daniel Lezcano daniel.lezc...@linaro.org
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/mach-exynos/platsmp.c  | 19 +--
 arch/arm/mach-exynos/regs-pmu.h |  1 +
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 7a1ebfe..9f9d7cd 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -126,6 +126,8 @@ static inline void platform_do_lowpower(unsigned int cpu, 
int *spurious)
  */
 void exynos_cpu_power_down(int cpu)
 {
+   u32 core_conf;
+
if (cpu == 0  (of_machine_is_compatible(samsung,exynos5420) ||
of_machine_is_compatible(samsung,exynos5800))) {
/*
@@ -138,7 +140,10 @@ void exynos_cpu_power_down(int cpu)
if (!(val  S5P_CORE_LOCAL_PWR_EN))
return;
}
-   pmu_raw_writel(0, EXYNOS_ARM_CORE_CONFIGURATION(cpu));
+
+   core_conf = pmu_raw_readl(EXYNOS_ARM_CORE_CONFIGURATION(cpu));
+   core_conf = ~S5P_CORE_LOCAL_PWR_EN;
+   pmu_raw_writel(core_conf, EXYNOS_ARM_CORE_CONFIGURATION(cpu));
 }
 
 /**
@@ -149,7 +154,12 @@ void exynos_cpu_power_down(int cpu)
  */
 void exynos_cpu_power_up(int cpu)
 {
-   pmu_raw_writel(S5P_CORE_LOCAL_PWR_EN,
+   u32 core_conf = S5P_CORE_LOCAL_PWR_EN;
+
+   if (soc_is_exynos3250())
+   core_conf |= S5P_CORE_AUTOWAKEUP_EN;
+
+   pmu_raw_writel(core_conf,
EXYNOS_ARM_CORE_CONFIGURATION(cpu));
 }
 
@@ -227,6 +237,11 @@ static void exynos_core_restart(u32 core_id)
if (!of_machine_is_compatible(samsung,exynos3250))
return;
 
+   /* 0x0908 is an undocumented register */
+   while (!pmu_raw_readl(0x0908))
+   udelay(10);
+   udelay(10);
+
val = pmu_raw_readl(EXYNOS_ARM_CORE_STATUS(core_id));
val |= S5P_CORE_WAKEUP_FROM_LOCAL_CFG;
pmu_raw_writel(val, EXYNOS_ARM_CORE_STATUS(core_id));
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index b5f4406..77defeb 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -180,6 +180,7 @@
 
 #define S5P_CORE_LOCAL_PWR_EN  0x3
 #define S5P_CORE_WAKEUP_FROM_LOCAL_CFG (0x3  8)
+#define S5P_CORE_AUTOWAKEUP_EN (1  31)
 
 /* Only for EXYNOS4210 */
 #define S5P_CMU_CLKSTOP_LCD1_LOWPWR0x1154
-- 
1.8.2.3

--
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/4] ARM: EXYNOS: add code for setting/clearing boot flag

2014-11-20 Thread Bartlomiej Zolnierkiewicz
This code is needed for cpuidle (W-)AFTR mode support on Exynos3250.

Cc: Daniel Lezcano daniel.lezc...@linaro.org
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/mach-exynos/common.h |  6 ++
 arch/arm/mach-exynos/exynos.c | 25 +
 2 files changed, 31 insertions(+)

diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 431be1b..155f019 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -119,6 +119,12 @@ extern void __iomem *sysram_base_addr;
 extern void __iomem *pmu_base_addr;
 void exynos_sysram_init(void);
 
+/* CPU BOOT mode flag */
+#define C2_STATE   (1  3)
+
+void exynos_set_boot_flag(unsigned int cpu, unsigned int mode);
+void exynos_clear_boot_flag(unsigned int cpu, unsigned int mode);
+
 enum {
FW_DO_IDLE_SLEEP,
FW_DO_IDLE_AFTR,
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 8f638ad..847cd0a 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -148,6 +148,31 @@ static void __init exynos_init_late(void)
exynos_pm_init();
 }
 
+#define REG_CPU_STATE_ADDR (sysram_ns_base_addr + 0x28)
+#define BOOT_MODE_MASK 0x1f
+
+void exynos_set_boot_flag(unsigned int cpu, unsigned int mode)
+{
+   unsigned int tmp;
+
+   tmp = __raw_readl(REG_CPU_STATE_ADDR + cpu * 4);
+
+   if (mode  BOOT_MODE_MASK)
+   tmp = ~BOOT_MODE_MASK;
+
+   tmp |= mode;
+   __raw_writel(tmp, REG_CPU_STATE_ADDR + cpu * 4);
+}
+
+void exynos_clear_boot_flag(unsigned int cpu, unsigned int mode)
+{
+   unsigned int tmp;
+
+   tmp = __raw_readl(REG_CPU_STATE_ADDR + cpu * 4);
+   tmp = ~mode;
+   __raw_writel(tmp, REG_CPU_STATE_ADDR + cpu * 4);
+}
+
 static int __init exynos_fdt_map_chipid(unsigned long node, const char *uname,
int depth, void *data)
 {
-- 
1.8.2.3

--
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 0/4] ARM: EXYNOS: cpuidle: add AFTR mode support for Exynos3250

2014-11-20 Thread Bartlomiej Zolnierkiewicz
Hi,

This patch series adds support for AFTR idle mode on boards with
Exynos3250 SoC and allows EXYNOS cpuidle driver usage on these
boards.

It has been tested on Samsung Rinato board (Gear 2).

Depends on:
- for-next branch of linux-samsung.git kernel tree
  (or next-20141114 branch of linux-next kernel tree)
- [PATCH v5] ARM: EXYNOS: add Exynos3250 PMU support
  (https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg39109.html)

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics


Bartlomiej Zolnierkiewicz (4):
  ARM: EXYNOS: fix CPU1 hotplug for AFTR mode on Exynos3250
  ARM: EXYNOS: add code for setting/clearing boot flag
  ARM: EXYNOS: cpuidle: add AFTR mode support for Exynos3250
  ARM: EXYNOS: cpuidle: allow driver usage on Exynos3250 SoC

 arch/arm/mach-exynos/common.h   |  6 ++
 arch/arm/mach-exynos/exynos.c   | 26 ++
 arch/arm/mach-exynos/firmware.c |  8 +++-
 arch/arm/mach-exynos/platsmp.c  | 19 +--
 arch/arm/mach-exynos/pm.c   | 12 +++-
 arch/arm/mach-exynos/regs-pmu.h |  2 ++
 arch/arm/mach-exynos/smc.h  |  9 +
 7 files changed, 78 insertions(+), 4 deletions(-)

-- 
1.8.2.3

--
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: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

2014-11-20 Thread Javier Martinez Canillas
Hello Inki,

On 11/20/2014 04:06 PM, Inki Dae wrote:
 BTW, it would be great if exynos-drm-next is pulled in linux-next. That is
 what most people use to test integration issues so you can catch earlier any
 regression that may arise.
 
 You have to email Stephen Rothwell s...@canb.auug.org.au and point to your
 tree and branch and he will be able to add it to linux-next.
 
 Thanks for information. Actually, I received a similar email privately
 before. However, exynos-drm-next should go to drm-next first and than to
 mainline by Dave who is DRM subsystem maintainer. I think all vendor
 specific drm drivers would need to be checked by drm subsystem
 maintainer because these changes might be affect drm subsystem or other
 vendor specific drm drivers before go to mainline.


This is orthogonal to the normal upstreaming path. linux-next is an integration
tree that is created daily. So all the remote branches are merged and a git tag
published. The branch does not get rebased and history is not preserved between
two published linux-next tags.

This is just to test the integration of different subsystems to be sure that a
commit in one tree does not cause a regression in another one so issues can be
spot earlier. For example in the case of $subject, a change in the OF caused a
regression in the Exynos DRM driver.
 
 If needed, I will make a new branch, which is based on top of linux-next
 so other people can check their systems.


You don't really need another branch, git will take care of merge everything
in linux-next :)
 
 Thanks,
 Inki Dae
 

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: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

2014-11-20 Thread Paolo Pisati
On Thu, Nov 20, 2014 at 03:22:23PM +0530, Vivek Gautam wrote:

 On linux-samsung tree the only patch that's missing apart from dptx-phy 
 patches
 is the syscon patch from Pankaj Dubey:
 b784b98 mfd: syscon: Decouple syscon interface from platform devices
 
 So with below git hash, linux-samsung/for-next display works fine along with
 other devices that request PMU system controller :
 
 7bd219e drm/exynos: dp: Remove support for unused dptx-phy
 e8f21fd arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
 7099bde Revert Revert ARM: exynos_defconfig: Enable options for
 display panel support
 713a994 mfd: syscon: Decouple syscon interface from platform devices
 7552917 Revert ARM: exynos_defconfig: Enable options for display
 panel support /* This is Kukjin's for-next today */
 ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next
 26c6283 Merge branch 'v3.18-samsung-fixes' into for-next
 cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next
 98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers
 839275c ARM: exynos_defconfig: Use 16 minors per MMC block device
 0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow
 fc14f9c Linux 3.18-rc5

are you using a clean exynos_defconfig?
don't you need Javier's drm/exynos: Move platform drivers registration to
module init patch too?

kgene/for-next at:

7552917 Revert ARM: exynos_defconfig: Enable options for display panel support

plus:

5e1e068 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
36d908e drm/exynos: dp: Remove support for unused dptx-phy
624bff2 POSTED: mfd: syscon: Decouple syscon interface from syscon devices
68944e3 Revert Revert ARM: exynos_defconfig: Enable options for display panel 
support

hangs with a black screen (albeit backlight seems to be on) on boot.
I'm betting on Javier's patch at this point (i even tried disabling SND_SOC_SNOW
but that didn't help).
-- 
bye,
p.
--
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] ARM: dts: Specify default clocks for Exynos4 camera devices

2014-11-20 Thread Sylwester Nawrocki
Specify the default mux and divider clocks in device tree
to ensure the FIMC devices on Trats, Trats2, Universal_c210
and Odroid X2/U3 boards are clocked from recommended clock
source and with maximum supported frequency.
For Trats2 also the MIPI-CSIS and the camera sensor clocks
are configured, the 'clock-frequency' property is deprecated
in favour of 'assigned-clock-rates' property.

Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
---
 arch/arm/boot/dts/exynos4210-trats.dts  |   16 
 arch/arm/boot/dts/exynos4210-universal_c210.dts |   16 
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi |   16 
 arch/arm/boot/dts/exynos4412-trats2.dts |   32 ---
 4 files changed, 77 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/exynos4210-trats.dts 
b/arch/arm/boot/dts/exynos4210-trats.dts
index f516da9..7208362 100644
--- a/arch/arm/boot/dts/exynos4210-trats.dts
+++ b/arch/arm/boot/dts/exynos4210-trats.dts
@@ -431,18 +431,34 @@
 
fimc_0: fimc@1180 {
status = okay;
+   assigned-clocks = clock CLK_MOUT_FIMC0,
+   clock CLK_SCLK_FIMC0;
+   assigned-clock-parents = clock CLK_SCLK_MPLL;
+   assigned-clock-rates = 0, 16000;
};
 
fimc_1: fimc@1181 {
status = okay;
+   assigned-clocks = clock CLK_MOUT_FIMC1,
+   clock CLK_SCLK_FIMC1;
+   assigned-clock-parents = clock CLK_SCLK_MPLL;
+   assigned-clock-rates = 0, 16000;
};
 
fimc_2: fimc@1182 {
status = okay;
+   assigned-clocks = clock CLK_MOUT_FIMC2,
+   clock CLK_SCLK_FIMC2;
+   assigned-clock-parents = clock CLK_SCLK_MPLL;
+   assigned-clock-rates = 0, 16000;
};
 
fimc_3: fimc@1183 {
status = okay;
+   assigned-clocks = clock CLK_MOUT_FIMC3,
+   clock CLK_SCLK_FIMC3;
+   assigned-clock-parents = clock CLK_SCLK_MPLL;
+   assigned-clock-rates = 0, 16000;
};
};
 };
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts 
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index d50eb3a..aaf0cae 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -473,18 +473,34 @@
 
fimc_0: fimc@1180 {
status = okay;
+   assigned-clocks = clock CLK_MOUT_FIMC0,
+   clock CLK_SCLK_FIMC0;
+   assigned-clock-parents = clock CLK_SCLK_MPLL;
+   assigned-clock-rates = 0, 16000;
};
 
fimc_1: fimc@1181 {
status = okay;
+   assigned-clocks = clock CLK_MOUT_FIMC1,
+   clock CLK_SCLK_FIMC1;
+   assigned-clock-parents = clock CLK_SCLK_MPLL;
+   assigned-clock-rates = 0, 16000;
};
 
fimc_2: fimc@1182 {
status = okay;
+   assigned-clocks = clock CLK_MOUT_FIMC2,
+   clock CLK_SCLK_FIMC2;
+   assigned-clock-parents = clock CLK_SCLK_MPLL;
+   assigned-clock-rates = 0, 16000;
};
 
fimc_3: fimc@1183 {
status = okay;
+   assigned-clocks = clock CLK_MOUT_FIMC3,
+   clock CLK_SCLK_FIMC3;
+   assigned-clock-parents = clock CLK_SCLK_MPLL;
+   assigned-clock-rates = 0, 16000;
};
};
 };
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index c697ff0..adf1331 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -82,18 +82,34 @@
 
fimc_0: fimc@1180 {
status = okay;
+   assigned-clocks = clock CLK_MOUT_FIMC0,
+   clock CLK_SCLK_FIMC0;
+   assigned-clock-parents = clock CLK_MOUT_MPLL_USER_T;
+   assigned-clock-rates = 0, 17600;
};
 
fimc_1: fimc@1181 {
status = okay;
+   assigned-clocks = clock CLK_MOUT_FIMC1,
+

Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

2014-11-20 Thread Kevin Hilman
Hi Vivek,

Vivek Gautam gautamvivek1...@gmail.com writes:

[...]

 I tested linux-next on Exynos5800 peach-pi board with linux-next and and the 
 two
 patches $Subject and [0].

 Below is my git hash:
 4d9e6ee drm/exynos: Move platform drivers registration to module init
 4545ed4 POSTED: arm: dts: Exynos5: Use pmu_system_controller phandle for dp 
 phy
 36391a5 Add linux-next specific files for 20141119
 9b1ced1 Merge branch 'akpm/master'
 282497e mm: add strictlimit knob

 With this display works for me.
 Without $Subject patch i get lookup in drm.

The current linux-next (next-20141120) is still not fully booting for
me.  I do see the penguins come up on the display, but it doesn't finish
booting.   Full boot log below.

I'm building using exynos_defconfig with CONFIG_SND_SOC_SNOW=n due to
other errors previously reported.  (Vivek, BTW, I'm curious how your peach-pi
is booting with the audio support enabled.)

Here's how I'm creating the tree, which appears to be the same as what
you guys are doing, but just to be thorough:

$ git reset --hard next/master
HEAD is now at 5b83d7ad9106 Add linux-next specific files for 20141120

$ pwclient git-am 5197701
Applying patch #5197701 using 'git am'
Description: [v2,2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for 
dp phy
Applying: arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

$ pwclient git-am 5328881
Applying patch #5328881 using 'git am'
Description: [RFC,1/1] drm/exynos: Move platform drivers registration to module 
init
Applying: drm/exynos: Move platform drivers registration to module init

$ git log --oneline -n5
b16800da58a3 drm/exynos: Move platform drivers registration to module init
87541edf8a17 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
5b83d7ad9106 Add linux-next specific files for 20141120
fd7e97b09f45 Merge branch 'akpm/master'
11729160b2d7 mm: add strictlimit knob

Kevin


[1] 
Connected to chromebook2 console [channel connected] (~$quit to exit)
(user:khilman) is already connected


# PYBOOT: console: connected.
~$hardreset

Command(chromebook2 console) hardreset
(user:khilman) Reboot chromebook2
Reboot: chromebook2 ; phidget 4 2 :  ('off', 1, 'on')


U-Boot 2013.04-gb98ed09 (Apr 30 2014 - 16:57:31) for Peach

CPU:Exynos5422@1800MHz

Board: Google Peach Pi, rev 13.6
I2C:   ready
DRAM:  3.5 GiB
PMIC max77802-pmic initialized
CPU:Exynos5422@1800MHz
TPS65090 PMIC EC init
MMC:   EXYNOS DWMMC: 0, EXYNOS DWMMC: 1
SF: Detected W25Q32DW with page size 4 KiB, total 32 MiB
In:cros-ec-keyb
Out:   serial
Err:   lcd
SF: Detected W25Q32DW with page size 4 KiB, total 32 MiB
ELOG: Event(17) added with size 13
Net:   No ethernet found.
Hit any key to stop autoboot:  2 

# PYBOOT: u-boot: taking control.
 0 
Exynos DP init done
Peach # 
Peach setenv stdout serial
# setenv stdout serialversion

Peach # versionsetenv preboot usb start; sleep 1


U-Boot 2013.04-gb98ed09 (Apr 30 2014 - 16:57:31) for Peach
armv7a-cros-linux-gnueabi-gcc.real (4.7.2_cos_gg_c8f69e0) 4.7.x-google 20130114 
(prerelease)
GNU ld (binutils-2.22_cos_gg_2) 2.22
Peach # setenv preboot usb start; sleep 1setenv bootargs console=tty1 
console=ttySAC3,115200 debug earlyprintk rw root=/dev/mmcblk1p3 rootwait 
rootfstype=ext3

Peach # setenv bootargs console=tty1 console=ttySAC3,115200 debug earlyprintk 
rw root=/dev/mmcblk1p3 rootwait rootfstype=ext3if test -n ${initenv}; then run 
initenv; fi

Peach # if test -n ${initenv}; then run initenv; fiif test -n ${preboot}; then 
run preboot; fi

Peach # if test -n ${preboot}; then run preboot; fisetenv autoload no; setenv 
autoboot no

(Re)start USB...
USB0:   Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
USB1:   Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus 1 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
   scanning usb for ethernet devices... 1 Ethernet Device(s) found
Peach # dhcp
dhcp
Waiting for Ethernet connection... done.
BOOTP broadcast 1
BOOTP broadcast 2
DHCP client bound to address 192.168.1.110
Peach # setenv serverip 192.168.1.2
setenv serverip 192.168.1.2
Peach # if test -n ${netargs}; then run netargs; fi
if test -n ${netargs}; then run netargs; fi
Peach # tftp 0x4100 192.168.1.2:tmp/chromebook2-3T8ptb/uImage-48m8WK
tftp 0x4100 192.168.1.2:tmp/chromebook2-3T8ptb/uImage-48m8WK
Using asx0 device
TFTP from server 192.168.1.2; our IP address is 192.168.1.110
Filename 'tmp/chromebook2-3T8ptb/uImage-48m8WK'.
Load address: 0x4100
Loading: *#
 #
 #
 ##
 1.2 MiB/s
done
Bytes transferred = 3473930 (35020a hex)
Peach # printenv bootargs
printenv bootargs
bootargs=console=tty1 console

Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

2014-11-20 Thread Javier Martinez Canillas
Hello Paolo,

On 11/20/2014 04:57 PM, Paolo Pisati wrote:
 On Thu, Nov 20, 2014 at 03:22:23PM +0530, Vivek Gautam wrote:

 On linux-samsung tree the only patch that's missing apart from dptx-phy 
 patches
 is the syscon patch from Pankaj Dubey:
 b784b98 mfd: syscon: Decouple syscon interface from platform devices
 
 So with below git hash, linux-samsung/for-next display works fine along with
 other devices that request PMU system controller :
 
 7bd219e drm/exynos: dp: Remove support for unused dptx-phy
 e8f21fd arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
 7099bde Revert Revert ARM: exynos_defconfig: Enable options for
 display panel support
 713a994 mfd: syscon: Decouple syscon interface from platform devices
 7552917 Revert ARM: exynos_defconfig: Enable options for display
 panel support /* This is Kukjin's for-next today */
 ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next
 26c6283 Merge branch 'v3.18-samsung-fixes' into for-next
 cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next
 98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers
 839275c ARM: exynos_defconfig: Use 16 minors per MMC block device
 0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow
 fc14f9c Linux 3.18-rc5
 
 are you using a clean exynos_defconfig?
 don't you need Javier's drm/exynos: Move platform drivers registration to
 module init patch too?
 

Since Kukjin's for-next is based on Linux 3.18-rc5, the OF patch that causes
the Exynos DRM deadlock is not there. That commit landed in next20141105.

 kgene/for-next at:
 
 7552917 Revert ARM: exynos_defconfig: Enable options for display panel 
 support
 
 plus:
 
 5e1e068 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
 36d908e drm/exynos: dp: Remove support for unused dptx-phy
 624bff2 POSTED: mfd: syscon: Decouple syscon interface from syscon devices
 68944e3 Revert Revert ARM: exynos_defconfig: Enable options for display 
 panel support
 
 hangs with a black screen (albeit backlight seems to be on) on boot.
 I'm betting on Javier's patch at this point (i even tried disabling 
 SND_SOC_SNOW
 but that didn't help).
 

I only tested with next20141120 but Vivek tested with Kukjin for-next AFAIU.

What's your kernel command line and u-boot env vars?

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: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

2014-11-20 Thread Inki Dae
2014-11-21 0:26 GMT+09:00 Javier Martinez Canillas
javier.marti...@collabora.co.uk:
 Hello Inki,

 On 11/20/2014 04:06 PM, Inki Dae wrote:
 BTW, it would be great if exynos-drm-next is pulled in linux-next. That is
 what most people use to test integration issues so you can catch earlier any
 regression that may arise.

 You have to email Stephen Rothwell s...@canb.auug.org.au and point to your
 tree and branch and he will be able to add it to linux-next.

 Thanks for information. Actually, I received a similar email privately
 before. However, exynos-drm-next should go to drm-next first and than to
 mainline by Dave who is DRM subsystem maintainer. I think all vendor
 specific drm drivers would need to be checked by drm subsystem
 maintainer because these changes might be affect drm subsystem or other
 vendor specific drm drivers before go to mainline.


 This is orthogonal to the normal upstreaming path. linux-next is an 
 integration
 tree that is created daily. So all the remote branches are merged and a git 
 tag
 published. The branch does not get rebased and history is not preserved 
 between
 two published linux-next tags.

 This is just to test the integration of different subsystems to be sure that a
 commit in one tree does not cause a regression in another one so issues can be
 spot earlier. For example in the case of $subject, a change in the OF caused a
 regression in the Exynos DRM driver.

 If needed, I will make a new branch, which is based on top of linux-next
 so other people can check their systems.


 You don't really need another branch, git will take care of merge everything
 in linux-next :)

Ah, sorry. There was my misunderstanding. drm-next already is merged
to linux-next so I think we can do the integration test if
exynos-drm-next is merged to drm-next earlier. Anyway, I will try to
consider your opinion.

Thanks,
Inki Dae


 Thanks,
 Inki Dae


 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
--
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: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

2014-11-20 Thread Javier Martinez Canillas
Hello,

For completeness I'll comment what we talked with Kevin on IRC
since probably this is the same issue that Paolo is facing.

On 11/20/2014 05:41 PM, Kevin Hilman wrote:
 Peach # setenv preboot usb start; sleep 1setenv bootargs console=tty1 
 console=ttySAC3,115200 debug earlyprintk rw root=/dev/mmcblk1p3 rootwait 
 rootfstype=ext3

My kernel command line is almost the same with the difference that I'm using
clk_ignore_unused and I just checked that not passing that parameter, makes
linux-next to hang showing the same output log that Kevin reported.

Now, the question is why this does not happen with 3.18-rc+? My guess is that
the clock been disabled by the common clock framework got added recently and
it used to be unmanaged and left with the state set by the bootloader since
the kernel didn't know about it. That's why clk_ignore_unused was not needed.

Any ideas?

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 v5 1/2] clk: samsung: exynos5440: move restart code into clock driver

2014-11-20 Thread Sylwester Nawrocki
On 19/11/14 04:37, Pankaj Dubey wrote:
  
   +static int exynos5440_clk_restart_notify(struct notifier_block *this,
   +   unsigned long code, void *unused)
   +{
   +   u32 val, status;
   +
   +   status = readl_relaxed(reg_base + 0xbc);
   +   val = readl_relaxed(reg_base + 0xcc);
   +   val = (val  0x) | (status  0x);
   +   writel_relaxed(val, reg_base + 0xcc);
  
  Can we have macro definitions for these 0xcc, 0xbc address offsets ?
  I must say I couldn't find them documented in any Exynos datasheet I've
 got though.
  

 I also wished this, but I could not find them documented. 
 So I tried to keep logic of original code as it is, just changed location. 
 I would also like to mention that I have not tested this on exynos5440 as I
 do not have
 one with me. I believe if it was working at its original place in
 exynos_restart it should work
 here also. Other patch (2/2) I have verified on Exynos3250 board and its
 working well.

I think it's best to merge both patches in that series through
the arm-soc tree, since applying them not in order may cause some
breakage. Thus I'd let Kukjin take this patch set into his tree.

For both patches:
Acked-by: Sylwester Nawrocki s.nawro...@samsung.com

--
Thanks,
Sylwester
--
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: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

2014-11-20 Thread Kevin Hilman
Javier Martinez Canillas javier.marti...@collabora.co.uk writes:

 Hello,

 For completeness I'll comment what we talked with Kevin on IRC
 since probably this is the same issue that Paolo is facing.

 On 11/20/2014 05:41 PM, Kevin Hilman wrote:
 Peach # setenv preboot usb start; sleep 1setenv bootargs
 console=tty1 console=ttySAC3,115200 debug earlyprintk rw
 root=/dev/mmcblk1p3 rootwait rootfstype=ext3

 My kernel command line is almost the same with the difference that I'm using
 clk_ignore_unused and I just checked that not passing that parameter, makes
 linux-next to hang showing the same output log that Kevin reported.

Ah!  Good find.  I confirm that adding clk_ignore_unused is getting me
booting again, but of course that is just masking a problem, so I hope
someone can shed light on which clock isn't being correctly managed.

Might I also suggest that folks have their default command-line to *not*
use clk_ignore_unused, since it's primary job is to workaround clock
bugs.

Kevin
--
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 1/2] usb: dwc2/gadget: add mutex to serialize init/deinit calls

2014-11-20 Thread Felipe Balbi
On Fri, Oct 31, 2014 at 11:12:33AM +0100, Marek Szyprowski wrote:
 This patch adds mutex, which protects initialization and
 deinitialization procedures against suspend/resume methods.
 
 Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com

doesn't apply either:

checking file drivers/usb/dwc2/core.h
Hunk #1 FAILED at 187.
1 out of 1 hunk FAILED
checking file drivers/usb/dwc2/gadget.c
Hunk #2 succeeded at 2863 (offset -46 lines).
Hunk #3 succeeded at 2889 (offset -46 lines).
Hunk #4 succeeded at 2915 (offset -47 lines).
Hunk #5 succeeded at 2934 (offset -47 lines).
Hunk #6 succeeded at 2964 (offset -47 lines).
Hunk #7 succeeded at 2976 (offset -47 lines).
Hunk #8 FAILED at 3518.
Hunk #9 succeeded at 3579 (offset -84 lines).
Hunk #10 succeeded at 3603 with fuzz 1 (offset -84 lines).
Hunk #11 succeeded at 3614 (offset -84 lines).
Hunk #12 succeeded at 3632 with fuzz 1 (offset -84 lines).
1 out of 12 hunks FAILED

please rebase on testing/next. Also, add Paul's Ack when doing so ;-)

thanks

-- 
balbi


signature.asc
Description: Digital signature


Re: [PATCH v5] usb: dwc2/gadget: rework disconnect event handling

2014-11-20 Thread Felipe Balbi
On Mon, Nov 17, 2014 at 09:59:42AM +0100, Marek Szyprowski wrote:
 This patch adds a call to s3c_hsotg_disconnect() from 'end session'
 interrupt (GOTGINT_SES_END_DET) to correctly notify gadget subsystem
 about unplugged usb cable. DISCONNINT interrupt cannot be used for this
 purpose, because it is asserted only in host mode.
 
 To avoid reporting disconnect event more than once, a disconnect call has
 been moved from USB_REQ_SET_ADDRESS handling function to SESSREQINT
 interrupt. This way driver ensures that disconnect event is reported
 either when usb cable is unplugged or every time the host starts a new
 session. To handle devices which has been synthesized without
 SRP support, connected state is set in ENUMDONE interrupt.
 
 Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com

doesn't apply, please rebase on my testing/next:

checking file drivers/usb/dwc2/core.h
Hunk #1 FAILED at 210.
1 out of 1 hunk FAILED
checking file drivers/usb/dwc2/gadget.c
Hunk #1 FAILED at 1029.
Hunk #2 succeeded at 1108 (offset 1 line).
Hunk #3 succeeded at 2031 (offset 1 line).
Hunk #4 FAILED at 2293.
2 out of 4 hunks FAILED

thanks

-- 
balbi


signature.asc
Description: Digital signature


Re: [PATCH] PM / Domains: Power on the PM domain right after attach completes

2014-11-20 Thread Rafael J. Wysocki
On Thursday, November 20, 2014 11:13:01 AM Ulf Hansson wrote:
 On 20 November 2014 01:35, Rafael J. Wysocki r...@rjwysocki.net wrote:
  On Wednesday, November 19, 2014 09:54:00 AM Ulf Hansson wrote:
  [...]
 
  
   Scenario 5), a platform driver with/without runtime PM callbacks.
   -probe()
   - do some initialization
   - may fetch handles to runtime PM resources
   - pm_runtime_enable()
  
   Well, and now how the driver knows if the device is on before 
   accessing it?
 
  In this case the driver don't need to access the device during
  -probe(). That's postponed until sometime later.
 
  If this is a platform driver, it rather does need to access the device,
  precisely because it doesn't know what power state the device is in 
  otherwise.
  See below.
 
   Note 1)
   Scenario 1) and 2), both relies on the approach to power on the PM
   domain by using pm_runtime_get_sync(). That approach didn't work when
   CONFIG_PM_RUNTIME was unset, but we recently decided to fixed that by
   the below patch, so that's good!
   [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd 
   enabled
  
   Note 2)
   Scenario 3) and 4) use the same principles for managing runtime PM.
   These scenarios needs a way to power on the generic PM domain prior
   probing the device. The call to pm_runtime_set_active(), prevents an
   already powered PM domain from power off until after probe, but that's
   not enough.
  
   Note 3)
   The $subject patch, tried to address the issues for scenario 3) and
   4). It does so, but will affect scenario 5) which was working nicely
   before. In scenario 5), the $subject patch will cause the generic PM
   domain to potentially stay powered after -probe() even if the device
   is runtime PM suspended.
  
   Why would it?  If the device is runtime-suspended, the domain will know
   that, because its callbacks will be used for that.  At least, that's
   what I'd expect to happen, so is there a problem here?
 
  Genpd do knows about the device but it doesn’t get a notification to
  power off. There are no issues whatsoever for driver.
 
  Except that the driver is arguably buggy.
 
  This is a somewhat special case. Let's go through an example.
 
  1. The PM domain is initially in powered off state.
  2. The bus -probe() invokes dev_pm_domain_attach() and then the PM
  domain gets attached to the device.
  3. $subject patch causes the PM domain to power on.
  4. A driver -probe() sequence start, following the Scenario 5).
  5. The device is initially in runtime PM suspended state and it will
  remain so during -probe().
 
  But is it physically suspended?
 
  The runtime PM status of the device after -probe is required to reflect its
  real state if runtime PM is enabled.  If that's not the case, it is a bug.
 
 Agree.
 
 While I was searching for drivers that behave as in scenario 5), they
 tend to register some subsystem specific callbacks and don't access
 the device until some of those callbacks are invoked.
 
 At least that was my interpretation of their -probe() methods, but
 it's not always easy to tell how those callbacks are being used for
 each subsystem.
 
 
  Now, for platform drivers, the driver can't really assume anything in
  particular about the current power state of the device at -probe time,
  because different platforms including devices handled by that driver may
  behave differently.
 
  A good example would be two platforms A and B where the same device X is in 
  a
  power domain such that A boots with the domain (physically) on, while B 
  boots
  with the domain off.  If the driver for X assumes anything about the 
  initial
  power state of the device, it may not work on either A or B.
 
 I get your point and agree!
 
 
  6. The pm_request_idle() invoked after really_probe() in driver core,
  won't trigger a runtime PM suspend callback to be invoked. In other
  words, genpd don't get a notification that it may power off.
 
  In this state, genpd will either power off from the late_initcall,
  genpd_poweroff_unused() (depending on when the driver was probed) or
  wait until some device's runtime PM suspend callback is invoked at any
  later point.
 
  Which sounds OK to me, so why is it a problem?
 
 The late_initcall doesn't work for modules.
 
 Also, suppose the PM domain only holds this inactive device that was
 probed as in scenario 5). Then, you could end up having the PM domain
 powered, even if it isn't needed.
 
 Anyway, I can live with this. It's likely the driver that behave as in
 scenario 5) that should be fixed as you stated.
 
 
   I see three options going forward.
  
   Option 1)
   Convert scenario 3) and 4) into using the pm_runtime_get_sync()
   approach. There are no theoretical obstacles to do this, but pure
   practical. There are a lot of drivers that needs to be converted and
   we also need to teach driver authors future wise to not use
   pm_runtime_set_active() in this manner.
  
   I'd say we need to do something like this 

Re: [PATCH 1/2] drm/exynos: fix null pointer dereference issue

2014-11-20 Thread Gustavo Padovan
2014-11-13 Inki Dae inki@samsung.com:

 This patch fixes null pointer dereference issue incurred
 when ipp driver is enabled and Exynos drm driver is closed.
 
 Non kms driver should register its own sub driver to setup necessary
 resources, which is done by load(). So null pointer dereference
 occurs when ipp driver is enabled and Exynos drm driver is closed
 because ipp core device is registered after component_master_add_with_match
 call.
 
 This patch makes exynos_drm_device_subdrv_probe() to be called after all non
 kms drivers are registered.

This patch is breaking exynos initialization, exynos_drm_device_subdrv_probe()
needs the drvdata but it is still NULL at this point which make the whole
exynos init fails. The drvdata is only set in exynos_drm_load() so we need
call exynos_drm_device_subdrv_probe() after that.

Do you have the crash output for this? What is the issue you are fixing?
Usually you should add this kind of information to you commit message, it
helps us understand what you are fixing, specially in cases when a regression
is introduced, like this patch for example

Gustavo
--
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] Revert drm/exynos: fix null pointer dereference issue

2014-11-20 Thread Gustavo Padovan
From: Gustavo Padovan gustavo.pado...@collabora.co.uk

This reverts commit cea24824ab432f8acabb254d6805e9aa756de6af.

Moving subdriver probe to exynos_drm_platform_probe() was making
exynos_drm_device_subdrv_probe() fail because the platform data wasn't set
yet. It only gets set in exynos_drm_load.

We need to find a smarter way to fix this issue.

Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index b94c9d1..91891cf 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -108,6 +108,11 @@ static int exynos_drm_load(struct drm_device *dev, 
unsigned long flags)
if (ret)
goto err_unbind_all;
 
+   /* Probe non kms sub drivers and virtual display driver. */
+   ret = exynos_drm_device_subdrv_probe(dev);
+   if (ret)
+   goto err_cleanup_vblank;
+
/*
 * enable drm irq mode.
 * - with irq_enabled = true, we can use the vblank feature.
@@ -133,6 +138,8 @@ static int exynos_drm_load(struct drm_device *dev, unsigned 
long flags)
 
return 0;
 
+err_cleanup_vblank:
+   drm_vblank_cleanup(dev);
 err_unbind_all:
component_unbind_all(dev-dev, dev);
 err_mode_config_cleanup:
@@ -146,6 +153,8 @@ err_free_private:
 
 static int exynos_drm_unload(struct drm_device *dev)
 {
+   exynos_drm_device_subdrv_remove(dev);
+
exynos_drm_fbdev_fini(dev);
drm_kms_helper_poll_fini(dev);
 
@@ -608,14 +617,8 @@ static int exynos_drm_platform_probe(struct 
platform_device *pdev)
if (ret  0)
goto err_unregister_non_kms_drivers;
 
-   /* Probe non kms sub drivers and virtual display driver. */
-   ret = exynos_drm_device_subdrv_probe(platform_get_drvdata(pdev));
-   if (ret)
-   goto err_unregister_resources;
-
return ret;
 
-err_unregister_resources:
 #ifdef CONFIG_DRM_EXYNOS_IPP
exynos_platform_device_ipp_unregister();
 #endif
@@ -637,8 +640,6 @@ static int exynos_drm_platform_remove(struct 
platform_device *pdev)
 {
int i;
 
-   exynos_drm_device_subdrv_remove(platform_get_drvdata(pdev));
-
 #ifdef CONFIG_DRM_EXYNOS_IPP
exynos_platform_device_ipp_unregister();
 #endif
-- 
1.9.3

--
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] drm/exynos: revert fixes for the infinite loop issue

2014-11-20 Thread Gustavo Padovan
From: Gustavo Padovan gustavo.pado...@collabora.co.uk

This reverts commit 06a2f5c2c4e0cb4ff38ca3769ae1f81cc2d030cf and
f7c2f36f4395f12d8ecb25c28ee88ec87b457089.

These two patches were trying to fix an issue that was causing an
infinite loop at the load of the exynos-drm but they were not tackling the
source of the problem.

A new patch that move the platform driver registration exynos_drm_init()
follows this revert and fix the issue properly.

Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 18 --
 1 file changed, 18 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index eab12f0..b94c9d1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -484,12 +484,6 @@ static struct component_match *exynos_drm_match_add(struct 
device *dev)
 
mutex_lock(drm_component_lock);
 
-   /* Do not retry to probe if there is no any kms driver regitered. */
-   if (list_empty(drm_component_list)) {
-   mutex_unlock(drm_component_lock);
-   return ERR_PTR(-ENODEV);
-   }
-
list_for_each_entry(cdev, drm_component_list, list) {
/*
 * Add components to master only in case that crtc and
@@ -674,18 +668,6 @@ static int exynos_drm_init(void)
 {
int ret;
 
-   /*
-* Register device object only in case of Exynos SoC.
-*
-* Below codes resolves temporarily infinite loop issue incurred
-* by Exynos drm driver when using multi-platform kernel.
-* So these codes will be replaced with more generic way later.
-*/
-   if (!of_machine_is_compatible(samsung,exynos3) 
-   !of_machine_is_compatible(samsung,exynos4) 
-   !of_machine_is_compatible(samsung,exynos5))
-   return -ENODEV;
-
exynos_drm_pdev = platform_device_register_simple(exynos-drm, -1,
NULL, 0);
if (IS_ERR(exynos_drm_pdev))
-- 
1.9.3

--
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 3/3] drm/exynos: move Exynos platform drivers registration to init

2014-11-20 Thread Gustavo Padovan
From: Gustavo Padovan gustavo.pado...@collabora.co.uk

Registering the Exynos DRM subdevices platform drivers in the probe
function is causing an infinite loop. Fix this by moving it to the
exynos_drm_init() function to register the drivers on module init.

Registering drivers in the probe functions causes a deadlock in the parent
device lock. See Grant Likely explanation on the topic:

I think the problem is that exynos_drm_init() is registering a normal
(non-OF) platform device, so the parent will be /sys/devices/platform.
It immediately gets bound against exynos_drm_platform_driver which
calls the exynos drm_platform_probe() hook. The driver core obtains
device_lock() on the device *and on the device parent*.

Inside the probe hook, additional platform_drivers get registered.
Each time one does, it tries to bind against every platform device in
the system, which includes the ones created by OF. When it attempts to
bind, it obtains device_lock() on the device *and on the device
parent*.

Before the change to move of-generated platform devices into
/sys/devices/platform, the devices had different parents. Now both
devices have /sys/devices/platform as the parent, so yes they are
going to deadlock.

The real problem is registering drivers from within a probe hook. That
is completely wrong for the above deadlock reason. __driver_attach()
will deadlock. Those registrations must be pulled out of .probe().

Registering devices in .probe() is okay because __device_attach()
doesn't try to obtain device_lock() on the parent.

 INFO: task swapper/0:1 blocked for more than 120 seconds.
   Not tainted 3.18.0-rc3-next-20141105 #794
 echo 0  /proc/sys/kernel/hung_task_timeout_secs disables this message.
 swapper/0   D c052534c 0 1  0 0x
 [c052534c] (__schedule) from [c0525b34] 
(schedule_preempt_disabled+0x14/0x20)
 [c0525b34] (schedule_preempt_disabled) from [c0526d44] 
(mutex_lock_nested+0x1c4/0x464

 [c0526d44] (mutex_lock_nested) from [c02be908] (__driver_attach+0x48/0x98)
 [c02be908] (__driver_attach) from [c02bcc00] (bus_for_each_dev+0x54/0x88)
 [c02bcc00] (bus_for_each_dev) from [c02bdce0] (bus_add_driver+0xe4/0x200)
 [c02bdce0] (bus_add_driver) from [c02bef94] (driver_register+0x78/0xf4)
 [c02bef94] (driver_register) from [c029e99c] 
(exynos_drm_platform_probe+0x34/0x234)
 [c029e99c] (exynos_drm_platform_probe) from [c02bfcf0] 
(platform_drv_probe+0x48/0xa4)
 [c02bfcf0] (platform_drv_probe) from [c02be680] 
(driver_probe_device+0x13c/0x37c)
 [c02be680] (driver_probe_device) from [c02be954] 
(__driver_attach+0x94/0x98)
 [c02be954] (__driver_attach) from [c02bcc00] (bus_for_each_dev+0x54/0x88)
 [c02bcc00] (bus_for_each_dev) from [c02bdce0] (bus_add_driver+0xe4/0x200)
 [c02bdce0] (bus_add_driver) from [c02bef94] (driver_register+0x78/0xf4)
 [c02bef94] (driver_register) from [c029e938] (exynos_drm_init+0x70/0xa0)
 [c029e938] (exynos_drm_init) from [c00089b0] (do_one_initcall+0xac/0x1f0)
 [c00089b0] (do_one_initcall) from [c074bd90] 
(kernel_init_freeable+0x10c/0x1d8)
 [c074bd90] (kernel_init_freeable) from [c051eabc] (kernel_init+0x8/0xec)
 [c051eabc] (kernel_init) from [c000f268] (ret_from_fork+0x14/0x2c)
 3 locks held by swapper/0/1:
  #0:  (dev-mutex){..}, at: [c02be908] __driver_attach+0x48/0x98
  #1:  (dev-mutex){..}, at: [c02be918] __driver_attach+0x58/0x98
  #2:  (dev-mutex){..}, at: [c02be908] __driver_attach+0x48/0x98

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 124 +++-
 1 file changed, 59 insertions(+), 65 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 91891cf..cb3ed9b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -548,6 +548,38 @@ static const struct component_master_ops exynos_drm_ops = {
.unbind = exynos_drm_unbind,
 };
 
+static int exynos_drm_platform_probe(struct platform_device *pdev)
+{
+   struct component_match *match;
+
+   pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+   exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);
+
+   match = exynos_drm_match_add(pdev-dev);
+   if (IS_ERR(match)) {
+   return PTR_ERR(match);
+   }
+
+   return component_master_add_with_match(pdev-dev, exynos_drm_ops,
+  match);
+}
+
+static int exynos_drm_platform_remove(struct platform_device *pdev)
+{
+   component_master_del(pdev-dev, exynos_drm_ops);
+   return 0;
+}
+
+static struct platform_driver exynos_drm_platform_driver = {
+   .probe  = exynos_drm_platform_probe,
+   .remove = exynos_drm_platform_remove,
+   .driver = {
+   .owner  = THIS_MODULE,
+   .name   = exynos-drm,
+   .pm = exynos_drm_pm_ops,
+   },

[PATCH 0/3] drm/exynos: Fix exynos-drm initialization

2014-11-20 Thread Gustavo Padovan
From: Gustavo Padovan gustavo.pado...@collabora.co.uk

These patches were tested both in drm-exynos-next and linux-next (with
drm-exynos-next merged in) and it solves the infinite loop and parent device
lock deadlock. It was tested with Ajay's DP patches applied. A tree based on
drm-exynos-next can be found here:

https://git.kernel.org/cgit/linux/kernel/git/padovan/drm-exynos.git/log/?h=dp-integ

The first patch reverts the other tries to fix this problem.

The second patch is a revert and fixes a regression with the subdriver probe
function getting a NULL drvdata and thus failing drm_exynos_init()

The third patch is a port to drm-exynos-next of Javier patches that moves the
platform driver registration to init.

Gustavo Padovan (3):
  drm/exynos: revert fixes for the infinite loop issue
  Revert drm/exynos: fix null pointer dereference issue
  drm/exynos: move Exynos platform drivers registration to init

 drivers/gpu/drm/exynos/exynos_drm_drv.c | 159 ++--
 1 file changed, 68 insertions(+), 91 deletions(-)

-- 
1.9.3

--
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: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init

2014-11-20 Thread Paolo Pisati
On Thu, Nov 20, 2014 at 10:22:54AM -0800, Kevin Hilman wrote:
 Javier Martinez Canillas javier.marti...@collabora.co.uk writes:
 
  Hello,
 
  For completeness I'll comment what we talked with Kevin on IRC
  since probably this is the same issue that Paolo is facing.
 
  On 11/20/2014 05:41 PM, Kevin Hilman wrote:
  Peach # setenv preboot usb start; sleep 1setenv bootargs
  console=tty1 console=ttySAC3,115200 debug earlyprintk rw
  root=/dev/mmcblk1p3 rootwait rootfstype=ext3
 
  My kernel command line is almost the same with the difference that I'm using
  clk_ignore_unused and I just checked that not passing that parameter, makes
  linux-next to hang showing the same output log that Kevin reported.
 
 Ah!  Good find.  I confirm that adding clk_ignore_unused is getting me
 booting again, but of course that is just masking a problem, so I hope
 someone can shed light on which clock isn't being correctly managed.
 
 Might I also suggest that folks have their default command-line to *not*
 use clk_ignore_unused, since it's primary job is to workaround clock
 bugs.

i'm testing kgene/for-next (not linux-next), with:

flag@peachpi:~/linux$ cat /proc/cmdline
console=tty1 console=ttySAC3,115200 debug earlyprintk rw rootwait
root=/dev/mmcblk1p3

adding clk_ignore_unused didn't make any difference: it hangs on boot
showing a black screen with backlight on.

vanilla kgene/for-next as of today:

7552917 Revert ARM: exynos_defconfig: Enable options for display panel support
ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next
26c6283 Merge branch 'v3.18-samsung-fixes' into for-next
cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next
98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers
839275c ARM: exynos_defconfig: Use 16 minors per MMC block device
0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow
fc14f9c Linux 3.18-rc5
...

plus

5e1e068 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy
36d908e drm/exynos: dp: Remove support for unused dptx-phy
624bff2 POSTED: mfd: syscon: Decouple syscon interface from syscon devices
68944e3 Revert Revert ARM: exynos_defconfig: Enable options for display panel
support

vanilla exynos_defconfig with SND_SOC_SNOW disabled.

I should probably try linux-next at this point, but i wonder if people who
reported kgene/for-next working were testing with a vanilla exynos_defconfig on
a peach pi.
-- 
bye,
p.
--
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 3/3] drm/exynos: avoid leak if exynos_dpi_probe() fails

2014-11-20 Thread Gustavo Padovan
From: Gustavo Padovan gustavo.pado...@collabora.co.uk

The component must be deleted if the probe fails.

Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 0673a39..173d135 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -1202,8 +1202,10 @@ static int fimd_probe(struct platform_device *pdev)
fimd_manager.ctx = ctx;
 
ctx-display = exynos_dpi_probe(dev);
-   if (IS_ERR(ctx-display))
-   return PTR_ERR(ctx-display);
+   if (IS_ERR(ctx-display)) {
+   ret = PTR_ERR(ctx-display);
+   goto err_del_component;
+   }
 
pm_runtime_enable(pdev-dev);
 
-- 
1.9.3

--
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] drm/exynos: avoid race condition when adding a drm component

2014-11-20 Thread Gustavo Padovan
From: Gustavo Padovan gustavo.pado...@collabora.co.uk

exynos_drm_component_add() correctly checks if a component is present on
drm_component_list however it release the lock right after the check
and before we add the new component to the list. That just creates room
to add the same component more than once to the list.

The lock should be held for the whole journey while adding a new
component.

Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index cb3ed9b..230573d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -402,10 +402,8 @@ int exynos_drm_component_add(struct device *dev,
 * added already just return.
 */
if (cdev-dev_type_flag == (EXYNOS_DEVICE_TYPE_CRTC |
-   EXYNOS_DEVICE_TYPE_CONNECTOR)) {
-   mutex_unlock(drm_component_lock);
-   return 0;
-   }
+   EXYNOS_DEVICE_TYPE_CONNECTOR))
+   goto unlock;
 
if (dev_type == EXYNOS_DEVICE_TYPE_CRTC) {
cdev-crtc_dev = dev;
@@ -417,14 +415,11 @@ int exynos_drm_component_add(struct device *dev,
cdev-dev_type_flag |= dev_type;
}
 
-   mutex_unlock(drm_component_lock);
-   return 0;
+   goto unlock;
}
}
 
-   mutex_unlock(drm_component_lock);
-
-   cdev = kzalloc(sizeof(*cdev), GFP_KERNEL);
+   cdev = kzalloc(sizeof(*cdev), GFP_ATOMIC);
if (!cdev)
return -ENOMEM;
 
@@ -436,10 +431,9 @@ int exynos_drm_component_add(struct device *dev,
cdev-out_type = out_type;
cdev-dev_type_flag = dev_type;
 
-   mutex_lock(drm_component_lock);
list_add_tail(cdev-list, drm_component_list);
+unlock:
mutex_unlock(drm_component_lock);
-
return 0;
 }
 
-- 
1.9.3

--
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] drm/exynos: free DP if probe fails to find a panel or bridge

2014-11-20 Thread Gustavo Padovan
From: Gustavo Padovan gustavo.pado...@collabora.co.uk

DP was leaked everytime function returns EPROBE_DEFER, free it before
returning.

Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
 drivers/gpu/drm/exynos/exynos_dp_core.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 85762cf..6fd4a46 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1336,8 +1336,10 @@ static int exynos_dp_probe(struct platform_device *pdev)
if (panel_node) {
dp-panel = of_drm_find_panel(panel_node);
of_node_put(panel_node);
-   if (!dp-panel)
-   return -EPROBE_DEFER;
+   if (!dp-panel) {
+   ret = -EPROBE_DEFER;
+   goto free_dp;
+   }
}
 
endpoint = of_graph_get_next_endpoint(dev-of_node, NULL);
@@ -1346,10 +1348,14 @@ static int exynos_dp_probe(struct platform_device *pdev)
if (bridge_node) {
dp-bridge = of_drm_find_bridge(bridge_node);
of_node_put(bridge_node);
-   if (!dp-bridge)
-   return -EPROBE_DEFER;
-   } else
-   return -EPROBE_DEFER;
+   if (!dp-bridge) {
+   ret = -EPROBE_DEFER;
+   goto free_dp;
+   }
+   } else {
+   ret = -EPROBE_DEFER;
+   goto free_dp;
+   }
}
 
exynos_dp_display.ctx = dp;
@@ -1359,6 +1365,9 @@ static int exynos_dp_probe(struct platform_device *pdev)
exynos_drm_component_del(pdev-dev,
EXYNOS_DEVICE_TYPE_CONNECTOR);
 
+free_dp:
+   devm_kfree(dev, dp);
+
return ret;
 }
 
-- 
1.9.3

--
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 1/2] Input: add regulator haptic driver

2014-11-20 Thread Jaewon Kim

Hi Pankaj,

2014년 11월 20일 23:33에 Pankaj Dubey 이(가) 쓴 글:

Hi Jaewon,

On 20 November 2014 19:01, Jaewon Kim jaewon02@samsung.com wrote:

This patch adds support for haptic driver controlled by
voltage of regulator. And this driver support for
Force Feedback interface from input framework

Signed-off-by: Jaewon Kim jaewon02@samsung.com
Signed-off-by: Hyunhee Kim hyunhee@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
  .../devicetree/bindings/input/regulator-haptic.txt |   24 ++
  drivers/input/misc/Kconfig |   11 +
  drivers/input/misc/Makefile|1 +
  drivers/input/misc/regulator-haptic.c  |  241 
  4 files changed, 277 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/input/regulator-haptic.txt
  create mode 100644 drivers/input/misc/regulator-haptic.c

diff --git a/Documentation/devicetree/bindings/input/regulator-haptic.txt 
b/Documentation/devicetree/bindings/input/regulator-haptic.txt
new file mode 100644
index 000..9f60e17
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/regulator-haptic.txt
@@ -0,0 +1,24 @@
+* Requlator Haptic Device Tree Bindings
+
+The regulator haptic driver controlled by voltage of regulator.
+This driver implemented via Force Feedback interface.
+
+Required Properties:
+ - compatible : Should be regulator-haptic
+ - haptic-supply : Power supply for the haptic motor.
+   [*] refer Documentation/devicetree/bindings/regulator/regulator.txt
+
+ - max-microvolt : The maximum voltage value supplied to haptic motor.
+   [The unit of the voltage is a micro]
+
+ - min-microvolt : The minimum voltage value in which haptic motor reacts.
+   [The unit of the voltage is a micro]
+
+Example:
+
+   regulator-haptic {
+   compatible = regulator-haptic;
+   haptic-supply = motor_regulator;
+   max-microvolt = 270;
+   min-microvolt = 110;
+   };
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 23297ab..e5e556d 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -394,6 +394,17 @@ config INPUT_CM109
   To compile this driver as a module, choose M here: the module will be
   called cm109.

+config INPUT_REGULATOR_HAPTIC
+   tristate regulator haptics support
+   select INPUT_FF_MEMLESS
+   help
+ This option enables device driver support for the haptic controlled
+ by regulator. This driver supports ff-memless interface
+ from input framework.
+
+ To compile this driver as a module, choose M here: the
+ module will be called regulator-haptic.
+
  config INPUT_RETU_PWRBUTTON
 tristate Retu Power button Driver
 depends on MFD_RETU
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 19c7603..1f135af 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY)   += pmic8xxx-pwrkey.o
  obj-$(CONFIG_INPUT_POWERMATE)  += powermate.o
  obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
  obj-$(CONFIG_INPUT_RB532_BUTTON)   += rb532_button.o
+obj-$(CONFIG_INPUT_REGULATOR_HAPTIC)   += regulator-haptic.o
  obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o
  obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER)+= rotary_encoder.o
  obj-$(CONFIG_INPUT_SGI_BTNS)   += sgi_btns.o
diff --git a/drivers/input/misc/regulator-haptic.c 
b/drivers/input/misc/regulator-haptic.c
new file mode 100644
index 000..1a83ecb
--- /dev/null
+++ b/drivers/input/misc/regulator-haptic.c
@@ -0,0 +1,241 @@
+/*
+ * Regulator haptic driver
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Jaewon Kim jaewon02@samsung.com
+ * Author: Hyunhee Kim hyunhee@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/input.h
+#include linux/slab.h
+#include linux/regulator/consumer.h
+#include linux/of.h
+
+#define MAX_MAGNITUDE_SHIFT16
+
+struct regulator_haptic {
+   struct device *dev;
+   struct input_dev *input_dev;
+   struct regulator *regulator;
+   struct work_struct work;
+
+   bool enabled;
+   bool suspend_state;
+   unsigned int max_volt;
+   unsigned int min_volt;
+   unsigned int intensity;
+   unsigned int magnitude;
+};
+
+static void regulator_haptic_enable(struct regulator_haptic *haptic)
+{
+   int error;
+
+   if (haptic-enabled)
+   return;
+
+   error = regulator_enable(haptic-regulator);
+   if (error) {
+   dev_err(haptic-dev, cannot enable regulator\n);
+   return;
+   }
+
+   

Re: [PATCH 1/2] Input: add regulator haptic driver

2014-11-20 Thread Jaewon Kim

Hi Dan,

2014년 11월 21일 00:09에 Dan Murphy 이(가) 쓴 글:

Hi

On 11/20/2014 08:33 AM, Pankaj Dubey wrote:

Hi Jaewon,

On 20 November 2014 19:01, Jaewon Kim jaewon02@samsung.com wrote:

This patch adds support for haptic driver controlled by
voltage of regulator. And this driver support for
Force Feedback interface from input framework

Signed-off-by: Jaewon Kim jaewon02@samsung.com
Signed-off-by: Hyunhee Kim hyunhee@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
  .../devicetree/bindings/input/regulator-haptic.txt |   24 ++
  drivers/input/misc/Kconfig |   11 +
  drivers/input/misc/Makefile|1 +
  drivers/input/misc/regulator-haptic.c  |  241 
  4 files changed, 277 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/input/regulator-haptic.txt
  create mode 100644 drivers/input/misc/regulator-haptic.c

diff --git a/Documentation/devicetree/bindings/input/regulator-haptic.txt 
b/Documentation/devicetree/bindings/input/regulator-haptic.txt
new file mode 100644
index 000..9f60e17
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/regulator-haptic.txt
@@ -0,0 +1,24 @@
+* Requlator Haptic Device Tree Bindings
+
+The regulator haptic driver controlled by voltage of regulator.
+This driver implemented via Force Feedback interface.
+
+Required Properties:
+ - compatible : Should be regulator-haptic
+ - haptic-supply : Power supply for the haptic motor.
+   [*] refer Documentation/devicetree/bindings/regulator/regulator.txt
+
+ - max-microvolt : The maximum voltage value supplied to haptic motor.
+   [The unit of the voltage is a micro]
+
+ - min-microvolt : The minimum voltage value in which haptic motor reacts.
+   [The unit of the voltage is a micro]
+
+Example:
+
+   regulator-haptic {

Should this be more about the function and not the driver name?
Somehting like

haptics {

Yes, haptics is better than driver name.




+   compatible = regulator-haptic;
+   haptic-supply = motor_regulator;
+   max-microvolt = 270;
+   min-microvolt = 110;
+   };
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 23297ab..e5e556d 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -394,6 +394,17 @@ config INPUT_CM109
   To compile this driver as a module, choose M here: the module will be
   called cm109.

+config INPUT_REGULATOR_HAPTIC
+   tristate regulator haptics support
+   select INPUT_FF_MEMLESS
+   help
+ This option enables device driver support for the haptic controlled
+ by regulator. This driver supports ff-memless interface
+ from input framework.
+
+ To compile this driver as a module, choose M here: the
+ module will be called regulator-haptic.
+
  config INPUT_RETU_PWRBUTTON
 tristate Retu Power button Driver
 depends on MFD_RETU
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 19c7603..1f135af 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY)   += pmic8xxx-pwrkey.o
  obj-$(CONFIG_INPUT_POWERMATE)  += powermate.o
  obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
  obj-$(CONFIG_INPUT_RB532_BUTTON)   += rb532_button.o
+obj-$(CONFIG_INPUT_REGULATOR_HAPTIC)   += regulator-haptic.o
  obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o
  obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER)+= rotary_encoder.o
  obj-$(CONFIG_INPUT_SGI_BTNS)   += sgi_btns.o
diff --git a/drivers/input/misc/regulator-haptic.c 
b/drivers/input/misc/regulator-haptic.c
new file mode 100644
index 000..1a83ecb
--- /dev/null
+++ b/drivers/input/misc/regulator-haptic.c
@@ -0,0 +1,241 @@
+/*
+ * Regulator haptic driver
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Jaewon Kim jaewon02@samsung.com
+ * Author: Hyunhee Kim hyunhee@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/input.h
+#include linux/slab.h
+#include linux/regulator/consumer.h
+#include linux/of.h
+
+#define MAX_MAGNITUDE_SHIFT16
+
+struct regulator_haptic {
+   struct device *dev;
+   struct input_dev *input_dev;
+   struct regulator *regulator;
+   struct work_struct work;
+
+   bool enabled;
+   bool suspend_state;

I don't understand what you are tracking here.  You only set it and unset
this value but never do any checking


+   unsigned int max_volt;
+   unsigned int min_volt;
+   unsigned int intensity;
+   unsigned int magnitude;
+};
+
+static void 

Re: [PATCH 1/2] drm/exynos: fix null pointer dereference issue

2014-11-20 Thread Inki Dae
On 2014년 11월 21일 08:12, Gustavo Padovan wrote:
 2014-11-13 Inki Dae inki@samsung.com:
 
 This patch fixes null pointer dereference issue incurred
 when ipp driver is enabled and Exynos drm driver is closed.

 Non kms driver should register its own sub driver to setup necessary
 resources, which is done by load(). So null pointer dereference
 occurs when ipp driver is enabled and Exynos drm driver is closed
 because ipp core device is registered after component_master_add_with_match
 call.

 This patch makes exynos_drm_device_subdrv_probe() to be called after all non
 kms drivers are registered.
 
 This patch is breaking exynos initialization, exynos_drm_device_subdrv_probe()
 needs the drvdata but it is still NULL at this point which make the whole
 exynos init fails. The drvdata is only set in exynos_drm_load() so we need
 call exynos_drm_device_subdrv_probe() after that.

There might be my missing point but with this patch,
exynos_drm_device_subdrv_probe() will be called after exynos_drm_load()
call because all kms drivers are probed before
component_master_add_with_match call so exynos_drm_load() must be called
by component_master_add_with_match function before
exynos_drm_device_subdrv_probe call.

So could you show me the error messages you faced with? There might be a
corner case I missed.

 
 Do you have the crash output for this? What is the issue you are fixing?

Ok, below is the error messages,
# modetest
[5.653291] [ cut here ]
[5.656469] WARNING: CPU: 2 PID: 1404 at kernel/locking/mutex.c:511
__mutex_lock_slowpath+0x3d4/0x3d8()
[5.665816] DEBUG_LOCKS_WARN_ON(l-magic != l)
[5.670069] Modules linked in:
[5.673286] CPU: 2 PID: 1404 Comm: modetest Not tainted
3.18.0-rc3-146775-gbcfef97 #1149
[5.681389] [c0014400] (unwind_backtrace) from [c0011570]
(show_stack+0x10/0x14)
[5.689090] [c0011570] (show_stack) from [c0474060]
(dump_stack+0x84/0xc4)
[5.696304] [c0474060] (dump_stack) from [c0021918]
(warn_slowpath_common+0x6c/0x88)
[5.704364] [c0021918] (warn_slowpath_common) from [c0021964]
(warn_slowpath_fmt+0x30/0x40)
[5.713047] [c0021964] (warn_slowpath_fmt) from [c0477a4c]
(__mutex_lock_slowpath+0x3d4/0x3d8)
[5.721984] [c0477a4c] (__mutex_lock_slowpath) from [c0477a5c]
(mutex_lock+0xc/0x24)
[5.730069] [c0477a5c] (mutex_lock) from [c028e6fc]
(ipp_subdrv_close+0x4c/0x13c)
[5.737881] [c028e6fc] (ipp_subdrv_close) from [c027a51c]
(exynos_drm_subdrv_close+0x3c/0x4c)
[5.746731] [c027a51c] (exynos_drm_subdrv_close) from [c025eadc]
(drm_release+0x94/0x4c8)
[5.755228] [c025eadc] (drm_release) from [c00cbdd4]
(__fput+0x80/0x1c8)
[5.762268] [c00cbdd4] (__fput) from [c0037840]
(task_work_run+0xac/0xe4)
[5.769382] [c0037840] (task_work_run) from [c00110f8]
(do_work_pending+0x94/0xb4)
[5.777275] [c00110f8] (do_work_pending) from [c000e6e0]
(work_pending+0xc/0x20)
[5.784994] ---[ end trace bb48a41ae89d1f25 ]---
[5.789598] Unable to handle kernel NULL pointer dereference at
virtual address 
[5.797664] pgd = ee3b8000
[5.800354] [] *pgd=6e366831, *pte=, *ppte=
[5.806610] Internal error: Oops: 817 [#1] PREEMPT SMP ARM
[5.812074] Modules linked in:
[5.815117] CPU: 2 PID: 1404 Comm: modetest Tainted: GW
3.18.0-rc3-146775-gbcfef97 #1149
[5.824314] task: eea90800 ti: ee33c000 task.ti: ee33c000
[5.829704] PC is at __mutex_lock_slowpath+0xf4/0x3d8
[5.834730] LR is at __mutex_lock_slowpath+0xdc/0x3d8
[5.839765] pc : [c047776c]lr : [c0477754]psr: 8093
[5.839765] sp : ee33de88  ip : ee33de98  fp : c06cb814
[5.851220] r10: ee0f5854  r9 : c0700784  r8 : eea90800
[5.856429] r7 : ee33c008  r6 : 6013  r5 : ee0f5844  r4 : ee0f5840
[5.862938] r3 :   r2 :   r1 : ee33de88  r0 : ee0f5840
[5.869451] Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
Segment user
[5.876654] Control: 10c5387d  Table: 6e3b804a  DAC: 0015
[5.882383] Process modetest (pid: 1404, stack limit = 0xee33c240)
[5.888544] Stack: (0xee33de88 to 0xee33e000)
[5.892888] de80:   ee0f5854  
ee33de88 0001d030 ee0f5840
[5.901048] dea0: c06b1d94 ee0f5810 c0705e4c ee0eeb00 
ee0f5840 ee0f5810 c0477a5c
[5.909207] dec0: eeb4a510 c028e6fc ee14a434 eeb4a510 c06b2fe4
ee14a400 ee33c000 eeb4a510
[5.917366] dee0: c06b1d94 ee0eeb00 ee14a400 ee14a434 0008
ee0eea08  c027a51c
[5.925525] df00: c0705e4c ee0eeb00 ee0eea00 ee14a400 ee14a434
c025eadc ee0eea08 0001
[5.933684] df20: eebce000    0021
ee0eea00 ee3354e0 
[5.941843] df40: ee32a250 ee711428 0008 ee0eea08 
c00cbdd4  
[5.950002] df60: eea90b4c  c06ca604 eea90800 c000e824
ee33c000  c0037840
[5.958161] df80: ee33c018 c000e824 ee33dfb0 ee33c000 c000e824
c00110f8 0003 0001
[5.966320] dfa0: beff0a4c 0006 

Re: [PATCH v5 2/2] ARM: EXYNOS: PMU: move restart code into pmu driver

2014-11-20 Thread Vivek Gautam
Hi Pankaj,


On Tue, Nov 18, 2014 at 4:17 PM, Pankaj Dubey pankaj.du...@samsung.com wrote:
 Let's register restart handler from PMU driver for restart
 functionality. So that we can remove restart hooks from
 machine specific file, and thus moving ahead when PMU moved
 to driver folder, this functionality can be reused for ARM64
 based Exynos SoC's.

 Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
 Acked-by: Guenter Roeck li...@roeck-us.net
 ---

Tested on Exynos5800 peach-pi board with linux-samsung/for-next.
Reboot works as expected mutiple times.

Tested-by: Vivek Gautam gautam.vi...@samsung.com

  arch/arm/mach-exynos/common.h |1 -
  arch/arm/mach-exynos/exynos.c |6 --
  arch/arm/mach-exynos/pmu.c|   23 +++
  3 files changed, 23 insertions(+), 7 deletions(-)

 diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
 index 431be1b..865f878 100644
 --- a/arch/arm/mach-exynos/common.h
 +++ b/arch/arm/mach-exynos/common.h
 @@ -12,7 +12,6 @@
  #ifndef __ARCH_ARM_MACH_EXYNOS_COMMON_H
  #define __ARCH_ARM_MACH_EXYNOS_COMMON_H

 -#include linux/reboot.h
  #include linux/of.h

  #define EXYNOS3250_SOC_ID  0xE3472000
 diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
 index 8f995b7..c13d083 100644
 --- a/arch/arm/mach-exynos/exynos.c
 +++ b/arch/arm/mach-exynos/exynos.c
 @@ -87,11 +87,6 @@ static struct map_desc exynos5_iodesc[] __initdata = {
 },
  };

 -static void exynos_restart(enum reboot_mode mode, const char *cmd)
 -{
 -   __raw_writel(0x1, pmu_base_addr + EXYNOS_SWRESET);
 -}
 -
  static struct platform_device exynos_cpuidle = {
 .name  = exynos_cpuidle,
  #ifdef CONFIG_ARM_EXYNOS_CPUIDLE
 @@ -316,7 +311,6 @@ DT_MACHINE_START(EXYNOS_DT, SAMSUNG EXYNOS (Flattened 
 Device Tree))
 .init_machine   = exynos_dt_machine_init,
 .init_late  = exynos_init_late,
 .dt_compat  = exynos_dt_compat,
 -   .restart= exynos_restart,
 .reserve= exynos_reserve,
 .dt_fixup   = exynos_dt_fixup,
  MACHINE_END
 diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c
 index 6c8a76d..e4c3512 100644
 --- a/arch/arm/mach-exynos/pmu.c
 +++ b/arch/arm/mach-exynos/pmu.c
 @@ -11,8 +11,11 @@

  #include linux/io.h
  #include linux/of.h
 +#include linux/of_address.h
  #include linux/platform_device.h
  #include linux/delay.h
 +#include linux/notifier.h
 +#include linux/reboot.h


  #include exynos-pmu.h
 @@ -716,6 +719,13 @@ static void exynos5420_pmu_init(void)
 pr_info(EXYNOS5420 PMU initialized\n);
  }

 +static int pmu_restart_notify(struct notifier_block *this,
 +   unsigned long code, void *unused)
 +{
 +   pmu_raw_writel(0x1, EXYNOS_SWRESET);
 +
 +   return NOTIFY_DONE;
 +}

  static const struct exynos_pmu_data exynos4210_pmu_data = {
 .pmu_config = exynos4210_pmu_config,
 @@ -765,11 +775,20 @@ static const struct of_device_id 
 exynos_pmu_of_device_ids[] = {
 { /*sentinel*/ },
  };

 +/*
 + * Exynos PMU restart notifier, handles restart functionality
 + */
 +static struct notifier_block pmu_restart_handler = {
 +   .notifier_call = pmu_restart_notify,
 +   .priority = 128,
 +};
 +
  static int exynos_pmu_probe(struct platform_device *pdev)
  {
 const struct of_device_id *match;
 struct device *dev = pdev-dev;
 struct resource *res;
 +   int ret;

 res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 pmu_base_addr = devm_ioremap_resource(dev, res);
 @@ -794,6 +813,10 @@ static int exynos_pmu_probe(struct platform_device *pdev)

 platform_set_drvdata(pdev, pmu_context);

 +   ret = register_restart_handler(pmu_restart_handler);
 +   if (ret)
 +   dev_warn(dev, can't register restart handler err=%d\n, ret);
 +
 dev_dbg(dev, Exynos PMU Driver probe done\n);
 return 0;
  }
 --
 1.7.9.5

 --
 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



-- 
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
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 2/5] drivers: soc: Add support for Exynos PMU driver

2014-11-20 Thread amit daniel kachhap
On Thu, Nov 20, 2014 at 3:33 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Thu, Nov 20, 2014 at 11:09:25AM +0530, Amit Daniel Kachhap wrote:
 diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
 index 063113d..44d220d 100644
 --- a/drivers/soc/Makefile
 +++ b/drivers/soc/Makefile
 @@ -6,3 +6,4 @@ obj-$(CONFIG_ARCH_QCOM)   += qcom/
  obj-$(CONFIG_ARCH_TEGRA) += tegra/
  obj-$(CONFIG_SOC_TI) += ti/
  obj-$(CONFIG_PLAT_VERSATILE) += versatile/
 +obj-$(CONFIG_ARCH_EXYNOS)+= samsung/

 Is ARCH_EXYNOS appropriate here, or is your new SOC_SAMSUNG better?
yes, SOC_SAMSUNG is more appropriate.

 diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
 new file mode 100644
 index 000..a424ebc
 --- /dev/null
 +++ b/drivers/soc/samsung/Kconfig
 @@ -0,0 +1,20 @@
 +#
 +# SAMSUNG SOC drivers
 +#
 +menuconfig SOC_SAMSUNG
 + bool Samsung SOC drivers support

 If you intend to select SOC_SAMSUNG, is there any point in making this
 a user-visible symbol?
Agreed, only menu Samsung SOC drivers support will be fine.

Regards,
Amit

 --
 FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
 according to speedtest.net.

 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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] spi: s3c64xx: add support for exynos7 SPI controller

2014-11-20 Thread Padma Venkat
Hi Mark,

 CS can also be controlled automatically by setting AUTO_N_MANUAL to 1
 in CS_CFG. When it is auto CS automatically toggles between packet to
 packet. NCS_TIME_COUNT in CS_CFG controls the inactive period. The
 driver by default uses manual mode. But on exynos7 the manual mode is
 removed.

 OK, but what's a packet here?

 Packet is either 1 byte or 4 bytes size depends on width of the SPI
 channel.


 I tested the driver with wm5110 codec.

 Did you try firmware downloads or something else that generates multiple
 transfers in a message?  Normal register writes will use a single
 transfer so I'd expect them to just work.


 OK. I don't have provision to test on this board. I will try to test
 on older boards by disabling manual mode.


 I tested on exynos5420 peach-pit by enabling auto mode. I used dd
 command to read 1MB data from spi flash and I compared the result with
 manual mode. Both are same.

I also tested this patch with Javier Martinez Canillas patches for
enabling spidev nodes from
http://www.spinics.net/lists/linux-samsung-soc/msg39057.html.

I read 4MB flashdata from spi by enabling auto mode and compared the
result. They look same.


 Thanks
 padma


--
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 v4 1/2] i2c: s3c2410: Handle i2c sys_cfg register in i2c driver

2014-11-20 Thread Wolfram Sang
On Thu, Oct 30, 2014 at 01:34:29PM +0530, Pankaj Dubey wrote:
 Let's handle i2c interrupt re-configuration in i2c driver. This will
 help us in removing some soc specific checks from machine files and
 will help in removing static iomapping of SYS register in exynos.c
 
 Since only Exynos5250, and Exynos5420 has i2c nodes in DT, added syscon
 based phandle to i2c device nodes of respective SoC DT files.
 
 Also handle saving and restoring of SYS_I2C_CFG register during
 suspend and resume of i2c driver.
 
 CC: Rob Herring robh...@kernel.org
 CC: Randy Dunlap rdun...@infradead.org
 CC: Wolfram Sang w...@the-dreams.de
 CC: Russell King li...@arm.linux.org.uk
 CC: devicet...@vger.kernel.org
 CC: linux-...@vger.kernel.org
 CC: linux-...@vger.kernel.org
 Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
 ---
  .../devicetree/bindings/i2c/i2c-s3c2410.txt|1 +
  arch/arm/boot/dts/exynos5250.dtsi  |4 +++
  arch/arm/boot/dts/exynos5420.dtsi  |4 +++

I usually don't take DTS patches. They should go via arm-soc. Please say
so if there are reasons I should take them.

 @@ -1084,6 +1092,23 @@ s3c24xx_i2c_parse_dt(struct device_node *np, struct 
 s3c24xx_i2c *i2c)
   of_property_read_u32(np, samsung,i2c-slave-addr, pdata-slave_addr);
   of_property_read_u32(np, samsung,i2c-max-bus-freq,
   (u32 *)pdata-frequency);
 + /*
 +  * Exynos5's legacy i2c controller and new high speed i2c
 +  * controller have muxed interrupt sources. By default the
 +  * interrupts for 4-channel HS-I2C controller are enabled.
 +  * If node for first four channels of legacy i2c controller

s/node/nodes/

 +  * are available then re-configure the interrupts via the
 +  * system register.
 +  */
 + id = of_alias_get_id(np, i2c);
 + i2c-sysreg = syscon_regmap_lookup_by_phandle(np,
 + samsung,sysreg-phandle);
 + if (IS_ERR(i2c-sysreg)) {
 + /* As this is not compulsory do not return error */
 + pr_info(i2c-%d skipping re-configuration of interrutps\n, id);

I'd say drop this message. If you want to keep it, it should be dev_dbg.

 + return;
 + }
 + regmap_update_bits(i2c-sysreg, EXYNOS5_SYS_I2C_CFG, BIT(id), 0);
  }

Rest looks good, thanks!


signature.asc
Description: Digital signature