headers
Barry Song | 2 Mar 2010 10:57
Picon

Re: IIO ring buffer

Jonathan,
I know you are changing iio ring buffer. Here a problem to discuss
with you, there are maybe this kind of use cases: the DACs have no
internal clock and buffer, so we need an external bus with continuous
DMA to "play" data flow with constant speed. It is very similar with
alsa driver to play audio by I2S or AC97. ALSA framework is easy to
implement this kind of drivers. But our DACs are not audio cards. Then
in the iio ring buffer core, it seems we also need APIs like
trigger(), pointer(), snd_pcm_period_elapsed()... to get a common
framework. Of course, we can let users to handle blocking in write()
callback like OSS, but alsa-like APIs should be better. So what's your
opinion for that?
If I begin to work on this, I am not sure how much is needed to do to
merge into your new iio ring buffer codes. So if you have some new
codes for reference, it should be better.
Thanks
Barry

On Wed, Feb 24, 2010 at 10:10 PM, Jonathan Cameron <jic23 <at> cam.ac.uk> wrote:
> On 02/24/10 06:42, Song, Barry wrote:
>>
>>
>>> -----Original Message-----
>>> From: Jonathan Cameron [mailto:jic23 <at> cam.ac.uk]
>>> Sent: Tuesday, February 23, 2010 7:45 PM
>>> To: Song, Barry
>>> Cc: jic23 <at> hermes.cam.ac.uk; manuel.stahl <at> iis.fraunhofer.de;
>>> uclinux-dist-devel <at> blackfin.uclinux.org; linux-iio <at> vger.kernel.org
>>> Subject: Re: IIO ring buffer
>>>
(Continue reading)

Permalink | Reply | 6 comments |
headers
J.I. Cameron | 2 Mar 2010 11:45
Picon
Picon
Favicon

Re: IIO ring buffer

Hi Barry,

>I know you are changing iio ring buffer. Here a problem to discuss
>with you, there are maybe this kind of use cases: the DACs have no
>internal clock and buffer, so we need an external bus with continuous
>DMA to "play" data flow with constant speed. It is very similar with
>alsa driver to play audio by I2S or AC97. ALSA framework is easy to
>implement this kind of drivers. But our DACs are not audio cards. Then
>in the iio ring buffer core, it seems we also need APIs like
>trigger(), pointer(), snd_pcm_period_elapsed()... to get a common
>framework.
I have to admit I'm in general a little unclear on how one even goes about
getting dma to occur at a constant speed.  I'm afraid I haven't had much
time to work on improving the ring buffer (though I will try and get a patch
out for one particular bug sometime today - if you get issues in the init
function with spin locks).   Hence, I suggest that you propose any changes
you would like to see in the core, if possible with some code along side
relevant data sheets so those of us not so familiar with this area can
better understand how this would work.

My short term plans for the buffering is to allow use of the new
implementation of kfifo as it allows dma transfers to occur directly into
the buffer.  Obviously this will involve adding a few new bits to the api.

That internal api is certainly far from locked in stone and as long as we
can mend any driver broken by changes, feel free to propose any changes you
like!

> Of course, we can let users to handle blocking in write()
>callback like OSS, but alsa-like APIs should be better. So what's your
(Continue reading)

Permalink | Reply | 5 comments |
headers
Barry Song | 3 Mar 2010 04:26
Picon

Re: IIO ring buffer

DACs like AD5624R/5644R/5664R(http://www.analog.com/en/digital-to-analog-converters/da-converters/ad5624r/products/product.html)
have no clock input and internal buffer. Some users maybe use it to
get discrete analog signals, that means once one data is written to
AD5624R, one new analog signal is output, then we don't need ring
buffer. But some other users maybe want the AD5624R to create
continuous signals with a fixed frequency, then we need use ring
buffer with linked DMA to input data to AD5624R with a constant rate.
This case is same with audio play.
To implement that, we need
1. Split ring buffer to some little fragments, one fragment is a DMA block.
2. Ring buffer core layer must handle the play pointer and user
writing pointer, stop the DMA automatically when user data under-run
flows( valid data is less than one fragment in ring buffer)
3. The DMA interrupt handler in the bottom driver should update the
play pointer by a ring buffer core API to notify the play status.
4. The DMA should support  linked mode, once one DMA block is
finished, another DMA fragment will be enabled by hardware
automatically except that it is disabled due to underflow.
Thanks
Barry

On Tue, Mar 2, 2010 at 6:45 PM, J.I. Cameron <jic23 <at> cam.ac.uk> wrote:
> Hi Barry,
>
>> I know you are changing iio ring buffer. Here a problem to discuss
>> with you, there are maybe this kind of use cases: the DACs have no
>> internal clock and buffer, so we need an external bus with continuous
>> DMA to "play" data flow with constant speed. It is very similar with
>> alsa driver to play audio by I2S or AC97. ALSA framework is easy to
>> implement this kind of drivers. But our DACs are not audio cards. Then
(Continue reading)

Permalink | Reply | 4 comments |
headers
Zhang, Sonic | 3 Mar 2010 06:59
Favicon

Re: IIO ring buffer

I think Barry forgot to mention that this DAC is connect to the CPU via a 3 PIN serial port with SYNC clock
enabled. This serial port controller has DMA master capability and output data at a given clock. The ring
buffer slots and size is better to be configurable and its API should be able to trigger output start/stop
to IIO driver based on data left in the ring.

Sonic 

>-----Original Message-----
>From: uclinux-dist-devel-bounces@... 
>[mailto:uclinux-dist-devel-bounces@...] On 
>Behalf Of Barry Song
>Sent: Wednesday, March 03, 2010 11:26 AM
>To: J.I. Cameron
>Cc: linux-iio@...; 
>uclinux-dist-devel@...; manuel.stahl@...
>Subject: Re: [Uclinux-dist-devel] IIO ring buffer
>
>DACs like 
>AD5624R/5644R/5664R(http://www.analog.com/en/digital-to-analog-
>converters/da-converters/ad5624r/products/product.html)
>have no clock input and internal buffer. Some users maybe use 
>it to get discrete analog signals, that means once one data is 
>written to AD5624R, one new analog signal is output, then we 
>don't need ring buffer. But some other users maybe want the 
>AD5624R to create continuous signals with a fixed frequency, 
>then we need use ring buffer with linked DMA to input data to 
>AD5624R with a constant rate.
>This case is same with audio play.
>To implement that, we need
>1. Split ring buffer to some little fragments, one fragment is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Cameron | 4 Mar 2010 13:33
Picon
Picon
Favicon

Re: IIO ring buffer

Hi Barry,

Sorry for the slow reply, been busy with the whole ALS thing
(see lkml if you are interested) and chasing down some rtc issues.

On 03/03/10 03:26, Barry Song wrote:
> DACs like AD5624R/5644R/5664R(http://www.analog.com/en/digital-to-analog-converters/da-converters/ad5624r/products/product.html)
> have no clock input and internal buffer. Some users maybe use it to
> get discrete analog signals, that means once one data is written to
> AD5624R, one new analog signal is output, then we don't need ring
> buffer.
Makes sense, I guess for these we provide a sysfs type interface.
> But some other users maybe want the AD5624R to create
> continuous signals with a fixed frequency, then we need use ring
> buffer with linked DMA to input data to AD5624R with a constant rate.
> This case is same with audio play.
> To implement that, we need
> 1. Split ring buffer to some little fragments, one fragment is a DMA block.
Makes sense, though we probably need to be a little careful 
as not spi implementations are going to do this via dma.
> 2. Ring buffer core layer must handle the play pointer and user
> writing pointer, stop the DMA automatically when user data under-run
> flows( valid data is less than one fragment in ring buffer)
Probably a fifo rather than a ring buffer, but it doesn't change your
point! At the moment I'm not seeing much shared functionality with the
rest of IIO.  Perhaps we treat DAC elements in a similar way to triggers?
That is a device may register them without registering anything else.
Will keep matters nice and slim if we have devices such as this one that
don't have any inputs.  The only disadvantage I can see is when we have
interesting interactions between the dac's and inputs (such as a feedback
(Continue reading)

Permalink | Reply | 2 comments |
headers
Thomas Petazzoni | 4 Mar 2010 15:08
Favicon
Gravatar

Re: Wakeup from hibernation on BF548 EZKit

Hello,

On Thu, 25 Feb 2010 12:59:11 +0100
Thomas Petazzoni <thomas.petazzoni@...> wrote:

> However, I tried it, and doesn't seem to make any difference. On the
> bf548-ezkit, the keypad is connected to PortD bits 8 to 11 for the
> rows and bits 12 to 15 for the columns.
> 
> So I did :
> 
>  echo 0xff00 > /debug/blackfin/Port_D/PORTD_FER
> 
> in order to switch PortD bits 8 to 15 to GPIO mode.
> 
> And then :
> 
>  echo 0xff00 > /debug/blackfin/Port_D/PORTD_SET
> 
> in order to put them in the 1 state.
> 
> (This debugfs thing seems to be working since I managed to blink some
> LEDs connected to PortG using it).
> 
> And finally, triggerred the hibernation. It goes out of hibernation
> immediatly, and the reason of the wakeup is again the keypad:

I'm still struggling on this, with no success so far.

My understanding is that I should not enable the wake-up on the keypad
(Continue reading)

Permalink | Reply | 15 comments |
headers
Hennerich, Michael | 4 Mar 2010 15:23
Favicon

Re: Wakeup from hibernation on BF548 EZKit

Thomas Petazzoni wrote on 2010-03-04:
> Hello,
>
> On Thu, 25 Feb 2010 12:59:11 +0100
> Thomas Petazzoni <thomas.petazzoni@...> wrote:
>
>> However, I tried it, and doesn't seem to make any difference. On the
>> bf548-ezkit, the keypad is connected to PortD bits 8 to 11 for the
>> rows and bits 12 to 15 for the columns.
>>
>> So I did :
>>
>>  echo 0xff00 > /debug/blackfin/Port_D/PORTD_FER
>> in order to switch PortD bits 8 to 15 to GPIO mode.
>>
>> And then :
>>
>>  echo 0xff00 > /debug/blackfin/Port_D/PORTD_SET
>> in order to put them in the 1 state.
>>
>> (This debugfs thing seems to be working since I managed to blink
>> some LEDs connected to PortG using it).
>>
>> And finally, triggerred the hibernation. It goes out of hibernation
>> immediatly, and the reason of the wakeup is again the keypad:
>
> I'm still struggling on this, with no success so far.
>
> My understanding is that I should not enable the wake-up on the keypad
> interrupt, but rather enable the wake-up on GPIO interrupt (and
(Continue reading)

Permalink | Reply | 14 comments |
headers
Hennerich, Michael | 4 Mar 2010 15:30
Favicon

Re: Wakeup from hibernation on BF548 EZKit

Hennerich, Michael wrote on 2010-03-04:
> Thomas Petazzoni wrote on 2010-03-04:
>> Hello,
>>
>> On Thu, 25 Feb 2010 12:59:11 +0100
>> Thomas Petazzoni <thomas.petazzoni@...> wrote:
>>
>>> However, I tried it, and doesn't seem to make any difference. On
>>> the bf548-ezkit, the keypad is connected to PortD bits 8 to 11 for
>>> the rows and bits 12 to 15 for the columns.
>>>
>>> So I did :
>>>
>>>  echo 0xff00 > /debug/blackfin/Port_D/PORTD_FER in order to switch
>>> PortD bits 8 to 15 to GPIO mode.
>>>
>>> And then :
>>>
>>>  echo 0xff00 > /debug/blackfin/Port_D/PORTD_SET in order to put
>>> them in the 1 state.
>>>
>>> (This debugfs thing seems to be working since I managed to blink some
>>> LEDs connected to PortG using it).
>>>
>>> And finally, triggerred the hibernation. It goes out of hibernation
>>> immediatly, and the reason of the wakeup is again the keypad:
>>
>> I'm still struggling on this, with no success so far.
>>
>> My understanding is that I should not enable the wake-up on the keypad
(Continue reading)

Permalink | Reply | 13 comments |
headers
Thomas Petazzoni | 4 Mar 2010 19:14
Favicon
Gravatar

Re: Wakeup from hibernation on BF548 EZKit

Hello Michael,

On Thu, 4 Mar 2010 14:30:16 +0000
"Hennerich, Michael" <Michael.Hennerich@...> wrote:

> Sorry I didn't read the indented part of you previous email - since I
> thought I read that before. So it looks like you already tried what I
> suggested. Maybe the description in the PRM is incomplete.
> 
> Try to configure the columns as GPIO output - set to 0.

Thanks for your help. I already tried to configure both the rows and
columns as GPIO and I'm not having success. To make it clear, here is
the patch I'm having at the moment (see below the patch for
explanations) :

=======================================================================
commit 204c55664ca0640c74082e99f33ad15a1bd26d3d
Author: Thomas Petazzoni <thomas.petazzoni@...>
Date:   Thu Mar 4 19:03:58 2010 +0100

    keyboard driver changes

diff --git a/drivers/input/keyboard/bf54x-keys.c b/drivers/input/keyboard/bf54x-keys.c
index 691db80..a8c9544 100644
--- a/drivers/input/keyboard/bf54x-keys.c
+++ b/drivers/input/keyboard/bf54x-keys.c
 <at>  <at>  -364,13 +364,44  <at>  <at>  static int __devexit bfin_kpad_remove(struct platform_device *pdev)
 static int bfin_kpad_suspend(struct platform_device *pdev, pm_message_t state)
 {
(Continue reading)

Permalink | Reply | 12 comments |
headers
Hennerich, Michael | 4 Mar 2010 22:21
Favicon

Re: Wakeup from hibernation on BF548 EZKit

Thomas Petazzoni wrote on 2010-03-04:
> Hello Michael,
>
> On Thu, 4 Mar 2010 14:30:16 +0000
> "Hennerich, Michael" <Michael.Hennerich@...> wrote:
>
>> Sorry I didn't read the indented part of you previous email - since
>> I thought I read that before. So it looks like you already tried
>> what I suggested. Maybe the description in the PRM is incomplete.
>>
>> Try to configure the columns as GPIO output - set to 0.
>
> Thanks for your help. I already tried to configure both the rows and
> columns as GPIO and I'm not having success. To make it clear, here is
> the patch I'm having at the moment (see below the patch for
> explanations) :
>
> ====================================================================== =
> commit 204c55664ca0640c74082e99f33ad15a1bd26d3d Author: Thomas Petazzoni
> <thomas.petazzoni@...> Date:   Thu Mar 4 19:03:58 2010
> +0100
>
>     keyboard driver changes
> diff --git a/drivers/input/keyboard/bf54x-keys.c
> b/drivers/input/keyboard/bf54x-keys.c index 691db80..a8c9544 100644 ---
> a/drivers/input/keyboard/bf54x-keys.c +++
> b/drivers/input/keyboard/bf54x-keys.c  <at>  <at>  -364,13 +364,44  <at>  <at>  static int
> __devexit bfin_kpad_remove(struct platform_device *pdev)  static int
> bfin_kpad_suspend(struct platform_device *pdev, pm_message_t state)  {
>       struct bf54x_kpad *bf54x_kpad = platform_get_drvdata(pdev);
(Continue reading)

Permalink | Reply | 11 comments |

Gmane