* [PATCH 2/2 v2] sound/soc: mpc5200_psc_ac97: Use gpio pins for cold reset.
From: Eric Millbrandt @ 2010-06-09 15:54 UTC (permalink / raw)
To: Grant Likely; +Cc: Mark Brown, linuxppc-dev, Eric Millbrandt
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 generating the reset manually.
>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 zero during the reset phase. To do
that, the pin muxing should switch to GPIO mode and the GPIO control
register should be used to control the output lines."
Signed-off-by: Eric Millbrandt <emillbrandt@dekaresearch.com>
---
changes since v1
- Amended with comments from Mark Brown
- Fall back to the original reset implementation if no gpio pins are define=
d
in the device tree
arch/powerpc/boot/dts/lite5200.dts | 3 +
arch/powerpc/boot/dts/lite5200b.dts | 3 +
arch/powerpc/boot/dts/pcm030.dts | 3 +
arch/powerpc/boot/dts/pcm032.dts | 3 +
sound/soc/fsl/mpc5200_dma.h | 5 ++
sound/soc/fsl/mpc5200_psc_ac97.c | 98 +++++++++++++++++++++++++++++++=
++--
6 files changed, 111 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/lite5200.dts b/arch/powerpc/boot/dts/lit=
e5200.dts
index 82ff2b1..cb4e49b 100644
--- a/arch/powerpc/boot/dts/lite5200.dts
+++ b/arch/powerpc/boot/dts/lite5200.dts
@@ -180,6 +180,9 @@
// compatible =3D "fsl,mpc5200-psc-ac97";
// cell-index =3D <1>;
// reg =3D <0x2200 0x100>;
+ // gpios =3D <&gpio 7 0 /* AC97_1_RES */
+ // &gpio_simple 29 0 /* AC97_1_SYNC */
+ // &gpio_simple 31 0>; /* AC97_1_SDATA_OUT=
*/
// interrupts =3D <2 2 0>;
//};
diff --git a/arch/powerpc/boot/dts/lite5200b.dts b/arch/powerpc/boot/dts/li=
te5200b.dts
index e45a63b..1fb0ac7 100644
--- a/arch/powerpc/boot/dts/lite5200b.dts
+++ b/arch/powerpc/boot/dts/lite5200b.dts
@@ -184,6 +184,9 @@
// compatible =3D "fsl,mpc5200b-psc-ac97","fsl,mpc5200=
-psc-ac97";
// cell-index =3D <1>;
// reg =3D <0x2200 0x100>;
+ // gpios =3D <&gpio 7 0 /* AC97_1_RES */
+ // &gpio_simple 29 0 /* AC97_1_SYNC */
+ // &gpio_simple 31 0>; /* AC97_1_SDATA_OUT=
*/
// interrupts =3D <2 2 0>;
//};
diff --git a/arch/powerpc/boot/dts/pcm030.dts b/arch/powerpc/boot/dts/pcm03=
0.dts
index 8a4ec30..0085e0f 100644
--- a/arch/powerpc/boot/dts/pcm030.dts
+++ b/arch/powerpc/boot/dts/pcm030.dts
@@ -189,6 +189,9 @@
compatible =3D "mpc5200b-psc-ac97","fsl,mpc5200b-ps=
c-ac97";
cell-index =3D <0>;
reg =3D <0x2000 0x100>;
+ gpios =3D <&gpio 7 0 /* AC97_1_RES */
+ &gpio_simple 29 0 /* AC97_1_SYNC */
+ &gpio_simple 31 0>; /* AC97_1_SDATA_OUT=
*/
interrupts =3D <2 1 0>;
};
diff --git a/arch/powerpc/boot/dts/pcm032.dts b/arch/powerpc/boot/dts/pcm03=
2.dts
index 85d857a..76f86d3 100644
--- a/arch/powerpc/boot/dts/pcm032.dts
+++ b/arch/powerpc/boot/dts/pcm032.dts
@@ -189,6 +189,9 @@
compatible =3D "fsl,mpc5200b-psc-ac97","fsl,mpc5200=
-psc-ac97";
cell-index =3D <0>;
reg =3D <0x2000 0x100>;
+ gpios =3D <&gpio 7 0 /* AC97_1_RES */
+ &gpio_simple 29 0 /* AC97_1_SYNC */
+ &gpio_simple 31 0>; /* AC97_1_SDATA_OUT=
*/
interrupts =3D <2 1 0>;
};
diff --git a/sound/soc/fsl/mpc5200_dma.h b/sound/soc/fsl/mpc5200_dma.h
index 22208b3..9fb0248 100644
--- a/sound/soc/fsl/mpc5200_dma.h
+++ b/sound/soc/fsl/mpc5200_dma.h
@@ -61,6 +61,11 @@ struct psc_dma {
int id;
unsigned int slots;
+ /* gpio pins locations for cold reset */
+ int reset_gpio;
+ int sync_gpio;
+ int out_gpio;
+
/* per-stream data */
struct psc_dma_stream playback;
struct psc_dma_stream capture;
diff --git a/sound/soc/fsl/mpc5200_psc_ac97.c b/sound/soc/fsl/mpc5200_psc_a=
c97.c
index e2ee220..08cd51f 100644
--- a/sound/soc/fsl/mpc5200_psc_ac97.c
+++ b/sound/soc/fsl/mpc5200_psc_ac97.c
@@ -9,8 +9,10 @@
* published by the Free Software Foundation.
*/
+#include <linux/gpio.h>
#include <linux/module.h>
#include <linux/of_device.h>
+#include <linux/of_gpio.h>
#include <linux/of_platform.h>
#include <linux/delay.h>
@@ -20,12 +22,17 @@
#include <asm/time.h>
#include <asm/delay.h>
+#include <asm/mpc52xx.h>
#include <asm/mpc52xx_psc.h>
#include "mpc5200_dma.h"
#include "mpc5200_psc_ac97.h"
#define DRV_NAME "mpc5200-psc-ac97"
+#define MPC52xx_GPIO_PSC1_MASK 0x7
+#define MPC52xx_GPIO_PSC2_MASK (0x7<<4)
+#define MPC52xx_AC97_PSC1 0x2
+#define MPC52xx_AC97_PSC2 (0x2<<4)
/* ALSA only supports a single AC97 device so static is recommend here */
static struct psc_dma *psc_dma;
@@ -100,19 +107,84 @@ static void psc_ac97_warm_reset(struct snd_ac97 *ac97=
)
{
struct mpc52xx_psc __iomem *regs =3D psc_dma->psc_regs;
+ mutex_lock(&psc_dma->mutex);
+
out_be32(®s->sicr, psc_dma->sicr | MPC52xx_PSC_SICR_AWR);
udelay(3);
out_be32(®s->sicr, psc_dma->sicr);
+
+ mutex_unlock(&psc_dma->mutex);
}
static void psc_ac97_cold_reset(struct snd_ac97 *ac97)
{
struct mpc52xx_psc __iomem *regs =3D psc_dma->psc_regs;
+ u32 gpio_mux;
+
+ mutex_lock(&psc_dma->mutex);
+
+ if ((psc_dma->reset_gpio < 0) ||
+ (psc_dma->sync_gpio < 0) ||
+ (psc_dma->out_gpio < 0)) {
+ /* Use the psc function to do a cold reset */
+ out_8(®s->op1, MPC52xx_PSC_OP_RES);
+ udelay(10);
+ out_8(®s->op0, MPC52xx_PSC_OP_RES);
+ goto warm;
+ }
+
+ /* Reconfigure pin-muxing to gpio */
+ switch (psc_dma->id) {
+ case 0:
+ gpio_mux =3D MPC52xx_GPIO_PSC1_MASK;
+ break;
+ case 1:
+ gpio_mux =3D MPC52xx_GPIO_PSC2_MASK;
+ break;
+ default:
+ dev_err(psc_dma->dev,
+ "Unable to determine PSC, no cold-reset will be "
+ "performed\n");
+ goto warm;
+ }
+
+ dev_info(psc_dma->dev, "cold reset\n");
+ mpc52xx_write_port_config(~gpio_mux, 1);
+
+ /* Assert cold reset */
+ gpio_direction_output(psc_dma->sync_gpio, 0);
+ gpio_direction_output(psc_dma->out_gpio, 0);
+ gpio_direction_output(psc_dma->reset_gpio, 0);
+
+ /* Notify the PSC that a cold reset is occurring */
+ out_be32(®s->sicr, 0);
+ udelay(2);
+
+ /* Deassert reset */
+ gpio_direction_output(psc_dma->reset_gpio, 1);
+ msleep(1);
+
+ /* Restore pin-muxing */
+ switch (psc_dma->id) {
+ case 0:
+ gpio_mux =3D MPC52xx_AC97_PSC1;
+ break;
+ case 1:
+ gpio_mux =3D MPC52xx_AC97_PSC2;
+ break;
+ default:
+ goto warm;
+ }
+
+ mpc52xx_write_port_config(gpio_mux, 0);
+
+ /* Restore the serial interface mode to AC97 */
+ out_be32(®s->sicr, psc_dma->sicr);
+ out_8(®s->command, MPC52xx_PSC_TX_ENABLE | MPC52xx_PSC_RX_ENABLE=
);
+
+warm:
+ mutex_unlock(&psc_dma->mutex);
- /* Do a cold reset */
- out_8(®s->op1, MPC52xx_PSC_OP_RES);
- udelay(10);
- out_8(®s->op0, MPC52xx_PSC_OP_RES);
msleep(1);
psc_ac97_warm_reset(ac97);
}
@@ -287,6 +359,24 @@ static int __devinit psc_ac97_of_probe(struct of_devic=
e *op,
regs =3D psc_dma->psc_regs;
ac97.private_data =3D psc_dma;
+ psc_dma->reset_gpio =3D of_get_gpio_flags(op->dev.of_node, 0, NULL)=
;
+ psc_dma->sync_gpio =3D of_get_gpio_flags(op->dev.of_node, 1, NULL);
+ psc_dma->out_gpio =3D of_get_gpio_flags(op->dev.of_node, 2, NULL);
+ if ((psc_dma->reset_gpio < 0) ||
+ (psc_dma->sync_gpio < 0) ||
+ (psc_dma->out_gpio < 0)) {
+ dev_err(&op->dev, "error: cannot get GPIO pins; "
+ "reset=3D%i sync=3D%i out=3D%i, defaulting to norma=
l ac97 "
+ "reset\n",
+ psc_dma->reset_gpio,
+ psc_dma->sync_gpio,
+ psc_dma->out_gpio);
+ } else {
+ gpio_request(psc_dma->reset_gpio, "psc_dma-reset");
+ gpio_request(psc_dma->sync_gpio, "psc_dma-sync");
+ gpio_request(psc_dma->out_gpio, "psc_dma-out");
+ }
+
for (i =3D 0; i < ARRAY_SIZE(psc_ac97_dai); i++)
psc_ac97_dai[i].private_data =3D psc_dma;
--
1.6.3.1
This e-mail and the information, including any attachments, it contains are=
intended to be a confidential communication only to the person or entity t=
o whom it is addressed and may contain information that is privileged. If t=
he reader of this message is not the intended recipient, you are hereby not=
ified that any dissemination, distribution or copying of this communication=
is strictly prohibited. If you have received this communication in error, =
please immediately notify the sender and destroy the original message.
Thank you.
Please consider the environment before printing this email.
^ permalink raw reply related
* Re: [PATCH 0/2] mpc5200 ac97 gpio reset
From: Mark Brown @ 2010-06-09 15:11 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev@lists.ozlabs.org, Eric Millbrandt, Wolfgang Denk
In-Reply-To: <AANLkTinxoQ7PL2OssJc5dZi2WnhkXMaTTGR7OVWxqL2g@mail.gmail.com>
On Wed, Jun 09, 2010 at 10:41:23AM -0400, Jon Smirl wrote:
> On Wed, Jun 9, 2010 at 10:32 AM, Mark Brown
> > Please include this quote in the changelog for the patch, if this a
> > documented workaround from the vendor that's a very different thing to
> > something that you've found happens to work on your systems (which is
> > more what your changelog sounded like).
> Mark, is there a way to ask the chip if it is in test mode? We need to
> be sure that's whats happening and it isn't some other glitch.
I'd need to work with the hardware teams to obtain this information, but
I can confirm that having SYNC high while doing a reset is not supported
and so fixing the driver to not do that is a good idea independantly of
what it actually does to the chip.
^ permalink raw reply
* [tip:irq/urgent] genirq: Deal with desc->set_type() changing desc->chip
From: tip-bot for Thomas Gleixner @ 2010-06-09 15:06 UTC (permalink / raw)
To: linux-tip-commits; +Cc: eha, linuxppc-dev, mingo, hpa, tglx
Commit-ID: 4673247562e39a17e09440fa1400819522ccd446
Gitweb: http://git.kernel.org/tip/4673247562e39a17e09440fa1400819522ccd446
Author: Thomas Gleixner <tglx@linutronix.de>
AuthorDate: Mon, 7 Jun 2010 17:53:51 +0200
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitDate: Wed, 9 Jun 2010 17:05:08 +0200
genirq: Deal with desc->set_type() changing desc->chip
The set_type() function can change the chip implementation when the
trigger mode changes. That might result in using an non-initialized
irq chip when called from __setup_irq() or when called via
set_irq_type() on an already enabled irq.
The set_irq_type() function should not be called on an enabled irq,
but because we forgot to put a check into it, we have a bunch of users
which grew the habit of doing that and it never blew up as the
function is serialized via desc->lock against all users of desc->chip
and they never hit the non-initialized irq chip issue.
The easy fix for the __setup_irq() issue would be to move the
irq_chip_set_defaults(desc->chip) call after the trigger setting to
make sure that a chip change is covered.
But as we have already users, which do the type setting after
request_irq(), the safe fix for now is to call irq_chip_set_defaults()
from __irq_set_trigger() when desc->set_type() changed the irq chip.
It needs a deeper analysis whether we should refuse to change the chip
on an already enabled irq, but that'd be a large scale change to fix
all the existing users. So that's neither stable nor 2.6.35 material.
Reported-by: Esben Haabendal <eha@doredevelopment.dk>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>
Cc: stable@kernel.org
---
kernel/irq/manage.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 3164ba7..e149748 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -456,6 +456,9 @@ int __irq_set_trigger(struct irq_desc *desc, unsigned int irq,
/* note that IRQF_TRIGGER_MASK == IRQ_TYPE_SENSE_MASK */
desc->status &= ~(IRQ_LEVEL | IRQ_TYPE_SENSE_MASK);
desc->status |= flags;
+
+ if (chip != desc->chip)
+ irq_chip_set_defaults(desc->chip);
}
return ret;
^ permalink raw reply related
* Re: [PATCH 0/2] mpc5200 ac97 gpio reset
From: Jon Smirl @ 2010-06-09 14:41 UTC (permalink / raw)
To: Mark Brown; +Cc: linuxppc-dev@lists.ozlabs.org, Eric Millbrandt, Wolfgang Denk
In-Reply-To: <20100609143246.GA17945@opensource.wolfsonmicro.com>
On Wed, Jun 9, 2010 at 10:32 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Wed, Jun 09, 2010 at 10:21:40AM -0400, Eric Millbrandt wrote:
>
> [Please fix your MUA to word wrap paragraphs to within 80 characters,
> I've reflowed the text below.]
>
>> From the MPC5200B user 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 zero during the reset phase. To do
>> that, the pin muxing should switch to GPIO mode and the GPIO control
>> register should be used to control the output lines."
>
> Please include this quote in the changelog for the patch, if this a
> documented workaround from the vendor that's a very different thing to
> something that you've found happens to work on your systems (which is
> more what your changelog sounded like).
>
Mark, is there a way to ask the chip if it is in test mode? We need to
be sure that's whats happening and it isn't some other glitch.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* can you give me some advice to test "dTSEC"
From: lei yang @ 2010-06-09 14:40 UTC (permalink / raw)
To: linuxppc-dev
Hi experts
can you give me some advice to test "dTSEC"
Lei
^ permalink raw reply
* CPM UART on MPC8270
From: Martyn Welch @ 2010-06-09 14:37 UTC (permalink / raw)
To: linuxppc-dev list
Hi All,
I'm attempting to get an SCC port on an MPC8270 working with Linux. I'm
not overly familiar with the CPM and am having a bit of trouble.
Linux is booting natively on the 8270. I have access to the 8270 via a
set of PCI windows from a second core (includes one setup over the main
memory and one over the IMMR) and SMC1 is up and working with a console.
The SCCs seem to be detected correctly at boot:
f011a80.serial: ttyCPM0 at MMIO 0xc3014a80 (irq = 16) is a CPM UART
f011a00.serial: ttyCPM1 at MMIO 0xc3018a00 (irq = 40) is a CPM UART
f011a20.serial: ttyCPM2 at MMIO 0xc3020a20 (irq = 41) is a CPM UART
f011a40.serial: ttyCPM3 at MMIO 0xc3028a40 (irq = 42) is a CPM UART
With the DTS reading:
smc1: serial@11a80 {
device_type = "serial";
compatible = "fsl,mpc8270-smc-uart",
"fsl,cpm2-smc-uart";
reg = <0x11a80 0x20 0x87fc 2>;
interrupts = <4 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <7>;
fsl,cpm-command = <0x1d000000>;
};
scc1: serial@11a00 {
device_type = "serial";
compatible = "fsl,mpc8270-scc-uart",
"fsl,cpm2-scc-uart";
reg = <0x11a00 0x20 0x8000 0x100>;
interrupts = <40 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <3>;
fsl,cpm-command = <0x800000>;
};
scc2: serial@11a20 {
device_type = "serial";
compatible = "fsl,mpc8270-scc-uart",
"fsl,cpm2-scc-uart";
reg = <0x11a20 0x20 0x8100 0x100>;
interrupts = <41 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <6>;
fsl,cpm-command = <0x4a00000>;
};
scc3: serial@11a40 {
device_type = "serial";
compatible = "fsl,mpc8270-scc-uart",
"fsl,cpm2-scc-uart";
reg = <0x11a40 0x20 0x8200 0x100>;
interrupts = <42 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <0x8c00000>;
};
I believe that I have the pins setup correctly and the BRGs connected
correctly in the setup_arch function.
At the moment I have SCC3 wired out. If I attempt to echo data out of
the SCC (echo "Hello" > /dev/ttyCPM3) I get the prompt sits waiting.
Rebooting and turning on the debug yields the following output on the
console (but nothing out of the SCC port):
CPM uart[3]:startup
Interrupt attached
CPM uart[3]:set_termios
CPM uart[3]:start tx
CPM uart[3]:stop tx
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:stop rx
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:shutdown
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
CPM uart[3]:tx_empty: 0
...
It seemed to be waiting for ready bit of the Transmit Buffer Descriptor
to be cleared (which it never seems to be), prodding this bit through
the pci window did cause the process to continue, no data out but I did
get back to the prompt on the console.
I'm sure I'm just missing something really basic - can anyone enlighten me?
Martyn
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at 100
T +44(0)127322748 | Barbirolli Square, Manchester,
E martyn.welch@ge.com | M2 3AB VAT:GB 927559189
^ permalink raw reply
* Re: [PATCH 0/2] mpc5200 ac97 gpio reset
From: Mark Brown @ 2010-06-09 14:32 UTC (permalink / raw)
To: Eric Millbrandt; +Cc: linuxppc-dev@lists.ozlabs.org, Wolfgang Denk
In-Reply-To: <0A40042D85E7C84DB443060EC44B3FD3253ECB8C84@dekaexchange07.deka.local>
On Wed, Jun 09, 2010 at 10:21:40AM -0400, Eric Millbrandt wrote:
[Please fix your MUA to word wrap paragraphs to within 80 characters,
I've reflowed the text below.]
> From the MPC5200B user 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 zero during the reset phase. To do
> that, the pin muxing should switch to GPIO mode and the GPIO control
> register should be used to control the output lines."
Please include this quote in the changelog for the patch, if this a
documented workaround from the vendor that's a very different thing to
something that you've found happens to work on your systems (which is
more what your changelog sounded like).
^ permalink raw reply
* RE: [PATCH 0/2] mpc5200 ac97 gpio reset
From: Eric Millbrandt @ 2010-06-09 14:24 UTC (permalink / raw)
To: 'Mark Brown', Wolfgang Denk; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20100609103046.GC5618@opensource.wolfsonmicro.com>
> -----Original Message-----
> From: Mark Brown [mailto:broonie@opensource.wolfsonmicro.com]
> Sent: Wednesday, June 09, 2010 06:31
> To: Wolfgang Denk
> Cc: Jon Smirl; Eric Millbrandt; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH 0/2] mpc5200 ac97 gpio reset
--snip--
> It might, however, be sensible to make the GPIO based reset be optional
> based on having the OF data for the GPIOs. That way existing DTs will
> work without changes and systems that can use the reset implementation
> in the controller will be able to do so.
This is a reasonable request. I will respin the patch to do this.
Eric Millbrandt
This e-mail and the information, including any attachments, it contains are=
intended to be a confidential communication only to the person or entity t=
o whom it is addressed and may contain information that is privileged. If t=
he reader of this message is not the intended recipient, you are hereby not=
ified that any dissemination, distribution or copying of this communication=
is strictly prohibited. If you have received this communication in error, =
please immediately notify the sender and destroy the original message.
Thank you.
Please consider the environment before printing this email.
^ permalink raw reply
* RE: [PATCH 0/2] mpc5200 ac97 gpio reset
From: Eric Millbrandt @ 2010-06-09 14:21 UTC (permalink / raw)
To: 'Jon Smirl', Wolfgang Denk
Cc: Mark Brown, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <AANLkTikDE14Y_r7nMpj5lNMy5anAyU3cuLjk_uxStHvo@mail.gmail.com>
> -----Original Message-----
> From: Jon Smirl [mailto:jonsmirl@gmail.com]
> Sent: Wednesday, June 09, 2010 08:22
> To: Wolfgang Denk
> Cc: Eric Millbrandt; Mark Brown; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH 0/2] mpc5200 ac97 gpio reset
>
> On Wed, Jun 9, 2010 at 2:13 AM, Wolfgang Denk <wd@denx.de> wrote:
> > Dear Jon Smirl,
> >
> > In message <AANLkTimIs90kR5uqhdBQ02oSd94dn08sOITm51Ylrl4-
> @mail.gmail.com> you wrote:
> >>
> >> Would making a change in uboot be a better solution? Eric, can you
> >> verify if changing uboot also fixes the problem?
> >
> > To me it seems better if the driver itself does what needs to be done
> > instead of relying on specific settings that may or may not be done in
> > U-Boot. Keep in mind that drivers may be loaded as modules, and that
> > we even see cases where the same port serves multiple purposes by
> > loading different driver modules (yes, this is not exactly a clever
> > idea, but hardware designers come up with such solutions).
>
>
> Someone with a scope can verify this, but my understanding of what
> happens is that uboot by default puts the pins into GPIO mode. Linux
> boots and reprograms the pins into AC97 mode. When the pins are
> reprogrammed it generates glitches on the reset line. About half of
> the time these glitches put the attached codec into test mode. Once
> the chip is in test mode it won't respond to normal commands.
>
Most of the pins on the 5200 default to gpio when the chip comes out of res=
et. U-Boot then sets the pin muxing by writing to the port configuration r=
egister. This value is defined as CONFIG_SYS_GPS_PORT_CONFIG in the U-Boot=
board header file.
The implementation of ac97 gives the codec control of the bus clock. This =
means that the codec is usually be clocking BITCLK when the 5200 pulls the =
reset line low, which is the cause of the problem. Freescale should have h=
andled this on the silicon by having the ac97 cold reset function pull the =
SYNC and SDATAOUT lines low during cold reset, but instead they just docume=
nted the problem.
>From the MPC5200B user 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 b=
e also forced to zero during the reset phase. To do that, the pin muxing sh=
ould switch to GPIO mode and the GPIO control register should be used to co=
ntrol the output lines."
> Another strategy would be to leave reset as is. If the chip is
> unresponsive send it the commands to get it out of test mode. That
> could be made part of the reset logic in the Linux driver.
This is what we used to do when we were using the out-of-tree ac97 driver f=
rom Sylvain Munaut. We would generate a cold reset/warm reset sequence in =
U-Boot. We modified the Linux ac97 driver so that the cold reset functions=
was a no-op. It did avoid the problem, but it caused other problems. Som=
etimes it is necessary to cold reset the codec in Linux to resync the ac97 =
bus.
>
>
> >
> >
> > Best regards,
> >
> > Wolfgang Denk
> >
> > --
> > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> > The typical page layout program is nothing more than an electronic
> > light table for cutting and pasting documents.
> >
>
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
Eric Millbrandt
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-
This e-mail and the information, including any attachments, it contains are=
intended to be a confidential communication only to the person or entity t=
o whom it is addressed and may contain information that is privileged. If t=
he reader of this message is not the intended recipient, you are hereby not=
ified that any dissemination, distribution or copying of this communication=
is strictly prohibited. If you have received this communication in error, =
please immediately notify the sender and destroy the original message.
Thank you.
Please consider the environment before printing this email.
^ permalink raw reply
* Re: [PATCH 3/5] Removing dead CONFIG_SMP_750
From: Josh Boyer @ 2010-06-09 12:35 UTC (permalink / raw)
To: Christoph Egger; +Cc: vamos, Paul Mackerras, linux-kernel, linuxppc-dev
In-Reply-To: <8bf8cfaf47590e1a85f9510bb546ca35e3458bf8.1275925219.git.siccegge@cs.fau.de>
On Wed, Jun 09, 2010 at 12:00:21PM +0200, Christoph Egger wrote:
>CONFIG_SMP_750 doesn't exist in Kconfig, therefore removing all
>references for it from the source code.
Yeah, we don't support SMP on 750 at the moment. This code was carried over
from the arch/ppc days, and that code was present pre-git. I think we can
drop it, but I'll leave that up to Ben. Maybe he has crazy plans for a 750 SMP
board.
josh
>
>Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
>---
> arch/powerpc/mm/tlb_hash32.c | 4 ----
> 1 files changed, 0 insertions(+), 4 deletions(-)
>
>diff --git a/arch/powerpc/mm/tlb_hash32.c b/arch/powerpc/mm/tlb_hash32.c
>index 8aaa8b7..925fecb 100644
>--- a/arch/powerpc/mm/tlb_hash32.c
>+++ b/arch/powerpc/mm/tlb_hash32.c
>@@ -94,11 +94,7 @@ void tlb_flush(struct mmu_gather *tlb)
> * the cache operations on the bus. Hence we need to use an IPI
> * to get the other CPU(s) to invalidate their TLBs.
> */
>-#ifdef CONFIG_SMP_750
>-#define FINISH_FLUSH smp_send_tlb_invalidate(0)
>-#else
> #define FINISH_FLUSH do { } while (0)
>-#endif
>
> static void flush_range(struct mm_struct *mm, unsigned long start,
> unsigned long end)
>--
>1.6.3.3
>
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev@lists.ozlabs.org
>https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 0/2] mpc5200 ac97 gpio reset
From: Jon Smirl @ 2010-06-09 12:21 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Mark Brown, linuxppc-dev, Eric Millbrandt
In-Reply-To: <20100609061330.620AC14E867@gemini.denx.de>
On Wed, Jun 9, 2010 at 2:13 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Jon Smirl,
>
> In message <AANLkTimIs90kR5uqhdBQ02oSd94dn08sOITm51Ylrl4-@mail.gmail.com>=
you wrote:
>>
>> Would making a change in uboot be a better solution? Eric, can you
>> verify if changing uboot also fixes the problem?
>
> To me it seems better if the driver itself does what needs to be done
> instead of relying on specific settings that may or may not be done in
> U-Boot. Keep in mind that drivers may be loaded as modules, and that
> we even see cases where the same port serves multiple purposes by
> loading different driver modules (yes, this is not exactly a clever
> idea, but hardware designers come up with such solutions).
Someone with a scope can verify this, but my understanding of what
happens is that uboot by default puts the pins into GPIO mode. Linux
boots and reprograms the pins into AC97 mode. When the pins are
reprogrammed it generates glitches on the reset line. About half of
the time these glitches put the attached codec into test mode. Once
the chip is in test mode it won't respond to normal commands.
Does the opposite happen? What if uboot has the pins in AC97 mode and
Linux reprograms them into GPIO mode. Will it also put the chip into
test mode? The piece of information I've been missing is an
understanding of what is making the glitches that trigger test mode.
Another strategy would be to leave reset as is. If the chip is
unresponsive send it the commands to get it out of test mode. That
could be made part of the reset logic in the Linux driver.
>
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, =A0 =A0 MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> The typical page layout program is nothing more =A0than =A0an =A0electron=
ic
> light table for cutting and pasting documents.
>
--=20
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Please pull 'merge' branch of 4xx tree
From: Josh Boyer @ 2010-06-09 12:09 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Hi Ben,
Two small fixes that should go into 2.6.35. Please pull them and shuffle along
to Linus. I know Linus is leaving for a while at the end of this week, so if
you want me to ask him to pull directly just let me know.
josh
The following changes since commit c2cdf6aba0dfcfb54be646ab630c1bccd180e890:
Benjamin Herrenschmidt (1):
powerpc/macio: Fix probing of macio devices by using the right of match table
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git merge
Christoph Egger (1):
powerpc/47x: Correct typo in ifdef guard for 47x
Stefan Roese (1):
powerpc/44x: Fix UART2/3 interrupt assignment in PPC460EX/GT dts files
arch/powerpc/boot/dts/canyonlands.dts | 4 ++--
arch/powerpc/boot/dts/glacier.dts | 4 ++--
arch/powerpc/mm/44x_mmu.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
^ permalink raw reply
* Re: [PATCH 5b/5] Removing dead CONFIG_PPC47x
From: Josh Boyer @ 2010-06-09 12:05 UTC (permalink / raw)
To: Christoph Egger
Cc: Stephen Rothwell, Dave Kleikamp, vamos, linux-kernel,
linuxppc-dev, Paul Mackerras, Torez Smith
In-Reply-To: <20100609110239.GA28290@faui48a.informatik.uni-erlangen.de>
On Wed, Jun 09, 2010 at 01:02:39PM +0200, Christoph Egger wrote:
>CONFIG_PPC47x should actually be spelled CONFIG_PPC_47x as reported by
>Andreas Schwab.
>
>Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
Thanks, I'll pull this one in and get it merged.
josh
>---
> arch/powerpc/mm/44x_mmu.c | 4 ----
> 1 files changed, 0 insertions(+), 4 deletions(-)
>
>diff --git a/arch/powerpc/mm/44x_mmu.c b/arch/powerpc/mm/44x_mmu.c
>index d8c6efb..f70da7e 100644
>--- a/arch/powerpc/mm/44x_mmu.c
>+++ b/arch/powerpc/mm/44x_mmu.c
>@@ -76,11 +76,11 @@ static void __init ppc44x_pin_tlb(unsigned int virt, unsigned int phys)
> "tlbwe %1,%3,%5\n"
> "tlbwe %0,%3,%6\n"
> :
>-#ifdef CONFIG_PPC47x
>+#ifdef CONFIG_PPC_47x
> : "r" (PPC47x_TLB2_S_RWX),
> #else
> : "r" (PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G),
> #endif
> "r" (phys),
> "r" (virt | PPC44x_TLB_VALID | PPC44x_TLB_256M),
> "r" (entry),
>--
>1.6.3.3
>
^ permalink raw reply
* Re: [PATCH] powerpc: Fix integer constant warning
From: Steve Best @ 2010-06-09 11:50 UTC (permalink / raw)
To: David Howells; +Cc: linuxppc-dev
In-Reply-To: <9000.1276002746@redhat.com>
On Tue, 2010-06-08 at 14:12 +0100, David Howells wrote:
> Steve Best <sfbest@us.ibm.com> wrote:
>
> > -#define KERNELBASE (0xc000000000000000)
> > +#define KERNELBASE (0xc000000000000000ULL)
>
> Is this the right fix? The code producing the warning is subtracting
> 0xc000000000000000 from a 32-bit number:
agree this fix needs more work, and can be dropped. Paul has another
patch that removes this file, since it is no longer used. I assume we'll
go with that patch.
>
> naca = ntohl(*((u_int32_t*) &inbuf[0x0C])) - KERNELBASE;
>
> which seems distinctly odd.
>
> David
-Steve
^ permalink raw reply
* [PATCH 5b/5] Removing dead CONFIG_PPC47x
From: Christoph Egger @ 2010-06-09 11:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Stephen Rothwell,
Torez Smith, Dave Kleikamp, Josh Boyer, linuxppc-dev,
linux-kernel
Cc: vamos
In-Reply-To: <cover.1275925219.git.siccegge@cs.fau.de>
CONFIG_PPC47x should actually be spelled CONFIG_PPC_47x as reported by
Andreas Schwab.
Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
---
arch/powerpc/mm/44x_mmu.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/mm/44x_mmu.c b/arch/powerpc/mm/44x_mmu.c
index d8c6efb..f70da7e 100644
--- a/arch/powerpc/mm/44x_mmu.c
+++ b/arch/powerpc/mm/44x_mmu.c
@@ -76,11 +76,11 @@ static void __init ppc44x_pin_tlb(unsigned int virt, unsigned int phys)
"tlbwe %1,%3,%5\n"
"tlbwe %0,%3,%6\n"
:
-#ifdef CONFIG_PPC47x
+#ifdef CONFIG_PPC_47x
: "r" (PPC47x_TLB2_S_RWX),
#else
: "r" (PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G),
#endif
"r" (phys),
"r" (virt | PPC44x_TLB_VALID | PPC44x_TLB_256M),
"r" (entry),
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 0/2] mpc5200 ac97 gpio reset
From: Mark Brown @ 2010-06-09 10:30 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, Eric Millbrandt
In-Reply-To: <20100609061330.620AC14E867@gemini.denx.de>
On Wed, Jun 09, 2010 at 08:13:30AM +0200, Wolfgang Denk wrote:
> In message <AANLkTimIs90kR5uqhdBQ02oSd94dn08sOITm51Ylrl4-@mail.gmail.com> you wrote:
> > Would making a change in uboot be a better solution? Eric, can you
> > verify if changing uboot also fixes the problem?
> To me it seems better if the driver itself does what needs to be done
> instead of relying on specific settings that may or may not be done in
> U-Boot. Keep in mind that drivers may be loaded as modules, and that
> we even see cases where the same port serves multiple purposes by
> loading different driver modules (yes, this is not exactly a clever
> idea, but hardware designers come up with such solutions).
I do tend to agree that having the driver be able to cope with things is
a bit more robust - it's not terribly discoverable for users and people
are often justifiably nervous about updating their bootloader.
It might, however, be sensible to make the GPIO based reset be optional
based on having the OF data for the GPIOs. That way existing DTs will
work without changes and systems that can use the reset implementation
in the controller will be able to do so.
^ permalink raw reply
* Re: [PATCH 2/2] sound/soc: mpc5200_psc_ac97: Use gpio pins for cold reset.
From: Mark Brown @ 2010-06-09 10:25 UTC (permalink / raw)
To: Eric Millbrandt; +Cc: linuxppc-dev
In-Reply-To: <1276015562-28928-3-git-send-email-emillbrandt@dekaresearch.com>
On Tue, Jun 08, 2010 at 12:46:02PM -0400, Eric Millbrandt wrote:
> + switch (psc_dma->id) {
> + case 0:
> + gpio_mux = MPC52xx_GPIO_PSC1_MASK; break;
> + case 1:
> + gpio_mux = MPC52xx_GPIO_PSC2_MASK; break;
Please don't place the break on the same line as the statement, it's
not good for legibility.
> + dev_err(psc_dma->dev, "cold reset\n");
You shouldn't be logging this as an error, doing a cold reset is
perfectly normal.
^ permalink raw reply
* Re: [Patch 0/5] PPC64-HWBKPT: Hardware Breakpoint interfaces - ver XXII
From: K.Prasad @ 2010-06-09 10:32 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org, Benjamin Herrenschmidt
In-Reply-To: <20100607112559.GA2419@brick.ozlabs.ibm.com>
On Mon, Jun 07, 2010 at 09:25:59PM +1000, Paul Mackerras wrote:
> On Mon, Jun 07, 2010 at 12:33:51PM +0530, K.Prasad wrote:
>
> > Given that 'ptrace_bps' is used only for ptrace originated breakpoints
> > and that we return early i.e. before detecting extraneous interrupts
> > in hw_breakpoint_handler() (as shown above) they shouldn't overlap each
> > other. The following comment in hw_breakpoint_handler() explains the
> > same.
> > /*
> > * To prevent invocation of perf_event_bp(), we shall overload
> > * thread.ptrace_bps[] pointer (unused for non-ptrace
> > * exceptions) to flag an extraneous interrupt which must be
> > * skipped.
> > */
>
> My point is that while we are using ptrace_bps[0] to mark a non-ptrace
> breakpoint that we're single-stepping, some other process could be
> ptracing this process and could get into ptrace_set_debugreg() and
> would think that the process already has a ptrace breakpoint and call
> modify_user_hw_breakpoint() when it should be calling
> register_user_hw_breakpoint(). Or this process could die and so we
> call flush_ptrace_hw_breakpoint() and it incorrectly thinks we have a
> ptrace breakpoint.
>
> If there is a reason why we can be quite sure that while we are using
> current->thread.ptrace_bps[0] in this way, ptrace_set_debugreg() can
> never get called with this task as the ptracee, and nor can
> flush_ptrace_hw_breakpoint() get called on this task, then maybe it's
> safe. But it's not at all obviously safe. So I'd very much rather we
> just use an extra flag somewhere, that isn't used elsewhere for
> anything else, so we can convince ourselves that it is all correct
> without having to look at lots of different pieces of code.
>
> There are 3 bytes of padding in struct arch_hw_breakpoint; couldn't we
> use one of them as a "not really hit" flag?
>
> Paul.
> _______________________________________________
I get your reasoning now; ptrace_bps[] re-use will cause failures under
these circumstances. I've sent a new version of the patchset which adds
a new flag in 'struct arch_hw_breakpoint' (I was always thinking of
'struct thread_struct' before and was scared to introduce another new
member in it, thereby leading me to incorrectly optimise using ptrace_bps)
to flag extraneous_interrupt (Given that it's your idea I've added your
signed-off too).
Kindly let me know your comments, if any.
Thanks,
K.Prasad
^ permalink raw reply
* Re: [PATCH 4/5] Removing dead CONFIG_SERIAL_TEXT_DEBUG
From: Josh Boyer @ 2010-06-09 10:28 UTC (permalink / raw)
To: Christoph Egger; +Cc: vamos, Paul Mackerras, linux-kernel, linuxppc-dev
In-Reply-To: <ddcbd960ff300073939bb0c6f20a38118c0875d4.1275925219.git.siccegge@cs.fau.de>
On Wed, Jun 09, 2010 at 12:00:46PM +0200, Christoph Egger wrote:
>CONFIG_SERIAL_TEXT_DEBUG doesn't exist in Kconfig, therefore removing all
>references for it from the source code.
>
>Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
It would be better to conver this to work with CONFIG_PPC_EARLY_DEBUG and
CONFIG_PPC_EARLY_DEBUG_40x. I'd rather just leave this for now until we can
get it switched over.
josh
>---
> arch/powerpc/kernel/head_40x.S | 19 -------------------
> 1 files changed, 0 insertions(+), 19 deletions(-)
>
>diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S
>index a90625f..1a10e4d 100644
>--- a/arch/powerpc/kernel/head_40x.S
>+++ b/arch/powerpc/kernel/head_40x.S
>@@ -939,25 +939,6 @@ initial_mmu:
> tlbwe r4,r0,TLB_DATA /* Load the data portion of the entry */
> tlbwe r3,r0,TLB_TAG /* Load the tag portion of the entry */
>
>-#if defined(CONFIG_SERIAL_TEXT_DEBUG) && defined(SERIAL_DEBUG_IO_BASE)
>-
>- /* Load a TLB entry for the UART, so that ppc4xx_progress() can use
>- * the UARTs nice and early. We use a 4k real==virtual mapping. */
>-
>- lis r3,SERIAL_DEBUG_IO_BASE@h
>- ori r3,r3,SERIAL_DEBUG_IO_BASE@l
>- mr r4,r3
>- clrrwi r4,r4,12
>- ori r4,r4,(TLB_WR|TLB_I|TLB_M|TLB_G)
>-
>- clrrwi r3,r3,12
>- ori r3,r3,(TLB_VALID | TLB_PAGESZ(PAGESZ_4K))
>-
>- li r0,0 /* TLB slot 0 */
>- tlbwe r4,r0,TLB_DATA
>- tlbwe r3,r0,TLB_TAG
>-#endif /* CONFIG_SERIAL_DEBUG_TEXT && SERIAL_DEBUG_IO_BASE */
>-
> isync
>
> /* Establish the exception vector base
>--
>1.6.3.3
>
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev@lists.ozlabs.org
>https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [Patch 5/5] PPC64-HWBKPT: Discard extraneous interrupt due to accesses outside symbol length
From: K.Prasad @ 2010-06-09 10:25 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org, Paul Mackerras
Cc: Michael Neuling, Benjamin Herrenschmidt, shaggy,
Frederic Weisbecker, David Gibson, Alan Stern, K.Prasad,
Roland McGrath
In-Reply-To: <20100609101417.644628763@linux.vnet.ibm.com>
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 (we don't
want to change ptrace behaviour for fear of breaking compatability).
Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
arch/powerpc/include/asm/hw_breakpoint.h | 1 +
arch/powerpc/kernel/hw_breakpoint.c | 19 ++++++++++++++++++-
2 files changed, 19 insertions(+), 1 deletion(-)
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/hw_breakpoint.c
===================================================================
--- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/hw_breakpoint.c
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/hw_breakpoint.c
@@ -202,6 +202,7 @@ int __kprobes hw_breakpoint_handler(stru
struct pt_regs *regs = args->regs;
int stepped = 1;
struct arch_hw_breakpoint *info;
+ unsigned long dar = regs->dar;
/* Disable breakpoints during exception handling */
set_dabr(0);
@@ -232,6 +233,21 @@ int __kprobes hw_breakpoint_handler(stru
goto out;
}
+ /*
+ * Verify if dar lies within the address range occupied by the symbol
+ * being watched to filter extraneous exceptions.
+ */
+ if (!((bp->attr.bp_addr <= dar) &&
+ (dar <= (bp->attr.bp_addr + bp->attr.bp_len)))) {
+ /*
+ * This exception is triggered not because of a memory access
+ * on the monitored variable but in the double-word address
+ * range in which it is contained. We will consume this
+ * exception, considering it as 'noise'.
+ */
+ info->extraneous_interrupt = true;
+ }
+
/* Do not emulate user-space instructions, instead single-step them */
if (user_mode(regs)) {
bp->ctx->task->thread.last_hit_ubp = bp;
@@ -286,7 +302,8 @@ int __kprobes single_step_dabr_instructi
* We shall invoke the user-defined callback function in the single
* stepping handler to confirm to 'trigger-after-execute' semantics
*/
- perf_bp_event(bp, regs);
+ if (!bp_info->extraneous_interrupt)
+ perf_bp_event(bp, regs);
/*
* Do not disable MSR_SE if the process was already in
Index: linux-2.6.ppc64_test/arch/powerpc/include/asm/hw_breakpoint.h
===================================================================
--- linux-2.6.ppc64_test.orig/arch/powerpc/include/asm/hw_breakpoint.h
+++ linux-2.6.ppc64_test/arch/powerpc/include/asm/hw_breakpoint.h
@@ -27,6 +27,7 @@
#ifdef CONFIG_HAVE_HW_BREAKPOINT
struct arch_hw_breakpoint {
+ bool extraneous_interrupt;
u8 len; /* length of the target data symbol */
int type;
unsigned long address;
^ permalink raw reply
* [Patch 4/5] PPC64-HWBKPT: Enable hw-breakpoints while handling intervening signals
From: K.Prasad @ 2010-06-09 10:25 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org, Paul Mackerras
Cc: Michael Neuling, Benjamin Herrenschmidt, shaggy,
Frederic Weisbecker, David Gibson, Alan Stern, K.Prasad,
Roland McGrath
In-Reply-To: <20100609101417.644628763@linux.vnet.ibm.com>
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 delivery.
Restore hw-breakpoints if the user-context is altered in the signal handler.
Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/hw_breakpoint.h | 3 +++
arch/powerpc/kernel/hw_breakpoint.c | 18 ++++++++++++++++++
arch/powerpc/kernel/signal.c | 3 +++
3 files changed, 24 insertions(+)
Index: linux-2.6.ppc64_test/arch/powerpc/include/asm/hw_breakpoint.h
===================================================================
--- linux-2.6.ppc64_test.orig/arch/powerpc/include/asm/hw_breakpoint.h
+++ linux-2.6.ppc64_test/arch/powerpc/include/asm/hw_breakpoint.h
@@ -65,9 +65,12 @@ static inline void hw_breakpoint_disable
{
set_dabr(0);
}
+extern void thread_change_pc(struct task_struct *tsk, struct pt_regs *regs);
#else /* CONFIG_HAVE_HW_BREAKPOINT */
static inline void hw_breakpoint_disable(void) { }
+static inline void thread_change_pc(struct task_struct *tsk,
+ struct pt_regs *regs) { }
#endif /* CONFIG_HAVE_HW_BREAKPOINT */
#endif /* __KERNEL__ */
#endif /* _PPC_BOOK3S_64_HW_BREAKPOINT_H */
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/hw_breakpoint.c
===================================================================
--- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/hw_breakpoint.c
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/hw_breakpoint.c
@@ -174,6 +174,24 @@ int arch_validate_hwbkpt_settings(struct
}
/*
+ * Restores the breakpoint on the debug registers.
+ * Invoke this function if it is known that the execution context is about to
+ * change to cause loss of MSR_SE settings.
+ */
+void thread_change_pc(struct task_struct *tsk, struct pt_regs *regs)
+{
+ struct arch_hw_breakpoint *info;
+
+ if (likely(!tsk->thread.last_hit_ubp))
+ return;
+
+ info = counter_arch_bp(tsk->thread.last_hit_ubp);
+ regs->msr &= ~MSR_SE;
+ set_dabr(info->address | info->type | DABR_TRANSLATION);
+ tsk->thread.last_hit_ubp = NULL;
+}
+
+/*
* Handle debug exception notifications.
*/
int __kprobes hw_breakpoint_handler(struct die_args *args)
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/signal.c
===================================================================
--- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/signal.c
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/signal.c
@@ -11,6 +11,7 @@
#include <linux/tracehook.h>
#include <linux/signal.h>
+#include <asm/hw_breakpoint.h>
#include <asm/uaccess.h>
#include <asm/unistd.h>
@@ -149,6 +150,8 @@ static int do_signal_pending(sigset_t *o
if (current->thread.dabr)
set_dabr(current->thread.dabr);
#endif
+ /* Re-enable the breakpoints for the signal stack */
+ thread_change_pc(current, regs);
if (is32) {
if (ka.sa.sa_flags & SA_SIGINFO)
^ permalink raw reply
* [Patch 3/5] PPC64-HWBKPT: Handle concurrent alignment interrupts
From: K.Prasad @ 2010-06-09 10:25 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org, Paul Mackerras
Cc: Michael Neuling, Benjamin Herrenschmidt, shaggy,
Frederic Weisbecker, David Gibson, Alan Stern, K.Prasad,
Roland McGrath
In-Reply-To: <20100609101417.644628763@linux.vnet.ibm.com>
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.
Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
---
arch/powerpc/kernel/traps.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/traps.c
===================================================================
--- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/traps.c
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/traps.c
@@ -602,7 +602,7 @@ void RunModeException(struct pt_regs *re
void __kprobes single_step_exception(struct pt_regs *regs)
{
- regs->msr &= ~(MSR_SE | MSR_BE); /* Turn off 'trace' bits */
+ clear_single_step(regs);
if (notify_die(DIE_SSTEP, "single_step", regs, 5,
5, SIGTRAP) == NOTIFY_STOP)
@@ -621,10 +621,8 @@ void __kprobes single_step_exception(str
*/
static void emulate_single_step(struct pt_regs *regs)
{
- if (single_stepping(regs)) {
- clear_single_step(regs);
- _exception(SIGTRAP, regs, TRAP_TRACE, 0);
- }
+ if (single_stepping(regs))
+ single_step_exception(regs);
}
static inline int __parse_fpscr(unsigned long fpscr)
^ permalink raw reply
* [Patch 2/5] PPC64-HWBKPT: Implement hw-breakpoints for PowerPC BookIII S
From: K.Prasad @ 2010-06-09 10:25 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org, Paul Mackerras
Cc: Michael Neuling, Benjamin Herrenschmidt, shaggy,
Frederic Weisbecker, David Gibson, Alan Stern, K.Prasad,
Roland McGrath
In-Reply-To: <20100609101417.644628763@linux.vnet.ibm.com>
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.
Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
---
arch/powerpc/Kconfig | 1
arch/powerpc/include/asm/cputable.h | 4
arch/powerpc/include/asm/hw_breakpoint.h | 73 +++++++
arch/powerpc/include/asm/processor.h | 8
arch/powerpc/kernel/Makefile | 1
arch/powerpc/kernel/hw_breakpoint.c | 320 +++++++++++++++++++++++++++++++
arch/powerpc/kernel/machine_kexec_64.c | 3
arch/powerpc/kernel/process.c | 14 +
arch/powerpc/kernel/ptrace.c | 64 ++++++
arch/powerpc/lib/Makefile | 1
10 files changed, 489 insertions(+)
Index: linux-2.6.ppc64_test/arch/powerpc/include/asm/hw_breakpoint.h
===================================================================
--- /dev/null
+++ linux-2.6.ppc64_test/arch/powerpc/include/asm/hw_breakpoint.h
@@ -0,0 +1,73 @@
+/*
+ * PowerPC BookIII S hardware breakpoint definitions
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright 2010, IBM Corporation.
+ * Author: K.Prasad <prasad@linux.vnet.ibm.com>
+ *
+ */
+
+#ifndef _PPC_BOOK3S_64_HW_BREAKPOINT_H
+#define _PPC_BOOK3S_64_HW_BREAKPOINT_H
+
+#ifdef __KERNEL__
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+
+struct arch_hw_breakpoint {
+ u8 len; /* length of the target data symbol */
+ int type;
+ unsigned long address;
+};
+
+#include <linux/kdebug.h>
+#include <asm/reg.h>
+#include <asm/system.h>
+
+static inline int hw_breakpoint_slots(int type)
+{
+ return HBP_NUM;
+}
+struct perf_event;
+struct pmu;
+struct perf_sample_data;
+
+#define HW_BREAKPOINT_ALIGN 0x7
+/* Maximum permissible length of any HW Breakpoint */
+#define HW_BREAKPOINT_LEN 0x8
+
+extern int arch_bp_generic_fields(int type, int *gen_bp_type);
+extern int arch_check_bp_in_kernelspace(struct perf_event *bp);
+extern int arch_validate_hwbkpt_settings(struct perf_event *bp);
+extern int hw_breakpoint_exceptions_notify(struct notifier_block *unused,
+ unsigned long val, void *data);
+int arch_install_hw_breakpoint(struct perf_event *bp);
+void arch_uninstall_hw_breakpoint(struct perf_event *bp);
+void hw_breakpoint_pmu_read(struct perf_event *bp);
+extern void flush_ptrace_hw_breakpoint(struct task_struct *tsk);
+
+extern struct pmu perf_ops_bp;
+extern void ptrace_triggered(struct perf_event *bp, int nmi,
+ struct perf_sample_data *data, struct pt_regs *regs);
+static inline void hw_breakpoint_disable(void)
+{
+ set_dabr(0);
+}
+
+#else /* CONFIG_HAVE_HW_BREAKPOINT */
+static inline void hw_breakpoint_disable(void) { }
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+#endif /* __KERNEL__ */
+#endif /* _PPC_BOOK3S_64_HW_BREAKPOINT_H */
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/hw_breakpoint.c
===================================================================
--- /dev/null
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/hw_breakpoint.c
@@ -0,0 +1,320 @@
+/*
+ * HW_breakpoint: a unified kernel/user-space hardware breakpoint facility,
+ * using the CPU's debug registers. Derived from
+ * "arch/x86/kernel/hw_breakpoint.c"
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright 2010 IBM Corporation
+ * Author: K.Prasad <prasad@linux.vnet.ibm.com>
+ *
+ */
+
+#include <linux/hw_breakpoint.h>
+#include <linux/notifier.h>
+#include <linux/kprobes.h>
+#include <linux/percpu.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/sched.h>
+#include <linux/init.h>
+#include <linux/smp.h>
+
+#include <asm/hw_breakpoint.h>
+#include <asm/processor.h>
+#include <asm/sstep.h>
+
+/*
+ * Stores the breakpoints currently in use on each breakpoint address
+ * register for every cpu
+ */
+static DEFINE_PER_CPU(struct perf_event *, bp_per_reg);
+
+/*
+ * Install a perf counter breakpoint.
+ *
+ * We seek a free debug address register and use it for this
+ * breakpoint.
+ *
+ * Atomic: we hold the counter->ctx->lock and we only handle variables
+ * and registers local to this cpu.
+ */
+int arch_install_hw_breakpoint(struct perf_event *bp)
+{
+ struct arch_hw_breakpoint *info = counter_arch_bp(bp);
+ struct perf_event **slot = &__get_cpu_var(bp_per_reg);
+
+ *slot = bp;
+
+ /*
+ * Do not install DABR values if the instruction must be single-stepped.
+ * If so, DABR will be populated in single_step_dabr_instruction().
+ */
+ if (current->thread.last_hit_ubp != bp)
+ set_dabr(info->address | info->type | DABR_TRANSLATION);
+
+ return 0;
+}
+
+/*
+ * Uninstall the breakpoint contained in the given counter.
+ *
+ * First we search the debug address register it uses and then we disable
+ * it.
+ *
+ * Atomic: we hold the counter->ctx->lock and we only handle variables
+ * and registers local to this cpu.
+ */
+void arch_uninstall_hw_breakpoint(struct perf_event *bp)
+{
+ struct perf_event **slot = &__get_cpu_var(bp_per_reg);
+
+ if (*slot != bp) {
+ WARN_ONCE(1, "Can't find the breakpoint");
+ return;
+ }
+
+ *slot = NULL;
+ set_dabr(0);
+}
+
+/*
+ * Perform cleanup of arch-specific counters during unregistration
+ * of the perf-event
+ */
+void arch_unregister_hw_breakpoint(struct perf_event *bp)
+{
+ /*
+ * If the breakpoint is unregistered between a hw_breakpoint_handler()
+ * and the single_step_dabr_instruction(), then cleanup the breakpoint
+ * restoration variables to prevent dangling pointers.
+ */
+ if (bp->ctx->task)
+ bp->ctx->task->thread.last_hit_ubp = NULL;
+}
+
+/*
+ * Check for virtual address in kernel space.
+ */
+int arch_check_bp_in_kernelspace(struct perf_event *bp)
+{
+ struct arch_hw_breakpoint *info = counter_arch_bp(bp);
+
+ return is_kernel_addr(info->address);
+}
+
+int arch_bp_generic_fields(int type, int *gen_bp_type)
+{
+ switch (type) {
+ case DABR_DATA_READ:
+ *gen_bp_type = HW_BREAKPOINT_R;
+ break;
+ case DABR_DATA_WRITE:
+ *gen_bp_type = HW_BREAKPOINT_W;
+ break;
+ case (DABR_DATA_WRITE | DABR_DATA_READ):
+ *gen_bp_type = (HW_BREAKPOINT_W | HW_BREAKPOINT_R);
+ break;
+ default:
+ return -EINVAL;
+ }
+ return 0;
+}
+
+/*
+ * Validate the arch-specific HW Breakpoint register settings
+ */
+int arch_validate_hwbkpt_settings(struct perf_event *bp)
+{
+ int ret = -EINVAL;
+ struct arch_hw_breakpoint *info = counter_arch_bp(bp);
+
+ if (!bp)
+ return ret;
+
+ switch (bp->attr.bp_type) {
+ case HW_BREAKPOINT_R:
+ info->type = DABR_DATA_READ;
+ break;
+ case HW_BREAKPOINT_W:
+ info->type = DABR_DATA_WRITE;
+ break;
+ case HW_BREAKPOINT_R | HW_BREAKPOINT_W:
+ info->type = (DABR_DATA_READ | DABR_DATA_WRITE);
+ break;
+ default:
+ return ret;
+ }
+
+ info->address = bp->attr.bp_addr;
+ info->len = bp->attr.bp_len;
+
+ /*
+ * Since breakpoint length can be a maximum of HW_BREAKPOINT_LEN(8)
+ * and breakpoint addresses are aligned to nearest double-word
+ * HW_BREAKPOINT_ALIGN by rounding off to the lower address, the
+ * 'symbolsize' should satisfy the check below.
+ */
+ if (info->len >
+ (HW_BREAKPOINT_LEN - (info->address & HW_BREAKPOINT_ALIGN)))
+ return -EINVAL;
+ return 0;
+}
+
+/*
+ * Handle debug exception notifications.
+ */
+int __kprobes hw_breakpoint_handler(struct die_args *args)
+{
+ bool is_ptrace_bp = false;
+ int rc = NOTIFY_STOP;
+ struct perf_event *bp;
+ struct pt_regs *regs = args->regs;
+ int stepped = 1;
+ struct arch_hw_breakpoint *info;
+
+ /* Disable breakpoints during exception handling */
+ set_dabr(0);
+ /*
+ * The counter may be concurrently released but that can only
+ * occur from a call_rcu() path. We can then safely fetch
+ * the breakpoint, use its callback, touch its counter
+ * while we are in an rcu_read_lock() path.
+ */
+ rcu_read_lock();
+
+ bp = __get_cpu_var(bp_per_reg);
+ if (!bp)
+ goto out;
+ info = counter_arch_bp(bp);
+ is_ptrace_bp = (bp->overflow_handler == ptrace_triggered) ?
+ true : false;
+
+ /*
+ * Return early after invoking user-callback function without restoring
+ * DABR if the breakpoint is from ptrace which always operates in
+ * one-shot mode. The ptrace-ed process will receive the SIGTRAP signal
+ * generated in do_dabr().
+ */
+ if (is_ptrace_bp) {
+ perf_bp_event(bp, regs);
+ rc = NOTIFY_DONE;
+ goto out;
+ }
+
+ /* Do not emulate user-space instructions, instead single-step them */
+ if (user_mode(regs)) {
+ bp->ctx->task->thread.last_hit_ubp = bp;
+ regs->msr |= MSR_SE;
+ goto out;
+ }
+
+ stepped = emulate_step(regs, regs->nip);
+ /*
+ * emulate_step() could not execute it. We've failed in reliably
+ * handling the hw-breakpoint. Unregister it and throw a warning
+ * message to let the user know about it.
+ */
+ if (!stepped) {
+ WARN(1, "Unable to handle hardware breakpoint. Breakpoint at "
+ "0x%lx will be uninstalled.", info->address);
+ unregister_hw_breakpoint(bp);
+ goto out;
+ }
+ /*
+ * As a policy, the callback is invoked in a 'trigger-after-execute'
+ * fashion
+ */
+ perf_bp_event(bp, regs);
+
+ set_dabr(info->address | info->type | DABR_TRANSLATION);
+out:
+ rcu_read_unlock();
+ return rc;
+}
+
+/*
+ * Handle single-step exceptions following a DABR hit.
+ */
+int __kprobes single_step_dabr_instruction(struct die_args *args)
+{
+ struct pt_regs *regs = args->regs;
+ struct perf_event *bp = NULL;
+ struct arch_hw_breakpoint *bp_info;
+
+ bp = current->thread.last_hit_ubp;
+ /*
+ * Check if we are single-stepping as a result of a
+ * previous HW Breakpoint exception
+ */
+ if (!bp)
+ return NOTIFY_DONE;
+
+ bp_info = counter_arch_bp(bp);
+
+ /*
+ * We shall invoke the user-defined callback function in the single
+ * stepping handler to confirm to 'trigger-after-execute' semantics
+ */
+ perf_bp_event(bp, regs);
+
+ /*
+ * Do not disable MSR_SE if the process was already in
+ * single-stepping mode.
+ */
+ if (!test_thread_flag(TIF_SINGLESTEP))
+ regs->msr &= ~MSR_SE;
+
+ set_dabr(bp_info->address | bp_info->type | DABR_TRANSLATION);
+ current->thread.last_hit_ubp = NULL;
+ return NOTIFY_STOP;
+}
+
+/*
+ * Handle debug exception notifications.
+ */
+int __kprobes hw_breakpoint_exceptions_notify(
+ struct notifier_block *unused, unsigned long val, void *data)
+{
+ int ret = NOTIFY_DONE;
+
+ switch (val) {
+ case DIE_DABR_MATCH:
+ ret = hw_breakpoint_handler(data);
+ break;
+ case DIE_SSTEP:
+ ret = single_step_dabr_instruction(data);
+ break;
+ }
+
+ return ret;
+}
+
+/*
+ * Release the user breakpoints used by ptrace
+ */
+void flush_ptrace_hw_breakpoint(struct task_struct *tsk)
+{
+ struct thread_struct *t = &tsk->thread;
+
+ unregister_hw_breakpoint(t->ptrace_bps[0]);
+ t->ptrace_bps[0] = NULL;
+}
+
+void hw_breakpoint_pmu_read(struct perf_event *bp)
+{
+ /* TODO */
+}
+
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/Makefile
===================================================================
--- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/Makefile
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/Makefile
@@ -34,6 +34,7 @@ obj-y += vdso32/
obj-$(CONFIG_PPC64) += setup_64.o sys_ppc32.o \
signal_64.o ptrace32.o \
paca.o nvram_64.o firmware.o
+obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o
obj-$(CONFIG_PPC_BOOK3S_64) += cpu_setup_ppc970.o cpu_setup_pa6t.o
obj64-$(CONFIG_RELOCATABLE) += reloc_64.o
obj-$(CONFIG_PPC_BOOK3E_64) += exceptions-64e.o
Index: linux-2.6.ppc64_test/arch/powerpc/include/asm/processor.h
===================================================================
--- linux-2.6.ppc64_test.orig/arch/powerpc/include/asm/processor.h
+++ linux-2.6.ppc64_test/arch/powerpc/include/asm/processor.h
@@ -209,6 +209,14 @@ struct thread_struct {
#ifdef CONFIG_PPC64
unsigned long start_tb; /* Start purr when proc switched in */
unsigned long accum_tb; /* Total accumilated purr for process */
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ struct perf_event *ptrace_bps[HBP_NUM];
+ /*
+ * Helps identify source of single-step exception and subsequent
+ * hw-breakpoint enablement
+ */
+ struct perf_event *last_hit_ubp;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
#endif
unsigned long dabr; /* Data address breakpoint register */
#ifdef CONFIG_ALTIVEC
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/ptrace.c
===================================================================
--- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/ptrace.c
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/ptrace.c
@@ -32,6 +32,8 @@
#ifdef CONFIG_PPC32
#include <linux/module.h>
#endif
+#include <linux/hw_breakpoint.h>
+#include <linux/perf_event.h>
#include <asm/uaccess.h>
#include <asm/page.h>
@@ -866,9 +868,34 @@ void user_disable_single_step(struct tas
clear_tsk_thread_flag(task, TIF_SINGLESTEP);
}
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+void ptrace_triggered(struct perf_event *bp, int nmi,
+ struct perf_sample_data *data, struct pt_regs *regs)
+{
+ struct perf_event_attr attr;
+
+ /*
+ * Disable the breakpoint request here since ptrace has defined a
+ * one-shot behaviour for breakpoint exceptions in PPC64.
+ * The SIGTRAP signal is generated automatically for us in do_dabr().
+ * We don't have to do anything about that here
+ */
+ attr = bp->attr;
+ attr.disabled = true;
+ modify_user_hw_breakpoint(bp, &attr);
+}
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+
int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
unsigned long data)
{
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ int ret;
+ struct thread_struct *thread = &(task->thread);
+ struct perf_event *bp;
+ struct perf_event_attr attr;
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+
/* For ppc64 we support one DABR and no IABR's at the moment (ppc64).
* For embedded processors we support one DAC and no IAC's at the
* moment.
@@ -896,6 +923,43 @@ int ptrace_set_debugreg(struct task_stru
/* Ensure breakpoint translation bit is set */
if (data && !(data & DABR_TRANSLATION))
return -EIO;
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ bp = thread->ptrace_bps[0];
+ if ((!data) || !(data & (DABR_DATA_WRITE | DABR_DATA_READ))) {
+ if (bp) {
+ unregister_hw_breakpoint(bp);
+ thread->ptrace_bps[0] = NULL;
+ }
+ return 0;
+ }
+ if (bp) {
+ attr = bp->attr;
+ attr.bp_addr = data & ~HW_BREAKPOINT_ALIGN;
+ arch_bp_generic_fields(data &
+ (DABR_DATA_WRITE | DABR_DATA_READ),
+ &attr.bp_type);
+ ret = modify_user_hw_breakpoint(bp, &attr);
+ if (ret)
+ return ret;
+ thread->ptrace_bps[0] = bp;
+ thread->dabr = data;
+ return 0;
+ }
+
+ /* Create a new breakpoint request if one doesn't exist already */
+ hw_breakpoint_init(&attr);
+ attr.bp_addr = data & ~HW_BREAKPOINT_ALIGN;
+ arch_bp_generic_fields(data & (DABR_DATA_WRITE | DABR_DATA_READ),
+ &attr.bp_type);
+
+ thread->ptrace_bps[0] = bp = register_user_hw_breakpoint(&attr,
+ ptrace_triggered, task);
+ if (IS_ERR(bp)) {
+ thread->ptrace_bps[0] = NULL;
+ return PTR_ERR(bp);
+ }
+
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
/* Move contents to the DABR register */
task->thread.dabr = data;
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/process.c
===================================================================
--- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/process.c
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/process.c
@@ -37,6 +37,7 @@
#include <linux/kernel_stat.h>
#include <linux/personality.h>
#include <linux/random.h>
+#include <linux/hw_breakpoint.h>
#include <asm/pgtable.h>
#include <asm/uaccess.h>
@@ -462,8 +463,14 @@ struct task_struct *__switch_to(struct t
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
switch_booke_debug_regs(&new->thread);
#else
+/*
+ * For PPC_BOOK3S_64, we use the hw-breakpoint interfaces that would
+ * schedule DABR
+ */
+#ifndef CONFIG_HAVE_HW_BREAKPOINT
if (unlikely(__get_cpu_var(current_dabr) != new->thread.dabr))
set_dabr(new->thread.dabr);
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
#endif
@@ -642,7 +649,11 @@ void flush_thread(void)
{
discard_lazy_cpu_state();
+#ifdef CONFIG_HAVE_HW_BREAKPOINTS
+ flush_ptrace_hw_breakpoint(current);
+#else /* CONFIG_HAVE_HW_BREAKPOINTS */
set_debug_reg_defaults(¤t->thread);
+#endif /* CONFIG_HAVE_HW_BREAKPOINTS */
}
void
@@ -660,6 +671,9 @@ void prepare_to_copy(struct task_struct
flush_altivec_to_thread(current);
flush_vsx_to_thread(current);
flush_spe_to_thread(current);
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+ flush_ptrace_hw_breakpoint(tsk);
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
}
/*
Index: linux-2.6.ppc64_test/arch/powerpc/include/asm/cputable.h
===================================================================
--- linux-2.6.ppc64_test.orig/arch/powerpc/include/asm/cputable.h
+++ linux-2.6.ppc64_test/arch/powerpc/include/asm/cputable.h
@@ -516,6 +516,10 @@ static inline int cpu_has_feature(unsign
& feature);
}
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+#define HBP_NUM 1
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+
#endif /* !__ASSEMBLY__ */
#endif /* __KERNEL__ */
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/machine_kexec_64.c
===================================================================
--- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/machine_kexec_64.c
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/machine_kexec_64.c
@@ -25,6 +25,7 @@
#include <asm/sections.h> /* _end */
#include <asm/prom.h>
#include <asm/smp.h>
+#include <asm/hw_breakpoint.h>
int default_machine_kexec_prepare(struct kimage *image)
{
@@ -165,6 +166,7 @@ static void kexec_smp_down(void *arg)
while(kexec_all_irq_disabled == 0)
cpu_relax();
mb(); /* make sure all irqs are disabled before this */
+ hw_breakpoint_disable();
/*
* Now every CPU has IRQs off, we can clear out any pending
* IPIs and be sure that no more will come in after this.
@@ -180,6 +182,7 @@ static void kexec_prepare_cpus_wait(int
{
int my_cpu, i, notified=-1;
+ hw_breakpoint_disable();
my_cpu = get_cpu();
/* Make sure each CPU has atleast made it to the state we need */
for (i=0; i < NR_CPUS; i++) {
Index: linux-2.6.ppc64_test/arch/powerpc/lib/Makefile
===================================================================
--- linux-2.6.ppc64_test.orig/arch/powerpc/lib/Makefile
+++ linux-2.6.ppc64_test/arch/powerpc/lib/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_PPC64) += copypage_64.o cop
memcpy_64.o usercopy_64.o mem_64.o string.o
obj-$(CONFIG_XMON) += sstep.o
obj-$(CONFIG_KPROBES) += sstep.o
+obj-$(CONFIG_HAVE_HW_BREAKPOINT) += sstep.o
ifeq ($(CONFIG_PPC64),y)
obj-$(CONFIG_SMP) += locks.o
Index: linux-2.6.ppc64_test/arch/powerpc/Kconfig
===================================================================
--- linux-2.6.ppc64_test.orig/arch/powerpc/Kconfig
+++ linux-2.6.ppc64_test/arch/powerpc/Kconfig
@@ -141,6 +141,7 @@ config PPC
select GENERIC_ATOMIC64 if PPC32
select HAVE_PERF_EVENTS
select HAVE_REGS_AND_STACK_ACCESS_API
+ select HAVE_HW_BREAKPOINT if PERF_EVENTS && PPC_BOOK3S_64
config EARLY_PRINTK
bool
^ permalink raw reply
* [Patch 1/5] Allow arch-specific cleanup before breakpoint unregistration
From: K.Prasad @ 2010-06-09 10:25 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org, Paul Mackerras
Cc: Michael Neuling, Benjamin Herrenschmidt, shaggy,
Frederic Weisbecker, David Gibson, Alan Stern, K.Prasad,
Roland McGrath
In-Reply-To: <20100609101417.644628763@linux.vnet.ibm.com>
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 <prasad@linux.vnet.ibm.com>
Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
---
kernel/hw_breakpoint.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
Index: linux-2.6.ppc64_test/kernel/hw_breakpoint.c
===================================================================
--- linux-2.6.ppc64_test.orig/kernel/hw_breakpoint.c
+++ linux-2.6.ppc64_test/kernel/hw_breakpoint.c
@@ -242,6 +242,17 @@ toggle_bp_slot(struct perf_event *bp, bo
}
/*
+ * Function to perform processor-specific cleanup during unregistration
+ */
+__weak void arch_unregister_hw_breakpoint(struct perf_event *bp)
+{
+ /*
+ * A weak stub function here for those archs that don't define
+ * it inside arch/.../kernel/hw_breakpoint.c
+ */
+}
+
+/*
* Contraints to check before allowing this new breakpoint counter:
*
* == Non-pinned counter == (Considered as pinned for now)
@@ -339,6 +350,7 @@ void release_bp_slot(struct perf_event *
{
mutex_lock(&nr_bp_mutex);
+ arch_unregister_hw_breakpoint(bp);
__release_bp_slot(bp);
mutex_unlock(&nr_bp_mutex);
^ permalink raw reply
* [Patch 0/5] PPC64-HWBKPT: Hardware Breakpoint interfaces - ver XXIII
From: K.Prasad @ 2010-06-09 10:24 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org, Paul Mackerras
Cc: Michael Neuling, Benjamin Herrenschmidt, shaggy,
Frederic Weisbecker, David Gibson, Alan Stern, Roland McGrath
Hi All,
Please find a new version of the patchset that implement hardware
breakpoint interfaces for the PowerPC BookIII S processor. The changes are
few and as described below.
Changelog - ver XXIII
--------------------
(Version XXII: 20100528063924.GA8679@in.ibm.com)
- Detection of extraneous breakpoint exceptions is now done using a boolean flag
in 'struct arch_hw_breakpoint'.
- A dangling put_cpu() (remnant from previous patch versions) in
arch_unregister_hw_breakpoint() is now removed.
Kindly let me know your comments.
Thanks,
K.Prasad
Changelog - ver XXII
--------------------
(Version XXI: linuxppc-dev ref:20100525091314.GA29003@in.ibm.com)
- Extraneous breakpoint exceptions are now properly handled; causative
instruction will be single-stepped and debug register values restored.
- Restoration of breakpoints during signal handling through thread_change_pc()
had defects which are now fixed.
- Breakpoints are flushed through flush_ptrace_hw_breakpoint() call in both
flush_thread() and prepare_to_copy() functions. 'ptrace_bps[]' and
'last_hit_ubp' members are now promptly cleaned-up.
- Single-step exception is now conditionally emulated upon hitting
alignment_exception.
- Rebased to commit 31f46717997a83bdf6db0dd04810c0a329eb3148 of linux-2.6 tree.
Changelog - ver XXI
--------------------
(Version XX: linuxppc-dev ref:20100524103136.GA8131@in.ibm.com)
- Decision to emulate an instruction is now based on whether the causative
instruction is in user_mode() or not.
- Breakpoints don't have to be cleared during sigreturn. A 'double-hit' on
hw_breakpoint_handler() is harmless for non-ptrace instructions.
- Minor changes to aid code brevity.
Changelog - ver XX
--------------------
(Version XIX: linuxppc-dev ref: 20100524040137.GA20873@in.ibm.com)
- Non task-bound breakpoints will only be emulated. Breakpoint will be
unregistered with a warning if emulation fails.
Changelog - ver XIX
--------------------
(Version XVIII: linuxppc-dev ref: 20100512033055.GA6384@in.ibm.com)
- Increased coverage of breakpoints during concurrent alignment_exception
and signal handling (which previously had 'blind-spots').
- Support for kernel-thread breakpoints and kernel-space breakpoints inside the
context of a user-space process.
- Patches re-based to commit f4b87dee923342505e1ddba8d34ce9de33e75050, thereby
necessitating minor changes to arch_validate_hwbkpt_settings().
Changelog - ver XVIII
--------------------
(Version XVII: linuxppc-dev ref: 20100414034340.GA6571@in.ibm.com)
- Slight code restructuring for brevity and coding-style corrections.
- emulate_single_step() now notifies DIE_SSTEP to registered handlers;
causes single_step_dabr_instruction() to be invoked after alignment_exception.
- hw-breakpoint restoration variables are cleaned-up before unregistration
through arch_unregister_hw_breakpoint().
- SIGTRAP is no longer generated for non-ptrace user-space breakpoints.
Changelog - ver XVII
--------------------
(Version XVI: linuxppc-dev ref: 20100330095809.GA14403@in.ibm.com)
- CONFIG_HAVE_HW_BREAKPOINT is now used to define the scope of the new code
(in lieu of CONFIG_PPC_BOOK3S_64).
- CONFIG_HAVE_HW_BREAKPOINT is now dependant upon CONFIG_PERF_EVENTS and
CONFIG_PPC_BOOK3S_64 (to overcome build failures under certain configs).
- Included a target in arch/powerpc/lib/Makefile to build sstep.o when
HAVE_HW_BREAKPOINT.
- Added a dummy definition for hw_breakpoint_disable() when !HAVE_HW_BREAKPOINT.
- Tested builds under defconfigs for ppc64, cell and g5 (found no patch induced
failures).
Changelog - ver XVI
--------------------
(Version XV: linuxppc-dev ref: 20100323140639.GA21836@in.ibm.com)
- Used a new config option CONFIG_PPC_BOOK3S_64 (in lieu of
CONFIG_PPC64/CPU_FTR_HAS_DABR) to limit the scope of the new code.
- Disabled breakpoints before kexec of the machine using hw_breakpoint_disable().
- Minor optimisation in exception-64s.S to check for data breakpoint exceptions
in DSISR finally (after check for other causes) + changes in code comments and
representation of DSISR_DABRMATCH constant.
- Rebased to commit ae6be51ed01d6c4aaf249a207b4434bc7785853b of linux-2.6.
Changelog - ver XV
--------------------
(Version XIV: linuxppc-dev ref: 20100308181232.GA3406@in.ibm.com)
- Additional patch to disable interrupts during data breakpoint exception
handling.
- Moved HBP_NUM definition to cputable.h under a new CPU_FTR definition
(CPU_FTR_HAS_DABR).
- Filtering of extraneous exceptions (due to accesses outside symbol length) is
by-passed for ptrace requests.
- Removed flush_ptrace_hw_breakpoint() from __switch_to() due to incorrect
coding placement.
- Changes to code comments as per community reviews for previous version.
- Minor coding-style changes in hw_breakpoint.c as per review comments.
- Re-based to commit ae6be51ed01d6c4aaf249a207b4434bc7785853b of linux-2.6
Changelog - ver XIV
--------------------
(Version XIII: linuxppc-dev ref: 20100215055605.GB3670@in.ibm.com)
- Removed the 'name' field from 'struct arch_hw_breakpoint'.
- All callback invocations through bp->overflow_handler() are replaced with
perf_bp_event().
- Removed the check for pre-existing single-stepping mode in
hw_breakpoint_handler() as this check is unreliable while in kernel-space.
Side effect of this change is the non-triggering of hw-breakpoints while
single-stepping kernel through KGDB or Xmon.
- Minor code-cleanups and addition of comments in hw_breakpoint_handler() and
single_step_dabr_instruction().
- Re-based to commit 25cf84cf377c0aae5dbcf937ea89bc7893db5176 of linux-2.6
Changelog - ver XIII
--------------------
(Version XII: linuxppc-dev ref: 20100121084640.GA3252@in.ibm.com)
- Fixed a bug for user-space breakpoints (triggered following the failure of a
breakpoint request).
- Re-based on commit 724e6d3fe8003c3f60bf404bf22e4e331327c596 of linux-2.6
Changelog - ver XII
--------------------
(Version XI: linuxppc-dev ref: 20100119091234.GA9971@in.ibm.com)
- Unset MSR_SE only if kernel was not previously in single-step mode.
- Pre-emption is now enabled before returning from the hw-breakpoint exception
handler.
- Variables to track the source of single-step exception (breakpoint from kernel,
user-space vs single-stepping due to other requests) are added.
- Extraneous hw-breakpoint exceptions (due to memory accesses lying outside
monitored symbol length) is now done for both kernel and user-space
(previously only user-space).
- single_step_dabr_instruction() now returns NOTIFY_DONE if kernel was in
single-step mode even before the hw-breakpoint. This enables other users of
single-step mode to be notified of the exception.
- User-space instructions are not emulated from kernel-space, they are instead
single-stepped.
Changelog - ver XI
------------------
(Version X: linuxppc-dev ref: 20091211160144.GA23156@in.ibm.com)
- Conditionally unset MSR_SE in the single-step handler
- Added comments to explain the duration and need for pre-emption
disable following hw-breakpoint exception.
Changelog - ver X
------------------
- Re-write the PPC64 patches for the new implementation of hw-breakpoints that
uses the perf-layer.
- Rebased to commit 7622fc234190a37d4e9fe3ed944a2b61a63fca03 of -tip.
Changelog - ver IX
-------------------
- Invocation of user-defined callback will be 'trigger-after-execute' (except
for ptrace).
- Creation of a new global per-CPU breakpoint structure to help invocation of
user-defined callback from single-step handler.
(Changes made now)
- Validation before registration will fail only if the address does not match
the kernel symbol's (if specified) resolved address
(through kallsyms_lookup_name()).
- 'symbolsize' value is expected to within the range contained by the symbol's
starting address and the end of a double-word boundary (8 Bytes).
- PPC64's arch-dependant code is now aware of 'cpumask' in 'struct hw_breakpoint'
and can accomodate requests for a subset of CPUs in the system.
- Introduced arch_disable_hw_breakpoint() required for
<enable><disable>_hw_breakpoint() APIs.
Changelog - ver VIII
-------------------
- Reverting changes to allow one-shot breakpoints only for ptrace requests.
- Minor changes in sanity checking in arch_validate_hwbkpt_settings().
- put_cpu_no_resched() is no longer available. Converted to put_cpu().
Changelog - ver VII
-------------------
- Allow the one-shot behaviour for exception handlers to be defined by the user.
A new 'is_one_shot' flag is added to 'struct arch_hw_breakpoint'.
Changelog - ver VI
------------------
The task of identifying 'genuine' breakpoint exceptions from those caused by
'out-of-range' accesses turned out to be more tricky than originally thought.
Some changes to this effect were made in version IV of this patchset, but they
were not sufficient for user-space. Basically the breakpoint address received
through ptrace is always aligned to 8-bytes since ptrace receives an encoded
'data' (consisting of address | translation_enable | bkpt_type), and the size of
the symbol is not known. However for kernel-space addresses, the symbol-size can
be determined using kallsyms_lookup_size_offset() and this is used to check if
DAR (in the exception context) is
'bkpt_address <= DAR <= (bkpt_address + symbol_size)', failing which we conclude
it as a stray exception.
The following changes are made to enable check:
- Addition of a symbolsize field in 'struct arch_hw_breakpoint' field.
- Store the size of the 'watched' kernel symbol into 'symbolsize' field in
arch_store_info(0 routine.
- Verify if the above described condition is true when is_one_shot is FALSE in
hw_breakpoint_handler().
Changelog - ver V
------------------
- Breakpoint requests from ptrace (for user-space) are designed to be one-shot
in PPC64. The patch contains changes to retain this behaviour by returning early
in hw_breakpoint_handler() [without re-initialising DABR] and unregistering the
user-space request in ptrace_triggered(). It is safe to make a
unregister_user_hw_breakpoint() call from the breakpoint exception context
[through ptrace_triggered()] without giving rise to circular locking-dependancy.
This is because there can be no kernel code running on the CPU (which received
the exception) with the same spinlock held.
- Minor change in 'type' member of 'struct arch_hw_breakpoint' from u8 to 'int'.
Changelog - ver IV
------------------
- While DABR register requires double-word (8 bytes) aligned addresses, i.e.
the breakpoint is active over a range of 8 bytes, PPC64 allows byte-level
addressability. This may lead to stray exceptions which have to be ignored in
hw_breakpoint_handler(), when DAR != (Breakpoint request address). However DABR
will be populated with the requested breakpoint address aligned to the previous
double-word address. The code is now modified to store user-requested address
in 'bp->info.address' but update the DABR with a double-word aligned address.
- Please note that the Data Breakpoint facility in Xmon is broken as of 2.6.29
and the same has not been integrated into this facility as described in Ver I.
Changelog - ver III
------------------
- Patches are based on commit 08f16e060bf54bdc34f800ed8b5362cdeda75d8b of -tip
tree.
- The declarations in arch/powerpc/include/asm/hw_breakpoint.h are done only if
CONFIG_PPC64 is defined. This eliminates the need to conditionally include this
header file.
- load_debug_registers() is done in start_secondary() i.e. during CPU
initialisation.
- arch_check_va_<> routines in hw_breakpoint.c are now replaced with a much
simpler is_kernel_addr() check in arch_validate_hwbkpt_settings()
- Return code of hw_breakpoint_handler() when triggered due to Lazy debug
register switching is now changed to NOTIFY_STOP.
- The ptrace code no longer sets the TIF_DEBUG task flag as it is proposed to
be done in register_user_hw_breakpoint() routine.
- hw_breakpoint_handler() is now modified to use hbp_kernel_pos value to
determine if the trigger was a user/kernel space address. The DAR register
value is checked with the address stored in 'struct hw_breakpoint' to avoid
handling of exceptions that belong to kprobe/Xmon.
Changelog - ver II
------------------
- Split the monolithic patch into six logical patches
- Changed the signature of arch_check_va_in_<user><kernel>space functions. They
are now marked static.
- HB_NUM is now called as HBP_NUM (to preserve a consistent short-name
convention)
- Introduced hw_breakpoint_disable() and changes to kexec code to disable
breakpoints before a reboot.
- Minor changes in ptrace code to use macro-defined constants instead of
numbers.
- Introduced a new constant definition INSTRUCTION_LEN in reg.h
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox