[PATCH] drm_crtc.c: fix some typo mistake and some annotations mistake

[John Hunter]

Hi Jani,

I did as you told me, I subscribed using my other email address, and
disable the mail delivery option in the management page of dri-devel.

Hope this may work.
Thanks.

Best regards,
John

On Fri, Mar 13, 2015 at 8:34 PM, Jani Nikula 
wrote:

> On Fri, 13 Mar 2015, Rob Clark  wrote:
> > hopefully someone else in China can suggest a good way of sending
> > patches (I have no clue there)
>
> An alternative is to subscribe with all email addresses you may be
> sending patches (or messages) from, but disabling list mail delivery for
> all but one address in the dri-devel list management interface.
>
> You can have git format-patch/send-email add a From: line at the
> beginning of the patch (separate from mail headers) matching the
> Signed-off-by. I forget the config for this, but it's there somewhere.
>
>
> HTH,
> Jani.
>
>
> --
> Jani Nikula, Intel Open Source Technology Center
>



-- 
Best regards
Junwang Zhao
Microprocessor Research and Develop Center
Department of Computer Science 
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachment was scrubbed...
URL: 

[PATCH] drm_crtc.c: fix some typo mistake and some annotations mistake

[Jani Nikula]

On Fri, 13 Mar 2015, Rob Clark  wrote:
> hopefully someone else in China can suggest a good way of sending
> patches (I have no clue there)

An alternative is to subscribe with all email addresses you may be
sending patches (or messages) from, but disabling list mail delivery for
all but one address in the dri-devel list management interface.

You can have git format-patch/send-email add a From: line at the
beginning of the patch (separate from mail headers) matching the
Signed-off-by. I forget the config for this, but it's there somewhere.


HTH,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm_crtc.c: fix some typo mistake and some annotations mistake

[John Hunter]

Fine, I will try to catch up.
Thanks anyway.

Have a nice day,
John

On Fri, Mar 13, 2015 at 11:07 AM, Rob Clark  wrote:

> On Thu, Mar 12, 2015 at 10:53 PM, John Hunter  wrote:
> > Got it, maybe I should work on the drm-next or latest linux master.
> >
> > I am working on the drm git repo below for now as Daniel Vetter told me
> > git://people.freedesktop.org/~airlied/linux
> > I am quite confused now 'cause there are a bounch of git repo, I really
> > do not know which one should I git clone.
> >
>
> Hmm, I suspect airlied hasn't updated his master branch in a while,
> which is probably causing confusing..  using his drm-next branch or
> linus master would be better..  in general, drm-next for latest and
> greatest drm is probably best, but right at the moment there is
> probably not much difference from linus master.
>
> I usually end up 'git remote add'ing a bunch of different trees to
> track both what has already landed in linus's master branch, and also
> what is coming in drm-next (and various different arm trees related to
> other stuff I work on)..  but for drm stuff, Dave's drm-next branch is
> a safe bet.
>
> BR,
> -R
>
>
> >
> > On Fri, Mar 13, 2015 at 10:33 AM, Rob Clark  wrote:
> >>
> >> On Thu, Mar 12, 2015 at 4:02 AM, John Hunter 
> >> wrote:
> >> > From: John Hunter 
> >> >
> >> > IMHO, some annotations were copypaste from somewhere else, it is
> >> > obviously not rightly modified. Hope I am right with that.
> >> > ---
> >> >  drivers/gpu/drm/drm_crtc.c | 115
> >> > ++---
> >> >  1 file changed, 56 insertions(+), 59 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> >> > index f2d667b..7f771e9 100644
> >> > --- a/drivers/gpu/drm/drm_crtc.c
> >> > +++ b/drivers/gpu/drm/drm_crtc.c
> >> > @@ -205,12 +205,12 @@ char *drm_get_connector_status_name(enum
> >> > drm_connector_status status)
> >> >  /**
> >> >   * drm_mode_object_get - allocate a new identifier
> >> >   * @dev: DRM device
> >> > - * @ptr: object pointer, used to generate unique ID
> >> > - * @type: object type
> >> > + * @obj: object pointer, used to generate unique ID
> >> > + * @obj_type: object type
> >> >   *
> >> >   * LOCKING:
> >> >   *
> >> > - * Create a unique identifier based on @ptr in @dev's identifier
> space.
> >> > Used
> >> > + * Create a unique identifier based on @obj in @dev's identifier
> space.
> >> > Used
> >> >   * for tracking modes, CRTCs and connectors.
> >>
> >> so, I don't suppose you can rebase against a newer upstream kernel?
> >>
> >> From a quick look, it seems like the arg name errors where corrected
> >> in 065a50ed3ef75cb265e12e3e1b615db0835150bc while the description
> >> bodies fixes from your patch are still applicable.  In the current
> >> form, the patch does not apply against drm-next (or latest linux
> >> master), but most of it is still applicable and would be a very
> >> welcome improvement.
> >>
> >> Thanks :-)
> >>
> >> BR,
> >> -R
> >>
>



-- 
Best regards
Junwang Zhao
Microprocessor Research and Develop Center
Department of Computer Science 
Peking University
Beijing, 100871, PRC
-- next part --
An HTML attachment was scrubbed...
URL: 

[PATCH] drm_crtc.c: fix some typo mistake and some annotations mistake

[John Hunter]

Got it, maybe I should work on the drm-next or latest linux master.

I am working on the drm git repo below for now as Daniel Vetter told me
git://people.freedesktop.org/~airlied/linux
I am quite confused now 'cause there are a bounch of git repo, I really
do not know which one should I git clone.


On Fri, Mar 13, 2015 at 10:33 AM, Rob Clark  wrote:

> On Thu, Mar 12, 2015 at 4:02 AM, John Hunter 
> wrote:
> > From: John Hunter 
> >
> > IMHO, some annotations were copypaste from somewhere else, it is
> > obviously not rightly modified. Hope I am right with that.
> > ---
> >  drivers/gpu/drm/drm_crtc.c | 115
> ++---
> >  1 file changed, 56 insertions(+), 59 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index f2d667b..7f771e9 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -205,12 +205,12 @@ char *drm_get_connector_status_name(enum
> drm_connector_status status)
> >  /**
> >   * drm_mode_object_get - allocate a new identifier
> >   * @dev: DRM device
> > - * @ptr: object pointer, used to generate unique ID
> > - * @type: object type
> > + * @obj: object pointer, used to generate unique ID
> > + * @obj_type: object type
> >   *
> >   * LOCKING:
> >   *
> > - * Create a unique identifier based on @ptr in @dev's identifier
> space.  Used
> > + * Create a unique identifier based on @obj in @dev's identifier
> space.  Used
> >   * for tracking modes, CRTCs and connectors.
>
> so, I don't suppose you can rebase against a newer upstream kernel?
>
> From a quick look, it seems like the arg name errors where corrected
> in 065a50ed3ef75cb265e12e3e1b615db0835150bc while the description
> bodies fixes from your patch are still applicable.  In the current
> form, the patch does not apply against drm-next (or latest linux
> master), but most of it is still applicable and would be a very
> welcome improvement.
>
> Thanks :-)
>
> BR,
> -R
>
>
> >   *
> >   * RETURNS:
> > @@ -245,12 +245,12 @@ again:
> >  /**
> >   * drm_mode_object_put - free an identifer
> >   * @dev: DRM device
> > - * @id: ID to free
> > + * @object: object to free
> >   *
> >   * LOCKING:
> >   * Caller must hold DRM mode_config lock.
> >   *
> > - * Free @id from @dev's unique identifier pool.
> > + * Free @object from @dev's unique identifier pool.
> >   */
> >  static void drm_mode_object_put(struct drm_device *dev,
> > struct drm_mode_object *object)
> > @@ -353,10 +353,11 @@ EXPORT_SYMBOL(drm_framebuffer_reference);
> >  void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
> >  {
> > struct drm_device *dev = fb->dev;
> > +
> > /*
> >  * This could be moved to drm_framebuffer_remove(), but for
> >  * debugging is nice to keep around the list of fb's that are
> > -* no longer associated w/ a drm_file but are not unreferenced
> > +* no longer associated with a drm_file but are not unreferenced
> >  * yet.  (i915 and omapdrm have debugfs files which will show
> >  * this.)
> >  */
> > @@ -519,7 +520,7 @@ EXPORT_SYMBOL(drm_mode_remove);
> >   * @dev: DRM device
> >   * @connector: the connector to init
> >   * @funcs: callbacks for this connector
> > - * @name: user visible name of the connector
> > + * @connector_type: type of the connector
> >   *
> >   * LOCKING:
> >   * Takes mode config lock.
> > @@ -683,7 +684,8 @@ int drm_plane_init(struct drm_device *dev, struct
> drm_plane *plane,
> > plane->format_count = format_count;
> > plane->possible_crtcs = possible_crtcs;
> >
> > -   /* private planes are not exposed to userspace, but depending on
> > +   /*
> > +* private planes are not exposed to userspace, but depending on
> >  * display hardware, might be convenient to allow sharing
> programming
> >  * for the scanout engine with the crtc implementation.
> >  */
> > @@ -1188,10 +1190,9 @@ static int drm_crtc_convert_umode(struct
> drm_display_mode *out,
> >
> >  /**
> >   * drm_mode_getresources - get graphics configuration
> > - * @inode: inode from the ioctl
> > - * @filp: file * from the ioctl
> > - * @cmd: cmd from ioctl
> > - * @arg: arg from ioctl
> > + * @dev: DRM device
> > + * @data: ioctl data
> > + * @file_priv: DRM file info
> >   *
> >   * LOCKING:
> >   * Takes mode config lock.
> > @@ -1249,7 +1250,6 @@ int drm_mode_getresources(struct drm_device *dev,
> void *data,
> > list_for_each(lh, >mode_config.encoder_list)
> > encoder_count++;
> > } else {
> > -
> > crtc_count = mode_group->num_crtcs;
> > connector_count = mode_group->num_connectors;
> > encoder_count = mode_group->num_encoders;
> > @@ -1328,7 +1328,6 @@ int drm_mode_getresources(struct drm_device *dev,
> void *data,
> > }
> > 

[PATCH] drm_crtc.c: fix some typo mistake and some annotations mistake

[John Hunter]

Hi Rob,

On Thu, Mar 12, 2015 at 10:34 PM, Rob Clark  wrote:

> On Thu, Mar 12, 2015 at 10:15 AM, John Hunter  wrote:
> > Hi,
> > I really don't  whether I am doing things on right workflow of dri-devel.
> > I am new to this community and I want to help.
> > Could anybody spare some time to tell me the right way .
> > Thanks.
>
> Hi John,
>
> I don't actually see the original patch, just your reply to it..  if
> you didn't already, could you git-send-email it to dri-devel?
>
> I searched the archieve of the maillinglist, I think this may be the
original patch
http://lists.freedesktop.org/archives/dri-devel/2015-March/079198.html


> (If you did, but were not subscribed, perhaps it is still stuck in
> list moderation queue?)
>
> I subscribed with the email : zhjwpku at gmail.com, but when git-send-email
to dri-devel,
I used another not subscribed email: zhaojunwang at pku.edu.cn to git-send the
patch ,
because I got trouble when I use the gmail stmp server in git-send-mail
I can only use the gmail under the help of chrome and goagent, cause I am
in China :-(

BR,
John


> BR,
> -R
>
>
> > John
> >
> > On Thu, Mar 12, 2015 at 4:02 PM, John Hunter 
> wrote:
> >>
> >> From: John Hunter 
> >>
> >> IMHO, some annotations were copypaste from somewhere else, it is
> >> obviously not rightly modified. Hope I am right with that.
> >> ---
> >>  drivers/gpu/drm/drm_crtc.c | 115
> >> ++---
> >>  1 file changed, 56 insertions(+), 59 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> >> index f2d667b..7f771e9 100644
> >> --- a/drivers/gpu/drm/drm_crtc.c
> >> +++ b/drivers/gpu/drm/drm_crtc.c
> >> @@ -205,12 +205,12 @@ char *drm_get_connector_status_name(enum
> >> drm_connector_status status)
> >>  /**
> >>   * drm_mode_object_get - allocate a new identifier
> >>   * @dev: DRM device
> >> - * @ptr: object pointer, used to generate unique ID
> >> - * @type: object type
> >> + * @obj: object pointer, used to generate unique ID
> >> + * @obj_type: object type
> >>   *
> >>   * LOCKING:
> >>   *
> >> - * Create a unique identifier based on @ptr in @dev's identifier space.
> >> Used
> >> + * Create a unique identifier based on @obj in @dev's identifier space.
> >> Used
> >>   * for tracking modes, CRTCs and connectors.
> >>   *
> >>   * RETURNS:
> >> @@ -245,12 +245,12 @@ again:
> >>  /**
> >>   * drm_mode_object_put - free an identifer
> >>   * @dev: DRM device
> >> - * @id: ID to free
> >> + * @object: object to free
> >>   *
> >>   * LOCKING:
> >>   * Caller must hold DRM mode_config lock.
> >>   *
> >> - * Free @id from @dev's unique identifier pool.
> >> + * Free @object from @dev's unique identifier pool.
> >>   */
> >>  static void drm_mode_object_put(struct drm_device *dev,
> >> struct drm_mode_object *object)
> >> @@ -353,10 +353,11 @@ EXPORT_SYMBOL(drm_framebuffer_reference);
> >>  void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
> >>  {
> >> struct drm_device *dev = fb->dev;
> >> +
> >> /*
> >>  * This could be moved to drm_framebuffer_remove(), but for
> >>  * debugging is nice to keep around the list of fb's that are
> >> -* no longer associated w/ a drm_file but are not unreferenced
> >> +* no longer associated with a drm_file but are not unreferenced
> >>  * yet.  (i915 and omapdrm have debugfs files which will show
> >>  * this.)
> >>  */
> >> @@ -519,7 +520,7 @@ EXPORT_SYMBOL(drm_mode_remove);
> >>   * @dev: DRM device
> >>   * @connector: the connector to init
> >>   * @funcs: callbacks for this connector
> >> - * @name: user visible name of the connector
> >> + * @connector_type: type of the connector
> >>   *
> >>   * LOCKING:
> >>   * Takes mode config lock.
> >> @@ -683,7 +684,8 @@ int drm_plane_init(struct drm_device *dev, struct
> >> drm_plane *plane,
> >> plane->format_count = format_count;
> >> plane->possible_crtcs = possible_crtcs;
> >>
> >> -   /* private planes are not exposed to userspace, but depending on
> >> +   /*
> >> +* private planes are not exposed to userspace, but depending on
> >>  * display hardware, might be convenient to allow sharing
> >> programming
> >>  * for the scanout engine with the crtc implementation.
> >>  */
> >> @@ -1188,10 +1190,9 @@ static int drm_crtc_convert_umode(struct
> >> drm_display_mode *out,
> >>
> >>  /**
> >>   * drm_mode_getresources - get graphics configuration
> >> - * @inode: inode from the ioctl
> >> - * @filp: file * from the ioctl
> >> - * @cmd: cmd from ioctl
> >> - * @arg: arg from ioctl
> >> + * @dev: DRM device
> >> + * @data: ioctl data
> >> + * @file_priv: DRM file info
> >>   *
> >>   * LOCKING:
> >>   * Takes mode config lock.
> >> @@ -1249,7 +1250,6 @@ int drm_mode_getresources(struct drm_device *dev,
> >> void *data,
> >> list_for_each(lh, >mode_config.encoder_list)
> >> 

[PATCH] drm_crtc.c: fix some typo mistake and some annotations mistake

[Rob Clark]

cool.. something along the lines of:

 git pull --rebase  drm-next

and then

 git mergetool

should do the job

Thanks :-)

BR,
-R

On Thu, Mar 12, 2015 at 11:31 PM, John Hunter  wrote:
> Fine, I will try to catch up.
> Thanks anyway.
>
> Have a nice day,
> John
>
> On Fri, Mar 13, 2015 at 11:07 AM, Rob Clark  wrote:
>>
>> On Thu, Mar 12, 2015 at 10:53 PM, John Hunter  wrote:
>> > Got it, maybe I should work on the drm-next or latest linux master.
>> >
>> > I am working on the drm git repo below for now as Daniel Vetter told me
>> > git://people.freedesktop.org/~airlied/linux
>> > I am quite confused now 'cause there are a bounch of git repo, I really
>> > do not know which one should I git clone.
>> >
>>
>> Hmm, I suspect airlied hasn't updated his master branch in a while,
>> which is probably causing confusing..  using his drm-next branch or
>> linus master would be better..  in general, drm-next for latest and
>> greatest drm is probably best, but right at the moment there is
>> probably not much difference from linus master.
>>
>> I usually end up 'git remote add'ing a bunch of different trees to
>> track both what has already landed in linus's master branch, and also
>> what is coming in drm-next (and various different arm trees related to
>> other stuff I work on)..  but for drm stuff, Dave's drm-next branch is
>> a safe bet.
>>
>> BR,
>> -R
>>
>>
>> >
>> > On Fri, Mar 13, 2015 at 10:33 AM, Rob Clark  wrote:
>> >>
>> >> On Thu, Mar 12, 2015 at 4:02 AM, John Hunter 
>> >> wrote:
>> >> > From: John Hunter 
>> >> >
>> >> > IMHO, some annotations were copypaste from somewhere else, it is
>> >> > obviously not rightly modified. Hope I am right with that.
>> >> > ---
>> >> >  drivers/gpu/drm/drm_crtc.c | 115
>> >> > ++---
>> >> >  1 file changed, 56 insertions(+), 59 deletions(-)
>> >> >
>> >> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> >> > index f2d667b..7f771e9 100644
>> >> > --- a/drivers/gpu/drm/drm_crtc.c
>> >> > +++ b/drivers/gpu/drm/drm_crtc.c
>> >> > @@ -205,12 +205,12 @@ char *drm_get_connector_status_name(enum
>> >> > drm_connector_status status)
>> >> >  /**
>> >> >   * drm_mode_object_get - allocate a new identifier
>> >> >   * @dev: DRM device
>> >> > - * @ptr: object pointer, used to generate unique ID
>> >> > - * @type: object type
>> >> > + * @obj: object pointer, used to generate unique ID
>> >> > + * @obj_type: object type
>> >> >   *
>> >> >   * LOCKING:
>> >> >   *
>> >> > - * Create a unique identifier based on @ptr in @dev's identifier
>> >> > space.
>> >> > Used
>> >> > + * Create a unique identifier based on @obj in @dev's identifier
>> >> > space.
>> >> > Used
>> >> >   * for tracking modes, CRTCs and connectors.
>> >>
>> >> so, I don't suppose you can rebase against a newer upstream kernel?
>> >>
>> >> From a quick look, it seems like the arg name errors where corrected
>> >> in 065a50ed3ef75cb265e12e3e1b615db0835150bc while the description
>> >> bodies fixes from your patch are still applicable.  In the current
>> >> form, the patch does not apply against drm-next (or latest linux
>> >> master), but most of it is still applicable and would be a very
>> >> welcome improvement.
>> >>
>> >> Thanks :-)
>> >>
>> >> BR,
>> >> -R
>> >>
>
>
>
>
> --
> Best regards
> Junwang Zhao
> Microprocessor Research and Develop Center
> Department of Computer Science 
> Peking University
> Beijing, 100871, PRC

[PATCH] drm_crtc.c: fix some typo mistake and some annotations mistake

[Rob Clark]

On Thu, Mar 12, 2015 at 10:53 PM, John Hunter  wrote:
> Got it, maybe I should work on the drm-next or latest linux master.
>
> I am working on the drm git repo below for now as Daniel Vetter told me
> git://people.freedesktop.org/~airlied/linux
> I am quite confused now 'cause there are a bounch of git repo, I really
> do not know which one should I git clone.
>

Hmm, I suspect airlied hasn't updated his master branch in a while,
which is probably causing confusing..  using his drm-next branch or
linus master would be better..  in general, drm-next for latest and
greatest drm is probably best, but right at the moment there is
probably not much difference from linus master.

I usually end up 'git remote add'ing a bunch of different trees to
track both what has already landed in linus's master branch, and also
what is coming in drm-next (and various different arm trees related to
other stuff I work on)..  but for drm stuff, Dave's drm-next branch is
a safe bet.

BR,
-R


>
> On Fri, Mar 13, 2015 at 10:33 AM, Rob Clark  wrote:
>>
>> On Thu, Mar 12, 2015 at 4:02 AM, John Hunter 
>> wrote:
>> > From: John Hunter 
>> >
>> > IMHO, some annotations were copypaste from somewhere else, it is
>> > obviously not rightly modified. Hope I am right with that.
>> > ---
>> >  drivers/gpu/drm/drm_crtc.c | 115
>> > ++---
>> >  1 file changed, 56 insertions(+), 59 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> > index f2d667b..7f771e9 100644
>> > --- a/drivers/gpu/drm/drm_crtc.c
>> > +++ b/drivers/gpu/drm/drm_crtc.c
>> > @@ -205,12 +205,12 @@ char *drm_get_connector_status_name(enum
>> > drm_connector_status status)
>> >  /**
>> >   * drm_mode_object_get - allocate a new identifier
>> >   * @dev: DRM device
>> > - * @ptr: object pointer, used to generate unique ID
>> > - * @type: object type
>> > + * @obj: object pointer, used to generate unique ID
>> > + * @obj_type: object type
>> >   *
>> >   * LOCKING:
>> >   *
>> > - * Create a unique identifier based on @ptr in @dev's identifier space.
>> > Used
>> > + * Create a unique identifier based on @obj in @dev's identifier space.
>> > Used
>> >   * for tracking modes, CRTCs and connectors.
>>
>> so, I don't suppose you can rebase against a newer upstream kernel?
>>
>> From a quick look, it seems like the arg name errors where corrected
>> in 065a50ed3ef75cb265e12e3e1b615db0835150bc while the description
>> bodies fixes from your patch are still applicable.  In the current
>> form, the patch does not apply against drm-next (or latest linux
>> master), but most of it is still applicable and would be a very
>> welcome improvement.
>>
>> Thanks :-)
>>
>> BR,
>> -R
>>

[PATCH] drm_crtc.c: fix some typo mistake and some annotations mistake

[Rob Clark]

On Thu, Mar 12, 2015 at 4:02 AM, John Hunter  wrote:
> From: John Hunter 
>
> IMHO, some annotations were copypaste from somewhere else, it is
> obviously not rightly modified. Hope I am right with that.
> ---
>  drivers/gpu/drm/drm_crtc.c | 115 
> ++---
>  1 file changed, 56 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f2d667b..7f771e9 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -205,12 +205,12 @@ char *drm_get_connector_status_name(enum 
> drm_connector_status status)
>  /**
>   * drm_mode_object_get - allocate a new identifier
>   * @dev: DRM device
> - * @ptr: object pointer, used to generate unique ID
> - * @type: object type
> + * @obj: object pointer, used to generate unique ID
> + * @obj_type: object type
>   *
>   * LOCKING:
>   *
> - * Create a unique identifier based on @ptr in @dev's identifier space.  Used
> + * Create a unique identifier based on @obj in @dev's identifier space.  Used
>   * for tracking modes, CRTCs and connectors.

so, I don't suppose you can rebase against a newer upstream kernel?

>From a quick look, it seems like the arg name errors where corrected
in 065a50ed3ef75cb265e12e3e1b615db0835150bc while the description
bodies fixes from your patch are still applicable.  In the current
form, the patch does not apply against drm-next (or latest linux
master), but most of it is still applicable and would be a very
welcome improvement.

Thanks :-)

BR,
-R


>   *
>   * RETURNS:
> @@ -245,12 +245,12 @@ again:
>  /**
>   * drm_mode_object_put - free an identifer
>   * @dev: DRM device
> - * @id: ID to free
> + * @object: object to free
>   *
>   * LOCKING:
>   * Caller must hold DRM mode_config lock.
>   *
> - * Free @id from @dev's unique identifier pool.
> + * Free @object from @dev's unique identifier pool.
>   */
>  static void drm_mode_object_put(struct drm_device *dev,
> struct drm_mode_object *object)
> @@ -353,10 +353,11 @@ EXPORT_SYMBOL(drm_framebuffer_reference);
>  void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
>  {
> struct drm_device *dev = fb->dev;
> +
> /*
>  * This could be moved to drm_framebuffer_remove(), but for
>  * debugging is nice to keep around the list of fb's that are
> -* no longer associated w/ a drm_file but are not unreferenced
> +* no longer associated with a drm_file but are not unreferenced
>  * yet.  (i915 and omapdrm have debugfs files which will show
>  * this.)
>  */
> @@ -519,7 +520,7 @@ EXPORT_SYMBOL(drm_mode_remove);
>   * @dev: DRM device
>   * @connector: the connector to init
>   * @funcs: callbacks for this connector
> - * @name: user visible name of the connector
> + * @connector_type: type of the connector
>   *
>   * LOCKING:
>   * Takes mode config lock.
> @@ -683,7 +684,8 @@ int drm_plane_init(struct drm_device *dev, struct 
> drm_plane *plane,
> plane->format_count = format_count;
> plane->possible_crtcs = possible_crtcs;
>
> -   /* private planes are not exposed to userspace, but depending on
> +   /*
> +* private planes are not exposed to userspace, but depending on
>  * display hardware, might be convenient to allow sharing programming
>  * for the scanout engine with the crtc implementation.
>  */
> @@ -1188,10 +1190,9 @@ static int drm_crtc_convert_umode(struct 
> drm_display_mode *out,
>
>  /**
>   * drm_mode_getresources - get graphics configuration
> - * @inode: inode from the ioctl
> - * @filp: file * from the ioctl
> - * @cmd: cmd from ioctl
> - * @arg: arg from ioctl
> + * @dev: DRM device
> + * @data: ioctl data
> + * @file_priv: DRM file info
>   *
>   * LOCKING:
>   * Takes mode config lock.
> @@ -1249,7 +1250,6 @@ int drm_mode_getresources(struct drm_device *dev, void 
> *data,
> list_for_each(lh, >mode_config.encoder_list)
> encoder_count++;
> } else {
> -
> crtc_count = mode_group->num_crtcs;
> connector_count = mode_group->num_connectors;
> encoder_count = mode_group->num_encoders;
> @@ -1328,7 +1328,6 @@ int drm_mode_getresources(struct drm_device *dev, void 
> *data,
> }
> copied++;
> }
> -
> }
> }
> card_res->count_encoders = encoder_count;
> @@ -1376,10 +1375,9 @@ out:
>
>  /**
>   * drm_mode_getcrtc - get CRTC configuration
> - * @inode: inode from the ioctl
> - * @filp: file * from the ioctl
> - * @cmd: cmd from ioctl
> - * @arg: arg from ioctl
> + * @dev: DRM device
> + * @data: ioctl data
> + * @file_priv: DRM file info
>   *
>   * LOCKING:
>   * Takes mode config lock.
> @@ -1421,10 +1419,8 @@ int drm_mode_getcrtc(struct drm_device *dev,
> crtc_resp->fb_id = 0;
>
>  

[PATCH] drm_crtc.c: fix some typo mistake and some annotations mistake

[John Hunter]

Hi,
I really don't  whether I am doing things on right workflow of dri-devel.
I am new to this community and I want to help.
Could anybody spare some time to tell me the right way .
Thanks.

John

On Thu, Mar 12, 2015 at 4:02 PM, John Hunter  wrote:

> From: John Hunter 
>
> IMHO, some annotations were copypaste from somewhere else, it is
> obviously not rightly modified. Hope I am right with that.
> ---
>  drivers/gpu/drm/drm_crtc.c | 115
> ++---
>  1 file changed, 56 insertions(+), 59 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f2d667b..7f771e9 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -205,12 +205,12 @@ char *drm_get_connector_status_name(enum
> drm_connector_status status)
>  /**
>   * drm_mode_object_get - allocate a new identifier
>   * @dev: DRM device
> - * @ptr: object pointer, used to generate unique ID
> - * @type: object type
> + * @obj: object pointer, used to generate unique ID
> + * @obj_type: object type
>   *
>   * LOCKING:
>   *
> - * Create a unique identifier based on @ptr in @dev's identifier space.
> Used
> + * Create a unique identifier based on @obj in @dev's identifier space.
> Used
>   * for tracking modes, CRTCs and connectors.
>   *
>   * RETURNS:
> @@ -245,12 +245,12 @@ again:
>  /**
>   * drm_mode_object_put - free an identifer
>   * @dev: DRM device
> - * @id: ID to free
> + * @object: object to free
>   *
>   * LOCKING:
>   * Caller must hold DRM mode_config lock.
>   *
> - * Free @id from @dev's unique identifier pool.
> + * Free @object from @dev's unique identifier pool.
>   */
>  static void drm_mode_object_put(struct drm_device *dev,
> struct drm_mode_object *object)
> @@ -353,10 +353,11 @@ EXPORT_SYMBOL(drm_framebuffer_reference);
>  void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
>  {
> struct drm_device *dev = fb->dev;
> +
> /*
>  * This could be moved to drm_framebuffer_remove(), but for
>  * debugging is nice to keep around the list of fb's that are
> -* no longer associated w/ a drm_file but are not unreferenced
> +* no longer associated with a drm_file but are not unreferenced
>  * yet.  (i915 and omapdrm have debugfs files which will show
>  * this.)
>  */
> @@ -519,7 +520,7 @@ EXPORT_SYMBOL(drm_mode_remove);
>   * @dev: DRM device
>   * @connector: the connector to init
>   * @funcs: callbacks for this connector
> - * @name: user visible name of the connector
> + * @connector_type: type of the connector
>   *
>   * LOCKING:
>   * Takes mode config lock.
> @@ -683,7 +684,8 @@ int drm_plane_init(struct drm_device *dev, struct
> drm_plane *plane,
> plane->format_count = format_count;
> plane->possible_crtcs = possible_crtcs;
>
> -   /* private planes are not exposed to userspace, but depending on
> +   /*
> +* private planes are not exposed to userspace, but depending on
>  * display hardware, might be convenient to allow sharing
> programming
>  * for the scanout engine with the crtc implementation.
>  */
> @@ -1188,10 +1190,9 @@ static int drm_crtc_convert_umode(struct
> drm_display_mode *out,
>
>  /**
>   * drm_mode_getresources - get graphics configuration
> - * @inode: inode from the ioctl
> - * @filp: file * from the ioctl
> - * @cmd: cmd from ioctl
> - * @arg: arg from ioctl
> + * @dev: DRM device
> + * @data: ioctl data
> + * @file_priv: DRM file info
>   *
>   * LOCKING:
>   * Takes mode config lock.
> @@ -1249,7 +1250,6 @@ int drm_mode_getresources(struct drm_device *dev,
> void *data,
> list_for_each(lh, >mode_config.encoder_list)
> encoder_count++;
> } else {
> -
> crtc_count = mode_group->num_crtcs;
> connector_count = mode_group->num_connectors;
> encoder_count = mode_group->num_encoders;
> @@ -1328,7 +1328,6 @@ int drm_mode_getresources(struct drm_device *dev,
> void *data,
> }
> copied++;
> }
> -
> }
> }
> card_res->count_encoders = encoder_count;
> @@ -1376,10 +1375,9 @@ out:
>
>  /**
>   * drm_mode_getcrtc - get CRTC configuration
> - * @inode: inode from the ioctl
> - * @filp: file * from the ioctl
> - * @cmd: cmd from ioctl
> - * @arg: arg from ioctl
> + * @dev: DRM device
> + * @data: ioctl data
> + * @file_priv: DRM file info
>   *
>   * LOCKING:
>   * Takes mode config lock.
> @@ -1421,10 +1419,8 @@ int drm_mode_getcrtc(struct drm_device *dev,
> crtc_resp->fb_id = 0;
>
> if (crtc->enabled) {
> -
> drm_crtc_convert_to_umode(_resp->mode, >mode);
> crtc_resp->mode_valid = 1;
> -
> } else {
> crtc_resp->mode_valid = 0;
> }
> @@ -1436,10 +1432,9 @@ out:

[PATCH] drm_crtc.c: fix some typo mistake and some annotations mistake

[Rob Clark]

On Thu, Mar 12, 2015 at 8:49 PM, John Hunter  wrote:
> Hi Rob,
>
> On Thu, Mar 12, 2015 at 10:34 PM, Rob Clark  wrote:
>>
>> On Thu, Mar 12, 2015 at 10:15 AM, John Hunter  wrote:
>> > Hi,
>> > I really don't  whether I am doing things on right workflow of
>> > dri-devel.
>> > I am new to this community and I want to help.
>> > Could anybody spare some time to tell me the right way .
>> > Thanks.
>>
>> Hi John,
>>
>> I don't actually see the original patch, just your reply to it..  if
>> you didn't already, could you git-send-email it to dri-devel?
>>
> I searched the archieve of the maillinglist, I think this may be the
> original patch
> http://lists.freedesktop.org/archives/dri-devel/2015-March/079198.html
>
>>
>> (If you did, but were not subscribed, perhaps it is still stuck in
>> list moderation queue?)
>>
> I subscribed with the email : zhjwpku at gmail.com, but when git-send-email to
> dri-devel,
> I used another not subscribed email: zhaojunwang at pku.edu.cn to git-send the
> patch ,
> because I got trouble when I use the gmail stmp server in git-send-mail
> I can only use the gmail under the help of chrome and goagent, cause I am in
> China :-(

I see your patch now, so I guess whoever has list admin privileges
stepped in and moderated it.. it is one my TODO list to review.. and
thanks for the patch, btw ;-)

hopefully someone else in China can suggest a good way of sending
patches (I have no clue there)

BR,
-R


>
> BR,
> John
>
>>
>> BR,
>> -R
>>
>>
>> > John
>> >
>> > On Thu, Mar 12, 2015 at 4:02 PM, John Hunter 
>> > wrote:
>> >>
>> >> From: John Hunter 
>> >>
>> >> IMHO, some annotations were copypaste from somewhere else, it is
>> >> obviously not rightly modified. Hope I am right with that.
>> >> ---
>> >>  drivers/gpu/drm/drm_crtc.c | 115
>> >> ++---
>> >>  1 file changed, 56 insertions(+), 59 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> >> index f2d667b..7f771e9 100644
>> >> --- a/drivers/gpu/drm/drm_crtc.c
>> >> +++ b/drivers/gpu/drm/drm_crtc.c
>> >> @@ -205,12 +205,12 @@ char *drm_get_connector_status_name(enum
>> >> drm_connector_status status)
>> >>  /**
>> >>   * drm_mode_object_get - allocate a new identifier
>> >>   * @dev: DRM device
>> >> - * @ptr: object pointer, used to generate unique ID
>> >> - * @type: object type
>> >> + * @obj: object pointer, used to generate unique ID
>> >> + * @obj_type: object type
>> >>   *
>> >>   * LOCKING:
>> >>   *
>> >> - * Create a unique identifier based on @ptr in @dev's identifier
>> >> space.
>> >> Used
>> >> + * Create a unique identifier based on @obj in @dev's identifier
>> >> space.
>> >> Used
>> >>   * for tracking modes, CRTCs and connectors.
>> >>   *
>> >>   * RETURNS:
>> >> @@ -245,12 +245,12 @@ again:
>> >>  /**
>> >>   * drm_mode_object_put - free an identifer
>> >>   * @dev: DRM device
>> >> - * @id: ID to free
>> >> + * @object: object to free
>> >>   *
>> >>   * LOCKING:
>> >>   * Caller must hold DRM mode_config lock.
>> >>   *
>> >> - * Free @id from @dev's unique identifier pool.
>> >> + * Free @object from @dev's unique identifier pool.
>> >>   */
>> >>  static void drm_mode_object_put(struct drm_device *dev,
>> >> struct drm_mode_object *object)
>> >> @@ -353,10 +353,11 @@ EXPORT_SYMBOL(drm_framebuffer_reference);
>> >>  void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
>> >>  {
>> >> struct drm_device *dev = fb->dev;
>> >> +
>> >> /*
>> >>  * This could be moved to drm_framebuffer_remove(), but for
>> >>  * debugging is nice to keep around the list of fb's that are
>> >> -* no longer associated w/ a drm_file but are not unreferenced
>> >> +* no longer associated with a drm_file but are not
>> >> unreferenced
>> >>  * yet.  (i915 and omapdrm have debugfs files which will show
>> >>  * this.)
>> >>  */
>> >> @@ -519,7 +520,7 @@ EXPORT_SYMBOL(drm_mode_remove);
>> >>   * @dev: DRM device
>> >>   * @connector: the connector to init
>> >>   * @funcs: callbacks for this connector
>> >> - * @name: user visible name of the connector
>> >> + * @connector_type: type of the connector
>> >>   *
>> >>   * LOCKING:
>> >>   * Takes mode config lock.
>> >> @@ -683,7 +684,8 @@ int drm_plane_init(struct drm_device *dev, struct
>> >> drm_plane *plane,
>> >> plane->format_count = format_count;
>> >> plane->possible_crtcs = possible_crtcs;
>> >>
>> >> -   /* private planes are not exposed to userspace, but depending
>> >> on
>> >> +   /*
>> >> +* private planes are not exposed to userspace, but depending
>> >> on
>> >>  * display hardware, might be convenient to allow sharing
>> >> programming
>> >>  * for the scanout engine with the crtc implementation.
>> >>  */
>> >> @@ -1188,10 +1190,9 @@ static int drm_crtc_convert_umode(struct
>> >> drm_display_mode *out,
>> >>
>> >>  /**
>> >>   

[PATCH] drm_crtc.c: fix some typo mistake and some annotations mistake

[John Hunter]

From: John Hunter 

IMHO, some annotations were copypaste from somewhere else, it is
obviously not rightly modified. Hope I am right with that.
---
 drivers/gpu/drm/drm_crtc.c | 115 ++---
 1 file changed, 56 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f2d667b..7f771e9 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -205,12 +205,12 @@ char *drm_get_connector_status_name(enum 
drm_connector_status status)
 /**
  * drm_mode_object_get - allocate a new identifier
  * @dev: DRM device
- * @ptr: object pointer, used to generate unique ID
- * @type: object type
+ * @obj: object pointer, used to generate unique ID
+ * @obj_type: object type
  *
  * LOCKING:
  *
- * Create a unique identifier based on @ptr in @dev's identifier space.  Used
+ * Create a unique identifier based on @obj in @dev's identifier space.  Used
  * for tracking modes, CRTCs and connectors.
  *
  * RETURNS:
@@ -245,12 +245,12 @@ again:
 /**
  * drm_mode_object_put - free an identifer
  * @dev: DRM device
- * @id: ID to free
+ * @object: object to free
  *
  * LOCKING:
  * Caller must hold DRM mode_config lock.
  *
- * Free @id from @dev's unique identifier pool.
+ * Free @object from @dev's unique identifier pool.
  */
 static void drm_mode_object_put(struct drm_device *dev,
struct drm_mode_object *object)
@@ -353,10 +353,11 @@ EXPORT_SYMBOL(drm_framebuffer_reference);
 void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
 {
struct drm_device *dev = fb->dev;
+
/*
 * This could be moved to drm_framebuffer_remove(), but for
 * debugging is nice to keep around the list of fb's that are
-* no longer associated w/ a drm_file but are not unreferenced
+* no longer associated with a drm_file but are not unreferenced
 * yet.  (i915 and omapdrm have debugfs files which will show
 * this.)
 */
@@ -519,7 +520,7 @@ EXPORT_SYMBOL(drm_mode_remove);
  * @dev: DRM device
  * @connector: the connector to init
  * @funcs: callbacks for this connector
- * @name: user visible name of the connector
+ * @connector_type: type of the connector
  *
  * LOCKING:
  * Takes mode config lock.
@@ -683,7 +684,8 @@ int drm_plane_init(struct drm_device *dev, struct drm_plane 
*plane,
plane->format_count = format_count;
plane->possible_crtcs = possible_crtcs;

-   /* private planes are not exposed to userspace, but depending on
+   /*
+* private planes are not exposed to userspace, but depending on
 * display hardware, might be convenient to allow sharing programming
 * for the scanout engine with the crtc implementation.
 */
@@ -1188,10 +1190,9 @@ static int drm_crtc_convert_umode(struct 
drm_display_mode *out,

 /**
  * drm_mode_getresources - get graphics configuration
- * @inode: inode from the ioctl
- * @filp: file * from the ioctl
- * @cmd: cmd from ioctl
- * @arg: arg from ioctl
+ * @dev: DRM device
+ * @data: ioctl data
+ * @file_priv: DRM file info
  *
  * LOCKING:
  * Takes mode config lock.
@@ -1249,7 +1250,6 @@ int drm_mode_getresources(struct drm_device *dev, void 
*data,
list_for_each(lh, >mode_config.encoder_list)
encoder_count++;
} else {
-
crtc_count = mode_group->num_crtcs;
connector_count = mode_group->num_connectors;
encoder_count = mode_group->num_encoders;
@@ -1328,7 +1328,6 @@ int drm_mode_getresources(struct drm_device *dev, void 
*data,
}
copied++;
}
-
}
}
card_res->count_encoders = encoder_count;
@@ -1376,10 +1375,9 @@ out:

 /**
  * drm_mode_getcrtc - get CRTC configuration
- * @inode: inode from the ioctl
- * @filp: file * from the ioctl
- * @cmd: cmd from ioctl
- * @arg: arg from ioctl
+ * @dev: DRM device
+ * @data: ioctl data
+ * @file_priv: DRM file info
  *
  * LOCKING:
  * Takes mode config lock.
@@ -1421,10 +1419,8 @@ int drm_mode_getcrtc(struct drm_device *dev,
crtc_resp->fb_id = 0;

if (crtc->enabled) {
-
drm_crtc_convert_to_umode(_resp->mode, >mode);
crtc_resp->mode_valid = 1;
-
} else {
crtc_resp->mode_valid = 0;
}
@@ -1436,10 +1432,9 @@ out:

 /**
  * drm_mode_getconnector - get connector configuration
- * @inode: inode from the ioctl
- * @filp: file * from the ioctl
- * @cmd: cmd from ioctl
- * @arg: arg from ioctl
+ * @dev: DRM device
+ * @data: ioctl data
+ * @file_priv: DRM file info
  *
  * LOCKING:
  * Takes mode config lock.
@@ -1732,8 +1727,8 @@ out:
 /**
  * drm_mode_setplane - set up or tear down an plane
  * @dev: DRM device
- * @data: ioctl data*
- * @file_prive: DRM file info
+ * @data: ioctl data
+ * @file_priv: DRM 

[PATCH] drm_crtc.c: fix some typo mistake and some annotations mistake

[Rob Clark]

On Thu, Mar 12, 2015 at 10:15 AM, John Hunter  wrote:
> Hi,
> I really don't  whether I am doing things on right workflow of dri-devel.
> I am new to this community and I want to help.
> Could anybody spare some time to tell me the right way .
> Thanks.

Hi John,

I don't actually see the original patch, just your reply to it..  if
you didn't already, could you git-send-email it to dri-devel?

(If you did, but were not subscribed, perhaps it is still stuck in
list moderation queue?)

BR,
-R


> John
>
> On Thu, Mar 12, 2015 at 4:02 PM, John Hunter  
> wrote:
>>
>> From: John Hunter 
>>
>> IMHO, some annotations were copypaste from somewhere else, it is
>> obviously not rightly modified. Hope I am right with that.
>> ---
>>  drivers/gpu/drm/drm_crtc.c | 115
>> ++---
>>  1 file changed, 56 insertions(+), 59 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index f2d667b..7f771e9 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -205,12 +205,12 @@ char *drm_get_connector_status_name(enum
>> drm_connector_status status)
>>  /**
>>   * drm_mode_object_get - allocate a new identifier
>>   * @dev: DRM device
>> - * @ptr: object pointer, used to generate unique ID
>> - * @type: object type
>> + * @obj: object pointer, used to generate unique ID
>> + * @obj_type: object type
>>   *
>>   * LOCKING:
>>   *
>> - * Create a unique identifier based on @ptr in @dev's identifier space.
>> Used
>> + * Create a unique identifier based on @obj in @dev's identifier space.
>> Used
>>   * for tracking modes, CRTCs and connectors.
>>   *
>>   * RETURNS:
>> @@ -245,12 +245,12 @@ again:
>>  /**
>>   * drm_mode_object_put - free an identifer
>>   * @dev: DRM device
>> - * @id: ID to free
>> + * @object: object to free
>>   *
>>   * LOCKING:
>>   * Caller must hold DRM mode_config lock.
>>   *
>> - * Free @id from @dev's unique identifier pool.
>> + * Free @object from @dev's unique identifier pool.
>>   */
>>  static void drm_mode_object_put(struct drm_device *dev,
>> struct drm_mode_object *object)
>> @@ -353,10 +353,11 @@ EXPORT_SYMBOL(drm_framebuffer_reference);
>>  void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
>>  {
>> struct drm_device *dev = fb->dev;
>> +
>> /*
>>  * This could be moved to drm_framebuffer_remove(), but for
>>  * debugging is nice to keep around the list of fb's that are
>> -* no longer associated w/ a drm_file but are not unreferenced
>> +* no longer associated with a drm_file but are not unreferenced
>>  * yet.  (i915 and omapdrm have debugfs files which will show
>>  * this.)
>>  */
>> @@ -519,7 +520,7 @@ EXPORT_SYMBOL(drm_mode_remove);
>>   * @dev: DRM device
>>   * @connector: the connector to init
>>   * @funcs: callbacks for this connector
>> - * @name: user visible name of the connector
>> + * @connector_type: type of the connector
>>   *
>>   * LOCKING:
>>   * Takes mode config lock.
>> @@ -683,7 +684,8 @@ int drm_plane_init(struct drm_device *dev, struct
>> drm_plane *plane,
>> plane->format_count = format_count;
>> plane->possible_crtcs = possible_crtcs;
>>
>> -   /* private planes are not exposed to userspace, but depending on
>> +   /*
>> +* private planes are not exposed to userspace, but depending on
>>  * display hardware, might be convenient to allow sharing
>> programming
>>  * for the scanout engine with the crtc implementation.
>>  */
>> @@ -1188,10 +1190,9 @@ static int drm_crtc_convert_umode(struct
>> drm_display_mode *out,
>>
>>  /**
>>   * drm_mode_getresources - get graphics configuration
>> - * @inode: inode from the ioctl
>> - * @filp: file * from the ioctl
>> - * @cmd: cmd from ioctl
>> - * @arg: arg from ioctl
>> + * @dev: DRM device
>> + * @data: ioctl data
>> + * @file_priv: DRM file info
>>   *
>>   * LOCKING:
>>   * Takes mode config lock.
>> @@ -1249,7 +1250,6 @@ int drm_mode_getresources(struct drm_device *dev,
>> void *data,
>> list_for_each(lh, >mode_config.encoder_list)
>> encoder_count++;
>> } else {
>> -
>> crtc_count = mode_group->num_crtcs;
>> connector_count = mode_group->num_connectors;
>> encoder_count = mode_group->num_encoders;
>> @@ -1328,7 +1328,6 @@ int drm_mode_getresources(struct drm_device *dev,
>> void *data,
>> }
>> copied++;
>> }
>> -
>> }
>> }
>> card_res->count_encoders = encoder_count;
>> @@ -1376,10 +1375,9 @@ out:
>>
>>  /**
>>   * drm_mode_getcrtc - get CRTC configuration
>> - * @inode: inode from the ioctl
>> - * @filp: file * from the ioctl
>> - * @cmd: cmd from ioctl
>> - * @arg: arg from ioctl
>> + * @dev: DRM device
>> + * @data: ioctl data
>> + *