<tuxd3v>
wens, how could I enable chanel 1 or pwm?
lurchi__ has joined #linux-sunxi
lurchi_ has quit [Ping timeout: 480 seconds]
<tuxd3v>
wens, reg = <0x01c21400 0x8>; means base address plus 8 bytes right?
<hanetzer>
think its base and size.
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 480 seconds]
libv has quit [Ping timeout: 480 seconds]
libv has joined #linux-sunxi
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 480 seconds]
hlauer has joined #linux-sunxi
Nemo_bis has joined #linux-sunxi
jaganteki has joined #linux-sunxi
cmeerw has joined #linux-sunxi
cmeerw has quit [Ping timeout: 480 seconds]
gamiee has joined #linux-sunxi
gamiee has quit [Read error: Connection reset by peer]
gamiee has joined #linux-sunxi
<wens>
pwm1 is probably an error in the docs :/
dollroot_ has quit [Ping timeout: 480 seconds]
dollroot has quit [Ping timeout: 480 seconds]
tnovotny has joined #linux-sunxi
palmer has joined #linux-sunxi
prefixcactus has joined #linux-sunxi
buZz has quit [Remote host closed the connection]
<gediz>
smaeul: it's great if there's a patch for this. thank you.
<gediz>
megi: nope. i use LCD. iirc A13 does not have HDMI.
<gediz>
i feel like sun8i_dw_hdmi.c patch is not necessary, "sram consumer & supplier from DT" patch would probably be sufficient for A13 but i will try it. much appreciated.
buZz has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
<tuxd3v>
wens, it could be since the lestest datasheet revisions doesn't mention it.. but it coulc also be a error untroduved in last revisions datasheets..
<tuxd3v>
latest*
<tuxd3v>
could also be a errors introduced*
gsz has joined #linux-sunxi
<hlauer>
submitted my patch v3 for axp209 charge enable/disable on 12 May 2021 to the lists, but did not hear anything so far
<hlauer>
wens et al, could you please have a look?
<hlauer>
thanks!
choozy has joined #linux-sunxi
Mangy_Dog has quit [Remote host closed the connection]
<karlp>
is there any way to verify that a dtbo has been applied? the uboot log says it has, and I've got this fragment: https://paste.jvnv.net/view/3F6zx
<karlp>
but I don't seem to get pullups on uart2 rx at least.
<karlp>
is there a better wya than poking devmem at the pullup registers?
<karlp>
ok, zeros for my pits in the PA_PULLx registers, so I guess those overlays didn't really do the right thing :)
<karlp>
manually writing to to the port A pullup/down register doesn't result in a sufficient pullup anyway, an external pullup works, but would like to be able to diagnose and rely on these things more.
<karlp>
I have an entry /proc/device-tree/soc/pinctrl@1c20800/k_uart2_rx/ with a "bias-pull-up" file there, so it _should_ have been applied?
<mripard>
you want U-Boot to apply it, but it looks to be the case indeed
<mripard>
k_uart2_rx isn't a node in the kernel though, so you apply it at the wrong place
<karlp>
I thought the names were pretty much free text, or can yo uonly have one node addressing a given pin?
<karlp>
so given that there's also /proc/device-tree/soc/pinctrl@1c20800/uart2 which also covers PA0/PA1, does that mean mine gets ignored?
<mripard>
the names are free text, but only the nodes dereferenced in the spi controller pinctrl-* properties are going to be used
<mripard>
and the other ones completely ignored
<mripard>
so you want to modify those nodes, and not just add new ones
<karlp>
so that's the before: after { } names both right?
<karlp>
I've never really followed when I need which name, and why we need both :)
<mripard>
no, it's just your "after" that have to match
<karlp>
and I can apply something like bias-pull-up to only _one_ of the pins though?
<karlp>
uart2-pins is an existing node, with pa0/pa1, and I only want to apply to it rx.
<mripard>
then you need to create a new node entirely, and make the spi controller use it intsead
<karlp>
you mean it wouldn't mux the other pins to uart? it seems to at least.
<karlp>
so, I have a few gpios I've not yet setup in dt, leds and inputs. the leds work just fine in the sysfs interface, I know it's not a permanent solution, but just for testing the hardware it seems fine.
<karlp>
but the inputs, on PC0/PC3 dont work at all.
<karlp>
they export ok, but the values never change.
<karlp>
and the port C config register had PC0 and PC3 listed as just 0x7: IO disable.
<karlp>
manually pking that to 0x0: input, and now they work?
<karlp>
the led is on port A.
<karlp>
is this "user error using deprecated sysfs" or is there something else at play?
<karlp>
I have an output on PE12 that works fine too, this is only inputs.
prefixcactus has joined #linux-sunxi
<karlp>
python's gpiod (which uses the chardev) reports "No such device" for PC0,1,2,3 but works for PA6 and PE12, matching the sysfs experience.
<karlp>
I suspect spi0 is enabled when it shouldn't be...
qCactus has quit [Ping timeout: 480 seconds]
<karlp>
hrm, spi0 is disabled in dt at least.
<MoeIcenowy>
BTW, REing BROM of D1 today
<MoeIcenowy>
and I found that when doing FEL_VERIFY_DEVICE, tag is now used