Re: [PATCH 1/4 v3] drm: Add support of ARC PGU display controller

[Alexey Brodkin]

Hi Daniel,

On Tue, 2016-03-15 at 09:10 +-0100, Daniel Vetter wrote:
+AD4- On Mon, Mar 14, 2016 at 11:15:59AM +-0000, Alexey Brodkin wrote:
+AD4- +AD4- 
+AD4- +AD4- On Mon, 2016-03-14 at 08:00 +-0100, Daniel Vetter wrote:
+AD4- +AD4- +AD4- 
+AD4- +AD4- +AD4- On Fri, Mar 11, 2016 at 06:42:36PM +-0300, Alexey Brodkin wrote:
+AD4- +AD4- +AD4- +AD4- 
+AD4- +AD4- +AD4- +AD4- +-static int arcpgu+AF8-atomic+AF8-commit(struct drm+AF8-device +ACo-dev,
+AD4- +AD4- +AD4- +AD4- +-				+AKAAoACgAKA-struct drm+AF8-atomic+AF8-state +ACo-state, bool async)
+AD4- +AD4- +AD4- +AD4- +-+AHs-
+AD4- +AD4- +AD4- +AD4- +-	return drm+AF8-atomic+AF8-helper+AF8-commit(dev, state, false)+ADs-
+AD4- +AD4- +AD4- Note that this isn't really async if you ever get around to implement
+AD4- +AD4- +AD4- fence support or vblank support. Just fyi.
+AD4- +AD4- Ok but for now should I leave it as it is?
+AD4- Yeah ok as-is, hence just fyi.

Thanks. Just wanted to make sure we're on the same page :)

+AD4- +AD4- 
+AD4- +AD4- +AD4- 
+AD4- +AD4- +AD4- +AD4- 
+AD4- +AD4- +AD4- +AD4- +-static struct drm+AF8-driver arcpgu+AF8-drm+AF8-driver +AD0- +AHs-
+AD4- +AD4- +AD4- +AD4- +-	.driver+AF8-features +AD0- DRIVER+AF8-MODESET +AHw- DRIVER+AF8-GEM +AHw- DRIVER+AF8-PRIME +AHw-
+AD4- +AD4- +AD4- +AD4- +-			+AKAAoACg-DRIVER+AF8-ATOMIC,
+AD4- +AD4- +AD4- +AD4- +-	.preclose +AD0- arcpgu+AF8-preclose,
+AD4- +AD4- +AD4- +AD4- +-	.lastclose +AD0- arcpgu+AF8-lastclose,
+AD4- +AD4- +AD4- +AD4- +-	.name +AD0- +ACI-drm-arcpgu+ACI-,
+AD4- +AD4- +AD4- +AD4- +-	.desc +AD0- +ACI-ARC PGU Controller+ACI-,
+AD4- +AD4- +AD4- +AD4- +-	.date +AD0- +ACI-20160219+ACI-,
+AD4- +AD4- +AD4- +AD4- +-	.major +AD0- 1,
+AD4- +AD4- +AD4- +AD4- +-	.minor +AD0- 0,
+AD4- +AD4- +AD4- +AD4- +-	.patchlevel +AD0- 0,
+AD4- +AD4- +AD4- +AD4- +-	.fops +AD0- +ACY-arcpgu+AF8-drm+AF8-ops,
+AD4- +AD4- +AD4- +AD4- +-	.load +AD0- arcpgu+AF8-load,
+AD4- +AD4- +AD4- +AD4- +-	.unload +AD0- arcpgu+AF8-unload,
+AD4- +AD4- +AD4- Load and unload hooks are deprecated (it's a classic midlayer mistake).
+AD4- +AD4- +AD4- Please use drm+AF8-dev+AF8-alloc/register pairs directly instead, and put your
+AD4- +AD4- +AD4- device setup code in-between. Similar for unloading. There's a bunch of
+AD4- +AD4- +AD4- example drivers converted already.
+AD4- +AD4- Ok I took +ACI-atmel-hlcdc+ACI- as example.
+AD4- +AD4- And that's interesting.
+AD4- +AD4- 
+AD4- +AD4- If I put my+AKA-arcpgu+AF8-load() in between+AKA-drm+AF8-dev+AF8-alloc() and
+AD4- +AD4- drm+AF8-dev+AF8-register() then I'm getting this on the driver probe:
+AD4- +AD4- ----------------------------------+AD4-8-------------------------------
+AD4- +AD4- +AFs-drm+AF0- Initialized drm 1.1.0 20060810
+AD4- +AD4- arcpgu e0017000.pgu: arc+AF8-pgu ID: 0xabbabaab
+AD4- +AD4- ------------+AFs- cut here +AF0-------------
+AD4- +AD4- WARNING: CPU: 0 PID: 1 at lib/kobject.c:244 kobject+AF8-add+AF8-internal+-0x17c/0x498()
+AD4- +AD4- kobject+AF8-add+AF8-internal failed for card0-HDMI-A-1 (error: -2 parent: card0)
+AD4- +AD4- Modules linked in:
+AD4- +AD4- CPU: 0 PID: 1 Comm: swapper Not tainted 4.5.0-rc3-01062-ga447822-dirty +ACM-17
+AD4- +AD4- 
+AD4- +AD4- Stack Trace:
+AD4- +AD4- +AKA- arc+AF8-unwind+AF8-core.constprop.1+-0xa4/0x110
+AD4- +AD4- +AKA- warn+AF8-slowpath+AF8-fmt+-0x6e/0xfc
+AD4- +AD4- +AKA- kobject+AF8-add+AF8-internal+-0x17c/0x498
+AD4- +AD4- +AKA- kobject+AF8-add+-0x98/0xe4
+AD4- +AD4- +AKA- device+AF8-add+-0xc6/0x734
+AD4- +AD4- +AKA- device+AF8-create+AF8-with+AF8-groups+-0x12a/0x144
+AD4- +AD4- +AKA- drm+AF8-sysfs+AF8-connector+AF8-add+-0x54/0xe8
+AD4- +AD4- +AKA- arcpgu+AF8-drm+AF8-hdmi+AF8-init+-0xd4/0x17c
+AD4- +AD4- +AKA- arcpgu+AF8-probe+-0x138/0x24c
+AD4- +AD4- +AKA- platform+AF8-drv+AF8-probe+-0x2e/0x6c
+AD4- +AD4- +AKA- really+AF8-probe+-0x212/0x35c
+AD4- +AD4- +AKA- +AF8AXw-driver+AF8-attach+-0x90/0x94
+AD4- +AD4- +AKA- bus+AF8-for+AF8-each+AF8-dev+-0x46/0x80
+AD4- +AD4- +AKA- bus+AF8-add+AF8-driver+-0x14e/0x1b4
+AD4- +AD4- +AKA- driver+AF8-register+-0x64/0x108
+AD4- +AD4- +AKA- do+AF8-one+AF8-initcall+-0x86/0x194
+AD4- +AD4- +AKA- kernel+AF8-init+AF8-freeable+-0xf0/0x188
+AD4- +AD4- ---+AFs- end trace c67166ad43ddcce2 +AF0----
+AD4- +AD4- +AFs-drm:drm+AF8-sysfs+AF8-connector+AF8-add+AF0- adding +ACI-HDMI-A-1+ACI- to sysfs
+AD4- +AD4- +AFs-drm:drm+AF8-sysfs+AF8-connector+AF8-add+AF0- +ACo-ERROR+ACo- failed to register connector device: -2
+AD4- +AD4- arcpgu e0017000.pgu: failed to regiter DRM connector and helper funcs
+AD4- +AD4- arcpgu: probe of e0017000.pgu failed with error -2
+AD4- +AD4- ----------------------------------+AD4-8-------------------------------
+AD4- +AD4- 
+AD4- +AD4- But if I move arcpgu+AF8-load() after drm+AF8-dev+AF8-register() then everything
+AD4- +AD4- starts properly and I may see HDMI screen works perfectly fine.
+AD4- +AD4- 
+AD4- +AD4- Any thoughts?
+AD4- Oops, yeah missed that detail. If you look at atmel it has a loop to
+AD4- register all the drm connectors +AF8-after+AF8- calling drm+AF8-dev+AF8-register().
+AD4- Totally forgot about that. Can you pls
+AD4- - Extract a new drm+AF8-connector+AF8-register+AF8-all() function
+AD4- +AKA- (atmel+AF8-hlcdc+AF8-dc+AF8-connector+AF8-plug+AF8-all seems to be the best template),
+AD4- +AKA- including kerneldoc.
+AD4- - Adjust kerneldoc of drm+AF8-dev+AF8-register() to mention
+AD4- +AKA- drm+AF8-connector+AF8-register+AF8-all() and that ordering constraint.
+AD4- - Roll that helper out to all the drivers that currently hand-roll it (one
+AD4- +AKA- patch per driver).
+AD4- 
+AD4- I know a bit of work but imo not too much, and by doing some small
+AD4- refactoring every time someone stumbles over a drm pitfall we keep the
+AD4- subsystem clean+ACY-easy to understand. You're up for this? Would be a prep
+AD4- series, I'll happily review it to get it merged fast. Just a few weeks ago
+AD4- I merged 20+- patches to make -+AD4-mode+AF8-fixup hooks optional and remove dummy
+AD4- ones all over the subsystem, in other words: You'll have my full attention
+AD4- +ADs--)

Sure, I'm ready to pay that price :)
Stay tuned and patches will follow.

+AD4- +AD4- 
+AD4- +AD4- +AD4- 
+AD4- +AD4- +AD4- +AD4- 
+AD4- +AD4- +AD4- +AD4- +-	.dumb+AF8-create +AD0- drm+AF8-gem+AF8-cma+AF8-dumb+AF8-create,
+AD4- +AD4- +AD4- +AD4- +-	.dumb+AF8-map+AF8-offset +AD0- drm+AF8-gem+AF8-cma+AF8-dumb+AF8-map+AF8-offset,
+AD4- +AD4- +AD4- +AD4- +-	.dumb+AF8-destroy +AD0- drm+AF8-gem+AF8-dumb+AF8-destroy,
+AD4- +AD4- +AD4- +AD4- +-	.get+AF8-vblank+AF8-counter +AD0- drm+AF8-vblank+AF8-no+AF8-hw+AF8-counter,
+AD4- +AD4- +AD4- +AD4- +-	.prime+AF8-handle+AF8-to+AF8-fd +AD0- drm+AF8-gem+AF8-prime+AF8-handle+AF8-to+AF8-fd,
+AD4- +AD4- +AD4- +AD4- +-	.prime+AF8-fd+AF8-to+AF8-handle +AD0- drm+AF8-gem+AF8-prime+AF8-fd+AF8-to+AF8-handle,
+AD4- +AD4- +AD4- +AD4- +-	.gem+AF8-free+AF8-object +AD0- drm+AF8-gem+AF8-cma+AF8-free+AF8-object,
+AD4- +AD4- +AD4- +AD4- +-	.gem+AF8-vm+AF8-ops +AD0- +ACY-drm+AF8-gem+AF8-cma+AF8-vm+AF8-ops,
+AD4- +AD4- +AD4- +AD4- +-	.gem+AF8-prime+AF8-export +AD0- drm+AF8-gem+AF8-prime+AF8-export,
+AD4- +AD4- +AD4- +AD4- +-	.gem+AF8-prime+AF8-import +AD0- drm+AF8-gem+AF8-prime+AF8-import,
+AD4- +AD4- +AD4- +AD4- +-	.gem+AF8-prime+AF8-get+AF8-sg+AF8-table +AD0- drm+AF8-gem+AF8-cma+AF8-prime+AF8-get+AF8-sg+AF8-table,
+AD4- +AD4- +AD4- +AD4- +-	.gem+AF8-prime+AF8-import+AF8-sg+AF8-table +AD0- drm+AF8-gem+AF8-cma+AF8-prime+AF8-import+AF8-sg+AF8-table,
+AD4- +AD4- +AD4- +AD4- +-	.gem+AF8-prime+AF8-vmap +AD0- drm+AF8-gem+AF8-cma+AF8-prime+AF8-vmap,
+AD4- +AD4- +AD4- +AD4- +-	.gem+AF8-prime+AF8-vunmap +AD0- drm+AF8-gem+AF8-cma+AF8-prime+AF8-vunmap,
+AD4- +AD4- +AD4- +AD4- +-	.gem+AF8-prime+AF8-mmap +AD0- drm+AF8-gem+AF8-cma+AF8-prime+AF8-mmap,
+AD4- +AD4- +AD4- +AD4- +-+AH0AOw-
+AD4- +AD4- +AD4- +AD4- +-
+AD4- +AD4- +AD4- +AD4- +-static int arcpgu+AF8-probe(struct platform+AF8-device +ACo-pdev)
+AD4- +AD4- +AD4- +AD4- +-+AHs-
+AD4- +AD4- +AD4- +AD4- +-	return drm+AF8-platform+AF8-init(+ACY-arcpgu+AF8-drm+AF8-driver, pdev)+ADs-
+AD4- +AD4- +AD4- ... or read the kerneldoc of this function, which also explains what you
+AD4- +AD4- +AD4- should do +ADs--)
+AD4- +AD4- Could you please point me to the relevant document?
+AD4- +AD4- I wasn't able to find anything related from the first glance :(
+AD4- The kerneldoc comment for drm+AF8-platform+AF8-init says it's deprecated, please
+AD4- use drm+AF8-dev+AF8-alloc/register instead.

Yeah I saw this. I was a bit confused with word +ACI-kerneldoc+ACI- thinking about
.txt files in Documentation folder.

+AD4- +AD4- 
+AD4- +AD4- +AD4- 
+AD4- +AD4- +AD4- +AD4- 
+AD4- +AD4- +AD4- +AD4- +-
+AD4- +AD4- +AD4- +AD4- +-/+ACo-
+AD4- +AD4- +AD4- +AD4- +- +ACo- This function is the only reason to have a copy of drm+AF8-fbdev+AF8-cma+AF8-init()
+AD4- +AD4- +AD4- +AD4- +- +ACo- here in this driver.
+AD4- +AD4- +AD4- +AD4- +- +ACo-
+AD4- +AD4- +AD4- +AD4- +- +ACo- In its turn this mmap() is required to mark user-space page as non-cached
+AD4- +AD4- +AD4- +AD4- +- +ACo- because it is just a mirror or real hardware frame-buffer.
+AD4- +AD4- +AD4- +AD4- +- +ACo-/
+AD4- +AD4- +AD4- +AD4- +-static int arcpgu+AF8-mmap(struct fb+AF8-info +ACo-info, struct vm+AF8-area+AF8-struct +ACo-vma)
+AD4- +AD4- +AD4- +AD4- +-+AHs-
+AD4- +AD4- +AD4- +AD4- +-	vma-+AD4-vm+AF8-page+AF8-prot +AD0- pgprot+AF8-noncached(vma-+AD4-vm+AF8-page+AF8-prot)+ADs-
+AD4- +AD4- +AD4- +AD4- +-	return vm+AF8-iomap+AF8-memory(vma, info-+AD4-fix.smem+AF8-start, info-+AD4-fix.smem+AF8-len)+ADs-
+AD4- +AD4- +AD4- +AD4- +-+AH0-
+AD4- +AD4- +AD4- This looks very fishy, no other drm driver even bothers with providing an
+AD4- +AD4- +AD4- fb+AF8-mmap hook. What exactly do you need this for? Assuming you've mmapped
+AD4- +AD4- +AD4- your fbcon drm+AF8-framebuffer correctly for kernel access things should just
+AD4- +AD4- +AD4- work ...
+AD4- +AD4- Indeed for kernel there's non need to that hack. Kernel deals directly with HW
+AD4- +AD4- frame-buffer area (that address we get from gem-+AD4-paddr). And so every byte written gets
+AD4- +AD4- picked up by PGU and is then rendered on the display.
+AD4- +AD4- 
+AD4- +AD4- But when user-space opens /dev/fb0 and mmaps() it deals with memory pages which
+AD4- +AD4- are by default (at least on ARC) marked as +ACI-cached+ACI-. I.e. user-space application
+AD4- +AD4- (I use that nice demo app+AKA-https://github.com/qtproject/qt/blob/4.8/examples/qws/framebuffer/main.c)
+AD4- +AD4- deals with frame-buffer via data cache. And that has 2 problems:
+AD4- +AD4- +AKAAWw-1+AF0- Since no explicit cache flush gets executed some data is left in data cache,
+AD4- +AD4- +AKA- +AKA- +AKA-i.e. some parts of the picture never reaches real PGU.
+AD4- +AD4- +AKA- +AKA- +AKA-See what happens on display -+AKA-http://imgur.com/iAbnnx3
+AD4- +AD4- +AKA- +AKA- +AKA-Those missing lines are exactly those 32-byte missing cache lines.
+AD4- +AD4- +AKAAWw-2+AF0- Even if we manage to flush data somehow massive amount of data that goes
+AD4- +AD4- +AKA- +AKA- +AKA-through data cache (let's sat 1080p+AEA-30Hz) will thrash it and as a result
+AD4- +AD4- +AKA- +AKA- +AKA-there will be no benefit for other cache users to use cache.
+AD4- +AD4- 
+AD4- +AD4- So we fix it simply marking pages mapped to user-space apps as uncached
+AD4- +AD4- that effectively routes all FB data directly to memry instead of polluting cache.
+AD4- +AD4- 
+AD4- +AD4- Hopefully that explanation makes sense.
+AD4- Still strange that you're the only one who needs this. I think best case
+AD4- would be to provide some mmap helpers for fbdev which remap to dumb buffer
+AD4- helpers or something similar. That way other drivers don't need to.

Ok I took another look and now see what's missing.
All other arches implement their own+AKA-fb+AF8-pgprotect() in arch/X/include/asm/fb.h
which does exactly what I need. So entire arcpgu+AF8-fbdev.c will be dumped in v4 :)

-Alexey