All of lore.kernel.org
 help / color / mirror / Atom feed
* Question about DC-DC frequency handling
@ 2015-04-26 14:31 ` Stefan Wahren
  0 siblings, 0 replies; 7+ messages in thread
From: Stefan Wahren @ 2015-04-26 14:31 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

i'm current working on a regulator driver which should be able to change DC-DC
clock frequency.

Now here is my question. What is the prefered way to implement the clock
handling?

Option A):

The regulator driver handles all internally (select clock source, set
frequency).

Option B):

The DC-DC clock domain is implemented in the clock driver and the regulator
driver uses the clock framework.

Best regards
Stefan

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Question about DC-DC frequency handling
@ 2015-04-26 14:31 ` Stefan Wahren
  0 siblings, 0 replies; 7+ messages in thread
From: Stefan Wahren @ 2015-04-26 14:31 UTC (permalink / raw)
  To: kernelnewbies

Hi,

i'm current working on a regulator driver which should be able to change DC-DC
clock frequency.

Now here is my question. What is the prefered way to implement the clock
handling?

Option A):

The regulator driver handles all internally (select clock source, set
frequency).

Option B):

The DC-DC clock domain is implemented in the clock driver and the regulator
driver uses the clock framework.

Best regards
Stefan

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Question about DC-DC frequency handling
  2015-04-26 14:31 ` Stefan Wahren
  (?)
@ 2015-04-26 19:07 ` Michael Turquette
  2015-04-27 20:44     ` Stefan Wahren
  -1 siblings, 1 reply; 7+ messages in thread
From: Michael Turquette @ 2015-04-26 19:07 UTC (permalink / raw)
  To: linux-arm-kernel

Quoting Stefan Wahren (2015-04-26 07:31:30)
> Hi,
> 
> i'm current working on a regulator driver which should be able to change DC-DC
> clock frequency.
> 
> Now here is my question. What is the prefered way to implement the clock
> handling?

Fun question. I have a question for you: who are the consumers of this
DC-DC? Do the downstream, consuming devices care about "clock rate" of
your regulator?

I'll hazard a guess that they do not care. DC-DC switching frequency is
an important aspect of power supply design, but switching frequency of a
power supply is not controlled by the clock framework in any example
that I am aware of.

> 
> Option A):
> 
> The regulator driver handles all internally (select clock source, set
> frequency).

Mark should weigh in on this, but I think option A is correct. Maybe
something like regulator_set_mode could program your switching
frequency?

> 
> Option B):
> 
> The DC-DC clock domain is implemented in the clock driver and the regulator
> driver uses the clock framework.

The only reason to use the clock framework is if downstream devices will
call clk_get and do something with the rate (e.g. clk_get_rate,
clk_set_rate, clk_enable, clk_disable, etc).

It sounds like your downstream devices will want to enable & disable the
regulator, but probably that's it?

Of course I could be wrong about the DC-DC switching frequency stuff
above, but that's my guess for now.

Regards,
Mike

> 
> Best regards
> Stefan

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Question about DC-DC frequency handling
  2015-04-26 14:31 ` Stefan Wahren
  (?)
  (?)
@ 2015-04-27 11:01 ` Mark Brown
  -1 siblings, 0 replies; 7+ messages in thread
From: Mark Brown @ 2015-04-27 11:01 UTC (permalink / raw)
  To: linux-arm-kernel

On Sun, Apr 26, 2015 at 04:31:30PM +0200, Stefan Wahren wrote:

> Option A):

> The regulator driver handles all internally (select clock source, set
> frequency).

This.  Nothing outside the regulator cares what clock rate it's
operating at, they just care about how good and efficient the regulation
is.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150427/94ff1f71/attachment.sig>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Question about DC-DC frequency handling
  2015-04-26 19:07 ` Michael Turquette
@ 2015-04-27 20:44     ` Stefan Wahren
  0 siblings, 0 replies; 7+ messages in thread
From: Stefan Wahren @ 2015-04-27 20:44 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

> Michael Turquette <mturquette@linaro.org> hat am 26. April 2015 um 21:07
> geschrieben:
>
>
> Quoting Stefan Wahren (2015-04-26 07:31:30)
> > Hi,
> >
> > i'm current working on a regulator driver which should be able to change
> > DC-DC
> > clock frequency.
> >
> > Now here is my question. What is the prefered way to implement the clock
> > handling?
>
> Fun question. I have a question for you: who are the consumers of this
> DC-DC? Do the downstream, consuming devices care about "clock rate" of
> your regulator?
>
> I'll hazard a guess that they do not care. DC-DC switching frequency is
> an important aspect of power supply design, but switching frequency of a
> power supply is not controlled by the clock framework in any example
> that I am aware of.

yes the consumers don't care. My intension for changing the switching frequency
is
to avoid interferences on HF band.

>
> >
> > Option A):
> >
> > The regulator driver handles all internally (select clock source, set
> > frequency).
>
> Mark should weigh in on this, but I think option A is correct. Maybe
> something like regulator_set_mode could program your switching
> frequency?

A runtime configuration isn't necessary. In a earlier discussion we decided to
use
a devicetree property.

Thanks

Stefan

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Question about DC-DC frequency handling
@ 2015-04-27 20:44     ` Stefan Wahren
  0 siblings, 0 replies; 7+ messages in thread
From: Stefan Wahren @ 2015-04-27 20:44 UTC (permalink / raw)
  To: kernelnewbies

Hi,

> Michael Turquette <mturquette@linaro.org> hat am 26. April 2015 um 21:07
> geschrieben:
>
>
> Quoting Stefan Wahren (2015-04-26 07:31:30)
> > Hi,
> >
> > i'm current working on a regulator driver which should be able to change
> > DC-DC
> > clock frequency.
> >
> > Now here is my question. What is the prefered way to implement the clock
> > handling?
>
> Fun question. I have a question for you: who are the consumers of this
> DC-DC? Do the downstream, consuming devices care about "clock rate" of
> your regulator?
>
> I'll hazard a guess that they do not care. DC-DC switching frequency is
> an important aspect of power supply design, but switching frequency of a
> power supply is not controlled by the clock framework in any example
> that I am aware of.

yes the consumers don't care. My intension for changing the switching frequency
is
to avoid interferences on HF band.

>
> >
> > Option A):
> >
> > The regulator driver handles all internally (select clock source, set
> > frequency).
>
> Mark should weigh in on this, but I think option A is correct. Maybe
> something like regulator_set_mode could program your switching
> frequency?

A runtime configuration isn't necessary. In a earlier discussion we decided to
use
a devicetree property.

Thanks

Stefan

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Question about DC-DC frequency handling
  2015-04-27 20:44     ` Stefan Wahren
  (?)
@ 2015-04-27 20:57     ` Mark Brown
  -1 siblings, 0 replies; 7+ messages in thread
From: Mark Brown @ 2015-04-27 20:57 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Apr 27, 2015 at 10:44:56PM +0200, Stefan Wahren wrote:
> > Michael Turquette <mturquette@linaro.org> hat am 26. April 2015 um 21:07
> > Quoting Stefan Wahren (2015-04-26 07:31:30)

> > I'll hazard a guess that they do not care. DC-DC switching frequency is
> > an important aspect of power supply design, but switching frequency of a
> > power supply is not controlled by the clock framework in any example
> > that I am aware of.

> yes the consumers don't care. My intension for changing the switching frequency
> is
> to avoid interferences on HF band.

You may also find that the switching frequency is dictated by the choice
of passives on the board - you may find there's restrictions there that
mean the user can't freely choose without running into performance
problems.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150427/fd70eb97/attachment-0001.sig>

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2015-04-27 20:57 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-04-26 14:31 Question about DC-DC frequency handling Stefan Wahren
2015-04-26 14:31 ` Stefan Wahren
2015-04-26 19:07 ` Michael Turquette
2015-04-27 20:44   ` Stefan Wahren
2015-04-27 20:44     ` Stefan Wahren
2015-04-27 20:57     ` Mark Brown
2015-04-27 11:01 ` Mark Brown

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.