On Mon, Feb 17, 2025 at 11:53:01AM +0100, Amit Shah wrote:
> On Fri, 2025-02-14 at 18:47 +0100, Uwe Kleine-König wrote:
> > On Fri, Feb 14, 2025 at 05:55:41PM +0100, Amit Shah wrote:
> > > On Fri, 2025-02-14 at 17:52 +0100, Uwe Kleine-König wrote:
> > > > Hello Amit
On Fri, Feb 14, 2025 at 05:55:41PM +0100, Amit Shah wrote:
> On Fri, 2025-02-14 at 17:52 +0100, Uwe Kleine-König wrote:
> > Hello Amit,
> >
> > On Fri, Feb 14, 2025 at 05:37:52PM +0100, Amit Shah wrote:
> > > I'm thinking of the two combinations of interest: REM
Hello Amit,
On Fri, Feb 14, 2025 at 05:37:52PM +0100, Amit Shah wrote:
> I'm thinking of the two combinations of interest: REMOTEPROC=m,
> VIRTIO_CONSOLE can be y or m. Say virtcons_probe() happens when the
> remoteproc module isn't yet loaded. Even after later loading
> remoteproc, virtio conso
Hello Amit,
On Fri, Feb 14, 2025 at 02:32:16PM +0100, Amit Shah wrote:
> On Fri, 2025-02-14 at 12:14 +0100, Uwe Kleine-König wrote:
> > On Fri, Feb 14, 2025 at 11:58:44AM +0100, Amit Shah wrote:
> > > On Thu, 2025-02-13 at 12:55 +0100, Uwe Kleine-König wrote:
> > > >
Hello Amit,
On Fri, Feb 14, 2025 at 11:58:44AM +0100, Amit Shah wrote:
> On Thu, 2025-02-13 at 12:55 +0100, Uwe Kleine-König wrote:
> > virtio_console.c can make use of REMOTEPROC. Therefore it has several
> > tests evaluating
> >
> > IS_ENABLED(CONFIG_REMOTEPROC
copes correctly for the
above case as it evaluates to false then.
Signed-off-by: Uwe Kleine-König
---
Hello,
I didn't check what else needs to be done to make CONFIG_REMOTEPROC
tristate but even if it stays a bool using IS_REACHABLE() is still the
better choice.
Best regards
Uwe
drivers
Mon Sep 17 00:00:00 2001
> > From: Vlastimil Babka
> > Date: Tue, 11 Feb 2025 16:16:11 +0100
> > Subject: [PATCH] get_maintainer: add --substatus for reporting subsystem
> > status - fix
> >
> > The automatically enabled --substatus can break existing scripts that do
&
Hello Geert,
On Tue, Feb 11, 2025 at 11:48:13AM +0100, Geert Uytterhoeven wrote:
> On Tue, 11 Feb 2025 at 11:32, Uwe Kleine-König
> wrote:
> > On Mon, Feb 03, 2025 at 12:13:16PM +0100, Vlastimil Babka wrote:
> > > The subsystem status is currently reported with --role(stat
Hello,
On Mon, Feb 03, 2025 at 12:13:16PM +0100, Vlastimil Babka wrote:
> The subsystem status is currently reported with --role(stats) by
> adjusting the maintainer role for any status different from Maintained.
> This has two downsides:
>
> - if a subsystem has only reviewers or mailing lists a
Hello,
On Thu, Nov 14, 2024 at 12:14:16PM +0100, Uwe Kleine-König wrote:
> On 11/14/24 11:49, Werner Sembach wrote:
> > Am 14.11.24 um 11:31 schrieb Uwe Kleine-König:
> > > the kernel modules provided by Tuxedo on
> > > https://gitlab.com/tuxedocomputers/developm
On Sat, Nov 16, 2024 at 09:15:55AM +0100, Daniel Gomez wrote:
> On Fri Nov 15, 2024 at 7:50 PM CET, Werner Sembach wrote:
> > From: Uwe Kleine-König
> >
> > TUXEDO has not yet relicensed a module for GPLv2+ as a reply from former
> > contributers the committed c
Hello Werner,
On Fri, Nov 15, 2024 at 02:03:27PM +0100, Werner Sembach wrote:
> Am 15.11.24 um 13:58 schrieb Werner Sembach:
> > Following the meeting I wrote about yesterday, I now changed the license
> > of what we could change spontaniously to prove good faith.
> >
> > I still hope that the re
Hello Werner,
On Fri, Nov 15, 2024 at 10:40:56AM +0100, Werner Sembach wrote:
> Then why does the proprietary NVIDIA driver exist?
Please don't use NVIDIA's behaviour as a blueprint for your actions.
INAL, but I would not recommend to deduce from "NVIDIA does it and
wasn't tried to stop" (for any
Hello Werner,
On Fri, Nov 15, 2024 at 07:09:49AM +0100, Werner Sembach wrote:
> Am 15.11.24 um 05:43 schrieb Greg KH:
> > On Thu, Nov 14, 2024 at 11:49:04AM +0100, Werner Sembach wrote:
> > > Am 14.11.24 um 11:31 schrieb Uwe Kleine-König:
> > > > the kernel
Hello,
On 11/14/24 11:49, Werner Sembach wrote:
Am 14.11.24 um 11:31 schrieb Uwe Kleine-König:
the kernel modules provided by Tuxedo on
https://gitlab.com/tuxedocomputers/development/packages/tuxedo-drivers
are licensed under GPLv3 or later. This is incompatible with the
kernel's licens
lab.com/tuxedocomputers/development/packages/tuxedo-drivers/-/commit/a8c09b6c2ce6393fe39d8652d133af9f06cfb427
Signed-off-by: Uwe Kleine-König
---
kernel/module/main.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/kernel/module/main.c b/kernel/module/main.c
inde
Instead of repeating the add_taint_module() call for each offender, create
an array and loop over that one. This simplifies adding new entries
considerably.
Signed-off-by: Uwe Kleine-König
---
kernel/module/main.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions
packages/tuxedo-drivers/-/commit/a8c09b6c2ce6393fe39d8652d133af9f06cfb427).
Best regards
Uwe
Uwe Kleine-König (2):
module: Put known GPL offenders in an array
module: Block modules by Tuxedo from accessing GPL symbols
kernel/module/main.c | 56 +---
1 f
Hello Andy, hello Aren,
On Mon, Nov 11, 2024 at 11:44:51AM +0200, Andy Shevchenko wrote:
> On Sun, Nov 10, 2024 at 04:34:30PM -0500, Aren wrote:
> > On Sun, Nov 10, 2024 at 09:52:32PM +0200, Andy Shevchenko wrote:
> > > Sun, Nov 10, 2024 at 02:14:24PM -0500, Aren kirjoitti:
>
> You can do it diff
On Tue, Jul 30, 2024 at 10:39:10AM -0400, Steven Rostedt wrote:
> On Tue, 30 Jul 2024 09:22:53 +0200
> Uwe Kleine-König wrote:
>
> > I think the patch is obvious enough to be ok even without the tracing
> > maintainer's blessing. I applied it to
> > https://git
Hello,
On Fri, Jul 05, 2024 at 11:14:51PM +0200, Uwe Kleine-König wrote:
> The hashed pointer isn't useful to identify the pwm device. Instead
> store and emit chipid and hwpwm.
>
> Signed-off-by: Uwe Kleine-König
> ---
> include/trace/events/pwm.h | 10 ++--
e at all, I think they
> would apply for most regular macros but initcall macros are just way
> different.
>
> Fixes: 061b1bd394ca ("Staging: add TAINT_CRAP for all drivers/staging code")
> Signed-off-by: Ágatha Isabelle Chris Moreira Guedes
I didn't grok
The hashed pointer isn't useful to identify the pwm device. Instead
store and emit chipid and hwpwm.
Signed-off-by: Uwe Kleine-König
---
include/trace/events/pwm.h | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/trace/events/pwm.h b/include/trace/e
Hello Ágatha,
On Tue, Jul 02, 2024 at 02:44:31AM -0300, Ágatha Isabelle Chris Moreira Guedes
wrote:
> ACKNOWLEDGEMENTS
> Thanks for Jookia, heat and ukleinek for the important comments &
> suggestions on this patch prior to submission.
FTR: That happend in the #kernelnewbies irc channel.
> dri
ut
if you can restrict both variables to the for loop, that's nicer.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
On Mon, Apr 19, 2021 at 09:00:07AM +0900, Nobuhiro Iwamatsu wrote:
> Add driver for the PWM controller on Toshiba Visconti ARM SoC.
>
> Signed-off-by: Nobuhiro Iwamatsu
Reviewed-by: Uwe Kleine-König
Thanks for your endurance to improve the driver
Uwe
--
Pengut
writel(pwmc0, priv->base + PIPGM_PWMC(pwm->hwpwm));
> + writel(duty_cycle, priv->base + PIPGM_PDUT(pwm->hwpwm));
> + writel(period, priv->base + PIPGM_PCSR(pwm->hwpwm));
> +
> + return 0;
> +}
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
Hello Thierry,
On Fri, Apr 16, 2021 at 12:45:10PM +0200, Thierry Reding wrote:
> On Fri, Apr 16, 2021 at 11:32:12AM +0200, Uwe Kleine-König wrote:
> > On Thu, Apr 15, 2021 at 06:27:02PM +0200, Thierry Reding wrote:
> > > On Tue, Apr 13, 2021 at 07:56:31PM +0200, Uwe
il if the first regmap_read or the first regmap_write fails.
>
> Signed-off-by: Clemens Gruber
Acked-by: Uwe Kleine-König
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.
ale setting. If there is more than one channel in use,
> the prescale settings resulting from the chosen periods must match.
>
> GPIOs do not count as enabled PWMs as they are not using the prescaler
> and can't change it.
>
> Signed-off-by: Clemens Gruber
Acked-by: Uwe Klei
t; ---
> Changes since v8:
> - As we left the math in apply as-is, use DIV_ROUND_DOWN in get_state
I first thought this was wrong, because .apply uses ROUND_CLOSEST for
period and ROUND_UP for duty. But as the calculation for period is exact
this doesn't matter and round-down is inde
R default (full OFF)
>
> Signed-off-by: Clemens Gruber
(I sent my ack to v8 before, but indeed this was the version I intended
to ack)
Acked-by: Uwe Kleine-König
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions |
e by PWM is not output.
A PWM that is currently configured with .enabled = true and .duty_cycle
= 0 doesn't have a pulse, so this is fine.
> However, I think this means that the device is working as this driver.
I don't understand this sentence.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
il if the first regmap_read or the first regmap_write fails.
>
> Signed-off-by: Clemens Gruber
Acked-by: Uwe Kleine-König
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.
patch could be a tad simpler (by just counting the number
of enabled channels instead of maintaining a bitmap). Still this is
beneficial, so:
Acked-by: Uwe Kleine-König
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions
tches 4 to 8 can probably wait for 5.13 and
> have some time in linux-next.
I'm ok in getting those into next now and than into the upcoming merge
window. That won't make them part of 5.12 however, but 5.13-rc1. IMHO
patches 7 and 8 can go in, too.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
efault (full OFF)
I didn't recheck all details, but the patch is definitively an
improvement, so:
Acked-by: Uwe Kleine-König
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengut
Hello Nobuhiro,
On Fri, Apr 16, 2021 at 05:07:21PM +0900, Nobuhiro Iwamatsu wrote:
> On Mon, Apr 12, 2021 at 09:02:32AM +0200, Uwe Kleine-König wrote:
> > On Mon, Apr 12, 2021 at 11:55:36AM +0900, Nobuhiro Iwamatsu wrote:
> > > On Sat, Apr 10, 2021 at 03:53:21PM +0200, Uwe
Hello Thierry,
On Thu, Apr 15, 2021 at 06:27:02PM +0200, Thierry Reding wrote:
> On Tue, Apr 13, 2021 at 07:56:31PM +0200, Uwe Kleine-König wrote:
> > On Tue, Apr 13, 2021 at 01:51:15PM +0200, Thierry Reding wrote:
> > > On Mon, Apr 12, 2021 at 06:27:23PM +0200, Uwe Kleine-König
ng
Looks right, even though I would prefer to see a patch implementing
.get_state instead (which probably would make use of this function).
Acked-by: Uwe Kleine-König
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux So
ah-Hartman
> Cc: Thierry Reding
> Cc: "Uwe Kleine-König"
> Cc: Lee Jones
> Cc: "David A. Schleef"
> Cc: Mori Hess
> Cc: Truxton Fulton
> Cc: linux-stag...@lists.linux.dev
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Lee Jones
> ---
> dri
On Wed, Apr 14, 2021 at 09:45:32PM +0200, Clemens Gruber wrote:
> On Wed, Apr 14, 2021 at 09:21:31PM +0200, Uwe Kleine-König wrote:
> > On Wed, Apr 14, 2021 at 02:09:14PM +0200, Clemens Gruber wrote:
> > > Hi Uwe,
> > >
> > > On Tue, Apr 13, 2021 at 09:3
On Wed, Apr 14, 2021 at 02:09:14PM +0200, Clemens Gruber wrote:
> Hi Uwe,
>
> On Tue, Apr 13, 2021 at 09:38:18PM +0200, Uwe Kleine-König wrote:
> > Hello Clemens,
> >
> > On Tue, Apr 13, 2021 at 02:11:38PM +0200, Clemens Gruber wrote:
> > > On Mon, Apr 12,
Hello Clemens,
On Tue, Apr 13, 2021 at 02:11:38PM +0200, Clemens Gruber wrote:
> On Mon, Apr 12, 2021 at 10:10:19PM +0200, Uwe Kleine-König wrote:
> > On Mon, Apr 12, 2021 at 06:39:28PM +0200, Clemens Gruber wrote:
> > > On Mon, Apr 12, 2021 at 06:18:08PM +0200, Uwe Kleine-König
On Tue, Apr 13, 2021 at 01:51:15PM +0200, Thierry Reding wrote:
> On Mon, Apr 12, 2021 at 06:27:23PM +0200, Uwe Kleine-König wrote:
> > On Mon, Apr 12, 2021 at 03:27:41PM +0200, Clemens Gruber wrote:
> > > Add the flag and corresponding documentation for PWM_USAGE_POWER.
> &
Hello,
On Mon, Apr 12, 2021 at 06:46:51PM +0200, Clemens Gruber wrote:
> On Mon, Apr 12, 2021 at 06:27:23PM +0200, Uwe Kleine-König wrote:
> > On Mon, Apr 12, 2021 at 03:27:41PM +0200, Clemens Gruber wrote:
> > > Add the flag and corresponding documentation for PWM_USAGE_
Hi Clemens,
On Mon, Apr 12, 2021 at 07:11:58PM +0200, Clemens Gruber wrote:
> On Mon, Apr 12, 2021 at 06:30:45PM +0200, Uwe Kleine-König wrote:
> > On Mon, Apr 12, 2021 at 03:27:43PM +0200, Clemens Gruber wrote:
> > > static unsigned int pca9685_pwm_get_duty(struct
Hello Clemens,
On Mon, Apr 12, 2021 at 06:39:28PM +0200, Clemens Gruber wrote:
> On Mon, Apr 12, 2021 at 06:18:08PM +0200, Uwe Kleine-König wrote:
> > On Mon, Apr 12, 2021 at 03:27:38PM +0200, Clemens Gruber wrote:
> > > The switch to the atomic API goes hand in hand w
+ /* Reset OFF/ON registers to POR default */
> regmap_write(pca->regmap, PCA9685_ALL_LED_OFF_L, LED_FULL);
> regmap_write(pca->regmap, PCA9685_ALL_LED_OFF_H, LED_FULL);
> + regmap_write(pca->regmap, PCA9685_ALL_LED_ON_L, 0);
> + regmap_write(pca->regmap,
there already is.
This is a NAck.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
prescale and
> counter register values.
>
> Also note that although the datasheet mentions 200 Hz as default
> frequency when using the internal 25 MHz oscillator, the calculated
> period from the default prescaler register setting of 30 is 5079040ns.
>
> Signed-off-by: Clemens Grube
ap_write(pca->regmap, PCA9685_PRESCALE, prescale);
>
> - regmap_update_bits(pca->regmap, reg, LED_FULL, 0x0);
> + /* Wake the chip up */
> + pca9685_set_sleep_mode(pca, false);
> + }
>
> + duty = PCA9685_COUNTER_RANGE * state->duty_c
Hello,
On Mon, Apr 12, 2021 at 05:54:54PM +0800, Billy Tsai wrote:
> + - Billy Tsai
I object because the MTA at aspeedtech.com doesn't know this email
address.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux S
priv->chip.dev = dev;
> + priv->chip.ops = &aspeed_pwm_ops;
> + priv->chip.base = -1;
This isn't necessary since f9a8ee8c8bcd118e800d88772c6457381db45224,
please drop the assignment to base.
> + priv->chip.npwm = ASPEED_NR_PWMS;
> + priv->chip.of_xlate = of_pwm_xlate_with_flags;
> + priv->chip.of_pwm_n_cells = 3;
> +
> + ret = pwmchip_add(&priv->chip);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "failed to add PWM chip: %d\n", ret);
Please use %pe to make the error messages better readable.
> + return ret;
> + }
> + dev_set_drvdata(dev, priv);
> + return ret;
> +}
> +
> +static const struct of_device_id of_pwm_match_table[] = {
> + {
> + .compatible = "aspeed,ast2600-pwm",
> + },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, of_pwm_match_table);
> +
> +static struct platform_driver aspeed_pwm_driver = {
> + .probe = aspeed_pwm_probe,
Please implement a .remove callback.
> + .driver = {
> + .name = "aspeed_pwm",
> + .of_match_table = of_pwm_match_table,
> + },
> +};
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
SPEEDG6 PWM support"
No depends?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
On Mon, Apr 12, 2021 at 11:55:36AM +0900, Nobuhiro Iwamatsu wrote:
> Hi Uwe,
>
> Thanks for your review.
>
> On Sat, Apr 10, 2021 at 03:53:21PM +0200, Uwe Kleine-König wrote:
> > Hello,
> >
> > just a few small details left to criticize ...
> >
>
on prefix and so you could rename this
function to visconti_pwm_from_chip or similar.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
ag.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
Hello Thierry,
On Fri, Apr 09, 2021 at 02:27:34PM +0200, Thierry Reding wrote:
> On Wed, Apr 07, 2021 at 07:33:57AM +0200, Uwe Kleine-König wrote:
> > On Tue, Apr 06, 2021 at 06:41:36PM +0200, Clemens Gruber wrote:
> > > Add the flag and corresponding documentation for the
pwmchip_remove will always return 0 since b2c200e3f2fd which is in v5.3.
So Thierry's suggestion is safe and indeed welcome.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
m = 4;
> +
> + ret = pwmchip_add(&priv->chip);
> + if (ret < 0)
> + return dev_err_probe(&pdev->dev, ret, "Cannot register visconti
> PWM\n");
Thierry told to have picked up my patch to add the function
devm_pwmchip_add. I just double checked and it didn't made it into his
for-next branch yet. When you respin this series please check if the
patch landed in the mean time and then make use of it.
> + return 0;
> +}
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
On Fri, Apr 09, 2021 at 02:24:43PM +0200, Thierry Reding wrote:
> On Tue, Apr 06, 2021 at 12:27:56PM +0200, Uwe Kleine-König wrote:
> > On Tue, Apr 06, 2021 at 05:57:42PM +0800, Rex-BC Chen wrote:
> > > implement get_state function for pwm-mtk-disp
> > >
>
Hello Thierry,
On Fri, Apr 09, 2021 at 01:25:36PM +0200, Thierry Reding wrote:
> On Thu, Apr 08, 2021 at 07:36:37PM +0200, Uwe Kleine-König wrote:
> > On Thu, Apr 08, 2021 at 05:51:36PM +0200, Clemens Gruber wrote:
> > > On Thu, Apr 08, 2021 at 02:50:40PM +0200, Thierry Reding
han
.period = 20
.duty_cycle = 5
would also be an allowed response for the request
.period = 200
.duty_cycle = 50
and this is not what is in the focus here.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
aracters per line has been changed to
> 100 characters. Does the pwm driver recommend 80 characters?
For free-text comments I'd still recommend 80, yes. For code lines I'd
be indeed more lax, as a line break in function calls reduces readability.
Best regards
Uwe
--
Pengutronix e.K.
Hello Clemens,
On Wed, Apr 07, 2021 at 10:47:45PM +0200, Clemens Gruber wrote:
> On Wed, Apr 07, 2021 at 08:16:19AM +0200, Uwe Kleine-König wrote:
> > You didn't check all return codes? How did you select the calls to
> > check?
>
> No, because it would become a bi
On Wed, Apr 07, 2021 at 10:41:27PM +0200, Clemens Gruber wrote:
> On Wed, Apr 07, 2021 at 08:12:29AM +0200, Uwe Kleine-König wrote:
> > On Tue, Apr 06, 2021 at 06:41:39PM +0200, Clemens Gruber wrote:
> > > Previously, the last used PWM channel could change the global prescale
&
On Wed, Apr 07, 2021 at 10:21:10PM +0200, Clemens Gruber wrote:
> On Wed, Apr 07, 2021 at 07:46:58AM +0200, Uwe Kleine-König wrote:
> > On Tue, Apr 06, 2021 at 06:41:37PM +0200, Clemens Gruber wrote:
> > > If the flag PWM_STAGGERING_ALLOWED is set on a channel, the PWM dr
On Wed, Apr 07, 2021 at 09:33:20AM +0200, Clemens Gruber wrote:
> On Wed, Apr 07, 2021 at 07:31:35AM +0200, Uwe Kleine-König wrote:
> > On Tue, Apr 06, 2021 at 06:41:34PM +0200, Clemens Gruber wrote:
> > > Implements .get_state to read-out the current hardware state.
> &g
pwm_set_duty(struct pca9685 *pca,
> int channel, unsigned int
>
> if (duty == 0) {
> /* Set the full OFF bit, which has the highest precedence */
> - regmap_write(pca->regmap, REG_OFF_H(channel), LED_FULL);
> + pca9685_write_reg(pca,
channel is correct
here. But given that it is messy anyhow, (e.g. because setting some
state to this set-all channel doesn't influence pwm_get_state for the
individual channels) I don't object if there is another problem in this
corner case. IMHO just dropping this virtual channel would be nice.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
tive.
Another objection I have is that we already have some technical debt
because there are already two different types of drivers (.apply vs
.config+.set_polarity+.enable+.disable) and I would like to unify this
first before introducing new stuff.
Best regards
Uwe
--
Pengutronix e.K.
ggering explicit for the consumer by expanding struct pwm_state with
an .offset member to shift the active phase in the period.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.d
period,
PCA9685_COUNTER_RANGE);
(I'm using round-up here assuming apply uses round-down to get
idempotency. In the current patch set state this is wrong however.)
> +}
> +
> static int pca9685_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
> {
> struct pca9685 *pca = to_pca(chip);
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
_ALL_LED_OFF_L;
> - else
> - reg = LED_N_OFF_L(pwm->hwpwm);
> -
> - regmap_write(pca->regmap, reg, 0x0);
> -}
> -
> static int pca9685_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
> {
> struct pca9685 *pca = to_pca(chip);
> @@
Hello Thierry,
On Tue, Apr 06, 2021 at 03:47:15PM +0200, Thierry Reding wrote:
> On Tue, Apr 06, 2021 at 08:33:57AM +0200, Uwe Kleine-König wrote:
> > On Wed, Mar 31, 2021 at 05:52:45PM +0200, Thierry Reding wrote:
> > > On Wed, Mar 31, 2021 at 12:25:43PM +0200, Uwe Kleine-König
Hello Thierry,
On Tue, Apr 06, 2021 at 01:16:31PM +0200, Thierry Reding wrote:
> On Tue, Apr 06, 2021 at 09:30:36AM +0200, Uwe Kleine-König wrote:
> > Given that lowlevel drivers usually cannot implement exactly what a
> > consumer requests with pwm_apply_state() there is some ro
clk_disable_unprepare(mdp->clk_mm);
> + clk_disable_unprepare(mdp->clk_main);
That's wrong, you enabled unconditionally so you should also disable
unconditionally. If you want to prevent that clocks of a running PWM are
disabled by the unused clk initc
clk_div << PWM_CLKDIV_SHIFT);
> + mtk_disp_pwm_update_bits(mdp, mdp->data->con0,
> + PWM_POLARITY, polarity);
> mtk_disp_pwm_update_bits(mdp, mdp->data->con1,
>PWM_PERIOD_MASK | PWM_HIGH_WIDTH_MASK,
>value);
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
ch applied? If not, please
rearrange and order this patch after the conversion to the atomic API.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
in reply to the last request). To make this semantic obvious
rename the function.
Signed-off-by: Uwe Kleine-König
---
Documentation/driver-api/pwm.rst | 6 +++-
drivers/clk/clk-pwm.c | 2 +-
drivers/gpu/drm/i915/display/intel_panel.c | 4 +--
drivers/input/misc
Hello Thierry,
On Wed, Mar 31, 2021 at 05:52:45PM +0200, Thierry Reding wrote:
> On Wed, Mar 31, 2021 at 12:25:43PM +0200, Uwe Kleine-König wrote:
> > On Mon, Mar 22, 2021 at 09:34:21AM +0100, Thierry Reding wrote:
> > > On Mon, Jan 11, 2021 at 09:43:50PM +0100, Uwe Kleine-König
On Wed, Mar 31, 2021 at 02:26:14PM +0200, Clemens Gruber wrote:
> On Mon, Mar 29, 2021 at 08:02:06PM +0200, Uwe Kleine-König wrote:
> > On Mon, Mar 29, 2021 at 07:16:38PM +0200, Clemens Gruber wrote:
> > > On Mon, Mar 29, 2021 at 07:03:57PM +0200, Uwe Kleine-König wrote:
>
h would need an ack by the dt guys, so you should Cc: them in
the next round if this (or a similar) patch is still part of the series.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www
k the end result is rechnically superior to the
approach suggested in the patch under discussion.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
On Wed, Mar 31, 2021 at 03:55:49PM +0200, Clemens Gruber wrote:
> On Wed, Mar 31, 2021 at 02:26:14PM +0200, Clemens Gruber wrote:
> > On Mon, Mar 29, 2021 at 08:02:06PM +0200, Uwe Kleine-König wrote:
> > > On Mon, Mar 29, 2021 at 07:16:38PM +0200, Clemens Gruber wrote:
> >
Hello Clemens,
On Wed, Mar 31, 2021 at 02:26:14PM +0200, Clemens Gruber wrote:
> On Mon, Mar 29, 2021 at 08:02:06PM +0200, Uwe Kleine-König wrote:
> > On Mon, Mar 29, 2021 at 07:16:38PM +0200, Clemens Gruber wrote:
> > > On Mon, Mar 29, 2021 at 07:03:57PM +0200, Uwe Kleine-König
Hello Thierry,
On Mon, Mar 22, 2021 at 09:34:21AM +0100, Thierry Reding wrote:
> On Mon, Jan 11, 2021 at 09:43:50PM +0100, Uwe Kleine-König wrote:
> > On Sun, Jan 03, 2021 at 06:04:10PM +0100, Clemens Gruber wrote:
> > > Another point is the period: Sven suggested we d
On Mon, Mar 29, 2021 at 07:16:38PM +0200, Clemens Gruber wrote:
> On Mon, Mar 29, 2021 at 07:03:57PM +0200, Uwe Kleine-König wrote:
> > On Mon, Mar 29, 2021 at 02:57:04PM +0200, Clemens Gruber wrote:
> > > The PCA9685 supports staggered LED output ON times to minimize curren
Hello Clemens,
On Mon, Mar 29, 2021 at 07:33:56PM +0200, Clemens Gruber wrote:
> On Mon, Mar 29, 2021 at 07:15:59PM +0200, Uwe Kleine-König wrote:
> > On Mon, Mar 29, 2021 at 02:57:06PM +0200, Clemens Gruber wrote:
> > > @@ -330,14 +345,22 @@ static int pca9685_pwm_apply(str
On Mon, Mar 29, 2021 at 07:11:53PM +0200, Clemens Gruber wrote:
> On Mon, Mar 29, 2021 at 06:54:29PM +0200, Uwe Kleine-König wrote:
> > On Mon, Mar 29, 2021 at 02:57:02PM +0200, Clemens Gruber wrote:
> > > [...]
> > > + /* Calculate (chip-wide) period from prescale value
channel modifies the
period and I won't be able to return to the initial setting.
So I think it's sensible to only clear the user bit if the PWM is
disabled, but not if it is configured for duty_cycle = 0.
Does this make sense?
Best regards
Uwe
--
Pengutronix e.K.
perty.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
ounding errors. So if you feed the state returned here into .apply
again, there is (as I want it) no change.
The only annoyance is that if PCA9685_PRESCALE holds a value smaller
than 3, .apply() will fail. Not sure there is any saner way to handle
this.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
->dev);
>
> + if (!IS_ENABLED(CONFIG_PM)) {
> + /* Wake the chip up on non-PM environments */
> + pca9685_set_sleep_mode(pca, false);
I admit I didn't grasp all the PM framework details, but I wonder if
it's right to first call set_sleep_m
re that's not preventable. My
requirement here is that
.get_state(pwm, &state);
.apply_state(pwm, &state);
doesn't yield any changes.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Soluti
Hello Sebastian,
On Tue, Mar 23, 2021 at 10:04:13AM +0100, Sebastian Andrzej Siewior wrote:
> On 2021-03-23 08:34:47 [+0100], Uwe Kleine-König wrote:
> > On Mon, Mar 22, 2021 at 09:48:36PM +0100, Sebastian Andrzej Siewior wrote:
> > > On 2021-03-22 14:40:32 [+0100], Uwe
Hello Johan,
On Tue, Mar 23, 2021 at 03:37:29PM +0100, Johan Hovold wrote:
> On Mon, Mar 22, 2021 at 02:40:32PM +0100, Uwe Kleine-König wrote:
> > On Mon, Mar 22, 2021 at 02:20:57PM +0100, Johan Hovold wrote:
> > > On Mon, Mar 22, 2021 at 12:55:36PM +0100, Uwe Kleine-König wro
Hello Sebastian,
On Mon, Mar 22, 2021 at 09:48:36PM +0100, Sebastian Andrzej Siewior wrote:
> On 2021-03-22 14:40:32 [+0100], Uwe Kleine-König wrote:
> > From a strictly logically point of view you indeed cannot. But if you go
> > to the street and say to people there that they can
Hello,
On Mon, Mar 01, 2021 at 02:50:50PM +0100, Uwe Kleine-König wrote:
> Uwe Kleine-König (3):
> clk: generalize devm_clk_get() a bit
> clk: Provide new devm_clk_helpers for prepared and enabled clocks
> pwm: atmel: Simplify using devm_clk_get_prepared()
>
> driver
1 - 100 of 1020 matches
Mail list logo
