On 18-11-02 23:05, Trent Piepho wrote: > On Fri, 2018-11-02 at 07:38 +0100, Marco Felsch wrote: > > On 18-11-01 18:21, Trent Piepho wrote: > > > On Thu, 2018-11-01 at 08:14 -0700, Guenter Roeck wrote: > > > > On Thu, Nov 01, 2018 at 03:53:12PM +0100, Marco Felsch wrote: > > > > > > > > > > > > > > > > > Isn't that configurable with devicetree flags ? I don't think a driver > > > > > > should get involved in deciding the active edge. > > > > > > > > > > No, AFAIK we can only specify the active level types for gpios. This > > > > > made sense to me, because I saw no gpio-controller which support > > > > > 'edge-level' reporting (however it will be called) currently. > > > > > > Interrupts types are specific to each interrupt controller, but there > > > is a standard set of flags that, AFAIK, every Linux controller uses. > > > These include IRQ_TYPE_EDGE_BOTH, IRQ_TYPE_EDGE_RISING, > > > IRQ_TYPE_LEVEL_HIGH, and so on. > > > > > > So you can support hardware that is inherently edge or level triggered. > > > > I've been spoken about gpio-controllers and AFAIK there are no edge > > types. Interrupt-Controller are a different story, as you pointed out > > above. > > You can use edge triggering with gpios. Just try writing "rising" or > "falling" into /sys/class/gpio/gpioX/edge Can we access the gpios trough the sysfs if they are requested by a driver? > It's level you can't do sysfs. The irq masking necessary isn't > supported to get it to work in a useful way, i.e. without a live-lock > IRQ loop. > > But you can in the kernel. > > Normal process is to call gpiod_to_irq() and then use standard IRQF > flags to select level, edge, etc. Currently I using the gpiod_to_irq() function to convert the sense gpio into a irq, but I do some magic to determine the edge. I tought there might be reasons why there are no edge defines in include/dt-bindings/gpio/gpio.h. > > Too fast state changes sounds like a glitch. Anyway, IMHO we should > > Linux has no hard real-time guarantee about interrupt latency, so > there's no way you can be sure each interrupt is processed before the > next. > > Trying to track level by interrupting on both edges doesn't work well. > You get out of sync and stuck waiting for something that's already > happened. Yes, I'm with you. > > support support both interrupts and gpios. If the users use gpios they > > have to poll the gpio, as Guenter pointed out, else we register a > > irq-handler. > > If gpio(d?)_to_irq returns a valid value, why poll? It usually works > to call this. Plenty of call sites in the kernel that use it and don't > fallback to polling if it doesn't work. > > I think it's fine to call gpiod_to_irq() and fail if that fails, and > let a polling fallback be written if and when the need arises. Okay, so no polling for the current solution. Let me summarize our solution: - no polling (currently) - dt-node specifies a gpio instead of a interrupt -> gpio <-> irq mapping is done by gpiod_to_irq() and fails if gpio doesn't support irq's - more alarms per sensor Only one last thing I tought about: Using a flat design like you mentioned would lead into a "virtual" address conflict, since both sensors are on the same level. I tought about i2c/spi/muxes/graph-devices which don't support such "addressing" scheme. hwmon_dev { compatible = "gpio-alarm"; bat@0 { reg = <0>; label = "Battery Pack1 Voltage"; type = "voltage"; alarm-type = <GPIO_ALARM_LCRIT, GPIO_ALARM_CRIT>; alarm-gpios = <&gpio3 15 GPIO_ACTIVE_LOW &gpio3 16 GPIO_ACTIVE_LOW>; }; bat@1 { reg = <1>; label = "Battery Pack2 Voltage"; alarm-type = <GPIO_ALARM_LCRIT, GPIO_ALARM_CRIT>; alarm-gpios = <&gpio3 9 GPIO_ACTIVE_LOW &gpio3 1 GPIO_ACTIVE_LOW>; }; cputemp@0 { reg = <0>; label = "CPU Temperature Critical"; type = "temperature"; alarm-type = <GPIO_ALARM_GENRIC>; alarm-gpios = <&gpio4 17 GPIO_ACTIVE_LOW>; }; }; Where a more structured layout don't have this "issue". hwmon_dev { compatible = "gpio-alarm"; voltage { bat@0 { reg = <0>; label = "Battery Pack1 Voltage"; alarm-type = <GPIO_ALARM_LCRIT, GPIO_ALARM_CRIT>; alarm-gpios = <&gpio3 15 GPIO_ACTIVE_LOW &gpio3 16 GPIO_ACTIVE_LOW>; }; bat@1 { reg = <1>; label = "Battery Pack2 Voltage"; alarm-type = <GPIO_ALARM_LCRIT, GPIO_ALARM_CRIT>; alarm-gpios = <&gpio3 9 GPIO_ACTIVE_LOW &gpio3 1 GPIO_ACTIVE_LOW>; }; }; temperature { cputemp { label = "CPU Temperature Critical"; alarm-type = <GPIO_ALARM_GENRIC>; alarm-gpios = <&gpio4 17 GPIO_ACTIVE_LOW>; }; }; }; We don't have to take this layout, we can also consider about devices: hwmon_dev { compatible = "gpio-alarm"; dev@0 { reg = <0>; voltage { label = "Battery Pack1 Voltage"; alarm-type = <GPIO_ALARM_LCRIT, GPIO_ALARM_CRIT>; alarm-gpios = <&gpio3 15 GPIO_ACTIVE_LOW &gpio3 16 GPIO_ACTIVE_LOW>; }; temperature { label = "Battery Pack1 Temperature Critical"; alarm-type = <GPIO_ALARM_GENRIC>; alarm-gpios = <&gpio4 17 GPIO_ACTIVE_LOW>; }; }; dev@1 { reg = <1>; temperature { label = "CPU Temperature Critical"; alarm-type = <GPIO_ALARM_GENRIC>; alarm-gpios = <&gpio4 19 GPIO_ACTIVE_LOW>; }; }; }; I don't think that is a issue at all, but I don't know the dt maintainers opinion of this theme. Regards, Marco