Re: [alsa-devel] [RFC PATCH 00/11] ARM: s3c64xx: Let amba-pl08x driver handle DMA
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.
(Apologies if this is mangled, fighting both Outlook and remote desktop :-( )
linux-kernel-owner@vger.kernel.org wrote on Behalf Of Mark Brown
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.
Can you just make that minimal change, and diff the objdump of the two .o's? It would be worth a bug-report against the toolchain if different code was being generated. If objdump spews huge numbers of diffs (due to one address changing and pushing everything else out of kilter), then feel free to forward both .o's or both objdumps to me, and I can run a script over them, which knows to ignore unimportant address changes.
Praying that this mail is readable to you, as it's not readable as I write it, Phil
On Thu, Jun 20, 2013 at 12:24:47PM +0300, Phil Carmody wrote:
Can you just make that minimal change, and diff the objdump of the two .o's? It would be worth a bug-report against the toolchain if different code was being generated. If objdump spews huge numbers of diffs (due to one address changing and pushing everything else out of kilter), then feel free to forward both .o's or both objdumps to me, and I can run a script over them, which knows to ignore unimportant address changes.
See Arnd's followup - this looks like a collision with the get_signal macro in signal.h.
-----Original Message----- On Thu, Jun 20, 2013 at 12:24:47PM +0300, Phil Carmody wrote:
Can you just make that minimal change, and diff the objdump of the
two .o's?
It would be worth a bug-report against the toolchain if different
code
was being generated. If objdump spews huge numbers of diffs (due to one address changing and pushing everything else out of kilter), then feel free to forward both .o's or both objdumps to me, and I can run
a
script over them, which knows to ignore unimportant address changes.
See Arnd's followup - this looks like a collision with the get_signal macro in signal.h.
With my language-lawyer hat on, I'd suggest ``(get_signal)'' to prevent the macro expansion:
/tmp$ cat crap.c
#define fnlikemacro(foo) foo+
int x(int y) { int (fnlikemacro) = y; return fnlikemacro(y)(fnlikemacro); }
/tmp$ gcc -E crap.c
int x(int y) { int (fnlikemacro) = y; return y+(fnlikemacro); }
(and yes, that compiles.)
However, it's more tempting (i.e. sensible) to just rename the one with the weaker claim to the name.
Phil
On Thu, Jun 20, 2013 at 02:14:53PM +0300, Phil Carmody wrote:
With my language-lawyer hat on, I'd suggest ``(get_signal)'' to prevent the macro expansion:
Right, which the patch I posted in the mail was doing IIRC.
However, it's more tempting (i.e. sensible) to just rename the one with the weaker claim to the name.
I sent a patch for that which Vinod has applied.
participants (2)
-
Mark Brown -
Phil Carmody