ux for the bu27034 with RAW IIO_LIGHT channel and scale
> - Fix bug from added in v4 bu27034 time setting.
--
With Best Regards,
Andy Shevchenko
+void *data, typec_mux_set_fn_t mux_set);
> +#else
> +static inline void drm_dp_unregister_typec_switches(struct
> drm_dp_typec_switch_desc *switch_desc)
> +{
> +}
> +static inline int drm_dp_register_typec_switches(
> + struct device *dev, struct fwnode_handle *port,
> + struct drm_dp_typec_switch_desc *switch_desc, void *data,
> + typec_mux_set_fn_t mux_set)
> +{
> + return -EOPNOTSUPP;
> +}
> +#endif
--
With Best Regards,
Andy Shevchenko
t it depends on if there will be no new users for those DRM
> helpers while waiting the new APIs being merged in DRM tree. More users we
> see in DRM, more effort the clean-up requires.
>
> I have no strong opinion on this specific case. I'd just be happy to see the
> IIO tests getting in preferably sooner than later - although 'soon' and
> 'late' does also depend on other factors besides these helpers...
Since I'm not a maintainer of either, and one of them requires something,
I can't oppose.
--
With Best Regards,
Andy Shevchenko
sizeof(*ctx->port_data),
?
> + GFP_KERNEL);
> + if (!ctx->port_data) {
> + ret = -ENOMEM;
> + goto unregister_mux;
> + }
...
> +struct anx7625_typec_port_data {
> + bool dp_connected;
> + enum typec_orientation orientation;
Most likely enum will be 32-bit and bool 8-bit. Which means that the data type
size become 8 bytes for no reason. Can you swap the lines and perhaps check this
with `pahole` tool?
> +};
--
With Best Regards,
Andy Shevchenko
; + it6505->extcon = extcon;
...
> + ret = it6505_register_typec_switches(dev, it6505);
> + if (ret != -ENODEV)
> + dev_warn(dev, "Didn't register Type-C switches, err: %d\n",
> ret);
> +
Unnecessary blank line.
> + if (ret && !it6505->extcon) {
> + dev_err(dev, "Both extcon and Type-C switch are not
> registered.\n");
> + return -EINVAL;
Why not return ret here?
> + }
--
With Best Regards,
Andy Shevchenko
On Wed, Mar 22, 2023 at 06:27:56PM +0200, Jani Nikula wrote:
> On Wed, 22 Mar 2023, Andy Shevchenko
> wrote:
> > On Wed, Mar 22, 2023 at 06:46:32PM +0800, Pin-yen Lin wrote:
> >> +#ifdef CONFIG_DRM_DISPLAY_DP_TYPEC_HELPER
> >
> > Ah, maybe this should use IS
the ASoC subsystem has a lot of
such cases.
> > + help
> > + DRM display helpers for USB Type-C Displayport Alternate mode.
--
With Best Regards,
Andy Shevchenko
On Fri, May 12, 2023 at 02:45:19PM +0300, Jani Nikula wrote:
> On Fri, 12 May 2023, Andy Shevchenko
> wrote:
> > On Fri, May 12, 2023 at 02:25:18PM +0300, Jani Nikula wrote:
> >> On Fri, 12 May 2023, Andy Shevchenko
> >> wrote:
> >> > On Mon, May 08,
On Fri, May 12, 2023 at 09:29:23AM -0700, Lucas De Marchi wrote:
> On Fri, May 12, 2023 at 02:14:19PM +0300, Andy Shevchenko wrote:
> > On Mon, May 08, 2023 at 10:14:02PM -0700, Lucas De Marchi wrote:
> > > Add GENMASK_U32(), GENMASK_U16() and GENMASK_U8() macros to create
>
On Tue, Jun 20, 2023 at 05:47:34PM +0300, Jani Nikula wrote:
> On Thu, 15 Jun 2023, Andy Shevchenko
> wrote:
> > On Fri, May 12, 2023 at 02:45:19PM +0300, Jani Nikula wrote:
> >> On Fri, 12 May 2023, Andy Shevchenko
> >> wrote:
> >> > On Fri, May 12, 2
On Tue, Jun 20, 2023 at 10:25:21AM -0700, Lucas De Marchi wrote:
> On Tue, Jun 20, 2023 at 05:55:19PM +0300, Andy Shevchenko wrote:
> > On Tue, Jun 20, 2023 at 05:47:34PM +0300, Jani Nikula wrote:
> > > On Thu, 15 Jun 2023, Andy Shevchenko
> > > wrote:
> > >
NFIG_FB_CORE,
> CONFIG_DRM_FBDEV_EMULATION and CONFIG_FB_DEVICE symbols set to 'y' or 'n'.
>
> Patch 1/2 makes the CONFIG_FB split that is mentioned above and patch 2/2
> makes DRM fbdev emulation depend on the new FB_CORE symbol instead of FB.
--
With Best Regards,
Andy Shevchenko
On Fri, Jun 30, 2023 at 07:38:01PM +0200, Javier Martinez Canillas wrote:
> Andy Shevchenko writes:
> > On Fri, Jun 30, 2023 at 12:51:02AM +0200, Javier Martinez Canillas wrote:
> >> This patch series splits the fbdev core support in two different Kconfig
> >> s
On Fri, Jun 30, 2023 at 08:42:21PM +0300, Andy Shevchenko wrote:
> On Fri, Jun 30, 2023 at 07:38:01PM +0200, Javier Martinez Canillas wrote:
> > Andy Shevchenko writes:
> > > On Fri, Jun 30, 2023 at 12:51:02AM +0200, Javier Martinez Canillas wrote:
...
> > >> The
On Fri, Jun 30, 2023 at 10:29:20PM +0200, Javier Martinez Canillas wrote:
> Andy Shevchenko writes:
> > On Fri, Jun 30, 2023 at 07:38:01PM +0200, Javier Martinez Canillas wrote:
> >> Andy Shevchenko writes:
> >> > On Fri, Jun 30, 2023 at 12:51:02AM +0200,
..
> +static struct gpiod_lookup_table db1100_touch_gpio_table = {
> + .dev_id = "spi0.0",
> + .table = {
> + GPIO_LOOKUP("alchemy-gpio2", 21,
> + "pendown", GPIO_ACTIVE_HIGH),
> + { },
Ditto.
> + },
> +};
--
With Best Regards,
Andy Shevchenko
for retu IRQ */
> + GPIO_LOOKUP("gpio-48-63", 15, "retu_irq",
> + GPIO_ACTIVE_HIGH),
> + /* GPIO used for tahvo IRQ */
> + GPIO_LOOKUP("gpio-32-47", 8, "tahvo_irq",
> + GPIO_ACTIVE_HIGH),
Missing terminator.
> + },
> +};
--
With Best Regards,
Andy Shevchenko
ic() in case you still wish to implement this.
--
With Best Regards,
Andy Shevchenko
On Fri, May 12, 2023 at 02:25:18PM +0300, Jani Nikula wrote:
> On Fri, 12 May 2023, Andy Shevchenko
> wrote:
> > On Mon, May 08, 2023 at 10:14:02PM -0700, Lucas De Marchi wrote:
> >> Add GENMASK_U32(), GENMASK_U16() and GENMASK_U8() macros to create
> >> masks for
ds a bit of elaboration. There is no
prohibition on reading value for the pin that is in any direction.
I.o.w. if the direction here is a problem it should have been
configured beforehand.
--
With Best Regards,
Andy Shevchenko
ling").
>
> Quote:
> ---
> If in DT boot we have phandle link then leave the GPIO in a state which the
> bootloader left it and let the user of the backlight to configure it further.
> ---
>
> So, let's drop output gpio direction check and only check gpio value to set
> the initial power state.
> -8<---
--
With Best Regards,
Andy Shevchenko
> the initial power state.
>
> Fixes: 706dc68102bc ("backlight: gpio: Explicitly set the direction of the
> GPIO")
> Signed-off-by: Liu Ying
--
With Best Regards,
Andy Shevchenko
abs_diff() belongs to math.h. Move it there.
This will allow others to use it.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 1 +
drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 7 ---
drivers/gpu/ipu-v3/ipu-image-convert.c| 14
On Fri, Jul 21, 2023 at 04:42:35PM +0300, Andy Shevchenko wrote:
> abs_diff() belongs to math.h. Move it there.
> This will allow others to use it.
Sorry, forgot omap-serial case.
Will be v2 soon.
--
With Best Regards,
Andy Shevchenko
abs_diff() belongs to math.h. Move it there.
This will allow others to use it.
Signed-off-by: Andy Shevchenko
---
v2: better header location on ipu-v3, converted omap-serial as well
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 1 +
drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 7
abs_diff() belongs to math.h. Move it there.
This will allow others to use it.
Signed-off-by: Andy Shevchenko
Reviewed-by: Jiri Slaby # tty/serial
---
v3: added tag (Jiri), removed space after a cast (fdo CI)
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 1 +
drivers/gpu/drm/i915/display
g
> message.
Do we have firmware node of PWM available? I would print it rather than some
(possibly non-unique) string.
--
With Best Regards,
Andy Shevchenko
r OF, but not
for the rest).
--
With Best Regards,
Andy Shevchenko
out the of_match_ptr(), since the only thing it can
> possibly do is to save a few bytes of .text if a driver can be used both
> with and without it.
>
> Signed-off-by: Zhu Wang
> Reviewed-by: Arnd Bergmann
> Reviewed-by: Andy Shevchenko
I haven't given you any tag, why is th
abs_diff() belongs to math.h. Move it there.
This will allow others to use it.
Reviewed-by: Jiri Slaby # tty/serial
Acked-by: Jani Nikula
Acked-by: Greg Kroah-Hartman
Reviewed-by: Andi Shyti
Reviewed-by: Philipp Zabel # gpu/ipu-v3
Signed-off-by: Andy Shevchenko
---
v4:
- Cc'ed to Andre
On Thu, Aug 03, 2023 at 10:24:46AM -0700, Andrew Morton wrote:
> On Thu, 3 Aug 2023 16:19:18 +0300 Andy Shevchenko
> wrote:
...
> > +#define abs_diff(a, b) ({ \
> > + typeof(a) __a = (a);\
> > + typeof(b) __b = (b);
piled as a
> module.
...
> drivers/pwm/pwm-lpss.c | 1 -
Acked-by: Andy Shevchenko # Intel LPSS
--
With Best Regards,
Andy Shevchenko
On Mon, Mar 20, 2023 at 01:54:26PM +0200, Andy Shevchenko wrote:
> On Fri, Mar 17, 2023 at 09:53:40PM +0100, Linus Walleij wrote:
> > On Fri, Mar 17, 2023 at 7:51 PM Andy Shevchenko
> > wrote:
> >
> > > The of_gpio.h is going to be removed. In preparation of that c
mpatible and i2c IDs.
--
With Best Regards,
Andy Shevchenko
On Fri, Aug 18, 2023 at 05:54:50PM +0100, Biju Das wrote:
> This patch series aims to add match data improvements for it66121 driver.
With the Fixes removed, FWIW,
Reviewed-by: Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
elete the i2c table and when someone has an actual need then they can
> > re-add it.
> >
> > Sound OK?
No. Please, do not remove the I2C ID table. It had already been
discussed a few years ago.
> Yes, it make sense, as it saves some memory.
--
With Best Regards,
Andy Shevchenko
On Wed, Aug 23, 2023 at 7:52 PM Andy Shevchenko
wrote:
> On Wed, Aug 23, 2023 at 5:36 PM Biju Das wrote:
> > > On Sun, Aug 13, 2023 at 1:51 AM Biju Das
> > > wrote:
...
> > > It seems like this is a sign that nobody is actually using the i2c match
> > >
On Wed, Aug 23, 2023 at 8:14 PM Doug Anderson wrote:
> On Wed, Aug 23, 2023 at 9:53 AM Andy Shevchenko
> wrote:
> > On Wed, Aug 23, 2023 at 5:36 PM Biju Das wrote:
...
> > No. Please, do not remove the I2C ID table. It had already been
> > discussed a few years ago.
&g
On Wed, Aug 23, 2023 at 9:39 PM Doug Anderson wrote:
> On Wed, Aug 23, 2023 at 10:10 AM Andy Shevchenko
> wrote:
> >
> > > No. Please, do not remove the I2C ID table. It had already been
> > > discussed a few years ago.
> > >
> > > > Yes,
t from
being instantiated on ACPI based systems (even if there is no ACPI ID
table, due to a gateway called PRP0001).
> to Kconfig, and drop the
>
> #if IS_ENABLED(CONFIG_OF)
>
> from the driver ?
Contrary this is an idea I fully support!
--
With Best Regards,
Andy Shevchenko
deo/fbdev/core/Kconfig"
Hmm... Shan't we start Kconfig from core options?
--
With Best Regards,
Andy Shevchenko
t; - depends on FB
> + depends on FB_CORE
> default y
--
With Best Regards,
Andy Shevchenko
On Tue, Jul 04, 2023 at 10:20:35AM +0300, Andy Shevchenko wrote:
> On Tue, Jul 04, 2023 at 01:05:28AM +0200, Javier Martinez Canillas wrote:
...
> Wondering if
>
> if FB_CORE
> ...
> endif
>
> makes Kconfig looking better instead of replacing all these "d
removing the redundant 'select THERMAL'
> from INTEL_MENLOW, so no other driver uses that statement.
>
For PDx86 part:
Acked-by: Andy Shevchenko
> Fixes: bcdfb5e56dc5 ("drm/etnaviv: add etnaviv cooling device")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/
is still in use when we try to change it.
> 4. Handle intermediate bridges as well.
> 5. Print some more messages when changing something.
>
> Please review and/or comment,
Would look later (perhaps this week),
--
With Best Regards,
Andy Shevchenko
___
AR_CTRL, ctrl);
> + return 0;
> + }
> +
> + return -ENOENT;
> +}
> -#define PCI_REBAR_CTRL_NBAR_MASK (7 << 5)/* mask for # bars */
> -#define PCI_REBAR_CTRL_NBAR_SHIFT 5 /* shift for # bars */
> +#define PCI_REBAR_CTRL_N
; + release_resource(res);
> + res->end = resource_size(res) - 1;
> + res->start = 0;
> + res->flags |= IORESOURCE_UNSET;
> + dev_info(&dev->dev, "BAR %d: released %pR\n", resno, res);
Makes little sense to me after you clea
T nn
> + pci_write_config_dword(dev, 0x180 + i * 0x4, high);
> + pci_write_config_dword(dev, 0x84 + i * 0x8, limit);
> + pci_write_config_dword(dev, 0x80 + i * 0x8, base);
Ditto for pos:s.
> +
> + pci_bus_add_resource(dev->bus, res, 0);
> +}
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, May 2, 2017 at 6:51 PM, Christian König wrote:
> Am 26.04.2017 um 19:00 schrieb Andy Shevchenko:
>> On Tue, Apr 25, 2017 at 4:19 PM, Christian König
>> wrote:
>>> +int pci_reassign_bridge_resources(struct pci_dev *bridge, unsigned long
>>> type)
>&
On Thu, May 4, 2017 at 12:23 PM, Christian König
wrote:
> Am 26.04.2017 um 19:00 schrieb Andy Shevchenko:
>>> + while (1) {
>>
>> This raises red flag. Care to refactor?
>> Also do {} while () syntax allows faster to get that the loop body
>> goe
@@ static void reset_semaphore(struct dw_i2c_dev
> > *dev)
> data &= ~PUNIT_SEMAPHORE_BIT;
> if (iosf_mbi_write(BT_MBI_UNIT_PMC, MBI_REG_WRITE,
> PUNIT_SEMAPHORE, data))
> dev_err(dev->dev, "iosf failed to reset punit
> semaphore during write\n");
>
> + ret = drm_simple_display_pipe_init(drm, &tdev->pipe, funcs, formats,
> + format_count, connector);
> + if (ret)
> + return ret;
> +
> + return 0;
return drm_... ?
> +}
> +EXPORT_SYMBOL(tinydrm_display_pipe_init);
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
IVER)
> + pr_debug("[drm:%s] bpw=%u, max_chunk=%zu, transfers:\n",
> +__func__, bpw, max_chunk);
For all of your dev_dbg() / pr_debug() __func__ argument might be
redundant. Dynamic Debug may include this by request from user.
> +/**
> + * t
.
Cc: Mika Kahola
Cc: Jani Nikula
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 8f683b8b1816..493d5ec2b53
On Tue, 2017-02-21 at 18:26 +0200, Jani Nikula wrote:
> On Tue, 21 Feb 2017, Andy Shevchenko m> wrote:
> > The commit 213e08ad60ba ("drm/i915/bxt: add bxt dsi gpio element
> > support") enables GPIO support for Broxton based platforms.
> >
> > While usin
On Fri, Jun 9, 2017 at 11:59 AM, Christian König
wrote:
> From: Christian König
>
> This way we can savely call it on SI as well.
s/savely/safely
FWIW,
Reviewed-by: Andy Shevchenko
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/am
, buf[0x9] & 0xf, buf[0xa], buf[0xb]);
Matter of taste, though buf[9], buf[10], buf[11] looks better to me :-)
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Sun, Jun 11, 2017 at 3:20 AM, Joe Perches wrote:
> On Sat, 2017-06-10 at 19:12 +0300, Andy Shevchenko wrote:
>> On Wed, May 31, 2017 at 2:35 AM, Joe Perches wrote:
>> > Using the extension saves a bit of code.
>> > + seq_printf(m,
; AMD_141b_MMIO_HIGH_MMIOBASE_MASK) |
> ^~
>arch/x86/pci/fixup.c:687:21: warning: right shift count >= width of type
> [-Wshift-count-overflow]
> res->end + 1) >> 40) << AMD_141b_MMIO_HIGH_MMI
llX\n",
> (uint64_t)adev->doorbell.base);
> DRM_INFO("doorbell mmio size: %u\n", (unsigned)adev->doorbell.size);
It seems I sent patch to remove those at all, but if you wish to leave
them, please convert to %pap and remove explicit casting.
--
W
he doorbell mapping, it is most likely moved as well */
> + amdgpu_doorbell_fini(adev);
> + BUG_ON(amdgpu_doorbell_init(adev));
No way to recover?!
> +}
> +
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
f resizing was successful, false otherwise.
> + */
> +bool pci_rbar_set_size(struct pci_dev *pdev, int bar, int size)
I would return int and error code. It would be better in the future
and seems in alignment with above.
> +{
> + int pos, nbars;
> + u32 ctrl;
> + in
On Sun, 2017-02-26 at 22:45 +0100, Daniel Vetter wrote:
> On Tue, Feb 21, 2017 at 06:52:24PM +0200, Andy Shevchenko wrote:
> > On Tue, 2017-02-21 at 18:26 +0200, Jani Nikula wrote:
> > > On Tue, 21 Feb 2017, Andy Shevchenko > > l.co
> > > m> wrote:
> >
se ack patch [5/5] of this series, barring any objections.
>
> I'll move the apple-gmux patch to the end of the series, so merging that
> one can be postponed until Darren and Andy find the time to look at it.
Yeah, please resend. It's probably buried in the pile of deleted mail
turn -ENOTSUPP;
> +
> + if (!(sizes & (1 << size)))
BIT(size) ?
> + return -EINVAL;
> +
and
old = pci_rbar_get_current_size(dev, resno);
here
> + if (old < 0)
> + return old;
> +error_resize:
> + pci_rbar_set_size(dev, resno, old);
> + res->end = res->start + (1ULL << (old + 20)) - 1;
BIT_ULL(old + 20) ?
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
ree(res);
> + return;
> + }
> +
> + base = ((res->start >> 8) & 0xff00) | 0x3;
> + limit = ((res->end + 1) >> 8) & 0xff00;
> + high = ((res->start >> 40) &
t the doorbell mapping, it is most likely moved as well */
> + amdgpu_doorbell_fini(adev);
> + BUG_ON(amdgpu_doorbell_init(adev));
Comment why it's used here.
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, May 4, 2017 at 1:15 PM, Andy Shevchenko
wrote:
> On Thu, May 4, 2017 at 12:23 PM, Christian König
> wrote:
>> Am 26.04.2017 um 19:00 schrieb Andy Shevchenko:
> static int ...xxx...(...)
> {
> unsigned int i;
> int ret;
>
> if (res->parent)
&
PWRGT_CTRL);
> Â ctrl &= ~mask;
> Â ctrl |= state;
> @@ -1037,6 +1040,8 @@ static void vlv_set_power_well(struct
> drm_i915_private *dev_priv,
> Â Â Â state,
> Â Â Â vlv_punit_read(dev_priv,
> PUNIT_REG_PWRGT_CTRL));
> Â
r from other stakeholders that's
_the_ way we are going.
So, FWIW:
Reviewed-by: Andy Shevchenko
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
> Signed-off-by: Hans de Goede
> Tested-by: tagorereddy
> ---
>  arch/x86/include/asm/iosf_mbi.h    | 54
>
On Sun, 2017-01-08 at 16:30 +0100, Hans de Goede wrote:
> Hi,
>
> On 08-01-17 16:16, Andy Shevchenko wrote:
> > On Sun, 2017-01-08 at 14:44 +0100, Hans de Goede wrote:
> > > One some systems the punit accesses the pmic to change various
> > > voltages
> >
> @@ -62,6 +62,8 @@ static void reset_semaphore(struct dw_i2c_dev *dev)
> + iosf_mbi_punit_unlock();
> @@ -79,6 +81,8 @@ static int baytrail_i2c_acquire(struct dw_i2c_dev
> + iosf_mbi_punit_lock();
For me it looks a bit asymmetrical.
Can we use acquire()/release()?
--
Andy Shevchenko
Intel Finland Oy
.
I'm fine with the patch, but please spell
P-Unit
PMIC
Reviewed-by: Andy Shevchenko
>
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
> Signed-off-by: Hans de Goede
> Tested-by: tagorereddy
> ---
>  arch/x86/include/asm/iosf_mbi.h    | 31
> +++
On Sun, 2017-01-08 at 14:44 +0100, Hans de Goede wrote:
> Call the iosf_mbi pmic_bus_access_notifier_chain on bus acquire /
> release.
>
FWIW:
Reviewed-by: Andy Shevchenko
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
> Signed-off-by: Hans de Goede
> Test
series.
This also moves indices arrays to lib/uuid.c to be shared accross modules.
Signed-off-by: Andy Shevchenko
---
include/linux/uuid.h | 13 ++
lib/uuid.c | 70
lib/vsprintf.c | 9 +++
3 files changed, 87
UUID constants after conversion).
So, please test this as much as you can and provide your tag. We appreciate the
effort.
Andy Shevchenko (10):
lib/vsprintf: simplify UUID printing
lib/uuid: move generate_random_uuid() to uuid.c
lib/uuid: introduce few more generic helpers for UUID
lib
Instead of opencoding the existing library functions let's use them directly.
The conversion fixes a potential bug in int340x_thermal as well since we have
to use memcmp() on binary data.
Signed-off-by: Andy Shevchenko
---
drivers/acpi/acpi_extlog.c| 8 +++---
dr
On Thu, Jul 09, 2020 at 03:23:13PM +0200, Hans de Goede wrote:
> On 7/9/20 2:53 PM, Andy Shevchenko wrote:
> > On Wed, Jul 08, 2020 at 11:14:20PM +0200, Hans de Goede wrote:
> > > When the user requests a high enough period ns value, then the
> > > calculations in pwm_
t_range - 1) << PWM_BASE_UNIT_SHIFT);
> - base_unit &= (base_unit_range - 1);
> ctrl |= (u32) base_unit << PWM_BASE_UNIT_SHIFT;
> ctrl |= on_time_div;
>
> --
> 2.26.2
>
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
better, like:
...
if (from_resume) {
ret = pwm_lpss_prepare_enable(...); // whatever name you think
suits better
} else {
pm_runtime_get_sync(...);
ret = pwm_lpss_prepare_enable(...);
if (ret)
pm_runtime_put(...);
}
...
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, Jul 09, 2020 at 04:33:50PM +0200, Hans de Goede wrote:
> On 7/9/20 4:21 PM, Andy Shevchenko wrote:
> > On Thu, Jul 09, 2020 at 03:23:13PM +0200, Hans de Goede wrote:
...
> > You can use clamp_val().
>
> I did not know about that, that will work nicely I will swit
do_div(on_time_div, 255);
> + state->duty_cycle = on_time_div;
> + }
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
; return dev_err_probe(dev, err, ...);
>
FWIW,
Reviewed-by: Andy Shevchenko
> Signed-off-by: Andrzej Hajda
> Reviewed-by: Rafael J. Wysocki
> Reviewed-by: Mark Brown
> ---
> drivers/base/core.c| 42 ++
> include/linux/dev
On Fri, May 29, 2020 at 03:33:17PM +0300, Andy Shevchenko wrote:
> acpi_dev_get_resources() does perform the NULL pointer check against
> ACPI companion device which is given as function parameter. Thus,
> there is no need to duplicate this check in the caller.
Any comment so far?
>
Should this go to another list as well?
Just drop this cover letter. For single patch is not needed. Use place
immediately after cutter '---' line for comments like above.
--
With Best Regards,
Andy Shevchenko
___
dri-dev
account that Fixes implies regression / bug?
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
also couple of lines of crash and add a paragraph about it.
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
struct mbxfb_info *mfbi = fbi->par;
>
> + mbxfb_debugfs_remove(fbi);
> unregister_framebuffer(fbi);
> if (mfbi) {
> if (mfbi->platform_remove)
--
With Best Regards,
Andy Shevchenko
in the rest of the code there?
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
king on this I noticed that the enabled -> enabled (update
> settings) path was quite similar, so I've added an enable parameter to
> the new pwm_lpss_prepare_enable() helper, which allows using it in that
> path too.
Reviewed-by: Andy Shevchenko
But see below.
> Suggested-by: Andy S
~PWM_ENABLE);
> return 0;
> }
and another one for !from_resume.
> +static int pwm_lpss_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> + const struct pwm_state *state)
> +{
> + return __pwm_lpss_apply(chip, pwm, state, false);
> +}
...
> +
ivisor, need to disable fisrt */
> crc_pwm_disable(c, pwm);
> - clk_div = PWM_BASE_CLK * period_ns / NSEC_PER_SEC;
> + clk_div = PWM_BASE_CLK_MHZ * period_ns / (256 * NSEC_PER_USEC);
>
> regmap_write(crc_pwm->regmap, PWM0_CLK_DI
assume the extra division by 256 then the register
> values set by the GOP are an exact match for the VBT values, where as
> otherwise the values would be of by a factor of 256.
>
> This commit fixes the period / duty_cycle calculations to take the
> extra division by 256 into account
> using the CRC PWM output to drive their backlight. Before the PWM would
> always run with the output frequency configured by the BIOS at boot, now
> the period time specified by the i915 driver will actually be honored.
We have a confirmation now that those two bits are real GPOs.
e PWM,
> this commit makes crc_pwm_disable() clear it on disable and makes
> crc_pwm_enable() set it again on re-enable.
Reviewed-by: Andy Shevchenko
> Acked-by: Uwe Kleine-König
> Signed-off-by: Hans de Goede
> ---
> Changes in v3:
> - Remove paragraph about tri-stating t
rror means that after the subtraction of 1 it is impossible
> to set the divider to 128. Also bump PWM_MAX_PERIOD_NS by 1 ns to allow
> setting a divider of 128 (register-value 127).
Reviewed-by: Andy Shevchenko
> Signed-off-by: Hans de Goede
> ---
> Changes in v3:
> - Introdu
On Fri, Jul 17, 2020 at 03:37:48PM +0200, Hans de Goede wrote:
> Replace the enable, disable and config pwm_ops with an apply op,
> to support the new atomic PWM API.
I didn't notice any visible issue, so
Reviewed-by: Andy Shevchenko
Perhaps you may consider reusing exist
On Tue, Jul 28, 2020 at 09:55:22PM +0200, Hans de Goede wrote:
> On 7/28/20 8:57 PM, Andy Shevchenko wrote:
> > On Fri, Jul 17, 2020 at 03:37:43PM +0200, Hans de Goede wrote:
...
> > Maybe I'm too picky, but I would go even further and split apply to two
> > ve
patch fixes properly.
> - PATCH v3 6 - 11 pwm-crc changes:
> - Various small changes resulting from the reviews by Andy and Uwe,
> including some refactoring of the patches to reduce the amount of churn
> in the patch-set
>
> Changes in v2:
> - Fix coverletter subj
if you expect me to pick those patches up as
> well. As far as I can tell the ACPI, PWM and DRM parts are all
> independent, so these patches could be applied to the corresponding
> subsystem trees.
>
> Anyway, if you want me to pick those all up into the PWM tree, I suppose
&
501 - 600 of 1147 matches
Mail list logo
