<Wizzup>
obbrobbrio: re: snow, I think so. But please document it when/if it works
prahal has quit [Ping timeout: 264 seconds]
prahal has joined #linux-exynos
prahal has quit [Ping timeout: 240 seconds]
gladiac has quit [Read error: Connection reset by peer]
gladiac has joined #linux-exynos
<obbrobbrio>
Wizzup: is it a yes? i mean, that is the right way to install video drivers or someone else managed to do it differently? i find really little documentation about
<obbrobbrio>
anyways if i get something good i'll report, yes
<Wizzup>
obbrobbrio: I don't want to use proprietary drivers, so I don't know, sorry
<Wizzup>
I think some people mentioned using it yesterday, check the logs
<Wizzup>
afk..bbl
<javier__>
afaerber: great, thanks for the info
<obbrobbrio>
Wizzup: ok, i think daniels and libv were talking about that yesterday.
<obbrobbrio>
anyways i'd like free (as in freedom) drivers too, but sice i use the chromebook for my daily works and not only for testing, for now it would be nice to see if at least it works with binary drivers.
<libv>
obbrobbrio: nothing relevant seems to have since been added to the wiki :(
<obbrobbrio>
and meanwhile if there is a way i can contribute i would be more than happy, even if i'm still not so skilled
<obbrobbrio>
libv: does this community consider the proprietary drivers a way for the end user? if not i'll not ask and disturb here about that
gladiac has quit [Remote host closed the connection]
<libv>
obbrobbrio: you will find that i have done a lot of the legwork for sunxi to help people in getting the binary going, simply because i hate to waste resources and my own time
<libv>
most people who use a mali-400 tend to use the integration and easier installation i provided
<libv>
mali-400 on a more proper linux than android
<libv>
you cannot RE thin air, so i too use the binary, and i too had to bring this up for mali-400 before
<obbrobbrio>
yes, seems legit
<obbrobbrio>
so if you like i can report here what i manage to get
<libv>
i have however not done the work to bring up the binary usefully on the mali t series, so i have had nothing worth documenting or improving
<libv>
but other people seem to have managed to do so, yet did not document things
<libv>
reporting here has severely limited use
<libv>
use the wiki
<obbrobbrio>
yes sure
<obbrobbrio>
i meant, report to guys that lives here from more time than me :)
<obbrobbrio>
anyways and avice about how to test if i "bring up the binary usefully" would be appreciated ;)
<obbrobbrio>
oh well, there is something in your link
gladiac has joined #linux-exynos
<libv>
obbrobbrio: very little of what is in there will apply for the mali midgard
<obbrobbrio>
yes indeed, i'm extracting the concept
<libv>
you will be able to employ quite a bit of it for the exynos 4xxx series, unless the odroid kernel has moved on to a version for which there are (more severe) limitations on distribution
<obbrobbrio>
the steps are similar to the ones in the link i pasted previously iirc, but the last time i tried i got frequent crashes and when not crashing the fishietank benchmark showed about 1 fps
<obbrobbrio>
and in the log there were some complaining about armsoc_dri.so
<obbrobbrio>
but i'll test more accurately in these days
<Wizzup>
obbrobbrio: I would be very happy if you documented the binary driver process
<obbrobbrio>
Wizzup: sure, but very likely you'll see me asking for help in this channel during the process :)
<Wizzup>
ssk: summary: kernel seems a bit old, looks like it perhaps cannot load/boot your rootfs/device, and config seems a bit off perhaps (cpu limit when there are more cores/cpus?)
ssk has quit [Ping timeout: 245 seconds]
ssk has joined #linux-exynos
ssvb has quit [Ping timeout: 250 seconds]
gautam__ has joined #linux-exynos
<ssk>
init: udev-fallback-graphics main process (2297) terminated with status 1
<javier__>
afaerber: hi, do you have some minutes to chat about your sound series?
<ssk>
any one tell me what this error mean, i cannot run monitor for exynos 5420 arndale octaboard kernelversion is :3.19.0 mainline
<ssk>
init: udev-fallback-graphics main process (2297) terminated with status 1
prahal has joined #linux-exynos
Tenkawa has joined #linux-exynos
<afaerber>
javier__, pong
<javier__>
afaerber: hi, already commented on the mailing list
<Tenkawa>
whats new all?
Tenkawa has quit [Remote host closed the connection]
<afaerber>
javier__, how do you test audio? :)
<javier__>
afaerber: I'm testing with alsaucm -c $board set _verb HiFi and aplay / arecord
<javier__>
afaerber: but I only got playback to work on peach pit/pi (no capture) and didn't get it work work at all on snow
<afaerber>
I've been using gnome-control-center's loudspeaker test, and as long as the drm driver is not working properly I can't login to the desktop and try ;)
<javier__>
afaerber: everything audio related is different in the mainline and dowstream kenrels (snow ASoC machine driver vs daisy_max98095), CPU and codec DAI drivers, missing mic and jack detection, etc
<afaerber>
javier__, is there some system audio file that comes with one of the desktops that I could test via aplay?
<javier__>
yes, I also used mpg123 and some mp3's to test the downstream 3.8 kernel but for now with mainline I just want some playback to work
Tenkawa has joined #linux-exynos
<javier__>
afaerber: I was not that familiar with alsa in general and ASoC so I've been learning along the way
<afaerber>
not working then atm (aplay /usr/share/sounds/alsa/test.wav, works on my notebook)
<javier__>
afaerber: and are you sure the ucm profile is correct?
<afaerber>
javier__, no, I still have some things commented out to make set _verb HiFi work at all
<javier__>
afaerber: the downstream daisy_max98095 driver does a lot of clocks setting in set_audio_clock_heirachy() and set_epll_rate() and also the sound dev node in cros5250-common.dtsi has *a lot* of clocks defined that are not in mainline
* Tenkawa
had to adapt the dts/dtsi a lot
<Tenkawa>
to get any audio
<Tenkawa>
and its still not working completely right yet
<javier__>
afaerber: but tushar's patches seems to imply that only the SoC XCLKOUT is needed and that matches the documentation I have so I'm a bit lost
<javier__>
Tenkawa: what changes did you do? are you using the Snow ASoC machine driver from mainline or did you cherry-pick the downstream ASoC driver?
<Tenkawa>
javier__: I'm working on reacquiring the src that I accidently cleanedv up
<Tenkawa>
its the snow machine though yes
ssvb has joined #linux-exynos
<Tenkawa>
bbl
Tenkawa has quit [Quit: bbl]
ssk has quit [Quit: Leaving]
gautam__ has quit [Remote host closed the connection]
afaerber has quit [Ping timeout: 265 seconds]
afaerber has joined #linux-exynos
zombah has quit [Quit: Leaving]
amitk has quit [Quit: leaving]
<afaerber>
javier__, sound working! :D
* afaerber
did adjust alsamixer manually, got to verify the ucm profile
<Wizzup>
! :)
<Wizzup>
on the hp 11?
<afaerber>
yes
<afaerber>
but...
<afaerber>
[ +0,006591] max98088 7-0010: Invalid master clock frequency
<afaerber>
on next boot
<Wizzup>
what Swabbles and I noticed a long time ago, is that when we rebooted from chromeos to mainline using reboot (not poweroff), sound would work
<Wizzup>
that was really annoying (figuring that out)
<Wizzup>
but I guess since then the situation changed quite a bit
<afaerber>
I wondered whether the firmware doing a beep (waiting for Ctrl+d) has influence on it as well
<bmbeach>
the Support table you have USB3=?. I don't know
<bmbeach>
whether it means whether the the higher speed usb3
<bmbeach>
a hub stuck in it and connected to the hub I have
<bmbeach>
Snow is my only machine and ever since I got
<bmbeach>
exclusively. Lots of things arent't working but
bmbeach has left #linux-exynos [#linux-exynos]
zombah has joined #linux-exynos
<javier__>
afaerber: are you still around?
<afaerber>
javier__, yes
<afaerber>
(^ that was the most unstructured and impatient irc posting I've seen... ;))
<javier__>
afaerber: haha, I had the same issue that you and digging into the exynos-reference vendor tree I found this commit that avoids the invalid master clock frequency
<javier__>
afaerber: with that + defining the master clock in the max98095 codec I've audio playback and capture on snow as well
<javier__>
but is buggy, sometimes if I record and then playing back the audio is really bad and doesn't work until I reboot
<afaerber>
javier__, is "Sylwester's patch" downstream as well?
<javier__>
afaerber: yes, it is. Let me look at the sha1 id
<javier__>
afaerber: Tushar refers to commit 86be408bfbd8 ("clk: Support for clock parents and rates assigned from device tree") afaict
<javier__>
afaerber: does it solve your issue too? I was planning to include Tushar's patch (with a proper commit message) on my series to add Sound support to Snow
<si1v3r_>
It would be good to have user reports of features working on the wiki.
<javier__>
afaerber: sorry, I missread your question and thought you asked if Sylwester patch is already in upstream
<javier__>
that commit id is for mainline
<afaerber>
javier__, I did find it in linux-next :) still compiling
<javier__>
afaerber: ok
<afaerber>
javier__, didn't work
<javier__>
afaerber: hrmm, can you print the rate returned by clk_round_rate() in max98088_dai_set_sysclk()?
<javier__>
for me is 0 without that patch and when the xclout is allowed to be re-parented on rate change is 24MHz
<javier__>
afaerber: I have to leave for today, I'll answer in the thread what we discussed here and maybe Doug can shed some light
<afaerber>
javier__, 24000000
<javier__>
afaerber: hrmm, that's strange I wonder why you are having the "Invalid master clock frequency" error then
<javier__>
if that falls between 20MHz to 30MHz so the codec driver should set M98088_REG_10_SYS_CLK to 0x20 by looking at the driver
<afaerber>
javier__, with your patch I don't
<afaerber>
I'll revert it and recheck
<javier__>
afaerber: but you said it didn't work...
<javier__>
or do you mean that the error is not shown but still audio is not working?
<afaerber>
correct, with your patch no error but no audio either
<javier__>
afaerber: not my patch btw, I found that doing some code archeology on Samsung's vendor tree :)
<javier__>
ok so with both patches from tushar + a working ucm profile I've audio on Snow
<javier__>
I wonder what's the difference
* Wizzup
is excited
<Tenkawa>
Wizzup: oh?
<Wizzup>
(for snow audio)
<afaerber>
Tenkawa, from time to time there's progress here ;)
<Tenkawa>
ahhh
<Tenkawa>
afaerber: I agree
<Wizzup>
bmbeach: I don't know if you read the logs, but cool, happy that it works for you
<Tenkawa>
Ive seen a lot of progress
<javier__>
afaerber: when you do a cool boot or waiting for the beep, you still see the invalid clock frequency but still works?
<javier__>
afaerber: but yeah, it seems that the kernel is relying on some setup made by the bootloader
<javier__>
probably it will work on each boot if you have "sound init" as a part of your u-boot boot cmd
<afaerber>
javier__, with early Ctrl+d, freq = 0
<javier__>
afaerber: oh, that's interesting even with tushar's patch to allow xclkout to be re-parented?
<afaerber>
javier__, no, I reverted that. with his patch and early Ctrl+d it was the above 24000000
<javier__>
afaerber: ok
<javier__>
afaerber: really gotta go now, I answered to your email so the people in list are aware of our latest findings and maybe have an idea