maintainers who never respond in a long time.
>
> [1]:
> https://lore.kernel.org/r/CAK=Wgbbcyi36ef1-PV8VS=m6nfoqnfgudwy6v7ocnkt0ddr...@mail.gmail.com/
>
> Signed-off-by: Bagas Sanjaya
> ---
Acked-by: Ohad Ben Cohen
Hi Bagas,
On Sat, Dec 16, 2023 at 1:10 PM Bagas Sanjaya wrote:
> --- a/CREDITS
> +++ b/CREDITS
> @@ -323,6 +323,7 @@ N: Ohad Ben Cohen
> E: o...@wizery.com
> D: Remote Processor (remoteproc) subsystem
> D: Remote Processor Messaging (rpmsg) subsystem
> +D: Hardware
Hi Stephen,
On Wed, Nov 23, 2016 at 6:41 AM, Stephen Rothwell wrote:
> Should I remove it from linux-next?
Yes, please.
Thanks,
Ohad.
> So I don't have any issue with this, but I _do_ want to get acks from
> the person I used to pull from before I switch to pulling from another
> person.
>
> Ohad?
Acked-by: Ohad Ben-Cohen
Thanks,
Ohad.
Hi Stephen,
On Wed, Mar 9, 2016 at 7:28 AM, Stephen Rothwell wrote:
> Hi Ohad,
>
> I noticed that the rpmsg tree
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git branch for-next
>
> has not been updated since November 2014. I am going to remove it from
> linux-next tomorrow unl
On Sun, Feb 14, 2016 at 3:35 AM, Bjorn Andersson
wrote:
>
> Add myself as co-maintainer for the remote processor related subsystems,
> as agreed with Ohad.
>
> Signed-off-by: Bjorn Andersson
Thank you Bjorn for the help!
Acked-by: Ohad Ben-Cohen
> ---
> MAINTAINERS | 3
Hi everyone,
Due to lack of time in the next few months, I've asked Bjorn Andersson for
help with the remoteproc/rpmsg/hwspinlock maintainership.
Bjorn has kindly agreed to step up and co-maintain
remoteproc/rpmsg/hwspinlock with me, and we expect that Bjorn will start
picking up patches as soon
On Mon, Dec 28, 2015 at 8:41 PM, Bjorn Andersson wrote:
> I interpreted this as you picked patch 1-4 and didn't pay more
> attention to them, but I can't find them in your kernel.org trees. So
> I've looked through them again.
>
> Please apply patch 1, 3 and 4 to your tree Ohad. I was unable to fi
On Mon, Dec 7, 2015 at 5:03 PM, zhaoxiu.zeng wrote:
> is_power_of_2 is simple, and faster than "hweightN(x) == 1" on most
> architectures.
Thanks. I'm not sure that speed is a major concern here, since this
code executes only once during the lifetime of the driver. Readability
is probably more i
Hi,
On Sun, Dec 6, 2015 at 12:33 PM, Zhaoxiu Zeng wrote:
>
> From: Zeng Zhaoxiu
>
> Signed-off-by: Zeng Zhaoxiu
Please explain why do you think we should make this change.
Btw, the original code used is_power_of_2, but we thought hweight is
more explicit so it was adopted.
Thanks,
Ohad.
--
T
The following changes since commit 1ec218373b8ebda821aec00bb156a9c94fad9cd4:
Linux 4.4-rc2 (2015-11-22 16:45:59 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
tags/remoteproc-4.4-fixes
for you to fetch changes up to f42f79af1
On Thu, Nov 26, 2015 at 12:37 PM, Michael S. Tsirkin wrote:
> On Thu, Nov 26, 2015 at 11:38:06AM +0200, Ohad Ben-Cohen wrote:
>> I saw there was some discussion about this between Michael, James and
>> Tejun whether this should be fixed in the IDA core or not.
>>
>>
On Wed, Sep 16, 2015 at 3:32 PM, Dave Gerlach wrote:
> Use MODULE_DEVICE_TABLE with wkup_m3_rproc_of_match so the module alias
> is exported and the wkup_m3_rproc driver can automatically probe.
>
> Signed-off-by: Dave Gerlach
Applied to remoteproc-next, thanks.
--
To unsubscribe from this list:
Hi Suman,
On Thu, Sep 17, 2015 at 3:29 AM, Suman Anna wrote:
> The remoteproc core uses a static ida named rproc_dev_index for
> assigning an automatic index number to a registered remoteproc.
> The ida core may allocate some internal idr cache layers and ida
> bitmap upon any ida allocation, and
On Thu, Nov 26, 2015 at 11:10 AM, Lee Jones wrote:
> On Thu, 26 Nov 2015, Ohad Ben-Cohen wrote:
>> On Tue, Nov 24, 2015 at 3:14 PM, Lee Jones wrote:
>> > ST's platforms often have multiple co-processors (usually ST40s or ST231s)
>> > on-board. This provides
Hi Stefan,
On Sat, Aug 29, 2015 at 4:08 AM, Stefan Agner wrote:
> Currently, if the resource table is completely missing in the
> firmware, powering up the remoteproc fails silently. Add a message
> indicating that the resource table is missing in the firmware.
>
> Signed-off-by: Stefan Agner
A
Hi Lee,
On Tue, Nov 24, 2015 at 3:14 PM, Lee Jones wrote:
> ST's platforms often have multiple co-processors (usually ST40s or ST231s)
> on-board. This provides the Linux-side infrastructure to flash and boot
> them successfully.
>
> This set has been tested on an STiH410-B2120.
It would be nic
On Fri, Nov 20, 2015 at 7:26 PM, Arnd Bergmann wrote:
> Recent gcc versions warn about reading from a negative offset of
> an on-stack array:
>
> drivers/remoteproc/remoteproc_debugfs.c: In function 'rproc_recovery_write':
> drivers/remoteproc/remoteproc_debugfs.c:167:9: warning: 'buf[4294967295u]
On Fri, Aug 14, 2015 at 6:24 PM, Lina Iyer wrote:
> Would you rather query the hwspinlock driver to see if the framework
> should take a s/w spinlock or not, IOW, raw-accessible or not?
Sorry, I'm afraid I rather not. This seems to make things even more
complicated without introducing any technic
On Thu, Aug 13, 2015 at 6:25 PM, Andy Gross wrote:
> The issue in hardwiring this into the driver itself means forfeiting
> extensibility. So on one side (w/ raw support), we get the ability to deal
> with
> the lock number changing. On the other side (w/o raw), we'd have to probably
> tie this
On Wed, Jul 29, 2015 at 12:51 AM, Lina Iyer wrote:
>> Let's not make this more complicated than needed, so please add the
>> hwcaps member to hwspinlock_device instead of to hwspinlock struct. We
>> could always change this later if it proves to be insufficient.
>>
> But this could yield wrong loc
Hi Lina,
On Thu, Jul 2, 2015 at 11:30 PM, Lina Iyer wrote:
> You are right, RAW capability is not lock specific. But we dont want to
> impose this on every lock in the bank either.
I'm not sure I'm following your concern here: drivers still need to
explicitly indicate RAW in order for this to ki
essor
remoteproc/wkup_m3: add a remoteproc driver for TI Wakeup M3
Ohad Ben-Cohen (1):
remoteproc: fix !CONFIG_OF build breakage
Suman Anna (4):
remoteproc/ste: add blank lines after declarations
remoteproc/davinci: fix quoted split string checkpatch warning
remoteproc: fix va
The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:
Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git
tags/hwspinlock-4.2
for you to fetch changes up to bd5717a4632cdec
Hi Lina,
On Sat, Jun 27, 2015 at 6:05 AM, Lina Iyer wrote:
> Hi Ohad,
>
> Any comments?
Sorry, I was under the impression the discussion with Bjorn is still open.
Like Bjorn, I'm not so sure too we want to bind a specific lock to the
RAW capability since this is not a lock-specific hardware det
On Thu, Jun 18, 2015 at 7:01 PM, Dave Gerlach wrote:
> Oh sorry about. Pulled your for-next, tried it out, everything looks good to
> me,
> thanks!
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majord
Hi Dave,
On Wed, Jun 17, 2015 at 9:46 PM, Dave Gerlach wrote:
> Allow users of remoteproc the ability to get a handle to an rproc by
> passing a phandle supplied in the user's device tree node. This is
> useful in situations that require manual booting of the rproc.
>
> This patch uses the code r
On Fri, May 22, 2015 at 11:45 PM, Dave Gerlach wrote:
> Hi,
> This patch series is v4 of the series to add a wkup_m3_rproc driver
> for TI AM335xi and AM437x SoCs. This family of SoCs contains an ARM
> Cortex M3 coprocessor that is responsible for low-level power tasks
> that cannot be handled by
On Sat, Jun 6, 2015 at 2:50 AM, Jeffrey Hugo wrote:
> If you still wish to scope out a capability based alternative, would you
> please provide some details about how you envision it working? An example
> of the API, how it would be used, future usecases that might be covered by
> it, etc. That
On Tue, May 26, 2015 at 11:36 PM, Lina Iyer wrote:
>> Just to make sure I understand, is this how your scenario is solved?
>>
>> - c1 goes down
>> - c0 goes down, carries information about shared resources
>> - c1 takes HWLOCK and calls into SCM, stuck handling FIQs
>> - c0 wants to call into SCM
Hi Lina,
On Mon, May 18, 2015 at 6:03 PM, Lina Iyer wrote:
> The lock in question is used differently than traditional locks across
> processors. This lock helps synchronizes context transition from
> non-secure to secure on the same processor.
>
> The usecase, goes like this. In cpuidle, any cor
On Mon, May 11, 2015 at 5:46 PM, Lina Iyer wrote:
> On Sat, May 09 2015 at 03:25 -0600, Ohad Ben-Cohen wrote:
>> On Fri, May 1, 2015 at 8:07 PM, Lina Iyer wrote:
>> Let's discuss whether we really want to expose this functionality
>> under the same hwspinlock API or n
Hi Suman,
On Mon, May 11, 2015 at 6:01 PM, Suman Anna wrote:
> We don't have any carveouts or usage of any external DDR, as this
> processor is used during Power Management, like cpuidle or suspend path,
> and is used to control the MPU and DDR states. The resource table is
> very simple and stra
Hi Suman,
On Mon, May 11, 2015 at 6:09 PM, Suman Anna wrote:
> On 05/09/2015 02:39 AM, Ohad Ben-Cohen wrote:
> > On Wed, Apr 1, 2015 at 10:37 PM, Dave Gerlach wrote:
> >> This patch uses the code removed by commit 40e575b1d0b3 ("remoteproc:
> >> remove the g
Hi Lina,
On Fri, May 1, 2015 at 8:07 PM, Lina Iyer wrote:
> Some uses of the hwspinlock could be that one entity acquires the lock
> and the other entity releases the lock. This allows for a serialized
> traversal path from the locking entity to the other.
>
> For example, the cpuidle entry from
Hi Dave,
On Wed, Apr 1, 2015 at 10:37 PM, Dave Gerlach wrote:
> Add a remoteproc driver to load the firmware and boot a small
> Wakeup M3 processor present on TI AM33xx and AM43xx SoCs. This
> Wakeup M3 remote processor is an integrated Cortex M3 that allows
> the SoC to enter the lowest possible
Hi Dave,
On Wed, Apr 1, 2015 at 10:37 PM, Dave Gerlach wrote:
> From: Suman Anna
>
> The rproc_da_to_va API is currently used to perform any device to
> kernel address translations to meet the different needs of the remoteproc
> core/drivers (eg: loading). The functionality is achieved within th
Hi Dave,
On Wed, Apr 1, 2015 at 10:37 PM, Dave Gerlach wrote:
> Allow users of remoteproc the ability to get a handle to an rproc by
> passing a phandle supplied in the user's device tree node. This is
> useful in situations that require manual booting of the rproc.
>
> This patch uses the code r
Hi Suman,
On Wed, Apr 29, 2015 at 7:05 PM, Suman Anna wrote:
> Ping, do you have any comments on this series?
I'll get to review this next week.
Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More ma
On Sat, Feb 28, 2015 at 1:18 AM, Suman Anna wrote:
> Suman Anna (3):
> remoteproc/ste: add blank lines after declarations
> remoteproc/davinci: fix quoted split string checkpatch warning
> remoteproc: fix various checkpatch warnings
Applied, thanks!
--
To unsubscribe from this list: send th
On Tue, Mar 24, 2015 at 7:11 PM, Bjorn Andersson
wrote:
> Add binding documentation for the Qualcomm Hardware Mutex.
>
> Reviewed-by: Andy Gross
> Reviewed-by: Jeffrey Hugo
> Signed-off-by: Bjorn Andersson
> ---
Both patches have been applied, thanks!
--
To unsubscribe from this list: send the
On Thu, Apr 16, 2015 at 1:28 PM, Ohad Ben-Cohen wrote:
> On Thu, Apr 16, 2015 at 12:31 PM, Mark Rutland wrote:
> > Hi,
> >
> > Apologies for the delay on this.
> >
> >> > Gentle reminder. Can you please provide your ack on the bindings in this
> >&g
The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539:
Linux 4.0-rc1 (2015-02-22 18:21:14 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
tags/remoteproc-4.1-next
for you to fetch changes up to 315491e5d6
On Thu, Apr 16, 2015 at 12:31 PM, Mark Rutland wrote:
> Hi,
>
> Apologies for the delay on this.
>
>> > Gentle reminder. Can you please provide your ack on the bindings in this
>> > series (Patches 1 & 3) for Ohad to queue up the series for 4.1.
>> >
>>
>> Ping again, if you can provide your ack o
On Tue, Apr 14, 2015 at 10:18 PM, Kumar Gala wrote:
>> On Feb 27, 2015, at 4:30 PM, Bjorn Andersson
>> wrote:
>>
>> Add binding documentation for the Qualcomm Hardware Mutex.
>>
>> Signed-off-by: Bjorn Andersson
>> —
>>
>
> Acked-by: Kumar Gala
Perfect, thanks a lot, Kumar.
--
To unsubscribe
On Mon, Apr 6, 2015 at 10:04 PM, Ohad Ben-Cohen wrote:
> Mark, are you OK with the latest iteration from Suman? it would be
> nice to get your +1 just to make sure we don't merge stuff you're
> uncomfortable with.
Quick update:
As Tim pointed out, we can move forward with
On Mon, Apr 6, 2015 at 7:48 PM, Bjorn Andersson wrote:
> Based on the long discussion we had on one of the previous iterations
> of Suman's DT binding, with the DT maintainers I believe that it would
> be fine to move along and sent Suman's patches to Linus - without an
> explicit Ack from the DT
On Mon, Apr 6, 2015 at 7:22 PM, Tim Bird wrote:
> On Fri, Apr 3, 2015 at 6:55 AM, Ohad Ben-Cohen wrote:
>> On Thu, Apr 2, 2015 at 9:11 PM, Tim Bird wrote:
>>> On Wed, Apr 1, 2015 at 9:40 PM, Ohad Ben-Cohen wrote:
>>>> Sorry, I can't take this without a DT ac
On Thu, Apr 2, 2015 at 9:11 PM, Tim Bird wrote:
> On Wed, Apr 1, 2015 at 9:40 PM, Ohad Ben-Cohen wrote:
>> Sorry, I can't take this without a DT ack.
>
> Hmmm.
>
> The policy seems to be:
> "For driver (not subsystem) bindings: If you are comfortable with
On Thu, Apr 2, 2015 at 12:32 AM, Tim Bird wrote:
> I didn't see an Ack from Mark or Rob. But I did see a question from
> Mark and response from Bjorn.
>
> Ohad - did you take this or are you still waiting for something?
>
> Who should I pester about this? :-)
Sorry, I can't take this without a D
Hi Mark, Rob,
On Sat, Feb 28, 2015 at 12:30 AM, Bjorn Andersson
wrote:
> Add binding documentation for the Qualcomm Hardware Mutex.
>
> Signed-off-by: Bjorn Andersson
> ---
>
> I think the conclusion on the dt binding discussion for hwspinlocks was that
> we're down to having the #hwlock-cells i
Hi Suman,
On Thu, Mar 5, 2015 at 4:01 AM, Suman Anna wrote:
> This is the latest version of the hwspinlock dt support series,
> rebased onto v4.0-rc1 and addressing the long discussion on the
> bindings in v7 [1]. I really hope that this series can make it
> into 4.1.
>From a quick glance this l
On Fri, Jan 9, 2015 at 11:21 PM, Suman Anna wrote:
> The remoteproc driver core currently relies on iommu_present() on
> the bus the device is on, to perform MMU management. However, this
> logic doesn't scale for multi-arch, especially for processors that
> do not have an IOMMU. Replace this logi
On Thu, Mar 12, 2015 at 12:15 AM, Andy Gross wrote:
> On Wed, Mar 11, 2015 at 01:42:38PM -0700, Tim Bird wrote:
>
>
>
>> I'm pretty anxious about this one, as my current work has a dependency on it.
>> Virtually the entirety of the QualComm SOC work is dependent on this
>> because it's needed by
ith adding buffers.
>>
>> Instead, split kick out to prepare+notify calls. prepare before
>> virtio_device_ready - when we know we won't get interrupts. notify right
>> afterwards.
>>
>> Signed-off-by: Michael S. Tsirkin
>> ---
>
> Ohad, ca
On Thu, Feb 12, 2015 at 10:54 PM, Suman Anna wrote:
> My original motivation was that it would only need to be added on
> firmwares requiring support for loading into internal memories,
> otherwise, these are something left to be managed by the software
> running on the remote processor completely
On Wed, Feb 11, 2015 at 10:57 PM, Tony Lindgren wrote:
>> > +static int rproc_handle_intmem(struct rproc *rproc, struct fw_rsc_intmem
>> > *rsc,
>> > + int offset, int avail)
>> > +{
>> ...
>> > + va = (__force void *)ioremap_nocache(rsc->pa, rsc->len);
>>
>> Ba
On Fri, Feb 6, 2015 at 2:34 AM, Bjorn Andersson wrote:
>> Yep, will do as soon as I hear from Ohad on what to do with the patch
>> "hwspinlock/core: maintain a list of registered hwspinlock banks" that I
>> dropped from v7. Without that and dropping hwlock-base-id, I can't get
>> the translations
Hi Suman,
On Fri, Jan 9, 2015 at 11:21 PM, Suman Anna wrote:
> A remote processor may need to load certain firmware sections into
> internal memories (eg: RAM at L1 or L2 levels) for performance or
> other reasons. Introduce a new resource type (RSC_INTMEM) and add
> an associated handler functio
Hi Suman,
On Tue, Feb 3, 2015 at 10:55 PM, Suman Anna wrote:
> > On 01/09/2015 03:21 PM, Suman Anna wrote:
> >> Hi Ohad,
> >>
> >> The following is an updated patchset addressing the previous pending
> >> comments
> >> from v1 & v2, and are rebased onto the latest 3.19-rc3 (are rc independent
>
On Sat, Jan 31, 2015 at 7:41 AM, Ohad Ben-Cohen wrote:
> On Sat, Jan 31, 2015 at 1:29 AM, Bjorn Andersson wrote:
> > In a system where you have two hwlock blocks lckA and lckB, each
> > consisting of 8 locks and you have dspB that can only access lckB
>
> This is a good ex
On Sat, Jan 31, 2015 at 1:29 AM, Bjorn Andersson wrote:
> In a system where you have two hwlock blocks lckA and lckB, each
> consisting of 8 locks and you have dspB that can only access lckB
This is a good example - thanks. To be able to cope with such cases we
will have to pass a hwlock block re
On Tue, Jan 20, 2015 at 8:05 PM, Tony Lindgren wrote:
> How about default to Linux id space and allow overriding that with
> a module param option if needed?
I'm not sure I'm following.
If the main point of contention is the base_id field, I'm also fine
with removing it entirely, as I'm not awar
Mark,
On Fri, Jan 16, 2015 at 12:17 PM, Mark Rutland wrote:
>> The hwlock is a basic hardware primitive that allow synchronization
>> between different processors in the system, which may be running Linux
>> as well as other operating systems, and may have no other means of
>> communication.
>>
>
On Thu, Jan 15, 2015 at 4:42 PM, Rob Herring wrote:
> On Thu, Jan 15, 2015 at 7:55 AM, Mark Rutland wrote:
>> On Thu, Jan 15, 2015 at 01:52:01PM +, Mark Rutland wrote:
>>> On Wed, Jan 14, 2015 at 08:58:18PM +, Suman Anna wrote:
>>> > +- hwlock-base-id: An unique base Id for the locks for
Hi Suman,
On Wed, Jan 14, 2015 at 10:58 PM, Suman Anna wrote:
> This is an updated version of the hwspinlock dt support series,
> rebased onto v3.19-rc3 and mainly addresses the continued discussion
> on the need to maintain a list of registered spinlock banks [1].
> I have removed this patch as
[Resending in plain text mode - sorry]
The following changes since commit 5d01410fe4d92081f349b013a2e7a95429e4f2c9:
Linux 3.18-rc6 (2014-11-23 15:25:20 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git
tags/rpmsg-3.19-next
for you t
On Thu, Nov 27, 2014 at 12:30 AM, Suman Anna wrote:
> Yep, I have reviewed and verified the changes, it is good to go.
Applied, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://v
onsidering the vring size, keep using the 512 hard coded
value as an upper limit to avoid wacky resource tables consuming
unreasonable amount of memory.
NOTE: The number of buffers is already assumed to be symmetrical
in each direction, and that logic is unchanged.
Signed-off-by: Suman Anna
Hi Bjorn,
On Thu, Nov 20, 2014 at 2:43 AM, Bjorn Andersson wrote:
> I still have a huge problem understanding the awesomeness with the
> "base_id". If you have a SoC with 2 hwlock blocks; say 8+8 locks, used
> for interaction with e.g. a modem and a video core respectively.
> Why would you in eit
On Fri, Nov 14, 2014 at 7:09 PM, Suman Anna wrote:
>> It seems to me that hwspin_lock_request_specific failures should be
>> used by clients to defer their probing. Why wouldn't such a simple
>> solution work?
> Because the API always returns NULL on failures and there is no way for
> the clients
Hi Suman,
On Thu, Nov 13, 2014 at 11:02 PM, Suman Anna wrote:
> OK, lets take an example. I have say 2 device instances, say
> hwlock1: hwlock@0 {
> hwlock-num-locks = <32>
> hwlock-base-id = <0>;
> #hwlock-cells = <1>;
> };
>
Hi Suman,
On Thu, Nov 13, 2014 at 7:38 PM, Suman Anna wrote:
> No, not always, because, either of them can be optional between
> different platform implementations. For example, on OMAP, the number of
> locks is read from an IP register, and not coded in DT. Similarly,
> base_id can be optional o
Hi Suman,
On Wed, Nov 12, 2014 at 9:32 PM, Suman Anna wrote:
>> Is this the validation you mentioned which requires the existence of
>> "hwspinlock/core: maintain a list of registered hwspinlock banks" ?
>
> Well, not exactly. The validation is on the following segment,
>
> + id = of_hwspin
Hi Suman,
On Wed, Nov 12, 2014 at 9:50 PM, Suman Anna wrote:
> None of the OMAPs have multiple IP instances, and as such the base-id is
> an optional property. I have made this change to make sure we atleast
> attempt to use the value if mentioned in DT and not hard-coding the
> value to begin wi
Hi Suman,
On Fri, Sep 12, 2014 at 11:24 PM, Suman Anna wrote:
> static int omap_hwspinlock_probe(struct platform_device *pdev)
> {
> - struct hwspinlock_pdata *pdata = pdev->dev.platform_data;
> + struct device_node *node = pdev->dev.of_node;
> struct hwspinlock_device *bank
Hi Suman,
On Fri, Sep 12, 2014 at 11:24 PM, Suman Anna wrote:
> +int of_hwspin_lock_get_id(struct device_node *np, int index)
> +{
> + struct hwspinlock_device *bank;
> + struct of_phandle_args args;
> + int id;
> + int ret;
> +
> + ret = of_parse_phandle_with_args(n
Hi Suman,
On Fri, Sep 12, 2014 at 11:24 PM, Suman Anna wrote:
> HwSpinlock IP is present only on OMAP4 and other newer SoCs,
> which are all device-tree boot only. This patch adds the
> DT bindings information for OMAP hwspinlock module.
>
> Cc: Rob Herring
> Signed-off-by: Suman Anna
> ---
>
Hi Suman,
On Fri, Sep 12, 2014 at 11:24 PM, Suman Anna wrote:
> This patch adds the generic common bindings used to represent
> a hwlock device and use/request locks in a device-tree build.
>
...
>
> Cc: Rob Herring
> Signed-off-by: Suman Anna
> ---
> .../devicetree/bindings/hwlock/hwlock.txt
Hi Suman,
On Thu, Nov 6, 2014 at 8:24 PM, Suman Anna wrote:
> Ping on this. Can you review the latest series v6 [1] and pick it up for
> 3.19? The MSM spinlock driver is also blocked/dependent on that series.
Sure, it's on my mind, I hope I'll get to it next week.
Thanks,
Ohad.
--
To unsubscrib
Hi Bjorn,
On Thu, Oct 30, 2014 at 2:38 AM, Bjorn Andersson
wrote:
> My concern is that merging SMD into rpmsg will still give us two different
> solutions, except that they will be deeply tangled.
I agree.
It's very clear that SMD and rpmsg are different. But fundamentally,
they do exactly the
[Thanks Kevin for the heads up on this]
Hi Bjorn,
On Tue, Sep 30, 2014 at 3:34 AM, Bjorn Andersson
wrote:
> == Codeaurora implementation ==
> The codeaurora implementation originates from an implementation that was
> based purely on initcall and global state
Do you refer to the in-tree arch/ar
On Fri, Sep 26, 2014 at 7:25 PM, Suman Anna wrote:
> I am yet to receive any comments on v6, but that series should address
> both your need for a probe deferral and Ohad's request to not change any
> return types. Please give it a try and let me know if you have any comments.
Guys,
Just to let
Hi Suman,
On Mon, Sep 15, 2014 at 10:39 PM, Suman Anna wrote:
> These processors need to use their internal RAM for loading, which is
> not for generic usage by the kernel, so defining a CMA block for this
> memory doesn't make sense.
Ok - so just to make sure I understand, this is physical memo
Hi Suman,
On Tue, Jul 29, 2014 at 10:33 PM, Suman Anna wrote:
> We currently have two usecases. The primary usecase is the WkupM3
> processor on TI Sitara AM335x/AM437x SoCs used for suspend/resume
> management. This series is a dependency for the WkupM3 remoteproc driver
> that Dave posted [1].
Hi Suman,
On Tue, Aug 12, 2014 at 7:19 PM, Suman Anna wrote:
> Yes, I was playing around with using less buffers in the remoteproc
> resource table for the vrings. The remoteproc virtio code creates the
> vrings using the number of buffers based on .num field value of struct
> fw_rsc_vdev_vring i
Hi Suman,
On Thu, Jul 3, 2014 at 11:53 PM, Suman Anna wrote:
> The buffers to be used for communication are allocated during
> the rpmsg virtio driver's probe, and the number of buffers is
> currently hard-coded to 512. Remove this hard-coded value, as
> this can vary from one platform to another
The following changes since commit 9a3c4145af32125c5ee39c0272662b47307a8323:
Linux 3.16-rc6 (2014-07-20 21:04:16 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git
tags/hwspinlock-3.17
for you to fetch changes up to ceca89e89ee21
On Mon, Aug 4, 2014 at 6:48 PM, Suman Anna wrote:
> On 08/04/2014 06:50 AM, Ohad Ben-Cohen wrote:
>> On Tue, Jul 29, 2014 at 7:10 PM, Suman Anna wrote:
>>> We are trying to add a remoteproc driver for a small Cortex M3 called
>>> the WkupM3 used for suspend/resume ma
On Tue, Jul 29, 2014 at 7:10 PM, Suman Anna wrote:
> We are trying to add a remoteproc driver for a small Cortex M3 called
> the WkupM3 used for suspend/resume management on TI AM335/AM437x SoCs.
> This processor does not have an MMU. Same is the case with another
> processor subsystem PRU-ICSS on
Hi Suman,
On Tue, Jul 8, 2014 at 7:22 PM, Suman Anna wrote:
> A remote processor may need to load certain firmware sections into
> internal memories (eg: RAM at L1 or L2 levels) for performance or
> other reasons.
Can you please provide as much details as you can about the scenario
you need this
Hi Suman,
On Tue, Jul 8, 2014 at 7:22 PM, Suman Anna wrote:
> The remoteproc driver core currently relies on iommu_present() on
> the bus the device is on, to perform MMU management. However, this
> logic doesn't scale for multi-arch, especially for processors that
> do not have an IOMMU.
Is the
Hi Suman,
On Thu, Jul 3, 2014 at 8:28 PM, Suman Anna wrote:
> OK, but we would still require this function to lookup the registered
> device from the controller-phandle to retrieve the base_id.
Can we retrieve the base_id from the parent DT node itself?
Thanks,
Ohad.
--
To unsubscribe from this
Hi Suman,
On Thu, Jul 3, 2014 at 8:35 PM, Suman Anna wrote:
> Not at the moment, with the existing platform implementations. So, if I
> understand you correctly, you are asking to leave out the xlate ops and
> make the of_hwspin_lock_simple_xlate() internal until a need for an
> xlate method aris
On Wed, Jul 2, 2014 at 10:42 PM, Suman Anna wrote:
> Yeah, I did this since we only had 1 instance, and used the same value
> as used in the non-DT legacy code. Once I fold back Patch 8 that adds
> the hwlock-base-id property, this will be assigned by reading that property.
Sounds good, thanks!
-
Hi Suman,
On Thu, Jul 3, 2014 at 12:14 AM, Suman Anna wrote:
>> Do we have a use case today that require the xlate() method?
>>
>> If not, let's remove it as we could always add it back if some new
>> hardware shows up that needs it.
>
> The xlate() method is to support the phandle + args specifi
Hi Suman,
On Thu, Jul 3, 2014 at 12:14 AM, Suman Anna wrote:
>> I'm not sure we need this patch.
>
> This patch is needed if we use the controller-phandle + args specifier
> for requesting hwlocks by a client, as we need to translate
> controller-phandle to the corresponding hwspinlock_device.
>
Hi Suman,
On Thu, May 1, 2014 at 3:34 AM, Suman Anna wrote:
> HwSpinlocks are supported on AM33xx, AM43xx and DRA7xx SoC
> device families as well. The IPs are identical to that of
> OMAP4/OMAP5, except for the number of locks.
>
> Add a depends on to the above family of SoCs to enable the
> buil
Hi Suman,
On Thu, May 1, 2014 at 3:34 AM, Suman Anna wrote:
> The number of hwspinlocks are determined based on the value read
> from the IP block's SYSSTATUS register. However, the module may
> not be enabled and clocked, and the read may result in a bus error.
>
> This particular issue is seen
Hi Suman,
On Thu, May 1, 2014 at 3:34 AM, Suman Anna wrote:
> static int omap_hwspinlock_probe(struct platform_device *pdev)
> {
> - struct hwspinlock_pdata *pdata = pdev->dev.platform_data;
> + struct device_node *node = pdev->dev.of_node;
> struct hwspinlock_device *bank;
1 - 100 of 235 matches
Mail list logo
