the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141118/1c3012d5/attachment.html>
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/20141118/09e3c00c/attachment.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141118/ee5e2b2b/attachment.html>
ash only happens when Basic Shaders are enabled.
--
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/20141118/fe065211/attachment.html>
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141118/a6ea5d35/attachment.html>
e the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141118/18616870/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/20141118/67a53916/attachment.html>
This patch fixes a infinite loop issue incurred when
it doesn't have a pair of crtc and connector drivers,
which was reported by Kevin Hilman like below,
http://www.spinics.net/lists/linux-samsung-soc/msg39050.html
cdev->conn_dev could be NULL by exynos_drm_component_del call in case
that co
On Sat, Nov 15, 2014 at 3:24 PM, Ajay Kumar wrote:
> This series is based on master branch of Linus tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>
> Changes since V2:
> -- Address comments from Jingoo Han for ps8622 driver
> -- Address comments from D
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141118/4acaa781/attachment.html>
e:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141118/4e07eca3/attachment.html>
Michel Dänzer ---
Can you bisect the kernel?
--
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/20141118/58a07ba5/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141118/021be3e3/attachment.html>
reedesktop.org/archives/dri-devel/attachments/20141118/105d4d82/attachment-0001.html>
On Mon, Nov 17, 2014 at 06:10:36PM -0800, Matt Roper wrote:
> From: Gustavo Padovan
>
> We need to get hdisplay and vdisplay in a few places so create a
> helper to make our job easier.
>
> v2 (by Matt): Use new stereo doubling function (suggested by Ville)
>
> Cc: dri-devel at lists.freedeskto
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141118/96f53e42/attachment.html>
K, I'll stop testing for now.
--
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/20141118/1790cfe2/attachment.html>
On 2014ë
11ì 18ì¼ 16:58, Sjoerd Simons wrote:
> On Tue, 2014-11-18 at 12:20 +0900, Inki Dae wrote:
>> This patch makes the deferred probe is tried up to 3 times in maximum.
>> However, this is considered only for Exynos drm so I think other SoC
>> drivers could also produce same issue. Therefo
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141118/db46b4bc/attachment.html>
On Tue, 18 Nov 2014, Matt Roper wrote:
> From: Gustavo Padovan
>
> We need to get hdisplay and vdisplay in a few places so create a
> helper to make our job easier.
>
> v2 (by Matt): Use new stereo doubling function (suggested by Ville)
>
> Cc: dri-devel at lists.freedesktop.org
> Suggested-by: V
Hi Dave,
Resending the pull request of amdkfd for 3.19 per your request.
Change from original pull-request is removing the line "default m" from the
Kconfig file of amdkfd.
Here is the link to the previous pull request:
http://lists.freedesktop.org/archives/dri-devel/2014-November/072053.html
T
From: Michel Dänzer
No functional change.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/radeon/radeon_cursor.c | 220 -
1 file changed, 109 insertions(+), 111 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c
b/drivers/gpu/drm/radeon/radeon
From: Michel Dänzer
The cursor_set2 hook provides the cursor hotspot position within the
cursor image. When the hotspot position changes, we can adjust the cursor
position such that the hotspot doesn't move on the screen. This prevents
the cursor from appearing to intermittently jump around on t
On 11/06/2014 10:06 AM, Krzysztof Kozlowski wrote:
> Hi,
>
> On last next (next-20141104, next-20141105) booting locks after
> initializing Exynos DRM (Trats2 board):
>
> [2.028283] [drm] Initialized drm 1.1.0 20060810
> [ 240.505795] INFO: task swapper/0:1 blocked for more than 120 seconds.
On 2014ë
11ì 18ì¼ 19:23, Javier Martinez Canillas wrote:
> Hello Inki,
>
>> Right, but at least, we could avoid kernel booting failure which is very
>> critical. Please know that this patch is temporary to avoid the kernel
>> booting failure although deferred probe request of Exynos drm could
On 2014ë
11ì 18ì¼ 19:42, Andrzej Hajda wrote:
> On 11/06/2014 10:06 AM, Krzysztof Kozlowski wrote:
>> Hi,
>>
>> On last next (next-20141104, next-20141105) booting locks after
>> initializing Exynos DRM (Trats2 board):
>>
>> [2.028283] [drm] Initialized drm 1.1.0 20060810
>> [ 240.505795]
On 11/18/2014 11:23 AM, Javier Martinez Canillas wrote:
> Hello Inki,
>
>> Right, but at least, we could avoid kernel booting failure which is very
>> critical. Please know that this patch is temporary to avoid the kernel
>> booting failure although deferred probe request of Exynos drm could be
>>
On 11/18/2014 11:52 AM, Inki Dae wrote:
> On 2014ë
11ì 18ì¼ 19:42, Andrzej Hajda wrote:
>> On 11/06/2014 10:06 AM, Krzysztof Kozlowski wrote:
>>> Hi,
>>>
>>> On last next (next-20141104, next-20141105) booting locks after
>>> initializing Exynos DRM (Trats2 board):
>>>
>>> [2.028283] [drm]
-
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141118/cec71580/attachment.html>
From: Mark yao
This adds binding documentation for Rockchip SoC VOP driver.
Signed-off-by: Mark Yao
---
Changes in v2:
- rename "lcdc" to "vop"
- add vop reset
- add iommu node
- add port for display-subsystem
Changes in v3: None
Changes in v4: None
Changes in v5: None
Changes in v6: None
This a series of patches is a DRM Driver for Rockchip Socs, add support
for vop devices. Future patches will add additional encoders/connectors,
such as eDP, HDMI.
The basic "crtc" for rockchip is a "VOP" - Video Output Processor.
the vop devices found on Rockchip rk3288 Soc, rk3288 soc have two s
This add a display subsystem comprise the all display interface nodes.
Signed-off-by: Mark Yao
---
Changes in v2:
- add DRM master device node to list all display nodes that comprise
the graphics subsystem.
Changes in v3: None
Changes in v4: None
Changes in v5: None
Changes in v6: None
Cha
From: Mark yao
This patch adds the basic structure of a DRM Driver for Rockchip Socs.
Signed-off-by: Mark Yao
Signed-off-by: Daniel Kurtz
Acked-by: Daniel Vetter
Reviewed-by: Rob Clark
---
Changes in v2:
- use the component framework to defer main drm driver probe
until all VOP devices hav
From: Mark yao
This add a display subsystem comprise the all display interface nodes.
Signed-off-by: Mark Yao
---
Changes in v2:
- add DRM master device node to list all display nodes that comprise
the graphics subsystem.
Changes in v3: None
Changes in v4: None
Changes in v5: None
Changes
On Tue, Nov 18, 2014 at 04:00:29PM +0800, Mark Yao wrote:
> From: Mark yao
>
> This patch adds the basic structure of a DRM Driver for Rockchip Socs.
>
> Signed-off-by: Mark Yao
> Signed-off-by: Daniel Kurtz
> Acked-by: Daniel Vetter
> Reviewed-by: Rob Clark
> ---
> Changes in v2:
> - use th
This patch adds the basic structure of a DRM Driver for Rockchip Socs.
Signed-off-by: Mark Yao
Signed-off-by: Daniel Kurtz
Acked-by: Daniel Vetter
Reviewed-by: Rob Clark
---
Changes in v2:
- use the component framework to defer main drm driver probe
until all VOP devices have been probed.
-
Hi Ganesan,
On Thursday, October 30, 2014 10:33pm, "Ganesan, Aravind" said:
> Splitting the command sequence for an IB1 submission at the end of
> the ring buffer can hang the GPU. To fix this, if there isn't
> enough contiguous space at the end to fit the full command sequence,
> insert NOPs
- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6170 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141118/098dcf0a/attachment-0001.bin>
This a series of patches is a DRM Driver for Rockchip Socs, add support
for vop devices. Future patches will add additional encoders/connectors,
such as eDP, HDMI.
The basic "crtc" for rockchip is a "VOP" - Video Output Processor.
the vop devices found on Rockchip rk3288 Soc, rk3288 soc have two s
On 2014å¹´11æ18æ¥ 16:32, Daniel Vetter wrote:
> On Tue, Nov 18, 2014 at 04:00:29PM +0800, Mark Yao wrote:
>> From: Mark yao
>>
>> This patch adds the basic structure of a DRM Driver for Rockchip Socs.
>>
>> Signed-off-by: Mark Yao
>> Signed-off-by: Daniel Kurtz
>> Acked-by: Daniel Vetter
>>
This adds binding documentation for Rockchip SoC VOP driver.
Signed-off-by: Mark Yao
---
Changes in v2:
- rename "lcdc" to "vop"
- add vop reset
- add iommu node
- add port for display-subsystem
Changes in v3: None
Changes in v4: None
Changes in v5: None
Changes in v6: None
Changes in v7: No
Hello Andrzej,
On Tue, Nov 18, 2014 at 11:48 AM, Andrzej Hajda wrote:
>> So we have two issues here and your patch is only a workaround for the later.
>
> This is the same issue Krzysztof reported two weeks ago and I answered
> him with my diagnosis[1].
>
> [1]: http://permalink.gmane.org/gmane.l
Hello Inki,
> Right, but at least, we could avoid kernel booting failure which is very
> critical. Please know that this patch is temporary to avoid the kernel
> booting failure although deferred probe request of Exynos drm could be
> broken. For this, I will look into dd core to find out more gen
uot;
thread.
Thanks...
--
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/20141118/f1c818ff/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141118/dc6c7326/attachment.html>
fy that
the bisected commit is the culprit.
--
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/20141118/5eb259b6/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141118/0398ebcb/attachment.html>
On 2014ë
11ì 18ì¼ 12:20, Inki Dae wrote:
> This patch fixes a infinite loop issue incurred when
> it doesn't have a pair of crtc and connector drivers,
> which was reported by Kevin Hilman like below,
> http://www.spinics.net/lists/linux-samsung-soc/msg39050.html
>
> cdev->conn_dev coul
Hello,
This series makes use of the MEDIA_BUS_FMT definition to describe how
the data are transmitted to the display.
This will allow drivers to configure their output display bus according
to the display capabilities.
For example some display controllers support DPI (or raw RGB) connectors
and n
Add bus_formats and nbus_formats fields and
drm_display_info_set_bus_formats helper function to specify the bus
formats supported by a given display.
This information can be used by display controller drivers to configure
the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw
RGB
Foxlink's fl500wvr00-a0t supports RGB888 format.
Signed-off-by: Boris Brezillon
---
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
index 66838a5..695f406 100644
--- a/drivers/gp
Provide a way to specify panel requirement in terms of supported media bus
format (particularly useful for panels connected to an RGB or LVDS bus).
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panel/panel-simple.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/pan
(Radeon 5850, KVM |
|GPU passthrough)|
--
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/20141
|FIXED
--
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/20141118/d4494159/attachment.html>
From: Thierry Reding
After seeing how the DRM_IOCTL_MODE_CREATE_DUMB was implemented with
different semantics on different drivers it seems like a good idea to
start to more rigorously document userspace ABI to avoid these things
in the future.
This is a first draft of what such documentation co
On Tue, Nov 18, 2014 at 03:19:33PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> After seeing how the DRM_IOCTL_MODE_CREATE_DUMB was implemented with
> different semantics on different drivers it seems like a good idea to
> start to more rigorously document userspace ABI to avoid these
The
kernel exposes them, so it should provide the documentation for it as
well.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141118/40ef036f/attachment.sig>
Hi
On Tue, Nov 18, 2014 at 3:43 PM, Thierry Reding
wrote:
> On Tue, Nov 18, 2014 at 03:27:27PM +0100, Daniel Vetter wrote:
>> On Tue, Nov 18, 2014 at 03:19:33PM +0100, Thierry Reding wrote:
>> > From: Thierry Reding
>> >
>> > After seeing how the DRM_IOCTL_MODE_CREATE_DUMB was implemented with
>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141118/f75ab6a3/attachment.html>
6bd93488
--
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/20141118/644f68e1/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=83611
--- Comment #6 from Alex Deucher ---
Fix is upstream:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8efe82ca908400785253c8f0dfcf301e6bd93488
--
You are receiving this mail because:
You are watching the assignee of the
ically.
> And even if people don't use libdrm, I think it's totally acceptable
> to ship man-pages with libdrm. Distributions are free to provide
> drm-man-pages as stand-alone package (which is _really_ easy to
> generate from libdrm).
I guess one other home for these could be the man-pages project on
kernel.org. It's what carries most (all?) of the Linux kernel-specific
man-pages (like the tty_ioctl and console_ioctl ones that you referred
to).
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141118/07915ba6/attachment-0001.sig>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141118/2949f3ea/attachment.html>
|--- |FIXED
--
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/20141118/cb5c69ac/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=83461
--- Comment #22 from kb at spatium.org ---
I've also added this line
DRM_DEBUG_KMS("in patched branch: %u\n", ref_div_max);
add the end of your patch, i.e. after
ref_div_max = min(ref_div_max, pll->reference_freq /
https://bugzilla.kernel.org/show_bug.cgi?id=83461
--- Comment #23 from kb at spatium.org ---
Created attachment 158001
--> https://bugzilla.kernel.org/attachment.cgi?id=158001&action=edit
dmesg #3
--
You are receiving this mail because:
You are watching the assignee of the bug.
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141118/67c92fbd/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141118/1e5b99c9/attachment.html>
not belong here.
--
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/20141118/f7338eef/attachment.html>
From: Gustavo Padovan
We need to get hdisplay and vdisplay in a few places so create a
helper to make our job easier.
v2 (by Matt): Use new stereo doubling function (suggested by Ville)
v3 (by Matt):
- Add missing kerneldoc (Daniel)
- Use drm_mode_copy() (Jani)
Cc: dri-devel at lists.freedes
d, so testing reset on the bad commit - Yes it does
workaround the issue.
--
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/atta
This patch set updates the SMP config for MDP5, introduces a Config module for
easier platform config update and allows MDP5 driver to use multiple CRTCs as
well as multiple planes (overlay).
Stephane Viau (3):
drm/msm/mdp5: make SMP module dynamically configurable
drm/msm/mdp5: introduce mdp5
The Shared Memory Pool (SMP) has its own limitation, features and
state. Some examples are:
- the number of Memory Macro Block (MMB) and their size
- the number of lines that can be fetched
- the state of MMB currently allocated
- the computation of number of blocks required per plane
- client
The hardware configuration modification from a version to another
is quite consequent. Introducing a configuration module
(mdp5_cfg) may make things more clear and easier to access when a
new hardware version comes up.
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/Makefile|
MDP5 currently support one single CRTC with its private pipe.
This change allows the configuration of multiple CRTCs with
the possibility to attach several public planes to these CRTCs.
Signed-off-by: Stephane Viau
---
drivers/gpu/drm/msm/Makefile| 1 +
drivers/gpu/drm/msm/mdp/
On Tue, Nov 18, 2014 at 05:39:30PM +, Andrew Jackson wrote:
> On HDMI, the audio data are carried across the HDMI link which is
> driven by the TDMS clock. The TDMS clock is dependent on the video pixel
> rate.
>
> This patch sets the denominator (Cycle Time Stamp) appropriately
> allowing the
ceiving 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/20141118/127bbe8a/attachment.html>
On Tue, Nov 18, 2014 at 4:00 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> The cursor_set2 hook provides the cursor hotspot position within the
> cursor image. When the hotspot position changes, we can adjust the cursor
> position such that the hotspot doesn't move on the screen. This prev
On Tue, Nov 18, 2014 at 09:12:49AM -0800, Matt Roper wrote:
> From: Gustavo Padovan
>
> We need to get hdisplay and vdisplay in a few places so create a
> helper to make our job easier.
>
> v2 (by Matt): Use new stereo doubling function (suggested by Ville)
>
> v3 (by Matt):
> - Add missing ke
2014-11-18 Kevin Hilman :
> Javier Martinez Canillas writes:
>
> > The Exynos DRM driver register its sub-devices platform drivers in
> > the probe function but after commit 43c0767 ("of/platform: Move
> > platform devices under /sys/devices/platform"), this is causing
> > a deadlock in __driver
-
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/20141118/c790b0f5/attachment.html>
ceiving 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/20141118/a319ad4f/attachment.html>
-devel/attachments/20141118/3e83a3af/attachment.html>
Inki Dae wrote:
> Hi Tomasz,
>
> Yes, of course.
>
> We will fix it soon. For this, I mentioned earlier,
> http://web.archiveorange.com/archive/v/hhSc574WhqJAKgdBq7KL
>
> Thanks,
> Inki Dae
Hello,
it looks like libdrm git master is still using the EXYNOS_GEM_MMAP ioctl
that was removed by thi
freedesktop.org/archives/dri-devel/attachments/20141118/d8220ec6/attachment-0001.html>
--- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141118/d943a267/attachment.html>
>failed
>make[2]: *** [R600/.makeall] Error 2
>make[2]: Leaving directory '/mnt/sdb1/Src64/llvm/lib/Target'
>/mnt/sdb1/Src64/llvm/Makefile.rules:932: recipe for target 'Target/.makeall'
>failed
>make[1]: *** [Target/.makeall] Error 2
>make[1]: Leaving directory '/mnt/sdb1/Src64/llvm/lib'
>/mnt/sdb1/Src64/llvm/Makefile.rules:883: recipe for target 'all' failed
>make: *** [all] Error 1
>
--
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/20141118/e210fbb2/attachment.html>
t was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141118/b4b50e5c/attachment-0001.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141118/875c6269/attachment.html>
Hi Daniel,
On Tue, 18 Nov 2014 09:32:34 +0100
Daniel Vetter wrote:
> On Tue, Nov 18, 2014 at 04:00:29PM +0800, Mark Yao wrote:
> > From: Mark yao
> >
> > This patch adds the basic structure of a DRM Driver for Rockchip Socs.
> >
> > Signed-off-by: Mark Yao
> > Signed-off-by: Daniel Kurtz
>
On HDMI, the audio data are carried across the HDMI link which is
driven by the TDMS clock. The TDMS clock is dependent on the video pixel
rate.
This patch sets the denominator (Cycle Time Stamp) appropriately
allowing the driver to send audio to a wider range of HDMI sinks
(i.e. monitors).
Signe
Fetching the EDID from a connected monitor is an automated thing
with NXP TDA19988. But on some boards the fetching fails for the
first time silently without any indication that an error has occured.
More than that, subsequent fetches of the EDID succeed until the
monitor(s) are unplugged.
Add a f
On Mon, Nov 17, 2014 at 1:51 AM, Michel Dänzer wrote:
> On 15.11.2014 07:21, Andy Lutomirski wrote:
>>
>> I have a Caicos card, like this:
>>
>> [3.077260] [drm] radeon kernel modesetting enabled.
>> [3.077338] checking generic (e000 60) vs hw (e000
>> 1000)
>> [3.0773
[adding Kevin to cc list]
Hello Inki,
On Tue, Nov 18, 2014 at 11:52 AM, Inki Dae wrote:
> On 2014ë
11ì 18ì¼ 19:42, Andrzej Hajda wrote:
>> On 11/06/2014 10:06 AM, Krzysztof Kozlowski wrote:
>>> Hi,
>>>
>>> On last next (next-20141104, next-20141105) booting locks after
>>> initializing Exyn
Javier Martinez Canillas writes:
> The Exynos DRM driver register its sub-devices platform drivers in
> the probe function but after commit 43c0767 ("of/platform: Move
> platform devices under /sys/devices/platform"), this is causing
> a deadlock in __driver_attach(). Fix this by moving the platf
Gustavo Padovan writes:
> 2014-11-18 Kevin Hilman :
>
>> Javier Martinez Canillas writes:
>>
>> > The Exynos DRM driver register its sub-devices platform drivers in
>> > the probe function but after commit 43c0767 ("of/platform: Move
>> > platform devices under /sys/devices/platform"), this is
On Tue, Nov 18, 2014 at 4:21 PM, Andy Lutomirski wrote:
> On Mon, Nov 17, 2014 at 1:51 AM, Michel Dänzer wrote:
>> On 15.11.2014 07:21, Andy Lutomirski wrote:
>>>
>>> I have a Caicos card, like this:
>>>
>>> [3.077260] [drm] radeon kernel modesetting enabled.
>>> [3.077338] checking gene
On Tue, Nov 18, 2014 at 4:34 PM, Andy Lutomirski wrote:
> On Tue, Nov 18, 2014 at 4:21 PM, Andy Lutomirski
> wrote:
>> On Mon, Nov 17, 2014 at 1:51 AM, Michel Dänzer
>> wrote:
>>> On 15.11.2014 07:21, Andy Lutomirski wrote:
I have a Caicos card, like this:
[3.077260] [
The Exynos DRM driver register its sub-devices platform drivers in
the probe function but after commit 43c0767 ("of/platform: Move
platform devices under /sys/devices/platform"), this is causing
a deadlock in __driver_attach(). Fix this by moving the platform
drivers registration to exynos_drm_init
On Tue, Nov 18, 2014 at 02:21:30PM +0100, Boris Brezillon wrote:
> Hi Daniel,
>
> On Tue, 18 Nov 2014 09:32:34 +0100
> Daniel Vetter wrote:
>
> > On Tue, Nov 18, 2014 at 04:00:29PM +0800, Mark Yao wrote:
> > > From: Mark yao
> > >
> > > This patch adds the basic structure of a DRM Driver for R
1 - 100 of 103 matches
Mail list logo
