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/6ff4cece/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150211/e8d3149f/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/8041bce6/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
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150211/1bdcd6be/attachment.html>
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
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/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
>>>
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>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150211/0d151055/attachment.html>
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
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 ++
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 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 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
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
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.
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 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
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>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150211/a97dab2a/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150211/12a059c4/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150211/5e5fd1da/attachment-0001.html>
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
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150211/a25e9c4f/attachment.html>
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
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:
> >
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
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 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.
>> >
>> >
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
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
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
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
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
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.
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 ++
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/
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 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 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 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 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
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 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
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
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
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
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
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
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
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
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>
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
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
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
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
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 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/
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.
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 #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
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>
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
>
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 ++
--
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>
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
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 #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
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 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
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150211/cef7ff10/attachment.html>
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
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.
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
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
; 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>
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 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
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
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
85 matches
Mail list logo
