<Net147>
What is the highest serial baud rate that works reliably on A20?
kaspter has joined #linux-sunxi
gaston_ has quit [Quit: Konversation terminated!]
arnidg has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 246 seconds]
_whitelogger has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
<wens>
1.5M seems to be ok
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
<Net147>
wens: yes, that is the maximum that will work with default clock configuration on mainline - APB1 24 MHz, 24000000 / 16 = 1500000
<Net147>
wondering if anyone has had any success getting rates higher than 1.5M working reliably (e.g. by reparenting apb1 from hosc to pll-periph and adjusting clock rates)
wwilly_ has joined #linux-sunxi
wwilly__ has quit [Ping timeout: 245 seconds]
kilobyte_ch has quit [Ping timeout: 245 seconds]
kilobyte_ch has joined #linux-sunxi
dddddd has quit [Remote host closed the connection]
JohnDoe_71Rus has joined #linux-sunxi
notme has joined #linux-sunxi
notme has quit [Client Quit]
arete74 has quit [Ping timeout: 246 seconds]
arete74 has joined #linux-sunxi
xes has quit [Quit: bye..]
NeuroScr has quit [Ping timeout: 258 seconds]
NeuroScr has joined #linux-sunxi
<libv_>
heh, rmmod sun4i_drm is also an oops
<libv_>
amazing
libv_ is now known as libv
pmpp has joined #linux-sunxi
pmp-p has quit [Ping timeout: 268 seconds]
reinforce has joined #linux-sunxi
NeuroScr has quit [Ping timeout: 248 seconds]
<libv>
so simplefb...
<libv>
now it needs to grown pwm support.
<wens>
libv: you're probably better off just binding the gpio instead
<MoeIcenowy>
libv: maybe it will be better if we switch to simpledrm at first ;-)
<wens>
when the pwm driver probes, it may or may not reset the hardware, so you might lose whatever state simplefb was originally depending on
<anarsoul>
libv: hehe, apparently you haven't tried suspend on sunxi yet
* anarsoul
hides
<libv>
wens: define binding the gpio
<wens>
libv: simply gpiod_get() ?
<libv>
ok, with the risk of the pin being driven high and the pwm driver not properly initializing?
diego_r has joined #linux-sunxi
[7] has quit [Ping timeout: 264 seconds]
TheSeven has joined #linux-sunxi
<wens>
yeah, but you can design the gpio specifier such that logical 1 is backlight on, and pass GPIOD_OUT_HIGH to gpiod_get
xes has joined #linux-sunxi
sunshavi has quit [Read error: Connection reset by peer]
<libv>
ok
ldevulder has joined #linux-sunxi
libv_ has joined #linux-sunxi
selfbg has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
libv has quit [Ping timeout: 268 seconds]
yann has quit [Ping timeout: 268 seconds]
msevo has joined #linux-sunxi
libv_ is now known as libv
<libv>
ok, simply adding the usual references to pinctrl makes the pinctrl driver claim these pins
<libv>
according to debugfs, all is well
<libv>
but the top bit of the red channel is at some point set to output again
<libv>
so that should work transparently
maz has joined #linux-sunxi
tl_lim has quit [Read error: Connection reset by peer]
<libv>
(but it doesn't at least not completely, but i will debug that one later)
<libv>
i am just going to try to bolt in backlight like clocks and regulators
airwind has joined #linux-sunxi
tnovotny has joined #linux-sunxi
yann has joined #linux-sunxi
arete74 has quit [Ping timeout: 244 seconds]
arete74 has joined #linux-sunxi
freemangordon has quit [Ping timeout: 258 seconds]
Mangy_Dog has joined #linux-sunxi
<libv>
with backlight handling added, and the backlight built-in, the lcd seems mostly steady
AneoX has joined #linux-sunxi
SopaXorzTaker has joined #linux-sunxi
pgreco has quit [Ping timeout: 248 seconds]
pgreco has joined #linux-sunxi
pmpp is now known as pmp-p
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
hramrach has quit [Ping timeout: 244 seconds]
hramrach has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
reinforce has joined #linux-sunxi
pg12 has quit [Ping timeout: 264 seconds]
tnovotny has quit [Quit: Leaving]
<libv>
nice, simplefb is 3x the original size now. what a colossal misnomer that was ;)
<fALSO>
lol
<wens>
huh?
<libv>
with the backlight code added, counting in the clocking code i added in august 2014, and the regulator code added by wens in 2015
SopaXorzTaker has quit [Remote host closed the connection]
<libv>
before that it was 200lines
<libv>
and it was simple, but could only work on rpi, because the videocore controlled all the hw bits anyway, and there were no drivers for anything real, and so nothing that could be disabled
<libv>
the clocking code addition produced an lkml email thread over 400mails long, double the original loc of the file.
<libv>
as that exposed the fundamental fallacy behind this driver
<MoeIcenowy>
montjoie: BTW what the hell is "alliwinnder"
<montjoie>
a typo that I have already asked to remove
<montjoie>
and since this is a good day, I think to have found THE bug in my sun8i-ss driver
<libv>
nice, r40 does seem highly compatible to a20
<libv>
here's hoping that olimex does a board soonish?
<MoeIcenowy>
libv: just the function is a superset of A20
<MoeIcenowy>
many IP cores changed
<libv>
csi1 seems the same
<MoeIcenowy>
oh interesting
<libv>
MoeIcenowy: as far as you know, did anything related to display change?
<MoeIcenowy>
everything.
<MoeIcenowy>
It uses DE2
<libv>
oh
<MoeIcenowy>
DesignWare HDMI
<libv>
ok
<libv>
hrm
<MoeIcenowy>
and there's a "TCON_TOP" managing the mux
* libv
goes digging for overlays and things
<montjoie>
ans it use the sun8i-ce instead of sun4i-ss
<libv>
why did they keep the tvd?
<mru>
aren't allwinner chips all mostly a pile of arm+designware parts lashed together with duct tape and baling wire?
<maz>
mru: just like most low-end silicon vendors. AW is no different from NXP, in that respect.
<mru>
nxp does a better job with the lashing
<mru>
and much better documentation
<mru>
as in, they actually publish some
<maz>
mru: sure. the final product still sucks rocks.
<mru>
the imx6 isn't that bad
<mru>
imx28 is a horror show, but that wasn't developed by them
<libv>
heh, they seem to no longer support csi-rgb (planar rgb888)
<libv>
and yuv444 also seems gone
<libv>
or at least it is not documented as a valid overlay input format
<libv>
so that's a reason not to jump on r40 for fosdem, if hw does arrive
<MoeIcenowy>
mru: not only ARM+Synopsys
<MoeIcenowy>
also some IP cores from Mentor Graphics
<mru>
usb...
cnxsoft has quit [Read error: Connection reset by peer]
<mru>
the horror
<MoeIcenowy>
mru: and I2C
<MoeIcenowy>
yes, musb really sucks
<MoeIcenowy>
I hope they can replace it w/ DWC3 furtherly
<MoeIcenowy>
the display and video codec seem to be their own
<fALSO>
yo moeicenowy - glad to "see" you back here
<MoeIcenowy>
fALSO: ?
<fALSO>
there was a huge time that you didnt said anything in the channel
<fALSO>
;-P
<fALSO>
tought you were in vacations
cnxsoft has joined #linux-sunxi
tnovotny has joined #linux-sunxi
gaston_ has joined #linux-sunxi
lerc has quit [Quit: No Ping reply in 180 seconds.]
lerc has joined #linux-sunxi
AneoX_ has joined #linux-sunxi
matthias_bgg has quit [Read error: Connection reset by peer]
matthias_bgg has joined #linux-sunxi
AneoX has quit [Ping timeout: 246 seconds]
pg12 has joined #linux-sunxi
cnxsoft has quit [Quit: cnxsoft]
SopaXorzTaker has joined #linux-sunxi
msevo has quit [Quit: Leaving]
tllim has joined #linux-sunxi
tllim has quit [Client Quit]
dddddd has joined #linux-sunxi
jbrown has quit [Remote host closed the connection]
tllim has joined #linux-sunxi
airwind has quit [Quit: airwind]
sunshavi has joined #linux-sunxi
tnovotny has quit [Quit: Leaving]
jbrown has joined #linux-sunxi
Mangy_Dog has quit [Ping timeout: 258 seconds]
Mangy_Dog has joined #linux-sunxi
selfbg has quit [Remote host closed the connection]
gaston_ has quit [Ping timeout: 258 seconds]
Wizzup has quit [Ping timeout: 272 seconds]
BenG83 has joined #linux-sunxi
Wizzup has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
<jernej>
libv: regarding yuv444 on R40, you mean for display or csi?
SopaXorzTaker has quit [Remote host closed the connection]
matthias_bgg has quit [Ping timeout: 244 seconds]
\\Mr_C\\ has joined #linux-sunxi
wwilly__ has joined #linux-sunxi
<jernej>
anyway, if you mean display, this format is already supported in DRM driver
wwilly_ has quit [Ping timeout: 268 seconds]
Wizzup has quit [Ping timeout: 272 seconds]
diego_r has quit [Ping timeout: 258 seconds]
Putti has quit [Remote host closed the connection]
return0e has quit [Ping timeout: 248 seconds]
Putti has joined #linux-sunxi
Wizzup has joined #linux-sunxi
reinforce has joined #linux-sunxi
return0e has joined #linux-sunxi
jbrown has quit [Remote host closed the connection]
<libv>
jernej: for display, really? i do not see it mentioned as an input format for DE2
<jernej>
libv: you have to use a bit of imagination
<jernej>
in this case, it's implemented ad RGB888 with CSC which actually converts it to RGB
<jernej>
s/ad/as/
<libv>
so interleaved
<libv>
and not planar
<jernej>
you mean to specify each color as separate plane?
<libv>
our csi engine only does planar for higher data rates
<libv>
yes, separate addresses for each of the channel, for yuv444/rgb888 at least width*height apart
<libv>
on a10/a20 the documentation mentions csi-rgb, which is probably exactly that
<libv>
as no-one in their right mind would use planar rgb
gaston_ has joined #linux-sunxi
<jernej>
I think DE2 supports only interleaved RGB formats
<libv>
and i was about to implement that when i noted the bs i had done with claiming the pins for simplefb, as i now need to fake the lcd0 pinctrl by attaching it to the backlight so it is used nicely by both drivers, at which point the pinctrl driver thinks it has set thing correctly, but the actual io registers say something else :)
<libv>
yeah, which is what i meant
<libv>
did r40 retain the "mixer" aka "g2d"
<libv>
?
<jernej>
idk
<libv>
yeah
<libv>
but it still rules out zero-copy for overlays
gaston_ has quit [Ping timeout: 246 seconds]
<libv>
and we need that 2d engine to convert to yuv420 for half the framerate for the h.264 encoder
<jernej>
heh, at the begining of chapter 6 in R40 manual, you have a block diagram how they designed display pipeline
<jernej>
of course, CSI output goes either to video encoder or GPU for rendering
<libv>
heh, 10+ years behind on everyone else ;)
<libv>
people have since moved back from "we can do _everything_ on the gpu", a bit
<wens>
libv: why do you need to claim the lcd0 pinctrl?
<libv>
wens: because if i do not, simplefb has the panel bleed until kms comes up
<jernej>
contrary to CSI, VPU output can be rendered directly with DE2
<wens>
libv: bleed?
<wens>
not following. shouldn't the pins already be setup by u-boot?
<libv>
jernej: surely this is also true for earlier revisions of the display engine?
<libv>
wens: yeah, but those get altered again when pinctrl loads
<wens>
ok. I had the idea that the pinctrl driver leaves things alone if not explicitly specified
<jernej>
libv: I don't know DE1 much, but yes, VPU output can be directly rendered with it too
<jernej>
just different format
<wens>
VPU output on earlier SoCs is the tiled format, which only the Front-End can render
<wens>
the drm driver already supports this
<jernej>
I just meant to say that it seems that only VPU seems to be considered for direct display, while CSI is second class citizen (just my opinion)
<libv>
planar yuv444 is also out, so our fallback option of having the hdmi->parallel converter do that csc for us is also not an option
sunilmohan has quit [Ping timeout: 244 seconds]
yann has quit [Ping timeout: 245 seconds]
<libv>
anyway, not a problem, it just means that we should not consider r40 as an upgrade path from our current a20 setup
<jernej>
libv: R40 states it supports YUV422 CMOS interface. Is this only for input? Is output always in YUV444?
<jernej>
for CSI
<libv>
jernej: between the two csi engines, it can take in a multitude of formats
<libv>
but if you wish to retain fidelity for text, you want to have 8 bits per channel at the full data rate
<libv>
so we like the fact that we can get that with csi1
sunilmohan has joined #linux-sunxi
sunilmohan has quit [Changing host]
sunilmohan has joined #linux-sunxi
<libv>
at 148.5MHz and 24bit colour, i rather not do double pumping
<libv>
which then means that get to feed separate channels through separate fifos and thus separate addresses
<libv>
hence, planar
SopaXorzTaker has joined #linux-sunxi
<libv>
ooh, could that be it, pinctrl clk.
<libv>
heh
putti_ has joined #linux-sunxi
Putti has quit [Ping timeout: 272 seconds]
sunshavi has quit [Read error: Connection reset by peer]
<Mangy_Dog>
bit of a stretch but does anyone know of a manufacturer with a true 4k or (3,840 x 2,160) 7 inch display? tft module not a monitor... Im looking for a pure tft
<mru>
why do you need that many pixels?
<mru>
or rather such high density
<Mangy_Dog>
its for a prospective 3d resin printer im thinking about
<Mangy_Dog>
future project
<Mangy_Dog>
anycubic photon uses 2k at 5 inches
<Mangy_Dog>
4k at up to 10 inches would be ok... but i would prefer 7 or 8 inches personally
<Mangy_Dog>
2k at 5inch shows very obviouse voxalisation even though it is still pretty good... with AA on it smooths those out really nicely but still leaves artifacts. I deffo dont want 2k at anything higher than 5inches though would look rough on 7 inch build area
<Mangy_Dog>
sooooo 4k
<mru>
4k in a 7" display would be over 600 ppi
<Mangy_Dog>
yeppers
<Mangy_Dog>
which inturn translate to high detailed super smooth prints
<mru>
my phone has ~440 ppi, and I can just about make out the pixels if I hold it as close to my eyes as possible without losing focus
<Mangy_Dog>
yeah
<Mangy_Dog>
i realise how detailed that is in terms of monitor displays
<Mangy_Dog>
anmd my phone is a full HD at 6 inches and i cant really make out the different pixels
<Mangy_Dog>
apart from when i see 1 dead one :D
<Mangy_Dog>
but with 3d printing you can see it
<mru>
my closest focus distance is about 6"
<Mangy_Dog>
like i say 2k aon the 5 inch you can see the voxels on the print
<mru>
of course you can see a single pixel even if it's super tiny
<Mangy_Dog>
so i dont want to buils a printer that makes them even larger... would be best to find a 4k at that higher build area
<mru>
single different colour pixel in a flat area, that is
<mru>
and what does 3d printing have to do with anything?
<Mangy_Dog>
you use the display as a slide show of each layer to cure each layer of uv cure resin
<Mangy_Dog>
you take off the backlight panel and just use the raw tft screen, the software takes your sliced print which is basicly a slideshow of images
<Mangy_Dog>
a stencel of every layer
<mru>
is the blue in the display short enough wavelength for that?
<Mangy_Dog>
no
<Mangy_Dog>
you take off the backlight
<Mangy_Dog>
so its just raw tft
<mru>
oh, replace the backlight with a uv light
<Mangy_Dog>
and you use a big uv light underneath
<Mangy_Dog>
yeah
<Mangy_Dog>
50w idealy
<mru>
can't you shrink the image with some optics?
<Mangy_Dog>
not reliably
<Mangy_Dog>
but also makes more points of failure to do that
<mru>
you mean not cheaply
<Mangy_Dog>
well its not the done thing
<Mangy_Dog>
you have your printing vat pretty much right against the display
<mru>
maybe finish the game thing first
<Mangy_Dog>
certainly
<Mangy_Dog>
this is very early thinking stage
<Mangy_Dog>
if i do this
<Mangy_Dog>
will likely be next year
pgreco has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Aria 5.0.0, revision: 5.0.0+git-7422-2fe1a3bca, build type: debug, sources date: 20160102, built on: 2019-07-01 08:27:19 UTC 5.0.0+git-7422-2fe1a3bca http://www.kvirc.net/]
aalm has joined #linux-sunxi
popolon has joined #linux-sunxi
vagrantc has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
vagrantc has quit [Ping timeout: 250 seconds]
SopaXorzTaker has quit [Remote host closed the connection]
ldevulder has quit [Quit: Leaving]
popolon has quit [Quit: WeeChat 2.5]
Mangy_Dog has quit [Ping timeout: 248 seconds]
popolon has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
curlybracket has joined #linux-sunxi
notme2 has joined #linux-sunxi
notme2 has quit [Client Quit]
Mangy_Dog has quit [Remote host closed the connection]