Re: [PATCH 09/11] drm/syncobj: add transition iotcls between binary and timeline

[Koenig, Christian]

Am 20.02.19 um 05:53 schrieb zhoucm1:


On 2019年02月19日 19:32, Koenig, Christian wrote:
Hi David,

Could you have a look if it's reasonable?

Patch #1 is also something I already fixed on my local branch.

But patch #2 won't work like this.

We can't return an error from drm_syncobj_add_point() because we already 
submitted work to the hardware. And just dropping the fence like you do in the 
patch is a clearly no-go as well.

Then do you have any idea to skip the messed order signal point?

No, I don't think we can actually do this.

The only solution I can see would be to lock down the syncobj to modifications 
while command submission is in progress. And that in turn would mean a huge 
bunch of ww_mutex overhead we will certainly want to avoid.

Christian.


-David

Regards,
Christian.

Am 19.02.19 um 11:46 schrieb zhoucm1:

Hi Lionel,

the attached should fix your problem and also messed signal order.

Hi Christian,

Could you have a look if it's reasonable?


btw: I pushed to change to 
https://github.com/amingriyue/timeline-syncobj-kernel, which is already rebased 
to latest drm-misc(kernel 5.0). You can directly use that branch.


-David

On 2019年02月19日 01:01, Koenig, Christian wrote:
Am 18.02.19 um 13:07 schrieb Lionel Landwerlin:
Thanks guys :)

You mentioned that signaling out of order is illegal.
Is this illegal with regard to the vulkan spec or to the syncobj implementation?

David is the expert on that, but as far as I know that is forbidden by the 
vulkan spec.

I'm not finding anything in the vulkan spec that makes out of order signaling 
illegal.
That's why I came up with this test, just verifying that the timeline does not 
go backward in term of its payload.

Well we need to handle this case gracefully in the kernel, so it is still a 
good testcase.

Christian.


-Lionel

On 18/02/2019 11:01, Koenig, Christian wrote:
Hi David,

well I think Lionel is testing the invalid signal order on purpose :)

Anyway we really need to handle invalid order graceful here. E.g. either the 
same way as during CS or we abort and return an error message.

I think just using the same approach as during CS ist the best we can do.

Regards,
Christian


Am 18.02.2019 11:35 schrieb "Zhou, David(ChunMing)" 
:

Hi Lionel,

I checked your igt test case,

uint64_t points[5] = { 1, 5, 3, 7, 6 };

which is illegal signal order.

I must admit we should handle it gracefully if signal isn't in-order, and we 
shouldn't lead to deadlock.

Hi Christian,

Can we just ignore when signal point X <= timeline Y? Or just give a warning?

Otherwise like Lionel's unexpected use cases, which easily leads to deadlock.


-David

On 2019年02月15日 22:28, Lionel Landwerlin wrote:

Hi David,

Thanks a lot for point me to the tests you've added in IGT.
While adding a test with that signals fences imported into a timeline
syncobj out of order, I ran into a deadlock.
Here is the test :
https://github.com/djdeath/intel-gpu-tools/commit/1e46cf7e7bff09b78a24367ddc2314f97eb0a1b9

Trying to kill the deadlocked process I got this backtrace :


[   33.969136] [IGT] syncobj_timeline: starting subtest signal-order
[   60.452823] watchdog: BUG: soft lockup - CPU#6 stuck for 23s!
[syncobj_timelin:2021]
[   60.452826] Modules linked in: rfcomm cmac bnep binfmt_misc
nls_iso8859_1 snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_codec_generic ledtrig_audio sch_fq_codel ib_iser snd_hda_intel
rdma_cm iw_cm snd_hda_codec ib_cm snd_hda_core snd_hwdep intel_rapl
snd_pcm ib_core x86_pkg_temp_thermal intel_powerclamp configf
s coretemp iscsi_tcp snd_seq_midi libiscsi_tcp snd_seq_midi_event
libiscsi kvm_intel scsi_transport_iscsi kvm btusb snd_rawmidi irqbypass
btrtl intel_cstate intel_rapl_perf btbcm btintel bluetooth snd_seq
snd_seq_device snd_timer input_leds ecdh_generic snd soundcore mei_me
mei intel_pch_thermal mac_hid acpi_pad parp
ort_pc ppdev lp parport ip_tables x_tables autofs4 btrfs zstd_decompress
zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq
async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear
hid_generic usbhid hid i915 crct10dif_pclmul crc32_pclmul i2c_algo_bit
ghash_clmulni_intel prime_numbers
drm_kms_helper aesni_intel syscopyarea sysfillrect
[   60.452876]  sysimgblt fb_sys_fops aes_x86_64 crypto_simd sdhci_pci
cryptd drm e1000e glue_helper cqhci sdhci wmi video
[   60.452881] CPU: 6 PID: 2021 Comm: syncobj_timelin Tainted: G
U5.0.0-rc5+ #337
[   60.452882] Hardware name:  /NUC6i7KYB, BIOS
KYSKLi70.86A.0042.2016.0929.1933 09/29/2016
[   60.452886] RIP: 0010:dma_fence_chain_walk+0x22c/0x260
[   60.452888] Code: ff e9 93 fe ff ff 48 8b 45 08 48 8b 40 18 48 85 c0
74 0c 48 89 ef e8 33 0f 58 00 84 c0 75 23 f0 41 ff 4d 00 0f 88 99 87 2f
00 <0f> 85 05 fe ff ff 4c 89 ef e8 56 ea ff ff 48 89 d8 5b 5d 41 5c 41
[   60.452888] RSP: 0018:9a5804653ca8 EFLAGS: 00010296 ORIG_RAX:
ff13
[   60.452889] RAX:  RBX: 8f5690fb2480 RCX:
8f5690fb2f00
[  

[PATCH] drm: bridge: dw-hdmi: Fix overflow workaround for Rockchip SoCs

[Jonas Karlman]

The Rockchip RK3288 SoC (v2.00a) and RK3328/RK3399 SoCs (v2.11a) have
also been identified as needing this workaround with a single iteration.

Fixes: be41fc55f1aa ("drm: bridge: dw-hdmi: Handle overflow workaround based on 
device version")
Signed-off-by: Jonas Karlman 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 64c3cf027518..14223c0ee784 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1655,6 +1655,8 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
 * iteration for others.
 * The Amlogic Meson GX SoCs (v2.01a) have been identified as needing
 * the workaround with a single iteration.
+* The Rockchip RK3288 SoC (v2.00a) and RK3328/RK3399 SoCs (v2.11a) have
+* been identified as needing the workaround with a single iteration.
 */
 
switch (hdmi->version) {
@@ -1663,7 +1665,9 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
break;
case 0x131a:
case 0x132a:
+   case 0x200a:
case 0x201a:
+   case 0x211a:
case 0x212a:
count = 1;
break;
-- 
2.17.1

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

RE: [PATCH libdrm] libdrm: Fix issue about differrent domainID but same BDF

[Deng, Emily]

Ping ..

>-Original Message-
>From: amd-gfx  On Behalf Of Deng,
>Emily
>Sent: Monday, February 18, 2019 10:17 AM
>To: Alex Deucher ; Maling list - DRI developers de...@lists.freedesktop.org>
>Cc: amd-gfx list 
>Subject: RE: [PATCH libdrm] libdrm: Fix issue about differrent domainID but 
>same
>BDF
>
>Thanks Alex to help to add the dri-devel.
>
>Best wishes
>Emily Deng
>
>
>>-Original Message-
>>From: Alex Deucher 
>>Sent: Friday, February 15, 2019 11:14 PM
>>To: Deng, Emily ; Maling list - DRI developers
>>
>>Cc: amd-gfx list 
>>Subject: Re: [PATCH libdrm] libdrm: Fix issue about differrent domainID
>>but same BDF
>>
>>Adding dri-devel.
>>
>>On Thu, Feb 14, 2019 at 2:53 AM Emily Deng  wrote:
>>>
>>> For multiple GPUs which has the same BDF, but has different domain
>>> ID, the drmOpenByBusid will return the wrong fd when startx.
>>>
>>> The reproduce sequence as below:
>>> 1. Call drmOpenByBusid to open Card0, then will return the right fd0,
>>> and the
>>> fd0 is master privilege;
>>> 2. Call drmOpenByBusid to open Card1. In function drmOpenByBusid, it
>>> will open Card0 first, this time, the fd1 for opening Card0 is not
>>> master privilege, and will call drmSetInterfaceVersion to identify
>>> the domain ID feature, as the fd1 is not master privilege, then
>>> drmSetInterfaceVersion will fail, and then won't compare domain ID,
>>> then
>>return the wrong fd for Card1.
>>>
>>> Solution:
>>> First loop search the best match fd about drm 1.4.
>>>
>>> Signed-off-by: Emily Deng 
>>> ---
>>>  xf86drm.c | 23 +++
>>>  1 file changed, 23 insertions(+)
>>>
>>> diff --git a/xf86drm.c b/xf86drm.c
>>> index 336d64d..b60e029 100644
>>> --- a/xf86drm.c
>>> +++ b/xf86drm.c
>>> @@ -584,11 +584,34 @@ static int drmOpenByBusid(const char *busid,
>>> int
>>type)
>>>  if (base < 0)
>>>  return -1;
>>>
>>> +/* We need to try for 1.4 first for proper PCI domain support */
>>>  drmMsg("drmOpenByBusid: Searching for BusID %s\n", busid);
>>>  for (i = base; i < base + DRM_MAX_MINOR; i++) {
>>>  fd = drmOpenMinor(i, 1, type);
>>>  drmMsg("drmOpenByBusid: drmOpenMinor returns %d\n", fd);
>>>  if (fd >= 0) {
>>> +sv.drm_di_major = 1;
>>> +sv.drm_di_minor = 4;
>>> +sv.drm_dd_major = -1;/* Don't care */
>>> +sv.drm_dd_minor = -1;/* Don't care */
>>> +if (!drmSetInterfaceVersion(fd, &sv)) {
>>> +buf = drmGetBusid(fd);
>>> +drmMsg("drmOpenByBusid: drmGetBusid reports %s\n", buf);
>>> +if (buf && drmMatchBusID(buf, busid, 1)) {
>>> +drmFreeBusid(buf);
>>> +return fd;
>>> +}
>>> +if (buf)
>>> +drmFreeBusid(buf);
>>> +}
>>> +close(fd);
>>> +}
>>> +}
>>> +
>>> +   for (i = base; i < base + DRM_MAX_MINOR; i++) {
>>> +fd = drmOpenMinor(i, 1, type);
>>> +drmMsg("drmOpenByBusid: drmOpenMinor returns %d\n", fd);
>>> +if (fd >= 0) {
>>>  /* We need to try for 1.4 first for proper PCI domain support
>>>   * and if that fails, we know the kernel is busted
>>>   */
>>> --
>>> 2.7.4
>>>
>>> ___
>>> amd-gfx mailing list
>>> amd-...@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>___
>amd-gfx mailing list
>amd-...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

linux-next: build failure after merge of the akpm-current tree

[Stephen Rothwell]

Hi all,

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

drivers/gpu/drm/nouveau/nouveau_dmem.c:299:11: error: initialization of 
'vm_fault_t (*)(struct hmm_devmem *, struct vm_area_struct *, long unsigned 
int,  const struct page *, unsigned int,  pmd_t *)' {aka 'unsigned int 
(*)(struct hmm_devmem *, struct vm_area_struct *, long unsigned int,  const 
struct page *, unsigned int,  struct  *)'} from incompatible pointer 
type 'int (*)(struct hmm_devmem *, struct vm_area_struct *, long unsigned int,  
const struct page *, unsigned int,  pmd_t *)' {aka 'int (*)(struct hmm_devmem 
*, struct vm_area_struct *, long unsigned int,  const struct page *, unsigned 
int,  struct  *)'} [-Werror=incompatible-pointer-types]
  .fault = nouveau_dmem_fault,
   ^~
drivers/gpu/drm/nouveau/nouveau_dmem.c:299:11: note: (near initialization for 
'nouveau_dmem_devmem_ops.fault')

Caused by commit

  5be73b690875 ("drm/nouveau/dmem: device memory helpers for SVM")

from the drm tree interacting with commit

  ed814eb7f91d ("mm/hmm: convert to use vm_fault_t")

from the akpm-current tree.

I added this merge fix patch:

From: Stephen Rothwell 
Date: Wed, 20 Feb 2019 17:36:18 +1100
Subject: [PATCH] drm/nouveau/dmem: update for struct hmm_devmem_ops member
 change

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

diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c 
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index 8be7a83ced9b..e2539f64de60 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
@@ -261,7 +261,7 @@ static const struct migrate_vma_ops 
nouveau_dmem_fault_migrate_ops = {
.finalize_and_map   = nouveau_dmem_fault_finalize_and_map,
 };
 
-static int
+static vm_fault_t
 nouveau_dmem_fault(struct hmm_devmem *devmem,
   struct vm_area_struct *vma,
   unsigned long addr,
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell


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

Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems

[Thomas Hellstrom]

On Tue, 2019-02-19 at 17:06 +, Kuehling, Felix wrote:
> On 2019-02-18 3:39 p.m., Thomas Hellstrom wrote:
> > On Mon, 2019-02-18 at 18:07 +0100, Christian König wrote:
> > > Am 18.02.19 um 10:47 schrieb Thomas Hellstrom:
> > > > On Mon, 2019-02-18 at 09:20 +, Koenig, Christian wrote:
> > > > > Another good question is also why the heck the acc_size
> > > > > counts
> > > > > towards
> > > > > the DMA32 zone?
> > > > DMA32 TTM pages are accounted in the DMA32 zone. Other pages
> > > > are
> > > > not.
> > > Yeah, I'm perfectly aware of this. But this is for the accounting
> > > size!
> > > 
> > > We have an accounting for the stuff needed additional to the
> > > pages
> > > backing the BO (e.g. the page and DMA addr array).
> > > 
> > > And from the bug description it sounds like we use the DMA32 zone
> > > for
> > > this accounting which of course is completely nonsense.
> > It's actually accounted in all available zones, since it would be
> > pretty hard to determine exactly where that memory should be
> > accounted.
> > In particular if it's vmalloced. It might be DMA32, it might not.
> > Given
> > the objective of stopping malicious user-space from exhausting the
> > DMA32 zone it was, at the time the code was written, a reasonable
> > approximation. With ever increasing memory sizes, there might be
> > better
> > solutions?
> 
> As far as I can see, in TTM, ttm_mem_global_alloc is only used for
> the 
> acc_size in ttm_bo_init_reserved. Other than that vmwgfx also seems
> to 
> use it to account for a few things that are allocated with kmalloc.
> 
> So would a better solution be to change ttm_mem_global_alloc to use
> only 
> the kernel zone?
> 

IMO we need to determine what functionality to keep and then the best
solution. The current code does its job, but is obviously too
restrictive. Both of the solutions you suggest open up for potential
DOS attacks (DMA32 and kernel zones are not mutually exclusive. They
overlap).


/Thomas




> Regards,
>Felix
> 
> 
> > /Thomas
> > 
> > > Christian.
> > > 
> > > > For small persistent allocations using ttm_mem_global_alloc(),
> > > > they
> > > > are
> > > > accounted also in the DMA32 zone, which may cause over-
> > > > accounting
> > > > of
> > > > that zone, but that's pretty unlikely to be a big problem..
> > > > 
> > > > /Thomas
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > > In other words why should the internal bookkeeping pages be
> > > > > allocated
> > > > > in
> > > > > the DMA32 zone?
> > > > > 
> > > > > That doesn't sounds valid to me in any way,
> > > > > Christian.
> > > > > 
> > > > > Am 18.02.19 um 09:02 schrieb Thomas Hellstrom:
> > > > > > Hmm,
> > > > > > 
> > > > > > This zone was intended to stop TTM page allocations from
> > > > > > exhausting
> > > > > > the DMA32 zone. IIRC dma_alloc_coherent() uses DMA32 by
> > > > > > default,
> > > > > > which
> > > > > > means if we drop this check, other devices may stop
> > > > > > functioning
> > > > > > unexpectedly?
> > > > > > 
> > > > > > However, in the end I'd expect the kernel page allocation
> > > > > > system
> > > > > > to
> > > > > > make sure there are some pages left in the DMA32 zone,
> > > > > > otherwise
> > > > > > random non-IO page allocations would also potentially
> > > > > > exhaust
> > > > > > the
> > > > > > DMA32 zone without anybody caring, which means removing
> > > > > > this
> > > > > > zone
> > > > > > wouldn't be any worse than whatever other subsystems may be
> > > > > > doing
> > > > > > already...
> > > > > > 
> > > > > > /Thomas
> > > > > > 
> > > > > > 
> > > > > > On 2/16/19 12:02 AM, Kuehling, Felix wrote:
> > > > > > > This is an RFC. I'm not sure this is the right solution,
> > > > > > > but
> > > > > > > it
> > > > > > > highlights the problem I'm trying to solve.
> > > > > > > 
> > > > > > > The dma32_zone limits the acc_size of all allocated BOs
> > > > > > > to
> > > > > > > 2GB.
> > > > > > > On a
> > > > > > > 64-bit system with hundreds of GB of system memory and
> > > > > > > GPU
> > > > > > > memory,
> > > > > > > this can become a bottle neck. We're seeing TTM memory
> > > > > > > allocation
> > > > > > > failures not because we're truly out of memory, but
> > > > > > > because
> > > > > > > we're
> > > > > > > out of space in the dma32_zone for the acc_size needed
> > > > > > > for
> > > > > > > our BO
> > > > > > > book-keeping.
> > > > > > > 
> > > > > > > Signed-off-by: Felix Kuehling 
> > > > > > > CC: thellst...@vmware.com
> > > > > > > CC: christian.koe...@amd.com
> > > > > > > ---
> > > > > > > drivers/gpu/drm/ttm/ttm_memory.c | 4 ++--
> > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
> > > > > > > b/drivers/gpu/drm/ttm/ttm_memory.c
> > > > > > > index f1567c3..bb05365 100644
> > > > > > > --- a/drivers/gpu/drm/ttm/ttm_memory.c
> > > > > > > +++ b/drivers/gpu/drm/ttm/ttm_memory.c
> > > > > > > @@ -363,7 +363,7 @@ static int
>

Re: [RFC v4 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework

[Brendan Higgins]

On Mon, Feb 18, 2019 at 12:02 PM Frank Rowand  wrote:

> I have not read through the patches in any detail.  I have read some of
> the code to try to understand the patches to the devicetree unit tests.
> So that may limit how valid my comments below are.

No problem.

>
> I found the code difficult to read in places where it should have been
> much simpler to read.  Structuring the code in a pseudo object oriented
> style meant that everywhere in a code path that I encountered a dynamic
> function call, I had to go find where that dynamic function call was
> initialized (and being the cautious person that I am, verify that
> no where else was the value of that dynamic function call).  With
> primitive vi and tags, that search would have instead just been a
> simple key press (or at worst a few keys) if hard coded function
> calls were done instead of dynamic function calls.  In the code paths
> that I looked at, I did not see any case of a dynamic function being
> anything other than the value it was originally initialized as.
> There may be such cases, I did not read the entire patch set.  There
> may also be cases envisioned in the architects mind of how this
> flexibility may be of future value.  Dunno.

Yeah, a lot of it is intended to make architecture specific
implementations and some other future work easier. Some of it is also
for testing purposes. Admittedly some is for neither reason, but given
the heavy usage elsewhere, I figured there was no harm since it was
all private internal usage anyway.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 1/2] drm/mediatek: separate mipi_tx to different file

[CK Hu]

Hi, Jitao:

On Tue, 2019-02-19 at 17:14 +0800, Jitao Shi wrote:
> Different IC has different mipi_tx setting of dsi.
> This patch separates the mipi_tx hardware relate part for mt8173.
> 
> Signed-off-by: Jitao Shi 
> ---
>  drivers/gpu/drm/mediatek/Makefile |   1 +
>  drivers/gpu/drm/mediatek/mtk_mipi_tx.c| 350 ++
>  drivers/gpu/drm/mediatek/mtk_mipi_tx.h|  51 +++
>  drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c | 290 +++
>  4 files changed, 377 insertions(+), 315 deletions(-)
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_mipi_tx.h
>  create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c
> 

[snip]
>  
> +static void mtk_mipi_tx_clk_get_ops(struct mtk_mipi_tx *mipi_tx,
> + const struct clk_ops **ops)
> +{
> + if (mipi_tx && mipi_tx->driver_data &&
> + mipi_tx->driver_data->mipi_tx_clk_ops)
> + *ops = mipi_tx->driver_data->mipi_tx_clk_ops;
> + else
> + dev_err(mipi_tx->dev, "Failed to get clk ops of phy\n");

Any where call mtk_mipi_tx_clk_get_ops() would make sure mipi_tx is not
NULL, so you need not to check mipi_tx. And the checking of driver_data
and mipi_tx_clk_ops looks unnecessary because any one who implement this
driver would never let this happen. So this function just need do the
assignment and therefore this assignment could just do in probe().

Regards,
CK

> +}
> +
>  static int mtk_mipi_tx_probe(struct platform_device *pdev)
>  {
>   struct device *dev = &pdev->dev;
>   struct mtk_mipi_tx *mipi_tx;
>   struct resource *mem;
> - struct clk *ref_clk;
>   const char *ref_clk_name;
>   struct clk_init_data clk_init = {
> - .ops = &mtk_mipi_tx_pll_ops,
>   .num_parents = 1,
>   .parent_names = (const char * const *)&ref_clk_name,
>   .flags = CLK_SET_RATE_GATE,
> @@ -408,6 +132,7 @@ static int mtk_mipi_tx_probe(struct platform_device *pdev)
>   return -ENOMEM;
>  
>   mipi_tx->driver_data = of_device_get_match_data(dev);
> +
>   mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>   mipi_tx->regs = devm_ioremap_resource(dev, mem);
>   if (IS_ERR(mipi_tx->regs)) {
> @@ -416,13 +141,14 @@ static int mtk_mipi_tx_probe(struct platform_device 
> *pdev)
>   return ret;
>   }
>  
> - ref_clk = devm_clk_get(dev, NULL);
> - if (IS_ERR(ref_clk)) {
> - ret = PTR_ERR(ref_clk);
> + mipi_tx->ref_clk = devm_clk_get(dev, NULL);
> + if (IS_ERR(mipi_tx->ref_clk)) {
> + ret = PTR_ERR(mipi_tx->ref_clk);
>   dev_err(dev, "Failed to get reference clock: %d\n", ret);
>   return ret;
>   }
> - ref_clk_name = __clk_get_name(ref_clk);
> +
> + ref_clk_name = __clk_get_name(mipi_tx->ref_clk);
>  
>   ret = of_property_read_string(dev->of_node, "clock-output-names",
> &clk_init.name);
> @@ -431,6 +157,8 @@ static int mtk_mipi_tx_probe(struct platform_device *pdev)
>   return ret;
>   }
>  
> + mtk_mipi_tx_clk_get_ops(mipi_tx, &clk_init.ops);
> +
>   mipi_tx->pll_hw.init = &clk_init;
>   mipi_tx->pll = devm_clk_register(dev, &mipi_tx->pll_hw);
>   if (IS_ERR(mipi_tx->pll)) {
> @@ -465,20 +193,12 @@ static int mtk_mipi_tx_remove(struct platform_device 
> *pdev)
>   return 0;
>  }
>  
> -static const struct mtk_mipitx_data mt2701_mipitx_data = {
> - .mppll_preserve = (3 << 8)
> -};
> -
> -static const struct mtk_mipitx_data mt8173_mipitx_data = {
> - .mppll_preserve = (0 << 8)
> -};
> -
>  static const struct of_device_id mtk_mipi_tx_match[] = {
>   { .compatible = "mediatek,mt2701-mipi-tx",
> .data = &mt2701_mipitx_data },
>   { .compatible = "mediatek,mt8173-mipi-tx",
> .data = &mt8173_mipitx_data },
> - {},
> + { },
>  };
>  



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

[RESEND PATCH 3/7] mm/gup: Change GUP fast to use flags rather than a write 'bool'

[ira . weiny]

From: Ira Weiny 

To facilitate additional options to get_user_pages_fast() change the
singular write parameter to be gup_flags.

This patch does not change any functionality.  New functionality will
follow in subsequent patches.

Some of the get_user_pages_fast() call sites were unchanged because they
already passed FOLL_WRITE or 0 for the write parameter.

Signed-off-by: Ira Weiny 
---
 arch/mips/mm/gup.c | 11 ++-
 arch/powerpc/kvm/book3s_64_mmu_hv.c|  4 ++--
 arch/powerpc/kvm/e500_mmu.c|  2 +-
 arch/powerpc/mm/mmu_context_iommu.c|  4 ++--
 arch/s390/kvm/interrupt.c  |  2 +-
 arch/s390/mm/gup.c | 12 ++--
 arch/sh/mm/gup.c   | 11 ++-
 arch/sparc/mm/gup.c|  9 +
 arch/x86/kvm/paging_tmpl.h |  2 +-
 arch/x86/kvm/svm.c |  2 +-
 drivers/fpga/dfl-afu-dma-region.c  |  2 +-
 drivers/gpu/drm/via/via_dmablit.c  |  3 ++-
 drivers/infiniband/hw/hfi1/user_pages.c|  3 ++-
 drivers/misc/genwqe/card_utils.c   |  2 +-
 drivers/misc/vmw_vmci/vmci_host.c  |  2 +-
 drivers/misc/vmw_vmci/vmci_queue_pair.c|  6 --
 drivers/platform/goldfish/goldfish_pipe.c  |  3 ++-
 drivers/rapidio/devices/rio_mport_cdev.c   |  4 +++-
 drivers/sbus/char/oradax.c |  2 +-
 drivers/scsi/st.c  |  3 ++-
 drivers/staging/gasket/gasket_page_table.c |  4 ++--
 drivers/tee/tee_shm.c  |  2 +-
 drivers/vfio/vfio_iommu_spapr_tce.c|  3 ++-
 drivers/vhost/vhost.c  |  2 +-
 drivers/video/fbdev/pvr2fb.c   |  2 +-
 drivers/virt/fsl_hypervisor.c  |  2 +-
 drivers/xen/gntdev.c   |  2 +-
 fs/orangefs/orangefs-bufmap.c  |  2 +-
 include/linux/mm.h |  4 ++--
 kernel/futex.c |  2 +-
 lib/iov_iter.c |  7 +--
 mm/gup.c   | 10 +-
 mm/util.c  |  8 
 net/ceph/pagevec.c |  2 +-
 net/rds/info.c |  2 +-
 net/rds/rdma.c |  3 ++-
 36 files changed, 81 insertions(+), 65 deletions(-)

diff --git a/arch/mips/mm/gup.c b/arch/mips/mm/gup.c
index 0d14e0d8eacf..4c2b4483683c 100644
--- a/arch/mips/mm/gup.c
+++ b/arch/mips/mm/gup.c
@@ -235,7 +235,7 @@ int __get_user_pages_fast(unsigned long start, int 
nr_pages, int write,
  * get_user_pages_fast() - pin user pages in memory
  * @start: starting user address
  * @nr_pages:  number of pages from start to pin
- * @write: whether pages will be written to
+ * @gup_flags: flags modifying pin behaviour
  * @pages: array that receives pointers to the pages pinned.
  * Should be at least nr_pages long.
  *
@@ -247,8 +247,8 @@ int __get_user_pages_fast(unsigned long start, int 
nr_pages, int write,
  * requested. If nr_pages is 0 or negative, returns 0. If no pages
  * were pinned, returns -errno.
  */
-int get_user_pages_fast(unsigned long start, int nr_pages, int write,
-   struct page **pages)
+int get_user_pages_fast(unsigned long start, int nr_pages,
+   unsigned int gup_flags, struct page **pages)
 {
struct mm_struct *mm = current->mm;
unsigned long addr, len, end;
@@ -273,7 +273,8 @@ int get_user_pages_fast(unsigned long start, int nr_pages, 
int write,
next = pgd_addr_end(addr, end);
if (pgd_none(pgd))
goto slow;
-   if (!gup_pud_range(pgd, addr, next, write, pages, &nr))
+   if (!gup_pud_range(pgd, addr, next, gup_flags & FOLL_WRITE,
+  pages, &nr))
goto slow;
} while (pgdp++, addr = next, addr != end);
local_irq_enable();
@@ -289,7 +290,7 @@ int get_user_pages_fast(unsigned long start, int nr_pages, 
int write,
pages += nr;
 
ret = get_user_pages_unlocked(start, (end - start) >> PAGE_SHIFT,
- pages, write ? FOLL_WRITE : 0);
+ pages, gup_flags);
 
/* Have to be a bit careful with return values */
if (nr > 0) {
diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c 
b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index bd2dcfbf00cd..8fcb0a921e46 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -582,7 +582,7 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run, struct 
kvm_vcpu *vcpu,
/* If writing != 0, then the HPTE must allow writing, if we get here */
write_ok = writing;
hva = gfn_to_hva_memslot(memslot, gfn);
-   npages = get_user_pages_fast(hva, 1, writing, pages);
+   npages = get_user_pages_fast(hva, 1

[RESEND PATCH 1/7] mm/gup: Replace get_user_pages_longterm() with FOLL_LONGTERM

[ira . weiny]

From: Ira Weiny 

Rather than have a separate get_user_pages_longterm() call,
introduce FOLL_LONGTERM and change the longterm callers to use
it.

This patch does not change any functionality.

FOLL_LONGTERM can only be supported with get_user_pages() as it
requires vmas to determine if DAX is in use.

Signed-off-by: Ira Weiny 
---
 drivers/infiniband/core/umem.c |   5 +-
 drivers/infiniband/hw/qib/qib_user_pages.c |   8 +-
 drivers/infiniband/hw/usnic/usnic_uiom.c   |   9 +-
 drivers/media/v4l2-core/videobuf-dma-sg.c  |   6 +-
 drivers/vfio/vfio_iommu_type1.c|   3 +-
 include/linux/mm.h |  13 +-
 mm/gup.c   | 138 -
 mm/gup_benchmark.c |   5 +-
 8 files changed, 101 insertions(+), 86 deletions(-)

diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index b69d3efa8712..120a40df91b4 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -185,10 +185,11 @@ struct ib_umem *ib_umem_get(struct ib_udata *udata, 
unsigned long addr,
 
while (npages) {
down_read(&mm->mmap_sem);
-   ret = get_user_pages_longterm(cur_base,
+   ret = get_user_pages(cur_base,
 min_t(unsigned long, npages,
   PAGE_SIZE / sizeof (struct page *)),
-gup_flags, page_list, vma_list);
+gup_flags | FOLL_LONGTERM,
+page_list, vma_list);
if (ret < 0) {
up_read(&mm->mmap_sem);
goto umem_release;
diff --git a/drivers/infiniband/hw/qib/qib_user_pages.c 
b/drivers/infiniband/hw/qib/qib_user_pages.c
index ef8bcf366ddc..1b9368261035 100644
--- a/drivers/infiniband/hw/qib/qib_user_pages.c
+++ b/drivers/infiniband/hw/qib/qib_user_pages.c
@@ -114,10 +114,10 @@ int qib_get_user_pages(unsigned long start_page, size_t 
num_pages,
 
down_read(¤t->mm->mmap_sem);
for (got = 0; got < num_pages; got += ret) {
-   ret = get_user_pages_longterm(start_page + got * PAGE_SIZE,
- num_pages - got,
- FOLL_WRITE | FOLL_FORCE,
- p + got, NULL);
+   ret = get_user_pages(start_page + got * PAGE_SIZE,
+num_pages - got,
+FOLL_LONGTERM | FOLL_WRITE | FOLL_FORCE,
+p + got, NULL);
if (ret < 0) {
up_read(¤t->mm->mmap_sem);
goto bail_release;
diff --git a/drivers/infiniband/hw/usnic/usnic_uiom.c 
b/drivers/infiniband/hw/usnic/usnic_uiom.c
index 06862a6af185..1d9a182ac163 100644
--- a/drivers/infiniband/hw/usnic/usnic_uiom.c
+++ b/drivers/infiniband/hw/usnic/usnic_uiom.c
@@ -143,10 +143,11 @@ static int usnic_uiom_get_pages(unsigned long addr, 
size_t size, int writable,
ret = 0;
 
while (npages) {
-   ret = get_user_pages_longterm(cur_base,
-   min_t(unsigned long, npages,
-   PAGE_SIZE / sizeof(struct page *)),
-   gup_flags, page_list, NULL);
+   ret = get_user_pages(cur_base,
+min_t(unsigned long, npages,
+PAGE_SIZE / sizeof(struct page *)),
+gup_flags | FOLL_LONGTERM,
+page_list, NULL);
 
if (ret < 0)
goto out;
diff --git a/drivers/media/v4l2-core/videobuf-dma-sg.c 
b/drivers/media/v4l2-core/videobuf-dma-sg.c
index 08929c087e27..870a2a526e0b 100644
--- a/drivers/media/v4l2-core/videobuf-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf-dma-sg.c
@@ -186,12 +186,12 @@ static int videobuf_dma_init_user_locked(struct 
videobuf_dmabuf *dma,
dprintk(1, "init user [0x%lx+0x%lx => %d pages]\n",
data, size, dma->nr_pages);
 
-   err = get_user_pages_longterm(data & PAGE_MASK, dma->nr_pages,
-flags, dma->pages, NULL);
+   err = get_user_pages(data & PAGE_MASK, dma->nr_pages,
+flags | FOLL_LONGTERM, dma->pages, NULL);
 
if (err != dma->nr_pages) {
dma->nr_pages = (err >= 0) ? err : 0;
-   dprintk(1, "get_user_pages_longterm: err=%d [%d]\n", err,
+   dprintk(1, "get_user_pages: err=%d [%d]\n", err,
dma->nr_pages);
return err < 0 ? err : -EINVAL;
}
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 73652e21efec..1500bd0bb6da 100644
--- a/drivers/vfio/

[RESEND PATCH 4/7] mm/gup: Add FOLL_LONGTERM capability to GUP fast

[ira . weiny]

From: Ira Weiny 

DAX pages were previously unprotected from longterm pins when users
called get_user_pages_fast().

Use the new FOLL_LONGTERM flag to check for DEVMAP pages and fall
back to regular GUP processing if a DEVMAP page is encountered.

Signed-off-by: Ira Weiny 
---
 mm/gup.c | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index 6f32d36b3c5b..f7e759c523bb 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1439,6 +1439,9 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr, 
unsigned long end,
goto pte_unmap;
 
if (pte_devmap(pte)) {
+   if (unlikely(flags & FOLL_LONGTERM))
+   goto pte_unmap;
+
pgmap = get_dev_pagemap(pte_pfn(pte), pgmap);
if (unlikely(!pgmap)) {
undo_dev_pagemap(nr, nr_start, pages);
@@ -1578,8 +1581,11 @@ static int gup_huge_pmd(pmd_t orig, pmd_t *pmdp, 
unsigned long addr,
if (!pmd_access_permitted(orig, flags & FOLL_WRITE))
return 0;
 
-   if (pmd_devmap(orig))
+   if (pmd_devmap(orig)) {
+   if (unlikely(flags & FOLL_LONGTERM))
+   return 0;
return __gup_device_huge_pmd(orig, pmdp, addr, end, pages, nr);
+   }
 
refs = 0;
page = pmd_page(orig) + ((addr & ~PMD_MASK) >> PAGE_SHIFT);
@@ -1904,8 +1910,20 @@ int get_user_pages_fast(unsigned long start, int 
nr_pages,
start += nr << PAGE_SHIFT;
pages += nr;
 
-   ret = get_user_pages_unlocked(start, nr_pages - nr, pages,
- gup_flags);
+   if (gup_flags & FOLL_LONGTERM) {
+   down_read(¤t->mm->mmap_sem);
+   ret = __gup_longterm_locked(current, current->mm,
+   start, nr_pages - nr,
+   pages, NULL, gup_flags);
+   up_read(¤t->mm->mmap_sem);
+   } else {
+   /*
+* retain FAULT_FOLL_ALLOW_RETRY optimization if
+* possible
+*/
+   ret = get_user_pages_unlocked(start, nr_pages - nr,
+ pages, gup_flags);
+   }
 
/* Have to be a bit careful with return values */
if (nr > 0) {
-- 
2.20.1

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

[RESEND PATCH 6/7] IB/qib: Use the new FOLL_LONGTERM flag to get_user_pages_fast()

[ira . weiny]

From: Ira Weiny 

Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
FS DAX pages being mapped.

Signed-off-by: Ira Weiny 
---
 drivers/infiniband/hw/qib/qib_user_sdma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/qib/qib_user_sdma.c 
b/drivers/infiniband/hw/qib/qib_user_sdma.c
index 31c523b2a9f5..b53cc0240e02 100644
--- a/drivers/infiniband/hw/qib/qib_user_sdma.c
+++ b/drivers/infiniband/hw/qib/qib_user_sdma.c
@@ -673,7 +673,7 @@ static int qib_user_sdma_pin_pages(const struct qib_devdata 
*dd,
else
j = npages;
 
-   ret = get_user_pages_fast(addr, j, 0, pages);
+   ret = get_user_pages_fast(addr, j, FOLL_LONGTERM, pages);
if (ret != j) {
i = 0;
j = ret;
-- 
2.20.1

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

[RESEND PATCH 2/7] mm/gup: Change write parameter to flags in fast walk

[ira . weiny]

From: Ira Weiny 

In order to support more options in the GUP fast walk, change
the write parameter to flags throughout the call stack.

This patch does not change functionality and passes FOLL_WRITE
where write was previously used.

Signed-off-by: Ira Weiny 
---
 mm/gup.c | 52 ++--
 1 file changed, 26 insertions(+), 26 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index ee96eaff118c..681388236106 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1417,7 +1417,7 @@ static void undo_dev_pagemap(int *nr, int nr_start, 
struct page **pages)
 
 #ifdef CONFIG_ARCH_HAS_PTE_SPECIAL
 static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
-int write, struct page **pages, int *nr)
+unsigned int flags, struct page **pages, int *nr)
 {
struct dev_pagemap *pgmap = NULL;
int nr_start = *nr, ret = 0;
@@ -1435,7 +1435,7 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr, 
unsigned long end,
if (pte_protnone(pte))
goto pte_unmap;
 
-   if (!pte_access_permitted(pte, write))
+   if (!pte_access_permitted(pte, flags & FOLL_WRITE))
goto pte_unmap;
 
if (pte_devmap(pte)) {
@@ -1487,7 +1487,7 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr, 
unsigned long end,
  * useful to have gup_huge_pmd even if we can't operate on ptes.
  */
 static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
-int write, struct page **pages, int *nr)
+unsigned int flags, struct page **pages, int *nr)
 {
return 0;
 }
@@ -1570,12 +1570,12 @@ static int __gup_device_huge_pud(pud_t pud, pud_t 
*pudp, unsigned long addr,
 #endif
 
 static int gup_huge_pmd(pmd_t orig, pmd_t *pmdp, unsigned long addr,
-   unsigned long end, int write, struct page **pages, int *nr)
+   unsigned long end, unsigned int flags, struct page **pages, int 
*nr)
 {
struct page *head, *page;
int refs;
 
-   if (!pmd_access_permitted(orig, write))
+   if (!pmd_access_permitted(orig, flags & FOLL_WRITE))
return 0;
 
if (pmd_devmap(orig))
@@ -1608,12 +1608,12 @@ static int gup_huge_pmd(pmd_t orig, pmd_t *pmdp, 
unsigned long addr,
 }
 
 static int gup_huge_pud(pud_t orig, pud_t *pudp, unsigned long addr,
-   unsigned long end, int write, struct page **pages, int *nr)
+   unsigned long end, unsigned int flags, struct page **pages, int 
*nr)
 {
struct page *head, *page;
int refs;
 
-   if (!pud_access_permitted(orig, write))
+   if (!pud_access_permitted(orig, flags & FOLL_WRITE))
return 0;
 
if (pud_devmap(orig))
@@ -1646,13 +1646,13 @@ static int gup_huge_pud(pud_t orig, pud_t *pudp, 
unsigned long addr,
 }
 
 static int gup_huge_pgd(pgd_t orig, pgd_t *pgdp, unsigned long addr,
-   unsigned long end, int write,
+   unsigned long end, unsigned int flags,
struct page **pages, int *nr)
 {
int refs;
struct page *head, *page;
 
-   if (!pgd_access_permitted(orig, write))
+   if (!pgd_access_permitted(orig, flags & FOLL_WRITE))
return 0;
 
BUILD_BUG_ON(pgd_devmap(orig));
@@ -1683,7 +1683,7 @@ static int gup_huge_pgd(pgd_t orig, pgd_t *pgdp, unsigned 
long addr,
 }
 
 static int gup_pmd_range(pud_t pud, unsigned long addr, unsigned long end,
-   int write, struct page **pages, int *nr)
+   unsigned int flags, struct page **pages, int *nr)
 {
unsigned long next;
pmd_t *pmdp;
@@ -1705,7 +1705,7 @@ static int gup_pmd_range(pud_t pud, unsigned long addr, 
unsigned long end,
if (pmd_protnone(pmd))
return 0;
 
-   if (!gup_huge_pmd(pmd, pmdp, addr, next, write,
+   if (!gup_huge_pmd(pmd, pmdp, addr, next, flags,
pages, nr))
return 0;
 
@@ -1715,9 +1715,9 @@ static int gup_pmd_range(pud_t pud, unsigned long addr, 
unsigned long end,
 * pmd format and THP pmd format
 */
if (!gup_huge_pd(__hugepd(pmd_val(pmd)), addr,
-PMD_SHIFT, next, write, pages, nr))
+PMD_SHIFT, next, flags, pages, nr))
return 0;
-   } else if (!gup_pte_range(pmd, addr, next, write, pages, nr))
+   } else if (!gup_pte_range(pmd, addr, next, flags, pages, nr))
return 0;
} while (pmdp++, addr = next, addr != end);
 
@@ -1725,7 +1725,7 @@ static int gup_pmd_range(pud_t pud, unsigned long addr, 
unsigned long end,
 }
 
 static int gup_pud_ran

[RESEND PATCH 5/7] IB/hfi1: Use the new FOLL_LONGTERM flag to get_user_pages_fast()

[ira . weiny]

From: Ira Weiny 

Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
FS DAX pages being mapped.

Signed-off-by: Ira Weiny 
---
 drivers/infiniband/hw/hfi1/user_pages.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/infiniband/hw/hfi1/user_pages.c 
b/drivers/infiniband/hw/hfi1/user_pages.c
index 78ccacaf97d0..6a7f9cd5a94e 100644
--- a/drivers/infiniband/hw/hfi1/user_pages.c
+++ b/drivers/infiniband/hw/hfi1/user_pages.c
@@ -104,9 +104,11 @@ int hfi1_acquire_user_pages(struct mm_struct *mm, unsigned 
long vaddr, size_t np
bool writable, struct page **pages)
 {
int ret;
+   unsigned int gup_flags = writable ? FOLL_WRITE : 0;
 
-   ret = get_user_pages_fast(vaddr, npages, writable ? FOLL_WRITE : 0,
- pages);
+   gup_flags |= FOLL_LONGTERM;
+
+   ret = get_user_pages_fast(vaddr, npages, gup_flags, pages);
if (ret < 0)
return ret;
 
-- 
2.20.1

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

[RESEND PATCH 7/7] IB/mthca: Use the new FOLL_LONGTERM flag to get_user_pages_fast()

[ira . weiny]

From: Ira Weiny 

Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
FS DAX pages being mapped.

Signed-off-by: Ira Weiny 
---
 drivers/infiniband/hw/mthca/mthca_memfree.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/mthca/mthca_memfree.c 
b/drivers/infiniband/hw/mthca/mthca_memfree.c
index 112d2f38e0de..8ff0e90d7564 100644
--- a/drivers/infiniband/hw/mthca/mthca_memfree.c
+++ b/drivers/infiniband/hw/mthca/mthca_memfree.c
@@ -472,7 +472,8 @@ int mthca_map_user_db(struct mthca_dev *dev, struct 
mthca_uar *uar,
goto out;
}
 
-   ret = get_user_pages_fast(uaddr & PAGE_MASK, 1, FOLL_WRITE, pages);
+   ret = get_user_pages_fast(uaddr & PAGE_MASK, 1,
+ FOLL_WRITE | FOLL_LONGTERM, pages);
if (ret < 0)
goto out;
 
-- 
2.20.1

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

[RESEND PATCH 0/7] Add FOLL_LONGTERM to GUP fast and use it

[ira . weiny]

From: Ira Weiny 

Resending these as I had only 1 minor comment which I believe we have covered
in this series.  I was anticipating these going through the mm tree as they
depend on a cleanup patch there and the IB changes are very minor.  But they
could just as well go through the IB tree.

NOTE: This series depends on my clean up patch to remove the write parameter
from gup_fast_permitted()[1]

HFI1, qib, and mthca, use get_user_pages_fast() due to it performance
advantages.  These pages can be held for a significant time.  But
get_user_pages_fast() does not protect against mapping of FS DAX pages.

Introduce FOLL_LONGTERM and use this flag in get_user_pages_fast() which
retains the performance while also adding the FS DAX checks.  XDP has also
shown interest in using this functionality.[2]

In addition we change get_user_pages() to use the new FOLL_LONGTERM flag and
remove the specialized get_user_pages_longterm call.

[1] https://lkml.org/lkml/2019/2/11/237
[2] https://lkml.org/lkml/2019/2/11/1789

Ira Weiny (7):
  mm/gup: Replace get_user_pages_longterm() with FOLL_LONGTERM
  mm/gup: Change write parameter to flags in fast walk
  mm/gup: Change GUP fast to use flags rather than a write 'bool'
  mm/gup: Add FOLL_LONGTERM capability to GUP fast
  IB/hfi1: Use the new FOLL_LONGTERM flag to get_user_pages_fast()
  IB/qib: Use the new FOLL_LONGTERM flag to get_user_pages_fast()
  IB/mthca: Use the new FOLL_LONGTERM flag to get_user_pages_fast()

 arch/mips/mm/gup.c  |  11 +-
 arch/powerpc/kvm/book3s_64_mmu_hv.c |   4 +-
 arch/powerpc/kvm/e500_mmu.c |   2 +-
 arch/powerpc/mm/mmu_context_iommu.c |   4 +-
 arch/s390/kvm/interrupt.c   |   2 +-
 arch/s390/mm/gup.c  |  12 +-
 arch/sh/mm/gup.c|  11 +-
 arch/sparc/mm/gup.c |   9 +-
 arch/x86/kvm/paging_tmpl.h  |   2 +-
 arch/x86/kvm/svm.c  |   2 +-
 drivers/fpga/dfl-afu-dma-region.c   |   2 +-
 drivers/gpu/drm/via/via_dmablit.c   |   3 +-
 drivers/infiniband/core/umem.c  |   5 +-
 drivers/infiniband/hw/hfi1/user_pages.c |   5 +-
 drivers/infiniband/hw/mthca/mthca_memfree.c |   3 +-
 drivers/infiniband/hw/qib/qib_user_pages.c  |   8 +-
 drivers/infiniband/hw/qib/qib_user_sdma.c   |   2 +-
 drivers/infiniband/hw/usnic/usnic_uiom.c|   9 +-
 drivers/media/v4l2-core/videobuf-dma-sg.c   |   6 +-
 drivers/misc/genwqe/card_utils.c|   2 +-
 drivers/misc/vmw_vmci/vmci_host.c   |   2 +-
 drivers/misc/vmw_vmci/vmci_queue_pair.c |   6 +-
 drivers/platform/goldfish/goldfish_pipe.c   |   3 +-
 drivers/rapidio/devices/rio_mport_cdev.c|   4 +-
 drivers/sbus/char/oradax.c  |   2 +-
 drivers/scsi/st.c   |   3 +-
 drivers/staging/gasket/gasket_page_table.c  |   4 +-
 drivers/tee/tee_shm.c   |   2 +-
 drivers/vfio/vfio_iommu_spapr_tce.c |   3 +-
 drivers/vfio/vfio_iommu_type1.c |   3 +-
 drivers/vhost/vhost.c   |   2 +-
 drivers/video/fbdev/pvr2fb.c|   2 +-
 drivers/virt/fsl_hypervisor.c   |   2 +-
 drivers/xen/gntdev.c|   2 +-
 fs/orangefs/orangefs-bufmap.c   |   2 +-
 include/linux/mm.h  |  17 +-
 kernel/futex.c  |   2 +-
 lib/iov_iter.c  |   7 +-
 mm/gup.c| 220 
 mm/gup_benchmark.c  |   5 +-
 mm/util.c   |   8 +-
 net/ceph/pagevec.c  |   2 +-
 net/rds/info.c  |   2 +-
 net/rds/rdma.c  |   3 +-
 44 files changed, 232 insertions(+), 180 deletions(-)

-- 
2.20.1

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

Re: [PATCH] drm/amd/display: Fix reference counting for struct dc_sink.

[Mathias Fröhlich]

Hi,

ping?
... to the dc folks?

best
Mathias

On Wednesday, 13 February 2019 21:38:03 CET Alex Deucher wrote:
> Add amd-gfx and some DC people.
> 
> Alex
> 
> On Sun, Feb 10, 2019 at 5:13 AM  wrote:
> >
> > From: Mathias Fröhlich 
> >
> > Reference counting in amdgpu_dm_connector for amdgpu_dm_connector::dc_sink
> > and amdgpu_dm_connector::dc_em_sink as well as in dc_link::local_sink seems
> > to be out of shape. Thus make reference counting consistent for these
> > members and just plain increment the reference count when the variable
> > gets assigned and decrement when the pointer is set to zero or replaced.
> > Also simplify reference counting in selected function sopes to be sure the
> > reference is released in any case. In some cases add NULL pointer check
> > before dereferencing.
> > At a hand full of places a comment is placed to stat that the reference
> > increment happened already somewhere else.
> >
> > This actually fixes the following kernel bug on my system when enabling
> > display core in amdgpu. There are some more similar bug reports around,
> > so it probably helps at more places.
> >
> >kernel BUG at mm/slub.c:294!
> >invalid opcode:  [#1] SMP PTI
> >CPU: 9 PID: 1180 Comm: Xorg Not tainted 5.0.0-rc1+ #2
> >Hardware name: Supermicro X10DAi/X10DAI, BIOS 3.0a 02/05/2018
> >RIP: 0010:__slab_free+0x1e2/0x3d0
> >Code: 8b 54 24 30 48 89 4c 24 28 e8 da fb ff ff 4c 8b 54 24 28 85 c0 0f 
> > 85 67 fe ff ff 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 <0f> 0b 49 3b 
> > 5c 24 28 75 ab 48 8b 44 24 30 49 89 4c 24 28 49 89 44
> >RSP: 0018:b0978589fa90 EFLAGS: 00010246
> >RAX: 92f12806c400 RBX: 80200019 RCX: 92f12806c400
> >RDX: 92f12806c400 RSI: dd6421a01a00 RDI: 92ed2f406e80
> >RBP: b0978589fb40 R08: 0001 R09: c0ee4748
> >R10: 92f12806c400 R11: 0001 R12: dd6421a01a00
> >R13: 92f12806c400 R14: 92ed2f406e80 R15: dd6421a01a20
> >FS:  7f4170be0ac0() GS:92ed2fb4() 
> > knlGS:
> >CS:  0010 DS:  ES:  CR0: 80050033
> >CR2: 562818aaa000 CR3: 00045745a002 CR4: 003606e0
> >DR0:  DR1:  DR2: 
> >DR3:  DR6: fffe0ff0 DR7: 0400
> >Call Trace:
> > ? drm_dbg+0x87/0x90 [drm]
> > dc_stream_release+0x28/0x50 [amdgpu]
> > amdgpu_dm_connector_mode_valid+0xb4/0x1f0 [amdgpu]
> > drm_helper_probe_single_connector_modes+0x492/0x6b0 [drm_kms_helper]
> > drm_mode_getconnector+0x457/0x490 [drm]
> > ? drm_connector_property_set_ioctl+0x60/0x60 [drm]
> > drm_ioctl_kernel+0xa9/0xf0 [drm]
> > drm_ioctl+0x201/0x3a0 [drm]
> > ? drm_connector_property_set_ioctl+0x60/0x60 [drm]
> > amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
> > do_vfs_ioctl+0xa4/0x630
> > ? __sys_recvmsg+0x83/0xa0
> > ksys_ioctl+0x60/0x90
> > __x64_sys_ioctl+0x16/0x20
> > do_syscall_64+0x5b/0x160
> > entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >RIP: 0033:0x7f417110809b
> >Code: 0f 1e fa 48 8b 05 ed bd 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff 
> > ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 
> > ff ff 73 01 c3 48 8b 0d bd bd 0c 00 f7 d8 64 89 01 48
> >RSP: 002b:7ffdd8d1c268 EFLAGS: 0246 ORIG_RAX: 0010
> >RAX: ffda RBX: 562818a8ebc0 RCX: 7f417110809b
> >RDX: 7ffdd8d1c2a0 RSI: c05064a7 RDI: 0012
> >RBP: 7ffdd8d1c2a0 R08: 562819012280 R09: 0007
> >R10:  R11: 0246 R12: c05064a7
> >R13: 0012 R14: 0012 R15: 7ffdd8d1c2a0
> >Modules linked in: nfsv4 dns_resolver nfs lockd grace fscache fuse vfat 
> > fat amdgpu intel_rapl sb_edac x86_pkg_temp_thermal intel_powerclamp 
> > coretemp kvm_intel kvm irqbypass crct10dif_pclmul chash gpu_sched 
> > crc32_pclmul snd_hda_codec_realtek ghash_clmulni_intel amd_iommu_v2 
> > iTCO_wdt iTCO_vendor_support ttm snd_hda_codec_generic snd_hda_codec_hdmi 
> > ledtrig_audio snd_hda_intel drm_kms_helper snd_hda_codec intel_cstate 
> > snd_hda_core drm snd_hwdep snd_seq snd_seq_device intel_uncore snd_pcm 
> > intel_rapl_perf snd_timer snd soundcore ioatdma pcspkr 
> > intel_wmi_thunderbolt mxm_wmi i2c_i801 lpc_ich pcc_cpufreq auth_rpcgss 
> > sunrpc igb crc32c_intel i2c_algo_bit dca wmi hid_cherry analog gameport 
> > joydev
> >
> > This patch is based on agd5f/drm-next-5.1-wip. This patch does not require
> > all of that, but agd5f/drm-next-5.1-wip contains at least one more dc_sink
> > counting fix that I could spot.
> >
> > Signed-off-by: Mathias Fröhlich 
> > ---
> >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 43 +++
> >  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  1 +
> >  drivers/gpu/drm/amd/display/dc/core/dc_link.c |  1 +
> >  3 files 

[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U

[bugzilla-daemon]

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

--- Comment #16 from Matrix  ---
Is it possible to upgrade the Bios from Linux? I think it's just a windows-only
bios upgrade from HP right? Will it work in Freedos?

-- 
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 09/11] drm/syncobj: add transition iotcls between binary and timeline

[zhoucm1]

On 2019年02月19日 19:32, Koenig, Christian wrote:

Hi David,


Could you have a look if it's reasonable?


Patch #1 is also something I already fixed on my local branch.

But patch #2 won't work like this.

We can't return an error from drm_syncobj_add_point() because we 
already submitted work to the hardware. And just dropping the fence 
like you do in the patch is a clearly no-go as well.


Then do you have any idea to skip the messed order signal point?

-David


Regards,
Christian.

Am 19.02.19 um 11:46 schrieb zhoucm1:


Hi Lionel,

the attached should fix your problem and also messed signal order.

Hi Christian,

Could you have a look if it's reasonable?


btw: I pushed to change to 
https://github.com/amingriyue/timeline-syncobj-kernel, which is 
already rebased to latest drm-misc(kernel 5.0). You can directly use 
that branch.



-David


On 2019年02月19日 01:01, Koenig, Christian wrote:

Am 18.02.19 um 13:07 schrieb Lionel Landwerlin:

Thanks guys :)

You mentioned that signaling out of order is illegal.
Is this illegal with regard to the vulkan spec or to the syncobj 
implementation?


David is the expert on that, but as far as I know that is forbidden 
by the vulkan spec.


I'm not finding anything in the vulkan spec that makes out of order 
signaling illegal.
That's why I came up with this test, just verifying that the 
timeline does not go backward in term of its payload.


Well we need to handle this case gracefully in the kernel, so it is 
still a good testcase.


Christian.



-Lionel

On 18/02/2019 11:01, Koenig, Christian wrote:

Hi David,

well I think Lionel is testing the invalid signal order on purpose :)

Anyway we really need to handle invalid order graceful here. E.g. 
either the same way as during CS or we abort and return an error 
message.


I think just using the same approach as during CS ist the best we 
can do.


Regards,
Christian


Am 18.02.2019 11:35 schrieb "Zhou, David(ChunMing)" 
:


Hi Lionel,

I checked your igt test case,

uint64_t points[5] = { 1, 5, 3, 7, 6 };

which is illegal signal order.

I must admit we should handle it gracefully if signal isn't 
in-order, and we shouldn't lead to deadlock.


Hi Christian,

Can we just ignore when signal point X <= timeline Y? Or just give 
a warning?


Otherwise like Lionel's unexpected use cases, which easily leads 
to deadlock.



-David


On 2019年02月15日 22:28, Lionel Landwerlin wrote:

Hi David,

Thanks a lot for point me to the tests you've added in IGT.
While adding a test with that signals fences imported into a timeline
syncobj out of order, I ran into a deadlock.
Here is the test :
https://github.com/djdeath/intel-gpu-tools/commit/1e46cf7e7bff09b78a24367ddc2314f97eb0a1b9

Trying to kill the deadlocked process I got this backtrace :


[   33.969136] [IGT] syncobj_timeline: starting subtest signal-order
[   60.452823] watchdog: BUG: soft lockup - CPU#6 stuck for 23s!
[syncobj_timelin:2021]
[   60.452826] Modules linked in: rfcomm cmac bnep binfmt_misc
nls_iso8859_1 snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_codec_generic ledtrig_audio sch_fq_codel ib_iser snd_hda_intel
rdma_cm iw_cm snd_hda_codec ib_cm snd_hda_core snd_hwdep intel_rapl
snd_pcm ib_core x86_pkg_temp_thermal intel_powerclamp configf
s coretemp iscsi_tcp snd_seq_midi libiscsi_tcp snd_seq_midi_event
libiscsi kvm_intel scsi_transport_iscsi kvm btusb snd_rawmidi irqbypass
btrtl intel_cstate intel_rapl_perf btbcm btintel bluetooth snd_seq
snd_seq_device snd_timer input_leds ecdh_generic snd soundcore mei_me
mei intel_pch_thermal mac_hid acpi_pad parp
ort_pc ppdev lp parport ip_tables x_tables autofs4 btrfs zstd_decompress
zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq
async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear
hid_generic usbhid hid i915 crct10dif_pclmul crc32_pclmul i2c_algo_bit
ghash_clmulni_intel prime_numbers
drm_kms_helper aesni_intel syscopyarea sysfillrect
[   60.452876]  sysimgblt fb_sys_fops aes_x86_64 crypto_simd sdhci_pci
cryptd drm e1000e glue_helper cqhci sdhci wmi video
[   60.452881] CPU: 6 PID: 2021 Comm: syncobj_timelin Tainted: G
U    5.0.0-rc5+ #337
[   60.452882] Hardware name:  /NUC6i7KYB, BIOS
KYSKLi70.86A.0042.2016.0929.1933 09/29/2016
[   60.452886] RIP: 0010:dma_fence_chain_walk+0x22c/0x260
[   60.452888] Code: ff e9 93 fe ff ff 48 8b 45 08 48 8b 40 18 48 85 c0
74 0c 48 89 ef e8 33 0f 58 00 84 c0 75 23 f0 41 ff 4d 00 0f 88 99 87 2f
00 <0f> 85 05 fe ff ff 4c 89 ef e8 56 ea ff ff 48 89 d8 5b 5d 41 5c 41
[   60.452888] RSP: 0018:9a5804653ca8 EFLAGS: 00010296 ORIG_RAX:
ff13
[   60.452889] RAX:  RBX: 8f5690fb2480 RCX:
8f5690fb2f00
[   60.452890] RDX: 003e3730 RSI:  RDI:
8f5690fb2180
[   60.452891] RBP: 8f5690fb2180 R08:  R09:
8f5690fb2eb0
[   60.452891] R10:  R11: 8f5660469860 R12:
8f5690fb2f68
[   60.452892] R13: 8f5690fb2f00 R14: 0003 R15:
8f5

[Bug 109561] [regression, bisected] code re-factor causing games to stutter or lock-up system

[bugzilla-daemon]

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

--- Comment #7 from Marek Olšák  ---
The fix doesn't apply to master. Also, it would be nice to get it into 19.0
before it's released. (originally it should have been released today)

-- 
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 v4 08/17] kunit: test: add support for test abort

[Brendan Higgins]

On Mon, Feb 18, 2019 at 11:52 AM Frank Rowand  wrote:
>
> On 2/14/19 1:37 PM, Brendan Higgins wrote:
> > Add support for aborting/bailing out of test cases. Needed for
> > implementing assertions.
> >
> > Signed-off-by: Brendan Higgins 
> > ---
> > Changes Since Last Version
> >  - This patch is new introducing a new cross-architecture way to abort
> >out of a test case (needed for KUNIT_ASSERT_*, see next patch for
> >details).
> >  - On a side note, this is not a complete replacement for the UML abort
> >mechanism, but covers the majority of necessary functionality. UML
> >architecture specific featurs have been dropped from the initial
> >patchset.
> > ---
> >  include/kunit/test.h |  24 +
> >  kunit/Makefile   |   3 +-
> >  kunit/test-test.c| 127 ++
> >  kunit/test.c | 208 +--
> >  4 files changed, 353 insertions(+), 9 deletions(-)
> >  create mode 100644 kunit/test-test.c
>
> < snip >
>
> > diff --git a/kunit/test.c b/kunit/test.c
> > index d18c50d5ed671..6e5244642ab07 100644
> > --- a/kunit/test.c
> > +++ b/kunit/test.c
> > @@ -6,9 +6,9 @@
> >   * Author: Brendan Higgins 
> >   */
> >
> > -#include 
> >  #include 
> > -#include 
> > +#include 
> > +#include 
> >  #include 
> >
> >  static bool kunit_get_success(struct kunit *test)
> > @@ -32,6 +32,27 @@ static void kunit_set_success(struct kunit *test, bool 
> > success)
> >   spin_unlock_irqrestore(&test->lock, flags);
> >  }
> >
> > +static bool kunit_get_death_test(struct kunit *test)
> > +{
> > + unsigned long flags;
> > + bool death_test;
> > +
> > + spin_lock_irqsave(&test->lock, flags);
> > + death_test = test->death_test;
> > + spin_unlock_irqrestore(&test->lock, flags);
> > +
> > + return death_test;
> > +}
> > +
> > +static void kunit_set_death_test(struct kunit *test, bool death_test)
> > +{
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&test->lock, flags);
> > + test->death_test = death_test;
> > + spin_unlock_irqrestore(&test->lock, flags);
> > +}
> > +
> >  static int kunit_vprintk_emit(const struct kunit *test,
> > int level,
> > const char *fmt,
> > @@ -70,13 +91,29 @@ static void kunit_fail(struct kunit *test, struct 
> > kunit_stream *stream)
> >   stream->commit(stream);
> >  }
> >
> > +static void __noreturn kunit_abort(struct kunit *test)
> > +{
> > + kunit_set_death_test(test, true);
> > +
> > + test->try_catch.throw(&test->try_catch);
> > +
> > + /*
> > +  * Throw could not abort from test.
> > +  */
> > + kunit_err(test, "Throw could not abort from test!");
> > + show_stack(NULL, NULL);
> > + BUG();
>
> kunit_abort() is what will be call as the result of an assert failure.

Yep. Does that need clarified somewhere?

>
> BUG(), which is a panic, which is crashing the system is not acceptable
> in the Linux kernel.  You will just annoy Linus if you submit this.

Sorry, I thought this was an acceptable use case since, a) this should
never be compiled in a production kernel, b) we are in a pretty bad,
unpredictable state if we get here and keep going. I think you might
have said elsewhere that you think "a" is not valid? In any case, I
can replace this with a WARN, would that be acceptable?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v4 15/17] of: unittest: migrate tests to run on KUnit

[Brendan Higgins]

On Fri, Feb 15, 2019 at 4:24 PM Frank Rowand  wrote:
>
> On 2/14/19 1:37 PM, Brendan Higgins wrote:
> > Migrate tests without any cleanup, or modifying test logic in anyway to
> > run under KUnit using the KUnit expectation and assertion API.
> >
> > Signed-off-by: Brendan Higgins 
> > ---
> >  drivers/of/Kconfig|1 +
> >  drivers/of/unittest.c | 1310 +
> >  2 files changed, 671 insertions(+), 640 deletions(-)
> >
> > diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> > index ad3fcad4d75b8..f309399deac20 100644
> > --- a/drivers/of/Kconfig
> > +++ b/drivers/of/Kconfig
> > @@ -15,6 +15,7 @@ if OF
> >  config OF_UNITTEST
> >   bool "Device Tree runtime unit tests"
> >   depends on !SPARC
> > + depends on KUNIT
> >   select IRQ_DOMAIN
> >   select OF_EARLY_FLATTREE
> >   select OF_RESOLVE
> > diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
>
> These comments are from applying the patches to 5.0-rc3.
>
> The final hunk of this patch fails to apply because it depends upon
>
>[PATCH v1 0/1] of: unittest: unflatten device tree on UML when testing.
>

Whoops, I probably should have made a note of that in the commit
description or cover letter, sorry.

> If I apply that patch then I can apply patches 15 through 17.
>
> If I apply patches 1 through 14 and boot the uml kernel then the devicetree
> unittest result is:
>
>   ### dt-test ### FAIL of_unittest_overlay_high_level():2372 
> overlay_base_root not initialized
>   ### dt-test ### end of unittest - 219 passed, 1 failed
>
> This is as expected from your previous reports, and is fixed after
> applying
>
>[PATCH v1 0/1] of: unittest: unflatten device tree on UML when testing.
>
> with the devicetree unittest result of:
>
>### dt-test ### end of unittest - 224 passed, 0 failed
>
> After adding patch 15, there are a lot of "unittest internal error" messages.

Yeah, I meant to ask you about that. I thought it was due to a change
you made, but after further examination, just now, I found it was my
fault. Sorry for not mentioning that anywhere. I will fix it in v5.

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

[Bug 109650] [amd-staging-drm-next] - Polaris 20 dc - idle power regession 3x [bisected]

[bugzilla-daemon]

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

Dieter Nützel  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

-- 
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 109650] [amd-staging-drm-next] - Polaris 20 dc - idle power regession 3x [bisected]

[bugzilla-daemon]

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

Dieter Nützel  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #3 from Dieter Nützel  ---
The relevant 2 commits are reverted.

-- 
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 109650] [amd-staging-drm-next] - Polaris 20 dc - idle power regession 3x [bisected]

[bugzilla-daemon]

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

--- Comment #2 from Alex Deucher  ---
Patch reverted.

-- 
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

linux-next: Signed-off-by missing for commit in the drm tree

[Stephen Rothwell]

Hi all,

Commits

  f180bf12ac06 ("drm/nouveau/svm: new ioctl to migrate process memory to GPU 
memory")
  5be73b690875 ("drm/nouveau/dmem: device memory helpers for SVM")

are missing a Signed-off-by from their committer.

-- 
Cheers,
Stephen Rothwell


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

[PATCH v5 5/7] gpu: ipu-v3: ipu-ic: Add support for limited range encoding

[Steve Longerbeam]

Add support for the following conversions:

- YUV full-range to YUV limited-range
- YUV limited-range to YUV full-range
- YUV limited-range to RGB full-range
- RGB full-range to YUV limited-range

The last two conversions require operating on the YUV full-range
encoding and inverse encoding coefficients, with the YUV-to-YUV
limited<->full coefficients. The formula to convert is

M_c = M_a * M_b
O_c = M_a * O_b + O_a

For calculating the RGB full-range to YUV limited-range coefficients:

[M_a, O_a] = YUV full-range to YUV limited-range coefficients.
[M_b, O_b] = RGB full-range to YUV full-range coefficients.

For calculating the YUV limited-range to RGB full-range coefficients:

[M_a, O_a] = YUV full-range to RGB full-range coefficients.
[M_b, O_b] = YUV limited-range to YUV full-range coefficients.

The calculation of [M_c, O_c] is carried out by the function
transform_coeffs().

In the future if RGB limited range encoding is required, the same
function can be used. And cascaded to create all combinations of
encoding for YUV limited/full range <-> RGB limited/full range,
passing the output coefficients from one call as the input for the
next.

For example, to create YUV full-range to RGB limited-range coefficients:

[M_a, O_a] = RGB full-range to RGB limited-range coefficients.
[M_b, O_b] = YUV full-range to RGB full-range coefficients.

and that output sent as input to create YUV limited-range to RGB
limited-range coefficients:

[M_a, O_a] = YUV full-range to RGB limited-range coefficients.
[M_b, O_b] = YUV limited-range to YUV full-range coefficients.

Signed-off-by: Steve Longerbeam 
---
 drivers/gpu/ipu-v3/ipu-ic.c | 281 +---
 1 file changed, 263 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index 012ea2239e97..861f43556df4 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -178,10 +178,10 @@ static inline void ipu_ic_write(struct ipu_ic *ic, u32 
value, unsigned offset)
 }
 
 struct ic_encode_coeff {
-   s16 coeff[3][3];/* signed 9-bit integer coefficients */
-   s16 offset[3];  /* signed 11+2-bit fixed point offset */
-   u8 scale:2; /* scale coefficients * 2^(scale-1) */
-   bool sat:1; /* saturate to (16, 235(Y) / 240(U, V)) */
+   int coeff[3][3];/* signed 9-bit integer coefficients */
+   int offset[3];  /* signed 13-bit integer offset */
+   int scale;  /* scale coefficients * 2^(scale-1) */
+   bool sat;   /* saturate to (16, 235(Y) / 240(U, V)) */
 };
 
 /*
@@ -277,6 +277,231 @@ static const struct ic_encode_coeff 
ic_encode_ycbcr2rgb_709 = {
.scale = 2,
 };
 
+/*
+ * YUV full range to YUV limited range:
+ *
+ * Y_lim  = 0.8588 * Y_full + 16
+ * Cb_lim = 0.8784 * (Cb_full - 128) + 128
+ * Cr_lim = 0.8784 * (Cr_full - 128) + 128
+ */
+static const struct ic_encode_coeff ic_encode_ycbcr_full2lim = {
+   .coeff = {
+   { 219, 0, 0 },
+   { 0, 224, 0 },
+   { 0, 0, 224 },
+   },
+   .offset = { 64, 62, 62 },
+   .scale = 1,
+};
+
+/*
+ * YUV limited range to YUV full range:
+ *
+ * Y_full  = 1.1644 * (Y_lim - 16)
+ * Cb_full = 1.1384 * (Cb_lim - 128) + 128
+ * Cr_full = 1.1384 * (Cr_lim - 128) + 128
+ */
+static const struct ic_encode_coeff ic_encode_ycbcr_lim2full = {
+   .coeff = {
+   { 149, 0, 0 },
+   { 0, 145, 0 },
+   { 0, 0, 145 },
+   },
+   .offset = { -37, -35, -35 },
+   .scale = 2,
+};
+
+/*
+ * RGB full range to RGB limited range:
+ *
+ * R_lim = 0.8588 * R_full + 16
+ * G_lim = 0.8588 * G_full + 16
+ * B_lim = 0.8588 * B_full + 16
+ */
+static const struct ic_encode_coeff
+ic_encode_rgb_full2lim __maybe_unused = {
+   .coeff = {
+   { 219, 0, 0 },
+   { 0, 219, 0 },
+   { 0, 0, 219 },
+   },
+   .offset = { 64, 64, 64 },
+   .scale = 1,
+};
+
+/*
+ * RGB limited range to RGB full range:
+ *
+ * R_full = 1.1644 * (R_lim - 16)
+ * G_full = 1.1644 * (G_lim - 16)
+ * B_full = 1.1644 * (B_lim - 16)
+ */
+static const struct ic_encode_coeff
+ic_encode_rgb_lim2full __maybe_unused = {
+   .coeff = {
+   { 149, 0, 0 },
+   { 0, 149, 0 },
+   { 0, 0, 149 },
+   },
+   .offset = { -37, -37, -37 },
+   .scale = 2,
+};
+
+/*
+ * Convert a coefficient and scale value in TPMEM register format
+ * to a signed int times 256 (fix the radix point). The TPMEM register
+ * coefficient format is a signed 9-bit value (sign bit at bit 8,
+ * mantissa = coeff * 2 ^ (8 - scale - 1)).
+ */
+static int coeff_fix(int coeff, int scale)
+{
+   if (coeff >= 256)
+   coeff -= 512;
+   if (scale == 0)
+   return DIV_ROUND_CLOSEST(coeff, 2);
+   return coeff << (scale - 1);
+}
+
+/*
+ * Convert a signed int coefficient times 256 to TPMEM register

[PATCH v5 2/7] gpu: ipu-v3: ipu-ic: Fix BT.601 coefficients

[Steve Longerbeam]

The ycbcr2rgb and inverse rgb2ycbcr tables define the BT.601 Y'CbCr
encoding coefficients.

The rgb2ycbcr table specifically describes the BT.601 encoding from
full range RGB to full range YUV. Add table comments to make this more
clear.

The ycbcr2rgb inverse table describes encoding YUV limited range to RGB
full range. To be consistent with the rgb2ycbcr table, convert this to
YUV full range to RGB full range, and adjust/expand on the comments.

The ic_csc_rgb2rgb table is just an identity matrix, so rename to
ic_encode_identity.

Fixes: 1aa8ea0d2bd5d ("gpu: ipu-v3: Add Image Converter unit")

Suggested-by: Philipp Zabel 
Signed-off-by: Steve Longerbeam 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/ipu-v3/ipu-ic.c | 63 ++---
 1 file changed, 38 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index 18816ccf600e..71a0409093e6 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -175,7 +175,7 @@ static inline void ipu_ic_write(struct ipu_ic *ic, u32 
value, unsigned offset)
writel(value, ic->priv->base + offset);
 }
 
-struct ic_csc_params {
+struct ic_encode_coeff {
s16 coeff[3][3];/* signed 9-bit integer coefficients */
s16 offset[3];  /* signed 11+2-bit fixed point offset */
u8 scale:2; /* scale coefficients * 2^(scale-1) */
@@ -183,22 +183,27 @@ struct ic_csc_params {
 };
 
 /*
- * Y = R *  .299 + G *  .587 + B *  .114;
- * U = R * -.169 + G * -.332 + B *  .500 + 128.;
- * V = R *  .500 + G * -.419 + B * -.0813 + 128.;
+ * BT.601 encoding from RGB full range to YUV full range:
+ *
+ * Y =  .2990 * R + .5870 * G + .1140 * B
+ * U = -.1687 * R - .3313 * G + .5000 * B + 128
+ * V =  .5000 * R - .4187 * G - .0813 * B + 128
  */
-static const struct ic_csc_params ic_csc_rgb2ycbcr = {
+static const struct ic_encode_coeff ic_encode_rgb2ycbcr_601 = {
.coeff = {
-   { 77, 150, 29 },
-   { 469, 427, 128 },
+   {  76, 150,  29 },
+   { 469, 428, 128 },
{ 128, 405, 491 },
},
.offset = { 0, 512, 512 },
.scale = 1,
 };
 
-/* transparent RGB->RGB matrix for graphics combining */
-static const struct ic_csc_params ic_csc_rgb2rgb = {
+/*
+ * identity matrix, used for transparent RGB->RGB graphics
+ * combining.
+ */
+static const struct ic_encode_coeff ic_encode_identity = {
.coeff = {
{ 128, 0, 0 },
{ 0, 128, 0 },
@@ -208,17 +213,25 @@ static const struct ic_csc_params ic_csc_rgb2rgb = {
 };
 
 /*
- * R = (1.164 * (Y - 16)) + (1.596 * (Cr - 128));
- * G = (1.164 * (Y - 16)) - (0.392 * (Cb - 128)) - (0.813 * (Cr - 128));
- * B = (1.164 * (Y - 16)) + (2.017 * (Cb - 128);
+ * Inverse BT.601 encoding from YUV full range to RGB full range:
+ *
+ * R = 1. * Y +  0 * (Cb - 128) + 1.4020 * (Cr - 128)
+ * G = 1. * Y -  .3442 * (Cb - 128) - 0.7142 * (Cr - 128)
+ * B = 1. * Y + 1.7720 * (Cb - 128) +  0 * (Cr - 128)
+ *
+ * equivalently (factoring out the offsets):
+ *
+ * R = 1. * Y  +  0 * Cb + 1.4020 * Cr - 179.456
+ * G = 1. * Y  -  .3442 * Cb - 0.7142 * Cr + 135.475
+ * B = 1. * Y  + 1.7720 * Cb +  0 * Cr - 226.816
  */
-static const struct ic_csc_params ic_csc_ycbcr2rgb = {
+static const struct ic_encode_coeff ic_encode_ycbcr2rgb_601 = {
.coeff = {
-   { 149, 0, 204 },
-   { 149, 462, 408 },
-   { 149, 255, 0 },
+   { 128,   0, 179 },
+   { 128, 468, 421 },
+   { 128, 226,   0 },
},
-   .offset = { -446, 266, -554 },
+   .offset = { -359, 271, -454 },
.scale = 2,
 };
 
@@ -228,7 +241,7 @@ static int init_csc(struct ipu_ic *ic,
int csc_index)
 {
struct ipu_ic_priv *priv = ic->priv;
-   const struct ic_csc_params *params;
+   const struct ic_encode_coeff *coeff;
u32 __iomem *base;
const u16 (*c)[3];
const u16 *a;
@@ -238,26 +251,26 @@ static int init_csc(struct ipu_ic *ic,
(priv->tpmem_base + ic->reg->tpmem_csc[csc_index]);
 
if (inf == IPUV3_COLORSPACE_YUV && outf == IPUV3_COLORSPACE_RGB)
-   params = &ic_csc_ycbcr2rgb;
+   coeff = &ic_encode_ycbcr2rgb_601;
else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_YUV)
-   params = &ic_csc_rgb2ycbcr;
+   coeff = &ic_encode_rgb2ycbcr_601;
else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_RGB)
-   params = &ic_csc_rgb2rgb;
+   coeff = &ic_encode_identity;
else {
dev_err(priv->ipu->dev, "Unsupported color space conversion\n");
return -EINVAL;
}
 
/* Cast to unsigned */
-   c = (const u16 (*)[3])params->coeff;
-   a = (const u16 *)params->offset;
+   c = (const u16 (*)[3])coeff->coeff;
+   a = (const

[PATCH v5 1/7] gpu: ipu-v3: ipu-ic: Fix saturation bit offset in TPMEM

[Steve Longerbeam]

The saturation bit was being set at bit 9 in the second 32-bit word
of the TPMEM CSC. This isn't correct, the saturation bit is bit 42,
which is bit 10 of the second word.

Fixes: 1aa8ea0d2bd5d ("gpu: ipu-v3: Add Image Converter unit")

Signed-off-by: Steve Longerbeam 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/ipu-v3/ipu-ic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index 594c3cbc8291..18816ccf600e 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -257,7 +257,7 @@ static int init_csc(struct ipu_ic *ic,
writel(param, base++);
 
param = ((a[0] & 0x1fe0) >> 5) | (params->scale << 8) |
-   (params->sat << 9);
+   (params->sat << 10);
writel(param, base++);
 
param = ((a[1] & 0x1f) << 27) | ((c[0][1] & 0x1ff) << 18) |
-- 
2.17.1

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

[PATCH v5 3/7] gpu: ipu-v3: ipu-ic: Fully describe colorspace conversions

[Steve Longerbeam]

Only providing the input and output RGB/YUV space to the IC task init
functions is not sufficient. To fully characterize a colorspace
conversion, the colorspace (chromaticities), Y'CbCr encoding standard,
and quantization also need to be specified.

Define a 'struct ipu_ic_colorspace' that includes all the above, and pass
the input and output ipu_ic_colorspace to the IC task init functions.

This allows to actually enforce the fact that the IC:

- can only encode to/from YUV full range (follow-up patch will remove
  this restriction).
- can only encode to/from RGB full range.
- can only encode using BT.601 standard (follow-up patch will add
  Rec.709 encoding support).
- cannot convert colorspaces from input to output, the
  input and output colorspace chromaticities must be the same.

Signed-off-by: Steve Longerbeam 
---
 drivers/gpu/ipu-v3/ipu-ic.c | 101 
 drivers/gpu/ipu-v3/ipu-image-convert.c  |  27 --
 drivers/staging/media/imx/imx-ic-prpencvf.c |  22 +++--
 include/video/imx-ipu-v3.h  |  37 +--
 4 files changed, 127 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index 71a0409093e6..02043f23f411 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -146,8 +146,10 @@ struct ipu_ic {
const struct ic_task_regoffs *reg;
const struct ic_task_bitfields *bit;
 
-   enum ipu_color_space in_cs, g_in_cs;
-   enum ipu_color_space out_cs;
+   struct ipu_ic_colorspace in_cs;
+   struct ipu_ic_colorspace g_in_cs;
+   struct ipu_ic_colorspace out_cs;
+
bool graphics;
bool rotation;
bool in_use;
@@ -236,8 +238,8 @@ static const struct ic_encode_coeff ic_encode_ycbcr2rgb_601 
= {
 };
 
 static int init_csc(struct ipu_ic *ic,
-   enum ipu_color_space inf,
-   enum ipu_color_space outf,
+   const struct ipu_ic_colorspace *in,
+   const struct ipu_ic_colorspace *out,
int csc_index)
 {
struct ipu_ic_priv *priv = ic->priv;
@@ -247,19 +249,41 @@ static int init_csc(struct ipu_ic *ic,
const u16 *a;
u32 param;
 
+   if (in->colorspace != out->colorspace) {
+   dev_err(priv->ipu->dev, "Cannot convert colorspaces\n");
+   return -ENOTSUPP;
+   }
+
+   if (out->enc != V4L2_YCBCR_ENC_601) {
+   dev_err(priv->ipu->dev, "Only BT.601 encoding supported\n");
+   return -ENOTSUPP;
+   }
+
+   if ((in->cs == IPUV3_COLORSPACE_YUV &&
+in->quant != V4L2_QUANTIZATION_FULL_RANGE) ||
+   (out->cs == IPUV3_COLORSPACE_YUV &&
+out->quant != V4L2_QUANTIZATION_FULL_RANGE)) {
+   dev_err(priv->ipu->dev, "Limited range YUV not supported\n");
+   return -ENOTSUPP;
+   }
+
+   if ((in->cs == IPUV3_COLORSPACE_RGB &&
+in->quant != V4L2_QUANTIZATION_FULL_RANGE) ||
+   (out->cs == IPUV3_COLORSPACE_RGB &&
+out->quant != V4L2_QUANTIZATION_FULL_RANGE)) {
+   dev_err(priv->ipu->dev, "Limited range RGB not supported\n");
+   return -ENOTSUPP;
+   }
+
base = (u32 __iomem *)
(priv->tpmem_base + ic->reg->tpmem_csc[csc_index]);
 
-   if (inf == IPUV3_COLORSPACE_YUV && outf == IPUV3_COLORSPACE_RGB)
+   if (in->cs == out->cs)
+   coeff = &ic_encode_identity;
+   else if (in->cs == IPUV3_COLORSPACE_YUV)
coeff = &ic_encode_ycbcr2rgb_601;
-   else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_YUV)
+   else
coeff = &ic_encode_rgb2ycbcr_601;
-   else if (inf == IPUV3_COLORSPACE_RGB && outf == IPUV3_COLORSPACE_RGB)
-   coeff = &ic_encode_identity;
-   else {
-   dev_err(priv->ipu->dev, "Unsupported color space conversion\n");
-   return -EINVAL;
-   }
 
/* Cast to unsigned */
c = (const u16 (*)[3])coeff->coeff;
@@ -357,14 +381,14 @@ void ipu_ic_task_enable(struct ipu_ic *ic)
if (ic->rotation)
ic_conf |= ic->bit->ic_conf_rot_en;
 
-   if (ic->in_cs != ic->out_cs)
+   if (ic->in_cs.cs != ic->out_cs.cs)
ic_conf |= ic->bit->ic_conf_csc1_en;
 
if (ic->graphics) {
ic_conf |= ic->bit->ic_conf_cmb_en;
ic_conf |= ic->bit->ic_conf_csc1_en;
 
-   if (ic->g_in_cs != ic->out_cs)
+   if (ic->g_in_cs.cs != ic->out_cs.cs)
ic_conf |= ic->bit->ic_conf_csc2_en;
}
 
@@ -399,7 +423,7 @@ void ipu_ic_task_disable(struct ipu_ic *ic)
 EXPORT_SYMBOL_GPL(ipu_ic_task_disable);
 
 int ipu_ic_task_graphics_init(struct ipu_ic *ic,
- enum ipu_color_space in_g_cs,
+ const struct ipu_ic_colorspace *g_in_cs,
  bool galpha_en

[PATCH v5 4/7] gpu: ipu-v3: ipu-ic: Add support for Rec.709 encoding

[Steve Longerbeam]

Add support for Rec.709 encoding and inverse encoding.

The determination of the CSC coefficients based on the input/output
colorspace parameters are moved to a new function calc_csc_coeffs().

Reported-by: Tim Harvey 
Signed-off-by: Steve Longerbeam 
---
Changes in v5:
- moved API changes to a previous patch.
- moved CSC coeff calc to new function calc_csc_coeffs().
Changes in v4:
- fix compile error.
Chnges in v3:
- none.
Changes in v2:
- only return "Unsupported YCbCr encoding" error if inf != outf,
  since if inf == outf, the identity matrix can be used. Reported
  by Tim Harvey.
---
 drivers/gpu/ipu-v3/ipu-ic.c | 120 
 1 file changed, 94 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index 02043f23f411..012ea2239e97 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -214,6 +214,23 @@ static const struct ic_encode_coeff ic_encode_identity = {
.scale = 2,
 };
 
+/*
+ * REC.709 encoding from RGB full range to YUV full range:
+ *
+ * Y =  .2126 * R + .7152 * G + .0722 * B
+ * U = -.1146 * R - .3854 * G + .5000 * B + 128
+ * V =  .5000 * R - .4542 * G - .0458 * B + 128
+ */
+static const struct ic_encode_coeff ic_encode_rgb2ycbcr_709 = {
+   .coeff = {
+   {  54, 183,  19 },
+   { 483, 413, 128 },
+   { 128, 396, 500 },
+   },
+   .offset = { 0, 512, 512 },
+   .scale = 1,
+};
+
 /*
  * Inverse BT.601 encoding from YUV full range to RGB full range:
  *
@@ -237,28 +254,42 @@ static const struct ic_encode_coeff 
ic_encode_ycbcr2rgb_601 = {
.scale = 2,
 };
 
-static int init_csc(struct ipu_ic *ic,
-   const struct ipu_ic_colorspace *in,
-   const struct ipu_ic_colorspace *out,
-   int csc_index)
+/*
+ * Inverse REC.709 encoding from YUV full range to RGB full range:
+ *
+ * R = 1. * Y +  0 * (Cb - 128) + 1.5748 * (Cr - 128)
+ * G = 1. * Y -  .1873 * (Cb - 128) -  .4681 * (Cr - 128)
+ * B = 1. * Y + 1.8556 * (Cb - 128) +  0 * (Cr - 128)
+ *
+ * equivalently (factoring out the offsets):
+ *
+ * R = 1. * Y  +  0 * Cb + 1.5748 * Cr - 201.574
+ * G = 1. * Y  -  .1873 * Cb -  .4681 * Cr +  83.891
+ * B = 1. * Y  + 1.8556 * Cb +  0 * Cr - 237.517
+ */
+static const struct ic_encode_coeff ic_encode_ycbcr2rgb_709 = {
+   .coeff = {
+   {  128,   0, 202 },
+   {  128, 488, 452 },
+   {  128, 238,   0 },
+   },
+   .offset = { -403, 168, -475 },
+   .scale = 2,
+};
+
+static int calc_csc_coeffs(struct ipu_ic_priv *priv,
+  struct ic_encode_coeff *coeff_out,
+  const struct ipu_ic_colorspace *in,
+  const struct ipu_ic_colorspace *out)
 {
-   struct ipu_ic_priv *priv = ic->priv;
-   const struct ic_encode_coeff *coeff;
-   u32 __iomem *base;
-   const u16 (*c)[3];
-   const u16 *a;
-   u32 param;
+   const struct ic_encode_coeff *encode_coeff;
+   bool inverse_encode;
 
if (in->colorspace != out->colorspace) {
dev_err(priv->ipu->dev, "Cannot convert colorspaces\n");
return -ENOTSUPP;
}
 
-   if (out->enc != V4L2_YCBCR_ENC_601) {
-   dev_err(priv->ipu->dev, "Only BT.601 encoding supported\n");
-   return -ENOTSUPP;
-   }
-
if ((in->cs == IPUV3_COLORSPACE_YUV &&
 in->quant != V4L2_QUANTIZATION_FULL_RANGE) ||
(out->cs == IPUV3_COLORSPACE_YUV &&
@@ -275,26 +306,63 @@ static int init_csc(struct ipu_ic *ic,
return -ENOTSUPP;
}
 
+   if (in->cs == out->cs) {
+   *coeff_out = ic_encode_identity;
+
+   return 0;
+   }
+
+   inverse_encode = (in->cs == IPUV3_COLORSPACE_YUV);
+
+   switch (out->enc) {
+   case V4L2_YCBCR_ENC_601:
+   encode_coeff = inverse_encode ?
+   &ic_encode_ycbcr2rgb_601 : &ic_encode_rgb2ycbcr_601;
+   break;
+   case V4L2_YCBCR_ENC_709:
+   encode_coeff = inverse_encode ?
+   &ic_encode_ycbcr2rgb_709 : &ic_encode_rgb2ycbcr_709;
+   break;
+   default:
+   dev_err(priv->ipu->dev, "Unsupported YCbCr encoding\n");
+   return -ENOTSUPP;
+   }
+
+   *coeff_out = *encode_coeff;
+
+   return 0;
+}
+
+static int init_csc(struct ipu_ic *ic,
+   const struct ipu_ic_colorspace *in,
+   const struct ipu_ic_colorspace *out,
+   int csc_index)
+{
+   struct ipu_ic_priv *priv = ic->priv;
+   struct ic_encode_coeff coeff;
+   u32 __iomem *base;
+   const u16 (*c)[3];
+   const u16 *a;
+   u32 param;
+   int ret;
+
+   ret = calc_csc_coeffs(priv, &coeff, in, out);
+   if (ret)
+   return ret;
+
base = (u32 __iomem *)

[Bug 109102] At dual monitor intel_do_flush_locked failed: Resource deadlock avoided

[bugzilla-daemon]

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

--- Comment #7 from Gert vd Kraats  ---
Created attachment 143415
  --> https://bugs.freedesktop.org/attachment.cgi?id=143415&action=edit
libdrm_ignore_deadlock

-- 
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 109102] At dual monitor intel_do_flush_locked failed: Resource deadlock avoided

[bugzilla-daemon]

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

--- Comment #6 from Gert vd Kraats  ---
Created attachment 143414
  --> https://bugs.freedesktop.org/attachment.cgi?id=143414&action=edit
fix intel_blit.c

fix error_patch2

-- 
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 109102] At dual monitor intel_do_flush_locked failed: Resource deadlock avoided

[bugzilla-daemon]

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

--- Comment #5 from Gert vd Kraats  ---
Some more investigation, understanding and adding 2 other possible fixes for
the problem.
The problem occurs at Ubuntu 18.10 only at gdm3 with wayland using dual
monitor.
It is not occuring with wayland at single monitor.
It totally doesnot occur if gdm3 is not using wayland.
At ubuntu 18.04 the same problem exists with wayland, but is not occurring so
often.

At ubuntu 18.10 with wayland and dual monitor the user session immediately
aborts, if 16 or more favorites are allocated at the dock.
For some reason wayland seems to use one extra fence register at dual monitor.
It is noticed at dual monitor, that gdm3 with wayland uses 2 calls to
clutter_stage_cogl_redraw_view for 2 logical screens for every call to
clutter_stage_cogl_redraw; gdm3 without wayland does only one call to
clutter_stage_cogl_redraw_view for 1 logical screen.

The crash occurs at intel_batchbuffer_flush. Always the last batch at such a
flush is coming from function emit_copy_blit and intelClearWithBlit at
src/mesa/drivers/dri/i915/intel_blit.c. At the call to
dri_bufmgr_check_aperture_space they indicate to use zero fence registers, but
in fact they use one. This violates the limit of 14, causing a crash at dual
monitor.
So the call to dri_bufmgr_check_aperture_space must be postponed, until the
needed fence register is added in the middle of the batch-generation and then
the batch-actions must be undone, a flush is called and batch is regenerated
again.
For this function intel_batchbuffer_emit_reset is added.
This also is done for function intel_miptree_set_alpha_to_one, although I never
saw a call of this function.
See fix error3_patch2.txt.

Another (dirty) solution is to decrement the availablity and just continue.
This gives somewhere a failure, but I could not see a failing layout.
See fix error3_patch3.txt.

-- 
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

nouveau-next 5.1 (take 2)

[Ben Skeggs]

Hey Dave,

Various fixes/cleanups, along with initial support for SVM features
utilising HMM address-space mirroring and device memory migration.
There's a lot more work to do in these areas, both in terms of
features and efficiency, but these can slowly trickle in later down
the track.

Jerome and I have corrected the issues mentioned in response to the
previous pull request, so we should be good to go!

Thanks,
Ben.

The following changes since commit c06de56121e3ac0f0f1f4a081c041654ffcacd62:

  Merge v5.0-rc7 into drm-next (2019-02-18 13:27:15 +1000)

are available in the Git repository at:

  git://github.com/skeggsb/linux linux-5.1

for you to fetch changes up to a788ade4f6e0302710f89b2a3534346df752072d:

  drm/nouveau/dmem: use dma addresses during migration copies
(2019-02-20 09:00:03 +1000)


Ben Skeggs (50):
  drm/nouveau/devinit/tu102: rename implementation from tu104
  drm/nouveau/mc/tu102: rename implementation from tu104
  drm/nouveau/mmu/tu102: rename implementation from tu104
  drm/nouveau/bar/tu102: rename implementation from tu104
  drm/nouveau/fault/tu102: rename implementation from tu104
  drm/nouveau/disp/tu102: rename implementation from tu104
  drm/nouveau/fifo/tu102: rename implementation from tu104
  drm/nouveau/ce/tu102: rename implementation from tu104
  drm/nouveau/core: define GSP subdev
  drm/nouveau/top: add function to lookup PRI address for devices
  drm/nouveau/top/gv100-: translate entry for the GSP
  drm/nouveau/gsp/gv100-: instantiate GSP falcon
  drm/nouveau/nvdec/gp102-: utilise engine PRI address from TOP
  drm/nouveau/nvdec/tu102-: instantiate NVDEC0 falcon
  drm/nouveau/sec2: utilise engine PRI address from TOP
  drm/nouveau/sec2/tu102-: instantiate SEC2 falcon
  drm/nouveau/secboot: fix missing newline in error messages
  drm/nouveau/bios/init: label existing INIT_GENERIC_CONDITION types
  drm/nouveau/bios/init: handle
INIT_GENERIC_CONDITION_ID_NO_PANEL_SEQ_DELAYS
  drm/nouveau/disp/gf119-: decode exception reason to human-readable string
  drm/nouveau: allocate kernel channel(s) before initialising display
  drm/nouveau/kms: display destroy/init/fini hooks can be static
  drm/nouveau/kms/nv04-nv4x: move a bunch of pre-nv50 page flip
code to dispnv04
  drm/nouveau/kms/nv04-nv4x: move suspend code to dispnv04 fini hook
  drm/nouveau/kms/nv04-nv4x: move resume code to dispnv04 init hook
  drm/nouveau: allow accelerated buffer moves even when gr isn't present
  drm/nouveau/gr/gf100-: move fecs set_watchdog_timeout method
into a function
  drm/nouveau/gr/gf100-: move fecs discover_image_size into a function
  drm/nouveau/gr/gf100-: move fecs discover_zcull_image_size into a function
  drm/nouveau/gr/gf100-: move fecs discover_pm_image_size into a function
  drm/nouveau/gr/gf100-: move fecs elpg setup into functions
  drm/nouveau/gr/gf100-: remove some unnecessary reg writes
  drm/nouveau/gr/gf100-: move fecs bind_pointer into a function
  drm/nouveau/gr/gf100-: store fecs/gpccs falcon pointers in substructures
  drm/nouveau/mmu/gf100-: make mmu invalidate function more general
  drm/nouveau/mmu/gf100-: virtualise setting pdb base address for
invalidation
  drm/nouveau/gr/gf100-: expose fecs methods for pausing ctxsw
  drm/nouveau/gr/gf100-: expose method to determine current context
  drm/nouveau/mmu: support initialisation of client-managed address-spaces
  drm/nouveau/mmu: store mapped flag separately from memory pointer
  drm/nouveau/mmu: add a privileged method to directly manage PTEs
  drm/nouveau/mmu/gp100-: add privileged methods for fault replay/cancel
  drm/nouveau/mmu/gp100-: support vmms with gcc/tex replayable
faults enabled
  drm/nouveau/fault/gp100: expose MaxwellFaultBufferA
  drm/nouveau/fault/gv100-: expose VoltaFaultBufferA
  drm/nouveau: prepare for enabling svm with existing userspace interfaces
  drm/nouveau/svm: initial support for shared virtual memory
  drm/nouveau/dmem: extend copy function to allow direct use of
physical addresses
  drm/nouveau/dmem: use physical vram addresses during migration copies
  drm/nouveau/dmem: use dma addresses during migration copies

Colin Ian King (5):
  drm/nouveau/bios/dp: make array vsoff static, shrinks object size
  drm/nouveau/bios/ramcfg: fix missing parentheses when calculating RON
  drm/nouveau/pmu: don't print reply values if exec is false
  drm/nouveau: fix missing break in switch statement
  drm/nouveau/falcon: fix a few indentation issues

Gustavo A. R. Silva (1):
  drm/nouveau: mark expected switch fall-through

Ilia Mirkin (1):
  drm/nouveau/volt/gf117: fix speedo readout register

Jérôme Glisse (2):
  drm/nouveau/dmem: device memory helpers for SVM
  drm/nouveau/svm: new ioctl to migrate process memory 

Re: [RFC v4 02/17] kunit: test: add test resource management API

[Brendan Higgins]

On Fri, Feb 15, 2019 at 1:01 PM Stephen Boyd  wrote:
>
> Quoting Brendan Higgins (2019-02-14 13:37:14)
> > @@ -104,6 +167,7 @@ struct kunit {
> > const char *name; /* Read only after initialization! */
> > spinlock_t lock; /* Gaurds all mutable test state. */
> > bool success; /* Protected by lock. */
> > +   struct list_head resources; /* Protected by lock. */
> > void (*vprintk)(const struct kunit *test,
> > const char *level,
> > struct va_format *vaf);
> > @@ -127,6 +191,51 @@ int kunit_run_tests(struct kunit_module *module);
> > } \
> > late_initcall(module_kunit_init##module)
> >
> > +/**
> > + * kunit_alloc_resource() - Allocates a *test managed resource*.
> > + * @test: The test context object.
> > + * @init: a user supplied function to initialize the resource.
> > + * @free: a user supplied function to free the resource.
> > + * @context: for the user to pass in arbitrary data.
>
> Nitpick: "pass in arbitrary data to the init function"? Maybe that
> provides some more clarity.

I think that makes sense. Will fix in next revision.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC v4 10/17] kunit: test: add test managed resource tests

[Brendan Higgins]

On Fri, Feb 15, 2019 at 12:54 PM Stephen Boyd  wrote:
>
> Quoting Brendan Higgins (2019-02-14 13:37:22)
> > diff --git a/kunit/test-test.c b/kunit/test-test.c
> > index 0b4ad6690310d..bb34431398526 100644
> > --- a/kunit/test-test.c
> > +++ b/kunit/test-test.c
> [...]
> > +
> > +#define KUNIT_RESOURCE_NUM 5
> > +static void kunit_resource_test_cleanup_resources(struct kunit *test)
> > +{
> > +   int i;
> > +   struct kunit_test_resource_context *ctx = test->priv;
> > +   struct kunit_resource *resources[KUNIT_RESOURCE_NUM];
> > +
> > +   for (i = 0; i < KUNIT_RESOURCE_NUM; i++) {
>
> Nitpick: This could use ARRAY_SIZE(resources) and then the #define could
> be dropped.

Noted. Will fix in next revision.

>
> > +   resources[i] = kunit_alloc_resource(&ctx->test,
> > +   fake_resource_init,
> > +   fake_resource_free,
> > +   ctx);
> > +   }
> > +
> > +   kunit_cleanup(&ctx->test);
> > +
> > +   KUNIT_EXPECT_TRUE(test, list_empty(&ctx->test.resources));
> > +}
> > +
> [...]
> > +
> > +static struct kunit_case kunit_resource_test_cases[] = {
>
> Can these arrays be const?

There is some private mutable state inside of `struct kunit_case` that
would be kind of annoying to pull out; I don't think it would make it
cleaner.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] drm/msm: msm-next for 5.1

[Rob Clark]

Hi Dave,

Reasonably smaller this time around, but still rockin the negative diffstat.

On the display side, cleanups and fixes to enabled modifiers
(QCOM_COMPRESSED).  And otherwise mostly misc fixes all around.

There is a6xx GMU reset support pending, but looks like a bit more
discussion about dt bindings needed, so holding that back until 5.2.



The following changes since commit f91168f48556486743392b8838e20afbd84b7b7a:

  Merge tag 'drm-misc-next-2019-01-23' of
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2019-01-24
20:02:12 +1000)

are available in the Git repository at:

  https://gitlab.freedesktop.org/drm/msm.git

for you to fetch changes up to 860433ed2a55dcd18f36c61b3c4fdb12dc76c869:

  drm/msm: Truncate the buffer object name if the copy from user
failed (2019-02-19 14:54:08 -0500)


Arnd Bergmann (2):
  drm/msm/gpu: fix building without debugfs
  drm/msm: avoid unused function warning

Bruce Wang (1):
  drm/msm/dpu: remove struct encoder_kickoff_params

Chandan Uddaraju (1):
  drm: add definitions for DP Audio/Video compliance tests

Dan Carpenter (1):
  drm/msm: fix an error code in the ioctl

Douglas Anderson (1):
  drm/msm: Fix A6XX support for opp-level

Fritz Koenig (5):
  drm/msm/dpu: Remove unused format tables.
  drm/msm/dpu: Use simple list for plane format init
  drm/msm/dpu: Plane helper for modifiers
  drm/msm/dpu: Initialize supported modifiers
  drm/msm/dpu: Correct initialization of modifiers

Jayant Shekhar (3):
  drm/msm/dpu: Remove unused enum and comment from dpu mdss
  drm/msm/dpu: Cleanup dpu plane interface
  drm/msm/dpu: Clean up dpu hw interrupts

Jeykumar Sankaran (13):
  drm/msm/dpu: avoid tracking reservations in RM
  drm/msm/dpu: remove dev from RM
  drm/msm/dpu: clean up dpu_rm_check_property_topctl declaration
  drm/msm/dpu: remove encoder from crtc mixer struct
  drm/msm/dpu: clean up redundant hw type
  drm/msm/dpu: maintain hw_mdp in kms
  drm/msm/dpu: fix documentation for intf_type
  drm/msm/dpu: handle failures while initializing displays
  drm/msm/dpu: use kthread_destroy_worker to release msm workers
  drm/msm/dpu: use msm wq for vblank events
  drm/msm/dpu: use msm wq for idle power collapse
  drm/msm: clean up display thread
  drm/msm: subclass work object for vblank events

Joe Perches (1):
  drm/msm: Add __printf verification

Jordan Crouse (5):
  drm/msm/gpu: Remove hardcoded interrupt name
  drm/msm: drop interrupt-names
  dt-bindings: drm/msm/a6xx: Document GMU and update GPU bindings
  dt-bindings: drm/msm/a6xx: Document GMU bindings
  drm/msm: Truncate the buffer object name if the copy from user failed

Kristian H. Kristensen (1):
  drm/msm: Unblock writer if reader closes file

Rob Clark (2):
  drm/msm: honor GPU_READONLY flag
  MAINTAINERS: update entry for drm/msm

Stephen Boyd (1):
  drm/msm/dpu: Convert to a chained irq chip

Tanmay Shah (1):
  drm/msm/dpu: Change definition of RGB565 and BGR565

 .../devicetree/bindings/display/msm/gmu.txt|  59 
 .../devicetree/bindings/display/msm/gpu.txt|  43 ++-
 MAINTAINERS|   3 +-
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c  |   2 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.c|   1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   |   9 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h   |   2 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c|  32 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h|  13 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h   |   3 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   |   5 +-
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   |   5 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c|  37 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.h|  14 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |   4 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |  19 +-
 .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog_format.h  | 220 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c  |  44 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h  |  44 ---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h|   7 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h|   1 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|  65 +++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c   |  36 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c  |  77 +++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h  |  27 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 325 +++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h |  28 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h  |  28 +-
 drivers/gpu/drm/msm/msm_drv.c  | 126 +++-
 drivers/gpu/drm/msm/msm_drv.h   

Re: [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools

[Dylan Baker]

Quoting Emil Velikov (2019-02-19 08:51:18)
> On Tue, 19 Feb 2019 at 15:36, Dylan Baker  wrote:
> >
> > Quoting Daniel Vetter (2019-02-19 07:20:12)
> > > On Tue, Feb 19, 2019 at 3:02 PM Eric Engestrom  
> > > wrote:
> > > >
> > > > On Tuesday, 2019-02-19 13:53:25 +0100, Daniel Vetter wrote:
> > > > > On Tue, Feb 19, 2019 at 12:57 PM Emil Velikov 
> > > > >  wrote:
> > > > > >
> > > > > > On Mon, 18 Feb 2019 at 17:42, Eric Engestrom 
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Thursday, 2018-12-20 11:53:11 -0800, Dylan Baker wrote:
> > > > > > > > Quoting Eric Engestrom (2018-12-19 08:23:40)
> > > > > > > > > Signed-off-by: Eric Engestrom 
> > > > > > > > > ---
> > > > > > > > >  RELEASING | 27 ---
> > > > > > > > >  1 file changed, 8 insertions(+), 19 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/RELEASING b/RELEASING
> > > > > > > > > index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
> > > > > > > > > --- a/RELEASING
> > > > > > > > > +++ b/RELEASING
> > > > > > > > > @@ -9,25 +9,14 @@ However, this is up to whoever is driving 
> > > > > > > > > the feature in question.
> > > > > > > > >
> > > > > > > > >  Follow these steps to release a new version of libdrm:
> > > > > > > > >
> > > > > > > > > -  1) Bump the version number in configure.ac and 
> > > > > > > > > meson.build. We seem
> > > > > > > > > - to have settled for 2.4.x as the versioning scheme for 
> > > > > > > > > libdrm, so
> > > > > > > > > - just bump the  micro version.
> > > > > > > > > -
> > > > > > > > > -  2) Run autoconf and then re-run ./configure so the build 
> > > > > > > > > system
> > > > > > > > > - picks up the new version number.
> > > > > > > > > -
> > > > > > > > > -  3) Verify that the code passes "make distcheck".  Running 
> > > > > > > > > "make
> > > > > > > > > - distcheck" should result in no warnings or errors and 
> > > > > > > > > end with a
> > > > > > > > > - message of the form:
> > > > > > > > > -
> > > > > > > > > -   =
> > > > > > > > > -   libdrm-X.Y.Z archives ready for distribution:
> > > > > > > > > -   libdrm-X.Y.Z.tar.gz
> > > > > > > > > -   libdrm-X.Y.Z.tar.bz2
> > > > > > > > > -   =
> > > > > > > > > -
> > > > > > > > > - Make sure that the version number reported by distcheck 
> > > > > > > > > and in
> > > > > > > > > - the tarball names matches the number you bumped to in 
> > > > > > > > > configure.ac.
> > > > > > > > > +  1) Bump the version number in meson.build. We seem to have 
> > > > > > > > > settled for
> > > > > > > > > + 2.4.x as the versioning scheme for libdrm, so just bump 
> > > > > > > > > the micro
> > > > > > > > > + version.
> > > > > > > > > +
> > > > > > > > > +  2) Run `ninja -C builddir/ dist` to generate the tarballs.
> > > > > > > > > + Make sure that the version number of the tarball name in
> > > > > > > > > + builddir/meson-dist/ matches the number you bumped to. 
> > > > > > > > > Move that
> > > > > > > > > + tarball to the libdrm repo root for the release script 
> > > > > > > > > to pick up.
> > > > > > > > >
> > > > > > > > >4) Push the updated master branch with the bumped version 
> > > > > > > > > number:
> > > > > > >
> > > > > > > Just noticed I forgot to decrement item 4 & 5 :]
> > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Cheers,
> > > > > > > > >   Eric
> > > > > > > > >
> > > > > > > >
> > > > > > > > Acked-by: Dylan Baker 
> > > > > > > >
> > > > > > > > But you should probably get someone other than just me to look 
> > > > > > > > at this.
> > > > > > >
> > > > > > > There is no "libdrm maintainer", which makes everyone a libdrm
> > > > > > > maintainer :]
> > > > > > >
> > > > > > > If nobody object, I'll push this in a few weeks (there's really 
> > > > > > > no rush,
> > > > > > > but I want to make that move at some point, we have no reason to 
> > > > > > > stay
> > > > > > > dependant on autotools now that we have better tools).
> > > > > >
> > > > > > Must admit I'm not the biggest fan. I can see this being cool for 
> > > > > > the
> > > > > > maintainer, if autotools was was present on their system.
> > > > > > The unfortunate reality is - it's there for the foreseeable future.
> > > > > > If anything it makes it more annoying for those using 
> > > > > > autotools/make -
> > > > > > regardless if they like doing so or not.
> > > > > >
> > > > > > So that's a nack from me :-\
> > > > >
> > > > > Not really following what's the downside is of using meson to cut the
> > > > > release tarball? Resulting tarball should still be able to build fine
> > > > > with automake. If the concern is that automake will bitrot, then I
> > > > > think a much better solution is to add a few automake targets to the
> > > > > gitlab ci autobuilder stuff. That's what we've done for igt at least,
> > > > > works neatly.
> > > >
> m

Re: [EARLY RFC][PATCH 0/4] ION per heap devices

[John Stultz]

On Tue, Feb 19, 2019 at 1:25 PM Laura Abbott  wrote:
>
> On 2/15/19 12:24 PM, John Stultz wrote:
> > This is a *very early RFC* (it builds, that's all I'll say :)
> > but I wanted to share it to get some initial feedback before I
> > go down the rabit hole of trying to adapt the Android userland
> > code to get this fully validated.
> >
> > This patchset tries to implement the per-heap devices for ION.
> > The main benefit is that it avoids multiplexing heap operations
> > through the /dev/ion interface, and allows for each heap to have
> > its own permissions/sepolicy rules.
> >
> > Feedback would be greatly appreciated!
> > thanks
> > -john
> >
> > Cc: Laura Abbott 
> > Cc: Sumit Semwal 
> > Cc: Liam Mark 
> > Cc: Brian Starkey 
> > Cc: Andrew F. Davis 
> > Cc: Alistair Strachan 
> > Cc: dri-devel@lists.freedesktop.org
> >
> > John Stultz (4):
> >ion: Add ION_VERSION ioctl
> >ion: Initial hack to create per heap devices
> >ion: Add HEAP_INFO ioctl to be able to fetch heap type
> >ion: Make "legacy" /dev/ion support optional
> >
> >   drivers/staging/android/ion/Kconfig |  7 +++
> >   drivers/staging/android/ion/ion-ioctl.c | 80 
> > +
> >   drivers/staging/android/ion/ion.c   | 51 -
> >   drivers/staging/android/ion/ion.h   |  6 +++
> >   drivers/staging/android/uapi/ion.h  | 57 +++
> >   5 files changed, 191 insertions(+), 10 deletions(-)
> >
>
> So it occurs to me if this is going to be a new ABI
> all together maybe we should just declare a new allocation ioctl
> to be used with it. We can keep the old ioctls around
> for legacy use cases and maybe eventually delete them
> and just use the new allocation ioctl with the new
> split heaps.

So... I did add ION_IOC_HEAP_ALLOC in my patchset.  Or are you
suggesting we use a new ION_IOC_MAGIC value for the new ABI? Or some
larger rework?

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

Re: [EARLY RFC][PATCH 0/4] ION per heap devices

[Laura Abbott]

On 2/19/19 1:30 PM, Andrew F. Davis wrote:

On 2/19/19 3:25 PM, Laura Abbott wrote:

On 2/15/19 12:24 PM, John Stultz wrote:

This is a *very early RFC* (it builds, that's all I'll say :)
but I wanted to share it to get some initial feedback before I
go down the rabit hole of trying to adapt the Android userland
code to get this fully validated.

This patchset tries to implement the per-heap devices for ION.
The main benefit is that it avoids multiplexing heap operations
through the /dev/ion interface, and allows for each heap to have
its own permissions/sepolicy rules.

Feedback would be greatly appreciated!
thanks
-john

Cc: Laura Abbott 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Brian Starkey 
Cc: Andrew F. Davis 
Cc: Alistair Strachan 
Cc: dri-devel@lists.freedesktop.org

John Stultz (4):
    ion: Add ION_VERSION ioctl
    ion: Initial hack to create per heap devices
    ion: Add HEAP_INFO ioctl to be able to fetch heap type
    ion: Make "legacy" /dev/ion support optional

   drivers/staging/android/ion/Kconfig |  7 +++
   drivers/staging/android/ion/ion-ioctl.c | 80
+
   drivers/staging/android/ion/ion.c   | 51 -
   drivers/staging/android/ion/ion.h   |  6 +++
   drivers/staging/android/uapi/ion.h  | 57 +++
   5 files changed, 191 insertions(+), 10 deletions(-)



So it occurs to me if this is going to be a new ABI
all together maybe we should just declare a new allocation ioctl
to be used with it. We can keep the old ioctls around
for legacy use cases and maybe eventually delete them
and just use the new allocation ioctl with the new
split heaps.



Why keep the old ones, this is staging, there are no legacy users (that
matter to kernel).. Slowing progress for the sake of backwards compat
with staging just slows the de-staging down.



I think we just fundamentally disagree here. I don't see keeping
legacy users as slowing anything down. We're still getting
the new ABI that we actually like and we get the chance to easily
go back and test. Having a non broken ABI makes it much
easier to do testing and validation and comparison. We can remove
the last ABI before we move it out of staging.

Thanks,
Laura


Andrew


Thanks,
Laura


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

Re: [EARLY RFC][PATCH 3/4] ion: Add HEAP_INFO ioctl to be able to fetch heap type

[John Stultz]

On Tue, Feb 19, 2019 at 1:46 PM Laura Abbott  wrote:
>
> On 2/19/19 1:39 PM, Andrew F. Davis wrote:
> > On 2/19/19 3:13 PM, Laura Abbott wrote:
> >> On 2/15/19 12:24 PM, John Stultz wrote:
> >>> The per-device heaps don't support HEAP_QUERY ioctl, since
> >>> the name is provided in the devnode path and the heapid isn't
> >>> useful with the new interface (one uses the fd of heapdevice).
> >>>
> >>> But, one missing bit of functionality is a way to find the
> >>> heap type. So provide a HEAP_INFO ioctl which exposes the
> >>> heap type out so there is the potential for some sort of
> >>> dynamic heap matching/discovery.
> >>>
> >>> Most likely this IOCTL will be useful when extended to allow
> >>> some sort of opaque constraint bitfield to be shared so userland
> >>> can match heaps with devices in a fully dynamic way.
> >>>
> >>
> >> We've been waiting on the constraint solving for a while and
> >> it's never really happened :(
> >>
> >
> > Most likely there will never be a one-size-fits-all solution here. So
> > allowing for an extensible ABI that permits new information to be
> > exported as needed will be important.
> >
> >> It certainly works but I'm concerned about adding this and
> >> then finding (yet again) that it doesn't work. We're
> >> getting the heap name now but do we lose anything if we
> >> don't expose it as part of the ABI?
> >>
> >
> > We can always add more ioctls, we cant go back and remove the old ones
> > if we make them too clunky and have to remove something they expose. A
> > simple starting ABI seems to make the most sense here. Even heap type
> > doesn't look like a good thing to expose, it is just as static and
> > one-off as heap name, I don't see it having all that much use :/
> >
>
> That's my point though, why are we adding this ioctl now if we
> don't have a good idea of its use case or why we want the heap
> type exposed? If we come up with a good use later we can
> add the ioctl then with better requirements.

Ok. I think we three are in agreement here.  Best to drop this bit and
leave it till someone has a clear need/use.

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

Re: [EARLY RFC][PATCH 3/4] ion: Add HEAP_INFO ioctl to be able to fetch heap type

[John Stultz]

On Tue, Feb 19, 2019 at 1:13 PM Laura Abbott  wrote:
>
> On 2/15/19 12:24 PM, John Stultz wrote:
> > The per-device heaps don't support HEAP_QUERY ioctl, since
> > the name is provided in the devnode path and the heapid isn't
> > useful with the new interface (one uses the fd of heapdevice).
> >
> > But, one missing bit of functionality is a way to find the
> > heap type. So provide a HEAP_INFO ioctl which exposes the
> > heap type out so there is the potential for some sort of
> > dynamic heap matching/discovery.
> >
> > Most likely this IOCTL will be useful when extended to allow
> > some sort of opaque constraint bitfield to be shared so userland
> > can match heaps with devices in a fully dynamic way.
> >
>
> We've been waiting on the constraint solving for a while and
> it's never really happened :(
>

Yea. I'm not trying to open that up again.

> It certainly works but I'm concerned about adding this and
> then finding (yet again) that it doesn't work. We're
> getting the heap name now but do we lose anything if we
> don't expose it as part of the ABI?

Right. So all we're exporting in this patch is the heap_type. This was
somewhat of an afterthought for me, as practically, I suspect the
gralloc users of ion will know which heap they want by name, and won't
do any sort of dynamic heap finding.

That said, ion's current API provides the QUERY interface which gives
you a list of heap ids/names/types, so if you wanted something that on
any random system was able to find a ION_HEAP_TYPE_DMA heap and use
it, you could.

So this HEAP_INFO ioctl provides a way to do the same. That's it.

That said, I could envision the ioctl to be extended (via the reserved
values) to provide some sort of constraint cookie to allow for
constraint solving, but that's still a unsolved issue at large.

Given the handwaving at the constraints part, and that the heap type
is a pretty coarse grained enum (only 6 types, as of now - one being
catchall "custom"), I'm fine holding off on this bit unless folks
really see it as valuable.

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

Re: [EARLY RFC][PATCH 3/4] ion: Add HEAP_INFO ioctl to be able to fetch heap type

[Laura Abbott]

On 2/19/19 1:39 PM, Andrew F. Davis wrote:

On 2/19/19 3:13 PM, Laura Abbott wrote:

On 2/15/19 12:24 PM, John Stultz wrote:

The per-device heaps don't support HEAP_QUERY ioctl, since
the name is provided in the devnode path and the heapid isn't
useful with the new interface (one uses the fd of heapdevice).

But, one missing bit of functionality is a way to find the
heap type. So provide a HEAP_INFO ioctl which exposes the
heap type out so there is the potential for some sort of
dynamic heap matching/discovery.

Most likely this IOCTL will be useful when extended to allow
some sort of opaque constraint bitfield to be shared so userland
can match heaps with devices in a fully dynamic way.



We've been waiting on the constraint solving for a while and
it's never really happened :(



Most likely there will never be a one-size-fits-all solution here. So
allowing for an extensible ABI that permits new information to be
exported as needed will be important.


It certainly works but I'm concerned about adding this and
then finding (yet again) that it doesn't work. We're
getting the heap name now but do we lose anything if we
don't expose it as part of the ABI?



We can always add more ioctls, we cant go back and remove the old ones
if we make them too clunky and have to remove something they expose. A
simple starting ABI seems to make the most sense here. Even heap type
doesn't look like a good thing to expose, it is just as static and
one-off as heap name, I don't see it having all that much use :/



That's my point though, why are we adding this ioctl now if we
don't have a good idea of its use case or why we want the heap
type exposed? If we come up with a good use later we can
add the ioctl then with better requirements.


Andrew


Cc: Laura Abbott 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Brian Starkey 
Cc: Andrew F. Davis 
Cc: Alistair Strachan 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
---
   drivers/staging/android/ion/ion-ioctl.c | 12 
   drivers/staging/android/uapi/ion.h  | 22 ++
   2 files changed, 34 insertions(+)

diff --git a/drivers/staging/android/ion/ion-ioctl.c
b/drivers/staging/android/ion/ion-ioctl.c
index ea8d263..6db5969 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -14,6 +14,7 @@ union ion_ioctl_arg {
   struct ion_allocation_data allocation;
   struct ion_heap_allocation_data heap_allocation;
   struct ion_heap_query query;
+    struct ion_heap_info heap_info;
   u32 version;
   };
   @@ -149,6 +150,17 @@ long ion_heap_ioctl(struct file *filp, unsigned
int cmd, unsigned long arg)
     break;
   }
+    case ION_IOC_HEAP_INFO:
+    {
+    struct miscdevice *miscdev = filp->private_data;
+    struct ion_heap *heap;
+
+    heap = container_of(miscdev, struct ion_heap, heap_dev);
+
+    data.heap_info.type = heap->type;
+
+    break;
+    }
   case ION_IOC_VERSION:
   data.version = ION_VERSION;
   break;
diff --git a/drivers/staging/android/uapi/ion.h
b/drivers/staging/android/uapi/ion.h
index 20db09f..1b3ca1e 100644
--- a/drivers/staging/android/uapi/ion.h
+++ b/drivers/staging/android/uapi/ion.h
@@ -111,6 +111,19 @@ struct ion_heap_data {
   };
     /**
+ * struct ion_heap_info - Info about the heap
+ *
+ */
+struct ion_heap_info {
+    __u32 type;
+    __u32 reserved0;
+    __u32 reserved1;
+    __u32 reserved2;
+    __u32 reserved3;
+    __u32 reserved4;
+};
+
+/**
    * struct ion_heap_query - collection of data about all heaps
    * @cnt - total number of heaps to be copied
    * @heaps - buffer to copy heap data
@@ -159,4 +172,13 @@ struct ion_heap_query {
   #define ION_IOC_HEAP_ALLOC    _IOWR(ION_IOC_MAGIC, 10, \
     struct ion_heap_allocation_data)
   +/**
+ * DOC: ION_IOC_HEAP_INFO - allocate memory from heap
+ *
+ * Takes an ion_heap_query structure and populates information about
+ * available Ion heaps.
+ */
+#define ION_IOC_HEAP_INFO    _IOWR(ION_IOC_MAGIC, 11, \
+  struct ion_heap_allocation_data)
+
   #endif /* _UAPI_LINUX_ION_H */





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

Re: [EARLY RFC][PATCH 3/4] ion: Add HEAP_INFO ioctl to be able to fetch heap type

[Andrew F. Davis]

On 2/19/19 3:13 PM, Laura Abbott wrote:
> On 2/15/19 12:24 PM, John Stultz wrote:
>> The per-device heaps don't support HEAP_QUERY ioctl, since
>> the name is provided in the devnode path and the heapid isn't
>> useful with the new interface (one uses the fd of heapdevice).
>>
>> But, one missing bit of functionality is a way to find the
>> heap type. So provide a HEAP_INFO ioctl which exposes the
>> heap type out so there is the potential for some sort of
>> dynamic heap matching/discovery.
>>
>> Most likely this IOCTL will be useful when extended to allow
>> some sort of opaque constraint bitfield to be shared so userland
>> can match heaps with devices in a fully dynamic way.
>>
> 
> We've been waiting on the constraint solving for a while and
> it's never really happened :(
> 

Most likely there will never be a one-size-fits-all solution here. So
allowing for an extensible ABI that permits new information to be
exported as needed will be important.

> It certainly works but I'm concerned about adding this and
> then finding (yet again) that it doesn't work. We're
> getting the heap name now but do we lose anything if we
> don't expose it as part of the ABI?
> 

We can always add more ioctls, we cant go back and remove the old ones
if we make them too clunky and have to remove something they expose. A
simple starting ABI seems to make the most sense here. Even heap type
doesn't look like a good thing to expose, it is just as static and
one-off as heap name, I don't see it having all that much use :/

Andrew

>> Cc: Laura Abbott 
>> Cc: Sumit Semwal 
>> Cc: Liam Mark 
>> Cc: Brian Starkey 
>> Cc: Andrew F. Davis 
>> Cc: Alistair Strachan 
>> Cc: dri-devel@lists.freedesktop.org
>> Signed-off-by: John Stultz 
>> ---
>>   drivers/staging/android/ion/ion-ioctl.c | 12 
>>   drivers/staging/android/uapi/ion.h  | 22 ++
>>   2 files changed, 34 insertions(+)
>>
>> diff --git a/drivers/staging/android/ion/ion-ioctl.c
>> b/drivers/staging/android/ion/ion-ioctl.c
>> index ea8d263..6db5969 100644
>> --- a/drivers/staging/android/ion/ion-ioctl.c
>> +++ b/drivers/staging/android/ion/ion-ioctl.c
>> @@ -14,6 +14,7 @@ union ion_ioctl_arg {
>>   struct ion_allocation_data allocation;
>>   struct ion_heap_allocation_data heap_allocation;
>>   struct ion_heap_query query;
>> +    struct ion_heap_info heap_info;
>>   u32 version;
>>   };
>>   @@ -149,6 +150,17 @@ long ion_heap_ioctl(struct file *filp, unsigned
>> int cmd, unsigned long arg)
>>     break;
>>   }
>> +    case ION_IOC_HEAP_INFO:
>> +    {
>> +    struct miscdevice *miscdev = filp->private_data;
>> +    struct ion_heap *heap;
>> +
>> +    heap = container_of(miscdev, struct ion_heap, heap_dev);
>> +
>> +    data.heap_info.type = heap->type;
>> +
>> +    break;
>> +    }
>>   case ION_IOC_VERSION:
>>   data.version = ION_VERSION;
>>   break;
>> diff --git a/drivers/staging/android/uapi/ion.h
>> b/drivers/staging/android/uapi/ion.h
>> index 20db09f..1b3ca1e 100644
>> --- a/drivers/staging/android/uapi/ion.h
>> +++ b/drivers/staging/android/uapi/ion.h
>> @@ -111,6 +111,19 @@ struct ion_heap_data {
>>   };
>>     /**
>> + * struct ion_heap_info - Info about the heap
>> + *
>> + */
>> +struct ion_heap_info {
>> +    __u32 type;
>> +    __u32 reserved0;
>> +    __u32 reserved1;
>> +    __u32 reserved2;
>> +    __u32 reserved3;
>> +    __u32 reserved4;
>> +};
>> +
>> +/**
>>    * struct ion_heap_query - collection of data about all heaps
>>    * @cnt - total number of heaps to be copied
>>    * @heaps - buffer to copy heap data
>> @@ -159,4 +172,13 @@ struct ion_heap_query {
>>   #define ION_IOC_HEAP_ALLOC    _IOWR(ION_IOC_MAGIC, 10, \
>>     struct ion_heap_allocation_data)
>>   +/**
>> + * DOC: ION_IOC_HEAP_INFO - allocate memory from heap
>> + *
>> + * Takes an ion_heap_query structure and populates information about
>> + * available Ion heaps.
>> + */
>> +#define ION_IOC_HEAP_INFO    _IOWR(ION_IOC_MAGIC, 11, \
>> +  struct ion_heap_allocation_data)
>> +
>>   #endif /* _UAPI_LINUX_ION_H */
>>
> 
___
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

[Laura Abbott]

On 1/24/19 8:44 AM, Brian Starkey wrote:

On Thu, Jan 24, 2019 at 10:04:46AM -0600, Andrew F. Davis wrote:

On 1/23/19 11:11 AM, Brian Starkey wrote:


[snip]



I'm very new to all this, so any pointers to history in this area are
appreciated.



[snip]




In case you didn't come across it already, the effort which seems to
have gained the most "air-time" recently is
https://github.com/cubanismo/allocator, which is still a userspace
module (perhaps some concepts from there could go into the kernel?),
but makes some attempts at generic constraint solving. It's also not
really moving anywhere at the moment.



Very interesting, I'm going to have to stare at this for a bit.


In which case, some reading material that might be of interest :-)

https://www.x.org/wiki/Events/XDC2016/Program/Unix_Device_Memory_Allocation.pdf
https://www.x.org/wiki/Events/XDC2017/jones_allocator.pdf
https://lists.freedesktop.org/archives/mesa-dev/2017-November/177632.html

-Brian



In some respects this is more a question of "what is the purpose
of Ion". Once upon a time, Ion was going to do constraint solving
but that never really happened and I figured Ion would get deprecated.
People keep coming out of the woodwork with new uses for Ion so
its stuck around. This is why I've primarily focused on Ion as a
framework for exposing available memory types to userspace and leave
the constraint solving to someone else, since that's what most
users seem to want out of Ion ("I know I want memory type X please
give it to me"). That's not to say that this was a perfect or
even the correct approach, just what made the most sense based
on users.

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

Re: [EARLY RFC][PATCH 2/4] ion: Initial hack to create per heap devices

[John Stultz]

On Tue, Feb 19, 2019 at 1:17 PM Laura Abbott  wrote:
>
> On 2/15/19 12:24 PM, John Stultz wrote:
> > One of the issues w/ the /dev/ion interface is that we have to
> > provide the complexity of a heap query interface and we end up
> > multiplexing all the heap access through that one interface via
> > a bit mask (which currently limits the heaps to 32).
> >
> > There has been a long running todo to provide per-heap devices
> > which would make the heap discovery/query interface "ls", and
> > would allow for different heaps to have different permisisons
> > and sepolicy rules.
> >
> > TODOs:
> > * Android doesn't use udev so "ion_heaps/%s" names don't
> >automatically create a /dev/ subdir. I need to rework
> >from miscdev to creating a proper device class and add
> >a "subsystem" entry for the DeviceHandler to match with
> >
> > * Each CMA region is exposed via a separate heap, not sure
> >if this is desired or not, and we may need to improve the
> >naming.
> >
>
> Every CMA region getting exposed was a side effect of doing
> the eneumeration without tying it to devicetree or other firmware.
> I'm not opposed to limiting the heaps exposed if we can find
> a good way to do so that's still compliant with devicetree/whatever.
>

I suspect this will actually be preferred in the end.  Its just that
having the CMA heaps (and whatever ill thought naming was used in the
dts) more visible made my nose crinkle a bit. But now its a good
motivator for more clear names in the dts' of future devices. But
allowing for separate cma heaps that can be logically partitioned
between uses doesn't seem like a negative to me.

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

Re: [PATCH v3 10/11] drm/panel: simple: Add NewEast Optoelectronics CO., LTD WJFH116008A panel support

[Vasily Khoruzhick]

On Tue, Feb 19, 2019 at 6:54 AM Rob Herring  wrote:

> > I believe using eDP connector binding wouldn't help much in my case
> > and it won't improve accuracy of hardware description while adding
> > unnecessary code duplication (edp-connector will be pretty much
> > simple-panel).
> >
> > Since currently there're no standalone connector drivers, implementing
> > one requires significant refactoring of the code that I'm not
> > familiar.
>
> I'm not talking about drivers. I'm talking about bindings. Those are
> not necessarily 1-1. There's no reason the simple panel driver can't
> have an 'edp-connector' entry.

These aren't independent things. Bindings are useless without drivers.

Also how are you going to address mainlined platforms that have eDP
and use panel bindings? E.g. rk3399 supports eDP and uses panel
binding - see rk3399-gru-kevin.dts as example.

> Also, since you have EDID, you should be using that for timing data
> IMO, and the binding needs to have enough information to support that.
> It may if DP-aux comes from the bridge chip or it may not if you need
> to describe that connection. Again, this is independent from what
> Linux chooses to do. If Linux chooses to have its own timing
> information that's its choice. Another OS may choose to use EDID.

I see nothing wrong here - anx6345 driver reads EDID (over AUX) and
uses timing from it, if reading EDID failed it fallback to timings
defined in panel driver.

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

[Bug 109073] AMDGPU Radeon RX540 system freezes and/or crashes; poor performance with ac adapter plugged in

[bugzilla-daemon]

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

--- Comment #10 from Utku Helvacı (tuxutku)  ---
hey i have opened a bug report here:
https://bugzilla.kernel.org/show_bug.cgi?id=201077
and i want to let you know that you can use 4.16 or 4.15 kernels for temporary
solution and all the people effected from this bug seem to using aspire 5
a515-41g laptop, also i updated to 1.09 bios and still there is no fix.
amd wanted from me to bisect the kernel but i could only found the main commit
and it contains dozens of other commits, but if you want to bisect the kernel
that's might be helpful

-- 
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 v5 0/9] mmu notifier provide context informations

[Jerome Glisse]

On Tue, Feb 19, 2019 at 01:19:09PM -0800, Dan Williams wrote:
> On Tue, Feb 19, 2019 at 12:58 PM Jerome Glisse  wrote:
> >
> > On Tue, Feb 19, 2019 at 12:40:37PM -0800, Dan Williams wrote:
> > > On Tue, Feb 19, 2019 at 12:30 PM Jerome Glisse  wrote:
> > > >
> > > > On Tue, Feb 19, 2019 at 12:15:55PM -0800, Dan Williams wrote:
> > > > > On Tue, Feb 19, 2019 at 12:04 PM  wrote:
> > > > > >
> > > > > > From: Jérôme Glisse 
> > > > > >
> > > > > > Since last version [4] i added the extra bits needed for the 
> > > > > > change_pte
> > > > > > optimization (which is a KSM thing). Here i am not posting users of
> > > > > > this, they will be posted to the appropriate sub-systems (KVM, GPU,
> > > > > > RDMA, ...) once this serie get upstream. If you want to look at 
> > > > > > users
> > > > > > of this see [5] [6]. If this gets in 5.1 then i will be submitting
> > > > > > those users for 5.2 (including KVM if KVM folks feel comfortable 
> > > > > > with
> > > > > > it).
> > > > >
> > > > > The users look small and straightforward. Why not await acks and
> > > > > reviewed-by's for the users like a typical upstream submission and
> > > > > merge them together? Is all of the functionality of this
> > > > > infrastructure consumed by the proposed users? Last time I checked it
> > > > > was only a subset.
> > > >
> > > > Yes pretty much all is use, the unuse case is SOFT_DIRTY and CLEAR
> > > > vs UNMAP. Both of which i intend to use. The RDMA folks already ack
> > > > the patches IIRC, so did radeon and amdgpu. I believe the i915 folks
> > > > were ok with it too. I do not want to merge things through Andrew
> > > > for all of this we discussed that in the past, merge mm bits through
> > > > Andrew in one release and bits that use things in the next release.
> > >
> > > Ok, I was trying to find the links to the acks on the mailing list,
> > > those references would address my concerns. I see no reason to rush
> > > SOFT_DIRTY and CLEAR ahead of the upstream user.
> >
> > I intend to post user for those in next couple weeks for 5.2 HMM bits.
> > So user for this (CLEAR/UNMAP/SOFTDIRTY) will definitly materialize in
> > time for 5.2.
> >
> > ACKS AMD/RADEON https://lkml.org/lkml/2019/2/1/395
> > ACKS RDMA https://lkml.org/lkml/2018/12/6/1473
> 
> Nice, thanks!
> 
> > For KVM Andrea Arcangeli seems to like the whole idea to restore the
> > change_pte optimization but i have not got ACK from Radim or Paolo,
> > however given the small performance improvement figure i get with it
> > i do not see while they would not ACK.
> 
> Sure, but no need to push ahead without that confirmation, right? At
> least for the piece that KVM cares about, maybe that's already covered
> in the infrastructure RDMA and RADEON are using?

The change_pte() for KVM is just one bit flag on top of the rest. So
i don't see much value in saving this last patch. I will be working
with KVM folks to merge KVM bits in 5.2. If they do not want that then
removing that extra flags is not much work.

But if you prefer than Andrew can drop the last patch in the serie.

Cheers,
Jérôme
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [EARLY RFC][PATCH 0/4] ION per heap devices

[Andrew F. Davis]

On 2/19/19 3:25 PM, Laura Abbott wrote:
> On 2/15/19 12:24 PM, John Stultz wrote:
>> This is a *very early RFC* (it builds, that's all I'll say :)
>> but I wanted to share it to get some initial feedback before I
>> go down the rabit hole of trying to adapt the Android userland
>> code to get this fully validated.
>>
>> This patchset tries to implement the per-heap devices for ION.
>> The main benefit is that it avoids multiplexing heap operations
>> through the /dev/ion interface, and allows for each heap to have
>> its own permissions/sepolicy rules.
>>
>> Feedback would be greatly appreciated!
>> thanks
>> -john
>>
>> Cc: Laura Abbott 
>> Cc: Sumit Semwal 
>> Cc: Liam Mark 
>> Cc: Brian Starkey 
>> Cc: Andrew F. Davis 
>> Cc: Alistair Strachan 
>> Cc: dri-devel@lists.freedesktop.org
>>
>> John Stultz (4):
>>    ion: Add ION_VERSION ioctl
>>    ion: Initial hack to create per heap devices
>>    ion: Add HEAP_INFO ioctl to be able to fetch heap type
>>    ion: Make "legacy" /dev/ion support optional
>>
>>   drivers/staging/android/ion/Kconfig |  7 +++
>>   drivers/staging/android/ion/ion-ioctl.c | 80
>> +
>>   drivers/staging/android/ion/ion.c   | 51 -
>>   drivers/staging/android/ion/ion.h   |  6 +++
>>   drivers/staging/android/uapi/ion.h  | 57 +++
>>   5 files changed, 191 insertions(+), 10 deletions(-)
>>
> 
> So it occurs to me if this is going to be a new ABI
> all together maybe we should just declare a new allocation ioctl
> to be used with it. We can keep the old ioctls around
> for legacy use cases and maybe eventually delete them
> and just use the new allocation ioctl with the new
> split heaps.
> 

Why keep the old ones, this is staging, there are no legacy users (that
matter to kernel).. Slowing progress for the sake of backwards compat
with staging just slows the de-staging down.

Andrew

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

Re: [EARLY RFC][PATCH 1/4] ion: Add ION_VERSION ioctl

[John Stultz]

On Tue, Feb 19, 2019 at 12:46 PM Laura Abbott  wrote:
>
> On 2/15/19 12:24 PM, John Stultz wrote:
> > With all the slight interface changes ion has had
> > through its time in staging, keeping userland working
> > properly has been a pain. Assuming more churn going
> > forward, provide a proper version interface.
> >
> > Cc: Laura Abbott 
> > Cc: Sumit Semwal 
> > Cc: Liam Mark 
> > Cc: Brian Starkey 
> > Cc: Andrew F. Davis 
> > Cc: Alistair Strachan 
> > Cc: dri-devel@lists.freedesktop.org
> > Signed-off-by: John Stultz 
> > ---
> >   drivers/staging/android/ion/ion-ioctl.c | 4 
> >   drivers/staging/android/ion/ion.h   | 2 ++
> >   drivers/staging/android/uapi/ion.h  | 7 +++
> >   3 files changed, 13 insertions(+)
> >
> > diff --git a/drivers/staging/android/ion/ion-ioctl.c 
> > b/drivers/staging/android/ion/ion-ioctl.c
> > index a8d3cc4..458a9f2 100644
> > --- a/drivers/staging/android/ion/ion-ioctl.c
> > +++ b/drivers/staging/android/ion/ion-ioctl.c
> > @@ -13,6 +13,7 @@
> >   union ion_ioctl_arg {
> >   struct ion_allocation_data allocation;
> >   struct ion_heap_query query;
> > + u32 version;
> >   };
> >
> >   static int validate_ioctl_arg(unsigned int cmd, union ion_ioctl_arg *arg)
> > @@ -86,6 +87,9 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
> > unsigned long arg)
> >   case ION_IOC_HEAP_QUERY:
> >   ret = ion_query_heaps(&data.query);
> >   break;
> > + case ION_IOC_VERSION:
> > + data.version = ION_VERSION;
> > + break;
> >   default:
> >   return -ENOTTY;
> >   }
> > diff --git a/drivers/staging/android/ion/ion.h 
> > b/drivers/staging/android/ion/ion.h
> > index 47b594c..439e682 100644
> > --- a/drivers/staging/android/ion/ion.h
> > +++ b/drivers/staging/android/ion/ion.h
> > @@ -21,6 +21,8 @@
> >
> >   #include "../uapi/ion.h"
> >
> > +#define ION_VERSION 3
> > +
> >   /**
> >* struct ion_platform_heap - defines a heap in the given platform
> >* @type:   type of the heap from ion_heap_type enum
> > diff --git a/drivers/staging/android/uapi/ion.h 
> > b/drivers/staging/android/uapi/ion.h
> > index 5d70098..c480448 100644
> > --- a/drivers/staging/android/uapi/ion.h
> > +++ b/drivers/staging/android/uapi/ion.h
> > @@ -124,4 +124,11 @@ struct ion_heap_query {
> >   #define ION_IOC_HEAP_QUERY _IOWR(ION_IOC_MAGIC, 8, \
> >   struct ion_heap_query)
> >
> > +/**
> > + * DOC: ION_IOC_VERSION - Get ION interface version
> > + *
> > + * Takes a u32 and returns the ION interface version
> > + */
> > +#define ION_IOC_VERSION  _IOR(ION_IOC_MAGIC, 9, u32)
> > +
> >   #endif /* _UAPI_LINUX_ION_H */
> >
>
> Like I said on the other thread, I was told no before
> https://lore.kernel.org/lkml/1472769644-11039-4-git-send-email-labb...@redhat.com/T/#u

Alright, then. I'm ok with dropping it. Hopefully we can just avoid
any more really subtle abi breaks.

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

Re: [EARLY RFC][PATCH 0/4] ION per heap devices

[Laura Abbott]

On 2/15/19 12:24 PM, John Stultz wrote:

This is a *very early RFC* (it builds, that's all I'll say :)
but I wanted to share it to get some initial feedback before I
go down the rabit hole of trying to adapt the Android userland
code to get this fully validated.

This patchset tries to implement the per-heap devices for ION.
The main benefit is that it avoids multiplexing heap operations
through the /dev/ion interface, and allows for each heap to have
its own permissions/sepolicy rules.

Feedback would be greatly appreciated!
thanks
-john

Cc: Laura Abbott 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Brian Starkey 
Cc: Andrew F. Davis 
Cc: Alistair Strachan 
Cc: dri-devel@lists.freedesktop.org

John Stultz (4):
   ion: Add ION_VERSION ioctl
   ion: Initial hack to create per heap devices
   ion: Add HEAP_INFO ioctl to be able to fetch heap type
   ion: Make "legacy" /dev/ion support optional

  drivers/staging/android/ion/Kconfig |  7 +++
  drivers/staging/android/ion/ion-ioctl.c | 80 +
  drivers/staging/android/ion/ion.c   | 51 -
  drivers/staging/android/ion/ion.h   |  6 +++
  drivers/staging/android/uapi/ion.h  | 57 +++
  5 files changed, 191 insertions(+), 10 deletions(-)



So it occurs to me if this is going to be a new ABI
all together maybe we should just declare a new allocation ioctl
to be used with it. We can keep the old ioctls around
for legacy use cases and maybe eventually delete them
and just use the new allocation ioctl with the new
split heaps.

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

[Bug 108514] heavy screen flickering with Mobility Radeon X1600 and kernel version 3.15rc2 onward

[bugzilla-daemon]

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

--- Comment #32 from Paul Dufresne  ---
Created attachment 143413
  --> https://bugs.freedesktop.org/attachment.cgi?id=143413&action=edit
patch radeon-display.c for latest kernel (5.0.0-rc7)

-- 
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 v5 0/9] mmu notifier provide context informations

[Dan Williams]

On Tue, Feb 19, 2019 at 12:58 PM Jerome Glisse  wrote:
>
> On Tue, Feb 19, 2019 at 12:40:37PM -0800, Dan Williams wrote:
> > On Tue, Feb 19, 2019 at 12:30 PM Jerome Glisse  wrote:
> > >
> > > On Tue, Feb 19, 2019 at 12:15:55PM -0800, Dan Williams wrote:
> > > > On Tue, Feb 19, 2019 at 12:04 PM  wrote:
> > > > >
> > > > > From: Jérôme Glisse 
> > > > >
> > > > > Since last version [4] i added the extra bits needed for the 
> > > > > change_pte
> > > > > optimization (which is a KSM thing). Here i am not posting users of
> > > > > this, they will be posted to the appropriate sub-systems (KVM, GPU,
> > > > > RDMA, ...) once this serie get upstream. If you want to look at users
> > > > > of this see [5] [6]. If this gets in 5.1 then i will be submitting
> > > > > those users for 5.2 (including KVM if KVM folks feel comfortable with
> > > > > it).
> > > >
> > > > The users look small and straightforward. Why not await acks and
> > > > reviewed-by's for the users like a typical upstream submission and
> > > > merge them together? Is all of the functionality of this
> > > > infrastructure consumed by the proposed users? Last time I checked it
> > > > was only a subset.
> > >
> > > Yes pretty much all is use, the unuse case is SOFT_DIRTY and CLEAR
> > > vs UNMAP. Both of which i intend to use. The RDMA folks already ack
> > > the patches IIRC, so did radeon and amdgpu. I believe the i915 folks
> > > were ok with it too. I do not want to merge things through Andrew
> > > for all of this we discussed that in the past, merge mm bits through
> > > Andrew in one release and bits that use things in the next release.
> >
> > Ok, I was trying to find the links to the acks on the mailing list,
> > those references would address my concerns. I see no reason to rush
> > SOFT_DIRTY and CLEAR ahead of the upstream user.
>
> I intend to post user for those in next couple weeks for 5.2 HMM bits.
> So user for this (CLEAR/UNMAP/SOFTDIRTY) will definitly materialize in
> time for 5.2.
>
> ACKS AMD/RADEON https://lkml.org/lkml/2019/2/1/395
> ACKS RDMA https://lkml.org/lkml/2018/12/6/1473

Nice, thanks!

> For KVM Andrea Arcangeli seems to like the whole idea to restore the
> change_pte optimization but i have not got ACK from Radim or Paolo,
> however given the small performance improvement figure i get with it
> i do not see while they would not ACK.

Sure, but no need to push ahead without that confirmation, right? At
least for the piece that KVM cares about, maybe that's already covered
in the infrastructure RDMA and RADEON are using?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] staging: android: ion: fix sys heap pool's gfp_flags

[Laura Abbott]

On 1/31/19 10:59 PM, Qing Xia wrote:

In the first loop, gfp_flags will be modified to high_order_gfp_flags,
and there will be no chance to change back to low_order_gfp_flags.

Fixes: e7f63771 ("ION: Sys_heap: Add cached pool to spead up cached buffer 
alloc")
Signed-off-by: Qing Xia 
---
  drivers/staging/android/ion/ion_system_heap.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/android/ion/ion_system_heap.c 
b/drivers/staging/android/ion/ion_system_heap.c
index 0383f75..20f2103 100644
--- a/drivers/staging/android/ion/ion_system_heap.c
+++ b/drivers/staging/android/ion/ion_system_heap.c
@@ -223,10 +223,10 @@ static void ion_system_heap_destroy_pools(struct 
ion_page_pool **pools)
  static int ion_system_heap_create_pools(struct ion_page_pool **pools)
  {
int i;
-   gfp_t gfp_flags = low_order_gfp_flags;
  
  	for (i = 0; i < NUM_ORDERS; i++) {

struct ion_page_pool *pool;
+   gfp_t gfp_flags = low_order_gfp_flags;
  
  		if (orders[i] > 4)

gfp_flags = high_order_gfp_flags;



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

Re: [EARLY RFC][PATCH 2/4] ion: Initial hack to create per heap devices

[Laura Abbott]

On 2/15/19 12:24 PM, John Stultz wrote:

One of the issues w/ the /dev/ion interface is that we have to
provide the complexity of a heap query interface and we end up
multiplexing all the heap access through that one interface via
a bit mask (which currently limits the heaps to 32).

There has been a long running todo to provide per-heap devices
which would make the heap discovery/query interface "ls", and
would allow for different heaps to have different permisisons
and sepolicy rules.

TODOs:
* Android doesn't use udev so "ion_heaps/%s" names don't
   automatically create a /dev/ subdir. I need to rework
   from miscdev to creating a proper device class and add
   a "subsystem" entry for the DeviceHandler to match with

* Each CMA region is exposed via a separate heap, not sure
   if this is desired or not, and we may need to improve the
   naming.



Every CMA region getting exposed was a side effect of doing
the eneumeration without tying it to devicetree or other firmware.
I'm not opposed to limiting the heaps exposed if we can find
a good way to do so that's still compliant with devicetree/whatever.

Thanks,
Laura


Cc: Laura Abbott 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Brian Starkey 
Cc: Andrew F. Davis 
Cc: Alistair Strachan 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
---
  drivers/staging/android/ion/ion-ioctl.c | 62 +
  drivers/staging/android/ion/ion.c   | 18 ++
  drivers/staging/android/ion/ion.h   |  2 ++
  drivers/staging/android/uapi/ion.h  | 28 +++
  4 files changed, 110 insertions(+)

diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index 458a9f2..ea8d263 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -12,6 +12,7 @@
  
  union ion_ioctl_arg {

struct ion_allocation_data allocation;
+   struct ion_heap_allocation_data heap_allocation;
struct ion_heap_query query;
u32 version;
  };
@@ -100,3 +101,64 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
unsigned long arg)
}
return ret;
  }
+
+long ion_heap_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
+{
+   int ret = 0;
+   unsigned int dir;
+   union ion_ioctl_arg data;
+
+   dir = ion_ioctl_dir(cmd);
+
+   if (_IOC_SIZE(cmd) > sizeof(data))
+   return -EINVAL;
+
+   /*
+* The copy_from_user is unconditional here for both read and write
+* to do the validate. If there is no write for the ioctl, the
+* buffer is cleared
+*/
+   if (copy_from_user(&data, (void __user *)arg, _IOC_SIZE(cmd)))
+   return -EFAULT;
+
+   ret = validate_ioctl_arg(cmd, &data);
+   if (ret) {
+   pr_warn_once("%s: ioctl validate failed\n", __func__);
+   return ret;
+   }
+
+   if (!(dir & _IOC_WRITE))
+   memset(&data, 0, sizeof(data));
+
+   switch (cmd) {
+   case ION_IOC_HEAP_ALLOC:
+   {
+   struct miscdevice *miscdev = filp->private_data;
+   struct ion_heap *heap;
+   int fd;
+
+   heap = container_of(miscdev, struct ion_heap, heap_dev);
+
+   fd = ion_alloc(data.heap_allocation.len,
+  (1 << heap->id),
+  data.heap_allocation.flags);
+   if (fd < 0)
+   return fd;
+
+   data.heap_allocation.fd = fd;
+
+   break;
+   }
+   case ION_IOC_VERSION:
+   data.version = ION_VERSION;
+   break;
+   default:
+   return -ENOTTY;
+   }
+
+   if (dir & _IOC_READ) {
+   if (copy_to_user((void __user *)arg, &data, _IOC_SIZE(cmd)))
+   return -EFAULT;
+   }
+   return ret;
+}
diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 6f5afab..1f7c893 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -492,6 +492,14 @@ int ion_query_heaps(struct ion_heap_query *query)
return ret;
  }
  
+static const struct file_operations ion_heap_fops = {

+   .owner  = THIS_MODULE,
+   .unlocked_ioctl = ion_heap_ioctl,
+#ifdef CONFIG_COMPAT
+   .compat_ioctl   = ion_heap_ioctl,
+#endif
+};
+
  static const struct file_operations ion_fops = {
.owner  = THIS_MODULE,
.unlocked_ioctl = ion_ioctl,
@@ -540,12 +548,22 @@ void ion_device_add_heap(struct ion_heap *heap)
struct ion_device *dev = internal_dev;
int ret;
struct dentry *heap_root;
+   char *heap_name;
char debug_name[64];
  
  	if (!heap->ops->allocate || !heap->ops->free)

pr_err("%s: can not add heap with invalid ops struct.\n",
   __func__);
  
+	heap_name = kasprintf(GFP_KERNEL, "ion_heaps

Re: [EARLY RFC][PATCH 3/4] ion: Add HEAP_INFO ioctl to be able to fetch heap type

[Laura Abbott]

On 2/15/19 12:24 PM, John Stultz wrote:

The per-device heaps don't support HEAP_QUERY ioctl, since
the name is provided in the devnode path and the heapid isn't
useful with the new interface (one uses the fd of heapdevice).

But, one missing bit of functionality is a way to find the
heap type. So provide a HEAP_INFO ioctl which exposes the
heap type out so there is the potential for some sort of
dynamic heap matching/discovery.

Most likely this IOCTL will be useful when extended to allow
some sort of opaque constraint bitfield to be shared so userland
can match heaps with devices in a fully dynamic way.



We've been waiting on the constraint solving for a while and
it's never really happened :(

It certainly works but I'm concerned about adding this and
then finding (yet again) that it doesn't work. We're
getting the heap name now but do we lose anything if we
don't expose it as part of the ABI?


Cc: Laura Abbott 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Brian Starkey 
Cc: Andrew F. Davis 
Cc: Alistair Strachan 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
---
  drivers/staging/android/ion/ion-ioctl.c | 12 
  drivers/staging/android/uapi/ion.h  | 22 ++
  2 files changed, 34 insertions(+)

diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index ea8d263..6db5969 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -14,6 +14,7 @@ union ion_ioctl_arg {
struct ion_allocation_data allocation;
struct ion_heap_allocation_data heap_allocation;
struct ion_heap_query query;
+   struct ion_heap_info heap_info;
u32 version;
  };
  
@@ -149,6 +150,17 @@ long ion_heap_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
  
  		break;

}
+   case ION_IOC_HEAP_INFO:
+   {
+   struct miscdevice *miscdev = filp->private_data;
+   struct ion_heap *heap;
+
+   heap = container_of(miscdev, struct ion_heap, heap_dev);
+
+   data.heap_info.type = heap->type;
+
+   break;
+   }
case ION_IOC_VERSION:
data.version = ION_VERSION;
break;
diff --git a/drivers/staging/android/uapi/ion.h 
b/drivers/staging/android/uapi/ion.h
index 20db09f..1b3ca1e 100644
--- a/drivers/staging/android/uapi/ion.h
+++ b/drivers/staging/android/uapi/ion.h
@@ -111,6 +111,19 @@ struct ion_heap_data {
  };
  
  /**

+ * struct ion_heap_info - Info about the heap
+ *
+ */
+struct ion_heap_info {
+   __u32 type;
+   __u32 reserved0;
+   __u32 reserved1;
+   __u32 reserved2;
+   __u32 reserved3;
+   __u32 reserved4;
+};
+
+/**
   * struct ion_heap_query - collection of data about all heaps
   * @cnt - total number of heaps to be copied
   * @heaps - buffer to copy heap data
@@ -159,4 +172,13 @@ struct ion_heap_query {
  #define ION_IOC_HEAP_ALLOC_IOWR(ION_IOC_MAGIC, 10, \
  struct ion_heap_allocation_data)
  
+/**

+ * DOC: ION_IOC_HEAP_INFO - allocate memory from heap
+ *
+ * Takes an ion_heap_query structure and populates information about
+ * available Ion heaps.
+ */
+#define ION_IOC_HEAP_INFO  _IOWR(ION_IOC_MAGIC, 11, \
+ struct ion_heap_allocation_data)
+
  #endif /* _UAPI_LINUX_ION_H */



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

[Bug 202537] amdgpu/DC failed to reserve new abo buffer before flip

[bugzilla-daemon]

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

--- Comment #23 from Bernd Steinhauser (li...@bernd-steinhauser.de) ---
(In reply to Paul Menzel from comment #22)
> Bernd, what triggers this on your system? What is your test case? Start some
> program?
basically start the system, log in, ensuring that /sys/kernel/debug/kmemleak is
empty, then initiating the scan and waiting for the result.
I found that testing without the login (starting sddm in my case) can be enough
to spot the memleaks, but you can't be sure.
Also, I think that putting some more work there for the gpu (e.g. playing a
video) helps to spot more memleaks quicker, thus getting a more reliable result
quicker, but I it doesn't seem necessary.

In case I don't find memleaks, I still repeat the scan routing a few times, do
something else in the meantime (like preparing the next test version) and then
before rebooting do the scan once more, just to be sure.
So in total – on my rather slow system – every version is tested for about
30min, although in case of a bad version about 5min is enough.

Anyway, back to the original topic. bisecting this time went much more smoothly
and much quicker than before and I can actually present the result already, see
below.
I tried to apply the fix on top of 4.20.10, but that doesn't compile as it most
likely depends on other commits.
So unfortunately can't cross-check this at the moment.
@Paul: might be a good idea if you check this as well, meaning to test
b61857b5e and its parent.

git bisect start '--term-old' 'unfixed' '--term-new' 'fixed'
# unfixed: [8fe28cb58bcb235034b64cbbb7550a8a43fd88be] Linux 4.20
git bisect unfixed 8fe28cb58bcb235034b64cbbb7550a8a43fd88be
# fixed: [256445aee13f4de36cb47c13a9560b5d74faacd2] drm/amdgpu: remove some old
unused dpm helpers
git bisect fixed 256445aee13f4de36cb47c13a9560b5d74faacd2
# unfixed: [e0c38a4d1f196a4b17d2eba36afff8f656a4f1de] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
git bisect unfixed e0c38a4d1f196a4b17d2eba36afff8f656a4f1de
# unfixed: [9ef10340749e1da0c7fde609cedd5360f8484a0b] Merge tag
'xtensa-20181228' of git://github.com/jcmvbkbc/linux-xtensa
git bisect unfixed 9ef10340749e1da0c7fde609cedd5360f8484a0b
# unfixed: [fcf010449ebe1db0cb68b2c6410972a782f2bd14] Merge tag 'kgdb-4.21-rc1'
of git://git.kernel.org/pub/scm/linux/kernel/git/danielt/linux
git bisect unfixed fcf010449ebe1db0cb68b2c6410972a782f2bd14
# unfixed: [9b286efeb5eb5aaa2712873fc1f928b2f879dbde] Merge branch 'for-linus'
of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
git bisect unfixed 9b286efeb5eb5aaa2712873fc1f928b2f879dbde
# unfixed: [ac5eed2b41776b05cf03aac761d3bb5e64eea24c] Merge branch
'perf-urgent-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect unfixed ac5eed2b41776b05cf03aac761d3bb5e64eea24c
# unfixed: [5dc3fc5a7835f6b98184d2b8df909c5230c37a2c] drm/amd/display: Check if
registers are available before accessing
git bisect unfixed 5dc3fc5a7835f6b98184d2b8df909c5230c37a2c
# fixed: [87076c8829465b8ae71225f7e639e0e28ab4b4a2] drm/amd/display: Re-enable
CRC capture following modeset
git bisect fixed 87076c8829465b8ae71225f7e639e0e28ab4b4a2
# fixed: [84d3245599f527138c4d4b87deed14a7e85cd81b] drm/amdgpu: Add missing
power attribute to APU check
git bisect fixed 84d3245599f527138c4d4b87deed14a7e85cd81b
# unfixed: [ae6d343541bb75958e9535d056adaf4ff6a66d6a] drm/ttm: add lru notify
to bo driver v2
git bisect unfixed ae6d343541bb75958e9535d056adaf4ff6a66d6a
# fixed: [5d50fcbda7b0acd301bb1fc3d828df0aa29237b8] drm/ttm: stop always moving
BOs on the LRU on page fault
git bisect fixed 5d50fcbda7b0acd301bb1fc3d828df0aa29237b8
# fixed: [d7337ca2640cde21ff178bd78f01d94cd5ea2e08] drm/amd/powerplay: support
retrieving and adjusting SOC clock power levels V2
git bisect fixed d7337ca2640cde21ff178bd78f01d94cd5ea2e08
# fixed: [b61857b5e365889d67a6296c413df396032d374d] drm/amdgpu: set
bulk_moveable to false when lru changed v2
git bisect fixed b61857b5e365889d67a6296c413df396032d374d
# first fixed commit: [b61857b5e365889d67a6296c413df396032d374d] drm/amdgpu:
set bulk_moveable to false when lru changed v2
commit b61857b5e365889d67a6296c413df396032d374d
Author: Chunming Zhou 
Date:   Thu Jan 10 15:49:54 2019 +0800

drm/amdgpu: set bulk_moveable to false when lru changed v2

if lru is changed, we cannot do bulk moving.
v2:
root bo isn't in bulk moving, skip its change.

Signed-off-by: Chunming Zhou 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 

:04 04 3544338af6c797a518386198369dc4766961d151
392a4c14309bd108b20046609138f7bc2859f3f7 M  drivers

-- 
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 v5 0/9] mmu notifier provide context informations

[Jerome Glisse]

On Tue, Feb 19, 2019 at 12:40:37PM -0800, Dan Williams wrote:
> On Tue, Feb 19, 2019 at 12:30 PM Jerome Glisse  wrote:
> >
> > On Tue, Feb 19, 2019 at 12:15:55PM -0800, Dan Williams wrote:
> > > On Tue, Feb 19, 2019 at 12:04 PM  wrote:
> > > >
> > > > From: Jérôme Glisse 
> > > >
> > > > Since last version [4] i added the extra bits needed for the change_pte
> > > > optimization (which is a KSM thing). Here i am not posting users of
> > > > this, they will be posted to the appropriate sub-systems (KVM, GPU,
> > > > RDMA, ...) once this serie get upstream. If you want to look at users
> > > > of this see [5] [6]. If this gets in 5.1 then i will be submitting
> > > > those users for 5.2 (including KVM if KVM folks feel comfortable with
> > > > it).
> > >
> > > The users look small and straightforward. Why not await acks and
> > > reviewed-by's for the users like a typical upstream submission and
> > > merge them together? Is all of the functionality of this
> > > infrastructure consumed by the proposed users? Last time I checked it
> > > was only a subset.
> >
> > Yes pretty much all is use, the unuse case is SOFT_DIRTY and CLEAR
> > vs UNMAP. Both of which i intend to use. The RDMA folks already ack
> > the patches IIRC, so did radeon and amdgpu. I believe the i915 folks
> > were ok with it too. I do not want to merge things through Andrew
> > for all of this we discussed that in the past, merge mm bits through
> > Andrew in one release and bits that use things in the next release.
> 
> Ok, I was trying to find the links to the acks on the mailing list,
> those references would address my concerns. I see no reason to rush
> SOFT_DIRTY and CLEAR ahead of the upstream user.

I intend to post user for those in next couple weeks for 5.2 HMM bits.
So user for this (CLEAR/UNMAP/SOFTDIRTY) will definitly materialize in
time for 5.2.

ACKS AMD/RADEON https://lkml.org/lkml/2019/2/1/395
ACKS RDMA https://lkml.org/lkml/2018/12/6/1473

For KVM Andrea Arcangeli seems to like the whole idea to restore the
change_pte optimization but i have not got ACK from Radim or Paolo,
however given the small performance improvement figure i get with it
i do not see while they would not ACK.

https://lkml.org/lkml/2019/2/18/1530

Cheers,
Jérôme
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [EARLY RFC][PATCH 0/4] ION per heap devices

[Laura Abbott]

On 2/19/19 9:21 AM, John Stultz wrote:

On Mon, Feb 18, 2019 at 3:51 AM Brian Starkey  wrote:

On Fri, Feb 15, 2019 at 12:24:08PM -0800, John Stultz wrote:

This is a *very early RFC* (it builds, that's all I'll say :)
but I wanted to share it to get some initial feedback before I
go down the rabit hole of trying to adapt the Android userland
code to get this fully validated.

This patchset tries to implement the per-heap devices for ION.
The main benefit is that it avoids multiplexing heap operations
through the /dev/ion interface, and allows for each heap to have
its own permissions/sepolicy rules.


In general, I've always thought that having a device node per-heap is
a bit messy for userspace. Multiplexing through the single node
doesn't seem like an insurmountable problem, but the point about


Hrm. I guess for me having a custom enumeration interface over ioctl
seems less ideal compared to a directory list.


permissions/sepolicy is reasonably compelling if it's a real
requirement. What would be the reasons for that?


Its a bit second hand for me, so hopefully I don't have it wrong. I've
cc'ed some additional google folks and Benjamin for extra context, but
my sense of it is that you may have some less-trusted code that we're
fine with allocating system heap dma-bufs, but don't want to to be
giving access to more limited heaps like carveout or cma, or more
potentially security troubling heaps like system-contig.

thanks
-john



Yes, the discussion was always based on being able to set separate
security policy for each heap. It's not clear to me how strong a
requirement is these days or if there's other options to enforce
the same thing.

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

Re: [PATCH v5 0/9] mmu notifier provide context informations

[Dan Williams]

On Tue, Feb 19, 2019 at 12:41 PM Jason Gunthorpe  wrote:
>
> On Tue, Feb 19, 2019 at 03:30:33PM -0500, Jerome Glisse wrote:
> > On Tue, Feb 19, 2019 at 12:15:55PM -0800, Dan Williams wrote:
> > > On Tue, Feb 19, 2019 at 12:04 PM  wrote:
> > > >
> > > > From: Jérôme Glisse 
> > > >
> > > > Since last version [4] i added the extra bits needed for the change_pte
> > > > optimization (which is a KSM thing). Here i am not posting users of
> > > > this, they will be posted to the appropriate sub-systems (KVM, GPU,
> > > > RDMA, ...) once this serie get upstream. If you want to look at users
> > > > of this see [5] [6]. If this gets in 5.1 then i will be submitting
> > > > those users for 5.2 (including KVM if KVM folks feel comfortable with
> > > > it).
> > >
> > > The users look small and straightforward. Why not await acks and
> > > reviewed-by's for the users like a typical upstream submission and
> > > merge them together? Is all of the functionality of this
> > > infrastructure consumed by the proposed users? Last time I checked it
> > > was only a subset.
> >
> > Yes pretty much all is use, the unuse case is SOFT_DIRTY and CLEAR
> > vs UNMAP. Both of which i intend to use. The RDMA folks already ack
> > the patches IIRC, so did radeon and amdgpu. I believe the i915 folks
> > were ok with it too. I do not want to merge things through Andrew
> > for all of this we discussed that in the past, merge mm bits through
> > Andrew in one release and bits that use things in the next release.
>
> It is usually cleaner for everyone to split patches like this, for
> instance I always prefer to merge RDMA patches via RDMA when
> possible. Less conflicts.
>
> The other somewhat reasonable option is to get acks and send your own
> complete PR to Linus next week? That works OK for tree-wide changes.

Yes, I'm not proposing that they be merged together, instead I'm just
looking for the acked-by / reviewed-by tags even if those patches are
targeting the next merge window.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [EARLY RFC][PATCH 1/4] ion: Add ION_VERSION ioctl

[Laura Abbott]

On 2/15/19 12:24 PM, John Stultz wrote:

With all the slight interface changes ion has had
through its time in staging, keeping userland working
properly has been a pain. Assuming more churn going
forward, provide a proper version interface.

Cc: Laura Abbott 
Cc: Sumit Semwal 
Cc: Liam Mark 
Cc: Brian Starkey 
Cc: Andrew F. Davis 
Cc: Alistair Strachan 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz 
---
  drivers/staging/android/ion/ion-ioctl.c | 4 
  drivers/staging/android/ion/ion.h   | 2 ++
  drivers/staging/android/uapi/ion.h  | 7 +++
  3 files changed, 13 insertions(+)

diff --git a/drivers/staging/android/ion/ion-ioctl.c 
b/drivers/staging/android/ion/ion-ioctl.c
index a8d3cc4..458a9f2 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -13,6 +13,7 @@
  union ion_ioctl_arg {
struct ion_allocation_data allocation;
struct ion_heap_query query;
+   u32 version;
  };
  
  static int validate_ioctl_arg(unsigned int cmd, union ion_ioctl_arg *arg)

@@ -86,6 +87,9 @@ long ion_ioctl(struct file *filp, unsigned int cmd, unsigned 
long arg)
case ION_IOC_HEAP_QUERY:
ret = ion_query_heaps(&data.query);
break;
+   case ION_IOC_VERSION:
+   data.version = ION_VERSION;
+   break;
default:
return -ENOTTY;
}
diff --git a/drivers/staging/android/ion/ion.h 
b/drivers/staging/android/ion/ion.h
index 47b594c..439e682 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -21,6 +21,8 @@
  
  #include "../uapi/ion.h"
  
+#define ION_VERSION 3

+
  /**
   * struct ion_platform_heap - defines a heap in the given platform
   * @type: type of the heap from ion_heap_type enum
diff --git a/drivers/staging/android/uapi/ion.h 
b/drivers/staging/android/uapi/ion.h
index 5d70098..c480448 100644
--- a/drivers/staging/android/uapi/ion.h
+++ b/drivers/staging/android/uapi/ion.h
@@ -124,4 +124,11 @@ struct ion_heap_query {
  #define ION_IOC_HEAP_QUERY _IOWR(ION_IOC_MAGIC, 8, \
struct ion_heap_query)
  
+/**

+ * DOC: ION_IOC_VERSION - Get ION interface version
+ *
+ * Takes a u32 and returns the ION interface version
+ */
+#define ION_IOC_VERSION_IOR(ION_IOC_MAGIC, 9, u32)
+
  #endif /* _UAPI_LINUX_ION_H */



Like I said on the other thread, I was told no before
https://lore.kernel.org/lkml/1472769644-11039-4-git-send-email-labb...@redhat.com/T/#u
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] staging: android: ion: Allocate from heap ID directly without mask

[Laura Abbott]

On 2/15/19 11:01 AM, John Stultz wrote:

On Fri, Feb 15, 2019 at 2:51 AM Brian Starkey  wrote:


Hi John,

On Thu, Feb 14, 2019 at 09:38:29AM -0800, John Stultz wrote:



[snip]


Some thoughts, as this ABI break has the potential to be pretty painful.

1) Unfortunately, this ABI is exposed *through* libion via
ion_alloc/ion_alloc_fd out to gralloc implementations. Which means it
will have a wider impact to vendor userland code.


I figured libion could fairly easily loop through all the set bits in
heap_mask and call the ioctl for each until it succeeds. That
preserves the old behaviour from the libion clients' perspective.


Potentially, though that implicitly still caps the heaps to 32.  So
I'm not sure what the net benefit would be.



2) For patches that cause ABI breaks, it might be good to make it
clear in the commit what the userland impact looks like in userspace,
possibly with an example, so the poor folks who bisect down the change
as breaking their system in a year or so have a clear example as to
what they need to change in their code.

3) Also, its not clear how a given userland should distinguish between
the different ABIs.  We already have logic in libion to distinguish
between pre-4.12 legacy and post-4.12 implementations (using implicit
ion_free() behavior). I don't see any such check we can make with this
code. Adding another ABI version may require we provide an actual
interface version ioctl.



A slightly fragile/ugly approach might be to attempt a small
allocation with a heap_mask of 0x. On an "old" implementation,
you'd expect that to succeed, whereas it would/could be made to fail
in the "new" one.


Yea I think having a proper ION_IOC_VERSION is going to be necessary.

I'm hoping to send out an ugly first stab at the kernel side for
switching to per-heap devices (with a config for keeping /dev/ion for
legacy compat), which I hope will address the core issue this patch
does (moving away from heap masks to specifically requested heaps).

thanks
-john



Arnd/Greg said no to this last time I tried back in 2016

https://lore.kernel.org/lkml/1472769644-11039-4-git-send-email-labb...@redhat.com/T/#u
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] xf86drm: Add drmIsMaster()

[Daniel Vetter]

On Thu, Jan 24, 2019 at 10:45:04AM +0100, Daniel Vetter wrote:
> On Thu, Jan 24, 2019 at 09:56:51AM +1300, Christopher James Halse Rogers 
> wrote:
> > On 24 January 2019 6:18:32 am NZDT, Emil Velikov  
> > wrote:
> > >On Wed, 23 Jan 2019 at 04:39, Christopher James Halse Rogers
> > > wrote:
> > >>
> > >> We can't use drmSetMaster to query whether or not a drm fd is master
> > >> because it requires CAP_SYS_ADMIN, even if the fd *is* a master fd.
> > >>
> > >> Pick DRM_IOCTL_MODE_ATTACHMODE as a long-deprecated ioctl that is
> > >> DRM_MASTER but not DRM_ROOT_ONLY as the probe by which we can detect
> > >> whether or not the fd is master.
> > >>
> > >> This is useful for code that might get master by open()ing the drm
> > >device
> > >> while no other master exists, but can't call drmSetMaster itself
> > >because
> > >> it's not running as root or is in a container, where container-root
> > >isn't
> > >> real-root.
> > >>
> > >> v2: Use the AUTH_MAGIC request rather than MODE_ATTACHMODE, as it's
> > >more
> > >> clearly related to master status.
> > >>
> > >> Signed-off-by: Christopher James Halse Rogers
> > >
> > >> ---
> > >>  xf86drm.c | 15 +++
> > >>  xf86drm.h |  2 ++
> > >>  2 files changed, 17 insertions(+)
> > >>
> > >> diff --git a/xf86drm.c b/xf86drm.c
> > >> index 10df682b..adee5bd9 100644
> > >> --- a/xf86drm.c
> > >> +++ b/xf86drm.c
> > >> @@ -2741,6 +2741,21 @@ drm_public int drmDropMaster(int fd)
> > >>  return drmIoctl(fd, DRM_IOCTL_DROP_MASTER, NULL);
> > >>  }
> > >>
> > >> +drm_public bool drmIsMaster(int fd)
> > >> +{
> > >> +/* Detect master by attempting something that requires
> > >master.
> > >> + *
> > >> + * Authenticating magic tokens requires master and 0 is
> > >> + * guaranteed to be an invalid magic number. Attempting this
> > >on
> > >> + * a master fd will fail therefore fail with EINVAL because
> > >0 is
> > >> + * invalid.
> > >> + *
> > >> + * A non-master fd will fail with EACCESS, as the kernel
> > >checks for
> > >> + * master before attempting to do anything else.
> > >> + */
> > >> +return drmAuthMagic(fd, 0) == EINVAL;
> > >What magic value is valid, is a DRM implementation detail, which we
> > >don't need to depend upon.
> > >
> > >Instead we can check for EACCES, since we care if we have permissions
> > >- aka are we master.
> > >The function returns a negative errno, so I'd make this a:
> > >
> > >return drmAuthMagic(fd, 0) != -EACCES;
> > >
> > >If you and Daniel agree, I'll squash this locally and push.
> > 
> > That's a much better idea, thanks!
> 
> I don't like checks for "something else happened", I much prefer checking
> for something specific. Hence == -EINVAL over != EACCESS. But I guess in
> this case here it doesn't matter.
> 
> We just need to make sure that the igt tests both ways, to make sure we'll
> never ever break this. I'd still prefer the current version, imo easier to
> write an igt to make sure it keeps working.

Since this landed now ... is the igt anywhere to make sure this keeps
working?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/9] mmu notifier provide context informations

[Dan Williams]

On Tue, Feb 19, 2019 at 12:30 PM Jerome Glisse  wrote:
>
> On Tue, Feb 19, 2019 at 12:15:55PM -0800, Dan Williams wrote:
> > On Tue, Feb 19, 2019 at 12:04 PM  wrote:
> > >
> > > From: Jérôme Glisse 
> > >
> > > Since last version [4] i added the extra bits needed for the change_pte
> > > optimization (which is a KSM thing). Here i am not posting users of
> > > this, they will be posted to the appropriate sub-systems (KVM, GPU,
> > > RDMA, ...) once this serie get upstream. If you want to look at users
> > > of this see [5] [6]. If this gets in 5.1 then i will be submitting
> > > those users for 5.2 (including KVM if KVM folks feel comfortable with
> > > it).
> >
> > The users look small and straightforward. Why not await acks and
> > reviewed-by's for the users like a typical upstream submission and
> > merge them together? Is all of the functionality of this
> > infrastructure consumed by the proposed users? Last time I checked it
> > was only a subset.
>
> Yes pretty much all is use, the unuse case is SOFT_DIRTY and CLEAR
> vs UNMAP. Both of which i intend to use. The RDMA folks already ack
> the patches IIRC, so did radeon and amdgpu. I believe the i915 folks
> were ok with it too. I do not want to merge things through Andrew
> for all of this we discussed that in the past, merge mm bits through
> Andrew in one release and bits that use things in the next release.

Ok, I was trying to find the links to the acks on the mailing list,
those references would address my concerns. I see no reason to rush
SOFT_DIRTY and CLEAR ahead of the upstream user.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U

[bugzilla-daemon]

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

--- Comment #15 from Harry Wentland  ---
Can you see if this patch fixes it:
https://patchwork.freedesktop.org/patch/277181/

-- 
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 v5 0/9] mmu notifier provide context informations

[Jerome Glisse]

On Tue, Feb 19, 2019 at 12:15:55PM -0800, Dan Williams wrote:
> On Tue, Feb 19, 2019 at 12:04 PM  wrote:
> >
> > From: Jérôme Glisse 
> >
> > Since last version [4] i added the extra bits needed for the change_pte
> > optimization (which is a KSM thing). Here i am not posting users of
> > this, they will be posted to the appropriate sub-systems (KVM, GPU,
> > RDMA, ...) once this serie get upstream. If you want to look at users
> > of this see [5] [6]. If this gets in 5.1 then i will be submitting
> > those users for 5.2 (including KVM if KVM folks feel comfortable with
> > it).
> 
> The users look small and straightforward. Why not await acks and
> reviewed-by's for the users like a typical upstream submission and
> merge them together? Is all of the functionality of this
> infrastructure consumed by the proposed users? Last time I checked it
> was only a subset.

Yes pretty much all is use, the unuse case is SOFT_DIRTY and CLEAR
vs UNMAP. Both of which i intend to use. The RDMA folks already ack
the patches IIRC, so did radeon and amdgpu. I believe the i915 folks
were ok with it too. I do not want to merge things through Andrew
for all of this we discussed that in the past, merge mm bits through
Andrew in one release and bits that use things in the next release.

Cheers,
Jérôme
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 0/9] mmu notifier provide context informations

[Dan Williams]

On Tue, Feb 19, 2019 at 12:04 PM  wrote:
>
> From: Jérôme Glisse 
>
> Since last version [4] i added the extra bits needed for the change_pte
> optimization (which is a KSM thing). Here i am not posting users of
> this, they will be posted to the appropriate sub-systems (KVM, GPU,
> RDMA, ...) once this serie get upstream. If you want to look at users
> of this see [5] [6]. If this gets in 5.1 then i will be submitting
> those users for 5.2 (including KVM if KVM folks feel comfortable with
> it).

The users look small and straightforward. Why not await acks and
reviewed-by's for the users like a typical upstream submission and
merge them together? Is all of the functionality of this
infrastructure consumed by the proposed users? Last time I checked it
was only a subset.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/powerplay/smu10_hwmgr: use struct_size() in kzalloc()

[Gustavo A. R. Silva]

On 2/19/19 1:51 PM, Alex Deucher wrote:
> On Tue, Feb 19, 2019 at 1:55 PM Gustavo A. R. Silva
>  wrote:
>>
>> One of the more common cases of allocation size calculations is finding
>> the size of a structure that has a zero-sized array at the end, along
>> with memory for some number of elements for that array. For example:
>>
>> struct foo {
>> int stuff;
>> struct boo entry[];
>> };
>>
>> size = sizeof(struct foo) + count * sizeof(struct boo);
>> instance = kzalloc(size, GFP_KERNEL);
>>
>> Instead of leaving these open-coded and prone to type mistakes, we can
>> now use the new struct_size() helper:
>>
>> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
>>
>> Notice that, in this case, variable table_size is not necessary, hence
>> it is removed.
>>
>> This code was detected with the help of Coccinelle.
>>
>> Signed-off-by: Gustavo A. R. Silva 
> 
> Applied this and the smu8 patch.  Thanks!
> 
Great!

Thanks, Alex.

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

[PATCH v5 9/9] mm/mmu_notifier: set MMU_NOTIFIER_USE_CHANGE_PTE flag where appropriate v2

[jglisse]

From: Jérôme Glisse 

When notifying change for a range use MMU_NOTIFIER_USE_CHANGE_PTE flag
for page table update that use set_pte_at_notify() and where the we are
going either from read and write to read only with same pfn or read only
to read and write with new pfn.

Note that set_pte_at_notify() itself should only be use in rare cases
ie we do not want to use it when we are updating a significant range of
virtual addresses and thus a significant number of pte. Instead for
those cases the event provided to mmu notifer invalidate_range_start()
callback should be use for optimization.

Changes since v1:
- Use the new unsigned flags field in struct mmu_notifier_range
- Use the new flags parameter to mmu_notifier_range_init()
- Explicitly list all the patterns where we can use change_pte()

Signed-off-by: Jérôme Glisse 
Cc: Christian König 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Jan Kara 
Cc: Andrea Arcangeli 
Cc: Peter Xu 
Cc: Felix Kuehling 
Cc: Jason Gunthorpe 
Cc: Ross Zwisler 
Cc: Dan Williams 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Michal Hocko 
Cc: Christian Koenig 
Cc: Ralph Campbell 
Cc: John Hubbard 
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: Arnd Bergmann 
---
 include/linux/mmu_notifier.h | 34 --
 mm/ksm.c | 11 ++-
 mm/memory.c  |  5 +++--
 3 files changed, 41 insertions(+), 9 deletions(-)

diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index b6c004bd9f6a..0230a4b06b46 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -40,6 +40,26 @@ enum mmu_notifier_event {
MMU_NOTIFY_SOFT_DIRTY,
 };
 
+/*
+ * @MMU_NOTIFIER_RANGE_BLOCKABLE: can the mmu notifier range_start/range_end
+ * callback block or not ? If set then the callback can block.
+ *
+ * @MMU_NOTIFIER_USE_CHANGE_PTE: only set when the page table it updated with
+ * the set_pte_at_notify() the valid patterns for this are:
+ *  - pte read and write to read only same pfn
+ *  - pte read only to read and write (pfn can change or stay the same)
+ *  - pte read only to read only with different pfn
+ * It is illegal to set in any other circumstances.
+ *
+ * Note that set_pte_at_notify() should not be use outside of the above cases.
+ * When updating a range in batch (like write protecting a range) it is better
+ * to rely on invalidate_range_start() and struct mmu_notifier_range to infer
+ * the kind of update that is happening (as an example you can look at the
+ * mmu_notifier_range_update_to_read_only() function).
+ */
+#define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0)
+#define MMU_NOTIFIER_USE_CHANGE_PTE (1 << 1)
+
 #ifdef CONFIG_MMU_NOTIFIER
 
 /*
@@ -55,8 +75,6 @@ struct mmu_notifier_mm {
spinlock_t lock;
 };
 
-#define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0)
-
 struct mmu_notifier_range {
struct vm_area_struct *vma;
struct mm_struct *mm;
@@ -268,6 +286,12 @@ mmu_notifier_range_blockable(const struct 
mmu_notifier_range *range)
return (range->flags & MMU_NOTIFIER_RANGE_BLOCKABLE);
 }
 
+static inline bool
+mmu_notifier_range_use_change_pte(const struct mmu_notifier_range *range)
+{
+   return (range->flags & MMU_NOTIFIER_USE_CHANGE_PTE);
+}
+
 static inline void mmu_notifier_release(struct mm_struct *mm)
 {
if (mm_has_notifiers(mm))
@@ -509,6 +533,12 @@ mmu_notifier_range_blockable(const struct 
mmu_notifier_range *range)
return true;
 }
 
+static inline bool
+mmu_notifier_range_use_change_pte(const struct mmu_notifier_range *range)
+{
+   return false;
+}
+
 static inline int mm_has_notifiers(struct mm_struct *mm)
 {
return 0;
diff --git a/mm/ksm.c b/mm/ksm.c
index b782fadade8f..41e51882f999 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -1066,9 +1066,9 @@ static int write_protect_page(struct vm_area_struct *vma, 
struct page *page,
 
BUG_ON(PageTransCompound(page));
 
-   mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, mm,
-   pvmw.address,
-   pvmw.address + PAGE_SIZE);
+   mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR,
+   MMU_NOTIFIER_USE_CHANGE_PTE, vma, mm,
+   pvmw.address, pvmw.address + PAGE_SIZE);
mmu_notifier_invalidate_range_start(&range);
 
if (!page_vma_mapped_walk(&pvmw))
@@ -1155,8 +1155,9 @@ static int replace_page(struct vm_area_struct *vma, 
struct page *page,
if (!pmd)
goto out;
 
-   mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, mm, addr,
-   addr + PAGE_SIZE);
+   mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR,
+   MMU_NOTIFIER_USE_CHANGE_PTE,
+   vma, mm, addr, addr + PAGE_SIZE);
mmu_notifier_invalidate_range_start(&range);
 
ptep = pte_o

[PATCH v5 8/9] mm/mmu_notifier: mmu_notifier_range_update_to_read_only() helper

[jglisse]

From: Jérôme Glisse 

Helper to test if a range is updated to read only (it is still valid
to read from the range). This is useful for device driver or anyone
who wish to optimize out update when they know that they already have
the range map read only.

Signed-off-by: Jérôme Glisse 
Cc: Christian König 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Jan Kara 
Cc: Andrea Arcangeli 
Cc: Peter Xu 
Cc: Felix Kuehling 
Cc: Jason Gunthorpe 
Cc: Ross Zwisler 
Cc: Dan Williams 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Michal Hocko 
Cc: Christian Koenig 
Cc: Ralph Campbell 
Cc: John Hubbard 
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: Arnd Bergmann 
---
 include/linux/mmu_notifier.h |  4 
 mm/mmu_notifier.c| 10 ++
 2 files changed, 14 insertions(+)

diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index 0379956fff23..b6c004bd9f6a 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -259,6 +259,8 @@ extern void __mmu_notifier_invalidate_range_end(struct 
mmu_notifier_range *r,
  bool only_end);
 extern void __mmu_notifier_invalidate_range(struct mm_struct *mm,
  unsigned long start, unsigned long end);
+extern bool
+mmu_notifier_range_update_to_read_only(const struct mmu_notifier_range *range);
 
 static inline bool
 mmu_notifier_range_blockable(const struct mmu_notifier_range *range)
@@ -568,6 +570,8 @@ static inline void mmu_notifier_mm_destroy(struct mm_struct 
*mm)
 {
 }
 
+#define mmu_notifier_range_update_to_read_only(r) false
+
 #define ptep_clear_flush_young_notify ptep_clear_flush_young
 #define pmdp_clear_flush_young_notify pmdp_clear_flush_young
 #define ptep_clear_young_notify ptep_test_and_clear_young
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index abd88c466eb2..ee36068077b6 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -395,3 +395,13 @@ void mmu_notifier_unregister_no_release(struct 
mmu_notifier *mn,
mmdrop(mm);
 }
 EXPORT_SYMBOL_GPL(mmu_notifier_unregister_no_release);
+
+bool
+mmu_notifier_range_update_to_read_only(const struct mmu_notifier_range *range)
+{
+   if (!range->vma || range->event != MMU_NOTIFY_PROTECTION_VMA)
+   return false;
+   /* Return true if the vma still have the read flag set. */
+   return range->vma->vm_flags & VM_READ;
+}
+EXPORT_SYMBOL_GPL(mmu_notifier_range_update_to_read_only);
-- 
2.17.2

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

[PATCH v5 5/9] mm/mmu_notifier: contextual information for event triggering invalidation v2

[jglisse]

From: Jérôme Glisse 

CPU page table update can happens for many reasons, not only as a result
of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
as a result of kernel activities (memory compression, reclaim, migration,
...).

Users of mmu notifier API track changes to the CPU page table and take
specific action for them. While current API only provide range of virtual
address affected by the change, not why the changes is happening.

This patchset do the initial mechanical convertion of all the places that
calls mmu_notifier_range_init to also provide the default MMU_NOTIFY_UNMAP
event as well as the vma if it is know (most invalidation happens against
a given vma). Passing down the vma allows the users of mmu notifier to
inspect the new vma page protection.

The MMU_NOTIFY_UNMAP is always the safe default as users of mmu notifier
should assume that every for the range is going away when that event
happens. A latter patch do convert mm call path to use a more appropriate
events for each call.

Changes since v1:
- add the flags parameter to init range flags

This is done as 2 patches so that no call site is forgotten especialy
as it uses this following coccinelle patch:

%<--
@@
identifier I1, I2, I3, I4;
@@
static inline void mmu_notifier_range_init(struct mmu_notifier_range *I1,
+enum mmu_notifier_event event,
+unsigned flags,
+struct vm_area_struct *vma,
struct mm_struct *I2, unsigned long I3, unsigned long I4) { ... }

@@
@@
-#define mmu_notifier_range_init(range, mm, start, end)
+#define mmu_notifier_range_init(range, event, flags, vma, mm, start, end)

@@
expression E1, E3, E4;
identifier I1;
@@
<...
mmu_notifier_range_init(E1,
+MMU_NOTIFY_UNMAP, 0, I1,
I1->vm_mm, E3, E4)
...>

@@
expression E1, E2, E3, E4;
identifier FN, VMA;
@@
FN(..., struct vm_area_struct *VMA, ...) {
<...
mmu_notifier_range_init(E1,
+MMU_NOTIFY_UNMAP, 0, VMA,
E2, E3, E4)
...> }

@@
expression E1, E2, E3, E4;
identifier FN, VMA;
@@
FN(...) {
struct vm_area_struct *VMA;
<...
mmu_notifier_range_init(E1,
+MMU_NOTIFY_UNMAP, 0, VMA,
E2, E3, E4)
...> }

@@
expression E1, E2, E3, E4;
identifier FN;
@@
FN(...) {
<...
mmu_notifier_range_init(E1,
+MMU_NOTIFY_UNMAP, 0, NULL,
E2, E3, E4)
...> }
-->%

Applied with:
spatch --all-includes --sp-file mmu-notifier.spatch fs/proc/task_mmu.c 
--in-place
spatch --sp-file mmu-notifier.spatch --dir kernel/events/ --in-place
spatch --sp-file mmu-notifier.spatch --dir mm --in-place

Signed-off-by: Jérôme Glisse 
Cc: Christian König 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Jan Kara 
Cc: Andrea Arcangeli 
Cc: Peter Xu 
Cc: Felix Kuehling 
Cc: Jason Gunthorpe 
Cc: Ross Zwisler 
Cc: Dan Williams 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Michal Hocko 
Cc: Christian Koenig 
Cc: Ralph Campbell 
Cc: John Hubbard 
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: Arnd Bergmann 
---
 fs/proc/task_mmu.c   |  3 ++-
 include/linux/mmu_notifier.h |  5 -
 kernel/events/uprobes.c  |  3 ++-
 mm/huge_memory.c | 12 
 mm/hugetlb.c | 12 
 mm/khugepaged.c  |  3 ++-
 mm/ksm.c |  6 --
 mm/madvise.c |  3 ++-
 mm/memory.c  | 25 -
 mm/migrate.c |  5 -
 mm/mprotect.c|  3 ++-
 mm/mremap.c  |  3 ++-
 mm/oom_kill.c|  3 ++-
 mm/rmap.c|  6 --
 14 files changed, 62 insertions(+), 30 deletions(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 92a91e7816d8..fcbd0e574917 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1151,7 +1151,8 @@ static ssize_t clear_refs_write(struct file *file, const 
char __user *buf,
break;
}
 
-   mmu_notifier_range_init(&range, mm, 0, -1UL);
+   mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0,
+   NULL, mm, 0, -1UL);
mmu_notifier_invalidate_range_start(&range);
}
walk_page_range(0, mm->highest_vm_end, &clear_refs_walk);
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index 2386e71ac1b8..62f94cd85455 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -356,6 +356,9 @@ static inline void mmu_notifier_mm_destroy(struct mm_struct 
*mm)
 
 
 static inline void mmu_notifier_range_init(struct mmu_notifier_range *range,
+  enum mmu_notifier_event event,
+  unsigned flags,
+  struct vm_area_struct *vma,
   struct mm_struc

[PATCH v5 2/9] mm/mmu_notifier: convert user range->blockable to helper function

[jglisse]

From: Jérôme Glisse 

Use the mmu_notifier_range_blockable() helper function instead of
directly dereferencing the range->blockable field. This is done to
make it easier to change the mmu_notifier range field.

This patch is the outcome of the following coccinelle patch:

%<---
@@
identifier I1, FN;
@@
FN(..., struct mmu_notifier_range *I1, ...) {
<...
-I1->blockable
+mmu_notifier_range_blockable(I1)
...>
}
--->%

spatch --in-place --sp-file blockable.spatch --dir .

Signed-off-by: Jérôme Glisse 
Cc: Christian König 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Jan Kara 
Cc: Andrea Arcangeli 
Cc: Peter Xu 
Cc: Felix Kuehling 
Cc: Jason Gunthorpe 
Cc: Ross Zwisler 
Cc: Dan Williams 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Michal Hocko 
Cc: Christian Koenig 
Cc: Ralph Campbell 
Cc: John Hubbard 
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: Arnd Bergmann 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c  | 8 
 drivers/gpu/drm/i915/i915_gem_userptr.c | 2 +-
 drivers/gpu/drm/radeon/radeon_mn.c  | 4 ++--
 drivers/infiniband/core/umem_odp.c  | 5 +++--
 drivers/xen/gntdev.c| 6 +++---
 mm/hmm.c| 6 +++---
 mm/mmu_notifier.c   | 2 +-
 virt/kvm/kvm_main.c | 3 ++-
 8 files changed, 19 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
index 3e6823fdd939..58ed401c5996 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
@@ -256,14 +256,14 @@ static int amdgpu_mn_invalidate_range_start_gfx(struct 
mmu_notifier *mn,
/* TODO we should be able to split locking for interval tree and
 * amdgpu_mn_invalidate_node
 */
-   if (amdgpu_mn_read_lock(amn, range->blockable))
+   if (amdgpu_mn_read_lock(amn, mmu_notifier_range_blockable(range)))
return -EAGAIN;
 
it = interval_tree_iter_first(&amn->objects, range->start, end);
while (it) {
struct amdgpu_mn_node *node;
 
-   if (!range->blockable) {
+   if (!mmu_notifier_range_blockable(range)) {
amdgpu_mn_read_unlock(amn);
return -EAGAIN;
}
@@ -299,7 +299,7 @@ static int amdgpu_mn_invalidate_range_start_hsa(struct 
mmu_notifier *mn,
/* notification is exclusive, but interval is inclusive */
end = range->end - 1;
 
-   if (amdgpu_mn_read_lock(amn, range->blockable))
+   if (amdgpu_mn_read_lock(amn, mmu_notifier_range_blockable(range)))
return -EAGAIN;
 
it = interval_tree_iter_first(&amn->objects, range->start, end);
@@ -307,7 +307,7 @@ static int amdgpu_mn_invalidate_range_start_hsa(struct 
mmu_notifier *mn,
struct amdgpu_mn_node *node;
struct amdgpu_bo *bo;
 
-   if (!range->blockable) {
+   if (!mmu_notifier_range_blockable(range)) {
amdgpu_mn_read_unlock(amn);
return -EAGAIN;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c 
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 1d3f9a31ad61..777b3f8727e7 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -122,7 +122,7 @@ userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
while (it) {
struct drm_i915_gem_object *obj;
 
-   if (!range->blockable) {
+   if (!mmu_notifier_range_blockable(range)) {
ret = -EAGAIN;
break;
}
diff --git a/drivers/gpu/drm/radeon/radeon_mn.c 
b/drivers/gpu/drm/radeon/radeon_mn.c
index b3019505065a..c9bd1278f573 100644
--- a/drivers/gpu/drm/radeon/radeon_mn.c
+++ b/drivers/gpu/drm/radeon/radeon_mn.c
@@ -133,7 +133,7 @@ static int radeon_mn_invalidate_range_start(struct 
mmu_notifier *mn,
/* TODO we should be able to split locking for interval tree and
 * the tear down.
 */
-   if (range->blockable)
+   if (mmu_notifier_range_blockable(range))
mutex_lock(&rmn->lock);
else if (!mutex_trylock(&rmn->lock))
return -EAGAIN;
@@ -144,7 +144,7 @@ static int radeon_mn_invalidate_range_start(struct 
mmu_notifier *mn,
struct radeon_bo *bo;
long r;
 
-   if (!range->blockable) {
+   if (!mmu_notifier_range_blockable(range)) {
ret = -EAGAIN;
goto out_unlock;
}
diff --git a/drivers/infiniband/core/umem_odp.c 
b/drivers/infiniband/core/umem_odp.c
index 012044f16d1c..3a3f1538d295 100644
--- a/drivers/infiniband/core/umem_odp.c
+++ 

[PATCH v5 4/9] mm/mmu_notifier: contextual information for event enums

[jglisse]

From: Jérôme Glisse 

CPU page table update can happens for many reasons, not only as a result
of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
as a result of kernel activities (memory compression, reclaim, migration,
...).

This patch introduce a set of enums that can be associated with each of
the events triggering a mmu notifier. Latter patches take advantages of
those enum values.

- UNMAP: munmap() or mremap()
- CLEAR: page table is cleared (migration, compaction, reclaim, ...)
- PROTECTION_VMA: change in access protections for the range
- PROTECTION_PAGE: change in access protections for page in the range
- SOFT_DIRTY: soft dirtyness tracking

Being able to identify munmap() and mremap() from other reasons why the
page table is cleared is important to allow user of mmu notifier to
update their own internal tracking structure accordingly (on munmap or
mremap it is not longer needed to track range of virtual address as it
becomes invalid).

Signed-off-by: Jérôme Glisse 
Cc: Christian König 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Jan Kara 
Cc: Andrea Arcangeli 
Cc: Peter Xu 
Cc: Felix Kuehling 
Cc: Jason Gunthorpe 
Cc: Ross Zwisler 
Cc: Dan Williams 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Michal Hocko 
Cc: Christian Koenig 
Cc: Ralph Campbell 
Cc: John Hubbard 
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: Arnd Bergmann 
---
 include/linux/mmu_notifier.h | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index c8672c366f67..2386e71ac1b8 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -10,6 +10,36 @@
 struct mmu_notifier;
 struct mmu_notifier_ops;
 
+/**
+ * enum mmu_notifier_event - reason for the mmu notifier callback
+ * @MMU_NOTIFY_UNMAP: either munmap() that unmap the range or a mremap() that
+ * move the range
+ *
+ * @MMU_NOTIFY_CLEAR: clear page table entry (many reasons for this like
+ * madvise() or replacing a page by another one, ...).
+ *
+ * @MMU_NOTIFY_PROTECTION_VMA: update is due to protection change for the range
+ * ie using the vma access permission (vm_page_prot) to update the whole range
+ * is enough no need to inspect changes to the CPU page table (mprotect()
+ * syscall)
+ *
+ * @MMU_NOTIFY_PROTECTION_PAGE: update is due to change in read/write flag for
+ * pages in the range so to mirror those changes the user must inspect the CPU
+ * page table (from the end callback).
+ *
+ * @MMU_NOTIFY_SOFT_DIRTY: soft dirty accounting (still same page and same
+ * access flags). User should soft dirty the page in the end callback to make
+ * sure that anyone relying on soft dirtyness catch pages that might be written
+ * through non CPU mappings.
+ */
+enum mmu_notifier_event {
+   MMU_NOTIFY_UNMAP = 0,
+   MMU_NOTIFY_CLEAR,
+   MMU_NOTIFY_PROTECTION_VMA,
+   MMU_NOTIFY_PROTECTION_PAGE,
+   MMU_NOTIFY_SOFT_DIRTY,
+};
+
 #ifdef CONFIG_MMU_NOTIFIER
 
 /*
-- 
2.17.2

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

[PATCH v5 7/9] mm/mmu_notifier: pass down vma and reasons why mmu notifier is happening v2

[jglisse]

From: Jérôme Glisse 

CPU page table update can happens for many reasons, not only as a result
of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
as a result of kernel activities (memory compression, reclaim, migration,
...).

Users of mmu notifier API track changes to the CPU page table and take
specific action for them. While current API only provide range of virtual
address affected by the change, not why the changes is happening

This patch is just passing down the new informations by adding it to the
mmu_notifier_range structure.

Changes since v1:
- Initialize flags field from mmu_notifier_range_init() arguments

Signed-off-by: Jérôme Glisse 
Cc: Christian König 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Jan Kara 
Cc: Andrea Arcangeli 
Cc: Peter Xu 
Cc: Felix Kuehling 
Cc: Jason Gunthorpe 
Cc: Ross Zwisler 
Cc: Dan Williams 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Michal Hocko 
Cc: Christian Koenig 
Cc: Ralph Campbell 
Cc: John Hubbard 
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: Arnd Bergmann 
---
 include/linux/mmu_notifier.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index 62f94cd85455..0379956fff23 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -58,10 +58,12 @@ struct mmu_notifier_mm {
 #define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0)
 
 struct mmu_notifier_range {
+   struct vm_area_struct *vma;
struct mm_struct *mm;
unsigned long start;
unsigned long end;
unsigned flags;
+   enum mmu_notifier_event event;
 };
 
 struct mmu_notifier_ops {
@@ -363,10 +365,12 @@ static inline void mmu_notifier_range_init(struct 
mmu_notifier_range *range,
   unsigned long start,
   unsigned long end)
 {
+   range->vma = vma;
+   range->event = event;
range->mm = mm;
range->start = start;
range->end = end;
-   range->flags = 0;
+   range->flags = flags;
 }
 
 #define ptep_clear_flush_young_notify(__vma, __address, __ptep)
\
-- 
2.17.2

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

[PATCH v5 0/9] mmu notifier provide context informations

[jglisse]

From: Jérôme Glisse 

Since last version [4] i added the extra bits needed for the change_pte
optimization (which is a KSM thing). Here i am not posting users of
this, they will be posted to the appropriate sub-systems (KVM, GPU,
RDMA, ...) once this serie get upstream. If you want to look at users
of this see [5] [6]. If this gets in 5.1 then i will be submitting
those users for 5.2 (including KVM if KVM folks feel comfortable with
it).

Note that this serie does not change any behavior for any existing
code. It just pass down more informations to mmu notifier listener.

The rational for this patchset:


CPU page table update can happens for many reasons, not only as a
result of a syscall (munmap(), mprotect(), mremap(), madvise(), ...)
but also as a result of kernel activities (memory compression, reclaim,
migration, ...).

This patch introduce a set of enums that can be associated with each
of the events triggering a mmu notifier:

- UNMAP: munmap() or mremap()
- CLEAR: page table is cleared (migration, compaction, reclaim, ...)
- PROTECTION_VMA: change in access protections for the range
- PROTECTION_PAGE: change in access protections for page in the range
- SOFT_DIRTY: soft dirtyness tracking

Being able to identify munmap() and mremap() from other reasons why the
page table is cleared is important to allow user of mmu notifier to
update their own internal tracking structure accordingly (on munmap or
mremap it is not longer needed to track range of virtual address as it
becomes invalid). Without this serie, driver are force to assume that
every notification is an munmap which triggers useless trashing within
drivers that associate structure with range of virtual address. Each
driver is force to free up its tracking structure and then restore it
on next device page fault. With this serie we can also optimize device
page table update [5].

More over this can also be use to optimize out some page table updates
like for KVM where we can update the secondary MMU directly from the
callback instead of clearing it.

Patches to leverage this serie will be posted separately to each sub-
system.

Cheers,
Jérôme

[1] v1 https://lkml.org/lkml/2018/3/23/1049
[2] v2 https://lkml.org/lkml/2018/12/5/10
[3] v3 https://lkml.org/lkml/2018/12/13/620
[4] v4 https://lkml.org/lkml/2019/1/23/838
[5] patches to use this:
https://lkml.org/lkml/2019/1/23/833
https://lkml.org/lkml/2019/1/23/834
https://lkml.org/lkml/2019/1/23/832
https://lkml.org/lkml/2019/1/23/831
[6] KVM restore change pte optimization
https://patchwork.kernel.org/cover/10791179/

Cc: Christian König 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Jan Kara 
Cc: Andrea Arcangeli 
Cc: Peter Xu 
Cc: Felix Kuehling 
Cc: Jason Gunthorpe 
Cc: Andrew Morton 
Cc: Ross Zwisler 
Cc: Dan Williams 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Michal Hocko 
Cc: Christian Koenig 
Cc: Ralph Campbell 
Cc: John Hubbard 
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: linux-fsde...@vger.kernel.org
Cc: Arnd Bergmann 

Jérôme Glisse (9):
  mm/mmu_notifier: helper to test if a range invalidation is blockable
  mm/mmu_notifier: convert user range->blockable to helper function
  mm/mmu_notifier: convert mmu_notifier_range->blockable to a flags
  mm/mmu_notifier: contextual information for event enums
  mm/mmu_notifier: contextual information for event triggering
invalidation v2
  mm/mmu_notifier: use correct mmu_notifier events for each invalidation
  mm/mmu_notifier: pass down vma and reasons why mmu notifier is
happening v2
  mm/mmu_notifier: mmu_notifier_range_update_to_read_only() helper
  mm/mmu_notifier: set MMU_NOTIFIER_USE_CHANGE_PTE flag where
appropriate v2

 drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c  |  8 +--
 drivers/gpu/drm/i915/i915_gem_userptr.c |  2 +-
 drivers/gpu/drm/radeon/radeon_mn.c  |  4 +-
 drivers/infiniband/core/umem_odp.c  |  5 +-
 drivers/xen/gntdev.c|  6 +-
 fs/proc/task_mmu.c  |  3 +-
 include/linux/mmu_notifier.h| 93 +++--
 kernel/events/uprobes.c |  3 +-
 mm/hmm.c|  6 +-
 mm/huge_memory.c| 14 ++--
 mm/hugetlb.c| 12 ++--
 mm/khugepaged.c |  3 +-
 mm/ksm.c|  9 ++-
 mm/madvise.c|  3 +-
 mm/memory.c | 26 ---
 mm/migrate.c|  5 +-
 mm/mmu_notifier.c   | 12 +++-
 mm/mprotect.c   |  4 +-
 mm/mremap.c |  3 +-
 mm/oom_kill.c   |  3 +-
 mm/rmap.c   |  6 +-
 virt/kvm/kvm_main.c |  3 +-
 22 files changed, 180 insertions(+), 53 deletions(-)

-- 
2.17.2

___
dri

[PATCH v5 6/9] mm/mmu_notifier: use correct mmu_notifier events for each invalidation

[jglisse]

From: Jérôme Glisse 

This update each existing invalidation to use the correct mmu notifier
event that represent what is happening to the CPU page table. See the
patch which introduced the events to see the rational behind this.

Signed-off-by: Jérôme Glisse 
Cc: Christian König 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Jan Kara 
Cc: Andrea Arcangeli 
Cc: Peter Xu 
Cc: Felix Kuehling 
Cc: Jason Gunthorpe 
Cc: Ross Zwisler 
Cc: Dan Williams 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Michal Hocko 
Cc: Christian Koenig 
Cc: Ralph Campbell 
Cc: John Hubbard 
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: Arnd Bergmann 
---
 fs/proc/task_mmu.c  |  4 ++--
 kernel/events/uprobes.c |  2 +-
 mm/huge_memory.c| 14 ++
 mm/hugetlb.c|  8 
 mm/khugepaged.c |  2 +-
 mm/ksm.c|  4 ++--
 mm/madvise.c|  2 +-
 mm/memory.c | 14 +++---
 mm/migrate.c|  4 ++--
 mm/mprotect.c   |  5 +++--
 mm/rmap.c   |  6 +++---
 11 files changed, 32 insertions(+), 33 deletions(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index fcbd0e574917..3b93ce496dd4 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1151,8 +1151,8 @@ static ssize_t clear_refs_write(struct file *file, const 
char __user *buf,
break;
}
 
-   mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0,
-   NULL, mm, 0, -1UL);
+   mmu_notifier_range_init(&range, MMU_NOTIFY_SOFT_DIRTY,
+   0, NULL, mm, 0, -1UL);
mmu_notifier_invalidate_range_start(&range);
}
walk_page_range(0, mm->highest_vm_end, &clear_refs_walk);
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 46f546bdba00..8e8342080013 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -161,7 +161,7 @@ static int __replace_page(struct vm_area_struct *vma, 
unsigned long addr,
struct mmu_notifier_range range;
struct mem_cgroup *memcg;
 
-   mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, mm, addr,
+   mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, mm, addr,
addr + PAGE_SIZE);
 
VM_BUG_ON_PAGE(PageTransHuge(old_page), old_page);
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index c9d638f1b34e..1da6ca0f0f6d 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1184,9 +1184,8 @@ static vm_fault_t do_huge_pmd_wp_page_fallback(struct 
vm_fault *vmf,
cond_resched();
}
 
-   mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, vma->vm_mm,
-   haddr,
-   haddr + HPAGE_PMD_SIZE);
+   mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm,
+   haddr, haddr + HPAGE_PMD_SIZE);
mmu_notifier_invalidate_range_start(&range);
 
vmf->ptl = pmd_lock(vma->vm_mm, vmf->pmd);
@@ -1349,9 +1348,8 @@ vm_fault_t do_huge_pmd_wp_page(struct vm_fault *vmf, 
pmd_t orig_pmd)
vma, HPAGE_PMD_NR);
__SetPageUptodate(new_page);
 
-   mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, vma->vm_mm,
-   haddr,
-   haddr + HPAGE_PMD_SIZE);
+   mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm,
+   haddr, haddr + HPAGE_PMD_SIZE);
mmu_notifier_invalidate_range_start(&range);
 
spin_lock(vmf->ptl);
@@ -2028,7 +2026,7 @@ void __split_huge_pud(struct vm_area_struct *vma, pud_t 
*pud,
spinlock_t *ptl;
struct mmu_notifier_range range;
 
-   mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, vma->vm_mm,
+   mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm,
address & HPAGE_PUD_MASK,
(address & HPAGE_PUD_MASK) + HPAGE_PUD_SIZE);
mmu_notifier_invalidate_range_start(&range);
@@ -2247,7 +2245,7 @@ void __split_huge_pmd(struct vm_area_struct *vma, pmd_t 
*pmd,
spinlock_t *ptl;
struct mmu_notifier_range range;
 
-   mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, vma->vm_mm,
+   mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm,
address & HPAGE_PMD_MASK,
(address & HPAGE_PMD_MASK) + HPAGE_PMD_SIZE);
mmu_notifier_invalidate_range_start(&range);
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index d9e5c5a4c004..a58115c6b0a3 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -3250,7 +3250,7 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct 
mm_st

[PATCH v5 1/9] mm/mmu_notifier: helper to test if a range invalidation is blockable

[jglisse]

From: Jérôme Glisse 

Simple helpers to test if range invalidation is blockable. Latter
patches use cocinnelle to convert all direct dereference of range->
blockable to use this function instead so that we can convert the
blockable field to an unsigned for more flags.

Signed-off-by: Jérôme Glisse 
Cc: Christian König 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Jan Kara 
Cc: Andrea Arcangeli 
Cc: Peter Xu 
Cc: Felix Kuehling 
Cc: Jason Gunthorpe 
Cc: Andrew Morton 
Cc: Ross Zwisler 
Cc: Dan Williams 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Michal Hocko 
Cc: Christian Koenig 
Cc: Ralph Campbell 
Cc: John Hubbard 
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: linux-fsde...@vger.kernel.org
Cc: Arnd Bergmann 
---
 include/linux/mmu_notifier.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index 4050ec1c3b45..e630def131ce 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -226,6 +226,12 @@ extern void __mmu_notifier_invalidate_range_end(struct 
mmu_notifier_range *r,
 extern void __mmu_notifier_invalidate_range(struct mm_struct *mm,
  unsigned long start, unsigned long end);
 
+static inline bool
+mmu_notifier_range_blockable(const struct mmu_notifier_range *range)
+{
+   return range->blockable;
+}
+
 static inline void mmu_notifier_release(struct mm_struct *mm)
 {
if (mm_has_notifiers(mm))
@@ -455,6 +461,11 @@ static inline void _mmu_notifier_range_init(struct 
mmu_notifier_range *range,
 #define mmu_notifier_range_init(range, mm, start, end) \
_mmu_notifier_range_init(range, start, end)
 
+static inline bool
+mmu_notifier_range_blockable(const struct mmu_notifier_range *range)
+{
+   return true;
+}
 
 static inline int mm_has_notifiers(struct mm_struct *mm)
 {
-- 
2.17.2

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

[PATCH v5 3/9] mm/mmu_notifier: convert mmu_notifier_range->blockable to a flags

[jglisse]

From: Jérôme Glisse 

Use an unsigned field for flags other than blockable and convert
the blockable field to be one of those flags.

Signed-off-by: Jérôme Glisse 
Cc: Christian König 
Cc: Joonas Lahtinen 
Cc: Jani Nikula 
Cc: Rodrigo Vivi 
Cc: Jan Kara 
Cc: Andrea Arcangeli 
Cc: Peter Xu 
Cc: Felix Kuehling 
Cc: Jason Gunthorpe 
Cc: Andrew Morton 
Cc: Ross Zwisler 
Cc: Dan Williams 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Michal Hocko 
Cc: Christian Koenig 
Cc: Ralph Campbell 
Cc: John Hubbard 
Cc: k...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: Arnd Bergmann 
---
 include/linux/mmu_notifier.h | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index e630def131ce..c8672c366f67 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -25,11 +25,13 @@ struct mmu_notifier_mm {
spinlock_t lock;
 };
 
+#define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0)
+
 struct mmu_notifier_range {
struct mm_struct *mm;
unsigned long start;
unsigned long end;
-   bool blockable;
+   unsigned flags;
 };
 
 struct mmu_notifier_ops {
@@ -229,7 +231,7 @@ extern void __mmu_notifier_invalidate_range(struct 
mm_struct *mm,
 static inline bool
 mmu_notifier_range_blockable(const struct mmu_notifier_range *range)
 {
-   return range->blockable;
+   return (range->flags & MMU_NOTIFIER_RANGE_BLOCKABLE);
 }
 
 static inline void mmu_notifier_release(struct mm_struct *mm)
@@ -275,7 +277,7 @@ static inline void
 mmu_notifier_invalidate_range_start(struct mmu_notifier_range *range)
 {
if (mm_has_notifiers(range->mm)) {
-   range->blockable = true;
+   range->flags |= MMU_NOTIFIER_RANGE_BLOCKABLE;
__mmu_notifier_invalidate_range_start(range);
}
 }
@@ -284,7 +286,7 @@ static inline int
 mmu_notifier_invalidate_range_start_nonblock(struct mmu_notifier_range *range)
 {
if (mm_has_notifiers(range->mm)) {
-   range->blockable = false;
+   range->flags &= ~MMU_NOTIFIER_RANGE_BLOCKABLE;
return __mmu_notifier_invalidate_range_start(range);
}
return 0;
@@ -331,6 +333,7 @@ static inline void mmu_notifier_range_init(struct 
mmu_notifier_range *range,
range->mm = mm;
range->start = start;
range->end = end;
+   range->flags = 0;
 }
 
 #define ptep_clear_flush_young_notify(__vma, __address, __ptep)
\
-- 
2.17.2

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

Re: [PATCH] drm/amd/powerplay/smu10_hwmgr: use struct_size() in kzalloc()

[Alex Deucher]

On Tue, Feb 19, 2019 at 1:55 PM Gustavo A. R. Silva
 wrote:
>
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo {
> int stuff;
> struct boo entry[];
> };
>
> size = sizeof(struct foo) + count * sizeof(struct boo);
> instance = kzalloc(size, GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
>
> Notice that, in this case, variable table_size is not necessary, hence
> it is removed.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva 

Applied this and the smu8 patch.  Thanks!

Alex

> ---
>  drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> index 5273de3c5b98..0ad8fe4a6277 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
> @@ -139,12 +139,10 @@ static int 
> smu10_construct_max_power_limits_table(struct pp_hwmgr *hwmgr,
>  static int smu10_init_dynamic_state_adjustment_rule_settings(
> struct pp_hwmgr 
> *hwmgr)
>  {
> -   uint32_t table_size =
> -   sizeof(struct phm_clock_voltage_dependency_table) +
> -   (7 * sizeof(struct phm_clock_voltage_dependency_record));
> +   struct phm_clock_voltage_dependency_table *table_clk_vlt;
>
> -   struct phm_clock_voltage_dependency_table *table_clk_vlt =
> -   kzalloc(table_size, GFP_KERNEL);
> +   table_clk_vlt = kzalloc(struct_size(table_clk_vlt, entries, 7),
> +   GFP_KERNEL);
>
> if (NULL == table_clk_vlt) {
> pr_err("Can not allocate memory!\n");
> --
> 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

[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U

[bugzilla-daemon]

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

--- Comment #14 from Harry Wentland  ---
I'd recommend updating the System BIOS.

Early BIOSes on HP Envy x360 (and possibly other Raven laptops) had trouble
loading the DMCU FW.

-- 
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 202537] amdgpu/DC failed to reserve new abo buffer before flip

[bugzilla-daemon]

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

--- Comment #22 from Paul Menzel (pmenzel+bugzilla.kernel@molgen.mpg.de) ---
Ok, being back at the system after some days, I see the kmemleaks are still
present with Linux 5.0-rc6+.

Bernd, what triggers this on your system? What is your test case? Start some
program?

-- 
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 109679] [CI][BAT] CHAMELIUM: igt@kms_chamelium@hdmi-crc-fast - fail - Chamelium RPC call failed: RPC failed at server. :integer division or

[bugzilla-daemon]

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

Easwar Hariharan  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |stuart.summ...@intel.com
   |.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

[PATCH] drm/amd/powerplay/smu10_hwmgr: use struct_size() in kzalloc()

[Gustavo A. R. Silva]

One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:

struct foo {
int stuff;
struct boo entry[];
};

size = sizeof(struct foo) + count * sizeof(struct boo);
instance = kzalloc(size, GFP_KERNEL);

Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:

instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);

Notice that, in this case, variable table_size is not necessary, hence
it is removed.

This code was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
index 5273de3c5b98..0ad8fe4a6277 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c
@@ -139,12 +139,10 @@ static int smu10_construct_max_power_limits_table(struct 
pp_hwmgr *hwmgr,
 static int smu10_init_dynamic_state_adjustment_rule_settings(
struct pp_hwmgr *hwmgr)
 {
-   uint32_t table_size =
-   sizeof(struct phm_clock_voltage_dependency_table) +
-   (7 * sizeof(struct phm_clock_voltage_dependency_record));
+   struct phm_clock_voltage_dependency_table *table_clk_vlt;
 
-   struct phm_clock_voltage_dependency_table *table_clk_vlt =
-   kzalloc(table_size, GFP_KERNEL);
+   table_clk_vlt = kzalloc(struct_size(table_clk_vlt, entries, 7),
+   GFP_KERNEL);
 
if (NULL == table_clk_vlt) {
pr_err("Can not allocate memory!\n");
-- 
2.20.1

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

[PATCH] drm/msm: Remove pm_runtime calls from msm_iommu.c

[Jordan Crouse]

Currently the IOMMU code calls pm_runtime_get/put on the GPU or display
device before doing a IOMMU operation. This was because usually the
IOMMU driver didn't do power control of its own and since the hardware
used the same clocks and power as the respective multimedia device it
was a easy way to make sure that the power was available.

Now two things have changed. First, the SMMU devices can do their own power
control and more important bringing up the a6xx GPU isn't as easy as
turning on some clocks. To bring the GPU up we need the GMU which itself
needs the IOMMU so we have a chicken and egg problem.

Luckily this is easily fixed by removing the pm_runtime calls from the
functions and letting the device link to the IOMMU device handle the magic.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/msm_iommu.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index 4d62790..12bb54c 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -38,13 +38,8 @@ static int msm_iommu_attach(struct msm_mmu *mmu, const char 
* const *names,
int cnt)
 {
struct msm_iommu *iommu = to_msm_iommu(mmu);
-   int ret;
 
-   pm_runtime_get_sync(mmu->dev);
-   ret = iommu_attach_device(iommu->domain, mmu->dev);
-   pm_runtime_put_sync(mmu->dev);
-
-   return ret;
+   return iommu_attach_device(iommu->domain, mmu->dev);
 }
 
 static void msm_iommu_detach(struct msm_mmu *mmu, const char * const *names,
@@ -52,9 +47,7 @@ static void msm_iommu_detach(struct msm_mmu *mmu, const char 
* const *names,
 {
struct msm_iommu *iommu = to_msm_iommu(mmu);
 
-   pm_runtime_get_sync(mmu->dev);
iommu_detach_device(iommu->domain, mmu->dev);
-   pm_runtime_put_sync(mmu->dev);
 }
 
 static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova,
@@ -63,9 +56,7 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova,
struct msm_iommu *iommu = to_msm_iommu(mmu);
size_t ret;
 
-// pm_runtime_get_sync(mmu->dev);
ret = iommu_map_sg(iommu->domain, iova, sgt->sgl, sgt->nents, prot);
-// pm_runtime_put_sync(mmu->dev);
WARN_ON(!ret);
 
return (ret == len) ? 0 : -EINVAL;
@@ -75,9 +66,7 @@ static int msm_iommu_unmap(struct msm_mmu *mmu, uint64_t 
iova, unsigned len)
 {
struct msm_iommu *iommu = to_msm_iommu(mmu);
 
-   pm_runtime_get_sync(mmu->dev);
iommu_unmap(iommu->domain, iova, len);
-   pm_runtime_put_sync(mmu->dev);
 
return 0;
 }
-- 
2.7.4

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

[PATCH] drm/amd/powerplay/smu8_hwmgr: use struct_size() in kzalloc()

[Gustavo A. R. Silva]

One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:

struct foo {
int stuff;
struct boo entry[];
};

size = sizeof(struct foo) + count * sizeof(struct boo);
instance = kzalloc(size, GFP_KERNEL);

Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:

instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);

Notice that, in this case, variable table_size is not necessary, hence
it is removed.

This code was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
index 553a203ac47c..019d6a206492 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
@@ -272,12 +272,10 @@ static int 
smu8_init_dynamic_state_adjustment_rule_settings(
struct pp_hwmgr *hwmgr,
ATOM_CLK_VOLT_CAPABILITY *disp_voltage_table)
 {
-   uint32_t table_size =
-   sizeof(struct phm_clock_voltage_dependency_table) +
-   (7 * sizeof(struct phm_clock_voltage_dependency_record));
+   struct phm_clock_voltage_dependency_table *table_clk_vlt;
 
-   struct phm_clock_voltage_dependency_table *table_clk_vlt =
-   kzalloc(table_size, GFP_KERNEL);
+   table_clk_vlt = kzalloc(struct_size(table_clk_vlt, entries, 7),
+   GFP_KERNEL);
 
if (NULL == table_clk_vlt) {
pr_err("Can not allocate memory!\n");
-- 
2.20.1

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

[PATCH RESEND] drm/msm: Truncate the buffer object name if the copy from user failed

[Jordan Crouse]

(Resend since there was a compile error that I forgot to commit before sending)

If there is a error while doing a copy_from_user() for MSM_INFO_SET_NAME
make sure to truncate the object name so that there isn't a chance that
we'll have random data in the string.

This is on top of [1] reported and fixed by Dan Carpenter.

[1] https://patchwork.freedesktop.org/series/56656/

Fixes: f05c83e77460 ("drm/msm: add uapi to get/set debug name")
Reported-by: Dan Carpenter 
Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/msm_drv.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 87eae44..906b2bb 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -852,8 +852,11 @@ static int msm_ioctl_gem_info(struct drm_device *dev, void 
*data,
break;
}
if (copy_from_user(msm_obj->name, u64_to_user_ptr(args->value),
-  args->len))
+  args->len)) {
+   msm_obj->name[0] = '\0';
ret = -EFAULT;
+   break;
+   }
msm_obj->name[args->len] = '\0';
for (i = 0; i < args->len; i++) {
if (!isprint(msm_obj->name[i])) {
-- 
2.7.4

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

[PATCH] drm/msm: Truncate the buffer object name if the copy from user failed

[Jordan Crouse]

If there is a error while doing a copy_from_user() for MSM_INFO_SET_NAME
make sure to truncate the object name so that there isn't a chance that
we'll have random data in the string.

This is on top of [1] reported and fixed by Dan Carpenter.

[1] https://patchwork.freedesktop.org/series/56656/

Fixes: f05c83e77460 ("drm/msm: add uapi to get/set debug name")
Reported-by: Dan Carpenter 
Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/msm_drv.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 87eae44..9ca558d 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -852,8 +852,11 @@ static int msm_ioctl_gem_info(struct drm_device *dev, void 
*data,
break;
}
if (copy_from_user(msm_obj->name, u64_to_user_ptr(args->value),
-  args->len))
+  args->len)) {
+   msm_obj->name[0] = '\0'
ret = -EFAULT;
+   break;
+   }
msm_obj->name[args->len] = '\0';
for (i = 0; i < args->len; i++) {
if (!isprint(msm_obj->name[i])) {
-- 
2.7.4

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

[Bug 109679] [CI][BAT] CHAMELIUM: igt@kms_chamelium@hdmi-crc-fast - fail - Chamelium RPC call failed: RPC failed at server. :integer division or

[bugzilla-daemon]

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

--- Comment #4 from Stuart Summers  ---
Sent that previous comment a little too quickly... It looks like we aren't
actually sending those 0's in the first place, in addition to my off-by-one
(given we are taking 0 - 1, not 0) miss:
  (w && h) ? "(ii)" : "(ii)",

>From chameleond, this will autofill x, y, width, and height based on the
current resolution. Maybe the resolution was misconfigured? Or perhaps there's
an issue in the chamelium FPGA?

I still think it would be interesting here to get the chameleond log (see
request here: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/29 + the
recent patch I posted to igt). There is quite a bit of state logging in
chameleond with that patch run locally with --d.

The only other thing I see interesting in the logs is this, just before the
error:
(kms_chamelium:2877) igt_chamelium-DEBUG: Chamelium needs FSM, handling

I don't see that when I run locally. Maybe we're getting a spurious hotplug
event while trying to capture video? Or maybe the video capture is taking to
long and/or hung for some reason, causing the hotplug to timeout?

-- 
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 109679] [CI][BAT] CHAMELIUM: igt@kms_chamelium@hdmi-crc-fast - fail - Chamelium RPC call failed: RPC failed at server. :integer division or

[bugzilla-daemon]

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

--- Comment #3 from Stuart Summers  ---
Agree this looks like an issue in IGT or possibly in the chameleond daemon. At
a quick glance, there aren't a whole lot of places in the CaptureVideo path
that might trigger this exception in chameleond. It does look feasible that if
we were to pass a 0 for width and height, we could potentially get a
div-by-zero exception when chameleond prepares the video output:
CaptureVideo ->
_PrepareCapturingVideo/_captured_params['max_frame_limit']/flow_manager.GetMaxFrameLimit
-> input_flow.GetMaxFrameLimit -> frame_manager.GetMaxFrameLimit ->
field_manager.GetMaxFieldLimit -> VideoDumper.GetMaxFieldLimit:
  def GetMaxFieldLimit(cls, width, height):  
"""Returns of the maximal number of fields which can be dumped.""" 
BYTE_PER_PIXEL = 3 
PAGE_SIZE = 4096 
field_size = width * height * BYTE_PER_PIXEL   
field_size = ((field_size - 1) / PAGE_SIZE + 1) * PAGE_SIZE
return cls._DUMP_BUFFER_SIZE / field_size

That said, running this myself locally does not result in the failure of this
sighting, and from kms_chamelium.c, during the CRC check, we are passing 0 for
width and height:
  chamelium_capture(data->chamelium, port, 0, 0, 0, 0, count);

So I'd expect this to fail all the time if the issue were in the Python call I
indicated above.

And I'd also expect for CI to have seen this already if that were the case,
given this code has been present for some time.

-- 
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: [Mesa-dev] [PATCH] intel: Add more PCI Device IDs for Coffee Lake and Ice Lake.

[Ville Syrjälä]

On Tue, Feb 19, 2019 at 09:36:14AM -0800, Rodrigo Vivi wrote:
> On Mon, Feb 18, 2019 at 04:54:34PM +1100, Jonathan Gray wrote:
> > Compared to linux and libdrm Mesa is missing a VLV and ICL id.
> > 
> > 0x0f30
> > ff049b6ce21d2814451afd4a116d001712e0116b
> > drm/i915: bind driver to ValleyView chipsets
> > 
> > 0x8A70
> > d55cb4fa2cf0105bfb16b60a2846737b91fdc173
> > drm/i915/icl: Add the ICL PCI IDs
> > 
> > The Intel Media SDK describes these as
> > 
> > /* VLV */
> > { 0x0f30, MFX_HW_VLV, MFX_GT1 },   /* VLV mobile */
> 
> hmmm... no idea about this one...
> Ville?
> maybe we should just remove from kernel since it was never
> missed from Mesa?

Bspec says that is the infamous X0. Assuming it's not
lying to us it should be safe to remove.

> 
> > 
> > /* ICL LP */
> > { 0x8A70, MFX_HW_ICL_LP, MFX_GT1 }
> 
> This is pure display so no Mesa needed for this ID.
> 
> > 
> > and libdrm's intel_chipset.h describes the VLV id as
> > 
> > #define PCI_CHIP_VALLEYVIEW_PO  0x0f30 /* VLV PO board */
> > 
> > It isn't clear what the ICL configuration should be from public
> > information.
> > 
> > diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
> > index b91abd7a3f9..3568007b1ef 100644
> > --- a/include/pci_ids/i965_pci_ids.h
> > +++ b/include/pci_ids/i965_pci_ids.h
> > @@ -86,6 +86,7 @@ CHIPSET(0x0D2B, hsw_gt3, "Intel(R) Haswell")
> >  CHIPSET(0x0D0E, hsw_gt1, "Intel(R) Haswell")
> >  CHIPSET(0x0D1E, hsw_gt2, "Intel(R) Haswell")
> >  CHIPSET(0x0D2E, hsw_gt3, "Intel(R) Haswell")
> > +CHIPSET(0x0F30, byt, "Intel(R) Bay Trail")
> >  CHIPSET(0x0F31, byt, "Intel(R) Bay Trail")
> >  CHIPSET(0x0F32, byt, "Intel(R) Bay Trail")
> >  CHIPSET(0x0F33, byt, "Intel(R) Bay Trail")
> > @@ -212,4 +213,5 @@ CHIPSET(0x8A5A, icl_6x8, "Intel(R) HD Graphics (Ice 
> > Lake 6x8 GT1.5)")
> >  CHIPSET(0x8A5B, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
> >  CHIPSET(0x8A5C, icl_6x8, "Intel(R) HD Graphics (Ice Lake 6x8 GT1.5)")
> >  CHIPSET(0x8A5D, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
> > +CHIPSET(0x8A70, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
> >  CHIPSET(0x8A71, icl_1x8, "Intel(R) HD Graphics (Ice Lake 1x8 GT0.5)")

-- 
Ville Syrjälä
Intel
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

Re: [Mesa-dev] [PATCH] intel: Add more PCI Device IDs for Coffee Lake and Ice Lake.

[Rodrigo Vivi]

On Mon, Feb 18, 2019 at 04:54:34PM +1100, Jonathan Gray wrote:
> Compared to linux and libdrm Mesa is missing a VLV and ICL id.
> 
> 0x0f30
> ff049b6ce21d2814451afd4a116d001712e0116b
> drm/i915: bind driver to ValleyView chipsets
> 
> 0x8A70
> d55cb4fa2cf0105bfb16b60a2846737b91fdc173
> drm/i915/icl: Add the ICL PCI IDs
> 
> The Intel Media SDK describes these as
> 
> /* VLV */
> { 0x0f30, MFX_HW_VLV, MFX_GT1 },   /* VLV mobile */

hmmm... no idea about this one...
Ville?
maybe we should just remove from kernel since it was never
missed from Mesa?

> 
> /* ICL LP */
> { 0x8A70, MFX_HW_ICL_LP, MFX_GT1 }

This is pure display so no Mesa needed for this ID.

> 
> and libdrm's intel_chipset.h describes the VLV id as
> 
> #define PCI_CHIP_VALLEYVIEW_PO0x0f30 /* VLV PO board */
> 
> It isn't clear what the ICL configuration should be from public
> information.
> 
> diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids.h
> index b91abd7a3f9..3568007b1ef 100644
> --- a/include/pci_ids/i965_pci_ids.h
> +++ b/include/pci_ids/i965_pci_ids.h
> @@ -86,6 +86,7 @@ CHIPSET(0x0D2B, hsw_gt3, "Intel(R) Haswell")
>  CHIPSET(0x0D0E, hsw_gt1, "Intel(R) Haswell")
>  CHIPSET(0x0D1E, hsw_gt2, "Intel(R) Haswell")
>  CHIPSET(0x0D2E, hsw_gt3, "Intel(R) Haswell")
> +CHIPSET(0x0F30, byt, "Intel(R) Bay Trail")
>  CHIPSET(0x0F31, byt, "Intel(R) Bay Trail")
>  CHIPSET(0x0F32, byt, "Intel(R) Bay Trail")
>  CHIPSET(0x0F33, byt, "Intel(R) Bay Trail")
> @@ -212,4 +213,5 @@ CHIPSET(0x8A5A, icl_6x8, "Intel(R) HD Graphics (Ice Lake 
> 6x8 GT1.5)")
>  CHIPSET(0x8A5B, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
>  CHIPSET(0x8A5C, icl_6x8, "Intel(R) HD Graphics (Ice Lake 6x8 GT1.5)")
>  CHIPSET(0x8A5D, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
> +CHIPSET(0x8A70, icl_4x8, "Intel(R) HD Graphics (Ice Lake 4x8 GT1)")
>  CHIPSET(0x8A71, icl_1x8, "Intel(R) HD Graphics (Ice Lake 1x8 GT0.5)")
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 201273] Fatal error during GPU init amdgpu RX560

[bugzilla-daemon]

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

--- Comment #35 from quirin.blae...@freenet.de ---
Bug is still alive. v4.20.9

-- 
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: [EARLY RFC][PATCH 0/4] ION per heap devices

[John Stultz]

On Mon, Feb 18, 2019 at 3:51 AM Brian Starkey  wrote:
> On Fri, Feb 15, 2019 at 12:24:08PM -0800, John Stultz wrote:
> > This is a *very early RFC* (it builds, that's all I'll say :)
> > but I wanted to share it to get some initial feedback before I
> > go down the rabit hole of trying to adapt the Android userland
> > code to get this fully validated.
> >
> > This patchset tries to implement the per-heap devices for ION.
> > The main benefit is that it avoids multiplexing heap operations
> > through the /dev/ion interface, and allows for each heap to have
> > its own permissions/sepolicy rules.
>
> In general, I've always thought that having a device node per-heap is
> a bit messy for userspace. Multiplexing through the single node
> doesn't seem like an insurmountable problem, but the point about

Hrm. I guess for me having a custom enumeration interface over ioctl
seems less ideal compared to a directory list.

> permissions/sepolicy is reasonably compelling if it's a real
> requirement. What would be the reasons for that?

Its a bit second hand for me, so hopefully I don't have it wrong. I've
cc'ed some additional google folks and Benjamin for extra context, but
my sense of it is that you may have some less-trusted code that we're
fine with allocating system heap dma-bufs, but don't want to to be
giving access to more limited heaps like carveout or cma, or more
potentially security troubling heaps like system-contig.

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

Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems

[Kuehling, Felix]

On 2019-02-18 3:39 p.m., Thomas Hellstrom wrote:
> On Mon, 2019-02-18 at 18:07 +0100, Christian König wrote:
>> Am 18.02.19 um 10:47 schrieb Thomas Hellstrom:
>>> On Mon, 2019-02-18 at 09:20 +, Koenig, Christian wrote:
 Another good question is also why the heck the acc_size counts
 towards
 the DMA32 zone?
>>> DMA32 TTM pages are accounted in the DMA32 zone. Other pages are
>>> not.
>> Yeah, I'm perfectly aware of this. But this is for the accounting
>> size!
>>
>> We have an accounting for the stuff needed additional to the pages
>> backing the BO (e.g. the page and DMA addr array).
>>
>> And from the bug description it sounds like we use the DMA32 zone
>> for
>> this accounting which of course is completely nonsense.
> It's actually accounted in all available zones, since it would be
> pretty hard to determine exactly where that memory should be accounted.
> In particular if it's vmalloced. It might be DMA32, it might not. Given
> the objective of stopping malicious user-space from exhausting the
> DMA32 zone it was, at the time the code was written, a reasonable
> approximation. With ever increasing memory sizes, there might be better
> solutions?

As far as I can see, in TTM, ttm_mem_global_alloc is only used for the 
acc_size in ttm_bo_init_reserved. Other than that vmwgfx also seems to 
use it to account for a few things that are allocated with kmalloc.

So would a better solution be to change ttm_mem_global_alloc to use only 
the kernel zone?

Regards,
   Felix


>
> /Thomas
>
>> Christian.
>>
>>> For small persistent allocations using ttm_mem_global_alloc(), they
>>> are
>>> accounted also in the DMA32 zone, which may cause over-accounting
>>> of
>>> that zone, but that's pretty unlikely to be a big problem..
>>>
>>> /Thomas
>>>
>>>
>>>
>>>
>>>
 In other words why should the internal bookkeeping pages be
 allocated
 in
 the DMA32 zone?

 That doesn't sounds valid to me in any way,
 Christian.

 Am 18.02.19 um 09:02 schrieb Thomas Hellstrom:
> Hmm,
>
> This zone was intended to stop TTM page allocations from
> exhausting
> the DMA32 zone. IIRC dma_alloc_coherent() uses DMA32 by
> default,
> which
> means if we drop this check, other devices may stop functioning
> unexpectedly?
>
> However, in the end I'd expect the kernel page allocation
> system
> to
> make sure there are some pages left in the DMA32 zone,
> otherwise
> random non-IO page allocations would also potentially exhaust
> the
> DMA32 zone without anybody caring, which means removing this
> zone
> wouldn't be any worse than whatever other subsystems may be
> doing
> already...
>
> /Thomas
>
>
> On 2/16/19 12:02 AM, Kuehling, Felix wrote:
>> This is an RFC. I'm not sure this is the right solution, but
>> it
>> highlights the problem I'm trying to solve.
>>
>> The dma32_zone limits the acc_size of all allocated BOs to
>> 2GB.
>> On a
>> 64-bit system with hundreds of GB of system memory and GPU
>> memory,
>> this can become a bottle neck. We're seeing TTM memory
>> allocation
>> failures not because we're truly out of memory, but because
>> we're
>> out of space in the dma32_zone for the acc_size needed for
>> our BO
>> book-keeping.
>>
>> Signed-off-by: Felix Kuehling 
>> CC: thellst...@vmware.com
>> CC: christian.koe...@amd.com
>> ---
>> drivers/gpu/drm/ttm/ttm_memory.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
>> b/drivers/gpu/drm/ttm/ttm_memory.c
>> index f1567c3..bb05365 100644
>> --- a/drivers/gpu/drm/ttm/ttm_memory.c
>> +++ b/drivers/gpu/drm/ttm/ttm_memory.c
>> @@ -363,7 +363,7 @@ static int
>> ttm_mem_init_highmem_zone(struct
>> ttm_mem_global *glob,
>> glob->zones[glob->num_zones++] = zone;
>> return 0;
>> }
>> -#else
>> +#elifndef CONFIG_64BIT
>> static int ttm_mem_init_dma32_zone(struct ttm_mem_global
>> *glob,
>>const struct sysinfo *si)
>> {
>> @@ -441,7 +441,7 @@ int ttm_mem_global_init(struct
>> ttm_mem_global
>> *glob)
>> ret = ttm_mem_init_highmem_zone(glob, &si);
>> if (unlikely(ret != 0))
>> goto out_no_zone;
>> -#else
>> +#elifndef CONFIG_64BIT
>> ret = ttm_mem_init_dma32_zone(glob, &si);
>> if (unlikely(ret != 0))
>> goto out_no_zone;
>>> ___
>>> amd-gfx mailing list
>>> amd-...@lists.freedesktop.org
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cthellstrom%40vmware.com%7C1a84a2a700cd48b3980a08d695c38ade%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7

Re: [PATCH libdrm] RELEASING: update instructions to use meson instead of autotools

[Emil Velikov]

On Tue, 19 Feb 2019 at 15:36, Dylan Baker  wrote:
>
> Quoting Daniel Vetter (2019-02-19 07:20:12)
> > On Tue, Feb 19, 2019 at 3:02 PM Eric Engestrom  
> > wrote:
> > >
> > > On Tuesday, 2019-02-19 13:53:25 +0100, Daniel Vetter wrote:
> > > > On Tue, Feb 19, 2019 at 12:57 PM Emil Velikov 
> > > >  wrote:
> > > > >
> > > > > On Mon, 18 Feb 2019 at 17:42, Eric Engestrom 
> > > > >  wrote:
> > > > > >
> > > > > > On Thursday, 2018-12-20 11:53:11 -0800, Dylan Baker wrote:
> > > > > > > Quoting Eric Engestrom (2018-12-19 08:23:40)
> > > > > > > > Signed-off-by: Eric Engestrom 
> > > > > > > > ---
> > > > > > > >  RELEASING | 27 ---
> > > > > > > >  1 file changed, 8 insertions(+), 19 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/RELEASING b/RELEASING
> > > > > > > > index 7e03e3b9acb1cbfb261a..d1ad8e3b4ad16d4ca14f 100644
> > > > > > > > --- a/RELEASING
> > > > > > > > +++ b/RELEASING
> > > > > > > > @@ -9,25 +9,14 @@ However, this is up to whoever is driving the 
> > > > > > > > feature in question.
> > > > > > > >
> > > > > > > >  Follow these steps to release a new version of libdrm:
> > > > > > > >
> > > > > > > > -  1) Bump the version number in configure.ac and meson.build. 
> > > > > > > > We seem
> > > > > > > > - to have settled for 2.4.x as the versioning scheme for 
> > > > > > > > libdrm, so
> > > > > > > > - just bump the  micro version.
> > > > > > > > -
> > > > > > > > -  2) Run autoconf and then re-run ./configure so the build 
> > > > > > > > system
> > > > > > > > - picks up the new version number.
> > > > > > > > -
> > > > > > > > -  3) Verify that the code passes "make distcheck".  Running 
> > > > > > > > "make
> > > > > > > > - distcheck" should result in no warnings or errors and end 
> > > > > > > > with a
> > > > > > > > - message of the form:
> > > > > > > > -
> > > > > > > > -   =
> > > > > > > > -   libdrm-X.Y.Z archives ready for distribution:
> > > > > > > > -   libdrm-X.Y.Z.tar.gz
> > > > > > > > -   libdrm-X.Y.Z.tar.bz2
> > > > > > > > -   =
> > > > > > > > -
> > > > > > > > - Make sure that the version number reported by distcheck 
> > > > > > > > and in
> > > > > > > > - the tarball names matches the number you bumped to in 
> > > > > > > > configure.ac.
> > > > > > > > +  1) Bump the version number in meson.build. We seem to have 
> > > > > > > > settled for
> > > > > > > > + 2.4.x as the versioning scheme for libdrm, so just bump 
> > > > > > > > the micro
> > > > > > > > + version.
> > > > > > > > +
> > > > > > > > +  2) Run `ninja -C builddir/ dist` to generate the tarballs.
> > > > > > > > + Make sure that the version number of the tarball name in
> > > > > > > > + builddir/meson-dist/ matches the number you bumped to. 
> > > > > > > > Move that
> > > > > > > > + tarball to the libdrm repo root for the release script to 
> > > > > > > > pick up.
> > > > > > > >
> > > > > > > >4) Push the updated master branch with the bumped version 
> > > > > > > > number:
> > > > > >
> > > > > > Just noticed I forgot to decrement item 4 & 5 :]
> > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Cheers,
> > > > > > > >   Eric
> > > > > > > >
> > > > > > >
> > > > > > > Acked-by: Dylan Baker 
> > > > > > >
> > > > > > > But you should probably get someone other than just me to look at 
> > > > > > > this.
> > > > > >
> > > > > > There is no "libdrm maintainer", which makes everyone a libdrm
> > > > > > maintainer :]
> > > > > >
> > > > > > If nobody object, I'll push this in a few weeks (there's really no 
> > > > > > rush,
> > > > > > but I want to make that move at some point, we have no reason to 
> > > > > > stay
> > > > > > dependant on autotools now that we have better tools).
> > > > >
> > > > > Must admit I'm not the biggest fan. I can see this being cool for the
> > > > > maintainer, if autotools was was present on their system.
> > > > > The unfortunate reality is - it's there for the foreseeable future.
> > > > > If anything it makes it more annoying for those using autotools/make -
> > > > > regardless if they like doing so or not.
> > > > >
> > > > > So that's a nack from me :-\
> > > >
> > > > Not really following what's the downside is of using meson to cut the
> > > > release tarball? Resulting tarball should still be able to build fine
> > > > with automake. If the concern is that automake will bitrot, then I
> > > > think a much better solution is to add a few automake targets to the
> > > > gitlab ci autobuilder stuff. That's what we've done for igt at least,
> > > > works neatly.
> > >
meson dist is effectively a git tarball. Hence one cannot simply
"./configure && make" it

> > > Agreed, and to me using meson has a huge upside: it packages what's in 
> > > git,
> > > unlike autotools which packages whatever was on your machine at the time.
If meson doesn't use any of 

[v17 3/3] drm/i915: Attach colorspace property and enable modeset

[Uma Shankar]

This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.

Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with proper colorspace value set which
will help to enable wider color gamut like BT2020 on sink.

This patch attaches and enables HDMI colorspace, DP will be
taken care separately.

v2: Merged the changes of creating infoframe as well to this
patch as per Maarten's suggestion.

v3: Addressed review comments from Shashank. Separated HDMI
and DP colorspaces as suggested by Ville and Maarten.

v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard. Handle the default case properly.

v5: Merged the DP handling along with platform colorspace
handling as per Shashank's comments.

v6: Reverted to old design of exposing all colorspaces to
userspace as per Ville's review comment

v7: Fixed a checkpatch complaint, Addressed  Maarten' review
comment, updated the RB from Maarten and Jani's ack.

v8: Moved colorspace AVI Infoframe programming to drm core and
removed from driver as per Ville's suggestion.

v9: Added a check to only allow RGB colorpsaces to be set in
infoframe though the colorspace property. Since there is no output
csc property to control planar formats and it will be added later.
Changes for RGB->YUV conversion inside driver without userspace
knowledge is still supported. This is as per Ville's suggestion.

v10: Fixed an error in if check.

v11: Dropped the check for planar vs RGB and allow all the colorspaces.
Onus will be on userspace to pick whatever pipe output it is able to
drive.

v12: Added Ville's RB.

Signed-off-by: Uma Shankar 
Acked-by: Jani Nikula 
Reviewed-by: Maarten Lankhorst 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_atomic.c|  1 +
 drivers/gpu/drm/i915/intel_connector.c |  8 
 drivers/gpu/drm/i915/intel_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_hdmi.c  | 13 +
 4 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 7cf9290..da419e1 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -126,6 +126,7 @@ int intel_digital_connector_atomic_check(struct 
drm_connector *conn,
 */
if (new_conn_state->force_audio != old_conn_state->force_audio ||
new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
+   new_conn_state->base.colorspace != old_conn_state->base.colorspace 
||
new_conn_state->base.picture_aspect_ratio != 
old_conn_state->base.picture_aspect_ratio ||
new_conn_state->base.content_type != 
old_conn_state->base.content_type ||
new_conn_state->base.scaling_mode != 
old_conn_state->base.scaling_mode)
diff --git a/drivers/gpu/drm/i915/intel_connector.c 
b/drivers/gpu/drm/i915/intel_connector.c
index ee16758..8352d0b 100644
--- a/drivers/gpu/drm/i915/intel_connector.c
+++ b/drivers/gpu/drm/i915/intel_connector.c
@@ -265,3 +265,11 @@ int intel_ddc_get_modes(struct drm_connector *connector,
connector->dev->mode_config.aspect_ratio_property,
DRM_MODE_PICTURE_ASPECT_NONE);
 }
+
+void
+intel_attach_colorspace_property(struct drm_connector *connector)
+{
+   if (!drm_mode_create_colorspace_property(connector))
+   drm_object_attach_property(&connector->base,
+  connector->colorspace_property, 0);
+}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index eec4ed9..7a883c3 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1803,6 +1803,7 @@ int intel_connector_update_modes(struct drm_connector 
*connector,
 void intel_attach_force_audio_property(struct drm_connector *connector);
 void intel_attach_broadcast_rgb_property(struct drm_connector *connector);
 void intel_attach_aspect_ratio_property(struct drm_connector *connector);
+void intel_attach_colorspace_property(struct drm_connector *connector);
 
 /* intel_csr.c */
 void intel_csr_ucode_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index f125a62..765718b 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -498,6 +498,8 @@ static void intel_hdmi_set_avi_infoframe(struct 
intel_encoder *encoder,
else
frame.avi.colorspace = HDMI_COLORSPACE_RGB;
 
+   drm_hdmi_avi_infoframe_colorspace(&frame.avi, conn_state);
+
drm_hdmi_avi_infoframe_quant_range(&frame.avi,
   conn_state->connector,
   adj

[v17 2/3] drm: Add colorspace info to AVI Infoframe

[Uma Shankar]

This adds colorspace information to HDMI AVI infoframe.
A helper function is added to program the same.

v2: Moved this to drm core instead of i915 driver.

v3: Exported the helper function.

v4: Added separate HDMI specific macro as per CTA spec.
This is separate from user exposed enum values. This is
as per Ville's suggestion.

v5: Appended BT709 and SMPTE 170M with YCC information as per Ville's
review comment to be clear and not to be confused with RGB.

v6: Added bit wise macro for various fields of colorimetry for easier
understanding and review as per Ville's comments. Moved the same out of
header file to avoid any namespace issues.

v7: Undef some macros to avoid any namespace collision as suggested by
Ville. Added Ville's RB.

Signed-off-by: Uma Shankar 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_edid.c | 70 ++
 include/drm/drm_edid.h |  6 
 2 files changed, 76 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 990b190..5f14253 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4924,6 +4924,76 @@ static bool is_hdmi2_sink(struct drm_connector 
*connector)
 }
 EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
 
+/* HDMI Colorspace Spec Definitions */
+#define FULL_COLORIMETRY_MASK  0x1FF
+#define NORMAL_COLORIMETRY_MASK0x3
+#define EXTENDED_COLORIMETRY_MASK  0x7
+#define EXTENDED_ACE_COLORIMETRY_MASK  0xF
+
+#define C(x) ((x) << 0)
+#define EC(x) ((x) << 2)
+#define ACE(x) ((x) << 5)
+
+#define HDMI_COLORIMETRY_NO_DATA   0x0
+#define HDMI_COLORIMETRY_SMPTE_170M_YCC(C(1) | EC(0) | ACE(0))
+#define HDMI_COLORIMETRY_BT709_YCC (C(2) | EC(0) | ACE(0))
+#define HDMI_COLORIMETRY_XVYCC_601 (C(3) | EC(0) | ACE(0))
+#define HDMI_COLORIMETRY_XVYCC_709 (C(3) | EC(1) | ACE(0))
+#define HDMI_COLORIMETRY_SYCC_601  (C(3) | EC(2) | ACE(0))
+#define HDMI_COLORIMETRY_OPYCC_601 (C(3) | EC(3) | ACE(0))
+#define HDMI_COLORIMETRY_OPRGB (C(3) | EC(4) | ACE(0))
+#define HDMI_COLORIMETRY_BT2020_CYCC   (C(3) | EC(5) | ACE(0))
+#define HDMI_COLORIMETRY_BT2020_RGB(C(3) | EC(6) | ACE(0))
+#define HDMI_COLORIMETRY_BT2020_YCC(C(3) | EC(6) | ACE(0))
+#define HDMI_COLORIMETRY_DCI_P3_RGB_D65(C(3) | EC(7) | ACE(0))
+#define HDMI_COLORIMETRY_DCI_P3_RGB_THEATER(C(3) | EC(7) | ACE(1))
+
+static const u32 hdmi_colorimetry_val[] = {
+   [DRM_MODE_COLORIMETRY_NO_DATA] = HDMI_COLORIMETRY_NO_DATA,
+   [DRM_MODE_COLORIMETRY_SMPTE_170M_YCC] = HDMI_COLORIMETRY_SMPTE_170M_YCC,
+   [DRM_MODE_COLORIMETRY_BT709_YCC] = HDMI_COLORIMETRY_BT709_YCC,
+   [DRM_MODE_COLORIMETRY_XVYCC_601] = HDMI_COLORIMETRY_XVYCC_601,
+   [DRM_MODE_COLORIMETRY_XVYCC_709] = HDMI_COLORIMETRY_XVYCC_709,
+   [DRM_MODE_COLORIMETRY_SYCC_601] = HDMI_COLORIMETRY_SYCC_601,
+   [DRM_MODE_COLORIMETRY_OPYCC_601] = HDMI_COLORIMETRY_OPYCC_601,
+   [DRM_MODE_COLORIMETRY_OPRGB] = HDMI_COLORIMETRY_OPRGB,
+   [DRM_MODE_COLORIMETRY_BT2020_CYCC] = HDMI_COLORIMETRY_BT2020_CYCC,
+   [DRM_MODE_COLORIMETRY_BT2020_RGB] = HDMI_COLORIMETRY_BT2020_RGB,
+   [DRM_MODE_COLORIMETRY_BT2020_YCC] = HDMI_COLORIMETRY_BT2020_YCC,
+};
+
+#undef C
+#undef EC
+#undef ACE
+
+/**
+ * drm_hdmi_avi_infoframe_colorspace() - fill the HDMI AVI infoframe
+ *   colorspace information
+ * @frame: HDMI AVI infoframe
+ * @conn_state: connector state
+ */
+void
+drm_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame,
+ const struct drm_connector_state *conn_state)
+{
+   u32 colorimetry_val;
+   u32 colorimetry_index = conn_state->colorspace & FULL_COLORIMETRY_MASK;
+
+   if (colorimetry_index >= ARRAY_SIZE(hdmi_colorimetry_val))
+   colorimetry_val = HDMI_COLORIMETRY_NO_DATA;
+   else
+   colorimetry_val = hdmi_colorimetry_val[colorimetry_index];
+
+   frame->colorimetry = colorimetry_val & NORMAL_COLORIMETRY_MASK;
+   /*
+* ToDo: Extend it for ACE formats as well. Modify the infoframe
+* structure and extend it in drivers/video/hdmi
+*/
+   frame->extended_colorimetry = (colorimetry_val >> 2) &
+   EXTENDED_COLORIMETRY_MASK;
+}
+EXPORT_SYMBOL(drm_hdmi_avi_infoframe_colorspace);
+
 /**
  * drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
  *quantization range information
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 8dc1a08..9d3b5b9 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -331,6 +331,7 @@ struct cea_sad {
 
 struct drm_encoder;
 struct drm_connector;
+struct drm_connector_state;
 struct drm_display_mode;
 
 int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
@@ -35

[v17 1/3] drm: Add HDMI colorspace property

[Uma Shankar]

Create a new connector property to program colorspace to sink
devices. Modern sink devices support more than 1 type of
colorspace like 601, 709, BT2020 etc. This helps to switch
based on content type which is to be displayed. The decision
lies with compositors as to in which scenarios, a particular
colorspace will be picked.

This will be helpful mostly to switch to higher gamut colorspaces
like BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.

The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to the
one supported. Sink supported colorspaces should be retrieved by
userspace from EDID and driver will not explicitly expose them.

Basically the expectation from userspace is:
 - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
   colorspace
 - Set this new property to let the sink know what it
   converted the CRTC output to.

v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.

v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the colorspace
is not chosen by user, suggested by Ville and Maarten. Addressed
other misc review comments from Maarten. Split the changes to
have separate colorspace property for DP and HDMI.

v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.

v5: Made the property creation helper accept enum list based on
platform capabilties as suggested by Shashank. Consolidated HDMI
and DP property creation in the common helper.

v6: Addressed Shashank's review comments.

v7: Added defines instead of enum in uapi as per Brian Starkey's
suggestion in order to go with string matching at userspace. Updated
the commit message to add more details as well kernel docs.

v8: Addressed Maarten's review comments.

v9: Removed macro defines from uapi as per Brian Starkey and Daniel
Stone's comments and moved to drm include file. Moved back to older
design with exposing all HDMI colorspaces to userspace since infoframe
capability is there even on legacy platforms, as per Ville's review
comments.

v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.

v11: Addressed Ville's review comments. Updated the Macro naming and
added DCI-P3 colorspace as well, defined in CTA 861.G spec.

v12: Appended BT709 and SMPTE 170M with YCC information as per Ville's
review comment to be clear and not to be confused with RGB.

v13: Reorder the colorspace macros.

v14: Removed DP as of now, will be added later once full support is
enabled, as per Ville's suggestion. Added Ville's RB.

Signed-off-by: Uma Shankar 
Acked-by: Jani Nikula 
Reviewed-by: Shashank Sharma 
Reviewed-by: Maarten Lankhorst 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_atomic_uapi.c |  4 ++
 drivers/gpu/drm/drm_connector.c   | 78 +++
 include/drm/drm_connector.h   | 42 +
 3 files changed, 124 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index 0aabd40..4eb81f1 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+   } else if (property == connector->colorspace_property) {
+   state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL, 
val);
int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
@@ -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
*val = state->content_type;
+   } else if (property == connector->colorspace_property) {
+   *val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index dd40eff..07d65a1 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -826,6 +826,33 @@ int drm_display_info_set_bus_formats(struct 
drm_display_info *info,
 };
 DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
 
+static const struct drm_prop_enum_list hdmi_co

[v17 0/3] Add Colorspace connector property interface

[Uma Shankar]

This patch series creates a new connector property to program
colorspace to sink devices. Modern sink devices support more
than 1 type of colorspace like 601, 709, BT2020 etc. This helps
to switch based on content type which is to be displayed. The
decision lies with compositors as to in which scenarios, a
particular colorspace will be picked.

This will be helpful mostly to switch to higher gamut colorspaces
like BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.

The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to the
one supported. Sink supported colorspaces should be retrieved by
userspace from EDID and driver will not explicitly expose them.

Basically the expectation from userspace is:
 - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
   colorspace
 - Set this new property to let the sink know what it
   converted the CRTC output to.
 - This property is just to inform sink what colorspace
   source is trying to drive.

Have tested this using xrandr by using below command:
xrandr --output HDMI2 --set "Colorspace" "BT2020_rgb"

v2: Addressed Ville and Maarten's review comments. Merged the 2nd
and 3rd patch into one common logical patch.

v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
default to an unset state where driver will assign the colorspace
when not chosen by user, suggested by Ville and Maarten. Addressed
other misc review comments from Maarten. Split the changes to
have separate colorspace property for DP and HDMI.

v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list

v5: Modified the colorspace property creation helper to take
platform specific enum list based on the capabilities of the
platform as suggested by Shashank. With this there is no need
for segregation between DP and HDMI.

v6: Addressed Shashank's review comments.

v7: Added defines instead of enum in uapi as per Brian Starkey's
suggestion in order to go with string matching at userspace. Updated
the kernel doc as well with more details.

v8: Addressed Maarten's review comments.

v9: Removed macro defines from uapi as per Brian Starkey and Daniel
Stone's comments and moved to drm include file. Moved back to older
design with exposing all HDMI colorspaces to userspace since infoframe
capability is there even on legacy platforms, as per Ville's review
comments.

v10: Addressed Maarten' review comment, updated the RB from Maarten
and Jani Nikula's ack. Also fixed sparse warnings and checkpatch
complaints.

v11: Addressed Ville's review comments. Modified MACRO names, added
infoframe helper for colorspace to drm layer. Added DCI-P3 colorspace
macro definitions defined in CTA 861.G. Currently linux/hdmi lacks
support for ACE formats, will be added as a separate series.

v12: Exported the helper API.

v13: As per Ville's suggestion, added separate CTA 861.G spec defined
HDMI specific macros. This is separate from user exposed enum values.
Fixed some macro naming inconsistencies.

v14: Appended BT709 and SMPTE 170M with YCC information as per Ville's
review comment to be clear and not to be confused with RGB. Added a check
to allow only RGB colorspaces to be set in infoframe through the colorspace
property, since there is no output csc property to control planar formats
and it will be added later.

v15: Fixed an error in one of the if check.

v16: Added bit wise macro for various fields of colorimetry for easier
understanding and review as per Ville's comments. Moved the same out of
header file to avoid any namespace issues. Dropped the check for planar
vs RGB and allow all the colorspaces.

v17: Dropped DP changes and will be added later once full support for DP
colorspace is enabled. Addressed Ville's review comments and added Ville's
RB tags.

Uma Shankar (3):
  drm: Add HDMI colorspace property
  drm: Add colorspace info to AVI Infoframe
  drm/i915: Attach colorspace property and enable modeset

 drivers/gpu/drm/drm_atomic_uapi.c  |  4 ++
 drivers/gpu/drm/drm_connector.c| 78 ++
 drivers/gpu/drm/drm_edid.c | 70 ++
 drivers/gpu/drm/i915/intel_atomic.c|  1 +
 drivers/gpu/drm/i915/intel_connector.c |  8 
 drivers/gpu/drm/i915/intel_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_hdmi.c  | 13 ++
 include/drm/drm_connector.h| 42 ++
 include/drm/drm_edid.h |  6 +++
 9 files changed, 223 insertions(+)

-- 
1.9.1

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