https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #78 from Dieter Nützel ---
(In reply to Gustaw Smolarczyk from comment #77)
> No pauses after I applied attachment 166571 [details] and "drm/radeon: do a
> posting read in si_set_irq" from posting-read branch on top of v3.19. So I
> g
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #77 from Gustaw Smolarczyk ---
No pauses after I applied attachment 166571 and "drm/radeon: do a posting read
in si_set_irq" from posting-read branch on top of v3.19. So I guess these
commits combined fix this issue.
@Dieter: I did no
On Tue, Mar 03, 2015 at 09:12:47AM -0800, Linus Torvalds wrote:
> On Tue, Mar 3, 2015 at 9:11 AM, Daniel Vetter wrote:
> >
> > Fine with me. If you haven't pushed out yet can you maybe clarify the
> > commit message?
>
> Oh well. I already applied and tagged it, so it's what it is..
No biggie, t
On Tue, Mar 03, 2015 at 09:03:32AM -0800, Linus Torvalds wrote:
> On Tue, Mar 3, 2015 at 8:31 AM, Daniel Vetter
> wrote:
> >
> > Fix this all by applying the same duct-tape as for the legacy setcrtc
> > ioctl code and set crtc->primary->crtc properly.
>
> Ack. Tests fine on the machine that show
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Dieter Nützel changed:
What|Removed |Added
CC||Dieter at nuetzel-hh.de
--- Comment #76
On Mon, Mar 02, 2015 at 04:35:20PM +0100, Daniel Vetter wrote:
> This reverts commit 3f678c96abb43a977d2ea41aefccdc49e8a3e896.
>
> We've been a bit too optimistic with this one here :(
>
> The trouble is that internally we're still using these plane
> update/disable hooks. Which was totally ok pr
This is a tricky story of the new atomic state handling and the legacy
code fighting over each another. The bug at hand is an underrun of the
framebuffer reference with subsequent hilarity caused by the load
detect code. Which is peculiar since the the exact same code works
fine as the implementati
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150303/65c9ddc3/attachment.html>
On Tue, Mar 3, 2015 at 12:46 AM, Simon Glass wrote:
> Hi,
>
> On 2 March 2015 at 01:41, Alexandre Courbot wrote:
>>
>> On Thu, Feb 12, 2015 at 5:51 PM, Tomeu Vizoso
>> wrote:
>> > As there isn't a way for the firmware on the Nyan chromebooks to hand
>> > over the display to the kernel.
>>
>> Cou
Hi Dave,
The following changes since commit 329414c4e7b7506fe3eab545b3fc9e44b7f28a10:
Merge tag 'topic/drm-misc-2015-02-25' of git://anongit.freedesktop.org/drm-
intel into drm-next (2015-02-26 10:32:55 +1000)
are available in the git repository at:
git://linuxtv.org/pinchartl/fbdev.git drm
On 03/02/2015 02:19 PM, Laurent Pinchart wrote:
> From: Laurent Pinchart
>
> Remove the internal dependency on DPMS mode for power management by
> using a by a powered state boolean instead, and use the new power off
> handler at probe time. This ensure that the regmap cache is properly
> marked a
On Sat, 28 Feb 2015, Michael Leuchtenburg wrote:
> No changes, even while the brightness is in the process of changing. Is it
> possible there's some other bit used on this hardware? The Broadwell chips
> are pretty new. I haven't had a chance to look for specs yet.
The DPCD info is specific to y
Add a reserved-memory region for bootloader splashscreen, and assign it
to the display device, so that drm/msm can take over the bootloader's
splashscreen.
Signed-off-by: Rob Clark
---
arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/
Add support to use the VRAM carveout (if specified in dtb) for fbdev
scanout buffer. This allows drm/msm to take over a bootloader splash-
screen, and avoids corruption on screen that results if the kernel uses
memory that is still being scanned out for itself.
Signed-off-by: Rob Clark
---
driv
We'll want to extend this a bit to handle also a reserved-memory
("stolen") region, so that drm/msm can take-over bootloader splash
screen. First split it out into it's own fxn to reduce noise in
the following patch.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 58 ++
From: Tvrtko Ursulin
Use cases like rotation require these hooks to have some context so they
know how to prepare and cleanup the frame buffer correctly.
For i915 specifically, object backing pages need to be mapped differently
for different rotation modes and the driver needs to know which mapp
https://bugzilla.kernel.org/show_bug.cgi?id=94171
--- Comment #1 from Alex Deucher ---
Created attachment 168731
--> https://bugzilla.kernel.org/attachment.cgi?id=168731&action=edit
possible fix
Please make sure your kernel has this patch:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/l
[fix address for linux-kbuild at vger.kernel.org, sorry for the noise]
On Tue, 03 Mar 2015, Jani Nikula wrote:
> On Tue, 03 Mar 2015, Daniel Vetter wrote:
>> Otherwise Kconfig gets confused and somehow ends up creating a 2nd drm
>> submenu. I couldn't find i915 because of this any more at first
More interfaces are soon coming into picture; rework the
interface type a bit in order to make the code more clear.
Ping Pong interrupts are not directly linked to an interface number.
This change removes the INTFn prefix for Ping Pong interrupts.
Also rename some fields linked to WB paths.
Signed
Up until now, we assume that eDP is tight to intf_0 and HDMI to
intf_3. This information shall actually come from the mdp5_cfg
module since it can change from one chip to another.
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 8 +++
drivers/gpu/drm/msm/mdp/mdp5/mdp
Some interfaces (WB, DSI Command Mode) need to be kicked off
through a START Signal. This signal needs to be sent at the right
time and requests in some cases to keep track of the pipeline
status (eg: whether pipeline registers are flushed AND output WB
buffers are ready, in case of WB interface).
DSI and WB interfaces need a more complex pipeline configuration
than the current mdp5_ctl_set_intf().
For example, memory output connections need to be selected for
WB. Interface mode (Video vs. Command modes) also need to be
configured for DSI.
This change takes care of configuring the whole pi
Prepare for pipeline operation mode configuration, in particular
for DSI and WB modes.
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 68 -
1 file changed, 33 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp
WB and DSI support are in the pipe and will come out soon. Before that, we
need to prepare the MDP5 driver so we can support these connectors.
Stephane Viau (4):
drm/msm/mdp5: Update generated header files
drm/msm/mdp5: Enhance operation mode for pipeline configuration
drm/msm/mdp5: Add STAR
On Tue, 03 Mar 2015, Daniel Vetter wrote:
> Otherwise Kconfig gets confused and somehow ends up creating a 2nd drm
> submenu. I couldn't find i915 because of this any more at first.
This is not it. I bisected it to
commit db88c8f4e7e1d1c9e82bc5645a537782b8836cc0
Author: Chen Gang S
Date: Sun
Hi Thierry,
Am Montag, den 23.02.2015, 15:04 +0100 schrieb Philipp Zabel:
> Hi Thierry,
>
> do you have any further thoughts on this?
[...]
> > Sorry for taking so long to get back on this. I generally like the idea,
> > though a couple of things are unclear to me.
> >
> > In struct display_tim
Hi,
Am Donnerstag, den 12.02.2015, 14:01 +0800 schrieb Liu Ying:
> Signed-off-by: Liu Ying
> ---
> v8->v9:
> * Rebase onto the imx-drm/next branch of Philipp Zabel's open git repository.
I can't test this myself for lack of hardware, but I see no further
issues with patches 09 - 13 except for t
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150303/1cf5e804/attachment-0001.html>
s a person is known* by bugzilla one cannot CC them. For example
one cannot CC your @intel email, so I've opted for the known @linux.intel one.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scru
On Tue, Mar 03, 2015 at 10:06:57AM +, Jianwei.Wang at freescale.com wrote:
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Sunday, February 22, 2015 7:35 PM
> > To: Wang Jianwei-B52261
> > Cc: dri-devel at lists.
On 02/24/2015 04:56 PM, Oded Gabbay wrote:
> In a nutshell:
>
> This RFC proposes a control mechanism for VRAM (GPU local memory) memory
> pinning that is initiated by HSA processes. This control mechanism is proposed
> in order to prevent starvation of graphic applications due to high VRAM usage
https://bugzilla.kernel.org/show_bug.cgi?id=90861
--- Comment #16 from Jon Arne Jørgensen ---
Yep, that's a fix.
--
You are receiving this mail because:
You are watching the assignee of the bug.
Otherwise Kconfig gets confused and somehow ends up creating a 2nd drm
submenu. I couldn't find i915 because of this any more at first.
Cc: Andy Yan
Cc: Russell King
Cc: Philipp Zabel
Cc: "Yann E. MORIN"
Cc: linux-kbuild at vger.kernel.or
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/rock
https://bugzilla.kernel.org/show_bug.cgi?id=90861
--- Comment #15 from Maarten Lankhorst ---
Ok, in that case it's probably a duplicate.
Can you attachment 166571 on top of
http://cgit.freedesktop.org/~agd5f/linux/log/?h=posting-read?
--
You are receiving this mail because:
You are watching th
https://bugzilla.kernel.org/show_bug.cgi?id=90861
--- Comment #14 from Jon Arne Jørgensen ---
I'm sorry to report that attachment 166571 doesn't fix the crash,
but I can also report that your suggestion from Bug 90741 comment 60 does fix
the crash.
That is, attachment 166571 +
if (fence->ring =
the drivers with some extra code.
So if people think it's a big chore to add the connectors and don't see
the benefit in them (and they don't want the symbolic labels that could
be added there), I'm fine with having them optional.
Tomi
-- next part ------
On 2 March 2015 at 09:41, Alexandre Courbot wrote:
> On Thu, Feb 12, 2015 at 5:51 PM, Tomeu Vizoso
> wrote:
>> As there isn't a way for the firmware on the Nyan chromebooks to hand
>> over the display to the kernel.
>
> Could this have a side-effect on models for which the firmware *does*
> hand
Hi Dave,
Am Dienstag, den 24.02.2015, 19:11 +0100 schrieb Philipp Zabel:
> Hi Dave,
>
> please consider pulling in these fixes to the mode setting fixup, dw_hdmi-imx
> driver and i.MX parallel-display probing:
gentle reminder, will you merge these fixes?
regards
Philipp
> The following changes
hment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150303/1147f4c2/attachment-0001.html>
Good catch.
Patch is Reviewed-by: Christian König
Regards,
Christian.
On 02.03.2015 20:36, Tommi Rantala wrote:
> Passing zeroed drm_radeon_cs struct to DRM_IOCTL_RADEON_CS produces the
> following oops.
>
> Fix by always calling INIT_LIST_HEAD() to avoid the crash in list_sort().
>
>
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Sunday, February 22, 2015 7:35 PM
> To: Wang Jianwei-B52261
> Cc: dri-devel at lists.freedesktop.org; jbarnes at virtuousgeek.org; Wood
> Scott-B07421; Xiubo Li; Wang Huan-B189
On Tue, Mar 03, 2015 at 09:54:39AM +0100, Daniel Vetter wrote:
> On Mon, Mar 02, 2015 at 03:37:32PM -0800, jeff.mcgee at intel.com wrote:
> > From: Jeff McGee
> >
> > Setup new I915_GETPARAM ioctl entries for subslice total and
> > EU total. Userspace drivers need these values when constructing
>
A normal wait adds to the front of the tail. By doing something
similar to fence_default_wait the fence code can run without racing.
This is a complete fix for "panic on suspend from KDE with radeon",
and a partial fix for "Radeon: System pauses on TAHITI". On tahiti
si_irq_set needs to be fixed t
On Mon, Mar 02, 2015 at 03:37:32PM -0800, jeff.mcgee at intel.com wrote:
> From: Jeff McGee
>
> Setup new I915_GETPARAM ioctl entries for subslice total and
> EU total. Userspace drivers need these values when constructing
> GPGPU commands. This kernel query method is intended to replace
> the PC
This patch allows the IPU to divide the 27 MHz input clock from
the TVE by two to obtain the 13.5 MHz pixel clock needed for
NTSC/PAL SD modes.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/ipuv3-crtc.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gp
On Tue, Mar 3, 2015 at 9:11 AM, Daniel Vetter wrote:
>
> Fine with me. If you haven't pushed out yet can you maybe clarify the
> commit message?
Oh well. I already applied and tagged it, so it's what it is..
Linus
Hello Kukjin,
On 02/06/2015 12:27 PM, Javier Martinez Canillas wrote:
> Hello Andrzej,
>
> On 02/06/2015 11:55 AM, Andrzej Hajda wrote:
>> FIMD and MIXER IPs in disp1 power domain have async-bridges (to GSCALER),
>> therefore their clocks should be enabled during power domain switch.
>>
>> Signe
Hi Laurent,
Am Sonntag, den 01.03.2015, 18:20 +0200 schrieb Laurent Pinchart:
> Hi Philipp and all,
>
> This series has been around for a long time, it seems to be time to get it
> merged.
>
> What's the plan ? If we wait for the v4.1 merge window there's a chance we'll
> get more conflicts, e
On Tue, Mar 3, 2015 at 8:31 AM, Daniel Vetter wrote:
>
> Fix this all by applying the same duct-tape as for the legacy setcrtc
> ioctl code and set crtc->primary->crtc properly.
Ack. Tests fine on the machine that showed issues for me.
I'll apply it manually directly to my tree, since I want to
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150303/55e269dc/attachment.html>
Am Montag, den 02.03.2015, 16:40 +0100 schrieb Lucas Stach:
> Am Montag, den 02.03.2015, 16:24 +0100 schrieb Philipp Zabel:
> > This patch allows the IPU to divide the 27 MHz input clock from
> > the TVE by two to obtain the 13.5 MHz pixel clock needed for
> > NTSC/PAL SD modes.
> >
> > Signed-off
On Tue, Mar 3, 2015 at 4:10 AM, Christian König
wrote:
> Good catch.
>
> Patch is Reviewed-by: Christian König
>
> Regards,
> Christian.
>
Applied to my -fixes tree. Thanks!
Alex
>
> On 02.03.2015 20:36, Tommi Rantala wrote:
>>
>> Passing zeroed drm_radeon_cs struct to DRM_IOCTL_RADEON_CS
https://bugzilla.kernel.org/show_bug.cgi?id=94171
Bug ID: 94171
Summary: ati multihead black on one output
Product: Drivers
Version: 2.5
Kernel Version: 3.16, 3.19, 4.0rc1
Hardware: x86-64
OS: Linux
Tree: Main
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #75 from Maarten Lankhorst ---
Michel, enabling irqs before checking the fence signaling was exactly what I
was doing already, I'm hoping the attachment plus the branch is enough. :)
--
You are receiving this mail because:
You are wa
s too :)
--
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/20150303/b2e274b6/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #74 from Alex Deucher ---
posting reads implemented here:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=posting-read
--
You are receiving this mail because:
You are watching the assignee of the bug.
Option "AccelMethod" "glamor"
EndSection
--
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/20150303/f0ad4a3f/attachment.html>
Hi Laurent,
> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinchart+renesas at ideasonboard.com]
> Sent: Monday, March 02, 2015 5:20 AM
> To: dri-devel at lists.freedesktop.org
> Cc: Lars-Peter Clausen; Chris Kohn; Hyun Kwon
> Subject: [PATCH] drm: adv7511: Refactor power ma
https://bugzilla.kernel.org/show_bug.cgi?id=90741
--- Comment #73 from Michel Dänzer ---
(In reply to Alex Deucher from comment #72)
> Does reading any arbitrary register also work? E.g., SRBM_STATUS
I think that would indeed be the right thing to do here, to prevent the PCIe
bridge from delay
59 matches
Mail list logo
