On Tuesday 15 April 2008 17:59, Scott Wood wrote: > 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.
I'll think about it. Thanks. -- Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75
pgpjHpnBG3l8p.pgp
Description: PGP signature
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
