Wrong revision numbers on Fedora about rppal HOT 17 CLOSED

@KuabeM @drahnr so just for fun, I made a quick proof of concept polling interrupts using the GPIO character device, and added the cdev_gpio_poll_interrupt() method to Gpio to experiment with. It'll block until the interrupt is triggered. Would either of you mind checking if it works on Fedora, or if it's bugged like the sysfs interrupts?

extern crate rppal;

use rppal::gpio::{Gpio, Trigger};

fn main() {
    let gpio = Gpio::new().unwrap();
    println!("{:?}", gpio.cdev_gpio_poll_interrupt(27, Trigger::RisingEdge).unwrap());
}

from rppal.

Here you go:
On the 3B:

cat  /sys/firmware/devicetree/base/model
    Raspberry Pi 3 Model B% 
cat /sys/firmware/devicetree/base/compatible
    raspberrypi,3-model-bbrcm,bcm2837%  

And on the 2B:

cat  /sys/firmware/devicetree/base/model
    Raspberry Pi 2 Model B%  
cat /sys/firmware/devicetree/base/compatible
    raspberrypi,2-model-bbrcm,bcm2836% 

That looks not that bad does it?

from rppal.

Indeed. That definitely seems like a good alternative, and makes things a bit easier than dealing with manually setting the model. Thanks for the quick reply with the needed info. Time to dig up some earlier models, and make sure they didn't change the format at some point like they did with revisions.

This looks like an easy fix, which I should be able to squeeze into the upcoming 0.7.0 release scheduled for this week.

from rppal.

Awesome! Thanks for testing. 0.7.0 should be available through crates.io later today.

from rppal.

@golemparts @KuabeM (<- as promised) added a tracking ticket for GPIO IRQs not working on Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1597577 (proper Fedora, FedBerry might be a differnt story)

from rppal.

Awesome. While researching alternatives yesterday, I learned that the sysfs gpio interface has been deprecated, so I would have to replace the existing interrupt code at some point anyway. If it's also a workaround for the Fedora bug that would be a nice bonus!

I'll move this to a new issue for more convenient tracking.

from rppal.

@KuabeM if that works we move back to fedora as soon as that got implemented (:

from rppal.

Your prove of concept works just fine on Fedora. I also tried the master branch in our project - no more bugs, everything is running flawless 🎉

from rppal.

Thanks for reporting this issue! /proc/cpuinfo has been less than reliable on Raspbian as well, forcing me to ignore the Hardware field, and now it seems Revision can't be trusted either...

Could you check the output of cat /sys/firmware/devicetree/base/model and cat /sys/firmware/devicetree/base/compatible for me on both your 2B and 3B? I may be able to use that as an alternative when /proc/cpuinfo doesn't provide enough information.

from rppal.

Sounds great, thanks for your effort!

from rppal.

@KuabeM the latest commit in the master branch should fix this. When you have a chance, could you give it a try on Fedora to make sure it works as expected?

from rppal.

I'll be back at work tomorrow morning, first thing I'll do!

from rppal.

Works like a charm!
Device info on the 3B: Model: Raspberry Pi 3 B (SoC: BCM2837A1)
And on the 2B: Model: Raspberry Pi 2 B (SoC: BCM2836)

Thanks for the great and fast work 😄

from rppal.

@drahnr @KuabeM that's unfortunate. RPPAL's interrupt functionality is based on the gpio sysfs interface as described in the kernel documentation. There are alternative ways to implement support for interrupts on the Pi, but they all require busy waiting which doesn't really make them viable.

from rppal.

@golemparts I am totally with you, thus the above issue. Busy looping is just plain silly in this context.

from rppal.

@drahnr it looks like there actually might be an alternative in the form of the relatively new GPIO character device, but considering the major overhaul that would take, and the sysfs solution working as intended on Raspbian, switching interfaces just for Fedora isn't a priority at the moment. I do plan on researching it more in the future though. Let's hope the Fedora bug you reported is easy to fix.

from rppal.

Wow sure, I'll probably have time for it on Sunday or Monday!

from rppal.