<codekipp1r>
have you defined the pins....that was a patch that was rejected last week as no product uses it
<oliv3r>
codekipp1r: yeah i have
<oliv3r>
btw, that's a stupid rule in a sense
<oliv3r>
if you wanna allow overrides, you need the pins to be available at the dtsi level :)
<oliv3r>
unless you also want to add the pins in the overlays
<oliv3r>
which becomes annoying once the pins do get in the dtsi
<codekipp1r>
yeah....I think I can respin the patch to consider that
<oliv3r>
codekipp1r: consider what?
<wens>
oliv3r: I'm referreing to the patch that added the reset control, landed in 4.11
<oliv3r>
wens: hmm, but i have it on my 4.9
<wens>
oliv3r: let me recheck
<codekipp1r>
I take that back..I was thinking of spdif
fkluknav has joined #linux-sunxi
<wens>
oliv3r: yup, 4.11.
<wens>
oliv3r: looks like it was backported
<wens>
oliv3r: care to do a patch?
<wens>
whats funny is that it will not work without it's preceding patch from mainline, as the DMA burst length is not supported on A31/A33
mhlavink has joined #linux-sunxi
<oliv3r>
wens: yeah once i can confirm that i2s works and that this fixes it :)
<oliv3r>
wens: you mean that i2s gained dma support in 4.11+ with i guess a quirk for sun6i, but that was not backported?
<oliv3r>
RX_DMA that is
<oliv3r>
as TX (playback) seems to be in 4.9
netlynx has quit [Quit: Ex-Chat]
<oliv3r>
wens: what is the reasoning behind for not adding pins to the dtsi? I mean, the SoC has the pins, used or unused, and it hinders overlay useage.
fkluknav has quit [Ping timeout: 240 seconds]
<wens>
oliv3r: it's not the RX/TX DMA, but rather the DMA burst length
<oliv3r>
ah okay
<wens>
oliv3r: On A10/A20, burst sizes of 1/4/8 are supported, and the driver uses 4.
<wens>
oliv3r: on A31+, only 1 and 8 are supported. If you ask for 4, the DMA driver will give an error
<wens>
so while the i2s driver may probe, playback will not happen
<oliv3r>
strange, concidering they are so related
<wens>
I'm guessing whoever submitted/picked the patches for stable didn't notice
<wens>
oliv3r: as for not adding pins to the dtsi, it's mainly so we only have stuff that is actually referenced somewhere
<wens>
with some boards with semi-generic GPIO headers (semi-generic meaning the vendor has assigned recommended usage, much like the RPi)
<oliv3r>
yeah I understand that
<wens>
we actually have the pinctrls assigned in the dts, but with the peripheral set as disabled explicitly
fugitive has joined #linux-sunxi
<oliv3r>
i do understand it, you dont' want unused pin definitions lingering in the dtsi
<oliv3r>
oth, the SoC's pin definitions are more or less set in stone :) you can't add pins ever. We do have all of the definitions in the pinctrl header, and the guideline came from a time where overlays where not that common i guess
<oliv3r>
so if i want to add a few overlays for our boards (based on some id like chip does), i have to put the pin defs also into the overlay
<oliv3r>
so just thinking whether this is something that could be reconsidered, when a peripherial driver is added (even disabled) do add the pin definitions
<wens>
I can't speak for mripard, but for me it's about visible test coverage
<wens>
1. someone actually tests the thing, and will continue to test it from time to time (by using it)
<MoeIcenowy>
wens: have you seen my patch that rename s_twi pin functions to s_i2c?
<oliv3r>
which is a little bit of a melon though; if I make my own board, like an EVB carrier board for example, and make 1 sample, document it on the wiki etc etc, where this board carries all 'missing' pin definitions, I could validly add all those, but it would not see the coverage we'd hope
<wens>
MoeIcenowy: I already reviewed it
<MoeIcenowy>
oh you just reviewed...
<wens>
oliv3r: there's no point in adding a one-off board to the repository is there?
popolon has joined #linux-sunxi
BenG83 has quit [Quit: Leaving]
<oliv3r>
wens: but who decides when it will be a one off
<oliv3r>
i'm a startup making a board :p
<oliv3r>
just playing devils advocate here
<wens>
oliv3r: then I'd expect you to add the dts file for the mass produced version, and not the pre-prod eng. samples :)
<oliv3r>
oth, the number of mainline users are very limited I would estimate, and once the momentum reaches critical mass, we would have all pin definitions in likley :)
<oliv3r>
wens: :D
<oliv3r>
wens: tindy shop!
<oliv3r>
or OSPark shop or etc etc
<wens>
oliv3r: yeah, it's still mostly dev boards
<oliv3r>
so are lime's orange pi's, raspberry pi's
<wens>
Allwinner's not really visible these days :(
<oliv3r>
yeah and all the press they do get is 'allwinner biggest GPL violaters omg'
<wens>
and any vendors out there are still using the vendor turnkey solution (like everyone else on any other platform)
<oliv3r>
whereas nobody knows that sunxi is the biggest community where sun[457]i are probably the best supported
<oliv3r>
yeah :(
diego_r has joined #linux-sunxi
<KotCzarny>
maybe allwinner doesnt like/want lowlevel community
<wens>
KotCzarny: define lowlevel?
JohnDoe_71Rus has quit [Ping timeout: 260 seconds]
<KotCzarny>
anything touching device drivers
<KotCzarny>
in opposition to 'users' which just tinker around but not the socs itself
<wens>
KotCzarny: I doubt they care
<wens>
it's mainly the board vendors' concern :p
<KotCzarny>
can 64bit kernel boot 32bit userspace?
<beeble>
of course
<KotCzarny>
without 64bit glue libs etc?
<beeble>
if you only run 32bit applications, yes
<KotCzarny>
cool
<KotCzarny>
what about drivers?
<oliv3r>
allwinner only cares about # of sold chips
<KotCzarny>
ie. would 32bit libmali work with 64bit kernel's mali.ko ?
<KotCzarny>
oliv3r: no political reasons?
<beeble>
should work
<KotCzarny>
and subsidies etc
<KotCzarny>
beeble: thx, will try
JohnDoe_71Rus has joined #linux-sunxi
<oliv3r>
KotCzarny: they don't even care about the small group of people calling them GPL violators, they probably dont' even really know
<oliv3r>
KotCzarny: the thing I doubt they realize, or even not care, besides the advantages of properly mainline support, is that the community may help sell chips (community -> engineer -> product)
<KotCzarny>
oliv3r: but that's management problem, isnt it?
<KotCzarny>
which is why i asked about 'political' reasons
<oliv3r>
KotCzarny: of course, i'm sure there's engineers there that care
<KotCzarny>
do they care about markets outside of china at all?
<oliv3r>
KotCzarny: well wasn't the a10/a20 tablet craze fueled by the chinese gov to help sell as many devices as possible, inc. overseas?
<oliv3r>
many many tablets sold/given away a few years ago where all sun[457]i
BenG83 has joined #linux-sunxi
LargePrime has quit [Ping timeout: 260 seconds]
JohnDoe_71Rus has quit [Quit: KVIrc KVIrc Aria 4.9.2, revision: git-7099-gca80ee628, build type: debug, sources date: 20160102, built on: 2017-03-12 14:49:35 UTC git-7099-gca80ee628 http://www.kvirc.net/]
enrico__ has joined #linux-sunxi
chlorine_ has joined #linux-sunxi
chlorine has quit [Ping timeout: 246 seconds]
<wens>
oliv3r: how things change so quickly :|
LargePrime has joined #linux-sunxi
msimpson has joined #linux-sunxi
<oliv3r>
wens: yeah, i sometimes wonder, is allwinner/sunxi (the socs) even still relevant?
matthias_bgg has joined #linux-sunxi
<oliv3r>
i.MX6 is quite interesting these days
<oliv3r>
they have etnvaviv
<oliv3r>
all peripherials are pretty much supported
<oliv3r>
i think just the video engine is still a blob
<oliv3r>
i think if we had a proper lima driver, display engine and cedarus support 2 years ago in mainline, a20's could have been great kodi players
<oliv3r>
though C.H.I.P. is doing quite well i think?
<oliv3r>
codekipp1r: ok i got your branch working, i have the 'new codec' with lots of mixer settings
<oliv3r>
codekipp1r: how do I use i2s as output
<oliv3r>
:)
<wens>
just select the 'new codec' as your output from whatever player you're using
<KotCzarny>
oliv3r: does it show int aplay -l ?
<KotCzarny>
*in
<oliv3r>
nop
<KotCzarny>
then something is missing
<oliv3r>
i know (:
<oliv3r>
maybe a driver module?
<oliv3r>
devmem 0x01c22400
<oliv3r>
oops
<oliv3r>
but that's all zero's
<oliv3r>
so codekipp1r's code does the same as 'mine'
<oliv3r>
i know that the probe successfully finishes
<KotCzarny>
might be you didnt enable daudio in sunxi codec
<oliv3r>
strange enough, i'm not getting the failed to deassert reset
<BenG83>
you'll see an ALSA device
<oliv3r>
i have/had
<BenG83>
I use codekipper's branch with my Pine64 DAC
mzki has quit [Ping timeout: 255 seconds]
<oliv3r>
<M> Allwinner A10 I2S Support
<oliv3r>
though i'm a little puzzled what this is: < > Audio support for A20 with UDA1380 codec on I2S DA0
<KotCzarny>
maybe specific chip on i2s
<oliv3r>
i2s + i2c
<oliv3r>
i get that, but isn't that configured via dt these days?
<oliv3r>
maybe i'm missing SND_SIMPLE_CARD ...
mzki has joined #linux-sunxi
<oliv3r>
anyway, the Kconfig does nothing more then enable a few standard kconfigs
<oliv3r>
but it's codekipp1r's playground so who knows :)
<oliv3r>
< > ASoC Simple sound card support HAH!
<oliv3r>
that's quite a critical component :)
<KotCzarny>
then it's a bug when it's not autoselected with i2s option?
<wens>
KotCzarny: there are a bunch of simple-card options :p
<wens>
oliv3r: not all boards use simple-card
<KotCzarny>
then at least suggest in daudio help ? :P
pfeerick has quit [Quit: WeeChat 1.8]
<oliv3r>
wens: yeah but i needed it, but didn't enable it; didn't realize it was a driver that needed enabling, so lets see :D
<KotCzarny>
wens, and oliv3r is a fine example that such help is needed ;)
<oliv3r>
it should be a module in the sunxi-defconfig (maybe it is, i'm using my own config)
<wens>
or we could add "implies" options to SPDIF and I2S Kconfig
<wens>
(since SPDIF also uses simple-card family)
<oliv3r>
i'm unfamiliar with the imples kconfig, what does it do?
<KotCzarny>
auto ticks other options
<oliv3r>
i thoguht that was 'selects'
<oliv3r>
ok, so i now got snd_soc_simple_card, but no go yet :(
<wens>
oliv3r: selects does not let you untick an option
<oliv3r>
ah, ok
<oliv3r>
very good to know
<wens>
so it's like "you should probably enable this, but it's really up to you"
<oliv3r>
then yeah, i2s does imply simple sound
<oliv3r>
so i have sun4i-is, snd-soc-simple-card, and my codec, snd-soc-max98357a, all loaded as the dt demanded it
<oliv3r>
ah yeah was looking into the reset thing, why is it not triggering a failure there
<KotCzarny>
ElBarto: your uboot is without block_cache, which means it hit my slow file
<KotCzarny>
anyway, "starting kernel ..." too
<ElBarto>
it's just vanilla u-boot with some patches for freebsd
ch40s[m] has joined #linux-sunxi
<ElBarto>
so not vanilla :)
<KotCzarny>
you might consider adding CONFIG_BLOCK_CACHE=y, it really helps with some cases (250kB/s -> 18MB/s)
<ElBarto>
I'll try that, but why it isn't enabled by default if it helps that much ?
<KotCzarny>
don't know, but some files on my ext4 boot partition are extremely slow (ext4 driver probably rereading whole tree)
<KotCzarny>
and some don't expose that problem
<oliv3r>
u-boot seems to also have issues with extents
<ElBarto>
I only load a small file with u-boot, then it's all freebsd loader dealing with raw devices/partitions
<oliv3r>
we noticed that after mkfs.ext4 u-boot is fast, once you move a file (say the kernel via apt-get update) u-boot becomes very slow. disabeling extents on the boot filesystem fixes that slow down
<oliv3r>
not sure if the BLOCK_CACHE option helps there
<KotCzarny>
oliv3r: adding that CONFIG_BLOCK_CACHE option also fixes that
<oliv3r>
ah nice
<oliv3r>
we now format our boot partition without the extents flag
reinforce has quit [Quit: Leaving.]
matthias_bgg has joined #linux-sunxi
mic-e[m] has joined #linux-sunxi
jernej has joined #linux-sunxi
lurchi__ has joined #linux-sunxi
lurchi_ has quit [Read error: Connection reset by peer]
IgorPec has joined #linux-sunxi
dave0x6d has joined #linux-sunxi
msimpson has quit [Quit: Leaving]
yann-kaelig has joined #linux-sunxi
reinforce has joined #linux-sunxi
chlorine_ has joined #linux-sunxi
chlorine has quit [Ping timeout: 240 seconds]
<KotCzarny>
hmm, loading initrd breaks the booting
matthias_bgg has quit [Quit: Leaving]
yann-kaelig has quit [Remote host closed the connection]
<wens>
MoeIcenowy: pinctrl patches were merged (but not pushed yet)
technix has joined #linux-sunxi
<technix>
Hello?
fugitive_ has joined #linux-sunxi
<technix>
So I get this on U-Boot: musb_init_controller failed with status -22. I am talking about my modified OrangePi Win Plus with SPI Flash and eMMC soldered.
chlorine_ has quit [Ping timeout: 240 seconds]
<technix>
I have modified the sun50i-orangepi-win.dts to include code regarding the eMMC and the USB OTG port
chlorine has joined #linux-sunxi
<KotCzarny>
technix: what tree are you using to boot it?
<technix>
sun50i-a64-orangepi-win
<technix>
I have modified it to add usb_phy and mmc2 sections
<technix>
The eMMC is largely okay (since I can see it)
<KotCzarny>
no no, i'm trying to compile kernel for my opiwin, but it's crashing at regulator_enable/sunxi_internal_codec_probe
<technix>
The USB OTG is the problem (I need it to use the UMS command in U-Boot
<technix>
Weird…
<KotCzarny>
that's why i asked what source are you using
<technix>
But I need the USB OTG to work so I can load stuff into the eMMC
<technix>
Also, when I copied the U-Boot that worked on the microSD card and can handle the eMMC directly onto the eMMC, it does not go past SPL.
<technix>
Strange.
chlorine_ has quit [Ping timeout: 260 seconds]
<technix>
Any idea?
<KotCzarny>
maybe you need to toggle something to make it into gadget mode?
<technix>
USB2: musb_init_controller failed with status -22
<technix>
The OTG port does not work regardless of mode
<technix>
It appeared to me that a lot of you have decided not to make use of the eMMC footprint?
<technix>
Also, where is the SPI support in the sun50i-a64.dtsi? If I can copy code from some other SoC which chip can serve the source? And where to find the addresses?
<KotCzarny>
soldering emmc isnt exactly easy task
enrico__ has quit [Quit: Bye]
<technix>
Local cell phone repair shops here can do it. I just need to provide the board and the eMMC chip. Pay them $10 and they can colder it for me.
<technix>
* solder
<jernej>
wens: should I respin all patches with "fixes:" tag?
<technix>
SUNXI SD/MMC: 1 (eMMC)
<wens>
jernej: I've taken the first 3, the third with a Fixes tag I added (see my reply)
<wens>
you're last patch is hard to figure out which commit it fixes
<wens>
since the earlier socs don't have the lock bit
<technix>
I have upgraded the SO-8 SPI Flash on my opiwin+ myself (that is some easy soldeing job with a good iron) and paid a local cell phone repair shop to add a 16GB Samsung eMMC
<jernej>
wens: true, but they also don't have fractional mode, right?
<wens>
jernej: sun5i does, so basically all SoCs do
reinforce has quit [Quit: Leaving.]
<jernej>
wens: Right. Should I add some logic which decides when to wait for lock?
kivutar has quit [Ping timeout: 246 seconds]
kivutar has joined #linux-sunxi
<wens>
jernej: not sure what you mean? does the lock exist? or some other condition?
kivutar has quit [Ping timeout: 240 seconds]
<jernej>
wens: I think fixes: 89a3dfb78707 ("clk: sunxi-ng: Add fractional lib") would apply. Function ccu_helper_wait_for_lock() returns without effect if lock number is 0.
<jernej>
so I think it is just nop on platforms without lock bit
<wens>
yup
<jernej>
should I add this info and send a new version?
<wens>
just reply and I'll add the tag
<jernej>
ok
phipli has joined #linux-sunxi
terra854 has quit [Quit: Connection closed for inactivity]
leviathan_ has joined #linux-sunxi
kivutar has joined #linux-sunxi
chlorine_ has joined #linux-sunxi
chlorine has quit [Ping timeout: 260 seconds]
kivutar has quit [Ping timeout: 260 seconds]
dave0x6d has quit [Quit: Connection closed for inactivity]