public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Javier Martinez Canillas <javierm@redhat.com>
Cc: linux-kernel@vger.kernel.org,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Noralf Trønnes" <noralf@tronnes.org>,
	"Maxime Ripard" <maxime@cerno.tech>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	linux-fbdev@vger.kernel.org,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Sam Ravnborg" <sam@ravnborg.org>,
	dri-devel@lists.freedesktop.org,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"David Airlie" <airlied@linux.ie>,
	"Lee Jones" <lee.jones@linaro.org>,
	"Liam Girdwood" <lgirdwood@gmail.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Mark Brown" <broonie@kernel.org>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	linux-pwm@vger.kernel.org
Subject: Re: [PATCH v3 3/7] drm: Add driver for Solomon SSD130X OLED displays
Date: Wed, 9 Feb 2022 17:12:29 +0200	[thread overview]
Message-ID: <YgPZ3W0e7N7JQ1dT@smile.fi.intel.com> (raw)
In-Reply-To: <20220209090314.2511959-4-javierm@redhat.com>

On Wed, Feb 09, 2022 at 10:03:10AM +0100, Javier Martinez Canillas wrote:
> This adds a DRM driver for SSD1305, SSD1306, SSD1307 and SSD1309 Solomon
> OLED display controllers.
> 
> It's only the core part of the driver and a bus specific driver is needed
> for each transport interface supported by the display controllers.

Thank you for the update, my comments below.

...

>  source "drivers/gpu/drm/sprd/Kconfig"
>  
> +source "drivers/gpu/drm/solomon/Kconfig"

'o' before 'p' ?

...

>  obj-$(CONFIG_DRM_SPRD) += sprd/
> +obj-y			+= solomon/

Ditto ?

...

> +/*
> + * DRM driver for Solomon SSD130X OLED displays

Solomon SSD130x (with lower letter it's easy to read and realize that it's
not a model name).

> + * Copyright 2022 Red Hat Inc.
> + * Authors: Javier Martinez Canillas <javierm@redhat.com>
> + *
> + * Based on drivers/video/fbdev/ssd1307fb.c
> + * Copyright 2012 Free Electrons
> + */

> +#include <linux/backlight.h>
> +#include <linux/delay.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/property.h>
> +#include <linux/pwm.h>
> +#include <linux/regulator/consumer.h>

...

> +#define DRIVER_NAME	"ssd130x"
> +#define DRIVER_DESC	"DRM driver for Solomon SSD130X OLED displays"
> +#define DRIVER_DATE	"20220131"
> +#define DRIVER_MAJOR	1
> +#define DRIVER_MINOR	0

Not sure it has a value when being defined. Only one string is reused and even
if hard coded twice linker will optimize it.

...

> +/*
> + * Helper to write command (SSD130X_COMMAND). The fist variadic argument
> + * is the command to write and the following are the command options.
> + */
> +static int ssd130x_write_cmd(struct ssd130x_device *ssd130x, int count,
> +				    /* u8 cmd, u8 option, ... */...)
> +{
> +	va_list ap;
> +	u8 value;
> +	int ret;
> +
> +	va_start(ap, count);
> +
> +	do {
> +		value = va_arg(ap, int);
> +		ret = regmap_write(ssd130x->regmap, SSD130X_COMMAND, (u8)value);
> +		if (ret)
> +			goto out_end;
> +	} while (--count);
> +
> +out_end:
> +	va_end(ap);
> +
> +	return ret;

Can bulk operation be used in the callers instead?

I have noticed that all of the callers are using
- 1 -- makes no sense at all, can be replaced with regmap_write()
- 2
- 3

Can be helpers for two and three arguments, with use of bulk call.

What do you think?

> +}

...

> +static void ssd130x_reset(struct ssd130x_device *ssd130x)
> +{
> +	/* Reset the screen */
> +	gpiod_set_value_cansleep(ssd130x->reset, 1);
> +	udelay(4);
> +	gpiod_set_value_cansleep(ssd130x->reset, 0);
> +	udelay(4);

I don't remember if reset pin is mandatory. fbtft does

	if (!gpiod->reset)
		return;

	...do reset...

> +}

...

> +	if (ssd130x->reset)

A-ha, why not in the callee?

> +		ssd130x_reset(ssd130x);

...

> +	/* Set COM direction */
> +	com_invdir = 0xc0 | ssd130x->com_invdir << 3;

Can 0xc0 and 3 be GENMASK()'ed and defined?

...

> +	/* Set clock frequency */
> +	dclk = ((ssd130x->dclk_div - 1) & 0xf) | (ssd130x->dclk_frq & 0xf) << 4;

GENMASK() ?

...

> +		u32 mode = ((ssd130x->area_color_enable ? 0x30 : 0) |
> +			    (ssd130x->low_power ? 5 : 0));

With if's it will look better.

		u32 mode = 0;

		if (ssd130x->area_color_enable)
			mode |= 0x30;
		if (ssd130x->low_power)
			mode |= 5;

...

> +	/* Turn on the DC-DC Charge Pump */
> +	chargepump = BIT(4) | (ssd130x->device_info->need_chargepump ? BIT(2) : 0);

Ditto.

...

> +		for (i = 0; i < ARRAY_SIZE(ssd130x->lookup_table); ++i) {

i++ should work as well.

> +			u8 val = ssd130x->lookup_table[i];
> +
> +			if (val < 31 || val > 63)
> +				dev_warn(ssd130x->dev,
> +					 "lookup table index %d value out of range 31 <= %d <= 63\n",
> +					 i, val);
> +			ret = ssd130x_write_cmd(ssd130x, 1, val);
> +			if (ret < 0)
> +				return ret;
> +		}

...

> +	u8 *buf = NULL;

> +

Redundant blank line, not sure if checkpatch catches this.

> +	struct drm_rect fullscreen = {
> +		.x1 = 0,
> +		.x2 = ssd130x->width,
> +		.y1 = 0,
> +		.y2 = ssd130x->height,
> +	};

...

> +power_off:

out_power_off: ?

...

> +		ret = PTR_ERR(ssd130x->vbat_reg);
> +		if (ret == -ENODEV)
> +			ssd130x->vbat_reg = NULL;
> +		else
> +			return dev_err_probe(dev, ret, "Failed to get VBAT regulator\n");

Can it be

		ret = PTR_ERR(ssd130x->vbat_reg);
		if (ret != -ENODEV)
			return dev_err_probe(dev, ret, "Failed to get VBAT regulator\n");

		ssd130x->vbat_reg = NULL;

?

...

> +	ssd130x = devm_drm_dev_alloc(dev, &ssd130x_drm_driver,
> +				     struct ssd130x_device, drm);
> +	if (IS_ERR(ssd130x)) {

> +		dev_err(dev, "Failed to allocate DRM device: %d\n", ret);
> +		return ssd130x;

return dev_err_probe() ?

> +	}

...

> +	bl = devm_backlight_device_register(dev, dev_name(dev), dev, ssd130x,
> +					    &ssd130xfb_bl_ops, NULL);
> +	if (IS_ERR(bl)) {
> +		ret = PTR_ERR(bl);
> +		dev_err(dev, "Unable to register backlight device: %d\n", ret);
> +		return ERR_PTR(ret);

Ditto.

> +	}

...

> +	ret = drm_dev_register(drm, 0);
> +	if (ret) {
> +		dev_err(dev, "DRM device register failed: %d\n", ret);
> +		return ERR_PTR(ret);

Ditto.

> +	}

...

I have feelings that half of my comments were ignored...
Maybe I missed the discussion(s).


-- 
With Best Regards,
Andy Shevchenko



  parent reply	other threads:[~2022-02-09 15:13 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-09  9:03 [PATCH v3 0/7] drm: Add driver for Solomon SSD130X OLED displays Javier Martinez Canillas
2022-02-09  9:03 ` [PATCH v3 1/7] drm/format-helper: Add drm_fb_xrgb8888_to_gray8_line() Javier Martinez Canillas
2022-02-09  9:03 ` [PATCH v3 2/7] drm/format-helper: Add drm_fb_{xrgb8888,gray8}_to_mono_reversed() Javier Martinez Canillas
2022-02-09 12:51   ` [PATCH v3 2/7] drm/format-helper: Add drm_fb_{xrgb8888, gray8}_to_mono_reversed() Thomas Zimmermann
2022-02-09 13:26     ` Javier Martinez Canillas
2022-02-09 15:21       ` Thomas Zimmermann
2022-02-09 15:30         ` Javier Martinez Canillas
2022-02-09  9:03 ` [PATCH v3 3/7] drm: Add driver for Solomon SSD130X OLED displays Javier Martinez Canillas
2022-02-09 13:43   ` Mark Brown
2022-02-09 14:17     ` Javier Martinez Canillas
2022-02-09 14:22       ` Mark Brown
2022-02-09 14:50         ` Javier Martinez Canillas
2022-02-09 15:03           ` Mark Brown
2022-02-09 15:17             ` Javier Martinez Canillas
2022-02-09 15:12   ` Andy Shevchenko [this message]
2022-02-09 15:54     ` Javier Martinez Canillas
2022-02-09 16:08       ` Andy Shevchenko
2022-02-09 16:26         ` Javier Martinez Canillas
2022-02-09 16:44           ` Andy Shevchenko
2022-02-11  8:54           ` Javier Martinez Canillas
2022-02-09  9:03 ` [PATCH v3 4/7] drm/solomon: Add SSD130X OLED displays I2C support Javier Martinez Canillas
2022-02-09 12:21   ` Geert Uytterhoeven
2022-02-09 12:41     ` Javier Martinez Canillas
2022-02-09 15:15   ` Andy Shevchenko
2022-02-09 16:05     ` Javier Martinez Canillas
2022-02-09  9:12 ` [PATCH v3 5/7] (WIP) drm/solomon: Add SSD130X OLED displays SPI support Javier Martinez Canillas
2022-02-09 12:25   ` Geert Uytterhoeven
2022-02-09 13:04     ` Javier Martinez Canillas
2022-02-09 15:19       ` Andy Shevchenko
2022-02-09 16:10         ` Javier Martinez Canillas
2022-02-09 15:17     ` Andy Shevchenko
2022-02-09 16:07       ` Javier Martinez Canillas
2022-02-09 16:25         ` Geert Uytterhoeven
2022-02-09 16:41           ` Andy Shevchenko
2022-02-09 17:04             ` Javier Martinez Canillas
2022-02-09 16:56           ` Javier Martinez Canillas
2022-02-09 16:40         ` Andy Shevchenko
2022-02-09 15:16   ` Andy Shevchenko
2022-02-09 16:05     ` Javier Martinez Canillas
2022-02-09  9:13 ` [PATCH v3 6/7] MAINTAINERS: Add entry for Solomon SSD130X OLED displays DRM driver Javier Martinez Canillas
2022-02-09  9:13 ` [PATCH v3 7/7] dt-bindings: display: ssd1307fb: Add myself as binding co-maintainer Javier Martinez Canillas
2022-02-09 12:19 ` [PATCH v3 0/7] drm: Add driver for Solomon SSD130X OLED displays Geert Uytterhoeven
2022-02-09 12:37   ` Javier Martinez Canillas
2022-02-11  8:45     ` Javier Martinez Canillas
2022-02-10 17:06   ` Geert Uytterhoeven
2022-02-10 17:55     ` Javier Martinez Canillas

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=YgPZ3W0e7N7JQ1dT@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=airlied@linux.ie \
    --cc=broonie@kernel.org \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=geert@linux-m68k.org \
    --cc=javierm@redhat.com \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=maxime@cerno.tech \
    --cc=mripard@kernel.org \
    --cc=noralf@tronnes.org \
    --cc=sam@ravnborg.org \
    --cc=thierry.reding@gmail.com \
    --cc=tzimmermann@suse.de \
    --cc=u.kleine-koenig@pengutronix.de \
    /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