On Thu, 2012-07-19 at 09:42 -0500, Seth Jennings wrote:
> This patch adds the driver for interacting with the 842
> compression accelerator on IBM Power7+ systems.
...
> +struct nx842_slentry {
> + unsigned long ptr; /* Absolute address (use virt_to_abs()) */
> /+unsigned long len;
> +};
On 06/14/2012 08:05 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2012-06-14 at 18:41 -0500, Scott Wood wrote:
>> - Like on e5500, the linear mapping is bolted, so we don't need the
>>overhead of supporting nested tlb misses.
>>
>> Note that hardware tablewalk does not work in rev1 of e6500.
>>
This patch enables compression engine support in the
architecture vector. This causes the Power hypervisor
to allow access to the nx comrpession accelerator.
Signed-off-by: Seth Jennings
---
arch/powerpc/kernel/prom_init.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
This patch creates a new submenu for the NX cryptographic
hardware accelerator and breaks the NX options into their own
Kconfig file under drivers/crypto/nx/Kconfig.
This will permit additional NX functionality to be easily
and more cleanly added in the future without touching
drivers/crypto/Makef
This is a continuation of support for the Power7+ in-Nest
hardware accelerator.
https://lkml.org/lkml/2012/4/12/223
This patchset adds the hardware driver and the cryptographic
driver for hardware accelerated compression, which uses a
hardware-optimized algorithm named 842.
The hardware driver h
This patch add the 842 cryptographic API driver that
submits compression requests to the 842 hardware compression
accelerator driver (nx-compress).
If the hardware accelerator goes offline for any reason
(dynamic disable, migration, etc...), this driver will use LZO
as a software failover for all
On Jul 19, 2012, at 5:28 AM, Claudiu Manoil wrote:
> The sram_offset parameter represents a physical address
> and should be of type phys_addr_t. As part of this fix,
> the extraction of sram_params is being cleaned-up and
> fixed.
> This patch fixes now the case when the offset value of
> 0xfff0
The sram_offset parameter represents a physical address
and should be of type phys_addr_t. As part of this fix,
the extraction of sram_params is being cleaned-up and
fixed.
This patch fixes now the case when the offset value of
0xfff0 was being rejected by the driver (returning
-EINVAL), althou
On Wed, Jul 18, 2012 at 6:12 PM, Yasuaki Ishimatsu
wrote:
> The patch adds __remove_pages() to remove_memory(). Then the range of
> phys_start_pfn argument and nr_pages argument in __remove_pagse() may
> have different zone. So zone argument is removed from __remove_pages()
> and __remove_pages()
Hi Yasuaki,
On Wed, Jul 18, 2012 at 6:05 PM, Yasuaki Ishimatsu
wrote:
> remove_memory() does not remove memory but just offlines memory. The patch
> changes name of it to offline_memory().
Since offline_memory() just align the start/end pfn and there is no
matched online_memory() function,
i thi
At 07/19/2012 05:45 PM, Wen Congyang Wrote:
> At 07/18/2012 06:16 PM, Yasuaki Ishimatsu Wrote:
>> All pages of virtual mapping in removed memory cannot be freed, since some
>> pages
>> used as PGD/PUD includes not only removed memory but also other memory. So
>> the
>> patch checks whether page c
Hi Wen,
2012/07/19 18:45, Wen Congyang wrote:
> At 07/18/2012 06:16 PM, Yasuaki Ishimatsu Wrote:
>> All pages of virtual mapping in removed memory cannot be freed, since some
>> pages
>> used as PGD/PUD includes not only removed memory but also other memory. So
>> the
>> patch checks whether pag
At 07/18/2012 06:16 PM, Yasuaki Ishimatsu Wrote:
> All pages of virtual mapping in removed memory cannot be freed, since some
> pages
> used as PGD/PUD includes not only removed memory but also other memory. So the
> patch checks whether page can be freed or not.
>
> How to check whether page can
Hi Wen,
2012/07/19 16:23, Wen Congyang wrote:
> At 07/18/2012 06:06 PM, Yasuaki Ishimatsu Wrote:
>> acpi_memory_device_remove() has been prepared to remove physical memory.
>> But, the function only frees acpi_memory_device currentlry.
>>
>> The patch adds following functions into acpi_memory_devi
Hi Bob,
2012/07/19 17:32, Bob Liu wrote:
On Wed, Jul 18, 2012 at 6:12 PM, Yasuaki Ishimatsu
wrote:
The patch adds __remove_pages() to remove_memory(). Then the range of
phys_start_pfn argument and nr_pages argument in __remove_pagse() may
have different zone. So zone argument is removed from _
Hi Bob,
2012/07/19 17:19, Bob Liu wrote:
Hi Yasuaki,
On Wed, Jul 18, 2012 at 6:05 PM, Yasuaki Ishimatsu
wrote:
remove_memory() does not remove memory but just offlines memory. The patch
changes name of it to offline_memory().
Since offline_memory() just align the start/end pfn and there is
Hello,
As there was no response to my question I assume that I see it correctly
that at the moment the only 2 options for setting up GPIO configurations
is either via platform-specific code by eg. platform_data or via userspace?
Would there be a common use of defining GPIO configurations via a de
On 07/11/2012 11:06 AM, Benjamin Herrenschmidt wrote:
diff --git a/arch/powerpc/kernel/machine_kexec.c
b/arch/powerpc/kernel/machine_kexec.c
index c957b12..0c9695d 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -207,6 +207,12 @@ static struct proper
On Wed, Jul 18, 2012 at 10:59:52AM -0600, Bjorn Helgaas wrote:
>On Tue, Jul 17, 2012 at 10:25 PM, Ram Pai wrote:
>> On Tue, Jul 17, 2012 at 11:14:51AM -0600, Bjorn Helgaas wrote:
>>> On Tue, Jul 17, 2012 at 4:38 AM, Benjamin Herrenschmidt
>>> wrote:
>>> > On Tue, 2012-07-17 at 18:03 +0800, Ram Pa
At 07/18/2012 06:06 PM, Yasuaki Ishimatsu Wrote:
> acpi_memory_device_remove() has been prepared to remove physical memory.
> But, the function only frees acpi_memory_device currentlry.
>
> The patch adds following functions into acpi_memory_device_remove():
> - offline memory
> - remove phys
20 matches
Mail list logo
