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
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:
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
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-omap" in
the body of a message to majord...@vger.kernel.org
More majordom
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
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
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
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, 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-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vge
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
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, Sep 16, 2014 at 7:14 PM, Suman Anna wrote:
> The current remoteproc infrastructure automatically calls rproc_boot
> only as part of the rpmsg/virtio stack (in remoteproc_virtio.c), but
> since the WkupM3 does not use rpmsg, there is no automatic booting of
> the WkupM3 processor
On Wed, Sep 10, 2014 at 12:10 AM, Kevin Hilman wrote:
> What I think you need to do (and what I've recommended at least once in
> earlier reviews) put all the (non-rproc) wkup_m3 IPC into into one
> driver and create a well-described, well-documented API that the
> platform PM code will use.
>
> I
On Tue, Sep 9, 2014 at 1:30 AM, Kevin Hilman wrote:
> To me, it's not terribly clear how you made the split between this PM
> core code an the remoteproc code. In the changelog for the remoteproc
> patch, it states it's to "load the firmware for and boot the wkup_m3".
> But, while parts of the IP
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
On Thu, Jul 24, 2014 at 6:13 PM, Suman Anna wrote:
>> Is there a specific reason for using the put_sync variant here? If
>> not, let's just use the regular put().
>
> There was no particular reason, you can change it.
Thanks for confirming. I've applied both patches to remoteproc's
for-next branc
Hi Suman,
On Thu, Jul 3, 2014 at 2:00 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, 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;
Hi Suman,
On Thu, May 1, 2014 at 3:34 AM, Suman Anna wrote:
> 2. The of_hwspin_lock_simple_xlate() is a simple default
>translator function for hwspinlock provider implementations
>that use a single cell number for requesting a specific lock
>(relatively indexed) within a hwlock bank.
Hi Suman,
On Thu, May 1, 2014 at 3:34 AM, Suman Anna wrote:
>
> The hwspinlock_device structure is used for registering a bank of
> locks with the driver core. The structure already contains the
> necessary members to identify the bank of locks. The core does not
> maintain the hwspinlock_devices
Hi Suman,
On Tue, Mar 18, 2014 at 1:46 AM, Suman Anna wrote:
> So far, we have not come across multiple controllers. I see your point,
> and I think this also depends on the semantics of how you exchange the
> lock id number. The agreement at the moment is on base_ids across
> multiple SoC compon
Hi Suman,
On Mon, Mar 17, 2014 at 9:10 PM, Suman Anna wrote:
> base_id would be a property (if added) of the hwspinlock controller node,
> and from DT perspective, we will be using the phandle for the controller
> anyway. So, using a base_id+specifier seems redundant, as the specifier is
> alread
Hi Suman,
On Sat, Mar 15, 2014 at 1:58 AM, Suman Anna wrote:
> The series doesn't change the semantics of hwspinlock registration or adds a
> new OF controller registration function. Implementations would still need to
> register a controller using a base_id and number of locks. The series rather
On Fri, Mar 14, 2014 at 5:23 PM, Josh Cartwright wrote:
> So, are you suggesting that because fatal errors should be "extremely
> rare", a consuming driver should just assume that if NULL is returned
> from a hwspin_lock_request*() function that it was the "device not yet
> probed" case that was h
Hi Suman, Mark,
On Mon, Feb 24, 2014 at 8:14 PM, Suman Anna wrote:
> Mark, Ohad,
...
> Gentle reminder, can you provide your acks/comments?
Sorry for the late jump in.
I have a few comments:
- Hardware spinlocks must have global and system-wide id numbers;
these numbers cannot be maintained in
On Sun, Mar 2, 2014 at 10:19 PM, Bjorn Andersson wrote:
> When introducing the ability to reference a hwspin lock via a phandle
> in device tree it makes a big difference to be able to differ between
> the case of "initialization failed" or "device not yet probed"; so
> that the client knows if it
Hi Suman,
On Tue, Mar 4, 2014 at 7:38 PM, Suman Anna wrote:
Do you have any objections to the return code convention change?
>>>
>>> Unless strictly needed, I prefer we don't switch to the ERR_PTR code
>>> convention, as it reduces code readability and increases chances of
>>> user bugs.
>>>
On Mon, Feb 10, 2014 at 9:14 PM, Suman Anna wrote:
> On 02/07/2014 04:49 PM, Bjorn Andersson wrote:
>> It seems to be standard practice to pass the error value back to the
>> consumer, so you should
>> return ERR_PTR(ret); here instead of the NULL...
>
>
> I have modelled the return values in this
With the lists this time
On Wed, Jul 10, 2013 at 6:17 PM, Ohad Ben-Cohen wrote:
> The following changes since commit 9e895ace5d82df8929b16f58e9f515f6d54ab82d:
>
> Linux 3.10-rc7 (2013-06-22 09:47:31 -1000)
>
> are available in the git repository at:
>
> git://git.ker
Hi,
On Mon, Jul 8, 2013 at 10:31 AM, Barry Song <21cn...@gmail.com> wrote:
> hi Ohad/all,
> i am trying to find some real users of rpmsg, here i only get
> samples/rpmsg/rpmsg_client_sample.c, does it mean other real drivers
> are out of mainline?
Yes
> where could i get them?
TI maintains them
l, from Vincent Stehlé.
- Fix Kconfig VIRTUALIZATION dependency, from Suman Anna
(a non-critical fix which arrived late during the rc cycle).
--------
Ohad Ben-Cohen (1):
remoteproc: perserve resource table data
Robert Tivy (2):
remo
.
Ohad Ben-Cohen (1):
MAINTAINERS: add rpmsg entry
Robert Tivy (1):
rpmsg: process _all_ pending messages in rpmsg_recv_done
Suman Anna (1):
rpmsg: fix kconfig dependencies for VIRTIO
MAINTAINERS | 8 +++
drivers/rpmsg/Kconfig
The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:
Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git
tags/hwspinlock-3.10
for you to fetch changes up to 8ae053d62e88c4
Hi Stephen,
On Tue, Apr 16, 2013 at 3:07 AM, Stephen Rothwell wrote:
> On Mon, 15 Apr 2013 09:28:17 +0300 Ohad Ben-Cohen wrote:
>> Could you please add:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git#for-next
>>
>> to linux-next to include ne
Hi Stephen,
Could you please add:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git#for-next
to linux-next to include new stuff coming from Rob?
Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.or
The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:
Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git
tags/hwspinlock-3.9-fix
for you to fetch changes up to c10b90d85a5
The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9:
Linux 3.9-rc2 (2013-03-10 16:54:19 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git
tags/remoteproc-3.9-fixes
for you to fetch changes up to c7426bce5
On Wed, Feb 27, 2013 at 7:10 PM, Vincent Stehlé wrote:
> OMAP5 has spinlocks, too.
>
> Signed-off-by: Vincent Stehlé
> Cc: Ohad Ben-Cohen
> Cc: Tony Lindgren
Thanks, applied to hwspinlock-next.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap"
On Mon, Feb 18, 2013 at 1:06 PM, Vincent Stehlé wrote:
> Signed-off-by: Vincent Stehlé
Thanks, applied to remoteproc-next.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
Hi Omar,
On Fri, Dec 21, 2012 at 9:33 PM, Omar Ramirez Luna
wrote:
> Yes, I made the changes, for tidspbridge and remoteproc, I will submit
> both for review, based on this series.
Great, thanks.
Please note that when we do eventually merge this, we need your
updates to be squashed into Loic's
;
> Signed-off-by: Guillaume Aubertin
Acked-by: Ohad Ben-Cohen
> ---
> drivers/iommu/omap-iommu.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
> index badc17c..a0fcad2 100644
> --
On Thu, Dec 20, 2012 at 9:19 PM, Olof Johansson wrote:
> While we can make the branch stable, would it make sense to make
> remoteproc for omap depend on !multiplatform during the transition, to
> reduce dependencies a little? Either way works, but it'd be nice to
> keep them independent if we can
Hi Loic,
On Tue, Dec 18, 2012 at 3:10 PM, Loic Pallardy
wrote:
> In order to create a generic mailbox framework, functions
> and structures should be renamed in mailbox.
This patch should also update omap_remoteproc.c so the build doesn't
break (and if you have a panda board around it might be n
riv.
----
Ohad Ben-Cohen (1):
remoteproc: fix error path of ->find_vqs
drivers/remoteproc/remoteproc_virtio.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body
anding comment or issue that might show up.
Joerg, can you please take it (or at least its first four patches) ?
We have Tony's ack for the mach-omap2 parts.
Tested-by: Ohad Ben-Cohen
Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap&qu
Hi Omar,
On Thu, Nov 15, 2012 at 6:53 PM, Omar Ramirez Luna wrote:
> On 14 November 2012 03:54, Ohad Ben-Cohen wrote:
>> Most of the above questions imply this patch not only converts the
>> iommu to runtime PM, but may carry additional changes that may imply
>> previous
Eliminate an erroneous invocation of rproc_shutdown inside
the error path of rproc_virtio_find_vqs.
Reported-by: Ido Yariv
Signed-off-by: Ohad Ben-Cohen
---
drivers/remoteproc/remoteproc_virtio.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers
Hi Omar,
On Wed, Nov 14, 2012 at 4:34 AM, Omar Ramirez Luna wrote:
> Use runtime PM functionality interfaced with hwmod enable/idle
> functions, to replace direct clock operations and sysconfig
> handling.
>
> Dues to reset sequence, pm_runtime_put_sync must be used, to avoid
> possible operation
On Fri, Nov 2, 2012 at 9:23 PM, Tony Lindgren wrote:
> We need to move the iommu code to live under drivers
> for arm common zImage support.
For the iommu changes in the entire series:
Acked-by: Ohad Ben-Cohen
Joerg, it might relieve some pain if this will go through Tony's tree,
a
Hi Laurent,
On Fri, Oct 26, 2012 at 11:35 AM, Laurent Pinchart
wrote:
> That's on my to-do list, as well as porting the OMAP3 ISP driver to videobuf2,
> adding DT support, moving to the common clock framework (when that will be
> available for the OMAP3), supporting missing V4L2 features, ... All
On Thu, Oct 25, 2012 at 11:39 PM, Tony Lindgren wrote:
>> > Joerg and Ohad, do you have any opinions on this?
I agree that there's some merit in having a separate header file for
IOVMM, since it's a different layer from the IOMMU API.
But in reality it's tightly coupled with OMAP's IOMMU, and id
Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen
Date: Sun, 14 Oct 2012 20:16:01 +0200
Subject: [PATCH] ARM: OMAP: don't print any error when wl12xx isn't
configured
Stop intimidating users with scary wlan error messages in case wl12xx
support wasn't even built.
In addition, when wl12x
On Tue, Oct 23, 2012 at 9:37 AM, Igor Grinberg wrote:
>> + ret = wl12xx_set_platform_data(wlan_data);
>> + /* bail out silently in case wl12xx isn't configured */
>> + if (ret == -ENOSYS)
>> + return ret;
>
> Since we have the function ifdef'ed, I don't think we need
> the
On Fri, Oct 19, 2012 at 7:07 PM, Tony Lindgren wrote:
...
> We could optimize away a minimal amount of code for many configurations
> with the ifdef? :)
Sure, here goes (compile tested only):
>From 6b82365da2c04986e647d06c285197efece7cb34 Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen
Hi Igor,
On Wed, Oct 17, 2012 at 2:43 PM, Igor Grinberg wrote:
> You are adding declarations inside the common-board-devices.h,
> but the implementation inside the devices.c.
> I can see that devices.c has only on-soc devices in it.
> So, I would expect to have the wl12xx_board_init() function im
ause it's pretty trivial. But do let me know if you want me
to get it tested.
>From b940fb88a97494ad3a0a093279a5f176c0b29e44 Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen
Date: Sun, 14 Oct 2012 20:16:01 +0200
Subject: [PATCH] ARM: OMAP: don't print any error when wl12xx isn't
co
7;t elicit any
error) and the patch below (also attached) should make it go away on:
>From 374f145568585c8d6a8d5e4b8b5d3e6baedd2f39 Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen
Date: Sun, 14 Oct 2012 20:16:01 +0200
Subject: [PATCH] ARM: OMAP: don't print any error when wl12xx isn't
1 - 100 of 824 matches
Mail list logo
