Re: [PATCH v3 01/16] clk: exynos5420: rename parent clocks

2014-05-04 Thread Shaik Ameer Basha
On Mon, May 5, 2014 at 10:58 AM, Shaik Ameer Basha wrote: > Hi Tomasz, > > > On Thu, May 1, 2014 at 11:09 PM, Tomasz Figa wrote: >> Hi Shaik, >> >> Thanks for splitting the series into reasonably-sized patches. It's much >> more convenient to review them now. >> >> >> On 24.04.2014 15:03, Shaik A

Re: [PATCH v3 01/16] clk: exynos5420: rename parent clocks

2014-05-04 Thread Shaik Ameer Basha
Hi Tomasz, On Thu, May 1, 2014 at 11:09 PM, Tomasz Figa wrote: > Hi Shaik, > > Thanks for splitting the series into reasonably-sized patches. It's much > more convenient to review them now. > > > On 24.04.2014 15:03, Shaik Ameer Basha wrote: >> >> This patch modifies the defined parent clock nam

[PATCH v4 2/4] usb: ehci-exynos: Use struct device instead of platform_device

2014-05-04 Thread Vivek Gautam
Change to use struct device instead of struct platform_device for some static functions. Signed-off-by: Vivek Gautam Acked-by: Alan Stern Acked-by: Jingoo Han Acked-by: Kukjin Kim --- Changes since v1: - none drivers/usb/host/ehci-exynos.c |5 ++--- 1 file changed, 2 insertions(+), 3 d

[PATCH v4 1/4] usb: ohci-exynos: Use struct device instead of platform_device

2014-05-04 Thread Vivek Gautam
Change to use struct device instead of struct platform_device for some static functions. Signed-off-by: Vivek Gautam Acked-by: Alan Stern Acked-by: Jingoo Han Acked-by: Kukjin Kim --- Changes since v1: - none drivers/usb/host/ohci-exynos.c | 20 +--- 1 file changed, 9 ins

[PATCH v6 3/4] usb: ohci-exynos: Add facility to use phy provided by the generic phy framework

2014-05-04 Thread Vivek Gautam
Add support to consume phy provided by Generic phy framework. Keeping the support for older usb-phy intact right now, in order to prevent any functionality break in absence of relevant device tree side change for ohci-exynos. Once we move to new phy in the device nodes for ohci, we can remove the s

[PATCH v12 4/4] usb: ehci-exynos: Change to use phy provided by the generic phy framework

2014-05-04 Thread Vivek Gautam
From: Kamil Debski Add the phy provider, supplied by new Exynos-usb2phy using Generic phy framework. Keeping the support for older USB phy intact right now, in order to prevent any functionality break in absence of relevant device tree side change for ehci-exynos. Once we move to new phy in the d

Re: [PATCH v3 00/16] exynos5420: clock file cleanup

2014-05-04 Thread Shaik Ameer Basha
Hi Tomasz, On Fri, May 2, 2014 at 2:58 AM, Tomasz Figa wrote: > On 24.04.2014 15:03, Shaik Ameer Basha wrote: >> >> Many changes/fixes have been identified for clock file for exynos5420. >> These include correct parents, bit fields, new clocks etc. Existing >> files needs some correction in terms

Re: [PATCH v3 02/16] clk: exynos5420: add clocks for ISP block

2014-05-04 Thread Shaik Ameer Basha
Hi Tomasz, On Fri, May 2, 2014 at 3:03 AM, Tomasz Figa wrote: > On 24.04.2014 15:03, Shaik Ameer Basha wrote: >> >> This patch adds missing clocks for ISP block >> >> Signed-off-by: Rahul Sharma >> Signed-off-by: Shaik Ameer Basha >> --- >> drivers/clk/samsung/clk-exynos5420.c | 80 >>

Re: Bare metal Code to test Big Little on Arndale Octa (5420)

2014-05-04 Thread Amit Kucheria
Hi, No public code has been released to boot all 8 cores on the 5420. You can only see the A15s. You could however, if you are interested, get IKS[1] working by integrating the MCPM patches posted by Samsung and the IKS patches that are already in mainline. Regards, Amit [1] http://lwn.net/Artic

Re: [PATCH] arm: exynos: add generic function to calculate cpu number

2014-05-04 Thread Chander Kashyap
On 25 April 2014 11:14, Chander Kashyap wrote: > The address of cpu power registers in pmu is based on cpu number > offsets. This function calculate the same. This is essentially > required in case of multicluster SoC's e.g Exynos5420. > > Signed-off-by: Chander Kashyap > Signed-off-by: Chander K

Re: [PATCH v3 02/16] clk: exynos5420: add clocks for ISP block

2014-05-04 Thread Shaik Ameer Basha
Hi Tomasz, Thanks for the review comments. On Fri, May 2, 2014 at 2:55 AM, Tomasz Figa wrote: > On 01.05.2014 23:09, Tomasz Figa wrote: >> >> Hi Shaik, >> >> On 24.04.2014 15:03, Shaik Ameer Basha wrote: >>> >>> This patch adds missing clocks for ISP block >>> >>> Signed-off-by: Rahul Sharma >>

Re: [PATCH 1/1] ARM: dts: Add MFC memory banks to Exynos5420 boards

2014-05-04 Thread Sachin Kamat
On 17 March 2014 11:41, Sachin Kamat wrote: > Add MFC memory banks to Exynos5420 based SMDK and Arndale-octa boards. > > Signed-off-by: Sachin Kamat > --- > arch/arm/boot/dts/exynos5420-arndale-octa.dts |5 + > arch/arm/boot/dts/exynos5420-smdk5420.dts |5 + > 2 files changed

Re: [PATCH 1/1] ARM: dts: Fix SPI interrupt numbers for Exynos5420

2014-05-04 Thread Sachin Kamat
On 10 April 2014 18:28, Sachin Kamat wrote: > Updated as per the user manual. > > Signed-off-by: Sachin Kamat > --- > arch/arm/boot/dts/exynos5420.dtsi |6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/arm/boot/dts/exynos5420.dtsi > b/arch/arm/boot/dts/exyno

Re: [PATCH v2 0/6] Further cleanup and enable multiplat build

2014-05-04 Thread Sachin Kamat
On 16 April 2014 19:21, Tomasz Figa wrote: > Hi Sachin, > > > On 15.04.2014 11:28, Sachin Kamat wrote: >> >> This series is based on latest linux-next and depends on the >> following patch: >> ARM: EXYNOS: Consolidate Kconfig entries >> http://article.gmane.org/gmane.linux.kernel.samsung-soc/28642

Re: [PATCH 1/1] ARM: dts: Keep LDO4 always ON on Arndale board

2014-05-04 Thread Sachin Kamat
On 21 April 2014 10:33, Sachin Kamat wrote: > LDO4 regulator was getting disabled preventing the system from > going into low power states. Keep it always on to fix it. > > Signed-off-by: Sachin Kamat > --- > arch/arm/boot/dts/exynos5250-arndale.dts |1 + > 1 file changed, 1 insertion(+) > >

[PATCH 1/4] drm/exynos/mixer: move format definitions to regs-mixer

2014-05-04 Thread Daniel Kurtz
These constants directly define register values, so move them to the register definition header. Also, the logic used for setting fmt from bpp is either/or, so just use if/else. ** No functional change Signed-off-by: Daniel Kurtz --- drivers/gpu/drm/exynos/exynos_mixer.c | 19 -

[PATCH 2/4] drm/exynos/mixer: use MXR_GRP_SXY_SY

2014-05-04 Thread Daniel Kurtz
Mixer hardware supports offsetting dma from start of source buffer using the MXR_GRP_SXY register. Signed-off-by: Daniel Kurtz --- drivers/gpu/drm/exynos/exynos_mixer.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gp

[PATCH 3/4] drm/exynos/mixer: planes are not disabled by setting dma_addr to zero

2014-05-04 Thread Daniel Kurtz
Planes are disabled by calling the win_mode_disable() callback, not by calling win_mode_commit()[->vp_video_buffer] with dma_addr set to zero. Thus, the comment in the pixel_format switch default clause is obsolete, we should always check if the pixel_format is supported, and therefore, since the

[PATCH 4/4] drm/exynos/mixer: add support for NV21

2014-05-04 Thread Daniel Kurtz
AFAICT, the only difference between NV12 and NV21 is Cr:Cb vs Cb:Cr. Since the video processor can handle either order, it should be able to handle both formats. Signed-off-by: Daniel Kurtz --- drivers/gpu/drm/exynos/exynos_drm_plane.c | 1 + drivers/gpu/drm/exynos/exynos_mixer.c | 12 +

[PATCH 0/4] drm/exynos/mixer: small cleanups

2014-05-04 Thread Daniel Kurtz
I don't actually have a way of testing the video processor changes, but they seem correct from looking at the code. Hopefully someone has a way of testing them. Daniel Kurtz (4): drm/exynos/mixer: move format definitions to regs-mixer drm/exynos/mixer: use MXR_GRP_SXY_SY drm/exynos/mixer: p

Re: [PATCH v2 1/2] ARM: EXYNOS: Map SYSRAM through generic SRAM bindings

2014-05-04 Thread Sachin Kamat
Hi Tomasz, On 2 May 2014 23:24, Tomasz Figa wrote: > Hi Sachin, > > The whole series looks quite good, Thanks :) >but I have one concern about support for > Universal C210 board. Please see my comment inline. > > > On 02.05.2014 07:06, Sachin Kamat wrote: >> >> Instead of hardcoding the SYSRAM