14:03 <narmstrong> xdarklight: hi, do you recall how you fixed occurence of https://pastebin.com/N1PhwwBf ?

14:04 <narmstrong> i recall having these on GXL

14:04 <narmstrong> but at some point it was fixed

14:04 <narmstrong> (it's for G12A)

14:05 <xdarklight> narmstrong: I believe it was you who found out that we need to set that 0x20 value which is why we have phy-meson-gxl-usb3

14:05 <narmstrong> xdarklight: hmm

14:05 <narmstrong> oh

14:06 <narmstrong> interesting, I set the usb3 regs :-/

14:06 <xdarklight> :/

14:06 <xdarklight> I think "phy-meson-gxl-usb3" is not really a PHY by the way

14:07 <narmstrong> xdarklight: yeah, it's kind of a glue for the usb3 phy, on G12A it talks to a true USB3 PHY

14:07 <xdarklight> yep

14:07 <xdarklight> we should probably re-implement it as dwc3-amlogic

14:07 <narmstrong> this one hasn't changed, except the USB3 PHY :-p

14:07 <xdarklight> and have a real G12A USB3 PHY driver

14:08 <narmstrong> yeap

14:08 <xdarklight> and the USB2 PHY obviously

14:08 <xdarklight> G12A has a new USB2 PHY

14:08 <narmstrong> usb2 phy has changed, and it split in two...

14:08 <narmstrong> now it's a glue, and the phy registers are separated

14:09 <narmstrong> so yeah, the best would be to have a dwc3-amlogic glue to setup this and have true PHY drivers

14:10 <xdarklight> narmstrong: re your G12A errors: maybe you need to set 0x20 on the dwc3 instance as well: https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/usb/dwc3.txt#L83

14:11 <xdarklight> (on GXL and GXM the dwc3 registers default to 0x20 for that value, so we don't have it there)

14:11 <narmstrong> let's check !

14:12 <xdarklight> narmstrong: also do you have the reset line hooked up?

14:13 <narmstrong> xdarklight: yep, each usb2 phy also have separate reset lines aswell

14:13 <xdarklight> finally!

14:14 <narmstrong> ok, this does not help, thanks for helping...

16:19 <garstyciuks> hey guys, I'm working on porting a kernel module to run on odroid C2, and hit an issue - I can't get GPIO interrupts to work at all

16:19 <garstyciuks> there's even no "edge" in /sys/class/gpio/.../ appearing after GPIOs are exported to user space

16:20 <garstyciuks> I have verified that running the 3.16 kernel that odroid officially supports, the 'edge' appears to be usable

16:20 <garstyciuks> I'm using 4.19.14 kernel version on armbian

16:21 <garstyciuks> the actual issue the kernel module I'm working on has is the gpiod_to_irq returns -6 (ENXIO 6 No such device or address), the GPIO itself is usable as input

16:22 <garstyciuks> so I just can't figure out how to attach a rising edge interrupt to the pin...

20:58 <xdarklight> garstyciuks: the mainline GPIO driver doesn't have GPIO IRQ support yet

20:59 <xdarklight> most of the code is there, but the final .to_irq call is missing because there was a discussion (for which I believe there was never a conclusion) how to model the IRQ domain inside the GPIO controller

21:53 <garstyciuks> hey, yeah, I think I found the discussion

21:54 <garstyciuks> I saw 'platform_get_irq' mentioned as an alternative way to get the interrupt to use for request_irq call

21:56 <garstyciuks> in my dt overlay, I have: interrupt-parent = <&gpio_intc>; interrupts = <109 0>;

21:57 <garstyciuks> platform_get_irq(pdev, 0) in the module probe then gives me some valid value, I haven't yet been able to test it, don't have access to the hardware at this time :)

21:58 <garstyciuks> but anyway, would this be the correct way to hook up a GPIO interrupt while gpio_to_irq is not implemented ?

21:58 <garstyciuks> I took 109 value from https://dn.odroid.com/S905/DataSheet/S905_Public_Datasheet_V1.1.4.pdf page 86, this is for GPIOX_3 pin

22:04 <xdarklight> garstyciuks: 109 seems correct

22:04 <xdarklight> garstyciuks: but I don't think you can use "109 0" in the .dts

22:05 <xdarklight> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts#L143 has an example - all possible values for the second cell are here: https://elixir.bootlin.com/linux/v5.0-rc5/source/include/dt-bindings/interrupt-controller/irq.h

22:05 <xdarklight> (the irq-meson-gpio driver forbids using IRQ_TYPE_EDGE_BOTH though)

22:06 <garstyciuks> I'm interested in IRQ_TYPE_EDGE_RISING, however, that gave me some 'type mismatch' error logged

22:06 <garstyciuks> when loading the overlay

22:06 <garstyciuks> IRQ_TYPE_LEVEL_LOW as in the example was loaded successfully as well

22:09 <garstyciuks> I don't have access to the log at the moment to tell the exact error that was printed in dmesg...