#linux-rockchip on 2017-01-17 — irc logs at freenode.irclog.whitequark.org

2014-10-07 12:46 ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | Wiki at http://linux-rockchip.info | Logs at http://irclog.whitequark.org/linux-rockchip | ML at http://groups.google.com/group/linux-rockchip

00:21 nighty has joined #linux-rockchip

00:43 paulk-collins has quit [Remote host closed the connection]

01:24 mrueg has quit [Remote host closed the connection]

01:26 mrueg has joined #linux-rockchip

01:59 cnxsoft has joined #linux-rockchip

02:30 lkcl has quit [Ping timeout: 258 seconds]

03:20 vagrantc has quit [Quit: leaving]

03:28 <stdint> phh, ping

03:35 xming has quit [Ping timeout: 240 seconds]

03:36 via has quit [Ping timeout: 256 seconds]

05:35 lkcl has joined #linux-rockchip

06:22 cnxsoft has quit [Remote host closed the connection]

06:49 cnxsoft has joined #linux-rockchip

07:04 xming has joined #linux-rockchip

07:04 xming has quit [Changing host]

07:15 cnxsoft has quit [Read error: Connection reset by peer]

07:16 cnxsoft has joined #linux-rockchip

07:29 <phh> ayaka stdint pong

07:29 <stdint> phh, I want to confirm some thing about drm with you

07:31 <stdint> phh, ok, nothing it suddenly work

07:32 <stdint> I don't know what is wrong with firefly, somethings it work

07:33 <stdint> I still got this https://paste.fedoraproject.org/528611/48463838/ at the morning

07:33 <stdint> but hdmi suddenly works

07:33 <phh> on 4.10-rc3?

07:34 <stdint> yes

07:34 <stdint> ok it doesn't work again

07:35 <phh> right, so c201 have blinking sdcard, firefly have blinking hdmi

07:35 <phh> it still needs some stabilisation :s

07:35 <stdint> phh, does the sdcard issue is fixed by the new patch

07:39 <phh> which one? I did try "soc: rockchip: power-domain: export idle request"

07:41 <phh> ( https://github.com/phhusson/linux/commit/4a63639f3a7c9fa5f1672f45730b9e8a92923590 for the actual diff)

07:44 <stdint> phh, [PATCH v5 1/2] mmc: dw_mmc: silent verbose log when calling from PM context

07:44 <stdint> phh, it is in the mail list

07:44 <phh> uh... this really helps sdcard randomly not booting?

07:44 <phh> it's not what the commit message says

07:49 <phh> I guess i also need [PATCH v5 2/2] mmc: dw_mmc: force setup bus if active slots exist

07:52 <stdint> sounds like CONFIG_DRM_FBDEV_EMULATION cause the problem

07:52 <stdint> phh, yes both of them

07:53 <phh> ok, i'll try that thanks

08:41 <rperier> mmind00: I have no informations about this otp_gpio on the firefly. As it conflicts with the pin for the headphone, what do you prefer ? pinmux headphone and disable tsadc locally or keep tsadc and don't pinmux headphone (it's working but I am not fan of this solution)

08:41 <rperier> hi btw :)

08:46 <rperier> I realized that it can conflicts at runtime with the pins of tsadc anyway... (init, default and sleep state) :/

08:50 libv_ has joined #linux-rockchip

08:52 libv has quit [Ping timeout: 255 seconds]

09:09 matthias_bgg has joined #linux-rockchip

09:33 <stdint> rperier, it looks like a bug anyway

09:33 <stdint> as the tsadc is configured as cru control mode

09:34 <stdint> that pin shouldn't be used for that as I said yesterday

09:45 libv has joined #linux-rockchip

09:47 libv_ has quit [Ping timeout: 240 seconds]

09:54 <mmind00> rperier: stdint is mostly correct it seems ... only veyron and the rk3288-evb seem to use this pin as otp indicator

09:55 <mmind00> rperier: so I guess, just move the otp pinctrl setting from rk3288.dtsi to the rk3288-evb.dtsi and rk3288-veyron.dtsi

09:58 <rperier> mhhh, ok. I will investigate. thanks

10:42 nighty has quit [Quit: Disappears in a puff of smoke]

11:11 libv has quit [Ping timeout: 240 seconds]

11:23 libv has joined #linux-rockchip

11:26 leah2 has quit [Ping timeout: 255 seconds]

11:30 libv_ has joined #linux-rockchip

11:31 libv has quit [Ping timeout: 240 seconds]

11:36 lkcl has quit [Ping timeout: 240 seconds]

11:42 leah2 has joined #linux-rockchip

11:53 lkcl has joined #linux-rockchip

11:55 wadim_ has joined #linux-rockchip

12:07 paulk-blaze has joined #linux-rockchip

12:11 libv has joined #linux-rockchip

12:14 libv_ has quit [Ping timeout: 240 seconds]

12:15 libv has quit [Ping timeout: 256 seconds]

12:21 libv has joined #linux-rockchip

12:31 paulk-blaze has quit [Remote host closed the connection]

12:33 paulk-blaze has joined #linux-rockchip

12:41 paulk-blaze has quit [Remote host closed the connection]

12:42 paulk-blaze has joined #linux-rockchip

12:46 ayaka has quit [Ping timeout: 240 seconds]

12:46 ayaka has joined #linux-rockchip

12:46 paulk-blaze has quit [Remote host closed the connection]

12:48 paulk-blaze has joined #linux-rockchip

12:55 nighty has joined #linux-rockchip

13:07 paulk-blaze has quit [Remote host closed the connection]

13:15 paulk-blaze has joined #linux-rockchip

13:19 libv_ has joined #linux-rockchip

13:22 libv has quit [Ping timeout: 240 seconds]

13:34 libv_ has quit [Ping timeout: 248 seconds]

13:37 sunxi_fan has quit [Ping timeout: 260 seconds]

13:45 libv has joined #linux-rockchip

13:46 hramrach has quit [Ping timeout: 248 seconds]

13:48 paulk-blaze has quit [Remote host closed the connection]

13:53 sunxi_fan has joined #linux-rockchip

13:54 hramrach has joined #linux-rockchip

14:00 paulk-blaze has joined #linux-rockchip

14:03 libv has quit [Ping timeout: 240 seconds]

14:03 cnxsoft has quit [Remote host closed the connection]

14:04 cnxsoft has joined #linux-rockchip

14:07 cnxsoft has quit [Remote host closed the connection]

14:10 paulk-blaze has quit [Remote host closed the connection]

14:21 libv has joined #linux-rockchip

14:23 paulk-blaze has joined #linux-rockchip

14:27 libv_ has joined #linux-rockchip

14:29 libv has quit [Ping timeout: 252 seconds]

14:33 libv_ has quit [Ping timeout: 240 seconds]

14:35 <ayaka> paulk-blaze, ping

14:36 <paulk-blaze> ayaka, pong

14:36 <ayaka> paulk-blaze, may I use the private message?

14:36 <paulk-blaze> ayaka, sure :)

14:37 Omegamoon has joined #linux-rockchip

14:44 libv has joined #linux-rockchip

15:11 mrjay has joined #linux-rockchip

15:16 libv has quit [Ping timeout: 258 seconds]

15:18 libv has joined #linux-rockchip

15:18 Myy has joined #linux-rockchip

15:23 matthias_bgg has quit [Ping timeout: 240 seconds]

15:32 JohnDoe_71Rus has joined #linux-rockchip

15:36 paulk-blaze has quit [Quit: Leaving]

15:36 matthias_bgg has joined #linux-rockchip

16:16 wadim_ has quit [Quit: Leaving.]

16:38 matthias_bgg has quit [Quit: Leaving]

16:59 paulk-collins has joined #linux-rockchip

17:18 vagrantc has joined #linux-rockchip

17:29 ayaka has quit [Quit: byte]

17:29 ayaka has joined #linux-rockchip

18:25 lkcl has quit [Ping timeout: 240 seconds]

18:34 lkcl has joined #linux-rockchip

18:45 mrjay has quit [Quit: Page closed]

19:06 Omegamoon has left #linux-rockchip [#linux-rockchip]

19:43 mrjay has joined #linux-rockchip

19:52 mrjay has quit [Quit: Page closed]

20:02 vagrantc has quit [Quit: leaving]

20:46 JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]

21:37 lkcl has quit [Ping timeout: 256 seconds]

22:14 <Myy> Are gbm_bo_(un)ref ARM Mali specific procedures ? It seems to be only defined in libmali gbm.h file

22:15 <phh> hello Myy :)

22:15 <Myy> Hello phh :)

22:16 <phh> Myy: I think you should rather try ARM's developer forums

22:17 <Myy> Yeah, I'll try to ask on the ARM Community. But they migrated to another forum software recently, and the activity went from low to very low

22:18 <Myy> I see that you also patched the MMC code in the 4.10. Do you have the noisy MMC warnings in the logs after the patch ?

22:18 <phh> right. fyi, this channel is more active in china timezone (i.e. morning in france)

22:18 <phh> well I applied the MMC patch in the hope to fix my random boot issue, but it doesn't work, and I see you have another patch for that

22:19 <Myy> Yeah. It works but the logs get spammed every minute.

22:20 <Myy> [ 9364.515382] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0)

22:20 <phh> have you looked at linux-rockchip mailing list?

22:20 <phh> there are two patches for that I think

22:20 <Myy> I don't know why it cannot get the remaining 2Mhz

22:21 <Myy> Ah, no. I only got this one https://patchwork.kernel.org/patch/9498527/ but I didn't know about the linux-rockchip LKML

22:22 <Myy> I might be missing that one I guess ? https://patchwork.kernel.org/patch/9494485/

22:22 <phh> http://lists.infradead.org/pipermail/linux-rockchip/2017-January/013621.html

22:23 <Myy> Oooh, interesting one

22:24 <phh> Myy: BTW, I need none of all the mali kernel patches you have

22:24 <phh> and I build mali module out of kernel tree

22:25 <Myy> Well, I used the r15p00 one which try to use get_user_pages_remote

22:25 <Myy> I also added the UMP driver "just in case" it was used somewhere

22:27 <Myy> They kind of work (FBDEV, DRM, Wayland works. X11 don't but I think I don't have the right xorg-server), but I'll try the OOT ones when I can.

22:28 <phh> right, github.com/rockchip-linux/ provides a xorg-server with a modified glamor to work on GLES

22:28 <phh> https://github.com/rockchip-linux/xserver even

22:30 <Myy> Yeah. That's the one I tried to compile and I got the dreaded "what is gbm_bo_ref" error from GCC.

22:30 <phh> ok

22:30 <phh> I cheat I use rockchip's prebuilt deb packages ;)

22:30 <Myy> I'll try to copy the mali headers

22:30 <Myy> Well I should too, but I'm trying to understand how everything pieces together

22:31 <Myy> However, I discovered way too late that Yocto was actually very Gentoo-like, with also a lot of ARM specific builds files.

22:31 <Myy> However, I'd like to know where they got these headers though... The SDK maybe ?

22:32 <phh> grmbl, https://patchwork.kernel.org/patch/9498527/ doesn't fix my mmc problem

22:33 <Myy> The problem I got was a hang-up and "hung task" after a few minutes, with ext4 code showing in the backtrace

22:33 <Myy> As reported here https://bugzilla.kernel.org/show_bug.cgi?id=192131

22:34 <phh> hum I have mostly the same thing. usually it's on partition scanning, so I did get it on ext4 once

22:36 <Myy> I remember finding this patch by actually searching the new scheduler symbols, as I thought that it was a new scheduler issue

22:38 <Myy> I'll try to find the LKML thread where I found this

22:40 <Myy> https://lkml.org/lkml/2017/1/9/381

22:41 <phh> right, I even have the same device as the guy :P

22:42 <Myy> And so, the supposed fix was https://lkml.org/lkml/2017/1/9/839

22:42 <phh> sounds like it's not a 100% fix then :s

22:43 <phh> I'll come back on that when I have fully working hw video decoding :P

22:44 <Myy> It seems that ayaka had the same problem as you http://lists.infradead.org/pipermail/linux-rockchip/2017-January/013639.html

22:45 <phh> well he was answering on the log patch

22:47 <Myy> Ah ! I thought it was the boot problem. However, did you try to only apply one part of the patch ?

23:01 paulk-collins has quit [Remote host closed the connection]

23:06 <Myy> No more MMC spamming... Yay...

23:07 <Myy> Still, I think that this log muting patch is hiding a real configuration problem.

23:13 nighty has quit [Quit: Disappears in a puff of smoke]

23:23 <Myy> Okay, so that's it for today. My slight rework of the the second MMC mute patch is here : https://gitlab.com/snippets/35594 . The first is here : https://github.com/Miouyouyou/MyyQi/blob/master/patches/kernel/v4.10-rc4/0004-mmc-Applied-Ziyuan-Xu-dw_mmc-patch.patch . You can try to play with them, apply just one of them, apply both or none and see if it changes anything.

23:24 <Myy> That said, I'm off !

23:24 <Myy> See you everyone !

23:24 Myy has quit [Quit: Leaving]