Hi Dave,
Here is the changes for drm headers, as requested.
The following changes since commit 9a0f76fde9ad2c00c0cf13aaf3dfb9d886dc578c:
Merge tag 'for-linus-4.4-1' of git://git.code.sf.net/p/openipmi/linux-ipmi
(2015-12-09 11:57:10 -0800)
are available in the git repository at:
https://g
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151210/697e401e/attachment.html>
- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151210/b254adde/attachment.html>
ng 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/20151210/22445bd2/attachment.html>
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151210/29207821/attachment.html>
ttachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151210/949bef0f/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151210/7ef8542c/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151210/18a5f4eb/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151210/b72199c4/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151210/558f4a9b/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20151210/201d4045/attachment.html>
On Mon, Nov 30, 2015 at 04:17:31AM +0200, Kirill A. Shutemov wrote:
> There are few defects in vga_get() related to signal hadning:
>
> - we shouldn't check for pending signals for TASK_UNINTERRUPTIBLE
> case;
>
> - if we found pending signal we must remove ourself from wait queue
> a
On 10 December 2015 at 10:03, Gabriel Laskar wrote:
> Hi Dave,
>
> Here is the changes for drm headers, as requested.
>
> The following changes since commit 9a0f76fde9ad2c00c0cf13aaf3dfb9d886dc578c:
>
> Merge tag 'for-linus-4.4-1' of git://git.code.sf.net/p/openipmi/linux-ipmi
> (2015-12-09 11:
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151210/61bd97ee/attachment-0001.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/20151210/b425c7c8/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/20151210/d5c0437e/attachment.html>
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/20151210/3a6ea3bb/attachment.html>
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/20151210/3e489766/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151210/96975f58/attachment.html>
remove it.
--
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/20151210/ac88e25c/attachment.html>
CCing Mr. Kukjin and Krzysztof
Hi Kukjin and Krzysztof,
Below patch includes dt binding about gsc device but it'd be nice this patch to
exynos drm tree with others.
So could you give me Acked-by so that I can merge it to exynos drm tree?
Thanks,
Inki Dae
2015ë
11ì 30ì¼ 22:53ì Marek Szy
On 10.12.2015 15:48, Inki Dae wrote:
> CCing Mr. Kukjin and Krzysztof
>
>
> Hi Kukjin and Krzysztof,
>
> Below patch includes dt binding about gsc device but it'd be nice this patch
> to exynos drm tree with others.
> So could you give me Acked-by so that I can merge it to exynos drm tree?
>
>
n HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151210/539324ca/attachment.html>
Hi
On 2015-11-09, Dave Airlie wrote:
[...]
The following changes since commit 06d1ee32a4d25356a710b49d5e95dbdd68bdf505:
Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux
(2015-10-13 09:45:21 -0700)
are available in the git repository at:
git://people.freedesktop.org/~
On Thu, Dec 10, 2015 at 04:04:20AM +0100, Stefan Lippers-Hollmann wrote:
> Hi
>
> On 2015-11-09, Dave Airlie wrote:
> [...]
> The following changes since commit 06d1ee32a4d25356a710b49d5e95dbdd68bdf505:
>
> Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux
> (2015-10-13 0
On Wed, Dec 09, 2015 at 08:11:39PM +0100, Corentin LABBE wrote:
> Le 09/12/2015 16:32, Jani Nikula a écrit :
> > On Wed, 09 Dec 2015, LABBE Corentin wrote:
> >> My latest commit introduce some case where a valid mode, could be
> >> rejected.
> >> simple_strtox functions stop at first non-digit ch
k_all+0x60/0xd8 [ 12.041037] #2:
>>> (crtc_ww_class_mutex){+.+.+.}, at: []
>>> drm_modeset_lock+0x84/0x104 [ 12.041044]
>>> [ 12.041044] stack backtrace:
>>> [ 12.041048] CPU: 3 PID: 793 Comm: Xorg Not tainted 4.4.0-rc3+ #2755
>>> [ 12.041049] Hardwa
This change just make a little clean to make code more like
drm core expect, move hdp detect code from bridge->enable(),
and place them into connector->detect().
Note: Gustavo Padovan try to remove the controller and phy
power on function in bind time at bellow commit:
drm/exynos: do not s
Turn off the panel power in suspend time would help to reduce
power waste.
Signed-off-by: Yakir Yang
---
This patch was introduced in v10.1, suggested by Heiko
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
It may caused a dead lock if we flush the hpd work in bridge disable time.
The normal flow would like:
IN --> DRM IOCTL
1. Acquire crtc_ww_class_mutex (DRM IOCTL)
IN --> analogix_dp_bridge
2. Acquire hpd work lock (Flush hpd work)
3. HPD work already in idle, no need to
ves/dri-devel/attachments/20151210/f7c40b48/attachment.html>
Hi
On Mon, Nov 30, 2015 at 3:17 AM, Kirill A. Shutemov
wrote:
> There are few defects in vga_get() related to signal hadning:
>
> - we shouldn't check for pending signals for TASK_UNINTERRUPTIBLE
> case;
>
> - if we found pending signal we must remove ourself from wait queue
> and cha
like the mmap error has been 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/20151210/7ee7cd77/attachment.html>
Hi Marek,
2015ë
11ì 30ì¼ 22:53ì Marek Szyprowski ì´(ê°) ì´ ê¸:
> This patch fixes trashed display of buffers cropped to very small width.
> Even if DMA is unstable and causes tearing when changing the burst size,
> it is still better than displaying a garbage.
It seems that this patch
On 08/12/15 16:52, Liviu Dudau wrote:
> On Tue, Dec 08, 2015 at 04:25:27PM +, Robin Murphy wrote:
>> Hi Liviu,
>>
>> On 07/12/15 12:11, Liviu Dudau wrote:
>>> The HDLCD controller is a display controller that supports resolutions
>>> up to 4096x4096 pixels. It is present on various development
Hi Marek,
2015ë
11ì 30ì¼ 22:53ì Marek Szyprowski ì´(ê°) ì´ ê¸:
> This patch adds common structure for keeping plane configuration and
> capabilities data. This patch is inspired by similar code developed by
> Tobias Jakobi.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/gpu/drm/
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151210/4bacd97f/attachment.html>
Hi Dave,
Here is the changes for drm headers, as requested and rebased onto 4.4-rc4
The following changes since commit 527e9316f8ec44bd53d90fb9f611fa752bb9:
Linux 4.4-rc4 (2015-12-06 15:43:12 -0800)
are available in the git repository at:
https://github.com/GabrielL/linux.git drm-heade
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151210/18457017/attachment.html>
We are currently restricted when it comes to supporting DSI on devices
that have a non-DSI control bus. For example, DSI encoder chips are
available in the market that are configured via i2c. Configuring their
registers via DSI bus is either optional or not available at all.
These devices still ne
of_mipi_dsi_device_add is used only when CONFIG_OF is enabled. It
currently works if OF support is disabled, but this will change
when we add more functionality to it.
Define the original func if CONFIG_OF is enabled. Define a dummy func
otherwise.
Signed-off-by: Archit Taneja
---
drivers/gpu/d
Simplify the mipi dsi device creation process. device_initialize and
device_add don't need to be called separately when creating
mipi_dsi_device's. Use device_register instead to simplify things.
Create a helper function mipi_dsi_device_new which takes in struct
mipi_dsi_device_info and mipi_dsi_h
Add a device name field in mipi_dsi_device. This name is different from
the actual dev name (which is of the format "hostname.reg"). When the
device is created via DT, this name is set to the modalias string.
In the non-DT case, the driver creating the DSI device provides the
name by populating a f
We don't check whether a previously registered mipi_dsi_device under the
same host shares the same virtual channel.
Before registering, check if any of the registered devices doesn't
already have the same virtual channel.
This wasn't crucial when all the devices under a host were populated via
DT
A driver calling mipi_dsi_device_new might want to unregister the device
once it's done. It might also require it in an error handling path in
case something didn't go right.
Reviewed-by: Andrzej Hajda
Signed-off-by: Archit Taneja
---
include/drm/drm_mipi_dsi.h | 5 +
1 file changed, 5 inse
mipi_dsi_devices are inherently aware of their host because they
share a parent-child hierarchy in the device tree.
non-dsi drivers that create dsi device don't have this data. In order to
get this information, they require to a phandle to the dsi host in the
device tree.
Maintain a list of all t
On Thu, 10 Dec 2015, Daniel Vetter wrote:
> On Thu, Dec 10, 2015 at 04:04:20AM +0100, Stefan Lippers-Hollmann wrote:
>> Hi
>>
>> On 2015-11-09, Dave Airlie wrote:
>> [...]
>> The following changes since commit 06d1ee32a4d25356a710b49d5e95dbdd68bdf505:
>>
>> Merge branch 'drm-fixes' of git://pe
loading the next round. Haven't captured
the tracebacks from that yet...
--
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/
Hello,
On 2015-12-10 12:35, Inki Dae wrote:
> Hi Marek,
>
> 2015ë
11ì 30ì¼ 22:53ì Marek Szyprowski ì´(ê°) ì´ ê¸:
>> This patch fixes trashed display of buffers cropped to very small width.
>> Even if DMA is unstable and causes tearing when changing the burst size,
>> it is still better
#x27;m inclined to say it's probably not the
OpenGL driver's fault.
--
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/a
2015ë
11ì 30ì¼ 22:53ì Marek Szyprowski ì´(ê°) ì´ ê¸:
> DMA address is a framebuffer attribute and the right place for it is
> exynos_drm_framebuffer not exynos_drm_plane. This patch also introduces
> helper function for getting dma address of the given framebuffer.
>
> Signed-off-by:
On 08/12/15 19:24, David Herrmann wrote:
> Hi
>
> On Tue, Dec 8, 2015 at 5:39 PM, Martin Peres wrote:
>> On 08/12/15 13:59, David Herrmann wrote:
>>> I looked into all this when working on WFD, but I cannot recommend
>>> going down that road. First of all, you still need heavy modifications
>>> fo
At the moment omapfb and omapdrm can be compiled at the same time, if
both are modules. However, they can't be both loaded, as they use the
same hardware. This has been mostly for compile testing.
To make it clear that omapfb and omapdrm are mutually exclusive drivers,
this patch makes omapfb avai
Hi,
Here's an RFC series to fix the mess we have at the moment with
omapdrm/omapfb/omapdss.
First, a short background on the current status. We have the following
entities:
* omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the
display subsystem IPs used on OMAP (and re
We need to change the config symbols of omapfb's private copy of
omapdss so that we won't have config symbol conflicts.
This patch changes the symbols from omapdss using simple replacement of
CONFIG_OMAP* to CONFIG_FB_OMAP*.
Signed-off-by: Tomi Valkeinen
---
drivers/video/fbdev/omap2/omapfb/dss
We are about to make a private copy of omapdss for omapfb and for
omapdrm. The omapdss.h file will still be shared for the time being. The
copy will need to change the config symbols, and we happen to have one
use of these config symbols in omapdss.h which needs to be removed.
Luckily we can just
We need to change the config symbols of omapfb's private copy of the
panel and encoder drivers so that we won't have config symbol conflicts.
This patch changes the symbols from the panel and encoder drivers using
simple replacement of DISPLAY_* to FB_OMAP2*.
Signed-off-by: Tomi Valkeinen
---
d
omapfb's private copy of omapdss is now ready to be used.
This patch makes omapfb use its private omapdss and display drivers, and
also makes omap_vout (which uses omapfb) to depend on omapfb.
Signed-off-by: Tomi Valkeinen
---
drivers/media/platform/omap/Kconfig | 2 +-
drivers/video/fbde
VRFB is only used by omapfb, so we can move it under omapfb's directory.
Signed-off-by: Tomi Valkeinen
---
drivers/video/fbdev/omap2/Kconfig | 3 ---
drivers/video/fbdev/omap2/Makefile| 2 --
drivers/video/fbdev/omap2/omapfb/Kconfig | 3 +++
drivers/video/fbdev/omap2
Now that omapfb has its own copy of omapdss and display drivers, we can
move omapdss and display drivers which omapdrm uses to omapdrm's
directory.
We also need to change the main drm Makefile so that omapdrm directory
is always entered, because omapdss has a file that always needs to be
built-in.
Now that omapdss is only for omapdrm, we can change omapdrm to select
OMAP2_DSS to enable omapdss if omapdrm is enabled, instead of omapdrm
depending on omapdss.
We can also change omapdss and the display drivers to depend on
DRM_OMAP, so that they are only visible under omapdrm in menuconfig.
Si
o try running it with
valgrind, but exit the game before it crashes.
--
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/20151210/
On Thu, Dec 10, 2015 at 9:25 AM, Tomi Valkeinen
wrote:
> Hi,
>
> Here's an RFC series to fix the mess we have at the moment with
> omapdrm/omapfb/omapdss.
>
> First, a short background on the current status. We have the following
> entities:
>
> * omapdss, located in drivers/video/fbdev/omap2/dss
re
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151210/b9a28003/attachment.sig>
This patch makes a copy of the omapdss driver and the omap panel &
encoder drivers for omapfb. The purpose is to separate omapdrm and
omapfb drivers from each other.
Note that this patch only does a direct copy of the files without any
other modifications. The files are not yet used.
Signed-off-b
Hi Inki,
On 10 December 2015 at 12:59, Marek Szyprowski
wrote:
> On 2015-12-10 12:35, Inki Dae wrote:
>> 2015ë
11ì 30ì¼ 22:53ì Marek Szyprowski ì´(ê°) ì´ ê¸:
>>> This patch fixes trashed display of buffers cropped to very small width.
>>> Even if DMA is unstable and causes tearing whe
On 10 December 2015 at 14:53, Rob Clark wrote:
> It would be nice to see omapdrm eventually using the panel framework,
> etc. But I think copy/paste to decouple omapdrm from omapfb/vout as
> the first step makes sense.
>
Moar panels/bridges :-P
But seriously, I think that this is the better ide
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151210/e226da56/attachment.sig>
tachments/20151210/b5c0f04a/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151210/9521e5f9/attachment.html>
On Fri, Dec 4, 2015 at 6:24 AM, Michel Thierry
wrote:
> On 11/18/2015 10:53 PM, Kristian Høgsberg wrote:
>>
>> On Wed, Oct 14, 2015 at 5:11 AM, Michel Thierry
>> wrote:
>>>
>>> On 10/14/2015 8:19 AM, Daniel Vetter wrote:
On Tue, Oct 13, 2015 at 02:51:36PM -0700, Kristian Høgsber
From: Ville Syrjälä
MODE_UNVERIFIED actually means that the mode came from a previous probe,
and if the new probe doesn't produce a matching mode it will get pruned
from the list. Rename the flag to MODE_STALE to better convey the
meaning.
v2: Rebased due to conflicts with Daniel's doc stuff
On Fri, Dec 04, 2015 at 09:17:28AM +0100, Daniel Vetter wrote:
> On Thu, Dec 03, 2015 at 11:14:09PM +0200, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrjälä
> >
> > The way the mode probing works is this:
> > 1. All modes currently on the mode list are marked as UNVERIFIED
> >
From: Ville Syrjälä
Daniel wanted me to slap some more docs on the probe helper, so I
tried (and mostly failed). And while doing that I realized that the
priority between the firmware EDID and override_edid didn't make
much sense so I went ahead and flipped it over.
Ville Syrjälä (2):
drm:
From: Ville Syrjälä
IMO the override_edid should override any default EDID for the
connector, whether that came in via the connector helper ->get_modes()
vfunc or via the firmware EDID mechanism.
Cc: Thomas Wood
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_probe_helper.c | 17
From: Ville Syrjälä
Describe the procedure that drm_helper_probe_single_connector_modes()
uses to do it's work in the kernel-doc comment.
Caveat: Looks like crap and trying to reverse engineer the documentation
tools is not something I want to do.
Suggested-by: Daniel Vetter
Signed-off-by: V
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/20151210/8a66fc54/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151210/004cae16/attachment-0001.html>
78 matches
Mail list logo
