Write more complete kerneldoc comments for the DRM panel API and
integrate the helpers in the DRM DocBook reference.
Signed-off-by: Thierry Reding
---
Documentation/DocBook/gpu.tmpl | 12 ++---
drivers/gpu/drm/drm_panel.c| 61 ++
include/drm/drm_pa
ecause:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141104/cf72633b/attachment.html>
On 11/03/2014 06:27 PM, Thierry Reding wrote:
> From: Thierry Reding
>
> When the CRTC is enabled, make sure the VBLANK machinery is enabled.
> Failure to do so will cause drm_vblank_get() to not enable the VBLANK on
> the CRTC and VBLANK-synchronized page-flips won't work.
>
> While at it, get ri
On Monday 03 November 2014 01:58 PM, Daniel Vetter wrote:
> On Mon, Nov 3, 2014 at 9:25 AM, Thierry Reding wrote:
>>> The idea is that you'd grab the DPCD field anyway since it's needed all
>>> over the place. We have a pile of helpers already that take exactly this
>>> block and decode parts of
Using %pf, __builtin_return_address(0) instead ofy
"%s", __func__ reduces code size by eliminating
a function argument.
(allyesconfig)
$ size drivers/gpu/drm/built-in.o*
textdata bss dec hex filename
4656061 1321947 1669536 7647544 74b138 drivers/gpu/drm/built-in.o.new
4737680
On Mon, Nov 03, 2014 at 03:41:32PM -0800, Matt Roper wrote:
> On Sun, Nov 02, 2014 at 02:19:19PM +0100, Daniel Vetter wrote:
> ...
> > +/**
> > + * drm_atomic_get_plane_state - get plane state
> > + * @state: global atomic state object
> > + * @plane: plane to get state object for
> > + *
> > + * T
On Mon, Nov 03, 2014 at 08:51:45PM -0500, Peter Hurley wrote:
> A connector may be forced on from the command line via video=
> command line setting. The digital output of dual-mode connectors
> can also be specifically selected and forced on; eg., 'video=DVI-I-2:D'.
> However, in this case, the co
On 01.11.2014 03:10, Alex Deucher wrote:
> On Thu, Oct 30, 2014 at 4:36 AM, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> In the words of Daniel Vetter:
>>
>> «I think SEARCH_BEST is pretty much always a bad idea - it rips apart
>> allocations from the same execbuf, and usually those get r
On Mon, Nov 03, 2014 at 08:53:41PM -0500, Peter Hurley wrote:
> modeset->num_connectors must be 0 to reach the BUG_ON() which tests
> for non-zero modeset->num_connectors; remove BUG_ON().
>
> Signed-off-by: Peter Hurley
Also picked up into topic/core-stuff. I'll probably send the pull for that
On Tue, Nov 04, 2014 at 12:03:46AM -0800, Joe Perches wrote:
> Using %pf, __builtin_return_address(0) instead ofy
> "%s", __func__ reduces code size by eliminating
> a function argument.
>
> (allyesconfig)
> $ size drivers/gpu/drm/built-in.o*
>text data bss dec hex filena
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/20141104/2b5fabf9/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141104/04fb1024/attachment.html>
inated with error (1). Closing log file.
**
The logs I get trying to start gdm is in the attachment.
--
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/20141104/79271c1a/attachment-0001.html>
Hi Russell,
Am Montag, den 27.10.2014, 23:57 + schrieb Russell King - ARM Linux:
> On Mon, Oct 27, 2014 at 11:26:30PM +0100, Daniel Vetter wrote:
> > Looking at the of_drm_find_panel function I actually wonder how that
> > works - the drm_panel doesn't really need to stick around afaics.
> > A
||lockup
--
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/20141104/d2175f9c/attachment.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141104/4769bec8/attachment.html>
||w_bug.cgi?id=525538
--
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/20141104/7ca3f
Hi,
Am Montag, den 03.11.2014, 10:59 -0800 schrieb Steve Longerbeam:
> On 11/03/2014 09:48 AM, Greg KH wrote:
> > On Mon, Nov 03, 2014 at 06:17:28PM +0100, Daniel Vetter wrote:
> >> On Mon, Nov 03, 2014 at 08:14:23AM -0800, Greg KH wrote:
> >>> On Mon, Nov 03, 2014 at 05:12:14PM +0100, Daniel Vett
Add myself as maintainer for the IPUv3 core driver.
Signed-off-by: Philipp Zabel
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 34d3671..1c48287 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3917,6 +3917,13 @@ S: Maintained
F:
On 11/03/2014 10:13 AM, Thierry Reding wrote:
> From: Thierry Reding
>
> This panel requires dual-channel mode. The device accepts command-mode
> data on 8 lanes and will therefore need a dual-channel DSI controller.
> The two interfaces that make up this device need to be instantiated in
> the c
Add myself as the maintainer of the i.MX DRM driver.
Signed-off-by: Philipp Zabel
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index df2aecf..ddf191d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3183,6 +3183,13 @@ F: drivers/gpu/drm
Linux already includes a copy of the GPL, checkpatch compains about the address.
Remove it from the license text.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/imx-ldb.c | 5 -
drivers/staging/imx-drm/imx-tve.c | 5 -
drivers/staging/imx-drm/ipuv3-crtc.c
The imx-drm driver was put into staging mostly for the following reasons,
all of which have been addressed or superseded:
- convert the irq driver to use linear irq domains
- work out the device tree bindings, this lead to the common of_graph
bindings being used
- factor out common helper fun
Hi Thierry,
Just passing by.
On 11/03/2014 10:27 AM, Thierry Reding wrote:
> From: Thierry Reding
>
> The HDMI hotplug signal may toggle after the DRM driver has been
> unloaded. Make sure not to call into DRM if that's the case.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/tegr
Am Dienstag, den 04.11.2014, 11:52 +0100 schrieb Philipp Zabel:
> The imx-drm driver was put into staging mostly for the following reasons,
> all of which have been addressed or superseded:
> - convert the irq driver to use linear irq domains
> - work out the device tree bindings, this lead to th
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141104/ecc72932/attachment-0001.html>
his mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141104/a75cd58b/attachment.html>
On 11/03/2014 10:13 AM, Thierry Reding wrote:
> From: Thierry Reding
>
> This commit introduces a new function, mipi_dsi_create_packet(), which
> converts from a MIPI DSI message to a MIPI DSI packet. The MIPI DSI
> packet is as close to the protocol described in the DSI specification as
> possibl
On 11/03/2014 10:13 AM, Thierry Reding wrote:
> From: Thierry Reding
>
> A common pattern is starting to emerge for higher level transfer
> helpers. Create a new helper that encapsulates this pattern and avoids
> code duplication.
>
> Signed-off-by: Thierry Reding
Acked-by: Andrzej Hajda
--
Rega
On Tue, Nov 4, 2014 at 6:28 PM, Philipp Zabel wrote:
> Add myself as maintainer for the IPUv3 core driver.
>
> Signed-off-by: Philipp Zabel
Acked-by: Shawn Guo
> ---
> MAINTAINERS | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 34d3671..1c4828
On Tue, Nov 4, 2014 at 6:52 PM, Philipp Zabel wrote:
> Add myself as the maintainer of the i.MX DRM driver.
>
> Signed-off-by: Philipp Zabel
Acked-by: Shawn Guo
> ---
> MAINTAINERS | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index df2aecf..ddf19
--
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/20141104/e82f6373/attachment-0001.sig>
to
the kernel so we can seamlessly transition graphics. If we pulse reset
for any of the blocks we can no longer do that.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not availab
of dsi->panel_node and dsi->panel with drm synchronization via
> drm_helper_hpd_irq_event.
There are a number of ways that one could possibly implement this. I do
not think any of the existing ones is as good as it could be and I think
we really ought to standardize on how to do this to make it easier for
other drivers to adapt DRM panels (and bridges for that matter).
Unfortunately before we have a good plan on how to handle panels more
uniformly I don't see how we can possibly make everybody happy. It seems
like currently whatever panel is written for Exynos isn't going to work
on Tegra and vice-versa. So how about we merge this series and I'll look
into how we can unify things?
I'd appreciate any ideas on how such a unification could look.
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/20141104/6a4b42f9/attachment.sig>
> It might be worth moving that logic into mipi_dsi_dcs_read, assuming
> we're not interested in partial data.
Agreed. I think we can leave that for a subsequent refactoring once
these function have matured a bit more and patterns appear.
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/20141104/2ca6f5ab/attachment.sig>
acket {
> > + size_t size;
> > + u8 header[4];
>
> I wonder if it wouldn't be good to make it u32 or at least anonymous union:
> union {
> u8 header[4];
> u32 header32;
> };
I'm not sure this is very useful. It's pretty trivial how you
concatenate the individual bytes and it actually remove any ambiguity
about the endianness.
> And of course we should document its endiannes.
The endianness is already documented in the kerneldoc, isn't it? Data ID
followed by Word Count (long packets) or Packet Data (short packets) and
finally the ECC byte. That's the ordering defined in the specification,
so I think it's fairly obvious.
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/20141104/6158d54c/attachment-0001.sig>
> before modeset, and it's unclear to me whether the vblank counter will
> be reset in prepare.
Done. Thanks,
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/20141104/9650b2f1/attachment.sig>
On 11/04/2014 02:58 PM, Thierry Reding wrote:
> On Tue, Nov 04, 2014 at 12:43:21PM +0100, Andrzej Hajda wrote:
>> On 11/03/2014 10:13 AM, Thierry Reding wrote:
>>> From: Thierry Reding
>>>
>>> This commit introduces a new function, mipi_dsi_create_packet(), which
>>> converts from a MIPI DSI messa
On Tue, Nov 04, 2014 at 09:33:10PM +0800, Andy Yan wrote:
> From: Andy yan
>
> We found freescale imx6 and rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS)
> use the interface compatible Designware HDMI IP, but they also have some
> lightly difference, such as phy pll configuration, register widt
On Tue, Nov 4, 2014 at 3:47 AM, Michel Dänzer wrote:
> On 01.11.2014 03:10, Alex Deucher wrote:
>>
>> On Thu, Oct 30, 2014 at 4:36 AM, Michel Dänzer
>> wrote:
>>>
>>> From: Michel Dänzer
>>>
>>> In the words of Daniel Vetter:
>>>
>>> «I think SEARCH_BEST is pretty much always a bad idea - i
>> u8 header[4];
> >> u32 header32;
> >> };
> > I'm not sure this is very useful. It's pretty trivial how you
> > concatenate the individual bytes and it actually remove any ambiguity
> > about the endianness.
>
> This looks better:
>
> val = le16_to_cpu(pkt->header32);
> writel(val, REG);
>
> than this:
>
> val = pkt->header[2] << 16 | pkt->header[1] << 8 | pkt->header[0];
> writel(val, REG);
I disagree. =) Having the individual bytes makes their ordering very
explicit.
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/20141104/8660fe9b/attachment.sig>
problem that patch fixes, but
I'll give it some testing to see if it doesn't break anything.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://li
On Tue, Nov 4, 2014 at 9:50 AM, Thierry Reding
wrote:
> On Mon, Nov 03, 2014 at 12:18:30PM -0500, Sean Paul wrote:
>> On Mon, Nov 3, 2014 at 4:27 AM, Thierry Reding
>> wrote:
>> > From: Thierry Reding
>> >
>> > The output is already enabled in .dpms(), doing it in .mode_set() too
>> > can caus
Hi Steve,
On Mon, Nov 3, 2014 at 8:41 PM, Steve Longerbeam
wrote:
> Hi Fabio, which panel? The Hannstar or the 1024x600 Okaya 7"
> panel?
I am using the Hannstar.
>
> I have noticed wrong colors using the Okaya panel as well, and it
> is fixed by switching to "jeida" 24-bit interface in the DT
On Tue, 2014-11-04 at 09:52 +0100, Daniel Vetter wrote:
> On Tue, Nov 04, 2014 at 12:03:46AM -0800, Joe Perches wrote:
> > Using %pf, __builtin_return_address(0) instead ofy
> > "%s", __func__ reduces code size by eliminating
> > a function argument.
[]
> I have an earlier version from you of this
rfect sense. It's somewhat unfortunate that the helpers even
allow this to happen. It doesn't seem like it's only the Tegra driver
using it wrongly. Anyway, I've applied this to my tree.
Thanks,
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/20141104/6b5289f1/attachment.sig>
> >
> > dsi->output.dev = dsi->dev = &pdev->dev;
> > + dsi->video_fifo_depth = 1920;
>
> This is not functionally equivalent to what was previously being set
> (1920/4). Perhaps calling that out in the commit message might be
> appropriate?
Done.
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/20141104/dcaea4bc/attachment.sig>
hierry
-- 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/20141104/3223282e/attachment-0001.sig>
On Tue, Nov 04, 2014 at 09:39:58PM +0800, Andy Yan wrote:
> From: Andy yan
>
> the original imx hdmi driver is under staging/imx-drm,
> which depends on imx-drm, so move the imx hdmi drvier out
> to drm/bridge and rename imx-hdmi to dw-hdmi
>
> Change-Id: I5f417372f256aa26cd00a3cd0160741680afd39
on top:
- drm_framebuffer_unreference(&fbdev->fb->base);
+ drm_framebuffer_remove(&fbdev->fb->base);
?
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/20141104/8a9bfc0b/attachment.sig>
Hi Philipp,
Just a flyby question
On 04/11/14 10:52, Philipp Zabel wrote:
> The imx-drm driver was put into staging mostly for the following reasons,
> all of which have been addressed or superseded:
> - convert the irq driver to use linear irq domains
> - work out the device tree bindings, thi
From: Thierry Reding
Write more complete kerneldoc comments for the DRM panel API and
integrate the helpers in the DRM DocBook reference.
Signed-off-by: Thierry Reding
---
Documentation/DocBook/drm.tmpl | 6 +
drivers/gpu/drm/drm_panel.c| 61 ++
From: Thierry Reding
Add a generic implementation of an object registry. This targets drivers
and subsystems that provide auxiliary objects that other drivers need to
look up. The goal is to put the difficult parts (keep object references,
module usage count, ...) into core code so that individua
From: Thierry Reding
Convert to the new generic object registry and introduce proper object
and module reference counting. This should make panel registration and
removal a lot more robust.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_panel.c | 100 ++--
On Tue, Nov 04, 2014 at 04:26:12PM +0100, Thierry Reding wrote:
> On Tue, Nov 04, 2014 at 10:11:22AM -0500, Sean Paul wrote:
> > On Tue, Nov 4, 2014 at 9:50 AM, Thierry Reding > gmail.com> wrote:
> > > On Mon, Nov 03, 2014 at 12:18:30PM -0500, Sean Paul wrote:
> > >> On Mon, Nov 3, 2014 at 4:27 AM
On Tue, Nov 04, 2014 at 05:29:27PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Add a generic implementation of an object registry. This targets drivers
> and subsystems that provide auxiliary objects that other drivers need to
> look up. The goal is to put the difficult parts (keep ob
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141104/cfc1a188/attachment.html>
Am Dienstag, den 04.11.2014, 16:19 + schrieb Emil Velikov:
> Hi Philipp,
>
> Just a flyby question
>
> On 04/11/14 10:52, Philipp Zabel wrote:
> > The imx-drm driver was put into staging mostly for the following reasons,
> > all of which have been addressed or superseded:
> > - convert the i
https://bugzilla.kernel.org/show_bug.cgi?id=80851
--- Comment #1 from swoorupj at gmail.com ---
Update,
I tried doing a git-bisect today. I only tried out kernel 3.18 rc3 which was
bad and had the same issue, and then I directly checkout kernel back to 3.8 in
which the issue was still occuring.
https://bugzilla.kernel.org/show_bug.cgi?id=80851
swoorupj at gmail.com changed:
What|Removed |Added
Kernel Version|3.15.6 |3.18-rc3
Regression|No
Hi Steve,
Am Freitag, den 31.10.2014, 15:54 -0700 schrieb Steve Longerbeam:
> Some cm_reg accesses were not being protected by the IPU spin lock.
>
> Signed-off-by: Steve Longerbeam
> ---
> drivers/gpu/ipu-v3/ipu-common.c | 22 --
> 1 file changed, 20 insertions(+), 2 delet
Am Freitag, den 31.10.2014, 15:54 -0700 schrieb Steve Longerbeam:
> Add support for reading EDID over Display Data Channel. If no DDC
> adapter is available, falls back to hardcoded EDID or display-timings
> node as before.
>
> Signed-off-by: Steve Longerbeam
Acked-by: Philipp Zabel
regards
Ph
Am Freitag, den 31.10.2014, 15:54 -0700 schrieb Steve Longerbeam:
> If a ddc node was specified in the device tree, use it in
> imx_ldb_connector_detect() to probe the ddc with drm_probe_ddc(), if
> the result is success, we know there is a display connected so return
> connected status. Otherwise
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/20141104/f87b8e69/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141104/80ffbe5d/attachment.html>
On Sun, Nov 02, 2014 at 02:19:19PM +0100, Daniel Vetter wrote:
> Some differences compared to Rob's patches again:
> - Dropped the committed and checked booleans. Checking will be
> internally enforced by always calling ->atomic_check before
> ->atomic_commit. And async handling needs to be sol
On Sun, Nov 02, 2014 at 02:19:14PM +0100, Daniel Vetter wrote:
> Just a bit of OCD cleanup on headers - this function isn't the core
> interface any more but just a helper for drivers who haven't yet
> transitioned to universal planes. Put the declaration at the right
> spot and sprinkle necessary
On Sun, Nov 02, 2014 at 02:19:17PM +0100, Daniel Vetter wrote:
> I've forgotten to do this in:
>
> commit cb597bb3a2fbfc871cc1c703fb330d247bd21394
> Author: Daniel Vetter
> Date: Sun Jul 27 19:09:33 2014 +0200
>
> drm: trylock modest locking for fbdev panics
>
> Oops, fix this asap.
>
> In m
On Sun, Nov 02, 2014 at 02:19:18PM +0100, Daniel Vetter wrote:
> Heavily based upon Rob Clark's atomic series.
> - Dropped the connctor state from the crtc state, instead opting for a
nit: s/connctor/connector/
> full-blown connector state. The only thing it has is the desired
> crtc, but dri
On Tue, Nov 04, 2014 at 03:31:07PM -0500, Sean Paul wrote:
> On Sun, Nov 02, 2014 at 02:19:19PM +0100, Daniel Vetter wrote:
> > +drm_atomic_set_crtc_for_connector(struct drm_connector_state *conn_state,
> > + struct drm_crtc *crtc)
> > +{
> > + struct drm_crtc_state *crtc_state;
> > +
> > + crtc_s
Some differences compared to Rob's patches again:
- Dropped the committed and checked booleans. Checking will be
internally enforced by always calling ->atomic_check before
->atomic_commit. And async handling needs to be solved differently
because the current scheme completely side-steps ww m
On Tue, Nov 04, 2014 at 10:30:37PM +0100, Daniel Vetter wrote:
> On Tue, Nov 04, 2014 at 03:31:07PM -0500, Sean Paul wrote:
> > On Sun, Nov 02, 2014 at 02:19:19PM +0100, Daniel Vetter wrote:
> > > +drm_atomic_set_crtc_for_connector(struct drm_connector_state *conn_state,
> > > + struct drm_crtc *c
So my original plan was that the drm core refcounts framebuffers like
with the legacy ioctls. But that doesn't work for a bunch of reasons:
- State objects might live longer than until the next fb change
happens for a plane. For example delayed cleanup work only happens
_after_ the pageflip io
Some differences compared to Rob's patches again:
- Dropped the committed and checked booleans. Checking will be
internally enforced by always calling ->atomic_check before
->atomic_commit. And async handling needs to be solved differently
because the current scheme completely side-steps ww m
Well, except page_flip since that requires async commit, which isn't
there yet.
For the functions which changes planes there's a bit of trickery
involved to keep the fb refcounting working. But otherwise fairly
straight-forward atomic updates.
The property setting functions are still a bit incomp
Currently there is no way to implement async flips using atomic, that
essentially requires us to be able to cancel pending requests
mid-flight.
To be able to do that (and I guess we want this since vblank synced
updates whic opportunistically cancel still pending updates seem to be
wanted) we'd ne
On Sun, Nov 2, 2014 at 5:29 PM, Dave Airlie wrote:
> So since -rc5/6 cutoff last merge windows was so successful from my
> POV, I think I'll keep trucking with the idea.
>
> Things I have on my radar for this window, outside normal driver pull
> requests:
>
> a) rockchip drm - this needs IOMMU dr
To address previous feedback, I'll quote below and answer.
>It would be nice if you could cite on the commit message the name of
>the specification and the name of the test(s) that use it.
Done. For reference, in the Displayport Link CTS spec, tests 4.2.2.4 and
4.2.2.5 are the ones that use thes
These counters are used for Displayort compliance testing to detect error
conditions when executing tests 4.2.2.4 and 4.2.2.5 in the Displayport Link
CTS specificaiton. They determine whether to use the preferred/requested
mode or the failsafe mode during these tests.
V2:
- Addressed previous revi
On Tue, Nov 04, 2014 at 03:12:27PM -0700, Todd Previte wrote:
> >Does it really need to be uint8_t? I see on patch 7 that you don't
> >really write this value to a place that only accepts uint8_t-sized
> >arguments, so I fear that if we get 256 NACKs or DEFERs we may end up
> >doing the wrong thing
On Tue, Nov 04, 2014 at 03:17:35PM -0700, Todd Previte wrote:
> These counters are used for Displayort compliance testing to detect error
> conditions when executing tests 4.2.2.4 and 4.2.2.5 in the Displayport Link
> CTS specificaiton. They determine whether to use the preferred/requested
> mode o
uest: 34 ()
Serial number of failed request: 72
Current serial number in output stream: 69
--
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-de
On Sun, Nov 02, 2014 at 02:19:20PM +0100, Daniel Vetter wrote:
> This is the first cut of atomic helper code. As-is it's only useful to
> implement a pure atomic interface for plane updates.
>
> Later patches will integrate this with the crtc helpers so that full
> atomic updates are possible. We a
On Tue, Nov 4, 2014 at 5:07 PM, Daniel Vetter wrote:
> Some differences compared to Rob's patches again:
> - Dropped the committed and checked booleans. Checking will be
> internally enforced by always calling ->atomic_check before
> ->atomic_commit. And async handling needs to be solved diffe
Filippov ---
Linux 3.16.5, Mesa 10.4.0-devel git, the bug still there.
--
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
GPU ...)
--
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/20141104/49ed74d7/attachment.html>
On Tue, Oct 28, 2014 at 7:20 AM, Jani Nikula wrote:
> In the interest of reducing magic numbers and having to cross check with
> the specs all the time.
>
> Signed-off-by: Jani Nikula
> ---
> include/drm/drm_edid.h | 102
> +
> 1 file changed, 102
On 11/04/2014 01:35 AM, Philipp Zabel wrote:
> Hi,
>
> Am Montag, den 03.11.2014, 10:59 -0800 schrieb Steve Longerbeam:
>> On 11/03/2014 09:48 AM, Greg KH wrote:
>>> On Mon, Nov 03, 2014 at 06:17:28PM +0100, Daniel Vetter wrote:
On Mon, Nov 03, 2014 at 08:14:23AM -0800, Greg KH wrote:
> On
On 11/04/2014 09:51 AM, Philipp Zabel wrote:
> Hi Steve,
>
> Am Freitag, den 31.10.2014, 15:54 -0700 schrieb Steve Longerbeam:
>> Some cm_reg accesses were not being protected by the IPU spin lock.
>>
>> Signed-off-by: Steve Longerbeam
>> ---
>> drivers/gpu/ipu-v3/ipu-common.c | 22
On Tue, Nov 4, 2014 at 8:03 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> This stuff is ancient, we have docs now in the kernel,
> lets just drop it.
>
> Pointed out by Glenn
>
> Signed-off-by: Dave Airlie
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/README.drm | 43 ---
Hi,
On 04/11/14 13:39, Andy Yan wrote:
> From: Andy yan
>
> the original imx hdmi driver is under staging/imx-drm,
> which depends on imx-drm, so move the imx hdmi drvier out
> to drm/bridge and rename imx-hdmi to dw-hdmi
>
> Change-Id: I5f417372f256aa26cd00a3cd0160741680afd39d
> ---
> drivers
From: Andy yan
We found freescale imx6 and rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS)
use the interface compatible Designware HDMI IP, but they also have some
lightly difference, such as phy pll configuration, register width(imx hdmi
register is one byte, but rk3288 is 4 bytes width and can
On 11/03/2014 06:13 PM, Kevin Hilman wrote:
> Andrzej Hajda writes:
>
>> On 10/30/2014 08:36 AM, Krzysztof Kozlowski wrote:
>>> On Åro, 2014-10-29 at 10:46 -0700, Kevin Hilman wrote:
Krzysztof Kozlowski writes:
> When resuming the system the power domain has to be powered on early
this patch with the -M option?
git format-patch should then understand its a rename.
Then it should generate a smaller patch that is possible to review easily.
Thanks
ZubairLK
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.free
Hi,
I run 3.18-rc3 kernel on BeagleBone Black. It doesn't have Exynos DRM
of course, but I run multi-platform kernel where CONFIG_DRM_EXYNOS is
set to 'y'.
The issue here is that the platform probe/init goes to infinite loop
as the following:
[5.717343] platform exynos-drm: Driver exynos-drm
imx6 and rockchip rk3288 and JZ4780 (Ingenic Xburst/MIPS)
use the interface compatible Designware HDMI IP, but they
also have some lightly difference, such as phy pll configuration,
register width(imx hdmi register is one byte, but rk3288 is 4
bytes width), 4K support(imx6 doesn't support 4k, but r
Hi Andy,
On 04/11/14 13:33, Andy Yan wrote:
> imx6 and rockchip rk3288 and JZ4780 (Ingenic Xburst/MIPS)
> use the interface compatible Designware HDMI IP, but they
> also have some lightly difference, such as phy pll configuration,
> register width(imx hdmi register is one byte, but rk3288 is 4
>
On 11/04/2014 09:51 AM, Philipp Zabel wrote:
> Hi Steve,
>
> Am Freitag, den 31.10.2014, 15:54 -0700 schrieb Steve Longerbeam:
>> Some cm_reg accesses were not being protected by the IPU spin lock.
>>
>> Signed-off-by: Steve Longerbeam
>> ---
>> drivers/gpu/ipu-v3/ipu-common.c | 22
From: Andy yan
the original imx hdmi driver is under staging/imx-drm,
which depends on imx-drm, so move the imx hdmi drvier out
to drm/bridge and rename imx-hdmi to dw-hdmi
Change-Id: I5f417372f256aa26cd00a3cd0160741680afd39d
---
drivers/gpu/drm/bridge/Kconfig|5 +
drivers/gpu/drm/b
99 matches
Mail list logo
