Re: [PATCH 1/2] drivers: pwm: core: implement pwm mode
Hi Andy, On 28.05.2017 01:11, Andy Shevchenko wrote: > On Tue, May 9, 2017 at 3:15 PM, Claudiu Beznea > wrote: >> Extends PWM framework to support PWM modes. The currently >> implemented PWM modes were called PWM complementary mode >> and PWM push-pull mode. For devices that have more than one >> output per PWM channel: >> - PWM complementary mode is standard working mode; in PWM >> complementary mode the rising and falling edges of the >> channels outputs have opposite levels, same duration and >> same starting time. >> - in PWM push-pull mode the channles outputs has same levels, >> same duration and the rising edges are delayed until the >> beginning of the next period. >> A new member was added in pwm_state structure in order to >> keep the new PWM argument. > > To me it sound over-engineered. > > It looks like polarity type Could you, please, give me more details on this? I don't understand your point. The PWM controller I worked with has more than one physical output per PWM channel (e.g. a linux PWM channel has 2 output pins, as you said below, one with polarity P, the other one with polarity !P). Different controllers could be configured to generate different kind of signals. PWM push-pull signal type is one of these and is a common characteristic. This kind of signal could be used, e.g., in half-bridge converter applications where you need delays between positive fronts of PWM signals which drives the transistors. It is a common characteristic of PWM controllers which is the reason I tried to implement it. The push-pull signal type looks like this in case of a controller with 2 outputs per PWM channel: __ __ channel Xa __| || | __ __ channel Xb | || |__ <--T--> > > I dunno if PWM supports linked / virtual channels, but it would be like that > > channel X (polarity P) effectively is > > channel Xa (polarity P) / channel Xb (polarity !P)> > and vise versa. The controller I worked for, the Atmel one, support 4 linux channels, but every channel has 2 physical outputs, 2 pins which outputs, by default, a signal with polarity P and a signal with polarity !P, exactly how you said. I called this in my patch the "complementary" mode. Signals looks like this: ________ channel Xa __| |__| |__| |__| |__ __________ channel Xb |__| |__| |__| |__| <--T--> > > Moreover, mode in your case doesn't fit to GPIO style of output which > would be emulated or native mode for PWM For the PWM controller I worked for, one linux PWM channel outputs on 2 physical pins. Those 2 pins are requested from pin controller to be used by PWM controller. The PWM controller is the one which generate the signal form on those pins. Could you please give more details on what what are you saying above? (we have already a use case > and one driver implements that). Could you, please, give me the driver name you are talking about? On PWM drivers I found only one driver which is started in push-pull, the drivers/pwm/pwm-bcm-kona.c one. The idea with the patches I send was to have a chip which could be user configurable to let the user choose how the chip to work. Thank you, Claudiu Beznea > > GPIO type of output is, obviously, duty=100% in case of emulation, > though separate state for HW assisted kind of that. > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] drivers: pwm: core: implement pwm dead-times
Hi Andy, On 28.05.2017 01:28, Andy Shevchenko wrote: > On Tue, May 9, 2017 at 11:19 AM, Claudiu Beznea > wrote: >> Extends PWM framework to support PWM dead-times. >> The notions introduced are rising edge dead-time >> and falling edge dead-time. These are useful for >> PWM controllers with channels that have more than >> one outputs. >> The implementation add sysfs interface for >> configuration. It extends the pwm_state structure >> with two new members which keeps the values for >> dead-times. >> There were no additions in device tree for PWM channels >> initialized by device tree. > > AFAIU it's effectively called phase of the signal. It is actually a delay introduce by the PWM controller between it's outputs. As I said in cover letter, for PWM controllers with 2 output signals per channel (these signals are on different physical pins), this dead-time is the delay introduced b/w these two outputs. The term is a PWM literature specific. These delays are useful when PWM drives a half bridge converter where you need delays b/w positive edges of the signals which drivers the transistors to avoid shoot through scenarios. > It looks to me much simpler if you allow to have linked / virtual > channels instead of creating a lot of (duplicated) properties.My linked > channels (the 2 outputs per PWM channel) are PWM controller specifics. The standard output of these linked channels is as follows: ________ channel Xa __| |__| |__| |__| |__ __________ channel Xb |__| |__| |__| |__| <--T--> This is the default output. To be able to use the controller in applications which needs delays b/w the fronts of this outputs I introduced the dead-time configuration. This allow the user to set it's PWM output as he needs in his setup (these dead-times, delays, if PWM is used e.g. in half bridge converters, depends on the transistors used). Thank you, Claudiu Beznea > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] drivers: pwm: core: implement pwm mode
Hello Thierry,
I know you may be very busy but do you have any resolution regarding
this series and the one with title
"[PATCH v2 0/2] extends PWM framework to support PWM dead-times"
Thank you,
Claudiu
On 09.05.2017 15:15, Claudiu Beznea - M18063 wrote:
> Extends PWM framework to support PWM modes. The currently
> implemented PWM modes were called PWM complementary mode
> and PWM push-pull mode. For devices that have more than one
> output per PWM channel:
> - PWM complementary mode is standard working mode; in PWM
> complementary mode the rising and falling edges of the
> channels outputs have opposite levels, same duration and
> same starting time.
> - in PWM push-pull mode the channles outputs has same levels,
> same duration and the rising edges are delayed until the
> beginning of the next period.
> A new member was added in pwm_state structure in order to
> keep the new PWM argument.
> For PWM channels with inputs in DT, the mode could also be
> passed via DT. No new extra field need to be added in device
> tree; since the signal polarity is passed as a flag via DT,
> the field used to pass information for PWM channel polarity
> via DT is also used by PWM mode. Since, for the moment, only
> the complementary and push-pull modes are implemented, only
> one bit in flags used to pass polarity could also be used for
> PWM mode. The other drivers are not affected by this change.
>
> Signed-off-by: Claudiu Beznea
> ---
> Documentation/pwm.txt | 24 +---
> drivers/pwm/core.c| 13 +--
> drivers/pwm/sysfs.c | 52
> +++
> include/dt-bindings/pwm/pwm.h | 1 +
> include/linux/pwm.h | 37 --
> 5 files changed, 120 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt
> index 789b27c..1b6fc59 100644
> --- a/Documentation/pwm.txt
> +++ b/Documentation/pwm.txt
> @@ -59,9 +59,9 @@ In addition to the PWM state, the PWM API also exposes PWM
> arguments, which
> are the reference PWM config one should use on this PWM.
> PWM arguments are usually platform-specific and allows the PWM user to only
> care about dutycycle relatively to the full period (like, duty = 50% of the
> -period). struct pwm_args contains 2 fields (period and polarity) and should
> -be used to set the initial PWM config (usually done in the probe function
> -of the PWM user). PWM arguments are retrieved with pwm_get_args().
> +period). struct pwm_args contains 3 fields (period, polarity and mode) and
> +should be used to set the initial PWM config (usually done in the probe
> +function of the PWM user). PWM arguments are retrieved with pwm_get_args().
>
> Using PWMs with the sysfs interface
> ---
> @@ -100,6 +100,24 @@ enable - Enable/disable the PWM signal (read/write).
> 0 - disabled
> 1 - enabled
>
> +mode - Set PWM signal type (for channels with more than one output
> + per channel)
> + complementary - for an output signal as follow:
> + ________
> +PWMH1 __| |__| |__| |__| |__
> + __________
> +PWML1 |__| |__| |__| |__|
> +<--T-->
> + Where T is the signal period.
> +
> + push-pull - for an output signal as follows:
> + __ __
> +PWMH1 __| || |
> + __ __
> +PWML1 | || |__
> +<--T-->
> + Where T is the signal period.
> +
> Implementing a PWM driver
> -
>
> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> index a0860b3..4efc92d 100644
> --- a/drivers/pwm/core.c
> +++ b/drivers/pwm/core.c
> @@ -154,9 +154,14 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc, const
> struct of_phandle_args *args)
>
> pwm->args.period = args->args[1];
> pwm->args.polarity = PWM_POLARITY_NORMAL;
> + pwm->args.mode = PWM_MODE_COMPLEMENTARY;
>
> - if (args->args_count > 2 && args->args[2] & PWM_POLARITY_INVERTED)
> - pwm->args.polarity = PWM_POLARITY_INVERSED;
> + if (args->args_count > 2) {
> + if (args->args[2] & PWM_POLARITY_INVERTED)
> + pwm->args.polarity = PWM_POLARITY_INVERSED;
> + if (args->args[2] & PWM_MODE_PUSHPULL)
> + pwm->args.mode = PWM_MODE_PUSH_PULL;
> + }
>
> return pwm;
>
Re: [PATCH 0/2] extend PWM framework to support PWM dead-times
Hi Thierry, Thank you for your response. I added few comments below. Thank you, Claudiu On 21.08.2017 11:25, Thierry Reding wrote: > On Tue, May 09, 2017 at 03:15:51PM +0300, Claudiu Beznea wrote: >> Hi all, >> >> Please give feedback on these patches which extends the PWM >> framework in order to support multiple PWM signal types. >> Since I didn't receive any inputs on RFC series I'm resending it as >> normal patch series. >> >> The current patch series add the following PWM signal types: >> - PWM complementary signals >> - PWM push-pull signal >> >> Definition of PWM complementary mode: >> For a PWM controllers with more than one outputs per PWM channel, >> e.g. with 2 outputs per PWM channels, the PWM complementary signals >> have opposite levels, same duration and same starting times, >> as in the following diagram: >> >> ________ >> PWMH __| |__| |__| |__| |__ >> __________ >> PWML |__| |__| |__| |__| >><--T--> >> Where T is the signal period. >> >> Definition of PWM push-pull mode: >> For PWM controllers with more than one outputs per PWM channel, >> e.g. with 2 outputs per PWM channel, the PWM push-pull signals >> have same levels, same duration and are delayed until the begining >> of the next period, as in the following diagram: >> >> __ __ >> PWMH __| || | >> __ __ >> PWML | || |__ >><--T--> >> >> Where T is the signal period. >> >> These output signals could be configured by setting PWM mode >> (a new input in sysfs has been added in order to support this >> operation). >> >> root@sama5d2-xplained:/sys/devices/platform/ahb/ahb:apb/f802c000.pwm/pwm/pwmchip0/pwm2# >> ls -l >> -r--r--r--1 root root 4096 Feb 9 10:54 capture >> -rw-r--r--1 root root 4096 Feb 9 10:54 duty_cycle >> -rw-r--r--1 root root 4096 Feb 9 10:54 enable >> -rw-r--r--1 root root 4096 Feb 9 10:54 mode >> -rw-r--r--1 root root 4096 Feb 9 10:54 period >> -rw-r--r--1 root root 4096 Feb 9 10:55 polarity >> drwxr-xr-x2 root root 0 Feb 9 10:54 power >> -rw-r--r--1 root root 4096 Feb 9 10:54 uevent >> >> The PWM push-pull mode could be usefull in applications like >> half bridge converters. > > Sorry for taking an absurdly long time to get back to you on this. > > One problem I see with this is that the PWM framework is built on the > assumption that we have a single output per PWM channel. This becomes > important when you start adding features such as this because now the > users have no way of determining whether or not the PWM they retrieve > will actually be able to do what they want. I was thinking that the framework is there to offer support in configuring the underlying hardware without taking into account how many outputs per PWM channels are actually present. It is true I only worked with Atmel/Microchip PWM controllers which for instance, SAMA5 SoC has a PWM controller with 2 outputs per PWM channel. Taking into account that the driver is already mainlined I though that the user is aware of what he is using (either a one output per PWM channel controller, or 2 outputs or more than 2) and about the underlying hardware support. I understand your position on this. I'm just explaining myself on the approach I've chose for this implementation. > > For example, let's say you have a half bridge converter driver in the > kernel and it does a pwm_get() to obtain a PWM to use. There's nothing > preventing it from using a simple one-output PWM and there's no way to > check that we're actually doing something wrong. I understand your position here. I've chose this approach taking into account that the user of the PWM will be aware of the capabilities of the underlying hardware because I worked on a controller which already has a mainlined driver and which has more than one output per PWM channel and I believe there are also other controllers with this kind of capability and with already mainlined driver (e.g. reading the code of STM32 PWM driver I saw a bool type variable in driver specific data structure (struct stm32_pwm): "bool have_complementary_output" which let me think that their controller also could support more than one output per PWM channel (I will also try to find the controller specific datasheet). At a first look I saw that also TI ECAP PWM controller supports this (it is true that I am not aware of how it is initialized in kernel, I need to check the datasheet, if it is public). > > I think any in-kernel API would have to be more fully-featured, > otherwise we're bound to run into problems. At the very least I think > we'd have to expose some sort of capabilities list. About the exposing of these capabilities would you prefer to have the supported PWM modes registered in driver probe as a new field mask in "struct pwm_chip". e.
Re: [PATCH 0/2] extend PWM framework to support PWM dead-times
Hi Thierry, I added few other comments below. Please let me know what you think. Thank you, Claudiu On 21.08.2017 14:25, Thierry Reding wrote: > On Mon, Aug 21, 2017 at 01:23:08PM +0300, m18063 wrote: >> Hi Thierry, >> >> Thank you for your response. I added few comments below. >> >> Thank you, >> Claudiu >> >> On 21.08.2017 11:25, Thierry Reding wrote: >>> On Tue, May 09, 2017 at 03:15:51PM +0300, Claudiu Beznea wrote: >>>> Hi all, >>>> >>>> Please give feedback on these patches which extends the PWM >>>> framework in order to support multiple PWM signal types. >>>> Since I didn't receive any inputs on RFC series I'm resending it as >>>> normal patch series. >>>> >>>> The current patch series add the following PWM signal types: >>>> - PWM complementary signals >>>> - PWM push-pull signal >>>> >>>> Definition of PWM complementary mode: >>>> For a PWM controllers with more than one outputs per PWM channel, >>>> e.g. with 2 outputs per PWM channels, the PWM complementary signals >>>> have opposite levels, same duration and same starting times, >>>> as in the following diagram: >>>> >>>> ________ >>>> PWMH __| |__| |__| |__| |__ >>>> __________ >>>> PWML |__| |__| |__| |__| >>>><--T--> >>>> Where T is the signal period. >>>> >>>> Definition of PWM push-pull mode: >>>> For PWM controllers with more than one outputs per PWM channel, >>>> e.g. with 2 outputs per PWM channel, the PWM push-pull signals >>>> have same levels, same duration and are delayed until the begining >>>> of the next period, as in the following diagram: >>>> >>>> __ __ >>>> PWMH __| || | >>>> __ __ >>>> PWML | || |__ >>>><--T--> >>>> >>>> Where T is the signal period. >>>> >>>> These output signals could be configured by setting PWM mode >>>> (a new input in sysfs has been added in order to support this >>>> operation). >>>> >>>> root@sama5d2-xplained:/sys/devices/platform/ahb/ahb:apb/f802c000.pwm/pwm/pwmchip0/pwm2# >>>> ls -l >>>> -r--r--r--1 root root 4096 Feb 9 10:54 capture >>>> -rw-r--r--1 root root 4096 Feb 9 10:54 duty_cycle >>>> -rw-r--r--1 root root 4096 Feb 9 10:54 enable >>>> -rw-r--r--1 root root 4096 Feb 9 10:54 mode >>>> -rw-r--r--1 root root 4096 Feb 9 10:54 period >>>> -rw-r--r--1 root root 4096 Feb 9 10:55 polarity >>>> drwxr-xr-x2 root root 0 Feb 9 10:54 power >>>> -rw-r--r--1 root root 4096 Feb 9 10:54 uevent >>>> >>>> The PWM push-pull mode could be usefull in applications like >>>> half bridge converters. >>> >>> Sorry for taking an absurdly long time to get back to you on this. >>> >>> One problem I see with this is that the PWM framework is built on the >>> assumption that we have a single output per PWM channel. This becomes >>> important when you start adding features such as this because now the >>> users have no way of determining whether or not the PWM they retrieve >>> will actually be able to do what they want. >> I was thinking that the framework is there to offer support in configuring >> the underlying hardware without taking into account how many outputs per >> PWM channels are actually present. It is true I only worked with >> Atmel/Microchip >> PWM controllers which for instance, SAMA5 SoC has a PWM controller >> with 2 outputs per PWM channel. Taking into account that the driver is >> already mainlined I though that the user is aware of what he is using >> (either a one output per PWM channel controller, or 2 outputs or >> more than 2) and about the underlying hardware support. I understand your >> position on this. I'm just explaining myself on the approach I've chose >> for this implementation. > > So currently we assume that there will be (at least) one output per PWM > channel. However there are currently no drivers that actually use any > output other than the "primary" one. > > That means, even if ther
Re: [PATCH 0/2] extend PWM framework to support PWM dead-times
On 22.08.2017 15:24, Benjamin Gaignard wrote: > 2017-08-22 14:11 GMT+02:00 m18063 : >> Hi Thierry, >> >> I added few other comments below. Please let me know what you think. >> >> Thank you, >> Claudiu >> >> On 21.08.2017 14:25, Thierry Reding wrote: >>> On Mon, Aug 21, 2017 at 01:23:08PM +0300, m18063 wrote: >>>> Hi Thierry, >>>> >>>> Thank you for your response. I added few comments below. >>>> >>>> Thank you, >>>> Claudiu >>>> >>>> On 21.08.2017 11:25, Thierry Reding wrote: >>>>> On Tue, May 09, 2017 at 03:15:51PM +0300, Claudiu Beznea wrote: >>>>>> Hi all, >>>>>> >>>>>> Please give feedback on these patches which extends the PWM >>>>>> framework in order to support multiple PWM signal types. >>>>>> Since I didn't receive any inputs on RFC series I'm resending it as >>>>>> normal patch series. >>>>>> >>>>>> The current patch series add the following PWM signal types: >>>>>> - PWM complementary signals >>>>>> - PWM push-pull signal >>>>>> >>>>>> Definition of PWM complementary mode: >>>>>> For a PWM controllers with more than one outputs per PWM channel, >>>>>> e.g. with 2 outputs per PWM channels, the PWM complementary signals >>>>>> have opposite levels, same duration and same starting times, >>>>>> as in the following diagram: >>>>>> >>>>>> ________ >>>>>> PWMH __| |__| |__| |__| |__ >>>>>> __________ >>>>>> PWML |__| |__| |__| |__| >>>>>><--T--> >>>>>> Where T is the signal period. >>>>>> >>>>>> Definition of PWM push-pull mode: >>>>>> For PWM controllers with more than one outputs per PWM channel, >>>>>> e.g. with 2 outputs per PWM channel, the PWM push-pull signals >>>>>> have same levels, same duration and are delayed until the begining >>>>>> of the next period, as in the following diagram: >>>>>> >>>>>> __ __ >>>>>> PWMH __| || | >>>>>> __ __ >>>>>> PWML | || |__ >>>>>><--T--> >>>>>> >>>>>> Where T is the signal period. >>>>>> >>>>>> These output signals could be configured by setting PWM mode >>>>>> (a new input in sysfs has been added in order to support this >>>>>> operation). >>>>>> >>>>>> root@sama5d2-xplained:/sys/devices/platform/ahb/ahb:apb/f802c000.pwm/pwm/pwmchip0/pwm2# >>>>>> ls -l >>>>>> -r--r--r--1 root root 4096 Feb 9 10:54 capture >>>>>> -rw-r--r--1 root root 4096 Feb 9 10:54 duty_cycle >>>>>> -rw-r--r--1 root root 4096 Feb 9 10:54 enable >>>>>> -rw-r--r--1 root root 4096 Feb 9 10:54 mode >>>>>> -rw-r--r--1 root root 4096 Feb 9 10:54 period >>>>>> -rw-r--r--1 root root 4096 Feb 9 10:55 polarity >>>>>> drwxr-xr-x2 root root 0 Feb 9 10:54 power >>>>>> -rw-r--r--1 root root 4096 Feb 9 10:54 uevent >>>>>> >>>>>> The PWM push-pull mode could be usefull in applications like >>>>>> half bridge converters. >>>>> >>>>> Sorry for taking an absurdly long time to get back to you on this. >>>>> >>>>> One problem I see with this is that the PWM framework is built on the >>>>> assumption that we have a single output per PWM channel. This becomes >>>>> important when you start adding features such as this because now the >>>>> users have no way of determining whether or not the PWM they retrieve >>>>> will actually be able to do what they want. >>>> I was thinking that the framework is there to offer support in configuring >>>> the underlying hardware without taking into account how many outputs per >>>> PWM channels are actually present. It is true I only worked with >>>> Atmel
Re: [PATCH 0/2] extend PWM framework to support PWM dead-times
Hi Thierry, Please, do you have any inputs on my previous proposals? Thank you, Claudiu On 22.08.2017 15:24, Benjamin Gaignard wrote: > 2017-08-22 14:11 GMT+02:00 m18063 : >> Hi Thierry, >> >> I added few other comments below. Please let me know what you think. >> >> Thank you, >> Claudiu >> >> On 21.08.2017 14:25, Thierry Reding wrote: >>> On Mon, Aug 21, 2017 at 01:23:08PM +0300, m18063 wrote: >>>> Hi Thierry, >>>> >>>> Thank you for your response. I added few comments below. >>>> >>>> Thank you, >>>> Claudiu >>>> >>>> On 21.08.2017 11:25, Thierry Reding wrote: >>>>> On Tue, May 09, 2017 at 03:15:51PM +0300, Claudiu Beznea wrote: >>>>>> Hi all, >>>>>> >>>>>> Please give feedback on these patches which extends the PWM >>>>>> framework in order to support multiple PWM signal types. >>>>>> Since I didn't receive any inputs on RFC series I'm resending it as >>>>>> normal patch series. >>>>>> >>>>>> The current patch series add the following PWM signal types: >>>>>> - PWM complementary signals >>>>>> - PWM push-pull signal >>>>>> >>>>>> Definition of PWM complementary mode: >>>>>> For a PWM controllers with more than one outputs per PWM channel, >>>>>> e.g. with 2 outputs per PWM channels, the PWM complementary signals >>>>>> have opposite levels, same duration and same starting times, >>>>>> as in the following diagram: >>>>>> >>>>>> ________ >>>>>> PWMH __| |__| |__| |__| |__ >>>>>> __________ >>>>>> PWML |__| |__| |__| |__| >>>>>><--T--> >>>>>> Where T is the signal period. >>>>>> >>>>>> Definition of PWM push-pull mode: >>>>>> For PWM controllers with more than one outputs per PWM channel, >>>>>> e.g. with 2 outputs per PWM channel, the PWM push-pull signals >>>>>> have same levels, same duration and are delayed until the begining >>>>>> of the next period, as in the following diagram: >>>>>> >>>>>> __ __ >>>>>> PWMH __| || | >>>>>> __ __ >>>>>> PWML | || |__ >>>>>><--T--> >>>>>> >>>>>> Where T is the signal period. >>>>>> >>>>>> These output signals could be configured by setting PWM mode >>>>>> (a new input in sysfs has been added in order to support this >>>>>> operation). >>>>>> >>>>>> root@sama5d2-xplained:/sys/devices/platform/ahb/ahb:apb/f802c000.pwm/pwm/pwmchip0/pwm2# >>>>>> ls -l >>>>>> -r--r--r--1 root root 4096 Feb 9 10:54 capture >>>>>> -rw-r--r--1 root root 4096 Feb 9 10:54 duty_cycle >>>>>> -rw-r--r--1 root root 4096 Feb 9 10:54 enable >>>>>> -rw-r--r--1 root root 4096 Feb 9 10:54 mode >>>>>> -rw-r--r--1 root root 4096 Feb 9 10:54 period >>>>>> -rw-r--r--1 root root 4096 Feb 9 10:55 polarity >>>>>> drwxr-xr-x2 root root 0 Feb 9 10:54 power >>>>>> -rw-r--r--1 root root 4096 Feb 9 10:54 uevent >>>>>> >>>>>> The PWM push-pull mode could be usefull in applications like >>>>>> half bridge converters. >>>>> >>>>> Sorry for taking an absurdly long time to get back to you on this. >>>>> >>>>> One problem I see with this is that the PWM framework is built on the >>>>> assumption that we have a single output per PWM channel. This becomes >>>>> important when you start adding features such as this because now the >>>>> users have no way of determining whether or not the PWM they retrieve >>>>> will actually be able to do what they want. >>>> I was thinking that the framework is there to offer support in configuring >>>> the underlying hardware without taking into account how many outputs per >&
