https://bugzilla.kernel.org/show_bug.cgi?id=88501
pr0v1d3nc14 at riseup.net changed:
What|Removed |Added
CC||pr0v1d3nc14 at riseup.net
---
Signed-off-by: Geert Uytterhoeven
---
drivers/gpu/drm/sti/sti_cursor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sti/sti_cursor.c b/drivers/gpu/drm/sti/sti_cursor.c
index 010eaee60bf7c17c..00bfc8dae45e8728 100644
--- a/drivers/gpu/drm/sti/sti_cursor.c
+++
On Mon, Mar 9, 2015 at 12:08:16 +, Emil Velikov wrote:
> By using it, any modifications to configure.ac or the Makefile.am files
> won't trigger a rebuild of the makefiles. Drop the switch from the
> autogen.sh as well.
>
Since it was set to enabled in configure.ac, the above is not true,
un
Signed-off-by: Geert Uytterhoeven
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 6d8e29abbc333c87..74fdd8ca2cb2a347 100644
--- a/drivers/
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150309/aef975a7/attachment.html>
On Mon, Mar 09, 2015 at 05:29:44PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 09, 2015 at 11:44:05AM +, Chris Wilson wrote:
> > On a noisy link, we may retry the EDID reads multiple times per block
> > and still succeed. In such cases, we don't want to flood the kernel logs
> > with *ERROR* me
On Mon, Mar 09, 2015 at 03:39:01PM +, Chris Wilson wrote:
> On Mon, Mar 09, 2015 at 05:29:44PM +0200, Ville Syrjälä wrote:
> > On Mon, Mar 09, 2015 at 11:44:05AM +, Chris Wilson wrote:
> > > On a noisy link, we may retry the EDID reads multiple times per block
> > > and still succeed. In
On Mon, 2015-03-09 at 17:22 +0100, Kamil Debski wrote:
> Hi Mauro,
>
> From: Mauro Carvalho Chehab [mailto:mchehab at osg.samsung.com]
> Sent: Sunday, March 08, 2015 3:21 PM
>
> > Em Thu, 22 Jan 2015 17:04:34 +0100
> > Kamil Debski escreveu:
> >
> > (c/c linux-input ML)
> >
> > > Add cec proto
Because of iMX6 & Rockchip have differnet mpll config parameter,
than the cklvl & txlvl would be different, we also should seperate
this parmeter.
When pixle clock less than 148.5MHz, the cklvl set to 13(2.79v), and
txlvl set to 20(2.77v).
When pixel clock less than 74.25MHz, the cklvl set to 18(2
As for 1920x1080 display resolution, we should turn on the
Transmitter Trailer-B.
Signed-off-by: Yakir Yang
---
Changes in v3: None
Changes in v2:
- Set slopeboost back to 10%-20%, then rasing/falling time would pass.
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +-
1 file changed, 1 insert
Using a local struct pointer to reduce one level of indirection
makes the code slightly more readable.
Signed-off-by: Yakir Yang
Reviewed-by: Daniel Kurtz
---
Changes in v3:
- make commit message more readable
Changes in v2: None
drivers/gpu/drm/bridge/dw_hdmi.c | 8
1 file changed,
RK3288 hdmi eye-diagram test would fail when pixel clock is 148.5MHz,
and single-ended test would failed when display mode is 74.25MHz.
To fix such problems, we make those patch set:
- Fix some code style, leave space for next patches.
- For hdmi eye-diagram test, we turn on the Transmitter Trail
On Mon, Mar 09, 2015 at 11:44:05AM +, Chris Wilson wrote:
> On a noisy link, we may retry the EDID reads multiple times per block
> and still succeed. In such cases, we don't want to flood the kernel logs
> with *ERROR* messages as we then succeed. Refactor the EDID dumping and
> push it into t
Hi Mauro,
Thank you for your comments.
From: Mauro Carvalho Chehab [mailto:mche...@osg.samsung.com]
Sent: Sunday, March 08, 2015 4:42 PM
>
> Em Fri, 06 Mar 2015 17:14:50 +0100
> Kamil Debski escreveu:
>
> > Hi Sean, Hans,
> >
> > I am sorry to reply so late, I was busy with other work. I am
>
Hi Mauro,
From: Mauro Carvalho Chehab [mailto:mche...@osg.samsung.com]
Sent: Sunday, March 08, 2015 3:21 PM
> Em Thu, 22 Jan 2015 17:04:34 +0100
> Kamil Debski escreveu:
>
> (c/c linux-input ML)
>
> > Add cec protocol handling the RC framework.
>
> I added some comments, that reflects my und
Hi Sean,
From: Sean Young [mailto:s...@mess.org]
Sent: Sunday, March 08, 2015 11:45 AM
>
> Hi Kamil,
>
> On Fri, Mar 06, 2015 at 05:14:50PM +0100, Kamil Debski wrote:
> > 3) As you suggested - load an empty keymap whenever the pass through
> > mode is enabled.
> > I am not that familiar with the
On 03/09/2015 04:22 PM, Daniel Vetter wrote:
> On Mon, Mar 09, 2015 at 11:04:01AM +0100, Thomas Hellstrom wrote:
>> Hi,
>>
>> I'm not sure this started with 4.0 but when I rmmod the device driver
>> like so
>> rmmod vmwgfx
>>
>> The device loses its IRQ line as shown in lscpi:
>>Flags: bus mast
From: Jeff McGee
tests/core_getparams needs the new libdrm interfaces for
querying subslice and EU counts.
For: VIZ-4636
Signed-off-by: Jeff McGee
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 16d6a2e..88a1c3d 100644
---
From: Jeff McGee
Values of device max compute units and max subslice obtained
directly from the driver should be more accurate than our own
ID-based lookup values. This is particularly important when a
single device ID may encompass more than one configuration. If
the driver cannot provide a vali
From: Jeff McGee
tests/core_getparams needs the new libdrm interfaces for
querying subslice and EU counts.
For: VIZ-4636
Signed-off-by: Jeff McGee
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 16d6a2e..88a1c3d 100644
---
On Mon, Mar 09, 2015 at 11:04:01AM +0100, Thomas Hellstrom wrote:
> Hi,
>
> I'm not sure this started with 4.0 but when I rmmod the device driver
> like so
> rmmod vmwgfx
>
> The device loses its IRQ line as shown in lscpi:
>Flags: bus master, medium devsel, latency 64
>
> and a subsequent
On Mon, Mar 09, 2015 at 06:04:46PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 09, 2015 at 03:39:01PM +, Chris Wilson wrote:
> > On Mon, Mar 09, 2015 at 05:29:44PM +0200, Ville Syrjälä wrote:
> > > On Mon, Mar 09, 2015 at 11:44:05AM +, Chris Wilson wrote:
> > > > On a noisy link, we may r
From: Jeff McGee
tests/core_getparams needs the new libdrm interfaces for
querying subslice and EU counts.
For: VIZ-4636
Signed-off-by: Jeff McGee
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 16d6a2e..88a1c3d 100644
---
From: Jeff McGee
New test core_getparams consists of 2 subtests, each one testing
the ability of userspace to query the correct value of a GT config
attribute: subslice total or EU total. drm/i915 implementation of
these queries is required for Cherryview and Gen9+ devices (non-
simulated).
For:
On Mon, Mar 09, 2015 at 10:41:07AM +0200, Laurent Pinchart wrote:
> Drivers implementing the universal planes API report the list of
> supported pixel formats for the primary plane. Make sure the fb passed
> to the setcrtc ioctl is compatible.
>
> Drivers not implementing the universal planes API
From: Jeff McGee
Signed-off-by: Jeff McGee
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 8afee83..278f29b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -20,7 +20,7 @@
AC_PREREQ([2.63])
AC_INIT([libdrm],
-[2.4.
From: Jeff McGee
Update kernel interface with new I915_GETPARAM ioctl entries for
subslice total and EU total. Add a wrapping function for each
parameter. Userspace drivers need these values when constructing
GPGPU commands. This kernel query method is intended to replace
the PCI ID-based tables
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 PCI ID-based tables that userspace drivers currently maintain.
The kernel driver can em
On Mon, Mar 09, 2015 at 02:24:09PM +0530, Archit Taneja wrote:
>
>
> On 03/09/2015 01:14 PM, Daniel Vetter wrote:
> >On Mon, Mar 09, 2015 at 11:27:06AM +0530, Archit Taneja wrote:
> >>On 03/05/2015 09:14 PM, Daniel Vetter wrote:
> >>>On Thu, Mar 05, 2015 at 07:10:44AM -0500, Rob Clark wrote:
> >>
On Mon, Mar 09, 2015 at 05:29:44PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 09, 2015 at 11:44:05AM +, Chris Wilson wrote:
> > On a noisy link, we may retry the EDID reads multiple times per block
> > and still succeed. In such cases, we don't want to flood the kernel logs
> > with *ERROR* me
On 2015å¹´03æ09æ¥ 15:05, Daniel Kurtz wrote:
> On Mon, Mar 9, 2015 at 12:42 PM, Yakir Yang wrote:
>> - const struct dw_hdmi_mpll_config *mpll_config =
>> -hdmi->plat_data->mpll_cfg;
>> - const struct dw_hdmi_curr_ctrl *curr_ctrl = hdmi->plat_data->cur_ct
On 2015å¹´03æ09æ¥ 14:48, Joe Perches wrote:
> On Sun, 2015-03-08 at 21:48 -0700, Joe Perches wrote:
>
>> Shouldn't all of these be static?
> Don't mind me. These shouldn't be static.
>
> I was a bit mislead by the commit message.
>
> I think it'd be better not to put patch-like
> + and - lines
https://bugzilla.kernel.org/show_bug.cgi?id=94061
--- Comment #6 from Klaus Maier ---
radeon.bapm=1 brings back the originally reported behaviour (based on 3.14).
I didn't enable rdev->cg_flags and rdev->pg_flags as it is already known to be
broken because it needs a complete kernel recompile.
On Mon, Mar 9, 2015 at 12:42 PM, Yakir Yang wrote:
> - const struct dw_hdmi_mpll_config *mpll_config =
> -hdmi->plat_data->mpll_cfg;
> - const struct dw_hdmi_curr_ctrl *curr_ctrl = hdmi->plat_data->cur_ctr;
> - const struct dw_hdmi_sym_term *sym_term = hdmi
On 03/09/2015 01:14 PM, Daniel Vetter wrote:
> On Mon, Mar 09, 2015 at 11:27:06AM +0530, Archit Taneja wrote:
>> On 03/05/2015 09:14 PM, Daniel Vetter wrote:
>>> On Thu, Mar 05, 2015 at 07:10:44AM -0500, Rob Clark wrote:
On Thu, Mar 5, 2015 at 5:06 AM, Archit Taneja
wrote:
>
>
https://bugzilla.kernel.org/show_bug.cgi?id=94061
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #5 fr
On 7 March 2015 at 19:50, Alan Coopersmith
wrote:
> Needed for the definitions of major() & minor() used in
> drmGetNodeTypeFromFd() and makedev() used in drmOpenMinor()
>
On my linux box they are declared in #include , behind a
_BSD_SOURCE guard.
That aside, patch looks great. Thanks.
Reviewed-
Ingenic JZ4780 hdmi is compatible with dw_hdmi.
Signed-off-by: Zubair Lutfullah Kakakhel
---
V1 -> V2
Fixed license macro
Rebased to 4.0-rc3
---
drivers/gpu/drm/jz4780/Kconfig | 10 ++
drivers/gpu/drm/jz4780/Makefile | 1 +
drivers/gpu/drm/jz4780/dw_hdmi-jz4780.c | 235
Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC.
Signed-off-by: Zubair Lutfullah Kakakhel
---
V1 -> V2
Rebased to 4.0-rc3
---
.../bindings/video/ingenic-jz4780-hdmi.txt | 41 ++
1 file changed, 41 insertions(+)
create mode 100644
Documentation/devic
Add drm driver for the Ingenic JZ4780 SoC.
Signed-off-by: Zubair Lutfullah Kakakhel
---
V1 -> V2
Fixed Module_License macro
Fix in makefile and a #include drm_flip_work
Rebased to 4.0-rc3
Removed you should have received a copy of license etc.
---
drivers/gpu/drm/Kconfig | 2 +
Add DT bindings for the LCD controller on the jz4780 SoC
Signed-off-by: Zubair Lutfullah Kakakhel
---
V1 -> V2
Rebased to 4.0-rc3
---
.../bindings/video/ingenic-jz4780-lcd.txt | 39 ++
1 file changed, 39 insertions(+)
create mode 100644
Documentation/devicetree/bi
This patch adds a display susbsytem for the Ingenic JZ4780 SoC
Signed-off-by: Zubair Lutfullah Kakakhel
---
V1 -> V2
Rebased to 4.0-rc3
---
.../devicetree/bindings/video/ingenic-jz4780-drm.txt| 17 +
1 file changed, 17 insertions(+)
create mode 100644
Documentation/devicet
Hi,
Here we have 5 patches that add a DRM driver for the LCD
controller in the Ingenic JZ4780 SoC.
The HDMI Controller in the JZ4780 is by Synopsys
and the dw_hdmi driver is used.
These patches are based on 4.0-rc3
V1 -> V2
Fixed module licenses
Fix in makefile and #include drm_flip_work
Rebase
Because of iMX6 & Rockchip have differnet mpll config parameter,
than the cklvl & txlvl would be different, we also should seperate
this parmeter.
As for Rockchip HDMI, when pixle clock less than 148MHz, the cklvl &
txlvl should set to 13. When pixel clock less than 74.25MHz the cklvl
should set t
As for 1920x1080 display resolution, we should turn on the
Transmitter Trailer-B.
Signed-off-by: Yakir Yang
---
Changes in v2:
- Set slopeboost back to 10%-20%, then rasing/falling time would pass.
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
- const struct dw_hdmi_mpll_config *mpll_config =
-hdmi->plat_data->mpll_cfg;
- const struct dw_hdmi_curr_ctrl *curr_ctrl = hdmi->plat_data->cur_ctr;
- const struct dw_hdmi_sym_term *sym_term = hdmi->plat_data->sym_term;
+ const struct dw_hdmi_plat_data *pl
RK3288 hdmi eye-diagram test would fail when pixel clock is 148.5MHz,
and single-ended test would failed when display mode is 74.25MHz.
To fix such problems, we make those patch set:
- Fix some code style, leave space for next patches.
- For hdmi eye-diagram test, we turn on the Transmitter Trail
For non-GCC (Sun) compilers check for "-xldscope=hidden". Use it if
supported to hide the internal symbols.
Cc: Alan Coopersmith
Signed-off-by: Emil Velikov
---
configure.ac | 13 +
1 file changed, 13 insertions(+)
diff --git a/configure.ac b/configure.ac
index 1fcc8de..91c6662 10
The former does not imply the latter and vice-versa. One such example is
the Sun compiler.
Cc: Alan Coopersmith
Cc: Thierry Reding
Signed-off-by: Emil Velikov
---
Hi Alan,
Can you please take a look it this series covers the symbol visibility
issues mentioned earlier ? In theory it should wor
RK3288 hdmi eye-diagram test would fail when pixel clock is 148.5MHz,
and single-ended test would failed when display mode is 74.25MHz.
To fix such problems, we make those patch set:
- Fix some code style, leave space for next patches.
- For hdmi eye-diagram test, we turn on the Transmitter Trail
Signed-off-by: Emil Velikov
---
autogen.sh | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/autogen.sh b/autogen.sh
index 30d679f..c896097 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -1,6 +1,14 @@
#! /bin/sh
-test -n "$srcdir" || srcdir=`dirname "$0"`
-test
By using it, any modifications to configure.ac or the Makefile.am files
won't trigger a rebuild of the makefiles. Drop the switch from the
autogen.sh as well.
Signed-off-by: Emil Velikov
---
autogen.sh | 2 +-
configure.ac | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/au
On a noisy link, we may retry the EDID reads multiple times per block
and still succeed. In such cases, we don't want to flood the kernel logs
with *ERROR* messages as we then succeed. Refactor the EDID dumping and
push it into the caller rather than the validator so we can suppress the
warnings fr
https://bugzilla.kernel.org/show_bug.cgi?id=94061
--- Comment #4 from Klaus Maier ---
Created attachment 169961
--> https://bugzilla.kernel.org/attachment.cgi?id=169961&action=edit
dmesg
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=94061
--- Comment #3 from Klaus Maier ---
Retested with 4.0 rc2
Now, the graphic unit consumes even more power (3W more) when radeon is loaded
compared to not loaded radeon.
cat /sys/kernel/debug/dri/0/radeon_pm_info
uvddisabled
vcedisabled
po
On 03/05/2015 09:14 PM, Daniel Vetter wrote:
> On Thu, Mar 05, 2015 at 07:10:44AM -0500, Rob Clark wrote:
>> On Thu, Mar 5, 2015 at 5:06 AM, Archit Taneja
>> wrote:
>>>
>>> On 02/23/2015 09:09 PM, Daniel Vetter wrote:
On Mon, Feb 23, 2015 at 10:03:21AM -0500, Rob Clark wrote:
>
>>
Hi,
I'm not sure this started with 4.0 but when I rmmod the device driver
like so
rmmod vmwgfx
The device loses its IRQ line as shown in lscpi:
Flags: bus master, medium devsel, latency 64
and a subsequent modprobe will fail since pdev->irq is 0.
Is anyone else seeing this with other driver
https://bugzilla.kernel.org/show_bug.cgi?id=94471
--- Comment #2 from isaac at mm.st ---
Created attachment 169951
--> https://bugzilla.kernel.org/attachment.cgi?id=169951&action=edit
Second journalctl dump from disconnect
Attaching a second log from most recent disconnect. This seems to have a
https://bugzilla.kernel.org/show_bug.cgi?id=94471
isaac at mm.st changed:
What|Removed |Added
CC||intel-gfx-bugs at lists.freede
Drivers implementing the universal planes API report the list of
supported pixel formats for the primary plane. Make sure the fb passed
to the setcrtc ioctl is compatible.
Drivers not implementing the universal planes API will have no format
reported for the primary plane, skip the check in that c
e at 0x80478000
> [4.469662] [drm] vram apper at 0x8000
> [4.473775] [drm] size 8294400
> [4.476840] [drm] fb depth is 24
> [4.480084] [drm]pitch is 7680
> [4.759376] Console: switching to colour frame buffer device 240x67
> [4.838736] radeon 0001:81:00.0: fb0: radeondrmfb frame buffer device
> [4.845560] radeon 0001:81:00.0: registered panic notifier
> [4.856007] [drm] Initialized radeon 2.40.0 20080528 for 0001:81:00.0 on
> minor 0
>
> [ 31.335598] [drm:dce6_audio_get_pin] *ERROR* No connected audio pins
> found!
>
>
>
> ___
> dri-devel mailing listdri-devel at
> lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150309/81c2eb4f/attachment-0001.html>
ktop.org/archives/dri-devel/attachments/20150309/5a2fb3f3/attachment.html>
SMP blocks are configured for specific client IDs (ports).
These client IDs can be different from one chip to another for a
given pipe.
e.g.: DMA0 pipe fetch Y component is connected to:
- port #10 for MDP5 v1.3
- port #4 for MDP5 v1.6
In order to be compatible for upcoming versions of MDP5, th
MDP block is actually contained inside the MDSS block. For some
chipsets, the base address of the MDP registers is different from the
current (assumed) 0x100 offset.
Like CTL and LM blocks, this changes introduce a dynamic offset
for the MDP instance, which can be found out at runtime, once the
M
This change adds the hw configuration for msm8x16 chipsets in
mdp5_cfg module.
Note that only one external display interface is present in this
configuration (DSI) but has not been enabled yet. It will be enabled
once drm/msm driver supports DSI connectors.
Signed-off-by: Stephane Viau
---
driv
SMP blocks are configured for specific client IDs (ports).
These client IDs can be different from one chip to another for a
given pipe.
e.g.: DMA0 pipe fetch Y component is connected to:
- port #10 for MDP5 v1.3
- port #4 for MDP5 v1.6
In order to be compatible for upcoming versions of MDP5, th
This patch contains the generated header file of the following
change "drm/msm/mdp5: Get SMP client list from mdp5_cfg".
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 41 ++---
1 file changed, 7 insertions(+), 34 deletions(-)
diff --git a
MDP block is actually contained inside the MDSS block. For some
chipsets, the base address of the MDP registers is different from the
current (assumed) 0x100 offset.
Like CTL and LM blocks, this changes introduce a dynamic offset
for the MDP instance, which can be found out at runtime, once the
MD
This change contains the generated header file for the following
change "drm/msm/mdp5: Separate MDP5 domain from MDSS domain".
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 203 +++-
1 file changed, 118 insertions(+), 85 deletions(-)
diff
This patch set contains a couple modifications of the MDP5 register
description, followed by the MDP hw configuration of the msm8016 and
msm8916 chipsets.
Stephane Viau (5):
drm/msm/mdp5: Update headers (introduce MDP5 domain)
drm/msm/mdp5: Separate MDP5 domain from MDSS domain
drm/msm/mdp5:
On Mon, Mar 09, 2015 at 11:27:06AM +0530, Archit Taneja wrote:
> On 03/05/2015 09:14 PM, Daniel Vetter wrote:
> >On Thu, Mar 05, 2015 at 07:10:44AM -0500, Rob Clark wrote:
> >>On Thu, Mar 5, 2015 at 5:06 AM, Archit Taneja
> >>wrote:
> >>>
> >>>On 02/23/2015 09:09 PM, Daniel Vetter wrote:
>
>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150309/bb48fd0f/attachment.html>
This patchset is a must for beignet to support CHV. One comment is that we
should
put the usage of these new libdrm APIs to conditional block thus we don't break
the
build on old system.
For the other parts of the patchset:
Reviewed-by: Zhigang Gong
Thanks,
Zhigang Gong.
> -Original Mess
On Mon, Mar 9, 2015 at 4:54 AM, Archit Taneja wrote:
>
>
> On 03/09/2015 01:14 PM, Daniel Vetter wrote:
>>
>> On Mon, Mar 09, 2015 at 11:27:06AM +0530, Archit Taneja wrote:
>>>
>>> On 03/05/2015 09:14 PM, Daniel Vetter wrote:
On Thu, Mar 05, 2015 at 07:10:44AM -0500, Rob Clark wrote:
>>>
> -Original Message-
> From: Beignet [mailto:beignet-bounces at lists.freedesktop.org] On Behalf Of
> Jeff McGee
> Sent: Saturday, March 7, 2015 2:44 AM
> To: Zhigang Gong
> Cc: daniel at ffwll.ch; intel-gfx at lists.freedesktop.org;
> beignet at lists.freedesktop.org; dri-devel at lists.fr
Adds, to the extent possible, lockdep annotation to the TTM lock.
Also removes some unused TTM lock code.
Signed-off-by: Thomas Hellstrom
Acked-by: Sinclair Yeh
---
drivers/gpu/drm/ttm/ttm_lock.c | 73 --
include/drm/ttm/ttm_lock.h | 13 +++-
2 fi
>> [4.047989] [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed
>>>> (scratch(0x850C)=0xCAFEDEAD)
>>>> [4.056845] radeon 0001:81:00.0: disabling GPU acceleration
>>>> [ 4.261053] [drm] Radeon Display Connectors
>>>> [4.265626] [drm] Connector 0:
>>>> [4.268744] [drm] HDMI-A-1
>>>> [4.271735] [drm] HPD4
>>>> [4.274313] [drm] DDC: 0x6570 0x6570 0x6574 0x6574 0x6578 0x6578
>>>> 0x657c
>>>> 0x657c
>>>> [4.281755] [drm] Encoders:
>>>> [4.284768] [drm] DFP1: INTERNAL_UNIPHY2
>>>> [4.289060] [drm] Connector 1:
>>>> [4.292125] [drm] DVI-I-1
>>>> [4.294929] [drm] HPD2
>>>> [4.297476] [drm] DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568
>>>> 0x656c
>>>> 0x656c
>>>> [4.304894] [drm] Encoders:
>>>> [4.307872] [drm] DFP2: INTERNAL_UNIPHY
>>>> [4.312064] [drm] CRT1: INTERNAL_KLDSCP_DAC1
>>>> [4.465445] [drm] fb mappable at 0x80478000
>>>> [4.469662] [drm] vram apper at 0x8000
>>>> [4.473775] [drm] size 8294400
>>>> [4.476840] [drm] fb depth is 24
>>>> [4.480084] [drm]pitch is 7680
>>>> [4.759376] Console: switching to colour frame buffer device 240x67
>>>> [4.838736] radeon 0001:81:00.0: fb0: radeondrmfb frame buffer
>>>> device
>>>> [4.845560] radeon 0001:81:00.0: registered panic notifier
>>>> [4.856007] [drm] Initialized radeon 2.40.0 20080528 for
>>>> 0001:81:00.0 on
>>>> minor 0
>>>>
>>>> [ 31.335598] [drm:dce6_audio_get_pin] *ERROR* No connected audio pins
>>>> found!
>>>>
>>>>
>>>>
>>>> ___
>>>> dri-devel mailing list
>>>> dri-devel at lists.freedesktop.org <mailto:dri-devel at
>>>> lists.freedesktop.org>
>>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>>
>>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> <mailto:dri-devel at lists.freedesktop.org>
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150309/4c500661/attachment-0001.html>
VI-I-1
>>> [4.294929] [drm] HPD2
>>> [4.297476] [drm] DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568 0x656c
>>> 0x656c
>>> [4.304894] [drm] Encoders:
>>> [4.307872] [drm] DFP2: INTERNAL_UNIPHY
>>> [4.312064] [drm] CRT1: INTERNAL_KLDSCP_DAC1
>>> [4.465445] [drm] fb mappable at 0x80478000
>>> [4.469662] [drm] vram apper at 0x8000
>>> [4.473775] [drm] size 8294400
>>> [4.476840] [drm] fb depth is 24
>>> [4.480084] [drm]pitch is 7680
>>> [4.759376] Console: switching to colour frame buffer device 240x67
>>> [4.838736] radeon 0001:81:00.0: fb0: radeondrmfb frame buffer device
>>> [4.845560] radeon 0001:81:00.0: registered panic notifier
>>> [4.856007] [drm] Initialized radeon 2.40.0 20080528 for 0001:81:00.0 on
>>> minor 0
>>>
>>> [ 31.335598] [drm:dce6_audio_get_pin] *ERROR* No connected audio pins
>>> found!
>>>
>>>
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150309/eb266b5b/attachment-0001.html>
From: Sinclair Yeh
Add support for the screen target device interface.
Add a getparam parameter and bump minor to signal availability.
Signed-off-by: Sinclair Yeh
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/Makefile |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |
For certain surface copies, we don't have a user space handle for
the destination surface. In such cases, we are going to trust that
our caller is giving us the right surface ID.
To do this case, we created a quirk flag that may be useful
in the future for handling other cases.
Signed-off-by: Th
From: Sinclair Yeh
Signed-off-by: Sinclair Yeh
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 22 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c| 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 563 +---
drivers/gpu/drm/vmwgfx/vmwgfx_k
From: Sinclair Yeh
Refactored vmw_gb_surface_define_ioctl() and made the surface
definition part a separate function. This way other parts of vmwgfx
can use it to allocate kernel-visible GB surfaces.
Signed-off-by: Sinclair Yeh
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgf
From: Sinclair Yeh
Update device definition headers to support screen targets.
Signed-off-by: Sinclair Yeh
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/svga3d_reg.h | 56 ++--
drivers/gpu/drm/vmwgfx/svga3d_surfacedefs.h | 67 ++
For screen targets it appears we need to pin surfaces while they are bound
as screen targets, so add a small interface to do that.
v2: Always increase pin_count on pin.
v3: Add missing reservation sem.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
---
drivers/gpu/drm/vmwgfx/vmwgfx_
Screen targets is a device interface to make a 3D surface a scanout
surface. It should speed swapbuffers / pageflips up somewhat, and
it relaxes the requirement for pinned virtual VRAM, which previously
needed to be pre-allocated to match the size of the scanout bounding box.
It's also needed for
To take down the MOB and GMR memory types, the driver may have to issue
fence objects and thus make sure that the fence manager is taken down
after those memory types.
Reorder device init accordingly.
Cc:
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
---
drivers/gpu/drm/vmwgfx/vmwg
Experimental lockdep annotation added to the TTM lock has unveiled a
couple of lock dependency violations in the vmwgfx driver. In both
cases it turns out that the device_private::reservation_sem is not
needed so the offending code is moved out of that lock.
Cc:
Acked-by: Sinclair Yeh
Signed-off
-
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150309/b084563a/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=94471
--- Comment #1 from Michel Dänzer ---
I can only see references to an Intel GPU in the attached log, so the component
field of this report is set incorrectly.
--
You are receiving this mail because:
You are watching the assignee of the bug.
Hello Emil,
Emil Velikov wrote:
> I'm planning to push the above mentioned patches around lunchtime this
> Tuesday. If anyone has objections please speak up.
I doubt you're going to hear anything from Inki Dae. I've contacted him
a few times with questions when I wrote the series, but never heard
90 matches
Mail list logo
