Hi Ajay,
On 19 March 2014 19:52, Ajay Kumar wrote:
> Add post processor ops for MDNIE and their support functions.
> Expose an interface for the FIMD to register MDNIE PP.
>
> Signed-off-by: Ajay Kumar
> Signed-off-by: Shirish S
> Signed-off-by: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/Mak
On Wed, Mar 19, 2014 at 7:51 PM, Daniel Vetter wrote:
> On Tue, Mar 18, 2014 at 05:22:49PM -0700, Matt Roper wrote:
>> 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 &
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/20140319/542bd7e7/attachment.html>
On Wed, Mar 19, 2014 at 12:06 PM, David Herrmann
wrote:
>
> Unlike existing techniques that provide similar protection, sealing allows
> file-sharing without any trust-relationship. This is enforced by rejecting
> seal
> modifications if you don't own an exclusive reference to the given file.
I
On Wed, Mar 19, 2014 at 10:26:13PM +0800, Daniel Kurtz wrote:
> On Wed, Mar 19, 2014 at 7:51 PM, Daniel Vetter wrote:
> > On Tue, Mar 18, 2014 at 05:22:49PM -0700, Matt Roper wrote:
> >> Before we add additional types of planes to the DRM plane list, ensure
> >> that existing loops over all planes
On Wed, Mar 19, 2014 at 11:15:36AM -0700, Matt Roper wrote:
> On Wed, Mar 19, 2014 at 12:28:43PM +0100, Daniel Vetter wrote:
> > On Tue, Mar 18, 2014 at 05:22:48PM -0700, Matt Roper wrote:
> ...
> > > +
> > > + /*
> > > + * set_config() adjusts crtc->primary->fb; however the DRM setplane
> > > +
vel/attachments/20140319/5e74aff3/attachment-0001.html>
Hi
>
> Perhaps you failed to install the modules that go with the kernel?
I've built today's git version. The system boots but short after I
log into X session system freezes.
I can login via ssh and see dmesg:
[ 58.699131] general protection fault: [#1] SMP
[ 58.699173] Modules lin
The memfd_create() syscall creates anonymous files similar to O_TMPFILE
but does not require an active mount-point.
Signed-off-by: David Herrmann
---
man2/memfd_create.2 | 110
1 file changed, 110 insertions(+)
create mode 100644 man2/memfd_c
The SHMEM_GET_SEALS and SHMEM_SET_SEALS commands allow retrieving and
modifying the active set of seals on a file. They're only supported on
selected file-systems (currently shmfs) and are linux-only.
Signed-off-by: David Herrmann
---
man2/fcntl.2 | 90 +++
Some basic tests to verify sealing on memfds works as expected and
guarantees the advertised semantics.
Signed-off-by: David Herrmann
---
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/memfd/.gitignore | 2 +
tools/testing/selftests/memfd/Makefile | 29 +
to
memfd_create() is similar to mmap(MAP_ANON), but returns a file-descriptor
that you can pass to mmap(). It explicitly allows sealing and
avoids any connection to user-visible mount-points. Thus, it's not
subject to quotas on mounted file-systems, but can be used like
malloc()'ed memory, but with a
If two processes share a common memory region, they usually want some
guarantees to allow safe access. This often includes:
- one side cannot overwrite data while the other reads it
- one side cannot shrink the buffer while the other accesses it
- one side cannot grow the buffer beyond previo
VM_DENYWRITE currently relies on i_writecount. Unless there's an active
writable reference to an inode, VM_DENYWRITE is not allowed.
Unfortunately, alloc_file() does not increase i_writecount, therefore,
does not prevent a following VM_DENYWRITE even though the new file might
have been opened with
Hi
This series introduces the concept of "file sealing". Sealing a file restricts
the set of allowed operations on the file in question. Multiple seals are
defined and each seal will cause a different set of operations to return EPERM
if it is set. The following seals are introduced:
* SEAL_SHRI
On Wed, Mar 19, 2014 at 08:06:45PM +0100, David Herrmann wrote:
> Hi
>
> This series introduces the concept of "file sealing". Sealing a file restricts
> the set of allowed operations on the file in question. Multiple seals are
> defined and each seal will cause a different set of operations to re
This patch adds code to add MDNIE and IELCD onto the
list of FIMD PP.
Signed-off-by: Ajay Kumar
Signed-off-by: Shirish S
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 17 +
drivers/gpu/drm/exynos/exynos_fimd_pp.h | 2 ++
2 files changed, 19 insert
Add post processor ops for IELCD and their support functions.
Expose an interface for the FIMD to register IELCD PP.
Signed-off-by: Ajay Kumar
Signed-off-by: Shirish S
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/Makefile | 3 +-
drivers/gpu/drm/exynos/exynos_ielcd.c | 295 ++
Add post processor ops for MDNIE and their support functions.
Expose an interface for the FIMD to register MDNIE PP.
Signed-off-by: Ajay Kumar
Signed-off-by: Shirish S
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/Makefile| 2 +-
drivers/gpu/drm/exynos/exynos_mdnie.c
Exynos variants support post pocessors(PP) for FIMD (MDNIE and IELCD)
which work closely with fimd. These post processors have strict
dependency on FIMD for poweron/poweroff. This patch adds an
infrastructure in FIMD driver to accomodate such devices.
Added structure definition for FIMD PP and int
This series is based on exynos-drm-next-todo branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
On Exynos SOC, FIMD supports various post processors
like MIE, MDNIE and IELCD for image enhancement purposes.
This patchset adds an infrastructure in exy
On Mon, 17 Mar 2014 15:49:10 +0100, Jean Delvare wrote:
> It was only ever used by the ACPI video driver, and that only use case
> vanished over 3 years ago (see commit 677bd810, "ACPI video: remove
> output switching control".) So this is dead code and I guess we can
> remove it now.
>
> Signed-o
Hi Russell,
(CC'ing Philipp Zabel who might be able to provide feedback as a user of the
component framework)
Could you please have a look at the questions below and provide an answer when
you'll have time ? I'd like to bridge the gap between the component and the
V4L2 asynchronous registratio
On Die, 2014-03-18 at 11:01 +0100, Daniel Vetter wrote:
> 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
> > c
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 Wed, Mar 19, 2014 at 06:22:14PM +0100, Laurent Pinchart wrote:
> Hi Russell,
>
> (CC'ing Philipp Zabel who might be able to provide feedback as a user of the
> component framework)
>
> Could you please have a look at the questions below and provide an answer
> when
> you'll have time ? I'd
Applied.
Thanks,
Inki Dae
2014-03-13 14:28 GMT+09:00 Shirish S :
> 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
2014-03-18 22:04 GMT+09:00 Tomasz Figa :
> 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 standar
This patch integrates existing drm_panel and drm_bridge frameworks
to one integrated framework, drm_hw_block.
For this, I had already sent a email to make a discussion[1] about
how we could support all bridges, one bridge between crtc and encoder,
and another bridge between encoder and panel.
Now
-
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140319/24001900/attachment.sig>
This patch integrates existing drm_panel and drm_bridge frameworks
to one integrated framework, drm_hw_block.
For this, I had already sent a email to make a discussion[1] about
how we could support all bridges, one bridge between crtc and encoder,
and another bridge between encoder and panel.
Now
On Wed, 19 Mar 2014, Alex Deucher wrote:
> On Tue, Mar 18, 2014 at 3:44 AM, Jani Nikula
> wrote:
>> 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
On Wed, Mar 19, 2014 at 01:24:23PM +0100, Daniel Vetter wrote:
> On Tue, Mar 18, 2014 at 05:22:48PM -0700, Matt Roper wrote:
> > 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 op
On Wed, Mar 19, 2014 at 01:11:26PM +0100, Daniel Vetter wrote:
> On Tue, Mar 18, 2014 at 05:22:56PM -0700, Matt Roper wrote:
> > Intel hardware allows the primary plane to be disabled independently of
> > the CRTC. Provide custom primary plane handling to allow this.
> >
> > Cc: Intel Graphics De
On Tue, Mar 18, 2014 at 05:22:54PM -0700, Matt Roper wrote:
> 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
I don't see any
At Wed, 19 Mar 2014 15:17:50 +0100,
Daniel Vetter wrote:
>
> On Wed, Mar 19, 2014 at 02:53:13PM +0100, Takashi Iwai wrote:
> > Currently drm_pick_cmdline_mode() doesn't care about the interlace
> > when the given mode line has no "i" suffix. That is, when there are
> > multiple entries for the sa
On Wed, Mar 19, 2014 at 02:53:13PM +0100, Takashi Iwai wrote:
> Currently drm_pick_cmdline_mode() doesn't care about the interlace
> when the given mode line has no "i" suffix. That is, when there are
> multiple entries for the same resolution, an interlace mode might be
> picked up just depending
On Wed, Mar 19, 2014 at 09:42:44AM -0400, Alex Deucher wrote:
> On Tue, Mar 18, 2014 at 3:44 AM, Jani Nikula
> wrote:
> > 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 w
Currently drm_pick_cmdline_mode() doesn't care about the interlace
when the given mode line has no "i" suffix. That is, when there are
multiple entries for the same resolution, an interlace mode might be
picked up just depending on the assigned order, and there is no way to
exclude it.
This patch
On Wed, Mar 19, 2014 at 08:23:31AM -0400, Rob Clark wrote:
> On Wed, Mar 19, 2014 at 7:07 AM, Daniel Vetter wrote:
> > On Tue, Mar 18, 2014 at 05:22:37PM -0400, Rob Clark wrote:
> > On the i915 side I think all the various pieces we need are finally coming
> > together, and I hope a lot of that go
On Wed, 19 Mar 2014 14:10:53 +0100, Rafael J. Wysocki wrote:
> On Wednesday, March 19, 2014 07:51:45 AM Jean Delvare wrote:
> > Hi Rafael,
> >
> > On Wed, 19 Mar 2014 02:26:52 +0100, Rafael J. Wysocki wrote:
> > > On Monday, March 17, 2014 03:46:44 PM Jean Delvare wrote:
> > > > From: Jean Delvare
On Wednesday, March 19, 2014 07:51:45 AM Jean Delvare wrote:
> Hi Rafael,
>
> On Wed, 19 Mar 2014 02:26:52 +0100, Rafael J. Wysocki wrote:
> > On Monday, March 17, 2014 03:46:44 PM Jean Delvare wrote:
> > > From: Jean Delvare
> > > Subject: ACPI: fix ACPI_VIDEO dependencies
> > >
> > > ACPI_VIDE
On 03/19/2014 12:45 PM, David Herrmann wrote:
> Hi
>
> On Wed, Mar 19, 2014 at 12:33 PM, Thomas Hellstrom
> wrote:
>> By handing the authentication mechanism tokens in the form of const void
>> pointers instead of struct file pointers, drivers are free to provide
>> whatever
>> file pointers they
On Tue, Mar 18, 2014 at 05:22:48PM -0700, Matt Roper wrote:
> 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 ha
2014-03-19 6:23 GMT+09:00 Dave Airlie :
> On Wed, Mar 19, 2014 at 3:37 AM, Daniel Vetter wrote:
>> 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
2014-03-19 13:07 GMT+09:00 Inki Dae :
> 2014-03-19 2:37 GMT+09:00 Daniel Vetter :
>> 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 wan
On Tue, Mar 18, 2014 at 05:22:56PM -0700, Matt Roper wrote:
> 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
Overall this is imo a new featur
2014-03-19 2:37 GMT+09:00 Daniel Vetter :
> 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_
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140319/34930438/attachment.html>
On Tue, Mar 18, 2014 at 05:22:55PM -0700, Matt Roper wrote:
> 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
On Tue, Mar 18, 2014 at 05:22:53PM -0700, Matt Roper wrote:
> 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
>
On Tue, Mar 18, 2014 at 05:22:49PM -0700, Matt Roper wrote:
> 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 Rope
On Tue, Mar 18, 2014 at 05:22:48PM -0700, Matt Roper wrote:
> 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 ha
Hi
On Wed, Mar 19, 2014 at 12:33 PM, Thomas Hellstrom
wrote:
> By handing the authentication mechanism tokens in the form of const void
> pointers instead of struct file pointers, drivers are free to provide whatever
> file pointers they find appropriate. The pointers are never dereferenced in
>
On Tue, Mar 18, 2014 at 05:22:52PM -0700, Matt Roper wrote:
> 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 help
By handing the authentication mechanism tokens in the form of const void
pointers instead of struct file pointers, drivers are free to provide whatever
file pointers they find appropriate. The pointers are never dereferenced in
the drm_vma_manager so that shouldn't be a problem.
As an example, the
On Tue, Mar 18, 2014 at 05:22:51PM -0700, Matt Roper wrote:
> 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
Lots o
On Tue, Mar 18, 2014 at 05:22:48PM -0700, Matt Roper wrote:
> 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 ha
On Tue, Mar 18, 2014 at 05:22:37PM -0400, Rob Clark wrote:
> 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/
-
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140319/fe11e2c7/attachment.sig>
On Wed, Mar 19, 2014 at 05:42:27PM +0900, Michel D?nzer wrote:
> On Die, 2014-03-18 at 11:01 +0100, Daniel Vetter wrote:
> > 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.
On Wed, Mar 19, 2014 at 7:30 AM, Gwenole Beauchesne
wrote:
> 2014-03-15 12:28 GMT+01:00 Daniel Vetter :
>> On Sat, Mar 15, 2014 at 05:41:05AM +0100, Gwenole Beauchesne wrote:
>>> Hi,
>>>
>>> 2014-03-14 22:52 GMT+01:00 Daniel Vetter :
>>> > On Fri, Mar 14, 2014 at 06:59:21PM +0100, Gwenole Beauche
Hi Linus,
This is a fix for an AGP regression exposed by e501b3d87f00 ("agp: Support
64-bit APBASE"), which we merged in v3.14-rc1. We've warned about the
conflict between the GART and PCI resources and cleared out the PCI
resource for a long time, but after e501b3d87f00, we still *use* that
clea
On Wed, Mar 19, 2014 at 12:28:43PM +0100, Daniel Vetter wrote:
> On Tue, Mar 18, 2014 at 05:22:48PM -0700, Matt Roper wrote:
...
> > +
> > + /*
> > +* set_config() adjusts crtc->primary->fb; however the DRM setplane
> > +* code that called us expects to handle the framebuffer update and
>
n-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/20140319/5f666d38/attachment-0001.sig>
Hi,
I have already proposed to reuse drm_panel infrastructure to
implement bridges in my RFC [1] and I have implemented DSI/LVDS bridge
in this way [2]. I guess this discussion is a result of my discussion
with Inki in thread [1]. More comments below.
[1]: http://permalink.gmane.org/gmane.linux.k
Hi Tomi,
Am Mittwoch, den 19.03.2014, 11:08 +0200 schrieb Tomi Valkeinen:
> On 19/03/14 10:22, Philipp Zabel wrote:
>
> > I don't disagree, either. I have no objection against the bindings
> > themselves.
> >
> > Acked-by: Philipp Zabel
>
> Thanks. Is the ack for this particular binding, or fo
n-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/20140319/d4352c4b/attachment.sig>
On Mon, Mar 17, 2014 at 03:48:23PM +0100, Jean Delvare wrote:
> ACPI_VIDEO no longer depends on VIDEO_OUTPUT_CONTROL, so drivers which
> want to select ACPI_VIDEO no longer have to select
> VIDEO_OUTPUT_CONTROL.
>
> Signed-off-by: Jean Delvare
> Cc: "Lee, Chun-Yi"
> Cc: Matthew Garrett
> ---
>
On Tue, Mar 18, 2014 at 3:44 AM, Jani Nikula
wrote:
> 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
Am Mittwoch, den 19.03.2014, 10:11 +0200 schrieb Tomi Valkeinen:
> On 19/03/14 10:03, Philipp Zabel wrote:
>
> >>> Geert's comment also applies to all other connector types. These can be
> >>> input connectors, too.
> >>
> >> We might not need to define all the properties required by input
> >> c
Hi Laurent,
Am Mittwoch, den 19.03.2014, 00:43 +0100 schrieb Laurent Pinchart:
> Hello,
>
> On Tuesday 18 March 2014 09:43:54 Philipp Zabel wrote:
> > Am Dienstag, den 18.03.2014, 10:15 +0200 schrieb Tomi Valkeinen:
> > > Add DT binding documentation for HDMI Connector.
> > >
> > > Signed-off-by
On Wed, Mar 19, 2014 at 7:28 AM, Daniel Vetter wrote:
>> + /*
>> + * set_config() adjusts crtc->primary->fb; however the DRM setplane
>> + * code that called us expects to handle the framebuffer update and
>> + * reference counting; save and restore the current fb before
>> +
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140319/66d8b137/attachment-0001.html>
On Wed, Mar 19, 2014 at 7:07 AM, Daniel Vetter wrote:
> On Tue, Mar 18, 2014 at 05:22:37PM -0400, Rob Clark wrote:
>> 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/~robc
On Wed, Mar 19, 2014 at 2:54 AM, Ben Widawsky wrote:
> On Tue, Mar 18, 2014 at 09:18:42PM -0400, Steven Rostedt wrote:
>> 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 e
On Tue, Mar 18, 2014 at 05:22:58PM -0700, Matt Roper wrote:
> 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 h
Hi Rafael,
On Wed, 19 Mar 2014 02:26:52 +0100, Rafael J. Wysocki wrote:
> On Monday, March 17, 2014 03:46:44 PM Jean Delvare wrote:
> > From: Jean Delvare
> > Subject: ACPI: fix ACPI_VIDEO dependencies
> >
> > ACPI_VIDEO stopped depending on VIDEO_OUTPUT_CONTROL over 3 years ago
> > (see commit
Hi,
2014-03-15 12:28 GMT+01:00 Daniel Vetter :
> On Sat, Mar 15, 2014 at 05:41:05AM +0100, Gwenole Beauchesne wrote:
>> Hi,
>>
>> 2014-03-14 22:52 GMT+01:00 Daniel Vetter :
>> > On Fri, Mar 14, 2014 at 06:59:21PM +0100, Gwenole Beauchesne wrote:
>> >> This is a follow-up to:
>> >> http://lists.fre
On Wed, Mar 19, 2014 at 3:37 AM, Daniel Vetter wrote:
> 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
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140319/7b7ea19a/attachment.html>
Hi,
On Monday, March 17, 2014 03:46:44 PM Jean Delvare wrote:
> From: Jean Delvare
> Subject: ACPI: fix ACPI_VIDEO dependencies
>
> ACPI_VIDEO stopped depending on VIDEO_OUTPUT_CONTROL over 3 years ago
> (see commit 677bd810, "ACPI video: remove output switching control".)
> So it's about time t
Hello,
On Tuesday 18 March 2014 09:43:54 Philipp Zabel wrote:
> 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/vi
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 want for embedded systems
as long as drm_encoder has dr
84 matches
Mail list logo
