Hi,
On 08.05.2014 14:49, Tomasz Figa wrote:
> Up till now there was no single generic method to bind devices to their
> power domains using Device Tree. Each platform has been doing this using
> its own way, example of which are Exynos power domain bindings [1] and
> look-up code [2].
>
> This se
On 16.05.2014 07:07, Abhilash Kesavan wrote:
> Hi Tomasz,
>
> On Fri, May 16, 2014 at 2:52 AM, Tomasz Figa wrote:
>> Hi Abhilash,
>>
>> On 13.05.2014 14:01, Abhilash Kesavan wrote:
>>> Rebased on
>>> 1] Kukjin Kim's tree for-next branch (which has Sachin Kamat's SYSRAM
>>> patches merged) with To
On Tue, May 13, 2014 at 4:09 AM, Seungwon Jeon wrote:
> On Tuesday, May 13, Sonny Rao wrote:
>> On Mon, May 12, 2014 at 10:02 PM, Seungwon Jeon wrote:
>> > As I mentioned in previous version, you put all reset stuff in existing
>> > fifo_reset function.
>> > Although databook mentions ciu_reset
On 16.05.2014 07:07, Abhilash Kesavan wrote:
> Hi Tomasz,
>
> On Fri, May 16, 2014 at 2:41 AM, Tomasz Figa wrote:
>> Hi Abhilash,
>>
>> On 13.05.2014 12:12, Abhilash Kesavan wrote:
>>> On Tue, May 13, 2014 at 7:54 AM, Kukjin Kim wrote:
>>
>> [snip]
>>
> diff --git a/arch/arm/mach-exynos/re
Hi Thomas,
In general the design already looks good, but I commented on several
implementation issues I found in particular patches (and some minor
nitpicks while at it).
Please let me know whether you have time to work on addressing them.
Otherwise we can just let me, Lukasz or someone else addr
On 05/16/14 21:28, Kukjin Kim wrote:
Ajay Kumar wrote:
Adds the PWM nodes to 5250 pinctrl dtsi file.
Signed-off-by: Ajay Kumar
---
arch/arm/boot/dts/exynos5250-pinctrl.dtsi | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-pinct
On 14.05.2014 03:11, Thomas Abraham wrote:
> From: Thomas Abraham
>
> Remove the platform device instantiation for Exynos specific cpufreq
> driver and add the platform device for cpufreq-cpu0 driver.
>
> Signed-off-by: Thomas Abraham
> ---
> arch/arm/mach-exynos/exynos.c |4 +++-
> 1 fi
On 05/17/14 07:56, Chirantan Ekbote wrote:
Anyway, I'm by no means opposed to switching to arch timers. They
provide a well designed, generic interface and drivers shared by
multiple platforms, which means more code sharing and possibly more eyes
looking at the code, which is always good. However
On 17.05.2014 01:24, Tomasz Figa wrote:
> Also, shouldn't you also extend exynos5420-clock.txt in the same way?
Please ignore this comment. Somehow I thought other patches of this
series also had support for Exynos5420.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubsc
On 05/16/14 06:11, Kukjin Kim wrote:
[...]
OK, I think I misread the original email. I thought you were asking for
future pull requests to go through the samsung tree, but you only mean
the ones in this thread. No problem there.
Acked-by: Mike Turquette
Mike, thanks for your ack on this who
Hi Thomas,
On 14.05.2014 03:11, Thomas Abraham wrote:
> From: Thomas Abraham
>
> With the addition of the new Samsung specific cpu-clock type, the
> arm clock can be represented as a cpu-clock type and the independent
> clock blocks that made up the arm clock can be removed.
>
> Cc: Tomasz Figa
On 05/16/14 01:52, Nicolas Pitre wrote:
On Thu, 15 May 2014, Abhilash Kesavan wrote:
Hi Nicolas,
Hi all,
[...]
Good, that looks pretty good.
Thanks for you guys effort and time.
Applied this whole series.
Once you implement full cluster shutdown I can provide you with another
script s
On 05/17/14 08:37, Tomasz Figa wrote:
On 17.05.2014 01:26, Kukjin Kim wrote:
On 05/16/14 20:07, Viresh Kumar wrote:
On 16 May 2014 15:48, Jonghwan Choi wrote:
Commit 7da83a80 ("ARM: EXYNOS: Migrate Exynos specific macros from
plat to mach") which lands in samsung tree causes build breakage
f
On 17.05.2014 01:26, Kukjin Kim wrote:
> On 05/16/14 20:07, Viresh Kumar wrote:
>> On 16 May 2014 15:48, Jonghwan Choi wrote:
>>> Commit 7da83a80 ("ARM: EXYNOS: Migrate Exynos specific macros from
>>> plat to mach") which lands in samsung tree causes build breakage
>>> for cpufreq-exynos like foll
Hi Kukjin,
On 17.05.2014 01:24, Kukjin Kim wrote:
> On 05/17/14 08:04, Rafael J. Wysocki wrote:
>> On Friday, May 16, 2014 07:54:01 PM Kukjin Kim wrote:
>>> Jonghwan Choi wrote:
Commit 7da83a80 ("ARM: EXYNOS: Migrate Exynos specific macros from
plat to
mach") which lands in sam
On 05/16/14 20:07, Viresh Kumar wrote:
On 16 May 2014 15:48, Jonghwan Choi wrote:
Commit 7da83a80 ("ARM: EXYNOS: Migrate Exynos specific macros from plat to
mach") which lands in samsung tree causes build breakage
for cpufreq-exynos like following:
drivers/cpufreq/exynos-cpufreq.c: In functio
Hi Thomas,
Please see my comments inline.
On 14.05.2014 03:11, Thomas Abraham wrote:
> From; Thomas Abraham
>
> The clock blocks within the CMU_CPU clock domain are put together into a
> new composite clock type called the cpu clock. This clock type requires
> configuration data that will be at
On 05/17/14 08:04, Rafael J. Wysocki wrote:
On Friday, May 16, 2014 07:54:01 PM Kukjin Kim wrote:
Jonghwan Choi wrote:
Commit 7da83a80 ("ARM: EXYNOS: Migrate Exynos specific macros from plat to
mach") which lands in samsung tree causes build breakage
for cpufreq-exynos like following:
drivers
Hi Thomas,
Please see my comments inline.
On 14.05.2014 03:11, Thomas Abraham wrote:
> From: Thomas Abraham
>
> For all Exynos based platforms, add CPU nodes, operating points and cpu
> clock data for migrating from Exynos specific cpufreq driver to using
> generic cpufreq-cpu0 driver.
>
> Cc:
Quoting Tomasz Figa (2014-05-15 10:32:30)
> This patch introduces a driver that handles configuration of CLKOUT pin
> of Exynos SoCs that can be used to output certain clocks from inside of
> the SoC to a dedicated output pin.
>
> Signed-off-by: Tomasz Figa
Overall implementation looks good to m
On 05/16/14 14:12, Arun Kumar K wrote:
Looks good.
Reviewed-by : Arun Kumar K
On Tue, Apr 29, 2014 at 12:19 PM, Sachin Kamat wrote:
PD entry was missing in MFC codec node.
Signed-off-by: Sachin Kamat
---
arch/arm/boot/dts/exynos5420.dtsi |1 +
1 file changed, 1 insertion(+)
diff --git
>>> Anyway, I'm by no means opposed to switching to arch timers. They
>>> provide a well designed, generic interface and drivers shared by
>>> multiple platforms, which means more code sharing and possibly more eyes
>>> looking at the code, which is always good. However if they don't support
>>> lo
On Friday, May 16, 2014 07:54:01 PM Kukjin Kim wrote:
> Jonghwan Choi wrote:
> >
> > Commit 7da83a80 ("ARM: EXYNOS: Migrate Exynos specific macros from plat to
> > mach") which lands in samsung tree causes build breakage
> > for cpufreq-exynos like following:
> >
> > drivers/cpufreq/exynos-cpufre
Hi Thomas,
On 14.05.2014 03:11, Thomas Abraham wrote:
> From: Thomas Abraham
>
> 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, divi
Seungwon,
On Thu, May 15, 2014 at 6:46 PM, Seungwon Jeon wrote:
> On Wed, May 14, 2014, Doug Anderson wrote:
>> Seungwon,
>>
>> On Mon, May 12, 2014 at 9:52 PM, Seungwon Jeon wrote:
>> > Hi Doug,
>> >
>> > On Tue, May 13, 2014, Doug Anderson wrote:
>> >> Seungwon,
>> >>
>> >> On Sat, May 10, 201
On 16.05.2014 16:35, Rahul Sharma wrote:
> On 16 May 2014 16:22, Tomasz Figa wrote:
>> Hi Rahul,
>>
>> On 16.05.2014 12:39, Rahul Sharma wrote:
>>> [snip]
+ gate->lock = &clkout_lock;
+
+ mux->reg = reg + EXYNOS_PMU_DEBUG_REG;
+ mux->mask = EXYNOS_CLKOUT_MUX_M
On 16.05.2014 16:30, Rahul Sharma wrote:
> On 16 May 2014 16:20, Tomasz Figa wrote:
>> On 16.05.2014 12:35, Rahul Sharma wrote:
>>> On 16 May 2014 15:12, Rahul Sharma wrote:
On 16 May 2014 03:14, Tomasz Figa wrote:
> On 15.05.2014 06:01, Rahul Sharma wrote:
>>> [snip]
>>> the PHY pr
On 16 May 2014 16:22, Tomasz Figa wrote:
> Hi Rahul,
>
> On 16.05.2014 12:39, Rahul Sharma wrote:
>> [snip]
>>> + gate->lock = &clkout_lock;
>>> +
>>> + mux->reg = reg + EXYNOS_PMU_DEBUG_REG;
>>> + mux->mask = EXYNOS_CLKOUT_MUX_MASK;
>>> + mux->shift = EXYNOS_CLKOUT_MUX_SHI
On 16 May 2014 16:20, Tomasz Figa wrote:
> On 16.05.2014 12:35, Rahul Sharma wrote:
>> On 16 May 2014 15:12, Rahul Sharma wrote:
>>> On 16 May 2014 03:14, Tomasz Figa wrote:
On 15.05.2014 06:01, Rahul Sharma wrote:
>> [snip]
>> the PHY provider.
>>
>
> Please correct me if I
Tushar Behera wrote:
>
>
> Patch 2 is dependent on Arun's following patch.
> 1. [PATCH v4 0/2] Add peach-pit board support
> http://www.mail-archive.com/linux-samsung-
> s...@vger.kernel.org/msg29948.html
>
> Tushar Behera (2):
> ARM: dts: Add sound node for Snow board
> ARM: dts: Add sound
Hi Thomas,
On 14.05.2014 03:11, Thomas Abraham wrote:
> From: Thomas Abraham
>
> Access to samsung clock lock is required to support newer samsung specific
> clock types. So change the scope of the samsung clock lock to global. And
> prefix 'samsung_clk_' to the existing name of the lock to prev
Since v2.6.34 there are two checks for CONFIG_SND_SOC_SMDK2443_WM9710.
But a Kconfig symbol SND_SOC_SMDK2443_WM9710 has never been part of the
tree. However, in v2.6.38 a symbol SND_SOC_SAMSUNG_SMDK2443_WM9710 was
added, so it seems these checks should be for its macro.
But the second check is a g
Ajay Kumar wrote:
>
> Adds the PWM nodes to 5250 pinctrl dtsi file.
>
> Signed-off-by: Ajay Kumar
> ---
> arch/arm/boot/dts/exynos5250-pinctrl.dtsi | 28
>
> 1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi
> b/arch/arm/
From: Thierry Reding
This commit introduces a generic device tree binding for IOMMU devices.
Only a very minimal subset is described here, but it is enough to cover
the requirements of both the Exynos System MMU and Tegra SMMU as
discussed here:
https://lkml.org/lkml/2014/4/27/346
More adva
There are a number of checks for CONFIG_CPU_S3C2413. But there's no
Kconfig symbol CPU_S3C2413. That symbol is not needed, as CPU_S3C2412 is
documented to support both the S3C2412 and the S3C2413 SoCs.
Luckily, all these checks for CONFIG_CPU_S3C2413 are in places were we
also checks for CONFIG_CP
This patch adds the audio subsystem clock controller and the I2S
IP block nodes for Exynos4 SoC series.
Signed-off-by: Sylwester Nawrocki
---
arch/arm/boot/dts/exynos4.dtsi | 38 ++
1 file changed, 38 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dts
On 16 May 2014 15:48, Jonghwan Choi wrote:
> Commit 7da83a80 ("ARM: EXYNOS: Migrate Exynos specific macros from plat to
> mach") which lands in samsung tree causes build breakage
> for cpufreq-exynos like following:
>
> drivers/cpufreq/exynos-cpufreq.c: In function 'exynos_cpufreq_probe':
> drive
Jonghwan Choi wrote:
>
> Commit 7da83a80 ("ARM: EXYNOS: Migrate Exynos specific macros from plat to
> mach") which lands in samsung tree causes build breakage
> for cpufreq-exynos like following:
>
> drivers/cpufreq/exynos-cpufreq.c: In function 'exynos_cpufreq_probe':
> drivers/cpufreq/exynos-cp
Hi Rahul,
On 16.05.2014 12:39, Rahul Sharma wrote:
> [snip]
>> + gate->lock = &clkout_lock;
>> +
>> + mux->reg = reg + EXYNOS_PMU_DEBUG_REG;
>> + mux->mask = EXYNOS_CLKOUT_MUX_MASK;
>> + mux->shift = EXYNOS_CLKOUT_MUX_SHIFT;
>> + mux->lock = &clkout_lock;
>> +
>> +
On 16.05.2014 12:35, Rahul Sharma wrote:
> On 16 May 2014 15:12, Rahul Sharma wrote:
>> On 16 May 2014 03:14, Tomasz Figa wrote:
>>> On 15.05.2014 06:01, Rahul Sharma wrote:
> [snip]
> the PHY provider.
>
Please correct me if I got you wrong. You want somthing like this:
>>
On 13 May 2014 08:53, Rahul Sharma wrote:
> Thanks Jingoo Han.
>
> Hi Kukjin,
>
> Please consider both of these series for your tree.
>
> 1) http://www.spinics.net/lists/arm-kernel/msg329697.html
> 2) http://www.spinics.net/lists/arm-kernel/msg330291.html
>
> Regards,
> Rahul Sharma
>
> On 13 Ma
[snip]
> + gate->lock = &clkout_lock;
> +
> + mux->reg = reg + EXYNOS_PMU_DEBUG_REG;
> + mux->mask = EXYNOS_CLKOUT_MUX_MASK;
> + mux->shift = EXYNOS_CLKOUT_MUX_SHIFT;
> + mux->lock = &clkout_lock;
> +
> + clk = clk_register_composite(NULL, "clkout", parent_names,
On 16 May 2014 15:12, Rahul Sharma wrote:
> On 16 May 2014 03:14, Tomasz Figa wrote:
>> On 15.05.2014 06:01, Rahul Sharma wrote:
[snip]
the PHY provider.
>>>
>>> Please correct me if I got you wrong. You want somthing like this:
>>>
>>> pmu_system_controller: system-controller@1004
Hi Kamil, Arun,
On 16.05.2014 12:09, Kamil Debski wrote:
> Hi,
>
> Original Message-
>> From: arunkk.sams...@gmail.com [mailto:arunkk.sams...@gmail.com] On
>> Behalf Of Arun Kumar K
>> Sent: Friday, May 16, 2014 12:00 PM
>>
>> Hi Kamil,
>>
>> On Fri, May 16, 2014 at 3:24 PM, Kamil Debski
Commit 7da83a80 ("ARM: EXYNOS: Migrate Exynos specific macros from plat to
mach") which lands in samsung tree causes build breakage
for cpufreq-exynos like following:
drivers/cpufreq/exynos-cpufreq.c: In function 'exynos_cpufreq_probe':
drivers/cpufreq/exynos-cpufreq.c:166:2: error: implicit decl
Hi,
Original Message-
> From: arunkk.sams...@gmail.com [mailto:arunkk.sams...@gmail.com] On
> Behalf Of Arun Kumar K
> Sent: Friday, May 16, 2014 12:00 PM
>
> Hi Kamil,
>
> On Fri, May 16, 2014 at 3:24 PM, Kamil Debski
> wrote:
> > Hi Arun,
> >
> > I asked you to put old and new v6 firm
Hi Kamil,
On Fri, May 16, 2014 at 3:24 PM, Kamil Debski wrote:
> Hi Arun,
>
> I asked you to put old and new v6 firmware in separate files.
But wont that require a different filename other than s5p-mfc-v6.fw?
But the driver still expects the same file name.
Can I put the new filename as s5p-mfc-
On 16.05.2014 5:50 PM, Tomasz Figa wrote:
> We have been discussing Exynos cpufreq framework rework, including DT support
> since quite a long time.
> so if you want to know details, please look at respective discussion threads.
> I don't have time to
> find them for you right now, but if you lo
Hi Arun,
I asked you to put old and new v6 firmware in separate files.
You should also mention in the commit message that this new firmware
will not work with the s5p-mfc driver without the patch you recently
submitted to linux-media mailing list. Please also add a link to the
thread with the nece
On 16 May 2014 03:14, Tomasz Figa wrote:
> On 15.05.2014 06:01, Rahul Sharma wrote:
>> Thanks Tomasz,
>>
>> On 15 May 2014 01:31, Tomasz Figa wrote:
>>> Hi Rahul, Tomasz,
>> [snip]
+ simplephys: simple-phys@1004 {
+ compatible = "samsung,exynos5250-simple-phy";
>>>
>
On 05/05/2014 12:57 PM, Bartlomiej Zolnierkiewicz wrote:
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
On 05/05/2014 12:57 PM, Bartlomiej Zolnierkiewicz wrote:
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
Hi Jonghwan,
On 16.05.2014 09:58, Jonghwan Choi wrote:
> Commit 7da83a80 ("ARM: EXYNOS: Migrate Exynos specific macros from plat to
> mach")
> which lands in samsung tree causes build breakage for cpufreq-exynos like
> following:
> drivers/cpufreq/exynos-cpufreq.c: In function 'exynos_cpufreq_pr
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 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
Kukjin Kim wrote:
>
> Viresh Kumar wrote:
> >
> > And please use Rafael's email id from Maintainers..
> >
> > On 16 May 2014 13:25, Viresh Kumar wrote:
> > > On 16 May 2014 13:20, Jonghwan Choi wrote:
> > >> Commit 7da83a80 ("ARM: EXYNOS: Migrate Exynos specific macros from
> > >> plat to
> > >>
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 v5: None
Changes in v4: None
Changes in v3:
1. Add compatible string to of_dev
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 v6: None
Changes in v5:
1. Add comment to address cache access wh
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
---
Changes in v6:
1. Move cpuidle registration ch
Viresh Kumar wrote:
>
> And please use Rafael's email id from Maintainers..
>
> On 16 May 2014 13:25, Viresh Kumar wrote:
> > On 16 May 2014 13:20, Jonghwan Choi wrote:
> >> Commit 7da83a80 ("ARM: EXYNOS: Migrate Exynos specific macros from
> >> plat to
> >> mach")
> >
> > Why do you have a lin
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
The address of cpu power registers in pmu is based on cpu number
offsets. This function calculate the same. This is essentially
required in case of multi-cluster SoC's e.g Exynos5420.
Signed-off-by: Chander Kashyap
Signed-off-by: Chander Kashyap
---
arch/arm/mach-exynos/regs-pmu.h |9 ++
Commit 7da83a80 ("ARM: EXYNOS: Migrate Exynos specific macros from plat to
mach")
which lands in samsung tree causes build breakage for cpufreq-exynos like
following:
drivers/cpufreq/exynos-cpufreq.c: In function 'exynos_cpufreq_probe':
drivers/cpufreq/exynos-cpufreq.c:166:2: error: implicit decl
And please use Rafael's email id from Maintainers..
On 16 May 2014 13:25, Viresh Kumar wrote:
> On 16 May 2014 13:20, Jonghwan Choi wrote:
>> Commit 7da83a80 ("ARM: EXYNOS: Migrate Exynos specific macros from plat to
>> mach")
>
> Why do you have a line break here ?
>
>> which lands in samsung t
On 16 May 2014 13:20, Jonghwan Choi wrote:
> Commit 7da83a80 ("ARM: EXYNOS: Migrate Exynos specific macros from plat to
> mach")
Why do you have a line break here ?
> which lands in samsung tree causes build breakage for cpufreq-exynos like
> following:
Enter a blank line here..
> drivers/cpuf
Commit 7da83a80 ("ARM: EXYNOS: Migrate Exynos specific macros from plat to
mach")
which lands in samsung tree causes build breakage for cpufreq-exynos like
following:
drivers/cpufreq/exynos-cpufreq.c: In function 'exynos_cpufreq_probe':
drivers/cpufreq/exynos-cpufreq.c:166:2: error: implicit declar
66 matches
Mail list logo
