linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: tomasz.figa@gmail.com (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 11/18] pwm: Add new pwm-samsung driver
Date: Mon, 24 Jun 2013 22:32:55 +0200	[thread overview]
Message-ID: <3059286.XLVAQe4lge@flatron> (raw)
In-Reply-To: <20130624201326.GB7163@mithrandir>

On Monday 24 of June 2013 22:13:27 Thierry Reding wrote:
> On Mon, Jun 24, 2013 at 08:31:43PM +0200, Tomasz Figa wrote:
> > On Monday 24 of June 2013 19:49:04 Thierry Reding wrote:
> > > On Tue, Jun 25, 2013 at 12:22:42AM +0900, Kukjin Kim wrote:
[snip]
> > > > 
> > > > Just note, checkpatch complains following, so fixed to use
> > > > pr_warn()
> > > > when I applied.
> > > 
> > > Note that you can't apply patches that touch the PWM tree without my
> > > Ack and I already mentioned that the current way this driver is
> > > written isn't acceptable.
> > > 
> > > So either you fix it properly, or if everybody except me thinks we
> > > don't need a proper design for drivers anymore, then the only way
> > > I'll accept this driver into the PWM tree is if you put a really
> > > big comment at the top of the file saying that the driver is badly
> > > designed on purpose and that people shouldn't be using it as a
> > > reference.
> > 
> > Sorry, I don't understand what problem you have with this design. It
> > completely meets all the requirements applicable on hardware platforms
> > it is (and going to be) used on.
> 
> My main problem with it is that there is no design. And as such it sets
> a bad example. If I accept this into the PWM tree as is then what am I
> supposed to tell the next person that comes up with a similarly broken
> driver?

I wouldn't call it no design. It's a simple (trivial) design.

Simple design is often better than a complex one. In this case it indeed 
is, because it doesn't add code that serves no purpose, without any 
functional drawbacks.

> > The only thing it would do in a suboptimal way would be
> > synchronization of register accesses for multiple instances of the
> > driver - one spinlock would be used for all of them. This is
> > insignificant because there is no time critical code in this driver
> > and it is really unlikely that a SoC with multiple instances of this
> > IP block shows up.
> 
> I've had people give me guarantees that this and that would *never*
> happen only to change their minds 6 months down the road. And again,
> even if it was actually true in this case, it isn't a valid excuse for
> setting a bad example.

Well, even if that happens, there is nothing on the way stopping from 
extending this design with something that will work optimally for multiple 
instances. For all currently supported platforms solution used in this 
series is enough.

> > Channel reservation between clocksource and PWM drivers is completely
> > correct, relying on the fact that the former can only use channels
> > _without_ outputs and the latter can only use channels _with_ outputs.
> > Do I have to add that there can't be a channel both with and without
> > output?
> The issue is that you can't really ensure that both the clocksource and
> PWM drivers use the same variant and therefore might be using different
> masks.

Output mask is _not_ a part of the constant variant data. It is stored in 
the same struct, which is to simplify passing SoC-specific parameters from 
platform code to both drivers, but it is not defined as a constant 
anywhere in drivers.

As I already explained in one of my previous replies, it is either parsed 
from DT (samsung,pwm-outputs property) or passed through the variant 
struct as platform_data from board files. It isn't possible for both 
drivers to get different mask values.

> > So the only place for improvement here, without starting
> > overengineering things, is a comment about the purpose of the
> > spinlock and why it can be used in our case.
> 
> I disagree. You actually even had a version with a halfway decent design
> at some point and it was discarded. I don't think I'm asking for all
> that much here. I even gave you the option of admitting that the driver
> was suboptimal. All I request in return is that you mention that in the
> code so that either somebody else might go and clean things up or at
> least that nobody will copy from a bad example.

What about:

/*
 * PWM block is shared between pwm-samsung and samsung_pwm_timer drivers
 * and some registers need access synchronization. If both drivers are
 * compiled in, the spinlock is defined in the clocksource driver,
 * otherwise following definition is used.
 *
 * Currently we do not need any more complex synchronization method 
 * because all the supported SoCs contain only one instance of the PWM 
 * IP. Should this change, both drivers will need to be modified to
 * properly synchronize accesses to particular instances.
 */

Best regards,
Tomasz

  reply	other threads:[~2013-06-24 20:32 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-20 22:12 [PATCH v2 00/18] Final Samsung PWM support cleanup Tomasz Figa
2013-06-20 22:12 ` [PATCH v2 01/18] ARM: SAMSUNG: Unify base address definitions of timer block Tomasz Figa
2013-06-20 22:12 ` [PATCH v2 02/18] ARM: SAMSUNG: Add new PWM platform device Tomasz Figa
2013-06-20 22:12 ` [PATCH v2 03/18] ARM: SAMSUNG: Set PWM platform data Tomasz Figa
2013-06-20 22:12 ` [PATCH v2 04/18] clocksource: samsung_pwm_timer: Cache clocksource register address Tomasz Figa
2013-06-20 22:12 ` [PATCH v2 05/18] clocksource: samsung_pwm_timer: Do not use clocksource_mmio Tomasz Figa
2013-06-20 22:12 ` [PATCH v2 06/18] clocksource: samsung_pwm_timer: Handle suspend/resume correctly Tomasz Figa
2013-06-20 22:12 ` [PATCH v2 07/18] ARM: SAMSUNG: Move all platforms to new clocksource driver Tomasz Figa
2013-06-24 15:33   ` Kukjin Kim
2013-06-24 15:38     ` Tomasz Figa
2013-06-24 15:46       ` Kukjin Kim
2013-06-24 15:49         ` Tomasz Figa
2013-06-20 22:12 ` [PATCH v2 08/18] ARM: SAMSUNG: Remove old samsung-time driver Tomasz Figa
2013-06-20 22:12 ` [PATCH v2 09/18] ARM: SAMSUNG: Remove unused PWM timer IRQ chip code Tomasz Figa
2013-06-20 22:12 ` [PATCH v2 10/18] pwm: samsung: Rename to pwm-samsung-legacy Tomasz Figa
2013-06-22 13:09   ` [PATCH v3 " Tomasz Figa
2013-06-20 22:12 ` [PATCH v2 11/18] pwm: Add new pwm-samsung driver Tomasz Figa
2013-06-22 13:06   ` [PATCH v3 " Tomasz Figa
2013-06-24 15:22     ` Kukjin Kim
2013-06-24 15:37       ` Tomasz Figa
2013-06-24 17:49       ` Thierry Reding
2013-06-24 18:31         ` Tomasz Figa
2013-06-24 20:13           ` Thierry Reding
2013-06-24 20:32             ` Tomasz Figa [this message]
2013-06-24 20:53               ` Thierry Reding
2013-06-24 21:17                 ` Tomasz Figa
2013-06-25 10:26                   ` Thierry Reding
2013-06-25 11:19                     ` Tomasz Figa
2013-06-25 15:18                       ` Mark Brown
2013-06-25 16:41                       ` Kukjin Kim
2013-06-25 16:30         ` Kukjin Kim
2013-06-20 22:12 ` [PATCH v2 12/18] ARM: SAMSUNG: Rework private data handling in dev-backlight Tomasz Figa
2013-06-20 22:12 ` [PATCH v2 13/18] ARM: SAMSUNG: Modify board files to use new PWM platform device Tomasz Figa
2013-06-20 22:12 ` [PATCH v2 14/18] pwm: Remove superseded pwm-samsung-legacy driver Tomasz Figa
2013-06-20 22:13 ` [PATCH v2 15/18] ARM: SAMSUNG: Remove old PWM timer platform devices Tomasz Figa
2013-06-20 22:13 ` [PATCH v2 16/18] ARM: SAMSUNG: Remove pwm-clock infrastructure Tomasz Figa
2013-06-20 22:13 ` [PATCH v2 17/18] ARM: SAMSUNG: Remove remaining uses of plat/regs-timer.h header Tomasz Figa
2013-06-20 22:13 ` [PATCH v2 18/18] ARM: SAMSUNG: Remove " Tomasz Figa
2013-06-20 23:05 ` [PATCH v2 00/18] Final Samsung PWM support cleanup Tomasz Figa
2013-06-21 14:04 ` Arnd Bergmann
2013-06-22 13:10   ` Tomasz Figa
2013-06-22 18:01 ` Heiko Stübner
2013-06-22 18:04   ` Tomasz Figa
2013-06-24  0:14     ` Kukjin Kim
2013-06-22 19:34   ` Sylwester Nawrocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3059286.XLVAQe4lge@flatron \
    --to=tomasz.figa@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).