On Saturday, August 17, 2013 01:46:55 PM Toshi Kani wrote:
> lock_device_hotplug() was recently introduced to serialize CPU & Memory
> online/offline and hotplug operations, along with sysfs online interface
> restructure (commit 4f3549d7). With this new locking scheme,
> cpu_hotplug_driver_lock()
On Saturday, August 17, 2013 01:46:59 PM Toshi Kani wrote:
> cpu_hotplug_driver_lock() serializes CPU online/offline operations
> when ARCH_CPU_PROBE_RELEASE is set. This lock interface is no longer
> necessary with the following reason:
>
> - lock_device_hotplug() now protects CPU online/offlin
On Saturday, August 17, 2013 01:46:57 PM Toshi Kani wrote:
> lock_device_hotplug() serializes CPU & Memory online/offline and hotplug
> operations. However, this lock is not held in the debug interfaces below
> that initiate CPU online/offline operations.
>
> - _debug_hotplug_cpu(), cpu0 hotplug
On Saturday, August 17, 2013 01:46:58 PM Toshi Kani wrote:
> Commit d7c53c9e enabled ARCH_CPU_PROBE_RELEASE on x86 in order to
> serialize CPU online/offline operations. Although it is the config
> option to enable CPU hotplug test interfaces, probe & release, it is
> also the option to enable cpu
On Saturday, August 17, 2013 01:46:56 PM Toshi Kani wrote:
> _debug_hotplug_cpu() is a debug interface that puts cpu0 offline during
> boot-up when CONFIG_DEBUG_HOTPLUG_CPU0 is set. After cpu0 is put offline
> in this interface, however, /sys/devices/system/cpu/cpu0/online still
> shows 1 (online)
Bhushan Bharat-R65777 writes:
> You should get rid of this by changing spin_lock/unlock() in
> fsl_sata_set_irq_coalescing() to spin_lock_irqsave/restore()
I can verify that the suggested change removes the lockdep warning.
The below patch is against 3.9.7 and has been tested on hardware with
th
On Sat, Aug 17, 2013 at 01:46:57PM -0600, Toshi Kani wrote:
> lock_device_hotplug() serializes CPU & Memory online/offline and hotplug
> operations. However, this lock is not held in the debug interfaces below
> that initiate CPU online/offline operations.
>
> - _debug_hotplug_cpu(), cpu0 hotplu
On Sunday 18 of August 2013 08:09:36 Benjamin Herrenschmidt wrote:
> On Sat, 2013-08-17 at 12:50 +0200, Tomasz Figa wrote:
> > I wonder how would this handle uniprocessor ARM (pre-v7) cores, for
> > which
> > the updated bindings[1] define #address-cells = <0> and so no reg
> > property.
> >
> > [
On Sat, 2013-08-17 at 12:50 +0200, Tomasz Figa wrote:
> I wonder how would this handle uniprocessor ARM (pre-v7) cores, for
> which
> the updated bindings[1] define #address-cells = <0> and so no reg
> property.
>
> [1] - http://thread.gmane.org/gmane.linux.ports.arm.kernel/260795
Why did you d
On Fri, 2013-08-16 at 06:04 -0500, Kumar Gala wrote:
> The 44x low level code needs to handle exception stacks properly for
> this to work. Since its possible to have a critical exception occur
> while in a normal exception level, you have to have proper saving of
> additional register state and a
Commit d7c53c9e enabled ARCH_CPU_PROBE_RELEASE on x86 in order to
serialize CPU online/offline operations. Although it is the config
option to enable CPU hotplug test interfaces, probe & release, it is
also the option to enable cpu_hotplug_driver_lock() as well. Therefore,
this option had to be e
lock_device_hotplug() was recently introduced to serialize CPU & Memory
online/offline and hotplug operations, along with sysfs online interface
restructure (commit 4f3549d7). With this new locking scheme,
cpu_hotplug_driver_lock() is redundant and is no longer necessary.
This patchset makes sure
lock_device_hotplug() serializes CPU & Memory online/offline and hotplug
operations. However, this lock is not held in the debug interfaces below
that initiate CPU online/offline operations.
- _debug_hotplug_cpu(), cpu0 hotplug test interface enabled by
CONFIG_DEBUG_HOTPLUG_CPU0.
- cpu_probe
cpu_hotplug_driver_lock() serializes CPU online/offline operations
when ARCH_CPU_PROBE_RELEASE is set. This lock interface is no longer
necessary with the following reason:
- lock_device_hotplug() now protects CPU online/offline operations,
including the probe & release interfaces enabled by
_debug_hotplug_cpu() is a debug interface that puts cpu0 offline during
boot-up when CONFIG_DEBUG_HOTPLUG_CPU0 is set. After cpu0 is put offline
in this interface, however, /sys/devices/system/cpu/cpu0/online still
shows 1 (online).
This patch fixes _debug_hotplug_cpu() to update dev->offline whe
On Fri, Aug 16, 2013 at 3:15 PM, Luck, Tony wrote:
>> Needs testing with erst backend, efivars and persistent ram.
>
> Tested against ERST - works fine for me now.
>
> Need to stare at the code to see if there are any more bits that could be
> cleaned up.
>
> Thanks for addressing my issues from
On Fri, Aug 16, 2013 at 6:19 AM, Aruna Balakrishnaiah
wrote:
> In pstore write, add character 'C'(compressed) or 'D'(decompressed)
> in the header while writing to Ram persistent buffer. In pstore read,
> read the header and update the 'compressed' flag accordingly.
>
> Signed-off-by: Aruna Balakr
Bharat, greetings --
Bhushan Bharat-R65777 writes:
> You should get rid of this by changing spin_lock/unlock() in
> fsl_sata_set_irq_coalescing() to spin_lock_irqsave/restore()
I'll do that -- thanks!
Looks like linux-next still has plain spin_lock, not the irqsave variant.
Is this something
On Saturday 17 of August 2013 17:14:09 Sascha Hauer wrote:
> On Sat, Aug 17, 2013 at 02:56:11PM +0200, Tomasz Figa wrote:
> > Hi Nicolin,
> >
> > > First, you are right that all the properties you just commented are
> > > software configurations. And I got the point that device tree now
> > > can'
On Saturday 17 of August 2013 16:53:16 Sascha Hauer wrote:
> On Sat, Aug 17, 2013 at 02:28:04PM +0200, Tomasz Figa wrote:
> > > > > Also I would make this option required. Use a dummy clock for
> > > > > mux
> > > > > inputs that are grounded for a specific SoC.
> > > >
> > > > Some clocks are not
On Sat, Aug 17, 2013 at 05:13:20PM +0200, Tomasz Figa wrote:
> On Saturday 17 of August 2013 17:00:02 Sascha Hauer wrote:
> > On Sat, Aug 17, 2013 at 02:26:40PM +0200, Tomasz Figa wrote:
> > > > You mean tx<0-7>.
> > > >
> > > > Also I would make this option required. Use a dummy clock for mux
> >
On Saturday 17 of August 2013 17:00:02 Sascha Hauer wrote:
> On Sat, Aug 17, 2013 at 02:26:40PM +0200, Tomasz Figa wrote:
> > > You mean tx<0-7>.
> > >
> > > Also I would make this option required. Use a dummy clock for mux
> > > inputs that are grounded for a specific SoC.
> >
> > Why do you nee
On Sat, Aug 17, 2013 at 02:56:11PM +0200, Tomasz Figa wrote:
> Hi Nicolin,
> > First, you are right that all the properties you just commented are
> > software configurations. And I got the point that device tree now
> > can't allow any software configuration even if the actual hardware
> > connect
On Sat, Aug 17, 2013 at 02:26:40PM +0200, Tomasz Figa wrote:
> > You mean tx<0-7>.
> >
> > Also I would make this option required. Use a dummy clock for mux inputs
> > that are grounded for a specific SoC.
>
> Why do you need a dummy clock?
>
> The driver can simply try to grab all the possible
On Sat, Aug 17, 2013 at 02:28:04PM +0200, Tomasz Figa wrote:
> > > > Also I would make this option required. Use a dummy clock for mux
> > > > inputs that are grounded for a specific SoC.
> > >
> > > Some clocks are not from CCM and we haven't defined in imx6q-clk.txt,
> > > so in most cases we ca
Hi Nicolin,
On Friday 16 of August 2013 12:43:31 Nicolin Chen wrote:
> Hi Tomasz,
>
>Thank you for the comments.
You're welcome.
>I'll revise them in v6.
>And below is my reply for you comments.
Thanks for your reply.
> On Thu, Aug 15, 2013 at 02:18:22PM +0200, Tomasz Figa wrote:
On Friday 16 of August 2013 12:11:51 Sascha Hauer wrote:
> On Fri, Aug 16, 2013 at 05:53:58PM +0800, Nicolin Chen wrote:
> > On Fri, Aug 16, 2013 at 10:56:32AM +0200, Sascha Hauer wrote:
> > > > "tx<0-8>" OptionalTx clock source for spdif
playback.
> > > >
> > > >
On Friday 16 of August 2013 10:56:32 Sascha Hauer wrote:
> On Fri, Aug 16, 2013 at 04:01:25PM +0800, Nicolin Chen wrote:
> > Hi Sascha,
> >
> >Thank you for the detailed comments.
> >
> > On Fri, Aug 16, 2013 at 09:08:18AM +0200, Sascha Hauer wrote:
> > > Which of them the driver should use i
Hi Sudeep,
This looks good to me overall, but I have one more question inline.
On Friday 16 of August 2013 18:39:50 Sudeep KarkadaNagesha wrote:
> From: Sudeep KarkadaNagesha
>
> Currently different drivers requiring to access cpu device node are
> parsing the device tree themselves. Since the
29 matches
Mail list logo
