Re: [PATCH v2 2/3] Subject: [PATCH] drm/mediatek/dp: Add HDCP2.x feature for DisplayPort

Re: [PATCH v2 2/3] Subject: [PATCH] drm/mediatek/dp: Add HDCP2.x feature for DisplayPort

Re: [PATCH v2 2/3] Subject: [PATCH] drm/mediatek/dp: Add HDCP2.x feature for DisplayPort

Re: [PATCH v2 1/3] Subject: [PATCH] drm/mediatek/dp: Add tee client application for HDCP feature

Re: [PATCH v2 1/3] Subject: [PATCH] drm/mediatek/dp: Add tee client application for HDCP feature

Re: [PATCH v2 2/3] Subject: [PATCH] drm/mediatek/dp: Add HDCP2.x feature for DisplayPort

Re: [PATCH v2 2/3] Subject: [PATCH] drm/mediatek/dp: Add HDCP2.x feature for DisplayPort

a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/mac-shen/Subject-PATCH-drm-mediatek-dp-Add-tee-client-application-for-HDCP-feature/20240205-163727

[no subject]

Hi Dave, A few fixes for v6.8, description below The following changes since commit d4ca26ac4be0d9aea7005c40df75e6775749671b: drm/msm/dp: call dp_display_get_next_bridge() during probe (2023-12-14 09:27:46 +0200) are available in the Git repository at:

Re: [PATCH v2 2/3] Subject: [PATCH] drm/mediatek/dp: Add HDCP2.x feature for DisplayPort

Il 05/02/24 06:50, mac.shen ha scritto: Add HDCP2.x feature for DisplayPort. When userspace request the kernel protect future content communicated over the link with Content_Protection property, the feature will do HDCP2.x authentication if the sink support HDCP2.X. Changes in v2: - remove

Re: [PATCH v2 1/3] Subject: [PATCH] drm/mediatek/dp: Add tee client application for HDCP feature

Il 05/02/24 06:50, mac.shen ha scritto: Add tee client application which will be used for HDCP 1.x and 2.x authentication in DisplayPort. Changes in v2: - remove ca folder, and change file name with lower case - refine the tci_t structure to make the data to tee can through this structure -

Re: [PATCH v2 1/3] Subject: [PATCH] drm/mediatek/dp: Add tee client application for HDCP feature

us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/mac-shen/Subject-PATCH-drm-mediatek-dp-Add-tee-client-application-for-HDCP-feature/20240205

[PATCH v2 2/3] Subject: [PATCH] drm/mediatek/dp: Add HDCP2.x feature for DisplayPort

Add HDCP2.x feature for DisplayPort. When userspace request the kernel protect future content communicated over the link with Content_Protection property, the feature will do HDCP2.x authentication if the sink support HDCP2.X. Changes in v2: - remove switch case, and refine code to make more

[PATCH v2 1/3] Subject: [PATCH] drm/mediatek/dp: Add tee client application for HDCP feature

Add tee client application which will be used for HDCP 1.x and 2.x authentication in DisplayPort. Changes in v2: - remove ca folder, and change file name with lower case - refine the tci_t structure to make the data to tee can through this structure - remove aux and regs from mtk_hdcp_info

[PATCH v2 3/3] Subject: [PATCH] drm/mediatek/dp: Add HDCP1.x feature for DisplayPort

Add HDCP1.x feature for DisplayPort. If the sink support HDCP1.X only, the feature will do HDCP1.x authentication when userspace request the kernel protect with HDCP_Content_Type property as DRM_MODE_HDCP_CONTENT_TYPE0. Changes in v2: - remove useless code - remove the prefix 'mdrv' - do HDCP1.x

[no subject]

Subject: [PATCH] ARM: multi_v7_defconfig: Enable BACKLIGHT_CLASS_DEVICE Commit 72fee6b0a3a4 ("fbdev: Restrict FB_SH_MOBILE_LCDC to SuperH") disabled availablity of the SH_MOBILE_LCDC driver on the RENESAS arch. This innocent change has a significant side-effect on the ARM's multi_v7

[no subject]

This patch fix's the failure of the frame buffer driver on my Asahi kernel which prevented X11 from starting on my Apple M1 laptop. It seems like a straight forward failure to follow the procedure described in drivers/video/aperture.c to remove the ealier driver. This patch is very simple and

[no subject]

Any progress on this? Is it ok if yi...@chromium.org and I do the followups on this patch so that we can also submit the Hotplug patch I wrote (that's now archived?).

[no subject]

Date: Sat, 11 Mar 2023 19:00:03 + Subject: [PATCH 5.10 1/1] drm/amdgpu: add error handling for drm_fb_helper_initial_config The type of return value of drm_fb_helper_initial_config is int, which may return wrong result, so we add error handling for it to reclaim memory resource, and return

[no subject]

Date: Thu, 10 Nov 2022 16:47:26 +0300 Subject: [PATCH] drm/amdgpu/display: Add pointer check Return value of a function 'dc_create_state' is dereferenced at amdgpu_dm.c:2027 without checking for null Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Denis Arefev

[no subject]

Date: Tue, 22 Nov 2022 15:51:44 +0300 Subject: [PATCH] powerplay: hwmgr: added result check The return value of the 'div64_s64' function called in ppevvmath.h:371 was not checked. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Denis Arefev --- drivers/gpu/drm

Subject: [PATCH] driver: gpu: add failure check for ftell

add return-value check of ftell to improve robustness(and avoid abnormal behavior) Signed-off-by: SPeak Signed-off-by: shenyanfeng --- drivers/gpu/drm/radeon/mkregtable.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/mkregtable.c

[no subject]

Just sending that out once more to intel-gfx to let the CI systems take a look. No functional change compared to the last version. Christian.

[no subject]

Just sending that to intel-gfx to let the CI systems take a look at it. Regards, Christian.

[no subject]

Hey Linus, pretty quiet week, one fbdev, msm, kconfig, and 2 amdgpu fixes, about what I'd expect for rc6. Regards, Dave. drm-fixes-2022-05-06: drm fixes for 5.18-rc6 fbdev: - hotunplugging fix amdgpu: - Fix a xen dom0 regression on APUs - Fix a potential array overflow if a receiver were to

[no subject]

Hi Daniel, rebased on top of all the changes in drm-misc-next now and hopefully ready for 5.19. I think I addressed all concern, but there was a bunch of rebase fallout from i915, so better to double check that once more. Regards, Christian.

Re: [PATCH v6 7/9] drm/i915: Reduce the number of objects subject to memcpy recover

On 9/23/21 11:44 AM, Matthew Auld wrote: On 22/09/2021 07:25, Thomas Hellström wrote: We really only need memcpy restore for objects that affect the operability of the migrate context. That is, primarily the page-table objects of the migrate VM. Add an object flag, I915_BO_ALLOC_PM_EARLY for

Re: [PATCH v6 7/9] drm/i915: Reduce the number of objects subject to memcpy recover

On 22/09/2021 07:25, Thomas Hellström wrote: We really only need memcpy restore for objects that affect the operability of the migrate context. That is, primarily the page-table objects of the migrate VM. Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early restores using

[PATCH v6 7/9] drm/i915: Reduce the number of objects subject to memcpy recover

We really only need memcpy restore for objects that affect the operability of the migrate context. That is, primarily the page-table objects of the migrate VM. Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early restores using memcpy and a way to assign LMEM page-table object

[PATCH v5 7/7] drm/i915: Reduce the number of objects subject to memcpy recover

We really only need memcpy restore for objects that affect the operability of the migrate context. That is, primarily the page-table objects of the migrate VM. Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early restores using memcpy and a way to assign LMEM page-table object

[PATCH v4 6/6] drm/i915: Reduce the number of objects subject to memcpy recover

We really only need memcpy restore for objects that affect the operability of the migrate context. That is, primarily the page-table objects of the migrate VM. Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early restores using memcpy and a way to assign LMEM page-table object

Re: [PATCH v3 6/6] drm/i915: Reduce the number of objects subject to memcpy recover

On Mon, 2021-09-20 at 12:05 +0100, Matthew Auld wrote: > On 14/09/2021 20:31, Thomas Hellström wrote: > > We really only need memcpy restore for objects that affect the > > operability of the migrate context. That is, primarily the page- > > table > > objects of the migrate VM. > > > > Add an

Re: [PATCH v3 6/6] drm/i915: Reduce the number of objects subject to memcpy recover

On 14/09/2021 20:31, Thomas Hellström wrote: We really only need memcpy restore for objects that affect the operability of the migrate context. That is, primarily the page-table objects of the migrate VM. Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early restores using

[PATCH v3 6/6] drm/i915: Reduce the number of objects subject to memcpy recover

We really only need memcpy restore for objects that affect the operability of the migrate context. That is, primarily the page-table objects of the migrate VM. Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early restores using memcpy and a way to assign LMEM page-table object

[PATCH v2 6/6] drm/i915: Reduce the number of objects subject to memcpy recover

We really only need memcpy restore for objects that affect the operability of the migrate context. That is, primarily the page-table objects of the migrate VM. Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early restores using memcpy and a way to assign LMEM page-table object

Subject: [PATCH v2 0/2] Fix a hung during memory pressure test

[AMD Official Use Only] A long time ago, someone reports system got hung during memory test. In recent days, I am trying to look for or understand the potential deadlock in ttm/amdgpu code. This patchset aims to fix the deadlock during ttm populate. TTM has a parameter called pages_limit, when

[PATCH 6/6] drm/i915: Reduce the number of objects subject to memcpy recover

We really only need memcpy restore for objects that affect the operability of the migrate context. That is, primarily the page-table objects of the migrate VM. Add an object flag, I915_BO_ALLOC_PM_EARLY for objects that need early restores using memcpy and a way to assign LMEM page-table object

[no subject]

Hello everyone, my name is Shashank Singh. I hope this is the right platform to reach out to the 'X.org' community. I was curious about the X.org Endless Vacation of Code. Is this program still active?

[no subject]

>From Dmitry Baryshkov # This line is ignored. From: Dmitry Baryshkov Reply-To: Subject: [PATCH v2 0/6] drm/msm/dpu: simplify RM code In-Reply-To: There is no need to request most of hardware blocks through the resource manager (RM), since typically there is 1:1 or N:1 relationship betw

[no subject]

Hi Linus, Regular fixes for final, there is a ttm regression fix, dp-mst fix, one amdgpu revert, two i915 fixes, and some misc fixes for sun4i, xlnx, and vc4. All pretty quiet and don't think we have any known outstanding regressions. Dave. drm-fixes-2021-02-12: drm fixes for 5.11-rc8 ttm: -

[no subject]

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

Re: Subject: [RFC] clang tooling cleanups

On 11/9/20 6:52 PM, Joe Perches wrote: > On Tue, 2020-10-27 at 09:42 -0700, t...@redhat.com wrote: >> This rfc will describe >> An upcoming treewide cleanup. >> How clang tooling was used to programatically do the clean up. >> Solicit opinions on how to generally use clang tooling. >> >> The

Re: Subject: [RFC] clang tooling cleanups

On Tue, 2020-10-27 at 09:42 -0700, t...@redhat.com wrote: > This rfc will describe > An upcoming treewide cleanup. > How clang tooling was used to programatically do the clean up. > Solicit opinions on how to generally use clang tooling. > > The clang warning -Wextra-semi-stmt produces about 10k

Subject: [RFC] clang tooling cleanups

This rfc will describe An upcoming treewide cleanup. How clang tooling was used to programatically do the clean up. Solicit opinions on how to generally use clang tooling. The clang warning -Wextra-semi-stmt produces about 10k warnings. Reviewing these, a subset of semicolon after a switch looks

[no subject]

Signed-off-by: Sandeep Raghuraman ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

The goal here is to make the ttm_tt object just represent a memory backing store, and now whether the store is bound to a global translation table. It moves binding up to the bo level. There's a lot more work on removing the global TT from the core of TTM, but this seems like a good start. Dave.

Re: [PATCH 0/4] *** SUBJECT HERE ***

On Tue, Aug 18, 2020 at 11:50:35AM +0200, Greg Kroah-Hartman wrote: > On Tue, Aug 18, 2020 at 12:17:08PM +0300, Tomer Samara wrote: > > *** BLURB HERE *** > > Really? > > And your subject line could use some work too :( > sorry for that, i've made a script for sending

Re: [PATCH 0/4] *** SUBJECT HERE ***

On Tue, Aug 18, 2020 at 12:17:08PM +0300, Tomer Samara wrote: > *** BLURB HERE *** Really? And your subject line could use some work too :( ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/

Re: [PATCHv2 0/4] Subject: panel-dsi-cm: update bindings

Hi Sebastian, On 16/07/2020 15:57, Sebastian Reichel wrote: > The cleanup series for omapdrm's DSI code got too big. Reviewing > this is not fun and the same goes for keeping track of the change > requests. Let's do the cleanup in smaller steps instead. This is > the first batch, which updates

[PATCHv2 0/4] Subject: panel-dsi-cm: update bindings

The cleanup series for omapdrm's DSI code got too big. Reviewing this is not fun and the same goes for keeping track of the change requests. Let's do the cleanup in smaller steps instead. This is the first batch, which updates the binding (txt -> yaml) and modifies the DT slightly. Changes since

Subject: [PATCH v1 0/8] support cmdq helper function on mt6779 platform

This patch support more gce helper function on mt6779 platform. depends on patch: support gce on mt6779 platform and depends on following applied patches soc: mediatek: cmdq: add set event function soc: mediatek: cmdq: export finalize function soc: mediatek: cmdq: add assign function Change

[no subject]

Hi Dave, A few fixes, mostly fallout from the address space refactor and dpu color processing. The following changes since commit 1cb2c4a2c89b2004a36399860c85a1af9b3fcba7: Revert "drm/msm/dpu: add support for clk and bw scaling for display" (2020-06-01 20:56:18 -0700) are available in the

Re: [PATCH V2 00/11] Subject: Remove duplicated kmap code

On Mon, May 04, 2020 at 01:17:41PM -0700, Ira Weiny wrote: > > || * arm: much, much worse. We have several files that pull > > linux/highmem.h: > > || arch/arm/mm/cache-feroceon-l2.c, arch/arm/mm/cache-xsc3l2.c, > > || arch/arm/mm/copypage-*.c, arch/arm/mm/dma-mapping.c, arch/arm/mm/flush.c, >

Re: [PATCH V2 00/11] Subject: Remove duplicated kmap code

On Mon, May 04, 2020 at 10:02:25PM +0100, Al Viro wrote: > On Mon, May 04, 2020 at 01:17:41PM -0700, Ira Weiny wrote: > > > > || * arm: much, much worse. We have several files that pull > > > linux/highmem.h: > > > || arch/arm/mm/cache-feroceon-l2.c, arch/arm/mm/cache-xsc3l2.c, > > > ||

Re: [PATCH V2 00/11] Subject: Remove duplicated kmap code

On Mon, May 04, 2020 at 06:33:57AM +0100, Al Viro wrote: > On Sun, May 03, 2020 at 10:04:47PM -0700, Ira Weiny wrote: > > > Grepping for 'asm/highmem.h' and investigations don't reveal any issues... > > But > > you do have me worried. That said 0-day has been crunching on multiple > > versions

Re: [PATCH V2 00/11] Subject: Remove duplicated kmap code

On Sun, May 03, 2020 at 06:09:01PM -0700, ira.we...@intel.com wrote: > From: Ira Weiny > > The kmap infrastructure has been copied almost verbatim to every architecture. > This series consolidates obvious duplicated code by defining core functions > which call into the architectures only when

Re: [PATCH V2 00/11] Subject: Remove duplicated kmap code

On Sun, May 03, 2020 at 10:04:47PM -0700, Ira Weiny wrote: > Grepping for 'asm/highmem.h' and investigations don't reveal any issues... > But > you do have me worried. That said 0-day has been crunching on multiple > versions of this series without issues such as this (save the mips issue >

Re: [PATCH V2 00/11] Subject: Remove duplicated kmap code

On Mon, May 04, 2020 at 02:35:09AM +0100, Al Viro wrote: > On Sun, May 03, 2020 at 06:09:01PM -0700, ira.we...@intel.com wrote: > > From: Ira Weiny > > > > The kmap infrastructure has been copied almost verbatim to every > > architecture. > > This series consolidates obvious duplicated code by

[PATCH V2 00/11] Subject: Remove duplicated kmap code

From: Ira Weiny The kmap infrastructure has been copied almost verbatim to every architecture. This series consolidates obvious duplicated code by defining core functions which call into the architectures only when needed. Some of the k[un]map_atomic() implementations have some similarities but

[no subject]

Subject: Re: [PATCH 04/12] drm: Nuke mode->vrefresh Message-ID: <20200226115708.gh13...@intel.com> References: <20200219203544.31013-1-ville.syrj...@linux.intel.com> <20200219203544.31013-5-ville.syrj...@linux.intel.com> <0f278771-79ce-fe23-e72c-3935dbe82...@samsung.co

[PATCH v2 4/5] Subject: drm/amdgpu: Redo XGMI reset synchronization.

Use task barrier in XGMI hive to synchronize ASIC resets across devices in XGMI hive. v2: Retrun right away with a warning if no xgmi hive, update doc. Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 37 +- 1 file changed, 31

Re: [RESEND PATCH 4/5] Subject: drm/amdgpu: Redo XGMI reset synchronization.

, Hawking ; Quan, Evan ; Grodzovsky, Andrey Subject: [RESEND PATCH 4/5] Subject: drm/amdgpu: Redo XGMI reset synchronization. Use task barrier in XGMI hive to synchronize ASIC resets across devices in XGMI hive. Signed-off-by: Andrey Grodzovsky <mailto:andrey.grodzov...@amd.com>> ---

RE: [RESEND PATCH 4/5] Subject: drm/amdgpu: Redo XGMI reset synchronization.

, Andrey Subject: [RESEND PATCH 4/5] Subject: drm/amdgpu: Redo XGMI reset synchronization. Use task barrier in XGMI hive to synchronize ASIC resets across devices in XGMI hive. Signed-off-by: Andrey Grodzovsky mailto:andrey.grodzov...@amd.com>> --- drivers/gpu/drm/amd/

[RESEND PATCH 4/5] Subject: drm/amdgpu: Redo XGMI reset synchronization.

Use task barrier in XGMI hive to synchronize ASIC resets across devices in XGMI hive. Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 42 +- 1 file changed, 36 insertions(+), 6 deletions(-) diff --git

[no subject]

Hi Dave, This time around: + OCMEM support to enable the couple generations that had shared OCMEM rather than GMEM exclusively for the GPU (late a3xx and I think basically all of a4xx). Bjorn and Brian decided to land this through the drm tree to avoid having to coordinate merge requests.

[no subject]

Subject: [PATCH v2 0/8] panfrost: Locking and runtime PM fixes With further testing of recent changes with lockdep and other locking checks enabled, we've found several bugs in the shrinker code and one sleep while atomic in panfrost_gem_open(). This series addresses those issues. Delaying

[no subject]

The first three patches prepare for the removal of drmP.h. The last patch remove use of drmP.h and replace with necessary include files to fix build. Build tested with various configs and various architectures. I had preferred that the via driver was replaced by the openchrome driver, but until

[no subject]

Hey Linus, A small bit more lively this week but not majorly so. I'm away in Japan next week for family holiday, so I'll be pretty disconnected, I've asked Daniel to do fixes for the week while I'm out. core: - Allow fb changes in async commits (drivers as well) udmabuf: - Unmap scatterlist

[no subject]

From tho...@m3y3r.de Sun May 26 13:49:04 2019 Subject: [PATCH] drm/omap: Make sure device_id tables are NULL terminated To: tomi.valkei...@ti.com, airl...@linux.ie, dan...@ffwll.ch, dri-devel@lists.freedesktop.org, linux-ker...@vger.kernel.org Content-Type: text/plain; charset="UTF-8&

[no subject]

Hi Linus, Just a couple of fixes PRs for rc1, One MAINTAINERS address change, two panels fixes, and set of amdgpu fixes (build fixes, display fixes and some others). Thanks Dave. drm-next-2018-08-24: amdgpu and panel/misc fixes. The following changes since commit

[no subject]

Hi Linus, (apologies for blank body pull earlier) This is the drm fixes for rc4. It's a bit larger than I'd like but the exynos cleanups are pretty mechanical, and I'd rather have them in sooner rather than later so we can avoid too much conflicts around them. The non-mechanincal exynos changes

[no subject]

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

[no subject]

linux-...@vger.kernel.org,Noralf Trønnes <nor...@tronnes.org>,Sean Paul <seanp...@chromium.org>,ker...@martin.sperl.org Cc: Bcc: Subject: Re: [PATCH v2 0/2] Chunk splitting of spi transfers Reply-To: In-Reply-To: <f6dbf3ca-4c1b-90cc-c4af-8889f7407...@tronnes.org> On Sun, Mar

[no subject]

Hi Linus, This is the main set of fixes for rc4, one amdgpu fix, some exynos regression fixes, some msm fixes and some i915 and GVT fixes. I've got a second regression fix for some DP chips that might be a bit large, but I think we'd like to land it now, I'll send it along tomorrow, once you are

No subject

hi, I'm a new programmer, i just was wondering if i can get some docs to start learning DRI. I googled a lot but i didn't find a starter documentation. Some refs will be apreciated thx

No subject

Subject: [PATCH v5 0/5] drm: Add Support for Passive RGB to VGA bridges Hi, This serie is about adding support for the RGB to VGA bridge found in the A13-Olinuxino and the CHIP VGA adapter. Both these boards rely on an entirely passive bridge made out of resitor ladders that do not require any

No subject

With patch http://patchwork.freedesktop.org/patch/msgid/1455106118-32145-1-git-send-email-palminha at synopsys.com i2c slave encoder drivers no longer need to implement dummy mode_fixup function. This patch set nukes the dummy functions from i2c slave encoder drivers. (changes made on top of

[GIT PULL x/y] SUBJECT HERE

Merge tag 'drm-intel-next-fixes-2016-01-14' of git://anongit.freedesktop.org/drm-intel into drm-next (2016-01-18 07:02:19 +1000) are available in the git repository at: http://github.com/anholt/linux tags/drm-vc4-fixes-2015-01-19 for you to fetch changes up to

[no subject]

On 2014.09.07 at 23:47 -0400, Alex Deucher wrote: > On Sun, Sep 7, 2014 at 9:24 AM, Markus Trippelsdorf > wrote: > > On 2014.08.25 at 11:10 +0200, Christian K?nig wrote: > >> Let me know if it works for you, cause we don't really have any hardware > >> any more to test it. > > > > I've tested

[no subject]

On Sun, Sep 7, 2014 at 9:24 AM, Markus Trippelsdorf wrote: > On 2014.08.25 at 11:10 +0200, Christian K?nig wrote: >> Let me know if it works for you, cause we don't really have any hardware >> any more to test it. > > I've tested your patch series today (using drm-next-3.18 from > ~agd5f/linux)

[no subject]

On 2014.08.25 at 11:10 +0200, Christian K?nig wrote: > Let me know if it works for you, cause we don't really have any hardware > any more to test it. I've tested your patch series today (using drm-next-3.18 from ~agd5f/linux) on a RS780D/Radeon HD 3300 system with a couple of H264 videos. While

[no subject]

Let me know if it works for you, cause we don't really have any hardware any more to test it. Christian. Am 24.08.2014 um 15:34 schrieb Mike Lothian: > > Thanks for this > > Good work > > On 24 Aug 2014 14:15, "Christian K?nig" > wrote: > > Hello

No subject

Hello everyone, the following patches add UVD support for older ASICs (RV6xx, RS[78]80, RV7[79]0). For everybody wanting to test it I've also uploaded a branch to FDO: http://cgit.freedesktop.org/~deathsimple/linux/log/?h=uvd-r600-release Additionally to the patches you need UVD firmware as

[no subject]

Thanks for this Good work On 24 Aug 2014 14:15, "Christian K?nig" wrote: > Hello everyone, > > the following patches add UVD support for older ASICs (RV6xx, RS[78]80, > RV7[79]0). For everybody wanting to test it I've also uploaded a branch to > FDO: >

No subject

After a previous patch series and a discussion with Daniel Vetter and David Herrmann, I've reworked the patches a bit. Please review. Patch 5 is already reviewed. /Thomas >From Thomas Hellstrom # This line is ignored. From: Thomas Hellstrom <thellst...@vmware.com> Subject: In-Reply-To:

[PATCH v3 0/2] *** SUBJECT HERE ***

*** BLURB HERE *** Jean-Francois Moine (2): drivers/base: permit base components to omit the bind/unbind ops drivers/base: declare phandle DT nodes as components drivers/base/component.c | 21 +++-- drivers/base/core.c | 18 ++ include/linux/of.h |

[PATCH v3 0/2] *** SUBJECT HERE ***

On Fri, Feb 07, 2014 at 06:09:46PM +0100, Jean-Francois Moine wrote: > *** BLURB HERE *** Subject and BLURB forgotten?

No subject

Hey Alex, here are my patches for reworking the ring function pointers and separating out the UVD and DMA rings. Everything is rebased on your drm-next-3.12-wip branch, please review and add them to your branch. Thanks, Christian.

[no subject]

On Tue, Aug 13, 2013 at 5:56 AM, Christian K?nig wrote: > Hey Alex, > > here are my patches for reworking the ring function pointers and separating > out the UVD and DMA rings. > > Everything is rebased on your drm-next-3.12-wip branch, please review and add > them to your branch. Patches look

[no subject]

Hey Alex, here are my patches for reworking the ring function pointers and separating out the UVD and DMA rings. Everything is rebased on your drm-next-3.12-wip branch, please review and add them to your branch. Thanks, Christian. ___ dri-devel

[PATCH v2 0/4] *** SUBJECT HERE ***

I forgot to include some acked and tested-by lines in v1 of this series. No code changes in v2. thanks, Christopher Harvey (4): drm/mgag200: Don't change unrelated registers during modeset drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register drm/mgag200: Convert counter delays to

[PATCH v2 0/4] *** SUBJECT HERE ***

I forgot to include some acked and tested-by lines in v1 of this series. No code changes in v2. thanks, Christopher Harvey (4): drm/mgag200: Don't change unrelated registers during modeset drm/mgag200: Fix writes into MGA1064_PIX_CLK_CTL register drm/mgag200: Convert counter delays to

No subject

, pza Bcc: Subject: Re: [PATCH 1/2 v6] of: add helper to parse display timings Reply-To: In-Reply-To: X-Sent-From: Pengutronix Hildesheim X-URL: http://www.pengutronix.de/ X-IRC: #ptxdist @freenode X-Accept-Language: de,en X-Accept-Content-Type: text/plain X-Uptime: 09:13:09 up 103 days, 22:24

[no subject]

tomi.valkei...@ti.com, pza Bcc: Subject: Re: [PATCH 1/2 v6] of: add helper to parse display timings Reply-To: In-Reply-To: Pine.LNX.4.64.1210042307300.3744@axis700.grange X-Sent-From: Pengutronix Hildesheim X-URL: http://www.pengutronix.de/ X-IRC: #ptxdist @freenode X-Accept-Language: de,en X

No subject

issue is that changing it will break any app relying on it being REALTIME clock.

No subject

0x0314e050: 0x61010006: STATE_BASE_ADDRESS 0x0314e054: 0x0001:general state base address 0x 0x0314e058: 0x0001:surface state base address 0x 0x0314e05c: 0x0001:indirect state base address 0x 0x0314e060: 0x0001:

[no subject]

On Tue, May 22, 2012 at 04:06:41PM +0200, Lars-Peter Clausen wrote: > On 05/18/2012 02:27 PM, Sascha Hauer wrote: > > Hi All, > > > > The following adds a drm/kms driver for the Freescale i.MX LCDC > > controller. Most notable change to the last SDRM based version is that > > the SDRM layer has

No subject

i don't think kernel is the right place for it, for instance you need to set the primary surface thing, i don't want to parse cmd stream in kernel to figure that out. I would rather have userspace tool that postprocess thing and convert it to proper AMD dump format. Cheers, Jerome

[no subject]

On Tue, May 22, 2012 at 04:06:41PM +0200, Lars-Peter Clausen wrote: > On 05/18/2012 02:27 PM, Sascha Hauer wrote: > > Hi All, > > > > The following adds a drm/kms driver for the Freescale i.MX LCDC > > controller. Most notable change to the last SDRM based version is that > > the SDRM layer has

[no subject]

On 05/18/2012 02:27 PM, Sascha Hauer wrote: > Hi All, > > The following adds a drm/kms driver for the Freescale i.MX LCDC > controller. Most notable change to the last SDRM based version is that > the SDRM layer has been removed and the driver now is purely i.MX > specific. I hope that this is

[no subject]

Hi All, The following adds a drm/kms driver for the Freescale i.MX LCDC controller. Most notable change to the last SDRM based version is that the SDRM layer has been removed and the driver now is purely i.MX specific. I hope that this is more acceptable now. Another change is that the probe is

  1   2   >