Search results

Okay, I got it to work now. This upstream patch is needed for Letux-5.6 kernel: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5afc1540f13804a31bb704b763308e17688369c5 You might also need to remove and insert the palmas_gpadc kernel module if something goes wrong...

I'm able to reproduce the issue and I'll take a look when I get the time :)

Okay, rookie mistake: I forgot to compile the device tree for every build :oops: Will try Letux-5.6 again now

Hmm... I can't get this kernel to boot on my devboard :( might be missing a cmdline parameter? I'll give this one a try Then maybe try this one :D

Great! I'll have a look and see if I can reproduce the issue. Is this Letux-5.6.19 kernel or mainline? I'm gonna assume Letux-5.6.19 and pyra_defconfig :) There are 2 sysfs/iio files to read data from: * in_voltage1_raw * in_voltage1_input The first one will give you the raw ADC values...

Yes, exactly. That chip is already always on

I've been tinkering with a different solution to this issue in in another thread. It uses the builtin threshold feature of the palmas gpadc chipset which only wakes up the Cortex-A15 when the volume wheel moves. It requires an updated kernel driver which is already on its way into the Letux...

One little fun thing I noticed with my volume wheel is that it is very capacitive (I think) so when I turn it quickly, the voltage reading overshoots xD I wonder if the little pyra wheel has the same issue? :oops:

Some updates! :D I re-soldered my volume wheel to my board and added some hot glue to keep it in place this time. I used makesd --debug -vk latest omap5432evm to get the latest Letux-6.1-rc4 kernel and Debian rootfs. Then I copied over my latest changes to the board and did some development...

@Asaggynoodle already reached out to me in June and asked if I wanted to buy one, but I respectfully declined. I've already pre-ordered a EU mobile version and the devkit I already have is (mostly) enough for tinkering. I imagine the devkit is even easier to tinker with for the really low-level...

Yeah, that's the idea. My application only forwards the mV and sets some requirements on threshold values. I think that's a sane approach

Hmm... Maybe. Might be odd if values jump from near min to 0. The output value could also be scaled between min and max, but then you loose what real mV it was

Yeah, I guess you're right. I'm a sucker for premature optimization and sometimes I need to get a hold of myself. :) Yes, both reading the value and calculating the new lower threshold is part of the same function. The problem was that for values close to 0, the calculated lower threshold would...

Yes, I had an issue when mV reached below the step (defaults to 25) value. The low threshold value is calculated as: low_threshold = MAX(0, current_mv - step) This effectively clamps the value to 0 or higher. However, setting the lower threshold to 0 led to continuous interrupts so I just...

CARD="$($SCRIPTPATH/findsoundcard -a | head -1)" # first channel CARD=L15 # this is the sound card... xD Yeah, that one is tricky. Unless I disabled the lower threshold trigger, it would repeatedly wake me up again. I believe there was some kind of unit conversion between raw ADC values...

What's the current status of the audio driver? Last info I heard was this little snippet of news from ED: The TWL6040 Audio Companion IC is also on the OMAP5432 devboard if I'm not mistaken

I'll take a look at this script!

Ah, yes, of course! Fix pushed to the repo now. I'll see if I can add any more unit tests for this, and test it out myself when I get home again tomorrow

Okay, I've updated the repo with your suggestions: https://github.com/Risca/pyra_vol_mon It should work to just run ./pyra_vol_mon /bin/echo The program takes the following options: Usage: pyra_vol_mon [OPTION]... EXECUTABLE Monitor palmas_gpadc ADC channel and run EXECUTABLE when input...

You shouldn't run minicom as root. It's better to add your user to the dialout group instead: https://askubuntu.com/a/210230