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
>>> controllers like this out there.
>>>
>
Hi Jassi,
On 04/26/2013 11:51 PM, Jassi Brar wrote:
> 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
Hi Andy,
On 04/26/2013 08:48 PM, Andy Green wrote:
> 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 t
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 done in TI's framework.
>> A controller
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
Hi Jassi,
On 04/25/2013 10:46 PM, Jassi Brar wrote:
> 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
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 configurable based on the c
On 26/04/13 06:29, the mail apparently from Suman Anna included:
Hi -
3. Shareable/exclusive nature of a mailbox. If it is shareable, then
duplicating the behavior between clients is not worth it, and this
should be absorbed into the respective controller driver.
I think the mailbox should be
Jassi,
On 04/25/2013 12:20 AM, Jassi Brar wrote:
> 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
>> t
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 client tried to send
Jassi,
On 04/24/2013 03:56 AM, Jassi Brar wrote:
> 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 the
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 the non/atomic requirements
> (at
Hi Jassi,
On 04/24/2013 09:59 AM, Jassi Brar wrote:
> 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
Hi Jassi,
On 04/24/2013 06:39 AM, Jassi Brar wrote:
> 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.
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 Jassi, Suman,
On 04/23/2013 09:20 PM, Anna, Suman wrote:
> Hi Jassi,
>
>>
>> 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
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:-
>>
>>
On 24/04/13 03:20, the mail apparently from Anna, Suman included:
Hi Suman -
This series missed the 3.9 merge window, and is currently slated for
getting merged into 3.10. The PL320 made it into 3.9 itself (I wasn't
aware of it until I saw it in mainline) and created the
drivers/mailbox folder.
Hi Jassi,
>
> 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 T
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
>
> 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
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
> >
> > Stephen,
> > I have hosted the series at [3]. Can you pull this into linux-next
> > sometime next week?
>
> > [3] https://github.com/sumananna/mailbox/commits/dbx500-prcmu-mailbox
>
> Please quote git URLs ... I guessed you meant
> git://github.com/sumananna/mailbox.git, branch dbx500-prc
Hi Suman,
On Tue, 12 Mar 2013 22:23:41 -0500 Suman Anna wrote:
>
> Stephen,
> I have hosted the series at [3]. Can you pull this into linux-next
> sometime next week?
> [3] https://github.com/sumananna/mailbox/commits/dbx500-prcmu-mailbox
Please quote git URLs ... I guessed you meant
git://gith
On Wed, Mar 13, 2013 at 4:23 AM, Suman Anna wrote:
> Please find the updated mailbox patch series for pulling into linux-next.
> The series is rebased on top of 3.9-rc2, and includes one new patch to
> rename an existing mailbox.h added as part of the highbank cpufreq
> support for 3.9 merge wind
Hi,
Please find the updated mailbox patch series for pulling into linux-next.
The series is rebased on top of 3.9-rc2, and includes one new patch to
rename an existing mailbox.h added as part of the highbank cpufreq
support for 3.9 merge window [1].
The rest of the patches are mostly unchanged fr
26 matches
Mail list logo
