[Bug 104762] Various segfaults/problems in qt/plasma

[bugzilla-daemon]

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

Fireball  changed:

   What|Removed |Added

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

--- Comment #15 from Fireball  ---
I still experience this with mesa 18.0.0_rc3 and r600 driver.
Resolution first looked ok, user processes (plasmashell etc.) stopped crashing,
but screen locker and logout screen crash (not right away, after a few hours of
working).

As always, clearing caches in /root/.cache and /var/lib/sddm/.cache helps, but
this problem would occur again.
I use Qt 5.9.4.
Backtrace of /usr/lib64/libexec/ksmserver-logout-greeter mentions
/usr/lib64/dri/r600_dri.so.

-- 
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 5/5] drm: Don't pass clip to drm_atomic_helper_check_plane_state()

[Shawn Guo]

On Tue, Jan 23, 2018 at 07:08:57PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Move the plane clip rectangle handling into
> drm_atomic_helper_check_plane_state(). Drivers no longer
> have to worry about such mundane details.
> 
> v2: Convert armada, rcar, and sun4i as well
> 
> Cc: Liviu Dudau 
> Cc: Brian Starkey 
> Cc: Mali DP Maintainers 
> Cc: Daniel Vetter 
> Cc: Gustavo Padovan 
> Cc: Sean Paul 
> Cc: Philipp Zabel 
> Cc: CK Hu 
> Cc: Neil Armstrong 
> Cc: Rob Clark 
> Cc: Ben Skeggs 
> Cc: Laurent Pinchart 
> Cc: Sandy Huang 
> Cc: "Heiko Stübner" 
> Cc: Maxime Ripard 
> Cc: Thierry Reding 
> Cc: VMware Graphics 
> Cc: Sinclair Yeh 
> Cc: Thomas Hellstrom 
> Cc: Shawn Guo 
> Cc: Archit Taneja 
> Cc: linux-amlo...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: linux-te...@vger.kernel.org
> Cc: Russell King 
> Suggested-by: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 
> Reviewed-by: Daniel Vetter 
> Reviewed-by: Thierry Reding 
> Reviewed-by: Archit Taneja  #msm
> ---
...
>  drivers/gpu/drm/zte/zx_plane.c  | 13 +

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

Re: [RFC PATCH v2 1/5] dt-bindings: add bindings for USB physical connector

[Rob Herring]

On Wed, Jan 31, 2018 at 02:44:31PM +0100, Andrzej Hajda wrote:
> These bindings allow to describe most known standard USB connectors
> and it should be possible to extend it if necessary.
> USB connectors, beside USB can be used to route other protocols,
> for example UART, Audio, MHL. In such case every device passing data
> through the connector should have appropriate graph bindings.
> 
> Signed-off-by: Andrzej Hajda 
> ---
> v2:
> - moved connector type(A,B,C) to compatible string (Rob),
> - renamed size property to type (Rob),
> - changed type description to be less confusing (Laurent),
> - removed vendor specific compatibles (implied by graph port number),

How so? More below...

> - added requirement of connector being a child of IC (Rob),
> - removed max-mode (subtly suggested by Rob, it should be detected anyway
>   by USB Controller in runtime, downside is that device is not able to
>   report its real capabilities, maybe better would be to make it optional(?)),
> - assigned port numbers to data buses (Rob).
> 
> Regards
> Andrzej
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  .../bindings/connector/usb-connector.txt   | 48 
> ++
>  1 file changed, 48 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/connector/usb-connector.txt
> 
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> new file mode 100644
> index ..02020f5d760a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> @@ -0,0 +1,48 @@
> +USB Connector
> +=
> +
> +USB connector node represents physical USB connector. It should be
> +a child of USB interface controller.
> +
> +Required properties:
> +- compatible: describes type of the connector, must be one of:
> +"usb-a-connector", "usb-b-connector", "usb-c-connector",

Nit: one per line.

> +
> +Optional properties:
> +- label: symbolic name for the connector
> +- type: size of the connector, should be specified in case of USB-A, USB-B
> +  non-standard (large) connector sizes: "mini", "micro"
> +
> +Required nodes:
> +- any data bus to the connector should be modeled using the OF graph bindings
> +  specified in bindings/graph.txt, unless the bus is between parent node and
> +  the connector. Since single connector can have multpile data buses every 
> bus
> +  has assigned OF graph port number as follows:
> +0: High Speed (HS), present in all connectors,
> +1: Super Speed (SS), present in SS capable connectors,
> +2: Sideband use (SBU), present in USB-C,
> +3: Mobile High-Definition Link (MHL), present in 11-pin Samsung micro-USB

This is un-muxed unlike Type-C where the signals are muxed with USB SS. 
That makes me think the Samsung connector should have its own compatible 
string.

Can we go ahead and define the video modes of Type-C? Normally, if 2 
data streams are mutually exclusive, then they are a single port with 2 
endpoints. So we'd either have 2 endpoints on port 1 or we stick with 
port 3 is always video. We can still know what is mutually exclusive 
based on the compatible. 

> +
> +Example
> +---
> +
> +muic_max77843@66 {
> + ...
> + musb_con: connector {
> + compatible = "usb-b-connector";
> + label = "micro-USB";
> + type = "micro";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@3 {
> + reg = <3>;
> + musb_con_mhl_in: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> + };
> +};
> -- 
> 2.15.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/5] dt-bindings: display: xlnx: Add ZynqMP DP subsystem bindings

[Rob Herring]

On Thu, Jan 25, 2018 at 05:33:59PM -0800, Hyun Kwon wrote:
> This add a dt binding for ZynqMP DP subsystem.
> 
> Signed-off-by: Hyun Kwon 
> ---
> v4
> - Specify phy related descriptions
> - Specify dma related descriptions
> - Remove ports
> - Remove child nodes for layers
> - Update the example accordingly
> v2
> - Group multiple ports under 'ports'
> - Replace linux specific terms with generic hardware descriptions
> ---
> ---
>  .../bindings/display/xlnx/xlnx,zynqmp-dpsub.txt| 67 
> ++
>  1 file changed, 67 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.txt

Reviewed-by: Rob Herring 

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

Re: [PATCH 1/2] drm/panel: Device tree bindings for ARM Versatile panels

[Rob Herring]

On Fri, Jan 26, 2018 at 02:33:35PM +0100, Linus Walleij wrote:
> This adds a pretty simple set of device tree bindings for
> ARM Versatile panels appearing as child nodes of a system
> controller.
> 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Linus Walleij 
> ---
>  .../display/panel/arm,versatile-tft-panel.txt  | 31 
> ++
>  1 file changed, 31 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/arm,versatile-tft-panel.txt

I guess at this point we know there's only 1 Versatile TFT panel...

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

RE: [PATCH 5/5] drm/amdgpu: replace iova debugfs file with iomem

[He, Roger]

Patch1 & 2 & 4,   Reviewed-by: Roger He 
Patch 5:  Acked-by: Roger He 

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Christian K?nig
Sent: Saturday, February 03, 2018 3:10 AM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: [PATCH 5/5] drm/amdgpu: replace iova debugfs file with iomem

This allows access to pages allocated through the driver with optional IOMMU 
mapping.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 57 -
 1 file changed, 35 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 648c449aaa79..795ceaeb82d5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1929,38 +1929,51 @@ static const struct file_operations amdgpu_ttm_gtt_fops 
= {
 
 #endif
 
-static ssize_t amdgpu_iova_to_phys_read(struct file *f, char __user *buf,
-  size_t size, loff_t *pos)
+static ssize_t amdgpu_iomem_read(struct file *f, char __user *buf,
+size_t size, loff_t *pos)
 {
struct amdgpu_device *adev = file_inode(f)->i_private;
-   int r;
-   uint64_t phys;
struct iommu_domain *dom;
+   ssize_t result = 0;
+   int r;
 
-   // always return 8 bytes
-   if (size != 8)
-   return -EINVAL;
+   dom = iommu_get_domain_for_dev(adev->dev);
 
-   // only accept page addresses
-   if (*pos & 0xFFF)
-   return -EINVAL;
+   while (size) {
+   phys_addr_t addr = *pos & PAGE_MASK;
+   loff_t off = *pos & ~PAGE_MASK;
+   size_t bytes = PAGE_SIZE - off;
+   unsigned long pfn;
+   struct page *p;
+   void *ptr;
 
-   dom = iommu_get_domain_for_dev(adev->dev);
-   if (dom)
-   phys = iommu_iova_to_phys(dom, *pos);
-   else
-   phys = *pos;
+   addr = dom ? iommu_iova_to_phys(dom, addr) : addr;
 
-   r = copy_to_user(buf, , 8);
-   if (r)
-   return -EFAULT;
+   pfn = addr >> PAGE_SHIFT;
+   if (!pfn_valid(pfn))
+   return -EPERM;
+
+   p = pfn_to_page(pfn);
+   if (p->mapping != adev->mman.bdev.dev_mapping)
+   return -EPERM;
+
+   ptr = kmap(p);
+   r = copy_to_user(buf, ptr, bytes);
+   kunmap(p);
+   if (r)
+   return -EFAULT;
 
-   return 8;
+   size -= bytes;
+   *pos += bytes;
+   result += bytes;
+   }
+
+   return result;
 }
 
-static const struct file_operations amdgpu_ttm_iova_fops = {
+static const struct file_operations amdgpu_ttm_iomem_fops = {
.owner = THIS_MODULE,
-   .read = amdgpu_iova_to_phys_read,
+   .read = amdgpu_iomem_read,
.llseek = default_llseek
 };
 
@@ -1973,7 +1986,7 @@ static const struct {  #ifdef 
CONFIG_DRM_AMDGPU_GART_DEBUGFS
{ "amdgpu_gtt", _ttm_gtt_fops, TTM_PL_TT },  #endif
-   { "amdgpu_iova", _ttm_iova_fops, TTM_PL_SYSTEM },
+   { "amdgpu_iomem", _ttm_iomem_fops, TTM_PL_SYSTEM },
 };
 
 #endif
--
2.14.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

RE: [PATCH 3/5] drm/radeon: remove extra TT unpopulated check

[He, Roger]

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Christian K?nig
Sent: Saturday, February 03, 2018 3:10 AM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Subject: [PATCH 3/5] drm/radeon: remove extra TT unpopulated check

The subsystem chould check that, not the driver.

Commit log typo, should be "should" rather than " chould".
With that fix,  this patch is Reviewed-by: Roger He 

Thanks
Roger(Hongbo.He)

Signed-off-by: Christian König 
---
 drivers/gpu/drm/radeon/radeon_ttm.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index a0a839bc39bf..42e3ee81a96e 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -728,9 +728,6 @@ static int radeon_ttm_tt_populate(struct ttm_tt *ttm,
struct radeon_device *rdev;
bool slave = !!(ttm->page_flags & TTM_PAGE_FLAG_SG);
 
-   if (ttm->state != tt_unpopulated)
-   return 0;
-
if (gtt && gtt->userptr) {
ttm->sg = kzalloc(sizeof(struct sg_table), GFP_KERNEL);
if (!ttm->sg)
-- 
2.14.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

Re: [Nouveau] [PATCH 3/3] drm/nouveau/pci: SOR crossbar quirk for 10b0:1b81

[Ben Skeggs]

On Mon, Feb 5, 2018 at 12:19 PM, Danilo Krummrich
 wrote:
> On 2018-02-05 02:39, Ben Skeggs wrote:
>>
>> On 5 February 2018 at 11:37, Ben Skeggs  wrote:
>>>
>>> On 5 February 2018 at 11:22, Danilo Krummrich
>>>  wrote:

 On Gainward GTX 1070 routing any other SOR than SOR-1 to macro link
 'G' (outp index 7) causes failures:

 [6.712111] nouveau :01:00.0: bus: MMIO read of  FAULT at
 61c880 [ IBUS ]
 [6.724888] nouveau :01:00.0: disp: intr24 8000
 [8.716668] nouveau :01:00.0: DRM: base-0: timeout
 [   10.716679] nouveau :01:00.0: DRM: base-1: timeout
 [   63.511862] nouveau :01:00.0: DRM: EVO timeout

 As I'm not able to spot an issue in the driver, I suppose it's
 firmware related.
>>>
>>> Are you able to mail me /dev/dri/card0/vbios.rom from that, please?
>>> I'd like to look into this some more and be 100% certain this is
>>> indeed a quirk, and not some subtle driver bug.
>>
>> Err.. /sys/kernel/debug/dri/0/vbios.rom rather ;)
>>
> Sure, that makes sense definitely, as I have checked gm200_sor_route_set and
> gm200_sor_route_get only to conform to the statements in this mail thread:
> https://lists.freedesktop.org/archives/nouveau/2014-December/019408.html
>
> BTW, I can reproduce the problem with a two monitor setup only, as (of
> course) having one
> monitor only at the physical port macro link 'G' is attached to makes to
> vbios pick the
> working SOR. Therefore the physical port macro link 'G' is attached to must
> not be picked
> as primary monitor.
Thanks for that.  I've only had a quick look so far, but I'm going to
guess the is a driver bug already.  The DCB specifies two different
outputs on pad macro 1 (which, would be SOR1 if identity-mapped) that
can apparently be used together.  If used at the same time though,
they both can't be driven by the same SOR, and would need routing.

I guess it'd be interesting to see if NVIDIA can manage to drive those
two outputs together, which would be a big hint as to whether the
board is buggy, or we are.  I'm going to guess the latter ;)

>
> Also, may I ask you a related question: I was a bit confused why 'link' is
> completely unused
> in nvkm_outp_init_route() after gm200_sor_route_get() returns. Is this just
> obsolete or
> intended to use in the future somehow?
I suspect it's a left-over from an earlier revision of that code, or
perhaps I intended to validate it against what we discovered?  Not
sure now!

Thanks,
Ben.

>
> Thanks,
> Danilo
>
>>>
>>> Thanks,
>>> Ben.
>>>

 Therefore to work around this issue skip crossbar routing for this
 particular macro link and instead use identity mapping.

 Signed-off-by: Danilo Krummrich 
 ---
  drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
 b/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
 index d2f9664afcf4..29de270f2232 100644
 --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
 +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
 @@ -797,6 +797,13 @@ nvkm_device_pci_10de_139b[] = {
 {}
  };

 +static const struct nvkm_device_pci_vendor
 +nvkm_device_pci_10de_1b81[] = {
 +   /* Gainward GTX 1070 8192 MB */
 +   { 0x10b0, 0x1b81, "GeForce GTX 1070",{ .outp_links_skip = BIT(7)
 } },
 +   {}
 +};
 +
  static const struct nvkm_device_pci_device
  nvkm_device_pci_10de[] = {
 { 0x0020, "RIVA TNT" },
 @@ -1556,7 +1563,7 @@ nvkm_device_pci_10de[] = {
 { 0x1b06, "GeForce GTX 1080 TI" },
 { 0x1bb7, "Quadro P6000" },
 { 0x1b80, "GeForce GTX 1080" },
 -   { 0x1b81, "GeForce GTX 1070" },
 +   { 0x1b81, "GeForce GTX 1070", nvkm_device_pci_10de_1b81 },
 { 0x1b82, "GeForce GTX 1070 TI" },
 { 0x1b84, "GeForce GTX 1060 3GB" },
 { 0x1b87, "P104-100" },
 --
 2.14.1

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

Re: [Nouveau] [PATCH 3/3] drm/nouveau/pci: SOR crossbar quirk for 10b0:1b81

[Ben Skeggs]

On 5 February 2018 at 11:37, Ben Skeggs  wrote:
> On 5 February 2018 at 11:22, Danilo Krummrich
>  wrote:
>> On Gainward GTX 1070 routing any other SOR than SOR-1 to macro link
>> 'G' (outp index 7) causes failures:
>>
>> [6.712111] nouveau :01:00.0: bus: MMIO read of  FAULT at 
>> 61c880 [ IBUS ]
>> [6.724888] nouveau :01:00.0: disp: intr24 8000
>> [8.716668] nouveau :01:00.0: DRM: base-0: timeout
>> [   10.716679] nouveau :01:00.0: DRM: base-1: timeout
>> [   63.511862] nouveau :01:00.0: DRM: EVO timeout
>>
>> As I'm not able to spot an issue in the driver, I suppose it's
>> firmware related.
> Are you able to mail me /dev/dri/card0/vbios.rom from that, please?
> I'd like to look into this some more and be 100% certain this is
> indeed a quirk, and not some subtle driver bug.
Err.. /sys/kernel/debug/dri/0/vbios.rom rather ;)

>
> Thanks,
> Ben.
>
>>
>> Therefore to work around this issue skip crossbar routing for this
>> particular macro link and instead use identity mapping.
>>
>> Signed-off-by: Danilo Krummrich 
>> ---
>>  drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c | 9 -
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c 
>> b/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
>> index d2f9664afcf4..29de270f2232 100644
>> --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
>> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
>> @@ -797,6 +797,13 @@ nvkm_device_pci_10de_139b[] = {
>> {}
>>  };
>>
>> +static const struct nvkm_device_pci_vendor
>> +nvkm_device_pci_10de_1b81[] = {
>> +   /* Gainward GTX 1070 8192 MB */
>> +   { 0x10b0, 0x1b81, "GeForce GTX 1070",{ .outp_links_skip = BIT(7) } },
>> +   {}
>> +};
>> +
>>  static const struct nvkm_device_pci_device
>>  nvkm_device_pci_10de[] = {
>> { 0x0020, "RIVA TNT" },
>> @@ -1556,7 +1563,7 @@ nvkm_device_pci_10de[] = {
>> { 0x1b06, "GeForce GTX 1080 TI" },
>> { 0x1bb7, "Quadro P6000" },
>> { 0x1b80, "GeForce GTX 1080" },
>> -   { 0x1b81, "GeForce GTX 1070" },
>> +   { 0x1b81, "GeForce GTX 1070", nvkm_device_pci_10de_1b81 },
>> { 0x1b82, "GeForce GTX 1070 TI" },
>> { 0x1b84, "GeForce GTX 1060 3GB" },
>> { 0x1b87, "P104-100" },
>> --
>> 2.14.1
>>
>> ___
>> Nouveau mailing list
>> nouv...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH 3/3] drm/nouveau/pci: SOR crossbar quirk for 10b0:1b81

[Ben Skeggs]

On 5 February 2018 at 11:22, Danilo Krummrich
 wrote:
> On Gainward GTX 1070 routing any other SOR than SOR-1 to macro link
> 'G' (outp index 7) causes failures:
>
> [6.712111] nouveau :01:00.0: bus: MMIO read of  FAULT at 
> 61c880 [ IBUS ]
> [6.724888] nouveau :01:00.0: disp: intr24 8000
> [8.716668] nouveau :01:00.0: DRM: base-0: timeout
> [   10.716679] nouveau :01:00.0: DRM: base-1: timeout
> [   63.511862] nouveau :01:00.0: DRM: EVO timeout
>
> As I'm not able to spot an issue in the driver, I suppose it's
> firmware related.
Are you able to mail me /dev/dri/card0/vbios.rom from that, please?
I'd like to look into this some more and be 100% certain this is
indeed a quirk, and not some subtle driver bug.

Thanks,
Ben.

>
> Therefore to work around this issue skip crossbar routing for this
> particular macro link and instead use identity mapping.
>
> Signed-off-by: Danilo Krummrich 
> ---
>  drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
> index d2f9664afcf4..29de270f2232 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
> @@ -797,6 +797,13 @@ nvkm_device_pci_10de_139b[] = {
> {}
>  };
>
> +static const struct nvkm_device_pci_vendor
> +nvkm_device_pci_10de_1b81[] = {
> +   /* Gainward GTX 1070 8192 MB */
> +   { 0x10b0, 0x1b81, "GeForce GTX 1070",{ .outp_links_skip = BIT(7) } },
> +   {}
> +};
> +
>  static const struct nvkm_device_pci_device
>  nvkm_device_pci_10de[] = {
> { 0x0020, "RIVA TNT" },
> @@ -1556,7 +1563,7 @@ nvkm_device_pci_10de[] = {
> { 0x1b06, "GeForce GTX 1080 TI" },
> { 0x1bb7, "Quadro P6000" },
> { 0x1b80, "GeForce GTX 1080" },
> -   { 0x1b81, "GeForce GTX 1070" },
> +   { 0x1b81, "GeForce GTX 1070", nvkm_device_pci_10de_1b81 },
> { 0x1b82, "GeForce GTX 1070 TI" },
> { 0x1b84, "GeForce GTX 1060 3GB" },
> { 0x1b87, "P104-100" },
> --
> 2.14.1
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm/nouveau/pci: SOR crossbar quirk for 10b0:1b81

[Danilo Krummrich]

On Gainward GTX 1070 routing any other SOR than SOR-1 to macro link
'G' (outp index 7) causes failures:

[6.712111] nouveau :01:00.0: bus: MMIO read of  FAULT at 61c880 
[ IBUS ]
[6.724888] nouveau :01:00.0: disp: intr24 8000
[8.716668] nouveau :01:00.0: DRM: base-0: timeout
[   10.716679] nouveau :01:00.0: DRM: base-1: timeout
[   63.511862] nouveau :01:00.0: DRM: EVO timeout

As I'm not able to spot an issue in the driver, I suppose it's
firmware related.

Therefore to work around this issue skip crossbar routing for this
particular macro link and instead use identity mapping.

Signed-off-by: Danilo Krummrich 
---
 drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
index d2f9664afcf4..29de270f2232 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
@@ -797,6 +797,13 @@ nvkm_device_pci_10de_139b[] = {
{}
 };
 
+static const struct nvkm_device_pci_vendor
+nvkm_device_pci_10de_1b81[] = {
+   /* Gainward GTX 1070 8192 MB */
+   { 0x10b0, 0x1b81, "GeForce GTX 1070",{ .outp_links_skip = BIT(7) } },
+   {}
+};
+
 static const struct nvkm_device_pci_device
 nvkm_device_pci_10de[] = {
{ 0x0020, "RIVA TNT" },
@@ -1556,7 +1563,7 @@ nvkm_device_pci_10de[] = {
{ 0x1b06, "GeForce GTX 1080 TI" },
{ 0x1bb7, "Quadro P6000" },
{ 0x1b80, "GeForce GTX 1080" },
-   { 0x1b81, "GeForce GTX 1070" },
+   { 0x1b81, "GeForce GTX 1070", nvkm_device_pci_10de_1b81 },
{ 0x1b82, "GeForce GTX 1070 TI" },
{ 0x1b84, "GeForce GTX 1060 3GB" },
{ 0x1b87, "P104-100" },
-- 
2.14.1

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

[PATCH 2/3] drm/nouveau/disp: quirk for SOR crossbar routing

[Danilo Krummrich]

With DCB 4.1 implemented by VBIOS since GM20x GPUs, SOR crossbar
routing should be possible, such that any SOR sublink can drive
any macro link.

Unfortunately, there's at least one card where some SOR sublinks
being connected to a particular macro link are causing failures.

To work around this issue, supply a quirk for such cards which
prevents a dynamic mapping of SOR sublink and macro link and
instead relies on identity mapping.

Signed-off-by: Danilo Krummrich 
---
 drivers/gpu/drm/nouveau/include/nvkm/core/device.h |  1 +
 drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c| 18 --
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/include/nvkm/core/device.h 
b/drivers/gpu/drm/nouveau/include/nvkm/core/device.h
index 560265b15ec2..d384cb03ad85 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/core/device.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/core/device.h
@@ -184,6 +184,7 @@ struct nvkm_device_func {
 struct nvkm_device_quirk {
u8 tv_pin_mask;
u8 tv_gpio;
+   u8 outp_links_skip;
 };
 
 struct nvkm_device_chip {
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c
index be9e7f8c3b23..47303bdb7ee0 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c
@@ -99,6 +99,17 @@ nvkm_outp_release(struct nvkm_outp *outp, u8 user)
}
 }
 
+static inline bool
+nvkm_outp_ior_route_quirk(struct nvkm_outp *outp)
+{
+   struct nvkm_device *dev = outp->disp->engine.subdev.device;
+
+   if (unlikely(dev->quirk))
+   return !(dev->quirk->outp_links_skip & BIT(outp->index));
+
+   return true;
+}
+
 static inline int
 nvkm_outp_acquire_ior(struct nvkm_outp *outp, u8 user, struct nvkm_ior *ior)
 {
@@ -115,6 +126,7 @@ nvkm_outp_acquire(struct nvkm_outp *outp, u8 user)
struct nvkm_ior *ior = outp->ior;
enum nvkm_ior_proto proto;
enum nvkm_ior_type type;
+   bool route_crossbar = nvkm_outp_ior_route_quirk(outp);
 
OUTP_TRACE(outp, "acquire %02x |= %02x %p", outp->acquired, user, ior);
if (ior) {
@@ -138,7 +150,8 @@ nvkm_outp_acquire(struct nvkm_outp *outp, u8 user)
/* Failing that, a completely unused OR is the next best thing. */
list_for_each_entry(ior, >disp->ior, head) {
if (!ior->asy.outp && ior->type == type && !ior->arm.outp &&
-   (ior->func->route.set || ior->id == __ffs(outp->info.or)))
+   ((ior->func->route.set && route_crossbar) ||
+ior->id == __ffs(outp->info.or)))
return nvkm_outp_acquire_ior(outp, user, ior);
}
 
@@ -147,7 +160,8 @@ nvkm_outp_acquire(struct nvkm_outp *outp, u8 user)
 */
list_for_each_entry(ior, >disp->ior, head) {
if (!ior->asy.outp && ior->type == type &&
-   (ior->func->route.set || ior->id == __ffs(outp->info.or)))
+   ((ior->func->route.set && route_crossbar) ||
+ior->id == __ffs(outp->info.or)))
return nvkm_outp_acquire_ior(outp, user, ior);
}
 
-- 
2.14.1

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

[PATCH 1/3] drm/nouveau/pci: PCI IDs for pascal architecture

[Danilo Krummrich]

Taken from NVIDIA binary driver (Linux 64-bit, revision 390.25)
from README.txt.

Signed-off-by: Danilo Krummrich 
---
 drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c | 41 
 1 file changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
index f302d2b5782a..d2f9664afcf4 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
@@ -1551,6 +1551,47 @@ nvkm_device_pci_10de[] = {
{ 0x17c2, "GeForce GTX TITAN X" },
{ 0x17c8, "GeForce GTX 980 Ti" },
{ 0x17f0, "Quadro M6000" },
+   { 0x1b00, "TITAN X (Pascal)" },
+   { 0x1b02, "TITAN Xp" },
+   { 0x1b06, "GeForce GTX 1080 TI" },
+   { 0x1bb7, "Quadro P6000" },
+   { 0x1b80, "GeForce GTX 1080" },
+   { 0x1b81, "GeForce GTX 1070" },
+   { 0x1b82, "GeForce GTX 1070 TI" },
+   { 0x1b84, "GeForce GTX 1060 3GB" },
+   { 0x1b87, "P104-100" },
+   { 0x1ba0, "GeForce GTX 1080M" },
+   { 0x1ba1, "GeForce GTX 1070M" },
+   { 0x1bb0, "Quadro P5000" },
+   { 0x1bb1, "Quadro P4000" },
+   { 0x1bb6, "Quadro P5000" },
+   { 0x1bb7, "Quadro P4000" },
+   { 0x1bb8, "Quadro P3000" },
+   { 0x1be0, "GeForce GTX 1080M" },
+   { 0x1be1, "GeForce GTX 1070M" },
+   { 0x1bc7, "P104-101" },
+   { 0x1c02, "GeForce GTX 1060 3GB" },
+   { 0x1c03, "GeForce GTX 1060 6GB" },
+   { 0x1c04, "GeForce GTX 1050 5GB" },
+   { 0x1c06, "GeForce GTX 1050 6GB" },
+   { 0x1c07, "P106-100" },
+   { 0x1c09, "P106-090" },
+   { 0x1c20, "GeForce GTX 1060M" },
+   { 0x1c21, "GeForce GTX 1050M TI" },
+   { 0x1c22, "GeForce GTX 1050M" },
+   { 0x1c30, "Quadro P2000" },
+   { 0x1c60, "GeForce GTX 1060M 6GB" },
+   { 0x1c61, "GeForce GTX 1050M TI" },
+   { 0x1c81, "GeForce GTX 1050" },
+   { 0x1c82, "GeForce GTX 1050 TI" },
+   { 0x1c8c, "GeForce GTX 1050M TI" },
+   { 0x1c8d, "GeForce GTX 1050M" },
+   { 0x1cb1, "Quadro P2000" },
+   { 0x1cb2, "Quadro P600" },
+   { 0x1cb3, "Quadro P400" },
+   { 0x1d01, "GeForce GT 1030" },
+   { 0x1d10, "GeForce MX 150" },
+   { 0x1d12, "GeForce MX 150" },
{}
 };
 
-- 
2.14.1

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

nouveau 30bpp / deep color status

[Ilia Mirkin]

In case anyone's curious about 30bpp framebuffer support, here's the
current status:

Kernel:

Ben and I have switched the code to using a 256-based LUT for Kepler+,
and I've also written a patch to cause the addfb ioctl to use the
proper format. You can pick this up at:

https://github.com/skeggsb/linux/commits/linux-4.16 (note the branch!)
https://patchwork.freedesktop.org/patch/202322/

With these two, you should be able to use "X -depth 30" again on any
G80+ GPU to bring up a screen (as you could in kernel 4.9 and
earlier). However this still has some deficiencies, some of which I've
addressed:

xf86-video-nouveau:

DRI3 was broken, and Xv was broken. Patches available at:

https://github.com/imirkin/xf86-video-nouveau/commits/master

mesa:

The NVIDIA hardware (pre-Kepler) can only do XBGR scanout. Further the
nouveau KMS doesn't add XRGB scanout for Kepler+ (although it could).
Mesa was only enabled for XRGB, so I've piped XBGR through all the
same places:

https://github.com/imirkin/mesa/commits/30bpp

libdrm:

For testing, I added a modetest gradient pattern split horizontally.
Top half is 10bpc, bottom half is 8bpc. This is useful for seeing
whether you're really getting 10bpc, or if things are getting
truncated along the way. Definitely hacky, but ... wasn't intending on
upstreaming it anyways:

https://github.com/imirkin/drm/commit/9b8776f58448b5745675c3a7f5eb2735e3989441

-

Results with the patches (tested on a GK208B and a "deep color" TV over HDMI):
 - modetest with a 10bpc gradient shows up smoother than an 8bpc
gradient. However it's still dithered to 8bpc, not "real" 10bpc.
 - things generally work in X -- dri2 and dri3, xv, and obviously
regular X rendering / acceleration
 - lots of X software can't handle 30bpp modes (mplayer hates it for
xv and x11 rendering, aterm bails on shading the root pixmap, probably
others)

I'm also told that with DP, it should actually send the higher-bpc
data over the wire. With HDMI, we're still stuck at 24bpp for now
(although the hardware can do 36bpp as well). This is why my gradient
result above was still dithered.

Things to do - mostly nouveau specific, but probably some general
infra needed too:
 - Figure out how to properly expose the 1024-sized LUT
 - Add fp16 scanout
 - Stop relying on the max bpc of the monitor/connector and make
decisions based on the "effective" bpc (e.g. based on the
currently-set fb format, take hdmi/dp into account, etc). This will
also affect the max clock somehow. Perhaps there should be a way to
force a connector to a certain bpc.
 - Add higher-bpc HDMI support
 - Add 10bpc dithering (only makes sense if >= 10bpc output is
*actually* enabled first)
 - Investigate YUV HDMI modes (esp since they can enable 4K@60 on HDMI
1.4 hardware)
 - Test out Wayland compositors
 - Teach xf86-video-modesetting about addfb2 or that nouveau's
ordering is different.

I don't necessarily plan on working further on this, so if there are
interested parties, they should definitely try to pick it up. I'll try
to upstream all my changes though.

Cheers,

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

[Bug 90595] [drm:si_dpm_set_power_state [radeon]] *ERROR* si_set_sw_state failed

[bugzilla-daemon]

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

--- Comment #12 from Mike  ---
(In reply to JATothrim from comment #9)
> Apparently after several kernel versions later hibernate is still broken on
> my machine. :(
> 
> uname -a: Linux HyperArchMachine 4.6.3-1-ARCH #1 SMP PREEMPT Fri Jun 24
> 21:19:13 CEST 2016 x86_64 GNU/Linux
> Operating system is Arch/Antergos.
> 
> Sympthoms:
> -No panic is displayed. The machine freezes completly soon as radeon tries
> to hibernate (to swap disk 8GiB). No way to soft reset.
> -On resuming first display VTs are showing up weird: resolution is same as
> second display (1680x1050) but parts beyond that reso of the FullHD display
> are corrupted (pink pixel noise).
> -[drm:si_dpm_set_power_state [radeon]] *ERROR* si_set_sw_state failed gets
> outputed on suspend/resume.
> 
> Disabling DPM on boot allows machine to hibernate/resume correctly but dual
> display VT weirdness persists.

I'm getting the same "tiles" on my display a moment before the x-windows system
hangs.  I'm able to ssh into my box and shut it down, but box must be
restarted.  Just curious, if after implementing "dpm=0" in the kernel, if you
experience crashing or just pixelated weirdness?

-- 
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 90595] [drm:si_dpm_set_power_state [radeon]] *ERROR* si_set_sw_state failed

[bugzilla-daemon]

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

--- Comment #11 from Mike  ---
I too have been experiencing this issue for quite some time.  I'm running:

# uname -a
Linux hostname 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64
GNU/Linux

# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 9.3 (stretch)
Release:9.3
Codename:   stretch

And here's what show's up in `dmesg` every time I boot up:

# dmesg | grep -i radeon
[2.877374] [drm] radeon kernel modesetting enabled.
[2.896977] radeon :01:00.0: VRAM: 2048M 0x -
0x7FFF (2048M used)
[2.896978] radeon :01:00.0: GTT: 2048M 0x8000 -
0x
[2.897154] [drm] radeon: 2048M of VRAM memory ready
[2.897155] [drm] radeon: 2048M of GTT memory ready.
[2.902498] radeon :01:00.0: firmware: direct-loading firmware
radeon/pitcairn_pfp.bin
[2.909274] radeon :01:00.0: firmware: direct-loading firmware
radeon/pitcairn_me.bin
[2.909826] radeon :01:00.0: firmware: direct-loading firmware
radeon/pitcairn_ce.bin
[2.911587] radeon :01:00.0: firmware: direct-loading firmware
radeon/pitcairn_rlc.bin
[2.912724] radeon :01:00.0: firmware: direct-loading firmware
radeon/pitcairn_mc.bin
[2.913984] radeon :01:00.0: firmware: direct-loading firmware
radeon/pitcairn_smc.bin
[2.922964] [drm] radeon: dpm initialized
[2.928860] radeon :01:00.0: firmware: direct-loading firmware
radeon/TAHITI_uvd.bin
[2.930542] radeon :01:00.0: firmware: direct-loading firmware
radeon/TAHITI_vce.bin
[2.949302] radeon :01:00.0: WB enabled
[2.949304] radeon :01:00.0: fence driver on ring 0 use gpu addr
0x8c00 and cpu addr 0x998d238abc00
[2.949305] radeon :01:00.0: fence driver on ring 1 use gpu addr
0x8c04 and cpu addr 0x998d238abc04
[2.949306] radeon :01:00.0: fence driver on ring 2 use gpu addr
0x8c08 and cpu addr 0x998d238abc08
[2.949307] radeon :01:00.0: fence driver on ring 3 use gpu addr
0x8c0c and cpu addr 0x998d238abc0c
[2.949308] radeon :01:00.0: fence driver on ring 4 use gpu addr
0x8c10 and cpu addr 0x998d238abc10
[2.949808] radeon :01:00.0: fence driver on ring 5 use gpu addr
0x00075a18 and cpu addr 0xb0f8c2c35a18
[2.969924] radeon :01:00.0: fence driver on ring 6 use gpu addr
0x8c18 and cpu addr 0x998d238abc18
[2.969926] radeon :01:00.0: fence driver on ring 7 use gpu addr
0x8c1c and cpu addr 0x998d238abc1c
[2.969943] radeon :01:00.0: radeon: MSI limited to 32-bit
[2.970010] radeon :01:00.0: radeon: using MSI.
[2.970036] [drm] radeon: irq initialized.
[5.136861] [drm] Radeon Display Connectors
[5.304534] fbcon: radeondrmfb (fb0) is primary device
[5.484728] [drm:si_dpm_set_power_state [radeon]] *ERROR*
si_restrict_performance_levels_before_switch failed
[5.576343] radeon :01:00.0: fb0: radeondrmfb frame buffer device
[5.603284] [drm] Initialized radeon 2.49.0 20080528 for :01:00.0 on
minor 0

Not sure if you need this, but just in case:

# dmesg | grep -i vga
[0.00] Console: colour VGA+ 80x25
[0.373862] vgaarb: setting as boot device: PCI::01:00.0
[0.373863] vgaarb: device added:
PCI::01:00.0,decodes=io+mem,owns=io+mem,locks=none
[0.373864] vgaarb: loaded
[0.373864] vgaarb: bridge control possible :01:00.0
[2.805123] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client

-- 
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 104880] No sound via DP on R9 Fury (4.15 + amd-staging-4.15 patches)

[bugzilla-daemon]

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

--- Comment #8 from Konstantin A. Lepikhov  ---
Sound is back when I've switched monitor via HDMI:

$ cat /proc/asound/HDMI/eld#0.4 
monitor_present 1
eld_valid   1
monitor_nameASUS PB278
connection_type HDMI
eld_version [0x2] CEA-861D or below
edid_version[0x0] no CEA EDID Timing Extension block present
manufacture_id  0x6904
product_id  0x27a3
port_id 0xd9894495558859e
support_hdcp0
support_ai  0
audio_sync_delay0
speakers[0x1] FL/FR
sad_count   1
sad0_coding_type[0x1] LPCM
sad0_channels   1
sad0_rates  [0x4e0] 32000 44100 48000 96000
sad0_bits   [0xe] 16 20 24

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

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Andy Lutomirski]

On Sat, Feb 3, 2018 at 5:08 PM, Andy Lutomirski  wrote:
> On Sat, Feb 3, 2018 at 5:20 AM, Pandiyan, Dhinakaran
>  wrote:
>>
>> On Fri, 2018-02-02 at 19:18 +, Andy Lutomirski wrote:
>>> I updated to 4.15, and the situation is much worse.  With
>>> enable_psr=1, the system survives for several seconds and then the
>>> screen stops updating entirely.  If I boot with i915.enable_psr=1, I
>>> get to the Fedora login screen and then the system dies.  If I set
>>> enable_psr=1 using sysfs, it does a bit after the next resume.  It
>>> seems like it also sometimes hangs even worse a bit after the screen
>>> stops updating, but it's hard to tell.
>>
>> The login screen freeze sounds like what I have. Does this system have
>> DMC firmware? If yes, can you try this series
>> https://patchwork.freedesktop.org/series/37598/. You'll only need
>> patches 1,8,9 and 10.
>
> That fixes the hang.  Feel free to add:
>
> Tested-by: Andy Lutomirski 
>
> to the i915 parts.  Also, any chance of getting it into the 4.15 stable 
> kernels?

Correction: I'm still getting a second or two of complete screen
freezing every now and then.  The kernel says:

[69400.016524] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
update failure on pipe A (start=19 end=20) time 198 us, min 1073, max
1079, scanline start 1068, end 1082

So something might still be a bit buggy.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/bridge/synopsys: dsi: readl_poll_timeout return value clean up

[Philippe Cornu]

The readl_poll_timeout() return value is 0 in case of success
so it is better to detect errors without taking care of the
return value sign.

Signed-off-by: Philippe Cornu 
---
 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 65aeb3f78b48..4d0e8471a15c 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -342,7 +342,7 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi 
*dsi, u32 hdr_val)
ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
 val, !(val & GEN_CMD_FULL), 1000,
 CMD_PKT_STATUS_TIMEOUT_US);
-   if (ret < 0) {
+   if (ret) {
dev_err(dsi->dev, "failed to get available command FIFO\n");
return ret;
}
@@ -353,7 +353,7 @@ static int dw_mipi_dsi_gen_pkt_hdr_write(struct dw_mipi_dsi 
*dsi, u32 hdr_val)
ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
 val, (val & mask) == mask,
 1000, CMD_PKT_STATUS_TIMEOUT_US);
-   if (ret < 0) {
+   if (ret) {
dev_err(dsi->dev, "failed to write command FIFO\n");
return ret;
}
@@ -385,7 +385,7 @@ static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
 val, !(val & GEN_PLD_W_FULL), 1000,
 CMD_PKT_STATUS_TIMEOUT_US);
-   if (ret < 0) {
+   if (ret) {
dev_err(dsi->dev,
"failed to get available write payload FIFO\n");
return ret;
@@ -716,13 +716,13 @@ static void dw_mipi_dsi_dphy_enable(struct dw_mipi_dsi 
*dsi)
 
ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS, val,
 val & PHY_LOCK, 1000, PHY_STATUS_TIMEOUT_US);
-   if (ret < 0)
+   if (ret)
DRM_DEBUG_DRIVER("failed to wait phy lock state\n");
 
ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS,
 val, val & PHY_STOP_STATE_CLK_LANE, 1000,
 PHY_STATUS_TIMEOUT_US);
-   if (ret < 0)
+   if (ret)
DRM_DEBUG_DRIVER("failed to wait phy clk lane stop state\n");
 }
 
-- 
2.15.1

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

[Bug 104919] R9285 4.17-wip locks/vmfaults since drm/amdgpu: revert "drm/amdgpu: use AMDGPU_GEM_CREATE_VRAM_CLEARED for VM PD/PTs" v2

[bugzilla-daemon]

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

--- Comment #6 from Andy Furniss  ---
That fixes it, thanks.

-- 
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/bridge/synopsys: dsi: Add read feature

[Philippe Cornu]

This patch adds the DCS/GENERIC DSI read feature.

Signed-off-by: Philippe Cornu 
---
Extra notes:
DSI read tests have been performed with DCS & GENERIC, short & long
commands, on two different panels.
The maximum fifo size (32*32-bit = 128 bytes on stm32) has been
verified too.

 drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 58 +--
 1 file changed, 45 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index e9422d05e897..65aeb3f78b48 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -397,18 +397,46 @@ static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
return dw_mipi_dsi_gen_pkt_hdr_write(dsi, le32_to_cpu(word));
 }
 
+static int dw_mipi_dsi_read(struct dw_mipi_dsi *dsi,
+   const struct mipi_dsi_msg *msg)
+{
+   int i, j, ret, len = msg->rx_len;
+   u8 *buf = msg->rx_buf;
+   u32 val;
+
+   /* Wait end of the read operation */
+   ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
+val, !(val & GEN_RD_CMD_BUSY),
+1000, CMD_PKT_STATUS_TIMEOUT_US);
+   if (ret) {
+   dev_err(dsi->dev, "Timeout during read operation\n");
+   return ret;
+   }
+
+   for (i = 0; i < len; i += 4) {
+   /* Read fifo must not be empty before all bytes are read */
+   ret = readl_poll_timeout(dsi->base + DSI_CMD_PKT_STATUS,
+val, !(val & GEN_PLD_R_EMPTY),
+1000, CMD_PKT_STATUS_TIMEOUT_US);
+   if (ret) {
+   dev_err(dsi->dev, "Read payload FIFO is empty\n");
+   return ret;
+   }
+
+   val = dsi_read(dsi, DSI_GEN_PLD_DATA);
+   for (j = 0; j < 4 && j + i < len; j++)
+   buf[i + j] = val >> (8 * j);
+   }
+
+   return ret;
+}
+
 static ssize_t dw_mipi_dsi_host_transfer(struct mipi_dsi_host *host,
 const struct mipi_dsi_msg *msg)
 {
struct dw_mipi_dsi *dsi = host_to_dsi(host);
struct mipi_dsi_packet packet;
-   int ret;
-
-   if (msg->rx_buf || msg->rx_len) {
-   /* TODO dw drv improvements: implement read feature */
-   dev_warn(dsi->dev, "read operations not yet implemented\n");
-   return -EINVAL;
-   }
+   int ret, nb_bytes;
 
ret = mipi_dsi_create_packet(, msg);
if (ret) {
@@ -422,12 +450,16 @@ static ssize_t dw_mipi_dsi_host_transfer(struct 
mipi_dsi_host *host,
if (ret)
return ret;
 
-   /*
-* TODO Only transmitted size is returned as actual driver does
-* not support dcs/generic reads. Please update return value when
-* delivering the read feature.
-*/
-   return packet.size;
+   if (msg->rx_buf && msg->rx_len) {
+   ret = dw_mipi_dsi_read(dsi, msg);
+   if (ret)
+   return ret;
+   nb_bytes = msg->rx_len;
+   } else {
+   nb_bytes = packet.size;
+   }
+
+   return nb_bytes;
 }
 
 static const struct mipi_dsi_host_ops dw_mipi_dsi_host_ops = {
-- 
2.15.1

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

[PATCH v3 5/7] ARM: dts: imx6q-icore-ofcap12: Switch LVDS timings from panel-simple

[Jagan Teki]

Switch to use koe_tx31d200vm0baa LVDS timings from
panel-simple instead hard coding the same in dts.

Signed-off-by: Jagan Teki 
---
Changes for v3, v2:
- none

 arch/arm/boot/dts/imx6q-icore-ofcap12.dts | 31 +--
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q-icore-ofcap12.dts 
b/arch/arm/boot/dts/imx6q-icore-ofcap12.dts
index 9e230f5..6e27c81 100644
--- a/arch/arm/boot/dts/imx6q-icore-ofcap12.dts
+++ b/arch/arm/boot/dts/imx6q-icore-ofcap12.dts
@@ -48,28 +48,31 @@
 / {
model = "Engicam i.CoreM6 Quad/Dual OpenFrame Capacitive touch 12 Kit";
compatible = "engicam,imx6-icore", "fsl,imx6q";
+
+   panel {
+   compatible = "koe,tx31d200vm0baa";
+   backlight = <_lvds>;
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
 };
 
  {
status = "okay";
 
lvds-channel@0 {
-   fsl,data-mapping = "spwg";
-   fsl,data-width = <18>;
+   reg = <0>;
status = "okay";
 
-   display-timings {
-   native-mode = <>;
-   timing0: timing0 {
-   clock-frequency = <4680>;
-   hactive = <1280>;
-   vactive = <480>;
-   hback-porch = <353>;
-   hfront-porch = <47>;
-   vback-porch = <39>;
-   vfront-porch = <4>;
-   hsync-len = <8>;
-   vsync-len = <2>;
+   port@4 {
+   reg = <4>;
+
+   lvds0_out: endpoint {
+   remote-endpoint = <_in>;
};
};
};
-- 
2.7.4

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

[PATCH] drm/msm: Call msm_init_vram before binding the gpu

[Craig Tatlor]

vram.size is needed when binding a gpu without an iommu and is defined
in msm_init_vram(), so run that before binding it.

Signed-off-by: Craig Tatlor 
---
 drivers/gpu/drm/msm/msm_drv.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index bdf0fe754f7b..82d4126ca017 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -400,6 +400,14 @@ static int msm_drm_init(struct device *dev, struct 
drm_driver *drv)
 
drm_mode_config_init(ddev);
 
+   ret = msm_init_vram(ddev);
+   if (ret) {
+   msm_mdss_destroy(ddev);
+   kfree(priv);
+   drm_dev_unref(ddev);
+   return ret;
+   }
+
/* Bind all our sub-components: */
ret = component_bind_all(dev, ddev);
if (ret) {
@@ -409,10 +417,6 @@ static int msm_drm_init(struct device *dev, struct 
drm_driver *drv)
return ret;
}
 
-   ret = msm_init_vram(ddev);
-   if (ret)
-   goto fail;
-
msm_gem_shrinker_init(ddev);
 
switch (get_mdp_ver(pdev)) {
-- 
2.15.1

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

[PATCH v3 0/7] ARM: dts: imx6q: engicam LVDS panel changes

[Jagan Teki]

Series adda LVDS panel attributes on panel drivers instead of defining
them in dts nodes, and also added new icorem6 engicam boards.

Jagan Teki (7):
  drm/panel: simple: add support for Ampire AM-800480AYTZQW-00H
  ARM: dts: imx6q-icore: Switch LVDS timings from panel-simple
  ARM: dts: imx6dl-icore: Add LVDS node
  drm/panel: simple: Add support for KEO TX31D200VM0BAA
  ARM: dts: imx6q-icore-ofcap12: Switch LVDS timings from panel-simple
  ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual OpenFrame Cap 7
initial support
  ARM: dts: imx6q: Add Engicam i.CoreM6 1.5 Quad/Dual MIPI starter kit
support

 .../display/panel/ampire,am-800480aytzqw-00h.txt   | 25 +
 .../bindings/display/panel/koe,tx31d200vm0baa.txt  | 25 +
 arch/arm/boot/dts/Makefile |  2 +
 arch/arm/boot/dts/imx6dl-icore.dts | 28 ++
 arch/arm/boot/dts/imx6q-icore-mipi.dts | 25 +
 arch/arm/boot/dts/imx6q-icore-ofcap12.dts  | 31 ++-
 arch/arm/boot/dts/imx6q-icore-ofcap7.dts   | 65 ++
 arch/arm/boot/dts/imx6q-icore.dts  | 31 ++-
 arch/arm/boot/dts/imx6qdl-icore.dtsi   | 25 -
 drivers/gpu/drm/panel/panel-simple.c   | 54 ++
 10 files changed, 282 insertions(+), 29 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/ampire,am-800480aytzqw-00h.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.txt
 create mode 100644 arch/arm/boot/dts/imx6q-icore-mipi.dts
 create mode 100644 arch/arm/boot/dts/imx6q-icore-ofcap7.dts

-- 
2.7.4

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

Re: [PATCH v2] Fixing arbitrary kernel leak in case FBIOGETCMAP_SPARC in sbusfb_ioctl_helper().

[Peter Malone]

Hi folks,

CVE-2018-6412 has been created for this. Is it possible for you to add a
note indicating the CVE number when merging the patch?

I received the CVE number after the patch was created and ack'd, which is
why I didn't include it in the commit message.



On Jan 31, 2018 10:49, "Mathieu Malaterre"  wrote:

> Hi Peter,
>
> On Wed, Jan 31, 2018 at 3:57 PM, Peter Malone 
> wrote:
> > Fixing arbitrary kernel leak in case FBIOGETCMAP_SPARC in
> > sbusfb_ioctl_helper().
> >
> > 'index' is defined as an int in sbusfb_ioctl_helper().
> > We retrieve this from the user:
> > if (get_user(index, >index) ||
> > __get_user(count, >count) ||
> > __get_user(ured, >red) ||
> > __get_user(ugreen, >green) ||
> > __get_user(ublue, >blue))
> >return -EFAULT;
> >
> > and then we use 'index' in the following way:
> > red = cmap->red[index + i] >> 8;
> > green = cmap->green[index + i] >> 8;
> > blue = cmap->blue[index + i] >> 8;
> >
> > This is a classic information leak vulnerability. 'index' should be
> > an unsigned int, given its usage above.
> >
> > This patch is straight-forward; it changes 'index' to unsigned int
> > in two switch-cases: FBIOGETCMAP_SPARC && FBIOPUTCMAP_SPARC.
> >
> > Signed-off-by: Peter Malone 
> > ---
>
> much better :)
>
> > v2: fixed formatting
> >
> >  drivers/video/fbdev/sbuslib.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/sbuslib.c
> b/drivers/video/fbdev/sbuslib.c
> > index af6fc97f4ba4..a436d44f1b7f 100644
> > --- a/drivers/video/fbdev/sbuslib.c
> > +++ b/drivers/video/fbdev/sbuslib.c
> > @@ -122,7 +122,7 @@ int sbusfb_ioctl_helper(unsigned long cmd, unsigned
> long arg,
> > unsigned char __user *ured;
> > unsigned char __user *ugreen;
> > unsigned char __user *ublue;
> > -   int index, count, i;
> > +   unsigned int index, count, i;
> >
> > if (get_user(index, >index) ||
> > __get_user(count, >count) ||
> > @@ -161,7 +161,7 @@ int sbusfb_ioctl_helper(unsigned long cmd, unsigned
> long arg,
> > unsigned char __user *ugreen;
> > unsigned char __user *ublue;
> > struct fb_cmap *cmap = >cmap;
> > -   int index, count, i;
> > +   unsigned int index, count, i;
> > u8 red, green, blue;
> >
> > if (get_user(index, >index) ||
> > --
> > 2.14.3
> >
>
> By just looking at the code and commit message:
>
> Acked-by: Mathieu Malaterre 
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 7/7] ARM: dts: imx6q: Add Engicam i.CoreM6 1.5 Quad/Dual MIPI starter kit support

[Jagan Teki]

i.CoreM6 1.5 is an another i.CoreM6 QDL cpu modules which can be connected
to EDIMM starter kit design with eMMC and MIPI-CSI interfaces suitable for
Android and video capture application.

notable features:
CPU NXP i.MX6 S/DL/D/Q, Up to 4 x Cortex-A9@800MHz
Memory  Up to 2 GB DDR3-1066
Video InterfacesUp to 1 Parallel Up to 2 LVDS HDMI 1.4
port 8 bit CSI INPUT MIPI-CSI INPUT
1 x 10/100 Ethernet interface, 2 x USB, 1 x PCIe, 1 x I2S etc

Signed-off-by: Jagan Teki 
---
Changes for v3:
- none
Changes for v2:
- new patch

 arch/arm/boot/dts/Makefile |  1 +
 arch/arm/boot/dts/imx6q-icore-mipi.dts | 25 +
 arch/arm/boot/dts/imx6qdl-icore.dtsi   | 23 +++
 3 files changed, 49 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-icore-mipi.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index aa60320..a0e46f3 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -456,6 +456,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-hummingboard2-emmc-som-v15.dtb \
imx6q-hummingboard2-som-v15.dtb \
imx6q-icore.dtb \
+   imx6q-icore-mipi.dtb \
imx6q-icore-ofcap10.dtb \
imx6q-icore-ofcap12.dtb \
imx6q-icore-ofcap7.dtb \
diff --git a/arch/arm/boot/dts/imx6q-icore-mipi.dts 
b/arch/arm/boot/dts/imx6q-icore-mipi.dts
new file mode 100644
index 000..acd3d33
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-icore-mipi.dts
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2017 Engicam S.r.l.
+ * Copyright (C) 2017 Amarula Solutions B.V.
+ * Author: Jagan Teki 
+ */
+
+/dts-v1/;
+
+#include "imx6q.dtsi"
+#include "imx6qdl-icore.dtsi"
+
+/ {
+   model = "Engicam i.CoreM6 Quad/Dual MIPI Starter Kit";
+   compatible = "engicam,imx6-icore", "fsl,imx6q";
+};
+
+ {
+   ddc-i2c-bus = <>;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6qdl-icore.dtsi 
b/arch/arm/boot/dts/imx6qdl-icore.dtsi
index 5fd9e00..d696447 100644
--- a/arch/arm/boot/dts/imx6qdl-icore.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-icore.dtsi
@@ -265,6 +265,14 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_usdhc3>;
+   no-1-8-v;
+   non-removable;
+   status = "disabled";
+};
+
  {
pinctrl_audmux: audmux {
fsl,pins = <
@@ -378,4 +386,19 @@
MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17070
>;
};
+
+   pinctrl_usdhc3: usdhc3grp {
+   fsl,pins = <
+   MX6QDL_PAD_SD3_CMD__SD3_CMD0x17059
+   MX6QDL_PAD_SD3_CLK__SD3_CLK0x10059
+   MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
+   MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
+   MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
+   MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
+   MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x17059
+   MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x17059
+   MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x17059
+   MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17059
+   >;
+   };
 };
-- 
2.7.4

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

[PATCH v3 6/7] ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual OpenFrame Cap 7 initial support

[Jagan Teki]

i.CoreM6 Quad/Dual OpenFrame modules are "system on modules plus
openframe display carriers" which are good solution for develop user
friendly graphic user interface.

ofcap 7 general features:
CPU   NXP Freescale i.MX6Q rev1.5 at 792 MHz
RAM   1GB, 32, 64 bit, DDR3-800/1066
NAND  SLC, 512MB
LVDS Display  TFT 7" industrial, 800x480 resolution
Touchscreen   EP0700M06 EDT Polytouch capacitive touch screen
Backlight LED backlight, brightness 300 Cd/m2
Power supply  15 to 30 Vdc

Signed-off-by: Jagan Teki 
---
Changes for v3:
- none
Changes for v2:
- Updated licence text - remove big notes, add SPDX and author

 arch/arm/boot/dts/Makefile   |  1 +
 arch/arm/boot/dts/imx6q-icore-ofcap7.dts | 65 
 2 files changed, 66 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-icore-ofcap7.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ade7a38..aa60320 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -458,6 +458,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-icore.dtb \
imx6q-icore-ofcap10.dtb \
imx6q-icore-ofcap12.dtb \
+   imx6q-icore-ofcap7.dtb \
imx6q-icore-rqs.dtb \
imx6q-marsboard.dtb \
imx6q-mccmon6.dtb \
diff --git a/arch/arm/boot/dts/imx6q-icore-ofcap7.dts 
b/arch/arm/boot/dts/imx6q-icore-ofcap7.dts
new file mode 100644
index 000..6ff7a0a
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-icore-ofcap7.dts
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2017 Engicam S.r.l.
+ * Copyright (C) 2017 Amarula Solutions B.V.
+ * Author: Jagan Teki 
+ */
+
+/dts-v1/;
+
+#include "imx6q.dtsi"
+#include "imx6qdl-icore.dtsi"
+
+/ {
+   model = "Engicam i.CoreM6 Quad/Dual OpenFrame Capacitive touch 7 Kit";
+   compatible = "engicam,imx6-icore", "fsl,imx6q";
+
+   panel {
+   compatible = "ampire,am-800480aytzqw-00h";
+   backlight = <_lvds>;
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+};
+
+ {
+   ep0700m06: touchscreen@38 {
+   compatible = "edt,edt-ft5406";
+   reg = <0x38>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_edt_ft5x06>;
+   interrupt-parent = <>;
+   interrupts = <30 IRQ_TYPE_NONE>;
+   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+   };
+};
+
+ {
+   status = "okay";
+
+   lvds-channel@0 {
+   reg = <0>;
+   status = "okay";
+
+   port@4 {
+   reg = <4>;
+
+   lvds0_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+};
+
+ {
+   pinctrl_edt_ft5x06:  edt-ft5x06grp  {
+   fsl,pins = <
+   MX6QDL_PAD_CSI0_DAT12__GPIO5_IO30 0x1b0b0 /*interrupt*/
+   MX6QDL_PAD_CSI0_DAT14__GPIO6_IO00 0x1b0b0 /*reset edt*/
+   >;
+   };
+};
-- 
2.7.4

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

Re: [PATCH] drm/msm/adreno/a5xx_debugfs: fix potential NULL pointer dereference

[Gustavo A. R. Silva]

Quoting Rob Clark :

On Fri, Feb 2, 2018 at 11:30 AM, Jordan Crouse  
 wrote:

On Fri, Feb 02, 2018 at 06:32:23AM -0600, Gustavo A. R. Silva wrote:

_minor_ is being dereferenced before it is null checked, hence there
is a potential null pointer dereference. Fix this by moving the pointer
dereference after _minor_ has been null checked.

Fixes: 024ad8df763f ("drm/msm: add a5xx specific debugfs")
Signed-off-by: Gustavo A. R. Silva 
---

I wonder if a better solution for this would be to WARN_ON in case _minor_
happens to be NULL and return -EINVAL, instead of just returning zero.

Something like:

struct drm_device *dev;

if (WARN_ON(!minor)
  return -EINVAL;

dev = minor->dev;

What do you think?


In my opinion everything in debugfs is optional. I'm not sure if it is even
possible for dev->primary, dev->render or dev->control to be NULL  
from the DRM

core but if so I think the failure should be silent.



Don't have code in front of me atm, but I think this is one of those
things you can hit both before and after we have the minor, depending
on whether filesystem and fw are present when the driver loads or
not.. so I don't think it should be a WARN_ON().



I get it. Then in this case this patch should work just fine.

Thank you both Jordan and Rob for the feedback.
--
Gustavo


BR,
-R



Jordan


 drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c  
b/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c

index 6b27941..059ec7d 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_debugfs.c
@@ -159,13 +159,15 @@ DEFINE_SIMPLE_ATTRIBUTE(reset_fops, NULL,  
reset_set, "%llx\n");


 int a5xx_debugfs_init(struct msm_gpu *gpu, struct drm_minor *minor)
 {
- struct drm_device *dev = minor->dev;
+ struct drm_device *dev;
  struct dentry *ent;
  int ret;

  if (!minor)
  return 0;

+ dev = minor->dev;
+
  ret = drm_debugfs_create_files(a5xx_debugfs_list,
  ARRAY_SIZE(a5xx_debugfs_list),
  minor->debugfs_root, minor);
--
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project







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

warning: "EDID_LENGTH" redefined (was Re: [PATCH v4] Fix loading of module radeonfb on PowerMac)

[Mathieu Malaterre]

Hi Dave,

Since I am not very familiar with the drm vs fbdev architecture, could
you please suggest a patch for the following [*].

Reference:
f453ba0460742 (Dave Airlie 2008-11-07 14:05:41 -0800  32)
#define EDID_LENGTH 128


Thanks

[*]
On Sat, Feb 3, 2018 at 3:39 AM, kbuild test robot  wrote:
> Hi Mathieu,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on linus/master]
> [also build test WARNING on v4.15 next-20180202]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Mathieu-Malaterre/Fix-loading-of-module-radeonfb-on-PowerMac/20180203-085907
> config: x86_64-randconfig-x009-201804 (attached as .config)
> compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All warnings (new ones prefixed by >>):
>
>In file included from drivers/video/fbdev/aty/radeon_base.c:91:0:
>>> drivers/video/fbdev/aty/../edid.h:21:0: warning: "EDID_LENGTH" redefined
> #define EDID_LENGTH0x80
>
>In file included from include/drm/drm_crtc.h:44:0,
> from include/drm/drm_fb_helper.h:35,
> from drivers/video/fbdev/aty/radeon_base.c:73:
>include/drm/drm_edid.h:32:0: note: this is the location of the previous 
> definition
> #define EDID_LENGTH 128
>
>Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls64
>Cyclomatic Complexity 1 include/linux/log2.h:__ilog2_u64
>Cyclomatic Complexity 1 include/asm-generic/getorder.h:__get_order
>Cyclomatic Complexity 1 include/linux/string.h:strnlen
>Cyclomatic Complexity 4 include/linux/string.h:strlen
>Cyclomatic Complexity 6 include/linux/string.h:strlcpy
>Cyclomatic Complexity 4 include/linux/string.h:memcpy
>Cyclomatic Complexity 1 
> arch/x86/include/asm/paravirt.h:arch_local_irq_disable
>Cyclomatic Complexity 1 
> arch/x86/include/asm/paravirt.h:arch_local_irq_enable
>Cyclomatic Complexity 1 include/linux/spinlock.h:spinlock_check
>Cyclomatic Complexity 1 include/linux/spinlock.h:spin_unlock_irqrestore
>Cyclomatic Complexity 1 include/linux/jiffies.h:_msecs_to_jiffies
>Cyclomatic Complexity 3 include/linux/jiffies.h:msecs_to_jiffies
>Cyclomatic Complexity 1 arch/x86/include/asm/io.h:readb
>Cyclomatic Complexity 1 arch/x86/include/asm/io.h:readw
>Cyclomatic Complexity 1 arch/x86/include/asm/io.h:readl
>Cyclomatic Complexity 1 arch/x86/include/asm/io.h:writeb
>Cyclomatic Complexity 1 arch/x86/include/asm/io.h:writel
>Cyclomatic Complexity 1 arch/x86/include/asm/io.h:ioremap
>Cyclomatic Complexity 1 include/linux/kobject.h:kobject_name
>Cyclomatic Complexity 2 include/linux/device.h:dev_name
>Cyclomatic Complexity 1 include/linux/device.h:dev_get_drvdata
>Cyclomatic Complexity 1 include/linux/device.h:dev_set_drvdata
>Cyclomatic Complexity 1 include/linux/io.h:arch_phys_wc_add
>Cyclomatic Complexity 1 include/linux/io.h:arch_phys_wc_del
>Cyclomatic Complexity 68 include/linux/slab.h:kmalloc_large
>Cyclomatic Complexity 3 include/linux/slab.h:kmalloc
>Cyclomatic Complexity 1 include/linux/slab.h:kzalloc
>Cyclomatic Complexity 1 include/linux/pci.h:pci_get_drvdata
>Cyclomatic Complexity 1 include/linux/pci.h:pci_set_drvdata
>Cyclomatic Complexity 1 include/linux/pci.h:pci_name
>Cyclomatic Complexity 2 include/linux/fb.h:alloc_apertures
>Cyclomatic Complexity 2 
> drivers/video/fbdev/aty/radeonfb.h:radeon_pll_errata_after_index
>Cyclomatic Complexity 2 
> drivers/video/fbdev/aty/radeonfb.h:radeon_pll_errata_after_data
>Cyclomatic Complexity 1 drivers/video/fbdev/aty/radeonfb.h:round_div
>Cyclomatic Complexity 3 drivers/video/fbdev/aty/radeonfb.h:var_to_depth
>Cyclomatic Complexity 5 
> drivers/video/fbdev/aty/radeonfb.h:radeon_get_dstbpp
>Cyclomatic Complexity 1 drivers/video/fbdev/aty/radeonfb.h:radeonfb_bl_init
>Cyclomatic Complexity 1 drivers/video/fbdev/aty/radeonfb.h:radeonfb_bl_exit
>Cyclomatic Complexity 1 
> include/drm/drm_fb_helper.h:drm_fb_helper_remove_conflicting_framebuffers
>Cyclomatic Complexity 21 
> drivers/video/fbdev/aty/radeon_base.c:radeon_calc_pll_regs
>Cyclomatic Complexity 1 drivers/video/fbdev/aty/radeon_base.c:radeonfb_exit
>Cyclomatic Complexity 6 
> drivers/video/fbdev/aty/radeon_base.c:radeon_find_mem_vbios
>Cyclomatic Complexity 4 
> drivers/video/fbdev/aty/radeon_base.c:radeon_kick_out_firmware_fb
>Cyclomatic Complexity 5 
> drivers/video/fbdev/aty/radeon_base.c:radeonfb_pci_unregister
>Cyclomatic Complexity 1 
> drivers/video/fbdev/aty/radeon_base.c:radeon_show_one_edid
>Cyclomatic Complexity 3 
> drivers/video/fbdev/aty/radeon_base.c:radeon_show_edid2
>Cyclomatic Complexity 3 
> drivers/video/fbdev/aty/radeon_base.c:radeon_show_edid1
>

[PATCH v3 4/7] drm/panel: simple: Add support for KEO TX31D200VM0BAA

[Jagan Teki]

This adds support for the Kaohsiung Opto-Electronics.,
TX31D200VM0BAA 12.3" HSXGA LVDS panel, which can be
supported by the simple panel driver.

Signed-off-by: Jagan Teki 
Reviewed-by: Rob Herring 
---
Changes for v3:
- collect Rob reiew tag 
Changes for v2:
- Updated binding info about optional properties, node and example

 .../bindings/display/panel/koe,tx31d200vm0baa.txt  | 25 
 drivers/gpu/drm/panel/panel-simple.c   | 27 ++
 2 files changed, 52 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.txt 
b/Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.txt
new file mode 100644
index 000..6a036ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.txt
@@ -0,0 +1,25 @@
+Kaohsiung Opto-Electronics. TX31D200VM0BAA 12.3" HSXGA LVDS panel
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
+
+Required properties:
+- compatible: should be "koe,tx31d200vm0baa"
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+
+Optional nodes:
+- Video port for LVDS panel input.
+
+Example:
+   panel {
+   compatible = "koe,tx31d200vm0baa";
+   backlight = <_lvds>;
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 2ecc14b..8a0e4a8 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1241,6 +1241,30 @@ static const struct panel_desc innolux_zj070na_01p = {
},
 };
 
+static const struct display_timing koe_tx31d200vm0baa_timing = {
+   .pixelclock = { 3960, 4320, 4800 },
+   .hactive = { 1280, 1280, 1280 },
+   .hfront_porch = { 16, 36, 56 },
+   .hback_porch = { 16, 36, 56 },
+   .hsync_len = { 8, 8, 8 },
+   .vactive = { 480, 480, 480 },
+   .vfront_porch = { 6, 21, 33.5 },
+   .vback_porch = { 6, 21, 33.5 },
+   .vsync_len = { 8, 8, 8 },
+   .flags = DISPLAY_FLAGS_DE_HIGH,
+};
+
+static const struct panel_desc koe_tx31d200vm0baa = {
+   .timings = _tx31d200vm0baa_timing,
+   .num_timings = 1,
+   .bpc = 6,
+   .size = {
+   .width = 292,
+   .height = 109,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+};
+
 static const struct display_timing kyo_tcg121xglp_timing = {
.pixelclock = { 5200, 6500, 7100 },
.hactive = { 1024, 1024, 1024 },
@@ -2151,6 +2175,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "innolux,zj070na-01p",
.data = _zj070na_01p,
}, {
+   .compatible = "koe,tx31d200vm0baa",
+   .data = _tx31d200vm0baa,
+   }, {
.compatible = "kyo,tcg121xglp",
.data = _tcg121xglp,
}, {
-- 
2.7.4

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

[PATCH v3 2/7] ARM: dts: imx6q-icore: Switch LVDS timings from panel-simple

[Jagan Teki]

Switch to use ampire,am-800480aytzqw-00h LVDS timings from
panel-simple instead hard coding the same in dts.

Signed-off-by: Jagan Teki 
---
Changes for v3, v2:
- none

 arch/arm/boot/dts/imx6q-icore.dts| 31 +--
 arch/arm/boot/dts/imx6qdl-icore.dtsi |  2 +-
 2 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q-icore.dts 
b/arch/arm/boot/dts/imx6q-icore.dts
index 5613dd9..c8e464e 100644
--- a/arch/arm/boot/dts/imx6q-icore.dts
+++ b/arch/arm/boot/dts/imx6q-icore.dts
@@ -48,6 +48,17 @@
 / {
model = "Engicam i.CoreM6 Quad/Dual Starter Kit";
compatible = "engicam,imx6-icore", "fsl,imx6q";
+
+   panel {
+   compatible = "ampire,am-800480aytzqw-00h";
+   backlight = <_lvds>;
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
 };
 
  {
@@ -71,22 +82,14 @@
status = "okay";
 
lvds-channel@0 {
-   fsl,data-mapping = "spwg";
-   fsl,data-width = <18>;
+   reg = <0>;
status = "okay";
 
-   display-timings {
-   native-mode = <>;
-   timing0: timing0 {
-   clock-frequency = <6000>;
-   hactive = <800>;
-   vactive = <480>;
-   hback-porch = <30>;
-   hfront-porch = <30>;
-   vback-porch = <5>;
-   vfront-porch = <5>;
-   hsync-len = <64>;
-   vsync-len = <20>;
+   port@4 {
+   reg = <4>;
+
+   lvds0_out: endpoint {
+   remote-endpoint = <_in>;
};
};
};
diff --git a/arch/arm/boot/dts/imx6qdl-icore.dtsi 
b/arch/arm/boot/dts/imx6qdl-icore.dtsi
index a1b469c..5fd9e00 100644
--- a/arch/arm/boot/dts/imx6qdl-icore.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-icore.dtsi
@@ -49,7 +49,7 @@
reg = <0x1000 0x8000>;
};
 
-   backlight {
+   backlight_lvds: backlight-lvds {
compatible = "pwm-backlight";
pwms = < 0 10>;
brightness-levels = <0 4 8 16 32 64 128 255>;
-- 
2.7.4

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

[PATCH v3 3/7] ARM: dts: imx6dl-icore: Add LVDS node

[Jagan Teki]

Add ampire,am-800480aytzqw-00h LVDS support by using
timings from panel-simple.

Signed-off-by: Jagan Teki 
---
Changes for v3, v2:
- none

 arch/arm/boot/dts/imx6dl-icore.dts | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/imx6dl-icore.dts 
b/arch/arm/boot/dts/imx6dl-icore.dts
index 971f9fc..74bff84 100644
--- a/arch/arm/boot/dts/imx6dl-icore.dts
+++ b/arch/arm/boot/dts/imx6dl-icore.dts
@@ -48,6 +48,17 @@
 / {
model = "Engicam i.CoreM6 DualLite/Solo Starter Kit";
compatible = "engicam,imx6-icore", "fsl,imx6dl";
+
+   panel {
+   compatible = "ampire,am-800480aytzqw-00h";
+   backlight = <_lvds>;
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
 };
 
  {
@@ -66,3 +77,20 @@
interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
};
 };
+
+ {
+   status = "okay";
+
+   lvds-channel@0 {
+   reg = <0>;
+   status = "okay";
+
+   port@4 {
+   reg = <4>;
+
+   lvds0_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+};
-- 
2.7.4

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

[PATCH v3 1/7] drm/panel: simple: add support for Ampire AM-800480AYTZQW-00H

[Jagan Teki]

This adds support for the Ampire AM-800480AYTZQW-00H 7.0" WGA LCD,
which can be supported by the simple panel driver.

Signed-off-by: Jagan Teki 
Reviewed-by: Rob Herring 
---
Changes for v3:
- collect Rob reiew tag 
Changes for v2:
- Updated binding info about optional properties, node and example

 .../display/panel/ampire,am-800480aytzqw-00h.txt   | 25 
 drivers/gpu/drm/panel/panel-simple.c   | 27 ++
 2 files changed, 52 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/ampire,am-800480aytzqw-00h.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/ampire,am-800480aytzqw-00h.txt
 
b/Documentation/devicetree/bindings/display/panel/ampire,am-800480aytzqw-00h.txt
new file mode 100644
index 000..abb5eee
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/panel/ampire,am-800480aytzqw-00h.txt
@@ -0,0 +1,25 @@
+Ampire AM-800480AYTZQW-00H 7.0" WVGA TFT LCD panel
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
+
+Required properties:
+- compatible: should be "ampire,am-800480aytzqw-00h"
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+
+Optional nodes:
+- Video port for LVDS panel input.
+
+Example:
+   panel {
+   compatible = "ampire,am-800480aytzqw-00h";
+   backlight = <_lvds>;
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 5591984..2ecc14b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -412,6 +412,30 @@ static const struct panel_desc ampire_am_480272h3tmqw_t01h 
= {
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
 };
 
+static const struct display_timing ampire_am_800480aytzqw_00h_timing = {
+   .pixelclock = { 2770, 2920, 3960 },
+   .hactive = { 800, 800, 800 },
+   .hfront_porch = { 12, 40, 212 },
+   .hback_porch = { 88, 88, 88 },
+   .hsync_len = { 1, 2, 40 },
+   .vactive = { 480, 480, 480 },
+   .vfront_porch = { 1, 13, 88 },
+   .vback_porch = { 32, 32, 32 },
+   .vsync_len = { 1, 2, 3 },
+   .flags = DISPLAY_FLAGS_DE_HIGH,
+};
+
+static const struct panel_desc ampire_am_800480aytzqw_00h = {
+   .timings = _am_800480aytzqw_00h_timing,
+   .num_timings = 1,
+   .bpc = 6,
+   .size = {
+   .width = 154,
+   .height = 86,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+};
+
 static const struct drm_display_mode ampire_am800480r3tmqwa1h_mode = {
.clock = 3,
.hdisplay = 800,
@@ -2028,6 +2052,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "ampire,am-480272h3tmqw-t01h",
.data = _am_480272h3tmqw_t01h,
}, {
+   .compatible = "ampire,am-800480aytzqw-00h",
+   .data = _am_800480aytzqw_00h,
+   }, {
.compatible = "ampire,am800480r3tmqwa1h",
.data = _am800480r3tmqwa1h,
}, {
-- 
2.7.4

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

Re: [PATCH v2] Fixing arbitrary kernel leak in case FBIOGETCMAP_SPARC in sbusfb_ioctl_helper().

[Peter Malone]

Hi folks,

CVE-2018-6412 has been created for this. Is it possible for you to add
a note indicating the CVE number when merging the patch?

I received the CVE number after the patch was created and ack'd, which
is why I didn't include it in the commit message.

On Wed, Jan 31, 2018 at 10:49 AM, Mathieu Malaterre  wrote:
> Hi Peter,
>
> On Wed, Jan 31, 2018 at 3:57 PM, Peter Malone  wrote:
>> Fixing arbitrary kernel leak in case FBIOGETCMAP_SPARC in
>> sbusfb_ioctl_helper().
>>
>> 'index' is defined as an int in sbusfb_ioctl_helper().
>> We retrieve this from the user:
>> if (get_user(index, >index) ||
>> __get_user(count, >count) ||
>> __get_user(ured, >red) ||
>> __get_user(ugreen, >green) ||
>> __get_user(ublue, >blue))
>>return -EFAULT;
>>
>> and then we use 'index' in the following way:
>> red = cmap->red[index + i] >> 8;
>> green = cmap->green[index + i] >> 8;
>> blue = cmap->blue[index + i] >> 8;
>>
>> This is a classic information leak vulnerability. 'index' should be
>> an unsigned int, given its usage above.
>>
>> This patch is straight-forward; it changes 'index' to unsigned int
>> in two switch-cases: FBIOGETCMAP_SPARC && FBIOPUTCMAP_SPARC.
>>
>> Signed-off-by: Peter Malone 
>> ---
>
> much better :)
>
>> v2: fixed formatting
>>
>>  drivers/video/fbdev/sbuslib.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/sbuslib.c b/drivers/video/fbdev/sbuslib.c
>> index af6fc97f4ba4..a436d44f1b7f 100644
>> --- a/drivers/video/fbdev/sbuslib.c
>> +++ b/drivers/video/fbdev/sbuslib.c
>> @@ -122,7 +122,7 @@ int sbusfb_ioctl_helper(unsigned long cmd, unsigned long 
>> arg,
>> unsigned char __user *ured;
>> unsigned char __user *ugreen;
>> unsigned char __user *ublue;
>> -   int index, count, i;
>> +   unsigned int index, count, i;
>>
>> if (get_user(index, >index) ||
>> __get_user(count, >count) ||
>> @@ -161,7 +161,7 @@ int sbusfb_ioctl_helper(unsigned long cmd, unsigned long 
>> arg,
>> unsigned char __user *ugreen;
>> unsigned char __user *ublue;
>> struct fb_cmap *cmap = >cmap;
>> -   int index, count, i;
>> +   unsigned int index, count, i;
>> u8 red, green, blue;
>>
>> if (get_user(index, >index) ||
>> --
>> 2.14.3
>>
>
> By just looking at the code and commit message:
>
> Acked-by: Mathieu Malaterre 



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

[Bug 198669] Driver crash at radeon_ring_backup+0xd3/0x140 [radeon]

[bugzilla-daemon]

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

--- Comment #2 from ro...@beardandsandals.co.uk (ro...@beardandsandals.co.uk) 
---
Looking at the debug files.

radeon_ring_backup resolves to 0x33430 so +0xd4 is 0x33503.

The line info gives this

radeon_ring.c323 0x334f4
radeon_ring.c324 0x33508

-- 
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] drm/bridge/synopsys: dsi: Add 1.31 version support

[Philippe CORNU]

Hi Archit,

and many thanks for your comments

On 02/04/2018 04:13 PM, Archit wrote:
> Hi Phillipe,
> 
> On Saturday 03 February 2018 03:49 AM, Philippe CORNU wrote:
>> Hi Archit, Andrzej, Laurent & Brian,
>>
>> What is your opinion regarding this patch? Do you have any advice for
>> handling hw versions?
>>
>> Do not hesitate to comment.
> 
> The patch looks mostly good to me. One query below.
> 
>>
>> Many thanks,
>> Philippe :-)
>>
>>
>> On 01/22/2018 04:08 PM, Philippe Cornu wrote:
>>> From: Philippe CORNU 
>>>
>>> Add support for the Synopsys DesignWare MIPI DSI version 1.31
>>> Two registers need to be updated/added for supporting 1.31:
>>> * PHY_TMR_CFG 0x9c (updated)
>>>     1.30 [31:24] phy_hs2lp_time
>>>  [23:16] phy_lp2hs_time
>>>  [14: 0] max_rd_time
>>>
>>>     1.31 [25:16] phy_hs2lp_time
>>>  [ 9: 0] phy_lp2hs_time
>>>
>>> * PHY_TMR_RD_CFG 0xf4 (new)
>>>     1.31 [14: 0] max_rd_time
>>>
>>> Signed-off-by: Philippe Cornu 
>>> ---
>>>    drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 52 
>>> +++
>>>    1 file changed, 46 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
>>> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> index 735f38429c06..20a2ca14a7ad 100644
>>> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
>>> @@ -25,7 +25,13 @@
>>>    #include 
>>>    #include 
>>> +#define HWVER_130    0x31333000    /* IP version 1.30 */
>>> +#define HWVER_131    0x31333100    /* IP version 1.31 */
>>> +#define HWVER_OLDEST    HWVER_130
>>> +#define HWVER_NEWEST    HWVER_131
>>> +
>>>    #define DSI_VERSION    0x00
>>> +#define VERSION    GENMASK(31, 8)
>>>    #define DSI_PWR_UP    0x04
>>>    #define RESET    0
>>> @@ -161,11 +167,12 @@
>>>    #define PHY_CLKHS2LP_TIME(lbcc)    (((lbcc) & 0x3ff) << 16)
>>>    #define PHY_CLKLP2HS_TIME(lbcc)    ((lbcc) & 0x3ff)
>>> -/* TODO Next register is slightly different between 1.30 & 1.31 IP 
>>> version */
>>>    #define DSI_PHY_TMR_CFG    0x9c
>>> -#define PHY_HS2LP_TIME(lbcc)    (((lbcc) & 0xff) << 24)
>>> -#define PHY_LP2HS_TIME(lbcc)    (((lbcc) & 0xff) << 16)
>>> -#define MAX_RD_TIME(lbcc)    ((lbcc) & 0x7fff)
>>> +#define PHY_HS2LP_TIME_V130(lbcc)    (((lbcc) & 0xff) << 24)
>>> +#define PHY_LP2HS_TIME_V130(lbcc)    (((lbcc) & 0xff) << 16)
>>> +#define MAX_RD_TIME_V130(lbcc)    ((lbcc) & 0x7fff)
>>> +#define PHY_HS2LP_TIME_V131(lbcc)    (((lbcc) & 0x3ff) << 16)
>>> +#define PHY_LP2HS_TIME_V131(lbcc)    ((lbcc) & 0x3ff)
>>>    #define DSI_PHY_RSTZ    0xa0
>>>    #define PHY_DISFORCEPLL    0
>>> @@ -204,7 +211,9 @@
>>>    #define DSI_INT_ST1    0xc0
>>>    #define DSI_INT_MSK0    0xc4
>>>    #define DSI_INT_MSK1    0xc8
>>> +
>>>    #define DSI_PHY_TMR_RD_CFG    0xf4
>>> +#define MAX_RD_TIME_V131(lbcc)    ((lbcc) & 0x7fff)
>>>    #define PHY_STATUS_TIMEOUT_US    1
>>>    #define CMD_PKT_STATUS_TIMEOUT_US    2
>>> @@ -215,6 +224,7 @@ struct dw_mipi_dsi {
>>>    struct drm_bridge *panel_bridge;
>>>    struct device *dev;
>>>    void __iomem *base;
>>> +    u32 hw_version;
>>>    struct clk *pclk;
>>>    struct clk *px_clk;
>>> @@ -616,8 +626,14 @@ static void 
>>> dw_mipi_dsi_dphy_timing_config(struct dw_mipi_dsi *dsi)
>>>     * note: DSI_PHY_TMR_CFG.MAX_RD_TIME should be in line with
>>>     * DSI_CMD_MODE_CFG.MAX_RD_PKT_SIZE_LP (see CMD_MODE_ALL_LP)
>>>     */
>>> -    dsi_write(dsi, DSI_PHY_TMR_CFG, PHY_HS2LP_TIME(0x40)
>>> -  | PHY_LP2HS_TIME(0x40) | MAX_RD_TIME(1));
>>> +    if (dsi->hw_version == HWVER_131) {
>>> +    dsi_write(dsi, DSI_PHY_TMR_CFG, PHY_HS2LP_TIME_V131(0x40) |
>>> +  PHY_LP2HS_TIME_V131(0x40));
>>> +    dsi_write(dsi, DSI_PHY_TMR_RD_CFG, MAX_RD_TIME_V131(1));
>>> +    } else {
>>> +    dsi_write(dsi, DSI_PHY_TMR_CFG, PHY_HS2LP_TIME_V130(0x40) |
>>> +  PHY_LP2HS_TIME_V130(0x40) | MAX_RD_TIME_V130(1));
>>> +    }
>>>    dsi_write(dsi, DSI_PHY_TMR_LPCLK_CFG, PHY_CLKHS2LP_TIME(0x40)
>>>  | PHY_CLKLP2HS_TIME(0x40));
>>> @@ -791,6 +807,28 @@ static const struct drm_bridge_funcs 
>>> dw_mipi_dsi_bridge_funcs = {
>>>    .attach  = dw_mipi_dsi_bridge_attach,
>>>    };
>>> +static void dsi_get_version(struct dw_mipi_dsi *dsi)
>>> +{
>>> +    u32 hw_version;
>>> +
>>> +    clk_prepare_enable(dsi->pclk);
>>> +    hw_version = dsi_read(dsi, DSI_VERSION) & VERSION;
>>> +    clk_disable_unprepare(dsi->pclk);
>>> +
>>> +    if (hw_version > HWVER_NEWEST) {
>>> +    DRM_DEBUG("hw version: use 0x%08x for this recent 0x%08x\n",
>>> +  HWVER_NEWEST, hw_version);
>>> +    hw_version = HWVER_NEWEST;
>>> +
>>> +    } else if (hw_version < HWVER_OLDEST) {
>>> + 

[Bug 100745] amdgpu fails to wake up DisplayPort DELL monitors with 'clock recovery failed'

[bugzilla-daemon]

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

--- Comment #13 from Dimitrios Liappis  ---
(In reply to Michel Dänzer from comment #12)
> 
> FWIW, that's most likely a gnome-shell/mutter bug.

Thank you, indeed this is a mutter bug; I hunted the bug in
https://bugzilla.gnome.org/show_bug.cgi?id=789501 and there is a specific patch
for a monitor-manager/kms bug that fixes it, as described in
https://bugzilla.gnome.org/show_bug.cgi?id=789501.

-- 
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 92827] Tonga: No Sound over HDMI with connected AV receiver

[bugzilla-daemon]

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

--- Comment #8 from Alex Deucher  ---
I suspect the receiver manufacturer never validated DPMS.  Most consumer
electronic devices (media players, DVD, Bluray, cable boxes, etc.) don't
actually blank the display.

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

[Bug 100289] 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor

[bugzilla-daemon]

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

--- Comment #15 from omegap...@startmail.com ---
After being able to identify xfsettingsd as a potential cause (ignoring whether
or not the monitor was actually Disconnected/Connected), I had a look at its
bug tracker - and https://bugzilla.xfce.org/show_bug.cgi?id=14096 looks
extremely suspicious - after applying the patch and turning on/off the monitor
10 times in a row (waiting 10 seconds inbetween), I haven't had a single
desktop reconfiguration (the patch makes complete sense too WRT this problem),
so I'm going to sit on this for a week to make sure its actually solved.

There seem to be a number of other people complaining of this issue over there
too...

-- 
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 104919] R9285 4.17-wip locks/vmfaults since drm/amdgpu: revert "drm/amdgpu: use AMDGPU_GEM_CREATE_VRAM_CLEARED for VM PD/PTs" v2

[bugzilla-daemon]

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

Christian König  changed:

   What|Removed |Added

 CC||ckoenig.leichtzumerken@gmai
   ||l.com

--- Comment #5 from Christian König  ---
Created attachment 137166
  --> https://bugs.freedesktop.org/attachment.cgi?id=137166=edit
Possible fix

One thing I've found while looking at the code.

Please test if that fixed the issue.

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

[Bug 198669] Driver crash at radeon_ring_backup+0xd3/0x140 [radeon]

[bugzilla-daemon]

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

Christian König (christian.koe...@amd.com) changed:

   What|Removed |Added

 CC||christian.koe...@amd.com

--- Comment #1 from Christian König (christian.koe...@amd.com) ---
What does radeon_ring_backup+0xd3 resolve to on your system?

-- 
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 100289] 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor

[bugzilla-daemon]

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

--- Comment #14 from omegap...@startmail.com ---
After messing around with this on and off for months, I have found that the
radeon_scanout_flip error is irrelevant - when the third monitor is turned off
and on, sometimes DisplayPort-0 is reported as Disconnected and then Connected
- through monitoring the root window (xev -root), I can finally get into a
useful X events stream:

==

RRScreenChangeNotify event, serial 114, synthetic NO, window 0x4bc,
root 0x4bc, timestamp 332828415, config_timestamp 386328254
size_index 65535, subpixel_order SubPixelHorizontalRGB
rotation RR_Rotate_0
width 5760, height 1200, mwidth 1526, mheight 318

RRNotify event, serial 114, synthetic NO, window 0x4bc,
subtype XRROutputChangeNotifyEvent
output DisplayPort-0, crtc 79, mode 1920x1200 (1920x1200)
rotation RR_Rotate_0
connection RR_Disconnected, subpixel_order SubPixelHorizontalRGB

RRScreenChangeNotify event, serial 115, synthetic NO, window 0x4bc,
root 0x4bc, timestamp 332828415, config_timestamp 386328254
size_index 65535, subpixel_order SubPixelHorizontalRGB
rotation RR_Rotate_0
width 5760, height 1200, mwidth 1526, mheight 318

RRNotify event, serial 115, synthetic NO, window 0x4bc,
subtype XRRCrtcChangeNotifyEvent
crtc 79, mode None, rotation RR_Rotate_0
x 0, y 0, width 0, height 0

RRNotify event, serial 115, synthetic NO, window 0x4bc,
subtype XRROutputChangeNotifyEvent
output DisplayPort-0, crtc None, mode None
rotation RR_Rotate_0
connection RR_Disconnected, subpixel_order SubPixelHorizontalRGB

ConfigureNotify event, serial 115, synthetic NO, window 0x4bc,
event 0x4bc, window 0x4bc, (0,0), width 5760, height 1200,
border_width 0, above 0x0, override NO

RRScreenChangeNotify event, serial 117, synthetic NO, window 0x4bc,
root 0x4bc, timestamp 386328636, config_timestamp 386328813
size_index 65535, subpixel_order SubPixelHorizontalRGB
rotation RR_Rotate_0
width 5760, height 1200, mwidth 1526, mheight 318

RRNotify event, serial 117, synthetic NO, window 0x4bc,
subtype XRROutputChangeNotifyEvent
output DisplayPort-0, crtc None, mode None
rotation RR_Rotate_0
connection RR_Connected, subpixel_order SubPixelHorizontalRGB

RRScreenChangeNotify event, serial 117, synthetic NO, window 0x4bc,
root 0x4bc, timestamp 386328636, config_timestamp 386328813
size_index 65535, subpixel_order SubPixelHorizontalRGB
rotation RR_Rotate_0
width 3840, height 1200, mwidth 1016, mheight 318

ConfigureNotify event, serial 117, synthetic NO, window 0x4bc,
event 0x4bc, window 0x4bc, (0,0), width 3840, height 1200,
border_width 0, above 0x0, override NO

...


RRScreenChangeNotify event, serial 125, synthetic NO, window 0x4bc,
root 0x4bc, timestamp 386328636, config_timestamp 386328813
size_index 65535, subpixel_order SubPixelHorizontalRGB
rotation RR_Rotate_0
width 3840, height 1200, mwidth 1016, mheight 318

RRNotify event, serial 125, synthetic NO, window 0x4bc,
subtype XRRCrtcChangeNotifyEvent
crtc 79, mode 1920x1200, rotation RR_Rotate_0
x 0, y 0, width 1920, height 1200

RRNotify event, serial 125, synthetic NO, window 0x4bc,
subtype XRROutputChangeNotifyEvent
output DisplayPort-0, crtc 79, mode 1920x1200 (1920x1200)
rotation RR_Rotate_0
connection RR_Connected, subpixel_order SubPixelHorizontalRGB

ConfigureNotify event, serial 125, synthetic NO, window 0x4bc,
event 0x4bc, window 0x4bc, (0,0), width 3840, height 1200,
border_width 0, above 0x0, override NO

==

In the middle of that mess, there is a RRScreenChangeNotify event with width
3840, which signifies the invalid desktop state that I get as the result of the
problem - I've managed to smoke it out to xfsettingsd (part of the
xfce4-settings package) - it responds to the disconnection by disabling the
CRTC, and then when it reappears, it enables it without a clue of what the
monitor is, despite it being described in the xfconf settings - and therefore
not putting it in the right place again.

xfsettingsd's version of the events:

=

Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
xfce4-settings(displays): RRScreenChangeNotify event received.
xfce4-settings(displays): Refreshing RandR cache.
xfce4-settings(displays): Detected CRTC 80.
xfce4-settings(displays): Detected CRTC 79.
xfce4-settings(displays): Detected CRTC 81.
xfce4-settings(displays): Detected CRTC 82.
xfce4-settings(displays): Detected CRTC 83.
xfce4-settings(displays): Detected CRTC 84.
xfce4-settings(displays): Detected output 85 DisplayPort-0.
xfce4-settings(displays): Detected output 86 HDMI-0.
xfce4-settings(displays): Detected output 88 DVI-1.

[Bug 198669] Driver crash at radeon_ring_backup+0xd3/0x140 [radeon]

[bugzilla-daemon]

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

ro...@beardandsandals.co.uk (ro...@beardandsandals.co.uk) changed:

   What|Removed |Added

URL||https://bugs.launchpad.net/
   ||ubuntu/+source/linux/+bug/1
   ||746232

-- 
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 198669] New: Driver crash at radeon_ring_backup+0xd3/0x140 [radeon]

[bugzilla-daemon]

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

Bug ID: 198669
   Summary: Driver crash at radeon_ring_backup+0xd3/0x140 [radeon]
   Product: Drivers
   Version: 2.5
Kernel Version: 4.13.0-32-generic x86_64
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: ro...@beardandsandals.co.uk
Regression: No

This is a resilience bug in the driver. When trying to recover from a GPU stall
radeon_ring_backup causes a paging violation.

[  488.507091] BUG: unable to handle kernel paging request at b406c1891ffc
[  488.507176] IP: radeon_ring_backup+0xd3/0x140 [radeon]

The GPU stall is caused by a hardware problem triggered by vibration. N.B. This
bug is not abput the hardware problem. It is about the drivers resilience when
trying to recover from it.

It is very similar to bug #62721 reported 4 years ago. However this is
occurring using with the driver in the 4.13.0 kernel.

Here os the dmesg output.

[  139.457873] rfkill: input handler disabled
[  468.102340] radeon :02:00.0: ring 0 stalled for more than 10256msec
[  468.102346] radeon :02:00.0: GPU lockup (current fence id
0x1bdb last fence id 0x1bdc on ring 0)

... Similar lines removed

[  487.558156] radeon :02:00.0: ring 0 stalled for more than 29712msec
[  487.558161] radeon :02:00.0: GPU lockup (current fence id
0x1bdb last fence id 0x1bdc on ring 0)
[  488.070157] radeon :02:00.0: ring 0 stalled for more than 30224msec
[  488.070162] radeon :02:00.0: GPU lockup (current fence id
0x1bdb last fence id 0x1bdc on ring 0)
[  488.507091] BUG: unable to handle kernel paging request at b406c1891ffc
[  488.507176] IP: radeon_ring_backup+0xd3/0x140 [radeon]
[  488.507195] PGD 236d37067 
[  488.507196] P4D 236d37067 
[  488.507207] PUD 0 

[  488.507234] Oops:  [#1] SMP PTI
[  488.507248] Modules linked in: rfcomm bnep bonding binfmt_misc btusb btrtl
btbcm btintel intel_powerclamp joydev coretemp kvm_intel kvm input_leds
bluetooth ecdh_generic arc4 ath9k ath9k_common ath9k_hw ath mac80211 irqbypass
snd_seq_midi snd_seq_midi_event intel_cstate snd_hda_codec_realtek
snd_hda_codec_generic snd_hda_codec_hdmi snd_rawmidi cfg80211 snd_hda_intel
snd_hda_codec snd_hda_core snd_hwdep serio_raw snd_pcm snd_seq snd_seq_device
snd_timer snd lpc_ich shpchp i7core_edac mac_hid i5500_temp soundcore
tpm_infineon asus_atk0110 nfsd auth_rpcgss nfs_acl lockd grace sunrpc
parport_pc ppdev lp parport ip_tables x_tables autofs4 amdkfd amd_iommu_v2
radeon i2c_algo_bit ttm drm_kms_helper hid_generic syscopyarea uas sysfillrect
usbhid sysimgblt firewire_ohci fb_sys_fops usb_storage pata_acpi hid
[  488.507500]  psmouse firewire_core r8169 drm crc_itu_t mii
[  488.507523] CPU: 7 PID: 2073 Comm: gnome-shell Tainted: G  I
4.13.0-32-generic #35-Ubuntu
[  488.507554] Hardware name: System manufacturer System Product Name/P6T SE,
BIOS 040305/19/2009
[  488.507584] task: 9e0cb6191600 task.stack: b402c3724000
[  488.507619] RIP: 0010:radeon_ring_backup+0xd3/0x140 [radeon]
[  488.507639] RSP: 0018:b402c3727c00 EFLAGS: 00010246
[  488.507658] RAX: 9e0c6f30 RBX: 00037ba1 RCX:

[  488.507682] RDX:  RSI: b406c1891ffc RDI:
000dee84
[  488.507707] RBP: b402c3727c28 R08: 000269a8 R09:
000b2c44
[  488.507731] R10: dc5046bd R11: 9e0cfffd1d00 R12:
b402c3727c68
[  488.507756] R13: 9e0ceafc9538 R14: 9e0ceafc9558 R15:

[  488.507780] FS:  7fdc82a60ac0() GS:9e0cf73c()
knlGS:
[  488.507808] CS:  0010 DS:  ES:  CR0: 80050033
[  488.507828] CR2: b406c1891ffc CR3: 0001f632a000 CR4:
06e0
[  488.507853] Call Trace:
[  488.507875]  radeon_gpu_reset+0xc0/0x330 [radeon]
[  488.507895]  ? dma_fence_wait_timeout+0x38/0xf0
[  488.507912]  ? reservation_object_wait_timeout_rcu+0x14f/0x2d0
[  488.507946]  radeon_gem_handle_lockup.part.4+0xe/0x20 [radeon]
[  488.507979]  radeon_gem_wait_idle_ioctl+0x9c/0x100 [radeon]
[  488.508012]  ? radeon_gem_busy_ioctl+0x80/0x80 [radeon]
[  488.508040]  drm_ioctl_kernel+0x5d/0xb0 [drm]
[  488.508063]  drm_ioctl+0x31b/0x3d0 [drm]
[  488.508091]  ? radeon_gem_busy_ioctl+0x80/0x80 [radeon]
[  488.508111]  ? futex_wake+0x8f/0x180
[  488.508134]  radeon_drm_ioctl+0x4f/0x90 [radeon]
[  488.508153]  do_vfs_ioctl+0xa5/0x610
[  488.509723]  ? entry_SYSCALL_64_after_hwframe+0x118/0x168
[  488.511292]  ? entry_SYSCALL_64_after_hwframe+0x111/0x168
[  488.512853]  ? entry_SYSCALL_64_after_hwframe+0x10a/0x168
[  488.514405]  ? entry_SYSCALL_64_after_hwframe+0x103/0x168
[  488.515956]  ? 

[Bug 99923] HITMAN (2016) having lighting and artefacting, and overly light room.

[bugzilla-daemon]

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

--- Comment #21 from Christoph Schwerdtfeger  ---
Still no change with Mesa 18.0rc20 (LLVM 5.0.1)

It's now nearly a year ago that the game stopped working properly and I can't
play it as is.


# glxinfo | grep Mesa
client glx vendor string: Mesa Project and SGI
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.0.0-rc2
OpenGL version string: 3.0 Mesa 18.0.0-rc2
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.0.0-rc2

# glxinfo | grep -i llvm
Device: AMD TAHITI (DRM 2.50.0 / 4.14.0-3-amd64, LLVM 5.0.1) (0x679a)
OpenGL renderer string: AMD TAHITI (DRM 2.50.0 / 4.14.0-3-amd64, LLVM 5.0.1)

-- 
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 104001] GPU driver hung when start steam client while playback video on Youtube (it occurs on latest staging kernel)

[bugzilla-daemon]

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

--- Comment #20 from mikhail.v.gavri...@gmail.com ---
Anybody is investigated this bug?
It is not necessary watch video for occurring computer hung.
It hangs just after running the client's Steam or during the game if computer
already worked some time.
I'm already tired of pressing the reset button because "init 6" is not able to
restart the computer after such a hang.
For today I already press reset button more than 30 times.
But no one care about it :(

-- 
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 92827] Tonga: No Sound over HDMI with connected AV receiver

[bugzilla-daemon]

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

--- Comment #7 from Michael Zapf  ---
With 4.15 (and the kernel boot parameter!) I now managed to get audio output
via HDMI. 

Splendid!

My configuration is 

PC HDMI---> Pioneer AV receiver (vsx330) ---HDMI---> HP monitor (lp2475w)

But there is one bad effect now: When I turn off the monitor during runtime, or
if the monitor enters power-save state, and it is turned on again, the screen
resolution is reset to a maximum of 1368x768 (before: 1920x1200), which messes
up the desktop.

The reason is that when the monitor is turned off, this seems to be sensed as a
change in the HMDI connection, and the EDID data is now coming from the AV
receiver. 

dmesg says:

[   82.689994] [drm] VSX-330: [Block 0] 
[   82.689995] [drm] VSX-330: [Block 1] 
[   82.689997] [drm] dc_link_detect: manufacturer_id = 2F41, product_id = 1027,
serial_number = 1010101, manufacture_week = 0, manufacture_year = 25,
display_name = VSX-330, speaker_flag = 79, audio_mode_count = 8
[   82.689998] [drm] dc_link_detect: mode number = 0, format_code = 1,
channel_count = 1, sample_rate = 127, sample_size = 7
[   82.68] [drm] dc_link_detect: mode number = 1, format_code = 1,
channel_count = 7, sample_rate = 127, sample_size = 7
[   82.69] [drm] dc_link_detect: mode number = 2, format_code = 2,
channel_count = 5, sample_rate = 7, sample_size = 80
[   82.69] [drm] dc_link_detect: mode number = 3, format_code = 7,
channel_count = 6, sample_rate = 6, sample_size = 192
[   82.690001] [drm] dc_link_detect: mode number = 4, format_code = 9,
channel_count = 1, sample_rate = 127, sample_size = 0
[   82.690002] [drm] dc_link_detect: mode number = 5, format_code = 10,
channel_count = 7, sample_rate = 6, sample_size = 0
[   82.690002] [drm] dc_link_detect: mode number = 6, format_code = 11,
channel_count = 7, sample_rate = 126, sample_size = 1
[   82.690003] [drm] dc_link_detect: mode number = 7, format_code = 12,
channel_count = 7, sample_rate = 126, sample_size = 0
[   82.691002] Raw EDID:
[   82.691003]  c8 01 00 00 06 00 00 00 20 00 00 00 02 00 00 00
[   82.691003]  80 07 00 00 b0 04 00 00 01 00 0a 00 fc 05 e0 01
[   82.691004]  e0 04 00 00 00 00 00 00 01 00 01 00 00 00 02 00
[   82.691004]  00 00 00 00 00 0a 00 00 01 00 00 00 70 00 00 00
[   82.691004]  08 00 02 00 fc 05 e0 01 12 00 07 00 fc 05 e0 01
[   82.691005]  9b 01 00 00 04 00 00 00 20 00 00 00 01 00 00 00
[   82.691005]  04 00 00 00 01 00 0a 00 fd 05 e0 01 e0 04 00 00
[   82.691006]  00 00 00 00 1e 00 1e 00 00 00 02 00 00 00 00 00
[   82.691007] amdgpu :01:00.0: HDMI-A-2: EDID invalid.

Note that the monitor is typically labeled as HDMI-A-1.

The screen configuration in KDE lists 1368x768 as the maximum resolution now. 

I managed to restore the old resolution either by rebooting, or by turning off
the AV receiver, then turning it back on. Still, the desktop is messed up.

-- 
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] drm/bridge/synopsys: dsi: Add 1.31 version support

[Archit]

Hi Phillipe,

On Saturday 03 February 2018 03:49 AM, Philippe CORNU wrote:

Hi Archit, Andrzej, Laurent & Brian,

What is your opinion regarding this patch? Do you have any advice for
handling hw versions?

Do not hesitate to comment.


The patch looks mostly good to me. One query below.



Many thanks,
Philippe :-)


On 01/22/2018 04:08 PM, Philippe Cornu wrote:

From: Philippe CORNU 

Add support for the Synopsys DesignWare MIPI DSI version 1.31
Two registers need to be updated/added for supporting 1.31:
* PHY_TMR_CFG 0x9c (updated)
1.30 [31:24] phy_hs2lp_time
 [23:16] phy_lp2hs_time
 [14: 0] max_rd_time

1.31 [25:16] phy_hs2lp_time
 [ 9: 0] phy_lp2hs_time

* PHY_TMR_RD_CFG 0xf4 (new)
1.31 [14: 0] max_rd_time

Signed-off-by: Philippe Cornu 
---
   drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 52 
+++
   1 file changed, 46 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
index 735f38429c06..20a2ca14a7ad 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
@@ -25,7 +25,13 @@
   #include 
   #include 
   
+#define HWVER_130			0x31333000	/* IP version 1.30 */

+#define HWVER_131  0x31333100  /* IP version 1.31 */
+#define HWVER_OLDEST   HWVER_130
+#define HWVER_NEWEST   HWVER_131
+
   #define DSI_VERSION  0x00
+#define VERSIONGENMASK(31, 8)
   
   #define DSI_PWR_UP			0x04

   #define RESET0
@@ -161,11 +167,12 @@
   #define PHY_CLKHS2LP_TIME(lbcc)  (((lbcc) & 0x3ff) << 16)
   #define PHY_CLKLP2HS_TIME(lbcc)  ((lbcc) & 0x3ff)
   
-/* TODO Next register is slightly different between 1.30 & 1.31 IP version */

   #define DSI_PHY_TMR_CFG  0x9c
-#define PHY_HS2LP_TIME(lbcc)   (((lbcc) & 0xff) << 24)
-#define PHY_LP2HS_TIME(lbcc)   (((lbcc) & 0xff) << 16)
-#define MAX_RD_TIME(lbcc)  ((lbcc) & 0x7fff)
+#define PHY_HS2LP_TIME_V130(lbcc)  (((lbcc) & 0xff) << 24)
+#define PHY_LP2HS_TIME_V130(lbcc)  (((lbcc) & 0xff) << 16)
+#define MAX_RD_TIME_V130(lbcc) ((lbcc) & 0x7fff)
+#define PHY_HS2LP_TIME_V131(lbcc)  (((lbcc) & 0x3ff) << 16)
+#define PHY_LP2HS_TIME_V131(lbcc)  ((lbcc) & 0x3ff)
   
   #define DSI_PHY_RSTZ			0xa0

   #define PHY_DISFORCEPLL  0
@@ -204,7 +211,9 @@
   #define DSI_INT_ST1  0xc0
   #define DSI_INT_MSK0 0xc4
   #define DSI_INT_MSK1 0xc8
+
   #define DSI_PHY_TMR_RD_CFG   0xf4
+#define MAX_RD_TIME_V131(lbcc) ((lbcc) & 0x7fff)
   
   #define PHY_STATUS_TIMEOUT_US		1

   #define CMD_PKT_STATUS_TIMEOUT_US2
@@ -215,6 +224,7 @@ struct dw_mipi_dsi {
struct drm_bridge *panel_bridge;
struct device *dev;
void __iomem *base;
+   u32 hw_version;
   
   	struct clk *pclk;

struct clk *px_clk;
@@ -616,8 +626,14 @@ static void dw_mipi_dsi_dphy_timing_config(struct 
dw_mipi_dsi *dsi)
 * note: DSI_PHY_TMR_CFG.MAX_RD_TIME should be in line with
 * DSI_CMD_MODE_CFG.MAX_RD_PKT_SIZE_LP (see CMD_MODE_ALL_LP)
 */
-   dsi_write(dsi, DSI_PHY_TMR_CFG, PHY_HS2LP_TIME(0x40)
- | PHY_LP2HS_TIME(0x40) | MAX_RD_TIME(1));
+   if (dsi->hw_version == HWVER_131) {
+   dsi_write(dsi, DSI_PHY_TMR_CFG, PHY_HS2LP_TIME_V131(0x40) |
+ PHY_LP2HS_TIME_V131(0x40));
+   dsi_write(dsi, DSI_PHY_TMR_RD_CFG, MAX_RD_TIME_V131(1));
+   } else {
+   dsi_write(dsi, DSI_PHY_TMR_CFG, PHY_HS2LP_TIME_V130(0x40) |
+ PHY_LP2HS_TIME_V130(0x40) | MAX_RD_TIME_V130(1));
+   }
   
   	dsi_write(dsi, DSI_PHY_TMR_LPCLK_CFG, PHY_CLKHS2LP_TIME(0x40)

  | PHY_CLKLP2HS_TIME(0x40));
@@ -791,6 +807,28 @@ static const struct drm_bridge_funcs 
dw_mipi_dsi_bridge_funcs = {
.attach   = dw_mipi_dsi_bridge_attach,
   };
   
+static void dsi_get_version(struct dw_mipi_dsi *dsi)

+{
+   u32 hw_version;
+
+   clk_prepare_enable(dsi->pclk);
+   hw_version = dsi_read(dsi, DSI_VERSION) & VERSION;
+   clk_disable_unprepare(dsi->pclk);
+
+   if (hw_version > HWVER_NEWEST) {
+   DRM_DEBUG("hw version: use 0x%08x for this recent 0x%08x\n",
+ HWVER_NEWEST, hw_version);
+   hw_version = HWVER_NEWEST;
+
+   } else if (hw_version < HWVER_OLDEST) {
+   DRM_DEBUG("hw version: use 0x%08x for this old 0x%08x\n",
+ HWVER_OLDEST, hw_version);
+   hw_version = HWVER_OLDEST;


I didn't understand the point of HWVER_NEWEST and HWVWER_OLDEST. We're
not going to have a huge number of hw versions that 

[Bug 96906] OpenCL program causes steady stream of GPU fault detected errors

[bugzilla-daemon]

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

--- Comment #8 from Rafael Ristovski  ---
I'm getting the same output when running vertminer with amdgpu + OpenCL lib
from amdgpu-pro ("Unsupported" setup as mixing binary with open source amdgpu).
I believe the issue is in the kernel driver, as that's the common link between
all these setups.

>[ 1228.836110] amdgpu :03:00.0: GPU fault detected: 147 0x09460402
>[ 1228.836110] amdgpu :03:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   
>0x001F0B43
>[ 1228.836111] amdgpu :03:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 
>0x06008002
>[ 1228.836112] amdgpu :03:00.0: VM fault (0x02, vmid 3) at page 2034499, 
>read from '' (0x) (8)
>[ 1228.836122] amdgpu :03:00.0: GPU fault detected: 147 0x0fe60402
>[ 1228.836123] amdgpu :03:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   
>0x
>[ 1228.836123] amdgpu :03:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 
>0x06008002
>[ 1228.836124] amdgpu :03:00.0: VM fault (0x02, vmid 3) at page 0, read 
>from '' (0x) (8)

-- 
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 104345] Playing video hangs X-Server with showing scrambled picture, sound still playing.

[bugzilla-daemon]

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

--- Comment #9 from bernhardu  ---
This time with latest firmware, with "rcu_nocbs=0-16" for #196683
Happened without any hibernation cycle.
Just the "GPU fault detected: 146" appeared, no "blocked for more than"
message.

Somehow it looks like when this "GPU fault" happens some locks are
never unlocked and therefore blocking the X server.
At least the possibility for a clean shutdown would be good.

Is there any other information I should collect next time, any other
configuration or version I can test?

-- 
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 104345] Playing video hangs X-Server with showing scrambled picture, sound still playing.

[bugzilla-daemon]

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

--- Comment #8 from bernhardu  ---
Created attachment 137162
  --> https://bugs.freedesktop.org/attachment.cgi?id=137162=edit
video output with the chess board like pattern

-- 
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 104345] Playing video hangs X-Server with showing scrambled picture, sound still playing.

[bugzilla-daemon]

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

--- Comment #7 from bernhardu  ---
Created attachment 137161
  --> https://bugs.freedesktop.org/attachment.cgi?id=137161=edit
kernel output captured from the serial line. (4.14.14 vanilla with debian
config)

-- 
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] drm/amdgpu/display: fix wrong enum type for ddc_result

[kbuild test robot]

Hi Dominik,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.15]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/dbehr-chromium-org/drm-amdgpu-display-fix-wrong-enum-type-for-ddc_result/20180204-073608
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


vim +1945 drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c

4562236b3b Harry Wentland 2017-09-12  1924  
d0778ebfd5 Harry Wentland 2017-07-22  1925  bool 
dc_link_handle_hpd_rx_irq(struct dc_link *link, union hpd_irq_data 
*out_hpd_irq_dpcd_data)
4562236b3b Harry Wentland 2017-09-12  1926  {
4562236b3b Harry Wentland 2017-09-12  1927  union hpd_irq_data 
hpd_irq_dpcd_data = 0;
c2e218dda0 Harry Wentland 2017-02-24  1928  union device_service_irq 
device_service_clear = { { 0 } };
4935e2b954 Dominik Behr   2018-02-01  1929  enum ddc_result result = 
DDC_RESULT_UNKNOWN;
4562236b3b Harry Wentland 2017-09-12  1930  bool status = false;
4562236b3b Harry Wentland 2017-09-12  1931  /* For use cases related to 
down stream connection status change,
4562236b3b Harry Wentland 2017-09-12  1932   * PSR and device auto test, 
refer to function handle_sst_hpd_irq
4562236b3b Harry Wentland 2017-09-12  1933   * in DAL2.1*/
4562236b3b Harry Wentland 2017-09-12  1934  
4562236b3b Harry Wentland 2017-09-12  1935  
dm_logger_write(link->ctx->logger, LOG_HW_HPD_IRQ,
4562236b3b Harry Wentland 2017-09-12  1936  "%s: Got short pulse 
HPD on link %d\n",
d0778ebfd5 Harry Wentland 2017-07-22  1937  __func__, 
link->link_index);
4562236b3b Harry Wentland 2017-09-12  1938  
8ee65d7c93 Wenjing Liu2017-07-19  1939  
4562236b3b Harry Wentland 2017-09-12  1940   /* All the 
"handle_hpd_irq_xxx()" methods
4562236b3b Harry Wentland 2017-09-12  1941   * should be called 
only after
4562236b3b Harry Wentland 2017-09-12  1942   * 
dal_dpsst_ls_read_hpd_irq_data
4562236b3b Harry Wentland 2017-09-12  1943   * Order of calls is 
important too
4562236b3b Harry Wentland 2017-09-12  1944   */
4562236b3b Harry Wentland 2017-09-12 @1945  result = 
read_hpd_rx_irq_data(link, _irq_dpcd_data);
8ee65d7c93 Wenjing Liu2017-07-19  1946  if (out_hpd_irq_dpcd_data)
8ee65d7c93 Wenjing Liu2017-07-19  1947  *out_hpd_irq_dpcd_data 
= hpd_irq_dpcd_data;
4562236b3b Harry Wentland 2017-09-12  1948  
4935e2b954 Dominik Behr   2018-02-01  1949  if (result != 
DDC_RESULT_SUCCESSFUL) {
4562236b3b Harry Wentland 2017-09-12  1950  
dm_logger_write(link->ctx->logger, LOG_HW_HPD_IRQ,
4562236b3b Harry Wentland 2017-09-12  1951  "%s: DPCD read 
failed to obtain irq data\n",
4562236b3b Harry Wentland 2017-09-12  1952  __func__);
4562236b3b Harry Wentland 2017-09-12  1953  return false;
4562236b3b Harry Wentland 2017-09-12  1954  }
4562236b3b Harry Wentland 2017-09-12  1955  
4562236b3b Harry Wentland 2017-09-12  1956  if 
(hpd_irq_dpcd_data.bytes.device_service_irq.bits.AUTOMATED_TEST) {
4562236b3b Harry Wentland 2017-09-12  1957  
device_service_clear.bits.AUTOMATED_TEST = 1;
4562236b3b Harry Wentland 2017-09-12  1958  core_link_write_dpcd(
4562236b3b Harry Wentland 2017-09-12  1959  link,
3a340294f7 Dave Airlie2016-12-13  1960  
DP_DEVICE_SERVICE_IRQ_VECTOR,
4562236b3b Harry Wentland 2017-09-12  1961  
_service_clear.raw,
4562236b3b Harry Wentland 2017-09-12  1962  
sizeof(device_service_clear.raw));
4562236b3b Harry Wentland 2017-09-12  1963  
device_service_clear.raw = 0;
4562236b3b Harry Wentland 2017-09-12  1964  
handle_automated_test(link);
4562236b3b Harry Wentland 2017-09-12  1965  return false;
4562236b3b Harry Wentland 2017-09-12  1966  }
4562236b3b Harry Wentland 2017-09-12  1967  
4562236b3b Harry Wentland 2017-09-12  1968  if (!allow_hpd_rx_irq(link)) {
4562236b3b Harry Wentland 2017-09-12  1969  
dm_logger_write(link->ctx->logger, LOG_HW_HPD_IRQ,
4562236b3b Harry Wentland 2017-09-12  1970  "%s: skipping 
HPD handling on %d\n",
d0778ebfd5 Harry Wentland 2017-07-22  1971  __func__, 
link->link_index);
4562236b3b Harry Wentland 2017-09-12  1972  return false;
4562236b3b Harry Wentland 2017-09-12  1973  }
4562236b3b Harry Wentland 2017-09-12  1974  
4562236b3b Harry Wentland 2017-09-12  1975  if 
(handle_hpd_irq_psr_sink(link))
4562236b3b Harry Wentland 2017-09-12  1976  /*