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
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
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
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 chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
Acked-by: Daniel Lezcano
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 chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
---
Changes in v3:
1. Removed
Add samsung,exynos5420 compatible string to initialize generic
big-little cpuidle driver for Exynos5420.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
Acked-by: Daniel Lezcano daniel.lezc...@linaro.org
---
Changes in v3:
1.
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 chander.kash...@linaro.org
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
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
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
Hi Andreas,
On 5 May 2014 14:29, Andreas Färber afaer...@suse.de 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
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)
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.
-
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 arun...@samsung.com
Reviewed-by: Tomasz Figa t.f...@samsung.com
Reviewed-by: Doug Anderson diand...@chromium.org
---
Adds the google peach-pit board dts file which uses
exynos5420 SoC.
Signed-off-by: Arun Kumar K arun...@samsung.com
Signed-off-by: Doug Anderson diand...@chromium.org
---
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/exynos5420-peach-pit.dts | 147
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 with
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
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
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 chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
---
Changes in v4:
1. Typo
Add samsung,exynos5420 compatible string to initialize generic
big-little cpuidle driver for Exynos5420.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
Acked-by: Daniel Lezcano daniel.lezc...@linaro.org
---
Changes in v4: None
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 chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
Acked-by: Daniel Lezcano
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 chander.kash...@linaro.org
Signed-off-by: Chander Kashyap k.chan...@samsung.com
---
Changes in v4: None
Changes in v3:
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. This way we
Hi Hans,
On Wed, Apr 30, 2014 at 8:03 PM, Hans Verkuil hverk...@xs4all.nl 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 posc...@chromium.org
This event indicates that the
On 05/05/2014 11:50 AM, Arun Kumar K wrote:
Hi Hans,
On Wed, Apr 30, 2014 at 8:03 PM, Hans Verkuil hverk...@xs4all.nl 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
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 properties
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
From: Kyungmin Park kyungmin.p...@samsung.com
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 {
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.
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 b.zolnier...@samsung.com
---
arch/arm/mach-exynos/pm.c |
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
From: Tomasz Figa t.f...@samsung.com
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 t.f...@samsung.com
[bzolnier: splitted out from bigger patch]
Signed-off-by: Bartlomiej
* 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
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
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 RD Institute Poland
Samsung Electronics
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.h | 40 ---
drivers/thermal/samsung/exynos_tmu_data.c | 2 --
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/thermal/samsung/exynos_tmu_data.h | 27 +--
1 file changed, 1 insertion(+), 26 deletions(-)
diff --git
There should be no functional changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 33 +--
drivers/thermal/samsung/exynos_tmu.h | 13
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 b.zolnier...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 55
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
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.
* 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
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 b.zolnier...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 12 ++--
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 b.zolnier...@samsung.com
---
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 b.zolnier...@samsung.com
---
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 this
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
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
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
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
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
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
Trats2
On 5 May 2014 19:03, Nishanth Menon n...@ti.com 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;
On Mon, May 5, 2014 at 9:23 AM, Viresh Kumar viresh.ku...@linaro.org 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
On 5 May 2014 19:03, Nishanth Menon n...@ti.com 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
On 5 May 2014 19:55, Nishanth Menon n...@ti.com wrote:
On Mon, May 5, 2014 at 9:23 AM, Viresh Kumar viresh.ku...@linaro.org 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
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.
So
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 at least
Arun,
On Mon, May 5, 2014 at 2:25 AM, Arun Kumar K arun...@samsung.com wrote:
Adds the google peach-pit board dts file which uses
exynos5420 SoC.
Signed-off-by: Arun Kumar K arun...@samsung.com
Signed-off-by: Doug Anderson diand...@chromium.org
---
arch/arm/boot/dts/Makefile
On Fri, May 2, 2014 at 7:00 PM, Tomasz Figa tomasz.f...@gmail.com 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
On Sat, May 3, 2014 at 10:02 AM, Arnd Bergmann a...@arndb.de 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
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:
From: Andrew Bresticker abres...@chromium.org
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 abres...@chromium.org
Signed-off-by: Abhilash Kesavan
From: Leela Krishna Amudala leela.kris...@linaro.org
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 leela.kris...@linaro.org
---
arch/arm/mach-exynos/common.h |3 +++
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 a.kesa...@samsung.com
---
arch/arm/mach-exynos/common.h |3 +++
arch/arm/mach-exynos/pm.c | 30 ++
From: Leela Krishna Amudala leela.kris...@linaro.org
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 leela.kris...@linaro.org
---
arch/arm/mach-exynos/platsmp.c |9 +++--
1 file changed, 3
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 thomas...@samsung.com
Signed-off-by: Inderpal Singh inderpa...@samsung.com
Signed-off-by: Andrew Bresticker
On Tue, Apr 29, 2014 at 9:39 AM, Doug Anderson diand...@chromium.org wrote:
Anton,
On Wed, Apr 23, 2014 at 8:56 AM, Doug Anderson diand...@chromium.org wrote:
On the ARM Chromebook tps65090 has two masters: the AP (the main
processor running linux) and the EC (the embedded controller). The
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 thomas...@samsung.com
Signed-off-by: Inderpal Singh
On 05/05/2014 11:17 AM, Doug Anderson wrote:
On Fri, May 2, 2014 at 7:00 PM, Tomasz Figa tomasz.f...@gmail.com 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.
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 ajaykumar...@samsung.com
---
drivers/gpu/drm/bridge/ptn3460.c | 21 +
1 file changed, 17 insertions(+), 4
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
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
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 ajaykumar...@samsung.com
---
.../bindings/drm/bridge/bridge_panel.txt | 45
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:
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 arun...@samsung.com wrote:
Adds the PWM nodes to 5420 pinctrl dtsi file.
Signed-off-by: Arun Kumar K arun...@samsung.com
---
Doug Anderson wrote:
Arun,
On Mon, May 5, 2014 at 2:25 AM, Arun Kumar K arun...@samsung.com wrote:
Adds the google peach-pit board dts file which uses
exynos5420 SoC.
Signed-off-by: Arun Kumar K arun...@samsung.com
Signed-off-by: Doug Anderson diand...@chromium.org
---
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 a.ha...@samsung.com
Acked-by: Kyungmin Park
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
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.
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 uart type
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't this
Heiko Stübner wrote:
This finally removes all remaining SAMSUNG_CLOCK conditional code
from s3c24xx architectures.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
This is of course meant to go on top of the s3c2410 ccf conversion
arch/arm/mach-s3c24xx/Kconfig | 5 -
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 maintainership at
84 matches
Mail list logo
