[PATCH v2 0/7] Consider G2D hardware restrictions.

This patch set checks the contents of g2d command list from user is valid or not according to G2D hardware restrictions. For now, G2D driver wasn't considered for them properly. For this, this patch set includes relevant code cleaups, fixups and adds a new function to get buffer size to the gem

[PATCH v2 3/7] drm/exynos: Fix G2D core malfunctioning issue

From: YoungJun Cho yj44@samsung.com This patch fixes G2D core malfunctioning issue once g2d dma is started. Without 'DMA_HOLD_CMD_REG' register setting, there is only one interrupt after the execution to all command lists have been completed. And that induces watchdog. So this patch sets

[PATCH v2 4/7] drm/exynos: Clean up some G2D codes for readability

From: YoungJun Cho yj44@samsung.com This patch just cleans up G2D codes for readability. For this, it changes the member of g2d_cmdlist_node, obj_type into buf_type. Changelog v2: - Revert irrelevant codes. Signed-off-by: YoungJun Cho yj44@samsung.com Signed-off-by: Inki Dae

[PATCH v2 5/7] drm/exynos: Deal with g2d buffer info more efficiently

From: YoungJun Cho yj44@samsung.com This patch adds g2d_buf_info structure and buffer relevant variables moves into the g2d_buf_info to manage g2d buffer information more efficiently. Changelog v2: - Fix merge conflict. Signed-off-by: YoungJun Cho yj44@samsung.com Signed-off-by: Inki

[PATCH v2 7/7] drm/exynos: Check g2d cmd list for g2d restrictions

From: YoungJun Cho yj44@samsung.com This patch checks command list from user for g2d restrictions. For now, g2d driver wasn't considered for G2D hardware restrictions properly. The below is the restrictions to G2D hardware and this patch considers them. - width or height value in the

[Bug 61690] Graphic issue on PCSX2 with Gallium 0.4 on AMD RS780

https://bugs.freedesktop.org/show_bug.cgi?id=61690 --- Comment #7 from gregory.hain...@gmail.com --- Created attachment 76524 -- https://bugs.freedesktop.org/attachment.cgi?id=76524action=edit texture rounded -- You are receiving this mail because: You are the assignee for the bug.

[Bug 61690] Graphic issue on PCSX2 with Gallium 0.4 on AMD RS780

https://bugs.freedesktop.org/show_bug.cgi?id=61690 --- Comment #8 from gregory.hain...@gmail.com --- Created attachment 76525 -- https://bugs.freedesktop.org/attachment.cgi?id=76525action=edit texture good Hello Alex, I'm a developper of PCSX2 and made some tests on my side. I think I

i915 drm oopses while fuzzing

Hi, I saw these i915 oopses while fuzzing with trinity. The kernel is mainline v3.9-rc2-188-g6c23cbb, along with these two patches from Dave Airlie applied: [PATCH 1/2] drm: fix idr_remove warning during fuzzing [PATCH 2/2] drm: don't oops in ioctls that require the lock if no lock [

Re: [PATCH 1/2] drm/radeon/benchmark: make sure bo blit copy exists before using it

Dear Alex, Am Mittwoch, den 13.03.2013, 12:38 -0400 schrieb alexdeuc...@gmail.com: From: Alex Deucher alexander.deuc...@amd.com Fixes a segfault on asics without a blit callback. so as a result this is not benchmarked for these ASICS, right? Fixes:

Re: [PATCH 2/2] drm/radeon/benchmark: allow same domains for dma copy

Dear Alex, Am Mittwoch, den 13.03.2013, 12:38 -0400 schrieb alexdeuc...@gmail.com: From: Alex Deucher alexander.deuc...@amd.com Remove old comment and allow benchmarking moves within the same memory domain for both dma and blit methods. Signed-off-by: Alex Deucher

Re: [PATCH 1/2] drm/radeon/benchmark: make sure bo blit copy exists before using it

On Thu, Mar 14, 2013 at 9:06 AM, Paul Menzel paulepan...@users.sourceforge.net wrote: Dear Alex, Am Mittwoch, den 13.03.2013, 12:38 -0400 schrieb alexdeuc...@gmail.com: From: Alex Deucher alexander.deuc...@amd.com Fixes a segfault on asics without a blit callback. so as a result this is

Re: [PATCH 2/2] drm/radeon/benchmark: allow same domains for dma copy

On Thu, Mar 14, 2013 at 9:07 AM, Paul Menzel paulepan...@users.sourceforge.net wrote: Dear Alex, Am Mittwoch, den 13.03.2013, 12:38 -0400 schrieb alexdeuc...@gmail.com: From: Alex Deucher alexander.deuc...@amd.com Remove old comment and allow benchmarking moves within the same memory

[PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer

In order to prevent a potential NULL deference with hostile userspace, we need to check whether the ioctl was passed an invalid args pointer. Reported-by: Tommi Rantala tt.rant...@gmail.com Link: http://lkml.kernel.org/r/ca+ydwtpubvbwxbt-tdgpuvj1eu7itmcho_2b3w13hkd5+jw...@mail.gmail.com

Re: [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer

2013/3/14 Chris Wilson ch...@chris-wilson.co.uk: In order to prevent a potential NULL deference with hostile userspace, we need to check whether the ioctl was passed an invalid args pointer. Reported-by: Tommi Rantala tt.rant...@gmail.com Link:

Re: [PATCH 0/2] GEM CMA DMA-BUF support

On Tuesday 12 March 2013 15:45:36 Laurent Pinchart wrote: Hello, This two patches add support for GEM CMA objects import and export as dma-buf file handles. There's not much to be added about the patches themselves, they're pretty self-explicit. The code is based on the Exynos DRM DMA-BUF

Re: [PATCH 4/4] omapdss: features: fixed supported outputs for OMAP4

On 2013-03-12 17:01, Archit Taneja wrote: So, what I'm saying is that we should stick to output-dispc_channel. We iterate through all the panels, and by using output-dispc_channel, we get the manager for an output, and map that manager to a crtc, and make sure the number of unique managers we

Re: linux-next: build failure after merge of the final tree (drm-intel tree related)

On Tue, Mar 12, 2013 at 10:50 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Tue, Mar 12, 2013 at 6:46 AM, Kees Cook keesc...@chromium.org wrote: On Mon, Mar 11, 2013 at 9:22 PM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi all, After merging the final tree, today's linux-next build

[PATCH] drm/exynos: change the method for getting the interrupt resource of FIMD

Replaces the platform_get_resource() for IORESOURCE_IRQ with platform_get_resource_byname(). Both in exynos4 and exynos5, FIMD IP has 3 interrupts in the order: fifo, vsync, and lcd_sys. But The FIMD driver expects the vsync interrupt to be mentioned as the 1st parameter in the FIMD DT node. So to

Re: linux 3.9-rc1: nouveau crash on PPC

Hi, On Sat, Mar 09, 2013 at 08:44:31PM +0200, Aaro Koskinen wrote: There's nouveau crash during boot with 3.9-rc1 on iMac G5 (nVidia GeForce FX 5200 Ultra). This happens also with current mainline kernel HEAD (0aefda3e8188ad71168bd32152d41b3d72f04087). git bisect tells the first bad commit

Re: OOPS with 3.9.0rc2+

On Wed, Mar 13, 2013 at 11:44 PM, Borislav Petkov b...@alien8.de wrote: + dri-devel. On Wed, Mar 13, 2013 at 02:34:31PM +0100, Rolf Offermanns wrote: Hi, I get a kernel oops / panic with a 3.9.0rc2+ kernel (git from 2h ago) on my Sony Vaio laptop. It happened with rc1, too.

Re: [PATCH v3] drm/i915: bounds check execbuffer relocation count

On Wed, Mar 13, 2013 at 9:28 PM, Daniel Vetter dan...@ffwll.ch wrote: On Tue, Mar 12, 2013 at 09:07:46AM +, Chris Wilson wrote: On Mon, Mar 11, 2013 at 05:31:45PM -0700, Kees Cook wrote: It is possible to wrap the counter used to allocate the buffer for relocation copies. This could lead

[PATCH 2/2] ppc64: Add arch-specific pcie_get_speed_cap_mask

From: Lucas Kannebley Tavares luca...@linux.vnet.ibm.com Betters support for gen2 speed detections on PCI buses on ppc64 architectures. Signed-off-by: Lucas Kannebley Tavares luca...@linux.vnet.ibm.com --- arch/powerpc/platforms/pseries/pci.c | 32 1 files

[PATCH 1/2] drm: Move drm_pcie_get_speed_cap_mask to PCI

From: Lucas Kannebley Tavares luca...@linux.vnet.ibm.com This function was more architecture related than drm related, as such it was moved to the PCI driver. This patch also allows it to be overwritten by architecture-dependent implementations, and fixes the radeon driver (only one that uses

PCI Speed Cap Fixes for ppc64

This patch series at first moves get_speed_cap_mask from DRM to PCI, fixes all radeon references (only driver that uses it) and then implements a architecture specific implementation for ppc64 for it. This is good because the drm_pcie_get_speed_cap_mask function is more architecture goo than

[Bug 42960] Display does not work when resuming from suspend

https://bugs.freedesktop.org/show_bug.cgi?id=42960 --- Comment #6 from interwe...@yahoo.ca --- Just a reminder, please try to fix this bug. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list

Re: [PATCH v2 3/3] ARM: shmobile: marzen: Add Display Unit support

Hi Sergei, On Thursday 14 March 2013 21:34:52 Sergei Shtylyov wrote: On 14-03-2013 18:35, Laurent Pinchart wrote: Only the DU0 VGA output is currently supported. Support for the DU0 LVDS and DU1 LVDS outputs will require information about the panels that will be connected to those outputs.

[Bug 60802] Corruption with DMA ring on cayman

https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #50 from Anthony Waters awate...@gmail.com --- I believe I have the source of the bug, it appears that there is a special case for Caymen GPUs that isn't handled in the DMA code path. In evergreen_state.c within the method

[Bug 60802] Corruption with DMA ring on cayman

https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #51 from Alex Deucher ag...@yahoo.com --- Created attachment 76544 -- https://bugs.freedesktop.org/attachment.cgi?id=76544action=edit set non_disp tiling bit for cayman Good catch! I believe the attached patch should fix the

[Bug 60802] Corruption with DMA ring on cayman

https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #52 from Alexandre Demers alexandre.f.dem...@gmail.com --- (In reply to comment #51) Created attachment 76544 [details] [review] set non_disp tiling bit for cayman Good catch! I believe the attached patch should fix the issue.

[Bug 60802] Corruption with DMA ring on cayman

https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #53 from Alexandre Demers alexandre.f.dem...@gmail.com --- (In reply to comment #50) I believe I have the source of the bug, it appears that there is a special case for Caymen GPUs that isn't handled in the DMA code path. In

Re: [PATCH v2 3/3] ARM: shmobile: marzen: Add Display Unit support

On Friday 15 March 2013 02:11:05 Sergei Shtylyov wrote: On 15.03.2013 0:11, Laurent Pinchart wrote: Only the DU0 VGA output is currently supported. Support for the DU0 LVDS and DU1 LVDS outputs will require information about the panels that will be connected to those outputs.

Re: [pull] drm-intel-next

On Thu, Sep 13, 2012 at 7:18 AM, Daniel Vetter dan...@ffwll.ch wrote: Hi Dave, The big ticket item here is the new i915 modeset infrastructure. Shockingly it didn't not blow up all over the place (i.e. I've managed to fix the ugly issues before merging). 1-2 smaller corner cases broke, but

[Bug 60802] Corruption with DMA ring on cayman

hat kind exactly is to be determined. -- 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/20130314/bb464fe4/attachment.html>

[PATCH 3/7] drm/exynos: Fix G2D core mulfunctioning issue

On 03/13/2013 07:53 PM, Inki Dae wrote: >> -Original Message- >> From: Joonyoung Shim [mailto:jy0922.shim at samsung.com] >> Sent: Wednesday, March 13, 2013 7:28 PM >> To: Inki Dae >> Cc:airlied at linux.ie;dri-devel at lists.freedesktop.org; >> kyungmin.park at samsung.com;sw0312.kim at

[Bug 60802] Corruption with DMA ring on cayman

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130314/b7cc0148/attachment.html>

[Bug 60802] Corruption with DMA ring on cayman

e moment. -- 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/20130314/f8cb415e/attachment-0001.html>

[Bug 60802] Corruption with DMA ring on cayman

for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130314/dfce4981/attachment.html>

[PATCH 3/7] drm/exynos: Fix G2D core mulfunctioning issue

> -Original Message- > From: Joonyoung Shim [mailto:jy0922.shim at samsung.com] > Sent: Thursday, March 14, 2013 11:30 AM > To: Inki Dae > Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org; > kyungmin.park at samsung.com; sw0312.kim at samsung.com; 'YoungJun Cho' > Subject: Re:

[PATCH 3/7] drm/exynos: Fix G2D core mulfunctioning issue

;> -#define G2D_USET_HOLD (1 << 2) > > >>>>> +#define G2D_USER_HOLD (1 << 2) > > >>>>> #define G2D_LIST_HOLD (1 << 1) > > >>>>> #define G2D_BITBLT_HOLD (1 << 0) > > >>>>> > > >>>>> @@ -863,10 +863,13 @@ int exynos_g2d_set_cmdlist_ioctl(struct > > >> drm_device > > >>>> *drm_dev, void *data, > > >>>>> cmdlist->data[cmdlist->last++] = G2D_SRC_BASE_ADDR; > > >>>>> cmdlist->data[cmdlist->last++] = 0; > > >>>>> > > >>>>> - if (node->event) { > > >>>>> - cmdlist->data[cmdlist->last++] = G2D_DMA_HOLD_CMD; > > >>>>> - cmdlist->data[cmdlist->last++] = G2D_LIST_HOLD; > > >>>>> - } > > >>>>> + /* > > >>>>> +* 'LIST_HOLD' command should be set to the DMA_HOLD_CMD_REG > > >>>>> +* if user wants G2D interrupt event once each command list > > or > > >>>>> +* BitBLT command execution is finished. > > >>>>> +*/ > > >>>>> + cmdlist->data[cmdlist->last++] = G2D_DMA_HOLD_CMD; > > >>>>> + cmdlist->data[cmdlist->last++] = G2D_LIST_HOLD; > > >>>>> > > >>>>> /* Check size of cmdlist: last 2 is about G2D_BITBLT_START > > > */ > > >>>>> size = cmdlist->last + req->cmd_nr * 2 + req->cmd_buf_nr * 2 > > > + 2; > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130314/f708cda7/attachment-0001.html>

[PATCH RFC] drm/exynos: hdmi: move hdmiphy related code to hdmiphy driver

On Tue, Mar 12, 2013 at 5:37 PM, Inki Dae wrote: > 2013/3/12 Rahul Sharma : >> On Mon, Mar 4, 2013 at 7:35 PM, Rahul Sharma wrote: >>> Thanks Sean, >>> >>> On Wed, Feb 27, 2013 at 9:47 PM, Sean Paul wrote: On Wed, Feb 27, 2013 at 8:22 AM, Rahul Sharma >>> samsung.com> wrote: > Right

[PATCH v2 0/7] Consider G2D hardware restrictions.

This patch set checks the contents of g2d command list from user is valid or not according to G2D hardware restrictions. For now, G2D driver wasn't considered for them properly. For this, this patch set includes relevant code cleaups, fixups and adds a new function to get buffer size to the gem

[PATCH v2 3/7] drm/exynos: Fix G2D core malfunctioning issue

From: YoungJun Cho This patch fixes G2D core malfunctioning issue once g2d dma is started. Without 'DMA_HOLD_CMD_REG' register setting, there is only one interrupt after the execution to all command lists have been completed. And that induces watchdog. So this patch sets

[PATCH v2 4/7] drm/exynos: Clean up some G2D codes for readability

From: YoungJun Cho This patch just cleans up G2D codes for readability. For this, it changes the member of g2d_cmdlist_node, obj_type into buf_type. Changelog v2: - Revert irrelevant codes. Signed-off-by: YoungJun Cho Signed-off-by: Inki Dae Signed-off-by: Kyungmin

[PATCH v2 5/7] drm/exynos: Deal with g2d buffer info more efficiently

From: YoungJun Cho This patch adds g2d_buf_info structure and buffer relevant variables moves into the g2d_buf_info to manage g2d buffer information more efficiently. Changelog v2: - Fix merge conflict. Signed-off-by: YoungJun Cho Signed-off-by: Inki Dae Signed-off-by:

[PATCH v2 7/7] drm/exynos: Check g2d cmd list for g2d restrictions

From: YoungJun Cho This patch checks command list from user for g2d restrictions. For now, g2d driver wasn't considered for G2D hardware restrictions properly. The below is the restrictions to G2D hardware and this patch considers them. - width or height value in the

[Bug 61690] Graphic issue on PCSX2 with Gallium 0.4 on AMD RS780

bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130314/71088033/attachment.html>

[Bug 61690] Graphic issue on PCSX2 with Gallium 0.4 on AMD RS780

URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130314/0deda877/attachment.html>

i915 drm oopses while fuzzing

Hi, I saw these i915 oopses while fuzzing with trinity. The kernel is mainline v3.9-rc2-188-g6c23cbb, along with these two patches from Dave Airlie applied: [PATCH 1/2] drm: fix idr_remove warning during fuzzing [PATCH 2/2] drm: don't oops in ioctls that require the lock if no lock [

[PATCH 1/2] drm/radeon/benchmark: make sure bo blit copy exists before using it

t attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130314/f12740fa/attachment.pgp>

[PATCH 2/2] drm/radeon/benchmark: allow same domains for dma copy

ature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130314/70734f72/attachment.pgp>

[PATCH 1/2] drm/radeon/benchmark: make sure bo blit copy exists before using it

On Thu, Mar 14, 2013 at 9:06 AM, Paul Menzel wrote: > Dear Alex, > > > Am Mittwoch, den 13.03.2013, 12:38 -0400 schrieb alexdeucher at gmail.com: >> From: Alex Deucher >> >> Fixes a segfault on asics without a blit callback. > > so as a result this is not benchmarked for these ASICS, right?

[PATCH 2/2] drm/radeon/benchmark: allow same domains for dma copy

On Thu, Mar 14, 2013 at 9:07 AM, Paul Menzel wrote: > Dear Alex, > > > Am Mittwoch, den 13.03.2013, 12:38 -0400 schrieb alexdeucher at gmail.com: >> From: Alex Deucher >> >> Remove old comment and allow benchmarking moves within the >> same memory domain for both dma and blit methods. >> >>

[PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer

In order to prevent a potential NULL deference with hostile userspace, we need to check whether the ioctl was passed an invalid args pointer. Reported-by: Tommi Rantala Link: http://lkml.kernel.org/r/CA+ydwtpuBvbwxbt-tdgPUvj1EU7itmCHo_2B3w13HkD5+jWKow at mail.gmail.com Signed-off-by: Chris

[PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer

2013/3/14 Chris Wilson : > In order to prevent a potential NULL deference with hostile userspace, > we need to check whether the ioctl was passed an invalid args pointer. > > Reported-by: Tommi Rantala > Link: > http://lkml.kernel.org/r/CA+ydwtpuBvbwxbt-tdgPUvj1EU7itmCHo_2B3w13HkD5+jWKow > at

[PATCH 0/2] GEM CMA DMA-BUF support

On Tuesday 12 March 2013 15:45:36 Laurent Pinchart wrote: > Hello, > > This two patches add support for GEM CMA objects import and export as > dma-buf file handles. > > There's not much to be added about the patches themselves, they're pretty > self-explicit. The code is based on the Exynos DRM

OOPS with 3.9.0rc2+

On Wed, Mar 13, 2013 at 11:44 PM, Borislav Petkov wrote: > + dri-devel. > > On Wed, Mar 13, 2013 at 02:34:31PM +0100, Rolf Offermanns wrote: >> Hi, >> >> I get a kernel oops / panic with a 3.9.0rc2+ kernel (git from 2h ago) on my >> Sony >> Vaio laptop. It happened with rc1, too. >> >>

[PATCH v3] drm/i915: bounds check execbuffer relocation count

On Wed, Mar 13, 2013 at 9:28 PM, Daniel Vetter wrote: > On Tue, Mar 12, 2013 at 09:07:46AM +, Chris Wilson wrote: >> On Mon, Mar 11, 2013 at 05:31:45PM -0700, Kees Cook wrote: >> > It is possible to wrap the counter used to allocate the buffer for >> > relocation copies. This could lead to

[PATCH 2/2] ppc64: Add arch-specific pcie_get_speed_cap_mask

From: Lucas Kannebley Tavares Betters support for gen2 speed detections on PCI buses on ppc64 architectures. Signed-off-by: Lucas Kannebley Tavares --- arch/powerpc/platforms/pseries/pci.c | 32 1 files changed, 32 insertions(+),

[PATCH 1/2] drm: Move drm_pcie_get_speed_cap_mask to PCI

From: Lucas Kannebley Tavares This function was more architecture related than drm related, as such it was moved to the PCI driver. This patch also allows it to be overwritten by architecture-dependent implementations, and fixes the radeon driver (only one that uses

PCI Speed Cap Fixes for ppc64

This patch series at first moves get_speed_cap_mask from DRM to PCI, fixes all radeon references (only driver that uses it) and then implements a architecture specific implementation for ppc64 for it. This is good because the drm_pcie_get_speed_cap_mask function is more architecture goo than

[Bug 42960] Display does not work when resuming from suspend

: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130314/c6ea6fa7/attachment.html>

[PATCH v2 3/3] ARM: shmobile: marzen: Add Display Unit support

Hi Sergei, On Thursday 14 March 2013 21:34:52 Sergei Shtylyov wrote: > On 14-03-2013 18:35, Laurent Pinchart wrote: > > Only the DU0 VGA output is currently supported. Support for the DU0 LVDS > > and DU1 LVDS outputs will require information about the panels that will > > be connected to those

[pull] drm-intel-next

On Thu, Sep 13, 2012 at 7:18 AM, Daniel Vetter wrote: > Hi Dave, > > The big ticket item here is the new i915 modeset infrastructure. > Shockingly it didn't not blow up all over the place (i.e. I've managed to > fix the ugly issues before merging). 1-2 smaller corner cases broke, but > we have

[Intel-gfx] [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer

On Thu, Mar 14, 2013 at 12:59:57PM +, Chris Wilson wrote: > In order to prevent a potential NULL deference with hostile userspace, > we need to check whether the ioctl was passed an invalid args pointer. > > Reported-by: Tommi Rantala > Link: >

[Intel-gfx] [PATCH] drm/i915: Sanity check incoming ioctl data for a NULL pointer

On Thu, Mar 14, 2013 at 12:59:57PM +, Chris Wilson wrote: > In order to prevent a potential NULL deference with hostile userspace, > we need to check whether the ioctl was passed an invalid args pointer. > > Reported-by: Tommi Rantala > Link: >

[PATCH 1/2] drm: Move drm_pcie_get_speed_cap_mask to PCI

On Thu, Mar 14, 2013 at 02:45:46PM -0300, lucaskt at linux.vnet.ibm.com wrote: > From: Lucas Kannebley Tavares > > This function was more architecture related than drm related, as such it was > moved to the PCI driver. > > This patch also allows it to be overwritten by architecture-dependent >

[PATCH v2 0/3] R-Car Display Unit DRM driver

Hello, Here's the second version of the Renesas R-Car Display Unit (DU) DRM driver. The DU features two superposition processors (modeled as CRTCs) and eight planes that can be shared between the superposition processors. The driver supports the superposition processors, all eight planes and

[PATCH v2 1/3] r8a7779: Add Display Unit clock support

From: Phil Edworthy Signed-off-by: Phil Edworthy [Rename device from to rcarfb to rcar-du] Signed-off-by: Laurent Pinchart --- arch/arm/mach-shmobile/clock-r8a7779.c | 4 +++- 1 file changed, 3 insertions(+), 1

[PATCH v2 3/3] ARM: shmobile: marzen: Add Display Unit support

Only the DU0 VGA output is currently supported. Support for the DU0 LVDS and DU1 LVDS outputs will require information about the panels that will be connected to those outputs. Signed-off-by: Laurent Pinchart --- arch/arm/configs/marzen_defconfig

[PATCH v2 2/3] drm: Renesas R-Car Display Unit DRM driver

The R-Car Display Unit (DU) DRM driver supports both superposition processors and all eight planes in RGB and YUV formats without alpha blending. Only VGA and LVDS encoders and connectors are currently supported. Signed-off-by: Laurent Pinchart ---

[PATCH v2 3/3] ARM: shmobile: marzen: Add Display Unit support

Hello. On 14-03-2013 18:35, Laurent Pinchart wrote: > Only the DU0 VGA output is currently supported. Support for the DU0 LVDS > and DU1 LVDS outputs will require information about the panels that will > be connected to those outputs. > Signed-off-by: Laurent Pinchart

[PATCH 2/2] ppc64: Add arch-specific pcie_get_speed_cap_mask

On Thu, Mar 14, 2013 at 02:45:47PM -0300, lucaskt at linux.vnet.ibm.com wrote: > From: Lucas Kannebley Tavares > > Betters support for gen2 speed detections on PCI buses on ppc64 > architectures. > > Signed-off-by: Lucas Kannebley Tavares > --- > arch/powerpc/platforms/pseries/pci.c | 32

[PATCH v3] drm/i915: bounds check execbuffer relocation count

On Thu, Mar 14, 2013 at 9:57 AM, Daniel Vetter wrote: > On Wed, Mar 13, 2013 at 9:28 PM, Daniel Vetter wrote: >> On Tue, Mar 12, 2013 at 09:07:46AM +, Chris Wilson wrote: >>> On Mon, Mar 11, 2013 at 05:31:45PM -0700, Kees Cook wrote: >>> > It is possible to wrap the counter used to allocate