On Sun, Sep 01, 2013 at 03:07:26PM +0200, Jonas Bonn wrote: > Hi Stefan, > Cool! Glad to see that you're on this track now... the SPI driver > changes look really good in general. > > That said, I've been working on the common clock bits, too... see: > > http://git.openrisc.net/cgit.cgi/jonas/linux/commit/?h=wip&id=913eedad91fe4ad082d7198174a414b436f51482 >
Heh, seems I'm stepping a bit on your toes there, well better that two persons try to solve the same problem than none =) > That's on a branch with the very descriptive name "wip" in my git > repo. The following commit is relevant, too. > > The trouble I've been having is how to get BASE_BAUD to work with > these changes. Without that, we lose the early serial console. Not a > big deal for production use, but annoying for development. > > As you've probably figured out by my lack of responsiveness, I'm a bit > pressed for time at the moment and don't have time right now to dig > into this in any depth. It would be great if you could grab those two > patches from my tree, squash them together, and massage your changes > on top of that. The jist of it is that the CPU frequency is also > driven by the oscillator and the bus frequency is a function thereof, > the details of which come entirely from the device tree description. > I took a quick look, and your changes are not really clashing with the driver patch I sent to lkml, but they *do* render it needless for OpenRISC. (All it does is essentially what you do in kernel/time.c, but as a driver with "fixed-clk" in the match table). I have to still say that it's a bit backwards how it currently works in the kernel, defining a fixed-clock in the dts should, IMO, just work(tm). Without any arch/soc/board needing to initialize it. So perhaps that patch has a place anyways, in that form or another. Let's see if there will be any comments on it, or if it'll just be ignored ;) I'll be happy to poke around your wip and see what falls out from it, because you're absolutely right what you said in the other mail, it'd be really great to have our common clock setup sorted out. I've got a couple of other things in the pipeline (you're not the only one that is busy =)) that I'm going to give higher priority, but this will still be among the top ones. > The SPI driver is not upstream... once we have the common clk bits in > place, that driver becomes arch independent and it should go upstream > via the SPI maintainer. > Actually, for the driver itself, there's no question marks regarding how it handles the common clock framework. That is not going to change whatever way we come up with to define the clocks within OpenRISC. So I'd say it's in pretty good shape for upstreaming, as of today. But as you indicated in the other mail, after a bit more test usage. I have tested it on my de0 nano board together with a touch screen controller and a spi flash, that have worked flawlessly so far. Stefan _______________________________________________ Linux mailing list Linux@lists.openrisc.net http://lists.openrisc.net/listinfo/linux
