<luoyi>
so can we combine this driver and the device tree patch togother to merge into the mainline ?
<wens>
yes, and someone should :)
iamfrankenstein has quit [Quit: iamfrankenstein]
cnxsoft1 has joined #linux-sunxi
cnxsoft has quit [Ping timeout: 250 seconds]
cnxsoft1 is now known as cnxsoft
iamfrankenstein has joined #linux-sunxi
luoyi has quit [Ping timeout: 250 seconds]
p1u3sch1 has quit [Ping timeout: 260 seconds]
p1u3sch1 has joined #linux-sunxi
leio has joined #linux-sunxi
IgorPec has joined #linux-sunxi
engideavr has joined #linux-sunxi
reev has quit [Read error: Connection reset by peer]
reev has joined #linux-sunxi
reev has quit [Ping timeout: 260 seconds]
<wens>
seems like it was the opi cases that were sold out
engideavr has quit [Quit: Konversation terminated!]
zuikis has joined #linux-sunxi
engideavr has joined #linux-sunxi
zuikis has left #linux-sunxi [#linux-sunxi]
reev has joined #linux-sunxi
reev has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has joined #linux-sunxi
luoyi has joined #linux-sunxi
<luoyi>
wens: you mean for now, all things I need to do is just wait for *someone* to merge these patches ?
<plaes>
luoyi: no, you need to submit them to mailinglist
<plaes>
..for review
IgorPec has quit [Ping timeout: 272 seconds]
JohnDoe_71Rus has quit [Read error: Connection reset by peer]
reev has joined #linux-sunxi
reev has quit [Max SendQ exceeded]
<wens>
if you have time to pick up the work, then submitting them yourself is probably the quickest way
reev has joined #linux-sunxi
<luoyi>
OK. which mailinglist is prefer ?
<luoyi>
linux-sunxi@googlegroups.com is the right place ?
<wens>
nope
<wens>
use scripts/get_maintainers.pl to figure out who to send the patches to
<wens>
and i mean the whole driver and dt changes, not just your fixes
<wens>
also read Documentation/SubmittingPatches
JohnDoe_71Rus has joined #linux-sunxi
yann|work has quit [Ping timeout: 260 seconds]
codekipper has joined #linux-sunxi
p1u3sch1 has quit [Ping timeout: 260 seconds]
p1u3sch1 has joined #linux-sunxi
<codekipper>
luoyi: I was looking at starting pushing of the i2s patches very soon....if you wanna take the helm then it would be wise to work from a kernel repo
reinforce has joined #linux-sunxi
<luoyi>
codekipper: glad to see you
<luoyi>
codekipper: I'm not familiar with such process, so I think maybe you submit the patch is a good idea :-)
<codekipper>
the patches you're pushing are meaningless to me but welcome to the i2s playback club
<codekipper>
check out the kernel documentation and also links in the wiki
<codekipper>
you can also look at the history of my pushing of the spdif patches
<luoyi>
I should start with linux-sunxi master branch or linus master branch ?
<codekipper>
thing is I only know of one commercially available device with i2s so it's unlikely that we'll be pushing anything into the dts.
<luoyi>
codekipper: there are many DAC with i2s interface
<codekipper>
I would work with linux-next...others work from the latest rc tag
<codekipper>
yeah but none of them are sold with sunxi products
<codekipper>
I've just got delivery of a PCM5102 device so I'll test that as soon as I can
<codekipper>
just got a lot going on outside of hacking to speed this process up.
<luoyi>
you mean we can't commit simple-card section into the repo ?
<wens>
luoyi: we don't enable anything that's not integrated on the board or in the device
<codekipper>
you can have it in your repo by all means but I doubt that it's something that can be pushed to mainline
<wens>
luoyi: so for an add-on card, maybe not
<wens>
codekipper: i was thinking of getting one of those rasbperry pi dacs, and hook it up w/ short wires
<luoyi>
ok. so the spdif is ok. because the spdif interface is integrated in the chip. but pcm510x simple-card is not
<codekipper>
that's what I've just bought....
<codekipper>
spdif optical connector appears on quite a few products.....
<codekipper>
i2s output is only available on one product that I know of
<luoyi>
codekipper: ok. now I know the point. but looks like the spdif can't work correctly with the mainline kernle now. because of the mod1 clock bug.
<wens>
codekipper: is there a driver for pcm510x? i only see pcm512x.c
<luoyi>
codekipper: the bananapi m1+ is a good choice .
<codekipper>
there is in my repo!
reev has quit [Remote host closed the connection]
wazzup has quit [Remote host closed the connection]
<codekipper>
but it's just a simple codec
<codekipper>
it's probably also in the raspberry pi repo
<codekipper>
luoyi: I have different repos for different things....for example upstreaming a put my patches ontop of linux-next whereas general hacking I commit ontop of hans sunxi-wip branch
<luoyi>
codekipper: so your plan is test the driver with your new 5102 dac, and if ok, we can send it to sunxi-wip branch ?
<luoyi>
these repo confuse me now ....
<wens>
codekipper: i was a bit unsure about the uda13xx, but it seems there's a mainline driver for it
<codekipper>
wip is work in progress so I test a develop ontop of this. But this isn't a good place to be delivering stuff from(especially dtsi changes)...
<luoyi>
the rpi's method to support these DAC is dt-overlay, does sunxi kernel have any plan to support dt overlay ?
<luoyi>
so we can put the simple-card section just in a overlay file
<codekipper>
I usually dev on sunxi-wip then when happy cherry pick the changes I need onto linux-next (fix any conflicts) and then push
<wens>
luoyi: there definitely will be, as the CHIP is depending on it
<wens>
you can also base stuff on sunxi-next, i typically merge anything sunxi related in
<codekipper>
wens: yep...uda1380 has been in mainline for a while
<codekipper>
luoyi: ignore that......like a said we all have our ways of working!
<wens>
luoyi: yes
<wens>
sunxi-next is a subset of linux-next
<wens>
basically me, mripard or hans will look out for drivers that have been merged for -next, and we merge the maintainer's -next tree into sunxi-next
<wens>
that will also include mripard's sunxi/for-next, which is mostly sunxi DT or clock patches
<wens>
codekipper: kind of want to go with PiFi DAC+ 2.0, but can't seem to find a vendor page :(
massi_ has joined #linux-sunxi
<luoyi>
wens: you can send your address to me. I can send you some DACs through international mail package
<tkaiser>
jrg: In case you're dealing with BPi-M3 and any of the crappy SinoVoip OS images please keep in mind that they try to provide images that boot on Raspberry Pi, BPi M2, M2+ and M3. So on the 1st FAT partition there's a lot of stuff and for M3 you have to look below bananapi/bpi-m3/linux/ (uEnv.txt and script.bin)
yann|work has joined #linux-sunxi
<luoyi>
changed the pcm5102 to a tda1543 one. and still hear ok
<luoyi>
codekipper: you mean the mic on this board doesn't send any signal ?
<codekipper>
I don't know....looking on my scope I've yet to see any pulses coming from the codec
<luoyi>
codekipper: you've done the uda1380 register setting ?
<codekipper>
It's from mainline so should be well tested.....I did put together a patch to read the registers back but I don't think I've tested it yet
<codekipper>
I sort of more interested in seeing if I can get i2s working on the H3...think everything is now in place to get it to work
<tkaiser>
codekipper: You're talking about mainline kernel, I2S and H3?
<codekipper>
tkaiser: I only work with mainline....with the dma patches now in I think we've enough to test with
reev has joined #linux-sunxi
reev has quit [Max SendQ exceeded]
reev has joined #linux-sunxi
<tkaiser>
codekipper: Ok, I just remembered that someone posted a tutorial in H3 Armbian forum regarding I2S with BSP kernel. And there only a few tweaks were needed to remove SPI from GPIO pins und use I2S instead
<codekipper>
yeah...I guess the board is set up for spi on the header....
<codekipper>
with mainline I don't think any of the header pins are configured....
<tkaiser>
codekipper: Yes, but in fex file most of the pin mappings try to be compatible to RPi header definition (not true for everything)
<codekipper>
this will only be my test platform....if anything I'll be posting just changes to the h3 dtsi
IgorPec has joined #linux-sunxi
apritzel has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
Mr__Anderson has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
caog has joined #linux-sunxi
caog has quit [Client Quit]
caog has joined #linux-sunxi
<Amit_T>
apritzel: Hello, are you able to load ATF+U-BOOT from EFL on pine64, right ?
<apritzel>
Amit_T: yes, but it's a bit hacky
<Amit_T>
apritzel: I am ready to try as long as My board is safe :)
<apritzel>
because I compile U-Boot twice, once with CPU_V7 (32-bit) to get sunxi-spl.bin and once with ARM64 to get the main U-Boot binary
<Amit_T>
ok, is it documented anywhere ?
<apritzel>
so you need two patches for (upstream) U-Boot: the first one to enable SPL (which also switches the port to 32-bit), and the second one to do the RMR switch
<apritzel>
Amit_T: no, not yet, and I only have the patches at home
<apritzel>
I just managed to do it and then went to bed ;-)
<Amit_T>
too hackyy then :P
<Amit_T>
apritzel: One doubt , did you make changes in FEL source ?
<apritzel>
no
<apritzel>
also ATF is unchanged
caog has left #linux-sunxi ["Ex-Chat"]
<apritzel>
one could change the FEL source to do the RMR switch and get rid of that one U-Boot patch then
<NiteHawk>
apritzel: i'm all ears :)
matthias_bgg has joined #linux-sunxi
<apritzel>
NiteHawk: either: sunxi-fel sees that the u-boot.img is an arm64 image, thus injects the RMR sequence to start in AArch64
<apritzel>
or: we introduce a special "rmr" command in sunxi-fel which allows to specifiy the address to which the RMR switch branches
<NiteHawk>
apritzel: may be safer to have an option for that? future SPLs/SoCs could do a 64-bit transition on their own, or even start completely as 64-bit without sunxi-fel intervening
<apritzel>
the first one has two problems: a) currently U-Boot wraps an arm64 U-boot build in an _32bit_ U-Boot image (the architecture flag is set to arm, not aarch64)
The_Loko has joined #linux-sunxi
<apritzel>
b) we need to enter ATF in 64-bit, not U-Boot
<apritzel>
maybe spl instead of uboot as the first command, not sure about that
<apritzel>
so that would mean: load and execute the SPL, load the kernel, load ATF (bl31.bin) and execute that in 64-bit (with the RMR switch)
<NiteHawk>
yes, spl should do - "uboot" would just request to start it (execute the entry address) - that's pointless with rmr
<apritzel>
NiteHawk: does that make sense?
<apritzel>
NiteHawk: I am still a noob with sunxi-fel, just looked at the code yesterday ...
<NiteHawk>
apritzel: yes, it makes sense. maybe we split the bl32 transfer into "write" and "rmr"... does the ATF go to address 0x44000 (i.e. load address = rmr entry)?
<apritzel>
NiteHawk: yes
<apritzel>
at the moment I put the ATF in SRAM A2
<apritzel>
could be SRAM C as well, but I had issues with that
<apritzel>
and SRAM A2 is much easier with boot0
<NiteHawk>
i'm aiming to keep maximum flexibility, so i'm thinking we might separate the "write" (upload operation) from "rmr <entry>"
<apritzel>
NiteHawk: sure
<NiteHawk>
let me know if you publish your RMR setup code / u-boot patch somewhere. i'm sure it can be integrated into fel.c without too much effort
<NiteHawk>
for testing, i'd need both 32-bit and 64-bit toolchains right? (i'd use the latter "native" on the pine64)
<apritzel>
NiteHawk: yes, that's the problem at the moment
<apritzel>
NiteHawk: if you use Debian or Ubuntu, you should be able to just apt-get a cross toolchain
<NiteHawk>
not too much of an issue for me - i need 32-bit anyway for the A20 (have gentoo cross-compiler in place), and the A64 should be able to take care of itself (native gcc)
<apritzel>
so the RMR switch is basically: you write the entry address to 0x017000A0, then set bit 0 and 1 in the RMR system register
<NiteHawk>
nice, thx. i think i'll need some time to setup my rig properly and have a look at that - will give it a try tonight
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
ricardocrudo has quit [Remote host closed the connection]
Mr__Anderson has quit [Remote host closed the connection]
<codekipper_>
ok...that's i2s + i2c...so there's drivers that need to be enabled(it's supported by mainline)
<codekipper_>
I would just copy the settings from the raspberry pi github...they should support this device
<mripard>
yeah, I just checked, there's a driver for that codec
<mripard>
how did you wire yours ?
<codekipper_>
i'm in the process of moving so I've not had the time to start any new setups
<codekipper_>
but it should be fairly straight fwd...same as uda1380
<mripard>
ok
pekka10 has joined #linux-sunxi
IgorPec111118 has joined #linux-sunxi
IgorPec111117 has quit [Ping timeout: 260 seconds]
akaizen has quit [Remote host closed the connection]
vagrantc has joined #linux-sunxi
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 246 seconds]
staplr has joined #linux-sunxi
Netlynx has joined #linux-sunxi
libv has joined #linux-sunxi
libv_ has quit [Ping timeout: 252 seconds]
apritzel has quit [Ping timeout: 244 seconds]
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 264 seconds]
libv_ has quit [Ping timeout: 264 seconds]
ricardocrudo has quit [Remote host closed the connection]
libv has joined #linux-sunxi
libv has quit [Ping timeout: 272 seconds]
mnr has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 244 seconds]
IgorPec has joined #linux-sunxi
IgorPec111118 has quit [Ping timeout: 264 seconds]
libv has joined #linux-sunxi
fl_0 has joined #linux-sunxi
Amit_T has quit [Ping timeout: 260 seconds]
cosm_ has joined #linux-sunxi
akaizen has joined #linux-sunxi
massi_ has quit [Remote host closed the connection]
Nacho_ has quit [Ping timeout: 260 seconds]
Nacho has joined #linux-sunxi
codekipper_ has quit [Ping timeout: 250 seconds]
Netlynx has quit [Quit: Leaving]
akaizen has quit [Remote host closed the connection]
avph has quit [Ping timeout: 260 seconds]
avph has joined #linux-sunxi
willmore has quit [Ping timeout: 240 seconds]
willmore has joined #linux-sunxi
JohnDoe7 has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 272 seconds]
susan33 has joined #linux-sunxi
<susan33>
hi, is it the good channel for the odroid xu4 kernel ?
apritzel has joined #linux-sunxi
<KotCzarny>
does it use allwinner soc ?
<susan33>
i have a xu4 and i'm building a self distribution. I use the kernel from https://github.com/hardkernel/linux. the xu3-3.10 works well and include the drivers/gpu drivers. the xu4-4.2 works but seems to not include the gpu drivers. can somebody tell me if i'm wrong ? and if i want to use the xu4 with a framebuffer i'm blocked at kernel 3.10 ?
<longsleep>
susan33: odroids do not use allwinner soc, so this is fc :)
<susan33>
ok
<susan33>
so, same question about the pine64. i don't find a kernel with the framebuffer and opengl acceleration. Where can i found it please ?
<longsleep>
does not exist
IgorPec has quit [Ping timeout: 260 seconds]
<susan33>
longsleep, is there a good reason ? or something to do ?
<KotCzarny>
reason being no one did it yet
<susan33>
KotCzarny, sorry, pine64 and odroid have in common the mali gpu, not the soc
<longsleep>
susan33: well thats a question for allwinner, they need to release the required software preferably as opensource, they have not - thus no support
<longsleep>
susan33: if i rememer correctly i told you the same in february or something :)
<susan33>
longsleep, yes, but at this time, i was completly a beginner and didn't understand all. now, i'm stil a beginner, but i manage to make my odroid card working
<susan33>
so, i'm back on the pine64 to try to understand what was missing.
<longsleep>
susan33: odroid situation is not much diffrent
zuikis has left #linux-sunxi [#linux-sunxi]
<susan33>
for odroid, i found a (old) kernel proposed by hardkernel which has the mali kernel drivre
<longsleep>
susan33: sure, Pine64 kernel has the mali kernel driver aswell
<susan33>
but there is something i don't understand.
<KotCzarny>
when you dont understand something, its about money
<susan33>
in the odroid kernel, i think but i'm perhaps wrong, that the driver is in drivers/gpu
<susan33>
in the pine64, i don't found it or something similar
<longsleep>
mali kernel driver does not help you though, mali binary blobs for arm64 for mali 400 is no available and i will only tell something else when they have released something
<longsleep>
susan33: its out of tree, see the modules director
<longsleep>
y
<apritzel>
btw:
<apritzel>
I asked around
<apritzel>
apparently the mali450 drivers could work for the mali400 as well
<apritzel>
because the 450 is basically the 400 with more cores
<apritzel>
so has anyone tried it?
<longsleep>
apritzel: yeah - but i think ssvb said that the ones available for download are only for framebuffer and not for x11 or something
<longsleep>
apritzel: but i have not tried it, so cant tell much more
<susan33>
i would like to be on arm 32 bits. is it available for 32 bits ?
<susan33>
anyway, i understand that your kernel has the mali drivers. and that i should be able to load the 32 bits 400 or 450 userland drivers for opengl. Am i definitively wrong ?
<longsleep>
susan33: yes, that kernel is 64 bit
<longsleep>
but honestly i have not much a clue or care about mali
<susan33>
ok
<apritzel>
susan33: it's a _really_ complex topic, there are many driver parts involved
<susan33>
so the mali drivers are here because there are in the mainline kernel ?
<apritzel>
susan33: what exactly do you refer to with "mali drivers"?
<susan33>
apritzel, ok. but you advise me to give up ? (because i'm too beginner for example which would be a good answer)
<susan33>
my aim is to have a framebuffer with opengl.
<susan33>
i understand that there are 2 parts :
<susan33>
kernel driver and userland binary drivers
<susan33>
(and a sdk to compile)
<apritzel>
please don't give, but you first need to understand the whole graphics stack
<apritzel>
*give up*
<susan33>
on the odroid xu4, i've the 3 components and things works
<susan33>
but because people probably did some job so that it because easy to me and i don't see the difficuly.
<apritzel>
but the odroid has a mali t628, right?
<apritzel>
also it's a 32-bit SoC
<longsleep>
susan33: yes, for the hardkernel odroid image they mostly have all the mali bits for that particular soc/board in place (mostly)
<apritzel>
my understanding is that it works without X11 - so you can write an application that runs directly on the framebuffer and can have 3D graphics there
<apritzel>
which is probably OK for some embedded applications, but not for a general Linux use case
<apritzel>
and if I got longsleep correctly, the 64-bit Mali450 blob is only for fbdev :-(
The_Loko has joined #linux-sunxi
mnr has quit [Quit: leaving]
Nyuutwo has quit [Ping timeout: 240 seconds]
Nyuutwo has joined #linux-sunxi
<susan33>
apritzel, thus, this is exatly what i want. i want a 32bit linux framebuffer.
<susan33>
no x11 server
<apritzel>
why 32-bit?
<susan33>
because my distribution is about emulator which have a lot of troubles in 64 bits
<apritzel>
because the code base is not 64-bit safe?
<apritzel>
well, you can always run a legacy 32-bit ARM binary on any 64-bit kernel run
<susan33>
i don't know. people of the team said me that on rpi3 64 bit, some fails, so to keep on 32 bits for the moment.
<apritzel>
but that's a general rpi3 problem (booting in 64-bit is a bit more involved)
Nyuutwo has quit [Ping timeout: 240 seconds]
<apritzel>
also there is no official Raspi-kernel for 64-bit, AFAIK
<apritzel>
so if the emulators are Open Source and used to run on commodity PC hardware, chances are that recompiling them for arm64 should work
<susan33>
yes possibly. i agree. However, you told me that binary are not available in 64 bits, so, i just said that 32 bits is not a problem to me.
<apritzel>
well, no, there is 64-bit binary driver to the 450
<apritzel>
(because of the HiKey board)
<apritzel>
and I cannot find a 32-bit Mali400 driver there
<apritzel>
I guess it's up to the SoC vendors to get them from ARM and ship them with the board
<willmore>
The XU4 is handled over in #odroid, susan33.
<susan33>
willmore, nice thanks. i will use it for my odroid questions ;-)
Nyuutwo has joined #linux-sunxi
<willmore>
You're welcome. Friendly people here and there. :)
<susan33>
but because that point, i wanted to know if the mali kernel stack was there. it seem to be true. so i'll try that with the longsleep kernel.
Nyuutwo has quit [Ping timeout: 240 seconds]
paulk-collins has quit [Quit: Leaving]
nove has quit [Quit: nove]
Nyuutwo has joined #linux-sunxi
akaizen has joined #linux-sunxi
ajeandet has joined #linux-sunxi
ajeandet is now known as jeandet
susan33 has left #linux-sunxi ["Quitte"]
cosm_ has quit [Quit: Leaving]
jeandet has quit [Quit: jeandet]
Nyuutwo has quit [Ping timeout: 240 seconds]
<lennyraposo>
aptritzel
<lennyraposo>
and ssvb
<lennyraposo>
news on the mali front from allwinner
Nyuutwo has joined #linux-sunxi
<lennyraposo>
also longsleep
<lennyraposo>
they are gonna test their implementation on the Debian Mate I put together
<lennyraposo>
based on longsleep's kernel
dev1990 has joined #linux-sunxi
<apritzel>
lennyraposo: so are they going to ship Linux X11 Mali userland blobs eventually?
<lennyraposo>
yeppers
<lennyraposo>
nope
<lennyraposo>
noep to the question apritzel
<lennyraposo>
yeppers was for someoen else
<lennyraposo>
the nope is because it is unknown at this point
<lennyraposo>
they are apparently working on a DMA Buf implementation
<lennyraposo>
for Ubuntu/Debian
<apritzel>
but what is that exercise for then?
<lennyraposo>
once they are done I would imagine they will release it
<lennyraposo>
as it is the only thing they haven't released thus far for the A64
<lennyraposo>
binary wise
<apritzel>
that's what I meant: so they will ship 64-bit Mali blobs?
<lennyraposo>
the mali blobs
<lennyraposo>
in the future yes
pitelpan has joined #linux-sunxi
<lennyraposo>
as of now no as they are working on it
<lennyraposo>
there has been a lot of back and forth regarding the subject
<lennyraposo>
originally it wasw gonna be released with their BSP 2
<lennyraposo>
but wasn't
<lennyraposo>
then it became they need to start working on it
<lennyraposo>
and now they are working on it
<lennyraposo>
the moment I get the news on it myself or tllim from Pine64 is gonna post it
<apritzel>
still this is going in the wrong direction
<apritzel>
nobody should waste their time on that doomed BSP kernel
<lennyraposo>
that's what they are testing against
<lennyraposo>
this is coming from tllim at pine64
<lennyraposo>
question apritzel as you are knowledgeable on the matter
<lennyraposo>
they release the blobs
<lennyraposo>
and their source for implementation
<lennyraposo>
what woudl the difficulty be in providing it outside the BSP?
<apritzel>
chances are that their kernel bits don't work anymore on an upstream kernel
The_Loko has quit [Remote host closed the connection]
<lennyraposo>
let me get the rest of the back and forth
<lennyraposo>
especially from allwinner's side
<lennyraposo>
1. UMP will not be support on A64 (ARM only support 32 but UMP and not 64 bit), this means cannot using UMP method to drive USER driver layer which is common implementation method in pass.
<lennyraposo>
2. Need to use dma_buffer method to implement USER layer and DRM driver.
<lennyraposo>
3. The KMS portion on the DRM driver related to display (DE, TCON, HDMI hardware related) needs Allwinner engineerign team to implement. The GEM portion coding can achieve by dma_buffer method, whcih is easy to accomplish.
<lennyraposo>
4. Allwinner will provide a interim solution, KMS portion using display driver and DE, TCON, and HDMI can become part of BSP parameter for KMS implementation.
<lennyraposo>
5. Allwinner will also privide DRM driver, same as using DE, TCON related BSP for KMS implementation. They are working on now and expected should be able to link up with Ubuntu upper layer driver on end of May.
<jrg>
if i touch testing to the share. and delete it on a windows or osx box the file goes away just fine. there has to be something wrong with the debian arm mount.cifs bin or something
<jrg>
i'll make a vm soon and see if i get the same problem on an x86 box
tlwoerner has quit [Quit: Leaving]
<jrg>
think I'll just resort to sshfs and keep the box separate from everything.