On Jul 23, 2008, at 11:10 AM, Luis Machado wrote:
On Wed, 2008-07-23 at 11:53 -0400, Josh Boyer wrote:
Shouldn't this (and other places) be:
#if defined(CONFIG_44x) || defined(CONFIG_BOOKE)
if you are going to exclude 40x for now? Otherwise this is still
enabled on 405 and setting the
On Jul 24, 2008, at 11:00 PM, Benjamin Herrenschmidt wrote:
On Wed, 2008-07-23 at 13:10 -0300, Luis Machado wrote:
On Wed, 2008-07-23 at 11:53 -0400, Josh Boyer wrote:
Shouldn't this (and other places) be:
#if defined(CONFIG_44x) || defined(CONFIG_BOOKE)
if you are going to exclude 40x for
On Jul 25, 2008, at 10:23 AM, Kumar Gala wrote:
On Jul 24, 2008, at 11:00 PM, Benjamin Herrenschmidt wrote:
On Wed, 2008-07-23 at 13:10 -0300, Luis Machado wrote:
On Wed, 2008-07-23 at 11:53 -0400, Josh Boyer wrote:
Shouldn't this (and other places) be:
#if defined(CONFIG_44x) ||
Josh pointed out that you went ahead and merged this. Curse you :)
I've got a patch in my tree to address my initial concerns.
Well, I asked Josh on IRC and he was fine, I got your email too late.
Cheers,
Ben.
___
Linuxppc-dev mailing list
On Fri, 2008-07-25 at 10:23 -0500, Kumar Gala wrote:
Ben, I want to make sure this works on FSL Book-E before it gets into
tree and I need to think about what SMP issues it might have.
Hrm.. too late. I merged it.
I talked to Josh about this at OLS and if you are ok I can deal with
On Sat, 26 Jul 2008 07:38:57 +1000
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
Josh pointed out that you went ahead and merged this. Curse you :)
I've got a patch in my tree to address my initial concerns.
Well, I asked Josh on IRC and he was fine, I got your email too late.
I
On Fri, 2008-07-25 at 19:08 -0400, Josh Boyer wrote:
On Sat, 26 Jul 2008 07:38:57 +1000
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
Josh pointed out that you went ahead and merged this. Curse you :)
I've got a patch in my tree to address my initial concerns.
Well, I
On Wed, 2008-07-23 at 13:10 -0300, Luis Machado wrote:
On Wed, 2008-07-23 at 11:53 -0400, Josh Boyer wrote:
Shouldn't this (and other places) be:
#if defined(CONFIG_44x) || defined(CONFIG_BOOKE)
if you are going to exclude 40x for now? Otherwise this is still
enabled on 405 and
On Jul 22, 2008, at 8:47 PM, Luis Machado wrote:
Hi,
That, or adding a small function to move the bits to the appropriate
registers (set_dbcr or set_dac_events).
Do you think it's worth to support this facility on 405's
processors? If
so, i'll gladly work on a solution to it.
I would
Some comment, first the above negate conditional
looks rather ugly, I'd rather do a
#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
dbcr0 case
#else
dabr case
#endif
Yes, it makes sense. I'll switch it around.
second I wonder why we have the notify_die only for one case,
On Wed, 2008-07-23 at 11:53 -0400, Josh Boyer wrote:
Shouldn't this (and other places) be:
#if defined(CONFIG_44x) || defined(CONFIG_BOOKE)
if you are going to exclude 40x for now? Otherwise this is still
enabled on 405 and setting the wrong register.
josh
Yes, sorry. I wasn't aware
On Jul 23, 2008, at 10:53 AM, Josh Boyer wrote:
On Tue, 22 Jul 2008 22:47:58 -0300
Luis Machado [EMAIL PROTECTED] wrote:
Hi,
That, or adding a small function to move the bits to the appropriate
registers (set_dbcr or set_dac_events).
Do you think it's worth to support this facility on
Hi,
That, or adding a small function to move the bits to the appropriate
registers (set_dbcr or set_dac_events).
Do you think it's worth to support this facility on 405's processors? If
so, i'll gladly work on a solution to it.
I would think so. There's really no difference from a
This doesn't look right for how it's coded. This would be the
CONFIG_4xx || CONFIG_BOOKE case, but CONFIG_4xx includes PowerPC 405.
That has a different bit layout among the DBCR registers. Namely, on
405 you would be clearing the TDE and IAC1 events because the DAC
events are in DBCR1,
On Mon, 21 Jul 2008 13:36:33 -0300
Luis Machado [EMAIL PROTECTED] wrote:
This doesn't look right for how it's coded. This would be the
CONFIG_4xx || CONFIG_BOOKE case, but CONFIG_4xx includes PowerPC 405.
That has a different bit layout among the DBCR registers. Namely, on
405 you
On Fri, 20 Jun 2008 17:14:53 -0300
Luis Machado [EMAIL PROTECTED] wrote:
Follows a re-worked patch that unifies the handling of hardware
watchpoint structures for DABR-based and DAC-based processors.
The flow is exactly the same for DABR-based processors.
As for the DAC-based code, i've
Hi guys,
Did anyone have a chance to go over this patch? Looking forward to
receive feedbacks on it.
Thanks!
Regards,
Luis
On Fri, 2008-06-20 at 17:14 -0300, Luis Machado wrote:
On Thu, 2008-05-22 at 13:51 +1000, Paul Mackerras wrote:
Luis Machado writes:
This is a patch that has been
On Thu, 2008-05-22 at 13:51 +1000, Paul Mackerras wrote:
Luis Machado writes:
This is a patch that has been sitting idle for quite some time. I
decided to move it further because it is something useful. It was
originally written by Michel Darneille, based off of 2.6.16.
The original
Kumar was just mentioning this post a few messages ago:
http://ozlabs.org/pipermail/linuxppc-dev/2008-May/055745.html
That is a very interesting approach to handle all the differences
between each processor's architecture, and a much cleaner way to set the
facilities we want than the
On Thu, 2008-05-22 at 13:51 +1000, Paul Mackerras wrote:
Luis Machado writes:
This is a patch that has been sitting idle for quite some time. I
decided to move it further because it is something useful. It was
originally written by Michel Darneille, based off of 2.6.16.
The original
On Wed, 2008-05-21 at 23:46 -0700, Roland McGrath wrote:
I would think there would be a different REQUEST value to mean set a
hardware breakpoint. Roland McGrath (cc'd) might be able to tell us
what other architectures do.
Other architectures don't give a good model to follow. (If
I would think there would be a different REQUEST value to mean set a
hardware breakpoint. Roland McGrath (cc'd) might be able to tell us
what other architectures do.
Other architectures don't give a good model to follow. (If anything,
they just trivally virtualize their own idiosyncratic
Hi,
This is a patch that has been sitting idle for quite some time. I
decided to move it further because it is something useful. It was
originally written by Michel Darneille, based off of 2.6.16.
The original patch, though, was not compatible with the current DABR
logic. DABR's are used to
Two real quick notes.
Take a look at:
http://ozlabs.org/pipermail/linuxppc-dev/2008-May/055745.html
and can you try and post the patch inline next time. Hard to provide
review comments on it :)
- k
___
Linuxppc-dev mailing list
Thanks for the inlining tip. It should be now. :-)
So, basically we are looking at a cleaner and much better interface to
set such hardware features? That's something that would greatly improve
the communication from, say, GDB to the kernel regarding these
facilities.
Regards,
Luis
On Wed,
Luis Machado writes:
This is a patch that has been sitting idle for quite some time. I
decided to move it further because it is something useful. It was
originally written by Michel Darneille, based off of 2.6.16.
The original patch, though, was not compatible with the current DABR
logic.
26 matches
Mail list logo
