[Bug 110371] HP Dreamcolor display *Error* No EDID read
https://bugs.freedesktop.org/show_bug.cgi?id=110371 --- Comment #2 from babblebo...@gmail.com --- Created attachment 143957 --> https://bugs.freedesktop.org/attachment.cgi?id=143957=edit Dmesg output from an affected kernel Here is the issue, you can see [1.335096] [drm:dc_link_detect [amdgpu]] *ERROR* No EDID read. Which is about where the display turns into fruit salad. Please let me know if I can submit any more debug info that would assist! I am very much in need of running a newer kernel. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] virtio-gpu api: VIRTIO_GPU_F_RESSOURCE_V2
On Thu, Apr 11, 2019 at 10:49 PM Gerd Hoffmann wrote:
>
> On Thu, Apr 11, 2019 at 06:36:15PM -0700, Gurchetan Singh wrote:
> > On Wed, Apr 10, 2019 at 10:03 PM Gerd Hoffmann wrote:
> > >
> > > > > +/* VIRTIO_GPU_CMD_RESOURCE_CREATE_V2 */
> > > > > +struct virtio_gpu_cmd_resource_create_v2 {
> > > > > + struct virtio_gpu_ctrl_hdr hdr;
> > > > > + __le32 resource_id;
> > > > > + __le32 format;
> > > > > + __le32 width;
> > > > > + __le32 height;
> > > > > + /* 3d only */
> > > > > + __le32 target;
> > > > > + __le32 bind;
> > > > > + __le32 depth;
> > > > > + __le32 array_size;
> > > > > + __le32 last_level;
> > > > > + __le32 nr_samples;
> > > > > + __le32 flags;
> > > > > +};
> > > >
> > > >
> > > > I assume this is always backed by some host side allocation, without any
> > > > guest side pages associated with it?
> > >
> > > No. It is not backed at all yet. Workflow would be like this:
> > >
> > > (1) VIRTIO_GPU_CMD_RESOURCE_CREATE_V2
> > > (2) VIRTIO_GPU_CMD_MEMORY_CREATE (see patch 2)
> > > (3) VIRTIO_GPU_CMD_RESOURCE_MEMORY_ATTACH (see patch 2)
> >
> > Thanks for the clarification.
> >
> > >
> > > You could also create a larger pool with VIRTIO_GPU_CMD_MEMORY_CREATE,
> > > then go attach multiple resources to it.
> > >
> > > > If so, do we want the option for the guest allocate?
> > >
> > > Allocation options are handled by VIRTIO_GPU_CMD_MEMORY_CREATE
> > > (initially guest allocated only, i.e. what virtio-gpu supports today,
> > > the plan is to add other allocation types later on).
> >
> > You want to cover Vulkan, host-allocated dma-bufs, and guest-allocated
> > dma-bufs with this, correct? Let me know if it's a non-goal :-)
>
> Yes, even though it is not clear yet how we are going to handle
> host-allocated buffers in the vhost-user case ...
For Vulkan, VK_EXT_external_memory_dma_buf +
VK_EXT_image_drm_format_modifier should do the trick on Linux devices
that support these extensions.
For GL, I don't see any way forward given the current KVM api.
> > If so, we might want to distinguish between memory types (kind of like
> > memoryTypeIndex in Vulkan). [Assuming memory_id is like resource_id]
>
> For the host-allocated buffers we surely want that, yes.
> For guest-allocated memory regions it isn't useful I think ...
Are guest memory regions always write combine, or can they be (read)
cached? Is this something we can control in the virtgpu kernel
driver?
>
> > 1) Vulkan seems the most straightforward
> >
> > virtio_gpu_cmd_memory_create --> create kernel data structure,
> > vkAllocateMemory on the host or import guest memory into Vulkan,
> > depending on the memory type
> > virtio_gpu_cmd_resource_create_v2 --> vkCreateImage +
> > vkGetImageMemoryRequirements on host
> > virtio_gpu_cmd_resource_attach_memory --> vkBindImageMemory on host
>
> Yes.
>
> Note 1: virtio_gpu_cmd_memory_create + virtio_gpu_cmd_resource_create_v2
> ordering doesn't matter, so you can virtio_gpu_cmd_resource_create_v2
> first to figure stride and size, then adjust memory size accordingly.
>
> Note 2: The old virtio_gpu_cmd_resource_create variants can be used
> too if you don't need the _v2 features.
>
> Note 3: If I understand things correctly it would be valid to create a
> memory pool (allocate one big chunk of memory) with vkAllocateMemory,
> then bind multiple images at different offsets to it.
>
> > 2) With a guest allocated dma-buf using some new allocation library,
> >
> > virtio_gpu_cmd_resource_create_v2 --> host returns metadata describing
> > optimal allocation
> > virtio_gpu_cmd_memory_create --> allocate guest memory pages since
> > it's guest memory type
> > virtio_gpu_cmd_resource_attach_memory --> associate guest pages with
> > resource in kernel, send iovecs to host for bookkeeping
>
> virtio_gpu_cmd_memory_create sends the iovecs. Otherwise correct.
>
> > 3) With gbm it's a little trickier,
> >
> > virtio_gpu_cmd_resource_create_v2 --> gbm_bo_create_with_modifiers,
> > get metadata in return
>
> Only get metadata in return.
With the current gbm API, metadata is only returned after the
allocation is complete.
We're fine with changing this for minigbm (i.e, having
gbm_get_allocation_metadata(width, height, modifier, *out_metadata).
Not sure what the plan is for Mesa gbm, or the Unix Device Memory
Allocator.
>
> > virtio_gpu_cmd_memory_create --> create kernel data structure, but
> > don't allocate pages, nothing on the host
>
> Memory allocation happens here. Probably makes sense to have a
> virtio_gpu_cmd_memory_create_host command here, because the parameters
> we need are quite different from the guest-allocated case.
>
> Maybe we even need a virtio_gpu_cmd_memory_create_host_for_resource
> variant, given that gbm doesn't have raw memory buffers without any
> format attached to it.
We should create VIRTIO_GPU_F_RESOURCE_V2 with what gbm should be in
mind, not what gbm currently is.
>
> > > > > +/*
Re: [PATCH v5 6/7] ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings
Hi, On Mon, Apr 8, 2019 at 9:26 AM Urja Rannikko wrote: > > Hi, > > On Mon, Apr 8, 2019 at 3:21 PM Doug Anderson wrote: > > > > Hi, > > > > On Sat, Apr 6, 2019 at 6:16 PM Urja Rannikko wrote: > > > > > > Hi, > > > > > > > The difference would be in this format just setting hfront-porch = 87 > > > and vback-porch = 14. > > > Anyways the point is: I support moving this mode info into the dts, > > > and I'd like to know how if at all should i go about getting a > > > 60Hz(ish) mode upstreamed? > > > > I'm a bit torn here. I like the idea of actually getting 60 Hz and > > you also increase the vblank time by a little bit (which means that if > > anyone ever gets DDRFreq upstream it will work better). ...but I'm > > also slightly nervous changing something like this without a really > > good motivation. As you said in your commit message the pixels clocks > > claimed by the spec don't actually all work and thus, to some extent, > > we can only rely on trial-and-error here. While your new mode works > > well on your device (and you wisely gave it a bit of margin), it is > > _possible_ that there could be devices out there where it doesn't work > > (especially across various temperature extremes). All devices were > > tested in the factory with the old timings and presumably have been > > running fine for years like that... > Re: the trial and error: it might be the case that the panels actually > work at 1506 vtotal if you also adjust the sync length and/or back > porch "accordingly", whatever that accordingly would be for this panel > since the datasheet doesnt tell. I missed this point when i was doing > my testing and just adjusted the variables with the most > "adjustability" (bigger starting value) to them. Fair enough. I guess I just have my gut instincts that say that this will break some device somewhere, but it's certainly possible that's wrong. > > I will certainly admit that it's unlikely devices would be affected, > > but at the same time I'd want to know how much of a difference going > > from 58.3 Hz to 60 Hz made for you. Could you actually notice any > > visible difference, or was it just nice to be at 60 Hz? > Honestly I was just doing this because i really liked the idea of > actually making it 60Hz and my eyes arent that good at noticing > high-fps things - i think the one case where it might be visible to a > keen eye is 720p60 playback where you'd need to skip "about 2" (1.7..) > frames a second if running at 58.3 Hz. But currently the C201 isnt > doing a lot of that given i dont think i/we have a good software setup > for it. That could be changing in the future with panfrost and the VPU > hardware decoder support, etc. Yeah, I'd definitely wonder how easy this is to notice. Since I haven't ever heard of anyone who thought that the current 58.3 Hz was causing problems that they could actually notice it makes me hesitant to change it. > Anyways I'm thinking it would be prudent to first get this framework > of device-tree modes in and then maybe adjust the mode later. If you're OK with it, let's aim to land things with the current 58.3 and then we can do think about the 60 Hz mode. ...I'm probably sounding super paranoid here since (presumably) anyone who is running upstream Linux on their Chromebook is more than capable of bisecting problems like this if it causes problems, but I guess I'm worried that this could eventually make its way into a Chrome OS tree (either through a kernel uprev or simple cherry-picks) and affect people. > Testing the 60Hz mode is simple enough: > xrandr --newmode 1366x768p60 74.25 1366 1453 1483 1543 768 776 790 802 > -HSync -VSync > xrandr --addmode eDP-1 1366x768p60 > xrandr --output eDP-1 --mode 1366x768p60 > > (The mode name can be anything...) > So meanwhile I would appreciate it if we could get some test reports > of the mode with other veyron chromebooks that have this panel :) I still haven't done this and I'm not in front of my Chromebook now. I'll try to give it a try soon. The kinds of problems I'd expect (if there are any) would be flickers that happen _very_ rarely though, but I can at least do some basic testing. One other note to justify my paranoia: on a past Chromebook we certainly had crazy flickering problems. On one device one day you'd get two flickers and then see nothing for the next two weeks. ...some devices would see at least a flicker a day and some would see no flickers ever. Obviously it's unlikely that would happen here, but such past experience just makes me paranoid. ;-) -Doug ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: imxfb: add COMPILE_TEST support
Hi Bartlomiej,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.1-rc4 next-20190412]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Bartlomiej-Zolnierkiewicz/video-fbdev-imxfb-add-COMPILE_TEST-support/20190413-050928
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
sparse warnings: (new ones prefixed by >>)
>> drivers/video/fbdev/imxfb.c:380:35: sparse: expression using sizeof(void)
>> drivers/video/fbdev/imxfb.c:380:35: sparse: expression using sizeof(void)
drivers/video/fbdev/imxfb.c:381:35: sparse: expression using sizeof(void)
drivers/video/fbdev/imxfb.c:381:35: sparse: expression using sizeof(void)
include/linux/slab.h:666:13: sparse: undefined identifier
'__builtin_mul_overflow'
drivers/video/fbdev/imxfb.c:926:38: sparse: expression using sizeof(void)
drivers/video/fbdev/imxfb.c:926:38: sparse: expression using sizeof(void)
>> drivers/video/fbdev/imxfb.c:977:27: sparse: incorrect type in assignment
>> (different address spaces) @@expected char [noderef] *screen_base
>> @@got sn:2>*screen_base @@
drivers/video/fbdev/imxfb.c:977:27:expected char [noderef]
*screen_base
drivers/video/fbdev/imxfb.c:977:27:got void *
>> drivers/video/fbdev/imxfb.c:1049:52: sparse: incorrect type in argument 3
>> (different address spaces) @@expected void *cpu_addr @@got char
>> [noderef] *screen_base
drivers/video/fbdev/imxfb.c:1080:52: sparse: incorrect type in argument 3
(different address spaces) @@expected void *cpu_addr @@got char
[noderef] *screen_base
include/linux/slab.h:666:13: sparse: call with no type!
vim +380 drivers/video/fbdev/imxfb.c
343684ffb drivers/video/imxfb.c Sascha Hauer 2009-03-19 344
7c2f891cb drivers/video/imxfb.c Sascha Hauer 2005-05-01 345 /*
7c2f891cb drivers/video/imxfb.c Sascha Hauer 2005-05-01 346 *
imxfb_check_var():
7c2f891cb drivers/video/imxfb.c Sascha Hauer 2005-05-01 347 *
Round up in the following order: bits_per_pixel, xres,
7c2f891cb drivers/video/imxfb.c Sascha Hauer 2005-05-01 348 *
yres, xres_virtual, yres_virtual, xoffset, yoffset, grayscale,
7c2f891cb drivers/video/imxfb.c Sascha Hauer 2005-05-01 349 *
bitfields, horizontal timing, vertical timing.
7c2f891cb drivers/video/imxfb.c Sascha Hauer 2005-05-01 350 */
66c8719b2 drivers/video/imxfb.c Sascha Hauer 2008-12-16 351 static int
imxfb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
7c2f891cb drivers/video/imxfb.c Sascha Hauer 2005-05-01 352 {
7c2f891cb drivers/video/imxfb.c Sascha Hauer 2005-05-01 353 struct
imxfb_info *fbi = info->par;
80eee6bca drivers/video/imxfb.c Sascha Hauer 2008-12-16 354 struct
imxfb_rgb *rgb;
343684ffb drivers/video/imxfb.c Sascha Hauer 2009-03-19 355 const
struct imx_fb_videomode *imxfb_mode;
343684ffb drivers/video/imxfb.c Sascha Hauer 2009-03-19 356
unsigned long lcd_clk;
343684ffb drivers/video/imxfb.c Sascha Hauer 2009-03-19 357
unsigned long long tmp;
343684ffb drivers/video/imxfb.c Sascha Hauer 2009-03-19 358 u32 pcr
= 0;
7c2f891cb drivers/video/imxfb.c Sascha Hauer 2005-05-01 359
7c2f891cb drivers/video/imxfb.c Sascha Hauer 2005-05-01 360 if
(var->xres < MIN_XRES)
7c2f891cb drivers/video/imxfb.c Sascha Hauer 2005-05-01 361
var->xres = MIN_XRES;
7c2f891cb drivers/video/imxfb.c Sascha Hauer 2005-05-01 362 if
(var->yres < MIN_YRES)
7c2f891cb drivers/video/imxfb.c Sascha Hauer 2005-05-01 363
var->yres = MIN_YRES;
343684ffb drivers/video/imxfb.c Sascha Hauer 2009-03-19 364
343684ffb drivers/video/imxfb.c Sascha Hauer 2009-03-19 365
imxfb_mode = imxfb_find_mode(fbi);
343684ffb drivers/video/imxfb.c Sascha Hauer 2009-03-19 366 if
(!imxfb_mode)
343684ffb drivers/video/imxfb.c Sascha Hauer 2009-03-19 367
return -EINVAL;
343684ffb drivers/video/imxfb.c Sascha Hauer 2009-03-19 368
343684ffb drivers/video/imxfb.c Sascha Hauer 2009-03-19 369
var->xres = imxfb_mode->mode.xres;
343684ffb drivers/video/imxfb.c Sascha Hauer 2009-03-19 370
var->yres = imxfb_mode->mode.yres;
343684ffb drivers/video/imxfb.c Sascha Hauer 2009-03-19 371
var->bits_per_pixel = imxfb_mode->bpp;
343684ffb drivers/video/imxfb.c Sascha Hauer 2009-03-19 372
var->pixclock = imxfb_mode->mode.pixclock;
343684ffb drivers/video/imxfb.c Sascha Hauer 2009-03-19 373
va
Re: [PATCH 3/3] virtio-gpu api: VIRTIO_GPU_F_RESSOURCE_V2
Hi,
I am still new to virgl, and missed the last round of discussion about
resource_create_v2.
>From the discussion below, semantically resource_create_v2 creates a host
resource object _without_ any storage; memory_create creates a host memory
object which provides the storage. Is that correct?
And this version of memory_create is probably the most special one among
its other potential variants, because it is the only(?) one who imports the
pre-allocated guest pages.
Do we expect these new commands to be supported by OpenGL, which does not
separate resources and memories?
On Thu, Apr 11, 2019 at 10:49 PM Gerd Hoffmann wrote:
> On Thu, Apr 11, 2019 at 06:36:15PM -0700, Gurchetan Singh wrote:
> > On Wed, Apr 10, 2019 at 10:03 PM Gerd Hoffmann
> wrote:
> > >
> > > > > +/* VIRTIO_GPU_CMD_RESOURCE_CREATE_V2 */
> > > > > +struct virtio_gpu_cmd_resource_create_v2 {
> > > > > + struct virtio_gpu_ctrl_hdr hdr;
> > > > > + __le32 resource_id;
> > > > > + __le32 format;
> > > > > + __le32 width;
> > > > > + __le32 height;
> > > > > + /* 3d only */
> > > > > + __le32 target;
> > > > > + __le32 bind;
> > > > > + __le32 depth;
> > > > > + __le32 array_size;
> > > > > + __le32 last_level;
> > > > > + __le32 nr_samples;
> > > > > + __le32 flags;
> > > > > +};
> > > >
> > > >
> > > > I assume this is always backed by some host side allocation, without
> any
> > > > guest side pages associated with it?
> > >
> > > No. It is not backed at all yet. Workflow would be like this:
> > >
> > > (1) VIRTIO_GPU_CMD_RESOURCE_CREATE_V2
> > > (2) VIRTIO_GPU_CMD_MEMORY_CREATE (see patch 2)
> > > (3) VIRTIO_GPU_CMD_RESOURCE_MEMORY_ATTACH (see patch 2)
> >
> > Thanks for the clarification.
> >
> > >
> > > You could also create a larger pool with VIRTIO_GPU_CMD_MEMORY_CREATE,
> > > then go attach multiple resources to it.
> > >
> > > > If so, do we want the option for the guest allocate?
> > >
> > > Allocation options are handled by VIRTIO_GPU_CMD_MEMORY_CREATE
> > > (initially guest allocated only, i.e. what virtio-gpu supports today,
> > > the plan is to add other allocation types later on).
> >
> > You want to cover Vulkan, host-allocated dma-bufs, and guest-allocated
> > dma-bufs with this, correct? Let me know if it's a non-goal :-)
>
> Yes, even though it is not clear yet how we are going to handle
> host-allocated buffers in the vhost-user case ...
This might be another dumb question, but is this only an issue for
vhost-user(-gpu) case? What mechanisms are used to map host dma-buf into
the guest address space?
>
> > If so, we might want to distinguish between memory types (kind of like
> > memoryTypeIndex in Vulkan). [Assuming memory_id is like resource_id]
>
> For the host-allocated buffers we surely want that, yes.
> For guest-allocated memory regions it isn't useful I think ...
>
Guest-allocated memory regions can be just another memory type.
But one needs to create the resource first to know which memory types can
be attached to it. I think the metadata needs to be returned with
resource_create_v2.
>
> > 1) Vulkan seems the most straightforward
> >
> > virtio_gpu_cmd_memory_create --> create kernel data structure,
> > vkAllocateMemory on the host or import guest memory into Vulkan,
> > depending on the memory type
> > virtio_gpu_cmd_resource_create_v2 --> vkCreateImage +
> > vkGetImageMemoryRequirements on host
> > virtio_gpu_cmd_resource_attach_memory --> vkBindImageMemory on host
>
> Yes.
>
> Note 1: virtio_gpu_cmd_memory_create + virtio_gpu_cmd_resource_create_v2
> ordering doesn't matter, so you can virtio_gpu_cmd_resource_create_v2
> first to figure stride and size, then adjust memory size accordingly.
>
> Note 2: The old virtio_gpu_cmd_resource_create variants can be used
> too if you don't need the _v2 features.
>
> Note 3: If I understand things correctly it would be valid to create a
> memory pool (allocate one big chunk of memory) with vkAllocateMemory,
> then bind multiple images at different offsets to it.
>
> > 2) With a guest allocated dma-buf using some new allocation library,
> >
> > virtio_gpu_cmd_resource_create_v2 --> host returns metadata describing
> > optimal allocation
> > virtio_gpu_cmd_memory_create --> allocate guest memory pages since
> > it's guest memory type
> > virtio_gpu_cmd_resource_attach_memory --> associate guest pages with
> > resource in kernel, send iovecs to host for bookkeeping
>
> virtio_gpu_cmd_memory_create sends the iovecs. Otherwise correct.
>
> > 3) With gbm it's a little trickier,
> >
> > virtio_gpu_cmd_resource_create_v2 --> gbm_bo_create_with_modifiers,
> > get metadata in return
>
> Only get metadata in return.
>
> > virtio_gpu_cmd_memory_create --> create kernel data structure, but
> > don't allocate pages, nothing on the host
>
> Memory allocation happens here. Probably makes sense to have a
> virtio_gpu_cmd_memory_create_host command here, because the parameters
> we
Re: [PATCH] video: fbdev: pxa168fb: add COMPILE_TEST support
Hi Bartlomiej,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.1-rc4 next-20190412]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Bartlomiej-Zolnierkiewicz/video-fbdev-pxa168fb-add-COMPILE_TEST-support/20190413-043546
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
sparse warnings: (new ones prefixed by >>)
>> drivers/video/fbdev/pxa168fb.c:175:29: sparse: expression using sizeof(void)
>> drivers/video/fbdev/pxa168fb.c:175:29: sparse: expression using sizeof(void)
drivers/video/fbdev/pxa168fb.c:180:37: sparse: expression using sizeof(void)
drivers/video/fbdev/pxa168fb.c:180:37: sparse: expression using sizeof(void)
>> drivers/video/fbdev/pxa168fb.c:603:32: sparse: Using plain integer as NULL
>> pointer
drivers/video/fbdev/pxa168fb.c:604:37: sparse: Using plain integer as NULL
pointer
>> drivers/video/fbdev/pxa168fb.c:680:27: sparse: incorrect type in assignment
>> (different address spaces) @@expected char [noderef] *screen_base
>> @@got sn:2>*screen_base @@
drivers/video/fbdev/pxa168fb.c:680:27:expected char [noderef]
*screen_base
drivers/video/fbdev/pxa168fb.c:680:27:got void *
>> drivers/video/fbdev/pxa168fb.c:770:29: sparse: incorrect type in argument 3
>> (different address spaces) @@expected void *cpu_addr @@got char
>> [noderef] *screen_base
drivers/video/fbdev/pxa168fb.c:805:25: sparse: incorrect type in argument 3
(different address spaces) @@expected void *cpu_addr @@got char
[noderef] *screen_base
vim +175 drivers/video/fbdev/pxa168fb.c
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 165
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 166 static
void set_mode(struct pxa168fb_info *fbi, struct fb_var_screeninfo *var,
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 167
struct fb_videomode *mode, int pix_fmt, int ystretch)
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 168 {
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 169 struct
fb_info *info = fbi->info;
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 170
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 171
set_pix_fmt(var, pix_fmt);
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 172
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 173
var->xres = mode->xres;
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 174
var->yres = mode->yres;
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 @175
var->xres_virtual = max(var->xres, var->xres_virtual);
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 176 if
(ystretch)
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 177
var->yres_virtual = info->fix.smem_len /
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 178
(var->xres_virtual * (var->bits_per_pixel >> 3));
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 179 else
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 180
var->yres_virtual = max(var->yres, var->yres_virtual);
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 181
var->grayscale = 0;
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 182
var->accel_flags = FB_ACCEL_NONE;
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 183
var->pixclock = mode->pixclock;
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 184
var->left_margin = mode->left_margin;
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 185
var->right_margin = mode->right_margin;
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 186
var->upper_margin = mode->upper_margin;
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 187
var->lower_margin = mode->lower_margin;
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 188
var->hsync_len = mode->hsync_len;
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 189
var->vsync_len = mode->vsync_len;
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 190
var->sync = mode->sync;
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 191
var->vmode = FB_VMODE_NONINTERLACED;
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 192
var->rotate = FB_ROTATE_UR;
638772c7 drivers/video/pxa168fb.c Lennert Buytenhek 2009-02-11 193
[Bug 110355] radeonsi: GTK elements become invisible in some applications (GIMP, LibreOffice)
https://bugs.freedesktop.org/show_bug.cgi?id=110355 --- Comment #9 from Diego Viola --- I get the same problem with GNOME 3.32 on archlinux (Wayland and GNOME Xorg). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!
https://bugs.freedesktop.org/show_bug.cgi?id=102322 --- Comment #80 from dwagner --- (In reply to Jaap Buurman from comment #79) > I am also running into the same issue. I have two questions that might help > tracking down why we are having issues, but not all people that are running > a Vega graphics card. As you can see from my initial description, I'm running an RX460, which uses not a "Vega", but a "Polaris 11" AMD GPU. > What is the output of the following command for you guys? > > cat /sys/class/drm/card0/device/vbios_version "113-BAFFIN_PRO_1606" I have not heard of any update to this from the vendor - there is just some unofficial hacked version around (which I do not use) that is said to enable some switched-off CUs. > Memory clocking is different for people running multiple monitors. Are you > guys also running multiple monitors by any chance? No, I'm using just one 3840x2160 @ 60Hz HDMI display. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110214] radeonsi: xterm scrollback buffer disappears while Shift+PgUp and Shift+PgDn
https://bugs.freedesktop.org/show_bug.cgi?id=110214 --- Comment #78 from Diego Viola --- Created attachment 143956 --> https://bugs.freedesktop.org/attachment.cgi?id=143956=edit clinfo -A output -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!
https://bugs.freedesktop.org/show_bug.cgi?id=102322 --- Comment #79 from Jaap Buurman --- I am also running into the same issue. I have two questions that might help tracking down why we are having issues, but not all people that are running a Vega graphics card. 1) What is the output of the following command for you guys? cat /sys/class/drm/card0/device/vbios_version I am running the following version: 113-D0500100-103 According to the techpowerup GPU bios database, this is a vega bios that was replaced two days (!) later by a new version. Perhaps issues were found that required another bios update? I might install Windows on a spare HDD and try to flash my Vega to see if that changes anything. 2) Memory clocking is different for people running multiple monitors. Are you guys also running multiple monitors by any chance? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #6 from Jaap Buurman --- Another question: What is the output of the following command for you guys? cat /sys/class/drm/card0/device/vbios_version I am running the following version: 113-D0500100-103 According to the techpowerup GPU bios database, this is a vega bios that was replaced two days (!) later by a new version. Perhaps issues were found that required another bios update? I might install Windows on a spare HDD and try to flash my Vega to see if that changes anything. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #5 from Jaap Buurman --- I have the exact same problem with my Vega 64. Crashes when playing games. Happens with Vulkan games (RADV), OpenGL games (RadeonSI) and DirectX 9 games via Wine (Gallium9). It happens only for some games, presumably because it depends on the workload. I am also suspecting power management issues. This might be a long shot, but worth a try. I know for a fact that Power management works slightly different when multiple monitors are connected, as memory isn't clocked back as much in that case. For the people also experiencing this issue, are you guys running multiple monitors like I am? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/9] mm: Add an apply_to_pfn_range interface
On Fri, Apr 12, 2019 at 04:04:18PM +, Thomas Hellstrom wrote:
> This is basically apply_to_page_range with added functionality:
> Allocating missing parts of the page table becomes optional, which
> means that the function can be guaranteed not to error if allocation
> is disabled. Also passing of the closure struct and callback function
> becomes different and more in line with how things are done elsewhere.
>
> Finally we keep apply_to_page_range as a wrapper around apply_to_pfn_range
>
> The reason for not using the page-walk code is that we want to perform
> the page-walk on vmas pointing to an address space without requiring the
> mmap_sem to be held rather thand on vmas belonging to a process with the
> mmap_sem held.
>
> Notable changes since RFC:
> Don't export apply_to_pfn range.
>
> Cc: Andrew Morton
> Cc: Matthew Wilcox
> Cc: Will Deacon
> Cc: Peter Zijlstra
> Cc: Rik van Riel
> Cc: Minchan Kim
> Cc: Michal Hocko
> Cc: Huang Ying
> Cc: Souptick Joarder
> Cc: "Jérôme Glisse"
> Cc: linux...@kvack.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Thomas Hellstrom
> ---
> include/linux/mm.h | 10
> mm/memory.c| 130 ++---
> 2 files changed, 108 insertions(+), 32 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 80bb6408fe73..b7dd4ddd6efb 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2632,6 +2632,16 @@ typedef int (*pte_fn_t)(pte_t *pte, pgtable_t token,
> unsigned long addr,
> extern int apply_to_page_range(struct mm_struct *mm, unsigned long address,
> unsigned long size, pte_fn_t fn, void *data);
>
> +struct pfn_range_apply;
> +typedef int (*pter_fn_t)(pte_t *pte, pgtable_t token, unsigned long addr,
> + struct pfn_range_apply *closure);
> +struct pfn_range_apply {
> + struct mm_struct *mm;
> + pter_fn_t ptefn;
> + unsigned int alloc;
> +};
> +extern int apply_to_pfn_range(struct pfn_range_apply *closure,
> + unsigned long address, unsigned long size);
>
> #ifdef CONFIG_PAGE_POISONING
> extern bool page_poisoning_enabled(void);
> diff --git a/mm/memory.c b/mm/memory.c
> index a95b4a3b1ae2..60d67158964f 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1938,18 +1938,17 @@ int vm_iomap_memory(struct vm_area_struct *vma,
> phys_addr_t start, unsigned long
> }
> EXPORT_SYMBOL(vm_iomap_memory);
>
> -static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
> - unsigned long addr, unsigned long end,
> - pte_fn_t fn, void *data)
> +static int apply_to_pte_range(struct pfn_range_apply *closure, pmd_t *pmd,
> + unsigned long addr, unsigned long end)
> {
> pte_t *pte;
> int err;
> pgtable_t token;
> spinlock_t *uninitialized_var(ptl);
>
> - pte = (mm == _mm) ?
> + pte = (closure->mm == _mm) ?
> pte_alloc_kernel(pmd, addr) :
> - pte_alloc_map_lock(mm, pmd, addr, );
> + pte_alloc_map_lock(closure->mm, pmd, addr, );
> if (!pte)
> return -ENOMEM;
>
> @@ -1960,86 +1959,107 @@ static int apply_to_pte_range(struct mm_struct *mm,
> pmd_t *pmd,
> token = pmd_pgtable(*pmd);
>
> do {
> - err = fn(pte++, token, addr, data);
> + err = closure->ptefn(pte++, token, addr, closure);
> if (err)
> break;
> } while (addr += PAGE_SIZE, addr != end);
>
> arch_leave_lazy_mmu_mode();
>
> - if (mm != _mm)
> + if (closure->mm != _mm)
> pte_unmap_unlock(pte-1, ptl);
> return err;
> }
>
> -static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud,
> - unsigned long addr, unsigned long end,
> - pte_fn_t fn, void *data)
> +static int apply_to_pmd_range(struct pfn_range_apply *closure, pud_t *pud,
> + unsigned long addr, unsigned long end)
> {
> pmd_t *pmd;
> unsigned long next;
> - int err;
> + int err = 0;
>
> BUG_ON(pud_huge(*pud));
>
> - pmd = pmd_alloc(mm, pud, addr);
> + pmd = pmd_alloc(closure->mm, pud, addr);
> if (!pmd)
> return -ENOMEM;
> +
> do {
> next = pmd_addr_end(addr, end);
> - err = apply_to_pte_range(mm, pmd, addr, next, fn, data);
> + if (!closure->alloc && pmd_none_or_clear_bad(pmd))
> + continue;
> + err = apply_to_pte_range(closure, pmd, addr, next);
> if (err)
> break;
> } while (pmd++, addr = next, addr != end);
> return err;
> }
>
> -static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d,
> - unsigned long addr, unsigned long end,
> -
[Bug 108044] [CI][BAT] igt@drv_selftest@live_hangcheck - incomplete
https://bugs.freedesktop.org/show_bug.cgi?id=108044 Chris Wilson changed: What|Removed |Added QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | Component|DRM/Intel |IGT Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org --- Comment #4 from Chris Wilson --- This happens quite frequently where Jenkins stops early, but the run continues until it randomly declares an incomplete later. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/rockchip: shutdown drm subsystem on shutdown
Hi,
On Tue, Apr 2, 2019 at 4:38 AM Heiko Stuebner wrote:
>
> From: Vicente Bergas
>
> As explained by Robin Murphy:
> > the IOMMU shutdown disables paging, so if the VOP is still
> > scanning out then that will result in whatever IOVAs it was using now going
> > straight out onto the bus as physical addresses.
>
> We had a more radical approach before in commit
> 7f3ef5dedb14 ("drm/rockchip: Allow driver to be shutdown on reboot/kexec")
> but that resulted in new warnings and oopses on shutdown on rk3399
> chromeos devices.
>
> So second try is resurrecting Vicentes shutdown change which should
> achieve the same result but in a less drastic way.
>
> Fixes: 63238173b2fa ("Revert drm/rockchip: Allow driver to be shutdown on
> reboot/kexec")
> Cc: Jeffy Chen
> Cc: Robin Murphy
> Cc: Marc Zyngier
> Cc: Brian Norris
> Cc: Doug Anderson
> Cc: sta...@vger.kernel.org
> Suggested-by: JeffyChen
> Suggested-by: Robin Murphy
> Signed-off-by: Vicente Bergas
> [adapted commit message to explain the history]
> Signed-off-by: Heiko Stuebner
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 9 +
> 1 file changed, 9 insertions(+)
I picked this back to the Chrome OS 4.19 kernel and tried it on
rk3288-veyron-jerry. Rebooting caused no complaints (I confirmed this
code was running by adding a printk).
I plugged in to an HDMI monitor. Rebooting caused no complaints.
I then let the display idle off (just in case that mattered). Again
no complaints.
Thus, in case it's helpful:
Tested-by: Douglas Anderson
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/2] Add AUX device entries for DP MST devices
On Fri, Apr 12, 2019 at 12:05:29PM -0400, sunpeng...@amd.com wrote: > From: Leo Li > > Hi all, > > This is a follup to this change made by Ville to add MST aux nodes: > https://github.com/vsyrjala/linux/commit/cac63f799ee2f5fbbe4f0a375383f13e03d640a5 > Patch 2/2 describes what I added on top. Cool. I take you got it to actually work? IIRC I never managed that :P > > Sending as an RFC since there are some items I'm not certain on: > > 1) Only expose aux devices for physical ports. FWICT, only DPTX and DPRX >can handle AUX transactions, leaving logical ports out. Hmm. My MST-foo is admittedly weak so I'm not sure. A quick trawl through the spec didn't provide any solid explanations either :( However eg. "Figure 2-83: Example Multi-function MST Branch-Sink Device Enumeration" in the DP 1.4 spec does appear to show kind of virtual DPCD thing behind a logical port. But I'm not really sure what than means. > 2) Naming of exposed AUX devices. I'm not sure if the scheme implemented >here is the best approach. I'm not sure magic naming schemes are the best. I believe we do have the sysfs hierarchy which allows you to find the right aux dev for the connector, but I do admit that can be a bit cumbersome to use. Also I'm not sure if all the things we might want to talk to are even represented by a connector, so maybe we do need something else. > > Let me know your thoughts, > Leo > > Leo Li (1): > drm/dp_mst: Use non-cyclic idr, add suffix option for aux device > > Ville Syrjälä (1): > drm/dp_mst: Register aux-dev nodes for MST ports > > drivers/gpu/drm/drm_crtc_helper_internal.h | 5 +- > drivers/gpu/drm/drm_dp_aux_dev.c | 21 -- > drivers/gpu/drm/drm_dp_helper.c| 2 +- > drivers/gpu/drm/drm_dp_mst_topology.c | 109 > + > include/drm/drm_dp_helper.h| 4 ++ > include/drm/drm_dp_mst_helper.h| 6 ++ > 6 files changed, 125 insertions(+), 22 deletions(-) > > -- > 2.7.4 -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: remove redundant 'default n' from Kconfig
On Fri, Apr 12, 2019 at 5:56 AM Bartlomiej Zolnierkiewicz
wrote:
>
> 'default n' is the default value for any bool or tristate Kconfig
> setting so there is no need to write it explicitly.
>
> Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
> is not set' for visible symbols") the Kconfig behavior is the same
> regardless of 'default n' being present or not:
>
> ...
> One side effect of (and the main motivation for) this change is making
> the following two definitions behave exactly the same:
>
> config FOO
> bool
>
> config FOO
> bool
> default n
>
> With this change, neither of these will generate a
> '# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
> That might make it clearer to people that a bare 'default n' is
> redundant.
> ...
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
Acked-by: Alex Deucher
for amdgpu and drm.
> ---
> drivers/gpu/drm/Kconfig |5 -
> drivers/gpu/drm/amd/amdgpu/Kconfig |1 -
> drivers/gpu/drm/arm/Kconfig |1 -
> drivers/gpu/drm/exynos/Kconfig |2 --
> drivers/gpu/drm/i915/Kconfig|3 ---
> drivers/gpu/drm/i915/Kconfig.debug | 13 -
> drivers/gpu/drm/msm/Kconfig |2 --
> drivers/gpu/drm/nouveau/Kconfig |2 --
> drivers/gpu/drm/omapdrm/Kconfig |1 -
> drivers/gpu/drm/omapdrm/dss/Kconfig |6 --
> 10 files changed, 36 deletions(-)
>
> Index: b/drivers/gpu/drm/Kconfig
> ===
> --- a/drivers/gpu/drm/Kconfig 2019-04-12 11:42:30.070095359 +0200
> +++ b/drivers/gpu/drm/Kconfig 2019-04-12 11:42:30.066095359 +0200
> @@ -37,7 +37,6 @@ config DRM_DP_AUX_CHARDEV
>
> config DRM_DEBUG_MM
> bool "Insert extra checks and debug info into the DRM range managers"
> - default n
> depends on DRM=y
> depends on STACKTRACE_SUPPORT
> select STACKDEPOT
> @@ -56,7 +55,6 @@ config DRM_DEBUG_SELFTEST
> select PRIME_NUMBERS
> select DRM_LIB_RANDOM
> select DRM_KMS_HELPER
> - default n
> help
> This option provides kernel modules that can be used to run
> various selftests on parts of the DRM api. This option is not
> @@ -113,7 +111,6 @@ config DRM_FBDEV_OVERALLOC
> config DRM_FBDEV_LEAK_PHYS_SMEM
> bool "Shamelessly allow leaking of fbdev physical address (DANGEROUS)"
> depends on DRM_FBDEV_EMULATION && EXPERT
> - default n
> help
> In order to keep user-space compatibility, we want in certain
> use-cases to keep leaking the fbdev physical address to the
> @@ -247,7 +244,6 @@ config DRM_VKMS
> tristate "Virtual KMS (EXPERIMENTAL)"
> depends on DRM
> select DRM_KMS_HELPER
> - default n
> help
> Virtual Kernel Mode-Setting (VKMS) is used for testing or for
> running GPU in a headless machines. Choose this option to get
> @@ -424,4 +420,3 @@ config DRM_PANEL_ORIENTATION_QUIRKS
>
> config DRM_LIB_RANDOM
> bool
> - default n
> Index: b/drivers/gpu/drm/amd/amdgpu/Kconfig
> ===
> --- a/drivers/gpu/drm/amd/amdgpu/Kconfig2019-04-12 11:42:30.070095359
> +0200
> +++ b/drivers/gpu/drm/amd/amdgpu/Kconfig2019-04-12 11:42:30.066095359
> +0200
> @@ -35,7 +35,6 @@ config DRM_AMDGPU_GART_DEBUGFS
> bool "Allow GART access through debugfs"
> depends on DRM_AMDGPU
> depends on DEBUG_FS
> - default n
> help
> Selecting this option creates a debugfs file to inspect the mapped
> pages. Uses more memory for housekeeping, enable only for debugging.
> Index: b/drivers/gpu/drm/arm/Kconfig
> ===
> --- a/drivers/gpu/drm/arm/Kconfig 2019-04-12 11:42:30.070095359 +0200
> +++ b/drivers/gpu/drm/arm/Kconfig 2019-04-12 11:42:30.066095359 +0200
> @@ -16,7 +16,6 @@ config DRM_HDLCD
> config DRM_HDLCD_SHOW_UNDERRUN
> bool "Show underrun conditions"
> depends on DRM_HDLCD
> - default n
> help
> Enable this option to show in red colour the pixels that the
> HDLCD device did not fetch from framebuffer due to underrun
> Index: b/drivers/gpu/drm/exynos/Kconfig
> ===
> --- a/drivers/gpu/drm/exynos/Kconfig2019-04-12 11:42:30.070095359 +0200
> +++ b/drivers/gpu/drm/exynos/Kconfig2019-04-12 11:42:30.066095359 +0200
> @@ -46,7 +46,6 @@ config DRM_EXYNOS_DPI
> bool "Parallel output"
> depends on DRM_EXYNOS_FIMD
> select DRM_PANEL
> - default n
> help
> This enables support for Exynos parallel output.
>
> @@ -55,7 +54,6 @@ config DRM_EXYNOS_DSI
>
[PATCH 1/2] drm/dp_aux: Use non-cyclic idr, add suffix option for aux device
From: Leo Li
In preparation for adding aux devices for DP MST:
1. A non-cyclic idr is used for the device minor version. That way,
hotplug cycling MST devices won't needlessly increment the minor
version index.
2. A suffix option is added to the aux device file name. It can be used
to identify the corresponding MST device.
Signed-off-by: Leo Li
---
drivers/gpu/drm/drm_crtc_helper_internal.h | 5 +++--
drivers/gpu/drm/drm_dp_aux_dev.c | 8
drivers/gpu/drm/drm_dp_helper.c| 2 +-
3 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper_internal.h
b/drivers/gpu/drm/drm_crtc_helper_internal.h
index b5ac158..9f0907b 100644
--- a/drivers/gpu/drm/drm_crtc_helper_internal.h
+++ b/drivers/gpu/drm/drm_crtc_helper_internal.h
@@ -46,7 +46,7 @@ static inline int drm_fb_helper_modinit(void)
#ifdef CONFIG_DRM_DP_AUX_CHARDEV
int drm_dp_aux_dev_init(void);
void drm_dp_aux_dev_exit(void);
-int drm_dp_aux_register_devnode(struct drm_dp_aux *aux);
+int drm_dp_aux_register_devnode(struct drm_dp_aux *aux, const char *suffix);
void drm_dp_aux_unregister_devnode(struct drm_dp_aux *aux);
#else
static inline int drm_dp_aux_dev_init(void)
@@ -58,7 +58,8 @@ static inline void drm_dp_aux_dev_exit(void)
{
}
-static inline int drm_dp_aux_register_devnode(struct drm_dp_aux *aux)
+static inline int drm_dp_aux_register_devnode(struct drm_dp_aux *aux,
+ const char *suffix)
{
return 0;
}
diff --git a/drivers/gpu/drm/drm_dp_aux_dev.c b/drivers/gpu/drm/drm_dp_aux_dev.c
index 0e4f25d..2310a67 100644
--- a/drivers/gpu/drm/drm_dp_aux_dev.c
+++ b/drivers/gpu/drm/drm_dp_aux_dev.c
@@ -80,8 +80,7 @@ static struct drm_dp_aux_dev *alloc_drm_dp_aux_dev(struct
drm_dp_aux *aux)
kref_init(_dev->refcount);
mutex_lock(_idr_mutex);
- index = idr_alloc_cyclic(_idr, aux_dev, 0, DRM_AUX_MINORS,
-GFP_KERNEL);
+ index = idr_alloc(_idr, aux_dev, 0, DRM_AUX_MINORS, GFP_KERNEL);
mutex_unlock(_idr_mutex);
if (index < 0) {
kfree(aux_dev);
@@ -290,7 +289,7 @@ void drm_dp_aux_unregister_devnode(struct drm_dp_aux *aux)
kref_put(_dev->refcount, release_drm_dp_aux_dev);
}
-int drm_dp_aux_register_devnode(struct drm_dp_aux *aux)
+int drm_dp_aux_register_devnode(struct drm_dp_aux *aux, const char *suffix)
{
struct drm_dp_aux_dev *aux_dev;
int res;
@@ -301,7 +300,8 @@ int drm_dp_aux_register_devnode(struct drm_dp_aux *aux)
aux_dev->dev = device_create(drm_dp_aux_dev_class, aux->dev,
MKDEV(drm_dev_major, aux_dev->index), NULL,
-"drm_dp_aux%d", aux_dev->index);
+"drm_dp_aux%d%s", aux_dev->index,
+suffix ? suffix : "");
if (IS_ERR(aux_dev->dev)) {
res = PTR_ERR(aux_dev->dev);
aux_dev->dev = NULL;
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index e2266ac..13f1005 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1143,7 +1143,7 @@ int drm_dp_aux_register(struct drm_dp_aux *aux)
strlcpy(aux->ddc.name, aux->name ? aux->name : dev_name(aux->dev),
sizeof(aux->ddc.name));
- ret = drm_dp_aux_register_devnode(aux);
+ ret = drm_dp_aux_register_devnode(aux, NULL);
if (ret)
return ret;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/dp_mst: Register aux-dev nodes for MST ports
From: Ville Syrjälä
Expose AUX devices for MST ports, similar to how they are exposed for
SST.
The registered device will have it's MST port path appended in order to
identify it. i.e. /dev/drm_dp_aux4_mst:0-2-1
So for a MST topology like so:
+-+
| ASIC |
+-+
Conn-0|
|
+v+
+| MST HUB |+
|+-+|
| |
|Port-1 Port-2|
+-v-+ +-v-+
| MST | | SST |
| Display | | Display |
+---+ +---+
|Port-1
x
The list of AUX device names will look like:
AUX Device Name | MST Device
--+--
drm_dp_aux0 | MST Hub
drm_dp_aux1_mst:0-1-1 | MST Display's disconnected DP out
drm_dp_aux2_mst:0-1 | MST Display
drm_dp_aux3_mst:0-2 | SST Display
Note that aux devices are only created for Physical Ports. Logical Ports
are left out, since they are internally connected within the MST device
(not connected to a DP RX or TX).
Leo Li:
* Add missing drm_crtc_helper_internal.h include
* Fix hard-coded offset and size in drm_dp_send_dpcd_read()
* Only create aux devices for physical ports.
Signed-off-by: Ville Syrjälä
Signed-off-by: Leo Li
---
drivers/gpu/drm/drm_dp_aux_dev.c | 13 +++-
drivers/gpu/drm/drm_dp_mst_topology.c | 109 ++
include/drm/drm_dp_helper.h | 4 ++
include/drm/drm_dp_mst_helper.h | 6 ++
4 files changed, 117 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_aux_dev.c b/drivers/gpu/drm/drm_dp_aux_dev.c
index 2310a67..f1241d1 100644
--- a/drivers/gpu/drm/drm_dp_aux_dev.c
+++ b/drivers/gpu/drm/drm_dp_aux_dev.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
@@ -160,7 +161,11 @@ static ssize_t auxdev_read_iter(struct kiocb *iocb, struct
iov_iter *to)
break;
}
- res = drm_dp_dpcd_read(aux_dev->aux, pos, buf, todo);
+ if (aux_dev->aux->is_remote)
+ res = drm_dp_mst_dpcd_read(aux_dev->aux, pos, buf,
todo);
+ else
+ res = drm_dp_dpcd_read(aux_dev->aux, pos, buf, todo);
+
if (res <= 0)
break;
@@ -207,7 +212,11 @@ static ssize_t auxdev_write_iter(struct kiocb *iocb,
struct iov_iter *from)
break;
}
- res = drm_dp_dpcd_write(aux_dev->aux, pos, buf, todo);
+ if (aux_dev->aux->is_remote)
+ res = drm_dp_mst_dpcd_write(aux_dev->aux, pos, buf,
todo);
+ else
+ res = drm_dp_dpcd_write(aux_dev->aux, pos, buf, todo);
+
if (res <= 0)
break;
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 2ab16c9..d5282db 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -35,6 +35,8 @@
#include
#include
+#include "drm_crtc_helper_internal.h"
+
/**
* DOC: dp mst helper
*
@@ -52,6 +54,9 @@ static int drm_dp_dpcd_write_payload(struct
drm_dp_mst_topology_mgr *mgr,
int id,
struct drm_dp_payload *payload);
+static int drm_dp_send_dpcd_read(struct drm_dp_mst_topology_mgr *mgr,
+struct drm_dp_mst_port *port,
+int offset, int size, u8 *bytes);
static int drm_dp_send_dpcd_write(struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_port *port,
int offset, int size, u8 *bytes);
@@ -941,6 +946,8 @@ static void drm_dp_destroy_port(struct kref *kref)
struct drm_dp_mst_topology_mgr *mgr = port->mgr;
if (!port->input) {
+ drm_dp_aux_unregister_devnode(>aux);
+
port->vcpi.num_slots = 0;
kfree(port->cached_edid);
@@ -1095,6 +1102,46 @@ static bool drm_dp_port_setup_pdt(struct drm_dp_mst_port
*port)
return send_link;
}
+/**
+ * drm_dp_mst_dpcd_read() - read a series of bytes from the DPCD via sideband
+ * @aux: Fake sideband AUX CH
+ * @offset: address of the (first) register to read
+ * @buffer: buffer to store the register values
+ * @size: number of bytes in @buffer
+ *
+ * Performs the same functionality for remote devices via
+ * sideband messaging as drm_dp_dpcd_read() does for local
+ * devices via actual AUX CH.
+ */
+ssize_t drm_dp_mst_dpcd_read(struct drm_dp_aux *aux,
+unsigned int offset, void *buffer, size_t size)
+{
+ struct drm_dp_mst_port *port = container_of(aux, struct
drm_dp_mst_port, aux);
+
+
[RFC 0/2] Add AUX device entries for DP MST devices
From: Leo Li Hi all, This is a follup to this change made by Ville to add MST aux nodes: https://github.com/vsyrjala/linux/commit/cac63f799ee2f5fbbe4f0a375383f13e03d640a5 Patch 2/2 describes what I added on top. Sending as an RFC since there are some items I'm not certain on: 1) Only expose aux devices for physical ports. FWICT, only DPTX and DPRX can handle AUX transactions, leaving logical ports out. 2) Naming of exposed AUX devices. I'm not sure if the scheme implemented here is the best approach. Let me know your thoughts, Leo Leo Li (1): drm/dp_mst: Use non-cyclic idr, add suffix option for aux device Ville Syrjälä (1): drm/dp_mst: Register aux-dev nodes for MST ports drivers/gpu/drm/drm_crtc_helper_internal.h | 5 +- drivers/gpu/drm/drm_dp_aux_dev.c | 21 -- drivers/gpu/drm/drm_dp_helper.c| 2 +- drivers/gpu/drm/drm_dp_mst_topology.c | 109 + include/drm/drm_dp_helper.h| 4 ++ include/drm/drm_dp_mst_helper.h| 6 ++ 6 files changed, 125 insertions(+), 22 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/9] drm/ttm: Allow the driver to provide the ttm struct vm_operations_struct
Add a pointer to the struct vm_operations_struct in the bo_device, and
assign that pointer to the default value currently used.
The driver can then optionally modify that pointer and the new value
can be used for each new vma created.
Cc: "Christian König"
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c| 1 +
drivers/gpu/drm/ttm/ttm_bo_vm.c | 6 +++---
include/drm/ttm/ttm_bo_driver.h | 6 ++
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 3f56647cdb35..1c85bec00472 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1656,6 +1656,7 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
mutex_lock(_global_mutex);
list_add_tail(>device_list, >device_list);
mutex_unlock(_global_mutex);
+ bdev->vm_ops = _bo_vm_ops;
return 0;
out_no_sys:
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index e86a29a1e51f..bfb25b81fed7 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -395,7 +395,7 @@ static int ttm_bo_vm_access(struct vm_area_struct *vma,
unsigned long addr,
return ret;
}
-static const struct vm_operations_struct ttm_bo_vm_ops = {
+const struct vm_operations_struct ttm_bo_vm_ops = {
.fault = ttm_bo_vm_fault,
.open = ttm_bo_vm_open,
.close = ttm_bo_vm_close,
@@ -445,7 +445,7 @@ int ttm_bo_mmap(struct file *filp, struct vm_area_struct
*vma,
if (unlikely(ret != 0))
goto out_unref;
- vma->vm_ops = _bo_vm_ops;
+ vma->vm_ops = bdev->vm_ops;
/*
* Note: We're transferring the bo reference to
@@ -477,7 +477,7 @@ int ttm_fbdev_mmap(struct vm_area_struct *vma, struct
ttm_buffer_object *bo)
ttm_bo_get(bo);
- vma->vm_ops = _bo_vm_ops;
+ vma->vm_ops = bo->bdev->vm_ops;
vma->vm_private_data = bo;
vma->vm_flags |= VM_MIXEDMAP;
vma->vm_flags |= VM_IO | VM_DONTEXPAND;
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index cbf3180cb612..cfeaff5d9706 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -443,6 +443,9 @@ extern struct ttm_bo_global {
* @driver: Pointer to a struct ttm_bo_driver struct setup by the driver.
* @man: An array of mem_type_managers.
* @vma_manager: Address space manager
+ * @vm_ops: Pointer to the struct vm_operations_struct used for this
+ * device's VM operations. The driver may override this before the first
+ * mmap() call.
* lru_lock: Spinlock that protects the buffer+device lru lists and
* ddestroy lists.
* @dev_mapping: A pointer to the struct address_space representing the
@@ -461,6 +464,7 @@ struct ttm_bo_device {
struct ttm_bo_global *glob;
struct ttm_bo_driver *driver;
struct ttm_mem_type_manager man[TTM_NUM_MEM_TYPES];
+ const struct vm_operations_struct *vm_ops;
/*
* Protected by internal locks.
@@ -489,6 +493,8 @@ struct ttm_bo_device {
bool no_retry;
};
+extern const struct vm_operations_struct ttm_bo_vm_ops;
+
/**
* struct ttm_lru_bulk_move_pos
*
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/9] mm: Add write-protect and clean utilities for address space ranges
Add two utilities to a) write-protect and b) clean all ptes pointing into
a range of an address space
The utilities are intended to aid in tracking dirty pages (either
driver-allocated system memory or pci device memory).
The write-protect utility should be used in conjunction with
page_mkwrite() and pfn_mkwrite() to trigger write page-faults on page
accesses. Typically one would want to use this on sparse accesses into
large memory regions. The clean utility should be used to utilize
hardware dirtying functionality and avoid the overhead of page-faults,
typically on large accesses into small memory regions.
The added file "apply_as_range.c" is initially listed as maintained by
VMware under our DRM driver. If somebody would like it elsewhere,
that's of course no problem.
Notable changes since RFC:
- Added comments to help avoid the usage of these function for VMAs
it's not intended for. We also do advisory checks on the vm_flags and
warn on illegal usage.
- Perform the pte modifications the same way softdirty does.
- Add mmu_notifier range invalidation calls.
- Add a config option so that this code is not unconditionally included.
- Tell the mmu_gather code about pending tlb flushes.
Cc: Andrew Morton
Cc: Matthew Wilcox
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Minchan Kim
Cc: Michal Hocko
Cc: Huang Ying
Cc: Souptick Joarder
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Thomas Hellstrom
---
MAINTAINERS | 1 +
include/linux/mm.h | 9 +-
mm/Kconfig | 3 +
mm/Makefile | 3 +-
mm/apply_as_range.c | 295
5 files changed, 309 insertions(+), 2 deletions(-)
create mode 100644 mm/apply_as_range.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 35e6357f9d30..bc243ffcb840 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4971,6 +4971,7 @@ T:git git://people.freedesktop.org/~thomash/linux
S: Supported
F: drivers/gpu/drm/vmwgfx/
F: include/uapi/drm/vmwgfx_drm.h
+F: mm/apply_as_range.c
DRM DRIVERS
M: David Airlie
diff --git a/include/linux/mm.h b/include/linux/mm.h
index b7dd4ddd6efb..62f24dd0bfa0 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2642,7 +2642,14 @@ struct pfn_range_apply {
};
extern int apply_to_pfn_range(struct pfn_range_apply *closure,
unsigned long address, unsigned long size);
-
+unsigned long apply_as_wrprotect(struct address_space *mapping,
+pgoff_t first_index, pgoff_t nr);
+unsigned long apply_as_clean(struct address_space *mapping,
+pgoff_t first_index, pgoff_t nr,
+pgoff_t bitmap_pgoff,
+unsigned long *bitmap,
+pgoff_t *start,
+pgoff_t *end);
#ifdef CONFIG_PAGE_POISONING
extern bool page_poisoning_enabled(void);
extern void kernel_poison_pages(struct page *page, int numpages, int enable);
diff --git a/mm/Kconfig b/mm/Kconfig
index 25c71eb8a7db..80e41cdbb4ae 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -758,4 +758,7 @@ config GUP_BENCHMARK
config ARCH_HAS_PTE_SPECIAL
bool
+config AS_DIRTY_HELPERS
+bool
+
endmenu
diff --git a/mm/Makefile b/mm/Makefile
index d210cc9d6f80..b295717be856 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -39,7 +39,7 @@ obj-y := filemap.o mempool.o oom_kill.o
fadvise.o \
mm_init.o mmu_context.o percpu.o slab_common.o \
compaction.o vmacache.o \
interval_tree.o list_lru.o workingset.o \
- debug.o $(mmu-y)
+ debug.o apply_as_range.o $(mmu-y)
obj-y += init-mm.o
obj-y += memblock.o
@@ -99,3 +99,4 @@ obj-$(CONFIG_HARDENED_USERCOPY) += usercopy.o
obj-$(CONFIG_PERCPU_STATS) += percpu-stats.o
obj-$(CONFIG_HMM) += hmm.o
obj-$(CONFIG_MEMFD_CREATE) += memfd.o
+obj-$(CONFIG_AS_DIRTY_HELPERS) += apply_as_range.o
diff --git a/mm/apply_as_range.c b/mm/apply_as_range.c
new file mode 100644
index ..32d28619aec5
--- /dev/null
+++ b/mm/apply_as_range.c
@@ -0,0 +1,295 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * struct apply_as - Closure structure for apply_as_range
+ * @base: struct pfn_range_apply we derive from
+ * @start: Address of first modified pte
+ * @end: Address of last modified pte + 1
+ * @total: Total number of modified ptes
+ * @vma: Pointer to the struct vm_area_struct we're currently operating on
+ */
+struct apply_as {
+ struct pfn_range_apply base;
+ unsigned long start, end;
+ unsigned long total;
+ const struct vm_area_struct *vma;
+};
+
+/**
+ * apply_pt_wrprotect - Leaf pte callback to write-protect a pte
+ * @pte: Pointer to the pte
+ * @token: Page table token, see
[PATCH 8/9] drm/vmwgfx: Implement an infrastructure for read-coherent resources
Similar to write-coherent resources, make sure that from the user-space
point of view, GPU rendered contents is automatically available for
reading by the CPU.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 8 +-
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c| 69 +++-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 102 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource_priv.h | 2 +
drivers/gpu/drm/vmwgfx/vmwgfx_validation.c| 3 +-
6 files changed, 176 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 3bd28fb97124..0065b138f450 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -42,6 +42,7 @@
#include
#include
+
static vm_fault_t ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo,
struct vm_fault *vmf)
{
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 81ebcd668038..00794415335e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -96,6 +96,7 @@ struct vmw_fpriv {
* @map: Kmap object for semi-persistent mappings
* @res_prios: Eviction priority counts for attached resources
* @dirty: structure for user-space dirty-tracking
+ * @cleaning: Current validation sequence is cleaning.
*/
struct vmw_buffer_object {
struct ttm_buffer_object base;
@@ -690,7 +691,8 @@ extern void vmw_resource_unreference(struct vmw_resource
**p_res);
extern struct vmw_resource *vmw_resource_reference(struct vmw_resource *res);
extern struct vmw_resource *
vmw_resource_reference_unless_doomed(struct vmw_resource *res);
-extern int vmw_resource_validate(struct vmw_resource *res, bool intr);
+extern int vmw_resource_validate(struct vmw_resource *res, bool intr,
+bool dirtying);
extern int vmw_resource_reserve(struct vmw_resource *res, bool interruptible,
bool no_backup);
extern bool vmw_resource_needs_backup(const struct vmw_resource *res);
@@ -734,6 +736,8 @@ void vmw_resource_mob_attach(struct vmw_resource *res);
void vmw_resource_mob_detach(struct vmw_resource *res);
void vmw_resource_dirty_update(struct vmw_resource *res, pgoff_t start,
pgoff_t end);
+int vmw_resources_clean(struct vmw_buffer_object *vbo, pgoff_t start,
+ pgoff_t end, pgoff_t *num_prefault);
/**
* vmw_resource_mob_attached - Whether a resource currently has a mob attached
@@ -1428,6 +1432,8 @@ int vmw_bo_dirty_add(struct vmw_buffer_object *vbo);
void vmw_bo_dirty_transfer_to_res(struct vmw_resource *res);
void vmw_bo_dirty_clear_res(struct vmw_resource *res);
void vmw_bo_dirty_release(struct vmw_buffer_object *vbo);
+void vmw_bo_dirty_unmap(struct vmw_buffer_object *vbo,
+ pgoff_t start, pgoff_t end);
vm_fault_t vmw_bo_vm_fault(struct vm_fault *vmf);
vm_fault_t vmw_bo_vm_mkwrite(struct vm_fault *vmf);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c
index 87e4a73b1175..773ff30a4b60 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c
@@ -153,7 +153,6 @@ static void vmw_bo_dirty_scan_mkwrite(struct
vmw_buffer_object *vbo)
}
}
-
/**
* vmw_bo_dirty_scan - Scan for dirty pages and add them to the dirty
* tracking structure
@@ -171,6 +170,51 @@ void vmw_bo_dirty_scan(struct vmw_buffer_object *vbo)
vmw_bo_dirty_scan_mkwrite(vbo);
}
+/**
+ * vmw_bo_dirty_pre_unmap - write-protect and pick up dirty pages before
+ * an unmap_mapping_range operation.
+ * @vbo: The buffer object,
+ * @start: First page of the range within the buffer object.
+ * @end: Last page of the range within the buffer object + 1.
+ *
+ * If we're using the _PAGETABLE scan method, we may leak dirty pages
+ * when calling unmap_mapping_range(). This function makes sure we pick
+ * up all dirty pages.
+ */
+static void vmw_bo_dirty_pre_unmap(struct vmw_buffer_object *vbo,
+ pgoff_t start, pgoff_t end)
+{
+ struct vmw_bo_dirty *dirty = vbo->dirty;
+ unsigned long offset = drm_vma_node_start(>base.vma_node);
+ struct address_space *mapping = vbo->base.bdev->dev_mapping;
+
+ if (dirty->method != VMW_BO_DIRTY_PAGETABLE || start >= end)
+ return;
+
+ apply_as_wrprotect(mapping, start + offset, end - start);
+ apply_as_clean(mapping, start + offset, end - start, offset,
+ >bitmap[0], >start, >end);
+}
+
+/**
+ * vmw_bo_dirty_unmap - Clear all ptes pointing to a range within a bo
+ * @vbo: The buffer object,
+ * @start: First page of the range within the buffer object.
+ * @end: Last page of the range within the buffer object + 1.
+ *
+ * This is similar to
[PATCH 9/9] drm/vmwgfx: Add surface dirty-tracking callbacks
Add the callbacks necessary to implement emulated coherent memory for
surfaces. Add a flag to the gb_surface_create ioctl to indicate that
surface memory should be coherent.
Also bump the drm minor version to signal the availability of coherent
surfaces.
Signed-off-by: Thomas Hellstrom
---
.../device_include/svga3d_surfacedefs.h | 209 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 390 +-
include/uapi/drm/vmwgfx_drm.h | 4 +-
4 files changed, 600 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/device_include/svga3d_surfacedefs.h
b/drivers/gpu/drm/vmwgfx/device_include/svga3d_surfacedefs.h
index f2bfd3d80598..d901206c04e3 100644
--- a/drivers/gpu/drm/vmwgfx/device_include/svga3d_surfacedefs.h
+++ b/drivers/gpu/drm/vmwgfx/device_include/svga3d_surfacedefs.h
@@ -1280,7 +1280,6 @@ svga3dsurface_get_pixel_offset(SVGA3dSurfaceFormat format,
return offset;
}
-
static inline u32
svga3dsurface_get_image_offset(SVGA3dSurfaceFormat format,
surf_size_struct baseLevelSize,
@@ -1375,4 +1374,212 @@
svga3dsurface_is_screen_target_format(SVGA3dSurfaceFormat format)
return svga3dsurface_is_dx_screen_target_format(format);
}
+/**
+ * struct svga3dsurface_mip - Mimpmap level information
+ * @bytes: Bytes required in the backing store of this mipmap level.
+ * @img_stride: Byte stride per image.
+ * @row_stride: Byte stride per block row.
+ * @size: The size of the mipmap.
+ */
+struct svga3dsurface_mip {
+ size_t bytes;
+ size_t img_stride;
+ size_t row_stride;
+ struct drm_vmw_size size;
+
+};
+
+/**
+ * struct svga3dsurface_cache - Cached surface information
+ * @desc: Pointer to the surface descriptor
+ * @mip: Array of mipmap level information. Valid size is @num_mip_levels.
+ * @mip_chain_bytes: Bytes required in the backing store for the whole chain
+ * of mip levels.
+ * @num_mip_levels: Valid size of the @mip array. Number of mipmap levels in
+ * a chain.
+ * @num_layers: Number of slices in an array texture or number of faces in
+ * a cubemap texture.
+ */
+struct svga3dsurface_cache {
+ const struct svga3d_surface_desc *desc;
+ struct svga3dsurface_mip mip[DRM_VMW_MAX_MIP_LEVELS];
+ size_t mip_chain_bytes;
+ u32 num_mip_levels;
+ u32 num_layers;
+};
+
+/**
+ * struct svga3dsurface_loc - Surface location
+ * @sub_resource: Surface subresource. Defined as layer * num_mip_levels +
+ * mip_level.
+ * @x: X coordinate.
+ * @y: Y coordinate.
+ * @z: Z coordinate.
+ */
+struct svga3dsurface_loc {
+ u32 sub_resource;
+ u32 x, y, z;
+};
+
+/**
+ * svga3dsurface_subres - Compute the subresource from layer and mipmap.
+ * @cache: Surface layout data.
+ * @mip_level: The mipmap level.
+ * @layer: The surface layer (face or array slice).
+ *
+ * Return: The subresource.
+ */
+static inline u32 svga3dsurface_subres(const struct svga3dsurface_cache *cache,
+ u32 mip_level, u32 layer)
+{
+ return cache->num_mip_levels * layer + mip_level;
+}
+
+/**
+ * svga3dsurface_setup_cache - Build a surface cache entry
+ * @size: The surface base level dimensions.
+ * @format: The surface format.
+ * @num_mip_levels: Number of mipmap levels.
+ * @num_layers: Number of layers.
+ * @cache: Pointer to a struct svga3dsurface_cach object to be filled in.
+ */
+static inline void svga3dsurface_setup_cache(const struct drm_vmw_size *size,
+SVGA3dSurfaceFormat format,
+u32 num_mip_levels,
+u32 num_layers,
+u32 num_samples,
+struct svga3dsurface_cache *cache)
+{
+ const struct svga3d_surface_desc *desc;
+ u32 i;
+
+ memset(cache, 0, sizeof(*cache));
+ cache->desc = desc = svga3dsurface_get_desc(format);
+ cache->num_mip_levels = num_mip_levels;
+ cache->num_layers = num_layers;
+ for (i = 0; i < cache->num_mip_levels; i++) {
+ struct svga3dsurface_mip *mip = >mip[i];
+
+ mip->size = svga3dsurface_get_mip_size(*size, i);
+ mip->bytes = svga3dsurface_get_image_buffer_size
+ (desc, >size, 0) * num_samples;
+ mip->row_stride =
+ __KERNEL_DIV_ROUND_UP(mip->size.width,
+ desc->block_size.width) *
+ desc->bytes_per_block * num_samples;
+ mip->img_stride =
+ __KERNEL_DIV_ROUND_UP(mip->size.height,
+ desc->block_size.height) *
+ mip->row_stride;
+ cache->mip_chain_bytes += mip->bytes;
+ }
+}
+
+/**
+ * svga3dsurface_get_loc - Get
[PATCH 6/9] drm/vmwgfx: Implement an infrastructure for write-coherent resources
This infrastructure will, for coherent resources, make sure that
from the user-space point of view, data written by the CPU is immediately
automatically available to the GPU at resource validation time.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/Kconfig| 1 +
drivers/gpu/drm/vmwgfx/Makefile | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 5 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 5 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 26 +-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 1 -
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c| 410 ++
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 57 +++
drivers/gpu/drm/vmwgfx/vmwgfx_resource_priv.h | 11 +
drivers/gpu/drm/vmwgfx/vmwgfx_validation.c| 74
drivers/gpu/drm/vmwgfx/vmwgfx_validation.h| 16 +-
11 files changed, 588 insertions(+), 20 deletions(-)
create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c
diff --git a/drivers/gpu/drm/vmwgfx/Kconfig b/drivers/gpu/drm/vmwgfx/Kconfig
index 6b28a326f8bb..d5fd81a521f6 100644
--- a/drivers/gpu/drm/vmwgfx/Kconfig
+++ b/drivers/gpu/drm/vmwgfx/Kconfig
@@ -8,6 +8,7 @@ config DRM_VMWGFX
select FB_CFB_IMAGEBLIT
select DRM_TTM
select FB
+ select AS_DIRTY_HELPERS
# Only needed for the transitional use of drm_crtc_init - can be removed
# again once vmwgfx sets up the primary plane itself.
select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
index 8841bd30e1e5..c877a21a0739 100644
--- a/drivers/gpu/drm/vmwgfx/Makefile
+++ b/drivers/gpu/drm/vmwgfx/Makefile
@@ -8,7 +8,7 @@ vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o
vmwgfx_drv.o \
vmwgfx_cmdbuf_res.o vmwgfx_cmdbuf.o vmwgfx_stdu.o \
vmwgfx_cotable.o vmwgfx_so.o vmwgfx_binding.o vmwgfx_msg.o \
vmwgfx_simple_resource.o vmwgfx_va.o vmwgfx_blit.o \
- vmwgfx_validation.o \
+ vmwgfx_validation.o vmwgfx_page_dirty.o \
ttm_object.o ttm_lock.o
obj-$(CONFIG_DRM_VMWGFX) := vmwgfx.o
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index c0829d50eecc..90ca866640fe 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -463,6 +463,7 @@ void vmw_bo_bo_free(struct ttm_buffer_object *bo)
{
struct vmw_buffer_object *vmw_bo = vmw_buffer_object(bo);
+ WARN_ON(vmw_bo->dirty);
vmw_bo_unmap(vmw_bo);
kfree(vmw_bo);
}
@@ -476,8 +477,10 @@ void vmw_bo_bo_free(struct ttm_buffer_object *bo)
static void vmw_user_bo_destroy(struct ttm_buffer_object *bo)
{
struct vmw_user_buffer_object *vmw_user_bo = vmw_user_buffer_object(bo);
+ struct vmw_buffer_object *vbo = _user_bo->vbo;
- vmw_bo_unmap(_user_bo->vbo);
+ WARN_ON(vbo->dirty);
+ vmw_bo_unmap(vbo);
ttm_prime_object_kfree(vmw_user_bo, prime);
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 6165fe2c4504..74e94138877e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -857,6 +857,11 @@ static int vmw_driver_load(struct drm_device *dev,
unsigned long chipset)
DRM_ERROR("Failed initializing TTM buffer object driver.\n");
goto out_no_bdev;
}
+ dev_priv->vm_ops = *dev_priv->bdev.vm_ops;
+ dev_priv->vm_ops.fault = vmw_bo_vm_fault;
+ dev_priv->vm_ops.pfn_mkwrite = vmw_bo_vm_mkwrite;
+ dev_priv->vm_ops.page_mkwrite = vmw_bo_vm_mkwrite;
+ dev_priv->bdev.vm_ops = _priv->vm_ops;
/*
* Enable VRAM, but initially don't use it until SVGA is enabled and
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index bd6919b90519..f05fce52fbb4 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -95,6 +95,7 @@ struct vmw_fpriv {
* @dx_query_ctx: DX context if this buffer object is used as a DX query MOB
* @map: Kmap object for semi-persistent mappings
* @res_prios: Eviction priority counts for attached resources
+ * @dirty: structure for user-space dirty-tracking
*/
struct vmw_buffer_object {
struct ttm_buffer_object base;
@@ -105,6 +106,7 @@ struct vmw_buffer_object {
/* Protected by reservation */
struct ttm_bo_kmap_obj map;
u32 res_prios[TTM_MAX_BO_PRIORITY];
+ struct vmw_bo_dirty *dirty;
};
/**
@@ -135,7 +137,8 @@ struct vmw_res_func;
* @res_dirty: Resource contains data not yet in the backup buffer. Protected
* by resource reserved.
* @backup_dirty: Backup buffer contains data not yet in the HW resource.
- * Protecte by resource reserved.
+ * Protected by resource reserved.
+ * @coherent: Emulate coherency by tracking vm accesses.
* @backup: The backup buffer if any. Protected by resource reserved.
*
[PATCH 5/9] drm/ttm: TTM fault handler helpers
With the vmwgfx dirty tracking, the default TTM fault handler is not
completely sufficient (vmwgfx need to modify the vma->vm_flags member,
and also needs to restrict the number of prefaults).
We also want to replicate the new ttm_bo_vm_reserve() functionality
So start turning the TTM vm code into helpers: ttm_bo_vm_fault_reserved()
and ttm_bo_vm_reserve(), and provide a default TTM fault handler for other
drivers to use.
Cc: "Christian König"
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 170
include/drm/ttm/ttm_bo_api.h| 10 ++
2 files changed, 116 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index bfb25b81fed7..3bd28fb97124 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -42,8 +42,6 @@
#include
#include
-#define TTM_BO_VM_NUM_PREFAULT 16
-
static vm_fault_t ttm_bo_vm_fault_idle(struct ttm_buffer_object *bo,
struct vm_fault *vmf)
{
@@ -106,31 +104,30 @@ static unsigned long ttm_bo_io_mem_pfn(struct
ttm_buffer_object *bo,
+ page_offset;
}
-static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
+/**
+ * ttm_bo_vm_reserve - Reserve a buffer object in a retryable vm callback
+ * @bo: The buffer object
+ * @vmf: The fault structure handed to the callback
+ *
+ * vm callbacks like fault() and *_mkwrite() allow for the mm_sem to be dropped
+ * during long waits, and after the wait the callback will be restarted. This
+ * is to allow other threads using the same virtual memory space concurrent
+ * access to map(), unmap() completely unrelated buffer objects. TTM buffer
+ * object reservations sometimes wait for GPU and should therefore be
+ * considered long waits. This function reserves the buffer object
interruptibly
+ * taking this into account. Starvation is avoided by the vm system not
+ * allowing too many repeated restarts.
+ * This function is intended to be used in customized fault() and _mkwrite()
+ * handlers.
+ *
+ * Return:
+ *0 on success and the bo was reserved.
+ *VM_FAULT_RETRY if blocking wait.
+ *VM_FAULT_NOPAGE if blocking wait and retrying was not allowed.
+ */
+vm_fault_t ttm_bo_vm_reserve(struct ttm_buffer_object *bo,
+struct vm_fault *vmf)
{
- struct vm_area_struct *vma = vmf->vma;
- struct ttm_buffer_object *bo = (struct ttm_buffer_object *)
- vma->vm_private_data;
- struct ttm_bo_device *bdev = bo->bdev;
- unsigned long page_offset;
- unsigned long page_last;
- unsigned long pfn;
- struct ttm_tt *ttm = NULL;
- struct page *page;
- int err;
- int i;
- vm_fault_t ret = VM_FAULT_NOPAGE;
- unsigned long address = vmf->address;
- struct ttm_mem_type_manager *man =
- >man[bo->mem.mem_type];
- struct vm_area_struct cvma;
-
- /*
-* Work around locking order reversal in fault / nopfn
-* between mmap_sem and bo_reserve: Perform a trylock operation
-* for reserve, and if it fails, retry the fault after waiting
-* for the buffer to become unreserved.
-*/
if (unlikely(!reservation_object_trylock(bo->resv))) {
if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
if (!(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) {
@@ -151,14 +148,56 @@ static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
return VM_FAULT_NOPAGE;
}
+ return 0;
+}
+EXPORT_SYMBOL(ttm_bo_vm_reserve);
+
+/**
+ * ttm_bo_vm_fault_reserved - TTM fault helper
+ * @vmf: The struct vm_fault given as argument to the fault callback
+ * @cvma: The struct vmw_area_struct affected. Note that this may be a
+ * copy of the real vma object if the caller needs, for example, VM
+ * flags to be temporarily altered while determining the page protection.
+ * @num_prefault: Maximum number of prefault pages. The caller may want to
+ * specify this based on madvice settings and the size of the GPU object
+ * backed by the memory.
+ *
+ * This function inserts one or more page table entries pointing to the
+ * memory backing the buffer object, and then returns a return code
+ * instructing the caller to retry the page access.
+ *
+ * Return:
+ * VM_FAULT_NOPAGE on success or pending signal
+ * VM_FAULT_SIGBUS on unspecified error
+ * VM_FAULT_OOM on out-of-memory
+ * VM_FAULT_RETRY if retryable wait
+ */
+vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
+ struct vm_area_struct *cvma,
+ pgoff_t num_prefault)
+{
+ struct vm_area_struct *vma = vmf->vma;
+ struct ttm_buffer_object *bo = (struct ttm_buffer_object *)
+ vma->vm_private_data;
+ struct ttm_bo_device *bdev = bo->bdev;
+ unsigned long page_offset;
+ unsigned long page_last;
+ unsigned long
[PATCH 7/9] drm/vmwgfx: Use an RBtree instead of linked list for MOB resources
With emulated coherent memory we need to be able to quickly look up
a resource from the MOB offset. Instead of traversing a linked list with
O(n) worst case, use an RBtree with O(log n) worst case complexity.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 5 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 10 +++
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 33 +---
3 files changed, 32 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index 90ca866640fe..e8bc7a7ac031 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -464,6 +464,7 @@ void vmw_bo_bo_free(struct ttm_buffer_object *bo)
struct vmw_buffer_object *vmw_bo = vmw_buffer_object(bo);
WARN_ON(vmw_bo->dirty);
+ WARN_ON(!RB_EMPTY_ROOT(_bo->res_tree));
vmw_bo_unmap(vmw_bo);
kfree(vmw_bo);
}
@@ -480,6 +481,7 @@ static void vmw_user_bo_destroy(struct ttm_buffer_object
*bo)
struct vmw_buffer_object *vbo = _user_bo->vbo;
WARN_ON(vbo->dirty);
+ WARN_ON(!RB_EMPTY_ROOT(>res_tree));
vmw_bo_unmap(vbo);
ttm_prime_object_kfree(vmw_user_bo, prime);
}
@@ -515,8 +517,7 @@ int vmw_bo_init(struct vmw_private *dev_priv,
memset(vmw_bo, 0, sizeof(*vmw_bo));
BUILD_BUG_ON(TTM_MAX_BO_PRIORITY <= 3);
vmw_bo->base.priority = 3;
-
- INIT_LIST_HEAD(_bo->res_list);
+ vmw_bo->res_tree = RB_ROOT;
ret = ttm_bo_init(bdev, _bo->base, size,
ttm_bo_type_device, placement,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index f05fce52fbb4..81ebcd668038 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -90,7 +90,7 @@ struct vmw_fpriv {
/**
* struct vmw_buffer_object - TTM buffer object with vmwgfx additions
* @base: The TTM buffer object
- * @res_list: List of resources using this buffer object as a backing MOB
+ * @res_tree: RB tree of resources using this buffer object as a backing MOB
* @pin_count: pin depth
* @dx_query_ctx: DX context if this buffer object is used as a DX query MOB
* @map: Kmap object for semi-persistent mappings
@@ -99,7 +99,7 @@ struct vmw_fpriv {
*/
struct vmw_buffer_object {
struct ttm_buffer_object base;
- struct list_head res_list;
+ struct rb_root res_tree;
s32 pin_count;
/* Not ref-counted. Protected by binding_mutex */
struct vmw_resource *dx_query_ctx;
@@ -147,8 +147,8 @@ struct vmw_res_func;
* pin-count greater than zero. It is not on the resource LRU lists and its
* backup buffer is pinned. Hence it can't be evicted.
* @func: Method vtable for this resource. Immutable.
+ * @mob_node; Node for the MOB backup rbtree. Protected by @backup reserved.
* @lru_head: List head for the LRU list. Protected by
@dev_priv::resource_lock.
- * @mob_head: List head for the MOB backup list. Protected by @backup reserved.
* @binding_head: List head for the context binding list. Protected by
* the @dev_priv::binding_mutex
* @res_free: The resource destructor.
@@ -169,8 +169,8 @@ struct vmw_resource {
unsigned long backup_offset;
unsigned long pin_count;
const struct vmw_res_func *func;
+ struct rb_node mob_node;
struct list_head lru_head;
- struct list_head mob_head;
struct list_head binding_head;
struct vmw_resource_dirty *dirty;
void (*res_free) (struct vmw_resource *res);
@@ -743,7 +743,7 @@ void vmw_resource_dirty_update(struct vmw_resource *res,
pgoff_t start,
*/
static inline bool vmw_resource_mob_attached(const struct vmw_resource *res)
{
- return !list_empty(>mob_head);
+ return !RB_EMPTY_NODE(>mob_node);
}
/**
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index d35f4bd32cd9..ff9fe5650468 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -41,11 +41,24 @@
void vmw_resource_mob_attach(struct vmw_resource *res)
{
struct vmw_buffer_object *backup = res->backup;
+ struct rb_node **new = >res_tree.rb_node, *parent = NULL;
lockdep_assert_held(>base.resv->lock.base);
res->used_prio = (res->res_dirty) ? res->func->dirty_prio :
res->func->prio;
- list_add_tail(>mob_head, >res_list);
+
+ while (*new) {
+ struct vmw_resource *this =
+ container_of(*new, struct vmw_resource, mob_node);
+
+ parent = *new;
+ new = (res->backup_offset < this->backup_offset) ?
+ &((*new)->rb_left) : &((*new)->rb_right);
+ }
+
+ rb_link_node(>mob_node, parent, new);
+ rb_insert_color(>mob_node, >res_tree);
+
vmw_bo_prio_add(backup, res->used_prio);
}
@@ -59,7 +72,8
[PATCH 2/9] mm: Add an apply_to_pfn_range interface
This is basically apply_to_page_range with added functionality:
Allocating missing parts of the page table becomes optional, which
means that the function can be guaranteed not to error if allocation
is disabled. Also passing of the closure struct and callback function
becomes different and more in line with how things are done elsewhere.
Finally we keep apply_to_page_range as a wrapper around apply_to_pfn_range
The reason for not using the page-walk code is that we want to perform
the page-walk on vmas pointing to an address space without requiring the
mmap_sem to be held rather thand on vmas belonging to a process with the
mmap_sem held.
Notable changes since RFC:
Don't export apply_to_pfn range.
Cc: Andrew Morton
Cc: Matthew Wilcox
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Minchan Kim
Cc: Michal Hocko
Cc: Huang Ying
Cc: Souptick Joarder
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Thomas Hellstrom
---
include/linux/mm.h | 10
mm/memory.c| 130 ++---
2 files changed, 108 insertions(+), 32 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 80bb6408fe73..b7dd4ddd6efb 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2632,6 +2632,16 @@ typedef int (*pte_fn_t)(pte_t *pte, pgtable_t token,
unsigned long addr,
extern int apply_to_page_range(struct mm_struct *mm, unsigned long address,
unsigned long size, pte_fn_t fn, void *data);
+struct pfn_range_apply;
+typedef int (*pter_fn_t)(pte_t *pte, pgtable_t token, unsigned long addr,
+struct pfn_range_apply *closure);
+struct pfn_range_apply {
+ struct mm_struct *mm;
+ pter_fn_t ptefn;
+ unsigned int alloc;
+};
+extern int apply_to_pfn_range(struct pfn_range_apply *closure,
+ unsigned long address, unsigned long size);
#ifdef CONFIG_PAGE_POISONING
extern bool page_poisoning_enabled(void);
diff --git a/mm/memory.c b/mm/memory.c
index a95b4a3b1ae2..60d67158964f 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1938,18 +1938,17 @@ int vm_iomap_memory(struct vm_area_struct *vma,
phys_addr_t start, unsigned long
}
EXPORT_SYMBOL(vm_iomap_memory);
-static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
-unsigned long addr, unsigned long end,
-pte_fn_t fn, void *data)
+static int apply_to_pte_range(struct pfn_range_apply *closure, pmd_t *pmd,
+ unsigned long addr, unsigned long end)
{
pte_t *pte;
int err;
pgtable_t token;
spinlock_t *uninitialized_var(ptl);
- pte = (mm == _mm) ?
+ pte = (closure->mm == _mm) ?
pte_alloc_kernel(pmd, addr) :
- pte_alloc_map_lock(mm, pmd, addr, );
+ pte_alloc_map_lock(closure->mm, pmd, addr, );
if (!pte)
return -ENOMEM;
@@ -1960,86 +1959,107 @@ static int apply_to_pte_range(struct mm_struct *mm,
pmd_t *pmd,
token = pmd_pgtable(*pmd);
do {
- err = fn(pte++, token, addr, data);
+ err = closure->ptefn(pte++, token, addr, closure);
if (err)
break;
} while (addr += PAGE_SIZE, addr != end);
arch_leave_lazy_mmu_mode();
- if (mm != _mm)
+ if (closure->mm != _mm)
pte_unmap_unlock(pte-1, ptl);
return err;
}
-static int apply_to_pmd_range(struct mm_struct *mm, pud_t *pud,
-unsigned long addr, unsigned long end,
-pte_fn_t fn, void *data)
+static int apply_to_pmd_range(struct pfn_range_apply *closure, pud_t *pud,
+ unsigned long addr, unsigned long end)
{
pmd_t *pmd;
unsigned long next;
- int err;
+ int err = 0;
BUG_ON(pud_huge(*pud));
- pmd = pmd_alloc(mm, pud, addr);
+ pmd = pmd_alloc(closure->mm, pud, addr);
if (!pmd)
return -ENOMEM;
+
do {
next = pmd_addr_end(addr, end);
- err = apply_to_pte_range(mm, pmd, addr, next, fn, data);
+ if (!closure->alloc && pmd_none_or_clear_bad(pmd))
+ continue;
+ err = apply_to_pte_range(closure, pmd, addr, next);
if (err)
break;
} while (pmd++, addr = next, addr != end);
return err;
}
-static int apply_to_pud_range(struct mm_struct *mm, p4d_t *p4d,
-unsigned long addr, unsigned long end,
-pte_fn_t fn, void *data)
+static int apply_to_pud_range(struct pfn_range_apply *closure, p4d_t *p4d,
+ unsigned long addr, unsigned long end)
{
pud_t *pud;
unsigned
[PATCH 0/9] Emulated coherent graphics memory
Graphics APIs like OpenGL 4.4 and Vulkan require the graphics driver to provide coherent graphics memory, meaning that the GPU sees any content written to the coherent memory on the next GPU operation that touches that memory, and the CPU sees any content written by the GPU to that memory immediately after any fence object trailing the GPU operation has signaled. Paravirtual drivers that otherwise require explicit synchronization needs to do this by hooking up dirty tracking to pagefault handlers and buffer object validation. This is a first attempt to do that for the vmwgfx driver. The mm patches has been out for RFC. I think I have addressed all the feedback I got, except a possible softdirty breakage. But although the dirty-tracking and softdirty may write-protect PTEs both care about, that shouldn't really cause any operation interference. In particular since we use the hardware dirty PTE bits and softdirty uses other PTE bits. For the TTM changes they are hopefully in line with the long-term strategy of making helpers out of what's left of TTM. The code has been tested and excercised by a tailored version of mesa where we disable all explicit synchronization and assume graphics memory is coherent. The performance loss varies of course; a typical number is around 5%. Any feedback greatly appreciated. Cc: Andrew Morton Cc: Matthew Wilcox Cc: Will Deacon Cc: Peter Zijlstra Cc: Rik van Riel Cc: Minchan Kim Cc: Michal Hocko Cc: Huang Ying Cc: Souptick Joarder Cc: "Jérôme Glisse" Cc: "Christian König" Cc: linux...@kvack.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/9] mm: Allow the [page|pfn]_mkwrite callbacks to drop the mmap_sem
Driver fault callbacks are allowed to drop the mmap_sem when expecting
long hardware waits to avoid blocking other mm users. Allow the mkwrite
callbacks to do the same by returning early on VM_FAULT_RETRY.
In particular we want to be able to drop the mmap_sem when waiting for
a reservation object lock on a GPU buffer object. These locks may be
held while waiting for the GPU.
Cc: Andrew Morton
Cc: Matthew Wilcox
Cc: Will Deacon
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Minchan Kim
Cc: Michal Hocko
Cc: Huang Ying
Cc: Souptick Joarder
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Thomas Hellstrom
---
mm/memory.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index e11ca9dd823f..a95b4a3b1ae2 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2144,7 +2144,7 @@ static vm_fault_t do_page_mkwrite(struct vm_fault *vmf)
ret = vmf->vma->vm_ops->page_mkwrite(vmf);
/* Restore original flags so that caller is not surprised */
vmf->flags = old_flags;
- if (unlikely(ret & (VM_FAULT_ERROR | VM_FAULT_NOPAGE)))
+ if (unlikely(ret & (VM_FAULT_ERROR | VM_FAULT_RETRY | VM_FAULT_NOPAGE)))
return ret;
if (unlikely(!(ret & VM_FAULT_LOCKED))) {
lock_page(page);
@@ -2419,7 +2419,7 @@ static vm_fault_t wp_pfn_shared(struct vm_fault *vmf)
pte_unmap_unlock(vmf->pte, vmf->ptl);
vmf->flags |= FAULT_FLAG_MKWRITE;
ret = vma->vm_ops->pfn_mkwrite(vmf);
- if (ret & (VM_FAULT_ERROR | VM_FAULT_NOPAGE))
+ if (ret & (VM_FAULT_ERROR | VM_FAULT_RETRY | VM_FAULT_NOPAGE))
return ret;
return finish_mkwrite_fault(vmf);
}
@@ -2440,7 +2440,8 @@ static vm_fault_t wp_page_shared(struct vm_fault *vmf)
pte_unmap_unlock(vmf->pte, vmf->ptl);
tmp = do_page_mkwrite(vmf);
if (unlikely(!tmp || (tmp &
- (VM_FAULT_ERROR | VM_FAULT_NOPAGE {
+ (VM_FAULT_ERROR | VM_FAULT_RETRY |
+ VM_FAULT_NOPAGE {
put_page(vmf->page);
return tmp;
}
@@ -3494,7 +3495,8 @@ static vm_fault_t do_shared_fault(struct vm_fault *vmf)
unlock_page(vmf->page);
tmp = do_page_mkwrite(vmf);
if (unlikely(!tmp ||
- (tmp & (VM_FAULT_ERROR | VM_FAULT_NOPAGE {
+ (tmp & (VM_FAULT_ERROR | VM_FAULT_RETRY |
+ VM_FAULT_NOPAGE {
put_page(vmf->page);
return tmp;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/5] drm/modes: Rewrite the command line parser
Hi Maxime,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.1-rc4 next-20190412]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Maxime-Ripard/drm-modes-Rewrite-the-command-line-parser/20190412-122837
config: x86_64-randconfig-s1-04121728 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
Note: the
linux-review/Maxime-Ripard/drm-modes-Rewrite-the-command-line-parser/20190412-122837
HEAD 6993bfc971bbb32a70c38ec6e89a92c658f21f74 builds fine.
It only hurts bisectibility.
All error/warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:11:0,
from include/linux/list.h:9,
from drivers/gpu//drm/drm_modes.c:34:
drivers/gpu//drm/drm_modes.c: In function
'drm_mode_parse_command_line_for_connector':
>> drivers/gpu//drm/drm_modes.c:1591:7: error: 'named_mode' undeclared (first
>> use in this function)
if (named_mode)
^
include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers/gpu//drm/drm_modes.c:1591:3: note: in expansion of macro 'if'
if (named_mode)
^~
drivers/gpu//drm/drm_modes.c:1591:7: note: each undeclared identifier is
reported only once for each function it appears in
if (named_mode)
^
include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
if (__builtin_constant_p(!!(cond)) ? !!(cond) : \
^~~~
>> drivers/gpu//drm/drm_modes.c:1591:3: note: in expansion of macro 'if'
if (named_mode)
^~
vim +/named_mode +1591 drivers/gpu//drm/drm_modes.c
1571
1572 if (!mode_option) {
1573 mode->specified = false;
1574 return false;
1575 }
1576
1577 name = mode_option;
1578
1579 if (!isdigit(name[0]))
1580 return false;
1581
1582 /* Try to locate the bpp and refresh specifiers, if any */
1583 bpp_ptr = strchr(name, '-');
1584 if (bpp_ptr) {
1585 bpp_off = bpp_ptr - name;
1586 mode->bpp_specified = true;
1587 }
1588
1589 refresh_ptr = strchr(name, '@');
1590 if (refresh_ptr) {
> 1591 if (named_mode)
1592 return false;
1593
1594 refresh_off = refresh_ptr - name;
1595 mode->refresh_specified = true;
1596 }
1597
1598 /* Locate the end of the name / resolution, and parse it */
1599 if (bpp_ptr && refresh_ptr) {
1600 mode_end = min(bpp_off, refresh_off);
1601 } else if (bpp_ptr) {
1602 mode_end = bpp_off;
1603 } else if (refresh_ptr) {
1604 mode_end = refresh_off;
1605 } else {
1606 mode_end = strlen(name);
1607 parse_extras = true;
1608 }
1609
1610 ret = drm_mode_parse_cmdline_res_mode(name, mode_end,
1611parse_extras,
1612connector,
1613mode);
1614 if (ret)
1615 return false;
1616 mode->specified = true;
1617
1618 if (bpp_ptr) {
1619 ret = drm_mode_parse_cmdline_bpp(bpp_ptr, _end_ptr,
mode);
1620 if (ret)
1621 return false;
1622 }
1623
1624 if (refresh_ptr) {
1625 ret = drm_mode_parse_cmdline_refresh(refresh_ptr,
1626 _end_ptr,
mode);
1627 if (ret)
1628 return false;
1629 }
1630
1631 /*
1632 * Locate the end of the bpp / refresh, and parse the extras
1633 * if relevant
1634 */
1635 if (bpp_ptr && refresh_ptr)
1636 extra_ptr = max(bpp_end_ptr, refresh_end_ptr);
1637 else if (bpp_ptr)
1638 extra_ptr = bpp_end_ptr;
1639 else if (refresh_ptr)
1640 extra_ptr = refresh_end_ptr;
1641
1642 if (extra_ptr) {
1643 int remaining = strlen(name) - (extra_ptr - name);
1644
1645 /*
1646 * We still have characters to process, while
1647
[PATCH] drm/imx: enable IDMAC watermark feature
The DMFC is configured to supply a watermark signal that can be used to temporarily increase channel priority if the FIFO runs low. Use it. Signed-off-by: Philipp Zabel --- drivers/gpu/drm/imx/ipuv3-plane.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c b/drivers/gpu/drm/imx/ipuv3-plane.c index d7a727a6e3d7..d81b3102b488 100644 --- a/drivers/gpu/drm/imx/ipuv3-plane.c +++ b/drivers/gpu/drm/imx/ipuv3-plane.c @@ -639,6 +639,7 @@ static void ipu_plane_atomic_update(struct drm_plane *plane, ipu_cpmem_set_fmt(ipu_plane->ipu_ch, fb->format->format); ipu_cpmem_set_burstsize(ipu_plane->ipu_ch, burstsize); ipu_cpmem_set_high_priority(ipu_plane->ipu_ch); + ipu_idmac_enable_watermark(ipu_plane->ipu_ch, true); ipu_idmac_set_double_buffer(ipu_plane->ipu_ch, 1); ipu_cpmem_set_stride(ipu_plane->ipu_ch, fb->pitches[0]); ipu_cpmem_set_axi_id(ipu_plane->ipu_ch, axi_id); -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] gpu: ipu-v3: dp: fix CSC handling
From: Lucas Stach
Initialize the flow input colorspaces to unknown and reset to that value
when the channel gets disabled. This avoids the state getting mixed up
with a previous mode.
Also keep the CSC settings for the background flow intact when disabling
the foreground flow.
Root-caused-by: Jonathan Marek
Signed-off-by: Lucas Stach
Signed-off-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-dp.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-dp.c b/drivers/gpu/ipu-v3/ipu-dp.c
index 9b2b3fa479c4..5e44ff1f2085 100644
--- a/drivers/gpu/ipu-v3/ipu-dp.c
+++ b/drivers/gpu/ipu-v3/ipu-dp.c
@@ -195,7 +195,8 @@ int ipu_dp_setup_channel(struct ipu_dp *dp,
ipu_dp_csc_init(flow, flow->foreground.in_cs, flow->out_cs,
DP_COM_CONF_CSC_DEF_BOTH);
} else {
- if (flow->foreground.in_cs == flow->out_cs)
+ if (flow->foreground.in_cs == IPUV3_COLORSPACE_UNKNOWN ||
+ flow->foreground.in_cs == flow->out_cs)
/*
* foreground identical to output, apply color
* conversion on background
@@ -261,6 +262,8 @@ void ipu_dp_disable_channel(struct ipu_dp *dp, bool sync)
struct ipu_dp_priv *priv = flow->priv;
u32 reg, csc;
+ dp->in_cs = IPUV3_COLORSPACE_UNKNOWN;
+
if (!dp->foreground)
return;
@@ -268,8 +271,9 @@ void ipu_dp_disable_channel(struct ipu_dp *dp, bool sync)
reg = readl(flow->base + DP_COM_CONF);
csc = reg & DP_COM_CONF_CSC_DEF_MASK;
- if (csc == DP_COM_CONF_CSC_DEF_FG)
- reg &= ~DP_COM_CONF_CSC_DEF_MASK;
+ reg &= ~DP_COM_CONF_CSC_DEF_MASK;
+ if (csc == DP_COM_CONF_CSC_DEF_BOTH || csc == DP_COM_CONF_CSC_DEF_BG)
+ reg |= DP_COM_CONF_CSC_DEF_BG;
reg &= ~DP_COM_CONF_FG_EN;
writel(reg, flow->base + DP_COM_CONF);
@@ -347,6 +351,8 @@ int ipu_dp_init(struct ipu_soc *ipu, struct device *dev,
unsigned long base)
mutex_init(>mutex);
for (i = 0; i < IPUV3_NUM_FLOWS; i++) {
+ priv->flow[i].background.in_cs = IPUV3_COLORSPACE_UNKNOWN;
+ priv->flow[i].foreground.in_cs = IPUV3_COLORSPACE_UNKNOWN;
priv->flow[i].foreground.foreground = true;
priv->flow[i].base = priv->base + ipu_dp_flow_base[i];
priv->flow[i].priv = priv;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/imx: don't skip DP channel disable for background plane
From: Lucas Stach In order to make sure that the plane color space gets reset correctly. Signed-off-by: Lucas Stach Signed-off-by: Philipp Zabel --- drivers/gpu/drm/imx/ipuv3-crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c index ec3602ebbc1c..54011df8c2e8 100644 --- a/drivers/gpu/drm/imx/ipuv3-crtc.c +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c @@ -71,7 +71,7 @@ static void ipu_crtc_disable_planes(struct ipu_crtc *ipu_crtc, if (disable_partial) ipu_plane_disable(ipu_crtc->plane[1], true); if (disable_full) - ipu_plane_disable(ipu_crtc->plane[0], false); + ipu_plane_disable(ipu_crtc->plane[0], true); } static void ipu_crtc_atomic_disable(struct drm_crtc *crtc, -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/malidp: Enable writeback scaling
Hi Ben,
On Fri, Apr 12, 2019 at 03:08:32PM +0100, Ben Davis wrote:
> The phase setting part of malidp_crtc_atomic_check_scaling is refactored
> to allow use in writeback scaling.
>
> Also the enable_memwrite function prototype is simplified by directly
> passing mw_state.
>
> Signed-off-by: Ben Davis
> ---
> drivers/gpu/drm/arm/malidp_crtc.c | 49 --
> drivers/gpu/drm/arm/malidp_crtc.h | 12 ++
> drivers/gpu/drm/arm/malidp_drv.c | 10 +++--
> drivers/gpu/drm/arm/malidp_hw.c | 45 ++--
> drivers/gpu/drm/arm/malidp_hw.h | 19 +++--
> drivers/gpu/drm/arm/malidp_mw.c | 86
> ++-
> drivers/gpu/drm/arm/malidp_regs.h | 1 +
> 7 files changed, 161 insertions(+), 61 deletions(-)
> create mode 100644 drivers/gpu/drm/arm/malidp_crtc.h
>
> diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
> b/drivers/gpu/drm/arm/malidp_crtc.c
> index 3f65996..aa66457 100644
> --- a/drivers/gpu/drm/arm/malidp_crtc.c
> +++ b/drivers/gpu/drm/arm/malidp_crtc.c
> @@ -265,6 +265,31 @@ static int malidp_crtc_atomic_check_ctm(struct drm_crtc
> *crtc,
> return 0;
> }
>
> +void malidp_set_se_config_phase(struct malidp_se_config *s)
> +{
> +#define SE_N_PHASE 4
> +#define SE_SHIFT_N_PHASE 12
> + u32 phase;
> +
> + /* Calculate initial_phase and delta_phase for horizontal. */
> + phase = s->input_w;
> + s->h_init_phase = ((phase << SE_N_PHASE) / s->output_w + 1) / 2;
> +
> + phase = s->input_w;
> + phase <<= (SE_SHIFT_N_PHASE + SE_N_PHASE);
> + s->h_delta_phase = phase / s->output_w;
> +
> + /* Same for vertical. */
> + phase = s->input_h;
> + s->v_init_phase = ((phase << SE_N_PHASE) / s->output_h + 1) / 2;
> +
> + phase = s->input_h;
> + phase <<= (SE_SHIFT_N_PHASE + SE_N_PHASE);
> + s->v_delta_phase = phase / s->output_h;
> +#undef SE_N_PHASE
> +#undef SE_SHIFT_N_PHASE
> +}
> +
> static int malidp_crtc_atomic_check_scaling(struct drm_crtc *crtc,
> struct drm_crtc_state *state)
> {
> @@ -291,7 +316,6 @@ static int malidp_crtc_atomic_check_scaling(struct
> drm_crtc *crtc,
>
> drm_atomic_crtc_state_for_each_plane_state(plane, pstate, state) {
> struct malidp_plane *mp = to_malidp_plane(plane);
> - u32 phase;
>
> if (!(mp->layer->id & scaling))
> continue;
> @@ -319,27 +343,8 @@ static int malidp_crtc_atomic_check_scaling(struct
> drm_crtc *crtc,
> s->output_w = pstate->crtc_w;
> s->output_h = pstate->crtc_h;
>
> -#define SE_N_PHASE 4
> -#define SE_SHIFT_N_PHASE 12
> - /* Calculate initial_phase and delta_phase for horizontal. */
> - phase = s->input_w;
> - s->h_init_phase =
> - ((phase << SE_N_PHASE) / s->output_w + 1) / 2;
> -
> - phase = s->input_w;
> - phase <<= (SE_SHIFT_N_PHASE + SE_N_PHASE);
> - s->h_delta_phase = phase / s->output_w;
> -
> - /* Same for vertical. */
> - phase = s->input_h;
> - s->v_init_phase =
> - ((phase << SE_N_PHASE) / s->output_h + 1) / 2;
> -
> - phase = s->input_h;
> - phase <<= (SE_SHIFT_N_PHASE + SE_N_PHASE);
> - s->v_delta_phase = phase / s->output_h;
> -#undef SE_N_PHASE
> -#undef SE_SHIFT_N_PHASE
> +
> + malidp_set_se_config_phase(s);
> s->plane_src_id = mp->layer->id;
> }
>
> diff --git a/drivers/gpu/drm/arm/malidp_crtc.h
> b/drivers/gpu/drm/arm/malidp_crtc.h
> new file mode 100644
> index 000..0f056f8
> --- /dev/null
> +++ b/drivers/gpu/drm/arm/malidp_crtc.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * (C) COPYRIGHT 2019 ARM Limited. All rights reserved.
> + *
> + */
> +
> +#include "malidp_hw.h"
> +
> +#ifndef __MALIDP_CRTC_H__
> +#define __MALIDP_CRTC_H__
> +void malidp_set_se_config_phase(struct malidp_se_config *s);
> +#endif
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index d37ff9d..e2465e9 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -138,7 +138,7 @@ static void malidp_atomic_commit_se_config(struct
> drm_crtc *crtc,
> u32 val;
>
> /* Set SE_CONTROL */
> - if (!s->scale_enable) {
> + if (!s->scale_enable && !s->wb_scale_enable) {
> val = malidp_hw_read(hwdev, se_control);
> val &= ~MALIDP_SE_SCALING_EN;
> malidp_hw_write(hwdev, val, se_control);
> @@ -147,12 +147,16 @@ static void malidp_atomic_commit_se_config(struct
> drm_crtc *crtc,
>
> hwdev->hw->se_set_scaling_coeffs(hwdev, s, old_s);
> val = malidp_hw_read(hwdev, se_control);
> - val |= MALIDP_SE_SCALING_EN | MALIDP_SE_ALPHA_EN;
> + val |= MALIDP_SE_SCALING_EN;
>
> val &=
Re: [PATCH 3/4] drm/amdgpu: Avoid HW reset if guilty job already signaled.
On 4/12/19 3:39 AM, Christian König wrote:
> Am 11.04.19 um 18:03 schrieb Andrey Grodzovsky:
>> Also reject TDRs if another one already running.
>>
>> v2:
>> Stop all schedulers across device and entire XGMI hive before
>> force signaling HW fences.
>>
>> Signed-off-by: Andrey Grodzovsky
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 125
>> -
>> 1 file changed, 88 insertions(+), 37 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index aabd043..ce9c494 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -3327,7 +3327,8 @@ bool amdgpu_device_should_recover_gpu(struct
>> amdgpu_device *adev)
>> static int amdgpu_device_pre_asic_reset(struct amdgpu_device *adev,
>> struct amdgpu_job *job,
>> - bool *need_full_reset_arg)
>> + bool *need_full_reset_arg,
>> + bool job_signaled)
>> {
>> int i, r = 0;
>> bool need_full_reset = *need_full_reset_arg;
>> @@ -3339,8 +3340,6 @@ static int amdgpu_device_pre_asic_reset(struct
>> amdgpu_device *adev,
>> if (!ring || !ring->sched.thread)
>> continue;
>> - drm_sched_stop(>sched, >base);
>> -
>> /* after all hw jobs are reset, hw fence is meaningless, so
>> force_completion */
>> amdgpu_fence_driver_force_completion(ring);
>> }
>> @@ -3358,7 +3357,8 @@ static int amdgpu_device_pre_asic_reset(struct
>> amdgpu_device *adev,
>> - if (!amdgpu_sriov_vf(adev)) {
>> + /* Don't suspend on bare metal if we are not going to HW reset
>> the ASIC */
>> + if (!amdgpu_sriov_vf(adev) && !job_signaled) {
>> if (!need_full_reset)
>> need_full_reset = amdgpu_device_ip_need_full_reset(adev);
>> @@ -3495,7 +3495,7 @@ static int amdgpu_do_asic_reset(struct
>> amdgpu_hive_info *hive,
>> return r;
>> }
>> -static void amdgpu_device_post_asic_reset(struct amdgpu_device *adev)
>> +static void amdgpu_device_post_asic_reset(struct amdgpu_device
>> *adev, bool job_signaled)
>> {
>> int i;
>> @@ -3505,7 +3505,8 @@ static void
>> amdgpu_device_post_asic_reset(struct amdgpu_device *adev)
>> if (!ring || !ring->sched.thread)
>> continue;
>> - if (!adev->asic_reset_res)
>> + /* No point to resubmit jobs if we didn't HW reset*/
>> + if (!adev->asic_reset_res && !job_signaled)
>> drm_sched_resubmit_jobs(>sched);
>> drm_sched_start(>sched, !adev->asic_reset_res);
>> @@ -3518,14 +3519,21 @@ static void
>> amdgpu_device_post_asic_reset(struct amdgpu_device *adev)
>> adev->asic_reset_res = 0;
>> }
>> -static void amdgpu_device_lock_adev(struct amdgpu_device *adev)
>> +static bool amdgpu_device_lock_adev(struct amdgpu_device *adev, bool
>> trylock)
>> {
>> - mutex_lock(>lock_reset);
>> + if (trylock) {
>> + if (!mutex_trylock(>lock_reset))
>> + return false;
>> + } else
>> + mutex_lock(>lock_reset);
>> +
>> atomic_inc(>gpu_reset_counter);
>> adev->in_gpu_reset = 1;
>> /* Block kfd: SRIOV would do it separately */
>> if (!amdgpu_sriov_vf(adev))
>> amdgpu_amdkfd_pre_reset(adev);
>> +
>> + return true;
>> }
>> static void amdgpu_device_unlock_adev(struct amdgpu_device *adev)
>> @@ -3553,38 +3561,43 @@ static void amdgpu_device_unlock_adev(struct
>> amdgpu_device *adev)
>> int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
>> struct amdgpu_job *job)
>> {
>> - int r;
>> + int r, i;
>
> BTW: Usual kernel coding style is to use reverse xmas tree. E.g.
> variables like "int i, r" last in the declarations.
>
>> struct amdgpu_hive_info *hive = NULL;
>> - bool need_full_reset = false;
>> struct amdgpu_device *tmp_adev = NULL;
>> struct list_head device_list, *device_list_handle = NULL;
>> + bool xgmi_topology_present, need_full_reset, job_signaled;
>> + need_full_reset = job_signaled = false;
>> INIT_LIST_HEAD(_list);
>> dev_info(adev->dev, "GPU reset begin!\n");
>> + hive = amdgpu_get_xgmi_hive(adev, 0);
>
> The second parameter should actually be a bool, so please use false here.
>
>> + xgmi_topology_present = hive &&
>> adev->gmc.xgmi.num_physical_nodes > 1;
>
> Why are we actually checking num_physical_nodes here?
That the usual way of knowing you have XGMI topology, but having
hive!=NULL should be equivalent so I can remove it.
>
>> +
>> /*
>> - * In case of XGMI hive disallow concurrent resets to be triggered
>> - * by different nodes. No point also since the one node already
>> executing
>> - * reset will also reset all the other nodes in the hive.
>> + * Here we trylock to avoid chain of resets executing from
>> + * either
Re: [git pull] drm fixes for 5.1-rc5
The pull request you sent on Fri, 12 Apr 2019 14:04:12 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-04-12 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/58890f31f98db230e708905a7f0bd700756ebbed Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm: Add writeback_w,h properties
Hi Ben,
On Fri, Apr 12, 2019 at 03:08:28PM +0100, Ben Davis wrote:
> Add new properties to specify width and height for writeback.
>
> Signed-off-by: Ben Davis
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 8
> drivers/gpu/drm/drm_writeback.c | 28
> include/drm/drm_connector.h | 4
> include/drm/drm_mode_config.h | 10 ++
> 4 files changed, 50 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index d520a04..1f68dce 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -765,6 +765,10 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> return -EINVAL;
> }
> state->content_protection = val;
> + } else if (property == config->prop_writeback_w) {
> + state->writeback_w = val;
> + } else if (property == config->prop_writeback_h) {
> + state->writeback_h = val;
> } else if (property == config->writeback_fb_id_property) {
> struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL,
> val);
> int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
> @@ -837,6 +841,10 @@ drm_atomic_connector_get_property(struct drm_connector
> *connector,
> *val = state->scaling_mode;
> } else if (property == connector->content_protection_property) {
> *val = state->content_protection;
> + } else if (property == config->prop_writeback_w) {
> + *val = state->writeback_w;
> + } else if (property == config->prop_writeback_h) {
> + *val = state->writeback_h;
> } else if (property == config->writeback_fb_id_property) {
> /* Writeback framebuffer is one-shot, write and forget */
> *val = 0;
> diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> index c20e6fe..3d0453e 100644
> --- a/drivers/gpu/drm/drm_writeback.c
> +++ b/drivers/gpu/drm/drm_writeback.c
> @@ -74,6 +74,12 @@
> * applications making use of writeback connectors *always* retrieve an
> * out-fence for the commit and use it appropriately.
> * From userspace, this property will always read as zero.
> + *
> + * "WRITEBACK_W":
> + * The width of the writeback buffer to write back. 0 acts as default.
To the "0 acts as default" I would add: "(i.e. its not set by userspace)".
I think it is worth explaining in more detail that 0 is default if no
value is set from userspace and that it also means no scaling.
Best regards,
Liviu
> + *
> + * "WRITEBACK_H":
> + * The height of the writeback buffer to write back. 0 acts as default.
> */
>
> #define fence_to_wb_connector(x) container_of(x->lock, \
> @@ -141,6 +147,22 @@ static int create_writeback_properties(struct drm_device
> *dev)
> dev->mode_config.writeback_out_fence_ptr_property = prop;
> }
>
> + if (!dev->mode_config.prop_writeback_w) {
> + prop = drm_property_create_range(dev, DRM_MODE_PROP_ATOMIC,
> + "WRITEBACK_W", 1, UINT_MAX);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.prop_writeback_w = prop;
> + }
> +
> + if (!dev->mode_config.prop_writeback_h) {
> + prop = drm_property_create_range(dev, DRM_MODE_PROP_ATOMIC,
> + "WRITEBACK_H", 1, UINT_MAX);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.prop_writeback_h = prop;
> + }
> +
> return 0;
> }
>
> @@ -225,6 +247,12 @@ int drm_writeback_connector_init(struct drm_device *dev,
> drm_object_attach_property(>base,
> config->writeback_pixel_formats_property,
> blob->base.id);
> +
> + drm_object_attach_property(>base,
> +config->prop_writeback_w, 0);
> + drm_object_attach_property(>base,
> +config->prop_writeback_h, 0);
> +
> wb_connector->pixel_formats_blob_ptr = blob;
>
> return 0;
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 8fe22ab..51c4cb2 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -515,6 +515,10 @@ struct drm_connector_state {
>*/
> struct drm_writeback_job *writeback_job;
>
> + /** @writeback_w: width of plane to write to wb buffer */
> + /** @writeback_h: height of plane to write to wb buffer */
> + uint32_t writeback_w, writeback_h;
> +
> /**
>* @max_requested_bpc: Connector property to limit the maximum bit
>* depth of the pixels.
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 7f60e8e..a0c2133 100644
> ---
Re: [PATCH] drm/panfrost: Add support for 2MB page entries
Acked-by: Tomeu Vizoso Thanks! Tomeu On Fri, 12 Apr 2019 at 09:27, Alyssa Rosenzweig wrote: > > Acked-by: Alyssa Rosenzweig > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110413] GPU crash and failed reset leading to deadlock on Polaris 22 XL [Radeon RX Vega M GL]
https://bugs.freedesktop.org/show_bug.cgi?id=110413 --- Comment #4 from Rémi Verschelde --- Pasting some relevant output from attachment 143951 so that relevant keywords can be found by Bugzilla searches. ``` [ 325.087186] mce: CPU7: Core temperature above threshold, cpu clock throttled (total events = 1) [ 325.087187] mce: CPU3: Core temperature above threshold, cpu clock throttled (total events = 1) [ 325.087188] mce: CPU3: Package temperature above threshold, cpu clock throttled (total events = 1) [ 325.087189] mce: CPU7: Package temperature above threshold, cpu clock throttled (total events = 1) [ 325.087224] mce: CPU5: Package temperature above threshold, cpu clock throttled (total events = 1) [ 325.087225] mce: CPU0: Package temperature above threshold, cpu clock throttled (total events = 1) [ 325.087226] mce: CPU1: Package temperature above threshold, cpu clock throttled (total events = 1) [ 325.087226] mce: CPU4: Package temperature above threshold, cpu clock throttled (total events = 1) [ 325.087227] mce: CPU6: Package temperature above threshold, cpu clock throttled (total events = 1) [ 325.087228] mce: CPU2: Package temperature above threshold, cpu clock throttled (total events = 1) [ 325.089212] mce: CPU7: Core temperature/speed normal [ 325.089213] mce: CPU0: Package temperature/speed normal [ 325.089214] mce: CPU3: Core temperature/speed normal [ 325.089214] mce: CPU4: Package temperature/speed normal [ 325.089215] mce: CPU7: Package temperature/speed normal [ 325.089215] mce: CPU3: Package temperature/speed normal [ 325.089248] mce: CPU6: Package temperature/speed normal [ 325.089248] mce: CPU5: Package temperature/speed normal [ 325.089249] mce: CPU2: Package temperature/speed normal [ 325.089250] mce: CPU1: Package temperature/speed normal [ 565.312183] amdgpu :01:00.0: GPU fault detected: 147 0x0040d508 for process pid 0 thread pid 0 [ 565.312194] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00169208 [ 565.312200] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [ 565.312209] amdgpu :01:00.0: VM fault (0xff, vmid 15, pasid 0) at page 1479176, write from '\xff\xff\xff\xff' (0x) (511) [ 565.312219] amdgpu :01:00.0: GPU fault detected: 147 0x00405508 for process pid 0 thread pid 0 [ 565.312224] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 565.312229] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [ 565.312236] amdgpu :01:00.0: VM fault (0xff, vmid 15, pasid 0) at page 4294967295, write from '\xff\xff\xff\xff' (0x) (511) [ 565.312244] amdgpu :01:00.0: GPU fault detected: 147 0x00485508 for process pid 0 thread pid 0 [ 565.312248] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 565.312252] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [ 565.312258] amdgpu :01:00.0: VM fault (0xff, vmid 15, pasid 0) at page 4294967295, write from '\xff\xff\xff\xff' (0x) (511) [ 565.312378] amdgpu :01:00.0: GPU fault detected: 147 0x00785508 for process pid 0 thread pid 0 [ 565.312383] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ 565.312387] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x [ 565.312393] amdgpu :01:00.0: VM fault (0xff, vmid 15, pasid 0) at page 4294967295, write from '\xff\xff\xff\xff' (0x) (511) [ 575.625913] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=117668, emitted seq=117670 [ 575.625950] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process starcrawlers.x8 pid 9151 thread starcrawle:cs0 pid 9162 [ 575.625953] amdgpu :01:00.0: GPU reset begin! [ 575.626419] amdgpu: [powerplay] last message was failed ret is 65535 [ 575.626420] amdgpu: [powerplay] failed to send message 281 ret is 65535 [ 575.636259] [drm:amdgpu_device_ip_suspend_phase2 [amdgpu]] *ERROR* suspend of IP block failed -110 [ 575.651311] amdgpu: [powerplay] last message was failed ret is 65535 [ 575.651312] amdgpu: [powerplay] failed to send message 133 ret is 65535 [ 575.651316] amdgpu: [powerplay] last message was failed ret is 65535 [ 575.651316] amdgpu: [powerplay] failed to send message 310 ret is 65535 [ 575.651317] amdgpu: [powerplay] last message was failed ret is 65535 [ 575.651317] amdgpu: [powerplay] failed to send message 5e ret is 65535 [ 575.651340] amdgpu: [powerplay] last message was failed ret is 65535 [ 575.651341] amdgpu: [powerplay] failed to send message 84 ret is 65535 [ 575.651341] amdgpu: [powerplay] Failed to force to switch arbf0! [ 575.651342] amdgpu: [powerplay] [disable_dpm_tasks] Failed to disable DPM! [ 575.651360] [drm:amdgpu_device_ip_suspend_phase2 [amdgpu]]
Re: [PATCH v3 2/3] drm: Add a drm_gem_objects_lookup helper
Acked-by: Tomeu Vizoso
On Tue, 9 Apr 2019 at 22:54, Rob Herring wrote:
>
> Similar to the single handle drm_gem_object_lookup(),
> drm_gem_objects_lookup() takes an array of handles and returns an array
> of GEM objects.
>
> v2:
> - Take the userspace pointer directly and allocate the array.
> - Expand the function documentation.
>
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> Acked-by: Alyssa Rosenzweig
> Signed-off-by: Rob Herring
> ---
> drivers/gpu/drm/drm_gem.c | 93 ++-
> include/drm/drm_gem.h | 2 +
> 2 files changed, 85 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 388b3742e562..faa2718e85e8 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -663,6 +663,85 @@ void drm_gem_put_pages(struct drm_gem_object *obj,
> struct page **pages,
> }
> EXPORT_SYMBOL(drm_gem_put_pages);
>
> +static int objects_lookup(struct drm_file *filp, u32 *handle, int count,
> + struct drm_gem_object **objs)
> +{
> + int i, ret = 0;
> + struct drm_gem_object *obj;
> +
> + spin_lock(>table_lock);
> +
> + for (i = 0; i < count; i++) {
> + /* Check if we currently have a reference on the object */
> + obj = idr_find(>object_idr, handle[i]);
> + if (!obj) {
> + ret = -ENOENT;
> + break;
> + }
> + drm_gem_object_get(obj);
> + objs[i] = obj;
> + }
> + spin_unlock(>table_lock);
> +
> + return ret;
> +}
> +
> +/**
> + * drm_gem_objects_lookup - look up GEM objects from an array of handles
> + * @filp: DRM file private date
> + * @bo_handles: user pointer to array of userspace handle
> + * @count: size of handle array
> + * @objs_out: returned pointer to array of drm_gem_object pointers
> + *
> + * Takes an array of userspace handles and returns a newly allocated array of
> + * GEM objects.
> + *
> + * For a single handle lookup, use drm_gem_object_lookup().
> + *
> + * Returns:
> + *
> + * @objs filled in with GEM object pointers. Returned GEM objects need to be
> + * released with drm_gem_object_put(). -ENOENT is returned on a lookup
> + * failure. 0 is returned on success.
> + *
> + */
> +int drm_gem_objects_lookup(struct drm_file *filp, void __user *bo_handles,
> + int count, struct drm_gem_object ***objs_out)
> +{
> + int ret;
> + u32 *handles;
> + struct drm_gem_object **objs;
> +
> + if (!count)
> + return 0;
> +
> + objs = kvmalloc_array(count, sizeof(struct drm_gem_object *),
> +GFP_KERNEL | __GFP_ZERO);
> + if (!objs)
> + return -ENOMEM;
> +
> + handles = kvmalloc_array(count, sizeof(u32), GFP_KERNEL);
> + if (!handles) {
> + ret = -ENOMEM;
> + goto out;
> + }
> +
> + if (copy_from_user(handles, bo_handles, count * sizeof(u32))) {
> + ret = -EFAULT;
> + DRM_DEBUG("Failed to copy in GEM handles\n");
> + goto out;
> + }
> +
> + ret = objects_lookup(filp, handles, count, objs);
> + *objs_out = objs;
> +
> +out:
> + kvfree(handles);
> + return ret;
> +
> +}
> +EXPORT_SYMBOL(drm_gem_objects_lookup);
> +
> /**
> * drm_gem_object_lookup - look up a GEM object from its handle
> * @filp: DRM file private date
> @@ -672,21 +751,15 @@ EXPORT_SYMBOL(drm_gem_put_pages);
> *
> * A reference to the object named by the handle if such exists on @filp,
> NULL
> * otherwise.
> + *
> + * If looking up an array of handles, use drm_gem_objects_lookup().
> */
> struct drm_gem_object *
> drm_gem_object_lookup(struct drm_file *filp, u32 handle)
> {
> - struct drm_gem_object *obj;
> -
> - spin_lock(>table_lock);
> -
> - /* Check if we currently have a reference on the object */
> - obj = idr_find(>object_idr, handle);
> - if (obj)
> - drm_gem_object_get(obj);
> -
> - spin_unlock(>table_lock);
> + struct drm_gem_object *obj = NULL;
>
> + objects_lookup(filp, , 1, );
> return obj;
> }
> EXPORT_SYMBOL(drm_gem_object_lookup);
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index 2955aaab3dca..5ee85c9eaa9d 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -381,6 +381,8 @@ struct page **drm_gem_get_pages(struct drm_gem_object
> *obj);
> void drm_gem_put_pages(struct drm_gem_object *obj, struct page **pages,
> bool dirty, bool accessed);
>
> +int drm_gem_objects_lookup(struct drm_file *filp, void __user *bo_handles,
> + int count, struct drm_gem_object ***objs_out);
> struct drm_gem_object *drm_gem_object_lookup(struct drm_file *filp, u32
> handle);
> long
Re: [PATCH V2 3/4] drm: rcar-du: Add R8A774A1 support
Hi Biju,
On 12/04/2019 13:38, Biju Das wrote:
> Add support for the R8A774A1 DU (which is very similar to the R8A7796 DU
> except that it lacks TCON and CMM); it has one RGB output, one LVDS output
> and one HDMI output.
> > Signed-off-by: Biju Das
Thank you for the updated patch,
Reviewed-by: Kieran Bingham
> ---
> V1-->V2
> * Incorporated Kieran's review comment
> (https://patchwork.kernel.org/patch/10896165/)
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 75ab17a..6df37c2 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -102,6 +102,35 @@ static const struct rcar_du_device_info
> rzg1_du_r8a77470_info = {
> },
> };
>
> +static const struct rcar_du_device_info rcar_du_r8a774a1_info = {
> + .gen = 3,
> + .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
> + | RCAR_DU_FEATURE_VSP1_SOURCE
> + | RCAR_DU_FEATURE_INTERLACED
> + | RCAR_DU_FEATURE_TVM_SYNC,
> + .channels_mask = BIT(2) | BIT(1) | BIT(0),
> + .routes = {
> + /*
> + * R8A774A1 has one RGB output, one LVDS output and one HDMI
> + * output.
> + */
> + [RCAR_DU_OUTPUT_DPAD0] = {
> + .possible_crtcs = BIT(2),
> + .port = 0,
> + },
> + [RCAR_DU_OUTPUT_HDMI0] = {
> + .possible_crtcs = BIT(1),
> + .port = 1,
> + },
> + [RCAR_DU_OUTPUT_LVDS0] = {
> + .possible_crtcs = BIT(0),
> + .port = 2,
> + },
> + },
> + .num_lvds = 1,
> + .dpll_mask = BIT(1),
> +};
> +
> static const struct rcar_du_device_info rcar_du_r8a774c0_info = {
> .gen = 3,
> .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
> @@ -386,6 +415,7 @@ static const struct of_device_id rcar_du_of_table[] = {
> { .compatible = "renesas,du-r8a7744", .data = _du_r8a7743_info },
> { .compatible = "renesas,du-r8a7745", .data = _du_r8a7745_info },
> { .compatible = "renesas,du-r8a77470", .data = _du_r8a77470_info },
> + { .compatible = "renesas,du-r8a774a1", .data = _du_r8a774a1_info },
> { .compatible = "renesas,du-r8a774c0", .data = _du_r8a774c0_info },
> { .compatible = "renesas,du-r8a7779", .data = _du_r8a7779_info },
> { .compatible = "renesas,du-r8a7790", .data = _du_r8a7790_info },
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110413] GPU crash and failed reset leading to deadlock on Polaris 22 XL [Radeon RX Vega M GL]
https://bugs.freedesktop.org/show_bug.cgi?id=110413 --- Comment #3 from Rémi Verschelde --- Created attachment 143953 --> https://bugs.freedesktop.org/attachment.cgi?id=143953=edit /proc/config.gz from Mageia's kernel 5.0.7-desktop, used for custom amd-staging-drm-next build -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110413] GPU crash and failed reset leading to deadlock on Polaris 22 XL [Radeon RX Vega M GL]
https://bugs.freedesktop.org/show_bug.cgi?id=110413 --- Comment #2 from Rémi Verschelde --- Created attachment 143952 --> https://bugs.freedesktop.org/attachment.cgi?id=143952=edit dmesg output after GPU crash in game For The King with kernel 5.0-rc1 built from amd-staging-drm-next Built with the same .config as Mageia's 5.0.7-desktop kernel, see next attachment. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 3/4] lib/hexdump.c: Replace ascii bool in hex_dump_to_buffer with flags
On 10/04/2019 04:17, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> In order to support additional features in hex_dump_to_buffer, replace
> the ascii bool parameter with flags.
>
> Signed-off-by: Alastair D'Silva
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c| 2 +-
> drivers/isdn/hardware/mISDN/mISDNisar.c | 6 --
> drivers/mailbox/mailbox-test.c| 2 +-
> drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 2 +-
> drivers/net/ethernet/synopsys/dwc-xlgmac-common.c | 2 +-
> drivers/net/wireless/ath/ath10k/debug.c | 3 ++-
> drivers/net/wireless/intel/iwlegacy/3945-mac.c| 2 +-
> drivers/platform/chrome/wilco_ec/debugfs.c| 3 ++-
> drivers/scsi/scsi_logging.c | 8 +++-
> drivers/staging/fbtft/fbtft-core.c| 2 +-
> fs/seq_file.c | 3 ++-
> include/linux/printk.h| 2 +-
> lib/hexdump.c | 15 ---
> lib/test_hexdump.c| 5 +++--
> 14 files changed, 31 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 49fa43ff02ba..fb133e729f9a 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -1318,7 +1318,7 @@ static void hexdump(struct drm_printer *m, const void
> *buf, size_t len)
> WARN_ON_ONCE(hex_dump_to_buffer(buf + pos, len - pos,
> rowsize, sizeof(u32),
> line, sizeof(line),
> - false) >= sizeof(line));
> + 0) >= sizeof(line));
> drm_printf(m, "[%04zx] %s\n", pos, line);
>
> prev = buf + pos;
i915 code here actually does something I think is more interesting than
HEXDUMP_SUPPRESS_0X**. It replaces any N repeating lines with a single star
marker. For example:
*
0040 0001 0018 0002 0001 0018
0060
0003
0080
*
00c0 0002
00e0
*
If or when you end up with this feature in your series you can therefore
replace the whole implementation of hexdump in the above file.
Regards,
Tvrtko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110413] GPU crash and failed reset leading to deadlock on Polaris 22 XL [Radeon RX Vega M GL]
https://bugs.freedesktop.org/show_bug.cgi?id=110413 --- Comment #1 from Rémi Verschelde --- Created attachment 143951 --> https://bugs.freedesktop.org/attachment.cgi?id=143951=edit dmesg output after GPU crash in game StarCrawlers with kernel 5.0.7-desktop from Mageia 7 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110413] GPU crash and failed reset leading to deadlock on Polaris 22 XL [Radeon RX Vega M GL]
https://bugs.freedesktop.org/show_bug.cgi?id=110413 Bug ID: 110413 Summary: GPU crash and failed reset leading to deadlock on Polaris 22 XL [Radeon RX Vega M GL] Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: rversche...@gmail.com Created attachment 143950 --> https://bugs.freedesktop.org/attachment.cgi?id=143950=edit lspci -vvv output for HP Spectre 360x My HP Spectre x360 laptop bought in March 2019 comes with KabyLake G HD Graphics 630 and a discrete AMD Radeon RX Vega M GL GPU. I only enable the Radeon GPU when needed to play graphics intensive games with `DRI_PRIME=1`, and so far I experience a lot of GPU deadlocks with the following symptoms: - Temperatures raise, the CPUs are throttled. Framerate drops when this happens. - Later on, GPU faults are reported in dmesg, the game's rendering freezes (but music continues playing). I am still able to alt+tab back to desktop or open a terminal, but the game's process can't be killed. If I'm monitoring temperatures, lm_sensors always reports a bogus 511°C temperature for the AMD dGPU at this point, before breaking. - Any subsequent attempt at using the AMD GPU will cause a system deadlock, and I need to force shutdown with the power button. My testing so far has covered: - Unity3D games like For The King or StarCrawlers. The crash happens mid-game, not in a strictly reproducible manner, but seems related to CPU temperature/throttling. * I could also reproduce the crash with SuperTuxKart, not in-game but when alt-tabbing back to desktop. * I could not get the crash yet with glmark2. With For The King, I can reliably get a crash within 1 to 10 minutes in-game when playing with "High" or "Dream" graphics quality. - Kernel 5.0.x (up to 5.0.7) from Mageia 7 (Cauldron), e.g. 5.0.7-desktop-4.mga7. * I also tried `git://people.freedesktop.org/~agd5f/linux -b amd-staging-drm-next` at b07c394a327fc9e435ee03288584c111fa73d963, but I still got the same symptoms. dmesg output was in part different though, more spammy. * Following discussions in bug 109692, I tried the patches provided by Andrey Grodzovsky in bug 109692 comment 34, but they did not solve the issue for me. - Mesa 19.0.0 to 19.0.2 built against LLVM 7.0.1. - Suspecting the CPU temperature/throttling as a trigger, I'm using https://github.com/kitsunyan/intel-undervolt to undervolt the CPU Cache by -100 mV and set the CPU limit temperature to 80°C instead of 100°C. This has helped with throttling issues I had during code compilation, but no visible change on my GPU crashes that I can tell. I can disable this undervolting when doing tests if required. I found various bug reports which might well be duplicates, but I'm opening my own to avoid hijacking discussions on what may or may not be the same root cause: bug 109461, bug 109466, bug 109692 (I installed Shadow of the Tomb Raider but haven't checked if I can reproduce this one's symptoms yet), bug 109819. I attach some relevant logs on the system and the bug. Please ask for anything else you may need. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/4] drm/atomic: rename async_{update,check} to amend_{update,check}
On Fri, 12 Apr 2019 11:06:13 -0300
Helen Koike wrote:
> Hi Boris,
>
> On 4/12/19 10:49 AM, Boris Brezillon wrote:
> > Hi Helen,
> >
> > On Fri, 12 Apr 2019 09:58:25 -0300
> > Helen Koike wrote:
> >
> >> Asynchronous update is the ability change the hw state at any time, not
> >> only during vblank.
> >>
> >> Amend mode is the ability to perform 1000 commits to be applied as soon
> >> as possible without waiting for 1000 vblanks.
> >>
> >> async updates can be seen as amend, but the opposite is not true.
> >>
> >> _plane_helper_funcs.atomic_async_{update,check}() was being used by
> >> drivers to implement amend and not async. So rename them to amend.
> >>
> >> Also improve docs explaining the difference.
> >>
> >> If asynchronous is required, normal page flip can be performed using
> >> DRM_MODE_PAGE_FLIP_ASYNC flag.
> >>
> >> Signed-off-by: Helen Koike
> >>
> >> ---
> >> Hello,
> >>
> >> I would like to officially clarify what async update means by adding it
> >> in the docs.
> >> Please correct me if I am wrong, but the current async_{update,check}
> >> callbacks are being used to do amend (the legacy cursor behavior), i.e.
> >> to allow 1000 updates without waiting for 1000 vblanks.
> >
> > Right now, the semantic of async update is driver dependent. Some
> > drivers will amend the last commit touching that plane (amend semantic),
> > others will update the plane buffer immediately which might cause
> > tearing (async semantic).
>
> In my pov, async updates holds the properties of an amend update, so all
> async updates we have are amend, but the opposite is not true.
By doing that you keep the definition quite vague, and developers will
still confused about what they should do when AMEND is requested. Why
not distinguishing AMEND and ASYNC now?
AMEND: replace the pending plane update (if any) by the new one, and
make sure things will be applied on the next VBLANK (if nothing else
amends the commit in the meantime)
ASYNC: update things immediately (don't wait for VBLANK)
>
> >
> >>
> >> So I would like to clarify this in the docs and rename the current
> >> callbacks to reflect this behaviour.
> >
> > I'm all for this clarification, but I don't think renaming the async
> > hooks is a good idea, since some drivers will not do real 'amend'. So,
> > you're changing the name, but it's still confusing :-).
> >
> > How about adding new hooks (and/or flags) for the AMEND case, and
> > keeping the async path untouched. We can then let drivers that
> > currently implement async as amend implement the amend hooks instead.
> > Once you've done that, you can hook that up to the legacy cursor update
> > path so that it first tries one then the other and finally falls back
> > to a sync update if none of ASYNC/AMEND is possible.
>
> I kinda did this (I re-introduced async in the last patch in the
> series). I know this order is confusing, but as rockchip doesn't
> implement true async, I would have to do a bunch of modifs at once to
> keep the commits consistent, but I can re-work on that if it makes
> things clearer.
Let's wait for more feedback before taking a decision on this aspect.
>
> >
> >>
> >> I also see that for real async updates, the flag
> >> DRM_MODE_PAGE_FLIP_ASYNC can be used in a normal sync update (it is
> >> already being used by some drivers actually, in the atomic path, not only
> >> in the legacy page flip, at least is what I understood from
> >> amdgpu_dm_atomic_commit_tail() implementation).
> >
> > Yes, right now, async does not necessarily imply non-block, but
> > Daniel seemed to think that most users want non-block when they do an
> > async page flip, so maybe it should be clarified too.
>
> users could combine NONBLOCK flag with PAGE_FLIP_ASYNC, no? (we need to
> add code for it of course).
I guess AMD goes through the sync update path to guarantee that fences
are signaled before doing the page flip, but most of the time, when you
do an async page flip you don't want to block :-).
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/amd/display: Restore deleted patch to resolve reset deadlock.
On 4/12/19 3:40 AM, Christian König wrote:
> Am 11.04.19 um 18:03 schrieb Andrey Grodzovsky:
>> Patch '5edb0c9b Fix deadlock with display during hanged ring recovery'
>> was accidentaly removed during one of DALs code merges.
>>
>> Signed-off-by: Andrey Grodzovsky
>> ---
>> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 19
>> +--
>> 1 file changed, 13 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> index 0648794..27e0383 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -5138,14 +5138,21 @@ static void amdgpu_dm_commit_planes(struct
>> drm_atomic_state *state,
>> */
>> abo = gem_to_amdgpu_bo(fb->obj[0]);
>> r = amdgpu_bo_reserve(abo, true);
>> - if (unlikely(r != 0)) {
>> + if (unlikely(r != 0))
>> DRM_ERROR("failed to reserve buffer before flip\n");
>> - WARN_ON(1);
>> - }
>
> I also already suggested to completely stop waiting while the BO is
> being reserved, but looks like that got dropped as well.
>
> I would say something is seriously wrong with DALs development process
> here.
>
> Christian.
Yea, I think your patch that moved the wait out of the reserved section
got dropped as well, when I re spin the series with your comments for
the TDR stuff I will also add a patch restoring your change.
Andrey
>
>> - /* Wait for all fences on this FB */
>> - WARN_ON(reservation_object_wait_timeout_rcu(abo->tbo.resv, true,
>> false,
>> - MAX_SCHEDULE_TIMEOUT) < 0);
>> + /*
>> + * Wait for all fences on this FB. Do limited wait to avoid
>> + * deadlock during GPU reset when this fence will not signal
>> + * but we hold reservation lock for the BO.
>> + */
>> + r = reservation_object_wait_timeout_rcu(abo->tbo.resv,
>> + true, false,
>> + msecs_to_jiffies(5000));
>> + if (unlikely(r == 0))
>> + DRM_ERROR("Waiting for fences timed out.");
>> +
>> +
>> amdgpu_bo_get_tiling_flags(abo, _flags);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v6 2/2] drm/i915: Add a missed update of edid property of drm connector
Quoting Gwan-gyeong Mun (2019-04-12 15:06:17) > After suspend/resume process, hotplug detection is handled by > i915_hpd_poll_init_work() workqueue. While intel_hdmi_detect() or > intel_dp_detect() are called, intel_hdmi_set_edid() or intel_dp_set_edid() > only update an internal detect_edid variable of intel_connector. > A missed update of edid property of drm_connector leads incorrect behavior > of drm_helper_hpd_irq_event() on below testcases. > It adds a missed update of edid property of drm connector and updates > drm edid modes, while i915_hpd_poll_init_work() workqueue works. It's not missing. set_edid is called in detect, update_modes is called from get_modes. It's the probe helper missing a call. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/malidp: Enable writeback scaling
The phase setting part of malidp_crtc_atomic_check_scaling is refactored
to allow use in writeback scaling.
Also the enable_memwrite function prototype is simplified by directly
passing mw_state.
Signed-off-by: Ben Davis
---
drivers/gpu/drm/arm/malidp_crtc.c | 49 --
drivers/gpu/drm/arm/malidp_crtc.h | 12 ++
drivers/gpu/drm/arm/malidp_drv.c | 10 +++--
drivers/gpu/drm/arm/malidp_hw.c | 45 ++--
drivers/gpu/drm/arm/malidp_hw.h | 19 +++--
drivers/gpu/drm/arm/malidp_mw.c | 86 ++-
drivers/gpu/drm/arm/malidp_regs.h | 1 +
7 files changed, 161 insertions(+), 61 deletions(-)
create mode 100644 drivers/gpu/drm/arm/malidp_crtc.h
diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
b/drivers/gpu/drm/arm/malidp_crtc.c
index 3f65996..aa66457 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -265,6 +265,31 @@ static int malidp_crtc_atomic_check_ctm(struct drm_crtc
*crtc,
return 0;
}
+void malidp_set_se_config_phase(struct malidp_se_config *s)
+{
+#define SE_N_PHASE 4
+#define SE_SHIFT_N_PHASE 12
+ u32 phase;
+
+ /* Calculate initial_phase and delta_phase for horizontal. */
+ phase = s->input_w;
+ s->h_init_phase = ((phase << SE_N_PHASE) / s->output_w + 1) / 2;
+
+ phase = s->input_w;
+ phase <<= (SE_SHIFT_N_PHASE + SE_N_PHASE);
+ s->h_delta_phase = phase / s->output_w;
+
+ /* Same for vertical. */
+ phase = s->input_h;
+ s->v_init_phase = ((phase << SE_N_PHASE) / s->output_h + 1) / 2;
+
+ phase = s->input_h;
+ phase <<= (SE_SHIFT_N_PHASE + SE_N_PHASE);
+ s->v_delta_phase = phase / s->output_h;
+#undef SE_N_PHASE
+#undef SE_SHIFT_N_PHASE
+}
+
static int malidp_crtc_atomic_check_scaling(struct drm_crtc *crtc,
struct drm_crtc_state *state)
{
@@ -291,7 +316,6 @@ static int malidp_crtc_atomic_check_scaling(struct drm_crtc
*crtc,
drm_atomic_crtc_state_for_each_plane_state(plane, pstate, state) {
struct malidp_plane *mp = to_malidp_plane(plane);
- u32 phase;
if (!(mp->layer->id & scaling))
continue;
@@ -319,27 +343,8 @@ static int malidp_crtc_atomic_check_scaling(struct
drm_crtc *crtc,
s->output_w = pstate->crtc_w;
s->output_h = pstate->crtc_h;
-#define SE_N_PHASE 4
-#define SE_SHIFT_N_PHASE 12
- /* Calculate initial_phase and delta_phase for horizontal. */
- phase = s->input_w;
- s->h_init_phase =
- ((phase << SE_N_PHASE) / s->output_w + 1) / 2;
-
- phase = s->input_w;
- phase <<= (SE_SHIFT_N_PHASE + SE_N_PHASE);
- s->h_delta_phase = phase / s->output_w;
-
- /* Same for vertical. */
- phase = s->input_h;
- s->v_init_phase =
- ((phase << SE_N_PHASE) / s->output_h + 1) / 2;
-
- phase = s->input_h;
- phase <<= (SE_SHIFT_N_PHASE + SE_N_PHASE);
- s->v_delta_phase = phase / s->output_h;
-#undef SE_N_PHASE
-#undef SE_SHIFT_N_PHASE
+
+ malidp_set_se_config_phase(s);
s->plane_src_id = mp->layer->id;
}
diff --git a/drivers/gpu/drm/arm/malidp_crtc.h
b/drivers/gpu/drm/arm/malidp_crtc.h
new file mode 100644
index 000..0f056f8
--- /dev/null
+++ b/drivers/gpu/drm/arm/malidp_crtc.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * (C) COPYRIGHT 2019 ARM Limited. All rights reserved.
+ *
+ */
+
+#include "malidp_hw.h"
+
+#ifndef __MALIDP_CRTC_H__
+#define __MALIDP_CRTC_H__
+void malidp_set_se_config_phase(struct malidp_se_config *s);
+#endif
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index d37ff9d..e2465e9 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -138,7 +138,7 @@ static void malidp_atomic_commit_se_config(struct drm_crtc
*crtc,
u32 val;
/* Set SE_CONTROL */
- if (!s->scale_enable) {
+ if (!s->scale_enable && !s->wb_scale_enable) {
val = malidp_hw_read(hwdev, se_control);
val &= ~MALIDP_SE_SCALING_EN;
malidp_hw_write(hwdev, val, se_control);
@@ -147,12 +147,16 @@ static void malidp_atomic_commit_se_config(struct
drm_crtc *crtc,
hwdev->hw->se_set_scaling_coeffs(hwdev, s, old_s);
val = malidp_hw_read(hwdev, se_control);
- val |= MALIDP_SE_SCALING_EN | MALIDP_SE_ALPHA_EN;
+ val |= MALIDP_SE_SCALING_EN;
val &= ~MALIDP_SE_ENH(MALIDP_SE_ENH_MASK);
val |= s->enhancer_enable ? MALIDP_SE_ENH(3) : 0;
- val |= MALIDP_SE_RGBO_IF_EN;
+ if (s->scale_enable)
+ val |= (MALIDP_SE_RGBO_IF_EN | MALIDP_SE_ALPHA_EN);
+ else
+ val &=
[PATCH v2 1/2] drm: Add writeback_w,h properties
Add new properties to specify width and height for writeback.
Signed-off-by: Ben Davis
---
drivers/gpu/drm/drm_atomic_uapi.c | 8
drivers/gpu/drm/drm_writeback.c | 28
include/drm/drm_connector.h | 4
include/drm/drm_mode_config.h | 10 ++
4 files changed, 50 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index d520a04..1f68dce 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -765,6 +765,10 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+ } else if (property == config->prop_writeback_w) {
+ state->writeback_w = val;
+ } else if (property == config->prop_writeback_h) {
+ state->writeback_h = val;
} else if (property == config->writeback_fb_id_property) {
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL,
val);
int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
@@ -837,6 +841,10 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
*val = state->content_protection;
+ } else if (property == config->prop_writeback_w) {
+ *val = state->writeback_w;
+ } else if (property == config->prop_writeback_h) {
+ *val = state->writeback_h;
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
*val = 0;
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index c20e6fe..3d0453e 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -74,6 +74,12 @@
* applications making use of writeback connectors *always* retrieve an
* out-fence for the commit and use it appropriately.
* From userspace, this property will always read as zero.
+ *
+ * "WRITEBACK_W":
+ * The width of the writeback buffer to write back. 0 acts as default.
+ *
+ * "WRITEBACK_H":
+ * The height of the writeback buffer to write back. 0 acts as default.
*/
#define fence_to_wb_connector(x) container_of(x->lock, \
@@ -141,6 +147,22 @@ static int create_writeback_properties(struct drm_device
*dev)
dev->mode_config.writeback_out_fence_ptr_property = prop;
}
+ if (!dev->mode_config.prop_writeback_w) {
+ prop = drm_property_create_range(dev, DRM_MODE_PROP_ATOMIC,
+"WRITEBACK_W", 1, UINT_MAX);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.prop_writeback_w = prop;
+ }
+
+ if (!dev->mode_config.prop_writeback_h) {
+ prop = drm_property_create_range(dev, DRM_MODE_PROP_ATOMIC,
+"WRITEBACK_H", 1, UINT_MAX);
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.prop_writeback_h = prop;
+ }
+
return 0;
}
@@ -225,6 +247,12 @@ int drm_writeback_connector_init(struct drm_device *dev,
drm_object_attach_property(>base,
config->writeback_pixel_formats_property,
blob->base.id);
+
+ drm_object_attach_property(>base,
+ config->prop_writeback_w, 0);
+ drm_object_attach_property(>base,
+ config->prop_writeback_h, 0);
+
wb_connector->pixel_formats_blob_ptr = blob;
return 0;
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 8fe22ab..51c4cb2 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -515,6 +515,10 @@ struct drm_connector_state {
*/
struct drm_writeback_job *writeback_job;
+ /** @writeback_w: width of plane to write to wb buffer */
+ /** @writeback_h: height of plane to write to wb buffer */
+ uint32_t writeback_w, writeback_h;
+
/**
* @max_requested_bpc: Connector property to limit the maximum bit
* depth of the pixels.
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 7f60e8e..a0c2133 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -622,6 +622,16 @@ struct drm_mode_config {
*/
struct drm_property *prop_crtc_h;
/**
+* @prop_writeback_w: Writeback connector property for the plane
+* destination position in the writeback buffer.
+*/
+ struct drm_property *prop_writeback_w;
+ /**
+* @prop_writeback_h:
[PATCH v2 0/2] Add writeback scaling
Add support for scaling on writeback. To do this add writeback_w and writeback_h as writeback connector properties to specify the desired output dimensions. Then implement downscaling on writeback for Malidp-550 and Malidp-650 (upscaling on writeback is not supported on these devices). v2: Use 0 as default for writeback_w,h and so update range to use 1 as minimum. Ben Davis (2): drm: Add writeback_w,h properties drm/malidp: Enable writeback scaling drivers/gpu/drm/arm/malidp_crtc.c | 49 -- drivers/gpu/drm/arm/malidp_crtc.h | 12 ++ drivers/gpu/drm/arm/malidp_drv.c | 10 +++-- drivers/gpu/drm/arm/malidp_hw.c | 45 ++-- drivers/gpu/drm/arm/malidp_hw.h | 19 +++-- drivers/gpu/drm/arm/malidp_mw.c | 86 ++- drivers/gpu/drm/arm/malidp_regs.h | 1 + drivers/gpu/drm/drm_atomic_uapi.c | 8 drivers/gpu/drm/drm_writeback.c | 28 + include/drm/drm_connector.h | 4 ++ include/drm/drm_mode_config.h | 10 + 11 files changed, 211 insertions(+), 61 deletions(-) create mode 100644 drivers/gpu/drm/arm/malidp_crtc.h -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 0/2] drm: Add detection of changing of edid on between suspend and resume
This patch series fix missed detection of changing of edid on between suspend and resume. First patch fixes drm_helper_hdp_irq_event() in order to fix a below use case. Following scenario requires detection of changing of edid. 1) plug display device to a connector 2) system suspend 3) unplug 1)'s display device and plug the other display device to a connector 4) system resume It adds edid check routine when a connector status still remains as "connector_status_connected". Second patch adds a missed update of edid property of drm connector on i915. v2: Add NULL check before comparing of EDIDs. v3: Make it as part of existing drm_helper_hpd_irq_event() (Stan, Mika) v4: Rebased v5: Use a cached edid property blob data of connector instead of adding a new detected_edid variable. (Maarten) Add an using of reference count for getting a cached edid property blob data. (Maarten) v6: Fixes coding style Testcase: igt/kms_chamelium/hdmi-edid-change-during-hibernate Testcase: igt/kms_chamelium/hdmi-edid-change-during-suspend Testcase: igt/kms_chamelium/dp-edid-change-during-hibernate Testcase: igt/kms_chamelium/dp-edid-change-during-suspend v1, v2: https://patchwork.freedesktop.org/series/47680/ v3: https://patchwork.freedesktop.org/series/49298/ v4: https://patchwork.freedesktop.org/series/57397/ Gwan-gyeong Mun (2): drm: Add detection of changing of edid on between suspend and resume drm/i915: Add a missed update of edid property of drm connector drivers/gpu/drm/drm_probe_helper.c | 34 +- drivers/gpu/drm/i915/intel_dp.c| 1 + drivers/gpu/drm/i915/intel_hdmi.c | 1 + 3 files changed, 35 insertions(+), 1 deletion(-) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/2] drm: Add detection of changing of edid on between suspend and resume
The hotplug detection routine of drm_helper_hpd_irq_event() can detect
changing of status of connector, but it can not detect changing of edid.
Following scenario requires detection of changing of edid.
1) plug display device to a connector
2) system suspend
3) unplug 1)'s display device and plug the other display device to a
connector
4) system resume
It adds edid check routine when a connector status still remains as
"connector_status_connected".
v2: Add NULL check before comparing of EDIDs.
v3: Make it as part of existing drm_helper_hpd_irq_event() (Stan, Mika)
v4: Rebased
v5: Use a cached edid property blob data of connector instead of adding
a new detected_edid variable. (Maarten)
Add an using of reference count for getting a cached edid property
blob data. (Maarten)
v6: Fixes coding style.
Testcase: igt/kms_chamelium/hdmi-edid-change-during-hibernate
Testcase: igt/kms_chamelium/hdmi-edid-change-during-suspend
Testcase: igt/kms_chamelium/dp-edid-change-during-hibernate
Testcase: igt/kms_chamelium/dp-edid-change-during-suspend
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/drm_probe_helper.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 6fd08e04b323..da8aff116ca4 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -742,7 +742,16 @@ EXPORT_SYMBOL(drm_kms_helper_poll_fini);
* panels.
*
* This helper function is useful for drivers which can't or don't track
hotplug
- * interrupts for each connector.
+ * interrupts for each connector. And it also supports a detection of changing
+ * of edid on between suspend and resume when a connector status still remains
+ * as "connector_status_connected".
+ *
+ * Following scenario requires detection of changing of edid.
+ * 1) plug display device to a connector
+ * 2) system suspend
+ * 3) unplug 1)'s display device and plug the other display device to a
+ * connector
+ * 4) system resume
*
* Drivers which support hotplug interrupts for each connector individually and
* which have a more fine-grained detect logic should bypass this code and
@@ -760,6 +769,7 @@ bool drm_helper_hpd_irq_event(struct drm_device *dev)
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
enum drm_connector_status old_status;
+ struct drm_property_blob *old_edid_blob_ptr;
bool changed = false;
if (!dev->mode_config.poll_enabled)
@@ -774,6 +784,11 @@ bool drm_helper_hpd_irq_event(struct drm_device *dev)
old_status = connector->status;
+ if (connector->edid_blob_ptr)
+ old_edid_blob_ptr =
drm_property_blob_get(connector->edid_blob_ptr);
+ else
+ old_edid_blob_ptr = NULL;
+
connector->status = drm_helper_probe_detect(connector, NULL,
false);
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to
%s\n",
connector->base.id,
@@ -782,6 +797,23 @@ bool drm_helper_hpd_irq_event(struct drm_device *dev)
drm_get_connector_status_name(connector->status));
if (old_status != connector->status)
changed = true;
+
+ /* Check changing of edid when a connector status still remains
+* as "connector_status_connected".
+*/
+ if (old_edid_blob_ptr && connector->edid_blob_ptr &&
+ old_status == connector->status &&
+ old_status == connector_status_connected) {
+ if (memcmp(old_edid_blob_ptr->data,
+ connector->edid_blob_ptr->data,
+ old_edid_blob_ptr->length)) {
+ changed = true;
+ DRM_DEBUG_KMS("[CONNECTOR:%d:%s] edid
updated\n",
+ connector->base.id,
+ connector->name);
+ }
+ }
+ drm_property_blob_put(old_edid_blob_ptr);
}
drm_connector_list_iter_end(_iter);
mutex_unlock(>mode_config.mutex);
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/4] drm/atomic: rename async_{update,check} to amend_{update,check}
Hi Boris,
On 4/12/19 10:49 AM, Boris Brezillon wrote:
> Hi Helen,
>
> On Fri, 12 Apr 2019 09:58:25 -0300
> Helen Koike wrote:
>
>> Asynchronous update is the ability change the hw state at any time, not
>> only during vblank.
>>
>> Amend mode is the ability to perform 1000 commits to be applied as soon
>> as possible without waiting for 1000 vblanks.
>>
>> async updates can be seen as amend, but the opposite is not true.
>>
>> _plane_helper_funcs.atomic_async_{update,check}() was being used by
>> drivers to implement amend and not async. So rename them to amend.
>>
>> Also improve docs explaining the difference.
>>
>> If asynchronous is required, normal page flip can be performed using
>> DRM_MODE_PAGE_FLIP_ASYNC flag.
>>
>> Signed-off-by: Helen Koike
>>
>> ---
>> Hello,
>>
>> I would like to officially clarify what async update means by adding it
>> in the docs.
>> Please correct me if I am wrong, but the current async_{update,check}
>> callbacks are being used to do amend (the legacy cursor behavior), i.e.
>> to allow 1000 updates without waiting for 1000 vblanks.
>
> Right now, the semantic of async update is driver dependent. Some
> drivers will amend the last commit touching that plane (amend semantic),
> others will update the plane buffer immediately which might cause
> tearing (async semantic).
In my pov, async updates holds the properties of an amend update, so all
async updates we have are amend, but the opposite is not true.
>
>>
>> So I would like to clarify this in the docs and rename the current
>> callbacks to reflect this behaviour.
>
> I'm all for this clarification, but I don't think renaming the async
> hooks is a good idea, since some drivers will not do real 'amend'. So,
> you're changing the name, but it's still confusing :-).
>
> How about adding new hooks (and/or flags) for the AMEND case, and
> keeping the async path untouched. We can then let drivers that
> currently implement async as amend implement the amend hooks instead.
> Once you've done that, you can hook that up to the legacy cursor update
> path so that it first tries one then the other and finally falls back
> to a sync update if none of ASYNC/AMEND is possible.
I kinda did this (I re-introduced async in the last patch in the
series). I know this order is confusing, but as rockchip doesn't
implement true async, I would have to do a bunch of modifs at once to
keep the commits consistent, but I can re-work on that if it makes
things clearer.
>
>>
>> I also see that for real async updates, the flag
>> DRM_MODE_PAGE_FLIP_ASYNC can be used in a normal sync update (it is
>> already being used by some drivers actually, in the atomic path, not only
>> in the legacy page flip, at least is what I understood from
>> amdgpu_dm_atomic_commit_tail() implementation).
>
> Yes, right now, async does not necessarily imply non-block, but
> Daniel seemed to think that most users want non-block when they do an
> async page flip, so maybe it should be clarified too.
users could combine NONBLOCK flag with PAGE_FLIP_ASYNC, no? (we need to
add code for it of course).
Thanks
Helen
>
> Regards,
>
> Boris
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 2/2] drm/i915: Add a missed update of edid property of drm connector
After suspend/resume process, hotplug detection is handled by i915_hpd_poll_init_work() workqueue. While intel_hdmi_detect() or intel_dp_detect() are called, intel_hdmi_set_edid() or intel_dp_set_edid() only update an internal detect_edid variable of intel_connector. A missed update of edid property of drm_connector leads incorrect behavior of drm_helper_hpd_irq_event() on below testcases. It adds a missed update of edid property of drm connector and updates drm edid modes, while i915_hpd_poll_init_work() workqueue works. Testcase: igt/kms_chamelium/hdmi-edid-change-during-hibernate Testcase: igt/kms_chamelium/hdmi-edid-change-during-suspend Testcase: igt/kms_chamelium/dp-edid-change-during-hibernate Testcase: igt/kms_chamelium/dp-edid-change-during-suspend Signed-off-by: Gwan-gyeong Mun --- drivers/gpu/drm/i915/intel_dp.c | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index c4e36759a756..0301e58495b4 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -5379,6 +5379,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp) intel_dp->has_audio = drm_detect_monitor_audio(edid); drm_dp_cec_set_edid(_dp->aux, edid); + intel_connector_update_modes(_connector->base, edid); } static void diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index e1005d7b75fd..b53360c4d0ef 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -2493,6 +2493,7 @@ intel_hdmi_set_edid(struct drm_connector *connector) } cec_notifier_set_phys_addr_from_edid(intel_hdmi->cec_notifier, edid); + intel_connector_update_modes(connector, edid); return connected; } -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/4] drm/atomic: rename async_{update,check} to amend_{update,check}
Hi Helen,
On Fri, 12 Apr 2019 09:58:25 -0300
Helen Koike wrote:
> Asynchronous update is the ability change the hw state at any time, not
> only during vblank.
>
> Amend mode is the ability to perform 1000 commits to be applied as soon
> as possible without waiting for 1000 vblanks.
>
> async updates can be seen as amend, but the opposite is not true.
>
> _plane_helper_funcs.atomic_async_{update,check}() was being used by
> drivers to implement amend and not async. So rename them to amend.
>
> Also improve docs explaining the difference.
>
> If asynchronous is required, normal page flip can be performed using
> DRM_MODE_PAGE_FLIP_ASYNC flag.
>
> Signed-off-by: Helen Koike
>
> ---
> Hello,
>
> I would like to officially clarify what async update means by adding it
> in the docs.
> Please correct me if I am wrong, but the current async_{update,check}
> callbacks are being used to do amend (the legacy cursor behavior), i.e.
> to allow 1000 updates without waiting for 1000 vblanks.
Right now, the semantic of async update is driver dependent. Some
drivers will amend the last commit touching that plane (amend semantic),
others will update the plane buffer immediately which might cause
tearing (async semantic).
>
> So I would like to clarify this in the docs and rename the current
> callbacks to reflect this behaviour.
I'm all for this clarification, but I don't think renaming the async
hooks is a good idea, since some drivers will not do real 'amend'. So,
you're changing the name, but it's still confusing :-).
How about adding new hooks (and/or flags) for the AMEND case, and
keeping the async path untouched. We can then let drivers that
currently implement async as amend implement the amend hooks instead.
Once you've done that, you can hook that up to the legacy cursor update
path so that it first tries one then the other and finally falls back
to a sync update if none of ASYNC/AMEND is possible.
>
> I also see that for real async updates, the flag
> DRM_MODE_PAGE_FLIP_ASYNC can be used in a normal sync update (it is
> already being used by some drivers actually, in the atomic path, not only
> in the legacy page flip, at least is what I understood from
> amdgpu_dm_atomic_commit_tail() implementation).
Yes, right now, async does not necessarily imply non-block, but
Daniel seemed to think that most users want non-block when they do an
async page flip, so maybe it should be clarified too.
Regards,
Boris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102646] Screen flickering under amdgpu-experimental [buggy auto power profile]
https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #80 from Garrett --- well...even better solution: install Radeon-Profile sudo su cd /usr/bin radeon-profile boom...manual control with the radeon-profile GUI...something i've not once seen mentioned in any tutorials. as long as you know what you're card is capable of, you can manually set clock percentages and a custom fan curve. fan curve only stays active as long as radeon-profile is opened as far as i can tell -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v3 4/4] drm/atomic: hook atomic_async_{check,update} with PAGE_FLIP_ASYNC flag
On 4/12/19 9:58 AM, Helen Koike wrote:
> Add atomic_async_{check,update} hooks in drm_plane_helper_funcs.
> These hooks are called when userspace requests asyncronous page flip in
> the atomic api through the flag DRM_MODE_PAGE_FLIP_ASYNC.
>
> Update those hooks in the drivers that implement async functions, except
> for amdgpu who handles the flag in the normal path, and rockchip who
> doesn't support async page flip.
>
> Signed-off-by: Helen Koike
>
> ---
> Hi,
>
> This patch is an attempt to expose the implementation that already exist
> for true async page flips updates through atomic api when the
> DRM_MODE_PAGE_FLIP_ASYNC is used.
>
> In this commit I'm re-introducing the atomic_async_{check,update} hooks.
> I know it is a bit weird to remove them first and them re-add them, but
> I did this in the last commit to avoid any state of inconsistency
> between commits, as rockchip doesn't support async page flip and they were
> being used as amend.
> So I reverted to amend first and then re-introced async again
> tied to the DRM_MODE_PAGE_FLIP_ASYNC flag (I also think this is easier
> to read).
>
> To use async, it is required to have
> dev->mode_config.async_page_flip = true;
> but I see that only amdgpu and vc4 have this, so this patch won't take
> effect on mdp5.
> Nouveau and radeon also have this flag, but they don't implement the
> async hooks yet.
>
> Please let me know what you think.
>
> Thanks
> Helen
>
> Changes in v3: None
> Changes in v2: None
> Changes in v1: None
>
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +++
> drivers/gpu/drm/drm_atomic_helper.c | 31
> drivers/gpu/drm/drm_atomic_uapi.c | 3 +-
> drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c| 2 +
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 ++
> drivers/gpu/drm/vc4/vc4_plane.c | 2 +
> include/drm/drm_atomic.h | 2 +
> include/drm/drm_atomic_helper.h | 9 +++--
> include/drm/drm_modeset_helper_vtables.h | 37 +++
> 9 files changed, 83 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 711e7715e112..bb8a5f1997d6 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -3785,6 +3785,11 @@ static const struct drm_plane_helper_funcs
> dm_plane_helper_funcs = {
>*/
> .atomic_amend_check = dm_plane_atomic_async_check,
> .atomic_amend_update = dm_plane_atomic_async_update
> + /*
> + * Note: amdgpu takes care of DRM_MODE_PAGE_FLIP_ASYNC flag in the
> + * normal commit path, thus .atomic_async_check and .atomic_async_update
> + * are not provided here.
> + */
> };
>
> /*
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 9b0df08836c3..bfcf88359de5 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -947,16 +947,31 @@ int drm_atomic_helper_check(struct drm_device *dev,
> if (ret)
> return ret;
>
> + /*
> + * If async page flip was explicitly requested, but it is not possible,
> + * return error instead of falling back to a normal commit.
> + * If async_amend_check returns -EOPNOTSUPP, it means
> + * ->atomic_async_update hook doesn't exist, so fallback to normal
> + * commit and let the driver handle DRM_MODE_PAGE_FLIP_ASYNC flag
> + * through normal commit code path.
> + */
> + if (state->async_update) {
> + ret = drm_atomic_helper_async_amend_check(dev, state, false);
> + state->async_update = !ret;
> + return !ret || ret == -EOPNOTSUPP ? 0 : ret;
> + }
> +
> /*
>* If amend was explicitly requested, but it is not possible,
>* return error instead of falling back to a normal commit.
>*/
> if (state->amend_update)
> - return drm_atomic_helper_amend_check(dev, state);
> + return drm_atomic_helper_async_amend_check(dev, state, true);
>
> /* Legacy mode falls back to a normal commit if amend isn't possible. */
> if (state->legacy_cursor_update)
> - state->amend_update = !drm_atomic_helper_amend_check(dev,
> state);
> + state->amend_update =
> + !drm_atomic_helper_async_amend_check(dev, state, true);
>
> return 0;
> }
> @@ -1651,8 +1666,9 @@ static void commit_work(struct work_struct *work)
> * if not. Note that error just mean it can't be committed in amend mode, if
> it
> * fails the commit should be treated like a normal commit.
> */
> -int drm_atomic_helper_amend_check(struct drm_device *dev,
> -struct drm_atomic_state *state)
> +int drm_atomic_helper_async_amend_check(struct drm_device *dev,
> +
Re: [PATCH v3 1/4] drm/uapi: add documentation for atomic flags
Hello Helen,
On Fri, 12 Apr 2019 09:58:24 -0300
Helen Koike wrote:
> add a brief description of the flags used in an atomic commit
>
> Signed-off-by: Helen Koike
> ---
>
> Changes in v3: None
> Changes in v2: None
> Changes in v1: None
>
> include/uapi/drm/drm_mode.h | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 83cd1636b9be..88ef2cf04d13 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -729,7 +729,23 @@ struct drm_mode_destroy_dumb {
> __u32 handle;
> };
>
> -/* page-flip flags are valid, plus: */
> +/*
You might want to use a standard kernel/sphynx doc header so that it
can be parsed by sphynx and included in the DRM doc.
> + * drm atomic flags
> + *
> + * page-flip flags are valid, plus:
> + *
> + * DRM_MODE_ATOMIC_TEST_ONLY
> + * Used with fences to check if the Sync File is a valid one.
I think it can be used for any kind of tests, like when you want to
know if a combination of property updates is supported. It's fine
having the fence example, but I think you should be clear that it's
just one use case.
> + *
> + * DRM_MODE_ATOMIC_NONBLOCK
> + * Perform a normal atomic update but do not block the ioctl until the
> request
> + * is finished, return the ioctl call immediately.
> + *
> + * DRM_MODE_ATOMIC_ALLOW_MODESET
> + * Indicates whether a full modeset is acceptable or not.
> + */
> +
> +/* */
> #define DRM_MODE_ATOMIC_TEST_ONLY 0x0100
> #define DRM_MODE_ATOMIC_NONBLOCK 0x0200
> #define DRM_MODE_ATOMIC_ALLOW_MODESET 0x0400
Regards,
Boris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110229] glMemoryBarrier doesn't work.
https://bugs.freedesktop.org/show_bug.cgi?id=110229 --- Comment #35 from Laurent --- (In reply to Andre Klapper from comment #34) > Right. And we cannot waste time going through your custom code if you do not > provide a minimal self-contained test case. Ok next time I'll provide a test case, anyway, I'll have to do this, because, I've a lot of bugs (or crash) with new opengl features. (From opengl 3.3 to opengl 4.4 (opengl 4.5 with GL_ARB_bindless_texture is not supported by my GPU) but normally (I've the specs of my GPU here), all functionalities until opengl 4.4 should be supported) This is why my shader version is 140 and not 330. On windows I've a driver which runs opengl 3.3 without any problems but it's an old driver and some shaders doesn't seems to run properly, and most of all, only opengl 4.1 is supported by this driver, and the driver on amd website doesn't work too I had to doawnload the driver on the asus website. And I haven't the bases to code a simple driver by myself. (Even if I have the technical specifications of the r600 GPU here, as far as I don't have a simple tutorial to simply run a basic shader to display something without passing by opencl which is not supported by my GPU) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/4] drm/uapi: add documentation for atomic flags
add a brief description of the flags used in an atomic commit
Signed-off-by: Helen Koike
---
Changes in v3: None
Changes in v2: None
Changes in v1: None
include/uapi/drm/drm_mode.h | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 83cd1636b9be..88ef2cf04d13 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -729,7 +729,23 @@ struct drm_mode_destroy_dumb {
__u32 handle;
};
-/* page-flip flags are valid, plus: */
+/*
+ * drm atomic flags
+ *
+ * page-flip flags are valid, plus:
+ *
+ * DRM_MODE_ATOMIC_TEST_ONLY
+ * Used with fences to check if the Sync File is a valid one.
+ *
+ * DRM_MODE_ATOMIC_NONBLOCK
+ * Perform a normal atomic update but do not block the ioctl until the request
+ * is finished, return the ioctl call immediately.
+ *
+ * DRM_MODE_ATOMIC_ALLOW_MODESET
+ * Indicates whether a full modeset is acceptable or not.
+ */
+
+/* */
#define DRM_MODE_ATOMIC_TEST_ONLY 0x0100
#define DRM_MODE_ATOMIC_NONBLOCK 0x0200
#define DRM_MODE_ATOMIC_ALLOW_MODESET 0x0400
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/4] async vs amend - UAPI
Hi,
This patch series is an attempt to clarify some concepts and how things
are hooked inside drm.
There are two main concepts that are similar but different and are
causing some confusion:
- Asynchronous update: is the ability change the hw state at any time, not
only during vblank.
- Amend update: is the ability to perform 1000 commits to be applied as soon
as possible without waiting for 1000 vblanks.
async updates can be seen as amend, but the opposite is not true.
Please see documentation on the commit
"drm/atomic: rename async_{update,check} to amend_{update,check}"
for a more detailed explanation.
To perform an async update, we already have the DRM_MODE_PAGE_FLIP_ASYNC
flag in the atomic API and it is already being used by amdgpu in the
atomic path.
The first two commits clarifies these differences. The last two are
RFCs that exposes new async and amend features to userspace.
We introduce in this series the flag DRM_MODE_ATOMIC_AMEND to expose
the amend feature to userspace.
The main reasons to expose this through atomic api is to avoid mixing legacy
with modern/atomic API (since their interactions are not well defined)
and to be able to explicitly manage the cursor plane.
And the last commit hooks the current async implementations with the
DRM_MODE_PAGE_FLIP_ASYNC flag.
Please, see the message in each commit and the documentation that was
added for more details and let me know what you think.
Thanks
Helen
Changes in v3:
- rebase tree
- rebase on top of renaming async_update to amend_update
- improve documentation
- don't fall back to a normal commit if amend is not possible when
requested through the atomic api
Changes in v2:
- rebase tree
- do not fall back to a non-async update if if there isn't any
pending commit to amend
Changes in v1:
- https://patchwork.freedesktop.org/patch/243088/
- Only enable it if userspace requests it.
- Only allow async update for cursor type planes.
- Rename ASYNC_UPDATE for ATOMIC_AMEND.
Helen Koike (4):
drm/uapi: add documentation for atomic flags
drm/atomic: rename async_{update,check} to amend_{update,check}
drm/atomic: add ATOMIC_AMEND flag to the Atomic IOCTL.
drm/atomic: hook atomic_async_{check,update} with PAGE_FLIP_ASYNC flag
Documentation/gpu/drm-kms-helpers.rst | 8 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +-
drivers/gpu/drm/drm_atomic_helper.c | 157 ++
drivers/gpu/drm/drm_atomic_uapi.c | 9 +
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c| 6 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 12 +-
drivers/gpu/drm/vc4/vc4_kms.c | 4 +-
drivers/gpu/drm/vc4/vc4_plane.c | 6 +
include/drm/drm_atomic.h | 4 +-
include/drm/drm_atomic_helper.h | 9 +-
include/drm/drm_modeset_helper_vtables.h | 69 ++--
include/uapi/drm/drm_mode.h | 27 ++-
12 files changed, 264 insertions(+), 62 deletions(-)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RFC v3 3/4] drm/atomic: add ATOMIC_AMEND flag to the Atomic IOCTL.
This flag tells core to jump ahead the queued update if the conditions in drm_atomic_amend_check() are met. That means we are only able to do an amend update if no modeset is pending and update for the same plane is not queued. It uses the already in place infrastructure for amend updates. It is useful for cursor updates over the atomic ioctl. Otherwise in some cases updates may be delayed to the point the user will notice it. Note that for now it's only enabled for cursor planes. DRM_MODE_ATOMIC_AMEND should be passed to the Atomic IOCTL to use this feature. Signed-off-by: Gustavo Padovan Signed-off-by: Enric Balletbo i Serra [updated for upstream] Signed-off-by: Helen Koike --- Hi, This is the third attempt to introduce the new ATOMIC_AMEND flag for atomic operations, see the commit message for a more detailed description. I am sending this patch in the series as an RFC as I still have things to define/discuss. The main reasons to expose this through atomic api is to avoid mixing legacy with modern/atomic API (since their interactions are not well defined) and to be able to explicitly manage the cursor plane. The way I envision it working is: 1) userspace just use DRM_MODE_PAGE_FLIP_ASYNC if true async is desired. 2) if it fails, then userspace can try DRM_MODE_ATOMIC_AMEND if true async is not required, but a legacy cursor behavior is required 3) if amend is not possible, we can or: A) fallback to a non amend update B) fail C) add another flag to define what it should do. Right now the code does A for legacy cursor and B for atomic api using the DRM_MODE_ATOMIC_AMEND flag. Discussing with some people it seems that failing is better for Xorg, but Ozone (chrome compositor) doesn't expect the amend to fail, but I think it could just retry the same atomic commit without the AMEND flag if it wants to fallback. Alexandros also did a proof-of-concept to use this flag and draw cursors using atomic if possible on ozone (Chrome compositor) [1]. I'm sending this as an RFC for now as I still need to verify the requirements from other compositors and make some tests (and also to justify the s/async/amend renaming). Please, let me know if you detect issues with this. If not, I'll start implementing tests in igt and push the adoption in other compositors. Thanks Helen [1] https://chromium-review.googlesource.com/c/chromium/src/+/1092711 [2] https://gitlab.collabora.com/eballetbo/drm-cursor/commits/async-capability Changes in v3: - rebase tree - rebase on top of renaming async_update to amend_update - improve documentation - don't fall back to a normal commit if amend is not possible when requested through the atomic api Changes in v2: - rebase tree - do not fall back to a non-async update if if there isn't any pending commit to amend Changes in v1: - https://patchwork.freedesktop.org/patch/243088/ - Only enable it if userspace requests it. - Only allow async update for cursor type planes. - Rename ASYNC_UPDATE for ATOMIC_AMEND. drivers/gpu/drm/drm_atomic_helper.c | 39 +++-- drivers/gpu/drm/drm_atomic_uapi.c | 8 ++ include/uapi/drm/drm_mode.h | 9 ++- 3 files changed, 48 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index eb5dcd84fea7..9b0df08836c3 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -947,10 +947,18 @@ int drm_atomic_helper_check(struct drm_device *dev, if (ret) return ret; + /* +* If amend was explicitly requested, but it is not possible, +* return error instead of falling back to a normal commit. +*/ + if (state->amend_update) + return drm_atomic_helper_amend_check(dev, state); + + /* Legacy mode falls back to a normal commit if amend isn't possible. */ if (state->legacy_cursor_update) state->amend_update = !drm_atomic_helper_amend_check(dev, state); - return ret; + return 0; } EXPORT_SYMBOL(drm_atomic_helper_check); @@ -1574,12 +1582,20 @@ static void commit_work(struct work_struct *work) * The amend feature provides a way to perform 1000 updates to be applied as * soon as possible without waiting for 1000 vblanks. - * Currently, only the legacy cursor update uses amend mode, where historically, + * Legacy cursor update uses amend mode, where historically, * userspace performs several updates before the next vblank and don't want to * see a delay in the cursor's movement. * If amend is not supported, legacy cursor falls back to a normal sync update. * - * To implement the legacy cursor update, drivers should provide + * Amend can also be performed through the atomic API using the flag + * DRM_MODE_ATOMIC_AMEND. The atomic commit will fail if this flag is set but + * the driver doesn't support it. + * Amend can't perform modeset, thus atomic API will fail if
[PATCH RFC v3 4/4] drm/atomic: hook atomic_async_{check, update} with PAGE_FLIP_ASYNC flag
Add atomic_async_{check,update} hooks in drm_plane_helper_funcs.
These hooks are called when userspace requests asyncronous page flip in
the atomic api through the flag DRM_MODE_PAGE_FLIP_ASYNC.
Update those hooks in the drivers that implement async functions, except
for amdgpu who handles the flag in the normal path, and rockchip who
doesn't support async page flip.
Signed-off-by: Helen Koike
---
Hi,
This patch is an attempt to expose the implementation that already exist
for true async page flips updates through atomic api when the
DRM_MODE_PAGE_FLIP_ASYNC is used.
In this commit I'm re-introducing the atomic_async_{check,update} hooks.
I know it is a bit weird to remove them first and them re-add them, but
I did this in the last commit to avoid any state of inconsistency
between commits, as rockchip doesn't support async page flip and they were
being used as amend.
So I reverted to amend first and then re-introced async again
tied to the DRM_MODE_PAGE_FLIP_ASYNC flag (I also think this is easier
to read).
To use async, it is required to have
dev->mode_config.async_page_flip = true;
but I see that only amdgpu and vc4 have this, so this patch won't take
effect on mdp5.
Nouveau and radeon also have this flag, but they don't implement the
async hooks yet.
Please let me know what you think.
Thanks
Helen
Changes in v3: None
Changes in v2: None
Changes in v1: None
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +++
drivers/gpu/drm/drm_atomic_helper.c | 31
drivers/gpu/drm/drm_atomic_uapi.c | 3 +-
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c| 2 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 ++
drivers/gpu/drm/vc4/vc4_plane.c | 2 +
include/drm/drm_atomic.h | 2 +
include/drm/drm_atomic_helper.h | 9 +++--
include/drm/drm_modeset_helper_vtables.h | 37 +++
9 files changed, 83 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 711e7715e112..bb8a5f1997d6 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3785,6 +3785,11 @@ static const struct drm_plane_helper_funcs
dm_plane_helper_funcs = {
*/
.atomic_amend_check = dm_plane_atomic_async_check,
.atomic_amend_update = dm_plane_atomic_async_update
+ /*
+* Note: amdgpu takes care of DRM_MODE_PAGE_FLIP_ASYNC flag in the
+* normal commit path, thus .atomic_async_check and .atomic_async_update
+* are not provided here.
+*/
};
/*
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 9b0df08836c3..bfcf88359de5 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -947,16 +947,31 @@ int drm_atomic_helper_check(struct drm_device *dev,
if (ret)
return ret;
+ /*
+* If async page flip was explicitly requested, but it is not possible,
+* return error instead of falling back to a normal commit.
+* If async_amend_check returns -EOPNOTSUPP, it means
+* ->atomic_async_update hook doesn't exist, so fallback to normal
+* commit and let the driver handle DRM_MODE_PAGE_FLIP_ASYNC flag
+* through normal commit code path.
+*/
+ if (state->async_update) {
+ ret = drm_atomic_helper_async_amend_check(dev, state, false);
+ state->async_update = !ret;
+ return !ret || ret == -EOPNOTSUPP ? 0 : ret;
+ }
+
/*
* If amend was explicitly requested, but it is not possible,
* return error instead of falling back to a normal commit.
*/
if (state->amend_update)
- return drm_atomic_helper_amend_check(dev, state);
+ return drm_atomic_helper_async_amend_check(dev, state, true);
/* Legacy mode falls back to a normal commit if amend isn't possible. */
if (state->legacy_cursor_update)
- state->amend_update = !drm_atomic_helper_amend_check(dev,
state);
+ state->amend_update =
+ !drm_atomic_helper_async_amend_check(dev, state, true);
return 0;
}
@@ -1651,8 +1666,9 @@ static void commit_work(struct work_struct *work)
* if not. Note that error just mean it can't be committed in amend mode, if it
* fails the commit should be treated like a normal commit.
*/
-int drm_atomic_helper_amend_check(struct drm_device *dev,
- struct drm_atomic_state *state)
+int drm_atomic_helper_async_amend_check(struct drm_device *dev,
+ struct drm_atomic_state *state,
+ bool amend)
{
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
@@ -1695,7 +1711,7 @@
[PATCH v3 2/4] drm/atomic: rename async_{update, check} to amend_{update, check}
Asynchronous update is the ability change the hw state at any time, not
only during vblank.
Amend mode is the ability to perform 1000 commits to be applied as soon
as possible without waiting for 1000 vblanks.
async updates can be seen as amend, but the opposite is not true.
_plane_helper_funcs.atomic_async_{update,check}() was being used by
drivers to implement amend and not async. So rename them to amend.
Also improve docs explaining the difference.
If asynchronous is required, normal page flip can be performed using
DRM_MODE_PAGE_FLIP_ASYNC flag.
Signed-off-by: Helen Koike
---
Hello,
I would like to officially clarify what async update means by adding it
in the docs.
Please correct me if I am wrong, but the current async_{update,check}
callbacks are being used to do amend (the legacy cursor behavior), i.e.
to allow 1000 updates without waiting for 1000 vblanks.
So I would like to clarify this in the docs and rename the current
callbacks to reflect this behaviour.
I also see that for real async updates, the flag
DRM_MODE_PAGE_FLIP_ASYNC can be used in a normal sync update (it is
already being used by some drivers actually, in the atomic path, not only
in the legacy page flip, at least is what I understood from
amdgpu_dm_atomic_commit_tail() implementation).
Please, let me know if I misunderstood anything. Otherwise renaming and
improving the docs would put us all in sync.
Thanks!
Helen
Changes in v3: None
Changes in v2: None
Changes in v1: None
Documentation/gpu/drm-kms-helpers.rst | 8 +-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 +-
drivers/gpu/drm/drm_atomic_helper.c | 111 +-
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c| 8 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 8 +-
drivers/gpu/drm/vc4/vc4_kms.c | 4 +-
drivers/gpu/drm/vc4/vc4_plane.c | 8 +-
include/drm/drm_atomic.h | 4 +-
include/drm/drm_atomic_helper.h | 4 +-
include/drm/drm_modeset_helper_vtables.h | 38 +++---
10 files changed, 139 insertions(+), 64 deletions(-)
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index 58b375e47615..c067a196902d 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -53,12 +53,18 @@ Overview
.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c
:doc: overview
-Implementing Asynchronous Atomic Commit
+Implementing Nonblocking Atomic Commit
---
.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c
:doc: implementing nonblocking commit
+Amend Mode Atomic Commit
+
+
+.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c
+ :doc: amend mode atomic commit
+
Helper Functions Reference
--
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 2f26581b93ff..711e7715e112 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -3779,8 +3779,12 @@ static const struct drm_plane_helper_funcs
dm_plane_helper_funcs = {
.prepare_fb = dm_plane_helper_prepare_fb,
.cleanup_fb = dm_plane_helper_cleanup_fb,
.atomic_check = dm_plane_atomic_check,
- .atomic_async_check = dm_plane_atomic_async_check,
- .atomic_async_update = dm_plane_atomic_async_update
+ /*
+* FIXME: ideally, instead of hooking async updates to amend,
+* we could avoid tearing by modifying the pending commit.
+*/
+ .atomic_amend_check = dm_plane_atomic_async_check,
+ .atomic_amend_update = dm_plane_atomic_async_update
};
/*
@@ -6140,7 +6144,7 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev,
* helper, check if it can be done asynchronously for better
* performance.
*/
- state->async_update = !drm_atomic_helper_async_check(dev,
state);
+ state->amend_update = !drm_atomic_helper_amend_check(dev,
state);
}
/* Must be success */
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 2453678d1186..eb5dcd84fea7 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -948,7 +948,7 @@ int drm_atomic_helper_check(struct drm_device *dev,
return ret;
if (state->legacy_cursor_update)
- state->async_update = !drm_atomic_helper_async_check(dev,
state);
+ state->amend_update = !drm_atomic_helper_amend_check(dev,
state);
return ret;
}
@@ -1569,19 +1569,68 @@ static void commit_work(struct work_struct *work)
}
/**
- * drm_atomic_helper_async_check - check if state can be commited
asynchronously
+ * DOC: amend mode atomic commit
+ *
+ * The amend feature provides a way to perform
Re: [PATCH] video: fbdev: imxfb: add COMPILE_TEST support
Hello, On Fri, Apr 12, 2019 at 12:59:53PM +0200, Bartlomiej Zolnierkiewicz wrote: > Add COMPILE_TEST support to imxfb driver for better compile > testing coverage. > > Signed-off-by: Bartlomiej Zolnierkiewicz > --- > drivers/video/fbdev/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: b/drivers/video/fbdev/Kconfig > === > --- a/drivers/video/fbdev/Kconfig 2019-04-12 12:35:07.322174869 +0200 > +++ b/drivers/video/fbdev/Kconfig 2019-04-12 12:35:07.306174869 +0200 > @@ -334,7 +334,7 @@ config FB_SA1100 > > config FB_IMX > tristate "Freescale i.MX1/21/25/27 LCD support" > - depends on FB && ARCH_MXC > + depends on FB && (ARCH_MXC || COMPILE_TEST) > select BACKLIGHT_LCD_SUPPORT > select LCD_CLASS_DEVICE > select FB_CFB_FILLRECT I think you need something like this instead: depends FB && HAVE_CLK && HAS_IOMEM depends ARCH_MXC || COMPILE_TEST Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 6/6] drm/bridge: sii902x: Implement HDMI audio support
On 12.04.2019 13:53, Jyri Sarha wrote: > On 12/04/2019 11:52, Andrzej Hajda wrote: >> On 22.03.2019 09:06, Jyri Sarha wrote: >>> Implement HDMI audio support by using ASoC HDMI codec. The commit >>> implements the necessary callbacks and configuration for the HDMI >>> codec and registers a virtual platform device for the codec to attach. >>> >>> Signed-off-by: Jyri Sarha >>> --- >>> drivers/gpu/drm/bridge/sii902x.c | 459 ++- >>> 1 file changed, 453 insertions(+), 6 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/bridge/sii902x.c >>> b/drivers/gpu/drm/bridge/sii902x.c >>> index 358cf81c5ea4..cb12e264111d 100644 >>> --- a/drivers/gpu/drm/bridge/sii902x.c >>> +++ b/drivers/gpu/drm/bridge/sii902x.c >>> @@ -27,12 +27,15 @@ >>> #include >>> #include >>> #include >>> +#include >>> >>> #include >>> #include >>> #include >>> #include >>> >>> +#include >>> + >>> #define SII902X_TPI_VIDEO_DATA 0x0 >>> >>> #define SII902X_TPI_PIXEL_REPETITION 0x8 >>> @@ -74,6 +77,77 @@ >>> #define SII902X_AVI_POWER_STATE_MSKGENMASK(1, 0) >>> #define SII902X_AVI_POWER_STATE_D(l) ((l) & >>> SII902X_AVI_POWER_STATE_MSK) >>> >>> +/* Audio */ >>> +#define SII902X_TPI_I2S_ENABLE_MAPPING_REG 0x1f >>> +#define SII902X_TPI_I2S_CONFIG_FIFO0 (0 << 0) >>> +#define SII902X_TPI_I2S_CONFIG_FIFO1 (1 << 0) >>> +#define SII902X_TPI_I2S_CONFIG_FIFO2 (2 << 0) >>> +#define SII902X_TPI_I2S_CONFIG_FIFO3 (3 << 0) >>> +#define SII902X_TPI_I2S_LEFT_RIGHT_SWAP(1 << 2) >>> +#define SII902X_TPI_I2S_AUTO_DOWNSAMPLE(1 << 3) >>> +#define SII902X_TPI_I2S_SELECT_SD0 (0 << 4) >>> +#define SII902X_TPI_I2S_SELECT_SD1 (1 << 4) >>> +#define SII902X_TPI_I2S_SELECT_SD2 (2 << 4) >>> +#define SII902X_TPI_I2S_SELECT_SD3 (3 << 4) >>> +#define SII902X_TPI_I2S_FIFO_ENABLE(1 << 7) >>> + >>> +#define SII902X_TPI_I2S_INPUT_CONFIG_REG 0x20 >>> +#define SII902X_TPI_I2S_FIRST_BIT_SHIFT_YES(0 << 0) >>> +#define SII902X_TPI_I2S_FIRST_BIT_SHIFT_NO (1 << 0) >>> +#define SII902X_TPI_I2S_SD_DIRECTION_MSB_FIRST (0 << 1) >>> +#define SII902X_TPI_I2S_SD_DIRECTION_LSB_FIRST (1 << 1) >>> +#define SII902X_TPI_I2S_SD_JUSTIFY_LEFT(0 << 2) >>> +#define SII902X_TPI_I2S_SD_JUSTIFY_RIGHT (1 << 2) >>> +#define SII902X_TPI_I2S_WS_POLARITY_LOW(0 << 3) >>> +#define SII902X_TPI_I2S_WS_POLARITY_HIGH (1 << 3) >>> +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_128(0 << 4) >>> +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_256(1 << 4) >>> +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_384(2 << 4) >>> +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_512(3 << 4) >>> +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_768(4 << 4) >>> +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_1024 (5 << 4) >>> +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_1152 (6 << 4) >>> +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_192(7 << 4) >>> +#define SII902X_TPI_I2S_SCK_EDGE_FALLING (0 << 7) >>> +#define SII902X_TPI_I2S_SCK_EDGE_RISING(1 << 7) >>> + >>> +#define SII902X_TPI_I2S_STRM_HDR_BASE 0x21 >>> +#define SII902X_TPI_I2S_STRM_HDR_SIZE 5 >>> + >>> +#define SII902X_TPI_AUDIO_CONFIG_BYTE2_REG 0x26 >>> +#define SII902X_TPI_AUDIO_CODING_STREAM_HEADER (0 << 0) >>> +#define SII902X_TPI_AUDIO_CODING_PCM (1 << 0) >>> +#define SII902X_TPI_AUDIO_CODING_AC3 (2 << 0) >>> +#define SII902X_TPI_AUDIO_CODING_MPEG1 (3 << 0) >>> +#define SII902X_TPI_AUDIO_CODING_MP3 (4 << 0) >>> +#define SII902X_TPI_AUDIO_CODING_MPEG2 (5 << 0) >>> +#define SII902X_TPI_AUDIO_CODING_AAC (6 << 0) >>> +#define SII902X_TPI_AUDIO_CODING_DTS (7 << 0) >>> +#define SII902X_TPI_AUDIO_CODING_ATRAC (8 << 0) >>> +#define SII902X_TPI_AUDIO_MUTE_DISABLE (0 << 4) >>> +#define SII902X_TPI_AUDIO_MUTE_ENABLE (1 << 4) >>> +#define SII902X_TPI_AUDIO_LAYOUT_2_CHANNELS(0 << 5) >>> +#define SII902X_TPI_AUDIO_LAYOUT_8_CHANNELS(1 << 5) >>> +#define SII902X_TPI_AUDIO_INTERFACE_DISABLE(0 << 6) >>> +#define SII902X_TPI_AUDIO_INTERFACE_SPDIF (1 << 6) >>> +#define SII902X_TPI_AUDIO_INTERFACE_I2S(2 << 6) >>> + >>> +#define SII902X_TPI_AUDIO_CONFIG_BYTE3_REG 0x27 >>> +#define SII902X_TPI_AUDIO_FREQ_STREAM (0 << 3) >>> +#define SII902X_TPI_AUDIO_FREQ_32KHZ (1 << 3) >>> +#define SII902X_TPI_AUDIO_FREQ_44KHZ
Re: [PATCH 4/4] drm: rcar-du: lvds: Add r8a774a1 support
Hi Biju,
On 11/04/2019 15:34, Biju Das wrote:
> The LVDS encoders on RZ/G2M SoC is similar to R-Car M3-W. Add support for
> RZ/G2M (R8A774A1) SoC to the LVDS encoder driver.
>
> Signed-off-by: Biju Das
This one seems to be ok using the gen3 as far as I can tell, the PLL
configuration and layout match.
We're lacking the TCON, but that's not supported currently anyway, and
shouldn't matter here.
Reviewed-by: Kieran Bingham
> ---
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> index 7ef97b2..819561e 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -857,6 +857,7 @@ static const struct rcar_lvds_device_info
> rcar_lvds_r8a77995_info = {
> static const struct of_device_id rcar_lvds_of_table[] = {
> { .compatible = "renesas,r8a7743-lvds", .data = _lvds_gen2_info },
> { .compatible = "renesas,r8a7744-lvds", .data = _lvds_gen2_info },
> + { .compatible = "renesas,r8a774a1-lvds", .data = _lvds_gen3_info },
> { .compatible = "renesas,r8a774c0-lvds", .data =
> _lvds_r8a77990_info },
> { .compatible = "renesas,r8a7790-lvds", .data = _lvds_r8a7790_info
> },
> { .compatible = "renesas,r8a7791-lvds", .data = _lvds_gen2_info },
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: fbdev: da8xx-fb: add COMPILE_TEST support
Add COMPILE_TEST support to da8xx-fb driver for better compile testing coverage. Signed-off-by: Bartlomiej Zolnierkiewicz --- drivers/video/fbdev/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: b/drivers/video/fbdev/Kconfig === --- a/drivers/video/fbdev/Kconfig 2019-04-12 13:40:48.246274115 +0200 +++ b/drivers/video/fbdev/Kconfig 2019-04-12 13:55:50.694296842 +0200 @@ -2058,7 +2058,7 @@ config FB_SH7760 config FB_DA8XX tristate "DA8xx/OMAP-L1xx/AM335x Framebuffer support" - depends on FB && (ARCH_DAVINCI_DA8XX || SOC_AM33XX) + depends on FB && (ARCH_DAVINCI_DA8XX || SOC_AM33XX || COMPILE_TEST) select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: fbdev: gbefb: add COMPILE_TEST support
Add COMPILE_TEST support to gbefb driver for better compile
testing coverage.
While at it remove dead x86 specific code.
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/Kconfig |2 +-
drivers/video/fbdev/gbefb.c |9 ++---
2 files changed, 3 insertions(+), 8 deletions(-)
Index: b/drivers/video/fbdev/Kconfig
===
--- a/drivers/video/fbdev/Kconfig 2019-04-12 13:34:54.0 +0200
+++ b/drivers/video/fbdev/Kconfig 2019-04-12 13:40:48.246274115 +0200
@@ -673,7 +673,7 @@ config FB_HGA
config FB_GBE
bool "SGI Graphics Backend frame buffer support"
- depends on (FB = y) && SGI_IP32
+ depends on (FB = y) && (SGI_IP32 || COMPILE_TEST)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
Index: b/drivers/video/fbdev/gbefb.c
===
--- a/drivers/video/fbdev/gbefb.c 2019-04-12 11:39:45.266091209 +0200
+++ b/drivers/video/fbdev/gbefb.c 2019-04-12 13:48:00.142284992 +0200
@@ -39,9 +39,7 @@ struct gbefb_par {
int valid;
};
-#ifdef CONFIG_SGI_IP32
#define GBE_BASE 0x1600 /* SGI O2 */
-#endif
/* macro for fastest write-though access to the framebuffer */
#ifdef CONFIG_MIPS
@@ -51,10 +49,6 @@ struct gbefb_par {
#define pgprot_fb(_prot) (((_prot) & (~_CACHE_MASK)) | _CACHE_CACHABLE_NO_WA)
#endif
#endif
-#ifdef CONFIG_X86
-#define pgprot_fb(_prot) (((_prot) & ~_PAGE_CACHE_MASK) | \
- cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS))
-#endif
/*
* RAM we reserve for the frame buffer. This defines the maximum screen
@@ -1018,9 +1012,10 @@ static int gbefb_mmap(struct fb_info *in
/* remap using the fastest write-through mode on architecture */
/* try not polluting the cache when possible */
+#ifdef CONFIG_MIPS
pgprot_val(vma->vm_page_prot) =
pgprot_fb(pgprot_val(vma->vm_page_prot));
-
+#endif
/* VM_IO | VM_DONTEXPAND | VM_DONTDUMP are set by remap_pfn_range() */
/* look for the starting tile */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 6/6] drm/bridge: sii902x: Implement HDMI audio support
On 12/04/2019 11:52, Andrzej Hajda wrote: > On 22.03.2019 09:06, Jyri Sarha wrote: >> Implement HDMI audio support by using ASoC HDMI codec. The commit >> implements the necessary callbacks and configuration for the HDMI >> codec and registers a virtual platform device for the codec to attach. >> >> Signed-off-by: Jyri Sarha >> --- >> drivers/gpu/drm/bridge/sii902x.c | 459 ++- >> 1 file changed, 453 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/gpu/drm/bridge/sii902x.c >> b/drivers/gpu/drm/bridge/sii902x.c >> index 358cf81c5ea4..cb12e264111d 100644 >> --- a/drivers/gpu/drm/bridge/sii902x.c >> +++ b/drivers/gpu/drm/bridge/sii902x.c >> @@ -27,12 +27,15 @@ >> #include >> #include >> #include >> +#include >> >> #include >> #include >> #include >> #include >> >> +#include >> + >> #define SII902X_TPI_VIDEO_DATA 0x0 >> >> #define SII902X_TPI_PIXEL_REPETITION0x8 >> @@ -74,6 +77,77 @@ >> #define SII902X_AVI_POWER_STATE_MSK GENMASK(1, 0) >> #define SII902X_AVI_POWER_STATE_D(l)((l) & >> SII902X_AVI_POWER_STATE_MSK) >> >> +/* Audio */ >> +#define SII902X_TPI_I2S_ENABLE_MAPPING_REG 0x1f >> +#define SII902X_TPI_I2S_CONFIG_FIFO0(0 << 0) >> +#define SII902X_TPI_I2S_CONFIG_FIFO1(1 << 0) >> +#define SII902X_TPI_I2S_CONFIG_FIFO2(2 << 0) >> +#define SII902X_TPI_I2S_CONFIG_FIFO3(3 << 0) >> +#define SII902X_TPI_I2S_LEFT_RIGHT_SWAP (1 << 2) >> +#define SII902X_TPI_I2S_AUTO_DOWNSAMPLE (1 << 3) >> +#define SII902X_TPI_I2S_SELECT_SD0 (0 << 4) >> +#define SII902X_TPI_I2S_SELECT_SD1 (1 << 4) >> +#define SII902X_TPI_I2S_SELECT_SD2 (2 << 4) >> +#define SII902X_TPI_I2S_SELECT_SD3 (3 << 4) >> +#define SII902X_TPI_I2S_FIFO_ENABLE (1 << 7) >> + >> +#define SII902X_TPI_I2S_INPUT_CONFIG_REG0x20 >> +#define SII902X_TPI_I2S_FIRST_BIT_SHIFT_YES (0 << 0) >> +#define SII902X_TPI_I2S_FIRST_BIT_SHIFT_NO (1 << 0) >> +#define SII902X_TPI_I2S_SD_DIRECTION_MSB_FIRST (0 << 1) >> +#define SII902X_TPI_I2S_SD_DIRECTION_LSB_FIRST (1 << 1) >> +#define SII902X_TPI_I2S_SD_JUSTIFY_LEFT (0 << 2) >> +#define SII902X_TPI_I2S_SD_JUSTIFY_RIGHT(1 << 2) >> +#define SII902X_TPI_I2S_WS_POLARITY_LOW (0 << 3) >> +#define SII902X_TPI_I2S_WS_POLARITY_HIGH(1 << 3) >> +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_128 (0 << 4) >> +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_256 (1 << 4) >> +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_384 (2 << 4) >> +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_512 (3 << 4) >> +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_768 (4 << 4) >> +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_1024(5 << 4) >> +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_1152(6 << 4) >> +#define SII902X_TPI_I2S_MCLK_MULTIPLIER_192 (7 << 4) >> +#define SII902X_TPI_I2S_SCK_EDGE_FALLING(0 << 7) >> +#define SII902X_TPI_I2S_SCK_EDGE_RISING (1 << 7) >> + >> +#define SII902X_TPI_I2S_STRM_HDR_BASE 0x21 >> +#define SII902X_TPI_I2S_STRM_HDR_SIZE 5 >> + >> +#define SII902X_TPI_AUDIO_CONFIG_BYTE2_REG 0x26 >> +#define SII902X_TPI_AUDIO_CODING_STREAM_HEADER (0 << 0) >> +#define SII902X_TPI_AUDIO_CODING_PCM(1 << 0) >> +#define SII902X_TPI_AUDIO_CODING_AC3(2 << 0) >> +#define SII902X_TPI_AUDIO_CODING_MPEG1 (3 << 0) >> +#define SII902X_TPI_AUDIO_CODING_MP3(4 << 0) >> +#define SII902X_TPI_AUDIO_CODING_MPEG2 (5 << 0) >> +#define SII902X_TPI_AUDIO_CODING_AAC(6 << 0) >> +#define SII902X_TPI_AUDIO_CODING_DTS(7 << 0) >> +#define SII902X_TPI_AUDIO_CODING_ATRAC (8 << 0) >> +#define SII902X_TPI_AUDIO_MUTE_DISABLE (0 << 4) >> +#define SII902X_TPI_AUDIO_MUTE_ENABLE (1 << 4) >> +#define SII902X_TPI_AUDIO_LAYOUT_2_CHANNELS (0 << 5) >> +#define SII902X_TPI_AUDIO_LAYOUT_8_CHANNELS (1 << 5) >> +#define SII902X_TPI_AUDIO_INTERFACE_DISABLE (0 << 6) >> +#define SII902X_TPI_AUDIO_INTERFACE_SPDIF (1 << 6) >> +#define SII902X_TPI_AUDIO_INTERFACE_I2S (2 << 6) >> + >> +#define SII902X_TPI_AUDIO_CONFIG_BYTE3_REG 0x27 >> +#define SII902X_TPI_AUDIO_FREQ_STREAM (0 << 3) >> +#define SII902X_TPI_AUDIO_FREQ_32KHZ(1 << 3) >> +#define SII902X_TPI_AUDIO_FREQ_44KHZ(2 << 3) >> +#define SII902X_TPI_AUDIO_FREQ_48KHZ(3 << 3) >> +#define SII902X_TPI_AUDIO_FREQ_88KHZ(4 << 3)
Re: [PATCH 3/4] drm: rcar-du: Add R8A774A1 support
Hi Biju,
On 11/04/2019 15:34, Biju Das wrote:
> Add support for the R8A774A1 DU (which is very similar to the R8A7796 DU);
> it has one RGB output, one LVDS output and one HDMI output.
>
> Signed-off-by: Biju Das
I see Figure 35.1b across the two datasheets does show some differences
between these two parts, but the layout defined by the
rcar_du_r8a7796_info structure is compatible based on the current state
of the driver...
However, if support for the TCON/CMM is added to the DU driver - then I
think this will need to be separated.
I have seen patches this month which are trying to upstream a CMM
implementation.
With that in mind - perhaps it would be worth creating a new structure
for this part?
Otherwise the CMM would end up being enabled when it doesn't exist and
could cause problems.
--
Regards
Kieran
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 75ab17a..f7a5314 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -386,6 +386,7 @@ static const struct of_device_id rcar_du_of_table[] = {
> { .compatible = "renesas,du-r8a7744", .data = _du_r8a7743_info },
> { .compatible = "renesas,du-r8a7745", .data = _du_r8a7745_info },
> { .compatible = "renesas,du-r8a77470", .data = _du_r8a77470_info },
> + { .compatible = "renesas,du-r8a774a1", .data = _du_r8a7796_info },
> { .compatible = "renesas,du-r8a774c0", .data = _du_r8a774c0_info },
> { .compatible = "renesas,du-r8a7779", .data = _du_r8a7779_info },
> { .compatible = "renesas,du-r8a7790", .data = _du_r8a7790_info },
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/4] spi: Split spi message into max_dma_len size chunks
On Fri, Apr 12, 2019 at 12:46:44PM +0200, Lukas Wunner wrote: > On Thu, Apr 11, 2019 at 11:02:26PM +0200, Noralf Trønnes wrote: > > Den 11.04.2019 20.18, skrev Lukas Wunner: > > > Note that spi_map_buf() already splits every transfer's sglist into > > > segments that are smaller than ctlr->max_dma_len. Now all that needs > > > to be done is to amend spi-bcm2835.c to iterate over the sglist > > > and transmit it in portions which do not exceed 65535. Addressing the > > > problem at this lower level would drastically reduce the overhead > > > compared to the approach in the present patch and hence appears to be > > > more recommendable. > > In a previous version of this I suggested to Meghana to put this in the > > driver, but Mark wanted it in the core. > Do you have a link to these comments of Mark? The first version of > this patchset that I have here is v2 of March 2018 and it already > uses spi_split_transfers_maxsize(). I've never seen a version which > splits the sglist in spi-bcm2835.c (instead of splitting the transfers > in spi.c, which, again, is significantly more expensive). The basic theory is that we shouldn't be open coding the same handling in multiple drivers, they should just be able to declare their capabilities and have the core handle things as far as possible. Since we're already iterating over the whole message I'd be surprised if there were a particularly big hit in cases where we don't need to split things out, though obviously that's not been tested yet. There have also been discussions in the past about pre-cooking some of the messages so that if the client is sending the same thing a lot (or things that vary only by data) we can do a lot of the validation one time which would help. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: fbdev: atmel_lcdfb: add COMPILE_TEST support
Add COMPILE_TEST support to atmel_lcdfb driver for better compile testing coverage. Signed-off-by: Bartlomiej Zolnierkiewicz --- drivers/video/fbdev/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: b/drivers/video/fbdev/Kconfig === --- a/drivers/video/fbdev/Kconfig 2019-04-12 13:12:24.0 +0200 +++ b/drivers/video/fbdev/Kconfig 2019-04-12 13:15:03.986235226 +0200 @@ -859,7 +859,7 @@ config FB_S1D13XXX config FB_ATMEL tristate "AT91 LCD Controller support" - depends on FB && OF && HAVE_FB_ATMEL + depends on FB && OF && (HAVE_FB_ATMEL || COMPILE_TEST) select FB_BACKLIGHT select FB_CFB_FILLRECT select FB_CFB_COPYAREA ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/4] spi: Split spi message into max_dma_len size chunks
On Fri, Apr 12, 2019 at 01:16:15PM +0200, Lukas Wunner wrote: > On Fri, Apr 12, 2019 at 12:09:34PM +0100, Mark Brown wrote: > > On Fri, Apr 12, 2019 at 12:54:48PM +0200, Lukas Wunner wrote: > > > My point was that the call to spi_split_transfers_maxsize() shouldn't > > > be called on non-DMA-capable platforms in the first place (because it's > > > DMA-specific). > > It's not a DMA specific problem - there can be SPI controller > > limitations on transfer sizes too. > The call does pass in ctlr->max_dma_len though, so is clearly motivated > by a DMA limitation. Yeah, that bit is but we can have other limitations. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/4] spi: Split spi message into max_dma_len size chunks
On Fri, Apr 12, 2019 at 12:09:34PM +0100, Mark Brown wrote: > On Fri, Apr 12, 2019 at 12:54:48PM +0200, Lukas Wunner wrote: > > On Fri, Apr 12, 2019 at 10:47:21AM +0100, Mark Brown wrote: > > > I *think* we managed to fix all the architectures to at least stub out > > > the DMA interfaces, it's such a pointless thing to have conditional - > > > it really only makes a difference for build coverage. > > > My point was that the call to spi_split_transfers_maxsize() shouldn't > > be called on non-DMA-capable platforms in the first place (because it's > > DMA-specific). > > It's not a DMA specific problem - there can be SPI controller > limitations on transfer sizes too. The call does pass in ctlr->max_dma_len though, so is clearly motivated by a DMA limitation. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/4] spi: Split spi message into max_dma_len size chunks
On Fri, Apr 12, 2019 at 12:54:48PM +0200, Lukas Wunner wrote: > On Fri, Apr 12, 2019 at 10:47:21AM +0100, Mark Brown wrote: > > I *think* we managed to fix all the architectures to at least stub out > > the DMA interfaces, it's such a pointless thing to have conditional - > > it really only makes a difference for build coverage. > My point was that the call to spi_split_transfers_maxsize() shouldn't > be called on non-DMA-capable platforms in the first place (because it's > DMA-specific). It's not a DMA specific problem - there can be SPI controller limitations on transfer sizes too. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH v3 00/11] Add support for Orange Pi 3
On Thu, Apr 11, 2019 at 6:19 PM megous via linux-sunxi wrote: > > From: Ondrej Jirman > > This series implements support for Xunlong Orange Pi 3 board. > > Unfortunately, this board needs some small driver patches, so I have > split the boards DT patch into chunks that require patches for drivers > in various subsystems. > > Suggested merging plan/dependencies: > > - Pinctrl and stmmac patches are needed for ethernet support. > (patches 1-5) > - HDMI support was changed, please review. (patches 6-8) > - brcmfmac patch 9, fixing firmware file selection, can be merged > now, after review, as it doesn't depend on anything (please > review :)) > - mmc1 pinconf (patch 10) can probably be merged now, too (it will > certainly be used soon by all the other WiFi featuring boards > based on H6) > - WiFi dts patch will have to wait for H6 RTC patches, which in turn > depend on ChenYu's RTC series, to be merged. That will take a > while yet. I'm just keeping it in the series for completness. > (patch 11) Unfortunately I will not have time to tackle this for the next release. Furthermore, I'd like to do this after the new clk parenting stuff lands. Otherwise it's going to be a mess, as the clock tree is a bit convoluted compared to previous SoCs. ChenYu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/4] spi: Split spi message into max_dma_len size chunks
On Fri, Apr 12, 2019 at 10:47:21AM +0100, Mark Brown wrote: > On Thu, Apr 11, 2019 at 11:02:26PM +0200, Noralf Trønnes wrote: > > Den 11.04.2019 20.18, skrev Lukas Wunner: > > > On Thu, Apr 11, 2019 at 06:42:33PM +0200, Noralf Trønnes wrote: > > > > @@ -1299,6 +1299,11 @@ static void __spi_pump_messages(struct > > > > spi_controller *ctlr, bool in_kthread) > > > > > trace_spi_message_start(ctlr->cur_msg); > > > > > + ret = spi_split_transfers_maxsize(ctlr, ctlr->cur_msg, > > > > ctlr->max_dma_len, > > > > + GFP_KERNEL | GFP_DMA); > > > > Um, shouldn't this be ifdef'ed to CONFIG_HAS_DMA? > > > Maybe, I don't know. Mark didn't mentioned it when he commented on a > > previous version of this. Some hate ifdef's and want to avoid them, some > > don't. > > I *think* we managed to fix all the architectures to at least stub out > the DMA interfaces, it's such a pointless thing to have conditional - > it really only makes a difference for build coverage. My point was that the call to spi_split_transfers_maxsize() shouldn't be called on non-DMA-capable platforms in the first place (because it's DMA-specific). > On Fri, Apr 12, 2019 at 12:03:35PM +0200, ker...@martin.sperl.org wrote: > > There is a register of the SPI controller where you have to configure the > > number of bytes that it will request via DMA (primarily support transfers > > that are not a multiple of 4 - the data is transferred by DMA as words). > > So it is not really related to the general DMA implementation but to the > > DMA (request) support of the SPI controller. Right, if the transfer is not a multiple of 4, the DMA engine will write up to 3 surplus bytes to the TX FIFO. The SPI controller knows how many bytes it has to send because the length is set via its DLEN register first. Internally it counts down the DLEN register to zero and then stops clocking out bytes. The surplus bytes written by the DMA engine are thus left as residue in the TX FIFO and have to be flushed by setting the CLEAR_TX bit in the CS register. Thanks, Lukas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: fbdev: pxa168fb: add COMPILE_TEST support
Add COMPILE_TEST support to pxa168fb driver for better compile testing coverage. Signed-off-by: Bartlomiej Zolnierkiewicz --- drivers/video/fbdev/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: b/drivers/video/fbdev/Kconfig === --- a/drivers/video/fbdev/Kconfig 2019-04-12 12:35:09.038174913 +0200 +++ b/drivers/video/fbdev/Kconfig 2019-04-12 12:35:09.034174912 +0200 @@ -1732,7 +1732,7 @@ config FB_68328 config FB_PXA168 tristate "PXA168/910 LCD framebuffer support" - depends on FB && (CPU_PXA168 || CPU_PXA910) + depends on FB && (CPU_PXA168 || CPU_PXA910 || COMPILE_TEST) select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: fbdev: imxfb: add COMPILE_TEST support
Add COMPILE_TEST support to imxfb driver for better compile testing coverage. Signed-off-by: Bartlomiej Zolnierkiewicz --- drivers/video/fbdev/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: b/drivers/video/fbdev/Kconfig === --- a/drivers/video/fbdev/Kconfig 2019-04-12 12:35:07.322174869 +0200 +++ b/drivers/video/fbdev/Kconfig 2019-04-12 12:35:07.306174869 +0200 @@ -334,7 +334,7 @@ config FB_SA1100 config FB_IMX tristate "Freescale i.MX1/21/25/27 LCD support" - depends on FB && ARCH_MXC + depends on FB && (ARCH_MXC || COMPILE_TEST) select BACKLIGHT_LCD_SUPPORT select LCD_CLASS_DEVICE select FB_CFB_FILLRECT ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/4] spi: Split spi message into max_dma_len size chunks
On Thu, Apr 11, 2019 at 11:02:26PM +0200, Noralf Trønnes wrote: > Den 11.04.2019 20.18, skrev Lukas Wunner: > > On Thu, Apr 11, 2019 at 06:42:33PM +0200, Noralf Trønnes wrote: > >> @@ -1299,6 +1299,11 @@ static void __spi_pump_messages(struct > >> spi_controller *ctlr, bool in_kthread) > >> > >>trace_spi_message_start(ctlr->cur_msg); > >> > >> + ret = spi_split_transfers_maxsize(ctlr, ctlr->cur_msg, > >> ctlr->max_dma_len, > >> +GFP_KERNEL | GFP_DMA); > > > > Um, shouldn't this be ifdef'ed to CONFIG_HAS_DMA? > > Maybe, I don't know. Mark didn't mentioned it when he commented on a > previous version of this. Some hate ifdef's and want to avoid them, some > don't. The above call is clearly only necessary if DMA is present and all the DMA-specific functionality in spi.c is ifdef'ed to CONFIG_HAS_DMA, so the above should likewise only be compiled in if DMA is present. Regardless whether this is achieved with an #ifdef or an empty inline stub for the non-DMA case. > > > Some drivers like spi_bcm2835 have a max size on DMA transfers. Work > > > around this by splitting up the transfer if necessary. > > > > This feels like a very expensive solution to the problem: Large transfers > > are split into multiple smaller transfers (requiring lots of overhead to > > allocate and populate the structures) and the split transfers seem to be > > cached for later reuse. > > > > Only drivers that set ->max_dma_len will be split, and only when the > length is bigger. The issue on the BCM2385 is that the (non-Lite) DMA channels have a max length of 1 GByte but the SPI controller has a 65535 byte limit. There are three other drivers which set max_dma_len, I'm not sure if they suffer from the same issue as the BCM2835, but this patch causes additional overhead for them so the driver maintainers / main authors should at least be cc'ed. > I can't see any caching with a quick glance, where do you see it? Misunderstanding of the code on my part, sorry. I thought spi_res_release() wouldn't be called until the spi_message is freed, in which case the split transfers would be kept around (cached) for retransmissions of the same message. But I notice now that spi_res_release() is already called upon finishing the first transmission of the spi_message, hence the split transfers are gone and need to be reconstructed on retransmission. > > Note that spi_map_buf() already splits every transfer's sglist into > > segments that are smaller than ctlr->max_dma_len. Now all that needs > > to be done is to amend spi-bcm2835.c to iterate over the sglist > > and transmit it in portions which do not exceed 65535. Addressing the > > problem at this lower level would drastically reduce the overhead > > compared to the approach in the present patch and hence appears to be > > more recommendable. > > In a previous version of this I suggested to Meghana to put this in the > driver, but Mark wanted it in the core. Do you have a link to these comments of Mark? The first version of this patchset that I have here is v2 of March 2018 and it already uses spi_split_transfers_maxsize(). I've never seen a version which splits the sglist in spi-bcm2835.c (instead of splitting the transfers in spi.c, which, again, is significantly more expensive). Thanks, Lukas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109461] [amdgpu/radeonsi,HAWAII] Hand of Fate 2 leads to GPU lock up (display powered off, SSH works, keyboard dead): "flip_done timed out"
https://bugs.freedesktop.org/show_bug.cgi?id=109461 --- Comment #3 from Hubert Kario --- did you try to monitor temperature while running the game? Did you try to reproduce it with something like glmark2 or FurMark? see also bug 109466 comment 9 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] dt-bindings: display: renesas: lvds: Document r8a774a1 bindings
Hi Biju, Thank you for the patch, On 11/04/2019 15:34, Biju Das wrote: > Document the RZ/G2M (R8A774A1) LVDS bindings. > > Signed-off-by: Biju Das This looks good. Reviewed-by: Kieran Bingham > --- > Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt > b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt > index 900a884..86a691a 100644 > --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt > @@ -9,6 +9,7 @@ Required properties: > - compatible : Shall contain one of >- "renesas,r8a7743-lvds" for R8A7743 (RZ/G1M) compatible LVDS encoders >- "renesas,r8a7744-lvds" for R8A7744 (RZ/G1N) compatible LVDS encoders > + - "renesas,r8a774a1-lvds" for R8A774A1 (RZ/G2M) compatible LVDS encoders >- "renesas,r8a774c0-lvds" for R8A774C0 (RZ/G2E) compatible LVDS encoders >- "renesas,r8a7790-lvds" for R8A7790 (R-Car H2) compatible LVDS encoders >- "renesas,r8a7791-lvds" for R8A7791 (R-Car M2-W) compatible LVDS encoders > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109466] Frozen display with Radeon RX 580 and Open Source Drivers under GNU/Linux Debian Sid
https://bugs.freedesktop.org/show_bug.cgi?id=109466 --- Comment #9 from Hubert Kario --- I'm experiencing similar issues with R9 290X. But after trying to reproduce it few times (crash in Witcher III, crash while running glmark2) I'm getting convinced that it's actually a temperature problem - the time it crashed with glmark2, the GPU reached 105°C. And now that I kept it under 95°C (by limiting the power to 100W), it haven't crashed during the few times I did run glmark2. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/sun4i: dw-hdmi: Bit bang CEC on some SoCs
On 4/1/19 9:15 PM, Jernej Skrabec wrote:
> All DW HDMI controllers used by Allwinner SoCs include CEC controller.
> However, due to additional logic put between CEC controller and pins,
> CEC communication doesn't work well on some of them.
>
> Based on observations, it seems that only outgoing messages are
> properly transmitted. It's possible that it would still work correctly
> if pins are switched between input and output mode manually in right
> moment. But that's very error prone. It's better and easier just to bit
> bang protocol.
>
> Enable bit banging just for controller and phy combination found in H3
> and other 40nm SoCs. Other combinations work (H6) or the status is
> unknown (A83T).
>
> Signed-off-by: Jernej Skrabec
> ---
> drivers/gpu/drm/sun4i/Kconfig | 10
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 11
> drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 83 +-
> 3 files changed, 102 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
> index 1dbbc3a1b763..7149c72e44c8 100644
> --- a/drivers/gpu/drm/sun4i/Kconfig
> +++ b/drivers/gpu/drm/sun4i/Kconfig
> @@ -60,6 +60,16 @@ config DRM_SUN8I_DW_HDMI
> DesignWare HDMI controller with custom HDMI PHY. If M is
> selected the module will be called sun8i_dw_hdmi.
>
> +config DRM_SUN8I_DW_HDMI_CEC
> + bool "Allwinner DesignWare HDMI CEC Support for 40nm SoCs"
I'm not sure mentioning "DesignWare" here is right. The CEC support
(as I understand it) bypasses the DW entirely and is really a sunxi
specific implementation.
> + depends on DRM_SUN8I_DW_HDMI
> + select CEC_CORE
> + select CEC_PIN
> + help
> + Choose this option if you have an 40nm Allwinner SoC with
> + the DesignWare HDMI controller with custom HDMI PHY and
> + you want to use CEC.
> +
> config DRM_SUN8I_MIXER
> tristate "Support for Allwinner Display Engine 2.0 Mixer"
> default MACH_SUN8I
> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> index 720c5aa8adc1..49ca001923e3 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
>
> #define SUN8I_HDMI_PHY_DBG_CTRL_REG 0x
> #define SUN8I_HDMI_PHY_DBG_CTRL_PX_LOCK BIT(0)
> @@ -144,6 +145,13 @@
> #define SUN8I_HDMI_PHY_ANA_STS_RCAL_MASK GENMASK(5, 0)
>
> #define SUN8I_HDMI_PHY_CEC_REG 0x003c
> +#define SUN8I_HDMI_PHY_CEC_PIN_CTRL BIT(7)
> +/*
> + * Documentation says that this bit is output enable. However,
> + * it seems that this bit is actually output disable.
> + */
> +#define SUN8I_HDMI_PHY_CEC_OUT_DIS BIT(2)
> +#define SUN8I_HDMI_PHY_CEC_IN_DATA BIT(1)
>
> struct sun8i_hdmi_phy;
>
> @@ -151,6 +159,7 @@ struct sun8i_hdmi_phy_variant {
> bool has_phy_clk;
> bool has_second_pll;
> unsigned int is_custom_phy : 1;
> + unsigned int bit_bang_cec : 1;
> const struct dw_hdmi_curr_ctrl *cur_ctr;
> const struct dw_hdmi_mpll_config *mpll_cfg;
> const struct dw_hdmi_phy_config *phy_cfg;
> @@ -163,6 +172,8 @@ struct sun8i_hdmi_phy_variant {
> };
>
> struct sun8i_hdmi_phy {
> + struct cec_adapter *cec_adapter;
> + struct cec_notifier *cec_notifier;
> struct clk *clk_bus;
> struct clk *clk_mod;
> struct clk *clk_phy;
> diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> index 66ea3a902e36..8fd6bf91714e 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
> @@ -503,8 +503,9 @@ static void sun8i_hdmi_phy_init_h3(struct sun8i_hdmi_phy
> *phy)
> regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_PLL_CFG1_REG,
> SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK, 0);
>
> - /* set HW control of CEC pins */
> - regmap_write(phy->regs, SUN8I_HDMI_PHY_CEC_REG, 0);
> + /* manual control of CEC pins */
> + regmap_write(phy->regs, SUN8I_HDMI_PHY_CEC_REG,
> + SUN8I_HDMI_PHY_CEC_PIN_CTRL);
>
> /* read calibration data */
> regmap_read(phy->regs, SUN8I_HDMI_PHY_ANA_STS_REG, );
> @@ -530,8 +531,49 @@ void sun8i_hdmi_phy_set_ops(struct sun8i_hdmi_phy *phy,
> plat_data->cur_ctr = variant->cur_ctr;
> plat_data->phy_config = variant->phy_cfg;
> }
> + plat_data->disable_cec = phy->variant->bit_bang_cec;
> }
>
> +#ifdef CONFIG_DRM_SUN8I_DW_HDMI_CEC
> +static bool sun8i_hdmi_phy_cec_pin_read(struct cec_adapter *adap)
> +{
> + struct sun8i_hdmi_phy *phy = cec_get_drvdata(adap);
> + unsigned int val;
> +
> + regmap_read(phy->regs, SUN8I_HDMI_PHY_CEC_REG, );
> +
> + return val & SUN8I_HDMI_PHY_CEC_IN_DATA;
>
Re: [PATCH v4 2/4] spi: Split spi message into max_dma_len size chunks
On Fri, Apr 12, 2019 at 12:03:35PM +0200, ker...@martin.sperl.org wrote: > > On 12.04.2019, at 11:47, Mark Brown wrote: > >> In a previous version of this I suggested to Meghana to put this in the > >> driver, but Mark wanted it in the core. > > If we want to do this at a lower level the DMA code could hide this > > limitation from the upper layers; presumably the SPI driver isn't the > > only thing that might run into this. > For clarification: > There is a register of the SPI controller where you have to configure the > number of bytes that it will request via DMA (primarily support transfers > that are not a multiple of 4 - the data is transferred by DMA as words). > So it is not really related to the general DMA implementation but to the > DMA (request) support of the SPI controller. Ah, I see. That's unfortunate :/ signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] spi: Add spi_is_bpw_supported()
On Fri, Apr 12, 2019 at 11:41:30AM +0200, Noralf Trønnes wrote: > This let SPI clients check if the controller supports a particular word > width. drivers/gpu/drm/tinydrm/mipi-dbi.c will use this to determine if > the controller supports 16-bit for RGB565 pixels. If it doesn't it will > swap the bytes before transfer on little endian machines. The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b: Linux 5.1-rc1 (2019-03-17 14:22:26 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git tags/spi-bpw-is-supported for you to fetch changes up to e6f3f7e4dc76eb8d8a546dc66621a02c5c84f4ac: spi: Add spi_is_bpw_supported() (2019-04-12 11:13:36 +0100) spi: Add spi_is_bpw_supported() Lets client drivers check and potentially handle issues. Noralf Trønnes (1): spi: Add spi_is_bpw_supported() include/linux/spi/spi.h | 20 1 file changed, 20 insertions(+) signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/2] drm/sun4i: dw-hdmi: Improve CEC support
Hi Jernej, On 4/1/19 9:15 PM, Jernej Skrabec wrote: > It turns out that additional logic between HDMI CEC controller and > pins on PHY on some Allwinner SoCs prevents proper communication. > It might be possible to fix it, but it's much easier and less error > prone to just directly drive pins using software implementation of > CEC protocol. 1) Please CC linux-media as well, I had almost missed this series. 2) Is this a SoC limitation or a board limitation? 3) Is the bit-banging support sunxi specific? Or is it still using some DW CEC functionality? It appears to be sunxi specific. 4) I had an old patch series: https://www.spinics.net/lists/dri-devel/msg170232.html Rob Herring disagreed with that, but the discussion fizzled out at the end. I still think doing this in the device tree is the right approach since this is very much hardware related. If the DW CEC implementation doesn't work for some reason (CEC pins not hooked up, or for other reasons non-functional), then it should be disabled in the device tree. So then adding a new SUN8I option to enable bitbanging CEC support seems logical. Regards, Hans > > Let me know what do you think. > > Best regards, > Jernej > > Changes from v1: > - renamed is_cec_unusable to disable_cec > - added review-by tag > > Jernej Skrabec (2): > drm/bridge/synopsys: dw-hdmi: Add an option to suppress loading CEC > driver > drm/sun4i: dw-hdmi: Bit bang CEC on some SoCs > > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +- > drivers/gpu/drm/sun4i/Kconfig | 10 +++ > drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 11 +++ > drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c| 83 ++- > include/drm/bridge/dw_hdmi.h | 2 + > 5 files changed, 105 insertions(+), 3 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: remove redundant 'default n' from Kconfig
On Fri, 12 Apr 2019, Bartlomiej Zolnierkiewicz wrote:
> 'default n' is the default value for any bool or tristate Kconfig
> setting so there is no need to write it explicitly.
>
> Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
> is not set' for visible symbols") the Kconfig behavior is the same
> regardless of 'default n' being present or not:
>
> ...
> One side effect of (and the main motivation for) this change is making
> the following two definitions behave exactly the same:
>
> config FOO
> bool
>
> config FOO
> bool
> default n
>
> With this change, neither of these will generate a
> '# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
> That might make it clearer to people that a bare 'default n' is
> redundant.
> ...
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
> ---
> drivers/gpu/drm/Kconfig |5 -
> drivers/gpu/drm/amd/amdgpu/Kconfig |1 -
> drivers/gpu/drm/arm/Kconfig |1 -
> drivers/gpu/drm/exynos/Kconfig |2 --
> drivers/gpu/drm/i915/Kconfig|3 ---
> drivers/gpu/drm/i915/Kconfig.debug | 13 -
For i915,
Acked-by: Jani Nikula
and can be merged through whichever tree you like.
> drivers/gpu/drm/msm/Kconfig |2 --
> drivers/gpu/drm/nouveau/Kconfig |2 --
> drivers/gpu/drm/omapdrm/Kconfig |1 -
> drivers/gpu/drm/omapdrm/dss/Kconfig |6 --
> 10 files changed, 36 deletions(-)
>
> Index: b/drivers/gpu/drm/Kconfig
> ===
> --- a/drivers/gpu/drm/Kconfig 2019-04-12 11:42:30.070095359 +0200
> +++ b/drivers/gpu/drm/Kconfig 2019-04-12 11:42:30.066095359 +0200
> @@ -37,7 +37,6 @@ config DRM_DP_AUX_CHARDEV
>
> config DRM_DEBUG_MM
> bool "Insert extra checks and debug info into the DRM range managers"
> - default n
> depends on DRM=y
> depends on STACKTRACE_SUPPORT
> select STACKDEPOT
> @@ -56,7 +55,6 @@ config DRM_DEBUG_SELFTEST
> select PRIME_NUMBERS
> select DRM_LIB_RANDOM
> select DRM_KMS_HELPER
> - default n
> help
> This option provides kernel modules that can be used to run
> various selftests on parts of the DRM api. This option is not
> @@ -113,7 +111,6 @@ config DRM_FBDEV_OVERALLOC
> config DRM_FBDEV_LEAK_PHYS_SMEM
> bool "Shamelessly allow leaking of fbdev physical address (DANGEROUS)"
> depends on DRM_FBDEV_EMULATION && EXPERT
> - default n
> help
> In order to keep user-space compatibility, we want in certain
> use-cases to keep leaking the fbdev physical address to the
> @@ -247,7 +244,6 @@ config DRM_VKMS
> tristate "Virtual KMS (EXPERIMENTAL)"
> depends on DRM
> select DRM_KMS_HELPER
> - default n
> help
> Virtual Kernel Mode-Setting (VKMS) is used for testing or for
> running GPU in a headless machines. Choose this option to get
> @@ -424,4 +420,3 @@ config DRM_PANEL_ORIENTATION_QUIRKS
>
> config DRM_LIB_RANDOM
> bool
> - default n
> Index: b/drivers/gpu/drm/amd/amdgpu/Kconfig
> ===
> --- a/drivers/gpu/drm/amd/amdgpu/Kconfig 2019-04-12 11:42:30.070095359
> +0200
> +++ b/drivers/gpu/drm/amd/amdgpu/Kconfig 2019-04-12 11:42:30.066095359
> +0200
> @@ -35,7 +35,6 @@ config DRM_AMDGPU_GART_DEBUGFS
> bool "Allow GART access through debugfs"
> depends on DRM_AMDGPU
> depends on DEBUG_FS
> - default n
> help
> Selecting this option creates a debugfs file to inspect the mapped
> pages. Uses more memory for housekeeping, enable only for debugging.
> Index: b/drivers/gpu/drm/arm/Kconfig
> ===
> --- a/drivers/gpu/drm/arm/Kconfig 2019-04-12 11:42:30.070095359 +0200
> +++ b/drivers/gpu/drm/arm/Kconfig 2019-04-12 11:42:30.066095359 +0200
> @@ -16,7 +16,6 @@ config DRM_HDLCD
> config DRM_HDLCD_SHOW_UNDERRUN
> bool "Show underrun conditions"
> depends on DRM_HDLCD
> - default n
> help
> Enable this option to show in red colour the pixels that the
> HDLCD device did not fetch from framebuffer due to underrun
> Index: b/drivers/gpu/drm/exynos/Kconfig
> ===
> --- a/drivers/gpu/drm/exynos/Kconfig 2019-04-12 11:42:30.070095359 +0200
> +++ b/drivers/gpu/drm/exynos/Kconfig 2019-04-12 11:42:30.066095359 +0200
> @@ -46,7 +46,6 @@ config DRM_EXYNOS_DPI
> bool "Parallel output"
> depends on DRM_EXYNOS_FIMD
> select DRM_PANEL
> - default n
> help
> This enables support for Exynos parallel output.
>
> @@ -55,7 +54,6 @@ config DRM_EXYNOS_DSI
> depends on DRM_EXYNOS_FIMD || DRM_EXYNOS5433_DECON ||
Re: [PATCH v2 5/5] drm/selftests: Add command line parser selftests
Hi Maxime, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v5.1-rc4 next-20190411] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Maxime-Ripard/drm-modes-Rewrite-the-command-line-parser/20190412-122837 config: x86_64-rhel (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): drivers/gpu/drm/selftests/test-drm_cmdline_parser.o: In function `test_drm_cmdline_init': >> test-drm_cmdline_parser.c:(.init.text+0x0): multiple definition of >> `init_module' drivers/gpu/drm/selftests/test-drm_modeset_common.o:test-drm_modeset_common.c:(.init.text+0x0): first defined here --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: remove redundant 'default n' from Kconfig
'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.
Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not:
...
One side effect of (and the main motivation for) this change is making
the following two definitions behave exactly the same:
config FOO
bool
config FOO
bool
default n
With this change, neither of these will generate a
'# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
That might make it clearer to people that a bare 'default n' is
redundant.
...
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/gpu/drm/Kconfig |5 -
drivers/gpu/drm/amd/amdgpu/Kconfig |1 -
drivers/gpu/drm/arm/Kconfig |1 -
drivers/gpu/drm/exynos/Kconfig |2 --
drivers/gpu/drm/i915/Kconfig|3 ---
drivers/gpu/drm/i915/Kconfig.debug | 13 -
drivers/gpu/drm/msm/Kconfig |2 --
drivers/gpu/drm/nouveau/Kconfig |2 --
drivers/gpu/drm/omapdrm/Kconfig |1 -
drivers/gpu/drm/omapdrm/dss/Kconfig |6 --
10 files changed, 36 deletions(-)
Index: b/drivers/gpu/drm/Kconfig
===
--- a/drivers/gpu/drm/Kconfig 2019-04-12 11:42:30.070095359 +0200
+++ b/drivers/gpu/drm/Kconfig 2019-04-12 11:42:30.066095359 +0200
@@ -37,7 +37,6 @@ config DRM_DP_AUX_CHARDEV
config DRM_DEBUG_MM
bool "Insert extra checks and debug info into the DRM range managers"
- default n
depends on DRM=y
depends on STACKTRACE_SUPPORT
select STACKDEPOT
@@ -56,7 +55,6 @@ config DRM_DEBUG_SELFTEST
select PRIME_NUMBERS
select DRM_LIB_RANDOM
select DRM_KMS_HELPER
- default n
help
This option provides kernel modules that can be used to run
various selftests on parts of the DRM api. This option is not
@@ -113,7 +111,6 @@ config DRM_FBDEV_OVERALLOC
config DRM_FBDEV_LEAK_PHYS_SMEM
bool "Shamelessly allow leaking of fbdev physical address (DANGEROUS)"
depends on DRM_FBDEV_EMULATION && EXPERT
- default n
help
In order to keep user-space compatibility, we want in certain
use-cases to keep leaking the fbdev physical address to the
@@ -247,7 +244,6 @@ config DRM_VKMS
tristate "Virtual KMS (EXPERIMENTAL)"
depends on DRM
select DRM_KMS_HELPER
- default n
help
Virtual Kernel Mode-Setting (VKMS) is used for testing or for
running GPU in a headless machines. Choose this option to get
@@ -424,4 +420,3 @@ config DRM_PANEL_ORIENTATION_QUIRKS
config DRM_LIB_RANDOM
bool
- default n
Index: b/drivers/gpu/drm/amd/amdgpu/Kconfig
===
--- a/drivers/gpu/drm/amd/amdgpu/Kconfig2019-04-12 11:42:30.070095359
+0200
+++ b/drivers/gpu/drm/amd/amdgpu/Kconfig2019-04-12 11:42:30.066095359
+0200
@@ -35,7 +35,6 @@ config DRM_AMDGPU_GART_DEBUGFS
bool "Allow GART access through debugfs"
depends on DRM_AMDGPU
depends on DEBUG_FS
- default n
help
Selecting this option creates a debugfs file to inspect the mapped
pages. Uses more memory for housekeeping, enable only for debugging.
Index: b/drivers/gpu/drm/arm/Kconfig
===
--- a/drivers/gpu/drm/arm/Kconfig 2019-04-12 11:42:30.070095359 +0200
+++ b/drivers/gpu/drm/arm/Kconfig 2019-04-12 11:42:30.066095359 +0200
@@ -16,7 +16,6 @@ config DRM_HDLCD
config DRM_HDLCD_SHOW_UNDERRUN
bool "Show underrun conditions"
depends on DRM_HDLCD
- default n
help
Enable this option to show in red colour the pixels that the
HDLCD device did not fetch from framebuffer due to underrun
Index: b/drivers/gpu/drm/exynos/Kconfig
===
--- a/drivers/gpu/drm/exynos/Kconfig2019-04-12 11:42:30.070095359 +0200
+++ b/drivers/gpu/drm/exynos/Kconfig2019-04-12 11:42:30.066095359 +0200
@@ -46,7 +46,6 @@ config DRM_EXYNOS_DPI
bool "Parallel output"
depends on DRM_EXYNOS_FIMD
select DRM_PANEL
- default n
help
This enables support for Exynos parallel output.
@@ -55,7 +54,6 @@ config DRM_EXYNOS_DSI
depends on DRM_EXYNOS_FIMD || DRM_EXYNOS5433_DECON || DRM_EXYNOS7_DECON
select DRM_MIPI_DSI
select DRM_PANEL
- default n
help
This enables support for Exynos MIPI-DSI device.
Index: b/drivers/gpu/drm/i915/Kconfig
===
[v3 7/7] drm/i915: Enable advance gamma mode
Enable advance gamma modes based on client
caps.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_color.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index edf5ff8..36604c16 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -926,8 +926,9 @@ static void icl_load_luts(const struct intel_crtc_state
*crtc_state)
if ((crtc_state->gamma_mode & GAMMA_MODE_MODE_MASK) ==
GAMMA_MODE_MODE_8BIT) {
i9xx_load_luts(crtc_state);
- } else if (crtc_state->base.gamma_mode_type ==
- MULTI_SEGMENTED_GAMMA_MODE_12BIT) {
+ } else if ((crtc_state->base.gamma_mode_type ==
+ MULTI_SEGMENTED_GAMMA_MODE_12BIT) &&
+ crtc_state->base.advance_gamma_mode_active) {
icl_load_gamma_multi_segmented_lut(crtc_state, 0);
} else {
bdw_load_lut_10(crtc, gamma_lut, PAL_PREC_INDEX_VALUE(0));
@@ -1352,12 +1353,13 @@ static u32 icl_gamma_mode(struct intel_crtc_state
*crtc_state)
!crtc_state->c8_planes)
gamma_mode |= POST_CSC_GAMMA_ENABLE;
- if (!crtc_state->base.gamma_lut ||
- crtc_state_is_legacy_gamma(crtc_state))
- gamma_mode |= GAMMA_MODE_MODE_8BIT;
- else if (crtc_state->base.gamma_mode_type ==
-MULTI_SEGMENTED_GAMMA_MODE_12BIT)
+ if (crtc_state->base.gamma_mode_type ==
+ MULTI_SEGMENTED_GAMMA_MODE_12BIT &&
+crtc_state->base.advance_gamma_mode_active)
gamma_mode |= GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED;
+ else if (!crtc_state->base.gamma_lut ||
+crtc_state_is_legacy_gamma(crtc_state))
+ gamma_mode |= GAMMA_MODE_MODE_8BIT;
else
gamma_mode |= GAMMA_MODE_MODE_10BIT;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v3 6/7] drm: Add Client Cap for advance gamma mode
Introduced a client cap for advance cap mode
capability. Userspace should set this to get
to be able to use the new gamma_mode property.
If this is not set, driver will work in legacy
mode.
Suggested-by: Ville Syrjälä
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_atomic_uapi.c | 3 +++
drivers/gpu/drm/drm_ioctl.c | 5 +
include/drm/drm_atomic.h | 1 +
include/drm/drm_crtc.h| 7 +++
include/drm/drm_file.h| 8
include/uapi/drm/drm.h| 2 ++
6 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index d85e0c9..590c87a 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -974,6 +974,8 @@ int drm_atomic_set_property(struct drm_atomic_state *state,
break;
}
+ crtc_state->advance_gamma_mode_active =
+ state->advance_gamma_mode_active;
ret = drm_atomic_crtc_set_property(crtc,
crtc_state, prop, prop_value);
break;
@@ -1297,6 +1299,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
state->acquire_ctx =
state->allow_modeset = !!(arg->flags & DRM_MODE_ATOMIC_ALLOW_MODESET);
+ state->advance_gamma_mode_active = file_priv->advance_gamma_mode_active;
retry:
copied_objs = 0;
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index d337f16..e593a4c 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -348,6 +348,11 @@ static int drm_getcap(struct drm_device *dev, void *data,
struct drm_file *file_
return -EINVAL;
file_priv->writeback_connectors = req->value;
break;
+ case DRM_CLIENT_CAP_ADVANCE_GAMMA_MODES:
+ if (req->value > 1)
+ return -EINVAL;
+ file_priv->advance_gamma_mode_active = req->value;
+ break;
default:
return -EINVAL;
}
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 824a5ed..02c1a68 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -338,6 +338,7 @@ struct drm_atomic_state {
* states.
*/
bool duplicated : 1;
+ bool advance_gamma_mode_active : 1;
struct __drm_planes_state *planes;
struct __drm_crtcs_state *crtcs;
int num_connector;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f789359..f11dc25 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -170,6 +170,11 @@ struct drm_crtc_state {
bool color_mgmt_changed : 1;
/**
+* This is to indicate advance gamma mode support
+*/
+ bool advance_gamma_mode_active : 1;
+
+ /**
* @no_vblank:
*
* Reflects the ability of a CRTC to send VBLANK events. This state
@@ -952,6 +957,8 @@ struct drm_crtc {
*/
bool enabled;
+ bool advance_gamma_mode_active : 1;
+
/**
* @mode:
*
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 6710b61..b5aa24e 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -201,6 +201,14 @@ struct drm_file {
bool writeback_connectors;
/**
+* This is to enable advance gamma modes using
+* gamma_mode property
+*
+* True if client understands advance gamma
+*/
+ bool advance_gamma_mode_active : 1;
+
+ /**
* @is_master:
*
* This client is the creator of @master. Protected by struct
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 236b01a..abef966 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -696,6 +696,8 @@ struct drm_get_cap {
*/
#define DRM_CLIENT_CAP_WRITEBACK_CONNECTORS5
+#define DRM_CLIENT_CAP_ADVANCE_GAMMA_MODES 6
+
/** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
struct drm_set_client_cap {
__u64 capability;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v3 1/7] drm: Add gamma mode property
From: Ville Syrjälä
Add a gamma mode property to enable various kind of
gamma modes supported by platforms like: Interpolated, Split,
Multi Segmented etc. Userspace can get this property and
should be able to get the platform capabilties wrt various
gamma modes possible and the possible ranges.
It can select one of the modes exposed as blob_id as an
enum and set the respective mode.
It can then create the LUT and send it to driver using
already available GAMMA_LUT property as blob.
v2: Addressed Sam Ravnborg's review comments. Implemented
gamma mode with just one property and renamed the current
one to GAMMA_MODE property as recommended by Ville.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_atomic_uapi.c | 5 +++
drivers/gpu/drm/drm_color_mgmt.c | 77 +++
include/drm/drm_color_mgmt.h | 8
include/drm/drm_crtc.h| 7
include/drm/drm_mode_config.h | 6 +++
include/uapi/drm/drm_mode.h | 38 +++
6 files changed, 141 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index ea797d4..d85e0c9 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -459,6 +459,9 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
);
state->color_mgmt_changed |= replaced;
return ret;
+ } else if (property == config->gamma_mode_property) {
+ state->gamma_mode = val;
+ state->color_mgmt_changed |= replaced;
} else if (property == config->prop_out_fence_ptr) {
s32 __user *fence_ptr = u64_to_user_ptr(val);
@@ -495,6 +498,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
*val = (state->mode_blob) ? state->mode_blob->base.id : 0;
else if (property == config->prop_vrr_enabled)
*val = state->vrr_enabled;
+ else if (property == config->gamma_mode_property)
+ *val = state->gamma_mode;
else if (property == config->degamma_lut_property)
*val = (state->degamma_lut) ? state->degamma_lut->base.id : 0;
else if (property == config->ctm_property)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index d5d34d0..4d6792d 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -176,6 +176,83 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
}
EXPORT_SYMBOL(drm_crtc_enable_color_mgmt);
+void drm_crtc_attach_gamma_mode_property(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_mode_config *config = >mode_config;
+
+ if (!config->gamma_mode_property)
+ return;
+
+ drm_object_attach_property(>base,
+ config->gamma_mode_property, 0);
+}
+EXPORT_SYMBOL(drm_crtc_attach_gamma_mode_property);
+
+int drm_color_create_gamma_mode_property(struct drm_device *dev,
+int num_values)
+{
+ struct drm_mode_config *config = >mode_config;
+ struct drm_property *prop;
+
+ prop = drm_property_create(dev,
+ DRM_MODE_PROP_ENUM,
+ "GAMMA_MODE", num_values);
+ if (!prop)
+ return -ENOMEM;
+
+ config->gamma_mode_property = prop;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_color_create_gamma_mode_property);
+
+int drm_color_add_gamma_mode_range(struct drm_device *dev,
+ const char *name,
+ const struct drm_color_lut_range *ranges,
+ size_t length)
+{
+ struct drm_mode_config *config = >mode_config;
+ struct drm_property_blob *blob;
+ struct drm_property *prop;
+ int num_ranges = length / sizeof(ranges[0]);
+ int i, ret, num_types_0;
+
+ if (WARN_ON(length == 0 || length % sizeof(ranges[0]) != 0))
+ return -EINVAL;
+
+ num_types_0 = hweight8(ranges[0].flags & (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_DEGAMMA));
+ if (num_types_0 == 0)
+ return -EINVAL;
+
+ for (i = 1; i < num_ranges; i++) {
+ int num_types = hweight8(ranges[i].flags & (DRM_MODE_LUT_GAMMA |
+
DRM_MODE_LUT_DEGAMMA));
+
+ /* either all ranges have DEGAMMA|GAMMA or none have it */
+ if (num_types_0 != num_types)
+ return -EINVAL;
+ }
+
+ prop = config->gamma_mode_property;
+ if (!prop)
+ return -EINVAL;
+
+ blob = drm_property_create_blob(dev, length, ranges);
+ if (IS_ERR(blob))
+ return PTR_ERR(blob);
+
+ ret =
[v3 4/7] drm/i915/icl: Add support for multi segmented gamma mode
Gen11 introduced a new gamma mode i.e, multi segmented
gamma mode. Added support for the same.
v2: Aligned to just 1 property interface as suggested by
Ville. Fixed Ville's review comments.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_color.c | 166 -
include/drm/drm_crtc.h | 3 +
2 files changed, 165 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index c433215..d4ce1ed 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -58,6 +58,12 @@
#define ILK_CSC_POSTOFF_LIMITED_RANGE (16 * (1 << 12) / 255)
+#define LEGACY_PALETTE_MODE_8BIT BIT(0)
+#define PRECISION_PALETTE_MODE_10BIT BIT(1)
+#define INTERPOLATED_GAMMA_MODE_12BIT BIT(2)
+#define MULTI_SEGMENTED_GAMMA_MODE_12BIT BIT(3)
+#define SPLIT_GAMMA_MODE_12BIT BIT(4)
+
static const u16 ilk_csc_off_zero[3] = {};
static const u16 ilk_csc_coeff_identity[9] = {
@@ -93,6 +99,22 @@
0x0800, 0x0100, 0x0800,
};
+/* ilk+ "12.4" interpolated format (high 10 bits) */
+static u32 ilk_lut_12p4_ldw(const struct drm_color_lut *color)
+{
+ return (color->red >> 6) << 20 |
+ (color->green >> 6) << 10 |
+ (color->blue >> 6);
+}
+
+/* ilk+ "12.4" interpolated format (low 6 bits) */
+static u32 ilk_lut_12p4_udw(const struct drm_color_lut *color)
+{
+ return (color->red & 0x3f) << 24 |
+ (color->green & 0x3f) << 14 |
+ (color->blue & 0x3f);
+}
+
static bool lut_is_legacy(const struct drm_property_blob *lut)
{
return drm_color_lut_size(lut) == LEGACY_LUT_LENGTH;
@@ -781,6 +803,118 @@ static void glk_load_luts(const struct intel_crtc_state
*crtc_state)
}
}
+static void icl_program_coarse_segment_lut(const struct intel_crtc_state
+ *crtc_state,
+ struct drm_color_lut *gamma_lut,
+ u32 offset)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ const struct drm_color_lut *lut = gamma_lut;
+ enum pipe pipe = crtc->pipe;
+ u32 i, lut_size, word;
+
+ WARN_ON(offset & ~PAL_PREC_INDEX_VALUE_MASK);
+
+ I915_WRITE(PREC_PAL_INDEX(pipe),
+ (offset ? PAL_PREC_SPLIT_MODE : 0) |
+ PAL_PREC_AUTO_INCREMENT |
+ offset);
+
+ if (lut && crtc_state->base.gamma_mode_type ==
+ MULTI_SEGMENTED_GAMMA_MODE_12BIT) {
+ lut_size = 9 + 514;
+ for (i = 9; i < lut_size; i++) {
+ /* For Even Index */
+ word = ilk_lut_12p4_udw([i]);
+
+ I915_WRITE(PREC_PAL_DATA(pipe), word);
+
+ /* For ODD index */
+ word = ilk_lut_12p4_ldw([i]);
+
+ I915_WRITE(PREC_PAL_DATA(pipe), word);
+ }
+ }
+
+ /*
+* Program the max register to clamp values > 1.0.
+* ToDo: Extend the ABI to be able to program values
+* from 1.0
+*/
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 0), (1 << 16));
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 1), (1 << 16));
+ I915_WRITE(PREC_PAL_GC_MAX(pipe, 2), (1 << 16));
+
+ /*
+* Program the max register to clamp values > 1.0.
+* ToDo: Extend the ABI to be able to program values
+* from 1.0 to 3.0
+*/
+ I915_WRITE(PREC_PAL_EXT_GC_MAX(pipe, 0), (1 << 16));
+ I915_WRITE(PREC_PAL_EXT_GC_MAX(pipe, 1), (1 << 16));
+ I915_WRITE(PREC_PAL_EXT_GC_MAX(pipe, 2), (1 << 16));
+
+ /*
+* Program the gc max 2 register to clamp values > 1.0.
+* ToDo: Extend the ABI to be able to program values
+* from 3.0 to 7.0
+*/
+ if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
+ I915_WRITE(PREC_PAL_EXT2_GC_MAX(pipe, 0), (1 << 16));
+ I915_WRITE(PREC_PAL_EXT2_GC_MAX(pipe, 1), (1 << 16));
+ I915_WRITE(PREC_PAL_EXT2_GC_MAX(pipe, 2), (1 << 16));
+ }
+}
+
+static void icl_program_fine_segment_lut(const struct intel_crtc_state
+*crtc_state,
+struct drm_color_lut *gamma_lut,
+u32 offset)
+{
+ struct drm_crtc *crtc = crtc_state->base.crtc;
+ struct drm_device *dev = crtc_state->base.crtc->dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ enum pipe pipe = to_intel_crtc(crtc)->pipe;
+ u32 i, word, lut_size = 9;
+
+ WARN_ON(offset & ~PAL_PREC_MULTI_SEGMENT_INDEX_VALUE_MASK);
+
+ I915_WRITE(PREC_PAL_MULTI_SEG_INDEX(pipe),
+
[v3 5/7] drm/i915: Attach gamma mode property
Attach the gamma mode property to allow userspace
set the gamma mode and provide the luts for the
same.
v2: Enabled just 1 property interface for gamma_mode,
as suggested by Ville.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_color.c | 3 +++
drivers/gpu/drm/i915/intel_display.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index d4ce1ed..edf5ff8 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -1884,6 +1884,9 @@ void intel_color_init(struct intel_crtc *crtc)
} else {
if (INTEL_GEN(dev_priv) >= 11) {
dev_priv->display.color_check = icl_color_check;
+
+ drm_crtc_attach_gamma_mode_property(>base);
+
/* don't advertize the >= 1.0 entries */
degamma_lut_size = 0;
gamma_lut_size = ILK_LUT_SIZE_10BIT;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f29a348..3e47935 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15680,6 +15680,9 @@ int intel_modeset_init(struct drm_device *dev)
INTEL_INFO(dev_priv)->num_pipes,
INTEL_INFO(dev_priv)->num_pipes > 1 ? "s" : "");
+ if (INTEL_GEN(dev_priv) >= 11)
+ drm_color_create_gamma_mode_property(_priv->drm, 4);
+
for_each_pipe(dev_priv, pipe) {
ret = intel_crtc_init(dev_priv, pipe);
if (ret) {
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v3 2/7] drm/i915: Define color lut range structure
From: Ville Syrjälä
This defines the color lut ranges for 10bit and multi
segmented gamma range for ICL.
v2: Defined and advertise the gamma modes supported on
various platforms as suggested by Ville.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_color.c | 566 -
1 file changed, 562 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index ca341a9..c433215 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -383,6 +383,20 @@ static u32 ilk_lut_10(const struct drm_color_lut *color)
drm_color_lut_extract(color->blue, 10);
}
+static bool i9xx_has_10bit_lut(struct drm_i915_private *dev_priv)
+{
+/*
+ * Bspec:
+ " "NOTE: The 8-bit (non-10-bit) mode is the only
+ * mode supported by BrookDale-G and Springdale-G."
+ * and
+ * "NOTE: The 8-bit (non-10-bit) mode is the only
+ * mode supported by Alviso and Grantsdale."
+ */
+return !IS_I845G(dev_priv) && !IS_I865G(dev_priv) &&
+!IS_I915G(dev_priv) && !IS_I915GM(dev_priv);
+}
+
/* Loads the legacy palette/gamma unit for the CRTC. */
static void i9xx_load_luts_internal(const struct intel_crtc_state *crtc_state,
const struct drm_property_blob *blob)
@@ -1221,10 +1235,420 @@ static int icl_color_check(struct intel_crtc_state
*crtc_state)
return 0;
}
+enum {
+ I9XX_LUT_SIZE_8BIT = 256,
+ I9XX_LUT_SIZE_10BIT = 129,
+
+ ILK_LUT_SIZE_10BIT = 1024,
+ ILK_LUT_SIZE_12BIT = 513,
+
+ IVB_LUT_SIZE_SPLIT = 512,
+
+ CHV_LUT_SIZE_CGM_DEGAMMA = 65,
+ CHV_LUT_SIZE_CGM_GAMMA = 257,
+};
+
+#define I9XX_GAMMA_8 \
+ { \
+ .flags = DRM_MODE_LUT_GAMMA, \
+ .count = 256, \
+ .input_bpc = 8, .output_bpc = 8, \
+ .start = 0, .end = (1 << 8) - 1, \
+ .min = 0, .max = (1 << 8) - 1, \
+ }
+
+static const struct drm_color_lut_range i9xx_gamma_8[] = {
+ I9XX_GAMMA_8,
+};
+
+static const struct drm_color_lut_range i9xx_gamma_10_slope[] = {
+ {
+ .flags = (DRM_MODE_LUT_GAMMA |
+ DRM_MODE_LUT_INTERPOLATE |
+ DRM_MODE_LUT_NON_DECREASING),
+ .count = 129,
+ .input_bpc = 10, .output_bpc = 10,
+ .start = 0, .end = 1 << 10,
+ .min = 0, .max = (1 << 10) - 1,
+ },
+};
+
+#define I965_GAMMA_10 \
+ { \
+ .flags = (DRM_MODE_LUT_GAMMA | \
+ DRM_MODE_LUT_INTERPOLATE | \
+ DRM_MODE_LUT_NON_DECREASING), \
+ .count = 128, \
+ .input_bpc = 10, .output_bpc = 16, \
+ .start = 0, .end = (1 << 10) - (1 << 10) / 128, \
+ .min = 0, .max = (1 << 16) - 1, \
+ }, \
+ /* PIPEGCMAX */ \
+ { \
+ .flags = (DRM_MODE_LUT_GAMMA | \
+ DRM_MODE_LUT_INTERPOLATE | \
+ DRM_MODE_LUT_REUSE_LAST | \
+ DRM_MODE_LUT_NON_DECREASING), \
+ .count = 1, \
+ .input_bpc = 10, .output_bpc = 16, \
+ .start = (1 << 10) - (1 << 10) / 128, .end = 1 << 10, \
+ .min = 0, .max = 1 << 16, \
+ }
+
+static const struct drm_color_lut_range i965_gamma_10[] = {
+ I965_GAMMA_10,
+};
+
+#define CHV_CGM_DEGAMMA \
+{ \
+.flags = (DRM_MODE_LUT_DEGAMMA | \
+ DRM_MODE_LUT_INTERPOLATE | \
+ DRM_MODE_LUT_NON_DECREASING), \
+.count = 65, \
+.input_bpc = 10, .output_bpc = 14, \
+.start = 0, .end = 1 << 10, \
+.min = 0, .max = (1 << 14) - 1, \
+}
+#define CHV_CGM_GAMMA \
+{ \
+.flags = (DRM_MODE_LUT_GAMMA | \
+ DRM_MODE_LUT_INTERPOLATE | \
+ DRM_MODE_LUT_NON_DECREASING), \
+.count = 257, \
+.input_bpc = 14, .output_bpc = 10, \
+.start = 0, .end = 1 << 14, \
+.min = 0, .max = (1 << 10) - 1, \
+}
+
+static const struct drm_color_lut_range chv_cgm_degamma[] = {
+CHV_CGM_DEGAMMA,
+};
+
+static const struct drm_color_lut_range chv_cgm_gamma[] = {
+CHV_CGM_GAMMA,
+};
+
+static const struct drm_color_lut_range chv_cgm_degamma_i9xx_gamma_8[] = {
+CHV_CGM_DEGAMMA,
+I9XX_GAMMA_8,
+};
+
+static const struct drm_color_lut_range chv_cgm_degamma_i965_gamma_10[] = {
+CHV_CGM_DEGAMMA,
+I965_GAMMA_10,
+};
+
+static const struct drm_color_lut_range chv_cgm_degamma_cgm_degamma[] = {
+CHV_CGM_DEGAMMA,
+CHV_CGM_GAMMA,
+};
+
+static const struct
