On 08/27/2015 04:32 PM, Mark Brown wrote:
On Thu, Aug 27, 2015 at 01:15:51PM +0100, Qais Yousef wrote:
On 08/26/2015 07:37 PM, Mark Brown wrote:
On Mon, Aug 24, 2015 at 01:39:12PM +0100, Qais Yousef wrote:
+#define AXD_INPUT_DESCRIPTORS 10
+struct axd_input {
+ struct axd_buffer_desc
On 08/26/2015 10:40 PM, Thomas Gleixner wrote:
On Wed, 26 Aug 2015, Qais Yousef wrote:
On 08/26/2015 04:08 PM, Thomas Gleixner wrote:
IPI = Inter Processor Interrupt
As the name says that's an interrupt which goes from one cpu to
another. So an IPI has a very clear target.
OK understoo
On 08/28/2015 03:22 PM, Thomas Gleixner wrote:
To configure your coprocessor proper, we need a translation
mechanism from the linux interrupt number to the magic value which
needs to be written into the trigger register when the coprocessor
wants to send an interrupt or an IPI
On 08/29/2015 10:47 AM, Mark Brown wrote:
On Thu, Aug 27, 2015 at 03:21:17PM +0100, Qais Yousef wrote:
On 08/26/2015 07:43 PM, Mark Brown wrote:
On Mon, Aug 24, 2015 at 01:39:14PM +0100, Qais Yousef wrote:
+ /*
+* must ensure we have one access at a time to the queue and rd_idx
On 08/29/2015 11:18 AM, Mark Brown wrote:
On Thu, Aug 27, 2015 at 04:40:09PM +0100, Qais Yousef wrote:
On 08/26/2015 08:16 PM, Mark Brown wrote:
On Mon, Aug 24, 2015 at 01:39:15PM +0100, Qais Yousef wrote:
+unsigned long axd_cmd_get_datain_address(struct axd_cmd *cmd)
+{
+ struct
This flag will be used to identify an IPI domain.
Signed-off-by: Qais Yousef
---
include/linux/irqdomain.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index d3ca79236fb0..9b3dc6c2a3cc 100644
--- a/include/linux
Introduce the new function to allow generic IPI send mechanism to be
used from drivers code.
Signed-off-by: Qais Yousef
---
include/linux/irq.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 4b537e4d393b..504133671985 100644
--- a/include
irqchip should select this config to denote it supports generic IPI.
This will aid generic arch code to know when it can use generic IPI layer.
Signed-off-by: Qais Yousef
---
kernel/irq/Kconfig | 4
1 file changed, 4 insertions(+)
diff --git a/kernel/irq/Kconfig b/kernel/irq/Kconfig
my commit messages aren't too terse.
Credit goes to Thomas for spec'ing and outlining the proper way to get this new
API in.
Qais Yousef (14):
irq: add new IRQ_DOMAIN_FLAGS_IPI
irq: add GENERIC_IRQ_IPI Kconfig symbol
irq: add new struct ipi_mask
irq: add a new irq_send_ipi() to irq_ch
We now have a generic IPI layer that will use GIC automatically
if it's compiled in.
Signed-off-by: Qais Yousef
---
arch/mips/Kconfig | 6 -
arch/mips/kernel/Makefile | 1 -
arch/mips/kernel/smp-gic.c | 64 --
3 files change
struct ipi_mapping will provide a mechanism for irqdomain/architure
code to fill out the mapping for the generic code later to implement
generic IPI reserve and send functions.
Signed-off-by: Qais Yousef
---
include/linux/irq.h | 21 +++
kernel/irq/manage.c | 59
Only the SMP variants that use GIC were converted as it's the only irqchip that
will have the support for generic IPI for now which will be introduced in
the following patches.
Signed-off-by: Qais Yousef
---
arch/mips/include/asm/smp-ops.h | 5 +++--
arch/mips/kernel/smp-cmp.c
It's now all handled in generic arch code.
Signed-off-by: Qais Yousef
---
drivers/irqchip/irq-mips-gic.c | 79
include/linux/irqchip/mips-gic.h | 3 --
2 files changed, 82 deletions(-)
diff --git a/drivers/irqchip/irq-mips-gic.c b/drivers/irqchi
There are 2 variants. __irq_desc_send_ipi() is meant to be used by arch code to
save the desc lookup when doing SMP IPIs.
irq_send_ipi() is meant for drivers that want to send IPIs to coprocessors they
interact with.
Signed-off-by: Qais Yousef
---
include/linux/irq.h | 3 +++
kernel/irq
Now irqchip has a irq_send_ipi() function, implement gic_send_ipi()
to make use of it
Signed-off-by: Qais Yousef
---
drivers/irqchip/irq-mips-gic.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-mips-gic.c b/drivers/irqchip/irq-mips
Add a new ipi domain on top of the normal domain.
We set it as the default domain to allow arch code to use it without looking up
DT.
Signed-off-by: Qais Yousef
---
drivers/irqchip/Kconfig| 2 +
drivers/irqchip/irq-mips-gic.c | 126 ++---
2 files
Use the new generic IPI layer to provide generic SMP IPI support if the irqchip
supports it.
Signed-off-by: Qais Yousef
---
arch/mips/kernel/smp.c | 117 +
1 file changed, 117 insertions(+)
diff --git a/arch/mips/kernel/smp.c b/arch/mips/kernel
Add a generic mechanism to dynamically allocate an IPI.
With this change the user can call irq_reserve_ipi() to dynamically allocate an
IPI and use the associate virq to send one to 1 or more cpus.
Signed-off-by: Qais Yousef
---
include/linux/irqdomain.h | 6
kernel/irq/irqdomain.c
cpumask is limited to NR_CPUS. introduce ipi_mask which allows us to address
cpu range that is higher than NR_CPUS which is required for drivers to send
IPIs for coprocessor that are outside Linux CPU range.
Signed-off-by: Qais Yousef
---
include/linux/irq.h | 15 +++
1 file changed
It has a similar role to affinity mask, but tracks the IPI affinity instead.
Signed-off-by: Qais Yousef
---
include/linux/irq.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 504133671985..b000b217ea24 100644
--- a/include/linux/irq.h
+++ b
On 10/13/2015 02:26 PM, Thomas Gleixner wrote:
On Tue, 13 Oct 2015, Qais Yousef wrote:
cpumask is limited to NR_CPUS. introduce ipi_mask which allows us to address
cpu range that is higher than NR_CPUS which is required for drivers to send
IPIs for coprocessor that are outside Linux CPU range
On 10/13/2015 02:31 PM, Thomas Gleixner wrote:
On Tue, 13 Oct 2015, Qais Yousef wrote:
+
+int irq_unmap_ipi(struct ipi_mapping *map,
+ unsigned int cpu, irq_hw_number_t *hwirq)
+{
+ if (cpu >= map->nr_cpus)
+ return -EINVAL;
+
+ if (map->c
On 10/13/2015 02:37 PM, Thomas Gleixner wrote:
On Tue, 13 Oct 2015, Qais Yousef wrote:
+ if (domain == NULL)
+ domain = irq_default_domain; /* need a separate
ipi_default_domain? */
No tail comments please.
We should neither use irq_default_domain nor have an
On 10/13/2015 02:40 PM, Thomas Gleixner wrote:
On Tue, 13 Oct 2015, Qais Yousef wrote:
Lacks kerneldoc
+int __irq_desc_send_ipi(struct irq_desc *desc, const struct ipi_mask *dest)
+{
+ struct irq_data *data = irq_desc_get_irq_data(desc);
+ struct irq_chip *chip
On 10/13/2015 02:53 PM, Thomas Gleixner wrote:
On Tue, 13 Oct 2015, Qais Yousef wrote:
This series is based on Linus tree. I couldn't compile test it
because MIPS compilation was broken due to other reasons. I expect
some brokeness because of the introduction of struct irq_common_data
whi
On 10/13/2015 02:48 PM, Thomas Gleixner wrote:
On Tue, 13 Oct 2015, Qais Yousef wrote:
+#ifdef CONFIG_GENERIC_IRQ_IPI
+void generic_smp_send_ipi_single(int cpu, unsigned int action)
Please use a mips name space. This suggests that it s completely
generic, which is not true
On 10/13/2015 02:49 PM, Thomas Gleixner wrote:
On Tue, 13 Oct 2015, Qais Yousef wrote:
Only the SMP variants that use GIC were converted as it's the only irqchip that
will have the support for generic IPI for now which will be introduced in
the following patches.
You break bisectab
Hi,
This is an attempt to revive a discussion on the right list this time
with all the correct people hopefully on CC.
While trying to upstream a driver, Thomas and Marc Zyngier pointed out
the need for a generic IPI support in the kernel to allow driver to
reserve and send ones. Hopefully m
On 10/14/2015 03:50 PM, Davidlohr Bueso wrote:
On Tue, 13 Oct 2015, Qais Yousef wrote:
It has a similar role to affinity mask, but tracks the IPI affinity
instead.
Signed-off-by: Qais Yousef
---
include/linux/irq.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/irq.h b
On 10/14/2015 04:04 PM, Davidlohr Bueso wrote:
On Tue, 13 Oct 2015, Qais Yousef wrote:
Qais Yousef (14):
irq: add new IRQ_DOMAIN_FLAGS_IPI
irq: add GENERIC_IRQ_IPI Kconfig symbol
irq: add new struct ipi_mask
irq: add a new irq_send_ipi() to irq_chip
irq: add struct ipi_mask to irq_data
On 10/12/2015 11:16 AM, Thomas Gleixner wrote:
On Mon, 12 Oct 2015, Marc Zyngier wrote:
On 12/10/15 10:40, Markos Chandras wrote:
From: Alex Smith
The GIC provides a "user-mode visible" section containing a mirror of
the counter registers which can be mapped into user memory. This will
be use
Is there anything more I can do to get more attention about this? I
think Marc's suggestion is more generic and future proof, if I send RFC
patches for that would this be better?
Thanks,
Qais
On 10/14/2015 11:18 AM, Qais Yousef wrote:
Hi,
This is an attempt to revive a discussion o
On 08/28/2015 03:22 PM, Thomas Gleixner wrote:
On Fri, 28 Aug 2015, Qais Yousef wrote:
Thanks a lot for the detailed explanation. I wasn't looking for a quick and
dirty solution but my view of the problem is much simpler than yours so my
idea of a solution would look quick and dirty. I h
On 09/02/2015 10:55 AM, Marc Zyngier wrote:
On 02/09/15 10:33, Qais Yousef wrote:
On 08/28/2015 03:22 PM, Thomas Gleixner wrote:
On Fri, 28 Aug 2015, Qais Yousef wrote:
Thanks a lot for the detailed explanation. I wasn't looking for a quick and
dirty solution but my view of the probl
On 09/02/2015 12:53 PM, Marc Zyngier wrote:
On 02/09/15 11:48, Qais Yousef wrote:
It's worth noting in the light of this that INT_SPEC should be optional
since for hardware similar to mine there's not much to tell the
controller if it's all dynamic except where we want the IPI
On 10/22/2015 02:43 PM, Rob Herring wrote:
On Wed, Oct 14, 2015 at 5:18 AM, Qais Yousef wrote:
Hi,
This is an attempt to revive a discussion on the right list this time with
all the correct people hopefully on CC.
devicetree-spec would be more appropriate list for something like this
|= SD_PREFER_SIBLING;
sd->imbalance_pct = 110;
- sd->smt_gain = 1178; /* ~15% */
} else if (sd->flags & SD_SHARE_PKG_RESOURCES) {
sd->flags |= SD_PREFER_SIBLING;
--
Qais Yousef
if (tl == tl_asym)
+ dflags |= SD_ASYM_CPUCAPACITY;
+
+ sd = build_sched_domain(tl, cpu_map, attr, sd, dflags,
i);
+
if (tl == sched_domain_topology)
*per_cpu_ptr(d.sd, i) = sd;
if (tl->flags & SDTL_OVERLAP)
--
Qais Yousef
d_domain hierarchy shouldn't be a
normal and common thing to do. If checking for the flag is not
acceptable on SMP-only architectures, I can move it under arch/arm[,64]
although it is not as clean.
I like the approach and I think it's nice and clean. If it actually
appears in some profiles I think we have room to optimize it.
--
Qais Yousef
On 24/07/18 09:37, Morten Rasmussen wrote:
On Mon, Jul 23, 2018 at 05:07:50PM +0100, Qais Yousef wrote:
On 23/07/18 16:27, Morten Rasmussen wrote:
It does increase the cost of things like hotplug slightly and
repartitioning of root_domains a slightly but I don't see how we can
avoid it
ltime() to task_has_realtime_policy() as the old name
is confusing against the new realtime_task().
No functional changes were intended.
[1]
https://lore.kernel.org/lkml/20240506100509.gl40...@noisy.programming.kicks-ass.net/
Signed-off-by: Qais Yousef
---
fs/select.c
On 05/15/24 10:32, Peter Zijlstra wrote:
> On Tue, May 14, 2024 at 07:58:51PM -0400, Phil Auld wrote:
> >
> > Hi Qais,
> >
> > On Wed, May 15, 2024 at 12:41:12AM +0100 Qais Yousef wrote:
> > > rt_task() checks if a task has RT priority. But depends on your
On 05/15/24 07:20, Phil Auld wrote:
> On Wed, May 15, 2024 at 10:32:38AM +0200 Peter Zijlstra wrote:
> > On Tue, May 14, 2024 at 07:58:51PM -0400, Phil Auld wrote:
> > >
> > > Hi Qais,
> > >
> > > On Wed, May 15, 2024 at 12:41:12AM +0100 Qais Yousef
audit the users and
replace the ones required the old behavior with the new realtime_task()
which returns true for RT and DL classes. Introduce similar
realtime_prio() to create similar distinction to rt_prio() and update
the users that required the old behavior to use the new function.
"""
> Reviewed-by: Phil Auld
Thanks for having a look!
Cheers
--
Qais Yousef
d-by: Phil Auld
Signed-off-by: Qais Yousef
---
Changes since v1:
* Use realtime_task_policy() instead task_has_realtime_policy() (Peter)
* Improve commit message readability about replace some rt_task()
users.
v1 discussion:
https://lore.kernel.org/lkml/2024051423411
On 05/21/24 13:00, Sebastian Andrzej Siewior wrote:
> On 2024-05-15 23:05:36 [+0100], Qais Yousef wrote:
> > rt_task() checks if a task has RT priority. But depends on your
> > dictionary, this could mean it belongs to RT class, or is a 'realtime'
> > task, w
On 05/23/24 11:45, Steven Rostedt wrote:
> On Wed, 15 May 2024 23:05:36 +0100
> Qais Yousef wrote:
> > diff --git a/include/linux/sched/deadline.h b/include/linux/sched/deadline.h
> > index df3aca89d4f5..5cb88b748ad6 100644
> > --- a/include/linux/sched/deadline.h
>
some rt_task()
users.
v1 discussion:
https://lore.kernel.org/lkml/20240514234112.792989-1-qyou...@layalina.io/
v2 discussion:
https://lore.kernel.org/lkml/20240515220536.823145-1-qyou...@layalina.io/
Qais Yousef (3):
sched/rt: Clean up usage of rt_task()
hrtimer: Convert
d-by: Phil Auld
Reviewed-by: Steven Rostedt (Google)
Signed-off-by: Qais Yousef
---
fs/bcachefs/six.c | 2 +-
fs/select.c | 2 +-
include/linux/ioprio.h| 2 +-
include/linux/sched/deadline.h| 6 --
include/linux/sched/prio.h| 1
As Sebastian explained in [1], We need only look at the policy to decide
if we need to remove the slack because PI-boosted tasks should not
sleep.
[1] https://lore.kernel.org/lkml/20240521110035.kriwl...@linutronix.de/
Suggested-by: Sebastian Andrzej Siewior
Signed-off-by: Qais Yousef
{rt, realtime, dl}_{task, prio}() functions return value is actually
a bool. Convert their return type to reflect that.
Suggested-by: Steven Rostedt (Google)
Signed-off-by: Qais Yousef
---
include/linux/sched/deadline.h | 4 ++--
include/linux/sched/rt.h | 8
2 files changed, 6
On 05/29/24 09:34, Sebastian Andrzej Siewior wrote:
> On 2024-05-28 00:45:08 [+0100], Qais Yousef wrote:
> > diff --git a/include/linux/sched/deadline.h b/include/linux/sched/deadline.h
> > index 5cb88b748ad6..87d2370dd3db 100644
> > --- a/include/linux/sched/deadline.h
&g
On 05/29/24 10:29, Sebastian Andrzej Siewior wrote:
> On 2024-05-27 18:26:50 [+0100], Qais Yousef wrote:
> > > In order to be PI-boosted you need to acquire a lock and the only lock
> > > you can sleep while acquired without generating a warning is a mutex_t
> > > (o
On 05/29/24 12:55, Sebastian Andrzej Siewior wrote:
> On 2024-05-29 11:34:09 [+0100], Qais Yousef wrote:
> > > behaviour. But then it is insistent which matters only in the RT case.
> > > Puh. Any sched folks regarding policy?
> >
> > I am not sure I understood yo
989-1-qyou...@layalina.io/
v2 discussion:
https://lore.kernel.org/lkml/20240515220536.823145-1-qyou...@layalina.io/
v3 discussion:
https://lore.kernel.org/lkml/20240527234508.1062360-1-qyou...@layalina.io/
Qais Yousef (2):
sched/rt: Clean up usage of rt_task()
sched/rt, dl: Convert functions
d-by: Phil Auld
Reviewed-by: Steven Rostedt (Google)
Signed-off-by: Qais Yousef
---
fs/bcachefs/six.c | 2 +-
fs/select.c | 2 +-
include/linux/ioprio.h| 2 +-
include/linux/sched/deadline.h| 6 --
include/linux/sched/prio.h| 1
{rt, realtime, dl}_{task, prio}() functions return value is actually
a bool. Convert their return type to reflect that.
Suggested-by: Steven Rostedt (Google)
Signed-off-by: Qais Yousef
---
include/linux/sched/deadline.h | 8
include/linux/sched/rt.h | 16
2
On 05/31/24 08:30, Sebastian Andrzej Siewior wrote:
> On 2024-05-30 12:10:44 [+0100], Qais Yousef wrote:
> > > This is not consistent because IMHO the clock setup & slack should be
> > > handled equally. So I am asking the sched folks for a policy and I am
> > &g
On 06/03/24 08:33, Metin Kaya wrote:
> On 01/06/2024 10:33 pm, Qais Yousef wrote:
> > {rt, realtime, dl}_{task, prio}() functions return value is actually
> > a bool. Convert their return type to reflect that.
> >
> > Suggested-by: Steven Rostedt (Google)
>
l.org/lkml/20240527234508.1062360-1-qyou...@layalina.io/
v4 discussion:
https://lore.kernel.org/lkml/20240601213309.1262206-1-qyou...@layalina.io/
Qais Yousef (2):
sched/rt: Clean up usage of rt_task()
sched/rt, dl: Convert functions to return bool
fs/bcachefs/six.c | 2 +-
f
d-by: Phil Auld
Reviewed-by: Steven Rostedt (Google)
Signed-off-by: Qais Yousef
---
fs/bcachefs/six.c | 2 +-
fs/select.c | 2 +-
include/linux/ioprio.h| 2 +-
include/linux/sched/deadline.h| 6 --
include/linux/sched/prio.h| 1
{rt, realtime, dl}_{task, prio}() functions return value is actually
a bool. Convert their return type to reflect that.
Suggested-by: Steven Rostedt (Google)
Signed-off-by: Qais Yousef
---
include/linux/sched/deadline.h | 8 +++-
include/linux/sched/rt.h | 16 ++--
2
On 06/05/24 11:32, Sebastian Andrzej Siewior wrote:
> On 2024-06-04 17:57:46 [+0200], Daniel Bristot de Oliveira wrote:
> > On 6/4/24 16:42, Qais Yousef wrote:
> > > - (wakeup_rt && !dl_task(p) && !rt_task(p)) ||
> > > + (wakeup_rt &
d-by: Phil Auld
Reviewed-by: Steven Rostedt (Google)
Reviewed-by: Sebastian Andrzej Siewior
Signed-off-by: Qais Yousef
---
fs/bcachefs/six.c | 2 +-
fs/select.c | 2 +-
include/linux/ioprio.h| 2 +-
include/linux/sched/deadline.h| 6 -
0527234508.1062360-1-qyou...@layalina.io/
v4 discussion:
https://lore.kernel.org/lkml/20240601213309.1262206-1-qyou...@layalina.io/
v5 discussion:
https://lore.kernel.org/lkml/20240604144228.1356121-1-qyou...@layalina.io/
Qais Yousef (3):
sched/rt: Clean up usage of rt_task()
sched/rt, dl: Convert functio
{rt, realtime, dl}_{task, prio}() functions' return value is actually
a bool. Convert their return type to reflect that.
Suggested-by: Steven Rostedt (Google)
Reviewed-by: Sebastian Andrzej Siewior
Reviewed-by: Steven Rostedt (Google)
Reviewed-by: Metin Kaya
Signed-off-by: Qais Y
Some find the name realtime overloaded. Use rt_or_dl() as an
alternative, hopefully better, name.
Suggested-by: Daniel Bristot de Oliveira
Signed-off-by: Qais Yousef
---
fs/bcachefs/six.c | 2 +-
fs/select.c | 2 +-
include/linux/ioprio.h| 2
On 06/05/24 16:07, Daniel Bristot de Oliveira wrote:
> On 6/5/24 15:24, Qais Yousef wrote:
> >>> But rt is a shortened version of realtime, and so it is making *it less*
> >>> clear that we also have DL here.
> >> Can SCHED_DL be considered a real-time sch
On 06/10/24 20:20, Qais Yousef wrote:
> Make rt_task() return true only for RT class and add new realtime_task() to
> return true for RT and DL classes to avoid some confusion the old API can
> cause.
I am not aware of any pending review comments for this series. Is it ready to
be
eadable, which is explained in
> -admin-guide/bug-hunting.rst.
> +Note, if you can't get this to work, simply skip this step and mention the
> +reason for it in the report. If you're lucky, it might not be needed. And if
> it
> +is, someone might help you to get things going. Also be aware this is just
> one
> +of several ways to decode kernel stack traces. Sometimes different steps will
> +be required to retrieve the relevant details. Don't worry about that, if
> that's
> +needed in your case, developers will tell you what to do.
Ah you already clarify nicely here this is a good-to-have rather than
a must-have as I was trying to elude to above :-)
This looks good to me in general. With the above minor nits fixed, feel free to
add my
Reviewed-by: Qais Yousef
Thanks!
--
Qais Yousef
>
>
> Special care for regressions
> --
> 2.29.2
>
Hi Thorsten
On 02/15/21 06:55, Thorsten Leemhuis wrote:
> Hi! Many thx for looking into this, much appreciated!
>
> Am 14.02.21 um 17:00 schrieb Qais Yousef:
> > On 02/10/21 06:48, Thorsten Leemhuis wrote:
> >
> >> - * If the failure includes a stack dum
hotplug() after onlining the
> cpu in cpu_device_up() and in cpuhp_smt_enable().
>
> Co-analyzed-by: Joshua Baker
> Signed-off-by: Alexey Klimov
> ---
This looks good to me.
Reviewed-by: Qais Yousef
Thanks
--
Qais Yousef
On 12/29/2014 04:13 PM, Mark Brown wrote:
On Tue, Dec 23, 2014 at 09:09:27AM +, Qais Yousef wrote:
In soc_new_compress() when rtd->dai_link->daynmic is set, we create the pcm
substreams with this call:
ret = snd_pcm_new_internal(rtd->card->snd_card, n
By all means I don't really understand the whole issues surrounding this
but this approach looks better to me as well. It seems more generic and
future proof and at least I can understand the patch series.
But did I say I don't understand all of this? Would be nice to hear from
more people :)
be_pcm->streams[SNDRV_PCM_STREAM_CAPTURE].substream
being NULL, hence when trying to set rtd a few lines below we get an oops.
Fix by removing this line of code since CAPTURE substream will always be NULL.
Signed-off-by: Qais Yousef
Cc: Vinod Koul
Cc: Liam Girdwood
Cc: Mark Brown
Cc: Jaroslav Kysela
C
On 01/13/2015 02:59 PM, Vinod Koul wrote:
On Tue, Jan 13, 2015 at 11:18:53AM +, Qais Yousef wrote:
In soc_new_compress() when rtd->dai_link->daynmic is set, we create the pcm
typo
substreams with this call:
On 01/13/2015 04:20 PM, Mark Brown wrote:
On Tue, Jan 13, 2015 at 03:16:10PM +, Qais Yousef wrote:
On 01/13/2015 02:59 PM, Vinod Koul wrote:
being NULL, hence when trying to set rtd a few lines below we get an oops.
It is a good practice to add the oops here
Will this really be helpful
On 01/13/2015 05:21 PM, James Hogan wrote:
On 13 January 2015 15:16:10 GMT+00:00, Qais Yousef
wrote:
Will this really be helpful? I think it'll be more clutter (the
backtrace on metag arch is not great):
I suspect you don't have frame pointers enabled in your kernel config. Th
be_pcm->streams[SNDRV_PCM_STREAM_CAPTURE].substream
being NULL, hence when trying to set rtd a few lines below we get an oops.
Fix by using rtd->dai_link->dpcm_playback and rtd->dai_link->dpcm_capture as
playback_count and capture_count to snd_pcm_new_internal().
Signed-off-by: Qais Yousef
Cc
be_pcm->streams[SNDRV_PCM_STREAM_CAPTURE].substream
being NULL, hence when trying to set rtd a few lines below we get an oops.
Fix by using rtd->dai_link->dpcm_playback and rtd->dai_link->dpcm_capture as
playback_count and capture_count to snd_pcm_new_internal().
Signed-off-by: Qais Yousef
Cc
gic_init.
Instead, they will pass the CPU interrupt vector (2 - 7) that they
expect the GIC to route interrupts to. Note that in EIC mode this
value is ignored and all GIC interrupts are routed to EIC vector 1.
Signed-off-by: Andrew Bresticker
Acked-by: Jason Cooper
Reviewed-by: Qais Yousef
Tested-by
be_pcm->streams[SNDRV_PCM_STREAM_CAPTURE].substream
being NULL, hence when trying to set rtd a few lines below we get an oops.
Fix by using rtd->dai_link->dpcm_playback and rtd->dai_link->dpcm_capture as
playback_count and capture_count to snd_pcm_new_internal().
Signed-off-by: Qais Yousef
Cc
Ping
On 12/19/2014 11:38 AM, Qais Yousef wrote:
Fixes the following compilation error:
include/sound/compress_driver.h: In function ‘snd_compr_drain_notify’:
include/sound/compress_driver.h:177:2: error: implicit declaration of
function ‘snd_BUG_ON’ [-Werror=implicit-function
ensure fairness and priority doesn't get skewed a lot, read local and shared
pending registers once
to service each pending IRQ once.
If another interupt triggers while servicing the current ones, then we shall
re-enter the handler after
we return.
Signed-off-by: Qais Yousef
Cc: Thomas Gleixne
gt; +cpio_dir=$outdir/$tarfile.tmp
> +
> +src_file_list=""
> +for f in $file_list; do
$file_list is not assigned here.
I applied the patches and I got an empty tar generated. Setting `file_list=$*`
fixed it for me - though not sure if this is the right fix to use. Last minute
change/cl
On 02/28/19 17:04, Dietmar Eggemann wrote:
> Hi Joel,
>
> On 2/28/19 3:47 PM, Joel Fernandes wrote:
> > On Thu, Feb 28, 2019 at 01:53:43PM +0000, Qais Yousef wrote:
> > > Hi Joel
> > >
> > > On 02/27/19 14:37, Joel Fernandes (Google) wrote:
>
> [.
On 02/28/19 17:04, Dietmar Eggemann wrote:
> Hi Joel,
>
> On 2/28/19 3:47 PM, Joel Fernandes wrote:
> > On Thu, Feb 28, 2019 at 01:53:43PM +0000, Qais Yousef wrote:
> > > Hi Joel
> > >
> > > On 02/27/19 14:37, Joel Fernandes (Google) wrote:
>
> [.
ling a new
syscall e.g: bpf) it's very easy to forget that the headers has changed as well
and you need to push an updated copy.
FWIW most of the time I run on non-android systems for development/debugging
purposes. I use the built-in version although I can see a module version
helpful
On 03/12/19 11:07, Qais Yousef wrote:
> eBPF tools like bcc-tools have hard time figuring out when features like
> raw_tracepoint are supported in the kernel on which we are running. At
> the moment a fragile mechanism of matching bpf_find_raw_tracepoint()
> function in /proc/kallsym
ich are a bandaid of sorts and it would be good to get rid of them.
> They are mostly used for thermal management and I guess that devfreq
> users also may want to reduce frequency for thermal reasons and I'd
> rather not add notifiers to that framework for this purpose.
>
>
(+ LKML)
Apologies forgot to CC the list.
On 04/07/19 18:52, Qais Yousef wrote:
> Hi Steve, Peter
>
> I know the topic has sprung up in the past but I couldn't find anything that
> points into any conclusion.
>
> As far as I understand new TRACE_EVENTS() in the schedu
/* Increase refcounts for claim_allocations: */
> + already_visited = atomic_inc_return(&sg->ref) > 1;
> + /* sgc visits should follow a similar trend as sg */
> + WARN_ON(already_visited != (atomic_inc_return(&sg->sgc->ref) > 1));
NIT: I think it would be better to not
On 04/10/19 11:17, Valentin Schneider wrote:
> On 10/04/2019 10:27, Qais Yousef wrote:
> [...]
> >> @@ -1066,9 +1067,14 @@ static struct sched_group *get_group(int cpu,
> >> struct sd_data *sdd)
> >>sg = *per_cpu_ptr(sdd->sg, cpu);
> >
On 02/26/19 08:00, Viresh Kumar wrote:
> On 25-02-19, 12:14, Qais Yousef wrote:
> > On 02/25/19 14:39, Viresh Kumar wrote:
> > > On 25-02-19, 08:58, Qais Yousef wrote:
> > > > On 02/25/19 10:01, Viresh Kumar wrote:
> > > > > > > + min = dev_
quot;)
> Reported-by: Randy Dunlap
> Signed-off-by: Shuo Liu
> Acked-by: Randy Dunlap # build-tested
> Cc: Stephen Rothwell
> Cc: Thomas Gleixner
> Cc: Greg Kroah-Hartman
> Cc: Qais Yousef
> ---
Reviewed-by: Qais Yousef
Thanks!
--
Qais Yousef
> include/linux/c
build-tested
> Cc: Stephen Rothwell
> Cc: Thomas Gleixner
> Cc: Greg Kroah-Hartman
> Cc: Qais Yousef
> ---
> drivers/virt/acrn/hsm.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/virt/acrn/hsm.c b/drivers/virt/acrn/hsm.c
> index 1f6b7c54a
capacities less
> than
> 5% apart.
One more margin is a cause of apprehension to me. But in this case I think it
is the appropriate thing to do now. I can't think of a scenario where this
could hurt.
Thanks
--
Qais Yousef
p's
> capacity extrema.
>
> Replace group_smaller_{min, max}_cpu_capacity() with comparisons of the
> source group's min/max capacity and the destination CPU's capacity.
>
> Signed-off-by: Valentin Schneider
> ---
Reviewed-by: Qais Yo
ly few lines below we have
return capacity_greater(ref->sgc->max_capacity, sg->sgc->max_capacity);
which pass 'ref->...' as cap which can be confusing when looking at the
function signature @ref.
Either way, this LGTM
Reviewed-by: Qais Yousef
Thanks
--
Qais
gt; single check:
>
> capacity_greater(, );
>
> This has the added benefit of returning false if the misfit task CPU's is
> heavily pressured, but there are no better candidates for migration.
>
> Signed-off-by: Valentin Schneider
> ---
check_cpu_capacity() call looks redundant
1 - 100 of 683 matches
Mail list logo
