dif
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
;line,
> + line + irq_first,
>num_interrupts[line],
> num_wake_interrupts[line]);
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Sat, Dec 12, 2020 at 12:07 AM Thomas Gleixner wrote:
>
> On Fri, Dec 11 2020 at 22:08, Thomas Gleixner wrote:
>
> > On Fri, Dec 11 2020 at 19:53, Andy Shevchenko wrote:
> >
> >> On Thu, Dec 10, 2020 at 10:14 PM Thomas Gleixner
> >> wrote:
> >
rivers that
> rely on FB_DDC to have an appropriate I2C dependency as well.
No objections from me.
Acked-by: Andy Shevchenko
> Signed-off-by: Arnd Bergmann
> ---
> drivers/video/fbdev/Kconfig | 17 +
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> d
On Wed, May 5, 2021 at 12:07 PM Hans de Goede wrote:
> On 5/4/21 9:52 AM, Andy Shevchenko wrote:
> > On Monday, May 3, 2021, Hans de Goede > <mailto:hdego...@redhat.com>> wrote:
...
> > + fwnode = device_get_next_child_node(kdev, fwnode);
&g
On Wed, May 5, 2021 at 12:28 PM Hans de Goede wrote:
> On 5/5/21 11:17 AM, Andy Shevchenko wrote:
> > On Wed, May 5, 2021 at 12:07 PM Hans de Goede wrote:
> >> On 5/4/21 9:52 AM, Andy Shevchenko wrote:
> >>> On Monday, May 3, 2021, Hans de Goede >>&
On Wed, May 5, 2021 at 1:30 PM Hans de Goede wrote:
> On 5/5/21 12:02 PM, Andy Shevchenko wrote:
...
> But we do really need to document the behavior better here
> in the kdoc for fwnode_get_next_child_node() and
> device_get_next_child_node().
Totally agree!
> of_get_next_chi
On Wed, Apr 07, 2021 at 03:23:37PM +0300, Andy Shevchenko wrote:
> The ascii85.h is user of exactly two headers, i.e. math.h and types.h.
> There is no need to carry on entire kernel.h.
It seems DRM has strict rules about what's going thru DRM tree and this one,
while being used o
KERNEL_PARAM_FL_UNSAFE)
(above left for the above comment)
...
> +#define __module_param_call_wdata(prefix, name, ops, arg, perm, level,
> flags, data) \
Similar __module_param_call_with_data()
--
With Best Regards,
Andy Shevchenko
kp->data;
So you need space after ')' ?
> + rc = kstrtoul(instr, 0, &inbits);
> + if (rc) {
> + pr_err("set_dyndbg: failed\n");
> + return -EINVAL;
Why not to return rc?
> + }
> + vpr_info("set_dyndbg: input 0x%lx\n", inbits);
> +
> + for (i = 0; !!bitmap[i].prefix; i++) {
Hmm... Why not simply
for (bitmap = ...; bitmap->prefix; bitmap++) {
?
> +
Redundant blank line.
> + sprintf(query, "format '^%s' %cp", bitmap[i].prefix,
> + test_bit(i, &inbits) ? '+' : '-');
snprintf() ?
> +
> + chgct = dynamic_debug_exec_queries(query, kp->mod->name);
> +
> + v2pr_info("bit-%d: %d changes by '%s'\n", i, chgct, query);
> + totct += chgct;
> + }
> + vpr_info("total changes: %d\n", totct);
> + return 0;
> +}
...
> + return scnprintf(buffer, PAGE_SIZE, "%u\n",
> + *((unsigned int *)kp->arg));
One line.
--
With Best Regards,
Andy Shevchenko
info("query %d: \"%s\" %s\n", i, query, (modname) ?
> modname : "");
too many parentheses. Also may use
modname ?: ""
form (but not all maintainers are happy with it).
...
> + if (!bitmap) {
> + pr_err("set_dyndbg: no bits=>queries map\n");
> + return -EINVAL;
> + }
> + rc = kstrtoul(instr, 0, &inbits);
> + if (rc) {
> + pr_err("set_dyndbg: failed\n");
> + return rc;
> + }
> + vpr_info("set_dyndbg: input 0x%lx\n", inbits);
> +
> + for (i = 0; bitmap->prefix; i++, bitmap++) {
> + snprintf(query, FMT_QUERY_SIZE, "format '^%s' %cp",
> bitmap->prefix,
> +test_bit(i, &inbits) ? '+' : '-');
> +
> + matches = ddebug_exec_queries(query, KP_MOD_NAME);
> +
> + v2pr_info("bit-%d: %d matches on '%s'\n", i, matches, query);
> + totct += matches;
> + }
I'm wondering if there is a room to parse a bitmap as a bitmap.
...
> +int param_get_dyndbg(char *buffer, const struct kernel_param *kp)
> +{
> + return scnprintf(buffer, PAGE_SIZE, "%u\n",
> +*((unsigned int *)kp->arg));
One line?
> +}
--
With Best Regards,
Andy Shevchenko
urn -EINVAL;
> + }
> +
> + rmem->ops = &rmem_swiotlb_ops;
> + pr_info("Reserved memory: created restricted DMA pool at %pa, size
> %ld MiB\n",
> + &rmem->base, (unsigned long)rmem->size / SZ_1M);
Oh là là, besides explicit casting that I believe can be avoided, %ld
!= unsigned long. Can you check the printk-formats.rst document?
> + return 0;
> +}
> +
> +RESERVEDMEM_OF_DECLARE(dma, "restricted-dma-pool", rmem_swiotlb_setup);
> #endif /* CONFIG_DMA_RESTRICTED_POOL */
--
With Best Regards,
Andy Shevchenko
The ascii85.h is user of exactly two headers, i.e. math.h and types.h.
There is no need to carry on entire kernel.h.
Signed-off-by: Andy Shevchenko
---
include/linux/ascii85.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/ascii85.h b/include/linux/ascii85.h
On Wed, Apr 07, 2021 at 03:46:37PM +0300, Jani Nikula wrote:
> On Wed, 07 Apr 2021, Andy Shevchenko
> wrote:
> > The ascii85.h is user of exactly two headers, i.e. math.h and types.h.
> > There is no need to carry on entire kernel.h.
> >
> > Signed-off-by: Andy Shev
On Wed, Apr 07, 2021 at 04:40:10PM +0300, Andy Shevchenko wrote:
> On Wed, Apr 07, 2021 at 03:46:37PM +0300, Jani Nikula wrote:
> > On Wed, 07 Apr 2021, Andy Shevchenko
> > wrote:
> > > The ascii85.h is user of exactly two headers, i.e. math.h and types.h.
> >
970,6 +14970,7 @@ int intel_modeset_init_nogem(struct
> drm_i915_private *i915)
>
> drm_modeset_lock_all(dev);
> intel_modeset_setup_hw_state(dev, dev->mode_config.acquire_ctx);
> + intel_acpi_assign_connector_fwnodes(i915);
> drm_modeset_unlock_all(dev);
>
> for_each_intel_crtc(dev, crtc) {
> --
> 2.31.1
>
>
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 0261801af62c..d20bfd7576ed 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1254,6 +1254,8 @@ struct drm_connector {
> struct device *kdev;
> /** @attr: sysfs
index d20bfd7576ed..ae377354e48e 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1267,6 +1267,14 @@ struct drm_connector {
> */
> struct list_head head;
>
> + /**
> +* @global_connector_list_entry:
> +*
> +* Connector entry in the global connector-list, used by
> +* drm_connector_find_by_fwnode().
> +*/
> + struct list_head global_connector_list_entry;
> +
> /** @base: base KMS object */
> struct drm_mode_object base;
>
> --
> 2.31.1
>
>
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, May 4, 2021 at 2:53 PM Hans de Goede wrote:
> On 5/4/21 10:00 AM, Andy Shevchenko wrote:
> > On Monday, May 3, 2021, Hans de Goede > <mailto:hdego...@redhat.com>> wrote:
...
> > +struct drm_connector *drm_connector_find_by_fwnode(struct
plied by the name of structure...
> + } else {
> + pr_warn("%s: Not implemented\n", __func__);
> + pr_warn("%s: i2c-addr: 0x%x reg-addr 0x%x value 0x%x mask
> 0x%x\n",
> + __func__, i2c_address, reg_address, value, mask
address);
I tried to parse the message and failed.
Perhaps something like
"%s: addresses too big for client 0x%x, reg 0x%x\n"
would be easier to understand?
> + return -ERANGE;
> + }
--
With Best Regards,
Andy Shevchenko
___
e instead of exposing PMIC I2C address?
Am I missing something in case it's not possible?
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, Jan 08, 2019 at 02:45:39PM +0100, Hans de Goede wrote:
> On 07-01-19 16:46, Andy Shevchenko wrote:
> > On Mon, Jan 07, 2019 at 12:15:55PM +0100, Hans de Goede wrote:
> > > + } else if (d->pmic_i2c_address) {
> > > + if (i2c_
On Tue, Jan 08, 2019 at 04:35:45PM +0100, Hans de Goede wrote:
> Hi,
>
> On 08-01-19 15:51, Andy Shevchenko wrote:
> > On Tue, Jan 08, 2019 at 02:45:39PM +0100, Hans de Goede wrote:
> > > On 07-01-19 16:46, Andy Shevchenko wrote:
> > > > On Mon, Jan 07, 201
decs/max98088.c
> +++ b/sound/soc/codecs/max98088.c
> @@ -1405,7 +1405,7 @@ static int max98088_get_channel(struct
> snd_soc_component *component, const char
> {
> int ret;
>
> - ret = __match_string(eq_mode_name, ARRAY_SIZE(eq_mode_name), name);
> + ret = match_s
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/selftests/test-drm_mm.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_gem_fence_reg.c | 3 +--
drivers/gpu
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_gem_fence_reg.c | 3 +--
drivers/gpu
Switch to bitmap_zalloc() to show clearly what we are allocating.
Besides that it returns pointer of bitmap type instead of opaque void *.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/selftests/test-drm_mm.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a
On Mon, Mar 04, 2019 at 09:41:34AM +, Chris Wilson wrote:
> Quoting Andy Shevchenko (2019-03-04 09:29:08)
> > Switch to bitmap_zalloc() to show clearly what we are allocating.
> > Besides that it returns pointer of bitmap type instead of opaque void *.
>
> Which i
On Tue, Mar 05, 2019 at 11:28:36AM +0200, Joonas Lahtinen wrote:
> I take it that both instances are supposed to call bitmap_zalloc?
>
> If you can send a v2 that compiles, I can merge it after it passes the
> CI.
v2 had been sent yesterday.
--
With Best Regards,
And
0x%x reg 0x%x\n",
> + __func__, i2c_client_address, reg_address);
> + return;
> + }
> +
> + address = (i2c_client_address << 8) | reg_address;
> + regmap_update_bits(regmap, address, mask, value);
> +}
--
With Best Regards,
Andy S
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.
Signed-off-by: Andy Shevchenko
---
v2: used LIST_HEAD() (Ville), initialized lookup directly on stack
ldn't see how even possibly to have any new regression with the change
provided. Can anybody assure me that it's my patch made all those breakages?
--
With Best Regards,
Andy Shevchenko
TLOG_YES));
> +yesno(cond->grant_log ==
> TOMOYO_GRANTLOG_YES));
> tomoyo_set_lf(head);
> return true;
> }
> diff --git a/security/tomoyo/common.h b/security/tomoyo/common.h
> index 85246b9df7ca..ca285f362705 100644
> --- a/security/tomoyo/common.h
> +++ b/security/tomoyo/common.h
> @@ -959,7 +959,6 @@ char *tomoyo_read_token(struct tomoyo_acl_param
> *param);
> char *tomoyo_realpath_from_path(const struct path *path);
> char *tomoyo_realpath_nofollow(const char *pathname);
> const char *tomoyo_get_exe(void);
> -const char *tomoyo_yesno(const unsigned int value);
> const struct tomoyo_path_info *tomoyo_compare_name_union
> (const struct tomoyo_path_info *name, const struct tomoyo_name_union
> *ptr);
> const struct tomoyo_path_info *tomoyo_get_domainname
> --
> 2.34.1
>
>
--
With Best Regards,
Andy Shevchenko
inline const char *enabledisable(bool v) { return v ? "enable" :
> "disable"; }
> +static inline const char *enableddisabled(bool v) { return v ? "enabled"
> : "disabled"; }
Looks not readable even if takes 80 characters. Please, keep original style.
I believe you wanted to have nice negative statistics from day 1, then you
may add more patches in the series to cleanup more users.
>
> #endif
> --
> 2.34.1
>
>
--
With Best Regards,
Andy Shevchenko
red starting with drm/ since this is "closer to home".
>
> I hope this is a good summary of the previous attempts and a way we can
> move forward.
>
> Andrew Morton, Petr Mladek, Andy Shevchenko: if this is accepted, my
> proposal is to take first 2 patches either t
>
> I say keep it one line!
>
> Reviewed-by: Steven Rostedt (Google)
I believe Sakari strongly follows the 80 rule, which means...
> > Reviewed-by: Sakari Ailus
...chose either of these tags and be happy with :-)
--
With Best Regards,
Andy Shevchenko
o\0\0yes" + v * 4' works a bit better.
Is it a C code obfuscation contest?
--
With Best Regards,
Andy Shevchenko
yesno(ident1 & V3D_HUB_IDENT1_WITH_TSY));
> seq_printf(m, "MSO:%s\n",
> -(ident1 & V3D_HUB_IDENT1_WITH_MSO) ? "yes" : "no");
> +yesno(ident1 & V3D_HUB_IDENT1_WITH_MSO));
> seq_printf(m, "L3C:%s (%dkb)\n",
> -(ident1 & V3D_HUB_IDENT1_WITH_L3C) ? "yes" : "no",
> +yesno(ident1 & V3D_HUB_IDENT1_WITH_L3C),
> V3D_GET_FIELD(ident2, V3D_HUB_IDENT2_L3C_NKB));
I believe it's fine to join back to have less LOCs (yes, it will be 83 or so,
but I believe in these cases it's very much okay).
--
With Best Regards,
Andy Shevchenko
On Wed, Jan 19, 2022 at 04:00:17PM -0500, Steven Rostedt wrote:
> On Wed, 19 Jan 2022 21:25:08 +0200
> Andy Shevchenko wrote:
>
> > > I say keep it one line!
> > >
> > > Reviewed-by: Steven Rostedt (Google)
> >
> > I believe
E.g. yesno() to me doesn't sound too bad to misunderstand its meaning,
esp.when it's used as an argument to the printf() functions.
--
With Best Regards,
Andy Shevchenko
On Tue, Oct 05, 2021 at 02:34:23PM -0700, Lucas De Marchi wrote:
> On Mon, Feb 15, 2021 at 04:21:35PM +0200, Andy Shevchenko wrote:
> > We have already few similar implementation and a lot of code that can
> > benefit
> > of the yesno() helper. Consolidate yesno() helper
On Mon, Nov 15, 2021 at 01:43:02PM +0200, Jani Nikula wrote:
> On Mon, 15 Nov 2021, Andy Shevchenko
> wrote:
> > On Tue, Oct 05, 2021 at 02:34:23PM -0700, Lucas De Marchi wrote:
> >> On Mon, Feb 15, 2021 at 04:21:35PM +0200, Andy Shevchenko wrote:
> >>
On Mon, Nov 15, 2021 at 01:53:10PM +0200, Jani Nikula wrote:
> Took Andy's patch [1] and expanded on it a bit.
Thank you!
It's always good to have cleanups in the headers,
Acked-by: Andy Shevchenko
for your changes (including ones that you've done against my patch
Split typeof_member() to
> - Split sizeof_field() to
> - Split NULL to
> - Split ARRAY_SIZE() to
Isn't it way too small granularity? I agree on having the separate header
for ARRAY_SIZE() and it was discussed, but the rest...
--
With Best Regards,
Andy Shevchenko
; The main reason I started doing this splitting
> is because I wouldn't be able to include
> in some headers,
> because it pulled too much stuff that broke unrelated things.
>
> So that's why I started from there.
>
> I for example would like to get NULL in memberof()
> without puling anything else,
> so makes sense for that.
I don't believe that the code that uses NULL won't include types.h.
--
With Best Regards,
Andy Shevchenko
so this is by
> definition not accessible here. It appears that there is also
> an include/uapi/linux/stddef.h that is really strange because
> it includes linux/compiler_types.h, which in turn is outside
> of uapi/. This should probably be fixed.
>
> Arnd
>
> [1]
> https://drive.google.com/file/d/14IKifYDadg2W5fMsefxr4373jizo9bLl/view?usp=sharing
> [2]
> https://drive.google.com/file/d/1pWQcv3_ZXGqZB8ogV-JOfoV-WJN2UNnd/view?usp=sharing
--
With Best Regards,
Andy Shevchenko
On Fri, Nov 19, 2021 at 05:22:48PM +0100, Alejandro Colomar (man-pages) wrote:
>
>
> On 11/19/21 17:18, Arnd Bergmann wrote:
> > On Fri, Nov 19, 2021 at 5:10 PM Andy Shevchenko
> > wrote:
> >> On Fri, Nov 19, 2021 at 04:57:46PM +0100, Arnd Bergmann wrote:
> &g
udes bitops.h and this is good and a must, why
to avoid this?
--
With Best Regards,
Andy Shevchenko
It's hard to parse for-loop which has some magic calculations inside.
Much cleaner to use while-loop directly.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/selftests/i915_syncmap.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm
On Tue, Feb 15, 2022 at 07:14:49PM +0200, Jani Nikula wrote:
> On Tue, 15 Feb 2022, Andy Shevchenko
> wrote:
> > It's hard to parse for-loop which has some magic calculations inside.
> > Much cleaner to use while-loop directly.
>
> I assume you're trying to
ge for modules, but if you compile in the
linker may try to optimize it. Would be nice to see the old-new for
`make allyesconfig` or equivalent.
...
> seq_printf(m, "\tDP branch device present: %s\n",
> - branch_device ? "yes" : "no");
> + str_yes_no(branch_device));
Can it be now on one line? Same Q for all similar cases in the entire series.
--
With Best Regards,
Andy Shevchenko
11 +-
> drivers/gpu/drm/virtio/virtgpu_debugfs.c | 4 +-
> .../ethernet/chelsio/cxgb4/cxgb4_debugfs.c| 249 ++
> include/linux/string_helpers.h| 20 ++
> security/tomoyo/audit.c | 2 +-
> security/tomoyo/common.c | 19 +-
> security/tomoyo/common.h | 1 -
> 60 files changed, 482 insertions(+), 373 deletions(-)
>
> --
> 2.34.1
>
--
With Best Regards,
Andy Shevchenko
On Wed, Jan 26, 2022 at 02:43:45AM -0800, Lucas De Marchi wrote:
> On Wed, Jan 26, 2022 at 12:12:50PM +0200, Andy Shevchenko wrote:
> > On Wed, Jan 26, 2022 at 11:39 AM Lucas De Marchi
> > wrote:
...
> > > 411986 104906176 428652 68a6c drm.ko.old
> > >
l tree?
>
Entire series (or a single patch) makes sense to me.
Thanks for fixing this old hardware!
FWIW,
Reviewed-by: Andy Shevchenko
> Regards,
>
> Hans
>
> p.s.
>
> The promised background info:
>
> We have this long standing issue where instead of looking
I get your ack
> for merging the pinctrl-baytrail patch throught the drm-inteol tree?
I'm not okay with this. I will tell more next week how I see this to be
implemented in a better way.
Happy Black Friday! :-)
--
With Best Regards,
Andy Shevchenko
ling us that the pin should
> definitely be muxed to the PWM controller is the VBT to which the PWM
> driver does not have access.
My concern here, as one of Linus', is a pollution the driver with board code.
Aren't we able to split this to a separate file under PD
CH_REPORTS) :
+
_MASKED_BIT_DISABLE(GEN12_OAG_OA_DEBUG_DISABLE_CTX_SWITCH_REPORTS)));
intel_uncore_write(uncore, GEN12_OAG_OAGLBCTXCTRL, periodic ?
(GEN12_OAG_OAGLBCTXCTRL_COUNTER_RESUME |
--
2.24.0
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
p-table.
>
> Since the lookup-table is attached to the i915 PCI device it really
> should be part of the i915 driver, this will also allow us to extend
> it with GPIOs from other sources when necessary.
Reviewed-by: Andy Shevchenko
One nit below.
> Signed-off-by: Hans de
I believe there will be no (significant) changes in the driver Hans
touched. For the record it seems only Hans is touching drivers for old Intel
platforms (such as Baytrail and Cherryview).
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
9c6d1f49ade2f3 ("drm/drm_panel: fix EXPORT of
> drm_panel_of_backlight") is fixing drm_panel_of_backlight(), but the
> error above is for backlight_device_register().
>
> From what I can tell, that commit is actually the cause of the error -
> now intel_backlight_device
On Tue, Dec 17, 2019 at 5:28 PM Jani Nikula wrote:
> On Tue, 17 Dec 2019, Andy Shevchenko wrote:
> > On Tue, Dec 17, 2019 at 1:56 PM Steven Price wrote:
> > I think the proper one is to have s/IS_ENABLED/IS_REACHABLE/.
> > It fixes issue for me.
>
> As discusse
Convert the GMA500 driver to use the new SCU IPC API. This allows us
to get rid of the duplicate PMC IPC implementation which is now covered
in SCU IPC driver.
Signed-off-by: Andy Shevchenko
Acked-by: Linus Walleij
---
drivers/gpu/drm/gma500/Kconfig | 1 +
drivers/gpu/drm/gma500
Since GPIOs are optional we don't need to repeat checks that are done
in the GPIO API. Remove them for good.
Signed-off-by: Andy Shevchenko
Acked-by: Linus Walleij
---
drivers/gpu/drm/gma500/tc35876x-dsi-lvds.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
On Fri, Jan 22, 2021 at 03:16:55PM +0100, Patrik Jakobsson wrote:
> On Fri, Jan 22, 2021 at 12:39 PM Andy Shevchenko
> wrote:
> >
> > Convert the GMA500 driver to use the new SCU IPC API. This allows us
> > to get rid of the duplicate PMC IPC implementation which is no
On Fri, Jan 22, 2021 at 04:15:33PM +0100, Patrik Jakobsson wrote:
> On Fri, Jan 22, 2021 at 3:51 PM Andy Shevchenko
> wrote:
> >
> > On Fri, Jan 22, 2021 at 03:16:55PM +0100, Patrik Jakobsson wrote:
> > > On Fri, Jan 22, 2021 at 12:39 PM Andy Shevchenko
> > >
d can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the co
On Thu, Feb 4, 2021 at 11:04 AM Andy Shevchenko
wrote:
>> Today's linux-next merge of the drivers-x86 tree got a conflict in:
>
> Thanks. I already asked Patrik yesterday day if DRM missed to pull an
> immutable tag I provided. I think they can pull and resolve con
On Fri, Feb 5, 2021 at 3:05 PM Daniel Vetter wrote:
> On Fri, Feb 5, 2021 at 12:14 PM Patrik Jakobsson
> wrote:
> >
> > On Fri, Feb 5, 2021 at 12:07 PM Andy Shevchenko
> > wrote:
> > >
> > > On Thu, Feb 4, 2021 at 11:04 AM Andy Shevchenko
> > &g
ually needed for such patches.
That's why I don't like churn produced by people who often even didn't
compile their useful contributions.
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
hat the drm-misc tree is merged before the pm
> tree (or the drivers-x86 tree). Or you need to include module.h in
> mdfld_output.c before intel_scu_ipc.h (or in intel_scu_ipc.h itself).
Thanks for the report.
I guess the DRM tree should carry this burden, or they can merge the
immutable tag themselve
+Cc: Patrik (JFYI).
On Mon, Feb 15, 2021 at 12:23 PM Andy Shevchenko
wrote:
>
> On Mon, Feb 15, 2021 at 2:45 AM Stephen Rothwell
> wrote:
> >
> > Hi all,
> >
> > After merging the pm tree, today's linux-next build (x86_64 allmodconfig)
> > produced
We have already an implementation and a lot of code that can benefit
of the enableddisabled() helper. Move it under string.h hood.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/i915_utils.h | 5 -
include/linux/string.h| 5 +
2 files changed, 5 insertions(+), 5
We have already few similar implementation and a lot of code that can benefit
of the yesno() helper. Consolidate yesno() helpers under string.h hood.
Signed-off-by: Andy Shevchenko
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c| 6 +-
drivers/gpu/drm/i915/i915_utils.h
We have already an implementation and a lot of code that can benefit
of the onoff() helper. Move it under string.h hood.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/i915_utils.h | 5 -
include/linux/string.h| 5 +
2 files changed, 5 insertions(+), 5 deletions
+Cc: Sakari and printk people
On Mon, Feb 15, 2021 at 4:28 PM Christian König
wrote:
> Am 15.02.21 um 15:21 schrieb Andy Shevchenko:
> > We have already few similar implementation and a lot of code that can
> > benefit
> > of the yesno() helper. Consolidate yesno() helper
On Mon, Feb 15, 2021 at 04:37:50PM +0200, Jani Nikula wrote:
> On Mon, 15 Feb 2021, Andy Shevchenko
> wrote:
> > We have already few similar implementation and a lot of code that can
> > benefit
> > of the yesno() helper. Consolidate yesno() helpers under string.h hood
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.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 24
171,10 @@ static int byt_gpio_direction_input(struct gpio_chip
*chip, unsigned int offset)
static int byt_gpio_direction_output(struct gpio_chip *chip,
unsigned int offset, int value)
{
- int ret = pinctrl_gpio_direction_output(chip-&g
On Tue, Jun 02, 2020 at 06:23:17PM +0300, Andy Shevchenko wrote:
> On Tue, Jun 02, 2020 at 02:21:30PM +0200, Hans de Goede wrote:
...
> Wouldn't be simple below fix the issue?
>
> @@ -1171,14 +1171,10 @@ static int byt_gpio_direction_input(struct gpio_chip
> *chip,
On Fri, Jun 05, 2020 at 04:33:47PM +0200, Hans de Goede wrote:
> On 6/2/20 5:23 PM, Andy Shevchenko wrote:
> > On Tue, Jun 02, 2020 at 02:21:30PM +0200, Hans de Goede wrote:
> > > The pins on the Bay Trail SoC have separate input-buffer and output-buffer
> > > enable b
On Fri, Jun 05, 2020 at 07:31:35PM +0200, Hans de Goede wrote:
> On 6/5/20 7:09 PM, Andy Shevchenko wrote:
> > On Fri, Jun 05, 2020 at 04:33:47PM +0200, Hans de Goede wrote:
> > > On 6/2/20 5:23 PM, Andy Shevchenko wrote:
> > > > On Tue, Jun 02, 2020 at 02:21:3
E_CTX | LPSS_SAVE_CTX_ONCE))
> lpss_deassert_reset(pdata);
>
> +#ifdef CONFIG_PM
> + if (pdata->dev_desc->flags & LPSS_SAVE_CTX_ONCE)
> + acpi_lpss_save_ctx(dev, pdata);
> +#endif
> +
> return 0;
> }
>
> @@
is part I don't understand. Why we limiting base unit? I seems like a
deliberate regression.
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
e tested on various platforms to see
how it affects on them.
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Mon, Jun 08, 2020 at 01:07:12PM +0200, Hans de Goede wrote:
> On 6/8/20 5:50 AM, Andy Shevchenko wrote:
> > On Sun, Jun 07, 2020 at 08:18:28PM +0200, Hans de Goede wrote:
> > > When the user requests a high enough period ns value, then the
> > > calculations in pwm_
On Mon, Jun 08, 2020 at 01:13:01PM +0200, Hans de Goede wrote:
> On 6/8/20 5:55 AM, Andy Shevchenko wrote:
> > On Sun, Jun 07, 2020 at 08:18:29PM +0200, Hans de Goede wrote:
> > > According to the data-sheet the way the PWM controller works is that
> > > each input clo
...
> +#define NSEC_PER_MHZ 1000
This is against physics. What this cryptic name means actually?
Existing NSEC_PER_USEC ?
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
}
You can reduce ping-pong format of the series if you introduced this helper in
the patch that adds -1 to clock divisor.
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Sun, Jun 07, 2020 at 08:18:36PM +0200, Hans de Goede wrote:
> Implement the pwm_ops.get_state() method to complete the support for the
> new atomic PWM API.
This one is good.
Reviewed-by: Andy Shevchenko
> Signed-off-by: Hans de Goede
> ---
> drivers/pwm
clk_div--;
And again... :-(
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, Jun 09, 2020 at 03:44:18PM +0200, Hans de Goede wrote:
> On 6/9/20 1:32 PM, Andy Shevchenko wrote:
> > On Sun, Jun 07, 2020 at 08:18:35PM +0200, Hans de Goede wrote:
...
> > And again... :-(
>
> Well yes I cannot help it that the original code, as submitted by
On Fri, Jun 12, 2020 at 12:12:42AM +0200, Uwe Kleine-König wrote:
> On Mon, Jun 08, 2020 at 01:07:12PM +0200, Hans de Goede wrote:
> > On 6/8/20 5:50 AM, Andy Shevchenko wrote:
> > > On Sun, Jun 07, 2020 at 08:18:28PM +0200, Hans de Goede wrote:
> > > > When the user
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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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_
do_div(on_time_div, 255);
> + state->duty_cycle = on_time_div;
> + }
--
With Best Regards,
Andy Shevchenko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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
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?
>
1 - 100 of 371 matches
Mail list logo
