On 19 September 2012 17:29, Felipe Balbi wrote:
> this is what I mean, actually. If we remove pm_runtime_get_sync() in
> exchange for pm_runtime_set_active() before pm_runtime_enable(), it
> works on PandaBoard, but breaks BeagleBoard.
>
Perhaps it suggests that OMAP4 (PandaBoard) serial port is
On Tue, Sep 25, 2012 at 2:27 PM, Inderpal Singh
wrote:
> The allocated memory for peripheral channels is not being freed upon
> failure in probe and in module's remove funtion. It will lead to memory
> leakage. Hence free the allocated memory.
>
> Signed-off-by: Inderpal Singh
> ---
> drivers/dm
On Tue, Sep 25, 2012 at 2:27 PM, Inderpal Singh
wrote:
> In probe, memory for multiple DMA descriptors were being allocated at once
> and then it was being split and added into DMA pool one by one. The address
> of this memory allocation is not being saved anywhere. To free this memory,
> the addr
On Tue, Sep 25, 2012 at 2:27 PM, Inderpal Singh
wrote:
> Since peripheral channel resources are not being allocated at probe,
> no need to flush the channels and free the resources in remove function.
>
> Signed-off-by: Inderpal Singh
> ---
> drivers/dma/pl330.c |8 +---
> 1 file changed
On Wed, Sep 26, 2012 at 12:11 PM, Inderpal Singh
wrote:
> How about conditionally DMA_TERMINATE_ALL and free resources like below ?
>
> @@ -3017,9 +3017,11 @@ static int __devexit pl330_remove(struct
> amba_device *adev)
> /* Remove the channel */
> list_del(&pch->
On Wed, Sep 26, 2012 at 4:25 PM, Inderpal Singh
wrote:
> On 26 September 2012 15:02, Jassi Brar wrote:
>> On Wed, Sep 26, 2012 at 12:11 PM, Inderpal Singh
>> wrote:
>>
>>> How about conditionally DMA_TERMINATE_ALL and free resources like below ?
>>>
On Mon, Oct 29, 2012 at 10:59 AM, Bartlomiej Zolnierkiewicz
wrote:
> * Add device tree (DT) property ("pl330,dma-memcpy") for DMA_MEMCPY
> capability and instead of setting this capability unconditionally
> in pl330_probe() do it only when property is present.
>
Perhaps we should pass the arra
xa0) from []
> (cpuidle_enter_state+0x18/0x68)
> [ 368.47] [] (cpuidle_enter_state+0x18/0x68) from []
> (cpuidle_idle_call+0xac/0xe0)
> [ 368.48] [] (cpuidle_idle_call+0xac/0xe0) from []
> (cpu_idle+0xac/0xf0)
> [ 368.49] [] (cpu_idle+0xac/0xf0) from []
> (st
On 18 October 2012 12:15, Huang Shijie wrote:
> 于 2012年10月18日 14:18, Vinod Koul 写道:
>
>> Why cant you do start (prepare clock etc) when you submit the descriptor
>> to dmaengine. Can be done in tx_submit callback.
>> Similarly remove the clock when dma transaction gets completed.
>
> I ever though
On 18 October 2012 20:48, Huang Shijie wrote:
> On Thu, Oct 18, 2012 at 5:29 AM, Jassi Brar
> wrote:
>> On 18 October 2012 12:15, Huang Shijie wrote:
>>> 于 2012年10月18日 14:18, Vinod Koul 写道:
>>>
>>>> Why cant you do start (prepare clock etc) when you su
t; Signed-off-by: Alessandro Rubini
> Acked-by: Giancarlo Asnaghi
> [Davide Ciminaghi : only registers prefixed]
> Signed-off-by: Davide Ciminaghi
> ---
Acked-by: Jassi Brar
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
y ("peri-map") for storing indices
> of peripherals connected to DMAC and fix DT nodes of client
> drivers to use 'dma peripheral id' instead of 'dma request id'.
> Also instead of setting DMA_MEMCPY capability unconditionally in
> pl330_probe() do it only wh
On 30 October 2012 14:51, Bartlomiej Zolnierkiewicz
wrote:
>
> Hi,
>
> On Monday 29 October 2012 22:45:48 Jassi Brar wrote:
>> On Mon, Oct 29, 2012 at 10:59 AM, Bartlomiej Zolnierkiewicz
>> wrote:
>> > * Add device tree (DT) property ("pl330,dma-memcpy&
On Thu, Dec 20, 2012 at 1:09 PM, Stephen Boyd wrote:
> On 11/26/2012 5:08 AM, Jassi Brar wrote:
>> The patchset introduces 64-bit atomic ops, which would need
>> init_atomic64_lock() already called, but that is an initcall made too
>> late. Should we consider calling init_a
Hi Suman,
[Resending with mailing-list CCed this time. For some reason LKML
doesn't appear in reply-to despite this message being fwd'ed from
there]
On Wed, Mar 13, 2013 at 8:53 AM, Suman Anna wrote:
> Hi,
> Please find the updated mailbox patch series for pulling into linux-next.
> The series
Hi Suman,
On Mon, Apr 22, 2013 at 9:26 PM, Anna, Suman wrote:
>>
>> a) No documentation. Usually the header would have proper documentation of
>> data structures and info for users of both side of the api.
>
> I will fix the documentation portion for 3.10. I will also add a TODO as part
> of the
On Thu, Jun 6, 2013 at 12:58 PM, Alexandre Courbot wrote:
> Boot loaders on some Tegra devices can be unlocked but do not let the
> system operate without SecureOS. SecureOS prevents access to some
> registers and requires the operating system to perform certain
> operations through Secure Monitor
On Fri, Jun 7, 2013 at 12:43 PM, Alexandre Courbot wrote:
> On Thu, Jun 6, 2013 at 9:26 PM, Jassi Brar wrote:
>> On Thu, Jun 6, 2013 at 12:58 PM, Alexandre Courbot
>> wrote:
>>> Boot loaders on some Tegra devices can be unlocked but do not let the
>>> system o
On 21 June 2013 12:42, Tony Lindgren wrote:
>
> Arnd pulled in tags/omap-for-v3.11/mailbox-signed, which is the branch
> that should get merged to the mainline tree while we're waiting for
> the generic mailbox framework from Jassi.
>
FYKI I, Suman and Loic have been co-ordinating offline. The gen
Hi Suman,
On 4 May 2013 07:50, Suman Anna wrote:
> Hi Jassi,
>
> On 04/27/2013 01:14 PM, jassisinghb...@gmail.com wrote:
>> From: Jassi Brar
>>
>> Introduce common framework for client/protocol drivers and
>> controller drivers of Inter-Processor-Communi
Hello,
I have made the implementation look more proper. Also made some changes
suggested by Suman. Changes since V1:
* Delete timer upon mailbox release
* Filled in the stub ipc_links_unregister()
* Check kzalloc return for errors.
* Add the controller driver for OMAP2 class. I have taken the pa
From: Suman Anna
The patch 30058677 "ARM / highbank: add support for pl320 IPC"
added a pl320 IPC specific header file as a generic mailbox.h.
This file has been renamed appropriately to allow the
introduction of the generic mailbox API framework.
Acked-by: Mark Langsdorf
Cc: Rafael J. Wysocki
should have a look
at include/linux/mailbox_controller.h
Signed-off-by: Jassi Brar
---
drivers/mailbox/Makefile |4 +
drivers/mailbox/mailbox.c | 494
include/linux/mailbox.h| 17 ++
include/linux/mailbox_client.h
Convert the PL320 controller driver to work with the common
mailbox API. Also convert the only user of PL320, highbank-cpufreq.c
to work with thee API. Drop the obsoleted driver pl320-ipc.c
Signed-off-by: Jassi Brar
---
drivers/cpufreq/highbank-cpufreq.c | 22 +++-
drivers/mailbox/Makefile
A new driver conforming to the common API.
Signed-off-by: Jassi Brar
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 12 +
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 11 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 11 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 13 +
drivers
Hi Suman,
On 7 May 2013 05:15, Suman Anna wrote:
>>
>> The client(s) can always generate TX requests at a rate greater than
>> the API could transmit on the physical link. So as much as we dislike
>> it, we have to buffer TX requests, otherwise N clients would.
>
> The current code doesn't suppo
On 7 May 2013 07:28, Rob Herring wrote:
> On 05/06/2013 02:24 AM, Jassi Brar wrote:
>> Convert the PL320 controller driver to work with the common
>> mailbox API. Also convert the only user of PL320, highbank-cpufreq.c
>> to work with thee API. Drop the obsoleted driver pl3
On 8 May 2013 03:18, Suman Anna wrote:
> Hi Jassi,
>
>> On 7 May 2013 05:15, Suman Anna wrote:
The client(s) can always generate TX requests at a rate greater than
the API could transmit on the physical link. So as much as we dislike
it, we have to buffer TX requests, otherwi
Hi Suman,
On 9 May 2013 06:55, Suman Anna wrote:
>> so it can't be driven by the controller. We could make it a Kconfig option.
>> What do you suggest?
>
> I am saying controller/link because they are the ones that knows how the
> physical transport is, and it may vary from one to another. I wou
On 9 May 2013 22:01, Suman Anna wrote:
> Hi Jassi,
>
> On 05/06/2013 02:24 AM, Jassi Brar wrote:
>> +++ b/include/linux/mailbox_client.h
>> @@ -0,0 +1,85 @@
>> +/*
>> + * This program is free software; you can redistribute it and/or modify
>> + * it un
On Thu, May 9, 2013 at 10:10 PM, Suman Anna wrote:
> On 05/09/2013 11:41 AM, Jassi Brar wrote:
>> On 9 May 2013 22:01, Suman Anna wrote:
>>> Hi Jassi,
>>>
>>> On 05/06/2013 02:24 AM, Jassi Brar wrote:
>>>> +++ b/include/linux/mailbox_client.h
>
On 9 May 2013 23:35, Suman Anna wrote:
>>
>> Perhaps we should change the following
>>
>>void ipc_link_txdone(struct ipc_link *link, enum xfer_result r)
>> to
>>void ipc_link_txdone(struct ipc_link *link, enum xfer_result r, void
>> *data)
>>
>> So that the API could pass that onto clien
Hello Suman,
On 10 May 2013 05:48, Suman Anna wrote:
>> No, please. The controller driver should not implement any policy (of
>> allowing/disallowing requests). It should simply try to do as
>> directed. If the client screwed up even after getting info from
>> platform_data/DT, let it suffer.
>
Hi Suman,
[please limit replies to not more than 80 columns per line]
On 24 April 2013 00:50, Anna, Suman wrote:
>>
>> Documentation wise, we'd need documentation for what we finally wanna have,
>> not the current implementation.
>>
>> There are also some desired features in a good API:-
>>
>>
Hi Loic,
On 24 April 2013 13:09, Loic PALLARDY wrote:
> Hi Jassi, Suman,
>
> Yes, the xxx_no_irq API has been introduced to answer some STE
> requirements. It must be possible to send some message under atomic
> context for different reasons (latency, during idle/suspend procedures...).
> This is
Hi -
On 24 April 2013 13:38, Loic PALLARDY wrote:
> Hi Jassi,
>
> On 04/24/2013 06:39 AM, Jassi Brar wrote:
>> The non-atomic API falls flat should just a single client comes with
>> very low latency requirements.
>
> In fact there are different situations for
On 25 April 2013 04:46, Suman Anna wrote:
> On 04/24/2013 03:56 AM, Jassi Brar wrote:
>
> I think there are two things here - one is what the client needs to do
> upon sending/receiving a message, and the other is what the send API or
> the mailbox controller should do when a
Hi Suman,
On 26 April 2013 03:59, Suman Anna wrote:
> On 04/25/2013 12:20 AM, Jassi Brar wrote:
> tranmitting right away. OK, I thought you didn't want buffering, if that
> is not the case, then the buffering should be within the main driver
> code, like it is now, but configur
Hi Suman,
>> On 26 April 2013 03:59, Suman Anna wrote:
>>> On 04/25/2013 12:20 AM, Jassi Brar wrote:
>> I never said no-buffering and I never said buffering should be in
>> controller drivers. In fact I don't remember ever objecting to how
>> buffering is d
Hi
On 29 April 2013 21:30, Suman Anna wrote:
> Hi Jassi,
>
> On 04/26/2013 11:51 PM, Jassi Brar wrote:
>>> OK, I didn't think of a no RTR interrupt-based controller. I would thing
>>> that such a controller is very rudimentary. I wonder if there are any
>
On 29 April 2013 22:14, Suman Anna wrote:
> On 04/27/2013 01:14 PM, jassisinghb...@gmail.com wrote:
>> From: Jassi Brar
>>
>> Convert the PL320 controller driver to work with the common
>> mailbox API. Also convert the only user of PL320, highbank-cpufreq.c
>>
On 29 April 2013 22:36, Mark Langsdorf wrote:
> On 04/29/2013 11:57 AM, Jassi Brar wrote:
>> On 29 April 2013 22:14, Suman Anna wrote:
>>> On 04/27/2013 01:14 PM, jassisinghb...@gmail.com wrote:
>>>> From: Jassi Brar
>>>> Signed-off-by: Jassi Bra
On Mon, Sep 17, 2012 at 9:57 AM, Inderpal Singh
wrote:
> Since 0 is not considered as error at dmaengine level, return ENOMEM
> from pl330_alloc_chan_resources in case of failure.
>
> Signed-off-by: Inderpal Singh
Acked-by: Jassi Brar
> ---
> drivers/dma/pl330.c |2 +-
On Mon, Sep 17, 2012 at 3:20 PM, Sachin Kamat wrote:
> kzalloc could return NULL. Hence add a check to avoid
> NULL pointer dereference.
>
> Signed-off-by: Sachin Kamat
Patch 1 and 2, both
Acked-by: Jassi Brar
--
To unsubscribe from this list: send the line "unsubscribe lin
/dma/pl330.c | 53
> ++++---
> 1 file changed, 38 insertions(+), 15 deletions(-)
>
All seem fine.
Acked-by: Jassi Brar
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 24 November 2012 06:23, Davide Ciminaghi wrote:
> From: Alessandro Rubini
>
> This driver would not compile if ARM_AMBA is selected under x86,
> because "CS" and "DS" are already defined there. But AMBA
> is used in the x86 world by a PCI-to-AMBA bridge, to be submitted.
>
> The patch just ad
On 24 November 2012 12:33, Alessandro Rubini wrote:
> My patch:
>>> This driver would not compile if ARM_AMBA is selected under x86,
>>> because "CS" and "DS" are already defined there. But AMBA
>>> is used in the x86 world by a PCI-to-AMBA bridge, to be submitted.
>>>
>>> The patch just adds the
Hi Paul,
On Thu, Aug 23, 2012 at 7:44 PM, wrote:
> Hi all,
>
> Please find attached the latest version for CFS load-tracking.
>
> It implements load-tracking on a per-sched_entity (currently SCHED_NORMAL, but
> could be extended to RT as well) basis. This results in a bottom-up
> load-computatio
On Thu, Sep 27, 2012 at 9:43 AM, Inderpal Singh
wrote:
>
> Don't you think free_chan_resource should be done __only if__
> alloc_chan_resource was successful ?
>
No, I don't think so. Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to maj
On Thu, Sep 27, 2012 at 11:00 AM, Inderpal Singh
wrote:
> On 27 September 2012 10:35, Jassi Brar wrote:
>> On Thu, Sep 27, 2012 at 9:43 AM, Inderpal Singh
>> wrote:
>>>
>>> Don't you think free_chan_resource should be done __only if__
>>> alloc_ch
On Thu, Sep 27, 2012 at 9:11 PM, Inderpal Singh
wrote:
> On 27 September 2012 15:18, Vinod Koul wrote:
>> On Wed, 2012-09-26 at 12:11 +0530, Inderpal Singh wrote:
>>> If we fail pl330_remove while some client is queued, the force unload
>>> will fail and the
>>> force unload will lose its purpose
On Fri, Sep 28, 2012 at 10:03 AM, Inderpal Singh
wrote:
>
> Now, if we have to check if any client is using the channel and then
> decide. We will have to traverse the channel list twice once to check
> the usage and second time to delete the nodes from the list if we go
> ahead with remove.
> The
On Mon, Sep 5, 2016 at 7:14 AM, HS Liao wrote:
> Use clk_disable_unprepare instead of clk_disable to save more energy
> when CMDQ is idle.
>
> Signed-off-by: HS Liao
> ---
> drivers/mailbox/mtk-cmdq.c | 54
> +++---
The driver is introduced by second patc
On Mon, Sep 5, 2016 at 7:14 AM, HS Liao wrote:
> This patch is first version of Mediatek Command Queue(CMDQ) driver. The
> CMDQ is used to help write registers with critical time limitation,
> such as updating display configuration during the vblank. It controls
> Global Command Engine (GCE) hardw
gt; @@ -0,0 +1,199 @@
> +/*
> + * Copyright (C) 2016 BayLibre SAS.
> + * Author: Neil Armstrong
> + * Heavily based on meson_mhu.c from :
> + * Copyright (C) 2013-2015 Fujitsu Semiconductor Ltd.
> + * Copyright (C) 2015 Linaro Ltd.
> + * Author: Jassi Brar
.
>
Hi Linus,
The following changes since commit 8714f8f5fe396ca513ccaaac2304497439c181fb:
Merge branch 'for-linus' of git://git.kernel.dk/linux-block
(2016-06-11 18:42:59 -0700)
are available in the git repository at:
git://git.linaro.org/landing-teams/working/fujitsu/integration.git
mailbox-f
On Wed, Aug 31, 2016 at 1:43 PM, Horng-Shyang Liao wrote:
>> >> The driver uses the mailbox framework, so it should live in the
>> >> drivers/mailbox folder.
>> >
>> > As you know, the maximum number of gce threads is 16.
>> > However, we plan to support more clients in the future,
>> > and they
On Thu, Aug 25, 2016 at 7:07 PM, Horng-Shyang Liao wrote:
> Hi Matthias,
>
> On Wed, 2016-08-24 at 13:00 +0200, Matthias Brugger wrote:
>> On 24/08/16 05:27, HS Liao wrote:
> [...]
>> > Changes since v12:
>> > - remove mediatek,gce from device tree
>>
>> Why? The binding got accepted by Rob.
>
>
On Wed, Nov 1, 2017 at 10:02 PM, Sudeep Holla wrote:
>
> Such controllers don't need to transmit any data, they just transmit
> the signal. In such controllers the data pointer passed to
> mbox_send_message is passed to client via it's tx_prepare callback.
> Controller doesn't need any data to be
On Wed, Nov 1, 2017 at 11:45 PM, Sudeep Holla wrote:
>
>
> On 01/11/17 18:03, Jassi Brar wrote:
>> On Wed, Nov 1, 2017 at 10:02 PM, Sudeep Holla wrote:
>>
>>>
>>> Such controllers don't need to transmit any data, they just transmit
>>> the s
On Thu, Nov 2, 2017 at 3:42 AM, Bjorn Andersson
wrote:
> On Wed 01 Nov 11:03 PDT 2017, Jassi Brar wrote:
>> On Wed, Nov 1, 2017 at 10:02 PM, Sudeep Holla wrote:
> [..]
>> >
>> > This is rough idea I have on extending mailbox interface to support
>> >
On Thu, Nov 2, 2017 at 3:47 AM, Bjorn Andersson
wrote:
> On Wed 01 Nov 11:15 PDT 2017, Sudeep Holla wrote:
>>
>> 80 writel_relaxed(msg->cmd, mb->mbox_base +
>> MAILBOX_A2B_CMD(chans->idx));
>> 81 writel_relaxed(msg->rx_size, mb->mbox_base +
>>
>> 82MAILBO
On Thu, Nov 2, 2017 at 8:57 AM, Bjorn Andersson
wrote:
> On Wed 01 Nov 20:02 PDT 2017, Jassi Brar wrote:
>
>> On Thu, Nov 2, 2017 at 3:47 AM, Bjorn Andersson
>> wrote:
>> > On Wed 01 Nov 11:15 PDT 2017, Sudeep Holla wrote:
>> >>
>> >>
On Thu, Nov 2, 2017 at 4:17 PM, Sudeep Holla wrote:
> On 02/11/17 02:39, Jassi Brar wrote:
>>>>>
>>>>> Such controllers don't need to transmit any data, they just transmit
>>>>> the signal. In such controllers the data pointer passed to
On Thu, Nov 2, 2017 at 5:19 PM, Sudeep Holla wrote:
> On 02/11/17 11:26, Jassi Brar wrote:
>>>> 1) Where does the "whatever_value_to_trigger_signal" come from?
>>>
>>> Controller specific.
>>>
>>>> That has to come from client
On Thu, Nov 2, 2017 at 6:07 PM, Sudeep Holla wrote:
> On 02/11/17 12:21, Jassi Brar wrote:
>> On Thu, Nov 2, 2017 at 5:19 PM, Sudeep Holla wrote:
>>> On 02/11/17 11:26, Jassi Brar wrote:
>>
>>>>>> 1) Where does the "whatever_value_to_trigger_sign
On Mon, Aug 7, 2017 at 2:47 PM, Zhong Kaihua wrote:
> From: Kaihua Zhong
>
> Add mailbox driver for Hi3660.
>
> Signed-off-by: Leo Yan
> Signed-off-by: Ruyi Wang
> Tested-by: Kaihua Zhong
>
> ---
> drivers/mailbox/Kconfig | 6 +
> drivers/mailbox/Makefile | 2 +
> drivers
On Fri, Nov 3, 2017 at 8:17 PM, Sudeep Holla wrote:
.
> +int scmi_do_xfer(const struct scmi_handle *handle, struct scmi_xfer *xfer)
> +{
> + int ret;
> + int timeout;
> + struct scmi_info *info = handle_to_scmi_info(handle);
> + struct device *dev = info->dev;
> +
> +
On Mon, Sep 14, 2015 at 4:36 PM, Caesar Wang wrote:
> This add the necessary binding documentation for mailbox
> found on RK3368 SoC.
>
> Signed-off-by: Caesar Wang
> ---
>
> .../bindings/mailbox/rockchip-mailbox.txt | 33
> ++
> 1 file changed, 33 insertions(+)
>
On Mon, Sep 14, 2015 at 4:36 PM, Caesar Wang wrote:
> This driver is found on RK3368 SoCs.
>
> The Mailbox module is a simple APB peripheral that allows both
> the Cortex-A53 MCU system to communicate by writing operation to
> generate interrupt.
> The registers are accessible by both CPU via APB
On 5 October 2015 at 18:32, Lee Jones wrote:
> Hi Jassi,
>
> This should be it. Exciting times!
>
> ST's platforms currently support a maximum of 5 Mailboxes, one for
> each of the supported co-processors situated on the platform. Each
> Mailbox is divided up into 4 instances which consist of 32
On Mon, Oct 12, 2015 at 10:02 PM, Leo Yan wrote:
> +
> +Mailbox Device Node:
> +
> +
> +Required properties:
> +
> +- compatible: Shall be "hisilicon,hi6220-mbox"
> +- reg: Contains the mailbox register address range (base
> +
On Mon, Oct 12, 2015 at 10:02 PM, Leo Yan wrote:
> +
> +#define MBOX_CHAN_MAX 32
> +#define MBOX_CHAN_NUM 2
> +
You mean the hardware has 32 channels but this driver can not manage
more than 2 ?
OR, there are 32 interfaces but only 2 physical 'floating' links, s
On Fri, Oct 16, 2015 at 10:59 AM, Leo Yan wrote:
> On Fri, Oct 16, 2015 at 10:43:00AM +0530, Jassi Brar wrote:
>> On Mon, Oct 12, 2015 at 10:02 PM, Leo Yan wrote:
>>
>> > +
>> > +#define MBOX_CHAN_MAX 32
>> > +#define MBOX_CHAN_NUM
On 16 October 2015 at 11:38, Leo Yan wrote:
> On Fri, Oct 16, 2015 at 11:17:32AM +0530, Jassi Brar wrote:
>> On Fri, Oct 16, 2015 at 10:59 AM, Leo Yan wrote:
>> > On Fri, Oct 16, 2015 at 10:43:00AM +0530, Jassi Brar wrote:
>> >> On Mon, Oct 12, 20
On 16 October 2015 at 12:51, Lee Jones wrote:
> Hi Jassi,
>
> [Resending the updated patch-set this time]
>
> This should be it. Exciting times!
>
> ST's platforms currently support a maximum of 5 Mailboxes, one for
> each of the supported co-processors situated on the platform. Each
> Mailbox i
On Wed, Sep 23, 2015 at 5:44 AM, Dave Gerlach wrote:
> The mailbox framework controls the transmission queue and requires
> either its controller implementations or clients to run the state
> machine for the Tx queue. The OMAP mailbox controller uses a Tx-ready
> interrupt as the equivalent of a T
On 22 October 2015 at 05:35, Suman Anna wrote:
>> Anyways I am OK too, if you guys want to fix it with a platform
>> specific quirk. Let me know I'll pick this patch.
>
> I haven't gotten a chance to try #1, and I won't be able to look at it
> atleast for another month. I suggest that you go ah
Hi Linus,
The following changes since commit 4e6b6ee253ce58aa156d7f1448d1038679b26783:
Merge tag 'md/4.2-rc5-fixes' of git://neil.brown.name/md (2015-08-05
11:02:42 +0200)
are available in the git repository at:
http://git.linaro.org/landing-teams/working/fujitsu/integration.git
mailbox-fo
On Wed, Aug 19, 2015 at 7:52 PM, Lee Jones wrote:
> +
> +#define MBOX_BASE(mdev, inst) ((mdev)->base + (inst * 4))
>
It should be(inst) * 4
> +/**
> + * STi Mailbox device data
> + *
> + * An IP Mailbox is currently composed of 4 instances
> + * Each instance is currently composed of
On 2 October 2015 at 15:02, Lee Jones wrote:
> On Fri, 02 Oct 2015, Jassi Brar wrote:
>
>> On Wed, Aug 19, 2015 at 7:52 PM, Lee Jones wrote:
>>
>>
>>
>> > +
>> > +#define MBOX_BASE(mdev, inst) ((mdev)->base + (inst * 4))
>>
On Mon, Jul 2, 2018 at 5:10 PM, Mikko Perttunen wrote:
> Add a new TXDONE option, TXDONE_BY_BLOCK. With this option, the
> send_data function of the mailbox driver is expected to block until
> the message has been sent. The new option is used with the Tegra
> Combined UART driver to minimize unnec
On Wed, Aug 8, 2018 at 5:08 PM, Mikko Perttunen wrote:
>
>
> On 04.08.2018 13:45, Mikko Perttunen wrote:
>>
>> On 08/03/2018 03:54 PM, Jassi Brar wrote:
>>>
>>> On Mon, Jul 2, 2018 at 5:10 PM, Mikko Perttunen
>>> wrote:
>>>>
>>
On Wed, Aug 8, 2018 at 8:04 PM, Mikko Perttunen wrote:
>
>
> On 08/08/2018 05:10 PM, Jassi Brar wrote:
>>
>> On Wed, Aug 8, 2018 at 5:08 PM, Mikko Perttunen wrote:
>>>
>>>
>>>
>>> On 04.08.2018 13:45, Mikko Perttunen wrote
d through the earlycon as
> it's printing out correctly.
>
> Thanks,
> Mikko
>
>
> On 08.08.2018 17:46, Mikko Perttunen wrote:
>>
>> On 08/08/2018 05:39 PM, Jassi Brar wrote:
>>>
>>> On Wed, Aug 8, 2018 at 8:04 PM, Mikko Perttunen wrote:
On Tue, May 29, 2018 at 2:12 AM, Samarth Parikh wrote:
> diff --git a/Documentation/devicetree/bindings/mailbox/arm-mhu.txt
> b/Documentation/devicetree/bindings/mailbox/arm-mhu.txt
> index 4971f03..1633535 100644
> --- a/Documentation/devicetree/bindings/mailbox/arm-mhu.txt
> +++ b/Documentati
On 21 August 2018 at 15:17, Masahiro Yamada
wrote:
> (+CC Rob, DT, LKML)
>
> I forgot to CC this to DT community...
>
>
> 2018-08-21 18:30 GMT+09:00 Masahiro Yamada :
>> The MIO DMAC (Media IO DMA Controller) is used in UniPhier LD4,
>> Pro4, and sLD8 SoCs.
>>
>> Signed-off-by: Masahiro Yamada
>>
On 23 August 2018 at 10:48, Masahiro Yamada
wrote:
> Hi Jassi,
>
>
> 2018-08-21 19:44 GMT+09:00 Jassi Brar :
>> On 21 August 2018 at 15:17, Masahiro Yamada
>> wrote:
>>> (+CC Rob, DT, LKML)
>>>
>>> I forgot to CC this to DT community...
>
On 23 August 2018 at 18:51, Rob Herring wrote:
> On Thu, Aug 23, 2018 at 12:38 AM Jassi Brar
> wrote:
>> On 23 August 2018 at 10:48, Masahiro Yamada
>> >
>> > If desired, I will export of_irq_count()
>> > and use it from my driver.
>> >
>&
On Thu, Jul 26, 2018 at 12:23 PM, Oleksij Rempel
wrote:
> From: Dong Aisheng
>
> Mailbox devices may have only one channel which means the mbox-cells
> at least 1 does not make sense for this type devices. Let's remove
> that limitation to allow the mbox-cells to be equal to 0.
>
OK
But please r
On Thu, Jul 26, 2018 at 4:30 PM, A.s. Dong wrote:
>> -Original Message-
>> From: Jassi Brar [mailto:jassisinghb...@gmail.com]
>> Sent: Thursday, July 26, 2018 5:42 PM
>> To: Oleksij Rempel
>> Cc: Shawn Guo ; Fabio Estevam
>> ; Rob Herring ; Mark
On Thu, Jul 26, 2018 at 5:25 PM, A.s. Dong wrote:
>> -Original Message-
>> From: Jassi Brar [mailto:jassisinghb...@gmail.com]
>> Sent: Thursday, July 26, 2018 7:37 PM
>> To: A.s. Dong
>> Cc: Oleksij Rempel ; Shawn Guo
>> ; Fabio Estevam ; Rob
>
On Mon, Jul 23, 2018 at 6:59 PM, Nishanth Menon wrote:
> On 18:06-20180716, Nishanth Menon wrote:
>> The V2 of the series updates a minor comment in binding and picks up Rob's
>> Reviewed-by
>>
>> Since I have'nt seen additional comments, I am assuming things are fine for
>> v4.19.
>>
>> The fol
On Wed, Jul 11, 2018 at 6:28 PM, A.s. Dong wrote:
> Hi Jassi,
>
>> -Original Message-----
>> From: Jassi Brar [mailto:jassisinghb...@gmail.com]
>> Sent: Wednesday, July 11, 2018 6:44 PM
>> To: A.s. Dong
>> Cc: Sascha Hauer ; linux-arm-
>> ker...@list
On Wed, Jul 11, 2018 at 10:11 PM, A.s. Dong wrote:
> Hi Jassi,
>
>> -Original Message-----
>> From: Jassi Brar [mailto:jassisinghb...@gmail.com]
>> Sent: Thursday, July 12, 2018 12:32 AM
>> To: A.s. Dong
>> Cc: Sascha Hauer ; linux-arm-
>> ker.
On Thu, Feb 1, 2018 at 12:10 AM, Georgi Djakov wrote:
>
> Hi Jassi,
>
> On 01/27/2018 05:44 AM, Jassi Brar wrote:
> > On Thu, Jan 4, 2018 at 10:26 PM, Georgi Djakov
> > wrote:
> >> Hi Jassi,
> >>
> >> On 12/29/2017 08:14 AM, Jassi Brar wrote:
On Tue, Dec 19, 2017 at 4:45 PM, Kaihua Zhong wrote:
.
> diff --git a/drivers/mailbox/hi3660-mailbox.c
> b/drivers/mailbox/hi3660-mailbox.c
> new file mode 100644
> index 000..3ceca40
> --- /dev/null
> +++ b/drivers/mailbox/hi3660-mailbox.c
> @@ -0,0 +1,319 @@
> +// SPDX-License-Identifi
On Thu, Jan 4, 2018 at 10:26 PM, Georgi Djakov wrote:
> Hi Jassi,
>
> On 12/29/2017 08:14 AM, Jassi Brar wrote:
>> Hi Bjorn,
>>
>> On Sun, Dec 24, 2017 at 10:36 AM, Bjorn Andersson
>> wrote:
>>> On Fri 22 Dec 20:57 PST 2017, Jassi Brar wrote:
>&
On Mon, Jan 8, 2018 at 2:08 PM, houlong wei wrote:
> Hi Jassi,
>
> Sorry for reply so late.
> According to previous discussion, there are two methods to move
> dma_map_single() outside of spin_lock.
> (1) put in mtk-cmdq-helper.c, as described by HS on 2017-02-09.
> > I think a trade-off solutio
On Fri, Jan 5, 2018 at 5:21 AM, Wendy Liang wrote:
> Xilinx ZynqMP IPI(Inter Processor Interrupt) is a hardware block
> in ZynqMP SoC used for the communication between various processor
> systems.
>
> Signed-off-by: Wendy Liang
> ---
> .../bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt | 104
>
1 - 100 of 590 matches
Mail list logo
