<junari>
it looks like axp717 is not enough to provide all the voltages for t527
<junari>
and they were too lazy to add support for something like AXP853T to BSP
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
electricworry has quit [Remote host closed the connection]
electricworry has joined #linux-sunxi
JohnDoe8 has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
dsimic is now known as Guest3800
dsimic has joined #linux-sunxi
Guest3800 has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
KREYREN_oftc has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
junari_ has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
<wingrime-ww>
H618 have video glitches in 4k@60 it's common?
ftg has joined #linux-sunxi
junari_ has quit [Ping timeout: 480 seconds]
<jernej>
it's know to happen
<jernej>
H616 display driver is hacked together, not properly designed according to HW limitation
<jernej>
what is your use case? I only noticed that with AFBC buffer rendering
<wingrime-ww>
HDMI 4k@fps and cpu load
<wingrime-ww>
I don't know this is interference or memory bandwidth starvation
<wingrime-ww>
In a first case, thats pcb design issue, for example wifi is nearby
<wingrime-ww>
In a second case, I think hdmi controller sometimes can't read memory buffer in time
smaeul has quit [Remote host closed the connection]
smaeul has joined #linux-sunxi
apritzel has joined #linux-sunxi
<jernej>
well, it also depends what kind of pixel clock you're using
<jernej>
RGB or YUV 4:4:4 output is much more sensitive and may be disturbed if any other high frequency device is in use
<jernej>
for such case, there is possibility to configure spread spectrum for HDMI clock, which should lower sensitivity
<jernej>
but that's not implemented there
<jernej>
but usually, for 4k@60 output, YUV 4:2:0 is used, since it requires only half the bandwith
KREYREN_oftc has joined #linux-sunxi
<jernej>
btw, only mixer(s) read(s) data from memory and compose it to one image (if multiple planes are used), TCON then serializes this data and gives it to encoders (like HDMI) or not (parallel LCD)
<jernej>
and yes, buffers and other data are not programmed into mixer at right time, that's why you can see artifacts in some cases
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
KREYREN_ has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #linux-sunxi
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
chewitt has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
KREYREN_ has quit [Remote host closed the connection]
KREYREN_ has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
nickA has joined #linux-sunxi
KREYREN_ has quit [Remote host closed the connection]
chewitt has quit [Quit: Zzz..]
JohnDoe8 has quit []
vagrantc has joined #linux-sunxi
warpme has quit []
timsu has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
<timsu>
Several H618 SBC list an SPDIF input in their schematic. What is up with that? Does it really exist in the hardware?
<apritzel>
timsu: do you have an example? Maybe it's just a pin with that signal on a header?
<apritzel>
ok, well, apparently the H616 die has a SPDIF input device, connected to (multiplexed) pin PH3, even though the H616 manual doesn't mention it
<apritzel>
but the T507 manual does
<apritzel>
so it might work, but you would need to connect some S/PDIF compliant circuitry and connector to that pin
<apritzel>
none of those boards seems to have a TOSLINK or coax connector, of course
<apritzel>
and only some older TV boxes have a TOSLINK, but only for output, I think
<timsu>
Yeah I know what to do for the hardware part. Do I have to enable it in software somehow?
<apritzel>
I am just checking this part. Are you talking about mainline or some dodgy vendor firmware?
<apritzel>
we do not have that pinmux mentioned in our pinctrl driver, so this one line would need to be added
<timsu>
Currently I'm using the sipeed build. But the included Wifi driver is horrible buggy in combination with other things, so im looking forward to switchting to mainline, especially with the 6.9 changes.
<apritzel>
timsu: wens probably knows more, he recently added the SPDIF OUT part for the H616 to mainline
<apritzel>
mmh, or maybe it's just some copy&paste bug on the schematic side? The T507 manual explicitly only describes OWA-OUT
<timsu>
apritzel: Thank you! What is the recommended way to get started with using mainline? Do I just modify the sipeed image build process to use the linux-net source?
<timsu>
Maybe they just reused their H6 schematic symbol in their PCB software
<apritzel>
so the bad news is that the mainline driver only seems to support TX anyway :-(
<apritzel>
so even if you would enable that in the DT and add the missing pinmux and bits here and there, it wouldn't work
<apritzel>
timsu: what's the WiFi chip on your board? Mainline support for those lesser and cheaper WiFi chips is not good, so unless it's something Broadcom or Realtek compatible, there will probably not be a driver
<timsu>
it's an aic8800. I can live without it working, but the driver included in the sipeed build makes booting with a few other modules like usb audio or ie1588 impossible.
<apritzel>
ah, I looked that up the other day: there doesn't seem to be mainline support for it
<apritzel>
those off-tree drivers are for some reason horrible, and hard to upstream without a significant rewrite
<apritzel>
off-tree WiFi drivers, I mean in particular - even though other off-tree drivers are usually not good as well, probably the reason they are still off-tree ;-)
<apritzel>
for mainline usage you should be able to pick up any distro kernel, some offer the latest builds packaged
<apritzel>
6.9-rc1 has just been released an hour ago, so this might still be a bit too young for this ;-)
<apritzel>
if you really rely on a whole image build process, it might be easier to just point the existing build scripts to Linus' tree on kernel.org, but I don't know any details, or how this works with the .config
<timsu>
Thanks, I will look into it. There seems to be no mainline uboot support for the Longan pi 3h right now.
<apritzel>
timsu: yes, patches welcome ;-)
<apritzel>
it's pretty straight-forward, though, you just need to extract the DRAM parameters from a vendor image
<apritzel>
and put them in a defconfig file. For now copy the .dts file from the kernel, though we will sync that automatically soon anyway
<apritzel>
either from an update image or live from a running vendor system. I have a static binary which runs on Android (./sunxi-fw info -v /dev/block/mmcblk1)
alikates has joined #linux-sunxi
alikates has quit []
alikates has joined #linux-sunxi
<timsu>
great, thank you for your help!
<apritzel>
any time!
<apritzel>
timsu: out of curiosity: how complicated is it to add a Coax or TOSLINK connector? Do you have a pointer to some information?
<timsu>
Toslink is probably easier, because it does not need magnetics and you do not have to watch out for ESD protection. I would probably make a small PCB which fits onto the expansion header. Add something like this https://www.digikey.de/de/products/detail/everlight-electronics-co-ltd/PLR135-T10/2693961 and a 100nf capacitor close to it between VCC and GND.
<timsu>
It would probably work on a breadboard if you have a high quality one and keep the cables short
<apritzel>
ah, nice, I was hoping for that ;-)
timsu has quit [Quit: Leaving]
Schimsalabim has quit [Read error: Connection reset by peer]