[PATCH] ARM: Exynos: remove arm diagnostic and power register save/restore code

[Chander Kashyap]

As save/restore of arm diagnostic and power registers is handled by
generic code, so remove the same.

Signed-off-by: Chander Kashyap k.chan...@samsung.com
---
 arch/arm/mach-exynos/pm.c |   54 ++---
 1 file changed, 2 insertions(+), 52 deletions(-)

diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 18646b7..af99c55 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -134,45 +134,6 @@ void exynos_enter_aftr(void)
exynos_sys_powerdown_conf(SYS_AFTR);
 }
 
-/* For Cortex-A9 Diagnostic and Power control register */
-static unsigned int save_arm_register[2];
-
-static void exynos_cpu_save_register(void)
-{
-   unsigned long tmp;
-
-   /* Save Power control register */
-   asm (mrc p15, 0, %0, c15, c0, 0
-: =r (tmp) : : cc);
-
-   save_arm_register[0] = tmp;
-
-   /* Save Diagnostic register */
-   asm (mrc p15, 0, %0, c15, c0, 1
-: =r (tmp) : : cc);
-
-   save_arm_register[1] = tmp;
-}
-
-static void exynos_cpu_restore_register(void)
-{
-   unsigned long tmp;
-
-   /* Restore Power control register */
-   tmp = save_arm_register[0];
-
-   asm volatile (mcr p15, 0, %0, c15, c0, 0
- : : r (tmp)
- : cc);
-
-   /* Restore Diagnostic register */
-   tmp = save_arm_register[1];
-
-   asm volatile (mcr p15, 0, %0, c15, c0, 1
- : : r (tmp)
- : cc);
-}
-
 static int exynos_cpu_suspend(unsigned long arg)
 {
 #ifdef CONFIG_CACHE_L2X0
@@ -238,9 +199,6 @@ static int exynos_pm_suspend(void)
tmp = (S5P_USE_STANDBY_WFI0 | S5P_USE_STANDBY_WFE0);
pmu_raw_writel(tmp, S5P_CENTRAL_SEQ_OPTION);
 
-   if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9)
-   exynos_cpu_save_register();
-
return 0;
 }
 
@@ -272,9 +230,6 @@ static void exynos_pm_resume(void)
if (exynos_pm_central_resume())
goto early_wakeup;
 
-   if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9)
-   exynos_cpu_restore_register();
-
/* For release retention */
 
pmu_raw_writel((1  28), S5P_PAD_RET_MAUDIO_OPTION);
@@ -376,19 +331,14 @@ static int exynos_cpu_pm_notifier(struct notifier_block 
*self,
 
switch (cmd) {
case CPU_PM_ENTER:
-   if (cpu == 0) {
+   if (cpu == 0)
exynos_pm_central_suspend();
-   if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9)
-   exynos_cpu_save_register();
-   }
break;
 
case CPU_PM_EXIT:
if (cpu == 0) {
-   if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) {
+   if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9)
scu_enable(S5P_VA_SCU);
-   exynos_cpu_restore_register();
-   }
exynos_pm_central_resume();
}
break;
-- 
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: [GIT PULL 3/5] Samsung exynos cpuidle update for v3.17

[Chander M. Kashyap]

Hi Kukjin,

On Sat, Aug 9, 2014 at 6:05 AM, Kukjin Kim kgene@samsung.com wrote:
 Kevin Hilman wrote:

 Hello,

 Hi,

 On Fri, Jul 18, 2014 at 5:52 PM, Kukjin Kim kgene@samsung.com wrote:
  The following changes since commit 
  1795cd9b3a91d4b5473c97f491d63892442212ab:
 
Linux 3.16-rc5 (2014-07-13 14:04:33 -0700)
 
  are available in the git repository at:
 
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
  tags/exynos-cpuidle
 
  for you to fetch changes up to fc2cac41ebbfb16da8b036cba6ec6714ab780a6d:
 
ARM: EXYNOS: populate suspend and powered_up callbacks for mcpm
  (2014-07-19 03:36:00 +0900)
 
  
  exynos cpuidle update for v3.17
 
  - add callbacks exynos_suspend() and exynos_powered_up()
for support cpuidle through mcpm
  - skip exynos_cpuidle for exynos5420 because is uses
cpuidle-big-liggle generic cpuidle driver
  - add generic functions to calculate cpu number is used
for pmu and this is required for exynos5420 multi-cluster
  - add of_device_id structure for big.LITTLE cpuidle and
add samsung,exynos5420 compatible string for exynos5420

 I'm curious what platforms this is expected to work on, and where it's
 been tested.

 exynos5420 and its reference board, smdk5420.

 I tried it on exynos5800-peach-pi (chromebook2) and it hangs up (no
 kernel messages) shortly after the driver loads, and never finishes to
 boot.

 Oh, sorry about that, if so, it should be fixed before -rc1. Just note that I
 thought since exynos5800 is very similar with exynos5420 so I didn't ask
 Chander to test the series on exynos5800 based board...Just asked to test with
 Nico's mcpm series. BTW, unfortunately I have no exynos5800-peach-pi...

 I needed an extra compatible entry for the 5800 in the driver for the
 driver to load, which suggests it hasn't been tested on 5800, but at
 least in theory, this should be compatible with the 542x, right?

 Yes I think so. As you can see in exynos5800.dtsi, it is including exynos5420.

 For testing, I tried today's linux-next and arm-soc/for-next.

 Hmm...why is the problem happened at last? Not at that time? :(

Patch has been sent for the same:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/270472.html

This patch has been dropped as Tomasz has sent the fix in his patch.

Below is the link for the patch:

https://lkml.org/lkml/2014/8/1/103

which is yet to be merged.



 I need to figure it out...

 Thanks,
 Kukjin


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



-- 
thanks and regards,
Chander M. Kashyap
Contact Number: +918123738320
--- TENSION LENE KA NAHI, DENE KE-
--
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 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Inki Dae]

On 2014년 08월 08일 18:40, Andrzej Hajda wrote:
 On 08/08/2014 11:02 AM, Andrzej Hajda wrote:
 On 08/08/2014 09:37 AM, Inki Dae wrote:
 On 2014년 08월 08일 16:03, Thierry Reding wrote:
 On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
 On 2014년 08월 07일 22:55, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
 On 2014년 08월 07일 22:17, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
 On 2014년 08월 07일 20:09, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
 On 2014년 08월 07일 18:09, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
 On 2014년 08월 07일 15:58, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
 2014-08-06 16:43 GMT+09:00 Thierry Reding 
 thierry.red...@gmail.com:
 [...]
 As far as I can tell non-continuous mode simply means that the 
 host can
 turn off the HS clock after a high-speed transmission. I think 
 Andrzej
 mentioned this already in another subthread, but this is an 
 optional
 mode that peripherals can support if they have extra circuitry 
 that
 provides an internal clock. Peripherals that don't have such 
 circuitry
 may rely on the HS clock to perform in between transmissions 
 and
 therefore require the HS clock to be always on (continuous 
 mode). That's
 what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises 
 that the
 peripheral supports non-continuous mode and therefore the host 
 can turn
 the HS clock off after high-speed transmissions.
 What I don't make sure is this sentence. With
 MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible 
 operations.
 One is,
 1. host controller will generates signals if a bit of a register
 related to non-contiguous clock mode is set or unset.
 2. And then video data is transmitted to panel in HS mode.
 3. And then D-PHY detects LP-11 signal (positive and negative 
 lane all
 are high).
 4. And then D-PHY disables HS clock of host controller.
 5. At this time, operation mode of host controller becomes LPM.

 Other is,
 1. host controller will generates signals if a bit of a register
 related to non-contiguous clock mode is set or unset.
 2. And then D-PHY detects LP-11 signal (positive and negative 
 lane all
 are high).
 3. And then video data is transmitted to panel in LPM.
 4. At this time, operation mode of host controller becomes LPM.

 It seems that you says latter case.
 No. High speed clock and low power mode are orthogonal. 
 Non-continuous
 mode simply means that the clock lane enters LP-11 between HS
 transmissions (see 5.6 Clock Management of the DSI 
 specification).

 It seems that clock lane enters LP-11 regardless of HS clock 
 enabled if
 non-continous mode is used. Right?
 No, I think as long as HS clock is enabled the clock lane won't 
 enter
 LP-11. Non-continuous mode means that the controller can disable 
 the HS
 clock between HS transmissions. So in non-continuous mode the 
 clock lane
 can enter LP-11 because the controller disables the HS clock.
 It makes me a little bit confusing. You said if HS clock is 
 enabled,
 the the clock lane won't enter LP-11 But you said again the clock 
 lane
 can enter LP-11 because the controller disables the HS clock What 
 is
 the meaning?
 It means that if the HS clock is enabled, then the clock lane is not 
 in
 LP-11. When the HS clock stops, then the clock lane enters LP-11.

 In continuous mode, then the clock will never be disabled, hence 
 the
 clock lane will never enter LP-11.

 And also it seems that non-continous mode is different from LPM 
 at all
 because with non-continuous mode, command data is transmitted to 
 panel
 in HS mode, but with LPM, command data is transmitted to panel in 
 LP
 mode. Also right?
 No. I think you can send command data to the peripheral in low 
 power
 mode in both continuous and non-continuous clock modes.

 If so, shouldn't the host driver disable HS clock, in case of LP 
 mode,
 before the host driver transmits command data?
 No. If the peripheral doesn't support non-continuous mode, then 
 the HS
 clock must never be turned off. On the other hand, if the 
 peripheral
 supports non-continuous mode, then the DSI host should 
 automatically
 disable the HS clock between high-speed transmissions. That means 
 if a
 packet is transmitted in low power mode the DSI host will not be
 transmitting in high-speed mode and therefore disable the HS clock.
 What is LPM you think? I thought LPM is LP-11 and HS clock 
 disabled. So
 for LPM transfer, lanes should be LP-11 state and also HS clock of 
 the
 host controller should be disabled.
 No. I don't think any transmissions can happen when all lanes are in
 LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a 
 packet
 should be transmitted in low power mode (see LP Transmission in 2.1
 Definitions of the MIPI DSI specification).

 Hm.. I see. I meant,

 if (flags  MIPI_DSI_MSG_USE_LPM)
disable HS clock - required.

 

Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Thierry Reding]

On Mon, Aug 11, 2014 at 02:19:21PM +0900, Inki Dae wrote:
 On 2014년 08월 08일 18:55, Thierry Reding wrote:
  On Fri, Aug 08, 2014 at 04:37:07PM +0900, Inki Dae wrote:
  On 2014년 08월 08일 16:03, Thierry Reding wrote:
  On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
  On 2014년 08월 07일 22:55, Thierry Reding wrote:
  On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
  On 2014년 08월 07일 22:17, Thierry Reding wrote:
  On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
  On 2014년 08월 07일 20:09, Thierry Reding wrote:
  On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
  On 2014년 08월 07일 18:09, Thierry Reding wrote:
  On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
  On 2014년 08월 07일 15:58, Thierry Reding wrote:
  On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
  2014-08-06 16:43 GMT+09:00 Thierry Reding 
  thierry.red...@gmail.com:
  [...]
  As far as I can tell non-continuous mode simply means that 
  the host can
  turn off the HS clock after a high-speed transmission. I 
  think Andrzej
  mentioned this already in another subthread, but this is an 
  optional
  mode that peripherals can support if they have extra 
  circuitry that
  provides an internal clock. Peripherals that don't have such 
  circuitry
  may rely on the HS clock to perform in between transmissions 
  and
  therefore require the HS clock to be always on (continuous 
  mode). That's
  what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises 
  that the
  peripheral supports non-continuous mode and therefore the 
  host can turn
  the HS clock off after high-speed transmissions.
 
  What I don't make sure is this sentence. With
  MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible 
  operations.
  One is,
  1. host controller will generates signals if a bit of a 
  register
  related to non-contiguous clock mode is set or unset.
  2. And then video data is transmitted to panel in HS mode.
  3. And then D-PHY detects LP-11 signal (positive and negative 
  lane all
  are high).
  4. And then D-PHY disables HS clock of host controller.
  5. At this time, operation mode of host controller becomes LPM.
 
  Other is,
  1. host controller will generates signals if a bit of a 
  register
  related to non-contiguous clock mode is set or unset.
  2. And then D-PHY detects LP-11 signal (positive and negative 
  lane all
  are high).
  3. And then video data is transmitted to panel in LPM.
  4. At this time, operation mode of host controller becomes LPM.
 
  It seems that you says latter case.
 
  No. High speed clock and low power mode are orthogonal. 
  Non-continuous
  mode simply means that the clock lane enters LP-11 between HS
  transmissions (see 5.6 Clock Management of the DSI 
  specification).
 
 
  It seems that clock lane enters LP-11 regardless of HS clock 
  enabled if
  non-continous mode is used. Right?
 
  No, I think as long as HS clock is enabled the clock lane won't 
  enter
  LP-11. Non-continuous mode means that the controller can disable 
  the HS
  clock between HS transmissions. So in non-continuous mode the 
  clock lane
  can enter LP-11 because the controller disables the HS clock.
 
  It makes me a little bit confusing. You said if HS clock is 
  enabled,
  the the clock lane won't enter LP-11 But you said again the 
  clock lane
  can enter LP-11 because the controller disables the HS clock What 
  is
  the meaning?
 
  It means that if the HS clock is enabled, then the clock lane is 
  not in
  LP-11. When the HS clock stops, then the clock lane enters LP-11.
 
  In continuous mode, then the clock will never be disabled, hence 
  the
  clock lane will never enter LP-11.
 
  And also it seems that non-continous mode is different from LPM 
  at all
  because with non-continuous mode, command data is transmitted to 
  panel
  in HS mode, but with LPM, command data is transmitted to panel 
  in LP
  mode. Also right?
 
  No. I think you can send command data to the peripheral in low 
  power
  mode in both continuous and non-continuous clock modes.
 
  If so, shouldn't the host driver disable HS clock, in case of LP 
  mode,
  before the host driver transmits command data?
 
  No. If the peripheral doesn't support non-continuous mode, then 
  the HS
  clock must never be turned off. On the other hand, if the 
  peripheral
  supports non-continuous mode, then the DSI host should 
  automatically
  disable the HS clock between high-speed transmissions. That means 
  if a
  packet is transmitted in low power mode the DSI host will not be
  transmitting in high-speed mode and therefore disable the HS 
  clock.
 
  What is LPM you think? I thought LPM is LP-11 and HS clock 
  disabled. So
  for LPM transfer, lanes should be LP-11 state and also HS clock of 
  the
  host controller should be disabled.
 
  No. I don't think any transmissions can happen when all lanes are in
  LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a 
  packet
  should be transmitted in 

Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Inki Dae]

On 2014년 08월 11일 16:24, Thierry Reding wrote:
 On Mon, Aug 11, 2014 at 02:19:21PM +0900, Inki Dae wrote:
 On 2014년 08월 08일 18:55, Thierry Reding wrote:
 On Fri, Aug 08, 2014 at 04:37:07PM +0900, Inki Dae wrote:
 On 2014년 08월 08일 16:03, Thierry Reding wrote:
 On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
 On 2014년 08월 07일 22:55, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
 On 2014년 08월 07일 22:17, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
 On 2014년 08월 07일 20:09, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
 On 2014년 08월 07일 18:09, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
 On 2014년 08월 07일 15:58, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
 2014-08-06 16:43 GMT+09:00 Thierry Reding 
 thierry.red...@gmail.com:
 [...]
 As far as I can tell non-continuous mode simply means that 
 the host can
 turn off the HS clock after a high-speed transmission. I 
 think Andrzej
 mentioned this already in another subthread, but this is an 
 optional
 mode that peripherals can support if they have extra 
 circuitry that
 provides an internal clock. Peripherals that don't have such 
 circuitry
 may rely on the HS clock to perform in between transmissions 
 and
 therefore require the HS clock to be always on (continuous 
 mode). That's
 what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises 
 that the
 peripheral supports non-continuous mode and therefore the 
 host can turn
 the HS clock off after high-speed transmissions.

 What I don't make sure is this sentence. With
 MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible 
 operations.
 One is,
 1. host controller will generates signals if a bit of a 
 register
 related to non-contiguous clock mode is set or unset.
 2. And then video data is transmitted to panel in HS mode.
 3. And then D-PHY detects LP-11 signal (positive and negative 
 lane all
 are high).
 4. And then D-PHY disables HS clock of host controller.
 5. At this time, operation mode of host controller becomes LPM.

 Other is,
 1. host controller will generates signals if a bit of a 
 register
 related to non-contiguous clock mode is set or unset.
 2. And then D-PHY detects LP-11 signal (positive and negative 
 lane all
 are high).
 3. And then video data is transmitted to panel in LPM.
 4. At this time, operation mode of host controller becomes LPM.

 It seems that you says latter case.

 No. High speed clock and low power mode are orthogonal. 
 Non-continuous
 mode simply means that the clock lane enters LP-11 between HS
 transmissions (see 5.6 Clock Management of the DSI 
 specification).


 It seems that clock lane enters LP-11 regardless of HS clock 
 enabled if
 non-continous mode is used. Right?

 No, I think as long as HS clock is enabled the clock lane won't 
 enter
 LP-11. Non-continuous mode means that the controller can disable 
 the HS
 clock between HS transmissions. So in non-continuous mode the 
 clock lane
 can enter LP-11 because the controller disables the HS clock.

 It makes me a little bit confusing. You said if HS clock is 
 enabled,
 the the clock lane won't enter LP-11 But you said again the 
 clock lane
 can enter LP-11 because the controller disables the HS clock What 
 is
 the meaning?

 It means that if the HS clock is enabled, then the clock lane is 
 not in
 LP-11. When the HS clock stops, then the clock lane enters LP-11.

 In continuous mode, then the clock will never be disabled, hence 
 the
 clock lane will never enter LP-11.

 And also it seems that non-continous mode is different from LPM 
 at all
 because with non-continuous mode, command data is transmitted to 
 panel
 in HS mode, but with LPM, command data is transmitted to panel 
 in LP
 mode. Also right?

 No. I think you can send command data to the peripheral in low 
 power
 mode in both continuous and non-continuous clock modes.

 If so, shouldn't the host driver disable HS clock, in case of LP 
 mode,
 before the host driver transmits command data?

 No. If the peripheral doesn't support non-continuous mode, then 
 the HS
 clock must never be turned off. On the other hand, if the 
 peripheral
 supports non-continuous mode, then the DSI host should 
 automatically
 disable the HS clock between high-speed transmissions. That means 
 if a
 packet is transmitted in low power mode the DSI host will not be
 transmitting in high-speed mode and therefore disable the HS 
 clock.

 What is LPM you think? I thought LPM is LP-11 and HS clock 
 disabled. So
 for LPM transfer, lanes should be LP-11 state and also HS clock of 
 the
 host controller should be disabled.

 No. I don't think any transmissions can happen when all lanes are in
 LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a 
 packet
 should be transmitted in low power mode (see LP Transmission in 2.1
 Definitions of the MIPI DSI specification).


 

Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Andrzej Hajda]

On 08/11/2014 09:09 AM, Inki Dae wrote:
 On 2014년 08월 08일 18:40, Andrzej Hajda wrote:
 On 08/08/2014 11:02 AM, Andrzej Hajda wrote:
 On 08/08/2014 09:37 AM, Inki Dae wrote:
 On 2014년 08월 08일 16:03, Thierry Reding wrote:
 On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
 On 2014년 08월 07일 22:55, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
 On 2014년 08월 07일 22:17, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
 On 2014년 08월 07일 20:09, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
 On 2014년 08월 07일 18:09, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
 On 2014년 08월 07일 15:58, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
 2014-08-06 16:43 GMT+09:00 Thierry Reding 
 thierry.red...@gmail.com:
 [...]
 As far as I can tell non-continuous mode simply means that 
 the host can
 turn off the HS clock after a high-speed transmission. I 
 think Andrzej
 mentioned this already in another subthread, but this is an 
 optional
 mode that peripherals can support if they have extra 
 circuitry that
 provides an internal clock. Peripherals that don't have such 
 circuitry
 may rely on the HS clock to perform in between transmissions 
 and
 therefore require the HS clock to be always on (continuous 
 mode). That's
 what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it advertises 
 that the
 peripheral supports non-continuous mode and therefore the 
 host can turn
 the HS clock off after high-speed transmissions.
 What I don't make sure is this sentence. With
 MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible 
 operations.
 One is,
 1. host controller will generates signals if a bit of a 
 register
 related to non-contiguous clock mode is set or unset.
 2. And then video data is transmitted to panel in HS mode.
 3. And then D-PHY detects LP-11 signal (positive and negative 
 lane all
 are high).
 4. And then D-PHY disables HS clock of host controller.
 5. At this time, operation mode of host controller becomes LPM.

 Other is,
 1. host controller will generates signals if a bit of a 
 register
 related to non-contiguous clock mode is set or unset.
 2. And then D-PHY detects LP-11 signal (positive and negative 
 lane all
 are high).
 3. And then video data is transmitted to panel in LPM.
 4. At this time, operation mode of host controller becomes LPM.

 It seems that you says latter case.
 No. High speed clock and low power mode are orthogonal. 
 Non-continuous
 mode simply means that the clock lane enters LP-11 between HS
 transmissions (see 5.6 Clock Management of the DSI 
 specification).

 It seems that clock lane enters LP-11 regardless of HS clock 
 enabled if
 non-continous mode is used. Right?
 No, I think as long as HS clock is enabled the clock lane won't 
 enter
 LP-11. Non-continuous mode means that the controller can disable 
 the HS
 clock between HS transmissions. So in non-continuous mode the 
 clock lane
 can enter LP-11 because the controller disables the HS clock.
 It makes me a little bit confusing. You said if HS clock is 
 enabled,
 the the clock lane won't enter LP-11 But you said again the 
 clock lane
 can enter LP-11 because the controller disables the HS clock What 
 is
 the meaning?
 It means that if the HS clock is enabled, then the clock lane is 
 not in
 LP-11. When the HS clock stops, then the clock lane enters LP-11.

 In continuous mode, then the clock will never be disabled, hence 
 the
 clock lane will never enter LP-11.

 And also it seems that non-continous mode is different from LPM 
 at all
 because with non-continuous mode, command data is transmitted to 
 panel
 in HS mode, but with LPM, command data is transmitted to panel 
 in LP
 mode. Also right?
 No. I think you can send command data to the peripheral in low 
 power
 mode in both continuous and non-continuous clock modes.

 If so, shouldn't the host driver disable HS clock, in case of LP 
 mode,
 before the host driver transmits command data?
 No. If the peripheral doesn't support non-continuous mode, then 
 the HS
 clock must never be turned off. On the other hand, if the 
 peripheral
 supports non-continuous mode, then the DSI host should 
 automatically
 disable the HS clock between high-speed transmissions. That means 
 if a
 packet is transmitted in low power mode the DSI host will not be
 transmitting in high-speed mode and therefore disable the HS 
 clock.
 What is LPM you think? I thought LPM is LP-11 and HS clock 
 disabled. So
 for LPM transfer, lanes should be LP-11 state and also HS clock of 
 the
 host controller should be disabled.
 No. I don't think any transmissions can happen when all lanes are in
 LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a 
 packet
 should be transmitted in low power mode (see LP Transmission in 2.1
 Definitions of the MIPI DSI specification).

 Hm.. I see. I meant,

 if (flags  

Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Thierry Reding]

On Mon, Aug 11, 2014 at 04:35:46PM +0900, Inki Dae wrote:
 On 2014년 08월 11일 16:24, Thierry Reding wrote:
  On Mon, Aug 11, 2014 at 02:19:21PM +0900, Inki Dae wrote:
  On 2014년 08월 08일 18:55, Thierry Reding wrote:
[...]
  The above is actually more like this:
 
if ((flags  MIPI_DSI_MODE_NON_CONTINUOUS) == 0)
clear DSI_HS_CLK_CTRL;
else
set DSI_HS_CLK_CTRL;
 
if (msg-flags  MIPI_DSI_MSG_USE_LPM)
clear DSI_HIGH_SPEED_TRANS;
else
set DSI_HIGH_SPEED_TRANS;
 
  So for peripherals that don't support non-continuous clock mode, this
  will result in the following for low-power transmissions:
 
clear DSI_HS_CLK_CTRL; /* HS clock always on */
clear DSI_HIGH_SPEED_TRANS;
 
  Right, then how host driver should check it if peripheral doesn't
  support non-continuous clock mode? Or how the peripheral should notify
  it to host driver? It would need a new flag instead of
  MIPI_DSI_MODE_NON_CONTINUOUS.
 
  MIPI_DSI_MODE_NON_CONTINUOUS is exactly the flag that devices need to
  set to signal that they support non-continuous mode. If devices don't
  have that set, then the controller should always provide the HS clock.
 
  So, if MIPI_DSI_MODE_NON_CONTINUOUS is *not* set, then the peripheral
  does *not* support non-continuous mode.
 
 
 Again, assume that there is a peripheral that doesn't support
 non-continuous clock mode but host driver want to transmit data in low
 power. For this, you already mentioned like below,
 
 So for peripherals that don't support non-continuous clock mode, this
 will result in the following for low-power transmissions:
 
   clear DSI_HS_CLK_CTRL; /* HS clock always on */
   clear DSI_HIGH_SPEED_TRANS;
 
 
 In this case, how should host driver check it to clear above two flags?
 As you know, this is required to clear two flags same as non-continuous
 clock mode. Don't you think that we need a new flag to identify them -
 non-continuous clock mode or just for low-power transmission?

See what I wrote a little further up:

if ((flags  MIPI_DSI_MODE_NON_CONTINUOUS) == 0)
clear DSI_HS_CLK_CTRL;
else
set DSI_HS_CLK_CTRL;
 
if (msg-flags  MIPI_DSI_MSG_USE_LPM)
clear DSI_HIGH_SPEED_TRANS;
else
set DSI_HIGH_SPEED_TRANS;
 

MIPI_DSI_MODE_NON_CONTINUOUS specifies that a peripheral supports non-
continuous mode. When set, we clear DSI_HS_CLK_CTRL on Tegra because
that tells the controller to turn off the HS clock between high-speed
transmissions.

MIPI_DSI_MSG_USE_LPM specifies that a message is to be sent in low-power
mode.

With the above two flags we can cover four cases:

  1) non-continuous mode with messages transmitted in low-power mode
  2) non-continuous mode with messages transmitted in high-speed mode
  3) continuous mode with messages transmitted in low-power mode
  4) continuous mode with messages transmitted in high-speed mode

What other cases do you think we need to support?

Thierry


pgp7G1pImdMYn.pgp
Description: PGP signature

Re: [PATCH] mmc: dw_mmc: change to use recommended reset procedure

[Ulf Hansson]

On 5 August 2014 03:19, Sonny Rao sonny...@chromium.org wrote:
 This patch changes the fifo reset code to follow the reset procedure
 outlined in the documentation of Synopsys Mobile storage host databook.

 Signed-off-by: Sonny Rao sonny...@chromium.org
 Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
 Acked-by: Seungwon Jeon tgih@samsung.com
 Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
 [sonnyrao: fix compile for !CONFIG_MMC_DW_IDMAC case]

Thanks! Applied for next!

Kind regards
Uffe

 ---
  drivers/mmc/host/dw_mmc.c | 87 
 ++-
  drivers/mmc/host/dw_mmc.h |  5 +++
  2 files changed, 69 insertions(+), 23 deletions(-)

 diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
 index 1ac227c..39cf54f 100644
 --- a/drivers/mmc/host/dw_mmc.c
 +++ b/drivers/mmc/host/dw_mmc.c
 @@ -111,8 +111,7 @@ static const u8 tuning_blk_pattern_8bit[] = {
 0xff, 0x77, 0x77, 0xff, 0x77, 0xbb, 0xdd, 0xee,
  };

 -static inline bool dw_mci_fifo_reset(struct dw_mci *host);
 -static inline bool dw_mci_ctrl_all_reset(struct dw_mci *host);
 +static bool dw_mci_reset(struct dw_mci *host);

  #if defined(CONFIG_DEBUG_FS)
  static int dw_mci_req_show(struct seq_file *s, void *v)
 @@ -1235,7 +1234,7 @@ static int dw_mci_data_complete(struct dw_mci *host, 
 struct mmc_data *data)
  * After an error, there may be data lingering
  * in the FIFO
  */
 -   dw_mci_fifo_reset(host);
 +   dw_mci_reset(host);
 } else {
 data-bytes_xfered = data-blocks * data-blksz;
 data-error = 0;
 @@ -1352,7 +1351,7 @@ static void dw_mci_tasklet_func(unsigned long priv)

 /* CMD error in data command */
 if (mrq-cmd-error  mrq-data)
 -   dw_mci_fifo_reset(host);
 +   dw_mci_reset(host);

 host-cmd = NULL;
 host-data = NULL;
 @@ -1963,14 +1962,8 @@ static void dw_mci_work_routine_card(struct 
 work_struct *work)
 }

 /* Power down slot */
 -   if (present == 0) {
 -   /* Clear down the FIFO */
 -   dw_mci_fifo_reset(host);
 -#ifdef CONFIG_MMC_DW_IDMAC
 -   dw_mci_idmac_reset(host);
 -#endif
 -
 -   }
 +   if (present == 0)
 +   dw_mci_reset(host);

 spin_unlock_bh(host-lock);

 @@ -2208,8 +2201,11 @@ static bool dw_mci_ctrl_reset(struct dw_mci *host, u32 
 reset)
 return false;
  }

 -static inline bool dw_mci_fifo_reset(struct dw_mci *host)
 +static bool dw_mci_reset(struct dw_mci *host)
  {
 +   u32 flags = SDMMC_CTRL_RESET | SDMMC_CTRL_FIFO_RESET;
 +   bool ret = false;
 +
 /*
  * Reseting generates a block interrupt, hence setting
  * the scatter-gather pointer to NULL.
 @@ -2219,15 +2215,60 @@ static inline bool dw_mci_fifo_reset(struct dw_mci 
 *host)
 host-sg = NULL;
 }

 -   return dw_mci_ctrl_reset(host, SDMMC_CTRL_FIFO_RESET);
 -}
 +   if (host-use_dma)
 +   flags |= SDMMC_CTRL_DMA_RESET;

 -static inline bool dw_mci_ctrl_all_reset(struct dw_mci *host)
 -{
 -   return dw_mci_ctrl_reset(host,
 -SDMMC_CTRL_FIFO_RESET |
 -SDMMC_CTRL_RESET |
 -SDMMC_CTRL_DMA_RESET);
 +   if (dw_mci_ctrl_reset(host, flags)) {
 +   /*
 +* In all cases we clear the RAWINTS register to clear any
 +* interrupts.
 +*/
 +   mci_writel(host, RINTSTS, 0x);
 +
 +   /* if using dma we wait for dma_req to clear */
 +   if (host-use_dma) {
 +   unsigned long timeout = jiffies + 
 msecs_to_jiffies(500);
 +   u32 status;
 +   do {
 +   status = mci_readl(host, STATUS);
 +   if (!(status  SDMMC_STATUS_DMA_REQ))
 +   break;
 +   cpu_relax();
 +   } while (time_before(jiffies, timeout));
 +
 +   if (status  SDMMC_STATUS_DMA_REQ) {
 +   dev_err(host-dev,
 +   %s: Timeout waiting for dma_req to 
 +   clear during reset\n, __func__);
 +   goto ciu_out;
 +   }
 +
 +   /* when using DMA next we reset the fifo again */
 +   if (!dw_mci_ctrl_reset(host, SDMMC_CTRL_FIFO_RESET))
 +   goto ciu_out;
 +  

Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Inki Dae]

On 2014년 08월 11일 16:44, Andrzej Hajda wrote:
 On 08/11/2014 09:09 AM, Inki Dae wrote:
 On 2014년 08월 08일 18:40, Andrzej Hajda wrote:
 On 08/08/2014 11:02 AM, Andrzej Hajda wrote:
 On 08/08/2014 09:37 AM, Inki Dae wrote:
 On 2014년 08월 08일 16:03, Thierry Reding wrote:
 On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
 On 2014년 08월 07일 22:55, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
 On 2014년 08월 07일 22:17, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
 On 2014년 08월 07일 20:09, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
 On 2014년 08월 07일 18:09, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
 On 2014년 08월 07일 15:58, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
 2014-08-06 16:43 GMT+09:00 Thierry Reding 
 thierry.red...@gmail.com:
 [...]
 As far as I can tell non-continuous mode simply means that 
 the host can
 turn off the HS clock after a high-speed transmission. I 
 think Andrzej
 mentioned this already in another subthread, but this is an 
 optional
 mode that peripherals can support if they have extra 
 circuitry that
 provides an internal clock. Peripherals that don't have such 
 circuitry
 may rely on the HS clock to perform in between transmissions 
 and
 therefore require the HS clock to be always on (continuous 
 mode). That's
 what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it 
 advertises that the
 peripheral supports non-continuous mode and therefore the 
 host can turn
 the HS clock off after high-speed transmissions.
 What I don't make sure is this sentence. With
 MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible 
 operations.
 One is,
 1. host controller will generates signals if a bit of a 
 register
 related to non-contiguous clock mode is set or unset.
 2. And then video data is transmitted to panel in HS mode.
 3. And then D-PHY detects LP-11 signal (positive and negative 
 lane all
 are high).
 4. And then D-PHY disables HS clock of host controller.
 5. At this time, operation mode of host controller becomes 
 LPM.

 Other is,
 1. host controller will generates signals if a bit of a 
 register
 related to non-contiguous clock mode is set or unset.
 2. And then D-PHY detects LP-11 signal (positive and negative 
 lane all
 are high).
 3. And then video data is transmitted to panel in LPM.
 4. At this time, operation mode of host controller becomes 
 LPM.

 It seems that you says latter case.
 No. High speed clock and low power mode are orthogonal. 
 Non-continuous
 mode simply means that the clock lane enters LP-11 between HS
 transmissions (see 5.6 Clock Management of the DSI 
 specification).

 It seems that clock lane enters LP-11 regardless of HS clock 
 enabled if
 non-continous mode is used. Right?
 No, I think as long as HS clock is enabled the clock lane won't 
 enter
 LP-11. Non-continuous mode means that the controller can disable 
 the HS
 clock between HS transmissions. So in non-continuous mode the 
 clock lane
 can enter LP-11 because the controller disables the HS clock.
 It makes me a little bit confusing. You said if HS clock is 
 enabled,
 the the clock lane won't enter LP-11 But you said again the 
 clock lane
 can enter LP-11 because the controller disables the HS clock 
 What is
 the meaning?
 It means that if the HS clock is enabled, then the clock lane is 
 not in
 LP-11. When the HS clock stops, then the clock lane enters LP-11.

 In continuous mode, then the clock will never be disabled, hence 
 the
 clock lane will never enter LP-11.

 And also it seems that non-continous mode is different from LPM 
 at all
 because with non-continuous mode, command data is transmitted 
 to panel
 in HS mode, but with LPM, command data is transmitted to panel 
 in LP
 mode. Also right?
 No. I think you can send command data to the peripheral in low 
 power
 mode in both continuous and non-continuous clock modes.

 If so, shouldn't the host driver disable HS clock, in case of 
 LP mode,
 before the host driver transmits command data?
 No. If the peripheral doesn't support non-continuous mode, then 
 the HS
 clock must never be turned off. On the other hand, if the 
 peripheral
 supports non-continuous mode, then the DSI host should 
 automatically
 disable the HS clock between high-speed transmissions. That 
 means if a
 packet is transmitted in low power mode the DSI host will not be
 transmitting in high-speed mode and therefore disable the HS 
 clock.
 What is LPM you think? I thought LPM is LP-11 and HS clock 
 disabled. So
 for LPM transfer, lanes should be LP-11 state and also HS clock 
 of the
 host controller should be disabled.
 No. I don't think any transmissions can happen when all lanes are 
 in
 LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a 
 packet
 should be transmitted in low power mode (see LP Transmission in 2.1
 Definitions of the MIPI DSI 

Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Andrzej Hajda]

On 08/11/2014 09:44 AM, Andrzej Hajda wrote:
 On 08/11/2014 09:09 AM, Inki Dae wrote:
 On 2014년 08월 08일 18:40, Andrzej Hajda wrote:
 On 08/08/2014 11:02 AM, Andrzej Hajda wrote:
 On 08/08/2014 09:37 AM, Inki Dae wrote:
 On 2014년 08월 08일 16:03, Thierry Reding wrote:
 On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote:
 On 2014년 08월 07일 22:55, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote:
 On 2014년 08월 07일 22:17, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote:
 On 2014년 08월 07일 20:09, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote:
 On 2014년 08월 07일 18:09, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote:
 On 2014년 08월 07일 15:58, Thierry Reding wrote:
 On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote:
 2014-08-06 16:43 GMT+09:00 Thierry Reding 
 thierry.red...@gmail.com:
 [...]
 As far as I can tell non-continuous mode simply means that 
 the host can
 turn off the HS clock after a high-speed transmission. I 
 think Andrzej
 mentioned this already in another subthread, but this is an 
 optional
 mode that peripherals can support if they have extra 
 circuitry that
 provides an internal clock. Peripherals that don't have such 
 circuitry
 may rely on the HS clock to perform in between transmissions 
 and
 therefore require the HS clock to be always on (continuous 
 mode). That's
 what the MIPI_DSI_CLOCK_NON_CONTINUOUS flag is: it 
 advertises that the
 peripheral supports non-continuous mode and therefore the 
 host can turn
 the HS clock off after high-speed transmissions.
 What I don't make sure is this sentence. With
 MIPI_DSI_CLOCK_NON_CONTIUOUS flag, I guess two possible 
 operations.
 One is,
 1. host controller will generates signals if a bit of a 
 register
 related to non-contiguous clock mode is set or unset.
 2. And then video data is transmitted to panel in HS mode.
 3. And then D-PHY detects LP-11 signal (positive and negative 
 lane all
 are high).
 4. And then D-PHY disables HS clock of host controller.
 5. At this time, operation mode of host controller becomes 
 LPM.

 Other is,
 1. host controller will generates signals if a bit of a 
 register
 related to non-contiguous clock mode is set or unset.
 2. And then D-PHY detects LP-11 signal (positive and negative 
 lane all
 are high).
 3. And then video data is transmitted to panel in LPM.
 4. At this time, operation mode of host controller becomes 
 LPM.

 It seems that you says latter case.
 No. High speed clock and low power mode are orthogonal. 
 Non-continuous
 mode simply means that the clock lane enters LP-11 between HS
 transmissions (see 5.6 Clock Management of the DSI 
 specification).

 It seems that clock lane enters LP-11 regardless of HS clock 
 enabled if
 non-continous mode is used. Right?
 No, I think as long as HS clock is enabled the clock lane won't 
 enter
 LP-11. Non-continuous mode means that the controller can disable 
 the HS
 clock between HS transmissions. So in non-continuous mode the 
 clock lane
 can enter LP-11 because the controller disables the HS clock.
 It makes me a little bit confusing. You said if HS clock is 
 enabled,
 the the clock lane won't enter LP-11 But you said again the 
 clock lane
 can enter LP-11 because the controller disables the HS clock 
 What is
 the meaning?
 It means that if the HS clock is enabled, then the clock lane is 
 not in
 LP-11. When the HS clock stops, then the clock lane enters LP-11.

 In continuous mode, then the clock will never be disabled, hence 
 the
 clock lane will never enter LP-11.

 And also it seems that non-continous mode is different from LPM 
 at all
 because with non-continuous mode, command data is transmitted 
 to panel
 in HS mode, but with LPM, command data is transmitted to panel 
 in LP
 mode. Also right?
 No. I think you can send command data to the peripheral in low 
 power
 mode in both continuous and non-continuous clock modes.

 If so, shouldn't the host driver disable HS clock, in case of 
 LP mode,
 before the host driver transmits command data?
 No. If the peripheral doesn't support non-continuous mode, then 
 the HS
 clock must never be turned off. On the other hand, if the 
 peripheral
 supports non-continuous mode, then the DSI host should 
 automatically
 disable the HS clock between high-speed transmissions. That 
 means if a
 packet is transmitted in low power mode the DSI host will not be
 transmitting in high-speed mode and therefore disable the HS 
 clock.
 What is LPM you think? I thought LPM is LP-11 and HS clock 
 disabled. So
 for LPM transfer, lanes should be LP-11 state and also HS clock 
 of the
 host controller should be disabled.
 No. I don't think any transmissions can happen when all lanes are 
 in
 LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a 
 packet
 should be transmitted in low power mode (see LP Transmission in 2.1
 Definitions of the MIPI DSI 

Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Inki Dae]

On 2014년 08월 11일 16:50, Thierry Reding wrote:
 On Mon, Aug 11, 2014 at 04:35:46PM +0900, Inki Dae wrote:
 On 2014년 08월 11일 16:24, Thierry Reding wrote:
 On Mon, Aug 11, 2014 at 02:19:21PM +0900, Inki Dae wrote:
 On 2014년 08월 08일 18:55, Thierry Reding wrote:
 [...]
 The above is actually more like this:

   if ((flags  MIPI_DSI_MODE_NON_CONTINUOUS) == 0)
   clear DSI_HS_CLK_CTRL;
   else
   set DSI_HS_CLK_CTRL;

   if (msg-flags  MIPI_DSI_MSG_USE_LPM)
   clear DSI_HIGH_SPEED_TRANS;
   else
   set DSI_HIGH_SPEED_TRANS;

 So for peripherals that don't support non-continuous clock mode, this
 will result in the following for low-power transmissions:

   clear DSI_HS_CLK_CTRL; /* HS clock always on */
   clear DSI_HIGH_SPEED_TRANS;

 Right, then how host driver should check it if peripheral doesn't
 support non-continuous clock mode? Or how the peripheral should notify
 it to host driver? It would need a new flag instead of
 MIPI_DSI_MODE_NON_CONTINUOUS.

 MIPI_DSI_MODE_NON_CONTINUOUS is exactly the flag that devices need to
 set to signal that they support non-continuous mode. If devices don't
 have that set, then the controller should always provide the HS clock.

 So, if MIPI_DSI_MODE_NON_CONTINUOUS is *not* set, then the peripheral
 does *not* support non-continuous mode.


 Again, assume that there is a peripheral that doesn't support
 non-continuous clock mode but host driver want to transmit data in low
 power. For this, you already mentioned like below,

 So for peripherals that don't support non-continuous clock mode, this
 will result in the following for low-power transmissions:

  clear DSI_HS_CLK_CTRL; /* HS clock always on */
  clear DSI_HIGH_SPEED_TRANS;
 

 In this case, how should host driver check it to clear above two flags?
 As you know, this is required to clear two flags same as non-continuous
 clock mode. Don't you think that we need a new flag to identify them -
 non-continuous clock mode or just for low-power transmission?
 
 See what I wrote a little further up:
 
   if ((flags  MIPI_DSI_MODE_NON_CONTINUOUS) == 0)
   clear DSI_HS_CLK_CTRL;
   else
   set DSI_HS_CLK_CTRL;

   if (msg-flags  MIPI_DSI_MSG_USE_LPM)
   clear DSI_HIGH_SPEED_TRANS;
   else
   set DSI_HIGH_SPEED_TRANS;

 
 MIPI_DSI_MODE_NON_CONTINUOUS specifies that a peripheral supports non-
 continuous mode. When set, we clear DSI_HS_CLK_CTRL on Tegra because
 that tells the controller to turn off the HS clock between high-speed
 transmissions.
 
 MIPI_DSI_MSG_USE_LPM specifies that a message is to be sent in low-power
 mode.
 
 With the above two flags we can cover four cases:
 
   1) non-continuous mode with messages transmitted in low-power mode
   2) non-continuous mode with messages transmitted in high-speed mode
   3) continuous mode with messages transmitted in low-power mode

In case of 3), it would mean set DSI_HS_CLK_CTRL and clear
DSI_HIGH_SPEED_TRANS. However, msg-flags has MIPI_DSI_MSG_USE_LPM but
dsi-mode_flags has no MIPI_DSI_MODE_NON_CONTINOUS flag. Ah, right.
You mean that continuous mode is set by default implicitly?

Thanks,
Inki Dae

   4) continuous mode with messages transmitted in high-speed mode
 
 What other cases do you think we need to support?
 
 Thierry
 

--
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 1/1] Input: atmel_mxt_ts - Get IRQ edge/level flags on DT booting

[Linus Walleij]

I guess this discussion is about drivers/pinctrl/samsung/pinctrl-exynos.c?

Or else I'm not really following this... $SUBJECT is a bit confusing.

On Sat, Aug 9, 2014 at 12:26 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:

 Regardless of this though I think that both the patch to move the IRQ
 pinmux setup from .irq_set_type to the .irq_request_resources and the patch to
 to prevent any pinmux reconfiguration are good improvements to avoid future
 issues like the one we found here.

I think someone should look into switching the Samsung/Exynos pinctrl
driver to the gpiolib irqchip helpers, I looked at it but was scared by
the special wkup chip and stuff I can't test.

The irqchip helpers will atleast help out in flagging GPIO lines as
used for IRQs so the core can keep track of stuff and show that
properly in debugfs.

The orthogonality compliance between GPIO and irqchip must
however be solved in the driver itself, the core only helps out
in blocking some abuse of the API.

Yours,
Linus Walleij
--
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/1] pinctrl: exynos: Lock GPIOs as interrupts when used as EINTs

[Linus Walleij]

On Sat, Aug 9, 2014 at 1:48 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:

 From: Tomasz Figa t.f...@samsung.com

 Currently after configuring a GPIO pin as an interrupt related pinmux
 registers are changed, but there is no protection from calling
 gpio_direction_*() in a badly written driver, which would cause the same
 pinmux register to be reconfigured for regular input/output and this
 disabling interrupt capability of the pin.

 This patch addresses this issue by moving pinmux reconfiguration to
 .irq_{request,release}_resources() callback of irq_chip and calling
 gpio_lock_as_irq() helper to prevent reconfiguration of pin direction.

 Setting up a GPIO interrupt on Samsung SoCs is a two-step operation -
 in addition to trigger configuration in a dedicated register, the pinmux
 must be also reconfigured to GPIO interrupt, which is a different function
 than normal GPIO input, although I/O-wise they both behave in the same way
 and gpio_get_value() can be used on a pin configured as IRQ as well.

 Such design implies subtleties such as gpio_direction_input() not having
 to fail if a pin is already configured as an interrupt nor change the
 configuration to normal input. But the FLAG_USED_AS_IRQ set in gpiolib by
 gpio_lock_as_irq() is only used to check that gpio_direction_output() is
 not called, it's not used to prevent gpio_direction_input() to be called.
 So this is not a complete solution for Samsung SoCs but it's definitely a
 move in the right direction.

 Signed-off-by: Tomasz Figa t.f...@samsung.com
 [javier: use request resources instead of startup and expand commit message]
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---

 This patch solves the issue explained in https://lkml.org/lkml/2014/8/8/461

Hm, this looks much better atleast, it is not possible to use the
irqchip helpers from gpiolib then, because that grabs the request/release
resource callbacks.

If I get some ACKs on this we can go for this solution.

Yours,
Linus Walleij
--
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 1/1] Input: atmel_mxt_ts - Get IRQ edge/level flags on DT booting

[Javier Martinez Canillas]

Hello Linus,

On 08/11/2014 10:32 AM, Linus Walleij wrote:
 I guess this discussion is about drivers/pinctrl/samsung/pinctrl-exynos.c?
 
 Or else I'm not really following this... $SUBJECT is a bit confusing.
 

Yes, the thing is that at the beginning I (wrongly) thought that the IRQ trigger
type flags defined in the DTS were discarded if someone called
request_threaded_irq() with a flags != 0. And since the atmel touchpad driver
was pass pdata-irqflags | IRQF_ONESHOT I posted this patch to get the trigger
type parsed from DT and pass it to request_threaded_irq().

But after digging further I found that the issue was in the pinctrl-exynos
driver and Tomasz explained to me that the real cause was that the pin was being
configured from GPIO IRQ to GPIO input (which on other platforms is just the
same mode but on Exynos are two different modes).

At the end passing the trigger type to request_threaded_irq() just had the side
effect to call the exynos .irq_set_type function handler that reconfigured the
pin as GPIO-IRQ and that is why it made it to work. So I posted a patch from
Tomasz that fixes the real cause [0].

I'm so sorry for the confusion.

 Yours,
 Linus Walleij
 

Best regards,
Javier

[0]: https://lkml.org/lkml/2014/8/8/962
--
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 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Thierry Reding]

On Mon, Aug 11, 2014 at 05:15:35PM +0900, Inki Dae wrote:
 On 2014년 08월 11일 16:50, Thierry Reding wrote:
  On Mon, Aug 11, 2014 at 04:35:46PM +0900, Inki Dae wrote:
  On 2014년 08월 11일 16:24, Thierry Reding wrote:
  On Mon, Aug 11, 2014 at 02:19:21PM +0900, Inki Dae wrote:
  On 2014년 08월 08일 18:55, Thierry Reding wrote:
  [...]
  The above is actually more like this:
 
  if ((flags  MIPI_DSI_MODE_NON_CONTINUOUS) == 0)
  clear DSI_HS_CLK_CTRL;
  else
  set DSI_HS_CLK_CTRL;
 
  if (msg-flags  MIPI_DSI_MSG_USE_LPM)
  clear DSI_HIGH_SPEED_TRANS;
  else
  set DSI_HIGH_SPEED_TRANS;
 
  So for peripherals that don't support non-continuous clock mode, this
  will result in the following for low-power transmissions:
 
  clear DSI_HS_CLK_CTRL; /* HS clock always on */
  clear DSI_HIGH_SPEED_TRANS;
 
  Right, then how host driver should check it if peripheral doesn't
  support non-continuous clock mode? Or how the peripheral should notify
  it to host driver? It would need a new flag instead of
  MIPI_DSI_MODE_NON_CONTINUOUS.
 
  MIPI_DSI_MODE_NON_CONTINUOUS is exactly the flag that devices need to
  set to signal that they support non-continuous mode. If devices don't
  have that set, then the controller should always provide the HS clock.
 
  So, if MIPI_DSI_MODE_NON_CONTINUOUS is *not* set, then the peripheral
  does *not* support non-continuous mode.
 
 
  Again, assume that there is a peripheral that doesn't support
  non-continuous clock mode but host driver want to transmit data in low
  power. For this, you already mentioned like below,
 
  So for peripherals that don't support non-continuous clock mode, this
  will result in the following for low-power transmissions:
 
 clear DSI_HS_CLK_CTRL; /* HS clock always on */
 clear DSI_HIGH_SPEED_TRANS;
  
 
  In this case, how should host driver check it to clear above two flags?
  As you know, this is required to clear two flags same as non-continuous
  clock mode. Don't you think that we need a new flag to identify them -
  non-continuous clock mode or just for low-power transmission?
 
  See what I wrote a little further up:
 
  if ((flags  MIPI_DSI_MODE_NON_CONTINUOUS) == 0)
  clear DSI_HS_CLK_CTRL;
  else
  set DSI_HS_CLK_CTRL;
 
  if (msg-flags  MIPI_DSI_MSG_USE_LPM)
  clear DSI_HIGH_SPEED_TRANS;
  else
  set DSI_HIGH_SPEED_TRANS;
 
 
  MIPI_DSI_MODE_NON_CONTINUOUS specifies that a peripheral supports non-
  continuous mode. When set, we clear DSI_HS_CLK_CTRL on Tegra because
  that tells the controller to turn off the HS clock between high-speed
  transmissions.
 
  MIPI_DSI_MSG_USE_LPM specifies that a message is to be sent in low-power
  mode.
 
  With the above two flags we can cover four cases:
 
1) non-continuous mode with messages transmitted in low-power mode
2) non-continuous mode with messages transmitted in high-speed mode
3) continuous mode with messages transmitted in low-power mode
 
 In case of 3), it would mean set DSI_HS_CLK_CTRL and clear
 DSI_HIGH_SPEED_TRANS. However, msg-flags has MIPI_DSI_MSG_USE_LPM but
 dsi-mode_flags has no MIPI_DSI_MODE_NON_CONTINOUS flag. Ah, right.
 You mean that continuous mode is set by default implicitly?

Yes, if the MIPI_DSI_MODE_NON_CONTINUOUS flag is not specified, then it
means the peripheral supports only continuous mode.

Thierry


pgpDS3SM5RpCn.pgp
Description: PGP signature

Re: [PATCHv10 2/5] mmc: dw_mmc: modify the dt-binding for removing slot-node and supports-highspeed

[Ulf Hansson]

On 7 August 2014 09:37, Jaehoon Chung jh80.ch...@samsung.com wrote:
 Almost all SoCs use one slot per host controller.
 (Even if controller can support the multiple slot, Recommend to use one slot 
 per host controller.)
 Don't use the slot-node and deprecate the supports-highspeed property.
 Instead, use the cap-mmc/sd-highspeed.

 Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
 Reviewed-by: Tushar Behera trbli...@gmail.com
 Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
 Tested-by: Sachin Kamat sachin.ka...@samsung.com
 Acked-by: Seungwon Jeon tgih@samsung.com
 Reviewed-by: Doug Anderson diand...@chromium.org

Thanks! Applied for next!

Kind regards
Uffe



 ---
  .../devicetree/bindings/mmc/exynos-dw-mshc.txt |   17 +
  .../devicetree/bindings/mmc/k3-dw-mshc.txt |   12 +---
  .../devicetree/bindings/mmc/synopsys-dw-mshc.txt   |   12 +---
  3 files changed, 15 insertions(+), 26 deletions(-)

 diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt 
 b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
 index 532b1d4..6cd3525 100644
 --- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
 +++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
 @@ -46,13 +46,14 @@ Required Properties:
- if CIU clock divider value is 0 (that is divide by 1), both tx and rx
  phase shift clocks should be 0.

 -Required properties for a slot:
 +Required properties for a slot (Deprecated - Recommend to use one slot per 
 host):

  * gpios: specifies a list of gpios used for command, clock and data bus. The
first gpio is the command line and the second gpio is the clock line. The
rest of the gpios (depending on the bus-width property) are the data lines 
 in
no particular order. The format of the gpio specifier depends on the gpio
controller.
 +(Deprecated - Refer to 
 Documentation/devicetree/binding/pinctrl/samsung-pinctrl.txt)

  Example:

 @@ -69,21 +70,13 @@ Example:

 dwmmc0@1220 {
 num-slots = 1;
 -   supports-highspeed;
 +   cap-mmc-highspeed;
 +   cap-sd-highspeed;
 broken-cd;
 fifo-depth = 0x80;
 card-detect-delay = 200;
 samsung,dw-mshc-ciu-div = 3;
 samsung,dw-mshc-sdr-timing = 2 3;
 samsung,dw-mshc-ddr-timing = 1 2;
 -
 -   slot@0 {
 -   reg = 0;
 -   bus-width = 8;
 -   gpios = gpc0 0 2 0 3, gpc0 1 2 0 3,
 -   gpc1 0 2 3 3, gpc1 1 2 3 3,
 -   gpc1 2 2 3 3, gpc1 3 2 3 3,
 -   gpc0 3 2 3 3, gpc0 4 2 3 3,
 -   gpc0 5 2 3 3, gpc0 6 2 3 3;
 -   };
 +   bus-width = 8;
 };
 diff --git a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt 
 b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
 index e5bc49f..3b35449 100644
 --- a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
 +++ b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
 @@ -34,13 +34,11 @@ Example:
 num-slots = 1;
 vmmc-supply = ldo12;
 fifo-depth = 0x100;
 -   supports-highspeed;
 pinctrl-names = default;
 pinctrl-0 = sd_pmx_pins sd_cfg_func1 sd_cfg_func2;
 -   slot@0 {
 -   reg = 0;
 -   bus-width = 4;
 -   disable-wp;
 -   cd-gpios = gpio10 3 0;
 -   };
 +   bus-width = 4;
 +   disable-wp;
 +   cd-gpios = gpio10 3 0;
 +   cap-mmc-highspeed;
 +   cap-sd-highspeed;
 };
 diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt 
 b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
 index 2d4a725..346c609 100644
 --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
 +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
 @@ -67,7 +67,8 @@ Optional properties:
  * card-detect-delay: Delay in milli-seconds before detecting card after card
insert event. The default value is 0.

 -* supports-highspeed: Enables support for high speed cards (up to 50MHz)
 +* supports-highspeed (DEPRECATED): Enables support for high speed cards (up 
 to 50MHz)
 +  (use cap-mmc-highspeed or cap-sd-highspeed 
 instead)

  * broken-cd: as documented in mmc core bindings.

 @@ -98,14 +99,11 @@ board specific portions as listed below.
 clock-frequency = 4;
 clock-freq-min-max = 40 2;
 num-slots = 1;
 -   supports-highspeed;
 broken-cd;
 fifo-depth = 0x80;
 card-detect-delay = 200;
 vmmc-supply = buck8;
 -
 - 

Re: [PATCHv10 1/5] mmc: dw_mmc: Slot quirk disable-wp is deprecated.

[Ulf Hansson]

On 7 August 2014 09:37, Jaehoon Chung jh80.ch...@samsung.com wrote:
 Slot quirks disable-wp is deprecated.
 Instead, use the host quirk disable-wp.
 (Because the slot-node is removed in dt-file.)

 Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
 Tested-by: Sachin Kamat sachin.ka...@samsung.com
 Acked-by: Seungwon Jeon tgih@samsung.com
 Reviewed-by: Doug Anderson diand...@chromium.org
 Tested-by: Doug Anderson diand...@chromium.org

Thanks! Applied for next!

Kind regards
Uffe

 ---
  drivers/mmc/host/dw_mmc.c  |   11 +--
  include/linux/mmc/dw_mmc.h |2 ++
  2 files changed, 11 insertions(+), 2 deletions(-)

 diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
 index 1ac227c..47b52cc 100644
 --- a/drivers/mmc/host/dw_mmc.c
 +++ b/drivers/mmc/host/dw_mmc.c
 @@ -997,7 +997,8 @@ static int dw_mci_get_ro(struct mmc_host *mmc)
 int gpio_ro = mmc_gpio_get_ro(mmc);

 /* Use platform get_ro function, else try on board write protect */
 -   if (slot-quirks  DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT)
 +   if ((slot-quirks  DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT) ||
 +   (slot-host-quirks  DW_MCI_QUIRK_NO_WRITE_PROTECT))
 read_only = 0;
 else if (!IS_ERR_VALUE(gpio_ro))
 read_only = gpio_ro;
 @@ -2021,8 +2022,11 @@ static int dw_mci_of_get_slot_quirks(struct device 
 *dev, u8 slot)

 /* get quirks */
 for (idx = 0; idx  ARRAY_SIZE(of_slot_quirks); idx++)
 -   if (of_get_property(np, of_slot_quirks[idx].quirk, NULL))
 +   if (of_get_property(np, of_slot_quirks[idx].quirk, NULL)) {
 +   dev_warn(dev, Slot quirk %s is deprecated\n,
 +   of_slot_quirks[idx].quirk);
 quirks |= of_slot_quirks[idx].id;
 +   }

 return quirks;
  }
 @@ -2238,6 +2242,9 @@ static struct dw_mci_of_quirks {
 {
 .quirk  = broken-cd,
 .id = DW_MCI_QUIRK_BROKEN_CARD_DETECTION,
 +   }, {
 +   .quirk  = disable-wp,
 +   .id = DW_MCI_QUIRK_NO_WRITE_PROTECT,
 },
  };

 diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
 index babaea9..29ce014 100644
 --- a/include/linux/mmc/dw_mmc.h
 +++ b/include/linux/mmc/dw_mmc.h
 @@ -213,6 +213,8 @@ struct dw_mci_dma_ops {
  #define DW_MCI_QUIRK_HIGHSPEED BIT(2)
  /* Unreliable card detection */
  #define DW_MCI_QUIRK_BROKEN_CARD_DETECTION BIT(3)
 +/* No write protect */
 +#define DW_MCI_QUIRK_NO_WRITE_PROTECT  BIT(4)

  /* Slot level quirks */
  /* This slot has no write protect */
 --
 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: [PATCH v5 05/10] ARM: dts: Move dp_hpd from exynos5250 into smdk5250 and snow

[Jingoo Han]

On Sunday, August 10, 2014 6:15 PM, Andreas Farber wrote:
 Am 05.08.2014 13:16, schrieb Jingoo Han:
  On Saturday, August 02, 2014 5:57 AM, Tomasz Figa wrote:
  On 01.08.2014 22:54, Andreas Färber wrote:
  Am 01.08.2014 22:33, schrieb Doug Anderson:
  On Thu, Jul 31, 2014 at 9:54 PM, Andreas Färber afaer...@suse.de wrote:
  Spring uses a different GPIO, so this is not a generic SoC piece.
 
  Suggested-by: Tomasz Figa t.f...@samsung.com
  Signed-off-by: Andreas Färber afaer...@suse.de
  ---
   v5: New (Tomasz Figa)
   Frees dp_hpd for Spring.
 
   arch/arm/boot/dts/exynos5250-pinctrl.dtsi | 7 ---
   arch/arm/boot/dts/exynos5250-smdk5250.dts | 9 +
   arch/arm/boot/dts/exynos5250-snow.dts | 7 +++
   3 files changed, 16 insertions(+), 7 deletions(-)
 
  diff --git a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi 
  b/arch/arm/boot/dts/exynos5250-
 pinctrl.dtsi
  index 886cfca044ac..ed0e5230514b 100644
  --- a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
  +++ b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
  @@ -581,13 +581,6 @@
  samsung,pin-pud = 0;
  samsung,pin-drv = 0;
  };
  -
  -   dp_hpd: dp_hpd {
  -   samsung,pins = gpx0-7;
  -   samsung,pin-function = 3;
  -   samsung,pin-pud = 0;
  -   samsung,pin-drv = 0;
  -   };
  };
 
  pinctrl@1340 {
  diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
  b/arch/arm/boot/dts/exynos5250-
 smdk5250.dts
  index aaa055ac0fe3..5d30fe1dcda4 100644
  --- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
  +++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
  @@ -414,3 +414,12 @@
  };
  };
   };
  +
  +pinctrl_0 {
  +   dp_hpd: dp_hpd {
  +   samsung,pins = gpx0-7;
  +   samsung,pin-function = 3;
  +   samsung,pin-pud = 0;
  +   samsung,pin-drv = 0;
  +   };
  +};
  diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
  b/arch/arm/boot/dts/exynos5250-snow.dts
  index c4b0c73c736d..a9a2f2743794 100644
  --- a/arch/arm/boot/dts/exynos5250-snow.dts
  +++ b/arch/arm/boot/dts/exynos5250-snow.dts
  @@ -547,6 +547,13 @@
   };
 
   pinctrl_0 {
  +   dp_hpd: dp_hpd {
  +   samsung,pins = gpx0-7;
  +   samsung,pin-function = 3;
  +   samsung,pin-pud = 0;
  +   samsung,pin-drv = 0;
  +   };
  +
 
  NAK.  dp_hpd is a generic SoC piece.  Pin function 0 and 1 are GPIOs.
  Pin function 3 is special function.  This pin _is_ the hot plug detect
  pin for display port.  When it's set as special function 3 it goes
  straight into the hot plug logic of the display port controller.
 
  Spring may have had its reasons to detect hot plug events on a GPIO
  instead of using this pin, but that doesn't make this pin any less the
  hot plug pin.
 
  Please advise how to handle it then: Should there be two different
  pinctrl entries (if so, how should it be named?),
 
  IMHO this is the right way. Just name the GPIO variant dp_hpd_gpio.
 
  Hi Andreas Färber,
 
  I agree with Tomasz Figa and Doug Anderson.
  Please refer to the following.
 
  1. case: Standard HPD pin is used. (smdk5420)
  arch/arm/boot/dts/exynos5420-pinctrl.dts
  pinctrl@1340 {
  dp_hpd: dp_hpd {
  samsung,pins = gpx0-7;
  samsung,pin-function = 3;
  samsung,pin-pud = 0;
  samsung,pin-drv = 0;
  };
  arch/arm/boot/dts/exynos5420-smdk5420.dts
  dp-controller@145B {
  pinctrl-names = default;
  pinctrl-0 = dp_hpd;
  ...
 
  2. case: non-standard HPD pin such as GPIO is used. (peach pit)
  arch/arm/boot/dts/exynos5420-peach-pit.dts
  pinctrl@1340 {
  dp_hpd_gpio: dp_hpd_gpio {
  samsung,pins = gpx2-6;
  samsung,pin-function = 0;
  samsung,pin-pud = 3;
  samsung,pin-drv = 0;
  };
  dp-controller@145B {
  pinctrl-names = default;
  pinctrl-0 = dp_hpd_gpio;
  ...
  samsung,hpd-gpio = gpx2 6 0;
 
  So, you need to follow the second case.
  dp_hpd_gpio can be used for Spring board.
 
 I believe I already did so in v6 [0]? Please take a look there and let
 me know if you still need anything changed. The label name seems
 identical, whereas for the node name I adopted the dashes convention.

OK, I checked v6 patches.
I have no objection. It looks good.
Thank you.

Best regards,
Jingoo Han

 
 Thanks,
 Andreas
 
 [0] https://patchwork.kernel.org/patch/4664691/
 
 --
 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
 GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body of 

[RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support

[Javier Martinez Canillas]

Many Exynos5 boards (e.g: Snow, Peach Pit and Pi) have
a SBS-compliant gas gauge battery. Enable it as module
so the needed support is available for these boards.

Suggested-by: Doug Anderson diand...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Kukjin Kim kgene@samsung.com
---
 arch/arm/configs/exynos_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/exynos_defconfig 
b/arch/arm/configs/exynos_defconfig
index fc7d168..c390bb9 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y
 CONFIG_I2C_S3C2410=y
 CONFIG_DEBUG_GPIO=y
 CONFIG_POWER_SUPPLY=y
+CONFIG_BATTERY_SBS=m
 CONFIG_CHARGER_TPS65090=y
 # CONFIG_HWMON is not set
 CONFIG_THERMAL=y
-- 
2.0.0.rc2

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

[RESEND PATCH 1/2] ARM: dts: Improve Peach Pit and Pi power scheme

[Javier Martinez Canillas]

The DeviceTree files for the Peach Pit and Pi machines have
a simplistic model of the connections between the different
regulators since not all the tps65090 regulators get their
input supply voltage from the VDC. DCDC1-3, LD0-1 and fet7
parent supply is indded VDC but the fet1-6 get their input
supply from the DCDC1 and DCDC2 output voltage rails.

Update the DeviceTree to better reflect the real connections
between tps65090 regulators. Having this information in the
DTS is useful since FETs are switches that don't provide an
output voltage so the regulator core needs to fetch the FET
parent output voltage if the child voltage is queried.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Mark Brown broo...@linaro.org
---
 arch/arm/boot/dts/exynos5420-peach-pit.dts | 12 ++--
 arch/arm/boot/dts/exynos5800-peach-pi.dts  | 12 ++--
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 228a6b1..d8710c1 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -365,12 +365,12 @@
vsys2-supply = vbat;
vsys3-supply = vbat;
infet1-supply = vbat;
-   infet2-supply = vbat;
-   infet3-supply = vbat;
-   infet4-supply = vbat;
-   infet5-supply = vbat;
-   infet6-supply = vbat;
-   infet7-supply = vbat;
+   infet2-supply = tps65090_dcdc1;
+   infet3-supply = tps65090_dcdc2;
+   infet4-supply = tps65090_dcdc2;
+   infet5-supply = tps65090_dcdc2;
+   infet6-supply = tps65090_dcdc2;
+   infet7-supply = tps65090_dcdc1;
vsys-l1-supply = vbat;
vsys-l2-supply = vbat;
 
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index f3ee48b..07b29b7 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -363,12 +363,12 @@
vsys2-supply = vbat;
vsys3-supply = vbat;
infet1-supply = vbat;
-   infet2-supply = vbat;
-   infet3-supply = vbat;
-   infet4-supply = vbat;
-   infet5-supply = vbat;
-   infet6-supply = vbat;
-   infet7-supply = vbat;
+   infet2-supply = tps65090_dcdc1;
+   infet3-supply = tps65090_dcdc2;
+   infet4-supply = tps65090_dcdc2;
+   infet5-supply = tps65090_dcdc2;
+   infet6-supply = tps65090_dcdc2;
+   infet7-supply = tps65090_dcdc1;
vsys-l1-supply = vbat;
vsys-l2-supply = vbat;
 
-- 
2.0.0.rc2

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

[RESEND PATCH 2/2] ARM: dts: Add tps65090 FET constraints on Peach Pit and Pi

[Javier Martinez Canillas]

Both Exynos5420 Peach Pit and Exynos5800 Peach Pi boards
have a tps65090 PMU that has a number of switches (FETs)
that are just on/off devices but they do have a current
limit and the output voltage of the switch is ramped up
within a controlled slope.

After the switch is turned on, a safety timer is started
and before this timer times out the output voltage must
have reached the input voltage. Otherwise the switch is
turned off expecting an overload condition.

So using the maximum output voltage slew rate and the timer
minimum and maximum timeouts, a voltage constraints can be
expressed as bounded limits for the timeout. That is what
is used in the board schematics and should be in the DT too.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
 arch/arm/boot/dts/exynos5420-peach-pit.dts | 14 ++
 arch/arm/boot/dts/exynos5800-peach-pi.dts  | 14 ++
 2 files changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index d8710c1..eefafe6 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -386,27 +386,41 @@
};
tps65090_fet1: fet1 {
regulator-name = vcd_led;
+   regulator-min-microvolt = 
500;
+   regulator-max-microvolt = 
170;
};
tps65090_fet2: fet2 {
regulator-name = video_mid;
+   regulator-min-microvolt = 
450;
+   regulator-max-microvolt = 
550;
regulator-always-on;
};
tps65090_fet3: fet3 {
regulator-name = wwan_r;
+   regulator-min-microvolt = 
300;
+   regulator-max-microvolt = 
550;
regulator-always-on;
};
tps65090_fet4: fet4 {
regulator-name = sdcard;
+   regulator-min-microvolt = 
300;
+   regulator-max-microvolt = 
550;
regulator-always-on;
};
tps65090_fet5: fet5 {
regulator-name = camout;
+   regulator-min-microvolt = 
300;
+   regulator-max-microvolt = 
550;
};
tps65090_fet6: fet6 {
regulator-name = lcd_vdd;
+   regulator-min-microvolt = 
300;
+   regulator-max-microvolt = 
550;
};
tps65090_fet7: fet7 {
regulator-name = video_mid_1a;
+   regulator-min-microvolt = 
300;
+   regulator-max-microvolt = 
550;
regulator-always-on;
};
tps65090_ldo1: ldo1 {
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 07b29b7..5c38bc0 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -384,27 +384,41 @@
};
tps65090_fet1: fet1 {
regulator-name = vcd_led;
+   regulator-min-microvolt = 
500;
+   regulator-max-microvolt = 
170;
};
tps65090_fet2: fet2 {
regulator-name = video_mid;
+   regulator-min-microvolt = 
450;
+   regulator-max-microvolt = 
550;
  

Re: [PATCH v2 0/2] Firmware-assisted suspend/resume of Exynos SoCs

[Tomeu Vizoso]

For both patches, on the Odroid U2:

Tested-by: Tomeu Vizoso tomeu.viz...@collabora.com

Thanks,

Tomeu

On 17 July 2014 17:56, Tomasz Figa t.f...@samsung.com wrote:
 On Exynos-based boards running secure firmware the sequence of low level
 operations to enter and leave system-wide sleep mode is different than
 on those without the firmware. Namely:
  - CP15 power control and diagnostic registers cannot be written directly,
  - the way of setting boot address and boot flag is different,
  - different resume handler needs to be used,
  - dedicated SMC call needs to be performed instead of letting the CPU enter
WFI.

 This series introduces .suspend() and .resume() firmware operations to
 perform low level firmware-specific suspend and resume and then leverages
 them to provide suspend-resume path meeting the above requirements.

 The series is based on Kgene's for-next branch and tested on:
  - Exynos4412-based Trats2 board running in non-secure mode (under secure
firmware) with few board-specific fixes that will be sent separately soon,
  - Exynos4210-based Trats board running in secure mode,
  - Exynos4412-based ODROID-U3 board running in non-secure mode with one minor
board-specific fix which will be send shortly.

 Depends on:
  - [PATCH v3] ARM: save/restore Cortex-A9 CP15 registers on suspend/resume
(http://www.spinics.net/lists/arm-kernel/msg346212.html)
  - [PATCH v3] ARM: EXYNOS: Fix suspend/resume sequences
(https://lkml.org/lkml/2014/7/15/319)
  - [PATCH] ARM: make it easier to check the CPU part number correctly
(http://thread.gmane.org/gmane.linux.ports.arm.kernel/335126
 already in linux-next)

 Changes since v1:
  - dropped outer_resume() - will be handled in assembly in further patches,
as support for L2C in non-secure mode gets added,
  - moved CP15 resume to assembly as it needs to be done before MMU is enabled,
  - surrounded CP15 save with a check for cpuid part, because it is valid only
on Cortex A9,
  - rebased on next-20140717 tag of linux-next tree.

 Tomasz Figa (2):
   ARM: firmware: Introduce suspend and resume operations
   ARM: EXYNOS: Add support for firmware-assisted suspend/resume

  Documentation/arm/firmware.txt  | 28 +
  arch/arm/include/asm/firmware.h |  8 
  arch/arm/mach-exynos/Makefile   |  1 +
  arch/arm/mach-exynos/common.h   |  4 
  arch/arm/mach-exynos/firmware.c | 45 
 +
  arch/arm/mach-exynos/pm.c   | 16 ++-
  arch/arm/mach-exynos/sleep.S| 28 +
  arch/arm/mach-exynos/smc.h  |  4 
  8 files changed, 106 insertions(+), 28 deletions(-)

 --
 1.9.3

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

Re: [RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support

[Bartlomiej Zolnierkiewicz]

Hi,

On Monday, August 11, 2014 01:06:38 PM Javier Martinez Canillas wrote:
 Many Exynos5 boards (e.g: Snow, Peach Pit and Pi) have
 a SBS-compliant gas gauge battery. Enable it as module
 so the needed support is available for these boards.
 
 Suggested-by: Doug Anderson diand...@chromium.org
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Acked-by: Kukjin Kim kgene@samsung.com
 ---
  arch/arm/configs/exynos_defconfig | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/arch/arm/configs/exynos_defconfig 
 b/arch/arm/configs/exynos_defconfig
 index fc7d168..c390bb9 100644
 --- a/arch/arm/configs/exynos_defconfig
 +++ b/arch/arm/configs/exynos_defconfig
 @@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y
  CONFIG_I2C_S3C2410=y
  CONFIG_DEBUG_GPIO=y
  CONFIG_POWER_SUPPLY=y
 +CONFIG_BATTERY_SBS=m

Why not make it =y?

Rationale:
- currently no hardware related option uses =m in exynos_defconfig
- it would match the SBS option usage in multi_v7_defconfig

  CONFIG_CHARGER_TPS65090=y
  # CONFIG_HWMON is not set
  CONFIG_THERMAL=y

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

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

Re: [RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support

[Javier Martinez Canillas]

Hello Bartlomiej,

On 08/11/2014 02:40 PM, Bartlomiej Zolnierkiewicz wrote:
 index fc7d168..c390bb9 100644
 --- a/arch/arm/configs/exynos_defconfig
 +++ b/arch/arm/configs/exynos_defconfig
 @@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y
  CONFIG_I2C_S3C2410=y
  CONFIG_DEBUG_GPIO=y
  CONFIG_POWER_SUPPLY=y
 +CONFIG_BATTERY_SBS=m
 
 Why not make it =y?
 
 Rationale:
 - currently no hardware related option uses =m in exynos_defconfig
 - it would match the SBS option usage in multi_v7_defconfig

  CONFIG_CHARGER_TPS65090=y
  # CONFIG_HWMON is not set
  CONFIG_THERMAL=y
 

I know but personally I think this should be changed. The idea of having a multi
platform kernel is to build a single kernel image that can be used to boot
different platforms. Not all platforms have a SBS-compliant battery so this
support shouldn't be built in the kernel image IMHO.

This also matches to what real users will do since distributions most likely
will have a minimal kernel and every possible hardware support will be enabled
as a loadable kernel module. This is what distros do for other platforms too.

If someone has a different use case and wants a kernel image that is optimized
for a particular platform then she has to create its own defconfig anyways.

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

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: [PATCHv10 5/5] ARM: dts: rockchip: unuse the slot-node and deprecate the supports-highspeed for dw-mmc

[Heiko Stübner]

Am Donnerstag, 7. August 2014, 16:38:02 schrieb Jaehoon Chung:
 dw-mmc controller can support multiple slots.
 But, there are no use-cases anywhere. So we don't need to support the
 slot-node for dw-mmc controller.
 And supports-highspeed property in dw-mmc is deprecated.
 supports-highspeed property can be replaced with cap-sd/mmc-highspeed.
 
 Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
 Reviewed-by: Tushar Behera trbli...@gmail.com
 Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
 Reviewed-by: Heiko Stuebner he...@sntech.de
 Acked-by: Seungwon Jeon tgih@samsung.com

I've added this one to my queue for 3.18


Heiko

 ---
  arch/arm/boot/dts/rk3066a-bqcurie2.dts |   15 ---
  arch/arm/boot/dts/rk3188-radxarock.dts |7 ++-
  2 files changed, 6 insertions(+), 16 deletions(-)
 
 diff --git a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
 b/arch/arm/boot/dts/rk3066a-bqcurie2.dts index 042f821d..665dd56 100644
 --- a/arch/arm/boot/dts/rk3066a-bqcurie2.dts
 +++ b/arch/arm/boot/dts/rk3066a-bqcurie2.dts
 @@ -150,12 +150,8 @@
   num-slots = 1;
   status = okay;
   vmmc-supply = vcc_sd0;
 -
 - slot@0 {
 - reg = 0;
 - bus-width = 4;
 - disable-wp;
 - };
 + bus-width = 4;
 + disable-wp;
  };
 
  mmc1 { /* wifi */
 @@ -166,11 +162,8 @@
   pinctrl-names = default;
   pinctrl-0 = sd1_clk sd1_cmd sd1_bus4;
 
 - slot@0 {
 - reg = 0;
 - bus-width = 4;
 - disable-wp;
 - };
 + bus-width = 4;
 + disable-wp;
  };
 
  uart0 {
 diff --git a/arch/arm/boot/dts/rk3188-radxarock.dts
 b/arch/arm/boot/dts/rk3188-radxarock.dts index 171b610..ef72faf 100644
 --- a/arch/arm/boot/dts/rk3188-radxarock.dts
 +++ b/arch/arm/boot/dts/rk3188-radxarock.dts
 @@ -181,11 +181,8 @@
   status = okay;
   vmmc-supply = vcc_sd0;
 
 - slot@0 {
 - reg = 0;
 - bus-width = 4;
 - disable-wp;
 - };
 + bus-width = 4;
 + disable-wp;
  };
 
  pinctrl {

--
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: [RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support

[Doug Anderson]

Javier,

On Mon, Aug 11, 2014 at 4:06 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 Many Exynos5 boards (e.g: Snow, Peach Pit and Pi) have
 a SBS-compliant gas gauge battery. Enable it as module
 so the needed support is available for these boards.

 Suggested-by: Doug Anderson diand...@chromium.org
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Acked-by: Kukjin Kim kgene@samsung.com
 ---
  arch/arm/configs/exynos_defconfig | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/arch/arm/configs/exynos_defconfig 
 b/arch/arm/configs/exynos_defconfig
 index fc7d168..c390bb9 100644
 --- a/arch/arm/configs/exynos_defconfig
 +++ b/arch/arm/configs/exynos_defconfig
 @@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y
  CONFIG_I2C_S3C2410=y
  CONFIG_DEBUG_GPIO=y
  CONFIG_POWER_SUPPLY=y
 +CONFIG_BATTERY_SBS=m
  CONFIG_CHARGER_TPS65090=y
  # CONFIG_HWMON is not set
  CONFIG_THERMAL=y

I'm good with this, so:

Reviewed-by: Doug Anderson diand...@chromium.org

To address Bartlomiej: =m is what's in ChromeOS for exynos, though I
notice that other platforms in the ChromeOS tree have =y.  I'm not
sure why there is a difference, but it's probably just carelessness.

Normally in ChromeOS we use =m for drivers that can afford to wait
until after the UI is up and running.  That helps improve boot time
since the user can use the device sooner (and it's OK if the battery
driver takes a few extra seconds to load).  The only things that
really should be =y are drivers that are critical to load early or
that are needed for the user to interact with the system.  In this
case you could argue that loading sbs earlier means that if the system
is low on battery it will get back to shutdown sooner.  I'm not sure
getting the shutdown a few seconds earlier is really critical,
though...

-Doug
--
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: [RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support

[Bartlomiej Zolnierkiewicz]

Hi,

On Monday, August 11, 2014 02:52:27 PM Javier Martinez Canillas wrote:
 Hello Bartlomiej,
 
 On 08/11/2014 02:40 PM, Bartlomiej Zolnierkiewicz wrote:
  index fc7d168..c390bb9 100644
  --- a/arch/arm/configs/exynos_defconfig
  +++ b/arch/arm/configs/exynos_defconfig
  @@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y
   CONFIG_I2C_S3C2410=y
   CONFIG_DEBUG_GPIO=y
   CONFIG_POWER_SUPPLY=y
  +CONFIG_BATTERY_SBS=m
  
  Why not make it =y?
  
  Rationale:
  - currently no hardware related option uses =m in exynos_defconfig
  - it would match the SBS option usage in multi_v7_defconfig
 
   CONFIG_CHARGER_TPS65090=y
   # CONFIG_HWMON is not set
   CONFIG_THERMAL=y
  
 
 I know but personally I think this should be changed. The idea of having a 
 multi
 platform kernel is to build a single kernel image that can be used to boot
 different platforms. Not all platforms have a SBS-compliant battery so this
 support shouldn't be built in the kernel image IMHO.
 
 This also matches to what real users will do since distributions most likely
 will have a minimal kernel and every possible hardware support will be enabled
 as a loadable kernel module. This is what distros do for other platforms too.
 
 If someone has a different use case and wants a kernel image that is optimized
 for a particular platform then she has to create its own defconfig anyways.

Distributions usually use their own configs anyway and the current most
popular use case for exynos_defconfig (not multi_v7_defconfig) seems to
be to build kernel image alone and use it without any modules:

$ grep =m arch/arm/configs/exynos_defconfig
CONFIG_DM_CRYPT=m

$ grep =m .config
CONFIG_NET_IP_TUNNEL=m
CONFIG_INET_TUNNEL=m
CONFIG_IPV6=m
CONFIG_INET6_XFRM_MODE_TRANSPORT=m
CONFIG_INET6_XFRM_MODE_TUNNEL=m
CONFIG_INET6_XFRM_MODE_BEET=m
CONFIG_IPV6_SIT=m
CONFIG_DM_CRYPT=m
CONFIG_CRYPTO_RNG=m
CONFIG_CRYPTO_ANSI_CPRNG=m

What I'm trying to say is that there is a high probability that people
will continue to use just the kernel image for exynos_defconfig and
will therefore miss SBS battery support altogether (which is only 3.6
kB of code more in the kernel image so there is no much gain in making
it modular currently).

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

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

Re: [RESEND PATCH 1/2] ARM: dts: Improve Peach Pit and Pi power scheme

[Doug Anderson]

Javier,

On Mon, Aug 11, 2014 at 4:38 AM, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
 The DeviceTree files for the Peach Pit and Pi machines have
 a simplistic model of the connections between the different
 regulators since not all the tps65090 regulators get their
 input supply voltage from the VDC. DCDC1-3, LD0-1 and fet7
 parent supply is indded VDC but the fet1-6 get their input
 supply from the DCDC1 and DCDC2 output voltage rails.

 Update the DeviceTree to better reflect the real connections
 between tps65090 regulators. Having this information in the
 DTS is useful since FETs are switches that don't provide an
 output voltage so the regulator core needs to fetch the FET
 parent output voltage if the child voltage is queried.

 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Acked-by: Mark Brown broo...@linaro.org
 ---
  arch/arm/boot/dts/exynos5420-peach-pit.dts | 12 ++--
  arch/arm/boot/dts/exynos5800-peach-pi.dts  | 12 ++--
  2 files changed, 12 insertions(+), 12 deletions(-)

Matches my schematics.  Kukjin: I think this could be applied to
for-next whenever it's convenient.

Acked-by: Doug Anderson diand...@chromium.org
--
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: [RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support

[Doug Anderson]

Bartlomiej,

On Mon, Aug 11, 2014 at 8:42 AM, Bartlomiej Zolnierkiewicz
b.zolnier...@samsung.com wrote:

 Hi,

 On Monday, August 11, 2014 02:52:27 PM Javier Martinez Canillas wrote:
 Hello Bartlomiej,

 On 08/11/2014 02:40 PM, Bartlomiej Zolnierkiewicz wrote:
  index fc7d168..c390bb9 100644
  --- a/arch/arm/configs/exynos_defconfig
  +++ b/arch/arm/configs/exynos_defconfig
  @@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y
   CONFIG_I2C_S3C2410=y
   CONFIG_DEBUG_GPIO=y
   CONFIG_POWER_SUPPLY=y
  +CONFIG_BATTERY_SBS=m
 
  Why not make it =y?
 
  Rationale:
  - currently no hardware related option uses =m in exynos_defconfig
  - it would match the SBS option usage in multi_v7_defconfig
 
   CONFIG_CHARGER_TPS65090=y
   # CONFIG_HWMON is not set
   CONFIG_THERMAL=y
 

 I know but personally I think this should be changed. The idea of having a 
 multi
 platform kernel is to build a single kernel image that can be used to boot
 different platforms. Not all platforms have a SBS-compliant battery so this
 support shouldn't be built in the kernel image IMHO.

 This also matches to what real users will do since distributions most likely
 will have a minimal kernel and every possible hardware support will be 
 enabled
 as a loadable kernel module. This is what distros do for other platforms too.

 If someone has a different use case and wants a kernel image that is 
 optimized
 for a particular platform then she has to create its own defconfig anyways.

 Distributions usually use their own configs anyway and the current most
 popular use case for exynos_defconfig (not multi_v7_defconfig) seems to
 be to build kernel image alone and use it without any modules:

 $ grep =m arch/arm/configs/exynos_defconfig
 CONFIG_DM_CRYPT=m

 $ grep =m .config
 CONFIG_NET_IP_TUNNEL=m
 CONFIG_INET_TUNNEL=m
 CONFIG_IPV6=m
 CONFIG_INET6_XFRM_MODE_TRANSPORT=m
 CONFIG_INET6_XFRM_MODE_TUNNEL=m
 CONFIG_INET6_XFRM_MODE_BEET=m
 CONFIG_IPV6_SIT=m
 CONFIG_DM_CRYPT=m
 CONFIG_CRYPTO_RNG=m
 CONFIG_CRYPTO_ANSI_CPRNG=m

 What I'm trying to say is that there is a high probability that people
 will continue to use just the kernel image for exynos_defconfig and
 will therefore miss SBS battery support altogether (which is only 3.6
 kB of code more in the kernel image so there is no much gain in making
 it modular currently).

I'm not against making it =y for exynos_defconfig.  I do pretty
strongly agree that the multi_v7 version should be =m eventually,
though.  We'd need to do everything we can to make that kernel
smaller.

-Doug
--
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: [RESEND PATCH 2/2] ARM: dts: Add tps65090 FET constraints on Peach Pit and Pi

[Mark Brown]

On Mon, Aug 11, 2014 at 08:57:24AM -0700, Doug Anderson wrote:
 On Mon, Aug 11, 2014 at 4:38 AM, Javier Martinez Canillas

  After the switch is turned on, a safety timer is started
  and before this timer times out the output voltage must
  have reached the input voltage. Otherwise the switch is
  turned off expecting an overload condition.

  So using the maximum output voltage slew rate and the timer
  minimum and maximum timeouts, a voltage constraints can be
  expressed as bounded limits for the timeout. That is what
  is used in the board schematics and should be in the DT too.

 I don't understand this, but if you and Mark are happy with it...

I have not looked at this change to my knowledge.

 ...I'm also not 100% certain what the above description has to do with
 this change, but I'll admit to having only skimmed some of the earlier
 conversations.

It's not at all clear to me either looking at the quoted section.


signature.asc
Description: Digital signature

Re: [RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support

[Javier Martinez Canillas]

Hello,

On 08/11/2014 05:59 PM, Doug Anderson wrote:
 Bartlomiej,
 
 On Mon, Aug 11, 2014 at 8:42 AM, Bartlomiej Zolnierkiewicz
 b.zolnier...@samsung.com wrote:

 Hi,

 On Monday, August 11, 2014 02:52:27 PM Javier Martinez Canillas wrote:
 Hello Bartlomiej,

 On 08/11/2014 02:40 PM, Bartlomiej Zolnierkiewicz wrote:
  index fc7d168..c390bb9 100644
  --- a/arch/arm/configs/exynos_defconfig
  +++ b/arch/arm/configs/exynos_defconfig
  @@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y
   CONFIG_I2C_S3C2410=y
   CONFIG_DEBUG_GPIO=y
   CONFIG_POWER_SUPPLY=y
  +CONFIG_BATTERY_SBS=m
 
  Why not make it =y?
 
  Rationale:
  - currently no hardware related option uses =m in exynos_defconfig
  - it would match the SBS option usage in multi_v7_defconfig
 
   CONFIG_CHARGER_TPS65090=y
   # CONFIG_HWMON is not set
   CONFIG_THERMAL=y
 

 I know but personally I think this should be changed. The idea of having a 
 multi
 platform kernel is to build a single kernel image that can be used to boot
 different platforms. Not all platforms have a SBS-compliant battery so this
 support shouldn't be built in the kernel image IMHO.

 This also matches to what real users will do since distributions most likely
 will have a minimal kernel and every possible hardware support will be 
 enabled
 as a loadable kernel module. This is what distros do for other platforms 
 too.

 If someone has a different use case and wants a kernel image that is 
 optimized
 for a particular platform then she has to create its own defconfig anyways.

 Distributions usually use their own configs anyway and the current most
 popular use case for exynos_defconfig (not multi_v7_defconfig) seems to
 be to build kernel image alone and use it without any modules:

 $ grep =m arch/arm/configs/exynos_defconfig
 CONFIG_DM_CRYPT=m

 $ grep =m .config
 CONFIG_NET_IP_TUNNEL=m
 CONFIG_INET_TUNNEL=m
 CONFIG_IPV6=m
 CONFIG_INET6_XFRM_MODE_TRANSPORT=m
 CONFIG_INET6_XFRM_MODE_TUNNEL=m
 CONFIG_INET6_XFRM_MODE_BEET=m
 CONFIG_IPV6_SIT=m
 CONFIG_DM_CRYPT=m
 CONFIG_CRYPTO_RNG=m
 CONFIG_CRYPTO_ANSI_CPRNG=m

 What I'm trying to say is that there is a high probability that people
 will continue to use just the kernel image for exynos_defconfig and
 will therefore miss SBS battery support altogether (which is only 3.6
 kB of code more in the kernel image so there is no much gain in making
 it modular currently).
 
 I'm not against making it =y for exynos_defconfig.  I do pretty
 strongly agree that the multi_v7 version should be =m eventually,
 though.  We'd need to do everything we can to make that kernel
 smaller.


Same for me. I don't have such a strong opinion about this so if you think that
I should re-spin to change to =m, I will.

I do think that we should try to keep the delta between exynos_defconfig and
multi_v7_defconfig as small as possible and eventually even get rid of
exynos_defconfig. Since building everything as built-in and having a config
targeted to a single platform is not aligned with the effort to have support for
multi platforms kernels.

 -Doug
 

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: [RESEND PATCH 2/2] ARM: dts: Add tps65090 FET constraints on Peach Pit and Pi

[Javier Martinez Canillas]

Hello Mark,

On 08/11/2014 06:02 PM, Mark Brown wrote:
 On Mon, Aug 11, 2014 at 08:57:24AM -0700, Doug Anderson wrote:
 On Mon, Aug 11, 2014 at 4:38 AM, Javier Martinez Canillas
 
  After the switch is turned on, a safety timer is started
  and before this timer times out the output voltage must
  have reached the input voltage. Otherwise the switch is
  turned off expecting an overload condition.
 
  So using the maximum output voltage slew rate and the timer
  minimum and maximum timeouts, a voltage constraints can be
  expressed as bounded limits for the timeout. That is what
  is used in the board schematics and should be in the DT too.
 
 I don't understand this, but if you and Mark are happy with it...
 
 I have not looked at this change to my knowledge.
 

No worries, I have to re-spin anyways to fix the 17v typo that Doug pointed out.
But basically is related to our previous discussion in patch:

[RFC 3/5] regulator: core: Only apply constraints if available on list voltage

where you explained [0] to me that child regulators should explicit set their
constraints instead of getting from its parent supply. So this patch adds the
needed constraints for the children FETs even when their output voltage depend
on its parent supply.

 ...I'm also not 100% certain what the above description has to do with
 this change, but I'll admit to having only skimmed some of the earlier
 conversations.
 
 It's not at all clear to me either looking at the quoted section.
 

Yes, the commit message is not great to say the least. Also I didn't have the
last version of the documentation so I misunderstood from where the constraints
mentioned in the schematics came from. Will fix the commit message when posting 
v2.

Thanks a lot and best regards,
Javier

[0]: https://lkml.org/lkml/2014/7/30/99
--
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] reset: Add a defer reset object to send board specific reset

[Maxime Ripard]

On Fri, Aug 08, 2014 at 04:23:09PM +0200, Philipp Zabel wrote:
 Am Dienstag, den 08.07.2014, 11:38 +0200 schrieb Linus Walleij:
  On Tue, Jul 8, 2014 at 10:05 AM, Maxime Ripard
  maxime.rip...@free-electrons.com wrote:
   On Tue, Jul 08, 2014 at 09:52:03AM +0200, Linus Walleij wrote:
   On Wed, Jun 18, 2014 at 3:37 PM, Houcheng Lin houch...@gmail.com wrote:
  
The Problem
---
The reset signal on a hardware board is send either:
- during machine initialization
- during bus master's initialization
  
   I just thought about this a bit, since there isn't already a generic GPIO
   reset driver, just call this drivers/reset/reset-gpio.c and make the
   ability to deferral just a configuration detail of the GPIO reset driver.
  
   Philipp has been working on one for quite some time. See
   http://www.spinics.net/lists/arm-kernel/msg321927.html
  
   However, it seems to progress slowly, and we don't seem to be able to
   reach a consensus here.
 
 Mostly because Maxime and I seem to have a completely different opinion
 and nobody else argued one way or the other.

Yep, mostly because I don't see how a generic approach can work.

The existing reset-gpios property only provide the gpio to use, but
some informations are encoded in the driver, such as the reset
duration, or a reset sequence if any.

How do you plan on giving that information to your generic driver?

The only solution I can think of would be to add an extra property
that your code would parse. But then, you break the existing DT
bindings.

And if we're going to break those bindings, at least do it in a way
consistent with reset bindings.

Plus, your approach doesn't cover the weird corner cases such as:
  - reset-gpio
  - wlf,reset-gpios
  - phy-reset-gpios
  - snps,reset-gpio
  - the drivers that need several gpio and expect the reset one as a
positional argument.
  - etc.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support

[Bartlomiej Zolnierkiewicz]

Hi,

On Monday, August 11, 2014 06:23:01 PM Javier Martinez Canillas wrote:
 Hello,
 
 On 08/11/2014 05:59 PM, Doug Anderson wrote:
  Bartlomiej,
  
  On Mon, Aug 11, 2014 at 8:42 AM, Bartlomiej Zolnierkiewicz
  b.zolnier...@samsung.com wrote:
 
  Hi,
 
  On Monday, August 11, 2014 02:52:27 PM Javier Martinez Canillas wrote:
  Hello Bartlomiej,
 
  On 08/11/2014 02:40 PM, Bartlomiej Zolnierkiewicz wrote:
   index fc7d168..c390bb9 100644
   --- a/arch/arm/configs/exynos_defconfig
   +++ b/arch/arm/configs/exynos_defconfig
   @@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y
CONFIG_I2C_S3C2410=y
CONFIG_DEBUG_GPIO=y
CONFIG_POWER_SUPPLY=y
   +CONFIG_BATTERY_SBS=m
  
   Why not make it =y?
  
   Rationale:
   - currently no hardware related option uses =m in exynos_defconfig
   - it would match the SBS option usage in multi_v7_defconfig
  
CONFIG_CHARGER_TPS65090=y
# CONFIG_HWMON is not set
CONFIG_THERMAL=y
  
 
  I know but personally I think this should be changed. The idea of having 
  a multi
  platform kernel is to build a single kernel image that can be used to boot
  different platforms. Not all platforms have a SBS-compliant battery so 
  this
  support shouldn't be built in the kernel image IMHO.
 
  This also matches to what real users will do since distributions most 
  likely
  will have a minimal kernel and every possible hardware support will be 
  enabled
  as a loadable kernel module. This is what distros do for other platforms 
  too.
 
  If someone has a different use case and wants a kernel image that is 
  optimized
  for a particular platform then she has to create its own defconfig 
  anyways.
 
  Distributions usually use their own configs anyway and the current most
  popular use case for exynos_defconfig (not multi_v7_defconfig) seems to
  be to build kernel image alone and use it without any modules:
 
  $ grep =m arch/arm/configs/exynos_defconfig
  CONFIG_DM_CRYPT=m
 
  $ grep =m .config
  CONFIG_NET_IP_TUNNEL=m
  CONFIG_INET_TUNNEL=m
  CONFIG_IPV6=m
  CONFIG_INET6_XFRM_MODE_TRANSPORT=m
  CONFIG_INET6_XFRM_MODE_TUNNEL=m
  CONFIG_INET6_XFRM_MODE_BEET=m
  CONFIG_IPV6_SIT=m
  CONFIG_DM_CRYPT=m
  CONFIG_CRYPTO_RNG=m
  CONFIG_CRYPTO_ANSI_CPRNG=m
 
  What I'm trying to say is that there is a high probability that people
  will continue to use just the kernel image for exynos_defconfig and
  will therefore miss SBS battery support altogether (which is only 3.6
  kB of code more in the kernel image so there is no much gain in making
  it modular currently).
  
  I'm not against making it =y for exynos_defconfig.  I do pretty
  strongly agree that the multi_v7 version should be =m eventually,
  though.  We'd need to do everything we can to make that kernel
  smaller.
 
 
 Same for me. I don't have such a strong opinion about this so if you think 
 that
 I should re-spin to change to =m, I will.
 
 I do think that we should try to keep the delta between exynos_defconfig and
 multi_v7_defconfig as small as possible and eventually even get rid of
 exynos_defconfig. Since building everything as built-in and having a config

I completely agree.  I proposed exynos_defconfig removal as soon as
Exynos gained multiplatform support (and before exynos_defconfig
started getting out-of-sync with multi_v7_defconfig).  There were
arguments that it is still useful in some cases.  I think that if
it would be possible to go from a modular multi_v7_defconfig to
a modular/built-in single platform config (using a script?) all
such use cases will be covered.

 targeted to a single platform is not aligned with the effort to have support 
 for
 multi platforms kernels.

Currently even for multi_v7_defconfig =m seems to be an exception
from the general rule:

$ grep =m arch/arm/configs/multi_v7_defconfig 
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
CONFIG_IPV6_MIP6=m
CONFIG_IPV6_TUNNEL=m
CONFIG_CFG80211=m
CONFIG_MAC80211=m
CONFIG_BRCMFMAC=m
CONFIG_RT2X00=m
CONFIG_RT2800USB=m

$ wc -l arch/arm/configs/multi_v7_defconfig 
405 arch/arm/configs/multi_v7_defconfig

so I would vote for CONFIG_BATTERY_SBS=y for both configs.  Especially
since it results in only 3.6 kB bigger kernel image (0.05% kernel size
increase for kernel image built with exynos_defconfig, probably a lot
less for multi_v7_defconfig one).

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

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

Re: [RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support

[Doug Anderson]

Hi,

On Mon, Aug 11, 2014 at 10:28 AM, Bartlomiej Zolnierkiewicz
b.zolnier...@samsung.com wrote:

 Hi,

 On Monday, August 11, 2014 06:23:01 PM Javier Martinez Canillas wrote:
 Hello,

 On 08/11/2014 05:59 PM, Doug Anderson wrote:
  Bartlomiej,
 
  On Mon, Aug 11, 2014 at 8:42 AM, Bartlomiej Zolnierkiewicz
  b.zolnier...@samsung.com wrote:
 
  Hi,
 
  On Monday, August 11, 2014 02:52:27 PM Javier Martinez Canillas wrote:
  Hello Bartlomiej,
 
  On 08/11/2014 02:40 PM, Bartlomiej Zolnierkiewicz wrote:
   index fc7d168..c390bb9 100644
   --- a/arch/arm/configs/exynos_defconfig
   +++ b/arch/arm/configs/exynos_defconfig
   @@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y
CONFIG_I2C_S3C2410=y
CONFIG_DEBUG_GPIO=y
CONFIG_POWER_SUPPLY=y
   +CONFIG_BATTERY_SBS=m
  
   Why not make it =y?
  
   Rationale:
   - currently no hardware related option uses =m in exynos_defconfig
   - it would match the SBS option usage in multi_v7_defconfig
  
CONFIG_CHARGER_TPS65090=y
# CONFIG_HWMON is not set
CONFIG_THERMAL=y
  
 
  I know but personally I think this should be changed. The idea of having 
  a multi
  platform kernel is to build a single kernel image that can be used to 
  boot
  different platforms. Not all platforms have a SBS-compliant battery so 
  this
  support shouldn't be built in the kernel image IMHO.
 
  This also matches to what real users will do since distributions most 
  likely
  will have a minimal kernel and every possible hardware support will be 
  enabled
  as a loadable kernel module. This is what distros do for other platforms 
  too.
 
  If someone has a different use case and wants a kernel image that is 
  optimized
  for a particular platform then she has to create its own defconfig 
  anyways.
 
  Distributions usually use their own configs anyway and the current most
  popular use case for exynos_defconfig (not multi_v7_defconfig) seems to
  be to build kernel image alone and use it without any modules:
 
  $ grep =m arch/arm/configs/exynos_defconfig
  CONFIG_DM_CRYPT=m
 
  $ grep =m .config
  CONFIG_NET_IP_TUNNEL=m
  CONFIG_INET_TUNNEL=m
  CONFIG_IPV6=m
  CONFIG_INET6_XFRM_MODE_TRANSPORT=m
  CONFIG_INET6_XFRM_MODE_TUNNEL=m
  CONFIG_INET6_XFRM_MODE_BEET=m
  CONFIG_IPV6_SIT=m
  CONFIG_DM_CRYPT=m
  CONFIG_CRYPTO_RNG=m
  CONFIG_CRYPTO_ANSI_CPRNG=m
 
  What I'm trying to say is that there is a high probability that people
  will continue to use just the kernel image for exynos_defconfig and
  will therefore miss SBS battery support altogether (which is only 3.6
  kB of code more in the kernel image so there is no much gain in making
  it modular currently).
 
  I'm not against making it =y for exynos_defconfig.  I do pretty
  strongly agree that the multi_v7 version should be =m eventually,
  though.  We'd need to do everything we can to make that kernel
  smaller.
 

 Same for me. I don't have such a strong opinion about this so if you think 
 that
 I should re-spin to change to =m, I will.

 I do think that we should try to keep the delta between exynos_defconfig and
 multi_v7_defconfig as small as possible and eventually even get rid of
 exynos_defconfig. Since building everything as built-in and having a config

 I completely agree.  I proposed exynos_defconfig removal as soon as
 Exynos gained multiplatform support (and before exynos_defconfig
 started getting out-of-sync with multi_v7_defconfig).  There were
 arguments that it is still useful in some cases.  I think that if
 it would be possible to go from a modular multi_v7_defconfig to
 a modular/built-in single platform config (using a script?) all
 such use cases will be covered.

There's one really nice thing about having an exynos_defconfig.  It
makes it a little easier to tease apart what's actually needed if you
just want to build a product kernel that support exynos.

Most product kernels shipping in embedded devices only support one or
maybe a small number of SoCs.  If you need to try to figure out what
parts of the multi_v7 config is relevant then it's very hard.

It's also nice to help measure multiplatform code bloat.  You can keep
measuring the output kernel size of the exynos kernel to see how much
bloat all of the mutliplatform stuff has added.


 so I would vote for CONFIG_BATTERY_SBS=y for both configs.  Especially
 since it results in only 3.6 kB bigger kernel image (0.05% kernel size
 increase for kernel image built with exynos_defconfig, probably a lot
 less for multi_v7_defconfig one).

Death by 1000 cuts is a very painful death indeed, even if each cut is small.

-Doug
--
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: [RESEND PATCH 1/1] ARM: exynos_defconfig: Enable SBS battery support

[Javier Martinez Canillas]

Hello Bartlomiej,

On 08/11/2014 07:28 PM, Bartlomiej Zolnierkiewicz wrote:
 
 Hi,
 
 On Monday, August 11, 2014 06:23:01 PM Javier Martinez Canillas wrote:
 Hello,
 
 On 08/11/2014 05:59 PM, Doug Anderson wrote:
  Bartlomiej,
  
  On Mon, Aug 11, 2014 at 8:42 AM, Bartlomiej Zolnierkiewicz
  b.zolnier...@samsung.com wrote:
 
  Hi,
 
  On Monday, August 11, 2014 02:52:27 PM Javier Martinez Canillas wrote:
  Hello Bartlomiej,
 
  On 08/11/2014 02:40 PM, Bartlomiej Zolnierkiewicz wrote:
   index fc7d168..c390bb9 100644
   --- a/arch/arm/configs/exynos_defconfig
   +++ b/arch/arm/configs/exynos_defconfig
   @@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y
CONFIG_I2C_S3C2410=y
CONFIG_DEBUG_GPIO=y
CONFIG_POWER_SUPPLY=y
   +CONFIG_BATTERY_SBS=m
  
   Why not make it =y?
  
   Rationale:
   - currently no hardware related option uses =m in exynos_defconfig
   - it would match the SBS option usage in multi_v7_defconfig
  
CONFIG_CHARGER_TPS65090=y
# CONFIG_HWMON is not set
CONFIG_THERMAL=y
  
 
  I know but personally I think this should be changed. The idea of having 
  a multi
  platform kernel is to build a single kernel image that can be used to 
  boot
  different platforms. Not all platforms have a SBS-compliant battery so 
  this
  support shouldn't be built in the kernel image IMHO.
 
  This also matches to what real users will do since distributions most 
  likely
  will have a minimal kernel and every possible hardware support will be 
  enabled
  as a loadable kernel module. This is what distros do for other platforms 
  too.
 
  If someone has a different use case and wants a kernel image that is 
  optimized
  for a particular platform then she has to create its own defconfig 
  anyways.
 
  Distributions usually use their own configs anyway and the current most
  popular use case for exynos_defconfig (not multi_v7_defconfig) seems to
  be to build kernel image alone and use it without any modules:
 
  $ grep =m arch/arm/configs/exynos_defconfig
  CONFIG_DM_CRYPT=m
 
  $ grep =m .config
  CONFIG_NET_IP_TUNNEL=m
  CONFIG_INET_TUNNEL=m
  CONFIG_IPV6=m
  CONFIG_INET6_XFRM_MODE_TRANSPORT=m
  CONFIG_INET6_XFRM_MODE_TUNNEL=m
  CONFIG_INET6_XFRM_MODE_BEET=m
  CONFIG_IPV6_SIT=m
  CONFIG_DM_CRYPT=m
  CONFIG_CRYPTO_RNG=m
  CONFIG_CRYPTO_ANSI_CPRNG=m
 
  What I'm trying to say is that there is a high probability that people
  will continue to use just the kernel image for exynos_defconfig and
  will therefore miss SBS battery support altogether (which is only 3.6
  kB of code more in the kernel image so there is no much gain in making
  it modular currently).
  
  I'm not against making it =y for exynos_defconfig.  I do pretty
  strongly agree that the multi_v7 version should be =m eventually,
  though.  We'd need to do everything we can to make that kernel
  smaller.
 
 
 Same for me. I don't have such a strong opinion about this so if you think 
 that
 I should re-spin to change to =m, I will.
 
 I do think that we should try to keep the delta between exynos_defconfig and
 multi_v7_defconfig as small as possible and eventually even get rid of
 exynos_defconfig. Since building everything as built-in and having a config
 
 I completely agree.  I proposed exynos_defconfig removal as soon as
 Exynos gained multiplatform support (and before exynos_defconfig
 started getting out-of-sync with multi_v7_defconfig).  There were
 arguments that it is still useful in some cases.  I think that if
 it would be possible to go from a modular multi_v7_defconfig to
 a modular/built-in single platform config (using a script?) all
 such use cases will be covered.
 
 targeted to a single platform is not aligned with the effort to have support 
 for
 multi platforms kernels.
 
 Currently even for multi_v7_defconfig =m seems to be an exception
 from the general rule:
 
 $ grep =m arch/arm/configs/multi_v7_defconfig 
 CONFIG_INET6_AH=m
 CONFIG_INET6_ESP=m
 CONFIG_INET6_IPCOMP=m
 CONFIG_IPV6_MIP6=m
 CONFIG_IPV6_TUNNEL=m
 CONFIG_CFG80211=m
 CONFIG_MAC80211=m
 CONFIG_BRCMFMAC=m
 CONFIG_RT2X00=m
 CONFIG_RT2800USB=m
 
 $ wc -l arch/arm/configs/multi_v7_defconfig 
 405 arch/arm/configs/multi_v7_defconfig
 

Again, I think this is more of a consequence of people adding the config they
use (which as you said in most cases is just built everything in the kernel to
avoid copying modules) than something that was made on purpose.

 so I would vote for CONFIG_BATTERY_SBS=y for both configs.  Especially
 since it results in only 3.6 kB bigger kernel image (0.05% kernel size
 increase for kernel image built with exynos_defconfig, probably a lot
 less for multi_v7_defconfig one).
 

I'll repost with =y for exynos_defconfig but I really think that for
multi_v7_defconfig we should have everything as a module if possible. It's just
3.6 kB but if every single platform do the same the kernel will be quite bloated
for little gain.

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

Best 

Re: [RESEND PATCH 2/2] ARM: dts: Add tps65090 FET constraints on Peach Pit and Pi

[Javier Martinez Canillas]

Hello Doug,

On 08/11/2014 05:57 PM, Doug Anderson wrote:
 Javier,
 
 On Mon, Aug 11, 2014 at 4:38 AM, Javier Martinez Canillas
 javier.marti...@collabora.co.uk wrote:
 Both Exynos5420 Peach Pit and Exynos5800 Peach Pi boards
 have a tps65090 PMU that has a number of switches (FETs)
 that are just on/off devices but they do have a current
 limit and the output voltage of the switch is ramped up
 within a controlled slope.

 After the switch is turned on, a safety timer is started
 and before this timer times out the output voltage must
 have reached the input voltage. Otherwise the switch is
 turned off expecting an overload condition.

 So using the maximum output voltage slew rate and the timer
 minimum and maximum timeouts, a voltage constraints can be
 expressed as bounded limits for the timeout. That is what
 is used in the board schematics and should be in the DT too.
 
 I don't understand this, but if you and Mark are happy with it...
 
 ...I'm also not 100% certain what the above description has to do with
 this change, but I'll admit to having only skimmed some of the earlier
 conversations.


As I stated before, I wrongly assumed from where the constraints in the
schematics came from. From the latest doc I now know that there is a
recommended operating conditions table. I'll fix it in v2, sorry for the
confusion...

 
 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 ---
  arch/arm/boot/dts/exynos5420-peach-pit.dts | 14 ++
  arch/arm/boot/dts/exynos5800-peach-pi.dts  | 14 ++
  2 files changed, 28 insertions(+)

 diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
 b/arch/arm/boot/dts/exynos5420-peach-pit.dts
 index d8710c1..eefafe6 100644
 --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
 +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
 @@ -386,27 +386,41 @@
 };
 tps65090_fet1: fet1 {
 regulator-name = vcd_led;
 +   regulator-min-microvolt = 
 500;
 +   regulator-max-microvolt = 
 170;
 
 This is almost certainly wrong.  Your max is smaller than your min.
 Perhaps you want an extra 0.
 
 };
 tps65090_fet2: fet2 {
 regulator-name = video_mid;
 +   regulator-min-microvolt = 
 450;
 +   regulator-max-microvolt = 
 550;
 regulator-always-on;
 };
 tps65090_fet3: fet3 {
 regulator-name = wwan_r;
 +   regulator-min-microvolt = 
 300;
 +   regulator-max-microvolt = 
 550;
 regulator-always-on;
 };
 tps65090_fet4: fet4 {
 regulator-name = sdcard;
 +   regulator-min-microvolt = 
 300;
 +   regulator-max-microvolt = 
 550;
 regulator-always-on;
 };
 tps65090_fet5: fet5 {
 regulator-name = camout;
 +   regulator-min-microvolt = 
 300;
 +   regulator-max-microvolt = 
 550;
 };
 tps65090_fet6: fet6 {
 regulator-name = lcd_vdd;
 +   regulator-min-microvolt = 
 300;
 +   regulator-max-microvolt = 
 550;
 };
 tps65090_fet7: fet7 {
 regulator-name = 
 video_mid_1a;
 +   regulator-min-microvolt = 
 300;
 +   regulator-max-microvolt = 
 550;
 regulator-always-on;
 };
 tps65090_ldo1: ldo1 {
 diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
 b/arch/arm/boot/dts/exynos5800-peach-pi.dts
 index 07b29b7..5c38bc0 100644
 --- 

[PATCH v2 1/1] ARM: exynos_defconfig: Enable SBS battery support

[Javier Martinez Canillas]

Many Exynos5 boards (e.g: Snow, Peach Pit and Pi) have
a SBS-compliant gas gauge battery. Enable to built it
so the needed support is available for these boards.

Suggested-by: Doug Anderson diand...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Acked-by: Kukjin Kim kgene@samsung.com
Reviewed-by: Doug Anderson diand...@chromium.org
---

Changes since v1:
 - Don't build it as a module since is the exception in exynos_defconfig.
   Suggested by Bartlomiej Zolnierkiewicz.

 arch/arm/configs/exynos_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/exynos_defconfig 
b/arch/arm/configs/exynos_defconfig
index fc7d168..c390bb9 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -77,6 +77,7 @@ CONFIG_SPI_S3C64XX=y
 CONFIG_I2C_S3C2410=y
 CONFIG_DEBUG_GPIO=y
 CONFIG_POWER_SUPPLY=y
+CONFIG_BATTERY_SBS=y
 CONFIG_CHARGER_TPS65090=y
 # CONFIG_HWMON is not set
 CONFIG_THERMAL=y
-- 
2.0.0.rc2

--
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: [PATCHv10 4/5] ARM: dts: socfpga: unuse the slot-node and deprecate the supports-highspeed for dw-mmc

[Dinh Nguyen]

On Thu, Aug 7, 2014 at 2:38 AM, Jaehoon Chung jh80.ch...@samsung.com wrote:
 dw-mmc controller can support multiple slots.
 But, there are no use-cases anywhere. So we don't need to support the
 slot-node for dw-mmc controller.
 And supports-highspeed property in dw-mmc is deprecated.
 supports-highspeed property can be replaced with cap-sd/mmc-highspeed.

 Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
 Reviewed-by: Tushar Behera trbli...@gmail.com
 Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
 Acked-by: Seungwon Jeon tgih@samsung.com
 Acked-by: Dinh Nguyen dingu...@altera.com
 ---

I've queued this patch in my tree for v3.18.

Thanks,
Dinh

  arch/arm/boot/dts/socfpga_arria5.dtsi   |9 +++--
  arch/arm/boot/dts/socfpga_cyclone5.dtsi |9 +++--
  arch/arm/boot/dts/socfpga_vt.dts|9 +++--
  3 files changed, 9 insertions(+), 18 deletions(-)

 diff --git a/arch/arm/boot/dts/socfpga_arria5.dtsi 
 b/arch/arm/boot/dts/socfpga_arria5.dtsi
 index 12d1c2c..468fc4c 100644
 --- a/arch/arm/boot/dts/socfpga_arria5.dtsi
 +++ b/arch/arm/boot/dts/socfpga_arria5.dtsi
 @@ -29,13 +29,10 @@

 dwmmc0@ff704000 {
 num-slots = 1;
 -   supports-highspeed;
 broken-cd;
 -
 -   slot@0 {
 -   reg = 0;
 -   bus-width = 4;
 -   };
 +   bus-width = 4;
 +   cap-mmc-highspeed;
 +   cap-sd-highspeed;
 };

 sysmgr@ffd08000 {
 diff --git a/arch/arm/boot/dts/socfpga_cyclone5.dtsi 
 b/arch/arm/boot/dts/socfpga_cyclone5.dtsi
 index bf51182..1ee03c4 100644
 --- a/arch/arm/boot/dts/socfpga_cyclone5.dtsi
 +++ b/arch/arm/boot/dts/socfpga_cyclone5.dtsi
 @@ -30,13 +30,10 @@

 dwmmc0@ff704000 {
 num-slots = 1;
 -   supports-highspeed;
 broken-cd;
 -
 -   slot@0 {
 -   reg = 0;
 -   bus-width = 4;
 -   };
 +   bus-width = 4;
 +   cap-mmc-highspeed;
 +   cap-sd-highspeed;
 };

 ethernet@ff702000 {
 diff --git a/arch/arm/boot/dts/socfpga_vt.dts 
 b/arch/arm/boot/dts/socfpga_vt.dts
 index 09792b4..f9345e0 100644
 --- a/arch/arm/boot/dts/socfpga_vt.dts
 +++ b/arch/arm/boot/dts/socfpga_vt.dts
 @@ -43,13 +43,10 @@

 dwmmc0@ff704000 {
 num-slots = 1;
 -   supports-highspeed;
 broken-cd;
 -
 -   slot@0 {
 -   reg = 0;
 -   bus-width = 4;
 -   };
 +   bus-width = 4;
 +   cap-mmc-highspeed;
 +   cap-sd-highspeed;
 };

 ethernet@ff70 {
 --
 1.7.9.5


 ___
 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

[PATCHv2 0/5] rtc: s3c: Refactoring s3c-rtc driver and support Exynos3250 RTC

[y]

From: Chanwoo Choi cw00.c...@samsung.com

This patchset clean up codes to improve readability as following and support
the RTC of Exynos3250 SoC.
- Remove global variables and then use new s3c_rtc structure
- Remove warn message with checking checkpatch script
- Use variant structure according to SoC type instead of legacy enum 
variable(s3c_cpu_type)

Changes from v1:
- Fix NULL pointer panic of s3c_rtc_settime()
- Check info-base value to protect NULL pointer panic

Chanwoo Choi (5):
  rtc: s3c: Define s3c_rtc structure to remove global variables.
  rtc: s3c: Remove warning message when checking coding style with checkpatch 
script
  rtc: s3c: Add s3c_rtc_data structure to use variant data instead of 
s3c_cpu_type
  rtc: s3c: Add support for RTC of Exynos3250 SoC
  ARM: dts: Fix wrong compatible string of Exynos3250 RTC dt node

 Documentation/devicetree/bindings/rtc/s3c-rtc.txt |   3 +
 arch/arm/boot/dts/exynos3250.dtsi |   2 +-
 drivers/rtc/rtc-s3c.c | 869 ++
 3 files changed, 553 insertions(+), 321 deletions(-)

-- 
1.8.0

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

[PATCHv2 3/5] rtc: s3c: Add s3c_rtc_data structure to use variant data instead of s3c_cpu_type

[y]

From: Chanwoo Choi cw00.c...@samsung.com

This patch add s3c_rtc_data structure to variant data according to SoC type.
The s3c_rtc_data structure includes some functions to control RTC operation
and specific data dependent on SoC type.

Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/rtc/rtc-s3c.c | 464 +++---
 1 file changed, 289 insertions(+), 175 deletions(-)

diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index d8f25bd..26a88f9 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -32,17 +32,6 @@
 #include asm/irq.h
 #include rtc-s3c.h
 
-enum s3c_cpu_type {
-   TYPE_S3C2410,
-   TYPE_S3C2416,
-   TYPE_S3C2443,
-   TYPE_S3C64XX,
-};
-
-struct s3c_rtc_drv_data {
-   int cpu_type;
-};
-
 struct s3c_rtc {
struct device *dev;
struct rtc_device *rtc;
@@ -51,7 +40,7 @@ struct s3c_rtc {
struct clk *rtc_clk;
bool enabled;
 
-   enum s3c_cpu_type cpu_type;
+   struct s3c_rtc_data *data;
 
int irq_alarm;
int irq_tick;
@@ -63,6 +52,19 @@ struct s3c_rtc {
bool wake_en;
 };
 
+struct s3c_rtc_data {
+   int max_user_freq;
+
+   void (*irq_handler) (struct s3c_rtc *info, int mask);
+   void (*set_freq) (struct s3c_rtc *info, int freq);
+   void (*enable_tick) (struct s3c_rtc *info, struct seq_file *seq);
+   void (*select_tick_clk) (struct s3c_rtc *info);
+   void (*save_tick_cnt) (struct s3c_rtc *info);
+   void (*restore_tick_cnt) (struct s3c_rtc *info);
+   void (*enable) (struct s3c_rtc *info);
+   void (*disable) (struct s3c_rtc *info);
+};
+
 static void s3c_rtc_alarm_clk_enable(struct s3c_rtc *info, bool enable)
 {
unsigned long irq_flags;
@@ -83,34 +85,22 @@ static void s3c_rtc_alarm_clk_enable(struct s3c_rtc *info, 
bool enable)
 }
 
 /* IRQ Handlers */
-static irqreturn_t s3c_rtc_alarmirq(int irq, void *id)
+static irqreturn_t s3c_rtc_tickirq(int irq, void *id)
 {
struct s3c_rtc *info = (struct s3c_rtc *)id;
 
-   clk_enable(info-rtc_clk);
-   rtc_update_irq(info-rtc, 1, RTC_AF | RTC_IRQF);
-
-   if (info-cpu_type == TYPE_S3C64XX)
-   writeb(S3C2410_INTP_ALM, info-base + S3C2410_INTP);
-
-   clk_disable(info-rtc_clk);
-
-   s3c_rtc_alarm_clk_enable(info, false);
+   if (info-data-irq_handler)
+   info-data-irq_handler(info, S3C2410_INTP_TIC);
 
return IRQ_HANDLED;
 }
 
-static irqreturn_t s3c_rtc_tickirq(int irq, void *id)
+static irqreturn_t s3c_rtc_alarmirq(int irq, void *id)
 {
struct s3c_rtc *info = (struct s3c_rtc *)id;
 
-   clk_enable(info-rtc_clk);
-   rtc_update_irq(info-rtc, 1, RTC_PF | RTC_IRQF);
-
-   if (info-cpu_type == TYPE_S3C64XX)
-   writeb(S3C2410_INTP_TIC, info-base + S3C2410_INTP);
-
-   clk_disable(info-rtc_clk);
+   if (info-data-irq_handler)
+   info-data-irq_handler(info, S3C2410_INTP_ALM);
 
return IRQ_HANDLED;
 }
@@ -140,36 +130,18 @@ static int s3c_rtc_setaie(struct device *dev, unsigned 
int enabled)
return 0;
 }
 
+/* Set RTC frequency */
 static int s3c_rtc_setfreq(struct s3c_rtc *info, int freq)
 {
-   unsigned int tmp = 0;
-   int val;
-
if (!is_power_of_2(freq))
return -EINVAL;
 
clk_enable(info-rtc_clk);
spin_lock_irq(info-pie_lock);
 
-   if (info-cpu_type != TYPE_S3C64XX) {
-   tmp = readb(info-base + S3C2410_TICNT);
-   tmp = S3C2410_TICNT_ENABLE;
-   }
-
-   val = (info-rtc-max_user_freq / freq) - 1;
-
-   if (info-cpu_type == TYPE_S3C2416 || info-cpu_type == TYPE_S3C2443) {
-   tmp |= S3C2443_TICNT_PART(val);
-   writel(S3C2443_TICNT1_PART(val), info-base + S3C2443_TICNT1);
+   if (info-data-set_freq)
+   info-data-set_freq(info, freq);
 
-   if (info-cpu_type == TYPE_S3C2416)
-   writel(S3C2416_TICNT2_PART(val),
-   info-base + S3C2416_TICNT2);
-   } else {
-   tmp |= val;
-   }
-
-   writel(tmp, info-base + S3C2410_TICNT);
spin_unlock_irq(info-pie_lock);
clk_disable(info-rtc_clk);
 
@@ -177,7 +149,6 @@ static int s3c_rtc_setfreq(struct s3c_rtc *info, int freq)
 }
 
 /* Time read/write */
-
 static int s3c_rtc_gettime(struct device *dev, struct rtc_time *rtc_tm)
 {
struct s3c_rtc *info = dev_get_drvdata(dev);
@@ -370,22 +341,17 @@ static int s3c_rtc_setalarm(struct device *dev, struct 
rtc_wkalrm *alrm)
 static int s3c_rtc_proc(struct device *dev, struct seq_file *seq)
 {
struct s3c_rtc *info = dev_get_drvdata(dev);
-   unsigned int ticnt;
 
if (!info-base)
return -EINVAL;
 
clk_enable(info-rtc_clk);
-   if (info-cpu_type == TYPE_S3C64XX) {
-   ticnt = readw(info-base + S3C2410_RTCCON);
-   

[PATCHv2 4/5] rtc: s3c: Add support for RTC of Exynos3250 SoC

[y]

From: Chanwoo Choi cw00.c...@samsung.com

This patch add support for RTC of Exynos3250 SoC. The Exynos3250 needs source
clock(32.768KHz) for RTC block. If source clock of RTC is registerd on clock
list of common clk framework, Exynos RTC drvier have to control this clock.

Clock list for s3c-rtc device:
- rtc : CLK_RTC of CLK_GATE_IP_PERIR is gate clock for RTC.
- rtc_src : XrtcXTI is 32.768.kHz source clock for RTC.
 (XRTCXTI: Specifies a clock from 32.768 kHz crystal pad with XRTCXTI and
 XRTCXTO pins. RTC uses this clock as the source of a real-time clock.)

Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
 Documentation/devicetree/bindings/rtc/s3c-rtc.txt |  1 +
 drivers/rtc/rtc-s3c.c | 93 ++-
 2 files changed, 93 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt 
b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
index 06db446..ab757b84 100644
--- a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
+++ b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
@@ -6,6 +6,7 @@ Required properties:
 * samsung,s3c2416-rtc - for controllers compatible with s3c2416 rtc.
 * samsung,s3c2443-rtc - for controllers compatible with s3c2443 rtc.
 * samsung,s3c6410-rtc - for controllers compatible with s3c6410 rtc.
+* samsung,exynos3250-rtc - for controllers compatible with exynos3250 
rtc.
 - reg: physical base address of the controller and length of memory mapped
   region.
 - interrupts: Two interrupt numbers to the cpu should be specified. First
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 26a88f9..90dcf51 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -38,6 +38,7 @@ struct s3c_rtc {
 
void __iomem *base;
struct clk *rtc_clk;
+   struct clk *rtc_src_clk;
bool enabled;
 
struct s3c_rtc_data *data;
@@ -54,6 +55,7 @@ struct s3c_rtc {
 
 struct s3c_rtc_data {
int max_user_freq;
+   bool needs_src_clk;
 
void (*irq_handler) (struct s3c_rtc *info, int mask);
void (*set_freq) (struct s3c_rtc *info, int freq);
@@ -73,10 +75,14 @@ static void s3c_rtc_alarm_clk_enable(struct s3c_rtc *info, 
bool enable)
if (enable) {
if (!info-enabled) {
clk_enable(info-rtc_clk);
+   if (info-data-needs_src_clk)
+   clk_enable(info-rtc_src_clk);
info-enabled = true;
}
} else {
if (info-enabled) {
+   if (info-data-needs_src_clk)
+   clk_disable(info-rtc_src_clk);
clk_disable(info-rtc_clk);
info-enabled = false;
}
@@ -117,12 +123,16 @@ static int s3c_rtc_setaie(struct device *dev, unsigned 
int enabled)
dev_dbg(info-dev, %s: aie=%d\n, __func__, enabled);
 
clk_enable(info-rtc_clk);
+   if (info-data-needs_src_clk)
+   clk_enable(info-rtc_src_clk);
tmp = readb(info-base + S3C2410_RTCALM)  ~S3C2410_RTCALM_ALMEN;
 
if (enabled)
tmp |= S3C2410_RTCALM_ALMEN;
 
writeb(tmp, info-base + S3C2410_RTCALM);
+   if (info-data-needs_src_clk)
+   clk_disable(info-rtc_src_clk);
clk_disable(info-rtc_clk);
 
s3c_rtc_alarm_clk_enable(info, enabled);
@@ -137,12 +147,16 @@ static int s3c_rtc_setfreq(struct s3c_rtc *info, int freq)
return -EINVAL;
 
clk_enable(info-rtc_clk);
+   if (info-data-needs_src_clk)
+   clk_enable(info-rtc_src_clk);
spin_lock_irq(info-pie_lock);
 
if (info-data-set_freq)
info-data-set_freq(info, freq);
 
spin_unlock_irq(info-pie_lock);
+   if (info-data-needs_src_clk)
+   clk_disable(info-rtc_src_clk);
clk_disable(info-rtc_clk);
 
return 0;
@@ -158,6 +172,9 @@ static int s3c_rtc_gettime(struct device *dev, struct 
rtc_time *rtc_tm)
return -EINVAL;
 
clk_enable(info-rtc_clk);
+   if (info-data-needs_src_clk)
+   clk_enable(info-rtc_src_clk);
+
  retry_get_time:
rtc_tm-tm_min  = readb(info-base + S3C2410_RTCMIN);
rtc_tm-tm_hour = readb(info-base + S3C2410_RTCHOUR);
@@ -191,6 +208,8 @@ static int s3c_rtc_gettime(struct device *dev, struct 
rtc_time *rtc_tm)
 
rtc_tm-tm_mon -= 1;
 
+   if (info-data-needs_src_clk)
+   clk_disable(info-rtc_src_clk);
clk_disable(info-rtc_clk);
 
return rtc_valid_tm(rtc_tm);
@@ -216,6 +235,8 @@ static int s3c_rtc_settime(struct device *dev, struct 
rtc_time *tm)
}
 
clk_enable(info-rtc_clk);
+   if (info-data-needs_src_clk)
+   clk_enable(info-rtc_src_clk);
 
writeb(bin2bcd(tm-tm_sec),  info-base + S3C2410_RTCSEC);

[PATCHv2 5/5] ARM: dts: Fix wrong compatible string of Exynos3250 RTC dt node

[y]

From: Chanwoo Choi cw00.c...@samsung.com

This patch fix wrong compatible string of Exynos3250 RTC (Real-Time Clock) dt
node. The RTC of Exynos3250 must need additional source clock (XrtcXTI).

Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/boot/dts/exynos3250.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
b/arch/arm/boot/dts/exynos3250.dtsi
index cd6a69a..1be5ef8 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -192,7 +192,7 @@
};
 
rtc: rtc@1007 {
-   compatible = samsung,s3c6410-rtc;
+   compatible = samsung,exynos3250-rtc;
reg = 0x1007 0x100;
interrupts = 0 73 0, 0 74 0;
status = disabled;
-- 
1.8.0

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

[PATCHv2 1/5] rtc: s3c: Define s3c_rtc structure to remove global variables.

[y]

From: Chanwoo Choi cw00.c...@samsung.com

This patch define s3c_rtc structure including necessary variables for S3C RTC
device instead of global variables. This patch improves the readability by
removing global variables.

Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/rtc/rtc-s3c.c | 448 ++
 1 file changed, 235 insertions(+), 213 deletions(-)

diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 4958a36..1d9e158 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -43,125 +43,135 @@ struct s3c_rtc_drv_data {
int cpu_type;
 };
 
-/* I have yet to find an S3C implementation with more than one
- * of these rtc blocks in */
+struct s3c_rtc {
+   struct device *dev;
+   struct rtc_device *rtc;
+
+   void __iomem *base;
+   struct clk *rtc_clk;
+   bool enabled;
 
-static struct clk *rtc_clk;
-static void __iomem *s3c_rtc_base;
-static int s3c_rtc_alarmno;
-static int s3c_rtc_tickno;
-static enum s3c_cpu_type s3c_rtc_cpu_type;
+   enum s3c_cpu_type cpu_type;
 
-static DEFINE_SPINLOCK(s3c_rtc_pie_lock);
+   int irq_alarm;
+   int irq_tick;
 
-static void s3c_rtc_alarm_clk_enable(bool enable)
+   spinlock_t pie_lock;
+   spinlock_t alarm_clk_lock;
+
+   int ticnt_save, ticnt_en_save;
+   bool wake_en;
+};
+
+static void s3c_rtc_alarm_clk_enable(struct s3c_rtc *info, bool enable)
 {
-   static DEFINE_SPINLOCK(s3c_rtc_alarm_clk_lock);
-   static bool alarm_clk_enabled;
unsigned long irq_flags;
 
-   spin_lock_irqsave(s3c_rtc_alarm_clk_lock, irq_flags);
+   spin_lock_irqsave(info-alarm_clk_lock, irq_flags);
if (enable) {
-   if (!alarm_clk_enabled) {
-   clk_enable(rtc_clk);
-   alarm_clk_enabled = true;
+   if (!info-enabled) {
+   clk_enable(info-rtc_clk);
+   info-enabled = true;
}
} else {
-   if (alarm_clk_enabled) {
-   clk_disable(rtc_clk);
-   alarm_clk_enabled = false;
+   if (info-enabled) {
+   clk_disable(info-rtc_clk);
+   info-enabled = false;
}
}
-   spin_unlock_irqrestore(s3c_rtc_alarm_clk_lock, irq_flags);
+   spin_unlock_irqrestore(info-alarm_clk_lock, irq_flags);
 }
 
 /* IRQ Handlers */
-
 static irqreturn_t s3c_rtc_alarmirq(int irq, void *id)
 {
-   struct rtc_device *rdev = id;
+   struct s3c_rtc *info = (struct s3c_rtc *)id;
 
-   clk_enable(rtc_clk);
-   rtc_update_irq(rdev, 1, RTC_AF | RTC_IRQF);
+   clk_enable(info-rtc_clk);
+   rtc_update_irq(info-rtc, 1, RTC_AF | RTC_IRQF);
 
-   if (s3c_rtc_cpu_type == TYPE_S3C64XX)
-   writeb(S3C2410_INTP_ALM, s3c_rtc_base + S3C2410_INTP);
+   if (info-cpu_type == TYPE_S3C64XX)
+   writeb(S3C2410_INTP_ALM, info-base + S3C2410_INTP);
 
-   clk_disable(rtc_clk);
+   clk_disable(info-rtc_clk);
 
-   s3c_rtc_alarm_clk_enable(false);
+   s3c_rtc_alarm_clk_enable(info, false);
 
return IRQ_HANDLED;
 }
 
 static irqreturn_t s3c_rtc_tickirq(int irq, void *id)
 {
-   struct rtc_device *rdev = id;
+   struct s3c_rtc *info = (struct s3c_rtc *)id;
+
+   clk_enable(info-rtc_clk);
+   rtc_update_irq(info-rtc, 1, RTC_PF | RTC_IRQF);
 
-   clk_enable(rtc_clk);
-   rtc_update_irq(rdev, 1, RTC_PF | RTC_IRQF);
+   if (info-cpu_type == TYPE_S3C64XX)
+   writeb(S3C2410_INTP_TIC, info-base + S3C2410_INTP);
 
-   if (s3c_rtc_cpu_type == TYPE_S3C64XX)
-   writeb(S3C2410_INTP_TIC, s3c_rtc_base + S3C2410_INTP);
+   clk_disable(info-rtc_clk);
 
-   clk_disable(rtc_clk);
return IRQ_HANDLED;
 }
 
 /* Update control registers */
 static int s3c_rtc_setaie(struct device *dev, unsigned int enabled)
 {
+   struct s3c_rtc *info = dev_get_drvdata(dev);
unsigned int tmp;
 
-   dev_dbg(dev, %s: aie=%d\n, __func__, enabled);
+   if (!info-base)
+   return -EINVAL;
+
+   dev_dbg(info-dev, %s: aie=%d\n, __func__, enabled);
 
-   clk_enable(rtc_clk);
-   tmp = readb(s3c_rtc_base + S3C2410_RTCALM)  ~S3C2410_RTCALM_ALMEN;
+   clk_enable(info-rtc_clk);
+   tmp = readb(info-base + S3C2410_RTCALM)  ~S3C2410_RTCALM_ALMEN;
 
if (enabled)
tmp |= S3C2410_RTCALM_ALMEN;
 
-   writeb(tmp, s3c_rtc_base + S3C2410_RTCALM);
-   clk_disable(rtc_clk);
+   writeb(tmp, info-base + S3C2410_RTCALM);
+   clk_disable(info-rtc_clk);
 
-   s3c_rtc_alarm_clk_enable(enabled);
+   s3c_rtc_alarm_clk_enable(info, enabled);
 
return 0;
 }
 
-static int s3c_rtc_setfreq(struct device *dev, int freq)
+static int s3c_rtc_setfreq(struct s3c_rtc *info, int freq)
 {
-   struct 

[PATCHv2 2/5] rtc: s3c: Remove warning message when checking coding style with checkpatch script

[y]

From: Chanwoo Choi cw00.c...@samsung.com

This patch remove warning message when checking codeing style with checkpatch
script and reduce un-necessary i2c read operation on s3c_rtc_enable.

WARNING: line over 80 characters
#406: FILE: drivers/rtc/rtc-s3c.c:406:
+   if ((readw(info-base + S3C2410_RTCCON)  
S3C2410_RTCCON_RTCEN) == 0) {

WARNING: line over 80 characters
#414: FILE: drivers/rtc/rtc-s3c.c:414:
+   if ((readw(info-base + S3C2410_RTCCON)  
S3C2410_RTCCON_CNTSEL)) {

WARNING: line over 80 characters
#422: FILE: drivers/rtc/rtc-s3c.c:422:
+   if ((readw(info-base + S3C2410_RTCCON)  
S3C2410_RTCCON_CLKRST)) {

WARNING: Missing a blank line after declarations
#451: FILE: drivers/rtc/rtc-s3c.c:451:
+   struct s3c_rtc_drv_data *data;
+   if (pdev-dev.of_node) {

WARNING: Missing a blank line after declarations
#453: FILE: drivers/rtc/rtc-s3c.c:453:
+   const struct of_device_id *match;
+   match = of_match_node(s3c_rtc_dt_match, 
pdev-dev.of_node);

WARNING: DT compatible string samsung,s3c2416-rtc appears 
un-documented -- check ./Documentation/devicetree/bindings/
#650: FILE: drivers/rtc/rtc-s3c.c:650:
+   .compatible = samsung,s3c2416-rtc,

WARNING: DT compatible string samsung,s3c2443-rtc appears 
un-documented -- check ./Documentation/devicetree/bindings/
#653: FILE: drivers/rtc/rtc-s3c.c:653:
+   .compatible = samsung,s3c2443-rtc,

Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
 Documentation/devicetree/bindings/rtc/s3c-rtc.txt |  2 ++
 drivers/rtc/rtc-s3c.c | 26 ---
 2 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt 
b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
index 7ac7259..06db446 100644
--- a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
+++ b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
@@ -3,6 +3,8 @@
 Required properties:
 - compatible: should be one of the following.
 * samsung,s3c2410-rtc - for controllers compatible with s3c2410 rtc.
+* samsung,s3c2416-rtc - for controllers compatible with s3c2416 rtc.
+* samsung,s3c2443-rtc - for controllers compatible with s3c2443 rtc.
 * samsung,s3c6410-rtc - for controllers compatible with s3c6410 rtc.
 - reg: physical base address of the controller and length of memory mapped
   region.
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 1d9e158..d8f25bd 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -400,28 +400,28 @@ static const struct rtc_class_ops s3c_rtcops = {
 
 static void s3c_rtc_enable(struct s3c_rtc *info, int en)
 {
-   unsigned int tmp;
+   unsigned int con, tmp;
 
if (!info-base)
return;
 
clk_enable(info-rtc_clk);
+
+   con = readw(info-base + S3C2410_RTCCON);
if (!en) {
-   tmp = readw(info-base + S3C2410_RTCCON);
if (info-cpu_type == TYPE_S3C64XX)
-   tmp = ~S3C64XX_RTCCON_TICEN;
-   tmp = ~S3C2410_RTCCON_RTCEN;
-   writew(tmp, info-base + S3C2410_RTCCON);
+   con = ~S3C64XX_RTCCON_TICEN;
+   con = ~S3C2410_RTCCON_RTCEN;
+   writew(con, info-base + S3C2410_RTCCON);
 
if (info-cpu_type != TYPE_S3C64XX) {
-   tmp = readb(info-base + S3C2410_TICNT);
-   tmp = ~S3C2410_TICNT_ENABLE;
-   writeb(tmp, info-base + S3C2410_TICNT);
+   con = readb(info-base + S3C2410_TICNT);
+   con = ~S3C2410_TICNT_ENABLE;
+   writeb(con, info-base + S3C2410_TICNT);
}
} else {
/* re-enable the device, and check it is ok */
-
-   if ((readw(info-base + S3C2410_RTCCON)  S3C2410_RTCCON_RTCEN) 
== 0) {
+   if ((con  S3C2410_RTCCON_RTCEN) == 0) {
dev_info(info-dev, rtc disabled, re-enabling\n);
 
tmp = readw(info-base + S3C2410_RTCCON);
@@ -429,7 +429,7 @@ static void s3c_rtc_enable(struct s3c_rtc *info, int en)
info-base + S3C2410_RTCCON);
}
 
-   if ((readw(info-base + S3C2410_RTCCON)  
S3C2410_RTCCON_CNTSEL)) {
+   if (con  S3C2410_RTCCON_CNTSEL) {
dev_info(info-dev, removing RTCCON_CNTSEL\n);
 
tmp = readw(info-base + S3C2410_RTCCON);
@@ -437,7 +437,7 @@ static void s3c_rtc_enable(struct s3c_rtc *info, int en)
info-base + S3C2410_RTCCON);
}
 
-   if ((readw(info-base + 

Re: [PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Inki Dae]

On 2014년 08월 11일 18:11, Thierry Reding wrote:
 On Mon, Aug 11, 2014 at 05:15:35PM +0900, Inki Dae wrote:
 On 2014년 08월 11일 16:50, Thierry Reding wrote:
 On Mon, Aug 11, 2014 at 04:35:46PM +0900, Inki Dae wrote:
 On 2014년 08월 11일 16:24, Thierry Reding wrote:
 On Mon, Aug 11, 2014 at 02:19:21PM +0900, Inki Dae wrote:
 On 2014년 08월 08일 18:55, Thierry Reding wrote:
 [...]
 The above is actually more like this:

 if ((flags  MIPI_DSI_MODE_NON_CONTINUOUS) == 0)
 clear DSI_HS_CLK_CTRL;
 else
 set DSI_HS_CLK_CTRL;

 if (msg-flags  MIPI_DSI_MSG_USE_LPM)
 clear DSI_HIGH_SPEED_TRANS;
 else
 set DSI_HIGH_SPEED_TRANS;

 So for peripherals that don't support non-continuous clock mode, this
 will result in the following for low-power transmissions:

 clear DSI_HS_CLK_CTRL; /* HS clock always on */
 clear DSI_HIGH_SPEED_TRANS;

 Right, then how host driver should check it if peripheral doesn't
 support non-continuous clock mode? Or how the peripheral should notify
 it to host driver? It would need a new flag instead of
 MIPI_DSI_MODE_NON_CONTINUOUS.

 MIPI_DSI_MODE_NON_CONTINUOUS is exactly the flag that devices need to
 set to signal that they support non-continuous mode. If devices don't
 have that set, then the controller should always provide the HS clock.

 So, if MIPI_DSI_MODE_NON_CONTINUOUS is *not* set, then the peripheral
 does *not* support non-continuous mode.


 Again, assume that there is a peripheral that doesn't support
 non-continuous clock mode but host driver want to transmit data in low
 power. For this, you already mentioned like below,

 So for peripherals that don't support non-continuous clock mode, this
 will result in the following for low-power transmissions:

clear DSI_HS_CLK_CTRL; /* HS clock always on */
clear DSI_HIGH_SPEED_TRANS;
 

 In this case, how should host driver check it to clear above two flags?
 As you know, this is required to clear two flags same as non-continuous
 clock mode. Don't you think that we need a new flag to identify them -
 non-continuous clock mode or just for low-power transmission?

 See what I wrote a little further up:

 if ((flags  MIPI_DSI_MODE_NON_CONTINUOUS) == 0)
 clear DSI_HS_CLK_CTRL;
 else
 set DSI_HS_CLK_CTRL;

 if (msg-flags  MIPI_DSI_MSG_USE_LPM)
 clear DSI_HIGH_SPEED_TRANS;
 else
 set DSI_HIGH_SPEED_TRANS;


 MIPI_DSI_MODE_NON_CONTINUOUS specifies that a peripheral supports non-
 continuous mode. When set, we clear DSI_HS_CLK_CTRL on Tegra because
 that tells the controller to turn off the HS clock between high-speed
 transmissions.

 MIPI_DSI_MSG_USE_LPM specifies that a message is to be sent in low-power
 mode.

 With the above two flags we can cover four cases:

   1) non-continuous mode with messages transmitted in low-power mode
   2) non-continuous mode with messages transmitted in high-speed mode
   3) continuous mode with messages transmitted in low-power mode

 In case of 3), it would mean set DSI_HS_CLK_CTRL and clear
 DSI_HIGH_SPEED_TRANS. However, msg-flags has MIPI_DSI_MSG_USE_LPM but
 dsi-mode_flags has no MIPI_DSI_MODE_NON_CONTINOUS flag. Ah, right.
 You mean that continuous mode is set by default implicitly?
 
 Yes, if the MIPI_DSI_MODE_NON_CONTINUOUS flag is not specified, then it
 means the peripheral supports only continuous mode.
 

On more thing, in case of non-continuous clock mode, host controller can
transmit data in low power or high speed.  With
MIPI_DSI_MODE_NON_CONTINUOUS flag, host controller can clear
DSI_HS_CLK_CTRL or set it by default. However, we have no any flag to
select low power or high speed transmission.

Of course, as your patch of other thread, we can set
MIPI_DSI_MSG_USE_LPM by default but I'm not sure that the change incurs
what problem to all other panel devices. So I think it's better to add a
new flag which decides host controller should transmit data in high
speed or low power. i.e., MIPI_DSI_MODE_LPM

at mipi dsi framework,
 if ((flags  MIPI_DSI_MODE_LPM) == 0)
msg-flags |= MIPI_DSI_MSG_USE_LPM;

at each host driver,
if ((flags  MIPI_DSI_MODE_NON_CONTINUOUS) == 0)
   clear high speed clock of each SoC
   else
  set high speed clock of each SoC - by default

   if ((msg-flags = MIPI_DSI_MSG_USE_LPM) == 0)
   clear high speed transmission of each SoC
  else
   set high speed transmission of each SoC - by default

Thanks,
Inki Dae

 Thierry
 

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