Andrew Morton a...@linux-foundation.org wrote on 2010/01/28 02:05:36:
On Mon, 25 Jan 2010 09:19:59 +0100
Joakim Tjernlund joakim.tjernl...@transmode.se wrote:
Commit 6846ee5ca68d81e6baccf0d56221d7a00c1be18b made the
new optimized inflate only available on arch's that
define
John,
I came across this thread/patchset from around June last year:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073086.html
where Wolfgang proposed a generic OF-driven UIO driver. The
Wolfram, please ;)
discussion seemed to stall after Grant Likely indicated he didn't
On 01/27/2010 05:05 PM, Gary Thomas wrote:
On 01/27/2010 01:20 PM, Gary Thomas wrote:
I have two nearly identical boards, with very different behavior.
Older 8347 (PVR: 0x80830011)
New 8347 (PVR: 0x80830031)
I lied (more precisely I was lied to and I passed it on - I've never
seen these
On 01/28/2010 05:17 AM, Gary Thomas wrote:
On 01/27/2010 05:05 PM, Gary Thomas wrote:
On 01/27/2010 01:20 PM, Gary Thomas wrote:
I have two nearly identical boards, with very different behavior.
Older 8347 (PVR: 0x80830011)
New 8347 (PVR: 0x80830031)
I lied (more precisely I was lied to and
From: Wolfgang Grandegger w...@denx.de
This patch adds the MPC5121 to the list of supported devices,
enhances the doc of the clock-frequency property and removes
the obsolete cell-index property from the example nodes.
Furthermore and example for the MPC5121 has been added.
Signed-off-by:
This patch series adds support for the MPC512x from Freescale to the
i2c-mpc driver. At that occasion, issues with __devinit[data] have
been fixed and the doc of the FSL I2C dts bindings updated. It has
been tested on a MPC5121ADS, TQM5200 and TQM8560 board
Changes since v1:
- use macro
From: Wolfgang Grandegger w...@denx.de
The setclock initialization functions have been renamed to setup
because I2C interrupts must be enabled for the MPC512x. This requires
to handle fsl,preserve-clocking in a slighly different way. Also,
the old settings are now reported calling dev_dbg(). For
From: Wolfgang Grandegger w...@denx.de
__devinit[data] has not yet been used for all initialization functions
and data. To avoid truncating lines, the struct mpc_i2c_match_data has
been renamed to mpc_i2c_data, which is even the better name.
Signed-off-by: Wolfgang Grandegger w...@denx.de
---
Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu
---
arch/powerpc/include/asm/mpc512x_gpio.h | 30 +
arch/powerpc/platforms/Kconfig |9 ++
arch/powerpc/sysdev/Makefile|1 +
arch/powerpc/sysdev/mpc512x_gpio.c | 179 +++
4
Hi all:
I have reserved top 128MBytes sdram for PCI DMA usage. External PCI
master sends data to top sdram and then wake up user space app.
User space use /dev/mem and mmap to access this region and then send
them to network using socket.
I found send speed of memory data in /dev/mem to network
On my MPC8548 based board, sometimes kernel printed out the following
messages, I wonder if it indicates the system is not normal?
pdflush used greatest stack depth: 4048 bytes left
pdflush used greatest stack depth: 4028 bytes left
pdflush used greatest stack depth: 3964 bytes left
pdflush used
On Thursday 28 January 2010, hank peng wrote:
On my MPC8548 based board, sometimes kernel printed out the following
messages, I wonder if it indicates the system is not normal?
pdflush used greatest stack depth: 4048 bytes left
pdflush used greatest stack depth: 4028 bytes left
pdflush used
The new Power7 processor has 4 way SMT. This 4 way SMT benefits from
dynamic power updates that arch_scale_smt_power was designed to provide.
The first patch fixes a generic scheduler bug necessary for arch_scale_smt
to properly function. The second patch implements arch_scale_smt_power
for
Enable the scheduler feature that allows use of arch_scale_smt_power. Stub out
the broken x86 implementation.
Signed-off-by: Joel Schopp jsch...@austin.ibm.com
---
Index: linux-2.6.git/kernel/sched_features.h
===
---
On Power7 processors running in SMT4 mode with 2, 3, or 4 idle threads
there is performance benefit to idling the higher numbered threads in
the core.
This patch implements arch_scale_smt_power to dynamically update smt
thread power in these idle cases in order to prefer threads 0,1 over
On 64-bit kernels we currently have a 512 byte struct paca_struct for
each cpu (usually just called the paca). Currently they are statically
allocated, which means a kernel built for a large number of cpus will
waste a lot of space if it's booted on a machine with few cpus.
We can avoid that by
On Power7 processors running in SMT4 mode with 2, 3, or 4 idle threads
there is performance benefit to idling the higher numbered threads in
the core.
This patch implements arch_scale_smt_power to dynamically update smt
thread power in these idle cases in order to prefer threads 0,1 over
On Wed, 2010-01-27 at 12:43 -0600, lei...@linux.vnet.ibm.com wrote:
diff --git a/arch/powerpc/platforms/pseries/eeh_driver.c
b/arch/powerpc/platforms/pseries/eeh_driver.c
index ef8e454..afdddf6 100644
--- a/arch/powerpc/platforms/pseries/eeh_driver.c
+++
On Wed, 2010-01-27 at 12:43 -0600, lei...@linux.vnet.ibm.com wrote:
Currently pci_dev can be null when EEH is in action. This patch
just assure that we pci_dev is not NULL before calling pci_dev_put.
Like all variants of *_put(), it already checks for a NULL argument
afaik. So that patch should
On Thu, 2010-01-28 at 17:24 -0600, Joel Schopp wrote:
On Power7 processors running in SMT4 mode with 2, 3, or 4 idle threads
there is performance benefit to idling the higher numbered threads in
the core.
This patch implements arch_scale_smt_power to dynamically update smt
thread power
I've tested it with manually offlined threads and it behaves as I'd like
it to.
Which is ? IE. I'm happy that you like how it behaves, but I'd like to u
understand how that is so I can make sure I'm also happy with it :-)
Cheers,
Ben.
___
On Wed, Jan 27, 2010 at 01:10:56PM +1100, Benjamin Herrenschmidt wrote:
Cc'ing Ben for PPC. Ben, should PPC use pci_scan_device when probing
its root busses? Sounds like it just uses pci_device_add for each one
it finds instead?
If you don't actually need scanning (though what about
On Thu, 2010-01-28 at 20:45 -0700, Matthew Wilcox wrote:
This is also probably going to be moved to a more generic place and
extended to be used optionally by other architectures.
Yes, having it under drivers/pci/ somewhere would be a big improvement,
that way we'd actually see it when
Hi All,
I have a Freescale MPC8313 customized board and want to confiugre
TSEC1 to SGMII. Would you please help me for this question,
1). Is it possible for MPC8313 TSEC1 connect to Ethernet Switch by
SGMII (without phy), like below diagram.
[MPC8313 TSEC1] SGMII [Ethernet Switch]
2).
24 matches
Mail list logo
