On Mon, Sep 22, 2014 at 05:23:25PM +0300, Tomi Valkeinen wrote:
On 22/09/14 11:06, Thierry Reding wrote:
Why do we need a complex graph when it can be handled using a simple
phandle?
Maybe in your case you can handle it with simple phandle. Can you
guarantee that it's enough for
On Tue, Sep 23, 2014 at 11:25 AM, Thierry Reding
thierry.red...@gmail.com wrote:
On Tue, Sep 23, 2014 at 03:00:37AM +0300, Laurent Pinchart wrote:
On Monday 22 September 2014 13:35:15 Thierry Reding wrote:
On Mon, Sep 22, 2014 at 04:53:22PM +0530, Ajay kumar wrote:
On Mon, Sep 22, 2014 at
Kukjin Kim wrote:
Andreas Färber wrote:
[...]
Kukjin: Andreas's patch series was Reviewed long ago I think and by
now I'd imagine it's got some conflicts due to it not having been
applied in a timely fashion. Perhaps you could fix it up for Andreas
(since he's already rebased it
On Mon, Sep 22, 2014 at 05:04:54PM +0300, Tomi Valkeinen wrote:
On 22/09/14 10:54, Thierry Reding wrote:
I wish all new display component bindings would use the video
ports/endpoints to describe the connections. It will be very difficult
to improve the display driver model later if we're
On Tue, Sep 23, 2014 at 11:41:33AM +0530, Ajay kumar wrote:
On Tue, Sep 23, 2014 at 11:25 AM, Thierry Reding
thierry.red...@gmail.com wrote:
On Tue, Sep 23, 2014 at 03:00:37AM +0300, Laurent Pinchart wrote:
On Monday 22 September 2014 13:35:15 Thierry Reding wrote:
On Mon, Sep 22, 2014 at
Hi Arnd,
I will be taking this forward as Naveen is no longer with Samsung.
On Wed, Sep 3, 2014 at 4:26 PM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 03 September 2014 13:51:56 Naveen Krishna Ch wrote:
On 2 September 2014 21:16, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 02
Hi Tomasz,
On Mon, Sep 22, 2014 at 1:25 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
On 22.09.2014 08:17, Abhilash Kesavan wrote:
Hi Tomasz,
On Sat, Sep 13, 2014 at 4:57 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Abhilash,
Please see my comments inline.
On 13.09.2014 10:50, Abhilash
Hi Thierry, Tomi,
On 09/23/2014 08:04 AM, Thierry Reding wrote:
On Mon, Sep 22, 2014 at 05:23:25PM +0300, Tomi Valkeinen wrote:
On 22/09/14 11:06, Thierry Reding wrote:
Why do we need a complex graph when it can be handled using a simple
phandle?
Maybe in your case you can handle it with
Hi,
-Original Message-
From: linux-arm-kernel [mailto:linux-arm-kernel-
boun...@lists.infradead.org] On Behalf Of Abhilash Kesavan
Sent: Monday, September 22, 2014 1:47 PM
To: linux-samsung-soc@vger.kernel.org; linux-arm-
ker...@lists.infradead.org; devicet...@vger.kernel.org;
Hi,
-Original Message-
From: linux-arm-kernel [mailto:linux-arm-kernel-
boun...@lists.infradead.org] On Behalf Of Abhilash Kesavan
Sent: Monday, September 22, 2014 1:47 PM
To: linux-samsung-soc@vger.kernel.org; linux-arm-
ker...@lists.infradead.org; devicet...@vger.kernel.org;
On Tuesday 23 September 2014 12:34:26 Abhilash Kesavan wrote:
The SERIAL_SAMSUNG_UARTS_4 and SERIAL_SAMSUNG_UARTS config options are
meaningful only if SERIAL_SAMSUNG is enabled. Hence the dependency
rules were changed. I will repost this patch with better description.
My point is that
From: Naveen Krishna Ch naveenkrishna...@gmail.com
Enable pinctrl support for exynos7 SoCs.
Signed-off-by: Naveen Krishna Ch naveenkrishna...@gmail.com
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Reviewed-by: Thomas Abraham thomas...@samsung.com
Tested-by: Thomas Abraham
From: Naveen Krishna Ch naveenkrishna...@gmail.com
Add intial pin configuration nodes for EXYNOS7.
Signed-off-by: Naveen Krishna Ch naveenkrishna...@gmail.com
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Reviewed-by: Thomas Abraham thomas...@samsung.com
Tested-by: Thomas Abraham
From: Naveen Krishna Ch naveenkrishna...@gmail.com
This patch adds initial driver data for Exynos7 pinctrl support.
Signed-off-by: Naveen Krishna Ch naveenkrishna...@gmail.com
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Reviewed-by: Thomas Abraham thomas...@samsung.com
Tested-by:
The function exynos_irq_demux_eint16_31 uses pre-defined offsets for external
interrupt pending status and mask registers. So this function is not extensible
for Exynos7 SoC which have these registers at different offsets. So generalize
the exynos_irq_demux_eint16_31 function by using the
Changes since v1:
- Marked the newly created irq_chip instances as __initdata
- Used kmemdup to keep a copy of the irq_chip
- Change the pinctrl name from sd0_rdqs to sd0_ds as per UM
- Moved the pinctrl enablement for exynos7 into a separate patch
- Added
Exynos7 uses different offsets for wakeup interrupt configuration registers.
So a new irq_chip instance for Exynos7 wakeup interrupts is added. The irq_chip
selection is now based on the wakeup interrupt controller compatible string.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
On Tue, Sep 23, 2014 at 09:24:12AM +0200, Andrzej Hajda wrote:
Hi Thierry, Tomi,
On 09/23/2014 08:04 AM, Thierry Reding wrote:
On Mon, Sep 22, 2014 at 05:23:25PM +0300, Tomi Valkeinen wrote:
On 22/09/14 11:06, Thierry Reding wrote:
Why do we need a complex graph when it can be handled
On 23/09/14 08:53, Thierry Reding wrote:
Yes, it's true we need a mux there. But we still have the complication
that for panel0 we may need different ps8622 settings than for panel1.
Yes, and that's why the bridge should be querying the panel for the
information it needs to determine the
Hi Chanho,
On Tue, Sep 23, 2014 at 1:20 PM, Chanho Park chanho61.p...@samsung.com wrote:
Hi,
-Original Message-
From: linux-arm-kernel [mailto:linux-arm-kernel-
boun...@lists.infradead.org] On Behalf Of Abhilash Kesavan
Sent: Monday, September 22, 2014 1:47 PM
To:
Hi Chanho,
On Tue, Sep 23, 2014 at 1:16 PM, Chanho Park chanho61.p...@samsung.com wrote:
Hi,
-Original Message-
From: linux-arm-kernel [mailto:linux-arm-kernel-
boun...@lists.infradead.org] On Behalf Of Abhilash Kesavan
Sent: Monday, September 22, 2014 1:47 PM
To:
On 23/09/14 09:04, Thierry Reding wrote:
I certainly agree that it's useful to have standard ways to describe at
least various aspects. For example I think it would be useful to add
standard properties for a bridge's connections, such as bridge or
panel to allow bridge chaining and attaching
On Tue, Sep 23, 2014 at 11:41:52AM +0300, Tomi Valkeinen wrote:
On 23/09/14 08:53, Thierry Reding wrote:
Yes, it's true we need a mux there. But we still have the complication
that for panel0 we may need different ps8622 settings than for panel1.
Yes, and that's why the bridge should
On 23/09/14 09:21, Thierry Reding wrote:
Well, I can write almost any kind of bindings, and then evidently my
device would work. For me, on my board.
Well, that's the whole problem with DT. For many devices we only have a
single setup to test against. And even when we have several they
On Tue, Sep 23, 2014 at 11:54:27AM +0300, Tomi Valkeinen wrote:
On 23/09/14 09:04, Thierry Reding wrote:
I certainly agree that it's useful to have standard ways to describe at
least various aspects. For example I think it would be useful to add
standard properties for a bridge's
On 23/09/14 11:35, Thierry Reding wrote:
Well, a display controller is never going to attach to a panel directly.
With parallel RGB, that (almost) happens. There's voltage level shifting
probably in the middle, but I don't see anything else there.
But I agree that it would be nice to unify
On 09/23/2014 10:35 AM, Thierry Reding wrote:
On Tue, Sep 23, 2014 at 09:24:12AM +0200, Andrzej Hajda wrote:
Hi Thierry, Tomi,
On 09/23/2014 08:04 AM, Thierry Reding wrote:
On Mon, Sep 22, 2014 at 05:23:25PM +0300, Tomi Valkeinen wrote:
On 22/09/14 11:06, Thierry Reding wrote:
Why do we
On Tue, Sep 23, 2014 at 12:30:20PM +0300, Tomi Valkeinen wrote:
On 23/09/14 09:21, Thierry Reding wrote:
Well, I can write almost any kind of bindings, and then evidently my
device would work. For me, on my board.
Well, that's the whole problem with DT. For many devices we only have a
On Tue, Sep 23, 2014 at 12:40:24PM +0300, Tomi Valkeinen wrote:
On 23/09/14 11:35, Thierry Reding wrote:
Well, a display controller is never going to attach to a panel directly.
With parallel RGB, that (almost) happens. There's voltage level shifting
probably in the middle, but I don't
On 09/23/2014 11:30 AM, Tomi Valkeinen wrote:
On 23/09/14 09:21, Thierry Reding wrote:
Well, I can write almost any kind of bindings, and then evidently my
device would work. For me, on my board.
Well, that's the whole problem with DT. For many devices we only have a
single setup to test
On 09/23/2014 11:30 AM, Tomi Valkeinen wrote:
On 23/09/14 09:21, Thierry Reding wrote:
Well, I can write almost any kind of bindings, and then evidently my
device would work. For me, on my board.
Well, that's the whole problem with DT. For many devices we only have a
single setup to test
On Tue, Sep 23, 2014 at 11:43:47AM +0200, Andrzej Hajda wrote:
On 09/23/2014 10:35 AM, Thierry Reding wrote:
[...]
But I agree that it would be nice to unify bridges and encoders more. It
should be possible to make encoder always a bridge (or perhaps even
replace encoders with bridges
Hi Dong,
On Monday, September 22, 2014, Dong Aisheng wrote,
On Mon, Sep 22, 2014 at 10:10:07AM +0530, Pankaj Dubey wrote:
[snip]
-static int syscon_match_node(struct device *dev, void *data)
+static struct syscon *of_syscon_register(struct device_node *np)
{
- struct device_node *dn
On 09/23/2014 12:10 PM, Thierry Reding wrote:
On Tue, Sep 23, 2014 at 11:43:47AM +0200, Andrzej Hajda wrote:
On 09/23/2014 10:35 AM, Thierry Reding wrote:
[...]
But I agree that it would be nice to unify bridges and encoders more. It
should be possible to make encoder always a bridge (or
On Tuesday 23 September 2014 12:02:45 Andrzej Hajda wrote:
On 09/23/2014 11:30 AM, Tomi Valkeinen wrote:
On 23/09/14 09:21, Thierry Reding wrote:
Well, I can write almost any kind of bindings, and then evidently my
device would work. For me, on my board.
Well, that's the whole problem
On Tuesday 23 September 2014 11:53:15 Thierry Reding wrote:
On Tue, Sep 23, 2014 at 12:30:20PM +0300, Tomi Valkeinen wrote:
On 23/09/14 09:21, Thierry Reding wrote:
Well, I can write almost any kind of bindings, and then evidently my
device would work. For me, on my board.
Well,
On 23/09/14 12:28, Thierry Reding wrote:
But, for example, let's say that the board is designed in a way that for
panel0 the bridge needs to output a bit higher level voltages than for
panel1. That's not a property of the panel, so it can't be queried from
the panel.
That feature (varying
On 09/23/2014 01:10 PM, Laurent Pinchart wrote:
On Tuesday 23 September 2014 12:02:45 Andrzej Hajda wrote:
On 09/23/2014 11:30 AM, Tomi Valkeinen wrote:
On 23/09/14 09:21, Thierry Reding wrote:
Well, I can write almost any kind of bindings, and then evidently my
device would work. For me, on
On Tuesday 23 September 2014 13:18:30 Andrzej Hajda wrote:
On 09/23/2014 01:10 PM, Laurent Pinchart wrote:
On Tuesday 23 September 2014 12:02:45 Andrzej Hajda wrote:
On 09/23/2014 11:30 AM, Tomi Valkeinen wrote:
On 23/09/14 09:21, Thierry Reding wrote:
Well, I can write almost any kind of
On 23/09/14 12:39, Thierry Reding wrote:
My point is that if you use plain phandles you usually have the
meta-data already. Referring to the above example, bridge0 knows that it
should look for a bridge with phandle bridge1, whereas bridge1 knows
that the device it is connected to is a panel.
Hi Thierry,
On Tuesday 23 September 2014 12:10:33 Thierry Reding wrote:
On Tue, Sep 23, 2014 at 11:43:47AM +0200, Andrzej Hajda wrote:
On 09/23/2014 10:35 AM, Thierry Reding wrote:
[...]
But I agree that it would be nice to unify bridges and encoders more. It
should be possible to
Hi Thierry,
On Tuesday 23 September 2014 07:55:34 Thierry Reding wrote:
On Tue, Sep 23, 2014 at 03:00:37AM +0300, Laurent Pinchart wrote:
On Monday 22 September 2014 13:35:15 Thierry Reding wrote:
On Mon, Sep 22, 2014 at 04:53:22PM +0530, Ajay kumar wrote:
On Mon, Sep 22, 2014 at 4:11 PM,
On 09/23/2014 01:23 PM, Laurent Pinchart wrote:
On Tuesday 23 September 2014 13:18:30 Andrzej Hajda wrote:
On 09/23/2014 01:10 PM, Laurent Pinchart wrote:
On Tuesday 23 September 2014 12:02:45 Andrzej Hajda wrote:
On 09/23/2014 11:30 AM, Tomi Valkeinen wrote:
On 23/09/14 09:21, Thierry Reding
On Tuesday 23 September 2014 13:47:40 Andrzej Hajda wrote:
On 09/23/2014 01:23 PM, Laurent Pinchart wrote:
On Tuesday 23 September 2014 13:18:30 Andrzej Hajda wrote:
On 09/23/2014 01:10 PM, Laurent Pinchart wrote:
On Tuesday 23 September 2014 12:02:45 Andrzej Hajda wrote:
On 09/23/2014
On 23/09/14 12:53, Thierry Reding wrote:
Yes, but in this case we know of existing boards that have complex
setups. It's not theoretical.
Complex setups involving /this particular/ bridge and binding are
theoretical at this point, however.
Right, but this discussion, at least from my part,
On 23/09/14 13:01, Thierry Reding wrote:
On Tue, Sep 23, 2014 at 12:40:24PM +0300, Tomi Valkeinen wrote:
On 23/09/14 11:35, Thierry Reding wrote:
Well, a display controller is never going to attach to a panel directly.
With parallel RGB, that (almost) happens. There's voltage level shifting
On 09/23/2014 01:52 PM, Laurent Pinchart wrote:
On Tuesday 23 September 2014 13:47:40 Andrzej Hajda wrote:
On 09/23/2014 01:23 PM, Laurent Pinchart wrote:
On Tuesday 23 September 2014 13:18:30 Andrzej Hajda wrote:
On 09/23/2014 01:10 PM, Laurent Pinchart wrote:
On Tuesday 23 September 2014
On 09/23/2014 01:52 PM, Laurent Pinchart wrote:
On Tuesday 23 September 2014 13:47:40 Andrzej Hajda wrote:
On 09/23/2014 01:23 PM, Laurent Pinchart wrote:
On Tuesday 23 September 2014 13:18:30 Andrzej Hajda wrote:
On 09/23/2014 01:10 PM, Laurent Pinchart wrote:
On Tuesday 23 September 2014
Hi Marek,
On Mon, Sep 22, 2014 at 6:44 PM, Marek Szyprowski
m.szyprow...@samsung.com wrote:
Hello,
This patchset adds support for early console defined in device tree. As
an example, DTS files for all Exynos4 based machines are updated with
the correct value for common chosen/sdtout
Hello,
On 2014-09-23 14:53, Alim Akhtar wrote:
Hi Marek,
On Mon, Sep 22, 2014 at 6:44 PM, Marek Szyprowski
m.szyprow...@samsung.com wrote:
Hello,
This patchset adds support for early console defined in device tree. As
an example, DTS files for all Exynos4 based machines are updated with
the
Hi Marek,
On Tue, Sep 23, 2014 at 6:38 PM, Marek Szyprowski
m.szyprow...@samsung.com wrote:
Hello,
On 2014-09-23 14:53, Alim Akhtar wrote:
Hi Marek,
On Mon, Sep 22, 2014 at 6:44 PM, Marek Szyprowski
m.szyprow...@samsung.com wrote:
Hello,
This patchset adds support for early console
On 23.09.2014 14:53, Alim Akhtar wrote:
Hi Marek,
On Mon, Sep 22, 2014 at 6:44 PM, Marek Szyprowski
m.szyprow...@samsung.com wrote:
Hello,
This patchset adds support for early console defined in device tree. As
an example, DTS files for all Exynos4 based machines are updated with
the
Hi Sjoerd,
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Sjoerd Simons
Sent: Monday, September 22, 2014 2:52 PM
To: Kyungmin Park; Kamil Debski; Arun Kumar K
Cc: Mauro Carvalho Chehab; linux-arm-ker...@lists.infradead.org; linux-
Hey Kamil,
On Tue, 2014-09-23 at 15:58 +0200, Kamil Debski wrote:
Commit 90c0ae50097 changed how the frame_type of a decoded frame
gets determined, by switching from the get_dec_frame_type to
get_disp_frame_type operation. Unfortunately it seems that on MFC v5
the
result of
On Tue, Sep 23, 2014 at 02:15:54PM +0300, Tomi Valkeinen wrote:
On 23/09/14 12:28, Thierry Reding wrote:
But, for example, let's say that the board is designed in a way that for
panel0 the bridge needs to output a bit higher level voltages than for
panel1. That's not a property of the
On Tue, Sep 23, 2014 at 03:09:44PM +0300, Tomi Valkeinen wrote:
On 23/09/14 13:01, Thierry Reding wrote:
On Tue, Sep 23, 2014 at 12:40:24PM +0300, Tomi Valkeinen wrote:
[...]
What exactly is a bridge and what is an encoder? Those are DRM
constructs, aren't they?
Yes. I think bridges
On Tue, Sep 23, 2014 at 12:34:54PM +0200, Andrzej Hajda wrote:
On 09/23/2014 12:10 PM, Thierry Reding wrote:
On Tue, Sep 23, 2014 at 11:43:47AM +0200, Andrzej Hajda wrote:
On 09/23/2014 10:35 AM, Thierry Reding wrote:
[...]
But I agree that it would be nice to unify bridges and encoders
On Tue, Sep 23, 2014 at 02:31:35PM +0300, Tomi Valkeinen wrote:
On 23/09/14 12:39, Thierry Reding wrote:
My point is that if you use plain phandles you usually have the
meta-data already. Referring to the above example, bridge0 knows that it
should look for a bridge with phandle bridge1,
On Tue, Sep 23, 2014 at 02:12:52PM +0300, Laurent Pinchart wrote:
On Tuesday 23 September 2014 11:53:15 Thierry Reding wrote:
On Tue, Sep 23, 2014 at 12:30:20PM +0300, Tomi Valkeinen wrote:
On 23/09/14 09:21, Thierry Reding wrote:
Well, I can write almost any kind of bindings, and then
On Tue, Sep 23, 2014 at 02:52:24PM +0300, Laurent Pinchart wrote:
On Tuesday 23 September 2014 13:47:40 Andrzej Hajda wrote:
On 09/23/2014 01:23 PM, Laurent Pinchart wrote:
[...]
This becomes an issue even on Linux when considering video-related devices
that can be part of either a
On 23.09.2014 10:16, Abhilash Kesavan wrote:
[snip]
@@ -383,9 +377,11 @@ static int exynos_wkup_irq_set_wake(struct irq_data
*irqd, unsigned int on)
/*
* irq_chip for wakeup interrupts
*/
-static struct exynos_irq_chip exynos_wkup_irq_chip = {
+static struct exynos_irq_chip
On Tue, Sep 9, 2014 at 12:26 PM, Masahiro Yamada
yamad...@jp.panasonic.com wrote:
Clearing obj-y, obj-m, obj-n, obj- in each Makefile is
a useless habit.
They are non-exported variables; therefore they are always empty
whenever descending into each subdirectory.
(Moreorver, obj-y and obj-m
On Tue, Sep 23, 2014 at 03:00:31PM +0300, Tomi Valkeinen wrote:
On 23/09/14 12:53, Thierry Reding wrote:
Yes, but in this case we know of existing boards that have complex
setups. It's not theoretical.
Complex setups involving /this particular/ bridge and binding are
theoretical at
On Tue, Sep 23, 2014 at 10:16 AM, Abhilash Kesavan
a.kesa...@samsung.com wrote:
The function exynos_irq_demux_eint16_31 uses pre-defined offsets for external
interrupt pending status and mask registers. So this function is not
extensible
for Exynos7 SoC which have these registers at
On 23/09/14 17:29, Thierry Reding wrote:
Trying to do this within the bridge's node directly has two flaws:
1) It violates the DT principle of describing hardware. The
device itself does not know anything about multiple streams
and deals only with a single input and output.
On 23/09/14 17:38, Thierry Reding wrote:
On Tue, Sep 23, 2014 at 03:09:44PM +0300, Tomi Valkeinen wrote:
On 23/09/14 13:01, Thierry Reding wrote:
On Tue, Sep 23, 2014 at 12:40:24PM +0300, Tomi Valkeinen wrote:
[...]
What exactly is a bridge and what is an encoder? Those are DRM
constructs,
On 09/23/14 15:17, Kukjin Kim wrote:
Kukjin Kim wrote:
Andreas Färber wrote:
[...]
Kukjin: Andreas's patch series was Reviewed long ago I think and by
now I'd imagine it's got some conflicts due to it not having been
applied in a timely fashion. Perhaps you could fix it up for Andreas
On 09/19/14 16:43, Sjoerd Simons wrote:
Hey Kukjin,
Hi,
Sorry for late response...
It's been almost a month since I posted the first iteration of this
patchset on the list, with only trivial cosmetic changes and an addition
of a similar fix for Arndale Octa boards. Do you feel it needs more
Hello Kukjin,
On 09/23/2014 06:00 PM, Kukjin Kim wrote:
On 09/23/14 15:17, Kukjin Kim wrote:
I've applied above and this series and please double-check the commits
in my tree. If no problems, I will send the branch out for v3.18 soon...
Thanks,
Kukjin
I've looked the RTC source clock
On 09/16/14 00:06, Krzysztof Kozlowski wrote:
The MAX77693 is a companion power management IC for smart phones and tablets.
The MAX77693 contains input over-voltage protection (OVP),
a fully-integrated 2.5A switching charger for Lithium Ion battery with
integrated battery disconnect,
On 08/26/14 23:10, Tomasz Figa wrote:
This patch extends the firmware_ops structure with two new callbacks:
.suspend() and .resume(). The former is intended to ask the firmware to
save all its volatile state and suspend the system, without returning
back to the kernel in between. The latter is
On 09/15/14 20:44, Jacek Anaszewski wrote:
Signed-off-by: Jacek Anaszewskij.anaszew...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
Cc: Kukjin Kimkgene@samsung.com
---
arch/arm/boot/dts/exynos3250.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git
On 08/13/14 00:11, Bartlomiej Zolnierkiewicz wrote:
Ifdef around cpu_\name\()_do_suspend and cpu_\name\()_do_resume
ops in proc-macros.S should check for CONFIG_ARM_CPU_SUSPEND and
not CONFIG_PM_SLEEP. Fix it.
[ Please note that cpu_v7_do_[suspend,resume] code in proc-v7.S
already correctly
On 22 September 2014 06:40, Pankaj Dubey pankaj.du...@samsung.com wrote:
Currently a syscon entity can be only registered directly through a
platform device that binds to a dedicated syscon driver. However in
certain use cases it is desirable to make a device used with another
driver a syscon
There is no code using it and in fact there are pin controller variants
that do not even have this field initialized in their init data. This
patch removes it completely.
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
drivers/pinctrl/samsung/pinctrl-exynos.c | 22 --
This structure is not intended to be modified at runtime and functions
as constant data shared between multiple pin banks. This patch makes all
instances of it constant across the driver.
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
drivers/pinctrl/samsung/pinctrl-exynos.c | 8
This series intends to clean up data structures used by pinctrl-samsung driver.
More specifically, it separates initial compile time constants from data used
at runtime, allowing unused variant data to be dropped and selected structures
constified to improve safety.
As a side effect, size of
Currently the function returns a valid pointer on success and NULL on
error, so exact error code is lost. This patch changes return convention
of the function to use ERR_PTR() on error instead.
Signed-off-by: Tomasz Figa tomasz.f...@gmail.com
---
drivers/pinctrl/samsung/pinctrl-samsung.c | 6
In order to separate initialization constants from runtime data, this
patch modifies the driver to store only constant data in
samsung_pin_ctrl struct and copy data required at runtime to
samsung_pinctrl_drv_data struct. This makes it possible to mark all
existing instances of samsung_pin_ctrl
Currently the driver mixes constant init data with runtime data, which
is far from being elegant and can invite potential hard to track issues.
This patch intends to solve this by introducing a new
samsung_pin_bank_data structure to hold only constant data known at
compile time, which can be
This patch resolves a issue that screen is shaked after resumed.
The issue could be incurred when overlay registers are updated to
new buffer while fimd is still transmitting video data.
So this patch make sure to wait for the completion of the transmission
if fimd is transmitting video data
The CPU clock provider supplies the clock to the CPU clock domain. The
composition and organization of the CPU clock provider could vary among
Exynos SoCs. A CPU clock provider can be composed of clock mux, dividers
and gates. This patch defines a new clock type for CPU clock provider and
adds
For Exynos 4210/5250/5420 based platforms, add CPU operating points and CPU
regulator supply properties for migrating from Exynos specific cpufreq driver
to using generic cpufreq drivers.
Cc: Kukjin Kim kgene@samsung.com
Cc: Doug Anderson diand...@chromium.org
Cc: Javier Martinez Canillas
With some of the Exynos SoCs switched over to use the generic CPUfreq drivers,
the unused clock aliases can be removed. In addition to this, the individual
clock blocks which are now encapsulated with the consolidate CPU clock type
can now be marked with read-only flags.
Cc: Tomasz Figa
Exynos4210 and Exynos5250 based platforms have switched over to use generic
cpufreq drivers for cpufreq functionality. So the Exynos specific cpufreq
drivers for these platforms can be removed.
Cc: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Signed-off-by: Thomas Abraham
This patch series removes the use of Exynos4210 and Exynos5250 specific cpufreq
drivers and enables the use of cpufreq-cpu0 driver for these platforms. This
series also enables cpufreq support for Exynos5420 using arm_big_little cpufreq
driver.
This patch series is dependent on two other patches
With the addition of the new Samsung specific cpu-clock type, the
arm clock can be represented as a cpu-clock type. Add the CPU clock
configuration data and instantiate the CPU clock type for Exynos4210,
Exynos5250 and Exynos5420.
Cc: Tomasz Figa tomasz.f...@gmail.com
Signed-off-by: Thomas
The new CPU clock type allows the use of generic CPUfreq drivers. So for
Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420,
which did not have CPUfreq driver support, enable the use of generic
CPUfreq driver.
Suggested-by: Tomasz Figa tomasz.f...@gmail.com
Cc: Kukjin Kim
Bartlomiej Zolnierkiewicz wrote:
Hi,
Hi,
On Tuesday, August 19, 2014 01:26:49 PM Vikas Sajjan wrote:
Hi Kukjin,
On Tue, Aug 19, 2014 at 12:22 PM, Vikas Sajjan vikas.saj...@samsung.com
wrote:
Refactoring the pm.c to avoid using soc_is_exynos checks,
instead use the DT based
89 matches
Mail list logo
