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