Hi Greg,
Today's linux-next merge of the driver-core tree got a conflict in
drivers/block/ps3disk.c between commits
6dee2c87ebbe5d7ce8c4c163966a0bd9c02c75ef (block/ps3: remove driver_data
direct access of struct device) and
03fa68c245cccbcb99035cbabaa13b408ba91ab5 (ps3: shorten ps3_system_bus_
On Tue, Jun 16, 2009 at 03:53:17PM +1000, Stephen Rothwell wrote:
Hi Greg,
Today's linux-next merge of the driver-core tree got a conflict in
drivers/block/ps3disk.c between commits
6dee2c87ebbe5d7ce8c4c163966a0bd9c02c75ef (block/ps3: remove driver_data
direct access of struct device) and
Hi Greg,
On Mon, 15 Jun 2009 23:18:49 -0700 Greg KH g...@kroah.com wrote:
I pushed out an update a number of hours ago (like 6+), so you should
have gotten it with this update.
When did you pull from my tree? I also just sent a merge request to
Linus, so everything should be fixed up now.
On Tue, 2009-06-16 at 16:24 +1000, Stephen Rothwell wrote:
Hi Ben,
Today's linux-next build (powerpc ppc44x_defconfig) produced this warning:
drivers/video/xilinxfb.c: In function 'xilinxfb_assign':
drivers/video/xilinxfb.c:328: warning: cast to pointer from integer of
different size
Hi Roland,
thank you for taking a look at the code!
On Fri, 12 Jun 2009 21:50:58 -0700
Roland Dreier rdre...@cisco.com wrote:
OK, one major issue with this patch and a few minor nits.
First, the major issue is that I don't see anything in the patch that
changes the code in
From: Hannes Hering heri...@de.ibm.com
This patch implements toleration of dynamic memory operations and 16 GB
gigantic pages. Toleration means that the driver can cope with dynamic
memory operations that happened before the driver was loaded. While using the
ehca driver, dynamic memory
diff --git a/Documentation/powerpc/dts-bindings/uio-generic.txt
b/Documentation/powerpc/dts-bindings/uio-generic.txt
new file mode 100644
index 000..8ad9861
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/uio-generic.txt
@@ -0,0 +1,16 @@
+UIO for custom devices
+
On Sat, Jun 06, 2009 at 09:14:08AM +0100, David Woodhouse wrote:
On Fri, 2009-06-05 at 14:05 +0200, Wolfram Sang wrote:
Create an of-aware driver using the now exported generic functions from
plat-ram.c. Also add the documentation for the binding. Partitions are
not yet supported. Tested on
On Mon, Jun 15, 2009 at 07:43:20PM +0200, Albrecht Dreß wrote:
Am 05.06.09 14:05 schrieb(en) Wolfram Sang:
Create an of-aware driver using the now exported generic functions
from plat-ram.c. Also add the documentation for the binding.
Partitions are not yet supported. Tested on a
Now my driver gets probed.
This modalias error was due to wrong compatible attribute of
my of node.
But I still need to have the call to of_register_spi_devices().
The attached patch shows what I mean.
rg
kd
Grant Likely wrote:
On Mon, Jun 15, 2009 at 10:36 AM, Kári
On Tue, Jun 16, 2009 at 3:04 AM, Wolfram Sangw.s...@pengutronix.de wrote:
diff --git a/Documentation/powerpc/dts-bindings/uio-generic.txt
b/Documentation/powerpc/dts-bindings/uio-generic.txt
new file mode 100644
index 000..8ad9861
--- /dev/null
+++
On Tue, Jun 16, 2009 at 3:18 AM, Wolfram Sangw.s...@pengutronix.de wrote:
On Mon, Jun 15, 2009 at 07:43:20PM +0200, Albrecht Dreß wrote:
Am 05.06.09 14:05 schrieb(en) Wolfram Sang:
Create an of-aware driver using the now exported generic functions
from plat-ram.c. Also add the documentation
Grant wondered if we need a bankwidth. IMHO it is needed for now, but I
don't
know if this is a common agreement.
I'm not happy about the use case though. It probably shouldn't appear
in this binding, or if it does it should be tagged as an optional
property. It is only in the 5200
On Apr 21, 2009, at 6:24 PM, Anatolij Gustschin wrote:
Kumar Gala wrote:
On Apr 21, 2009, at 4:54 PM, Kumar Gala wrote:
On Apr 21, 2009, at 12:19 PM, Anatolij Gustschin wrote:
If the firmware missed to initialize the PHY correctly,
Linux may hang up on socrates while eth0/eth1 interface
Hello All,
We're developing on a Freescale MPC8272 and are having some nasty
problems with PCI bus mastering and data corruption.
We have some custom hardware that is bus mastering, reading data from
the CPUs memory for it's own use. Most of the time, the data is correct,
however
Thanks for taking the time to look at this Ben, comments inline.
Benjamin Herrenschmidt wrote:
On Tue, 2009-05-26 at 14:19 -0400, Geoff Thorpe wrote:
NOT FOR COMMIT, THIS IS A REQUEST FOR FEEDBACK.
The bitops.h functions that operate on a single bit in a bitfield are
implemented by operating
I forgot to include the defconfig in the last set of patches. So you
don't get to use the shiny new LEDS driver on the warp unless you turn
it on.
Enabling hotplug is also very important since we have moved to udev on
the warp.
Like most defconfig patches, most of the changes are just the normal
Hi Chris,
The last couple of months I had the 'pleasure' to work with a Xilinx
ML510 ATX board which contains a Virtex-5 FXT. In my case I had to set
up the plbv46 pci soft-core to function properly with PCI add-on
boards and onboard pci devices. I have had a lot of issues including
ones with DMA
Yeah, the notifier code remains untouched as we still do not allow dynamic
memory operations _while_ our module is loaded. The patch allows the driver
to
cope with DMEM operations that happened before the module was loaded, which
might result in a non-contiguous memory layout. When the
Hello,
this is a hardware, even board issue, but I hope to find the right
target audience here.
In our MPC83xx design I would like to prevent dead lock in case where
a field upgrade is performed, i.e. NOR Flash is erased or written, and
the MPC83xx built-in hardware watchdog triggers.
In
Hi Leon,
Most MPC8xxx board designs I have seen suffer from this possible dead lock:
- NOR Flash is put in erase mode or write mode
- Hardware watchdog triggers
- HRESET# is asserted by the processor, during which the configuration
words are read from NOR Flash.
Either
HRESET# is not attached
On Mon, Jun 15, 2009 at 12:57 AM, Benjamin
Herrenschmidtb...@kernel.crashing.org wrote:
On Wed, 2009-05-27 at 12:55 -0600, Grant Likely wrote:
From: Grant Likely grant.lik...@secretlab.ca
ioremap_early() is useful for things like mapping SoC internally registers
and early debug output because
Chris Pringle wrote:
The kernel version is 2.6.26. Firmware is custom on a custom board.
Cache coherency on PCI DMA requires that the memory be mapped with the M
attribute on this chip, but that should be happening based on
detection of
the core.
I'm not sure where to look to verify this?
Scott Wood wrote:
Check asm/cputable.h for CPU_FTR_NEED_COHERENT. Make sure that
CONFIG_8260 is one of the #ifdefs that turns that on. It looks like
that was in place by 2.6.26 in arch/powerpc. I'm not sure what to
look for in arch/ppc.
I've just checked that and it's definitely switched
Hello,
On Tue, Jun 16, 2009 at 6:30 PM, David Hawkinsd...@ovro.caltech.edu wrote:
Most MPC8xxx board designs I have seen suffer from this possible dead
lock:
- NOR Flash is put in erase mode or write mode
- Hardware watchdog triggers
- HRESET# is asserted by the processor, during which the
Chris Pringle wrote:
Ah right - that would explain what we're seeing then... Doh. Thought I
might have been onto something then. Is there any way to force a cache
flush? That'd at least prove it was a caching issue if it resolved the
problem.
You could enable CONFIG_NOT_COHERENT_CACHE.
Am 16.06.09 14:53 schrieb(en) Grant Likely:
I'm not happy about the use case though. It probably shouldn't
appear in this binding, or if it does it should be tagged as an
optional property.
I agree with you that the naming is really misleading - other devices
which are not mtd's may
Arnd Bergmann wrote:
On Tuesday 16 June 2009, Scott Wood wrote:
Chris Pringle wrote:
Ah right - that would explain what we're seeing then... Doh. Thought I
might have been onto something then. Is there any way to force a cache
flush? That'd at least prove it was a caching issue if it resolved
On Tuesday 16 June 2009, Scott Wood wrote:
If the
device is the only one, you can also use dma_alloc_noncoherent() and
flush explicitly with dma_cache_sync().
I don't see how that would help -- aren't those also controlled by
CONFIG_NOT_COHERENT_CACHE?
Ah, yes you are right. PowerPC
Hi Ira,
Ira Snyder wrote:
Use the DMA_SLAVE capability of the DMAEngine API to copy/from a
scatterlist into an arbitrary list of hardware address/length pairs.
This allows a single DMA transaction to copy data from several different
devices into a scatterlist at the same time.
This also adds
Hi Leon,
Most MPC8xxx board designs I have seen suffer from this possible dead
lock:
- NOR Flash is put in erase mode or write mode
- Hardware watchdog triggers
- HRESET# is asserted by the processor, during which the configuration
words are read from NOR Flash.
Either
HRESET# is not attached
Okay, fair enough. I wasn't paying very close attention when I replied. It
still seems awkward to me, but not enough to object (ie. It's not
dangerous).
g.
On Jun 16, 2009 7:20 AM, Wolfram Sang w.s...@pengutronix.de wrote:
Grant wondered if we need a bankwidth. IMHO it is needed for now,
I just merged in 2.6.30 into our tree and I'm seeing this only when I
have a network driver built into the kernel, and it doesn't seem to
matter which network driver.
Maybe I missed something I need to update in our network drivers to
match the kernel.
Thanks for any help,
John
On Tue, Jun 16, 2009 at 12:01:40PM -0700, Dan Williams wrote:
Hi Ira,
Ira Snyder wrote:
Use the DMA_SLAVE capability of the DMAEngine API to copy/from a
scatterlist into an arbitrary list of hardware address/length pairs.
This allows a single DMA transaction to copy data from several
According to Segher Boessenkool and GCC manual, -fomit-frame-pointer
is only the default when optimising on archs/ABIs where it doesn't
hinder debugging and -pg. So, we do not get it by default on x86,
not at any optimisation level.
On the other hand, *using* -fno-omit-frame-pointer causes gcc to
The workarounds aren't needed any longer since the top level Makefile
doesn't pass -fno-omit-frame-pointer cflag for PowerPC builds.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
arch/powerpc/Makefile|5 -
arch/powerpc/kernel/Makefile | 12
John Linn wrote:
console [ttyS0] enabled
brd: module loaded
loop: module loaded
Unable to handle kernel paging request for data at address 0x75686369
That address spells uhci, FWIW. Maybe a bad pointer cast somewhere in
the USB platform data?
-Scott
On Tue, 2009-06-16 at 10:28 -0400, Geoff Thorpe wrote:
Hi ! Sorry for the delay, that was on my have a look one of these days,
low priority list for a bit too long :-)
NP, optimal throughput often requires a compromise in latency :-)
Hehehe, so true :-)
I'm not sure it's useful to
On Sun, Jun 14, 2009 at 04:04:36PM +0300, Avi Kivity wrote:
Paul Mackerras wrote:
Avi Kivity writes:
An alternative implementation using 64-bit cmpxchg will recover most
of the costs of hashed spinlocks. I assume most serious 32-bit
architectures have them?
Have a 64-bit
On May 26, 2009, at 10:21 AM, Timur Tabi wrote:
The qe_issue_cmd() function (Freescale PowerPC QUICC Engine library)
polls on
a register until a status bit changes, but does not include a
timeout to
handle the situation if the bit never changes. Change the code to
use the new
On Tue, 2009-06-16 at 20:02 +0200, Arnd Bergmann wrote:
On Tuesday 16 June 2009, Scott Wood wrote:
If the
device is the only one, you can also use dma_alloc_noncoherent() and
flush explicitly with dma_cache_sync().
I don't see how that would help -- aren't those also controlled by
On Wed, 17 Jun 2009 10:18:45 +1000
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
On Tue, 2009-06-16 at 20:02 +0200, Arnd Bergmann wrote:
On Tuesday 16 June 2009, Scott Wood wrote:
If the
device is the only one, you can also use dma_alloc_noncoherent() and
flush explicitly
Hello all,
On Wed, Jun 17, 2009 at 2:37 AM, FUJITA
Tomonorifujita.tomon...@lab.ntt.co.jp wrote:
On Wed, 17 Jun 2009 10:18:45 +1000
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
On Tue, 2009-06-16 at 20:02 +0200, Arnd Bergmann wrote:
On Tuesday 16 June 2009, Scott Wood wrote:
If
On Wed, 17 Jun 2009 07:33:46 +1000 Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
You can also go totally mad and generate the whole function (both -s and
non -s variants) from one macro but I wouldn't go that far :-)
Please don't (unless you keep the function names intact), it makes
On Wed, 2009-06-17 at 09:37 +0900, FUJITA Tomonori wrote:
dma_cache_sync is supposed to be used only with the buffers that
dma_alloc_noncoherent() returns. On architecutures that maps
dma_alloc_noncoherent to dma_alloc_coherent, dma_cache_sync() is
supposed to be NOP.
Or at least a sync()
Hoy !
I see that:
block/blk-settings.c: In function ‘blk_set_default_limits’:
block/blk-settings.c:115: warning: large integer implicitly truncated to
unsigned type
Comes from
lim-bounce_pfn = BLK_BOUNCE_ANY;
With BLK_BOUNCE_ANY being a
include/linux/blkdev.h:#define BLK_BOUNCE_ANY
dev_set_name() takes a format string, so use it properly and avoid
a warning with recent gcc's
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/kernel/of_device.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
The function udbg_44x_as1_flush() has the wrong prototype causing
a warning when enabling 440 early debug.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/kernel/udbg_16550.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
On Tue, 16 Jun 2009 11:24:35 -0400
Sean MacLennan smaclen...@pikatech.com wrote:
I forgot to include the defconfig in the last set of patches. So you
don't get to use the shiny new LEDS driver on the warp unless you turn
it on.
Enabling hotplug is also very important since we have moved to
RTAS currently uses a normal spinlock. However it can be called from
contexts where this is not necessarily a good idea. For example, it
can be called while syncing timebases, with the core timebase being
frozen. Unfortunately, that will deadlock in case of lock contention
when spinlock debugging
Several platforms use their own copy of what is essentially the same code,
using RTAS to synchronize the timebases when bringing up new CPUs. This
moves it all into a single common implementation and additionally
turns the spinlock into a raw spinlock since the former can rely on
the timebase not
spin_lock() can hang if called while the timebase is frozen,
so use a raw lock instead, also disable interrupts while
at it.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/platforms/pasemi/setup.c | 15 ++-
1 file changed, 10 insertions(+), 5
Some architectures need to initialize SLAB caches to be able
to allocate page tables. They do that from pgtable_cache_init()
so the later should be called earlier now, best is before
vmalloc_init().
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
Note: Only powerpc, sparc and
Hi Ben,
On Wed, Jun 17, 2009 at 6:48 AM, Benjamin
Herrenschmidtb...@kernel.crashing.org wrote:
Some architectures need to initialize SLAB caches to be able
to allocate page tables. They do that from pgtable_cache_init()
so the later should be called earlier now, best is before
vmalloc_init().
On Wed, Jun 17 2009, Benjamin Herrenschmidt wrote:
Hoy !
I see that:
block/blk-settings.c: In function ???blk_set_default_limits???:
block/blk-settings.c:115: warning: large integer implicitly truncated to
unsigned type
Comes from
lim-bounce_pfn = BLK_BOUNCE_ANY;
With
Hi Avi, Ben,
Today's linux-next build (powerpc ppc44x_defconfig) failed like this:
cc1: warnings being treated as errors
arch/powerpc/kvm/../../../virt/kvm/kvm_main.c: In function
'__kvm_set_memory_region':
arch/powerpc/kvm/../../../virt/kvm/kvm_main.c:1178: error: integer overflow in
On Wed, Jun 10, 2009 at 02:38:06PM +0530, K.Prasad wrote:
Introduce PPC64 implementation for the generic hardware breakpoint interfaces
defined in kernel/hw_breakpoint.c. Enable the HAVE_HW_BREAKPOINT flag and the
Makefile.
[snip]
+void arch_update_kernel_hw_breakpoint(void *unused)
+{
+
On Wed, Jun 10, 2009 at 02:38:24PM +0530, K.Prasad wrote:
Modify Data storage exception code to first lookout for a DABR match before
recognising a kprobe or xmon exception.
Signed-off-by: K.Prasad pra...@linux.vnet.ibm.com
---
arch/powerpc/mm/fault.c | 14 ++
1 file
On Wed, Jun 10, 2009 at 02:38:18PM +0530, K.Prasad wrote:
Modify process handling code to recognise hardware debug registers during copy
and flush operations. Introduce a new TIF_DEBUG task flag to indicate a
process's use of debug register. Load the debug register values into a
new CPU during
On Mon, Jun 15, 2009 at 12:48:28PM +0530, K.Prasad wrote:
On Mon, Jun 15, 2009 at 04:40:45PM +1000, David Gibson wrote:
On Wed, Jun 10, 2009 at 12:13:49PM +0530, K.Prasad wrote:
On Fri, Jun 05, 2009 at 03:11:58PM +1000, David Gibson wrote:
On Wed, Jun 03, 2009 at 10:05:11PM +0530,
60 matches
Mail list logo
