* [PATCH 8/9] X86: remove redundant cpuidle_idle_call()
From: Nicolas Pitre @ 2014-01-27 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390802904-28399-1-git-send-email-nicolas.pitre@linaro.org>
The core idle loop now takes care of it.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
---
arch/x86/kernel/process.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 3fb8d95ab8..4505e2a950 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -298,10 +298,7 @@ void arch_cpu_idle_dead(void)
*/
void arch_cpu_idle(void)
{
- if (cpuidle_idle_call())
- x86_idle();
- else
- local_irq_enable();
+ x86_idle();
}
/*
--
1.8.4.108.g55ea5f6
^ permalink raw reply related
* [PATCH 9/9] cpu/idle.c: move to sched/idle.c
From: Nicolas Pitre @ 2014-01-27 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390802904-28399-1-git-send-email-nicolas.pitre@linaro.org>
Integration of cpuidle with the scheduler requires that the idle loop be
closely integrated with the scheduler proper. Moving cpu/idle.c into the
sched directory will allow for a smoother integration, and eliminate a
subdirectory which contained only one source file.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
---
kernel/Makefile | 1 -
kernel/cpu/Makefile | 1 -
kernel/sched/Makefile | 2 +-
kernel/{cpu => sched}/idle.c | 0
4 files changed, 1 insertion(+), 3 deletions(-)
delete mode 100644 kernel/cpu/Makefile
rename kernel/{cpu => sched}/idle.c (100%)
diff --git a/kernel/Makefile b/kernel/Makefile
index bc010ee272..6f1c7e5cfc 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -22,7 +22,6 @@ obj-y += sched/
obj-y += locking/
obj-y += power/
obj-y += printk/
-obj-y += cpu/
obj-y += irq/
obj-y += rcu/
diff --git a/kernel/cpu/Makefile b/kernel/cpu/Makefile
deleted file mode 100644
index 59ab052ef7..0000000000
--- a/kernel/cpu/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-y = idle.o
diff --git a/kernel/sched/Makefile b/kernel/sched/Makefile
index 7b621409cf..ac3e0ea68f 100644
--- a/kernel/sched/Makefile
+++ b/kernel/sched/Makefile
@@ -11,7 +11,7 @@ ifneq ($(CONFIG_SCHED_OMIT_FRAME_POINTER),y)
CFLAGS_core.o := $(PROFILING) -fno-omit-frame-pointer
endif
-obj-y += core.o proc.o clock.o cputime.o idle_task.o fair.o rt.o stop_task.o
+obj-y += core.o proc.o clock.o cputime.o idle_task.o idle.o fair.o rt.o stop_task.o
obj-y += wait.o completion.o
obj-$(CONFIG_SMP) += cpupri.o
obj-$(CONFIG_SCHED_AUTOGROUP) += auto_group.o
diff --git a/kernel/cpu/idle.c b/kernel/sched/idle.c
similarity index 100%
rename from kernel/cpu/idle.c
rename to kernel/sched/idle.c
--
1.8.4.108.g55ea5f6
^ permalink raw reply related
* [PATCH v2 5/6] arm64: audit: Add makefile rule to create unistd_32.h for compat syscalls
From: AKASHI Takahiro @ 2014-01-27 6:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123145351.GF27520@arm.com>
Catalin,
On 01/23/2014 11:53 PM, Catalin Marinas wrote:
> On Fri, Jan 17, 2014 at 08:13:18AM +0000, AKASHI Takahiro wrote:
>> generic compat sycall audit (lib/compat_audit.c) requires unistd_32.h
>> for __NR_xyx compat syscall numbers. This is a different file from unistd32.h
>> on arm64 and so it must be generated from unistd32.h.
>>
>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
>> ---
>> arch/arm64/Makefile | 4 ++++
>> arch/arm64/kernel/syscalls/Makefile | 20 ++++++++++++++++++++
>> 2 files changed, 24 insertions(+)
>> create mode 100644 arch/arm64/kernel/syscalls/Makefile
>>
>> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
>> index 2fceb71..6d24f92 100644
>> --- a/arch/arm64/Makefile
>> +++ b/arch/arm64/Makefile
>> @@ -72,6 +72,10 @@ PHONY += vdso_install
>> vdso_install:
>> $(Q)$(MAKE) $(build)=arch/arm64/kernel/vdso $@
>>
>> +# Compat syscall header generation
>> +archheaders:
>> + $(Q)$(MAKE) $(build)=arch/arm64/kernel/syscalls $@
>
> See my other post to the lib/compat_audit.c file. I think that's too
> complex for what you need.
Generation script is getting more complexed than I assumed at first
because some of system call names are a bit inconsistent with native 32-bit
system calls, for example, fchown16 vs. fchown, fchown vs. fchown32.
Now my tentative sed script looks like:
+quiet_cmd_syshdr = SYSHDR $@
+ cmd_syshdr = cat $< | sed -r \
+ -e 's/compat_//' \
+ -e 's/_wrapper//' \
+ -e 's/(sys_[fl]?chown)(\))/\132\)/' \
+ -e 's/(sys_[gs]et)(|e|fs|re|res)(uid\))/\1\2uid32\)/' \
+ -e 's/(sys_[gs]et)(|e|fs|re|res)(gid\))/\1\2gid32\)/' \
+ -e 's/(sys_[gs]etgroups)(\))/\132\)/' \
+ -e 's/(sys_new)(.*)/sys_\2/' \
+ -e 's/sys_mmap_pgoff/sys_mmap2/' \
+ -e 's/(sys_[_a-z]*)16(.*)/\1\2/' \
+ -e 's/^__SYSCALL\((.*),[ ]*sys_([^)].*)\).*/\#define __NR_\2 \1/p;d' \
+ | grep -v __NR_ni_syscall > $@
So, yeah, I agree with you now.
-Takahiro AKASHI
^ permalink raw reply
* [PATCH] ARM: imx: add cpuidle support for i.mx6sl
From: Shawn Guo @ 2014-01-27 6:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c3acb9ee4a574bbaa1cdc5fa77050408@BY2PR03MB315.namprd03.prod.outlook.com>
On Fri, Jan 24, 2014 at 02:05:09AM +0000, Anson.Huang at freescale.com wrote:
> Hi, Tobias
> Yes, the root cause is the reschedule introduced by the usleep, for our internal release, we use busy loop for PLL wait lock, just removing the usleep is not good enough, as the PLL hardware may need about 60~90us to lock, during this period, there will be no clock output in PLL. So, we need to figure out a way to fix this issue, either using busy loop instead of usleep or access the ccm register to adjust ARM divider instead of calling clk APIs.
>
Yes, since imx6sl_set_wait_clk() is provided by imx6sl clock driver,
it's reasonable to just access register than going through clk API.
Shawn
^ permalink raw reply
* GPIO triggers kernel reboot
From: Heiko Schocher @ 2014-01-27 6:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <371E240E6FC1D44DA5E51EE9DCDCB7845E5EA0E1@NA-MBX-01.mgc.mentorg.com>
Hello John,
Am 25.01.2014 21:24, schrieb Mehaffey, John:
>> -----Original Message-----
>> From: linux-embedded-owner at vger.kernel.org
>> [mailto:linux-embedded-owner at vger.kernel.org] On Behalf Of Heiko
>> Schocher
>> Sent: Saturday, January 25, 2014 8:03 AM
>> To: linux-embedded at vger.kernel.org
>> Cc: Wolfgang Denk; linux-arm-kernel at lists.infradead.org
>> Subject: GPIO triggers kernel reboot
>>
>> Hello all,
>>
>> is it possible to reboot current mainline kernel triggered from a GPIO in kernel space?
>>
>> If not, how can be done this, so that it has a chance to go into mainline?
>>
>> Thanks for any suggestions
>>
>> bye,
>> Heiko
>
> Hi Heiko,
> Call kexec() from the GPIO driver.
> It will take some effort to get it right :)
Thanks for your answer!
Hmm.. but has this a chance to go into mainline?
> Or if a simple reboot is all that you want, examine the several reboot APIs in kernel/reboot.c
A current implementation from a customer is for an arm, am335x based board
to add in board setup code:
ret = request_irq(OMAP_GPIO_IRQ(RESET_BUTTON_IRQ_GPIO)
, (irq_handler_t)arm_pm_restart, IRQF_TRIGGER_LOW, "reset button", NULL);
and as I want to bring this board to mainline, I think this is not
an acceptable/good way ... or?
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* GPIO triggers kernel reboot
From: Heiko Schocher @ 2014-01-27 6:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALLGbRKK_ZcOB6nAiV67njrphXMQXN7Y2s81n5k3PWoSVrsrUw@mail.gmail.com>
Hello Steve,
Thanks for your answer!
Am 25.01.2014 20:39, schrieb Steve deRosier:
> Hi Heiko,
>
> It's certainly possible, and it's also easily done from user-space.
> Something like this is more policy than function. It's also a potential
> security issue. As such I'd expect it highly unlikely that the kernel
> maintainers would allow it to go upstream. Give it a try though.
Ok, thats what I also think ...
> I'd approach this from user-space. Add in the gpio-keys driver and use the
> input-event-daemon to trigger a reboot. Super easy.
Yes, that was also my suggestion, but is there a way to do this without
user space usage in a generic way?
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* [PATCH] ARM: imx: add cpuidle support for i.mx6sl
From: Anson.Huang at freescale.com @ 2014-01-27 6:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127061434.GA3135@S2101-09.ap.freescale.net>
OK, then I will generate a patch of accessing clk register directly to fix this issue, otherwise, we will meet it when the cpufreq driver and cpuidle driver are merged.
Best Regards.
Anson Huang
?
Freescale Semiconductor Shanghai
Tel:021-28937058
>-----Original Message-----
>From: Shawn Guo [mailto:shawn.guo at linaro.org]
>Sent: Monday, January 27, 2014 2:15 PM
>To: Huang Yongcai-B20788
>Cc: John Tobias; <linux-arm-kernel@lists.infradead.org>
>Subject: Re: [PATCH] ARM: imx: add cpuidle support for i.mx6sl
>
>On Fri, Jan 24, 2014 at 02:05:09AM +0000, Anson.Huang at freescale.com wrote:
>> Hi, Tobias
>> Yes, the root cause is the reschedule introduced by the usleep, for our
>internal release, we use busy loop for PLL wait lock, just removing the usleep
>is not good enough, as the PLL hardware may need about 60~90us to lock, during
>this period, there will be no clock output in PLL. So, we need to figure out a
>way to fix this issue, either using busy loop instead of usleep or access the
>ccm register to adjust ARM divider instead of calling clk APIs.
>>
>
>Yes, since imx6sl_set_wait_clk() is provided by imx6sl clock driver, it's
>reasonable to just access register than going through clk API.
>
>Shawn
^ permalink raw reply
* [PATCH v3 04/15] watchdog: orion: Handle IRQ
From: Ezequiel Garcia @ 2014-01-27 6:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DE84A6.6090909@roeck-us.net>
Hi Guenter,
On Tue, Jan 21, 2014 at 06:31:02AM -0800, Guenter Roeck wrote:
[..]
> > @@ -131,6 +138,19 @@ static int orion_wdt_probe(struct platform_device *pdev)
> > if (!wdt_reg)
> > return -ENOMEM;
> >
> > + irq = platform_get_irq(pdev, 0);
> > + if (irq > 0) {
>
> 0 is a valid interrupt number, and platform_get_irq returns an error code on errors.
> Should be >= 0.
>
I'm revisiting this one. I believe this is not the hardware interrupt
number, but the one mapped into virq space. So, 0 is not a valid
interrupt number.
Right?
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 04/15] watchdog: orion: Handle IRQ
From: Guenter Roeck @ 2014-01-27 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127063040.GA17506@localhost>
On 01/26/2014 10:30 PM, Ezequiel Garcia wrote:
> Hi Guenter,
>
> On Tue, Jan 21, 2014 at 06:31:02AM -0800, Guenter Roeck wrote:
> [..]
>>> @@ -131,6 +138,19 @@ static int orion_wdt_probe(struct platform_device *pdev)
>>> if (!wdt_reg)
>>> return -ENOMEM;
>>>
>>> + irq = platform_get_irq(pdev, 0);
>>> + if (irq > 0) {
>>
>> 0 is a valid interrupt number, and platform_get_irq returns an error code on errors.
>> Should be >= 0.
>>
>
> I'm revisiting this one. I believe this is not the hardware interrupt
> number, but the one mapped into virq space. So, 0 is not a valid
> interrupt number.
>
> Right?
>
Hi,
If so, the entire interrupt numbering scheme appears broken. Conceptually it should
not make a difference where the interrupt is coming from. If the virq system
returns 0 for invalid (non-configured) interrupts, and non-configured 'real'
interrupts are reported as -ENXIO, all bets are off. How would a driver know
what to expect ? And how would one be expected to review such non-deterministic
code ?
FWIW, platform_get_irq() does return -ENXIO for invalid interrupts. If there
is an independent notion of "0 is an invalid interrupt", it is well hidden.
Anyway, if you think the driver should treat 0 as invalid interrupt, go ahead.
Who am I to know. Just please don't use my Reviewed-by in this case.
Thanks,
Guenter
^ permalink raw reply
* [PATCH v2 0/3] ASoC: atmel_ssc_dai: add option to choose clock
From: Bo Shen @ 2014-01-27 6:55 UTC (permalink / raw)
To: linux-arm-kernel
When SSC work in slave mode, the clock can come from TK pin and also
can come from RK pin, this is hardware design decided. So, make it
available to choose where the clock from.
Changes in v2:
- using "-" replace "_" in binding document
Bo Shen (3):
ASoC: atmel_ssc_dai: make option to choose clock
ASoC: atmel_wm8904: make it available to choose clock
Binding: atmel-wm8904: add option to choose clock
Documentation/devicetree/bindings/sound/atmel-wm8904.txt | 6 ++++++
sound/soc/atmel/atmel_ssc_dai.c | 16 ++++++++++++----
sound/soc/atmel/atmel_ssc_dai.h | 1 +
sound/soc/atmel/atmel_wm8904.c | 10 ++++++++++
4 files changed, 29 insertions(+), 4 deletions(-)
--
1.8.5.2
^ permalink raw reply
* [PATCH v2 1/3] ASoC: atmel_ssc_dai: make option to choose clock
From: Bo Shen @ 2014-01-27 6:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390805726-1841-1-git-send-email-voice.shen@atmel.com>
When SSC works in slave mode, according to the hardware design, the
clock can get from TK pin, also can get from RK pin. So, add one
parameter to choose where the clock from.
Signed-off-by: Bo Shen <voice.shen@atmel.com>
---
Changes in v2: None
sound/soc/atmel/atmel_ssc_dai.c | 16 ++++++++++++----
sound/soc/atmel/atmel_ssc_dai.h | 1 +
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
index 8697ced..03eb0be 100644
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -340,6 +340,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
int id = dai->id;
+ struct snd_soc_card *card = dai->card;
struct atmel_ssc_info *ssc_p = &ssc_info[id];
struct atmel_pcm_dma_params *dma_params;
int dir, channels, bits;
@@ -347,6 +348,9 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
int start_event;
int ret;
+ ssc_p->clk_from_rk_pin =
+ ((struct atmel_ssc_info *)(card->drvdata))->clk_from_rk_pin;
+
/*
* Currently, there is only one set of dma params for
* each direction. If more are added, this code will
@@ -466,7 +470,8 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
| SSC_BF(RCMR_START, start_event)
| SSC_BF(RCMR_CKI, SSC_CKI_RISING)
| SSC_BF(RCMR_CKO, SSC_CKO_NONE)
- | SSC_BF(RCMR_CKS, SSC_CKS_CLOCK);
+ | SSC_BF(RCMR_CKS, ssc_p->clk_from_rk_pin ?
+ SSC_CKS_PIN : SSC_CKS_CLOCK);
rfmr = SSC_BF(RFMR_FSEDGE, SSC_FSEDGE_POSITIVE)
| SSC_BF(RFMR_FSOS, SSC_FSOS_NONE)
@@ -481,7 +486,8 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
| SSC_BF(TCMR_START, start_event)
| SSC_BF(TCMR_CKI, SSC_CKI_FALLING)
| SSC_BF(TCMR_CKO, SSC_CKO_NONE)
- | SSC_BF(TCMR_CKS, SSC_CKS_PIN);
+ | SSC_BF(TCMR_CKS, ssc_p->clk_from_rk_pin ?
+ SSC_CKS_CLOCK : SSC_CKS_PIN);
tfmr = SSC_BF(TFMR_FSEDGE, SSC_FSEDGE_POSITIVE)
| SSC_BF(TFMR_FSDEN, 0)
@@ -550,7 +556,8 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
| SSC_BF(RCMR_START, SSC_START_RISING_RF)
| SSC_BF(RCMR_CKI, SSC_CKI_RISING)
| SSC_BF(RCMR_CKO, SSC_CKO_NONE)
- | SSC_BF(RCMR_CKS, SSC_CKS_PIN);
+ | SSC_BF(RCMR_CKS, ssc_p->clk_from_rk_pin ?
+ SSC_CKS_PIN : SSC_CKS_CLOCK);
rfmr = SSC_BF(RFMR_FSEDGE, SSC_FSEDGE_POSITIVE)
| SSC_BF(RFMR_FSOS, SSC_FSOS_NONE)
@@ -565,7 +572,8 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
| SSC_BF(TCMR_START, SSC_START_RISING_RF)
| SSC_BF(TCMR_CKI, SSC_CKI_FALLING)
| SSC_BF(TCMR_CKO, SSC_CKO_NONE)
- | SSC_BF(TCMR_CKS, SSC_CKS_PIN);
+ | SSC_BF(RCMR_CKS, ssc_p->clk_from_rk_pin ?
+ SSC_CKS_CLOCK : SSC_CKS_PIN);
tfmr = SSC_BF(TFMR_FSEDGE, SSC_FSEDGE_POSITIVE)
| SSC_BF(TFMR_FSDEN, 0)
diff --git a/sound/soc/atmel/atmel_ssc_dai.h b/sound/soc/atmel/atmel_ssc_dai.h
index b1f08d5..f147895 100644
--- a/sound/soc/atmel/atmel_ssc_dai.h
+++ b/sound/soc/atmel/atmel_ssc_dai.h
@@ -113,6 +113,7 @@ struct atmel_ssc_info {
unsigned short cmr_div;
unsigned short tcmr_period;
unsigned short rcmr_period;
+ bool clk_from_rk_pin;
struct atmel_pcm_dma_params *dma_params[2];
struct atmel_ssc_state ssc_state;
};
--
1.8.5.2
^ permalink raw reply related
* [PATCH v2 2/3] ASoC: atmel_wm8904: make it available to choose clock
From: Bo Shen @ 2014-01-27 6:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390805726-1841-1-git-send-email-voice.shen@atmel.com>
Make it available to choose the clock from TK pin or RK pin. This
is hardware design decided.
Signed-off-by: Bo Shen <voice.shen@atmel.com>
---
Changes in v2: None
sound/soc/atmel/atmel_wm8904.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/sound/soc/atmel/atmel_wm8904.c b/sound/soc/atmel/atmel_wm8904.c
index b4e3690..9346410 100644
--- a/sound/soc/atmel/atmel_wm8904.c
+++ b/sound/soc/atmel/atmel_wm8904.c
@@ -108,6 +108,7 @@ static int atmel_asoc_wm8904_dt_init(struct platform_device *pdev)
struct device_node *codec_np, *cpu_np;
struct snd_soc_card *card = &atmel_asoc_wm8904_card;
struct snd_soc_dai_link *dailink = &atmel_asoc_wm8904_dailink;
+ struct atmel_ssc_info *ssc_info;
int ret;
if (!np) {
@@ -115,6 +116,15 @@ static int atmel_asoc_wm8904_dt_init(struct platform_device *pdev)
return -EINVAL;
}
+ ssc_info = devm_kzalloc(&pdev->dev, sizeof(*ssc_info), GFP_KERNEL);
+ if (!ssc_info)
+ return -ENOMEM;
+
+ ssc_info->clk_from_rk_pin =
+ of_property_read_bool(np, "atmel,clk-from-rk-pin");
+
+ card->drvdata = (void *)ssc_info;
+
ret = snd_soc_of_parse_card_name(card, "atmel,model");
if (ret) {
dev_err(&pdev->dev, "failed to parse card name\n");
--
1.8.5.2
^ permalink raw reply related
* [PATCH v2 3/3] Binding: atmel-wm8904: add option to choose clock
From: Bo Shen @ 2014-01-27 6:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390805726-1841-1-git-send-email-voice.shen@atmel.com>
Add the option to choose clock on which pin input to SSC (as slave).
Default is on TK pin to SSC, add "atmel,clk-from-rk-pin" option to
specify the clock is on RK pin to SSC.
Signed-off-by: Bo Shen <voice.shen@atmel.com>
---
Changes in v2:
- using "-" replace "_" in binding document
Documentation/devicetree/bindings/sound/atmel-wm8904.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/atmel-wm8904.txt b/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
index 8bbe50c..2d86e2b 100644
--- a/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
+++ b/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
@@ -33,6 +33,12 @@ Required properties:
Optional properties:
- pinctrl-names, pinctrl-0: Please refer to pinctrl-bindings.txt
+ - atmel,clk-from-rk-pin: bool property.
+ - When SSC works in slave mode, according to the hardware design, the
+ clock can get from TK pin, and also can get from RK pin. So, add
+ this parameter to choose where the clock from.
+ - By default the clock is from TK pin, if the clock from RK pin, this
+ property is needed.
Example:
sound {
--
1.8.5.2
^ permalink raw reply related
* [alsa-devel] [PATCH v2 1/3] ASoC: atmel_ssc_dai: make option to choose clock
From: Lars-Peter Clausen @ 2014-01-27 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390805726-1841-2-git-send-email-voice.shen@atmel.com>
On 01/27/2014 07:55 AM, Bo Shen wrote:
> When SSC works in slave mode, according to the hardware design, the
> clock can get from TK pin, also can get from RK pin. So, add one
> parameter to choose where the clock from.
>
> Signed-off-by: Bo Shen <voice.shen@atmel.com>
> ---
> Changes in v2: None
>
> sound/soc/atmel/atmel_ssc_dai.c | 16 ++++++++++++----
> sound/soc/atmel/atmel_ssc_dai.h | 1 +
> 2 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
> index 8697ced..03eb0be 100644
> --- a/sound/soc/atmel/atmel_ssc_dai.c
> +++ b/sound/soc/atmel/atmel_ssc_dai.c
> @@ -340,6 +340,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
> struct snd_soc_dai *dai)
> {
> int id = dai->id;
> + struct snd_soc_card *card = dai->card;
> struct atmel_ssc_info *ssc_p = &ssc_info[id];
> struct atmel_pcm_dma_params *dma_params;
> int dir, channels, bits;
> @@ -347,6 +348,9 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
> int start_event;
> int ret;
>
> + ssc_p->clk_from_rk_pin =
> + ((struct atmel_ssc_info *)(card->drvdata))->clk_from_rk_pin;
This is a layering violation. The DAI driver is not supposed to make any
assumptions what drvdata is attached to the card. Use the set_sysclk API to
set the source clock.
- Lars
^ permalink raw reply
* [PATCH v2 1/7] cpufreq: cpufreq-cpu0: allow optional safe voltage during frequency transitions
From: Shawn Guo @ 2014-01-27 7:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390047057-2239-2-git-send-email-thomas.ab@samsung.com>
On Sat, Jan 18, 2014 at 05:40:51PM +0530, Thomas Abraham wrote:
> From: Thomas Abraham <thomas.ab@samsung.com>
>
> On some platforms such as the Samsung Exynos, changing the frequency
> of the CPU clock requires changing the frequency of the PLL that is
> supplying the CPU clock. To change the frequency of the PLL, the CPU
> clock is temporarily reparented to another parent clock.
>
> The clock frequency of this temporary parent clock could be much higher
> than the clock frequency of the PLL at the time of reparenting. Due
> to the temporary increase in the CPU clock speed, the CPU (and any other
> components in the CPU clock domain such as dividers, mux, etc.) have to
> to be operated at a higher voltage level, called the safe voltage level.
> This patch adds optional support to temporarily switch to a safe voltage
> level during CPU frequency transitions.
>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
> ---
> .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 7 ++++
The devicetree list should be copied for this change.
> drivers/cpufreq/cpufreq-cpu0.c | 37 +++++++++++++++++--
> 2 files changed, 40 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
> index f055515..37453ab 100644
> --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
> @@ -19,6 +19,12 @@ Optional properties:
> - cooling-min-level:
> - cooling-max-level:
> Please refer to Documentation/devicetree/bindings/thermal/thermal.txt.
> +- safe-opp: Certain platforms require that during a opp transition,
> + a system should not go below a particular opp level. For such systems,
> + this property specifies the minimum opp to be maintained during the
> + opp transitions. The safe-opp value is a tuple with first element
> + representing the safe frequency and the second element representing the
> + safe voltage.
>
> Examples:
>
> @@ -36,6 +42,7 @@ cpus {
> 396000 950000
> 198000 850000
> >;
> + safe-opp = <396000 950000>
> clock-latency = <61036>; /* two CLK32 periods */
> #cooling-cells = <2>;
> cooling-min-level = <0>;
> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
> index 0c12ffc..075d3d1 100644
> --- a/drivers/cpufreq/cpufreq-cpu0.c
> +++ b/drivers/cpufreq/cpufreq-cpu0.c
> @@ -27,6 +27,8 @@
>
> static unsigned int transition_latency;
> static unsigned int voltage_tolerance; /* in percentage */
> +static unsigned long safe_frequency;
> +static unsigned long safe_voltage;
>
> static struct device *cpu_dev;
> static struct clk *cpu_clk;
> @@ -64,17 +66,30 @@ static int cpu0_set_target(struct cpufreq_policy *policy, unsigned int index)
> volt_old = regulator_get_voltage(cpu_reg);
> }
>
> - pr_debug("%u MHz, %ld mV --> %u MHz, %ld mV\n",
> + pr_debug("\n\n%u MHz, %ld mV --> %u MHz, %ld mV\n",
This is an unnecessary change?
Otherwise,
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Shawn
> old_freq / 1000, volt_old ? volt_old / 1000 : -1,
> new_freq / 1000, volt ? volt / 1000 : -1);
>
> /* scaling up? scale voltage before frequency */
> - if (!IS_ERR(cpu_reg) && new_freq > old_freq) {
> + if (!IS_ERR(cpu_reg) && new_freq > old_freq &&
> + new_freq >= safe_frequency) {
> ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
> if (ret) {
> pr_err("failed to scale voltage up: %d\n", ret);
> return ret;
> }
> + } else if (!IS_ERR(cpu_reg) && old_freq < safe_frequency) {
> + /*
> + * the scaled up voltage level for the new_freq is lower
> + * than the safe voltage level. so set safe_voltage
> + * as the intermediate voltage level and revert it
> + * back after the frequency has been changed.
> + */
> + ret = regulator_set_voltage_tol(cpu_reg, safe_voltage, tol);
> + if (ret) {
> + pr_err("failed to set safe voltage: %d\n", ret);
> + return ret;
> + }
> }
>
> ret = clk_set_rate(cpu_clk, freq_exact);
> @@ -86,7 +101,8 @@ static int cpu0_set_target(struct cpufreq_policy *policy, unsigned int index)
> }
>
> /* scaling down? scale voltage after frequency */
> - if (!IS_ERR(cpu_reg) && new_freq < old_freq) {
> + if (!IS_ERR(cpu_reg) &&
> + (new_freq < old_freq || new_freq < safe_frequency)) {
> ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
> if (ret) {
> pr_err("failed to scale voltage down: %d\n", ret);
> @@ -116,6 +132,8 @@ static struct cpufreq_driver cpu0_cpufreq_driver = {
>
> static int cpu0_cpufreq_probe(struct platform_device *pdev)
> {
> + const struct property *prop;
> + struct dev_pm_opp *opp;
> struct device_node *np;
> int ret;
>
> @@ -165,13 +183,24 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
> goto out_put_node;
> }
>
> + prop = of_find_property(np, "safe-opp", NULL);
> + if (prop) {
> + if (prop->value && (prop->length / sizeof(u32)) == 2) {
> + const __be32 *val;
> + val = prop->value;
> + safe_frequency = be32_to_cpup(val++);
> + safe_voltage = be32_to_cpup(val);
> + } else {
> + pr_err("invalid safe-opp level specified\n");
> + }
> + }
> +
> of_property_read_u32(np, "voltage-tolerance", &voltage_tolerance);
>
> if (of_property_read_u32(np, "clock-latency", &transition_latency))
> transition_latency = CPUFREQ_ETERNAL;
>
> if (!IS_ERR(cpu_reg)) {
> - struct dev_pm_opp *opp;
> unsigned long min_uV, max_uV;
> int i;
>
> --
> 1.6.6.rc2
>
^ permalink raw reply
* [PATCH v3 04/15] watchdog: orion: Handle IRQ
From: Ezequiel Garcia @ 2014-01-27 7:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E5FFCB.5000802@roeck-us.net>
On Sun, Jan 26, 2014 at 10:42:19PM -0800, Guenter Roeck wrote:
> On 01/26/2014 10:30 PM, Ezequiel Garcia wrote:
> > Hi Guenter,
> >
> > On Tue, Jan 21, 2014 at 06:31:02AM -0800, Guenter Roeck wrote:
> > [..]
> >>> @@ -131,6 +138,19 @@ static int orion_wdt_probe(struct platform_device *pdev)
> >>> if (!wdt_reg)
> >>> return -ENOMEM;
> >>>
> >>> + irq = platform_get_irq(pdev, 0);
> >>> + if (irq > 0) {
> >>
> >> 0 is a valid interrupt number, and platform_get_irq returns an error code on errors.
> >> Should be >= 0.
> >>
> >
> > I'm revisiting this one. I believe this is not the hardware interrupt
> > number, but the one mapped into virq space. So, 0 is not a valid
> > interrupt number.
> >
> > Right?
> >
>
> If so, the entire interrupt numbering scheme appears broken. Conceptually it should
> not make a difference where the interrupt is coming from. If the virq system
> returns 0 for invalid (non-configured) interrupts, and non-configured 'real'
> interrupts are reported as -ENXIO, all bets are off. How would a driver know
> what to expect ? And how would one be expected to review such non-deterministic
> code ?
>
I wouldn't know that much. I'm just pointing out that '0' doesn't seem
to be a valid IRQ number in this context (i.e. virq space).
> FWIW, platform_get_irq() does return -ENXIO for invalid interrupts. If there
> is an independent notion of "0 is an invalid interrupt", it is well hidden.
>
Yes, AFAICS platform_get_irq() returns a negative error or a positive
irq number. I fail to see how it's able return '0' (of course, I can be
wrong).
> Anyway, if you think the driver should treat 0 as invalid interrupt, go ahead.
> Who am I to know. Just please don't use my Reviewed-by in this case.
>
Quite frankly not sure how to handle this best. A quick grep through the
code doesn't help either: lots of drivers treat 0 as a valid interrupt
and lots treat it as invalid. So I guess it doesn't really matter...
Can someone shed a light on this?
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] arm64: mm: fix the function name in comment of cpu_do_switch_mm
From: Jingoo Han @ 2014-01-27 7:19 UTC (permalink / raw)
To: linux-arm-kernel
Fix the function name of comment of cpu_do_switch_mm,
because cpu_do_switch_mm is the correct name.
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
arch/arm64/mm/proc.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index bed1f1d..1333e6f 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -150,7 +150,7 @@ ENDPROC(cpu_do_resume)
#endif
/*
- * cpu_switch_mm(pgd_phys, tsk)
+ * cpu_do_switch_mm(pgd_phys, tsk)
*
* Set the translation table base pointer to be pgd_phys.
*
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/4] ARM: dts: cm-fx6: add SATA support
From: Shawn Guo @ 2014-01-27 7:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390320812-25100-3-git-send-email-grinberg@compulab.co.il>
On Tue, Jan 21, 2014 at 06:13:30PM +0200, Igor Grinberg wrote:
> Enable SATA on cm-fx6.
>
> Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
> ---
> arch/arm/boot/dts/imx6q-cm-fx6.dts | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6q-cm-fx6.dts b/arch/arm/boot/dts/imx6q-cm-fx6.dts
> index 94cc6b5..07f90a5 100644
> --- a/arch/arm/boot/dts/imx6q-cm-fx6.dts
> +++ b/arch/arm/boot/dts/imx6q-cm-fx6.dts
> @@ -69,3 +69,7 @@
> pinctrl-0 = <&pinctrl_uart4>;
> status = "okay";
> };
> +
> +&sata {
> + status = "okay";
> +};
Please sort these labeled nodes alphabetically.
Shawn
> --
> 1.8.3.2
>
^ permalink raw reply
* [PATCH v4 0/3] serial: fsl_lpuart: add DMA support
From: Shawn Guo @ 2014-01-27 7:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390363773-24108-1-git-send-email-yao.yuan@freescale.com>
On Wed, Jan 22, 2014 at 12:09:30PM +0800, Yuan Yao wrote:
> Changed in v4:
> - Move dma properties from dtsi to dts.
Why this change? DMA is a SoC level resource rather than board one.
Shawn
^ permalink raw reply
* GPIO triggers kernel reboot
From: Arnaud Patard (Rtp) @ 2014-01-27 8:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E5FB1A.2020205@denx.de>
Heiko Schocher <hs@denx.de> writes:
> Hello Steve,
>
> Thanks for your answer!
>
> Am 25.01.2014 20:39, schrieb Steve deRosier:
>> Hi Heiko,
>>
>> It's certainly possible, and it's also easily done from user-space.
>> Something like this is more policy than function. It's also a potential
>> security issue. As such I'd expect it highly unlikely that the kernel
>> maintainers would allow it to go upstream. Give it a try though.
>
> Ok, thats what I also think ...
>
>> I'd approach this from user-space. Add in the gpio-keys driver and use the
>> input-event-daemon to trigger a reboot. Super easy.
>
> Yes, that was also my suggestion, but is there a way to do this without
> user space usage in a generic way?
I think that you can register an input handler for that. iirc, there was
a driver doing something similar for apm.
Arnaud
^ permalink raw reply
* [PATCH 0/2] DT updates for Hummingboard and new Cubox-i
From: Lucas Stach @ 2014-01-27 8:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMhp1S-XJjGZQBPmH7RFT_pobSFLTBT+4fSKdZ3zhukEhA@mail.gmail.com>
Am Freitag, den 24.01.2014, 19:44 -0800 schrieb Olof Johansson:
> Hi,
>
> On Fri, Jan 24, 2014 at 7:09 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> > On Sun, Jan 19, 2014 at 10:52:46AM -0800, Olof Johansson wrote:
> >> I'm well aware that the DT branch has not been merged, and that's because
> >> there has been no consensus from DT maintainers on the massive rework
> >> you did as the base of the branch.
> >
> > I guess the 'massive rework' you're talking about is the patch series
> > that begins with 'ARM: dts: imx6qdl: make pinctrl nodes board specific'?
> > If so, I hope you would agree that we're trying to solve a real
> > problem [1], even though the solution does not look like the best to
> > you.
> >
> > So which specific part of the solution are you objecting to? Those
> > MX6QDL_*_PINGRP macros defined in imx6qdl-pingrp.h? If that's the
> > case, I can send a follow-up patch to kill the macros by filling in the
> > pin group definitions directly. The pros is that the pin group
> > definitions for given board will be more intuitive, and the cons is that
> > the change set will be even more massive, because the same multi-lines
> > pin group definitions will be duplicated in multiple board dts files,
> > which use the same group of pins for given device.
> >
> > Or any other better idea?
>
> I haven't heard any other maintainers being positive to this change.
> Not Linus W, as the pinctrl maintainer, and none of the DT
> maintainers. I asked for their review, which should mean acks or
> general approval from them, and I haven't seen any come in. Or did I
> miss it?
>
Just to throw in some opinion: we at Pengutronix use the new macros for
some time now and we pretty much like them. We are even in the process
of pushing them to our bootloader. They do not obfuscate things beyond
the status quo, as we always needed some form of grouping. Now it's just
a macro, before it was a phandle.
Also those are not changing ABI, so if people really hate them (which I
seriously doubt) we can always revert or change them to something other
later. So IMHO I would really like the change to go in as is.
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH 1/9] ARM: get rid of arch_cpu_idle_prepare()
From: Daniel Lezcano @ 2014-01-27 8:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390802904-28399-2-git-send-email-nicolas.pitre@linaro.org>
On 01/27/2014 07:08 AM, Nicolas Pitre wrote:
> ARM and ARM64 are the only two architectures implementing
> arch_cpu_idle_prepare() simply to call local_fiq_enable().
>
> We have secondary_start_kernel() already calling local_fiq_enable() and
> this is done a second time in arch_cpu_idle_prepare() in that case. And
> enabling FIQs has nothing to do with idling the CPU to start with.
>
> So let's introduce init_fiq_boot_cpu() to take care of FIQs on the boot
> CPU and remove arch_cpu_idle_prepare(). This is now done a bit earlier
> at late_initcall time but this shouldn't make a difference in practice
> i.e. when FIQs are actually used.
>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>
Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> ---
> arch/arm/kernel/process.c | 5 -----
> arch/arm/kernel/setup.c | 7 +++++++
> 2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
> index 92f7b15dd2..725b8c95e0 100644
> --- a/arch/arm/kernel/process.c
> +++ b/arch/arm/kernel/process.c
> @@ -142,11 +142,6 @@ static void default_idle(void)
> local_irq_enable();
> }
>
> -void arch_cpu_idle_prepare(void)
> -{
> - local_fiq_enable();
> -}
> -
> void arch_cpu_idle_enter(void)
> {
> ledtrig_cpu(CPU_LED_IDLE_START);
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 987a7f5bce..d027b1a6fe 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -789,6 +789,13 @@ static int __init init_machine_late(void)
> }
> late_initcall(init_machine_late);
>
> +static int __init init_fiq_boot_cpu(void)
> +{
> + local_fiq_enable();
> + return 0;
> +}
> +late_initcall(init_fiq_boot_cpu);
> +
> #ifdef CONFIG_KEXEC
> static inline unsigned long long get_total_mem(void)
> {
>
--
<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/9] ARM64: get rid of arch_cpu_idle_prepare()
From: Daniel Lezcano @ 2014-01-27 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390802904-28399-3-git-send-email-nicolas.pitre@linaro.org>
On 01/27/2014 07:08 AM, Nicolas Pitre wrote:
> ARM and ARM64 are the only two architectures implementing
> arch_cpu_idle_prepare() simply to call local_fiq_enable().
>
> We have secondary_start_kernel() already calling local_fiq_enable() and
> this is done a second time in arch_cpu_idle_prepare() in that case. And
> enabling FIQs has nothing to do with idling the CPU to start with.
>
> So let's introduce init_fiq_boot_cpu() to take care of FIQs on the boot
> CPU and remove arch_cpu_idle_prepare(). This is now done a bit earlier
> at late_initcall time but this shouldn't make a difference in practice
> given that FIQs are not currently used on ARM64.
>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>
Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> ---
> arch/arm64/kernel/process.c | 5 -----
> arch/arm64/kernel/setup.c | 7 +++++++
> 2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> index de17c89985..f6c733da67 100644
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -84,11 +84,6 @@ EXPORT_SYMBOL_GPL(pm_power_off);
> void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
> EXPORT_SYMBOL_GPL(arm_pm_restart);
>
> -void arch_cpu_idle_prepare(void)
> -{
> - local_fiq_enable();
> -}
> -
> /*
> * This is our default idle handler.
> */
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index bd9bbd0e44..259557983a 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -255,6 +255,13 @@ static int __init arm64_device_init(void)
> }
> arch_initcall(arm64_device_init);
>
> +static int __init init_fiq_boot_cpu(void)
> +{
> + local_fiq_enable();
> + return 0;
> +}
> +late_initcall(init_fiq_boot_cpu);
> +
> static DEFINE_PER_CPU(struct cpu, cpu_data);
>
> static int __init topology_init(void)
>
--
<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 3/9] idle: no more arch_cpu_idle_prepare() users
From: Daniel Lezcano @ 2014-01-27 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390802904-28399-4-git-send-email-nicolas.pitre@linaro.org>
On 01/27/2014 07:08 AM, Nicolas Pitre wrote:
> ... so we can get rid of it entirely.
>
> Signed-off-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> ---
> include/linux/cpu.h | 1 -
> kernel/cpu/idle.c | 2 --
> 2 files changed, 3 deletions(-)
>
> diff --git a/include/linux/cpu.h b/include/linux/cpu.h
> index 03e235ad1b..218fab7521 100644
> --- a/include/linux/cpu.h
> +++ b/include/linux/cpu.h
> @@ -221,7 +221,6 @@ void cpu_idle(void);
> void cpu_idle_poll_ctrl(bool enable);
>
> void arch_cpu_idle(void);
> -void arch_cpu_idle_prepare(void);
> void arch_cpu_idle_enter(void);
> void arch_cpu_idle_exit(void);
> void arch_cpu_idle_dead(void);
> diff --git a/kernel/cpu/idle.c b/kernel/cpu/idle.c
> index 988573a9a3..4e327e211b 100644
> --- a/kernel/cpu/idle.c
> +++ b/kernel/cpu/idle.c
> @@ -52,7 +52,6 @@ static inline int cpu_idle_poll(void)
> }
>
> /* Weak implementations for optional arch specific functions */
> -void __weak arch_cpu_idle_prepare(void) { }
> void __weak arch_cpu_idle_enter(void) { }
> void __weak arch_cpu_idle_exit(void) { }
> void __weak arch_cpu_idle_dead(void) { }
> @@ -136,6 +135,5 @@ void cpu_startup_entry(enum cpuhp_state state)
> boot_init_stack_canary();
> #endif
> __current_set_polling();
> - arch_cpu_idle_prepare();
> cpu_idle_loop();
> }
>
--
<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
* GPIO triggers kernel reboot
From: Geert Uytterhoeven @ 2014-01-27 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8761p5hmni.fsf@lebrac.rtp-net.org>
On Mon, Jan 27, 2014 at 9:08 AM, Arnaud Patard
<arnaud.patard@rtp-net.org> wrote:
>>> It's certainly possible, and it's also easily done from user-space.
>>> Something like this is more policy than function. It's also a potential
>>> security issue. As such I'd expect it highly unlikely that the kernel
>>> maintainers would allow it to go upstream. Give it a try though.
>>
>> Ok, thats what I also think ...
>>
>>> I'd approach this from user-space. Add in the gpio-keys driver and use the
>>> input-event-daemon to trigger a reboot. Super easy.
>>
>> Yes, that was also my suggestion, but is there a way to do this without
>> user space usage in a generic way?
>
> I think that you can register an input handler for that. iirc, there was
> a driver doing something similar for apm.
According to Documentation/sysctl/kernel.txt, the default for the
"ctrl-alt-del" input is to just reboot.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ 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