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 si
Hi Roland,
thank you for taking a look at the code!
On Fri, 12 Jun 2009 21:50:58 -0700
Roland Dreier 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 ehca_mem_notifier() in ehca_ma
From: Hannes Hering
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 operations are still prohi
> > 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
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. Tes
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 phy
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
Davíðsson wrote:
Is
On Tue, Jun 16, 2009 at 3:04 AM, Wolfram Sang 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
>> > +++ b/Documentation/powerpc/dts-bindin
On Tue, Jun 16, 2009 at 3:18 AM, Wolfram Sang 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 for the binding
> > 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 t
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 occasionall
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 o
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
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 u-boot
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 t
On Mon, Jun 15, 2009 at 12:55 AM, Benjamin
Herrenschmidt wrote:
> On Wed, 2009-05-27 at 12:55 -0600, Grant Likely wrote:
>> From: Grant Likely
>>
>> ioremap_early() is useful for things like mapping SoC internally registers
>> and early debug output because it allows mappings to devices to be setu
On Mon, Jun 15, 2009 at 12:57 AM, Benjamin
Herrenschmidt wrote:
> On Wed, 2009-05-27 at 12:55 -0600, Grant Likely wrote:
>> From: Grant Likely
>>
>> ioremap_early() is useful for things like mapping SoC internally registers
>> and early debug output because it allows mappings to devices to be setu
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 o
Hello,
On Tue, Jun 16, 2009 at 6:30 PM, David Hawkins 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 configuration
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.
-Scot
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 suffe
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 the
> > p
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. Po
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 s
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 t
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" wrote:
> > Grant wondered if we need a bankwidth. IMHO it is needed for now, but I
don't > > know
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
console
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 seve
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
---
arch/powerpc/Makefile|5 -
arch/powerpc/kernel/Makefile | 12 ++--
arch/powerp
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 usef
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?
>>>
>>
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
spin_event_t
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 co
On Wed, 17 Jun 2009 10:18:45 +1000
Benjamin Herrenschmidt 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 with dma_c
Hello all,
On Wed, Jun 17, 2009 at 2:37 AM, FUJITA
Tomonori wrote:
> On Wed, 17 Jun 2009 10:18:45 +1000
> Benjamin Herrenschmidt 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
On Wed, 17 Jun 2009 07:33:46 +1000 Benjamin Herrenschmidt
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
finding the function w
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 sy
On Wed, 2009-06-17 at 02:56 +0200, Leon Woestenberg wrote:
> I use pci_map_sg(), have the device perform either DMA master reads or
> writes to the bus address using PCIe.
> After that, I use pci_unmap_sg().
>
> My assumption is that pci_unmap_sg() either makes the cache coherent
> or invalidated
Hello Benjamin,
On Wed, Jun 17, 2009 at 3:08 AM, Benjamin
Herrenschmidt wrote:
> On Wed, 2009-06-17 at 02:56 +0200, Leon Woestenberg wrote:
>> I use pci_map_sg(), have the device perform either DMA master reads or
>> writes to the bus address using PCIe.
>> After that, I use pci_unmap_sg().
>>
>>
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
---
arch/powerpc/kernel/of_device.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-work.orig/arch/powerpc/kernel/of_device.c 2009-06-17
The function udbg_44x_as1_flush() has the wrong prototype causing
a warning when enabling 440 early debug.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/kernel/udbg_16550.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-work.orig/arch/powerpc/kernel/udbg_16550.c
On Tue, 16 Jun 2009 11:24:35 -0400
Sean MacLennan 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 udev on
> the warp.
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 i
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 b
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
---
arch/powerpc/platforms/pasemi/setup.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
--- linux-work.o
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
---
Note: Only powerpc, sparc and xtensa use this and only
Hi Ben,
On Wed, Jun 17, 2009 at 6:48 AM, Benjamin
Herrenschmidt 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().
>
> Signed-off-by: B
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;
>
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
expressio
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
> ---
> arch/powerpc/mm/fault.c | 14 ++
> 1 file changed, 6 insertions(+),
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 dur
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 +053
On Thu, Apr 16, 2009 at 7:46 AM, Grant Likely wrote:
> On Thu, Apr 16, 2009 at 7:37 AM, Stefan Roese wrote:
>> On Thursday 16 April 2009, Grant Likely wrote:
>>> > Signed-off-by: Stefan Roese
>>> > Reviewd-by: Grant Likely
>>>
>>> Yup, still looks good to me. What boards has this been tested on
On Thu, Jun 11, 2009 at 2:19 PM, Wolfgang Denk wrote:
> So far, MPC512x used mpc512x_find_ips_freq() to get the bus frequency,
> while MPC52xx used mpc52xx_find_ipb_freq(). Despite the different
> clock names (IPS vs. IPB) the code was identical.
>
> Use common code for both processor families.
>
On Wed, Jun 17, 2009 at 12:14 AM, Grant Likely wrote:
> On Thu, Jun 11, 2009 at 2:19 PM, Wolfgang Denk wrote:
>> So far, MPC512x used mpc512x_find_ips_freq() to get the bus frequency,
>> while MPC52xx used mpc52xx_find_ipb_freq(). Despite the different
>> clock names (IPS vs. IPB) the code was ide
On Tue, 16 Jun 2009 09:10:39 -0700
Roland Dreier wrote:
>
> > 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 load
65 matches
Mail list logo
