Re: [PATCH -v2] drm/exynos: track vblank events on a per crtc basis

[Daniel Stone]

Hi,

On 30 January 2015 at 14:30, Gustavo Padovan gust...@padovan.org wrote:
 2015-01-30 Joonyoung Shim jy0922.s...@samsung.com:
 We will lose unfinished prior events by this change. That's why we use
 linked list.

 I think you are right, but I was using exynos_crtc-event to do exactly the
 same as exynos_crtc-pending_flip. So we were losing a event in
 exynos_drm_crtc_dpms() before too. I change this patch to have a page_flip
 list on the crtc.

The usual approach in other drivers is to return -EBUSY when there is
already an async pageflip pending. This definitely makes sense to me,
as I don't see the point of submitting pageflips faster than the
hardware can actually render, and pretending to the application that
they were actually shown.

Cheers,
Daniel
--
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] drm/exynos: track vblank events on a per crtc basis

[Daniel Vetter]

On Fri, Jan 30, 2015 at 03:57:53PM +, Daniel Stone wrote:
 Hi,
 
 On 30 January 2015 at 14:30, Gustavo Padovan gust...@padovan.org wrote:
  2015-01-30 Joonyoung Shim jy0922.s...@samsung.com:
  We will lose unfinished prior events by this change. That's why we use
  linked list.
 
  I think you are right, but I was using exynos_crtc-event to do exactly the
  same as exynos_crtc-pending_flip. So we were losing a event in
  exynos_drm_crtc_dpms() before too. I change this patch to have a page_flip
  list on the crtc.
 
 The usual approach in other drivers is to return -EBUSY when there is
 already an async pageflip pending. This definitely makes sense to me,
 as I don't see the point of submitting pageflips faster than the
 hardware can actually render, and pretending to the application that
 they were actually shown.

Yes, right now drm doesn't really support anything like a pageflip queue.
Same for atomic really. Even the async pageflip mode works like it, it
just ends up flipping faster.

Long-term we want a flip queue where subsequent flips can be folded
together on the next vblank. That makes benchmark-mode games happy,
without resulting in tearing like async flips and still resulting in the
lowest possible latency (since the kernel we just commit the flips for
which all the buffers are ready and not stall).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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] drm/exynos: track vblank events on a per crtc basis

[Gustavo Padovan]

2015-01-30 Daniel Vetter dan...@ffwll.ch:

 On Fri, Jan 30, 2015 at 03:57:53PM +, Daniel Stone wrote:
  Hi,
  
  On 30 January 2015 at 14:30, Gustavo Padovan gust...@padovan.org wrote:
   2015-01-30 Joonyoung Shim jy0922.s...@samsung.com:
   We will lose unfinished prior events by this change. That's why we use
   linked list.
  
   I think you are right, but I was using exynos_crtc-event to do exactly 
   the
   same as exynos_crtc-pending_flip. So we were losing a event in
   exynos_drm_crtc_dpms() before too. I change this patch to have a page_flip
   list on the crtc.
  
  The usual approach in other drivers is to return -EBUSY when there is
  already an async pageflip pending. This definitely makes sense to me,
  as I don't see the point of submitting pageflips faster than the
  hardware can actually render, and pretending to the application that
  they were actually shown.
 
 Yes, right now drm doesn't really support anything like a pageflip queue.
 Same for atomic really. Even the async pageflip mode works like it, it
 just ends up flipping faster.
 
 Long-term we want a flip queue where subsequent flips can be folded
 together on the next vblank. That makes benchmark-mode games happy,
 without resulting in tearing like async flips and still resulting in the
 lowest possible latency (since the kernel we just commit the flips for
 which all the buffers are ready and not stall).

Yeah, that makes sense. I'll just add a check for -EBUSY and send a v2.

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

Re: [PATCH 03/14] drm/bridge: make bridge registration independent of drm flow

[Rob Clark]

On Tue, Jan 20, 2015 at 11:38 AM, Ajay Kumar ajaykumar...@samsung.com wrote:
 Currently, third party bridge drivers(ptn3460) are dependent
 on the corresponding encoder driver init, since bridge driver
 needs a drm_device pointer to finish drm initializations.
 The encoder driver passes the drm_device pointer to the
 bridge driver. Because of this dependency, third party drivers
 like ptn3460 doesn't adhere to the driver model.

 In this patch, we reframe the bridge registration framework
 so that bridge initialization is split into 2 steps, and
 bridge registration happens independent of drm flow:
 --Step 1: gather all the bridge settings independent of drm and
   add the bridge onto a global list of bridges.
 --Step 2: when the encoder driver is probed, call drm_bridge_attach
   for the corresponding bridge so that the bridge receives
   drm_device pointer and continues with connector and other
   drm initializations.

 The old set of bridge helpers are removed, and a set of new helpers
 are added to accomplish the 2 step initialization.

 The bridge devices register themselves onto global list of bridges
 when they get probed by calling drm_bridge_add.

 The parent encoder driver waits till the bridge is available
 in the lookup table(by calling of_drm_find_bridge) and then
 continues with its initialization.

 The encoder driver should also call drm_bridge_attach to pass
 on the drm_device to the bridge object.

 drm_bridge_attach inturn calls bridge-funcs-attach so that
 bridge can continue with drm related initializations.

ok, so I probably should have had a closer look at this before it
landed in drm-next, so if it is too late to revert (and deal w/
untangling subsequent patches that depend on this) some of these
issues we'll just have to fix with follow-on patches.

1) needs headerdoc for new fxns in drm_bridge.c, and needs to be added
in drm.tmpl
2) as far as I can tell, the new approach to cleaning up bridge
objects is to just let them leak !?!

I'll also need to update the new bridge in the msm edp code..
although that isn't such a big deal if I knew how this was *supposed*
to work.. since what is there now at least doesn't look right..

BR,
-R



 Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
 Acked-by: Inki Dae inki@samsung.com
 Tested-by: Rahul Sharma rahul.sha...@samsung.com
 Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Tested-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
 Tested-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
 ---
  drivers/gpu/drm/Makefile   |2 +-
  drivers/gpu/drm/bridge/ptn3460.c   |   27 +-
  drivers/gpu/drm/drm_bridge.c   |   91 
 
  drivers/gpu/drm/drm_crtc.c |   67 ---
  drivers/gpu/drm/msm/hdmi/hdmi.c|4 +-
  drivers/gpu/drm/msm/hdmi/hdmi.h|1 +
  drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |6 +--
  drivers/gpu/drm/sti/sti_hda.c  |   10 +---
  drivers/gpu/drm/sti/sti_hdmi.c |   10 +---
  include/drm/bridge/ptn3460.h   |8 +++
  include/drm/drm_crtc.h |   26 -
  11 files changed, 133 insertions(+), 119 deletions(-)
  create mode 100644 drivers/gpu/drm/drm_bridge.c

 diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
 index e620807..c83ef2d 100644
 --- a/drivers/gpu/drm/Makefile
 +++ b/drivers/gpu/drm/Makefile
 @@ -14,7 +14,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
 drm_info.o drm_debugfs.o drm_encoder_slave.o \
 drm_trace_points.o drm_global.o drm_prime.o \
 drm_rect.o drm_vma_manager.o drm_flip_work.o \
 -   drm_modeset_lock.o drm_atomic.o
 +   drm_modeset_lock.o drm_atomic.o drm_bridge.o

  drm-$(CONFIG_COMPAT) += drm_ioc32.o
  drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
 diff --git a/drivers/gpu/drm/bridge/ptn3460.c 
 b/drivers/gpu/drm/bridge/ptn3460.c
 index a2ddc8d..4a818c1 100644
 --- a/drivers/gpu/drm/bridge/ptn3460.c
 +++ b/drivers/gpu/drm/bridge/ptn3460.c
 @@ -176,24 +176,11 @@ static void ptn3460_post_disable(struct drm_bridge 
 *bridge)
  {
  }

 -static void ptn3460_bridge_destroy(struct drm_bridge *bridge)
 -{
 -   struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
 -
 -   drm_bridge_cleanup(bridge);
 -   if (gpio_is_valid(ptn_bridge-gpio_pd_n))
 -   gpio_free(ptn_bridge-gpio_pd_n);
 -   if (gpio_is_valid(ptn_bridge-gpio_rst_n))
 -   gpio_free(ptn_bridge-gpio_rst_n);
 -   /* Nothing else to free, we've got devm allocated memory */
 -}
 -
  static struct drm_bridge_funcs ptn3460_bridge_funcs = {
 .pre_enable = ptn3460_pre_enable,
 .enable = ptn3460_enable,
 .disable = ptn3460_disable,
 .post_disable = ptn3460_post_disable,
 -   .destroy = ptn3460_bridge_destroy,
  };

  static int ptn3460_get_modes(struct 

Re: [PATCH 03/14] drm/bridge: make bridge registration independent of drm flow

[Russell King - ARM Linux]

On Fri, Jan 30, 2015 at 10:37:19AM -0500, Rob Clark wrote:
 On Tue, Jan 20, 2015 at 11:38 AM, Ajay Kumar ajaykumar...@samsung.com wrote:
 I'll also need to update the new bridge in the msm edp code..
 although that isn't such a big deal if I knew how this was *supposed*
 to work.. since what is there now at least doesn't look right..

I wonder whether the new dw-hdmi bridge code get fixed up too...

-- 
FTTC broadband for 0.8mile line: currently at 10.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 03/14] drm/bridge: make bridge registration independent of drm flow

[Daniel Stone]

Hi,

On 30 January 2015 at 15:37, Rob Clark robdcl...@gmail.com wrote:
 ok, so I probably should have had a closer look at this before it
 landed in drm-next, so if it is too late to revert (and deal w/
 untangling subsequent patches that depend on this) some of these
 issues we'll just have to fix with follow-on patches.

 1) needs headerdoc for new fxns in drm_bridge.c, and needs to be added
 in drm.tmpl
 2) as far as I can tell, the new approach to cleaning up bridge
 objects is to just let them leak !?!

 I'll also need to update the new bridge in the msm edp code..
 although that isn't such a big deal if I knew how this was *supposed*
 to work.. since what is there now at least doesn't look right..

Given how long these patches sat around doing being passively NACKed
by discussions going around in circles, and how useful they are, I'd
be much more in favour of fixing them up than reverting and going
through the whole circus again ...

Cheers,
Daniel
--
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 3/3] cpufreq: exynos: allow modular build

[Arnd Bergmann]

On Thursday 29 January 2015 18:21:51 Eduardo Valentin wrote:
 Hello Arnd and Viresh,
 
 On Thu, Jan 29, 2015 at 01:42:32PM +0100, Arnd Bergmann wrote:
  On Thursday 29 January 2015 15:40:15 Viresh Kumar wrote:
obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o
obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o
   -obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)   += exynos-cpufreq.o
   -obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += exynos4210-cpufreq.o
   -obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)   += exynos4x12-cpufreq.o
   -obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)   += exynos5250-cpufreq.o
   +obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += exynos-cpufreq.o 
   exynos4210-cpufreq.o
   +obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)   += exynos-cpufreq.o 
   exynos4x12-cpufreq.o
   +obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)   += exynos-cpufreq.o 
   exynos5250-cpufreq.o
   
  
  I'd have to try it, but this might fail if one of the three drivers
  is built-in and another one is a module.
  
  Arnd
 
 Let me make one step back here. The original issue is, now this exynos
 cpufreq driver depends on of thermal; but of thermal can be built as
 module, while this cpufreq driver cannot. Original proposal is to allow
 module build in the exynos cpufreq driver.
 
 On the original proposal, my concern is that the driver code does not
 have separated modules, but one single module platform driver,  which uses 
 functions from
 other c files. On top of that, the patch originally allows four
 (independent) modules builds. Although the children drivers still
 selects the core part, we would still need to change the original patch
 to add module dependency too.
 
 So, my proposal was to, in order to allow module builds on this cpufreq
 driver, we also need to properly construct the driver into a single
 module, instead of several modules. The issue with my patch was the fact
 that it was allowing platforms that do not use that driver, to select it
 by default. And eventually this may cause a unusable module being loaded
 into those systems.
 
 Well, trying harder here in the same approach. The diff bellow is based
 on Arnd's original patch and on Viresh's amendment, except that the core
 part is now dependent on all the supported platforms, instead of
 ARCH_EXYNOS. This way, it wont load in platforms that are not supposed
 to be loaded. The user will be able to build the support for all
 platforms, or select which platforms he/she wants (as originally),
 except that now it can be a module, instead.
 
 I believe now by default it will still keep the driver only on those
 configs that expect it to be on. And it won't compile/load on platforms
 that it is not supposed to. It brings closer a config that is dependent on 
 this
 driver, so it looks better in the menuconfig.
 
 Let me know if I missed something (feel free to amend to your patch):

Yes, I think your refined approach works and is better than my
original patch, thanks a lot for giving it more thought!

One tiny problem:

 @@ -90,6 +84,20 @@ config ARM_EXYNOS_CPU_FREQ_BOOST_SW
  
 If in doubt, say N.
  
 +config ARM_EXYNOS5440_CPUFREQ
 + bool SAMSUNG EXYNOS5440
 + depends on SOC_EXYNOS5440
 + depends on HAVE_CLK  OF
 + select PM_OPP
 + default y
 + help
 +   This adds the CPUFreq driver for Samsung EXYNOS5440
 +   SoC. The nature of exynos5440 clock controller is
 +   different than previous exynos controllers so not using
 +   the common exynos framework.
 +
 +   If in doubt, say N.

I believe this one also has to be tristate, for the same reason.

  
 -#ifdef CONFIG_ARM_EXYNOS4210_CPUFREQ
 +#if IS_ENABLED(CONFIG_ARM_EXYNOS4210_CPUFREQ)
  extern int exynos4210_cpufreq_init(struct exynos_dvfs_info *);
  #else
  static inline int exynos4210_cpufreq_init(struct exynos_dvfs_info *info)
 @@ -61,7 +61,7 @@ static inline int exynos4210_cpufreq_init(struct 
 exynos_dvfs_info *info)
   return -EOPNOTSUPP;
  }
  #endif
 -#ifdef CONFIG_ARM_EXYNOS4X12_CPUFREQ
 +#if IS_ENABLED(CONFIG_ARM_EXYNOS4X12_CPUFREQ)
  extern int exynos4x12_cpufreq_init(struct exynos_dvfs_info *);
  #else
  static inline int exynos4x12_cpufreq_init(struct exynos_dvfs_info *info)
 @@ -69,7 +69,7 @@ static inline int exynos4x12_cpufreq_init(struct 
 exynos_dvfs_info *info)
   return -EOPNOTSUPP;
  }
  #endif
 -#ifdef CONFIG_ARM_EXYNOS5250_CPUFREQ
 +#if IS_ENABLED(CONFIG_ARM_EXYNOS5250_CPUFREQ)
  extern int exynos5250_cpufreq_init(struct exynos_dvfs_info *);
  #else
  static inline int exynos5250_cpufreq_init(struct exynos_dvfs_info *info)

This change is ok, but not needed, because the three extra symbols are still
bool. I would leave that change out, but I also don't mind it.

With the change to make ARM_EXYNOS5440_CPUFREQ tristate:

Acked-by: Arnd Bergmann a...@arndb.de
--
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  

Re: [PATCH 3/3] cpufreq: exynos: allow modular build

[Eduardo Valentin]

On Fri, Jan 30, 2015 at 10:24:12PM +0100, Arnd Bergmann wrote:
 On Thursday 29 January 2015 18:21:51 Eduardo Valentin wrote:
  Hello Arnd and Viresh,
  
  On Thu, Jan 29, 2015 at 01:42:32PM +0100, Arnd Bergmann wrote:
   On Thursday 29 January 2015 15:40:15 Viresh Kumar wrote:
 obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o
 obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)   += exynos-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += exynos4210-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)   += exynos4x12-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)   += exynos5250-cpufreq.o
+obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += exynos-cpufreq.o 
exynos4210-cpufreq.o
+obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)   += exynos-cpufreq.o 
exynos4x12-cpufreq.o
+obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)   += exynos-cpufreq.o 
exynos5250-cpufreq.o

   
   I'd have to try it, but this might fail if one of the three drivers
   is built-in and another one is a module.
   
 Arnd
  
  Let me make one step back here. The original issue is, now this exynos
  cpufreq driver depends on of thermal; but of thermal can be built as
  module, while this cpufreq driver cannot. Original proposal is to allow
  module build in the exynos cpufreq driver.
  
  On the original proposal, my concern is that the driver code does not
  have separated modules, but one single module platform driver,  which uses 
  functions from
  other c files. On top of that, the patch originally allows four
  (independent) modules builds. Although the children drivers still
  selects the core part, we would still need to change the original patch
  to add module dependency too.
  
  So, my proposal was to, in order to allow module builds on this cpufreq
  driver, we also need to properly construct the driver into a single
  module, instead of several modules. The issue with my patch was the fact
  that it was allowing platforms that do not use that driver, to select it
  by default. And eventually this may cause a unusable module being loaded
  into those systems.
  
  Well, trying harder here in the same approach. The diff bellow is based
  on Arnd's original patch and on Viresh's amendment, except that the core
  part is now dependent on all the supported platforms, instead of
  ARCH_EXYNOS. This way, it wont load in platforms that are not supposed
  to be loaded. The user will be able to build the support for all
  platforms, or select which platforms he/she wants (as originally),
  except that now it can be a module, instead.
  
  I believe now by default it will still keep the driver only on those
  configs that expect it to be on. And it won't compile/load on platforms
  that it is not supposed to. It brings closer a config that is dependent on 
  this
  driver, so it looks better in the menuconfig.
  
  Let me know if I missed something (feel free to amend to your patch):
 
 Yes, I think your refined approach works and is better than my
 original patch, thanks a lot for giving it more thought!
 
 One tiny problem:
 
  @@ -90,6 +84,20 @@ config ARM_EXYNOS_CPU_FREQ_BOOST_SW
   
If in doubt, say N.
   
  +config ARM_EXYNOS5440_CPUFREQ
  +   bool SAMSUNG EXYNOS5440
  +   depends on SOC_EXYNOS5440
  +   depends on HAVE_CLK  OF
  +   select PM_OPP
  +   default y
  +   help
  + This adds the CPUFreq driver for Samsung EXYNOS5440
  + SoC. The nature of exynos5440 clock controller is
  + different than previous exynos controllers so not using
  + the common exynos framework.
  +
  + If in doubt, say N.
 
 I believe this one also has to be tristate, for the same reason.
 

I agree with you that it is better if we make it tristate. So, on my
side, I have no concerns changing it to tristate.

However, the exynos5440 cpufreq driver does not depend on of thermal as
of today, and therefore, I did not touch this driver for this matter.
Meaning, if it is not causing troubles, no need to mess with it.

But I can add this change. No issues, on my side.

   
  -#ifdef CONFIG_ARM_EXYNOS4210_CPUFREQ
  +#if IS_ENABLED(CONFIG_ARM_EXYNOS4210_CPUFREQ)
   extern int exynos4210_cpufreq_init(struct exynos_dvfs_info *);
   #else
   static inline int exynos4210_cpufreq_init(struct exynos_dvfs_info *info)
  @@ -61,7 +61,7 @@ static inline int exynos4210_cpufreq_init(struct 
  exynos_dvfs_info *info)
  return -EOPNOTSUPP;
   }
   #endif
  -#ifdef CONFIG_ARM_EXYNOS4X12_CPUFREQ
  +#if IS_ENABLED(CONFIG_ARM_EXYNOS4X12_CPUFREQ)
   extern int exynos4x12_cpufreq_init(struct exynos_dvfs_info *);
   #else
   static inline int exynos4x12_cpufreq_init(struct exynos_dvfs_info *info)
  @@ -69,7 +69,7 @@ static inline int exynos4x12_cpufreq_init(struct 
  exynos_dvfs_info *info)
  return -EOPNOTSUPP;
   }
   #endif
  -#ifdef CONFIG_ARM_EXYNOS5250_CPUFREQ
  +#if IS_ENABLED(CONFIG_ARM_EXYNOS5250_CPUFREQ)
   extern int exynos5250_cpufreq_init(struct 

[PATCH] drm/exynos: don' disable hdmi clocks for exynos5420

[Gustavo Padovan]

From: Prathyush K prathyus...@samsung.com

When VPLL clock of less than 140 MHz was used and all the three
clocks - hdmiphy, hdmi, sclk_hdmi are disabled, the system hangs
during S2R when HDMI is connected. Since we want to use a vpll
clock of 70.5 MHz, we cannot disable these 3 clocks before suspending.
This patch moves the clk enable/disable of hdmi and sclk_hdmi
outside of the pm ops. Now system suspends and resumes with HDMI
connected with VPLL set at 70.5 MHz.

Signed-off-by: Prathyush K prathyus...@samsung.com
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 6aa0d65..0be6921 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2254,6 +2254,20 @@ static int hdmi_resources_init(struct hdmi_context 
*hdata)
} else
res-reg_hdmi_en = NULL;
 
+   /*
+* For these two clocks exynos5420 fails to suspend if VPLL clock of
+* 70.5 MHz is used and these clocks are disabled before suspend. So
+* enable them here.
+* Note that this will keep the clocks enabled for the entire
+* lifetime of the driver and waste energy when it is suspended.
+* However it prevents the system crash until a better solution is
+* found
+*/
+   if (of_machine_is_compatible(samsung,exynos5420)) {
+   clk_prepare_enable(res-sclk_hdmi);
+   clk_prepare_enable(res-hdmi);
+   }
+
return ret;
 fail:
DRM_ERROR(HDMI resource init - failed\n);
@@ -2516,6 +2530,11 @@ static int hdmi_remove(struct platform_device *pdev)
if (hdata-res.reg_hdmi_en)
regulator_disable(hdata-res.reg_hdmi_en);
 
+   if (of_machine_is_compatible(samsung,exynos5420)) {
+   clk_disable_unprepare(hdata-res.sclk_hdmi);
+   clk_disable_unprepare(hdata-res.hdmi);
+   }
+
if (hdata-hdmiphy_port)
put_device(hdata-hdmiphy_port-dev);
put_device(hdata-ddc_adpt-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

Re: PROBLEM: BUG appearing when trying to allocate interrupt on Exynos MCT after CPU hotplug

[Stephen Boyd]

Kept meaning to get back to this thread. Have you resolved it?

On 10/29/14 03:38, Marcin Jabrzyk wrote:
 So I've tried this patch, it resolves one problem but introduces also
 new ones. As expected the BUG warning is not showing after applying
 this patch but there are some interesting side effects.

Well that's half good news.

 I was looking on /proc/interrupts output. IRQ for CPU0 have MCT name
 and IRQ for CPU1 has unexpectedly no name at all.

This is pretty confusing. I don't see how the patch could cause this to
happen.

 After making hotplug cycle of CPU1 I've observed that IRQs attached
 originally for that CPU are generating on really low count and not in
 order with IRQ for CPU0.
 What's more the interrupt for CPU1 is showing to me as being counted
 for both CPUs, so it's probably not being attached to CPU1.


yeah. Can you give the output of /proc/timer_list in addition to
/proc/interrupts? It may give some hints on what's going on. It may also
be interesting to see if irq_force_affinity() is failing. Please check
the return value and print an error


diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 1800053b4644..3c4538e26731 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -450,6 +450,7 @@ static int exynos4_local_timer_setup(struct 
clock_event_device *evt)
 {
struct mct_clock_event_device *mevt;
unsigned int cpu = smp_processor_id();
+   int ret;
 
mevt = container_of(evt, struct mct_clock_event_device, evt);
 
@@ -468,7 +469,9 @@ static int exynos4_local_timer_setup(struct 
clock_event_device *evt)
if (mct_int_type == MCT_INT_SPI) {
evt-irq = mct_irqs[MCT_L0_IRQ + cpu];
enable_irq(evt-irq);
-   irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu], cpumask_of(cpu));
+   ret = irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu], 
cpumask_of(cpu));
+   if (ret)
+   pr_err(force failed %d\n, ret);
} else {
enable_percpu_irq(mct_irqs[MCT_L0_IRQ], 0);
}

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: [PATCH -v2] drm/exynos: track vblank events on a per crtc basis

[Gustavo Padovan]

2015-01-30 Joonyoung Shim jy0922.s...@samsung.com:

 +Cc Inki,
 
 Hi,
 
 On 01/30/2015 02:10 AM, Gustavo Padovan wrote:
  From: Mandeep Singh Baines m...@chromium.org
  
  The goal of the change is to make sure we send the vblank event on the
  current vblank. My hope is to fix any races that might be causing flicker.
  After this change I only see a flicker in the transition plymouth and
  X11.
  
  Simplified the code by tracking vblank events on a per-crtc basis. This
  allowed me to remove all error paths from the callback. It also allowed
  me to remove the vblank wait from the callback.
  
  Signed-off-by: Mandeep Singh Baines m...@chromium.org
  Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
  ---
   drivers/gpu/drm/exynos/exynos_drm_crtc.c | 29 +++--
   drivers/gpu/drm/exynos/exynos_drm_drv.c  | 19 ---
   drivers/gpu/drm/exynos/exynos_drm_drv.h  |  6 ++
   3 files changed, 9 insertions(+), 45 deletions(-)
  
  diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
  b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
  index a85c451..91c175b 100644
  --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
  +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
  @@ -34,9 +34,8 @@ static void exynos_drm_crtc_dpms(struct drm_crtc *crtc, 
  int mode)
  if (mode  DRM_MODE_DPMS_ON) {
  /* wait for the completion of page flip. */
  if (!wait_event_timeout(exynos_crtc-pending_flip_queue,
  -   !atomic_read(exynos_crtc-pending_flip),
  -   HZ/20))
  -   atomic_set(exynos_crtc-pending_flip, 0);
  +   (exynos_crtc-event == NULL), HZ/20))
  +   exynos_crtc-event = NULL;
  drm_crtc_vblank_off(crtc);
  }
   
  @@ -166,7 +165,6 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc 
  *crtc,
   uint32_t page_flip_flags)
   {
  struct drm_device *dev = crtc-dev;
  -   struct exynos_drm_private *dev_priv = dev-dev_private;
  struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
  struct drm_framebuffer *old_fb = crtc-primary-fb;
  unsigned int crtc_w, crtc_h;
  @@ -195,9 +193,7 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc 
  *crtc,
  }
   
  spin_lock_irq(dev-event_lock);
  -   list_add_tail(event-base.link,
  -   dev_priv-pageflip_event_list);
  -   atomic_set(exynos_crtc-pending_flip, 1);
  +   exynos_crtc-event = event;
 
 We will lose unfinished prior events by this change. That's why we use
 linked list.

I think you are right, but I was using exynos_crtc-event to do exactly the
same as exynos_crtc-pending_flip. So we were losing a event in
exynos_drm_crtc_dpms() before too. I change this patch to have a page_flip
list on the crtc. 

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

Re: [PATCH 3/6] drm/exynos: Remove exynos_plane_dpms() call with no effect

[Gustavo Padovan]

2015-01-30 Joonyoung Shim jy0922.s...@samsung.com:

 +Cc Inki,
 
 Hi,
 
 On 01/23/2015 09:42 PM, Gustavo Padovan wrote:
  From: Gustavo Padovan gustavo.pado...@collabora.co.uk
  
  exynos_plane_dpms(DRM_MODE_DPMS_ON) calls the win_enable()'s callback
  from the underlying layer. However neither one of these layers implement
  win_enable() - FIMD, Mixer and VIDI. Thus the call to exynos_plane_dpms()
  is pointless.
  
 
 No, it needs for pair with DRM_MODE_DPMS_OFF case.

It is a stub call. exynos_plane_dpms(DRM_MODE_DPMS_ON) only calls
exynos_crtc-ops-win_enable() however neither FIMD, VIDI or Mixer implements
win_enable(). So it has no effect and we can remove this call safely.

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] clocksource: exynos_mct: fix for sleeping in atomic ctx handling cpu hotplug notif.

[Damian Eppel]

This is to fix an issue of sleeping in atomic context when processing
hotplug notifications in Exynos MCT(Multi-Core Timer).
The issue was reproducible on Exynos 3250 (Rinato board) and Exynos 5420
(Arndale Octa board).

Whilst testing cpu hotplug events on kernel configured with DEBUG_PREEMPT
and DEBUG_ATOMIC_SLEEP we get following BUG message, caused by calling
request_irq() and free_irq() in the context of hotplug notification
(which is in this case atomic context).

root@target:~# echo 0  /sys/devices/system/cpu/cpu1/online

[   25.157867] IRQ18 no longer affine to CPU1
...
[   25.158445] CPU1: shutdown

root@target:~# echo 1  /sys/devices/system/cpu/cpu1/online

[   40.785859] CPU1: Software reset
[   40.786660] BUG: sleeping function called from invalid context at 
mm/slub.c:1241
[   40.786668] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/1
[   40.786678] Preemption disabled at:[  (null)]   (null)
[   40.786681]
[   40.786692] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 
3.19.0-rc4-00024-g7dca860 #36
[   40.786698] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   40.786728] [c0014a00] (unwind_backtrace) from [c0011980] 
(show_stack+0x10/0x14)
[   40.786747] [c0011980] (show_stack) from [c0449ba0] 
(dump_stack+0x70/0xbc)
[   40.786767] [c0449ba0] (dump_stack) from [c00c6124] 
(kmem_cache_alloc+0xd8/0x170)
[   40.786785] [c00c6124] (kmem_cache_alloc) from [c005d6f8] 
(request_threaded_irq+0x64/0x128)
[   40.786804] [c005d6f8] (request_threaded_irq) from [c0350b8c] 
(exynos4_local_timer_setup+0xc0/0x13c)
[   40.786820] [c0350b8c] (exynos4_local_timer_setup) from [c0350ca8] 
(exynos4_mct_cpu_notify+0x30/0xa8)
[   40.786838] [c0350ca8] (exynos4_mct_cpu_notify) from [c003b330] 
(notifier_call_chain+0x44/0x84)
[   40.786857] [c003b330] (notifier_call_chain) from [c0022fd4] 
(__cpu_notify+0x28/0x44)
[   40.786873] [c0022fd4] (__cpu_notify) from [c0013714] 
(secondary_start_kernel+0xec/0x150)
[   40.786886] [c0013714] (secondary_start_kernel) from [40008764] 
(0x40008764)

Solution:
Clockevent irqs cannot be requested/freed every time cpu is
hot-plugged/unplugged as CPU_STARTING/CPU_DYING notifications
that signals hotplug or unplug events are sent with both preemption
and local interrupts disabled. Since request_irq() may sleep it is
moved to the initialization stage and performed for all possible
cpus prior putting them online. Then, in the case of hotplug event
the irq asociated with the given cpu will simply be enabled.
Similarly on cpu unplug event the interrupt is not freed but just
disabled.

Note that after successful request_irq() call for a clockevent device
associated to given cpu the requested irq is disabled (via disable_irq()).
That is to make things symmetric as we expect hotplug event as a next
thing (which will enable irq again). This should not pose any problems
because at the time of requesting irq the clockevent device is not
fully initialized yet, therefore should not produce interrupts at that point.

For disabling an irq at cpu unplug notification disable_irq_nosync() is
chosen which is a non-blocking function. This again shouldn't be a problem as
prior sending CPU_DYING notification interrupts are migrated away
from the cpu.

Fixes: 7114cd749a12 (clocksource: exynos_mct: use (request/free)_irq calls for 
local timer registration)
Signed-off-by: Damian Eppel d.ep...@samsung.com
Cc: sta...@vger.kernel.org
Reported-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
 drivers/clocksource/exynos_mct.c | 45 
 1 file changed, 32 insertions(+), 13 deletions(-)

diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 83564c9..9beca58 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -466,15 +466,12 @@ static int exynos4_local_timer_setup(struct 
clock_event_device *evt)
exynos4_mct_write(TICK_BASE_CNT, mevt-base + MCT_L_TCNTB_OFFSET);
 
if (mct_int_type == MCT_INT_SPI) {
-   evt-irq = mct_irqs[MCT_L0_IRQ + cpu];
-   if (request_irq(evt-irq, exynos4_mct_tick_isr,
-   IRQF_TIMER | IRQF_NOBALANCING,
-   evt-name, mevt)) {
-   pr_err(exynos-mct: cannot register IRQ %d\n,
-   evt-irq);
+
+   if (evt-irq == -1)
return -EIO;
-   }
-   irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu], cpumask_of(cpu));
+
+   irq_force_affinity(evt-irq, cpumask_of(cpu));
+   enable_irq(evt-irq);
} else {
enable_percpu_irq(mct_irqs[MCT_L0_IRQ], 0);
}
@@ -487,10 +484,12 @@ static int exynos4_local_timer_setup(struct 
clock_event_device *evt)
 static void exynos4_local_timer_stop(struct clock_event_device *evt)
 {
evt-set_mode(CLOCK_EVT_MODE_UNUSED, evt);
-   if (mct_int_type == MCT_INT_SPI)
-   free_irq(evt-irq, 

Re: [PATCH 5/6] drm/exynos: remove struct *_win_data abstraction on planes

[Gustavo Padovan]

Hi Joonyoung,

2015-01-30 Joonyoung Shim jy0922.s...@samsung.com:

 +Cc Inki,
 
 Hi,
 
 On 01/23/2015 09:42 PM, Gustavo Padovan wrote:
  From: Gustavo Padovan gustavo.pado...@collabora.co.uk
  
  struct {fimd,mixer,vidi}_win_data was just keeping the same data
  as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
  directly.
  
  It changes how planes are created and remove .win_mode_set() callback
  that was only filling all *_win_data structs.
  
  Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
  ---
   drivers/gpu/drm/exynos/exynos_drm_crtc.c  |   9 +-
   drivers/gpu/drm/exynos/exynos_drm_crtc.h  |   1 +
   drivers/gpu/drm/exynos/exynos_drm_drv.c   |  14 --
   drivers/gpu/drm/exynos/exynos_drm_drv.h   |   5 +-
   drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 181 ++---
   drivers/gpu/drm/exynos/exynos_drm_plane.c |  20 +--
   drivers/gpu/drm/exynos/exynos_drm_plane.h |   6 +-
   drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 123 -
   drivers/gpu/drm/exynos/exynos_mixer.c | 212 
  +++---
   9 files changed, 182 insertions(+), 389 deletions(-)
  
  diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
  b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
  index d0f4e1b..5cd6c1a 100644
  --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
  +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
  @@ -287,13 +287,13 @@ static void 
  exynos_drm_crtc_attach_mode_property(struct drm_crtc *crtc)
   }
   
   struct exynos_drm_crtc *exynos_drm_crtc_create(struct drm_device *drm_dev,
  +  struct drm_plane *plane,
 int pipe,
 enum exynos_drm_output_type type,
 struct exynos_drm_crtc_ops *ops,
 void *ctx)
   {
  struct exynos_drm_crtc *exynos_crtc;
  -   struct drm_plane *plane;
  struct exynos_drm_private *private = drm_dev-dev_private;
  struct drm_crtc *crtc;
  int ret;
  @@ -309,12 +309,6 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct 
  drm_device *drm_dev,
  exynos_crtc-type = type;
  exynos_crtc-ops = ops;
  exynos_crtc-ctx = ctx;
  -   plane = exynos_plane_init(drm_dev, 1  pipe,
  - DRM_PLANE_TYPE_PRIMARY);
  -   if (IS_ERR(plane)) {
  -   ret = PTR_ERR(plane);
  -   goto err_plane;
  -   }
   
 
 The crtc should have one primary plane, i think it is more reasonable
 exynos_drm_crtc_create function creates primary plane.

Yes and it has a primary plane. They are defined in the drivers' struct 
*_context
the same way *_win_data was defined. And they allocated together wit the
context struct and and initialized by exynos_plane_init() right before the
call to exynos_drm_crtc_create(). Check the fimd_bind() part of 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

Re: [PATCH 6/6] drm/exynos: do not copy adjusted mode into mode during crtc mode_set

[Gustavo Padovan]

Hi Joonyoung,

2015-01-30 Joonyoung Shim jy0922.s...@samsung.com:

 Hi,
 
 On 01/23/2015 09:43 PM, Gustavo Padovan wrote:
  From: Daniel Kurtz djku...@chromium.org
  
  The 'mode' is the modeline information which specifies the ideal mode
  requested by the mode set initiator (usually userspace).
  The 'adjusted_mode' is the actual hardware mode after all the crtcs
  and encoders have had a chance to fix it up.
  
  The adjusted_mode starts as a duplicate of the mode in
  drm_crtc_helper_set_mode(), and gets modified as required.  There is no
  reason to touch the original requested mode.
  
 
 Agree, but is there any side effect after this commit? Should we save
 adjusted_mode to other variable and use it?

I haven't seen any. Tested on peach pi and snow. Do we have any reason to save
it now? I don't we have a user for it now.

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

Re: [PATCH] exynos/drm: fix no hdmi output

[Gustavo Padovan]

Hi Alban,

2015-01-29 Alban Browaeys alban.browa...@gmail.com:

 The hdmi outputs black screen only even though under the hood Xorg and
 framebuffer console  are fine : devices found and initialized, but
 not a pixel out.
 
 Commit 93bca243ec96 (drm/exynos: remove struct exynos_drm_manager)
 changed the call order of mixer_initialize with regards to
  exynos_drm_crtc_create.
 
 This changes breaks hdmi out on Odroid U2 (linux-next with added
  Marek Szyprowski v4 hdmi patchset from linux-samsung-soc ML).
 
 Restore the previous call ordering get hdmi to ouput proper pixels:
 ie call mixer_initialize first then exynos_drm_crtc_create.
 
 Fixes: 93bca243ec96 (drm/exynos: remove struct exynos_drm_manager)
 Signed-off-by: Alban Browaeys pra...@yahoo.com
 ---
  drivers/gpu/drm/exynos/exynos_mixer.c | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)

Reviewed-by: Gustavo Padovan gustavo.pado...@collabora.co.uk

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

Re: [PATCH 1/2] thermal: exynos: Reorder exynos_map_dt_data() function

[Abhilash Kesavan]

Hi Lukasz,

On Fri, Jan 30, 2015 at 1:44 PM, Lukasz Majewski l.majew...@samsung.com wrote:
 Hi Eduardo, Abhilash,

 On Thu, Jan 22, 2015 at 06:02:07PM +0530, Abhilash Kesavan wrote:
  Hi Lukasz,
 
  On Thu, Jan 22, 2015 at 2:31 PM, Lukasz Majewski
  l.majew...@samsung.com wrote:
   Hi Abhilash,
  
   Hi Lukasz,
  
   On Mon, Jan 19, 2015 at 5:14 PM, Lukasz Majewski
   l.majew...@samsung.com wrote:
The exynos_map_dt_data() function must be called before
thermal_zone_of_sensor_register(), and hence provide tmu_read()
function, before it is needed.
   
This change is driven by adding support for enabling
thermal_zoneX when it is properly initialized.
   
One can read the mode of operation
at /sys/class/thermal/thermal_zone0/mode Such functionality was
missing in the of-thermal.c code.
   
Reported-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
 drivers/thermal/samsung/exynos_tmu.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)
   
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c index 9d2d685..5d946ab
100644 --- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -975,15 +975,16 @@ static int exynos_tmu_probe(struct
platform_device *pdev) platform_set_drvdata(pdev, data);
mutex_init(data-lock);
   
+   ret = exynos_map_dt_data(pdev);
+   if (ret)
+   goto err_sensor;
+
data-tzd =
thermal_zone_of_sensor_register(pdev-dev, 0, data,
exynos_sensor_ops); if (IS_ERR(data-tzd)) {
pr_err(thermal: tz: %p ERROR\n, data-tzd);
return PTR_ERR(data-tzd);
}
-   ret = exynos_map_dt_data(pdev);
-   if (ret)
-   goto err_sensor;
   
pdata = data-pdata;
  
   I have been testing this along with your v5 patch set and am
   seeing incorrect temperature being reported at boot-up on
   exynos7.
  
   Does it show a maximal temperature value (0x1FF)?
 
  I did not print the current temperature register, but I remember the
  message showing ~105C. Will give you the register value when I test
  with more debug prints tomorrow.
 
  
It looks
   like exynos_tmu_read gets called from
   thermal_zone_of_device_update during boot-up, now that we have
   it populated early. However, as the tmu initialization function
   has not been called yet it returns a wrong value. Does that
   sound correct ?
  
   No, this is a mistake. However, I'm wondering why on Exynos4/5
   this error didn't show up...
 
  I have been lowering the software trip point temperature in the
  exynos7 dts file (to 55C) for testing purposes. Hence, when the
  temperature is read incorrectly as ~105C the board trips at boot-up

  this is a very unusual
 value - I had problems with
 reading 0xFF values with
 similar symptom (but this was
 caused by lack of vtmu).

  itself. Maybe for exynos4/5 the incorrect value read during boot-up
  is in the non-tripping range and once the tmu is initialized later
  it continues to function properly thereafter ?
 
  
   The reordering is needed to be able to call set_mode callback at
   of-thermal.c to set the mode.
  
   If this change causes problems, then another solution (probably
   not so neat) must be found.
 
  Please let me know if you need any further details.

 Abhilash, could you provide more details (like relevant output from
 dmesg) and point me a list of patches which shall I apply to test this
 issue on Exynos4/5?
Sorry, I have not had the time to re-check this and provide you with
the current temperature register value. I will definitely do so on
Monday and also provide you the dmesg output. I applied the following
patches on linux-next:

bbf872d thermal: exynos: Add TMU support for Exynos7 SoC
b8190ac dts: Documentation: Add documentation for Exynos7 SoC thermal bindings
9330ec1 thermal: exynos: Reorder exynos_map_dt_data() function
4dd41c4 thermal: exynos: dts: Provide device tree bindings identical
to the one in exynos_tmu_data.c
a7b80b9 thermal: dts: exynos: Trip points and sensor configuration
data for Exynos5440
77d072e thermal: exynos: dts: Define default thermal-zones for Exynos4
964dd36 thermal: dts: Default trip points definition for Exynos5420 SoCs
c1d2f97 thermal: exynos: dts: Add default definition of the TMU sensor parameter
02a4496 arm: dts: Adding CPU cooling binding for Exynos SoCs
bfadff0 arm: dts: odroid: Enable TMU at Exynos4412 based Odroid U3 device
862764c arm: dts: odroid: Add LDO10 regulator node necessary for TMU on Odroid
c064731 arm: dts: trats: Enable TMU on the Exynos4210 trats device

Along with the above list 

Re: [RFC] drm/exynos: move hdmi clk disable out of pm ops

[Javier Martinez Canillas]

Hello,

On Fri, Jan 30, 2015 at 9:03 AM, Javier Martinez Canillas
jav...@dowhile0.org wrote:

 I haven't the S2R case since it is broken in mainline for Exynos5420
 (even with $subject applied) but $subject fixes for me the system
 crash we have discussed before [0]. That is when mixer_poweron() tries
 to access the mixer register without hdmi_poweron() enabling the
 hdmi clock.


I forgot to add the reference to the previously discussed issue, sorry
for the noise...

Best regards,
Javier

[0]: http://www.spinics.net/lists/arm-kernel/msg393206.html
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] drm/exynos: hdmi: replace fb size with mode size from win commit

[Joonyoung Shim]

Hi,

On 01/30/2015 05:30 PM, Seung-Woo Kim wrote:
 For default graphic window, mixer_win_commit() sets display size
 register as fb size. Calling setplane with smaller fb size than
 mode size to default window causes distorted display result. So
 this patch replaces fb size with mode size for display size from
 the mixer_win_commit().
 
 Signed-off-by: Seung-Woo Kim sw0312@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_mixer.c |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
 b/drivers/gpu/drm/exynos/exynos_mixer.c
 index 6766271..086fe0e 100644
 --- a/drivers/gpu/drm/exynos/exynos_mixer.c
 +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
 @@ -584,8 +584,8 @@ static void mixer_graph_buffer(struct mixer_context *ctx, 
 int win)
   /* setup display size */
   if (ctx-mxr_ver == MXR_VER_128_0_0_184 
   win == MIXER_DEFAULT_WIN) {
 - val  = MXR_MXR_RES_HEIGHT(win_data-fb_height);
 - val |= MXR_MXR_RES_WIDTH(win_data-fb_width);
 + val  = MXR_MXR_RES_HEIGHT(win_data-mode_height);
 + val |= MXR_MXR_RES_WIDTH(win_data-mode_width);
   mixer_reg_write(res, MXR_RESOLUTION, val);
   }
  
 

Acked-by: Joonyoung Shim jy0922.s...@samsung.com

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

Re: [PATCH 1/4] mmc: core: add support for hardware reset gpio line

[Marek Szyprowski]

Hello,

On 2015-01-29 11:56, Javier Martinez Canillas wrote:

On Thu, Jan 29, 2015 at 10:15 AM, Marek Szyprowski
m.szyprow...@samsung.com wrote:

Also, I wonder whether we could extend the mmc-pwrseq to cover your
case? Did you consider that as an option?


I didn't consider mmc-pwrseq yet. For me it looked straightforward to

I agree with Ulf that using mmc-pwrseq would be a good solution and in
fact I think the pwrseq_simple [0] driver will fit your use case since
it supports a reset GPIO pin which is what many WLAN chips attached to
a SDIO interface use.


Ok, I've checked mmc-prwseq and mmc-pwrseq-simple. I also checked the
hardware and it mmc-pwrseq-simple cannot be used directly.

Although the signal is called RSTN (on Odroid U3 schema), the eMMC card
gets resetted not on low line level, but during the rising edge. This RSTN
line is also pulled up by the external resistor. However, the strangest
thing is the fact that the default SoC configuration (which is applied
during hw reset) for this GPIO line is input, pulled-down. The SoC
internal pull-down is stronger than the external pull up, so in the end,
during the SoC reboot the RSTN signal is set to zero. Later bootloader
disables the internal pull-down.

To sum up - to perform proper reboot on Odroid U3/XU3, one need to set
RSTN to zero, wait a while and the set it back to 1.

To achieve this with mmc-pwrseq-simple, I would need to modify the power_off
callback to toggle reset line to zero and back to one. This however might
not be desired to other sd/mmc cards used with mmc-pwrseq-simple.

I can also provide separate mmc-pwrsrq-odroid driver, which will be very
similar to mmc-pwrseq-simple.

Ulf - which approach would you prefer?





implement
it just like card detect or write-protection gpio pins. I already noticed
that
there is code for some mmc host driver, which perform mmc hardware reset. If
you
think that extending pwrseq is the better approach, I will try to update my
patches. This will add reboot handler to mmc-pwrseq then. The only question
is

I don't think that adding a reboot handler to mmc-pwrseq is needed.
AFAICT the call chain is:

sys_reboot() - kernel_restart() - device_shutdown() -
mmc_bus_shutdown() - _mmc_suspend() - mmc_power_off() -
mmc_pwrseq_power_off() - struct mmc_pwrseq_ops .power_off

So since the pwrseq_simple already asserts the reset GPIO in
.power_off, it should be enough to ensure the eMMC will be reset to
its default configuration for the iROM to work properly.

It also asserts the GPIO pin in .pre_power_on and de-asserts in
.post_power_on which should be needed as well for the other case you
mentioned when a broken bootloader left the emmc card in some unknown
state.


emergency_restart() doesn't call device_shutdown(), so I think it still 
makes

sense to add real reset handler to mmc-pwrseq to ensure that power_off will
be called even during emergency_restart().

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

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

Re: [PATCH v2] pwm: samsung: Fix output race on disabling

[Sjoerd Simons]

+To Kukjin

Jingoo, Kukjin, could one of you review this patch to ensure it's the
right thing to do on samsung hardware? 

On Thu, 2015-01-22 at 22:41 +0100, Sjoerd Simons wrote:
 When disabling the samsung PWM the output state remains at the level it
 was in the end of a pwm cycle. In other words, calling pwm_disable when
 at 100% duty will keep the output active, while at all other setting the
 output will go/stay inactive. On top of that the samsung PWM settings are
 double-buffered, which means the new settings only get applied at the
 start of a new PWM cycle.
 
 This results in a race if the PWM is at 100% duty and a driver calls:
   pwm_config (pwm, 0, period);
   pwm_disable (pwm);
 
 In this case the PWMs output will unexpectedly stay active, unless a new
 PWM cycle happened to start between the register writes in _config and
 _disable. As far as i can tell this is a regression introduced by 3bdf878,
 before that a call to pwm_config would call pwm_samsung_enable which,
 while heavy-handed, made sure the expected settings were live.
 
 To resolve this, while not re-introducing the issues 3bdf878 (flickering
 as the PWM got reset while in a PWM cycle). Only force an update of the
 settings when at 100% duty, which shouldn't have a noticeable effect on
 the output but is enough to ensure the behaviour is as expected on
 disable.
 
 Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
 ---
 Changes since v1:
   Fix small issues pointed out by Tomasz Figa
   - Correct various coding style issues
   - Read the current value of the tcmp register for comparison rather then
 using a non-trivial comparison to decide whether the current state was
 100% duty
   - Move the code to force manual update out into its own function
   - Clarify the comment indicating why a manual update is sometimes required
 
  drivers/pwm/pwm-samsung.c | 31 ++-
  1 file changed, 30 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
 index 3e9b583..649f6c4 100644
 --- a/drivers/pwm/pwm-samsung.c
 +++ b/drivers/pwm/pwm-samsung.c
 @@ -269,12 +269,31 @@ static void pwm_samsung_disable(struct pwm_chip *chip, 
 struct pwm_device *pwm)
   spin_unlock_irqrestore(samsung_pwm_lock, flags);
  }
  
 +static void pwm_samsung_manual_update(struct samsung_pwm_chip *chip,
 +   struct pwm_device *pwm)
 +{
 + unsigned int tcon_chan = to_tcon_channel(pwm-hwpwm);
 + u32 tcon;
 + unsigned long flags;
 +
 + spin_lock_irqsave(samsung_pwm_lock, flags);
 +
 + tcon = readl(chip-base + REG_TCON);
 + tcon |= TCON_MANUALUPDATE(tcon_chan);
 + writel(tcon, chip-base + REG_TCON);
 +
 + tcon = ~TCON_MANUALUPDATE(tcon_chan);
 + writel(tcon, chip-base + REG_TCON);
 +
 + spin_unlock_irqrestore(samsung_pwm_lock, flags);
 +}
 +
  static int pwm_samsung_config(struct pwm_chip *chip, struct pwm_device *pwm,
 int duty_ns, int period_ns)
  {
   struct samsung_pwm_chip *our_chip = to_samsung_pwm_chip(chip);
   struct samsung_pwm_channel *chan = pwm_get_chip_data(pwm);
 - u32 tin_ns = chan-tin_ns, tcnt, tcmp;
 + u32 tin_ns = chan-tin_ns, tcnt, tcmp, oldtcmp;
  
   /*
* We currently avoid using 64bit arithmetic by using the
 @@ -288,6 +307,7 @@ static int pwm_samsung_config(struct pwm_chip *chip, 
 struct pwm_device *pwm,
   return 0;
  
   tcnt = readl(our_chip-base + REG_TCNTB(pwm-hwpwm));
 + oldtcmp = readl(our_chip-base + REG_TCMPB(pwm-hwpwm));
  
   /* We need tick count for calculation, not last tick. */
   ++tcnt;
 @@ -335,6 +355,15 @@ static int pwm_samsung_config(struct pwm_chip *chip, 
 struct pwm_device *pwm,
   writel(tcnt, our_chip-base + REG_TCNTB(pwm-hwpwm));
   writel(tcmp, our_chip-base + REG_TCMPB(pwm-hwpwm));
  
 + /* In case the PWM is currently at 100% duty, force a manual update
 +  * to prevent the signal staying high in the pwm is disabled shortly
 +  * afer this update (before it autoreloaded the new values) .
 +  */
 + if (oldtcmp == (u32) -1) {
 + dev_dbg(our_chip-chip.dev, Forcing manual update);
 + pwm_samsung_manual_update(our_chip, pwm);
 + }
 +
   chan-period_ns = period_ns;
   chan-tin_ns = tin_ns;
   chan-duty_ns = duty_ns;




smime.p7s
Description: S/MIME cryptographic signature

Re: [RFC] drm/exynos: move hdmi clk disable out of pm ops

[Javier Martinez Canillas]

Hello Joonyoung,

On Fri, Jan 30, 2015 at 3:02 AM, Joonyoung Shim jy0922.s...@samsung.com wrote:
 +Cc Kukjin,

 Hi,

 On 01/29/2015 10:31 PM, Gustavo Padovan wrote:
 From: Prathyush K prathyus...@samsung.com

 When VPLL clock of less than 140 MHz was used and all the three
 clocks - hdmiphy, hdmi, sclk_hdmi are disabled, the system hangs
 during S2R when HDMI is connected. Since we want to use a vpll
 clock of 70.5 MHz, we cannot disable these 3 clocks before suspending.
 This patch moves the clk enable/disable of hdmi and sclk_hdmi
 outside of the pm ops. Now system suspends and resumes with HDMI
 connected with VPLL set at 70.5 MHz.

 Signed-off-by: Prathyush K prathyus...@samsung.com
 Signed-off-by: Andrew Bresticker abres...@chromium.org
 Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk

 ---
 This work depends on the HDMI support patches from Javier:
 https://lkml.org/lkml/2015/1/20/235

 This patch comes from a downstream tree (Google chormeOS) and it is
 authored by a Samsung employee, but we still think this may not fix
 the real cause of the bug, there might be something else that we
 haven't found that could be the cause of this issue. Anyone has some
 comment to add here?

 Hmm, do you test from which exynos SoC?


I haven't the S2R case since it is broken in mainline for Exynos5420
(even with $subject applied) but $subject fixes for me the system
crash we have discussed before [0]. That is when mixer_poweron() tries
to access the mixer register without hdmi_poweron() enabling the
hdmi clock.

 Kukjin, if it is hw issue, do you know hw experts of exynos hdmi and
 could we get any advice?


It would be great if someone can shed some light on both issues.

 ---
  drivers/gpu/drm/exynos/exynos_hdmi.c | 17 +++--
  1 file changed, 11 insertions(+), 6 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
 b/drivers/gpu/drm/exynos/exynos_hdmi.c
 index 6aa0d65..7a473cb 100644
 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
 +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
 @@ -2064,9 +2064,6 @@ static void hdmi_poweron(struct exynos_drm_display 
 *display)
   regmap_update_bits(hdata-pmureg, PMU_HDMI_PHY_CONTROL,
   PMU_HDMI_PHY_ENABLE_BIT, 1);

 - clk_prepare_enable(res-hdmi);
 - clk_prepare_enable(res-sclk_hdmi);
 -
   hdmiphy_poweron(hdata);
   hdmi_commit(display);
  }
 @@ -2088,9 +2085,6 @@ static void hdmi_poweroff(struct exynos_drm_display 
 *display)

   cancel_delayed_work(hdata-hotplug_work);

 - clk_disable_unprepare(res-sclk_hdmi);
 - clk_disable_unprepare(res-hdmi);
 -
   /* reset pmu hdmiphy control bit to disable hdmiphy */
   regmap_update_bits(hdata-pmureg, PMU_HDMI_PHY_CONTROL,
   PMU_HDMI_PHY_ENABLE_BIT, 0);
 @@ -2254,6 +2248,14 @@ static int hdmi_resources_init(struct hdmi_context 
 *hdata)
   } else
   res-reg_hdmi_en = NULL;

 + /*
 +  * These two clocks are not moved into hdmi_poweron/off since system
 +  * fails to suspend if VPLL clock of 70.5 MHz is used and these
 +  * clocks are disabled before suspend. So enable them here.
 +  */
 + clk_prepare_enable(res-sclk_hdmi);
 + clk_prepare_enable(res-hdmi);
 +

 Then twe clocks are turned on always. I don't think it's reasonable.


Agreed that it would be better to gate/ungate the clocks as necessary
to reduce power consumption but OTOH is better to leave some clocks
enabled to avoid system crashes. Of course it would be even better to
understand the root cause and fix it.

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

Re: [PATCH v3 0/6] Add multiple GPIO and external clock to MMC pwrseq_simple

[Ulf Hansson]

On 29 January 2015 at 16:00, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 Hello Ulf,

 Many WLAN chips attached to an SDIO interface needs more than one GPIO
 for their reset sequence and also an external clock to be operational.

 Since this is very common, this series extend the simple MMC power sequence
 to support more than one reset GPIO and also an optional external clock.

 This is the third version of the series that addressed issues pointed out
 in the previous versions.

 The series depend on v4 mmc: core: Add support for MMC power sequences:

 http://comments.gmane.org/gmane.linux.kernel.mmc/30665

 Javier Martinez Canillas (6):
   mmc: pwrseq: Document that simple sequence support more than one GPIO
   mmc: pwrseq_simple: Extend to support more pins
   mmc: pwrseq: Document optional clock for the simple power sequence
   mmc: pwrseq_simple: Add optional reference clock support
   ARM: dts: exynos5250-snow: Enable wifi power-on
   ARM: dts: exynos5250-snow: Add cap-sdio-irq to wifi mmc node

  .../devicetree/bindings/mmc/mmc-pwrseq-simple.txt  | 11 ++-
  arch/arm/boot/dts/exynos5250-snow.dts  | 26 ++-
  drivers/mmc/core/pwrseq_simple.c   | 89 
 ++
  3 files changed, 107 insertions(+), 19 deletions(-)

 Patch #1 extends the simple MMC power sequence DT binding to support more
 than one GPIO and patch #2 adds the actual implementation.

 In the same way, patch #3 and #4 extend the simple MMC power sequence DT
 binding and pwrseq_simple driver to support an optional external clock.

 Finally as an example, patch #5 and patch #6 adds support for the wifi
 chip in the Exynos5250 Snow that needs all these resources. These two
 patches were added to the series only for completeness and should be
 picked by Kukjin through his linux-samsung tree.

 Best regards,
 Javier

Thanks Javier! I have applied patch 1 - 4 for my next branch.

I made some minor fix to patch4, I send a separate response to that
patch so you know.

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 v3 4/6] mmc: pwrseq_simple: Add optional reference clock support

[Ulf Hansson]

On 29 January 2015 at 16:00, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 Some WLAN chips attached to a SDIO interface, need a reference clock.

 Since this is very common, extend the prseq_simple driver to support
 an optional clock that is enabled prior the card power up procedure.

 Note: the external clock is optional. Thus an error is not returned
 if the clock is not found.

 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---

 Changes since v2:
  - Add a clk_enabled bool to struct mmc_pwrseq_simple to track clock
gate/ungate since .power_off can be called prior to .pre_power_on.
Suggested by Ulf Hansson.
  - clk_get() does not return -ENOSYS so don't check for that.
Suggested by Ulf Hansson.

 Changes since v1:
  - Rebase on top of latest changes.
  - Use IS_ERR() instead of checking for NULL to see if the clock exists.
 ---
  drivers/mmc/core/pwrseq_simple.c | 38 --
  1 file changed, 36 insertions(+), 2 deletions(-)

 diff --git a/drivers/mmc/core/pwrseq_simple.c 
 b/drivers/mmc/core/pwrseq_simple.c
 index e53d3c7e059c..50d09d920430 100644
 --- a/drivers/mmc/core/pwrseq_simple.c
 +++ b/drivers/mmc/core/pwrseq_simple.c
 @@ -7,6 +7,7 @@
   *
   *  Simple MMC power sequence management
   */
 +#include linux/clk.h
  #include linux/kernel.h
  #include linux/slab.h
  #include linux/device.h
 @@ -20,6 +21,8 @@

  struct mmc_pwrseq_simple {
 struct mmc_pwrseq pwrseq;
 +   bool clk_enabled;
 +   struct clk *ext_clk;
 int nr_gpios;
 struct gpio_desc *reset_gpios[0];
  };
 @@ -39,6 +42,11 @@ static void mmc_pwrseq_simple_pre_power_on(struct mmc_host 
 *host)
 struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
 struct mmc_pwrseq_simple, pwrseq);

 +   if (!IS_ERR(pwrseq-ext_clk)) {

This should be:

if (!IS_ERR(pwrseq-ext_clk)  !pwrseq-clk_enabled) {


 +   clk_prepare_enable(pwrseq-ext_clk);
 +   pwrseq-clk_enabled = true;
 +   }
 +
 mmc_pwrseq_simple_set_gpios_value(pwrseq, 1);
  }

 @@ -50,6 +58,19 @@ static void mmc_pwrseq_simple_post_power_on(struct 
 mmc_host *host)
 mmc_pwrseq_simple_set_gpios_value(pwrseq, 0);
  }

 +static void mmc_pwrseq_simple_power_off(struct mmc_host *host)
 +{
 +   struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
 +   struct mmc_pwrseq_simple, pwrseq);
 +
 +   mmc_pwrseq_simple_set_gpios_value(pwrseq, 1);
 +
 +   if (pwrseq-clk_enabled) {

I changed this as well, but that was just to make code clearer.

if (!IS_ERR(pwrseq-ext_clk)  pwrseq-clk_enabled) {


 +   clk_disable_unprepare(pwrseq-ext_clk);
 +   pwrseq-clk_enabled = false;
 +   }
 +}
 +
  static void mmc_pwrseq_simple_free(struct mmc_host *host)
  {
 struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
 @@ -60,6 +81,9 @@ static void mmc_pwrseq_simple_free(struct mmc_host *host)
 if (!IS_ERR(pwrseq-reset_gpios[i]))
 gpiod_put(pwrseq-reset_gpios[i]);

 +   if (!IS_ERR(pwrseq-ext_clk))
 +   clk_put(pwrseq-ext_clk);
 +
 kfree(pwrseq);
 host-pwrseq = NULL;
  }
 @@ -67,7 +91,7 @@ static void mmc_pwrseq_simple_free(struct mmc_host *host)
  static struct mmc_pwrseq_ops mmc_pwrseq_simple_ops = {
 .pre_power_on = mmc_pwrseq_simple_pre_power_on,
 .post_power_on = mmc_pwrseq_simple_post_power_on,
 -   .power_off = mmc_pwrseq_simple_pre_power_on,
 +   .power_off = mmc_pwrseq_simple_power_off,
 .free = mmc_pwrseq_simple_free,
  };

 @@ -85,6 +109,13 @@ int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct 
 device *dev)
 if (!pwrseq)
 return -ENOMEM;

 +   pwrseq-ext_clk = clk_get(dev, ext_clock);
 +   if (IS_ERR(pwrseq-ext_clk) 
 +   PTR_ERR(pwrseq-ext_clk) != -ENOENT) {
 +   ret = PTR_ERR(pwrseq-ext_clk);
 +   goto free;
 +   }
 +
 for (i = 0; i  nr_gpios; i++) {
 pwrseq-reset_gpios[i] = gpiod_get_index(dev, reset, i,
  GPIOD_OUT_HIGH);
 @@ -96,7 +127,7 @@ int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct 
 device *dev)
 while (--i)
 gpiod_put(pwrseq-reset_gpios[i]);

 -   goto free;
 +   goto clk_put;
 }
 }

 @@ -105,6 +136,9 @@ int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct 
 device *dev)
 host-pwrseq = pwrseq-pwrseq;

 return 0;
 +clk_put:
 +   if (!IS_ERR(pwrseq-ext_clk))
 +   clk_put(pwrseq-ext_clk);
  free:
 kfree(pwrseq);
 return ret;
 --
 2.1.3


As I stated in the response to he coverletter for the patchset, this
patch is applied for next with above changes.

[PATCH v2 1/4] ARM: EXYNOS: fix CPU1 hotplug for AFTR mode on Exynos3250

[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()
- using dsb_sev() instead of IPI in exynos_boot_secondary() on
  Exynos3250

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  | 23 ---
 arch/arm/mach-exynos/regs-pmu.h |  2 ++
 2 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 3f32c47..511b81a 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,10 @@ static void exynos_core_restart(u32 core_id)
if (!of_machine_is_compatible(samsung,exynos3250))
return;
 
+   while (!pmu_raw_readl(S5P_PMU_SPARE2))
+   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));
@@ -347,7 +361,10 @@ static int exynos_boot_secondary(unsigned int cpu, struct 
task_struct *idle)
 
call_firmware_op(cpu_boot, core_id);
 
-   arch_send_wakeup_ipi_mask(cpumask_of(cpu));
+   if (soc_is_exynos3250())
+   dsb_sev();
+   else
+   arch_send_wakeup_ipi_mask(cpumask_of(cpu));
 
if (pen_release == -1)
break;
diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
index eb461e1..84ddce1 100644
--- a/arch/arm/mach-exynos/regs-pmu.h
+++ b/arch/arm/mach-exynos/regs-pmu.h
@@ -49,6 +49,7 @@
 #define S5P_INFORM50x0814
 #define S5P_INFORM60x0818
 #define S5P_INFORM70x081C
+#define S5P_PMU_SPARE2 0x0908
 #define S5P_PMU_SPARE3 0x090C
 
 #define EXYNOS_IROM_DATA2  0x0988
@@ -182,6 +183,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 v2 2/4] ARM: EXYNOS: add code for setting/clearing boot flag

[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 f70eca7..87bf1f3 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 2013f73..c599a0f 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -117,6 +117,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 v2 0/4] ARM: EXYNOS: cpuidle: add AFTR mode support for Exynos3250

[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 (commit: ce275c369a0b) of linux-samsung.git
  kernel tree

Changes since v1:
- rebased on top of for-next branch (commit: ce275c369a0b) of
  linux-samsung.git kernel tree
- fixed lockup on hotplug by using dsb_sev() instead of IPI in
  exynos_boot_secondary() on Exynos3250

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  | 23 ---
 arch/arm/mach-exynos/pm.c   | 12 +++-
 arch/arm/mach-exynos/regs-pmu.h |  3 +++
 arch/arm/mach-exynos/smc.h  |  9 +
 7 files changed, 82 insertions(+), 5 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: [PATCH v3 4/6] mmc: pwrseq_simple: Add optional reference clock support

[Javier Martinez Canillas]

Hello Ulf,

On 01/30/2015 12:17 PM, Ulf Hansson wrote:
  };
 @@ -39,6 +42,11 @@ static void mmc_pwrseq_simple_pre_power_on(struct 
 mmc_host *host)
 struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
 struct mmc_pwrseq_simple, pwrseq);

 +   if (!IS_ERR(pwrseq-ext_clk)) {
 
 This should be:
 
 if (!IS_ERR(pwrseq-ext_clk)  !pwrseq-clk_enabled) {
 


Oh, I thought that it was not possible to enter mmc_pwrseq_pre_power_on()
twice without a prior call to mmc_pwrseq_power_off() but I guess I didn't
read the MMC core code carefully...
 
 +   clk_prepare_enable(pwrseq-ext_clk);
 +   pwrseq-clk_enabled = true;
 +   }
 +
 mmc_pwrseq_simple_set_gpios_value(pwrseq, 1);
  }

 @@ -50,6 +58,19 @@ static void mmc_pwrseq_simple_post_power_on(struct 
 mmc_host *host)
 mmc_pwrseq_simple_set_gpios_value(pwrseq, 0);
  }

 +static void mmc_pwrseq_simple_power_off(struct mmc_host *host)
 +{
 +   struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
 +   struct mmc_pwrseq_simple, pwrseq);
 +
 +   mmc_pwrseq_simple_set_gpios_value(pwrseq, 1);
 +
 +   if (pwrseq-clk_enabled) {
 
 I changed this as well, but that was just to make code clearer.
 
 if (!IS_ERR(pwrseq-ext_clk)  pwrseq-clk_enabled) {
 


Yeah, if IS_ERR(pwrseq-ext_clk) then clk_enabled will always be false but I
agree that the change makes the code to be more consistent.


 
 As I stated in the response to he coverletter for the patchset, this
 patch is applied for next with above changes.
 
 Thanks!


Thanks a lot for your help and for fixing these things!

 Kind regards
 Uffe


Best regards,
Javier

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

Re: [PATCH v3 0/6] Add multiple GPIO and external clock to MMC pwrseq_simple

[Javier Martinez Canillas]

Hello Ulf,

On 01/30/2015 12:13 PM, Ulf Hansson wrote:

 Patch #1 extends the simple MMC power sequence DT binding to support more
 than one GPIO and patch #2 adds the actual implementation.

 In the same way, patch #3 and #4 extend the simple MMC power sequence DT
 binding and pwrseq_simple driver to support an optional external clock.

 Finally as an example, patch #5 and patch #6 adds support for the wifi
 chip in the Exynos5250 Snow that needs all these resources. These two
 patches were added to the series only for completeness and should be
 picked by Kukjin through his linux-samsung tree.

 Best regards,
 Javier
 
 Thanks Javier! I have applied patch 1 - 4 for my next branch.
 
 I made some minor fix to patch4, I send a separate response to that
 patch so you know.


Great, thanks a lot!

Kukjin,

Could you please pick patches #5 and #6 then now that Ulf picked the others?
 
 Kind regards
 Uffe
 

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/6] drm/exynos: remove leftover code using event_list

[Gustavo Padovan]

2015-01-30 Joonyoung Shim jy0922.s...@samsung.com:

 +Cc Inki,
 
 Hi,
 
 On 01/23/2015 09:42 PM, Gustavo Padovan wrote:
  From: Gustavo Padovan gustavo.pado...@collabora.co.uk
  
  The drm_file event_list hasn't been used anymore by exynos, so we don't
  need any code to clean it.
  
 
 No, it is used from drm core e.g. drm_irq.c file.

You are right, I'll drop this patch.

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

Re: [PATCH v4 3/7] misc: Add cros_ec_lpc driver for x86 devices

[Javier Martinez Canillas]

Hello Paul,

Thanks a lot for your feedback.

On 01/29/2015 10:11 PM, Paul Bolle wrote:
  
 +config CROS_EC_LPC
 +tristate ChromeOS Embedded Controller (LPC)
 +depends on MFD_CROS_EC
 +
 
 Please drop this empty line.


Ok.
 
 +help
 +  If you say Y here, you get support for talking to the ChromeOS EC
 +  over an LPC bus. This uses a simple byte-level protocol with a
 +  checksum. This is used for userspace access only. The kernel
 +  typically has its own communication methods.
 +
 
 What happens when you say M?
 

Since it is a tristate kconfig symbol, it can be built as a kernel module
but since there isn't a LPC subsystem, the platform device is registered
in the module_init() function. So, building as a module is trickier since
there won't be an uevent that can trigger a module auto-load based on the
modinfo aliases information.

One can of course force udev to load the module by adding to modules.conf
or such but I wonder if is better to change from tristate to boolean or
add to the help that it can be built as a module but auto-load does not
work in that case.

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

[PATCH v2 3/4] ARM: EXYNOS: cpuidle: add AFTR mode support for Exynos3250

[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 e6209da..0a7e3af 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -127,6 +127,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)
@@ -140,7 +142,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);
 
@@ -157,8 +159,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();
 
if (of_machine_is_compatible(samsung,exynos4212) ||
@@ -178,6 +185,9 @@ 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 84ddce1..b761433 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 v2 4/4] ARM: EXYNOS: cpuidle: allow driver usage on Exynos3250 SoC

[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 c599a0f..2652024 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -244,6 +244,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

Re: [PATCH 1/4] mmc: core: add support for hardware reset gpio line

[Ulf Hansson]

On 30 January 2015 at 11:37, Marek Szyprowski m.szyprow...@samsung.com wrote:
 Hello,

 On 2015-01-29 11:56, Javier Martinez Canillas wrote:

 On Thu, Jan 29, 2015 at 10:15 AM, Marek Szyprowski
 m.szyprow...@samsung.com wrote:

 Also, I wonder whether we could extend the mmc-pwrseq to cover your
 case? Did you consider that as an option?


 I didn't consider mmc-pwrseq yet. For me it looked straightforward to

 I agree with Ulf that using mmc-pwrseq would be a good solution and in
 fact I think the pwrseq_simple [0] driver will fit your use case since
 it supports a reset GPIO pin which is what many WLAN chips attached to
 a SDIO interface use.


 Ok, I've checked mmc-prwseq and mmc-pwrseq-simple. I also checked the
 hardware and it mmc-pwrseq-simple cannot be used directly.

 Although the signal is called RSTN (on Odroid U3 schema), the eMMC card
 gets resetted not on low line level, but during the rising edge. This RSTN
 line is also pulled up by the external resistor. However, the strangest
 thing is the fact that the default SoC configuration (which is applied
 during hw reset) for this GPIO line is input, pulled-down. The SoC
 internal pull-down is stronger than the external pull up, so in the end,
 during the SoC reboot the RSTN signal is set to zero. Later bootloader
 disables the internal pull-down.

 To sum up - to perform proper reboot on Odroid U3/XU3, one need to set
 RSTN to zero, wait a while and the set it back to 1.

 To achieve this with mmc-pwrseq-simple, I would need to modify the power_off
 callback to toggle reset line to zero and back to one. This however might
 not be desired to other sd/mmc cards used with mmc-pwrseq-simple.

 I can also provide separate mmc-pwrsrq-odroid driver, which will be very
 similar to mmc-pwrseq-simple.

 Ulf - which approach would you prefer?

To me this seems like a quite generic eMMC hw-reset thing, thus we
should maybe add a new pwrseq driver for it.

In principle you need to toogle a GPIO in the -pre_power_on()
callback, right? And you are also proposing to register a restart
handler from the -alloc() callback!?

I suppose this should work nicely.

Kind regards
Uffe




 implement
 it just like card detect or write-protection gpio pins. I already noticed
 that
 there is code for some mmc host driver, which perform mmc hardware reset.
 If
 you
 think that extending pwrseq is the better approach, I will try to update
 my
 patches. This will add reboot handler to mmc-pwrseq then. The only
 question
 is

 I don't think that adding a reboot handler to mmc-pwrseq is needed.
 AFAICT the call chain is:

 sys_reboot() - kernel_restart() - device_shutdown() -
 mmc_bus_shutdown() - _mmc_suspend() - mmc_power_off() -
 mmc_pwrseq_power_off() - struct mmc_pwrseq_ops .power_off

 So since the pwrseq_simple already asserts the reset GPIO in
 .power_off, it should be enough to ensure the eMMC will be reset to
 its default configuration for the iROM to work properly.

 It also asserts the GPIO pin in .pre_power_on and de-asserts in
 .post_power_on which should be needed as well for the other case you
 mentioned when a broken bootloader left the emmc card in some unknown
 state.


 emergency_restart() doesn't call device_shutdown(), so I think it still
 makes
 sense to add real reset handler to mmc-pwrseq to ensure that power_off will
 be called even during emergency_restart().


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

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

Re: [PATCH V9 12/14] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge

[Thierry Reding]

On Thu, Jan 29, 2015 at 08:12:20PM +0530, Ajay kumar wrote:
 Hi Thierry,
 
 I think you forgot to take this patch!
 Can you check this?

Yes, I missed it somehow. It didn't build for me after applying it now,
but I fixed that up (and a few sparse warnings along with it). I'll send
out another pull request shortly.

Thierry


pgpRXBmwWcgjN.pgp
Description: PGP signature

Re: [PATCH 1/4] mmc: core: add support for hardware reset gpio line

[Sjoerd Simons]

On Fri, 2015-01-30 at 11:37 +0100, Marek Szyprowski wrote:
 Hello,
 
 On 2015-01-29 11:56, Javier Martinez Canillas wrote:
  On Thu, Jan 29, 2015 at 10:15 AM, Marek Szyprowski
  m.szyprow...@samsung.com wrote:
  Also, I wonder whether we could extend the mmc-pwrseq to cover your
  case? Did you consider that as an option?
 
  I didn't consider mmc-pwrseq yet. For me it looked straightforward to
  I agree with Ulf that using mmc-pwrseq would be a good solution and in
  fact I think the pwrseq_simple [0] driver will fit your use case since
  it supports a reset GPIO pin which is what many WLAN chips attached to
  a SDIO interface use.
 
 Ok, I've checked mmc-prwseq and mmc-pwrseq-simple. I also checked the
 hardware and it mmc-pwrseq-simple cannot be used directly.
 
 Although the signal is called RSTN (on Odroid U3 schema), the eMMC card
 gets resetted not on low line level, but during the rising edge. This RSTN
 line is also pulled up by the external resistor. However, the strangest
 thing is the fact that the default SoC configuration (which is applied
 during hw reset) for this GPIO line is input, pulled-down. The SoC
 internal pull-down is stronger than the external pull up, so in the end,
 during the SoC reboot the RSTN signal is set to zero. Later bootloader
 disables the internal pull-down.
 
 To sum up - to perform proper reboot on Odroid U3/XU3, one need to set
 RSTN to zero, wait a while and the set it back to 1.

 To achieve this with mmc-pwrseq-simple, I would need to modify the power_off
 callback to toggle reset line to zero and back to one. This however might
 not be desired to other sd/mmc cards used with mmc-pwrseq-simple.
 
 I can also provide separate mmc-pwrsrq-odroid driver, which will be very
 similar to mmc-pwrseq-simple.

Apart from the initial odd setup of the SoC pins this is the standard
H/W reset operation specified by Jedec 4.4:

* pull the reset line down for at least 1us
* pull the line up again
* Wait at least 200us before sending commands

(sdhci_pci_int_hw_reset also implements this).

I'm not sure what the determining factor is for a pwrseq driver vs. it
being part of the mmc core would be. But if you do a pwrseq driver it
shouldn't be board specific e.g. call it mmc-pwrseq-emmc4.4 instead of
-odroid?


-- 
Sjoerd Simons sjoerd.sim...@collabora.co.uk
Collabora Ltd.


smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH 02/15] iommu: Introduce iommu domain types

[Joerg Roedel]

Hi Will,

On Wed, Jan 28, 2015 at 02:19:34PM +, Will Deacon wrote:
  +/* This are the possible domain-types */
  +enum iommu_domain_type {
  +   IOMMU_DOMAIN_DMA,   /* Domain used for DMA-API */
  +   IOMMU_DOMAIN_IDENTITY,  /* Identity mapped domain  */
 
 What happens if somebody calls map or unmap on an identity-mapping domain?
 Can we catch that in the IOMMU core before calling the IOMMU driver? That
 also implies we need something extra to parameterise the attributes for
 the mapping (e.g. cacheable, read-only) and also potentially the address
 range.

The domain type is only used by the IOMMU drivers to do be able to enter
special allocation paths (the AMD-Vi driver for example could allocate a
special internal domain type for IOMMU_DOMAIN_DMA).
But I think you are right, a couple of the current domain attributes we
have could be moved here, turning the domain-type into a bit-field. So
we could have bits for PAGING, CACHABLE, DMA_API and NESTING and build
the domain types above from those bits.

  +   IOMMU_DOMAIN_UNMANAGED, /* Domain mappings are managed by a third party
  +  user (like KVM or VFIO) */
 
 We already have the domain attributes (iommu_attr) to describe features
 of a domain. Is there really a need for this extra type, or can we extend
 the attribute set and allow for domain allocation with attributes?

I don't think that domains attributed will become obsolete with this
domain-type field. Some of the attributes should stay there for now,
like all the PAMU specific stuff. But I agree, some could be moved over.


Joerg

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