<critch>
bashintosh: Looks like our manufacturer is just not very clued into how to validate the SDK before handing it off to the customer. They are supposed to be getting me the current kernel tree for our device. When that is done, I should have the complete SDK for 4.4.4 on this tablet.
rory096 has joined #linux-rockchip
pizthewiz has quit [Quit:
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 244 seconds]
tony_ has quit [Quit: Leaving]
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 250 seconds]
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 260 seconds]
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 265 seconds]
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 240 seconds]
robogoat has joined #linux-rockchip
jey has joined #linux-rockchip
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 250 seconds]
markm has quit [Ping timeout: 240 seconds]
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 245 seconds]
akaizen has quit [Remote host closed the connection]
levd1 has quit [Remote host closed the connection]
levd has joined #linux-rockchip
levd has quit [Remote host closed the connection]
levd has joined #linux-rockchip
pizthewiz has joined #linux-rockchip
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 255 seconds]
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 246 seconds]
<mmind00>
norris: sorry, that was to late for me
levd1 has joined #linux-rockchip
JohnDoe_71Rus has joined #linux-rockchip
levd has quit [Ping timeout: 245 seconds]
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 252 seconds]
rory096 has quit [Ping timeout: 244 seconds]
pizthewiz has quit [Quit:
jey has quit [Remote host closed the connection]
akaizen has joined #linux-rockchip
markm has joined #linux-rockchip
akaizen has quit [Remote host closed the connection]
levd1 has joined #linux-rockchip
nighty^ has joined #linux-rockchip
levd has quit [Ping timeout: 265 seconds]
levd has joined #linux-rockchip
Paowz_ has joined #linux-rockchip
levd1 has quit [Ping timeout: 272 seconds]
levd1 has joined #linux-rockchip
ssvb has joined #linux-rockchip
levd has quit [Ping timeout: 255 seconds]
levd has joined #linux-rockchip
levd1 has quit [Ping timeout: 250 seconds]
naobsd has quit [Quit: naobsd]
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 245 seconds]
GTRsdk has quit [Remote host closed the connection]
<norris>
mmind00: no problem. it was a long shot :)
<mmind00>
norris: :-D
<norris>
mmind00: now that I have your ear though... :)
<mmind00>
norris: just fire away :-)
<norris>
what is your stance on factoring out common DTSI info vs having several similar DTS files for veyron-* platforms?
<norris>
I believe chromium has a sometimes hard to follow hierarchy of #includes
<mmind00>
norris: hehe yep ... the number of includes is interesting, but I guess comes with the number of individual devices
<norris>
AFAICT, they're often >50% similar
<norris>
but the last 20-50% makes it difficult
<mmind00>
norris: yeah ... what I want to avoid is numerous tiny dtsi files ... so stuff split out into separate dtsi files should provide value
<norris>
for one - i believe mighty (not submitted) is probably about as similar to jaq (just submitted) as jaq is to jerry
<norris>
ok, so you'd err on the side of several similar, larger DTS files? i.e., like my latest submission?
<mmind00>
yep ... if we find big chunks that warrant splitting out this can be done later as well
<norris>
ok, sure
<mmind00>
and for me, the jerry, minnie, etc dts files are not _that_ big ... as most stuff is contained in veyron.dtsi and veyron-chromebook.dtsi
<norris>
yeah
<norris>
mmind00: ok, thanks for the comments! i can take v2 from here
<mmind00>
norris: great ... looking forward to them :-)
<norris>
mmind00: btw, what time zone, so I can know when to expect to bug you?
<norris>
:D
<mmind00>
norris: timezone is CEST aka Europe :-D
<norris>
(I'm PDT / UTC-0700)
<norris>
thanks
<mmind00>
norris: yeah like amstan and dianders :-)
<norris>
exactly, i suspected you could guess
<mmind00>
hehe ... yeah
<c0d3z3r0>
rperier: I did some more tests… with/without cpuidle, hotplug etc. always the same problem "CPU… failed to come online"
cosm has quit [Ping timeout: 244 seconds]
JohnDoe_71Rus has joined #linux-rockchip
<c0d3z3r0>
rperier: the same kernel starts all cpus without kexec
cosm has joined #linux-rockchip
mrjay has joined #linux-rockchip
<topi`_>
I wonder how long until we see first 64-bit hacker boards, like RK3368 based
<topi`_>
I have the Rock2, which is nice, but it's still only 32-bit board
JohnDoe6 has joined #linux-rockchip
JohnDoe_71Rus has quit [Ping timeout: 244 seconds]
<rperier>
c0d3z3r0: don't compute, when you boot this kernel without using kexec everything works fine, but when you use kexec CPUs are not online when you restart your kernel on the fly ?
<rperier>
(via kexec)
<c0d3z3r0>
rperier: right
cosm has quit [Ping timeout: 244 seconds]
<c0d3z3r0>
I also tried kexec'ing this kernel from a kernel with disabled smp. same problem
cosm has joined #linux-rockchip
<c0d3z3r0>
rperier: looking at arch/arm/kernel/smp.c the cpus 1-3 get started but don't come online after the timeout
<rperier>
trying to boot my marsboard with next first... it does not boot :D
<rperier>
Failed to find PMU node is not criticial normally, I mean, rockchip_suspend_init just returns if the compatibility is not found ---> BUT, perhaps nothing is initialized on the PMU side...
<rperier>
which might explains why it hangs...
gb_master has joined #linux-rockchip
cosm has quit [Ping timeout: 250 seconds]
<c0d3z3r0>
hmm I get the PMU error with or without kexec
<c0d3z3r0>
and the system boots fine but with just one cpu
<Apocx>
I'm trying to follow the steps here (http://www.multitech.com/manuals/s000616_1.pdf) in order to add support to linux-rockchip for the LE910 4G modem. I'm at step 4, but the file /drivers/net/usb/qmi_wwan.c does not exist. Is there another file I should be using instead?
nighty^ has quit [Quit: Disappears in a puff of smoke]
<mmind00>
mrjay: strange aclk_peri is already in the critical clock list ... I currently don't have any rk3188/rk3066 boards with me (for next 2 weeks too), so maybe you could poke a bit around where it does missing?
<mmind00>
mrjay: one point to check would be of the clock actually is found in drivers/clk/rockchip/clk.c ... rockchip_clk_protect_critical()
<mrjay>
mmind00: alck_peri: was in the list, aclk_peri_pre: wasn't. Does the order in that list matter?
<mrjay>
mmind00: yes i can ... but my knowledge about clocks is very poor
<mmind00>
mrjay: normally it shouldn't ... and the clock-framework should enable parent clocks as well
<mmind00>
mrjay: aka rk3188_common_clk_init() is the setup of shared clocks between rk3066/rk3188 and I noticed, the critical clocks may be handled a bit prematurely, as the soc-specific functions also add clocks as well
<mrjay>
mmind00: applied, compiling
<Apocx>
so if qmi_wwan.c does not exist in linux-rockchip, does that mean I won't be able to use the LE910? There were definitions for an LE920 in /drivers/usb/serial/option.c, so I assumed I'd be able to add support for the 910
cristian_c has quit [Read error: Connection reset by peer]
cristian_c has joined #linux-rockchip
cristian_c has quit [Excess Flood]
Guest10925 has joined #linux-rockchip
Guest10925 has quit [Excess Flood]
<mmind00>
sjoerd: when you're looking at the spdif again, you could also give https://github.com/mmind/linux-rockchip/tree/tmp/spdif a try ... fractional dividers (issue 1) work for me with this and the dma-related (issue 2) stuttering is also gone
<sjoerd>
mmind00: hmm i didn't see the burst issue thus far on spdif
<sjoerd>
mmind00: but that's great, will have a play with that :)
<mmind00>
sjoerd: when playing spdif stuff on my firefly it was stuttering all the time (stuttering in the sense of playback breaking off for a very short while)
<Apocx>
mmind00: I see your repo includes qmi_wwan.c, do you happen to know if I can drop that into my own repo and have it work? Or does it depend on a bunch of other files?
<mmind00>
Apocx: that is simply the mainline kernel, with that modem driver ... not sure if this will fit into an ancient 3.0 or 3.10 kernel
<Apocx>
Ah ok. I'm using the radxa-linux-rockchip 3.0 kernel
<Apocx>
Welp I added it and am trying to compile now. Probably a longshot and will just throw a million errors but worth a try I guess
<sjoerd>
mmind00: wonder wy it dosn't happen on my square nor rock pro
<sjoerd>
anyway naptime here :)
gb_master has joined #linux-rockchip
<mrjay>
mmind: last patch helped
<mrjay>
mmind00: board is booting again
<mrjay>
mmind00: last patch helped (keep forgeting about tab thing ;)
<mrjay>
mmind00: thanks for your time ... you're awsome
<mrjay>
rperier: about marsboard: check mmind last hint mine board is booting again
<mmind00>
mrjay: great to hear that
<mrjay>
mmind00: i know you're busy man, but if you find time send fix for mainline please :)
<mmind00>
mrjay: yep, already on the list
markm has quit [Ping timeout: 246 seconds]
dlezcano has joined #linux-rockchip
markm has joined #linux-rockchip
dlezcano has quit [Ping timeout: 245 seconds]
mrjay has quit [Quit: Page closed]
<Apocx>
nope, missing dependencies. down the rabbit hole I go. guess I'll keep adding them until I find something I can't fix
<Apocx>
and if that happens, good bye Radxa Rock Pro
<mmind00>
leming: amstan said, you have working sound ... could you share your alsa settings somehow? ... I'm currently playing around with alsa on mainline, but mindlessly playing around with mixer settings seems to have the ability to damage speakers it seems [they at least start to smell bad] - so some starting point that is working somewhere would help a lot :-)
<amstan>
right.. i wanted to talk to dgreid about this, perhaps srao too
<amstan>
srao: how do we not burn our veyron speakers by misconfiguring alsa?
<mmind00>
srao: additionally do you know what could be missing from upstream - the rockchip_max98090 glue driver seems to make it into 4.3, but so far I didn't hear anything, just smelled strange things :-)
<amstan>
mmind00: it's probably just your settings then, i didn't hear anything either even though i made it smell, once i got leming's config it worked perfectly
<amstan>
despite the smell
<amstan>
mmind00: could you send me the config that makes it smelly btw?
<amstan>
perhaps we could hack some of those dangerous settings out the kernel
<mmind00>
amstan: sadly I didn't save anything ... just scrolled through the alsamixer interface, noticed the smell and turned off the device
<mmind00>
s/scrolled through/scrolled through and toggled some options/
<amstan>
mmind00: yep.. i did the same stuff
<amstan>
mmind00: i could do testing one day to see what settings are dangerous
<amstan>
perhaps with speakers disconnected
<amstan>
or.. i could do that capacitor thing too
gb_master has quit [Remote host closed the connection]
<amstan>
mmind00: dgreid suggests we copy the chromeos UCM files
<amstan>
and be very careful what else you edit in alsa
<amstan>
and the bleak truth is that they're not meant to be adjusted without a scope/datasheet and schematics
<amstan>
kinda sucks..
<amstan>
mmind00: of course i managed to send another html email to linux kernel lists
<amstan>
at least the important people got it...
markm has quit [Ping timeout: 245 seconds]
<Apocx>
Is there no version of the linux-rockchip kernel that supports QMI?