On Fri, Aug 05, 2016 at 06:59:08PM +0100, Mark Brown wrote:
> On Fri, Aug 05, 2016 at 06:04:50PM +0100, Russell King - ARM Linux wrote:
> > On Fri, Aug 05, 2016 at 05:59:59PM +0100, Mark Brown wrote:
>
> > > We do have some stuff in there in order to handle MFDs - they'll
> > > instantiate a Linux
||
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160805/56a6218d/attachment.html>
||
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160805/f6c8d089/attachment.html>
Timeouts can be errors, but timeouts are also usually normal behavior
and happen a lot. Since the kernel already lets us know when we're
suppressing messages due to rate limiting, rate limit timeout errors so
we don't make too much noise in the kernel log.
Signed-off-by: Lyude
---
drivers/gpu/dr
There's a couple of places where this would be useful for drivers (such
as reporting DP aux transaction timeouts).
Signed-off-by: Lyude
---
include/drm/drmP.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index d377865
When this code was written, we didn't retry DP aux transactions on any
error, which required retrying important transactions like this in
individual drivers. Since that's no longer the case, retrying here is
not necessary. As well, we retry any aux transaction on any error 32
times. 7 * 32 = 224, w
Since it's normal for DRM to retry our aux transaction helpers multiple
times in a row, up to 32 times for each attempted transaction, we're
making a lot of noise that is no longer necessary now that DRM will just
print the return code we give it.
Signed-off-by: Lyude
---
drivers/gpu/drm/amd/amd
When this code was written, we didn't retry DP aux transactions on any
error, which required retrying important transactions like this in
individual drivers. Since that's no longer the case, retrying here is
not necessary. As well, we retry any aux transaction on any error 32
times. 7 * 32 = 224, w
Since it's normal for DRM to retry our aux transaction helpers multiple
times in a row, up to 32 times for each attempted transaction, we're
making a lot of noise that is no longer necessary now that DRM will just
print the return code we give it.
Signed-off-by: Lyude
---
drivers/gpu/drm/radeon/
Since we always retry in drm_dp_dpcd_access() regardless of the error,
we're going to make a lot of noise if the aux->transfer function prints
it's own errors (as is the case with radeon). If we can print the error
code here, this reduces the need for drivers to do this. So instead of
having to pri
While I was investigating an unrelated bug on the radeon driver, I noticed that
it's become rather difficult to actually read through dmesg with drm.debug
turned on, on account of the huge number of messages we end up printing from
failed DP aux transactions that happen every time we reprobe each c
Now that we can hook into update_crtcs and control the order in which we
update CRTCs at each modeset, we can finish the final step of fixing
Skylake's watermark handling by performing DDB updates at the same time
as plane updates and watermark updates.
The first major change in this patch is skl_
Since we have to write ddb allocations at the same time as we do other
plane updates, we're going to need to be able to control the order in
which we execute modesets on each pipe. The easiest way to do this is to
just factor this section of intel_atomic_commit_tail()
(intel_atomic_commit() for sta
If we're enabling a pipe, we'll need to modify the watermarks on all
active planes. Since those planes won't be added to the state on
their own, we need to add them ourselves.
Signed-off-by: Lyude
Reviewed-by: Matt Roper
Cc: stable at vger.kernel.org
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: R
Thanks to Ville for suggesting this as a potential solution to pipe
underruns on Skylake.
On Skylake all of the registers for configuring planes, including the
registers for configuring their watermarks, are double buffered. New
values written to them won't take effect until said registers are
"ar
From: Matt Roper
When we write watermark values to the hardware, those values are stored
in dev_priv->wm.skl_hw. However with recent watermark changes, the
results structure we're copying from only contains valid watermark and
DDB values for the pipes that are actually changing; the values for
o
Since the watermark calculations for Skylake are still broken, we're apt
to hitting underruns very easily under multi-monitor configurations.
While it would be lovely if this was fixed, it's not. Another problem
that's been coming from this however, is the mysterious issue of
underruns causing full
Latest version of https://patchwork.freedesktop.org/series/10276/
All patches are being resent to keep them in one place. Most of the changes are
very minor, with the exception of patch 6.
The patches that actually changed:
- drm/i915/skl: Add support for the SAGV, fix underrun hangs
- drm/i915
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160805/877472e4/attachment-0001.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160805/73070a72/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160805/fb9209ab/attachment.html>
Fix unsupported GEM memory type error message to include the memory type
information.
Signed-off-by: Shuah Khan
---
drivers/gpu/drm/exynos/exynos_drm_fb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exyn
g/archives/dri-devel/attachments/20160805/99cffbce/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=151541
--- Comment #6 from Dainius Masiliūnas ---
Created attachment 227741
--> https://bugzilla.kernel.org/attachment.cgi?id=227741&action=edit
4.7.0-next-20160803 dmesg
No. I tried the linux-next tree and it gave me the same errors even during boo
https://bugzilla.kernel.org/show_bug.cgi?id=84431
--- Comment #10 from JoaquÃn AramendÃa ---
> JoaquÃn, how does 97d30fa35 break nouveau vga-switcheroo? If you load
> nouveau with runpm=0, then you can write OFF to debugfs' vga_switcheroo.
> However runpm=1 (or -1 for Optimus systems) is reco
so there is
probably context I'm missing here...
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160805/6dd803d6/attachment.sig>
From: Michel Dänzer
Fixes hangs under memory pressure, e.g. running the piglit test
tex3d-maxsize concurrently with other tests.
Fixes: 17d33bc9d6ef ("drm/ttm: drop waiting for idle in ttm_bo_evict.")
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 ++--
drivers
On Fri, Aug 5, 2016 at 11:44 AM, Noralf Trønnes wrote:
> Create a simple fbdev device during SimpleDRM setup so legacy user-space
> and fbcon can use it.
>
> Original work by David Herrmann.
>
> Cc: dh.herrmann at gmail.com
> Signed-off-by: Noralf Trønnes
> ---
>
> Changes from version 1:
> N
Hi, YT:
On Thu, 2016-08-04 at 19:07 +0800, YT Shen wrote:
> From: shaoming chen
>
> add dsi interrupt control
>
> Signed-off-by: shaoming chen
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 76
>
> 1 file changed, 76 insertions(+)
>
> diff --git a/driver
https://bugzilla.kernel.org/show_bug.cgi?id=151541
--- Comment #5 from Alex Deucher ---
Does it work any better with kernel 4.8?
--
You are receiving this mail because:
You are watching the assignee of the bug.
Hi, YT:
On Thu, 2016-08-04 at 19:07 +0800, YT Shen wrote:
> From: shaoming chen
>
> add dsi read/write commands for transfer function
>
> Signed-off-by: shaoming chen
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 261
>
> 1 file changed, 261 insertions(+)
On Fri, Aug 05, 2016 at 05:59:59PM +0100, Mark Brown wrote:
> On Fri, Aug 05, 2016 at 05:48:45PM +0100, Russell King - ARM Linux wrote:
> > On Fri, Aug 05, 2016 at 12:02:39PM +0300, Jyri Sarha wrote:
>
> > > That may be a problem. The ASoC card device tree binding current looks
> > > for the ASoC
27;re definitely not
expecting to find anything for parentless platform devices though, it's
only done if the ASoC level device has no of_node and the parent does.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signatur
On Fri, Aug 05, 2016 at 12:02:39PM +0300, Jyri Sarha wrote:
> On 08/04/16 17:07, Russell King - ARM Linux wrote:
> > On Tue, Aug 02, 2016 at 03:05:08PM +0300, Jyri Sarha wrote:
> >> + priv->audio_pdev = platform_device_register_data(
> >> + dev, HDMI_CODEC_DRV_NAME, PLATFORM_DEVID_AUTO,
>
There is currently no non-fbdev mechanism in place to kick out
simpledrm when the real hw-driver is probed. As a stop gap until
that is in place, honour remove_conflicting_framebuffers() and
delete the simple-framebuffer platform device when it's called.
Signed-off-by: Noralf Trønnes
---
driver
Create a simple fbdev device during SimpleDRM setup so legacy user-space
and fbcon can use it.
Original work by David Herrmann.
Cc: dh.herrmann at gmail.com
Signed-off-by: Noralf Trønnes
---
Changes from version 1:
No changes
Changes from previous version:
- Remove the DRM_SIMPLEDRM_FBDEV k
The SimpleDRM driver binds to simple-framebuffer devices and provides a
DRM/KMS API. It provides only a single CRTC+encoder+connector combination
plus one initial mode.
Userspace can create dumb-buffers which can be blit into the real
framebuffer similar to UDL. No access to the real framebuffer i
This patchset adds the simpledrm driver by David Herrmann based on a
patchset[1] from 2014. That patchset also included patches for kicking
out simpledrm by real drivers. I have stayed away from that since it
involves another subsystem and I would probably be unable to answer any
questions about th
was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160805/7c18ccd7/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160805/1a2d3504/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160805/1088b1ed/attachment.html>
nts/20160805/6a26ba16/attachment.html>
Hi Heiko,
On 2016å¹´08æ05æ¥ 06:37, Heiko Stuebner wrote:
> Am Freitag, 29. Juli 2016, 15:56:55 schrieb Lin Huang:
>> From: Heiko Stübner
>>
>> add clock flag parameter so we can pass specific clock flag
>> (like CLK_GET_RATE_NOCACHE etc..)to pll driver.
>>
>> Signed-off-by: Heiko Stübner
>>
Hi Dave, a few more fixes for the merge window. I know the timing
probably isn't good, apologies.
I see the PSR fixes in Linus' tree, and then there's the lockdep fix
we'd like you to pick up directly [1].
BR,
Jani.
[1]
http://patchwork.freedesktop.org/patch/msgid/1470328548-27533-1-git-send-
Tomeu,
o_O
Ignore my previous email, seems I make a mistaken about the email
format, and mess up the patch format.
I have move my previous comments to this one :-)
On 08/04/2016 02:23 PM, Tomeu Vizoso wrote:
> Remove code for reading the EDID and DPCD fields and use the helpers
> instead.
>
>
Tomeu,
Nice job ! Have a few nits bellow. ;)
On 08/04/2016 02:23 PM, Tomeu Vizoso wrote:
> Remove code for reading the EDID and DPCD fields and use the helpers
> instead.
>
> Besides the obvious code reduction, other helpers are being added to the
> core that could be used in this driver and wil
https://bugzilla.kernel.org/show_bug.cgi?id=151541
--- Comment #4 from Dainius Masiliūnas ---
Yes, it does. With that setting, there are no errors either, and lspci runs
quickly.
--
You are receiving this mail because:
You are watching the assignee of the bug.
On 29 July 2016 at 09:56, Lin Huang wrote:
> rk3399 platform have dfi controller can monitor ddr load,
> and dcf controller to handle ddr register so we can get the
> right ddr frequency and make ddr controller happy work(which
> will implement in bl31). So we do ddr frequency scaling with
> follo
This patch is blocking PSR on panels that we know that our hardware support.
I wonder if:
1. This restrictions was for older platforms and spec is out dated
2. Or Spec is not documenting the restriction properly
3. Or we have some issue with out setup time calculation.
On Tue, May 31, 2016 at 8:
Remove code for reading the EDID and DPCD fields and use the helpers
instead.
Besides the obvious code reduction, other helpers are being added to the
core that could be used in this driver and will be good to be able to
use them instead of duplicating them.
Signed-off-by: Tomeu Vizoso
Tested-by
On Thu, Aug 4, 2016 at 1:26 AM, Daniel Vetter wrote:
> On Wed, Aug 03, 2016 at 02:33:39PM -0700, Rodrigo Vivi wrote:
>> DC state reset the frame counter that is a read-only register.
>>
>> So, besides blocking DC state on vblank let's restore the
>> drm crtc vblank counter to a place we know it is
On Fri, Aug 05, 2016 at 12:46:29PM +0200, Tomeu Vizoso wrote:
> On 3 August 2016 at 09:06, Ville Syrjälä
> wrote:
> > On Fri, Jul 22, 2016 at 04:10:44PM +0200, Tomeu Vizoso wrote:
> >> Adds files and directories to debugfs for controlling and reading frame
> >> CRCs, per CRTC:
> >>
> >> dri/0/c
Hi, YT:
On Thu, 2016-08-04 at 19:07 +0800, YT Shen wrote:
> This patch add support for the Mediatek MT2701 DISP subsystem.
> There is only one OVL engine in MT2701.
>
> Signed-off-by: YT Shen
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c |6 ++
> drivers/gpu/drm/mediatek/mtk_disp_
Hi Dave,
A few fixes for amdgpu and ttm for 4.8
- fix a ttm regression caused by the new pipelining code
- fixes for mullins on amdgpu
- updated golden settings for amdgpu
The following changes since commit 1cf915d305b6e1d57db6c35c208016f9747ba3c6:
Merge tag 'imx-drm-fixes-2016-07-27' of
git:
Hi, YT:
On Thu, 2016-08-04 at 19:07 +0800, YT Shen wrote:
> This patch adds the device nodes for the DISP function blocks for MT2701
>
> Signed-off-by: YT Shen
> ---
> arch/arm/boot/dts/mt2701.dtsi | 86
> +
> 1 file changed, 86 insertions(+)
>
> diff
vel/attachments/20160805/a0b62d0b/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160805/a7095f62/attachment.html>
--- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160805/81cd4973/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=151541
--- Comment #3 from Alex Deucher ---
On the kernel command line in grub.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=151541
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #2 f
The patch
ASoC: hdmi-codec: enable multi probe for same device
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and se
On 3 August 2016 at 09:06, Ville Syrjälä
wrote:
> On Fri, Jul 22, 2016 at 04:10:44PM +0200, Tomeu Vizoso wrote:
>> Adds files and directories to debugfs for controlling and reading frame
>> CRCs, per CRTC:
>>
>> dri/0/crtc-0/crc
>> dri/0/crtc-0/crc/control
>> dri/0/crtc-0/crc/data
>>
>> Drivers
Use drm_accurate_vblank_count so we have the full 32 bit to represent
the frame counter and userspace has a simpler way of knowing when the
counter wraps around.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/i915/i915_irq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --g
The core provides now an ABI to userspace for generation of frame CRCs,
so implement the ->set_crc_source() callback and reuse as much code as
possible with the previous ABI implementation.
v2:
- Leave the legacy implementation in place as the ABI implementation
in the core is incompatib
Adds files and directories to debugfs for controlling and reading frame
CRCs, per CRTC:
dri/0/crtc-0/crc
dri/0/crtc-0/crc/control
dri/0/crtc-0/crc/data
Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
start and stop generating frame CRCs and can add entries to the output
b
In preparation to using a generic API in the DRM core for continuous CRC
generation, move the related code out of i915_debugfs.c into a new file.
Eventually, only the Intel-specific code will remain in this new file.
v2: Rebased.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/i915/Makefile
Hi,
this series basically takes the facility for continuously capturing CRCs
of frames from the i915 driver and into the DRM core.
The idea is that test suites such as IGT use this information to check
that frames that are exected to be identical, also have identical CRC
values.
Other drivers fo
it's easier for people to work this out and send patches to
him?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-de
On 08/04/16 17:07, Russell King - ARM Linux wrote:
> On Tue, Aug 02, 2016 at 03:05:08PM +0300, Jyri Sarha wrote:
>> +memcpy(audio.status, params->iec.status,
>> + min(sizeof(audio.status), sizeof(params->iec.status)));
>
> As mentioned in the other patch, the audio status does not di
On 08/04/16 16:31, Russell King - ARM Linux wrote:
> On Tue, Aug 02, 2016 at 03:05:07PM +0300, Jyri Sarha wrote:
>> @@ -787,19 +792,13 @@ tda998x_configure_audio(struct tda998x_priv *priv,
>> reg_clear(priv, REG_AIP_CNTRL_0, AIP_CNTRL_0_RST_CTS);
>>
>> /* Write the channel status */
>>
https://bugzilla.kernel.org/show_bug.cgi?id=118611
K. Paden changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Add New Vision Display 7.0" 800 RGB x 480 TFT LCD panel
Signed-off-by: Fabien Lahoudere
---
.../devicetree/bindings/display/panel/nvd,9128.txt | 7 ++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
drivers/gpu/drm/panel/panel-simple.c | 26 ++
3
Am 05.08.2016 um 11:40 schrieb Michel Dänzer:
> From: Michel Dänzer
>
> Fixes hangs under memory pressure, e.g. running the piglit test
> tex3d-maxsize concurrently with other tests.
>
> Fixes: 17d33bc9d6ef ("drm/ttm: drop waiting for idle in ttm_bo_evict.")
> Signed-off-by: Michel Dänzer
Ah,
On Thu, 04 Aug 2016, David Herrmann wrote:
> Hi
>
> On Thu, Aug 4, 2016 at 10:01 PM, Daniel Vetter wrote:
>> On Thu, Aug 04, 2016 at 02:50:37PM -0500, Ken Phillis Jr wrote:
>>> I believe this driver is extremely useful, and I see possible issues with
>>> the fact that the driver is GPL Only. This
On Fri, Aug 05, 2016 at 11:04:21AM +0200, Enrico Weigelt, metux IT consult
wrote:
> On 05.08.2016 10:15, Daniel Vetter wrote:
>
> Hi,
>
> > There's a driver cap DRM_CAP_DUMB_PREFER_SHADOW for this. If set,
> > render into a shadow buffer and copy over in bursts, otherwise you
> > can assume that
On Fri, Aug 05, 2016 at 10:57:58AM +0200, Jiri Kosina wrote:
> On Thu, 4 Aug 2016, Daniel Vetter wrote:
>
> > drm_connector_register_all requires a few too many locks because our
> > connector_list locking is busted. Add another FIXME+hack to work
> > around this. This should address the below loc
On Thu, 04 Aug 2016, Daniel Vetter wrote:
> drm_connector_register_all requires a few too many locks because our
> connector_list locking is busted. Add another FIXME+hack to work
> around this. This should address the below lockdep splat:
Jiri, a Tested-by on this would be appreciated.
BR,
Jani
On 05.08.2016 10:15, Daniel Vetter wrote:
Hi,
> There's a driver cap DRM_CAP_DUMB_PREFER_SHADOW for this. If set,
> render into a shadow buffer and copy over in bursts, otherwise you
> can assume that the memory is fully cpu cached and fast with random
> access.
h!
nekrad at orion:~/src/lin
On Thu, 4 Aug 2016, Daniel Vetter wrote:
> drm_connector_register_all requires a few too many locks because our
> connector_list locking is busted. Add another FIXME+hack to work
> around this. This should address the below lockdep splat:
[ ... snip ... ]
> v2: Rebase onto the right branch (hand-e
Hi Lin,
Am Freitag, 5. August 2016, 16:50:49 schrieb hl:
> On 2016å¹´08æ05æ¥ 06:37, Heiko Stuebner wrote:
> > Am Freitag, 29. Juli 2016, 15:56:55 schrieb Lin Huang:
> >> From: Heiko Stübner
> >>
> >> add clock flag parameter so we can pass specific clock flag
> >> (like CLK_GET_RATE_NOCACHE
From: Gustavo Padovan
Signalling doesn't need to be enabled at sync_file creation, it is only
required if userspace waiting the fence to signal through poll().
Thus we delay fence_add_callback() until poll is called. It only adds the
callback the first time poll() is called. This avoid re-adding
From: Gustavo Padovan
Document the new function added to sync_file.c
v2: Adapt to fence_array
v3: Take in Chris Wilson suggestions
Signed-off-by: Gustavo Padovan
Acked-by: Christian König
Reviewed-by: Chris Wilson
---
Documentation/sync_file.txt | 14 ++
1 file changed, 14 ins
From: Gustavo Padovan
Creates a function that given an sync file descriptor returns a
fence containing all fences in the sync_file.
v2: Comments by Daniel Vetter
- Adapt to new version of fence_collection_init()
- Hold a reference for the fence we return
v3:
- Adapt to u
From: Gustavo Padovan
Create sync_file->fence to abstract the type of fence we are using for
each sync_file. If only one fence is present we use a normal struct fence
but if there is more fences to be added to the sync_file a fence_array
is created.
This change cleans up sync_file a bit. We don'
From: Gustavo Padovan
Add helper to check if fence is array.
v2: Comments from Chris Wilson
- remove ternary if from ops comparison
- add EXPORT_SYMBOL(fence_array_ops)
Cc: Chris Wilson
Cc: Christian König
Signed-off-by: Gustavo Padovan
Reviewed-by: Chris Wilson
Reviewed-by
On Fri, Aug 05, 2016 at 04:35:25AM +0200, Enrico Weigelt, metux IT consult
wrote:
> Hi folks,
>
>
> when putting pixels into an DRM framebuffer, should I do that in
> bursts/blocks instead of byte-per-byte ? (eg. explicitly using
> aligned 32bit ops).
There's a driver cap DRM_CAP_DUMB_PREFER_SH
On 05.08.2016 02:31, Bridgman, John wrote:
>> -Original Message-
>> From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf
>> Of Daniel Vetter
>>
>> Another option for entirely fake outputs would be vkms.ko, similar to
>> vgem.ko. With the simple display driver it sh
On Thu, Aug 04, 2016 at 02:08:46PM -0400, Mike Marshall wrote:
> [1.291797] [drm] Initialized drm 1.1.0 20060810
> [1.352761] [TTM] Zone kernel: Available graphics memory: 502128 kiB
> [1.353248] [TTM] Initializing pool allocator
> [1.353660] [TTM] Initializing DMA pool allocator
>
On Fri, Aug 05, 2016 at 12:01:25AM +0100, Russell King - ARM Linux wrote:
> On Thu, Aug 04, 2016 at 06:13:18PM +0100, Jose Abreu wrote:
> > Hi Russell,
> >
> > So, I didn't use framebuffer console but used X instead and it is
> > working as it should. I think we can drop this patch. I am now
> > m
https://bugzilla.kernel.org/show_bug.cgi?id=151541
--- Comment #1 from Dainius Masiliūnas ---
Using radeon.dpm=0 doesn't change anything, only the "*ERROR* radeon: dpm
resume failed" line is not there in that case.
--
You are receiving this mail because:
You are watching the assignee of the bu
Am 04.08.2016 um 17:42 schrieb Amitoj Kaur Chawla:
> To indicate an error, debugfs_create_file can return an ERR_PTR for
> !CONFIG_DEBUG_FS and NULL otherwise, so in case the result is
> dereferenced there should be a previous IS_ERR and a NULL check.
>
> The Coccinelle semantic patch used to find
https://bugzilla.kernel.org/show_bug.cgi?id=151541
Dainius Masiliūnas changed:
What|Removed |Added
Attachment #227711|text/x-log |text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=151541
Bug ID: 151541
Summary: AMD hybrid graphics: [drm:evergreen_resume [radeon]]
*ERROR* evergreen startup failed on resume
Product: Drivers
Version: 2.5
Kernel Version: 4.7.0
On Fri, Aug 05, 2016 at 06:37:26AM +0200, Enrico Weigelt, metux IT consult
wrote:
> On 05.08.2016 01:16, Enrico Weigelt, metux IT consult wrote:
>
>
> Seems I've been on a completely wrong path - what I'm looking
> for is dma-buf. So my idea now goes like this:
>
> * add a new 'virtual GPU' as
On Fri, Aug 05, 2016 at 01:16:55AM +0200, Enrico Weigelt, metux IT consult
wrote:
> On 04.08.2016 09:50, Daniel Vetter wrote:
>
> Hi,
>
> > One problem with 2d blitters is that there's no common userspace
> > interface, but many: Xrender, hwc, old X drawing api, various attempts by
> > khronos t
Hi Peter,
Only one comment below and one nitpick
2016-08-05 0:37 GMT+02:00 Peter Senna Tschudin :
> Add a driver that create a drm_bridge and a drm_connector for the LVDS
> to DP++ display bridge of the GE B850v3.
>
> There are two physical bridges on the video signal pipeline: a
> STDP4028(LVDS
On Fri, Aug 5, 2016 at 8:59 AM, Tomeu Vizoso
wrote:
> Remove code for reading the EDID and DPCD fields and use the helpers
> instead.
>
> Besides the obvious code reduction, other helpers are being added to the
> core that could be used in this driver and will be good to be able to
> use them ins
Hi Peter,
2016-08-05 0:36 GMT+02:00 Peter Senna Tschudin :
> Devicetree bindings documentation for the GE B850v3 LVDS/DP++
> display bridge.
>
> Cc: Javier Martinez Canillas
> Cc: Enric Balletbo i Serra
> Cc: Philipp Zabel
> Cc: Rob Herring
> Cc: Fabio Estevam
> Signed-off-by: Peter Senna Tsc
Hi,
On 04-08-16 20:12, Luc Verhaegen wrote:
> On Thu, Aug 04, 2016 at 06:58:55PM +0200, Noralf Trønnes wrote:
>>
>> I didn't read the binding document[1], which I should have done.
>> If simpledrm claims to be compatible with simple-framebuffer I assume it
>> should support the entire binding doc
On Fri, Aug 05, 2016 at 10:06:08AM +0200, Daniel Vetter wrote:
> On Fri, Aug 05, 2016 at 12:01:25AM +0100, Russell King - ARM Linux wrote:
> > On Thu, Aug 04, 2016 at 06:13:18PM +0100, Jose Abreu wrote:
> > > Hi Russell,
> > >
> > > So, I didn't use framebuffer console but used X instead and it is
1 - 100 of 117 matches
Mail list logo
