[PATCH v2] Staging: fbtft: Switch to the gpio descriptor interface

[Nishad Kamdar]

This switches the fbtft driver to use GPIO descriptors
rather than numerical gpios:

Utilize the GPIO library's intrinsic handling of OF GPIOs
and polarity. If the line is flagged active low, gpiolib
will deal with this.

Remove gpios from platform device structure. Neither assign
statically numbers to gpios in platform device nor allow
gpios to be parsed as module parameters.

Signed-off-by: Nishad Kamdar 
Changes in v2:
 - Merge all patches in a single patch. This is because the
   first patch changes par->gpio from an int to a pointer
   so all the checks have to be updated in the same patch.
   Otherwie it breaks 'git bisect'.
---
 drivers/staging/fbtft/fb_agm1264k-fl.c |  52 ++--
 drivers/staging/fbtft/fb_bd663474.c|   6 +-
 drivers/staging/fbtft/fb_ili9163.c |   6 +-
 drivers/staging/fbtft/fb_ili9320.c |   2 +-
 drivers/staging/fbtft/fb_ili9325.c |   6 +-
 drivers/staging/fbtft/fb_ili9340.c |   2 +-
 drivers/staging/fbtft/fb_pcd8544.c |   4 +-
 drivers/staging/fbtft/fb_ra8875.c  |   4 +-
 drivers/staging/fbtft/fb_s6d1121.c |   6 +-
 drivers/staging/fbtft/fb_sh1106.c  |   2 +-
 drivers/staging/fbtft/fb_ssd1289.c |   6 +-
 drivers/staging/fbtft/fb_ssd1305.c |   4 +-
 drivers/staging/fbtft/fb_ssd1306.c |   4 +-
 drivers/staging/fbtft/fb_ssd1325.c |   6 +-
 drivers/staging/fbtft/fb_ssd1331.c |  10 +-
 drivers/staging/fbtft/fb_ssd1351.c |   2 +-
 drivers/staging/fbtft/fb_tls8204.c |   6 +-
 drivers/staging/fbtft/fb_uc1611.c  |   4 +-
 drivers/staging/fbtft/fb_uc1701.c  |   6 +-
 drivers/staging/fbtft/fb_upd161704.c   |   6 +-
 drivers/staging/fbtft/fb_watterott.c   |   4 +-
 drivers/staging/fbtft/fbtft-bus.c  |   6 +-
 drivers/staging/fbtft/fbtft-core.c | 173 +++--
 drivers/staging/fbtft/fbtft-io.c   |  26 +-
 drivers/staging/fbtft/fbtft.h  |  21 +-
 drivers/staging/fbtft/fbtft_device.c   | 344 +
 drivers/staging/fbtft/flexfb.c |  12 +-
 27 files changed, 143 insertions(+), 587 deletions(-)

diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c 
b/drivers/staging/fbtft/fb_agm1264k-fl.c
index f6f30f5bf15a..8f27bd8da17d 100644
--- a/drivers/staging/fbtft/fb_agm1264k-fl.c
+++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
@@ -8,7 +8,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
@@ -79,14 +79,14 @@ static int init_display(struct fbtft_par *par)
 
 static void reset(struct fbtft_par *par)
 {
-   if (par->gpio.reset == -1)
+   if (!par->gpio.reset)
return;
 
dev_dbg(par->info->device, "%s()\n", __func__);
 
-   gpio_set_value(par->gpio.reset, 0);
+   gpiod_set_value(par->gpio.reset, 0);
udelay(20);
-   gpio_set_value(par->gpio.reset, 1);
+   gpiod_set_value(par->gpio.reset, 1);
mdelay(120);
 }
 
@@ -98,30 +98,30 @@ static int verify_gpios(struct fbtft_par *par)
dev_dbg(par->info->device,
"%s()\n", __func__);
 
-   if (par->EPIN < 0) {
+   if (!par->EPIN) {
dev_err(par->info->device,
"Missing info about 'wr' (aka E) gpio. Aborting.\n");
return -EINVAL;
}
for (i = 0; i < 8; ++i) {
-   if (par->gpio.db[i] < 0) {
+   if (!par->gpio.db[i]) {
dev_err(par->info->device,
"Missing info about 'db[%i]' gpio. Aborting.\n",
i);
return -EINVAL;
}
}
-   if (par->CS0 < 0) {
+   if (!par->CS0) {
dev_err(par->info->device,
"Missing info about 'cs0' gpio. Aborting.\n");
return -EINVAL;
}
-   if (par->CS1 < 0) {
+   if (!par->CS1) {
dev_err(par->info->device,
"Missing info about 'cs1' gpio. Aborting.\n");
return -EINVAL;
}
-   if (par->RW < 0) {
+   if (!par->RW) {
dev_err(par->info->device,
"Missing info about 'rw' gpio. Aborting.\n");
return -EINVAL;
@@ -139,22 +139,22 @@ request_gpios_match(struct fbtft_par *par, const struct 
fbtft_gpio *gpio)
if (strcasecmp(gpio->name, "wr") == 0) {
/* left ks0108 E pin */
par->EPIN = gpio->gpio;
-   return GPIOF_OUT_INIT_LOW;
+   return GPIOD_OUT_LOW;
} else if (strcasecmp(gpio->name, "cs0") == 0) {
/* left ks0108 controller pin */
par->CS0 = gpio->gpio;
-   return GPIOF_OUT_INIT_HIGH;
+   return GPIOD_OUT_HIGH;
} else if (strcasecmp(gpio->name, "cs1") == 0) {
/* right ks0108 controller pin */
par->CS1 = gpio->gpio;
-   return GPIOF_OUT_INIT_HIGH;
+   return GPIOD_OUT_HIGH;
}
 
/* if write (rw = 0) 

Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM

[Will Deacon]

On Mon, Jan 14, 2019 at 07:07:54PM +, Koenig, Christian wrote:
> Am 14.01.19 um 18:32 schrieb Ard Biesheuvel:
> - The reason remapping the CPU side as cacheable does work (which 
> I
> did test) is because the GPU's uncacheable accesses (which I 
> assume
> are made using the NoSnoop PCIe transaction attribute) are 
> actually
> emitted as cacheable in some cases.
>. On my AMD Seattle, with or without SMMU (which is stage 2 
> only), I
> must use cacheable accesses from the CPU side or things are 
> broken.
> This might be a h/w flaw, though.
>. On systems with stage 1+2 SMMUs, the driver uses stage 1
> translations which always override the memory attributes to 
> cacheable
> for DMA coherent devices. This is what is affecting the Cavium
> ThunderX2 (although it appears the attributes emitted by the RC 
> may be
> incorrect as well.)
> 
> The latter issue is a shortcoming in the SMMU driver that we have 
> to
> fix, i.e., it should take care not to modify the incoming 
> attributes
> of DMA coherent PCIe devices for NoSnoop to be able to work.
> 
> So in summary, the mismatch appears to be between the CPU 
> accessing
> the vmap region with non-cacheable attributes and the GPU 
> accessing
> the same memory with cacheable attributes, resulting in a loss of
> coherency and lots of visible corruption.
> 
> Actually it is the other way around. The CPU thinks some data is in 
> the
> cache and the GPU only updates the system memory version because the
> snoop flag is not set.
> 
> 
> That doesn't seem to be what is happening. As far as we can tell from
> our experiments, all inbound transactions are always cacheable, and so
> the only way to make things work is to ensure that the CPU uses the
> same attributes.
> 
> 
> Ok that doesn't make any sense. If inbound transactions are cacheable or not 
> is
> irrelevant when the CPU always uses uncached accesses.
> 
> See on the PCIe side you have the snoop bit in the read/write transactions
> which tells the root hub if the device wants to snoop caches or not.
> 
> When the CPU accesses some memory as cached then devices need to snoop the
> cache for coherent accesses.
> 
> When the CPU accesses some memory as uncached then devices can disable 
> snooping
> to improve performance, but when they don't do this it is mandated by the spec
> that this still works.

Which spec? The Arm architecture (and others including Power afaiu) doesn't
guarantee coherency when memory is accessed using mismatched cacheability
attributes.

Will
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] Staging: fbtft: Switch to the gpio descriptor interface

[Nishad Kamdar]

This switches the fbtft driver to use GPIO descriptors
rather than numerical gpios:

Utilize the GPIO library's intrinsic handling of OF GPIOs
and polarity. If the line is flagged active low, gpiolib
will deal with this.

Remove gpios from platform device structure. Neither assign
statically numbers to gpios in platform device nor allow
gpios to be parsed as module parameters.

Signed-off-by: Nishad Kamdar 
Changes in v2:
 - Merge all patches in a single patch. This is because the
   first patch changes par->gpio from an int to a pointer
   so all the checks have to be updated in the same patch.
   Otherwie it breaks 'git bisect'.
---
 drivers/staging/fbtft/fb_agm1264k-fl.c |  52 ++--
 drivers/staging/fbtft/fb_bd663474.c|   6 +-
 drivers/staging/fbtft/fb_ili9163.c |   6 +-
 drivers/staging/fbtft/fb_ili9320.c |   2 +-
 drivers/staging/fbtft/fb_ili9325.c |   6 +-
 drivers/staging/fbtft/fb_ili9340.c |   2 +-
 drivers/staging/fbtft/fb_pcd8544.c |   4 +-
 drivers/staging/fbtft/fb_ra8875.c  |   4 +-
 drivers/staging/fbtft/fb_s6d1121.c |   6 +-
 drivers/staging/fbtft/fb_sh1106.c  |   2 +-
 drivers/staging/fbtft/fb_ssd1289.c |   6 +-
 drivers/staging/fbtft/fb_ssd1305.c |   4 +-
 drivers/staging/fbtft/fb_ssd1306.c |   4 +-
 drivers/staging/fbtft/fb_ssd1325.c |   6 +-
 drivers/staging/fbtft/fb_ssd1331.c |  10 +-
 drivers/staging/fbtft/fb_ssd1351.c |   2 +-
 drivers/staging/fbtft/fb_tls8204.c |   6 +-
 drivers/staging/fbtft/fb_uc1611.c  |   4 +-
 drivers/staging/fbtft/fb_uc1701.c  |   6 +-
 drivers/staging/fbtft/fb_upd161704.c   |   6 +-
 drivers/staging/fbtft/fb_watterott.c   |   4 +-
 drivers/staging/fbtft/fbtft-bus.c  |   6 +-
 drivers/staging/fbtft/fbtft-core.c | 173 +++--
 drivers/staging/fbtft/fbtft-io.c   |  26 +-
 drivers/staging/fbtft/fbtft.h  |  21 +-
 drivers/staging/fbtft/fbtft_device.c   | 344 +
 drivers/staging/fbtft/flexfb.c |  12 +-
 27 files changed, 143 insertions(+), 587 deletions(-)

diff --git a/drivers/staging/fbtft/fb_agm1264k-fl.c 
b/drivers/staging/fbtft/fb_agm1264k-fl.c
index f6f30f5bf15a..8f27bd8da17d 100644
--- a/drivers/staging/fbtft/fb_agm1264k-fl.c
+++ b/drivers/staging/fbtft/fb_agm1264k-fl.c
@@ -8,7 +8,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
@@ -79,14 +79,14 @@ static int init_display(struct fbtft_par *par)
 
 static void reset(struct fbtft_par *par)
 {
-   if (par->gpio.reset == -1)
+   if (!par->gpio.reset)
return;
 
dev_dbg(par->info->device, "%s()\n", __func__);
 
-   gpio_set_value(par->gpio.reset, 0);
+   gpiod_set_value(par->gpio.reset, 0);
udelay(20);
-   gpio_set_value(par->gpio.reset, 1);
+   gpiod_set_value(par->gpio.reset, 1);
mdelay(120);
 }
 
@@ -98,30 +98,30 @@ static int verify_gpios(struct fbtft_par *par)
dev_dbg(par->info->device,
"%s()\n", __func__);
 
-   if (par->EPIN < 0) {
+   if (!par->EPIN) {
dev_err(par->info->device,
"Missing info about 'wr' (aka E) gpio. Aborting.\n");
return -EINVAL;
}
for (i = 0; i < 8; ++i) {
-   if (par->gpio.db[i] < 0) {
+   if (!par->gpio.db[i]) {
dev_err(par->info->device,
"Missing info about 'db[%i]' gpio. Aborting.\n",
i);
return -EINVAL;
}
}
-   if (par->CS0 < 0) {
+   if (!par->CS0) {
dev_err(par->info->device,
"Missing info about 'cs0' gpio. Aborting.\n");
return -EINVAL;
}
-   if (par->CS1 < 0) {
+   if (!par->CS1) {
dev_err(par->info->device,
"Missing info about 'cs1' gpio. Aborting.\n");
return -EINVAL;
}
-   if (par->RW < 0) {
+   if (!par->RW) {
dev_err(par->info->device,
"Missing info about 'rw' gpio. Aborting.\n");
return -EINVAL;
@@ -139,22 +139,22 @@ request_gpios_match(struct fbtft_par *par, const struct 
fbtft_gpio *gpio)
if (strcasecmp(gpio->name, "wr") == 0) {
/* left ks0108 E pin */
par->EPIN = gpio->gpio;
-   return GPIOF_OUT_INIT_LOW;
+   return GPIOD_OUT_LOW;
} else if (strcasecmp(gpio->name, "cs0") == 0) {
/* left ks0108 controller pin */
par->CS0 = gpio->gpio;
-   return GPIOF_OUT_INIT_HIGH;
+   return GPIOD_OUT_HIGH;
} else if (strcasecmp(gpio->name, "cs1") == 0) {
/* right ks0108 controller pin */
par->CS1 = gpio->gpio;
-   return GPIOF_OUT_INIT_HIGH;
+   return GPIOD_OUT_HIGH;
}
 
/* if write (rw = 0) 

Re: amdgpu/TTM oopses since merging swiotlb_dma_ops into the dma_direct code

[Sibren Vasse]

On Mon, 14 Jan 2019 at 19:10, Christoph Hellwig  wrote:
>
> On Thu, Jan 10, 2019 at 06:52:26PM +0100, Sibren Vasse wrote:
> > On Thu, 10 Jan 2019 at 15:48, Christoph Hellwig  wrote:
> > >
> > > On Thu, Jan 10, 2019 at 03:00:31PM +0100, Christian König wrote:
> > > >>  From the trace it looks like we git the case where swiotlb tries
> > > >> to copy back data from a bounce buffer, but hits a dangling or NULL
> > > >> pointer.  So a couple questions for the submitter:
> > > >>
> > > >>   - does the system have more than 4GB memory and thus use swiotlb?
> > > >> (check /proc/meminfo, and if something SWIOTLB appears in dmesg)
> > > >>   - does the device this happens on have a DMA mask smaller than
> > > >> the available memory, that is should swiotlb be used here to start
> > > >> with?
> > > >
> > > > Rather unlikely. The device is an AMD GPU, so we can address memory up 
> > > > to
> > > > 1TB.
> > >
> > > So we probably somehow got a false positive.
> > >
> > > For now I'like the reported to confirm that the dma_direct_unmap_page+0x92
> > > backtrace really is in the swiotlb code (I can't think of anything else,
> > > but I'd rather be sure).
> > I'm not sure what you want me to confirm. Could you elaborate?
>
> Please open the vmlinux file for which this happend in gdb,
> then send the output from this command
>
> l *(dma_direct_unmap_page+0x92)
>
> to this thread.
My call trace contained:
Jan 10 16:34:51  kernel:  dma_direct_unmap_page+0x7a/0x80

(gdb) list *(dma_direct_unmap_page+0x7a)
0x810fa28a is in dma_direct_unmap_page (kernel/dma/direct.c:291).
286 size_t size, enum dma_data_direction dir,
unsigned long attrs)
287 {
288 phys_addr_t phys = dma_to_phys(dev, addr);
289
290 if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
291 dma_direct_sync_single_for_cpu(dev, addr, size, dir);
292
293 if (unlikely(is_swiotlb_buffer(phys)))
294 swiotlb_tbl_unmap_single(dev, phys, size, dir, attrs);
295 }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 3/3] drm/panel: simple: add support for PDA 91-00156-A0 panel

[Eugen.Hristev]

From: Eugen Hristev 

PDA 91-00156-A0 5.0 is a 5.0" WVGA TFT LCD panel.
This panel with backlight is found in PDA 5" LCD screen (TM5000 series or
AC320005-5).

Signed-off-by: Eugen Hristev 
---
 drivers/gpu/drm/panel/panel-simple.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 9c69e73..61361ba 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2008,6 +2008,30 @@ static const struct panel_desc ortustech_com43h4m85ulc = 
{
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
 };
 
+static const struct drm_display_mode pda_91_00156_a0_mode = {
+   .clock = 33300,
+   .hdisplay = 800,
+   .hsync_start = 800 + 1,
+   .hsync_end = 800 + 1 + 64,
+   .htotal = 800 + 1 + 64 + 64,
+   .vdisplay = 480,
+   .vsync_start = 480 + 1,
+   .vsync_end = 480 + 1 + 23,
+   .vtotal = 480 + 1 + 23 + 22,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc pda_91_00156_a0  = {
+   .modes = _91_00156_a0_mode,
+   .num_modes = 1,
+   .size = {
+   .width = 152,
+   .height = 91,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+};
+
+
 static const struct drm_display_mode qd43003c0_40_mode = {
.clock = 9000,
.hdisplay = 480,
@@ -2686,6 +2710,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "ortustech,com43h4m85ulc",
.data = _com43h4m85ulc,
}, {
+   .compatible = "pda,91-00156-a0",
+   .data = _91_00156_a0,
+   }, {
.compatible = "qiaodian,qd43003c0-40",
.data = _40,
}, {
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] lib/scatterlist: Provide a DMA page iterator

[Jason Gunthorpe]

On Sat, Jan 12, 2019 at 01:03:05PM -0600, Shiraz Saleem wrote:
> On Sat, Jan 12, 2019 at 06:37:58PM +, Jason Gunthorpe wrote:
> > On Sat, Jan 12, 2019 at 12:27:05PM -0600, Shiraz Saleem wrote:
> > > On Fri, Jan 04, 2019 at 10:35:43PM +, Jason Gunthorpe wrote:
> > > > Commit 2db76d7c3c6d ("lib/scatterlist: sg_page_iter: support sg lists 
> > > > w/o
> > > > backing pages") introduced the sg_page_iter_dma_address() function 
> > > > without
> > > > providing a way to use it in the general case. If the sg_dma_len is not
> > > > equal to the dma_length callers cannot safely use the
> > > > for_each_sg_page/sg_page_iter_dma_address combination.
> > > > 
> > > > Resolve this API mistake by providing a DMA specific iterator,
> > > > for_each_sg_dma_page(), that uses the right length so
> > > > sg_page_iter_dma_address() works as expected with all sglists. A new
> > > > iterator type is introduced to provide compile-time safety against 
> > > > wrongly
> > > > mixing accessors and iterators.
> > > [..]
> > > 
> > > >  
> > > > +/*
> > > > + * sg page iterator for DMA addresses
> > > > + *
> > > > + * This is the same as sg_page_iter however you can call
> > > > + * sg_page_iter_dma_address(@dma_iter) to get the page's DMA
> > > > + * address. sg_page_iter_page() cannot be called on this iterator.
> > > > + */
> > > Does it make sense to have a variant of sg_page_iter_page() to get the
> > > page descriptor with this dma_iter? This can be used when walking 
> > > DMA-mapped
> > > SG lists with for_each_sg_dma_page.
> > 
> > I think that would be a complicated cacluation to find the right
> > offset into the page sg list to get the page pointer back. We can't
> > just naively use the existing iterator location.
> > 
> > Probably places that need this are better to run with two iterators,
> > less computationally expensive.
> > 
> > Did you find a need for this? 
> > 
> 
> Well I was trying convert the RDMA drivers to use your new iterator variant
> and saw the need for it in locations where we need virtual address of the 
> pages
> contained in the SGEs.
> 
> diff --git a/drivers/infiniband/hw/bnxt_re/qplib_res.c 
> b/drivers/infiniband/hw/bnxt_re/qplib_res.c
> index 59eeac5..7d26903 100644
> --- a/drivers/infiniband/hw/bnxt_re/qplib_res.c
> +++ b/drivers/infiniband/hw/bnxt_re/qplib_res.c
> @@ -85,7 +85,7 @@ static void __free_pbl(struct pci_dev *pdev, struct 
> bnxt_qplib_pbl *pbl,
>  static int __alloc_pbl(struct pci_dev *pdev, struct bnxt_qplib_pbl *pbl,
>struct scatterlist *sghead, u32 pages, u32 pg_size)
>  {
> -   struct scatterlist *sg;
> +   struct sg_dma_page_iter sg_iter;
> bool is_umem = false;
> int i;
> 
> @@ -116,12 +116,13 @@ static int __alloc_pbl(struct pci_dev *pdev, struct 
> bnxt_qplib_pbl *pbl,
> } else {
> i = 0;
> is_umem = true;
> -   for_each_sg(sghead, sg, pages, i) {
> -   pbl->pg_map_arr[i] = sg_dma_address(sg);
> -   pbl->pg_arr[i] = sg_virt(sg);
> +   for_each_sg_dma_page(sghead, _iter, pages, 0) {
> +   pbl->pg_map_arr[i] = 
> sg_page_iter_dma_address(_iter);
> +   pbl->pg_arr[i] = 
> page_address(sg_page_iter_page(_iter.base)); ???
>   ^

I concur with CH, pg_arr only looks used in the !umem case, so set to
NULL here. Check with Selvin & Devesh ?

> @@ -191,16 +190,16 @@ int rxe_mem_init_user(struct rxe_pd *pd, u64 start,
> goto err1;
> }
> 
> -   mem->page_shift = umem->page_shift;
> -   mem->page_mask  = BIT(umem->page_shift) - 1;
> +   mem->page_shift = PAGE_SHIFT;
> +   mem->page_mask  = PAGE_SIZE - 1;
> 
> num_buf = 0;
> map = mem->map;
> if (length > 0) {
> buf = map[0]->buf;
> 
> -   for_each_sg(umem->sg_head.sgl, sg, umem->nmap, entry) {
> -   vaddr = page_address(sg_page(sg));
> +   for_each_sg_dma_page(umem->sg_head.sgl, _iter, umem->nmap, 
> 0) {
> +   vaddr = 
> page_address(sg_page_iter_page(_iter.base));   ?
>   

rxe doesn't use DMA addreses, so just leave as for_each_sg_page

Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v4 5/8] drm/arcpgu: prepare for drmP.h removal from drm_modeset_helper.h

[Alexey Brodkin]

Hi Sam,

> -Original Message-
> From: Sam Ravnborg [mailto:sam.ravnb...@gmail.com] On Behalf Of Sam Ravnborg
> Sent: Saturday, January 12, 2019 10:33 PM
> To: Alex Deucher ; Alexey Brodkin 
> ; Andrzej
> Hajda ; Benjamin Gaignard 
> ; Chen Feng
> ; Christian Konig ; Daniel 
> Vetter
> ; David Airlie ; David Zhou 
> ; Eric Anholt
> ; Gerd Hoffmann ; Kieran Bingham
> ; Laurent Pinchart 
> ;
> Laurent Pinchart ; Maarten Lankhorst
> ; Maxime Ripard 
> ; Philippe Cornu
> ; Rob Clark ; Rongrong Zou 
> ; Sean
> Paul ; Tomi Valkeinen ; Vincent Abriou
> ; Xinliang Liu ; Xinwei 
> Kong
> ; Yannick Fertre ; 
> linux-ker...@vger.kernel.org;
> dri-devel@lists.freedesktop.org
> Cc: Sam Ravnborg 
> Subject: [PATCH v4 5/8] drm/arcpgu: prepare for drmP.h removal from 
> drm_modeset_helper.h
> 
> The use of drmP.h is discouraged and removal of it from
> drm_modeset_helper.h caused arcgpu to fail to build.
> 
> This patch introduce the necessary fixes to prepare for the
> drmP.h removal from drm_modeset_helper.h.
> List of include files sorted alphabetically.
> 
> Build tested on arm x86 and arm allmodconfig.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Alexey Brodkin 
> Cc: David Airlie 
> Cc: Daniel Vetter 

Thanks for your patch!

Build tested for ARC AXS103 board.

Acked-by: Alexey Brodkin 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/dp: annotate implicit fall throughs

[Mathieu Malaterre]

There is a plan to build the kernel with -Wimplicit-fallthrough and
these places in the code produced warnings (W=1). Fix them up.

This commit remove the following warnings:

  include/linux/compiler.h:77:22: warning: this statement may fall through 
[-Wimplicit-fallthrough=]
  include/asm-generic/bug.h:134:2: note: in expansion of macro 'unlikely'
  drivers/gpu/drm/drm_dp_helper.c:155:3: note: in expansion of macro 'WARN'
  include/linux/compiler.h:77:22: warning: this statement may fall through 
[-Wimplicit-fallthrough=]
  include/asm-generic/bug.h:134:2: note: in expansion of macro 'unlikely'
  drivers/gpu/drm/drm_dp_helper.c:173:3: note: in expansion of macro 'WARN'
  drivers/gpu/drm/drm_dp_helper.c:547:3: warning: this statement may fall 
through [-Wimplicit-fallthrough=]

Signed-off-by: Mathieu Malaterre 
---
 drivers/gpu/drm/drm_dp_helper.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 516e82d0ed50..26835d174939 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -154,6 +154,7 @@ u8 drm_dp_link_rate_to_bw_code(int link_rate)
default:
WARN(1, "unknown DP link rate %d, using %x\n", link_rate,
 DP_LINK_BW_1_62);
+   /* fall through */
case 162000:
return DP_LINK_BW_1_62;
case 27:
@@ -171,6 +172,7 @@ int drm_dp_bw_code_to_link_rate(u8 link_bw)
switch (link_bw) {
default:
WARN(1, "unknown DP link BW code %x, using 162000\n", link_bw);
+   /* fall through */
case DP_LINK_BW_1_62:
return 162000;
case DP_LINK_BW_2_7:
@@ -552,6 +554,7 @@ int drm_dp_downstream_max_bpc(const u8 
dpcd[DP_RECEIVER_CAP_SIZE],
case DP_DS_16BPC:
return 16;
}
+   /* fall through */
default:
return 0;
}
-- 
2.19.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: amdgpu/TTM oopses since merging swiotlb_dma_ops into the dma_direct code

[Sibren Vasse]

On Mon, 14 Jan 2019 at 19:13, Christoph Hellwig  wrote:
>
> Hmm, I wonder if we are not actually using swiotlb in the end,
> can you check if your dmesg contains this line or not?
>
> PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
This line does not appear in my dmesg.

>
> If not I guess we found a bug in swiotlb exit vs is_swiotlb_buffer,
> and you can try this patch:
>
> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index d6361776dc5c..1fb6fd68b9c7 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
> @@ -378,6 +378,8 @@ void __init swiotlb_exit(void)
> memblock_free_late(io_tlb_start,
>PAGE_ALIGN(io_tlb_nslabs << IO_TLB_SHIFT));
> }
> +   io_tlb_start = 0;
> +   io_tlb_end = 0;
> io_tlb_nslabs = 0;
> max_segment = 0;
>  }
With the patch applied to v5.0-rc2 I can no longer reproduce the issue.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM

[Will Deacon]

[+ BenH and MPE]

On Mon, Jan 14, 2019 at 07:21:08PM +, Koenig, Christian wrote:
> Am 14.01.19 um 20:13 schrieb Will Deacon:
> > On Mon, Jan 14, 2019 at 07:07:54PM +, Koenig, Christian wrote:
> >> Am 14.01.19 um 18:32 schrieb Ard Biesheuvel:
> >>  - The reason remapping the CPU side as cacheable does work 
> >> (which I
> >>  did test) is because the GPU's uncacheable accesses (which I 
> >> assume
> >>  are made using the NoSnoop PCIe transaction attribute) are 
> >> actually
> >>  emitted as cacheable in some cases.
> >> . On my AMD Seattle, with or without SMMU (which is stage 
> >> 2 only), I
> >>  must use cacheable accesses from the CPU side or things are 
> >> broken.
> >>  This might be a h/w flaw, though.
> >> . On systems with stage 1+2 SMMUs, the driver uses stage 1
> >>  translations which always override the memory attributes to 
> >> cacheable
> >>  for DMA coherent devices. This is what is affecting the Cavium
> >>  ThunderX2 (although it appears the attributes emitted by the 
> >> RC may be
> >>  incorrect as well.)
> >>
> >>  The latter issue is a shortcoming in the SMMU driver that we 
> >> have to
> >>  fix, i.e., it should take care not to modify the incoming 
> >> attributes
> >>  of DMA coherent PCIe devices for NoSnoop to be able to work.
> >>
> >>  So in summary, the mismatch appears to be between the CPU 
> >> accessing
> >>  the vmap region with non-cacheable attributes and the GPU 
> >> accessing
> >>  the same memory with cacheable attributes, resulting in a 
> >> loss of
> >>  coherency and lots of visible corruption.
> >>
> >>  Actually it is the other way around. The CPU thinks some data is 
> >> in the
> >>  cache and the GPU only updates the system memory version because 
> >> the
> >>  snoop flag is not set.
> >>
> >>
> >>  That doesn't seem to be what is happening. As far as we can tell from
> >>  our experiments, all inbound transactions are always cacheable, and so
> >>  the only way to make things work is to ensure that the CPU uses the
> >>  same attributes.
> >>
> >>
> >> Ok that doesn't make any sense. If inbound transactions are cacheable or 
> >> not is
> >> irrelevant when the CPU always uses uncached accesses.
> >>
> >> See on the PCIe side you have the snoop bit in the read/write transactions
> >> which tells the root hub if the device wants to snoop caches or not.
> >>
> >> When the CPU accesses some memory as cached then devices need to snoop the
> >> cache for coherent accesses.
> >>
> >> When the CPU accesses some memory as uncached then devices can disable 
> >> snooping
> >> to improve performance, but when they don't do this it is mandated by the 
> >> spec
> >> that this still works.
> > Which spec?
> 
> The PCIe spec. The snoop bit (or rather the NoSnoop) in the transaction 
> is perfectly optional IIRC.

Thanks for the clarification. I suspect the devil is in the details, so I'll
try to dig up the spec.

> > The Arm architecture (and others including Power afaiu) doesn't
> > guarantee coherency when memory is accessed using mismatched cacheability
> > attributes.
> 
> Well what exactly goes wrong on ARM?

Coherency (and any ordering guarantees) can be lost, so the device may see a
stale copy of the memory it is accessing. The architecture requires cache
maintenance to restore coherency between the mismatched aliases.

> As far as I know Power doesn't really supports un-cached memory at all, 
> except for a very very old and odd configuration with AGP.

Hopefully Michael/Ben can elaborate here, but I was under the (possibly
mistaken) impression that mismatched attributes could cause a machine-check
on Power.

> I mean in theory I agree that devices should use matching cacheability 
> attributes, but in practice I know of quite a bunch of devices/engines 
> which fails to do this correctly.

Given that the experiences of Ard and I so far has been that the system
ends up making everything cacheable after the RC, perhaps that's an attempt
by system designers to correct for these devices. Unfortunately, it doesn't
help if the CPU carefully goes ahead and establishes a non-cacheable mapping
for itself!

Will
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] qcom-scm: Include header

[Amit Kucheria]

On Sun, Dec 30, 2018 at 1:21 AM Andy Gross  wrote:
>
> On Sat, Dec 29, 2018 at 10:19:32AM -0200, Fabio Estevam wrote:
> > Hi Bjorn,
> >
> > On Fri, Dec 28, 2018 at 10:27 PM Bjorn Andersson
> >  wrote:
> >
> > > Sorry about that, I forgot that the header file is not covered by the
> > > MAINTAINERS file.
> > >
> > > Your second patch looks good, but I'm hoping we can merge the upcoming
> > > v3 of Amit's patch right after the merge window. It fixes this and a lot
> > > of other pieces where we would like to include linux-arm-msm@:
> > >
> > > https://lore.kernel.org/lkml/d153a86748f99526e7790bfc4ef8781a2016fd51.1545126964.git.amit.kuche...@linaro.org/
> >
> > Amit's patch adds the following entry:
> >
> > +F: include/linux/*/qcom*
> >
> > but it does not catch include/linux/qcom_scm.h
> >
> > It also needs
> >
> > +F: include/linux/qcom*
> >
> > in order to catch include/linux/qcom-geni-se.h  and include/linux/qcom_scm.h
> >
> > I can add that entry after Amit's patch gets applied.
>
> Or I can add it to Amit's.  I'll ping him to make sure that's ok.
>

I'd forgotten about this patch! Just sent out v3 which is still
missing "F: include/linux/qcom*".

Let me know if you want me to send out v4 with this added.

Regards,
Amit
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] video: offb: annotate implicit fall throughs

[Mathieu Malaterre]

There is a plan to build the kernel with -Wimplicit-fallthrough and
these places in the code produced warnings (W=1). Fix them up.

This commit remove the following warnings:

  drivers/video/fbdev/offb.c:211:5: warning: this statement may fall through 
[-Wimplicit-fallthrough=]
  drivers/video/fbdev/offb.c:142:3: warning: this statement may fall through 
[-Wimplicit-fallthrough=]

Signed-off-by: Mathieu Malaterre 
---
 drivers/video/fbdev/offb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/video/fbdev/offb.c b/drivers/video/fbdev/offb.c
index 31f769d67195..e0f0c5351306 100644
--- a/drivers/video/fbdev/offb.c
+++ b/drivers/video/fbdev/offb.c
@@ -141,6 +141,7 @@ static int offb_setcolreg(u_int regno, u_int red, u_int 
green, u_int blue,
/* Clear PALETTE_ACCESS_CNTL in DAC_CNTL */
out_le32(par->cmap_adr + 0x58,
 in_le32(par->cmap_adr + 0x58) & ~0x20);
+   /* fall through */
case cmap_r128:
/* Set palette index & data */
out_8(par->cmap_adr + 0xb0, regno);
@@ -210,6 +211,7 @@ static int offb_blank(int blank, struct fb_info *info)
/* Clear PALETTE_ACCESS_CNTL in DAC_CNTL */
out_le32(par->cmap_adr + 0x58,
 in_le32(par->cmap_adr + 0x58) & ~0x20);
+   /* fall through */
case cmap_r128:
/* Set palette index & data */
out_8(par->cmap_adr + 0xb0, i);
-- 
2.19.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/amdgpu: Replace kzalloc with kcalloc

[Gustavo A. R. Silva]

Replace kzalloc() function with its 2-factor argument form, kcalloc().

This patch replaces cases of:

kzalloc(a * b, gfp)

with:
kcalloc(a, b, gfp)

Also, improve the coding style and the use of sizeof during
allocation by changing sizeof(struct dc_surface_update) and
sizeof(struct dc_plane_state) to sizeof(*updates) and
sizeof(*surfaces), correspondingly.

This code was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +--
 1 file changed, 5 insertions(+), 2 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 a3e65e457348..4c201de38329 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5782,11 +5782,14 @@ dm_determine_update_type_for_commit(struct dc *dc,
struct dm_crtc_state *new_dm_crtc_state, *old_dm_crtc_state;
struct dc_stream_status *status = NULL;
 
-   struct dc_surface_update *updates = kzalloc(MAX_SURFACES * 
sizeof(struct dc_surface_update), GFP_KERNEL);
-   struct dc_plane_state *surface = kzalloc(MAX_SURFACES * sizeof(struct 
dc_plane_state), GFP_KERNEL);
+   struct dc_surface_update *updates;
+   struct dc_plane_state *surface;
struct dc_stream_update stream_update;
enum surface_update_type update_type = UPDATE_TYPE_FAST;
 
+   updates = kcalloc(MAX_SURFACES, sizeof(*updates), GFP_KERNEL);
+   surface = kcalloc(MAX_SURFACES, sizeof(*surface), GFP_KERNEL);
+
if (!updates || !surface) {
DRM_ERROR("Plane or surface update failed to allocate");
/* Set type to FULL to avoid crashing in DC*/
-- 
2.20.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v9 06/22] powerpc: Replace nvram_* extern declarations with standard header

[Finn Thain]

Remove the nvram_read_byte() and nvram_write_byte() declarations in
powerpc/include/asm/nvram.h and use the cross-platform static functions
in linux/nvram.h instead.

Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
Changed since v8:
 - Added nvram_read_byte() and nvram_write_byte() functions to avoid a
potential build failure during 'git bisect'.
 - Brought forward some powerpc cleanup to avoid naming collisions with
nvram.h functions.
 - Replaced the ppc_md.nvram_* method wrappers with the ones in nvram.h.
---
 arch/powerpc/include/asm/nvram.h   |  6 --
 arch/powerpc/kernel/setup_32.c | 25 +-
 drivers/char/generic_nvram.c   |  1 +
 drivers/video/fbdev/matrox/matroxfb_base.c |  2 +-
 include/linux/nvram.h  |  3 +++
 5 files changed, 6 insertions(+), 31 deletions(-)

diff --git a/arch/powerpc/include/asm/nvram.h b/arch/powerpc/include/asm/nvram.h
index 09a518bb7c03..56a388da9c4f 100644
--- a/arch/powerpc/include/asm/nvram.h
+++ b/arch/powerpc/include/asm/nvram.h
@@ -98,10 +98,4 @@ extern int nvram_write_os_partition(struct 
nvram_os_partition *part,
unsigned int err_type,
unsigned int error_log_cnt);
 
-/* Determine NVRAM size */
-extern ssize_t nvram_get_size(void);
-
-/* Normal access to NVRAM */
-extern unsigned char nvram_read_byte(int i);
-extern void nvram_write_byte(unsigned char c, int i);
 #endif /* _ASM_POWERPC_NVRAM_H */
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 947f904688b0..f5107796e2d7 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -149,30 +150,6 @@ __setup("l3cr=", ppc_setup_l3cr);
 
 #ifdef CONFIG_GENERIC_NVRAM
 
-/* Generic nvram hooks used by drivers/char/gen_nvram.c */
-unsigned char nvram_read_byte(int addr)
-{
-   if (ppc_md.nvram_read_val)
-   return ppc_md.nvram_read_val(addr);
-   return 0xff;
-}
-EXPORT_SYMBOL(nvram_read_byte);
-
-void nvram_write_byte(unsigned char val, int addr)
-{
-   if (ppc_md.nvram_write_val)
-   ppc_md.nvram_write_val(addr, val);
-}
-EXPORT_SYMBOL(nvram_write_byte);
-
-ssize_t nvram_get_size(void)
-{
-   if (ppc_md.nvram_size)
-   return ppc_md.nvram_size();
-   return -1;
-}
-EXPORT_SYMBOL(nvram_get_size);
-
 void nvram_sync(void)
 {
if (ppc_md.nvram_sync)
diff --git a/drivers/char/generic_nvram.c b/drivers/char/generic_nvram.c
index ff5394f47587..0c22b9503e84 100644
--- a/drivers/char/generic_nvram.c
+++ b/drivers/char/generic_nvram.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/video/fbdev/matrox/matroxfb_base.c 
b/drivers/video/fbdev/matrox/matroxfb_base.c
index 838869c6490c..0a4e5bad33f4 100644
--- a/drivers/video/fbdev/matrox/matroxfb_base.c
+++ b/drivers/video/fbdev/matrox/matroxfb_base.c
@@ -111,12 +111,12 @@
 #include "matroxfb_g450.h"
 #include 
 #include 
+#include 
 #include 
 #include 
 
 #ifdef CONFIG_PPC_PMAC
 #include 
-unsigned char nvram_read_byte(int);
 static int default_vmode = VMODE_NVRAM;
 static int default_cmode = CMODE_NVRAM;
 #endif
diff --git a/include/linux/nvram.h b/include/linux/nvram.h
index a1e01dc89759..79431dab87a1 100644
--- a/include/linux/nvram.h
+++ b/include/linux/nvram.h
@@ -15,8 +15,11 @@ extern const struct nvram_ops arch_nvram_ops;
 
 static inline ssize_t nvram_get_size(void)
 {
+#ifdef CONFIG_PPC
+#else
if (arch_nvram_ops.get_size)
return arch_nvram_ops.get_size();
+#endif
return -ENODEV;
 }
 
-- 
2.19.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] video: offb: annotate implicit fall throughs

[Gustavo A. R. Silva]

On 1/14/19 2:40 PM, Mathieu Malaterre wrote:

There is a plan to build the kernel with -Wimplicit-fallthrough and
these places in the code produced warnings (W=1). Fix them up.

This commit remove the following warnings:

   drivers/video/fbdev/offb.c:211:5: warning: this statement may fall through 
[-Wimplicit-fallthrough=]
   drivers/video/fbdev/offb.c:142:3: warning: this statement may fall through 
[-Wimplicit-fallthrough=]

Signed-off-by: Mathieu Malaterre 


Acked-by: Gustavo A. R. Silva 

Thanks
--
Gustavo


---
  drivers/video/fbdev/offb.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/video/fbdev/offb.c b/drivers/video/fbdev/offb.c
index 31f769d67195..e0f0c5351306 100644
--- a/drivers/video/fbdev/offb.c
+++ b/drivers/video/fbdev/offb.c
@@ -141,6 +141,7 @@ static int offb_setcolreg(u_int regno, u_int red, u_int 
green, u_int blue,
/* Clear PALETTE_ACCESS_CNTL in DAC_CNTL */
out_le32(par->cmap_adr + 0x58,
 in_le32(par->cmap_adr + 0x58) & ~0x20);
+   /* fall through */
case cmap_r128:
/* Set palette index & data */
out_8(par->cmap_adr + 0xb0, regno);
@@ -210,6 +211,7 @@ static int offb_blank(int blank, struct fb_info *info)
/* Clear PALETTE_ACCESS_CNTL in DAC_CNTL */
out_le32(par->cmap_adr + 0x58,
 in_le32(par->cmap_adr + 0x58) & ~0x20);
+   /* fall through */
case cmap_r128:
/* Set palette index & data */
out_8(par->cmap_adr + 0xb0, i);


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm/panel: simple: Add Evervision VGG804821 pannel support

[Marco Felsch]

Hi Sam,

On 19-01-04 17:40, Sam Ravnborg wrote:
> Hi Marco.
> 
> In $subject pannel => panel

Thanks for covering that, Thierry can you fix this inline?

Regards,
Marco

> 
> Other than that, bonus points for specifying
> all of .flags, .bus_format and .bus_flags
> 
>   Sam
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] qcom-scm: Include header

[Chris Healy]

There we go, I was definitely confused...  Tnx

On Mon, Jan 14, 2019 at 12:02 PM Fabio Estevam  wrote:
>
> Hi Chris,
>
> On Mon, Jan 14, 2019 at 5:54 PM Chris Healy  wrote:
> >
> > Perhaps I am confused but it appears that this patch has already
> > landed upstream and got included in 5.0-rc2:
>
> The patch that Amit is referring is the following entry in MAINTAINERS file:
>
> +F: include/linux/qcom*
>
> so that the proper lists can be put on Cc on future changes of this file.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH] staging: android: ion: add buffer flag update ioctl

[Zengtao (B)]

>-Original Message-
>From: Laura Abbott [mailto:labb...@redhat.com]
>Sent: Friday, January 04, 2019 9:53 AM
>To: Zengtao (B) ; sumit.sem...@linaro.org
>Cc: Greg Kroah-Hartman ; Arve Hjønnevåg
>; Todd Kjos ; Martijn Coenen
>; Joel Fernandes ;
>de...@driverdev.osuosl.org; dri-devel@lists.freedesktop.org;
>linaro-mm-...@lists.linaro.org; linux-ker...@vger.kernel.org
>Subject: Re: [PATCH] staging: android: ion: add buffer flag update ioctl
>
>On 1/3/19 5:42 PM, Zengtao (B) wrote:
>>> -Original Message-
>>> From: Laura Abbott [mailto:labb...@redhat.com]
>>> Sent: Thursday, January 03, 2019 6:31 AM
>>> To: Zengtao (B) ;
>sumit.sem...@linaro.org
>>> Cc: Greg Kroah-Hartman ; Arve
>Hjønnevåg
>>> ; Todd Kjos ; Martijn
>Coenen
>>> ; Joel Fernandes ;
>>> de...@driverdev.osuosl.org; dri-devel@lists.freedesktop.org;
>>> linaro-mm-...@lists.linaro.org; linux-ker...@vger.kernel.org
>>> Subject: Re: [PATCH] staging: android: ion: add buffer flag update
>>> ioctl
>>>
>>> On 12/23/18 6:47 PM, Zengtao (B) wrote:
 Hi laura:

> -Original Message-
> From: Laura Abbott [mailto:labb...@redhat.com]
> Sent: Friday, December 21, 2018 4:50 AM
> To: Zengtao (B) ;
>>> sumit.sem...@linaro.org
> Cc: Greg Kroah-Hartman ; Arve
>>> Hjønnevåg
> ; Todd Kjos ; Martijn
>>> Coenen
> ; Joel Fernandes ;
> de...@driverdev.osuosl.org; dri-devel@lists.freedesktop.org;
> linaro-mm-...@lists.linaro.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH] staging: android: ion: add buffer flag update
> ioctl
>
> On 12/19/18 5:39 PM, Zengtao (B) wrote:
>> Hi laura:
>>
>>> -Original Message-
>>> From: Laura Abbott [mailto:labb...@redhat.com]
>>> Sent: Thursday, December 20, 2018 2:10 AM
>>> To: Zengtao (B) ;
> sumit.sem...@linaro.org
>>> Cc: Greg Kroah-Hartman ; Arve
> Hjønnevåg
>>> ; Todd Kjos ; Martijn
> Coenen
>>> ; Joel Fernandes ;
>>> de...@driverdev.osuosl.org; dri-devel@lists.freedesktop.org;
>>> linaro-mm-...@lists.linaro.org; linux-ker...@vger.kernel.org
>>> Subject: Re: [PATCH] staging: android: ion: add buffer flag
>>> update ioctl
>>>
>>> On 12/19/18 9:19 AM, Zeng Tao wrote:
 In some usecases, the buffer cached attribute is not determined
 at allocation time, it's determined just before the real cpu
>mapping.
 And from the memory view of point, a buffer should not have
>the
>>> cached
 attribute util is really mapped by the cpu. So in this patch, we
 introduced the new ioctl command to target the requirement.

>>>
>>> This is racy and error prone. Can you explain more what problem
>>> you
>>> are trying to solve?
>>
>> My use case is like this:
>> 1.  There are two process A and B, A takes case of ion buffer
>> allocation,
> and
>> pass the buffer fd to B, then B maps and uses it.
>> 2.  Process B need to map the buffer with different cached
>> attribute for different use case, for example, if the buffer is
>> used for pure software algorithm, then we need to map it as
>> cached, otherwise non-cached, and B needs to deal with both
>cases.
>> And unfortunately the mmap syscall takes no cached flags and we
>> can't decide the cache attribute when we are doing the mmap, so I
>> introduce new the ioctl even though I think the solution is not as
>>> good.
>>
>>
>
> Thanks for the explanation, this was about the use case I expected.
> I'm pretty sure I had this exact problem once upon a time and we
> didn't come up with a solution. I'd still like to get rid of
> uncached buffers in general and just use cached buffers (see
> http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2
> 01
> 8-N
> ovember/128842.html)
> What's your usecase for uncached buffers?

 Some buffers are only used by HW, in this case, we tend to use
>>> uncached buffers.
 But sometimes the SW need to read few buffer contents for debug
 purpose and no synchronization is needed.

>>>
>>> If this is primarily for debug, that's not really a compelling reason
>>> to support uncached buffers. It's incredibly difficult to do uncached
>>> buffers correctly I'd rather spend effort on making the cached use
>>> cases work better.
>>>
>> No, not only for debug, I meant if the buffers are uncached, the SW
>> will only mmap them for debug or even don't need to mmap them.
>> So for the two kinds of buffers:
>> 1.  uncached: only the HW need to access it, the SW don't need to
>mmap it or just for debug.
>> 2.  cached: both the HW and the SW need to access it.
>> The ION is designed as a generalized memory manager, I think we
>should
>> cover as many requirements as we can in the ION design, so I 'd rather
>that we keep the uncached support.
>> And I don’t quite understand the difficulty you mentioned to support
>> the uncached buffers, 

[PATCH v9 19/22] powerpc, fbdev: Use NV_CMODE and NV_VMODE only when CONFIG_PPC32 && CONFIG_PPC_PMAC && CONFIG_NVRAM

[Finn Thain]

This patch addresses inconsistencies in Mac framebuffer drivers and their
use of Kconfig symbols relating to NVRAM, so PPC64 can use CONFIG_NVRAM.

The defined(CONFIG_NVRAM) condition is replaced with the weaker
IS_REACHABLE(CONFIG_NVRAM) condition, like atari_scsi.

Macintosh framebuffer drivers use default settings for color mode and
video mode that are found in NVRAM. On PCI Macs, MacOS stores display
settings in the Name Registry (NR) partition in NVRAM*. On NuBus Macs,
there is no NR partition and MacOS stores display mode settings in PRAM**.

Early-model Macs are the ones most likely to benefit from these settings,
since they are more likely to have a fixed-frequency monitor connected to
the built-in framebuffer device. Moreover, a single NV_CMODE value and
a single NV_VMODE value provide for only one display.

The NV_CMODE and NV_VMODE constants are apparently offsets into the NR
partition for Old World machines. This also suggests that these defaults
are not useful on later models. The NR partition seems to be optional on
New World machines. CONFIG_NVRAM cannot be enabled on PPC64 at present.

It is safe to say that NVRAM support in PowerMac fbdev drivers is only
applicable to CONFIG_PPC32 so make this condition explicit. This means
matroxfb driver won't crash on PPC64 when CONFIG_NVRAM becomes available
there.

For imsttfb, add the missing CONFIG_NVRAM test to prevent a build failure,
since PPC64 does not implement nvram_read_byte(). Also add a missing
machine_is(powermac) check. Change the inconsistent dependency on
CONFIG_PPC and the matching #ifdef tests to CONFIG_PPC_PMAC.

For valkyriefb, to improve clarity and consistency with the other PowerMac
fbdev drivers, test for CONFIG_PPC_PMAC instead of !CONFIG_MAC. Remove a
bogus comment regarding PRAM.

* See GetPreferredConfiguration and SavePreferredConfiguration in
"Designing PCI Cards and Drivers for Power Macintosh Computers".

** See SetDefaultMode and GetDefaultMode in "Designing Cards and Drivers
for the Macintosh Family".

Signed-off-by: Finn Thain 
---
Changed since v8:
 - Replaced defined(CONFIG_NVRAM) with IS_REACHABLE(CONFIG_NVRAM) as
suggested by James Bottomley.
 - Changed #ifdef to if as suggested by Christophe Leroy.
 - Expanded the patch to include controlfb.c and platinumfb.c due to the
conversion from '#if defined(CONFIG_NVRAM)' to
'if (IS_REACHABLE(CONFIG_NVRAM))'.
---
 drivers/video/fbdev/Kconfig|  2 +-
 drivers/video/fbdev/controlfb.c| 42 --
 drivers/video/fbdev/imsttfb.c  | 23 ++--
 drivers/video/fbdev/matrox/matroxfb_base.c |  5 +--
 drivers/video/fbdev/platinumfb.c   | 21 +--
 drivers/video/fbdev/valkyriefb.c   | 30 ++--
 6 files changed, 48 insertions(+), 75 deletions(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index ae7712c9687a..58a9590c9db6 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -536,7 +536,7 @@ config FB_IMSTT
bool "IMS Twin Turbo display support"
depends on (FB = y) && PCI
select FB_CFB_IMAGEBLIT
-   select FB_MACMODES if PPC
+   select FB_MACMODES if PPC_PMAC
help
  The IMS Twin Turbo is a PCI-based frame buffer card bundled with
  many Macintosh and compatible computers.
diff --git a/drivers/video/fbdev/controlfb.c b/drivers/video/fbdev/controlfb.c
index 9cb0ef7ac29e..7af8db28bb80 100644
--- a/drivers/video/fbdev/controlfb.c
+++ b/drivers/video/fbdev/controlfb.c
@@ -411,35 +411,23 @@ static int __init init_control(struct fb_info_control *p)
full = p->total_vram == 0x40;
 
/* Try to pick a video mode out of NVRAM if we have one. */
-#ifdef CONFIG_NVRAM
-   if (default_cmode == CMODE_NVRAM) {
+   cmode = default_cmode;
+   if (IS_REACHABLE(CONFIG_NVRAM) && cmode == CMODE_NVRAM)
cmode = nvram_read_byte(NV_CMODE);
-   if(cmode < CMODE_8 || cmode > CMODE_32)
-   cmode = CMODE_8;
-   } else
-#endif
-   cmode=default_cmode;
-#ifdef CONFIG_NVRAM
-   if (default_vmode == VMODE_NVRAM) {
+   if (cmode < CMODE_8 || cmode > CMODE_32)
+   cmode = CMODE_8;
+
+   vmode = default_vmode;
+   if (IS_REACHABLE(CONFIG_NVRAM) && vmode == VMODE_NVRAM)
vmode = nvram_read_byte(NV_VMODE);
-   if (vmode < 1 || vmode > VMODE_MAX ||
-   control_mac_modes[vmode - 1].m[full] < cmode) {
-   sense = read_control_sense(p);
-   printk("Monitor sense value = 0x%x, ", sense);
-   vmode = mac_map_monitor_sense(sense);
-   if (control_mac_modes[vmode - 1].m[full] < cmode)
-   vmode = VMODE_640_480_60;
-   }
-   } else
-#endif
-   {
-   vmode=default_vmode;
-   if (control_mac_modes[vmode - 1].m[full] < cmode) {

Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM

[Ard Biesheuvel]

On Mon, 14 Jan 2019 at 12:38, Koenig, Christian
 wrote:
>
> Am 14.01.19 um 11:53 schrieb Ard Biesheuvel:
> > On Thu, 10 Jan 2019 at 10:34, Michel Dänzer  wrote:
> >> On 2019-01-10 8:28 a.m., Ard Biesheuvel wrote:
> >>> ARM systems do not permit the use of anything other than cached
> >>> mappings for system memory, since that memory may be mapped in the
> >>> linear region as well, and the architecture does not permit aliases
> >>> with mismatched attributes.
> >>>
> >>> So short-circuit the evaluation in ttm_io_prot() if the flags include
> >>> TTM_PL_SYSTEM when running on ARM or arm64, and just return cached
> >>> attributes immediately.
> >>>
> >>> This fixes the radeon and amdgpu [TBC] drivers when running on arm64.
> >>> Without this change, amdgpu does not start at all, and radeon only
> >>> produces corrupt display output.
> >>>
> >>> Cc: Christian Koenig 
> >>> Cc: Huang Rui 
> >>> Cc: Junwei Zhang 
> >>> Cc: David Airlie 
> >>> Reported-by: Carsten Haitzler 
> >>> Signed-off-by: Ard Biesheuvel 
> >>> ---
> >>>   drivers/gpu/drm/ttm/ttm_bo_util.c | 5 +
> >>>   1 file changed, 5 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
> >>> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> >>> index 046a6dda690a..0c1eef5f7ae3 100644
> >>> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> >>> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> >>> @@ -530,6 +530,11 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, 
> >>> pgprot_t tmp)
> >>>if (caching_flags & TTM_PL_FLAG_CACHED)
> >>>return tmp;
> >>>
> >>> +#if defined(__arm__) || defined(__aarch64__)
> >>> + /* ARM only permits cached mappings of system memory */
> >>> + if (caching_flags & TTM_PL_SYSTEM)
> >>> + return tmp;
> >>> +#endif
> >>>   #if defined(__i386__) || defined(__x86_64__)
> >>>if (caching_flags & TTM_PL_FLAG_WC)
> >>>tmp = pgprot_writecombine(tmp);
> >>>
> >> Apart from Christian's concerns, I think this is the wrong place for
> >> this, because other TTM / driver code will still consider the memory
> >> uncacheable. E.g. the amdgpu driver will program the GPU to treat the
> >> memory as uncacheable, so it won't participate in cache coherency
> >> protocol for it, which is unlikely to work as expected in general if the
> >> CPU treats the memory as cacheable.
> >>
> > Will and I have spent some time digging into this, so allow me to
> > share some preliminary findings while we carry on and try to fix this
> > properly.
> >
> > - The patch above is flawed, i.e., it doesn't do what it intends to
> > since it uses TTM_PL_SYSTEM instead of TTM_PL_FLAG_SYSTEM. Apologies
> > for that.
> > - The existence of a linear region mapping with mismatched attributes
> > is likely not the culprit here. (We do something similar with
> > non-cache coherent DMA in other places).
>
> This is still rather problematic.
>
> The issue is that we often don't create a vmap for a page, but rather
> access the page directly using the linear mapping.
>
> So we would use the wrong access type here.
>

Yes. But how are these accesses done? Are they wrapped in a kmap()?

> > - The reason remapping the CPU side as cacheable does work (which I
> > did test) is because the GPU's uncacheable accesses (which I assume
> > are made using the NoSnoop PCIe transaction attribute) are actually
> > emitted as cacheable in some cases.
> >. On my AMD Seattle, with or without SMMU (which is stage 2 only), I
> > must use cacheable accesses from the CPU side or things are broken.
> > This might be a h/w flaw, though.
> >. On systems with stage 1+2 SMMUs, the driver uses stage 1
> > translations which always override the memory attributes to cacheable
> > for DMA coherent devices. This is what is affecting the Cavium
> > ThunderX2 (although it appears the attributes emitted by the RC may be
> > incorrect as well.)
> >
> > The latter issue is a shortcoming in the SMMU driver that we have to
> > fix, i.e., it should take care not to modify the incoming attributes
> > of DMA coherent PCIe devices for NoSnoop to be able to work.
> >
> > So in summary, the mismatch appears to be between the CPU accessing
> > the vmap region with non-cacheable attributes and the GPU accessing
> > the same memory with cacheable attributes, resulting in a loss of
> > coherency and lots of visible corruption.
>
> Actually it is the other way around. The CPU thinks some data is in the
> cache and the GPU only updates the system memory version because the
> snoop flag is not set.
>

That doesn't seem to be what is happening. As far as we can tell from
our experiments, all inbound transactions are always cacheable, and so
the only way to make things work is to ensure that the CPU uses the
same attributes.

> > To be able to debug this further, could you elaborate a bit on
> > - How does the hardware emit those uncached/wc inbound accesses? Do
> > they rely on NoSnoop?
>
> The GPU has a separate page walker in the MC and the page tables there

Re: drm/vc4: NULL ptr dereference during HDMI audio registration with next-20190111

[Rohit Kumar]

On 1/13/2019 4:38 AM, Stefan Wahren wrote:

Stefan Wahren  hat am 12. Januar 2019 um 12:24 
geschrieben:


Hi,

kernelci.org [1] noticed a NULL pointer dereference during HDMI audio registration with 
linux-next-20190111 on Raspberry Pi using bcm2835_defconfig. I was able to reproduce it, 
but couldn't find anything suspicious in the commit ("Merge remote-tracking branch 
'drm-misc-fixes/for-linux-next-fixes'") bisected by kernelci.org.

Best regards
Stefan

[1] - https://kernelci.org/boot/id/5c383ceb59b514d9ca6edd2f/

[1.956798] Unable to handle kernel NULL pointer dereference at virtual 
address 

okay, i think i've found the responsible commit 8780cf1142a5 ("ASoC: soc-core: defer 
card probe until all component is added to list").


The fix is already posted via 
https://lore.kernel.org/patchwork/patch/1031226/.


Mark, Can you pick this up. We will still have to consider intel platform

where there is no soc_component associated with platform_name.



The following patch fixes the issue for me:

diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 0934b36..dc6b6d1 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -1134,7 +1134,8 @@ static int soc_init_dai_link(struct snd_soc_card *card,
 * Defer card registartion if platform dai component is not added to
 * component list.
 */
-   if (!soc_find_component(link->platform->of_node, link->platform->name))
+   if ((link->platform->of_node || link->platform->name) &&
+   !soc_find_component(link->platform->of_node, link->platform->name))
return -EPROBE_DEFER;
  
  	/*

@@ -1153,7 +1154,8 @@ static int soc_init_dai_link(struct snd_soc_card *card,
 * Defer card registartion if cpu dai component is not added to
 * component list.
 */
-   if (!soc_find_component(link->cpu_of_node, link->cpu_name))
+   if ((link->cpu_of_node || link->cpu_name) &&
+   !soc_find_component(link->cpu_of_node, link->cpu_name))
return -EPROBE_DEFER;
  
  	/*


Thanks,
Rohit
--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code Aurora Forum, hosted by the Linux Foundation.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap

[Liam Mark]

On Fri, 11 Jan 2019, Andrew F. Davis wrote:

> Buffers may not be mapped from the CPU so skip cache maintenance here.
> Accesses from the CPU to a cached heap should be bracketed with
> {begin,end}_cpu_access calls so maintenance should not be needed anyway.
> 
> Signed-off-by: Andrew F. Davis 
> ---
>  drivers/staging/android/ion/ion.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/staging/android/ion/ion.c 
> b/drivers/staging/android/ion/ion.c
> index 14e48f6eb734..09cb5a8e2b09 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -261,8 +261,8 @@ static struct sg_table *ion_map_dma_buf(struct 
> dma_buf_attachment *attachment,
>  
>   table = a->table;
>  
> - if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
> - direction))
> + if (!dma_map_sg_attrs(attachment->dev, table->sgl, table->nents,
> +   direction, DMA_ATTR_SKIP_CPU_SYNC))

Unfortunately I don't think you can do this for a couple reasons.
You can't rely on {begin,end}_cpu_access calls to do cache maintenance.
If the calls to {begin,end}_cpu_access were made before the call to 
dma_buf_attach then there won't have been a device attached so the calls 
to {begin,end}_cpu_access won't have done any cache maintenance.

Also ION no longer provides DMA ready memory, so if you are not doing CPU 
access then there is no requirement (that I am aware of) for you to call 
{begin,end}_cpu_access before passing the buffer to the device and if this 
buffer is cached and your device is not IO-coherent then the cache maintenance
in ion_map_dma_buf and ion_unmap_dma_buf is required.

>   return ERR_PTR(-ENOMEM);
>  
>   return table;
> @@ -272,7 +272,8 @@ static void ion_unmap_dma_buf(struct dma_buf_attachment 
> *attachment,
> struct sg_table *table,
> enum dma_data_direction direction)
>  {
> - dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
> + dma_unmap_sg_attrs(attachment->dev, table->sgl, table->nents,
> +direction, DMA_ATTR_SKIP_CPU_SYNC);
>  }
>  
>  static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
> -- 
> 2.19.1
> 
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
> 

Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/3] dt-bindings: drm/panel: simple: add support for PDA 91-00156-A0

[Eugen.Hristev]

From: Cristian Birsan 

PDA 91-00156-A0 5.0 is a 5.0" WVGA TFT LCD panel.
This panel with backlight is found in PDA 5" LCD screen (TM5000 series or
AC320005-5).
Adding Device Tree bindings for this panel.

Signed-off-by: Cristian Birsan 
[eugen.hris...@microchip.com]: specified backlight and supply bindings
Signed-off-by: Eugen Hristev 
---
Changes in v2:
- added binding explanations for required properties from simple-panel:
backlight and power supply which are mandatory

 .../devicetree/bindings/display/panel/pda,91-00156-a0.txt  | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt 
b/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt
new file mode 100644
index 000..1639fb1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt
@@ -0,0 +1,14 @@
+PDA 91-00156-A0 5.0" WVGA TFT LCD panel
+
+Required properties:
+- compatible: should be "pda,91-00156-a0"
+- power-supply: this panel requires a single power supply. A phandle to a
+regulator needs to be specified here. Compatible with panel-common binding 
which
+is specified in the panel-common.txt in this directory.
+- backlight: this panel's backlight is controlled by an external backlight
+controller. A phandle to this controller needs to be specified here.
+Compatible with panel-common binding which is specified in the panel-common.txt
+in this directory.
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM

[Ard Biesheuvel]

On Thu, 10 Jan 2019 at 10:34, Michel Dänzer  wrote:
>
> On 2019-01-10 8:28 a.m., Ard Biesheuvel wrote:
> > ARM systems do not permit the use of anything other than cached
> > mappings for system memory, since that memory may be mapped in the
> > linear region as well, and the architecture does not permit aliases
> > with mismatched attributes.
> >
> > So short-circuit the evaluation in ttm_io_prot() if the flags include
> > TTM_PL_SYSTEM when running on ARM or arm64, and just return cached
> > attributes immediately.
> >
> > This fixes the radeon and amdgpu [TBC] drivers when running on arm64.
> > Without this change, amdgpu does not start at all, and radeon only
> > produces corrupt display output.
> >
> > Cc: Christian Koenig 
> > Cc: Huang Rui 
> > Cc: Junwei Zhang 
> > Cc: David Airlie 
> > Reported-by: Carsten Haitzler 
> > Signed-off-by: Ard Biesheuvel 
> > ---
> >  drivers/gpu/drm/ttm/ttm_bo_util.c | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
> > b/drivers/gpu/drm/ttm/ttm_bo_util.c
> > index 046a6dda690a..0c1eef5f7ae3 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> > @@ -530,6 +530,11 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t 
> > tmp)
> >   if (caching_flags & TTM_PL_FLAG_CACHED)
> >   return tmp;
> >
> > +#if defined(__arm__) || defined(__aarch64__)
> > + /* ARM only permits cached mappings of system memory */
> > + if (caching_flags & TTM_PL_SYSTEM)
> > + return tmp;
> > +#endif
> >  #if defined(__i386__) || defined(__x86_64__)
> >   if (caching_flags & TTM_PL_FLAG_WC)
> >   tmp = pgprot_writecombine(tmp);
> >
>
> Apart from Christian's concerns, I think this is the wrong place for
> this, because other TTM / driver code will still consider the memory
> uncacheable. E.g. the amdgpu driver will program the GPU to treat the
> memory as uncacheable, so it won't participate in cache coherency
> protocol for it, which is unlikely to work as expected in general if the
> CPU treats the memory as cacheable.
>

Will and I have spent some time digging into this, so allow me to
share some preliminary findings while we carry on and try to fix this
properly.

- The patch above is flawed, i.e., it doesn't do what it intends to
since it uses TTM_PL_SYSTEM instead of TTM_PL_FLAG_SYSTEM. Apologies
for that.
- The existence of a linear region mapping with mismatched attributes
is likely not the culprit here. (We do something similar with
non-cache coherent DMA in other places).
- The reason remapping the CPU side as cacheable does work (which I
did test) is because the GPU's uncacheable accesses (which I assume
are made using the NoSnoop PCIe transaction attribute) are actually
emitted as cacheable in some cases.
  . On my AMD Seattle, with or without SMMU (which is stage 2 only), I
must use cacheable accesses from the CPU side or things are broken.
This might be a h/w flaw, though.
  . On systems with stage 1+2 SMMUs, the driver uses stage 1
translations which always override the memory attributes to cacheable
for DMA coherent devices. This is what is affecting the Cavium
ThunderX2 (although it appears the attributes emitted by the RC may be
incorrect as well.)

The latter issue is a shortcoming in the SMMU driver that we have to
fix, i.e., it should take care not to modify the incoming attributes
of DMA coherent PCIe devices for NoSnoop to be able to work.

So in summary, the mismatch appears to be between the CPU accessing
the vmap region with non-cacheable attributes and the GPU accessing
the same memory with cacheable attributes, resulting in a loss of
coherency and lots of visible corruption.

To be able to debug this further, could you elaborate a bit on
- How does the hardware emit those uncached/wc inbound accesses? Do
they rely on NoSnoop?
- Christian pointed out that some accesses must be uncached even when
not using WC. What kind of accesses are those? And do they access
system RAM?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: radeon: annotate implicit fall through

[Mathieu Malaterre]

There is a plan to build the kernel with -Wimplicit-fallthrough and
this place in the code produced a warning (W=1).

This commit remove the following warning:

  drivers/gpu/drm/radeon/evergreen_cs.c:1301:11: warning: this statement may 
fall through [-Wimplicit-fallthrough=]

Signed-off-by: Mathieu Malaterre 
---
 drivers/gpu/drm/radeon/evergreen_cs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c 
b/drivers/gpu/drm/radeon/evergreen_cs.c
index f471537c852f..fbf346185790 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -1299,6 +1299,7 @@ static int evergreen_cs_handle_reg(struct 
radeon_cs_parser *p, u32 reg, u32 idx)
return -EINVAL;
}
ib[idx] += (u32)((reloc->gpu_offset >> 8) & 0x);
+   /* fall through */
case CB_TARGET_MASK:
track->cb_target_mask = radeon_get_ib_value(p, idx);
track->cb_dirty = true;
-- 
2.19.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/dp: annotate implicit fall throughs

[Gustavo A. R. Silva]

On 1/14/19 2:27 PM, Mathieu Malaterre wrote:

There is a plan to build the kernel with -Wimplicit-fallthrough and
these places in the code produced warnings (W=1). Fix them up.

This commit remove the following warnings:

   include/linux/compiler.h:77:22: warning: this statement may fall through 
[-Wimplicit-fallthrough=]
   include/asm-generic/bug.h:134:2: note: in expansion of macro 'unlikely'
   drivers/gpu/drm/drm_dp_helper.c:155:3: note: in expansion of macro 'WARN'
   include/linux/compiler.h:77:22: warning: this statement may fall through 
[-Wimplicit-fallthrough=]
   include/asm-generic/bug.h:134:2: note: in expansion of macro 'unlikely'
   drivers/gpu/drm/drm_dp_helper.c:173:3: note: in expansion of macro 'WARN'
   drivers/gpu/drm/drm_dp_helper.c:547:3: warning: this statement may fall 
through [-Wimplicit-fallthrough=]

Signed-off-by: Mathieu Malaterre 

Acked-by: Gustavo A. R. Silva 


---
  drivers/gpu/drm/drm_dp_helper.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 516e82d0ed50..26835d174939 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -154,6 +154,7 @@ u8 drm_dp_link_rate_to_bw_code(int link_rate)
default:
WARN(1, "unknown DP link rate %d, using %x\n", link_rate,
 DP_LINK_BW_1_62);
+   /* fall through */
case 162000:
return DP_LINK_BW_1_62;
case 27:
@@ -171,6 +172,7 @@ int drm_dp_bw_code_to_link_rate(u8 link_bw)
switch (link_bw) {
default:
WARN(1, "unknown DP link BW code %x, using 162000\n", link_bw);
+   /* fall through */
case DP_LINK_BW_1_62:
return 162000;
case DP_LINK_BW_2_7:
@@ -552,6 +554,7 @@ int drm_dp_downstream_max_bpc(const u8 
dpcd[DP_RECEIVER_CAP_SIZE],
case DP_DS_16BPC:
return 16;
}
+   /* fall through */
default:
return 0;
}


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/3] drm: Add panel support for PDA 91-00156-A0

[Eugen.Hristev]

From: Eugen Hristev 

Hello,

This patch series adds support for PDA (Precision Design Associates, Inc.)
vendor, and for the PDA 91-00156-A0 simple panel, together with the bindings.

The series is on top of http://anongit.freedesktop.org/git/drm/drm.git drm-next
branch.

Changes in v2:
- According to Rob Herring's review, added backlight and supply binding
to the .../devicetree/bindings/display/panel/pda,91-00156-a0.txt to comply with
the simple-panel bindings

Cristian Birsan (1):
  dt-bindings: drm/panel: simple: add support for PDA 91-00156-A0

Eugen Hristev (2):
  dt-bindings: add vendor prefix for PDA Precision Design Associates,
Inc.
  drm/panel: simple: add support for PDA 91-00156-A0 panel

 .../bindings/display/panel/pda,91-00156-a0.txt | 14 +++
 .../devicetree/bindings/vendor-prefixes.txt|  1 +
 drivers/gpu/drm/panel/panel-simple.c   | 27 ++
 3 files changed, 42 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.txt

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/3] dt-bindings: add vendor prefix for PDA Precision Design Associates, Inc.

[Eugen.Hristev]

From: Eugen Hristev 

Precision Design Associates, Inc. (PDA) manufactures standard and custom
capacitive touch screens, LCD's embedded controllers and custom embedded
software. They specialize in industrial, rugged and outdoor applications.
Website: http://www.pdaatl.com/

Signed-off-by: Eugen Hristev 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 3895085..967a670 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -297,6 +297,7 @@ ovtiOmniVision Technologies
 oxsemi Oxford Semiconductor, Ltd.
 panasonic  Panasonic Corporation
 parade Parade Technologies Inc.
+pdaPrecision Design Associates, Inc.
 pericomPericom Technology Inc.
 pervasive  Pervasive Displays, Inc.
 phicomm PHICOMM Co., Ltd.
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] qcom-scm: Include header

[Chris Healy]

Perhaps I am confused but it appears that this patch has already
landed upstream and got included in 5.0-rc2:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/linux/qcom_scm.h?h=v5.0-rc2=2076607a20bd4dfba699185616cbbbce06d3fa59

On Mon, Jan 14, 2019 at 11:51 AM Amit Kucheria
 wrote:
>
> On Sun, Dec 30, 2018 at 1:21 AM Andy Gross  wrote:
> >
> > On Sat, Dec 29, 2018 at 10:19:32AM -0200, Fabio Estevam wrote:
> > > Hi Bjorn,
> > >
> > > On Fri, Dec 28, 2018 at 10:27 PM Bjorn Andersson
> > >  wrote:
> > >
> > > > Sorry about that, I forgot that the header file is not covered by the
> > > > MAINTAINERS file.
> > > >
> > > > Your second patch looks good, but I'm hoping we can merge the upcoming
> > > > v3 of Amit's patch right after the merge window. It fixes this and a lot
> > > > of other pieces where we would like to include linux-arm-msm@:
> > > >
> > > > https://lore.kernel.org/lkml/d153a86748f99526e7790bfc4ef8781a2016fd51.1545126964.git.amit.kuche...@linaro.org/
> > >
> > > Amit's patch adds the following entry:
> > >
> > > +F: include/linux/*/qcom*
> > >
> > > but it does not catch include/linux/qcom_scm.h
> > >
> > > It also needs
> > >
> > > +F: include/linux/qcom*
> > >
> > > in order to catch include/linux/qcom-geni-se.h  and 
> > > include/linux/qcom_scm.h
> > >
> > > I can add that entry after Amit's patch gets applied.
> >
> > Or I can add it to Amit's.  I'll ping him to make sure that's ok.
> >
>
> I'd forgotten about this patch! Just sent out v3 which is still
> missing "F: include/linux/qcom*".
>
> Let me know if you want me to send out v4 with this added.
>
> Regards,
> Amit
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v9 00/22] Re-use nvram module

[Finn Thain]

The "generic" NVRAM module, drivers/char/generic_nvram.c, implements a
/dev/nvram misc device. This module is used only by 32-bit PowerPC
platforms.

The RTC "CMOS" NVRAM module, drivers/char/nvram.c, also implements a
/dev/nvram misc device. This module is now used only by x86 and m68k
thanks to commit 3ba9faedc180 ("char: nvram: disable on ARM").

The "generic" module cannot be used by x86 or m68k platforms because it
cannot co-exist with the "CMOS" module. One reason for that is the
CONFIG_GENERIC_NVRAM kludge in drivers/char/Makefile. Another reason is
that automatically loading the appropriate module would be impossible
because only one module can provide the char-major-10-144 alias.

A multi-platform kernel binary needs a single, generic module. With this
patch series, drivers/char/nvram.c becomes more generic and some of the
arch-specific code gets moved under arch/. The nvram module is then
usable by all m68k, powerpc and x86 platforms.

This allows for removal of drivers/char/generic_nvram.c as well as a
duplicate in arch/powerpc/kernel/nvram_64.c. By reducing the number of
/dev/nvram char misc device implementations, the number of bugs and
inconsistencies is also reduced.

This approach reduces inconsistencies between PPC32 and PPC64 and also
between PPC_PMAC and MAC. A uniform API has benefits for userspace.

For example, some error codes for some ioctl calls become consistent
across PowerPC platforms. The uniform API can potentially benefit any
bootloader that works across the various platforms having XPRAM
(e.g. Emile).

This patch series was tested on Atari, Mac, PowerMac (both 32-bit and
64-bit) and ThinkPad hardware. AFAIK, it has not yet been tested on
pSeries or CHRP.

I think there are two possible merge strategies for this patch series.
The char misc maintainer could take the entire series. Alternatively,
the m68k maintainer could take patches 1 thru 16 (though some of these
have nothing to do with m68k) and after those patches reach mainline
the powerpc maintainer could take 17 thru 22.

Changed since v8:
 - Replaced defined(CONFIG_NVRAM) with IS_REACHABLE(CONFIG_NVRAM) as
suggested by James Bottomley.
 - Changed #ifdef to if as suggested by Christophe Leroy.
 - Expanded the fbdev patch to include controlfb.c and platinumfb.c.
 - Added kernel-doc comment to describe struct nvram_ops.
 - Moved the HAVE_ARCH_NVRAM_OPS symbol to common code as suggested
by Christoph Hellwig.
 - Abandoned conversion of powerpc drivers to arch_nvram_ops, as discussed
with Arnd Bergmann.
 - Dropped patch 6 ("x86/thinkpad_acpi: Use arch_nvram_ops methods").
 - Dropped patch 17 ("powerpc: Implement arch_nvram_ops.get_size() ...").
 - Dropped patch 20 ("powerpc, fbdev: Use arch_nvram_ops methods ...").
 - Dropped patch 25 ("powerpc: Remove pmac_xpram_{read,write} functions").
 - Added portable static functions to nvram.h which wrap both arch_nvram_ops
and ppc_md method calls.
 - Re-ordered and revised patches to resolve conflicts with existing extern
definitions in nvram.h and elsewhere.
 - Rebased on v5.0-rc2.
 - Added patch 14 ("macintosh/via-cuda: Don't rely on Cuda to end a transfer").

Changed since v7:
 - Rebased.
 - Dropped patch 9/26, "char/nvram: Use generic fixed_size_llseek()"
because generic_file_llseek_size() was adopted in commit b808b1d632f6.
 - Reordered the m68k and powerpc patches to simplify the merge strategy.
 - Addressed some trivial checkpatch.pl complaints.
 - Improved some commit log entries.
 - Changed the CONFIG_NVRAM default to better approximate the present code.
In particular, the CONFIG_GENERIC_NVRAM default and use of "select NVRAM".
 - Added more tested-by tags.

For older change logs, please refer to,
https://lore.kernel.org/lkml/20151101104202.301856...@telegraphics.com.au/


Finn Thain (22):
  scsi/atari_scsi: Don't select CONFIG_NVRAM
  m68k/atari: Move Atari-specific code out of drivers/char/nvram.c
  char/nvram: Re-order functions to remove forward declarations and
#ifdefs
  nvram: Replace nvram_* function exports with static functions
  m68k/atari: Implement arch_nvram_ops struct
  powerpc: Replace nvram_* extern declarations with standard header
  char/nvram: Adopt arch_nvram_ops
  char/nvram: Allow the set_checksum and initialize ioctls to be omitted
  char/nvram: Implement NVRAM read/write methods
  m68k/atari: Implement arch_nvram_ops methods and enable
CONFIG_HAVE_ARCH_NVRAM_OPS
  m68k/mac: Adopt naming and calling conventions for PRAM routines
  m68k/mac: Use macros for RTC accesses not magic numbers
  m68k/mac: Fix PRAM accessors
  macintosh/via-cuda: Don't rely on Cuda to end a transfer
  m68k: Dispatch nvram_ops calls to Atari or Mac functions
  char/nvram: Add "devname:nvram" module alias
  powerpc: Define missing ppc_md.nvram_size for CHRP and PowerMac
  powerpc: Implement nvram ioctls
  powerpc, fbdev: Use NV_CMODE and NV_VMODE only when CONFIG_PPC32 &&
CONFIG_PPC_PMAC && CONFIG_NVRAM
  powerpc: Enable HAVE_ARCH_NVRAM_OPS and disable GENERIC_NVRAM

[Bug 109345] drm-next-2018-12-14 -Linux PPC

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109345

--- Comment #2 from Allan Cairns  ---
Micahel

Hope these help


Allan



On 14/01/19 9:19 pm, bugzilla-dae...@freedesktop.org wrote:
>
> *Comment # 1  
> on bug 109345  
> from Michel Dänzer  *
> Please attach the output of dmesg corresponding to the problem.
>
> Somebody will probably need to isolate the exact commit which introduced the
> problem using git bisect.
> 
> You are receiving this mail because:
>
>   * You reported the bug.
>

-- 
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 202263] AMDGPU: DRM couldn't schedule ib on ring (-22)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=202263

--- Comment #4 from Emre Işık (e.isi...@gmail.com) ---
(In reply to Alex Deucher from comment #1)
> Please attach your full dmesg output form boot (so it doesn't get lost when
> the pastebin goes away) and xorg log (if using X).

Okey I uploaded the both log files here.
Thanks for the fast reply!

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 202263] AMDGPU: DRM couldn't schedule ib on ring (-22)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=202263

--- Comment #2 from Emre Işık (e.isi...@gmail.com) ---
Created attachment 280479
  --> https://bugzilla.kernel.org/attachment.cgi?id=280479=edit
dmesg.log

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 202263] AMDGPU: DRM couldn't schedule ib on ring (-22)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=202263

--- Comment #3 from Emre Işık (e.isi...@gmail.com) ---
Created attachment 280481
  --> https://bugzilla.kernel.org/attachment.cgi?id=280481=edit
Xorg.0.log

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 1/1] drm: fix alpha build after drm_util.h change

[Sam Ravnborg]

Hi all.

Please do not apply.

O-DAY found a similar bug when building ia64, but this time there is
something else from irqflags.h that causes the error.

So...
> It was considered just to pull in interrupt.h but that would
> pull in a lot of unused stuff.

This seems to be the rigth solution anyway, as interrupt.h
have all the necessary dependencies.
I will try this tonight and post an updated patch.

Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb

[Noralf Trønnes]

Den 15.01.2019 05.38, skrev Noralf Trønnes:
> 
> 
> Den 15.01.2019 00.26, skrev David Lechner:
>> On 1/14/19 4:53 PM, Noralf Trønnes wrote:
>>>
>>>
>>> Den 14.01.2019 23.33, skrev David Lechner:
 On 1/14/19 3:50 PM, David Lechner wrote:
> On 1/14/19 10:13 AM, Noralf Trønnes wrote:
>>
>> I see that you have this call chain:
>> st7586_pipe_enable() -> mipi_dbi_enable_flush() ->
>> mipi_dbi_fb_dirty().
>>
>> That doesn't look safe. The st7586 driver allocates a tx_buf with
>> size:
>>  size_t bufsize = (mode->vdisplay + 2) / 3 * mode->hdisplay;
>>
>> whereas mipi_dbi_enable_flush() will trigger a copy to tx_buf with
>> len:
>> fb->width * fb->height * 2
>>
>> It looks like you're writing zeroes way past the end of the buffer.
>>
>> Noralf.
>>
>
> Thanks! That does indeed seem to be the problem. I'll put together
> a patch to fix this. I'm thinking it will be easier to make the
> fix before applying this series so that it will be easier to
> backport.
>

 Well, now that I am looking into it more, I see that the problem
 was not preexisting. This patch ("drm/tinydrm: Use damage helper
 for dirtyfb") also changes mipi_dbi_enable_flush() from calling
 tdev->fb_dirty() to mipi_dbi_fb_dirty().

 Perhaps we should not be dropping tdev->fb_dirty()?
>>>
>>> I want to get rid of tinydrm_device, to avoid tinydrm being like a
>>> mid-layer. My goal is to make tinydrm just a collection of tiny regular
>>> DRM drivers.
>>>
>>
>> OK. Perhaps we should add a comment to mipi_dbi_enable_flush() to
>> say that it should not be used by drivers with a custom dirty function.
>>
> 
> I've added a note.
> 
>> Or perhaps we could pass an optional parameter with the custom dirty
>> function to mipi_dbi_enable_flush() like this:
>>
> 
> I prefer to open code the function instead since it's only 2 lines of code.

'2 lines of code', that sounds like a misleading commercial :-)
It's more like 9 including the declarions. But anyways I prefer it.


> 
> Noralf.
> 
>> diff --git a/drivers/gpu/drm/tinydrm/hx8357d.c
>> b/drivers/gpu/drm/tinydrm/hx8357d.c
>> index 8bbd0beafc6a..4b9981ffe5a4 100644
>> --- a/drivers/gpu/drm/tinydrm/hx8357d.c
>> +++ b/drivers/gpu/drm/tinydrm/hx8357d.c
>> @@ -170,7 +170,7 @@ static void yx240qv29_enable(struct
>> drm_simple_display_pipe *pipe,
>>     break;
>>     }
>>     mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
>> -   mipi_dbi_enable_flush(mipi, crtc_state, plane_state);
>> +   mipi_dbi_enable_flush(mipi, crtc_state, plane_state, NULL);
>>  }
>>
>>  static const struct drm_simple_display_pipe_funcs hx8357d_pipe_funcs = {
>> diff --git a/drivers/gpu/drm/tinydrm/ili9225.c
>> b/drivers/gpu/drm/tinydrm/ili9225.c
>> index aa1376a22bda..bebfd0d01340 100644
>> --- a/drivers/gpu/drm/tinydrm/ili9225.c
>> +++ b/drivers/gpu/drm/tinydrm/ili9225.c
>> @@ -270,7 +270,7 @@ static void ili9225_pipe_enable(struct
>> drm_simple_display_pipe *pipe,
>>
>>     ili9225_command(mipi, ILI9225_DISPLAY_CONTROL_1, 0x1017);
>>
>> -   mipi_dbi_enable_flush(mipi, crtc_state, plane_state);
>> +   mipi_dbi_enable_flush(mipi, crtc_state, plane_state,
>> ili9225_fb_dirty);
>>  }
>>
>>  static void ili9225_pipe_disable(struct drm_simple_display_pipe *pipe)
>> diff --git a/drivers/gpu/drm/tinydrm/ili9341.c
>> b/drivers/gpu/drm/tinydrm/ili9341.c
>> index 713bb2dd7e04..ecfb8ff02a40 100644
>> --- a/drivers/gpu/drm/tinydrm/ili9341.c
>> +++ b/drivers/gpu/drm/tinydrm/ili9341.c
>> @@ -126,7 +126,7 @@ static void yx240qv29_enable(struct
>> drm_simple_display_pipe *pipe,
>>     }
>>     addr_mode |= ILI9341_MADCTL_BGR;
>>     mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
>> -   mipi_dbi_enable_flush(mipi, crtc_state, plane_state);
>> +   mipi_dbi_enable_flush(mipi, crtc_state, plane_state, NULL);
>>  }
>>
>>  static const struct drm_simple_display_pipe_funcs ili9341_pipe_funcs = {
>> diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c
>> b/drivers/gpu/drm/tinydrm/mi0283qt.c
>> index 82a92ec9ae3c..c81aa1fbc2ad 100644
>> --- a/drivers/gpu/drm/tinydrm/mi0283qt.c
>> +++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
>> @@ -134,7 +134,7 @@ static void mi0283qt_enable(struct
>> drm_simple_display_pipe *pipe,
>>     }
>>     addr_mode |= ILI9341_MADCTL_BGR;
>>     mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
>> -   mipi_dbi_enable_flush(mipi, crtc_state, plane_state);
>> +   mipi_dbi_enable_flush(mipi, crtc_state, plane_state, NULL);
>>  }
>>
>>  static const struct drm_simple_display_pipe_funcs mi0283qt_pipe_funcs = {
>> diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c
>> b/drivers/gpu/drm/tinydrm/mipi-dbi.c
>> index 680692a83f94..399c66b3f0d7 100644
>> --- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
>> +++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
>> @@ -287,6 +287,7 @@ EXPORT_SYMBOL(mipi_dbi_pipe_update);
>>   * @mipi: MIPI 

Re: [PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb

[Noralf Trønnes]

Den 15.01.2019 00.26, skrev David Lechner:
> On 1/14/19 4:53 PM, Noralf Trønnes wrote:
>>
>>
>> Den 14.01.2019 23.33, skrev David Lechner:
>>> On 1/14/19 3:50 PM, David Lechner wrote:
 On 1/14/19 10:13 AM, Noralf Trønnes wrote:
>
> I see that you have this call chain:
> st7586_pipe_enable() -> mipi_dbi_enable_flush() ->
> mipi_dbi_fb_dirty().
>
> That doesn't look safe. The st7586 driver allocates a tx_buf with
> size:
>  size_t bufsize = (mode->vdisplay + 2) / 3 * mode->hdisplay;
>
> whereas mipi_dbi_enable_flush() will trigger a copy to tx_buf with
> len:
> fb->width * fb->height * 2
>
> It looks like you're writing zeroes way past the end of the buffer.
>
> Noralf.
>

 Thanks! That does indeed seem to be the problem. I'll put together
 a patch to fix this. I'm thinking it will be easier to make the
 fix before applying this series so that it will be easier to
 backport.

>>>
>>> Well, now that I am looking into it more, I see that the problem
>>> was not preexisting. This patch ("drm/tinydrm: Use damage helper
>>> for dirtyfb") also changes mipi_dbi_enable_flush() from calling
>>> tdev->fb_dirty() to mipi_dbi_fb_dirty().
>>>
>>> Perhaps we should not be dropping tdev->fb_dirty()?
>>
>> I want to get rid of tinydrm_device, to avoid tinydrm being like a
>> mid-layer. My goal is to make tinydrm just a collection of tiny regular
>> DRM drivers.
>>
> 
> OK. Perhaps we should add a comment to mipi_dbi_enable_flush() to
> say that it should not be used by drivers with a custom dirty function.
> 

I've added a note.

> Or perhaps we could pass an optional parameter with the custom dirty
> function to mipi_dbi_enable_flush() like this:
> 

I prefer to open code the function instead since it's only 2 lines of code.

Noralf.

> diff --git a/drivers/gpu/drm/tinydrm/hx8357d.c
> b/drivers/gpu/drm/tinydrm/hx8357d.c
> index 8bbd0beafc6a..4b9981ffe5a4 100644
> --- a/drivers/gpu/drm/tinydrm/hx8357d.c
> +++ b/drivers/gpu/drm/tinydrm/hx8357d.c
> @@ -170,7 +170,7 @@ static void yx240qv29_enable(struct
> drm_simple_display_pipe *pipe,
>     break;
>     }
>     mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
> -   mipi_dbi_enable_flush(mipi, crtc_state, plane_state);
> +   mipi_dbi_enable_flush(mipi, crtc_state, plane_state, NULL);
>  }
> 
>  static const struct drm_simple_display_pipe_funcs hx8357d_pipe_funcs = {
> diff --git a/drivers/gpu/drm/tinydrm/ili9225.c
> b/drivers/gpu/drm/tinydrm/ili9225.c
> index aa1376a22bda..bebfd0d01340 100644
> --- a/drivers/gpu/drm/tinydrm/ili9225.c
> +++ b/drivers/gpu/drm/tinydrm/ili9225.c
> @@ -270,7 +270,7 @@ static void ili9225_pipe_enable(struct
> drm_simple_display_pipe *pipe,
> 
>     ili9225_command(mipi, ILI9225_DISPLAY_CONTROL_1, 0x1017);
> 
> -   mipi_dbi_enable_flush(mipi, crtc_state, plane_state);
> +   mipi_dbi_enable_flush(mipi, crtc_state, plane_state,
> ili9225_fb_dirty);
>  }
> 
>  static void ili9225_pipe_disable(struct drm_simple_display_pipe *pipe)
> diff --git a/drivers/gpu/drm/tinydrm/ili9341.c
> b/drivers/gpu/drm/tinydrm/ili9341.c
> index 713bb2dd7e04..ecfb8ff02a40 100644
> --- a/drivers/gpu/drm/tinydrm/ili9341.c
> +++ b/drivers/gpu/drm/tinydrm/ili9341.c
> @@ -126,7 +126,7 @@ static void yx240qv29_enable(struct
> drm_simple_display_pipe *pipe,
>     }
>     addr_mode |= ILI9341_MADCTL_BGR;
>     mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
> -   mipi_dbi_enable_flush(mipi, crtc_state, plane_state);
> +   mipi_dbi_enable_flush(mipi, crtc_state, plane_state, NULL);
>  }
> 
>  static const struct drm_simple_display_pipe_funcs ili9341_pipe_funcs = {
> diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c
> b/drivers/gpu/drm/tinydrm/mi0283qt.c
> index 82a92ec9ae3c..c81aa1fbc2ad 100644
> --- a/drivers/gpu/drm/tinydrm/mi0283qt.c
> +++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
> @@ -134,7 +134,7 @@ static void mi0283qt_enable(struct
> drm_simple_display_pipe *pipe,
>     }
>     addr_mode |= ILI9341_MADCTL_BGR;
>     mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
> -   mipi_dbi_enable_flush(mipi, crtc_state, plane_state);
> +   mipi_dbi_enable_flush(mipi, crtc_state, plane_state, NULL);
>  }
> 
>  static const struct drm_simple_display_pipe_funcs mi0283qt_pipe_funcs = {
> diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c
> b/drivers/gpu/drm/tinydrm/mipi-dbi.c
> index 680692a83f94..399c66b3f0d7 100644
> --- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
> +++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
> @@ -287,6 +287,7 @@ EXPORT_SYMBOL(mipi_dbi_pipe_update);
>   * @mipi: MIPI DBI structure
>   * @crtc_state: CRTC state
>   * @plane_state: Plane state
> + * @dirty: Optional custom dirty function
>   *
>   * This function sets _dbi->enabled, flushes the whole framebuffer
> and
>   * enables the backlight. Drivers can use this in their
> @@ -294,7 +295,9 @@ 

[PATCH v3 0/5] drm/tinydrm: Use damage helper for dirtyfb

[Noralf Trønnes]

David discovered a bug which gave memory corruption because the tx_buf
was written past its end for st7586 which has a smaller tx_buf. The
problem was that mipi_dbi_enable_flush() now calls directly into
mipi_dbi_fb_dirty() instead of going via the tindyrm_device dirtyfb
callback.

Changes:
- Include vblank header (Sam)
- ili9225 and st7586 can't use mipi_dbi_enable_flush() (David)

Noralf.

Noralf Trønnes (5):
  drm/gem-fb-helper: Add drm_gem_fb_create_with_dirty()
  drm/damage-helper: Add drm_atomic_helper_damage_merged()
  drm/tinydrm: Use struct drm_rect
  drm/tinydrm: Use damage helper for dirtyfb
  drm/todo: Tick off some tinydrm entries

 Documentation/gpu/todo.rst|  35 
 drivers/gpu/drm/drm_damage_helper.c   |  41 +
 drivers/gpu/drm/drm_gem_framebuffer_helper.c  |  50 +-
 drivers/gpu/drm/tinydrm/core/tinydrm-core.c   |  21 +--
 .../gpu/drm/tinydrm/core/tinydrm-helpers.c| 100 +---
 drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c   |  31 
 drivers/gpu/drm/tinydrm/hx8357d.c |   2 +-
 drivers/gpu/drm/tinydrm/ili9225.c | 149 +++---
 drivers/gpu/drm/tinydrm/ili9341.c |   2 +-
 drivers/gpu/drm/tinydrm/mi0283qt.c|   2 +-
 drivers/gpu/drm/tinydrm/mipi-dbi.c|  94 +++
 drivers/gpu/drm/tinydrm/repaper.c |  43 ++---
 drivers/gpu/drm/tinydrm/st7586.c  |  86 ++
 drivers/gpu/drm/tinydrm/st7735r.c |   2 +-
 include/drm/drm_damage_helper.h   |   3 +
 include/drm/drm_gem_framebuffer_helper.h  |   3 +
 include/drm/tinydrm/mipi-dbi.h|   5 +-
 include/drm/tinydrm/tinydrm-helpers.h |  20 +--
 include/drm/tinydrm/tinydrm.h |  26 ---
 19 files changed, 309 insertions(+), 406 deletions(-)

-- 
2.20.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 1/5] drm/gem-fb-helper: Add drm_gem_fb_create_with_dirty()

[Noralf Trønnes]

This adds a .fb_create helper that sets the .dirty callback to
drm_atomic_helper_dirtyfb().

v2: Improve docs (Daniel)

Signed-off-by: Noralf Trønnes 
Acked-by: Daniel Vetter 
Reviewed-by: Sam Ravnborg 
---
 drivers/gpu/drm/drm_gem_framebuffer_helper.c | 50 +---
 include/drm/drm_gem_framebuffer_helper.h |  3 ++
 2 files changed, 47 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c 
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index acb466d25afc..65edb1ccb185 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -136,10 +137,9 @@ EXPORT_SYMBOL(drm_gem_fb_create_handle);
  * @mode_cmd: Metadata from the userspace framebuffer creation request
  * @funcs: vtable to be used for the new framebuffer object
  *
- * This can be used to set _framebuffer_funcs for drivers that need the
- * _framebuffer_funcs.dirty callback. Use drm_gem_fb_create() if you don't
- * need to change _framebuffer_funcs.
- * The function does buffer size validation.
+ * This function can be used to set _framebuffer_funcs for drivers that 
need
+ * custom framebuffer callbacks. Use drm_gem_fb_create() if you don't need to
+ * change _framebuffer_funcs. The function does buffer size validation.
  *
  * Returns:
  * Pointer to a _framebuffer on success or an error pointer on failure.
@@ -215,8 +215,8 @@ static const struct drm_framebuffer_funcs drm_gem_fb_funcs 
= {
  *
  * If your hardware has special alignment or pitch requirements these should be
  * checked before calling this function. The function does buffer size
- * validation. Use drm_gem_fb_create_with_funcs() if you need to set
- * _framebuffer_funcs.dirty.
+ * validation. Use drm_gem_fb_create_with_dirty() if you need framebuffer
+ * flushing.
  *
  * Drivers can use this as their _mode_config_funcs.fb_create callback.
  * The ADDFB2 IOCTL calls into this callback.
@@ -233,6 +233,44 @@ drm_gem_fb_create(struct drm_device *dev, struct drm_file 
*file,
 }
 EXPORT_SYMBOL_GPL(drm_gem_fb_create);
 
+static const struct drm_framebuffer_funcs drm_gem_fb_funcs_dirtyfb = {
+   .destroy= drm_gem_fb_destroy,
+   .create_handle  = drm_gem_fb_create_handle,
+   .dirty  = drm_atomic_helper_dirtyfb,
+};
+
+/**
+ * drm_gem_fb_create_with_dirty() - Helper function for the
+ *   _mode_config_funcs.fb_create callback
+ * @dev: DRM device
+ * @file: DRM file that holds the GEM handle(s) backing the framebuffer
+ * @mode_cmd: Metadata from the userspace framebuffer creation request
+ *
+ * This function creates a new framebuffer object described by
+ * _mode_fb_cmd2. This description includes handles for the buffer(s)
+ * backing the framebuffer. drm_atomic_helper_dirtyfb() is used for the dirty
+ * callback giving framebuffer flushing through the atomic machinery. Use
+ * drm_gem_fb_create() if you don't need the dirty callback.
+ * The function does buffer size validation.
+ *
+ * Drivers should also call drm_plane_enable_fb_damage_clips() on all planes
+ * to enable userspace to use damage clips also with the ATOMIC IOCTL.
+ *
+ * Drivers can use this as their _mode_config_funcs.fb_create callback.
+ * The ADDFB2 IOCTL calls into this callback.
+ *
+ * Returns:
+ * Pointer to a _framebuffer on success or an error pointer on failure.
+ */
+struct drm_framebuffer *
+drm_gem_fb_create_with_dirty(struct drm_device *dev, struct drm_file *file,
+const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+   return drm_gem_fb_create_with_funcs(dev, file, mode_cmd,
+   _gem_fb_funcs_dirtyfb);
+}
+EXPORT_SYMBOL_GPL(drm_gem_fb_create_with_dirty);
+
 /**
  * drm_gem_fb_prepare_fb() - Prepare a GEM backed framebuffer
  * @plane: Plane
diff --git a/include/drm/drm_gem_framebuffer_helper.h 
b/include/drm/drm_gem_framebuffer_helper.h
index a38de7eb55b4..7f307e834eef 100644
--- a/include/drm/drm_gem_framebuffer_helper.h
+++ b/include/drm/drm_gem_framebuffer_helper.h
@@ -25,6 +25,9 @@ drm_gem_fb_create_with_funcs(struct drm_device *dev, struct 
drm_file *file,
 struct drm_framebuffer *
 drm_gem_fb_create(struct drm_device *dev, struct drm_file *file,
  const struct drm_mode_fb_cmd2 *mode_cmd);
+struct drm_framebuffer *
+drm_gem_fb_create_with_dirty(struct drm_device *dev, struct drm_file *file,
+const struct drm_mode_fb_cmd2 *mode_cmd);
 
 int drm_gem_fb_prepare_fb(struct drm_plane *plane,
  struct drm_plane_state *state);
-- 
2.20.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 2/5] drm/damage-helper: Add drm_atomic_helper_damage_merged()

[Noralf Trønnes]

Useful for drivers that only care about the combined damage.

v2: Remove unnecessary clearing of damage clips

Cc: Deepak Rawat 
Signed-off-by: Noralf Trønnes 
Acked-by: Daniel Vetter 
Reviewed-by: Sam Ravnborg 
---
 drivers/gpu/drm/drm_damage_helper.c | 41 +
 include/drm/drm_damage_helper.h |  3 +++
 2 files changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/drm_damage_helper.c 
b/drivers/gpu/drm/drm_damage_helper.c
index 31032407254d..e16aa5ae00b4 100644
--- a/drivers/gpu/drm/drm_damage_helper.c
+++ b/drivers/gpu/drm/drm_damage_helper.c
@@ -333,3 +333,44 @@ drm_atomic_helper_damage_iter_next(struct 
drm_atomic_helper_damage_iter *iter,
return ret;
 }
 EXPORT_SYMBOL(drm_atomic_helper_damage_iter_next);
+
+/**
+ * drm_atomic_helper_damage_merged - Merged plane damage
+ * @old_state: Old plane state for validation.
+ * @state: Plane state from which to iterate the damage clips.
+ * @rect: Returns the merged damage rectangle
+ *
+ * This function merges any valid plane damage clips into one rectangle and
+ * returns it in @rect.
+ *
+ * For details see: drm_atomic_helper_damage_iter_init() and
+ * drm_atomic_helper_damage_iter_next().
+ *
+ * Returns:
+ * True if there is valid plane damage otherwise false.
+ */
+bool drm_atomic_helper_damage_merged(const struct drm_plane_state *old_state,
+struct drm_plane_state *state,
+struct drm_rect *rect)
+{
+   struct drm_atomic_helper_damage_iter iter;
+   struct drm_rect clip;
+   bool valid = false;
+
+   rect->x1 = INT_MAX;
+   rect->y1 = INT_MAX;
+   rect->x2 = 0;
+   rect->y2 = 0;
+
+   drm_atomic_helper_damage_iter_init(, old_state, state);
+   drm_atomic_for_each_plane_damage(, ) {
+   rect->x1 = min(rect->x1, clip.x1);
+   rect->y1 = min(rect->y1, clip.y1);
+   rect->x2 = max(rect->x2, clip.x2);
+   rect->y2 = max(rect->y2, clip.y2);
+   valid = true;
+   }
+
+   return valid;
+}
+EXPORT_SYMBOL(drm_atomic_helper_damage_merged);
diff --git a/include/drm/drm_damage_helper.h b/include/drm/drm_damage_helper.h
index 4487660b26b8..40c34a5bf149 100644
--- a/include/drm/drm_damage_helper.h
+++ b/include/drm/drm_damage_helper.h
@@ -78,6 +78,9 @@ drm_atomic_helper_damage_iter_init(struct 
drm_atomic_helper_damage_iter *iter,
 bool
 drm_atomic_helper_damage_iter_next(struct drm_atomic_helper_damage_iter *iter,
   struct drm_rect *rect);
+bool drm_atomic_helper_damage_merged(const struct drm_plane_state *old_state,
+struct drm_plane_state *state,
+struct drm_rect *rect);
 
 /**
  * drm_helper_get_plane_damage_clips - Returns damage clips in _rect.
-- 
2.20.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 4/5] drm/tinydrm: Use damage helper for dirtyfb

[Noralf Trønnes]

This switches to drm_atomic_helper_dirtyfb() as the framebuffer dirty
handler. All flushing will now happen in the pipe functions.

Also enable the damage plane property for all except repaper which can
only do full updates.

ili9225:
This change made ili9225_init() equal to mipi_dbi_init() so use it.

v3: Include vblank header (Sam)
ili9225 and st7586 can't use mipi_dbi_enable_flush() (David)

v2: Remove fb check in mipi_dbi_enable_flush() it can't be NULL
(kbuild test robot)

Cc: David Lechner 
Cc: Eric Anholt 
Signed-off-by: Noralf Trønnes 
Acked-by: Daniel Vetter 
Reviewed-by: Sam Ravnborg 
---
 drivers/gpu/drm/tinydrm/core/tinydrm-core.c   |  21 +---
 .../gpu/drm/tinydrm/core/tinydrm-helpers.c|  91 +-
 drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c   |  31 -
 drivers/gpu/drm/tinydrm/hx8357d.c |   2 +-
 drivers/gpu/drm/tinydrm/ili9225.c | 112 +++---
 drivers/gpu/drm/tinydrm/ili9341.c |   2 +-
 drivers/gpu/drm/tinydrm/mi0283qt.c|   2 +-
 drivers/gpu/drm/tinydrm/mipi-dbi.c|  79 +++-
 drivers/gpu/drm/tinydrm/repaper.c |  40 ---
 drivers/gpu/drm/tinydrm/st7586.c  |  63 ++
 drivers/gpu/drm/tinydrm/st7735r.c |   2 +-
 include/drm/tinydrm/mipi-dbi.h|   2 +
 include/drm/tinydrm/tinydrm-helpers.h |  11 +-
 include/drm/tinydrm/tinydrm.h |  26 
 14 files changed, 165 insertions(+), 319 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
index aeb93eadb047..614f532ea89f 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
@@ -39,31 +39,17 @@
  * and registers the DRM device using devm_tinydrm_register().
  */
 
-static struct drm_framebuffer *
-tinydrm_fb_create(struct drm_device *drm, struct drm_file *file_priv,
- const struct drm_mode_fb_cmd2 *mode_cmd)
-{
-   struct tinydrm_device *tdev = drm->dev_private;
-
-   return drm_gem_fb_create_with_funcs(drm, file_priv, mode_cmd,
-   tdev->fb_funcs);
-}
-
 static const struct drm_mode_config_funcs tinydrm_mode_config_funcs = {
-   .fb_create = tinydrm_fb_create,
+   .fb_create = drm_gem_fb_create_with_dirty,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
 };
 
 static int tinydrm_init(struct device *parent, struct tinydrm_device *tdev,
-   const struct drm_framebuffer_funcs *fb_funcs,
struct drm_driver *driver)
 {
struct drm_device *drm;
 
-   mutex_init(>dirty_lock);
-   tdev->fb_funcs = fb_funcs;
-
/*
 * We don't embed drm_device, because that prevent us from using
 * devm_kzalloc() to allocate tinydrm_device in the driver since
@@ -86,7 +72,6 @@ static int tinydrm_init(struct device *parent, struct 
tinydrm_device *tdev,
 static void tinydrm_fini(struct tinydrm_device *tdev)
 {
drm_mode_config_cleanup(tdev->drm);
-   mutex_destroy(>dirty_lock);
tdev->drm->dev_private = NULL;
drm_dev_put(tdev->drm);
 }
@@ -100,7 +85,6 @@ static void devm_tinydrm_release(void *data)
  * devm_tinydrm_init - Initialize tinydrm device
  * @parent: Parent device object
  * @tdev: tinydrm device
- * @fb_funcs: Framebuffer functions
  * @driver: DRM driver
  *
  * This function initializes @tdev, the underlying DRM device and it's
@@ -111,12 +95,11 @@ static void devm_tinydrm_release(void *data)
  * Zero on success, negative error code on failure.
  */
 int devm_tinydrm_init(struct device *parent, struct tinydrm_device *tdev,
- const struct drm_framebuffer_funcs *fb_funcs,
  struct drm_driver *driver)
 {
int ret;
 
-   ret = tinydrm_init(parent, tdev, fb_funcs, driver);
+   ret = tinydrm_init(parent, tdev, driver);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index d0ece6ad4a1c..2737b6fdadc8 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -17,104 +17,15 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
 #include 
-#include 
 
 static unsigned int spi_max;
 module_param(spi_max, uint, 0400);
 MODULE_PARM_DESC(spi_max, "Set a lower SPI max transfer size");
 
-/**
- * tinydrm_merge_clips - Merge clip rectangles
- * @dst: Destination clip rectangle
- * @src: Source clip rectangle(s)
- * @num_clips: Number of @src clip rectangles
- * @flags: Dirty fb ioctl flags
- * @max_width: Maximum width of @dst
- * @max_height: Maximum height of @dst
- *
- * This function merges @src clip rectangle(s) into @dst. If @src is NULL,
- * @max_width and @min_width is used to set a full @dst clip rectangle.

[PATCH v3 5/5] drm/todo: Tick off some tinydrm entries

[Noralf Trønnes]

- Better manual-upload support for atomic
  The new damage helper has the necessary pieces to make this work.

- tinydrm_gem_cma_prime_import_sg_table
  This is now moved to the CMA helper and can be set using the
  DRM_GEM_CMA_VMAP_DRIVER_OPS macro.

- tinydrm_fb_create
  This is now covered by drm_gem_fb_create_with_dirty()

Cc: Sam Ravnborg 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Sam Ravnborg 
---
 Documentation/gpu/todo.rst | 35 ---
 1 file changed, 35 deletions(-)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 0a85dad876ae..38360ede1221 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -82,30 +82,6 @@ events for atomic commits correctly. But fixing these bugs 
is good anyway.
 
 Contact: Daniel Vetter, respective driver maintainers
 
-Better manual-upload support for atomic

-
-This would be especially useful for tinydrm:
-
-- Add a struct drm_rect dirty_clip to drm_crtc_state. When duplicating the
-  crtc state, clear that to the max values, x/y = 0 and w/h = MAX_INT, in
-  __drm_atomic_helper_crtc_duplicate_state().
-
-- Move tinydrm_merge_clips into drm_framebuffer.c, dropping the tinydrm\_
-  prefix ofc and using drm_fb\_. drm_framebuffer.c makes sense since this
-  is a function useful to implement the fb->dirty function.
-
-- Create a new drm_fb_dirty function which does essentially what e.g.
-  mipi_dbi_fb_dirty does. You can use e.g. drm_atomic_helper_update_plane as 
the
-  template. But instead of doing a simple full-screen plane update, this new
-  helper also sets crtc_state->dirty_clip to the right coordinates. And of
-  course it needs to check whether the fb is actually active (and maybe where),
-  so there's some book-keeping involved. There's also some good fun involved in
-  scaling things appropriately. For that case we might simply give up and
-  declare the entire area covered by the plane as dirty.
-
-Contact: Noralf Trønnes, Daniel Vetter
-
 Fallout from atomic KMS
 ---
 
@@ -459,21 +435,10 @@ those drivers as simple as possible, so lots of room for 
refactoring:
   one of the ideas for having a shared dsi/dbi helper, abstracting away the
   transport details more.
 
-- tinydrm_gem_cma_prime_import_sg_table should probably go into the cma
-  helpers, as a _vmapped variant (since not every driver needs the vmap).
-  And tinydrm_gem_cma_free_object could the be merged into
-  drm_gem_cma_free_object().
-
-- tinydrm_fb_create we could move into drm_simple_pipe, only need to add
-  the fb_create hook to drm_simple_pipe_funcs, which would again simplify a
-  bunch of things (since it gives you a one-stop vfunc for simple drivers).
-
 - Quick aside: The unregister devm stuff is kinda getting the lifetimes of
   a drm_device wrong. Doesn't matter, since everyone else gets it wrong
   too :-)
 
-- also rework the drm_framebuffer_funcs->dirty hook wire-up, see above.
-
 Contact: Noralf Trønnes, Daniel Vetter
 
 AMD DC Display Driver
-- 
2.20.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 3/5] drm/tinydrm: Use struct drm_rect

[Noralf Trønnes]

This prepares for the switch to drm_atomic_helper_dirtyfb() in the next
patch. The damage helper returns a drm_rect so switch to that everywhere
including using a pointer in the dirty functions.

This is a non-functional change except for the debug print which looks a
bit different.

Signed-off-by: Noralf Trønnes 
Acked-by: Daniel Vetter 
Reviewed-by: Sam Ravnborg 
---
 .../gpu/drm/tinydrm/core/tinydrm-helpers.c| 19 
 drivers/gpu/drm/tinydrm/ili9225.c | 43 ++-
 drivers/gpu/drm/tinydrm/mipi-dbi.c| 21 -
 drivers/gpu/drm/tinydrm/repaper.c |  3 +-
 drivers/gpu/drm/tinydrm/st7586.c  | 27 ++--
 include/drm/tinydrm/mipi-dbi.h|  3 +-
 include/drm/tinydrm/tinydrm-helpers.h | 11 ++---
 7 files changed, 67 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index bf6bfbc5d412..d0ece6ad4a1c 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -41,7 +42,7 @@ MODULE_PARM_DESC(spi_max, "Set a lower SPI max transfer 
size");
  * Returns:
  * true if it's a full clip, false otherwise
  */
-bool tinydrm_merge_clips(struct drm_clip_rect *dst,
+bool tinydrm_merge_clips(struct drm_rect *dst,
 struct drm_clip_rect *src, unsigned int num_clips,
 unsigned int flags, u32 max_width, u32 max_height)
 {
@@ -63,10 +64,10 @@ bool tinydrm_merge_clips(struct drm_clip_rect *dst,
for (i = 0; i < num_clips; i++) {
if (flags & DRM_MODE_FB_DIRTY_ANNOTATE_COPY)
i++;
-   dst->x1 = min(dst->x1, src[i].x1);
-   dst->x2 = max(dst->x2, src[i].x2);
-   dst->y1 = min(dst->y1, src[i].y1);
-   dst->y2 = max(dst->y2, src[i].y2);
+   dst->x1 = min_t(int, dst->x1, src[i].x1);
+   dst->x2 = max_t(int, dst->x2, src[i].x2);
+   dst->y1 = min_t(int, dst->y1, src[i].y1);
+   dst->y2 = max_t(int, dst->y2, src[i].y2);
}
 
if (dst->x2 > max_width || dst->y2 > max_height ||
@@ -122,7 +123,7 @@ EXPORT_SYMBOL(tinydrm_fb_dirty);
  * @clip: Clip rectangle area to copy
  */
 void tinydrm_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
-   struct drm_clip_rect *clip)
+   struct drm_rect *clip)
 {
unsigned int cpp = drm_format_plane_cpp(fb->format->format, 0);
unsigned int pitch = fb->pitches[0];
@@ -146,7 +147,7 @@ EXPORT_SYMBOL(tinydrm_memcpy);
  * @clip: Clip rectangle area to copy
  */
 void tinydrm_swab16(u16 *dst, void *vaddr, struct drm_framebuffer *fb,
-   struct drm_clip_rect *clip)
+   struct drm_rect *clip)
 {
size_t len = (clip->x2 - clip->x1) * sizeof(u16);
unsigned int x, y;
@@ -186,7 +187,7 @@ EXPORT_SYMBOL(tinydrm_swab16);
  */
 void tinydrm_xrgb_to_rgb565(u16 *dst, void *vaddr,
struct drm_framebuffer *fb,
-   struct drm_clip_rect *clip, bool swap)
+   struct drm_rect *clip, bool swap)
 {
size_t len = (clip->x2 - clip->x1) * sizeof(u32);
unsigned int x, y;
@@ -235,7 +236,7 @@ EXPORT_SYMBOL(tinydrm_xrgb_to_rgb565);
  * ITU BT.601 is used for the RGB -> luma (brightness) conversion.
  */
 void tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr, struct drm_framebuffer 
*fb,
-  struct drm_clip_rect *clip)
+  struct drm_rect *clip)
 {
unsigned int len = (clip->x2 - clip->x1) * sizeof(u32);
unsigned int x, y;
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c 
b/drivers/gpu/drm/tinydrm/ili9225.c
index b0ad58b97227..ad644069089f 100644
--- a/drivers/gpu/drm/tinydrm/ili9225.c
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -84,7 +85,8 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
struct tinydrm_device *tdev = fb->dev->dev_private;
struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
bool swap = mipi->swap_bytes;
-   struct drm_clip_rect clip;
+   struct drm_rect clip;
+   struct drm_rect *rect = 
u16 x_start, y_start;
u16 x1, x2, y1, y2;
int ret = 0;
@@ -97,13 +99,12 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
full = tinydrm_merge_clips(, clips, num_clips, flags,
   fb->width, fb->height);
 
-   DRM_DEBUG("Flushing [FB:%d] x1=%u, x2=%u, y1=%u, y2=%u\n", fb->base.id,
- clip.x1, clip.x2, clip.y1, clip.y2);
+   DRM_DEBUG_KMS("Flushing [FB:%d] " DRM_RECT_FMT "\n", fb->base.id, 
DRM_RECT_ARG(rect));
 

[Bug 109361] [KBL-G][GL-es] several shader test cases failed to compile

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109361

Hai  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
 QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org

-- 
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 109361] [KBL-G][GL-es] several shader test cases failed to compile

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109361

Bug ID: 109361
   Summary: [KBL-G][GL-es] several shader test cases failed to
compile
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: hai@intel.com
QA Contact: dri-devel@lists.freedesktop.org

When ruuning OpenGL CTS, several shader test cases failed to compile


Test Environment
Platform: KBL-G
CPU: Intel (R) Core (TM) i7-8809G CPU @3.10GHz
GPU: AMD(Radeon RX Vega M GH Graphics); Intel GPU
Memory: 16G
OS: Ubutu18.04
Kernel: 4.19.0
amd driver version: amdgpu-pro-18.40-697810-ubuntu-18.04.tar.xz(Open Stack) 
VK-GL-CTS commit id:54e546a1a0a6fa412ea4c3e3081bbc9518928a6e


Failed cases list:
dEQP-GLES3.functional.shaders.preprocessor.conditional_inclusion.defined_macro_defined_test_vertex
dEQP-GLES3.functional.shaders.preprocessor.conditional_inclusion.defined_macro_defined_test_fragment
dEQP-GLES3.functional.shaders.preprocessor.conditional_inclusion.define_defined_vertex
dEQP-GLES3.functional.shaders.preprocessor.conditional_inclusion.define_defined_fragment
dEQP-GLES3.functional.shaders.preprocessor.conditional_inclusion.define_defined_outside_if_vertex
dEQP-GLES3.functional.shaders.preprocessor.conditional_inclusion.define_defined_outside_if_fragment

dEQP-GLES2.functional.shaders.scoping.valid.local_variable_hides_function_parameter_vertex
dEQP-GLES2.functional.shaders.scoping.valid.local_variable_hides_function_parameter_fragment

run command:
./glcts -n
dEQP-GLES3.functional.shaders.preprocessor.conditional_inclusion.defined_macro_defined_test_vertex
Writing test log into TestResults.qpa
dEQP Core git-54e546a1a0a6fa412ea4c3e3081bbc9518928a6e (0x54e546a1) starting..
  target implementation = 'Default'

Test case
'dEQP-GLES3.functional.shaders.preprocessor.conditional_inclusion.defined_macro_defined_test_vertex'..
  Fail (expected shaders to compile and link properly, but failed to compile.)

DONE!

Test run totals:
  Passed:0/1 (0.0%)
  Failed:1/1 (100.0%)
  Not supported: 0/1 (0.0%)
  Warnings:  0/1 (0.0%)

-- 
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 00/14] Misc ION cleanups and adding unmapped heap

[Laura Abbott]

On 1/11/19 10:05 AM, Andrew F. Davis wrote:

Hello all,

This is a set of (hopefully) non-controversial cleanups for the ION
framework and current set of heaps. These were found as I start to
familiarize myself with the framework to help in whatever way I
can in getting all this up to the standards needed for de-staging.

I would like to get some ideas of what is left to work on to get ION
out of staging. Has there been some kind of agreement on what ION should
eventually end up being? To me it looks like it is being whittled away at
to it's most core functions. To me that is looking like being a DMA-BUF
user-space front end, simply advertising available memory backings in a
system and providing allocations as DMA-BUF handles. If this is the case
then it looks close to being ready to me at least, but I would love to
hear any other opinions and concerns.



Yes, at this point the only functionality that people are really
depending on is the ability to allocate a dma_buf easily from userspace.


Back to this patchset, the last patch may be a bit different than the
others, it adds an unmapped heaps type and creation helper. I wanted to
get this in to show off another heap type and maybe some issues we may
have with the current ION framework. The unmapped heap is used when the
backing memory should not (or cannot) be touched. Currently this kind
of heap is used for firewalled secure memory that can be allocated like
normal heap memory but only used by secure devices (OP-TEE, crypto HW,
etc). It is basically just copied from the "carveout" heap type with the
only difference being it is not mappable to userspace and we do not clear
the memory (as we should not map it either). So should this really be a
new heap type? Or maybe advertised as a carveout heap but with an
additional allocation flag? Perhaps we do away with "types" altogether
and just have flags, coherent/non-coherent, mapped/unmapped, etc.

Maybe more thinking will be needed afterall..



So the cleanup looks okay (I need to finish reviewing) but I'm not a
fan of adding another heaptype without solving the problem of adding
some sort of devicetree binding or other method of allocating and
placing Ion heaps. That plus uncached buffers are one of the big
open problems that need to be solved for destaging Ion. See
https://lore.kernel.org/lkml/20181120164636.jcw7li2uaa3cmwc3@DESKTOP-E1NTVVP.localdomain/
for some background on that problem.

Thanks,
Laura


Thanks,
Andrew

Andrew F. Davis (14):
   staging: android: ion: Add proper header information
   staging: android: ion: Remove empty ion_ioctl_dir() function
   staging: android: ion: Merge ion-ioctl.c into ion.c
   staging: android: ion: Remove leftover comment
   staging: android: ion: Remove struct ion_platform_heap
   staging: android: ion: Fixup some white-space issues
   staging: android: ion: Sync comment docs with struct ion_buffer
   staging: android: ion: Remove base from ion_carveout_heap
   staging: android: ion: Remove base from ion_chunk_heap
   staging: android: ion: Remove unused headers
   staging: android: ion: Allow heap name to be null
   staging: android: ion: Declare helpers for carveout and chunk heaps
   staging: android: ion: Do not sync CPU cache on map/unmap
   staging: android: ion: Add UNMAPPED heap type and helper

  drivers/staging/android/ion/Kconfig   |  10 ++
  drivers/staging/android/ion/Makefile  |   3 +-
  drivers/staging/android/ion/ion-ioctl.c   |  98 --
  drivers/staging/android/ion/ion.c |  93 +++--
  drivers/staging/android/ion/ion.h |  87 -
  .../staging/android/ion/ion_carveout_heap.c   |  19 +--
  drivers/staging/android/ion/ion_chunk_heap.c  |  25 ++--
  drivers/staging/android/ion/ion_cma_heap.c|   6 +-
  drivers/staging/android/ion/ion_heap.c|   8 +-
  drivers/staging/android/ion/ion_page_pool.c   |   2 +-
  drivers/staging/android/ion/ion_system_heap.c |   8 +-
  .../staging/android/ion/ion_unmapped_heap.c   | 123 ++
  drivers/staging/android/uapi/ion.h|   3 +
  13 files changed, 307 insertions(+), 178 deletions(-)
  delete mode 100644 drivers/staging/android/ion/ion-ioctl.c
  create mode 100644 drivers/staging/android/ion/ion_unmapped_heap.c



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 14/14] staging: android: ion: Add UNMAPPED heap type and helper

[Laura Abbott]

On 1/11/19 10:05 AM, Andrew F. Davis wrote:

The "unmapped" heap is very similar to the carveout heap except
the backing memory is presumed to be unmappable by the host, in
my specific case due to firewalls. This memory can still be
allocated from and used by devices that do have access to the
backing memory.

Based originally on the secure/unmapped heap from Linaro for
the OP-TEE SDP implementation, this was re-written to match
the carveout heap helper code.

Suggested-by: Etienne Carriere 
Signed-off-by: Andrew F. Davis 
---
  drivers/staging/android/ion/Kconfig   |  10 ++
  drivers/staging/android/ion/Makefile  |   1 +
  drivers/staging/android/ion/ion.h |  16 +++
  .../staging/android/ion/ion_unmapped_heap.c   | 123 ++
  drivers/staging/android/uapi/ion.h|   3 +
  5 files changed, 153 insertions(+)
  create mode 100644 drivers/staging/android/ion/ion_unmapped_heap.c

diff --git a/drivers/staging/android/ion/Kconfig 
b/drivers/staging/android/ion/Kconfig
index 0fdda6f62953..a117b8b91b14 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -42,3 +42,13 @@ config ION_CMA_HEAP
  Choose this option to enable CMA heaps with Ion. This heap is backed
  by the Contiguous Memory Allocator (CMA). If your system has these
  regions, you should say Y here.
+
+config ION_UNMAPPED_HEAP
+   bool "ION unmapped heap support"
+   depends on ION
+   help
+ Choose this option to enable UNMAPPED heaps with Ion. This heap is
+ backed in specific memory pools, carveout from the Linux memory.
+ Unlike carveout heaps these are assumed to be not mappable by
+ kernel or user-space.
+ Unless you know your system has these regions, you should say N here.
diff --git a/drivers/staging/android/ion/Makefile 
b/drivers/staging/android/ion/Makefile
index 17f3a7569e3d..c71a1f3de581 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o 
ion_page_pool.o
  obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
  obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
  obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
+obj-$(CONFIG_ION_UNMAPPED_HEAP) += ion_unmapped_heap.o
diff --git a/drivers/staging/android/ion/ion.h 
b/drivers/staging/android/ion/ion.h
index 97b2876b165a..ce74332018ba 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -341,4 +341,20 @@ static inline struct ion_heap 
*ion_chunk_heap_create(phys_addr_t base, size_t si
  }
  #endif
  
+#ifdef CONFIG_ION_UNMAPPED_HEAP

+/**
+ * ion_unmapped_heap_create
+ * @base:  base address of carveout memory
+ * @size:  size of carveout memory region
+ *
+ * Creates an unmapped ion_heap using the passed in data
+ */
+struct ion_heap *ion_unmapped_heap_create(phys_addr_t base, size_t size);
+#else
+struct ion_heap *ion_unmapped_heap_create(phys_addr_t base, size_t size)
+{
+   return ERR_PTR(-ENODEV);
+}
+#endif
+
  #endif /* _ION_H */
diff --git a/drivers/staging/android/ion/ion_unmapped_heap.c 
b/drivers/staging/android/ion/ion_unmapped_heap.c
new file mode 100644
index ..7602b659c2ec
--- /dev/null
+++ b/drivers/staging/android/ion/ion_unmapped_heap.c
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ION Memory Allocator unmapped heap helper
+ *
+ * Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis 
+ *
+ * ION "unmapped" heaps are physical memory heaps not by default mapped into
+ * a virtual address space. The buffer owner can explicitly request kernel
+ * space mappings but the underlying memory may still not be accessible for
+ * various reasons, such as firewalls.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "ion.h"
+
+#define ION_UNMAPPED_ALLOCATE_FAIL -1
+
+struct ion_unmapped_heap {
+   struct ion_heap heap;
+   struct gen_pool *pool;
+};
+
+static phys_addr_t ion_unmapped_allocate(struct ion_heap *heap,
+unsigned long size)
+{
+   struct ion_unmapped_heap *unmapped_heap =
+   container_of(heap, struct ion_unmapped_heap, heap);
+   unsigned long offset;
+
+   offset = gen_pool_alloc(unmapped_heap->pool, size);
+   if (!offset)
+   return ION_UNMAPPED_ALLOCATE_FAIL;
+
+   return offset;
+}
+
+static void ion_unmapped_free(struct ion_heap *heap, phys_addr_t addr,
+ unsigned long size)
+{
+   struct ion_unmapped_heap *unmapped_heap =
+   container_of(heap, struct ion_unmapped_heap, heap);
+
+   gen_pool_free(unmapped_heap->pool, addr, size);
+}
+
+static int ion_unmapped_heap_allocate(struct ion_heap *heap,
+ struct ion_buffer *buffer,
+ unsigned long 

[Bug 109360] [AMD][TAHITI XT] dota2 vulkan texture glitches

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109360

Bug ID: 109360
   Summary: [AMD][TAHITI XT] dota2 vulkan texture glitches
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: sylvain.bertr...@gmail.com

linux(amd-staging-drm-next), libdrm, llvm, mesa, xserver, xf86-video-amdgpu,
all git from last sunday

linux from 2 weeks ago seems ok with this sunday userland stack. Something
committed last week probably broke in the kernel.

currently, looking into reproducing the glitches for sure in order to bisect

-- 
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 104362] GPU fault detected on wine-nine Path of Exile

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104362

--- Comment #17 from Marek Olšák  ---
(In reply to nmr from comment #15)
> Marek forgive my ignorance but why would SGPR spilling or branching cause
> the hang? Is the shader just timing out somehow and the timeout resulting in
> a kernel module abort?

Pretty much. The shader is stuck and doesn't continue. Also the shader is
insanely huge with lots of SGPR spilling and branching.

-- 
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 104362] GPU fault detected on wine-nine Path of Exile

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104362

--- Comment #16 from Marek Olšák  ---
The wave dump suggests that image_sample_lz might be responsible for the hang,
but its SGPR inputs seem to contain valid descriptors.

-- 
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 104362] GPU fault detected on wine-nine Path of Exile

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104362

--- Comment #15 from nmr  ---
Marek forgive my ignorance but why would SGPR spilling or branching cause the
hang? Is the shader just timing out somehow and the timeout resulting in a
kernel module abort?

-- 
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 104362] GPU fault detected on wine-nine Path of Exile

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104362

--- Comment #14 from Marek Olšák  ---
There is some branching and SGPR spilling, so I guess that's the problem.

-- 
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: Armada DRM: bridge with componentized devices

[Rafael J. Wysocki]

[CC Lukas and linux-pm]

On Mon, Jan 14, 2019 at 1:32 PM Rafael J. Wysocki  wrote:
>
> On Fri, Jan 11, 2019 at 3:49 PM Russell King - ARM Linux
>  wrote:

[cut]

> >
> > This thread is discussing how to deal with Armada DRM, its use of the
> > component helper, TDA998x's hybrid use of the component helper and
> > DRM bridges.
> >
> > Currently, DRM bridges register into the DRM system and are added to
> > a global list of bridges.  When a DRM driver binds, it looks up the
> > DRM bridge and attaches to it.  There is no way in generic DRM code
> > for the DRM driver to know if the DRM bridge is unbound from DRM,
> > consequently a DRM driver may continue trying to call functions in
> > the DRM bridge driver using memory that has already been freed.
> >
> > We had similar issues with imx-drm, and a number of years ago at a
> > kernel summit, this was discussed, and I proposed a system which is
> > now known as the component helper.  This handles the problem of a
> > multi-component system.
> >
> > However, DRM bridge was already established, and there appears to be
> > no desire to convert DRM bridges and DRM drivers to use the component
> > helper.
> >
> > We are presently in the situation where Armada DRM is incompatible
> > with the DRM bridges way of doing things, and making it compatible
> > essentially means introducing potential use-after-free bugs into the
> > code.
> >
> > Device links in their stateful form appear to provide an alternative
> > to the component helper, in that a stateful device link will remove
> > consumers of a resource when the supplier is going away - which is
> > exactly the problem which the component helper is solving.  The
> > difference is that device links look like being a cleaner solution.
> >
> > Just like the component helper, a stateful link would unbind the
> > consumer of a resource when the supplier goes away - which is exactly
> > the behaviour we're wanting.
> >
> > The problem is that the connection between various drivers is only
> > really known when the drivers obtain their resources, and the
> > following can happen:
> >
> > supplierconsumer
> >
> > probe()
> >  alloc
> > probe()
> >  publish
> > obtain supplier's resource
> >  return
> >
> > Where things go wrong is if a stateful link is created when the
> > consumer obtains the suppliers resource before the supplier has
> > finished probing - which from what's been said is illegal.
>
> It just doesn't work (which means "invalid" rather than "illegal" I
> guess, but whatever :-)).
>
> Admittedly, the original design didn't take this particular case into
> account and I'm not actually sure how it can be taken into account
> either.
>
> If the link is created by the consumer in the scenario above, its
> status will be updated twice in a row after the consumer probe returns
> and after the supplier probe returns.  It looks like this update would
> need to work regardless of the order it which this happened which
> sounds somewhat challenging.  I would need to think about that.

So if I'm not mistaken it can be made work with the help of the
(completely untested) attached patch (of course, the documentation
would need to be updated too).

The key observation here is that it should be fine to create a link
from the consumer driver's probe while the supplier is still probing
if the consumer has some way to find out that the supplier is
functional at that point (like when it has published itself already in
your example above).  The initial state of the link can be "consumer
probe" in that case and I don't see a reason why that might not work.
---
 drivers/base/core.c |   19 +++
 1 file changed, 19 insertions(+)

Index: linux-pm/drivers/base/core.c
===
--- linux-pm.orig/drivers/base/core.c
+++ linux-pm/drivers/base/core.c
@@ -260,6 +260,17 @@ struct device_link *device_link_add(stru
 		link->status = DL_STATE_NONE;
 	} else {
 		switch (supplier->links.status) {
+		case DL_DEV_PROBING:
+			/*
+			 * A consumer driver can create a link to a supplier
+			 * that also is probing as long as it knows that the
+			 * supplier is already functional (for example, it has
+			 * just acquired some resources from the supplier).
+			 */
+			link->status = consumer->links.status == DL_DEV_PROBING ?
+	DL_STATE_CONSUMER_PROBE :
+	DL_STATE_DORMANT;
+			break;
 		case DL_DEV_DRIVER_BOUND:
 			switch (consumer->links.status) {
 			case DL_DEV_PROBING:
@@ -474,6 +485,14 @@ void device_links_driver_bound(struct de
 		if (link->flags & DL_FLAG_STATELESS)
 			continue;
 
+		/*
+		 * Links created during consumer probe may be in the "consumer
+		 * probe" state to start with if the supplier is still probing
+		 * when they are created.  Skip them here.
+		 */
+		if (link->status == DL_STATE_CONSUMER_PROBE)
+			continue;
+
 		WARN_ON(link->status != DL_STATE_DORMANT);
 		

linux-next: build failure after merge of the mali-dp tree

[Stephen Rothwell]

Hi Liviu,

After merging the mali-dp tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c: In function 
'komeda_pipeline_obj_add':
drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c:48:30: error: passing 
argument 1 of 'drm_atomic_private_obj_init' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
  drm_atomic_private_obj_init(>obj, >obj,
  ^~
In file included from drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h:11,
 from drivers/gpu/drm/arm/display/komeda/komeda_dev.h:12,
 from drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c:7:
include/drm/drm_atomic.h:437:53: note: expected 'struct drm_device *' but 
argument is of type 'struct drm_private_obj *'
 void drm_atomic_private_obj_init(struct drm_device *dev,
  ~~~^~~
drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c:48:42: error: passing 
argument 2 of 'drm_atomic_private_obj_init' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
  drm_atomic_private_obj_init(>obj, >obj,
  ^~~~
In file included from drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h:11,
 from drivers/gpu/drm/arm/display/komeda/komeda_dev.h:12,
 from drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c:7:
include/drm/drm_atomic.h:438:30: note: expected 'struct drm_private_obj *' but 
argument is of type 'struct drm_private_state *'
  struct drm_private_obj *obj,
  ^~~
drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c:49:9: error: passing 
argument 3 of 'drm_atomic_private_obj_init' from incompatible pointer type 
[-Werror=incompatible-pointer-types]
 _pipeline_obj_funcs);
 ^~
In file included from drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h:11,
 from drivers/gpu/drm/arm/display/komeda/komeda_dev.h:12,
 from drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c:7:
include/drm/drm_atomic.h:439:32: note: expected 'struct drm_private_state *' 
but argument is of type 'const struct drm_private_state_funcs *'
  struct drm_private_state *state,
  ~~^
drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c:48:2: error: too few 
arguments to function 'drm_atomic_private_obj_init'
  drm_atomic_private_obj_init(>obj, >obj,
  ^~~
In file included from drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h:11,
 from drivers/gpu/drm/arm/display/komeda/komeda_dev.h:12,
 from drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c:7:
include/drm/drm_atomic.h:437:6: note: declared here
 void drm_atomic_private_obj_init(struct drm_device *dev,
  ^~~

Caused by commit

  61f1c4a8ab75 ("drm/komeda: Attach komeda_dev to DRM-KMS")

interacting with commit

  b962a12050a3 ("drm/atomic: integrate modeset lock with private objects")

from the drm tree.

I have applied the following merge fix patch:

From: Stephen Rothwell 
Date: Tue, 15 Jan 2019 10:42:04 +1100
Subject: [PATCH] drm/komeda: merge fix for drm_atomic_private_obj_init() API 
change

Signed-off-by: Stephen Rothwell 
---
 drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
index 9edfd6ab0c12..f1c9e3fefa86 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
@@ -45,7 +45,7 @@ static int komeda_pipeline_obj_add(struct komeda_kms_dev *kms,
return -ENOMEM;
 
st->pipe = pipe;
-   drm_atomic_private_obj_init(>obj, >obj,
+   drm_atomic_private_obj_init(>base, >obj, >obj,
_pipeline_obj_funcs);
 
return 0;
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell


pgp4opwoRe1F7.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb

[David Lechner]

On 1/14/19 4:53 PM, Noralf Trønnes wrote:



Den 14.01.2019 23.33, skrev David Lechner:

On 1/14/19 3:50 PM, David Lechner wrote:

On 1/14/19 10:13 AM, Noralf Trønnes wrote:


I see that you have this call chain:
st7586_pipe_enable() -> mipi_dbi_enable_flush() -> mipi_dbi_fb_dirty().

That doesn't look safe. The st7586 driver allocates a tx_buf with size:
 size_t bufsize = (mode->vdisplay + 2) / 3 * mode->hdisplay;

whereas mipi_dbi_enable_flush() will trigger a copy to tx_buf with len:
fb->width * fb->height * 2

It looks like you're writing zeroes way past the end of the buffer.

Noralf.



Thanks! That does indeed seem to be the problem. I'll put together
a patch to fix this. I'm thinking it will be easier to make the
fix before applying this series so that it will be easier to
backport.



Well, now that I am looking into it more, I see that the problem
was not preexisting. This patch ("drm/tinydrm: Use damage helper
for dirtyfb") also changes mipi_dbi_enable_flush() from calling
tdev->fb_dirty() to mipi_dbi_fb_dirty().

Perhaps we should not be dropping tdev->fb_dirty()?


I want to get rid of tinydrm_device, to avoid tinydrm being like a
mid-layer. My goal is to make tinydrm just a collection of tiny regular
DRM drivers.



OK. Perhaps we should add a comment to mipi_dbi_enable_flush() to
say that it should not be used by drivers with a custom dirty function.

Or perhaps we could pass an optional parameter with the custom dirty
function to mipi_dbi_enable_flush() like this:

diff --git a/drivers/gpu/drm/tinydrm/hx8357d.c 
b/drivers/gpu/drm/tinydrm/hx8357d.c
index 8bbd0beafc6a..4b9981ffe5a4 100644
--- a/drivers/gpu/drm/tinydrm/hx8357d.c
+++ b/drivers/gpu/drm/tinydrm/hx8357d.c
@@ -170,7 +170,7 @@ static void yx240qv29_enable(struct drm_simple_display_pipe 
*pipe,
break;
}
mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
-   mipi_dbi_enable_flush(mipi, crtc_state, plane_state);
+   mipi_dbi_enable_flush(mipi, crtc_state, plane_state, NULL);
 }

 static const struct drm_simple_display_pipe_funcs hx8357d_pipe_funcs = {
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c 
b/drivers/gpu/drm/tinydrm/ili9225.c
index aa1376a22bda..bebfd0d01340 100644
--- a/drivers/gpu/drm/tinydrm/ili9225.c
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -270,7 +270,7 @@ static void ili9225_pipe_enable(struct 
drm_simple_display_pipe *pipe,

ili9225_command(mipi, ILI9225_DISPLAY_CONTROL_1, 0x1017);

-   mipi_dbi_enable_flush(mipi, crtc_state, plane_state);
+   mipi_dbi_enable_flush(mipi, crtc_state, plane_state, ili9225_fb_dirty);
 }

 static void ili9225_pipe_disable(struct drm_simple_display_pipe *pipe)
diff --git a/drivers/gpu/drm/tinydrm/ili9341.c 
b/drivers/gpu/drm/tinydrm/ili9341.c
index 713bb2dd7e04..ecfb8ff02a40 100644
--- a/drivers/gpu/drm/tinydrm/ili9341.c
+++ b/drivers/gpu/drm/tinydrm/ili9341.c
@@ -126,7 +126,7 @@ static void yx240qv29_enable(struct drm_simple_display_pipe 
*pipe,
}
addr_mode |= ILI9341_MADCTL_BGR;
mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
-   mipi_dbi_enable_flush(mipi, crtc_state, plane_state);
+   mipi_dbi_enable_flush(mipi, crtc_state, plane_state, NULL);
 }

 static const struct drm_simple_display_pipe_funcs ili9341_pipe_funcs = {
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 82a92ec9ae3c..c81aa1fbc2ad 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -134,7 +134,7 @@ static void mi0283qt_enable(struct drm_simple_display_pipe 
*pipe,
}
addr_mode |= ILI9341_MADCTL_BGR;
mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
-   mipi_dbi_enable_flush(mipi, crtc_state, plane_state);
+   mipi_dbi_enable_flush(mipi, crtc_state, plane_state, NULL);
 }

 static const struct drm_simple_display_pipe_funcs mi0283qt_pipe_funcs = {
diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index 680692a83f94..399c66b3f0d7 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -287,6 +287,7 @@ EXPORT_SYMBOL(mipi_dbi_pipe_update);
  * @mipi: MIPI DBI structure
  * @crtc_state: CRTC state
  * @plane_state: Plane state
+ * @dirty: Optional custom dirty function
  *
  * This function sets _dbi->enabled, flushes the whole framebuffer and
  * enables the backlight. Drivers can use this in their
@@ -294,7 +295,9 @@ EXPORT_SYMBOL(mipi_dbi_pipe_update);
  */
 void mipi_dbi_enable_flush(struct mipi_dbi *mipi,
   struct drm_crtc_state *crtc_state,
-  struct drm_plane_state *plane_state)
+  struct drm_plane_state *plane_state,
+  void (*dirty)(struct drm_framebuffer *fb,
+struct drm_rect *rect))
 {
struct drm_framebuffer *fb = plane_state->fb;
struct drm_rect rect = {

Re: [PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb

[Noralf Trønnes]

Den 15.01.2019 00.03, skrev David Lechner:
> On 1/14/19 4:43 PM, Noralf Trønnes wrote:
>>
>>
>> Den 14.01.2019 23.33, skrev David Lechner:
>>> On 1/14/19 3:50 PM, David Lechner wrote:
 On 1/14/19 10:13 AM, Noralf Trønnes wrote:
>
> I see that you have this call chain:
> st7586_pipe_enable() -> mipi_dbi_enable_flush() ->
> mipi_dbi_fb_dirty().
>
> That doesn't look safe. The st7586 driver allocates a tx_buf with
> size:
>  size_t bufsize = (mode->vdisplay + 2) / 3 * mode->hdisplay;
>
> whereas mipi_dbi_enable_flush() will trigger a copy to tx_buf with
> len:
> fb->width * fb->height * 2
>
> It looks like you're writing zeroes way past the end of the buffer.
>
> Noralf.
>

 Thanks! That does indeed seem to be the problem. I'll put together
 a patch to fix this. I'm thinking it will be easier to make the
 fix before applying this series so that it will be easier to
 backport.

>>>
>>> Well, now that I am looking into it more, I see that the problem
>>> was not preexisting. This patch ("drm/tinydrm: Use damage helper
>>> for dirtyfb") also changes mipi_dbi_enable_flush() from calling
>>> tdev->fb_dirty() to mipi_dbi_fb_dirty().
>>>
>>> Perhaps we should not be dropping tdev->fb_dirty()?
>>
>> Ah, now it makes sense. I thought it strange that you hadn't experienced
>> the corruption before.
>>
>> How about this change?
>>
>> diff --git a/drivers/gpu/drm/tinydrm/st7586.c
>> b/drivers/gpu/drm/tinydrm/st7586.c
>> index d39417b74e8b..01a8077954b3 100644
>> --- a/drivers/gpu/drm/tinydrm/st7586.c
>> +++ b/drivers/gpu/drm/tinydrm/st7586.c
>> @@ -177,6 +177,13 @@ static void st7586_pipe_enable(struct
>> drm_simple_display_pipe *pipe,
>>   {
>>  struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
>>  struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
>> +   struct drm_framebuffer *fb = plane_state->fb;
>> +   struct drm_rect rect = {
>> +   .x1 = 0,
>> +   .x2 = fb->width,
>> +   .y1 = 0,
>> +   .y2 = fb->height,
>> +   };
>>  int ret;
>>  u8 addr_mode;
>>
>> @@ -233,9 +240,10 @@ static void st7586_pipe_enable(struct
>> drm_simple_display_pipe *pipe,
>>
>>  msleep(100);
>>
>> -   mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_ON);
>> +   mipi->enabled = true;
>> +   st7586_fb_dirty(fb, );
>>
>> -   mipi_dbi_enable_flush(mipi, crtc_state, plane_state);
>> +   mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_ON);
>>   }
>>
>>   static void st7586_pipe_disable(struct drm_simple_display_pipe *pipe)
>>
>>
> 
> 
> That looks good. I also noticed that ili9225 has a custom dirty
> function, so it will need a similar change as well.
> 

Thanks for tracking this down, I'll spin a new version tomorrow.

Noralf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb

[David Lechner]

On 1/14/19 4:43 PM, Noralf Trønnes wrote:



Den 14.01.2019 23.33, skrev David Lechner:

On 1/14/19 3:50 PM, David Lechner wrote:

On 1/14/19 10:13 AM, Noralf Trønnes wrote:


I see that you have this call chain:
st7586_pipe_enable() -> mipi_dbi_enable_flush() -> mipi_dbi_fb_dirty().

That doesn't look safe. The st7586 driver allocates a tx_buf with size:
 size_t bufsize = (mode->vdisplay + 2) / 3 * mode->hdisplay;

whereas mipi_dbi_enable_flush() will trigger a copy to tx_buf with len:
fb->width * fb->height * 2

It looks like you're writing zeroes way past the end of the buffer.

Noralf.



Thanks! That does indeed seem to be the problem. I'll put together
a patch to fix this. I'm thinking it will be easier to make the
fix before applying this series so that it will be easier to
backport.



Well, now that I am looking into it more, I see that the problem
was not preexisting. This patch ("drm/tinydrm: Use damage helper
for dirtyfb") also changes mipi_dbi_enable_flush() from calling
tdev->fb_dirty() to mipi_dbi_fb_dirty().

Perhaps we should not be dropping tdev->fb_dirty()?


Ah, now it makes sense. I thought it strange that you hadn't experienced
the corruption before.

How about this change?

diff --git a/drivers/gpu/drm/tinydrm/st7586.c
b/drivers/gpu/drm/tinydrm/st7586.c
index d39417b74e8b..01a8077954b3 100644
--- a/drivers/gpu/drm/tinydrm/st7586.c
+++ b/drivers/gpu/drm/tinydrm/st7586.c
@@ -177,6 +177,13 @@ static void st7586_pipe_enable(struct
drm_simple_display_pipe *pipe,
  {
 struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
 struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
+   struct drm_framebuffer *fb = plane_state->fb;
+   struct drm_rect rect = {
+   .x1 = 0,
+   .x2 = fb->width,
+   .y1 = 0,
+   .y2 = fb->height,
+   };
 int ret;
 u8 addr_mode;

@@ -233,9 +240,10 @@ static void st7586_pipe_enable(struct
drm_simple_display_pipe *pipe,

 msleep(100);

-   mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_ON);
+   mipi->enabled = true;
+   st7586_fb_dirty(fb, );

-   mipi_dbi_enable_flush(mipi, crtc_state, plane_state);
+   mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_ON);
  }

  static void st7586_pipe_disable(struct drm_simple_display_pipe *pipe)





That looks good. I also noticed that ili9225 has a custom dirty
function, so it will need a similar change as well.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb

[Noralf Trønnes]

Den 14.01.2019 23.33, skrev David Lechner:
> On 1/14/19 3:50 PM, David Lechner wrote:
>> On 1/14/19 10:13 AM, Noralf Trønnes wrote:
>>>
>>> I see that you have this call chain:
>>> st7586_pipe_enable() -> mipi_dbi_enable_flush() -> mipi_dbi_fb_dirty().
>>>
>>> That doesn't look safe. The st7586 driver allocates a tx_buf with size:
>>> size_t bufsize = (mode->vdisplay + 2) / 3 * mode->hdisplay;
>>>
>>> whereas mipi_dbi_enable_flush() will trigger a copy to tx_buf with len:
>>> fb->width * fb->height * 2
>>>
>>> It looks like you're writing zeroes way past the end of the buffer.
>>>
>>> Noralf.
>>>
>>
>> Thanks! That does indeed seem to be the problem. I'll put together
>> a patch to fix this. I'm thinking it will be easier to make the
>> fix before applying this series so that it will be easier to
>> backport.
>>
> 
> Well, now that I am looking into it more, I see that the problem
> was not preexisting. This patch ("drm/tinydrm: Use damage helper
> for dirtyfb") also changes mipi_dbi_enable_flush() from calling
> tdev->fb_dirty() to mipi_dbi_fb_dirty().
> 
> Perhaps we should not be dropping tdev->fb_dirty()?

I want to get rid of tinydrm_device, to avoid tinydrm being like a
mid-layer. My goal is to make tinydrm just a collection of tiny regular
DRM drivers.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb

[Noralf Trønnes]

Den 14.01.2019 23.06, skrev David Lechner:
> On 1/11/19 2:12 PM, Noralf Trønnes wrote:
>> This switches to drm_atomic_helper_dirtyfb() as the framebuffer dirty
>> handler. All flushing will now happen in the pipe functions.
>>
>> Also enable the damage plane property for all except repaper which can
>> only do full updates.
>>
>> ili9225:
>> This change made ili9225_init() equal to mipi_dbi_init() so use it.
>>
>> v2: Remove fb check in mipi_dbi_enable_flush() it can't be NULL
>>  (kbuild test robot)
>>
>> Cc: David Lechner 
>> Cc: Eric Anholt 
>> Signed-off-by: Noralf Trønnes 
>> Acked-by: Sam Ravnborg 
>> Acked-by: Daniel Vetter 
>> ---
> 
> 
> ...
> 
>> diff --git a/drivers/gpu/drm/tinydrm/st7586.c
>> b/drivers/gpu/drm/tinydrm/st7586.c
>> index a52bc3b02606..50e370ce5a59 100644
>> --- a/drivers/gpu/drm/tinydrm/st7586.c
>> +++ b/drivers/gpu/drm/tinydrm/st7586.c
>> @@ -17,6 +17,7 @@
>>   #include 
>>   #include 
>>   +#include 
>>   #include 
>>   #include 
>>   #include 
>> @@ -112,23 +113,15 @@ static int st7586_buf_copy(void *dst, struct
>> drm_framebuffer *fb,
>>   return ret;
>>   }
>>   -static int st7586_fb_dirty(struct drm_framebuffer *fb,
>> -   struct drm_file *file_priv, unsigned int flags,
>> -   unsigned int color, struct drm_clip_rect *clips,
>> -   unsigned int num_clips)
>> +static void st7586_fb_dirty(struct drm_framebuffer *fb, struct
>> drm_rect *rect)
>>   {
>>   struct tinydrm_device *tdev = fb->dev->dev_private;
>>   struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
>> -    struct drm_rect clip;
>> -    struct drm_rect *rect = 
> 
> This function later modifies the fields of the struct pointed to by rect.
> Are all callers of this function OK with having it modified or should we
> make a local copy of rect and modify that instead?

It's safe to modify it. st7586_pipe_update() owns the structure and it
doesn't use it after calling st7586_fb_dirty().

Noralf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb

[Noralf Trønnes]

Den 14.01.2019 23.33, skrev David Lechner:
> On 1/14/19 3:50 PM, David Lechner wrote:
>> On 1/14/19 10:13 AM, Noralf Trønnes wrote:
>>>
>>> I see that you have this call chain:
>>> st7586_pipe_enable() -> mipi_dbi_enable_flush() -> mipi_dbi_fb_dirty().
>>>
>>> That doesn't look safe. The st7586 driver allocates a tx_buf with size:
>>> size_t bufsize = (mode->vdisplay + 2) / 3 * mode->hdisplay;
>>>
>>> whereas mipi_dbi_enable_flush() will trigger a copy to tx_buf with len:
>>> fb->width * fb->height * 2
>>>
>>> It looks like you're writing zeroes way past the end of the buffer.
>>>
>>> Noralf.
>>>
>>
>> Thanks! That does indeed seem to be the problem. I'll put together
>> a patch to fix this. I'm thinking it will be easier to make the
>> fix before applying this series so that it will be easier to
>> backport.
>>
> 
> Well, now that I am looking into it more, I see that the problem
> was not preexisting. This patch ("drm/tinydrm: Use damage helper
> for dirtyfb") also changes mipi_dbi_enable_flush() from calling
> tdev->fb_dirty() to mipi_dbi_fb_dirty().
> 
> Perhaps we should not be dropping tdev->fb_dirty()?

Ah, now it makes sense. I thought it strange that you hadn't experienced
the corruption before.

How about this change?

diff --git a/drivers/gpu/drm/tinydrm/st7586.c
b/drivers/gpu/drm/tinydrm/st7586.c
index d39417b74e8b..01a8077954b3 100644
--- a/drivers/gpu/drm/tinydrm/st7586.c
+++ b/drivers/gpu/drm/tinydrm/st7586.c
@@ -177,6 +177,13 @@ static void st7586_pipe_enable(struct
drm_simple_display_pipe *pipe,
 {
struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
+   struct drm_framebuffer *fb = plane_state->fb;
+   struct drm_rect rect = {
+   .x1 = 0,
+   .x2 = fb->width,
+   .y1 = 0,
+   .y2 = fb->height,
+   };
int ret;
u8 addr_mode;

@@ -233,9 +240,10 @@ static void st7586_pipe_enable(struct
drm_simple_display_pipe *pipe,

msleep(100);

-   mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_ON);
+   mipi->enabled = true;
+   st7586_fb_dirty(fb, );

-   mipi_dbi_enable_flush(mipi, crtc_state, plane_state);
+   mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_ON);
 }

 static void st7586_pipe_disable(struct drm_simple_display_pipe *pipe)


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 95517] Constant GPU VM faults

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=95517

Dima  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

-- 
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 4/5] drm/tinydrm: Use damage helper for dirtyfb

[David Lechner]

On 1/14/19 3:50 PM, David Lechner wrote:

On 1/14/19 10:13 AM, Noralf Trønnes wrote:


I see that you have this call chain:
st7586_pipe_enable() -> mipi_dbi_enable_flush() -> mipi_dbi_fb_dirty().

That doesn't look safe. The st7586 driver allocates a tx_buf with size:
size_t bufsize = (mode->vdisplay + 2) / 3 * mode->hdisplay;

whereas mipi_dbi_enable_flush() will trigger a copy to tx_buf with len:
fb->width * fb->height * 2

It looks like you're writing zeroes way past the end of the buffer.

Noralf.



Thanks! That does indeed seem to be the problem. I'll put together
a patch to fix this. I'm thinking it will be easier to make the
fix before applying this series so that it will be easier to
backport.



Well, now that I am looking into it more, I see that the problem
was not preexisting. This patch ("drm/tinydrm: Use damage helper
for dirtyfb") also changes mipi_dbi_enable_flush() from calling
tdev->fb_dirty() to mipi_dbi_fb_dirty().

Perhaps we should not be dropping tdev->fb_dirty()?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: Pass down rc in intel_encoder->compute_config()

[Lyude Paul]

Something that I completely missed when implementing the new MST VCPI
atomic helpers is that with those helpers, there's technically a chance
of us having to grab additional modeset locks in ->compute_config() and
furthermore, that means we have the potential to hit a normal modeset
deadlock. However, because ->compute_config() only returns a bool this
means we can't return -EDEADLK when we need to drop locks and try again
which means we end up just failing the atomic check permanently. Whoops.

So, fix this by modifying ->compute_config() to pass down an actual
error code instead of a bool so that the atomic check can be restarted
on modeset deadlocks.

Thanks to Ville Syrjälä for pointing this out!

Signed-off-by: Lyude Paul 
Cc: Ville Syrjälä 
Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320
---
 drivers/gpu/drm/i915/icl_dsi.c   |  8 +++
 drivers/gpu/drm/i915/intel_crt.c | 34 ++--
 drivers/gpu/drm/i915/intel_ddi.c |  6 ++---
 drivers/gpu/drm/i915/intel_display.c | 11 +
 drivers/gpu/drm/i915/intel_dp.c  | 32 +-
 drivers/gpu/drm/i915/intel_dp_mst.c  | 12 +-
 drivers/gpu/drm/i915/intel_drv.h | 18 +++
 drivers/gpu/drm/i915/intel_dvo.c | 10 
 drivers/gpu/drm/i915/intel_hdmi.c| 12 +-
 drivers/gpu/drm/i915/intel_lvds.c| 12 +-
 drivers/gpu/drm/i915/intel_sdvo.c| 14 ++--
 drivers/gpu/drm/i915/intel_tv.c  |  8 +++
 drivers/gpu/drm/i915/vlv_dsi.c   | 14 ++--
 13 files changed, 97 insertions(+), 94 deletions(-)

diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
index f3a5f03646ce..355b48d1c937 100644
--- a/drivers/gpu/drm/i915/icl_dsi.c
+++ b/drivers/gpu/drm/i915/icl_dsi.c
@@ -1188,9 +1188,9 @@ static void gen11_dsi_get_config(struct intel_encoder 
*encoder,
pipe_config->output_types |= BIT(INTEL_OUTPUT_DSI);
 }
 
-static bool gen11_dsi_compute_config(struct intel_encoder *encoder,
-struct intel_crtc_state *pipe_config,
-struct drm_connector_state *conn_state)
+static int gen11_dsi_compute_config(struct intel_encoder *encoder,
+   struct intel_crtc_state *pipe_config,
+   struct drm_connector_state *conn_state)
 {
struct intel_dsi *intel_dsi = container_of(encoder, struct intel_dsi,
   base);
@@ -1215,7 +1215,7 @@ static bool gen11_dsi_compute_config(struct intel_encoder 
*encoder,
pipe_config->clock_set = true;
pipe_config->port_clock = intel_dsi_bitrate(intel_dsi) / 5;
 
-   return true;
+   return 0;
 }
 
 static u64 gen11_dsi_get_power_domains(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 33bd2addcbdd..625794883433 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -345,51 +345,51 @@ intel_crt_mode_valid(struct drm_connector *connector,
return MODE_OK;
 }
 
-static bool intel_crt_compute_config(struct intel_encoder *encoder,
-struct intel_crtc_state *pipe_config,
-struct drm_connector_state *conn_state)
+static int intel_crt_compute_config(struct intel_encoder *encoder,
+   struct intel_crtc_state *pipe_config,
+   struct drm_connector_state *conn_state)
 {
struct drm_display_mode *adjusted_mode =
_config->base.adjusted_mode;
 
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
-   return false;
+   return -EINVAL;
 
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
-   return true;
+   return 0;
 }
 
-static bool pch_crt_compute_config(struct intel_encoder *encoder,
-  struct intel_crtc_state *pipe_config,
-  struct drm_connector_state *conn_state)
+static int pch_crt_compute_config(struct intel_encoder *encoder,
+ struct intel_crtc_state *pipe_config,
+ struct drm_connector_state *conn_state)
 {
struct drm_display_mode *adjusted_mode =
_config->base.adjusted_mode;
 
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
-   return false;
+   return -EINVAL;
 
pipe_config->has_pch_encoder = true;
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
 
-   return true;
+   return 0;
 }
 
-static bool hsw_crt_compute_config(struct intel_encoder *encoder,
-  struct intel_crtc_state *pipe_config,
-  struct drm_connector_state 

Re: [PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb

[David Lechner]

On 1/11/19 2:12 PM, Noralf Trønnes wrote:

This switches to drm_atomic_helper_dirtyfb() as the framebuffer dirty
handler. All flushing will now happen in the pipe functions.

Also enable the damage plane property for all except repaper which can
only do full updates.

ili9225:
This change made ili9225_init() equal to mipi_dbi_init() so use it.

v2: Remove fb check in mipi_dbi_enable_flush() it can't be NULL
 (kbuild test robot)

Cc: David Lechner 
Cc: Eric Anholt 
Signed-off-by: Noralf Trønnes 
Acked-by: Sam Ravnborg 
Acked-by: Daniel Vetter 
---



...


diff --git a/drivers/gpu/drm/tinydrm/st7586.c b/drivers/gpu/drm/tinydrm/st7586.c
index a52bc3b02606..50e370ce5a59 100644
--- a/drivers/gpu/drm/tinydrm/st7586.c
+++ b/drivers/gpu/drm/tinydrm/st7586.c
@@ -17,6 +17,7 @@
  #include 
  #include 
  
+#include 

  #include 
  #include 
  #include 
@@ -112,23 +113,15 @@ static int st7586_buf_copy(void *dst, struct 
drm_framebuffer *fb,
return ret;
  }
  
-static int st7586_fb_dirty(struct drm_framebuffer *fb,

-  struct drm_file *file_priv, unsigned int flags,
-  unsigned int color, struct drm_clip_rect *clips,
-  unsigned int num_clips)
+static void st7586_fb_dirty(struct drm_framebuffer *fb, struct drm_rect *rect)
  {
struct tinydrm_device *tdev = fb->dev->dev_private;
struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
-   struct drm_rect clip;
-   struct drm_rect *rect = 


This function later modifies the fields of the struct pointed to by rect.
Are all callers of this function OK with having it modified or should we
make a local copy of rect and modify that instead?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3 v2] drm: rcar-du: add missing of_node_put

[Kieran Bingham]

Hi Julia,

On 14/01/2019 16:44, Julia Lawall wrote:
> Add an of_node_put when the result of of_graph_get_remote_port_parent is
> not available.
> 
> Add a second of_node_put if no encoder is selected (encoder remains NULL).
> 
> The semantic match that finds the first problem is as follows
> (http://coccinelle.lip6.fr):
> 
> // 
> @r exists@
> local idexpression e;
> expression x;
> @@
> e = of_graph_get_remote_port_parent(...);
> ... when != x = e
> when != true e == NULL
> when != of_node_put(e)
> when != of_fwnode_handle(e)
> (
> return e;
> |
> *return ...;
> )
> // 
> 
> Signed-off-by: Julia Lawall 

Thankyou for the update.

Reviewed-by: Kieran Bingham 


> 
> ---
> v2: Add the second of_node_put(entity);, as suggested by Kieran Bingham.
> 
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c |2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 9c7007d..f9a90ff 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -331,6 +331,7 @@ static int rcar_du_encoders_init_one(struct 
> rcar_du_device *rcdu,
>   dev_dbg(rcdu->dev,
>   "connected entity %pOF is disabled, skipping\n",
>   entity);
> + of_node_put(entity);
>   return -ENODEV;
>   }
> 
> @@ -366,6 +367,7 @@ static int rcar_du_encoders_init_one(struct 
> rcar_du_device *rcdu,
>   dev_warn(rcdu->dev,
>"no encoder found for endpoint %pOF, skipping\n",
>ep->local_node);
> + of_node_put(entity);
>   return -ENODEV;
>   }
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb

[David Lechner]

On 1/14/19 10:13 AM, Noralf Trønnes wrote:


I see that you have this call chain:
st7586_pipe_enable() -> mipi_dbi_enable_flush() -> mipi_dbi_fb_dirty().

That doesn't look safe. The st7586 driver allocates a tx_buf with size:
size_t bufsize = (mode->vdisplay + 2) / 3 * mode->hdisplay;

whereas mipi_dbi_enable_flush() will trigger a copy to tx_buf with len:
fb->width * fb->height * 2

It looks like you're writing zeroes way past the end of the buffer.

Noralf.



Thanks! That does indeed seem to be the problem. I'll put together
a patch to fix this. I'm thinking it will be easier to make the
fix before applying this series so that it will be easier to
backport.

FWIW, here is the change I made on top of this series.

diff --git a/drivers/gpu/drm/tinydrm/st7586.c b/drivers/gpu/drm/tinydrm/st7586.c
index 50e370ce5a59..a6cad8f1d2c9 100644
--- a/drivers/gpu/drm/tinydrm/st7586.c
+++ b/drivers/gpu/drm/tinydrm/st7586.c
@@ -176,6 +176,12 @@ static void st7586_pipe_enable(struct 
drm_simple_display_pipe *pipe,
 {
struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
+   struct drm_rect rect = {
+   .x1 = 0,
+   .x2 = plane_state->fb->width,
+   .y1 = 0,
+   .y2 = plane_state->fb->height,
+   };
int ret;
u8 addr_mode;

@@ -234,7 +240,7 @@ static void st7586_pipe_enable(struct 
drm_simple_display_pipe *pipe,

mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_ON);

-   mipi_dbi_enable_flush(mipi, crtc_state, plane_state);
+   st7586_fb_dirty(plane_state->fb, );
 }

 static void st7586_pipe_disable(struct drm_simple_display_pipe *pipe)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109359] Flickering and artifacts on dual 4K displays from RX 570

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109359

Alex Deucher  changed:

   What|Removed |Added

 CC||harry.wentl...@amd.com,
   ||sunpeng...@amd.com

--- Comment #1 from Alex Deucher  ---
Please attach your dmesg output and xorg log (if using X).

-- 
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 109234] amdgpu random hangs with 5.0-rc2/4.21+

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109234

--- Comment #18 from bmil...@gmail.com ---
(In reply to Sibren Vasse from comment #17)
> @bmilreu: Could you try this patch? It works for me.
> https://lists.linuxfoundation.org/pipermail/iommu/2019-January/032651.html

Sure, will report if it fixes it for me.

-- 
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 109359] Flickering and artifacts on dual 4K displays from RX 570

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109359

Bug ID: 109359
   Summary: Flickering and artifacts on dual 4K displays from RX
570
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ven...@msn.com

There are two Dell U2718Q 4K monitors connected to a Sapphire Pulse RX 570 ITX
card, one using the DisplayPort output and the other using the HDMI output.

There is a visible flickering artifact on both displays. There is no problem
when only a single display is connected.

Searching online yields a couple of results that suggest a workaround: manually
increasing the shader and/or memory clock of the GPU. On the RX 570 the
following commands can get rid of the problem:

echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level
echo "2" > /sys/class/drm/card0/device/pp_dpm_mclk
echo "5 6 7" > /sys/class/drm/card0/device/pp_dpm_sclk

However, I believe the amdgpu driver should be able to figure out the correct
necessary clock settings on its own. The problem exists in Linux 4.19 and
5.0-rc1 as well.

-- 
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 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #95 from Brandon Wright  ---
(In reply to Michel Dänzer from comment #94)
> (In reply to tempel.julian from comment #88)
> > (TearFree however doesn't work well in general without amdgpu.dc=1).
> 
> Can you elaborate on that? Maybe file another report on it.

For me, at least, it hiccups regularly every second and introduces noticeable
latency. With dc=1 it's smooth and more responsive.

-- 
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 202261] general protection fault: 0000 [#1] PREEMPT SMP Workqueue: events ttm_bo_delayed_workqueue

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=202261

--- Comment #4 from Johannes Hirte (johannes.hi...@datenkhaos.de) ---
(In reply to Michel Dänzer from comment #3)
> Looks like https://bugs.freedesktop.org/109234 =>
> https://lists.freedesktop.org/archives/dri-devel/2019-January/202909.html
> and follow-ups.

Yes, looks like it's this bug.

From https://lists.linuxfoundation.org/pipermail/iommu/2019-January/032651.html

> Hmm, I wonder if we are not actually using swiotlb in the end,
> can you check if your dmesg contains this line or not?
>
> PCI-DMA: Using software bounce buffering for IO (SWIOTLB)

No, it isn't. I can't find anything about SWIOTLB or PCI-DMA in dmesg.

Just testing the patch. I don't have a reproducer, but it could be
suspend/resume related.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109135] R9 390 hangs at boot with DPM/DC enabled for kernels 4.19.x and above, says KMS not supported

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109135

--- Comment #19 from rmuncr...@humanavance.com ---
Oh, I see. I wasn't aware of the change. I wondered in the beginning if things
were different because I knew the explicit dc and dpm settings were a temporary
work around, but unfortunately I didn't come across any explicit notices about
whether or not they were still used.

In any case, I'd tried both setting amdgpu.dpm=0 and omitting it completely and
that's when I discovered I could boot without it (if I remember correctly I
believe it wouldn't boot with dpm=0 either). However the problem is that my
computer doesn't resume from suspend with any kernels from 4.19.x on so I
assumed display power management wasn't enabled. But if I understand you
correctly it seems it's enabled but not working with resume for some reason.

And by the way, thank you for working on this problem so diligently with me.
I've had a lot of problems with my beloved R9 390 and it's nice to see it
getting the attention it deserves! :)

-- 
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] qcom-scm: Include header

[Fabio Estevam]

Hi Chris,

On Mon, Jan 14, 2019 at 5:54 PM Chris Healy  wrote:
>
> Perhaps I am confused but it appears that this patch has already
> landed upstream and got included in 5.0-rc2:

The patch that Amit is referring is the following entry in MAINTAINERS file:

+F: include/linux/qcom*

so that the proper lists can be put on Cc on future changes of this file.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109234] amdgpu random hangs with 5.0-rc2/4.21+

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109234

--- Comment #17 from Sibren Vasse  ---
@bmilreu: Could you try this patch? It works for me.
https://lists.linuxfoundation.org/pipermail/iommu/2019-January/032651.html

-- 
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: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM

[Koenig, Christian]

Am 14.01.19 um 20:13 schrieb Will Deacon:
> On Mon, Jan 14, 2019 at 07:07:54PM +, Koenig, Christian wrote:
>> Am 14.01.19 um 18:32 schrieb Ard Biesheuvel:
>>  - The reason remapping the CPU side as cacheable does work 
>> (which I
>>  did test) is because the GPU's uncacheable accesses (which I 
>> assume
>>  are made using the NoSnoop PCIe transaction attribute) are 
>> actually
>>  emitted as cacheable in some cases.
>> . On my AMD Seattle, with or without SMMU (which is stage 2 
>> only), I
>>  must use cacheable accesses from the CPU side or things are 
>> broken.
>>  This might be a h/w flaw, though.
>> . On systems with stage 1+2 SMMUs, the driver uses stage 1
>>  translations which always override the memory attributes to 
>> cacheable
>>  for DMA coherent devices. This is what is affecting the Cavium
>>  ThunderX2 (although it appears the attributes emitted by the RC 
>> may be
>>  incorrect as well.)
>>
>>  The latter issue is a shortcoming in the SMMU driver that we 
>> have to
>>  fix, i.e., it should take care not to modify the incoming 
>> attributes
>>  of DMA coherent PCIe devices for NoSnoop to be able to work.
>>
>>  So in summary, the mismatch appears to be between the CPU 
>> accessing
>>  the vmap region with non-cacheable attributes and the GPU 
>> accessing
>>  the same memory with cacheable attributes, resulting in a loss 
>> of
>>  coherency and lots of visible corruption.
>>
>>  Actually it is the other way around. The CPU thinks some data is in 
>> the
>>  cache and the GPU only updates the system memory version because the
>>  snoop flag is not set.
>>
>>
>>  That doesn't seem to be what is happening. As far as we can tell from
>>  our experiments, all inbound transactions are always cacheable, and so
>>  the only way to make things work is to ensure that the CPU uses the
>>  same attributes.
>>
>>
>> Ok that doesn't make any sense. If inbound transactions are cacheable or not 
>> is
>> irrelevant when the CPU always uses uncached accesses.
>>
>> See on the PCIe side you have the snoop bit in the read/write transactions
>> which tells the root hub if the device wants to snoop caches or not.
>>
>> When the CPU accesses some memory as cached then devices need to snoop the
>> cache for coherent accesses.
>>
>> When the CPU accesses some memory as uncached then devices can disable 
>> snooping
>> to improve performance, but when they don't do this it is mandated by the 
>> spec
>> that this still works.
> Which spec?

The PCIe spec. The snoop bit (or rather the NoSnoop) in the transaction 
is perfectly optional IIRC.

> The Arm architecture (and others including Power afaiu) doesn't
> guarantee coherency when memory is accessed using mismatched cacheability
> attributes.

Well what exactly goes wrong on ARM?

As far as I know Power doesn't really supports un-cached memory at all, 
except for a very very old and odd configuration with AGP.

I mean in theory I agree that devices should use matching cacheability 
attributes, but in practice I know of quite a bunch of devices/engines 
which fails to do this correctly.

Regards,
Christian.

>
> Will

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109135] R9 390 hangs at boot with DPM/DC enabled for kernels 4.19.x and above, says KMS not supported

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109135

--- Comment #18 from Alex Deucher  ---
(In reply to rmuncrief from comment #17)
> Yes, As I said in the beginning if you don't set amdgpu.dpm=1 the system
> boots but resume doesn't work. I presume it's because power management isn't
> working. All kernels before 4.19.x work great, and have no problem with
> resume so long as dpm is enabled.

dynamic power management is always enabled by default.  the only way to disable
it is to set dpm=0.  dpm=1 either does nothing or changes the implementation
used in the driver depending on the asic.  You shouldn't set dpm= unless you
are debugging something. For your asic, kernels 4.18 and older the default was
the original dpm implementation; setting dpm=1 used the newer powerplay code. 
For kernel 4.19 and newer, the default implementation switched to the newer
powerplay code and setting dpm=1 switched back to the older implementation.  So
removing dpm=1 is correct for 4.19 and newer.  Can you elaborate on the resume
issue?

-- 
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: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM

[Koenig, Christian]

Am 14.01.19 um 18:32 schrieb Ard Biesheuvel:
[SNIP]

- The existence of a linear region mapping with mismatched attributes
is likely not the culprit here. (We do something similar with
non-cache coherent DMA in other places).



This is still rather problematic.

The issue is that we often don't create a vmap for a page, but rather
access the page directly using the linear mapping.

So we would use the wrong access type here.




Yes. But how are these accesses done? Are they wrapped in a kmap()?

I just double checked the source for this and it should actually be handled 
gracefully:

if 
(num_pages == 1 && 
(mem->placement
 & 
TTM_PL_FLAG_CACHED))
 {
/*
 * We're mapping a single page, and the desired
 * page protection is consistent with the bo.
 */


map->bo_kmap_type = 
ttm_bo_map_kmap;
map->page 
= ttm->pages[start_page];

map->virtual = 
kmap(map->page);
} else {
/*
 * We need to use vmap to get the desired page protection
 * or to make the buffer object look contiguous.
 */
prot = 
ttm_io_prot(mem->placement,
 PAGE_KERNEL);

map->bo_kmap_type = 
ttm_bo_map_vmap;

map->virtual = 
vmap(ttm->pages
 + start_page, 
num_pages,
0, prot);
}

We check the placement flags and only directly use kmap when it is cached. 
Otherwise we fallback to using vmap. So that should indeed work correctly.


- The reason remapping the CPU side as cacheable does work (which I
did test) is because the GPU's uncacheable accesses (which I assume
are made using the NoSnoop PCIe transaction attribute) are actually
emitted as cacheable in some cases.
   . On my AMD Seattle, with or without SMMU (which is stage 2 only), I
must use cacheable accesses from the CPU side or things are broken.
This might be a h/w flaw, though.
   . On systems with stage 1+2 SMMUs, the driver uses stage 1
translations which always override the memory attributes to cacheable
for DMA coherent devices. This is what is affecting the Cavium
ThunderX2 (although it appears the attributes emitted by the RC may be
incorrect as well.)

The latter issue is a shortcoming in the SMMU driver that we have to
fix, i.e., it should take care not to modify the incoming attributes
of DMA coherent PCIe devices for NoSnoop to be able to work.

So in summary, the mismatch appears to be between the CPU accessing
the vmap region with non-cacheable attributes and the GPU accessing
the same memory with cacheable attributes, resulting in a loss of
coherency and lots of visible corruption.



Actually it is the other way around. The CPU thinks some data is in the
cache and the GPU only updates the system memory version because the
snoop flag is not set.




That doesn't seem to be what is happening. As far as we can tell from
our experiments, all inbound transactions are always cacheable, and so
the only way to make things work is to ensure that the CPU uses the
same attributes.

Ok that doesn't make any sense. If inbound transactions are cacheable or not is 
irrelevant when the CPU always uses uncached accesses.

See on the PCIe side you have the snoop bit in the read/write transactions 
which tells the root hub if the device wants to snoop caches or not.

When the CPU accesses some memory as cached then devices need to snoop the 
cache for coherent accesses.

When the CPU accesses some memory as uncached then devices can disable snooping 
to improve performance, but when they don't do this it is mandated by the spec 
that this still works.


To be able to debug this further, could you elaborate a bit on
- How does the hardware 

[PULL] drm-intel-next

[Rodrigo Vivi]

Hi Dave and Daniel,

Here goes first pull request targeting 5.1
made out of 2 tags:

drm-intel-next-2019-01-10:

- Unwind failure on pinning the gen7 PPGTT (Chris)
- Fastset updates to make sure DRRS and PSR are properly enabled (Hans)
- Header include clean-up (Brajeswar, Jani)
- Improvements and clean-up on debugfs (Chris, Jani)
- Avoid division by zero on CNL clocks setup (Xiao)
- Restrict PSMI context load w/a to Haswell GT1 (Chris)
- Remove HW semaphores for gen7 inter-engine sync (Chris)
- Pull the render flush into breadcrumb emission (Chris)
- i915_params copy and free helpers and other reorgs and docs (Jani)
- Remove has_pooled_eu static initializer (Tvrtko)
- Updates on kerneldoc (Chris)
- Remove redundant trailing request flush (Chris)
- ringbuffer irq seqno fixes and clean-up (Chris)
- splitting off runtime device info and other clean-up around (Jani)
- Selftests improvements (Chris, Daniele)
- Flush RING_IMR changes before changing the global GT IMR on gen6 and HSW 
(Chris)
- Some improvements and fixes around GPU reset and GPU hang report (Chris)
- Remove partial attempt to swizzle on pread/pwrite (Chris)
- Return immediately if trylock fails for direct-reclaim (Chris)
- Downgrade scare message for unknown HuC firmware (Jani)
- ACPI / PMIC for MIPI / DSI (Hans)
- Reduce i915_request_alloc retirement to local context (Chris)
- Init per-engine WAs for all engines (Daniele)
- drop DPF code for gen8+ (Daniele)
- Guard error capture against unpinned vma (Chris)
- Use mutex_lock_killable from inside the shrinker (Chris)
- Removing pooling from struct_mutex from vmap shrinker (Chris)

drm-intel-next-2018-12-21-1:

- Selftests fixes and improvements (Chris, Tvrtko)
- PSR/PSR2 fixes and improvements (Jose)
- Makefile style fixes (Pedro)
- Implement Vesa's DP Extended Receiver Capability field (Matt Atwood)
- Allow FBC with 5k on newer displays gen10+ (Jose)
- HDCP-1.4 fixes and improvements (Ram)
- Move Render ring mmio init workaround to new common wa_list (Chris)
- Execlist: Apply a full mb before execution for Braswell (Chris)
- Forcibly evict stale csb entries on ICL (Mika)
- Push EMIT_INVALIDATE at request start to backends (Chris)
- EMIT_INVALIDATE after switch context (Chris)
- Pipeline PDP updates for Braswell (chris)
- Skip the ERR_PTR error state (Chris)
- Flush GPU relocs harder for gen3 (Chris)
- Watermark fixes and improvements (Ville, Matt Roper, Paulo)
- Use intel_ types more consistently (Matt Roper)
- Fix HDMI SCDC scrambling enable for CTS (Clint)
- Expand DFSM pipe disable to gen >= 9 (Bob)
- IS_GEN/IS_GEN_RANGE reorg and improvements (Lucas)
- Ice Lake VDBoxes (Oscar/Chris)
- DSC per connector debugfs node and fix (Manasi)
- HuC updated version for Broxton (Anusha)
- Update crtc scaler settings when needed for gen9+ (Hans)
- Ice Lake vswing programming changes for combo ports (Clint)
- Apply missed interrupt after reset w/a to all ringbuffer gen (Chris)
- Ice Lake fixes for TypeC and Thunderbolt (Imre)

Thanks,
Rodrigo.

The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c:

  Linux 5.0-rc1 (2019-01-06 17:08:20 -0800)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2019-01-10

for you to fetch changes up to 74256b7ecf7790de78ea14facfc9dac02afcc76a:

  drm/i915: Update DRIVER_DATE to 20190110 (2019-01-10 15:18:57 -0800)


- Unwind failure on pinning the gen7 PPGTT (Chris)
- Fastset updates to make sure DRRS and PSR are properly enabled (Hans)
- Header include clean-up (Brajeswar, Jani)
- Improvements and clean-up on debugfs (Chris, Jani)
- Avoid division by zero on CNL clocks setup (Xiao)
- Restrict PSMI context load w/a to Haswell GT1 (Chris)
- Remove HW semaphores for gen7 inter-engine sync (Chris)
- Pull the render flush into breadcrumb emission (Chris)
- i915_params copy and free helpers and other reorgs and docs (Jani)
- Remove has_pooled_eu static initializer (Tvrtko)
- Updates on kerneldoc (Chris)
- Remove redundant trailing request flush (Chris)
- ringbuffer irq seqno fixes and clean-up (Chris)
- splitting off runtime device info and other clean-up around (Jani)
- Selftests improvements (Chris, Daniele)
- Flush RING_IMR changes before changing the global GT IMR on gen6 and HSW 
(Chris)
- Some improvements and fixes around GPU reset and GPU hang report (Chris)
- Remove partial attempt to swizzle on pread/pwrite (Chris)
- Return immediately if trylock fails for direct-reclaim (Chris)
- Downgrade scare message for unknown HuC firmware (Jani)
- ACPI / PMIC for MIPI / DSI (Hans)
- Reduce i915_request_alloc retirement to local context (Chris)
- Init per-engine WAs for all engines (Daniele)
- drop DPF code for gen8+ (Daniele)
- Guard error capture against unpinned vma (Chris)
- Use mutex_lock_killable from inside the shrinker (Chris)
- Removing pooling from struct_mutex from vmap shrinker (Chris)

Re: amdgpu/TTM oopses since merging swiotlb_dma_ops into the dma_direct code

[Christoph Hellwig]

Hmm, I wonder if we are not actually using swiotlb in the end,
can you check if your dmesg contains this line or not?

PCI-DMA: Using software bounce buffering for IO (SWIOTLB)

If not I guess we found a bug in swiotlb exit vs is_swiotlb_buffer,
and you can try this patch:

diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index d6361776dc5c..1fb6fd68b9c7 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -378,6 +378,8 @@ void __init swiotlb_exit(void)
memblock_free_late(io_tlb_start,
   PAGE_ALIGN(io_tlb_nslabs << IO_TLB_SHIFT));
}
+   io_tlb_start = 0;
+   io_tlb_end = 0;
io_tlb_nslabs = 0;
max_segment = 0;
 }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3 v2] drm: rcar-du: add missing of_node_put

[Laurent Pinchart]

Hi Julia,

Thank you for the patch.

On Monday, 14 January 2019 18:44:56 EET Julia Lawall wrote:
> Add an of_node_put when the result of of_graph_get_remote_port_parent is
> not available.
> 
> Add a second of_node_put if no encoder is selected (encoder remains NULL).
> 
> The semantic match that finds the first problem is as follows
> (http://coccinelle.lip6.fr):
> 
> // 
> @r exists@
> local idexpression e;
> expression x;
> @@
> e = of_graph_get_remote_port_parent(...);
> ... when != x = e
> when != true e == NULL
> when != of_node_put(e)
> when != of_fwnode_handle(e)
> (
> return e;
> 
> *return ...;
> )
> // 
> 
> Signed-off-by: Julia Lawall 

Reviewed-by: Laurent Pinchart 

and applied to my tree.

> ---
> v2: Add the second of_node_put(entity);, as suggested by Kieran Bingham.
> 
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c |2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 9c7007d..f9a90ff 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -331,6 +331,7 @@ static int rcar_du_encoders_init_one(struct
> rcar_du_device *rcdu, dev_dbg(rcdu->dev,
>   "connected entity %pOF is disabled, skipping\n",
>   entity);
> + of_node_put(entity);
>   return -ENODEV;
>   }
> 
> @@ -366,6 +367,7 @@ static int rcar_du_encoders_init_one(struct
> rcar_du_device *rcdu, dev_warn(rcdu->dev,
>"no encoder found for endpoint %pOF, skipping\n",
>ep->local_node);
> + of_node_put(entity);
>   return -ENODEV;
>   }

-- 
Regards,

Laurent Pinchart



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: amdgpu/TTM oopses since merging swiotlb_dma_ops into the dma_direct code

[Christoph Hellwig]

On Thu, Jan 10, 2019 at 06:52:26PM +0100, Sibren Vasse wrote:
> On Thu, 10 Jan 2019 at 15:48, Christoph Hellwig  wrote:
> >
> > On Thu, Jan 10, 2019 at 03:00:31PM +0100, Christian König wrote:
> > >>  From the trace it looks like we git the case where swiotlb tries
> > >> to copy back data from a bounce buffer, but hits a dangling or NULL
> > >> pointer.  So a couple questions for the submitter:
> > >>
> > >>   - does the system have more than 4GB memory and thus use swiotlb?
> > >> (check /proc/meminfo, and if something SWIOTLB appears in dmesg)
> > >>   - does the device this happens on have a DMA mask smaller than
> > >> the available memory, that is should swiotlb be used here to start
> > >> with?
> > >
> > > Rather unlikely. The device is an AMD GPU, so we can address memory up to
> > > 1TB.
> >
> > So we probably somehow got a false positive.
> >
> > For now I'like the reported to confirm that the dma_direct_unmap_page+0x92
> > backtrace really is in the swiotlb code (I can't think of anything else,
> > but I'd rather be sure).
> I'm not sure what you want me to confirm. Could you elaborate?

Please open the vmlinux file for which this happend in gdb,
then send the output from this command

l *(dma_direct_unmap_page+0x92)

to this thread.

> > Second it would be great to print what the contents of io_tlb_start
> > and io_tlb_end are, e.g. by doing a printk_once in is_swiotlb_buffer,
> > maybe that gives a clue why we are hitting the swiotlb code here.
> 
> diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
> index 7c007ed7505f..042246dbae00 100644
> --- a/include/linux/swiotlb.h
> +++ b/include/linux/swiotlb.h
> @@ -69,6 +69,7 @@ extern phys_addr_t io_tlb_start, io_tlb_end;
> 
>  static inline bool is_swiotlb_buffer(phys_addr_t paddr)
>  {
> +printk_once(KERN_INFO "io_tlb_start: %llu, io_tlb_end: %llu",
> io_tlb_start, io_tlb_end);
>  return paddr >= io_tlb_start && paddr < io_tlb_end;
>  }
> 
> Result on boot:
> [   11.405558] io_tlb_start: 3782983680, io_tlb_end: 3850092544

So this is a normal swiotlb location, and it does defintively exist.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v1 1/1] drm: fix alpha build after drm_util.h change

[Sam Ravnborg]

0-DAY reported the following bug:

tree:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head:   21376e2c3c5bad5e87ba700c055c8a8235c2bfd5
commit: e9eafcb589213395232084a2378e2e90f67feb29 [1/2] drm: move 
drm_can_sleep() to drm_util.h
config: alpha-allmodconfig (attached as .config)
...
   In file included from include/linux/irqflags.h:16:0,
from include/drm/drm_util.h:35,
from drivers/gpu/drm/qxl/qxl_cmd.c:28:
>> arch/alpha/include/asm/irqflags.h:58:15: error: unknown type name 'bool'
static inline bool arch_irqs_disabled_flags(unsigned long flags)
  ^~~~
...

So we have a situation where we do not pull in 
when building for alpha.

An quick grep shows that roughly half of the declarations of
arch_irqs_disabled_flags() uses int as return type, the other half bool.

Two invasive fixes where considered:
- Change all declarations of arch_irqs_disabled_flags() to use bool
- Add include of  to all files that uses bool for
  arch_irqs_disabled_flags

To invases with a too high pain/benefit ratio, so dropped.

Some less invasive fixes was also considered:
- Add include of  to irqflags.h
- Add include of  to qxl_cmd.c
- Add include of  to drm_util.h

The first was dropped as irqflags.h did not use bool, so no need for the
types.h header file.

The latter was considered the best option as there could
be other similar cases and we would like the header files below
include/drm/ to be selfcontained.

It turns out that using the standard alphabetical order did not work
well as we then included irqflags.h before types.h.
It was considered just to pull in interrupt.h but that would
pull in a lot of unused stuff.
So in the end types.h was included with a comment that it must be first.

Build tested with alpha allmodconfig.

Fixes: 733748ac37b45 ("drm: move drm_can_sleep() to drm_util.h")
Signed-off-by: Sam Ravnborg 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 include/drm/drm_util.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/drm/drm_util.h b/include/drm/drm_util.h
index 0500da65b1d1..0f550bc91db1 100644
--- a/include/drm/drm_util.h
+++ b/include/drm/drm_util.h
@@ -32,6 +32,8 @@
  * Macros and inline functions that does not naturally belong in other places
  */
 
+#include   /* Due to header dependencies this must be first */
+
 #include 
 #include 
 #include 
-- 
2.12.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109135] R9 390 hangs at boot with DPM/DC enabled for kernels 4.19.x and above, says KMS not supported

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=109135

--- Comment #17 from rmuncr...@humanavance.com ---
Yes, As I said in the beginning if you don't set amdgpu.dpm=1 the system boots
but resume doesn't work. I presume it's because power management isn't working.
All kernels before 4.19.x work great, and have no problem with resume so long
as dpm is enabled.

-- 
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 108854] [polaris11] - Failed GPU reset after hang

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108854

--- Comment #10 from Tom Seewald  ---
Created attachment 143113
  --> https://bugs.freedesktop.org/attachment.cgi?id=143113=edit
dmesg with xorg 1.20, kernel 5.0-rc2

-- 
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 108854] [polaris11] - Failed GPU reset after hang

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108854

--- Comment #9 from Tom Seewald  ---
I temporarily upgraded to Xorg 1.20, and the issue still occurs.

-- 
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: amdgpu/TTM oopses since merging swiotlb_dma_ops into the dma_direct code

[Michel Dänzer]

On 2019-01-10 3:48 p.m., Christoph Hellwig wrote:
> On Thu, Jan 10, 2019 at 03:00:31PM +0100, Christian König wrote:
>>>  From the trace it looks like we git the case where swiotlb tries
>>> to copy back data from a bounce buffer, but hits a dangling or NULL
>>> pointer.  So a couple questions for the submitter:
>>>
>>>   - does the system have more than 4GB memory and thus use swiotlb?
>>> (check /proc/meminfo, and if something SWIOTLB appears in dmesg)
>>>   - does the device this happens on have a DMA mask smaller than
>>> the available memory, that is should swiotlb be used here to start
>>> with?
>>
>> Rather unlikely. The device is an AMD GPU, so we can address memory up to 
>> 1TB.
> 
> So we probably somehow got a false positive.
> 
> For now I'like the reported to confirm that the dma_direct_unmap_page+0x92
> backtrace really is in the swiotlb code (I can't think of anything else,
> but I'd rather be sure).
> 
> Second it would be great to print what the contents of io_tlb_start
> and io_tlb_end are, e.g. by doing a printk_once in is_swiotlb_buffer,
> maybe that gives a clue why we are hitting the swiotlb code here.

Any progress? https://bugzilla.kernel.org/show_bug.cgi?id=202261 was
also filed about this.

I hope everyone's clear that this needs to be resolved one way or
another by 5.0 final (though the sooner, the better :).


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 202261] general protection fault: 0000 [#1] PREEMPT SMP Workqueue: events ttm_bo_delayed_workqueue

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=202261

Michel Dänzer (mic...@daenzer.net) changed:

   What|Removed |Added

 CC||h...@lst.de

--- Comment #3 from Michel Dänzer (mic...@daenzer.net) ---
Looks like https://bugs.freedesktop.org/109234 =>
https://lists.freedesktop.org/archives/dri-devel/2019-January/202909.html and
follow-ups.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 108854] [polaris11] - Failed GPU reset after hang

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108854

--- Comment #8 from Tom Seewald  ---
I've reproduced this issue on amd-staging-drm-next and have attached a UMR wave
and gfx ring dump, along with a new dmesg.  To clarify, this issue also
prevents me from rebooting/shutting down my computer, and I am forced to hold
the power button.

Here are the version strings of the relevant software I'm running:

Kernel: amd-staging-drm-next (commit: d2d07f246b126b23d02af0603b83866a3c3e2483)
Mesa: 18.3.1
Xorg: 1.19.6
UMR: 016bc2e93af2cac7a9bd790f7fcacb1ffdadc819

This is my first attempt at using UMR to get information about this system
hang.  I'm essentially just copying what Andrey Grodzovsky suggested in a
previous thread[0].

Here are the umr commands used to gather the information:

Waves dump: umr -i 1 -O verbose,halt_waves -wa

GFX ring dump: umr -i 1 -O verbose,follow -R gfx[.]

GFX info: umr -i 1 -e

I've attached the output of these to the bugzilla report.

[0] https://lists.freedesktop.org/archives/amd-gfx/2018-December/029790.html

-- 
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] drm/fourcc: Add modifier defininitions for AFBC 1.3

[Ayan Halder]

From: Matteo Franchin 

This commit adds definitions of format modifiers for version 1.3 of the
Arm Framebuffer Compression (AFBC).

Signed-off-by: Matteo Franchin 
---
 include/uapi/drm/drm_fourcc.h | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 8dd1328..d6a20d4 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -602,10 +602,18 @@ extern "C" {
  * Indicates the superblock size(s) used for the AFBC buffer. The buffer
  * size (in pixels) must be aligned to a multiple of the superblock size.
  * Four lowest significant bits(LSBs) are reserved for block size.
+ *
+ * Where one superblock size is specified, it applies to all planes of the
+ * buffer (e.g. 16x16, 32x8). When multiple superblock sizes are specified,
+ * the first applies to the Luma plane and the second applies to the Chroma
+ * plane(s). e.g. (32x8_64x4 means 32x8 Luma, with 64x4 Chroma).
+ * Multiple superblock sizes are only valid for multi-plane YCbCr formats.
  */
 #define AFBC_FORMAT_MOD_BLOCK_SIZE_MASK  0xf
 #define AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 (1ULL)
 #define AFBC_FORMAT_MOD_BLOCK_SIZE_32x8  (2ULL)
+#define AFBC_FORMAT_MOD_BLOCK_SIZE_64x4  (3ULL)
+#define AFBC_FORMAT_MOD_BLOCK_SIZE_32x8_64x4 (4ULL)
 
 /*
  * AFBC lossless colorspace transform
@@ -665,6 +673,21 @@ extern "C" {
  */
 #define AFBC_FORMAT_MOD_SC  (1ULL <<  9)
 
+/*
+ * AFBC double-buffer
+ *
+ * Indicates that the buffer is allocated in a layout safe for front-buffer
+ * rendering.
+ */
+#define AFBC_FORMAT_MOD_DB  (1ULL << 10)
+
+/*
+ * AFBC buffer content hints
+ *
+ * Indicates that the buffer includes per-superblock content hints.
+ */
+#define AFBC_FORMAT_MOD_BCH (1ULL << 11)
+
 #if defined(__cplusplus)
 }
 #endif
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 108854] [polaris11] - Failed GPU reset after hang

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108854

--- Comment #7 from Tom Seewald  ---
Created attachment 143110
  --> https://bugs.freedesktop.org/attachment.cgi?id=143110=edit
UMR gpu info

-- 
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 108854] [polaris11] - Failed GPU reset after hang

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108854

--- Comment #6 from Tom Seewald  ---
Created attachment 143109
  --> https://bugs.freedesktop.org/attachment.cgi?id=143109=edit
UMR gfx ring dump as of January 14th 2019

-- 
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 108854] [polaris11] - Failed GPU reset after hang

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108854

--- Comment #5 from Tom Seewald  ---
Created attachment 143108
  --> https://bugs.freedesktop.org/attachment.cgi?id=143108=edit
UMR wave dump as of January 14th 2019

-- 
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 108854] [polaris11] - Failed GPU reset after hang

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108854

--- Comment #4 from Tom Seewald  ---
Created attachment 143107
  --> https://bugs.freedesktop.org/attachment.cgi?id=143107=edit
amd-drm-staging-next dmesg as of January 14th 2019

-- 
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 1/3 v2] drm: rcar-du: add missing of_node_put

[Julia Lawall]

Add an of_node_put when the result of of_graph_get_remote_port_parent is
not available.

Add a second of_node_put if no encoder is selected (encoder remains NULL).

The semantic match that finds the first problem is as follows
(http://coccinelle.lip6.fr):

// 
@r exists@
local idexpression e;
expression x;
@@
e = of_graph_get_remote_port_parent(...);
... when != x = e
when != true e == NULL
when != of_node_put(e)
when != of_fwnode_handle(e)
(
return e;
|
*return ...;
)
// 

Signed-off-by: Julia Lawall 

---
v2: Add the second of_node_put(entity);, as suggested by Kieran Bingham.

 drivers/gpu/drm/rcar-du/rcar_du_kms.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 9c7007d..f9a90ff 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -331,6 +331,7 @@ static int rcar_du_encoders_init_one(struct rcar_du_device 
*rcdu,
dev_dbg(rcdu->dev,
"connected entity %pOF is disabled, skipping\n",
entity);
+   of_node_put(entity);
return -ENODEV;
}

@@ -366,6 +367,7 @@ static int rcar_du_encoders_init_one(struct rcar_du_device 
*rcdu,
dev_warn(rcdu->dev,
 "no encoder found for endpoint %pOF, skipping\n",
 ep->local_node);
+   of_node_put(entity);
return -ENODEV;
}

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 108592] [CI][DRMTIP] igt@gem_exec_whisper@normal - timeout

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=108592

Martin Peres  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #3 from Martin Peres  ---
(In reply to Chris Wilson from comment #2)
> commit d9cd03c887a5f46bc002280d70a6716bb2bf8d43 (upstream/master,
> origin/master, origin/HEAD)
> Author: Chris Wilson 
> Date:   Mon Jan 14 09:13:54 2019 +
> 
> i915/gem_exec_whisper: Limit to a maximum of 150s
> 
> Each individual pass is as effective at spotting an error using the
> Chinese whisper as any other, so the effectiveness of adding more passes
> rapidly diminishes. To keep the tests bounded within time, limit a
> subtest to a mere 150s!
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108592
> Signed-off-by: Chris Wilson 
> Reviewed-by: Tvrtko Ursulin 

Thanks, it did the trick!

-- 
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 04/10] drm/mxsfb: Update mxsfb with additional pixel formats

[Guido Günther]

Hi,
On Wed, Jan 09, 2019 at 02:13:43PM +, Robert Chiras wrote:
> Since version 4 of eLCDIF, there are some registers that can do
> transformations on the input data, like re-arranging the pixel
> components. By doing that, we can support more pixel formats.
> This patch adds support for X/ABGR and RGBX/A. Although, the local alpha
> is not supported by eLCDIF, the alpha pixel formats were added to the
> supported pixel formats but it will be ignored. This was necessary since
> there are systems (like Android) that requires such pixel formats.
> 
> Signed-off-by: Robert Chiras 
> ---
>  drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 108 
> -
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c  |  27 +++---
>  drivers/gpu/drm/mxsfb/mxsfb_drv.h  |   4 +-
>  drivers/gpu/drm/mxsfb/mxsfb_regs.h | 100 --
>  4 files changed, 169 insertions(+), 70 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c 
> b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> index f0648ce..6aa8804 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> @@ -48,15 +48,35 @@ static u32 set_hsync_pulse_width(struct mxsfb_drm_private 
> *mxsfb, u32 val)
>   mxsfb->devdata->hs_wdth_shift;
>  }
>  
> +/*  Print Four-character-code (FOURCC) */
> +static char *fourcc_to_str(u32 fmt)
> +{
> + /* Use 10 chars so we can simultaneously print two codes */
> + static char code[10], *c = [0];
> +
> + if (c == [10])
> + c = [0];
> +
> + *(c++) = (unsigned char)(fmt & 0xff);
> + *(c++) = (unsigned char)((fmt >> 8) & 0xff);
> + *(c++) = (unsigned char)((fmt >> 16) & 0xff);
> + *(c++) = (unsigned char)((fmt >> 24) & 0xff);
> + *(c++) = '\0';
> +
> + return (c - 5);
> +}
> +
>  /* Setup the MXSFB registers for decoding the pixels out of the framebuffer 
> */
> -static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private *mxsfb)
> +static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private *mxsfb, bool update)
>  {
>   struct drm_crtc *crtc = >pipe.crtc;
>   struct drm_device *drm = crtc->dev;
>   const u32 format = crtc->primary->state->fb->format->format;
> - u32 ctrl, ctrl1;
> + u32 ctrl = 0, ctrl1 = 0;
> + bool bgr_format = true;
>  
> - ctrl = CTRL_BYPASS_COUNT | CTRL_MASTER;
> + if (!update)
> + ctrl = CTRL_BYPASS_COUNT | CTRL_MASTER;
>  
>   /*
>* WARNING: The bus width, CTRL_SET_BUS_WIDTH(), is configured to
> @@ -65,31 +85,69 @@ static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private 
> *mxsfb)
>* to arbitrary value. This limitation should not pose an issue.
>*/
>  
> - /* CTRL1 contains IRQ config and status bits, preserve those. */
> - ctrl1 = readl(mxsfb->base + LCDC_CTRL1);
> - ctrl1 &= CTRL1_CUR_FRAME_DONE_IRQ_EN | CTRL1_CUR_FRAME_DONE_IRQ;
> + if (!update) {
> + /* CTRL1 contains IRQ config and status bits, preserve those. */
> + ctrl1 = readl(mxsfb->base + LCDC_CTRL1);
> + ctrl1 &= CTRL1_CUR_FRAME_DONE_IRQ_EN | CTRL1_CUR_FRAME_DONE_IRQ;
> + }
> +
> + DRM_DEV_DEBUG_DRIVER(drm->dev, "Setting up %s mode\n",
> + fourcc_to_str(format));
> +
> + /* Do some clean-up that we might have from a previous mode */
> + ctrl &= ~CTRL_SHIFT_DIR(1);
> + ctrl &= ~CTRL_SHIFT_NUM(0x3f);
> + if (mxsfb->devdata->ipversion >= 4)
> + writel(CTRL2_ODD_LINE_PATTERN(0x7) |
> +CTRL2_EVEN_LINE_PATTERN(0x7),
> +mxsfb->base + LCDC_V4_CTRL2 + REG_CLR);
>  
>   switch (format) {
>   case DRM_FORMAT_RGB565:
> - dev_dbg(drm->dev, "Setting up RGB565 mode\n");
>   ctrl |= CTRL_SET_WORD_LENGTH(0);
>   ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0xf);
>   break;
> + case DRM_FORMAT_RGBX:
> + case DRM_FORMAT_RGBA:
> + /* RGBX - > 0RGB */
> + ctrl |= CTRL_SHIFT_DIR(1);
> + ctrl |= CTRL_SHIFT_NUM(8);
> + bgr_format = false;
> + /* Fall through */
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_ABGR:
> + if (bgr_format) {
> + if (mxsfb->devdata->ipversion < 4)
> + goto err;
> + writel(CTRL2_ODD_LINE_PATTERN(0x5) |
> +CTRL2_EVEN_LINE_PATTERN(0x5),
> +mxsfb->base + LCDC_V4_CTRL2 + REG_SET);
> + }
> + /* Fall through */
>   case DRM_FORMAT_XRGB:
> - dev_dbg(drm->dev, "Setting up XRGB mode\n");
> + case DRM_FORMAT_ARGB:
>   ctrl |= CTRL_SET_WORD_LENGTH(3);
>   /* Do not use packed pixels = one pixel per word instead. */
>   ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0x7);
>   break;
>   default:
> - dev_err(drm->dev, "Unhandled pixel format %08x\n", format);
> -   

Re: [PATCH 07/10] drm/mxsfb: Signal mode changed when bpp changed

[Guido Günther]

Hi,
On Wed, Jan 09, 2019 at 02:13:47PM +, Robert Chiras wrote:
> From: Mirela Rabulea 
> 
> Add mxsfb_atomic_helper_check to signal mode changed when bpp changed.
> This will trigger the execution of disable/enable on
> a modeset with different bpp than the current one.
> 
> Signed-off-by: Mirela Rabulea 
> ---
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c | 48 
> ++-
>  1 file changed, 47 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c 
> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> index d3fb3a8..f528a37 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> @@ -115,9 +115,55 @@ void mxsfb_disable_axi_clk(struct mxsfb_drm_private 
> *mxsfb)
>   clk_disable_unprepare(mxsfb->clk_axi);
>  }
>  
> +/**
> + * mxsfb_atomic_helper_check - validate state object
> + * @dev: DRM device
> + * @state: the driver state object
> + *
> + * On top of the drm imlementation drm_atomic_helper_check,
> + * check if the bpp is changed, if so, signal mode_changed,
> + * this will trigger disable/enable
> + *
> + * RETURNS:
> + * Zero for success or -errno
> + */
> +static int mxsfb_atomic_helper_check(struct drm_device *dev,
> + struct drm_atomic_state *state)
> +{
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *crtc_state;
> + int i, ret;
> +
> + ret = drm_atomic_helper_check(dev, state);
> + if (ret)
> + return ret;
> +
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {

This does not exist anymore in recent drm, see
9ba29fcb76a559078491adffc74f66bf92b9dbea.
Cheers,
 -- Guido

> + struct drm_plane_state *primary_state;
> + int old_bpp = 0;
> + int new_bpp = 0;
> +
> + if (!crtc->primary || !crtc->primary->old_fb)
> + continue;
> + primary_state =
> + drm_atomic_get_plane_state(state, crtc->primary);
> + if (!primary_state || !primary_state->fb)
> + continue;
> + old_bpp = crtc->primary->old_fb->format->depth;
> + new_bpp = primary_state->fb->format->depth;
> + if (old_bpp != new_bpp) {
> + crtc_state->mode_changed = true;
> + DRM_DEBUG_ATOMIC(
> + "[CRTC:%d:%s] mode changed, bpp %d->%d\n",
> + crtc->base.id, crtc->name, old_bpp, new_bpp);
> + }
> + }
> + return ret;
> +}
> +
>  static const struct drm_mode_config_funcs mxsfb_mode_config_funcs = {
>   .fb_create  = drm_gem_fb_create,
> - .atomic_check   = drm_atomic_helper_check,
> + .atomic_check   = mxsfb_atomic_helper_check,
>   .atomic_commit  = drm_atomic_helper_commit,
>  };
>  
> -- 
> 2.7.4
> 
> ___
> 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

Re: [PATCH v10 1/2] drm/fourcc: Add new P010, P016 video format

[Ayan Halder]

On Thu, Jan 10, 2019 at 03:57:09AM +0800, Randy Li wrote:
> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
> channel video format.
> 
> P012 is a planar 4:2:0 YUV 12 bits per channel
> 
> P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
> channel video format.
> 
> V3: Added P012 and fixed cpp for P010.
> V4: format definition refined per review.
> V5: Format comment block for each new pixel format.
> V6: reversed Cb/Cr order in comments.
> v7: reversed Cb/Cr order in comments of header files, remove
> the wrong part of commit message.
> V8: reversed V7 changes except commit message and rebased.
> v9: used the new properties to describe those format and
> rebased.
> 
> Cc: Daniel Stone 
> Cc: Ville Syrj??l?? 
> 
> Signed-off-by: Randy Li 
> Signed-off-by: Clint Taylor 
> ---
>  drivers/gpu/drm/drm_fourcc.c  |  9 +
>  include/uapi/drm/drm_fourcc.h | 21 +
>  2 files changed, 30 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index d90ee03a84c6..ba7e19d4336c 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -238,6 +238,15 @@ const struct drm_format_info *__drm_format_info(u32 
> format)
>   { .format = DRM_FORMAT_X0L2,.depth = 0,  
> .num_planes = 1,
> .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 }, 
> .block_h = { 2, 0, 0 },
> .hsub = 2, .vsub = 2, .is_yuv = true },
> + { .format = DRM_FORMAT_P010,.depth = 0,  
> .num_planes = 2,
> +   .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 }, 
> .block_h = { 1, 0, 0 },
> +   .hsub = 2, .vsub = 2, .is_yuv = true},
> + { .format = DRM_FORMAT_P012,.depth = 0,  
> .num_planes = 2,
> +   .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 }, 
> .block_h = { 1, 0, 0 },
> +.hsub = 2, .vsub = 2, .is_yuv = true},
> + { .format = DRM_FORMAT_P016,.depth = 0,  
> .num_planes = 2,
> +   .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 }, 
> .block_h = { 1, 0, 0 },
> +   .hsub = 2, .vsub = 2, .is_yuv = true},
>   };
>  
>   unsigned int i;
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 0b44260a5ee9..8dd1328bc8d6 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -195,6 +195,27 @@ extern "C" {
>  #define DRM_FORMAT_NV24  fourcc_code('N', 'V', '2', '4') /* 
> non-subsampled Cr:Cb plane */
>  #define DRM_FORMAT_NV42  fourcc_code('N', 'V', '4', '2') /* 
> non-subsampled Cb:Cr plane */
>  
> +/*
> + * 2 plane YCbCr MSB aligned
> + * index 0 = Y plane, [15:0] Y:x [10:6] little endian
> + * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [10:6:10:6] little endian
> + */
> +#define DRM_FORMAT_P010  fourcc_code('P', '0', '1', '0') /* 2x2 
> subsampled Cr:Cb plane 10 bits per channel */
> +
> +/*
> + * 2 plane YCbCr MSB aligned
> + * index 0 = Y plane, [15:0] Y:x [12:4] little endian
> + * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [12:4:12:4] little endian
> + */
> +#define DRM_FORMAT_P012  fourcc_code('P', '0', '1', '2') /* 2x2 
> subsampled Cr:Cb plane 12 bits per channel */
> +
> +/*
> + * 2 plane YCbCr MSB aligned
> + * index 0 = Y plane, [15:0] Y little endian
> + * index 1 = Cr:Cb plane, [31:0] Cr:Cb [16:16] little endian
> + */
> +#define DRM_FORMAT_P016  fourcc_code('P', '0', '1', '6') /* 2x2 
> subsampled Cr:Cb plane 16 bits per channel */
> +

looks good to me.
Reviewed by:- Ayan Kumar Halder 

We are using P010 format for our mali display driver. Our AFBC patch
series(https://patchwork.freedesktop.org/series/53395/) is dependent
on this patch. So, that's why I wanted to know when you are planning to
merge this. As far as I remember, Juha wanted to implement some igt
tests
(https://lists.freedesktop.org/archives/intel-gfx/2018-September/174877.html)
, so is that done now?

My apologies if I am pushing hard on this.
>  /*
>   * 3 plane YCbCr
>   * index 0: Y plane, [7:0] Y
> -- 
> 2.20.1
> 
> ___
> 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

[PATCH] etnaviv: allow to build on ARC

[Eugeniy Paltsev]

ARC HSDK SoC has Vivante GPU IP so allow build etnaviv for ARC.

Signed-off-by: Eugeniy Paltsev 
---
 drivers/gpu/drm/etnaviv/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig
index 342591a1084e..49a9957c3373 100644
--- a/drivers/gpu/drm/etnaviv/Kconfig
+++ b/drivers/gpu/drm/etnaviv/Kconfig
@@ -2,7 +2,7 @@
 config DRM_ETNAVIV
tristate "ETNAVIV (DRM support for Vivante GPU IP cores)"
depends on DRM
-   depends on ARCH_MXC || ARCH_DOVE || ARM || COMPILE_TEST
+   depends on ARCH_MXC || ARCH_DOVE || ARM || ARC || COMPILE_TEST
depends on MMU
select SHMEM
select SYNC_FILE
-- 
2.14.5

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: stop always moving BOs on the LRU on page fault

[Michel Dänzer]

On 2019-01-11 8:12 p.m., Christian König wrote:
> Am 11.01.19 um 15:17 schrieb Michel Dänzer:
>> On 2019-01-11 2:15 p.m., Christian König wrote:
>>> Move the BO on the LRU only when it is actually moved by a DMA
>>> operation.
>>>
>>> [...]
>>>
>>> @@ -177,6 +175,13 @@ static vm_fault_t ttm_bo_vm_fault(struct
>>> vm_fault *vmf)
>>>   ret = VM_FAULT_SIGBUS;
>>>   goto out_unlock;
>>>   }
>>> +
>>> +    if (bo->moving != moving) {
>> Hmm, could a driver just update the existing fence instead of attaching
>> a new one?
> 
> Mhm, not as far as I know. That would violate similar checks elsewhere.

Makes sense, my R-b stands.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel