From: Kristoffer Glembo <kristoffer@gaisler.com>
To: linux-fbdev@vger.kernel.org
Subject: Re: [PATCH] video: Add GRVGA framebuffer device driver
Date: Thu, 16 Jun 2011 07:20:33 +0000 [thread overview]
Message-ID: <4DF9AEC1.8050808@gaisler.com> (raw)
In-Reply-To: <1308128180-14645-1-git-send-email-kristoffer@gaisler.com>
Hi Konrad,
Konrad Rzeszutek Wilk wrote:
>> +#define GRVGA_REGLOAD(a) (__raw_readl(&(a)))
>> +#define GRVGA_REGSAVE(a, v) (__raw_writel(v, &(a)))
>
> writel?
>
I use __raw since I want native endianess. On a big endian system
writel/readl byte swap since they are for little endian (PCI).
>> +struct grvga_regs {
>> + u32 status; /* 0x00 */
>> + u32 video_length; /* 0x04 */
>> + u32 front_porch; /* 0x08 */
>> + u32 sync_length; /* 0x0C */
>> + u32 line_length; /* 0x10 */
>> + u32 fb_pos; /* 0x14 */
>> + u32 clk_vector[4]; /* 0x18 */
>> + u32 clut; /* 0x20 */
>> +};
>
> Would it make sense to add __packed__ here? It seems that you
> really depend on this ordering.
>
I depend on the ordering, but that is guaranteed by the compiler without __packed__.
Attribute __packed__ is dangerous here since it tells the compiler that it is ok
to do byte accesses.
>> +static struct fb_ops grvga_ops = {
>> + .owner = THIS_MODULE,
>> + .fb_check_var = grvga_check_var,
>> + .fb_set_par = grvga_set_par,
>> + .fb_setcolreg = grvga_setcolreg,
>> + .fb_pan_display = grvga_pan_display,
>> + .fb_fillrect = cfb_fillrect,
>> + .fb_copyarea = cfb_copyarea,
>> + .fb_imageblit = cfb_imageblit
>> +};
>
> Could you move this struct down and remove the declarations earlier?
Yes sure.
>> + }
>> + if (i != -1)
>> + par->clk_sel = i;
>
> How would i possibly become -1?
Refactoring error .. thanks!
>> +static int grvga_set_par(struct fb_info *info)
>> +{
>> +
>> + int func = 0;
>
> You probably want that to be u32.
Sure why not.
> No default case?
Will add ...
>> + physical_start = __pa(virtual_start);
>
> Yikes. That is one big assumption. You don't want to use the PCI/DMA API
> to map it? I thought that on SPARCs the Bus addresses are different
> from the physical addresses?
Yeah I should map it for cleanliness sake. It does not matter on this architecture (LEON) though.
>> +
>> + if (info) {
>> + unregister_framebuffer(info);
>> + fb_dealloc_cmap(&info->cmap);
>> + of_iounmap(&device->resource[0], par->regs,
>> + resource_size(&device->resource[0]));
>> + framebuffer_release(info);
>> + dev_set_drvdata(&device->dev, NULL);
>
> Shouldn't that be much earlier? Like right after unregister_framebuffer?
>
You mean I should set driver_data = NULL ASAP after unregistering the framebuffer?
Does it really matter? Please enlighten me.
Thanks a lot for your feedback.
Best regards,
Kristoffer Glembo
prev parent reply other threads:[~2011-06-16 7:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-15 8:56 [PATCH] video: Add GRVGA framebuffer device driver Kristoffer Glembo
2011-06-15 11:32 ` Geert Uytterhoeven
2011-06-15 11:52 ` Kristoffer Glembo
2011-06-15 12:09 ` Geert Uytterhoeven
2011-06-15 14:56 ` Konrad Rzeszutek Wilk
2011-06-16 7:20 ` Kristoffer Glembo [this message]
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=4DF9AEC1.8050808@gaisler.com \
--to=kristoffer@gaisler.com \
--cc=linux-fbdev@vger.kernel.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).