On 4/13/21 7:19 PM, Nishanth Menon wrote:
> Rename message-manager instance node name to be better aligned with
> current style of device tree nodes for mailboxes.
>
> Signed-off-by: Nishanth Menon
Acked-by: Suman Anna
> ---
>
> Santosh:
> - This is'nt crit
Hi Rob,
On 3/27/21 9:31 AM, Suman Anna wrote:
> The K3 AM64x SoCs have two dual-core Arm R5F clusters/subsystems, with
> 2 R5F cores each, both in the MAIN voltage domain.
>
> These clusters are a revised IP version compared to those present on
> J721E and J7200 SoCs, and support
Hi Bjorn,
On 4/7/21 10:56 AM, Suman Anna wrote:
> Hi All,
>
> The following is a minor revised version of the series [1] that includes fixes
> for various different issues associated with the PRU firmware event/interrupt
> mapping configuration logic. Please see the v1 cover
and boot the PRU.
Fix this by returning an error value back upon any such failure. While
at this, revise the error trace to print some meaningful info about the
failed event.
Fixes: c75c9fdac66e ("remoteproc: pru: Add support for PRU specific interrupt
configuration")
Signed-off-by:
quot;remoteproc: pru: Add support for PRU specific interrupt
configuration")
Reported-by: Vignesh Raghavendra
Signed-off-by: Suman Anna
---
v2:
- Fixed two additional cleanup paths in pru_handle_intrmap()
addressing Mathieu's review comment
v1:
https://patchwork.kernel
always find and use the sibling interrupt controller.
Also, while at this, fix the acquired interrupt controller device node
reference properly.
Fixes: c75c9fdac66e ("remoteproc: pru: Add support for PRU specific interrupt
configuration")
Signed-off-by: Suman Anna
Reviewed-by: Mathi
.
regards
Suman
[1]
https://patchwork.kernel.org/project/linux-remoteproc/cover/20210323223839.17464-1-s-a...@ti.com/
Suman Anna (3):
remoteproc: pru: Fixup interrupt-parent logic for fw events
remoteproc: pru: Fix wrong success return value for fw events
remoteproc: pru: Fix and cleanup
On 4/6/21 6:28 PM, Mathieu Poirier wrote:
> On Tue, Mar 23, 2021 at 05:38:37PM -0500, Suman Anna wrote:
>> The PRU firmware interrupt mapping logic in pru_handle_intrmap() uses
>> of_irq_find_parent() with PRU device node to get a handle to the PRUSS
>> Interrupt Controller a
Hi Mathieu,
On 4/6/21 6:47 PM, Mathieu Poirier wrote:
> On Tue, Mar 23, 2021 at 05:38:39PM -0500, Suman Anna wrote:
>> The PRU firmware interrupt mappings are configured and unconfigured in
>> .start() and .stop() callbacks respectively using the variables 'evt_count&#
. Also,
corrected the AM46x typo in the cover-letter title :)
regards
Suman
[1]
https://patchwork.kernel.org/project/linux-remoteproc/cover/20210318215842.8196-1-s-a...@ti.com/
Suman Anna (2):
dt-bindings: remoteproc: k3-r5f: Update bindings for AM64x SoCs
remoteproc: k3-r5: Extend support to R5F
the K3 R5F remoteproc bindings with the compatible
info relevant to these R5F clusters/subsystems on K3 AM64x SoCs.
Signed-off-by: Suman Anna
---
v2: No changes
.../bindings/remoteproc/ti,k3-r5f-rproc.yaml | 31 ---
1 file changed, 26 insertions(+), 5 deletions(-)
diff --git a/Doc
oCs. The
reset assert and deassert sequence of both the cores in Single-CPU mode
is agnostic of the order, so the same LockStep reset and release sequences
are re-used.
The integration of these clusters is very much similar to existing SoCs
otherwise.
Signed-off-by: Suman Anna
---
v2:
- Address a
On 3/25/21 5:17 PM, Mathieu Poirier wrote:
> On Thu, Mar 25, 2021 at 04:00:55PM -0500, Suman Anna wrote:
>> Hi Mathieu,
>>
>> On 3/25/21 12:30 PM, Mathieu Poirier wrote:
>>> Good morning,
>>>
>>> On Thu, Mar 18, 2021 at 04:58:42PM -0500, Suman Anna w
Hi Mathieu,
On 3/25/21 12:30 PM, Mathieu Poirier wrote:
> Good morning,
>
> On Thu, Mar 18, 2021 at 04:58:42PM -0500, Suman Anna wrote:
>> The K3 AM64x SoC family has a revised R5F sub-system and contains a
>> subset of the R5F clusters present on J721E SoCs. The K3 AM64x
On 3/25/21 3:09 PM, Suman Anna wrote:
> On 3/25/21 12:36 PM, Mathieu Poirier wrote:
>> On Wed, 24 Mar 2021 at 11:09, Suman Anna wrote:
>>>
>>> On 3/23/21 6:20 PM, Mathieu Poirier wrote:
>>>> On Mon, Mar 15, 2021 at 03:58:59PM -0500, Suman Anna wrote:
>>
On 3/25/21 12:36 PM, Mathieu Poirier wrote:
> On Wed, 24 Mar 2021 at 11:09, Suman Anna wrote:
>>
>> On 3/23/21 6:20 PM, Mathieu Poirier wrote:
>>> On Mon, Mar 15, 2021 at 03:58:59PM -0500, Suman Anna wrote:
>>>> The K3 PRUs are 32-bit processors and in general
Hi Mathieu,
On 3/24/21 11:46 AM, Mathieu Poirier wrote:
> Good day Suman,
>
> On Thu, Mar 18, 2021 at 04:58:42PM -0500, Suman Anna wrote:
>> The K3 AM64x SoC family has a revised R5F sub-system and contains a
>> subset of the R5F clusters present on J721E SoCs. The K3 AM64x
On 3/23/21 6:20 PM, Mathieu Poirier wrote:
> On Mon, Mar 15, 2021 at 03:58:59PM -0500, Suman Anna wrote:
>> The K3 PRUs are 32-bit processors and in general have some limitations
>> in using the standard ARMv8 memcpy function for loading firmware segments,
>> so the driver
quot;remoteproc: pru: Add support for PRU specific interrupt
configuration")
Reported-by: Vignesh Raghavendra
Signed-off-by: Suman Anna
---
drivers/remoteproc/pru_rproc.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/remoteproc/pru_rproc.c b/driver
fc ("remoteproc: pru: Fix firmware loading crashes on K3 SoCs")
regards
Suman
Suman Anna (3):
remoteproc: pru: Fixup interrupt-parent logic for fw events
remoteproc: pru: Fix wrong success return value for fw events
remoteproc: pru: Fix and cleanup firmware interrupt mapping logic
and boot the PRU.
Fix this by returning an error value back upon any such failure. While
at this, revise the error trace to print some meaningful info about the
failed event.
Fixes: c75c9fdac66e ("remoteproc: pru: Add support for PRU specific interrupt
configuration")
Signed-off-by:
always find and use the sibling interrupt controller.
Also, while at this, fix the acquired interrupt controller device node
reference properly.
Fixes: c75c9fdac66e ("remoteproc: pru: Add support for PRU specific interrupt
configuration")
Signed-off-by: Suman Anna
---
drivers/remoteproc/p
On 3/18/21 4:58 PM, Suman Anna wrote:
> Hi All,
>
> The following series enhances the K3 R5F remoteproc driver to add support
> for the R5F clusters on the newer TI K3 AM64x SoC family. The AM64x SoCs
> have 2 R5FSS clusters and no DSPs. Both clusters are capable of supporti
oCs. The
reset assert and deassert sequence of both the cores in Single-CPU mode
is agnostic of the order, so the same LockStep reset and release sequences
are re-used.
The integration of these clusters is very much similar to existing SoCs
otherwise.
Signed-off-by: Suman Anna
---
driv
the K3 R5F remoteproc bindings with the compatible
info relevant to these R5F clusters/subsystems on K3 AM64x SoCs.
Signed-off-by: Suman Anna
---
.../bindings/remoteproc/ti,k3-r5f-rproc.yaml | 31 ---
1 file changed, 26 insertions(+), 5 deletions(-)
diff --git a/Documentation/
AM65x and J721E SoCs.
The series is based on 5.12-rc2, and can apply on top of the current
rproc-next branch as well.
regards
Suman
Suman Anna (2):
dt-bindings: remoteproc: k3-r5f: Update bindings for AM64x SoCs
remoteproc: k3-r5: Extend support to R5F clusters on AM64x SoCs
.../bindings/rem
c: Mark Brown
> Cc: Cheng-Yi Chiang
> Cc: Benson Leung
> Cc: Zhang Rui
> Cc: Daniel Lezcano
> Cc: Greg Kroah-Hartman
> Cc: Stefan Wahren
> Cc: Masahiro Yamada
> Cc: Odelu Kukatla
> Cc: Alex Elder
> Cc: Suman Anna
> Cc: Kuninori Morimoto
> Cc: Dmitry B
s PRU cores on K3
AM65x SoCs")
Signed-off-by: Suman Anna
---
drivers/remoteproc/pru_rproc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rproc.c
index 2667919d76b3..16979c1cd2f4 100644
--- a/drivers/remoteproc/p
On 2/9/21 1:24 PM, Rob Herring wrote:
> On Wed, Jan 27, 2021 at 01:55:59PM -0600, Suman Anna wrote:
>> Update the existing OMAP Mailbox binding to include the info for
>> AM64x SoCs. There are some minor IP integration differences between
>> the AM64x SoCs and the previou
/20210127195600.23501-1-s-a...@ti.com/
Suman Anna (2):
dt-bindings: mailbox: omap: Update binding for AM64x SoCs
mailbox: omap: Add support for K3 AM64x SoCs
Documentation/devicetree/bindings/mailbox/omap-mailbox.txt | 4
drivers/mailbox/omap-mailbox.c | 6 +-
2 files
through any Interrupt Routers and are hard-wired
to each processor, with only couple of interrupts from each cluster
reaching the A53 core. The IP is also not built with the K3 safety
feature in hardware.
Add the support for this IP through a new compatible.
Signed-off-by: Suman Anna
---
v2: No
Update the existing OMAP Mailbox binding to include the info for
AM64x SoCs. There are some minor IP integration differences between
the AM64x SoCs and the previous AM65x and J721E SoC families.
Signed-off-by: Suman Anna
---
v2: Remove AM64x example as per Rob's comments
v1:
Simplify the retrieval of getting the match data in the probe
function by directly using of_device_get_match_data() instead
of using of_match_node() and getting data.
Signed-off-by: Suman Anna
---
drivers/soc/ti/k3-ringacc.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff
On 1/28/21 5:21 PM, David Lechner wrote:
> On 1/28/21 4:55 PM, Suman Anna wrote:
>> Hi David,
>>
>> On 1/15/21 6:53 PM, Suman Anna wrote:
>>> On 1/4/21 3:18 PM, David Lechner wrote:
>>>> static int pru_rproc_probe(struct platform_device *p
Hi David,
On 1/15/21 6:53 PM, Suman Anna wrote:
> On 1/4/21 3:18 PM, David Lechner wrote:
>> Currently, to determine the ID (0 or 1) of a PRU core, the last 19 bits
>> of the physical address of the cores IRAM are compared to known values.
>> However, the PRUs on TI AM18XX ha
separately once the binding is acked/merged.
regards
Suman
[1]
https://patchwork.kernel.org/project/linux-arm-kernel/cover/20210120202532.9011-1-d-gerl...@ti.com/
Suman Anna (2):
dt-bindings: mailbox: omap: Update binding for AM64x SoCs
mailbox: omap: Add support for K3 AM64x SoCs
.../bindings
through any Interrupt Routers and are hard-wired
to each processor, with only couple of interrupts from each cluster
reaching the A53 core. The IP is also not built with the K3 safety
feature in hardware.
Add the support for this IP through a new compatible.
Signed-off-by: Suman Anna
---
drivers
Update the existing OMAP Mailbox binding to include the info for
AM64x SoCs. There are some minor IP integration differences between
the AM64x SoCs and the previous AM65x and J721E SoC families.
Signed-off-by: Suman Anna
---
.../bindings/mailbox/omap-mailbox.txt | 22
troller.yaml
is automatically applied to this binding.
Signed-off-by: Suman Anna
---
This patch is a result of the previous discussion at
https://patchwork.kernel.org/comment/23926133/
.../bindings/interrupt-controller/ti,pruss-intc.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git
Hi Rob,
On 1/25/21 8:47 PM, Rob Herring wrote:
> On Mon, Jan 25, 2021 at 6:16 PM Suman Anna wrote:
>>
>> Hi Rob,
>>
>> On 1/25/21 6:04 PM, Rob Herring wrote:
>>> On Fri, Jan 15, 2021 at 02:58:19PM -0600, Suman Anna wrote:
>>>> The '#addres
<<< No Message Collected >>>
Hi Santosh,
On 1/24/21 10:34 PM, santosh.shilim...@oracle.com wrote:
> Hi Suman, Mathieu,
>
> On 1/7/21 2:49 PM, Suman Anna wrote:
>> On 1/7/21 4:44 PM, Mathieu Poirier wrote:
>>> On Wed, Jan 06, 2021 at 06:03:25PM -0600, Suman Anna wrote:
>>>> Hi Mathieu,
&g
The CFG sub-module is not present on some earlier SoCs like the
DA850/OMAPL-138 in the TI Davinci family. Refactor out the CFG
sub-module parse and initialization logic into a separate function
to make it easier to add logic for the PRUSS IP on the above legacy
SoC families.
Signed-off-by: Suman
mmc(@.*)?$'
>
> Fix above warnings by updating mmc DT definitions to follow
> sdhci-am654.yaml bindings:
> - rename sdhci dt nodes to 'mmc@'
> - swap clk_xin/clk_ahb clocks, the clk_ahb clock expected to be defined
> first
>
> Signed-off-by: Grygorii
On 1/20/21 1:51 PM, Nishanth Menon wrote:
> We can use CPU specific pmu configuration to expose the appropriate
> CPU specific events rather than just the basic generic pmuv3 perf
> events.
>
> Reported-by: Sudeep Holla
> Signed-off-by: Nishanth Menon
Tested-by: Suman An
On 1/4/21 3:18 PM, David Lechner wrote:
> Currently, to determine the ID (0 or 1) of a PRU core, the last 19 bits
> of the physical address of the cores IRAM are compared to known values.
> However, the PRUs on TI AM18XX have IRAM at 0x01c38000 and 0x01c3c000
> respectively. The former conflicts wi
Hi David,
On 1/4/21 12:30 PM, David Lechner wrote:
> This adds support for the PRUSS found in AM18XX/OMAP-L138. This PRUSS
> doesn't have a CFG register, so that is made optional as selected by
> the device tree compatible string.
>
> ARCH_DAVINCI is added in the Kconfig so that the driver can be
to make it compliant with both dtbs_check and
building dtbs.
Signed-off-by: Suman Anna
---
Hi Rob,
This patch is also part of our effort to get rid of the warnings seen
around interrupt providers on TI K3 dtbs [1]. I needed this in the PRUSS
INTC bindings to not get a warning with dtbs_check while als
+ Sekhar and Bartosz
Hi David,
On 1/4/21 12:30 PM, David Lechner wrote:
> This adds a "ti,am1806-pruss" compatible type for the PRUSS found in
> TI AM18xx/OMAP-L138 SoCs.
>
> Signed-off-by: David Lechner
> ---
> Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml | 2 ++
> 1 file changed, 2
Hi Santosh,
On 12/21/20 3:32 PM, Rob Herring wrote:
> On Wed, 16 Dec 2020 23:50:27 +0100, Grzegorz Jaszczyk wrote:
>> Now after ti,pruss-intc.yaml and ti,pru-rproc.yaml are merged, include
>> them in proper property and extend the examples section.
>>
>> At the occasion extend the allowed property
The following commit has been merged into the irq/irqchip-next branch of
irqchip:
Commit-ID: b8e594fa20d2e33d40c7a8c7c106549a35c38972
Gitweb:
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms/b8e594fa20d2e33d40c7a8c7c106549a35c38972
Author:Suman Anna
The pruss_clk_init() function can register more than one clock.
Correct the existing misleading error trace upon a failure within
this function.
Signed-off-by: Suman Anna
---
drivers/soc/ti/pruss.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/ti/pruss.c b
part of the overall PRUSS software architecture, and is
not useful at all by itself.
Simplify the TI_PRUSS_INTC Kconfig dependencies by making it silent and
selected automatically when the TI_PRUSS platform driver is enabled.
Signed-off-by: Suman Anna
---
drivers/irqchip/Kconfig | 5 +++--
1
On 1/7/21 4:44 PM, Mathieu Poirier wrote:
> On Wed, Jan 06, 2021 at 06:03:25PM -0600, Suman Anna wrote:
>> Hi Mathieu,
>>
>> On 1/6/21 5:27 PM, Mathieu Poirier wrote:
>>> On Wed, Dec 16, 2020 at 05:52:34PM +0100, Grzegorz Jaszczyk wrote:
>>>> Hi All,
>
,prus' as suggested by Rob Herring,
>> which influences patch #1 and patch #2
>>
>> [1]
>> https://patchwork.kernel.org/project/linux-remoteproc/patch/20201121030156.22857-3-s-a...@ti.com/
>>
>> Best regards,
>> Grzegorz
>>
>> Roger Quadros (1)
Hi David,
On 1/4/21 2:11 PM, David Lechner wrote:
>
>> Please see the individual patches for exact changes in each patch, following
>> is
>> the only change from v1:
>> - Change the 'prus' property name to 'ti,prus' as suggested by Rob Herring,
>> which influences patch #1 and patch #2
>
> It
entation/devicetree/bindings/remoteproc/ingenic,vpu.yaml
>> @@ -44,7 +44,7 @@ properties:
>>- const: vpu
>>
>>interrupts:
>> -description: VPU hardware interrupt
>> +maxItems: 1
>>
>> required:
>>- compatible
>&g
Best regards,
> Grzegorz
>
> Grzegorz Jaszczyk (1):
> remoteproc: pru: Add support for PRU specific interrupt configuration
>
> Suman Anna (5):
> dt-bindings: remoteproc: Add binding doc for PRU cores in the PRU-ICSS
> remoteproc: pru: Add a PRU remoteproc driver
gt; Best regards,
> Grzegorz
>
> Grzegorz Jaszczyk (1):
> remoteproc/pru: Add support for PRU specific interrupt configuration
>
> Suman Anna (5):
> dt-bindings: remoteproc: Add binding doc for PRU cores in the PRU-ICSS
> remoteproc/pru: Add a PRU remoteproc d
ill come over the next few
>>> days.
>>>
>>> See below for a start.
>>>
>>> On Thu, Nov 19, 2020 at 03:08:46PM +0100, Grzegorz Jaszczyk wrote:
>>>> From: Suman Anna
>>>>
>>>> The Programmable Real-Time Unit Subsyst
On 11/23/20 6:55 PM, Mathieu Poirier wrote:
> On Mon, 23 Nov 2020 at 16:51, Mathieu Poirier
> wrote:
>>
>> Good afternoon Suman,
>>
>> On Wed, Nov 18, 2020 at 07:05:31PM -0600, Suman Anna wrote:
>>> The J7200 SoCs have a revised R5FSS IP that adds a unique
On 11/21/20 11:33 PM, Bjorn Andersson wrote:
> On Fri 20 Nov 21:44 CST 2020, Suman Anna wrote:
>
>> On 11/20/20 9:38 PM, Bjorn Andersson wrote:
>>> On Fri 20 Nov 21:01 CST 2020, Suman Anna wrote:
>>>
>>>> The remoteproc framework provides sysfs interfac
Hi Paul,
On 11/21/20 12:47 PM, Paul Cercueil wrote:
> Hi Suman,
>
> Le ven. 20 nov. 2020 à 17:06, Suman Anna a écrit :
>> Hi Paul,
>>
>> On 11/20/20 4:37 PM, Mathieu Poirier wrote:
>>> Hi Paul,
>>>
>>> On Sun, Nov 15, 2020 at 11:5
On 11/20/20 9:38 PM, Bjorn Andersson wrote:
> On Fri 20 Nov 21:01 CST 2020, Suman Anna wrote:
>
>> The remoteproc framework provides sysfs interfaces for changing
>> the firmware name and for starting/stopping a remote processor
>> through the sysfs files 'state&#
will be an example of such usage as it
requires to use different firmwares for different supported protocols.
Also, update the firmware_store() function used by the sysfs interface
to reuse this function to avoid code duplication.
Signed-off-by: Suman Anna
---
drivers/remoteproc/remoteproc_core.c
needs. The default
behavior is to allow the sysfs operations as before.
Signed-off-by: Suman Anna
---
v2: revised to account for the 'recovery' sysfs file as well, patch
description updated accordingly
v1:
https://patchwork.kernel.org/project/linux-remoteproc/patch/20180915
kernel.org/project/linux-remoteproc/cover/20180915003725.17549-1-s-a...@ti.com/
[2]
https://patchwork.kernel.org/project/linux-remoteproc/cover/20201119140850.12268-1-grzegorz.jaszc...@linaro.org/
Suman Anna (3):
remoteproc: Fix unbalanced boot with sysfs for no auto-boot rprocs
remoteproc:
The Wakeup M3 remote processor is controlled by the wkup_m3_ipc
client driver, so set the newly introduced 'deny_sysfs_ops' flag
to not allow any overriding of the remoteproc firmware or state
from userspace.
Signed-off-by: Suman Anna
---
v2: rebased version, no code changes, p
and releasing it during the sysfs 'stop'
operation.
Signed-off-by: Suman Anna
Acked-by: Arnaud Pouliquen
---
v2: rebased version, no changes
v1:
https://patchwork.kernel.org/project/linux-remoteproc/patch/20180915003725.17549-2-s-a...@ti.com/
drivers/remoteproc/remoteproc_sysfs
Hi Paul,
On 11/20/20 4:37 PM, Mathieu Poirier wrote:
> Hi Paul,
>
> On Sun, Nov 15, 2020 at 11:50:56AM +, Paul Cercueil wrote:
>> Until now the remoteproc core would always default to trying to boot the
>> remote processor at startup. The various remoteproc drivers could
>> however override t
these R5F clusters/subsystems on K3 J7200 SoCs.
Signed-off-by: Suman Anna
---
.../devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml
b/Documentation/devicetree
normal 32 KB size in Split mode. Enhance the
TI K3 R5F remoteproc for this logic through a new function. The adjustment
is a no-op on prior SoCs and relies on the correct DTS node sizes in
LockStep-mode on applicable SoCs.
Signed-off-by: Suman Anna
---
drivers/remoteproc/ti_k3_r5_remoteproc.c | 43
compatibles. Logic for the second feature is
added in the next patch. The integration of these clusters is very
much similar to J721E SoCs otherwise.
Signed-off-by: Suman Anna
---
drivers/remoteproc/ti_k3_r5_remoteproc.c | 52 +++-
1 file changed, 50 insertions(+), 2 deletions(-)
diff
well. Following is the patch summary:
- Patch 1 updates the dt-bindings
- Patch 2 introduces new SoC data logic and handles the TCM auto-init
feature
- Patch 3 handles the TCM adjustment logic in Split-mode
regards
Suman
Suman Anna (3):
dt-bindings: remoteproc: k3-r5f: Update bindings for
Hi Greg,
On 11/18/20 9:27 AM, Grzegorz Jaszczyk wrote:
> Hi Suman,
>
> On Tue, 17 Nov 2020 at 21:40, Suman Anna wrote:
>>
>> Hi Greg,
>>
>> On 11/14/20 2:46 AM, Grzegorz Jaszczyk wrote:
>>> The firmware blob can contain optional ELF sections: .resou
PU). The mappings are
> currently programmed during the booting/shutdown of the PRU.
>
> The interrupt configuration passed through .pru_irq_map ELF section is
> optional. It varies on specific firmware functionality and therefore
> have to be unwinded during PRU stop and performed
Hi Greg,
On 11/14/20 2:46 AM, Grzegorz Jaszczyk wrote:
> From: Suman Anna
>
> The K3 AM65x family of SoCs have the next generation of the PRU-ICSS
> processor subsystem, commonly referred to as ICSSG. Each ICSSG processor
> subsystem on AM65x SR1.0 contains two primary PRU co
Hi Greg,
I have a few minor comments below..
On 11/14/20 2:46 AM, Grzegorz Jaszczyk wrote:
> From: Suman Anna
>
> The Programmable Real-Time Unit Subsystem (PRUSS) consists of
> dual 32-bit RISC cores (Programmable Real-Time Units, or PRUs)
> for program execution. This patch ad
On 11/16/20 1:06 PM, santosh.shilim...@oracle.com wrote:
> On 11/16/20 9:31 AM, Suman Anna wrote:
>> Hi Santosh,
>>
>> On 11/16/20 11:22 AM, Grzegorz Jaszczyk wrote:
>>> Since the of_device_get_match_data() doesn't return error code, remove
>>> wrong IS
y, proceeding with empty device data is valid (e.g. in case
> of "ti,am3356-pruss").
>
> Fixes: ba59c9b43c86 ("soc: ti: pruss: support CORECLK_MUX and IEPCLK_MUX")
> Reported-by: Wei Yongjun
> Signed-off-by: Grzegorz Jaszczyk
> Acked-by: Suman Anna
Can
oceeding with empty device data is valid (e.g. in case
> of "ti,am3356-pruss").
>
> Reported-by: Wei Yongjun
Please add the appropriate Fixes: tag.
And prefer %s/Remove/Fix/ in patch title.
With that,
Acked-by: Suman Anna
regards
Suman
> Signed-off-by: Grzegorz Jasz
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 6016f32d1de2798cc88c1a4b703d0ea096c19793
Gitweb:
https://git.kernel.org/tip/6016f32d1de2798cc88c1a4b703d0ea096c19793
Author:Suman Anna
AuthorDate:Wed, 16 Sep 2020 18:36:36 +02:00
Committer
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 7e92dee60cba51f8a5c7637bac815e70c85935f7
Gitweb:
https://git.kernel.org/tip/7e92dee60cba51f8a5c7637bac815e70c85935f7
Author:Suman Anna
AuthorDate:Wed, 16 Sep 2020 18:36:38 +02:00
Committer
The following commit has been merged into the irq/core branch of tip:
Commit-ID: 8a1b09ed4308caf12c231430afb78d3331a85dc2
Gitweb:
https://git.kernel.org/tip/8a1b09ed4308caf12c231430afb78d3331a85dc2
Author:Suman Anna
AuthorDate:Wed, 16 Sep 2020 18:34:54 +02:00
Committer
ment fault on device type memory).
These SRAM regions are completely optional as not all firmware images
require these memories, and any such memory has to be reserved as such
in the DTS files.
Signed-off-by: Suman Anna
Reviewed-by: Mathieu Poirier
---
v5: No changes
v4: No changes
series for 5.10.
regards
Suman
[1] R5F v1: https://patchwork.kernel.org/cover/11456367/
[2] R5F v2: https://patchwork.kernel.org/cover/11632993/
[3] R5F v3: https://patchwork.kernel.org/cover/11679327/
[4] R5F v4: https://patchwork.kernel.org/cover/11763783/
Suman Anna (4):
dt-bindings
processors.
The R5F processors can also optionally use any internal on-chip SRAM
memories either for executing code or using it as fast-access data.
The added example illustrates the DT nodes for the single R5FSS device
present on K3 AM65x family of SoCs.
Signed-off-by: Suman Anna
---
v5
onto a R5F in remoteproc mode. Any R5F booted from U-Boot/SPL would
require a similar initialization in the bootloader. Note that both
the TCMs are initialized unconditionally as the TCM enable config bits
only manage the access and visibility from R5.
Signed-off-by: Suman Anna
Reviewed-by
o
slightly different in that these IPs do support an actual local reset line,
while they are a no-op on AM65x SoCs.
Signed-off-by: Suman Anna
Reviewed-by: Mathieu Poirier
---
v5: No changes
v4: https://patchwork.kernel.org/patch/11763795/
- Fixed error check and return code around devm_ior
On 9/24/20 7:39 AM, Lee Jones wrote:
> On Thu, 03 Sep 2020, Marc Zyngier wrote:
>
>> The name allocated for the regmap_config structure is freed
>> pretty early, right after the registration of the MMIO region.
>>
>> Unfortunately, that doesn't follow the life cycle that debugfs
>> expects, as it
>
> Changes in v4:
> - fixed comments from Suman Anna
>
> Changes in v3:
> - rebase
> - updated dependencies
> - added tested-by
>
> Changes in v2:
> - fixed DT build warnings (Nishanth Menon)
>
> v3: https://lore.kernel.org/patchwork/cover/1308044/
&g
Hi Rob,
On 9/22/20 2:47 PM, Rob Herring wrote:
> On Tue, Sep 08, 2020 at 12:45:52PM -0500, Suman Anna wrote:
>> Hi All,
>>
>> The following is v4 of the TI K3 R5F remoteproc driver series supporting all
>> the R5F processor clusters/subsystems on TI AM65x and J721E
Hi Grygorii,
On 9/18/20 10:38 AM, Grygorii Strashko wrote:
> From: Peter Ujfalusi
>
> Add the intr, inta, ringacc and udmap nodes for main and mcu NAVSS.
Need to update the changelog, intr and inta are not part of this revised series.
>
> Signed-off-by: Peter Ujfalusi
> Signed-off-by: Grygor
On 9/18/20 10:38 AM, Grygorii Strashko wrote:
> Add DT node for The TI j7200 MCU SoC Gigabit Ethernet two ports Switch
> subsystem (MCU CPSW NUSS).
nit, %s/j7200/J7200/ on this patch and the next.
regards
Suman
>
> Signed-off-by: Grygorii Strashko
> Tested-by: Kishon Vijay Abraham I
> ---
>
ore.yaml#',
>>> 'http://devicetree.org/meta-schemas/base.yaml#']
>>> Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml: ignoring, error
>>> in schema: $id
>>>
Thanks for the fix, Krzysztof.
Fixes: bd691ce0ba9d ("dt-bindings: soc: ti
On 9/11/20 9:26 AM, Philipp Zabel wrote:
> Hi Crystal,
>
> On Fri, 2020-09-11 at 14:07 +0800, Crystal Guo wrote:
> [...]
>> Should I add the SoC-specific data as follows?
>> This may also modify the ti original code, is it OK?
>>
>> + data->reset_data = of_device_get_match_data(&pdev->dev);
On 9/10/20 9:42 PM, Crystal Guo wrote:
> On Wed, 2020-09-09 at 23:39 +0800, Suman Anna wrote:
>> On 9/8/20 9:57 PM, Crystal Guo wrote:
>>> On Thu, 2020-09-03 at 07:40 +0800, Suman Anna wrote:
>>>> Hi Crystal,
>>>>
>>>> On 8/16/20 10:03 PM, C
On 9/8/20 9:57 PM, Crystal Guo wrote:
> On Thu, 2020-09-03 at 07:40 +0800, Suman Anna wrote:
>> Hi Crystal,
>>
>> On 8/16/20 10:03 PM, Crystal Guo wrote:
>>> Introduce ti_syscon_reset() to integrate assert and deassert together.
>>> If some modules need do se
On 9/8/20 1:49 PM, Rob Herring wrote:
> On Wed, Sep 2, 2020 at 5:26 PM Suman Anna wrote:
>>
>> Hi Rob,
>>
>> On 8/26/20 6:09 AM, Crystal Guo wrote:
>>> On Wed, 2020-08-26 at 03:02 +0800, Rob Herring wrote:
>>>> On Mon, Aug 17, 2020 at 11:03:22AM +08
Hi Santosh,
On 8/31/20 1:34 PM, santosh.shilim...@oracle.com wrote:
> On 8/29/20 11:41 AM, Grygorii Strashko wrote:
>> Hi Santosh,
>>
>> I've rebased on top of linux-next and identified merge conflict of patch 3
>> with commit 6da45875fa17 ("arm64: dts: k3-am65: Update the RM resource
>> types")
1 - 100 of 1001 matches
Mail list logo
