(rproc->dev.parent);
> ret = mutex_lock_interruptible(&rproc->lock);
> if (ret) {
> dev_err(dev, "can't lock rproc %s: %d\n", rproc->name, ret);
> @@ -2027,6 +2030,7 @@ int rproc_shutdown(struct rproc *rproc)
> rproc-&g
On Mon, Dec 23, 2024 at 11:27 PM Mukesh Ojha
wrote:
>
> Hi All,
>
> Wanted to check if we have encountered remoteproc use case where a device
> with dma is assigned to a remoteproc with its own streamid and iommu
> translation context. This DMA device can have a selective DMA
Hi All,
Wanted to check if we have encountered remoteproc use case where a device
with dma is assigned to a remoteproc with its own streamid and iommu
translation context. This DMA device can have a selective DMA range
within the remoteproc carveout memory that needs to be iommu mapped
before the
On Fri, Oct 25, 2024 at 09:08:03AM -0600, Mathieu Poirier wrote:
> On Fri, Oct 25, 2024 at 01:40:45PM +0530, Mukesh Ojha wrote:
> > On Mon, Oct 21, 2024 at 09:12:47AM -0600, Mathieu Poirier wrote:
> > > Hi Mukesh,
> > >
> > > On Wed, Oct 16, 2024 at
On Mon, Oct 21, 2024 at 09:12:47AM -0600, Mathieu Poirier wrote:
> Hi Mukesh,
>
> On Wed, Oct 16, 2024 at 10:25:46AM +0530, Mukesh Ojha wrote:
> > Multiple call to glink_subdev_stop() for the same remoteproc can happen
> > if rproc_stop() fails from Process-A that leav
V
Unable to handle kernel
NULL pointer dereference
at virtual
address 0358
Signed-off-by: Mukesh Ojha
---
Changes in v3:
- Fix kernel test report
On Tue, Oct 15, 2024 at 02:01:18AM +0530, Mukesh Ojha wrote:
> Multiple call to glink_subdev_stop() for the same remoteproc can happen
> if rproc_stop() fails from Process-A that leaves the rproc state to
> RPROC_CRASHED state later a call to recovery_store from user space in
> Proces
V
Unable to handle kernel
NULL pointer dereference
at virtual
address 0358
Signed-off-by: Mukesh Ojha
---
Changes in v2:
- Removed NULL pointer
On Fri, Oct 11, 2024 at 09:23:05AM +0300, Dmitry Baryshkov wrote:
> On Fri, Oct 11, 2024 at 10:35:18AM GMT, Shiraz Hashim wrote:
> > On Thu, Oct 10, 2024 at 08:57:56AM +0200, neil.armstr...@linaro.org wrote:
> > > On 08/10/2024 08:21, Mukesh Ojha wrote:
> > > > On M
On Mon, Oct 07, 2024 at 08:22:39PM +0530, Mukesh Ojha wrote:
> On Mon, Oct 07, 2024 at 10:05:08AM +0200, neil.armstr...@linaro.org wrote:
> > On 04/10/2024 23:23, Mukesh Ojha wrote:
> > > For Qualcomm SoCs runnning with Qualcomm EL2 hypervisor(QHEE), IOMMU
> > > transl
On Tue, Oct 01, 2024 at 02:15:52PM -0700, Bjorn Andersson wrote:
> On Tue, Oct 01, 2024 at 12:06:17PM +0530, Mukesh Ojha wrote:
> > On Fri, Sep 27, 2024 at 02:59:09PM -0700, Bjorn Andersson wrote:
> > > On Sat, Sep 28, 2024 at 01:07:43AM +0530, Mukesh Ojha wrote:
> > > &
On Sun, Oct 06, 2024 at 10:34:19PM +0300, Dmitry Baryshkov wrote:
> On Sat, Oct 05, 2024 at 02:53:53AM GMT, Mukesh Ojha wrote:
> > Qualcomm is looking to enable remote processors on the SA8775p SoC
> > running KVM Linux host and is currently trying to figure out an
> > upstrea
On Sun, Oct 06, 2024 at 10:38:01PM +0300, Dmitry Baryshkov wrote:
> On Sat, Oct 05, 2024 at 02:53:54AM GMT, Mukesh Ojha wrote:
> > From: Shiraz Hashim
> >
> > Qualcomm’s PAS implementation for remote processors only supports a
> > single stage of IOMMU translation and
On Mon, Oct 07, 2024 at 10:05:08AM +0200, neil.armstr...@linaro.org wrote:
> On 04/10/2024 23:23, Mukesh Ojha wrote:
> > For Qualcomm SoCs runnning with Qualcomm EL2 hypervisor(QHEE), IOMMU
> > translation for remote processors is managed by QHEE and if the same SoC
> > run
On Mon, Oct 07, 2024 at 10:08:16AM +0200, neil.armstr...@linaro.org wrote:
> On 04/10/2024 23:23, Mukesh Ojha wrote:
> > From: Shiraz Hashim
> >
> > Qualcomm SoCs runnning with Qualcomm EL2 hypervisor(QHEE), IOMMU
> > translation set up for remote processors is managed
Subject got wrapped and later part got ignored,
Quoting it again here for reference.
"Peripheral Image Loader support for Qualcomm SoCs on KVM host system"
-Mukesh
tear down and apart from this, SHM bridge also need
to set up to enable memory protection on both remoteproc meta data
memory as well as for the carveout region.
Enable the support required to run Qualcomm remoteprocs on non-QHEE
hypervisors.
Signed-off-by: Mukesh Ojha
---
drivers/remoteproc
. Make
qcom_tzmem_init_area() and qcom_tzmem_cleanup_area() exported symbol so
that it could be used to create SHM bridge for remoteproc region.
Signed-off-by: Mukesh Ojha
---
drivers/firmware/qcom/qcom_scm.c | 29 +++-
drivers/firmware/qcom/qcom_tzmem.c | 14
qcom,devmem information.
Signed-off-by: Shiraz Hashim
Co-developed-by: Mukesh Ojha
Signed-off-by: Mukesh Ojha
---
drivers/remoteproc/qcom_q6v5_pas.c | 55 ++
1 file changed, 55 insertions(+)
diff --git a/drivers/remoteproc/qcom_q6v5_pas.c
b/drivers/remoteproc
: Mukesh Ojha
Signed-off-by: Mukesh Ojha
---
drivers/remoteproc/qcom_common.c | 96
drivers/remoteproc/qcom_common.h | 35
2 files changed, 131 insertions(+)
diff --git a/drivers/remoteproc/qcom_common.c b/drivers/remoteproc/qcom_common.c
index
le in
qcom_q6v5_adsp.c. So, in motivation to reuse code, introduce common
exported functions like qcom_map_unmap_carveout() such that it can be
used by both qcom_q6v5_adsp and qcom_q6v5_pas.
Signed-off-by: Komal Bajaj
Co-Developed-by: Mukesh Ojha
Signed-off-by: Mukesh Ojha
---
drivers/remot
either QHEE or a KVM hypervisor
(CPUs booted in EL2).
The qcom,devmem property provides IOMMU devmem translation information
intended for non-QHEE based systems.
Signed-off-by: Shiraz Hashim
Co-Developed-by: Mukesh Ojha
Signed-off-by: Mukesh Ojha
---
.../bindings/remoteproc/qcom,pas
the iommus
properties and mapping/unmapping carveout and device memory based on
it.
Komal Bajaj (1):
remoteproc: qcom: Add iommu map_unmap helper function
Mukesh Ojha (2):
remoteproc: qcom: Add support of SHM bridge to enable memory
protection
remoteproc: qcom: Enable map/unmap and
On Fri, Sep 27, 2024 at 02:59:09PM -0700, Bjorn Andersson wrote:
> On Sat, Sep 28, 2024 at 01:07:43AM +0530, Mukesh Ojha wrote:
> > On Wed, Sep 25, 2024 at 08:41:55PM -0700, Bjorn Andersson wrote:
> > > On Wed, Sep 25, 2024 at 04:03:51PM +0530, Mukesh Ojha wrote:
> &
On Wed, Sep 25, 2024 at 08:41:55PM -0700, Bjorn Andersson wrote:
> On Wed, Sep 25, 2024 at 04:03:51PM +0530, Mukesh Ojha wrote:
> > Multiple call to glink_subdev_stop() for the same remoteproc can happen
> > if rproc_stop() fails from Process-A that leaves the rproc state to
&g
ble to handle kernel
NULL pointer dereference
at virtual
address 0358
Signed-off-by: Mukesh Ojha
---
- We can do this NULL check in qcom_glink_smem_unregister() as it is
exported function however, there is only one user of this. So, doing
it with c
eptdev'
drivers/rpmsg/rpmsg_char.c:75: warning: Function parameter or struct member
'remote_flow_updated' not described in 'rpmsg_eptdev'
Fixes: 5550201c0fe2 ("rpmsg: char: Add RPMSG GET/SET FLOWCONTROL IOCTL support")
Signed-off-by: Arnaud Pouliquen
Reviewed-by: Mukesh Ojha
-Mukesh
ize - len);
Although, it does not make any difference apart from a write of len
bytes, still a good improvement to do ..
Acked-by: Mukesh Ojha
-Mukesh
handler(scp->share_buf, len, ipi_desc[id].priv);
scp_ipi_unlock(scp, id);
On 4/30/2024 7:08 PM, Bjorn Andersson wrote:
On Tue, Mar 26, 2024 at 07:43:12PM +0530, Mukesh Ojha wrote:
Add qcom_rproc_minidump module in a preparation to remove
minidump specific code from driver/remoteproc/qcom_common.c
and provide needed exported API, this as well helps to
abstract
. Guards the qcom_minidump() with CONFIG_QCOM_RPROC_MINIDUMP.
3. Selects this QCOM_RPROC_MINIDUMP config when QCOM_RPROC_COMMON
enabled.
4. Added new header qcom_minidump.h .
Signed-off-by: Mukesh Ojha
---
Changes in v10:
- Converted all 3 changes sent in v9 to a single to properly
reflect
Gentle ping..
-Mukesh
On 3/26/2024 7:43 PM, Mukesh Ojha wrote:
Add qcom_rproc_minidump module in a preparation to remove
minidump specific code from driver/remoteproc/qcom_common.c
and provide needed exported API, this as well helps to
abstract minidump specific data layout from qualcomm&#
As minidump specific data structure and functions move under
config QCOM_RPROC_MINIDUMP, so remove minidump specific data
from driver/remoteproc/qcom_common.c .
Signed-off-by: Mukesh Ojha
---
Changes in v9:
- Change in patch order.
- rebased it.
v8: https://lore.kernel.org/lkml
s use qcom_rproc_minidump() and
we will be removing qcom_minidump() and minidump related stuff
from driver/remoteproc/qcom_common.c .
Signed-off-by: Mukesh Ojha
---
Changes in v9:
- Change in patch order from its last version.
- Rebased it.
v8: https://lore.kernel.org/lkml/20240131105734.13090-1-qu
idump() functionality from
driver/remoteproc/qcom_common.c into a separate file under
qcom_rproc_minidump().
Signed-off-by: Mukesh Ojha
---
Changes in v9:
- Added source file driver/remoteproc/qcom_common.c copyright
to qcom_rproc_minidump.c
- Dissociated it from minidump series as this can go separ
On 1/23/2024 2:21 PM, Neil Armstrong wrote:
The qlink_logging memory region is also used by the modem firmware,
add it to the reserved memories and add it to the MPSS memory regions.
Signed-off-by: Neil Armstrong
LGTM,
Reviewed-by: Mukesh Ojha
-Mukesh
---
arch/arm64/boot/dts/qcom
= &sm8550_cdsp_resource},
{ .compatible = "qcom,sm8550-mpss-pas", .data = &sm8550_mpss_resource},
+ { .compatible = "qcom,sm8650-adsp-pas", .data = &sm8550_adsp_resource},
Same as sm8550;
+ { .compatible = "qcom,sm8650-cdsp-pas", .data = &sm8650_cdsp_resource},
+ { .compatible = "qcom,sm8650-mpss-pas", .data = &sm8650_mpss_resource},
LGTM,
Acked-by: Mukesh Ojha
-Mukesh
{ },
};
MODULE_DEVICE_TABLE(of, adsp_of_match);
On 12/18/2023 11:40 AM, Vignesh Viswanathan wrote:
q6v5 fatal and watchdog IRQ handlers always retrieves the crash reason
information from SMEM global partition (QCOM_SMEM_HOST_ANY).
For some targets like IPQ9574 and IPQ5332, crash reason information is
present in target specific partition du
ms[offset],
+ &perm, 1);
+ if (ret < 0)
+ dev_err(adsp->dev, "unassign memory failed\n");
In case you are going to send another version,
you can print offset similar to the assign call failure.,
Othe
On 11/2/2023 3:56 PM, neil.armstr...@linaro.org wrote:
On 01/11/2023 15:42, Mukesh Ojha wrote:
On 10/31/2023 10:36 PM, Neil Armstrong wrote:
Hi,
On 30/10/2023 14:10, Mukesh Ojha wrote:
On 10/30/2023 3:33 PM, Neil Armstrong wrote:
The current memory region assign only supports a
On 11/2/2023 1:30 AM, Steven Rostedt wrote:
On Mon, 30 Oct 2023 21:57:13 +0530
Mukesh Ojha wrote:
On 10/30/2023 9:45 PM, Steven Rostedt wrote:
From: "Steven Rostedt (Google)"
The eventfs_remove_rec() had some missing parameters in the kerneldoc
comment above it. Also, re
On 10/31/2023 10:36 PM, Neil Armstrong wrote:
Hi,
On 30/10/2023 14:10, Mukesh Ojha wrote:
On 10/30/2023 3:33 PM, Neil Armstrong wrote:
The current memory region assign only supports a single
memory region.
But new platforms introduces more regions to make the
memory requirements more
const char *name, const char *loc, ...)
Fixes: 2a588dd1d5d6 ("tracing: Add kprobe event command generation functions")
Suggested-by: Mukesh Ojha
Signed-off-by: Yujie Liu
Thanks.
Reviewed-by: Mukesh Ojha
-Mukesh
---
kernel/trace/trace_kprobe.c | 2 +-
1 file changed, 1 insertion(+),
On 10/30/2023 8:33 PM, Doug Anderson wrote:
Hi,
On Mon, Oct 30, 2023 at 7:43 AM Luca Weiss wrote:
On Mon Oct 30, 2023 at 3:11 PM CET, Doug Anderson wrote:
Hi,
On Mon, Oct 30, 2023 at 2:12 AM Luca Weiss wrote:
On Mon Oct 30, 2023 at 10:04 AM CET, Mukesh Ojha wrote:
On 10/27/2023 7
eventfs: Remove eventfs_file and just use
eventfs_inode");
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202310052216.4sgqaswo-...@intel.com/
Signed-off-by: Steven Rostedt (Google)
Reviewed-by: Mukesh Ojha
-Mukesh
---
fs/tracefs/event_inode.c | 6 --
On 10/30/2023 3:33 PM, Neil Armstrong wrote:
The current memory region assign only supports a single
memory region.
But new platforms introduces more regions to make the
memory requirements more flexible for various use cases.
Those new platforms also shares the memory region between the
DSP
On 10/27/2023 7:50 PM, Luca Weiss wrote:
Add the node for the ADSP found on the SC7280 SoC, using standard
Qualcomm firmware.
The memory region for sc7280-chrome-common.dtsi is taken from msm-5.4
yupik.dtsi since the other areas also seem to match that file there,
though I cannot be sure ther
ctions")
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202310190437.pai6lyjf-...@intel.com/
Signed-off-by: Yujie Liu
Not related to this patch, but I see order of the argument as well is
not proper in the document of the __kprobe_event_gen_cmd_start(),
if you c
ostedt (Google)
Reviewed-by: Mukesh Ojha
-Mukesh
---
fs/tracefs/internal.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/tracefs/internal.h b/fs/tracefs/internal.h
index 298d3ecaf621..64fde9490f52 100644
--- a/fs/tracefs/internal.h
+++ b/fs/tracefs/internal.h
@@ -37,7
n., Thanks.
Reviewed-by: Mukesh ojha
-Mukesh
-
if (file) {
call = file->event_call;
system = call->class->system;
=6939
Signed-off-by: Jiapeng Chong
Reviewed-by: Mukesh Ojha
-Mukesh
---
fs/tracefs/event_inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/tracefs/event_inode.c b/fs/tracefs/event_inode.c
index 1ccd100bc565..ba9d1cb0d24c 100644
--- a/fs/tracefs/event_inode.c
c-95f-1117-706c2c22...@inria.fr/
Fixes: 5790b1fb3d67 ("eventfs: Remove eventfs_file and just use eventfs_inode")
Reported-by: Julia Lawall
Signed-off-by: Steven Rostedt (Google)
Reviewed-by: Mukesh Ojha
-Mukesh
---
fs/tracefs/event_inode.c | 3 ++-
1 file changed, 2 inser
Hi Kees/All,
Could you please review again? I have addressed your comment made on
last patch version.
Thanks,
Mukesh
On 3/23/2021 12:12 AM, Mukesh Ojha wrote:
There could be a scenario where we define some region
in normal memory and use them store to logs which is later
retrieved by
cacheable could improve
performance.
This commit gives control to change mem_type from Device
tree, and also documents the value for normal memory.
Signed-off-by: Mukesh Ojha
---
Changes in v3:
- Minor code and documentation update done as per comment given by Kees.
Changes in v2:
- if-else
Hi All,
can you please review this ?
Thanks,
Mukesh
On 3/2/2021 1:59 PM, Mukesh Ojha wrote:
Hi Kees,
i have updated the patch based on your last comments.
please review.
Thanks,
Mukesh
On 2/25/2021 9:30 PM, Mukesh Ojha wrote:
There could be a sceanario where we define some region
in
Hi Kees,
i have updated the patch based on your last comments.
please review.
Thanks,
Mukesh
On 2/25/2021 9:30 PM, Mukesh Ojha wrote:
There could be a sceanario where we define some region
in normal memory and use them store to logs which is later
retrieved by bootloader during warm reset
So add the start check to avoid.
Signed-off-by: Huang Yiwei
Signed-off-by: Mukesh Ojha
---
change in v2:
- this is on top of first patchset.
fs/pstore/ram_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index 0da012f..a157
cacheable could improve
performance.
This commit gives control to change mem_type from Device
tree, and also documents the value for normal memory.
Signed-off-by: Mukesh Ojha
---
Changes in v2:
- if-else converted to switch case
- updated MODULE_PARM_DESC with new memory type.
- default setting
From: Mukesh Ojha
There could be a sceanario where we define some region
in normal memory and use them store to logs which is later
retrieved by bootloader during warm reset.
In this scenario, we wanted to treat this memory as normal
cacheable memory instead of default behaviour which
is an
So add the start check to avoid.
Signed-off-by: Huang Yiwei
Signed-off-by: Mukesh Ojha
---
change in v2:
- this is on top of first patchset.
fs/pstore/ram_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index 0da012f..a157
On 2/11/2021 1:47 AM, Kees Cook wrote:
On Wed, Feb 10, 2021 at 08:22:21PM +0530, Mukesh Ojha wrote:
There could be a sceanario where we define some region
in normal memory and use them store to logs which is later
retrieved by bootloader during warm reset.
In this scenario, we wanted to
On 2/10/2021 2:32 AM, Luck, Tony wrote:
Can we use existing backend pstore ram driver (fs/pstore/ram.c) for DDR
instead of SRAM ?
The expectation for pstore is that the system will go through a reset when it
crashes. Most systems do not preserve DDR contents across reset.
to support DDR, If w
cacheable could improve
performance.
This commit gives control to change mem_type from Device
tree, and also documents the value for normal memory.
Signed-off-by: Huang Yiwei
Signed-off-by: Mukesh Ojha
---
Documentation/admin-guide/ramoops.rst | 4 +++-
fs/pstore/ram.c | 1
Hi All,
Can we use existing backend pstore ram driver (fs/pstore/ram.c) for DDR
instead of SRAM ?
Was the current driver written only to support persistant RAM like SRAM
or it can accept further change
to support DDR, If we have a mechanism to copy stored data from DDR to
external device after
Cooling stats variable inside thermal_cooling_device_stats_update()
can get NULL. We should add a NULL check on stat inside for sanity.
Signed-off-by: Mukesh Ojha
---
drivers/thermal/thermal_sysfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/thermal/thermal_sysfs.c b/drivers
iterrupts => interrupts
stratight => straight
Minor comment correction.
Signed-off-by: Mukesh Ojha
---
kernel/sched/idle.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index 8dad5aa..2df8ae1 100644
--- a/kernel/sched/
witin => within
Signed-off-by: Mukesh Ojha
---
kernel/time/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/time/time.c b/kernel/time/time.c
index 5c54ca6..d31661c4 100644
--- a/kernel/time/time.c
+++ b/kernel/time/time.c
@@ -179,7 +179,7 @@
accuratly => accurately
while at it change `clock source` to clocksource to make
it align with its usage at other places.
Signed-off-by: Mukesh Ojha
---
kernel/time/jiffies.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/time/jiffies.c b/kernel/time/jiffie
write_seqcountbeqin => write_seqcount_begin
Signed-off-by: Mukesh Ojha
---
include/linux/seqlock.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
index bcf4cf2..370ef8f 100644
--- a/include/linux/seqlock.h
+++ b/incl
On 8/12/2019 4:12 PM, Jiri Olsa wrote:
On Fri, Aug 02, 2019 at 12:16:53AM +0530, Mukesh Ojha wrote:
Perf framework doesn't allow preserving CPU events across
CPU hotplugs. The events are scheduled out as and when the
CPU walks offline. Moreover, the framework also doesn't
allow the
On 9/11/2019 8:51 PM, Colin King wrote:
From: Colin Ian King
There is a spelling mistake in a TEST_ASSERT_VAL message. Fix it.
Signed-off-by: Colin Ian King
Reviewed-by: Mukesh Ojha
Thanks,
Mukesh
---
tools/perf/tests/event_update.c | 2 +-
1 file changed, 1 insertion(+), 1
On 8/12/2019 4:12 PM, Jiri Olsa wrote:
On Fri, Aug 02, 2019 at 12:16:53AM +0530, Mukesh Ojha wrote:
Perf framework doesn't allow preserving CPU events across
CPU hotplugs. The events are scheduled out as and when the
CPU walks offline. Moreover, the framework also doesn't
allow the
: Mukesh Ojha
Thanks,
Mukesh
---
tools/perf/builtin-annotate.c |5 +++--
tools/perf/builtin-buildid-cache.c |5 +++--
tools/perf/builtin-buildid-list.c |5 +++--
tools/perf/builtin-c2c.c |6 --
tools/perf/builtin-diff.c |9 +
tools
Commit-ID: a037d269221c0ae15f47046757afcbd1a7177bbf
Gitweb: https://git.kernel.org/tip/a037d269221c0ae15f47046757afcbd1a7177bbf
Author: Mukesh Ojha
AuthorDate: Wed, 31 Jul 2019 20:35:04 +0530
Committer: Peter Zijlstra
CommitDate: Tue, 6 Aug 2019 12:49:16 +0200
locking/mutex: Use mutex
Commit-ID: 5f35d5a66b3ec62cb5ec4ec2ad9aebe2ac325673
Gitweb: https://git.kernel.org/tip/5f35d5a66b3ec62cb5ec4ec2ad9aebe2ac325673
Author: Mukesh Ojha
AuthorDate: Wed, 31 Jul 2019 20:35:03 +0530
Committer: Peter Zijlstra
CommitDate: Tue, 6 Aug 2019 12:49:16 +0200
locking/mutex: Make
On 8/1/2019 8:58 AM, Masanari Iida wrote:
This patch fix a spelling typo in Makefile.
Signed-off-by: Masanari Iida
Reviewed-by: Mukesh Ojha
-Mukesh
---
tools/perf/Documentation/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/Documentation
ander Shishkin
Cc: Jiri Olsa
Cc: Alexei Starovoitov
Mukesh Ojha (1):
perf: event preserve and create across cpu hotplug
include/linux/perf_event.h | 1 +
kernel/events/core.c | 122 +
2 files changed, 79 insertions(+), 44 deletions(-)
o Ananta
Signed-off-by: Mukesh Ojha
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Alexei Starovoitov
---
Change in V5:
=
- Rebased it.
Change in V4:
=
- Released, __get_cpu_context would not be correct
Use the mutex flag macro instead of hard code value inside
__mutex_owner().
Signed-off-by: Mukesh Ojha
---
Changes in v3:
- no change.
Changes in v2:
- Framed the commit according the changes done in 1/2 of
the patchset.
kernel/locking/mutex.c | 2 +-
1 file changed, 1 insertion(+), 1
gacy thing intact move them as well and
export them.
Move mutex_waiter structure also to keep it private to the
file.
Signed-off-by: Mukesh Ojha
---
Changes in v3:
- Moved mutex_waiter and removed inline from mutex_trylock_recursive()
mutex_is_owner().
Changes in v2:
- On Peterz suggest
On 7/30/2019 9:32 PM, Peter Zijlstra wrote:
On Tue, Jul 30, 2019 at 06:10:49PM +0530, Mukesh Ojha wrote:
To make it static , i have to export mutex_is_locked() after moving it
inside mutex.c, so that other module can use it.
Yep, see below -- completely untested.
Also are we thinking of
Use the mutex flag macro instead of hard code value inside
__mutex_owner().
Signed-off-by: Mukesh Ojha
---
Changes in v2:
- Framed the commit according the changes done in 1/2 of
the patchset.
kernel/locking/mutex.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel
ing intact move them as well and
export them.
Signed-off-by: Mukesh Ojha
---
Changes in v2:
- On Peterz suggestion, moved __mutex_owner() to mutex.c to
make it static to mutex.c.
- Exported mutex_is_owner() and mutex_trylock_recursive()
to keep the existing thing intact as there are loadable
On 7/30/2019 1:33 PM, Peter Zijlstra wrote:
On Tue, Jul 30, 2019 at 01:23:13PM +0530, Mukesh Ojha wrote:
On 7/29/2019 4:37 PM, Peter Zijlstra wrote:
On Mon, Jul 29, 2019 at 04:22:58PM +0530, Mukesh Ojha wrote:
Let's use the mutex flag macro(which got moved from mutex.c
to linux/mutex
On 7/29/2019 4:37 PM, Peter Zijlstra wrote:
On Mon, Jul 29, 2019 at 04:22:58PM +0530, Mukesh Ojha wrote:
Let's use the mutex flag macro(which got moved from mutex.c
to linux/mutex.h in the last patch) instead of hard code
value which was used in __mutex_owner().
Signed-off-by: Mukesh
Let's use the mutex flag macro(which got moved from mutex.c
to linux/mutex.h in the last patch) instead of hard code
value which was used in __mutex_owner().
Signed-off-by: Mukesh Ojha
---
include/linux/mutex.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/
There exist a place where we use hard code value for mutex
flag(e.g in mutex.h __mutex_owner()). Let's move the mutex
flag macros to header linux/mutex.h, so that it could be
reused at other places as well.
Signed-off-by: Mukesh Ojha
---
include/linux/mutex.h | 15 +++
k
There is a spelling mistake in file tree_exp.h,
fix this.
Signed-off-by: Mukesh Ojha
---
kernel/rcu/tree_exp.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
index af7e7b9..609fc87 100644
--- a/kernel/rcu/tree_exp.h
+++ b/kernel
Hi All,
Can you please review this ?
Thanks,
Mukesh
On 6/24/2019 2:31 PM, Mukesh Ojha wrote:
Friendly ping.
On 6/18/2019 7:16 PM, Mukesh Ojha wrote:
The embedded world, specifically Android mobile SoCs, rely on CPU
hotplugs to manage power and thermal constraints. These hotplugs
can happen
On 7/24/2019 7:11 PM, Mukesh Ojha wrote:
On 7/18/2019 4:49 PM, Muchun Song wrote:
There is a race condition between removing glue directory and adding
a new
device under the glue directory. It can be reproduced in following test:
path 1: Add the child device under glue dir
device_add
ttps://lkml.org/lkml/2019/5/1/3
+ref = kref_read(&glue_dir->kref);
+if (!kobject_has_children(glue_dir) && --ref)
We have seen many pattern of this issue which is coming from different
driver e.g uinput as well in 4.14
kernel.(https://lkml.org/lkml/2019/4/10/146)
Friendly Ping.
More explanation of the usecase added in the coverletter
[PATCH RESEND V4 0/1] perf: Add CPU hotplug support for events.
-Mukesh
On 6/18/2019 7:16 PM, Mukesh Ojha wrote:
Perf framework doesn't allow preserving CPU events across
CPU hotplugs. The events are scheduled out a
On 6/28/2019 10:29 PM, Mark Rutland wrote:
On Fri, Jun 28, 2019 at 10:23:10PM +0530, Mukesh Ojha wrote:
Hi All,
Hi Mukesh,
Is it looks considerable to add cluster based event support to add in
current perf event framework and later in userspace perf to support
such events ?
Could you
Hi All,
Is it looks considerable to add cluster based event support to add in
current perf event framework and later
in userspace perf to support such events ?
Thanks,
Mukesh
Friendly ping.
On 6/18/2019 7:16 PM, Mukesh Ojha wrote:
The embedded world, specifically Android mobile SoCs, rely on CPU
hotplugs to manage power and thermal constraints. These hotplugs
can happen at a very rapid pace. Adjacently, they also relies on
many perf event counters for its management
o Ananta
Signed-off-by: Mukesh Ojha
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Alexei Starovoitov
---
Change in V4:
=
- Released, __get_cpu_context would not be correct way to get the
cpu context of the cpu which is
243819 cycles
9.6300522877102438 cycles
9.839848225 337454 cycles
10.049645048 644072 cycles
10.2594762461855410 cycles
Mukesh Ojha (1):
perf: event preserve and create across cpu hotpl
On 6/18/2019 5:53 PM, Peter Zijlstra wrote:
On Tue, Jun 18, 2019 at 02:24:51PM +0530, Mukesh Ojha wrote:
Perf framework doesn't allow preserving CPU events across
CPU hotplugs. The events are scheduled out as and when the
CPU walks offline. Moreover, the framework also doesn't
o Ananta
Signed-off-by: Mukesh Ojha
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Alexei Starovoitov
---
Change in V4:
=
- Released, __get_cpu_context would not be correct way to get the
cpu context of the cpu which is
o Ananta
Signed-off-by: Mukesh Ojha
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Cc: Alexander Shishkin
Cc: Jiri Olsa
Cc: Alexei Starovoitov
---
Change in V3:
- Jiri has tried perf stat -a and removed one of the cpu from the other
terminal. This resulted in a crash.
On 6/3/2019 11:23 PM, Jiri Olsa wrote:
On Fri, May 31, 2019 at 07:09:16PM +0530, Mukesh Ojha wrote:
Perf framework doesn't allow preserving CPU events across
CPU hotplugs. The events are scheduled out as and when the
CPU walks offline. Moreover, the framework also doesn't
allow the
1 - 100 of 366 matches
Mail list logo
