Em Sat, 06 Sep 2014 06:00:28 +0300 Antti Palosaari <crope@xxxxxx> escreveu: > On 09/06/2014 05:27 AM, Mauro Carvalho Chehab wrote: > > Em Sat, 06 Sep 2014 05:02:15 +0300 > > Antti Palosaari <crope@xxxxxx> 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) Ok, in the above scenario, I agree that using the clock framework makes sense, but, on devices where the clock is independent (e. g. each chip has its on XTAL), I'm yet to see a scenario where using the clock framework will simplify the code or bring some extra benefit. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
