, and I am waiting
for that to be finalized before I update our BIOS-side logic/firmwares.
regards
Suman
[1] https://patchwork.kernel.org/patch/11096599/
Suman Anna (2):
ARM: dts: am5729-beaglebone-ai: Enable IPU & DSP rprocs
ARM: dts: am5729-beaglebone-ai: Disable ununsed mailboxes
arch
On 6/10/20 3:47 PM, Rob Herring wrote:
On Tue, Jun 09, 2020 at 09:47:02AM -0600, Mathieu Poirier wrote:
On Tue, 9 Jun 2020 at 09:29, Ben Levinsky wrote:
Hi Suman, Mathieu,
Thank you for your comments. Please see my replies inline.
Best Regards,
Ben
-Original Message-
From: Suman
Hi Paul,
On 6/8/20 5:46 PM, Paul Cercueil wrote:
Hi Suman,
On 5/15/20 5:43 AM, Paul Cercueil wrote:
Call pm_runtime_get_sync() before the firmware is loaded, and
pm_runtime_put() after the remote processor has been stopped.
Even though the remoteproc device has no PM callbacks, this allows
On 6/8/20 6:49 PM, Mathieu Poirier wrote:
On Wed, Jun 03, 2020 at 07:49:43AM -0700, Ben Levinsky wrote:
R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
remotproc driver, we can boot the R5 sub-system in different
configurations.
Acked-by: Stefano Stabellini
Acked-by: Ben
code to extract the information.
Suggested-by: Suman Anna ;
Signed-off-by: Mathieu Poirier
Acked-by: Arnaud Pouliquen
With the below minor nits fixed,
Acked-by: Suman Anna
---
drivers/rpmsg/rpmsg_core.c | 95 ++
include/linux/rpmsg.h | 13
On 5/20/20 9:49 AM, Arnaud POULIQUEN wrote:
Hi Bjorn,
On 5/15/20 11:09 PM, Bjorn Andersson wrote:
On Fri 15 May 13:56 PDT 2020, Mathieu Poirier wrote:
This patchset adds the capability to supplement the base definition
published by an rpmsg_driver with a postfix description so that it
is
Hi Paul,
On 5/22/20 12:11 PM, Paul Cercueil wrote:
Hi Suman,
Le ven. 22 mai 2020 à 11:47, Suman Anna a écrit :
Hi Paul,
On 5/15/20 5:43 AM, Paul Cercueil wrote:
Call pm_runtime_get_sync() before the firmware is loaded, and
pm_runtime_put() after the remote processor has been stopped.
Even
to my review and testing done back on v2,
Acked-by: Suman Anna
regards
Suman
---
drivers/rpmsg/rpmsg_core.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
index a6361cad608b..5e01e8dede6b 100644
TI patches based on 5.4 kernel.
regards
Suman
[1] https://patchwork.kernel.org/cover/11508091/
Suman Anna (2):
ARM: dts: dra7: Fix timer nodes properly for timer_sys_ck clocks
ARM: dts: dra7-evm-common: Fix duplicate mailbox nodes
arch/arm/boot/dts/dra7-evm-common.dtsi | 20 ---
roperly, so that any of these timers can be used with OMAP remoteproc
IPU and DSP devices. The always-on timers 1 and 12 are not expected
to use this clock source, so they are not modified.
Fixes: 5390130f3b28 ("ARM: dts: dra7: add timer_sys_ck entries for IPU/DSP
timers")
Signed-off-by: Suman Ann
.dtsi file. Fix this by removing these duplicate nodes.
Signed-off-by: Suman Anna
---
arch/arm/boot/dts/dra7-evm-common.dtsi | 20
1 file changed, 20 deletions(-)
diff --git a/arch/arm/boot/dts/dra7-evm-common.dtsi
b/arch/arm/boot/dts/dra7-evm-common.dtsi
index f8
Hi Rob,
On 5/28/20 5:47 PM, Suman Anna wrote:
Hi Rob,
On 5/28/20 5:32 PM, Rob Herring wrote:
On Wed, May 20, 2020 at 07:10:04PM -0500, Suman Anna wrote:
Some Texas Instruments K3 family of SoCs have one of more Digital Signal
Processor (DSP) subsystems that are comprised of either
Hi Rob,
On 5/28/20 5:32 PM, Rob Herring wrote:
On Wed, May 20, 2020 at 07:10:04PM -0500, Suman Anna wrote:
Some Texas Instruments K3 family of SoCs have one of more Digital Signal
Processor (DSP) subsystems that are comprised of either a TMS320C66x
CorePac and/or a next-generation TMS320C71x
Hi Clement,
> - On 22 May, 2020, at 20:03, Clément Leger cle...@kalray.eu wrote:>
Hi Suman,
- On 22 May, 2020, at 19:33, Bjorn Andersson bjorn.anders...@linaro.org
wrote:
On Fri 22 May 09:54 PDT 2020, Suman Anna wrote:
On 5/21/20 2:42 PM, Suman Anna wrote:
Hi Bjorn,
On 5
On 5/21/20 2:42 PM, Suman Anna wrote:
Hi Bjorn,
On 5/21/20 1:04 PM, Bjorn Andersson wrote:
On Wed 25 Mar 13:47 PDT 2020, Suman Anna wrote:
Introduce a new trace entry resource structure that accommodates
a 64-bit device address to support 64-bit processors. This is to
be used using
On 5/22/20 11:39 AM, Grygorii Strashko wrote:
vlan_for_each() are required to be called with rtnl_lock taken, otherwise
ASSERT_RTNL() warning will be triggered - which happens now during System
resume from suspend:
cpsw_suspend()
|- cpsw_ndo_stop()
|- __hw_addr_ref_unsync_dev()
Hi Paul,
On 5/15/20 5:43 AM, Paul Cercueil wrote:
Call pm_runtime_get_sync() before the firmware is loaded, and
pm_runtime_put() after the remote processor has been stopped.
Even though the remoteproc device has no PM callbacks, this allows the
parent device's PM callbacks to be properly
On 5/21/20 2:41 PM, Bjorn Andersson wrote:
On Thu 21 May 12:29 PDT 2020, Suman Anna wrote:
On 5/21/20 2:21 PM, Bjorn Andersson wrote:
On Thu 21 May 12:06 PDT 2020, Suman Anna wrote:
Hi Bjorn,
On 5/21/20 12:54 PM, Bjorn Andersson wrote:
On Wed 25 Mar 13:46 PDT 2020, Suman Anna wrote
Hi Bjorn,
On 5/21/20 1:04 PM, Bjorn Andersson wrote:
On Wed 25 Mar 13:47 PDT 2020, Suman Anna wrote:
Introduce a new trace entry resource structure that accommodates
a 64-bit device address to support 64-bit processors. This is to
be used using an overloaded version value of 1 in the upper 32
On 5/21/20 2:21 PM, Bjorn Andersson wrote:
On Thu 21 May 12:06 PDT 2020, Suman Anna wrote:
Hi Bjorn,
On 5/21/20 12:54 PM, Bjorn Andersson wrote:
On Wed 25 Mar 13:46 PDT 2020, Suman Anna wrote:
The current remoteproc core has supported only 32-bit remote
processors and as such some
Hi Bjorn,
On 5/21/20 12:54 PM, Bjorn Andersson wrote:
On Wed 25 Mar 13:46 PDT 2020, Suman Anna wrote:
The current remoteproc core has supported only 32-bit remote
processors and as such some of the current resource structures
may not scale well for 64-bit remote processors, and would
require
Hi Bjorn,
On 5/20/20 7:10 PM, Suman Anna wrote:
Hi All,
The following is v2 of the K3 DSP remoteproc driver supporting the C66x DSPs
on the TI K3 J721E SoCs. The patches are based on the latest commit on the
rproc-next branch, 7dcef3988eed ("remoteproc: Fix an error code in
devm_rproc_
On 3/25/20 3:46 PM, Suman Anna wrote:
Hi All,
This series adds support for a new next generation 64-bit TI DSP based on
the TMS320C71x CorePac processor subsystem called the C71x. The support is
enabled through couple of enhancements to the remoteproc core (primarily to
support a 64-bit trace
as if it is in bypass mode.
Signed-off-by: Suman Anna
---
v2:
- k3_dsp_rproc_prepare/unprepare plugged in dynamically based on local reset,
C71x doesn't use local resets
- Dropped the sanity_check ops override, not needed on latest codebase
v1: https://patchwork.kernel.org/patch/11458595/
drivers
C71 DSP present
on J721E SoCs.
Signed-off-by: Suman Anna
Reviewed-by: Rob Herring
---
v2:
- Rebased patch, no changes to binding properties
- Example additions indented one level to right as part of rebase and
changes done in updated C66x bindings patch
- Added Rob's Reviewed-by
v1: https
://patchwork.kernel.org/cover/11561787/
[2] https://patchwork.kernel.org/cover/11458599/
[3] https://patchwork.kernel.org/patch/11458593/
[4] https://patchwork.kernel.org/patch/11458589/
Suman Anna (2):
dt-bindings: remoteproc: k3-dsp: Update bindings for C71x DSPs
remoteproc/k3-dsp: Add
ext branch. The only dependency for this series is the common
ti-sci-proc helper between R5 and DSP drivers [1]. Please see the initial
cover-letter [2] for v1 details.
regards
Suman
[1] https://patchwork.kernel.org/patch/11456379/
[2] https://patchwork.kernel.org/cover/11458573/
Suman Anna (4):
equivalent code in remoteproc drivers.
Signed-off-by: Suman Anna
---
v2: New patch
drivers/remoteproc/remoteproc_core.c | 23 +++
drivers/remoteproc/remoteproc_internal.h | 2 ++
2 files changed, 25 insertions(+)
diff --git a/drivers/remoteproc/remoteproc_core.c
b/drivers/
RAMs.
Signed-off-by: Suman Anna
---
v2:
- Dropped the local-reset no-op checks from k3_dsp_rproc_prepare/unprepare()
callbacks. The logic will be adjusted back in the C71 patch series.
- The C71 local reset references are also removed from the comments for the
k3_dsp_rproc_prepare() function
tack using shared memory and OMAP Mailboxes.
Signed-off-by: Suman Anna
---
v2:
- Dropped the pm_runtime usage
- Replaced the private k3_dsp_rproc_get_firmware() with the newly introduced
rproc_of_parse_firmware()
- Addressed other minor comments from Mathieu - Revised help on Kconfig,
reord
. The added example illustrates the DT nodes for the first C66x DSP
device present on the K3 J721E family of SoCs.
Signed-off-by: Suman Anna
---
v2:
- Updated the example to include the root-node to fix the bot errors from v1
- Added maxItems to resets, mboxes, memory-region, sram properties
- Changed
Hi Mathieu,
On 4/28/20 3:09 PM, Mathieu Poirier wrote:
On Tue, 28 Apr 2020 at 13:58, Mathieu Poirier
wrote:
On Wed, Mar 25, 2020 at 03:18:39PM -0500, Suman Anna wrote:
The resets for the DSP processors on K3 SoCs are managed through the
Power and Sleep Controller (PSC) module. Each DSP
Hi Mathieu,
On 4/27/20 5:57 PM, Mathieu Poirier wrote:
On Wed, Mar 25, 2020 at 03:18:38PM -0500, Suman Anna wrote:
The Texas Instrument's K3 J721E SoCs have two C66x DSP Subsystems in MAIN
voltage domain that are based on the TI's standard TMS320C66x DSP CorePac
module. Each subsystem has
On 4/27/20 2:49 PM, Mathieu Poirier wrote:
Hi Suman,
I have started to review this set - comments will come over the next few days.
On Wed, Mar 25, 2020 at 03:18:37PM -0500, Suman Anna wrote:
Some Texas Instruments K3 family of SoCs have one of more Digital Signal
Processor (DSP) subsystems
Hi Bjorn,
On 5/2/20 1:29 PM, Suman Anna wrote:
Hi Bjorn,
On 4/20/20 11:05 AM, Suman Anna wrote:
Hi Bjorn,
This is another minor revision of the fixes around fixed memory region
support [1] series. Patch 1 is revised to go back to the logic used in v1
after a long discussion on the v2 version
overwritten. So drop this default setting of parent in prepare().
Signed-off-by: Lokesh Vutla
Reviewed-by: Suman Anna
This works just fine for me but depends on the dts changes.
Daniel, for merging, do you want to set up an immutable branch
for the related dts change and this? I'm afraid
Hi Bjorn,
On 4/20/20 11:05 AM, Suman Anna wrote:
Hi Bjorn,
This is another minor revision of the fixes around fixed memory region
support [1] series. Patch 1 is revised to go back to the logic used in v1
after a long discussion on the v2 version [2]. The other suggestions can
be future
Hi Arnaud,
On 9/4/19 8:09 AM, Arnaud Pouliquen wrote:
> Return the rpmsg buffer size for sending message, so rpmsg users
> can split a long message in several sub rpmsg buffers.
Couple more minor comments..
>
> Signed-off-by: Arnaud Pouliquen
> ---
> drivers/rpmsg/rpmsg_core.c | 21
Hi Arnaud,
On 9/3/19 4:49 AM, Arnaud Pouliquen wrote:
> hi Suman
>
> On 8/29/19 12:34 AM, Suman Anna wrote:
>> Hi Arnaud,
>>
>> On 8/28/19 10:19 AM, Arnaud Pouliquen wrote:
>>> Return the rpmsg buffer size for sending message, so rpmsg users
>>>
Hi Arnaud,
On 8/28/19 10:19 AM, Arnaud Pouliquen wrote:
> Return the rpmsg buffer size for sending message, so rpmsg users
> can split a long message in several sub rpmsg buffers.
Thanks for the patch, I also have a need for the same to be able to
compute permissible payload size. Minor comments
Hi Arnaud,
On 8/27/19 8:58 AM, Arnaud Pouliquen wrote:
> Hi Suman,
>
> On 8/16/19 1:14 AM, Suman Anna wrote:
>> From: Ohad Ben-Cohen
>>
>> Add a new description field to the rpmsg bus infrastructure
>> that can be passed onto the rpmsg client drivers for addit
On 8/27/19 5:15 PM, Suman Anna wrote:
> On 8/27/19 5:07 PM, Bjorn Andersson wrote:
>> On Tue 27 Aug 13:25 PDT 2019, Suman Anna wrote:
>>
>>> Hi Bjorn,
>>>
>>> On 8/27/19 12:10 AM, Bjorn Andersson wrote:
>>>> On Fri 09 Aug 13:25 PDT 2019, Sum
On 8/27/19 5:07 PM, Bjorn Andersson wrote:
> On Tue 27 Aug 13:25 PDT 2019, Suman Anna wrote:
>
>> Hi Bjorn,
>>
>> On 8/27/19 12:10 AM, Bjorn Andersson wrote:
>>> On Fri 09 Aug 13:25 PDT 2019, Suman Anna wrote:
>>>
>>>> Hi Bjorn,
>>>&g
Hi Bjorn,
On 8/27/19 12:10 AM, Bjorn Andersson wrote:
> On Fri 09 Aug 13:25 PDT 2019, Suman Anna wrote:
>
>> Hi Bjorn,
>>
>
> Hi Suman
>
>> On 10/23/18 8:19 PM, Suman Anna wrote:
>>> The virtio_rpmsg_bus driver uses the "%p" format
from Ohad Ben-Cohen.
Signed-off-by: Ohad Ben-Cohen
[s-a...@ti.com: forward port, add sysfs documentation, fixup qcom drivers]
Signed-off-by: Suman Anna
[t-kri...@ti.com: reworked to support both rpmsg with/without the desc field]
Signed-off-by: Tero Kristo
---
v2:
- Localized the desc match check
Hi David,
On 8/13/19 9:26 AM, David Lechner wrote:
> On 8/12/19 2:39 PM, Suman Anna wrote:
>> Hi David,
>>
>> On 8/8/19 12:09 PM, David Lechner wrote:
>>> On 8/2/19 4:26 PM, Suman Anna wrote:
>>>> Point is different applications might use mapping differe
Hi Fabien,
On 8/12/19 8:43 AM, Fabien DESSENNE wrote:
> Hi Suman,
>
> See my remarks below
Thank you for all the review comments.
>
> BR
>
> Fabien
>
>
> On 09/08/2019 11:40 PM, Suman Anna wrote:
>> From: Ohad Ben-Cohen
>>
>> Add a new d
Hi David,
On 8/8/19 12:09 PM, David Lechner wrote:
> On 8/2/19 4:26 PM, Suman Anna wrote:
>> Point is different applications might use mapping differently as per
>> their firmware and driver/application design and their split across one
>> or more PRUs (design by contract
On 8/12/19 11:36 AM, Andrew F. Davis wrote:
> On 8/12/19 12:28 PM, Suman Anna wrote:
>> On 8/12/19 10:47 AM, Andrew F. Davis wrote:
>>> On 10/23/18 9:19 PM, Suman Anna wrote:
>>>> The virtio_rpmsg_bus driver uses the "%p" format-specifier for
>>>
On 8/12/19 10:47 AM, Andrew F. Davis wrote:
> On 10/23/18 9:19 PM, Suman Anna wrote:
>> The virtio_rpmsg_bus driver uses the "%p" format-specifier for
>> printing the vring buffer address. This prints only a hashed
>> pointer even for previliged users. Use "%pK
available in debugfs originally, and is being
retained for now. This can be cleaned up after couple of releases
once users get familiar with the new interface.
Signed-off-by: Suman Anna
---
Documentation/ABI/testing/sysfs-class-remoteproc | 10 ++
drivers/remoteproc/remoteproc_sysfs.c
from Ohad Ben-Cohen.
Signed-off-by: Ohad Ben-Cohen
[s-a...@ti.com: forward port, add sysfs documentation, fixup qcom drivers]
Signed-off-by: Suman Anna
[t-kri...@ti.com: reworked to support both rpmsg with/without the desc field]
Signed-off-by: Tero Kristo
---
Documentation/ABI/testing/sysfs-bus
Hi Bjorn,
On 10/23/18 8:19 PM, Suman Anna wrote:
> The virtio_rpmsg_bus driver uses the "%p" format-specifier for
> printing the vring buffer address. This prints only a hashed
> pointer even for previliged users. Use "%pK" instead so that
> the address c
Replace the raw print_hex_dump() call in the rpmsg_sample_cb() function
with the equivalent print_hex_dump_debug() better suited for dynamic
debug. This switch allows flexibility of controlling this trace through
dynamic debug when enabled.
Signed-off-by: Suman Anna
---
samples/rpmsg
Hi Bjorn,
The following are minor cleanup/improvement patches to the rpmsg_client_sample.
The first patch is new, and the second patch is a repost. Appreciate it if you
can pick these up for 5.4 merge window.
regards
Suman
Suman Anna (2):
samples/rpmsg: Replace print_hex_dump
The current rpmsg_client_sample uses a fixed number of messages to
be sent to each instance. This is currently set at 100. Introduce
an optional module parameter 'count' so that the number of messages
to be exchanged can be made flexible.
Signed-off-by: Suman Anna
---
samples/rpmsg
On 8/7/19 12:39 AM, Bjorn Andersson wrote:
> Introduce a "panic" function in the remoteproc ops table, to allow
> remoteproc instances to perform operations needed in order to aid in
> post mortem system debugging, such as flushing caches etc, when the
> kernel panics.
>
> Signed-off-by: Bjorn
On 8/7/19 12:39 AM, Bjorn Andersson wrote:
> A region in IMEM is used to communicate load addresses of remoteproc to
> post mortem debug tools. Implement a driver that can be used to store
> this information in order to enable these tools to process collected
> ramdumps.
>
> Signed-off-by: Bjorn
Hi Loic,
On 8/7/19 4:41 AM, Loic Pallardy wrote:
> Post [1] and checkpatch tool indicate that usage of bool type
> in structure is now no more allowed/advised.
> This patch replaces bool by unsigned char (u8) and reorders
> struct rproc fields to avoid padding.
>
> [1]
Hi David,
On 8/1/19 1:31 PM, David Lechner wrote:
> On 8/1/19 12:10 PM, Suman Anna wrote:
>> Hi Marc,
>>
>> On 8/1/19 3:45 AM, Marc Zyngier wrote:
>>> On 31/07/2019 23:41, Suman Anna wrote:
>>>> The PRUSS INTC receives a number of system input interrupt
Hi Marc,
On 8/1/19 3:45 AM, Marc Zyngier wrote:
> On 31/07/2019 23:41, Suman Anna wrote:
>> The PRUSS INTC receives a number of system input interrupt source events
>> and supports individual control configuration and hardware prioritization.
>> These input events can be
Hi Marc,
On 8/1/19 4:42 AM, Marc Zyngier wrote:
> On 31/07/2019 23:41, Suman Anna wrote:
>> From: "Andrew F. Davis"
>>
>> The Programmable Real-Time Unit Subsystem (PRUSS) contains a local
>> interrupt controller (INTC) that can handle various system inp
);
Signed-off-by: David Lechner
Signed-off-by: Suman Anna
---
v2: New patch from David replacing an exported API from v1,
https://patchwork.kernel.org/patch/11034565/
drivers/irqchip/irq-pruss-intc.c | 41 ++--
1 file changed, 39 insertions(+), 2 deletions(-)
ared between MPU and
a DMA controller.
Add support to the PRUSS INTC driver to allow both these shared and
invalid interrupts by not returning a failure if any of these interrupts
are skipped from the corresponding INTC DT node.
Signed-off-by: Suman Anna
---
v2:
- Fixed a typo in error message t
: Andrew F. Davis
Signed-off-by: Suman Anna
Signed-off-by: Roger Quadros
---
v2:
- Addressed all of David Lechner's comments
- Dropped irq_retrigger callback
- Updated interrupt names from "hostX" to "host_intrX"
- Moved host_mask variable to patch 4
v1: https://patchwork
the
applicable SoCs. It covers the OMAP architecture SoCs - AM33xx, AM437x
and AM57xx; the Keystone 2 architecture based 66AK2G SoC; the Davinci
architecture based OMAPL138 SoCs, and the K3 architecture based AM65x
and J721E SoCs.
Signed-off-by: Suman Anna
Signed-off-by: Andrew F. Davis
Signed-off
to use the
higher events and channels on all SoCs, while limiting the actual
processing to only the relevant number of events/channels/interrupts.
Signed-off-by: Suman Anna
---
v2:
- Rebased patch with indexed macros like ESRx, ECRx where x = 0,1 dropped
v1: https://patchwork.kernel.org/patch
: pruss_intc_configure() & pruss_intc_unconfigure()
that the PRU remoteproc driver can use to configure the PRUSS INTC.
Signed-off-by: Suman Anna
Signed-off-by: Andrew F. Davis
Signed-off-by: Roger Quadros
---
v2:
- Added new internal helper functions pruss_intc_update_cmr/hmr for
programming
/spruhz6
Andrew F. Davis (1):
irqchip/irq-pruss-intc: Add a PRUSS irqchip driver for PRUSS
interrupts
David Lechner (1):
irqchip/irq-pruss-intc: Implement irq_{get,set}_irqchip_state ops
Suman Anna (4):
dt-bindings: irqchip: Add PRUSS interrupt controller bindings
irqchip/irq-pruss-intc: Add
On 7/24/19 11:34 AM, Rob Herring wrote:
> On Sun, 7 Jul 2019 22:52:38 -0500, Suman Anna wrote:
>> The Programmable Real-Time Unit Subsystem (PRUSS) contains an interrupt
>> controller (INTC) that can handle various system input events and post
>> interrupts back to the de
On 7/24/19 1:31 AM, Tony Lindgren wrote:
> * Keerthy [190724 05:50]:
>>
>> On 24/07/19 12:33 AM, Suman Anna wrote:
>>> + Jyri
>>>
>>> On 7/23/19 6:28 AM, Tony Lindgren wrote:
>>>> We currently get a warning for lcdc because of a di
for ti,no-idle-on-init
> dts flag should be at module level for ti,no-reset-on-init
>
> Signed-off-by: Tony Lindgren
There's a similar one within the am335x-icev2.dts file for gpio0
that can also use this fix.
Reviewed-by: Suman Anna
regards
Suman
> ---
> arch/arm/boot/dts/am5
Hi Tony,
On 7/23/19 6:28 AM, Tony Lindgren wrote:
> The ahclkr clkctrl clock bit 28 only exists for mcasp 1 and 2 on dra7.
> Otherwise we get the following warning on beagle-x15:
>
> ti-sysc 48468000.target-module: could not add child clock ahclkr: -19
>
> Fixes: 5241ccbf2819 ("ARM: dts: Add
+ Jyri
On 7/23/19 6:28 AM, Tony Lindgren wrote:
> We currently get a warning for lcdc because of a difference
> with dts provided configuration compared to the legacy platform
> data. This is because lcdc has SYSC_HAS_MIDLEMODE configured in
> the platform data without configuring the modes.
Hi
> Fixes: d59b60564cbf ("bus: ti-sysc: Add generic enable/disable functions")
> Cc: Roger Quadros
> Signed-off-by: Tony Lindgren
Reviewed-by: Suman Anna
regards
Suman
> ---
> drivers/bus/ti-sysc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> dif
just dropped, but let's fix the
> warning first.
>
> Signed-off-by: Tony Lindgren
Reviewed-by: Suman Anna
regards
Suman
> ---
> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/omap
On 7/17/19 12:57 PM, David Lechner wrote:
> On 7/16/19 6:29 PM, Suman Anna wrote:
>> Hi David,
>>
>> On 7/10/19 10:10 PM, David Lechner wrote:
>>> On 7/7/19 10:52 PM, Suman Anna wrote:
>>>> The PRUSS INTC receives a number of system input interrupt sourc
On 7/17/19 12:21 PM, David Lechner wrote:
> On 7/16/19 12:21 PM, Suman Anna wrote:
>>>> +static int pruss_intc_probe(struct platform_device *pdev)
>>>> +{
>>>> + static const char * const irq_names[] = {
>>>> + "host0&q
Hi David,
On 7/10/19 10:10 PM, David Lechner wrote:
> On 7/7/19 10:52 PM, Suman Anna wrote:
>> The PRUSS INTC receives a number of system input interrupt source events
>> and supports individual control configuration and hardware
>> prioritization.
>> These input e
Hi David,
On 7/11/19 11:45 AM, David Lechner wrote:
> On 7/7/19 10:52 PM, Suman Anna wrote:
>> From: "Andrew F. Davis"
>>
>> The Programmable Real-Time Unit Subsystem (PRUSS) contains a local
>> interrupt controller (INTC) that can handle various system inp
Hi David,
On 7/10/19 12:08 PM, David Lechner wrote:
>
+- interrupts : all the interrupts generated towards the
main host
+ processor in the SoC. The format depends
on the
+ interrupt specifier for the particular
Hi Andrew,
On 7/8/19 9:34 AM, Andrew F. Davis wrote:
> On 7/7/19 11:52 PM, Suman Anna wrote:
>> The Programmable Real-Time Unit Subsystem (PRUSS) contains an interrupt
>> controller (INTC) that can handle various system input events and post
>> interrupts back to the de
ller.
Add support to the PRUSS INTC driver to allow both these shared and
invalid interrupts by not returning a failure if any of these interrupts
are skipped from the corresponding INTC DT node.
Signed-off-by: Suman Anna
---
drivers/irqchip/irq-pruss-intc.c | 44 +++
SoCs. It covers the OMAP architecture SoCs - AM33xx, AM437x
and AM57xx; the Keystone 2 architecture based 66AK2G SoC; the Davinci
architecture based OMAPL138 SoCs, and the K3 architecture based AM65x
and J721E SoCs.
Signed-off-by: Suman Anna
Signed-off-by: Andrew F. Davis
Signed-off-by: Roger
registers when stopping a PRU.
Add two helper functions: pruss_intc_configure() & pruss_intc_unconfigure()
that the PRU remoteproc driver can use to configure the PRUSS INTC.
Signed-off-by: Suman Anna
Signed-off-by: Andrew F. Davis
Signed-off-by: Roger Quadros
---
drivers/irqchip/irq-p
U or other processors. A new API, pruss_intc_trigger() is
provided to MPU-side PRU client drivers/applications to be able
to trigger an event/interrupt using IRQ numbers provided by the
PRUSS-INTC irqdomain chip.
Signed-off-by: Andrew F. Davis
Signed-off-by: Suman Anna
Signed-off-by: Roger Quadros
--
: Andrew F. Davis
Signed-off-by: Suman Anna
Signed-off-by: Roger Quadros
---
Prior version: https://patchwork.kernel.org/patch/10795761/
drivers/irqchip/Kconfig | 10 +
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-pruss-intc.c | 352 +++
3 fil
http://www.ti.com/lit/pdf/spruhz6
Andrew F. Davis (2):
irqchip/irq-pruss-intc: Add a PRUSS irqchip driver for PRUSS
interrupts
irqchip/irq-pruss-intc: Add API to trigger a PRU sysevent
Suman Anna (4):
dt-bindings: irqchip: Add PRUSS interrupt controller bindings
irqchip/irq-pruss-intc:
to use the
higher events and channels on all SoCs, while limiting the actual
processing to only the relevant number of events/channels/interrupts.
Signed-off-by: Suman Anna
---
drivers/irqchip/Kconfig| 2 +-
drivers/irqchip/irq-pruss-intc.c | 172
On 6/27/19 7:11 AM, Tony Lindgren wrote:
> Hi,
>
> * Suman Anna [190625 23:33]:
>> The clocks are not yet parsed and prepared until after a successful
>> sysc_get_clocks(), so there is no need to unprepare the clocks upon
>> any failure of any of the prior functions i
A few fields in various structures is missing the corresponding
kerneldoc comments. Add them. Also, fixed the comment for sidlemodes.
Signed-off-by: Suman Anna
---
drivers/bus/ti-sysc.c | 7 +++
include/linux/platform_data/ti-sysc.h | 5 +++--
2 files changed, 10 insertions
Add the ti-sysc source files under the OMAP2+ entry so that
the get_maintainer script also generates the linux-omap
list to be cc'd for all patches touching these files.
Signed-off-by: Suman Anna
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
is a minor
fixup cleaning up the code flow on failure error paths in sysc_probe()
function. I have boot tested on the limited boards that I have - AM335x
BeagleBone Black, AM437x IDK, AM57xx GP EVM, OMAP4 PandaBoard and OMAP5
uEVM.
regards
Suman
Suman Anna (5):
MAINTAINERS: Add ti-sysc files
sysc_unprepare(), but let's just simplify the cleanup path by
returning the error directly.
While at this, also fix the cleanup path for a sysc_init_resets()
failure which is executed after the clocks are prepared.
Signed-off-by: Suman Anna
---
drivers/bus/ti-sysc.c | 14 +++---
1 file changed, 7
Add the appropriate SPDX license identifier to the common
TI sysc bindings header file.
Signed-off-by: Suman Anna
---
include/dt-bindings/bus/ti-sysc.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/dt-bindings/bus/ti-sysc.h
b/include/dt-bindings/bus/ti-sysc.h
index 7138384e2ef9
Use the appropriate SPDX license identifier in the TI sysc
interconnect target driver source files and drop the previous
boilerplate license text. Also, add the the SPDX license
identifier in the associated ti-sysc header files.
Signed-off-by: Suman Anna
---
drivers/bus/ti-sysc.c
Hi Jassi,
On 6/4/19 12:01 PM, Suman Anna wrote:
> Hi Jassi,
>
> The following series adds the support for the Mailbox IP present
> within the Main NavSS module on the newer TI K3 AM65x and J721E SoCs.
>
> The Mailbox IP is similar to the previous generation IP on OMAP
to fix this.
>
> Reported-by: Hulk Robot
> Signed-off-by: YueHaibing
Acked-by: Suman Anna
Hi Santosh,
Can you pick up this patch, goes on top of your for_5.3/driver-soc branch?
regards
Suman
> ---
> v3: fix patch title
> v2: use the 'dev' variable as Suman Anna's suggestion
On 6/14/19 10:44 AM, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/firmware/ti_sci.c: In function ti_sci_cmd_ring_config:
> drivers/firmware/ti_sci.c:2035:17: warning: variable dev set but not used
> [-Wunused-but-set-variable]
> drivers/firmware/ti_sci.c: In
or folded into this patch.
include/linux/platform_data/iommu-omap.h
Acked-by: Suman Anna
regards
Suman
> ---
> drivers/iommu/omap-iommu-debug.c | 5 +
> drivers/iommu/omap-iommu.c | 5 +
> drivers/iommu/omap-iommu.h | 5 +
> drivers/iommu/omap-iopgtable.h | 5 +--
201 - 300 of 1689 matches
Mail list logo
