[PATCH 1/1] ARM: dts: Add missing clock names for exynos4412 dwmmc node

2013-12-01 Thread Alex Ling
This patch adds biu and ciu clock names for exynos4412 dwmmc node. Without this patch, dwmmc host driver will skip enabling the two clocks and it will break dwmmc host function on exynos4412. Tested on FriendlyARM TINY4412 board. Signed-off-by: Alex Ling kasiml...@gmail.com ---

Re: [RFC PATCH v2 0/7] VFIO for device tree based platform devices (work in progress)

2013-12-01 Thread Kim Phillips
On Mon, 30 Sep 2013 17:28:36 +0200 Antonios Motakis a.mota...@virtualopensystems.com wrote: This is a preview of the base work, towards VFIO support on ARM platforms with an IOMMU. It forms a base on to which to implement the functionality necessary to enable using device tree devices on ARM

Re: [PATCH 1/1] ARM: dts: Add missing clock names for exynos4412 dwmmc node

2013-12-01 Thread randy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't know whether it will works. Actually I don't what the name used for. So I just referencing my mail before. Thank you - origin mail 主题: Re: linux 3.13-rc1 make dw_mmc-exynos more worse 日期: Tue, 26 Nov 2013 14:00:20 +0800 发件人:

Re: How to enable usb in exynos4412

2013-12-01 Thread randy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 But do you notice the mail Tomasz sent to me before? I don't know whether the power control reg address of your code is correct. As the status is disable in your code, so shall I change it to okay When I test it? I will do a test later.

Re: How to enable usb in exynos4412

2013-12-01 Thread randy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yes, the usb is workable. The 0x1001021c is the USB control register from samsung datasheet(12.2) Thank you. I will check my code to know why it doesn't work. I didn't notice your work in mail list before. But I think we shall separate hw:1306 and

Re: How to enable usb in exynos4412

2013-12-01 Thread Tomasz Figa
Hi, Since it seems like you are not quite accustomed to posting on mailing lists yet, I'd like to recommend you to read following great article: http://linux.sgms-centre.com/misc/netiquette.php Applying the simple rules pointed there will save you from potential unpleasant reception of your

Re: [PATCH v2] irqchip: exynos-combiner: remove hard-coded irq_base value

2013-12-01 Thread Kukjin Kim
On 11/25/13 15:37, Chander Kashyap wrote: Hi Kikjin, Hi Chander, On 21 October 2013 02:32, Kukjin Kimkgene@samsung.com wrote: On 10/18/13 02:53, Tomasz Figa wrote: Hi Kukjin, On Thursday 26 of September 2013 14:05:09 Kukjin Kim wrote: Chander Kashyap wrote: Replace

Re: How to enable usb in exynos4412

2013-12-01 Thread kasim ling
(Resend in plain text mode) Hi, Randy, I'm also working with FriendlyARM Tiny4412 board and I've had a working 3.13-rc2-based kernel tree with USB host function working. You can refer to my commit at https://github.com/kasimling/linux/commit/a452fb006c657de5c038f04d8f610567580ea99c. You can also

Re: [PATCH 2/2] ARM: dts: Update display clock frequency for Origen-4412

2013-12-01 Thread Sachin Kamat
On 13 November 2013 09:17, Tushar Behera tushar.beh...@linaro.org wrote: On 12 November 2013 15:47, Kukjin Kim kg...@kernel.org wrote: Sachin Kamat wrote: + dt ml. As per the timing information for supported panel, the value should be between 47.2 MHz to 47.9 MHz for 60Hz refresh rate.

Re: [PATCH v3 1/2] ARM: dts: Fix sysreg node name in exynos4.dtsi

2013-12-01 Thread Sachin Kamat
On 12 November 2013 16:10, Kukjin Kim kg...@kernel.org wrote: Sachin Kamat wrote: Fix the name as per DT node naming convention. - rename the node to syscon which is a more generic name. - append the register value to the node name. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org

[PATCH V4 0/6] cpufreq: suspend early/resume late: dpm_{suspend|resume}()

2013-12-01 Thread Viresh Kumar
This patchset moves cpufreq callbacks to dpm_{suspend|resume}() from dpm_{suspend|resume}_noirq() for handling suspend/resume of cpufreq governors and core. This is required for early suspend and late resume of governors as there are drivers which want to change cpu frequency before suspending

[PATCH V4 5/6] cpufreq: s5pv210: Use cpufreq_generic_suspend()

2013-12-01 Thread Viresh Kumar
Currently we have implemented PM notifiers to disable/enable -target() routines functionality during suspend/resume. Now we have support present in cpufreq core, lets use it. Signed-off-by: Viresh Kumar viresh.ku...@linaro.org --- drivers/cpufreq/s5pv210-cpufreq.c | 49

[PATCH V4 3/6] cpufreq: Implement cpufreq_generic_suspend()

2013-12-01 Thread Viresh Kumar
Multiple platforms need to set CPU to a particular frequency before suspending system. And so they need a common infrastructure which is provided by this patch. Those platforms just need to initialize their -suspend() pointers with the generic routine. Tested-by: Stephen Warren swar...@nvidia.com

[PATCH V4 6/6] cpufreq: Tegra: Use cpufreq_generic_suspend()

2013-12-01 Thread Viresh Kumar
Currently we have implemented PM notifiers to disable/enable -target() routines functionality during suspend/resume. Now we have support present in cpufreq core, lets use it. Acked-and-tested-by: Stephen Warren swar...@nvidia.com Signed-off-by: Viresh Kumar viresh.ku...@linaro.org ---

[PATCH V4 4/6] cpufreq: exynos: Use cpufreq_generic_suspend()

2013-12-01 Thread Viresh Kumar
Currently we have implemented PM notifiers to disable/enable -target() routines functionality during suspend/resume. Now we have support present in cpufreq core, lets use it. Signed-off-by: Viresh Kumar viresh.ku...@linaro.org --- drivers/cpufreq/exynos-cpufreq.c | 96

[PATCH V4 1/6] cpufreq: suspend governors from dpm_{suspend|resume}()

2013-12-01 Thread Viresh Kumar
Recently support for suspending governors has been added in cpufreq and callbacks are called from dpm_{suspend|resume}_noirq(). The problem here is that most of the devices (i.e. devices with -suspend() callbacks) have already been suspended by now and so if drivers want to change frequency before

[PATCH V4 2/6] cpufreq: call driver's suspend/resume for each policy

2013-12-01 Thread Viresh Kumar
Earlier cpufreq suspend/resume callbacks into drivers were getting called only for the boot CPU, as by the time callbacks were called non-boot CPUs were already removed. Because we might still need driver specific actions on suspend/resume, its better to use earlier infrastructure from the early