#linux-exynos on 2019-01-31 — irc logs at freenode.irclog.whitequark.org

2014-05-14 17:51 Wizzup changed the topic of #linux-exynos to: This channel is logged: http://irclog.whitequark.org/linux-exynos | http://linux-exynos.org | http://lists.linux-exynos.org/listinfo/linux-exynos | https://github.com/linux-exynos

00:24 ahajda has joined #linux-exynos

00:25 snawrocki has joined #linux-exynos

00:28 ahajda has quit [Ping timeout: 252 seconds]

00:30 snawrocki has quit [Ping timeout: 245 seconds]

02:13 snawrocki has joined #linux-exynos

02:15 ahajda has joined #linux-exynos

02:22 ahajda1 has joined #linux-exynos

02:24 ahajda has quit [Ping timeout: 252 seconds]

02:27 ahajda1 has quit [Ping timeout: 252 seconds]

02:27 snawrocki has quit [Ping timeout: 245 seconds]

02:39 genii has quit [Remote host closed the connection]

02:51 snawrocki has joined #linux-exynos

02:55 ahajda has joined #linux-exynos

03:09 ahajda1 has joined #linux-exynos

03:12 ahajda has quit [Ping timeout: 252 seconds]

03:17 snawrocki has quit [Ping timeout: 250 seconds]

03:18 ahajda1 has quit [Ping timeout: 252 seconds]

05:05 ahajda has joined #linux-exynos

05:10 snawrocki has joined #linux-exynos

05:17 ahajda has quit [Ping timeout: 252 seconds]

05:20 snawrocki has quit [Ping timeout: 250 seconds]

05:28 snawrocki has joined #linux-exynos

05:28 ahajda has joined #linux-exynos

05:47 ahajda1 has joined #linux-exynos

05:49 ahajda has quit [Ping timeout: 252 seconds]

06:00 snawrocki has quit [Ping timeout: 245 seconds]

06:01 ahajda1 has quit [Ping timeout: 252 seconds]

06:12 snawrocki has joined #linux-exynos

06:13 ahajda has joined #linux-exynos

06:21 ahajda has quit [Ping timeout: 252 seconds]

06:21 snawrocki has quit [Ping timeout: 250 seconds]

06:28 ahajda has joined #linux-exynos

06:34 ahajda has quit [Ping timeout: 252 seconds]

06:51 snawrocki has joined #linux-exynos

06:51 ahajda has joined #linux-exynos

06:56 ahajda has quit [Ping timeout: 252 seconds]

06:57 snawrocki has quit [Ping timeout: 245 seconds]

07:06 mszyprow has joined #linux-exynos

07:07 snawrocki has joined #linux-exynos

07:09 mszyprow_ has joined #linux-exynos

07:10 ahajda has joined #linux-exynos

07:13 mszyprow has quit [Ping timeout: 250 seconds]

07:15 mszyprow_ has quit [Ping timeout: 250 seconds]

07:18 snawrocki has quit [Ping timeout: 245 seconds]

07:19 ahajda has quit [Ping timeout: 252 seconds]

07:33 mszyprow has joined #linux-exynos

07:34 ahajda has joined #linux-exynos

07:37 ahajda1 has joined #linux-exynos

07:38 ahajda has quit [Ping timeout: 252 seconds]

07:39 mszyprow has quit [Ping timeout: 250 seconds]

07:40 mszyprow has joined #linux-exynos

07:41 ahajda has joined #linux-exynos

07:42 ahajda1 has quit [Ping timeout: 252 seconds]

07:45 snawrocki has joined #linux-exynos

08:37 <memeka> mszyprow: Ping

08:44 <memeka> mszyprow: I guess you can ignore my email

08:44 <mszyprow> memeka: pong

08:44 <memeka> mszyprow: looking at the last patch you sent me I think it kind of does exactly that

08:44 <memeka> The layout sync update

08:45 <mszyprow> memeka: that layout sync update described in the datasheet seems to be noop

08:45 <memeka> Minus setting the gsc regs

08:45 <memeka> Which I guess is needed just when gsc is in local output mode

08:45 <mszyprow> memeka: and playing with gsc regs has no relation too

08:46 <mszyprow> memeka: I have example code to trigger those bugs without touching gsc

08:46 <memeka> mszyprow: why use 8 bit burst instead of 16?

08:47 <mszyprow> memeka: as there are at least 2 separate issues there (proper buffer switch on vsync and access to bytes after buffer the configured buffer)

08:47 <mszyprow> memeka: just random idea I've tried

08:47 <mszyprow> memeka: it didn't change much

08:48 <memeka> I will try removing the h-2 from there too

08:48 <memeka> I think just the layer sync thing actually made the diff

08:52 <memeka> mszyprow: is it not possible to disable mixer1?

08:53 <memeka> Just leave mixer0 ... would that fix the issue? :)

08:53 <mszyprow> mixer1 is disabled by default...

08:56 <memeka> Hm

09:29 <memeka> mszyprow: is it possible to call gsc from mixer via ipp?

09:29 <mszyprow> memeka: in the current code? rather not

09:33 <memeka> mszyprow: I was thinking: drm falsely advertises nv12 on graphics0, and in mixer if format = nv12 then send it for gsc, and continue after getting result back

09:35 <memeka> Would that work? Would the delay be an issue?

09:36 <memeka> Also, mszyprow - who really uses ipp? Why all that effort in doing an alternative to v4

09:36 <memeka> To v4l2?

09:45 <mszyprow> memeka: some time ago I've did a p-o-c of using ipp transparently for displaying plane with unsupported fourcc/transformation

09:46 <memeka> mszyprow: that’s a feat that I would like to see repeated :))

09:46 <mszyprow> memeka: let me find the link...

09:47 <mszyprow> memeka: https://www.spinics.net/lists/dri-devel/msg95345.html

09:49 <mszyprow> memeka: this one is the core patch for this feature: https://www.spinics.net/lists/dri-devel/msg95362.html

09:49 <mszyprow> memeka: one would need to adapt it to current drm code

09:50 <mszyprow> memeka: ipp v2 is quite easy to be called from inside exynos drm

09:51 <mszyprow> memeka: and it is state-less, what make things even easier to handle

09:51 <memeka> mszyprow: isn’t ipp2 already in mainline?

09:51 nighty- has joined #linux-exynos

09:52 <mszyprow> memeka: yes, it is

09:52 <memeka> Wouldn’t I just need patch 22 adapted to ippv2 and current drm?

09:52 <mszyprow> memeka: all you need to make it working is to adapt that patch #22 to the current code base

09:52 <mszyprow> and fix bugs ;)

09:52 <memeka> mszyprow: thx I will try!

09:56 <memeka> mszyprow: in 5.0, is gsc ipp still OR gsc v4l2?

09:56 <mszyprow> afair yes

09:56 <mszyprow> but it shouldn't be hard to share one for v4l2 and one for drm

09:59 <memeka> mszyprow: also, would that plane be visible from modetest? Patch 22 doesn’t touch the mixer - is this all happening before the mixer?

10:00 <mszyprow> memeka: it adds transparent ipp usage for all planes

10:00 <mszyprow> memeka: directly in the exynos drm core

10:00 <memeka> Where all planes = one plane :)

10:01 <memeka> Or 2, if combine with the other patch to enable graphics1 :)

10:01 <mszyprow> memeka: you can use whichever plane you want for nv12

10:08 <memeka> mszyprow: btw https://imgur.com/a/CTSJPQ6

10:44 <memeka> mszyprow: looks like it's quite some work to convert that to ippv2 :P

10:44 <mszyprow> memeka: it shouldn't be that hard, a matter of renaming a few structures and rewritting ipp glue

10:47 <memeka> yes rewriting ipp glue when you're looking at ipp for the first time :P

10:49 <mszyprow> memeka: you need to fill exynos_drm_ipp_task structure and call exynos_drm_ipp_schedule_task() ;P

10:53 <memeka> mszyprow: i was looking at exynos_ipp_process_internal being the hardest to rewrite :P

11:29 <mszyprow> memeka: btw, on xu4 you can use m2m scaler for ippv2 and gsc for v4l2

11:30 <memeka> mszyprow: can the scaler convert from nv12 to rgba? :P

11:36 <mszyprow> memeka: yep

11:37 <mszyprow> memeka: it even has more relaxed requirements than gsc

11:37 <mszyprow> memeka: for buffer width/height

11:37 <memeka> mszyprow: cool so then i don't need to do anything, i will just leave the gsc drm disabled (and leave the gsc v4l2 on)

11:44 <memeka> mszyprow: is ipp using dmabuf? would it be zero-copy?

11:44 <mszyprow> memeka: ipp2 uses drm gems

11:45 <mszyprow> memeka: and you can inport dma buf as drm gem

11:46 <memeka> but i can't send dmabuf to the plane, can i?

11:46 <memeka> unless i do a drmprime thing?

12:07 <memeka> mszyprow: do you think it will be faster than using mali?

12:08 <memeka> i just got a mali binary with drmbuf_import :D

14:36 genii has joined #linux-exynos

14:54 afaerber has joined #linux-exynos

15:58 mszyprow has quit [Ping timeout: 250 seconds]

16:45 nighty- has quit [Remote host closed the connection]

16:49 LiquidAcid has joined #linux-exynos

19:40 LiquidAcid has quit [Quit: Leaving]

20:05 afaerber has quit [Quit: Leaving]

20:17 mszyprow|home has joined #linux-exynos

20:27 jackmitchell has quit [Remote host closed the connection]

20:28 jackmitchell has joined #linux-exynos

21:26 mszyprow^home has joined #linux-exynos

21:29 mszyprow|home has quit [Ping timeout: 272 seconds]

22:18 <memeka> mszyprow^home: ping

22:18 <mszyprow^home> memeka: pong

22:19 <memeka> mszyprow^home: interesting that the layer_sync explanation I could find on 5250 manual but not on 5420

22:19 <mszyprow^home> memeka: true

22:20 <mszyprow^home> memeka: although that explanation doesn't help much fixing the issue

22:20 jackmitchell has quit [Ping timeout: 246 seconds]

22:20 <memeka> mszyprow^home: after your last patch, do you still get crashes with your tests?

22:21 <mszyprow^home> memeka: with height-2 and irq workarounds i don't get crash

22:22 <mszyprow^home> memeka: but I get only swap display buffer at 30fps instead of 60fps

22:22 <memeka> mszyprow^home: how about irq workarounds but keep h?

22:22 <mszyprow^home> iommu fault sooner or later

22:22 <mszyprow^home> usually when nothing happens

22:23 <mszyprow^home> i mean no buffers are swapped

22:23 <mszyprow^home> i can send you tomorrow a simple test app to trigger both issues if you are interested

22:23 <memeka> mszyprow^home: can’t you find someone at Samsung that knows more about this? :)

22:24 <mszyprow^home> well, its not that easy...

22:25 <memeka> mszyprow^home: to tell you the truth, after getting a mali blob with dmabuf import, I can do this with mali

22:25 <memeka> Conversions, rotations etc

22:25 <mszyprow^home> right

22:25 <memeka> But it still bugs me just because it’s a bug :)

22:26 <memeka> But in terms of capability, I can do what I need so the house is not in fire anymore :)

22:27 <mszyprow^home> well, i will try to keep it near the top on todo list anyway

22:27 <mszyprow^home> as it is somehow interesting to finally find how this hardware is really working

22:29 <memeka> mszyprow^home: btw I saw that comment about the DP on xu3 needing a hardware fix..?

22:29 <memeka> Why?

22:30 <mszyprow^home> memeka: it needs a fix if you want to use it with dp-> hdmi converter

22:30 <mszyprow^home> memeka: the problem is with 3,3v line on dp port

22:31 <memeka> got it

22:32 <mszyprow^home> memeka: is it provided by 2,4v regulator with too low power capacity

22:32 <mszyprow^home> it should work if you connect real dp monitor

22:33 <memeka> yup

22:33 <mszyprow^home> assuming it will not use that line to supply power to edid logic

22:33 <mszyprow^home> as it is definitely too low to get it working properly

22:33 <mszyprow^home> it is a know hardware bug

22:34 <mszyprow^home> i got an idea to steal some power from usb port with 5v->3.3V converter and wire it to dp port

22:34 <mszyprow^home> but i never had time to solder it

22:35 <memeka> mszyprow^home: I saw HK puts the modeline in the dtb

22:35 <memeka> So I guess there’s no edid logic?

22:36 <memeka> There was a howto: find your monitors modeling and compile dtb

22:36 <memeka> -modeline-

22:36 <mszyprow^home> frankly i have no idea why hk forces that edid mess into kernel/dtb/whatever

22:37 <memeka> For DP? Dunno

22:37 <mszyprow^home> reading edid works just fine with my setup

22:37 <mszyprow^home> at least for hdmi

22:37 <mszyprow^home> even with hdmi->dvi converters

22:37 <memeka> For hdmi... there were many complaints about monitor x and y

22:37 <memeka> That didn’t work

22:37 <mszyprow^home> for dp case - no idea really

22:38 <memeka> So they force some edids :)

22:38 <mszyprow^home> maybe they connected some weird panels

22:38 <memeka> It was not theirs, it was clients

22:38 <mszyprow^home> or maybe due to lack of power reading edid failed

22:38 <memeka> They got some modeline from some ppl, added them to the driver, then another then another :)

22:39 <memeka> mszyprow^home: I myself have some weird panel :)

22:39 <mszyprow^home> all this can be handled in userspace

22:39 <memeka> It’s a 5” 1080p touchscreen lcd

22:39 <mszyprow^home> drm framework supports injecting edid

22:39 <memeka> On hdmi with power from USB (and touch too)

22:40 <memeka> Pretty nice, but the modelines are crazy

22:40 <memeka> Pixel clocks are all non standard :)

22:41 <memeka> mszyprow^home: that’s exactly what they do

22:41 <memeka> It’s 2 things really

22:42 <memeka> 1. Add more pixel clocks

22:42 <memeka> 2. Bundle some edids and use drm to inject them

22:42 <memeka> So there is nothing I see funky here

22:44 <memeka> mszyprow^home: I gathered everything in 1 commit: https://github.com/mihailescu2m/linux/commit/4994bd68d7c9b1469a429a9d1d3e4612d6ed5744

22:44 <mszyprow^home> well, right, but i would still like to handle this mess fully in userspace without the need to add anything to the kernel

22:44 <mszyprow^home> anyway, /me needs to go to bed now...

22:45 <memeka> mszyprow^home: oki gnite and thx

22:50 mszyprow^home has quit [Ping timeout: 245 seconds]