Le 19/05/2017 à 16:41, Anton Blanchard a écrit :
From: Anton Blanchard
ppc64 is the only architecture that turns on VIRT_CPU_ACCOUNTING_NATIVE
by default. The overhead of this option is extremely high - a context
switch microbenchmark using sched_yield() is almost 20% slower.
To get finer gr
Pavel Machek writes:
> Hi!
>
>> >>> > > Signed-off-by: Pavel Machek
>> >>> >
>> >>> > Ping? Two partitions at same place are bad news...
>> >>>
>> >>> Please expand on "bad news"? What are the runtime effects of this
>> >>> change? Decisions about which kernel(s) to patch depend on this info
With commit 11550dc0a00b ("powerpc/fadump: reuse crashkernel parameter
for fadump memory reservation"), 'fadump_reserve_mem=' parameter is
deprecated in favor of 'crashkernel=' parameter. Add a warning if
'fadump_reserve_mem=' is still used.
Suggested-by: Prarit Bhargava
Signed-off-by: Hari Bathi
With commit f6e6bedb7731 ("powerpc/fadump: Reserve memory at an offset
closer to bottom of RAM"), memory for fadump is no longer reserved at
the top of RAM. But there are still a few places which say so. Change
them appropriately.
Signed-off-by: Hari Bathini
---
Documentation/powerpc/firmware-as
Dear Sir,
I'd like to report that SPU not working for kernel > 4.9. The problem
caused by spe_context_run function, when call , it never return back.
Please see my attached file.
My current system (working fine)
Gentoo kernel 4.4.69
libspe2-2.2.80_p95-r1
gcc-6.3.0
spu-elf-gcc-5.3.0
Bets reagrds,
Daniel Axtens writes:
> prom_init is a bit special; in theory it should be able to be
> linked separately to the kernel. To keep this from getting too
> complex, the symbols that prom_init.c uses are checked.
>
> Fortification adds symbols, and it gets quite messy as it includes
> things like pani
On Mon, 22 May 2017 15:04:47 +0530
Hari Bathini wrote:
> With commit f6e6bedb7731 ("powerpc/fadump: Reserve memory at an offset
> closer to bottom of RAM"), memory for fadump is no longer reserved at
> the top of RAM. But there are still a few places which say so. Change
> them appropriately.
>
On Sun, May 21, 2017 at 8:14 PM, Thomas Gleixner wrote:
> On Sun, 21 May 2017, Thomas Gleixner wrote:
>> On Tue, 16 May 2017, Arnd Bergmann wrote:
>> > On Tue, May 16, 2017 at 5:51 PM, Christoph Hellwig wrote:
>> > > Yes, that sounds useful to me as well. As you said it's an independent
>> > > b
On Sun, May 21, 2017 at 7:13 PM, Thomas Gleixner wrote:
> On Tue, 16 May 2017, Arnd Bergmann wrote:
>> On Tue, May 16, 2017 at 5:51 PM, Christoph Hellwig wrote:
>> > Yes, that sounds useful to me as well. As you said it's an independent
>> > but somewhat related change. I can add it to my serie
Hi Javier,
On Mon, May 22, 2017 at 4:01 PM, Javier Martinez Canillas
wrote:
> This series is a follow-up to patch [0] that added an OF device ID table
> to the at24 EEPROM driver. As you suggested [1], this version instead of
> adding entries for every used tuple, only adds a single
> entry for
On Mon, May 22, 2017 at 9:23 AM, Geert Uytterhoeven
wrote:
> Hi Javier,
>
> On Mon, May 22, 2017 at 4:01 PM, Javier Martinez Canillas
> wrote:
>> This series is a follow-up to patch [0] that added an OF device ID table
>> to the at24 EEPROM driver. As you suggested [1], this version instead of
>>
On Mon, May 22, 2017 at 9:46 AM, Javier Martinez Canillas
wrote:
> Hello Geert and Rob,
>
> On Mon, May 22, 2017 at 4:26 PM, Rob Herring wrote:
>> On Mon, May 22, 2017 at 9:23 AM, Geert Uytterhoeven
>> wrote:
>>> Hi Javier,
>>>
>>> On Mon, May 22, 2017 at 4:01 PM, Javier Martinez Canillas
>>> w
Hi Michal,
Thanks for the review..
On Monday 22 May 2017 04:25 PM, Michal Suchánek wrote:
On Mon, 22 May 2017 15:04:47 +0530
Hari Bathini wrote:
With commit f6e6bedb7731 ("powerpc/fadump: Reserve memory at an offset
closer to bottom of RAM"), memory for fadump is no longer reserved at
the t
On Mon, 22 May 2017, Arnd Bergmann wrote:
> On Sun, May 21, 2017 at 7:13 PM, Thomas Gleixner wrote:
> I agree, one of the above is good enough, if we do the large-scale API
> replacement. Having both ms and sec variants would be for convenience
> to avoid having lots of open-coded '*MSEC_PER_SEC)
On Mon, 22 May 2017, Arnd Bergmann wrote:
> On Sun, May 21, 2017 at 8:14 PM, Thomas Gleixner wrote:
> > But it's easy enough to provide them. All we need for that is something
> > like
> >
> > unsigned long time_msec;
> >
> > which gets incremented every tick by the appropriate amount of
>
Hi Javier,
On Mon, May 22, 2017 at 7:15 PM, Javier Martinez Canillas
wrote:
>>> I also wonder why this is really needed if AFAIU "renesas,24c02" is
>>> compatible with "atmel,24c02". IOW, the driver doesn't need to
>>> differentiate between the two since the devices are the same and will
>>> alwa
When adding or removing memory, the aa_index (affinity value) for the
memblock must also be converted to match the endianness of the rest
of the 'ibm,dynamic-memory' property. Otherwise, subsequent retrieval
of the attribute will likely lead to non-existent nodes, followed by
using the default no
On Mon, 15 May 2017, Will Deacon wrote:
> Hi Jiri,
>
> On Mon, May 15, 2017 at 03:07:42PM +0200, Jiri Slaby wrote:
> > There is code duplicated over all architecture's headers for
> > futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr,
> > and comparison of the result.
> >
> >
Hello Wolfram,
This series is a follow-up to patch [0] that added an OF device ID table
to the at24 EEPROM driver. As you suggested [1], this version instead of
adding entries for every used tuple, only adds a single
entry for each chip type using the "atmel" vendor as a generic fallback.
This i
The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.
But when matching using an OF table, both the vendor and device has to be
taken in
The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.
But when matching using an OF table, both the vendor and device has to be
taken in
The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.
But when matching using an OF table, both the vendor and device has to be
taken in
The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.
But when matching using an OF table, both the vendor and device has to be
taken in
The at24 driver allows to register I2C EEPROM chips using different vendor
and devices, but the I2C subsystem does not take the vendor into account
when matching using the I2C table since it only has device entries.
But when matching using an OF table, both the vendor and device has to be
taken in
Hello Geert and Rob,
On Mon, May 22, 2017 at 4:26 PM, Rob Herring wrote:
> On Mon, May 22, 2017 at 9:23 AM, Geert Uytterhoeven
> wrote:
>> Hi Javier,
>>
>> On Mon, May 22, 2017 at 4:01 PM, Javier Martinez Canillas
>> wrote:
>>> This series is a follow-up to patch [0] that added an OF device ID
Hello Rob,
Thanks a lot for your feedback.
On Mon, May 22, 2017 at 6:52 PM, Rob Herring wrote:
> On Mon, May 22, 2017 at 9:46 AM, Javier Martinez Canillas
> wrote:
[snip]
| >
| > at24@50 {
| > - compatible = "at24,24c02";
| > + compatible = "at24,24
Hello Geert,
On Mon, May 22, 2017 at 9:30 PM, Geert Uytterhoeven
wrote:
> Hi Javier,
>
> On Mon, May 22, 2017 at 7:15 PM, Javier Martinez Canillas
> wrote:
I also wonder why this is really needed if AFAIU "renesas,24c02" is
compatible with "atmel,24c02". IOW, the driver doesn't need to
From: Anton Blanchard
Adds support for removing bolted (i.e kernel linear mapping) mappings on
powernv. This is needed to support memory hot unplug operations which
are required for the teardown of DAX/PMEM devices.
Reviewed-by: Rashmica Gupta
Signed-off-by: Anton Blanchard
Signed-off-by: Oliv
Removes an indentation level and shuffles some code around to make the
following patch cleaner. No functional changes.
Signed-off-by: Oliver O'Halloran
---
v1 -> v2: Remove broken initialiser
---
arch/powerpc/mm/init_64.c | 48 ---
1 file changed, 25 i
Adds support to powerpc for the altmap feature of ZONE_DEVICE memory. An
altmap is a driver provided region that is used to provide the backing
storage for the struct pages of ZONE_DEVICE memory. In situations where
large amount of ZONE_DEVICE memory is being added to the system the
altmap reduces
Add support for the devmap bit on PTEs and PMDs for PPC64 Book3S. This
is used to differentiate device backed memory from transparent huge
pages since they are handled in more or less the same manner by the core
mm code.
Cc: Aneesh Kumar K.V
Signed-off-by: Oliver O'Halloran
---
v1 -> v2: Proper
Currently ZONE_DEVICE depends on X86_64. This is fine for now, but it
will get unwieldly as new platforms get ZONE_DEVICE support. Moving it
to an arch selected Kconfig option to save us some trouble in the
future.
Cc: x...@kernel.org
Signed-off-by: Oliver O'Halloran
---
arch/x86/Kconfig | 1 +
Flip the switch. Running around and screaming "IT'S ALIVE" is optional,
but recommended.
Signed-off-by: Oliver O'Halloran
---
arch/powerpc/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index f7c8f9972f61..bf3365c34244 100644
--- a/arch/po
Ivan Mikhaylov writes:
>
> From my point of view it's possible. I've checked docu and on idea
> it should be possible cause WP is only affecting watchdog ping time.
The question is, is there any chance that leaving those bits set on
another platform will cause a problem?
ie. on existing machines
Oliver O'Halloran writes:
> Add support for the devmap bit on PTEs and PMDs for PPC64 Book3S. This
> is used to differentiate device backed memory from transparent huge
> pages since they are handled in more or less the same manner by the core
> mm code.
>
> Cc: Aneesh Kumar K.V
> Signed-off-by
Hi all,
> I'd like to report that SPU not working for kernel > 4.9. The problem
> caused by spe_context_run function, when call , it never return back.
Looks like this also happens with the simple spu_run test:
https://github.com/jk-ozlabs/spufs-testsuite/blob/master/tests/03-spu_run/01-spu_ru
On Mon, 2017-04-03 at 14:33 +0530, Abdul Haleem wrote:
> On Mon, 2017-04-03 at 14:28 +0530, Abdul Haleem wrote:
> > On Tue, 2017-03-28 at 21:00 +1100, Michael Ellerman wrote:
> > > Abdul Haleem writes:
> > >
> > > > Hi,
> > > >
> > > > While running kernel self tests on ppc64, tm/tm-signal-contex
* Oliver O'Halloran wrote:
> Currently ZONE_DEVICE depends on X86_64. This is fine for now, but it
> will get unwieldly as new platforms get ZONE_DEVICE support. Moving it
> to an arch selected Kconfig option to save us some trouble in the
> future.
>
> Cc: x...@kernel.org
> Signed-off-by: Oliv
On Tue, May 23, 2017 at 2:23 PM, Aneesh Kumar K.V
wrote:
> Oliver O'Halloran writes:
>
>> Add support for the devmap bit on PTEs and PMDs for PPC64 Book3S. This
>> is used to differentiate device backed memory from transparent huge
>> pages since they are handled in more or less the same manner
39 matches
Mail list logo
