Re: media: platform: s5p-jpeg: jpeg-hw-exynos4: Remove some unused functions

2015-01-04 Thread Pankaj Dubey

+Tony Nadackal

Hi Rickard,

On Saturday 03 January 2015 02:07 AM, Rickard Strandqvist wrote:

Removes some functions that are not used anywhere:
exynos4_jpeg_set_timer_count() exynos4_jpeg_get_frame_size() 
exynos4_jpeg_set_sys_int_enable() exynos4_jpeg_get_fifo_status()

This was partially found by using a static code analysis program called 
cppcheck.

Signed-off-by: Rickard Strandqvist 

---
drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c |   35 -
  drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.h |5 ---
  2 files changed, 40 deletions(-)

diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c 
b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
index ab6d6f4..5685577 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
@@ -163,15 +163,6 @@ unsigned int exynos4_jpeg_get_int_status(void __iomem 
*base)
return int_status;
  }

-unsigned int exynos4_jpeg_get_fifo_status(void __iomem *base)
-{
-   unsigned int fifo_status;
-
-   fifo_status = readl(base + EXYNOS4_FIFO_STATUS_REG);
-
-   return fifo_status;
-}
-
  void exynos4_jpeg_set_huf_table_enable(void __iomem *base, int value)
  {
unsigned intreg;
@@ -186,18 +177,6 @@ void exynos4_jpeg_set_huf_table_enable(void __iomem *base, 
int value)
base + EXYNOS4_JPEG_CNTL_REG);
  }

-void exynos4_jpeg_set_sys_int_enable(void __iomem *base, int value)
-{
-   unsigned intreg;
-
-   reg = readl(base + EXYNOS4_JPEG_CNTL_REG) & ~(EXYNOS4_SYS_INT_EN);
-
-   if (value == 1)
-   writel(reg | EXYNOS4_SYS_INT_EN, base + EXYNOS4_JPEG_CNTL_REG);
-   else
-   writel(reg & ~EXYNOS4_SYS_INT_EN, base + EXYNOS4_JPEG_CNTL_REG);
-}
-


Above function will be needed for enabling JPEG support on Exynos7 SoC. 
There is already inflight patch [1] which will be using it.


1: https://patchwork.kernel.org/patch/5505391/


Thanks,
Pankaj Dubey
--
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 0/2] Adding support for Exynos7 Jpeg variant

2015-01-04 Thread Tony K Nadackal
Gentle Reminder.

Thanks,
Tony

> -Original Message-
> From: Tony K Nadackal [mailto:tony...@samsung.com]
> Sent: Friday, December 19, 2014 1:08 PM
> To: linux-me...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> samsung-...@vger.kernel.org; devicet...@vger.kernel.org
> Cc: mche...@osg.samsung.com; j.anaszew...@samsung.com;
> kg...@kernel.org; k.deb...@samsung.com; s.nawro...@samsung.com;
> robh...@kernel.org; mark.rutl...@arm.com; bhusha...@samsung.com; Tony K
> Nadackal
> Subject: [PATCH v2 0/2] Adding support for Exynos7 Jpeg variant
> 
> This patch series adds support for Exynos7 JPEG variant, which is mostly same
as
> Exynos4 JPEG variants with few register configuration differences.
> At the same time it modifies #define based JPEG variant macros into enum.
> Patch 1/2 fixes possible bug in setting INT EN register, where
> EXYNOS4_INT_EN_REG was getting modified without reading before.
> 
> Patch set v1 and related discussion can be found here [1].
> 
> [1]: http://www.spinics.net/lists/linux-samsung-soc/msg40308.html
> 
> Changes since v1:
>  - Added new patch 1/2 which fixes issues in writing EXYNOS4_INT_EN_REG.
>  - Converted JPEG variant macros into enum as suggested by Jacek Anaszewski.
> 
> 
> Tony K Nadackal (2):
>   [media] s5p-jpeg: Fix modification sequence of interrupt enable
> register
>   [media] s5p-jpeg: Adding Exynos7 Jpeg variant
> 
>  .../bindings/media/exynos-jpeg-codec.txt   |  2 +-
>  drivers/media/platform/s5p-jpeg/jpeg-core.c| 61 ++---
> -
>  drivers/media/platform/s5p-jpeg/jpeg-core.h| 10 ++--
>  drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c  | 33 +++-
> drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.h  |  8 +--
>  drivers/media/platform/s5p-jpeg/jpeg-regs.h| 17 --
>  6 files changed, 95 insertions(+), 36 deletions(-)
> 
> --
> 2.2.0

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


RE: [PATCH] [media] s5p-jpeg: Initialize cb and cr to zero.

2015-01-04 Thread Tony K Nadackal
Gentle Reminder.

Thanks,
Tony

> -Original Message-
> From: Tony K Nadackal [mailto:tony...@samsung.com]
> Sent: Wednesday, December 17, 2014 12:51 PM
> To: linux-me...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> samsung-...@vger.kernel.org
> Cc: mche...@osg.samsung.com; j.anaszew...@samsung.com;
> kg...@kernel.org; k.deb...@samsung.com; s.nawro...@samsung.com;
> bhusha...@samsung.com; Tony K Nadackal
> Subject: [PATCH] [media] s5p-jpeg: Initialize cb and cr to zero.
> 
> To avoid garbage value written into image base address planes, initialize cb
and cr
> of structure s5p_jpeg_addr to zero.
> 
> Signed-off-by: Tony K Nadackal 
> ---
> This patch is created and tested on top of linux-next-20141210.
> It can be cleanly applied on media-next and kgene/for-next.
> 
>  drivers/media/platform/s5p-jpeg/jpeg-core.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
> b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> index 91bd3e6..54fa5d9 100644
> --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
> +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> @@ -1845,6 +1845,9 @@ static void exynos4_jpeg_set_img_addr(struct
> s5p_jpeg_ctx *ctx)
>   struct s5p_jpeg_addr jpeg_addr;
>   u32 pix_size, padding_bytes = 0;
> 
> + jpeg_addr.cb = 0;
> + jpeg_addr.cr = 0;
> +
>   pix_size = ctx->cap_q.w * ctx->cap_q.h;
> 
>   if (ctx->mode == S5P_JPEG_ENCODE) {
> --
> 2.2.0

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


RE: [PATCH] [media] s5p-jpeg: Fix crash in jpeg isr due to multiple interrupts.

2015-01-04 Thread Tony K Nadackal
Gentle Reminder.

Thanks
Tony

> -Original Message-
> From: Tony K Nadackal [mailto:tony...@samsung.com]
> Sent: Wednesday, December 17, 2014 11:55 AM
> To: linux-me...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> samsung-...@vger.kernel.org
> Cc: mche...@osg.samsung.com; j.anaszew...@samsung.com;
> kg...@kernel.org; k.deb...@samsung.com; s.nawro...@samsung.com;
> bhusha...@samsung.com; Tony K Nadackal
> Subject: [PATCH] [media] s5p-jpeg: Fix crash in jpeg isr due to multiple
interrupts.
> 
> In case of corrupt images, multiple interrupts may occur due to different
error
> scenarios.
> 
> Since we are removing the src and dest buffers in the first interrupt itself,
crash
> occurs in the second error interrupts.
> 
> Disable the global interrupt before we start processing the interrupt avoid
the
> crash.
> 
> Disable System interrupt in isr to avoid the crash below.
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00c8
> pgd = ffc0007db000 [00c8] *pgd=fb006003,
> *pud=fb006003, *pmd=fb007003, *pte=006011001707
> Internal error: Oops: 9607 [#1] PREEMPT SMP Modules linked in:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.18.0-next-20141210+ #22 Hardware
> name: Samsung Exynos7 Espresso board based on EXYNOS7 (DT)
> task: ffc00075e5c0 ti: ffc00074c000 task.ti: ffc00074c000 PC is at
> exynos4_jpeg_irq+0x30/0x15c LR is at exynos4_jpeg_irq+0x2c/0x15c pc :
> [] lr : [] pstate: 81c5 sp :
> ffc00074fc60
> x29: ffc00074fc60 x28: 00404000
> x27: ffc000673928 x26: ffc000673940
> x25: ffc0007a030c x24: ffc0bb20a400
> x23: 0030 x22: ffc0ba56ba40
> x21:  x20: 
> x19: ffc0ba56ba18 x18: 
> x17:  x16: ffc00018b508
> x15:  x14: 
> x13: 00989680 x12: 00989680
> x11: 0004 x10: 0101010101010101
> x9 : 0020a285a9ea x8 : ffc0007af880
> x7 : ffc0bac001a8 x6 : ffc0bac0
> x5 : fffa x4 : ffc00040870c
> x3 : 0003 x2 : 00010003
> x1 : 00010002 x0 : 
> 
> Process swapper/0 (pid: 0, stack limit = 0xffc00074c058)
> Stack: (0xffc00074fc60 to 0xffc00075)
> fc60: 0074fca0 ffc0 000e4508 ffc0 bb225300 ffc0 bb20a494 ffc0
> fc80:     0030  000f8c6c ffc0
> fca0: 0074fd00 ffc0 000e4644 ffc0 bb20a400 ffc0 bb20a494 ffc0
> fcc0: 00776a00 ffc0 00670da8 ffc0   0001 
> fce0: bb008000 ffc0 407db000  00081230 ffc0 000e4638 ffc0
> fd00: 0074fd40 ffc0 000e7338 ffc0 bb20a400 ffc0 bb20a494 ffc0
> fd20: 00776a00 ffc0 000e7280 ffc0 bb225300 ffc0 000e72e0 ffc0
> fd40: 0074fd70 ffc0 000e3d60 ffc0 0030  00743000 ffc0
> fd60: 0066e000 ffc0 006c2000 ffc0 0074fd90 ffc0 000e3e90 ffc0
> fd80: 007437c8 ffc0 000e3e6c ffc0 0074fdf0 ffc0 00082404 ffc0
> fda0: 0074fe20 ffc0 0075a000 ffc0 200c ff80 2010 ff80
> fdc0: 6145  00672cc8 ffc0 407d9000  befb9b40 ffc0
> fde0: 0074fe20 ffc0 01d2  0074ff40 ffc0 00085da8 ffc0
> fe00: 00758584 ffc0 0052c000 ffc0 0074ff40 ffc0 00087114 ffc0
> fe20:   0074ff50 ffc0 0067d760 ffc0 befb9adc ffc0
> fe40: 0001  d4414200 0020 d6a39c00 0020 007a6a18 ffc0
> fe60: 0075eb00 ffc0 0074fd60 ffc0 c185  0020 
> fe80: 0052d340 ffc0 0030  fffe 0fff  
> fea0: 0018b508 ffc0     00758584 ffc0
> fec0: 0052c000 ffc0 006c24e8 ffc0 007a030a ffc0 0001 
> fee0: 00672cc8 ffc0 407d9000  407db000  00081230 ffc0
> ff00: 4000 0040 0074ff40 ffc0 00087110 ffc0 0074ff40 ffc0
> ff20: 00087114 ffc0 6145  00758584 ffc0 0052c000 ffc0
> ff40: 0074ff50 ffc0 000db568 ffc0 0074ff90 ffc0 00515fdc ffc0
> ff60: 00758000 ffc0 007a3000 ffc0 007a3000 ffc0 befc8940 ffc0
> ff80: 4076  4000  0074ffb0 ffc0 006ff998 ffc0
> ffa0: 0002  006ff988 ffc0   400826c0 
> ffc0: 8f03a688  0e11  4800  410fd030
> 
> ffe0: 0072c250 ffc0      
> Call trace:
> [] exynos4_jpeg_irq+0x30/0x15c []
> handle_irq_event_percpu+0x6c/0x160
> [] handle_irq_event+0x48/0x78 []
> handle_fasteoi_irq+0xe0/0x198 []
> generic_handle_irq+0x24/0x40 []
> __handle_domain_irq+0x80/0xf0 [] gic_handle_irq+0x30/0x80
> Exception stack(0xffc00074fe00 to 0xffc00074ff20)
> fe00: 00758584 ffc0 

RE: [PATCH] [media] s5p-jpeg: Clear JPEG_CODEC_ON bits in sw reset function

2015-01-04 Thread Tony K Nadackal
Gentle Reminder.

Thanks
Tony

> -Original Message-
> From: Tony K Nadackal [mailto:tony...@samsung.com]
> Sent: Wednesday, December 17, 2014 11:52 AM
> To: linux-me...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> samsung-...@vger.kernel.org
> Cc: mche...@osg.samsung.com; j.anaszew...@samsung.com;
> kg...@kernel.org; k.deb...@samsung.com; s.nawro...@samsung.com;
> bhusha...@samsung.com; Tony K Nadackal
> Subject: [PATCH] [media] s5p-jpeg: Clear JPEG_CODEC_ON bits in sw reset
> function
> 
> Bits EXYNOS4_DEC_MODE and EXYNOS4_ENC_MODE do not get cleared on
> software reset. These bits need to be cleared explicitly.
> 
> Signed-off-by: Tony K Nadackal 
> ---
> This patch is created and tested on top of linux-next-20141210.
> It can be cleanly applied on media-next and kgene/for-next.
> 
> 
>  drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
> b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
> index ab6d6f43..e53f13a 100644
> --- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
> +++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
> @@ -21,6 +21,10 @@ void exynos4_jpeg_sw_reset(void __iomem *base)
>   unsigned int reg;
> 
>   reg = readl(base + EXYNOS4_JPEG_CNTL_REG);
> + writel(reg & ~(EXYNOS4_DEC_MODE | EXYNOS4_ENC_MODE),
> + base + EXYNOS4_JPEG_CNTL_REG);
> +
> + reg = readl(base + EXYNOS4_JPEG_CNTL_REG);
>   writel(reg & ~EXYNOS4_SOFT_RESET_HI, base +
> EXYNOS4_JPEG_CNTL_REG);
> 
>   udelay(100);
> --
> 2.2.0

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


Re: [PATCH] ARM: EXYNOS: Add exynos3250 suspend-to-ram support

2015-01-04 Thread Chanwoo Choi
Dear Kukjin,

Could you please review this patch-set?

I tested this patch-set on Exynos3250-baesd Rinato board.

Best Regards,
Chanwoo Choi

On 12/24/2014 11:37 AM, Chanwoo Choi wrote:
> This patch adds the support for suspend-to-ram feature of Exynos3250 SoC.
> Exynos3250 don't contain the L2 cache.
> 
> The measured power-consumption in suspend state:
> - before entering suspend : 31mA
> - in suspend state : 16mA
> 
> Cc: Kukjin Kim 
> Signed-off-by: Chanwoo Choi 
> Acked-by: Kyungmin Park 
> ---
> This patch is based on v3.19-rc1 and is tested on Exynos3250-based Rinato 
> board.
> 
>  arch/arm/mach-exynos/regs-pmu.h |  3 ++
>  arch/arm/mach-exynos/suspend.c  | 77 
> +
>  2 files changed, 80 insertions(+)
> 
> diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h
> index b5f4406..eb461e1 100644
> --- a/arch/arm/mach-exynos/regs-pmu.h
> +++ b/arch/arm/mach-exynos/regs-pmu.h
> @@ -160,12 +160,14 @@
>  #define EXYNOS5_L2RSTDISABLE_VALUE   BIT(3)
>  
>  #define S5P_PAD_RET_MAUDIO_OPTION0x3028
> +#define S5P_PAD_RET_MMC2_OPTION  0x30c8
>  #define S5P_PAD_RET_GPIO_OPTION  0x3108
>  #define S5P_PAD_RET_UART_OPTION  0x3128
>  #define S5P_PAD_RET_MMCA_OPTION  0x3148
>  #define S5P_PAD_RET_MMCB_OPTION  0x3168
>  #define S5P_PAD_RET_EBIA_OPTION  0x3188
>  #define S5P_PAD_RET_EBIB_OPTION  0x31A8
> +#define S5P_PAD_RET_SPI_OPTION   0x31c8
>  
>  #define S5P_PS_HOLD_CONTROL  0x330C
>  #define S5P_PS_HOLD_EN   (1 << 31)
> @@ -326,6 +328,7 @@
>   (EXYNOS3_ARM_CORE0_OPTION + ((_nr) * 0x80))
>  
>  #define EXYNOS3_ARM_COMMON_OPTION0x2408
> +#define EXYNOS3_ARM_L2_OPTION0x2608
>  #define EXYNOS3_TOP_PWR_OPTION   0x2C48
>  #define EXYNOS3_CORE_TOP_PWR_OPTION  0x2CA8
>  #define EXYNOS3_XUSBXTI_DURATION 0x341C
> diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
> index f8e7dcd..d6feef3 100644
> --- a/arch/arm/mach-exynos/suspend.c
> +++ b/arch/arm/mach-exynos/suspend.c
> @@ -91,6 +91,12 @@ static unsigned int exynos_pmu_spare3;
>  
>  static u32 exynos_irqwake_intmask = 0x;
>  
> +static const struct exynos_wkup_irq exynos3250_wkup_irq[] = {
> + { 73, BIT(1) }, /* RTC alarm */
> + { 74, BIT(2) }, /* RTC tick */
> + { /* sentinel */ },
> +};
> +
>  static const struct exynos_wkup_irq exynos4_wkup_irq[] = {
>   { 76, BIT(1) }, /* RTC alarm */
>   { 77, BIT(2) }, /* RTC tick */
> @@ -114,6 +120,19 @@ unsigned int exynos_release_ret_regs[] = {
>   REG_TABLE_END,
>  };
>  
> +unsigned int exynos3250_release_ret_regs[] = {
> + S5P_PAD_RET_MAUDIO_OPTION,
> + S5P_PAD_RET_GPIO_OPTION,
> + S5P_PAD_RET_UART_OPTION,
> + S5P_PAD_RET_MMCA_OPTION,
> + S5P_PAD_RET_MMCB_OPTION,
> + S5P_PAD_RET_EBIA_OPTION,
> + S5P_PAD_RET_EBIB_OPTION,
> + S5P_PAD_RET_MMC2_OPTION,
> + S5P_PAD_RET_SPI_OPTION,
> + REG_TABLE_END,
> +};
> +
>  unsigned int exynos5420_release_ret_regs[] = {
>   EXYNOS_PAD_RET_DRAM_OPTION,
>   EXYNOS_PAD_RET_MAUDIO_OPTION,
> @@ -173,6 +192,12 @@ static int exynos_cpu_suspend(unsigned long arg)
>   return exynos_cpu_do_idle();
>  }
>  
> +static int exynos3250_cpu_suspend(unsigned long arg)
> +{
> + flush_cache_all();
> + return exynos_cpu_do_idle();
> +}
> +
>  static int exynos5420_cpu_suspend(unsigned long arg)
>  {
>   /* MCPM works with HW CPU identifiers */
> @@ -230,6 +255,23 @@ static void exynos_pm_prepare(void)
>   pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
>  }
>  
> +static void exynos3250_pm_prepare(void)
> +{
> + unsigned int tmp;
> +
> + /* Set wake-up mask registers */
> + exynos_pm_set_wakeup_mask();
> +
> + tmp = pmu_raw_readl(EXYNOS3_ARM_L2_OPTION);
> + tmp &= ~EXYNOS5_OPTION_USE_RETENTION;
> + pmu_raw_writel(tmp, EXYNOS3_ARM_L2_OPTION);
> +
> + exynos_pm_enter_sleep_mode();
> +
> + /* ensure at least INFORM0 has the resume address */
> + pmu_raw_writel(virt_to_phys(exynos_cpu_resume), S5P_INFORM0);
> +}
> +
>  static void exynos5420_pm_prepare(void)
>  {
>   unsigned int tmp;
> @@ -344,6 +386,28 @@ early_wakeup:
>   pmu_raw_writel(0x0, S5P_INFORM1);
>  }
>  
> +static void exynos3250_pm_resume(void)
> +{
> + u32 cpuid = read_cpuid_part();
> +
> + if (exynos_pm_central_resume())
> + goto early_wakeup;
> +
> + /* For release retention */
> + exynos_pm_release_retention();
> +
> + pmu_raw_writel(S5P_USE_STANDBY_WFI_ALL, S5P_CENTRAL_SEQ_OPTION);
> +
> + if (call_firmware_op(resume) == -ENOSYS
> + && cpuid == ARM_CPU_PART_CORTEX_A9)
> + exynos_cpu_restore_reg

Re: [PATCH v3 1/4] mmc: dw_mmc: exynos: incorporate ciu_div into timing property

2015-01-04 Thread Alim Akhtar
Hi Doug,
Thanks for looking into this series.

On Fri, Jan 2, 2015 at 10:28 PM, Doug Anderson  wrote:
> Alim,
>
> On Tue, Dec 30, 2014 at 10:43 PM, Alim Akhtar  wrote:
>> From: Seungwon Jeon 
>>
>> ciu_div may not be common value for all speed mode.
>> So, it needs to be attached to CLKSEL timing.
>
> The more time I've spent looking at all of this stuff the less I like
> the exynos bindings.  Personally I'd prefer to see the exynos bindings
> fixed rather than go further down the path of these bindings.
>
> Specifically:
>
> 1. The "drive" really should be specified quite differently.
> According to the DesignWare docs, the "drive" phase is there to meet
> hold time requirements.  Hold time requirements are different for
> different SD/MMC modes and are specified in nanoseconds (SDR104 is
> .8ns, ID mode is 5.0ns).  There is a per-SoC parameter needed that
> indicates some built-in delay (in nanoseconds) and that shouldn't
> change based on clock speed or card mode.
>
Yes, "drive" phase shift are there to meet hold time requirements. And
that why we in general don't change it as those are fixed for a
SoC/Board based on actual measurement of the same.

> 2. The ciu_div really ought to be automatic.  Start out at a divide by
> 4.  If you end up with both drive and sample at phases of 0, 90, 180,
> 270 then you can change to divide by 2.
>
> I still haven't looked at every last detail of these delays though, so
> please correct me if I'm wrong.  I've added Alex who may have looked
> at this more than I have.
>
Thanks, suggestions/comments are welcome.
>
> With all of the above, there's also the fact that (I think) we should
> be moving towards working with the clock phase API since all of your
> values are effectively specifying clock phases, just in a very arcane
> way.
>
That is something nice to have, and should be done at some point.
As you know exynos implements a custom register called CLKSEL, and it
allows us to set the required "sample" phase shift. And exynos uses
"variable delay tuning" as per DW databook to set "sample" phase shift
based on tuning data.
>
>> This also introduce a new compatibale 'dw-mshc-hs200-timing'
>> for selecting hs200 timing value
>
> As per above, I don't think this is needed.
>
>
>> Signed-off-by: Seungwon Jeon 
>> Signed-off-by: Alim Akhtar 
>> ---
>>  .../devicetree/bindings/mmc/exynos-dw-mshc.txt |   15 ++--
>>  drivers/mmc/host/dw_mmc-exynos.c   |   81 
>> ++--
>>  drivers/mmc/host/dw_mmc-exynos.h   |1 +
>>  3 files changed, 67 insertions(+), 30 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt 
>> b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>> index ee4fc05..06455de 100644
>> --- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>> +++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>> @@ -23,10 +23,6 @@ Required Properties:
>> - "samsung,exynos7-dw-mshc-smu": for controllers with Samsung Exynos7
>>   specific extensions having an SMU.
>>
>> -* samsung,dw-mshc-ciu-div: Specifies the divider value for the card 
>> interface
>> -  unit (ciu) clock. This property is applicable only for Exynos5 SoC's and
>> -  ignored for Exynos4 SoC's. The valid range of divider value is 0 to 7.
>> -
>>  * samsung,dw-mshc-sdr-timing: Specifies the value of CIU clock phase shift 
>> value
>>in transmit mode and CIU clock phase shift value in receive mode for 
>> single
>>data rate mode operation. Refer notes below for the order of the cells 
>> and the
>> @@ -37,11 +33,16 @@ Required Properties:
>>data rate mode operation. Refer notes below for the order of the cells 
>> and the
>>valid values.
>>
>> +* samsung,dw-mshc-hs200-timing: Similar with dw-mshc-sdr-timing.
>> +
>>Notes for the sdr-timing and ddr-timing values:
>>
>>  The order of the cells should be
>>- First Cell: CIU clock phase shift value for tx mode.
>>- Second Cell: CIU clock phase shift value for rx mode.
>> +  - Thrid Cell: Specifies the divider value for the card interface
>> +unit (ciu) clock. This property is applicable only for Exynos5 
>> SoC's and
>> +ignored for Exynos4 SoC's. The valid range of divider value is 0 to 
>> 7.
>>
>>  Valid values for SDR and DDR CIU clock timing for Exynos5250:
>>- valid value for tx phase shift and rx phase shift is 0 to 7.
>> @@ -79,8 +80,8 @@ Example:
>> 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>;
>> +   samsung,dw-mshc-sdr-timing = <2 3 3>;
>> +   samsung,dw-mshc-ddr-timing = <1 2 3>;
>> +   samsung,dw-mshc-hs200-timing = <0 2 3>;
>
> You are breaking backward compatibility here.  If your change is
> merged