[RFC PATCH linus] drm/nouveau/kms: nouveau_hdmimhz can be static

[kbuild test robot]

Signed-off-by: Fengguang Wu 
---
 nouveau_connector.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index ae96ebc..b845482 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -60,7 +60,7 @@ int nouveau_duallink = 1;
 module_param_named(duallink, nouveau_duallink, int, 0400);

 MODULE_PARM_DESC(hdmimhz, "Force a maximum HDMI pixel clock (in MHz)");
-int nouveau_hdmimhz = 0;
+static int nouveau_hdmimhz = 0;
 module_param_named(hdmimhz, nouveau_hdmimhz, int, 0400);

 struct nouveau_encoder *

drivers/gpu/drm/nouveau/nouveau_connector.c:60:5: sparse: symbol 'nouveau_hdmimhz' was not declared. Should it be static?

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   6b5f04b6cf8ebab9a65d9c0026c650bb2538fd0f
commit: 1a0c96c075bb4517d4ce4fb6750ee0a3cf38714c drm/nouveau/kms: allow 
225/297MHz pixel clocks for HDMI on Fermi/Kepler
date:   10 weeks ago
reproduce:
# apt-get install sparse
git checkout 1a0c96c075bb4517d4ce4fb6750ee0a3cf38714c
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/nouveau/nouveau_connector.c:60:5: sparse: symbol 
>> 'nouveau_hdmimhz' was not declared. Should it be static?
   drivers/gpu/drm/nouveau/nouveau_connector.c:1081:29: sparse: cast to 
restricted __le16
   drivers/gpu/drm/nouveau/nouveau_connector.c:1083:39: sparse: cast to 
restricted __le16

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

[PATCH] drm/radeon: evergreen_hpd_init()/_fini(): fix HPD IRQ bitset

[Nicolai Stange]

The values of all but the RADEON_HPD_NONE members of the radeon_hpd_id
enum transform 1:1 into bit positions within the 'enabled' bitset as
assembled by evergreen_hpd_init():

  enabled |= 1 << radeon_connector->hpd.hpd;

However, if ->hpd.hpd happens to equal RADEON_HPD_NONE == 0xff, UBSAN
reports

  UBSAN: Undefined behaviour in drivers/gpu/drm/radeon/evergreen.c:1867:16
  shift exponent 255 is too large for 32-bit type 'int'
  [...]
  Call Trace:
   [] dump_stack+0xbc/0x117
   [] ? _atomic_dec_and_lock+0x169/0x169
   [] ubsan_epilogue+0xd/0x4e
   [] __ubsan_handle_shift_out_of_bounds+0x1fb/0x254
   [] ? atom_execute_table+0x3e/0x50 [radeon]
   [] ? __ubsan_handle_load_invalid_value+0x158/0x158
   [] ? radeon_get_pll_use_mask+0x130/0x130 [radeon]
   [] ? wake_up_klogd_work_func+0x60/0x60
   [] ? vprintk_default+0x3e/0x60
   [] evergreen_hpd_init+0x274/0x2d0 [radeon]
   [] ? evergreen_hpd_init+0x274/0x2d0 [radeon]
   [] radeon_modeset_init+0x8ce/0x18d0 [radeon]
   [] radeon_driver_load_kms+0x186/0x350 [radeon]
   [] drm_dev_register+0xc6/0x100 [drm]
   [] drm_get_pci_dev+0xe4/0x490 [drm]
   [] ? kfree+0x220/0x370
   [] radeon_pci_probe+0x112/0x140 [radeon]
   [...]
  =
  radeon :01:00.0: No connectors reported connected with modes

The net effect is that radeon_irq_kms_enable_hpd() enables the HPD
interrupts for all HPD pins in the range from 0 to RADEON_MAX_HPD_PINS.
The system seems to work without any noticeable glitches though.

All of the above applies analogously to evergreen_hpd_fini().

Silence UBSAN by checking ->hpd.hpd for RADEON_HPD_NONE before oring it
into the 'enabled' bitset in evergreen_hpd_init() or the 'disabled' bitset
in evergreen_hpd_fini() respectively.

Signed-off-by: Nicolai Stange 
---
 Applicable to linux-next-20160318.

 drivers/gpu/drm/radeon/evergreen.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index 76c4bdf..6360717 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1864,7 +1864,8 @@ void evergreen_hpd_init(struct radeon_device *rdev)
break;
}
radeon_hpd_set_polarity(rdev, radeon_connector->hpd.hpd);
-   enabled |= 1 << radeon_connector->hpd.hpd;
+   if (radeon_connector->hpd.hpd != RADEON_HPD_NONE)
+   enabled |= 1 << radeon_connector->hpd.hpd;
}
radeon_irq_kms_enable_hpd(rdev, enabled);
 }
@@ -1907,7 +1908,8 @@ void evergreen_hpd_fini(struct radeon_device *rdev)
default:
break;
}
-   disabled |= 1 << radeon_connector->hpd.hpd;
+   if (radeon_connector->hpd.hpd != RADEON_HPD_NONE)
+   disabled |= 1 << radeon_connector->hpd.hpd;
}
radeon_irq_kms_disable_hpd(rdev, disabled);
 }
-- 
2.7.3

[Bug 80419] XCOM: Enemy Unknown Causes lockup

[bugzilla-dae...@freedesktop.org]

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

--- Comment #122 from Daniel Exner <dex+fdobugzilla at dragonslave.de> ---
Tested again, same setup as before: crashed after 5 Minutes.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160319/6b2b3163/attachment.html>

[PATCH] fence: add missing descriptions for fence

[Javier Martinez Canillas]

Hello Luis,

On Sat, Mar 19, 2016 at 4:50 PM, Luis de Bethencourt
 wrote:
> Commit b55b54b5db33 ("staging/android: remove struct sync_pt")
> added the members child_list and active_list to the fence struct, but
> didn't add descriptions for these. Adding the descriptions.
>

Patches whose commit message mentions a specific commit that
introduced and issue, usually also have a "Fixes:" tag before the
S-o-B. For example this patch should have:

Fixes: b55b54b5db33 ("staging/android: remove struct sync_pt")
> Signed-off-by: Luis de Bethencourt 
> ---
> Hi,
>
> Noticed this missing descriptions when running make htmldocs.
>
> Got the following warnings:
> .//include/linux/fence.h:84: warning: No description found for parameter 
> 'child_list'
> .//include/linux/fence.h:84: warning: No description found for parameter 
> 'active_list'
>
> Thanks :)
> Luis
>

Patch looks good to me.

Reviewed-by: Javier Martinez Canillas 

Best regards,
Javier

[PATCH] fence: add missing descriptions for fence

[Luis de Bethencourt]

Commit b55b54b5db33 ("staging/android: remove struct sync_pt")
added the members child_list and active_list to the fence struct, but
didn't add descriptions for these. Adding the descriptions.

Signed-off-by: Luis de Bethencourt 
---
Hi,

Noticed this missing descriptions when running make htmldocs.

Got the following warnings:
.//include/linux/fence.h:84: warning: No description found for parameter 
'child_list'
.//include/linux/fence.h:84: warning: No description found for parameter 
'active_list'

Thanks :)
Luis

 include/linux/fence.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/fence.h b/include/linux/fence.h
index 2b17698..2056e9f 100644
--- a/include/linux/fence.h
+++ b/include/linux/fence.h
@@ -49,6 +49,8 @@ struct fence_cb;
  * @timestamp: Timestamp when the fence was signaled.
  * @status: Optional, only valid if < 0, must be set before calling
  * fence_signal, indicates that the fence has completed with an error.
+ * @child_list: list of children fences
+ * @active_list: list of active fences
  *
  * the flags member must be manipulated and read using the appropriate
  * atomic ops (bit_*), so taking the spinlock will not be needed most
-- 
2.5.1

[Bug 94581] Red flood in dmesg when running applications

[bugzilla-dae...@freedesktop.org]

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

Vladislav Kamenev  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=34643

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160319/eb5785c4/attachment.html>

[Bug 34643] ut2004/doom3 looping in submenu on r300g/PageFlip

[bugzilla-dae...@freedesktop.org]

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

Vladislav Kamenev  changed:

   What|Removed |Added

   See Also||https://bugs.freedesktop.or
   ||g/show_bug.cgi?id=94581

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160319/60f7ae58/attachment.html>

[PATCH] drm: remove excess description

[Luis de Bethencourt]

Description of expected_size doesn't match any parameter of the function
drm_atomic_replace_property_blob. Removing it.

Signed-off-by: Luis de Bethencourt 
---
Hi,

I noticed this while running make htmldocs. It gives the following warning:
.//drivers/gpu/drm/drm_atomic.c:393: warning: Excess function parameter 
'expected_size' description in 'drm_atomic_replace_property_blob'

Thanks,
Luis

 drivers/gpu/drm/drm_atomic.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index a2596eb..8ee1db8 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -380,7 +380,6 @@ EXPORT_SYMBOL(drm_atomic_set_mode_prop_for_crtc);
  * drm_atomic_replace_property_blob - replace a blob property
  * @blob: a pointer to the member blob to be replaced
  * @new_blob: the new blob to replace with
- * @expected_size: the expected size of the new blob
  * @replaced: whether the blob has been replaced
  *
  * RETURNS:
-- 
2.5.1

[PATCH 7/7] drm/amdgpu: mark amdgpu_allowed_register_entry tables as 'const'

[Nils Wallménius]

Signed-off-by: Nils Wallménius 
---
 drivers/gpu/drm/amd/amdgpu/cik.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/vi.c  | 10 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/cik.c b/drivers/gpu/drm/amd/amdgpu/cik.c
index 5da14a3..9152e71 100644
--- a/drivers/gpu/drm/amd/amdgpu/cik.c
+++ b/drivers/gpu/drm/amd/amdgpu/cik.c
@@ -962,7 +962,7 @@ static bool cik_read_bios_from_rom(struct amdgpu_device 
*adev,
return true;
 }

-static struct amdgpu_allowed_register_entry cik_allowed_read_registers[] = {
+static const struct amdgpu_allowed_register_entry cik_allowed_read_registers[] 
= {
{mmGRBM_STATUS, false},
{mmGB_ADDR_CONFIG, false},
{mmMC_ARB_RAMCFG, false},
diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index 9163f59..e1bee10 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -414,11 +414,11 @@ static bool vi_read_bios_from_rom(struct amdgpu_device 
*adev,
return true;
 }

-static struct amdgpu_allowed_register_entry tonga_allowed_read_registers[] = {
+static const struct amdgpu_allowed_register_entry 
tonga_allowed_read_registers[] = {
{mmGB_MACROTILE_MODE7, true},
 };

-static struct amdgpu_allowed_register_entry cz_allowed_read_registers[] = {
+static const struct amdgpu_allowed_register_entry cz_allowed_read_registers[] 
= {
{mmGB_TILE_MODE7, true},
{mmGB_TILE_MODE12, true},
{mmGB_TILE_MODE17, true},
@@ -426,7 +426,7 @@ static struct amdgpu_allowed_register_entry 
cz_allowed_read_registers[] = {
{mmGB_MACROTILE_MODE7, true},
 };

-static struct amdgpu_allowed_register_entry vi_allowed_read_registers[] = {
+static const struct amdgpu_allowed_register_entry vi_allowed_read_registers[] 
= {
{mmGRBM_STATUS, false},
{mmGRBM_STATUS2, false},
{mmGRBM_STATUS_SE0, false},
@@ -525,8 +525,8 @@ static uint32_t vi_read_indexed_register(struct 
amdgpu_device *adev, u32 se_num,
 static int vi_read_register(struct amdgpu_device *adev, u32 se_num,
u32 sh_num, u32 reg_offset, u32 *value)
 {
-   struct amdgpu_allowed_register_entry *asic_register_table = NULL;
-   struct amdgpu_allowed_register_entry *asic_register_entry;
+   const struct amdgpu_allowed_register_entry *asic_register_table = NULL;
+   const struct amdgpu_allowed_register_entry *asic_register_entry;
uint32_t size, i;

*value = 0;
-- 
2.7.0

[PATCH 6/7] drm/radeon: delete unused member from struct radeon_pll

[Nils Wallménius]

Signed-off-by: Nils Wallménius 
---
 drivers/gpu/drm/radeon/radeon_mode.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_mode.h 
b/drivers/gpu/drm/radeon/radeon_mode.h
index bb75201a..b0060f4 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -191,9 +191,6 @@ struct radeon_pll {

/* flags for the current clock */
uint32_t flags;
-
-   /* pll id */
-   uint32_t id;
 };

 struct radeon_i2c_chan {
-- 
2.7.0

[PATCH 5/7] drm/amdgpu: delete unused members from struct amdgpu_pll

[Nils Wallménius]

Clean up some set-but-not-read members and one unused member.

Signed-off-by: Nils Wallménius 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 5 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 6 --
 2 files changed, 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
index 84b0ce3..a2a15b7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c
@@ -599,13 +599,10 @@ int amdgpu_atombios_get_clock_info(struct amdgpu_device 
*adev)

ppll->min_post_div = 2;
ppll->max_post_div = 0x7f;
-   ppll->min_frac_feedback_div = 0;
-   ppll->max_frac_feedback_div = 9;
ppll->min_ref_div = 2;
ppll->max_ref_div = 0x3ff;
ppll->min_feedback_div = 4;
ppll->max_feedback_div = 0xfff;
-   ppll->best_vco = 0;

for (i = 1; i < AMDGPU_MAX_PPLL; i++)
adev->clock.ppll[i] = *ppll;
@@ -635,7 +632,6 @@ int amdgpu_atombios_get_clock_info(struct amdgpu_device 
*adev)
spll->max_ref_div = 0xff;
spll->min_feedback_div = 4;
spll->max_feedback_div = 0xff;
-   spll->best_vco = 0;

/* memory clock */
mpll->reference_freq =
@@ -667,7 +663,6 @@ int amdgpu_atombios_get_clock_info(struct amdgpu_device 
*adev)
mpll->max_ref_div = 0xff;
mpll->min_feedback_div = 4;
mpll->max_feedback_div = 0xff;
-   mpll->best_vco = 0;

/* disp clock */
adev->clock.default_dispclk =
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
index 8d432e6..1dff768 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
@@ -195,7 +195,6 @@ struct amdgpu_pll {
uint32_t pll_out_max;
uint32_t lcd_pll_out_min;
uint32_t lcd_pll_out_max;
-   uint32_t best_vco;

/* divider limits */
uint32_t min_ref_div;
@@ -204,14 +203,9 @@ struct amdgpu_pll {
uint32_t max_post_div;
uint32_t min_feedback_div;
uint32_t max_feedback_div;
-   uint32_t min_frac_feedback_div;
-   uint32_t max_frac_feedback_div;

/* flags for the current clock */
uint32_t flags;
-
-   /* pll id */
-   uint32_t id;
 };

 struct amdgpu_i2c_chan {
-- 
2.7.0

[PATCH 4/7] drm/amdgpu: delete unused sdma_*_emit_fill_buffer functions

[Nils Wallménius]

Signed-off-by: Nils Wallménius 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h| 16 
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c  | 26 --
 drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 26 --
 drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 26 --
 4 files changed, 94 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 4d2c335..739a63d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -255,21 +255,6 @@ struct amdgpu_buffer_funcs {
 uint64_t dst_offset,
 /* number of byte to transfer */
 uint32_t byte_count);
-
-   /* maximum bytes in a single operation */
-   uint32_tfill_max_bytes;
-
-   /* number of dw to reserve per operation */
-   unsignedfill_num_dw;
-
-   /* used for buffer clearing */
-   void (*emit_fill_buffer)(struct amdgpu_ib *ib,
-/* value to write to memory */
-uint32_t src_data,
-/* dst addr in bytes */
-uint64_t dst_offset,
-/* number of byte to fill */
-uint32_t byte_count);
 };

 /* provided by hw blocks that can write ptes, e.g., sdma */
@@ -2239,7 +2224,6 @@ amdgpu_get_sdma_instance(struct amdgpu_ring *ring)
 #define amdgpu_display_stop_mc_access(adev, s) 
(adev)->mode_info.funcs->stop_mc_access((adev), (s))
 #define amdgpu_display_resume_mc_access(adev, s) 
(adev)->mode_info.funcs->resume_mc_access((adev), (s))
 #define amdgpu_emit_copy_buffer(adev, ib, s, d, b) 
(adev)->mman.buffer_funcs->emit_copy_buffer((ib),  (s), (d), (b))
-#define amdgpu_emit_fill_buffer(adev, ib, s, d, b) 
(adev)->mman.buffer_funcs->emit_fill_buffer((ib), (s), (d), (b))
 #define amdgpu_dpm_pre_set_power_state(adev) 
(adev)->pm.funcs->pre_set_power_state((adev))
 #define amdgpu_dpm_set_power_state(adev) 
(adev)->pm.funcs->set_power_state((adev))
 #define amdgpu_dpm_post_set_power_state(adev) 
(adev)->pm.funcs->post_set_power_state((adev))
diff --git a/drivers/gpu/drm/amd/amdgpu/cik_sdma.c 
b/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
index 72543f1..28b1b77 100644
--- a/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
+++ b/drivers/gpu/drm/amd/amdgpu/cik_sdma.c
@@ -1361,36 +1361,10 @@ static void cik_sdma_emit_copy_buffer(struct amdgpu_ib 
*ib,
ib->ptr[ib->length_dw++] = upper_32_bits(dst_offset);
 }

-/**
- * cik_sdma_emit_fill_buffer - fill buffer using the sDMA engine
- *
- * @ring: amdgpu_ring structure holding ring information
- * @src_data: value to write to buffer
- * @dst_offset: dst GPU address
- * @byte_count: number of bytes to xfer
- *
- * Fill GPU buffers using the DMA engine (CIK).
- */
-static void cik_sdma_emit_fill_buffer(struct amdgpu_ib *ib,
- uint32_t src_data,
- uint64_t dst_offset,
- uint32_t byte_count)
-{
-   ib->ptr[ib->length_dw++] = SDMA_PACKET(SDMA_OPCODE_CONSTANT_FILL, 0, 0);
-   ib->ptr[ib->length_dw++] = lower_32_bits(dst_offset);
-   ib->ptr[ib->length_dw++] = upper_32_bits(dst_offset);
-   ib->ptr[ib->length_dw++] = src_data;
-   ib->ptr[ib->length_dw++] = byte_count;
-}
-
 static const struct amdgpu_buffer_funcs cik_sdma_buffer_funcs = {
.copy_max_bytes = 0x1f,
.copy_num_dw = 7,
.emit_copy_buffer = cik_sdma_emit_copy_buffer,
-
-   .fill_max_bytes = 0x1f,
-   .fill_num_dw = 5,
-   .emit_fill_buffer = cik_sdma_emit_fill_buffer,
 };

 static void cik_sdma_set_buffer_funcs(struct amdgpu_device *adev)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
index 6e0a86a..b0b939a 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
@@ -1367,36 +1367,10 @@ static void sdma_v2_4_emit_copy_buffer(struct amdgpu_ib 
*ib,
ib->ptr[ib->length_dw++] = upper_32_bits(dst_offset);
 }

-/**
- * sdma_v2_4_emit_fill_buffer - fill buffer using the sDMA engine
- *
- * @ring: amdgpu_ring structure holding ring information
- * @src_data: value to write to buffer
- * @dst_offset: dst GPU address
- * @byte_count: number of bytes to xfer
- *
- * Fill GPU buffers using the DMA engine (VI).
- */
-static void sdma_v2_4_emit_fill_buffer(struct amdgpu_ib *ib,
-  uint32_t src_data,
-  uint64_t dst_offset,
-  uint32_t byte_count)
-{
-   ib->ptr[ib->length_dw++] = SDMA_PKT_HEADER_OP(SDMA_OP_CONST_FILL);
-   ib->ptr[ib->length_dw++] = lower_32_bits(dst_offset);
-   ib->ptr[ib->length_dw++] = upper_32_bits(dst_offset);
-   ib->ptr[ib->length_dw++] = src_data;
- 

[PATCH 3/7] drm/amdgpu: do not store bios_header_start in amdgpu_device

[Nils Wallménius]

It is only used locally in amdgpu_get_bios

Signed-off-by: Nils Wallménius 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h  | 1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 8 
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 00dade8..4d2c335 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1964,7 +1964,6 @@ struct amdgpu_device {
/* BIOS */
uint8_t *bios;
boolis_atom_bios;
-   uint16_tbios_header_start;
struct amdgpu_bo*stollen_vga_memory;
uint32_tbios_scratch[AMDGPU_BIOS_NUM_SCRATCH];

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
index 80add22..99ca75b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
@@ -349,7 +349,7 @@ static inline bool amdgpu_acpi_vfct_bios(struct 
amdgpu_device *adev)
 bool amdgpu_get_bios(struct amdgpu_device *adev)
 {
bool r;
-   uint16_t tmp;
+   uint16_t tmp, bios_header_start;

r = amdgpu_atrm_get_bios(adev);
if (r == false)
@@ -383,11 +383,11 @@ bool amdgpu_get_bios(struct amdgpu_device *adev)
goto free_bios;
}

-   adev->bios_header_start = RBIOS16(0x48);
-   if (!adev->bios_header_start) {
+   bios_header_start = RBIOS16(0x48);
+   if (!bios_header_start) {
goto free_bios;
}
-   tmp = adev->bios_header_start + 4;
+   tmp = bios_header_start + 4;
if (!memcmp(adev->bios + tmp, "ATOM", 4) ||
!memcmp(adev->bios + tmp, "MOTA", 4)) {
adev->is_atom_bios = true;
-- 
2.7.0

[PATCH 2/7] drm/radeon: delete unused struct member suspend from radeon_device

[Nils Wallménius]

Signed-off-by: Nils Wallménius 
---
 drivers/gpu/drm/radeon/radeon.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 007be29..7bb966d 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2394,7 +2394,6 @@ struct radeon_device {
struct radeon_wbwb;
struct radeon_dummy_pagedummy_page;
boolshutdown;
-   boolsuspend;
boolneed_dma32;
boolaccel_working;
boolfastfb_working; /* IGP feature*/
-- 
2.7.0

[PATCH 1/7] drm/amdgpu: delete unused struct member suspend from amdgpu_device

[Nils Wallménius]

Signed-off-by: Nils Wallménius 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index c28b23c..00dade8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1943,7 +1943,6 @@ struct amdgpu_device {
int usec_timeout;
const struct amdgpu_asic_funcs  *asic_funcs;
boolshutdown;
-   boolsuspend;
boolneed_dma32;
boolaccel_working;
struct work_struct  reset_work;
-- 
2.7.0

[PATCHv13 01/17] dts: exynos4*: add HDMI CEC pin definition to pinctrl

[Krzysztof Kozlowski]

On Fri, Mar 18, 2016 at 03:07:00PM +0100, Hans Verkuil wrote:
> From: Kamil Debski 
> 
> Add pinctrl nodes for the HDMI CEC device to the Exynos4210 and
> Exynos4x12 SoCs. These are required by the HDMI CEC device.
> 
> Signed-off-by: Kamil Debski 
> Signed-off-by: Hans Verkuil 
> Acked-by: Krzysztof Kozlowski 
> ---
>  arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 7 +++
>  arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 7 +++
>  2 files changed, 14 insertions(+)

Hi Hans,

I see you have been carrying these three patches for a long time.
Initially I thought that there are some dependencies... but maybe there
are not?

Can I take these Exynos DTS patches to samsung-soc?

Best regards,
Krzysztof

[PATCH v2 1/9] drm: atmel-hlcdc: add a ->cleanup_fb() operation

[Boris Brezillon]

On Fri, 18 Mar 2016 18:58:48 +0100
Daniel Vetter  wrote:

> On Thu, Mar 17, 2016 at 09:49:42AM +0100, Boris Brezillon wrote:
> > Hi Daniel,
> > 
> > On Wed, 16 Mar 2016 16:17:38 +0100
> > Daniel Vetter  wrote:
> > 
> > > On Wed, Mar 16, 2016 at 02:57:35PM +0100, Boris Brezillon wrote:
> > > > Add a ->cleanup_fb() operation to avoid memory leaks when the atomic
> > > > operation is interrupted after the ->prepare_fb() call.
> > > > 
> > > > Signed-off-by: Boris Brezillon 
> > > > Fixes 2389fc1 ("drm: atmel-hlcdc: Atomic mode-setting conversion")
> > > > Reviewed-by: Nicolas Ferre 
> > > > Tested-by: Nicolas Ferre 
> > > > ---
> > > >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h|  2 ++
> > > >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 22 
> > > > +++---
> > > >  2 files changed, 21 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h 
> > > > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> > > > index fed517f..ec64140 100644
> > > > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> > > > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
> > > > @@ -81,11 +81,13 @@ struct atmel_hlcdc_plane_properties {
> > > >   * @layer: HLCDC layer structure
> > > >   * @properties: pointer to the property definitions structure
> > > >   * @rotation: current rotation status
> > > > + * @prepared: flagging the plane has prepared for an atomic update
> > > >   */
> > > >  struct atmel_hlcdc_plane {
> > > > struct drm_plane base;
> > > > struct atmel_hlcdc_layer layer;
> > > > struct atmel_hlcdc_plane_properties *properties;
> > > > +   bool prepared;
> > > >  };
> > > >  
> > > >  static inline struct atmel_hlcdc_plane *
> > > > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
> > > > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > > > index 1ffe9c3..35027d0 100644
> > > > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > > > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > > > @@ -715,11 +715,25 @@ static int atmel_hlcdc_plane_prepare_fb(struct 
> > > > drm_plane *p,
> > > > const struct drm_plane_state 
> > > > *new_state)
> > > >  {
> > > > struct atmel_hlcdc_plane *plane = 
> > > > drm_plane_to_atmel_hlcdc_plane(p);
> > > > +   int ret;
> > > >  
> > > > -   if (!new_state->fb)
> > > > -   return 0;
> > > > +   ret = atmel_hlcdc_layer_update_start(>layer);
> > > > +   if (!ret)
> > > > +   plane->prepared = true;
> > > 
> > > Atomic helpers will keep track of this for you, and only call ->cleanup_fb
> > > on a plane combo where it did (successfully) call ->prepare_fb.
> > 
> > Hm, it's not exactly encoding the same thing. What I want to do here is
> > call atmel_hlcdc_layer_update_rollback() only if the atomic update has
> > failed (see below, I set ->prepared back to false in the
> > ->atomic_update() method). AFAICT, ->cleanup_fb() is also called
> > when the whole operation succeed (and in this case I don't want to
> > call atmel_hlcdc_layer_update_rollback()).
> > 
> > Let me know if you see a better approach to do that.
> 
> Ah makes sense. And yeah I guess this is the only approach really. Note
> that you should put plane_prepared into plane_state though, in case we
> start to pipeline updates.

Absolutely, I'll move it to the plane state.

Thanks,

Boris


-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH 3/4] drm/radeon: consolidate uvd/vce initialization, resume and suspend.

[Daniel Vetter]

On Sat, Mar 19, 2016 at 10:41:59AM +0100, Daniel Vetter wrote:
> On Fri, Mar 18, 2016 at 09:16:08AM +0100, Daniel Vetter wrote:
> > On Fri, Mar 18, 2016 at 01:00:26PM +0900, Michel Dänzer wrote:
> > > On 17.03.2016 16:36, Daniel Vetter wrote:
> > > > On Thu, Mar 17, 2016 at 06:41:14AM +1000, Dave Airlie wrote:
> > > >> Just an aside,
> > > >>
> > > >> So is there no way to do hibernate with these blocks?
> > > >>
> > > >> Like can you not cleanly shut them down without doing a power cycle.
> > > >>
> > > >> I have to say UVD is a real pain in the ass from a stability pov, I'd
> > > >> kinda wished I'd enforced AMD creating something like intel-gpu-tools
> > > >> and having tests to make sure GPU reset etc stayed working before
> > > >> merging it.
> > > > 
> > > > igt already supports running on any kind of drm device, and it has a 
> > > > bunch
> > > > of vc4 specific testcases on top. If anyone finds offence in the "intel"
> > > > part, we can rename it to igt gpu tools/tests ;-)
> > > 
> > > Any tips for running the tests on non-Intel GPUs? I tried piglit igt.py,
> > > but it was generating tens of thousands of failures from tests which
> > > look Intel specific.
> > 
> > Yeah Chris again broke the SKIP logic in gem_concurrent_blt/all testcases.
> > Just explicitly exclude those with -x gem_concurrent. The problem is that
> > hw/kernel feature checks aren't properlty encapsulated in the right
> > igt_fixture or igt_subtest blocks, so it falls over. Specifically the
> > access_mode->require() test is only protetected by
> > igt_only_list_subtests(), which is the wrong way to do it.
> > 
> > Adding Chris.
> 
> Ok, fixed pushed now using the just added igt_subtest_group blocks. Please
> scream when anything else falls apart.

Ok, just realized that Chris' combinatorial stress-test crusade reached a
few 100k tests now ;-) So just run with -x gem_ to get rid of all the i915
gem stuff. If we get more along the lines of vc4, we probably need to give
them all a i915_ prefix. Same for the i915 ioctl wrappers probably.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 94512] X segfaults with glx-tls enabled in a x32 environment

[bugzilla-dae...@freedesktop.org]

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

EoD  changed:

   What|Removed |Added

Summary|X segfaults on launching in |X segfaults with glx-tls
   |x32 environment |enabled in a x32
   ||environment

--- Comment #3 from EoD  ---
This segfault is not restricted to starting X, but also happen with glxgears
and glxinfo in a multilib environment.


I also figured out those segfaults only happen if glx-tls is enabled. If
glx-tls is disabled X, glxinfo and glxgears work fine again.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160319/e1ac38ce/attachment-0001.html>

[Bug 94623] [AMDGPU][CIK][bisected] drm/amdgpu: apply gfx_v8 fixes to gfx_v7 as well

[bugzilla-dae...@freedesktop.org]

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

Bug ID: 94623
   Summary: [AMDGPU][CIK][bisected] drm/amdgpu: apply gfx_v8 fixes
to gfx_v7 as well
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: shawn.starr at rogers.com

The following commit cause GPU lockup on CIK when starting X:

feebe91aa9a9d99d9ec157612a614fadb79beb99 is the first bad commit
commit feebe91aa9a9d99d9ec157612a614fadb79beb99
Author: Christian K�nig 
Date:   Fri Feb 26 16:18:15 2016 +0100

drm/amdgpu: apply gfx_v8 fixes to gfx_v7 as well

We never ported that back to CIK, so we could run into VM faults here.

Signed-off-by: Christian K�nig 
Reviewed-by: Alex Deucher 
Cc: stable at vger.kernel.org

:04 04 1229f0ca17d5518c15d64c773303dd494b3c74a8
d31a4da20d5bec8c9a59608b86a928bd06e4cd0b M  drivers


When reverting this patch on kernel 4.5 final and Fedora's 4.6-rc0.git sources,
no GPU lockup happens anymore.


Bisect history (Starting from 4.5-rc5):

git bisect start
# good: [81f70ba233d5f660e1ea5fe23260ee323af5d53a] Linux 4.5-rc5
git bisect good 81f70ba233d5f660e1ea5fe23260ee323af5d53a
# bad: [710d60cbf1b312a8075a2158cbfbbd9c66132dcc] Merge branch
'smp-hotplug-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 710d60cbf1b312a8075a2158cbfbbd9c66132dcc
# bad: [7ae9c768e19ec8ce1b397a5c4abf88f9ee053e09] Merge tag 'pm+acpi-4.5-final'
of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect bad 7ae9c768e19ec8ce1b397a5c4abf88f9ee053e09
# good: [f691b77b1fc491dae601631c8531a0a13e915466] Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
git bisect good f691b77b1fc491dae601631c8531a0a13e915466
# bad: [848819c5447eb318a787467e8435a07c733e16c9] Merge tag
'imx-drm-fixes-2016-02-19' of git://git.pengutronix.de/git/pza/linux into
drm-fixes
git bisect bad 848819c5447eb318a787467e8435a07c733e16c9
# bad: [e5322c54068162846fdbac0f0891cd95f37d4c4e] Merge branch 'for-linus2' of
git://git.kernel.dk/linux-block
git bisect bad e5322c54068162846fdbac0f0891cd95f37d4c4e
# good: [da35825d9a091a7a1d5824c8468168e2658333ff] nvme: set queue limits for
the admin queue
git bisect good da35825d9a091a7a1d5824c8468168e2658333ff
# bad: [26bae5e04c3570728787f809b13546a8169fdf95] Merge tag
'drm/tegra/for-4.5-rc7' of git://anongit.freedesktop.org/tegra/linux into
drm-fixes
git bisect bad 26bae5e04c3570728787f809b13546a8169fdf95
# bad: [89913ea615754163ae9a066c9c1b95aa2a2f51b4] drm/amdgpu/cz: remove
commented out call to enable vce pg
git bisect bad 89913ea615754163ae9a066c9c1b95aa2a2f51b4
# good: [4ea2efae0d117c5b5f44081bab941542d892e758] drm/amd/powerplay: send
event to notify powerplay all modules are initialized.
git bisect good 4ea2efae0d117c5b5f44081bab941542d892e758
# bad: [9cac537332f5502c103415b25609548c276a09f8] drm/amdgpu/gfx8: specify
which engine to wait before vm flush
git bisect bad 9cac537332f5502c103415b25609548c276a09f8
# bad: [feebe91aa9a9d99d9ec157612a614fadb79beb99] drm/amdgpu: apply gfx_v8
fixes to gfx_v7 as well
git bisect bad feebe91aa9a9d99d9ec157612a614fadb79beb99
# first bad commit: [feebe91aa9a9d99d9ec157612a614fadb79beb99] drm/amdgpu:
apply gfx_v8 fixes to gfx_v7 as well

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160319/b2acc7da/attachment.html>

[PATCH] dma-buf, drm, ion: Propagate error code from dma_buf_start_cpu_access()

[Daniel Vetter]

On Fri, Mar 18, 2016 at 08:02:39PM +, Chris Wilson wrote:
> Drivers, especially i915.ko, can fail during the initial migration of a
> dma-buf for CPU access. However, the error code from the driver was not
> being propagated back to ioctl and so userspace was blissfully ignorant
> of the failure. Rendering corruption ensues.
> 
> Whilst fixing the ioctl to return the error code from
> dma_buf_start_cpu_access(), also do the same for
> dma_buf_end_cpu_access().  For most drivers, dma_buf_end_cpu_access()
> cannot fail. i915.ko however, as most drivers would, wants to avoid being
> uninterruptible (as would be required to guarrantee no failure when
> flushing the buffer to the device). As userspace already has to handle
> errors from the SYNC_IOCTL, take advantage of this to be able to restart
> the syscall across signals.
> 
> This fixes a coherency issue for i915.ko as well as reducing the
> uninterruptible hold upon its BKL, the struct_mutex.
> 
> Fixes commit c11e391da2a8fe973c3c2398452000bed505851e
> Author: Daniel Vetter 
> Date:   Thu Feb 11 20:04:51 2016 -0200
> 
> dma-buf: Add ioctls to allow userspace to flush
> 
> Testcase: igt/gem_concurrent_blit/*dmabuf*interruptible
> Testcase: igt/prime_mmap_coherency/ioctl-errors
> Signed-off-by: Chris Wilson 
> Cc: Tiago Vignatti 
> Cc: Stéphane Marchesin 
> Cc: David Herrmann 
> Cc: Sumit Semwal 
> Cc: Daniel Vetter 
> CC: linux-media at vger.kernel.org
> Cc: dri-devel at lists.freedesktop.org
> Cc: linaro-mm-sig at lists.linaro.org
> Cc: intel-gfx at lists.freedesktop.org
> Cc: devel at driverdev.osuosl.org

Applied to drm-misc, I'll send a pull to Dave the next few days if no one
screams.
-Daniel

> ---
>  drivers/dma-buf/dma-buf.c | 17 +++--
>  drivers/gpu/drm/i915/i915_gem_dmabuf.c| 15 +--
>  drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c |  5 +++--
>  drivers/gpu/drm/udl/udl_fb.c  |  4 ++--
>  drivers/staging/android/ion/ion.c |  6 --
>  include/linux/dma-buf.h   |  6 +++---
>  6 files changed, 28 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 9810d1df0691..774a60f4309a 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -259,6 +259,7 @@ static long dma_buf_ioctl(struct file *file,
>   struct dma_buf *dmabuf;
>   struct dma_buf_sync sync;
>   enum dma_data_direction direction;
> + int ret;
>  
>   dmabuf = file->private_data;
>  
> @@ -285,11 +286,11 @@ static long dma_buf_ioctl(struct file *file,
>   }
>  
>   if (sync.flags & DMA_BUF_SYNC_END)
> - dma_buf_end_cpu_access(dmabuf, direction);
> + ret = dma_buf_end_cpu_access(dmabuf, direction);
>   else
> - dma_buf_begin_cpu_access(dmabuf, direction);
> + ret = dma_buf_begin_cpu_access(dmabuf, direction);
>  
> - return 0;
> + return ret;
>   default:
>   return -ENOTTY;
>   }
> @@ -613,13 +614,17 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
>   *
>   * This call must always succeed.
>   */
> -void dma_buf_end_cpu_access(struct dma_buf *dmabuf,
> - enum dma_data_direction direction)
> +int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
> +enum dma_data_direction direction)
>  {
> + int ret = 0;
> +
>   WARN_ON(!dmabuf);
>  
>   if (dmabuf->ops->end_cpu_access)
> - dmabuf->ops->end_cpu_access(dmabuf, direction);
> + ret = dmabuf->ops->end_cpu_access(dmabuf, direction);
> +
> + return ret;
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
>  
> diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
> b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> index 1f3eef6fb345..0506016e18e0 100644
> --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> @@ -228,25 +228,20 @@ static int i915_gem_begin_cpu_access(struct dma_buf 
> *dma_buf, enum dma_data_dire
>   return ret;
>  }
>  
> -static void i915_gem_end_cpu_access(struct dma_buf *dma_buf, enum 
> dma_data_direction direction)
> +static int i915_gem_end_cpu_access(struct dma_buf *dma_buf, enum 
> dma_data_direction direction)
>  {
>   struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
>   struct drm_device *dev = obj->base.dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - bool was_interruptible;
>   int ret;
>  
> - mutex_lock(>struct_mutex);
> - was_interruptible = dev_priv->mm.interruptible;
> - dev_priv->mm.interruptible = false;
> + ret = i915_mutex_lock_interruptible(dev);
> + if (ret)
> + return ret;
>  
>   ret = i915_gem_object_set_to_gtt_domain(obj, false);
> -
> - dev_priv->mm.interruptible = was_interruptible;
>   mutex_unlock(>struct_mutex);
>  
> - if (unlikely(ret))
> -

[PATCH 1/3] drm: introduce drm_connector_plug_all() helper

[Daniel Vetter]

On Fri, Mar 18, 2016 at 09:58:49PM +, Alexey Brodkin wrote:
> Hi Daniel,
> 
> On Fri, 2016-03-18 at 19:06 +0100, Daniel Vetter wrote:
> > On Fri, Mar 18, 2016 at 01:01:42PM +0300, Alexey Brodkin wrote:
> > > 
> > > As a pair to already existing drm_connector_unplug_all() we're adding
> > > generic implementation of what is already done in some drivers.
> > > 
> > > Once this helper is implemented we'll be ready to switch existing
> > > driver-specific implementations with generic one.
> > > 
> > > Signed-off-by: Alexey Brodkin 
> > > Cc: Daniel Vetter 
> > > Cc: David Airlie 
> > > ---
> > >  drivers/gpu/drm/drm_crtc.c | 44 
> > > +++-
> > >  drivers/gpu/drm/drm_drv.c  |  3 ++-
> > >  include/drm/drm_crtc.h     |  3 ++-
> > >  3 files changed, 47 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > > index 65258ac..ce27420 100644
> > > --- a/drivers/gpu/drm/drm_crtc.c
> > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > @@ -1080,6 +1080,46 @@ void drm_connector_unregister(struct drm_connector 
> > > *connector)
> > >  }
> > >  EXPORT_SYMBOL(drm_connector_unregister);
> > >  
> > > +/**
> > > + * drm_connector_plug_all - register connector userspace interfaces
> > > + * @dev: drm device
> > > + *
> > > + * This function registers all connector userspace interfaces in sysfs. 
> > > Should
> > > + * be call when the device is disconnected, e.g. from an usb driver's
> > Still talks about disconnect ;-) Please also mention that this just calls
> > drm_connector_register() exactly like this including () to generate a
> > kerneldoc hyperlink.
> 
> Well I intentionally left in description of drm_connector_register_all():
> "Should be call when the device is disconnected, e.g. from an usb driver's
>  ->connect callback."

You use "disconnected" for connecting stuff. That doesn't make sense to me
at all - register_all is for when you want to publish something, not for
unpublishing when the device disappears. Or maybe this is a case of lost
in translation, and you mean something else?
-Daniel

> I did mean it. Or is this statement is incorrect and example of invocation of
> drm_connector_register_all() should be different? Which one works better then?
> 
> > > 
> > > + * ->connect callback.
> > Returns: section is missing, specifying how this can fail. Just copy the
> > one from connector_register().
> 
> Yeah, correct. Blind copy-paste doesn't work equally good always :(
> 
> > > 
> > > + */
> > > +int drm_connector_plug_all(struct drm_device *dev)
> > > +{
> > > + struct drm_connector *connector, *failed;
> > > + int ret;
> > > +
> > > + mutex_lock(>mode_config.mutex);
> > > +
> > > + list_for_each_entry(connector, >mode_config.connector_list, head) {
> > for_each_connector here please. And the s/plug/register/ naming discussion
> > we've had.
> 
> Ok.
> 
> > > 
> > > + ret = drm_connector_register(connector);
> > > + if (ret) {
> > > + failed = connector;
> > > + goto err;
> > > + }
> > > + }
> > > +
> > > + mutex_unlock(>mode_config.mutex);
> > > +
> > > + return 0;
> > > +
> > > +err:
> > > + list_for_each_entry(connector, >mode_config.connector_list, head) {
> > > + if (failed == connector)
> > > + break;
> > > +
> > > + drm_connector_unregister(connector);
> > > + }
> > > +
> > > + mutex_unlock(>mode_config.mutex);
> > > +
> > > + return ret;
> > > +}
> > > +EXPORT_SYMBOL(drm_connector_plug_all);
> > >  
> > >  /**
> > >   * drm_connector_unplug_all - unregister connector userspace interfaces
> > > @@ -1093,10 +1133,12 @@ void drm_connector_unplug_all(struct drm_device 
> > > *dev)
> > >  {
> > >  struct drm_connector *connector;
> > >  
> > > - /* FIXME: taking the mode config mutex ends up in a clash with sysfs */
> > > + mutex_lock(>mode_config.mutex);
> > You can't drop that FIXME, the bug is still there.
> 
> That's clear given your explanation in the previous email.
> 
> > > 
> > > +
> > >  list_for_each_entry(connector, 
> > > >mode_config.connector_list, head)
> > >  drm_connector_unregister(connector);
> > >  
> > > + mutex_unlock(>mode_config.mutex);
> > >  }
> > >  EXPORT_SYMBOL(drm_connector_unplug_all);
> > >  
> > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > > index 167c8d3..4a559c6 100644
> > > --- a/drivers/gpu/drm/drm_drv.c
> > > +++ b/drivers/gpu/drm/drm_drv.c
> > > @@ -715,7 +715,8 @@ EXPORT_SYMBOL(drm_dev_unref);
> > >   *
> > >   * Register the DRM device @dev with the system, advertise device to 
> > > user-space
> > >   * and start normal device operation. @dev must be allocated via 
> > > drm_dev_alloc()
> > > - * previously.
> > > + * previously and right after drm_dev_register() driver should call
> > It'd do 2 sentences here for simplicity, not connect them with and. Also
> > "... _the_ driver should ..."
> 

[Bug 105711] amdgpu: no monitor signal (modprobe amdgpu fails)

[bugzilla-dae...@bugzilla.kernel.org]

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

Lars W.  changed:

   What|Removed |Added

 Attachment #209851|application/octet-stream|text/plain
  mime type||

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 105711] amdgpu: no monitor signal (modprobe amdgpu fails)

[bugzilla-dae...@bugzilla.kernel.org]

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

Lars W.  changed:

   What|Removed |Added

 Attachment #189801|0   |1
is obsolete||
 Attachment #189821|0   |1
is obsolete||

--- Comment #5 from Lars W.  ---
Created attachment 209851
  --> https://bugzilla.kernel.org/attachment.cgi?id=209851=edit
kernel dmesg output

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 105711] amdgpu: no monitor signal (modprobe amdgpu fails)

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #4 from Lars W.  ---
Created attachment 209841
  --> https://bugzilla.kernel.org/attachment.cgi?id=209841=edit
kernel-4.5.0 config (gzip compressed)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 105711] amdgpu: no monitor signal (modprobe amdgpu fails)

[bugzilla-dae...@bugzilla.kernel.org]

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

Lars W.  changed:

   What|Removed |Added

Summary|amdgpu: no monitor signal   |amdgpu: no monitor signal
   |and kernel panic|(modprobe amdgpu fails)

--- Comment #3 from Lars W.  ---
Still failing with kernel-4.5.0:

[   43.006770] [drm] amdgpu kernel modesetting enabled.
[   43.007422] ACPI: PCI Interrupt Link [LK2E] enabled at IRQ 47
[   43.007760] [drm] initializing kernel modesetting (TONGA 0x1002:0x6939
0x174B:0xE306 0x00).
[   43.007789] [drm] register mmio base: 0xB0B4
[   43.007792] [drm] register mmio size: 262144
[   43.007804] [drm] doorbell mmio base: 0xB0E0
[   43.007806] [drm] doorbell mmio size: 2097152
[   43.007818] [drm] probing gen 2 caps for device 10de:377 = 113501/0
[   43.007822] [drm] probing mlw for device 10de:377 = 113501
[   43.007991] ATOM BIOS: E306
[   43.009420] amdgpu :83:00.0: VRAM: 2048M 0x -
0x7FFF (2048M used)
[   43.009427] amdgpu :83:00.0: GTT: 2048M 0x8000 -
0x
[   43.009431] [drm] Detected VRAM RAM=2048M, BAR=256M
[   43.009434] [drm] RAM width 256bits DDR
[   43.010009] [TTM] Zone  kernel: Available graphics memory: 12376642 kiB
[   43.010016] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[   43.010019] [TTM] Initializing pool allocator
[   43.010031] [TTM] Initializing DMA pool allocator
[   43.010078] [drm] amdgpu: 2048M of VRAM memory ready
[   43.010081] [drm] amdgpu: 2048M of GTT memory ready.
[   43.010090] [drm] GART: num cpu pages 524288, num gpu pages 524288
[   43.018292] [drm] PCIE GART of 2048M enabled (table at 0x0004).
[   43.018309] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   43.018309] [drm] Driver supports precise vblank timestamp query.
[   43.018348] amdgpu :83:00.0: amdgpu: using MSI.
[   43.018376] [drm] amdgpu: irq initialized.
[   43.018384] Can't find requested voltage id in vdd_dep_on_sclk table!
[   43.022329] amdgpu: powerplay initialized
[   43.023020] [drm] AMDGPU Display Connectors
[   43.023021] [drm] Connector 0:
[   43.023021] [drm]   DP-1
[   43.023022] [drm]   HPD4
[   43.023023] [drm]   DDC: 0x4868 0x4868 0x4869 0x4869 0x486a 0x486a 0x486b
0x486b
[   43.023024] [drm]   Encoders:
[   43.023025] [drm] DFP1: INTERNAL_UNIPHY1
[   43.023025] [drm] Connector 1:
[   43.023026] [drm]   HDMI-A-1
[   43.023026] [drm]   HPD5
[   43.023028] [drm]   DDC: 0x4870 0x4870 0x4871 0x4871 0x4872 0x4872 0x4873
0x4873
[   43.023028] [drm]   Encoders:
[   43.023029] [drm] DFP2: INTERNAL_UNIPHY1
[   43.023029] [drm] Connector 2:
[   43.023030] [drm]   DVI-D-1
[   43.023030] [drm]   HPD1
[   43.023031] [drm]   DDC: 0x4878 0x4878 0x4879 0x4879 0x487a 0x487a 0x487b
0x487b
[   43.023032] [drm]   Encoders:
[   43.023033] [drm] DFP3: INTERNAL_UNIPHY
[   43.023033] [drm] Connector 3:
[   43.023034] [drm]   DVI-I-1
[   43.023034] [drm]   HPD6
[   43.023035] [drm]   DDC: 0x487c 0x487c 0x487d 0x487d 0x487e 0x487e 0x487f
0x487f
[   43.023036] [drm]   Encoders:
[   43.023036] [drm] DFP4: INTERNAL_UNIPHY2
[   43.023037] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[   43.023144] amdgpu :83:00.0: fence driver on ring 0 use gpu addr
0x8008, cpu addr 0x880632c0b008
[   43.023549] amdgpu :83:00.0: fence driver on ring 1 use gpu addr
0x8018, cpu addr 0x880632c0b018
[   43.023729] amdgpu :83:00.0: fence driver on ring 2 use gpu addr
0x8028, cpu addr 0x880632c0b028
[   43.023870] amdgpu :83:00.0: fence driver on ring 3 use gpu addr
0x8038, cpu addr 0x880632c0b038
[   43.025305] amdgpu :83:00.0: fence driver on ring 4 use gpu addr
0x8048, cpu addr 0x880632c0b048
[   43.025693] amdgpu :83:00.0: fence driver on ring 5 use gpu addr
0x8058, cpu addr 0x880632c0b058
[   43.026043] amdgpu :83:00.0: fence driver on ring 6 use gpu addr
0x8068, cpu addr 0x880632c0b068
[   43.026248] amdgpu :83:00.0: fence driver on ring 7 use gpu addr
0x8078, cpu addr 0x880632c0b078
[   43.026425] amdgpu :83:00.0: fence driver on ring 8 use gpu addr
0x8088, cpu addr 0x880632c0b088
[   43.026594] amdgpu :83:00.0: fence driver on ring 9 use gpu addr
0x8098, cpu addr 0x880632c0b098
[   43.026683] amdgpu :83:00.0: fence driver on ring 10 use gpu addr
0x80a8, cpu addr 0x880632c0b0a8
[   43.026717] [drm] Found UVD firmware Version: 1.52 Family ID: 10
[   43.027592] amdgpu :83:00.0: fence driver on ring 11 use gpu addr
0x0048f7b0, cpu addr 0xc9000584e7b0
[   43.027602] [drm] Found VCE firmware Version: 50.17 Binary ID: 3
[   43.027712] amdgpu :83:00.0: fence driver on ring 12 use gpu addr
0x80c8, cpu addr 0x880632c0b0c8
[   

[PATCH 3/4] drm/radeon: consolidate uvd/vce initialization, resume and suspend.

[Daniel Vetter]

On Fri, Mar 18, 2016 at 09:16:08AM +0100, Daniel Vetter wrote:
> On Fri, Mar 18, 2016 at 01:00:26PM +0900, Michel Dänzer wrote:
> > On 17.03.2016 16:36, Daniel Vetter wrote:
> > > On Thu, Mar 17, 2016 at 06:41:14AM +1000, Dave Airlie wrote:
> > >> Just an aside,
> > >>
> > >> So is there no way to do hibernate with these blocks?
> > >>
> > >> Like can you not cleanly shut them down without doing a power cycle.
> > >>
> > >> I have to say UVD is a real pain in the ass from a stability pov, I'd
> > >> kinda wished I'd enforced AMD creating something like intel-gpu-tools
> > >> and having tests to make sure GPU reset etc stayed working before
> > >> merging it.
> > > 
> > > igt already supports running on any kind of drm device, and it has a bunch
> > > of vc4 specific testcases on top. If anyone finds offence in the "intel"
> > > part, we can rename it to igt gpu tools/tests ;-)
> > 
> > Any tips for running the tests on non-Intel GPUs? I tried piglit igt.py,
> > but it was generating tens of thousands of failures from tests which
> > look Intel specific.
> 
> Yeah Chris again broke the SKIP logic in gem_concurrent_blt/all testcases.
> Just explicitly exclude those with -x gem_concurrent. The problem is that
> hw/kernel feature checks aren't properlty encapsulated in the right
> igt_fixture or igt_subtest blocks, so it falls over. Specifically the
> access_mode->require() test is only protetected by
> igt_only_list_subtests(), which is the wrong way to do it.
> 
> Adding Chris.

Ok, fixed pushed now using the just added igt_subtest_group blocks. Please
scream when anything else falls apart.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/rockchip: vop: Reset yrgb_mst when re-enabling

[Mark yao]

On 2016年03月18日 19:22, Tomeu Vizoso wrote:
> When the VOP is re-enabled, it will start scanning right away the
> framebuffers that were configured from the last time, even if those have
> been destroyed already. To prevent the VOP from trying to access freed
> memory, reset the registers that hold pointers to framebuffers right
> after we can write to them, but before the VOP is awaken from standby.
>
> Signed-off-by: Tomeu Vizoso 
> Link: 
> http://lkml.kernel.org/g/CAAObsKAv+05ih5U+=4kic_NsjGMhfxYheHR8xXXmacZs+p5SHw 
> at mail.gmail.com
> ---
>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 +
>   1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 5e57f5b2e4b0..0df91c28740b 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -429,6 +429,7 @@ static void vop_dsp_hold_valid_irq_disable(struct vop 
> *vop)
>   static void vop_enable(struct drm_crtc *crtc)
>   {
>   struct vop *vop = to_vop(crtc);
> + int i;
>   int ret;
>   
>   if (vop->is_enabled)
> @@ -476,6 +477,18 @@ static void vop_enable(struct drm_crtc *crtc)
>*/
>   vop->is_enabled = true;
>   
> + /*
> +  * Before turning the VOP completely on, unset the registers
> +  * containing FB addresses to avoid the HW start scanning old FBs.
> +  */
> + for (i = 0; i < vop->data->win_size; i++) {
> + struct vop_win *vop_win = >win[i];
> + const struct vop_win_data *win = vop_win->data;
> +
> + VOP_WIN_SET(vop, win, yrgb_mst, 0x0);
> + VOP_WIN_SET(vop, win, uv_mst, 0x0);
> + }
> +
Hi Tomeu

Thanks for your fix.

Set yrgb_mst and uv_mst is not a good idea, because 0x0 also is a memory 
buffer address, ddr will access the 0x0 buffer.
I think you may enable DRM_FBDEV_EMULATION, the 0x0 address is iommu 
mmaped address for fbdev, so your test can works.
but if DRM_FBDEV_EMULATION is not define, may be 0x0 address is 
unmmaped, would get the iommu crash.

I think we can use atomic disable function like this:
for_each_plane_in_state(old_state, plane, old_plane_state, i) {
 const struct drm_plane_helper_funcs *funcs;
 funcs = plane->helper_private;
 funcs->atomic_disable(plane, old_plane_state);
}

But I think we'd better find why we need do this hack here.

Does the old FB address is ummaped when crtc disabling? why plane is not 
disabled?

Thanks.

>   spin_lock(>reg_lock);
>   
>   VOP_CTRL_SET(vop, standby, 0);


-- 
ï¼­ark Yao

[PATCHv13 01/17] dts: exynos4*: add HDMI CEC pin definition to pinctrl

[Hans Verkuil]

On 03/19/2016 03:50 AM, Krzysztof Kozlowski wrote:
> On Fri, Mar 18, 2016 at 03:07:00PM +0100, Hans Verkuil wrote:
>> From: Kamil Debski 
>>
>> Add pinctrl nodes for the HDMI CEC device to the Exynos4210 and
>> Exynos4x12 SoCs. These are required by the HDMI CEC device.
>>
>> Signed-off-by: Kamil Debski 
>> Signed-off-by: Hans Verkuil 
>> Acked-by: Krzysztof Kozlowski 
>> ---
>>  arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 7 +++
>>  arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 7 +++
>>  2 files changed, 14 insertions(+)
> 
> Hi Hans,
> 
> I see you have been carrying these three patches for a long time.
> Initially I thought that there are some dependencies... but maybe there
> are not?
> 
> Can I take these Exynos DTS patches to samsung-soc?

That would be very nice!

BTW, it would be nice if someone from Samsung could try to improve the s5p
CEC driver from this patch series.

The problem is that it expects userspace to tell it the physical address,
which is read from the EDID. But the HDMI driver in the kernel already knows
this, so requiring userspace to handle this is not nice.

Basically the CEC driver needs to know when a new EDID has been read and
when the hotplug detect goes low (EDID has been lost).

If someone who actually knows the HDMI code could provide me with a patch,
then I can fix the CEC driver. I have an odroid to test with, so I can check
the code.

Regards,

Hans

[PATCH v8 6/6] ARM: dts: am335x-boneblack: Add HDMI audio support

[Jean-Francois Moine]

On Thu, 17 Mar 2016 14:22:34 +0200
Jyri Sarha  wrote:

> @@ -76,16 +87,22 @@
>  };
>  
>   {
> - tda19988 {
> + tda19988: tda19988 {
>   compatible = "nxp,tda998x";
>   reg = <0x70>;
> +
>   pinctrl-names = "default", "off";
>   pinctrl-0 = <_hdmi_bonelt_pins>;
>   pinctrl-1 = <_hdmi_bonelt_off_pins>;
>  
> - port {
> - hdmi_0: endpoint at 0 {
> - remote-endpoint = <_0>;
> + #sound-dai-cells = <0>;
> + audio-ports = < AFMT_I2S0x03>;
> +
> + ports {
> + port at 0 {
> + hdmi_0: endpoint at 0 {
> + remote-endpoint = <_0>;
> + };
>   };
>   };
>   };

Why did you add a 'ports' container? As there is only one port,
it is useless.

Also, you don't need '@0' in the 'port' and 'endpoint'.
If you want to keep it, you must add 'reg = 0;'s.

-- 
Ken ar c'hentañ| ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[Bug 94171] ati multihead black on one output

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #5 from Felix Miata  ---
Created attachment 209811
  --> https://bugzilla.kernel.org/attachment.cgi?id=209811=edit
Xorg.0.log F23 on big41, black DVI 1920x1080 output

On host big 41 in Fedora 21 with KDE4 and kernel 4.1.13 on Cedar booting
multi-user.target, using startx and
xrandr --dpi 144 --output DVI-0 --mode 1920x1080 --above VGA-0 --output VGA-0
--primary --mode 1680x1050
both LCD screens play Xorg as expected, 1920x2130.

With
xrandr --dpi 144 --output DVI-0 --mode 1920x1080 --above VGA-0 --output VGA-0
--primary --mode 1920x1440
Xorg runs the LCD, where xrandr reports 1920x2520, as expected, but turns the
CRT black. If I append --rate 75, which isn't required for expected results
with Intel 4 Series or NVidia G84 gfxchips, then both displays work, comprising
1920x2520 as expected.

Still with CRT on VGA and LCD on DVI, startx with
xrandr --dpi 120 --output DVI-0 --mode 1920x1080 --above VGA-0 --output VGA-0
--primary --mode 1600x1200
produces 1920x2280 as expected in Xorg - no --rate parameter is required.

Fedora 23 with KDE5 and kernel 4.4.3 on same host with same three displays and
Cedar mirrors exactly as herein described for Fedora 21.

Replacing the Cedar in big41 with rv516 X1300, and still using F23,
xrandr --dpi 144 --output DVI-0 --mode 1920x1080 --above VGA-0 --output VGA-0
--primary --mode 1920x1440
keeps the DVI's LCD black while in Xorg's expected 1920x2520, but working as
expected on the ttys, even with
xrandr --dpi 120 --output DVI-0 --mode 1920x1080 --above VGA-0 --output VGA-0
--primary --mode 1600x1200
and even if appending --rate. With rv516, lowering demand all the way to
xrandr --dpi 108 --output DVI-0 --mode 1280x720 --above VGA-0 --output VGA-0
--primary --mode 1280x1024
is required to see output on the DVI portion of 1280x1744 on the LCD.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH] gpu/drm: Use u64_to_user_pointer

[kbuild test robot]

Hi Joe,

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

url:
https://github.com/0day-ci/linux/commits/Joe-Perches/gpu-drm-Use-u64_to_user_pointer/20160319-012749
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: mips-allmodconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=mips 

All warnings (new ones prefixed by >>):

   In file included from include/linux/uaccess.h:5:0,
from include/linux/highmem.h:8,
from include/drm/drmP.h:40,
from drivers/gpu/drm/vc4/vc4_drv.h:9,
from drivers/gpu/drm/vc4/vc4_bo.c:21:
   drivers/gpu/drm/vc4/vc4_bo.c: In function 'vc4_create_shader_bo_ioctl':
   drivers/gpu/drm/vc4/vc4_bo.c:503:7: error: implicit declaration of function 
'u64_to_user_ptr' [-Werror=implicit-function-declaration]
  u64_to_user_ptr(args->data),
  ^
   arch/mips/include/asm/uaccess.h:1161:15: note: in definition of macro 
'copy_from_user'
 __cu_from = (from);  \
  ^
>> arch/mips/include/asm/uaccess.h:1161:12: warning: assignment makes pointer 
>> from integer without a cast [-Wint-conversion]
 __cu_from = (from);  \
   ^
   drivers/gpu/drm/vc4/vc4_bo.c:502:6: note: in expansion of macro 
'copy_from_user'
 if (copy_from_user(bo->base.vaddr,
 ^
   cc1: some warnings being treated as errors
--
   In file included from arch/mips/include/asm/module.h:6:0,
from include/linux/module.h:24,
from drivers/gpu/drm/vc4/vc4_gem.c:24:
   drivers/gpu/drm/vc4/vc4_gem.c: In function 'vc4_get_hang_state_ioctl':
   drivers/gpu/drm/vc4/vc4_gem.c:123:19: error: implicit declaration of 
function 'u64_to_user_ptr' [-Werror=implicit-function-declaration]
 if (copy_to_user(u64_to_user_ptr(get_state->bo),
  ^
   arch/mips/include/asm/uaccess.h:930:13: note: in definition of macro 
'copy_to_user'
 __cu_to = (to);   \
^
   arch/mips/include/asm/uaccess.h:930:10: warning: assignment makes pointer 
from integer without a cast [-Wint-conversion]
 __cu_to = (to);   \
 ^
   drivers/gpu/drm/vc4/vc4_gem.c:123:6: note: in expansion of macro 
'copy_to_user'
 if (copy_to_user(u64_to_user_ptr(get_state->bo),
 ^
   drivers/gpu/drm/vc4/vc4_gem.c: In function 'vc4_cl_lookup_bos':
>> arch/mips/include/asm/uaccess.h:1161:12: warning: assignment makes pointer 
>> from integer without a cast [-Wint-conversion]
 __cu_from = (from);  \
   ^
   drivers/gpu/drm/vc4/vc4_gem.c:552:8: note: in expansion of macro 
'copy_from_user'
 ret = copy_from_user(handles,
   ^
   drivers/gpu/drm/vc4/vc4_gem.c: In function 'vc4_get_bcl':
>> arch/mips/include/asm/uaccess.h:1161:12: warning: assignment makes pointer 
>> from integer without a cast [-Wint-conversion]
 __cu_from = (from);  \
   ^
   drivers/gpu/drm/vc4/vc4_gem.c:626:6: note: in expansion of macro 
'copy_from_user'
 if (copy_from_user(bin,
 ^
>> arch/mips/include/asm/uaccess.h:1161:12: warning: assignment makes pointer 
>> from integer without a cast [-Wint-conversion]
 __cu_from = (from);  \
   ^
   drivers/gpu/drm/vc4/vc4_gem.c:633:6: note: in expansion of macro 
'copy_from_user'
 if (copy_from_user(exec->shader_rec_u,
 ^
>> arch/mips/include/asm/uaccess.h:1161:12: warning: assignment makes pointer 
>> from integer without a cast [-Wint-conversion]
 __cu_from = (from);  \
   ^
   drivers/gpu/drm/vc4/vc4_gem.c:640:6: note: in expansion of macro 
'copy_from_user'
 if (copy_from_user(exec->uniforms_u,
 ^
   cc1: some warnings being treated as errors

vim +1161 arch/mips/include/asm/uaccess.h

^1da177e include/asm-mips/uaccess.h  Linus Torvalds  2005-04-16  1145   *
^1da177e include/asm-mips/uaccess.h  Linus Torvalds  2005-04-16  1146   * 
Copy data from user space to kernel space.
^1da177e include/asm-mips/uaccess.h  Linus Torvalds  2005-04-16  1147   *
^1da177e include/asm-mips/uaccess.h  Linus Torvalds  2005-04-16  1148   * 
Returns number of bytes that could not be copied.
^1da177e include/asm-mips/uaccess.h  Linus Torvalds  2005-04-16  1149   * 
On success, this will be zero.
^1da177e include/asm-mips/uaccess.h  Linus Torvalds  2005-04-16  1150   *
^1da177e include/asm-mips/uaccess.h  Linus Torvalds  2005-04-16  1151   * 
If some data could not be copied, this function will pad the copied

[PATCH] gpu/drm: Use u64_to_user_pointer

[kbuild test robot]

Hi Joe,

[auto build test ERROR on drm/drm-next]
[also build test ERROR on next-20160318]
[cannot apply to v4.5]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Joe-Perches/gpu-drm-Use-u64_to_user_pointer/20160319-012749
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: xtensa-allmodconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All error/warnings (new ones prefixed by >>):

   drivers/gpu/drm/vc4/vc4_bo.c: In function 'vc4_create_shader_bo_ioctl':
>> drivers/gpu/drm/vc4/vc4_bo.c:502:2: error: implicit declaration of function 
>> 'u64_to_user_ptr' [-Werror=implicit-function-declaration]
 if (copy_from_user(bo->base.vaddr,
 ^
   In file included from include/linux/uaccess.h:5:0,
from include/linux/highmem.h:8,
from include/drm/drmP.h:40,
from drivers/gpu/drm/vc4/vc4_drv.h:9,
from drivers/gpu/drm/vc4/vc4_bo.c:21:
>> arch/xtensa/include/asm/uaccess.h:429:37: warning: passing argument 2 of 
>> '__generic_copy_from_user' makes pointer from integer without a cast
#define copy_from_user(to, from, n) __generic_copy_from_user((to), (from), 
(n))
^
>> drivers/gpu/drm/vc4/vc4_bo.c:502:6: note: in expansion of macro 
>> 'copy_from_user'
 if (copy_from_user(bo->base.vaddr,
 ^
   arch/xtensa/include/asm/uaccess.h:418:1: note: expected 'const void *' but 
argument is of type 'int'
__generic_copy_from_user(void *to, const void *from, unsigned long n)
^
   cc1: some warnings being treated as errors
--
   drivers/gpu/drm/vc4/vc4_gem.c: In function 'vc4_get_hang_state_ioctl':
>> drivers/gpu/drm/vc4/vc4_gem.c:123:2: error: implicit declaration of function 
>> 'u64_to_user_ptr' [-Werror=implicit-function-declaration]
 if (copy_to_user(u64_to_user_ptr(get_state->bo),
 ^
   In file included from include/linux/uaccess.h:5:0,
from include/linux/highmem.h:8,
from include/drm/drmP.h:40,
from drivers/gpu/drm/vc4/vc4_drv.h:9,
from drivers/gpu/drm/vc4/vc4_gem.c:31:
>> arch/xtensa/include/asm/uaccess.h:428:35: warning: passing argument 1 of 
>> '__generic_copy_to_user' makes pointer from integer without a cast
#define copy_to_user(to, from, n) __generic_copy_to_user((to), (from), (n))
  ^
>> drivers/gpu/drm/vc4/vc4_gem.c:123:6: note: in expansion of macro 
>> 'copy_to_user'
 if (copy_to_user(u64_to_user_ptr(get_state->bo),
 ^
   arch/xtensa/include/asm/uaccess.h:409:1: note: expected 'void *' but 
argument is of type 'int'
__generic_copy_to_user(void *to, const void *from, unsigned long n)
^
   drivers/gpu/drm/vc4/vc4_gem.c: In function 'vc4_cl_lookup_bos':
>> arch/xtensa/include/asm/uaccess.h:429:37: warning: passing argument 2 of 
>> '__generic_copy_from_user' makes pointer from integer without a cast
#define copy_from_user(to, from, n) __generic_copy_from_user((to), (from), 
(n))
^
>> drivers/gpu/drm/vc4/vc4_gem.c:552:8: note: in expansion of macro 
>> 'copy_from_user'
 ret = copy_from_user(handles,
   ^
   arch/xtensa/include/asm/uaccess.h:418:1: note: expected 'const void *' but 
argument is of type 'int'
__generic_copy_from_user(void *to, const void *from, unsigned long n)
^
   drivers/gpu/drm/vc4/vc4_gem.c: In function 'vc4_get_bcl':
>> arch/xtensa/include/asm/uaccess.h:429:37: warning: passing argument 2 of 
>> '__generic_copy_from_user' makes pointer from integer without a cast
#define copy_from_user(to, from, n) __generic_copy_from_user((to), (from), 
(n))
^
   drivers/gpu/drm/vc4/vc4_gem.c:626:6: note: in expansion of macro 
'copy_from_user'
 if (copy_from_user(bin,
 ^
   arch/xtensa/include/asm/uaccess.h:418:1: note: expected 'const void *' but 
argument is of type 'int'
__generic_copy_from_user(void *to, const void *from, unsigned long n)
^
>> arch/xtensa/include/asm/uaccess.h:429:37: warning: passing argument 2 of 
>> '__generic_copy_from_user' makes pointer from integer without a cast
#define copy_from_user(to, from, n) __generic_copy_from_user((to), (from), 
(n))
^
   drivers/gpu/drm/vc4/vc4_gem.c:633:6: note: in expansion of macro 
'copy_from_user'
 if (copy_from_user(exec->shader_rec_u,
 ^
   arch/xtensa/include/asm/uaccess.h:418:1: note: expected

[PATCH] gpu/drm: Use u64_to_user_pointer

[kbuild test robot]

Hi Joe,

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

url:
https://github.com/0day-ci/linux/commits/Joe-Perches/gpu-drm-Use-u64_to_user_pointer/20160319-012749
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: m68k-allmodconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/vc4/vc4_bo.c: In function 'vc4_create_shader_bo_ioctl':
   drivers/gpu/drm/vc4/vc4_bo.c:502:2: error: implicit declaration of function 
'u64_to_user_ptr' [-Werror=implicit-function-declaration]
 if (copy_from_user(bo->base.vaddr,
 ^
   In file included from arch/m68k/include/asm/uaccess.h:4:0,
from include/linux/uaccess.h:5,
from include/linux/highmem.h:8,
from include/drm/drmP.h:40,
from drivers/gpu/drm/vc4/vc4_drv.h:9,
from drivers/gpu/drm/vc4/vc4_bo.c:21:
>> arch/m68k/include/asm/uaccess_mm.h:368:2: warning: passing argument 2 of 
>> '__constant_copy_from_user' makes pointer from integer without a cast
 __constant_copy_from_user(to, from, n) : \
 ^
>> arch/m68k/include/asm/uaccess_mm.h:379:37: note: in expansion of macro 
>> '__copy_from_user'
#define copy_from_user(to, from, n) __copy_from_user(to, from, n)
^
   drivers/gpu/drm/vc4/vc4_bo.c:502:6: note: in expansion of macro 
'copy_from_user'
 if (copy_from_user(bo->base.vaddr,
 ^
   arch/m68k/include/asm/uaccess_mm.h:239:1: note: expected 'const void *' but 
argument is of type 'int'
__constant_copy_from_user(void *to, const void __user *from, unsigned long 
n)
^
>> arch/m68k/include/asm/uaccess_mm.h:369:2: warning: passing argument 2 of 
>> '__generic_copy_from_user' makes pointer from integer without a cast
 __generic_copy_from_user(to, from, n))
 ^
>> arch/m68k/include/asm/uaccess_mm.h:379:37: note: in expansion of macro 
>> '__copy_from_user'
#define copy_from_user(to, from, n) __copy_from_user(to, from, n)
^
   drivers/gpu/drm/vc4/vc4_bo.c:502:6: note: in expansion of macro 
'copy_from_user'
 if (copy_from_user(bo->base.vaddr,
 ^
   arch/m68k/include/asm/uaccess_mm.h:202:15: note: expected 'const void *' but 
argument is of type 'int'
unsigned long __generic_copy_from_user(void *to, const void __user *from, 
unsigned long n);
  ^
   cc1: some warnings being treated as errors
--
   drivers/gpu/drm/vc4/vc4_gem.c: In function 'vc4_get_hang_state_ioctl':
   drivers/gpu/drm/vc4/vc4_gem.c:123:2: error: implicit declaration of function 
'u64_to_user_ptr' [-Werror=implicit-function-declaration]
 if (copy_to_user(u64_to_user_ptr(get_state->bo),
 ^
   In file included from arch/m68k/include/asm/uaccess.h:4:0,
from include/linux/uaccess.h:5,
from include/linux/highmem.h:8,
from include/drm/drmP.h:40,
from drivers/gpu/drm/vc4/vc4_drv.h:9,
from drivers/gpu/drm/vc4/vc4_gem.c:31:
>> arch/m68k/include/asm/uaccess_mm.h:373:2: warning: passing argument 1 of 
>> '__constant_copy_to_user' makes pointer from integer without a cast
 __constant_copy_to_user(to, from, n) :  \
 ^
>> arch/m68k/include/asm/uaccess_mm.h:380:35: note: in expansion of macro 
>> '__copy_to_user'
#define copy_to_user(to, from, n) __copy_to_user(to, from, n)
  ^
   drivers/gpu/drm/vc4/vc4_gem.c:123:6: note: in expansion of macro 
'copy_to_user'
 if (copy_to_user(u64_to_user_ptr(get_state->bo),
 ^
   arch/m68k/include/asm/uaccess_mm.h:320:1: note: expected 'void *' but 
argument is of type 'int'
__constant_copy_to_user(void __user *to, const void *from, unsigned long n)
^
>> arch/m68k/include/asm/uaccess_mm.h:374:2: warning: passing argument 1 of 
>> '__generic_copy_to_user' makes pointer from integer without a cast
 __generic_copy_to_user(to, from, n))
 ^
>> arch/m68k/include/asm/uaccess_mm.h:380:35: note: in expansion of macro 
>> '__copy_to_user'
#define copy_to_user(to, from, n) __copy_to_user(to, from, n)
  ^
   drivers/gpu/drm/vc4/vc4_gem.c:123:6: note: in expansion of macro 
'copy_to_user'
 if (copy_to_user(u64_to_user_ptr(get_state->bo),
 ^
   arch/m68k/include/asm/uaccess_mm.h:203:15: note: expected 'void *' but

[Bug 94595] [Mesa AMD] Texture views attached as framebuffers return their viewed tecture's color encoding and render incorrectly

[bugzilla-dae...@freedesktop.org]

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

--- Comment #8 from Nicolai H�hnle  ---
There is a patch at https://patchwork.freedesktop.org/patch/77510/ which fixes
your test case (and should fix format casting with render-to-texture more
generally).

Let us know if this fixes your SRGB-related rendering problems.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: