On Sun, 10 Feb 2013 19:58:12 +0100, Andrew Lunn and...@lunn.ch wrote:
+* QNAP Power Off
+
+QNAP NAS devices have a microcontroller controlling the main power
+supply. This microcontroller is connected to UART1 of the Kirkwood and
+Orion5x SoCs. Sending the charactor 'A', at 19200
+* QNAP Power Off
+
+QNAP NAS devices have a microcontroller controlling the main power
+supply. This microcontroller is connected to UART1 of the Kirkwood and
+Orion5x SoCs. Sending the charactor 'A', at 19200 baud, tells the
+microcontroller to turn the power off. This driver adds a
On Fri, 28 Dec 2012 13:47:24 +0100, Andrew Lunn and...@lunn.ch wrote:
Move the Kirkwood cpuidle driver out of arch/arm/mach-kirkwood and
into drivers/cpuidle. Convert the driver into a platform driver and
add a device tree binding. Add a DT node to instantiate the driver for
boards converted
Hello Andrew,
Le 12/28/12 13:47, Andrew Lunn a écrit :
Move the Kirkwood cpuidle driver out of arch/arm/mach-kirkwood and
into drivers/cpuidle. Convert the driver into a platform driver and
add a device tree binding. Add a DT node to instantiate the driver for
boards converted to DT, and a
Move the Kirkwood cpuidle driver out of arch/arm/mach-kirkwood and
into drivers/cpuidle. Convert the driver into a platform driver and
add a device tree binding. Add a DT node to instantiate the driver for
boards converted to DT, and a platform data for old style boards.
Signed-off-by: Andrew
On 12/28/2012 06:47 AM, Andrew Lunn wrote:
Move the Kirkwood cpuidle driver out of arch/arm/mach-kirkwood and
into drivers/cpuidle. Convert the driver into a platform driver and
add a device tree binding. Add a DT node to instantiate the driver for
boards converted to DT, and a platform data
On Fri, Dec 28, 2012 at 08:18:42AM -0600, Rob Herring wrote:
On 12/28/2012 06:47 AM, Andrew Lunn wrote:
Move the Kirkwood cpuidle driver out of arch/arm/mach-kirkwood and
into drivers/cpuidle. Convert the driver into a platform driver and
add a device tree binding. Add a DT node to
On Fri, Dec 28, 2012 at 03:32:08PM +0100, Florian Fainelli wrote:
Hello Andrew,
Le 12/28/12 13:47, Andrew Lunn a ??crit :
Move the Kirkwood cpuidle driver out of arch/arm/mach-kirkwood and
into drivers/cpuidle. Convert the driver into a platform driver and
add a device tree binding. Add a
On 12/28/2012 08:35 AM, Andrew Lunn wrote:
On Fri, Dec 28, 2012 at 08:18:42AM -0600, Rob Herring wrote:
On 12/28/2012 06:47 AM, Andrew Lunn wrote:
Move the Kirkwood cpuidle driver out of arch/arm/mach-kirkwood and
into drivers/cpuidle. Convert the driver into a platform driver and
add a
On Fri, Dec 28, 2012 at 08:55:31AM -0600, Rob Herring wrote:
On 12/28/2012 08:35 AM, Andrew Lunn wrote:
On Fri, Dec 28, 2012 at 08:18:42AM -0600, Rob Herring wrote:
On 12/28/2012 06:47 AM, Andrew Lunn wrote:
Move the Kirkwood cpuidle driver out of arch/arm/mach-kirkwood and
into
On 12/28/2012 09:49 AM, Andrew Lunn wrote:
On Fri, Dec 28, 2012 at 08:55:31AM -0600, Rob Herring wrote:
On 12/28/2012 08:35 AM, Andrew Lunn wrote:
On Fri, Dec 28, 2012 at 08:18:42AM -0600, Rob Herring wrote:
On 12/28/2012 06:47 AM, Andrew Lunn wrote:
Move the Kirkwood cpuidle driver out of
The block of registers is for controlling the SDRAM. Its not really a
MFD. The cpuidle code is putting the SDRAM controller into self
refresh mode and then doing a WFI.
It is multi-function in the sense that multiple subsystems needing to
access shared registers. If you have ECC, then
On Friday 28 December 2012 09:44 PM, Rob Herring wrote:
On 12/28/2012 09:49 AM, Andrew Lunn wrote:
On Fri, Dec 28, 2012 at 08:55:31AM -0600, Rob Herring wrote:
On 12/28/2012 08:35 AM, Andrew Lunn wrote:
On Fri, Dec 28, 2012 at 08:18:42AM -0600, Rob Herring wrote:
On 12/28/2012 06:47 AM,
On 12/28/2012 10:38 AM, Andrew Lunn wrote:
The block of registers is for controlling the SDRAM. Its not really a
MFD. The cpuidle code is putting the SDRAM controller into self
refresh mode and then doing a WFI.
It is multi-function in the sense that multiple subsystems needing to
access
Putting DDR/SDRAM into self refresh means, you no longer have RAM
available to execute and any code CPU needs to execute after that has
to be executed either from lock down cache with no cache evictions or
from some internal on chip memory with caches disabled to avoid accesses
to DDR. Not
Is this single CPU or multi-cpu machine ?
Its a uniprocessor.
Even though the cpu_do_idle()
has just couple of instructions, there can be lot more happening in
background especially with multi masters system. It might be safe if the
single CPU is the only master accessing DDR. In
On Friday 28 December 2012 11:26 PM, Andrew Lunn wrote:
Is this single CPU or multi-cpu machine ?
Its a uniprocessor.
That should work then.
Even though the cpu_do_idle()
has just couple of instructions, there can be lot more happening in
background especially with multi masters system. It
17 matches
Mail list logo
