On 31/07/15 14:45, Jassi Brar wrote:
On Fri, Jul 31, 2015 at 6:38 PM, Sudeep Holla wrote:
On 31/07/15 11:43, Sudeep Holla wrote:
On 31/07/15 11:38, Jassi Brar wrote:
On Fri, Jul 31, 2015 at 3:10 PM, Sudeep Holla
wrote:
I forgot to mention, we have a the following description in
On 31/07/15 14:45, Jassi Brar wrote:
On Fri, Jul 31, 2015 at 6:38 PM, Sudeep Holla sudeep.ho...@arm.com wrote:
On 31/07/15 11:43, Sudeep Holla wrote:
On 31/07/15 11:38, Jassi Brar wrote:
On Fri, Jul 31, 2015 at 3:10 PM, Sudeep Holla sudeep.ho...@arm.com
wrote:
I forgot to mention,
On Fri, Jul 31, 2015 at 6:38 PM, Sudeep Holla wrote:
>
>
> On 31/07/15 11:43, Sudeep Holla wrote:
>>
>>
>>
>> On 31/07/15 11:38, Jassi Brar wrote:
>>>
>>> On Fri, Jul 31, 2015 at 3:10 PM, Sudeep Holla
>>> wrote:
I forgot to mention, we have a the following description in
On 31/07/15 11:43, Sudeep Holla wrote:
On 31/07/15 11:38, Jassi Brar wrote:
On Fri, Jul 31, 2015 at 3:10 PM, Sudeep Holla wrote:
I forgot to mention, we have a the following description in
mbox_client_txdone which is misleading:
"The client/protocol had received some 'ACK' packet and it
On 31/07/15 11:38, Jassi Brar wrote:
On Fri, Jul 31, 2015 at 3:10 PM, Sudeep Holla wrote:
I forgot to mention, we have a the following description in
mbox_client_txdone which is misleading:
"The client/protocol had received some 'ACK' packet and it notifies the
API that the last packet was
On Fri, Jul 31, 2015 at 3:10 PM, Sudeep Holla wrote:
>
> I forgot to mention, we have a the following description in
> mbox_client_txdone which is misleading:
>
> "The client/protocol had received some 'ACK' packet and it notifies the
> API that the last packet was sent successfully. This only
On 30/07/15 18:56, Jassi Brar wrote:
On Wed, Jul 29, 2015 at 6:20 PM, Sudeep Holla wrote:
On 29/07/15 12:19, Jassi Brar wrote:
Assuming the former, let me explain. When a client receives a
response, it can be sure that the request has already been read by the
remote.
Waiting for the
On 30/07/15 18:56, Jassi Brar wrote:
On Wed, Jul 29, 2015 at 6:20 PM, Sudeep Holla wrote:
On 29/07/15 12:19, Jassi Brar wrote:
Assuming the former, let me explain. When a client receives a
response, it can be sure that the request has already been read by the
remote.
Waiting for the
On 31/07/15 11:43, Sudeep Holla wrote:
On 31/07/15 11:38, Jassi Brar wrote:
On Fri, Jul 31, 2015 at 3:10 PM, Sudeep Holla sudeep.ho...@arm.com wrote:
I forgot to mention, we have a the following description in
mbox_client_txdone which is misleading:
The client/protocol had received some
On Fri, Jul 31, 2015 at 6:38 PM, Sudeep Holla sudeep.ho...@arm.com wrote:
On 31/07/15 11:43, Sudeep Holla wrote:
On 31/07/15 11:38, Jassi Brar wrote:
On Fri, Jul 31, 2015 at 3:10 PM, Sudeep Holla sudeep.ho...@arm.com
wrote:
I forgot to mention, we have a the following description in
On 30/07/15 18:56, Jassi Brar wrote:
On Wed, Jul 29, 2015 at 6:20 PM, Sudeep Holla sudeep.ho...@arm.com wrote:
On 29/07/15 12:19, Jassi Brar wrote:
Assuming the former, let me explain. When a client receives a
response, it can be sure that the request has already been read by the
remote.
On 30/07/15 18:56, Jassi Brar wrote:
On Wed, Jul 29, 2015 at 6:20 PM, Sudeep Holla sudeep.ho...@arm.com wrote:
On 29/07/15 12:19, Jassi Brar wrote:
Assuming the former, let me explain. When a client receives a
response, it can be sure that the request has already been read by the
remote.
On Fri, Jul 31, 2015 at 3:10 PM, Sudeep Holla sudeep.ho...@arm.com wrote:
I forgot to mention, we have a the following description in
mbox_client_txdone which is misleading:
The client/protocol had received some 'ACK' packet and it notifies the
API that the last packet was sent successfully.
On 31/07/15 11:38, Jassi Brar wrote:
On Fri, Jul 31, 2015 at 3:10 PM, Sudeep Holla sudeep.ho...@arm.com wrote:
I forgot to mention, we have a the following description in
mbox_client_txdone which is misleading:
The client/protocol had received some 'ACK' packet and it notifies the
API that
On Wed, Jul 29, 2015 at 6:20 PM, Sudeep Holla wrote:
> On 29/07/15 12:19, Jassi Brar wrote:
>
>> Assuming the former, let me explain. When a client receives a
>> response, it can be sure that the request has already been read by the
>> remote.
>
> Waiting for the response would be too late for
On Wed, Jul 29, 2015 at 6:20 PM, Sudeep Holla sudeep.ho...@arm.com wrote:
On 29/07/15 12:19, Jassi Brar wrote:
Assuming the former, let me explain. When a client receives a
response, it can be sure that the request has already been read by the
remote.
Waiting for the response would be too
On 29/07/15 12:19, Jassi Brar wrote:
On Wed, Jul 29, 2015 at 2:08 PM, Sudeep Holla wrote:
On 29/07/15 09:05, Jassi Brar wrote:
+static int scpi_probe(struct platform_device *pdev)
+{
+ int count, idx, ret;
+ struct resource res;
+ struct scpi_chan *scpi_chan;
+
On Wed, Jul 29, 2015 at 2:08 PM, Sudeep Holla wrote:
> On 29/07/15 09:05, Jassi Brar wrote:
>
>>
>>> +static int scpi_probe(struct platform_device *pdev)
>>> +{
>>> + int count, idx, ret;
>>> + struct resource res;
>>> + struct scpi_chan *scpi_chan;
>>> + struct device
On 29/07/15 09:05, Jassi Brar wrote:
On Thu, Jul 23, 2015 at 4:40 PM, Sudeep Holla wrote:
...
+static int scpi_probe(struct platform_device *pdev)
+{
+ int count, idx, ret;
+ struct resource res;
+ struct scpi_chan *scpi_chan;
+ struct device *dev = >dev;
+
On Thu, Jul 23, 2015 at 4:40 PM, Sudeep Holla wrote:
...
> +static int scpi_probe(struct platform_device *pdev)
> +{
> + int count, idx, ret;
> + struct resource res;
> + struct scpi_chan *scpi_chan;
> + struct device *dev = >dev;
> + struct device_node *np =
On Thu, Jul 23, 2015 at 4:40 PM, Sudeep Holla sudeep.ho...@arm.com wrote:
...
+static int scpi_probe(struct platform_device *pdev)
+{
+ int count, idx, ret;
+ struct resource res;
+ struct scpi_chan *scpi_chan;
+ struct device *dev = pdev-dev;
+ struct
On 29/07/15 09:05, Jassi Brar wrote:
On Thu, Jul 23, 2015 at 4:40 PM, Sudeep Holla sudeep.ho...@arm.com wrote:
...
+static int scpi_probe(struct platform_device *pdev)
+{
+ int count, idx, ret;
+ struct resource res;
+ struct scpi_chan *scpi_chan;
+ struct device
On Wed, Jul 29, 2015 at 2:08 PM, Sudeep Holla sudeep.ho...@arm.com wrote:
On 29/07/15 09:05, Jassi Brar wrote:
+static int scpi_probe(struct platform_device *pdev)
+{
+ int count, idx, ret;
+ struct resource res;
+ struct scpi_chan *scpi_chan;
+ struct device *dev
On 29/07/15 12:19, Jassi Brar wrote:
On Wed, Jul 29, 2015 at 2:08 PM, Sudeep Holla sudeep.ho...@arm.com wrote:
On 29/07/15 09:05, Jassi Brar wrote:
+static int scpi_probe(struct platform_device *pdev)
+{
+ int count, idx, ret;
+ struct resource res;
+ struct scpi_chan
This patch adds support for System Control and Power Interface (SCPI)
Message Protocol used between the Application Cores(AP) and the System
Control Processor(SCP). The MHU peripheral provides a mechanism for
inter-processor communication between SCP's M3 processor and AP.
SCP offers control and
This patch adds support for System Control and Power Interface (SCPI)
Message Protocol used between the Application Cores(AP) and the System
Control Processor(SCP). The MHU peripheral provides a mechanism for
inter-processor communication between SCP's M3 processor and AP.
SCP offers control and
26 matches
Mail list logo
