Reading the temperature from another module
Hi everybody,
I wrote some drivers for an embedded box. In one of these drivers I need the
current system temperature.
My system works with the jc42.c driver and I can read the temperature perfectly
via the proc filesystem in user space.
How do I query the temperature from another kernel driver?
First of all I added a new function and exported the symbol
int jc42_get_temperature()
{
int temp;
// TODO get the correct temp
temp = jc42_read_value(my_local_client, JC42_REG_TEMP);
return temp;
}
EXPORT_SYMBOL(jc42_get_temperature);
BUT: how do I get the temp? Most of the internal functions require a struct
device or a struct i2c_client, which - I assume - are perfectly provided by the
kernel when going the way over the proc file system.
I tried to statically save such a struct during the probing process (this is
the above my_local_client), but this works neither. When I use the saved struct
to call jc42_read_value, I always get a temperature value which is not correct
at all.
Kernel is 2.6.29.6-rt24 (yes, jc42 is originally not included there - we ported
it from a newer kernel release.)
Thanks for any help!
Matthias
--
To unsubscribe from this list: send the line unsubscribe linux-embedded in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Embedded Linux Boot Time Poll
Hi Andy, Talking about boot time with Linux needs to cover how user space initialization is done. I'm talking about init runlevels and all of this inherited functionality from System V. This is a software issue and although it worked fine for years in servers and desktop systems, it is not the right option for embedded systems dedicated to final users like mobile phones, cameras, minilaptos, tablets, ... . As you probably know, there are people working in this specific part trying to improve the way Linux is doing this things like avoiding shell scripts as much as possible and doing things in parallel when dependencies do not exist. By other hand, some embedded systems, those gaining main attention, are clearly closer to generic purpose Linux systems as we know them and it will be even more difuse in the close future. But generic purpose and boot time reduction should not be incompatible. Andrew Murray amur...@mpcdata.com ha escrito: Hello, I'm performing some research [for a CELF presentation] into reducing boot time on embedded systems and would like to see if the embedded community agree with the following statement as to why Linux [arguably] takes so long in the first place for an unoptimised system: Linux is general purpose, convenient and flexible. As it's general purpose it's likely to contain un-required functionality which results in more initialisation and a larger image size. As it's convenient and flexible it will spent time discovering devices and verifying their existence. Do you largely agree or disagree? Also do you believe that boot time isn't the highest priority when it comes to improving the kernel? Thanks, Andrew Murray -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Embedded Linux Boot Time Poll
On 22/10/10 00:20, Andrew Murray wrote: Hello, I'm performing some research [for a CELF presentation] into reducing boot time on embedded systems and would like to see if the embedded community agree with the following statement as to why Linux [arguably] takes so long in the first place for an unoptimised system: Linux is general purpose, convenient and flexible. As it's general purpose it's likely to contain un-required functionality which results in more initialisation and a larger image size. As it's convenient and flexible it will spent time discovering devices and verifying their existence. Do you largely agree or disagree? Also do you believe that boot time isn't the highest priority when it comes to improving the kernel? Thanks, Andrew Murray From my experience, your statements are broadly correct. As has been pointed out, there are techniques to optimise the boot time in a system, but they are not very well known to the majority of engineers working on embedded Linux devices. The situation is not helped by the poor choices made by many board and chip level vendors who bundle a Linux tool chain and rootfs with their hardware. So, I believe that it is mostly a problem of education, starting with the chip- and board- vendors. Bye for now Chris Simmonds -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
