lkml.org 
[lkml]   [2013]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCHv3 00/14] drivers: mailbox: framework creation
On 27/04/13 09:04, the mail apparently from Suman Anna included:

Hi Suman -

> Even though both the scenarios look very similar, I believe there are
> some slight differences. All the devices belonging to a controller may
> not be of the same type (meaning, intended towards the same remote or be
> used interchangeably with one another). It is definitely possible if you
> have a similar scenario to the DMA physical channels and your remote
> rx interrupt can identify the device/channel to process. This would be
> very much dependent on the architecture of a controller. The particular
> example that I have in mind is s/w clients between the same set of
> remote and host entities using the same device - the send part is anyway
> arbitrated by the controller, and the same received message can be
> delivered to the clients, with the clients making the decision whether
> the packet belongs to them or not. I agree that all remote-ends will not
> be able to cope up intermixed requests, but isn't this again a
> controller architecture dependent?

Maybe it's helpful to describe our situation more concretely, because
the problem is not coming from "the architecture of the [mailbox]
controller".

In the SoC we work on clock and subsystem power control registers, a
serial bus, and some other assets are not directly accessible from
Linux. We must ask a coprocessor to operate these for us, using the
mailbox.

So at any one time, the clock driver or voltagedomain driver for the SoC
may want to own the mailbox and perform one or more operations over it
synchronously, in some cases on the remote side involving transactions
on a serial bus. We don't want other transactions to be occurring while
we wait for the serial bus to complete what the driver who started that
asked for, for example.

We can cope with this by having an outer driver mediate access to the
mailbox. But then there are multiple sync primitives like completions
and notifiers per operation, because your core already does this.

In short the FIFO + sync operations approach your core implements
doesn't fit our use case. That can be our problem, in which case we'll
live with the outer mediation driver on top of the mailbox, or it can be
a sign the fixed choice of FIFO + sync operations in your core did not
quite hit the nail on the head to really model all the facets of legit
mailbox usage.

At least, this real scenario should be interesting to think about before
rejecting ^^

-Andy

--
Andy Green | Fujitsu Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2013-04-27 04:01    [W:2.755 / U:0.856 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site