How bad is bad? That other driver/device has stale data? The chip gets fried? Somewhere in between?
If I'm certain that my application is the only user space application accessing a particular pin, can I safely use /dev/mem for the speed increase? On Thursday, March 26, 2020 at 11:19:48 AM UTC-6, William Hermans wrote: > > > > On Thu, Mar 26, 2020 at 10:59 AM John Allwine <jo...@allwinedesigns.com > <javascript:>> wrote: > >> I'm happy to leave the pinmux alone, but if all I'm doing is reading or >> writing to the GPIO can I do so from /dev/mem? >> >> According to this post, it's about 1000x faster: >> http://chiragnagpal.com/examples.html >> >> It's also how hal_bb_gpio is implemented: >> https://github.com/machinekit/machinekit-hal/blob/master/src/hal/drivers/hal_bb_gpio/hal_bb_gpio.c >> >> If necessary, it could be rewritten to use sysfs, but if it means being >> 1000x slower, that's not ideal. >> > > I've used /dev/mem to access(read, and write), registers on the BBB and I > do agree. It is much faster. > > The reason why it's bad to use /dev/mem . . . is that there is no way for > the kernel to know what state a given "device" is in. That is, without a > physical read. Potentially, this could be bad. Especially if another driver > or application has access to the given hardware register. > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/ff844173-a117-4df6-b1d2-38b0c3c711c2%40googlegroups.com.
