Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1415228 > unrolled thread

Re: [PATCH v2 00/11] pwm: Add support for PWM Capture

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2 00/11] pwm: Add support for PWM Capture Lee Jones <lee.jones@linaro.org> - 2016-06-06 17:40 +0200
    Re: [PATCH v2 00/11] pwm: Add support for PWM Capture Boris Brezillon <boris.brezillon@free-electrons.com> - 2016-06-06 20:50 +0200
      Re: [PATCH v2 00/11] pwm: Add support for PWM Capture Lee Jones <lee.jones@linaro.org> - 2016-06-07 09:50 +0200

#1415228 — Re: [PATCH v2 00/11] pwm: Add support for PWM Capture

On Fri, 29 Apr 2016, Boris Brezillon wrote:

> Hi Lee,
> 
> On Fri, 22 Apr 2016 11:18:04 +0100
> Lee Jones <lee.jones@linaro.org> wrote:
> 
> > The first part of this set extends the current PWM API to allow external
> > code to request a PWM Capture.  Subsequent patches then make use of the
> > new API by providing a userspace offering via /sysfs.  The final part of
> > the set supplies PWM Capture functionality into the already existing STi
> > PWM driver.
> 
> Is there a reason you decided to not put this driver in IIO? IMHO, it
> would be more appropriate to make your PWM device an MFD that can either
> bind to the PWM or the capture driver.
> And BTW, IIO already has a sysfs interface (you may have to extend the
> API to support your type of capture though).

Multi-Function Device drivers can only be justified if the IP
contained does not and can not live in a single subsystem.  The IP
which controls both PWM-in and PWM-out in this device is the same.  I
can't fathom a sane reason why you would wish to separate this
functionality over multiple subsystems.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[toc] | [next] | [standalone]

#1415369

On Mon, 6 Jun 2016 16:32:31 +0100
Lee Jones <lee.jones@linaro.org> wrote:

> On Fri, 29 Apr 2016, Boris Brezillon wrote:
> 
> > Hi Lee,
> > 
> > On Fri, 22 Apr 2016 11:18:04 +0100
> > Lee Jones <lee.jones@linaro.org> wrote:
> >   
> > > The first part of this set extends the current PWM API to allow external
> > > code to request a PWM Capture.  Subsequent patches then make use of the
> > > new API by providing a userspace offering via /sysfs.  The final part of
> > > the set supplies PWM Capture functionality into the already existing STi
> > > PWM driver.  
> > 
> > Is there a reason you decided to not put this driver in IIO? IMHO, it
> > would be more appropriate to make your PWM device an MFD that can either
> > bind to the PWM or the capture driver.
> > And BTW, IIO already has a sysfs interface (you may have to extend the
> > API to support your type of capture though).  
> 
> Multi-Function Device drivers can only be justified if the IP
> contained does not and can not live in a single subsystem.  The IP
> which controls both PWM-in and PWM-out in this device is the same.  I
> can't fathom a sane reason why you would wish to separate this
> functionality over multiple subsystems.
> 

Well, I still think what you describe as PWM-in is actually a capture
device that would perfectly fit in the IIO subsystem, and I guess you
can't use the PWM IP as a capture and waveform generator device as the
same time, which is why I suggested the MFD approach to select the mode.

Anyway, I'm not the PWM or the IIO maintainer, so I'm just sharing my
opinion here.

Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1415807

On Mon, 06 Jun 2016, Boris Brezillon wrote:

> On Mon, 6 Jun 2016 16:32:31 +0100
> Lee Jones <lee.jones@linaro.org> wrote:
> 
> > On Fri, 29 Apr 2016, Boris Brezillon wrote:
> > 
> > > Hi Lee,
> > > 
> > > On Fri, 22 Apr 2016 11:18:04 +0100
> > > Lee Jones <lee.jones@linaro.org> wrote:
> > >   
> > > > The first part of this set extends the current PWM API to allow external
> > > > code to request a PWM Capture.  Subsequent patches then make use of the
> > > > new API by providing a userspace offering via /sysfs.  The final part of
> > > > the set supplies PWM Capture functionality into the already existing STi
> > > > PWM driver.  
> > > 
> > > Is there a reason you decided to not put this driver in IIO? IMHO, it
> > > would be more appropriate to make your PWM device an MFD that can either
> > > bind to the PWM or the capture driver.
> > > And BTW, IIO already has a sysfs interface (you may have to extend the
> > > API to support your type of capture though).  
> > 
> > Multi-Function Device drivers can only be justified if the IP
> > contained does not and can not live in a single subsystem.  The IP
> > which controls both PWM-in and PWM-out in this device is the same.  I
> > can't fathom a sane reason why you would wish to separate this
> > functionality over multiple subsystems.
> > 
> 
> Well, I still think what you describe as PWM-in is actually a capture
> device that would perfectly fit in the IIO subsystem, and I guess you
> can't use the PWM IP as a capture and waveform generator device as the
> same time, which is why I suggested the MFD approach to select the mode.

We only tend to place devices in IIO if they do not fit anywhere
else.  There are lots of unidirectional and bidirectional capture
devices that belong in other subsystems.

This is a PWM device through and through, and the API fits in
perfectly with the remainder of the subsystem.  To attempt to manage
and maintain similar functionality spread over more than one subsystem
when there is no clear requirement (like there is with a chip
containing a GPIO, Regulator and HWMON components for inistance),
would be unnecessarily over-complicating matters.

> Anyway, I'm not the PWM or the IIO maintainer, so I'm just sharing my
> opinion here.
> 
> Regards,
> 
> Boris
> 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web