naobsd has quit [Remote host closed the connection]
levd has quit [Ping timeout: 272 seconds]
levd1 is now known as levd
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 246 seconds]
levd1 is now known as levd
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 246 seconds]
levd1 is now known as levd
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 252 seconds]
levd1 is now known as levd
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 250 seconds]
levd1 is now known as levd
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 260 seconds]
levd1 is now known as levd
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 255 seconds]
levd1 is now known as levd
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 255 seconds]
levd1 is now known as levd
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 252 seconds]
levd1 is now known as levd
<bashintosh>
..finally booting mainline 4.0.0-rc1 on CX929!
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 264 seconds]
levd1 is now known as levd
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 255 seconds]
levd1 is now known as levd
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 255 seconds]
levd1 is now known as levd
levd has quit [Ping timeout: 240 seconds]
levd has joined #linux-rockchip
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 240 seconds]
levd1 is now known as levd
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 250 seconds]
levd1 is now known as levd
sjoerd` is now known as sjoerd
sjoerd is now known as sjoerd`
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 240 seconds]
levd1 is now known as levd
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 240 seconds]
levd1 is now known as levd
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 256 seconds]
levd1 is now known as levd
premoboss has joined #linux-rockchip
levd has quit [Remote host closed the connection]
levd has joined #linux-rockchip
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 256 seconds]
levd1 is now known as levd
markm has joined #linux-rockchip
levd1 has joined #linux-rockchip
jas-hacks has joined #linux-rockchip
levd has quit [Ping timeout: 256 seconds]
levd1 is now known as levd
naobsd has joined #linux-rockchip
premoboss has quit [Read error: No route to host]
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 265 seconds]
levd1 is now known as levd
naobsd has quit [Quit: naobsd]
premoboss has joined #linux-rockchip
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 252 seconds]
levd1 is now known as levd
gb_master has joined #linux-rockchip
dlezcano has joined #linux-rockchip
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 252 seconds]
levd1 is now known as levd
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 246 seconds]
levd1 is now known as levd
rubensm has quit [Ping timeout: 268 seconds]
levd has quit [Ping timeout: 264 seconds]
levd has joined #linux-rockchip
rubensm has joined #linux-rockchip
levd1 has joined #linux-rockchip
levd has quit [Ping timeout: 255 seconds]
levd1 is now known as levd
levd has quit [Ping timeout: 240 seconds]
gb_master has quit [Remote host closed the connection]
jas-hacks has left #linux-rockchip [#linux-rockchip]
mrutland_ is now known as mrutland
premoboss has quit [Quit: Sto andando via]
pietrushnic has quit [Quit: Coyote finally caught me]
ssvb has quit [Ping timeout: 272 seconds]
premoboss has joined #linux-rockchip
markm has quit [Ping timeout: 246 seconds]
cristian_c has joined #linux-rockchip
ssvb has joined #linux-rockchip
jkstrick has joined #linux-rockchip
gb_master has joined #linux-rockchip
cnxsoft has quit [Quit: cnxsoft]
<sjoerd`>
mmind00: do you know of any issues with the precision of the clock on rk3288
<sjoerd`>
I'm having some fun with libvlc where it seems to try and correlate the system clock with the audio rate and think the speed doesn't match up
<mmind00>
sjoerd`: not that I know of ... on the very fine granularity side, there is possible pll-jitter but other than that I'm nt aware of anything actually happening in the past
* sjoerd`
thinks vlc is just being silly
<sjoerd`>
gstreamer works fine as it just slaves everything to the audio clock typically
<mmind00>
maybe vlc is trying to find some common multiple or something?
<sjoerd`>
neh it just seems tobe trying to determine the actual output rate of the audio by looking at the system clock
<mmind00>
hmm, system-clock do you mean the cpu clock itself?
<sjoerd`>
which doesn't work too well
<sjoerd`>
yeah
<sjoerd`>
it's CLOCK_MONOTONIC where it looks afaik
<mmind00>
hmm, on the rk3288 timer clocks are supposed to be sourced from the 24mhz oscillator exclusively ... I'd think on the rk3188 you might have more issues [global-timer supplied by core-periph clock]
<sjoerd`>
this is on 3288
<mmind00>
I read that :-) ... was mrely talking to myself here
<sjoerd`>
ah :)
<mmind00>
but sorry, I don't have any really bright idea for this right now
<sjoerd`>
Np
<sjoerd`>
for now i'm just going to blame vlc
<sjoerd`>
the only other thing i could think of was the calculation in the fractional dividers being wrong tbh
<mmind00>
hmm, neither the ChromeOS nor the Rockchip guy doing the RK3036 complained so far, so I guess the fractional calculation might the one part that is actually correct ;-)
<sjoerd`>
:)
* sjoerd`
still very happy to see RK3036 being upstreamed
<mmind00>
me as well
sjoerd` is now known as sjoerd
<gb_master>
mmind00, sjoerd`: what's the situation about the clocksource for rk3188?
GriefNorth has joined #linux-rockchip
<mmind00>
gb_master: I guess you mean my sentence above? ... the Cortex-A9 SoCs do have an arm-global-timer as clocksource ... it gets supplied by the core-periph clock that is dependent on the cpuclk-speed and the driver currently does not handle the changing cpuclk well
<gb_master>
mmind00: the other day I was talking with c0d3z3r0 about this, and apparently rk3188 should use xin24m as a clocksource (instead of the CPU clock), as, apparently, there's clock drift after a while. Sadly I don't have many details on this... I just wanted to ask if you knew more
<mmind00>
gb_master: sadly the global-timer is not really documented in the TRM at all, but we mean the same thing :-) ... from what I gathered, as I said the global-timer is supplied by the core-periph clock (most likely) and thus gets influenced by it changing together with the cpuclk
<mmind00>
gb_master: which is probably the reason Rockchip used the other soc-specific timers in the first place and not the global-timer ... but so far nobody looked any deeper into if that is actually fixable via the global-timer as well
<gb_master>
mmind00: I was going to ask you exactly this :)
<mmind00>
gb_master: I did a preliminary change at some point, but c0d3z3r0 said, that while it helped a bit, it wasn't fixing the whole problem
<mmind00>
gb_master: at least that is what I remember ;-)
<gb_master>
mmind00: I wish I could really help you guys, at least for the rk3188... but, apart from testing...
<mmind00>
gb_master: np ... sadly the rk3188/rk3066 don't get as much love currently as the newer socs
akaizen has joined #linux-rockchip
<gb_master>
mmind00: too bad
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-rockchip
rubensm has quit [Ping timeout: 240 seconds]
<sjoerd>
hmrngt why does rkflashtool suddenly fail to read stuff of teh emmc in maskrom mode
* sjoerd
stabs
rubensm has joined #linux-rockchip
premoboss has quit [Remote host closed the connection]
rory096 has quit [Ping timeout: 246 seconds]
akaizen has quit [Remote host closed the connection]
cristian_c has quit [Ping timeout: 260 seconds]
cristian_c has joined #linux-rockchip
rubensm has quit [Ping timeout: 240 seconds]
rubensm has joined #linux-rockchip
akaizen has joined #linux-rockchip
BorgCuba has joined #linux-rockchip
akaizen has quit [Remote host closed the connection]
akaizen has joined #linux-rockchip
akaizen has quit [Remote host closed the connection]
cristian_c has quit [Ping timeout: 260 seconds]
johnnyr has quit [Ping timeout: 272 seconds]
johnnyr has joined #linux-rockchip
akaizen has joined #linux-rockchip
GriefNorth has quit [Ping timeout: 256 seconds]
cristian_c has joined #linux-rockchip
cristian_c has quit [Read error: Connection reset by peer]
akaizen has quit [Remote host closed the connection]
cristian_c has joined #linux-rockchip
cristian_c has quit [Read error: Connection reset by peer]
pietrushnic has joined #linux-rockchip
cristian_c has joined #linux-rockchip
cristian_c has quit [Read error: Connection reset by peer]
lerc has joined #linux-rockchip
<tnn>
I'm trying to probe around with a scope in order to find the console port on a rk3026 board. I have tied "home" to ground, which makes the board show up with rkflashtool.
<tnn>
should powering on this way generate some output on the first uart?
<tnn>
maybe I could write uboot to the flash and get some output that way? Currently the thing runs android.
<mmind00>
tnn: any loader will normally generate console output ... on most socs I've seen so far on uart2 (aka the 3rd one)
<tnn>
would you happen to know which pin this is on a LQFP176 RK3026?
<bashintosh>
What's the status of eDP transmitter support on mainline kernel (RK3288)? amstan, you folks use eDP on the Chromebook right?
<mmind00>
tnn: not sure what you mean with a LQFP176
<mmind00>
tnn: generally I haven't seen a rk3026 at all yet ... but on all others I've seen it's always uart2 but where those pins are I don't know
<amstan>
mmind00: that's a nice patch series
<amstan>
i like how yakir collaborated with javier
<BorgCuba>
mmind00, lqfp176 ist the package of the chip quad flat pack with 176 leads
<BorgCuba>
the 3026 ist dual a9 @1ghz, very similar to the 2926 except for its two cores
<tnn>
I'm 90% sure I found the correct pin but it's wired to an sd card slot. The rk3126 datasheet does mention that uart2_tx can double as sdmmc0_d1.
<mmind00>
amstan: yep, Yakir really understands the process
<tnn>
so I should probably just try a different boot loader and not plug an SD card in
<mmind00>
tnn: please don't try to use datasheets for other socs as source :-) ... pin-muxing (what pins are shared between components) is highly soc-specific
<BorgCuba>
tnn, you could compile your own uboot (with the appropriate uart) and upload it via rkflashtool (n addr1; x addr2)
<BorgCuba>
though I am not sure atm if these commands will work with the bootrom
<mmind00>
tnn: uart2_sin is shared with LCDC0_D20 and EBC_BORDER0, uart2_sout with LCDC_d20 and EBC_BORDER1 [not sure what tht EBC-stuff is though] ... but it looks like on the rk3026 the debug-uart is a bit more flexible and dependant on the board
<mmind00>
tnn: uart0 does not share its pins with anything, but is generally used for bluetooth or so ... uart1 shares its pins with the SPI controller
<mmind00>
tnn: not sure if that helps you though
<bashintosh>
mmind00: thanks!! Will read through! ^_^
<bashintosh>
mmind00: which tree to these patches currently apply to? linux-next?
<mmind00>
bashintosh: not sure, probably drm-next or linux-next ... in the previous revision Yakir provided a github repository so another developer could test the Samsung-related part
<bashintosh>
mmind00: alrighty - will dig around. Very willing to contribute/test as I am using eDP as main display source..
gb_master has quit [Quit: Leaving]
BorgCuba has quit [Quit: leaving]
gb_master has joined #linux-rockchip
gb_master has quit [Remote host closed the connection]
rory096 has joined #linux-rockchip
<mmind00>
bashintosh: yep, I'm also meaning to give this another go :-)
jkstrick has quit [Remote host closed the connection]
<bashintosh>
mmind00: aah grand! I'll give it a go later today - dts should not be a problem as my board is quite custom anyway so (sadly) never boots with "default" rk3288.dtsi and alike
<bashintosh>
mmind00: ..and thanks!
<mmind00>
bashintosh: glad to help ... most likely you can just look at the dt-binding docs to make a edp node
<mmind00>
bashintosh: why doesn't it boot (and what "default" dtsi do you mean)?
<bashintosh>
I have eDP working with older kernels (i.e. RK 3.10 and ChromeOS 3.14) but I bet the dts nodes won't work with mainline for some reason so documentation will be vital ^_^
<mmind00>
bashintosh: looks more like ChromiumOS :-) [the stuff Rockchip worked on initially] ... [rk_fb.h being a good indicator :-) ]
<bashintosh>
mmind00: oops yes ChromiumOS, not ChromeOS (do they use the same kernel?).
<mmind00>
bashintosh: similar ones ... both are based on 3.14, but the real ChromeOS kernel did a lot different ... the kernel from RK being more like some sort of prototype
<bashintosh>
mmind00: gotcha - quite exciting to test mainline actually!