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

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 07:49:03PM +0900, Inki Dae wrote: On 2014? 08? 07? 18:09, Thierry Reding wrote: > On Thu, Aug 07, 2014 at

[sbc_gxx] kernel BUG at include/linux/mtd/map.h:148!

On Thu, Aug 7, 2014 at 6:46 PM, Brian Norris wrote: > Hi, > > On Tue, Aug 05, 2014 at 08:08:57PM -0400, Nick Krause wrote: >> On Tue, Aug 5, 2014 at 9:59 AM, Fengguang Wu >> wrote: >> > Hello, >> > >> > This is an old BUG that still lives in linux-next. >> > >> > [4.284620] device id = 2670

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

On 2014? 08? 07? 20:09, Thierry Reding wrote: > On Thu, Aug 07, 2014 at 07:49:03PM +0900, Inki Dae wrote: >> On 2014? 08? 07? 18:09, Thierry Reding wrote: >>> On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote: On 2014? 08? 07? 15:58, Thierry Reding wrote: > On Thu, Aug 07, 2014 at

ipu-v3 build fix

does ipu-v3 need to select GENERIC_IRQ_CHIP otherwise on my arm test builds I get a failure to link due to missing irq symbols. Dave.

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

On 2014? 08? 07? 18:09, Thierry Reding wrote: > On Thu, Aug 07, 2014 at 04:51:18PM +0900, Inki Dae wrote: >> On 2014? 08? 07? 15:58, Thierry Reding wrote: >>> On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote: 2014-08-06 16:43 GMT+09:00 Thierry Reding : > [...] > As far as I can

[patch] drm/radeon: add a check for allocation failure

On Thu, Aug 07, 2014 at 11:31:15AM -0400, Alex Deucher wrote: > On Thu, Aug 7, 2014 at 11:27 AM, Dan Carpenter > wrote: > > We can easily return -ENOMEM here if kzalloc() fails. > > > > Signed-off-by: Dan Carpenter > > > > diff --git a/drivers/gpu/drm/radeon/radeon_vm.c > >

[patch] drm/radeon: add a check for allocation failure

We can easily return -ENOMEM here if kzalloc() fails. Signed-off-by: Dan Carpenter diff --git a/drivers/gpu/drm/radeon/radeon_vm.c b/drivers/gpu/drm/radeon/radeon_vm.c index ccae4d9..d15d987 100644 --- a/drivers/gpu/drm/radeon/radeon_vm.c +++ b/drivers/gpu/drm/radeon/radeon_vm.c @@ -483,6

[pull] radeon drm-next-3.17

Hi Dave, Latest version of the userptr stuff after yesterday's discussions. If you're ok with it, please apply, otherwise, we'll push to 3.18. The following changes since commit 21d70354bba9965a098382fc4d7fb17e138111f3: drm: move drm_stub.c to drm_drv.c (2014-08-06 19:10:44 +1000) are

[PATCH] drm: Restore drm_file->is_master

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 drm_file->is_master > > drm_file->is_master is not synomous with

[PATCH 2/2] drm/radeon: allow zero sized BOs for fences

Am 07.08.2014 um 17:01 schrieb Jerome Glisse: > On Thu, Aug 07, 2014 at 04:30:33PM +0200, Christian K?nig wrote: >> From: Christian K?nig > > Can we get proper change log with motivation for doing that, use case, > why it can not be done any other ways ... > > Change log is invaluable information

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

The GFX CP is split up into two different engines - the PFP and the ME (starting with SI you additionally get the CE as well). The PFP is responsible for reading commands out of memory and forwarding it to the ME (or the CE). Some commands can be executed on the PFP as well, like simple

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

So what's difference between WRITE_DATA with PFP vs ME? Would it also be preferable for DMA_DATA and COPY_DATA? Marek On Thu, Aug 7, 2014 at 3:59 PM, Alex Deucher wrote: > On Thu, Aug 7, 2014 at 3:46 AM, Michel D?nzer wrote: >> From: Michel D?nzer >> >> Not doing this causes piglit hangs[0]

[patch] drm/radeon: add a check for allocation failure

I'm 100% sure that I've fixed that as well with a follow up patch. Looks like that one didn't made it into 3.17 Christian. Am 07.08.2014 um 17:31 schrieb Alex Deucher: > On Thu, Aug 7, 2014 at 11:27 AM, Dan Carpenter > wrote: >> We can easily return -ENOMEM here if kzalloc() fails. >> >>

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

Am 07.08.2014 um 16:32 schrieb Alex Deucher: > On Thu, Aug 7, 2014 at 7:33 AM, Christian K?nig > wrote: >> From: Marco A Benatto >> >> Adding a Frames Per Second estimation logic on UVD handles >> when it has being used. This estimation is per handle basis >> and will help on DPM profile

[PATCH 3/3] drm: Use vblank_disable_and_save in drm_vblank_cleanup()

On 08/07/2014 08:50 AM, Daniel Vetter wrote: > On Thu, Aug 7, 2014 at 2:50 AM, Mario Kleiner > wrote: >> I'm not sure about all the new embedded drivers, if they have hw vblank >> counters? > Quick grep says a lot don't have it or at least not implemented - they > use drm_vblank_count. Thinking

[PATCH] drm/panel/simple: add optronics B101XTN01.0

.compatible = "optronics,b101xtn01", > > > > From the commit message this panel is from AU Optronics, so it should > > use the auo vendor prefix. > > so, "auo,b101xtn01" works for everyone? Yeah, that's consistent with the other ones from AUO, so looking good to me. 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/20140807/aabfedfd/attachment.sig>

[Bug 82162] Syslog flooded by [drm:radeon_gem_object_create] errors

part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/2826ed8a/attachment.html>

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

On 2014? 08? 07? 15:58, Thierry Reding wrote: > On Thu, Aug 07, 2014 at 02:09:19AM +0900, Inki Dae wrote: >> 2014-08-06 16:43 GMT+09:00 Thierry Reding : >>> On Wed, Aug 06, 2014 at 04:11:54PM +0900, Inki Dae wrote: On 2014? 08? 05? 20:12, Thierry Reding wrote: >>> [...] > I think that low

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

From: Michel D?nzer Not doing this causes piglit hangs[0] on my Cape Verde card. No issues on Bonaire and Kaveri though. [0] Same symptoms as those fixed on CIK by 'drm/radeon: set VM base addr using the PFP v2'. Signed-off-by: Michel D?nzer ---

[PATCH 1/9] drm: Add drm driver for Rockchip Socs

This patch is a DRM Driver for Rockchip Socs, driver provides an abstraction for the graphics hardware, such as lcd controller and connector interface. Signed-off-by: mark yao --- changes since v1: Adviced by Daniel Vetter: - Switch to universal plane API's --- drivers/gpu/drm/Kconfig

[PATCH 2/2] drm/radeon: allow zero sized BOs for fences

From: Christian K?nig Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_drv.c| 3 ++- drivers/gpu/drm/radeon/radeon_object.c | 2 +- drivers/gpu/drm/radeon/radeon_vm.c | 3 +++ 3 files changed, 6 insertions(+), 2 deletions(-) diff --git

[PATCH 1/2] drm/ttm: allow zero sized kernel allocations

From: Christian K?nig This patch allows to create zero sized TTM buffer objects for driver internal use. Signed-off-by: Christian K?nig --- drivers/gpu/drm/ttm/ttm_bo.c | 4 ++-- drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +- 2 files changed, 3 insertions(+), 3

i915 kernel warning

On Wed, 6 Aug 2014 22:29:54 +0200 Daniel Vetter wrote: > On Wed, Aug 06, 2014 at 10:03:46PM +0300, Mihai Don?u wrote: > > Hi, > > > > This just happened to me: > > > > Aug 6 21:37:37 mdontu-l kernel: [ cut here ] > > Aug 6 21:37:37 mdontu-l kernel: WARNING: CPU: 3 PID:

[PATCH] drm/panel: simple: Use devm_gpiod_get_optional()

Ping, Thierry? On Fri, Jul 25, 2014 at 11:47 PM, Alexandre Courbot wrote: > Use the new devm_gpiod_get_optional() to simplify the probe code. > > Signed-off-by: Alexandre Courbot > --- > drivers/gpu/drm/panel/panel-simple.c | 12 +--- > 1 file changed, 5 insertions(+), 7 deletions(-)

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

On 2014? 07? 29? 22:16, Andrzej Hajda wrote: > On 07/29/2014 02:08 PM, Inki Dae wrote: >> On 2014? 07? 29? 20:39, Andrzej Hajda wrote: >>> On 07/29/2014 05:42 AM, Inki Dae wrote: On 2014? 07? 29? 00:50, Andrzej Hajda wrote: > On 07/28/2014 04:00 AM, Inki Dae wrote: >> This patch adds

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

r 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 the HS clock isn't involved in the transmission and the clock lane may enter LP-11 during the whole transmission (if non-continuous mode is enabled). > We have one lcd panel, nt35502a, which needs LPM transfer support > because it should receive some initial commands with LPM by default > hardware setting, and we faced with that the panel didn't work without > disabling HS clock before transmitting command data. How can you explain > that? The specification clearly says that (5.6.1 "Clock Requirements"): All DSI transmitters and receivers shall support continuous clock behavior on the Clock Lane, and optionally may support non-continuous clock behavior. So if you need to "disable HS clock" for command data to be successfully transmitted, either the panel doesn't comply to the specification, or whatever you do to "disable HS clock" doesn't do what you think it does. 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/20140807/5e5efd5b/attachment.sig>

[sbc_gxx] kernel BUG at include/linux/mtd/map.h:148!

Hi, On Tue, Aug 05, 2014 at 08:08:57PM -0400, Nick Krause wrote: > On Tue, Aug 5, 2014 at 9:59 AM, Fengguang Wu > wrote: > > Hello, > > > > This is an old BUG that still lives in linux-next. > > > > [4.284620] device id = 2670 > > [4.286157] SBC-GXx flash: IO:0x258-0x259

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

On Thu, Aug 7, 2014 at 11:32 AM, Christian K?nig wrote: > Am 07.08.2014 um 16:32 schrieb Alex Deucher: > >> On Thu, Aug 7, 2014 at 7:33 AM, Christian K?nig >> wrote: >>> >>> From: Marco A Benatto >>> >>> Adding a Frames Per Second estimation logic on UVD handles >>> when it has being used. This

[Bug 81021] AMD CPUs w/ Integrated Graphics (APUs) And Turbo Core Only Boost If "fglrx" Module Is Loaded

https://bugzilla.kernel.org/show_bug.cgi?id=81021 --- Comment #14 from Alex Deucher --- The information in radeon_pm_info represents the current GPU power state. It will vary dynamically with GPU load. E.g., if you are rendering stuff on your desktop, the GPU clocks and voltages will ramp

[Bug 81021] AMD CPUs w/ Integrated Graphics (APUs) And Turbo Core Only Boost If "fglrx" Module Is Loaded

https://bugzilla.kernel.org/show_bug.cgi?id=81021 --- Comment #13 from LiNuxXer --- (In reply to Alex Deucher from comment #11) > Yes, I can add a module parameter to force it on. That's great news, thank you! I was beginning to think that I'd have to compile my kernel from now on. BTW, I

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

he DSI host should automatically > >>> disable the HS clock between high-speed transmissions. That means if a > >>> packet is transmitted in low power mode the DSI host will not be > >>> transmitting in high-speed mode and therefore disable the HS clock. > >> > >> What is LPM you think? I thought LPM is LP-11 and HS clock disabled. So > >> 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. 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/20140807/9366efea/attachment.sig>

[Bug 60879] [radeonsi] X11 can't start with acceleration enabled

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

[Bug 82162] Syslog flooded by [drm:radeon_gem_object_create] errors

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

[Bug 82162] Syslog flooded by [drm:radeon_gem_object_create] errors

. That would be P8 or 8 pipes. -- 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/20140807/6d2a6e16/attachment.html>

[PATCH] drm: Restore drm_file->is_master

Despite the claims of commit 48ba813701eb14b3008edefef4a0789b328e278c Author: David Herrmann Date: Tue Jul 22 18:46:09 2014 +0200 drm: drop redundant drm_file->is_master drm_file->is_master is not synomous with having drm_file->master == drm_file->minor->master. This is because

[Bug 82279] [bisected] double free or corruption on context destruction with postprocessing enabled

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140807/dfe0ecca/attachment.html>

[Bug 82162] Syslog flooded by [drm:radeon_gem_object_create] errors

mized out (gdb) p rscreen->info value has been optimized out (gdb) p pipe_interleave_bytes $1 = 256 (gdb) p num_pipes $2 = 12 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.fre

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

From: Marco A Benatto Adding a Frames Per Second estimation logic on UVD handles when it has being used. This estimation is per handle basis and will help on DPM profile calculation. v2 (chk): fix timestamp type, move functions around and cleanup code a

[Bug 81021] AMD CPUs w/ Integrated Graphics (APUs) And Turbo Core Only Boost If "fglrx" Module Is Loaded

https://bugzilla.kernel.org/show_bug.cgi?id=81021 --- Comment #12 from Alex Deucher --- Created attachment 145411 --> https://bugzilla.kernel.org/attachment.cgi?id=145411=edit add a bapm module parameter -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 81021] AMD CPUs w/ Integrated Graphics (APUs) And Turbo Core Only Boost If "fglrx" Module Is Loaded

https://bugzilla.kernel.org/show_bug.cgi?id=81021 --- Comment #11 from Alex Deucher --- (In reply to LiNuxXer from comment #10) > > 3) One question remains -- can't bapm enabling become at least a parameter? > Or is it already? Yes, I can add a module parameter to force it on. -- You are

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

de, then the DSI host should automatically > > disable the HS clock between high-speed transmissions. That means if a > > packet is transmitted in low power mode the DSI host will not be > > transmitting in high-speed mode and therefore disable the HS clock. > > What i

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

On Thu, Aug 7, 2014 at 11:38 AM, Marek Ol??k wrote: > So what's difference between WRITE_DATA with PFP vs ME? Would it also > be preferable for DMA_DATA and COPY_DATA? The PFP comes before the ME in the pipeline. Note that there is no PFP (or CE) on the compute queues so we can't use PFP (or

Any help needed?

Linux user ID: #506236 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/c5f6542e/attachment.html>

[patch] drm/radeon: add a check for allocation failure

On Thu, Aug 7, 2014 at 11:27 AM, Dan Carpenter wrote: > We can easily return -ENOMEM here if kzalloc() fails. > > Signed-off-by: Dan Carpenter > > diff --git a/drivers/gpu/drm/radeon/radeon_vm.c > b/drivers/gpu/drm/radeon/radeon_vm.c > index ccae4d9..d15d987 100644 > ---

[Intel-gfx] [PATCH 0/6] Rename DP training vswing/pre-emph defines

On Tue, Aug 05, 2014 at 04:38:16PM +0530, sonika.jindal at intel.com wrote: > 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. >

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

rk a packet to be transmitted in low power mode (as opposed to high speed mode). For peripherals that don't support non-continuous mode the NON_CONTINUOUS flag needs to be set. But the driver for the peripheral can still initiate low power mode packet transmissions by setting the MSG_LPM flag. 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/20140807/1a3904eb/attachment.sig>

[PATCH 2/2] drm/radeon: allow zero sized BOs for fences

On Thu, Aug 07, 2014 at 04:30:33PM +0200, Christian K?nig wrote: > From: Christian K?nig Can we get proper change log with motivation for doing that, use case, why it can not be done any other ways ... Change log is invaluable information and empty change log is the worst thing ever. > >

Dual-channel DSI

he two. 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). One other problem with the above is that the dependency implied by your "secondary_dsi" property is the wrong way around. The above would mean that requires 's services to function, but that's not the case. If anything it's the other way around. could still work standalone (though only drive the left half of the screen). 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/20140807/d374b834/attachment-0001.sig>

ipu-v3 build fix

On Thu, Aug 7, 2014 at 7:32 AM, Dave Airlie wrote: > does ipu-v3 need to > > select GENERIC_IRQ_CHIP > > otherwise on my arm test builds I get a failure to link due to missing > irq symbols. Which defconfig you use in order to trigger the failure?

Dual-channel DSI

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, Thierry Reding wrote: >>> Hi everyone, >>> >>> I've been working on adding support for a panel that uses what's >>> commonly

[PATCH] drm/radeon: Adding UVD handle basis fps estimation v2

On Thu, Aug 7, 2014 at 7:33 AM, Christian K?nig wrote: > From: Marco A Benatto > > Adding a Frames Per Second estimation logic on UVD handles > when it has being used. This estimation is per handle basis > and will help on DPM profile calculation. > > v2 (chk): fix timestamp type, move

[Bug 82162] Syslog flooded by [drm:radeon_gem_object_create] errors

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

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

updates.patch Type: text/x-diff Size: 3275 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/d03eda17/attachment-0001.patch>

[GIT PULL] drm/tegra: Changes for v3.17-rc1

(-) -- 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/20140807/b481e2c5/attachment.sig>

[GIT PULL] drm/panel: Changes for v3.17-rc1

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140807/5771aca5/attachment.sig>

[PATCH] drm/panel: simple: Use devm_gpiod_get_optional()

ilable URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/c7c0ad90/attachment.sig>

[Bug 81021] AMD CPUs w/ Integrated Graphics (APUs) And Turbo Core Only Boost If "fglrx" Module Is Loaded

https://bugzilla.kernel.org/show_bug.cgi?id=81021 --- Comment #10 from LiNuxXer --- (In reply to Alex Deucher from comment #8) > I'm not sure why you don't think you need a GPU driver installed. When the > driver is installed it not only allows the GPU to dynamically adjust it > clocks and

[PATCH 2/5] drm/radeon: add userptr flag to limit it to anonymous memory v2

Am 07.08.2014 um 08:55 schrieb Daniel Vetter: > On Wed, Aug 06, 2014 at 11:45:48PM -0400, Jerome Glisse wrote: >> On Wed, Aug 06, 2014 at 10:24:31PM +0200, Daniel Vetter wrote: >>> On Wed, Aug 06, 2014 at 02:34:16PM -0400, Jerome Glisse wrote: On Wed, Aug 06, 2014 at 07:17:25PM +0200,

[PATCH 5/5] drm/radeon: allow userptr write access under certain conditions

From: Christian K?nig It needs to be anonymous memory (no file mappings) and we are requried to install an MMU notifier. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_gem.c | 19 --- 1 file changed, 12 insertions(+), 7 deletions(-)

[PATCH 4/5] drm/radeon: add userptr flag to register MMU notifier v3

From: Christian K?nig Whenever userspace mapping related to our userptr change we wait for it to become idle and unmap it from GTT. v2: rebased, fix mutex unlock in error path v3: improve commit message Signed-off-by: Christian K?nig --- drivers/gpu/drm/Kconfig

[PATCH 3/5] drm/radeon: add userptr flag to directly validate the BO to GTT

From: Christian K?nig This way we test userptr availability at BO creation time instead of first use. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_gem.c | 18 +- include/uapi/drm/radeon_drm.h | 1 + 2 files changed, 18

[PATCH 2/5] drm/radeon: add userptr flag to limit it to anonymous memory v2

From: Christian K?nig Avoid problems with writeback by limiting userptr to anonymous memory. v2: add commit and code comments Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_gem.c | 3 ++- drivers/gpu/drm/radeon/radeon_ttm.c | 10 ++

[PATCH 1/5] drm/radeon: add userptr support v8

From: Christian K?nig This patch adds an IOCTL for turning a pointer supplied by userspace into a buffer object. It imposes several restrictions upon the memory being mapped: 1. It must be page aligned (both start/end addresses, i.e ptr and size). 2. It must be

[Bug 81021] AMD CPUs w/ Integrated Graphics (APUs) And Turbo Core Only Boost If "fglrx" Module Is Loaded

https://bugzilla.kernel.org/show_bug.cgi?id=81021 --- Comment #9 from LiNuxXer --- (In reply to Kertesz Laszlo from comment #3) > [...] > Additionally, even if fglrx eables turbo core boost, sometimes something > weird happens and even the nominal speed is reported as maximum, in effect > you

[PATCH] drm/panel/simple: add optronics B101XTN01.0

On Wed, Aug 06, 2014 at 04:31:30PM -0400, Rob Clark wrote: > LVDS panel, make/model described as: > > AU Optronics Corporation - B101XTN01.0 (H/W:0A) > > See: > http://www.encore-electronic.com/media/B101XTN01.0.pdf I've made it a custom to mention which board a panel is used on in the commit

[PATCH] drm/radeon: add bapm module parameter

Add a module paramter to enable bapm on APUs. It's disabled by default on certain APUs due to stability issues. This option makes it easier to test and to enable it on systems that are stable. bug: https://bugzilla.kernel.org/show_bug.cgi?id=81021 Signed-off-by: Alex Deucher ---

Dual-channel DSI

On Thu, Aug 07, 2014 at 08:53:47AM +0200, Andrzej Hajda wrote: > Hi Thierry, > > Nice case. > > On 08/05/2014 05:39 PM, Thierry Reding wrote: > > Hi everyone, > > > > I've been working on adding support for a panel that uses what's > > commonly known as dual-channel DSI. Sometimes this is

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

of any reasonable resolution and framerate, so I would assume that video data can always be transmitted in HS mode. So even if some device required video data transmission to use low power mode, then that should be considered the oddball peripheral and it could be handled by an extra flag. By default we should still assume high-speed mode for video data packet transmissions. We can address those quirks when we actually encounter peripherals that don't work under those assumptions. 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/20140807/769ccea8/attachment.sig>

[PATCH 3/3] drm: Use vblank_disable_and_save in drm_vblank_cleanup()

On Thu, Aug 7, 2014 at 2:50 AM, Mario Kleiner wrote: > Ok, good with me, thanks. Ville, thanks for the review. I'll review and test > your vblank series next week when i have access to suitable machines and > enough time. I need to go through this in single-step mode, vblank on/off > changes

[PATCH 2/5] drm/radeon: add userptr flag to limit it to anonymous memory v2

On Wed, Aug 06, 2014 at 11:45:48PM -0400, Jerome Glisse wrote: > On Wed, Aug 06, 2014 at 10:24:31PM +0200, Daniel Vetter wrote: > > On Wed, Aug 06, 2014 at 02:34:16PM -0400, Jerome Glisse wrote: > > > On Wed, Aug 06, 2014 at 07:17:25PM +0200, Christian K?nig wrote: > > > > Am 06.08.2014 um 18:08

Dual-channel DSI

Hi Thierry, Nice case. On 08/05/2014 05:39 PM, Thierry Reding wrote: > Hi everyone, > > I've been working on adding support for a panel that uses what's > commonly known as dual-channel DSI. Sometimes this is referred to as > ganged-mode as well. > > What is it, you ask? It's essentially a hack

[PATCH] drm/panel/simple: add optronics B101XTN01.0

On Thu, Aug 7, 2014 at 3:33 AM, Thierry Reding wrote: > On Wed, Aug 06, 2014 at 04:31:30PM -0400, Rob Clark wrote: >> LVDS panel, make/model described as: >> >> AU Optronics Corporation - B101XTN01.0 (H/W:0A) >> >> See: >> http://www.encore-electronic.com/media/B101XTN01.0.pdf > > I've made it a

[PATCH 3/3] drm: Use vblank_disable_and_save in drm_vblank_cleanup()

On Thu, Aug 7, 2014 at 2:50 AM, Mario Kleiner wrote: > I'm not sure about all the new embedded drivers, if they have hw vblank > counters? Quick grep says a lot don't have it or at least not implemented - they use drm_vblank_count. Thinking about this, should we use that as a signal to also set

[RFC PATCH] drm/mipi-dsi: add some generic functions for DCS

Hi YoungJun, Thierry, On 07/31/2014 06:14 AM, YoungJun Cho wrote: > This patch adds some generic functions for DCS like below > to standize on common APIs rather than per-driver > implementations. > > mipi_dcs_enter_sleep_mode() / mipi_dcs_exit_sleep_mode() > - These are required to disable /

[Bug 82279] [bisected] double free or corruption on context destruction with postprocessing enabled

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

[Bug 18154] DRM support for addressing >32 bits on 32 bit cores

es/dri-devel/attachments/20140807/200690f1/attachment.html>

[Bug 82253] JanusVR Browser rendering misses floors on radeonsi, works on intel

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/a193dc34/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

[Bug 82279] [bisected] double free or corruption on context destruction with postprocessing enabled

und > state on destruction v2". Christian, any ideas? -- 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/20140807/8f21211b/attachment.html>

[Bug 82279] SDL applications crash when changing video mode on radeonsi: double free or corruption

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/3514cee5/attachment.html>

[Bug 82279] SDL applications crash when changing video mode: double free or corruption

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/1da76fa8/attachment.html>

[Bug 82279] [bisected] SDL applications crash when changing video mode: double free or corruption

. -- 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/20140807/6d15a331/attachment.html>

[Bug 82279] [bisected] SDL applications crash when changing video mode: double free or corruption

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140807/f8770736/attachment-0001.html>

[Bug 82279] SDL applications crash when changing video mode: double free or corruption

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

[Bug 82279] SDL applications crash when changing video mode: double free or corruption

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

[Bug 82279] New: SDL applications crash when changing video mode: double free or corruption

p.org/archives/dri-devel/attachments/20140807/58e6e2e8/attachment.html>

[PATCH 3/3] drm: Use vblank_disable_and_save in drm_vblank_cleanup()

On 08/06/2014 03:57 PM, Daniel Vetter wrote: > On Wed, Aug 06, 2014 at 01:51:41PM +0300, Ville Syrj?l? wrote: >> On Wed, Aug 06, 2014 at 03:22:46AM +0200, Mario Kleiner wrote: >>> Calling vblank_disable_fn() will cause that function to no-op >>> if !dev->vblank_disable_allowed for some kms

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

2014-08-06 16:43 GMT+09:00 Thierry Reding : > On Wed, Aug 06, 2014 at 04:11:54PM +0900, Inki Dae wrote: >> On 2014? 08? 05? 20:12, Thierry Reding wrote: > [...] >> > I think that low power mode is more often used for command transmission >> > (in host-driven mode). I'm not sure how much sense it

[Bug 81644] Random crashes on RadeonSI with Chromium.

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/20140807/62331b79/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

14.04 only. -- 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/20140807/2e481b0d/attachment-0001.html>

[PATCH 2/5] drm/radeon: add userptr flag to limit it to anonymous memory v2

On Wed, Aug 06, 2014 at 10:24:31PM +0200, Daniel Vetter wrote: > On Wed, Aug 06, 2014 at 02:34:16PM -0400, Jerome Glisse wrote: > > On Wed, Aug 06, 2014 at 07:17:25PM +0200, Christian K?nig wrote: > > > Am 06.08.2014 um 18:08 schrieb Jerome Glisse: > > > >On Wed, Aug 06, 2014 at 08:55:28AM +0200,

[Bug 82253] JanusVR Browser rendering misses floors on radeonsi, works on intel

https://bugs.freedesktop.org/show_bug.cgi?id=82253 --- Comment #3 from Christoph Haag --- Created attachment 104184 --> https://bugs.freedesktop.org/attachment.cgi?id=104184=edit correct rendering on intel -- You are receiving this mail because: You are the assignee for the bug.

[Bug 82253] JanusVR Browser rendering misses floors on radeonsi, works on intel

https://bugs.freedesktop.org/show_bug.cgi?id=82253 --- Comment #2 from Christoph Haag --- Created attachment 104183 --> https://bugs.freedesktop.org/attachment.cgi?id=104183=edit floors missing on radeonsi It seems to be a purely visual problem in the rendering. Here is a screenshot with

[Bug 82253] JanusVR Browser rendering misses floors on radeonsi, works on intel

https://bugs.freedesktop.org/show_bug.cgi?id=82253 --- Comment #1 from Aaron B --- What sort of problems does this cause? So is it only when using hardware accel? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML