CONFIG_DMA_CMA causes ttm performance problems/hangs.

Hi all, there is a rather severe performance problem i accidentally found when trying to give Linux 3.16.0 a final test on a x86_64 MacBookPro under Ubuntu 14.04 LTS with nouveau as graphics driver. I was lazy and just installed the Ubuntu precompiled mainline kernel. That kernel happens to

[Bug 79575] [radeonsi] Wine's d3d8 test crashes in SITargetLowering::analyzeImmediate

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

[PATCH] drm: Use the type of the array element when reallocating

Static analysers find it 'suspicious', that we're trying to allocate memory for elements of size sizeof(struct drm_fb_helper_connector) when the array is defined as struct drm_fb_helper_connector **. Use sizeof(struct drm_fb_helper_connector *) instead. Note that the structure being defined as:

[PATCH] drm: Don't return 0 for a value used as a denominator

Static analysis will be unhappy if a function can theoretically return 0 and we're trying to divide by that value. Mark that case that cannot occur as a BUG() instead. Signed-off-by: Damien Lespiau --- drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH] drm/radeon: Always flush VM again on < CIK

On 08.08.2014 17:44, Christian K?nig wrote: On Thu, Aug 7, 2014 at 3:59 PM, Alex Deucher wrote: > We should be using PFP as much as possible. Does the attached > patch help? >> Unfortunately not. > > Maybe add a readback of the VM base addr pointer to make sure that the >

[PATCH] drm/radeon: Read back ring buffer before updating WPTR

From: Michel D?nzer This fixes a ring test failure reported on a Kabini system which was triggered by write-combined CPU mappings of the ring buffers. Reported-and-Tested-by: Will Trives Signed-off-by: Michel D?nzer --- drivers/gpu/drm/radeon/radeon_ring.c | 4 1

Looking for a start point for fixing a bug

I started looking through the code week or so ago. No much progress though but could you explain meaning of this to me: if (running == 0) { if (running) { blackout = RREG32(MC_SHARED_BLACKOUT_CNTL); WREG32(MC_SHARED_BLACKOUT_CNTL, blackout | 1); } ... It's in si.c, line

[Bug 81680] [r600g] Firefox crashes with hardware acceleration turned on

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140808/2b649f23/attachment.html>

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

On 2014? 08? 08? 16:03, Thierry Reding wrote: > On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote: >> On 2014? 08? 07? 22:55, Thierry Reding wrote: >>> On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote: On 2014? 08? 07? 22:17, Thierry Reding wrote: > On Thu, Aug 07, 2014 at

[PULL] drm-intel-fixes

Hi Dave, So I heard that proper pull requests have a revert on top ;-) So here we go with my usual mid-merge-window pile of fixes. Big fix is the duct-tape for ring init on g4x platforms, we seem to have found the magic again to make those machines as happy as before (not perfect though

[PATCH 7/7] drm: Remove old defines for vswing and pre-emph values

From: Sonika Jindal This is the last patch in the series, so remove old defines Signed-off-by: Sonika Jindal --- include/drm/drm_dp_helper.h |8 1 file changed, 8 deletions(-) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index

[PATCH 6/7] drm/tegra: Renaming DP training vswing pre emph defines

From: Sonika Jindal Rename the defines to have levels instead of values for vswing and pre-emph levels as the values may differ in other scenarios like low vswing of eDP1.4 where the values are different. Done using following cocci patch for each define: @@ @@ #

[PATCH 5/7] drm/radeon: Renaming DP training vswing pre emph defines

From: Sonika Jindal Rename the defines to have levels instead of values for vswing and pre-emph levels as the values may differ in other scenarios like low vswing of eDP1.4 where the values are different. Done using following cocci patch for each define: @@ @@ #

[PATCH 4/7] drm/gma500: Renaming DP training vswing pre emph defines

From: Sonika Jindal Rename the defines to have levels instead of values for vswing and pre-emph levels as the values may differ in other scenarios like low vswing of eDP1.4 where the values are different. Done using following cocci patch for each define: @@ @@ #

[PATCH 3/7] drm/exynos: Renaming DP training vswing pre emph defines

From: Sonika Jindal Rename the defines to have levels instead of values for vswing and pre-emph levels as the values may differ in other scenarios like low vswing of eDP1.4 where the values are different. Done using following cocci patch for each define: @@ @@ #

[PATCH 2/7] drm/i915: Renaming DP training vswing pre emph defines

From: Sonika Jindal Rename the defines to have levels instead of values for vswing and pre-emph levels as the values may differ in other scenarios like low vswing of eDP1.4 where the values are different. Done using following cocci patch for each define: @@ @@ #

[PATCH 1/7] drm: Renaming DP training vswing pre emph defines

From: Sonika Jindal Adding new defines, older one will be removed in the last patch in the series. This is to rename the defines to have levels instead of values for vswing and pre-emph levels as the values may differ in other scenarios like low vswing of eDP1.4 where

[PATCH v2 0/7] Rename DP training vswing/pre-emph defines

From: Sonika Jindal Rename the defines to have levels instead of values for vswing and pre-emph levels as the values may differ in other scenarios like low vswing of eDP 1.4 where the values are different. Updated in all the drivers as well v2: Keeping the old defines

[PATCH] drm: Don't grab an fb reference for the idr

On Fri, Aug 8, 2014 at 12:35 PM, David Herrmann wrote: > Ewww, this is ugly. You now make the unregistration dynamic and it's > no longer under driver control. The typical device-control flow > assumes there's an authority that controls at which point objects are > registered and unregistered.

[PATCH 0/9] Beaglebone-Black HDMI audio

Hello Jyri, On 06 Aug 04:47 PM, Jyri Sarha wrote: > The code has a functional dependency to: > http://www.mail-archive.com/linux-omap at vger.kernel.org/msg108199.html > > Without the above patch the audio card does not probe. > > The code has been rebased on top of Linux 3.16 merged with >

[PULL] drm-intel-fixes

On Fri, Aug 8, 2014 at 1:52 PM, Linus Torvalds wrote: > > Got this while bisecting. I'm not sure it's related It's not. The actual bug was panel self refresh. It's still broken, and doesn't work. So enabling it by default was a big mistake (commit b6d547791fd3: "drm/i915: Enable PSR by

Radeon: [TTM] Failed to find memory space for buffer [...] eviction

Hi! I recetly repurposed a BlueMedia OPTIMA II system, Biostar MCP6P M2+ mainboard, AMD Athlon II X2 215 with 2700 MHz, 8 GiB RAM, Xen setup, for use as a desktop machine (the Xen dom0, specifically). I put in a Sapphire Radeon HD 4350 card where I'm connecting the DVI output to a

[PATCH 6/9] ARM: dts: am33xx: Add external clock provider

On 06 Aug 04:47 PM, Jyri Sarha wrote: > Add external clock provaider for am33xx devices. Typo: s/provaider/provider -- Ezequiel Garc?a, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com

[PULL] drm-intel-fixes

On Fri, Aug 8, 2014 at 12:37 PM, Linus Torvalds wrote: > > The problem seems to exist already with just the plain drm pull from > Dave. I thought I had tested that, but apparently not. Still busy bisecting (and it's going into the i915 part of Dave's drm pull, so the bisect looks sane so far),

[PATCH] dma-buf/fence: Fix one more kerneldoc warning

From: Thierry Reding The seqno_fence_init() function's cond argument isn't described in the kerneldoc comment. Fix that to silence a warning when building DocBook documentation. Signed-off-by: Thierry Reding --- include/linux/seqno-fence.h | 1 + 1 file changed, 1

[PATCH] dma-buf/fence: Fix a kerneldoc warning

From: Thierry Reding kerneldoc doesn't know how to parse variables, so don't let it try. Signed-off-by: Thierry Reding --- drivers/dma-buf/fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c index

[PULL] drm-intel-fixes

On Fri, Aug 8, 2014 at 12:19 PM, Linus Torvalds wrote: > On Fri, Aug 8, 2014 at 7:34 AM, Daniel Vetter > wrote: >> >> git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-08-08 > > Hmm. My laptop no longer resumes properly. The problem seems to exist already with just the plain

[PATCH] drm/doc: Refer to proper source file

Hi On Fri, Aug 8, 2014 at 11:33 AM, Thierry Reding wrote: > From: Thierry Reding > > Commit 21d70354bba9 ("drm: move drm_stub.c to drm_drv.c") moves the code > from drm_stub.c into drm_drv.c. Update DocBook to include that instead. > > Signed-off-by: Thierry Reding Nice catch. Reviewed-by:

[PATCH] drm: Don't grab an fb reference for the idr

Hi On Wed, Aug 6, 2014 at 9:10 AM, Daniel Vetter wrote: > The current refcounting scheme is that the fb lookup idr also holds a > reference. This works out nicely bacause thus far we've always > explicitly cleaned up idr entries for framebuffers: > - Userspace fbs get removed in the rmfb ioctl

[PULL] drm-intel-fixes

On Fri, Aug 8, 2014 at 7:34 AM, Daniel Vetter wrote: > > git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-08-08 Hmm. My laptop no longer resumes properly. Or rather, I suspect it resumes, but the screen is black. I will bisect, and I *will* revert if I find the offending

Dual-channel DSI

ou do not like video > >> interfaces > >> maybe better would be sth like this: > >> > >>dsi at 5430 { > >>panel: panel at 0 { > >>compatible = "sharp,lq101r1sx01"; > >>reg = <0>; > >>secondary_dsi = <>; > >>}; > >>}; > >> > >>dsiB: dsi at 5440 { > >>}; > > That's pretty much the same thing that I proposed, except that it > > reverses the link between the two. > For me it is fundamentally different - in your proposition you have two > different panels, in my you have only one, attached to one dsi with > phandle to 2nd dsi. Looking at the example again I don't see how it could work. The phandle references the second DSI host, but we need a reference to the second DSI peripheral. We can't just assume that it's on the same virtual channel as the first. > > In fact I tried something similar to > > that before, but it has a couple of problems: if the secondary device > > does not have a compatible string (that's probably not valid in device > > tree to begin with) then there's no way for the device to report what > > format it expects or what number of lanes it uses. But those are > > parameters that are needed to set up the DSI (and display controllers). > > I2C has: > struct i2c_client * > i2c_new_device(struct i2c_adapter *adap, struct i2c_board_info const *info) > > DSI could have something similar, this way you could pass everything you > need. We don't need any of that if both devices have a proper compatible string, which they should have anyway, since then the driver can fill in those values as appropriate. 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/20140808/2655c561/attachment.sig>

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

g the HS clock is not required for LPM mode. In fact if the > >>>>> peripheral specifies that it doesn't support non-continuous mode then > >>>>> the HS clock must *never* be disabled as long as the peripheral is in > >>>>> use. > >>>>> > >>>>> MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and > >>>>> need to be considered separately. > >>>> > >>>> I mentioned already LPM and NON_CONTINUOUS are unrelated. > >>>> > >>>> It seems that you say the only way to transfer command data in LPM is > >>>> non-continuous clock mode. > >>> > >>> No, that's not what I'm saying. > >>> > >>>> However, you said and also the spec says, "Non-continuous mode simply > >>>> means that the clock lane enters LP-11 between HS transmissions". > >>>> Doesn't *between HS transmissions" mean the command data is transmitted > >>>> in HS, *not in LPM*, and clock lane enters LP-11 between them? > >>> > >>> Not necessarily. You can transmit command packets in high-speed mode, > >>> but you don't have to. If you transmit packets in low power mode, then > >> > >> That would may why we are mentioning same comments repeatedly. > >> > >> In my case, host driver waits for the lane stop state (LP-11), and then > >> disables HS clock to transmit command data in LPM. Of course, I'm not > >> sure that yet it's correct way. > > > > That's confusing. How can the lane go to LP-11 when the clock is still > > running? > > Actually, we are doing so. If the clock is still running then dsi driver > will wait for stop state of the clock and data lanes. Know that this is > valid only when initial time - just one time since power up. > > /* Check clock and data lane state are stop state */ > timeout = 100; > do { > if (timeout-- == 0) { > dev_err(dsi->dev, "waiting for bus lanes timed out\n"); > return -EFAULT; > } > > reg = readl(dsi->reg_base + DSIM_STATUS_REG); > if ((reg & DSIM_STOP_STATE_DAT(lanes_mask)) > != DSIM_STOP_STATE_DAT(lanes_mask)) > continue; > } while (!(reg & (DSIM_STOP_STATE_CLK | DSIM_TX_READY_HS_CLK))); > > > > >> In Tegra, What to do for it? > > > > There are two bits in two separate registers for this: > > > > DSI_HOST_CONTROL: > > bit 5: DSI_HIGH_SPEED_TRANS: DSI high speed transmission of > >packets > > - 0 = LOW: low speed > > - 1 = HIGH: high speed > > > > DSI_CONTROL: > > bit 20: DSI_HS_CLK_CTRL: Control for the HS clock lane > > - 0 = CONTINUOUS: HS clock is on all the time > > - 1 = TX_ONLY: HS clock is only active during HS > >transmissions > > > > So if the peripheral supports non-continuous mode of operation we set > > the DSI_HS_CLK_CTRL bit, otherwise we clear it to make sure the clock > > remains on all the time. > > > > When a packet is to be transmitted in high speed mode, we set the > > DSI_HIGH_SPEED_TRANS bit. For low power mode transmissions that bit is > > cleared. > > That is exactly what I want. In your case, if you want to transmit > command data in Low Power Mode in case of supporting non-continuous > clock mode, then you would set DSI_HS_CLK_CTRL (TX_ONLY), and also you > would clear DSI_HIGH_SPEED_TRANS (LOW). > > So I guess, > > if (flags & MIPI_DSI_MODE_NON_CONTINUOUS) { > disable DSI_HIGH_SPEED_TRANS; <- LOW > enable DSI_HS_CLK_CTRL; <- TX_ONLY > } > > transmit command data <- in LPM. > > However, what if the peripheral doesn't support non-continuous but want > to transmit command data in LPM? Is that impossible? The above is actually more like this: if ((flags & MIPI_DSI_MODE_NON_CONTINUOUS) == 0) clear DSI_HS_CLK_CTRL; else set DSI_HS_CLK_CTRL; if (msg->flags & MIPI_DSI_MSG_USE_LPM) clear DSI_HIGH_SPEED_TRANS; else set DSI_HIGH_SPEED_TRANS; So for peripherals that don't support non-continuous clock mode, this will result in the following for low-power transmissions: clear DSI_HS_CLK_CTRL; /* HS clock always on */ clear DSI_HIGH_SPEED_TRANS; 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/20140808/84b8af1e/attachment-0001.sig>

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

On 08/08/2014 11:02 AM, Andrzej Hajda wrote: > On 08/08/2014 09:37 AM, Inki Dae wrote: >> On 2014? 08? 08? 16:03, Thierry Reding wrote: >>> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote: On 2014? 08? 07? 22:55, Thierry Reding wrote: > On Thu, Aug 07, 2014 at 10:39:29PM +0900,

[PATCH] drm/radeon: Always flush VM again on < CIK

On 08.08.2014 00:55, Alex Deucher wrote: > > Note that there is no PFP (or CE) on the compute queues so we can't > use PFP (or CE) for compute. AFAICT cik_hdp_flush_cp_ring_emit() always uses the PFP though. > Note also that the engine bit is not always consistent (for some packets 0 > = ME, 1

[PATCH] drm/doc: Refer to proper source file

From: Thierry Reding Commit 21d70354bba9 ("drm: move drm_stub.c to drm_drv.c") moves the code from drm_stub.c into drm_drv.c. Update DocBook to include that instead. Signed-off-by: Thierry Reding --- Documentation/DocBook/drm.tmpl | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

On 08/08/2014 09:37 AM, Inki Dae wrote: > On 2014? 08? 08? 16:03, Thierry Reding wrote: >> On Fri, Aug 08, 2014 at 10:45:47AM +0900, Inki Dae wrote: >>> On 2014? 08? 07? 22:55, Thierry Reding wrote: On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote: > On 2014? 08? 07? 22:17,

[PULL] drm-intel-fixes

On Fri, Aug 8, 2014 at 10:30 AM, Linus Torvalds wrote: > > This is a Sony Vaio Pro 11, so it's bog-standard intel graphics (Haswell ULT). Got this while bisecting. I'm not sure it's related, the behavior was a bit different from the other cases. So I'll try to continue bisecting, but am a bit

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

On 2014? 08? 07? 22:55, Thierry Reding wrote: > On Thu, Aug 07, 2014 at 10:39:29PM +0900, Inki Dae wrote: >> On 2014? 08? 07? 22:17, Thierry Reding wrote: >>> On Thu, Aug 07, 2014 at 10:05:44PM +0900, Inki Dae wrote: On 2014? 08? 07? 20:09, Thierry Reding wrote: > On Thu, Aug 07, 2014 at

[PATCH] drm/radeon: Always flush VM again on < CIK

>>> On Thu, Aug 7, 2014 at 3:59 PM, Alex Deucher >>> wrote: We should be using PFP as much as possible. Does the attached patch help? > Unfortunately not. Maybe add a readback of the VM base addr pointer to make sure that the write has really reached the SBRM? Otherwise I'm out of ideas

[PATCH 2/2] Enables gem prime helpers for qxl using dummy driver callbacks

As there should not be any other virtual device that might share buffers, the callbacks remain empty stubs. Still prime can be used to transfer buffers between processes that use qxl. Signed-off-by: Andreas Pokorny --- drivers/gpu/drm/qxl/Makefile| 2 +- drivers/gpu/drm/qxl/qxl_drv.c |

[PATCH 1/2] Simple crtc page flipping emulated using buffer copy

Signed-off-by: Andreas Pokorny --- drivers/gpu/drm/qxl/qxl_display.c | 49 +++ drivers/gpu/drm/qxl/qxl_drv.c | 18 ++ drivers/gpu/drm/qxl/qxl_kms.c | 16 + 3 files changed, 79 insertions(+), 4 deletions(-) diff --git

[PATCH 0/2] QXL page flip and prime support

Hi, This series adds a page flipping implementation using qxl_draw_dirty_fb and prime support. Similar to the vmware driver it assumes that there is no other virtual device to share buffers with. Andreas Pokorny (2): Simple crtc page flipping emulated using buffer copy Enables gem prime

[Bug 82186] [r600g] BARTS GPU lockup with minecraft shaders

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

[PATCH] drm/radeon: Read back ring buffer before updating WPTR

On Fri, Aug 8, 2014 at 4:45 AM, Michel D?nzer wrote: > From: Michel D?nzer > > This fixes a ring test failure reported on a Kabini system which was > triggered by write-combined CPU mappings of the ring buffers. > > Reported-and-Tested-by: Will Trives > Signed-off-by: Michel D?nzer Applied to

[PATCH] drm/radeon: Always flush VM again on < CIK

On Fri, Aug 8, 2014 at 9:31 AM, Alex Deucher wrote: > On Fri, Aug 8, 2014 at 4:50 AM, Michel D?nzer wrote: >> On 08.08.2014 17:44, Christian K?nig wrote: >> On Thu, Aug 7, 2014 at 3:59 PM, Alex Deucher >> wrote: >>> We should be using PFP as much as possible. Does the attached

[PATCH] drm/radeon: Always flush VM again on < CIK

On Fri, Aug 8, 2014 at 4:50 AM, Michel D?nzer wrote: > On 08.08.2014 17:44, Christian K?nig wrote: > On Thu, Aug 7, 2014 at 3:59 PM, Alex Deucher > wrote: >> We should be using PFP as much as possible. Does the attached >> patch help? >>> Unfortunately not. >> >> Maybe add a

Dual-channel DSI

On 08/07/2014 10:54 AM, Thierry Reding wrote: > On Thu, Aug 07, 2014 at 10:39:36AM +0200, Andrzej Hajda wrote: >> On 08/07/2014 09:25 AM, Thierry Reding wrote: >>> On Thu, Aug 07, 2014 at 08:53:47AM +0200, Andrzej Hajda wrote: Hi Thierry, Nice case. On 08/05/2014 05:39 PM,

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

> for LPM transfer, lanes should be LP-11 state and also HS clock of the > >>>>>> host controller should be disabled. > >>>>> > >>>>> No. I don't think any transmissions can happen when all lanes are in > >>>>> LP-11 state. The MIPI_DSI_MSG_USE_LPM is used to specify that a packet > >>>>> should be transmitted in low power mode (see LP Transmission in 2.1 > >>>>> "Definitions" of the MIPI DSI specification). > >>>>> > >>>> > >>>> Hm.. I see. I meant, > >>>> > >>>> if (flags & MIPI_DSI_MSG_USE_LPM) > >>>>disable HS clock <- required. > >>>> > >>>> transmit command data <- in LPM. > >>> > >>> No. Disabling the HS clock is not required for LPM mode. In fact if the > >>> peripheral specifies that it doesn't support non-continuous mode then > >>> the HS clock must *never* be disabled as long as the peripheral is in > >>> use. > >>> > >>> MIPI_DSI_MSG_USE_LPM and MIPI_DSI_CLOCK_NON_CONTINUOUS are unrelated and > >>> need to be considered separately. > >> > >> I mentioned already LPM and NON_CONTINUOUS are unrelated. > >> > >> It seems that you say the only way to transfer command data in LPM is > >> non-continuous clock mode. > > > > No, that's not what I'm saying. > > > >> However, you said and also the spec says, "Non-continuous mode simply > >> means that the clock lane enters LP-11 between HS transmissions". > >> Doesn't *between HS transmissions" mean the command data is transmitted > >> in HS, *not in LPM*, and clock lane enters LP-11 between them? > > > > Not necessarily. You can transmit command packets in high-speed mode, > > but you don't have to. If you transmit packets in low power mode, then > > That would may why we are mentioning same comments repeatedly. > > In my case, host driver waits for the lane stop state (LP-11), and then > disables HS clock to transmit command data in LPM. Of course, I'm not > sure that yet it's correct way. That's confusing. How can the lane go to LP-11 when the clock is still running? > In Tegra, What to do for it? There are two bits in two separate registers for this: DSI_HOST_CONTROL: bit 5: DSI_HIGH_SPEED_TRANS: DSI high speed transmission of packets - 0 = LOW: low speed - 1 = HIGH: high speed DSI_CONTROL: bit 20: DSI_HS_CLK_CTRL: Control for the HS clock lane - 0 = CONTINUOUS: HS clock is on all the time - 1 = TX_ONLY: HS clock is only active during HS transmissions So if the peripheral supports non-continuous mode of operation we set the DSI_HS_CLK_CTRL bit, otherwise we clear it to make sure the clock remains on all the time. When a packet is to be transmitted in high speed mode, we set the DSI_HIGH_SPEED_TRANS bit. For low power mode transmissions that bit is cleared. 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/20140808/e120cc7a/attachment-0001.sig>

[Bug 79575] [radeonsi] Wine's d3d8 test crashes in SITargetLowering::analyzeImmediate

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

[PATCH] drm: Restore drm_file->is_master

On 8 August 2014 02:00, David Herrmann wrote: > Hi > > On Thu, Aug 7, 2014 at 3:04 PM, Chris Wilson > wrote: >> Despite the claims of >> >> commit 48ba813701eb14b3008edefef4a0789b328e278c >> Author: David Herrmann >> Date: Tue Jul 22 18:46:09 2014 +0200 >> >> drm: drop redundant

[Bug 79575] [radeonsi] Wine's d3d8 test crashes in SITargetLowering::analyzeImmediate

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/20140808/aeada4a9/attachment.html>

[Bug 79575] [radeonsi] Wine's d3d8 test crashes in SITargetLowering::analyzeImmediate

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140808/254540ba/attachment.html>

[git pull] drm merge window pull

Hi Linus, like all good pull reqs this ends with a revert, so it must mean we tested it, This pull is missing nouveau, Ben has been stuck trying to track down a very longstanding bug that revealed itself due to some other changes, I've asked him to send you a direct pull request for nouveau