https://bugzilla.kernel.org/show_bug.cgi?id=91861
--- Comment #6 from Mike S. ---
I can confirm that the patch
https://bugzilla.kernel.org/attachment.cgi?id=163891 to cap ref_div to 7 fixes
the problem on my RS780. I did the test on kernel 3.18.3. Note that I also cast
the number 7 in the min() t
anymore.
However Radeon still crashes, now in radeon_driver_postclose_kms.
--
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/2015012
[ Hm... That's weird. I don't know why this old bug is showing up in
my new bugs pile. Oh well, it looks valid. ]
Hello Ben Skeggs,
The patch 88524bc06926: "drm/nouveau/devinit: move simple pll setting
routines to devinit" from Mar 5, 2013, leads to the following static
checker warning:
andling code for how
to limit the sclk and mclk.
--
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/20150128/f7204742/attachment.html>
On Wed, Jan 28, 2015 at 10:15:29AM -0800, Haixia Shi wrote:
> The run-length encoding algorithm should compare 16-bit encoded pixel
> values instead of comparing raw pixel values. It allows pixels
> with similar but different colors to be encoded as repeat pixels, and
> thus potentially save USB ba
On Wed, Jan 28, 2015 at 10:15:30AM -0800, Haixia Shi wrote:
> The prefetch_range amount is already in number of bytes. Multiplying again by
> bpp is unnecessary.
>
> Signed-off-by: Haixia Shi
> Reviewed-by: Daniel Kurtz
> Tested-by: Haixia Shi
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/2145b6d3/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/ab9801d1/attachment.html>
e the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/53ce7a79/attachment.html>
org/archives/dri-devel/attachments/20150128/2ae300b7/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/9ab5d931/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #28 from Gustaw Smolarczyk ---
Created attachment 165091
--> https://bugzilla.kernel.org/attachment.cgi?id=165091&action=edit
dmesg after "Print refcounts..." patch
I have applied this patch on top of original "another approach" one
act the that acceleration does not seem to initialized properly.
--
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/20
Hi Mauro,
On 28 January 2015 at 18:53, Mauro Carvalho Chehab
wrote:
> Em Wed, 28 Jan 2015 18:24:03 +0530
> Sumit Semwal escreveu:
>
>> +/**
>> + * helper macro for exporters; zeros and fills in most common values
>> + */
>> +#define DEFINE_DMA_BUF_EXPORT_INFO(a)\
>> + struct dma_buf_
mpletely idle.
--
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/20150128/b0a61de1/attachment.html>
From: Rob Clark
In DRM/KMS we are lacking a good way to deal with tiled/compressed
formats. Especially in the case of dmabuf/prime buffer sharing, where
we cannot always rely on under-the-hood flags passed to driver specific
gem-create ioctl to pass around these extra flags.
The proposal is to
---
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/91ae11d2/attachment-0001.html>
At present, dma_buf_export() takes a series of parameters, which
makes it difficult to add any new parameters for exporters, if required.
Make it simpler by moving all these parameters into a struct, and pass
the struct * as parameter to dma_buf_export().
While at it, unite dma_buf_export_named()
On 01/28/2015 05:37 PM, Daniel Vetter wrote:
> From: Rob Clark
>
> In DRM/KMS we are lacking a good way to deal with tiled/compressed
> formats. Especially in the case of dmabuf/prime buffer sharing, where
> we cannot always rely on under-the-hood flags passed to driver specific
> gem-create ioc
On 28 January 2015 at 16:50, Daniel Thompson
wrote:
> On 28/01/15 06:00, Sumit Semwal wrote:
>> +/**
>> + * helper macro for exporters; zeros and fills in most common values
>> + */
>> +#define DEFINE_DMA_BUF_EXPORT_INFO(a)\
>> + struct dma_buf_export_info a = {0};
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/50792b78/attachment.html>
Add compatible strings for the SOR IP blocks present on several Tegra
chips. The primary objective here is to avoid checkpatch warnings,
per:
http://marc.info/?l=linux-tegra&m=142201349727836&w=2
Signed-off-by: Paul Walmsley
Cc: Thierry Reding
Cc: "Terje Bergström"
Cc: Rob Herring
Cc: Pawe
From: Dave Airlie
With drm-next, we can get a backtrace like below,
this is due to the callback checking the txmsg state taking
the mutex, which can cause a sleep inside a sleep,
Fix this my creating a spinlock protecting the txmsg state
and locking it in appropriate places.
: [ cut
Op 28-01-15 om 13:54 schreef Sumit Semwal:
> At present, dma_buf_export() takes a series of parameters, which
> makes it difficult to add any new parameters for exporters, if required.
>
> Make it simpler by moving all these parameters into a struct, and pass
> the struct * as parameter to dma_buf_
Hi Dave,
please consider merging these fixes that correct issues in the IPUv3
IPUv3 core and imx-drm TVE encoder code:
The following changes since commit 5159571ceb44eba9bf9f9a34ec625386d421de9c:
Merge branch 'drm-fixes-3.19' of git://people.freedesktop.org/~agd5f/linux
into drm-fixes (2015-0
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #27 from Maarten Lankhorst ---
Created attachment 165071
--> https://bugzilla.kernel.org/attachment.cgi?id=165071&action=edit
Print refcounts on sw irq, panic on disabled.
Can you test this patch on top of 'another approach', keep t
On Wednesday 28 January 2015 14:48:09 Arnd Bergmann wrote:
> The msm gpu drivers depend on both the DT mechanism and the
> common clk handling code, if they are not enabled, we get
> ...
As should be obvious, this one was meant to be [PATCH 5/5], but
I messed up the subject line.
Arnd
Hello,
On 2015-01-27 09:25, Sumit Semwal wrote:
> From: Rob Clark
>
> For devices which have constraints about maximum number of segments in
> an sglist. For example, a device which could only deal with contiguous
> buffers would set max_segment_count to 1.
>
> The initial motivation is for devi
The msm gpu drivers depend on both the DT mechanism and the
common clk handling code, if they are not enabled, we get
a number of build errors:
In file included from drivers/gpu/drm/msm/hdmi/hdmi.h:27:0,
from drivers/gpu/drm/msm/hdmi/hdmi_bridge.c:18:
drivers/gpu/drm/msm/msm_drv.h
The newly added sti driver requires the drm_panel helpers,
and we get a link error if they are not enabled
ERROR: "drm_panel_attach" [drivers/gpu/drm/sti/stidvo.ko] undefined!
ERROR: "of_drm_find_panel" [drivers/gpu/drm/sti/stidvo.ko] undefined!
This adds a 'select' statement as we have for the o
When the reset controller subsystem is disabled, this driver
fails to build:
drivers/gpu/drm/rockchip/rockchip_drm_vop.c: In function 'vop_initial':
drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1267:2: error: implicit declaration
of function 'devm_reset_control_get' [-Werror=implicit-function-decl
The simple panel code uses the backlight interface to
find a device, which fails when backlight is disabled:
drivers/built-in.o: In function `panel_simple_platform_probe':
:(.text+0xd3c48): undefined reference to `of_find_backlight_by_node'
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/panel
The sharp panel code uses the backlight interface to
find a device, which fails when backlight is disabled:
drivers/built-in.o: In function `sharp_panel_probe':
:(.text+0x5ceac): undefined reference to `of_find_backlight_by_node'
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/panel/Kconfig |
I did lots of randconfig tests over time, which resulted in many patches,
five of which are for drm. In each of these cases, the Kconfig dependencies
are incomplete, which can lead to broken builds, and specifying the
complete dependencies solves it.
The patches are all independent from one anothe
Hi Dan,
nit: this patch is not really for "drm/bridge".
On Wed, Jan 28, 2015 at 2:43 PM, Dan Carpenter
wrote:
>
> We were supposed to check "fmts" here instead of "formats". I suppose
> it eventually leads to a NULL dereference.
>
> Signed-off-by: Dan Carpenter
>
Otherwise, good catch!
Revi
If acceleration is disabled, it does not make sense
to init gpuvm since nothing will use it. Moreover,
if radeon_vm_init() gets called it uses accel to try
and clear the pde tables, etc. which results in a bug.
Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=88786
Signed-off-by: Alex Deucher
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/20150128/d916942e/attachment.html>
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/102b4432/attachment.html>
On Wed, Jan 28, 2015 at 12:56:06PM +, Ian Molton wrote:
> On 28/01/15 12:52, Sascha Hauer wrote:
> >Hi Ian,
> >
> >On Wed, Jan 28, 2015 at 12:08:19PM +, Ian Molton wrote:
> >>Hi,
> >>
> >>Can anyone tell me where best to follow / contribute to *mainline* kernel
> >>based imx6 graphics stuf
Hi Ian,
On Wed, Jan 28, 2015 at 12:08:19PM +, Ian Molton wrote:
> Hi,
>
> Can anyone tell me where best to follow / contribute to *mainline* kernel
> based imx6 graphics stuff?
>
> I'm currently running a 3.19-rc kernel with imx6 drm (fbdev emulation) and it
> works, but I'm seeing segfaul
Sorry about that; I have just re-sent the patches based on upstream code.
On Wed, Jan 28, 2015 at 1:12 PM, Chris Wilson
wrote:
> On Wed, Jan 28, 2015 at 10:15:29AM -0800, Haixia Shi wrote:
>> The run-length encoding algorithm should compare 16-bit encoded pixel
>> values instead of comparing raw
On Wed, Jan 28, 2015 at 12:37 PM, Daniel Vetter
wrote:
> From: Rob Clark
>
> In DRM/KMS we are lacking a good way to deal with tiled/compressed
> formats. Especially in the case of dmabuf/prime buffer sharing, where
> we cannot always rely on under-the-hood flags passed to driver specific
> gem
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/44b054b7/attachment.html>
rt --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/d0ac7a36/attachment.html>
The prefetch_range amount is already in number of bytes. Multiplying again by
bpp is unnecessary.
Signed-off-by: Haixia Shi
Reviewed-by: Daniel Kurtz
Tested-by: Haixia Shi
---
drivers/gpu/drm/udl/udl_transfer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm
The run-length encoding algorithm should compare 16-bit encoded pixel
values instead of comparing raw pixel values. It allows pixels
with similar but different colors to be encoded as repeat pixels, and
thus potentially save USB bandwidth.
Signed-off-by: Haixia Shi
Reviewed-by: Daniel Kurtz
Test
On 28/01/15 12:52, Sascha Hauer wrote:
> Hi Ian,
>
> On Wed, Jan 28, 2015 at 12:08:19PM +, Ian Molton wrote:
>> Hi,
>>
>> Can anyone tell me where best to follow / contribute to *mainline* kernel
>> based imx6 graphics stuff?
>>
>> I'm currently running a 3.19-rc kernel with imx6 drm (fbdev em
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #26 from Jon Arne Jørgensen ---
I've tested, and can confirm that they are needed for the patch to fix the
crash.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #25 from Maarten Lankhorst ---
Oke, can you test without the calls to sw_irq_get/put?
--
You are receiving this mail because:
You are watching the assignee of the bug.
Hi,
Can anyone tell me where best to follow / contribute to *mainline* kernel based
imx6 graphics stuff?
I'm currently running a 3.19-rc kernel with imx6 drm (fbdev emulation) and it
works, but I'm seeing segfaults from Xfbdev.
Presumably, theres a proper DRM/DRI X driver to go with the kernel
From: Stéphane Marchesin
This panel is used by the Nyan Blaze board and supported by the simple-panel
driver.
Signed-off-by: Stéphane Marchesin
[tomeu.vizoso at collabora.com: add device tree binding document]
Signed-off-by: Tomeu Vizoso
---
.../bindings/panel/samsung,ltn140at29-301.txt
. I have tested that USB2, the panels,
HDMI, the trackpad, Wifi and sound work on both.
The DT for the Big includes the pinmux configuration as generated by
tegra-pinmux-scripts with Simon's patch at:
https://patchwork.ozlabs.org/patch/417779/
These patches are based on top of linux-next 201
On Wed, 28 Jan 2015, Daniel Vetter wrote:
> On Wed, Jan 28, 2015 at 10:59:06AM +0200, Jani Nikula wrote:
>> On Tue, 27 Jan 2015, Ville Syrjälä
>> wrote:
>> > So I've been experimenting a bit with various dongles here, and sadly I've
>> > not managed to get any one of them to return short reads
On Wed, Jan 28, 2015 at 11:09:21AM +0200, Jani Nikula wrote:
> On Tue, 27 Jan 2015, Simon Farnsworth
> wrote:
> > DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs in
> > their I2C over AUX implementation. They work fine with Windows, but fail
> > with Linux.
> >
> > It turns
On Wed, Jan 28, 2015 at 11:33:34AM +0200, Jani Nikula wrote:
> On Wed, 28 Jan 2015, Daniel Vetter wrote:
> > On Wed, Jan 28, 2015 at 10:59:06AM +0200, Jani Nikula wrote:
> >> On Tue, 27 Jan 2015, Ville Syrjälä
> >> wrote:
> >> > So I've been experimenting a bit with various dongles here, and s
At present, dma_buf_export() takes a series of parameters, which
makes it difficult to add any new parameters for exporters, if required.
Make it simpler by moving all these parameters into a struct, and pass
the struct * as parameter to dma_buf_export().
While at it, unite dma_buf_export_named()
Em Wed, 28 Jan 2015 18:24:03 +0530
Sumit Semwal escreveu:
> +/**
> + * helper macro for exporters; zeros and fills in most common values
> + */
> +#define DEFINE_DMA_BUF_EXPORT_INFO(a)\
> + struct dma_buf_export_info a = { .exp_name = KBUILD_MODNAME }
> +
I suspect that this will let
On 28/01/15 06:00, Sumit Semwal wrote:
> At present, dma_buf_export() takes a series of parameters, which
> makes it difficult to add any new parameters for exporters, if required.
>
> Make it simpler by moving all these parameters into a struct, and pass
> the struct * as parameter to dma_buf_exp
On Tue, 27 Jan 2015, Simon Farnsworth wrote:
> DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs in
> their I2C over AUX implementation. They work fine with Windows, but fail
> with Linux.
>
> It turns out that they cannot keep an I2C transaction open unless the
> previous read
On Tue, 27 Jan 2015, Ville Syrjälä wrote:
> So I've been experimenting a bit with various dongles here, and sadly I've
> not managed to get any one of them to return short reads :(
>
> I did find one that allows changing the speed of the i2c bus, but even if
> I reduce it to 1khz there are no sh
s assistance analysing the differences in behaviour
between us and Windows).
--
Simon Farnsworth
Software Engineer
ONELAN Ltd
http://www.onelan.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/336fc10c/attachment.sig>
llvm 3.6 behavior in lately february.
--
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/20150128/6466d8a5/attachment-0001.html>
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/993e1411/attachment.html>
The prefetch_range amount is already in number of bytes. Multiplying again by
bpp is unnecessary.
Signed-off-by: Haixia Shi
Reviewed-by: Daniel Kurtz
Tested-by: Haixia Shi
---
drivers/gpu/drm/udl/udl_transfer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm
The run-length encoding algorithm should compare 16-bit encoded pixel
values instead of comparing raw pixel values. It allows pixels
with similar but different colors to be encoded as repeat pixels, and
thus potentially save USB bandwidth.
Signed-off-by: Haixia Shi
Reviewed-by: Daniel Kurtz
Test
On Wed, Jan 28, 2015 at 10:59:06AM +0200, Jani Nikula wrote:
> On Tue, 27 Jan 2015, Ville Syrjälä wrote:
> > So I've been experimenting a bit with various dongles here, and sadly I've
> > not managed to get any one of them to return short reads :(
> >
> > I did find one that allows changing the
Hi Dave,
The following changes since commit 21773f16f2cb3c056051c679da542f0b494252e2:
Merge tag 'topic/atomic-core-2015-01-27' of
git://anongit.freedesktop.org/drm-intel into drm-next (2015-01-28 09:34:27
+1000)
are available in the git repository at:
git://anongit.freedesktop.org/tegra/l
On Wed, Jan 28, 2015 at 04:37:01PM +1300, Dave Airlie wrote:
> From: Dave Airlie
>
> With drm-next, we can get a backtrace like below,
> this is due to the callback checking the txmsg state taking
> the mutex, which can cause a sleep inside a sleep,
>
> Fix this my creating a spinlock protecting
Building with the attached random configuration file,
drivers/built-in.o: In function `panel_simple_probe':
panel-simple.c:(.text+0x37cfd): undefined reference to
`of_find_backlight_by_node'
drivers/built-in.o: In function `sharp_panel_probe':
panel-sharp-lq101r1sx01.c:(.text+0x383ef): undefined r
Hi Thierry,
Am Mittwoch, den 28.01.2015, 09:00 +0100 schrieb Thierry Reding:
> On Tue, Jan 27, 2015 at 04:17:51PM +0100, Philipp Zabel wrote:
> > Hi Fabio,
> >
> > Am Dienstag, den 27.01.2015, 10:54 -0200 schrieb Fabio Estevam:
> > > If devm_request_threaded_irq() fails we should jump to 'err_iah
We were supposed to check "fmts" here instead of "formats". I suppose
it eventually leads to a NULL dereference.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 98fb640..8ae239f 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm
erator
>
> Thanks for the fix. I have applied this to my tree since I've introduced
> the bug in there.
I'm currently redoing the drm/{panel,bridge} pull request anyway, so I
could apply this while at it.
Thierry
-- next part --
A non-text attachment was sc
- 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/20150128/96e4203c/attachment.sig>
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/35a7d5aa/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150128/087d95c3/attachment.html>
eiving 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/20150128/32e900a4/attachment.html>
On 28 January 2015 at 04:04, Linus Torvalds
wrote:
> On Mon, Jan 26, 2015 at 6:06 PM, Dave Airlie wrote:
>>
>> are available in the git repository at:
>>
>> git://people.freedesktop.org/~airlied/linux drm-fixes
>
> No they aren't, actually, because you've screwed up your repository.
>
> It look
..
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/f241f922/attachment.html>
t's probably a kernel regression, can you bisect?
--
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/20150128/2befa7d0/attachment.html>
patches in the 3.19.0-rc6+ kernel, I still experienced a
lockup.
--
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/2015012
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/6a5e2010/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/60f0f0d2/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150128/4ce26189/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150128/6d6236fd/attachment.html>
84 matches
Mail list logo
