From: Alan Cox
Lose all the PSB debug gunge. We can replace it with dev_dbg() like normal
drivers if and when we need debug on stuff.
Signed-off-by: Alan Cox
---
drivers/staging/gma500/mrst_crtc.c | 23 ++
drivers/staging/gma500/mrst_lvds.c | 12 +--
drivers/staging/
From: Alan Cox
Lose all the PSB debug gunge. We can replace it with dev_dbg() like normal
drivers if and when we need debug on stuff.
Signed-off-by: Alan Cox
---
drivers/staging/gma500/mrst_crtc.c | 23 ++
drivers/staging/gma500/mrst_lvds.c | 12 +--
drivers/staging/
From: Alan Cox
Lose all the PSB debug gunge. We can replace it with dev_dbg() like normal
drivers if and when we need debug on stuff.
Signed-off-by: Alan Cox
---
drivers/staging/gma500/mrst_crtc.c | 23 ++
drivers/staging/gma500/mrst_lvds.c | 12 +--
drivers/staging/
From: Alan Cox
Lose all the PSB debug gunge. We can replace it with dev_dbg() like normal
drivers if and when we need debug on stuff.
Signed-off-by: Alan Cox
---
drivers/staging/gma500/mrst_crtc.c | 23 ++
drivers/staging/gma500/mrst_lvds.c | 12 +--
drivers/staging/
From: Alan Cox
Lose all the PSB debug gunge. We can replace it with dev_dbg() like normal
drivers if and when we need debug on stuff.
Signed-off-by: Alan Cox
---
drivers/staging/gma500/mrst_crtc.c | 23 ++
drivers/staging/gma500/mrst_lvds.c | 12 +--
drivers/staging/
From: Alan Cox
Lose all the PSB debug gunge. We can replace it with dev_dbg() like normal
drivers if and when we need debug on stuff.
Signed-off-by: Alan Cox
---
drivers/staging/gma500/mrst_crtc.c | 23 ++
drivers/staging/gma500/mrst_lvds.c | 12 +--
drivers/staging/
From: Alan Cox
Lose all the PSB debug gunge. We can replace it with dev_dbg() like normal
drivers if and when we need debug on stuff.
Signed-off-by: Alan Cox
---
drivers/staging/gma500/mrst_crtc.c | 23 ++
drivers/staging/gma500/mrst_lvds.c | 12 +--
drivers/staging/
Hi Alan
Just a thought. Shouldn't we use the DRM macros for printing debug info?
-Patrik
On Wed, Jun 8, 2011 at 12:15 PM, Alan Cox wrote:
> From: Alan Cox
>
> Lose all the PSB debug gunge. We can replace it with dev_dbg() like normal
> drivers if and when we need debug on stuff.
>
> Signed-off
On Thu, 9 Jun 2011 03:10:03 +0200
Patrik Jakobsson wrote:
> Hi Alan
>
> Just a thought. Shouldn't we use the DRM macros for printing debug info?
Linux has perfectly good printing functions and using them means we can
use dev_dbg() which supports things like nice runtime switching.
On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote:
> On Thu, 9 Jun 2011 03:10:03 +0200
> Patrik Jakobsson wrote:
>
> > Hi Alan
> >
> > Just a thought. Shouldn't we use the DRM macros for printing debug info?
>
> Linux has perfectly good printing functions and using them means we can
> use dev_d
On Thu, Jun 9, 2011 at 12:36 PM, Dave Airlie wrote:
> On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote:
>> On Thu, 9 Jun 2011 03:10:03 +0200
>> Patrik Jakobsson wrote:
>>
>> > Hi Alan
>> >
>> > Just a thought. Shouldn't we use the DRM macros for printing debug info?
>>
>> Linux has perfectly good
> Though if psb wants to be different to other drm drivers it can lead the
> way, though it'll be a total nightmare for all the people who follow
> documentation on how to debug drm drivers using drm.debug=1,2,4,8. for
> various code paths.
Actually it seems to work out nicely because you can debu
> Yes, my concern was about drm.debug and use of all the DRM portability stuff
> (like using DRM_IRQ_HANDLED instead of IRQ_HANDLED, etc...)
>
> The portability might not be important at this point but I just wanted to
> raise
> the question so I know what is right / wrong.
The gma500 driver use
Hi Alan.
On Thu, Jun 9, 2011 at 14:04, Alan Cox wrote:
> The gma500 driver uses a lot of direct Linux services rather than
> disappearing into the weird world of drm_mm and the like so any
> portability is going to be a bit of an illusion at best.
Given that I've mucked around in drm_mm quite a
> Given that I've mucked around in drm_mm quite a bit I'd be very interested
> in your opinion about what's weird in it (and presumably what could be
> improved). Can you elaborate?
Mostly the API, which is also somewhat poorly documented. I've not dug
into the internals beyond trying to figure ou
On Mon, Jun 13, 2011 at 04:44:03PM +0100, Alan Cox wrote:
> > Given that I've mucked around in drm_mm quite a bit I'd be very interested
> > in your opinion about what's weird in it (and presumably what could be
> > improved). Can you elaborate?
>
> Mostly the API, which is also somewhat poorly do
On Thu, 9 Jun 2011 03:10:03 +0200
Patrik Jakobsson wrote:
> Hi Alan
>
> Just a thought. Shouldn't we use the DRM macros for printing debug info?
Linux has perfectly good printing functions and using them means we can
use dev_dbg() which supports things like nice runtime switching.
_
On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote:
> On Thu, 9 Jun 2011 03:10:03 +0200
> Patrik Jakobsson wrote:
>
> > Hi Alan
> >
> > Just a thought. Shouldn't we use the DRM macros for printing debug info?
>
> Linux has perfectly good printing functions and using them means we can
> use dev_d
On Thu, Jun 9, 2011 at 12:36 PM, Dave Airlie wrote:
> On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote:
>> On Thu, 9 Jun 2011 03:10:03 +0200
>> Patrik Jakobsson wrote:
>>
>> > Hi Alan
>> >
>> > Just a thought. Shouldn't we use the DRM macros for printing debug info?
>>
>> Linux has perfectly good
> Though if psb wants to be different to other drm drivers it can lead the
> way, though it'll be a total nightmare for all the people who follow
> documentation on how to debug drm drivers using drm.debug=1,2,4,8. for
> various code paths.
Actually it seems to work out nicely because you can debu
> Yes, my concern was about drm.debug and use of all the DRM portability stuff
> (like using DRM_IRQ_HANDLED instead of IRQ_HANDLED, etc...)
>
> The portability might not be important at this point but I just wanted to
> raise
> the question so I know what is right / wrong.
The gma500 driver use
Hi Alan.
On Thu, Jun 9, 2011 at 14:04, Alan Cox wrote:
> The gma500 driver uses a lot of direct Linux services rather than
> disappearing into the weird world of drm_mm and the like so any
> portability is going to be a bit of an illusion at best.
Given that I've mucked around in drm_mm quite a
> Given that I've mucked around in drm_mm quite a bit I'd be very interested
> in your opinion about what's weird in it (and presumably what could be
> improved). Can you elaborate?
Mostly the API, which is also somewhat poorly documented. I've not dug
into the internals beyond trying to figure ou
On Mon, Jun 13, 2011 at 04:44:03PM +0100, Alan Cox wrote:
> > Given that I've mucked around in drm_mm quite a bit I'd be very interested
> > in your opinion about what's weird in it (and presumably what could be
> > improved). Can you elaborate?
>
> Mostly the API, which is also somewhat poorly do
On Thu, 9 Jun 2011 03:10:03 +0200
Patrik Jakobsson wrote:
> Hi Alan
>
> Just a thought. Shouldn't we use the DRM macros for printing debug info?
Linux has perfectly good printing functions and using them means we can
use dev_dbg() which supports things like nice runtime switching.
_
On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote:
> On Thu, 9 Jun 2011 03:10:03 +0200
> Patrik Jakobsson wrote:
>
> > Hi Alan
> >
> > Just a thought. Shouldn't we use the DRM macros for printing debug info?
>
> Linux has perfectly good printing functions and using them means we can
> use dev_d
On Thu, Jun 9, 2011 at 12:36 PM, Dave Airlie wrote:
> On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote:
>> On Thu, 9 Jun 2011 03:10:03 +0200
>> Patrik Jakobsson wrote:
>>
>> > Hi Alan
>> >
>> > Just a thought. Shouldn't we use the DRM macros for printing debug info?
>>
>> Linux has perfectly good
> Though if psb wants to be different to other drm drivers it can lead the
> way, though it'll be a total nightmare for all the people who follow
> documentation on how to debug drm drivers using drm.debug=1,2,4,8. for
> various code paths.
Actually it seems to work out nicely because you can debu
> Yes, my concern was about drm.debug and use of all the DRM portability stuff
> (like using DRM_IRQ_HANDLED instead of IRQ_HANDLED, etc...)
>
> The portability might not be important at this point but I just wanted to
> raise
> the question so I know what is right / wrong.
The gma500 driver use
Hi Alan.
On Thu, Jun 9, 2011 at 14:04, Alan Cox wrote:
> The gma500 driver uses a lot of direct Linux services rather than
> disappearing into the weird world of drm_mm and the like so any
> portability is going to be a bit of an illusion at best.
Given that I've mucked around in drm_mm quite a
> Given that I've mucked around in drm_mm quite a bit I'd be very interested
> in your opinion about what's weird in it (and presumably what could be
> improved). Can you elaborate?
Mostly the API, which is also somewhat poorly documented. I've not dug
into the internals beyond trying to figure ou
On Mon, Jun 13, 2011 at 04:44:03PM +0100, Alan Cox wrote:
> > Given that I've mucked around in drm_mm quite a bit I'd be very interested
> > in your opinion about what's weird in it (and presumably what could be
> > improved). Can you elaborate?
>
> Mostly the API, which is also somewhat poorly do
On Thu, 9 Jun 2011 03:10:03 +0200
Patrik Jakobsson wrote:
> Hi Alan
>
> Just a thought. Shouldn't we use the DRM macros for printing debug info?
Linux has perfectly good printing functions and using them means we can
use dev_dbg() which supports things like nice runtime switching.
_
On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote:
> On Thu, 9 Jun 2011 03:10:03 +0200
> Patrik Jakobsson wrote:
>
> > Hi Alan
> >
> > Just a thought. Shouldn't we use the DRM macros for printing debug info?
>
> Linux has perfectly good printing functions and using them means we can
> use dev_d
On Thu, Jun 9, 2011 at 12:36 PM, Dave Airlie wrote:
> On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote:
>> On Thu, 9 Jun 2011 03:10:03 +0200
>> Patrik Jakobsson wrote:
>>
>> > Hi Alan
>> >
>> > Just a thought. Shouldn't we use the DRM macros for printing debug info?
>>
>> Linux has perfectly good
> Though if psb wants to be different to other drm drivers it can lead the
> way, though it'll be a total nightmare for all the people who follow
> documentation on how to debug drm drivers using drm.debug=1,2,4,8. for
> various code paths.
Actually it seems to work out nicely because you can debu
> Yes, my concern was about drm.debug and use of all the DRM portability stuff
> (like using DRM_IRQ_HANDLED instead of IRQ_HANDLED, etc...)
>
> The portability might not be important at this point but I just wanted to
> raise
> the question so I know what is right / wrong.
The gma500 driver use
Hi Alan.
On Thu, Jun 9, 2011 at 14:04, Alan Cox wrote:
> The gma500 driver uses a lot of direct Linux services rather than
> disappearing into the weird world of drm_mm and the like so any
> portability is going to be a bit of an illusion at best.
Given that I've mucked around in drm_mm quite a
> Given that I've mucked around in drm_mm quite a bit I'd be very interested
> in your opinion about what's weird in it (and presumably what could be
> improved). Can you elaborate?
Mostly the API, which is also somewhat poorly documented. I've not dug
into the internals beyond trying to figure ou
On Mon, Jun 13, 2011 at 04:44:03PM +0100, Alan Cox wrote:
> > Given that I've mucked around in drm_mm quite a bit I'd be very interested
> > in your opinion about what's weird in it (and presumably what could be
> > improved). Can you elaborate?
>
> Mostly the API, which is also somewhat poorly do
On Thu, 9 Jun 2011 03:10:03 +0200
Patrik Jakobsson wrote:
> Hi Alan
>
> Just a thought. Shouldn't we use the DRM macros for printing debug info?
Linux has perfectly good printing functions and using them means we can
use dev_dbg() which supports things like nice runtime switching.
_
On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote:
> On Thu, 9 Jun 2011 03:10:03 +0200
> Patrik Jakobsson wrote:
>
> > Hi Alan
> >
> > Just a thought. Shouldn't we use the DRM macros for printing debug info?
>
> Linux has perfectly good printing functions and using them means we can
> use dev_d
On Thu, Jun 9, 2011 at 12:36 PM, Dave Airlie wrote:
> On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote:
>> On Thu, 9 Jun 2011 03:10:03 +0200
>> Patrik Jakobsson wrote:
>>
>> > Hi Alan
>> >
>> > Just a thought. Shouldn't we use the DRM macros for printing debug info?
>>
>> Linux has perfectly good
> Though if psb wants to be different to other drm drivers it can lead the
> way, though it'll be a total nightmare for all the people who follow
> documentation on how to debug drm drivers using drm.debug=1,2,4,8. for
> various code paths.
Actually it seems to work out nicely because you can debu
> Yes, my concern was about drm.debug and use of all the DRM portability stuff
> (like using DRM_IRQ_HANDLED instead of IRQ_HANDLED, etc...)
>
> The portability might not be important at this point but I just wanted to
> raise
> the question so I know what is right / wrong.
The gma500 driver use
Hi Alan.
On Thu, Jun 9, 2011 at 14:04, Alan Cox wrote:
> The gma500 driver uses a lot of direct Linux services rather than
> disappearing into the weird world of drm_mm and the like so any
> portability is going to be a bit of an illusion at best.
Given that I've mucked around in drm_mm quite a
> Given that I've mucked around in drm_mm quite a bit I'd be very interested
> in your opinion about what's weird in it (and presumably what could be
> improved). Can you elaborate?
Mostly the API, which is also somewhat poorly documented. I've not dug
into the internals beyond trying to figure ou
On Mon, Jun 13, 2011 at 04:44:03PM +0100, Alan Cox wrote:
> > Given that I've mucked around in drm_mm quite a bit I'd be very interested
> > in your opinion about what's weird in it (and presumably what could be
> > improved). Can you elaborate?
>
> Mostly the API, which is also somewhat poorly do
On Thu, 9 Jun 2011 03:10:03 +0200
Patrik Jakobsson wrote:
> Hi Alan
>
> Just a thought. Shouldn't we use the DRM macros for printing debug info?
Linux has perfectly good printing functions and using them means we can
use dev_dbg() which supports things like nice runtime switching.
_
On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote:
> On Thu, 9 Jun 2011 03:10:03 +0200
> Patrik Jakobsson wrote:
>
> > Hi Alan
> >
> > Just a thought. Shouldn't we use the DRM macros for printing debug info?
>
> Linux has perfectly good printing functions and using them means we can
> use dev_d
On Thu, Jun 9, 2011 at 12:36 PM, Dave Airlie wrote:
> On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote:
>> On Thu, 9 Jun 2011 03:10:03 +0200
>> Patrik Jakobsson wrote:
>>
>> > Hi Alan
>> >
>> > Just a thought. Shouldn't we use the DRM macros for printing debug info?
>>
>> Linux has perfectly good
> Though if psb wants to be different to other drm drivers it can lead the
> way, though it'll be a total nightmare for all the people who follow
> documentation on how to debug drm drivers using drm.debug=1,2,4,8. for
> various code paths.
Actually it seems to work out nicely because you can debu
> Yes, my concern was about drm.debug and use of all the DRM portability stuff
> (like using DRM_IRQ_HANDLED instead of IRQ_HANDLED, etc...)
>
> The portability might not be important at this point but I just wanted to
> raise
> the question so I know what is right / wrong.
The gma500 driver use
Hi Alan.
On Thu, Jun 9, 2011 at 14:04, Alan Cox wrote:
> The gma500 driver uses a lot of direct Linux services rather than
> disappearing into the weird world of drm_mm and the like so any
> portability is going to be a bit of an illusion at best.
Given that I've mucked around in drm_mm quite a
> Given that I've mucked around in drm_mm quite a bit I'd be very interested
> in your opinion about what's weird in it (and presumably what could be
> improved). Can you elaborate?
Mostly the API, which is also somewhat poorly documented. I've not dug
into the internals beyond trying to figure ou
On Mon, Jun 13, 2011 at 04:44:03PM +0100, Alan Cox wrote:
> > Given that I've mucked around in drm_mm quite a bit I'd be very interested
> > in your opinion about what's weird in it (and presumably what could be
> > improved). Can you elaborate?
>
> Mostly the API, which is also somewhat poorly do
On Thu, 9 Jun 2011 03:10:03 +0200
Patrik Jakobsson wrote:
> Hi Alan
>
> Just a thought. Shouldn't we use the DRM macros for printing debug info?
Linux has perfectly good printing functions and using them means we can
use dev_dbg() which supports things like nice runtime switching.
_
On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote:
> On Thu, 9 Jun 2011 03:10:03 +0200
> Patrik Jakobsson wrote:
>
> > Hi Alan
> >
> > Just a thought. Shouldn't we use the DRM macros for printing debug info?
>
> Linux has perfectly good printing functions and using them means we can
> use dev_d
On Thu, Jun 9, 2011 at 12:36 PM, Dave Airlie wrote:
> On Thu, 2011-06-09 at 09:11 +0100, Alan Cox wrote:
>> On Thu, 9 Jun 2011 03:10:03 +0200
>> Patrik Jakobsson wrote:
>>
>> > Hi Alan
>> >
>> > Just a thought. Shouldn't we use the DRM macros for printing debug info?
>>
>> Linux has perfectly good
> Though if psb wants to be different to other drm drivers it can lead the
> way, though it'll be a total nightmare for all the people who follow
> documentation on how to debug drm drivers using drm.debug=1,2,4,8. for
> various code paths.
Actually it seems to work out nicely because you can debu
> Yes, my concern was about drm.debug and use of all the DRM portability stuff
> (like using DRM_IRQ_HANDLED instead of IRQ_HANDLED, etc...)
>
> The portability might not be important at this point but I just wanted to
> raise
> the question so I know what is right / wrong.
The gma500 driver use
Hi Alan.
On Thu, Jun 9, 2011 at 14:04, Alan Cox wrote:
> The gma500 driver uses a lot of direct Linux services rather than
> disappearing into the weird world of drm_mm and the like so any
> portability is going to be a bit of an illusion at best.
Given that I've mucked around in drm_mm quite a
> Given that I've mucked around in drm_mm quite a bit I'd be very interested
> in your opinion about what's weird in it (and presumably what could be
> improved). Can you elaborate?
Mostly the API, which is also somewhat poorly documented. I've not dug
into the internals beyond trying to figure ou
On Mon, Jun 13, 2011 at 04:44:03PM +0100, Alan Cox wrote:
> > Given that I've mucked around in drm_mm quite a bit I'd be very interested
> > in your opinion about what's weird in it (and presumably what could be
> > improved). Can you elaborate?
>
> Mostly the API, which is also somewhat poorly do
64 matches
Mail list logo
