lkml.org 
[lkml]   [2012]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v6 1/4] Runtime Interpreted Power Sequences
    On Thu, Sep 13, 2012 at 10:03:27AM +0300, Tomi Valkeinen wrote:
    > On Thu, 2012-09-13 at 09:00 +0200, Sascha Hauer wrote:
    > > On Thu, Sep 13, 2012 at 09:54:09AM +0300, Tomi Valkeinen wrote:
    > > > On Thu, 2012-09-13 at 15:36 +0900, Alex Courbot wrote:
    > > > > On Thursday 13 September 2012 14:22:57 Tomi Valkeinen wrote:
    > > > >
    > > > > > However, I fear these board specific things may be quite a bit anything,
    > > > > > so it may well be pwm, gpios and regulators are not enough for them. For
    > > > > > example, there could be an FPGA on the board which requires some
    > > > > > configuration to accomplish the task at hand. It could be rather
    > > > > > difficult to handle it with a generic power sequence.
    > > > >
    > > > > Right. Note that this framework is supposed to be extended - I would like to
    > > > > at least add regulator voltage setting, and maybe even support for clocks and
    > > > > pinmux (but that might be out of place).
    > > >
    > > > Yes, that's one concern of mine... I already can imagine someone
    > > > suggesting adding conditionals to the power sequence data. Perhaps also
    > > > direct memory read/writes so you can twiddle registers directly. And so
    > > > on. Where's the limit what it should contain? Can we soon write full
    > > > drivers with the DT data? =)
    > >
    > > I have this concern aswell, that's why I'm sceptical about this patch
    > > set. But what are the alternatives? Adding power code to the drivers and
    > > thus adding board specific code to them is backwards.
    >
    > As was pointed out in earlier posts in this thread, these are almost
    > always device specific, not board specific.
    >
    > Do you have examples of board specific power sequences or such?

    It is true that most (perhaps all) power sequences can be associated
    with a specific device, but if we go and implement drivers for these
    kinds of devices we will probably end up with loads of variations of
    the same scheme.

    Lets take display panels as an example. One of the devices that we build
    has gone through two generations so far and both are slightly different
    in how they control the panel backlight: one has an external backlight
    controller, the other has the display controller built into the panel.
    However, from the board's perspective the control of the backlight
    doesn't change, because both devices get the same inputs (an enable pin
    and a PWM) that map to the same pins on the SoC.

    This may not be a very good example because the timing isn't relevant,
    but the basic point is still valid: if we provide a driver for both
    panel devices, the code will be exactly the same. So we end up having to
    refactor to avoid code duplication and use the same driver for a number
    of backlight/panel combinations. Which in itself isn't very bad, but it
    also means that we'll probably get to see a large number of "generic"
    drivers which aren't very generic after all.

    Another problem, which also applies to the case of power-sequences, is
    that often the panel and backlight are not the same device. So you could
    have the same panel with any number of different backlight controllers
    or vice-versa any number of different panels with the same backlight
    controller.

    Thierry
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2012-09-13 12:21    [W:4.555 / U:0.184 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site