Laurent Pinchart wrote:
The clean solution would be to have an abstracted clock API, similar to
phylib, where the caller doesn't know details about BRGs and such.
Maybe the linux/clk.h API would be suitable; I haven't looked at it in
detail.
The clock API would have to be quite advanced to express things like "the SCC4
clock is a combination of BRG2 and BRG5" (and I don't even consider
adding "with BRG2 set to 16x the baud rate and BRG5 to the baud rate").
What I was picturing was platform code providing a clock object that the
cpm_uart driver could be pointed at (possibly by modifying the device
tree in platform init); the knowledge of the multiple BRG weirdness
would be contained in platform code.
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
