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
> > wrote:
> > > Refactoring the pm.c to avoid using "soc_is_exynos" checks,
> > > instead use the DT based lookup.
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
Signed-off-by: Thomas Abraham
Acked-by: Mike Turq
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
Cc: Kukjin Kim
Signed-off-by: Thomas Ab
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
Cc: Doug Anderson
Cc: Javier Martinez Canillas
Cc: Andreas Faerber
Cc: Sachin Kamat
Signed
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
Signed-of
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
Signed-off-by: Thomas Abraham
Acked-by: Viresh Kumar
Tested-by: Javier
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
1
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 infr
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 befo
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 copied
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 stru
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
---
drivers/pinctrl/samsung/pinctrl-samsung.c | 6 +++---
1 file changed, 3
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 vmlin
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
---
drivers/pinctrl/samsung/pinctrl-exynos.c | 8
drivers/pinctrl/sams
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
---
drivers/pinctrl/samsung/pinctrl-exynos.c | 22 --
drivers/pinctrl/samsung
On 22 September 2014 06:40, Pankaj Dubey 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 interface provider.
>
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 09/15/14 20:44, Jacek Anaszewski wrote:
Signed-off-by: Jacek Anaszewski
Signed-off-by: Kyungmin Park
Cc: Kukjin Kim
---
arch/arm/boot/dts/exynos3250.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
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 to
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, OTG/accesso
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 sourc
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
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
(si
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
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 inp
On Tue, Sep 23, 2014 at 10:16 AM, Abhilash Kesavan
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 different offsets. So gene
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
> > the
On Tue, Sep 9, 2014 at 12:26 PM, Masahiro Yamada
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 are also set to empt
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 *exy
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,
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
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 &b
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
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 thin
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
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 ge
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-
> me...
On 23.09.2014 14:53, Alim Akhtar wrote:
> Hi Marek,
>
> On Mon, Sep 22, 2014 at 6:44 PM, Marek Szyprowski
> 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
Hi Marek,
On Tue, Sep 23, 2014 at 6:38 PM, Marek Szyprowski
wrote:
> Hello,
>
> On 2014-09-23 14:53, Alim Akhtar wrote:
>>
>> Hi Marek,
>>
>> On Mon, Sep 22, 2014 at 6:44 PM, Marek Szyprowski
>> wrote:
>>>
>>> Hello,
>>>
>>> This patchset adds support for early console defined in device tree. As
Hello,
On 2014-09-23 14:53, Alim Akhtar wrote:
Hi Marek,
On Mon, Sep 22, 2014 at 6:44 PM, Marek Szyprowski
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
Hi Marek,
On Mon, Sep 22, 2014 at 6:44 PM, Marek Szyprowski
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 property.
>
> To get it full
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 Sep
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 Sep
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 leve
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
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
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
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,
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 possi
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 pa
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 alm
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 wo
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
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.
> > >
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 th
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
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_
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
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 se
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 se
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 do
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 o
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:
>
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 b
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 c
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 the
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 brid
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 att
Hi Chanho,
On Tue, Sep 23, 2014 at 1:16 PM, Chanho Park 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: linux-samsung-soc@vger.kernel.o
Hi Chanho,
On Tue, Sep 23, 2014 at 1:20 PM, Chanho Park 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: linux-samsung-soc@vger.kernel.o
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
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
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 te
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
Reviewed-by: Thomas Abraham
Te
From: Naveen Krishna Ch
Add intial pin configuration nodes for EXYNOS7.
Signed-off-by: Naveen Krishna Ch
Signed-off-by: Abhilash Kesavan
Reviewed-by: Thomas Abraham
Tested-by: Thomas Abraham
Cc: Rob Herring
Cc: Catalin Marinas
Cc: Tomasz Figa
Cc: Linus Walleij
Cc: Thomas Abraham
---
ar
From: Naveen Krishna Ch
Enable pinctrl support for exynos7 SoCs.
Signed-off-by: Naveen Krishna Ch
Signed-off-by: Abhilash Kesavan
Reviewed-by: Thomas Abraham
Tested-by: Thomas Abraham
Cc: Rob Herring
Cc: Catalin Marinas
Cc: Tomasz Figa
Cc: Linus Walleij
Cc: Thomas Abraham
---
arch/arm6
From: Naveen Krishna Ch
This patch adds initial driver data for Exynos7 pinctrl support.
Signed-off-by: Naveen Krishna Ch
Signed-off-by: Abhilash Kesavan
Reviewed-by: Thomas Abraham
Tested-by: Thomas Abraham
Cc: Thomas Abraham
Cc: Tomasz Figa
Cc: Linus Walleij
---
.../bindings/pinctrl/sa
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 pending/m
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.
> >
> > M
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;
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 y
Hi Tomasz,
On Mon, Sep 22, 2014 at 1:25 PM, Tomasz Figa wrote:
> On 22.09.2014 08:17, Abhilash Kesavan wrote:
>> Hi Tomasz,
>>
>> On Sat, Sep 13, 2014 at 4:57 PM, Tomasz Figa wrote:
>>> Hi Abhilash,
>>>
>>> Please see my comments inline.
>>>
>>> On 13.09.2014 10:50, Abhilash Kesavan wrote:
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 wrote:
> On Wednesday 03 September 2014 13:51:56 Naveen Krishna Ch wrote:
>> On 2 September 2014 21:16, Arnd Bergmann wrote:
>> > On Tuesday 02 September 2014 20:52:00 Navee
84 matches
Mail list logo