for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150211/cef7ff10/attachment.html>
Hi Philipp,
On Wed, Feb 11, 2015 at 02:00:48PM +0100, Philipp Zabel wrote:
> Hi Liu,
>
> Am Mittwoch, den 11.02.2015, 15:21 +0800 schrieb Liu Ying:
> [...]
> > Our internal MIPI DSI SoC owner gave me some feedbacks on the clock sources.
> > According to him, the Synopsys DesignWare MIPI DSI host
his 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/20150211/daa8e33c/attachment.html>
On 2015ë
02ì 05ì¼ 16:11, Joonyoung Shim wrote:
> There is a case called disable_plane callback function even if
> plane->crtc is NULL from exynos_drm_encoder_disable and it will cause
> NULL pointer reference error.
Applied. (patch 1 though 4)
Thanks,
Inki Dae
>
> Signed-off-by: Joonyoung
Your patch had a minor issue which is the use of config name,
DRM_EXYNOS_DECON. The config name should be changed to DRM_EXYNOS7_DECON
to distinguish DECON controller of Exynos7 and one of Exynos5433. I
remember that we had already a discussion about it.
So I fixed it up and applied.
Thanks,
Ink
https://bugzilla.kernel.org/show_bug.cgi?id=92891
--- Comment #17 from georg at schorsch-tech.de ---
Oh my god! I just saw it!
[ 17.080350] si_cp: Failed to load firmware "radeon/PITCAIRN_pfp.bin"
After i copied from my other partition the radeon firmware to /lib/firmware,
the display is now ok
https://bugzilla.kernel.org/show_bug.cgi?id=92891
--- Comment #16 from georg at schorsch-tech.de ---
Created attachment 166501
--> https://bugzilla.kernel.org/attachment.cgi?id=166501&action=edit
dmesg when display doesnt update anymore
And this is the dmesg when the display doesnt update anymo
https://bugzilla.kernel.org/show_bug.cgi?id=92891
--- Comment #15 from georg at schorsch-tech.de ---
Created attachment 166491
--> https://bugzilla.kernel.org/attachment.cgi?id=166491&action=edit
dmesg of current 3.18.5 (non rt)
This is from the curren working 3.18.5 (non-rt) kernel.
--
You a
--
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/20150211/6458ae83/attachment.html>
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head: db275e69533f74b3d5cf2884cb8bba9d7640724d
commit: 64a008c61c4615ba0fffd1cdae7d39b4246048f8 [161/168] drm/i915: Make
intel_ring_setup_status_page() static
reproduce:
# apt-get install sparse
git checkout 64a008c61c4615
drivers/gpu/drm/i915/intel_ringbuffer.c:505:6: sparse: symbol
'intel_ring_setup_status_page' was not declared. Should it be static?
Signed-off-by: Fengguang Wu
---
intel_ringbuffer.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
Hi everyone!
It's that time of year again. Time to start coming up with GSoC
ideas. Martin and I are organizing this year's Xorg entry. We need
to fill in our ideas page with some good possible projects for
students. The project ideas should be something that a student could
accomplish over th
There is one issue to use i2c_smbus_XX functions:
i2c_smbus_read_i2c_block_data has limitation with the maximum count
I2C_SMBUS_BLOCK_MAX.
But in function hdmi_hdcp_recv_ksv_fifo, since the downstream ksv_fifo
size will exceed this limitation and must be read in a single transaction,
we can't use
Hi Dave,
Some radeon fixes for 3.20.
The following changes since commit 85840c76d8ad18d978da44e8d2f27bb35b7159af:
Merge tag 'imx-drm-fixes-2015-01-28' of
git://git.pengutronix.de/git/pza/linux into drm-next (2015-02-11 15:35:26 +1000)
are available in the git repository at:
git://people.
This adds support for the COM43H4M85ULC 3.7" 800x480 panel to the
DRM simple panel driver.
Signed-off-by: Philipp Zabel
---
.../bindings/panel/ortustech,com43h4m85ulc.txt | 7 ++
drivers/gpu/drm/panel/panel-simple.c | 27 ++
2 files changed, 34 insertio
Add Ortus Technology Co., Ltd. to the list of device tree vendor prefixes.
Signed-off-by: Philipp Zabel
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/
This adds support for the AM-800480R3TMQW-A1H 7" 800x480 panel to the
DRM simple panel driver.
Signed-off-by: Philipp Zabel
---
.../bindings/panel/ampire,am800480r3tmqwa1h.txt| 7 ++
drivers/gpu/drm/panel/panel-simple.c | 28 ++
2 files changed, 35 inse
Add Ampire Co., Ltd. to the list of device tree vendor prefixes.
Signed-off-by: Philipp Zabel
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/v
From: Philipp Zabel
This patch adds the bus_format field to the GPG482739QS5 panel structure.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
i
Don't restrict it to just eDP panels. Some LVDS bridge chips require
this. May fix blank panels on resume on certain laptops. Noticed
by mrnuke on IRC.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=42960
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150211/d59b022c/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=92891
--- Comment #14 from Alex Deucher ---
(In reply to georg from comment #13)
> With radeon.dpm=0 the 3.10.67 kernel did boot up and showed me on the
> PITCAIRN card the display and let me work on it.
>
> What kernel/card combination dmesg log shoul
https://bugzilla.kernel.org/show_bug.cgi?id=92891
--- Comment #13 from georg at schorsch-tech.de ---
With radeon.dpm=0 the 3.10.67 kernel did boot up and showed me on the PITCAIRN
card the display and let me work on it.
What kernel/card combination dmesg log should i post?
--
You are receiving
https://bugzilla.kernel.org/show_bug.cgi?id=92891
--- Comment #12 from georg at schorsch-tech.de ---
Created attachment 166481
--> https://bugzilla.kernel.org/attachment.cgi?id=166481&action=edit
vbios PITCAIRN
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Wed, Feb 11, 2015 at 10:57:08AM -0500, Jan Vesely wrote:
> On Wed, 2015-02-11 at 12:42 +0100, Daniel Vetter wrote:
> > We really have to do this to avoid surprises when extending the ABI
> > later on. Especially when growing the structures.
> >
> > A bit overkill to update all the old legacy io
; drm.debug=14 module parameter set, running the new kernel.
>
> BR,
> Jani.
>
>
> --
> Jani Nikula, Intel Open Source Technology Center
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150211/03e8fd10/attachment.html>
On Wed, Feb 11, 2015 at 01:20:24PM +0100, Marek Szyprowski wrote:
> Hello,
>
> On 2015-02-11 12:12, Russell King - ARM Linux wrote:
> >Which is a damn good reason to NAK it - by that admission, it's a half-baked
> >idea.
> >
> >If all we want to know is whether the importer can accept only contigu
Am Mittwoch, den 11.02.2015, 22:09 +0800 schrieb Liu Ying:
> BTW, regarding the compatible string topic, shall I keep my implementation
> unchanged and don't append the additional "snps,dw-mipi-dsi" as I shared
> my concerns about it before?
Leave the implementation unchanged. Still, I'd like to s
ping.
On Thu, Feb 5, 2015 at 9:24 PM, Ajay Kumar wrote:
> This patch is based on exynos-drm-next branch of Inki Dae's tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>
> DECON(Display and Enhancement Controller) is the new IP
> in exynos7 SOC for generating video s
As there isn't a way for the firmware on the Nyan chromebooks to hand
over the display to the kernel.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/tegra/sor.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 2a
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
at:
https://patchwork.ozlabs.org/patch/417779/
These patches are based on top of linux-next 20150211.
http://cgit.collabora.com/git/user/tomeu/linux.git/log/?h=nyan-v4
Regards,
Tomeu
Andrew Bresticker (1):
ARM: tegra: add support for warm reset GPIO
Stéphane Marchesin (1):
drm/panel: add support f
On 11 February 2015 at 04:42, Simon Farnsworth
wrote:
> A note:
>
> This is *not* enough to bring us to parity with Windows with these
> adapters. There's also something wrong with our HPD handling that trips them
> up - I suspect, based on AUX traces from one that's happy, that it's our
> handlin
On Wed, Feb 11, 2015 at 01:13:26PM +, Emil Velikov wrote:
> On 11 February 2015 at 11:42, Daniel Vetter wrote:
> > Well just core drm. All the other callers in there that still use
> > direct calls to ioctl have some custom retry logic already, so should
> > be good already.
> >
> Afaics intel
Hi Philipp,
On Fri, Feb 06, 2015 at 04:13:20PM +0800, Liu Ying wrote:
> On Thu, Feb 05, 2015 at 11:10:04AM +0100, Philipp Zabel wrote:
> > Am Mittwoch, den 31.12.2014, 16:23 +0800 schrieb Liu Ying:
> > > This patch adds device tree bindings for Synopsys DesignWare MIPI DSI
> > > host controller DR
ps.
i think we need something like
R600_DEBUG=nosfmath in this case
--
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/20150211
On Wed, Feb 11, 2015 at 10:59 AM, wrote:
> There is one issue to use i2c_smbus_XX functions:
> i2c_smbus_read_i2c_block_data has limitation with the maximum count
> I2C_SMBUS_BLOCK_MAX.
> But in function hdmi_hdcp_recv_ksv_fifo, since the downstream ksv_fifo
> size will exceed this limitation and
Hi Dave -
Another go, with "drm/i915: Do not invalidate obj->pages under
mempressure" dropped.
Here's a batch of i915 fixes for drm-next, with more cc: stable material
than fixes specific to drm-next.
BR,
Jani.
The following changes since commit 1293eaa3ebf92f146f366d9b678a07b8b3200ea1:
drm
On Tue, Feb 10, 2015 at 06:38:08PM +, Simon Farnsworth wrote:
> Older DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs
> in their I2C over AUX implementation (fixed in newer revisions). They work
> fine with Windows, but fail with Linux.
>
> It turns out that they cannot k
Hi Liu,
Am Mittwoch, den 11.02.2015, 15:21 +0800 schrieb Liu Ying:
[...]
> Our internal MIPI DSI SoC owner gave me some feedbacks on the clock sources.
> According to him, the Synopsys DesignWare MIPI DSI host controller needs four
> clock sources from an application platform - pclk, refclk, cfg_c
On Wed, Feb 11, 2015 at 06:23:52AM -0500, Rob Clark wrote:
> On Wed, Feb 11, 2015 at 6:12 AM, Russell King - ARM Linux
> wrote:
> > As I've already pointed out, there's a major problem if you have already
> > had a less restrictive attachment which has an active mapping, and a new
> > more restric
On 11 February 2015 at 04:40, Jammy Zhou wrote:
> v2: Add drmGetMinorBase, and call drmOpenWithType in drmOpen
> v3: Pass 'type' to drmOpenByBusid and drmOpenDevice in drmOpenByName
> v4: Renumber node type definitions, and return -1 for unsupported type
>
> Signed-off-by: Jammy Zhou
> Reviewed-b
On 11 February 2015 at 11:42, Daniel Vetter wrote:
> We really have to do this to avoid surprises when extending the ABI
> later on. Especially when growing the structures.
>
> A bit overkill to update all the old legacy ioctl wrappers, but can't
> hurt really either.
>
> Signed-off-by: Daniel Vet
Hello,
On 2015-02-11 12:12, Russell King - ARM Linux wrote:
> On Wed, Feb 11, 2015 at 09:28:37AM +0100, Marek Szyprowski wrote:
>> On 2015-01-27 09:25, Sumit Semwal wrote:
>>> Add some helpers to share the constraints of devices while attaching
>>> to the dmabuf buffer.
>>>
>>> At each attach, the
On 11 February 2015 at 11:42, Daniel Vetter wrote:
> Well just core drm. All the other callers in there that still use
> direct calls to ioctl have some custom retry logic already, so should
> be good already.
>
Afaics intel/intel_bufmgr_gem.c has one instance, plus most of the tests.
> freedreno
Hi Dave -
Here's a batch of i915 fixes for drm-next, with more cc: stable material
than fixes specific to drm-next.
BR,
Jani.
The following changes since commit 1293eaa3ebf92f146f366d9b678a07b8b3200ea1:
drm/i915: Update DRIVER_DATE to 20150130 (2015-01-30 22:37:54 +0100)
are available in th
These all moved to igt meanwhile.
Signed-off-by: Daniel Vetter
---
.gitignore| 4 --
tests/Makefile.am | 9
tests/gem_basic.c | 102
tests/gem_flink.c | 137 -
tests/gem_mmap.c
On Wed, Feb 11, 2015 at 01:09:51PM +0200, Jani Nikula wrote:
>
> Hi Dave -
>
> Here's a batch of i915 fixes for drm-next, with more cc: stable material
> than fixes specific to drm-next.
>
> BR,
> Jani.
>
> The following changes since commit 1293eaa3ebf92f146f366d9b678a07b8b3200ea1:
>
> drm/
We really have to do this to avoid surprises when extending the ABI
later on. Especially when growing the structures.
A bit overkill to update all the old legacy ioctl wrappers, but can't
hurt really either.
Signed-off-by: Daniel Vetter
---
xf86drm.c | 112 ++
Well just core drm. All the other callers in there that still use
direct calls to ioctl have some custom retry logic already, so should
be good already.
freedreno/kgsl ahas all the other bare ioctl calls, dunnot what to do
about that.
Signed-off-by: Daniel Vetter
---
xf86drm.c | 4 ++--
1 file
We really have to do this to avoid surprises when extending the ABI
later on. Especially when growing the structures.
Signed-off-by: Daniel Vetter
---
xf86drmMode.c | 55 ---
1 file changed, 28 insertions(+), 27 deletions(-)
diff --git a/xf86d
We really have to do this to avoid surprises when extending the ABI
later on. Especially when growing the structures.
Signed-off-by: Daniel Vetter
---
intel/intel_bufmgr_gem.c | 68
1 file changed, 34 insertions(+), 34 deletions(-)
diff --git a/i
v2: Add drmGetMinorBase, and call drmOpenWithType in drmOpen
v3: Pass 'type' to drmOpenByBusid and drmOpenDevice in drmOpenByName
v4: Renumber node type definitions, and return -1 for unsupported type
Signed-off-by: Jammy Zhou
Reviewed-by: Alex Deucher (v3)
---
xf86drm.c | 70 ++
On Wed, Feb 11, 2015 at 09:28:37AM +0100, Marek Szyprowski wrote:
> Hello,
>
> On 2015-01-27 09:25, Sumit Semwal wrote:
> >Add some helpers to share the constraints of devices while attaching
> >to the dmabuf buffer.
> >
> >At each attach, the constraints are calculated based on the following:
> >
This patch is
Reviewed-by: Ian Romanick
On 02/11/2015 03:42 AM, Daniel Vetter wrote:
> We really have to do this to avoid surprises when extending the ABI
> later on. Especially when growing the structures.
>
> Signed-off-by: Daniel Vetter
> ---
> xf86drmMode.c | 55 ++
This patch is
Reviewed-by: Ian Romanick
On 02/11/2015 03:42 AM, Daniel Vetter wrote:
> We really have to do this to avoid surprises when extending the ABI
> later on. Especially when growing the structures.
>
> Signed-off-by: Daniel Vetter
> ---
> intel/intel_bufmgr_gem.c | 68
>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150211/a25e9c4f/attachment.html>
199,6 +2239,7 @@ int drmGetClient(int fd, int idx, int *auth, int *pid,
> int *uid,
> {
> drm_client_t client;
>
> +memclear(client);
> client.idx = idx;
> if (drmIoctl(fd, DRM_IOCTL_GET_CLIENT, &client))
> return -errno;
> @@ -2215,6 +2256,7 @@ int drmGetStats(int fd, drmStatsT *stats)
> drm_stats_t s;
> unsignedi;
>
> +memclear(s);
> if (drmIoctl(fd, DRM_IOCTL_GET_STATS, &s))
> return -errno;
>
> @@ -2352,6 +2394,7 @@ int drmSetInterfaceVersion(int fd, drmSetVersion
> *version)
> int retcode = 0;
> drm_set_version_t sv;
>
> +memclear(sv);
> sv.drm_di_major = version->drm_di_major;
> sv.drm_di_minor = version->drm_di_minor;
> sv.drm_dd_major = version->drm_dd_major;
> @@ -2383,12 +2426,11 @@ int drmSetInterfaceVersion(int fd, drmSetVersion
> *version)
> */
> int drmCommandNone(int fd, unsigned long drmCommandIndex)
> {
> -void *data = NULL; /* dummy */
> unsigned long request;
>
> request = DRM_IO( DRM_COMMAND_BASE + drmCommandIndex);
>
> -if (drmIoctl(fd, request, data)) {
> +if (drmIoctl(fd, request, NULL)) {
> return -errno;
> }
> return 0;
> @@ -2543,12 +2585,12 @@ void drmCloseOnce(int fd)
>
> int drmSetMaster(int fd)
> {
> - return drmIoctl(fd, DRM_IOCTL_SET_MASTER, 0);
> + return drmIoctl(fd, DRM_IOCTL_SET_MASTER, NULL);
> }
>
> int drmDropMaster(int fd)
> {
> - return drmIoctl(fd, DRM_IOCTL_DROP_MASTER, 0);
> + return drmIoctl(fd, DRM_IOCTL_DROP_MASTER, NULL);
> }
>
> char *drmGetDeviceNameFromFd(int fd)
--
Jan Vesely
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150211/9758ea44/attachment.sig>
Hi,
On 02/11/2015 10:39 AM, Tobias Jakobi wrote:
> Hello Joonyoung!
>
> Joonyoung Shim wrote:
>> Hi,
>>
>> On 02/03/2015 10:53 PM, Tobias Jakobi wrote:
>>> The blend test uses the userptr functionality of exynos-drm, which
>>> is currently not safe to use. If the kernel hasn't been build with
>>>
On Tue, Feb 10, 2015 at 10:37:16PM +, Emil Velikov wrote:
> On 02/02/15 00:14, Emil Velikov wrote:
> > Hi all,
> >
> > As mentioned a couple of days ago at #dri-devel some(most) users of
> > render nodes tend to rely on strict mapping between the primary and
> > render node. I.e. something a
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150211/5e5fd1da/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150211/12a059c4/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150211/a97dab2a/attachment.html>
s 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/20150211/bc6a8ada/attachment.html>
On Tue, 10 Feb 2015, Simon Farnsworth wrote:
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55228
> Tested-by: Aidan Marks
Aidan writes in the bug, "Hi Simon, I'm sorry to report that the v4
patch doesn't work for me at all, it reverts to 1024x768. v3 was great
though."
BR,
Jani.
Hi,
On 02/03/2015 10:53 PM, Tobias Jakobi wrote:
> The blend test uses the userptr functionality of exynos-drm, which
> is currently not safe to use. If the kernel hasn't been build with
> exynos-iommu support, then the blend test is going to produce (kernel)
> memory corruption, eventually leadin
Hi,
On 02/03/2015 10:53 PM, Tobias Jakobi wrote:
> Hello,
>
> here are some miscellaneous improvements (small features, bugfixes, spelling
> fixes, etc.) for the exynos component of libdrm. The general idea is to let
> userspace use the G2D engine functionality more
> efficiently.
>
> If some
Hello,
On 2015-01-27 09:25, Sumit Semwal wrote:
> Add some helpers to share the constraints of devices while attaching
> to the dmabuf buffer.
>
> At each attach, the constraints are calculated based on the following:
> - max_segment_size, max_segment_count, segment_boundary_mask from
> device
On Wed, Feb 11, 2015 at 7:56 AM, Daniel Vetter wrote:
> On Wed, Feb 11, 2015 at 06:23:52AM -0500, Rob Clark wrote:
>> On Wed, Feb 11, 2015 at 6:12 AM, Russell King - ARM Linux
>> wrote:
>> > As I've already pointed out, there's a major problem if you have already
>> > had a less restrictive attac
Reviewed-by: Frank Binns
On 11/02/15 04:40, Jammy Zhou wrote:
> v2: Add drmGetMinorBase, and call drmOpenWithType in drmOpen
> v3: Pass 'type' to drmOpenByBusid and drmOpenDevice in drmOpenByName
> v4: Renumber node type definitions, and return -1 for unsupported type
>
> Signed-off-by: Jammy Zho
On Wed, Feb 11, 2015 at 03:36:29PM +1000, Dave Airlie wrote:
> On 11 February 2015 at 04:42, Simon Farnsworth
> wrote:
> > A note:
> >
> > This is *not* enough to bring us to parity with Windows with these
> > adapters. There's also something wrong with our HPD handling that trips them
> > up - I
On Wed, Feb 11, 2015 at 6:42 AM, Daniel Vetter
wrote:
> Well just core drm. All the other callers in there that still use
> direct calls to ioctl have some custom retry logic already, so should
> be good already.
>
> freedreno/kgsl ahas all the other bare ioctl calls, dunnot what to do
> about th
On Wed, Feb 11, 2015 at 6:12 AM, Russell King - ARM Linux
wrote:
> On Wed, Feb 11, 2015 at 09:28:37AM +0100, Marek Szyprowski wrote:
>> Hello,
>>
>> On 2015-01-27 09:25, Sumit Semwal wrote:
>> >Add some helpers to share the constraints of devices while attaching
>> >to the dmabuf buffer.
>> >
>> >
iving 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/20150211/72aca6df/attachment.html>
On Wed, Feb 11, 2015 at 3:53 AM, wrote:
> Hello.
>
> I'm looking for a PCI or AGP video card that would work on a Linux port for a
> big endian architecture (HP PA-RISC). Unfortunately the stock video options
> (ATI FireGL X1 and X3) give an incredibly slow unaccelerated 2D due to
> failure to
Thanks for the comments, Frank. I will send out the updated patch later.
Regards,
Jammy
-Original Message-
From: Frank Binns [mailto:frank.bi...@imgtec.com]
Sent: Wednesday, February 11, 2015 1:04 AM
To: Zhou, Jammy; dri-devel at lists.freedesktop.org
Subject: Re: [PATCH 1/2] Add new drm
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150211/0d151055/attachment.html>
recheck that...
--
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/20150211/bb3e044e/attachment.html>
Hello Joonyoung!
Joonyoung Shim wrote:
> Hi,
>
> On 02/03/2015 10:53 PM, Tobias Jakobi wrote:
>> The blend test uses the userptr functionality of exynos-drm, which
>> is currently not safe to use. If the kernel hasn't been build with
>> exynos-iommu support, then the blend test is going to produc
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150211/1bdcd6be/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/20150211/4b500e3d/attachment.html>
0x3010C)=0xCAFEDEAD)
[1.026678] radeon :01:00.0: disabling GPU acceleration
--
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/attachment
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150211/8041bce6/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150211/e8d3149f/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150211/6ff4cece/attachment.html>
85 matches
Mail list logo
