On Thu, Sep 9, 2010 at 2:55 PM, Grant Likely <[email protected]> wrote: > On Thu, Sep 09, 2010 at 02:29:22PM +0900, Jassi Brar wrote: >> On Thu, Sep 9, 2010 at 2:11 PM, Grant Likely <[email protected]> >> wrote: >> > On Fri, Sep 03, 2010 at 10:37:10AM +0900, Jassi Brar wrote: >> >> Newer SoCs have the SPI clock scaling control in platform's >> >> clock management unit. Inorder for such SoCs to work, we need >> >> to check the flag clk_from_cmu before making any clock changes. >> >> >> >> Signed-off-by: Jassi Brar <[email protected]> >> > >> > Would it not make sense (or be possible) to roll the current clock >> > behaviour into the current clock struct so that this driver can always use >> > the same API for dealing with its clocking? Or am I missing something? >> > >> >> The problem is, earlier SPI had clock control/scaling in it's own IP, >> whereas latest(and in future) >> SPIs have them moved out into the Clock-Management-Unit of the SoC - >> just how it should be. >> In order to have common API, we need to hack clock-api to manipulate >> SPI controller >> registers outside of the SPI driver for older SPIs.... which wouldn't >> be very nice to see. >> any suggestion is welcome, though. > > Fair enough, not an ideal situation regardless of the approach. Your > approach is probably better then.
Ok, I am resending after squashing it with 5/6 ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
