diff for duplicates of <1458055486.4174.16.camel@synopsys.com> diff --git a/a/1.txt b/N1/1.txt index c824779..0968b25 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,14 +1,14 @@ Hi Daniel, -On Tue, 2016-03-15@09:10 +0100, Daniel Vetter wrote: -> On Mon, Mar 14, 2016@11:15:59AM +0000, Alexey Brodkin wrote: +On Tue, 2016-03-15 at 09:10 +0100, Daniel Vetter wrote: +> On Mon, Mar 14, 2016 at 11:15:59AM +0000, Alexey Brodkin wrote: > > -> > On Mon, 2016-03-14@08:00 +0100, Daniel Vetter wrote: +> > On Mon, 2016-03-14 at 08:00 +0100, Daniel Vetter wrote: > > > -> > > On Fri, Mar 11, 2016@06:42:36PM +0300, Alexey Brodkin wrote: +> > > On Fri, Mar 11, 2016 at 06:42:36PM +0300, Alexey Brodkin wrote: > > > > > > > > +static int arcpgu_atomic_commit(struct drm_device *dev, -> > > > + ????struct drm_atomic_state *state, bool async) +> > > > + struct drm_atomic_state *state, bool async) > > > > +{ > > > > + return drm_atomic_helper_commit(dev, state, false); > > > Note that this isn't really async if you ever get around to implement @@ -23,7 +23,7 @@ Thanks. Just wanted to make sure we're on the same page :) > > > > > > > > +static struct drm_driver arcpgu_drm_driver = { > > > > + .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME | -> > > > + ???DRIVER_ATOMIC, +> > > > + DRIVER_ATOMIC, > > > > + .preclose = arcpgu_preclose, > > > > + .lastclose = arcpgu_lastclose, > > > > + .name = "drm-arcpgu", @@ -42,7 +42,7 @@ Thanks. Just wanted to make sure we're on the same page :) > > Ok I took "atmel-hlcdc" as example. > > And that's interesting. > > -> > If I put my?arcpgu_load() in between?drm_dev_alloc() and +> > If I put my arcpgu_load() in between drm_dev_alloc() and > > drm_dev_register() then I'm getting this on the driver probe: > > ---------------------------------->8------------------------------- > > [drm] Initialized drm 1.1.0 20060810 @@ -54,23 +54,23 @@ Thanks. Just wanted to make sure we're on the same page :) > > CPU: 0 PID: 1 Comm: swapper Not tainted 4.5.0-rc3-01062-ga447822-dirty #17 > > > > Stack Trace: -> > ? arc_unwind_core.constprop.1+0xa4/0x110 -> > ? warn_slowpath_fmt+0x6e/0xfc -> > ? kobject_add_internal+0x17c/0x498 -> > ? kobject_add+0x98/0xe4 -> > ? device_add+0xc6/0x734 -> > ? device_create_with_groups+0x12a/0x144 -> > ? drm_sysfs_connector_add+0x54/0xe8 -> > ? arcpgu_drm_hdmi_init+0xd4/0x17c -> > ? arcpgu_probe+0x138/0x24c -> > ? platform_drv_probe+0x2e/0x6c -> > ? really_probe+0x212/0x35c -> > ? __driver_attach+0x90/0x94 -> > ? bus_for_each_dev+0x46/0x80 -> > ? bus_add_driver+0x14e/0x1b4 -> > ? driver_register+0x64/0x108 -> > ? do_one_initcall+0x86/0x194 -> > ? kernel_init_freeable+0xf0/0x188 +> > arc_unwind_core.constprop.1+0xa4/0x110 +> > warn_slowpath_fmt+0x6e/0xfc +> > kobject_add_internal+0x17c/0x498 +> > kobject_add+0x98/0xe4 +> > device_add+0xc6/0x734 +> > device_create_with_groups+0x12a/0x144 +> > drm_sysfs_connector_add+0x54/0xe8 +> > arcpgu_drm_hdmi_init+0xd4/0x17c +> > arcpgu_probe+0x138/0x24c +> > platform_drv_probe+0x2e/0x6c +> > really_probe+0x212/0x35c +> > __driver_attach+0x90/0x94 +> > bus_for_each_dev+0x46/0x80 +> > bus_add_driver+0x14e/0x1b4 +> > driver_register+0x64/0x108 +> > do_one_initcall+0x86/0x194 +> > kernel_init_freeable+0xf0/0x188 > > ---[ end trace c67166ad43ddcce2 ]--- > > [drm:drm_sysfs_connector_add] adding "HDMI-A-1" to sysfs > > [drm:drm_sysfs_connector_add] *ERROR* failed to register connector device: -2 @@ -86,12 +86,12 @@ Thanks. Just wanted to make sure we're on the same page :) > register all the drm connectors _after_ calling drm_dev_register(). > Totally forgot about that. Can you pls > - Extract a new drm_connector_register_all() function -> ? (atmel_hlcdc_dc_connector_plug_all seems to be the best template), -> ? including kerneldoc. +> (atmel_hlcdc_dc_connector_plug_all seems to be the best template), +> including kerneldoc. > - Adjust kerneldoc of drm_dev_register() to mention -> ? drm_connector_register_all() and that ordering constraint. +> drm_connector_register_all() and that ordering constraint. > - Roll that helper out to all the drivers that currently hand-roll it (one -> ? patch per driver). +> patch per driver). > > I know a bit of work but imo not too much, and by doing some small > refactoring every time someone stumbles over a drm pitfall we keep the @@ -163,15 +163,15 @@ Yeah I saw this. I was a bit confused with word "kerneldoc" thinking about > > > > But when user-space opens /dev/fb0 and mmaps() it deals with memory pages which > > are by default (at least on ARC) marked as "cached". I.e. user-space application -> > (I use that nice demo app?https://github.com/qtproject/qt/blob/4.8/examples/qws/framebuffer/main.c) +> > (I use that nice demo app https://github.com/qtproject/qt/blob/4.8/examples/qws/framebuffer/main.c) > > deals with frame-buffer via data cache. And that has 2 problems: -> > ?[1] Since no explicit cache flush gets executed some data is left in data cache, -> > ? ? ?i.e. some parts of the picture never reaches real PGU. -> > ? ? ?See what happens on display -?http://imgur.com/iAbnnx3 -> > ? ? ?Those missing lines are exactly those 32-byte missing cache lines. -> > ?[2] Even if we manage to flush data somehow massive amount of data that goes -> > ? ? ?through data cache (let's sat 1080p at 30Hz) will thrash it and as a result -> > ? ? ?there will be no benefit for other cache users to use cache. +> > [1] Since no explicit cache flush gets executed some data is left in data cache, +> > i.e. some parts of the picture never reaches real PGU. +> > See what happens on display - http://imgur.com/iAbnnx3 +> > Those missing lines are exactly those 32-byte missing cache lines. +> > [2] Even if we manage to flush data somehow massive amount of data that goes +> > through data cache (let's sat 1080p@30Hz) will thrash it and as a result +> > there will be no benefit for other cache users to use cache. > > > > So we fix it simply marking pages mapped to user-space apps as uncached > > that effectively routes all FB data directly to memry instead of polluting cache. @@ -182,7 +182,7 @@ Yeah I saw this. I was a bit confused with word "kerneldoc" thinking about > 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?fb_pgprotect() in arch/X/include/asm/fb.h +All other arches implement their own fb_pgprotect() in arch/X/include/asm/fb.h which does exactly what I need. So entire arcpgu_fbdev.c will be dumped in v4 :) -Alexey diff --git a/a/content_digest b/N1/content_digest index 582ac92..36ded40 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -3,23 +3,27 @@ "ref\020160314070009.GN14170@phenom.ffwll.local\0" "ref\01457954159.3306.24.camel@synopsys.com\0" "ref\020160315081056.GS14170@phenom.ffwll.local\0" - "From\0Alexey.Brodkin@synopsys.com (Alexey Brodkin)\0" - "Subject\0[PATCH 1/4 v3] drm: Add support of ARC PGU display controller\0" + "From\0Alexey Brodkin <Alexey.Brodkin@synopsys.com>\0" + "Subject\0Re: [PATCH 1/4 v3] drm: Add support of ARC PGU display controller\0" "Date\0Tue, 15 Mar 2016 15:24:46 +0000\0" - "To\0linux-snps-arc@lists.infradead.org\0" + "To\0daniel@ffwll.ch <daniel@ffwll.ch>\0" + "Cc\0dri-devel@lists.freedesktop.org <dri-devel@lists.freedesktop.org>" + linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> + Jose.Abreu@synopsys.com <Jose.Abreu@synopsys.com> + " linux-snps-arc@lists.infradead.org <linux-snps-arc@lists.infradead.org>\0" "\00:1\0" "b\0" "Hi Daniel,\n" "\n" - "On Tue, 2016-03-15@09:10 +0100, Daniel Vetter wrote:\n" - "> On Mon, Mar 14, 2016@11:15:59AM +0000, Alexey Brodkin wrote:\n" + "On Tue, 2016-03-15 at 09:10 +0100, Daniel Vetter wrote:\n" + "> On Mon, Mar 14, 2016 at 11:15:59AM +0000, Alexey Brodkin wrote:\n" "> > \n" - "> > On Mon, 2016-03-14@08:00 +0100, Daniel Vetter wrote:\n" + "> > On Mon, 2016-03-14 at 08:00 +0100, Daniel Vetter wrote:\n" "> > > \n" - "> > > On Fri, Mar 11, 2016@06:42:36PM +0300, Alexey Brodkin wrote:\n" + "> > > On Fri, Mar 11, 2016 at 06:42:36PM +0300, Alexey Brodkin wrote:\n" "> > > > \n" "> > > > +static int arcpgu_atomic_commit(struct drm_device *dev,\n" - "> > > > +\t\t\t\t????struct drm_atomic_state *state, bool async)\n" + "> > > > +\t\t\t\t\302\240\302\240\302\240\302\240struct drm_atomic_state *state, bool async)\n" "> > > > +{\n" "> > > > +\treturn drm_atomic_helper_commit(dev, state, false);\n" "> > > Note that this isn't really async if you ever get around to implement\n" @@ -34,7 +38,7 @@ "> > > > \n" "> > > > +static struct drm_driver arcpgu_drm_driver = {\n" "> > > > +\t.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |\n" - "> > > > +\t\t\t???DRIVER_ATOMIC,\n" + "> > > > +\t\t\t\302\240\302\240\302\240DRIVER_ATOMIC,\n" "> > > > +\t.preclose = arcpgu_preclose,\n" "> > > > +\t.lastclose = arcpgu_lastclose,\n" "> > > > +\t.name = \"drm-arcpgu\",\n" @@ -53,7 +57,7 @@ "> > Ok I took \"atmel-hlcdc\" as example.\n" "> > And that's interesting.\n" "> > \n" - "> > If I put my?arcpgu_load() in between?drm_dev_alloc() and\n" + "> > If I put my\302\240arcpgu_load() in between\302\240drm_dev_alloc() and\n" "> > drm_dev_register() then I'm getting this on the driver probe:\n" "> > ---------------------------------->8-------------------------------\n" "> > [drm] Initialized drm 1.1.0 20060810\n" @@ -65,23 +69,23 @@ "> > CPU: 0 PID: 1 Comm: swapper Not tainted 4.5.0-rc3-01062-ga447822-dirty #17\n" "> > \n" "> > Stack Trace:\n" - "> > ? arc_unwind_core.constprop.1+0xa4/0x110\n" - "> > ? warn_slowpath_fmt+0x6e/0xfc\n" - "> > ? kobject_add_internal+0x17c/0x498\n" - "> > ? kobject_add+0x98/0xe4\n" - "> > ? device_add+0xc6/0x734\n" - "> > ? device_create_with_groups+0x12a/0x144\n" - "> > ? drm_sysfs_connector_add+0x54/0xe8\n" - "> > ? arcpgu_drm_hdmi_init+0xd4/0x17c\n" - "> > ? arcpgu_probe+0x138/0x24c\n" - "> > ? platform_drv_probe+0x2e/0x6c\n" - "> > ? really_probe+0x212/0x35c\n" - "> > ? __driver_attach+0x90/0x94\n" - "> > ? bus_for_each_dev+0x46/0x80\n" - "> > ? bus_add_driver+0x14e/0x1b4\n" - "> > ? driver_register+0x64/0x108\n" - "> > ? do_one_initcall+0x86/0x194\n" - "> > ? kernel_init_freeable+0xf0/0x188\n" + "> > \302\240 arc_unwind_core.constprop.1+0xa4/0x110\n" + "> > \302\240 warn_slowpath_fmt+0x6e/0xfc\n" + "> > \302\240 kobject_add_internal+0x17c/0x498\n" + "> > \302\240 kobject_add+0x98/0xe4\n" + "> > \302\240 device_add+0xc6/0x734\n" + "> > \302\240 device_create_with_groups+0x12a/0x144\n" + "> > \302\240 drm_sysfs_connector_add+0x54/0xe8\n" + "> > \302\240 arcpgu_drm_hdmi_init+0xd4/0x17c\n" + "> > \302\240 arcpgu_probe+0x138/0x24c\n" + "> > \302\240 platform_drv_probe+0x2e/0x6c\n" + "> > \302\240 really_probe+0x212/0x35c\n" + "> > \302\240 __driver_attach+0x90/0x94\n" + "> > \302\240 bus_for_each_dev+0x46/0x80\n" + "> > \302\240 bus_add_driver+0x14e/0x1b4\n" + "> > \302\240 driver_register+0x64/0x108\n" + "> > \302\240 do_one_initcall+0x86/0x194\n" + "> > \302\240 kernel_init_freeable+0xf0/0x188\n" "> > ---[ end trace c67166ad43ddcce2 ]---\n" "> > [drm:drm_sysfs_connector_add] adding \"HDMI-A-1\" to sysfs\n" "> > [drm:drm_sysfs_connector_add] *ERROR* failed to register connector device: -2\n" @@ -97,12 +101,12 @@ "> register all the drm connectors _after_ calling drm_dev_register().\n" "> Totally forgot about that. Can you pls\n" "> - Extract a new drm_connector_register_all() function\n" - "> ? (atmel_hlcdc_dc_connector_plug_all seems to be the best template),\n" - "> ? including kerneldoc.\n" + "> \302\240 (atmel_hlcdc_dc_connector_plug_all seems to be the best template),\n" + "> \302\240 including kerneldoc.\n" "> - Adjust kerneldoc of drm_dev_register() to mention\n" - "> ? drm_connector_register_all() and that ordering constraint.\n" + "> \302\240 drm_connector_register_all() and that ordering constraint.\n" "> - Roll that helper out to all the drivers that currently hand-roll it (one\n" - "> ? patch per driver).\n" + "> \302\240 patch per driver).\n" "> \n" "> I know a bit of work but imo not too much, and by doing some small\n" "> refactoring every time someone stumbles over a drm pitfall we keep the\n" @@ -174,15 +178,15 @@ "> > \n" "> > But when user-space opens /dev/fb0 and mmaps() it deals with memory pages which\n" "> > are by default (at least on ARC) marked as \"cached\". I.e. user-space application\n" - "> > (I use that nice demo app?https://github.com/qtproject/qt/blob/4.8/examples/qws/framebuffer/main.c)\n" + "> > (I use that nice demo app\302\240https://github.com/qtproject/qt/blob/4.8/examples/qws/framebuffer/main.c)\n" "> > deals with frame-buffer via data cache. And that has 2 problems:\n" - "> > ?[1] Since no explicit cache flush gets executed some data is left in data cache,\n" - "> > ? ? ?i.e. some parts of the picture never reaches real PGU.\n" - "> > ? ? ?See what happens on display -?http://imgur.com/iAbnnx3\n" - "> > ? ? ?Those missing lines are exactly those 32-byte missing cache lines.\n" - "> > ?[2] Even if we manage to flush data somehow massive amount of data that goes\n" - "> > ? ? ?through data cache (let's sat 1080p at 30Hz) will thrash it and as a result\n" - "> > ? ? ?there will be no benefit for other cache users to use cache.\n" + "> > \302\240[1] Since no explicit cache flush gets executed some data is left in data cache,\n" + "> > \302\240 \302\240 \302\240i.e. some parts of the picture never reaches real PGU.\n" + "> > \302\240 \302\240 \302\240See what happens on display -\302\240http://imgur.com/iAbnnx3\n" + "> > \302\240 \302\240 \302\240Those missing lines are exactly those 32-byte missing cache lines.\n" + "> > \302\240[2] Even if we manage to flush data somehow massive amount of data that goes\n" + "> > \302\240 \302\240 \302\240through data cache (let's sat 1080p@30Hz) will thrash it and as a result\n" + "> > \302\240 \302\240 \302\240there will be no benefit for other cache users to use cache.\n" "> > \n" "> > So we fix it simply marking pages mapped to user-space apps as uncached\n" "> > that effectively routes all FB data directly to memry instead of polluting cache.\n" @@ -193,9 +197,9 @@ "> helpers or something similar. That way other drivers don't need to.\n" "\n" "Ok I took another look and now see what's missing.\n" - "All other arches implement their own?fb_pgprotect() in arch/X/include/asm/fb.h\n" + "All other arches implement their own\302\240fb_pgprotect() in arch/X/include/asm/fb.h\n" "which does exactly what I need. So entire arcpgu_fbdev.c will be dumped in v4 :)\n" "\n" -Alexey -8894c3028247614e044272a08b402f4a4365f2344d591a203854239f1ade6254 +5c9cf8d18b77827f0dfb37594ab71904adba669771c5b13bf75fc07eccfd17f5
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.