<mmind00>
mrjay: yeah, supposedly it can draw a triangle currently :-)
libv has quit [Quit: Changing server]
libv has joined #linux-rockchip
<mrjay>
mmind00: yep ... but it's a start
<mmind00>
mrjay: yep ... when I have time I hope to give this a try on a rk3036 board (mali400 but also supported display subsystem)
<mrjay>
mmind00: i'll wait until it will be mainlined ;-)
<mmind00>
mrjay: also the general available boards with mali400 don't have a supported drm driver (+hdmi or whatever) right now
<mrjay>
mmind00: maybe it will need only simple(or not that simple) glue code in rockchip drm
LongWork has joined #linux-rockchip
rperier has quit [Changing host]
rperier has joined #linux-rockchip
feoafka has quit [Quit: feoafka]
LongWork1 has joined #linux-rockchip
<mmind00>
mrjay: the integration isn't the problem ... more like getting core support for display and hdmi controllers for rk3066/rk3188
LongWork has quit [Ping timeout: 240 seconds]
<mrjay>
mmind00: you're right ... for rk3066 lcdc shoudn't be that hard as there is a section in trm about that
LongWork1 is now known as LongWork
<mrjay>
mmind00: but hdmi ip isn't
wzyy2 has joined #linux-rockchip
moneymaker has joined #linux-rockchip
<moneymaker>
hi
<moneymaker>
anyone here who can help me to get a working defconfig for an RK3288 tablet?
<moneymaker>
nobody here? :)
ganbold has quit [Quit: This computer has gone to sleep]
ganbold has joined #linux-rockchip
Aussie_matt has quit [Remote host closed the connection]
ganbold has quit [Quit: This computer has gone to sleep]
ganbold has joined #linux-rockchip
JohnDoe_71Rus has joined #linux-rockchip
<paulk-gagarine>
moneymaker, with upstream?
moneymaker_ has joined #linux-rockchip
<moneymaker_>
hey, no its 3.10.0
<moneymaker_>
i'm stuck at "__clk_unprepare" kernel oops - at address 00000032
moneymaker has quit [Ping timeout: 260 seconds]
matthias_bgg has joined #linux-rockchip
matthias_bgg has quit [Client Quit]
matthias_bgg has joined #linux-rockchip
mrjay has quit [Quit: Page closed]
cnxsoft has quit [Quit: cnxsoft]
afaerber has quit [Remote host closed the connection]
<paulk-gagarine>
ok, I'm not interested in downstream stuff
<moneymaker_>
thats sad
<moneymaker_>
i dont know it any newer kernel runs with my tablet, i did the test with mainstream 4.4 - but i got the same result, do you know if its possible to run a newer kernel?
<moneymaker_>
maybe the device drivers for MPU or VPU dont work over 3.10? i dont know
moneymaker_ has quit [Quit: Page closed]
afaerber has joined #linux-rockchip
LongWork has quit [Quit: LongWork]
afaerber has quit [Remote host closed the connection]
afaerber has joined #linux-rockchip
patrik has quit [Ping timeout: 240 seconds]
perr has joined #linux-rockchip
wadim_ has quit [Remote host closed the connection]
patrik has joined #linux-rockchip
vagrantc has joined #linux-rockchip
perr has quit [Quit: Leaving]
matthias_bgg has quit [Quit: Leaving]
afaerber has quit [Quit: Leaving]
BenG83 has quit [Ping timeout: 240 seconds]
BenG83_ has quit [Quit: Leaving]
BenG83 has joined #linux-rockchip
moneymaker has joined #linux-rockchip
moneymaker has quit [Ping timeout: 260 seconds]
cyteen has quit [Ping timeout: 260 seconds]
afaerber has joined #linux-rockchip
kloczek has joined #linux-rockchip
afaerber has quit [Ping timeout: 246 seconds]
afaerber has joined #linux-rockchip
cyteen has joined #linux-rockchip
wzyy2 has quit [Ping timeout: 240 seconds]
<vagrantc>
filed a bug on screen to get support for 1500000 baud (used by firefly-rk3399), and lo and behold it's in Debian experimental's screen now :)
<diego71>
vagrantc: good!
<diego71>
But I thought that 115200 was enough for everybody :)
<vagrantc>
me too, but apparently some boards have the ATF, firmware, u-boot, linux all defaulting to 1500000
<vagrantc>
can't say i notice the kernel messages scrolling by any faster... :)
<beeble>
its a lot faster
<beeble>
you don't have any uart blocking during bootup anymore
<beeble>
but instill default to 115200 for the own builds since 1500000 is a problem with a lot of converters and terminal software
<beeble>
but building picocom from source is straight forward and has no dependencies
<vagrantc>
i've been debating weather to change the default to 115200 in debian's u-boot when i enable the firefly-rk3399 board...
<beeble>
as a easy way to have at least the software part everywhere
<beeble>
for uboot there is a kconfig now. so at least its no hassle to change
<vagrantc>
for people building from source, no
<beeble>
why?
<vagrantc>
it's easy for people building from source to change.
<vagrantc>
but not for people using pre-built binaries :)
<vagrantc>
hence, wondering weather debian should ship the pre-built binaries with the default set to 115200
<beeble>
i would recommend 115290 for compatibilty reasons
<beeble>
115200 (sorry small phone keys)
<beeble>
i have tested some of the more popular usb uart converters and the most common ones don't even go that fast
<beeble>
and even newer ones can have issues with the drivers on windows not supporting it
<vagrantc>
hrm. firefly-rk3399 mmc patches haven't been merged into u-boot yet...
* vagrantc
might just upload to debian experimental with the submitted patches
descend-irc has quit [Quit: Connection closed for inactivity]
<BenG83>
RK3328 BSP also uses 1.5Mbaud for miniloard, u-boot and kernel
<BenG83>
*miniloader
<beeble>
its the default register settings
<vagrantc>
ah, looks like the patches have been applied to u-boot-rockchip/next... good
<mmind00>
hmm, my cheap PL2303 china clone doesn't have a problem with 1500000 on my rock64 (rk3328) and miniterm.py and ser2net also seemed fine :-)
<mmind00>
and for the rk3328 you cannot change the default right now, as there is no spl support yet
<BenG83>
I am using PL2303HX and FT232RL with Rock64, both work fine so far
<BenG83>
PL2303TA didnt want to set 1.5Mb
<vagrantc>
some have all the luck :)
<BenG83>
I am trying to get the SPI flash on Rock64 to play nice
<BenG83>
but my kernel crashes during longe read/write operations :(
<beeble>
mmind00: not wanting to say that there arent any chips out there. but some common ftdi and prolific do have the issue. also stock cu on mac os and packed minicoms, picocom and screen. so it's really just something you have to address at least in the documentation. i opted to not try to add another thing that could go wring with customers :)
<mmind00>
beeble: :-)
<beeble>
still running into the issue that they have 32bit userland and try to run 64bit toolchains
<beeble>
even if you have a chapter about it in the manual