Hi Paul,
Please find a new set of patches with changes as described below.
The patches have been tested for kernel- and user-mode breakpoints (after
applying the two patches you sent, refer message-id:
20100603004758.ga19...@brick.ozlabs.ibm.com and message-id:
Certain architectures (such as PowerPC Book III S) have a need to cleanup
data-structures before the breakpoint is unregistered. This patch introduces
an arch-specific hook in release_bp_slot() along with a weak definition in
the form of a stub funciton.
Signed-off-by: K.Prasad
Implement perf-events based hw-breakpoint interfaces for PowerPC Book III S
processors. These interfaces help arbitrate requests from various users and
schedules them as appropriate.
[Suggestions from Paul Mackerras pau...@samba.org to
- emulate_step() all non-task bound breakpoints and
An alignment interrupt may intervene between a DSI/hw-breakpoint exception
and the single-step exception. Enable the alignment interrupt (through
modifications to emulate_single_step()) to notify the single-step exception
handler for proper restoration of hw-breakpoints.
[The need to invoke
A signal delivered between a hw_breakpoint_handler() and the
single_step_dabr_instruction() will not have the breakpoint active during
signal handling (since breakpoint will not be restored through single-stepping
due to absence of MSR_SE bit on the signal frame). Enable breakpoints before
signal
Many a times, the requested breakpoint length can be less than the fixed
breakpoint length i.e. 8 bytes supported by PowerPC BookIII S. This could lead
to extraneous interrupts resulting in false breakpoint notifications. The patch
below detects and discards such interrupts for non-ptrace requests
On Thu, Jun 10, 2010 at 10:40:24PM +1000, Paul Mackerras wrote:
On Wed, Jun 09, 2010 at 03:55:59PM +0530, K.Prasad wrote:
+ if (!((bp-attr.bp_addr = dar)
+(dar = (bp-attr.bp_addr + bp-attr.bp_len {
+ /*
+* This exception is triggered not because of a
On Tue, Jun 15, 2010 at 11:54:59AM +1000, Paul Mackerras wrote:
On Fri, Jun 04, 2010 at 12:21:45PM +0530, K.Prasad wrote:
Meanwhile I tested the per-cpu breakpoints with the new emulate_step
patch (refer linuxppc-dev message-id:
20100602112903.gb30...@brick.ozlabs.ibm.com) and they
Hi Linus !
Here's a few powerpc fixes for 2.6.35. The diffstat is sadly bloated by
a small defconfig change, I hate that too :-) We'll switch to some
better mechanism as soon as the dust as settled on what that mechanism
should be, hopefully real soon.
Cheers,
Ben.
The following changes since
On Tue, 2010-06-15 at 15:05 +0800, jxnuxdy wrote:
Thanks Benjamin, the regions don't display as what we expect, that's why we
suspect if there any configuration probelms in CPU host bridge, but we
changed the uboot/linux a lot, seems take no effect on that problems.
We use CPU MPC8544, and
In the eHEA poll function an rmb() is required. Without that some packets
on the receive queue are not seen and thus delayed until the next interrupt
is handled for the same receive queue.
Signed-off-by: Jan-Bernd Themann them...@de.ibm.com
---
Patch created against 2.6.35-rc3
Port reset operations and memory add/remove operations need to
be serialized to avoid a kernel deadlock. The deadlock is caused
by calling the napi_disable() function twice.
Therefore we have to employ the dlpar_mem_lock in the ehea_reset_port
function as well
Signed-off-by: Jan-Bernd Themann
These patches reimplement the reset fuction in the ac97 to use gpio pins
instead of using the mpc5200 ac97 reset functionality in the psc. This
avoids a problem in which attached ac97 devices go into test mode appear
unresponsive.
These patches were tested on a pcm030 baseboard and on custom
Work around a silicon bug in the ac97 reset functionality of the
mpc5200(b). The implementation of the ac97 cold reset is flawed.
If the sync and output lines are high when reset is asserted the
attached ac97 device may go into test mode. Avoid this by
reconfiguring the psc to gpio mode and
Call the gpio reset platform function instead of using the flawed
ac97 functionality of the MPC5200(b)
From MPC5200B User's Manual:
Some AC97 devices goes to a test mode, if the Sync line is high
during the Res line is low (reset phase). To avoid this behavior the
Sync line must be also forced to
Now and again there has been talk on the netdev list of adding PTP
support into Linux. One part of the picture is already in place, the
SO_TIMESTAMPING API for hardware time stamping. This patch set offers
the missing second part needed for complete IEEE 1588 support.
The only feature still to be
The phy_mii_ioctl() function unnecessarily throws away the original ifreq.
We need access to the ifreq in order to support PHYs that can perform
hardware time stamping.
Signed-off-by: Richard Cochran richard.coch...@omicron.at
---
drivers/net/arm/ixp4xx_eth.c |3 ++-
Two maverick drivers filter the ioctl commands passed to phy_mii_ioctl().
This is unnecessary since phylib will check the command in any case.
Signed-off-by: Richard Cochran richard.coch...@omicron.at
---
drivers/net/cpmac.c |5 +
drivers/net/stmmac/stmmac_main.c | 22
This patch adds a phy driver method for configuring hardware time stamping.
Drivers may optionally implement this function.
Signed-off-by: Richard Cochran richard.coch...@omicron.at
---
drivers/net/phy/phy.c |5 +
include/linux/phy.h |3 +++
2 files changed, 8 insertions(+), 0
This patch adds a new networking option to allow hardware time stamps
from PHY devices. Using PHY time stamps will still require adding two
inline function calls to each MAC driver. The CONFIG option makes these
calls safe to add, since the calls become NOOPs when the option is
disabled.
In order to support hardware time stamping from a PHY, it is necessary to
read from the PHY while running in_interrupt(). This patch allows a mii
bus to operate in an atomic context. An mii_bus driver may declare itself
capable for this mode. Drivers which do not do this will remain with the
Certain kinds of hardware time stamping units in both MACs and PHYs have
the limitation that they can only time stamp PTP packets. Drivers for such
hardware are left with the task of correctly matching skbs to time stamps.
This patch adds a BPF that drivers can use to classify PTP packets when
This patch adds a driver for the DP83640. This device is one of a new
generation of PHYs able to time stamp PTP packets.
Signed-off-by: Richard Cochran richard.coch...@omicron.at
---
drivers/net/phy/Kconfig |5 +
drivers/net/phy/Makefile |1 +
drivers/net/phy/dp83640.c |
This patch adds an infrastructure for hardware clocks that implement
IEEE 1588, the Precision Time Protocol (PTP). A class driver offers a
registration method to particular hardware clock drivers. Each clock is
exposed to user space as a character device with ioctls that allow tuning
of the PTP
This PTP clock simply uses the NTP time adjustment system calls. The
driver can be used in systems that lack a special hardware PTP clock.
Signed-off-by: Richard Cochran richard.coch...@omicron.at
---
drivers/ptp/Kconfig | 12
drivers/ptp/Makefile|1 +
drivers/ptp/ptp_linux.c
The eTSEC includes a PTP clock with quite a few features. This patch adds
support for the basic clock adjustment functions, plus two external time
stamps and one alarm.
Signed-off-by: Richard Cochran richard.coch...@omicron.at
---
Documentation/powerpc/dts-bindings/fsl/tsec.txt | 54 +++
This patch adds a driver for the hardware time stamping unit found on the
IXP465. Only the basic clock operations are implemented.
Signed-off-by: Richard Cochran richard.coch...@omicron.at
---
arch/arm/mach-ixp4xx/include/mach/ixp46x_ts.h | 67 +++
drivers/net/arm/ixp4xx_eth.c
This patch adds support for the PTP clock found on the DP83640. Only the
basic clock operations have been implemented.
Signed-off-by: Richard Cochran richard.coch...@omicron.at
---
drivers/net/phy/Kconfig | 11 +++
drivers/net/phy/dp83640.c | 158
Certain Apple machines don't use the ranges property correctly,
but the
workaround should not be applied on other architectures. This patch
disables the workaround for non-powerpc architectures.
I'm half tempted to add it to the quirk list (which should really be
made generic) so I can
On Tue, Jun 15, 2010 at 10:07 AM, Richard Cochran
richardcoch...@gmail.com wrote:
Two maverick drivers filter the ioctl commands passed to phy_mii_ioctl().
This is unnecessary since phylib will check the command in any case.
Signed-off-by: Richard Cochran richard.coch...@omicron.at
At a
On Tue, Jun 15, 2010 at 10:08 AM, Richard Cochran
richardcoch...@gmail.com wrote:
This patch adds a phy driver method for configuring hardware time stamping.
Drivers may optionally implement this function.
Signed-off-by: Richard Cochran richard.coch...@omicron.at
Adding an ioctl to the
On Tue, Jun 15, 2010 at 10:27:59AM -0600, Grant Likely wrote:
On Tue, Jun 15, 2010 at 10:08 AM, Richard Cochran
richardcoch...@gmail.com wrote:
This patch adds a phy driver method for configuring hardware time stamping.
Drivers may optionally implement this function.
Signed-off-by:
On Tue, Jun 15, 2010 at 10:08 AM, Richard Cochran
richardcoch...@gmail.com wrote:
This patch adds a new networking option to allow hardware time stamps
from PHY devices. Using PHY time stamps will still require adding two
inline function calls to each MAC driver. The CONFIG option makes these
On Tue, Jun 15, 2010 at 10:08 AM, Richard Cochran
richardcoch...@gmail.com wrote:
In order to support hardware time stamping from a PHY, it is necessary to
read from the PHY while running in_interrupt(). This patch allows a mii
bus to operate in an atomic context. An mii_bus driver may declare
On Tue, Jun 15, 2010 at 10:34 AM, Richard Cochran
richardcoch...@gmail.com wrote:
On Tue, Jun 15, 2010 at 10:27:59AM -0600, Grant Likely wrote:
On Tue, Jun 15, 2010 at 10:08 AM, Richard Cochran
richardcoch...@gmail.com wrote:
This patch adds a phy driver method for configuring hardware time
On Tue, Jun 15, 2010 at 10:49 AM, Grant Likely
grant.lik...@secretlab.ca wrote:
On Tue, Jun 15, 2010 at 10:34 AM, Richard Cochran
richardcoch...@gmail.com wrote:
On Tue, Jun 15, 2010 at 10:27:59AM -0600, Grant Likely wrote:
On Tue, Jun 15, 2010 at 10:08 AM, Richard Cochran
On Tue, Jun 15, 2010 at 10:09 AM, Richard Cochran
richardcoch...@gmail.com wrote:
This patch adds an infrastructure for hardware clocks that implement
IEEE 1588, the Precision Time Protocol (PTP). A class driver offers a
registration method to particular hardware clock drivers. Each clock is
On Tue, Jun 15, 2010 at 10:43:08AM -0600, Grant Likely wrote:
On Tue, Jun 15, 2010 at 10:08 AM, Richard Cochran
richardcoch...@gmail.com wrote:
In order to support hardware time stamping from a PHY, it is necessary to
read from the PHY while running in_interrupt(). This patch allows a mii
On Tue, Jun 15, 2010 at 10:10 AM, Richard Cochran
richardcoch...@gmail.com wrote:
The eTSEC includes a PTP clock with quite a few features. This patch adds
support for the basic clock adjustment functions, plus two external time
stamps and one alarm.
Signed-off-by: Richard Cochran
On Tue, Jun 15, 2010 at 11:08 AM, Richard Cochran
richardcoch...@gmail.com wrote:
On Tue, Jun 15, 2010 at 10:43:08AM -0600, Grant Likely wrote:
On Tue, Jun 15, 2010 at 10:08 AM, Richard Cochran
richardcoch...@gmail.com wrote:
In order to support hardware time stamping from a PHY, it is
On Tue, Jun 15, 2010 at 10:10 AM, Richard Cochran
richardcoch...@gmail.com wrote:
This patch adds a driver for the hardware time stamping unit found on the
IXP465. Only the basic clock operations are implemented.
Signed-off-by: Richard Cochran richard.coch...@omicron.at
Hi Richard,
Comments
On Tue, Jun 15, 2010 at 10:10 AM, Richard Cochran
richardcoch...@gmail.com wrote:
This patch adds support for the PTP clock found on the DP83640. Only the
basic clock operations have been implemented.
Signed-off-by: Richard Cochran richard.coch...@omicron.at
---
drivers/net/phy/Kconfig |
On Tue, Jun 15, 2010 at 10:09 AM, Richard Cochran
richardcoch...@gmail.com wrote:
This patch adds an infrastructure for hardware clocks that implement
IEEE 1588, the Precision Time Protocol (PTP). A class driver offers a
registration method to particular hardware clock drivers. Each clock is
Jan-Bernd Themann ossth...@de.ibm.com wrote:
In the eHEA poll function an rmb() is required. Without that some packets
on the receive queue are not seen and thus delayed until the next interrupt
is handled for the same receive queue.
Signed-off-by: Jan-Bernd Themann them...@de.ibm.com
Work around a silicon bug in the ac97 reset functionality of the
mpc5200(b). The implementation of the ac97 cold reset is flawed.
If the sync and output lines are high when reset is asserted the
attached ac97 device may go into test mode. Avoid this by
reconfiguring the psc to gpio mode and
I am trying to port a DSA (Distributed Switch Architecture) driver for
the Micrel KS8995M managed switch connected to a MPC5200. There is an
SPI interface and MII interface managed by the DSA driver.
I can't understand how probe gets called when the flatted device tree
(FDT) system is used, and
Dmitry Eremin-Solenikov wrote:
According to my schematics, on Lite5200 board ethernet phy uses address
0 (all ADDR lines are pulled down). With this change I can talk to
onboard phy (LXT971) and correctly use autonegotiation.
What about this patch?
--
With best wishes
Dmitry
I am trying to port a DSA (Distributed Switch Architecture) driver for
the Micrel KS8995M managed switch connected to a MPC5200. There is an
SPI interface and MII interface managed by the DSA driver.
I can't understand how probe gets called when the flatted device tree
(FDT) system is used,
On Tue, 2010-06-15 at 18:23 +0200, Segher Boessenkool wrote:
Certain Apple machines don't use the ranges property correctly,
but the
workaround should not be applied on other architectures. This patch
disables the workaround for non-powerpc architectures.
I'm half tempted to add it
crash_kexec_wait_realmode() is defined only if CONFIG_PPC_STD_MMU_64
and CONFIG_SMP, but is called if CONFIG_PPC_STD_MMU_64 even if !CONFIG_SMP.
Fix the conditional compilation around the invocation.
Untested, probably does not compile.
Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com
CCed linuxppc-dev to fish for an ack.
On Mon, Jun 14, 2010 at 02:38:42PM -0500, Matthew McClintock wrote:
Booting with uImage-ppc was broken by previous work, this
patch should restore it to working order
Signed-off-by: Matthew McClintock m...@freescale.com
---
kexec/arch/ppc/kexec-ppc.c
On Tue, Jun 15, 2010 at 10:33:51AM -0600, Grant Likely wrote:
+config NETWORK_PHY_TIMESTAMPING
Some overhead? At a brief glance of the series it looks like it could
add a lot of overhead, but I'm not fully clear on what the full
process is. Can you describe how the hardware timestamping
52 matches
Mail list logo
