Re: [PATCH] remoteproc: Create a separate workqueue for recovery tasks

On 2020-12-21 16:35, Bjorn Andersson wrote: On Thu 17 Dec 12:49 CST 2020, Alex Elder wrote: On 12/17/20 12:21 PM, risha...@codeaurora.org wrote: > On 2020-12-17 08:12, Alex Elder wrote: > > On 12/15/20 4:55 PM, Bjorn Andersson wrote: > > > On Sat 12 Dec 14:48 CST 2020, Rishabh Bhatnagar wrote:

Re: [PATCH] remoteproc: Create a separate workqueue for recovery tasks

On 2020-12-17 08:12, Alex Elder wrote: On 12/15/20 4:55 PM, Bjorn Andersson wrote: On Sat 12 Dec 14:48 CST 2020, Rishabh Bhatnagar wrote: Create an unbound high priority workqueue for recovery tasks. I have been looking at a different issue that is caused by crash notification. What

Re: [PATCH] remoteproc: Add a rproc_set_firmware() API

On 2020-11-20 19:20, Suman Anna wrote: A new API, rproc_set_firmware() is added to allow the remoteproc platform drivers and remoteproc client drivers to be able to configure a custom firmware name that is different from the default name used during remoteproc registration. This function is

Re: [PATCH v3 1/4] remoteproc: sysmon: Ensure remote notification ordering

On 2020-11-21 21:41, Bjorn Andersson wrote: The reliance on the remoteproc's state for determining when to send sysmon notifications to a remote processor is racy with regard to concurrent remoteproc operations. Further more the advertisement of the state of other remote processor to a newly

Re: [PATCH v2 4/4] remoteproc: sysmon: Improve error messages

On 2020-11-04 20:50, Bjorn Andersson wrote: Improve the style of a few of the error messages printed by the sysmon implementation and fix the copy-pasted shutdown error in the send-event function. Signed-off-by: Bjorn Andersson --- Changes since v1: - New patch

Re: [PATCH v2 3/4] remoteproc: qcom: q6v5: Query sysmon before graceful shutdown

On 2020-11-04 20:50, Bjorn Andersson wrote: Requesting a graceful shutdown through the shared memory state signals will not be acked in the event that sysmon has already successfully shut down the remote firmware. So extend the stop request API to optinally optionally take the remoteproc's

Re: [PATCH v2 2/4] remoteproc: sysmon: Expose the shutdown result

On 2020-11-04 20:50, Bjorn Andersson wrote: A graceful shutdown of the Qualcomm remote processors where traditionally performed by invoking a shared memory state signal and waiting for the associated ack. This was later superseded by the "sysmon" mechanism, where some form of shared memory bus

Re: [PATCH v2 1/4] remoteproc: sysmon: Ensure remote notification ordering

On 2020-11-04 20:50, Bjorn Andersson wrote: The reliance on the remoteproc's state for determining when to send sysmon notifications to a remote processor is racy with regard to concurrent remoteproc operations. Further more the advertisement of the state of other remote processor to a newly

Re: [PATCH v4 0/3] Move recovery/coredump configuration to sysfs

On 2020-09-17 16:40, Randy Dunlap wrote: On 9/17/20 11:56 AM, Rishabh Bhatnagar wrote: From Android R onwards Google has restricted access to debugfs in user and user-debug builds. This restricts access to most of the features exposed through debugfs. This patch series removes the

Re: [PATCH] soc: qcom: pdr: Fixup array type of get_domain_list_resp message

On 2020-09-14 07:58, Sibi Sankar wrote: The array type of get_domain_list_resp is incorrectly marked as NO_ARRAY. Due to which the following error was observed when using pdr helpers with the downstream proprietary pd-mapper. Fix this up by marking it as VAR_LEN_ARRAY instead. Err logs:

Re: [PATCH v2 0/3] Expose recovery/coredump configuration from sysfs

+android kernel team On 2020-09-09 10:27, risha...@codeaurora.org wrote: On 2020-09-04 15:02, Mathieu Poirier wrote: On Thu, Sep 03, 2020 at 06:59:44PM -0500, Bjorn Andersson wrote: On Tue 01 Sep 17:05 CDT 2020, Mathieu Poirier wrote: > Hi Rishabh, > > On Thu, Aug 27, 2020 at 12:48:48PM

Re: [PATCH v2 0/3] Expose recovery/coredump configuration from sysfs

On 2020-09-04 15:02, Mathieu Poirier wrote: On Thu, Sep 03, 2020 at 06:59:44PM -0500, Bjorn Andersson wrote: On Tue 01 Sep 17:05 CDT 2020, Mathieu Poirier wrote: > Hi Rishabh, > > On Thu, Aug 27, 2020 at 12:48:48PM -0700, Rishabh Bhatnagar wrote: > > From Android R onwards Google has

Re: [PATCH v2 0/3] Expose recovery/coredump configuration from sysfs

On 2020-09-01 15:05, Mathieu Poirier wrote: Hi Rishabh, On Thu, Aug 27, 2020 at 12:48:48PM -0700, Rishabh Bhatnagar wrote: From Android R onwards Google has restricted access to debugfs in user and user-debug builds. This restricts access to most of the features exposed through debugfs. This

Re: [PATCH v7 3/4] remoteproc: Add inline coredump functionality

On 2020-07-16 01:25, Sibi Sankar wrote: On 2020-07-10 02:01, Rishabh Bhatnagar wrote: The current coredump implementation uses vmalloc area to copy all the segments. But this might put strain on low memory targets as the firmware size sometimes is in tens of MBs. The situation becomes worse if

Re: [PATCH v1 2/4] remoteproc: qcom_q6v5_mss: Replace mask based tracking with size

On 2020-07-16 01:10, Sibi Sankar wrote: On 2020-07-14 22:48, Mathieu Poirier wrote: On Thu, Jul 09, 2020 at 01:31:54PM -0700, Rishabh Bhatnagar wrote: From: Sibi Sankar In order to land inline coredump support for mss, the dump_segment function would need to support granularities less than

Re: [PATCH v7 3/4] remoteproc: Add inline coredump functionality

On 2020-07-14 10:53, Mathieu Poirier wrote: On Thu, Jul 09, 2020 at 01:31:55PM -0700, Rishabh Bhatnagar wrote: The current coredump implementation uses vmalloc area to copy all the segments. But this might put strain on low memory targets as the firmware size sometimes is in tens of MBs. The

Re: [PATCH v7 1/5] dt-bindings: remoteproc: Add Qualcomm PIL info binding

On 2020-06-22 12:19, Bjorn Andersson wrote: Add a devicetree binding for the Qualcomm peripheral image loader relocation information region found in the IMEM. Reviewed-by: Mathieu Poirier Reviewed-by: Rob Herring Reviewed-by: Stephen Boyd Reviewed-by: Vinod Koul Signed-off-by: Bjorn

Re: [PATCH v7 3/5] remoteproc: qcom: Update PIL relocation info on load

On 2020-06-22 12:19, Bjorn Andersson wrote: Update the PIL relocation information in IMEM with information about where the firmware for various remoteprocs are loaded. Reviewed-by: Vinod Koul Reviewed-by: Stephen Boyd Signed-off-by: Bjorn Andersson --- Changes since v6: - None

Re: [PATCH v7 2/5] remoteproc: qcom: Introduce helper to store pil info in IMEM

On 2020-06-22 12:19, Bjorn Andersson wrote: A region in IMEM is used to communicate load addresses of remoteproc to post mortem debug tools. Implement a helper function that can be used to store this information in order to enable these tools to process collected ramdumps. Reviewed-by:

Re: [RESEND v1] soc: qcom: pdr: Reorder the PD state indication ack

On 2020-07-01 12:59, Sibi Sankar wrote: The Protection Domains (PD) have a mechanism to keep its resources enabled until the PD down indication is acked. Reorder the PD state indication ack so that clients get to release the relevant resources before the PD goes down. Fixes: fbe639b44a82 ("soc:

Re: [PATCH v6 2/3] remoteproc: Add inline coredump functionality

On 2020-07-06 10:47, Mathieu Poirier wrote: On Mon, Jun 29, 2020 at 01:02:12PM -0700, Rishabh Bhatnagar wrote: The current coredump implementation uses vmalloc area to copy all the segments. But this might put strain on low memory targets as the firmware size sometimes is in tens of MBs. The

Re: [PATCH v5 1/2] remoteproc: qcom: Add per subsystem SSR notification

On 2020-06-23 14:45, Alex Elder wrote: On 6/22/20 8:04 PM, Rishabh Bhatnagar wrote: Currently there is a single notification chain which is called whenever any remoteproc shuts down. This leads to all the listeners being notified, and is not an optimal design as kernel drivers might only be

Re: [v4 PATCH 0/3] Extend coredump functionality

On 2020-06-22 15:23, Bjorn Andersson wrote: On Wed 27 May 13:26 PDT 2020, Rishabh Bhatnagar wrote: This patch series moves the coredump functionality to a separate file and adds "inline" coredump feature. Inline coredump directly copies segments from device memory during coredump to userspace.

Re: [PATCH v4 1/2] remoteproc: qcom: Add per subsystem SSR notification

On 2020-06-18 16:35, Bjorn Andersson wrote: On Thu 18 Jun 16:00 PDT 2020, Alex Elder wrote: On 5/27/20 10:34 PM, Rishabh Bhatnagar wrote: > Currently there is a single notification chain which is called whenever any > remoteproc shuts down. This leads to all the listeners being notified, and >

Re: [PATCH v3 1/2] remoteproc: Add remoteproc character device interface

On 2020-04-30 01:30, Arnaud POULIQUEN wrote: Hi Rishabh, On 4/21/20 8:10 PM, Rishabh Bhatnagar wrote: Add the character device interface into remoteproc framework. This interface can be used in order to boot/shutdown remote subsystems and provides a basic ioctl based interface to implement

Re: [PATCH v3 1/2] remoteproc: qcom: Add per subsystem SSR notification

On 2020-05-19 13:38, Bjorn Andersson wrote: On Tue 28 Apr 15:16 PDT 2020, Rishabh Bhatnagar wrote: Currently there is a single notification chain which is called whenever any remoteproc shuts down. This leads to all the listeners being notified, and is not an optimal design as kernel drivers

Re: [PATCH v5 3/5] remoteproc: qcom: Update PIL relocation info on load

On 2020-05-12 22:56, Bjorn Andersson wrote: Update the PIL relocation information in IMEM with information about where the firmware for various remoteprocs are loaded. Signed-off-by: Bjorn Andersson --- Changes since v4: - Dropped unnecessary comment about ignoring return value.

Re: [PATCH 2/3] remoteproc: Add inline coredump functionality

On 2020-05-07 13:21, Bjorn Andersson wrote: On Thu 16 Apr 11:38 PDT 2020, Rishabh Bhatnagar wrote: This patch adds the inline coredump functionality. The current coredump implementation uses vmalloc area to copy all the segments. But this might put a lot of strain on low memory targets as the

Re: [PATCH 2/3] remoteproc: Add inline coredump functionality

On 2020-05-11 17:30, Bjorn Andersson wrote: On Mon 11 May 17:11 PDT 2020, risha...@codeaurora.org wrote: On 2020-05-07 13:21, Bjorn Andersson wrote: > On Thu 16 Apr 11:38 PDT 2020, Rishabh Bhatnagar wrote: > > > This patch adds the inline coredump functionality. The current > > coredump

Re: [PATCH 2/3] remoteproc: Add inline coredump functionality

On 2020-05-07 13:21, Bjorn Andersson wrote: On Thu 16 Apr 11:38 PDT 2020, Rishabh Bhatnagar wrote: This patch adds the inline coredump functionality. The current coredump implementation uses vmalloc area to copy all the segments. But this might put a lot of strain on low memory targets as the

Re: [PATCH 4/4] arm64: defconfig: Remove QCOM_GLINK_SSR

On 2020-04-22 17:37, Bjorn Andersson wrote: Remove the QCOM_GLINK_SSR option from the arm64 defconfig, as the module is assimilated by QCOM_GLINK - which is selected by other means. Signed-off-by: Bjorn Andersson --- Acked-by: Rishabh Bhatnagar arch/arm64/configs/defconfig | 1 - 1 file

Re: [PATCH 3/4] rpmsg: glink: Integrate glink_ssr in qcom_glink

On 2020-04-22 17:37, Bjorn Andersson wrote: In all but the very special case of a system with _only_ glink_rpm, GLINK is dependent on glink_ssr, so move it to rpmsg and combine it with qcom_glink_native in the new qcom_glink kernel module. Signed-off-by: Bjorn Andersson --- Acked-by:

Re: [PATCH 2/4] soc: qcom: glink_ssr: Internalize ssr_notifiers

On 2020-04-22 17:37, Bjorn Andersson wrote: Rather than carrying a special purpose blocking notifier for glink_ssr in remoteproc's qcom_common.c, move it into glink_ssr so allow wider reuse of the common one. The rpmsg glink header file is used in preparation for the next patch. Signed-off-by:

Re: [PATCH 1/4] remoteproc: qcom: Pass ssr_name to glink subdevice

On 2020-04-22 17:37, Bjorn Andersson wrote: Pass ssr_name to glink subdevice in preparation for tying glink_ssr to the glink subdevice, rather than having its own "ssr subdevice". Signed-off-by: Bjorn Andersson --- Acked-by: Rishabh Bhatnagar drivers/remoteproc/qcom_common.c| 9

Re: Bug at kernel/cred.c +443

On 2019-09-09 15:47, risha...@codeaurora.org wrote: Hi Miklos In 4.19 kernel when we write to a file that doesn't exist we see the following stack: [ 377.382745] ovl_create_or_link+0xac/0x710 [ 377.382745] ovl_create_object+0xb8/0x110 [ 377.382745] ovl_create+0x34/0x40 [ 377.382745]

Bug at kernel/cred.c +432

Hi Miklos In 4.19 kernel when we write to a file that doesn't exist we see the following stack: [ 377.382745] ovl_create_or_link+0xac/0x710 [ 377.382745] ovl_create_object+0xb8/0x110 [ 377.382745] ovl_create+0x34/0x40 [ 377.382745] path_openat+0xd44/0x15a8 [ 377.382745]

usercopy_warn in __copy_to_user

In the 4.19 kernel, we are seeing a USERCOPY_WARN in __copy_to_user during bootup. The code-flow is something like this: (arch/arm64/kernel/signal.c) struct sigset_t *set; __copy_to_user(>uc.uc_sigmask, set, sizeof(*set)) (include/linux/uaccess.h) __copy_to_user(void __user *to, const void

Re: [PATCH v1] dd: Invoke one probe retry cycle after some initcall levels

On 2018-08-13 10:39, Rishabh Bhatnagar wrote: From: Rishabh Bhatnagar Drivers that are registered at an initcall level may have to wait until late_init before the probe deferral mechanism can retry their probe functions. It is possible that their dependencies were resolved much earlier, in

Re: [PATCH v1] dd: Invoke one probe retry cycle after some initcall levels

On 2018-08-13 10:39, Rishabh Bhatnagar wrote: From: Rishabh Bhatnagar Drivers that are registered at an initcall level may have to wait until late_init before the probe deferral mechanism can retry their probe functions. It is possible that their dependencies were resolved much earlier, in

Re: [PATCH] dd: Invoke one probe retry cycle after every initcall level

On 2018-08-06 01:53, Rafael J. Wysocki wrote: On Fri, Aug 3, 2018 at 12:20 AM, Sodagudi Prasad wrote: From: RAFAEL J. WYSOCKI Date: Wed, Aug 1, 2018 at 2:21 PM Subject: Re: [PATCH] dd: Invoke one probe retry cycle after every initcall level To: Rishabh Bhatnagar Cc: "Rafael J. Wysocki" ,

Re: [PATCH] dd: Invoke one probe retry cycle after every initcall level

On 2018-08-06 01:53, Rafael J. Wysocki wrote: On Fri, Aug 3, 2018 at 12:20 AM, Sodagudi Prasad wrote: From: RAFAEL J. WYSOCKI Date: Wed, Aug 1, 2018 at 2:21 PM Subject: Re: [PATCH] dd: Invoke one probe retry cycle after every initcall level To: Rishabh Bhatnagar Cc: "Rafael J. Wysocki" ,

Re: [PATCH] firmware: Fix security issue with request_firmware_into_buf()

On 2018-08-02 14:58, Luis Chamberlain wrote: On Wed, Aug 1, 2018, 4:26 PM Rishabh Bhatnagar wrote: When calling request_firmware_into_buf() with the FW_OPT_NOCACHE flag it is expected that firmware is loaded into buffer from memory. But inside alloc_lookup_fw_priv every new firmware that is

Re: [PATCH] firmware: Fix security issue with request_firmware_into_buf()

On 2018-08-02 14:58, Luis Chamberlain wrote: On Wed, Aug 1, 2018, 4:26 PM Rishabh Bhatnagar wrote: When calling request_firmware_into_buf() with the FW_OPT_NOCACHE flag it is expected that firmware is loaded into buffer from memory. But inside alloc_lookup_fw_priv every new firmware that is

Re: [PATCH] dd: Invoke one probe retry cycle after every initcall level

On 2018-07-24 01:24, Rafael J. Wysocki wrote: On Mon, Jul 23, 2018 at 10:22 PM, wrote: On 2018-07-23 04:17, Rafael J. Wysocki wrote: On Thu, Jul 19, 2018 at 11:24 PM, Rishabh Bhatnagar wrote: Drivers that are registered at an initcall level may have to wait until late_init before the

Re: [PATCH] dd: Invoke one probe retry cycle after every initcall level

On 2018-07-24 01:24, Rafael J. Wysocki wrote: On Mon, Jul 23, 2018 at 10:22 PM, wrote: On 2018-07-23 04:17, Rafael J. Wysocki wrote: On Thu, Jul 19, 2018 at 11:24 PM, Rishabh Bhatnagar wrote: Drivers that are registered at an initcall level may have to wait until late_init before the

Re: [PATCH] dd: Invoke one probe retry cycle after every initcall level

On 2018-07-23 04:17, Rafael J. Wysocki wrote: On Thu, Jul 19, 2018 at 11:24 PM, Rishabh Bhatnagar wrote: Drivers that are registered at an initcall level may have to wait until late_init before the probe deferral mechanism can retry their probe functions. It is possible that their dependencies

Re: [PATCH] dd: Invoke one probe retry cycle after every initcall level

On 2018-07-23 04:17, Rafael J. Wysocki wrote: On Thu, Jul 19, 2018 at 11:24 PM, Rishabh Bhatnagar wrote: Drivers that are registered at an initcall level may have to wait until late_init before the probe deferral mechanism can retry their probe functions. It is possible that their dependencies

Re: [PATCH v8 0/2] SDM845 System Cache Driver

On 2018-05-23 17:35, Rishabh Bhatnagar wrote: This series implements system cache or LLCC(Last Level Cache Controller) driver for SDM845 SOC. The purpose of the driver is to partition the system cache and program the settings such as priortiy, lines to probe while doing a look up in the system

Re: [PATCH v8 0/2] SDM845 System Cache Driver

On 2018-05-23 17:35, Rishabh Bhatnagar wrote: This series implements system cache or LLCC(Last Level Cache Controller) driver for SDM845 SOC. The purpose of the driver is to partition the system cache and program the settings such as priortiy, lines to probe while doing a look up in the system

Re: [PATCH v7 2/2] drivers: soc: Add LLCC driver

On 2018-05-22 12:38, Andy Shevchenko wrote: On Tue, May 22, 2018 at 9:33 PM, wrote: On 2018-05-18 14:01, Andy Shevchenko wrote: On Wed, May 16, 2018 at 8:43 PM, Rishabh Bhatnagar wrote: +#define ACTIVATE 0x1 +#define

Re: [PATCH v7 2/2] drivers: soc: Add LLCC driver

On 2018-05-22 12:38, Andy Shevchenko wrote: On Tue, May 22, 2018 at 9:33 PM, wrote: On 2018-05-18 14:01, Andy Shevchenko wrote: On Wed, May 16, 2018 at 8:43 PM, Rishabh Bhatnagar wrote: +#define ACTIVATE 0x1 +#define DEACTIVATE0x2 +#define

Re: [PATCH v7 2/2] drivers: soc: Add LLCC driver

On 2018-05-22 12:38, Andy Shevchenko wrote: On Tue, May 22, 2018 at 9:33 PM, wrote: On 2018-05-18 14:01, Andy Shevchenko wrote: On Wed, May 16, 2018 at 8:43 PM, Rishabh Bhatnagar wrote: +#define ACTIVATE 0x1 +#define

Re: [PATCH v7 2/2] drivers: soc: Add LLCC driver

On 2018-05-22 12:38, Andy Shevchenko wrote: On Tue, May 22, 2018 at 9:33 PM, wrote: On 2018-05-18 14:01, Andy Shevchenko wrote: On Wed, May 16, 2018 at 8:43 PM, Rishabh Bhatnagar wrote: +#define ACTIVATE 0x1 +#define DEACTIVATE0x2 +#define

Re: [PATCH v7 2/2] drivers: soc: Add LLCC driver

On 2018-05-18 14:01, Andy Shevchenko wrote: On Wed, May 16, 2018 at 8:43 PM, Rishabh Bhatnagar wrote: LLCC (Last Level Cache Controller) provides additional cache memory in the system. LLCC is partitioned into multiple slices and each slice gets its own priority, size,

Re: [PATCH v7 2/2] drivers: soc: Add LLCC driver

On 2018-05-18 14:01, Andy Shevchenko wrote: On Wed, May 16, 2018 at 8:43 PM, Rishabh Bhatnagar wrote: LLCC (Last Level Cache Controller) provides additional cache memory in the system. LLCC is partitioned into multiple slices and each slice gets its own priority, size, ID and other config

Re: [PATCH v6 1/2] dt-bindings: Documentation for qcom, llcc

On 2018-05-16 11:08, Stephen Boyd wrote: Quoting risha...@codeaurora.org (2018-05-16 10:33:14) On 2018-05-16 10:03, Stephen Boyd wrote: > Quoting Rishabh Bhatnagar (2018-05-08 13:22:00) >> + >> +- max-slices: >> + usage: required >> + Value Type: >> + Definition: Number of

Re: [PATCH v6 1/2] dt-bindings: Documentation for qcom, llcc

On 2018-05-16 11:08, Stephen Boyd wrote: Quoting risha...@codeaurora.org (2018-05-16 10:33:14) On 2018-05-16 10:03, Stephen Boyd wrote: > Quoting Rishabh Bhatnagar (2018-05-08 13:22:00) >> + >> +- max-slices: >> + usage: required >> + Value Type: >> + Definition: Number of

Re: [PATCH v6 1/2] dt-bindings: Documentation for qcom, llcc

On 2018-05-16 10:03, Stephen Boyd wrote: Quoting Rishabh Bhatnagar (2018-05-08 13:22:00) diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt new file mode 100644 index 000..a586a17 --- /dev/null +++

Re: [PATCH v6 1/2] dt-bindings: Documentation for qcom, llcc

On 2018-05-16 10:03, Stephen Boyd wrote: Quoting Rishabh Bhatnagar (2018-05-08 13:22:00) diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.txt new file mode 100644 index 000..a586a17 --- /dev/null +++

Re: [PATCH v5 1/2] dt-bindings: Documentation for qcom, llcc

On 2018-04-30 07:33, Rob Herring wrote: On Fri, Apr 27, 2018 at 5:57 PM, wrote: On 2018-04-27 07:21, Rob Herring wrote: On Mon, Apr 23, 2018 at 04:09:31PM -0700, Rishabh Bhatnagar wrote: Documentation for last level cache controller device tree bindings, client

Re: [PATCH v5 1/2] dt-bindings: Documentation for qcom, llcc

On 2018-04-30 07:33, Rob Herring wrote: On Fri, Apr 27, 2018 at 5:57 PM, wrote: On 2018-04-27 07:21, Rob Herring wrote: On Mon, Apr 23, 2018 at 04:09:31PM -0700, Rishabh Bhatnagar wrote: Documentation for last level cache controller device tree bindings, client bindings usage examples.

Re: [PATCH v5 1/2] dt-bindings: Documentation for qcom, llcc

On 2018-04-27 07:21, Rob Herring wrote: On Mon, Apr 23, 2018 at 04:09:31PM -0700, Rishabh Bhatnagar wrote: Documentation for last level cache controller device tree bindings, client bindings usage examples. Signed-off-by: Channagoud Kadabi Signed-off-by: Rishabh

Re: [PATCH v5 1/2] dt-bindings: Documentation for qcom, llcc

On 2018-04-27 07:21, Rob Herring wrote: On Mon, Apr 23, 2018 at 04:09:31PM -0700, Rishabh Bhatnagar wrote: Documentation for last level cache controller device tree bindings, client bindings usage examples. Signed-off-by: Channagoud Kadabi Signed-off-by: Rishabh Bhatnagar ---

Re: [PATCH v4 1/2] Documentation: Documentation for qcom, llcc

On 2018-04-17 10:43, risha...@codeaurora.org wrote: On 2018-04-16 07:59, Rob Herring wrote: On Tue, Apr 10, 2018 at 01:08:12PM -0700, Rishabh Bhatnagar wrote: Documentation for last level cache controller device tree bindings, client bindings usage examples. "Documentation: Documentation

Re: [PATCH v4 1/2] Documentation: Documentation for qcom, llcc

On 2018-04-17 10:43, risha...@codeaurora.org wrote: On 2018-04-16 07:59, Rob Herring wrote: On Tue, Apr 10, 2018 at 01:08:12PM -0700, Rishabh Bhatnagar wrote: Documentation for last level cache controller device tree bindings, client bindings usage examples. "Documentation: Documentation

Re: [PATCH v4 1/2] Documentation: Documentation for qcom, llcc

On 2018-04-16 07:59, Rob Herring wrote: On Tue, Apr 10, 2018 at 01:08:12PM -0700, Rishabh Bhatnagar wrote: Documentation for last level cache controller device tree bindings, client bindings usage examples. "Documentation: Documentation ..."? That wastes a lot of the subject line... The

Re: [PATCH v4 1/2] Documentation: Documentation for qcom, llcc

On 2018-04-16 07:59, Rob Herring wrote: On Tue, Apr 10, 2018 at 01:08:12PM -0700, Rishabh Bhatnagar wrote: Documentation for last level cache controller device tree bindings, client bindings usage examples. "Documentation: Documentation ..."? That wastes a lot of the subject line... The

Re: [PATCH v4 2/2] drivers: soc: Add LLCC driver

On 2018-04-16 10:14, Evan Green wrote: On Fri, Apr 13, 2018 at 4:08 PM wrote: On 2018-04-12 15:02, Evan Green wrote: > Hi Rishabh, > > On Tue, Apr 10, 2018 at 1:09 PM Rishabh Bhatnagar > > wrote: > >> LLCC (Last Level Cache Controller)

Re: [PATCH v4 2/2] drivers: soc: Add LLCC driver

On 2018-04-16 10:14, Evan Green wrote: On Fri, Apr 13, 2018 at 4:08 PM wrote: On 2018-04-12 15:02, Evan Green wrote: > Hi Rishabh, > > On Tue, Apr 10, 2018 at 1:09 PM Rishabh Bhatnagar > > wrote: > >> LLCC (Last Level Cache Controller) provides additional cache memory >> in the system. LLCC

Re: [PATCH v4 2/2] drivers: soc: Add LLCC driver

On 2018-04-12 15:02, Evan Green wrote: Hi Rishabh, On Tue, Apr 10, 2018 at 1:09 PM Rishabh Bhatnagar wrote: LLCC (Last Level Cache Controller) provides additional cache memory in the system. LLCC is partitioned into multiple slices and each slice gets its own

Re: [PATCH v4 2/2] drivers: soc: Add LLCC driver

On 2018-04-12 15:02, Evan Green wrote: Hi Rishabh, On Tue, Apr 10, 2018 at 1:09 PM Rishabh Bhatnagar wrote: LLCC (Last Level Cache Controller) provides additional cache memory in the system. LLCC is partitioned into multiple slices and each slice gets its own priority, size, ID and other

Re: [PATCH v3 2/2] drivers: soc: Add LLCC driver

Hi Stanimir, We incorporated all your comments except the following: 1. Removing the driver that maintains the SCT (system cache table) per chipset. As responded earlier the data is expected to change from chipset to chipset and would clutter the main driver if we choose using compatible string.

Re: [PATCH v3 2/2] drivers: soc: Add LLCC driver

Hi Stanimir, We incorporated all your comments except the following: 1. Removing the driver that maintains the SCT (system cache table) per chipset. As responded earlier the data is expected to change from chipset to chipset and would clutter the main driver if we choose using compatible string.