linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Duje Mihanović" <duje.mihanovic@skole.hr>
To: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Lee Jones <lee@kernel.org>, Jingoo Han <jingoohan1@gmail.com>,
	Pavel Machek <pavel@ucw.cz>, Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>, Helge Deller <deller@gmx.de>,
	Karel Balej <balejk@matfyz.cz>,
	dri-devel@lists.freedesktop.org, linux-leds@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-fbdev@vger.kernel.org,
	~postmarketos/upstreaming@lists.sr.ht
Subject: Re: [PATCH 2/2] backlight: Add Kinetic KTD2801 driver
Date: Mon, 09 Oct 2023 17:08:59 +0200	[thread overview]
Message-ID: <2914963.e9J7NaK4W3@radijator> (raw)
In-Reply-To: <20231009092103.GB96854@aspen.lan>

On Monday, October 9, 2023 11:21:03 AM CEST Daniel Thompson wrote:
> On Thu, Oct 05, 2023 at 08:49:09PM +0200, Duje Mihanović wrote:
> > +#define EW_DELAY	150
> > +#define EW_DET		270
> > +#define LOW_BIT_HIGH	5
> > +#define LOW_BIT_LOW	(4 * HIGH_BIT_LOW)
> > +#define HIGH_BIT_LOW	5
> > +#define HIGH_BIT_HIGH	(4 * HIGH_BIT_LOW)
> 
> These names are pretty cryptic (they don't even mention that they
> are time values and that the unit is microseconds). They also look
> like they were derived by tuning so comments would be nice explaining
> where they come from (or, failing that, why they are correct).

These values are taken from Samsung's driver, which themselves are datasheet 
values with a couple of us added for I presume safety. The datasheet is 
publicly available [1] and I can add a link to it to the binding patch in v2.

> > +	if (!ktd2801->was_on) {
> > +		gpiod_set_value(ktd2801->desc, 0);
> > +		udelay(EW_DELAY);
> > +		gpiod_set_value(ktd2801->desc, 1);
> > +		udelay(EW_DET);
> > +		gpiod_set_value(ktd2801->desc, 0);
> > +		ktd2801->was_on = true;
> > +	}
> 
> Isn't this implementing the same single GPIO line protocol used by
> drivers/leds/flash/leds-ktd2692.c?
> 
> If so, it would be good to pull the expresswire handling into a library
> so it can be shared between drivers. leds-ktd2692.c does a pretty
> good job of decomposing the expresswire management into functions (e.g.
> separating data framing from setting of control values). Expresswire is
> a data framing protocol rather than a bus so I think just implementing
> it as library code is probably sufficient.

KTD2801 and 2692 indeed seem to share the protocol and I can write a library 
just for this. I believe such a library could go in drivers/leds/leds-
expresswire.c and include/linux/leds-expresswire.h (or perhaps even just in a 
header), do you have any better ideas?

> Also, can the expresswire code have protocol-violation watchdogs that
> trigger a re-transmit of the message if we get pre-empted in the middle
> of sending a message to the backlight (see calls to ktime_get_ns() in
> ktd253-backlight.c ).

The Samsung driver does not have such watchdogs, but if you think they are 
needed I can add them.

[1] https://www.mouser.com/datasheet/2/936/KTD2801-04b-1391831.pdf

Regards,
Duje




  reply	other threads:[~2023-10-09 15:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-05 18:49 [PATCH 0/2] Kinetic KTD2801 backlight driver Duje Mihanović
2023-10-05 18:49 ` [PATCH 1/2] dt-bindings: backlight: add Kinetic KTD2801 binding Duje Mihanović
2023-10-05 20:37   ` Krzysztof Kozlowski
2023-10-06 12:30   ` Daniel Thompson
2023-10-06 13:08     ` Duje Mihanović
2023-10-09  9:29       ` Daniel Thompson
2023-10-05 18:49 ` [PATCH 2/2] backlight: Add Kinetic KTD2801 driver Duje Mihanović
2023-10-05 20:40   ` Krzysztof Kozlowski
2023-10-06 13:11     ` Duje Mihanović
2023-10-09  9:21   ` Daniel Thompson
2023-10-09 15:08     ` Duje Mihanović [this message]
2023-10-10 17:20   ` kernel test robot
2023-10-19  1:14   ` kernel test robot

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=2914963.e9J7NaK4W3@radijator \
    --to=duje.mihanovic@skole.hr \
    --cc=balejk@matfyz.cz \
    --cc=conor+dt@kernel.org \
    --cc=daniel.thompson@linaro.org \
    --cc=deller@gmx.de \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jingoohan1@gmail.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lee@kernel.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=robh+dt@kernel.org \
    --cc=~postmarketos/upstreaming@lists.sr.ht \
    /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).