* [RFC PATCH 3/7] ARM: OMAP4+: PRM: remove "wkup" event
From: Nishanth Menon @ 2014-07-21 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721104413.GT18374@atomide.com>
On Mon, Jul 21, 2014 at 5:44 AM, Tony Lindgren <tony@atomide.com> wrote:
>
> Hmm so why was it added originally then?
>
> Do the PRM_IRQSTATUS line and the following line belong together
> or is it missing something?
Seems like to have been a copy paste from OMAP3 code which did have
wakeup event at bit 0.
--
---
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCHv2 12/17] cpuidle: mvebu: make the cpuidle driver capable of handling multiple SoCs
From: Arnd Bergmann @ 2014-07-21 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CCF295.6030907@linaro.org>
On Monday 21 July 2014 12:59:33 Daniel Lezcano wrote:
> On 07/09/2014 03:40 PM, Thomas Petazzoni wrote:
> > From: Gregory CLEMENT <gregory.clement@free-electrons.com>
> >
> > In order to prepare the add of new SoCs supports for this cpuidle
> > driver, this patch extends the platform_data understood by the
> > cpuidle-mvebu-v7 driver to contain a "type" identifying which specific
> > SoC the cpuidle driver is being probed for. It will be used by the
> > cpuidle driver to know the list of states for the current SoC.
>
> It makes more sense to use/implement a 'soc_is_xxx' macro or
> 'of_machine_is_compatible', like the other cpuidle drivers, no ?
>
> Is there a good reason to implement a new way to check the board ?
In all other subsystems, we try to do this per-device: We have almost
killed off all soc_is_* macros, and we strongly discourage anybody
from using of_machine_is_compatible() in driver code, as this goes
against the goals of multiplatform kernels on which we treat every
device as a separate thing that may get reused on any number of
machines or SoCs.
> It isn't possible to do:
>
> if (of_machine_is_compatible("marvell,armada-370-xp-pmsu"))
> cpuidle_register(&armadaxp_cpuidle_driver, NULL);
>
> ?
>
> That will prevent the creation of the new single-declaration header file.
It would be best to have a way to read a property (or multiple
properties) from DT instead, to identify the requirements of the
device individually. However, I guess that would also require
changing the DT representation in an incompatible way, which we
normally don't.
Arnd
^ permalink raw reply
* [PATCHv2 12/17] cpuidle: mvebu: make the cpuidle driver capable of handling multiple SoCs
From: Thomas Petazzoni @ 2014-07-21 11:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CCF295.6030907@linaro.org>
Dear Daniel Lezcano,
On Mon, 21 Jul 2014 12:59:33 +0200, Daniel Lezcano wrote:
> > In order to prepare the add of new SoCs supports for this cpuidle
> > driver, this patch extends the platform_data understood by the
> > cpuidle-mvebu-v7 driver to contain a "type" identifying which specific
> > SoC the cpuidle driver is being probed for. It will be used by the
> > cpuidle driver to know the list of states for the current SoC.
>
> It makes more sense to use/implement a 'soc_is_xxx' macro or
> 'of_machine_is_compatible', like the other cpuidle drivers, no ?
>
> Is there a good reason to implement a new way to check the board ?
>
> It isn't possible to do:
>
> if (of_machine_is_compatible("marvell,armada-370-xp-pmsu"))
> cpuidle_register(&armadaxp_cpuidle_driver, NULL);
So you suggest to have a different cpuidle driver, with a different
name, one for each SoC ?
Or do you suggest to have the cpuidle probe() function call
of_machine_is_compatible() to find out the SoC type?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2] ARM: EXYNOS: Fix build with PM_SLEEP=n
From: Bartlomiej Zolnierkiewicz @ 2014-07-21 11:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5864544.mJGdtT36g8@amdc1032>
On Monday, July 21, 2014 12:38:28 PM Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Saturday, July 19, 2014 04:42:34 AM Kukjin Kim wrote:
> > On 07/16/14 20:59, Tomasz Figa wrote:
> > > Hi Krzysztof,
> > >
> > > On 14.07.2014 09:45, Krzysztof Kozlowski wrote:
> > >> Fix building of exynos defconfig with disabled PM_SLEEP:
> > >> CONFIG_PM_SLEEP=n
> > >> CONFIG_PM_SLEEP_SMP=n
> > >> CONFIG_SUSPEND=n
> > >> by moving functions for power up/down of CPU and cluster to platsmp.c
> > >>
> > >> The build error messages:
> > >> arch/arm/mach-exynos/built-in.o: In function `exynos_boot_secondary':
> > >> arch/arm/mach-exynos/platsmp.c:111: undefined reference to `exynos_cpu_power_state'
> > >> arch/arm/mach-exynos/platsmp.c:112: undefined reference to `exynos_cpu_power_up'
> > >> arch/arm/mach-exynos/platsmp.c:116: undefined reference to `exynos_cpu_power_state'
> > >> make: *** [vmlinux] Error 1
> > >>
> > >> Signed-off-by: Krzysztof Kozlowski<k.kozlowski@samsung.com>
> > >>
> > >> ---
> > >> Changes since v1:
> > >> 1. Use different solution - just move the power up/down functions to a
> > >> common place instead of adding stubs in common.h. Suggested by Tomasz
> > >> Figa.
> > >> ---
> > >> arch/arm/mach-exynos/platsmp.c | 66 ++++++++++++++++++++++++++++++++++++++++++
> > >> arch/arm/mach-exynos/pm.c | 66 ------------------------------------------
> > >> 2 files changed, 66 insertions(+), 66 deletions(-)
> > >>
> > >
> > + Bart,
> >
> > > Reviewed-by: Tomasz Figa<t.figa@samsung.com>
> > >
> > Applied, thanks.
> >
> > Bart, I think this is better at this moment to fix the build breakage
> > with disabling PM...if you have any comments, please let me know.
>
> To fix PM_SLEEP=n build itself (with ARM_EXYNOS_CPUIDLE=n) Krzysztof's
> patch is not enough and patch [1] is also needed (this patch is very
> simple so I think that it is okay for v3.16).
Hmmm, I now see that you've applied Krzysztof's patch for v3.17 not v3.16.
In that case how do you want to deal with PM_SLEEP=n build breakages for
v3.16 and what do you mean with "fix the build breakage with disabling PM"?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> For PM_SLEEP=n and ARM_EXYNOS_CPUIDLE=y config more changes are needed
> and they are contained in patch [2] (please note that this patch depends
> on patch [3] from Tomasz Figa which was redone recently into [4] so my
> patch also needs to be refreshed). However if you think that this would
> result in too much changes for v3.16 kernel we can make ARM_EXYNOS_CPUIDLE
> select (or depend on) PM_SLEEP for now and fix the issue completely later
> in v3.17 kernel.
>
> [1] "[PATCH 1/2] ARM: EXYNOS: Fix build with PM_SLEEP=n part #2"
> http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34080.html
>
> [2] "[PATCH 2/2] ARM: EXYNOS: Fix build with PM_SLEEP=n and ARM_EXYNOS_CPUIDLE=y"
> http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34081.html
>
> [3] "[PATCH 5/6] ARM: EXYNOS: Fix suspend/resume sequencies"
> http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg32809.html
>
> [4] "[PATCH v3] ARM: EXYNOS: Fix suspend/resume sequences"
> http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34150.html
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
^ permalink raw reply
* [PATCH 7/8] ARM: OMAP2+: timer: Add fallback for of_clk_get
From: Tony Lindgren @ 2014-07-21 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398216429-4681-8-git-send-email-joelf@ti.com>
* Joel Fernandes <joelf@ti.com> [140422 18:27]:
> Not all platforms currently will support of_clk_get on timer
> because they may not have clock property in their DT nodes. Add
> code to handle this case so that things are kept working. Finally
> we can delete this code once all system timer nodes have a clock
> property.
I think this needs updating now too? Might be best to fix the
platforms that don't have clocks available yet via DT instead :)
Regards,
Tony
^ permalink raw reply
* [PATCH 6/8] ARM: OMAP2+: timer: Fix error message to not use hwmod structure
From: Tony Lindgren @ 2014-07-21 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398216429-4681-7-git-send-email-joelf@ti.com>
* Joel Fernandes <joelf@ti.com> [140422 18:27]:
> oh->name is no longer used, correct the error message.
I guess this error is created by one of the patchs in this
series? So maybe fold it into the patch creating this error?
Regards,
Tony
> Signed-off-by: Joel Fernandes <joelf@ti.com>
> ---
> arch/arm/mach-omap2/timer.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 4fcfd7a..519ccfd 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -331,8 +331,8 @@ static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
> if (clk_get_parent(timer->fclk) != src) {
> r = clk_set_parent(timer->fclk, src);
> if (r < 0) {
> - pr_warn("%s: %s cannot set source\n", __func__,
> - oh->name);
> + pr_warn("%s: cannot set timer's source\n", __func__);
> + WARN_ON(1);
> clk_put(src);
> return r;
> }
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH 3/8] ARM: OMAP2+: timer: Add comment on timer clk parenting
From: Tony Lindgren @ 2014-07-21 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398216429-4681-4-git-send-email-joelf@ti.com>
* Joel Fernandes <joelf@ti.com> [140422 18:27]:
> Add a comment describing the state of system timer clock parenting. The code
> following the comment should be deleted once all platforms can do DT boot, and
> specially should not be executed for DT platforms once we can specify default
> clock parents through DT.
I think we can do it already for DT based booting?
Regards,
Tony
> Signed-off-by: Joel Fernandes <joelf@ti.com>
> ---
> arch/arm/mach-omap2/timer.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index f192a41..9fdff5b 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -313,6 +313,10 @@ static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
> if (IS_ERR(timer->fclk))
> return PTR_ERR(timer->fclk);
>
> + /*
> + * Clock reparenting code, goes away for DT-boot atleast,
> + * once clock layer can do it through DT.
> + */
> src = clk_get(NULL, fck_source);
> if (IS_ERR(src))
> return PTR_ERR(src);
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH] Exynos4: cpuidle: support dual CPUs with AFTR state
From: Daniel Lezcano @ 2014-07-21 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2337363.gvYnZM7kuD@amdc1032>
On 07/16/2014 07:34 PM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Friday, May 30, 2014 03:53:09 PM Bartlomiej Zolnierkiewicz wrote:
>>
>> Hi,
>>
>> On Friday, May 30, 2014 01:34:45 PM Tomasz Figa wrote:
>>> Hi Daniel,
>>>
>>> On 30.05.2014 11:30, Daniel Lezcano wrote:
>>>> On 04/24/2014 07:42 PM, Tomasz Figa wrote:
>>>>> Hi Daniel,
>>>>>
>>>>> Please see my comments inline.
>>>>>
>>>>> Btw. Please fix your e-mail composer to properly wrap your messages
>>>>> around 7xth column, as otherwise they're hard to read.
>>>>>
>>>>> On 04.04.2014 11:48, Daniel Lezcano wrote:
>>>>>> The following driver is for exynos4210. I did not yet finished the
>>>>>> other boards, so
>>>>>> I created a specific driver for 4210 which could be merged later.
>>>>>>
>>>>>> The driver is based on Colin Cross's driver found at:
>>>>>>
>>>>>> https://android.googlesource.com/kernel/exynos/+/e686b1ec67423c40b4fdf811f9a4dfa3b393a010%5E%5E!/
>>>>>>
>>>>>>
>>>>>>
>>>>>> This one was based on a 3.4 kernel and an old API.
>>>>>>
>>>>>> It has been refreshed, simplified and based on the recent code cleanup
>>>>>> I sent
>>>>>> today.
>>>>>>
>>>>>> The AFTR could be entered when all the cpus (except cpu0) are down. In
>>>>>> order to
>>>>>> reach this situation, the couple idle states are used.
>>>>>>
>>>>>> There is a sync barrier at the entry and the exit of the low power
>>>>>> function. So
>>>>>> all cpus will enter and exit the function at the same time.
>>>>>>
>>>>>> At this point, CPU0 knows the other cpu will power down itself. CPU0
>>>>>> waits for
>>>>>> the CPU1 to be powered down and then initiate the AFTR power down
>>>>>> sequence.
>>>>>>
>>>>>> No interrupts are handled by CPU1, this is why we switch to the timer
>>>>>> broadcast
>>>>>> even if the local timer is not impacted by the idle state.
>>>>>>
>>>>>> When CPU0 wakes up, it powers up CPU1 and waits for it to boot. Then
>>>>>> they both
>>>>>> exit the idle function.
>>>>>>
>>>>>> This driver allows the exynos4210 to have the same power consumption
>>>>>> at idle
>>>>>> time than the one when we have to unplug CPU1 in order to let CPU0 to
>>>>>> reach
>>>>>> the AFTR state.
>>>>>>
>>>>>> This patch is a RFC because, we have to find a way to remove the macros
>>>>>> definitions and cpu powerdown function without pulling the arch
>>>>>> dependent
>>>>>> headers.
>>>>>>
>>>>>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>>>>>> ---
>>>>>> arch/arm/mach-exynos/common.c | 11 +-
>>>>>> drivers/cpuidle/Kconfig.arm | 8 ++
>>>>>> drivers/cpuidle/Makefile | 1 +
>>>>>> drivers/cpuidle/cpuidle-exynos4210.c | 226
>>>>>> ++++++++++++++++++++++++++++++++++
>>>>
>>>> [ ... ]
>>>>
>>>>
>>>>> Otherwise, I quite like the whole idea. I need to play a bit with CPU
>>>>> hotplug and PMU to verify that things couldn't really be simplified a
>>>>> bit, but in general this looks reasonably.
>>>>
>>>> Hi Tomasz,
>>>>
>>>> did you have time to look at this simplification ?
>>>
>>> Unfortunately I got preempted with other things to do and now I'm on
>>> vacation. I worked a bit with Bart (added on CC) on this and generally
>>> the conclusion was that all the things are necessary. He was also
>>> working to extend the driver to support Exynos4x12.
>>>
>>> Bart, has anything interesting showed up since we talked about this last
>>> time?
>>
>> Since we last looked into this I have fixed the "standard" AFTR support
>> for Exynos3250 and started to work on adding Exynos3250 support to this
>> driver (as Exynos3250 support has bigger priority than Exynos4x12 one).
>> Unfortunately I also got preempted with other things so it is still
>> unfinished and doesn't work yet. Moreover I had no possibility to test
>> the new driver on Exynos4210 based Origen yet (I hope to do this next
>> week).
>
> I have tested this patch on Origen board (Exynos4210 rev 1.1) and it
> causes system lockup (it seems that the code gets stuck on waiting for
> CPU1 to wake up).
>
> The kernels I have tried:
> * current -next + this patch + few fixes to bring it up to date
> * commit cd245f5 + this patch + some fixes
> * next-20140403 + your Exynos cpuidle patch series + this patch
>
> I have also tried with S5P_VA_SYSRAM replaced by S5P_INFORM5 to
> match Exynos 4210 rev 1.1 but it didn't help.
>
> U-Boot version used is:
> U-Boot 2012.07 (Sep 22 2012 - 05:12:41) for ORIGEN
>
> Could you please tell me which hardware/bootloader/kernel exactly
> have you used to test this patch?
When I used it, it was on top of 3.15-rc1:
https://git.linaro.org/people/daniel.lezcano/linux.git/shortlog/refs/heads/cpuidle/samsung-next
The hardware was a exynos-4210 origen board ver A.
> Also could you please port/retest your patch over the current -next?
Will do that in my free time after unstacking my emails after 2 weeks of
vacations :)
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH 2/8] ARM: OMAP2+: timer: Simplify clock event/source name setting
From: Tony Lindgren @ 2014-07-21 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398216429-4681-3-git-send-email-joelf@ti.com>
* Joel Fernandes <joelf@ti.com> [140422 18:27]:
> For the OMAPs, we're setting up only one clockevent and clocksource. Further,
> for DT boot there's no easy way to get the timer name and currently this is
> done in an ugly way by reading a hwmod entry. So let's just set it to a simpler
> name like timer_clkev and timer_clksrc.
>
> Signed-off-by: Joel Fernandes <joelf@ti.com>
> ---
> arch/arm/mach-omap2/timer.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index ec427e6..f192a41 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -251,7 +251,6 @@ static u32 __init omap_dm_timer_get_errata(void)
> static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
> const char *fck_source,
> const char *property,
> - const char **timer_name,
> int posted)
> {
> char name[10]; /* 10 = sizeof("gptXX_Xck0") */
> @@ -290,8 +289,6 @@ static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
> if (!oh)
> return -ENODEV;
>
> - *timer_name = oh->name;
> -
> if (!of_have_populated_dt()) {
> r = omap_hwmod_get_resource_byname(oh, IORESOURCE_IRQ, NULL,
> &irq);
> @@ -365,8 +362,10 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
> */
> __omap_dm_timer_override_errata(&clkev, OMAP_TIMER_ERRATA_I103_I767);
>
> + clockevent_gpt.name = "timer_clkev";
> +
> res = omap_dm_timer_init_one(&clkev, fck_source, property,
> - &clockevent_gpt.name, OMAP_TIMER_POSTED);
> + OMAP_TIMER_POSTED);
> BUG_ON(res);
>
> omap2_gp_timer_irq.dev_id = &clkev;
> @@ -489,10 +488,11 @@ static void __init omap2_gptimer_clocksource_init(int gptimer_id,
> clksrc.errata = omap_dm_timer_get_errata();
>
> res = omap_dm_timer_init_one(&clksrc, fck_source, property,
> - &clocksource_gpt.name,
> OMAP_TIMER_NONPOSTED);
> BUG_ON(res);
>
> + clocksource_gpt.name = "timer_clksrc";
> +
> __omap_dm_timer_load_start(&clksrc,
> OMAP_TIMER_CTRL_AR, 0,
> OMAP_TIMER_NONPOSTED);
Hmm aren't we losing information now about which timer we are using?
Might be worth checking if these new names are getting copied somewhere
or what happens after init?
Regards,
Tony
^ permalink raw reply
* [PATCH 1/8] ARM: OMAP2+: timer: Add a powerup function
From: Tony Lindgren @ 2014-07-21 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1398216429-4681-2-git-send-email-joelf@ti.com>
* Joel Fernandes <joelf@ti.com> [140422 18:27]:
> In an effort to isolate the time power initialization for future purposes, add
> a function to do the same. This primarily involves a hwmod lookup, setup and
> enable.
No users yet for this function? Can you remove the same code from
somewhere else in this patch?
Regards,
Tony
> Signed-off-by: Joel Fernandes <joelf@ti.com>
> ---
> arch/arm/mach-omap2/timer.c | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index dfb19df..ec427e6 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -210,6 +210,31 @@ static void __init omap_dmtimer_init(void)
> }
> }
>
> +int __init omap_dmtimer_powerup(struct device_node *np)
> +{
> + struct omap_hwmod *oh;
> + const char *oh_name = NULL;
> + int ret;
> +
> + of_property_read_string_index(np, "ti,hwmods", 0, &oh_name);
> + if (!oh_name)
> + return -ENODEV;
> +
> + oh = omap_hwmod_lookup(oh_name);
> + if (!oh)
> + return -ENODEV;
> +
> + ret = omap_hwmod_setup_one(oh_name);
> + if (ret)
> + return ret;
> +
> + ret = omap_hwmod_enable(oh);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +
> /**
> * omap_dm_timer_get_errata - get errata flags for a timer
> *
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCHv2 12/17] cpuidle: mvebu: make the cpuidle driver capable of handling multiple SoCs
From: Daniel Lezcano @ 2014-07-21 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1404913221-17343-13-git-send-email-thomas.petazzoni@free-electrons.com>
On 07/09/2014 03:40 PM, Thomas Petazzoni wrote:
> From: Gregory CLEMENT <gregory.clement@free-electrons.com>
>
> In order to prepare the add of new SoCs supports for this cpuidle
> driver, this patch extends the platform_data understood by the
> cpuidle-mvebu-v7 driver to contain a "type" identifying which specific
> SoC the cpuidle driver is being probed for. It will be used by the
> cpuidle driver to know the list of states for the current SoC.
It makes more sense to use/implement a 'soc_is_xxx' macro or
'of_machine_is_compatible', like the other cpuidle drivers, no ?
Is there a good reason to implement a new way to check the board ?
It isn't possible to do:
if (of_machine_is_compatible("marvell,armada-370-xp-pmsu"))
cpuidle_register(&armadaxp_cpuidle_driver, NULL);
?
That will prevent the creation of the new single-declaration header file.
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> arch/arm/mach-mvebu/pmsu.c | 20 +++++++++++++-------
> drivers/cpuidle/cpuidle-mvebu-v7.c | 32 ++++++++++++++++++++------------
> include/linux/mvebu-v7-cpuidle.h | 26 ++++++++++++++++++++++++++
> 3 files changed, 59 insertions(+), 19 deletions(-)
> create mode 100644 include/linux/mvebu-v7-cpuidle.h
>
> diff --git a/arch/arm/mach-mvebu/pmsu.c b/arch/arm/mach-mvebu/pmsu.c
> index 802edc8..0a24073 100644
> --- a/arch/arm/mach-mvebu/pmsu.c
> +++ b/arch/arm/mach-mvebu/pmsu.c
> @@ -19,10 +19,12 @@
> #define pr_fmt(fmt) "mvebu-pmsu: " fmt
>
> #include <linux/cpu_pm.h>
> +#include <linux/cpuidle.h>
> #include <linux/init.h>
> #include <linux/io.h>
> #include <linux/kernel.h>
> #include <linux/mbus.h>
> +#include <linux/mvebu-v7-cpuidle.h>
> #include <linux/of_address.h>
> #include <linux/platform_device.h>
> #include <linux/resource.h>
> @@ -75,10 +77,6 @@ extern void armada_370_xp_cpu_resume(void);
>
> static void *mvebu_cpu_resume;
>
> -static struct platform_device mvebu_v7_cpuidle_device = {
> - .name = "cpuidle-mvebu-v7",
> -};
> -
> static struct of_device_id of_pmsu_table[] = {
> { .compatible = "marvell,armada-370-pmsu", },
> { .compatible = "marvell,armada-370-xp-pmsu", },
> @@ -325,17 +323,25 @@ static struct notifier_block mvebu_v7_cpu_pm_notifier = {
> .notifier_call = mvebu_v7_cpu_pm_notify,
> };
>
> -static int __init armada_xp_cpuidle_init(void)
> +static struct mvebu_v7_cpuidle armada_xp_cpuidle = {
> + .type = CPUIDLE_ARMADA_XP,
> + .cpu_suspend = armada_370_xp_cpu_suspend,
> +};
> +
> +static struct platform_device mvebu_v7_cpuidle_device = {
> + .name = "cpuidle-mvebu-v7",
> +};
> +
> +static __init int armada_xp_cpuidle_init(void)
> {
> struct device_node *np;
> -
> np = of_find_compatible_node(NULL, NULL, "marvell,coherency-fabric");
> if (!np)
> return -ENODEV;
> of_node_put(np);
>
> mvebu_cpu_resume = armada_370_xp_cpu_resume;
> - mvebu_v7_cpuidle_device.dev.platform_data = armada_370_xp_cpu_suspend;
> + mvebu_v7_cpuidle_device.dev.platform_data = &armada_xp_cpuidle;
>
> return 0;
> }
> diff --git a/drivers/cpuidle/cpuidle-mvebu-v7.c b/drivers/cpuidle/cpuidle-mvebu-v7.c
> index 302596e..82c545bb 100644
> --- a/drivers/cpuidle/cpuidle-mvebu-v7.c
> +++ b/drivers/cpuidle/cpuidle-mvebu-v7.c
> @@ -16,15 +16,15 @@
> #include <linux/cpu_pm.h>
> #include <linux/cpuidle.h>
> #include <linux/module.h>
> +#include <linux/mvebu-v7-cpuidle.h>
> #include <linux/of.h>
> #include <linux/suspend.h>
> #include <linux/platform_device.h>
> #include <asm/cpuidle.h>
>
> -#define MVEBU_V7_MAX_STATES 3
> #define MVEBU_V7_FLAG_DEEP_IDLE 0x10000
>
> -static int (*mvebu_v7_cpu_suspend)(int);
> +static struct mvebu_v7_cpuidle *pcpuidle;
>
> static int mvebu_v7_enter_idle(struct cpuidle_device *dev,
> struct cpuidle_driver *drv,
> @@ -32,12 +32,13 @@ static int mvebu_v7_enter_idle(struct cpuidle_device *dev,
> {
> int ret;
> bool deepidle = false;
> +
> cpu_pm_enter();
>
> if (drv->states[index].flags & MVEBU_V7_FLAG_DEEP_IDLE)
> deepidle = true;
>
> - ret = mvebu_v7_cpu_suspend(deepidle);
> + ret = pcpuidle->cpu_suspend(deepidle);
> if (ret)
> return ret;
>
> @@ -46,8 +47,8 @@ static int mvebu_v7_enter_idle(struct cpuidle_device *dev,
> return index;
> }
>
> -static struct cpuidle_driver mvebu_v7_idle_driver = {
> - .name = "mvebu_v7_idle",
> +static struct cpuidle_driver armadaxp_cpuidle_driver = {
> + .name = "armada_xp_idle",
> .states[0] = ARM_CPUIDLE_WFI_STATE,
> .states[1] = {
> .enter = mvebu_v7_enter_idle,
> @@ -55,7 +56,7 @@ static struct cpuidle_driver mvebu_v7_idle_driver = {
> .power_usage = 50,
> .target_residency = 100,
> .flags = CPUIDLE_FLAG_TIME_VALID,
> - .name = "MV CPU IDLE",
> + .name = "Idle",
> .desc = "CPU power down",
> },
> .states[2] = {
> @@ -63,19 +64,26 @@ static struct cpuidle_driver mvebu_v7_idle_driver = {
> .exit_latency = 100,
> .power_usage = 5,
> .target_residency = 1000,
> - .flags = CPUIDLE_FLAG_TIME_VALID |
> - MVEBU_V7_FLAG_DEEP_IDLE,
> - .name = "MV CPU DEEP IDLE",
> + .flags = (CPUIDLE_FLAG_TIME_VALID |
> + MVEBU_V7_FLAG_DEEP_IDLE),
> + .name = "Deep idle",
> .desc = "CPU and L2 Fabric power down",
> },
> - .state_count = MVEBU_V7_MAX_STATES,
> + .state_count = 3,
> };
>
> static int mvebu_v7_cpuidle_probe(struct platform_device *pdev)
> {
> + struct cpuidle_driver *drv;
> +
> + pcpuidle = pdev->dev.platform_data;
> +
> + if (pcpuidle->type == CPUIDLE_ARMADA_XP)
> + drv = &armadaxp_cpuidle_driver;
> + else
> + return -EINVAL;
>
> - mvebu_v7_cpu_suspend = (void *)(pdev->dev.platform_data);
> - return cpuidle_register(&mvebu_v7_idle_driver, NULL);
> + return cpuidle_register(drv, NULL);
> }
>
> static struct platform_driver mvebu_v7_cpuidle_plat_driver = {
> diff --git a/include/linux/mvebu-v7-cpuidle.h b/include/linux/mvebu-v7-cpuidle.h
> new file mode 100644
> index 0000000..00fde86
> --- /dev/null
> +++ b/include/linux/mvebu-v7-cpuidle.h
> @@ -0,0 +1,26 @@
> +/*
> + * Marvell EBU cpuidle defintion
> + *
> + * Copyright (C) 2014 Marvell
> + *
> + * Gregory CLEMENT <gregory.clement@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + *
> + */
> +
> +#ifndef __LINUX_MVEBU_V7_CPUIDLE_H__
> +#define __LINUX_MVEBU_V7_CPUIDLE_H__
> +
> +enum mvebu_v7_cpuidle_types {
> + CPUIDLE_ARMADA_XP,
> +};
> +
> +struct mvebu_v7_cpuidle {
> + int type;
> + int (*cpu_suspend)(unsigned long deepidle);
> +};
> +
> +#endif
>
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [RFC PATCH 4/7] ARM: OMAP4+: PRM: register interrupt information from DT
From: Tony Lindgren @ 2014-07-21 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1402025761-16831-5-git-send-email-nm@ti.com>
* Nishanth Menon <nm@ti.com> [140605 20:37]:
> Allow the PRM interrupt information to be picked up from device tree.
> the only exception is for OMAP4 which uses values pre-populated and allows
> compatibility with older dtb.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> arch/arm/mach-omap2/prm44xx.c | 41 +++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
> index 1ecf244..784b3e1 100644
> --- a/arch/arm/mach-omap2/prm44xx.c
> +++ b/arch/arm/mach-omap2/prm44xx.c
> @@ -17,6 +17,7 @@
> #include <linux/errno.h>
> #include <linux/err.h>
> #include <linux/io.h>
> +#include <linux/of_irq.h>
>
>
> #include "soc.h"
> @@ -698,11 +699,51 @@ int __init omap44xx_prm_init(void)
> return prm_register(&omap44xx_prm_ll_data);
> }
>
> +static struct of_device_id omap_prm_dt_match_table[] = {
> + { .compatible = "ti,omap4-prm" },
> + { .compatible = "ti,omap5-prm" },
> + { .compatible = "ti,dra7-prm" },
> + { }
> +};
> +
I'd like to avoid adding more driver like stuff to mach-omap2
and parsing compatible flags and dealing with interupts sounds
very driver like.. But maybe just the handling can be moved
out?
Would a simple driver be doable that parses the compatible
flags, takes care of the IRQ chaining, and gets some SoC specific
function pointers as auxdata?
That would allow further work later on to remove the auxdata
dependencies possibly.
Regards,
Tony
^ permalink raw reply
* [PATCHv6 3/4] iio: devicetree: Add DT binding documentation for Exynos3250 ADC
From: Arnd Bergmann @ 2014-07-21 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CCEDBF.7010300@gmail.com>
On Monday 21 July 2014 12:38:55 Tomasz Figa wrote:
>
> I believe we should be enforcing as much correctness on DT data as
> possible without too much burden in the code. Otherwise how we are
> supposed to know if an error is caused by wrong/missing data in DT, bug
> in the driver or who knows else?
>
> In this case making this clock required depending on compatible string
> doesn't seem too bothersome to me.
It makes some sense given that we already need the separate compatible
string (for the number of channels). Without that part, I'd probably
prefer not having the new string just for the extra clock being required,
that could be handled more easily by just making it an optional clock.
Arnd
^ permalink raw reply
* [RFC PATCH 3/7] ARM: OMAP4+: PRM: remove "wkup" event
From: Tony Lindgren @ 2014-07-21 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1402025761-16831-4-git-send-email-nm@ti.com>
* Nishanth Menon <nm@ti.com> [140605 20:37]:
> "wkup" event at bit offset 0 exists only on OMAP3.
> OMAP4430/60 PRM_IRQSTATUS_A9, OMAP5/DRA7 PRM_IRQSTATUS_MPU
>
> register bit 0 is DPLL_CORE_RECAL_ST not wakeup event like OMAP3.
Hmm so why was it added originally then?
Do the PRM_IRQSTATUS line and the following line belong together
or is it missing something?
Regards,
Tony
> The same applies to AM437x as well.
>
> Remove the wrong definition.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> arch/arm/mach-omap2/prm44xx.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
> index d4d745e..1ecf244 100644
> --- a/arch/arm/mach-omap2/prm44xx.c
> +++ b/arch/arm/mach-omap2/prm44xx.c
> @@ -32,7 +32,6 @@
> /* Static data */
>
> static const struct omap_prcm_irq omap4_prcm_irqs[] = {
> - OMAP_PRCM_IRQ("wkup", 0, 0),
> OMAP_PRCM_IRQ("io", 9, 1),
> };
>
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCHv6 3/4] iio: devicetree: Add DT binding documentation for Exynos3250 ADC
From: Tomasz Figa @ 2014-07-21 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7477106.gq1AqisQx4@wuerfel>
On 21.07.2014 10:00, Arnd Bergmann wrote:
> On Monday 21 July 2014 10:52:28 Chanwoo Choi wrote:
>>> Yes, your current version is certainly better than this, but another way
>>> to address Tomasz' comment would be to change the binding to list the "sclk"
>>> as optional for any device and make the code silently ignore missing sclk
>>> entries, like:
>>>
>>>
>>> info->sclk = devm_clk_get(&pdev->dev, "sclk");
>>> if (IS_ERR(info->sclk)) {
>>> switch (PTR_ERR(info->sclk)) {
>>> case -EPROBE_DEFER:
>>> /* silently return error so we can retry */
>>> return -EPROBE_DEFER:
>>> case -ENOENT:
>>> /* silently ignore missing optional clk */
>>> info->sclk = NULL;
>>> break;
>>> default:
>>> /* any other error: clk is defined by doesn't work */
>>> dev_err(&pdev->dev, "failed getting sclk clock, err = %ld\n",
>>> PTR_ERR(info->sclk));
>>> return PTR_ERR(info->sclk));
>>> }
>>> }
>>
>> I tested this patch suggested by you.
>> But, devm_clk_get returns always '-ENOENT' on follwong two cases:
>>
>> Case 1.
>> ADC dt node in exynos3250.dtsi don't include 'sclk' clock as following:
>>
>> adc: adc at 126C0000 {
>> compatible = "samsung,exynos3250-adc";
>> reg = <0x126C0000 0x100>, <0x10020718 0x4>;
>> interrupts = <0 137 0>;
>> clock-names = "adc";
>> clocks = <&cmu CLK_TSADC>;
>> #io-channel-cells = <1>;
>> io-channel-ranges;
>> };
>>
>> Case 2.
>> ADC dt node in exynos3250.dtsi don't include 'sclk' clock
>> but, exynos3250 clock controller don't support CLK_SCLK_TSADC clock as following:
>>
>> adc: adc at 126C0000 {
>> compatible = "samsung,exynos3250-adc";
>> reg = <0x126C0000 0x100>, <0x10020718 0x4>;
>> interrupts = <0 137 0>;
>> clock-names = "adc", "sclk";
>> clocks = <&cmu CLK_TSADC>, <&cmu CLK_SCLK_TSADC>;
>> #io-channel-cells = <1>;
>> io-channel-ranges;
>> };
>
> But neither of those cases is actually a correct DT representation for
> exynos3250: The first case describes an ADC that doesn't need a second
> clock, so if the hardware actually needs it to function, it is clearly
> unsufficiently described. The second case is even worse because it refers
> to a clock that isn't there. Actually that should probably return a different
> error code, but that's a different matter.
>
>> So, I think exynos-adc needs to use 'needs_sclk' field suggested by Tomasz Figa.
>
> I don't mind you adding a field to the data, especially since you already
> need to have separate structures to encode the different number of channels.
> However, I don't see it as necessary either. What you do here is just
> checking the DT representation for correctness and consistency. It's not
> harmful but we don't normally do that because passing incorrect DT blobs
> can cause an infinite number of other problems that we don't check for.
I believe we should be enforcing as much correctness on DT data as
possible without too much burden in the code. Otherwise how we are
supposed to know if an error is caused by wrong/missing data in DT, bug
in the driver or who knows else?
In this case making this clock required depending on compatible string
doesn't seem too bothersome to me.
Best regards,
Tomasz
^ permalink raw reply
* [PATCH v2] ARM: EXYNOS: Fix build with PM_SLEEP=n
From: Bartlomiej Zolnierkiewicz @ 2014-07-21 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C978AA.9090603@samsung.com>
Hi,
On Saturday, July 19, 2014 04:42:34 AM Kukjin Kim wrote:
> On 07/16/14 20:59, Tomasz Figa wrote:
> > Hi Krzysztof,
> >
> > On 14.07.2014 09:45, Krzysztof Kozlowski wrote:
> >> Fix building of exynos defconfig with disabled PM_SLEEP:
> >> CONFIG_PM_SLEEP=n
> >> CONFIG_PM_SLEEP_SMP=n
> >> CONFIG_SUSPEND=n
> >> by moving functions for power up/down of CPU and cluster to platsmp.c
> >>
> >> The build error messages:
> >> arch/arm/mach-exynos/built-in.o: In function `exynos_boot_secondary':
> >> arch/arm/mach-exynos/platsmp.c:111: undefined reference to `exynos_cpu_power_state'
> >> arch/arm/mach-exynos/platsmp.c:112: undefined reference to `exynos_cpu_power_up'
> >> arch/arm/mach-exynos/platsmp.c:116: undefined reference to `exynos_cpu_power_state'
> >> make: *** [vmlinux] Error 1
> >>
> >> Signed-off-by: Krzysztof Kozlowski<k.kozlowski@samsung.com>
> >>
> >> ---
> >> Changes since v1:
> >> 1. Use different solution - just move the power up/down functions to a
> >> common place instead of adding stubs in common.h. Suggested by Tomasz
> >> Figa.
> >> ---
> >> arch/arm/mach-exynos/platsmp.c | 66 ++++++++++++++++++++++++++++++++++++++++++
> >> arch/arm/mach-exynos/pm.c | 66 ------------------------------------------
> >> 2 files changed, 66 insertions(+), 66 deletions(-)
> >>
> >
> + Bart,
>
> > Reviewed-by: Tomasz Figa<t.figa@samsung.com>
> >
> Applied, thanks.
>
> Bart, I think this is better at this moment to fix the build breakage
> with disabling PM...if you have any comments, please let me know.
To fix PM_SLEEP=n build itself (with ARM_EXYNOS_CPUIDLE=n) Krzysztof's
patch is not enough and patch [1] is also needed (this patch is very
simple so I think that it is okay for v3.16).
For PM_SLEEP=n and ARM_EXYNOS_CPUIDLE=y config more changes are needed
and they are contained in patch [2] (please note that this patch depends
on patch [3] from Tomasz Figa which was redone recently into [4] so my
patch also needs to be refreshed). However if you think that this would
result in too much changes for v3.16 kernel we can make ARM_EXYNOS_CPUIDLE
select (or depend on) PM_SLEEP for now and fix the issue completely later
in v3.17 kernel.
[1] "[PATCH 1/2] ARM: EXYNOS: Fix build with PM_SLEEP=n part #2"
http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34080.html
[2] "[PATCH 2/2] ARM: EXYNOS: Fix build with PM_SLEEP=n and ARM_EXYNOS_CPUIDLE=y"
http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34081.html
[3] "[PATCH 5/6] ARM: EXYNOS: Fix suspend/resume sequencies"
http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg32809.html
[4] "[PATCH v3] ARM: EXYNOS: Fix suspend/resume sequences"
http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg34150.html
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH resend v2] arm64: dmi: Add SMBIOS/DMI support
From: Catalin Marinas @ 2014-07-21 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9dfw7+URK+YG6D9_gUiFn17abUk2MUw5Jj5+5BwgrVbA@mail.gmail.com>
On Mon, Jul 21, 2014 at 11:18:37AM +0100, Ard Biesheuvel wrote:
> On 21 July 2014 12:03, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Fri, Jul 11, 2014 at 12:46:50PM +0100, Ard Biesheuvel wrote:
> >> --- /dev/null
> >> +++ b/arch/arm64/include/asm/dmi.h
> >> @@ -0,0 +1,41 @@
> > [...]
> >> +static inline void __iomem *dmi_remap(u64 phys, u64 size)
> >> +{
> >> + void __iomem *p = efi_lookup_mapped_addr(phys);
> >
> > When are dmi_remap/dmi_early_remap() called? A quick grep through the
> > kernel shows that it is at least called once from dmi_scan_machine().
> > The latter is a device_initcall() in this patch. However, the comments
> > for efi_lookup_mapped_addr() state that it should only be called between
> > efi_enter_virtual_mode and efi_free_boot_services. The latter is invoked
> > from an early_initcall(). Could you please clarify which part is wrong
> > here?
>
> The comment about efi_lookup_mapped_addr() is wrong. Those mappings
> are always available.
> As the comment is in shared code, I will propose a patch to Matt
> Fleming to clarify it.
Thanks for the clarification. I'll merge this patch as is.
--
Catalin
^ permalink raw reply
* [PATCH 3/4] ARM64: add IPI tracepoints
From: Catalin Marinas @ 2014-07-21 10:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405660735-13408-4-git-send-email-nicolas.pitre@linaro.org>
On Fri, Jul 18, 2014 at 06:18:54AM +0100, Nicolas Pitre wrote:
> The strings used to list IPIs in /proc/interrupts are reused for tracing
> purposes.
>
> While at it, the code is slightly cleaned up so the ipi_types array
> indices are no longer offset by IPI_RESCHEDULE whose value is 0 anyway.
>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH 4/6] ARM: SAMSUNG: Restore Samsung PM Debug functionality
From: Tomasz Figa @ 2014-07-21 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C5C065.3010106@gmail.com>
On 16.07.2014 01:59, Tomasz Figa wrote:
> On 15.07.2014 20:02, Kukjin Kim wrote:
>> On 07/08/14 22:54, Tomasz Figa wrote:
>>> On 08.07.2014 15:48, Kukjin Kim wrote:
>>>> Tomasz Figa wrote:
>>>>>
>>>>> Due to recently merged patches and previous merge conflicts, the
>>>>> Samsung
>>>>> PM Debug functionality no longer can be enabled. This patch fixes
>>>>> incorrect dependency of SAMSUNG_PM_DEBUG on an integer symbol and adds
>>>>> missing header inclusion.
>>>>>
>>>> Yes, you're right and it should be fixed...but I have comments...
>>>>
>>>>> Signed-off-by: Tomasz Figa<t.figa@samsung.com>
>>>>> ---
>>>>> arch/arm/plat-samsung/Kconfig | 8 +++++++-
>>>>> arch/arm/plat-samsung/pm-debug.c | 1 +
>>>>> 2 files changed, 8 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/arm/plat-samsung/Kconfig
>>>>> b/arch/arm/plat-samsung/Kconfig
>>>>> index 301b892..483c959 100644
>>>>> --- a/arch/arm/plat-samsung/Kconfig
>>>>> +++ b/arch/arm/plat-samsung/Kconfig
>>>>> @@ -412,9 +412,14 @@ config S5P_DEV_MFC
>>>>>
>>>>> comment "Power management"
>>>>>
>>>>> +config HAVE_SAMSUNG_PM_DEBUG
>>>>> + bool
>>>>> + help
>>>>> + Allow compilation of Samsung PM debugging code.
>>>>> +
>>>>> config SAMSUNG_PM_DEBUG
>>>>> bool "S3C2410 PM Suspend debug"
>>>>> - depends on PM&& DEBUG_KERNEL&& DEBUG_S3C_UART
>>>>> + depends on PM&& DEBUG_KERNEL&& HAVE_SAMSUNG_PM_DEBUG
>>>>> help
>>>>> Say Y here if you want verbose debugging from the PM Suspend
>>>>> and
>>>>> Resume code.
>>>>> See<file:Documentation/arm/Samsung-S3C24XX/Suspend.txt>
>>>>> @@ -484,6 +489,7 @@ config S5P_SLEEP
>>>>>
>>>>> config DEBUG_S3C_UART
>>>>> depends on PLAT_SAMSUNG
>>>>> + select HAVE_SAMSUNG_PM_DEBUG
>>>>
>>>> Hmm...
>>>>
>>>> The DEBUG_S3C_UART will be '0' when we select DEBUG_S3C_UART0, then the
>>>> HAVE_SAMSUNG_PM_DEBUG will not be selected so SAMSUNG_PM_DEBUG is
>>>> also...
>>>
>>> Yes, that's right. I posted v2 after a while in another reply to this
>>> thread.
>>>
>> Any updates? Or I missed your updated?
>
> I'm afraid you missed. V2 has been there since a long time posted as a
> reply to original patch. You can find it here:
>
> https://lkml.org/lkml/2014/6/25/301
Ping.
Best regards,
Tomasz
^ permalink raw reply
* [PATCH 2/3] ARM: smp_scu: enable SCU standby support
From: Catalin Marinas @ 2014-07-21 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721092703.GL8537@dragon>
On Mon, Jul 21, 2014 at 05:27:04PM +0800, Shawn Guo wrote:
> On Mon, Jul 21, 2014 at 09:51:50AM +0100, Will Deacon wrote:
> > On Mon, Jul 21, 2014 at 08:45:54AM +0100, Shawn Guo wrote:
> > > With SCU standby enabled, SCU CLK will be turned off when all processors
> > > are in WFI mode. And the clock will be turned on when any processor
> > > leaves WFI mode.
> > >
> > > This behavior should be preferable in terms of power efficiency of
> > > system idle. So let's set the SCU standby bit to enable the support in
> > > function scu_enable().
> > >
> > > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> > > ---
> > > arch/arm/kernel/smp_scu.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm/kernel/smp_scu.c b/arch/arm/kernel/smp_scu.c
> > > index c947508f84e6..9f29d167d02c 100644
> > > --- a/arch/arm/kernel/smp_scu.c
> > > +++ b/arch/arm/kernel/smp_scu.c
> > > @@ -18,6 +18,7 @@
> > >
> > > #define SCU_CTRL 0x00
> > > #define SCU_ENABLE (1 << 0)
> > > +#define SCU_STANDBY_ENABLE (1 << 5)
> > > #define SCU_CONFIG 0x04
> > > #define SCU_CPU_STATUS 0x08
> > > #define SCU_INVALIDATE 0x0c
> > > @@ -54,7 +55,7 @@ void scu_enable(void __iomem *scu_base)
> > > if (scu_ctrl & SCU_ENABLE)
> > > return;
> > >
> > > - scu_ctrl |= SCU_ENABLE;
> > > + scu_ctrl |= SCU_ENABLE | SCU_STANDBY_ENABLE;
> >
> > I don't think this bit exists on all revisions of the A9.
>
> Thanks for the info, Will. Is there any side-effect to write the
> standby bit on those revisions which do not define the bit?
The usual question - could the firmware enable this bit before Linux
starts? We already do a read/modify/write sequence here and are only
supposed to write the enable bit as the rest are implementation defined.
--
Catalin
^ permalink raw reply
* [PATCH 2/2] iio: exynos-adc: add experimental touchscreen support
From: Arnd Bergmann @ 2014-07-21 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5158672.dMAnnUQc7Z@wuerfel>
On Monday 21 July 2014 12:23:58 Arnd Bergmann wrote:
>
> Thanks a lot for the review! I'll send out the new version after some build testing.
Here are the changes I did to the adc driver based on the review comments.
I'll start a new thread for the updated version that includes the changes.
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 3d2caea05977..823d7ebc7f52 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -67,6 +67,9 @@
#define ADC_S3C2410_CON_SELMUX(x) (((x)&0x7)<<3)
+/* touch screen always uses channel 0 */
+#define ADC_S3C2410_MUX_TS 0
+
/* ADCTSC Register Bits */
#define ADC_S3C2443_TSC_UD_SEN (1u << 8)
#define ADC_S3C2410_TSC_YM_SEN (1u << 7)
@@ -106,6 +109,7 @@
#define ADC_CON_EN_START (1u << 0)
#define ADC_DATX_PRESSED (1u << 15)
#define ADC_DATX_MASK 0xFFF
+#define ADC_DATY_MASK 0xFFF
#define EXYNOS_ADC_TIMEOUT (msecs_to_jiffies(100))
@@ -123,10 +127,12 @@ struct exynos_adc {
struct completion completion;
- bool read_ts;
u32 value;
- u32 value2;
unsigned int version;
+
+ bool read_ts;
+ u32 ts_x;
+ u32 ts_y;
};
struct exynos_adc_data {
@@ -396,21 +402,14 @@ static int exynos_read_raw(struct iio_dev *indio_dev,
return ret;
}
-static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev,
- struct iio_chan_spec const *chan,
- int *val,
- int *val2,
- long mask)
+static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev, int *x, int *y)
{
struct exynos_adc *info = iio_priv(indio_dev);
unsigned long timeout;
int ret;
- if (mask != IIO_CHAN_INFO_RAW)
- return -EINVAL;
-
mutex_lock(&indio_dev->mlock);
- info->read_ts = 1;
+ info->read_ts = true;
reinit_completion(&info->completion);
@@ -418,7 +417,7 @@ static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev,
ADC_V1_TSC(info->regs));
/* Select the ts channel to be used and Trigger conversion */
- info->data->start_conv(info, 0);
+ info->data->start_conv(info, ADC_S3C2410_MUX_TS);
timeout = wait_for_completion_timeout
(&info->completion, EXYNOS_ADC_TIMEOUT);
@@ -428,12 +427,12 @@ static int exynos_read_s3c64xx_ts(struct iio_dev *indio_dev,
info->data->init_hw(info);
ret = -ETIMEDOUT;
} else {
- *val = info->value;
- *val2 = info->value2;
- ret = IIO_VAL_INT;
+ *x = info->ts_x;
+ *y = info->ts_y;
+ ret = 0;
}
- info->read_ts = 0;
+ info->read_ts = false;
mutex_unlock(&indio_dev->mlock);
return ret;
@@ -445,8 +444,8 @@ static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
/* Read value */
if (info->read_ts) {
- info->value = readl(ADC_V1_DATX(info->regs)) & ADC_DATX_MASK;
- info->value2 = readl(ADC_V1_DATY(info->regs)) & ADC_DATX_MASK;
+ info->ts_x = readl(ADC_V1_DATX(info->regs));
+ info->ts_y = readl(ADC_V1_DATY(info->regs));
writel(ADC_TSC_WAIT4INT | ADC_S3C2443_TSC_UD_SEN, ADC_V1_TSC(info->regs));
} else {
info->value = readl(ADC_V1_DATX(info->regs)) & ADC_DATX_MASK;
@@ -477,7 +476,7 @@ static irqreturn_t exynos_ts_isr(int irq, void *dev_id)
int ret;
do {
- ret =exynos_read_s3c64xx_ts(dev, NULL, &x, &y, IIO_CHAN_INFO_RAW);
+ ret = exynos_read_s3c64xx_ts(dev, &x, &y);
if (ret == -ETIMEDOUT)
break;
@@ -486,11 +485,15 @@ static irqreturn_t exynos_ts_isr(int irq, void *dev_id)
break;
input_report_abs(info->input, ABS_X, x & ADC_DATX_MASK);
- input_report_abs(info->input, ABS_Y, y & ADC_DATX_MASK);
+ input_report_abs(info->input, ABS_Y, y & ADC_DATY_MASK);
input_report_key(info->input, BTN_TOUCH, 1);
input_sync(info->input);
msleep(1);
+
+ /* device may have been closed while touched */
+ if (!info->input->users)
+ return IRQ_HANDLED;
} while (1);
input_report_key(info->input, BTN_TOUCH, 0);
@@ -552,10 +555,28 @@ static int exynos_adc_remove_devices(struct device *dev, void *c)
return 0;
}
+static int exynos_adc_ts_open(struct input_dev *dev)
+{
+ struct exynos_adc *info = input_get_drvdata(dev);
+
+ return request_threaded_irq(info->tsirq, NULL, exynos_ts_isr,
+ 0, "touchscreen", info);
+}
+
+static void exynos_adc_ts_close(struct input_dev *dev)
+{
+ struct exynos_adc *info = input_get_drvdata(dev);
+
+ free_irq(info->tsirq, info);
+}
+
static int exynos_adc_ts_init(struct exynos_adc *info)
{
int ret;
+ if (info->tsirq <= 0)
+ return -ENODEV;
+
info->input = input_allocate_device();
if (!info->input)
return -ENOMEM;
@@ -566,33 +587,17 @@ static int exynos_adc_ts_init(struct exynos_adc *info)
input_set_abs_params(info->input, ABS_X, 0, 0x3FF, 0, 0);
input_set_abs_params(info->input, ABS_Y, 0, 0x3FF, 0, 0);
- /* data from s3c2410_ts driver */
info->input->name = "S3C24xx TouchScreen";
info->input->id.bustype = BUS_HOST;
- info->input->id.vendor = 0xDEAD;
- info->input->id.product = 0xBEEF;
- info->input->id.version = 0x0200;
+ info->input->open = exynos_adc_ts_open;
+ info->input->close = exynos_adc_ts_close;
+
+ input_set_drvdata(info->input, info);
ret = input_register_device(info->input);
- if (ret) {
+ if (ret)
input_free_device(info->input);
- goto err;
- }
-
- if (info->tsirq > 0)
- ret = request_threaded_irq(info->irq, NULL, exynos_ts_isr,
- 0, "touchscreen", info);
- if (ret < 0) {
- dev_err(info->dev, "failed requesting touchsccreen irq, irq = %d\n",
- info->irq);
- goto err_input;
- }
-
- return 0;
-err_input:
- input_unregister_device(info->input);
-err:
return ret;
}
@@ -602,7 +607,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
struct device_node *np = pdev->dev.of_node;
struct iio_dev *indio_dev = NULL;
struct resource *mem;
- bool has_ts;
+ bool has_ts = false;
int ret = -ENODEV;
int irq;
@@ -711,7 +716,10 @@ static int exynos_adc_probe(struct platform_device *pdev)
if (info->data->init_hw)
info->data->init_hw(info);
- has_ts = of_property_read_bool(pdev->dev.of_node, "has-touchscreen");
+ /* leave out any TS related code if unreachable */
+ if (IS_BUILTIN(CONFIG_INPUT) ||
+ (IS_MODULE(CONFIG_INPUT) && config_enabled(MODULE)))
+ has_ts = of_property_read_bool(pdev->dev.of_node, "has-touchscreen");
if (has_ts)
ret = exynos_adc_ts_init(info);
if (ret)
@@ -752,7 +760,7 @@ static int exynos_adc_remove(struct platform_device *pdev)
struct iio_dev *indio_dev = platform_get_drvdata(pdev);
struct exynos_adc *info = iio_priv(indio_dev);
- input_free_device(info->input);
+ input_unregister_device(info->input);
device_for_each_child(&indio_dev->dev, NULL,
exynos_adc_remove_devices);
iio_device_unregister(indio_dev);
^ permalink raw reply related
* [PATCH 2/2] iio: exynos-adc: add experimental touchscreen support
From: Arnd Bergmann @ 2014-07-21 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140720202842.GB18347@core.coreip.homeip.net>
On Sunday 20 July 2014 13:28:42 Dmitry Torokhov wrote:
> On Sun, Jul 20, 2014 at 02:51:37PM +0100, Jonathan Cameron wrote:
> > >>+
> > >>+ do {
> > >>+ ret =exynos_read_s3c64xx_ts(dev, NULL, &x, &y, IIO_CHAN_INFO_RAW);
> > >= exynos
> > >>+ if (ret == -ETIMEDOUT)
> > >>+ break;
> > >>+
> > >>+ pressed = x & y & ADC_DATX_PRESSED;
> > >>+ if (!pressed)
> > >>+ break;
> > >>+
> > >>+ input_report_abs(info->input, ABS_X, x & ADC_DATX_MASK);
> > >>+ input_report_abs(info->input, ABS_Y, y & ADC_DATX_MASK);
> > >>+ input_report_key(info->input, BTN_TOUCH, 1);
> > >>+ input_sync(info->input);
> > >>+
> > >>+ msleep(1);
> > >>+ } while (1);
>
> It would be nice to actually close the device even if someone is
> touching screen. Please implement open/close methods and have them set a
> flag that you would check here.
Ok. I think it's even better to move the request_irq() into the open function,
which will avoid the flag and defer the error handling into the actual opening,
as well as syncing the running irq with the close function.
> > >>+ /* data from s3c2410_ts driver */
> > >>+ info->input->name = "S3C24xx TouchScreen";
> > >>+ info->input->id.bustype = BUS_HOST;
> > >>+ info->input->id.vendor = 0xDEAD;
> > >>+ info->input->id.product = 0xBEEF;
>
> You do not need to fill these entries with fake data.
Ok, I wondered about this, but didn't want to change too much from
the old driver (I changed the version number).
> > >>+ info->input->id.version = 0x0200;
Do I need this?
> > >>@@ -576,6 +728,11 @@ static int exynos_adc_probe(struct platform_device *pdev)
> > >> err_of_populate:
> > >> device_for_each_child(&indio_dev->dev, NULL,
> > >> exynos_adc_remove_devices);
> > >>+ if (has_ts) {
> > >>+ input_unregister_device(info->input);
> > >>+ free_irq(info->tsirq, info);
>
> Are we sure that device is quiesced here and interrupt won't arrive
> between input_unregister_device() and free_irq()? I guess if you
> properly implement open/close it won't matter.
Should be fixed now.
> > >>+err_iio:
> > >> iio_device_unregister(indio_dev);
> > >> err_irq:
> > >> free_irq(info->irq, info);
> > >>@@ -595,9 +752,12 @@ static int exynos_adc_remove(struct platform_device *pdev)
> > >> struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> > >> struct exynos_adc *info = iio_priv(indio_dev);
> > >>
> > >>+ input_free_device(info->input);
>
> Should be unregister, not free.
Ok.
Thanks a lot for the review! I'll send out the new version after some build testing.
Arnd
^ permalink raw reply
* [PATCH v3] ARM: EXYNOS: Fix suspend/resume sequences
From: Tomasz Figa @ 2014-07-21 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C53A1A.6060701@samsung.com>
Hi,
On 15.07.2014 16:26, Tomasz Figa wrote:
> Forgot to CC Daniel and linux-pm. Sorry for the noise.
>
> On 15.07.2014 16:24, Tomasz Figa wrote:
>> Due to recent consolidation of Exynos suspend and cpuidle code, some
>> parts of suspend and resume sequences are executed two times, once from
>> exynos_pm_syscore_ops and then from exynos_cpu_pm_notifier() and thus it
>> breaks suspend, at least on Exynos4-based boards. In addition, simple
>> core power down from a cpuidle driver could, in case of CPU 0 could
>> result in calling functions that are specific to suspend and deeper idle
>> states.
>>
>> This patch fixes the issue by moving those operations outside the CPU PM
>> notifier into suspend and AFTR code paths. This leads to a bit of code
>> duplication, but allows additional code simplification, so in the end
>> more code is removed than added.
>>
>> Signed-off-by: Tomasz Figa <t.figa@samsung.com>
>> ---
>> arch/arm/mach-exynos/pm.c | 164 ++++++++++++++++++---------------------
>> drivers/cpuidle/cpuidle-exynos.c | 25 +-----
>> 2 files changed, 80 insertions(+), 109 deletions(-)
>>
This is an important regression fix for 3.16 and today 3.16-rc6 was
already released...
Kukjin, could you pick up this patch and few others you missed and make
sure that it is included in 3.16-rc7? If you are busy, maybe Arnd or
Olof could take them directly?
Best regards,
Tomasz
^ permalink raw reply
* [PATCH resend v2] arm64: dmi: Add SMBIOS/DMI support
From: Ard Biesheuvel @ 2014-07-21 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721100304.GB12817@arm.com>
On 21 July 2014 12:03, Catalin Marinas <catalin.marinas@arm.com> wrote:
> Ard,
>
> I have some technical questions below before merging this patch.
>
> On Fri, Jul 11, 2014 at 12:46:50PM +0100, Ard Biesheuvel wrote:
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/dmi.h
>> @@ -0,0 +1,41 @@
> [...]
>> +static inline void __iomem *dmi_remap(u64 phys, u64 size)
>> +{
>> + void __iomem *p = efi_lookup_mapped_addr(phys);
>
> When are dmi_remap/dmi_early_remap() called? A quick grep through the
> kernel shows that it is at least called once from dmi_scan_machine().
> The latter is a device_initcall() in this patch. However, the comments
> for efi_lookup_mapped_addr() state that it should only be called between
> efi_enter_virtual_mode and efi_free_boot_services. The latter is invoked
> from an early_initcall(). Could you please clarify which part is wrong
> here?
>
The comment about efi_lookup_mapped_addr() is wrong. Those mappings
are always available.
As the comment is in shared code, I will propose a patch to Matt
Fleming to clarify it.
>> +
>> + /*
>> + * If the mapping spans multiple pages, do a minimal check to ensure
>> + * that the mapping returned by efi_lookup_mapped_addr() covers the
>> + * whole requested range (but ignore potential holes)
>> + */
>> + if ((phys & ~PAGE_MASK) + size > PAGE_SIZE
>> + && (p + size - 1) != efi_lookup_mapped_addr(phys + size - 1))
>> + return NULL;
>> + return p;
>> +}
>> +
>> +/* Reuse existing UEFI mappings for DMI */
>> +#define dmi_alloc(l) kzalloc(l, GFP_KERNEL)
>> +#define dmi_early_remap(x, l) dmi_remap(x, l)
>> +#define dmi_early_unmap(x, l)
>> +#define dmi_unmap(x)
>
> Same questions as above, when are these functions called? Can we not
> just use early_ioremap/ioremap like x86?
>
x86 uses DMI for quirks handling, so there the call to
dmi_scan_machine() needs to occur very early, hence the early versions
of map/unmap.
In our case, DMI/SMBIOS is UEFI only and not executed early, so we can
just reuse the mappings that have already been set up for UEFI by
arm64_enter_virtual_mode().
--
Ard.
^ permalink raw reply
* [RESEND PATCH 0/6] thermal: sti: Add new Thermal driver
From: Lee Jones @ 2014-07-21 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405935299.2455.3.camel@rzhang1-toshiba>
On Mon, 21 Jul 2014, Zhang Rui wrote:
> On Mon, 2014-07-21 at 10:17 +0100, Lee Jones wrote:
> > On Mon, 14 Jul 2014, Lee Jones wrote:
> >
> > > On Mon, 14 Jul 2014, Zhang Rui wrote:
> > >
> > > > On Mon, 2014-07-14 at 14:08 +0100, Lee Jones wrote:
> > > > > On Wed, 09 Jul 2014, Lee Jones wrote:
> > > > > > On Wed, 09 Jul 2014, Zhang Rui wrote:
> > > > > > > On Wed, 2014-07-09 at 13:08 +0100, Lee Jones wrote:
> > > > > > > > On Tue, 24 Jun 2014, Lee Jones wrote:
> > > > > > > >
> > > > > > > > > > I'm re-sending this set, as one of the maintainers' email addresses
> > > > > > > > > > is incorrect in the MAINTAINERS file.
> > > > > > > > > >
> > > > > > > > > > This patchset adds full support for 2 types of Thermal Controllers
> > > > > > > > > > produced by STMicroelectronics. One is a more traditional memory
> > > > > > > > > > mapped variant, the other is controlled solely by system configuration
> > > > > > > > > > registers.
> > > > > > > > >
> > > > > > > > > Any thing from the Thermal guys? Has this set fallen through the gaps?
> > > > > > > >
> > > > > > > > Anything at all? It's been well over a month now.
> > > > > > > >
> > > > > > > Well, for the soc thermal drivers, I'd prefer to take them via Eduardo,
> > > > > > > but as we didn't get any feedback from Eduardo, I will take them.
> > > > > >
> > > > > > Thanks Rui.
> > > > > >
> > > > > > So have you taken all 4 "thermal: sti: *" patches?
> > > > >
> > > > > Have you taken these yet?
> > > >
> > > > Not yet. will do tomorrow.
> >
> > I waited 7 days and still don't see them?
> >
> Done, they're in my local tree and I forgot to push them.
> thanks for the reminder.
Thanks dude.
> > > Perfect, thanks for the update.
> > >
> > > > > I notice that these aren't in -next yet.
> >
>
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox