linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: ccross@android.com (Colin Cross)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC/PATCH 08/10] [ARM] tegra: Add framebuffer driver
Date: Tue, 16 Mar 2010 17:31:28 -0700	[thread overview]
Message-ID: <d73d4eaf1003161731h2b8032dch55baf7b49eede625@mail.gmail.com> (raw)
In-Reply-To: <45a44e481003160057oaf4a75ax2ec6c9eee9f4a3e9@mail.gmail.com>

(Sorry about the HTML - resending in plain text for the linux-fbdev list)

Hi Jaya, thanks for your comments.

On Tue, Mar 16, 2010 at 12:57 AM, Jaya Kumar <jayakumar.lkml@gmail.com>wrote:

> Hi Colin, Erik,
>
> Interesting work.
>
> I'd recommend CCing linux-fbdev as well in future so that fbdev folks
> can also get a chance to review your new fbdev driver.

Will do

> +struct tegra_fb_lcd_data {
> > +       int     fb_xres;
> > +       int     fb_yres;
> > +       int     lcd_xres;
> > +       int     lcd_yres;
> > +       int     bits_per_pixel;
> > +};
>
> I'm trying to understand what's the difference between fb and lcd *res.

fb res is the resolution of the framebuffer driver as seen by userspace.
 lcd res is the resolution of the screen connected to the Tegra pins.  If
they are different, the Tegra display block can do scaling on the output.
 Generally they will be the same.  I'll add a comment to the lcd resolution.


> > +config FB_TEGRA
> > +       tristate "NVIDIA Tegra SoC display support"
> > +       depends on ARCH_TEGRA && FB = y
> > +       select FB_CFB_FILLRECT
> > +       select FB_CFB_COPYAREA
> > +       select FB_CFB_IMAGEBLIT
> > +       default FB
> > +       help
> > +         This driver supports the NVIDIA Tegra systems-on-a-chip.  This
> > +         driver can not be compiled as a module.
>
> Out of curiosity, why not?
>
Oversight, the option is tristate, so I'll remove this text.


> > +#define DEBUG 1
>
> You want to enable Debug by default for everyone?

Oops, I'll take it out


> > +struct tegra_fb_info {
> > +       struct clk *clk;
> > +       struct resource *reg_mem;
> > +       struct resource *fb_mem;
> > +       void __iomem *reg_base;
> > +       wait_queue_head_t event_wq;
> > +       unsigned int wait_condition;
> > +       int lcd_xres;
> > +       int lcd_yres;
> > +       int irq;
> > +};
>
> I think a comment about lcd_.res would help us understand what its
> used for and how it differs from fb_.res. How come it is being
> duplicated in multiple structures?

 The tegra_fb_lcd_data struct is passed in as platform_data, and used to
initialize the state in the tegra_fb_info struct.

 > +static int tegra_fb_cursor(struct fb_info *info, struct fb_cursor
> *cursor)
> > +{
> > +       return 0;
> > +}
> > +
> > +static int tegra_fb_sync(struct fb_info *info)
> > +{
> > +       return 0;
> > +}
>
> Out of curiosity, why populate these functions if they don't do anything?

They were placeholders, I'll remove them until they get implemented.


>  > +
> > +#ifdef DEBUG
> > +#define DUMP_REG(a) pr_info("%-32s\t%03x\t%08x\n", #a, a,
> tegra_fb_readl(tegra_fb, a));
>
> Could pr_debug be useful above?
>
The dump_regs function still needs to be inside the #ifdef DEBUG, but I'll
change the pr_info to pr_debug to lower the log level.


>  > +static struct fb_ops tegra_fb_ops = {
> > +       .fb_cursor = tegra_fb_cursor,
> > +       .fb_sync = tegra_fb_sync,
>
> These 2 were the empty functions from above. I'm guessing this isn't
> needed.

Removed


>  > +
> > +static int tegra_plat_remove(struct platform_device *pdev)
> > +{
> > +       struct fb_info *fb = platform_get_drvdata(pdev);
> > +       struct tegra_fb_info *tegra_fb = fb->par;
> > +       clk_disable(tegra_fb->clk);
> > +       iounmap(fb->screen_base);
> > +       release_resource(tegra_fb->fb_mem);
> > +       iounmap(tegra_fb->reg_base);
> > +       release_resource(tegra_fb->reg_mem);
> > +       framebuffer_release(fb);
> > +       return 0;
> > +}
> > +
>
> I didn't read through carefully but shouldn't there be an
> unregister_framebuffer in above? Wouldn't the above cause a free while
> the structures could still in use by fb*?
>
Good catch - unregister_framebuffer should be the first call. We generally
don't use modules much, so compiling as a module has been tested, but not
running as a module.

Thanks,
Colin

  reply	other threads:[~2010-03-17  0:31 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-09 16:38 [RFC/PATCH] ARM: add Tegra support Mike Rapoport
2010-03-14  6:51 ` Mike Rapoport
2010-03-15  6:54   ` Thierry Reding
2010-03-15 16:16     ` Thierry Reding
2010-03-15 17:41 ` Gary King
2010-03-15 18:09 ` Russell King - ARM Linux
2010-03-15 22:38 ` Erik Gilling
2010-03-16  6:41   ` [RFC/PATCH 00/10] Tegra2 support konkers at google.com
2010-03-16  6:41     ` [RFC/PATCH 01/10] [ARM] tegra: initial tegra support konkers at google.com
2010-03-16  6:41       ` [RFC/PATCH 02/10] [ARM] tegra: Add IRQ support konkers at google.com
2010-03-16  6:41         ` [RFC/PATCH 03/10] [ARM] tegra: Add clock support konkers at google.com
2010-03-16  6:41           ` [RFC/PATCH 04/10] [ARM] tegra: SMP support konkers at google.com
2010-03-16  6:41             ` [RFC/PATCH 05/10] [ARM] tegra: Add timer support konkers at google.com
2010-03-16  6:41               ` [RFC/PATCH 06/10] [ARM] tegra: add GPIO support konkers at google.com
2010-03-16  6:41                 ` [RFC/PATCH 07/10] [ARM] tegra: add pinmux support konkers at google.com
2010-03-16  6:41                   ` [RFC/PATCH 08/10] [ARM] tegra: Add framebuffer driver konkers at google.com
2010-03-16  6:41                     ` [RFC/PATCH 09/10] [ARM] tegra: harmony: Add harmony board file konkers at google.com
2010-03-16  6:41                       ` [RFC/PATCH 10/10] [ARM] tegra: Add harmony_defconfig konkers at google.com
2010-03-17  8:21                       ` [RFC/PATCH 09/10] [ARM] tegra: harmony: Add harmony board file Mike Rapoport
2010-03-18  2:27                         ` Erik Gilling
2010-03-18 20:41                           ` mike at compulab.co.il
2010-03-16  7:57                     ` [RFC/PATCH 08/10] [ARM] tegra: Add framebuffer driver Jaya Kumar
2010-03-17  0:31                       ` Colin Cross [this message]
2010-03-18  8:47                     ` Russell King - ARM Linux
2010-03-18 23:57                       ` Colin Cross
2010-03-17  8:15                 ` [RFC/PATCH 06/10] [ARM] tegra: add GPIO support Mike Rapoport
2010-03-18  2:19                   ` Erik Gilling
2010-03-18  8:42           ` [RFC/PATCH 03/10] [ARM] tegra: Add clock support Russell King - ARM Linux
2010-03-18 23:57             ` Colin Cross
2010-03-17  7:57       ` [RFC/PATCH 01/10] [ARM] tegra: initial tegra support Mike Rapoport
2010-03-18  8:32     ` [RFC/PATCH 00/10] Tegra2 support Russell King - ARM Linux
2010-03-18 16:40       ` Erik Gilling
2010-03-18 20:30       ` Erik Gilling
2010-03-18 21:03         ` Erik Gilling
2010-03-16  8:49   ` [RFC/PATCH] ARM: add Tegra support Mike Rapoport
2010-03-16 13:44     ` Brian Swetland
2010-03-16 14:11       ` Mike Rapoport

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=d73d4eaf1003161731h2b8032dch55baf7b49eede625@mail.gmail.com \
    --to=ccross@android.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).