Re: quick help on PDM DAC driver

Re: quick help on PDM DAC driver

[Naidu Tellapati]

Hi Thierry,

Many thanks for your quick response.

There are total 4 blocks available on our SOC, those could be used
either as PWM DAC (or) PDM DAC blocks. If one of them is used as a PWM
DAC block, it can’t be used as a PDM block. As an example if the user
wants, based on the configuration from the device tree, he could use
all the 4 blocks as PWM DAC blocks (or) all 4 as PDM DAC blocks (or) 2
PDM DAC blocks & 2 PDM blocks (or) any combination of these two types.
Since there are 4 blocks available, total 16 combinations of these two
types (PDM & PWM) are possible.

For example based on sort of channel mask defined in the device tree,
If the user wishes to use the blocks as PWM DAC blocks, my driver
exactly fits into linux PWM frame work. As usual, the PWM blocks
expect the user to configure all the required configuration attributes
(frequency, duty-cycle etc) as defined by the Linux PWM Framework.

Bu if the user wishes to use the blocks as PDM DAC blocks, my driver
does not exactly fit into PWM framework. In this case the PDM DAC
block takes only a 12 bit value (as input) program in one of the SOC
configuration registers as an
input and based on some simple internal logic, the block produces a
form of analogue output according to the relative density of output
pulses to the intended analogue signal amplitude. The width of the
output pulse varies with the 12-bit value we program in one of the SOC
configuration registers.

If the user wants to change the width of the output pulse, he has to
program different values for 12-bit value. For example different
12-bit input values 0xFFF, 0x800, 0x0800, 0x0080, 0x0008, 0x001 will
produce output pulses of totally different widths.

The idea is to implement a driver which could be upstream-able. I am
trying to understand how I could use the existing PWM Framework to
achieve this. If you think this does not fit into existing PWM
Framework, I request you to please suggest me some better approach.

Thanks in advance,

Regards,
Naidu.















On Mon, Sep 22, 2014 at 3:18 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Sun, Sep 21, 2014 at 04:15:42PM +0530, Naidu Tellapati wrote:
>> Hi Thierry and all,
>>
>> Many thanks in advance. My name is Naidu Tellapati. I am from India.
>>
>> The Pulse Density Modulation DAC which we have on our SOC produces a
>> form of analogue output according to the relative density of output
>> pulses to the intended analogue signal amplitude. The 4 PDM outputs
>> are provided that can be used to control targets such as an LCD
>> backlight. After going through Linux PWM documentation, I understand
>> that our PDM DAC driver does not exactly fit into the Linux PWM
>> framework.
>>
>> The PDM DAC block takes only input clock and a 12 bit value (as input
>> pulse) configured in one of the SOC configuration registers as an
>> input and based on some simple internal logic, the block produces a
>> form of analogue output according to the relative density of output
>> pulses to the intended analogue signal amplitude. The PDM DAC block
>> won't take duty_cycle as input configuration parameters. Instead it
>> takes 12 bit value (input pulse) as a configuration parameter.
>
> What does this 12-bit value represent? It sounds to me like it's exactly
> what the duty-cycle is for other devices. And if it's the only parameter
> then it seems to me like the device simply has a fixed period.
>
> Both of the above should be possible to do in the current PWM framework.
> For example, you could compute the period (in ns) of the PDM based on
> the input clock frequency and inter/extrapolate the 12-bit parameter to
> range [0..period].
>
> You can also add checks to refuse setting a period in pwm_config() that
> doesn't correspond to the fixed period derived from the input clock.
>
> Thierry

Re: quick help on PDM DAC driver

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2754 bytes --]

On Mon, Sep 22, 2014 at 04:37:11PM +0530, Naidu Tellapati wrote:
> Hi Thierry,
> 
> Many thanks for your quick response.
> 
> There are total 4 blocks available on our SOC, those could be used
> either as PWM DAC (or) PDM DAC blocks. If one of them is used as a PWM
> DAC block, it can’t be used as a PDM block. As an example if the user
> wants, based on the configuration from the device tree, he could use
> all the 4 blocks as PWM DAC blocks (or) all 4 as PDM DAC blocks (or) 2
> PDM DAC blocks & 2 PDM blocks (or) any combination of these two types.
> Since there are 4 blocks available, total 16 combinations of these two
> types (PDM & PWM) are possible.
> 
> For example based on sort of channel mask defined in the device tree,
> If the user wishes to use the blocks as PWM DAC blocks, my driver
> exactly fits into linux PWM frame work. As usual, the PWM blocks
> expect the user to configure all the required configuration attributes
> (frequency, duty-cycle etc) as defined by the Linux PWM Framework.
> 
> Bu if the user wishes to use the blocks as PDM DAC blocks, my driver
> does not exactly fit into PWM framework. In this case the PDM DAC
> block takes only a 12 bit value (as input) program in one of the SOC
> configuration registers as an
> input and based on some simple internal logic, the block produces a
> form of analogue output according to the relative density of output
> pulses to the intended analogue signal amplitude. The width of the
> output pulse varies with the 12-bit value we program in one of the SOC
> configuration registers.
> 
> If the user wants to change the width of the output pulse, he has to
> program different values for 12-bit value. For example different
> 12-bit input values 0xFFF, 0x800, 0x0800, 0x0080, 0x0008, 0x001 will
> produce output pulses of totally different widths.

What's the relation of the 12-bit value to the resulting signal? Does
each bit in the value correspond to a fixed interval so that a one is
high and 0 low? That is, does:

	0x800 produce -___________
	0x080 produce ____-_______
	0x008 produce ________-___
	0x444 produce _-___-___-__
	0x555 produce _-_-_-_-_-_-
	0x00f produce ________----
	...

? If so you can probably still mimic PWM behaviour by subdividing the
duty-cycle into 12 intervals.

> The idea is to implement a driver which could be upstream-able. I am
> trying to understand how I could use the existing PWM Framework to
> achieve this. If you think this does not fit into existing PWM
> Framework, I request you to please suggest me some better approach.

Even if you can't mimic PWM using PDM it's still possible to use a PWM
driver only if all channels are configured in PWM mode.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: quick help on PDM DAC driver

[Naidu Tellapati]

Hi Thierry,

Many thanks for your continued help in this regard.

Each bit in my 12-bit input value to the PDM block does not in anyway
corresponds to fixed interval. My hardware PDM block works with the
following simple logic

counter [12:0] = counter [11:0] + pluse_in [11:0]     /* pulse_in is a
12-bit input value to PDM block */
pdm_out = counter [12]

The above logic runs for every pdm_clk cycle.

And hence I am of the opinion that I need to have a Linux PDM
Framework which is similar to PWM Framework and which provides
pulse_in as device attribute to the Linux User Space.

Please correct me if my understand is wrong. Please also suggest me if
there is a better approach. The plan is to write an upstream-ble PDM
driver.

Thanks in advance,

Regards,
Naidu.



















On Mon, Sep 22, 2014 at 4:57 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Mon, Sep 22, 2014 at 04:37:11PM +0530, Naidu Tellapati wrote:
>> Hi Thierry,
>>
>> Many thanks for your quick response.
>>
>> There are total 4 blocks available on our SOC, those could be used
>> either as PWM DAC (or) PDM DAC blocks. If one of them is used as a PWM
>> DAC block, it can’t be used as a PDM block. As an example if the user
>> wants, based on the configuration from the device tree, he could use
>> all the 4 blocks as PWM DAC blocks (or) all 4 as PDM DAC blocks (or) 2
>> PDM DAC blocks & 2 PDM blocks (or) any combination of these two types.
>> Since there are 4 blocks available, total 16 combinations of these two
>> types (PDM & PWM) are possible.
>>
>> For example based on sort of channel mask defined in the device tree,
>> If the user wishes to use the blocks as PWM DAC blocks, my driver
>> exactly fits into linux PWM frame work. As usual, the PWM blocks
>> expect the user to configure all the required configuration attributes
>> (frequency, duty-cycle etc) as defined by the Linux PWM Framework.
>>
>> Bu if the user wishes to use the blocks as PDM DAC blocks, my driver
>> does not exactly fit into PWM framework. In this case the PDM DAC
>> block takes only a 12 bit value (as input) program in one of the SOC
>> configuration registers as an
>> input and based on some simple internal logic, the block produces a
>> form of analogue output according to the relative density of output
>> pulses to the intended analogue signal amplitude. The width of the
>> output pulse varies with the 12-bit value we program in one of the SOC
>> configuration registers.
>>
>> If the user wants to change the width of the output pulse, he has to
>> program different values for 12-bit value. For example different
>> 12-bit input values 0xFFF, 0x800, 0x0800, 0x0080, 0x0008, 0x001 will
>> produce output pulses of totally different widths.
>
> What's the relation of the 12-bit value to the resulting signal? Does
> each bit in the value correspond to a fixed interval so that a one is
> high and 0 low? That is, does:
>
>         0x800 produce -___________
>         0x080 produce ____-_______
>         0x008 produce ________-___
>         0x444 produce _-___-___-__
>         0x555 produce _-_-_-_-_-_-
>         0x00f produce ________----
>         ...
>
> ? If so you can probably still mimic PWM behaviour by subdividing the
> duty-cycle into 12 intervals.
>
>> The idea is to implement a driver which could be upstream-able. I am
>> trying to understand how I could use the existing PWM Framework to
>> achieve this. If you think this does not fit into existing PWM
>> Framework, I request you to please suggest me some better approach.
>
> Even if you can't mimic PWM using PDM it's still possible to use a PWM
> driver only if all channels are configured in PWM mode.
>
> Thierry

Re: quick help on PDM DAC driver

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]

On Mon, Sep 22, 2014 at 07:28:43PM +0530, Naidu Tellapati wrote:
> Hi Thierry,
> 
> Many thanks for your continued help in this regard.
> 
> Each bit in my 12-bit input value to the PDM block does not in anyway
> corresponds to fixed interval. My hardware PDM block works with the
> following simple logic
> 
> counter [12:0] = counter [11:0] + pluse_in [11:0]     /* pulse_in is a
> 12-bit input value to PDM block */
> pdm_out = counter [12]
> 
> The above logic runs for every pdm_clk cycle.

I don't see how this could reasonably fake a PWM. The best you can
probably get is a 0%, 50% and 100% duty-cycles.

> And hence I am of the opinion that I need to have a Linux PDM
> Framework which is similar to PWM Framework and which provides
> pulse_in as device attribute to the Linux User Space.

Given the peculiarity of the device I don't think adding a framework is
necessary. But you could perhaps add a driver to drivers/misc that
exposes the pulse_in parameter in sysfs.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: quick help on PDM DAC driver

[Naidu Tellapati]

Hi Thierry,

Many thanks for your continued help. We really appreciate it. We use
Linux PWM Framework for our PWM driver. And probably add our PDM
driver to drivers/misc.

Thanks again.

Regards,
Naidu.




On Tue, Sep 23, 2014 at 12:57 PM, Thierry Reding
<thierry.reding@gmail.com> wrote:
> On Mon, Sep 22, 2014 at 07:28:43PM +0530, Naidu Tellapati wrote:
>> Hi Thierry,
>>
>> Many thanks for your continued help in this regard.
>>
>> Each bit in my 12-bit input value to the PDM block does not in anyway
>> corresponds to fixed interval. My hardware PDM block works with the
>> following simple logic
>>
>> counter [12:0] = counter [11:0] + pluse_in [11:0]     /* pulse_in is a
>> 12-bit input value to PDM block */
>> pdm_out = counter [12]
>>
>> The above logic runs for every pdm_clk cycle.
>
> I don't see how this could reasonably fake a PWM. The best you can
> probably get is a 0%, 50% and 100% duty-cycles.
>
>> And hence I am of the opinion that I need to have a Linux PDM
>> Framework which is similar to PWM Framework and which provides
>> pulse_in as device attribute to the Linux User Space.
>
> Given the peculiarity of the device I don't think adding a framework is
> necessary. But you could perhaps add a driver to drivers/misc that
> exposes the pulse_in parameter in sysfs.
>
> Thierry