I don't believe there's a way to access them from userspace but I
assume the driver could be enhanced to allow interaction via sysfs or
debugfs. You should be able to disable Linux's ability to control the
TPS65217 by not including it in the board-file and disabling it in the
kernel config, but then you'd probably end up with a separate kernel
for your testing vs production, which might not be what you want.
If you want low level register read and write and you don't need it to
be from Linux, u-boot allows I2C access to the TPS65217 fairly easily
and can be scripted.
-Andrew
Hi Andrew,
Thanks a lot for the reply. I can’t do it in UBoot as there are few others tests for which anyway I need to use linux. This is an automated test framework where you just start one script and wait for the final report.
I tried ‘-f’ option (forcibly take the ownership) with i2cset and it worked for me. Since, I am only reading the registers, I believe it won’t affect operations of kernel PMIC regulator driver, except that it clears some clear-on-read status registers. This might cause PMIC driver to miss few interrupts. It should not be a problem in production testing context.
As you mentioend, exposing the driver to user space through sysfs or debugfs would be convinient. It is the request for the author of the driver (I think Anil Kumar from TI). I have sent the same query to him directly; but yet to receive any reply.
Regards
Aravinthan
Thanks a lot for the reply. I can't do it in UBoot as there are few
others tests for which anyway I need to use linux. This is an
automated test framework where you just start one script and wait for
the final report.
Meh, that's what serial ports are for. Load a u-boot image over UART0,
do u-boot tests, then let it boot to Linux for the rest.
Out of curiosity, what test framework are you using?
I tried '-f' option (forcibly take the ownership) with i2cset and it
worked for me. Since, I am only reading the registers, I believe it
won't affect operations of kernel PMIC regulator driver, except that
it clears some clear-on-read status registers. This might cause PMIC
driver to miss few interrupts. It should not be a problem in
production testing context.
Good to hear it is accessible from userspace.
Last I knew, the PSP kernel didn't do anything with the interrupts
anyway. Maybe that's changed recently or mainline's getting it,
though. I haven't been keeping up.
As you mentioend, exposing the driver to user space through sysfs or
debugfs would be convinient. It is the request for the author of the
driver (I think Anil Kumar from TI). I have sent the same query to
him directly; but yet to receive any reply.
That'd be nice to have.
-Andrew