On Fri, Feb 28, 2014 at 15:34 -0800, Soren Brinkmann wrote: > > [ MMIO registers assumed for clock control modules, but I2C > communication may be involved in other hardware, individual for > a (set of) clock(s) and not for an architecture or platform ] > > Does anybody have a good idea how we could avoid all this code > duplication while enabling usage of the clock primitives with different > IO accessors? > Especially the divider and mux primitive have a lot of code that would > be painful to maintain twice.
Hasn't past discussion already reached the point where code duplication of the clock control logic was considered undesirable, and "low level ops" were outlined? I.e. extending the compile time decision for a specific clk_{read,write}l() implementation by another potential redirection that is specific to a clock item? Re-submitting a series which duplicates complete clock types, while the difference is only in how registers get accessed, is quite saddening. > In the next step, I encountered a divider clock whose divider is stored > in 2 I2C registers. So now, the simple IO access replacement doesn't > work anymore either since this clock needs 2 registers to be read and > then shifting around the bitfields accordingly. Are the registers adjacent and contain only bit fields for one clock? Or do registers share parameters for several clocks, or are not adjacent? In the former case you may use a table from "divider value" to "bit pattern to read/write". In the latter case, the clock control module is rather special, and may not be easily get mapped to the common primitives. Unless the ll_ops can implement the required special handling. virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/