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] [Ethernet Switch]
2)
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 wh
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
> 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.
___
Linuxp
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 po
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 shoul
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
> +++ b/arch/powerpc/platforms/pseries
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
thread
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
thread
Enable the scheduler feature that allows use of arch_scale_smt_power. Stub out
the broken x86 implementation.
Signed-off-by: Joel Schopp
---
Index: linux-2.6.git/kernel/sched_features.h
===
--- linux-2.6.git.orig/kernel/sched_featur
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 powe
What about an early exit if !cpu_has_feature(CPU_FTR_SMT) ? That would
de-facto compile it out for 32-bit CPU platforms that don't support SMT
at all and avoid some overhead on POWER3,4,970...
If the SD_SHARE_CPUPOWER flag isn't set for the sched domain this
function isn't called. So an ex
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
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 g
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 is
Signed-off-by: Matthias Fuchs
---
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 files changed, 219 inserti
From: Wolfgang Grandegger
"__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
---
drivers/i2c/busses/i
From: Wolfgang Grandegger
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 the MPC
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 MPC_I2C_
From: Wolfgang Grandegger
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: Wolfgang Grande
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
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 board
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'
Andrew Morton wrote on 2010/01/28 02:05:36:
>
> On Mon, 25 Jan 2010 09:19:59 +0100
> Joakim Tjernlund wrote:
>
> > Commit 6846ee5ca68d81e6baccf0d56221d7a00c1be18b made the
> > new optimized inflate only available on arch's that
> > define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS. This
> > fixes it
25 matches
Mail list logo
