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
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 the same
Hi Jassi,
On 04/26/2013 11:51 PM, Jassi Brar wrote:
Hi Suman,
On 26 April 2013 03:59, Suman Anna s-a...@ti.com 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
Hi
On 29 April 2013 21:30, Suman Anna s-a...@ti.com 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 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 Jassi,
On 04/25/2013 10:46 PM, Jassi Brar wrote:
Hi Suman,
On 26 April 2013 03:59, Suman Anna s-a...@ti.com 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
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 Suman,
On 26 April 2013 03:59, Suman Anna s-a...@ti.com 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
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
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
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
>>
Jassi,
On 04/25/2013 12:20 AM, Jassi Brar wrote:
On 25 April 2013 04:46, Suman Anna s-a...@ti.com 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
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
Hi Suman,
On 26 April 2013 03:59, Suman Anna s-a...@ti.com 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
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
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
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
>
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
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.
>>>
>>>
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, Sumans-a...@ti.com 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
Hi Loic,
On 24 April 2013 13:09, Loic PALLARDY loic.palla...@st.com 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
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, Sumans-a...@ti.com wrote:
Documentation wise, we'd need documentation for what we finally wanna have,
not the current implementation.
Hi Jassi,
On 04/24/2013 09:59 AM, Jassi Brar wrote:
Hi Loic,
On 24 April 2013 13:09, Loic PALLARDYloic.palla...@st.com 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
Hi -
On 24 April 2013 13:38, Loic PALLARDY loic.palla...@st.com 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
Jassi,
On 04/24/2013 03:56 AM, Jassi Brar wrote:
Hi -
On 24 April 2013 13:38, Loic PALLARDY loic.palla...@st.com 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
On 25 April 2013 04:46, Suman Anna s-a...@ti.com 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
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
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
Hi Jassi,
On Mon, Apr 22, 2013 at 9:26 PM, Anna, Suman s-a...@ti.com 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
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
Hi Suman,
[please limit replies to not more than 80 columns per line]
On 24 April 2013 00:50, Anna, Suman s-a...@ti.com 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 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
>
> 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
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 s-a...@ti.com wrote:
Hi,
Please find the updated mailbox patch series for pulling into
Hi Suman,
On Mon, Apr 22, 2013 at 9:26 PM, Anna, Suman s-a...@ti.com 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
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
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 s-a...@ti.com wrote:
Hi,
Please find the updated mailbox patch series for pulling into linux-next.
> >
> > 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
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
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
On Wed, Mar 13, 2013 at 4:23 AM, Suman Anna s-a...@ti.com 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
Hi Suman,
On Tue, 12 Mar 2013 22:23:41 -0500 Suman Anna s-a...@ti.com 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
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-prcmu-mailbox ?
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
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
52 matches
Mail list logo
