On Thu, 2011-12-15 at 08:49 +0100, Andreas Färber wrote:
Am 15.12.2011 00:58, schrieb Benjamin Herrenschmidt:
We rename the mach64 hack to simple since that's also applicable
to anything using VGA-style DAC IO ports (set to 8-bit DAC) and we
use it for qemu vga.
Note that this is keyed
Am 15.12.2011 00:58, schrieb Benjamin Herrenschmidt:
We rename the mach64 hack to simple since that's also applicable
to anything using VGA-style DAC IO ports (set to 8-bit DAC) and we
use it for qemu vga.
Note that this is keyed on a device-tree compatible property that
is currently only
The following series implements:
* Generic framework for relocatable kernel on PPC32, based on processing
the dynamic relocation entries.
* Relocatable kernel support for 44x
* Kdump support for 44x. Doesn't support 47x yet, as the kexec
support is missing.
Changes from V4:
The current implementation of CONFIG_RELOCATABLE in BookE is based
on mapping the page aligned kernel load address to KERNELBASE. This
approach however is not enough for platforms, where the TLB page size
is large (e.g, 256M on 44x). So we are renaming the RELOCATABLE used
currently in BookE to
We find the runtime address of _stext and relocate ourselves based
on the following calculation.
virtual_base = ALIGN(KERNELBASE,KERNEL_TLB_PIN_SIZE) +
MODULO(_stext.run,KERNEL_TLB_PIN_SIZE)
relocate() is called with the Effective Virtual Base Address (as
shown
DYNAMIC_MEMSTART(old RELOCATABLE) was restricted only to PPC_47x variants
of 44x. This patch enables DYNAMIC_MEMSTART for 440x based chipsets.
Signed-off-by: Suzuki K. Poulose suz...@in.ibm.com
Cc: Josh Boyer jwbo...@gmail.com
Cc: Kumar Gala ga...@kernel.crashing.org
Cc: Benjamin Herrenschmidt
The following patch implements the dynamic relocation processing for
PPC32 kernel. relocate() accepts the target virtual address and relocates
the kernel image to the same.
Currently the following relocation types are handled :
R_PPC_RELATIVE
R_PPC_ADDR16_LO
The following patch adds relocatable kernel support - based on processing
of dynamic relocations - for PPC44x kernel.
We find the runtime address of _stext and relocate ourselves based
on the following calculation.
virtual_base = ALIGN(KERNELBASE,256M) +
Now that we have relocatable kernel, supporting CRASH_DUMP only requires
turning the switches on for UP machines.
We don't have kexec support on 47x yet. Enabling SMP support would be done
as part of enabling the PPC_47x support.
Signed-off-by: Suzuki K. Poulose suz...@in.ibm.com
Cc: Josh Boyer
The wrapper code which uncompresses the kernel in case of a 'ppc' boot
is by default loaded at 0x0040 and the kernel will be uncompressed
to fit the location 0-0x0040. But with dynamic relocations, the size
of the kernel may exceed 0x0040(4M). This would cause an overlap
of the
On Mon, 12 Dec 2011, Tony Breeds wrote:
On Mon, Dec 12, 2011 at 12:21:16AM +0100, Jiri Kosina wrote:
On Thu, 8 Dec 2011, Jeremy Fitzhardinge wrote:
Hm. How about making it depends on HID POWER_SUPPLY? I think that
would needlessly disable it if HID is also modular, but I'm not
We don't do the real store operation for kprobing 'stwu Rx,(y)R1'
since this may corrupt the exception frame, now we will do this
operation safely in exception return code after migrate current
exception frame below the kprobed function stack.
So we only update gpr[1] here and trigger a thread
We need to add a new thread flag, TIF_EMULATE_STACK_STORE,
for emulating stack store operation while exiting exception.
Signed-off-by: Tiejun Chen tiejun.c...@windriver.com
---
arch/powerpc/include/asm/thread_info.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git
Changes from V1:
* use memcpy simply to withdraw copy_exc_stack
* add !(regs-msr MSR_PR)) and
WARN_ON(test_thread_flag(TIF_EMULATE_STACK_STORE));
to make sure we're in goot path.
* move this migration process inside 'restore'
* clear TIF flag atomically
Tiejun Chen (3):
We can't emulate stwu since that may corrupt current exception stack.
So we will have to do real store operation in the exception return code.
Firstly we'll allocate a trampoline exception frame below the kprobed
function stack and copy the current exception frame to the trampoline.
Then we can
Looks we have to go into 'restore' at last as I said previously. I send v2 based
on your all comments.
I assume it may not necessary to reorganize ret_from_except for *ppc32* .
It might be cleaner but I can do that myself later.
I have this version but I'm not 100% sure if its as you
found p5020_ds.c in platforms/85xx;
why is it a part of 85xx directory ? the core of P5020 is E5500 where the
core of 85xx is e500;
Do we have the processor initialization code (start.S, head.S) files, port
available with linux ?
On Wed, Dec 14, 2011 at 12:58 AM, Scott Wood
This series of patches builds on top of my previous series and
modifies the Book3S HV memory management code to use the hardware
reference and change bits in the guest hashed page table. This makes
kvm_age_hva() more efficient, lets us implement the dirty page
tracking properly (which in turn
This changes the implementation of kvm_vm_ioctl_get_dirty_log() for
Book3s HV guests to use the hardware C (changed) bits in the guest
hashed page table. Since this makes the implementation quite different
from the Book3s PR case, this moves the existing implementation from
book3s.c to
This allows both the guest and the host to use the referenced (R) and
changed (C) bits in the guest hashed page table. The guest has a view
of R and C that is maintained in the guest_rpte field of the revmap
entry for the HPTE, and the host has a view that is maintained in the
rmap entry for the
This reworks the implementations of the H_REMOVE and H_BULK_REMOVE
hcalls to make sure that we keep the HPTE locked and in the reverse-
mapping chain until we have finished invalidating it. Previously
we would remove it from the chain and unlock it before invalidating
it, leaving a tiny window
This adds implementations for the H_CLEAR_REF (test and clear reference
bit) and H_CLEAR_MOD (test and clear changed bit) hypercalls. These
hypercalls are not used by Linux guests at this stage, and these
implementations are only compile tested.
Signed-off-by: Paul Mackerras pau...@samba.org
---
This uses the host view of the hardware R (referenced) bit to speed
up kvm_age_hva() and kvm_test_age_hva(). Instead of removing all
the relevant HPTEs in kvm_age_hva(), we now just reset their R bits
if set. Also, kvm_test_age_hva() now scans the relevant HPTEs to
see if any of them have R set.
On Thu, Dec 15, 2011 at 5:45 AM, Vineeth vnee...@gmail.com wrote:
why is it a part of 85xx directory ? the core of P5020 is E5500 where the
core of 85xx is e500;
e5500 is very similar to e500, so it's all part of the same family of cores.
--
Timur Tabi
Linux kernel developer at Freescale
On 12/15/2011 02:08 AM, Jiri Kosina wrote:
On Mon, 12 Dec 2011, Tony Breeds wrote:
On Mon, Dec 12, 2011 at 12:21:16AM +0100, Jiri Kosina wrote:
On Thu, 8 Dec 2011, Jeremy Fitzhardinge wrote:
Hm. How about making it depends on HID POWER_SUPPLY? I think that
would needlessly disable it if
Augment mdiobus_alloc() to take a parameter indicating the number of extra
bytes to allocate for private data. Almost all callers of mdiobus_alloc()
separately allocate a private data structure. By allowing mdiobus_alloc()
to allocate extra memory, the two allocations can be merged into one.
what would be the status of these? should I resend/rebase to the current
etc?..
On 11/21/2011 08:43 AM, Justin P. Mattock wrote:
From: Justin P. Mattockjustinmatt...@gmail.com
The patch below removes an extra semicolon.
Signed-off-by: Justin P. Mattockjustinmatt...@gmail.com
CC:
On Dec 15, 2011, at 11:51 AM, Timur Tabi wrote:
Augment mdiobus_alloc() to take a parameter indicating the number of extra
bytes to allocate for private data. Almost all callers of mdiobus_alloc()
separately allocate a private data structure. By allowing mdiobus_alloc()
to allocate extra
Andy Fleming wrote:
Why? Doesn't this just obfuscate things a little, while providing no
immediate benefit?
I see code like this frequently:
bus = mdiobus_alloc();
if (bus == NULL)
return -ENOMEM;
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if
On 12/14/2011 10:59 PM, Li Yang wrote:
The limitation of the proposed bad block marker migration is that you
need to make sure the migration is done and only done once. If it is
done more than once, the factory bad block marker is totally messed
up. It requires a complex mechanism to
On Thu, 15 Dec 2011, Justin P. Mattock wrote:
what would be the status of these? should I resend/rebase to the current
etc?..
Check linux-next, it's already there.
On 11/21/2011 08:43 AM, Justin P. Mattock wrote:
From: Justin P. Mattockjustinmatt...@gmail.com
The patch below removes
Ill check through the commits.. Thank you for applying..
On Dec 15, 2011 9:46 AM, Jiri Kosina jkos...@suse.cz wrote:
On Thu, 15 Dec 2011, Justin P. Mattock wrote:
what would be the status of these? should I resend/rebase to the current
etc?..
Check linux-next, it's already there.
On
On Thu, Dec 15, 2011 at 11:08:08AM +0100, Jiri Kosina wrote:
Tony,
have you actually tested this one to work in the configuration you have
been seeing it to fail?
I don't seem to be able to find any use of '==' in other Kconfig files
(and never used it myself), so I'd like to have
Vineeth wrote:
found p5020_ds.c in platforms/85xx;
why is it a part of 85xx directory ? the core of P5020 is E5500 where the
core of 85xx is e500;
e5500 is e500mc-64bit Power Architecture core.
Do we have the processor initialization code (start.S, head.S) files, port
available with linux
于 2011年12月15日 04:15, Scott Wood 写道:
On 12/14/2011 02:41 AM, LiuShuo wrote:
于 2011年12月13日 10:46, LiuShuo 写道:
于 2011年12月13日 05:30, Scott Wood 写道:
On 12/12/2011 03:19 PM, Artem Bityutskiy wrote:
On Mon, 2011-12-12 at 15:15 -0600, Scott Wood wrote:
NAND chips come from the factory with bad
On Mon, 2011-11-28 at 22:24 -0600, Matthew McClintock wrote:
boot_cpuid and init_thread_info.cpu are redundant, just use the
var that stays around longer and add a define to make boot_cpuid
point at the correct value
boot_cpudid_phys is not needed and can completly go away from the
SMP
On Thu, Dec 15, 2011 at 9:12 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Mon, 2011-11-28 at 22:24 -0600, Matthew McClintock wrote:
boot_cpuid and init_thread_info.cpu are redundant, just use the
var that stays around longer and add a define to make boot_cpuid
point at the
On Fri, 2011-12-16 at 03:29 +, McClintock Matthew-B29882 wrote:
On Thu, Dec 15, 2011 at 9:12 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Mon, 2011-11-28 at 22:24 -0600, Matthew McClintock wrote:
boot_cpuid and init_thread_info.cpu are redundant, just use the
var that
On Thu, Dec 15, 2011 at 9:35 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
This is 4/5 which is also waiting for your review.
http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-October/093474.html
Ah missed that. This is FSL specific, I'd need Kumar and/or Scott's ack
for that
On (Tue) 06 Dec 2011 [09:05:38], Miche Baker-Harvey wrote:
Amit,
Ah, indeed. I am not using MSI-X, so virtio_pci::vp_try_to_find_vqs()
calls vp_request_intx() and sets up an interrupt callback. From
there, when an interrupt occurs, the stack looks something like this:
40 matches
Mail list logo
