On Thu, Nov 19, 2009 at 9:09 PM, Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> wrote: > Hello, > > On Thursday, November 19, 2009 12:49 PM Mark Brown wrote: > >> On Thu, Nov 19, 2009 at 11:38:41AM +0000, Russell King - ARM Linux wrote: >> >> > I'm not sure what you're commenting on precisely, but the Samsung code as >> > a whole doesn't use the clk API very well, and I suspect that is starting >> > to cause people to have to pass clock names around. >> >> That's what I'd thought originally but it's not quite the problem here. >> The issue is that Samsung serial port clock is chosen from a mux and the >> logic to select which of the inputs to that mux should be used is in the >> serial driver. This means that if the set of parent clocks changes then >> the serial driver needs to be told what they are. >> >> My suggestion was to push this logic down into the clock API so the >> serial driver just requests a rate and then clock API picks the best >> option from the mux. As well as being nicer from the clock API point of >> view this would also allow other drivers to use the same logic since >> these muxes are a standard idiom for Samsung SoCs. > > What if a device does not operate properly when clocked from one of the > available clock sources (lets say machine specific problem)? There must > be a way of setting which clock(s) should not be considered when calculating > best choice for particular device. That shudn't be a concern. for example, if some machine doesn't provide clock at some PAD, which could be used as a source, then the clock API wud read the clock as 0 and the calculations wudn't pick that source up. Likewise, any such 'unusable' clock in the machine wud be marked by having invalid(0) rates. The problem is moving this uart-mux into the the Clock API. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |