Zotan has joined #linux-exynos
EmilMedve has joined #linux-exynos
prahal____ has joined #linux-exynos
prahal_____ has quit [Ping timeout: 240 seconds]
EmilMedve has quit [Quit: Leaving.]
EmilMedve has joined #linux-exynos
dlan has quit [Quit: leaving]
dlan has joined #linux-exynos
bmbeach has joined #linux-exynos
<bmbeach> :wizzup yes quite interesting. I can dump the max chip and the I2s system
<bmbeach> and have a gui(I decided on motif) for the mixer
<bmbeach> From looking at what is happening and reading the discusions on sound
<bmbeach> on this channel it seems clear that the problem is with the epll.
<bmbeach> I'm talking about all the exynos chromebooks not just snow.
<bmbeach> The recommended values are not something that can be readily played around with
<bmbeach> since a pll is not a simple divider but a device with a tuned bp amplifier in it.
<bmbeach> the symptoms are what you are seeing and what I see all the time when I play
<bmbeach> with the values which is loss of lock.
<bmbeach> The other problem of playing to fast is simply the pll and the divider chain following
<bmbeach> it being programmed incorrectly. In particular when I load alsa and read the value
<bmbeach> for the epll frequenies I always get pdiv out of range ! **. The good new is that there
<bmbeach> are no registers that need to be programmed in the max chip(and other chips
<bmbeach> that operate similarly. When the i2s is operating in master mode (and i believe it can
<bmbeach> only operate in master mode) the max chip has a pll that locks onto the (i forget the name)
<bmbeach> the left-right multiplexer. The clock known as mclk on drivers the internal state machines
<bmbeach> and dsp things. So to summarize to fix the problem on peach-pit? (the frequency problem
<bmbeach> that is because I am seeing problems all over the place) the only thing that needs
<bmbeach> to be done is to correctly program the EPLL(fairly well documented in the samsung manual)
<bmbeach> and correcly program the following divider chain.
<bmbeach> BTW is is perfectly okay to change the frequency of the epll on the fly. I does not need to remain static
<bmbeach> I do it all the time even in the middle of a song playing.
bmbeach has left #linux-exynos [#linux-exynos]
dlan has quit [Ping timeout: 272 seconds]
dlan has joined #linux-exynos
caveat- has joined #linux-exynos
_anomaly_ has joined #linux-exynos
<Wizzup> bmbeach: thanks for all the info!
amitk has quit [Ping timeout: 240 seconds]
EmilMedve has quit [Quit: Leaving.]
amitk has joined #linux-exynos
zombah has joined #linux-exynos
gordan has joined #linux-exynos
krzk has joined #linux-exynos
krzk has quit [Quit: Wychodzi]
EmilMedve has joined #linux-exynos
prahal_____ has joined #linux-exynos
prahal____ has quit [Ping timeout: 256 seconds]
masta has quit [Ping timeout: 240 seconds]
pekka30 has joined #linux-exynos
EmilMedve has quit [Quit: Leaving.]
thopiekar has joined #linux-exynos
Vasco_O is now known as Vasco
masta has joined #linux-exynos
<Wizzup> javier__: you mailed the audio person about the audio issue, right? ever got a reply?
<daniels> i'm pretty sure the downstream chromeos tree carries a wider range of epll frequencies than upstream has
<daniels> (ditto vpll for mali)
<javier__> Wizzup: no answer and I didn't have time to look more
<Wizzup> ack :)
<javier__> daniels: but the ASoC machine driver doen't have a hw_params callback that sets the clock rates and dividers
<javier__> the downstream has one, that's what I mentioned to Alim
<daniels> javier__: ah, ugh
<javier__> so as bmbeach said, the master clock rate is just set on the drivers' probe and never touched again
zombah has quit [Quit: Leaving]
amitk has quit [Ping timeout: 272 seconds]
gordan has left #linux-exynos ["Konversation terminated!"]
thopiekar has quit [Remote host closed the connection]
<sjoerd> javier__: i'm always surprised by machine drivers that do clock rate/divider settings tbh
<sjoerd> unless there is some mchine specific logic to the clock settings it seems rather odd
<javier__> sjoerd: I see, so that should be handled in the codec driver then?
<javier__> sorry if my questions are silly, if I had be more familiar with audio, I would had solved this issue already :)
<sjoerd> It can
<sjoerd> It can be in either location, but if your codec is going to be the master and has a clock that only feeds it I'm unsure why you'd set it anywhere else
<sjoerd> then youcan also hopefully use the simple-card thing rather then even having a machine driver :)
<javier__> sjoerd: yes, that was in fact my second question to Alim ;)
masta has quit [Ping timeout: 240 seconds]
masta has joined #linux-exynos
mturquette has quit []
mturquette has joined #linux-exynos
Vasco is now known as Vasco_O
zombah has joined #linux-exynos
steev has quit [Ping timeout: 250 seconds]
mturquette has quit [Ping timeout: 250 seconds]
zombah has quit [Ping timeout: 250 seconds]
zombah has joined #linux-exynos
steev has joined #linux-exynos
mturquette has joined #linux-exynos