[PATCH v2] dma-buf: add ref counting for module as exporter
On Thu, May 07, 2015 at 06:58:44PM +0530, Sumit Semwal wrote: > Add reference counting on a kernel module that exports dma-buf and > implements its operations. This prevents the module from being unloaded > while DMABUF file is in use. > > The original patch [1] was submitted by Tomasz Stanislawski, but this > is a simpler way to do it. > > v2: move owner to struct dma_buf, and use DEFINE_DMA_BUF_EXPORT_INFO > macro to simplify the change. > > Signed-off-by: Sumit Semwal > > [1]: https://lkml.org/lkml/2012/8/8/163 > --- > drivers/dma-buf/dma-buf.c | 10 +- > include/linux/dma-buf.h | 10 -- > 2 files changed, 17 insertions(+), 3 deletions(-) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index c5a9138a6a8d..0eff4bf56ef6 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -29,6 +29,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -64,6 +65,7 @@ static int dma_buf_release(struct inode *inode, struct file > *file) > BUG_ON(dmabuf->cb_shared.active || dmabuf->cb_excl.active); > > dmabuf->ops->release(dmabuf); > + module_put(dmabuf->owner); The module can now go away. > > mutex_lock(&db_list.lock); > list_del(&dmabuf->list_node); But you reference it here :( Please drop the reference at the last possible moment. thanks, greg k-h
[Bug 90266] Unigine Heaven 4.0 logging vm faults since radeon/llvm: Run LLVM's instruction combining pass
https://bugs.freedesktop.org/show_bug.cgi?id=90266 --- Comment #6 from Tom Stellard --- Created attachment 115625 --> https://bugs.freedesktop.org/attachment.cgi?id=115625&action=edit Possible Fix This patch should fix the issue, can you test? -- 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/20150507/eefb36f9/attachment.html>
[i915]] *ERROR* mismatch in scaler_state.scaler_id
On (05/07/15 00:40), Konduru, Chandra wrote: > > Hi, > This error happens when crtc_state in driver not matching with hardware > registers. > On skylake board that I have, I am not able to reproduce the issue. > Can you send the system configuration and steps to reproduce the issue? > Also can you send the full dmesg.log file? > Hi, there are no specific steps, happens during boot and every time the screen goes unblank. attached dmesg, .config. ~$ lspci 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller (rev 06) 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller (rev 06) 00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) 00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06) 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 04) 00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04) 00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 (rev d4) 00:1c.5 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #6 (rev d4) 00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation HM86 Express LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 04) 00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 04) 01:00.0 3D controller: NVIDIA Corporation GK107M [GeForce GT 750M] (rev a1) 02:00.0 Network controller: Intel Corporation Wireless 7260 (rev 93) 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c) /* 01:00.0 3D controller: NVIDIA Corporation GK107M not used */ -ss -- next part -- [0.00] Initializing cgroup subsys cpu [0.00] Linux version 4.1.0-rc2-next-20150505-dbg-00010-gcf45f25-dirty (ss at swordfish) (gcc version 5.1.0 (GCC) ) #80 SMP Wed May 6 21:46:04 KST 2015 [0.00] Command line: BOOT_IMAGE=/vmlinuz-4.1.0-rc2-next-20150505-dbg-00010-gcf45f25-dirty root=UUID=5fb878c3-78ec-4208-bccf-de546dffa41e rw init=/usr/lib/systemd/systemd [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x00057fff] usable [0.00] BIOS-e820: [mem 0x00058000-0x00058fff] reserved [0.00] BIOS-e820: [mem 0x00059000-0x0009dfff] usable [0.00] BIOS-e820: [mem 0x0009e000-0x0009] reserved [0.00] BIOS-e820: [mem 0x0010-0xbbd99fff] usable [0.00] BIOS-e820: [mem 0xbbd9a000-0xbbda0fff] ACPI NVS [0.00] BIOS-e820: [mem 0xbbda1000-0xbc1e0fff] usable [0.00] BIOS-e820: [mem 0xbc1e1000-0xbc53efff] reserved [0.00] BIOS-e820: [mem 0xbc53f000-0xcb010fff] usable [0.00] BIOS-e820: [mem 0xcb011000-0xcb09dfff] reserved [0.00] BIOS-e820: [mem 0xcb09e000-0xcb0b7fff] ACPI data [0.00] BIOS-e820: [mem 0xcb0b8000-0xcb8bbfff] ACPI NVS [0.00] BIOS-e820: [mem 0xcb8bc000-0xcbf79fff] reserved [0.00] BIOS-e820: [mem 0xcbf7a000-0xcbffefff] type 20 [0.00] BIOS-e820: [mem 0xcbfff000-0xcbff] usable [0.00] BIOS-e820: [mem 0xcd00-0xcf1f] reserved [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00042fdf] usable [0.00] NX (Execute Disable) protection: active [0.00] DMI not present or invalid. [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x42fe00 max_arch_pfn = 0x4 [0.00] MTRR default type: un
Radeon Verde displayport failure.
I just bought a new radeon (1002:682c), to pair with my shiny new displayport monitor. It shows a display during through the BIOS POST, and grub, but when the kernel starts up, it's a coin toss whether or not I get anything. Sometimes it just goes straight into power saving. When I do get something on the console, it continues to boot and then X starts up and puts it into power saving too. Trying to flip back to tty1 doesn't light up the display again. I'm running On debian stable, with copied-by-hand verde_* firmware files from the linux-firmware git tree. Here's a log from the 4.0-rc2 kernel. Any other info I can provide ? Dave [drm] register mmio base: 0xFBE0 [drm] register mmio size: 262144 radeon :01:00.0: Invalid ROM contents ATOM BIOS: C755 radeon :01:00.0: VRAM: 2048M 0x - 0x7FFF (2048M used) radeon :01:00.0: GTT: 1024M 0x8000 - 0xBFFF [drm] Detected VRAM RAM=2048M, BAR=256M [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 16400232 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator [TTM] Initializing DMA pool allocator [drm] radeon: 2048M of VRAM memory ready [drm] radeon: 1024M of GTT memory ready. [drm] Loading verde Microcode [drm] Internal thermal controller with fan control [drm] probing gen 2 caps for device 8086:2f08 = 77a3103/e input: HDA ATI HDMI HDMI as /devices/pci:00/:00:03.0/:01:00.1/sound/card0/input4 input: HDA ATI HDMI HDMI as /devices/pci:00/:00:03.0/:01:00.1/sound/card0/input5 [drm] radeon: dpm initialized [drm] GART: num cpu pages 262144, num gpu pages 262144 [drm] probing gen 2 caps for device 8086:2f08 = 77a3103/e [drm] PCIE gen 3 link speeds already enabled [drm] PCIE GART of 1024M enabled (table at 0x00277000). radeon :01:00.0: WB enabled radeon :01:00.0: fence driver on ring 0 use gpu addr 0x8c00 and cpu addr 0x880807d0ac00 radeon :01:00.0: fence driver on ring 1 use gpu addr 0x8c04 and cpu addr 0x880807d0ac04 radeon :01:00.0: fence driver on ring 2 use gpu addr 0x8c08 and cpu addr 0x880807d0ac08 radeon :01:00.0: fence driver on ring 3 use gpu addr 0x8c0c and cpu addr 0x880807d0ac0c radeon :01:00.0: fence driver on ring 4 use gpu addr 0x8c10 and cpu addr 0x880807d0ac10 radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00075a18 and cpu addr 0xc90001035a18 [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] Driver supports precise vblank timestamp query. radeon :01:00.0: radeon: MSI limited to 32-bit radeon :01:00.0: radeon: using MSI. [drm] radeon: irq initialized. [drm] ring test on 0 succeeded in 1 usecs [drm] ring test on 1 succeeded in 1 usecs [drm] ring test on 2 succeeded in 1 usecs [drm] ring test on 3 succeeded in 9 usecs [drm] ring test on 4 succeeded in 3 usecs [drm] ring test on 5 succeeded in 2 usecs [drm] UVD initialized successfully. [drm] ib test on ring 0 succeeded in 0 usecs [drm] ib test on ring 1 succeeded in 0 usecs [drm] ib test on ring 2 succeeded in 0 usecs [drm] ib test on ring 3 succeeded in 0 usecs [drm] ib test on ring 4 succeeded in 0 usecs [drm] ib test on ring 5 succeeded [drm] Radeon Display Connectors [drm] Connector 0: [drm] DP-1 [drm] HPD4 [drm] DDC: 0x6540 0x6540 0x6544 0x6544 0x6548 0x6548 0x654c 0x654c [drm] Encoders: [drm] DFP1: INTERNAL_UNIPHY2 [drm] Connector 1: [drm] DP-2 [drm] HPD5 [drm] DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c [drm] Encoders: [drm] DFP2: INTERNAL_UNIPHY1 [drm] Connector 2: [drm] DP-3 [drm] HPD1 [drm] DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568 0x656c 0x656c [drm] Encoders: [drm] DFP3: INTERNAL_UNIPHY1 [drm] Connector 3: [drm] DP-4 [drm] HPD2 [drm] DDC: 0x6580 0x6580 0x6584 0x6584 0x6588 0x6588 0x658c 0x658c [drm] Encoders: [drm] DFP4: INTERNAL_UNIPHY [drm:si_dpm_set_power_state [radeon]] *ERROR* si_enable_smc_cac failed [drm] fb mappable at 0xD047A000 [drm] vram apper at 0xD000 [drm] size 3145728 [drm] fb depth is 24 [drm]pitch is 4096 fbcon: radeondrmfb (fb0) is primary device [drm:si_dpm_set_power_state [radeon]] *ERROR* si_enable_smc_cac failed [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed Console: switching to colour frame buffer device 128x48 radeon :01:00.0: fb0: radeondrmfb frame buffer device radeon :01:00.0: registered panic notifier [drm] Initialized radeon 2.42.0 20080528 for :01:00.0 on minor 0 [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
[PATCH] drm/radeon: add a GPU reset counter queryable by userspace
On 07.05.2015 19:13, Marek Olšák wrote:
> Ping
>
> On Wed, Apr 29, 2015 at 7:40 PM, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> Userspace will be able to tell whether a GPU reset occured by comparing
>> an old referece value of the counter with a new value.
>>
>> Signed-off-by: Marek Olšák
Reviewed-by: Christian König
>> ---
>> drivers/gpu/drm/radeon/radeon.h| 1 +
>> drivers/gpu/drm/radeon/radeon_device.c | 2 ++
>> drivers/gpu/drm/radeon/radeon_drv.c| 3 ++-
>> drivers/gpu/drm/radeon/radeon_kms.c| 3 +++
>> include/uapi/drm/radeon_drm.h | 1 +
>> 5 files changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon.h
>> b/drivers/gpu/drm/radeon/radeon.h
>> index d2abe48..c2b345a 100644
>> --- a/drivers/gpu/drm/radeon/radeon.h
>> +++ b/drivers/gpu/drm/radeon/radeon.h
>> @@ -2436,6 +2436,7 @@ struct radeon_device {
>> atomic64_t vram_usage;
>> atomic64_t gtt_usage;
>> atomic64_t num_bytes_moved;
>> + atomic_tgpu_reset_counter;
>> /* ACPI interface */
>> struct radeon_atif atif;
>> struct radeon_atcs atcs;
>> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
>> b/drivers/gpu/drm/radeon/radeon_device.c
>> index b7ca4c5..13e207e 100644
>> --- a/drivers/gpu/drm/radeon/radeon_device.c
>> +++ b/drivers/gpu/drm/radeon/radeon_device.c
>> @@ -1725,6 +1725,8 @@ int radeon_gpu_reset(struct radeon_device *rdev)
>> return 0;
>> }
>>
>> + atomic_inc(&rdev->gpu_reset_counter);
>> +
>> radeon_save_bios_scratch_regs(rdev);
>> /* block TTM */
>> resched = ttm_bo_lock_delayed_workqueue(&rdev->mman.bdev);
>> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
>> b/drivers/gpu/drm/radeon/radeon_drv.c
>> index 7d620d4..5751446 100644
>> --- a/drivers/gpu/drm/radeon/radeon_drv.c
>> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
>> @@ -90,9 +90,10 @@
>>*CS to GPU on >= r600
>>* 2.41.0 - evergreen/cayman: Add SET_BASE/DRAW_INDIRECT command parsing
>> support
>>* 2.42.0 - Add VCE/VUI (Video Usability Information) support
>> + * 2.43.0 - RADEON_INFO_GPU_RESET_COUNTER
>>*/
>> #define KMS_DRIVER_MAJOR 2
>> -#define KMS_DRIVER_MINOR 42
>> +#define KMS_DRIVER_MINOR 43
>> #define KMS_DRIVER_PATCHLEVEL 0
>> int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
>> int radeon_driver_unload_kms(struct drm_device *dev);
>> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
>> b/drivers/gpu/drm/radeon/radeon_kms.c
>> index 7b2a733..9632e88 100644
>> --- a/drivers/gpu/drm/radeon/radeon_kms.c
>> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
>> @@ -576,6 +576,9 @@ static int radeon_info_ioctl(struct drm_device *dev,
>> void *data, struct drm_file
>> if (radeon_get_allowed_info_register(rdev, *value, value))
>> return -EINVAL;
>> break;
>> + case RADEON_INFO_GPU_RESET_COUNTER:
>> + *value = atomic_read(&rdev->gpu_reset_counter);
>> + break;
>> default:
>> DRM_DEBUG_KMS("Invalid request %d\n", info->request);
>> return -EINVAL;
>> diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
>> index 871e73f..573cb86 100644
>> --- a/include/uapi/drm/radeon_drm.h
>> +++ b/include/uapi/drm/radeon_drm.h
>> @@ -1038,6 +1038,7 @@ struct drm_radeon_cs {
>> #define RADEON_INFO_CURRENT_GPU_SCLK 0x22
>> #define RADEON_INFO_CURRENT_GPU_MCLK 0x23
>> #define RADEON_INFO_READ_REG 0x24
>> +#define RADEON_INFO_GPU_RESET_COUNTER 0x25
>>
>> struct drm_radeon_info {
>> uint32_trequest;
>> --
>> 2.1.0
>>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Intel-gfx] [PATCH] drm/vblank: Fixup and document timestamp update/read barriers
On 05/07/2015 01:56 PM, Peter Hurley wrote:
> On 05/06/2015 04:56 AM, Daniel Vetter wrote:
>> On Tue, May 05, 2015 at 11:57:42AM -0400, Peter Hurley wrote:
>>> On 05/05/2015 11:42 AM, Daniel Vetter wrote:
On Tue, May 05, 2015 at 10:36:24AM -0400, Peter Hurley wrote:
> On 05/04/2015 12:52 AM, Mario Kleiner wrote:
>> On 04/16/2015 03:03 PM, Daniel Vetter wrote:
>>> On Thu, Apr 16, 2015 at 08:30:55AM -0400, Peter Hurley wrote:
On 04/15/2015 01:31 PM, Daniel Vetter wrote:
> On Wed, Apr 15, 2015 at 09:00:04AM -0400, Peter Hurley wrote:
>> Hi Daniel,
>>
>> On 04/15/2015 03:17 AM, Daniel Vetter wrote:
>>> This was a bit too much cargo-culted, so lets make it solid:
>>> - vblank->count doesn't need to be an atomic, writes are always done
>>> under the protection of dev->vblank_time_lock. Switch to an
>>> unsigned
>>> long instead and update comments. Note that atomic_read is just
>>> a
>>> normal read of a volatile variable, so no need to audit all the
>>> read-side access specifically.
>>>
>>> - The barriers for the vblank counter seqlock weren't complete: The
>>> read-side was missing the first barrier between the counter
>>> read and
>>> the timestamp read, it only had a barrier between the ts and the
>>> counter read. We need both.
>>>
>>> - Barriers weren't properly documented. Since barriers only work if
>>> you have them on boths sides of the transaction it's prudent to
>>> reference where the other side is. To avoid duplicating the
>>> write-side comment 3 times extract a little store_vblank()
>>> helper.
>>> In that helper also assert that we do indeed hold
>>> dev->vblank_time_lock, since in some cases the lock is acquired
>>> a
>>> few functions up in the callchain.
>>>
>>> Spotted while reviewing a patch from Chris Wilson to add a fastpath
>>> to
>>> the vblank_wait ioctl.
>>>
>>> Cc: Chris Wilson
>>> Cc: Mario Kleiner
>>> Cc: Ville Syrjälä
>>> Cc: Michel Dänzer
>>> Signed-off-by: Daniel Vetter
>>> ---
>>>drivers/gpu/drm/drm_irq.c | 92
>>> ---
>>>include/drm/drmP.h| 8 +++--
>>>2 files changed, 54 insertions(+), 46 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
>>> index c8a34476570a..23bfbc61a494 100644
>>> --- a/drivers/gpu/drm/drm_irq.c
>>> +++ b/drivers/gpu/drm/drm_irq.c
>>> @@ -74,6 +74,33 @@ module_param_named(vblankoffdelay,
>>> drm_vblank_offdelay, int, 0600);
>>>module_param_named(timestamp_precision_usec,
>>> drm_timestamp_precision, int, 0600);
>>>module_param_named(timestamp_monotonic, drm_timestamp_monotonic,
>>> int, 0600);
>>>
>>> +static void store_vblank(struct drm_device *dev, int crtc,
>>> + unsigned vblank_count_inc,
>>> + struct timeval *t_vblank)
>>> +{
>>> +struct drm_vblank_crtc *vblank = &dev->vblank[crtc];
>>> +u32 tslot;
>>> +
>>> +assert_spin_locked(&dev->vblank_time_lock);
>>> +
>>> +if (t_vblank) {
>>> +tslot = vblank->count + vblank_count_inc;
>>> +vblanktimestamp(dev, crtc, tslot) = *t_vblank;
>>> +}
>>> +
>>> +/*
>>> + * vblank timestamp updates are protected on the write side
>>> with
>>> + * vblank_time_lock, but on the read side done locklessly
>>> using a
>>> + * sequence-lock on the vblank counter. Ensure correct
>>> ordering using
>>> + * memory barrriers. We need the barrier both before and also
>>> after the
>>> + * counter update to synchronize with the next timestamp write.
>>> + * The read-side barriers for this are in
>>> drm_vblank_count_and_time.
>>> + */
>>> +smp_wmb();
>>> +vblank->count += vblank_count_inc;
>>> +smp_wmb();
>>
>> The comment and the code are each self-contradictory.
>>
>> If vblank->count writes are always protected by vblank_time_lock
>> (something I
>> did not verify but that the comment above asserts), then the
>> trailing write
>> barrier is not required (and the assertion that it is in the comment
>> is incorrect).
>>
>> A spin unlock operation is always a write barrier.
>
> Hm yeah. Otoh to me that's bordering on "code too clever for my own
>>
[PATCH] drm/radeon: add a GPU reset counter queryable by userspace
Ping
On Wed, Apr 29, 2015 at 7:40 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> Userspace will be able to tell whether a GPU reset occured by comparing
> an old referece value of the counter with a new value.
>
> Signed-off-by: Marek Olšák
> ---
> drivers/gpu/drm/radeon/radeon.h| 1 +
> drivers/gpu/drm/radeon/radeon_device.c | 2 ++
> drivers/gpu/drm/radeon/radeon_drv.c| 3 ++-
> drivers/gpu/drm/radeon/radeon_kms.c| 3 +++
> include/uapi/drm/radeon_drm.h | 1 +
> 5 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index d2abe48..c2b345a 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -2436,6 +2436,7 @@ struct radeon_device {
> atomic64_t vram_usage;
> atomic64_t gtt_usage;
> atomic64_t num_bytes_moved;
> + atomic_tgpu_reset_counter;
> /* ACPI interface */
> struct radeon_atif atif;
> struct radeon_atcs atcs;
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> b/drivers/gpu/drm/radeon/radeon_device.c
> index b7ca4c5..13e207e 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -1725,6 +1725,8 @@ int radeon_gpu_reset(struct radeon_device *rdev)
> return 0;
> }
>
> + atomic_inc(&rdev->gpu_reset_counter);
> +
> radeon_save_bios_scratch_regs(rdev);
> /* block TTM */
> resched = ttm_bo_lock_delayed_workqueue(&rdev->mman.bdev);
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 7d620d4..5751446 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -90,9 +90,10 @@
> *CS to GPU on >= r600
> * 2.41.0 - evergreen/cayman: Add SET_BASE/DRAW_INDIRECT command parsing
> support
> * 2.42.0 - Add VCE/VUI (Video Usability Information) support
> + * 2.43.0 - RADEON_INFO_GPU_RESET_COUNTER
> */
> #define KMS_DRIVER_MAJOR 2
> -#define KMS_DRIVER_MINOR 42
> +#define KMS_DRIVER_MINOR 43
> #define KMS_DRIVER_PATCHLEVEL 0
> int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
> int radeon_driver_unload_kms(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index 7b2a733..9632e88 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -576,6 +576,9 @@ static int radeon_info_ioctl(struct drm_device *dev, void
> *data, struct drm_file
> if (radeon_get_allowed_info_register(rdev, *value, value))
> return -EINVAL;
> break;
> + case RADEON_INFO_GPU_RESET_COUNTER:
> + *value = atomic_read(&rdev->gpu_reset_counter);
> + break;
> default:
> DRM_DEBUG_KMS("Invalid request %d\n", info->request);
> return -EINVAL;
> diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
> index 871e73f..573cb86 100644
> --- a/include/uapi/drm/radeon_drm.h
> +++ b/include/uapi/drm/radeon_drm.h
> @@ -1038,6 +1038,7 @@ struct drm_radeon_cs {
> #define RADEON_INFO_CURRENT_GPU_SCLK 0x22
> #define RADEON_INFO_CURRENT_GPU_MCLK 0x23
> #define RADEON_INFO_READ_REG 0x24
> +#define RADEON_INFO_GPU_RESET_COUNTER 0x25
>
> struct drm_radeon_info {
> uint32_trequest;
> --
> 2.1.0
>
[PATCH v2] dma-buf: add ref counting for module as exporter
Add reference counting on a kernel module that exports dma-buf and
implements its operations. This prevents the module from being unloaded
while DMABUF file is in use.
The original patch [1] was submitted by Tomasz Stanislawski, but this
is a simpler way to do it.
v2: move owner to struct dma_buf, and use DEFINE_DMA_BUF_EXPORT_INFO
macro to simplify the change.
Signed-off-by: Sumit Semwal
[1]: https://lkml.org/lkml/2012/8/8/163
---
drivers/dma-buf/dma-buf.c | 10 +-
include/linux/dma-buf.h | 10 --
2 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index c5a9138a6a8d..0eff4bf56ef6 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -64,6 +65,7 @@ static int dma_buf_release(struct inode *inode, struct file
*file)
BUG_ON(dmabuf->cb_shared.active || dmabuf->cb_excl.active);
dmabuf->ops->release(dmabuf);
+ module_put(dmabuf->owner);
mutex_lock(&db_list.lock);
list_del(&dmabuf->list_node);
@@ -302,14 +304,20 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
return ERR_PTR(-EINVAL);
}
+ if (!try_module_get(exp_info->owner))
+ return ERR_PTR(-ENOENT);
+
dmabuf = kzalloc(alloc_size, GFP_KERNEL);
- if (dmabuf == NULL)
+ if (!dmabuf) {
+ module_put(exp_info->owner);
return ERR_PTR(-ENOMEM);
+ }
dmabuf->priv = exp_info->priv;
dmabuf->ops = exp_info->ops;
dmabuf->size = exp_info->size;
dmabuf->exp_name = exp_info->exp_name;
+ dmabuf->owner = exp_info->owner;
init_waitqueue_head(&dmabuf->poll);
dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = &dmabuf->poll;
dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0;
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 2f0b431b73e0..f98bd7068d55 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -115,6 +115,8 @@ struct dma_buf_ops {
* @attachments: list of dma_buf_attachment that denotes all devices attached.
* @ops: dma_buf_ops associated with this buffer object.
* @exp_name: name of the exporter; useful for debugging.
+ * @owner: pointer to exporter module; used for refcounting when exporter is a
+ * kernel module.
* @list_node: node for dma_buf accounting and debugging.
* @priv: exporter specific private data for this buffer object.
* @resv: reservation object linked to this dma-buf
@@ -129,6 +131,7 @@ struct dma_buf {
unsigned vmapping_counter;
void *vmap_ptr;
const char *exp_name;
+ struct module *owner;
struct list_head list_node;
void *priv;
struct reservation_object *resv;
@@ -164,7 +167,8 @@ struct dma_buf_attachment {
/**
* struct dma_buf_export_info - holds information needed to export a dma_buf
- * @exp_name: name of the exporting module - useful for debugging.
+ * @exp_name: name of the exporter - useful for debugging.
+ * @owner: pointer to exporter module - used for refcounting kernel module
* @ops: Attach allocator-defined dma buf ops to the new buffer
* @size: Size of the buffer
* @flags: mode flags for the file
@@ -176,6 +180,7 @@ struct dma_buf_attachment {
*/
struct dma_buf_export_info {
const char *exp_name;
+ struct module *owner;
const struct dma_buf_ops *ops;
size_t size;
int flags;
@@ -187,7 +192,8 @@ struct dma_buf_export_info {
* helper macro for exporters; zeros and fills in most common values
*/
#define DEFINE_DMA_BUF_EXPORT_INFO(a) \
- struct dma_buf_export_info a = { .exp_name = KBUILD_MODNAME }
+ struct dma_buf_export_info a = { .exp_name = KBUILD_MODNAME, \
+.owner = THIS_MODULE }
/**
* get_dma_buf - convenience wrapper for get_file.
--
1.9.1
[PULL] drm-amdkfd-fixes
Hi Dave, Please pull the following three bug fixes for next -rc: - Add missing initialization of SDMA vm register when creating an SDMA queue - Don't report local memory size, as we don't support local memory allocation yet. - Allow to unregister process with exisiting queues. Until now we blocked it with BUG_ON, which was also an error by itself. All three fixes are marked as stable. Thanks, Oded The following changes since commit 5ebe6afaf0057ac3eaeb98defd5456894b446d22: Linux 4.1-rc2 (2015-05-03 19:22:23 -0700) are available in the git repository at: git://people.freedesktop.org/~gabbayo/linux tags/drm-amdkfd-fixes-2015-05-07 for you to fetch changes up to 79b066bd76d501cfe8328142153da301f5ca11d1: drm/amdkfd: Initialize sdma vm when creating sdma queue (2015-05-07 17:38:06 +0300) Oded Gabbay (2): drm/amdkfd: allow unregister process with queues drm/amdkfd: Don't report local memory size Xihan Zhang (1): drm/amdkfd: Initialize sdma vm when creating sdma queue drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 7 +-- drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 4 ++-- 2 files changed, 7 insertions(+), 4 deletions(-)
[RFT PATCH v2 0/3] drm/exynos: Fix build breakage on !DRM_EXYNOS_FIMD
2015-05-07 18:16 GMT+09:00 Javier Martinez Canillas
:
> Hello Krzysztof,
>
> On 05/07/2015 02:04 AM, Krzysztof Kozlowski wrote:
>> From: Krzysztof Kozlowski
>>
>> Hi,
>>
>> This is second try to fix the build breakage introduced in 1c363c7cccf6
>> ("drm/exynos: Enable DP clock to fix display on Exynos5250 and other").
>>
>> The fix is not trivial so I am kindly asking for testing on Chromebook
>> and other DP-enabled boards (I don't have Chromebook right now).
>>
>
> For all the series:
>
> Reviewed-by: Javier Martinez Canillas
>
>> Tested on Exynos4412 Trats2 board.
>>
>
> On Exynos5250 Snow, Exynos5420 Peach Pit and Exynos5800 Peach Pi Chromebooks:
>
> Tested-by: Javier Martinez Canillas
Thanks, your help is appreciated.
Krzysztof
Some issues with the new amdgpu driver
On 06.05.2015 12:12, Brian Paterni wrote: > > I was on irc a few days ago trying to get the new amdgpu driver up and > running on my system. I am able to get the kernel booted successfully, > however X via amdgpu is turning out to be a real roadblock. It is the > problem with amdgpu_drv.so seeing gbm_create_device as an undefined > symbol. From what little I understand, I may be needing a more recent > xserver to resolve this... I don't think that would help. Does the attached xf86-video-amdgpu patch fix the problem? If not, you can manually load the glamoregl module in /etc/X11/xorg.conf to pull in libgbm: Section "Module" Load"glamoregl" EndSection -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer -- next part -- A non-text attachment was scrubbed... Name: 0001-Link-against-libgbm.patch Type: text/x-patch Size: 1635 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150507/8cadd306/attachment.bin>
[PATCH 0/5] drm/exynos: rework layer blending setup
2015-05-06 Tobias Jakobi : > Hello, > > this is a rework of the layer blending setup in the Exynos DRM mixer. The > current setup is static and spread out through the mixer code. This rework > pushes all the configuration details into a layer_config array, which > specifies the priority of each layer. > > Two arrays are currently found in the code, one for SoC versions with a video > processor (VP) and one for SoC versions without VP. The VP gives us one > additional layer, the video layer, which natively supports the NV12/NV21 > pixelformat. > > The blending setup roughly works like this: > 1) Find the bottom-most enabled layer. Disable all blending for this layer. > This is done because we currently don't expose modification of the mixer > background to userspace. Once this is done we can add more flexibility here. > 2) Find the next enabled layer in our layer stack. If the layer has a > framebuffer with an alpha-pixelformat attached, enable blending for this > layer. If not, disable blending. > 3) Iterate (2) until all enabled layers are processed. > > The series has been tested on a Hardkernel Odroid-X2 (Exynos4412, which has a > VP). > > If you want to use libdrm's modetest to check the series, please apply > patches [1] and [2]. This should make it possible to also test a plane with > NV12 format (which is located 'behind' the primary plane). The whole series works fine for me on Samsung Snow 5250 (which doesn't have a VP). Tested-by: Gustavo Padovan Gustavo
[PATCH 2/2] drm/amdkfd: make the sdma vm init to be asic specific
On Tue, May 5, 2015 at 7:28 PM, Alex Deucher wrote: > On Tue, May 5, 2015 at 5:03 AM, Oded Gabbay wrote: >> Signed-off-by: Oded Gabbay >> --- > > Maybe call it, init_vm() in cause you need to do something queue > specific for other rings? Either way, this series is: > Reviewed-by: Alex Deucher > >> }; >> >From what I currently know, this is only required for sdma queues, because the vm info is in a register per queue. In compute queues, there are shared registers (sh_mem_*) so we don't need to init something per queue. -- Oded
[RFC] How implement Secure Data Path ?
On Thu, 7 May 2015 15:52:12 +0200 Daniel Vetter wrote: > On Thu, May 07, 2015 at 03:22:20PM +0200, Thierry Reding wrote: > > On Wed, May 06, 2015 at 03:15:32PM +0200, Daniel Vetter wrote: > > > Yes the idea would be a special-purpose allocater thing like ion. Might > > > even want that to be a syscall to do it properly. > > > > Would you care to elaborate why a syscall would be more proper? Not that > > I'm objecting to it, just for my education. > > It seems to be the theme with someone proposing a global /dev node for a > few system wide ioctls, then reviewers ask to make a proper ioctl out of > it. E.g. kdbus, but I have vague memory of this happening a lot. kdbus is not necessarily an advert for how to do anything 8) If it can be user allocated then it really ought to be one or more device nodes IMHO, because you want the resource to be passable between users, you need a handle to it and you want it to go away nicely on last close. In the cases where the CPU is allowed to or expected to have write only access you also might want an mmap of it. I guess the same kind of logic as with GEM (except preferably without the DoS security holes) applies as to why its useful to have handles to the DMA buffers. Alan
Initial amdgpu driver release
On Mon, Apr 20, 2015 at 6:33 PM, Alex Deucher wrote: > I'm pleased to announce the initial release of the new amdgpu driver. > This is a partial replacement for the radeon driver for newer AMD > asics. A number of components are still shared. Here is a comparison > of the radeon and amdgpu stacks: > > 1. radeon stack > kernel driver: radeon.ko > libdrm: libdrm_radeon > mesa: radeon, r200, r300, r600, radeonsi > ddx: xf86-video-ati > > 2. amdgpu stack > kernel driver: amdgpu.ko > libdrm: libdrm_amdgpu > mesa: radeonsi > ddx: xf86-video-amdgpu > > Older asics will continue to be supported by the radeon stack; new > asics will be supported by the amdgpu stack. CI (Sea Islands) asics > have support in both driver stacks, but this is purely for testing > purposes. CI parts are officially supported in the radeon stack. > Support for CI on the amdgpu stack is determined by a config option in > the kernel. CI support is not enabled by default for amdgpu. > > Most of our focus has been on Carrizo support, so there are some gaps > in the dGPU support for Tonga and Iceland, notably power management. > Those gaps will be filled in eventually. > > Also included in this code base are full register headers for just > about every block on the asics. > > Barring the gaps mentioned above, the driver stack is functionally on > par with radeon including: > - OpenGL 3.3 support using the radeonsi mesa driver > - Video decode support using UVD > - Video encode support using VCE > > The code can be found in the amdgpu branches of the following git trees. > xf86-video-amdgpu: > http://cgit.freedesktop.org/~agd5f/xf86-video-amdgpu/log/?h=amdgpu > libdrm: > http://cgit.freedesktop.org/~agd5f/drm/log/?h=amdgpu > kernel: > http://cgit.freedesktop.org/~agd5f/linux/log/?h=amdgpu > mesa: > http://cgit.freedesktop.org/~mareko/mesa/log/?h=amdgpu Some updates on the latest source locations: xf86-video-amdgpu: http://cgit.freedesktop.org/xorg/driver/xf86-video-amdgpu libdrm: http://cgit.freedesktop.org/~agd5f/drm/log/?h=amdgpu kernel: http://cgit.freedesktop.org/amd/drm-amd/ mesa: http://cgit.freedesktop.org/mesa/mesa/log/?h=amdgpu Alex > > To test the new driver stack you will need to specify a device section > in your xorg.conf with the driver set to amdgpu rather than radeon. > > Please review! > > Thanks, > > The AMD Linux Driver Team
[BUG] i915: suspend by closing Laptop lid broken
On Thu, 07 May 2015, Martin Kepplinger wrote: > Am 2015-05-04 um 13:24 schrieb Jani Nikula: >> On Mon, 04 May 2015, Martin Kepplinger wrote: >>> So. -rc1 broke suspending by closing my laptop lid and it's not fixed in >>> -rc2. It works exactly *one* first time and every subsequent lid-closing >>> is ignored. >>> >>> Biscted and tested first bad commit: >>> 14aa02449064541217836b9f3d3295e241d5ae9c >>> >>> This pulls in i915 changes as well as ACPI changes. I don't know the >>> driver but I'm sure you can find the mistake. I'm happy to test changes. >>> >>> There are no log differences. >> >> Any chance you could bisect into the merge? It would be helpful. >> >> BR, >> Jani. >> >> > > My attempt to go into the merge was too much effort as the checkouts in > between break random other stuff. This should obviously *not* be the case. :( > We should be between 09d51602cf84a1264946711dd4ea0dddbac599a1 (good) and > c0f404284192f2d4a0159a714372a8c8610c1f6d. Could you have a look and > maybe you have guesses for me, what I should test? It's not sooo much > anymore, maybe you even have a guess about the bug? $ git log --oneline 09d51602cf..c0f4042841 | grep drm/i915 | wc -l 286 Oof, I eyeballed the list, but didn't spot any obvious candidates. If a commit is inconclusive or borken in other ways, you could try git bisect skip to try another commit... BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
[RFC] How implement Secure Data Path ?
ting out platform nonsense.. not sure if it is exactly that > easy, since importing device probably needs to set some special bits > here and there.. I would expect there to be a central entity handing out the secure buffers and that the entity would have the ability to grant access to the buffers to devices. So I'm thinking that the exporter would deal with this in the ->attach() operation. That's passed a struct device, so we should be able to retrieve the information necessary somehow. Then again, maybe things will be more involved than that. I think the way this typically works in consumer devices is that you need to jump into secure firmware to get access granted. For example on Tegra most registers that control this are TrustZone-protected, so if you don't happen to be lucky enough to be running the kernel in secure mode you can't enable access to secure memory from the kernel. As Alan mentioned before this is designed with the assumption that the user is not to be trusted, so the OEM must make sure that the chain of trust is upheld. In practice that means that consumer devices will run some secure firmware that can't be replaced and which boots the kernel in non-secure mode, thereby disallowing the kernel from touching these registers that could potentially expose protected content to untrusted consumers. In practice I think the result is that secure firmware sets up secure memory (VPR on Tegra) and then lets the kernel know its geometry. The kernel is then free to manage the VPR as it sees fit. If the devices need to deal with both secure and non-secure memory, I'm not exactly sure how the above security model is supposed to hold. If the kernel is free to program any address into the device, then it would be easy to trick it into writing to some region that the CPU can access. I'm fairly sure that there's some mechanism to disallow that, but I don't know exactly how it's implemented. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150507/a2acca15/attachment.sig>
[PATCH v4 0/7] Use DRM component API in tilcdc to connect to tda998x
On 05/07/15 12:44, Tomi Valkeinen wrote:
>
> On 01/04/15 11:49, Jyri Sarha wrote:
>> Ok, let's do one more full review round. The mode filtering issue was
>> the main reason for this new patch series version. However, I found
>> couple other things to fix too after scrutinizing the patches once
>> more.
>>
>> Changes since v3 version of the patch-set:
>> * drm/tilcdc: Add support for external tda998x encoder
>> - Hijack external connectors helper functions
>> - Remove select of nonexistent DRM_TILCDC_INIT in tilcdc Kconfig
>> - Correct author mail address to tilcdc_exteral.h
>> * drm/tilcdc: Add DRM_TILCDC_SLAVE_COMPAT for ti,tilcdc,slave binding
>> - Add a header file for tilcdc_slave_compat.dtb symbol declarations
>>
>> Changes since v2 version of the patch-set:
>> - use obj-y in Makefle for tilcdc subdir in:
>>"drm/tilcdc: Force building of DRM_TILCDC_SLAVE_COMPAT"
>> - move to last:
>>"drm/tilcdc: Decrement refcount of ep-node from
>> of_graph_get_next_endpoint"
>>
>> Changes since first version of the patch-set:
>> - Rename DRM_TILCDC_INIT to DRM_TILCDC_SLAVE_COMPAT and make it visible
>> - Add separate:
>>drm/tilcdc: Decrement refcount of ep-node from of_graph_get_next_endpoint
>> - Reduce info-level spam
>> - Use component_master_add_with_match()
>> - Be more explicit about tda998x being the only supported external encoder
>>
>> Remove tilcdc slave support and connect to tda998x trough its
>> component DRM API. For dtb backward compatibility the code creates at
>> boot time a DT overlay based on the earlier binding. The overlay
>> conforms to the new graph based binding.
>>
>> The "drm/tilcdc: Decrement refcount of ep-node from
>> of_graph_get_next_endpoint" should probably not be merged. The "of:
>> Decrement refcount of previous endpoint in of_graph_get_next_endpoint"
>> is eventually going to be merged and before that leaking of two
>> of-node refcount increments each time the module is loaded is not that
>> serious. The of-nodes live forever anyway.
>>
>> The merge of the dts patch can be delayed until the next merger
>> window, when the other patches are already in. The
>> DRM_TILCDC_SLAVE_COMPAT should keep the bbb HDMI operational until
>> then.
>
> I made a quick test on v4.1-rc2, and:
>
What did you do to get this dump. The tilcdc driver has not done much at
this point. There is basically noting before calling this function:
int tilcdc_get_external_components(struct device *dev,
struct component_match **match)
{
struct device_node *ep = NULL;
int count = 0;
while ((ep = of_graph_get_next_endpoint(dev->of_node, ep))) {
struct device_node *node;
node = of_graph_get_remote_port_parent(ep);
if (!node && !of_device_is_available(node)) {
of_node_put(node);
continue;
}
dev_dbg(dev, "Subdevice node '%s' found\n", node->name);
if (match)
component_match_add(dev, match, dev_match_of, node);
of_node_put(node);
count++;
}
if (count > 1) {
dev_err(dev, "Only one external encoder is supported\n");
return -EINVAL;
}
return count;
}
If there is something wrong with the function I would certainly like to
know what. Or is the bug somewhere else?
Best regards,
Jyri
> [ 15.199584] [drm] Initialized drm 1.1.0 20060810
> [ 15.319496] BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:616
> [ 15.328339] in_atomic(): 1, irqs_disabled(): 128, pid: 130, name: insmod
> [ 15.335336] 3 locks held by insmod/130:
> [ 15.339339] #0: (&dev->mutex){..}, at: []
> __driver_attach+0x50/0xa0
> [ 15.347389] #1: (&dev->mutex){..}, at: []
> __driver_attach+0x60/0xa0
> [ 15.355420] #2: (devtree_lock){..}, at: []
> of_get_next_child+0x20/0x4c
> [ 15.363731] irq event stamp: 5750
> [ 15.367189] hardirqs last enabled at (5749): []
> _raw_spin_unlock_irqrestore+0x38/0x64
> [ 15.376377] hardirqs last disabled at (5750): []
> _raw_spin_lock_irqsave+0x24/0x6c
> [ 15.385104] softirqs last enabled at (5200): []
> __do_softirq+0x318/0x710
> [ 15.393111] softirqs last disabled at (5147): []
> irq_exit+0xc4/0x138
> [ 15.400668] CPU: 0 PID: 130 Comm: insmod Not tainted
> 4.1.0-rc2-7-g877542591d33-dirty #22
> [ 15.409477] Hardware name: Generic AM33XX (Flattened Device Tree)
> [ 15.415837] Backtrace:
> [ 15.418403] [] (dump_backtrace) from []
> (show_stack+0x18/0x1c)
> [ 15.426306] r6:c08d04b0 r5:dd652000 r4: r3:
> [ 15.432257] [] (show_stack) from []
> (dump_stack+0x94/0xc8)
> [ 15.439810] [] (dump_stack) from []
> (___might_sleep+0x18c/0x294)
> [ 15.447893] r5:0268 r4:
> [ 15.451643] [] (___might_sleep) from []
> (__might_sleep+0x64/0xa4)
> [ 15.459816] r7:dd119280 r6:0
[PATCH] dma-buf: add ref counting for module as exporter
On 7 May 2015 at 13:40, Greg KH wrote:
> On Thu, May 07, 2015 at 01:00:52PM +0530, Sumit Semwal wrote:
>> Add reference counting on a kernel module that exports dma-buf and
>> implements its operations. This prevents the module from being unloaded
>> while DMABUF file is in use.
>>
>> The original patch [1] was submitted by Tomasz, but he's since shifted
>> jobs and a ping didn't elicit any response.
>>
>> [tomasz: Original author]
>> Signed-off-by: Tomasz Stanislawski
>> Acked-by: Daniel Vetter
>> [sumits: updated & rebased as per review comments]
>> Signed-off-by: Sumit Semwal
>>
>> [1]: https://lkml.org/lkml/2012/8/8/163
>> ---
>> drivers/dma-buf/dma-buf.c | 9 -
>> drivers/gpu/drm/armada/armada_gem.c| 1 +
>> drivers/gpu/drm/drm_prime.c| 1 +
>> drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 1 +
>> drivers/gpu/drm/i915/i915_gem_dmabuf.c | 1 +
>> drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 1 +
>> drivers/gpu/drm/tegra/gem.c| 1 +
>> drivers/gpu/drm/udl/udl_dmabuf.c | 1 +
>> drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 1 +
>> drivers/media/v4l2-core/videobuf2-dma-contig.c | 1 +
>> drivers/media/v4l2-core/videobuf2-dma-sg.c | 1 +
>> drivers/media/v4l2-core/videobuf2-vmalloc.c| 1 +
>> drivers/staging/android/ion/ion.c | 1 +
>> include/linux/dma-buf.h| 2 ++
>> 14 files changed, 22 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index c5a9138a6a8d..9583eac0238f 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -29,6 +29,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -64,6 +65,7 @@ static int dma_buf_release(struct inode *inode, struct
>> file *file)
>> BUG_ON(dmabuf->cb_shared.active || dmabuf->cb_excl.active);
>>
>> dmabuf->ops->release(dmabuf);
>> + module_put(dmabuf->ops->owner);
>>
>> mutex_lock(&db_list.lock);
>> list_del(&dmabuf->list_node);
>> @@ -302,9 +304,14 @@ struct dma_buf *dma_buf_export(const struct
>> dma_buf_export_info *exp_info)
>> return ERR_PTR(-EINVAL);
>> }
>>
>> + if (!try_module_get(exp_info->ops->owner))
>> + return ERR_PTR(-ENOENT);
>> +
>> dmabuf = kzalloc(alloc_size, GFP_KERNEL);
>> - if (dmabuf == NULL)
>> + if (!dmabuf) {
>> + module_put(exp_info->ops->owner);
>> return ERR_PTR(-ENOMEM);
>> + }
>>
>> dmabuf->priv = exp_info->priv;
>> dmabuf->ops = exp_info->ops;
>> diff --git a/drivers/gpu/drm/armada/armada_gem.c
>> b/drivers/gpu/drm/armada/armada_gem.c
>> index 580e10acaa3a..d2c5fc1269b7 100644
>> --- a/drivers/gpu/drm/armada/armada_gem.c
>> +++ b/drivers/gpu/drm/armada/armada_gem.c
>> @@ -524,6 +524,7 @@ armada_gem_dmabuf_mmap(struct dma_buf *buf, struct
>> vm_area_struct *vma)
>> }
>>
>> static const struct dma_buf_ops armada_gem_prime_dmabuf_ops = {
>> + .owner = THIS_MODULE,
>> .map_dma_buf= armada_gem_prime_map_dma_buf,
>> .unmap_dma_buf = armada_gem_prime_unmap_dma_buf,
>> .release= drm_gem_dmabuf_release,
>
> The "easier" way to do this is change the registration function to add
> the module owner automatically, which keeps you from having to modify
> all of the individual drivers. Look at how pci and usb do this for
> their driver registration functions. That should result in a much
> smaller patch, that always works properly for everyone (there's no way
> for driver to get it wrong.)
>
Thanks Greg; but of course, you're right! We already have a
DEFINE_DMA_BUF_EXPORT_INFO macro, so this is far easier incorporated
into that.
I will spin up the (much simpler) patch and repost!
> thanks,
>
> greg k-h
Best regards,
Sumit.
[Intel-gfx] [RFC PATCH 07/11] drm/i915: Expose PMU for Observation Architecture
On Thu, May 07, 2015 at 03:15:50PM +0100, Robert Bragg wrote:
> + /* We bypass the default perf core perf_paranoid_cpu() ||
> + * CAP_SYS_ADMIN check by using the PERF_PMU_CAP_IS_DEVICE
> + * flag and instead authenticate based on whether the current
> + * pid owns the specified context, or require CAP_SYS_ADMIN
> + * when collecting cross-context metrics.
> + */
> + dev_priv->oa_pmu.specific_ctx = NULL;
> + if (oa_attr.single_context) {
> + u32 ctx_id = oa_attr.ctx_id;
> + unsigned int drm_fd = oa_attr.drm_fd;
> + struct fd fd = fdget(drm_fd);
> +
> + if (fd.file) {
Specify a ctx and not providing the right fd should be its own error,
either EBADF or EINVAL.
> + dev_priv->oa_pmu.specific_ctx =
> + lookup_context(dev_priv, fd.file, ctx_id);
> + }
Missing fdput
> + }
> +
> + if (!dev_priv->oa_pmu.specific_ctx && !capable(CAP_SYS_ADMIN))
> + return -EACCES;
> +
> + mutex_lock(&dev_priv->dev->struct_mutex);
i915_mutex_interruptible, probably best to couple into the GPU error
handling here as well especially as init_oa_buffer() will go onto touch
GPU internals.
> + ret = init_oa_buffer(event);
> + mutex_unlock(&dev_priv->dev->struct_mutex);
> +
> + if (ret)
> + return ret;
> +
> + BUG_ON(dev_priv->oa_pmu.exclusive_event);
> + dev_priv->oa_pmu.exclusive_event = event;
> +
> + event->destroy = i915_oa_event_destroy;
> +
> + /* PRM - observability performance counters:
> + *
> + * OACONTROL, performance counter enable, note:
> + *
> + * "When this bit is set, in order to have coherent counts,
> + * RC6 power state and trunk clock gating must be disabled.
> + * This can be achieved by programming MMIO registers as
> + * 0xA094=0 and 0xA090[31]=1"
> + *
> + * In our case we are expected that taking pm + FORCEWAKE
> + * references will effectively disable RC6 and trunk clock
> + * gating.
> + */
> + intel_runtime_pm_get(dev_priv);
> + intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
That is a nuisance. Aside: Why isn't OA inside the powerctx? Is a subset
valid with forcewake? It does perturb the system greatly to disable rc6,
so I wonder if it could be made optional?
> +
> + return 0;
> +}
> +
> +static void update_oacontrol(struct drm_i915_private *dev_priv)
> +{
> + BUG_ON(!spin_is_locked(&dev_priv->oa_pmu.lock));
> +
> + if (dev_priv->oa_pmu.event_active) {
> + unsigned long ctx_id = 0;
> + bool pinning_ok = false;
> +
> + if (dev_priv->oa_pmu.specific_ctx) {
> + struct intel_context *ctx =
> + dev_priv->oa_pmu.specific_ctx;
> + struct drm_i915_gem_object *obj =
> + ctx->legacy_hw_ctx.rcs_state;
If only there was ctx->legacy_hw_ctx.rcs_vma...
> +
> + if (i915_gem_obj_is_pinned(obj)) {
> + ctx_id = i915_gem_obj_ggtt_offset(obj);
> + pinning_ok = true;
> + }
> + }
> +
> + if ((ctx_id == 0 || pinning_ok)) {
> + bool periodic = dev_priv->oa_pmu.periodic;
> + u32 period_exponent = dev_priv->oa_pmu.period_exponent;
> + u32 report_format = dev_priv->oa_pmu.oa_buffer.format;
> +
> + I915_WRITE(GEN7_OACONTROL,
> +(ctx_id & GEN7_OACONTROL_CTX_MASK) |
> +(period_exponent <<
> + GEN7_OACONTROL_TIMER_PERIOD_SHIFT) |
> +(periodic ?
> + GEN7_OACONTROL_TIMER_ENABLE : 0) |
> +(report_format <<
> + GEN7_OACONTROL_FORMAT_SHIFT) |
> +(ctx_id ?
> + GEN7_OACONTROL_PER_CTX_ENABLE : 0) |
> +GEN7_OACONTROL_ENABLE);
I notice you don't use any write barriers...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[RFC] How implement Secure Data Path ?
On Thu, May 07, 2015 at 03:22:20PM +0200, Thierry Reding wrote: > On Wed, May 06, 2015 at 03:15:32PM +0200, Daniel Vetter wrote: > > Yes the idea would be a special-purpose allocater thing like ion. Might > > even want that to be a syscall to do it properly. > > Would you care to elaborate why a syscall would be more proper? Not that > I'm objecting to it, just for my education. It seems to be the theme with someone proposing a global /dev node for a few system wide ioctls, then reviewers ask to make a proper ioctl out of it. E.g. kdbus, but I have vague memory of this happening a lot. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH] drm/msm: adreno a306 support
As found in apq8016 (used in DragonBoard 410c) and msm8916.
Note that numerically a306 is actually 307 (since a305c already claimed
306). Nice and confusing.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 12 +---
drivers/gpu/drm/msm/adreno/adreno_device.c | 8
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 6 ++
3 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index b66c53b..3d3db1d 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -93,7 +93,10 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
/* Set up AOOO: */
gpu_write(gpu, REG_A3XX_VBIF_OUT_AXI_AOOO_EN, 0x003c);
gpu_write(gpu, REG_A3XX_VBIF_OUT_AXI_AOOO, 0x003c003c);
-
+ } else if (adreno_is_a306(adreno_gpu)) {
+ gpu_write(gpu, REG_A3XX_VBIF_ROUND_ROBIN_QOS_ARB, 0x0003);
+ gpu_write(gpu, REG_A3XX_VBIF_OUT_RD_LIM_CONF0, 0x000a);
+ gpu_write(gpu, REG_A3XX_VBIF_OUT_WR_LIM_CONF0, 0x000a);
} else if (adreno_is_a320(adreno_gpu)) {
/* Set up 16 deep read/write request queues: */
gpu_write(gpu, REG_A3XX_VBIF_IN_RD_LIM_CONF0, 0x10101010);
@@ -186,7 +189,9 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
gpu_write(gpu, REG_A3XX_UCHE_CACHE_MODE_CONTROL_REG, 0x0001);
/* Enable Clock gating: */
- if (adreno_is_a320(adreno_gpu))
+ if (adreno_is_a306(adreno_gpu))
+ gpu_write(gpu, REG_A3XX_RBBM_CLOCK_CTL, 0x);
+ else if (adreno_is_a320(adreno_gpu))
gpu_write(gpu, REG_A3XX_RBBM_CLOCK_CTL, 0xbfff);
else if (adreno_is_a330v2(adreno_gpu))
gpu_write(gpu, REG_A3XX_RBBM_CLOCK_CTL, 0x);
@@ -271,7 +276,8 @@ static int a3xx_hw_init(struct msm_gpu *gpu)
gpu_write(gpu, REG_A3XX_CP_PFP_UCODE_DATA, ptr[i]);
/* CP ROQ queue sizes (bytes) - RB:16, ST:16, IB1:32, IB2:64 */
- if (adreno_is_a305(adreno_gpu) || adreno_is_a320(adreno_gpu)) {
+ if (adreno_is_a305(adreno_gpu) || adreno_is_a306(adreno_gpu) ||
+ adreno_is_a320(adreno_gpu)) {
gpu_write(gpu, REG_AXXX_CP_QUEUE_THRESHOLDS,
AXXX_CP_QUEUE_THRESHOLDS_CSQ_IB1_START(2) |
AXXX_CP_QUEUE_THRESHOLDS_CSQ_IB2_START(6) |
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index be83dee..8b94c1d 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -42,6 +42,14 @@ static const struct adreno_info gpulist[] = {
.gmem = SZ_256K,
.init = a3xx_gpu_init,
}, {
+ .rev = ADRENO_REV(3, 0, 6, 0),
+ .revn = 307,/* because a305c is revn==306 */
+ .name = "A306",
+ .pm4fw = "a300_pm4.fw",
+ .pfpfw = "a300_pfp.fw",
+ .gmem = SZ_128K,
+ .init = a3xx_gpu_init,
+ }, {
.rev = ADRENO_REV(3, 2, ANY_ID, ANY_ID),
.revn = 320,
.name = "A320",
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index a0cc309..0becca3 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -197,6 +197,12 @@ static inline bool adreno_is_a305(struct adreno_gpu *gpu)
return gpu->revn == 305;
}
+static inline bool adreno_is_a306(struct adreno_gpu *gpu)
+{
+ /* yes, 307, because a305c is 306 */
+ return gpu->revn == 307;
+}
+
static inline bool adreno_is_a320(struct adreno_gpu *gpu)
{
return gpu->revn == 320;
--
2.4.0
[WARNING 4.1-rc2] i915: Unclaimed register detected before writing to register 0xc4040
[ cut here ] WARNING: CPU: 2 PID: 0 at /work/autotest/nobackup/linux-test.git/drivers/gpu/drm/i915/intel_uncore.c:566 hsw_unclaimed_reg_debug.isra.10+0x6c/0x84() Unclaimed register detected before writing to register 0xc4040 Modules linked in: microcode r8169 CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.1.0-rc2-test+ #4 Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823), BIOS V1.6 02/22/2014 0236 880215203c68 81ba8161 880215203cb8 880215203ca8 81080dbb 81626bc6 88020de60068 000c4040 0001 Call Trace: [] dump_stack+0x4c/0x65 [] warn_slowpath_common+0xa1/0xbb [] ? hsw_unclaimed_reg_debug.isra.10+0x6c/0x84 [] warn_slowpath_fmt+0x46/0x48 [] hsw_unclaimed_reg_debug.isra.10+0x6c/0x84 [] hsw_write32+0x86/0xcf [] cpt_irq_handler+0x1e8/0x1f5 [] ivb_display_irq_handler+0xf4/0x11b [] ironlake_irq_handler+0x187/0x24d [] handle_irq_event_percpu+0xf7/0x2a3 [] handle_irq_event+0x41/0x64 [] handle_edge_irq+0xa0/0xb9 [] handle_irq+0x11d/0x128 [] ? atomic_notifier_call_chain+0x14/0x16 [] do_IRQ+0x4e/0xc4 [] common_interrupt+0x70/0x70 [] ? cpuidle_enter_state+0xd8/0x135 [] ? cpuidle_enter_state+0xd4/0x135 [] cpuidle_enter+0x17/0x19 [] cpuidle_idle_call+0xf2/0x180 [] cpu_idle_loop+0x12b/0x164 [] cpu_startup_entry+0x13/0x14 [] start_secondary+0x102/0x106 [] ? set_cpu_sibling_map+0x35e/0x35e ---[ end trace 77c6a96cf41e96d1 ]--- I'm still triggering warnings in the i915 code. :-( config attached. -- Steve -- next part -- A non-text attachment was scrubbed... Name: config Type: application/octet-stream Size: 106140 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150507/a7739a86/attachment-0001.obj>
[Intel-gfx] [RFC PATCH 07/11] drm/i915: Expose PMU for Observation Architecture
On Thu, May 07, 2015 at 03:15:50PM +0100, Robert Bragg wrote:
> +static int init_oa_buffer(struct perf_event *event)
> +{
> + struct drm_i915_private *dev_priv =
> + container_of(event->pmu, typeof(*dev_priv), oa_pmu.pmu);
> + struct drm_i915_gem_object *bo;
> + int ret;
> +
> + BUG_ON(!IS_HASWELL(dev_priv->dev));
> + BUG_ON(!mutex_is_locked(&dev_priv->dev->struct_mutex));
> + BUG_ON(dev_priv->oa_pmu.oa_buffer.obj);
> +
> + spin_lock_init(&dev_priv->oa_pmu.oa_buffer.flush_lock);
> +
> + /* NB: We over allocate the OA buffer due to the way raw sample data
> + * gets copied from the gpu mapped circular buffer into the perf
> + * circular buffer so that only one copy is required.
> + *
> + * For each perf sample (raw->size + 4) needs to be 8 byte aligned,
> + * where the 4 corresponds to the 32bit raw->size member that's
> + * added to the sample header that userspace sees.
> + *
> + * Due to the + 4 for the size member: when we copy a report to the
> + * userspace facing perf buffer we always copy an additional 4 bytes
> + * from the subsequent report to make up for the miss alignment, but
> + * when a report is at the end of the gpu mapped buffer we need to
> + * read 4 bytes past the end of the buffer.
> + */
> + bo = i915_gem_alloc_object(dev_priv->dev, OA_BUFFER_SIZE + PAGE_SIZE);
> + if (bo == NULL) {
> + DRM_ERROR("Failed to allocate OA buffer\n");
> + ret = -ENOMEM;
> + goto err;
> + }
> + dev_priv->oa_pmu.oa_buffer.obj = bo;
> +
> + ret = i915_gem_object_set_cache_level(bo, I915_CACHE_LLC);
> + if (ret)
> + goto err_unref;
> +
> + /* PreHSW required 512K alignment, HSW requires 16M */
> + ret = i915_gem_obj_ggtt_pin(bo, SZ_16M, 0);
> + if (ret)
> + goto err_unref;
> +
> + dev_priv->oa_pmu.oa_buffer.gtt_offset = i915_gem_obj_ggtt_offset(bo);
> + dev_priv->oa_pmu.oa_buffer.addr = vmap_oa_buffer(bo);
You can look forward to both i915_gem_object_create_internal() and
i915_gem_object_pin_vmap()
> +
> + /* Pre-DevBDW: OABUFFER must be set with counters off,
> + * before OASTATUS1, but after OASTATUS2 */
> + I915_WRITE(GEN7_OASTATUS2, dev_priv->oa_pmu.oa_buffer.gtt_offset |
> +GEN7_OASTATUS2_GGTT); /* head */
> + I915_WRITE(GEN7_OABUFFER, dev_priv->oa_pmu.oa_buffer.gtt_offset);
> + I915_WRITE(GEN7_OASTATUS1, dev_priv->oa_pmu.oa_buffer.gtt_offset |
> +GEN7_OASTATUS1_OABUFFER_SIZE_16M); /* tail */
> +
> + DRM_DEBUG_DRIVER("OA Buffer initialized, gtt offset = 0x%x, vaddr = %p",
> + dev_priv->oa_pmu.oa_buffer.gtt_offset,
> + dev_priv->oa_pmu.oa_buffer.addr);
> +
> + return 0;
> +
> +err_unref:
> + drm_gem_object_unreference_unlocked(&bo->base);
But what I really what to say was:
mutex deadlock^^^
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[BUG] i915: suspend by closing Laptop lid broken
Am 2015-05-04 um 13:24 schrieb Jani Nikula: > On Mon, 04 May 2015, Martin Kepplinger wrote: >> So. -rc1 broke suspending by closing my laptop lid and it's not fixed in >> -rc2. It works exactly *one* first time and every subsequent lid-closing >> is ignored. >> >> Biscted and tested first bad commit: >> 14aa02449064541217836b9f3d3295e241d5ae9c >> >> This pulls in i915 changes as well as ACPI changes. I don't know the >> driver but I'm sure you can find the mistake. I'm happy to test changes. >> >> There are no log differences. > > Any chance you could bisect into the merge? It would be helpful. > > BR, > Jani. > > My attempt to go into the merge was too much effort as the checkouts in between break random other stuff. We should be between 09d51602cf84a1264946711dd4ea0dddbac599a1 (good) and c0f404284192f2d4a0159a714372a8c8610c1f6d. Could you have a look and maybe you have guesses for me, what I should test? It's not sooo much anymore, maybe you even have a guess about the bug? thanks martin
linux-next: build warning after merge of the drm-intel tree
Hi all,
After merging the drm-intel tree, today's linux-next build (i386 defconfig)
produced this warning:
drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen8_ppgtt_init':
drivers/gpu/drm/i915/i915_gem_gtt.c:954:22: warning: large integer implicitly
truncated to unsigned type [-Woverflow]
ppgtt->base.total = 1ULL << 32;
^
Introduced by commit 5c5f645773b6 ("drm/i915: Unify aliasing ppgtt
handling"). "total" is a size_t, so unsigned 32 bit on i386.
--
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150507/7465f295/attachment.sig>
[PATCH 2/2] drm/exynos: 'win' is always unsigned
Hi Tobias, 2015-05-06 Tobias Jakobi : > The index for the hardware layer is always >=0. Previous > code that also used -1 as special index is now gone. > > Also apply this to 'ch_enabled' (decon/fimd), since the > variable is on the same line (and is again always unsigned). > > Signed-off-by: Tobias Jakobi > --- > drivers/gpu/drm/exynos/exynos7_drm_decon.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 +++--- > drivers/gpu/drm/exynos/exynos_mixer.c | 6 +++--- > 3 files changed, 7 insertions(+), 7 deletions(-) Reviewed-by: Gustavo Padovan Gustavo
[RFC] How implement Secure Data Path ?
On Wed, May 06, 2015 at 03:15:32PM +0200, Daniel Vetter wrote:
> On Wed, May 06, 2015 at 11:19:21AM +0200, Thierry Reding wrote:
> > On Wed, May 06, 2015 at 10:35:52AM +0200, Daniel Vetter wrote:
> > > On Tue, May 05, 2015 at 05:54:05PM +0100, One Thousand Gnomes wrote:
> > > > > First what is Secure Data Path ? SDP is a set of hardware features to
> > > > > garanty
> > > > > that some memories regions could only be read and/or write by
> > > > > specific hardware
> > > > > IPs. You can imagine it as a kind of memory firewall which
> > > > > grant/revoke
> > > > > accesses to memory per devices. Firewall configuration must be done
> > > > > in a trusted
> > > > > environment: for ARM architecture we plan to use OP-TEE + a trusted
> > > > > application to do that.
> > > >
> > > > It's not just an ARM feature so any basis for this in the core code
> > > > should be generic, whether its being enforced by ARM SDP, various Intel
> > > > feature sets or even via a hypervisor.
> > > >
> > > > > I have try 2 "hacky" approachs with dma_buf:
> > > > > - add a secure field in dma_buf structure and configure firewall in
> > > > > dma_buf_{map/unmap}_attachment() functions.
> > > >
> > > > How is SDP not just another IOMMU. The only oddity here is that it
> > > > happens to configure buffers the CPU can't touch and it has a control
> > > > mechanism that is designed to cover big media corp type uses where the
> > > > threat model is that the system owner is the enemy. Why does anything
> > > > care
> > > > about it being SDP, there are also generic cases this might be a useful
> > > > optimisation (eg knowing the buffer isn't CPU touched so you can
> > > > optimise
> > > > cache flushing).
> > > >
> > > > The control mechanism is a device/platform detail as with any IOMMU. It
> > > > doesn't matter who configures it or how, providing it happens.
> > > >
> > > > We do presumably need some small core DMA changes - anyone trying to map
> > > > such a buffer into CPU space needs to get a warning or error but what
> > > > else ?
> > > >
> > > > > >From buffer allocation point of view I also facing a problem because
> > > > > >when v4l2
> > > > > or drm/kms are exporting buffers by using dma_buf they don't attaching
> > > > > themself on it and never call dma_buf_{map/unmap}_attachment(). This
> > > > > is not
> > > > > an issue in those framework while it is how dma_buf exporters are
> > > > > supposed to work.
> > > >
> > > > Which could be addressed if need be.
> > > >
> > > > So if "SDP" is just another IOMMU feature, just as stuff like IMR is on
> > > > some x86 devices, and hypervisor enforced protection is on assorted
> > > > platforms why do we need a special way to do it ? Is there anything
> > > > actually needed beyond being able to tell the existing DMA code that
> > > > this
> > > > buffer won't be CPU touched and wiring it into the DMA operations for
> > > > the
> > > > platform ?
> > >
> > > Iirc most of the dma api stuff gets unhappy when memory isn't struct page
> > > backed. In i915 we do use sg tables everywhere though (even for memory not
> > > backed by struct page, e.g. the "stolen" range the bios prereserves), but
> > > we fill those out manually.
> > >
> > > A possible generic design I see is to have a secure memory allocator
> > > device which doesn nothing else but hand out dma-bufs.
> >
> > Are you suggesting a device file with a custom set of IOCTLs for this?
> > Or some in-kernel API that would perform the secure allocations? I
> > suspect the former would be better suited, because it gives applications
> > the control over whether they need secure buffers or not. The latter
> > would require custom extensions in every driver to make them allocate
> > from a secure memory pool.
>
> Yes the idea would be a special-purpose allocater thing like ion. Might
> even want that to be a syscall to do it properly.
Would you care to elaborate why a syscall would be more proper? Not that
I'm objecting to it, just for my education.
> > For my understanding, would the secure memory allocator be responsible
> > for setting up the permissions to access the memory at attachment time?
>
> Well not permission checks, but hw capability checks. The allocator should
> have platform knowledge about which devices can access such secure memory
> (since some will definitely not be able to do that for fear of just plain
> sending it out to the world).
At least on Tegra there are controls to grant access to the VPR to a
given device, so I'd expect some driver needing to frob some registers
before the device can access a secure buffer.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150507/ec56c122/attachment.sig>
[Intel-gfx] [RFC PATCH 03/11] perf: Add PERF_EVENT_IOC_FLUSH ioctl
On Thu, May 07, 2015 at 03:15:46PM +0100, Robert Bragg wrote:
> To allow for pmus that may have internal buffering (e.g. the hardware
> itself writes out data to its own circular buffer which is only
> periodically forwarded to userspace via perf) this ioctl enables
> userspace to explicitly ensure it has received all samples before a
> point in time.
>
> Signed-off-by: Robert Bragg
> ---
> include/linux/perf_event.h | 7 +++
> include/uapi/linux/perf_event.h | 1 +
> kernel/events/core.c| 5 +
> 3 files changed, 13 insertions(+)
>
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index 1af35b4..69a0cb9 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -266,6 +266,13 @@ struct pmu {
>* flush branch stack on context-switches (needed in cpu-wide mode)
>*/
> void (*flush_branch_stack) (void);
> +
> + /*
> + * Flush buffered samples (E.g. for pmu hardware that writes samples to
> + * some intermediate buffer) userspace may need to explicitly ensure
> + * such samples have been forwarded to perf.
> + */
> + void (*flush) (struct perf_event *event); /*optional
> */
void return?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[PATCH 4/4] drm/radeon: stop trying to suspend UVD sessions
From: Christian König
Saving the current UVD state on suspend and restoring it on resume
just doesn't work reliable. Just close cleanup all sessions on suspend.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h | 1 -
drivers/gpu/drm/radeon/radeon_uvd.c | 39 ++---
2 files changed, 19 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index d2abe48..46eb0fa 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1673,7 +1673,6 @@ struct radeon_uvd {
struct radeon_bo*vcpu_bo;
void*cpu_addr;
uint64_tgpu_addr;
- void*saved_bo;
atomic_thandles[RADEON_MAX_UVD_HANDLES];
struct drm_file *filp[RADEON_MAX_UVD_HANDLES];
unsignedimg_size[RADEON_MAX_UVD_HANDLES];
diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
b/drivers/gpu/drm/radeon/radeon_uvd.c
index cd63028..6edcb54 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -204,28 +204,32 @@ void radeon_uvd_fini(struct radeon_device *rdev)
int radeon_uvd_suspend(struct radeon_device *rdev)
{
- unsigned size;
- void *ptr;
- int i;
+ int i, r;
if (rdev->uvd.vcpu_bo == NULL)
return 0;
- for (i = 0; i < RADEON_MAX_UVD_HANDLES; ++i)
- if (atomic_read(&rdev->uvd.handles[i]))
- break;
+ for (i = 0; i < RADEON_MAX_UVD_HANDLES; ++i) {
+ uint32_t handle = atomic_read(&rdev->uvd.handles[i]);
+ if (handle != 0) {
+ struct radeon_fence *fence;
- if (i == RADEON_MAX_UVD_HANDLES)
- return 0;
+ radeon_uvd_note_usage(rdev);
- size = radeon_bo_size(rdev->uvd.vcpu_bo);
- size -= rdev->uvd_fw->size;
+ r = radeon_uvd_get_destroy_msg(rdev,
+ R600_RING_TYPE_UVD_INDEX, handle, &fence);
+ if (r) {
+ DRM_ERROR("Error destroying UVD (%d)!\n", r);
+ continue;
+ }
- ptr = rdev->uvd.cpu_addr;
- ptr += rdev->uvd_fw->size;
+ radeon_fence_wait(fence, false);
+ radeon_fence_unref(&fence);
- rdev->uvd.saved_bo = kmalloc(size, GFP_KERNEL);
- memcpy(rdev->uvd.saved_bo, ptr, size);
+ rdev->uvd.filp[i] = NULL;
+ atomic_set(&rdev->uvd.handles[i], 0);
+ }
+ }
return 0;
}
@@ -246,12 +250,7 @@ int radeon_uvd_resume(struct radeon_device *rdev)
ptr = rdev->uvd.cpu_addr;
ptr += rdev->uvd_fw->size;
- if (rdev->uvd.saved_bo != NULL) {
- memcpy(ptr, rdev->uvd.saved_bo, size);
- kfree(rdev->uvd.saved_bo);
- rdev->uvd.saved_bo = NULL;
- } else
- memset(ptr, 0, size);
+ memset(ptr, 0, size);
return 0;
}
--
1.9.1
[PATCH 3/4] drm/radeon: more strictly validate the UVD codec
From: Christian König
MPEG 2/4 are only supported since UVD3.
Signed-off-by: Christian König
CC: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_uvd.c | 33 +++--
1 file changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
b/drivers/gpu/drm/radeon/radeon_uvd.c
index f67a6aa..cd63028 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -396,6 +396,29 @@ static int radeon_uvd_cs_msg_decode(uint32_t *msg,
unsigned buf_sizes[])
return 0;
}
+static int radeon_uvd_validate_codec(struct radeon_cs_parser *p,
+unsigned stream_type)
+{
+ switch (stream_type) {
+ case 0: /* H264 */
+ case 1: /* VC1 */
+ /* always supported */
+ return 0;
+
+ case 3: /* MPEG2 */
+ case 4: /* MPEG4 */
+ /* only since UVD 3 */
+ if (p->rdev->family >= CHIP_PALM)
+ return 0;
+
+ /* fall through */
+ default:
+ DRM_ERROR("UVD codec not supported by hardware %d!\n",
+ stream_type);
+ return -EINVAL;
+ }
+}
+
static int radeon_uvd_cs_msg(struct radeon_cs_parser *p, struct radeon_bo *bo,
unsigned offset, unsigned buf_sizes[])
{
@@ -440,7 +463,11 @@ static int radeon_uvd_cs_msg(struct radeon_cs_parser *p,
struct radeon_bo *bo,
case 0:
/* it's a create msg, calc image size (width * height) */
img_size = msg[7] * msg[8];
+
+ r = radeon_uvd_validate_codec(p, msg[4]);
radeon_bo_kunmap(bo);
+ if (r)
+ return r;
/* try to alloc a new handle */
for (i = 0; i < RADEON_MAX_UVD_HANDLES; ++i) {
@@ -460,8 +487,10 @@ static int radeon_uvd_cs_msg(struct radeon_cs_parser *p,
struct radeon_bo *bo,
return -EINVAL;
case 1:
- /* it's a decode msg, calc buffer sizes */
- r = radeon_uvd_cs_msg_decode(msg, buf_sizes);
+ /* it's a decode msg, validate codec and calc buffer sizes */
+ r = radeon_uvd_validate_codec(p, msg[4]);
+ if (!r)
+ r = radeon_uvd_cs_msg_decode(msg, buf_sizes);
radeon_bo_kunmap(bo);
if (r)
return r;
--
1.9.1
[PATCH 2/4] drm/radeon: make UVD handle checking more strict
From: Christian König
Invalid messages can crash the hw otherwise.
Signed-off-by: Christian König
CC: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_uvd.c | 72 ++---
1 file changed, 43 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c
b/drivers/gpu/drm/radeon/radeon_uvd.c
index c10b2ae..f67a6aa 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -436,50 +436,64 @@ static int radeon_uvd_cs_msg(struct radeon_cs_parser *p,
struct radeon_bo *bo,
return -EINVAL;
}
- if (msg_type == 1) {
+ switch (msg_type) {
+ case 0:
+ /* it's a create msg, calc image size (width * height) */
+ img_size = msg[7] * msg[8];
+ radeon_bo_kunmap(bo);
+
+ /* try to alloc a new handle */
+ for (i = 0; i < RADEON_MAX_UVD_HANDLES; ++i) {
+ if (atomic_read(&p->rdev->uvd.handles[i]) == handle) {
+ DRM_ERROR("Handle 0x%x already in use!\n",
handle);
+ return -EINVAL;
+ }
+
+ if (!atomic_cmpxchg(&p->rdev->uvd.handles[i], 0,
handle)) {
+ p->rdev->uvd.filp[i] = p->filp;
+ p->rdev->uvd.img_size[i] = img_size;
+ return 0;
+ }
+ }
+
+ DRM_ERROR("No more free UVD handles!\n");
+ return -EINVAL;
+
+ case 1:
/* it's a decode msg, calc buffer sizes */
r = radeon_uvd_cs_msg_decode(msg, buf_sizes);
- /* calc image size (width * height) */
- img_size = msg[6] * msg[7];
radeon_bo_kunmap(bo);
if (r)
return r;
- } else if (msg_type == 2) {
+ /* validate the handle */
+ for (i = 0; i < RADEON_MAX_UVD_HANDLES; ++i) {
+ if (atomic_read(&p->rdev->uvd.handles[i]) == handle) {
+ if (p->rdev->uvd.filp[i] != p->filp) {
+ DRM_ERROR("UVD handle collision
detected!\n");
+ return -EINVAL;
+ }
+ return 0;
+ }
+ }
+
+ DRM_ERROR("Invalid UVD handle 0x%x!\n", handle);
+ return -ENOENT;
+
+ case 2:
/* it's a destroy msg, free the handle */
for (i = 0; i < RADEON_MAX_UVD_HANDLES; ++i)
atomic_cmpxchg(&p->rdev->uvd.handles[i], handle, 0);
radeon_bo_kunmap(bo);
return 0;
- } else {
- /* it's a create msg, calc image size (width * height) */
- img_size = msg[7] * msg[8];
- radeon_bo_kunmap(bo);
- if (msg_type != 0) {
- DRM_ERROR("Illegal UVD message type (%d)!\n", msg_type);
- return -EINVAL;
- }
-
- /* it's a create msg, no special handling needed */
- }
-
- /* create or decode, validate the handle */
- for (i = 0; i < RADEON_MAX_UVD_HANDLES; ++i) {
- if (atomic_read(&p->rdev->uvd.handles[i]) == handle)
- return 0;
- }
+ default:
- /* handle not found try to alloc a new one */
- for (i = 0; i < RADEON_MAX_UVD_HANDLES; ++i) {
- if (!atomic_cmpxchg(&p->rdev->uvd.handles[i], 0, handle)) {
- p->rdev->uvd.filp[i] = p->filp;
- p->rdev->uvd.img_size[i] = img_size;
- return 0;
- }
+ DRM_ERROR("Illegal UVD message type (%d)!\n", msg_type);
+ return -EINVAL;
}
- DRM_ERROR("No more free UVD handles!\n");
+ BUG();
return -EINVAL;
}
--
1.9.1
[PATCH 1/4] drm/radeon: make VCE handle check more strict
From: Christian König
Invalid handles can crash the hw.
Signed-off-by: Christian König
CC: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_vce.c | 65 +++--
1 file changed, 48 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_vce.c
b/drivers/gpu/drm/radeon/radeon_vce.c
index 24f849f..0de5711 100644
--- a/drivers/gpu/drm/radeon/radeon_vce.c
+++ b/drivers/gpu/drm/radeon/radeon_vce.c
@@ -493,18 +493,27 @@ int radeon_vce_cs_reloc(struct radeon_cs_parser *p, int
lo, int hi,
*
* @p: parser context
* @handle: handle to validate
+ * @allocated: allocated a new handle?
*
* Validates the handle and return the found session index or -EINVAL
* we we don't have another free session index.
*/
-int radeon_vce_validate_handle(struct radeon_cs_parser *p, uint32_t handle)
+static int radeon_vce_validate_handle(struct radeon_cs_parser *p,
+ uint32_t handle, bool *allocated)
{
unsigned i;
+ *allocated = false;
+
/* validate the handle */
for (i = 0; i < RADEON_MAX_VCE_HANDLES; ++i) {
- if (atomic_read(&p->rdev->vce.handles[i]) == handle)
+ if (atomic_read(&p->rdev->vce.handles[i]) == handle) {
+ if (p->rdev->vce.filp[i] != p->filp) {
+ DRM_ERROR("VCE handle collision detected!\n");
+ return -EINVAL;
+ }
return i;
+ }
}
/* handle not found try to alloc a new one */
@@ -512,6 +521,7 @@ int radeon_vce_validate_handle(struct radeon_cs_parser *p,
uint32_t handle)
if (!atomic_cmpxchg(&p->rdev->vce.handles[i], 0, handle)) {
p->rdev->vce.filp[i] = p->filp;
p->rdev->vce.img_size[i] = 0;
+ *allocated = true;
return i;
}
}
@@ -529,10 +539,10 @@ int radeon_vce_validate_handle(struct radeon_cs_parser
*p, uint32_t handle)
int radeon_vce_cs_parse(struct radeon_cs_parser *p)
{
int session_idx = -1;
- bool destroyed = false;
+ bool destroyed = false, created = false, allocated = false;
uint32_t tmp, handle = 0;
uint32_t *size = &tmp;
- int i, r;
+ int i, r = 0;
while (p->idx < p->chunk_ib->length_dw) {
uint32_t len = radeon_get_ib_value(p, p->idx);
@@ -540,18 +550,21 @@ int radeon_vce_cs_parse(struct radeon_cs_parser *p)
if ((len < 8) || (len & 3)) {
DRM_ERROR("invalid VCE command length (%d)!\n", len);
- return -EINVAL;
+ r = -EINVAL;
+ goto out;
}
if (destroyed) {
DRM_ERROR("No other command allowed after destroy!\n");
- return -EINVAL;
+ r = -EINVAL;
+ goto out;
}
switch (cmd) {
case 0x0001: // session
handle = radeon_get_ib_value(p, p->idx + 2);
- session_idx = radeon_vce_validate_handle(p, handle);
+ session_idx = radeon_vce_validate_handle(p, handle,
+&allocated);
if (session_idx < 0)
return session_idx;
size = &p->rdev->vce.img_size[session_idx];
@@ -561,6 +574,13 @@ int radeon_vce_cs_parse(struct radeon_cs_parser *p)
break;
case 0x0101: // create
+ created = true;
+ if (!allocated) {
+ DRM_ERROR("Handle already in use!\n");
+ r = -EINVAL;
+ goto out;
+ }
+
*size = radeon_get_ib_value(p, p->idx + 8) *
radeon_get_ib_value(p, p->idx + 10) *
8 * 3 / 2;
@@ -578,12 +598,12 @@ int radeon_vce_cs_parse(struct radeon_cs_parser *p)
r = radeon_vce_cs_reloc(p, p->idx + 10, p->idx + 9,
*size);
if (r)
- return r;
+ goto out;
r = radeon_vce_cs_reloc(p, p->idx + 12, p->idx + 11,
*size / 3);
if (r)
- return r;
+ goto out;
break;
case 0x0201: // destroy
@@ -594,7 +614,7 @@ int radeon_vce_cs_parse(struct radeon_cs_parser *p)
r = radeon_vce_cs_reloc(p, p->idx + 3,
[PATCH 1/2] drm/exynos: mixer: don't dump registers under spinlock
Hi Tobias, 2015-05-06 Tobias Jakobi : > mixer_regs_dump() was called in mixer_run(), which was called > under the register spinlock in mixer_graph_buffer() and > vp_video_buffer(). > > This would trigger a sysmmu pagefault with drm.debug=0xff because > of the large delay caused by the register dumping. > > To keep consistency also move register dumping out of mixer_stop(), > which is the counterpart to mixer_run(). > > Kernel dump: > [ 131.296529] [drm:mixer_win_commit] win: 2 > [ 131.300693] [drm:mixer_regs_dump] MXR_STATUS = 0081 > [ 131.305888] [drm:mixer_regs_dump] MXR_CFG = 07d5 > [ 131.310835] [drm:mixer_regs_dump] MXR_INT_EN = > [ 131.316043] [drm:mixer_regs_dump] MXR_INT_STATUS = 0900 > [ 131.321598] [drm:mixer_regs_dump] MXR_LAYER_CFG = 0321 > [ 131.327066] [drm:mixer_regs_dump] MXR_VIDEO_CFG = > [ 131.332535] [drm:mixer_regs_dump] MXR_GRAPHIC0_CFG = 00310700 > [ 131.338263] [drm:mixer_regs_dump] MXR_GRAPHIC0_BASE = 20c0 > [ 131.344079] [drm:mixer_regs_dump] MXR_GRAPHIC0_SPAN = 0780 > [ 131.349895] [drm:mixer_regs_dump] MXR_GRAPHIC0_WH = 07800438 > [ 131.355537] [drm:mixer_regs_dump] MXR_GRAPHIC0_SXY = > [ 131.361265] [drm:mixer_regs_dump] MXR_GRAPHIC0_DXY = > [ 131.366994] [drm:mixer_regs_dump] MXR_GRAPHIC1_CFG = > [ 131.372723] [drm:mixer_regs_dump] MXR_GRAPHIC1_BASE = > [ 131.378539] [drm:mixer_regs_dump] MXR_GRAPHIC1_SPAN = > [ 131.384354] [drm:mixer_regs_dump] MXR_GRAPHIC1_WH = > [ 131.389996] [drm:mixer_regs_dump] MXR_GRAPHIC1_SXY = > [ 131.395725] [drm:mixer_regs_dump] MXR_GRAPHIC1_DXY = > [ 131.401486] PAGE FAULT occurred at 0x0 by 12e2.sysmmu(Page table base: > 0x6d99) > [ 131.409353] Lv1 entry: 0x6e0f2401 > [ 131.412753] [ cut here ] > [ 131.417339] kernel BUG at drivers/iommu/exynos-iommu.c:358! > [ 131.422894] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM > [ 131.428709] Modules linked in: ecb bridge stp llc bnep btrfs xor xor_neon > zlib_inflate zlib_deflate raid6_pq btusb bluetooth usb_storage s5p_jpeg > videobuf2_dma_contig videobuf2_memops v4l2_mem2mem videobuf2_core > [ 131.447461] CPU: 0 PID: 2418 Comm: lt-modetest Tainted: GW > 4.0.1-debug+ #3 > [ 131.455530] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > [ 131.461607] task: ee194100 ti: ec4fe000 task.ti: ec4fe000 > [ 131.466995] PC is at exynos_sysmmu_irq+0x2a0/0x2a8 > [ 131.471766] LR is at vprintk_emit+0x268/0x594 > [ 131.476103] pc : []lr : []psr: a1d3 > [ 131.476103] sp : ec4ff9d8 ip : fp : ec4ffa14 > [ 131.487559] r10: ffda r9 : ee206e28 r8 : ee2d1a10 > [ 131.492767] r7 : r6 : r5 : r4 : ee206e10 > [ 131.499277] r3 : c06fca20 r2 : r1 : r0 : ee28be00 > [ 131.505788] Flags: NzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment > user > [ 131.513079] Control: 10c5387d Table: 6c72404a DAC: 0015 > [ 131.518808] Process lt-modetest (pid: 2418, stack limit = 0xec4fe218) > [ 131.525231] Stack: (0xec4ff9d8 to 0xec50) > [ 131.529571] f9c0: > ec4ff9e4 c03a0c40 > [ 131.537732] f9e0: bbfa6e35 6d99 6d161c3d ee20a900 ee04a7e0 0028 > ee007000 > [ 131.545891] fa00: c06fb1fc ec4ffa5c ec4ffa18 c0066a34 c0277f10 > ee257664 000b > [ 131.554050] fa20: ec4ffa5c c06fafbb ee04a780 c06fb1e8 ee04a780 > ee04a7e0 ee20a900 > [ 131.562209] fa40: ee007000 0015 ec4ffb48 ee008000 ec4ffa7c ec4ffa60 > c0066c90 c00669e0 > [ 131.570369] fa60: 0002 ee04a780 ee04a7e0 1000 ec4ffa94 ec4ffa80 > c0069c6c c0066c58 > [ 131.578528] fa80: 0028 ee004450 ec4ffaac ec4ffa98 c0066028 c0069bac > 00a0 c06e19b4 > [ 131.586687] faa0: ec4ffad4 ec4ffab0 c0223678 c0066000 c02235dc 0015 > 0015 > [ 131.594846] fac0: ec4ffc80 0001 ec4ffaec ec4ffad8 c0066028 c02235e8 > 0089 c06bfc54 > [ 131.603005] fae0: ec4ffb1c ec4ffaf0 c006633c c0066000 ec4ffb48 f002000c > 0025 0015 > [ 131.611165] fb00: c06c680c ec4ffb48 f002 ee008000 ec4ffb44 ec4ffb20 > c000867c c00662c4 > [ 131.619324] fb20: c02046ac 6153 ec4ffb7c 0101 > ec4ffbb4 ec4ffb48 > [ 131.627483] fb40: c0013240 c0008650 0001 ee257508 0002 0001 > ee257504 ee257508 > [ 131.635642] fb60: c06bf27c 0101 ee008000 ec4ffbb4 > ec4ffb90 > [ 131.643802] fb80: c002e124 c02046ac 6153 c002e09c > c06c6080 0283 > [ 131.651960] fba0: 0001 c06fb1ac ec4ffc0c ec4ffbb8 c002d690 c002e0a8 > ee78d080 ee008000 > [ 131.660120] fbc0: 0040 c04eb3b0 7c44 c06c6100 c06fdac0 000a > c06bf2f0 c06c6080 > [ 131.668279] fbe0: c06bfc54 c06bfc54 0025 0001 > ec4ffc80 ee008000 > [ 131.676438] fc00: ec4ffc24 ec4ffc10 c002dbb8 c002d564 0089 c06bfc54
[RFC PATCH 11/11] WIP: drm/i915: constrain unit gating while using OA
We are still investigating the detailed requirements here, but there are
some constraints we need to apply on unit level clock gating for
reliable metrics (in particular for a reliable sampling period).
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_oa_perf.c | 70 +++--
drivers/gpu/drm/i915/i915_reg.h | 3 ++
2 files changed, 63 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_oa_perf.c
b/drivers/gpu/drm/i915/i915_oa_perf.c
index d0dad5d..2a4121b 100644
--- a/drivers/gpu/drm/i915/i915_oa_perf.c
+++ b/drivers/gpu/drm/i915/i915_oa_perf.c
@@ -257,20 +257,46 @@ oa_buffer_destroy(struct drm_i915_private *i915)
static void i915_oa_event_destroy(struct perf_event *event)
{
- struct drm_i915_private *i915 =
- container_of(event->pmu, typeof(*i915), oa_pmu.pmu);
+ struct drm_i915_private *dev_priv =
+ container_of(event->pmu, typeof(*dev_priv), oa_pmu.pmu);
WARN_ON(event->parent);
- oa_buffer_destroy(i915);
+ I915_WRITE(GEN6_UCGCTL1, (I915_READ(GEN6_UCGCTL1) &
+ ~GEN6_RCZUNIT_CLOCK_GATE_DISABLE));
+ //I915_WRITE(GEN6_UCGCTL3, (I915_READ(GEN6_UCGCTL3) &
+ //~GEN6_OACSUNIT_CLOCK_GATE_DISABLE));
+ I915_WRITE(GEN7_MISCCPCTL, (I915_READ(GEN7_MISCCPCTL) |
+ GEN7_DOP_CLOCK_GATE_ENABLE));
+
+ I915_WRITE(GEN7_ROW_CHICKEN2,
+ _MASKED_BIT_DISABLE(DOP_CLOCK_GATING_DISABLE));
+
+ //if (IS_HSW_GT2(dev_priv->dev)) {
+ if (1) {
+ I915_WRITE(HSW_ROW_CHICKEN2_GT2,
+ _MASKED_BIT_DISABLE(DOP_CLOCK_GATING_DISABLE));
+ }
+
+ if (IS_HSW_GT3(dev_priv->dev)) {
+ I915_WRITE(HSW_ROW_CHICKEN2_GT3_0,
+ _MASKED_BIT_DISABLE(DOP_CLOCK_GATING_DISABLE));
+ I915_WRITE(HSW_ROW_CHICKEN2_GT3_1,
+ _MASKED_BIT_DISABLE(DOP_CLOCK_GATING_DISABLE));
+ }
- i915->oa_pmu.specific_ctx = NULL;
+ I915_WRITE(GDT_CHICKEN_BITS, (I915_READ(GDT_CHICKEN_BITS) &
+ ~GT_NOA_ENABLE));
+
+ oa_buffer_destroy(dev_priv);
+
+ dev_priv->oa_pmu.specific_ctx = NULL;
- BUG_ON(i915->oa_pmu.exclusive_event != event);
- i915->oa_pmu.exclusive_event = NULL;
+ BUG_ON(dev_priv->oa_pmu.exclusive_event != event);
+ dev_priv->oa_pmu.exclusive_event = NULL;
- intel_uncore_forcewake_put(i915, FORCEWAKE_ALL);
- intel_runtime_pm_put(i915);
+ intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+ intel_runtime_pm_put(dev_priv);
}
static void *vmap_oa_buffer(struct drm_i915_gem_object *obj)
@@ -581,6 +607,32 @@ static int i915_oa_event_init(struct perf_event *event)
BUG_ON(dev_priv->oa_pmu.exclusive_event);
dev_priv->oa_pmu.exclusive_event = event;
+
+ I915_WRITE(GDT_CHICKEN_BITS, GT_NOA_ENABLE);
+
+ I915_WRITE(GEN6_UCGCTL1, (I915_READ(GEN6_UCGCTL1) |
+ GEN6_RCZUNIT_CLOCK_GATE_DISABLE));
+ //I915_WRITE(GEN6_UCGCTL3, (I915_READ(GEN6_UCGCTL3) |
+ //GEN6_OACSUNIT_CLOCK_GATE_DISABLE));
+ I915_WRITE(GEN7_MISCCPCTL, (I915_READ(GEN7_MISCCPCTL) &
+ ~GEN7_DOP_CLOCK_GATE_ENABLE));
+
+ I915_WRITE(GEN7_ROW_CHICKEN2,
+ _MASKED_BIT_ENABLE(DOP_CLOCK_GATING_DISABLE));
+
+ //if (IS_HSW_GT2(dev_priv->dev)) {
+ if (1) {
+ I915_WRITE(HSW_ROW_CHICKEN2_GT2,
+ _MASKED_BIT_ENABLE(DOP_CLOCK_GATING_DISABLE));
+ }
+
+ if (IS_HSW_GT3(dev_priv->dev)) {
+ I915_WRITE(HSW_ROW_CHICKEN2_GT3_0,
+ _MASKED_BIT_ENABLE(DOP_CLOCK_GATING_DISABLE));
+ I915_WRITE(HSW_ROW_CHICKEN2_GT3_1,
+ _MASKED_BIT_ENABLE(DOP_CLOCK_GATING_DISABLE));
+ }
+
event->destroy = i915_oa_event_destroy;
/* PRM - observability performance counters:
@@ -678,8 +730,6 @@ static void i915_oa_event_start(struct perf_event *event,
int flags)
WARN_ONCE(I915_READ(GEN6_UCGCTL3) & GEN6_OACSUNIT_CLOCK_GATE_DISABLE,
"disabled OA unit level clock gating will result in incorrect
per-context OA counters");
- I915_WRITE(GDT_CHICKEN_BITS, GT_NOA_ENABLE);
-
if (dev_priv->oa_pmu.metrics_set == I915_OA_METRICS_SET_3D) {
config_oa_regs(dev_priv, hsw_profile_3d_mux_config,
ARRAY_SIZE(hsw_profile_3d_mux_config));
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d94932a..518b34c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7036,6 +7036,9 @@ enum skl_disp_power_wells {
#define GEN7_ROW_CHICKEN2 0xe4f4
#define GEN7_ROW_CHICKEN2_GT2 0xf4f4
+#define HSW_ROW_CHICK
[RFC PATCH 10/11] drm/i915: report OA buf overrun + report lost status
This adds two driver specific PERF_RECORD_DEVICE event types for
reporting OA buffer overrun and report lost status bits to userspace.
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_oa_perf.c | 53 -
include/uapi/drm/i915_drm.h | 27 +++
2 files changed, 62 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_oa_perf.c
b/drivers/gpu/drm/i915/i915_oa_perf.c
index c3e5059..d0dad5d 100644
--- a/drivers/gpu/drm/i915/i915_oa_perf.c
+++ b/drivers/gpu/drm/i915/i915_oa_perf.c
@@ -159,6 +159,34 @@ static u32 forward_oa_snapshots(struct drm_i915_private
*dev_priv,
return dev_priv->oa_pmu.oa_buffer.gtt_offset + head;
}
+static void log_oa_status(struct drm_i915_private *dev_priv,
+ enum drm_i915_oa_event_type status)
+{
+ struct {
+ struct perf_event_header header;
+ drm_i915_oa_event_header_t i915_oa_header;
+ } oa_event;
+ struct perf_output_handle handle;
+ struct perf_sample_data sample_data;
+ struct perf_event *event = dev_priv->oa_pmu.exclusive_event;
+ int ret;
+
+ oa_event.header.size = sizeof(oa_event);
+ oa_event.header.type = PERF_RECORD_DEVICE;
+ oa_event.i915_oa_header.type = status;
+ oa_event.i915_oa_header.__reserved_1 = 0;
+
+ perf_event_header__init_id(&oa_event.header, &sample_data, event);
+
+ ret = perf_output_begin(&handle, event, oa_event.header.size);
+ if (ret)
+ return;
+
+ perf_output_put(&handle, oa_event);
+ perf_event__output_id_sample(event, &handle, &sample_data);
+ perf_output_end(&handle);
+}
+
static void flush_oa_snapshots(struct drm_i915_private *dev_priv,
bool skip_if_flushing)
{
@@ -189,25 +217,14 @@ static void flush_oa_snapshots(struct drm_i915_private
*dev_priv,
head = oastatus2 & GEN7_OASTATUS2_HEAD_MASK;
tail = oastatus1 & GEN7_OASTATUS1_TAIL_MASK;
- if (oastatus1 & (GEN7_OASTATUS1_OABUFFER_OVERFLOW |
-GEN7_OASTATUS1_REPORT_LOST)) {
+ if (unlikely(oastatus1 & (GEN7_OASTATUS1_OABUFFER_OVERFLOW |
+ GEN7_OASTATUS1_REPORT_LOST))) {
- /* XXX: How can we convey report-lost errors to userspace? It
-* doesn't look like perf's _REPORT_LOST mechanism is
-* appropriate in this case; that's just for cases where we
-* run out of space for samples in the perf circular buffer.
-*
-* Maybe we can claim a special report-id and use that to
-* forward status flags?
-*/
- pr_debug("OA buffer read error: addr = %p, head = %u, offset =
%u, tail = %u cnt o'flow = %d, buf o'flow = %d, rpt lost = %d\n",
-dev_priv->oa_pmu.oa_buffer.addr,
-head,
-head - dev_priv->oa_pmu.oa_buffer.gtt_offset,
-tail,
-oastatus1 & GEN7_OASTATUS1_COUNTER_OVERFLOW ? 1 : 0,
-oastatus1 & GEN7_OASTATUS1_OABUFFER_OVERFLOW ? 1 : 0,
-oastatus1 & GEN7_OASTATUS1_REPORT_LOST ? 1 : 0);
+ if (oastatus1 & GEN7_OASTATUS1_OABUFFER_OVERFLOW)
+ log_oa_status(dev_priv, I915_OA_RECORD_BUFFER_OVERFLOW);
+
+ if (oastatus1 & GEN7_OASTATUS1_REPORT_LOST)
+ log_oa_status(dev_priv, I915_OA_RECORD_REPORT_LOST);
I915_WRITE(GEN7_OASTATUS1, oastatus1 &
~(GEN7_OASTATUS1_OABUFFER_OVERFLOW |
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 7aa1d33..2871922 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -89,6 +89,33 @@ typedef struct _drm_i915_oa_attr {
__reserved_1 : 63;
} drm_i915_oa_attr_t;
+/* Header for PERF_RECORD_DEVICE type events */
+typedef struct _drm_i915_oa_event_header {
+ __u32 type;
+ __u32 __reserved_1;
+} drm_i915_oa_event_header_t;
+
+enum drm_i915_oa_event_type {
+
+ /*
+* struct {
+* struct perf_event_headerheader;
+* drm_i915_oa_event_header_t i915_oa_header;
+* };
+*/
+ I915_OA_RECORD_BUFFER_OVERFLOW = 1,
+
+ /*
+* struct {
+* struct perf_event_headerheader;
+* drm_i915_oa_event_header_t i915_oa_header;
+* };
+*/
+ I915_OA_RECORD_REPORT_LOST = 2,
+
+ I915_OA_RECORD_MAX, /* non-ABI */
+};
+
/* Each region is a minimum of 16k, and there are at most 255 of them.
*/
#define I915_NR_TEX_REGIONS 255/* table size 2k - maximum due to use
--
2.3.2
[RFC PATCH 09/11] drm/i915: Add dev.i915.oa_event_paranoid sysctl option
Consistent with the kernel.perf_event_paranoid sysctl option that can
allow non-root users to access system wide cpu metrics, this can
optionally allow non-root users to access system wide OA counter metrics
from Gen graphics hardware.
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_oa_perf.c | 40 -
2 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1e65dc2..7bc7243 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1831,6 +1831,8 @@ struct drm_i915_private {
struct hrtimer timer;
struct pt_regs dummy_regs;
+ struct ctl_table_header *sysctl_header;
+
struct perf_event *exclusive_event;
struct intel_context *specific_ctx;
bool event_active;
diff --git a/drivers/gpu/drm/i915/i915_oa_perf.c
b/drivers/gpu/drm/i915/i915_oa_perf.c
index d0e144c..c3e5059 100644
--- a/drivers/gpu/drm/i915/i915_oa_perf.c
+++ b/drivers/gpu/drm/i915/i915_oa_perf.c
@@ -11,6 +11,8 @@
#define FREQUENCY 200
#define PERIOD max_t(u64, 1, NSEC_PER_SEC / FREQUENCY)
+static u32 i915_oa_event_paranoid = true;
+
static int hsw_perf_format_sizes[] = {
64, /* A13_HSW */
128, /* A29_HSW */
@@ -548,7 +550,8 @@ static int i915_oa_event_init(struct perf_event *event)
}
}
- if (!dev_priv->oa_pmu.specific_ctx && !capable(CAP_SYS_ADMIN))
+ if (!dev_priv->oa_pmu.specific_ctx &&
+ i915_oa_event_paranoid && !capable(CAP_SYS_ADMIN))
return -EACCES;
mutex_lock(&dev_priv->dev->struct_mutex);
@@ -795,6 +798,37 @@ void i915_oa_context_unpin_notify(struct drm_i915_private
*dev_priv,
spin_unlock_irqrestore(&dev_priv->oa_pmu.lock, flags);
}
+static struct ctl_table oa_table[] = {
+ {
+.procname = "oa_event_paranoid",
+.data = &i915_oa_event_paranoid,
+.maxlen = sizeof(i915_oa_event_paranoid),
+.mode = 0644,
+.proc_handler = proc_dointvec,
+},
+ {}
+};
+
+static struct ctl_table i915_root[] = {
+ {
+.procname = "i915",
+.maxlen = 0,
+.mode = 0555,
+.child = oa_table,
+},
+ {}
+};
+
+static struct ctl_table dev_root[] = {
+ {
+.procname = "dev",
+.maxlen = 0,
+.mode = 0555,
+.child = i915_root,
+},
+ {}
+};
+
void i915_oa_pmu_register(struct drm_device *dev)
{
struct drm_i915_private *i915 = to_i915(dev);
@@ -802,6 +836,8 @@ void i915_oa_pmu_register(struct drm_device *dev)
if (!IS_HASWELL(dev))
return;
+ i915->oa_pmu.sysctl_header = register_sysctl_table(dev_root);
+
/* We need to be careful about forwarding cpu metrics to
* userspace considering that PERF_PMU_CAP_IS_DEVICE bypasses
* the events/core security check that stops an unprivileged
@@ -841,6 +877,8 @@ void i915_oa_pmu_unregister(struct drm_device *dev)
if (i915->oa_pmu.pmu.event_init == NULL)
return;
+ unregister_sysctl_table(i915->oa_pmu.sysctl_header);
+
perf_pmu_unregister(&i915->oa_pmu.pmu);
i915->oa_pmu.pmu.event_init = NULL;
}
--
2.3.2
[RFC PATCH 08/11] drm/i915: add OA config for 3D render counters
This enables access to some additional counters beyond the aggregating A
counters, adding a '3D' metric set configuration useful while profiling
3D rendering workloads.
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_drv.h | 7 +
drivers/gpu/drm/i915/i915_oa_perf.c | 124 +--
drivers/gpu/drm/i915/i915_reg.h | 294
include/uapi/drm/i915_drm.h | 2 +
4 files changed, 385 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3d8e4ed..1e65dc2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1564,6 +1564,13 @@ struct i915_virtual_gpu {
bool active;
};
+#ifdef CONFIG_PERF_EVENTS
+struct i915_oa_reg {
+ u32 addr;
+ u32 value;
+};
+#endif
+
struct drm_i915_private {
struct drm_device *dev;
struct kmem_cache *objects;
diff --git a/drivers/gpu/drm/i915/i915_oa_perf.c
b/drivers/gpu/drm/i915/i915_oa_perf.c
index a1cf55f..d0e144c 100644
--- a/drivers/gpu/drm/i915/i915_oa_perf.c
+++ b/drivers/gpu/drm/i915/i915_oa_perf.c
@@ -23,6 +23,80 @@ static int hsw_perf_format_sizes[] = {
64 /* C4_B8_HSW */
};
+
+/* A generated mux config to select counters useful for profiling 3D
+ * workloads */
+static struct i915_oa_reg hsw_profile_3d_mux_config[] = {
+
+ { 0x253A4, 0x0160 },
+ { 0x25440, 0x0010 },
+ { 0x25128, 0x },
+ { 0x2691C, 0x0800 },
+ { 0x26AA0, 0x0150 },
+ { 0x26B9C, 0x6000 },
+ { 0x2791C, 0x0800 },
+ { 0x27AA0, 0x0150 },
+ { 0x27B9C, 0x6000 },
+ { 0x2641C, 0x0400 },
+ { 0x25380, 0x0010 },
+ { 0x2538C, 0x },
+ { 0x25384, 0x0800 },
+ { 0x25400, 0x0004 },
+ { 0x2540C, 0x06029000 },
+ { 0x25410, 0x0002 },
+ { 0x25404, 0x5C30 },
+ { 0x25100, 0x0016 },
+ { 0x25110, 0x0400 },
+ { 0x25104, 0x },
+ { 0x26804, 0x1211 },
+ { 0x26884, 0x0100 },
+ { 0x26900, 0x0002 },
+ { 0x26908, 0x0070 },
+ { 0x26904, 0x },
+ { 0x26984, 0x1022 },
+ { 0x26A04, 0x0011 },
+ { 0x26A80, 0x0006 },
+ { 0x26A88, 0x0C02 },
+ { 0x26A84, 0x },
+ { 0x26B04, 0x1000 },
+ { 0x26B80, 0x0002 },
+ { 0x26B8C, 0x0007 },
+ { 0x26B84, 0x },
+ { 0x27804, 0x4844 },
+ { 0x27884, 0x0400 },
+ { 0x27900, 0x0002 },
+ { 0x27908, 0x0E00 },
+ { 0x27904, 0x },
+ { 0x27984, 0x4088 },
+ { 0x27A04, 0x0044 },
+ { 0x27A80, 0x0006 },
+ { 0x27A88, 0x00018040 },
+ { 0x27A84, 0x },
+ { 0x27B04, 0x4000 },
+ { 0x27B80, 0x0002 },
+ { 0x27B8C, 0x00E0 },
+ { 0x27B84, 0x },
+ { 0x26104, 0x },
+ { 0x26184, 0x0C00 },
+ { 0x26284, 0x0400 },
+ { 0x26304, 0x0400 },
+ { 0x26400, 0x0002 },
+ { 0x26410, 0x00A0 },
+ { 0x26404, 0x },
+ { 0x25420, 0x04108020 },
+ { 0x25424, 0x1284A420 },
+ { 0x2541C, 0x },
+ { 0x25428, 0x00042049 },
+};
+
+/* A corresponding B counter configuration for profiling 3D workloads */
+static struct i915_oa_reg hsw_profile_3d_b_counter_config[] = {
+ { 0x2724, 0x0080 },
+ { 0x2720, 0x },
+ { 0x2714, 0x0080 },
+ { 0x2710, 0x },
+};
+
static void forward_one_oa_snapshot_to_event(struct drm_i915_private *dev_priv,
u8 *snapshot,
struct perf_event *event)
@@ -551,6 +625,19 @@ static void update_oacontrol(struct drm_i915_private
*dev_priv)
I915_WRITE(GEN7_OACONTROL, 0);
}
+static void config_oa_regs(struct drm_i915_private *dev_priv,
+ struct i915_oa_reg *regs,
+ int n_regs)
+{
+ int i;
+
+ for (i = 0; i < n_regs; i++) {
+ struct i915_oa_reg *reg = regs + i;
+
+ I915_WRITE(reg->addr, reg->value);
+ }
+}
+
static void i915_oa_event_start(struct perf_event *event, int flags)
{
struct drm_i915_private *dev_priv =
@@ -571,22 +658,31 @@ static void i915_oa_event_start(struct perf_event *event,
int flags)
WARN_ONCE(I915_READ(GEN6_UCGCTL3) & GEN6_OACSUNIT_CLOCK_GATE_DISABLE,
"disabled OA unit level clock gating will result in incorrect
per-context OA counters");
- /* XXX: On Haswell, when threshold disable mode is desired,
-* instead of setting the threshold enable to '0', we need to
-* program it to '1' and set OASTARTTRIG1 bits 15:0 to 0
-* (threshold value of 0)
-*/
- I915_WRITE(OASTARTTRIG6, (OASTARTTRIG6_B4_TO_B7_THRESHOLD_ENA
[RFC PATCH 07/11] drm/i915: Expose PMU for Observation Architecture
Gen graphics hardware can be set up to periodically write snapshots of
performance counters into a circular buffer and this patch exposes that
capability to userspace via the perf interface.
To start with this only enables the A (aggregating) counters with the
simplest configuration requirements.
Only Haswell is supported currently.
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_dma.c | 6 +
drivers/gpu/drm/i915/i915_drv.h | 53 +++
drivers/gpu/drm/i915/i915_gem_context.c | 45 +-
drivers/gpu/drm/i915/i915_oa_perf.c | 750
drivers/gpu/drm/i915/i915_reg.h | 68 +++
include/uapi/drm/i915_drm.h | 29 ++
7 files changed, 942 insertions(+), 10 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_oa_perf.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a69002e..8af9f4a 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -16,6 +16,7 @@ i915-y := i915_drv.o \
i915-$(CONFIG_COMPAT) += i915_ioc32.o
i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o
+i915-$(CONFIG_PERF_EVENTS) += i915_oa_perf.o
# GEM code
i915-y += i915_cmd_parser.o \
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index e44116f..1de6639 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -817,6 +817,11 @@ int i915_driver_load(struct drm_device *dev, unsigned long
flags)
mutex_init(&dev_priv->dpio_lock);
mutex_init(&dev_priv->modeset_restore_lock);
+ /* Must at least be registered before trying to pin any context
+* otherwise i915_oa_context_pin_notify() will lock an un-initialized
+* spinlock, upsetting lockdep checks */
+ i915_oa_pmu_register(dev);
+
intel_pm_setup(dev);
intel_display_crc_init(dev);
@@ -1062,6 +1067,7 @@ int i915_driver_unload(struct drm_device *dev)
return ret;
}
+ i915_oa_pmu_unregister(dev);
intel_power_domains_fini(dev_priv);
intel_gpu_ips_teardown();
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f5020a8..3d8e4ed 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -49,6 +49,7 @@
#include
#include
#include
+#include
#include
/* General customization:
@@ -1816,6 +1817,35 @@ struct drm_i915_private {
*/
struct workqueue_struct *dp_wq;
+#ifdef CONFIG_PERF_EVENTS
+ struct {
+ struct pmu pmu;
+ spinlock_t lock;
+ struct hrtimer timer;
+ struct pt_regs dummy_regs;
+
+ struct perf_event *exclusive_event;
+ struct intel_context *specific_ctx;
+ bool event_active;
+
+ bool periodic;
+ u32 period_exponent;
+
+ u32 metrics_set;
+
+ struct {
+ struct drm_i915_gem_object *obj;
+ u32 gtt_offset;
+ u8 *addr;
+ u32 head;
+ u32 tail;
+ int format;
+ int format_size;
+ spinlock_t flush_lock;
+ } oa_buffer;
+ } oa_pmu;
+#endif
+
/* Abstract the submission mechanism (legacy ringbuffer or execlists)
away */
struct {
int (*execbuf_submit)(struct drm_device *dev, struct drm_file
*file,
@@ -2975,6 +3005,20 @@ int i915_gem_context_getparam_ioctl(struct drm_device
*dev, void *data,
int i915_gem_context_setparam_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
+#ifdef CONFIG_PERF_EVENTS
+void i915_oa_context_pin_notify(struct drm_i915_private *dev_priv,
+ struct intel_context *context);
+void i915_oa_context_unpin_notify(struct drm_i915_private *dev_priv,
+ struct intel_context *context);
+#else
+static inline void
+i915_oa_context_pin_notify(struct drm_i915_private *dev_priv,
+ struct intel_context *context) {}
+static inline void
+i915_oa_context_unpin_notify(struct drm_i915_private *dev_priv,
+struct intel_context *context) {}
+#endif
+
/* i915_gem_evict.c */
int __must_check i915_gem_evict_something(struct drm_device *dev,
struct i915_address_space *vm,
@@ -3084,6 +3128,15 @@ int i915_parse_cmds(struct intel_engine_cs *ring,
u32 batch_len,
bool is_master);
+/* i915_oa_perf.c */
+#ifdef CONFIG_PERF_EVENTS
+extern void i915_oa_pmu_register(struct drm_device *dev);
+extern void i915_oa_pmu_unregister(struct drm_device *dev);
+#else
+static inline void i915_oa_pmu_register(struct drm_device *dev) {}
+static inline void i915_oa_pmu_unr
[RFC PATCH 06/11] drm/i915: rename OACONTROL GEN7_OACONTROL
OACONTROL changes quite a bit for gen8, with some bits split out into a
per-context OACTXCONTROL register
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++--
drivers/gpu/drm/i915/i915_reg.h| 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 9605ff8..f7ef20c 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -417,7 +417,7 @@ static const u32 gen7_render_regs[] = {
REG64(CL_PRIMITIVES_COUNT),
REG64(PS_INVOCATION_COUNT),
REG64(PS_DEPTH_COUNT),
- OACONTROL, /* Only allowed for LRI and SRM. See below. */
+ GEN7_OACONTROL, /* Only allowed for LRI and SRM. See below. */
REG64(MI_PREDICATE_SRC0),
REG64(MI_PREDICATE_SRC1),
GEN7_3DPRIM_END_OFFSET,
@@ -961,7 +961,7 @@ static bool check_cmd(const struct intel_engine_cs *ring,
* that will be written to the register. Hence, limit
* OACONTROL writes to only MI_LOAD_REGISTER_IMM commands.
*/
- if (reg_addr == OACONTROL) {
+ if (reg_addr == GEN7_OACONTROL) {
if (desc->cmd.value == MI_LOAD_REGISTER_MEM) {
DRM_DEBUG_DRIVER("CMD: Rejected LRM to
OACONTROL\n");
return false;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d47afbc..2fa1669 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -515,7 +515,7 @@
#define GEN7_3DPRIM_START_INSTANCE 0x243C
#define GEN7_3DPRIM_BASE_VERTEX 0x2440
-#define OACONTROL 0x2360
+#define GEN7_OACONTROL 0x2360
#define _GEN7_PIPEA_DE_LOAD_SL 0x70068
#define _GEN7_PIPEB_DE_LOAD_SL 0x71068
--
2.3.2
[RFC PATCH 05/11] perf: allow drivers more control over event logging
This exports enough api to allow drivers to output their own
PERF_RECORD_DEVICE events.
Signed-off-by: Robert Bragg
---
include/linux/perf_event.h | 7 +++
kernel/events/core.c| 2 ++
kernel/events/internal.h| 9 -
kernel/events/ring_buffer.c | 3 +++
4 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 69a0cb9..293f041 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -633,6 +633,10 @@ struct perf_sample_data {
PERF_MEM_S(LOCK, NA) |\
PERF_MEM_S(TLB, NA))
+extern void perf_event_header__init_id(struct perf_event_header *header,
+ struct perf_sample_data *data,
+ struct perf_event *event);
+
static inline void perf_sample_data_init(struct perf_sample_data *data,
u64 addr, u64 period)
{
@@ -654,6 +658,9 @@ extern void perf_prepare_sample(struct perf_event_header
*header,
struct perf_sample_data *data,
struct perf_event *event,
struct pt_regs *regs);
+extern void perf_event__output_id_sample(struct perf_event *event,
+struct perf_output_handle *handle,
+struct perf_sample_data *sample);
extern int perf_event_overflow(struct perf_event *event,
struct perf_sample_data *data,
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 340deaa..26b84fc 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4793,6 +4793,7 @@ void perf_event_header__init_id(struct perf_event_header
*header,
if (event->attr.sample_id_all)
__perf_event_header__init_id(header, data, event);
}
+EXPORT_SYMBOL_GPL(perf_event_header__init_id);
static void __perf_event__output_id_sample(struct perf_output_handle *handle,
struct perf_sample_data *data)
@@ -4825,6 +4826,7 @@ void perf_event__output_id_sample(struct perf_event
*event,
if (event->attr.sample_id_all)
__perf_event__output_id_sample(handle, sample);
}
+EXPORT_SYMBOL_GPL(perf_event__output_id_sample);
static void perf_output_read_one(struct perf_output_handle *handle,
struct perf_event *event,
diff --git a/kernel/events/internal.h b/kernel/events/internal.h
index 569b2187..3c86bb3 100644
--- a/kernel/events/internal.h
+++ b/kernel/events/internal.h
@@ -44,15 +44,6 @@ extern struct ring_buffer *
rb_alloc(int nr_pages, long watermark, int cpu, int flags);
extern void perf_event_wakeup(struct perf_event *event);
-extern void
-perf_event_header__init_id(struct perf_event_header *header,
- struct perf_sample_data *data,
- struct perf_event *event);
-extern void
-perf_event__output_id_sample(struct perf_event *event,
-struct perf_output_handle *handle,
-struct perf_sample_data *sample);
-
extern struct page *
perf_mmap_to_page(struct ring_buffer *rb, unsigned long pgoff);
diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
index eadb95c..fa100d4 100644
--- a/kernel/events/ring_buffer.c
+++ b/kernel/events/ring_buffer.c
@@ -202,12 +202,14 @@ out:
return -ENOSPC;
}
+EXPORT_SYMBOL_GPL(perf_output_begin);
unsigned int perf_output_copy(struct perf_output_handle *handle,
const void *buf, unsigned int len)
{
return __output_copy(handle, buf, len);
}
+EXPORT_SYMBOL_GPL(perf_output_copy);
unsigned int perf_output_skip(struct perf_output_handle *handle,
unsigned int len)
@@ -220,6 +222,7 @@ void perf_output_end(struct perf_output_handle *handle)
perf_output_put_handle(handle);
rcu_read_unlock();
}
+EXPORT_SYMBOL_GPL(perf_output_end);
static void
ring_buffer_init(struct ring_buffer *rb, long watermark, int flags)
--
2.3.2
[RFC PATCH 04/11] perf: Add a PERF_RECORD_DEVICE event type
To allow for more extensible, device specific, perf record types this
adds a generic PERF_RECORD_DEVICE type that can be used by device
drivers. Driver developers can then document some driver-specific header
to further detail such a record's type.
Signed-off-by: Robert Bragg
---
include/uapi/linux/perf_event.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index a25967b..688e192 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -726,6 +726,19 @@ enum perf_event_type {
*/
PERF_RECORD_MMAP2 = 10,
+ /*
+* The DEVICE record implies some device driver specific record that
+* will have some further mechanism for describing the contents of
+* the record (i.e. some driver specific event header).
+*
+* struct {
+* struct perf_event_headerheader;
+*
+* struct DEVICE_EVENT_HEADER device_header;
+* };
+*/
+ PERF_RECORD_DEVICE = 11,
+
PERF_RECORD_MAX,/* non-ABI */
};
--
2.3.2
[RFC PATCH 03/11] perf: Add PERF_EVENT_IOC_FLUSH ioctl
To allow for pmus that may have internal buffering (e.g. the hardware
itself writes out data to its own circular buffer which is only
periodically forwarded to userspace via perf) this ioctl enables
userspace to explicitly ensure it has received all samples before a
point in time.
Signed-off-by: Robert Bragg
---
include/linux/perf_event.h | 7 +++
include/uapi/linux/perf_event.h | 1 +
kernel/events/core.c| 5 +
3 files changed, 13 insertions(+)
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 1af35b4..69a0cb9 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -266,6 +266,13 @@ struct pmu {
* flush branch stack on context-switches (needed in cpu-wide mode)
*/
void (*flush_branch_stack) (void);
+
+ /*
+* Flush buffered samples (E.g. for pmu hardware that writes samples to
+* some intermediate buffer) userspace may need to explicitly ensure
+* such samples have been forwarded to perf.
+*/
+ void (*flush) (struct perf_event *event); /*optional
*/
};
/**
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index 9b79abb..a25967b 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -360,6 +360,7 @@ struct perf_event_attr {
#define PERF_EVENT_IOC_SET_OUTPUT _IO ('$', 5)
#define PERF_EVENT_IOC_SET_FILTER _IOW('$', 6, char *)
#define PERF_EVENT_IOC_ID _IOR('$', 7, __u64 *)
+#define PERF_EVENT_IOC_FLUSH _IO ('$', 8)
enum perf_event_ioc_flags {
PERF_IOC_FLAG_GROUP = 1U << 0,
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 7218b01..340deaa 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3981,6 +3981,11 @@ static long _perf_ioctl(struct perf_event *event,
unsigned int cmd, unsigned lon
case PERF_EVENT_IOC_SET_FILTER:
return perf_event_set_filter(event, (void __user *)arg);
+ case PERF_EVENT_IOC_FLUSH:
+ if (event->pmu->flush)
+ event->pmu->flush(event);
+ return 0;
+
default:
return -ENOTTY;
}
--
2.3.2
[RFC PATCH 02/11] perf: Add PERF_PMU_CAP_IS_DEVICE flag
The PERF_PMU_CAP_IS_DEVICE flag provides pmu drivers a way to declare
that they only monitor device specific metrics and since they don't
monitor any cpu metrics then perf should bypass any cpu centric security
checks, as well as disallow cpu centric attributes.
Signed-off-by: Robert Bragg
---
include/linux/perf_event.h | 1 +
kernel/events/core.c | 39 +--
2 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 2b62198..1af35b4 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -166,6 +166,7 @@ struct perf_event;
* pmu::capabilities flags
*/
#define PERF_PMU_CAP_NO_INTERRUPT 0x01
+#define PERF_PMU_CAP_IS_DEVICE 0x02
/**
* struct pmu - generic performance monitoring unit
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 38c240c..7218b01 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3330,7 +3330,8 @@ find_get_context(struct pmu *pmu, struct task_struct
*task, int cpu)
if (!task) {
/* Must be root to operate on a CPU event: */
- if (perf_paranoid_cpu() && !capable(CAP_SYS_ADMIN))
+ if (!(pmu->capabilities & PERF_PMU_CAP_IS_DEVICE) &&
+ perf_paranoid_cpu() && !capable(CAP_SYS_ADMIN))
return ERR_PTR(-EACCES);
/*
@@ -7475,11 +7476,6 @@ SYSCALL_DEFINE5(perf_event_open,
if (err)
return err;
- if (!attr.exclude_kernel) {
- if (perf_paranoid_kernel() && !capable(CAP_SYS_ADMIN))
- return -EACCES;
- }
-
if (attr.freq) {
if (attr.sample_freq > sysctl_perf_event_sample_rate)
return -EINVAL;
@@ -7538,6 +7534,37 @@ SYSCALL_DEFINE5(perf_event_open,
goto err_cpus;
}
+ if (event->pmu->capabilities & PERF_PMU_CAP_IS_DEVICE) {
+
+ /* Don't allow cpu centric attributes... */
+ if (event->attr.exclude_user ||
+ event->attr.exclude_callchain_user ||
+ event->attr.exclude_kernel ||
+ event->attr.exclude_callchain_kernel ||
+ event->attr.exclude_hv ||
+ event->attr.exclude_idle ||
+ event->attr.exclude_host ||
+ event->attr.exclude_guest ||
+ event->attr.mmap ||
+ event->attr.comm ||
+ event->attr.task)
+ return -EINVAL;
+
+ if (attr.sample_type &
+ (PERF_SAMPLE_IP |
+PERF_SAMPLE_TID |
+PERF_SAMPLE_ADDR |
+PERF_SAMPLE_CALLCHAIN |
+PERF_SAMPLE_CPU |
+PERF_SAMPLE_BRANCH_STACK |
+PERF_SAMPLE_REGS_USER |
+PERF_SAMPLE_STACK_USER))
+ return -EINVAL;
+ } else if (!attr.exclude_kernel) {
+ if (perf_paranoid_kernel() && !capable(CAP_SYS_ADMIN))
+ return -EACCES;
+ }
+
if (flags & PERF_FLAG_PID_CGROUP) {
err = perf_cgroup_connect(pid, event, &attr, group_leader);
if (err) {
--
2.3.2
[RFC PATCH 01/11] perf: export perf_event_overflow
To support pmu drivers in loadable modules, such as the i915 driver
Signed-off-by: Robert Bragg
---
kernel/events/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 2fabc06..38c240c 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5851,6 +5851,7 @@ int perf_event_overflow(struct perf_event *event,
{
return __perf_event_overflow(event, 1, data, regs);
}
+EXPORT_SYMBOL_GPL(perf_event_overflow);
/*
* Generic software event infrastructure
--
2.3.2
[RFC PATCH 00/11] drm/i915: Expose OA metrics via perf PMU
This is an updated series adding support for an "i915_oa" perf PMU for configuring the Intel Gen graphics Observability unit (Haswell only to start with) and forwarding periodic counter reports as perf samples. Compared to the series I sent out last year: The driver is now hooked into context switching so we no longer require a context to be pinned for the full lifetime of a perf event fd (when profiling a specific context). Not visible in the series, but I can say we've also gained some experience from looking at enabling Broadwell within the same architecture. There are some fiddly challenges ahead with enabling Broadwell but I do feel comfortable that it can be supported in the same kind of way via perf. I haven't updated my Broadwell branches for a little while now but if anyone is interested I can share this code as a point of reference if that's helpful. As I've had interest from folks looking at developing tools based on this interface to not require root, but we are following the precedent of not exposing system wide metrics to unprivileged processes, I've added a sysctl directly comparable to kernel.perf_event_paranoid (dev.i915.oa_event_paranoid) that lets users optionally allow unprivileged access to system wide gpu metrics. This series is able to expose more than just the A (aggregating) counters and demonstrates selecting a more counters that are useful when benchmarking 3D render workloads. The expectation is to add further configurations later geared towards media or gpgpu workloads for example. I've changed the uapi for configuring the i915_oa specific attributes when calling perf_event_open(2) whereby instead of cramming lots of bitfields into the perf_event_attr config members, I'm now daisy-chaining a drm_i915_oa_event_attr_t structure off of a single config member that's extensible and validated in the same way as the perf_event_attr struct. I've found this much nicer to work with while being neatly extensible too. I've made a few more (small) changes to core perf infrastructure: I've added a PERF_EVENT_IOC_FLUSH ioctl that can be used to explicitly ask the driver to flush buffered samples. In our case this makes sure to forward all reports currently in the gpu mapped, circular, oabuffer as perf samples. This issue was discussed a bit on LKML last year and previously I was overloading our PMU's read() hook but decided that the cleaner approach would be to add a dedicated ioctl instead. To allow device-driver PMUs to define their own types for records written to the perf circular buffer I've introduced a PERF_RECORD_DEVICE type whereby drivers can then document their own header defining a driver specific scheme for sub-types. This is then used in the i915_oa driver for reporting hw status conditions such as OABUFFER overruns or report lost conditions from the hw. For examples of using the i915_oa driver I have a branch of Mesa that enables support for the INTEL_performance_query extension based on this: https://github.com/rib/drm wip/rib/oa-hsw-4.0.0 https://github.com/rib/mesa wip/rib/oa-hsw-4.0.0 For reference I sent out a corresponding series for the Mesa work for review yesterday: http://lists.freedesktop.org/archives/mesa-dev/2015-May/083519.html I also have a minimal gputop tool that can both test Mesa's INTEL_performance_query implementation to view per-context metrics or it can view system wide gpu metrics collected directly from perf (gputop/gputop-perf.c would be the main code of interest): https://github.com/rib/gputop If it's convenient for testing, my kernel patches can also be fetched from here: https://github.com/rib/linux wip/rib/oa-hsw-4.0.0 One specific patch comment: [RFC PATCH 11/11] WIP: drm/i915: constrain unit gating while using OA I didn't want to hold up getting feedback due to this issue that I'm currently investigating (since the effect on the driver should be trivial) but I've included a work-in-progress patch since it does address a known problem with collecting reliable periodic metrics. Besides the last patch, I feel like this series is in pretty good shape now and by testing it with Mesa and several profiling tools as well as starting the work to enable Broadwell I feel quite happy with our approach of leveraging perf infrastructure. I'd really appreciate any feedback on the core perf changes I've made, as well as general feedback on the PMU driver itself. Since it's been quite a long time since I last sent out patches for this work; in case it's helpful to refer back to some of the discussion last year: https://lkml.org/lkml/2014/10/22/462 For anyone interested to know more details about this hardware, this PRM is a good starting point: https://01.org/sites/default/files/documentation/ observability_performance_counters_haswell.pdf Kind regards, - Robert Robert Bragg (11): perf: export perf_event_overflow perf: Add PERF_PMU_CAP_IS_DEVICE flag perf: Add PERF_EVENT_IOC_FLUSH ioctl perf: Add a PERF_RECORD_DEVICE event
[Bug 90340] RADEON "PITCAIRN" displayport output breaks when monitor turned off and on
https://bugs.freedesktop.org/show_bug.cgi?id=90340 --- Comment #3 from Alex Deucher --- Does forcing a dpms cycle also work? E.g., sleep 5; xset dpms force off Does turning the monitor off work with other drivers or OSes? DP requires link training to bring the link up between the monitor and the GPU. I suspect when you physically turn off/on the monitor, it does not generate a hotplug signal so the driver had no way of knowing that the link needs to be re-established. -- 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/20150507/6ba5e63a/attachment-0001.html>
[PATCH] drm/msm: Fix compil issue when DRM_MSM_FBDEV is disabled
Hi,
On 05/06/2015 07:58 PM, Rob Clark wrote:
> On Wed, May 6, 2015 at 9:25 AM, Stephane Viau wrote:
>> When CONFIG_DRM_MSM_FBDEV is not defined,
>> CONFIG_DRM_KMS_FB_HELPER does not get selected and
>> drm_fb_helper_*() helper functions are thus not available.
>>
>> This change fixes these link issues.
>
> Hmm, didn't Archit start on making fbdev config option global and
> adding nop-stubs for the case that it was disabled? I lost track of
> where that was going..
Daniel and I had thought of a possible solution. I had started working
on it, but it's still work in progress. It required more things to do
than originally thought of.
I don't know if that work will make it in time for 4.2. Maybe we could
pull this for the time being?
Archit
>
> BR,
> -R
>
>> Signed-off-by: Stephane Viau
>> ---
>> drivers/gpu/drm/msm/msm_drv.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
>> index 2b1218c..35380ec 100644
>> --- a/drivers/gpu/drm/msm/msm_drv.c
>> +++ b/drivers/gpu/drm/msm/msm_drv.c
>> @@ -21,9 +21,11 @@
>>
>> static void msm_fb_output_poll_changed(struct drm_device *dev)
>> {
>> +#ifdef DRM_MSM_FBDEV
>> struct msm_drm_private *priv = dev->dev_private;
>> if (priv->fbdev)
>> drm_fb_helper_hotplug_event(priv->fbdev);
>> +#endif
>> }
>>
>> static const struct drm_mode_config_funcs mode_config_funcs = {
>> @@ -419,9 +421,11 @@ static void msm_preclose(struct drm_device *dev, struct
>> drm_file *file)
>>
>> static void msm_lastclose(struct drm_device *dev)
>> {
>> +#ifdef DRM_MSM_FBDEV
>> struct msm_drm_private *priv = dev->dev_private;
>> if (priv->fbdev)
>> drm_fb_helper_restore_fbdev_mode_unlocked(priv->fbdev);
>> +#endif
>> }
>>
>> static irqreturn_t msm_irq(int irq, void *arg)
>> --
>> Qualcomm Innovation Center, Inc.
>>
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a
>> Linux Foundation Collaborative Project
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
[Bug 90360] [RV710/M92] GPU lockup caused by shader based MPEG2 decoding
https://bugs.freedesktop.org/show_bug.cgi?id=90360 --- Comment #5 from Mohammad AlSaleh --- Yes. I already have my player configured to only use VDPAU with H264(by default). However, playback is not the only use-case of hardware acceleration. I actually stumbled upon this bug when a script called "ffmpeg" with "-hwaccel vdpau". So, this bug can be triggered in scenarios that are not user-visible. Which makes it more severe IMHO. May I suggest disabling hardware MPEG2 decoding completely for the time being? -- 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/20150507/0f9e6e51/attachment-0001.html>
[alsa-devel] [PATCH RFC v2 10/13] sound/core: add DRM ELD helper
On 05/07/2015 12:41 PM, Russell King - ARM Linux wrote: [...] >>> What I'm concerned about is that when the ALSA parameter refining >>> starts, we start with (eg) 2-8 channels, 32-192kHz. Given that, >>> if we invoke the channel restriction before the rate restriction, >>> we would end up limiting to 2 channel at 32-192kHz. If we apply >>> the restrictions in the opposite order, we'd restrict to 6 >>> channel, 32-48kHz. Neither are obviously correct in this >>> circumstance, and I don't really see a way to solve it given my >>> understanding of the way ALSA's parameter refinement works. >>> >>> I suspect this is why most HDMI drivers are implemented such that >>> they take the maximum capabilities over all SADs, which would end >>> up restricting audio in the above case to: up to 6 channels, at >>> 32, 44.1, 48, 96 and 192kHz, even though 6 channel @ 192kHz isn't >>> hasn't been indicated as supported. >>> >>> Most of this is speculation though, based off what is in the >>> documentation. As I say, I don't have enough real-world examples >>> to get a feel for what manufacturers _actually_ do to give a hint >>> as to how the documentation should be interpreted. > > ... so this is probably less than speculation. > > So, ALSA gurus, how do we handle this? How do we arrange the parameter > resolution such that ALSA can permit _either_ 2 channels at 192kHz or 6 > channels at 48kHz, but not 6 channels at 192kHz? Right now, I don't > see how that's possible. That's pretty straight forward and can be done using custom rules linking the number of channels to the sample rate. Have a look at snd_ac97_pcm_double_rate_rules() this is pretty much the same constraint. - Lars
[PATCH] qxl: rewrite framebuffer support
On 5 May 2015 at 21:52, Gerd Hoffmann wrote: > Completely different approach: Instead of encoding each and every > framebuffer update as spice operation simply update the shadow > framebuffer and maintain a dirty rectangle. Also schedule a worker > to push an update for the dirty rectangle as spice operation. Usually > a bunch of dirty rectangle updates are collected before the worker > actually runs. > > What changes: Updates get batched now. Instead of sending tons of > small updates a few large ones are sent. When the same region is > updated multiple times within a short timeframe (scrolling multiple > lines for example) we send a single update only. Spice server has an > easier job now: The dependency tree for display operations which spice > server maintains for lazy rendering is alot smaller now. Spice server's > image compression probably works better too with the larger image blits. > > Net effect: framebuffer console @ qxldrmfb is an order of magnitude > faster now. > > Signed-off-by: Gerd Hoffmann Looks good, I often wondered if we should have done this, spice protocol overhead seemed quite high. I'll merge this into drm-next. Dave.
[PATCH] dma-buf: add ref counting for module as exporter
Add reference counting on a kernel module that exports dma-buf and
implements its operations. This prevents the module from being unloaded
while DMABUF file is in use.
The original patch [1] was submitted by Tomasz, but he's since shifted
jobs and a ping didn't elicit any response.
[tomasz: Original author]
Signed-off-by: Tomasz Stanislawski
Acked-by: Daniel Vetter
[sumits: updated & rebased as per review comments]
Signed-off-by: Sumit Semwal
[1]: https://lkml.org/lkml/2012/8/8/163
---
drivers/dma-buf/dma-buf.c | 9 -
drivers/gpu/drm/armada/armada_gem.c| 1 +
drivers/gpu/drm/drm_prime.c| 1 +
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 1 +
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 1 +
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 1 +
drivers/gpu/drm/tegra/gem.c| 1 +
drivers/gpu/drm/udl/udl_dmabuf.c | 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 1 +
drivers/media/v4l2-core/videobuf2-dma-contig.c | 1 +
drivers/media/v4l2-core/videobuf2-dma-sg.c | 1 +
drivers/media/v4l2-core/videobuf2-vmalloc.c| 1 +
drivers/staging/android/ion/ion.c | 1 +
include/linux/dma-buf.h| 2 ++
14 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index c5a9138a6a8d..9583eac0238f 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -64,6 +65,7 @@ static int dma_buf_release(struct inode *inode, struct file
*file)
BUG_ON(dmabuf->cb_shared.active || dmabuf->cb_excl.active);
dmabuf->ops->release(dmabuf);
+ module_put(dmabuf->ops->owner);
mutex_lock(&db_list.lock);
list_del(&dmabuf->list_node);
@@ -302,9 +304,14 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
return ERR_PTR(-EINVAL);
}
+ if (!try_module_get(exp_info->ops->owner))
+ return ERR_PTR(-ENOENT);
+
dmabuf = kzalloc(alloc_size, GFP_KERNEL);
- if (dmabuf == NULL)
+ if (!dmabuf) {
+ module_put(exp_info->ops->owner);
return ERR_PTR(-ENOMEM);
+ }
dmabuf->priv = exp_info->priv;
dmabuf->ops = exp_info->ops;
diff --git a/drivers/gpu/drm/armada/armada_gem.c
b/drivers/gpu/drm/armada/armada_gem.c
index 580e10acaa3a..d2c5fc1269b7 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -524,6 +524,7 @@ armada_gem_dmabuf_mmap(struct dma_buf *buf, struct
vm_area_struct *vma)
}
static const struct dma_buf_ops armada_gem_prime_dmabuf_ops = {
+ .owner = THIS_MODULE,
.map_dma_buf= armada_gem_prime_map_dma_buf,
.unmap_dma_buf = armada_gem_prime_unmap_dma_buf,
.release= drm_gem_dmabuf_release,
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7fec191b45f7..ed4a6e35dd91 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -289,6 +289,7 @@ static int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf,
}
static const struct dma_buf_ops drm_gem_prime_dmabuf_ops = {
+ .owner = THIS_MODULE,
.attach = drm_gem_map_attach,
.detach = drm_gem_map_detach,
.map_dma_buf = drm_gem_map_dma_buf,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index cd485c091b30..35fa029353e9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -169,6 +169,7 @@ static int exynos_gem_dmabuf_mmap(struct dma_buf *dma_buf,
}
static struct dma_buf_ops exynos_dmabuf_ops = {
+ .owner = THIS_MODULE,
.attach = exynos_gem_attach_dma_buf,
.detach = exynos_gem_detach_dma_buf,
.map_dma_buf= exynos_gem_map_dma_buf,
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 7998da27c500..b9355d8d4862 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -213,6 +213,7 @@ static int i915_gem_begin_cpu_access(struct dma_buf
*dma_buf, size_t start, size
}
static const struct dma_buf_ops i915_dmabuf_ops = {
+ .owner = THIS_MODULE,
.map_dma_buf = i915_gem_map_dma_buf,
.unmap_dma_buf = i915_gem_unmap_dma_buf,
.release = drm_gem_dmabuf_release,
diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
index 344fd789170d..977ece9be62c 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
@@ -156,6 +156,7 @@ static int omap_gem_dmabuf_mmap(struct dma_buf *buffer,
}
static struct dma_buf_ops omap_dmabuf_ops = {
+ .owner = THIS_MODULE,
[Intel-gfx] [PATCH 6/8] pwm: crc: Add Crystalcove (CRC) PWM driver
On Wed, May 6, 2015 at 5:44 PM, Thierry Reding
wrote:
> On Tue, May 05, 2015 at 03:08:36PM +0530, Shobhit Kumar wrote:
>> The Crystalcove PMIC controls PWM signals and this driver exports that
>
> You say signal_s_ here, but you only expose a single PWM device. Does
> the PMIC really control more than one? If it isn't, this should probably
> become: "controls a PWM output and this driver...".
Actually it does support 3 of them but on the platform only one is
being used and I exported only that as of now. Probably I should
expand a little in the commit message indicating this. will re-post
after fixing based on your other comments.
Regards
Shobhit
>
>> capability as a PWM chip driver. This is platform device implementtaion
>
> "implementation"
>
>> of the drivers/mfd cell device for CRC PMIC
>
> Sentences should end with a full stop.
>
>> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
>> index b1541f4..954da3e 100644
>> --- a/drivers/pwm/Kconfig
>> +++ b/drivers/pwm/Kconfig
>> @@ -183,6 +183,13 @@ config PWM_LPC32XX
>> To compile this driver as a module, choose M here: the module
>> will be called pwm-lpc32xx.
>>
>> +config PWM_CRC
>> + bool "Intel Crystalcove (CRC) PWM support"
>> + depends on X86 && INTEL_SOC_PMIC
>> + help
>> + Generic PWM framework driver for Crystalcove (CRC) PMIC based PWM
>> + control.
>> +
>
> This is badly sorted. Please keep the list sorted alphabetically.
>
>> config PWM_LPSS
>> tristate "Intel LPSS PWM support"
>> depends on X86
>> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
>> index ec50eb5..3d38fed 100644
>> --- a/drivers/pwm/Makefile
>> +++ b/drivers/pwm/Makefile
>> @@ -35,3 +35,4 @@ obj-$(CONFIG_PWM_TIPWMSS) += pwm-tipwmss.o
>> obj-$(CONFIG_PWM_TWL)+= pwm-twl.o
>> obj-$(CONFIG_PWM_TWL_LED)+= pwm-twl-led.o
>> obj-$(CONFIG_PWM_VT8500) += pwm-vt8500.o
>> +obj-$(CONFIG_PWM_CRC)+= pwm-crc.o
>
> This too.
>
>> diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
>> new file mode 100644
>> index 000..987f3b4
>> --- /dev/null
>> +++ b/drivers/pwm/pwm-crc.c
>> @@ -0,0 +1,171 @@
>> +/*
>> + * pwm-crc.c - Intel Crystal Cove PWM Driver
>
> I think you can safely remove this line. You already know what file it
> is when you open it in your editor, and the description is in the
> MODULE_DESCRIPTION string already.
>
>> + *
>> + * Copyright (C) 2015 Intel Corporation. All rights reserved.
>> + *
>> + * 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.
>> + *
>> + * Author: Shobhit Kumar
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define PWM0_CLK_DIV 0x4B
>> +#define PWM_OUTPUT_ENABLE (1<<7)
>
> Should have spaces around <<.
>
>> +#define PWM_DIV_CLK_0 0x00 /* DIVIDECLK = BASECLK */
>> +#define PWM_DIV_CLK_100 0x63 /* DIVIDECLK = BASECLK/100 */
>> +#define PWM_DIV_CLK_128 0x7F /* DIVIDECLK = BASECLK/128 */
>> +
>> +#define PWM0_DUTY_CYCLE 0x4E
>> +#define BACKLIGHT_EN 0x51
>> +
>> +#define PWM_MAX_LEVEL0xFF
>> +
>> +#define PWM_BASE_CLK 6000/* 6 MHz */
>
> This number is actually 6 KHz. I think it'd be better if you stuck with
> one unit here. Or perhaps there's some other reason why you can't use
> 600 here instead?
>
>> +#define PWM_MAX_PERIOD_NS21333 /* 46.875KHz */
>> +
>> +/**
>> + * struct crystalcove_pwm - Crystal Cove PWM controller
>> + * @chip: the abstract pwm_chip structure.
>> + * @regmap: the regmap from the parent device.
>> + */
>> +struct crystalcove_pwm {
>> + struct pwm_chip chip;
>> + struct platform_device *pdev;
>
> I think I had at some point requested that you get rid of this and use
> the chip.dev member instead. There's no kerneldoc for it and it isn't
> (well, almost, see below) used anywhere else, so perhaps you forgot to
> remove it here?
>
>> + struct regmap *regmap;
>> +};
>> +
>> +static inline struct crystalcove_pwm *to_crc_pwm(struct pwm_chip *pc)
>> +{
>> + return container_of(pc, struct crystalcove_pwm, chip);
>> +}
>> +
>> +static int crc_pwm_enable(struct pwm_chip *c, struct pwm_device *pwm)
>> +{
>> + struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
>> +
>> + regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 1);
>> +
>> + return 0;
>> +}
>> +
>> +static void crc_pwm_disable(struct pwm_chip *c, struct pwm_device *pwm)
>> +{
>> + struct crystalcove_pwm *crc_pwm = to_crc_pwm(c);
>> +
>> + regmap_write(crc_pwm->regmap, BACKLIGHT_EN, 0);
>> +}
>> +
>> +
[pull] radeon drm-fixes-4.1
Hi Dave, Mostly stability fixes for UVD and VCE, plus a few other bug and regression fixes. The following changes since commit 71aee81937963ccb07b3fa1b912e4cc6cd77dfa8: Merge tag 'drm-intel-fixes-2015-04-30' of git://anongit.freedesktop.org/drm-intel into drm-fixes (2015-05-04 08:56:47 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.1 for you to fetch changes up to 12e49feadff6d7b7ebbe852b36943a71524d8d34: drm/radeon: stop trying to suspend UVD sessions (2015-05-07 11:00:18 -0400) Alex Deucher (1): drm/radeon: don't setup audio on asics that don't support it Christian König (6): drm/radeon: disable semaphores for UVD V1 (v2) drm/radeon: fix userptr lockup drm/radeon: make VCE handle check more strict drm/radeon: make UVD handle checking more strict drm/radeon: more strictly validate the UVD codec drm/radeon: stop trying to suspend UVD sessions monk.liu (1): drm/radeon: fix userptr BO unpin bug v3 drivers/gpu/drm/radeon/radeon.h | 1 - drivers/gpu/drm/radeon/radeon_asic.c | 2 +- drivers/gpu/drm/radeon/radeon_asic.h | 4 + drivers/gpu/drm/radeon/radeon_audio.c | 4 + drivers/gpu/drm/radeon/radeon_mn.c| 3 + drivers/gpu/drm/radeon/radeon_ttm.c | 8 +- drivers/gpu/drm/radeon/radeon_uvd.c | 144 ++ drivers/gpu/drm/radeon/radeon_vce.c | 65 +++ drivers/gpu/drm/radeon/rv770d.h | 3 + drivers/gpu/drm/radeon/uvd_v1_0.c | 14 +--- drivers/gpu/drm/radeon/uvd_v2_2.c | 29 +++ 11 files changed, 190 insertions(+), 87 deletions(-)
[PATCH v4 0/7] Use DRM component API in tilcdc to connect to tda998x
- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150507/cef91e8a/attachment-0001.sig>
[Intel-gfx] [PATCH 6/8] pwm: crc: Add Crystalcove (CRC) PWM driver
On Wed, May 6, 2015 at 1:10 PM, Paul Bolle wrote: > On Tue, 2015-05-05 at 15:08 +0530, Shobhit Kumar wrote: >> The Crystalcove PMIC controls PWM signals and this driver exports that >> capability as a PWM chip driver. This is platform device implementtaion >> of the drivers/mfd cell device for CRC PMIC >> >> v2: Use the existing config callback with duty_ns and period_ns(Thierry) >> >> v3: Correct the subject line (Lee jones) >> >> CC: Samuel Ortiz >> Cc: Linus Walleij >> Cc: Alexandre Courbot >> Cc: Thierry Reding >> Signed-off-by: Shobhit Kumar > > The same comments can be made as for v2, see > http://lkml.kernel.org/r/1430428322.2187.24.camel at x220 . Maybe you > didn't receive that message. > > It could also be that you think my comments were invalid, or too vague, > or whatever. Please say so, because then I don't have to bother you > again when you send out v4. > Not at all, I just missed your comments and realise my mistake later after sending next update. Somehow the mailing list filters that I have setup are not working correctly. I will look into your comments. Regards Shobhit
[Bug 90360] [RV710/M92] GPU lockup caused by shader based MPEG2 decoding
https://bugs.freedesktop.org/show_bug.cgi?id=90360 Christian König changed: What|Removed |Added Summary|[RV710/M92] Soft lock |[RV710/M92] GPU lockup |caused by UVD (linux 4.0.1) |caused by shader based ||MPEG2 decoding -- 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/20150507/113d4364/attachment.html>
[Bug 90360] [RV710/M92] Soft lock caused by UVD (linux 4.0.1)
https://bugs.freedesktop.org/show_bug.cgi?id=90360 --- Comment #4 from Christian König --- The UVD block on the RV710 doesn't support MPEG2 in hardware. Because of that we fall back to shader based MPEG2 decoding and that seems to crash the GPU. IIRC this used to work on RV710, but I'm not 100% sure. Best solution I can see is to configure your player to not try to use hw acceleration for MPEG2. -- 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/20150507/a36e651d/attachment.html>
[PATCH 1/4] drm/radeon: make VCE handle check more strict
On Thu, May 7, 2015 at 9:19 AM, Christian König
wrote:
> From: Christian König
>
> Invalid handles can crash the hw.
>
> Signed-off-by: Christian König
> CC: stable at vger.kernel.org
Applied the series to my -fixes tree.
Alex
> ---
> drivers/gpu/drm/radeon/radeon_vce.c | 65
> +++--
> 1 file changed, 48 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_vce.c
> b/drivers/gpu/drm/radeon/radeon_vce.c
> index 24f849f..0de5711 100644
> --- a/drivers/gpu/drm/radeon/radeon_vce.c
> +++ b/drivers/gpu/drm/radeon/radeon_vce.c
> @@ -493,18 +493,27 @@ int radeon_vce_cs_reloc(struct radeon_cs_parser *p, int
> lo, int hi,
> *
> * @p: parser context
> * @handle: handle to validate
> + * @allocated: allocated a new handle?
> *
> * Validates the handle and return the found session index or -EINVAL
> * we we don't have another free session index.
> */
> -int radeon_vce_validate_handle(struct radeon_cs_parser *p, uint32_t handle)
> +static int radeon_vce_validate_handle(struct radeon_cs_parser *p,
> + uint32_t handle, bool *allocated)
> {
> unsigned i;
>
> + *allocated = false;
> +
> /* validate the handle */
> for (i = 0; i < RADEON_MAX_VCE_HANDLES; ++i) {
> - if (atomic_read(&p->rdev->vce.handles[i]) == handle)
> + if (atomic_read(&p->rdev->vce.handles[i]) == handle) {
> + if (p->rdev->vce.filp[i] != p->filp) {
> + DRM_ERROR("VCE handle collision detected!\n");
> + return -EINVAL;
> + }
> return i;
> + }
> }
>
> /* handle not found try to alloc a new one */
> @@ -512,6 +521,7 @@ int radeon_vce_validate_handle(struct radeon_cs_parser
> *p, uint32_t handle)
> if (!atomic_cmpxchg(&p->rdev->vce.handles[i], 0, handle)) {
> p->rdev->vce.filp[i] = p->filp;
> p->rdev->vce.img_size[i] = 0;
> + *allocated = true;
> return i;
> }
> }
> @@ -529,10 +539,10 @@ int radeon_vce_validate_handle(struct radeon_cs_parser
> *p, uint32_t handle)
> int radeon_vce_cs_parse(struct radeon_cs_parser *p)
> {
> int session_idx = -1;
> - bool destroyed = false;
> + bool destroyed = false, created = false, allocated = false;
> uint32_t tmp, handle = 0;
> uint32_t *size = &tmp;
> - int i, r;
> + int i, r = 0;
>
> while (p->idx < p->chunk_ib->length_dw) {
> uint32_t len = radeon_get_ib_value(p, p->idx);
> @@ -540,18 +550,21 @@ int radeon_vce_cs_parse(struct radeon_cs_parser *p)
>
> if ((len < 8) || (len & 3)) {
> DRM_ERROR("invalid VCE command length (%d)!\n", len);
> - return -EINVAL;
> + r = -EINVAL;
> + goto out;
> }
>
> if (destroyed) {
> DRM_ERROR("No other command allowed after
> destroy!\n");
> - return -EINVAL;
> + r = -EINVAL;
> + goto out;
> }
>
> switch (cmd) {
> case 0x0001: // session
> handle = radeon_get_ib_value(p, p->idx + 2);
> - session_idx = radeon_vce_validate_handle(p, handle);
> + session_idx = radeon_vce_validate_handle(p, handle,
> +&allocated);
> if (session_idx < 0)
> return session_idx;
> size = &p->rdev->vce.img_size[session_idx];
> @@ -561,6 +574,13 @@ int radeon_vce_cs_parse(struct radeon_cs_parser *p)
> break;
>
> case 0x0101: // create
> + created = true;
> + if (!allocated) {
> + DRM_ERROR("Handle already in use!\n");
> + r = -EINVAL;
> + goto out;
> + }
> +
> *size = radeon_get_ib_value(p, p->idx + 8) *
> radeon_get_ib_value(p, p->idx + 10) *
> 8 * 3 / 2;
> @@ -578,12 +598,12 @@ int radeon_vce_cs_parse(struct radeon_cs_parser *p)
> r = radeon_vce_cs_reloc(p, p->idx + 10, p->idx + 9,
> *size);
> if (r)
> - return r;
> + goto out;
>
> r = radeon_vce_cs_reloc(p, p->idx + 12, p->idx + 11,
> *size
drm/exynos: Add atomic modesetting support
Hi, On 2015ë 05ì 07ì¼ 06:45, Gustavo Padovan wrote: > Hi Inki and Joonyoung. > > Any thoughts on this? You need to resolve one issue that booting is still halted when one more crtc drivers are enabled, which is a dead lock issue incurred by register_framebuffer call. For this, I pointed out already at v3. The last patch may resolve invalid memory access which state->crtc had NULL while modetest is being performed but it didn't resolve above booting halt issue. So as of now, I have merged this patch series for more reviews to exynos-drm-next-todo yesterday. I will move them to exynos-drm-next if the issue is resolved. Thanks, Inki Dae > > 2015-04-30 Gustavo Padovan : > >> Hi, >> >> Here goes the full support for atomic modesetting on exynos. I've >> split the patches in the various phases of atomic support. >> >> v2: fixes comments by Joonyoung >> - remove unused var in patch 09 >> - use ->disable instead of outdated ->dpms in hdmi code >> - remove WARN_ON from crtc enable/disable >> >> v3: fixes comment by Joonyoung >> - move the removal of drm_helper_disable_unused_functions() to >> separated patch >> >> v4: add patches that remove unnecessary calls to disable_plane() >> >> Gustavo >> >> --- >> Gustavo Padovan (12): >> drm/exynos: atomic phase 1: use drm_plane_helper_update() >> drm/exynos: atomic phase 1: use drm_plane_helper_disable() >> drm/exynos: atomic phase 1: add .mode_set_nofb() callback >> drm/exynos: atomic phase 2: wire up state reset(), duplicate() and >> destroy() >> drm/exynos: atomic phase 2: keep track of framebuffer pointer >> drm/exynos: atomic phase 3: atomic updates of planes >> drm/exynos: atomic phase 3: use atomic .set_config helper >> drm/exynos: atomic phase 3: convert page flips >> drm/exynos: remove exported functions from exynos_drm_plane >> drm/exynos: don't disable unused functions at init >> drm/exynos: atomic dpms support >> drm/exynos: remove unnecessary calls to disable_plane() >> >> drivers/gpu/drm/bridge/ps8622.c | 6 +- >> drivers/gpu/drm/bridge/ptn3460.c| 6 +- >> drivers/gpu/drm/exynos/exynos_dp_core.c | 6 +- >> drivers/gpu/drm/exynos/exynos_drm_crtc.c| 215 >> +-- >> drivers/gpu/drm/exynos/exynos_drm_dpi.c | 6 +- >> drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 + >> drivers/gpu/drm/exynos/exynos_drm_drv.h | 4 +- >> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 +- >> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 35 + >> drivers/gpu/drm/exynos/exynos_drm_fb.c | 12 +- >> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 - >> drivers/gpu/drm/exynos/exynos_drm_plane.c | 115 + >> drivers/gpu/drm/exynos/exynos_drm_plane.h | 11 -- >> drivers/gpu/drm/exynos/exynos_drm_vidi.c| 6 +- >> drivers/gpu/drm/exynos/exynos_hdmi.c| 10 +- >> 15 files changed, 178 insertions(+), 265 deletions(-) >> > > Gustavo >
[ANNOUNCE] libdrm 2.4.61
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Release to fix regression in nouveau in 2.4.60,
but brings lots of android changes and other fixes.
Ben Skeggs (2):
nouveau: restore check that avoids multiple user bos per kernel bo
configure.ac: bump version to 2.4.61 for release
Chih-Wei Huang (3):
android: simplify the including rule of subdirs
android: get rid of LIBDRM_TOP
android: remove unnecessary TARGET_OUT_HEADERS variable
Chris Wilson (2):
mode: Retrieve only the current information for a Connector
intel: Delay testing for userptr until first use
Connor Behan (1):
xf86drm: Fix ioctl struct clearing in drmAgpEnable
Damien Lespiau (3):
RELEASING: Fix releasing instructions to match the latest release.sh
RELEASING: Fix the step numbering
RELEASING: Fix annouce typo
Daniel Kurtz (3):
proptest: install it with --enable-install-test-programs
tests: add rockchip to modetest, kmstest, vbltest and proptest
xf86drmMode.h: inline -> __inline for use with gcc -std=c89 -pedantic
Emil Velikov (39):
android: correcly set LOCAL_EXPORT_C_INCLUDE_DIRS
android: simplify LOCAL_C_INCLUDES
android: remove ${srcdir} from the includes
android: remove LOCAL_COPY_HEADERS* variables
android: add the missing tag "optional" to libkms
autotools: remove ${srcdir} from the includes
android: remove explicit include to libpciaccess
tests/hash: extract test out of xf86drmHash.c
tests/hash: misc compilation fixes
tests/hash: style fixes
tests/hash: return non-zero on failure
tests/random: extract test out of xf86drmRandom.c
tests/random: return non-zero on test failure
drm: replace HASH_DEBUG with DEBUG
drm: use correct printf modifiers
configure.ac: split -fvisibility and __attribute__((visibility)) checks
radeon: move bof.[ch] out of libdrm_radeon
radeon: add symbols test
freedreno: annotate the private symbols
freedreno: add symbols test
intel: remove the drm_mm* symbol workarounds
intel: remove unused mmFindBlock
intel: annotate the private symbols
intel: add symbols test
nouveau: annotate the private symbols
nouveau: add symbols test
libkms: annotate private symbols
libkms: add symbols test
exynos: add symbols test
omap: add symbols test
tegra: add symbols test
drm: rename libdrm{,_macros}.h
drm: remove no longer needed VISIBILITY_CFLAGS
drm: remove drm_public macro
configure: request/set the compiler in C99 mode
drm: use c99 __func__ over __FUNCTION__
man: rework the Makefile.am
android: set the HAVE_VISIBILITY define
freedreno: link against CLOCK_LIB
Greg Hackmann (1):
Add missing includes
Jan Vesely (5):
Fix unused function warnings
Remove drmSetDebugMsgFunction and related infrastructure
tests/exynos: Fix missing static keyword
drmSL: Fix neighbor lookup
tests/drmsl: Extract tests out of xf86drmSL.c
Joonyoung Shim (6):
modetest: fix Segmentation fault
modetest: make use of drmModeRmFB
modetest: fix the error path handling
modetest: clear buffer and framebuffer for planes
modetest: destroy the cursor bo
modetest: fix the arguments of the MAKE_RGB_INFO define
Neil Roberts (1):
intel: Merge latest i915_drm.h
Rob Clark (2):
modeprint: add missing encoder/connector type names
modetest: fix allocation for yuv420/yvu420
Tobias Jakobi (1):
modetest: initialize handles/pitches in set_plane()
Tvrtko Ursulin (1):
intel: Leak the userptr test bo
git tag: libdrm-2.4.61
http://dri.freedesktop.org/libdrm/libdrm-2.4.61.tar.bz2
MD5: c3d31138d63e0edde3f5b93cd88fb93a libdrm-2.4.61.tar.bz2
SHA1: fce70371540af0490541b05d96c6b6b43f1fab80 libdrm-2.4.61.tar.bz2
SHA256: 8b549092c8961a393a7e1d9a1bccddcea8e2af67c0d7d7c67babb9fc3b47699c
libdrm-2.4.61.tar.bz2
PGP: http://dri.freedesktop.org/libdrm/libdrm-2.4.61.tar.bz2.sig
http://dri.freedesktop.org/libdrm/libdrm-2.4.61.tar.gz
MD5: a77a37370f6f8e17f5c4fe40b1b98782 libdrm-2.4.61.tar.gz
SHA1: 25b2225197c714549f95fdde6ba24406645549bd libdrm-2.4.61.tar.gz
SHA256: cfc768c22bd2bf6a8ee20c97ae3f85733e6cad6bc28c023f163312604204fcd6
libdrm-2.4.61.tar.gz
PGP: http://dri.freedesktop.org/libdrm/libdrm-2.4.61.tar.gz.sig
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBAgAGBQJVSsKcAAoJEMUGCSafkIbkbbIP/3a8bREUNcgRD0nI2HM0G8dZ
7KYnVV4cXUCQGnIoD3GA47PIsBOlXGwC5y7e1fRJby9fI5em3RYa+j+dqWm7CsHW
Fl7Kk300miJ45tkHH8sVGzrGqnJ1Dj4sm8YXmwQ6Dzo8f504DIMjwGBqxrBldNpr
UO/lXA0lK9gg764Me17W3vb5R5vfNiCQmzl3OOUhZb8aMwXXt8nv0EivZ3QJGhn8
FrdF1zgRH6A/h901AkHKAEglVGNY5AaHee3f0H9i0usedt0LOAp+2ilu0VhIjbin
s3bov2ThCUBgz3HBgmN9/qjZJ00SsPYOqnrPt1sfaqS3gPBVsz4mJYhNM27ZHXfn
kLBv9DWIa2sQO5r+Cl5OGJX9yXqQUlOP4C+k9VYTO8S5PFqnvoIsQ9caa61Dfzdm
WYaGrODR36JehSo5WQYGSs6P5xlNjZtxL5sBt8kIH8b8yehZV8dTVibD7utO
[PATCH RFC v2 10/13] sound/core: add DRM ELD helper
On Wed, May 06, 2015 at 08:02:52PM +0300, Anssi Hannula wrote: > 05.04.2015, 20:26, Russell King - ARM Linux kirjoitti: > > On Sun, Apr 05, 2015 at 06:46:13PM +0200, Takashi Iwai wrote: > >> > >> One another question: don't we need to deal with the sample bits in > >> sad[2]? > > > > It should, but I'm very wary about doing that without seeing more > > examples of real SADs. Right now, all my examples only support > > one SAD with either 2 channel or 6 channel audio at the standard > > (basic) 32, 44.1 and 48kHz rates. > > > > The HDMI / CEA specs are very loose in their wording about the > > short audio descriptors. I've no idea whether a sink can provide > > (for example) descriptors such as: > > > > LPCM, 6 channel 32, 44.1, 48kHz > > LPCM, 2 channel, 32, 44.1, 48, 96, 192kHz > > > > or whether have to describe that as a single descriptor. I only > > have two TVs to test with here. > > For the record, yes, multiple LPCM SADs are relatively common, and I > think I've seen some that offered more rates on a stereo SAD than on a > multichannel SAD (like in your example). Okay, so we "think" we've seen it in the wild... > > What I'm concerned about is that when the ALSA parameter refining > > starts, we start with (eg) 2-8 channels, 32-192kHz. Given that, > > if we invoke the channel restriction before the rate restriction, > > we would end up limiting to 2 channel at 32-192kHz. If we apply > > the restrictions in the opposite order, we'd restrict to 6 > > channel, 32-48kHz. Neither are obviously correct in this > > circumstance, and I don't really see a way to solve it given my > > understanding of the way ALSA's parameter refinement works. > > > > I suspect this is why most HDMI drivers are implemented such that > > they take the maximum capabilities over all SADs, which would end > > up restricting audio in the above case to: up to 6 channels, at > > 32, 44.1, 48, 96 and 192kHz, even though 6 channel @ 192kHz isn't > > hasn't been indicated as supported. > > > > Most of this is speculation though, based off what is in the > > documentation. As I say, I don't have enough real-world examples > > to get a feel for what manufacturers _actually_ do to give a hint > > as to how the documentation should be interpreted. ... so this is probably less than speculation. So, ALSA gurus, how do we handle this? How do we arrange the parameter resolution such that ALSA can permit _either_ 2 channels at 192kHz or 6 channels at 48kHz, but not 6 channels at 192kHz? Right now, I don't see how that's possible. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.
[Bug 90360] [RV710/M92] Soft lock caused by UVD (linux 4.0.1)
https://bugs.freedesktop.org/show_bug.cgi?id=90360 --- Comment #3 from Mohammad AlSaleh --- Looking closer at what's going on. This could be codec related. I just noticed that the bug is triggered with MPEG2(the particular file is 1080i) but not with H264. And the bug goes back to at least 3.18.6. -- 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/20150507/0ab7e674/attachment-0001.html>
[RFT PATCH v2 0/3] drm/exynos: Fix build breakage on !DRM_EXYNOS_FIMD
Hello Krzysztof,
On 05/07/2015 02:04 AM, Krzysztof Kozlowski wrote:
> From: Krzysztof Kozlowski
>
> Hi,
>
> This is second try to fix the build breakage introduced in 1c363c7cccf6
> ("drm/exynos: Enable DP clock to fix display on Exynos5250 and other").
>
> The fix is not trivial so I am kindly asking for testing on Chromebook
> and other DP-enabled boards (I don't have Chromebook right now).
>
For all the series:
Reviewed-by: Javier Martinez Canillas
> Tested on Exynos4412 Trats2 board.
>
On Exynos5250 Snow, Exynos5420 Peach Pit and Exynos5800 Peach Pi Chromebooks:
Tested-by: Javier Martinez Canillas
> Best regards,
> Krzysztof
>
Best regards,
Javier
[PATCH 6/7] drm: Add reference counting to blob properties
On Mon, Apr 20, 2015 at 07:22:55PM +0100, Daniel Stone wrote:
> Reference-count drm_property_blob objects, changing the API to
> ref/unref.
>
> Signed-off-by: Daniel Stone
Merged up to this on (except patch 2) to topic/drm-misc.
Thanks, Daniel
> ---
> drivers/gpu/drm/drm_crtc.c | 164
> +
> include/drm/drm_crtc.h | 17 ++---
> 2 files changed, 159 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 9947078..03245fb 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -352,7 +352,9 @@ static struct drm_mode_object *_object_find(struct
> drm_device *dev,
> if (obj && obj->id != id)
> obj = NULL;
> /* don't leak out unref'd fb's */
> - if (obj && (obj->type == DRM_MODE_OBJECT_FB))
> + if (obj &&
> + (obj->type == DRM_MODE_OBJECT_FB ||
> + obj->type == DRM_MODE_OBJECT_BLOB))
> obj = NULL;
> mutex_unlock(&dev->mode_config.idr_mutex);
>
> @@ -377,7 +379,7 @@ struct drm_mode_object *drm_mode_object_find(struct
> drm_device *dev,
>
> /* Framebuffers are reference counted and need their own lookup
>* function.*/
> - WARN_ON(type == DRM_MODE_OBJECT_FB);
> + WARN_ON(type == DRM_MODE_OBJECT_FB || type == DRM_MODE_OBJECT_BLOB);
> obj = _object_find(dev, id, type);
> return obj;
> }
> @@ -4200,7 +4202,7 @@ done:
> return ret;
> }
>
> -static struct drm_property_blob *
> +struct drm_property_blob *
> drm_property_create_blob(struct drm_device *dev, size_t length,
>const void *data)
> {
> @@ -4215,6 +4217,7 @@ drm_property_create_blob(struct drm_device *dev, size_t
> length,
> return NULL;
>
> blob->length = length;
> + blob->dev = dev;
>
> memcpy(blob->data, data, length);
>
> @@ -4227,25 +4230,148 @@ drm_property_create_blob(struct drm_device *dev,
> size_t length,
> return NULL;
> }
>
> + kref_init(&blob->refcount);
> +
> list_add_tail(&blob->head, &dev->mode_config.property_blob_list);
>
> mutex_unlock(&dev->mode_config.blob_lock);
>
> return blob;
> }
> +EXPORT_SYMBOL(drm_property_create_blob);
>
> -static void drm_property_destroy_blob(struct drm_device *dev,
> -struct drm_property_blob *blob)
> +/**
> + * drm_property_free_blob - Blob property destructor
> + *
> + * Internal free function for blob properties; must not be used directly.
> + *
> + * @param kref Reference
> + */
> +static void drm_property_free_blob(struct kref *kref)
> {
> - mutex_lock(&dev->mode_config.blob_lock);
> - drm_mode_object_put(dev, &blob->base);
> + struct drm_property_blob *blob =
> + container_of(kref, struct drm_property_blob, refcount);
> +
> + WARN_ON(!mutex_is_locked(&blob->dev->mode_config.blob_lock));
> +
> list_del(&blob->head);
> - mutex_unlock(&dev->mode_config.blob_lock);
> + drm_mode_object_put(blob->dev, &blob->base);
>
> kfree(blob);
> }
>
> /**
> + * drm_property_unreference_blob - Unreference a blob property
> + *
> + * Drop a reference on a blob property. May free the object.
> + *
> + * @param dev Device the blob was created on
> + * @param blob Pointer to blob property
> + */
> +void drm_property_unreference_blob(struct drm_property_blob *blob)
> +{
> + struct drm_device *dev;
> +
> + if (!blob)
> + return;
> +
> + dev = blob->dev;
> +
> + DRM_DEBUG("%p: blob ID: %d (%d)\n", blob, blob->base.id,
> atomic_read(&blob->refcount.refcount));
> +
> + if (kref_put_mutex(&blob->refcount, drm_property_free_blob,
> +&dev->mode_config.blob_lock))
> + mutex_unlock(&blob->dev->mode_config.blob_lock);
> + else
> + might_lock(&dev->mode_config.blob_lock);
> +
> +}
> +EXPORT_SYMBOL(drm_property_unreference_blob);
> +
> +/**
> + * drm_property_unreference_blob_locked - Unreference a blob property with
> blob_lock held
> + *
> + * Drop a reference on a blob property. May free the object. This must be
> + * called with blob_lock held.
> + *
> + * @param dev Device the blob was created on
> + * @param blob Pointer to blob property
> + */
> +static void drm_property_unreference_blob_locked(struct drm_property_blob
> *blob)
> +{
> + if (!blob)
> + return;
> +
> + DRM_DEBUG("%p: blob ID: %d (%d)\n", blob, blob->base.id,
> atomic_read(&blob->refcount.refcount));
> +
> + kref_put(&blob->refcount, drm_property_free_blob);
> +}
> +
> +/**
> + * drm_property_reference_blob - Take a reference on an existing property
> + *
> + * Take a new reference on an existing blob property.
> + *
> + * @param blob Pointer to blob property
> + */
> +struct drm_property_blob *drm_property_reference_blob(struct
> drm_property_blob *blob)
> +{
> + DRM_DEBUG("%p: blob ID: %d (%d)\n", blob, blo
[PATCH 2/7] drm/atomic: Early-exit from CRTC dup state
On Mon, Apr 20, 2015 at 07:22:51PM +0100, Daniel Stone wrote:
> Just change an if (success) branch to if (fail) return;
>
> Signed-off-by: Daniel Stone
I dropped this one since the code already changed a bit.
-Daniel
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index d536817..60eb505 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1983,12 +1983,13 @@ drm_atomic_helper_crtc_duplicate_state(struct
> drm_crtc *crtc)
>
> state = kmemdup(crtc->state, sizeof(*crtc->state), GFP_KERNEL);
>
> - if (state) {
> - state->mode_changed = false;
> - state->active_changed = false;
> - state->planes_changed = false;
> - state->event = NULL;
> - }
> + if (!state)
> + return NULL;
> +
> + state->mode_changed = false;
> + state->active_changed = false;
> + state->planes_changed = false;
> + state->event = NULL;
>
> return state;
> }
> --
> 2.3.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Bug 90340] RADEON "PITCAIRN" displayport output breaks when monitor turned off and on
https://bugs.freedesktop.org/show_bug.cgi?id=90340 --- Comment #2 from smoki --- Might be some kind of setup issue as Xorg.0.log shows: [14.853] (EE) RADEON(0): eglInitialize() failed [14.853] (EE) RADEON(0): glamor detected, failed to initialize EGL. and [14.437] (II) NVIDIA GLX Module 340.65 Tue Dec 2 09:10:06 PST 2014 ... [15.071] (EE) Failed to initialize GLX extension (Compatible NVIDIA X driver not found) -- 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/20150507/3fa3c371/attachment.html>
[PATCH] drm/nouveau/core: deinline nv_mask()
Function compiles to 89 bytes of machine code.
466 callsites with this .config:
http://busybox.net/~vda/kernel_config
Size reduction:
text data bss dec hex filename
82432426 22255384 20627456 125315266 77828c2 vmlinux.before
82426986 22255416 20627456 125309858 77813a2 vmlinux
Signed-off-by: Denys Vlasenko
CC: Stefan Huehner
CC: Ben Skeggs
CC: David Airlie
CC: dri-devel at lists.freedesktop.org
CC: linux-kernel at vger.kernel.org
---
drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h | 9 ++---
drivers/gpu/drm/nouveau/nvkm/core/subdev.c | 8
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h
b/drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h
index 6fdc391..261b7ff 100644
--- a/drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h
+++ b/drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h
@@ -109,11 +109,6 @@ nv_wr32(void *obj, u32 addr, u32 data)
iowrite32_native(data, subdev->mmio + addr);
}
-static inline u32
-nv_mask(void *obj, u32 addr, u32 mask, u32 data)
-{
- u32 temp = nv_rd32(obj, addr);
- nv_wr32(obj, addr, (temp & ~mask) | data);
- return temp;
-}
+u32
+nv_mask(void *obj, u32 addr, u32 mask, u32 data);
#endif
diff --git a/drivers/gpu/drm/nouveau/nvkm/core/subdev.c
b/drivers/gpu/drm/nouveau/nvkm/core/subdev.c
index c5fb3a79..88331ea 100644
--- a/drivers/gpu/drm/nouveau/nvkm/core/subdev.c
+++ b/drivers/gpu/drm/nouveau/nvkm/core/subdev.c
@@ -25,6 +25,14 @@
#include
#include
+u32
+nv_mask(void *obj, u32 addr, u32 mask, u32 data)
+{
+ u32 temp = nv_rd32(obj, addr);
+ nv_wr32(obj, addr, (temp & ~mask) | data);
+ return temp;
+}
+
struct nvkm_subdev *
nvkm_subdev(void *obj, int idx)
{
--
1.8.1.4
[PATCH 0/7] User-created blob properties
On Mon, Apr 20, 2015 at 07:22:49PM +0100, Daniel Stone wrote: > Hi, > This is the spritual successor to the modes-as-blob-properties patchset. > > There are some fairly drastic differences though, namely: > - the referenced object in this case is the blob property - being just > a dumb chunk of data - rather than attempting to refcount modes; > meaning that ... > - userspace doesn't see blob mode IDs from the connector list, only > from the current mode, so it really needs to create the mdoes again > from the drm_mode_modeinfo it gets > - the mode-constness series has been split out and will be sent > separately > > Actually exposing the mode property does largely seem to work, but > need to fix i915 to not copy CRTC states by value before it does. > > This series still retains the concept of a type within the create blob > ioctl, on the grounds that otherwise we could allow userspace to create > unbounded allocations in the kernel with no attribution. Other than > matching size, the type has no meaning per se. Yeah I'm a bit late, but not sure whether trying to restrict the size is all that useful really. Userspace can still just create a bazillion of them and starve the kernel of memory. And as long as we use kmalloc there'll be a natural limit to how big a blob can be. I'm bringing this up since if we go with encoding size limits we'll need to add a new type of blob for each use, and with gamma tables, csc matrices and other stuff there will be lots of them. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Bug 90360] [RV710/M92] Soft lock caused by UVD (linux 4.0.1)
https://bugs.freedesktop.org/show_bug.cgi?id=90360 --- Comment #2 from Mohammad AlSaleh --- Created attachment 115621 --> https://bugs.freedesktop.org/attachment.cgi?id=115621&action=edit dmesg output -- 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/20150507/607ef5a4/attachment.html>
[Bug 90360] [RV710/M92] Soft lock caused by UVD (linux 4.0.1)
https://bugs.freedesktop.org/show_bug.cgi?id=90360 --- Comment #1 from Mohammad AlSaleh --- Hello. Card:Mobility Radeon HD 4570 I set those at start-up: echo performance > /sys/class/drm/card0/device/power_dpm_state echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level When trying to use VDPAU/UVD (e.g. with ffmpeg). The GPU soft-locks. X can be killed remotely. But the GPU is not reset properly. GL and VDPAU don't work after I start X again. This bug was net present in 3.18.2. dmesg output attached. -- 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/20150507/d9464db5/attachment-0001.html>
[Bug 90355] DRI_PRIME+radeon+steam=problems + crash
https://bugs.freedesktop.org/show_bug.cgi?id=90355 --- Comment #1 from higuita at gmx.net --- updated to kernel 4.0.1, same problem Installed oibaf (https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers) PPA, so i'm using mesa 10.6~git1505070730.55b66d and it still lockup the machine... but seems a little more stable, must check if the oops is still the same -- 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/20150507/23fc8cf0/attachment.html>
[PATCH 0/7] User-created blob properties
Hi, On Thursday, May 7, 2015, Daniel Vetter wrote: > On Mon, Apr 20, 2015 at 07:22:49PM +0100, Daniel Stone wrote: > > This is the spritual successor to the modes-as-blob-properties patchset. > > > > There are some fairly drastic differences though, namely: > > - the referenced object in this case is the blob property - being just > > a dumb chunk of data - rather than attempting to refcount modes; > > meaning that ... > > - userspace doesn't see blob mode IDs from the connector list, only > > from the current mode, so it really needs to create the mdoes again > > from the drm_mode_modeinfo it gets > > - the mode-constness series has been split out and will be sent > > separately > > > > Actually exposing the mode property does largely seem to work, but > > need to fix i915 to not copy CRTC states by value before it does. > > > > This series still retains the concept of a type within the create blob > > ioctl, on the grounds that otherwise we could allow userspace to create > > unbounded allocations in the kernel with no attribution. Other than > > matching size, the type has no meaning per se. > > Yeah I'm a bit late, but not sure whether trying to restrict the size is > all that useful really. Userspace can still just create a bazillion of > them and starve the kernel of memory. And as long as we use kmalloc > there'll be a natural limit to how big a blob can be. > > I'm bringing this up since if we go with encoding size limits we'll need > to add a new type of blob for each use, and with gamma tables, csc > matrices and other stuff there will be lots of them. > Fair enough. My thinking is that it would be easier to catch a userspace in the act of gradually starving memory with a billion ioctls than all in one big go, but see the argument. Will drop that (nearly resolving Maarten's -E2BIG correction), and also dig out the single-alloc patch I had earlier, but must've lost during rebase. Cheers, Daniel -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150507/e42b0404/attachment.html>
[Bug 90360] [RV710/M92] Soft lock caused by UVD (linux 4.0.1)
https://bugs.freedesktop.org/show_bug.cgi?id=90360 Mohammad AlSaleh changed: What|Removed |Added Summary|[] |[RV710/M92] Soft lock ||caused by UVD (linux 4.0.1) -- 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/20150507/ebc46e67/attachment.html>
[PATCH] dma-buf: add ref counting for module as exporter
On Thu, May 07, 2015 at 01:00:52PM +0530, Sumit Semwal wrote:
> Add reference counting on a kernel module that exports dma-buf and
> implements its operations. This prevents the module from being unloaded
> while DMABUF file is in use.
>
> The original patch [1] was submitted by Tomasz, but he's since shifted
> jobs and a ping didn't elicit any response.
>
> [tomasz: Original author]
> Signed-off-by: Tomasz Stanislawski
> Acked-by: Daniel Vetter
> [sumits: updated & rebased as per review comments]
> Signed-off-by: Sumit Semwal
>
> [1]: https://lkml.org/lkml/2012/8/8/163
> ---
> drivers/dma-buf/dma-buf.c | 9 -
> drivers/gpu/drm/armada/armada_gem.c| 1 +
> drivers/gpu/drm/drm_prime.c| 1 +
> drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 1 +
> drivers/gpu/drm/i915/i915_gem_dmabuf.c | 1 +
> drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 1 +
> drivers/gpu/drm/tegra/gem.c| 1 +
> drivers/gpu/drm/udl/udl_dmabuf.c | 1 +
> drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 1 +
> drivers/media/v4l2-core/videobuf2-dma-contig.c | 1 +
> drivers/media/v4l2-core/videobuf2-dma-sg.c | 1 +
> drivers/media/v4l2-core/videobuf2-vmalloc.c| 1 +
> drivers/staging/android/ion/ion.c | 1 +
> include/linux/dma-buf.h| 2 ++
> 14 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index c5a9138a6a8d..9583eac0238f 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -64,6 +65,7 @@ static int dma_buf_release(struct inode *inode, struct file
> *file)
> BUG_ON(dmabuf->cb_shared.active || dmabuf->cb_excl.active);
>
> dmabuf->ops->release(dmabuf);
> + module_put(dmabuf->ops->owner);
>
> mutex_lock(&db_list.lock);
> list_del(&dmabuf->list_node);
> @@ -302,9 +304,14 @@ struct dma_buf *dma_buf_export(const struct
> dma_buf_export_info *exp_info)
> return ERR_PTR(-EINVAL);
> }
>
> + if (!try_module_get(exp_info->ops->owner))
> + return ERR_PTR(-ENOENT);
> +
> dmabuf = kzalloc(alloc_size, GFP_KERNEL);
> - if (dmabuf == NULL)
> + if (!dmabuf) {
> + module_put(exp_info->ops->owner);
> return ERR_PTR(-ENOMEM);
> + }
>
> dmabuf->priv = exp_info->priv;
> dmabuf->ops = exp_info->ops;
> diff --git a/drivers/gpu/drm/armada/armada_gem.c
> b/drivers/gpu/drm/armada/armada_gem.c
> index 580e10acaa3a..d2c5fc1269b7 100644
> --- a/drivers/gpu/drm/armada/armada_gem.c
> +++ b/drivers/gpu/drm/armada/armada_gem.c
> @@ -524,6 +524,7 @@ armada_gem_dmabuf_mmap(struct dma_buf *buf, struct
> vm_area_struct *vma)
> }
>
> static const struct dma_buf_ops armada_gem_prime_dmabuf_ops = {
> + .owner = THIS_MODULE,
> .map_dma_buf= armada_gem_prime_map_dma_buf,
> .unmap_dma_buf = armada_gem_prime_unmap_dma_buf,
> .release= drm_gem_dmabuf_release,
The "easier" way to do this is change the registration function to add
the module owner automatically, which keeps you from having to modify
all of the individual drivers. Look at how pci and usb do this for
their driver registration functions. That should result in a much
smaller patch, that always works properly for everyone (there's no way
for driver to get it wrong.)
thanks,
greg k-h
[Bug 85801] [Mobility Radeon HD 4570] Enabling HDMI monitor fails with kernel versions 3.17/3.16
https://bugs.freedesktop.org/show_bug.cgi?id=85801 Mohammad AlSaleh changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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/20150507/9d75082e/attachment.html>
[Bug 70654] [DPM] Mobility 4570: power_dpm_force_performance_level is reset to auto when UVD is used
https://bugs.freedesktop.org/show_bug.cgi?id=70654 Mohammad AlSaleh changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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/20150507/1ed79946/attachment.html>
[PATCH 7/7] drm/mode: Add user blob-creation ioctl
Op 20-04-15 om 20:22 schreef Daniel Stone:
> Add an ioctl which allows users to create blob properties from supplied
> data. Currently this only supports modes, creating a drm_display_mode from
> the userspace drm_mode_modeinfo.
>
> Signed-off-by: Daniel Stone
> ---
>
> +int drm_mode_createblob_ioctl(struct drm_device *dev,
> + void *data, struct drm_file *file_priv)
> +{
> + struct drm_mode_create_blob *out_resp = data;
> + struct drm_property_blob *blob;
> + void *blob_data;
> + int ret = 0;
> + void __user *blob_ptr;
> +
> + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> + return -EINVAL;
> +
> + switch (out_resp->type) {
> + case DRM_MODE_BLOB_TYPE_MODE: {
> + if (out_resp->length != sizeof(struct drm_mode_modeinfo)) {
> + ret = -E2BIG;to length
You want -EINVAL here, -E2BIG means "argument list too long".
> + goto out_unlocked;
> + }
> + break;
> + }
> + default:
> + ret = -EINVAL;
> + goto out_unlocked;
> + }
> +
> + blob_data = kzalloc(out_resp->length, GFP_USER);
> + if (!blob_data) {
> + ret = -ENOMEM;
> + goto out_unlocked;
> + }
> +
> + blob_ptr = (void __user *)(unsigned long)out_resp->data;
> + if (copy_from_user(blob_data, blob_ptr, out_resp->length)) {
> + ret = -EFAULT;
> + goto out_data;
> + }
> +
> + blob = drm_property_create_blob(dev, out_resp->length, blob_data);
> + if (!blob) {
> + ret = -EINVAL;
drm_property_create_blob can fail from -ENOMEM or -EINVAL here, so correctly
return the error from drm_property_create_blob?
You're also doing a double allocation, one for blob_ptr and the other for blob.
It might be better to do a single allocation of the blob and copy
the data to blob->data directly.
For the whole series if this patch is fixed up:
Reviewed-by: Maarten Lankhorst
[PULL] drm-intel-next
Hi Dave, drm-intel-next-2015-04-23: - dither support for ns2501 dvo (Thomas Richter) - some polish for the gtt code and fixes to finally enable the cmd parser on hsw - first pile of bxt stage 1 enabling (too many different people to list ...) - more psr fixes from Rodrigo - skl rotation support from Chandra - more atomic work from Ander and Matt - pile of cleanups and micro-ops for execlist from Chris drm-intel-next-2015-04-10: - cdclk handling cleanup and fixes from Ville - more prep patches for olr removal from John Harrison - gmbus pin naming rework from Jani (prep for bxt) - remove ->new_config from Ander (more atomic conversion work) - rps (boost) tuning and unification with byt/bsw from Chris - cmd parser batch bool tuning from Chris - gen8 dynamic pte allocation (Michel Thierry, based on work from Ben Widawsky) - execlist tuning (not yet all of it) from Chris - add drm_plane_from_index (Chandra) - various small things all over Plus a few patches Jani collected while I was on vacation. Cheers, Daniel The following changes since commit 1d8ac08d498d579aae36221a80b4b724b2f52f39: Merge tag 'v4.0-rc7' into drm-next (2015-04-09 07:48:27 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2015-04-23-fixed for you to fetch changes up to 93a96c6f049d047bc196890fc4284eff15b3770f: Merge commit '75d04a3773ecee617847de963ae4195d6aa74c28' into drm-intel-next-queued (2015-05-04 09:25:12 +0200) A.Sunil Kamath (1): drm/i915/bxt: Implement enable/disable for Display C9 state Ander Conselvan de Oliveira (10): drm/i915: Check lane sharing between pipes B & C using atomic state drm/i915: Set best_encoder field of connector_state also when disabling drm/i915: Don't use staged config for VLV cdclk calculations drm/i915: Don't use intel_crtc->new_config in pll calculation code drm/i915: Remove intel_crtc->new_config drm/i915: Don't use staged config in check_digital_port_conflicts() drm/i915: Don't use staged config in check_encoder_cloning() drm/i915: Don't use staged config in intel_mst_pre_enable_dp() drm/i915: Remove stale comment from __intel_set_mode() drm/i915: Allocate connector state together with the connectors Arun Siluvery (1): drm/i915: Do not set L3-LLC Coherency bit in ctx descriptor Ben Widawsky (3): drm/i915/bxt: add GEN8_HDCUNIT_CLOCK_GATE_DISABLE_HDCREQ workaround drm/i915/bxt: add WaDisableMaskBasedCammingInRCC workaround drm/i915/skl: add WaDisableMaskBasedCammingInRCC workaround Chandra Konduru (12): drm: Adding drm helper function drm_plane_from_index(). drm/i915: Register definitions for skylake scalers drm/i915: skylake scaler structure definitions drm/i915: Initialize plane colorkey to NONE drm/i915: Initialize skylake scalers drm/i915: Keep sprite plane src rect in 16.16 format drm/i915: Dump scaler_state too as part of dumping crtc_state drm/i915: Preserve scaler state when clearing crtc_state drm/i915: setup scalers for crtc_compute_config drm/i915: Ensure setting up scalers into staged crtc_state drm/i915: copy staged scaler state from drm state to crtc->config. drm/i915: skylake panel fitting using shared scalers Chris Wilson (35): drm/i915: Add i915_gem_request_unreference__unlocked drm/i915: Make debugfs/i915_gem_request more friendly drm/i915: Allow disabling the destination colorkey for overlay drm/i915: Cache last obj->pages location for i915_gem_object_get_page() drm/i915: Fix the flip synchronisation to consider mmioflips drm/i915: Agressive downclocking on Baytrail drm/i915: Fix computation of last_adjustment for RPS autotuning drm/i915: Boost GPU frequency if we detect outstanding pageflips drm/i915: Deminish contribution of wait-boosting from clients drm/i915: Re-enable RPS wait-boosting for all engines drm/i915: Split i915_gem_batch_pool into its own header drm/i915: Tidy batch pool logic drm/i915: Split the batch pool by engine drm/i915: Free batch pool when idle drm/i915: Split batch pool into size buckets drm/i915: Include active flag when describing objects in debugfs drm/i915: Suppress empty lines from debugfs/i915_gem_objects drm/i915: Record ring->start address in error state drm/i915: Use simpler form of spin_lock_irq(execlist_lock) drm/i915: Use the global runtime-pm wakelock for a busy GPU for execlists drm/i915: Remove vestigal DRI1 ring quiescing code drm/i915: Use a separate slab for requests drm/i915: Use a separate slab for vmas drm/i915: Reduce locking in execlist command submission drm/i915: Reduce locking in gen8 IRQ handler drm/i915: Tidy gen8 IRQ handler drm/i915: Prefer to check for idleness in worker ra
[PATCH v2 1/2] clk: change clk_ops' ->round_rate() prototype
Hi Stephen, On Wed, 6 May 2015 23:39:53 -0700 Stephen Boyd wrote: > On 04/30, Boris Brezillon wrote: > > Clock rates are stored in an unsigned long field, but ->round_rate() > > (which returns a rounded rate from a requested one) returns a long > > value (errors are reported using negative error codes), which can lead > > to long overflow if the clock rate exceed 2Ghz. > > > > Change ->round_rate() prototype to return 0 or an error code, and pass the > > requested rate as a pointer so that it can be adjusted depending on > > hardware capabilities. > > > > Signed-off-by: Boris Brezillon > > Tested-by: Heiko Stuebner > > Tested-by: Mikko Perttunen > > Reviewed-by: Heiko Stuebner > > This patch is fairly invasive, and it probably doesn't even > matter for most of these clock providers to be able to round a > rate above 2GHz. Fair enough. > I've been trying to remove the .round_rate op > from the framework by encouraging new features via the > .determine_rate op. Oh, I wasn't aware of that (BTW, that's a good thing). Maybe this should be clearly stated (both in the struct clk_ops kerneldoc header and in Documentation/clk.txt). > Sadly, we still have to do a flag day and > change all the .determine_rate ops when we want to add things. Yes, but the number of clk drivers implementing ->determine_rate() is still quite limited compared to those implementing ->round_rate(). > > What if we changed determine_rate ops to take a struct > clk_determine_info (or some better named structure) instead of > the current list of arguments that it currently takes? Then when > we want to make these sorts of framework wide changes we can just > throw a new member into that structure and be done. I really like this idea, especially since I was wondering if we could pass other 'clk rate requirements' like the rounding policy (down, closest, up), or the maximum clk inaccuracy. > > It doesn't solve the unsigned long to int return value problem > though. We can solve that by gradually introducing a new op and > handling another case in the rounding path. If we can come up > with some good name for that new op like .decide_rate or > something then it makes things nicer in the long run. I like the > name .determine_rate though :/ Why not changing the ->determine_rate() prototype. As said above, the number of clk drivers implementing this function is still quite limited, and I guess we can have an ack for all of them. > > The benefit of all this is that we don't have to worry about > finding the random clk providers that get added into other > subsystems and fixing them up. If drivers actually care about > this problem then they'll be fixed to use the proper op. FYI, > last time we updated the function signature of .determine_rate we > broke a couple drivers along the way. > Hm, IMHO, adding a new op is not a good thing. I agree that it eases the transition, but ITOH you'll have to live with old/deprecated ops in your clk_ops structure with people introducing new drivers still using the old ops (see the number of clk drivers implementing ->round_rate() instead of ->determine_rate()). Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[RFT PATCH v2 3/3] drm/exynos: Consolidate return statements in fimd_bind()
From: Krzysztof Kozlowski Simplify the code and remove superfluous return statement. Just return the result of fimd_iommu_attach_devices(). Signed-off-by: Krzysztof Kozlowski --- Changes since v1: New patch. --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 5c1a148525f8..d704f2ba7179 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c @@ -1042,12 +1042,7 @@ static int fimd_bind(struct device *dev, struct device *master, void *data) if (ctx->display) exynos_drm_create_enc_conn(drm_dev, ctx->display); - ret = fimd_iommu_attach_devices(ctx, drm_dev); - if (ret) - return ret; - - return 0; - + return fimd_iommu_attach_devices(ctx, drm_dev); } static void fimd_unbind(struct device *dev, struct device *master, -- 2.1.4
[RFT PATCH v2 2/3] drm/exynos: Constify exynos_drm_crtc_ops
From: Krzysztof Kozlowski
The Exynos DRM code does not modify the ops provided by CRTC driver in
exynos_drm_crtc_create() call.
Signed-off-by: Krzysztof Kozlowski
---
Changes since v1:
New patch.
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 2 +-
drivers/gpu/drm/exynos/exynos_drm_drv.h| 2 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 +-
drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 1f7e33f59de6..3d00df76220d 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -710,7 +710,7 @@ static void decon_dpms(struct exynos_drm_crtc *crtc, int
mode)
}
}
-static struct exynos_drm_crtc_ops decon_crtc_ops = {
+static const struct exynos_drm_crtc_ops decon_crtc_ops = {
.dpms = decon_dpms,
.mode_fixup = decon_mode_fixup,
.commit = decon_commit,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index eb49195cec5c..93f873f11f64 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -241,7 +241,7 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct
drm_device *drm_dev,
struct drm_plane *plane,
int pipe,
enum exynos_drm_output_type type,
- struct exynos_drm_crtc_ops *ops,
+ const struct exynos_drm_crtc_ops
*ops,
void *ctx)
{
struct exynos_drm_crtc *exynos_crtc;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index 0ecd8fc45cff..ed0994b3cb47 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -21,7 +21,7 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct
drm_device *drm_dev,
struct drm_plane *plane,
int pipe,
enum exynos_drm_output_type type,
- struct exynos_drm_crtc_ops *ops,
+ const struct exynos_drm_crtc_ops
*ops,
void *context);
int exynos_drm_crtc_enable_vblank(struct drm_device *dev, int pipe);
void exynos_drm_crtc_disable_vblank(struct drm_device *dev, int pipe);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 44f128a03aea..0e951226ca06 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -226,7 +226,7 @@ struct exynos_drm_crtc {
unsigned intdpms;
wait_queue_head_t pending_flip_queue;
struct drm_pending_vblank_event *event;
- struct exynos_drm_crtc_ops *ops;
+ const struct exynos_drm_crtc_ops*ops;
void*ctx;
};
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 2fb95ccb5841..5c1a148525f8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -962,7 +962,7 @@ static void fimd_dp_clock_enable(struct exynos_drm_crtc
*crtc, bool enable)
writel(DP_MIE_CLK_DP_ENABLE, ctx->regs + DP_MIE_CLKCON);
}
-static struct exynos_drm_crtc_ops fimd_crtc_ops = {
+static const struct exynos_drm_crtc_ops fimd_crtc_ops = {
.dpms = fimd_dpms,
.mode_fixup = fimd_mode_fixup,
.commit = fimd_commit,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 27e84ec21694..1b3479a8db5f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -217,7 +217,7 @@ static int vidi_ctx_initialize(struct vidi_context *ctx,
return 0;
}
-static struct exynos_drm_crtc_ops vidi_crtc_ops = {
+static const struct exynos_drm_crtc_ops vidi_crtc_ops = {
.dpms = vidi_dpms,
.enable_vblank = vidi_enable_vblank,
.disable_vblank = vidi_disable_vblank,
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index fbec750574e6..d4afd1abe373 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1126,7 +1126,7 @@ int mixer_check_mode(struct drm_display_mode *mode)
return -EINVAL;
}
-static struct exynos_drm_crtc_ops mixer_crtc_
[RFT PATCH v2 1/3] drm/exynos: Fix build breakage on !DRM_EXYNOS_FIMD
From: Krzysztof Kozlowski
Disabling the CONFIG_DRM_EXYNOS_FIMD (e.g. by enabling of CONFIG_FB_S3C)
leads to build error:
drivers/built-in.o: In function `exynos_dp_dpms':
binder.c:(.text+0xd6a840): undefined reference to `fimd_dp_clock_enable'
binder.c:(.text+0xd6ab54): undefined reference to `fimd_dp_clock_enable'
Fix this by changing direct call to fimd_dp_clock_enable() into optional
call to exynos_drm_crtc_ops->clock_enable(). Only the DRM_EXYNOS_FIMD
implements this op.
Signed-off-by: Krzysztof Kozlowski
---
Changes since v1:
1. Rewrite the idea into exynos_drm_crtc_ops after discussion with Inki
Dae.
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 11 +++---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 5 +
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 37
drivers/gpu/drm/exynos/exynos_drm_fimd.h | 15 -
4 files changed, 31 insertions(+), 37 deletions(-)
delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimd.h
diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index 1dbfba58f909..441ef06b8894 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -32,7 +32,6 @@
#include
#include "exynos_dp_core.h"
-#include "exynos_drm_fimd.h"
#define ctx_from_connector(c) container_of(c, struct exynos_dp_device, \
connector)
@@ -1066,6 +1065,8 @@ static void exynos_dp_phy_exit(struct exynos_dp_device
*dp)
static void exynos_dp_poweron(struct exynos_dp_device *dp)
{
+ struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
+
if (dp->dpms_mode == DRM_MODE_DPMS_ON)
return;
@@ -1076,7 +1077,8 @@ static void exynos_dp_poweron(struct exynos_dp_device *dp)
}
}
- fimd_dp_clock_enable(dp_to_crtc(dp), true);
+ if (crtc->ops->clock_enable)
+ crtc->ops->clock_enable(dp_to_crtc(dp), true);
clk_prepare_enable(dp->clock);
exynos_dp_phy_init(dp);
@@ -1087,6 +1089,8 @@ static void exynos_dp_poweron(struct exynos_dp_device *dp)
static void exynos_dp_poweroff(struct exynos_dp_device *dp)
{
+ struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
+
if (dp->dpms_mode != DRM_MODE_DPMS_ON)
return;
@@ -1102,7 +1106,8 @@ static void exynos_dp_poweroff(struct exynos_dp_device
*dp)
exynos_dp_phy_exit(dp);
clk_disable_unprepare(dp->clock);
- fimd_dp_clock_enable(dp_to_crtc(dp), false);
+ if (crtc->ops->clock_enable)
+ crtc->ops->clock_enable(dp_to_crtc(dp), false);
if (dp->panel) {
if (drm_panel_unprepare(dp->panel))
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index e12ecb5d5d9a..44f128a03aea 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -181,6 +181,10 @@ struct exynos_drm_display {
* @win_disable: disable hardware specific overlay.
* @te_handler: trigger to transfer video image at the tearing effect
* synchronization signal if there is a page flip request.
+ * @clock_enable: optional function enabling/disabling display domain clock,
+ * called from exynos-dp driver before powering up (with
+ * 'enable' argument as true) and after powering down (with
+ * 'enable' as false).
*/
struct exynos_drm_crtc;
struct exynos_drm_crtc_ops {
@@ -195,6 +199,7 @@ struct exynos_drm_crtc_ops {
void (*win_commit)(struct exynos_drm_crtc *crtc, unsigned int zpos);
void (*win_disable)(struct exynos_drm_crtc *crtc, unsigned int zpos);
void (*te_handler)(struct exynos_drm_crtc *crtc);
+ void (*clock_enable)(struct exynos_drm_crtc *crtc, bool enable);
};
/*
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9819fa6a9e2a..2fb95ccb5841 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -33,7 +33,6 @@
#include "exynos_drm_crtc.h"
#include "exynos_drm_plane.h"
#include "exynos_drm_iommu.h"
-#include "exynos_drm_fimd.h"
/*
* FIMD stands for Fully Interactive Mobile Display and
@@ -946,6 +945,23 @@ static void fimd_te_handler(struct exynos_drm_crtc *crtc)
drm_handle_vblank(ctx->drm_dev, ctx->pipe);
}
+static void fimd_dp_clock_enable(struct exynos_drm_crtc *crtc, bool enable)
+{
+ struct fimd_context *ctx = crtc->ctx;
+ u32 val;
+
+ /*
+* Only Exynos 5250, 5260, 5410 and 542x requires enabling DP/MIE
+* clock. On these SoCs the bootloader may enable it but any
+* power domain off/on will reset it to disable state.
+*/
+ if (ctx->driver_data != &exynos5_fimd_driver_data)
+ return;
+
+ val = enable ? DP_MIE_CLK_DP_ENABLE : DP_MIE_CLK_DISABLE;
+ writel(DP_MIE_CLK_DP_ENABLE, ctx->regs + DP_MIE_CLKCON);
+}
+
static stru
[RFT PATCH v2 0/3] drm/exynos: Fix build breakage on !DRM_EXYNOS_FIMD
From: Krzysztof Kozlowski
Hi,
This is second try to fix the build breakage introduced in 1c363c7cccf6
("drm/exynos: Enable DP clock to fix display on Exynos5250 and other").
The fix is not trivial so I am kindly asking for testing on Chromebook
and other DP-enabled boards (I don't have Chromebook right now).
Tested on Exynos4412 Trats2 board.
Best regards,
Krzysztof
Krzysztof Kozlowski (3):
drm/exynos: Fix build breakage on !DRM_EXYNOS_FIMD
drm/exynos: Constify exynos_drm_crtc_ops
drm/exynos: Consolidate return statements in fimd_bind()
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 2 +-
drivers/gpu/drm/exynos/exynos_dp_core.c| 11 +--
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 2 +-
drivers/gpu/drm/exynos/exynos_drm_drv.h| 7 -
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 46 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.h | 15 --
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 +-
drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
9 files changed, 39 insertions(+), 50 deletions(-)
delete mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimd.h
--
1.9.1
[Intel-gfx] [PATCH 1/8] gpiolib: Add support for removing registered consumer lookup table
On Tue, 05 May 2015, Daniel Vetter wrote:
> On Tue, May 05, 2015 at 11:45:05AM +0100, Lee Jones wrote:
> > This is not how we submit subsequent patch-sets.
>
> It is unfortunately how we handle patches on dri-devel&intel-gfx to be
> able to cope with massive mail load. If everyone who submits to intel-gfx
> would always resend the entire series for minor updates of som patches
> we'd completely drown in the resulting flood.
For one or two simple fix-ups in the set perhaps, but when submitting
the entire set it needs to be threaded as a separate block, rather
than seeing current and superseded patches inter-woven. This
submission is already a rat's nest and I'm struggling to see which
patches are which. I'm really not looking forward to v3 and v4!
Attaching one version to another is a good way to keep control if you
really are over-whelmed. For your use-case I would expect to see the
following, which is achieved using --in-reply-to:
[PATCH 0/2] Here is what I did...
[PATCH 1/2] Clean up and tests
[PATCH 2/2] Implementation
[PATCH v2 0/3] Here is a reroll
[PATCH v2 1/3] Clean up
[PATCH v2 2/3] New tests
[PATCH v2 3/3] Implementation
The version numbers also need to be present and aren't in this
re-submission.
> > Please submit them as a whole, seperately from the first submission
> > and with versioning information i.e. [PATCH v2 X/Y] Stuff ...
> >
> > > In case we unload and load a driver module again that is registering a
> > > lookup table, without this it will result in multiple entries. Provide
> > > an option to remove the lookup table on driver unload
> > >
> > > v2: Ccing maintainers
> > > v3: Correct the subject line (Lee jones)
> >
> > Change logs should go underneth the '---' and above the diffstat found
> > below.
>
> Again just style differences between subsystems, I generally want to have
> those above the ---.
For all commits? Then I'm guessing your Git history is all but
unreadable. In the kernel, unless the changelog holds valuable
historic information which influance key design decisions, we put the
patch changelog *below* the '---'.
Please read Documentation/SubmittingPatches:
"14) The canonical patch format
[...]
The "---" marker line serves the essential purpose of marking
for patch handling tools where the changelog message ends.
[...]
Other comments relevant only to the moment or the maintainer,
not suitable for the permanent changelog, should also go here.
A good example of such comments might be *"patch changelogs"*
which describe what has changed between the v1 and v2 version
of the patch."
> > > Cc: Samuel Ortiz
> > > Cc: Linus Walleij
> > > Cc: Alexandre Courbot
> > > Cc: Thierry Reding
> > > Reviewed-by: Alexandre Courbot
> > > Signed-off-by: Shobhit Kumar
> > > ---
> > > drivers/gpio/gpiolib.c | 13 +
> > > include/linux/gpio/machine.h | 1 +
> > > 2 files changed, 14 insertions(+)
> > >
> > > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> > > index 59eaa23..2420af9 100644
> > > --- a/drivers/gpio/gpiolib.c
> > > +++ b/drivers/gpio/gpiolib.c
> > > @@ -1658,6 +1658,19 @@ void gpiod_add_lookup_table(struct
> > > gpiod_lookup_table *table)
> > > mutex_unlock(&gpio_lookup_lock);
> > > }
> > >
> > > +/**
> > > + * gpiod_remove_lookup_table() - unregister GPIO device consumers
> > > + * @table: table of consumers to unregister
> > > + */
> > > +void gpiod_remove_lookup_table(struct gpiod_lookup_table *table)
> > > +{
> > > + mutex_lock(&gpio_lookup_lock);
> > > +
> > > + list_del(&table->list);
> > > +
> > > + mutex_unlock(&gpio_lookup_lock);
> > > +}
> > > +
> > > static struct gpio_desc *of_find_gpio(struct device *dev, const char
> > > *con_id,
> > > unsigned int idx,
> > > enum gpio_lookup_flags *flags)
> > > diff --git a/include/linux/gpio/machine.h b/include/linux/gpio/machine.h
> > > index e270614..c0d712d 100644
> > > --- a/include/linux/gpio/machine.h
> > > +++ b/include/linux/gpio/machine.h
> > > @@ -57,5 +57,6 @@ struct gpiod_lookup_table {
> > > }
> > >
> > > void gpiod_add_lookup_table(struct gpiod_lookup_table *table);
> > > +void gpiod_remove_lookup_table(struct gpiod_lookup_table *table);
> > >
> > > #endif /* __LINUX_GPIO_MACHINE_H */
> >
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org â Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
[Intel-gfx] [PATCH] drm/vblank: Fixup and document timestamp update/read barriers
On 05/06/2015 04:56 AM, Daniel Vetter wrote:
> On Tue, May 05, 2015 at 11:57:42AM -0400, Peter Hurley wrote:
>> On 05/05/2015 11:42 AM, Daniel Vetter wrote:
>>> On Tue, May 05, 2015 at 10:36:24AM -0400, Peter Hurley wrote:
On 05/04/2015 12:52 AM, Mario Kleiner wrote:
> On 04/16/2015 03:03 PM, Daniel Vetter wrote:
>> On Thu, Apr 16, 2015 at 08:30:55AM -0400, Peter Hurley wrote:
>>> On 04/15/2015 01:31 PM, Daniel Vetter wrote:
On Wed, Apr 15, 2015 at 09:00:04AM -0400, Peter Hurley wrote:
> Hi Daniel,
>
> On 04/15/2015 03:17 AM, Daniel Vetter wrote:
>> This was a bit too much cargo-culted, so lets make it solid:
>> - vblank->count doesn't need to be an atomic, writes are always done
>>under the protection of dev->vblank_time_lock. Switch to an
>> unsigned
>>long instead and update comments. Note that atomic_read is just a
>>normal read of a volatile variable, so no need to audit all the
>>read-side access specifically.
>>
>> - The barriers for the vblank counter seqlock weren't complete: The
>>read-side was missing the first barrier between the counter read
>> and
>>the timestamp read, it only had a barrier between the ts and the
>>counter read. We need both.
>>
>> - Barriers weren't properly documented. Since barriers only work if
>>you have them on boths sides of the transaction it's prudent to
>>reference where the other side is. To avoid duplicating the
>>write-side comment 3 times extract a little store_vblank() helper.
>>In that helper also assert that we do indeed hold
>>dev->vblank_time_lock, since in some cases the lock is acquired a
>>few functions up in the callchain.
>>
>> Spotted while reviewing a patch from Chris Wilson to add a fastpath
>> to
>> the vblank_wait ioctl.
>>
>> Cc: Chris Wilson
>> Cc: Mario Kleiner
>> Cc: Ville Syrjälä
>> Cc: Michel Dänzer
>> Signed-off-by: Daniel Vetter
>> ---
>> drivers/gpu/drm/drm_irq.c | 92
>> ---
>> include/drm/drmP.h| 8 +++--
>> 2 files changed, 54 insertions(+), 46 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
>> index c8a34476570a..23bfbc61a494 100644
>> --- a/drivers/gpu/drm/drm_irq.c
>> +++ b/drivers/gpu/drm/drm_irq.c
>> @@ -74,6 +74,33 @@ module_param_named(vblankoffdelay,
>> drm_vblank_offdelay, int, 0600);
>> module_param_named(timestamp_precision_usec,
>> drm_timestamp_precision, int, 0600);
>> module_param_named(timestamp_monotonic, drm_timestamp_monotonic,
>> int, 0600);
>>
>> +static void store_vblank(struct drm_device *dev, int crtc,
>> + unsigned vblank_count_inc,
>> + struct timeval *t_vblank)
>> +{
>> +struct drm_vblank_crtc *vblank = &dev->vblank[crtc];
>> +u32 tslot;
>> +
>> +assert_spin_locked(&dev->vblank_time_lock);
>> +
>> +if (t_vblank) {
>> +tslot = vblank->count + vblank_count_inc;
>> +vblanktimestamp(dev, crtc, tslot) = *t_vblank;
>> +}
>> +
>> +/*
>> + * vblank timestamp updates are protected on the write side with
>> + * vblank_time_lock, but on the read side done locklessly using
>> a
>> + * sequence-lock on the vblank counter. Ensure correct ordering
>> using
>> + * memory barrriers. We need the barrier both before and also
>> after the
>> + * counter update to synchronize with the next timestamp write.
>> + * The read-side barriers for this are in
>> drm_vblank_count_and_time.
>> + */
>> +smp_wmb();
>> +vblank->count += vblank_count_inc;
>> +smp_wmb();
>
> The comment and the code are each self-contradictory.
>
> If vblank->count writes are always protected by vblank_time_lock
> (something I
> did not verify but that the comment above asserts), then the trailing
> write
> barrier is not required (and the assertion that it is in the comment
> is incorrect).
>
> A spin unlock operation is always a write barrier.
Hm yeah. Otoh to me that's bordering on "code too clever for my own
good".
That the spinlock is held I can assure. That no one goes around and
does
multiple vblank updates (because somehow that code raced with the hw
itself) I can't easily assur
[Bug 96351] System hangs up after update to any kernel newer than 3.12*
https://bugzilla.kernel.org/show_bug.cgi?id=96351 --- Comment #38 from Michel Dänzer --- (In reply to George Cheban from comment #37) > I've made another bisect and the result is > 61cf16d8bd38c3dc52033ea75d5b1f8368514a17. > I hope, I did it right. I'm afraid not. That commit just adds a few functions, but doesn't hook them up anywhere. So there's no functional change. Since you don't have a reliable way to reproduce the problem, please take enough time (probably at least one day, preferably several days of using a certain commit) to be at least 99% sure the problem doesn't occur before running git bisect good. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/msm: Fix compil issue when DRM_MSM_FBDEV is disabled
On Thu, May 7, 2015 at 4:13 AM, Archit Taneja wrote:
> Hi,
>
> On 05/06/2015 07:58 PM, Rob Clark wrote:
>>
>> On Wed, May 6, 2015 at 9:25 AM, Stephane Viau
>> wrote:
>>>
>>> When CONFIG_DRM_MSM_FBDEV is not defined,
>>> CONFIG_DRM_KMS_FB_HELPER does not get selected and
>>> drm_fb_helper_*() helper functions are thus not available.
>>>
>>> This change fixes these link issues.
>>
>>
>> Hmm, didn't Archit start on making fbdev config option global and
>> adding nop-stubs for the case that it was disabled? I lost track of
>> where that was going..
>
>
> Daniel and I had thought of a possible solution. I had started working
> on it, but it's still work in progress. It required more things to do
> than originally thought of.
>
> I don't know if that work will make it in time for 4.2. Maybe we could
> pull this for the time being?
Ok, then I'll pull in this change for the time being..
BR,
-R
> Archit
>
>>
>> BR,
>> -R
>>
>>> Signed-off-by: Stephane Viau
>>> ---
>>> drivers/gpu/drm/msm/msm_drv.c | 4
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/msm/msm_drv.c
>>> b/drivers/gpu/drm/msm/msm_drv.c
>>> index 2b1218c..35380ec 100644
>>> --- a/drivers/gpu/drm/msm/msm_drv.c
>>> +++ b/drivers/gpu/drm/msm/msm_drv.c
>>> @@ -21,9 +21,11 @@
>>>
>>> static void msm_fb_output_poll_changed(struct drm_device *dev)
>>> {
>>> +#ifdef DRM_MSM_FBDEV
>>> struct msm_drm_private *priv = dev->dev_private;
>>> if (priv->fbdev)
>>> drm_fb_helper_hotplug_event(priv->fbdev);
>>> +#endif
>>> }
>>>
>>> static const struct drm_mode_config_funcs mode_config_funcs = {
>>> @@ -419,9 +421,11 @@ static void msm_preclose(struct drm_device *dev,
>>> struct drm_file *file)
>>>
>>> static void msm_lastclose(struct drm_device *dev)
>>> {
>>> +#ifdef DRM_MSM_FBDEV
>>> struct msm_drm_private *priv = dev->dev_private;
>>> if (priv->fbdev)
>>> drm_fb_helper_restore_fbdev_mode_unlocked(priv->fbdev);
>>> +#endif
>>> }
>>>
>>> static irqreturn_t msm_irq(int irq, void *arg)
>>> --
>>> Qualcomm Innovation Center, Inc.
>>>
>>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
>>> Forum, a Linux Foundation Collaborative Project
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm"
>> in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>
> a Linux Foundation Collaborative Project
[PATCH v5 1/3] drm/layerscape: Add Freescale DCU DRM driver
Hi Dave, Can you help me to review this patch? Thanks. Jianwei > -Original Message- > From: Jianwei Wang [mailto:jianwei.wang at freescale.com] > Sent: Friday, April 17, 2015 2:36 PM > To: airlied at linux.ie; daniel.vetter at intel.com; stefan at agner.ch; Wood > Scott-B07421; dri-devel at lists.freedesktop.org > Cc: linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; > Jin Zhengxiong-R64188; Wang Jianwei-B52261; Wang Huan-B18965; Xiubo Li; > Wang Jianwei-B52261 > Subject: [PATCH v5 1/3] drm/layerscape: Add Freescale DCU DRM driver > > From: Jianwei Wang > > This patch add support for Two Dimensional Animation and Compositing > Engine (2D-ACE) on the Freescale SoCs. > > 2D-ACE is a Freescale display controller. 2D-ACE describes the > functionality of the module extremely well its name is a value that cannot > be used as a token in programming languages. > Instead the valid token "DCU" is used to tag the register names and > function names. > > The Display Controller Unit (DCU) module is a system master that fetches > graphics stored in internal or external memory and displays them on a TFT > LCD panel. A wide range of panel sizes is supported and the timing of the > interface signals is highly configurable. > Graphics are read directly from memory and then blended in real-time, > which allows for dynamic content creation with minimal CPU intervention. > > The features: > (1) Full RGB888 output to TFT LCD panel. > (2) For the current LCD panel, WQVGA "480x272" is supported. > (3) Blending of each pixel using up to 4 source layers dependent on size > of panel. > (4) Each graphic layer can be placed with one pixel resolution in either > axis. > (5) Each graphic layer support RGB565 and RGB888 direct colors without > alpha channel and BGRA BGRA ARGB1555 direct colors with an alpha > channel and YUV422 format. > (6) Each graphic layer support alpha blending with 8-bit resolution. > > This is a simplified version, only one primary plane, one framebuffer > created for fbdev, one crtc, one connector for TFT LCD panel, an encoder. > > Signed-off-by: Alison Wang > Signed-off-by: Xiubo Li > Signed-off-by: Jianwei Wang > --- > > Changed in V5 > > - Update commit message > - Add layer registers initialization > - Remove unused functions > - Rename driver folder > - Move pixel clock control functions to fsl_dcu_drm_drv.c > - remove redundant enable the clock implicitly using regmap > - Add maintainer message > > Changed in V4: > > -This version doesn't have functionality changed Just a minor adjustment. > > Changed in V3: > > - Test driver on Vybrid board and add compatible string > - Remove unused functions > - set default crtc for encoder > - replace legacy functions with atomic help functions > - Set the unique name of the DRM device > - Implement irq handle function for vblank interrupt > > Changed in v2: > - Add atomic support > - Modify bindings file > - Rename node for compatibility > - Move platform related code out for compatibility > > .../devicetree/bindings/drm/fsl-dcu/fsl,dcu.txt| 50 +++ > MAINTAINERS| 8 + > drivers/gpu/drm/Kconfig| 2 + > drivers/gpu/drm/Makefile | 1 + > drivers/gpu/drm/fsl-dcu/Kconfig| 17 + > drivers/gpu/drm/fsl-dcu/Makefile | 7 + > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.c| 194 +++ > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.h| 30 ++ > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 172 ++ > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.h | 22 ++ > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 373 > + > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 223 > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c| 26 ++ > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c | 42 +++ > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.h | 17 + > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c| 192 +++ > drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.h| 23 ++ > 17 files changed, 1399 insertions(+) > create mode 100644 Documentation/devicetree/bindings/drm/fsl- > dcu/fsl,dcu.txt > create mode 100644 drivers/gpu/drm/fsl-dcu/Kconfig create mode 100644 > drivers/gpu/drm/fsl-dcu/Makefile create mode 100644 drivers/gpu/drm/fsl- > dcu/fsl_dcu_drm_connector.c > create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector.h > create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c > create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.h > create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c > create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h > create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_fbdev.c > create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.c > create mode 100644 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_kms.h > c
[Bug 90284] GPU lockup with DOTA2
https://bugs.freedesktop.org/show_bug.cgi?id=90284 Michel Dänzer changed: What|Removed |Added Attachment #115594|text/plain |application/gzip mime type|| -- 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/20150507/16640601/attachment.html>
[Bug 89203] Mesa 10.4.3 and up causes stuttering and frame drops in a particular game
https://bugs.freedesktop.org/show_bug.cgi?id=89203 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Michel Dänzer --- Glad to hear it's working better now! -- 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/20150507/a7cea65e/attachment.html>
[Bug 90355] DRI_PRIME+radeon+steam=problems + crash
https://bugs.freedesktop.org/show_bug.cgi?id=90355 Michel Dänzer changed: What|Removed |Added Component|Drivers/Gallium/radeonsi|DRM/Radeon Version|10.5|unspecified Product|Mesa|DRI QA Contact|dri-devel at lists.freedesktop | |.org| -- 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/20150507/de3d7bac/attachment.html>
[Bug 95911] Recursive error in radeon device driver module after resume from hibernation
https://bugzilla.kernel.org/show_bug.cgi?id=95911
--- Comment #14 from Michel Dänzer ---
(In reply to gitne from comment #13)
> Mantas MikulÄnas has determined that git commit 4474f3a91f95 was the last
> known good to work.
So commit f2ba57b5eab8817d86d0f108fdf1878e51dc0a37 ("drm/radeon: UVD bringup
v8") is the first bad one? In that case, I think you should be able to work
around it by removing the /lib/firmware/radeon/*_uvd.bin files (and
re-generating the initrd if necessary)
> It's a pity that actually *users* have to do the digging for this kind of
> information. Its all there but kernel developers are obviously too tired or
> too lazy to do actual work after they have spent countless hours bragging
> about how genius they are in delivering fucked up work.
Your rudeness makes me highly doubt that you're Japanese, despite your e-mail
address. Would you like us to respond in kind?
We could spend all our time fixing bugs, but then there wouldn't be any support
for new hardware or features. It's a trade-off. So yes, we do need users' help
for testing and tracking down bugs.
> Oh and another "secret" has been revealed: The bug is caused by ring test
> failures. Wow! Who could have thought of that!
A ring test failure is a symptom which can be caused by many things.
--
You are receiving this mail because:
You are watching the assignee of the bug.
[Bug 90355] DRI_PRIME+radeon+steam=problems + crash
7 00:46:20 danielleite kernel: [ 238.247421] 8800bb0a3998 880224a83c40 88020c3e56c0 880221305a38 May 7 00:46:20 danielleite kernel: [ 238.247443] 8800bb0a39c8 c04e03b4 8800bb0a3c00 880221305990 May 7 00:46:20 danielleite kernel: [ 238.247463] 8800bb0a3c00 5d00 8800bb0a3ac8 c04e0ac8 May 7 00:46:20 danielleite kernel: [ 238.247483] Call Trace: May 7 00:46:20 danielleite kernel: [ 238.247508] [] radeon_sa_bo_try_free+0x64/0x80 [radeon] May 7 00:46:20 danielleite kernel: [ 238.247540] [] radeon_sa_bo_new+0xf8/0x3b0 [radeon] May 7 00:46:20 danielleite kernel: [ 238.247567] [] ? radeon_irq_kms_disable_hpd+0xb0/0xb0 [radeon] May 7 00:46:20 danielleite kernel: [ 238.247599] [] radeon_ib_get+0x42/0xe0 [radeon] May 7 00:46:20 danielleite kernel: [ 238.247625] [] radeon_cs_ib_fill+0x85/0x220 [radeon] May 7 00:46:20 danielleite kernel: [ 238.247652] [] radeon_cs_ioctl+0x10b/0x200 [radeon] May 7 00:46:20 danielleite kernel: [ 238.247677] [] drm_ioctl+0x2e6/0x590 [drm] May 7 00:46:20 danielleite kernel: [ 238.247702] [] ? radeon_cs_parser_init+0x400/0x400 [radeon] May 7 00:46:20 danielleite kernel: [ 238.247722] [] ? futex_wake+0x72/0x140 May 7 00:46:20 danielleite kernel: [ 238.247742] [] radeon_drm_ioctl+0x5d/0xa0 [radeon] May 7 00:46:20 danielleite kernel: [ 238.247769] [] radeon_kms_compat_ioctl+0x14/0x30 [radeon] May 7 00:46:20 danielleite kernel: [ 238.247788] [] compat_SyS_ioctl+0xb8/0x220 May 7 00:46:20 danielleite kernel: [ 238.247804] [] sysenter_dispatch+0x7/0x21 May 7 00:46:20 danielleite kernel: [ 238.247817] Code: 89 fb 4c 89 6d f8 74 39 8b 77 68 4c 8b 67 60 48 8b 7f 58 89 f0 48 89 c2 48 c1 e0 08 48 c1 e2 04 48 29 d0 4c 8d ac 07 60 0d 00 00 <49> 8b 45 00 49 39 c4 77 1e 48 89 df e8 96 e0 0e c1 b8 01 00 00 May 7 00:46:20 danielleite kernel: [ 238.247893] RIP [] radeon_fence_signaled+0x49/0x90 [radeon] May 7 00:46:20 danielleite kernel: [ 238.247919] RSP May 7 00:46:20 danielleite kernel: [ 238.247927] CR2: 0d60 May 7 00:46:20 danielleite kernel: [ 238.252481] ---[ end trace b0a26b210316c3d3 ]--- Thanks for the help and for mesa & open drivers! -- 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/20150507/c8277d31/attachment-0001.html>
[i915]] *ERROR* mismatch in scaler_state.scaler_id
Hi, This error happens when crtc_state in driver not matching with hardware registers. On skylake board that I have, I am not able to reproduce the issue. Can you send the system configuration and steps to reproduce the issue? Also can you send the full dmesg.log file? -Chandra > -Original Message- > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel > Vetter > Sent: Wednesday, May 06, 2015 4:09 AM > To: Sergey Senozhatsky > Cc: David Airlie; Vetter, Daniel; intel-gfx at lists.freedesktop.org; dri- > devel at lists.freedesktop.org; linux-kernel at vger.kernel.org; Konduru, > Chandra > Subject: Re: [i915]] *ERROR* mismatch in scaler_state.scaler_id > > Adding Chandra, who's implemented skl scaler code. > -Daniel > > On Sat, May 02, 2015 at 10:05:42AM +0900, Sergey Senozhatsky wrote: > > Hi, > > > > linux-next 20150501 > > > > [1.968953] [drm:check_crtc_state [i915]] *ERROR* mismatch in > scaler_state.scaler_id (expected 0, found -1) > > [1.968953] [ cut here ] > > [1.968983] WARNING: CPU: 0 PID: 6 at > drivers/gpu/drm/i915/intel_display.c:12008 check_crtc_state+0xb15/0xb83 > [i915]() > > [1.968983] pipe state doesn't match! > > [..] > > [1.969005] CPU: 0 PID: 6 Comm: kworker/u16:0 Not tainted 4.1.0-rc1-next- > 20150501-dbg-00011-gbcb7bed-dirty #49 > > [1.969010] Workqueue: events_unbound async_run_entry_fn > > [1.969012] 0009 88041d9eb448 812e9753 > > > [1.969013] 88041d9eb498 88041d9eb488 81034c24 > 88041d9eb490 > > [1.969015] a03a81dc 88041d123000 88041cbbc800 > 0001 > > [1.969015] Call Trace: > > [1.969019] [] dump_stack+0x45/0x57 > > [1.969022] [] warn_slowpath_common+0x97/0xb1 > > [1.969050] [] ? check_crtc_state+0xb15/0xb83 [i915] > > [1.969052] [] warn_slowpath_fmt+0x41/0x43 > > [1.969080] [] check_crtc_state+0xb15/0xb83 [i915] > > [1.969082] [] ? update_curr+0x68/0xd1 > > [1.969112] [] intel_modeset_check_state+0x603/0xa3d > [i915] > > [1.969140] [] intel_crtc_set_config+0x8dc/0xc02 > > [i915] > > [1.969147] [] ? > drm_atomic_helper_plane_set_property+0x6c/0xa4 [drm_kms_helper] > > [1.969159] [] drm_mode_set_config_internal+0x57/0xe3 > [drm] > > [1.969164] [] restore_fbdev_mode+0xb5/0xcf > [drm_kms_helper] > > [1.969169] [] > drm_fb_helper_restore_fbdev_mode_unlocked+0x22/0x59 [drm_kms_helper] > > [1.969173] [] drm_fb_helper_set_par+0x31/0x35 > [drm_kms_helper] > > [1.969202] [] intel_fbdev_set_par+0x15/0x58 [i915] > > [1.969204] [] fbcon_init+0x323/0x431 > > [1.969206] [] visual_init+0xb7/0x10d > > [1.969208] [] do_bind_con_driver+0x1b1/0x2d8 > > [1.969209] [] do_take_over_console+0x15a/0x184 > > [1.969212] [] do_fbcon_takeover+0x5b/0x97 > > [1.969213] [] fbcon_event_notify+0x419/0x740 > > [1.969215] [] notifier_call_chain+0x3b/0x5f > > [1.969217] [] > > __blocking_notifier_call_chain+0x43/0x5f > > [1.969219] [] blocking_notifier_call_chain+0xf/0x11 > > [1.969220] [] fb_notifier_call_chain+0x16/0x18 > > [1.969222] [] register_framebuffer+0x28f/0x2c7 > > [1.969250] [] ? intelfb_create+0x2e7/0x38a [i915] > > [1.969256] [] > > drm_fb_helper_initial_config+0x297/0x3e1 > [drm_kms_helper] > > [1.969284] [] intel_fbdev_initial_config+0x16/0x18 > [i915] > > [1.969286] [] async_run_entry_fn+0x33/0xca > > [1.969288] [] process_one_work+0x192/0x2a8 > > [1.969290] [] worker_thread+0x266/0x34c > > [1.969291] [] ? rescuer_thread+0x276/0x276 > > [1.969293] [] kthread+0xcd/0xd5 > > [1.969294] [] ? kthread_worker_fn+0x130/0x130 > > [1.969296] [] ret_from_fork+0x42/0x70 > > [1.969297] [] ? kthread_worker_fn+0x130/0x130 > > [1.969298] ---[ end trace 7f37d8e5ab4ee0a8 ]--- > > > > -ss > > ___ > > dri-devel mailing list > > dri-devel at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
