On Wed, Jul 24, 2013 at 2:21 PM, wrote:
> From: Hongbo Zhang
>
> Hi Vinod, Dan, Scott and Leo, please have a look at these V2 patches.
>
Looks good now after rounds of review.
Acked-by: Li Yang
>
> Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch
> set
> adds suppor
Hi Linus !
Here is a series of powerpc fixes. It's a bit big, mostly because of the
series of 11 "EEH" patches from Gavin. The EEH (Our IBM specific
PCI/PCIe Enhanced Error Handling) code had been rotting for a while and
this merge window saw a significant rework & fixing of it by Gavin Shan.
How
> On Fri, Jul 19, 2013 at 6:46 AM, Gerhard Sittig wrote:
> > So: No, not having to fiddle with DMA stuff when doing PCI need
> > not be a problem, it's actually expected. But since a DMA engine
> > might be involved (that's just not under your command), the
> > accompanying problems may arise.
On 07/23/2013 07:36 PM, Michael Ellerman wrote:
> On Tue, Jul 23, 2013 at 02:31:41PM +0530, Deepthi Dharwar wrote:
>> This patch implements a back-end cpuidle driver for
>> powernv calling power7_nap and snooze idle states.
>> This can be extended by adding more idle states
>> in the future to the
Hi,
On Wed, Jul 24, 2013 at 11:04:50AM +0530, Viresh Kumar wrote:
> On 24 July 2013 01:54, Aaro Koskinen wrote:
> > The patch also enables to use ondemand governor on the latter.
>
> How? I can't see anything obvious here. :(
It replaces CPUFREQ_ETERNAL with a proper value on older PowerMacs.
o
> -Original Message-
> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> ow...@vger.kernel.org] On Behalf Of Wang Dongsheng-B40534
> Sent: Wednesday, July 24, 2013 10:26 AM
> To: Rafael J. Wysocki
> Cc: daniel.lezc...@linaro.org; linux...@vger.kernel.org; linuxppc-
> d...@lists.ozl
On 24 July 2013 15:48, Aaro Koskinen wrote:
> Hi,
>
> On Wed, Jul 24, 2013 at 11:04:50AM +0530, Viresh Kumar wrote:
>> On 24 July 2013 01:54, Aaro Koskinen wrote:
>> > The patch also enables to use ondemand governor on the latter.
>>
>> How? I can't see anything obvious here. :(
>
> It replaces C
* Benjamin Herrenschmidt (b...@kernel.crashing.org) wrote:
> On Tue, 2013-07-23 at 07:33 -0500, Robert Jennings wrote:
> > When an associativity level change is found for one thread, the
> > siblings threads need to be updated as well. This is done today
> > for PRRN in stage_topology_update() but
When an associativity level change is found for one thread, the
siblings threads need to be updated as well. This is done today
for PRRN in stage_topology_update() but is missing for VPHN in
update_cpu_associativity_changes_mask().
All threads should be updated to move to the new node. Without t
On Wed, Jul 24, 2013 at 10:00:05AM -0500, Robert Jennings wrote:
> When an associativity level change is found for one thread, the
> siblings threads need to be updated as well. This is done today
> for PRRN in stage_topology_update() but is missing for VPHN in
> update_cpu_associativity_changes_m
On Tue, Jul 23, 2013 at 9:27 PM, Benjamin Herrenschmidt
wrote:
> CONFIG_NOT_COHERENT_CACHE will do it for you (in
> arch/powerpc/kernel/dma.c) provided the driver does the right things vs.
> the DMA accessors but afaik e1000 does.
Well, when I went to make the changes I noted a few things. First
> This breaks the vdso for e500v1/v2 (userspace dies with SIGILL), since
> KBUILD_CFLAGS doesn't get used when building asm files, and the vdso
> uses mftbu/mftbl which are not being assembled to the form that
> e500v1/v2 support.
>
> We should be setting -mcpu=whatever and -msoft-float in both CF
On 07/24/2013 11:25:52 AM, Udma Catalin-Dan-B32721 wrote:
> This breaks the vdso for e500v1/v2 (userspace dies with SIGILL),
since
> KBUILD_CFLAGS doesn't get used when building asm files, and the vdso
> uses mftbu/mftbl which are not being assembled to the form that
> e500v1/v2 support.
>
> We
[+cc linux-pci]
On Tue, Jul 23, 2013 at 8:24 PM, Gavin Shan wrote:
> Since pcibios_release_device() called by pci_stop_and_remove_bus_device()
> has removed the EEH cache, we needn't do that again.
>
> Cc: Bjorn Helgaas
> Acked-by: Bjorn Helgaas
> Signed-off-by: Gavin Shan
I'll be happy to me
The current implementation of memory hot add and remove for powerpc is broken.
This patch set both corrects this issue and updates the memory hot add and
remove code for powerpc so that it can be done properly in the kernel.
The first two patches update the powerpc hot add and remove code to work
Previous commit 46723bfa540... introduced a new config option
HAVE_BOOTMEM_INFO_NODE that ended up breaking memory hot-remove for powerpc
when sparse vmemmap is not defined.
This patch defines HAVE_BOOTMEM_INFO_NODE for powerpc and adds the call to
register_page_bootmem_info_node. Without this pat
Memory I/O resources need to be marked as busy or else we cannot remove
them when doing memory hot remove.
Signed-off-by: Nathan Fontenot
---
arch/powerpc/mm/mem.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/arch/powerpc/mm/mem.c
===
When doing memory hot add via the 'probe' interface in sysfs we do not
need to loop through and add memory one section at a time. I think this
was originally done for powerpc, but is not needed. This patch removes
the loop and just calls add_memory for all of the memory to be added.
Signed-off-by:
Provide a sysfs interface to hot remove memory.
This patch updates the sysfs interface for hot add of memory to also
provide a sysfs interface to hot remove memory. The use of this interface
is controlled with the ARCH_MEMORY_PROBE config option, currently used
by x86 and powerpc. This patch also
In order to allow architectures or other subsystems to do any needed
work prior to hot adding or hot removing memory the memory notifier
chain should be updated to provide notifications of these events.
This patch adds the notifications for memory hot add and hot remove.
Signed-off-by: Nathan Fon
In order to properly hot add and remove memory for powerpc the arch
specific callouts need to now complete all of the required work to
fully add or remove the memory.
With this update we can also remove the handler for memory node add
because the powerpc arch specific memory add handler will do al
Add memory hot add/remove notifier handlers for powerpc/pseries.
This patch allows the powerpc/pseries platforms to perform memory DLPAR
int the kernel. The handlers for add and remove do the work of
acquiring/releasing the memory to firmware and updating the device tree.
This is only used when m
Remove the update_node handler for powerpc/pseries.
Now that we can do memory dlpar in the kernel we no longer need the of
update node notifier to update the ibm,dynamic-memory property of the
ibm,dynamic-reconfiguration-memory node. This work is now handled by
the memory notification handlers for
On 07/23/2013 08:30:32 AM, Michael Ellerman wrote:
On Fri, Jul 19, 2013 at 05:59:30PM -0500, Scott Wood wrote:
> On 07/17/2013 11:00:45 PM, Anton Blanchard wrote:
> >
> >Hi Scott,
> >
> >> What specifically should I do to test it?
> >
> >Could you double check perf annotate works? I'm 99% sure it
On 07/24/2013 01:21:07 AM, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this
patch add
the device tree nodes for them.
Signed-off-by: Hongbo Zhang
---
.../devicetree/bindings/powerpc/fsl/dma.txt| 66
+++
On 07/24/2013 01:21:08 AM, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang
This patch adds support to 8-channel DMA engine, thus the driver
works for both
the new 8-channel and the legacy 4-channel DMA engines.
Signed-off-by: Hongbo Zhang
---
drivers/dma/Kconfig |9 +
dr
On 07/24/2013 01:21:09 AM, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang
The variable cookie is initialized in a list_for_each_entry loop,
if(unlikely)
the list is empty, this variable will be used uninitialized, so we
get a gcc
compiling warning about this. This patch fixes this def
On 07/24/2013 04:39:59 AM, Alexander Graf wrote:
On 24.07.2013, at 11:35, Gleb Natapov wrote:
> On Wed, Jul 24, 2013 at 11:21:11AM +0200, Alexander Graf wrote:
>>> Are not we going to use page_is_ram() from
e500_shadow_mas2_attrib() as Scott commented?
>>
>> rWhy aren't we using page_is_ram
On Wed, 2013-07-24 at 12:02 -0600, Bjorn Helgaas wrote:
> [+cc linux-pci]
>
> On Tue, Jul 23, 2013 at 8:24 PM, Gavin Shan wrote:
> > Since pcibios_release_device() called by pci_stop_and_remove_bus_device()
> > has removed the EEH cache, we needn't do that again.
> >
> > Cc: Bjorn Helgaas
> > Ac
On Wed, 2013-07-24 at 08:39 -0700, Peter LaDow wrote:
> A bit of history that may help. We were using an e100 (an 82559)
> part, but Intel EOL'd that part so we picked up the 82540EP (which
> they have also recently EOL'd). The e100 driver uses a different DMA
> model. It uses pci_map_single/pci
Hi Scott,
> I'm not really sure what it's supposed to look like when "perf
> annotate" works. It spits a bunch of unreadable[1]
> dark-blue-on-black assembly code at me, all with "0.00 :" in the left
> column.
>
> Oh, wait -- some lines have "100.00 : " on the left, in
> even-more-unreadabl
On Tue, 23 Jul 2013 12:22:59 +1000 Alexey Kardashevskiy wrote:
> Ping, anyone, please?
ew, you top-posted.
> Ben needs ack from any of MM people before proceeding with this patch. Thanks!
For what? The three lines of comment in page-flags.h? ack :)
Manipulating page->_count directly is con
On Wed, 2013-07-24 at 10:00 -0500, Robert Jennings wrote:
> When an associativity level change is found for one thread, the
> siblings threads need to be updated as well. This is done today
> for PRRN in stage_topology_update() but is missing for VPHN in
> update_cpu_associativity_changes_mask().
On Wed, 2013-07-24 at 15:43 -0700, Andrew Morton wrote:
> For what? The three lines of comment in page-flags.h? ack :)
>
> Manipulating page->_count directly is considered poor form. Don't
> blame us if we break your code ;)
>
> Actually, the manipulation in realmode_get_page() duplicates the
On Thu, 2013-07-25 at 08:34 +1000, Anton Blanchard wrote:
> > Apart from the annoying colors, is there anything specific I should
> > be looking for? Some sort of error message, or output that actually
> > makes sense?
>
> Thanks for testing! Ben, I think the patch is good to go.
Sent it yesterd
When an associativity level change is found for one thread, the
siblings threads need to be updated as well. This is done today
for PRRN in stage_topology_update() but is missing for VPHN in
update_cpu_associativity_changes_mask(). This patch will correctly
update all thread siblings during a top
Add voltage-range support in esdhc of T4, So we can choose
to read voltages from dts file as one optional.
If we can get a valid voltage-range from device node, we use
this voltage as the final voltage support. Else we still read
from capacity or from other provider.
Signed-off-by: Haijun Zhang
S
We have a bunch of CONFIG_PPC_EARLY_DEBUG_* options that are intended
for bringup/debug only. They hard wire a machine specific udbg backend
very early on (before we even probe the platform), and use whatever
tricks are available on each machine/cpu to be able to get some kind
of output out there e
On 07/25/2013 03:33 AM, Scott Wood wrote:
On 07/24/2013 01:21:09 AM, hongbo.zh...@freescale.com wrote:
From: Hongbo Zhang
The variable cookie is initialized in a list_for_each_entry loop,
if(unlikely)
the list is empty, this variable will be used uninitialized, so we
get a gcc
compiling war
On Thu, 2013-07-25 at 12:12 +1000, Benjamin Herrenschmidt wrote:
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -10,7 +10,7 @@
> * 2 of the License, or (at your option) any later version.
> */
>
> -#undef DEBUG
> +#define DEBUG
Ooops... sent the wrong
We feed the entire DMI table into the random pool to provide
better random data during early boot, so do the same with the
flattened device tree.
Signed-off-by: Anton Blanchard
---
It might be worth doing this somewhere common, but the only place
I could find (unflatten_device_tree) is almost c
On Wed, Jul 24, 2013 at 10:09:33AM +0800, Chen Gang wrote:
> On 07/24/2013 09:16 AM, Michael Ellerman wrote:
> > On Wed, Jul 24, 2013 at 08:28:07AM +0800, Chen Gang wrote:
> >> > On 07/23/2013 09:44 PM, Michael Ellerman wrote:
> >>> > > On Mon, Jul 22, 2013 at 12:21:16PM +0530, Srivatsa S. Bhat wro
On Thu, Jul 25, 2013 at 12:51:22PM +1000, Anton Blanchard wrote:
>
> We feed the entire DMI table into the random pool to provide
> better random data during early boot, so do the same with the
> flattened device tree.
>
> Signed-off-by: Anton Blanchard
> ---
>
> It might be worth doing this so
On 07/25/2013 11:15 AM, Michael Ellerman wrote:
> On Wed, Jul 24, 2013 at 10:09:33AM +0800, Chen Gang wrote:
>> > On 07/24/2013 09:16 AM, Michael Ellerman wrote:
>>> > > On Wed, Jul 24, 2013 at 08:28:07AM +0800, Chen Gang wrote:
> > >> > On 07/23/2013 09:44 PM, Michael Ellerman wrote:
>>> >
Hi Michael,
> But why not put the initcall in drivers/of/fdt.c, that way it's not
> early but it's still common ?
Good idea! How does this look? So long as it happens before
module_init(rand_initialize) we should be good.
Anton
--
We feed the entire DMI table into the random pool to provide
be
On Thu, Jul 25, 2013 at 02:30:31PM +1000, Anton Blanchard wrote:
>
> Hi Michael,
>
> > But why not put the initcall in drivers/of/fdt.c, that way it's not
> > early but it's still common ?
>
> Good idea! How does this look? So long as it happens before
> module_init(rand_initialize) we should be
On Thu, 2013-07-25 at 13:15 +1000, Michael Ellerman wrote:
> > But for API (also include the internal API), at least, better to always
> > provide the return value which can indicate failure by negative number
> > (if succeed can return the meanness value, e.g. the number of cpus).
>
> Are we stil
On 07/25/2013 01:16 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-07-25 at 13:15 +1000, Michael Ellerman wrote:
>>> But for API (also include the internal API), at least, better to always
>>> provide the return value which can indicate failure by negative number
>>> (if succeed can return the me
On Thu, 2013-07-25 at 13:24 +0800, Chen Gang wrote:
> For an extern function, if the performance is not sensible, better to
> have the return value which can indicate the failure with the negative
> number.
The return value is meaningless.
We don't have a good way to handle it. It has no defined
On Thu, 2013-07-25 at 15:51 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2013-07-25 at 13:24 +0800, Chen Gang wrote:
> > For an extern function, if the performance is not sensible, better to
> > have the return value which can indicate the failure with the negative
> > number.
>
> The return val
On Wed, Jul 24, 2013 at 3:08 PM, Benjamin Herrenschmidt
wrote:
> No, they resolve to the same thing under the hood. Did you do other
> changes ? Could it be another unrelated kernel bug causing something
> like use-after-free of network buffer or similar oddity unrelated to the
> network driver ?
On 07/25/2013 01:51 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-07-25 at 13:24 +0800, Chen Gang wrote:
>> For an extern function, if the performance is not sensible, better to
>> have the return value which can indicate the failure with the negative
>> number.
>
> The return value is meaningl
On 07/25/2013 02:03 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-07-25 at 15:51 +1000, Benjamin Herrenschmidt wrote:
>> On Thu, 2013-07-25 at 13:24 +0800, Chen Gang wrote:
>>> For an extern function, if the performance is not sensible, better to
>>> have the return value which can indicate the
53 matches
Mail list logo
