"EDID checksum is invalid"

[Keith Packard]

Robert Morell  writes:

> FWIW, I've seen that exact symptom on some monitors when the +5V pin on
> the DVI or HDMI cable from the GPU isn't enabled (or isn't providing
> enough current).  Some monitors power the i2c/edid/DDC logic from that
> +5V either exclusively or when in the DPMS off state, and the i2c chip
> will just stop responding after a few cycles if not provided sufficient
> power.

Makes sense -- the chip will power itself from the i2c when not
transmitting, and can talk until whatever energy is stored in various
capacitors on the Vcc rail discharge.

-- 
-keith
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150106/bb2caccd/attachment.sig>

"EDID checksum is invalid"

[Robert Morell]

On Tue, Jan 06, 2015 at 10:07:58PM -0800, Keith Packard wrote:
> * PGP Signed by an unknown key
> 
> Linus Torvalds  writes:
> 
> > it looks like the beginning is the same, but then it just turns to all
> > ones at a random point (even *within* a byte).
> 
> Looks like the EDID ROM is dropping off the i2c bus in the middle of the
> transfer. Wonder if it's being 'clever' if things go too slowly at some
> point, or if there's a bug in the DDC code that's in use.

FWIW, I've seen that exact symptom on some monitors when the +5V pin on
the DVI or HDMI cable from the GPU isn't enabled (or isn't providing
enough current).  Some monitors power the i2c/edid/DDC logic from that
+5V either exclusively or when in the DPMS off state, and the i2c chip
will just stop responding after a few cycles if not provided sufficient
power.

- Robert

"EDID checksum is invalid"

[Keith Packard]

Linus Torvalds  writes:

> it looks like the beginning is the same, but then it just turns to all
> ones at a random point (even *within* a byte).

Looks like the EDID ROM is dropping off the i2c bus in the middle of the
transfer. Wonder if it's being 'clever' if things go too slowly at some
point, or if there's a bug in the DDC code that's in use.

-- 
-keith
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150106/dd699238/attachment.sig>

[Bug 90861] Panic on suspend from KDE with radeon

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

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

--- Comment #5 from Jon Arne Jørgensen  ---
I reproduced the panic when I tried to suspend when radeon was loaded without
radeon.dpm=1.

I was _not_ able to reproduce the panic with kernel-3.10.0-rc7 that I had lying
around in my /boot directory.

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

[Bug 90861] Panic on suspend from KDE with radeon

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

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

--- Comment #4 from Jon Arne Jørgensen  ---
Created attachment 162751
  --> https://bugzilla.kernel.org/attachment.cgi?id=162751=edit
Full pm-suspend log

This is also from a reproduced crash.

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

[Bug 90861] Panic on suspend from KDE with radeon

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

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

--- Comment #3 from Jon Arne Jørgensen  ---
Created attachment 162741
  --> https://bugzilla.kernel.org/attachment.cgi?id=162741=edit
Complete Xorg.log

This is the Xorg.log from a reproduced crash because i forgot to save the Xorg
log when I ran the crashkernel.

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

[Bug 90861] Panic on suspend from KDE with radeon

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

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

--- Comment #2 from Jon Arne Jørgensen  ---
Created attachment 162731
  --> https://bugzilla.kernel.org/attachment.cgi?id=162731=edit
full dmesg from panic

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

[Bug 90861] Panic on suspend from KDE with radeon

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #1 from Alex Deucher  ---
Please attach your xorg log and full dmesg output.

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

[Bug 90861] New: Panic on suspend from KDE with radeon

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

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

Bug ID: 90861
   Summary: Panic on suspend from KDE with radeon
   Product: Drivers
   Version: 2.5
Kernel Version: 3.19.0-rc2-219-g693a30b8
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: jonjon.arnearne at gmail.com
Regression: No

My laptop is running OpenSUSE 13.1 on self compiled kernel.
As of last week, my kernel is panicing when suspending.

This only happens when I'm logged in to my KDE session.
If I log out of KDE and run pm-suspend as root from VT1 with kdm running. The
laptop suspends as expected.

I've suspended via pm-suspend while my user was logged in to both IceWM and TWM
with success.

My suspicion is that some part of my KDE system was upgraded, and something is
preventing radeon from suspending propperly.

Here is dmesg from the crash:
[  267.445563] PM: Syncing filesystems ... done.
[  267.704349] PM: Preparing system for mem sleep
[  267.953474] Freezing user space processes ... (elapsed 0.001 seconds) done.
[  267.955241] Freezing remaining freezable tasks ... (elapsed 0.001 seconds)
done.
[  267.956352] PM: Entering mem sleep
[  267.956405] Suspending console(s) (use no_console_suspend to debug)
[  267.956924] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  267.957167] sd 0:0:0:0: [sda] Stopping disk
[  280.034180] radeon :02:00.0:  DPM device timeout 
[  280.034185]  88022885b748 8802288546d0 00013180
88022885bfd8
[  280.034188]  00013180 88022e1fa3d0 8802288546d0
88022885b728
[  280.034191]  88022e39c000 88022885b788 ec3b
88022e39c000
[  280.034192] Call Trace:
[  280.034201]  [] schedule+0x24/0x70
[  280.034205]  [] schedule_timeout+0x14b/0x2d0
[  280.034211]  [] ? internal_add_timer+0x80/0x80
[  280.034255]  [] radeon_fence_default_wait+0xc9/0x220
[radeon]
[  280.034260]  [] ? prepare_to_wait_event+0x100/0x100
[  280.034265]  [] fence_wait_timeout+0x34/0x120
[  280.034278]  [] ttm_bo_wait+0x14f/0x1b0 [ttm]
[  280.034289]  [] ttm_bo_move_accel_cleanup+0x52/0x3c0 [ttm]
[  280.034310]  [] radeon_move_blit.isra.12+0xc0/0x150
[radeon]
[  280.034321]  [] radeon_bo_move+0xab/0x210 [radeon]
[  280.034325]  [] ttm_bo_handle_move_mem+0x265/0x5c0 [ttm]
[  280.034330]  [] ? ttm_bo_mem_space+0x181/0x350 [ttm]
[  280.034334]  [] ttm_bo_evict+0x132/0x300 [ttm]
[  280.034348]  [] ? drm_vma_offset_add+0x2e/0xc0 [drm]
[  280.034352]  [] ttm_mem_evict_first+0x1c0/0x250 [ttm]
[  280.034357]  [] ttm_bo_force_list_clean+0x62/0xb0 [ttm]
[  280.034361]  [] ttm_bo_evict_mm+0x2e/0x60 [ttm]
[  280.034372]  [] radeon_bo_evict_vram+0x15/0x20 [radeon]
[  280.034380]  [] radeon_suspend_kms+0x163/0x2c0 [radeon]
[  280.034388]  [] radeon_pmops_suspend+0x1a/0x20 [radeon]
[  280.034390]  [] pci_pm_suspend+0x75/0x150
[  280.034391]  [] ? pci_pm_freeze+0xf0/0xf0
[  280.034393]  [] dpm_run_callback+0x49/0x160
[  280.034394]  [] __device_suspend+0x12d/0x370
[  280.034395]  [] ? pm_dev_dbg+0x80/0x80
[  280.034396]  [] async_suspend+0x1a/0xa0
[  280.034398]  [] async_run_entry_fn+0x47/0x160
[  280.034400]  [] process_one_work+0x140/0x420
[  280.034401]  [] worker_thread+0x11b/0x490
[  280.034402]  [] ? process_one_work+0x420/0x420
[  280.034403]  [] kthread+0xcd/0xf0
[  280.034404]  [] ? kthread_create_on_node+0x180/0x180
[  280.034405]  [] ret_from_fork+0x7c/0xb0
[  280.034406]  [] ? kthread_create_on_node+0x180/0x180
[  280.034408] Kernel panic - not syncing: radeon :02:00.0: unrecoverable
failure

[  280.034410] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
3.19.0-rc2-219-g693a30b8+ #1
[  280.034410] Hardware name: Dell Inc. Studio XPS 1645/0Y517R, BIOS A13
04/01/2011
[  280.034411]  88022885bd30 880237c03d88 8162e880
81c45c38
[  280.034412]  81a7b1e5 880237c03e08 81629367
880237bfffc0
[  280.034413]  88020018 880237c03e18 880237c03db8
880237c03dc0
[  280.034414] Call Trace:
[  280.034416][] dump_stack+0x4c/0x6e
[  280.034418]  [] panic+0xb6/0x1e4
[  280.034420]  [] ? pm_dev_dbg+0x80/0x80
[  280.034421]  [] dpm_watchdog_handler+0x4d/0x60
[  280.034423]  [] call_timer_fn+0x34/0x150
[  280.034424]  [] ? pm_dev_dbg+0x80/0x80
[  280.034425]  [] run_timer_softirq+0x254/0x300
[  280.034427]  [] __do_softirq+0xe4/0x2a0
[  280.034429]  [] irq_exit+0x9d/0xb0
[  280.034431]  [] do_IRQ+0x55/0xf0
[  280.034432]  [] common_interrupt+0x6a/0x6a
[  280.034435][] ? cpuidle_enter_state+0x69/0x1b0
[  280.034436]  [] ? cpuidle_enter_state+0x58/0x1b0
[  280.034438]  [] cpuidle_enter+0x12/0x20
[  280.034439]  [] cpu_startup_entry+0x354/0x3f0
[  280.034440]  [] rest_init+0x80/0x90
[  280.034443]  [] start_kernel+0x470/0x47d
[  280.03]  [] ? 

[PULL resend] amdkfd-fixes

[Oded Gabbay]

Hi Dave,

I'm resending this pull request due to Christian's email on the ioctl 
patch-set.

Highlights:

- Complete overhaul to the main IOCTL function, kfd_ioctl(), according to 
  drm_ioctl() example. This includes changing the IOCTL definitions, so it 
  breaks compatibility with previous versions of the userspace. However, 
  because the kernel was not officialy released yet, and this the first 
  kernel that includes amdkfd, I assume I can still do that at this stage.

- A couple of bug fixes for the non-HWS path (used for bring-ups and 
  debugging purposes only). 

Our QA team run a test on -rc2 and didn't discover any regressions, 
so I don't expect an additionl pull request for 3.19 unless something 
unexpected will pop-up.

Oded

The following changes since commit 2f6bd4da08b5054ba933be6f7b17ed02ad6c4162:

  Merge tag 'amdkfd-fixes-2014-12-30' of 
git://people.freedesktop.org/~gabbayo/linux into linus (2015-01-04 17:44:43 
+1000)

are available in the git repository at:


  git://people.freedesktop.org/~gabbayo/linux tags/amdkfd-fixes-2015-01-06

for you to fetch changes up to 76baee6c733bfef30fcf86cbd121e336b839e408:

  drm/amdkfd: rewrite kfd_ioctl() according to drm_ioctl() (2015-01-06 19:44:36 
+0200)


Alexey Khoroshilov (1):
  drm/radeon: do not leave queue acquired if timeout happens in 
kgd_hqd_destroy()

Ben Goz (4):
  drm/amd: Fixing typos in kfd<->kgd interface
  drm/amdkfd: Load mqd to hqd in non-HWS mode
  drm/radeon: Assign VMID to PASID for IH in non-HWS mode
  drm/amdkfd: unmap VMID<-->PASID when relesing VMID (non-HWS)

Oded Gabbay (3):
  drm/amdkfd: Do copy_to/from_user in general kfd_ioctl()
  drm/amdkfd: reformat IOCTL definitions to drm-style
  drm/amdkfd: rewrite kfd_ioctl() according to drm_ioctl()

 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c   | 315 +++--
 .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c  |  15 +
 drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c   |   2 +-
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h  |  18 ++
 drivers/gpu/drm/amd/include/kgd_kfd_interface.h|   2 +-
 drivers/gpu/drm/radeon/cikd.h  |   2 +
 drivers/gpu/drm/radeon/radeon_kfd.c|  11 +-
 include/uapi/linux/kfd_ioctl.h |  37 ++-
 8 files changed, 235 insertions(+), 167 deletions(-)

i915: regression: after DP connected monitor is turned off, when turned on, it does not work anymore

[Jiri Pirko]

Mon, Dec 29, 2014 at 10:04:50AM CET, jani.nikula at linux.intel.com wrote:
>On Sat, 27 Dec 2014, Jiri Pirko  wrote:
>> Please let me know if you need me to provide any other info. I'm eager to
>> test patches.
>
>Please file a bug at [1] to ensure this doesn't get lost. Holiday season
>and all. Please reference this thread, and attach dmesg with
>drm.debug=14 module parameter set, reproducing the issue.
>
>Please also give drm-intel-nightly branch of [2] a try, although I don't
>immediately recall any specific fixes that might address your issue.
>
>Thanks,
>Jani.
>
>[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel
>[2] http://cgit.freedesktop.org/drm-intel


Hi Jani.

Thanks for reply and sorry for the delay (vacation).

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

Let me know if I can do anything more.

Thanks!

Jiri

[PULL] amdkfd-fixes

[Oded Gabbay]

On 01/06/2015 07:09 PM, Oded Gabbay wrote:
> Hi Dave,
>
> Here are a couple of bug fixes for the non-HWS path (used for bring-ups and
> debugging purposes only).
>
> Our QA team run a test on -rc2 and didn't discover any regressions,
> so I don't expect an additionl pull request for 3.19 unless something
> unexpected will pop-up.
Oops, sorry, but I forgot I have an important patch-set regarding fixing the 
IOCTL error handling as you asked me to do. Christian is still reviewing it but 
I definitely want it to be in 3.19 as that patch changes the IOCTLs.

Oded

>
>   Oded
>
> The following changes since commit 2f6bd4da08b5054ba933be6f7b17ed02ad6c4162:
>
>Merge tag 'amdkfd-fixes-2014-12-30' of 
> git://people.freedesktop.org/~gabbayo/linux into linus (2015-01-04 17:44:43 
> +1000)
>
> are available in the git repository at:
>
>
>git://people.freedesktop.org/~gabbayo/linux tags/amdkfd-fixes-2015-01-06
>
> for you to fetch changes up to 2030664b709caa769f2b6a1d2e71d8cb343c6884:
>
>drm/amdkfd: unmap VMID<-->PASID when relesing VMID (non-HWS) (2015-01-05 
> 15:48:28 +0200)
>
> 
> Alexey Khoroshilov (1):
>drm/radeon: do not leave queue acquired if timeout happens in 
> kgd_hqd_destroy()
>
> Ben Goz (4):
>drm/amd: Fixing typos in kfd<->kgd interface
>drm/amdkfd: Load mqd to hqd in non-HWS mode
>drm/radeon: Assign VMID to PASID for IH in non-HWS mode
>drm/amdkfd: unmap VMID<-->PASID when relesing VMID (non-HWS)
>
>   drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 15 +++
>   drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c  |  2 +-
>   drivers/gpu/drm/amd/include/kgd_kfd_interface.h   |  2 +-
>   drivers/gpu/drm/radeon/cikd.h |  2 ++
>   drivers/gpu/drm/radeon/radeon_kfd.c   | 11 ---
>   5 files changed, 27 insertions(+), 5 deletions(-)
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PULL] amdkfd-fixes

[Oded Gabbay]

Hi Dave,

Here are a couple of bug fixes for the non-HWS path (used for bring-ups and 
debugging purposes only). 

Our QA team run a test on -rc2 and didn't discover any regressions, 
so I don't expect an additionl pull request for 3.19 unless something 
unexpected will pop-up.

Oded

The following changes since commit 2f6bd4da08b5054ba933be6f7b17ed02ad6c4162:

  Merge tag 'amdkfd-fixes-2014-12-30' of 
git://people.freedesktop.org/~gabbayo/linux into linus (2015-01-04 17:44:43 
+1000)

are available in the git repository at:


  git://people.freedesktop.org/~gabbayo/linux tags/amdkfd-fixes-2015-01-06

for you to fetch changes up to 2030664b709caa769f2b6a1d2e71d8cb343c6884:

  drm/amdkfd: unmap VMID<-->PASID when relesing VMID (non-HWS) (2015-01-05 
15:48:28 +0200)


Alexey Khoroshilov (1):
  drm/radeon: do not leave queue acquired if timeout happens in 
kgd_hqd_destroy()

Ben Goz (4):
  drm/amd: Fixing typos in kfd<->kgd interface
  drm/amdkfd: Load mqd to hqd in non-HWS mode
  drm/radeon: Assign VMID to PASID for IH in non-HWS mode
  drm/amdkfd: unmap VMID<-->PASID when relesing VMID (non-HWS)

 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 15 +++
 drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c  |  2 +-
 drivers/gpu/drm/amd/include/kgd_kfd_interface.h   |  2 +-
 drivers/gpu/drm/radeon/cikd.h |  2 ++
 drivers/gpu/drm/radeon/radeon_kfd.c   | 11 ---
 5 files changed, 27 insertions(+), 5 deletions(-)

[PATCH 1/2] drm/radeon: Assign VMID to PASID for IH in non-HWS mode

[Oded Gabbay]

On 01/05/2015 08:41 PM, Alex Deucher wrote:
> On Mon, Jan 5, 2015 at 8:52 AM, Oded Gabbay  wrote:
>> From: Ben Goz 
>>
>> This patch fixes a bug in kgd_set_pasid_vmid_mapping(), where the function
>> only updated the ATC registers (IOMMU) with the new VMID <--> PASID mapping,
>> but didn't update the IH (Interrupt) registers.
>>
>> The bug only occurs when using non-HWS mode. In HWS mode, the CP 
>> automatically
>> does the VMID <--> PASID mapping.
>>
>> Signed-off-by: Ben Goz 
>> Signed-off-by: Oded Gabbay 
>
> I'm not too familiar with how these registers work.  I'm assuming they
> are just scratch registers that either the fw or the driver has to
> update depending on the scheduling model?  For the series:
>
> Acked-by: Alex Deucher 
>
Yes, those registers need to be updated by the driver, if we are working in 
non-HWS mode, or by the fw, if we are working in HWS mode, which is the default 
mode and the "production" mode.

Oded

>> ---
>>   drivers/gpu/drm/radeon/cikd.h   | 2 ++
>>   drivers/gpu/drm/radeon/radeon_kfd.c | 4 
>>   2 files changed, 6 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/radeon/cikd.h b/drivers/gpu/drm/radeon/cikd.h
>> index ba85986..03003f8 100644
>> --- a/drivers/gpu/drm/radeon/cikd.h
>> +++ b/drivers/gpu/drm/radeon/cikd.h
>> @@ -2156,4 +2156,6 @@
>>   #define ATC_VM_APERTURE1_HIGH_ADDR 0x330Cu
>>   #define ATC_VM_APERTURE1_LOW_ADDR  0x3304u
>>
>> +#define IH_VMID_0_LUT  0x3D40u
>> +
>>   #endif
>> diff --git a/drivers/gpu/drm/radeon/radeon_kfd.c 
>> b/drivers/gpu/drm/radeon/radeon_kfd.c
>> index a55afba..8bf87f1 100644
>> --- a/drivers/gpu/drm/radeon/radeon_kfd.c
>> +++ b/drivers/gpu/drm/radeon/radeon_kfd.c
>> @@ -390,6 +390,10 @@ static int kgd_set_pasid_vmid_mapping(struct kgd_dev 
>> *kgd, unsigned int pasid,
>>  cpu_relax();
>>  write_register(kgd, ATC_VMID_PASID_MAPPING_UPDATE_STATUS, 1U << 
>> vmid);
>>
>> +   /* Mapping vmid to pasid also for IH block */
>> +   write_register(kgd, IH_VMID_0_LUT + vmid * sizeof(uint32_t),
>> +   pasid_mapping);
>> +
>>  return 0;
>>   }
>>
>> --
>> 1.9.1
>>

[PULL] amdkfd-fixes

[Christian König]

Am 06.01.2015 um 18:18 schrieb Oded Gabbay:
>
>
> On 01/06/2015 07:09 PM, Oded Gabbay wrote:
>> Hi Dave,
>>
>> Here are a couple of bug fixes for the non-HWS path (used for 
>> bring-ups and
>> debugging purposes only).
>>
>> Our QA team run a test on -rc2 and didn't discover any regressions,
>> so I don't expect an additionl pull request for 3.19 unless something
>> unexpected will pop-up.
> Oops, sorry, but I forgot I have an important patch-set regarding 
> fixing the IOCTL error handling as you asked me to do. Christian is 
> still reviewing it but I definitely want it to be in 3.19 as that 
> patch changes the IOCTLs.

Still haven't found time to look closer into it. But feel free to send 
it out cause the general approach sounded good and it is Acked-by: 
Christian König 

Regards,
Christian.

>
> Oded
>
>>
>> Oded
>>
>> The following changes since commit 
>> 2f6bd4da08b5054ba933be6f7b17ed02ad6c4162:
>>
>>Merge tag 'amdkfd-fixes-2014-12-30' of 
>> git://people.freedesktop.org/~gabbayo/linux into linus (2015-01-04 
>> 17:44:43 +1000)
>>
>> are available in the git repository at:
>>
>>
>>git://people.freedesktop.org/~gabbayo/linux 
>> tags/amdkfd-fixes-2015-01-06
>>
>> for you to fetch changes up to 2030664b709caa769f2b6a1d2e71d8cb343c6884:
>>
>>drm/amdkfd: unmap VMID<-->PASID when relesing VMID (non-HWS) 
>> (2015-01-05 15:48:28 +0200)
>>
>> 
>> Alexey Khoroshilov (1):
>>drm/radeon: do not leave queue acquired if timeout happens in 
>> kgd_hqd_destroy()
>>
>> Ben Goz (4):
>>drm/amd: Fixing typos in kfd<->kgd interface
>>drm/amdkfd: Load mqd to hqd in non-HWS mode
>>drm/radeon: Assign VMID to PASID for IH in non-HWS mode
>>drm/amdkfd: unmap VMID<-->PASID when relesing VMID (non-HWS)
>>
>>   drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 15 
>> +++
>>   drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c  |  2 +-
>>   drivers/gpu/drm/amd/include/kgd_kfd_interface.h   |  2 +-
>>   drivers/gpu/drm/radeon/cikd.h |  2 ++
>>   drivers/gpu/drm/radeon/radeon_kfd.c   | 11 ---
>>   5 files changed, 27 insertions(+), 5 deletions(-)
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

"EDID checksum is invalid"

[Linus Torvalds]

So my el-cheapo UHD Dell monitor is unhappy with dmps, and just never
wakes up from it.

I work around it with just doing "xset -dpms" and it's not a big deal,
but I thought I'd report it anyway, since there are actual debug
messages, and maybe there's a better way to handle it. Does anybody
have any idea of why it would do this:

   [drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid,
remainder is 111
   Raw EDID:
00 ff ff ff ff ff ff 00 10 ac 5c f0 4d 54 31 41
24 18 01 03 80 3e 22 78 ea 0a a5 a2 57 4f a2 28
0f 50 54 a5 4b 00 71 4f 81 00 81 80 a9 40 b3 00
d1 c0 d1 00 7f ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

   [drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid,
remainder is 240
   Raw EDID:
00 ff ff ff ff ff ff 00 10 ac 5c f0 4d 54 31 41
24 18 01 03 80 3e 22 78 ea 0a a5 a2 57 4f a2 28
0f 50 54 a5 4b 00 71 4f 81 00 81 87 ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

   [drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid,
remainder is 35
   Raw EDID:
00 ff ff ff ff ff ff 00 10 ac 5c f0 4d 54 31 41
24 18 01 03 80 3e 22 78 ea 0a a5 a2 57 4f a2 28
0f 50 54 a5 4b 00 71 4f 81 00 81 80 a9 40 b3 00
d1 c7 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

   [drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid,
remainder is 212
   Raw EDID:
00 ff ff ff ff ff ff 00 10 ac 5c f0 4d 54 31 41
24 18 01 03 80 3e 22 78 ea 0a a5 a2 57 4f a2 28
0f 50 54 a5 4b 00 71 4f 81 00 81 80 a9 40 ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

it looks like the beginning is the same, but then it just turns to all
ones at a random point (even *within* a byte).

Does anything spring to mind?

 Linus

[PATCH v18 0/12] dw-hdmi: convert imx hdmi to bridge/dw_hdmi

[Philipp Zabel]

Hi Heiko,

Am Dienstag, den 06.01.2015, 12:49 +0100 schrieb Heiko Stübner:
> Hi Philipp,
> 
> Am Samstag, 6. Dezember 2014, 00:31:46 schrieb Andy Yan:
> > > I am happy with the series so far. Pending Acks from the device tree
> > > maintainers for the new binding documents, I'd like to apply either the
> > > whole of it on top of
> > > 
> > >  git://git.pengutronix.de/git/pza/linux.git imx-drm/next
> > > 
> > > or take at least the i.MX specific patches (1-5) because of the
> > > dependency on the imx-drm OF helper conversion.
> 
> do you still want to take this series?
>
> As for the devicetree ACK, there is this (unwritten) rule that if the
> dt-maintainers do not respond after 3 weeks (and a ping mail to them)
> it should be considered acked. As this version of the series is sitting
> on the lists for a month now and nobody complained during the other
> 17 versions as well, I think we should be on the safe side :-)

Alright, let's assume silent approval.

> There is one slight catch. Patch 3 needs a little modification, as the
> THIS_MODULE ower of the imx_hdmi got meanwhile cleaned up.
> 
> So the patch would need to be modified as shown by the diff at the
> bottom. I'm not sure if you want Andy to repost the whole series again
> but I'll just post my fixed variant as reply to the origin v18 of patch 3
> for convenience.

No need to post this again, I can apply the patches and fix up the
remaining issues you and Russell pointed out in the process.

regards
Philipp

[PATCH v9 0/2] drm: add support for Atmel HLCDC Display Controller

[Nicolas Ferre]

Le 06/01/2015 12:35, Boris Brezillon a écrit :
> Hi Dave,
> 
> As I already said here [1], I'd really like to have the Atmel HLCDC driver
> merged in 3.20 (it's already floating around for quite some time now).
> So, unless someone complain about this version, I plan to send a PR soon,
> is that okay for you ?
> Please note that this series depends on [1] (which I can also include in my
> PR).
> 
> Here comes the usual description:
> 
> This patch series adds support for the Atmel HLCDC Display Controller
> embedded in the HLCDC block.
> 
> The drivers supports basic CRTC functionalities, several overlays and
> provides an hardware cursor.
> 
> At the moment, it only supports connection to LCD panels through an RGB
> connector (defined as an LVDS connector in my implementation), though
> connection to other kind of devices (like DRM bridges) could be added later.
> 
> It also supports several RGB formats on all planes and some YUV formats on
> the HEO overlay plane.
> 
> Best Regards,
> 
> Boris
> 
> [1]https://lkml.org/lkml/2015/1/6/171
> 
> Changes since v8:
>  - remove dependency on this series https://lkml.org/lkml/2014/11/16/12
>(which did not make it into 3.19) to avoid cross subsystem dependency
>issues
> 
> Changes since v7:
>  - split MFD, PWM and Display Controller drivers in several patch series
>  - fix inline documentation (suggested by Nicolas)
>  - fix DMA BURST LEN config (suggested by Nicolas)
>  - call load and unload in probe and remove functions instead of setting
>them in drm_driver struct
> 
> Changes since v6:
> - move interrupts property from hlcdc display controller node to its
>   parent node (the MFD device)
> - add mode_set_base implementation
> - rework page flip handling to rely on vblank events instead of DMA
>   transfer events (the end of a DMA transfer does not mean the frame
>   is actually flipped: data are first copied to an output FIFO before
>   being sent on the RGB/DPI connector)
> - few minor coding style fixes
> 
> Changes since v5:
> - fix Kconfig dependency bug
> - use adjusted mode in crtc config
> - move signal config (clk, hsync, vsync) from connector to crtc mode_set
>   function
> - use standard rotation property
> - check display_mode validity in connecto mode_valid function
> - remove dma_set_coherent mask call (now done in MFD core)
> - do not use drm_platform_init
> 
> Changes since v4:
> - fix a few more bugs in rotation handling (rotation was buggy on some
>   formats)
> - return connector_status_unknown until a panel is exposed by the
>   drm_panel infrastructure (prevent fbdev creation until everyting is
>   in place)
> - rework Kconfig MFD_ATMEL_HLCDC selection to simplify the configuration
>   (automatically select this option when selecting the HLCDC PMW or DRM
>   driver, instead of depending on this option)
> 
> Changes since v3:
> - rework the layer code to simplify several parts (locking and layer
>   disabling)
> - make use of the drm_flip_work infrastructure
> - rely on default HW cursor implementation using on the cursor plane
> - rework the display controller DT bindings (based on OF graph
>   representation)
> - add rotation support
> - retrieve RGB bus format from drm_display_info
> - drop the dynamic pinctrl state selection
> - rework HLCDC output handling (previously specialized to interface
>   with LCD panels)
> - drop ".module = THIS_MODULE" lines
> - change display controller compatible string
> 
> Changes since v2:
> - fix coding style issues (macro indentation)
> - make use of GENMASK in several places
> - declare regmap config as a static structure
> - rework hlcdc plane update API
> - rework cursor handling to make use of the new plane update API
> - fix backporch config
> - do not use devm_regmap_init_mmio_clk to avoid extra clk_enable
>   clk disable calls when accessing registers
> - explicitly include regmap and clk headers instead of relying on
>   atmel-hlcdc.h inclusions
> - make the atmel-hlcdc driver depends on CONFIG_OF
> - separate DT bindings documentation from driver implementation
> - support several pin muxing for HLCDC pins on sama5d3 SoCs
> 
> Changes since v1:
> - replace the backlight driver by a PWM driver
> - make use of drm_panel infrastructure
> - split driver code in several subsystem: MFD, PWM and DRM
> - add support for overlays
> - add support for hardware cursor
> 
> 
> Boris Brezillon (2):
>   drm: add Atmel HLCDC Display Controller support
>   drm: add DT bindings documentation for atmel-hlcdc-dc driver

Boris, David,

I realize that I already gave my acknowledgement to this driver for the
v7 revision. It was before it is split.
For the record, here is my review and the message:
https://lkml.org/lkml/2014/10/8/219

As I had said:
"I'm absolutely not an expert in DRM drivers" but here is my:

Acked-by: Nicolas Ferre 

On the driver and associated DT binding.

Thanks, bye,


>  .../devicetree/bindings/drm/atmel/hlcdc-dc.txt |  53 ++
>  drivers/gpu/drm/Kconfig

[PATCH RESEND 1/2] exynos: Don't use DRM_EXYNOS_GEM_{MAP_OFFSET/MMAP} ioctls

[Hyungwon Hwang]

+CC Rob clark

I sent these patches about a month ago, but could not get any response.
Can you review these patches? You can find the whole patch set from

https://patchwork.kernel.org/patch/5478981/
https://patchwork.kernel.org/patch/5478991/


On Fri, 12 Dec 2014 14:44:39 +0900
Hyungwon Hwang  wrote:

> The ioctl DRM_EXYNOS_GEM_MAP_OFFSET and DRM_EXYNOS_GEM_MMAP are
> removed from the linux kernel. This patch modifies libdrm and libkms
> to use drm generic ioctls instead of the removed ioctls.
> 
> Signed-off-by: Hyungwon Hwang 
> Signed-off-by: Inki Dae 
> ---
>  exynos/exynos_drm.c | 24 +---
>  libkms/exynos.c |  7 ---
>  2 files changed, 17 insertions(+), 14 deletions(-)
> 
> diff --git a/exynos/exynos_drm.c b/exynos/exynos_drm.c
> index 4c7dd13..4cb6a6d 100644
> --- a/exynos/exynos_drm.c
> +++ b/exynos/exynos_drm.c
> @@ -283,20 +283,22 @@ drm_public void *exynos_bo_map(struct exynos_bo
> *bo) {
>   if (!bo->vaddr) {
>   struct exynos_device *dev = bo->dev;
> - struct drm_exynos_gem_mmap req = {
> - .handle = bo->handle,
> - .size   = bo->size,
> - };
> + struct drm_mode_map_dumb arg;
> + void *map = NULL;
>   int ret;
>  
> - ret = drmIoctl(dev->fd, DRM_IOCTL_EXYNOS_GEM_MMAP,
> );
> - if (ret) {
> - fprintf(stderr, "failed to mmap[%s].\n",
> - strerror(errno));
> - return NULL;
> - }
> + memset(, 0, sizeof(arg));
> + arg.handle = bo->handle;
> +
> + ret = drmIoctl(dev->fd, DRM_IOCTL_MODE_MAP_DUMB,
> );
> + if (ret)
> + return ret;
>  
> - bo->vaddr = (void *)(uintptr_t)req.mapped;
> + map = drm_mmap(0, bo->size, PROT_READ | PROT_WRITE,
> MAP_SHARED,
> + dev->fd, arg.offset);
> +
> + if (map == MAP_FAILED)
> + return NULL;
>   }
>  
>   return bo->vaddr;
> diff --git a/libkms/exynos.c b/libkms/exynos.c
> index 92e329c..1123482 100644
> --- a/libkms/exynos.c
> +++ b/libkms/exynos.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include "xf86drm.h"
>  
> +#include "libdrm.h"
>  #include "exynos_drm.h"
>  
>  struct exynos_bo
> @@ -124,7 +125,7 @@ static int
>  exynos_bo_map(struct kms_bo *_bo, void **out)
>  {
>   struct exynos_bo *bo = (struct exynos_bo *)_bo;
> - struct drm_exynos_gem_map_off arg;
> + struct drm_mode_map_dumb arg;
>   void *map = NULL;
>   int ret;
>  
> @@ -137,11 +138,11 @@ exynos_bo_map(struct kms_bo *_bo, void **out)
>   memset(, 0, sizeof(arg));
>   arg.handle = bo->base.handle;
>  
> - ret = drmCommandWriteRead(bo->base.kms->fd,
> DRM_EXYNOS_GEM_MAP_OFFSET, , sizeof(arg));
> + ret = drmIoctl(bo->base.kms->fd, DRM_IOCTL_MODE_MAP_DUMB,
> ); if (ret)
>   return ret;
>  
> - map = mmap(0, bo->base.size, PROT_READ | PROT_WRITE,
> MAP_SHARED, bo->base.kms->fd, arg.offset);
> + map = drm_mmap(0, bo->base.size, PROT_READ | PROT_WRITE,
> MAP_SHARED, bo->base.kms->fd, arg.offset); if (map == MAP_FAILED)
>   return -errno;
>  

Best regards,
Hyungwon Hwang

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #10 from Christian König  ---
(In reply to Gustaw Smolarczyk from comment #9)
> Created attachment 162601 [details]
> /proc/interrupts on 3.17.4
> 
> I have attached the contents of /proc/interrupts on 3.17.4. Should I attach
> one with a faulty kernel too?

No, all I wanted to check is that interrupts work as expected. And that indeed
seems to be the case here:

 26:  40191  12200   8939   6450  22186  15970  
9307   6821   PCI-MSI-edge  radeon

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

[RFC PATCH v3 4/4] tests/drv_module_reload: add ipvr support

[Cheng, Yao]

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Monday, January 5, 2015 16:40
> To: Cheng, Yao
> Cc: Daniel Vetter; Thierry Reding; intel-gfx at lists.freedesktop.org; dri-
> devel at lists.freedesktop.org; Kelley, Sean V; Chehab, John;
> emil.l.velikov at gmail.com; Jiang, Fei; Beckett, Robert; Barbalho, Rafael
> Subject: Re: [RFC PATCH v3 4/4] tests/drv_module_reload: add ipvr support
> 
> On Sun, Dec 21, 2014 at 02:40:24PM +, Cheng, Yao wrote:
> > > -Original Message-
> > > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch]
> > > Sent: Thursday, December 18, 2014 19:21
> > > To: Thierry Reding
> > > Cc: Cheng, Yao; intel-gfx at lists.freedesktop.org; dri-
> > > devel at lists.freedesktop.org; Kelley, Sean V; Chehab, John;
> > > emil.l.velikov at gmail.com; Jiang, Fei
> > > Subject: Re: [RFC PATCH v3 4/4] tests/drv_module_reload: add ipvr
> > > support
> > >
> > > On Thu, Dec 18, 2014 at 11:04 AM, Thierry Reding
> > > 
> > > wrote:
> > > >> I double checked the symptom and found it was a deadlock on
> > > drm_global_mutex.
> > > >> When i915_driver_load() registers the platform device while ipvr
> > > >> module
> > > is in the system, ipvr's probe() function tries to lock
> > > drm_global_mutex which was already held by i915.
> > > >> I think either of the following 2 actions need to be moved to a
> > > >> bottom half
> > > e.g. a work queue:
> > > >>   platform_device_add () call in i915_ved.c (called during
> > > i915_driver_load())
> > > >>   drm_dev_register() call during ipvr's probe() Which one
> > > >> makes more sense? pls kindly advise (I personally prefer the former
> one.).
> > > >
> > > > Yes, that's somewhat ugly, but I don't see a way around that. I'd
> > > > also think that moving platform_device_add() to a workqueue would
> > > > be the best option here.
> > >
> > > Or we simply kill drm_global_mutex for platform drivers that don't
> > > use the -
> > > >probe hook. It should work when they have a correct order betwen
> > > drm_dev_alloc and _register and all the code in between. So just
> > > ditch the -
> > > >load callback in teh ipvr driver and rework the load sequence as
> > > >suggested
> > > somewhere else and this is fixed already. No need for bottom halfs I
> think.
> >
> > Daniel, sorry I didn't quite understand "platform drivers that don't
> > use the probe hook". For initialization, the ipvr platform driver's
> > probe() is called in following 2 possible paths:
> > 1. ipvr installed before i915. In this case, ipvr's probe() is called
> > inside i915_driver_load() and falls into the drm_global_mutex dead lock.
> > 2. i915 installed before ipvr. In this case, ipvr's probe() is called
> > without drm_global_mutex held by i915 and no dead lock issue.
> > If we kill drm_global_mutex, will path 2 run into issue? And in your
> > suggestion, how to rework the load sequence? Do you mean calling
> > ipvr's
> > load() callback directly during platform driver probe()?
> 
> Hm right it's not that simple really. What we need in more detail is:
> - Move the mutex_lock(_global_mutex) out of drm_dev_register into
>   all the callers. If a driver has a ->load() callback it most likely is
>   racy with the usual load ordering issues.
> 
> - Rework ipvr to no longer have a ->load callback. Insteaed use the
>   following sequence (in the platform ->probe callback):
> 
>   drm_dev_alloc();
>   ipvr_load();
>   drm_dev_register();
> 
>   With that ordering we don't need the additional guarantees that
>   drm_global_mutex provides and we can avoid to take that lock around
>   drm_dev_registrer() call in the ipvr code.

Thanks for the detailed explanation, Daniel!
That sounds to be a small refactor on drm core, and need change many drm 
drivers: nouveau, tegra, udl.
Should it be a standalone RFC patch?

> 
> This should resolve the deadlock I hope.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 86635] Live for Speed and gallium nine, missing objects

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

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

--- Comment #7 from David Heidelberg (okias)  ---
HyperZ should be enabled by default. Wait with closing bug, until fix hit main
mesa tree.

Thanks for your report :)

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

[PATCH v18 12/12] drm: bridge/dw_hdmi: add rockchip rk3288 support

[Russell King - ARM Linux]

On Thu, Dec 11, 2014 at 12:24:15PM +0100, Heiko Stübner wrote:
> Past practices suggest that having the dw in the name is a sane solution too, 
> like in dw_mmc-foo (mmc/host), dwmac-foo (net/ethernet/stmicro/stmmac).
> 
> And personally I'd keep to this already established naming scheme ... i.e. 
> not 
> hiding the dw heritage.
> 
> And also it looks like other involved parties like Philipp and Russell seemed 
> to be ok with the naming through the revisions till now.

I don't have much of a preference when it comes to this.  I was disappointed
that the original imx-hdmi driver did not use "dw" in its filename, as the
documentation clearly stated in several places that it was a designware
part, and as we all know, they're a company which sells IP, so their
designs are going to crop up in different places.

So I welcome this patch set - and I've also tested it on a SolidRun
Hummingboard i2ex along with all my CEC and audio patches, where it
seems to be fine.  So for the set:

Tested-by: Russell King 

Apart from the two minor items I've pointed out in separate replies:

Acked-by: Russell King 

Thanks.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #9 from Gustaw Smolarczyk  ---
Created attachment 162601
  --> https://bugzilla.kernel.org/attachment.cgi?id=162601=edit
/proc/interrupts on 3.17.4

I have attached the contents of /proc/interrupts on 3.17.4. Should I attach one
with a faulty kernel too?

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

[Bug 90741] Radeon: System pauses on TAHITI

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

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

Christian König  changed:

   What|Removed |Added

 CC||deathsimple at vodafone.de

--- Comment #8 from Christian König  ---
Just a shot into the dark, but can you please post the content of
/proc/interrupts.

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

[PATCH v18 04/12] drm: imx: imx-hdmi: split phy configuration to platform driver

[Russell King - ARM Linux]

On Fri, Dec 05, 2014 at 02:25:50PM +0800, Andy Yan wrote:
> hdmi phy configuration is platform specific, which can be adusted

Minor typo: adjusted

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

[PATCH v18.1 03/12] drm: imx: imx-hdmi: convert imx-hdmi to drm_bridge mode

[Russell King - ARM Linux]

On Tue, Jan 06, 2015 at 12:52:24PM +0100, Heiko Stübner wrote:
> +static void imx_hdmi_bridge_nope(struct drm_bridge *bridge)

"_nope" ?  As in "No"?  Or should this be "_nop" for no-operation ?

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #7 from Gustaw Smolarczyk  ---
Unfortunately, it was a false lead. Disabling iGPU didn't help in any way on
3.18.1.

Additionally, I take back the "less pauses in 3.18.0 and later" thing. 3.18.1
was horrible just now (same as any kernel after the commit bisected).

Is there any way I can help investigating it more?

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

[PATCH v18.1 03/12] drm: imx: imx-hdmi: convert imx-hdmi to drm_bridge mode

[Heiko Stübner]

From: Andy Yan 

IMX6 and Rockchip RK3288 and JZ4780 (Ingenic Xburst/MIPS)
use the interface compatible Designware HDMI IP, but they
also have some lightly differences, such as phy pll configuration,
register width, 4K support, clk useage, and the crtc mux configuration
is also platform specific.

To reuse the imx hdmi driver, convert it to drm_bridge

handle encoder in imx-hdmi_pltfm.c, as most of the encoder
operation are platform specific such as crtc select and
panel format set

This patch depends on Russell King's patch:
 drm: imx: convert imx-drm to use the generic DRM OF helper
 
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2014-July/053484.html

Signed-off-by: Andy Yan 
Signed-off-by: Yakir Yang 

---
Changes in v18.1:
- adapt to THIS_MODULE cleanup

Changes in v18:
- remove a multiple blank lines in imx-hdmi.c
- fix a checkpatch warning in imx-hdmi_pltfm.c

Changes in v17:
- remove platform device stuff, adviced by Russell King

Changes in v16:
- use the common binding for the clocks

Changes in v15: None
Changes in v14:
- add defer probing, adviced by Philipp Zabel

Changes in v13:
- split platform specific phy configuration

Changes in v12:
- squash patch 

Changes in v11:
- squash patch  

Changes in v10:
- split generic dw_hdmi.c improvements from patch#11 (add rk3288 support)

Changes in v9: None
Changes in v8: None
Changes in v7:
- remove unused variables from structure dw_hdmi
- remove a wrong modification
- add copyrights for dw_hdmi-imx.c

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

 drivers/gpu/drm/imx/Makefile |   2 +-
 drivers/gpu/drm/imx/imx-hdmi.c   | 258 +--
 drivers/gpu/drm/imx/imx-hdmi.h   |  15 ++
 drivers/gpu/drm/imx/imx-hdmi_pltfm.c | 203 +++
 4 files changed, 315 insertions(+), 163 deletions(-)
 create mode 100644 drivers/gpu/drm/imx/imx-hdmi_pltfm.c

diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
index 582c438..63cf56a 100644
--- a/drivers/gpu/drm/imx/Makefile
+++ b/drivers/gpu/drm/imx/Makefile
@@ -9,4 +9,4 @@ obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o

 imx-ipuv3-crtc-objs  := ipuv3-crtc.o ipuv3-plane.o
 obj-$(CONFIG_DRM_IMX_IPUV3)+= imx-ipuv3-crtc.o
-obj-$(CONFIG_DRM_IMX_HDMI) += imx-hdmi.o
+obj-$(CONFIG_DRM_IMX_HDMI) += imx-hdmi.o imx-hdmi_pltfm.o
diff --git a/drivers/gpu/drm/imx/imx-hdmi.c b/drivers/gpu/drm/imx/imx-hdmi.c
index 7a54d20..d72f82c 100644
--- a/drivers/gpu/drm/imx/imx-hdmi.c
+++ b/drivers/gpu/drm/imx/imx-hdmi.c
@@ -12,25 +12,20 @@
  * Copyright (C) 2010, Guennadi Liakhovetski 
  */

-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
 #include 

+#include 
 #include 
 #include 
 #include 
 #include 
-#include 

 #include "imx-hdmi.h"
-#include "imx-drm.h"

 #define HDMI_EDID_LEN  512

@@ -54,11 +49,6 @@ enum hdmi_datamap {
YCbCr422_12B = 0x12,
 };

-enum imx_hdmi_devtype {
-   IMX6Q_HDMI,
-   IMX6DL_HDMI,
-};
-
 static const u16 csc_coeff_default[3][4] = {
{ 0x2000, 0x, 0x, 0x },
{ 0x, 0x2000, 0x, 0x },
@@ -113,7 +103,8 @@ struct hdmi_data_info {

 struct imx_hdmi {
struct drm_connector connector;
-   struct drm_encoder encoder;
+   struct drm_encoder *encoder;
+   struct drm_bridge *bridge;

enum imx_hdmi_devtype dev_type;
struct device *dev;
@@ -121,6 +112,7 @@ struct imx_hdmi {
struct clk *iahb_clk;

struct hdmi_data_info hdmi_data;
+   const struct imx_hdmi_plat_data *plat_data;
int vic;

u8 edid[HDMI_EDID_LEN];
@@ -137,13 +129,6 @@ struct imx_hdmi {
int ratio;
 };

-static void imx_hdmi_set_ipu_di_mux(struct imx_hdmi *hdmi, int ipu_di)
-{
-   regmap_update_bits(hdmi->regmap, IOMUXC_GPR3,
-  IMX6Q_GPR3_HDMI_MUX_CTL_MASK,
-  ipu_di << IMX6Q_GPR3_HDMI_MUX_CTL_SHIFT);
-}
-
 static inline void hdmi_writeb(struct imx_hdmi *hdmi, u8 val, int offset)
 {
writeb(val, hdmi->regs + offset);
@@ -1371,6 +1356,50 @@ static void imx_hdmi_poweroff(struct imx_hdmi *hdmi)
imx_hdmi_phy_disable(hdmi);
 }

+static void imx_hdmi_bridge_mode_set(struct drm_bridge *bridge,
+struct drm_display_mode *mode,
+struct drm_display_mode *adjusted_mode)
+{
+   struct imx_hdmi *hdmi = bridge->driver_private;
+
+   imx_hdmi_setup(hdmi, mode);
+
+   /* Store the display mode for plugin/DKMS poweron events */
+   memcpy(>previous_mode, mode, sizeof(hdmi->previous_mode));
+}
+
+static bool imx_hdmi_bridge_mode_fixup(struct drm_bridge *bridge,
+  const struct drm_display_mode *mode,
+  struct drm_display_mode *adjusted_mode)
+{
+   return true;
+}
+
+static void imx_hdmi_bridge_disable(struct 

[PATCH v18 0/12] dw-hdmi: convert imx hdmi to bridge/dw_hdmi

[Heiko Stübner]

Hi Philipp,

Am Samstag, 6. Dezember 2014, 00:31:46 schrieb Andy Yan:
> > I am happy with the series so far. Pending Acks from the device tree
> > maintainers for the new binding documents, I'd like to apply either the
> > whole of it on top of
> > 
> >  git://git.pengutronix.de/git/pza/linux.git imx-drm/next
> > 
> > or take at least the i.MX specific patches (1-5) because of the
> > dependency on the imx-drm OF helper conversion.

do you still want to take this series?

As for the devicetree ACK, there is this (unwritten) rule that if the
dt-maintainers do not respond after 3 weeks (and a ping mail to them)
it should be considered acked. As this version of the series is sitting
on the lists for a month now and nobody complained during the other
17 versions as well, I think we should be on the safe side :-)

There is one slight catch. Patch 3 needs a little modification, as the
THIS_MODULE ower of the imx_hdmi got meanwhile cleaned up.

So the patch would need to be modified as shown by the diff at the
bottom. I'm not sure if you want Andy to repost the whole series again
but I'll just post my fixed variant as reply to the origin v18 of patch 3
for convenience.


Heiko

-- 8< 
--- "[PATCH v18 03_12] drm_imx_imx-hdmi_convert imx-hdmi to drm_bridge 
mode.mbox.old"   2015-01-06 12:33:52.0 +0100
+++ "[PATCH v18 03_12] drm_imx_imx-hdmi_convert imx-hdmi to drm_bridge 
mode.mbox"   2015-01-04 22:17:20.0 +0100
@@ -511,7 +511,7 @@
  {
struct imx_hdmi *hdmi = dev_get_drvdata(dev);

-@@ -1723,42 +1682,17 @@ static void imx_hdmi_unbind(struct device *dev, struct 
device *master,
+@@ -1723,41 +1682,17 @@ static void imx_hdmi_unbind(struct device *dev, struct 
device *master,
hdmi_writeb(hdmi, ~0, HDMI_IH_MUTE_PHY_STAT0);

hdmi->connector.funcs->destroy(>connector);
@@ -544,7 +544,6 @@
 -  .remove = imx_hdmi_platform_remove,
 -  .driver = {
 -  .name = "imx-hdmi",
--  .owner = THIS_MODULE,
 -  .of_match_table = imx_hdmi_dt_ids,
 -  },
 -};

[PATCH v9 2/2] drm: add DT bindings documentation for atmel-hlcdc-dc driver

[Boris Brezillon]

The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
controller device.

The HLCDC block provides a single RGB output port, and only supports LCD
panels connection to LCD panels for now.

The atmel,panel property link the HLCDC RGB output with the LCD panel
connected on this port (note that the HLCDC RGB connector implementation
makes use of the DRM panel framework).

Connection to other external devices (DRM bridges) might be added later by
mean of a new atmel,xxx (atmel,bridge) property.

Signed-off-by: Boris Brezillon 
---
 .../devicetree/bindings/drm/atmel/hlcdc-dc.txt | 53 ++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/drm/atmel/hlcdc-dc.txt

diff --git a/Documentation/devicetree/bindings/drm/atmel/hlcdc-dc.txt 
b/Documentation/devicetree/bindings/drm/atmel/hlcdc-dc.txt
new file mode 100644
index 000..ebc1a91
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/atmel/hlcdc-dc.txt
@@ -0,0 +1,53 @@
+Device-Tree bindings for Atmel's HLCDC (High LCD Controller) DRM driver
+
+The Atmel HLCDC Display Controller is subdevice of the HLCDC MFD device.
+See ../mfd/atmel-hlcdc.txt for more details.
+
+Required properties:
+ - compatible: value should be "atmel,hlcdc-display-controller"
+ - pinctrl-names: the pin control state names. Should contain "default".
+ - pinctrl-0: should contain the default pinctrl states.
+ - #address-cells: should be set to 1.
+ - #size-cells: should be set to 0.
+
+Required children nodes:
+ Children nodes are encoding available output ports and their connections
+ to external devices using the OF graph reprensentation (see ../graph.txt).
+ At least one port node is required.
+
+Example:
+
+   hlcdc: hlcdc at f003 {
+   compatible = "atmel,sama5d3-hlcdc";
+   reg = <0xf003 0x2000>;
+   interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>;
+   clocks = <_clk>, <>, <>;
+   clock-names = "periph_clk","sys_clk", "slow_clk";
+   status = "disabled";
+
+   hlcdc-display-controller {
+   compatible = "atmel,hlcdc-display-controller";
+   pinctrl-names = "default";
+   pinctrl-0 = <_lcd_base _lcd_rgb888>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   hlcdc_panel_output: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <_input>;
+   };
+   };
+   };
+
+   hlcdc_pwm: hlcdc-pwm {
+   compatible = "atmel,hlcdc-pwm";
+   pinctrl-names = "default";
+   pinctrl-0 = <_lcd_pwm>;
+   #pwm-cells = <3>;
+   };
+   };
-- 
1.9.1

[PATCH v9 1/2] drm: add Atmel HLCDC Display Controller support

[Boris Brezillon]

The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
controller device.

This display controller supports at least one primary plane and might
provide several overlays and an hardware cursor depending on the IP
version.

At the moment, this driver only implements an RGB connector to interface
with LCD panels, but support for other kind of external devices might be
added later.

Signed-off-by: Boris Brezillon 
Reviewed-by: Rob Clark 
Tested-by: Anthony Harivel 
Tested-by: Ludovic Desroches 
---
 drivers/gpu/drm/Kconfig  |   2 +
 drivers/gpu/drm/Makefile |   1 +
 drivers/gpu/drm/atmel-hlcdc/Kconfig  |  11 +
 drivers/gpu/drm/atmel-hlcdc/Makefile |   7 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c   | 406 +++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 579 +++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 213 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c  | 667 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h  | 398 +++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 319 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c  | 856 +++
 11 files changed, 3459 insertions(+)
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/Kconfig
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/Makefile
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c
 create mode 100644 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index c3413b6..ea28389 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -183,6 +183,8 @@ source "drivers/gpu/drm/cirrus/Kconfig"

 source "drivers/gpu/drm/armada/Kconfig"

+source "drivers/gpu/drm/atmel-hlcdc/Kconfig"
+
 source "drivers/gpu/drm/rcar-du/Kconfig"

 source "drivers/gpu/drm/shmobile/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 66e4039..9d92ba3 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_DRM_GMA500) += gma500/
 obj-$(CONFIG_DRM_UDL) += udl/
 obj-$(CONFIG_DRM_AST) += ast/
 obj-$(CONFIG_DRM_ARMADA) += armada/
+obj-$(CONFIG_DRM_ATMEL_HLCDC)  += atmel-hlcdc/
 obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/
 obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
 obj-$(CONFIG_DRM_OMAP) += omapdrm/
diff --git a/drivers/gpu/drm/atmel-hlcdc/Kconfig 
b/drivers/gpu/drm/atmel-hlcdc/Kconfig
new file mode 100644
index 000..1a08562
--- /dev/null
+++ b/drivers/gpu/drm/atmel-hlcdc/Kconfig
@@ -0,0 +1,11 @@
+config DRM_ATMEL_HLCDC
+   tristate "DRM Support for ATMEL HLCDC Display Controller"
+   depends on DRM && OF && COMMON_CLK && MFD_ATMEL_HLCDC
+   select DRM_GEM_CMA_HELPER
+   select DRM_KMS_HELPER
+   select DRM_KMS_FB_HELPER
+   select DRM_KMS_CMA_HELPER
+   select DRM_PANEL
+   help
+ Choose this option if you have an ATMEL SoC with an HLCDC display
+ controller (i.e. at91sam9n12, at91sam9x5 family or sama5d3 family).
diff --git a/drivers/gpu/drm/atmel-hlcdc/Makefile 
b/drivers/gpu/drm/atmel-hlcdc/Makefile
new file mode 100644
index 000..10ae426
--- /dev/null
+++ b/drivers/gpu/drm/atmel-hlcdc/Makefile
@@ -0,0 +1,7 @@
+atmel-hlcdc-dc-y := atmel_hlcdc_crtc.o \
+   atmel_hlcdc_dc.o \
+   atmel_hlcdc_layer.o \
+   atmel_hlcdc_output.o \
+   atmel_hlcdc_plane.o
+
+obj-$(CONFIG_DRM_ATMEL_HLCDC)  += atmel-hlcdc-dc.o
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
new file mode 100644
index 000..0409b90
--- /dev/null
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -0,0 +1,406 @@
+/*
+ * Copyright (C) 2014 Traphandler
+ * Copyright (C) 2014 Free Electrons
+ *
+ * Author: Jean-Jacques Hiblot 
+ * Author: Boris BREZILLON 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+

[PATCH v9 0/2] drm: add support for Atmel HLCDC Display Controller

[Boris Brezillon]

Hi Dave,

As I already said here [1], I'd really like to have the Atmel HLCDC driver
merged in 3.20 (it's already floating around for quite some time now).
So, unless someone complain about this version, I plan to send a PR soon,
is that okay for you ?
Please note that this series depends on [1] (which I can also include in my
PR).

Here comes the usual description:

This patch series adds support for the Atmel HLCDC Display Controller
embedded in the HLCDC block.

The drivers supports basic CRTC functionalities, several overlays and
provides an hardware cursor.

At the moment, it only supports connection to LCD panels through an RGB
connector (defined as an LVDS connector in my implementation), though
connection to other kind of devices (like DRM bridges) could be added later.

It also supports several RGB formats on all planes and some YUV formats on
the HEO overlay plane.

Best Regards,

Boris

[1]https://lkml.org/lkml/2015/1/6/171

Changes since v8:
 - remove dependency on this series https://lkml.org/lkml/2014/11/16/12
   (which did not make it into 3.19) to avoid cross subsystem dependency
   issues

Changes since v7:
 - split MFD, PWM and Display Controller drivers in several patch series
 - fix inline documentation (suggested by Nicolas)
 - fix DMA BURST LEN config (suggested by Nicolas)
 - call load and unload in probe and remove functions instead of setting
   them in drm_driver struct

Changes since v6:
- move interrupts property from hlcdc display controller node to its
  parent node (the MFD device)
- add mode_set_base implementation
- rework page flip handling to rely on vblank events instead of DMA
  transfer events (the end of a DMA transfer does not mean the frame
  is actually flipped: data are first copied to an output FIFO before
  being sent on the RGB/DPI connector)
- few minor coding style fixes

Changes since v5:
- fix Kconfig dependency bug
- use adjusted mode in crtc config
- move signal config (clk, hsync, vsync) from connector to crtc mode_set
  function
- use standard rotation property
- check display_mode validity in connecto mode_valid function
- remove dma_set_coherent mask call (now done in MFD core)
- do not use drm_platform_init

Changes since v4:
- fix a few more bugs in rotation handling (rotation was buggy on some
  formats)
- return connector_status_unknown until a panel is exposed by the
  drm_panel infrastructure (prevent fbdev creation until everyting is
  in place)
- rework Kconfig MFD_ATMEL_HLCDC selection to simplify the configuration
  (automatically select this option when selecting the HLCDC PMW or DRM
  driver, instead of depending on this option)

Changes since v3:
- rework the layer code to simplify several parts (locking and layer
  disabling)
- make use of the drm_flip_work infrastructure
- rely on default HW cursor implementation using on the cursor plane
- rework the display controller DT bindings (based on OF graph
  representation)
- add rotation support
- retrieve RGB bus format from drm_display_info
- drop the dynamic pinctrl state selection
- rework HLCDC output handling (previously specialized to interface
  with LCD panels)
- drop ".module = THIS_MODULE" lines
- change display controller compatible string

Changes since v2:
- fix coding style issues (macro indentation)
- make use of GENMASK in several places
- declare regmap config as a static structure
- rework hlcdc plane update API
- rework cursor handling to make use of the new plane update API
- fix backporch config
- do not use devm_regmap_init_mmio_clk to avoid extra clk_enable
  clk disable calls when accessing registers
- explicitly include regmap and clk headers instead of relying on
  atmel-hlcdc.h inclusions
- make the atmel-hlcdc driver depends on CONFIG_OF
- separate DT bindings documentation from driver implementation
- support several pin muxing for HLCDC pins on sama5d3 SoCs

Changes since v1:
- replace the backlight driver by a PWM driver
- make use of drm_panel infrastructure
- split driver code in several subsystem: MFD, PWM and DRM
- add support for overlays
- add support for hardware cursor


Boris Brezillon (2):
  drm: add Atmel HLCDC Display Controller support
  drm: add DT bindings documentation for atmel-hlcdc-dc driver

 .../devicetree/bindings/drm/atmel/hlcdc-dc.txt |  53 ++
 drivers/gpu/drm/Kconfig|   2 +
 drivers/gpu/drm/Makefile   |   1 +
 drivers/gpu/drm/atmel-hlcdc/Kconfig|  11 +
 drivers/gpu/drm/atmel-hlcdc/Makefile   |   7 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 406 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   | 579 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h   | 213 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c| 667 
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.h| 398 ++
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c   | 319 
 

[LKP] [PATCH] drm/radeon: Try to init amdkfd only if 64 bit kernel

[Kees Cook]

On Sun, Jan 4, 2015 at 8:28 PM, Rusty Russell  wrote:
> Oded Gabbay  writes:
>> On 12/24/2014 01:01 AM, Rusty Russell wrote:
>>> Oded Gabbay  writes:
 I didn't say it doesn't always work.
 The actual thing that doesn't work is the define symbol_get and only in a
 specific case of 32bit kernel AND CONFIG_MODULES is unset AND
 CONFIG_RANDOMIZE_BASE is set.
 The define in that case is:
 #define symbol_get(x) ({ extern typeof(x) x __attribute__((weak)); &(x); })

 Why it doesn't work (doesn't return NULL when symbol doesn't exists) ?
>>>
>>> Hmm, I'd guess CONFIG_RANDOMIZE_BASE is relocating NULL symbols...
>>>
>>> No, I can't reproduce this.  Please send your .config privately.
>>>
>>> Here's my test case:
>>>
>>> diff --git a/init/main.c b/init/main.c
>>> index 61b993767db5..a3ee1ec97ec3 100644
>>> --- a/init/main.c
>>> +++ b/init/main.c
>>> @@ -683,6 +683,12 @@ asmlinkage __visible void __init start_kernel(void)
>>>
>>>  ftrace_init();
>>>
>>> +{
>>> +extern void nonexistent_fn(void);
>>> +printk("symbol_get(nonexistent_fn) = %p\n",
>>> +   symbol_get(nonexistent_fn));
>>> +}
>>> +
>>>  /* Do the rest non-__init'ed, we're now alive */
>>>  rest_init();
>>>   }
>>>
>>> Thanks,
>>> Rusty.
>>>
>> Hi Rusty,
>>
>> Attached is the bad config file. (config-bad)
>> I have narrowed the changes you need to do to the config file in order to
>> reproduce this bug.
>> The base assumption is a 32-bit kernel and without modules support. Rest of 
>> the
>> config file is pretty standard, IMO.
>> Then, its not enough to enable CONFIG_RANDOMIZE_BASE like I wrote in my 
>> original
>> post. You need also to unset CONFIG_HIBERNATION.
>
> Indeed, thanks; your config breaks as reported.  With CONFIG_HIBERNATION
> the kernel offset is 0, so we don't see this.
>
> Kees, as far as I can tell you need another 0-terminated vmlinux.relocs
> section for weak symbols.  These should not be relocated if already 0.

A few questions:

Why doesn't this break on 32-bit without kASLR? 32-bit does relocation
by default, even without CONFIG_RANDOMIZE_BASE.

Are there any symbols that are NULL that aren't weak? I'd expect all
strong symbols to have non-zero offsets, but I must be
misunderstanding something here.

-Kees

>
> Put this somewhere to test.  It fails for x86_64, too:
>
> diff --git a/init/main.c b/init/main.c
> index 61b993767db5..c9e0195c792a 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -683,6 +683,12 @@ asmlinkage __visible void __init start_kernel(void)
>
> ftrace_init();
>
> +   {
> +   extern void __attribute__((weak)) nonexistent_fn(void);
> +   printk("nonexistent_fn = %p\n", nonexistent_fn);
> +   BUG_ON(nonexistent_fn != NULL);
> +   }
> +
> /* Do the rest non-__init'ed, we're now alive */
> rest_init();
>  }
>
> Cheers,
> Rusty.



-- 
Kees Cook
Chrome OS Security

[RESEND PATCH v5 3/3] drm: panel: simple-panel: add bus format information for foxlink panel

[Boris Brezillon]

Foxlink's fl500wvr00-a0t supports RGB888 format.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/panel/panel-simple.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 4504018..6049d24 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -563,6 +563,7 @@ static const struct panel_desc foxlink_fl500wvr00_a0t = {
.width = 108,
.height = 65,
},
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
 };

 static const struct drm_display_mode hannstar_hsd070pww1_mode = {
-- 
1.9.1

[RESEND PATCH v5 2/3] drm: panel: simple-panel: add support for bus_format retrieval

[Boris Brezillon]

Provide a way to specify panel requirement in terms of supported media bus
format (particularly useful for panels connected to an RGB or LVDS bus).

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/panel/panel-simple.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index e95385b..4504018 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -61,6 +61,8 @@ struct panel_desc {
unsigned int disable;
unsigned int unprepare;
} delay;
+
+   u32 bus_format;
 };

 struct panel_simple {
@@ -111,6 +113,9 @@ static int panel_simple_get_fixed_modes(struct panel_simple 
*panel)
connector->display_info.bpc = panel->desc->bpc;
connector->display_info.width_mm = panel->desc->size.width;
connector->display_info.height_mm = panel->desc->size.height;
+   if (panel->desc->bus_format)
+   drm_display_info_set_bus_formats(>display_info,
+>desc->bus_format, 1);

return num;
 }
-- 
1.9.1

[RESEND PATCH v5 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info

[Boris Brezillon]

Add bus_formats and num_bus_formats fields and
drm_display_info_set_bus_formats helper function to specify the bus
formats supported by a given display.

This information can be used by display controller drivers to configure
the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw
RGB or LVDS busses).

Signed-off-by: Boris Brezillon 
Acked-by: Laurent Pinchart 
Acked-by: Philipp Zabel 
---
 drivers/gpu/drm/drm_crtc.c | 35 +++
 include/drm/drm_crtc.h |  8 
 2 files changed, 43 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5213da4..8c3d5b4 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -768,6 +768,40 @@ static void drm_mode_remove(struct drm_connector 
*connector,
 }

 /**
+ * drm_display_info_set_bus_formats - set the supported bus formats
+ * @info: display info to store bus formats in
+ * @fmts: array containing the supported bus formats
+ * @nfmts: the number of entries in the fmts array
+ *
+ * Store the supported bus formats in display info structure.
+ * See MEDIA_BUS_FMT_* definitions in include/uapi/linux/media-bus-format.h for
+ * a full list of available formats.
+ */
+int drm_display_info_set_bus_formats(struct drm_display_info *info,
+const u32 *formats,
+unsigned int num_formats)
+{
+   u32 *fmts = NULL;
+
+   if (!formats && num_formats)
+   return -EINVAL;
+
+   if (formats && num_formats) {
+   fmts = kmemdup(formats, sizeof(*formats) * num_formats,
+  GFP_KERNEL);
+   if (!formats)
+   return -ENOMEM;
+   }
+
+   kfree(info->bus_formats);
+   info->bus_formats = fmts;
+   info->num_bus_formats = num_formats;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_display_info_set_bus_formats);
+
+/**
  * drm_connector_get_cmdline_mode - reads the user's cmdline mode
  * @connector: connector to quwery
  *
@@ -924,6 +958,7 @@ void drm_connector_cleanup(struct drm_connector *connector)
ida_remove(_connector_enum_list[connector->connector_type].ida,
   connector->connector_type_id);

+   kfree(connector->display_info.bus_formats);
drm_mode_object_put(dev, >base);
kfree(connector->name);
connector->name = NULL;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index b863298..3652d2c 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -131,6 +132,9 @@ struct drm_display_info {
enum subpixel_order subpixel_order;
u32 color_formats;

+   const u32 *bus_formats;
+   unsigned int num_bus_formats;
+
/* Mask of supported hdmi deep color modes */
u8 edid_hdmi_dc_modes;

@@ -1224,6 +1228,10 @@ int drm_mode_connector_set_tile_property(struct 
drm_connector *connector);
 extern int drm_mode_connector_update_edid_property(struct drm_connector 
*connector,
   const struct edid *edid);

+extern int drm_display_info_set_bus_formats(struct drm_display_info *info,
+   const u32 *formats,
+   unsigned int num_formats);
+
 static inline bool drm_property_type_is(struct drm_property *property,
uint32_t type)
 {
-- 
1.9.1

[RESEND PATCH v5 0/3] drm: describe display bus format

[Boris Brezillon]

Hello,

Resending this series I depends on for the Atmel HLCDC driver which, BTW,
I really expect to be merged in 3.20.
Thierry, do you see any remaining issues that should be fixed ?
If not, Dave, Thierry, could you take it for 3.20 (or, if you prefer, I
could make it part of my PR for the atmel-hlcdc driver inclusion).

Here follows the usual description:

This series makes use of the MEDIA_BUS_FMT definition to describe how
the data are transmitted to the display.

This will allow drivers to configure their output display bus according
to the display capabilities.
For example some display controllers support DPI (or raw RGB) connectors
and need to specify which format will be transmitted on the DPI bus
(RGB444, RGB565, RGB888, ...).

This series also adds a field to the panel_desc struct so that one
can specify which format is natevely supported by a panel.

Regards,

Boris

Changes since v4:
 - fix typo
 - fix 'line over 80 characters' warnings
 - fix leak of formats array

Changes since v3:
 - store num_bus_formats on an unsigned int
 - clearly state that fmts argument (in drm_display_info_set_bus_formats
   function) should be an array of MEDIA_BUS_FMT_* values.

Changes since v2:
 - use the MEDIA_BUS_FMT macros

Changes since v1:
 - rename nformats into num_formats
 - declare num_formats as an unsigned int


Boris Brezillon (3):
  drm: add bus_formats and num_bus_formats fields to drm_display_info
  drm: panel: simple-panel: add support for bus_format retrieval
  drm: panel: simple-panel: add bus format information for foxlink panel

 drivers/gpu/drm/drm_crtc.c   | 35 +++
 drivers/gpu/drm/panel/panel-simple.c |  6 ++
 include/drm/drm_crtc.h   |  8 
 3 files changed, 49 insertions(+)

-- 
1.9.1

[PATCH 0/9] Replace use of radeon_sa with a new sub allocator

[Alex Deucher]

On Wed, Dec 31, 2014 at 8:39 AM, Oded Gabbay  wrote:
> Background:
>
> amdkfd needs GART memory for several things, such as runlist packets,
> MQDs, HPDs and more. Unfortunately, all of this memory must be always
> pinned (due to several reasons which were discussed during the
> initial review of amdkfd).
>
> Current Solution:
>
> The current (short/mid-term) solution that was proposed by Jerome.G, is
> to limit the amount of memory to a small size, roughly 4MB and allocate
> this buffer at the start of the GART. To accomodate this, amdkfd has
> two kernel module parameters, maximum number of HSA processes and
> maximum number of queues per process, which require under 4MB of GART
> memory when using their defaults, 32 and 128 respectively.
>
> Until now, amdkfd used the radeon sub-allocator module (radeon_sa)
> to handle the sub-allocation of memory from this large buffer to
> different modules inside the amdkfd.
>
> However, while running OpenCL conformance test suite, we found that
> radeon_sa module is not suitable for this kind of task, due to its
> design:
> 1. Every allocation increments its interal pointer so the next
> allocation is *always* done ahead of the previous allocation. This
> causes the internal pointer to wrap-around when it reaches the end of
> the buffer.
>
> 2. When encoutering an area that is already allocated, the module
> waits for that area to be freed. If it is not freed in a timely manner
> (or has no fence), the allocation fails. Simply put, it can't "skip"
> the allocated area.
>
> Now, this is most probably good for graphics, but for amdkfd needs,
> the combination of the two behaviors mentioned above eventually causes
> a denial-of-service. This is because some memory allocations
> are *always* present and *never* freed (such as HPDs).
> Therefore, given enough time and workload, the radeon_sa eventually
> wraps around, encounters an already allocated area and gets stuck.
>
> Proposed new solution:
>
> To solve this, I have written a simple sub-allocator module inside
> amdkfd. It allocates fixed-size contiguous chunks (1 or more) and uses
> a bitmap to manage the allocations. The next allocation is always
> being searched for from the start of the GART buffer, and the module
> knows how to skip allocated chunks.
>
> Because most allocations are MQDs, and MQDs are 512 Bytes in size, I
> set the default chunk size to be 512 Bytes.
>
> The basic GART memory allocation is still being done in the
> amdkfd <--> radeon interface, and it still occupies less than 4MB.
>
> I have chosen to implement a new allocator instead of changing
> radeon_sa because the behavior of radeon_sa is very appropriate for
> graphics, where allocations do not stay forever. Also, amdkfd doesn't
> actually need the flexibility and features radeon_sa provides.
>

For the series:

Reviewed-by: Alex Deucher 

> Oded
>
> Oded Gabbay (9):
>   drm/amd: Add new kfd-->kgd interface for gart usage
>   drm/radeon: Impl. new gtt allocate/free functions
>   drm/amdkfd: Add gtt sa related data to kfd_dev struct
>   drm/amdkfd: Add kfd gtt sub-allocator functions
>   drm/amdkfd: Fixed calculation of gart buffer size
>   drm/amdkfd: Allocate gart memory using new interface
>   drm/amdkfd: Using new gtt sa in amdkfd
>   drm/radeon: Remove old radeon_sa usage from kfd-->kgd interface
>   drm/amd: Remove old radeon_sa funcs from kfd-->kgd interface
>
>  drivers/gpu/drm/amd/amdkfd/kfd_device.c| 217 
> -
>  .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c  |  23 +--
>  drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c  |  41 ++--
>  drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c   |  16 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c|  10 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_priv.h  |  28 ++-
>  drivers/gpu/drm/amd/include/kgd_kfd_interface.h|  23 +--
>  drivers/gpu/drm/radeon/radeon_kfd.c| 128 ++--
>  8 files changed, 329 insertions(+), 157 deletions(-)
>
> --
> 2.1.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 87625] Radeon 7950 hangs for a bit when switching video to fullscreen mode in mplayer2

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

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

Luke-Jr <luke-jr+freedesktopbugs at utopios.org> changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #10 from Luke-Jr <luke-jr+freedesktopbugs at utopios.org> ---
I've not been able to reproduce this since upgrading.

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

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #6 from Maarten Lankhorst  ---
I think that right now i915 doesn't use the fence stuff yet so it's probably
not causing the problem, still it would be useful to check.

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

[Bug 90851] radeonsi on pitcairn: nine and skyrim - unable to handle kernel paging request

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

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

Christoph Haag  changed:

   What|Removed |Added

Summary|nine and skyrim: unable to  |radeonsi on pitcairn: nine
   |handle kernel paging|and skyrim - unable to
   |request |handle kernel paging
   ||request

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

[Bug 90851] New: nine and skyrim: unable to handle kernel paging request

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

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

Bug ID: 90851
   Summary: nine and skyrim: unable to handle kernel paging
request
   Product: Drivers
   Version: 2.5
Kernel Version: 3.19-rc2
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: haagch.christoph at googlemail.com
Regression: No

Created attachment 162571
  --> https://bugzilla.kernel.org/attachment.cgi?id=162571=edit
full dmesg

It does not happen very often, but when it does, the game freezes and has to be
killed. radeon takes a little wile, but recovers.

00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor
Graphics Controller (rev 09)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Wimbledon XT [Radeon HD 7970M] (rev ff)

mesa was a then recent git master build with master from
https://github.com/iXit/Mesa-3D.git merged into it so there's a possibility it
doesn't happen with pure upstream mesa.

I think it has only happened in skyrim with nine so far.

[106308.053804] BUG: unable to handle kernel paging request at 8004a2fa79e8
[106308.055548] IP: [] ttm_eu_reserve_buffers+0xbe/0x390
[ttm]
[106308.057054] PGD 0 
[106308.057059] Oops:  [#1] PREEMPT SMP 
[106308.057088] Modules linked in: hidp uvcvideo rfcomm joydev btrfs xor ecb
bnep msr videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common raid6_pq
videodev media coretemp btusb arc4 mousedev intel_rapl bluetooth iosf_mbi
x86_pkg_temp_thermal intel_powerclamp kvm_intel iTCO_wdt iTCO_vendor_support
snd_hda_codec_hdmi kvm snd_hda_codec_realtek iwldvm snd_hda_codec_generic
led_class mac80211 crct10dif_pclmul crc32_pclmul crc32c_intel snd_hda_intel
ghash_clmulni_intel snd_hda_controller aesni_intel snd_hda_codec aes_x86_64 lrw
gf128mul glue_helper snd_hwdep iwlwifi snd_pcm ablk_helper cfg80211 snd_timer
psmouse cryptd r8169 i2c_i801 serio_raw snd pcspkr rtsx_pci_ms soundcore
memstick rfkill lpc_ich mii wmi tpm_tis tpm mei_me mei shpchp evdev battery ac
thermal processor mac_hid sch_fq_codel nfs
[106308.057104]  lockd grace sunrpc fscache fuse ext4 crc16 mbcache jbd2 sr_mod
cdrom sd_mod hid_generic usbhid hid rtsx_pci_sdmmc mmc_core atkbd libps2 ahci
ehci_pci libahci libata xhci_pci xhci_hcd firewire_ohci ehci_hcd scsi_mod
firewire_core crc_itu_t rtsx_pci usbcore usb_common i8042 serio radeon hwmon
ttm i915 button intel_gtt video i2c_algo_bit drm_kms_helper drm i2c_core [last
unloaded: uvcvideo]
[106308.057107] CPU: 2 PID: 3057 Comm: TESV.exe Not tainted 3.19.0-1-mainline
#1
[106308.057108] Hardware name: CLEVO P170EM/P170EM,
BIOS 4.6.5 08/22/2012
[106308.057109] task: 88070cae13e0 ti: 8804a30dc000 task.ti:
8804a30dc000
[106308.057115] RIP: 0010:[]  []
ttm_eu_reserve_buffers+0xbe/0x390 [ttm]
[106308.057116] RSP: 0018:8804a30df738  EFLAGS: 00010286
[106308.057117] RAX:  RBX: 8804a30dfb30 RCX:
0008
[106308.057117] RDX: 0004 RSI: 0058 RDI:

[106308.057118] RBP: 8804a30df788 R08: c9002295b488 R09:

[106308.057118] R10: 817215ea R11: ea0013907a00 R12:

[106308.057119] R13: 8004a2fa7868 R14: 880808e08000 R15:
88031f24c388
[106308.057120] FS:  7ffd8000(0063) GS:88082f28(006b)
knlGS:eb4adb40
[106308.057121] CS:  0010 DS: 002b ES: 002b CR0: 80050033
[106308.057121] CR2: 8004a2fa79e8 CR3: 00070d02d000 CR4:
001407e0
[106308.057122] Stack:
[106308.057124]  880809282d80 8804a30df7e0 0100
8804a30dfcd8
[106308.057125]  880337cba800 8804a30dfb30 8804a30dfa80
8804a30dfb30
[106308.057127]  880808e08000 8804a30dfae8 8804a30df828
a01eeaa7
[106308.057127] Call Trace:
[106308.057144]  [] radeon_bo_list_validate+0x97/0x230
[radeon]
[106308.057158]  [] radeon_cs_parser_relocs+0x34d/0x440
[radeon]
[106308.057172]  [] radeon_cs_ioctl+0x2a0/0x810 [radeon]
[106308.057176]  [] ? __switch_to+0x445/0x5f0
[106308.057186]  [] drm_ioctl+0x1df/0x680 [drm]
[106308.057197]  [] radeon_drm_ioctl+0x4c/0x80 [radeon]
[106308.057208]  [] radeon_kms_compat_ioctl+0x14/0x30
[radeon]
[106308.057211]  [] compat_SyS_ioctl+0xf0/0x1260
[106308.057214]  [] ? compat_SyS_futex+0x84/0x1a0
[106308.057216]  [] ? task_work_run+0xd9/0xf0
[106308.057220]  [] sysenter_dispatch+0x7/0x25
[106308.057234] Code: 00 00 00 85 c0 0f 8f d2 01 00 00 41 80 7f 18 00 0f 85 a7
01 00 00 4d 8b 3f 49 39 df 0f 84 eb 01 00 00 48 83 7d c8 00 4d 8b 6f 10 <49> 8b
bd 80 01 00 00 0f 84 65 01 00 00 80 7d c7 00 48 8b 75 c8 
[106308.057238] RIP  [] ttm_eu_reserve_buffers+0xbe/0x390
[ttm]
[106308.057239]  RSP 
[106308.057239] CR2: 

[PATCH 5/5] drm/tegra: Add minimal power management

[Mark Zhang]

I mean:

Reviewed-by: Mark Zhang 

To make display suspend/resume working, we need some other patches. I
will send out the patches soon, based on this patch set. Thanks Thierry.

Mark
On 01/05/2015 10:50 PM, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Tue, Dec 23, 2014 at 03:32:43PM +0800, Mark Zhang wrote:
>> +1
> 
> Does that translate into a "Reviewed-by" or "Tested-by"?
> 
> Thierry
> 
> * Unknown Key
> * 0x7F3EB3A1
> 

[PATCH 4/5] gpu: host1x: Provide a proper struct bus_type

[Mark Zhang]

Thanks for the explanation.

Reviewed-by: Mark Zhang 

Mark
On 01/05/2015 10:49 PM, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Tue, Dec 23, 2014 at 03:30:20PM +0800, Mark Zhang wrote:
>> On 12/19/2014 11:24 PM, Thierry Reding wrote:
>>> From: Thierry Reding 
>>>
>>> Previously the struct bus_type exported by the host1x infrastructure was
>>> only a very basic skeleton. Turn that implementation into a more full-
>>> fledged bus to support proper probe ordering and power management.
>>>
>>> Note that the bus infrastructure needs to be available before any of the
>>> drivers can be registered, so the bus needs to be registered before the
>>> host1x module. Otherwise drivers could be registered before the module
>>> is loaded and trigger a BUG_ON() in driver_register(). To ensure the bus
>>> infrastructure is always there, always build the code into the kernel
>>> when enabled and register it with a postcore initcall.
>>>
>>
>> So this means there is no chance that host1x can be built as a kernel
>> module, right? I'm fine with that, just asking.
> 
> No, it means that not all of host1x can be built as a module. The host1x
> bus infrastructure will always be built-in when TEGRA_HOST1X is enabled.
> 
>>> Signed-off-by: Thierry Reding 
>>> ---
>> [...]
>>> diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
>>> index c1189f004441..a3e667a1b6f5 100644
>>> --- a/drivers/gpu/host1x/Makefile
>>> +++ b/drivers/gpu/host1x/Makefile
>>> @@ -1,5 +1,4 @@
>>>  host1x-y = \
>>> -   bus.o \
>>> syncpt.o \
>>> dev.o \
>>> intr.o \
>>> @@ -13,3 +12,5 @@ host1x-y = \
>>> hw/host1x04.o
>>>  
>>>  obj-$(CONFIG_TEGRA_HOST1X) += host1x.o
>>> +
>>> +obj-y += bus.o
>>
>> I didn't get it, why we need to do this?
> 
> If CONFIG_TEGRA_HOST1X=m, then obj-$(CONFIG_TEGRA_HOST1X) builds the
> bus.o into a module. But we want it to always be built-in. The build
> system will descend into the drivers/gpu/host1x directory only if the
> TEGRA_HOST1X symbol is selected (either =y or =m), therefore obj-y here
> will result in bus.o being built-in whether the rest of host1x is built
> as a module or built-in.
> 
>>> diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
>>> index 0b52f0ea8871..28630a5e9397 100644
>>> --- a/drivers/gpu/host1x/bus.c
>>> +++ b/drivers/gpu/host1x/bus.c
>>> @@ -72,13 +72,14 @@ static void host1x_subdev_del(struct host1x_subdev 
>>> *subdev)
>> [...]
>>>  
>>>  static inline struct host1x_device *to_host1x_device(struct device *dev)
>>>
>>
>> The change looks good to me. Just one thing I feel not comfortable:
>> "struct host1x_device" is not a real device, it represents the drm
>> device actually. The real tegra host1x device is represented by "struct
>> host1x". But the name "host1x_device" makes people confusing, I mean, it
>> will make people thinking it's the real "tegra host1x" device then bring
>> the reading difficulty.
> 
> The reason behind that name is that host1x provides a bus (real to some
> degree, but also virtual). host1x is the device that provides the bus
> whereas a host1x_device is a "device" on the "host1x" bus. That's just
> like an i2c_client is a "client" on the "I2C" bus. Or an spi_device is a
> "device" on the "SPI" bus.
> 
>> Why don't we change this to something like "drm_device" or
>> "tegra_drm_device"?
> 
> Other devices can be host1x devices. Some time ago work was being done
> on a driver for the CSI/VI hardware (for camera or video input). The
> idea was that it would also be instantiated as a host1x_device in some
> other subsystem (V4L2 at the time).
> 
> The functionality here is generic and in no way DRM specific.
> 
> Thierry
> 
> * Unknown Key
> * 0x7F3EB3A1
> 

[PATCH v2 2/3] drm/panel: add s6e63j0x03 LCD panel driver

[Hyungwon Hwang]

Dear all,

On Tue, 06 Jan 2015 00:21:22 +0900
Inki Dae  wrote:

> On 2015년 01월 05일 23:19, Thierry Reding wrote:
> > On Wed, Dec 31, 2014 at 07:41:43PM +0900, Inki Dae wrote:
> >> Hi Thierry,
> >>
> >> Ping~.
> >>
> >> Or is it ok to pick up this patch to my tree, exynos-drm-next? It
> >> doesn't seem to care for a long time.
> > 
> > I don't seem to have a copy of the v2 2/3 patch. All I found in my
> > inbox is the v2 0/3 cover-letter. Please resend with me in Cc so
> > that I can properly review (and apply) the patch.
> 
> Please, refer to below link,
> http://lists.freedesktop.org/archives/dri-devel/2014-December/073666.html
> 
> We already sent it with you in Cc. Anyway, I will resend it.
> 

Also you can find the whole patchset from

[1/3] https://patchwork.kernel.org/patch/5461421/
[2/3] https://patchwork.kernel.org/patch/5461431/
[3/3] https://patchwork.kernel.org/patch/5461441/

> Thanks,
> Inki Dae
> 
> > 
> > Thierry
> > 
> 

Best regards,
Hyungwon Hwang

[PATCH] drm/amdkfd: Load mqd to hqd in non-HWS mode

[Alex Deucher]

On Sun, Jan 4, 2015 at 2:53 PM, Oded Gabbay  wrote:
> From: Ben Goz 
>
> This patch fixes a bug in DQM, where the MQD of a newly created compute queue
> is not loaded to an HQD slot. As a result, the CP never reads packets from 
> this
> queue.
>
> This bug happens only in non-HWS (hardware scheduling) mode. In HWS mode, the
> CP is responsible of loading MQDs to HQDs slots.
>
> Signed-off-by: Ben Goz 
> Reviewed-by: Oded Gabbay 

Acked-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> index f44d673..3b08ed6 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
> @@ -272,6 +272,18 @@ static int create_compute_queue_nocpsch(struct 
> device_queue_manager *dqm,
> return retval;
> }
>
> +   pr_debug("kfd: loading mqd to hqd on pipe (%d) queue (%d)\n",
> +   q->pipe,
> +   q->queue);
> +
> +   retval = mqd->load_mqd(mqd, q->mqd, q->pipe,
> +   q->queue, q->properties.write_ptr);
> +   if (retval != 0) {
> +   deallocate_hqd(dqm, q);
> +   mqd->uninit_mqd(mqd, q->mqd, q->mqd_mem_obj);
> +   return retval;
> +   }
> +
> return 0;
>  }
>
> --
> 2.1.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/7] Add SDMA user-mode queues support to amdkfd

[Alex Deucher]

On Sat, Jan 3, 2015 at 3:12 PM, Oded Gabbay  wrote:
> Although I didn't get any replies on v1, I still decided to send this
> v2, because:
>
> a. Alex and I decided to move some H/W initialization functionallity
>into radeon.
>
> b. The next patch-set that I intend to send (prepare to support future
>AMD GPUs) is based on this patch-set. Therefore, I wanted
>to quickly publish the most updated version of this patch-set.
>
> The only change in this version is moving initialization of H/W
> registers into radeon driver, instead of putting it in the interface
> file. It is detailed in the relevant commits.
>
> Link to cover letter of original version:
> http://lists.freedesktop.org/archives/dri-devel/2014-December/073934.html
>

Series is:
Reviewed-by: Alex Deucher 

> Oded Gabbay
>
> Ben Goz (7):
>   drm/amd: Add SDMA functions to kfd-->kgd interface
>   drm/radeon: Implement SDMA interface functions
>   drm/amdkfd: Add SDMA mqd support
>   drm/amdkfd: Add SDMA user-mode queues support to QCM
>   drm/amdkfd: Identify SDMA queue in create queue ioctl
>   drm/amdkfd: Pass queue type to pqm_create_queue()
>   drm/radeon: Enable sdma preemption
>
>  drivers/gpu/drm/amd/amdkfd/kfd_chardev.c   |   6 +-
>  .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c  | 159 ++--
>  .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.h  |   5 +
>  drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c   | 121 +
>  drivers/gpu/drm/amd/amdkfd/kfd_priv.h  |   8 +
>  .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c |   2 +-
>  drivers/gpu/drm/amd/include/kgd_kfd_interface.h|  13 +-
>  drivers/gpu/drm/radeon/cik_reg.h   | 200 
> -
>  drivers/gpu/drm/radeon/cik_sdma.c  |  29 +++
>  drivers/gpu/drm/radeon/radeon_kfd.c| 115 +++-
>  10 files changed, 640 insertions(+), 18 deletions(-)
>
> --
> 2.1.0
>

[PATCH 3/3] drm/radeon: fix VM flush on CIK (v2)

[Alex Deucher]

We need to wait for the GPUVM flush to complete.  There
was some confusion as to how this mechanism was supposed
to work.  The operation is not atomic.  For GPU initiated
invalidations you need to read back a VM register to
introduce enough latency for the update to complete.

v2: drop gart changes

Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/cik.c  | 11 +++
 drivers/gpu/drm/radeon/cik_sdma.c | 10 ++
 2 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 6dcde37..63adce3 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -6033,6 +6033,17 @@ void cik_vm_flush(struct radeon_device *rdev, struct 
radeon_ring *ring,
radeon_ring_write(ring, 0);
radeon_ring_write(ring, 1 << vm_id);

+   /* wait for the invalidate to complete */
+   radeon_ring_write(ring, PACKET3(PACKET3_WAIT_REG_MEM, 5));
+   radeon_ring_write(ring, (WAIT_REG_MEM_OPERATION(0) | /* wait */
+WAIT_REG_MEM_FUNCTION(3) |  /* == */
+WAIT_REG_MEM_ENGINE(0))); /* me */
+   radeon_ring_write(ring, VM_INVALIDATE_REQUEST >> 2);
+   radeon_ring_write(ring, 0);
+   radeon_ring_write(ring, 0); /* ref */
+   radeon_ring_write(ring, 1 << vm_id); /* mask */
+   radeon_ring_write(ring, 0x20); /* poll interval */
+
/* compute doesn't have PFP */
if (usepfp) {
/* sync PFP to ME, otherwise we might get invalid PFP reads */
diff --git a/drivers/gpu/drm/radeon/cik_sdma.c 
b/drivers/gpu/drm/radeon/cik_sdma.c
index dde5c7e..f1a5cac 100644
--- a/drivers/gpu/drm/radeon/cik_sdma.c
+++ b/drivers/gpu/drm/radeon/cik_sdma.c
@@ -903,6 +903,9 @@ void cik_sdma_vm_pad_ib(struct radeon_ib *ib)
 void cik_dma_vm_flush(struct radeon_device *rdev, struct radeon_ring *ring,
  unsigned vm_id, uint64_t pd_addr)
 {
+   u32 extra_bits = (SDMA_POLL_REG_MEM_EXTRA_OP(0) |
+ SDMA_POLL_REG_MEM_EXTRA_FUNC(3)); /* == */
+
radeon_ring_write(ring, SDMA_PACKET(SDMA_OPCODE_SRBM_WRITE, 0, 0xf000));
if (vm_id < 8) {
radeon_ring_write(ring, (VM_CONTEXT0_PAGE_TABLE_BASE_ADDR + 
(vm_id << 2)) >> 2);
@@ -943,5 +946,12 @@ void cik_dma_vm_flush(struct radeon_device *rdev, struct 
radeon_ring *ring,
radeon_ring_write(ring, SDMA_PACKET(SDMA_OPCODE_SRBM_WRITE, 0, 0xf000));
radeon_ring_write(ring, VM_INVALIDATE_REQUEST >> 2);
radeon_ring_write(ring, 1 << vm_id);
+
+   radeon_ring_write(ring, SDMA_PACKET(SDMA_OPCODE_POLL_REG_MEM, 0, 
extra_bits));
+   radeon_ring_write(ring, VM_INVALIDATE_REQUEST >> 2);
+   radeon_ring_write(ring, 0);
+   radeon_ring_write(ring, 0); /* reference */
+   radeon_ring_write(ring, 1 << vm_id); /* mask */
+   radeon_ring_write(ring, (0xfff << 16) | 10); /* retry count, poll 
interval */
 }

-- 
1.8.3.1

[PATCH 2/3] drm/radeon: fix VM flush on SI (v2)

[Alex Deucher]

We need to wait for the GPUVM flush to complete.  There
was some confusion as to how this mechanism was supposed
to work.  The operation is not atomic.  For GPU initiated
invalidations you need to read back a VM register to
introduce enough latency for the update to complete.

v2: drop gart changes

Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/si.c | 10 ++
 drivers/gpu/drm/radeon/si_dma.c |  8 
 drivers/gpu/drm/radeon/sid.h| 18 ++
 3 files changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 60df444..f1354ed 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -5057,6 +5057,16 @@ void si_vm_flush(struct radeon_device *rdev, struct 
radeon_ring *ring,
radeon_ring_write(ring, 0);
radeon_ring_write(ring, 1 << vm_id);

+   /* wait for the invalidate to complete */
+   radeon_ring_write(ring, PACKET3(PACKET3_WAIT_REG_MEM, 5));
+   radeon_ring_write(ring, (WAIT_REG_MEM_FUNCTION(3) |  /* == */
+WAIT_REG_MEM_ENGINE(0))); /* me */
+   radeon_ring_write(ring, VM_INVALIDATE_REQUEST >> 2);
+   radeon_ring_write(ring, 0);
+   radeon_ring_write(ring, 0); /* ref */
+   radeon_ring_write(ring, 1 << vm_id); /* mask */
+   radeon_ring_write(ring, 0x20); /* poll interval */
+
/* sync PFP to ME, otherwise we might get invalid PFP reads */
radeon_ring_write(ring, PACKET3(PACKET3_PFP_SYNC_ME, 0));
radeon_ring_write(ring, 0x0);
diff --git a/drivers/gpu/drm/radeon/si_dma.c b/drivers/gpu/drm/radeon/si_dma.c
index f5cc777..0a37112 100644
--- a/drivers/gpu/drm/radeon/si_dma.c
+++ b/drivers/gpu/drm/radeon/si_dma.c
@@ -206,6 +206,14 @@ void si_dma_vm_flush(struct radeon_device *rdev, struct 
radeon_ring *ring,
radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_SRBM_WRITE, 0, 0, 0, 0));
radeon_ring_write(ring, (0xf << 16) | (VM_INVALIDATE_REQUEST >> 2));
radeon_ring_write(ring, 1 << vm_id);
+
+   /* wait for invalidate to complete */
+   radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_POLL_REG_MEM, 0, 0, 0, 
0));
+   radeon_ring_write(ring, VM_INVALIDATE_REQUEST);
+   radeon_ring_write(ring, 0xff << 16); /* retry */
+   radeon_ring_write(ring, 1 << vm_id); /* mask */
+   radeon_ring_write(ring, 0); /* value */
+   radeon_ring_write(ring, 0x20); /* poll interval */
 }

 /**
diff --git a/drivers/gpu/drm/radeon/sid.h b/drivers/gpu/drm/radeon/sid.h
index 4069be89..8499924 100644
--- a/drivers/gpu/drm/radeon/sid.h
+++ b/drivers/gpu/drm/radeon/sid.h
@@ -1632,6 +1632,23 @@
 #definePACKET3_MPEG_INDEX  0x3A
 #definePACKET3_COPY_DW 0x3B
 #definePACKET3_WAIT_REG_MEM0x3C
+#defineWAIT_REG_MEM_FUNCTION(x)((x) << 0)
+/* 0 - always
+* 1 - <
+* 2 - <=
+* 3 - ==
+* 4 - !=
+* 5 - >=
+* 6 - >
+*/
+#defineWAIT_REG_MEM_MEM_SPACE(x)   ((x) << 4)
+/* 0 - reg
+* 1 - mem
+*/
+#defineWAIT_REG_MEM_ENGINE(x)  ((x) << 8)
+/* 0 - me
+* 1 - pfp
+*/
 #definePACKET3_MEM_WRITE   0x3D
 #definePACKET3_COPY_DATA   0x40
 #definePACKET3_CP_DMA  0x41
@@ -1835,6 +1852,7 @@
 #defineDMA_PACKET_TRAP   0x7
 #defineDMA_PACKET_SRBM_WRITE 0x9
 #defineDMA_PACKET_CONSTANT_FILL  0xd
+#defineDMA_PACKET_POLL_REG_MEM   0xe
 #defineDMA_PACKET_NOP0xf

 #define VCE_STATUS 0x20004
-- 
1.8.3.1

[PATCH 1/3] drm/radeon: fix VM flush on cayman/aruba (v2)

[Alex Deucher]

We need to wait for the GPUVM flush to complete.  There
was some confusion as to how this mechanism was supposed
to work.  The operation is not atomic.  For GPU initiated
invalidations you need to read back a VM register to
introduce enough latency for the update to complete.

v2: drop gart changes

Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/ni.c | 10 ++
 drivers/gpu/drm/radeon/ni_dma.c |  6 ++
 drivers/gpu/drm/radeon/nid.h| 21 +
 3 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 360de9f..ba7c68b 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -2516,6 +2516,16 @@ void cayman_vm_flush(struct radeon_device *rdev, struct 
radeon_ring *ring,
radeon_ring_write(ring, PACKET0(VM_INVALIDATE_REQUEST, 0));
radeon_ring_write(ring, 1 << vm_id);

+   /* wait for the invalidate to complete */
+   radeon_ring_write(ring, PACKET3(PACKET3_WAIT_REG_MEM, 5));
+   radeon_ring_write(ring, (WAIT_REG_MEM_FUNCTION(3) |  /* == */
+WAIT_REG_MEM_ENGINE(0))); /* me */
+   radeon_ring_write(ring, VM_INVALIDATE_REQUEST >> 2);
+   radeon_ring_write(ring, 0);
+   radeon_ring_write(ring, 0); /* ref */
+   radeon_ring_write(ring, 1 << vm_id); /* mask */
+   radeon_ring_write(ring, 0x20); /* poll interval */
+
/* sync PFP to ME, otherwise we might get invalid PFP reads */
radeon_ring_write(ring, PACKET3(PACKET3_PFP_SYNC_ME, 0));
radeon_ring_write(ring, 0x0);
diff --git a/drivers/gpu/drm/radeon/ni_dma.c b/drivers/gpu/drm/radeon/ni_dma.c
index 50f8861..545e5f1 100644
--- a/drivers/gpu/drm/radeon/ni_dma.c
+++ b/drivers/gpu/drm/radeon/ni_dma.c
@@ -463,5 +463,11 @@ void cayman_dma_vm_flush(struct radeon_device *rdev, 
struct radeon_ring *ring,
radeon_ring_write(ring, DMA_PACKET(DMA_PACKET_SRBM_WRITE, 0, 0, 0));
radeon_ring_write(ring, (0xf << 16) | (VM_INVALIDATE_REQUEST >> 2));
radeon_ring_write(ring, 1 << vm_id);
+
+   /* wait for invalidate to complete */
+   radeon_ring_write(ring, DMA_SRBM_POLL_PACKET);
+   radeon_ring_write(ring, (0xff << 20) | (VM_INVALIDATE_REQUEST >> 2));
+   radeon_ring_write(ring, 1 << vm_id); /* mask */
+   radeon_ring_write(ring, 0); /* value */
 }

diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h
index 2e12e4d..e2b8bbf 100644
--- a/drivers/gpu/drm/radeon/nid.h
+++ b/drivers/gpu/drm/radeon/nid.h
@@ -1133,6 +1133,23 @@
 #definePACKET3_MEM_SEMAPHORE   0x39
 #definePACKET3_MPEG_INDEX  0x3A
 #definePACKET3_WAIT_REG_MEM0x3C
+#defineWAIT_REG_MEM_FUNCTION(x)((x) << 0)
+/* 0 - always
+* 1 - <
+* 2 - <=
+* 3 - ==
+* 4 - !=
+* 5 - >=
+* 6 - >
+*/
+#defineWAIT_REG_MEM_MEM_SPACE(x)   ((x) << 4)
+/* 0 - reg
+* 1 - mem
+*/
+#defineWAIT_REG_MEM_ENGINE(x)  ((x) << 8)
+/* 0 - me
+* 1 - pfp
+*/
 #definePACKET3_MEM_WRITE   0x3D
 #definePACKET3_PFP_SYNC_ME 0x42
 #definePACKET3_SURFACE_SYNC0x43
@@ -1272,6 +1289,10 @@
 (1 << 21) |\
 (((n) & 0xF) << 0))

+#define DMA_SRBM_POLL_PACKET   ((9 << 28) |\
+(1 << 27) |\
+(1 << 26))
+
 /* async DMA Packet types */
 #defineDMA_PACKET_WRITE  0x2
 #defineDMA_PACKET_COPY   0x3
-- 
1.8.3.1

[Bug 83510] Graphical glitches in Unreal Engine 4

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

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

--- Comment #13 from Michel Dänzer  ---
(In reply to Clément Guérin from comment #12)
> Low lighting glitch is still here. "can be seen in the Realistic Rendering
> demo or the Shooter Game demo with the Sanctuary map"

Make sure you use the current versions of the demos. I was seeing the darkness
in the first version of the Realistic Rendering demo, but it's fixed with the
current version, and Shooter Game looks fine as well.

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

[Bug 90741] Radeon: System pauses on TAHITI

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

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

--- Comment #5 from Michel Dänzer  ---
(In reply to Gustaw Smolarczyk from comment #4)
> If that may be the source of these problems, I could disable the second
> monitor along with the iGPU in order to test that hypothesis.

That would be interesting.

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

[Bug 85320] [RV620][RV630][RS880] GPU hangs using UVD hardware acceleration

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

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

--- Comment #32 from Maxim Kachur  ---
Created attachment 111799
  --> https://bugs.freedesktop.org/attachment.cgi?id=111799=edit
journalctl dump for uvd/vdpau crash

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

[Resend][PATCH v2 2/3] drm/panel: add s6e63j0x03 LCD panel driver

[Inki Dae]

Just resend it with Thierry's request.

Thanks,
Inki Dae

 Original Message 
Subject: [PATCH v2 2/3] drm/panel: add s6e63j0x03 LCD panel driver
Date: Tue, 09 Dec 2014 18:29:05 +0900
From: Hyungwon Hwang 
To: dri-devel at lists.freedesktop.org
CC: airlied at linux.ie, devicetree at vger.kernel.org, robh+dt at kernel.org,
pawel.moll at arm.com, mark.rutland at arm.com, ijc+devicetree at 
hellion.org.uk,
galak at codeaurora.org, linux-samsung-soc at vger.kernel.org,
kyungmin.park at samsung.com, inki.dae at samsung.com, a.hajda at samsung.com,
kgene.kim at samsung.com, thierry.reding at gmail.com, Hyungwon Hwang


From: Inki Dae 

This patch adds MIPI-DSI based S6E63J0X03 AMOLED LCD panel driver
which uses mipi_dsi bus to communicate with panel. The panel has
320×320 resolution in 1.63-inch physical panel. This panel is used in
Samsung Galaxy Gear 2.

Signed-off-by: Inki Dae 
Signed-off-by: Hyungwon Hwang 
Acked-by: Kyungmin Park 
---
Changes for v2:
- Change the gamma table to 2-dimensional array
- Change the way to make index for brightness
- Make command functions to an array so that it can be called simply
- Change command id for reading device ID
- Change the way to handle the error condition
- Remove power variable, and use the same name variable in bl_dev
- Add the state FB_BLANK_NORMAL to represent the state which the panel
is working but blanked
- Miscellaneous changes to increase the readability and follow the
  coding-style standard

 drivers/gpu/drm/panel/Kconfig|   6 +
 drivers/gpu/drm/panel/Makefile   |   1 +
 drivers/gpu/drm/panel/panel-s6e63j0x03.c | 549
+++
 3 files changed, 556 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-s6e63j0x03.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index bee9f72..bc133e2 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -27,4 +27,10 @@ config DRM_PANEL_S6E8AA0
select DRM_MIPI_DSI
select VIDEOMODE_HELPERS

+config DRM_PANEL_S6E63J0X03
+   tristate "S6E63J0X03 DSI video mode panel"
+   depends on OF
+   select DRM_MIPI_DSI
+   select VIDEOMODE_HELPERS
+
 endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 8b92921..7f36dc2 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_DRM_PANEL_SIMPLE) += panel-simple.o
 obj-$(CONFIG_DRM_PANEL_LD9040) += panel-ld9040.o
 obj-$(CONFIG_DRM_PANEL_S6E8AA0) += panel-s6e8aa0.o
+obj-$(CONFIG_DRM_PANEL_S6E63J0X03) += panel-s6e63j0x03.o
diff --git a/drivers/gpu/drm/panel/panel-s6e63j0x03.c
b/drivers/gpu/drm/panel/panel-s6e63j0x03.c
new file mode 100644
index 000..28e4a51
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-s6e63j0x03.c
@@ -0,0 +1,549 @@
+/*
+ * MIPI-DSI based S6E63J0X03 AMOLED lcd 1.63 inch panel driver.
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ *
+ * Inki Dae, 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define READ_ID1   0xDA
+#define READ_ID2   0xDB
+#define READ_ID3   0xDC
+
+#define MCS_LEVEL2_KEY 0xf0
+#define MCS_MTP_KEY0xf1
+#define MCS_MTP_SET3   0xd4
+
+#define MIN_BRIGHTNESS 0
+#define MAX_BRIGHTNESS 100
+#define DEFAULT_BRIGHTNESS 80
+
+#define GAMMA_LEVEL_NUM30
+#define NUM_GAMMA_STEPS9
+#define GAMMA_CMD_CNT  28
+
+struct s6e63j0x03 {
+   struct device *dev;
+   struct drm_panel panel;
+   struct backlight_device *bl_dev;
+
+   struct regulator_bulk_data supplies[2];
+   struct gpio_desc *reset_gpio;
+   u32 power_on_delay;
+   u32 power_off_delay;
+   u32 reset_delay;
+   u32 init_delay;
+   bool flip_horizontal;
+   bool flip_vertical;
+   struct videomode vm;
+   unsigned int width_mm;
+   unsigned int height_mm;
+};
+
+static const unsigned char gamma_tbl[NUM_GAMMA_STEPS][GAMMA_CMD_CNT] = {
+   {   /* Gamma 10 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x7f, 0x7f, 0x7f, 0x52, 0x6b, 0x6f, 0x26,
+   0x28, 0x2d, 0x28, 0x26, 0x27, 0x33, 0x34, 0x32, 0x36, 0x36,
+   0x35, 0x00, 0xab, 0x00, 0xae, 0x00, 0xbf
+   },
+   {   /* gamma 30 */
+   MCS_MTP_SET3,
+   0x00, 0x00, 0x00, 0x70, 0x7f, 0x7f, 0x4e, 0x64, 0x69, 0x26,
+   0x27, 0x2a, 0x28, 0x29, 0x27, 0x31, 0x32, 0x31, 0x35, 0x34,
+   0x35, 0x00, 0xc4, 0x00, 0xca, 0x00, 0xdc
+   },
+   {   /* gamma 60 */
+   MCS_MTP_SET3,
+   0x00, 

[Bug 85320] [RV620][RV630][RS880] GPU hangs using UVD hardware acceleration

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

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

--- Comment #31 from Maxim Kachur  ---
I think I have the same on RS880 here (HD4290).
Mesa 10.3.5, libdrm 2.4.58, kernel 3.18.1, R600_rlm.bin + RS780_uvd.bin
firmware from August 2014.
Testing with mplayer + vdpau.

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

[PATCH v2 2/3] drm/panel: add s6e63j0x03 LCD panel driver

[Inki Dae]

On 2015년 01월 05일 23:19, Thierry Reding wrote:
> On Wed, Dec 31, 2014 at 07:41:43PM +0900, Inki Dae wrote:
>> Hi Thierry,
>>
>> Ping~.
>>
>> Or is it ok to pick up this patch to my tree, exynos-drm-next? It
>> doesn't seem to care for a long time.
> 
> I don't seem to have a copy of the v2 2/3 patch. All I found in my inbox
> is the v2 0/3 cover-letter. Please resend with me in Cc so that I can
> properly review (and apply) the patch.

Please, refer to below link,
http://lists.freedesktop.org/archives/dri-devel/2014-December/073666.html

We already sent it with you in Cc. Anyway, I will resend it.

Thanks,
Inki Dae

> 
> Thierry
>