02:20 <wens> naoki: why would you need to define the pin function? it should be that when you request the GPIOs, they are automatically muxed to the proper GPIO functions

04:34 <naoki> well

04:35 <naoki> xxx {

04:35 <naoki> gpio_pins: gpio-pins {

04:35 <naoki> <1 RK_PB1 RK_FUNC_GPIO &pcfg_pull_up>,

04:35 <naoki> <1 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>,

04:35 <naoki> rockchip,pins = <1 RK_PA7 RK_FUNC_GPIO &pcfg_pull_up>,

04:35 <naoki> <1 RK_PB2 RK_FUNC_GPIO &pcfg_pull_up>;

04:35 <naoki> };

04:35 <naoki> };

04:36 <naoki> I'm using linux/tools/gpio/gpio-hammer.c for testing

04:37 <naoki> without this hack, nothing is changed with gpio-hammer

04:40 <naoki> wens: if pin function is not GPIO, user(land) cannot change pin state. am I wrong?

04:42 <naoki> (these are RK3399 SPI1 pins)

04:43 <naoki> I'm sure spi1 is disabled in dts

04:43 <naoki> and on running machine

04:45 <naoki> ah... user(land) cannot change pin state _as GPIO_

04:46 <naoki> I have no idea why these pins are not GPIO by default

04:46 <naoki> maybe maskrom/bootloader change function?

05:29 <underpantsgnome[> <amstan> "underpantsgnome: i'm willing..." <- Thanks, but my main question was about non-video I/O like ethernet... I guess keyboard + mouse would just need USB hub passed along via USB-C port but I want to know if these and especially ethernet work independently of the proprietary blob required for USB-C Alt Mode DP video output... can I have ethernet + USB hubs (also TF cards on hubs) without the DP Alt Mode blob?

05:37 <underpantsgnome[> <phh> "hanetzer: you already tried..." <- phh: when you say there are "@rock-chips.com developers there" does this mean official Rockchip employees? Not sure because the domain is registered but no host is up there.

05:42 <underpantsgnome[> <phh> "hanetzer: you already tried..." <- hmmm HTTP on port 443 for lists.infradead.org redirects to some openwrt thing

05:52 <underpantsgnome[> <hanetzer> "mmind00: also Mr. Glass said you..." <- hanetzer: What are you trying to do, get serial input/output via a USB-C port?

05:54 <hanetzer> underpantsgnome[: if that would work, sure, but my reading of the docs is that the type c are not 2.0, which is where the usb2uart redir works on. my current attempt is uart via sdcard

05:54 <underpantsgnome[> > <@tinybronca:sibnsk.net> > <@amstan:hypertriangle.com> underpantsgnome: i'm willing to bet vga, hdmi and dvi are just using DP alt mode with a converter

05:54 <underpantsgnome[> >

05:54 <underpantsgnome[> > Thanks, but my main question was about non-video I/O like ethernet... I guess keyboard + mouse would just need USB hub passed along via USB-C port but I want to know if these and especially ethernet work independently of the proprietary blob required for USB-C Alt Mode DP video output... can I have ethernet + USB hubs (also TF cards on hubs) without the DP Alt Mode blob?

05:54 <underpantsgnome[> this ethernet / keyboard/mouse/USB-hub / TF card question via USB-C is about RK3399 variants btw

05:54 <hanetzer> input works. not output tho.

05:55 <underpantsgnome[> hanetzer: via sdcard? Have a foto of what that looks like physically connector style? :)

05:55 <hanetzer> sparkfun microsd breakout. nothing worth the hassle of getting my phone out and uploading to $image_sharing_site.com

05:57 <underpantsgnome[> hanetzer: search term is enough, thanks!

05:58 <underpantsgnome[> also hanetzer, since you seem to have RK3399 hardware on hand, can you get ethernet + extra USB port functionality via a USB-C hub without that DP Alt Mode blob?

05:58 <hanetzer> np.

05:58 <hanetzer> no idea. I'm more concerned with why its simply not booting ;P

05:58 <underpantsgnome[> Oh wow I had no idea it was not booting, wellll

05:59 <underpantsgnome[> is higher important

05:59 <hanetzer> I mean. it may be booting.

05:59 <hanetzer> but idk, becuase all I see is about an inch of the bottom of the screen glitch/corrupt and then nothin :P

06:01 <underpantsgnome[> Hmm, curious how it got in that state. You may need to rewrite contents of SPI flash

06:02 <underpantsgnome[> assuming your board boots from there first?

06:04 <hanetzer> oh, u-boot is fine. its at the point of bootm/booti that it borks.

06:05 <underpantsgnome[> I'm not even sure what bootm/booti are, sorry

06:06 <hanetzer> commands you execute from u-boot to boot two kinds of kernel images

06:08 <underpantsgnome[> hanetzer: Okay well it sounds like part of u-boot? You don't think recompiling and replacing the entire thing would help?

07:11 <wens> naoki: how are you using the GPIOs from userspace exactly? as soon as you request the GPIOs, either from sysfs or the gpio chardev, the gpio driver should mux the pins properly

07:13 <naoki> wens: I just use gpio-hammer

07:17 <naoki> I think, if I request the GPIO which is used as another function, gpio driver should not override pin mux configuration...

07:22 <naoki> ah, well

07:22 <naoki> what happen is something strange

07:24 <naoki> those pins are displayed as "unused" from userspace

07:24 <naoki> so gpio-hammer doesn't return error

07:27 <naoki> gpio-hammer is running, but pin state is not changed

07:29 <naoki> sorry, it's too complicated to explain... :(

10:37 <naoki> $ grep interrupts.*GPIO_ACTIVE_ *dts

10:37 <naoki> rk3399-eaidk-610.dts:interrupts = <RK_PA3 GPIO_ACTIVE_HIGH>;

10:37 <naoki> rk3399-rock-pi-4b-plus.dts:interrupts = <RK_PA3 GPIO_ACTIVE_HIGH>;

10:37 <naoki> hmm...

14:04 <robmur01> yeah, that's a funny way to say IRQ_TYPE_NONE :)

14:12 <robmur01> FWIW I had a funny thing on my Nanopi R2S where the pinmux doesn't get set properly if GPIOs are claimed too early (for some indeterminate value of "early") - I had to manually unbind and rebind the leds-gpio driver to make the LEDs actually behave properly

14:13 <robmur01> been a while since I last fired that one up though

14:16 <robmur01> ha, I see patches on the list specifically fixing userspace GPIOs, so that's clearly its own thing :)

15:39 <naoki> "fix gpio-sysfs/libgpiod for rockchip"

15:41 <naoki> I have to throw away my crazy hack happily!