Re: [PATCH v3 3/6] ARM: EXYNOS: Remove soc_is_exynos4/5 from exynos.c

On Sat, May 10, 2014 at 12:18 AM, wrote: > From: Pankaj Dubey > > This patch removes usage of soc_is_exynos4/5 from exynos.c. > For this we need to separate machine descriptors for exynos4 > and exynos5. While doing this patch does some consolidation also. > > CC: Russell King > CC: Thomas Abra

Re: [PATCH 5/6] usb: host: ehci-tegra: Use devm_ioremap_resource instead of devm_ioremap

Hello. On 05/10/2014 01:57 PM, Vivek Gautam wrote: Using devm_ioremap_resource() API should actually be preferred over devm_ioremap(), since the former request the mem region first and then gives back the ioremap'ed memory pointer. devm_ioremap_resource() calls request_mem_region(), therby prev

Re: [PATCH v2 0/6] usb: host: Cleanup for ioremap'ing hcd memory

Sat, 10 May 2014 17:30:04 +0530 от Vivek Gautam : > Based on 'usb-next' branch of Greg's usb tree. > > devm_ioremap_resource() API is advantageous over devm_ioremap() > and should therefore be preferred to request any ioremap'ed address > for hcd. > > Changes from v1: > - Changed the way returne

RE: [PATCH] mmc: dw_mmc: Make sure we don't get stuck when we get an error

On Fri, May 09, 2014, Sonny Rao wrote: > On Thu, May 8, 2014 at 2:42 AM, Yuvaraj Kumar wrote: > > Any comments on this patch? > > > > I'll just add that without this fix, running the tuning loop for UHS > modes is not reliable on dw_mmc because errors will happen and you > will eventually hit thi

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

Hi Sonny, Can you separate procedure? Reset all are handled in fifo-reset. And ciu reset is always needed for error handling? Thanks, Seungwon Jeon On Sat, May 10, 2014, Sonny Rao wrote: > On Fri, May 9, 2014 at 12:32 AM, Jaehoon Chung wrote: > > Hi, Sonny. > > > > You can discard the my previo

[PATCH v2 0/6] usb: host: Cleanup for ioremap'ing hcd memory

Based on 'usb-next' branch of Greg's usb tree. devm_ioremap_resource() API is advantageous over devm_ioremap() and should therefore be preferred to request any ioremap'ed address for hcd. Changes from v1: - Changed the way returned pointer is checked for error value as pointed out in the revi

[PATCH v2 3/6] usb: host: ehci-mv: Use devm_ioremap_resource instead of devm_ioremap

Using devm_ioremap_resource() API should actually be preferred over devm_ioremap(), since the former request the mem region first and then gives back the ioremap'ed memory pointer. devm_ioremap_resource() calls request_mem_region(), therby preventing other drivers to make any overlapping call to th

[PATCH v2 4/6] usb: host: ehci-spear: Use devm_ioremap_resource instead of devm_ioremap

Using devm_ioremap_resource() API should actually be preferred over devm_ioremap(), since the former request the mem region first and then gives back the ioremap'ed memory pointer. devm_ioremap_resource() calls request_mem_region(), therby preventing other drivers to make any overlapping call to th

[PATCH v2 2/6] usb: host: ehci-msm: Use devm_ioremap_resource instead of devm_ioremap

Using devm_ioremap_resource() API should actually be preferred over devm_ioremap(), since the former request the mem region first and then gives back the ioremap'ed memory pointer. devm_ioremap_resource() calls request_mem_region(), therby preventing other drivers to make any overlapping call to th

[PATCH v2 1/6] usb: host: ehci-exynos: Use devm_ioremap_resource instead of devm_ioremap

Using devm_ioremap_resource() API should actually be preferred over devm_ioremap(), since the former request the mem region first and then gives back the ioremap'ed memory pointer. devm_ioremap_resource() calls request_mem_region(), therby preventing other drivers to make any overlapping call to th

[PATCH v2 6/6] usb: host: ohci-exynos: Use devm_ioremap_resource instead of devm_ioremap

Using devm_ioremap_resource() API should actually be preferred over devm_ioremap(), since the former request the mem region first and then gives back the ioremap'ed memory pointer. devm_ioremap_resource() calls request_mem_region(), therby preventing other drivers to make any overlapping call to th

[PATCH v2 5/6] usb: host: ehci-tegra: Use devm_ioremap_resource instead of devm_ioremap

Using devm_ioremap_resource() API should actually be preferred over devm_ioremap(), since the former request the mem region first and then gives back the ioremap'ed memory pointer. devm_ioremap_resource() calls request_mem_region(), therby preventing other drivers to make any overlapping call to th

Re: [PATCH 1/6] usb: host: ehci-exynos: Use devm_ioremap_resource instead of devm_ioremap

Hi, On Sat, May 10, 2014 at 3:36 PM, Alexander Shiyan wrote: > Sat, 10 May 2014 15:26:58 +0530 от Vivek Gautam : >> Using devm_ioremap_resource() API should actually be preferred over >> devm_ioremap(), since the former request the mem region first and then >> gives back the ioremap'ed memory po

Re: [PATCH 1/6] usb: host: ehci-exynos: Use devm_ioremap_resource instead of devm_ioremap

Sat, 10 May 2014 15:26:58 +0530 от Vivek Gautam : > Using devm_ioremap_resource() API should actually be preferred over > devm_ioremap(), since the former request the mem region first and then > gives back the ioremap'ed memory pointer. > devm_ioremap_resource() calls request_mem_region(), therby p

[PATCH 1/6] usb: host: ehci-exynos: Use devm_ioremap_resource instead of devm_ioremap

Using devm_ioremap_resource() API should actually be preferred over devm_ioremap(), since the former request the mem region first and then gives back the ioremap'ed memory pointer. devm_ioremap_resource() calls request_mem_region(), therby preventing other drivers to make any overlapping call to th

[PATCH 2/6] usb: host: ehci-msm: Use devm_ioremap_resource instead of devm_ioremap

Using devm_ioremap_resource() API should actually be preferred over devm_ioremap(), since the former request the mem region first and then gives back the ioremap'ed memory pointer. devm_ioremap_resource() calls request_mem_region(), therby preventing other drivers to make any overlapping call to th

[PATCH 5/6] usb: host: ehci-tegra: Use devm_ioremap_resource instead of devm_ioremap

Using devm_ioremap_resource() API should actually be preferred over devm_ioremap(), since the former request the mem region first and then gives back the ioremap'ed memory pointer. devm_ioremap_resource() calls request_mem_region(), therby preventing other drivers to make any overlapping call to th

[PATCH 4/6] usb: host: ehci-spear: Use devm_ioremap_resource instead of devm_ioremap

Using devm_ioremap_resource() API should actually be preferred over devm_ioremap(), since the former request the mem region first and then gives back the ioremap'ed memory pointer. devm_ioremap_resource() calls request_mem_region(), therby preventing other drivers to make any overlapping call to th

[PATCH 3/6] usb: host: ehci-mv: Use devm_ioremap_resource instead of devm_ioremap

Using devm_ioremap_resource() API should actually be preferred over devm_ioremap(), since the former request the mem region first and then gives back the ioremap'ed memory pointer. devm_ioremap_resource() calls request_mem_region(), therby preventing other drivers to make any overlapping call to th

[PATCH 0/6] usb: host: Cleanup for ioremap'ing hcd memory

Based on 'usb-next' branch of Greg's usb tree. devm_ioremap_resource() API is advantageous over devm_ioremap() and should therefore be preferred to request any ioremap'ed address for hcd. Vivek Gautam (6): usb: host: ehci-exynos: Use devm_ioremap_resource instead of devm_ioremap usb: host

[PATCH 6/6] usb: host: ohci-exynos: Use devm_ioremap_resource instead of devm_ioremap

Using devm_ioremap_resource() API should actually be preferred over devm_ioremap(), since the former request the mem region first and then gives back the ioremap'ed memory pointer. devm_ioremap_resource() calls request_mem_region(), therby preventing other drivers to make any overlapping call to th

[PATCH v3 1/6] i2c: s3c2410: Handle i2c sys_cfg register in i2c driver

Let's handle i2c interrupt re-configuration in i2c driver. This will help us in removing some soc specific checks from machine files. Since only Exynos5250, and Exynos5420 need to do this, added syscon based phandle to i2c device nodes of respective SoC DT files. Also handle saving and restoring of

[PATCH v3 5/6] soc: samsung: exynos-chipid: Add Exynos Chipid driver support

Exynos SoCs have Chipid, for identification of product IDs and SoC revistions. Till now we are using static macros such as soc_is_exynos and #ifdefs for run time identification of SoCs and their revisions. This is leading to add new Kconfig, soc_is_exynos definitions each time new SoC suppo

[PATCH v3 4/6] ARM: EXYNOS: Remove unused header inclusion from hotplug.c

This patch removed "plat/cpu.h" inclusion from hotplug.c as it is not required. Signed-off-by: Pankaj Dubey --- arch/arm/mach-exynos/hotplug.c |2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c index 0243ef3..5e19601 100644 ---

[PATCH v3 6/6] ARM: EXYNOS: Refactoring to remove soc_is_exynos macros from exynos

This patch enables chipid driver for ARCH_EXYNOS and refactors machine code as well as exynos cpufreq driver code for using chipid driver for identification of SoC ID and SoC rev. This patch also updates DT binding information in exynos4 and exynos5 dtsi file. As to differentiate product id bit-ma

[PATCH v3 2/6] ARM: EXYNOS: Remove i2c sys configuration related code

Since all these code has been moved into i2c driver, now we can safely remove them from machine files. CC: Russell King Signed-off-by: Pankaj Dubey --- arch/arm/mach-exynos/exynos.c | 38 +-- arch/arm/mach-exynos/include/mach/map.h |3 --- arch/arm/ma

[PATCH v3 0/6] Introducing Exynos ChipId driver

This patch series attempts to get rid of soc_is_exynos macros and eventually with the help of this series we can probably get rid of CONFIG_SOC_EXYNOS in near future. Each Exynos SoC has ChipID block which can give information about SoC's product Id and revision number. Currently we have si

[PATCH v3 3/6] ARM: EXYNOS: Remove soc_is_exynos4/5 from exynos.c

From: Pankaj Dubey This patch removes usage of soc_is_exynos4/5 from exynos.c. For this we need to separate machine descriptors for exynos4 and exynos5. While doing this patch does some consolidation also. CC: Russell King CC: Thomas Abraham Signed-off-by: Pankaj Dubey --- arch/arm/mach-exyn

[PATCH v3 2/6] ARM: EXYNOS: Remove i2c sys configuration related code

From: Pankaj Dubey Since all these code has been moved into i2c driver, now we can safely remove them from machine files. CC: Russell King Signed-off-by: Pankaj Dubey --- arch/arm/mach-exynos/exynos.c | 38 +-- arch/arm/mach-exynos/include/mach/map.h |

[PATCH v3 3/6] ARM: EXYNOS: Remove soc_is_exynos4/5 from exynos.c

This patch removes usage of soc_is_exynos4/5 from exynos.c. For this we need to separate machine descriptors for exynos4 and exynos5. While doing this patch does some consolidation also. CC: Russell King CC: Thomas Abraham Signed-off-by: Pankaj Dubey --- arch/arm/mach-exynos/exynos.c

[PATCH v3 1/6] i2c: s3c2410: Handle i2c sys_cfg register in i2c driver

From: Pankaj Dubey Let's handle i2c interrupt re-configuration in i2c driver. This will help us in removing some soc specific checks from machine files. Since only Exynos5250, and Exynos5420 need to do this, added syscon based phandle to i2c device nodes of respective SoC DT files. Also handle sa

[PATCH v3 5/6] soc: samsung: exynos-chipid: Add Exynos Chipid driver support

From: Pankaj Dubey Exynos SoCs have Chipid, for identification of product IDs and SoC revistions. Till now we are using static macros such as soc_is_exynos and #ifdefs for run time identification of SoCs and their revisions. This is leading to add new Kconfig, soc_is_exynos definitions ea

[PATCH v3 6/6] ARM: EXYNOS: Refactoring to remove soc_is_exynos macros from exynos

From: Pankaj Dubey This patch enables chipid driver for ARCH_EXYNOS and refactors machine code as well as exynos cpufreq driver code for using chipid driver for identification of SoC ID and SoC rev. This patch also updates DT binding information in exynos4 and exynos5 dtsi file. As to differenti

[PATCH v3 4/6] ARM: EXYNOS: Remove unused header inclusion from hotplug.c

From: Pankaj Dubey This patch removed "plat/cpu.h" inclusion from hotplug.c as it is not required. Signed-off-by: Pankaj Dubey --- arch/arm/mach-exynos/hotplug.c |2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c index 0243ef

[PATCH v3 0/6] Introducing Exynos ChipId driver

From: Pankaj Dubey This patch series attempts to get rid of soc_is_exynos macros and eventually with the help of this series we can probably get rid of CONFIG_SOC_EXYNOS in near future. Each Exynos SoC has ChipID block which can give information about SoC's product Id and revision number.