vpeter has quit [Remote host closed the connection]
vpeter has joined #linux-sunxi
<tokyovigilante>
I've had HDMI working with 6.9, and have the LCD working now, so I don't think so, and I don't think the A10-based drivers use a 2x video clock, but I'm not acros the details
<loki666>
HDMI is still not working for me... Display pickup the signal, but it's just a static garbage
<loki666>
Is your LCD branch testable?
<loki666>
Fixed my WiFi, not sure yet which kconfig was missing or wrong
<loki666>
I have a small config fragment I can start playing with
<tokyovigilante>
you only need earlycon if you're not getting any console output early in boot, and drm.debug is helpful for the LCD and HDMI work
<tokyovigilante>
I've stopped work on the anbernic-lcd branch, and am about to push a new anbernic-display branch which will be the mainline WIP branch
<tokyovigilante>
quite a few components so will likely be a group of patchsets for DE, LCD panel, TCON, etc
<tokyovigilante>
then need to solve the GPU bug and the clock calibration patch posted previouly needs work
<loki666>
Mmmh I think I miss console=tty0 could it be my issue with fbconsole?
<tokyovigilante>
the UART console is of course a serial one, the FB console I don't *think* is used unless you have a pixel-based display attached, so quite possibly, you need FB support in the kernel, whatever you are rendering starts there before being transferred to whatever display you're using
<loki666>
tokyovigilante well I'm not sure I'm testing properly the HDMI, what should I see when plugging the cable? Do you send an image to /dev/fb0 ?
<loki666>
I was expecting a console with a login prompt...
<tokyovigilante>
yeah you should see the boot console then a tty login
<tokyovigilante>
Finished for the night, have pushed a new branch which is my WIP mainline version, code more or less the same but a bit tidier with more docs so may be helpful
<macromorgan>
do we have registers on the OTG controller for the H700/H616/T507?
<macromorgan>
no matter what I do the extcon keeps reporting host...
gsz has joined #linux-sunxi
vagrantc has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
bauen1 has quit [Ping timeout: 480 seconds]
bauen1 has joined #linux-sunxi
warpme has quit []
<apritzel>
macromorgan: that's most likely not a hardware issue, but a Linux driver problem
<macromorgan>
yeah, just having trouble nailing it down is all
<apritzel>
from what I debugged some times ago, it's the EHCI/OHCI controller and the OTG controller both fighting over the PHY device
<apritzel>
they both claim the PHY, and for some reason it's only ever the host part winning
<macromorgan>
I think that's part of it, but even when I deactivate the ehci/ohci it seems to want to force it to host mode
<apritzel>
with what setting for dr_mode?
<macromorgan>
otg
<apritzel>
I think it works with peripheral?
<macromorgan>
yeah, I was hoping to try and figure out more closely exactly why I can't get proper OTG working, but I'm thinking might have to hard code to periph and move on
<apritzel>
yes, that's probably a reasonable approach for now. I looked at it some years back, and it didn't look easy to solve. IIRC the key function is sun4i_usb_phy_set_mode()
<apritzel>
that does the right thing, I think, but it's called with conflicting requests, from the USB controllers
<apritzel>
and it's not clear whether the callers shouldn't do that in the first place, or if this PHY function is supposed to handle this cleverly
<macromorgan>
I noticed among other things that the id_det request is always returning the same value, regardless of whether or not the gpio is 0 or 1
<apritzel>
that might be an unrelated problem. I saw the issues with ID detection working properly
<apritzel>
speaking of id_det: so mentioned some days ago that the AXP717's USB-C part didn't really work?
<apritzel>
so is there any chance it's not wired up properly, or they just ignored that part?
<macromorgan>
for me it doesn't, but that's possibly (likely) an implementation thing rather than the AXP717 itself not working
<macromorgan>
when I enable the cc mode register I still get no output, but let me try one last thing before I throw in the towel there
<apritzel>
but the registers you dumped didn't seem to change?
<apritzel>
I was wondering if they didn't connect the CC pins to the AXP? Maybe ignored them completely?
<macromorgan>
register 0x0b bit 3
<macromorgan>
it's possible they didn't
<apritzel>
I am not sure one can pull off a simple GPIO driven OTG detection with USB-C?
<apritzel>
(at least not without extra circuitry)
<macromorgan>
I can confirm id_det changes if I plug in an OTG device
<apritzel>
what id_det? is that some GPIO?
<macromorgan>
my GPIO PI16 is set as an input, it goes low unless a USB OTG device is plugged in in which case it goes high
<apritzel>
ah!
<apritzel>
so there might be some logic on the board to pull this off, and they connected the CC pins there, instead of to the AXP
<apritzel>
which is a bummer
<apritzel>
anyway, regardless of id_det working, the Linux logic will probably still fail, as mentioned above
<macromorgan>
nothing: gpio-260 ( |usb0_id_det ) in lo IRQ
<macromorgan>
otg adapter: gpio-260 ( |usb0_id_det ) in hi IRQ
<macromorgan>
cable into computer: gpio-260 ( |usb0_id_det ) in lo IRQ
<macromorgan>
usb-c cable into usb-c pd brick: gpio-260 ( |usb0_id_det ) in lo IRQ
<macromorgan>
the usb-c pd brick keeps triggering an IRQ though
<macromorgan>
but for now I'll say screw it and just do it as a periph mode port
<macromorgan>
I'll finish up the USB power driver and submit it then and not worry. For the record I have the vbus_det working as well, I can see the PHY see the vbus get added/removed as I plug in a charger or not
<apritzel>
nice!
apritzel has quit [Ping timeout: 480 seconds]
bauen1 has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
warpme has quit []
<tokyovigilante>
macromorgan: what does that mean for tbe devices with one USB port? no ability to connect and charge from a hub while having downstream devices attached?
<macromorgan>
correct
<macromorgan>
you can use it in gadget mode though
<macromorgan>
but devices with only 1 usb port (and no ethernet) are kind of SOL
<tokyovigilante>
annoying... definitely need to fix this bluetooth/clock cal issue then. so effectively the OTG labelling on the aingle port devices is incorrect?
<macromorgan>
did you try setting the rtc pin?
<macromorgan>
and the device does work as OTG (as shown by the stock firmware), it's just some sort of a driver issue
<tokyovigilante>
ah right, so HW capable
<tokyovigilante>
of data down and charge up?
<tokyovigilante>
i havent yet but will re-look now that i have display working. being able to hexdump registers directly a bit of a gamechanger.
apritzel has joined #linux-sunxi
<apritzel>
I guess the device charges without software intervention? So at least that's not lost.
<apritzel>
And I think it should work to force it to host mode, through the DT
<apritzel>
and with PI16 apparently doing the right thing, we should be able to make it work, eventually
bauen1 has joined #linux-sunxi
<tokyovigilante>
apritzel: great, thanks for clarifying. have made peace with regulators, now it seems USB standards are the next thing to get to grips with
<tokyovigilante>
macromorgan: does the second port on the -H work currently? should just get a USB-c to mini cable for my keyboard
<macromorgan>
it works for me, but not on mainline. I'll have to fix the regulators now that I know which ones to fix.
<tokyovigilante>
no drama, if you could share even a rough patch then i can keep going with the display work.
apritzel has quit [Ping timeout: 480 seconds]
<macromorgan>
yeah, it's just a simple matter of defining the regulator(s), no big deal.
<macromorgan>
I'm going through what's ahead of me in the AXP717 queue, looks like the boost regulator is all (but I need a register renamed from that series in order to push what I have)
vagrantc has quit [Quit: leaving]
apritzel has joined #linux-sunxi
<tokyovigilante>
oh yup nice, yeah I've got the WIP boost patches in my tree
Parthiban has quit [Remote host closed the connection]
vagrantc has joined #linux-sunxi
Parthiban has joined #linux-sunxi
Parthiban has quit [Remote host closed the connection]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
Parthiban has joined #linux-sunxi
<tokyovigilante>
what is the position on adding modules to defconfigs? I notice a lot of the driver patches also enable the module to be built by default (eg +CONFIG_SPI_GPIO=m) but I remember vaguely this being unpopular in mainline because it bloats all the default builds
<tokyovigilante>
Just wondering when I upstream some of this stuff
<apritzel>
tokyovigilante: for mainline you would need some rationale, but eventually the in-kernel defconfig is mostly meant as a common ground for booting and troubleshooting. Adding drivers as modules is less of a problem, though
<apritzel>
but ultimately defconfig is not really relevant, what matters is what the distributions do
<apritzel>
and most distributions enable almost everything as =m, to cover everyone, but to also keep the Image file reasonably small
<apritzel>
tokyovigilante: I wouldn't worry about an eventual config so much, this is not really your problem
<apritzel>
I'd work with something based off defconfig, then with everything you need added as =y
<apritzel>
this is then your "development config", to make your life easier
<apritzel>
(and to keep your kernel build time low)
<apritzel>
once you have everything working, you could check how this plays out with some distro configs, to see if something needs adding (as =m) there
Schimsalabim has quit [Read error: No route to host]
Schimsalabim has joined #linux-sunxi
Parthiban has quit [Remote host closed the connection]