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 co
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
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
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
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 d
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 single
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 to
- emulate_step() all non-task bound breakpoints and single-step only the
pe
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
Acked-by: Frederic
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:
20100615015459.ga30...@drongo
On Sat, 2010-06-12 at 21:36 -0400, Alastair Bridgewater wrote:
> mpic_resume() on G5 macs blindly dereferences mpic->fixups, but
> it may legitimately be NULL (as on PowerMac7,2). Add an explicit
> check.
>
> This fixes susend-to-disk with one processor (maxcpus=1) for me.
Thanks. Patch is terri
On Mon, Jun 14, 2010 at 10:59:20AM -0400, Nicolas Pitre wrote:
> On Mon, 14 Jun 2010, David Gibson wrote:
>
> > On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote:
> > [sni]
> > > > That's sort of a self-fulfilling prophecy. If the OS doesn't trust the
> > > > firmware, there is no pres
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 continue to fail
> due to emulate_step() failure, in my case, on a "lwz r
On Mon, Jun 14, 2010 at 3:55 PM, Eric Millbrandt
wrote:
> 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 tes
On Mon, Jun 14, 2010 at 3:55 PM, Eric Millbrandt
wrote:
> 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
On Mon, Jun 14, 2010 at 3:55 PM, Eric Millbrandt
wrote:
> 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.
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 t
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 gen
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 ha
On Mon, Jun 14, 2010 at 03:40:19PM -0400, Nicolas Pitre wrote:
> On Mon, 14 Jun 2010, Mitch Bradley wrote:
> > Arranging for a JTAG dongle to appear at the customer site, then
> > getting it set up and the necessary software installed and configured
> > on a suitable host system, typically requi
On Sun, Jun 13, 2010 at 11:36:57PM -0600, Grant Likely wrote:
> On Sun, Jun 13, 2010 at 2:29 AM, Benjamin Herrenschmidt
> wrote:
> > On Sat, 2010-06-12 at 20:45 -1000, Mitch Bradley wrote:
> >
> >> Either fought or embraced. To the extent that it is possible to focus
> >> solely on Linux and ARM,
On Mon, 14 Jun 2010, Mitch Bradley wrote:
> Nicolas Pitre wrote:
> > On Mon, 14 Jun 2010, Mitch Bradley wrote:
> >
> >
> > > First, the primary use case for "keeping OFW alive" is for debugging
> > > purposes.
> > > OFW remains resident in memory so that, if the OS is set to allow it (not
> >
Nicolas Pitre wrote:
On Mon, 14 Jun 2010, Mitch Bradley wrote:
First, the primary use case for "keeping OFW alive" is for debugging purposes.
OFW remains resident in memory so that, if the OS is set to allow it (not the
default), a hot-key freezes the OS and enters OFW, where a human can ins
On Mon, 14 Jun 2010, Mitch Bradley wrote:
> First, the primary use case for "keeping OFW alive" is for debugging purposes.
> OFW remains resident in memory so that, if the OS is set to allow it (not the
> default), a hot-key freezes the OS and enters OFW, where a human can inspect
> the state of d
I shall try to clarify this discussion.
There are actually two different things being discussed. The first is,
I hope, not too controversial. The second is so controversial as to be
a hopeless cause.
First, the primary use case for "keeping OFW alive" is for debugging
purposes. OFW remain
Grant Likely wrote:
> > Like initrd, some people will find they need to compile it in to the
> > kernel image to fit some bootloader they can't change, or daren't risk
> > changing in already rolled out devices that they want to update to a
> > DT-using kernel.
>
> Yes, I fully expect that. Fortu
On Mon, Jun 14, 2010 at 10:23 AM, Nicolas Pitre wrote:
> On Mon, 14 Jun 2010, Jamie Lokier wrote:
>> So requiring that a bootloader can update the DT _independently_ of
>> everything else is a bit much for some devices.
>
> In my opinion, this use case you're illustrating above simply could
> cont
On Mon, Jun 14, 2010 at 10:02 AM, Jamie Lokier wrote:
> Nicolas Pitre wrote:
>> On Mon, 14 Jun 2010, David Gibson wrote:
>>
>> > On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote:
>> > [sni]
>> > > > That's sort of a self-fulfilling prophecy. If the OS doesn't trust the
>> > > > firmwa
On Mon, 14 Jun 2010, Jamie Lokier wrote:
> Nicolas Pitre wrote:
> > On Mon, 14 Jun 2010, David Gibson wrote:
> >
> > > On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote:
> > > [sni]
> > > > > That's sort of a self-fulfilling prophecy. If the OS doesn't trust
> > > > > the
> > > > > f
On Mon, 14 Jun 2010, Grant Likely wrote:
> The discussion *started* with a request to review this document:
>
> http://devicetree.org/Device_Tree_Usage
>
> Which is in early draft form (which is why the arm list wasn't
> initially cc'd. I was soliciting feedback from the current device tree
> us
On Mon, 14 Jun 2010, David Gibson wrote:
> On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote:
> [sni]
> > > That's sort of a self-fulfilling prophecy. If the OS doesn't trust the
> > > firmware, there is no pressure for the firmware to "get it right".
> >
> > Firmware will not get it
On Sun, 13 Jun 2010, Grant Likely wrote:
> [cc'ing linux-arm-kernel]
>
> On Sat, Jun 12, 2010 at 11:59 PM, Benjamin Herrenschmidt
> > BTW. I notice no ARM list is CCed on this discussion ... maybe we should
> > fix that ?
>
> cc'ing linux-arm-kernel in all my replies
I'm afraid this won't be en
On Mon, Jun 14, 2010 at 9:58 AM, Nicolas Pitre wrote:
> On Mon, 14 Jun 2010, Grant Likely wrote:
>
>> The discussion *started* with a request to review this document:
>>
>> http://devicetree.org/Device_Tree_Usage
>>
>> Which is in early draft form (which is why the arm list wasn't
>> initially cc'
In message: <20100614124438.gf9...@yookeroo>
David Gibson writes:
: On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote:
: [sni]
: > > That's sort of a self-fulfilling prophecy. If the OS doesn't trust the
: > > firmware, there is no pressure for the firmware to "get it right
Nicolas Pitre wrote:
> On Mon, 14 Jun 2010, David Gibson wrote:
>
> > On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote:
> > [sni]
> > > > That's sort of a self-fulfilling prophecy. If the OS doesn't trust the
> > > > firmware, there is no pressure for the firmware to "get it right".
>
On Mon, Jun 14, 2010 at 7:51 AM, Nicolas Pitre wrote:
> On Sun, 13 Jun 2010, Grant Likely wrote:
>
>> [cc'ing linux-arm-kernel]
>>
>> On Sat, Jun 12, 2010 at 11:59 PM, Benjamin Herrenschmidt
>> > BTW. I notice no ARM list is CCed on this discussion ... maybe we should
>> > fix that ?
>>
>> cc'ing
On Mon, Jun 14, 2010 at 8:59 AM, Nicolas Pitre wrote:
> On Mon, 14 Jun 2010, David Gibson wrote:
>
>> On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote:
>> Indeed. In fact, the general rule of thumb is really "put as much as
>> possible into the most easily replaced layer of the stack"
Russell King - ARM Linux wrote:
> On Mon, Jun 14, 2010 at 07:36:10PM +1000, Benjamin Herrenschmidt wrote:
> > However, there's a lot of room for abuse here and I'm worried that if it
> > becomes widespread, we'll start seeing vendors use that as a way to do
> > some kind of HAL and hide various pla
On Sun, Jun 13, 2010 at 11:02:15PM -0600, Grant Likely wrote:
[sni]
> > That's sort of a self-fulfilling prophecy. If the OS doesn't trust the
> > firmware, there is no pressure for the firmware to "get it right".
>
> Firmware will not get it right. Period. There will always be
> something wron
On Mon, Jun 14, 2010 at 07:36:10PM +1000, Benjamin Herrenschmidt wrote:
> However, there's a lot of room for abuse here and I'm worried that if it
> becomes widespread, we'll start seeing vendors use that as a way to do
> some kind of HAL and hide various platform methods in there (clock
> control,
On Mon, 2010-06-14 at 10:25 +0100, Russell King - ARM Linux wrote:
> On Sun, Jun 13, 2010 at 09:45:50PM -1000, Mitch Bradley wrote:
> > None of this is a deal-breaker for the kind of debugging tasks that are
> > the primary use case for the callback.
>
> Would you mind explaining what kind of ta
On Sun, Jun 13, 2010 at 09:45:50PM -1000, Mitch Bradley wrote:
> None of this is a deal-breaker for the kind of debugging tasks that are
> the primary use case for the callback.
Would you mind explaining what kind of tasks these callbacks will
be used for?
___
If any changes w.r.t board then John Linn (XILINX) should be able to provide
some pointers.
2010/6/11 kostas padarnitsas
> Hi Srikant,
>
> Thanks for your help. I checked the driver versions and they seem ok. The
> problem is that when I download the linux image the program counter is not
> se
On Sun, Jun 13, 2010 at 11:23:45PM -0600, Grant Likely wrote:
> >> Or perhaps the MMU and caches can be turned off for the duration of the
> >> callback.
> >> I don't have the details of ARM MMUs and caches reloaded into my head
> >> yet. Maybe next week...
We've had these kinds of questions in t
Russell King - ARM Linux wrote:
On Sun, Jun 13, 2010 at 11:23:45PM -0600, Grant Likely wrote:
Or perhaps the MMU and caches can be turned off for the duration of the
callback.
I don't have the details of ARM MMUs and caches reloaded into my head
yet. Maybe next week...
We've had t
44 matches
Mail list logo
