[PATCH 00/10] Start documenting the radeon drm better

[Rafał Miłecki]

2012/6/29  :
> From: Alex Deucher 
>
> This is something I've been wanting to do for a while and
> I finally spent a little time getting a start on it. ?There
> is still a lot to do and not all of my descriptions are great,
> but I think we can document the rest in bits and pieces. I
> also added a note about what asics the function is applicable
> to. I tried to start with the more common and complex code.
> I was thinking it would make sense to have an informal
> documentation policy something like the following:
> 1. If you edit an undocumented function, add documentation
> 2. If you edit a documented function and change how it works,
> ? update the documentation
> 3. All new functions added should be documented
>
> Fulfulling all of these for stable fixes could pose problems
> so obviously there is some leeway.
>
> Thoughts?

I'd try to avoid repeating definitions over and over, but generally
THIS IS GREAT. Thanks a lot for doing that!

-- 
Rafa?

[PATCH 00/10] Start documenting the radeon drm better

[Christian König]

On 29.06.2012 16:28, alexdeucher at gmail.com wrote:
> From: Alex Deucher 
>
> This is something I've been wanting to do for a while and
> I finally spent a little time getting a start on it.  There
> is still a lot to do and not all of my descriptions are great,
> but I think we can document the rest in bits and pieces. I
> also added a note about what asics the function is applicable
> to. I tried to start with the more common and complex code.
> I was thinking it would make sense to have an informal
> documentation policy something like the following:
> 1. If you edit an undocumented function, add documentation
> 2. If you edit a documented function and change how it works,
> update the documentation
> 3. All new functions added should be documented
>
> Fulfulling all of these for stable fixes could pose problems
> so obviously there is some leeway.
>
> Thoughts?
Sounds like a good idea to me, but could we move the old and deprecated 
non KMS code into it's own subdirectory or something like that first?

Also for some files it might be a good idea to spread them into separate 
ones first, like the gart and vm and/or the ring and ib stuff.

Cheers,
Christian.

>
> Alex Deucher (10):
>drm/radeon: document radeon_device.c
>drm/radeon: document radeon_kms.c
>drm/radeon: document radeon_irq_kms.c
>drm/radeon: document radeon_asic.c
>drm/radeon: document radeon_fence.c
>drm/radeon: document radeon_ring.c
>drm/radeon: document non-VM functions in radeon_gart.c
>drm/radeon: document VM functions in radeon_gart.c
>drm/radeon: start to document the functions r100.c
>drm/radeon: start to document evergreen.c
>
>   drivers/gpu/drm/radeon/evergreen.c  |  120 ++
>   drivers/gpu/drm/radeon/r100.c   |  127 ++-
>   drivers/gpu/drm/radeon/radeon_asic.c|   46 
>   drivers/gpu/drm/radeon/radeon_device.c  |  344 +++-
>   drivers/gpu/drm/radeon/radeon_fence.c   |  373 +
>   drivers/gpu/drm/radeon/radeon_gart.c|  391 
> ++-
>   drivers/gpu/drm/radeon/radeon_irq_kms.c |  150 
>   drivers/gpu/drm/radeon/radeon_kms.c |  126 ++
>   drivers/gpu/drm/radeon/radeon_ring.c|  374 
> +-
>   9 files changed, 2041 insertions(+), 10 deletions(-)
>

[PATCH 00/10] Start documenting the radeon drm better

[Alex Deucher]

On Fri, Jun 29, 2012 at 10:39 AM, Christian K?nig
 wrote:
> On 29.06.2012 16:28, alexdeucher at gmail.com wrote:
>>
>> From: Alex Deucher 
>>
>> This is something I've been wanting to do for a while and
>> I finally spent a little time getting a start on it. ?There
>> is still a lot to do and not all of my descriptions are great,
>> but I think we can document the rest in bits and pieces. I
>> also added a note about what asics the function is applicable
>> to. I tried to start with the more common and complex code.
>> I was thinking it would make sense to have an informal
>> documentation policy something like the following:
>> 1. If you edit an undocumented function, add documentation
>> 2. If you edit a documented function and change how it works,
>> ? ?update the documentation
>> 3. All new functions added should be documented
>>
>> Fulfulling all of these for stable fixes could pose problems
>> so obviously there is some leeway.
>>
>> Thoughts?
>
> Sounds like a good idea to me, but could we move the old and deprecated non
> KMS code into it's own subdirectory or something like that first?

That would be nice.  Maybe add a new ums folder in radeon?

>
> Also for some files it might be a good idea to spread them into separate
> ones first, like the gart and vm and/or the ring and ib stuff.

Yeah, there is a lot of room of clean up.  r100.c could be split into
about 3 files to match newer asics.

Alex

>
> Cheers,
> Christian.
>
>
>>
>> Alex Deucher (10):
>> ? drm/radeon: document radeon_device.c
>> ? drm/radeon: document radeon_kms.c
>> ? drm/radeon: document radeon_irq_kms.c
>> ? drm/radeon: document radeon_asic.c
>> ? drm/radeon: document radeon_fence.c
>> ? drm/radeon: document radeon_ring.c
>> ? drm/radeon: document non-VM functions in radeon_gart.c
>> ? drm/radeon: document VM functions in radeon_gart.c
>> ? drm/radeon: start to document the functions r100.c
>> ? drm/radeon: start to document evergreen.c
>>
>> ?drivers/gpu/drm/radeon/evergreen.c ? ? ?| ?120 ++
>> ?drivers/gpu/drm/radeon/r100.c ? ? ? ? ? | ?127 ++-
>> ?drivers/gpu/drm/radeon/radeon_asic.c ? ?| ? 46 
>> ?drivers/gpu/drm/radeon/radeon_device.c ?| ?344
>> +++-
>> ?drivers/gpu/drm/radeon/radeon_fence.c ? | ?373
>> +
>> ?drivers/gpu/drm/radeon/radeon_gart.c ? ?| ?391
>> ++-
>> ?drivers/gpu/drm/radeon/radeon_irq_kms.c | ?150 
>> ?drivers/gpu/drm/radeon/radeon_kms.c ? ? | ?126 ++
>> ?drivers/gpu/drm/radeon/radeon_ring.c ? ?| ?374
>> +-
>> ?9 files changed, 2041 insertions(+), 10 deletions(-)
>>
>
>

[PATCH 00/10] Start documenting the radeon drm better

[Alex Deucher]

On Fri, Jun 29, 2012 at 10:42 AM, Tom Stellard  
wrote:
> On Fri, Jun 29, 2012 at 10:28:20AM -0400, alexdeucher at gmail.com wrote:
>> From: Alex Deucher 
>>
>> This is something I've been wanting to do for a while and
>> I finally spent a little time getting a start on it. ?There
>> is still a lot to do and not all of my descriptions are great,
>> but I think we can document the rest in bits and pieces. I
>> also added a note about what asics the function is applicable
>> to. I tried to start with the more common and complex code.
>> I was thinking it would make sense to have an informal
>> documentation policy something like the following:
>> 1. If you edit an undocumented function, add documentation
>> 2. If you edit a documented function and change how it works,
>> ? ?update the documentation
>> 3. All new functions added should be documented
>>
>> Fulfulling all of these for stable fixes could pose problems
>> so obviously there is some leeway.
>>
>> Thoughts?
>>
> I think this is a good policy. ?You might also want to specify the
> documentation style to use. ?It looks like you are using some form of
> Doxygen comments. ?I would also be in favor of a similar policy for
> userspace code.

I just copied the existing documentation bits in radeon and the drm in
general.  I'm open to other suggestions.

Alex

>
> -Tom
>
>> Alex Deucher (10):
>> ? drm/radeon: document radeon_device.c
>> ? drm/radeon: document radeon_kms.c
>> ? drm/radeon: document radeon_irq_kms.c
>> ? drm/radeon: document radeon_asic.c
>> ? drm/radeon: document radeon_fence.c
>> ? drm/radeon: document radeon_ring.c
>> ? drm/radeon: document non-VM functions in radeon_gart.c
>> ? drm/radeon: document VM functions in radeon_gart.c
>> ? drm/radeon: start to document the functions r100.c
>> ? drm/radeon: start to document evergreen.c
>>
>> ?drivers/gpu/drm/radeon/evergreen.c ? ? ?| ?120 ++
>> ?drivers/gpu/drm/radeon/r100.c ? ? ? ? ? | ?127 ++-
>> ?drivers/gpu/drm/radeon/radeon_asic.c ? ?| ? 46 
>> ?drivers/gpu/drm/radeon/radeon_device.c ?| ?344 +++-
>> ?drivers/gpu/drm/radeon/radeon_fence.c ? | ?373 +
>> ?drivers/gpu/drm/radeon/radeon_gart.c ? ?| ?391 
>> ++-
>> ?drivers/gpu/drm/radeon/radeon_irq_kms.c | ?150 
>> ?drivers/gpu/drm/radeon/radeon_kms.c ? ? | ?126 ++
>> ?drivers/gpu/drm/radeon/radeon_ring.c ? ?| ?374 
>> +-
>> ?9 files changed, 2041 insertions(+), 10 deletions(-)
>>
>> --
>> 1.7.7.5
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>

[PATCH 00/10] Start documenting the radeon drm better

[Tom Stellard]

On Fri, Jun 29, 2012 at 10:28:20AM -0400, alexdeucher at gmail.com wrote:
> From: Alex Deucher 
> 
> This is something I've been wanting to do for a while and
> I finally spent a little time getting a start on it.  There
> is still a lot to do and not all of my descriptions are great,
> but I think we can document the rest in bits and pieces. I
> also added a note about what asics the function is applicable
> to. I tried to start with the more common and complex code.
> I was thinking it would make sense to have an informal
> documentation policy something like the following:
> 1. If you edit an undocumented function, add documentation
> 2. If you edit a documented function and change how it works,
>update the documentation
> 3. All new functions added should be documented
> 
> Fulfulling all of these for stable fixes could pose problems
> so obviously there is some leeway.
> 
> Thoughts?
>
I think this is a good policy.  You might also want to specify the
documentation style to use.  It looks like you are using some form of
Doxygen comments.  I would also be in favor of a similar policy for
userspace code.

-Tom

> Alex Deucher (10):
>   drm/radeon: document radeon_device.c
>   drm/radeon: document radeon_kms.c
>   drm/radeon: document radeon_irq_kms.c
>   drm/radeon: document radeon_asic.c
>   drm/radeon: document radeon_fence.c
>   drm/radeon: document radeon_ring.c
>   drm/radeon: document non-VM functions in radeon_gart.c
>   drm/radeon: document VM functions in radeon_gart.c
>   drm/radeon: start to document the functions r100.c
>   drm/radeon: start to document evergreen.c
> 
>  drivers/gpu/drm/radeon/evergreen.c  |  120 ++
>  drivers/gpu/drm/radeon/r100.c   |  127 ++-
>  drivers/gpu/drm/radeon/radeon_asic.c|   46 
>  drivers/gpu/drm/radeon/radeon_device.c  |  344 +++-
>  drivers/gpu/drm/radeon/radeon_fence.c   |  373 +
>  drivers/gpu/drm/radeon/radeon_gart.c|  391 
> ++-
>  drivers/gpu/drm/radeon/radeon_irq_kms.c |  150 
>  drivers/gpu/drm/radeon/radeon_kms.c |  126 ++
>  drivers/gpu/drm/radeon/radeon_ring.c|  374 +-
>  9 files changed, 2041 insertions(+), 10 deletions(-)
> 
> -- 
> 1.7.7.5
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

[PATCH 00/10] Start documenting the radeon drm better

[alexdeuc...@gmail.com]

From: Alex Deucher 

This is something I've been wanting to do for a while and
I finally spent a little time getting a start on it.  There
is still a lot to do and not all of my descriptions are great,
but I think we can document the rest in bits and pieces. I
also added a note about what asics the function is applicable
to. I tried to start with the more common and complex code.
I was thinking it would make sense to have an informal
documentation policy something like the following:
1. If you edit an undocumented function, add documentation
2. If you edit a documented function and change how it works,
   update the documentation
3. All new functions added should be documented

Fulfulling all of these for stable fixes could pose problems
so obviously there is some leeway.

Thoughts?

Alex Deucher (10):
  drm/radeon: document radeon_device.c
  drm/radeon: document radeon_kms.c
  drm/radeon: document radeon_irq_kms.c
  drm/radeon: document radeon_asic.c
  drm/radeon: document radeon_fence.c
  drm/radeon: document radeon_ring.c
  drm/radeon: document non-VM functions in radeon_gart.c
  drm/radeon: document VM functions in radeon_gart.c
  drm/radeon: start to document the functions r100.c
  drm/radeon: start to document evergreen.c

 drivers/gpu/drm/radeon/evergreen.c  |  120 ++
 drivers/gpu/drm/radeon/r100.c   |  127 ++-
 drivers/gpu/drm/radeon/radeon_asic.c|   46 
 drivers/gpu/drm/radeon/radeon_device.c  |  344 +++-
 drivers/gpu/drm/radeon/radeon_fence.c   |  373 +
 drivers/gpu/drm/radeon/radeon_gart.c|  391 ++-
 drivers/gpu/drm/radeon/radeon_irq_kms.c |  150 
 drivers/gpu/drm/radeon/radeon_kms.c |  126 ++
 drivers/gpu/drm/radeon/radeon_ring.c|  374 +-
 9 files changed, 2041 insertions(+), 10 deletions(-)

-- 
1.7.7.5

[PATCH 00/10] Start documenting the radeon drm better

[alexdeucher]

From: Alex Deucher alexander.deuc...@amd.com

This is something I've been wanting to do for a while and
I finally spent a little time getting a start on it.  There
is still a lot to do and not all of my descriptions are great,
but I think we can document the rest in bits and pieces. I
also added a note about what asics the function is applicable
to. I tried to start with the more common and complex code.
I was thinking it would make sense to have an informal
documentation policy something like the following:
1. If you edit an undocumented function, add documentation
2. If you edit a documented function and change how it works,
   update the documentation
3. All new functions added should be documented

Fulfulling all of these for stable fixes could pose problems
so obviously there is some leeway.

Thoughts?

Alex Deucher (10):
  drm/radeon: document radeon_device.c
  drm/radeon: document radeon_kms.c
  drm/radeon: document radeon_irq_kms.c
  drm/radeon: document radeon_asic.c
  drm/radeon: document radeon_fence.c
  drm/radeon: document radeon_ring.c
  drm/radeon: document non-VM functions in radeon_gart.c
  drm/radeon: document VM functions in radeon_gart.c
  drm/radeon: start to document the functions r100.c
  drm/radeon: start to document evergreen.c

 drivers/gpu/drm/radeon/evergreen.c  |  120 ++
 drivers/gpu/drm/radeon/r100.c   |  127 ++-
 drivers/gpu/drm/radeon/radeon_asic.c|   46 
 drivers/gpu/drm/radeon/radeon_device.c  |  344 +++-
 drivers/gpu/drm/radeon/radeon_fence.c   |  373 +
 drivers/gpu/drm/radeon/radeon_gart.c|  391 ++-
 drivers/gpu/drm/radeon/radeon_irq_kms.c |  150 
 drivers/gpu/drm/radeon/radeon_kms.c |  126 ++
 drivers/gpu/drm/radeon/radeon_ring.c|  374 +-
 9 files changed, 2041 insertions(+), 10 deletions(-)

-- 
1.7.7.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/10] Start documenting the radeon drm better

[Christian König]

On 29.06.2012 16:28, alexdeuc...@gmail.com wrote:

From: Alex Deucher alexander.deuc...@amd.com

This is something I've been wanting to do for a while and
I finally spent a little time getting a start on it.  There
is still a lot to do and not all of my descriptions are great,
but I think we can document the rest in bits and pieces. I
also added a note about what asics the function is applicable
to. I tried to start with the more common and complex code.
I was thinking it would make sense to have an informal
documentation policy something like the following:
1. If you edit an undocumented function, add documentation
2. If you edit a documented function and change how it works,
update the documentation
3. All new functions added should be documented

Fulfulling all of these for stable fixes could pose problems
so obviously there is some leeway.

Thoughts?
Sounds like a good idea to me, but could we move the old and deprecated 
non KMS code into it's own subdirectory or something like that first?


Also for some files it might be a good idea to spread them into separate 
ones first, like the gart and vm and/or the ring and ib stuff.


Cheers,
Christian.



Alex Deucher (10):
   drm/radeon: document radeon_device.c
   drm/radeon: document radeon_kms.c
   drm/radeon: document radeon_irq_kms.c
   drm/radeon: document radeon_asic.c
   drm/radeon: document radeon_fence.c
   drm/radeon: document radeon_ring.c
   drm/radeon: document non-VM functions in radeon_gart.c
   drm/radeon: document VM functions in radeon_gart.c
   drm/radeon: start to document the functions r100.c
   drm/radeon: start to document evergreen.c

  drivers/gpu/drm/radeon/evergreen.c  |  120 ++
  drivers/gpu/drm/radeon/r100.c   |  127 ++-
  drivers/gpu/drm/radeon/radeon_asic.c|   46 
  drivers/gpu/drm/radeon/radeon_device.c  |  344 +++-
  drivers/gpu/drm/radeon/radeon_fence.c   |  373 +
  drivers/gpu/drm/radeon/radeon_gart.c|  391 ++-
  drivers/gpu/drm/radeon/radeon_irq_kms.c |  150 
  drivers/gpu/drm/radeon/radeon_kms.c |  126 ++
  drivers/gpu/drm/radeon/radeon_ring.c|  374 +-
  9 files changed, 2041 insertions(+), 10 deletions(-)




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/10] Start documenting the radeon drm better

[Alex Deucher]

On Fri, Jun 29, 2012 at 10:42 AM, Tom Stellard thomas.stell...@amd.com wrote:
 On Fri, Jun 29, 2012 at 10:28:20AM -0400, alexdeuc...@gmail.com wrote:
 From: Alex Deucher alexander.deuc...@amd.com

 This is something I've been wanting to do for a while and
 I finally spent a little time getting a start on it.  There
 is still a lot to do and not all of my descriptions are great,
 but I think we can document the rest in bits and pieces. I
 also added a note about what asics the function is applicable
 to. I tried to start with the more common and complex code.
 I was thinking it would make sense to have an informal
 documentation policy something like the following:
 1. If you edit an undocumented function, add documentation
 2. If you edit a documented function and change how it works,
    update the documentation
 3. All new functions added should be documented

 Fulfulling all of these for stable fixes could pose problems
 so obviously there is some leeway.

 Thoughts?

 I think this is a good policy.  You might also want to specify the
 documentation style to use.  It looks like you are using some form of
 Doxygen comments.  I would also be in favor of a similar policy for
 userspace code.

I just copied the existing documentation bits in radeon and the drm in
general.  I'm open to other suggestions.

Alex


 -Tom

 Alex Deucher (10):
   drm/radeon: document radeon_device.c
   drm/radeon: document radeon_kms.c
   drm/radeon: document radeon_irq_kms.c
   drm/radeon: document radeon_asic.c
   drm/radeon: document radeon_fence.c
   drm/radeon: document radeon_ring.c
   drm/radeon: document non-VM functions in radeon_gart.c
   drm/radeon: document VM functions in radeon_gart.c
   drm/radeon: start to document the functions r100.c
   drm/radeon: start to document evergreen.c

  drivers/gpu/drm/radeon/evergreen.c      |  120 ++
  drivers/gpu/drm/radeon/r100.c           |  127 ++-
  drivers/gpu/drm/radeon/radeon_asic.c    |   46 
  drivers/gpu/drm/radeon/radeon_device.c  |  344 +++-
  drivers/gpu/drm/radeon/radeon_fence.c   |  373 +
  drivers/gpu/drm/radeon/radeon_gart.c    |  391 
 ++-
  drivers/gpu/drm/radeon/radeon_irq_kms.c |  150 
  drivers/gpu/drm/radeon/radeon_kms.c     |  126 ++
  drivers/gpu/drm/radeon/radeon_ring.c    |  374 
 +-
  9 files changed, 2041 insertions(+), 10 deletions(-)

 --
 1.7.7.5

 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/10] Start documenting the radeon drm better

[Alex Deucher]

On Fri, Jun 29, 2012 at 10:39 AM, Christian König
deathsim...@vodafone.de wrote:
 On 29.06.2012 16:28, alexdeuc...@gmail.com wrote:

 From: Alex Deucher alexander.deuc...@amd.com

 This is something I've been wanting to do for a while and
 I finally spent a little time getting a start on it.  There
 is still a lot to do and not all of my descriptions are great,
 but I think we can document the rest in bits and pieces. I
 also added a note about what asics the function is applicable
 to. I tried to start with the more common and complex code.
 I was thinking it would make sense to have an informal
 documentation policy something like the following:
 1. If you edit an undocumented function, add documentation
 2. If you edit a documented function and change how it works,
    update the documentation
 3. All new functions added should be documented

 Fulfulling all of these for stable fixes could pose problems
 so obviously there is some leeway.

 Thoughts?

 Sounds like a good idea to me, but could we move the old and deprecated non
 KMS code into it's own subdirectory or something like that first?

That would be nice.  Maybe add a new ums folder in radeon?


 Also for some files it might be a good idea to spread them into separate
 ones first, like the gart and vm and/or the ring and ib stuff.

Yeah, there is a lot of room of clean up.  r100.c could be split into
about 3 files to match newer asics.

Alex


 Cheers,
 Christian.



 Alex Deucher (10):
   drm/radeon: document radeon_device.c
   drm/radeon: document radeon_kms.c
   drm/radeon: document radeon_irq_kms.c
   drm/radeon: document radeon_asic.c
   drm/radeon: document radeon_fence.c
   drm/radeon: document radeon_ring.c
   drm/radeon: document non-VM functions in radeon_gart.c
   drm/radeon: document VM functions in radeon_gart.c
   drm/radeon: start to document the functions r100.c
   drm/radeon: start to document evergreen.c

  drivers/gpu/drm/radeon/evergreen.c      |  120 ++
  drivers/gpu/drm/radeon/r100.c           |  127 ++-
  drivers/gpu/drm/radeon/radeon_asic.c    |   46 
  drivers/gpu/drm/radeon/radeon_device.c  |  344
 +++-
  drivers/gpu/drm/radeon/radeon_fence.c   |  373
 +
  drivers/gpu/drm/radeon/radeon_gart.c    |  391
 ++-
  drivers/gpu/drm/radeon/radeon_irq_kms.c |  150 
  drivers/gpu/drm/radeon/radeon_kms.c     |  126 ++
  drivers/gpu/drm/radeon/radeon_ring.c    |  374
 +-
  9 files changed, 2041 insertions(+), 10 deletions(-)



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/10] Start documenting the radeon drm better

[Tom Stellard]

On Fri, Jun 29, 2012 at 10:28:20AM -0400, alexdeuc...@gmail.com wrote:
 From: Alex Deucher alexander.deuc...@amd.com
 
 This is something I've been wanting to do for a while and
 I finally spent a little time getting a start on it.  There
 is still a lot to do and not all of my descriptions are great,
 but I think we can document the rest in bits and pieces. I
 also added a note about what asics the function is applicable
 to. I tried to start with the more common and complex code.
 I was thinking it would make sense to have an informal
 documentation policy something like the following:
 1. If you edit an undocumented function, add documentation
 2. If you edit a documented function and change how it works,
update the documentation
 3. All new functions added should be documented
 
 Fulfulling all of these for stable fixes could pose problems
 so obviously there is some leeway.
 
 Thoughts?

I think this is a good policy.  You might also want to specify the
documentation style to use.  It looks like you are using some form of
Doxygen comments.  I would also be in favor of a similar policy for
userspace code.

-Tom
 
 Alex Deucher (10):
   drm/radeon: document radeon_device.c
   drm/radeon: document radeon_kms.c
   drm/radeon: document radeon_irq_kms.c
   drm/radeon: document radeon_asic.c
   drm/radeon: document radeon_fence.c
   drm/radeon: document radeon_ring.c
   drm/radeon: document non-VM functions in radeon_gart.c
   drm/radeon: document VM functions in radeon_gart.c
   drm/radeon: start to document the functions r100.c
   drm/radeon: start to document evergreen.c
 
  drivers/gpu/drm/radeon/evergreen.c  |  120 ++
  drivers/gpu/drm/radeon/r100.c   |  127 ++-
  drivers/gpu/drm/radeon/radeon_asic.c|   46 
  drivers/gpu/drm/radeon/radeon_device.c  |  344 +++-
  drivers/gpu/drm/radeon/radeon_fence.c   |  373 +
  drivers/gpu/drm/radeon/radeon_gart.c|  391 
 ++-
  drivers/gpu/drm/radeon/radeon_irq_kms.c |  150 
  drivers/gpu/drm/radeon/radeon_kms.c |  126 ++
  drivers/gpu/drm/radeon/radeon_ring.c|  374 +-
  9 files changed, 2041 insertions(+), 10 deletions(-)
 
 -- 
 1.7.7.5
 
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/10] Start documenting the radeon drm better

[Rafał Miłecki]

2012/6/29  alexdeuc...@gmail.com:
 From: Alex Deucher alexander.deuc...@amd.com

 This is something I've been wanting to do for a while and
 I finally spent a little time getting a start on it.  There
 is still a lot to do and not all of my descriptions are great,
 but I think we can document the rest in bits and pieces. I
 also added a note about what asics the function is applicable
 to. I tried to start with the more common and complex code.
 I was thinking it would make sense to have an informal
 documentation policy something like the following:
 1. If you edit an undocumented function, add documentation
 2. If you edit a documented function and change how it works,
   update the documentation
 3. All new functions added should be documented

 Fulfulling all of these for stable fixes could pose problems
 so obviously there is some leeway.

 Thoughts?

I'd try to avoid repeating definitions over and over, but generally
THIS IS GREAT. Thanks a lot for doing that!

-- 
Rafał
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel