All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
To: Yifeng Li <tomli@tomli.me>
Cc: Teddy Wang <teddy.wang@siliconmotion.com>,
	linux-kernel@vger.kernel.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 4/7] fbdev: sm712fb: add 32-bit color modes, drops some other modes.
Date: Sun, 31 Mar 2019 19:33:33 +0100	[thread overview]
Message-ID: <20190331183333.kpyt2hm5iy6m5u34@debian> (raw)
In-Reply-To: <20190322051759.15007-5-tomli@tomli.me>

On Fri, Mar 22, 2019 at 01:17:56PM +0800, Yifeng Li wrote:
> The modesetting in sm712fb is an ugly hack. First, all the registers
> are programmed by hardcoded register arrays, which makes it difficult
> to support different variations of color depths, refresh rates, CRT/LCD
> panel, etc of the same resolution. Second, it means the standard
> fb_find_mode() cannot be used and a confusing non-standard "vga="
> parameter is needed. Third, there's only minimum differences between
> some modes, yet around 70 lines of code and 100 registers are needed to
> be indepentently specified for each mode. Fourth, the register between
> some modes are inconsistent: the register configuration of different
> color depths in 640 x 480 modes are identical, but for 800 x 600 modes
> it's completely different. Also, some modes can drive the LCD panel
> properly yet some other modes will only show a white screen of death on
> the LCD panel. Fifth, some modes, such as 32-bit color modes, are
> supported but never listed, and some modes are listed, such as 1280x1024
> modes, but never supported by the register configuration arrays. And
> some modes are partially implemented but neither listed nor supported,
> i.e. the 8-bit color modes.
> 
> Fixing these problems requires a complete rewrite of modesetting code,
> which is well-beyond my motivation. This commit only perform a minimum
> cleanup:
> 
> 1. Remove the 320 x 240 register settings, since there are never listed
> and never actually being used. This resolution is not even supported by
> vesafb, so it's safe to assume that no one is using such hardware. Future
> developers who needs them can simply recover them from the git history.

Why are you removing existing functionality from the driver? These are
supported but were never listed so could not be used. I think you can
just add these to vesa_mode_table[] and they can be used. I have an old
CRT in India which supports 320x240 mode and can test there when I am
there next.

> 
> 2. Remove 1280x1024 modes and 8-bit color modes. They are listed but never
> supported by the register array. So it doesn't work in the beginning, and
> only gives a black screen.
> 
> 3. Add 32-bit color modes. They are supported but never listed, and are
> useful to some users.
> 
> Signed-off-by: Yifeng Li <tomli@tomli.me>
> ---
>  drivers/video/fbdev/sm712fb.c | 158 +++++++---------------------------
>  1 file changed, 31 insertions(+), 127 deletions(-)
> 
> diff --git a/drivers/video/fbdev/sm712fb.c b/drivers/video/fbdev/sm712fb.c
> index 75d60ea63883..5e887653ef5d 100644
> --- a/drivers/video/fbdev/sm712fb.c
> +++ b/drivers/video/fbdev/sm712fb.c
> @@ -118,25 +118,48 @@ struct vesa_mode {
>  };
>  
>  static const struct vesa_mode vesa_mode_table[] = {
> -	{"0x301", 640,  480,  8},
> -	{"0x303", 800,  600,  8},
> -	{"0x305", 1024, 768,  8},
> -	{"0x307", 1280, 1024, 8},
> -
>  	{"0x311", 640,  480,  16},
>  	{"0x314", 800,  600,  16},
>  	{"0x317", 1024, 768,  16},
> -	{"0x31A", 1280, 1024, 16},
>  
>  	{"0x312", 640,  480,  24},
>  	{"0x315", 800,  600,  24},
>  	{"0x318", 1024, 768,  24},
> -	{"0x31B", 1280, 1024, 24},
> +
> +	{"0x329", 640,  480,  32},
> +	{"0x32e", 800,  600,  32},
> +	{"0x338", 1024, 768,  32},
>  };
>  
>  /**********************************************************************
>  			 SM712 Mode table.
> - **********************************************************************/
> +
> + The modesetting in sm712fb is an ugly hack. First, all the registers
> + are programmed by hardcoded register arrays, which makes it difficult
> + to support different variations of color depths, refresh rates, CRT/LCD
> + panel, etc of the same resolution. Second, it means the standard
> + fb_find_mode() cannot be used and a confusing non-standard "vga="
> + parameter is needed. Third, there's only minimum differences between
> + some modes, yet around 70 lines of code and 100 registers are needed to
> + be indepentently specified for each mode. Fourth, the register between
> + some modes are inconsistent: the register configuration of different
> + color depths in 640 x 480 modes are identical, but for 800 x 600 modes
> + it's completely different. Also, some modes can drive the LCD panel
> + properly yet some other modes will only show a white screen of death on
> + the LCD panel. Fifth, there is a specific hack for Lemote Loongson 8089D
> + laptop, the 1024x768, 16-bit color mode was modified to drive its LCD panel
> + and changed to 1024x600, but the original mode was not preserved, so
> + 1024x768 16-bit color mode is completely unsupported. And previously,
> + some modes are listed, such as 1280x1024 modes, but never supported by
> + the register configuration arrays, so they are now removed. And some modes
> + are partially implemented but neither listed nor supported, i.e. the 8-bit
> + color modes, so they have been removed from vesa_mode_table, too.

I think this comment sounds more like a commit message instead of a
code comment. Does this improve readability?

> +
> + I'm not the original author of the code, fixing these problems requires a
> + complete rewrite of modesetting code, which is well-beyond my motivation.
> +
> + See Documentation/fb/sm712fb.txt for more information.
> +**********************************************************************/

Is this needed? Many of the commits of the driver are done by people who
are not the original author.

--
Regards
Sudip

WARNING: multiple messages have this Message-ID (diff)
From: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
To: Yifeng Li <tomli@tomli.me>
Cc: Teddy Wang <teddy.wang@siliconmotion.com>,
	linux-kernel@vger.kernel.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 4/7] fbdev: sm712fb: add 32-bit color modes, drops some other modes.
Date: Sun, 31 Mar 2019 18:33:33 +0000	[thread overview]
Message-ID: <20190331183333.kpyt2hm5iy6m5u34@debian> (raw)
In-Reply-To: <20190322051759.15007-5-tomli@tomli.me>

On Fri, Mar 22, 2019 at 01:17:56PM +0800, Yifeng Li wrote:
> The modesetting in sm712fb is an ugly hack. First, all the registers
> are programmed by hardcoded register arrays, which makes it difficult
> to support different variations of color depths, refresh rates, CRT/LCD
> panel, etc of the same resolution. Second, it means the standard
> fb_find_mode() cannot be used and a confusing non-standard "vga="
> parameter is needed. Third, there's only minimum differences between
> some modes, yet around 70 lines of code and 100 registers are needed to
> be indepentently specified for each mode. Fourth, the register between
> some modes are inconsistent: the register configuration of different
> color depths in 640 x 480 modes are identical, but for 800 x 600 modes
> it's completely different. Also, some modes can drive the LCD panel
> properly yet some other modes will only show a white screen of death on
> the LCD panel. Fifth, some modes, such as 32-bit color modes, are
> supported but never listed, and some modes are listed, such as 1280x1024
> modes, but never supported by the register configuration arrays. And
> some modes are partially implemented but neither listed nor supported,
> i.e. the 8-bit color modes.
> 
> Fixing these problems requires a complete rewrite of modesetting code,
> which is well-beyond my motivation. This commit only perform a minimum
> cleanup:
> 
> 1. Remove the 320 x 240 register settings, since there are never listed
> and never actually being used. This resolution is not even supported by
> vesafb, so it's safe to assume that no one is using such hardware. Future
> developers who needs them can simply recover them from the git history.

Why are you removing existing functionality from the driver? These are
supported but were never listed so could not be used. I think you can
just add these to vesa_mode_table[] and they can be used. I have an old
CRT in India which supports 320x240 mode and can test there when I am
there next.

> 
> 2. Remove 1280x1024 modes and 8-bit color modes. They are listed but never
> supported by the register array. So it doesn't work in the beginning, and
> only gives a black screen.
> 
> 3. Add 32-bit color modes. They are supported but never listed, and are
> useful to some users.
> 
> Signed-off-by: Yifeng Li <tomli@tomli.me>
> ---
>  drivers/video/fbdev/sm712fb.c | 158 +++++++---------------------------
>  1 file changed, 31 insertions(+), 127 deletions(-)
> 
> diff --git a/drivers/video/fbdev/sm712fb.c b/drivers/video/fbdev/sm712fb.c
> index 75d60ea63883..5e887653ef5d 100644
> --- a/drivers/video/fbdev/sm712fb.c
> +++ b/drivers/video/fbdev/sm712fb.c
> @@ -118,25 +118,48 @@ struct vesa_mode {
>  };
>  
>  static const struct vesa_mode vesa_mode_table[] = {
> -	{"0x301", 640,  480,  8},
> -	{"0x303", 800,  600,  8},
> -	{"0x305", 1024, 768,  8},
> -	{"0x307", 1280, 1024, 8},
> -
>  	{"0x311", 640,  480,  16},
>  	{"0x314", 800,  600,  16},
>  	{"0x317", 1024, 768,  16},
> -	{"0x31A", 1280, 1024, 16},
>  
>  	{"0x312", 640,  480,  24},
>  	{"0x315", 800,  600,  24},
>  	{"0x318", 1024, 768,  24},
> -	{"0x31B", 1280, 1024, 24},
> +
> +	{"0x329", 640,  480,  32},
> +	{"0x32e", 800,  600,  32},
> +	{"0x338", 1024, 768,  32},
>  };
>  
>  /**********************************************************************
>  			 SM712 Mode table.
> - **********************************************************************/
> +
> + The modesetting in sm712fb is an ugly hack. First, all the registers
> + are programmed by hardcoded register arrays, which makes it difficult
> + to support different variations of color depths, refresh rates, CRT/LCD
> + panel, etc of the same resolution. Second, it means the standard
> + fb_find_mode() cannot be used and a confusing non-standard "vga="
> + parameter is needed. Third, there's only minimum differences between
> + some modes, yet around 70 lines of code and 100 registers are needed to
> + be indepentently specified for each mode. Fourth, the register between
> + some modes are inconsistent: the register configuration of different
> + color depths in 640 x 480 modes are identical, but for 800 x 600 modes
> + it's completely different. Also, some modes can drive the LCD panel
> + properly yet some other modes will only show a white screen of death on
> + the LCD panel. Fifth, there is a specific hack for Lemote Loongson 8089D
> + laptop, the 1024x768, 16-bit color mode was modified to drive its LCD panel
> + and changed to 1024x600, but the original mode was not preserved, so
> + 1024x768 16-bit color mode is completely unsupported. And previously,
> + some modes are listed, such as 1280x1024 modes, but never supported by
> + the register configuration arrays, so they are now removed. And some modes
> + are partially implemented but neither listed nor supported, i.e. the 8-bit
> + color modes, so they have been removed from vesa_mode_table, too.

I think this comment sounds more like a commit message instead of a
code comment. Does this improve readability?

> +
> + I'm not the original author of the code, fixing these problems requires a
> + complete rewrite of modesetting code, which is well-beyond my motivation.
> +
> + See Documentation/fb/sm712fb.txt for more information.
> +**********************************************************************/

Is this needed? Many of the commits of the driver are done by people who
are not the original author.

--
Regards
Sudip

  reply	other threads:[~2019-03-31 18:33 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-22  5:17 [PATCH v2 0/7] implement 2D acceleration, minor cleanups, doc updates Yifeng Li
2019-03-22  5:17 ` Yifeng Li
2019-03-22  5:17 ` [PATCH v2 1/7] fbdev: sm712fb: use type "u8" for 8-bit I/O Yifeng Li
2019-03-22  5:17   ` Yifeng Li
2019-03-31 17:16   ` Sudip Mukherjee
2019-03-31 17:16     ` Sudip Mukherjee
2019-03-31 17:16     ` Sudip Mukherjee
2019-03-22  5:17 ` [PATCH v2 2/7] fbdev: sm712fb: add 2D-related I/O headers and functions Yifeng Li
2019-03-22  5:17   ` Yifeng Li
2019-03-31 17:25   ` Sudip Mukherjee
2019-03-31 17:25     ` Sudip Mukherjee
2019-04-01 16:04     ` Tom Li
2019-04-01 16:04       ` Tom Li
2019-03-22  5:17 ` [PATCH v2 3/7] fbdev: sm712fb: support 2D acceleration on SM712 w/ Little-Endian CPU Yifeng Li
2019-03-22  5:17   ` Yifeng Li
2019-03-31 18:09   ` Sudip Mukherjee
2019-03-31 18:09     ` Sudip Mukherjee
2019-04-01 16:26     ` Tom Li
2019-04-01 16:26       ` Tom Li
2019-04-02 20:53       ` Sudip Mukherjee
2019-04-02 20:53         ` Sudip Mukherjee
2019-03-22  5:17 ` [PATCH v2 4/7] fbdev: sm712fb: add 32-bit color modes, drops some other modes Yifeng Li
2019-03-22  5:17   ` Yifeng Li
2019-03-31 18:33   ` Sudip Mukherjee [this message]
2019-03-31 18:33     ` Sudip Mukherjee
2019-04-01 16:41     ` Tom Li
2019-04-01 16:41       ` Tom Li
2019-04-02 20:59       ` Sudip Mukherjee
2019-04-02 20:59         ` Sudip Mukherjee
2019-03-22  5:17 ` [PATCH v2 5/7] Documentation: fb: sm712fb: add information mainly about 2D Yifeng Li
2019-03-22  5:17   ` Yifeng Li
2019-03-31 18:54   ` Sudip Mukherjee
2019-03-31 18:54     ` Sudip Mukherjee
2019-03-31 18:54     ` Sudip Mukherjee
2019-04-01 17:30     ` Tom Li
2019-04-01 17:30       ` Tom Li
2019-04-02 21:03       ` Sudip Mukherjee
2019-04-02 21:03         ` Sudip Mukherjee
2019-04-02 21:03         ` Sudip Mukherjee
2019-03-22  5:17 ` [PATCH v2 6/7] fbdev: sm712fb: Kconfig: add information about docs Yifeng Li
2019-03-22  5:17   ` Yifeng Li
2019-03-31 19:01   ` Sudip Mukherjee
2019-03-31 19:01     ` Sudip Mukherjee
2019-04-01 17:33     ` Tom Li
2019-04-01 17:33       ` Tom Li
2019-03-22  5:17 ` [PATCH v2 7/7] MAINTAINERS: sm712fb: list myself as one maintainer Yifeng Li
2019-03-22  5:17   ` Yifeng Li
2019-03-31 19:08   ` Sudip Mukherjee
2019-03-31 19:08     ` Sudip Mukherjee
2019-03-31 19:08     ` Sudip Mukherjee
2019-04-01 17:41     ` Tom Li
2019-04-01 17:41       ` Tom Li
2019-04-02 21:09       ` Sudip Mukherjee
2019-04-02 21:09         ` Sudip Mukherjee
2019-04-02 21:09         ` Sudip Mukherjee
2019-04-03 13:53         ` Bartlomiej Zolnierkiewicz
2019-04-03 13:53           ` Bartlomiej Zolnierkiewicz
2019-04-05 22:11           ` Sudip Mukherjee
2019-04-05 22:11             ` Sudip Mukherjee
2019-04-05 22:11             ` Sudip Mukherjee

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=20190331183333.kpyt2hm5iy6m5u34@debian \
    --to=sudipm.mukherjee@gmail.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=teddy.wang@siliconmotion.com \
    --cc=tomli@tomli.me \
    /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.