On Tuesday 09 December 2008, Alessandro Zummo wrote:
> I'm just trying to understand if it does make sense to have
> one driver that can handle very simple platform devices
> that provide stateless get/set functions.
Other than the state held inside the RTC ... it's hard
to find any RTC driver that's not "stateless" like that!
That doesn't seem like a good motivation for adding one
more abstraction layer. The use-cases I saw for the
rtc-ppc code were different: reuse an existing layer,
to help phase it out gradually.
From what I've seen of the rtc-firmware thing, it would
not help in this case. I think much the same accounting
would apply in other cases where there wasn't an existing
framework to wrap.
~/kernel/dm355/drivers/rtc$ nm --size-sort -S rtc-dm*o | egrep ' t '
00000000 00000004 t __initcall_dm355evm_rtc_init6
00000000 0000001c t dm355evm_rtc_exit
00000000 0000001c t dm355evm_rtc_init
... that init/exit overhead is essentially fixed
00000000 00000024 t dm355evm_rtc_remove
00000000 00000068 t dm355evm_rtc_probe
... while probe()/remove() would essentially be
... what rtc-firmware provides, along with new
... wrappers that call the set/read time methods
00000000 0000007c t dm355evm_rtc_set_time
0000007c 00000100 t dm355evm_rtc_read_time
~/kernel/dm355/drivers/rtc$ nm --size-sort -S rtc-dm*o | egrep ' d '
00000000 00000004 d __exitcall_dm355evm_rtc_exit
... also fixed overhead
00000050 00000030 d dm355evm_rtc_ops
... maybe rtc_ops could shrink
00000000 00000050 d rtc_dm355evm_driver
... also fixed overhead, if there's a platform_device
So the *most* rtc-firmware could do here is morph the ops table
into 8 bytes, replacing the probe/remove logic with more complex
code that takes up more space (since it's got to do the same thing
PLUS provide wrappers) ... and is less obvious.
- Dave
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
