<MoeIcenowy>
I don't think they're going to change the core ;-)
<wens>
lol a10 hdmi color is reversed
insane^^ has quit [Read error: Connection reset by peer]
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
baali has joined #linux-sunxi
baali has quit [Ping timeout: 248 seconds]
IgorPec has joined #linux-sunxi
a|3x has quit [Ping timeout: 248 seconds]
TheSeven has quit [Ping timeout: 258 seconds]
TheSeven has joined #linux-sunxi
aalm has quit [Quit: xyz 1.9.1]
TheSeven has quit [Ping timeout: 258 seconds]
[7] has joined #linux-sunxi
baali has joined #linux-sunxi
HeavyMetal has quit [Ping timeout: 240 seconds]
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 240 seconds]
awais_ has joined #linux-sunxi
<plaes>
o_O
JohnDoe_71Rus has joined #linux-sunxi
gnufan has joined #linux-sunxi
<wens>
seems like the hardware is doing something unexpected, like toggling register bits by itself :/
Gerwin_J has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
DullTube has joined #linux-sunxi
HeavyMetal has joined #linux-sunxi
HeavyMetal has quit [Changing host]
HeavyMetal has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
Gerwin_J has quit [Quit: Gerwin_J]
<wens>
and hdmi doesn't work on my cubietruck :/
dave0x6d has quit [Quit: Connection closed for inactivity]
kaspter has quit [Quit: kaspter]
kaspter has joined #linux-sunxi
fl_0 has quit [Ping timeout: 264 seconds]
<oliv3r>
ouch
<wens>
it only breaks in the kernel , not in u-boot :/
<oliv3r>
i'm going to build checkout stuff and build stuff in the next few hours
<oliv3r>
so i'll let you know how i'm fairing
fl_0 has joined #linux-sunxi
<wens>
some bug with the layer code :/
fl_0 has quit [Ping timeout: 258 seconds]
fl_0 has joined #linux-sunxi
<oliv3r>
wens: specific to a20 and simply not caught before?
<oliv3r>
on my a20 hardware it did work with net147's patches
<mripard>
freemangordon: this won't be accepted either
<wens>
looks like a physical vs dma address offset issue :/
<oliv3r>
bah
<freemangordon>
mripard: well, I will look at how other drivers implement GEM allocation and will try to come up with something
<mripard>
freemangordon: the thing is, you want to allocate a GEM buffer for the GPU
<mripard>
through the display engine
<mripard>
this is why it won't be accepted, it's not tied to the right device
<oliv3r>
speaking of dri rendering; i collegue of mine is working with that, and noticed, after a buffer has been scheduled and renderd and is ready to accept the next buffer, he has to wait about 100ms or so, before he can schedule the next buffer; any clue as to why this could be?
alsy has joined #linux-sunxi
<freemangordon>
mripard: in the meanwhile - do you have idea why I get that terrible tearing with clutter? (hildon-desktop that is). I looks like wrong page is selected. This is mali400 on A33. could it be because irq handler checks for both SUN4I_TCON_GINT0_VBLANK_INT(0) and SUN4I_TCON_GINT0_VBLANK_INT(1), but there is only tcon 0 on A33 (saw it somewhere in the notes)
alsy has left #linux-sunxi [#linux-sunxi]
alsy has joined #linux-sunxi
alsy has left #linux-sunxi [#linux-sunxi]
<freemangordon>
ok (re wrong device)
asyring has joined #linux-sunxi
<mripard>
a proper solution would be to rely on ION to do that
<asyring>
Hi, which driver is the best for sun4i-drm? Xf86-video-armsoc from mripard github?
<mripard>
it's quite low on my todo list, so if you want to give it a shot :)
<mripard>
asyring: the absolute best would be modesetting, if you don't care about the GPU
<asyring>
Ok how do I configure it in xorg?
<mripard>
freemangordon: and no, I don't know for the tearing, sorry
<freemangordon>
mripard: sure, why not :). could you provide some more info on where should I look at? sorry, I am new to drm/mali/sun4i and I am still getting used to the terminology
<mripard>
freemangordon: ION is a general allocator
<mripard>
so it's not really tied to mali or sun4i
* freemangordon
checks
<mripard>
the code is here: drivers/staging/android/ion/
<freemangordon>
yeah, android allocator
<freemangordon>
ok, thanks
<mripard>
there's currently effort to move it out of staging by Laura Abbott, you might want to check that too
<mripard>
asyring: it should be the default
<freemangordon>
ok
<freemangordon>
mripard: BTW, why not use CMA?
<freemangordon>
well CMA/DMABUF
<wens>
freemangordon: ask arm? :p
<KotCzarny>
is it tied to the blob?
<wens>
mripard: looks like the backend needs dma-ranges, but I can't figure out how to not use the DMA mapping API and just get it to translate addresses for me
<freemangordon>
wens: sorry, how's ARM related to the method of allocatiing a piece of contig memory?
<mripard>
freemangordon: CMA is an in-kernel API
<mripard>
freemangordon: actually, our GEM allocator is backed by CMA
<freemangordon>
mripard: my bad, I actually meant DMABUF
<mripard>
freemangordon: what you want is a userspace API, and CMA doesn't provide it
mhlavink has quit [Quit: No Ping reply in 180 seconds.]
<freemangordon>
and there is userspace API there afaik
<mripard>
and afaik, dma-buf doesn't allow you to allocate buffers, but only to share buffers that have already been allocated
fkluknav has joined #linux-sunxi
asyring has quit [Read error: Connection reset by peer]
<freemangordon>
mripard: yes, it is kernel that allocates the buffer, but can't we use that private ioctl to tell the kernel to allocate dba_buf and return the handle? and then mmap from userspace.
<freemangordon>
could be that I miss something, however, will try to implement such support
<wens>
freemangordon: my bad, I thought you were referring to mali in this case
<freemangordon>
:)
matthias_bgg has joined #linux-sunxi
tom_nov has joined #linux-sunxi
msimpson has joined #linux-sunxi
baali has quit [Ping timeout: 248 seconds]
leviathanch has joined #linux-sunxi
Leepty has joined #linux-sunxi
f0xx has joined #linux-sunxi
<oliv3r>
wens: sadly, your branch doesn't rebase cleanly onto 4.14 due to some i915/amdgpu changes; so that'll have to wait unfortunatly
fl_0 has quit [Ping timeout: 255 seconds]
freemangordon_ has joined #linux-sunxi
<oliv3r>
wens: you didn't add the lime's, shall I add them and send a patch for those?
<oliv3r>
i can even send it just to you so you can add it to your series
<wens>
oliv3r: I haven't finished the a10 support yet, so no a10-lime
<wens>
I did include the A20-lime
<oliv3r>
ah ok i just noticed the a20-lime2 missing
<oliv3r>
which will be my primary test :)
<wens>
huh?
<oliv3r>
wens: btw, any reason you list sun7i before sun5i as the compatible in sun7i.dtsi for the hdmi node?
<wens>
it's clearly in there
<oliv3r>
A20-lime and A20-lime2
<oliv3r>
ok then i'm overlooking things
<wens>
yes you are
<oliv3r>
i am :)
<wens>
as for sun5i after sun7i, because we want soc specific comaptibles in case some day we find out that sun7i and sun5i hdmi are not in fact compatible
<oliv3r>
i know we want both
<oliv3r>
but why not alphabetically order the compatibles
<oliv3r>
i would think there'd be no difference in ordering as far as the compatible field is concerned?
<oliv3r>
ah, i see the other compatibles do the same
<oliv3r>
weird as to not sorting them in order though :)
fdlg has quit [Ping timeout: 255 seconds]
<wens>
yes there is
<wens>
the first one is matched first
<wens>
if it doesn't match any driver, the next one is tried, and so on
<wens>
hence, most specific to least specific compatible
reinforce has joined #linux-sunxi
<wens>
why do you think ehci has "generic-ehci" listed last?
<oliv3r>
ah, then it makes perfect sense
<oliv3r>
i didn't look at the ehci one :p
<oliv3r>
wens: this is a change in how we do things right? i mean compared to a (ong) while ago, i belive we only had 1 compatible listed
<oliv3r>
e.g. a lot of sun4i drivers are identical on sun7i, but we only list the sun4i compatible
<oliv3r>
(used to)
<ElBarto>
it's still the case if the driver/IP is 100% compatible
<oliv3r>
how can you know this for sure though?
<wens>
oliv3r: it's been this way for some time, maybe a year
<oliv3r>
yeah, hence a 'long' time :p
<oliv3r>
so it's quite recent in my world :)
<wens>
you can't, which is why we switched to this approach
<oliv3r>
so ElBarto is wrong :p
<oliv3r>
are all compatibles updates?
<oliv3r>
(i don't know the new dtsi's by heart)
<oliv3r>
we've been working with 4.2 for 3? years now, and switched to 4.9 very recently
<wens>
we don't bother to change the existing ones, unless there is breakage
<oliv3r>
maybe that's why i hadn't spotted it
<oliv3r>
but a patch to fix up the existing compatibles wouldn't be outright denied, right?
<oliv3r>
it's just work that hasn't been done yet?
<wens>
correct
<mripard>
if it ain't broken, don't fix it
<oliv3r>
tss tss, if it ain't broken, improve it :)
<oliv3r>
in this case, not having it could yield confusion 'why is it here, and not there' not helping in overal readability to those uninformed
<mripard>
it would also make it harder to figure out how to deal with an old device tree binding when we would have to change i t
<wens>
mripard: a while back ago you mentioned that we explicitly cleared all the backend registers, because some soc didn't have a reset control for it
<oliv3r>
damned legacy and backwards compatibility!
<wens>
mripard: is that true? I couldn't find one that didn't
fdlg has joined #linux-sunxi
<mripard>
I think that's something I took from the U-Boot's code
<mripard>
so we probably should ask Hans about that :)
<ElBarto>
oliv3r: I'm always wrong, just remember this :)
<oliv3r>
ElBarto: i jest i jest
<mripard>
he's doing FreeBSD stuff, that should be a big clue already
<wens>
the user manual does say most of the default values are undefined
<oliv3r>
i noticed for arm64, we are splitting the dts up into directories, are there any plans (or is it even possible with legacy) to split up the 32 bit dts into directories as well? (github for example can't even list the current list anymore, with sun* falling below the list :(
<wens>
no
<wens>
that's up to the arm-soc maintainers, and iirc the answer was no
<oliv3r>
ah someone suggested it then
<oliv3r>
and the answer being no is due to having too much legacy depend on it?
<oliv3r>
i guess having a seperate dts repository will be a no too :)
Worf has joined #linux-sunxi
<wens>
you can ask over in #armlinux
<ElBarto>
oliv3r: as the FreeBSD developer that import DTS in our tree I don't even see the point of having a separate dts repo honestly
<ElBarto>
oliv3r: this wouldn't make a difference
<Net147>
ElBarto: did you have a chance to try "gpio clear PA17" in U-Boot to get ethernet working on the Olimex A20 eMMC board?
<ElBarto>
Net147: totally forgot about that, it's been a long time this I haven't done anything <A31
chlorine_ has quit [Remote host closed the connection]
<ElBarto>
but I've started A13 for clkng yesterday and will do A10/A20 this weekend too, this is a great opportunity to test this
chlorine has joined #linux-sunxi
<ElBarto>
talking about ethernet, anyone knows if some revision of the pine64 have weird phy issues ?
<ElBarto>
on mine I cannot use ethernet on u-boot
<ElBarto>
and on FreeBSD TX is ok while RX sucks (other users don't have this problem)
<ElBarto>
Net147: didn't someone from olimex sent a dts change for that recently ?
<oliv3r>
ElBarto: well there's more out there than just fbsd :p
<Net147>
ElBarto: yes, that is for Linux. I don't know if U-Boot automatically configures the GPIOs according to the DT...
chlorine_ has joined #linux-sunxi
<ElBarto>
oliv3r: still, I don't see a point, why do you think that having a separate repo would be better ?
<ElBarto>
Net147: ah right, I don't think that u-boot reads the DT (at least for A20)
<ElBarto>
this would need some kconfig magic I guess
<oliv3r>
ElBarto: well fbsd needs it, u-boot needs it; wouldn't it be cleaner to have it maintained outside of the kernel, to make imports easier, as, yes it originated within the linux kernel, it really is just a hardware description file, not related to the kernel, the kernel just uses
<ElBarto>
and again, separate repo won't make importing easier
chlorine has quit [Ping timeout: 240 seconds]
<oliv3r>
oh that's nice
reinforce has quit [Quit: Leaving.]
chlorine has joined #linux-sunxi
<oliv3r>
but you are using a seperate repo so you are doing exactl ywhat i suggested :D
<ElBarto>
oliv3r: and having the dts in the same repo is good for linux as if someone change some dts, he will need to send driver change at the same time
<ElBarto>
I'm just using this repo as the old maintainer uses it
<Net147>
oliv3r: what is the status on the AXP209 LDO3 voltage ramping patch you submitted for U-Boot?
<oliv3r>
that is a fair comment, but doesn't the same apply to linux?
<ElBarto>
I honestly don't care
<oliv3r>
Net147: good question; i think it's still stuck. i am preparing my regulator fix for the kernel to be sent out, and it contains the same fix for the kernel as well
<oliv3r>
doesn't the same apply to u-boot i meant :)
<mripard>
oliv3r: there's no plan to split the DT into separate directories
<oliv3r>
Net147: i think it's on ja... forgot his name's todo?
<mripard>
this would break virtually every build script on the planet
<mripard>
distros, build systems, custom tools, etc.
<oliv3r>
yeahf
<oliv3r>
its just annoying that its breaking certain (broken) tools due to the long lists
<oliv3r>
cgit manages it fine however
chlorine_ has quit [Ping timeout: 240 seconds]
<ElBarto>
fix the tools then :)
<oliv3r>
you mean every build script on the planet? :p
<mripard>
so broken tools are broken ? :)
<oliv3r>
can't fix github :p
<ElBarto>
oliv3r: you can complain on twitter, isn't that what people do nowadays ? :P
<oliv3r>
i think they added that as a 'feature' to prevent heavy server load
fl_0 has joined #linux-sunxi
<oliv3r>
i don't have twitter :(
<ElBarto>
then you're not allowed to complain
<oliv3r>
but since we do use a payed github account, they do respond reasonably to e-mails
<oliv3r>
:(
<oliv3r>
stupid twitter
<oliv3r>
but its true, if you try to call any company nowadays, they hardly respond or you have to wait for hours
<oliv3r>
complain on twitter, and you get help
<oliv3r>
Net147: why did you name hdmi_con_out and hdmi_in_con? wouldn't it be more concistent to name hdmi_con_in as well? i think that's what's common/documented how naming was
<oliv3r>
(or vice versa, i forget)
<Net147>
oliv3r: I think I copied wen's naming
<oliv3r>
ah
<Net147>
also I don't know what clock rate be0, be1 and mali are supposed to run at on A20
<oliv3r>
why not?
<oliv3r>
can't we just get those from a working android?
<Net147>
I don't have android
<Net147>
it's large and bloated
<oliv3r>
yeah i know
<oliv3r>
but devmem should give us the active registry settings
painten_0 has joined #linux-sunxi
<oliv3r>
register*
<oliv3r>
i wonder if i have some android device
<oliv3r>
i guess a lime2 with the olimex android should still have it
sebi26 has joined #linux-sunxi
afaerber has joined #linux-sunxi
paintenzero has quit [Ping timeout: 240 seconds]
painten_0 has quit [Ping timeout: 260 seconds]
<oliv3r>
Net147: what register is the data your after in?
<oliv3r>
i've got an android enabled lime2 still :)
<Net147>
oliv3r: no idea...
<oliv3r>
which should output to hdmi
<Net147>
oliv3r: does android have /sys/kernel/debug/clk/clk_summary ?
<oliv3r>
can i tell u-boot to somehow not load the initramfs (when it's an android kernel which includes the initramfs by default afaik)
freemangordon_ has quit [Ping timeout: 264 seconds]
<oliv3r>
i give up :(
<oliv3r>
i can't access recovery via adb, due to authorization denied recovery keys bla bla
<oliv3r>
doing it from the fully booted android, i can enter it via serial or adb, but i can't umount and format /data which causes boot to hang/loop and never completes booting ...
<oliv3r>
wens: bah, this is new :/ depmod: ERROR: Cycle detected: drm_kms_helper -> drm -> drm_kms_helper
<oliv3r>
probably my config needs to be rewritten
<plaes>
oliv3r: what if you override boot with 'init=/bin/sh' boot arg?
<oliv3r>
won't work, androids init somehow manages to overide it
<oliv3r>
though i did init=/sbin/busybox
<plaes>
hmkay..
<oliv3r>
wens: seems i can't have drm as a module anymore
<oliv3r>
plaes: stupid android
<oliv3r>
all i want/need is for it to stop crashing
<oliv3r>
and to do that, all i need is to format /data
<oliv3r>
hmm, i rm -rfed all /system/app/*apk and now i can umount /data :)
<oliv3r>
atleast that's fixed
<oliv3r>
now i probably have to get the key apk's back somehow :p
jmcneill has joined #linux-sunxi
LargePrime has quit [Ping timeout: 240 seconds]
<oliv3r>
and that wasn't enough, still keeps crashing :S
<oliv3r>
though it's outputting the boot animation i suppose
<jmcneill>
MoeIcenowy: ElBarto tells me you have a question about pine64?
LargePrime has joined #linux-sunxi
<oliv3r>
Net147: i only have an a10 tablet left where i can check this, but i doubt it outputs anything on HDMI by default
IgorPec has joined #linux-sunxi
<wens>
oliv3r: looks like something in the drm core
<oliv3r>
i built it in for now, was going to built it in anyway, but made it a module for testing so i could rmod/modprobe the whole drm stack
enrico_ has joined #linux-sunxi
<oliv3r>
wens: first out of the box trial i get this: [ 4.584792] sun4i-drm display-engine: Failed to initialize drm fb helper.
<oliv3r>
i haven't looked at it further then dmesg however :)
<oliv3r>
going to do that now
<wens>
did you enable CMA and enlarge the default size?
<oliv3r>
nope
<oliv3r>
well cma i'm not sure let me check
<oliv3r>
but i did not change the default size
<wens>
the default size is too small
<oliv3r>
ok, what is the recommended size?
<wens>
64 ~ 128M?
<oliv3r>
what node does it fall under, i'm sure it's not the 'memory' node which has reg = <0x40000000 0x80000000>;
<wens>
if you picked / rebased the patches on to some other tree, maybe you're missing something
IgorPec has joined #linux-sunxi
<oliv3r>
i added stuff ontop of your patches
<oliv3r>
but it works from your head
<oliv3r>
or rather, no errors
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<oliv3r>
so that's really nice :)
<oliv3r>
now i gotta figure which of my patches breaks it and why
<oliv3r>
probably some merge thing
<oliv3r>
but for a20; test okay
<oliv3r>
erm a20 lime2 that is
deskwizard has joined #linux-sunxi
IgorPec has quit [Ping timeout: 240 seconds]
LargePrime has quit [Ping timeout: 255 seconds]
reinforce has joined #linux-sunxi
chlorine has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
LargePrime has joined #linux-sunxi
Ntemis has joined #linux-sunxi
<MoeIcenowy>
jmcneill: yes, about NetBSD on Pines
chlorine has quit [Remote host closed the connection]
chlorine has joined #linux-sunxi
yann-kaelig has joined #linux-sunxi
chlorine has quit [Read error: Connection reset by peer]
<MoeIcenowy>
will you mainline it?
chlorine has joined #linux-sunxi
awais_ has quit [Ping timeout: 240 seconds]
pmpp_ has joined #linux-sunxi
pmpp has quit [Ping timeout: 248 seconds]
pmpp_ is now known as pmpp
chlorine_ has joined #linux-sunxi
chlorine has quit [Ping timeout: 246 seconds]
JohnDoe_71Rus has joined #linux-sunxi
<Ntemis>
anyone, am looking for the needed sun7i mali node changes in mainline
antony has quit [Quit: Leaving.]
<jmcneill>
MoeIcenowy: The only change to U-Boot is I build it with CONFIG_ARMV8_SWITCH_TO_EL1=y
<jmcneill>
MoeIcenowy: Otherwise it is a standard mainline U-Boot + ATF built with 64-bit toolchain.
<jmcneill>
MoeIcenowy: Not yet solved is how to make PSCI work in this scenario. I haven't spent too much time on it as the focus has been more around "lets get this running in AArch64 mode instead".
chlorine_ has quit [Remote host closed the connection]
msimpson has quit [Quit: Leaving]
IgorPec has joined #linux-sunxi
Leepty has quit [Remote host closed the connection]
a|3x has joined #linux-sunxi
chlorine has joined #linux-sunxi
IgorPec has quit [Ping timeout: 240 seconds]
dev1990 has quit [Quit: Konversation terminated!]
chlorine_ has joined #linux-sunxi
chlorine has quit [Ping timeout: 258 seconds]
matthias_bgg has quit [Quit: Leaving]
anarsoul|2 has joined #linux-sunxi
antony has joined #linux-sunxi
aalm has joined #linux-sunxi
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
deskwizard has quit [Ping timeout: 240 seconds]
dave0x6d has joined #linux-sunxi
diego_r has quit [Ping timeout: 255 seconds]
deskwizard has joined #linux-sunxi
deskwizard has joined #linux-sunxi
IgorPec has joined #linux-sunxi
antony has quit [Quit: Leaving.]
jstein has quit [Remote host closed the connection]
sr-digitronic has quit [Remote host closed the connection]
chlorine_ has quit [Remote host closed the connection]
<wens>
a10/a20 hdmi seems stable enough, will send out patches tomorrow
agraf has quit [Ping timeout: 258 seconds]
antony has joined #linux-sunxi
anarsoul|2 has quit [Ping timeout: 248 seconds]
ninolein has quit [Remote host closed the connection]
jstein_ has joined #linux-sunxi
jstein_ is now known as jstein
enrico_ has quit [Quit: Bye]
vagrantc has joined #linux-sunxi
pmpp_ has joined #linux-sunxi
detectiveaoi has joined #linux-sunxi
detectiveaoi has quit [Remote host closed the connection]
pmpp has quit [Ping timeout: 246 seconds]
anarsoul|2 has joined #linux-sunxi
tom_nov has quit [Quit: Leaving]
kivutar has quit [Ping timeout: 248 seconds]
kivutar has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
asyring has joined #linux-sunxi
<asyring>
Wens: hdmi on a20 doesn't show me anything. Is there a problem with fbsimple? I can see uboot and console untill drm is loaded. Xserver is loaded but no output.
jbrown has quit [Ping timeout: 255 seconds]
deskwizard has quit [Ping timeout: 248 seconds]
akaizen has joined #linux-sunxi
asyring has quit [Remote host closed the connection]
jbrown has joined #linux-sunxi
IgorPec has quit [Ping timeout: 255 seconds]
scream has joined #linux-sunxi
yann-kaelig has quit [Quit: I'll be back]
afaerber has quit [Quit: Leaving]
<plaes>
wens: Gemei G9 A10 - hdmi works!
leviathanch has quit [Remote host closed the connection]
<plaes>
wens: Cubietruck A20 - hdmi works!
<plaes>
although there was something wonky in u-boot
<Wizzup>
[ 677.499985] silead_ts: probe of 0-0040 failed with error -5
<freemangordon_>
and seems they can't find script.bin location in android to extract the needed data. any clue how fex might be called and where it is located?
<Wizzup>
We verified in android that that the addr is indeed 0x40, and that the chip is silead. We don't yet get to the point where any firmware is being loaded
gnufan has quit [Quit: Leaving.]
reinforce has quit [Quit: Leaving.]
anarsoul has quit [Ping timeout: 240 seconds]
lurchi__ is now known as lurchi_
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
<Wizzup>
figured it out, was missing vddio-supply = <®_ldo_io1>;