r
the individual drivers.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/Kconfig | 5 -
drivers/gpu/drm/ast/Kconfig | 2 ++
drivers/gpu/drm/gma500/Kconfig | 2 ++
drivers/gpu/drm/hisilicon/hibmc/Kconfig | 2 ++
drivers/gpu/drm/i915/Kconfig
256.html
I have problems understanding this mail, but I assume that my patch is
not the problem here as these are all runtime errors if I'm not
mistaken. If my patch has a problem it should result in a build failure
instead. Am I missing something?
Best regards
Uwe
--
Peng
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 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
Hello,
On Fri, May 14, 2021 at 12:01:42PM +0200, Uwe Kleine-König wrote:
> While working on a drm driver that doesn't need the i2c algobit stuff I
> noticed that DRM selects this code even tough only 8 drivers actually use
> it. While also only some drivers use i2c, keep the sele
state->duty_cycle = duty_cycle_reg * state->period / PWM_MAX_LEVEL;
> + state->polarity = PWM_POLARITY_NORMAL;
> + state->enabled= !!(clk_div_reg & PWM_OUTPUT_ENABLE);
These aligned = look strange (IMHO). If you don't feel strong here I'd
like to see a single s
ng low.
I didn't follow the complete discussion but note that the general rule
is:
round period down to the next possible implementable period
round duty_cycle down to the next possible implementable duty_cycle
so if a small enough period (and so a small duty_cycle) is req
utput is the right thing for a disabled PWM.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
__
m-intel can both pull
> in.
>
> Up to the two maintainer teams to figure this one out.
I'm unclear about the dependencies, but the changes to drivers/pwm need
an ack (or processing) by the PWM team.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König
Hello Andy,
On Fri, Jun 12, 2020 at 02:57:32PM +0300, Andy Shevchenko wrote:
> On Fri, Jun 12, 2020 at 12:12:42AM +0200, Uwe Kleine-König wrote:
> > I didn't follow the complete discussion but note that the general rule
> > is:
> >
> > round period down to
iewed-by tag
> - Remove extra whitespace to align some code after assignments (requested by
> Uwe Kleine-König)
> ---
> drivers/pwm/pwm-crc.c | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
ASE_UNIT_SHIFT);
> + base_unit &= (base_unit_range - 1);
> ctrl |= (u32) base_unit << PWM_BASE_UNIT_SHIFT;
> ctrl |= on_time_div;
I willing to believe your change is right, what I don't like is that the
calculation is really hard to follow. But that's
base_unit_range - 1);
.get_state seems to handle base_unit == 0 just fine?! Though this
doesn't look right either ...
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.peng
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
htt
ate method,
> as mentioned above I wrote that when I did not fully understood
> how the controller works.
>
> We really should never encounter this.
>
> But if we do then I think closest to the truth would be:
>
> state->period = UINT_MAX;
> state->duty_cycle =
one would appear with a
datasheet. Given that this probably won't happen I can take a look at
the remaining patches.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
p, PWM0_CLK_DIV, div);
> }
>
> static int crc_pwm_config(struct pwm_chip *c, struct pwm_device *pwm,
In the absence of documentation this looks reasonable.
Acked-by: Uwe Kleine-König
Best regards
Uwe
--
Pengutronix e.K.
el = DIV_ROUND_UP(panel->backlight.pwm_state.duty_cycle *
> + 100, panel->backlight.pwm_state.period);
> + level = intel_panel_compute_brightness(connector, level);
In pwm_enable_backlight() the order of these
Hello Hans,
On Tue, Jul 07, 2020 at 07:31:29PM +0200, Hans de Goede wrote:
> On 7/7/20 9:34 AM, Uwe Kleine-König wrote:
> > On Mon, Jul 06, 2020 at 10:53:08PM +0200, Hans de Goede wrote:
> > > But if we do then I think closest to the truth would be:
> > >
> &g
xplicitly and others using the PWM API" can be seen
as "unified manner" compared to "provide a pwm driver for whatever might
be in the GPU and then use generic code (PWM API, pwm_bl) to drive it".
Maybe I'm not understanding some involved complexity here?
prepared to fixup here.
> + get_vbt_pwm_freq(dev_priv), level);
> + } else {
> + /* Set period from VBT frequency, leave other settings at 0. */
> + panel->backlight.pwm_state.period =
> +
this a problem of the consumer that we don't need to solve? Are there
known consumers running into this problem?
pwm_lpss_prepare() is buggy here, a request for a too low period should be
refused.
Best regards
Uwe
--
Pengutronix e.K.
From: Chris Wilson
As the introduced comment admits this is clearly a workaround, but for
me this is the only known way to make my Lenovo X201 work without
flickering and crashing.
Signed-off-by: Uwe Kleine-König
[uwe: added changelog, comment and restrict to GEN5]
---
Hello,
as I don't
Hello,
On Tue, Jan 31, 2017 at 10:03:26AM +0100, Maarten Lankhorst wrote:
> Op 31-01-17 om 09:09 schreef Uwe Kleine-König:
> > From: Chris Wilson
> >
> > As the introduced comment admits this is clearly a workaround, but for
> > me this is the only known way to make
Hello,
On 02/01/2017 03:37 PM, Ville Syrjälä wrote:
> On Wed, Feb 01, 2017 at 01:41:08PM +0100, Maarten Lankhorst wrote:
>> Op 31-01-17 om 20:13 schreef Uwe Kleine-König:
>>> On Tue, Jan 31, 2017 at 10:03:26AM +0100, Maarten Lankhorst wrote:
>>>> Op 31-01-17 om
On 02/07/2017 04:35 PM, Ville Syrjälä wrote:
> On Tue, Feb 07, 2017 at 05:03:09PM +0200, Martin Peres wrote:
>> On 07/02/17 15:22, Uwe Kleine-König wrote:
>>> Hello,
>>>
>>> On 02/01/2017 03:37 PM, Ville Syrjälä wrote:
>>>> On Wed, Feb 01, 2
Lankhorst
> Cc: Daniel Vetter
> Cc: Uwe Kleine-König
> Reported-by: Uwe Kleine-König
> Fixes: f79f26921ee1 ("drm/i915: Add a cursor hack to allow converting legacy
> page flip to atomic, v3.")
> Signed-off-by: Ville Syrjälä
Is this supposed to fix
https://bugs.freed
c ) <(git
show 90c95c3892dd)
--- /dev/fd/63 2023-09-13 10:22:37.368055450 +0200
+++ /dev/fd/62 2023-09-13 10:22:37.372055516 +0200
@@ -1,46 +1,36 @@
-commit c04ca6bbb7ea6ea7cba9ba8d3d4d4c767008d189
-Author: Uwe Kleine-König
-Date: Sun May 7 18:25:52 2023 +0200
+commit 90c95c3892dd
On Thu, Jul 13, 2023 at 12:03:05PM +0300, Jani Nikula wrote:
> On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> > Hello Jani,
> >
> > On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
> >> On Wed, 12 Jul 2023, Uwe Kleine-König
> >> wrote:
> >
On Thu, Jul 13, 2023 at 08:52:12AM +0200, Geert Uytterhoeven wrote:
> Hi Uwe,
>
> Let's add some fuel to keep the thread alive ;-)
>
> On Wed, Jul 12, 2023 at 6:13 PM Uwe Kleine-König
> wrote:
> > On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
> &g
4 using an
allmodconfig (though I only build drivers/gpu/).
Best regards
Uwe
Uwe Kleine-König (52):
drm/crtc: Start renaming struct drm_crtc::dev to drm_dev
drm/core: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev
drm/amd: Use struct drm_crtc::drm_dev instead of struct drm_crtc:
Hello Thomas,
On Wed, Jul 12, 2023 at 12:19:37PM +0200, Thomas Zimmermann wrote:
> Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
> > Hello,
> >
> > while I debugged an issue in the imx-lcdc driver I was constantly
> > irritated about struct drm_device pointer
Hello Maxime,
On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote:
> On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
> > > Background is that this makes merge conflicts easier to handle and detect.
> >
> > Really?
>
> FWIW, I agree wi
Hello Jani,
On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
> On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> > Hello,
> >
> > while I debugged an issue in the imx-lcdc driver I was constantly
> > irritated about struct drm_device pointer variables being n
On Wed, Jul 12, 2023 at 12:46:33PM +0200, Christian König wrote:
> Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
> > Hello,
> >
> > while I debugged an issue in the imx-lcdc driver I was constantly
> > irritated about struct drm_device pointer variables being named
On Thu, Jul 13, 2023 at 10:41:45AM -0400, Sean Paul wrote:
> On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König
> > But even with the one-patch-per-rename approach I'd consider the
> > renaming a net win, because ease of understanding code has a big value.
> > It's val
alue.
It's value is not so easy measurable as "conflicts when backporting",
but it also matters in say two years from now, while backporting
shouldn't be an issue then any more.
Thanks for your input, best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-Köni
to_i915 is defined as
container_of(dev, struct drm_i915_private, drm);
So for a struct drm_device *dev, to_i915(dev)->drm is just dev. Simplify
accordingly.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 6 ++
drivers/gpu/drm/i915
reduce false positives in CI.
I don't think my patch results in regressions. But I fail to understand
the indications reported by patchwork, so I might miss something.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions
port_atomic() and scmi_handle::is_transport_atomic()
(Is this also about sleeping?)
- There are quite a lot more symbols ending in _atomic and in
_cansleep, but several of them don't exists to differentiate a slow
and a fast procedure. (e.g. drm_mode_atomic)
Not entirely su
()? I know we've talked about
> pwm_apply_atomic in the past, however I think this this the best
> option I've seen so far.
>
> > 2. If there is an API rename can we make sure the patch contains no
> >other changes (e.g. don't introduce any new API in the
ng
Not a in-detail-review, but I just noticed again, that we have
K: pwm_(config|apply_state|ops)
in MAINTAINERS. That one needs adaption, too.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions
ed-by: Lee Jones
> Signed-off-by: Sean Young
Acked-by: Uwe Kleine-König
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
ed-by: Lee Jones
> Signed-off-by: Sean Young
Acked-by: Uwe Kleine-König
Several affected maintainers already acked, so I guess it's fine to take
this via the pwm tree. An Ack from the remaining maintainers would be
very welcome, an alternative would be to split the patch.
Missing Ac
r
the individual drivers.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/Kconfig | 1 -
drivers/gpu/drm/amd/amdgpu/Kconfig | 2 ++
drivers/gpu/drm/ast/Kconfig | 2 ++
drivers/gpu/drm/gma500/Kconfig | 2 ++
drivers/gpu/drm/hisilicon/hibmc/Kconfi
45 matches
Mail list logo
