On Friday 19 December 2008, Felix Radensky wrote:
> Thanks a lot to everyone who replied. I've managed to identify the cause
> of the delay. The board is equipped with 256 MiB Samsung NAND flash.
> Since NAND support is a must for this platform, I've intergated the ndfc
> driver recently posted by
Hello Dan,
On Wednesday, December 17, 2008 you wrote:
[..]
>> + /* DMAs use destinations as sources, so use BIDIRECTIONAL mapping */
>> + dma_dest[0] = !blocks[src_cnt] ? 0 :
>> + dma_map_page(dma->dev, blocks[src_cnt],
>> +
On Thursday 18 December 2008, Grant Erickson wrote:
> Added additional information for type and compatibility strings and
> interrupt information to the SDRAM0 memory-controller device tree
> nodes for AMCC PowerPC 405EX[r]-based boards to facilitate binding
> with the new "ibm,sdram-4xx-ddr2" EDAC
Josh Boyer-3 wrote:
>
> On Thu, Dec 18, 2008 at 02:29:52AM -0800, Felix Radensky wrote:
>>
>
>
> I booted on a canyonlands this morning (after having removed the brown
> paper bag that preventing me from booting it yesterday). I saw no
> delay.
>
> josh
>
This patch adds support for 256KB pages on ppc44x-based boards.
For simplification of implementation with 256KB pages we still assume
2-level paging. As a side effect this leads to wasting extra memory space
reserved for PTE tables: only 1/4 of pages allocated for PTEs are
actually used. But this
The following patch fixes division by zero, which we have in
shmem_truncate_range() and shmem_unuse_inode(), if use big
PAGE_SIZE values (e.g. 256KB on ppc44x).
With 256KB PAGE_SIZE the ENTRIES_PER_PAGEPAGE constant becomes
too large (0x1..), so this patch just changes the types
from 'ulo
Hello Andrew,
On Friday, December 19, 2008 you wrote:
[snip]
>> There is one more warning from the common code when I use 256KB pages:
>>
>>CC mm/shmem.o
>> mm/shmem.c: In function 'shmem_truncate_range':
>> mm/shmem.c:613: warning: division by zero
>> mm/shmem.c:619: warning: division
On Fri, 19 Dec 2008, Paul Mackerras wrote:
> Steven Rostedt writes:
>
> > Sorry, I rebased to edit the change log where I mispelled Paul's name.
>
> So, what commits should I be pulling into powerpc.git, or what patches
> should I be committing, for dynamic ftrace on powerpc?
Ingo did not like
After discussing with chip designers, it appears that it's not
necessary to set G everywhere on 440 cores. The various core
errata related to prefetch should be sorted out by firmware by
disabling icache prefetching in CCR0. We add the workaround to
the kernel however just in case ld firmwares
Currently, we never set _PAGE_COHERENT in the PTEs, we just OR it in
in the hash code based on some CPU feature bit. We also manipulate
_PAGE_NO_CACHE and _PAGE_GUARDED by hand in all sorts of places.
This changes the logic so that instead, the PTE now contains
_PAGE_COHERENT for all normal RAM pa
This makes the MMU context code used for CPUs with no hash table
(except 603) dynamically allocate the various maps used to track
the state of contexts.
Only the main free map and CPU 0 stale map are allocated at boot
time. Other CPU maps are allocated when those CPUs are brought up
and freed if t
The handlers for Critical, Machine Check or Debug interrupts
will save and restore MMUCR nowadays, thus we only need to
disable normal interrupts when invalidating TLB entries.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/mm/tlb_nohash_low.S | 19 ++-
1 file changed,
Currently, the various forms of low level TLB invalidations are all
implemented in misc_32.S for 32-bit processors, in a fairly scary
mess of #ifdef's and with interesting duplication such as a whole
bunch of code for FSL _tlbie and _tlbia which are no longer used.
This moves things around such th
This patch moves the whole no-hash TLB handling out of line into a
new tlb_nohash.c file, and implements some basic SMP support using
IPIs and/or broadcast tlbivax instructions.
Note that I'm using local invalidations for D->I cache coherency.
At worst, if another processor is trying to execute t
This reworks the context management code used by 4xx,8xx and
freescale BookE. It adds support for SMP by implementing a
concept of stale context map to lazily flush the TLB on
processors where a context may have been invalidated. This
also contains the ground work for generalizing such lazy TLB
flu
This splits the mmu_context handling between 32-bit hash based processors,
64-bit hash based processors and everybody else. This is preliminary work
for adding SMP support for BookE processors.
Signed-off-by: Benjamin Herrenschmidt
---
v2. address various comments for Josh and Stephen
v3. properl
This adds supports to the "extended" DCR addressing via
the indirect mfdcrx/mtdcrx instructions supported by some
4xx cores (440H6 and later)
I enabled the feature for now only on AMCC 460 chips
Signed-off-by: Benjamin Herrenschmidt
---
This variant uses "440x6" instead of "440H6". I made no ot
This series of patches is aimed at supporting SMP on non-hash
based processors. It consists of a rework of the MMU context
management and TLB management, clearly splitting hash32, hash64
and nohash in both cases, adding SMP safe context handling and
some basic SMP TLB management.
There is room for
Steven Rostedt writes:
> Sorry, I rebased to edit the change log where I mispelled Paul's name.
So, what commits should I be pulling into powerpc.git, or what patches
should I be committing, for dynamic ftrace on powerpc?
Paul.
___
Linuxppc-dev mailing
KVM on E500 platform currently utilize TLB1 entries without bothering host,
that is using unused TLB1 entries.
So, KVM needs to read tlbcam_index to know exactly
which TLB1 entry is unused by host.
Signed-off-by: Liu Yu
---
[v2]
Remove num_tlbcam_entries declare and read from SPRN_TLB1CFG in KVM
On 12/18/08 11:13 AM, Grant Erickson wrote:
> On 12/18/08 9:56 AM, Josh Boyer wrote:
>> So, I am not an expert at the EDAC subsystem. Just looking at the
>> number of functions that get call from this interrupt handler, I'm
>> wondering if a significant amount of time could be spent here. With
>>
On Thu, 2008-12-18 at 22:01 +0300, Anton Vorontsov wrote:
> On Thu, Dec 18, 2008 at 12:51:29PM -0600, Kumar Gala wrote:
> >> I saw somewhat similar behaviour on 83xx target, the cause was
> >> that my .config file contained bogus UDBG_RTAS_CONSOLE=y symbol
> >> (or was it PPC_EARLY_DEBUG_RTAS_PANE
On Thu, 18 Dec 2008 10:47:50 +0300
Yuri Tikhonov wrote:
> Hello Paul,
>
> On Friday 12 December 2008 03:48, Paul Mackerras wrote:
> > Andrew Morton writes:
> >
> > > > +#if (8 * THREAD_SIZE) > PAGE_SIZE
> > > > max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
> > > > +#else
> > >
Added additional information for type and compatibility strings and
interrupt information to the SDRAM0 memory-controller device tree
nodes for AMCC PowerPC 405EX[r]-based boards to facilitate binding
with the new "ibm,sdram-4xx-ddr2" EDAC memory controller adapter driver.
Signed-off-by: Grant Eri
Added additional information for type and compatibility strings and
interrupt information to the SDRAM0 memory-controller device tree
nodes for AMCC PowerPC 405EX[r]-based boards to facilitate binding
with the new "ibm,sdram-4xx-ddr2" EDAC memory controller adapter driver.
Signed-off-by: Grant Eri
When running Active Memory Sharing, pages can get marked as
"loaned" with the hypervisor by the CMM driver. This state gets
cleared by the system firmware when rebooting the partition.
When using kexec to boot a new kernel, this state never gets
cleared and the hypervisor and CMM driver can get ou
When running Active Memory Sharing, the Collaborative Memory
Manager (CMM) may mark some pages as "loaned" with the hypervisor.
Periodically, the CMM will query the hypervisor for a loan request,
which is a single signed value. When kexec'ing into a kdump kernel,
the CMM driver in the kdump kernel
Dear Felix Radensky,
In message <21070179.p...@talk.nabble.com> you wrote:
>
> I'm experiencing a long (around 20 sec) delay from the moment
> u-boot-1.3.4 passes control to linux and until the first kernel message
> appears on console. This happens on custom board, I don't have access
> to Canyo
Added additional information for type and compatibility strings and
interrupt information to the SDRAM0 memory-controller device tree
nodes for AMCC PowerPC 405EX[r]-based boards to facilitate binding
with the new "ibm,sdram-4xx-ddr2" EDAC memory controller adapter driver.
Signed-off-by: Grant Eri
On 12/18/08 9:56 AM, Josh Boyer wrote:
> On Wed, Dec 17, 2008 at 05:42:21PM -0800, Grant Erickson wrote:
>> This adds support for an EDAC memory controller adaptation driver for
>> the "ibm,sdram-4xx-ddr2" ECC controller realized in the AMCC PowerPC
>> 405EX[r].
>>
>> Signed-off-by: Grant Erickson
On Thu, Dec 18, 2008 at 02:29:52AM -0800, Felix Radensky wrote:
>
>Hi,
>
>I'm experiencing a long (around 20 sec) delay from the moment
>u-boot-1.3.4 passes control to linux and until the first kernel message
>appears on console. This happens on custom board, I don't have access
>to Canyonlands to
On Thu, Dec 18, 2008 at 12:51:29PM -0600, Kumar Gala wrote:
>
> On Dec 18, 2008, at 10:02 AM, Anton Vorontsov wrote:
>
>> On Thu, Dec 18, 2008 at 02:29:52AM -0800, Felix Radensky wrote:
>>>
>>> Hi,
>>>
>>> I'm experiencing a long (around 20 sec) delay from the moment
>>> u-boot-1.3.4 passes control
On Dec 18, 2008, at 10:02 AM, Anton Vorontsov wrote:
On Thu, Dec 18, 2008 at 02:29:52AM -0800, Felix Radensky wrote:
Hi,
I'm experiencing a long (around 20 sec) delay from the moment
u-boot-1.3.4 passes control to linux and until the first kernel
message
appears on console.
I saw somewh
On Dec 18, 2008, at 10:36 AM, Anton Vorontsov wrote:
Kumar, Timur,
Much thanks for the reviews and comments, here is an updated patch
set.
Changes:
- BCSR GPIO bindings were split into a separate patch.
- simple_gpiochip_init() return value changed to void (the function
prints errors by i
On Thu, Dec 18, 2008 at 10:04:48AM -0800, Grant Erickson wrote:
>On 12/18/08 9:56 AM, Josh Boyer wrote:
>> On Thu, Dec 18, 2008 at 09:04:23AM +0100, Stefan Roese wrote:
>>> On Thursday 18 December 2008, Grant Erickson wrote:
diff --git a/arch/powerpc/boot/dts/haleakala.dts
b/arch/powerpc/
On Fri, Dec 05, 2008 at 11:09:36PM +0300, Anton Vorontsov wrote:
> Hi all,
>
> The patch series are used to support SPI via the OF SPI subsystem
> (driver/of/of_spi.c). Now the driver is able to manage its own
> chip selects, and doesn't need any auxiliary support from the
> board files or fsl_soc
No need to call ucc_geth_memclean() so many times, just check for
errors in ucc_geth_open(), and call ucc_geth_stop() in case of errors.
The ucc_geth_stop() may be called anytime and will do the right thing.
Signed-off-by: Anton Vorontsov
---
drivers/net/ucc_geth.c | 31 +-
The driver doesn't check ioremap() return value, and doesn't free the
remapped memory.
This patch fixes it.
Signed-off-by: Anton Vorontsov
---
drivers/net/ucc_geth.c | 15 ---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_
The code appears to be dead: nobody call these functions, plus build
breaks when UGETH_FILTERING is enabled:
ucc_geth.c:1848: warning: 'struct enet_addr' declared inside parameter list
ucc_geth.c:1848: warning: its scope is only this definition or declaration,
which is probably not what you want
The timeout handling code is currently broken in several ways:
- It calls stop() (which frees all the memory and IRQ), and then
calls startup() (which won't re-request IRQ, neither it will
re-init the Fast UCC structure).
- It calls these routines from the softirq context, which is wrong,
si
open() routine calls stop() in case of errors, the function will try
to free the requested IRQ. But we don't know if it was actually
requested, so the code might issue bogus free_irq(0, dev) call.
Fix this by rearranging the code so that now request_irq() is the last
call in the open() routine, an
Currently the routines wait for the various bits w/o an assumption that
bits may never get set. When timeouts happen I see that these bits never
get set and so the routines hang the kernel.
With this patch we'll wait the graceful stop for 100 ms, and then will
simply exit. There is nothing* we can
On 12/18/08 9:56 AM, Josh Boyer wrote:
> On Thu, Dec 18, 2008 at 09:04:23AM +0100, Stefan Roese wrote:
>> On Thursday 18 December 2008, Grant Erickson wrote:
>>> diff --git a/arch/powerpc/boot/dts/haleakala.dts
>>> b/arch/powerpc/boot/dts/haleakala.dts index 513bc43..64880ab 100644
>>> --- a/arch/p
On Thu, Dec 18, 2008 at 09:04:23AM +0100, Stefan Roese wrote:
>On Thursday 18 December 2008, Grant Erickson wrote:
>> Added additional information for type and compatibility strings and
>> interrupt information to the SDRAM0 memory-controller device tree
>> nodes for AMCC PowerPC 405EX[r]-based boa
On Wed, Dec 17, 2008 at 05:42:21PM -0800, Grant Erickson wrote:
>This adds support for an EDAC memory controller adaptation driver for
>the "ibm,sdram-4xx-ddr2" ECC controller realized in the AMCC PowerPC
>405EX[r].
>
>Signed-off-by: Grant Erickson
>---
>At present, this driver has been developed
On Thu, Dec 18, 2008 at 06:38:26PM +0100, M B wrote:
> Hi,
>
> I'm having Problems with the gianfar Ethernet. eth1 is working fine,
> but eth0 is making trouble. It's making trouble in u-boot as well, so
> it could as well be a hardware problem.
> First of all eth0 receives some frame errors (fram
On Thu, Dec 18, 2008 at 11:20:03AM -0600, Scott Wood wrote:
> Anton Vorontsov wrote:
>> On Thu, Dec 18, 2008 at 10:14:11AM +0800, Mingkai Hu wrote:
>>> There is no standard way of getting device platform data from
>>> dts file to the I2C device when it's probed. This patch adds
>>> a function point
Hi,
I'm having Problems with the gianfar Ethernet. eth1 is working fine,
but eth0 is making trouble. It's making trouble in u-boot as well, so
it could as well be a hardware problem.
First of all eth0 receives some frame errors (frame: in ifconfig), but
eth1 doesn't.
eth1 performs well under a pin
Anton Vorontsov wrote:
On Thu, Dec 18, 2008 at 10:14:11AM +0800, Mingkai Hu wrote:
There is no standard way of getting device platform data from
dts file to the I2C device when it's probed. This patch adds
a function pointer to the of_modalias_table to get such bindings
properties into device's
On Thu, Dec 18, 2008 at 10:14:11AM +0800, Mingkai Hu wrote:
> There is no standard way of getting device platform data from
> dts file to the I2C device when it's probed. This patch adds
> a function pointer to the of_modalias_table to get such bindings
> properties into device's platform data.
Un
Simply add the usb node to support USB host on the MPC8360E-RDK
boards.
Currently U-Boot doesn't fill the clock-frequency property for
timer nodes, so for now we have to fill it manually.
Signed-off-by: Anton Vorontsov
---
arch/powerpc/boot/dts/mpc836x_rdk.dts | 19 +--
1 file
- Update the device tree per QE USB bindings;
- Add timer (FSL GTM) node;
- Add gpio-controller node for BCSR13 bank (GPIOs on that bank
are used to control the USB transceiver);
- Set up other BCSR registers;
- Configure the QE Par IO.
The work is loosely based on Li Yang's patch[1], which was
The driver supports very simple GPIO controllers, that is, when a
controller provides just a 'data' register. Such controllers may be
found in various BCSRs (Board's FPGAs used to control board's
switches, LEDs, chip-selects, Ethernet/USB PHY power, etc).
So far we support only 1-byte GPIO banks.
The patch adds bindings for BCSR GPIO banks, the bindings are used to
describe particular BCSR registers that act as simple GPIO controllers.
These GPIO banks might control power switches, SPI chip-selects, LEDs,
etc.
While at it, also fix "length" spelling error in the PIXIS FPGA
bindings.
Signe
Kumar, Timur,
Much thanks for the reviews and comments, here is an updated patch set.
Changes:
- BCSR GPIO bindings were split into a separate patch.
- simple_gpiochip_init() return value changed to void (the function
prints errors by itself, and we don't check its return value anyway).
p.s.
>
On Thu, Dec 18, 2008 at 02:29:52AM -0800, Felix Radensky wrote:
>
> Hi,
>
> I'm experiencing a long (around 20 sec) delay from the moment
> u-boot-1.3.4 passes control to linux and until the first kernel message
> appears on console.
I saw somewhat similar behaviour on 83xx target, the cause was
Ben Dooks schrieb:
> Ok, but this isn't really a fix, so I'll look at putting it into my
> i2c-next tree, not i2c-fixes.
That's OK for me.
Thanks,
Jochen
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc
On Wed, Dec 17, 2008 at 12:55:06PM +0100, Jochen Friedrich wrote:
> Hi Ben,
>
> > Mike Ditto (1):
> > i2c-cpm: Detect and report NAK right away instead of timing out
>
> Could you also have a look at http://patchwork.ozlabs.org/patch/7452/ ?
> (Discussion at http://patchwork.ozlabs.org/patc
Hi,
I'm experiencing a long (around 20 sec) delay from the moment
u-boot-1.3.4 passes control to linux and until the first kernel message
appears on console. This happens on custom board, I don't have access
to Canyonlands to test how it behaves. I did not modify anything in kernel
code to make
Hi Remi,
On Wednesday 17 December 2008 21:27:49 Remi Lefevre wrote:
> >> Also 40% seems quite a lot, even at 1000Hz interruptions, an idea how
> >> much does the CRC computation contribute in this CPU hogging ?
> >
> > I haven't measured that, but probably not much. The biggest CPU time
> > eater
On Thursday 18 December 2008, Grant Erickson wrote:
> Added additional information for type and compatibility strings and
> interrupt information to the SDRAM0 memory-controller device tree
> nodes for AMCC PowerPC 405EX[r]-based boards to facilitate binding
> with the new "ibm,sdram-4xx-ddr2" EDAC
61 matches
Mail list logo
