amp;priv);
...
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/8d29e34e/attachment.sig>
Hi Jean-Fran?ois,
Thank you for the patch.
On Friday 21 March 2014 09:17:32 Jean-Francois Moine wrote:
> The 'slave encoder' structure of the tda998x driver asks for glue
> between the DRM driver and the encoder/connector structures.
>
> This patch changes the driver to a normal DRM encoder/conn
next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/16ffb2ac/attachment.sig>
core/engine/fifo/nvea.c
Looks good to me:
Reviewed-by: Thierry Reding
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/9c7c7236/attachment.sig>
--- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/67a79728/attachment.sig>
nit_vm(priv, &priv->bar[1], 1);
...
Unfortunately that would require a new type to be created for the bar[]
structures, so it'd be slightly more intrusive.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/e33e3552/attachment.sig>
ent was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/16ab7985/attachment.sig>
by: Thierry Reding
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/50d176b9/attachment.sig>
On Mon, Mar 24, 2014 at 9:40 PM, Mikulas Patocka wrote:
>> > > -> All hell breaks loose if Xorg dies and takes all it's mappings with it
>> > > (in master_destroy, since the Xorg /dev fd is the master) and leaves the
>> > > driver hanging in the air if there's an interrupt still pending (or
>> > >
t;\n");
> > + DRM_DEBUG_KMS("\n");
> > return true;
> >
> > log_fail:
> > - DRM_LOG_KMS("... failed\n");
> > + DRM_DEBUG_KMS("... failed\n");
> > return false;
> > }
> >
> > --
> > 1.8.3.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> 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/20140324/e75005cc/attachment-0001.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/82c38052/attachment-0001.html>
On Mon, Mar 24, 2014 at 03:53:07PM +, Damien Lespiau wrote:
> As patch 8/11 explains, I noticed that we where evaluating the arguments to
> drm_ut_debug_printk() even when drm.debug was 0, doing some work for no good
> reason. By pulling the test on drm_debug before calling drm_ut_debug_printk(
On Mon, Mar 24, 2014 at 03:53:11PM +, Damien Lespiau wrote:
> There are only a few users of the DRM_LOG_KMS() macro. We can simplify
> the DRM code a bit by replacing them by DRM_DEBUG_KMS().
>
> Cc: Patrik Jakobsson
> Signed-off-by: Damien Lespiau
Note that the point here of using LOG_KMS
On Mon, Mar 24, 2014 at 12:06:21PM +, Dmitry Malkin wrote:
>
> Hello guys,
>
> I've been playing with reloading intel gfx driver (i915) in a cycle, for a
> while,
> and at some point I've found a non-deterministic kernel crash with a
> highly-variable
> iteration dependency -- 2 to 200 driv
On Mon, Mar 24, 2014 at 01:17:12PM -0400, Mikulas Patocka wrote:
>
>
> On Mon, 24 Mar 2014, Daniel Vetter wrote:
>
> > On Mon, Mar 24, 2014 at 07:45:47AM +1000, Dave Airlie wrote:
> > > On Mon, Mar 24, 2014 at 7:27 AM, Andreas Mohr wrote:
> > > > On Sun, Mar 23, 2014 at 09:39:16AM -0700, Linus
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/309a8e53/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/823f9495/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/b776e78a/attachment.html>
-- next part ------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/f837d1cb/attachment-0001.html>
The following error and warnings will be seen when compiling a C file
which includes but without
being included before.
include/drm/drm_gem_cma_helper.h:5:24: error: field ?base? has incomplete type
include/drm/drm_gem_cma_helper.h: In function ?to_drm_gem_cma_obj?:
include/drm/drm_gem_cma_helpe
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/ba69e33f/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=72701
--- Comment #6 from klod ---
Well, "radeon.runpm=0" allows me to boot and use the system, but with much
higher temperature and shorter battery life. I wouldn't call that "fixing the
issue", as it's still worse than what I have with 3.12 and "radeo
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/3918dd93/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=72701
--- Comment #5 from Alex Deucher ---
(In reply to klod from comment #4)
> Just a few questions:
>
> 1. - What are "PX" and "non-PX" cards?
PX = PowerXpress. PX systems are laptops with two GPUs, an integrated and a
discrete GPU.
>
> 2. - Aren
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140324/3122c9a0/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=72701
--- Comment #4 from klod ---
Just a few questions:
1. - What are "PX" and "non-PX" cards?
2. - Aren't these going to disable power management in my GPU? What's the
difference between applying those and using "radeon.runpm=0" in grub?
3. - How
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/68847c71/attachment.html>
On Wed, Mar 19, 2014 at 12:57:21PM +0100, Daniel Vetter wrote:
> On Tue, Mar 18, 2014 at 05:22:53PM -0700, Matt Roper wrote:
> > Now that CRTC's have a primary plane, there's no need to track the
> > framebuffer in the CRTC. Replace all references to the CRTC fb
> > with the primary plane's fb.
>
org/archives/dri-devel/attachments/20140324/be885041/attachment-0001.html>
es/dri-devel/attachments/20140324/fda9d467/attachment.html>
Set the correct subdev/engine classes when GK20A (0xea) is probed.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/core/engine/device/nve0.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
b/drivers/gpu/drm
GK20A does not embed a dedicated COPY engine and thus cannot allocate
the copy channel that nouveau_accel_init() attempts to create. It also
lacks any display hardware, so the creation of a software channel does
not apply neither.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/nouv
Add a GR device for GK20A based on NVE4, with the correct classes
definitions (GK20A's 3D class is 0xa297).
Most of the NVE4 code can be used on GK20A, so make relevant bits of
NVE4 available to other chips as well.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/Makefile
Pad the microcode to a multiple of 0x40, otherwise firmware will fail to
run from non-prepadded firmware files.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/
nvc0_graph_ctor() would only let the graphics engine be enabled if its
oclass has a proper microcode linked to it. This prevents GR from being
enabled at all on chips that rely exclusively on external firmware, even
though such a use-case is valid.
Relax the conditions enabling the GR engine to al
Add a simple FB device for GK20A, as well as a RAM implementation based
on contiguous DMA memory allocations suitable for chips that use system
memory as video RAM.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/Makefile | 2 +
drivers/gpu/drm/nouveau/core/include
Add support for initializing the priv ring of GK20A. This is done by the
BIOS on desktop GPUs, but needs to be done by hand on Tegra.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/Makefile | 1 +
drivers/gpu/drm/nouveau/core/include/subdev/ibus.h | 1 +
drive
GK20A's FIFO is compatible with NVE0, but only features 128 channels and
1 runlist.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/Makefile | 1 +
drivers/gpu/drm/nouveau/core/engine/fifo/nve0.h| 1 +
drivers/gpu/drm/nouveau/core/engine/fifo/nvea.c| 35 +
Adapt the NVC0 BAR driver to make it able to support chips that do not
expose a BAR3. When this happens, BAR1 is then used for USERD mapping
and the BAR alloc() functions is disabled, making GPU objects unable
to rely on BAR for data access and falling back to PRAMIN.
Signed-off-by: Alexandre Cour
Some chips that use system memory exclusively (e.g. GK20A) do not
expose 2 BAR regions. For them only BAR1 exists, and it should be used
for USERD mapping. Do not map BAR3 if its resource does not exist.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/core/subdev/bar/base.c | 7
GK20A's timer is directly attached to the system timer and cannot be
calibrated. Skip the calibration phase on that chip since the
corresponding registers do not exist.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c | 19 +--
1 file changed,
Add a missing newline at the end of a DRM_INFO message.
Signed-off-by: Alexandre Courbot
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index b2a674531fba
Hi everyone,
Here is the second batch of patches to add GK20A support to Nouveau. This time
we are adding the actual chip support, and this series brings the driver to a
point where a slightly-tweaked Mesa successfully runs shaders and renders
triangles on GBM! Many thanks to Thierry Reding and th
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/c003f63d/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/a1ba2459/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/73723bdb/attachment.html>
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/9e730746/attachment.html>
On Mon, 24 Mar 2014, Daniel Vetter wrote:
> On Mon, Mar 24, 2014 at 01:17:12PM -0400, Mikulas Patocka wrote:
> > > > > Hmm, given that Mikulas in
> > > > > https://lkml.org/lkml/2014/2/26/537
> > > > > offered a diff of linux-3.13.5 files, it truly seems (shock! ack!
> > > > > noo!)
> > > > >
--
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/20140324/e5868001/attachment-0001.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/5619e3c5/attachment.html>
d...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/73fc9456/attachment.html>
top.org/archives/dri-devel/attachments/20140324/d0f07574/attachment.html>
On Sat, Mar 22, 2014 at 9:18 AM, Andy Lutomirski wrote:
> On Fri, Mar 21, 2014 at 9:37 AM, Bjorn Helgaas wrote:
>> On Fri, Mar 21, 2014 at 9:49 AM, Andy Lutomirski
>> wrote:
>>> On Fri, Mar 21, 2014 at 7:41 AM, Alex Deucher
>>> wrote:
On Thu, Mar 20, 2014 at 10:17 PM, Andy Lutomirski
>
Right now a debug message looks like:
[drm:drm_ioctl], pid=860, dev=0xe200, auth=1, DRM_IOCTL_MODE_GETCRTC
That first comma looks weird as we already have ']' as a separator.
Remove it.
If anyone sees this commit message and also thinks that auth=1 isn't the
most useful info to have here, let'
This is always DRM_NAME, so we can just make it part of the format
string instead of asking prink to do it for us.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_stub.c | 6 ++
include/drm/drmP.h | 17 ++---
2 files changed, 8 insertions(+), 15 deletions(-)
diff
The DRM_LOG* macros where the only sites where drm_ut_debug_printk was
called with NULL arguments for prefix and function_name. Now that they
are gone, we can remove that case.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_stub.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
In the logging code, we are currently checking is we need to output in
drm_ut_debug_printk(). This is too late. The problem is that when we write
something like:
DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
connector->base.id,
drm_ge
Signed-off-by: Damien Lespiau
---
include/drm/drmP.h | 19 ---
1 file changed, 19 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 1455e58..3055b36 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -228,30 +228,11 @@ int drm_err(const char *func,
There are only a few users of the DRM_LOG_KMS() macro. We can simplify
the DRM code a bit by replacing them by DRM_DEBUG_KMS().
Cc: Philipp Zabel
Cc: Lucas Stach
Signed-off-by: Damien Lespiau
---
drivers/staging/imx-drm/ipuv3-plane.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
There are only a few users of the DRM_LOG_KMS() macro. We can simplify
the DRM code a bit by replacing them by DRM_DEBUG_KMS().
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/dvo_ch7xxx.c | 4 ++--
drivers/gpu/drm/i915/dvo_ivch.c | 30 +++---
drivers/gpu/drm/i9
There are only a few users of the DRM_LOG_KMS() macro. We can simplify
the DRM code a bit by replacing them by DRM_DEBUG_KMS().
Cc: Patrik Jakobsson
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/gma500/psb_intel_sdvo.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletion
There are only a few users of the DRM_LOG_KMS() macro. We can simplify
the DRM code a bit by replacing them by DRM_DEBUG_KMS().
Cc: Inki Dae
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 +-
2 files changed, 2 i
This macro was trying to use the non existing DRM_UT_MODE debug category
and looks like it should be covered by DRM_LOG_KMS().
Signed-off-by: Damien Lespiau
---
include/drm/drmP.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 97900b7..1455
That comment wasn't super-readable, so I tried to improve it:
- Put the comment before the values it's documenting
- Add a mention to PRIME
- Reword things a bit to be a lighter read
- Add a note about the option to set the debug value at run-time
Signed-off-by: Damien Lespiau
---
include/drm/d
As patch 8/11 explains, I noticed that we where evaluating the arguments to
drm_ut_debug_printk() even when drm.debug was 0, doing some work for no good
reason. By pulling the test on drm_debug before calling drm_ut_debug_printk(),
we skip those instructions that only need to be executed when loggi
> }
> --
> Code Aurora Forum chooses to take this file under the GPL v 2 license only.
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Micha? ?mina86? Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/bfcfa73d/attachment-0001.sig>
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/0ca02cc4/attachment.html>
n which specific features are problematic?
--
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/20140324/1c3dafc4/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/380cd386/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=72701
--- Comment #3 from Alex Deucher ---
These patches should fix it:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9babd35ad72af631547c7ca294bc2e931cc40e58
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/com
Hi Alexandre,
Am Montag, den 24.03.2014, 17:42 +0900 schrieb Alexandre Courbot:
> Hi everyone,
[...]
>
> A few lines of hacks (not included here) are still needed to deal with cached
> mappings triggering external aborts and CPU/GPU memory coherency issues, but I
> hope to understand and address
On Mon, 24 Mar 2014, Daniel Vetter wrote:
> On Mon, Mar 24, 2014 at 07:45:47AM +1000, Dave Airlie wrote:
> > On Mon, Mar 24, 2014 at 7:27 AM, Andreas Mohr wrote:
> > > On Sun, Mar 23, 2014 at 09:39:16AM -0700, Linus Torvalds wrote:
> > >> On Sun, Mar 23, 2014 at 5:15 AM, Andreas Mohr wrote:
>
ace
8cd466c131375550 ]---
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140324/4995bd56/attachment-0001.html>
On Sun, Mar 23, 2014 at 8:53 AM, Fengguang Wu wrote:
> Hi Bjorn,
>
> On Fri, Mar 21, 2014 at 12:42:33PM -0600, Bjorn Helgaas wrote:
>> On Thu, Mar 20, 2014 at 8:09 PM, Fengguang Wu
>> wrote:
>> > // CC Stephane for RAPL related bug
>> >
>> > Bjorn, sorry this bug report is mis-titled. The only n
On Mon, Mar 24, 2014 at 07:45:47AM +1000, Dave Airlie wrote:
> On Mon, Mar 24, 2014 at 7:27 AM, Andreas Mohr wrote:
> > On Sun, Mar 23, 2014 at 09:39:16AM -0700, Linus Torvalds wrote:
> >> On Sun, Mar 23, 2014 at 5:15 AM, Andreas Mohr wrote:
> >> >
> >> > which did end up flawless on 3.12.0-rc2+,
Hi all,
Adding piles more people.
For the first case of caching the iommu mapping there's different
answers, depening upon the exact case:
1) You need to fix your userspace to not constantly re-establish the sharing.
2) We need to add streaming dma support for real to dma-bufs so that
the mappi
On Mon, Mar 24, 2014 at 7:27 AM, Andreas Mohr wrote:
> On Sun, Mar 23, 2014 at 09:39:16AM -0700, Linus Torvalds wrote:
>> On Sun, Mar 23, 2014 at 5:15 AM, Andreas Mohr wrote:
>> >
>> > which did end up flawless on 3.12.0-rc2+, too
>> > (but failed to improve the issue on 3.14.0-rc7+).
>> >
>> > S
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140324/ebba1264/attachment.html>
78 matches
Mail list logo
