How to support various hardware blocks in drm driver

2014-03-18 21:47 GMT+09:00 Daniel Vetter : > On Tue, Mar 18, 2014 at 1:42 PM, Inki Dae wrote: >> I think now drm_bridge couldn't do what we want for embedded systems >> as long as drm_encoder has drm_bridge. >> See the blow hardware pipeline, >> Display Controller-Image Enhancement

How to support various hardware blocks in drm driver

2014-03-18 21:22 GMT+09:00 Daniel Vetter : > On Tue, Mar 18, 2014 at 1:12 PM, Rob Clark wrote: >> I think the question is how to go from zero or one >> bridge/hwblock/widget/whatever to zero or more.. >> >> an alternate set of helpers is one option. But it didn't turn out to >> be too intrusive

linux-next: build failure after merge of the drm-intel tree

On Wed, 19 Mar 2014 11:53:50 +1100 Stephen Rothwell wrote: > Caused by commit a25ca17c1eac ("drm/i915: Do not dereference pointers > from ring buffer in evict event"). > > I have used the drm-intel tree from next-20140318 for today. > Bah! I'm still suffering fro

[RFCv3 00/14] Unified plane support

On Tue, Mar 18, 2014 at 8:22 PM, Matt Roper wrote: > Previous revision and explanation of series: >http://lists.freedesktop.org/archives/dri-devel/2014-March/055222.html > > Main changes since last pass: > * Added cursor plane support on i915. Unfortunately it isn't possible to >create

[Bug 76297] open source radeon drivers for old graphics cards crash the system while booting kernels 3.12+

ked so yes it used to work in many kernel before 3.2 , 3.4 , 3.9 , 3.11 for sure dont remember if there were more. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.o

How to support various hardware blocks in drm driver

Thanks for comments, 2014-03-18 19:27 GMT+09:00 Daniel Vetter : > On Tue, Mar 18, 2014 at 05:26:42PM +0900, Inki Dae wrote: >> Hello all, >> >> The purpose of this email is for discussion to how we could support >> various hardware blocks such as LVDS bridges, Image Enhancement chips >> and

[Bug 42960] Display does not work when resuming from suspend

scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140318/3d77fc90/attachment.html>

[Bug 42960] Display does not work when resuming from suspend

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140318/950644df/attachment-0001.html>

[Intel-gfx] linux-next: build failure after merge of the drm-intel tree

> I have used the drm-intel tree from next-20140318 for today. > > > > Bah! I'm still suffering from jet lag (just came back from Linux-Tage > in Chemnitz). > > The next time I compile test a patch for a module, I'll make sure I have > that module's config option se

How to support various hardware blocks in drm driver

On Tue, Mar 18, 2014 at 09:58:25PM +0900, Inki Dae wrote: > 2014-03-18 21:47 GMT+09:00 Daniel Vetter : > > On Tue, Mar 18, 2014 at 1:42 PM, Inki Dae wrote: > >> I think now drm_bridge couldn't do what we want for embedded systems > >> as long as drm_encoder has drm_bridge. > >> See the blow

[RFC patch v3] x86: Improve boot_vga/vga_default_device() for EFI

With commit b4aa0163056b6c70029b6e8619ce07c274351f42 Matthew Garret introduced a efifb vga_default_device() so that EFI systems that do not load shadow VBIOS or setup VGA get proper value for boot_vga PCI sysfs attribute on the corresponding PCI device. Xorg is refusing to detect devices when

How to support various hardware blocks in drm driver

Hello all, The purpose of this email is for discussion to how we could support various hardware blocks such as LVDS bridges, Image Enhancement chips and parallel panels in drm driver. Now we have drm_panel framework for controlling parallel panels, and drm_bridge for controlling LVDS bridge

[RFCv3 14/14] drm/i915: Add cursor handlers and create cursor at crtc init

Cc: Intel Graphics Development Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/intel_display.c | 90 +++- 1 file changed, 89 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index

[RFCv3 13/14] drm/i915: Split cursor update code from cursor ioctl handling

Legacy cursor ioctls took GEM buffer handles from userspace directly whereas the new unified plane handling assigns drm_framebuffer's to cursor planes. Splitting the code that actually updates the cursor plane from the code that handles object lookup and reference counting allows us to share

[RFCv3 12/14] drm: Specify cursor plane at CRTC initialization

Add cursor plane as a parameter to drm_crtc_init() and update all existing DRM drivers to use a helper-provided primary plane. Passing NULL for this parameter indicates that there is no hardware cursor supported by the driver and no cursor plane should be provided to userspace. Signed-off-by:

[RFCv3 11/14] drm/i915: Intel-specific primary plane handling

Intel hardware allows the primary plane to be disabled independently of the CRTC. Provide custom primary plane handling to allow this. Cc: Intel Graphics Development Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/intel_display.c | 132 ++-

[RFCv3 10/14] drm/i915: Rename similar plane functions to avoid confusion

The name 'update_plane' was used both for the primary plane functions in intel_display.c and the sprite/overlay functions in intel_sprite.c. Rename the primary plane functions to 'update_primary_plane' to avoid confusion. On a similar note, intel_display.c already had a function called

[RFCv3 09/14] drm: Allow userspace to ask for full plane list (universal planes)

Userspace clients which wish to receive all DRM planes (primary and cursor planes in addition to the traditional overlay planes) may set the DRM_CLIENT_CAP_UNIVERSAL_PLANES capability. Signed-off-by: Matt Roper --- drivers/gpu/drm/drm_crtc.c | 20 +++-

[PATCH 16/16] drm: spiff out FB refcnting traces

I find myself making this change locally whenever debugging FB reference counting. Which seems a bit silly. Signed-off-by: Rob Clark --- drivers/gpu/drm/drm_crtc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c

[RFCv3 08/14] drm: Replace crtc fb with primary plane fb (v2)

Now that CRTC's have a primary plane, there's no need to track the framebuffer in the CRTC. Replace all references to the CRTC fb with the primary plane's fb. Also note that this simplifies framebuffer removal slightly; we no longer need to scan all CRTC's and disable the ones that were using

[PATCH 15/16] drm/msm: add atomic support

TODO: probably can split this up into prep patch which splits the msm_queue_fence_cb out of gem.. --- drivers/gpu/drm/msm/Makefile | 1 + drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 59 ++--- drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 6 ++

[RFCv3 07/14] drm: Specify primary plane at CRTC initialization (v2)

Add primary plane as a parameter to drm_crtc_init() and update all existing DRM drivers to use a helper-provided primary plane. v2: Update msm & omap drivers to use existing "private" planes as primary planes instead of helper [Rob Clark] Tested-by: Rob Clark Signed-off-by: Matt Roper ---

[PATCH 14/16] drm: Atomic modeset ioctl

From: Ville Syrj?l? The atomic modeset ioctl cna be used to push any number of new values for object properties. The driver can then check the full device configuration as single unit, and try to apply the changes atomically. The ioctl simply takes a list of

[RFCv3 06/14] drm: Add plane type property

Add a plane type property to allow userspace to distinguish plane types. The type of the plane will now be established at drm_plane_init() time (replacing the 'priv' parameter previously used). Signed-off-by: Matt Roper --- drivers/gpu/drm/armada/armada_overlay.c| 3 +-

[PATCH 13/16] drm: push locking down into restore_fbdev_mode

All the call-sites save one need locking. By pushing it down and adding a lockless flag, we can use the new spiffy atomic ww_mutex crtc locking and simplify all the call-sites. Signed-off-by: Rob Clark --- drivers/gpu/drm/armada/armada_fbdev.c | 4 +--- drivers/gpu/drm/drm_fb_cma_helper.c

[RFCv3 05/14] drm/i915: Restrict plane loops to only operate on overlay planes

Before we add additional types of planes to the DRM plane list, ensure that existing loops over all planes continue to operate only on "overlay" planes and ignore primary & cursor planes. Cc: Intel Graphics Development Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/intel_display.c | 6

[PATCH 12/16] drm: convert crtc to properties/state

Break the mutable state of a crtc out into a separate structure and use atomic properties mechanism to set crtc attributes. This makes it easier to have some helpers for crtc->set_property() and for checking for invalid params. The idea is that individual drivers can wrap the state struct in

[RFCv3 04/14] drm/exynos: Restrict plane loops to only operate on overlay planes

Before we add additional types of planes to the DRM plane list, ensure that existing loops over all planes continue to operate only on "overlay" planes and ignore primary & cursor planes. Cc: Inki Dae Signed-off-by: Matt Roper --- drivers/gpu/drm/exynos/exynos_drm_encoder.c | 6 ++ 1 file

[PATCH 11/16] drm: convert plane to properties/state

Break the mutable state of a plane out into a separate structure and use atomic properties mechanism to set plane attributes. This makes it easier to have some helpers for plane->set_property() and for checking for invalid params. The idea is that individual drivers can wrap the state struct in

[RFCv3 03/14] drm: Add primary plane helpers

When we expose non-overlay planes to userspace, they will become accessible via standard userspace plane API's. We should be able to handle the standard plane operations against primary planes in a generic way via the page flip handler and modeset handler. Drivers that can program primary planes

[PATCH 10/16] drm: allow FB's in drm_mode_object_find

We do actually want to permit FB's in atomic case, since FB will be looked up like any other object property value in a few code paths (like property value validation). So split out into an internal function without the WARN_ON() which we can use in those special cases. Signed-off-by: Rob Clark

[RFCv3 02/14] drm: Add support for multiple plane types

The DRM core currently only tracks "overlay"-style planes. Start refactoring the plane handling to allow other plane types (primary and cursor) to also be placed on the DRM plane list. Signed-off-by: Matt Roper --- drivers/gpu/drm/drm_crtc.c | 21 -

[PATCH 09/16] drm: Refactor object property check code

From: Ville Syrj?l? Refactor the code to check whether an object has a specific property to a new function. v1: original v2: rebase on atomic -- Rob Clark v3: EINVAL->ENOENT Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_crtc.c | 25

[RFCv3 01/14] SQUASH! drm/i915: Do not dereference pointers from ring buffer in evict event

Build fix for drm-intel-nightly: there is no 'dev' variable for TP_fast_assign(); should be vm->dev. Cc: intel-gfx at lists.freedesktop.org Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/i915_trace.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 08/16] drm: Allow drm_mode_object_find() to look up an object of any type

From: Ville Syrj?l? To avoid having to pass object types from userspace for atomic mode setting ioctl, allow drm_mode_object_find() to look up an object of any type. This will only work as long as the all object types share the ID space. Signed-off-by: Ville

[RFCv3 00/14] Unified plane support

Previous revision and explanation of series: http://lists.freedesktop.org/archives/dri-devel/2014-March/055222.html Main changes since last pass: * Added cursor plane support on i915. Unfortunately it isn't possible to create nice generic helper functions that make use of the legacy API's

[PATCH 07/16] drm: split propvals out and blob property support

Split property values out into a different struct, so we can later move property values into state structs. This will allow the property values to stay in sync w/ the state updates which are either discarded or atomically committed. And since we are touching all the same code, add support for

[PATCH 06/16] drm: helpers to find mode objects

Add a few more useful helpers to find mode objects. Signed-off-by: Rob Clark --- drivers/gpu/drm/drm_crtc.c | 97 ++ include/drm/drm_crtc.h | 33 2 files changed, 63 insertions(+), 67 deletions(-) diff --git

[PATCH 05/16] drm: add signed-range property type

Like range, but values are signed. Signed-off-by: Rob Clark --- drivers/gpu/drm/drm_crtc.c | 29 + include/drm/drm_crtc.h | 12 include/uapi/drm/drm_mode.h | 1 + 3 files changed, 38 insertions(+), 4 deletions(-) diff --git

[PATCH 04/16] drm: add object property type

An object property is an id (idr) for a drm mode object. This will allow a property to be used set/get a framebuffer, CRTC, etc. Signed-off-by: Rob Clark --- drivers/gpu/drm/drm_crtc.c | 60 +++-- include/drm/drm_crtc.h | 27

[PATCH 03/16] drm: convert crtc to ww_mutex

For atomic, it will be quite convenient to not have to care so much about locking order. And 'state' gives us a convenient place to stash a ww_ctx for any sort of update that needs to grab multiple crtc locks. Because we will want to eventually make locking even more fine grained (giving locks

[PATCH 02/16] drm: add atomic fxns

The 'atomic' mechanism allows for multiple properties to be updated, checked, and commited atomically. This will be the basis of atomic- modeset and nuclear-pageflip. The basic flow is: state = dev->atomic_begin(); for (... one or more ...) obj->set_property(obj, state, prop,

[PATCH 01/16] drm: fix typo

Signed-off-by: Rob Clark --- drivers/gpu/drm/drm_crtc_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c index 6d438ef..b2fdf35 100644 --- a/drivers/gpu/drm/drm_crtc_helper.c +++

[PATCH 00/16] Atomic/nuclear modeset/pageflip

Previous revision of series: http://lists.freedesktop.org/archives/dri-devel/2013-November/049594.html And if you prefer, in git form: http://cgit.freedesktop.org/~robclark/linux/log/?h=cold-fusion git://people.freedesktop.org/~robclark/linux cold-fusion Compared to previous revision: * rebased

[PATCH 1/4] drm/radeon/dp: use i2c_get_adapdata rather than casting

Am 18.03.2014 04:48, schrieb Alex Deucher: > Minor code cleanup. > > Signed-off-by: Alex Deucher Added to my 3.15 queue (http://cgit.freedesktop.org/~deathsimple/linux/log/?h=drm-next-3.15-wip). Thanks, Christian. > --- > drivers/gpu/drm/radeon/atombios_dp.c | 2 +- > 1 file changed, 1

[Bug 65787] r600g: corruption in menu in "stunt rally"

: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140318/5607740b/attachment.html>

Kernel oops in udl driver

Hi, While testing server managed fd support for the xf86-video-modesetting driver I encountered the following oops on exiting the Xserver (this happened only once during all my testing). This was with the Xserver / udev configured to use a single Xserver for both the intel-gfx of my workstation

[Bug 65787] r600g: corruption in menu in "stunt rally"

ok 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/20140318/e221d8ea/attachment.html>

[PATCH] drm/exynos: Fix (more) freeing issues in exynos_drm_drv.c

2014-03-18 14:45 GMT+09:00 Kukjin Kim : > Inki Dae wrote: >> >> Applied. >> >> Thanks, >> Inki Dae >> >> 2014-03-17 12:28 GMT+09:00 Daniel Kurtz : >> > The following commit [0] fixed a use-after-free, but left the subdrv >> open >> > in the error path. >> > >> > [0] commit

[PATCH] drm/exynos: Fix (more) freeing issues in exynos_drm_drv.c

On Tue, Mar 18, 2014 at 2:08 PM, Inki Dae wrote: > 2014-03-18 14:45 GMT+09:00 Kukjin Kim : >> Inki Dae wrote: >>> >>> Applied. >>> >>> Thanks, >>> Inki Dae >>> >>> 2014-03-17 12:28 GMT+09:00 Daniel Kurtz : >>> > The following commit [0] fixed a use-after-free, but left the subdrv >>> open >>> >

[PATCH] drm/exynos: Fix (more) freeing issues in exynos_drm_drv.c

Inki Dae wrote: > > Applied. > > Thanks, > Inki Dae > > 2014-03-17 12:28 GMT+09:00 Daniel Kurtz : > > The following commit [0] fixed a use-after-free, but left the subdrv > open > > in the error path. > > > > [0] commit 6ca605f7c70895a35737435f17ae9cc5e36f1466 > > drm/exynos: Fix freeing issues

[PATCH 0/9] Restore parallel display support for Exynos based boards

Hi Andrzej, On 17.03.2014 11:27, Andrzej Hajda wrote: > Hi, > > This patch set restores parallel display support removed during exynos > refactorization. It is rebased on the latest exynos-drm-next branch plus patch > adding polarization flags to drm_display_mode [1]. > > [1]:

[PATCH 07/12] drm: drm_display_mode: add signal polarity flags

Hi, Laurent Pinchart wrote: > Hi Lothar, > > On Tuesday 18 March 2014 08:50:30 Lothar Wa?mann wrote: > > Laurent Pinchart wrote: > > > On Monday 17 March 2014 16:14:36 Lothar Wa?mann wrote: > > > > Laurent Pinchart wrote: > > > > > On Monday 17 March 2014 14:41:09 Andrzej Hajda wrote: > > > > >

[PATCH 07/12] drm: drm_display_mode: add signal polarity flags

Hi Russell, On Tuesday 18 March 2014 12:56:23 Russell King - ARM Linux wrote: > On Tue, Mar 18, 2014 at 01:41:54PM +0100, Laurent Pinchart wrote: > > Hi Lothar, > > > > That's not my point. I *know* that DE is a data gating signal with a > > polarity already defined by the

[PATCH 08/12] imx-drm: Use drm_display_mode timings flags.

Hi, Denis Carikli wrote: > The previous hardware behaviour was kept if the > flags are not set. > > Signed-off-by: Denis Carikli > --- > ChangeLog v10->v11: > - This patch was splitted-out and adapted from: > "Prepare imx-drm for extra display-timings retrival." > - The display-timings dt

[PATCH] drm/exynos: set the active aspect ratio as per mode

Hi Shirish, On 13.03.2014 06:28, Shirish S wrote: > Now that the drm_display_mode also provides aspect > ratio for all resolutions, this patch adds its usage > to set the active aspect ratio of AVI info frame > packets as per CEA-861-D standard's Table 9. > > This is also needed to abide by the

[PATCH] drm/exynos: Fix (more) freeing issues in exynos_drm_drv.c

Applied. Thanks, Inki Dae 2014-03-17 12:28 GMT+09:00 Daniel Kurtz : > The following commit [0] fixed a use-after-free, but left the subdrv open > in the error path. > > [0] commit 6ca605f7c70895a35737435f17ae9cc5e36f1466 > drm/exynos: Fix freeing issues in exynos_drm_drv.c > > Change-Id:

[Bug 76320] New: libpciaccess seems to require xorg-macros for no reason

eiving 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/20140318/577e72e6/attachment.html>

[PATCH] drm/exynos: add phy settings for RB resolutions

Hi Shirish, On 13.03.2014 06:28, Shirish S wrote: > This patch adds support for the below mentioned > pixel clocks in Exynos5250. > Without them, following display modes won?t > be supported: > > 71 MHz- 1280x800 at 60Hz RB > 73.25 MHz - 800x600 at 120Hz RB > 88.75 MHz - 1440x900

How to support various hardware blocks in drm driver

On Tue, Mar 18, 2014 at 1:42 PM, Inki Dae wrote: > I think now drm_bridge couldn't do what we want for embedded systems > as long as drm_encoder has drm_bridge. > See the blow hardware pipeline, > Display Controller-Image Enhancement chip-MIP DSI-MIPI TO > LVDS Bridge-LCD Panel >

[PATCH 6/9] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel

e much guidance on this. -- Regards, Laurent Pinchart -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140318/7f542994/attachment.sig>

[PATCH 07/12] drm: drm_display_mode: add signal polarity flags

Hi Lothar, On Tuesday 18 March 2014 08:50:30 Lothar Wa?mann wrote: > Laurent Pinchart wrote: > > On Monday 17 March 2014 16:14:36 Lothar Wa?mann wrote: > > > Laurent Pinchart wrote: > > > > On Monday 17 March 2014 14:41:09 Andrzej Hajda wrote: > > > > > On 03/13/2014 06:17 PM, Denis Carikli

[RFCv4 09/14] drm: convert plane to properties/state

On Tue, Mar 18, 2014 at 12:24 PM, Rob Clark wrote: > On Tue, Mar 18, 2014 at 11:48 AM, Sean Paul wrote: >> On Mon, Nov 25, 2013 at 9:47 AM, Rob Clark wrote: >>> Break the mutable state of a plane out into a separate structure >>> and use atomic properties mechanism to set plane attributes.

[Bug 75929] Configuring Mesa to use shared libLLVM.so fails

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140318/2c066249/attachment.html>

[Bug 76297] open source radeon drivers for old graphics cards crash the system while booting kernels 3.12+

... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140318/f32f1482/attachment.html>

How to support various hardware blocks in drm driver

On Tue, Mar 18, 2014 at 1:12 PM, Rob Clark wrote: > I think the question is how to go from zero or one > bridge/hwblock/widget/whatever to zero or more.. > > an alternate set of helpers is one option. But it didn't turn out to > be too intrusive to the existing helpers to add bridge in the first

How to support various hardware blocks in drm driver

On Tue, Mar 18, 2014 at 1:12 PM, Rob Clark wrote: >> What's the difference here compared to an encoder_slave? I don't really >> see the point of adding yet another such thing to the drm core ... > > so I think at one point the rough idea was to add additional fxn ptrs > to bridge as the need

[PATCH 07/12] drm: drm_display_mode: add signal polarity flags

On Tue, Mar 18, 2014 at 01:41:54PM +0100, Laurent Pinchart wrote: > Hi Lothar, > > That's not my point. I *know* that DE is a data gating signal with a polarity > already defined by the DRM_MODE_FLAG_POL_DE_(LOW|HIGH) flags. Like all other > signals it gets generated on a clock edge and is

[RFCv4 09/14] drm: convert plane to properties/state

On Tue, Mar 18, 2014 at 11:48 AM, Sean Paul wrote: > On Mon, Nov 25, 2013 at 9:47 AM, Rob Clark wrote: >> Break the mutable state of a plane out into a separate structure >> and use atomic properties mechanism to set plane attributes. This >> makes it easier to have some helpers for

How to support various hardware blocks in drm driver

On Tue, Mar 18, 2014 at 11:22 AM, Inki Dae wrote: > 2014-03-18 22:29 GMT+09:00 Rob Clark : >> On Tue, Mar 18, 2014 at 8:58 AM, Inki Dae wrote: >>> 2014-03-18 21:47 GMT+09:00 Daniel Vetter : On Tue, Mar 18, 2014 at 1:42 PM, Inki Dae wrote: > I think now drm_bridge couldn't do what we

[Bug 73619] XServer frequently freezes for a few seconds

. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140318/41103737/attachment-0001.html>

[RFCv4 09/14] drm: convert plane to properties/state

On Mon, Nov 25, 2013 at 9:47 AM, Rob Clark wrote: > Break the mutable state of a plane out into a separate structure > and use atomic properties mechanism to set plane attributes. This > makes it easier to have some helpers for plane->set_property() > and for checking for invalid params. The

How to support various hardware blocks in drm driver

On Tue, Mar 18, 2014 at 05:26:42PM +0900, Inki Dae wrote: > Hello all, > > The purpose of this email is for discussion to how we could support > various hardware blocks such as LVDS bridges, Image Enhancement chips > and parallel panels in drm driver. > > Now we have drm_panel framework for

[PATCH] Revert "[PATCH] Insert GART region into resource map"

This reverts commit 56dd669a138c, which makes the GART visible in /proc/iomem. This fixes a regression: e501b3d87f00 ("agp: Support 64-bit APBASE") exposed an existing problem with a conflict between the GART region and a PCI BAR region. The GART addresses are bus addresses, not CPU addresses,

[PATCH] Remove GART aperture from iomem_resource

This is a fix for a regression exposed by an AGP patch I merged in v3.14-rc1. Assuming nobody complains, I'd like to ask Linus to pull it ASAP, before v3.14 releases. I think it's correct, but I'd sure appreciate it if an AGP expert could check this out and confirm my belief that the GART

[PATCH] drm/mm: Fix search for smallest hole satisfying constraints

On Tue, Mar 18, 2014 at 09:58:14AM +0900, Michel D?nzer wrote: > From: Michel D?nzer > > entry->size is the size of the node, not the size of the hole after it. > So the code would actually find the hole which can satisfy the > constraints and which is preceded by the smallest node, not the

[PATCHv2 2/8] Doc/DT: Add DT binding documentation for Analog TV Connector

n the connector type. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140318/0fe5f211/attachment-0001.sig>

Intel G41 doesn't see any screens connected after suspend/resume

On Tue, 18 Mar 2014, Nikolay Martynov wrote: > Hi. > >>> >>> I would really appreciate if you could point me on some sort of >>> manual that describes how to properly run [2] on Ubuntu? Should I run >>> the whole kernel or just some modules? Is there any way to build only >>> requires modules?

[PATCHv2 8/8] Doc/DT: Add DT binding documentation for tpd12s015 encoder

Add DT binding documentation for tpd12s015 encoder Signed-off-by: Tomi Valkeinen Reviewed-by: Archit Taneja --- .../devicetree/bindings/video/ti,tpd12s015.txt | 44 ++ 1 file changed, 44 insertions(+) create mode 100644

[PATCHv2 7/8] Doc/DT: Add DT binding documentation for TFP410 encoder

Add DT binding documentation for TFP410 encoder Signed-off-by: Tomi Valkeinen Reviewed-by: Archit Taneja --- .../devicetree/bindings/video/ti,tfp410.txt| 41 ++ 1 file changed, 41 insertions(+) create mode 100644

[PATCHv2 6/8] Doc/DT: Add DT binding documentation for Sony acx565akm panel

Add DT binding documentation for Sony acx565akm panel Signed-off-by: Tomi Valkeinen Reviewed-by: Sebastian Reichel Reviewed-by: Archit Taneja --- .../devicetree/bindings/video/sony,acx565akm.txt | 30 ++ 1 file changed, 30 insertions(+) create mode 100644

[PATCHv2 5/8] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel

Add DT binding documentation for MIPI DSI Command Mode Panel. Signed-off-by: Tomi Valkeinen Reviewed-by: Archit Taneja --- .../devicetree/bindings/video/panel-dsi-cm.txt | 29 ++ 1 file changed, 29 insertions(+) create mode 100644

[PATCHv2 4/8] Doc/DT: Add DT binding documentation for HDMI Connector

Add DT binding documentation for HDMI Connector. Signed-off-by: Tomi Valkeinen Reviewed-by: Archit Taneja --- .../devicetree/bindings/video/hdmi-connector.txt | 28 ++ 1 file changed, 28 insertions(+) create mode 100644

[PATCHv2 3/8] Doc/DT: Add DT binding documentation for DVI Connector

Add DT binding documentation for DVI Connector. Signed-off-by: Tomi Valkeinen Reviewed-by: Archit Taneja --- .../devicetree/bindings/video/dvi-connector.txt| 35 ++ 1 file changed, 35 insertions(+) create mode 100644

[PATCHv2 2/8] Doc/DT: Add DT binding documentation for Analog TV Connector

Add DT binding documentation for Analog TV Connector. Signed-off-by: Tomi Valkeinen Reviewed-by: Archit Taneja --- .../bindings/video/analog-tv-connector.txt | 25 ++ 1 file changed, 25 insertions(+) create mode 100644

[PATCHv2 1/8] Doc/DT: Add DT binding documentation for OMAP DSS

Add device tree bindings for OMAP Display Subsystem for the following SoCs: OMAP2, OMAP3, OMAP4. Signed-off-by: Tomi Valkeinen Reviewed-by: Archit Taneja --- .../devicetree/bindings/video/ti,omap-dss.txt | 211 + .../devicetree/bindings/video/ti,omap2-dss.txt | 54

[PATCHv2 0/8] Doc/DT: DT bindings for various display components

Hi, This is v2 of the series adding DT bindings for various display components. The v1 can be found from [1]. The changes for v2: * abbreviated endpoint format dropped (nacked) * MIPI DPI panel dropped (missing backlight handling, delayed to 3.16) * dvi-connector: add properties for

[PATCH] drm/mm: Fix search for smallest hole satisfying constraints

From: Michel D?nzer entry->size is the size of the node, not the size of the hole after it. So the code would actually find the hole which can satisfy the constraints and which is preceded by the smallest node, not the smallest hole satisfying the constraints.

[PATCH 2/3] drm/radeon: use the new drm helpers for dp aux

On Tue, 18 Mar 2014, Alex Deucher wrote: > Switch to the new dp helpers. The main difference is > that the DP helpers don't allow an adjustable delay in > the aux transaction, but I don't know that this is > necessary. This is related to my comment on patch 1. We should probably work to make

[PATCH 1/3] drm/dp: make aux retries less chatty

On Tue, 18 Mar 2014, Alex Deucher wrote: > Switch to debug only to avoid flooding the logs. > This mirrors the behavior in some other drivers. I'd rather think we should find out why the DP devices are replying with repeated native or i2c-over-aux defers. This doesn't help; I'm not in favour.

[PATCHv2 4/8] Doc/DT: Add DT binding documentation for HDMI Connector

Hi Tomi, Am Dienstag, den 18.03.2014, 10:15 +0200 schrieb Tomi Valkeinen: > Add DT binding documentation for HDMI Connector. > > Signed-off-by: Tomi Valkeinen > Reviewed-by: Archit Taneja > --- > .../devicetree/bindings/video/hdmi-connector.txt | 28 > ++ > 1 file

[PATCHv2 2/8] Doc/DT: Add DT binding documentation for Analog TV Connector

Hi Tomi, On Tue, Mar 18, 2014 at 9:15 AM, Tomi Valkeinen wrote: > --- /dev/null > +++ b/Documentation/devicetree/bindings/video/analog-tv-connector.txt > @@ -0,0 +1,25 @@ > +Analog TV Connector > +=== > + > +Required properties: > +- compatible: "composite-connector" or

[PATCH 07/12] drm: drm_display_mode: add signal polarity flags

On Tue, Mar 18, 2014 at 08:50:30AM +0100, Lothar Wa?mann wrote: > Hi, > > Laurent Pinchart wrote: > > Hi Lothar, > > > > On Monday 17 March 2014 16:14:36 Lothar Wa?mann wrote: > > > DE is not a clock signal, but an 'Enable' signal whose value (high or > > > low) defines the window in which the

How to support various hardware blocks in drm driver

On Tue, Mar 18, 2014 at 8:58 AM, Inki Dae wrote: > 2014-03-18 21:47 GMT+09:00 Daniel Vetter : >> On Tue, Mar 18, 2014 at 1:42 PM, Inki Dae wrote: >>> I think now drm_bridge couldn't do what we want for embedded systems >>> as long as drm_encoder has drm_bridge. >>> See the blow hardware

[PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel

dpi bindings from my series, and the backlight for panel-dpi can then be fixed for 3.16. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140318/ed0d92a9/attachment-0001.sig>

How to support various hardware blocks in drm driver

On Tue, Mar 18, 2014 at 4:26 AM, Inki Dae wrote: > > enum { > DRM_HW_BLOCK_PANEL, > DRM_HW_BLOCK_BRIDGE, > DRM_HW_BLOCK_ENHANCE, > }; > > struct drm_hw_block { > unsigned int type; > struct device *dev; just fyi, drop the 'struct device' ptr.. that sort of

[PATCH 07/12] drm: drm_display_mode: add signal polarity flags

Hi, Laurent Pinchart wrote: > Hi Lothar, > > On Monday 17 March 2014 16:14:36 Lothar Wa?mann wrote: > > Laurent Pinchart wrote: > > > On Monday 17 March 2014 14:41:09 Andrzej Hajda wrote: > > > > On 03/13/2014 06:17 PM, Denis Carikli wrote: > > > > > We need a way to pass signal polarity

[PATCH 5/9] Doc/DT: Add DT binding documentation for MIPI DPI Panel

me: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140318/85ddaef8/attachment-0001.sig>

[PATCH 6/9] Doc/DT: Add DT binding documentation for MIPI DSI CM Panel

e you really have multiple gpios with the same purpose? The gpio binding documentation doesn't give much guidance on this. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140318/d3f51e70/attachment-0001.sig>

How to support various hardware blocks in drm driver

On Tue, Mar 18, 2014 at 6:27 AM, Daniel Vetter wrote: > On Tue, Mar 18, 2014 at 05:26:42PM +0900, Inki Dae wrote: >> Hello all, >> >> The purpose of this email is for discussion to how we could support >> various hardware blocks such as LVDS bridges, Image Enhancement chips >> and parallel panels

  1   2   >