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 chip-MI
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 t
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 sufferin
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
t worked 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.freedesk
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 parall
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140318/3d77fc90/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140318/950644df/attachment-0001.html>
> 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
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 hardwa
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 boot
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 devic
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 f661469..3
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 commo
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: Mat
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 ++-
drivers/gpu/drm/i9
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
intel_disab
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 +++-
drivers/gpu/drm/drm_ioctl.
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
i
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 the
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 ++
drivers/gpu/drm/msm/mdp/mdp4/m
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
---
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 object IDs and property IDs and their
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 +-
drivers/gpu/drm/drm_
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
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 +
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 thei
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 c
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 t
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
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
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 -
drivers/gpu/drm/drm_
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 ++---
1 file changed, 14 insertio
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 a/drivers/gpu/drm/i915/i9
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 Syrj?l?
---
drivers/gpu/drm/drm_crt
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
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 mut
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 a/drivers/gpu/drm/drm_
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 a/drivers/gpu/drm/drm_c
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
in
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 to
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, value);
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
+++ b/drivers/gpu/drm/drm
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
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 inse
cause:
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>
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 as
fonts look 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>
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 6ca605f7c70895a35737435f1
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
>>> > in
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
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]: http://permalink.gma
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:
> > > > > >
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 DRM_MODE_FLAG_POL_DE_(L
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 spec
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 7-
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: I452e944
e 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/577e72e6/attachment.html>
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 a
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
>
>
t; The gpio binding documentation doesn't give 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>
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 wrote:
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. This
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140318/2c066249/attachment.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140318/f32f1482/attachment.html>
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
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 arose
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 sampl
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 plane->set_p
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 wan
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140318/41103737/attachment-0001.html>
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 ide
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 contr
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, an
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 apertur
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 small
to specify than 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>
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?
>
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 Documentation/devicetree/bindings/video/ti,tpd12s0
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 Documentation/devicetree/bindings/video/ti,tfp410.txt
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 Documentation/d
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 Documentation/devicetree/bindings/video
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 Documentation/devicetree/bindings/video/hdmi-connect
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 Documentation/devicetree/bindings/video/dvi-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
Documentation/devicetree/bindings/video/analog
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
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 analog/digit
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.
Reported-by: "Huang, FrankR"
Signe
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 the
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.
BR
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 change
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 "svideo-c
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 pi
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 pipeline,
So I'll
drop 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>
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
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 informat
bbed...
Name: 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>
ng except
the case where 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>
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 - 100 of 119 matches
Mail list logo
