[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <458AEF79.5030600@billgatliff.com>
Date: Thu, 21 Dec 2006 14:32:57 -0600
From: Bill Gatliff <bgat@...lgatliff.com>
To: Nicolas Pitre <nico@....org>
CC: pHilipp Zabel <philipp.zabel@...il.com>,
David Brownell <david-b@...bell.net>,
Andrew Morton <akpm@...l.org>,
Linux Kernel list <linux-kernel@...r.kernel.org>,
Andrew Victor <andrew@...people.com>,
Haavard Skinnemoen <hskinnemoen@...el.com>,
Kevin Hilman <khilman@...sta.com>,
Russell King <rmk@....linux.org.uk>,
Tony Lindgren <tony@...mide.com>
Subject: Re: [patch 2.6.20-rc1 4/6] PXA GPIO wrappers
Guys:
>>Probably? What I am wondering is this: can the compiler
>>optimize away the range check that is duplicated in GPSR/GPCR
>>and GPIO_bit for __gpio_set/get_value? Or could we optimize
>>this case by expanding the macros in place (which would mean
>>duplicating code from pxa-regs.h)...
>>
>>
Who cares? :)
I don't think there's much point in optimizing here, since these
functions won't be hot paths anyway. Yes, they'll be called in
interrupt handlers and so we don't want them to be _too_ heavy, but
compared to the overhead of an interrupt handler, a few extra
instructions in the GPIO access will get lost in the noise.
Inlines generally seem to be more maintainable, give you a symbol that
you can disassemble and breakpoint, etc. I'll take them over the macro
implementations any day, in this case even if there's a cost of a few
instructions.
All IMHO, of course.
b.g.
--
Bill Gatliff
bgat@...lgatliff.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists