linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Versaclock usage and improvement question
@ 2020-03-24 17:15 Adam Ford
  2020-03-24 17:30 ` Marek Vasut
  0 siblings, 1 reply; 2+ messages in thread
From: Adam Ford @ 2020-03-24 17:15 UTC (permalink / raw)
  To: Marek Vasut, Michael Turquette, Stephen Boyd, linux-clk,
	Linux Kernel Mailing List

Marek,

I am working on a board that uses two versaclock chips using different
i2c buses, but it appears to the driver is hard-coding the names of
the clocks.  This appears to be a problem when the second instance is
loaded, it fails, because the clock names already exist.  I am
inquiring to you as how you'd prefer to see the clock names generated
so we can do multiple instances. I am planning on using kasprintf and
following a pattern similar to drivers/clk/keystone/sci-clk.c.

Secondly, our Versaclock chips are un-programmed, so we need to both
enable the clock signal and set the output type which means adding a
few device tree options.  I am curious to know if you have an opinion
on how the new flags should be named.

Lastly, we're going to use the versaclock to drive multiple devices,
and some of them do not call the function to enable the clocks, so we
need some method to force the clocks on.  Is there a method to forcing
the clock outputs on similar to a gpio-hog holding a GPIO line in a
known state?

thank you,

adam

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

* Re: Versaclock usage and improvement question
  2020-03-24 17:15 Versaclock usage and improvement question Adam Ford
@ 2020-03-24 17:30 ` Marek Vasut
  0 siblings, 0 replies; 2+ messages in thread
From: Marek Vasut @ 2020-03-24 17:30 UTC (permalink / raw)
  To: Adam Ford, Michael Turquette, Stephen Boyd, linux-clk,
	Linux Kernel Mailing List

On 3/24/20 6:15 PM, Adam Ford wrote:
> Marek,

Hi,

> I am working on a board that uses two versaclock chips using different
> i2c buses, but it appears to the driver is hard-coding the names of
> the clocks.  This appears to be a problem when the second instance is
> loaded, it fails, because the clock names already exist.  I am
> inquiring to you as how you'd prefer to see the clock names generated
> so we can do multiple instances. I am planning on using kasprintf and
> following a pattern similar to drivers/clk/keystone/sci-clk.c.

I never had a board with two of them indeed, sorry.

> Secondly, our Versaclock chips are un-programmed, so we need to both
> enable the clock signal and set the output type which means adding a
> few device tree options.  I am curious to know if you have an opinion
> on how the new flags should be named.

I'd say, send an RFC patch and let's move on from there ?
The chips I use are factory pre-programmed btw.

> Lastly, we're going to use the versaclock to drive multiple devices,
> and some of them do not call the function to enable the clocks, so we
> need some method to force the clocks on.  Is there a method to forcing
> the clock outputs on similar to a gpio-hog holding a GPIO line in a
> known state?

I think something around assigned-clock DT props might help here ?

-- 
Best regards,
Marek Vasut

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

end of thread, other threads:[~2020-03-24 17:30 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-24 17:15 Versaclock usage and improvement question Adam Ford
2020-03-24 17:30 ` Marek Vasut

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).