* Re: [RESEND PATCH v2 9/9] ath5k: Constify ioreadX() iomem argument (as in generic implementation)
From: Jiri Slaby @ 2020-02-20 9:48 UTC (permalink / raw)
To: Krzysztof Kozlowski, Richard Henderson, Ivan Kokshaysky,
Matt Turner, Alexey Brodkin, Vineet Gupta, James E.J. Bottomley,
Helge Deller, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Yoshinori Sato, Rich Felker, Dave Airlie,
David Airlie, Daniel Vetter, Ben Skeggs, Mauro Carvalho Chehab,
Nick Kossifidis, Luis Chamberlain, Kalle Valo, David S. Miller,
Dave Jiang
In-Reply-To: <20200219175007.13627-10-krzk@kernel.org>
On 19. 02. 20, 18:50, Krzysztof Kozlowski wrote:
> The ioreadX() helpers have inconsistent interface. On some architectures
> void *__iomem address argument is a pointer to const, on some not.
>
> Implementations of ioreadX() do not modify the memory under the address
> so they can be converted to a "const" version for const-safety and
> consistency among architectures.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> Acked-by: Kalle Valo <kvalo@codeaurora.org>
> ---
> drivers/net/wireless/ath/ath5k/ahb.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/ahb.c b/drivers/net/wireless/ath/ath5k/ahb.c
> index 2c9cec8b53d9..8bd01df369fb 100644
> --- a/drivers/net/wireless/ath/ath5k/ahb.c
> +++ b/drivers/net/wireless/ath/ath5k/ahb.c
> @@ -138,18 +138,18 @@ static int ath_ahb_probe(struct platform_device *pdev)
>
> if (bcfg->devid >= AR5K_SREV_AR2315_R6) {
> /* Enable WMAC AHB arbitration */
> - reg = ioread32((void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
> + reg = ioread32((const void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
While I understand why the parameter of ioread32 should be const, I
don't see a reason for these casts on the users' side. What does it
bring except longer code to read?
thanks,
--
js
^ permalink raw reply
* Re: [RESEND PATCH v2 9/9] ath5k: Constify ioreadX() iomem argument (as in generic implementation)
From: Jiri Slaby @ 2020-02-20 9:48 UTC (permalink / raw)
To: Krzysztof Kozlowski, Richard Henderson, Ivan Kokshaysky,
Matt Turner, Alexey Brodkin, Vineet Gupta, James E.J. Bottomley,
Helge Deller, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Yoshinori Sato, Rich Felker, Dave Airlie,
David Airlie, Daniel Vetter, Ben Skeggs, Mauro Carvalho Chehab,
Nick Kossifidis, Luis Chamberlain, Kalle Valo, David S. Miller,
Dave Jiang
In-Reply-To: <20200219175007.13627-10-krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On 19. 02. 20, 18:50, Krzysztof Kozlowski wrote:
> The ioreadX() helpers have inconsistent interface. On some architectures
> void *__iomem address argument is a pointer to const, on some not.
>
> Implementations of ioreadX() do not modify the memory under the address
> so they can be converted to a "const" version for const-safety and
> consistency among architectures.
>
> Signed-off-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Acked-by: Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
> drivers/net/wireless/ath/ath5k/ahb.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/ahb.c b/drivers/net/wireless/ath/ath5k/ahb.c
> index 2c9cec8b53d9..8bd01df369fb 100644
> --- a/drivers/net/wireless/ath/ath5k/ahb.c
> +++ b/drivers/net/wireless/ath/ath5k/ahb.c
> @@ -138,18 +138,18 @@ static int ath_ahb_probe(struct platform_device *pdev)
>
> if (bcfg->devid >= AR5K_SREV_AR2315_R6) {
> /* Enable WMAC AHB arbitration */
> - reg = ioread32((void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
> + reg = ioread32((const void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
While I understand why the parameter of ioread32 should be const, I
don't see a reason for these casts on the users' side. What does it
bring except longer code to read?
thanks,
--
js
^ permalink raw reply
* Re: [RESEND PATCH v2 9/9] ath5k: Constify ioreadX() iomem argument (as in generic implementation)
From: Jiri Slaby @ 2020-02-20 9:48 UTC (permalink / raw)
To: Krzysztof Kozlowski, Richard Henderson, Ivan Kokshaysky,
Matt Turner, Alexey Brodkin, Vineet Gupta, James E.J. Bottomley,
Helge Deller, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Yoshinori Sato, Rich Felker, Dave Airlie,
David Airlie, Daniel Vetter, Ben Skeggs, Mauro Carvalho Chehab,
Nick Kossifidis, Luis Chamberlain, Kalle Valo, David S. Miller,
Dave Jiang, Jon Mason, Allen Hubbe, Michael S. Tsirkin,
Jason Wang, Arnd Bergmann, Geert Uytterhoeven, Andrew Morton,
Thomas Gleixner, linux-alpha, linux-kernel, linux-snps-arc,
linux-parisc, linuxppc-dev, linux-sh, dri-devel, nouveau,
linux-media, linux-wireless, netdev, linux-ntb, virtualization,
linux-arch
In-Reply-To: <20200219175007.13627-10-krzk@kernel.org>
On 19. 02. 20, 18:50, Krzysztof Kozlowski wrote:
> The ioreadX() helpers have inconsistent interface. On some architectures
> void *__iomem address argument is a pointer to const, on some not.
>
> Implementations of ioreadX() do not modify the memory under the address
> so they can be converted to a "const" version for const-safety and
> consistency among architectures.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> Acked-by: Kalle Valo <kvalo@codeaurora.org>
> ---
> drivers/net/wireless/ath/ath5k/ahb.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/ahb.c b/drivers/net/wireless/ath/ath5k/ahb.c
> index 2c9cec8b53d9..8bd01df369fb 100644
> --- a/drivers/net/wireless/ath/ath5k/ahb.c
> +++ b/drivers/net/wireless/ath/ath5k/ahb.c
> @@ -138,18 +138,18 @@ static int ath_ahb_probe(struct platform_device *pdev)
>
> if (bcfg->devid >= AR5K_SREV_AR2315_R6) {
> /* Enable WMAC AHB arbitration */
> - reg = ioread32((void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
> + reg = ioread32((const void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
While I understand why the parameter of ioread32 should be const, I
don't see a reason for these casts on the users' side. What does it
bring except longer code to read?
thanks,
--
js
^ permalink raw reply
* Re: [RESEND PATCH v2 9/9] ath5k: Constify ioreadX() iomem argument (as in generic implementation)
From: Jiri Slaby @ 2020-02-20 9:48 UTC (permalink / raw)
To: Krzysztof Kozlowski, Richard Henderson, Ivan Kokshaysky,
Matt Turner, Alexey Brodkin, Vineet Gupta, James E.J. Bottomley,
Helge Deller, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Yoshinori Sato, Rich Felker, Dave Airlie,
David Airlie, Daniel Vetter, Ben Skeggs, Mauro Carvalho Chehab,
Nick Kossifidis, Lui
In-Reply-To: <20200219175007.13627-10-krzk@kernel.org>
On 19. 02. 20, 18:50, Krzysztof Kozlowski wrote:
> The ioreadX() helpers have inconsistent interface. On some architectures
> void *__iomem address argument is a pointer to const, on some not.
>
> Implementations of ioreadX() do not modify the memory under the address
> so they can be converted to a "const" version for const-safety and
> consistency among architectures.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> Acked-by: Kalle Valo <kvalo@codeaurora.org>
> ---
> drivers/net/wireless/ath/ath5k/ahb.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/ahb.c b/drivers/net/wireless/ath/ath5k/ahb.c
> index 2c9cec8b53d9..8bd01df369fb 100644
> --- a/drivers/net/wireless/ath/ath5k/ahb.c
> +++ b/drivers/net/wireless/ath/ath5k/ahb.c
> @@ -138,18 +138,18 @@ static int ath_ahb_probe(struct platform_device *pdev)
>
> if (bcfg->devid >= AR5K_SREV_AR2315_R6) {
> /* Enable WMAC AHB arbitration */
> - reg = ioread32((void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
> + reg = ioread32((const void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
While I understand why the parameter of ioread32 should be const, I
don't see a reason for these casts on the users' side. What does it
bring except longer code to read?
thanks,
--
js
^ permalink raw reply
* Re: [PATCHv5 02/34] drm/gem-fb-helper: Allow drivers to allocate struct drm_framebuffer on their own
From: Boris Brezillon @ 2020-02-20 9:47 UTC (permalink / raw)
To: Andrzej Pietrasiewicz
Cc: kernel, Mihail Atanassov, David Airlie, Liviu Dudau, Sandy Huang,
dri-devel, James Wang, Ayan Halder, Sean Paul
In-Reply-To: <20191217145020.14645-3-andrzej.p@collabora.com>
On Tue, 17 Dec 2019 15:49:48 +0100
Andrzej Pietrasiewicz <andrzej.p@collabora.com> wrote:
> +/**
> + * drm_gem_fb_size_check() - Helper function for use in
> + * &drm_mode_config_funcs.fb_create implementations
> + * @dev: DRM device
> + * @mode_cmd: Metadata from the userspace framebuffer creation request
> + *
> + * This function can be used to verify buffer sizes for all planes.
> + * It is caller's responsibility to put the objects on failure.
> + *
> + * Returns:
> + * Zero on success or a negative error code on failure.
> + */
> +int drm_gem_fb_size_check(struct drm_device *dev,
> + const struct drm_mode_fb_cmd2 *mode_cmd,
> + struct drm_gem_object **objs)
Maybe we should rename that one drm_gem_fb_linear_size_check().
> +{
> + const struct drm_format_info *info;
> + int i;
> +
> + info = drm_get_format_info(dev, mode_cmd);
> + if (!info)
> + return -EINVAL;
> +
> + for (i = 0; i < info->num_planes; i++) {
> + unsigned int width = mode_cmd->width / (i ? info->hsub : 1);
> + unsigned int height = mode_cmd->height / (i ? info->vsub : 1);
> + unsigned int min_size;
> +
> + min_size = (height - 1) * mode_cmd->pitches[i]
> + + drm_format_info_min_pitch(info, i, width)
> + + mode_cmd->offsets[i];
> +
> + if (objs[i]->size < min_size)
> + return -EINVAL;
> + }
> +
> + return 0;
> +
> +}
> +EXPORT_SYMBOL_GPL(drm_gem_fb_size_check);
> +
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: usb cdc-acm TIOCSSERIAL may wrongly report EPERM
From: Oliver Neukum @ 2020-02-20 9:46 UTC (permalink / raw)
To: Anthony Mallet; +Cc: linux-usb
In-Reply-To: <24141.6739.313167.448875@beetle.laas.fr>
^ permalink raw reply
* Re: [PATCH] mm: memcontrol: asynchronous reclaim for memory.high
From: Michal Hocko @ 2020-02-20 9:46 UTC (permalink / raw)
To: Johannes Weiner
Cc: Andrew Morton, Tejun Heo, Roman Gushchin, linux-mm, cgroups,
linux-kernel, kernel-team
In-Reply-To: <20200219211735.GD54486@cmpxchg.org>
On Wed 19-02-20 16:17:35, Johannes Weiner wrote:
> On Wed, Feb 19, 2020 at 08:53:32PM +0100, Michal Hocko wrote:
> > On Wed 19-02-20 14:16:18, Johannes Weiner wrote:
[...]
> > > [ This is generally work in process: for example, if you isolate
> > > workloads with memory.low, kswapd cpu time isn't accounted to the
> > > cgroup that causes it. Swap IO issued by kswapd isn't accounted to
> > > the group that is getting swapped.
> >
> > Well, kswapd is a system activity and as such it is acceptable that it
> > is accounted to the system. But in this case we are talking about a
> > memcg configuration which influences all other workloads by stealing CPU
> > cycles from them
>
> From a user perspective this isn't a meaningful distinction.
>
> If I partition my memory among containers and one cgroup is acting
> out, I would want the culprit to be charged for the cpu cycles the
> reclaim is causing. Whether I divide my machine up using memory.low or
> using memory.max doesn't really matter: I'm choosing between the two
> based on a *memory policy* I want to implement - work-conserving vs
> non-conserving. I shouldn't have to worry about the kernel tracking
> CPU cycles properly in the respective implementations of these knobs.
>
> So kswapd is very much a cgroup-attributable activity, *especially* if
> I'm using memory.low to delineate different memory domains.
While I understand what you are saying I do not think this is easily
achievable with the current implementation. The biggest problem I can
see is that you do not have a clear information who to charge for
the memory shortage on a particular NUMA node with a pure low limit
based balancing because the limit is not NUMA aware. Besides that the
origin of the memory pressure might be outside of any memcg. You can
punish/account all memcgs in excess in some manner, e.g. proportionally
to their size/excess but I am not really sure how fair that will
be. Sounds like an interesting project but also sounds like tangent to
this patch.
High/Max limits are quite different because they are dealing with
the internal memory pressure and you can attribute it to the
cgroup/hierarchy which is in excess. There is a clear domain to reclaim
from. This is an easier model to reason about IMHO.
> > without much throttling on the consumer side - especially when the
> > memory is reclaimable without a lot of sleeping or contention on
> > locks etc.
>
> The limiting factor on the consumer side is IO. Reading a page is way
> more costly than reclaiming it, which is why we built our isolation
> stack starting with memory and IO control and are only now getting to
> working on proper CPU isolation.
>
> > I am absolutely aware that we will never achieve a perfect isolation due
> > to all sorts of shared data structures, lock contention and what not but
> > this patch alone just allows spill over to unaccounted work way too
> > easily IMHO.
>
> I understand your concern about CPU cycles escaping, and I share
> it. My point is that this patch isn't adding a problem that isn't
> already there, nor is it that much of a practical concern at the time
> of this writing given the state of CPU isolation in general.
I beg to differ here. Ppu controller should be able to isolate user
contexts performing high limit reclaim now. Your patch is changing that
functionality to become unaccounted for a large part and that might be
seen as a regression for those workloads which partition the system by
using high limit and also rely on cpu controller because workloads are
CPU sensitive.
Without the CPU controller support this patch is not complete and I do
not see an absolute must to marge it ASAP because it is not a regression
fix or something we cannot live without.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH] mm: memcontrol: asynchronous reclaim for memory.high
From: Michal Hocko @ 2020-02-20 9:46 UTC (permalink / raw)
To: Johannes Weiner
Cc: Andrew Morton, Tejun Heo, Roman Gushchin,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg, cgroups-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, kernel-team-b10kYP2dOMg
In-Reply-To: <20200219211735.GD54486-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
On Wed 19-02-20 16:17:35, Johannes Weiner wrote:
> On Wed, Feb 19, 2020 at 08:53:32PM +0100, Michal Hocko wrote:
> > On Wed 19-02-20 14:16:18, Johannes Weiner wrote:
[...]
> > > [ This is generally work in process: for example, if you isolate
> > > workloads with memory.low, kswapd cpu time isn't accounted to the
> > > cgroup that causes it. Swap IO issued by kswapd isn't accounted to
> > > the group that is getting swapped.
> >
> > Well, kswapd is a system activity and as such it is acceptable that it
> > is accounted to the system. But in this case we are talking about a
> > memcg configuration which influences all other workloads by stealing CPU
> > cycles from them
>
> From a user perspective this isn't a meaningful distinction.
>
> If I partition my memory among containers and one cgroup is acting
> out, I would want the culprit to be charged for the cpu cycles the
> reclaim is causing. Whether I divide my machine up using memory.low or
> using memory.max doesn't really matter: I'm choosing between the two
> based on a *memory policy* I want to implement - work-conserving vs
> non-conserving. I shouldn't have to worry about the kernel tracking
> CPU cycles properly in the respective implementations of these knobs.
>
> So kswapd is very much a cgroup-attributable activity, *especially* if
> I'm using memory.low to delineate different memory domains.
While I understand what you are saying I do not think this is easily
achievable with the current implementation. The biggest problem I can
see is that you do not have a clear information who to charge for
the memory shortage on a particular NUMA node with a pure low limit
based balancing because the limit is not NUMA aware. Besides that the
origin of the memory pressure might be outside of any memcg. You can
punish/account all memcgs in excess in some manner, e.g. proportionally
to their size/excess but I am not really sure how fair that will
be. Sounds like an interesting project but also sounds like tangent to
this patch.
High/Max limits are quite different because they are dealing with
the internal memory pressure and you can attribute it to the
cgroup/hierarchy which is in excess. There is a clear domain to reclaim
from. This is an easier model to reason about IMHO.
> > without much throttling on the consumer side - especially when the
> > memory is reclaimable without a lot of sleeping or contention on
> > locks etc.
>
> The limiting factor on the consumer side is IO. Reading a page is way
> more costly than reclaiming it, which is why we built our isolation
> stack starting with memory and IO control and are only now getting to
> working on proper CPU isolation.
>
> > I am absolutely aware that we will never achieve a perfect isolation due
> > to all sorts of shared data structures, lock contention and what not but
> > this patch alone just allows spill over to unaccounted work way too
> > easily IMHO.
>
> I understand your concern about CPU cycles escaping, and I share
> it. My point is that this patch isn't adding a problem that isn't
> already there, nor is it that much of a practical concern at the time
> of this writing given the state of CPU isolation in general.
I beg to differ here. Ppu controller should be able to isolate user
contexts performing high limit reclaim now. Your patch is changing that
functionality to become unaccounted for a large part and that might be
seen as a regression for those workloads which partition the system by
using high limit and also rely on cpu controller because workloads are
CPU sensitive.
Without the CPU controller support this patch is not complete and I do
not see an absolute must to marge it ASAP because it is not a regression
fix or something we cannot live without.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH v3] trace-cmd: Clear synthetic events on reset subcommand
From: Tzvetomir Stoyanov (VMware) @ 2020-02-20 9:46 UTC (permalink / raw)
To: rostedt; +Cc: linux-trace-devel
The "trace-cmd reset" command is supposed to set the ftrace state to default.
However, the synthetic events are not reseted.
A logic is added to delete all entries from "synthetic_events" files.
Signed-off-by: Tzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com>
---
v3: remove the warning in case there are no configured synthetic events
v2: remove the patch from "SQL-like syntax for ftrace histograms configuration" patch set
---
tracecmd/trace-record.c | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/tracecmd/trace-record.c b/tracecmd/trace-record.c
index 4a49b640..881efe44 100644
--- a/tracecmd/trace-record.c
+++ b/tracecmd/trace-record.c
@@ -4638,6 +4638,41 @@ static void clear_triggers(void)
clear_instance_triggers(instance);
}
+static void clear_all_synth_events(void)
+{
+ char sevent[BUFSIZ];
+ char *save = NULL;
+ char *line;
+ char *file;
+ char *buf;
+ int len;
+
+ file = tracefs_instance_get_file(NULL, "synthetic_events");
+ if (!file)
+ return;
+
+ buf = read_file(file);
+ if (!buf)
+ goto out;
+
+ sevent[0] = '!';
+
+ for (line = strtok_r(buf, "\n", &save); line; line = strtok_r(NULL, "\n", &save)) {
+ len = strlen(line);
+ if (len > BUFSIZ - 2)
+ len = BUFSIZ - 2;
+ strncpy(sevent + 1, line, len);
+ sevent[len + 1] = '\0';
+ write_file(file, sevent);
+ }
+out:
+ free(buf);
+ tracefs_put_tracing_file(file);
+
+}
+
+
+
static void clear_func_filters(void)
{
struct buffer_instance *instance;
@@ -5344,6 +5379,7 @@ void trace_reset(int argc, char **argv)
set_buffer_size();
clear_filters();
clear_triggers();
+ clear_all_synth_events();
/* set clock to "local" */
reset_clock();
reset_event_pid();
--
2.24.1
^ permalink raw reply related
* Re: [PATCH 1/3] btrfs: Call btrfs_check_uuid_tree_entry directly in btrfs_uuid_tree_iterate
From: Johannes Thumshirn @ 2020-02-20 9:45 UTC (permalink / raw)
To: Nikolay Borisov, linux-btrfs@vger.kernel.org
In-Reply-To: <20200218145609.13427-2-nborisov@suse.com>
Looks good,
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
^ permalink raw reply
* Re: [PATCH] console: make QMP screendump use coroutine
From: Marc-André Lureau @ 2020-02-20 9:43 UTC (permalink / raw)
To: Markus Armbruster; +Cc: Kevin Wolf, QEMU, Gerd Hoffmann
In-Reply-To: <87a75dn1gd.fsf@dusky.pond.sub.org>
Hi
On Thu, Feb 20, 2020 at 8:49 AM Markus Armbruster <armbru@redhat.com> wrote:
>
> Marc-André Lureau <marcandre.lureau@redhat.com> writes:
>
> > Thanks to the QMP coroutine support, the screendump handler can
> > trigger a graphic_hw_update(), yield and let the main loop run until
> > update is done. Then the handler is resumed, and the ppm_save() will
> > write the screen image to disk in the coroutine context (thus
> > non-blocking).
> >
> > For now, HMP doesn't have coroutine support, so it remains potentially
> > outdated or glitched.
> >
> > Fixes:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1230527
> >
> > Based-on: <20200109183545.27452-2-kwolf@redhat.com>
> >
> > Cc: Kevin Wolf <kwolf@redhat.com>
> > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > ---
> > qapi/ui.json | 3 ++-
> > ui/console.c | 35 +++++++++++++++++++++++++++--------
> > ui/trace-events | 2 +-
> > 3 files changed, 30 insertions(+), 10 deletions(-)
> >
> > diff --git a/qapi/ui.json b/qapi/ui.json
> > index e04525d8b4..d941202f34 100644
> > --- a/qapi/ui.json
> > +++ b/qapi/ui.json
> > @@ -96,7 +96,8 @@
> > #
> > ##
> > { 'command': 'screendump',
> > - 'data': {'filename': 'str', '*device': 'str', '*head': 'int'} }
> > + 'data': {'filename': 'str', '*device': 'str', '*head': 'int'},
> > + 'coroutine': true }
> >
> > ##
> > # == Spice
> > diff --git a/ui/console.c b/ui/console.c
> > index ac79d679f5..db184b473f 100644
> > --- a/ui/console.c
> > +++ b/ui/console.c
> > @@ -167,6 +167,7 @@ struct QemuConsole {
> > QEMUFIFO out_fifo;
> > uint8_t out_fifo_buf[16];
> > QEMUTimer *kbd_timer;
> > + Coroutine *screendump_co;
> >
> > QTAILQ_ENTRY(QemuConsole) next;
> > };
> > @@ -194,7 +195,6 @@ static void dpy_refresh(DisplayState *s);
> > static DisplayState *get_alloc_displaystate(void);
> > static void text_console_update_cursor_timer(void);
> > static void text_console_update_cursor(void *opaque);
> > -static bool ppm_save(int fd, DisplaySurface *ds, Error **errp);
> >
> > static void gui_update(void *opaque)
> > {
> > @@ -263,6 +263,9 @@ static void gui_setup_refresh(DisplayState *ds)
> >
> > void graphic_hw_update_done(QemuConsole *con)
> > {
> > + if (con && con->screendump_co) {
>
> How can !con happen?
I don't think it can happen anymore (the patch evolved over several
years, this is probably a left-over). In any case, it doesn't hurt.
>
> > + aio_co_wake(con->screendump_co);
> > + }
> > }
> >
> > void graphic_hw_update(QemuConsole *con)
> > @@ -310,16 +313,16 @@ void graphic_hw_invalidate(QemuConsole *con)
> > }
> > }
> >
> > -static bool ppm_save(int fd, DisplaySurface *ds, Error **errp)
> > +static bool ppm_save(int fd, pixman_image_t *image, Error **errp)
> > {
> > - int width = pixman_image_get_width(ds->image);
> > - int height = pixman_image_get_height(ds->image);
> > + int width = pixman_image_get_width(image);
> > + int height = pixman_image_get_height(image);
> > g_autoptr(Object) ioc = OBJECT(qio_channel_file_new_fd(fd));
> > g_autofree char *header = NULL;
> > g_autoptr(pixman_image_t) linebuf = NULL;
> > int y;
> >
> > - trace_ppm_save(fd, ds);
> > + trace_ppm_save(fd, image);
> >
> > header = g_strdup_printf("P6\n%d %d\n%d\n", width, height, 255);
> > if (qio_channel_write_all(QIO_CHANNEL(ioc),
> > @@ -329,7 +332,7 @@ static bool ppm_save(int fd, DisplaySurface *ds, Error **errp)
> >
> > linebuf = qemu_pixman_linebuf_create(PIXMAN_BE_r8g8b8, width);
> > for (y = 0; y < height; y++) {
> > - qemu_pixman_linebuf_fill(linebuf, ds->image, width, 0, y);
> > + qemu_pixman_linebuf_fill(linebuf, image, width, 0, y);
> > if (qio_channel_write_all(QIO_CHANNEL(ioc),
> > (char *)pixman_image_get_data(linebuf),
> > pixman_image_get_stride(linebuf), errp) < 0) {
>
> Looks like an unrelated optimization / simplification. If I was
> maintainer, I'd ask for a separate patch.
I can be split, but it's related. We should pass a reference to
pixman_image_t, rather than a pointer to DisplaySurface, as the
underlying image may change over time, and would result in corrupted
coroutine save or worse.
> > @@ -340,11 +343,18 @@ static bool ppm_save(int fd, DisplaySurface *ds, Error **errp)
> > return true;
> > }
> >
> > +static void graphic_hw_update_bh(void *con)
> > +{
> > + graphic_hw_update(con);
> > +}
> > +
> > +/* may be called in coroutine context or not */
>
> Hmm.
>
> Even though the QMP core always calls in coroutine context, the comment
> is correct: hmp_screendump() calls it outside coroutine context.
> Because of that...
>
> > void qmp_screendump(const char *filename, bool has_device, const char *device,
> > bool has_head, int64_t head, Error **errp)
> > {
> > QemuConsole *con;
> > DisplaySurface *surface;
> > + g_autoptr(pixman_image_t) image = NULL;
> > int fd;
> >
> > if (has_device) {
> > @@ -365,7 +375,15 @@ void qmp_screendump(const char *filename, bool has_device, const char *device,
> > }
> > }
> >
> > - graphic_hw_update(con);
> > + if (qemu_in_coroutine()) {
> > + assert(!con->screendump_co);
>
> What if multiple QMP monitors simultaneously screendump? Hmm, it works
> because all execute one after another in the same coroutine
> qmp_dispatcher_co. Implicit mutual exclusion.
>
> Executing them one after another is bad, because it lets an ill-behaved
> QMP command starve *all* QMP monitors. We do it only out of
> (reasonable!) fear of implicit mutual exclusion requirements like the
> one you add.
>
> Let's not add more if we can help it.
The situation is not worse than the current blocking handling.
>
> Your screendump_co is per QemuConsole instead of per QMP monitor only
> because you need to find the coroutine in graphic_hw_update_done(). Can
> we somehow pass it via function arguments?
I think it could be done later, so I suggest a TODO.
> In case avoiding the mutual exclusion is impractical: please explain it
> in a comment to make it somewhat less implicit.
>
> > + con->screendump_co = qemu_coroutine_self();
> > + aio_bh_schedule_oneshot(qemu_get_aio_context(),
> > + graphic_hw_update_bh, con);
> > + qemu_coroutine_yield();
> > + con->screendump_co = NULL;
> > + }
> > +
>
> ... the command handler needs extra code to cope with either. Is this
> really what we want for coroutine QMP command handlers? We'll acquire
> more of them, and I'd hate to make each one run both in and outside
> coroutine context. Shouldn't we let the HMP core take care of this? Or
> at least have some common infrastructure these handlers can use?
We have several functions that have this dual support, for ex QIO.
Changing both QMP & HMP commands to run in coroutine is likely
additional work that we may not care at this point.
I propose to leave a TODO, once we have several similar QMP & HMP mix
cases we can try to find a common HMP solution to make the code
simpler in QMP handler.
I don't know if this is going to be a common pattern, we may end up
with conversions that can run both without explicit handling (like the
ppm_save() function, thanks to QIO).
>
> Why is it okay not to call graphic_hw_update() anymore when
> !qemu_in_coroutine()?
You could call it, but then you should wait for completion by
reentering the main loop (that was the point of my earlier qapi-async
series)
>
> If qemu_in_coroutine(), we now run graphic_hw_update() in a bottom half,
> then yield until the update completes (see graphic_hw_update_done()
> above). Can you explain the need for the bottom half?
At least spice rendering is done in a separate thread, completion is async.
>
> > surface = qemu_console_surface(con);
> > if (!surface) {
> > error_setg(errp, "no surface");
> > @@ -379,7 +397,8 @@ void qmp_screendump(const char *filename, bool has_device, const char *device,
> > return;
> > }
> >
> > - if (!ppm_save(fd, surface, errp)) {
> > + image = pixman_image_ref(surface->image);
> > + if (!ppm_save(fd, image, errp)) {
> > qemu_unlink(filename);
> > }
> > }
> > diff --git a/ui/trace-events b/ui/trace-events
> > index 0dcda393c1..e8726fc969 100644
> > --- a/ui/trace-events
> > +++ b/ui/trace-events
> > @@ -15,7 +15,7 @@ displaysurface_create_pixman(void *display_surface) "surface=%p"
> > displaysurface_free(void *display_surface) "surface=%p"
> > displaychangelistener_register(void *dcl, const char *name) "%p [ %s ]"
> > displaychangelistener_unregister(void *dcl, const char *name) "%p [ %s ]"
> > -ppm_save(int fd, void *display_surface) "fd=%d surface=%p"
> > +ppm_save(int fd, void *image) "fd=%d image=%p"
> >
> > # gtk.c
> > # gtk-gl-area.c
>
>
--
Marc-André Lureau
^ permalink raw reply
* Re: [PATCH] GPU: DRM: VC4/V3D Replace wait_for macros in to remove use of msleep
From: James Hughes @ 2020-02-20 9:44 UTC (permalink / raw)
To: Eric Anholt; +Cc: David Airlie, DRI Development, linux-kernel
In-Reply-To: <CADaigPXfS4o-QQVPsp1axNz+hAATJqA-vzupC0VRWceJNEZNEg@mail.gmail.com>
On Wed, 19 Feb 2020 at 22:51, Eric Anholt <eric@anholt.net> wrote:
>
> On Mon, Feb 17, 2020 at 7:41 AM James Hughes
> <james.hughes@raspberrypi.com> wrote:
> >
> > The wait_for macro's for Broadcom VC4 and V3D drivers used msleep
> > which is inappropriate due to its inaccuracy at low values (minimum
> > wait time is about 30ms on the Raspberry Pi).
> >
> > This patch replaces the macro with the one from the Intel i915 version
> > which uses usleep_range to provide more accurate waits.
> >
> > Signed-off-by: James Hughes <james.hughes@raspberrypi.com>
>
> To apply this, we're going to want to split the patch up between v3d
> (with a fixes tag to the introduction of the driver, since it's a
> pretty critical fix) and vc4 (where it's used in KMS, and we're pretty
> sure we want it but changing timing like this in KMS paths is risky so
> we don't want to backport to stable). And adjust the commit messages
> to have consistent prefixes to the rest of the commits to those
> drivers.
>
> I've been fighting with the drm maintainer tools today to try to apply
> the patch, with no luck. I'll keep trying, and if I succeed, I'll
> push it.
Hi Eric,
unclear whether you want me to do the split or whether you are going
to (your last paragraph). Also I'm a bit unclear on the exact
requirements for the prefixes etc.
James
^ permalink raw reply
* Re: [dpdk-dev] [PATCH] net/ice: fix queue bind MSI-X interrupt error
From: Zhu, TaoX @ 2020-02-20 9:43 UTC (permalink / raw)
To: Yigit, Ferruh, Yang, Qiming, Lu, Wenzhuo
Cc: dev@dpdk.org, Xing, Beilei, Zhang, Qi Z, Ye, Xiaolong,
stable@dpdk.org
In-Reply-To: <eff245e6-4b63-72a4-7033-2df6df806898@intel.com>
Hi Yigit, Ferruh
The original author was not found. The meaning of these bits is as follows:
ITR Index of the interrupt cause:
00b - ITR0 ; 01b - ITR1; 10b - ITR2; 11b - NoITR
I think the reason why the original author wrote this strange code is to highlight that these bits are important in this function,
he wanted to make it clear that he used ITR0 . I think it's possible, so I keep it.
BR,
Zhu, Tao
> -----Original Message-----
> From: Yigit, Ferruh
> Sent: Thursday, February 20, 2020 5:21 PM
> To: Zhu, TaoX <taox.zhu@intel.com>; Yang, Qiming
> <qiming.yang@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>
> Cc: dev@dpdk.org; Xing, Beilei <beilei.xing@intel.com>; Zhang, Qi Z
> <qi.z.zhang@intel.com>; Ye, Xiaolong <xiaolong.ye@intel.com>;
> stable@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] net/ice: fix queue bind MSI-X interrupt
> error
>
> On 2/19/2020 10:17 AM, taox.zhu@intel.com wrote:
> > From: Zhu Tao <taox.zhu@intel.com>
> >
> > To bind a queue to an MSI-X interrupt, need to set some register.
> > The register consists of many parts, each of which has several bits;
> > therefore, the shift operator '<<' was used; so the operator '<' in
> > the code should be '<<'.
> >
> > Old code adds 1 on even MSI-X interrupt vector index used by queue,
> > resulting in interrupt mapping error.
> >
> > Fixes: 65dfc889d8 ("net/ice: support Rx queue interruption")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Zhu Tao <taox.zhu@intel.com>
> > ---
> > drivers/net/ice/ice_ethdev.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ice/ice_ethdev.c
> > b/drivers/net/ice/ice_ethdev.c index 8e9369e0a..85ef83e92 100644
> > --- a/drivers/net/ice/ice_ethdev.c
> > +++ b/drivers/net/ice/ice_ethdev.c
> > @@ -2605,9 +2605,9 @@ __vsi_queues_bind_intr(struct ice_vsi *vsi,
> uint16_t msix_vect,
> > for (i = 0; i < nb_queue; i++) {
> > /*do actual bind*/
> > val = (msix_vect & QINT_RQCTL_MSIX_INDX_M) |
> > - (0 < QINT_RQCTL_ITR_INDX_S) |
> QINT_RQCTL_CAUSE_ENA_M;
> > + (0 << QINT_RQCTL_ITR_INDX_S) |
> QINT_RQCTL_CAUSE_ENA_M;
> > val_tx = (msix_vect & QINT_TQCTL_MSIX_INDX_M) |
> > - (0 < QINT_TQCTL_ITR_INDX_S) |
> QINT_TQCTL_CAUSE_ENA_M;
> > + (0 << QINT_TQCTL_ITR_INDX_S) |
> QINT_TQCTL_CAUSE_ENA_M;
>
> Hi Tao,
>
> Out of curiosity, what is the point of left shifting "0"?
^ permalink raw reply
* Re: [PATCH v7 14/24] btrfs: Convert from readpages to readahead
From: Johannes Thumshirn @ 2020-02-20 9:42 UTC (permalink / raw)
To: Matthew Wilcox, linux-fsdevel@vger.kernel.org
Cc: linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com,
linux-mm@kvack.org, ocfs2-devel@oss.oracle.com,
linux-ext4@vger.kernel.org, linux-erofs@lists.ozlabs.org,
linux-btrfs@vger.kernel.org
In-Reply-To: <20200219210103.32400-15-willy@infradead.org>
On 19/02/2020 22:03, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>
> Use the new readahead operation in btrfs. Add a
> readahead_for_each_batch() iterator to optimise the loop in the XArray.
OK I must admit I haven't followed this series closely, but what
happened to said readahead_for_each_batch()?
As far as I can see it's now:
[...]
> + while ((nr = readahead_page_batch(rac, pagepool))) {
^ permalink raw reply
* Re: [Intel-gfx] [CI v3 3/3] drm/i915/dp: Add all tiled and port sync conns to modeset
From: Shankar, Uma @ 2020-02-20 9:43 UTC (permalink / raw)
To: Navare, Manasi D, intel-gfx@lists.freedesktop.org
In-Reply-To: <20200214114126.13192-3-manasi.d.navare@intel.com>
> -----Original Message-----
> From: Intel-gfx <intel-gfx-bounces@lists.freedesktop.org> On Behalf Of Manasi
> Navare
> Sent: Friday, February 14, 2020 5:11 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [CI v3 3/3] drm/i915/dp: Add all tiled and port sync conns to
> modeset
>
> If one of the synced crtcs needs a full modeset, we need to make sure all the synced
> crtcs are forced a full modeset.
>
> v3:
> * Remove ~BIT(cpu_trans) which is a nop (Ville)
> * use get_new_crtc_state and remove error check (Ville)
>
> v2:
> * Add tiles based on cpu_trans check (Ville)
Pushed the changes to dinq, there was some conflict in this patch.
@Manasi/Ville: Can you check if the conflict resolution was ok.
Thanks Jonas for helping in getting this resolved and help on handling the merge conflicts
Regards,
Uma Shankar
> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 85 ------------
> drivers/gpu/drm/i915/display/intel_dp.c | 136 ++++++++++++++++++-
> 2 files changed, 135 insertions(+), 86 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index c8615f212e8f..8693585d8d88 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -14694,76 +14694,6 @@ static bool
> intel_cpu_transcoders_need_modeset(struct intel_atomic_state *state,
> return false;
> }
>
> -static int
> -intel_modeset_all_tiles(struct intel_atomic_state *state, int tile_grp_id) -{
> - struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> - struct drm_connector *connector;
> - struct drm_connector_list_iter conn_iter;
> - int ret = 0;
> -
> - drm_connector_list_iter_begin(&dev_priv->drm, &conn_iter);
> - drm_for_each_connector_iter(connector, &conn_iter) {
> - struct drm_connector_state *conn_state;
> - struct drm_crtc_state *crtc_state;
> -
> - if (!connector->has_tile ||
> - connector->tile_group->id != tile_grp_id)
> - continue;
> - conn_state = drm_atomic_get_connector_state(&state->base,
> - connector);
> - if (IS_ERR(conn_state)) {
> - ret = PTR_ERR(conn_state);
> - break;
> - }
> -
> - if (!conn_state->crtc)
> - continue;
> -
> - crtc_state = drm_atomic_get_crtc_state(&state->base,
> - conn_state->crtc);
> - if (IS_ERR(crtc_state)) {
> - ret = PTR_ERR(crtc_state);
> - break;
> - }
> - crtc_state->mode_changed = true;
> - ret = drm_atomic_add_affected_connectors(&state->base,
> - conn_state->crtc);
> - if (ret)
> - break;
> - }
> - drm_connector_list_iter_end(&conn_iter);
> -
> - return ret;
> -}
> -
> -static int
> -intel_atomic_check_tiled_conns(struct intel_atomic_state *state) -{
> - struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> - struct drm_connector *connector;
> - struct drm_connector_state *old_conn_state, *new_conn_state;
> - int i, ret;
> -
> - if (INTEL_GEN(dev_priv) < 11)
> - return 0;
> -
> - /* Is tiled, mark all other tiled CRTCs as needing a modeset */
> - for_each_oldnew_connector_in_state(&state->base, connector,
> - old_conn_state, new_conn_state, i) {
> - if (!connector->has_tile)
> - continue;
> - if (!intel_connector_needs_modeset(state, connector))
> - continue;
> -
> - ret = intel_modeset_all_tiles(state, connector->tile_group->id);
> - if (ret)
> - return ret;
> - }
> -
> - return 0;
> -}
> -
> /**
> * intel_atomic_check - validate state object
> * @dev: drm device
> @@ -14792,21 +14722,6 @@ static int intel_atomic_check(struct drm_device *dev,
> if (ret)
> goto fail;
>
> - /**
> - * This check adds all the connectors in current state that belong to
> - * the same tile group to a full modeset.
> - * This function directly sets the mode_changed to true and we also call
> - * drm_atomic_add_affected_connectors(). Hence we are not explicitly
> - * calling drm_atomic_helper_check_modeset() after this.
> - *
> - * Fixme: Handle some corner cases where one of the
> - * tiled connectors gets disconnected and tile info is lost but since it
> - * was previously synced to other conn, we need to add that to the modeset.
> - */
> - ret = intel_atomic_check_tiled_conns(state);
> - if (ret)
> - goto fail;
> -
> for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
> new_crtc_state, i) {
> if (!needs_modeset(new_crtc_state)) { diff --git
> a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index f4dede6253f8..27ffbaab8296 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -6582,6 +6582,140 @@ void intel_dp_encoder_reset(struct drm_encoder
> *encoder)
> }
> }
>
> +static int intel_modeset_tile_group(struct intel_atomic_state *state,
> + int tile_group_id)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + struct drm_connector_list_iter conn_iter;
> + struct drm_connector *connector;
> + int ret = 0;
> +
> + drm_connector_list_iter_begin(&dev_priv->drm, &conn_iter);
> + drm_for_each_connector_iter(connector, &conn_iter) {
> + struct drm_connector_state *conn_state;
> + struct intel_crtc_state *crtc_state;
> + struct intel_crtc *crtc;
> +
> + if (!connector->has_tile ||
> + connector->tile_group->id != tile_group_id)
> + continue;
> +
> + conn_state = drm_atomic_get_connector_state(&state->base,
> + connector);
> + if (IS_ERR(conn_state)) {
> + ret = PTR_ERR(conn_state);
> + break;
> + }
> +
> + crtc = to_intel_crtc(conn_state->crtc);
> +
> + if (!crtc)
> + continue;
> +
> + crtc_state = intel_atomic_get_new_crtc_state(state, crtc);
> + crtc_state->uapi.mode_changed = true;
> +
> + ret = drm_atomic_add_affected_planes(&state->base, &crtc-
> >base);
> + if (ret)
> + break;
> + }
> + drm_connector_list_iter_begin(&dev_priv->drm, &conn_iter);
> +
> + return ret;
> +}
> +
> +static int intel_modeset_affected_transcoders(struct intel_atomic_state
> +*state, u8 transcoders) {
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + struct intel_crtc *crtc;
> +
> + if (transcoders == 0)
> + return 0;
> +
> + for_each_intel_crtc(&dev_priv->drm, crtc) {
> + struct intel_crtc_state *crtc_state;
> + int ret;
> +
> + crtc_state = intel_atomic_get_crtc_state(&state->base, crtc);
> + if (IS_ERR(crtc_state))
> + return PTR_ERR(crtc_state);
> +
> + if (!crtc_state->hw.enable)
> + continue;
> +
> + if (!(transcoders & BIT(crtc_state->cpu_transcoder)))
> + continue;
> +
> + crtc_state->uapi.mode_changed = true;
> +
> + ret = drm_atomic_add_affected_connectors(&state->base, &crtc-
> >base);
> + if (ret)
> + return ret;
> +
> + ret = drm_atomic_add_affected_planes(&state->base, &crtc-
> >base);
> + if (ret)
> + return ret;
> +
> + transcoders &= ~BIT(crtc_state->cpu_transcoder);
> + }
> +
> + WARN_ON(transcoders != 0);
> +
> + return 0;
> +}
> +
> +static int intel_modeset_synced_crtcs(struct intel_atomic_state *state,
> + struct drm_connector *connector) {
> + const struct drm_connector_state *old_conn_state =
> + drm_atomic_get_old_connector_state(&state->base, connector);
> + const struct intel_crtc_state *old_crtc_state;
> + struct intel_crtc *crtc;
> + u8 transcoders;
> +
> + crtc = to_intel_crtc(old_conn_state->crtc);
> + if (!crtc)
> + return 0;
> +
> + old_crtc_state = intel_atomic_get_old_crtc_state(state, crtc);
> +
> + if (!old_crtc_state->hw.active)
> + return 0;
> +
> + transcoders = old_crtc_state->sync_mode_slaves_mask;
> + if (old_crtc_state->master_transcoder != INVALID_TRANSCODER)
> + transcoders |= BIT(old_crtc_state->master_transcoder);
> +
> + return intel_modeset_affected_transcoders(state,
> + transcoders);
> +}
> +
> +static int intel_dp_connector_atomic_check(struct drm_connector *conn,
> + struct drm_atomic_state *_state) {
> + struct drm_i915_private *dev_priv = to_i915(conn->dev);
> + struct intel_atomic_state *state = to_intel_atomic_state(_state);
> + int ret;
> +
> + ret = intel_digital_connector_atomic_check(conn, &state->base);
> + if (ret)
> + return ret;
> +
> + if (INTEL_GEN(dev_priv) < 11)
> + return 0;
> +
> + if (!intel_connector_needs_modeset(state, conn))
> + return 0;
> +
> + if (conn->has_tile) {
> + ret = intel_modeset_tile_group(state, conn->tile_group->id);
> + if (ret)
> + return ret;
> + }
> +
> + return intel_modeset_synced_crtcs(state, conn); }
> +
> static const struct drm_connector_funcs intel_dp_connector_funcs = {
> .force = intel_dp_force,
> .fill_modes = drm_helper_probe_single_connector_modes,
> @@ -6598,7 +6732,7 @@ static const struct drm_connector_helper_funcs
> intel_dp_connector_helper_funcs =
> .detect_ctx = intel_dp_detect,
> .get_modes = intel_dp_get_modes,
> .mode_valid = intel_dp_mode_valid,
> - .atomic_check = intel_digital_connector_atomic_check,
> + .atomic_check = intel_dp_connector_atomic_check,
> };
>
> static const struct drm_encoder_funcs intel_dp_enc_funcs = {
> --
> 2.19.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH v2] trace-cmd: Clear synthetic events on reset subcommand
From: Tzvetomir Stoyanov (VMware) @ 2020-02-20 9:43 UTC (permalink / raw)
To: rostedt; +Cc: linux-trace-devel
The "trace-cmd reset" command is supposed to set the ftrace state to default.
However, the synthetic events are not reseted.
A logic is added to delete all entries from "synthetic_events" files.
Signed-off-by: Tzvetomir Stoyanov (VMware) <tz.stoyanov@gmail.com>
---
v2: remove the warning in case there are no configured synthetic events
---
tracecmd/trace-record.c | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/tracecmd/trace-record.c b/tracecmd/trace-record.c
index 4a49b640..881efe44 100644
--- a/tracecmd/trace-record.c
+++ b/tracecmd/trace-record.c
@@ -4638,6 +4638,41 @@ static void clear_triggers(void)
clear_instance_triggers(instance);
}
+static void clear_all_synth_events(void)
+{
+ char sevent[BUFSIZ];
+ char *save = NULL;
+ char *line;
+ char *file;
+ char *buf;
+ int len;
+
+ file = tracefs_instance_get_file(NULL, "synthetic_events");
+ if (!file)
+ return;
+
+ buf = read_file(file);
+ if (!buf)
+ goto out;
+
+ sevent[0] = '!';
+
+ for (line = strtok_r(buf, "\n", &save); line; line = strtok_r(NULL, "\n", &save)) {
+ len = strlen(line);
+ if (len > BUFSIZ - 2)
+ len = BUFSIZ - 2;
+ strncpy(sevent + 1, line, len);
+ sevent[len + 1] = '\0';
+ write_file(file, sevent);
+ }
+out:
+ free(buf);
+ tracefs_put_tracing_file(file);
+
+}
+
+
+
static void clear_func_filters(void)
{
struct buffer_instance *instance;
@@ -5344,6 +5379,7 @@ void trace_reset(int argc, char **argv)
set_buffer_size();
clear_filters();
clear_triggers();
+ clear_all_synth_events();
/* set clock to "local" */
reset_clock();
reset_event_pid();
--
2.24.1
^ permalink raw reply related
* Re: [PATCH v2] irqchip: vic: Support cascaded VIC in device tree
From: Marc Zyngier @ 2020-02-20 9:42 UTC (permalink / raw)
To: Linus Walleij; +Cc: Thomas Gleixner, Jason Cooper, linux-kernel
In-Reply-To: <20200219153644.137293-1-linus.walleij@linaro.org>
On 2020-02-19 15:36, Linus Walleij wrote:
> When transitioning some elder platforms to device tree it
> becomes necessary to cascade VIC IRQ chips off another
> interrupt controller.
>
> Tested with the cascaded VIC on the Integrator/AP attached
> logic module IM-PD1.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Queued for 5.7.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH v7 14/24] btrfs: Convert from readpages to readahead
From: Johannes Thumshirn @ 2020-02-20 9:42 UTC (permalink / raw)
To: Matthew Wilcox, linux-fsdevel@vger.kernel.org
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-erofs@lists.ozlabs.org,
linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com,
ocfs2-devel@oss.oracle.com, linux-xfs@vger.kernel.org
In-Reply-To: <20200219210103.32400-15-willy@infradead.org>
On 19/02/2020 22:03, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>
> Use the new readahead operation in btrfs. Add a
> readahead_for_each_batch() iterator to optimise the loop in the XArray.
OK I must admit I haven't followed this series closely, but what
happened to said readahead_for_each_batch()?
As far as I can see it's now:
[...]
> + while ((nr = readahead_page_batch(rac, pagepool))) {
^ permalink raw reply
* [Ocfs2-devel] [PATCH v7 14/24] btrfs: Convert from readpages to readahead
From: Johannes Thumshirn @ 2020-02-20 9:42 UTC (permalink / raw)
To: Matthew Wilcox, linux-fsdevel@vger.kernel.org
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-erofs@lists.ozlabs.org,
linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com,
ocfs2-devel@oss.oracle.com, linux-xfs@vger.kernel.org
In-Reply-To: <20200219210103.32400-15-willy@infradead.org>
On 19/02/2020 22:03, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>
> Use the new readahead operation in btrfs. Add a
> readahead_for_each_batch() iterator to optimise the loop in the XArray.
OK I must admit I haven't followed this series closely, but what
happened to said readahead_for_each_batch()?
As far as I can see it's now:
[...]
> + while ((nr = readahead_page_batch(rac, pagepool))) {
^ permalink raw reply
* [Cluster-devel] [PATCH v7 14/24] btrfs: Convert from readpages to readahead
From: Johannes Thumshirn @ 2020-02-20 9:42 UTC (permalink / raw)
To: cluster-devel.redhat.com
In-Reply-To: <20200219210103.32400-15-willy@infradead.org>
On 19/02/2020 22:03, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>
> Use the new readahead operation in btrfs. Add a
> readahead_for_each_batch() iterator to optimise the loop in the XArray.
OK I must admit I haven't followed this series closely, but what
happened to said readahead_for_each_batch()?
As far as I can see it's now:
[...]
> + while ((nr = readahead_page_batch(rac, pagepool))) {
^ permalink raw reply
* [Intel-gfx] [PATCH i-g-t 3/3] igt/kms_draw_crc: Test for a working GPU first
From: Chris Wilson @ 2020-02-20 9:41 UTC (permalink / raw)
To: intel-gfx; +Cc: igt-dev
In-Reply-To: <20200220094134.1560435-1-chris@chris-wilson.co.uk>
The draw-method-blt subtests require a working GPU, so create a subtest
group for the draw-methods, and skip the BLT group using
igt_require_gem() in its fixture.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
tests/kms_draw_crc.c | 26 ++++++++++++++++++--------
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/tests/kms_draw_crc.c b/tests/kms_draw_crc.c
index fa7433ab2..917a55432 100644
--- a/tests/kms_draw_crc.c
+++ b/tests/kms_draw_crc.c
@@ -331,14 +331,24 @@ igt_main
for (format_idx = 0; format_idx < N_FORMATS; format_idx++) {
for (method = 0; method < IGT_DRAW_METHOD_COUNT; method++) {
- for (tiling_idx = 0; tiling_idx < N_TILING_METHODS; tiling_idx++) {
- igt_subtest_f("draw-method-%s-%s-%s",
- format_str(format_idx),
- igt_draw_get_method_name(method),
- tiling_str(tiling_idx))
- draw_method_subtest(method, format_idx,
- tilings[tiling_idx]);
- } } }
+ igt_subtest_group {
+ igt_fixture {
+ if (method == IGT_DRAW_BLT)
+ igt_require_gem(drm_fd);
+ }
+
+ for (tiling_idx = 0;
+ tiling_idx < N_TILING_METHODS;
+ tiling_idx++) {
+ igt_subtest_f("draw-method-%s-%s-%s",
+ format_str(format_idx),
+ igt_draw_get_method_name(method),
+ tiling_str(tiling_idx))
+ draw_method_subtest(method,
+ format_idx,
+ tilings[tiling_idx]);
+ }
+ }}}
igt_subtest("fill-fb")
fill_fb_subtest();
--
2.25.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [Intel-gfx] [PATCH i-g-t 2/3] igt/kms_flip_tiling: Check GEM availability before use
From: Chris Wilson @ 2020-02-20 9:41 UTC (permalink / raw)
To: intel-gfx; +Cc: igt-dev
In-Reply-To: <20200220094134.1560435-1-chris@chris-wilson.co.uk>
We use the GPU to convert between tiling formats, indirectly via the
call to igt_create_pattern_fb. So before we try and execute commands on
the GPU, we should check that the GPU is available.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
tests/kms_flip_tiling.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/kms_flip_tiling.c b/tests/kms_flip_tiling.c
index 17cf816de..1465e73a1 100644
--- a/tests/kms_flip_tiling.c
+++ b/tests/kms_flip_tiling.c
@@ -154,6 +154,7 @@ igt_main
igt_fixture {
data.drm_fd = drm_open_driver_master(DRIVER_INTEL);
data.gen = intel_gen(intel_get_drm_devid(data.drm_fd));
+ igt_require_gem(data.drm_fd);
data.testformat = DRM_FORMAT_XRGB8888;
--
2.25.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [Intel-gfx] [PATCH i-g-t 1/3] igt/kms_frontbuffer_tracking: Skip over IGT_DRAW_BLT when there's no BLT
From: Chris Wilson @ 2020-02-20 9:41 UTC (permalink / raw)
To: intel-gfx; +Cc: igt-dev
If the blitter is not available, we cannot use it as a source for dirty
rectangles. We shall have to rely on the other engines to create GPU
dirty instead.
v2: Try using lots of subgroup+fixtures
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
tests/kms_frontbuffer_tracking.c | 57 ++++++++++++++++++++++++++++++--
1 file changed, 55 insertions(+), 2 deletions(-)
diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index c4b4af43a..9e00fa2e1 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -3043,6 +3043,8 @@ static void basic_subtest(const struct test_mode *t)
fb1 = params->primary.fb;
for (r = 0, method = 0; method < IGT_DRAW_METHOD_COUNT; method++) {
+ if (method == IGT_DRAW_BLT && !gem_has_blitter(drm.fd))
+ continue;
if (method == IGT_DRAW_MMAP_GTT &&
!gem_has_mappable_ggtt(drm.fd))
continue;
@@ -3275,10 +3277,11 @@ static const char *flip_str(enum flip_type flip)
continue; \
if (!opt.show_hidden && t.fbs == FBS_SHARED && \
(t.plane == PLANE_CUR || t.plane == PLANE_SPR)) \
- continue;
+ continue; \
+ igt_subtest_group {
-#define TEST_MODE_ITER_END } } } } } }
+#define TEST_MODE_ITER_END } } } } } } }
struct option long_options[] = {
{ "no-status-check", 0, 0, 's'},
@@ -3324,6 +3327,10 @@ igt_main_args("", long_options, help_str, opt_handler, NULL)
}
TEST_MODE_ITER_BEGIN(t)
+ igt_fixture {
+ if (t.method == IGT_DRAW_BLT)
+ gem_require_blitter(drm.fd);
+ }
igt_subtest_f("%s-%s-%s-%s-%s-draw-%s",
feature_str(t.feature),
pipes_str(t.pipes),
@@ -3340,6 +3347,11 @@ igt_main_args("", long_options, help_str, opt_handler, NULL)
(!opt.show_hidden && t.method != IGT_DRAW_BLT))
continue;
+ igt_fixture {
+ if (t.method == IGT_DRAW_BLT)
+ gem_require_blitter(drm.fd);
+ }
+
for (t.flip = 0; t.flip < FLIP_COUNT; t.flip++)
igt_subtest_f("%s-%s-%s-%s-%sflip-%s",
feature_str(t.feature),
@@ -3358,6 +3370,11 @@ igt_main_args("", long_options, help_str, opt_handler, NULL)
(t.feature & FEATURE_FBC) == 0)
continue;
+ igt_fixture {
+ if (t.method == IGT_DRAW_BLT)
+ gem_require_blitter(drm.fd);
+ }
+
igt_subtest_f("%s-%s-%s-fliptrack",
feature_str(t.feature),
pipes_str(t.pipes),
@@ -3371,6 +3388,11 @@ igt_main_args("", long_options, help_str, opt_handler, NULL)
t.plane == PLANE_PRI)
continue;
+ igt_fixture {
+ if (t.method == IGT_DRAW_BLT)
+ gem_require_blitter(drm.fd);
+ }
+
igt_subtest_f("%s-%s-%s-%s-%s-move",
feature_str(t.feature),
pipes_str(t.pipes),
@@ -3394,6 +3416,11 @@ igt_main_args("", long_options, help_str, opt_handler, NULL)
t.plane != PLANE_SPR)
continue;
+ igt_fixture {
+ if (t.method == IGT_DRAW_BLT)
+ gem_require_blitter(drm.fd);
+ }
+
igt_subtest_f("%s-%s-%s-%s-%s-fullscreen",
feature_str(t.feature),
pipes_str(t.pipes),
@@ -3410,6 +3437,11 @@ igt_main_args("", long_options, help_str, opt_handler, NULL)
(!opt.show_hidden && t.fbs != FBS_INDIVIDUAL))
continue;
+ igt_fixture {
+ if (t.method == IGT_DRAW_BLT)
+ gem_require_blitter(drm.fd);
+ }
+
igt_subtest_f("%s-%s-%s-%s-multidraw",
feature_str(t.feature),
pipes_str(t.pipes),
@@ -3426,6 +3458,11 @@ igt_main_args("", long_options, help_str, opt_handler, NULL)
t.method != IGT_DRAW_MMAP_GTT)
continue;
+ igt_fixture {
+ if (t.method == IGT_DRAW_BLT)
+ gem_require_blitter(drm.fd);
+ }
+
igt_subtest_f("%s-farfromfence", feature_str(t.feature))
farfromfence_subtest(&t);
TEST_MODE_ITER_END
@@ -3437,6 +3474,11 @@ igt_main_args("", long_options, help_str, opt_handler, NULL)
t.fbs != FBS_INDIVIDUAL)
continue;
+ igt_fixture {
+ if (t.method == IGT_DRAW_BLT)
+ gem_require_blitter(drm.fd);
+ }
+
for (t.format = 0; t.format < FORMAT_COUNT; t.format++) {
/* Skip what we already tested. */
if (t.format == FORMAT_DEFAULT)
@@ -3456,6 +3498,12 @@ igt_main_args("", long_options, help_str, opt_handler, NULL)
t.plane != PLANE_PRI ||
t.method != IGT_DRAW_BLT)
continue;
+
+ igt_fixture {
+ if (t.method == IGT_DRAW_BLT)
+ gem_require_blitter(drm.fd);
+ }
+
igt_subtest_f("%s-%s-scaledprimary",
feature_str(t.feature),
fbs_str(t.fbs))
@@ -3470,6 +3518,11 @@ igt_main_args("", long_options, help_str, opt_handler, NULL)
t.method != IGT_DRAW_BLT)
continue;
+ igt_fixture {
+ if (t.method == IGT_DRAW_BLT)
+ gem_require_blitter(drm.fd);
+ }
+
igt_subtest_f("%s-modesetfrombusy", feature_str(t.feature))
modesetfrombusy_subtest(&t);
--
2.25.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* Re: [dpdk-dev] [dpdk-announce] release candidate 20.02-rc3
From: Peng, Yuan @ 2020-02-20 9:41 UTC (permalink / raw)
To: Thomas Monjalon, dev@dpdk.org
In-Reply-To: <2445921.YqazSvReao@xps>
DPDK 20.02 RC3 Test Report from intel:
Summary
• Totally 9898 test cases for 20.02 RC3, 9629 cases are executed, 9428 test cases passed, 178 test cases failed, 23 test case blocked, Execution rate is 97.28%, pass rate is 97.91%.
• Totally create ~278 new tests for DPDK20.02 new features.
• New to create 9 issues from STV in RC3 till now, not include some issues have found and reported before RC3.
• Met 1 build issue on Centos 7.4 with DPDK 20.02 RC3, now it has been fixed, and patch applied.
Details:
• Intel NIC PMD PF & VF regression: 99% executed, 0 critical issue and 1 high issue is tracked(verified).
Function cases include rx/tx/forward packets, packet processing, jumboframe, dual vlan, filter cases and so on: 5 bugs found, no critical and high level.
Performance cases such as l2fwd, l3fwd, single core and so on: no new bug is found.
• Crypto cases include ipsec_gw cryptodev, fips cryptodev, l2fwd crypto, performance cases and so on: no critical and no high bugs found.
• Vhost/virtio: PVP/loopback, qemu/virtio-user, multi-queue, dequeue zero copy cases and so on: 1 new medium bug is found.
• Power relate cases, no new bug is found.
• ABI test includes unit test, vhost and flow related tests. no new bug is found.
• 20.02 new features include ABI test, L2tpv3, crypto_dev related new features and so no. no new bug is found.
• Scecurity tests include Nic malformed to PF/VF, virtio, Compreqssion/cryptodev, power and invalid command line, all passed.
Thanks.
Yuan.
-----Original Message-----
From: dev <dev-bounces@dpdk.org> On Behalf Of Thomas Monjalon
Sent: Monday, February 17, 2020 5:59 AM
To: announce@dpdk.org
Subject: [dpdk-dev] [dpdk-announce] release candidate 20.02-rc3
A new DPDK release candidate is ready for testing:
https://git.dpdk.org/dpdk/tag/?id=v20.02-rc3
121 patches were integrated.
The release notes so far:
http://doc.dpdk.org/guides/rel_notes/release_20_02.html
Some deprecation notices might be added if reviewed on time.
The -rc4 will include only bug fixes, doc and tooling.
This next milestone is expected during next week.
Please hurry up to do the last checks and bug fixes.
You may share some release validation results by replying to this message (at dev@dpdk.org).
If you are preparing the next release cycle, please send your v1 patches before the 20.05 proposal deadline, which will happen on March 18th.
It is also time to build an estimated roadmap for the next cycles.
Thank you everyone
^ permalink raw reply
* [igt-dev] [PATCH i-g-t 3/3] igt/kms_draw_crc: Test for a working GPU first
From: Chris Wilson @ 2020-02-20 9:41 UTC (permalink / raw)
To: intel-gfx; +Cc: igt-dev
In-Reply-To: <20200220094134.1560435-1-chris@chris-wilson.co.uk>
The draw-method-blt subtests require a working GPU, so create a subtest
group for the draw-methods, and skip the BLT group using
igt_require_gem() in its fixture.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
tests/kms_draw_crc.c | 26 ++++++++++++++++++--------
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/tests/kms_draw_crc.c b/tests/kms_draw_crc.c
index fa7433ab2..917a55432 100644
--- a/tests/kms_draw_crc.c
+++ b/tests/kms_draw_crc.c
@@ -331,14 +331,24 @@ igt_main
for (format_idx = 0; format_idx < N_FORMATS; format_idx++) {
for (method = 0; method < IGT_DRAW_METHOD_COUNT; method++) {
- for (tiling_idx = 0; tiling_idx < N_TILING_METHODS; tiling_idx++) {
- igt_subtest_f("draw-method-%s-%s-%s",
- format_str(format_idx),
- igt_draw_get_method_name(method),
- tiling_str(tiling_idx))
- draw_method_subtest(method, format_idx,
- tilings[tiling_idx]);
- } } }
+ igt_subtest_group {
+ igt_fixture {
+ if (method == IGT_DRAW_BLT)
+ igt_require_gem(drm_fd);
+ }
+
+ for (tiling_idx = 0;
+ tiling_idx < N_TILING_METHODS;
+ tiling_idx++) {
+ igt_subtest_f("draw-method-%s-%s-%s",
+ format_str(format_idx),
+ igt_draw_get_method_name(method),
+ tiling_str(tiling_idx))
+ draw_method_subtest(method,
+ format_idx,
+ tilings[tiling_idx]);
+ }
+ }}}
igt_subtest("fill-fb")
fill_fb_subtest();
--
2.25.1
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.