On Mon, Aug 01, 2016 at 07:12:45PM +0100, Mark Brown wrote: > On Fri, Jul 29, 2016 at 11:34:41PM -0400, Rich Felker wrote: > > > I was able to get it working via the clk api and I'll include support > > for this in the next version of the patch, but to actually use it > > depends on changing arch/sh to use the common clk framework; otherwise > > there's no way to provide a suitable clk in the DT and have > > [devm_]clk_get actually pick it up. Should I keep around the option of > > using clock-frequency too? That would be most convenient. > > It sounds like at the minute the devices all have one frequency anyway > in which case just having a default frequency in there that you fall > back to if you get -ENOENT from a failed clock lookup might be enough? Yes. 50 MHz is the natural default frequency, but I found out at the last minute from the hardware engineers that clocking the current SoC up to 62.5 MHz (for faster cpu) will require the SPI timing to be programmed based on the faster reference clock. This messes up the ability to get optimal SD card transfer rates, so we'll probably end up having a real 50 MHz clock for the SPI anyway, but I thought it was important to be able to handle this issue in the DT binding anyway. Since it's not an immediate need right now anyway I'll drop the clock-frequency property proposal and just use the more general clocks approach you suggested. Rich -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
