All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Tomasz Figa" <tomasz.figa@gmail.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>,
	Kyungmin Park <kmpark@infradead.org>
Cc: "Paul Mundt" <lethal@linux-sh.org>,
	"Magnus Damm" <magnus.damm@gmail.com>,
	"Kukjin Kim" <kgene.kim@samsung.com>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	linux-pm@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, 최찬우 <cw00.choi@samsung.com>,
	함명주 <myungjoo.ham@samsung.com>
Subject: Re: [PATCH 3/3] ARM: S3C64XX: Implement basic power domain support
Date: Fri, 2 Dec 2011 19:25:01 +0100	[thread overview]
Message-ID: <4008DCBCB90E409AA8C5E085EB54D2DB@Flatron> (raw)
In-Reply-To: <20111202005604.GA31948@opensource.wolfsonmicro.com>

Hi,

W dniu 2 grudnia 2011 01:56 użytkownik Mark Brown
<broonie@opensource.wolfsonmicro.com> napisał:
> On Fri, Dec 02, 2011 at 09:35:44AM +0900, Kyungmin Park wrote:
>
>> I'm not sure what's the next step at s3c64xx for generic power domain.
>> Related with exysno4 series, it's helpful to read following threads.
>> http://68.183.106.108/lists/linux-pm/msg26291.html
>
>> "I don't think we should control/gate the clocks with regarding power
>> domain" from Mr. Kim
>
> I tend to agree with him that gating the clocks automatically using
> runtime PM would be nice as if nothing else it saves code in drivers.
> I'm not sure how easy it's going to be to transition to doing that in
> one jump, though - there's a lot of SoCs sharing IP right back to
> S3C24xx.
>
> Of course it should be fairly easy for most of the domains on s3c64xx
> right now as there's only one actual driver involved in mainline, we
> should just be gating almost all of the clocks concerned immediately
> after we boot (assuming they aren't gated by default, I'd need to check)
> and never touching them again anyway.  It'd only be the framebuffer
> clocks that'd need some work and for a first pass we could just mark the
> framebuffer domain as always on and get most of the win.  Sometimes lack
> of driver support is a good thing :)

Please do not forget that there might be some drivers not yet submited
to mainline and mainline should not break them with an assumption that
there are no such drivers.

For example, there is an on-going work on an open source OpenGL
implementation for the GPU in S3C6410, known as OpenFIMG. Currently it
uses a little kernel module for low level hardware management
(interrupts, contexts, locking, power management), involving clock
gating and runtime power management, but a DRM driver is planned.

Best regards,
Tom 

WARNING: multiple messages have this Message-ID (diff)
From: tomasz.figa@gmail.com (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] ARM: S3C64XX: Implement basic power domain support
Date: Fri, 2 Dec 2011 19:25:01 +0100	[thread overview]
Message-ID: <4008DCBCB90E409AA8C5E085EB54D2DB@Flatron> (raw)
In-Reply-To: <20111202005604.GA31948@opensource.wolfsonmicro.com>

Hi,

W dniu 2 grudnia 2011 01:56 u?ytkownik Mark Brown
<broonie@opensource.wolfsonmicro.com> napisa?:
> On Fri, Dec 02, 2011 at 09:35:44AM +0900, Kyungmin Park wrote:
>
>> I'm not sure what's the next step at s3c64xx for generic power domain.
>> Related with exysno4 series, it's helpful to read following threads.
>> http://68.183.106.108/lists/linux-pm/msg26291.html
>
>> "I don't think we should control/gate the clocks with regarding power
>> domain" from Mr. Kim
>
> I tend to agree with him that gating the clocks automatically using
> runtime PM would be nice as if nothing else it saves code in drivers.
> I'm not sure how easy it's going to be to transition to doing that in
> one jump, though - there's a lot of SoCs sharing IP right back to
> S3C24xx.
>
> Of course it should be fairly easy for most of the domains on s3c64xx
> right now as there's only one actual driver involved in mainline, we
> should just be gating almost all of the clocks concerned immediately
> after we boot (assuming they aren't gated by default, I'd need to check)
> and never touching them again anyway.  It'd only be the framebuffer
> clocks that'd need some work and for a first pass we could just mark the
> framebuffer domain as always on and get most of the win.  Sometimes lack
> of driver support is a good thing :)

Please do not forget that there might be some drivers not yet submited
to mainline and mainline should not break them with an assumption that
there are no such drivers.

For example, there is an on-going work on an open source OpenGL
implementation for the GPU in S3C6410, known as OpenFIMG. Currently it
uses a little kernel module for low level hardware management
(interrupts, contexts, locking, power management), involving clock
gating and runtime power management, but a DRM driver is planned.

Best regards,
Tom 

  reply	other threads:[~2011-12-02 18:25 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-01 18:48 [PATCH 1/3] PM: Provide an always on power domain governor Mark Brown
2011-12-01 18:48 ` Mark Brown
2011-12-01 18:48 ` [PATCH 2/3] ARM: mach-shmobile: Use common " Mark Brown
2011-12-01 18:48   ` Mark Brown
2011-12-01 20:37   ` Rafael J. Wysocki
2011-12-01 20:37     ` Rafael J. Wysocki
2011-12-02  0:33     ` Mark Brown
2011-12-02  0:33       ` Mark Brown
2011-12-02 22:36       ` Rafael J. Wysocki
2011-12-02 22:36         ` Rafael J. Wysocki
2011-12-03 11:03         ` Mark Brown
2011-12-03 11:03           ` Mark Brown
2011-12-03 22:31           ` Rafael J. Wysocki
2011-12-03 22:31             ` Rafael J. Wysocki
2011-12-04  1:22             ` Mark Brown
2011-12-04  1:22               ` Mark Brown
2011-12-04 19:53               ` Rafael J. Wysocki
2011-12-04 19:53                 ` Rafael J. Wysocki
2011-12-04  1:24           ` [PATCH v2] " Mark Brown
2011-12-04  1:24             ` Mark Brown
2011-12-01 18:48 ` [PATCH 3/3] ARM: S3C64XX: Implement basic power domain support Mark Brown
2011-12-01 18:48   ` Mark Brown
2011-12-02  0:35   ` Kyungmin Park
2011-12-02  0:35     ` Kyungmin Park
2011-12-02  0:56     ` Mark Brown
2011-12-02  0:56       ` Mark Brown
2011-12-02 18:25       ` Tomasz Figa [this message]
2011-12-02 18:25         ` Tomasz Figa
2011-12-02 18:57         ` Mark Brown
2011-12-02 18:57           ` Mark Brown
2011-12-02 19:06           ` Tomasz Figa
2011-12-02 19:06             ` Tomasz Figa
2011-12-02 20:10   ` Sylwester Nawrocki
2011-12-02 20:10     ` Sylwester Nawrocki
2011-12-02 21:07     ` Mark Brown
2011-12-02 21:07       ` Mark Brown
2011-12-07 21:44       ` Rafael J. Wysocki
2011-12-07 21:44         ` Rafael J. Wysocki
2011-12-08  1:09         ` Mark Brown
2011-12-08  1:09           ` Mark Brown
2011-12-08 22:15           ` Rafael J. Wysocki
2011-12-08 22:15             ` Rafael J. Wysocki
2011-12-08 22:22             ` Rafael J. Wysocki
2011-12-08 22:22               ` Rafael J. Wysocki
2011-12-04 20:56 ` [PATCH 1/3] PM: Provide an always on power domain governor Rafael J. Wysocki
2011-12-04 20:56   ` Rafael J. Wysocki
2011-12-04 23:10   ` Mark Brown
2011-12-04 23:10     ` Mark Brown
2011-12-05  0:15     ` Rafael J. Wysocki
2011-12-05  0:15       ` Rafael J. Wysocki
2011-12-05  0:15       ` Mark Brown
2011-12-05  0:15         ` Mark Brown
2011-12-06 10:20         ` Kukjin Kim
2011-12-06 10:20           ` Kukjin Kim
2011-12-06 12:04           ` Marek Szyprowski
2011-12-06 12:04             ` Marek Szyprowski
2011-12-06 14:33             ` Mark Brown
2011-12-06 14:33               ` Mark Brown
2011-12-06 21:39           ` Rafael J. Wysocki
2011-12-06 21:39             ` Rafael J. Wysocki
2011-12-07 12:35             ` Mark Brown
2011-12-07 12:35               ` Mark Brown
2011-12-07 21:28               ` Rafael J. Wysocki
2011-12-07 21:28                 ` Rafael J. Wysocki
2011-12-08  0:40                 ` Mark Brown
2011-12-08  0:40                   ` Mark Brown

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=4008DCBCB90E409AA8C5E085EB54D2DB@Flatron \
    --to=tomasz.figa@gmail.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=cw00.choi@samsung.com \
    --cc=kgene.kim@samsung.com \
    --cc=kmpark@infradead.org \
    --cc=lethal@linux-sh.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=myungjoo.ham@samsung.com \
    --cc=rjw@sisk.pl \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.