mmap fails for DRM_IOCTL_MODE_MAP_DUMB for Radeon, Nouveau, and VMWGFX

On 11 November 2014 06:33, Rian Quinn wrote: > I did another test using the following that David put up on github: > > https://github.com/dvdhrm/docs/blob/master/drm-howto/modeset.c > > This test also fails on everything except Intel. What's really strange is > this test actually does a test to

[PATCH v5 00/24] AMDKFD Kernel Driver

>> How does amdkfd interfact with runtime pm on the radeon driver? I'd expect >> some calls to the runtime get/put functions in some places. >> >> Dave. >> > Hi Dave, > Per Jerome's request from the first time he saw the driver, we removed all > the "register bashing" code from amdkfd and moved

mmap fails for DRM_IOCTL_MODE_MAP_DUMB for Radeon, Nouveau, and VMWGFX

On 11 November 2014 07:33, Rian Quinn wrote: > I would be surprised if the size argument was the issue. That comes right > out out of the create IOCTL unmodified. Here is the full source that I am > using. > > // Clear the arg buffers. > memset(_arg, 0, sizeof(create_arg)); >

[PATCH 2/2] drm/edid: fix Baseline_ELD_Len field in drm_edid_to_eld()

On Mon, Nov 10, 2014 at 11:39 PM, Daniel Vetter wrote: > Hi Ben, > > The below patch from Jani also touches nouveau, can you please take a > look at it an ack? The core part + nouveau apply on top of drm-next, > the i915 part needs stuff from my next queue. So I'd prefer if we can > get this in

[PATCH 2/2] drm/edid: fix Baseline_ELD_Len field in drm_edid_to_eld()

On Tue, Oct 28, 2014 at 04:20:48PM +0200, Jani Nikula wrote: > The Baseline_ELD_Len field does not include ELD Header Block size. > > From High Definition Audio Specification, Revision 1.0a: > > The header block is a fixed size of 4 bytes. The baseline block > is variable size in

[PATCH] drm/radeon: add locking around atombios scratch space usage

From: Dave Airlie While developing MST support I noticed I often got the wrong data back from a transaction, in a racy fashion. I noticed the scratch space wasn't locked against concurrent users. Based on a patch by Alex, but I've made it a bit more obvious when things are

[PATCH] drm: export atomic wait_for_vblanks helper

On Mon, Nov 10, 2014 at 10:59:23AM -0500, Rob Clark wrote: > Signed-off-by: Rob Clark > --- > I'll need this helper for msm async commit, and I suspect other > drivers will as well. Yeah, makes sense. Some nits to clarify the kerneldoc below, with that addressed this is Reviewed-by: Daniel

[Bug 86133] Graphics Driver Fails to Restart Post Suspend

You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2014/53077a15/attachment.html>

[Bug 75276] Implement VGPR Register Spilling

but I see no special wine error on the console. -- 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/2014/6353d246/attachment.html>

[Bug 86133] Graphics Driver Fails to Restart Post Suspend

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141111/07114456/attachment-0001.html>

[Bug 79659] R9 270X lockup with unigine valley since radeonsi: enable ARB_sample_shading

vel/attachments/20141111/2bfd6762/attachment.html>

[Bug 86133] Graphics Driver Fails to Restart Post Suspend

has completely woken up. -- 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/2014/42a6adc0/attachment.html>

[Bug 86133] Graphics Driver Fails to Restart Post Suspend

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

[Bug 86133] Graphics Driver Fails to Restart Post Suspend

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

[Bug 85647] Random radeonsi crashes with mesa 10.3.x

ing 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/2014/942505dc/attachment.html>

[Bug 85647] Random radeonsi crashes with mesa 10.3.x

. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2014/ab1fd9b5/attachment.html>

[PATCH 1/2] drm: Per-plane locking

Turned out to be much simpler on top of my latest atomic stuff than what I've feared. Some details: - Drop the modeset_lock_all snakeoil in drm_plane_init. Same justification as for the equivalent change in drm_crtc_init done in commit d0fa1af40e784aaf7ebb7ba8a17b229bb3fa4c21

[PATCH 2/2] drm: More specific locking for get* ioctls

Motivated by the per-plane locking I've gone through all the get* ioctls and reduced the locking to the bare minimum required. v2: Rebase and make it compile ... Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc.c | 46 ++ 1 file changed, 18

How to handle planes/fbs when disabling the crtc? (was Re: [Intel-gfx] [PATCH] drm/i915: use the correct obj when preparing the sprite plane)

On Mon, Nov 10, 2014 at 07:15:04PM +0200, Ville Syrjälä wrote: > As a side note if someone is looking for stuff to do, then the pin/unpin > logic might be good thing to look at. We're currently a bit inconsistent > whether we have the buffer pinned when the plane is disabled, or just > otherwise

[Bug 79980] Random radeonsi crashes

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141111/e21bec1c/attachment.html>

[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!

647. -- 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/2014/184e52cc/attachment.html>

[Bug 84944] tearing on radeonsi vdpau deinterlacer

se: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2014/45c00199/attachment.html>

[Bug 85647] Random radeonsi crashes with mesa 10.3.x

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/2014/a71ee986/attachment-0001.html>

[Bug 85647] Random radeonsi crashes with mesa 10.3.x

URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2014/95e8f62f/attachment.html>

mmap fails for DRM_IOCTL_MODE_MAP_DUMB for Radeon, Nouveau, and VMWGFX

READ | PROT_WRITE, >> > MAP_SHARED, gpu->fd(), map_arg.offset)) == MAP_FAILED) >> > { >> > // Need to clear out the address so that we don't try to use it. >> > mVaddr = NULL; >> > >> > // Error out. >> > svWarning(0) << "Failed: Dumb Buffer mmap - " << >> strerror(errno); >> > return; >> > } >> > >> >> mmap is probably truncating the offset, >> >> look into, >> #define _FILE_OFFSET_BITS 64 >> >> AC_SYS_LARGEFILE >> >> Dave. >> > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2014/14cfd0d7/attachment.html>

[Bug 86130] Some textures are not rendering correctly in apitrace but are fine while capturing

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141111/fc544fcd/attachment.html>

Nouveau dumb buffer bug

uffer(4096, 4096); allocate_buffer(4096, 4096); close(fd); } -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2014/e14bd5b1/attachment-0001.html>

[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!

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

[Bug 86130] Some textures are not rendering correctly in apitrace but are fine while capturing

use: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2014/85f3baad/attachment.html>

[PATCH v7 5/7] drm: bridge/dw-hdmi: add support for multi byte register width access

Am Dienstag, den 11.11.2014, 14:20 + schrieb Zubair Lutfullah Kakakhel: > Hi Andy, > > This patch adds the reg-io-width binding. > > Hence the binding patch should come before it. > > > On 11/11/14 12:53, Andy Yan wrote: > > On rockchip rk3288, only word(32-bit) accesses are > > permitted

[Bug 86133] Graphics Driver Fails to Restart Post Suspend

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141111/d50a2b06/attachment.html>

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

vel/attachments/20141111/0599ebcb/attachment.html>

[PATCH v3.18-rc3] drm: msm: Allow exported dma-bufs to be mapped

On 10/11/14 17:36, Rob Clark wrote: > On Mon, Nov 10, 2014 at 12:16 PM, Daniel Thompson > wrote: >> diff --git a/drivers/gpu/drm/msm/msm_gem_prime.c >> b/drivers/gpu/drm/msm/msm_gem_prime.c >> index ad772fe36115..4e4fa5828d5d 100644 >> --- a/drivers/gpu/drm/msm/msm_gem_prime.c >> +++

[Intel-gfx] [PATCH 1/2] drm: Per-plane locking

On Tue, Nov 11, 2014 at 10:12:00AM +0100, Daniel Vetter wrote: > Turned out to be much simpler on top of my latest atomic stuff than > what I've feared. Some details: > > - Drop the modeset_lock_all snakeoil in drm_plane_init. Same > justification as for the equivalent change in drm_crtc_init

[Intel-gfx] [PATCH 2/2] drm: More specific locking for get* ioctls

On Tue, Nov 11, 2014 at 10:12:01AM +0100, Daniel Vetter wrote: > Motivated by the per-plane locking I've gone through all the get* > ioctls and reduced the locking to the bare minimum required. > > v2: Rebase and make it compile ... > > Signed-off-by: Daniel Vetter Just a couple nits. > --- >

[PATCH v3.18-rc3] drm: msm: Allow exported dma-bufs to be mapped

On Tue, Nov 11, 2014 at 9:28 AM, Daniel Thompson wrote: > On 10/11/14 17:36, Rob Clark wrote: >> On Mon, Nov 10, 2014 at 12:16 PM, Daniel Thompson >> wrote: >>> diff --git a/drivers/gpu/drm/msm/msm_gem_prime.c >>> b/drivers/gpu/drm/msm/msm_gem_prime.c >>> index ad772fe36115..4e4fa5828d5d 100644

[PATCH] drm: More specific locking for get* ioctls

Motivated by the per-plane locking I've gone through all the get* ioctls and reduced the locking to the bare minimum required. v2: Rebase and make it compile ... v3: Review from Sean: - Simplify return handling in getplane_res. - Add a comment to getplane_res that the plane list is invariant and

[RFC PATCH] drm/exynos: Add DECON driver

Hi Inki, On Mon, Nov 3, 2014 at 3:31 PM, Inki Dae wrote: > > Hi, > > Fortunately, I could get the user manual for Exynos7420. Below are my > comments. > > Thanks, > Inki Dae > > On 2014년 10월 23일 01:34, Ajay kumar wrote: >> On Wed, Oct 22, 2014 at 8:26 PM, Inki Dae wrote: >>> >>> Thanks

[Bug 29226] on r600 and llvmpipe 3d applications are rendered in too bright colors

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141111/0c8607f1/attachment.html>

LibDRM Cloned Monitor Support

f to some more basic resolutions (like 800x600). - Rian -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2014/5cf1c594/attachment.html>

[Bug 85376] Dolphin emulator has bad colors

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

[Bug 80004] Serious Sam 3 BFE - incorrect weapon rendering

ves/dri-devel/attachments/2014/eb262e9f/attachment.html>

[Bug 86165] [RV770] [bisected] Bad textures rendering on Serious Sam 3 with sb enabled

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

[Bug 86165] [RV770] [bisected] Bad textures rendering on Serious Sam 3 with sb enabled

vel/attachments/20141111/56f64455/attachment.html>

[Bug 86165] [RV770] [bisected] Bad textures rendering on Serious Sam 3 with sb enabled

You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2014/91a9cc7d/attachment-0001.html>

[Bug 86165] [RV770] [bisected] Bad textures rendering on Serious Sam 3 with sb enabled

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

[Bug 86165] [RV770] [bisected] Bad textures rendering on Serious Sam 3 with sb enabled

ail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2014/cbb52a51/attachment.html>

[Bug 86165] [RV770] [bisected] Bad textures rendering on Serious Sam 3 with sb enabled

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/20141111/0a3e8103/attachment.html>

[Bug 85376] Dolphin emulator has bad colors

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

[PATCH 3/6] x86: Add support for the clwb instruction

On Tue, Nov 11, 2014 at 08:12:39PM +0100, Borislav Petkov wrote: > > +".byte 0x66; xsaveopt %P0", > > Huh, XSAVEOPT?!? Shouldn't that be CLWB?? Bah, the same opcodes, only 0x66 prefix makes it into CLWB. Could use a comment I guess. -- Regards/Gruss, Boris. Sent from a

[PATCH 3/6] x86: Add support for the clwb instruction

On Tue, Nov 11, 2014 at 11:43:13AM -0700, Ross Zwisler wrote: > Add support for the new clwb instruction. This instruction was > announced in the document "Intel Architecture Instruction Set Extensions > Programming Reference" with reference number 319433-022. > >

[Bug 80004] Serious Sam 3 BFE - incorrect weapon rendering

ing 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/2014/05080cfa/attachment-0001.html>

[Bug 80004] Serious Sam 3 BFE - incorrect weapon rendering

|| -- 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/20141111/c83597ff/attachment.html>

[Bug 80004] Serious Sam 3 BFE - incorrect weapon rendering

scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2014/de5b224c/attachment.html>

[Bug 85491] radeon 0000:01:00.0: Fatal error during GPU init

https://bugzilla.kernel.org/show_bug.cgi?id=85491 Marek changed: What|Removed |Added CC||kordikmarek at gmail.com --- Comment #10 from

[Bug 85491] radeon 0000:01:00.0: Fatal error during GPU init

https://bugzilla.kernel.org/show_bug.cgi?id=85491 --- Comment #11 from Marek --- Created attachment 157331 --> https://bugzilla.kernel.org/attachment.cgi?id=157331=edit logs for last working kernel -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 85491] radeon 0000:01:00.0: Fatal error during GPU init

https://bugzilla.kernel.org/show_bug.cgi?id=85491 --- Comment #12 from Marek --- Created attachment 157341 --> https://bugzilla.kernel.org/attachment.cgi?id=157341=edit logs for first not working kernel -- You are receiving this mail because: You are watching the assignee of the bug.

[PATCH 3/6] x86: Add support for the clwb instruction

On Tue, Nov 11, 2014 at 12:40:00PM -0700, Ross Zwisler wrote: > Yep, it's weird, I know. :) But sure, saving opcode space, makes sense to me. Btw, I'd still be interested about this: > +static inline void clwb(volatile void *__p) > +{ > + alternative_io_2(".byte "

[Bug 82441] [gma500] Dell Inspiron Mini 1010 black screen after boot

||g/show_bug.cgi?id=86169 -- 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/20141111/559af

[Bug 82441] [gma500] Dell Inspiron Mini 1010 black screen after boot

=86169 | -- 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/20141111/8446bd0f/attachment-0001.html>

[PATCH 3/6] x86: Add support for the clwb instruction

On Tue, Nov 11, 2014 at 12:48:52PM -0700, Ross Zwisler wrote: > Essentially we need one additional byte at the beginning of the clflush so > that we can flip it into a clflushopt by changing that byte into a 0x66 > prefix. Two options are to either insert a 1 byte ASM_NOP1, or to add a 1 > byte

[Bug 85376] Dolphin emulator has bad colors

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

[Bug 80004] Serious Sam 3 BFE - incorrect weapon rendering

77288... -- 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/20141111/768359ea/attachment.html>

[Bug 86038] [radeonsi] Dreamfall Chapters: heavy visual corruption, large parts of the screen are black in some scenes

answered both your questions by private e-mail. -- 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/2014/651a2ddf/attachment.html>

Crash of radeon_ttm_tt_unpopulate in ttm_dma_unpopulate with

Marcus -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/2014/c76b08bf/attachment.html>

[PATCH v7 6/7] drm: bridge/dw-hdmi: convert dw-hdmi to drm_bridge mode

From: Yakir Yang keep the connector & birdge in dw_hdmi.c, handle encoder in dw_hdmi-imx.c Signed-off-by: Andy Yan Signed-off-by: Yakir Yang --- Changes in v7: None Changes in v6: - move some modification from patch#5 Changes in v5: None Changes in v4: None Changes in

[PATCH v7 0/7] dw-hdmi: convert imx hdmi to bridge/dw-hdmi

We found freescale imx5 and rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS) use the interface compatible Designware HDMI IP, but they also have some lightly differences, such as phy pll configuration, register width(imx hdmi register is one byte, but rk3288 is 4 bytes width and can only access

[PATCH v7 5/7] drm: bridge/dw-hdmi: add support for multi byte register width access

On rockchip rk3288, only word(32-bit) accesses are permitted for hdmi registers. Byte width accesses (writeb, readb) generate an imprecise external abort. Signed-off-by: Andy Yan --- Changes in v7: None Changes in v6: - move some modification to patch#6 - refactor register access without

[PATCH v7 0/7] dw-hdmi: convert imx hdmi to bridge/dw-hdmi

We found freescale imx5 and rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS) use the interface compatible Designware HDMI IP, but they also have some lightly differences, such as phy pll configuration, register width(imx hdmi register is one byte, but rk3288 is 4 bytes width and can only access

[PATCH v7 1/7] staging: imx-drm: imx-hdmi: make checkpatch happy

CHECK: Alignment should match open parenthesis + if ((hdmi->vic == 10) || (hdmi->vic == 11) || + (hdmi->vic == 12) || (hdmi->vic == 13) || CHECK: braces {} should be used on all arms of this statement + if (hdmi->hdmi_data.video_mode.mdvi) [...] + else { [...]

[PATCH v7 2/7] staging: imx-drm: imx-hdmi: return defer if can't get ddc i2c adapter

drm driver may probe before the i2c bus, so the driver should defer probing until it is available Signed-off-by: Andy Yan --- Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: - defer probe ddc i2c adapter Changes in v3: None Changes in v2: None

[PATCH v7 3/7] staging: imx-drm: imx-hdmi: split imx soc specific code from imx-hdmi

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

[PATCH v7 5/7] drm: bridge/dw-hdmi: add support for multi byte register width access

On rockchip rk3288, only word(32-bit) accesses are permitted for hdmi registers. Byte width accesses (writeb, readb) generate an imprecise external abort. Signed-off-by: Andy Yan --- Changes in v7: None Changes in v6: - move some modification to patch#6 - refactor register access without

[PATCH v7 6/7] drm: bridge/dw-hdmi: convert dw-hdmi to drm_bridge mode

From: Yakir Yang keep the connector & birdge in dw_hdmi.c, handle encoder in dw_hdmi-imx.c Signed-off-by: Andy Yan Signed-off-by: Yakir Yang --- Changes in v7: None Changes in v6: - move some modification from patch#5 Changes in v5: None Changes in v4: None Changes in

[PATCH v7 7/7] dt-bindings: add document for dw-hdmi

Signed-off-by: Andy Yan --- Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None .../devicetree/bindings/drm/bridge/dw-hdmi.txt | 38 ++ 1 file changed, 38 insertions(+) create mode 100644

[PATCH v7 4/7] staging: imx-drm: imx-hdmi: move imx-hdmi to bridge/dw-hdmi

Hi Andy, On 11/11/14 12:53, Andy Yan wrote: > the original imx hdmi driver is under staging/imx-drm, > which depends on imx-drm, so move the imx hdmi drvier out Spelling mistake. ^'driver' > to drm/bridge and rename imx-hdmi to dw-hdmi

[PATCH v7 5/7] drm: bridge/dw-hdmi: add support for multi byte register width access

Hi Andy, This patch adds the reg-io-width binding. Hence the binding patch should come before it. On 11/11/14 12:53, Andy Yan wrote: > On rockchip rk3288, only word(32-bit) accesses are > permitted for hdmi registers. Byte width accesses (writeb, > readb) generate an imprecise external abort.

[PATCH v7 5/7] drm: bridge/dw-hdmi: add support for multi byte register width access

On 11/11/14 14:23, Lucas Stach wrote: > Am Dienstag, den 11.11.2014, 14:20 + schrieb Zubair Lutfullah > Kakakhel: >> Hi Andy, >> >> This patch adds the reg-io-width binding. >> >> Hence the binding patch should come before it. >> >> >> On 11/11/14 12:53, Andy Yan wrote: >>> On rockchip

[PATCH v7 7/7] dt-bindings: add document for dw-hdmi

Hi Andy, Some minor comments inline. On 11/11/14 12:54, Andy Yan wrote: > Signed-off-by: Andy Yan > --- > > Changes in v7: None > Changes in v6: None > Changes in v5: None > Changes in v4: None > Changes in v3: None > Changes in v2: None > > .../devicetree/bindings/drm/bridge/dw-hdmi.txt

[PATCH v7 4/7] staging: imx-drm: imx-hdmi: move imx-hdmi to bridge/dw-hdmi

On 2014年11月11日 22:16, Zubair Lutfullah Kakakhel wrote: > Hi Andy, > > On 11/11/14 12:53, Andy Yan wrote: >> the original imx hdmi driver is under staging/imx-drm, >> which depends on imx-drm, so move the imx hdmi drvier out > Spelling mistake. ^'driver' > >> to

[PATCH v7 5/7] drm: bridge/dw-hdmi: add support for multi byte register width access

On 2014年11月11日 22:20, Zubair Lutfullah Kakakhel wrote: > Hi Andy, > > This patch adds the reg-io-width binding. > > Hence the binding patch should come before it. > do you mean that I should put dts binding patch before this patch? > On 11/11/14 12:53, Andy Yan wrote: >> On rockchip

[PATCH v7 5/7] drm: bridge/dw-hdmi: add support for multi byte register width access

On 11/11/14 14:46, Andy Yan wrote: > > On 2014年11月11日 22:20, Zubair Lutfullah Kakakhel wrote: >> Hi Andy, >> >> This patch adds the reg-io-width binding. >> >> Hence the binding patch should come before it. >> >do you mean that I should put dts binding patch >before this patch?

[PATCH v7 6/7] drm: bridge/dw-hdmi: convert dw-hdmi to drm_bridge mode

Hi ZubairLK: On 2014年11月11日 22:36, Zubair Lutfullah Kakakhel wrote: > Hi Andy, > > On 11/11/14 12:54, Andy Yan wrote: >> From: Yakir Yang >> >> keep the connector & birdge in dw_hdmi.c, handle encoder in dw_hdmi-imx.c > Is there a reason for this separation? Keeping encoder in platform

[PATCH 0/6] add support for new persistent memory instructions

This patch set adds support for two new persistent memory instructions, pcommit and clwb. These instructions were announced in the document "Intel Architecture Instruction Set Extensions Programming Reference" with reference number 319433-022.

[PATCH 2/6] x86/alternative: Add alternative_io_2

Add alternative_io_2 in the spirit of alternative_input_2 and alternative_io. This will allow us to have instructions with an output parameter that vary based on two CPU features. Signed-off-by: Ross Zwisler Cc: H Peter Anvin Cc: Ingo Molnar Cc: Thomas Gleixner Cc: David Airlie Cc:

[PATCH 3/6] x86: Add support for the clwb instruction

Add support for the new clwb instruction. This instruction was announced in the document "Intel Architecture Instruction Set Extensions Programming Reference" with reference number 319433-022. https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf Here are some things of

[PATCH 4/6] x86: Use clwb in clflush_cache_range

If clwb is available on the system, use it in clflush_cache_range. If clwb is not available, fall back to clflushopt if you can. If clflushopt is not supported, fall all the way back to clflush. Signed-off-by: Ross Zwisler Cc: H Peter Anvin Cc: Ingo Molnar Cc: Thomas Gleixner Cc: David Airlie

[PATCH 5/6] x86: Use clwb in drm_clflush_page

If clwb is available on the system, use it in drm_clflush_page. If clwb is not available, fall back to clflushopt if you can. If clflushopt is not supported, fall all the way back to clflush. Signed-off-by: Ross Zwisler Cc: H Peter Anvin Cc: Ingo Molnar Cc: Thomas Gleixner Cc: David Airlie

[PATCH 6/6] x86: Use clwb in drm_clflush_virt_range

If clwb is available on the system, use it in drm_clflush_virt_range. If clwb is not available, fall back to clflushopt if you can. If clflushopt is not supported, fall all the way back to clflush. Signed-off-by: Ross Zwisler Cc: H Peter Anvin Cc: Ingo Molnar Cc: Thomas Gleixner Cc: David

[PATCH 3/6] x86: Add support for the clwb instruction

On Tue, 2014-11-11 at 20:12 +0100, Borislav Petkov wrote: > On Tue, Nov 11, 2014 at 11:43:13AM -0700, Ross Zwisler wrote: > > Add support for the new clwb instruction. This instruction was > > announced in the document "Intel Architecture Instruction Set Extensions > > Programming Reference" with

[PATCH 3/6] x86: Add support for the clwb instruction

On Tue, 2014-11-11 at 20:46 +0100, Borislav Petkov wrote: > On Tue, Nov 11, 2014 at 12:40:00PM -0700, Ross Zwisler wrote: > > Yep, it's weird, I know. :) > > But sure, saving opcode space, makes sense to me. > > Btw, I'd still be interested about this: > > > +static inline void clwb(volatile

[PATCH v7 4/7] staging: imx-drm: imx-hdmi: move imx-hdmi to bridge/dw-hdmi

the original imx hdmi driver is under staging/imx-drm, which depends on imx-drm, so move the imx hdmi drvier out to drm/bridge and rename imx-hdmi to dw-hdmi Signed-off-by: Andy Yan --- Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None Changes

[PATCH v7 6/7] drm: bridge/dw-hdmi: convert dw-hdmi to drm_bridge mode

Hi Andy, On 11/11/14 12:54, Andy Yan wrote: > From: Yakir Yang > > keep the connector & birdge in dw_hdmi.c, handle encoder in dw_hdmi-imx.c Is there a reason for this separation? Keeping encoder in platform files? If yes, then the commit message should explain that. > > Signed-off-by: Andy

[PATCH 1/6] x86: Add support for the pcommit instruction

Add support for the new pcommit instruction. This instruction was announced in the document "Intel Architecture Instruction Set Extensions Programming Reference" with reference number 319433-022. https://software.intel.com/sites/default/files/managed/0d/53/319433-022.pdf Signed-off-by: Ross

[PATCH 3/6] x86: Add support for the clwb instruction

On Tue, 2014-11-11 at 20:19 +0100, Borislav Petkov wrote: > On Tue, Nov 11, 2014 at 08:12:39PM +0100, Borislav Petkov wrote: > > > + ".byte 0x66; xsaveopt %P0", > > > > Huh, XSAVEOPT?!? Shouldn't that be CLWB?? > > Bah, the same opcodes, only 0x66 prefix makes it into CLWB.

[PATCH v7 7/7] dt-bindings: add document for dw-hdmi

On 2014年11月11日 22:40, Zubair Lutfullah Kakakhel wrote: > Hi Andy, > > Some minor comments inline. > > On 11/11/14 12:54, Andy Yan wrote: >> Signed-off-by: Andy Yan >> --- >> >> Changes in v7: None >> Changes in v6: None >> Changes in v5: None >> Changes in v4: None >> Changes in v3: None

[Bug 85647] Random radeonsi crashes with mesa 10.3.x

are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141111/4a8d320c/attachment.html>

[Bug 85376] Dolphin emulator has bad colors

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

[PATCH] drm/radeon: add locking around atombios scratch space usage

On Mon, Nov 10, 2014 at 6:16 PM, Dave Airlie wrote: > From: Dave Airlie > > While developing MST support I noticed I often got the wrong data > back from a transaction, in a racy fashion. I noticed the scratch > space wasn't locked against concurrent users. > > Based on a patch by Alex, but I've

[Bug 87891] New: kernel BUG at mm/slab.c:2625!

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Thu, 06 Nov 2014 17:28:41 + bugzilla-daemon at bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=87891 > > Bug ID: 87891 >Summary: kernel BUG

  1   2   >