On Wed, Jun 19, 2013 at 08:26:12PM +0200, Tomasz Figa wrote:
On Wednesday 19 of June 2013 18:40:47 Mark Brown wrote:
ret = pd->get_signal(plchan->cd);
ret = (pd->get_signal)(plchan->cd);
Hmm, that's strange. The former is a completely valid piece of code...
I know, hence...
to get it to build which makes me suspect the compiler a bit as well...
...my comment about suspecting the compiler.
I was applying this to -next, are there any other dependencies I need or anything?
Hmm, I've been testing this on top of my common clock framework and device tree patches, but I don't think this had any effect. Did you add necessary clkdev lookups to the clock driver?
No, I didn't - that's most likely it, I didn't really investigate. I didn't test the watchdog stuff as the clocks didn't get sent to me.
In Samsung CCF alias notation it looks like this:
ALIAS(HCLK_DMA1, "dma-pl080s.1", "apb_pclk"),ALIAS(HCLK_DMA0, "dma-pl080s.0", "apb_pclk"),
Not sure how hard it will be to add such lookups to the old clock driver, though.
It's pretty much the same providing you know which clock needs to be used.
I will test this applied directly on top of current linux-next when I find some time, but for now you might check out my v3.11-devel branch on my github:
Will try to get round to it.