All of lore.kernel.org
 help / color / mirror / Atom feed
From: daeinki <inki.dae@samsung.com>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: Some questions about DRM(Direct Rendering Manager)
Date: Wed, 22 Jun 2011 06:04:23 +0000	[thread overview]
Message-ID: <4E0185E7.8020708@samsung.com> (raw)
In-Reply-To: <4E016EDC.30200@samsung.com>

below is additional comments.

daeinki ¾´ ±Û:
> Hi all,
> 
> I'm writing Samsung SoC based DRM framework and this one includes FIMD
> and HDMI driver as hardware dependent modules. and for now, encoder,
> connector, crtc and fb module has been materialized almost. but I'm
> contending with  framebuffer setting issue(created fb_info should be
> registered to linux framebuffer through register_framebuffer() or not)as
> default framebuffer at booting time.
> 
> at drm_fb_helper_single_fb_probe() of drm_fb_helper.c file, fb_helper's
> fb_probe callback is called and this one creates new framebuffer and
> returns a value more then 0 if true. internally, this process creates an
> fb_info object and drm_framebuffer and then drm_framebuffer would be
> added to mode_config.fb_list of the drm_device.
>
it's my mistake. return value is 0 if true, nonzero otherwise.

> a value returned, new_fb is used to decide that it calls
> register_framebuffer() or drm_fb_helper_set_par(). at this point, I am
> confused it's a good way to call register_framebuffer() otherwise
> drm_fb_helper_set_par(). if register_framebuffer() is called then I
> guess drm_fb_helper_set_par() or drm_crtc_helper_set_config() should be
> called somewhere subsequently to apply this one to real hardware because
> previous process is just for maintaining data logically.(not set up data
> to h/w)
> 
> it's a right way to call register_framebuffer() and then
> drm_fb_helper_set_par() or drm_crtc_helper_set_config()? otherwise just
> only drm_fb_helper_set_par() or drm_crtc_helper_set_config() ignoring
> register_framebuffer()? and what is the purpose of using
> register_framebuffer()?
> 
I understood that if fb_probe() callback is fail then fb_info object is
registered to linux framebuffer through register_framebuffer()
otherwise(if true) hardware configuration would be completed by
drm_fb_helper_set_par() so the reason of using register_framebuffer() is
that the case of failing fb_probe() callback, it is for drawing on only
linux framebuffer. is it right?

> In my case, first, register_framebuffer() is called and then if desired
> default crtc id is matched with drm_fb_helper->crtc_info[0 ~ n].crtc_id,
> it gets mode_set of drm_fb_helper->crtc_info[n] and then  it calls
> drm_crtc_helper_set_config(mode_set). at this time, all the hardware
> configurations would be completed.
> 
> thank you in advance.
> 
> Best Regards
> Inki Dae.
> 


WARNING: multiple messages have this Message-ID (diff)
From: inki.dae@samsung.com (daeinki)
To: linux-arm-kernel@lists.infradead.org
Subject: Some questions about DRM(Direct Rendering Manager)
Date: Wed, 22 Jun 2011 15:04:23 +0900	[thread overview]
Message-ID: <4E0185E7.8020708@samsung.com> (raw)
In-Reply-To: <4E016EDC.30200@samsung.com>

below is additional comments.

daeinki ? ?:
> Hi all,
> 
> I'm writing Samsung SoC based DRM framework and this one includes FIMD
> and HDMI driver as hardware dependent modules. and for now, encoder,
> connector, crtc and fb module has been materialized almost. but I'm
> contending with  framebuffer setting issue(created fb_info should be
> registered to linux framebuffer through register_framebuffer() or not)as
> default framebuffer at booting time.
> 
> at drm_fb_helper_single_fb_probe() of drm_fb_helper.c file, fb_helper's
> fb_probe callback is called and this one creates new framebuffer and
> returns a value more then 0 if true. internally, this process creates an
> fb_info object and drm_framebuffer and then drm_framebuffer would be
> added to mode_config.fb_list of the drm_device.
>
it's my mistake. return value is 0 if true, nonzero otherwise.

> a value returned, new_fb is used to decide that it calls
> register_framebuffer() or drm_fb_helper_set_par(). at this point, I am
> confused it's a good way to call register_framebuffer() otherwise
> drm_fb_helper_set_par(). if register_framebuffer() is called then I
> guess drm_fb_helper_set_par() or drm_crtc_helper_set_config() should be
> called somewhere subsequently to apply this one to real hardware because
> previous process is just for maintaining data logically.(not set up data
> to h/w)
> 
> it's a right way to call register_framebuffer() and then
> drm_fb_helper_set_par() or drm_crtc_helper_set_config()? otherwise just
> only drm_fb_helper_set_par() or drm_crtc_helper_set_config() ignoring
> register_framebuffer()? and what is the purpose of using
> register_framebuffer()?
> 
I understood that if fb_probe() callback is fail then fb_info object is
registered to linux framebuffer through register_framebuffer()
otherwise(if true) hardware configuration would be completed by
drm_fb_helper_set_par() so the reason of using register_framebuffer() is
that the case of failing fb_probe() callback, it is for drawing on only
linux framebuffer. is it right?

> In my case, first, register_framebuffer() is called and then if desired
> default crtc id is matched with drm_fb_helper->crtc_info[0 ~ n].crtc_id,
> it gets mode_set of drm_fb_helper->crtc_info[n] and then  it calls
> drm_crtc_helper_set_config(mode_set). at this time, all the hardware
> configurations would be completed.
> 
> thank you in advance.
> 
> Best Regards
> Inki Dae.
> 

  reply	other threads:[~2011-06-22  6:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-22  4:26 Some questions about DRM(Direct Rendering Manager) daeinki
2011-06-22  4:26 ` daeinki
2011-06-22  6:04 ` daeinki [this message]
2011-06-22  6:04   ` daeinki
2011-06-22  7:50   ` InKi Dae
2011-06-22  7:50     ` InKi Dae
2011-06-22  7:50     ` InKi Dae
2011-06-22 13:07     ` Rob Clark
2011-06-22 13:07       ` Rob Clark
2011-06-22 13:07       ` Rob Clark
2011-06-23  1:55       ` daeinki
2011-06-23  1:55         ` daeinki
2011-06-23  1:55         ` daeinki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E0185E7.8020708@samsung.com \
    --to=inki.dae@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.