On 05/05/2014 11:58 PM, Arnd Bergmann wrote:
On Monday 05 May 2014 18:23:55 Pankaj Dubey wrote:
On 05/04/2014 12:02 AM, Arnd Bergmann wrote:
Ideally this should be done by slightly restructuring the DT
source to make all on-chip devices appear below the soc node.
Currently I can't see soc node
On Mon, May 05, 2014 at 09:51:28AM -0700, Olof Johansson wrote:
> > All the rest of this series has been acked and applied. Do you have
> > time to review this patch?
> >
> > Thanks! :)
>
> FWIW, I've seen very little email traffic from Anton this year, he
> might have limited time for maintaine
Heiko Stübner wrote:
>
> This finally removes all remaining SAMSUNG_CLOCK conditional code
> from s3c24xx architectures.
>
> Signed-off-by: Heiko Stuebner
> ---
> This is of course meant to go on top of the s3c2410 ccf conversion
>
> arch/arm/mach-s3c24xx/Kconfig | 5 -
> arch/arm
Heiko Stübner wrote:
>
[...]
> > Anyway, Heiko, thanks for working on this. I'll try to review rest of
> > the series soon. (I'm attending the ELC next week, though, so I'm not
> > sure if I find some time then, though.)
>
Yeah, this series is really good to us.
> Just as a reminder, there isn
Heiko Stübner wrote:
>
> This series tries to simplify the s3c24xx debug macro, removing
> dependencies
> on mach/ includes, static mappings and finally moving it into
> include/debug.
>
I think, it's good way :)
> The one slightly invasive change is the need for the developer to select
> the ua
Tomasz Figa wrote:
>
> Hi Tomasz,
>
> On 16.04.2014 14:40, Tomasz Stanislawski wrote:
> > This patch adds missing pinctrls for I2C controllers 2-7.
> >
> > Signed-off-by: Tomasz Stanislawski
> > ---
> > arch/arm/boot/dts/exynos4.dtsi | 12
> > 1 file changed, 12 insertions(+)
>
Tomasz Figa wrote:
>
> Hi Tomasz,
>
> On 15.04.2014 16:25, Tomasz Stanislawski wrote:
> > The i2c_ak8975 controler uses label i2c8.
> > This alias is already used for I2C controller 8 defined
> > in file arch/arm/boot/dts/exynos4.dtsi.
> >
> > This patch renames a label for i2c_ak8975 to i2c9.
>
Sylwester Nawrocki wrote:
>
> Remove unused /camera/clock-controller node and add required clock
> properties to the camera node. This is required for a clock provider
> that will be referenced by image sensor devices.
> Also add required clock related changes to s5k6a3 device node and
> afvdd reg
Sylwester Nawrocki wrote:
>
> This patch enables the rear facing camera (s5c73m3) on TRATS2 board
> by adding the I2C0 bus controller, s5c73m3 sensor, MIPI CSI-2 receiver
> and the sensor's voltage regulator supply nodes.
>
> Signed-off-by: Andrzej Hajda
> Acked-by: Kyungmin Park
> Signed-off-b
Doug Anderson wrote:
>
> Arun,
>
> On Mon, May 5, 2014 at 2:25 AM, Arun Kumar K wrote:
> > Adds the google peach-pit board dts file which uses
> > exynos5420 SoC.
> >
> > Signed-off-by: Arun Kumar K
> > Signed-off-by: Doug Anderson
> > ---
> > arch/arm/boot/dts/Makefile |1
Tomasz Figa wrote:
>
> Hi,
>
Hi,
> On 02.05.2014 17:44, Doug Anderson wrote:
> > Arun,
> >
> > On Fri, May 2, 2014 at 5:48 AM, Arun Kumar K wrote:
> >> Adds the PWM nodes to 5420 pinctrl dtsi file.
> >>
> >> Signed-off-by: Arun Kumar K
> >> ---
> >> arch/arm/boot/dts/exynos5420-pinctrl.dtsi
Hello Tomasz,
thanks a lot for the support!
> The meaning of hdmiphy is ambiguous.
> In exynos4 spec there are _TWO_ components named HDMIPHY.
> The first one is a PLL that generates a clock for HDMI subsystem.
> This PLL is controlled by I2C.
>
> You can find an example of its bindings at:
> ht
As of now, we can have only one bridge hanging off the encoder.
With this patch, we allow multiple bridges to hang onto the same encoder
with the use of a simple next_bridge ptr.
The drm core calls bridge->funcs for the first bridge which
is attached to it, and its upto the individual bridge drive
implement basic panel controls as a drm_bridge so that
the existing bridges can make use of it.
The driver assumes that it is the last entity in the bridge chain.
Signed-off-by: Ajay Kumar
---
.../bindings/drm/bridge/bridge_panel.txt | 45
drivers/gpu/drm/bridge/Kconfig
modify the driver to call the bridge->funcs of the next bridge
in the chain.
We assume that the bridge sitting next to ptn3460 is a bridge-panel.
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/bridge/ptn3460.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --gi
This patchset is based on exynos-drm-next-todo branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
I have just put up Rob's and Sean's idea of chaining up the bridges
in code, and have implemented basic panel controls as a chained bridge.
This works w
On 05/05/2014 11:17 AM, Doug Anderson wrote:
> On Fri, May 2, 2014 at 7:00 PM, Tomasz Figa wrote:
>> Well, if you can use the device tree of peach-pit board and boot peach-pi
>> and vice-versa and it won't cause any hardware failures then I guess it's
>> fine to keep this string.
>
> I believe yo
On Mon, 5 May 2014, Abhilash Kesavan wrote:
> Add machine-dependent MCPM call-backs for Exynos5420. These are used
> to power up/down the secondary CPUs during boot, shutdown, s2r and
> switching.
>
> Signed-off-by: Thomas Abraham
> Signed-off-by: Inderpal Singh
> Signed-off-by: Andrew Brestick
On Tue, Apr 29, 2014 at 9:39 AM, Doug Anderson wrote:
> Anton,
>
> On Wed, Apr 23, 2014 at 8:56 AM, Doug Anderson wrote:
>> On the ARM Chromebook tps65090 has two masters: the AP (the main
>> processor running linux) and the EC (the embedded controller). The AP
>> is allowed to mess with FETs bu
From: Leela Krishna Amudala
Use generic exynos cpu power control functions to power up/down
and to know the status of the cpu.
Signed-off-by: Leela Krishna Amudala
---
arch/arm/mach-exynos/platsmp.c |9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-e
Add machine-dependent MCPM call-backs for Exynos5420. These are used
to power up/down the secondary CPUs during boot, shutdown, s2r and
switching.
Signed-off-by: Thomas Abraham
Signed-off-by: Inderpal Singh
Signed-off-by: Andrew Bresticker
Signed-off-by: Abhilash Kesavan
---
arch/arm/mach-exy
From: Andrew Bresticker
Add device-tree bindings for the ARM CCI-400 on Exynos5420. There
are two slave interfaces: one for the A15 cluster and one for the
A7 cluster.
Signed-off-by: Andrew Bresticker
Signed-off-by: Abhilash Kesavan
---
arch/arm/boot/dts/exynos5420.dtsi | 27 ++
From: Leela Krishna Amudala
Add generic cpu power control functions for exynos based SoCS
for cpu power up/down and to know the cpu status.
Signed-off-by: Leela Krishna Amudala
---
arch/arm/mach-exynos/common.h |3 +++
arch/arm/mach-exynos/pm.c | 36 ++
Add generic cluster power control functions for exynos based SoCS
for cluster power up/down and to know the cluster status.
Signed-off-by: Abhilash Kesavan
---
arch/arm/mach-exynos/common.h |3 +++
arch/arm/mach-exynos/pm.c | 30 ++
arch/arm/mach-exynos/
This is v5 of the series adding MCPM backend support for SMP secondary boot
and core switching on Samsung's Exynos5420. The patches are based on the mcpm
support added for Exynos5420 in the Chromium kernel repository here:
https://chromium.googlesource.com/chromiumos/third_party/kernel-next/+/chrom
On Sat, May 3, 2014 at 10:02 AM, Arnd Bergmann wrote:
> On Saturday 03 May 2014 15:11:36 Pankaj Dubey wrote:
>> 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.
>> Ea
On Fri, May 2, 2014 at 7:00 PM, Tomasz Figa wrote:
> Well, if you can use the device tree of peach-pit board and boot peach-pi
> and vice-versa and it won't cause any hardware failures then I guess it's
> fine to keep this string.
I believe you can actually make it a good portion of the way throu
Arun,
On Mon, May 5, 2014 at 2:25 AM, Arun Kumar K wrote:
> Adds the google peach-pit board dts file which uses
> exynos5420 SoC.
>
> Signed-off-by: Arun Kumar K
> Signed-off-by: Doug Anderson
> ---
> arch/arm/boot/dts/Makefile |1 +
> arch/arm/boot/dts/exynos5420-peach-pit
On Monday 05 May 2014 16:58:14 Arnd Bergmann wrote:
> > Also for platsmp.c and pm.c I can think of following approaches
> > 1: Keep these macros till we get generic solution?
> > 2: Allow chipid driver to expose APIs to check SoC id and SoC revisions
> > till we get
> > generic solution. So that a
On Monday 05 May 2014 18:23:55 Pankaj Dubey wrote:
> On 05/04/2014 12:02 AM, Arnd Bergmann wrote:
> > Ideally this should be done by slightly restructuring the DT
> > source to make all on-chip devices appear below the soc node.
>
> Currently I can't see soc nodes in exynos4 and exynos5 DT files.
On 5 May 2014 19:55, Nishanth Menon wrote:
> On Mon, May 5, 2014 at 9:23 AM, Viresh Kumar wrote:
>>
>>
>> What if opp is being added for some reason at the same time?
>> I hope we can surely see some awkward results, maybe some
>> NULL pointers invocations as well..
>
> we wont - rcu operations e
On 5 May 2014 19:03, Nishanth Menon wrote:
> CPUFreq specific helper functions for OPP (Operating Performance Points)
> now use generic OPP functions that allow CPUFreq to be be moved back
> into CPUFreq framework. This allows for independent modifications
> or future enhancements as needed isolat
On Mon, May 5, 2014 at 9:23 AM, Viresh Kumar wrote:
>
>
> What if opp is being added for some reason at the same time?
> I hope we can surely see some awkward results, maybe some
> NULL pointers invocations as well..
we wont - rcu operations ensure that.
--
To unsubscribe from this list: send the
On 5 May 2014 19:03, Nishanth Menon wrote:
> diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
> int dev_pm_opp_init_cpufreq_table(struct device *dev,
> struct cpufreq_frequency_table **table)
> {
> - struct device_opp *dev_opp;
> struct d
On 05/04/2014 01:17 AM, Greg KH wrote:
> On Fri, Apr 11, 2014 at 01:48:28PM +0200, Tomasz Stanislawski wrote:
>> Hi everyone,
>> This patchset adds support for sii9234 HD Mobile Link Bridge. The chip is
>> used
>> to convert HDMI signal into MHL. The driver enables HDMI output on Trats and
>> Tr
CPUFreq usage of OPP should be independent of the ordering of type of
data storage inside OPP layer. The current operations can equally be
performed by generic operations.
[RFC]: https://patchwork.kernel.org/patch/4100811/
Series based on: v3.15-rc1
Nishanth Menon (2):
PM / OPP: Remove cpufreq
CPUFreq specific helper functions for OPP (Operating Performance Points)
now use generic OPP functions that allow CPUFreq to be be moved back
into CPUFreq framework. This allows for independent modifications
or future enhancements as needed isolated to just CPUFreq framework
alone.
Here, we just m
CPUFREQ custom functions for OPP (Operating Performance Points)
currently exist inside the OPP library. These custom functions currently
depend on internal data structures to pick up OPP information to create
the cpufreq table. For example, the cpufreq table is created precisely
in the same order
The exynos5420-peach-pit has a SMSC USB3503 connected in
hardware only mode like a PHY. Enable support for it,
and add necessary 'reset-gpio' for it.
This is in correspondance to similar patch by Mark Brown
7c1b0ec ARM: dts: Enable USB hub on Arndale
Signed-off-by: Vivek Gautam
---
Based on 'fo
The exynos5250-snow has a SMSC USB3503 connected in
hardware only mode like a PHY. Enable support for it,
and add necessary 'reset-gpio' for it.
This is in correspondance to similar patch by Mark Brown
7c1b0ec ARM: dts: Enable USB hub on Arndale
Signed-off-by: Vivek Gautam
---
Based on 'for-nex
On 04/27/2014 03:50 AM, YoungJun Cho wrote:
> The offset of register DSIM_PLLTMR_REG in Exynos5420 is different
> from the one in Exynos4 SoC.
>
> In case of Exynos5420 SoC, there is no frequency band bit in DSIM_PLLCTRL_REG,
> and it uses DSIM_PHYCTRL_REG and DSIM_PHYTIMING*_REG instead.
> So thi
Cache number of non-hardware trigger levels in a new pdata field
(non_hw_trigger_levels) and convert code in exynos_tmu_initialize()
accordingly.
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/thermal/samsung/exynos_tmu.c |
There is no need for abstracting configuration for registers that
are identical on all SoC types.
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/thermal/samsung/exynos_tmu.c | 12 ++--
drivers/thermal/samsung/exynos_
pdata->reference_voltage and pdata->gain are always defined
to non-zero values so remove the redundant checks from
exynos_tmu_control().
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/thermal/samsung/exynos_tmu.c | 12 ---
* Remove dead temp check from temp_to_code() (this function users
in exynos_tmu_initialize() always pass correct temperatures and
exynos_tmu_set_emulation() returns early for EXYNOS4210 because
TMU_SUPPORT_EMULATION flag is not set on this SoC).
* Move temp_code check from code_to_temp() to
Remove runtime checks for negative return values of temp_to_code()
from exynos_tmu_initialize(). The current level temperature data
hardcoded in pdata will never cause a negative temp_to_code()
return values and for the new code potential mistakes should be
caught during development/review phases.
Remove runtime checks for pdata sanity from exynos_tmu_initialize().
The current values hardcoded in pdata will never trigger the checks
and for the new code potential mistakes should be caught during
development/review phases.
There should be no functional changes caused by this patch.
Signed-of
Only TYPE_ONE_POINT_TRIMMING calibration is used so remove
the dead code for TYPE_TWO_POINT_TRIMMING calibration.
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/thermal/samsung/exynos_tmu.c | 55 ++---
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/thermal/samsung/exynos_tmu.c | 33 +--
drivers/thermal/samsung/exynos_tmu.h | 13
drivers/thermal/samsung/exynos_tmu_data.c | 3 ---
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/thermal/samsung/exynos_tmu_data.h | 27 +--
1 file changed, 1 insertion(+), 26 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu_data.h
b/drivers/
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/thermal/samsung/exynos_tmu.h | 40 ---
drivers/thermal/samsung/exynos_tmu_data.c | 2 --
drivers/thermal/samsung/exynos_tmu_data.h | 1 -
3 files ch
Hi,
This patch series contains various cleanups for EXYNOS thermal
driver. Overall it decreases driver's LOC by 13%. It is based
on next-20140428 kernel. It should not cause any functionality
changes.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
On some platforms (i.e. EXYNOS ones) more than one idle mode is
available and we need to distinguish them in firmware do_idle method.
Add mode parameter to do_idle firmware method and AFTR mode support
to EXYNOS do_idle implementation.
This change is a preparation for adding secure firmware suppo
* Use do_idle firmware method instead of cpu_do_idle() on boards
with secure firmware enabled.
* Use S5P_VA_SYSRAM_NS + 0x24 address for exynos_boot_vector_addr()
and S5P_VA_SYSRAM_NS + 0x20 one for exynos_boot_vector_flag() on
boards with secure firmware enabled.
This patch fixes hang on a
From: Tomasz Figa
This change is a preparation for adding secure firmware support to
EXYNOS cpuidle driver.
This patch shouldn't cause any functionality changes.
Signed-off-by: Tomasz Figa
[bzolnier: splitted out from bigger patch]
Signed-off-by: Bartlomiej Zolnierkiewicz
---
arch/arm/includ
Add S5P_CENTRAL_SEQ_OPTION register setup for EXYNOS4x12 to AFTR
mode code. Without this setup AFTR mode doesn't show any benefit
over WFI one. When this setup is applied AFTR mode reduces power
consumption by ~12% (as measured on Trats2 board).
This change is a preparation for adding secure fir
Use c15resume firmware method instead of accessing the registers
directly in exynos_cpu_restore_register() if secure firmware is
enabled. This affects both PM resume method and cpuidle AFTR mode.
This patch shouldn't cause any functionality changes on boards that
don't use secure firmware.
Signe
Replace EXYNOS_BOOT_VECTOR_ADDR and EXYNOS_BOOT_VECTOR_FLAG macros
by exynos_boot_vector_addr() and exynos_boot_vector_flag() static
inlines.
This patch shouldn't cause any functionality changes.
Signed-off-by: Bartlomiej Zolnierkiewicz
---
arch/arm/mach-exynos/pm.c | 28 ---
From: Kyungmin Park
To support multi-platform, it needs to know it's running under secure
OS or not. Sometimes it needs to access physical address by SMC calls.
e.g.,
if (firmware_run()) {
addr = physical address;
} else {
addr = virtual address;
Hi,
This patch series fixes support for AFTR idle mode on boards with
secure firmware enabled (it also includes fix for register setup on
EXYNOS4x12 SoCs). It has been tested on Trats2 target but should
also work on (EXYNOS4412 based) Insignal Origen board.
This patchset depends on "[PATCH V5 00
On 04/27/2014 03:50 AM, YoungJun Cho wrote:
> This patch adds DT bindings for s6e3fa0 panel.
> The bindings describes panel resources, display timings and cpu mode timings.
>
> Changelog v2:
> - Adds unit address (commented by Sachin Kamat)
> Changelog v3:
> - Removes optional delay, size properti
On 05/05/2014 11:50 AM, Arun Kumar K wrote:
> Hi Hans,
>
> On Wed, Apr 30, 2014 at 8:03 PM, Hans Verkuil wrote:
>> On 04/30/2014 12:38 PM, Arun Kumar K wrote:
>>> Hi Hans,
>>>
>>>
>>> On 04/22/14 18:22, Hans Verkuil wrote:
On 04/21/2014 11:26 AM, Arun Kumar K wrote:
> From: Pawel Osciak
Hi Hans,
On Wed, Apr 30, 2014 at 8:03 PM, Hans Verkuil wrote:
> On 04/30/2014 12:38 PM, Arun Kumar K wrote:
>> Hi Hans,
>>
>>
>> On 04/22/14 18:22, Hans Verkuil wrote:
>>> On 04/21/2014 11:26 AM, Arun Kumar K wrote:
From: Pawel Osciak
This event indicates that the decoder has reac
Hi,
On Wednesday 09 April 2014 03:31 PM, Sylwester Nawrocki wrote:
> Hi,
>
> On 09/04/14 11:12, Rahul Sharma wrote:
>> Idea looks good. How about keeping compatible which is independent
>> of SoC, something like "samsung,exynos-simple-phy" and provide Reg
>> and Bit through phy provider node. Thi
Add support to select generic big-little cpuidle driver for Samsung Exynos
series SoC's. This is required for Exynos big-llittle SoC's eg, Exynos5420.
Signed-off-by: Chander Kashyap
Signed-off-by: Chander Kashyap
---
Changes in v4:
1. Typo fixed from SOC_EXYNOS5420 to ARCH_EXYNOS
Add "samsung,exynos5420" compatible string to initialize generic
big-little cpuidle driver for Exynos5420.
Signed-off-by: Chander Kashyap
Signed-off-by: Chander Kashyap
Acked-by: Daniel Lezcano
---
Changes in v4: None
Changes in v3:
1. Add compatible string to of_device_id table insted
Exynos5420 is big.Little Soc. It uses cpuidle-big-litle generic cpuidle driver.
Hence do not allow exynos cpuidle driver registration for Exynos5420.
Signed-off-by: Chander Kashyap
Signed-off-by: Chander Kashyap
Acked-by: Daniel Lezcano
---
arch/arm/mach-exynos/cpuidle.c |3 +++
1 file cha
In order to support cpuidle through mcpm, suspend and powered-up
callbacks are required in mcpm platform code.
Hence populate the same callbacks.
Signed-off-by: Chander Kashyap
Signed-off-by: Chander Kashyap
---
Changes in v4: None
Changes in v3:
1. Removed coherancy enablement after sus
e [enabled by
default]
Signed-off-by: Sachin Kamat
Cc: Rob Herring
---
Based on linux-next (20140505)
---
arch/arm/mach-exynos/exynos.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 77293d39dfc9..f3
This driver will be used by many big.Little Soc's. As of now it does
string matching of hardcoded compatible string to init the driver. This
comparison list will keep on growing with addition of new SoC's.
Hence add of_device_id structure to collect the compatible strings of
SoC's using this driver
Exynos5420 is a big-little Soc from Samsung. It has 4 A15 and 4 A7 cores.
This patchset adds cpuidle support for Exynos5420 SoC based on
generic big.little cpuidle driver.
Tested on SMDK5420.
This patch set depends on:
1. [PATCH 0/5] MCPM backend for Exynos5420
http://www.spin
Hi Tobias,
Sorry for a late reply.
Please refer to the comments below.
On 04/27/2014 02:33 AM, Tobias Jakobi wrote:
> Hello,
>
> I'm trying to get the HDMI port working on a Exynos4412 based board.
> Attached is a snippet of a dts. This config was supposed to "work" in
> the past.
>
> However wi
Dependencies
Adding pwm nodes for backlight
https://patchwork.kernel.org/patch/4101881/
Changes from v3
--
- Addressed comments from Tomasz and Doug.
Changes from v2
--
- Use reference based node addressing in board dts file
as suggested by Tomasz.
- Include
Adding labels to nodes which do not have it yet
in exynos5420.dtsi. This is done so as to use reference
based node updation in board files.
Signed-off-by: Arun Kumar K
Reviewed-by: Tomasz Figa
Reviewed-by: Doug Anderson
---
arch/arm/boot/dts/exynos5420.dtsi | 26 +-
1
Adds the google peach-pit board dts file which uses
exynos5420 SoC.
Signed-off-by: Arun Kumar K
Signed-off-by: Doug Anderson
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/exynos5420-peach-pit.dts | 147
2 files changed, 148 insertions(+
On 05/05/2014 04:57 PM, Krzysztof Kozlowski wrote:
On sob, 2014-05-03 at 15:11 +0900, Pankaj Dubey wrote:
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 7eb4b69..48c8fb5 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -55,3 +55,4 @@ obj-$(CONFIG_SRAM)
Hi Andreas,
On 5 May 2014 14:29, Andreas Färber wrote:
> Hi,
>
> Am 05.05.2014 10:27, schrieb Chander Kashyap:
>> Exynos5420 is a big-little SoC from Samsung. It has 4 A15 and 4 A7 cores.
>> In order to use generic cpuidle-big-little driver, this patch adds Exynos5420
>> specific check to initial
Hi Arnd,
Thanks for review and suggestions.
On 05/04/2014 12:02 AM, Arnd Bergmann wrote:
On Saturday 03 May 2014 15:11:36 Pankaj Dubey wrote:
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_EXYN
Hi,
Am 05.05.2014 10:27, schrieb Chander Kashyap:
> Exynos5420 is a big-little SoC from Samsung. It has 4 A15 and 4 A7 cores.
> In order to use generic cpuidle-big-little driver, this patch adds Exynos5420
> specific check to initialize generic cpuidle driver.
>
> Signed-off-by: Chander Kashyap
This driver will be used by many big.Little Soc's. As of now it does
string matching of hardcoded compatible string to init the driver. This
comparison list will keep on growing with addition of new SoC's.
Hence add of_device_id structure to collect the compatible strings of
SoC's using this driver
Add "samsung,exynos5420" compatible string to initialize generic
big-little cpuidle driver for Exynos5420.
Signed-off-by: Chander Kashyap
Signed-off-by: Chander Kashyap
Acked-by: Daniel Lezcano
---
Changes in v3:
1. Add compatible string to of_device_id table insted comparing
directoly
Exynos5420 is a big-little SoC from Samsung. It has 4 A15 and 4 A7 cores.
In order to use generic cpuidle-big-little driver, this patch adds Exynos5420
specific check to initialize generic cpuidle driver.
Signed-off-by: Chander Kashyap
Signed-off-by: Chander Kashyap
---
Changes in v3: None
Chang
In order to support cpuidle through mcpm, suspend and powered-up
callbacks are required in mcpm platform code.
Hence populate the same callbacks.
Signed-off-by: Chander Kashyap
Signed-off-by: Chander Kashyap
---
Changes in v3:
1. Removed coherance enablement after suspend failure.
Exynos5420 is big.Little Soc. It uses cpuidle-big-litle generic cpuidle driver.
Hence do not allow exynos cpuidle driver registration for Exynos5420.
Signed-off-by: Chander Kashyap
Signed-off-by: Chander Kashyap
Acked-by: Daniel Lezcano
---
arch/arm/mach-exynos/cpuidle.c |3 +++
1 file cha
Exynos5420 is a big-little Soc from Samsung. It has 4 A15 and 4 A7 cores.
This patchset adds cpuidle support for Exynos5420 SoC based on
generic big.little cpuidle driver.
Tested on SMDK5420.
This patch set depends on:
1. [PATCH 0/5] MCPM backend for Exynos5420
http://www.spin
On sob, 2014-05-03 at 15:11 +0900, Pankaj Dubey wrote:
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index 7eb4b69..48c8fb5 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -55,3 +55,4 @@ obj-$(CONFIG_SRAM) += sram.o
> obj-y
On 05/01/2014 11:11 AM, Russell King - ARM Linux wrote:
> On Thu, May 01, 2014 at 09:04:19AM +0200, Andrzej Hajda wrote:
>> 2. You replace calls of component_add and component_del with calls
>> to interface_tracker_ifup(dev, INTERFACE_TRACKER_TYPE_COMPONENT,
>> &specific_component_ops),
>> or int
87 matches
Mail list logo
