All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com>
To: krzysztof.h1@poczta.fm
Cc: "Linux-fbdev-devel@lists.sourceforge.net"
	<Linux-fbdev-devel@lists.sourceforge.net>,
	Paul Mundt <lethal@linux-sh.org>,
	Linux-sh <linux-sh@vger.kernel.org>
Subject: Re: [Linux-fbdev-devel] [PATCH 1/4] video: sh7760fb: SH7760/SH7763 LCDC framebuffer driver part 1/3
Date: Thu, 26 Jun 2008 14:31:47 +0900	[thread overview]
Message-ID: <486329C3.2020806@renesas.com> (raw)
In-Reply-To: <20080625082914.E208721C824@f28.poczta.interia.pl>

krzysztof.h1@poczta.fm wrote:
>> Main source code of Driver for the LCDC interface on the SH7760 and SH7763
>> SoCs.
>>
>> Signed-off-by: Manuel Lauss <mano@roarinelk.homelinux.net>
>> Signed-off-by: Nobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com>
>> ---
>>  drivers/video/sh7760fb.c |  717
>> ++++++++++++++++++++++++++++++++++++++++++++++
>>  1 files changed, 717 insertions(+), 0 deletions(-)
>>  create mode 100644 drivers/video/sh7760fb.c
>>
>> diff --git a/drivers/video/sh7760fb.c b/drivers/video/sh7760fb.c
<snip>

>> +#define LDCNTR		0x428
>> +#define LDCNTR_DON	(1 << 0)
>> +#define LDCNTR_DON2	(1 << 4)
>> +#ifdef CONFIG_CPU_SUBTYPE_SH7763
>> +# define LDLIRNR	0x440
>> +#endif
>> +
> 
> These definitions should be moved to the header file. Part of bits definitions are there and I suppose these bits are related to registers.
> 
>> +/*
>> + * some bits of the colormap registers should be written as zero.
>> + * create a mask for that.
>> + */
>> +#define SH7760FB_PALETTE_MASK    0x00f8fcf8
>> +
>> +/* The LCDC dma engine always sets bits 27-26 to 1: this is Area3 */
>> +#define SH7760FB_DMA_MASK      0x0C000000
>> +
>> +struct sh7760fb_par {
>> +	void __iomem *base;
>> +	struct sh7760fb_platdata *pd;	/* display information */
>> +
>> +	/* framebuffer memory information */
>> +	void *fbmem;		/* alloced framebuffer */
>> +	dma_addr_t fbdma;	/* physical address */
>> +	unsigned long vram;	/* size, in bytes */
> 
> The fields fbmem and vram are redundant as you can use smem_start/smem_len or or screen_base/screen_size to store the same information (and you do it anyway).
> 
>> +	unsigned long stride;
>> +
> 
> The line_length field is the same (redundant).
> 
<snip>

>> +	if (blank == FB_BLANK_UNBLANK) {
>> +		cntr = LDCNTR_DON2 | LDCNTR_DON;
>> +		lps = 3;
>> +		if (pd->blank)
>> +			pd->blank(blank);
> 
> Probably pd->blank can be moved outside the if-else stantement.
> 
>> +
>> +	if (par->disp_set)
>> +		return 0;
>> +
> 
> Is there any specific reason you cannot do disp_set twice? It means that the framebuffer is not able to change display depth at runtime. Probably you can drop the disp_set field completely. If the registers are programmed twice to the same values it should do no harm.
> 
<snip>

>> +
>> +	bpp = gray = 0;
> 
> There is no reason to set the bpp (it is set in all cases).
<snip>

>> +
>> +	var->bits_per_pixel = bpp;
>> +
> 
> The changes in fbinfo->var is allowed only in the check_var function (see skeletonfb.c foe explanations). You should move the code which changes the var structure into the check_var functions and get some code reduction.
<snip>

>> +
>> +	par->fbmem = NULL;
>> +	par->fbdma = 0;
>> +	info->screen_base = NULL;
>> +	info->screen_size = 0;
> 
> Just use the screen_base/screen_size instead of the fbmem/vram fields.
<snip>

>> +	OUT16(par, LDCNTR_DON2, LDCNTR);
>> +	info->fbops = &sh7760fb_ops;
>> +	fb_alloc_cmap(&info->cmap, 256, 0);
>> +
> 
> Check if the cmap was correctly allocated and release it on error below (if the framebuffer is not registered).
> 
Thank you for your check and comments.
I will fix and update all.

Best regards,
  Nobuhiro

WARNING: multiple messages have this Message-ID (diff)
From: Nobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com>
To: krzysztof.h1@poczta.fm
Cc: "Linux-fbdev-devel@lists.sourceforge.net"
	<Linux-fbdev-devel@lists.sourceforge.net>,
	Paul Mundt <lethal@linux-sh.org>,
	Linux-sh <linux-sh@vger.kernel.org>
Subject: Re: [Linux-fbdev-devel] [PATCH 1/4] video: sh7760fb: SH7760/SH7763
Date: Thu, 26 Jun 2008 05:31:47 +0000	[thread overview]
Message-ID: <486329C3.2020806@renesas.com> (raw)
In-Reply-To: <20080625082914.E208721C824@f28.poczta.interia.pl>

krzysztof.h1@poczta.fm wrote:
>> Main source code of Driver for the LCDC interface on the SH7760 and SH7763
>> SoCs.
>>
>> Signed-off-by: Manuel Lauss <mano@roarinelk.homelinux.net>
>> Signed-off-by: Nobuhiro Iwamatsu <iwamatsu.nobuhiro@renesas.com>
>> ---
>>  drivers/video/sh7760fb.c |  717
>> ++++++++++++++++++++++++++++++++++++++++++++++
>>  1 files changed, 717 insertions(+), 0 deletions(-)
>>  create mode 100644 drivers/video/sh7760fb.c
>>
>> diff --git a/drivers/video/sh7760fb.c b/drivers/video/sh7760fb.c
<snip>

>> +#define LDCNTR		0x428
>> +#define LDCNTR_DON	(1 << 0)
>> +#define LDCNTR_DON2	(1 << 4)
>> +#ifdef CONFIG_CPU_SUBTYPE_SH7763
>> +# define LDLIRNR	0x440
>> +#endif
>> +
> 
> These definitions should be moved to the header file. Part of bits definitions are there and I suppose these bits are related to registers.
> 
>> +/*
>> + * some bits of the colormap registers should be written as zero.
>> + * create a mask for that.
>> + */
>> +#define SH7760FB_PALETTE_MASK    0x00f8fcf8
>> +
>> +/* The LCDC dma engine always sets bits 27-26 to 1: this is Area3 */
>> +#define SH7760FB_DMA_MASK      0x0C000000
>> +
>> +struct sh7760fb_par {
>> +	void __iomem *base;
>> +	struct sh7760fb_platdata *pd;	/* display information */
>> +
>> +	/* framebuffer memory information */
>> +	void *fbmem;		/* alloced framebuffer */
>> +	dma_addr_t fbdma;	/* physical address */
>> +	unsigned long vram;	/* size, in bytes */
> 
> The fields fbmem and vram are redundant as you can use smem_start/smem_len or or screen_base/screen_size to store the same information (and you do it anyway).
> 
>> +	unsigned long stride;
>> +
> 
> The line_length field is the same (redundant).
> 
<snip>

>> +	if (blank = FB_BLANK_UNBLANK) {
>> +		cntr = LDCNTR_DON2 | LDCNTR_DON;
>> +		lps = 3;
>> +		if (pd->blank)
>> +			pd->blank(blank);
> 
> Probably pd->blank can be moved outside the if-else stantement.
> 
>> +
>> +	if (par->disp_set)
>> +		return 0;
>> +
> 
> Is there any specific reason you cannot do disp_set twice? It means that the framebuffer is not able to change display depth at runtime. Probably you can drop the disp_set field completely. If the registers are programmed twice to the same values it should do no harm.
> 
<snip>

>> +
>> +	bpp = gray = 0;
> 
> There is no reason to set the bpp (it is set in all cases).
<snip>

>> +
>> +	var->bits_per_pixel = bpp;
>> +
> 
> The changes in fbinfo->var is allowed only in the check_var function (see skeletonfb.c foe explanations). You should move the code which changes the var structure into the check_var functions and get some code reduction.
<snip>

>> +
>> +	par->fbmem = NULL;
>> +	par->fbdma = 0;
>> +	info->screen_base = NULL;
>> +	info->screen_size = 0;
> 
> Just use the screen_base/screen_size instead of the fbmem/vram fields.
<snip>

>> +	OUT16(par, LDCNTR_DON2, LDCNTR);
>> +	info->fbops = &sh7760fb_ops;
>> +	fb_alloc_cmap(&info->cmap, 256, 0);
>> +
> 
> Check if the cmap was correctly allocated and release it on error below (if the framebuffer is not registered).
> 
Thank you for your check and comments.
I will fix and update all.

Best regards,
  Nobuhiro

  reply	other threads:[~2008-06-26  5:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-25  8:29 [Linux-fbdev-devel] [PATCH 1/4] video: sh7760fb: SH7760/SH7763 LCDC framebuffer driver part 1/3 krzysztof.h1
2008-06-25  8:29 ` krzysztof.h1
2008-06-26  5:31 ` Nobuhiro Iwamatsu [this message]
2008-06-26  5:31   ` [Linux-fbdev-devel] [PATCH 1/4] video: sh7760fb: SH7760/SH7763 Nobuhiro Iwamatsu

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=486329C3.2020806@renesas.com \
    --to=iwamatsu.nobuhiro@renesas.com \
    --cc=Linux-fbdev-devel@lists.sourceforge.net \
    --cc=krzysztof.h1@poczta.fm \
    --cc=lethal@linux-sh.org \
    --cc=linux-sh@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 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.