DVB clock source (Re: [PATCH v2 4/5] tc90522: add driver for Toshiba TC90522 quad demodulator)

[Antti Palosaari <crope@iki.fi>]

On 09/06/2014 05:27 AM, Mauro Carvalho Chehab wrote:
> Em Sat, 06 Sep 2014 05:02:15 +0300
> Antti Palosaari <crope@iki.fi> escreveu:

>> Lets mention that I am not even now fully happy to solution, even it
>> somehow now works. Proper solution is implement clock source and clock
>> client. Then register client to that source. And when client needs a
>> clock (or power) it makes call to enable clock.
>
> Well, we need to discuss more about that, because you need to convince
> me first about that ;)
>
> We had already some discussions about that related to V4L2 I2C devices.
> The consensus we've reached is that it makes sense to use the clock
> framework only for the cases where the bridge driver doesn't know anything
> about the clock to be used by a given device, e. g. in the case where this
> data comes from the Device Tree (embedded systems).
>
> In the case where the bridge is the ownership of the information that will
> be used by a given device model (clock, serial/parallel mode, etc), then
> a series of data information should be passed by a call from the bridge driver
> to the device at setup time, and doing it in an atomic way is the best
> way to go.

For AF9033/IT9133 demod + tuner I resolved it like that:
https://patchwork.linuxtv.org/patch/25772/
https://patchwork.linuxtv.org/patch/25774/

It is demod which provides clock for tuner. It is very common situation 
nowadays, one or more clocks are shared. And clock sharing is routed via 
chips so that there is clock gates you have enable/disable for power 
management reasons.

Currently we just enable clocks always. Clock output is put on when 
driver is attached and it is never disabled after that, leaving power 
management partly broken.

Lets take a example, dual tuner case:
tuner#0 gets clock from Xtal
tuner#1 gets clock from #tuner0

All possible use cases are:
1) #tuner0 off & #tuner1 off
2) #tuner0 on & #tuner1 off
3) #tuner1 off & #tuner1 on
4) #tuner1 on & #tuner1 on

you will need, as per aforementioned use case:
1) #tuner0 clock out off & #tuner1 clock out off
2) #tuner0 clock out off & #tuner1 clock out off
3) #tuner0 clock out on & #tuner1 clock out off
4) #tuner0 clock out on & #tuner1 clock out off

Implementing that currently is simply impossible. But if you use clock 
framework (or what ever its name is) I think it is possible to implement 
that properly. When tuner#1 driver needs a clock, it calls "get clock" 
and that call is routed to #tuner0 which enables clock.

And that was not even the most complicated case, as many times clock is 
routed to demod and USB bridge too.

Quite same situation is for power on/off gpios (which should likely 
implemented as a regulator). Also there is many times reset gpio (for PM 
chip is powered off by switching power totally off *or* chip is put to 
reset using GPIO)

regards
Antti

-- 
http://palosaari.fi/