Hi,
I have a cuImage kernel in order to support legacy u-boot and a
ramdisk image. Kernel boots fine if these two images are separate and
"bootm $kernel $ramdisk" is used. But I can not make it to work using
a single multi image that contains the kernel and ramdisk images. Is
it even technically p
Hi,
I am trying to hotplug/offline sections of memory on a Power machine.
I boot the kernel with kernelcore=1G commandline parameter. I see that except
for 512MB, the rest of the memory is movable. When trying to do hot-remove, I
notice that I am unable to remove the very last section of memory, o
Guillaume Dargaud wrote:
>> Please use simpleImage..elf.
>
> Great, that seems to be it...
> Except that nothing happens when I jump to 0x4, no message from the
0x4? I recalled the entry point should be 0x40 for simepleImage.*.elf.
So you have to change this on the file, arch/powerpc
On Wed, Sep 15, 2010 at 10:12:57PM +0200, Anatolij Gustschin wrote:
> Enabling the MPC8xxx GPIO driver with MPC512x GPIO extension
> breaks touch screen support on this board since the GPIO
> interrupt will be mapped to 8xxx GPIO irq host resulting in
> a not requestable interrupt in the touch scre
Scott Wood wrote:
> On Wed, 15 Sep 2010 16:27:10 +0800
> "tiejun.chen" wrote:
>
>> It's impossible to boot PPC vmlinux format directly if you only change the
>> original entry point address, 0xc000.
>
> Why? That's pretty much what the bootwrapper does. Our hypervisor has
> directly booted
Enabling the MPC8xxx GPIO driver with MPC512x GPIO extension
breaks touch screen support on this board since the GPIO
interrupt will be mapped to 8xxx GPIO irq host resulting in
a not requestable interrupt in the touch screen driver. Fix
it by mapping the touch interrupt on 8xxx GPIO irq host.
Sig
Stephen found bunch of section mismatch warnings with memblock new changes.
Use __init_memblock to replace __init in memblock.c and remove __init in
memblock.h.
We should not use __init in header files.
Reported-by: Stephen Rothwell
Tested-by: Stephen Rothwell
Signed-off-by: Yinghai Lu
---
Andrew Morton wrote:
> What is the locking for rdev? In other patches I see pointer chases
> with no obvious locking against concurrent changes?
This rdev should be safe because it is intended for use only by
rio_switch
attached to the same rdev. Therefore rio_global_list_lock will work
here.
> -Original Message-
> From: Bounine, Alexandre [mailto:alexandre.boun...@idt.com]
> Sent: Wednesday, September 15, 2010 11:53 AM
> To: Anderson, Trevor; Andrew Morton
> Cc: linux-ker...@vger.kernel.org; Thomas Moll; linuxppc-dev@lists.ozlabs.org
> Subject: RE: [PATCH v2 09/10] RapidIO: A
Anderson, Trevor wrote:
>
> Keep it in please. We lurkers in the embedded community do use the
per-port routing tables.
> One of the problems with SRIO switch tables is that access to routes
is not atomic; we can use
> restricted access to per-port routing tables to reduce the risk of
interferenc
On Wed, Sep 15, 2010 at 11:44:56AM -0700, Nishanth Aravamudan wrote:
> On 15.09.2010 [12:37:58 -0600], Grant Likely wrote:
> > On Wed, Sep 15, 2010 at 12:05 PM, Nishanth Aravamudan
> > wrote:
> > > Without this change drivers, such as ibmvscsi, fail to load with the
> > > previous change.
> >
>
On 15.09.2010 [12:37:58 -0600], Grant Likely wrote:
> On Wed, Sep 15, 2010 at 12:05 PM, Nishanth Aravamudan wrote:
> > Without this change drivers, such as ibmvscsi, fail to load with the
> > previous change.
>
> Shouldn't this patch be ordered before the previous change then to
> preserve bisect
On Wed, Sep 15, 2010 at 02:59:42PM +0200, Stefan Roese wrote:
> On Tuesday 14 September 2010 16:29:06 Stefan Roese wrote:
> > I'm stumbling upon a problem noticed on the Ebony (440GP) eval board.
> > Here the first chip-select is connected to 512KiB of SRAM and 512KiB
> > NOR flash.
>
> "Brown pap
On Wed, Sep 15, 2010 at 12:05 PM, Nishanth Aravamudan wrote:
> Without this change drivers, such as ibmvscsi, fail to load with the
> previous change.
Shouldn't this patch be ordered before the previous change then to
preserve bisectability?
Also, patch descriptions should be explicit about what
On Wed, Sep 15, 2010 at 12:05 PM, Nishanth Aravamudan wrote:
> No need to initialize per-cpu pointer to NULL, it is the default.
>
> Direct dma ops and no setup are the defaults, no need to set for
> iommu-off.
>
> Signed-off-by: Milton Miller
> Signed-off-by: Nishanth Aravamudan
Also looks cor
On Wed, Sep 15, 2010 at 12:05 PM, Nishanth Aravamudan wrote:
> Use the set_dma_ops helper. Instead of modifying vio_dma_mapping_ops,
> just create a trivial wrapper for dma_supported.
>
> Signed-off-by: Milton Miller
> Signed-off-by: Nishanth Aravamudan
Looks right to me.
> ---
> arch/powerpc
On Wed, Sep 15, 2010 at 12:05 PM, Nishanth Aravamudan wrote:
> Use set_dma_ops and remove unused oddly-named temp pointer sd.
>
> Signed-off-by: Milton Miller
> Signed-off-by: Nishanth Aravamudan
Acked-by: Grant Likely
> ---
> arch/powerpc/kernel/pci-common.c | 4 +---
> 1 files changed,
On Wed, Sep 15, 2010 at 12:05 PM, Nishanth Aravamudan wrote:
> The kernel doc for device_register (and device_initialize) very clearly
> state to call put_device not kfree after calling, even on error.
>
> Signed-off-by: Milton Miller
> Signed-off-by: Nishanth Aravamudan
Acked-by: Grant Likely
On Wed, Sep 15, 2010 at 11:05:53AM -0700, Nishanth Aravamudan wrote:
> No need for empty helpers with iommu off, the ppc_md hooks are optional.
Not any more, they used to be needed. :-)
> The direct_dma_ops are the default pci_dma_ops, so no need to set in the
> them iommu off case.
>
> No need
Keep it in please. We lurkers in the embedded community do use the per-port
routing tables.
One of the problems with SRIO switch tables is that access to routes is not
atomic; we can use
restricted access to per-port routing tables to reduce the risk of
interference. And we still use
the Global
BUID_HI and BUID_LO are used to pass data to call_rtas, which expects
ints or u32s. But the macro doesn't cast the return, so the result is
still u64. Use the upper_32_bits and lower_32_bits macros that have been
added to kernel.h.
Found by getting printf format errors trying to debug print the ar
Clearly need to work on my git-send-mail usage! Apologies...
- Forwarded message from Nishanth Aravamudan -
Date: Wed, 15 Sep 2010 11:05:43 -0700
From: Nishanth Aravamudan
To: n...@us.ibm.com
Subject: [PATCH 00/15] ppc iommu cleanups
While working on some upcoming IOMMU-related changes
Without this change drivers, such as ibmvscsi, fail to load with the
previous change.
---
arch/powerpc/kernel/vio.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index 3c3083f..e8d73de 100644
--- a/arch/powerpc/kern
direct_dma_ops is the default pci dma ops.
No need to call a function to get the pci dma ops, we know they are the
dma_direct_ops.
Signed-off-by: Milton Miller
Signed-off-by: Nishanth Aravamudan
---
arch/powerpc/platforms/cell/beat_iommu.c |3 +--
1 files changed, 1 insertions(+), 2 deleti
No need to initialize per-cpu pointer to NULL, it is the default.
Direct dma ops and no setup are the defaults, no need to set for
iommu-off.
Signed-off-by: Milton Miller
Signed-off-by: Nishanth Aravamudan
---
arch/powerpc/platforms/pseries/iommu.c |9 ++---
1 files changed, 2 insertio
The IOMMU code has been passing the dma-mask instead of the
coherent_dma_mask to the iommu allocator. Coherent allocations should
be made using the coherent_dma_mask.
Signed-off-by: Milton Miller
Signed-off-by: Nishanth Aravamudan
---
We currently don't check the mask other than to warn when it
While looking at some code paths I came across this code that zeros
memory then copies over the entire length.
Signed-off-by: Milton Miller
Signed-off-by: Nishanth Aravamudan
---
arch/powerpc/platforms/pseries/dlpar.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/ar
No need for empty helpers with iommu off, the ppc_md hooks are optional.
The direct_dma_ops are the default pci_dma_ops, so no need to set in the
them iommu off case.
No need to set the device tree device_node pci node iommu pointer, its
only used for dlpar remove.
Signed-off-by: Milton Miller
The current check is wrong because it does not take the DMA offset intot
account, and in the case of a driver which doesn't actually support
64bits would falsely report that device as working.
Signed-off-by: Milton Miller
Signed-off-by: Nishanth Aravamudan
---
arch/powerpc/kernel/dma.c |2 +
Use the set_dma_ops helper. Instead of modifying vio_dma_mapping_ops,
just create a trivial wrapper for dma_supported.
Signed-off-by: Milton Miller
Signed-off-by: Nishanth Aravamudan
---
arch/powerpc/kernel/vio.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a
Release the TCE table as the XXX suggests, except on FW_FEATURE_ISERIES,
where the tables are allocated globally and reused.
Signed-off-by: Milton Miller
Signed-off-by: Nishanth Aravamudan
---
arch/powerpc/kernel/vio.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git
No need to set the device tree device_node pci node iommu pointer, its
only used for dlpar remove.
direct_dma_ops are the default, no need to restore them or dma bus ops
if we haven't set them in the error paths.
Signed-off-by: Milton Miller
Signed-off-by: Nishanth Aravamudan
---
arch/powerpc/
Use set_dma_ops and remove unused oddly-named temp pointer sd.
Signed-off-by: Milton Miller
Signed-off-by: Nishanth Aravamudan
---
arch/powerpc/kernel/pci-common.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/
The table offset is in entries, each of which imply a dma address of
an IOMMU page.
Also, we should check the device can reach the whole IOMMU table.
Signed-off-by: Milton Miller
Signed-off-by: Nishanth Aravamudan
---
arch/powerpc/kernel/dma-iommu.c | 21 +++--
1 files change
The kernel doc for device_register (and device_initialize) very clearly
state to call put_device not kfree after calling, even on error.
Signed-off-by: Milton Miller
Signed-off-by: Nishanth Aravamudan
---
arch/powerpc/kernel/vio.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
di
On Wed, 15 Sep 2010 16:27:10 +0800
"tiejun.chen" wrote:
> It's impossible to boot PPC vmlinux format directly if you only change the
> original entry point address, 0xc000.
Why? That's pretty much what the bootwrapper does. Our hypervisor has
directly booted vmlinux this way.
Note that in
On Wednesday 15 September 2010, valdis.kletni...@vt.edu wrote:
> Show Details
> On Tue, 14 Sep 2010 22:22:28 +0200, Arnd Bergmann said:
>
> > This changes all instances of struct file_operations in
> > the kernel to have a .llseek operation and then changes
> > the default to no_llseek, which
On Wed, Sep 15, 2010 at 2:39 AM, Stephen Rothwell wrote:
> Hi Arnd,
>
> On Tue, 14 Sep 2010 22:22:28 +0200 Arnd Bergmann wrote:
>>
>> Stephen, please add
>> git+ssh://master.kernel.org/pub/scm/linux/kernel/git/arnd/bkl.git llseek
>
> Added from today.
>
> Thanks for adding your subsystem tree as
Hi,
I accordance with document MPC8xxRMAD the CPM of MPC8xx includes some
DSP functions.
However, it is not real clear if some additional microcode is needed or
not to operate it.
Does anyone know any implementation of that DSP functionality with Linux ?
Regards
C. Leroy
___
Andrew Morton wrote:
> The handling of `table' is strange. One would expect the caller of
> this function to provide the correct table index, and for the caller
to
> increment that index at an appropriate time.
Handling of the 'table' parameter is hardware-dependent.
RIO switches (at least all
>
> This patch applies to 2.6.34.7. It also applies to 2.6.35.4 althought
> part of it is already included in 2.6.35.4
> It fixed a problem with spi_mpc8xxx.c when transmitting or receiving
> data bigger than PAGE_SIZE when doing a read only or write only operation
> It also fixed an issue with t
> Please use simpleImage..elf.
Great, that seems to be it...
Except that nothing happens when I jump to 0x4, no message from the
kernel, nothing.
I'm a bit stumped here as my old kernel worked fine.
--
Guillaume Dargaud
http://www.gdargaud.net/
___
Andrew Morton wrote:
> Non-backward compatible change? What is the risk of breaking existing
> setups with this change?
I think that risk is very low. Assuming that this change brings sysfs
entries
to their intended hierarchy, it has sense to do it now (at relatively
early stage).
___
Andrew Morton wrote:
> This is also a non-back compatible userspace-visible change?
This should be a safe change because endpoints do not have a routing
table.
RapidIO differentiates devices by using naming templates for switches
and endpoints (":s:" and ":e:") and this indicates which device f
This patch applies to 2.6.34.7. It also applies to 2.6.35.4 althought
part of it is already included in 2.6.35.4
It fixed a problem with spi_mpc8xxx.c when transmitting or receiving
data bigger than PAGE_SIZE when doing a read only or write only operation
It also fixed an issue with the init pro
On Tuesday 14 September 2010 16:29:06 Stefan Roese wrote:
> I'm stumbling upon a problem noticed on the Ebony (440GP) eval board.
> Here the first chip-select is connected to 512KiB of SRAM and 512KiB
> NOR flash.
"Brown paper bag" time for me. Problem was located in U-Boot. Sorry for the
noise.
Hi Arnd,
On Tue, 14 Sep 2010 22:22:28 +0200 Arnd Bergmann wrote:
>
> Stephen, please add
> git+ssh://master.kernel.org/pub/scm/linux/kernel/git/arnd/bkl.git llseek
Added from today.
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgment of
Hi Arnd,
On Tue, 14 Sep 2010 21:53:35 +0200 Arnd Bergmann wrote:
>
> Stephen, please add
> git+ssh://master.kernel.org/pub/scm/linux/kernel/git/arnd/bkl.git trivial
Added from today.
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgment o
* Stephen Rothwell wrote:
> Hi Yinghai,
>
> On Tue, 14 Sep 2010 16:00:06 -0700 Yinghai Lu wrote:
> >
> > Also, we may need to remove all extern and __init and __initdata etc in .h
> > files.
> >
> > please check
> >
> > [PATCH -v3] memblock: Fix section mismatch warning
> >
> > Use __init_
Guillaume Dargaud wrote:
>>> How do I generate an elf file ?
>> vmlinux?
>
> Thanks.
>
> The entry point address has change and I can't upload it:
> New (bad) one:
> $ readelf -h vmlinux
> ...
> Entry point address: 0xc000
>
> Old (good) one:
> $ readelf -h zImage.elf
> ...
> > How do I generate an elf file ?
> vmlinux?
Thanks.
The entry point address has change and I can't upload it:
New (bad) one:
$ readelf -h vmlinux
...
Entry point address: 0xc000
Old (good) one:
$ readelf -h zImage.elf
...
Entry point address: 0x40
How
51 matches
Mail list logo
