lkml.org 
[lkml]   [2014]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v4 0/3] Generic Device Tree based power domain look-up
    Hi,

    On 08.05.2014 14:49, Tomasz Figa wrote:
    > Up till now there was no single generic method to bind devices to their
    > power domains using Device Tree. Each platform has been doing this using
    > its own way, example of which are Exynos power domain bindings [1] and
    > look-up code [2].
    >
    > This series is intended to change this and provide generic DT bindings for
    > power domain specification and generic code performing look-up of power
    > domains and binding them to devices.
    >
    > First two patches are the most important part of this series, as they
    > introduce $subject. Patch 3 converts mach-exynos to use the new generic
    > method. Further patches are adding one more user of the new code,
    > mach-s3c64xx, with first 3 patches (4-6) required to clean-up its power
    > domain driver a bit and last 3 patches (9-11) adding display support for
    > Mini6410 board, including a node for display controller (FIMD) which is
    > a power domain consumer.
    >
    > The design of DT bindings and provider code is heavily inspired by
    > implementation of clock providers in Common Clock Framework, while
    > the code binding devices to power domains by my Exynos power domain
    > implementation (now removed by this series ;)).
    >
    > Successfully tested on Exynos4210-based Trats and Exynos4412-based Trats2
    > boards using MFC,
    >
    > [1] Documentation/devicetree/bindings/arm/exynos/power_domain.txt
    > [2] arch/arm/mach-exynos/pm_domains.c
    >
    > Changes since v3:
    > (http://thread.gmane.org/gmane.linux.power-management.general/44571)
    > - rebased onto current Rafael's linux-pm bleeding-edge branch (0a112bf),
    > - renamed "power-domain" property to "power-domains" to facilitate further
    > extension to support multiple power domains per device in future.
    >
    > Changes since v2:
    > (http://thread.gmane.org/gmane.linux.kernel/1658926)
    > - rebased onto current Rafael's linux-pm bleeding-edge branch,
    > - dropped patches for s3c64xx for now. I will send them in separate series,
    > - do not call pm_genpd_dev_need_restore(true) in genpd_bind_domain(),
    > - fixed various stylistic issues reported in review comments.
    >
    > Changes since v1 (RFC):
    > [https://lkml.org/lkml/2014/1/11/141]
    > - rebased onto current Rafael's linux-pm bleeding-edge branch,
    > - reordered the patches a bit (to have the generic ones first),
    > - dropped renaming of S3C64xx power domains (as suggested by Mark Brown),
    > - added support for deferred probing (as suggested by Stephen Boyd),
    > - fixed several minor issues pointed by Stephen Boyd,
    > - replaced notifiers with direct hooks in driver core to make power domain
    > support independent from specific bus type and allow error handling.
    >
    > Tomasz Figa (3):
    > base: power: Add generic OF-based power domain look-up
    > drivercore: Bind/unbind power domain on probe/remove
    > ARM: exynos: Move to generic power domain bindings
    >
    > .../bindings/arm/exynos/power_domain.txt | 12 +-
    > .../devicetree/bindings/power/power_domain.txt | 51 ++++
    > arch/arm/mach-exynos/pm_domains.c | 81 +-----
    > drivers/base/dd.c | 9 +-
    > drivers/base/power/domain.c | 283 +++++++++++++++++++++
    > include/linux/pm_domain.h | 46 ++++
    > kernel/power/Kconfig | 4 +
    > 7 files changed, 398 insertions(+), 88 deletions(-)
    > create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
    >

    Rob, Mark, could we have your ACK (or NAK if you find some issues) for
    DT bindings introduced by this series?

    Rafael, I wonder if we could still have this series applied for 3.16. I
    know it is a bit late already, but the series isn't too invasive, as it
    mostly generalizes what was being done on per-platform basis and makes
    the code generic. Also I have already seen at least two other series
    depending on this one, so they would benefit from this being merged.

    Best regards,
    Tomasz


    \
     
     \ /
      Last update: 2014-05-17 04:01    [W:3.706 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site