All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: "Maíra Canal" <maira.canal@usp.br>
Cc: Sean Young <sean@mess.org>, kernel test robot <lkp@intel.com>,
	mchehab@kernel.org, thierry.reding@gmail.com,
	Lee Jones <lee.jones@linaro.org>,
	llvm@lists.linux.dev, kbuild-all@lists.01.org,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-pwm@vger.kernel.org
Subject: Re: [PATCH v4] media: rc: pwm-ir-tx: Switch to atomic PWM API
Date: Fri, 29 Oct 2021 17:18:15 +0200	[thread overview]
Message-ID: <20211029151815.kn4ya7sk2bsrcrwo@pengutronix.de> (raw)
In-Reply-To: <CAH7FV3njgZ7sOnZZF88KZ2C4UwqxoodpUuLsnucvBxYXmaZo1Q@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2262 bytes --]

Hello,

On Fri, Oct 29, 2021 at 09:08:29AM -0300, Maíra Canal wrote:
> I would like to thank you guys for the attention and this interesting
> discussion. I'm looking for some work in the kernel and I would like
> to know if you guys have any suggestions for beginner tasks in this
> subsystem. I have solid knowledge in C programming, but I started in
> the kernel a couple of weeks ago. Anyway, thank you for all the
> feedback.

If you want something mathematically demanding, you can pick up the
patch I pointed out to Sean, I think I won't find the time in the near
future to work on this.

The background is that PWM drivers have to round most requests and there
is no uniformity among drivers and so if a consumer (e.g. the pwm-ir
driver) requests say 20000 ns, it will get 18000 from some drivers and
maybe 25000 from others. So the idea is to have a function
pwm_round_state that has fixed rounding rules such that a consumer can
pick the best setting for their use-case.

Something more mechanic in the PWM area is to convert drivers that still
implement .config/.enable/.disable to .apply. See
http://patchwork.ozlabs.org/project/linux-pwm/patch/20211029105617.210178-1-u.kleine-koenig@pengutronix.de/
for an example. The well-known good template is pwm_apply_legacy() after
applying
http://patchwork.ozlabs.org/project/linux-pwm/list/?series=251456 .

If you want something more global: The prototype of the remove callbacks
for platform devices returns an int:

	https://elixir.bootlin.com/linux/v5.15-rc7/source/include/linux/platform_device.h#L206

However the returned value is (nearly) ignored by the driver core:

	https://elixir.bootlin.com/linux/v5.15-rc7/source/drivers/base/platform.c#L1433

The longterm goal is to change the prototype of .remove to return void.
As a first step making all functions return 0 is a worthwile project.

The same problem exists for several other buses, one patch I sent to
work on this goal for i2c is:

	https://lore.kernel.org/r/20211021105657.72572-1-u.kleine-koenig@pengutronix.de

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
To: kbuild-all@lists.01.org
Subject: Re: [PATCH v4] media: rc: pwm-ir-tx: Switch to atomic PWM API
Date: Fri, 29 Oct 2021 17:18:15 +0200	[thread overview]
Message-ID: <20211029151815.kn4ya7sk2bsrcrwo@pengutronix.de> (raw)
In-Reply-To: <CAH7FV3njgZ7sOnZZF88KZ2C4UwqxoodpUuLsnucvBxYXmaZo1Q@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2268 bytes --]

Hello,

On Fri, Oct 29, 2021 at 09:08:29AM -0300, Maíra Canal wrote:
> I would like to thank you guys for the attention and this interesting
> discussion. I'm looking for some work in the kernel and I would like
> to know if you guys have any suggestions for beginner tasks in this
> subsystem. I have solid knowledge in C programming, but I started in
> the kernel a couple of weeks ago. Anyway, thank you for all the
> feedback.

If you want something mathematically demanding, you can pick up the
patch I pointed out to Sean, I think I won't find the time in the near
future to work on this.

The background is that PWM drivers have to round most requests and there
is no uniformity among drivers and so if a consumer (e.g. the pwm-ir
driver) requests say 20000 ns, it will get 18000 from some drivers and
maybe 25000 from others. So the idea is to have a function
pwm_round_state that has fixed rounding rules such that a consumer can
pick the best setting for their use-case.

Something more mechanic in the PWM area is to convert drivers that still
implement .config/.enable/.disable to .apply. See
http://patchwork.ozlabs.org/project/linux-pwm/patch/20211029105617.210178-1-u.kleine-koenig(a)pengutronix.de/
for an example. The well-known good template is pwm_apply_legacy() after
applying
http://patchwork.ozlabs.org/project/linux-pwm/list/?series=251456 .

If you want something more global: The prototype of the remove callbacks
for platform devices returns an int:

	https://elixir.bootlin.com/linux/v5.15-rc7/source/include/linux/platform_device.h#L206

However the returned value is (nearly) ignored by the driver core:

	https://elixir.bootlin.com/linux/v5.15-rc7/source/drivers/base/platform.c#L1433

The longterm goal is to change the prototype of .remove to return void.
As a first step making all functions return 0 is a worthwile project.

The same problem exists for several other buses, one patch I sent to
work on this goal for i2c is:

	https://lore.kernel.org/r/20211021105657.72572-1-u.kleine-koenig(a)pengutronix.de

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2021-10-29 15:18 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-27 15:34 [PATCH v4] media: rc: pwm-ir-tx: Switch to atomic PWM API Maíra Canal
2021-10-27 15:34 ` Maíra Canal
2021-10-28  6:45 ` Uwe Kleine-König
2021-10-28  6:45   ` Uwe Kleine-König
2021-10-28  9:14   ` Sean Young
2021-10-28  9:14     ` Sean Young
2021-10-28 11:15     ` Uwe Kleine-König
2021-10-28 11:15       ` Uwe Kleine-König
2021-10-28 12:26       ` Sean Young
2021-10-28 12:26         ` Sean Young
2021-10-28 18:05         ` Uwe Kleine-König
2021-10-28 18:05           ` Uwe Kleine-König
2021-10-29  7:16           ` Sean Young
2021-10-29  7:16             ` Sean Young
2021-10-29 11:06             ` Uwe Kleine-König
2021-10-29 11:06               ` Uwe Kleine-König
2021-10-29 11:54               ` Sean Young
2021-10-29 11:54                 ` Sean Young
2021-10-29 12:08                 ` Maíra Canal
2021-10-29 12:08                   ` Maíra Canal
2021-10-29 15:18                   ` Uwe Kleine-König [this message]
2021-10-29 15:18                     ` Uwe Kleine-König
2021-10-30  9:21                   ` Sean Young
2021-10-30  9:21                     ` Sean Young
2021-10-31 10:39       ` Sean Young
2021-10-31 17:40         ` Uwe Kleine-König

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=20211029151815.kn4ya7sk2bsrcrwo@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --cc=kbuild-all@lists.01.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=llvm@lists.linux.dev \
    --cc=maira.canal@usp.br \
    --cc=mchehab@kernel.org \
    --cc=sean@mess.org \
    --cc=thierry.reding@gmail.com \
    /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.