attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141212/ff4fe40d/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141212/7dae965b/attachment-0001.html>
The ioctl DRM_EXYNOS_GEM_MAP_OFFSET and DRM_EXYNOS_GEM_MMAP are removed from
the linux kernel. This patch modifies libdrm and libkms to use drm generic
ioctls instead of the removed ioctls.
Signed-off-by: Hyungwon Hwang
Signed-off-by: Inki Dae
---
exynos/exynos_drm.c | 24 +-
This patch removes the ioctls which are removed from the linux kernel.
Signed-off-by: Hyungwon Hwang
Signed-off-by: Inki Dae
---
exynos/exynos_drm.h | 40
1 file changed, 40 deletions(-)
diff --git a/exynos/exynos_drm.h b/exynos/exynos_drm.h
index c3c65
On Thu, Dec 11, 2014 at 06:18:12PM -0500, Rob Clark wrote:
> Many distro's have mechanism in place to collect and automatically file
> bugs for failed WARN()s. And since every third line in i915 is a WARN()
> it generates quite a lot of noise which is somewhat disconcerting to the
> end user.
>
>
On Fri, Dec 12, 2014 at 08:17:23AM +0100, Daniel Vetter wrote:
> On Thu, Dec 11, 2014 at 06:18:12PM -0500, Rob Clark wrote:
> > Many distro's have mechanism in place to collect and automatically file
> > bugs for failed WARN()s. And since every third line in i915 is a WARN()
> > it generates quite
On 12/11/2014 02:43 PM, Russell King - ARM Linux wrote:
> On Thu, Dec 11, 2014 at 12:58:37PM +, Mark Brown wrote:
>> I'd expect someone reading the change in the regulator API to have at
>> least some idea how this fits in with the rest of the API and how to use
>> it, and probably more importa
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141212/a8745075/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=85421
--- Comment #19 from Jorn Amundsen ---
(In reply to Hin-Tak Leung from comment #18)
> (In reply to Alex Deucher from comment #14)
> > Please make sure your version of mesa has this patch:
> > http://cgit.freedesktop.org/mesa/mesa/commit/
> > ?id=a
On Fri, 12 Dec 2014, Chris Wilson wrote:
> On Fri, Dec 12, 2014 at 08:17:23AM +0100, Daniel Vetter wrote:
>> On Thu, Dec 11, 2014 at 06:18:12PM -0500, Rob Clark wrote:
>> > Many distro's have mechanism in place to collect and automatically file
>> > bugs for failed WARN()s. And since every third
https://bugzilla.kernel.org/show_bug.cgi?id=88481
Cherry Ontop changed:
What|Removed |Added
CC||amerikapsn at web.de
--- Comment #13 from
uery for supported modifiers. Makes life much
easier for generic userspace.
Cheers,
Daniel
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141212/f28f729d/attachment-0001.html>
[adding arm-soc maintainers to cc]
Hello Kukjin,
On 12/02/2014 09:39 AM, Jingoo Han wrote:
> On Tuesday, December 02, 2014 5:17 PM, Javier Martinez Canillas wrote:
>> On Mon, Nov 24, 2014 at 6:41 AM, Vivek Gautam
>> wrote:
>> > DP PHY now require pmu-system-controller to handle PMU register
>>
Hello,
On 11/18/2014 07:20 AM, Ajay kumar wrote:
> On Sat, Nov 15, 2014 at 3:24 PM, Ajay Kumar
> wrote:
>> This series is based on master branch of Linus tree at:
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>>
This series has been in the mailing lists for months and have
A syslog entry of a newly installed ThinkPad T440s advices me :
Dec 12 00:17:59 t44 kernel: [drm:hsw_unclaimed_reg_detect] *ERROR* Unclaimed
register detected. Please use the i915.mmio_debug=1 to debug this problem.
after ei s2disk'ed and resumed it.
So I did it and recompiled the kernel with
On Fri, Dec 12, 2014 at 5:57 AM, Jani Nikula
wrote:
> On Fri, 12 Dec 2014, Chris Wilson wrote:
>> On Fri, Dec 12, 2014 at 08:17:23AM +0100, Daniel Vetter wrote:
>>> On Thu, Dec 11, 2014 at 06:18:12PM -0500, Rob Clark wrote:
>>> > Many distro's have mechanism in place to collect and automatically
On Fri, Dec 12, 2014 at 6:27 AM, Daniel Stone wrote:
> Hey,
>
> On 10 December 2014 at 17:17, Rob Clark wrote:
>>
>> In DRM/KMS we are lacking a good way to deal with tiled/compressed
>> formats. Especially in the case of dmabuf/prime buffer sharing, where
>> we cannot always rely on under-the-h
https://bugzilla.kernel.org/show_bug.cgi?id=88481
--- Comment #14 from Alex Deucher ---
It should be fixed in .5 and .6.
http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-3.17.y&id=68814ef48cc23572b14b494216598d3116f71096
--
You are receiving this mail because:
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/20141212/95a81b3f/attachment-0001.html>
Hi Dave,
Just three small bug fixes for 3.19
The following changes since commit b59f78228ca3d81ecb491fb17d348b07002dbe03:
Merge tag 'drm-intel-next-fixes-2014-12-11' of
git://anongit.freedesktop.org/drm-intel into drm-next (2014-12-12 11:39:49
+1000)
are available in the git repository at:
On Fri, Dec 12, 2014 at 08:50:18AM -0500, Rob Clark wrote:
> On Fri, Dec 12, 2014 at 6:27 AM, Daniel Stone wrote:
> > Hey,
> >
> > On 10 December 2014 at 17:17, Rob Clark wrote:
> >>
> >> In DRM/KMS we are lacking a good way to deal with tiled/compressed
> >> formats. Especially in the case of d
; >
> > > Yeah, I'd second all of danvet's comments here, as well as adding a new
> > > ADDFB2_MODIFIERS cap + query for supported modifiers. Makes life much
> easier
> > > for generic userspace.
> >
> > I've locally made a few tweaks (64b and move some stuff to
> drm_fourcc.h)..
> >
> > I was kicking around the idea of letting plane specify an array of
> > supported format modifiers, and adding this to getplane ioctl, as an
> > alternative to a cap. That plus wiring up some checking to disallow
> > addfb2 for a format + modifiers not supported by at least one plane.
> > Although some hw could only support certain tiling patterns for
> > certain layers of an fb (ie. luma vs chroma). So I may scrap that
> > idea and just go back to cap.
>
> Indeed the format specific limitations are problem. Properties can't
> handle that. We'd need to have some kind of caps for each plane+format
> combination if we want to deal with that. But I don't think we can
> still make it handle all the hw limitations, so I'm not sure it's worth
> going down this path.
>
> --
> Ville Syrjälä
> Intel OTC
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141212/eb565cf6/attachment-0001.html>
On Fri, Dec 12, 2014 at 03:11:02PM +, Daniel Stone wrote:
> Hi,
>
> On 12 December 2014 at 14:56, Ville Syrjälä linux.intel.com>
> wrote:
> >
> > On Fri, Dec 12, 2014 at 08:50:18AM -0500, Rob Clark wrote:
> >
> > It does make me briefly think of just letting us set properties on fb
> >
> >
On Fri, Dec 12, 2014 at 10:11 AM, Daniel Stone wrote:
> Hi,
>
> On 12 December 2014 at 14:56, Ville Syrjälä linux.intel.com>
> wrote:
>>
>> On Fri, Dec 12, 2014 at 08:50:18AM -0500, Rob Clark wrote:
>>
>> > It does make me briefly think of just letting us set properties on fb
>>
>> > objects :-
On Fri, Dec 12, 2014 at 10:30 AM, Ville Syrjälä
wrote:
>>
>> Having them separated is still kinda nice though, for the same rationale as
>> the EGLImage import extension having them as hints. If your hardware
>> doesn't support the tiling/compression format you use, then you're going to
>> be sh
On Fri, Dec 12, 2014 at 11:00:29AM -0500, Rob Clark wrote:
> On Fri, Dec 12, 2014 at 10:30 AM, Ville Syrjälä
> wrote:
> >>
> >> Having them separated is still kinda nice though, for the same rationale as
> >> the EGLImage import extension having them as hints. If your hardware
> >> doesn't suppo
On Fri, Dec 12, 2014 at 11:14 AM, Ville Syrjälä
wrote:
> On Fri, Dec 12, 2014 at 11:00:29AM -0500, Rob Clark wrote:
>> On Fri, Dec 12, 2014 at 10:30 AM, Ville Syrjälä
>> wrote:
>> >>
>> >> Having them separated is still kinda nice though, for the same rationale
>> >> as
>> >> the EGLImage im
rary restrictions. There already are, such as scaling
factors, maximum one non-primary plane per scanline, global bandwidth
limits, etc etc. Those are not something KMS has ever attempted to solve,
and I'm not suggesting that the modifier mechanism attempts to solve them.
Cheers,
Daniel
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141212/28ffaeaf/attachment.html>
On Fri, Dec 12, 2014 at 05:11:50PM +, Daniel Stone wrote:
> Hi,
>
> On 12 December 2014 at 15:30, Ville Syrjälä linux.intel.com>
> wrote:
> >
> > On Fri, Dec 12, 2014 at 03:11:02PM +, Daniel Stone wrote:
> > > On 12 December 2014 at 14:56, Ville Syrjälä <
> > ville.syrjala at linux.in
iting/range hints,
because it makes it far more clear exactly what it affects.
Cheers,
Daniel
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141212/e08e6c44/attachment-0001.html>
On Fri, Dec 12, 2014 at 06:05:49PM +, Daniel Stone wrote:
> Hi,
>
> On 12 December 2014 at 18:00, Ville Syrjälä linux.intel.com>
> wrote:
> >
> > On Fri, Dec 12, 2014 at 05:11:50PM +, Daniel Stone wrote:
> > > If you're doing it through GL, you've already lost. Either you're doing
> > >
On Wednesday 10 December 2014 18:30:10 Daniel Vetter wrote:
> On Wed, Dec 10, 2014 at 12:17:51PM -0500, Rob Clark wrote:
> > In DRM/KMS we are lacking a good way to deal with tiled/compressed
> > formats. Especially in the case of dmabuf/prime buffer sharing, where
> > we cannot always rely on und
Hi Rob,
On Wednesday 10 December 2014 12:17:51 Rob Clark wrote:
> In DRM/KMS we are lacking a good way to deal with tiled/compressed
> formats. Especially in the case of dmabuf/prime buffer sharing, where
> we cannot always rely on under-the-hood flags passed to driver specific
> gem-create ioctl
rchives/dri-devel/attachments/20141212/86cdfe0f/attachment.html>
.org/archives/dri-devel/attachments/20141212/4c683c78/attachment.html>
On Fri, Dec 12, 2014 at 3:57 PM, Laurent Pinchart
wrote:
> Hi Rob,
>
> On Wednesday 10 December 2014 12:17:51 Rob Clark wrote:
>> In DRM/KMS we are lacking a good way to deal with tiled/compressed
>> formats. Especially in the case of dmabuf/prime buffer sharing, where
>> we cannot always rely on
e:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141212/4289caf6/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141212/da2f4edd/attachment-0001.html>
desktop.org/archives/dri-devel/attachments/20141212/1d25eb93/attachment.html>
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/20141212/cf3ff7d3/attachment.html>
This change adds a new eDP connector in msm drm driver. With this
change, eDP panel can work with msm platform under drm framework.
V1: Initial change
V2: Address Rob's comments
Use generated header file for register definitions
Change to devm_* APIs
V3: Address Thierry's comments and re
Modified the hard-coded hdmi connector/encoder implementations in msm drm
driver to support both edp and hdmi.
V1: Initial change
V2: Address Thierry's change
Signed-off-by: Hai Li
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 38 +++--
drivers/gpu/drm/msm/mdp/mdp5/mdp5
t that's
a bit obscure, it's not specific about what the requirements are (or
what the limits are supposed to be on the notification callbacks).
I'm also unclear what is supposed to happen if adding a notification
races with removing the thing being watched.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141212/01edde99/attachment.sig>
al signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141212/10951c43/attachment.sig>
44 matches
Mail list logo
