On 11/12/11 17:10, Jassi Brar wrote:
> On 11 December 2011 20:39, Javi Merino wrote:
What about properly tracking what we have sent to the DMA? Something
like the following (warning *ugly* and untested code ahead, may eat your
kitten):
>>> Yeah, this is like I said 'marke
On 11 December 2011 20:39, Javi Merino wrote:
>>>
>>> What about properly tracking what we have sent to the DMA? Something
>>> like the following (warning *ugly* and untested code ahead, may eat your
>>> kitten):
>>>
>> Yeah, this is like I said 'marker' method. Though we can clean it up a bit.
>
On 11/12/11 10:51, Jassi Brar wrote:
> On Sat, Dec 10, 2011 at 1:20 AM, Javi Merino wrote:
>>
>> What about properly tracking what we have sent to the DMA? Something
>> like the following (warning *ugly* and untested code ahead, may eat your
>> kitten):
>>
> Yeah, this is like I said 'marker' met
On Sat, Dec 10, 2011 at 1:20 AM, Javi Merino wrote:
>
> What about properly tracking what we have sent to the DMA? Something
> like the following (warning *ugly* and untested code ahead, may eat your
> kitten):
>
> diff --git a/arch/arm/common/pl330.c b/arch/arm/common/pl330.c
> index f407a6b..36
On 09/12/11 16:50, Jassi Brar wrote:
> What do you think about ...
>
> diff --git a/arch/arm/common/pl330.c b/arch/arm/common/pl330.c
> index f407a6b..3a51cdd 100644
> --- a/arch/arm/common/pl330.c
> +++ b/arch/arm/common/pl330.c
> @@ -1546,7 +1546,7 @@ int pl330_chan_ctrl(void *ch_id, enum pl330_
On Fri, Dec 9, 2011 at 8:22 PM, Javi Merino wrote:
>
> I think the best solution would be to revert
> ee3f615819404a9438b2dd01b7a39f276d2737f2 and go back to my original
> patch (in the beginning of this thread):
>
> http://article.gmane.org/gmane.linux.ports.arm.kernel/133110
>
> What do you thin
On 09/12/11 14:15, Jassi Brar wrote:
> On Fri, Dec 9, 2011 at 7:11 PM, Javi Merino wrote:
>> On 09/12/11 13:04, Jassi Brar wrote:
>>> Hi Javi,
>>>
>>> On 9 December 2011 17:28, Javi Merino wrote:
Javi, could you please check if you too get the memcpy failure with
dmatest ?
On Fri, Dec 9, 2011 at 7:11 PM, Javi Merino wrote:
> On 09/12/11 13:04, Jassi Brar wrote:
>> Hi Javi,
>>
>> On 9 December 2011 17:28, Javi Merino wrote:
>>>
>>> Javi, could you please check if you too get the memcpy failure with
>>> dmatest ?
>>
Ok, I think I've just reproduced i
On 09/12/11 13:04, Jassi Brar wrote:
> Hi Javi,
>
> On 9 December 2011 17:28, Javi Merino wrote:
>>
>> Javi, could you please check if you too get the memcpy failure with
>> dmatest ?
>
>>> Ok, I think I've just reproduced it in my end with the kernel's dmatest
>>> module. After the f
Hi Javi,
On 9 December 2011 17:28, Javi Merino wrote:
>
> Javi, could you please check if you too get the memcpy failure with
> dmatest ?
>> Ok, I think I've just reproduced it in my end with the kernel's dmatest
>> module. After the first transaction it looks like the dma test wasn
On 07/12/11 20:54, Javi Merino wrote:
> On 07/12/11 10:01, Javi Merino wrote:
>> On 07/12/11 07:52, Kukjin Kim wrote:
>>> Jassi Brar wrote:
On 29 November 2011 15:23, Javi Merino wrote:
>> On Samsung's Exynos4 platform, while testing audio playback with
>>> i2s
>> interfac
On 07/12/11 10:01, Javi Merino wrote:
> On 07/12/11 07:52, Kukjin Kim wrote:
>> Jassi Brar wrote:
>>>
>>> On 29 November 2011 15:23, Javi Merino wrote:
> On Samsung's Exynos4 platform, while testing audio playback with
>> i2s
> interface, the above change causes the playback to
On 07/12/11 07:52, Kukjin Kim wrote:
> Jassi Brar wrote:
>>
>> On 29 November 2011 15:23, Javi Merino wrote:
On Samsung's Exynos4 platform, while testing audio playback with
> i2s
interface, the above change causes the playback to freeze. The
_thrd_active(thrd) call
Jassi Brar wrote:
>
> On 29 November 2011 15:23, Javi Merino wrote:
> >> On Samsung's Exynos4 platform, while testing audio playback with
> >>> i2s
> >> interface, the above change causes the playback to freeze. The
> >> _thrd_active(thrd) call always returns '1' and hence _start(thrd
On 29 November 2011 15:23, Javi Merino wrote:
>> On Samsung's Exynos4 platform, while testing audio playback with
>>> i2s
>> interface, the above change causes the playback to freeze. The
>> _thrd_active(thrd) call always returns '1' and hence _start(thrd)
>>> is
>> not getting cal
On 29/11/11 03:41, Boojin Kim wrote:
> Javi Merino wrote:
>
>
>>>
> On Samsung's Exynos4 platform, while testing audio playback with
>> i2s
> interface, the above change causes the playback to freeze. The
> _thrd_active(thrd) call always returns '1' and hence _start(thrd)
>> is
>
Javi Merino wrote:
> >
> >>> On Samsung's Exynos4 platform, while testing audio playback with
> i2s
> >>> interface, the above change causes the playback to freeze. The
> >>> _thrd_active(thrd) call always returns '1' and hence _start(thrd)
> is
> >>> not getting called.
> >>
> >> If _thrd_active
On 28/11/11 08:23, Boojin Kim wrote:
> Javi Merino wrote:
>
>>> On Samsung's Exynos4 platform, while testing audio playback with i2s
>>> interface, the above change causes the playback to freeze. The
>>> _thrd_active(thrd) call always returns '1' and hence _start(thrd) is
>>> not getting called.
>
Javi Merino wrote:
> > On Samsung's Exynos4 platform, while testing audio playback with i2s
> > interface, the above change causes the playback to freeze. The
> > _thrd_active(thrd) call always returns '1' and hence _start(thrd) is
> > not getting called.
>
> If _thrd_active(thrd) returns '1', tha
On 7 November 2011 16:18, Javi Merino wrote:
> On 05/11/11 19:05, Thomas Abraham wrote:
>> Hi Javi,
>>
>> On 6 October 2011 05:10, Javi Merino wrote:
>>> If two requests have been submitted and one of them is running, if you
>>> call pl330_chan_ctrl(ch_id, PL330_OP_START), there's a window of tim
On 05/11/11 19:05, Thomas Abraham wrote:
> Hi Javi,
>
> On 6 October 2011 05:10, Javi Merino wrote:
>> If two requests have been submitted and one of them is running, if you
>> call pl330_chan_ctrl(ch_id, PL330_OP_START), there's a window of time
>> between the spin_lock_irqsave() and the _state(
Hi Javi,
On 6 October 2011 05:10, Javi Merino wrote:
> If two requests have been submitted and one of them is running, if you
> call pl330_chan_ctrl(ch_id, PL330_OP_START), there's a window of time
> between the spin_lock_irqsave() and the _state() check in which the
> running transaction may fin
22 matches
Mail list logo
