Hi Dave,
I would like to add one more thing to your radar - amdkfd ;)
We are going to release AMD's HSA Runtime library as Open Source in the next
few
days, and coupled with the modification that Thomas Stellard did for the r600
LLVM back-end, we are effectively releasing a _complete_
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 Vetter wrote:
> > > On Fri, Oct 31, 2014 at 03:53:43PM -0700, Steve Longerbeam wrote:
> > > > Hi, this affects only
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 it. So I think this makes sense - dp aux is fast
>> but not
ock and decode parts of it. So I think this makes sense - dp aux is fast
> but not entirely free, so caching seems useful.
If we want to always cache part of the DPCD wouldn't it be better to add
the cache to struct drm_dp_aux instead of having to duplicate this in
every driver?
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/20141103/8ab9109a/attachment.sig>
On Mon, Nov 03, 2014 at 09:06:04AM +0100, Thierry Reding wrote:
> On Fri, Oct 31, 2014 at 04:59:40PM +0100, Daniel Vetter wrote:
> > On Wed, Oct 29, 2014 at 10:16:49AM +0100, Thierry Reding wrote:
> > > On Wed, Oct 29, 2014 at 08:51:27AM +0100, Daniel Vetter wrote:
> > > > On Tue, Oct 28, 2014 at
On 11/03/2014 04:31 AM, Philipp Zabel wrote:
> Hi Steve,
>
> Am Freitag, den 31.10.2014, 15:53 -0700 schrieb Steve Longerbeam:
>> Create imx-drm crtc device nodes. Each crtc node requires the following
>> parameters:
>>
>> - parent ipu phandle.
>> - di number.
>> - port endpoints.
> [...]
>
>
gt; midlayer mess. Same goes with drm_bridge/panel, which didn't even bother
> to have separate headers from the core modeset header drm_crtc.h.
DRM panel does have a separate header. It's still built into the core
DRM module, but using a separate drm-$(CONFIG_DRM_PANEL) += drm_panel.o
entry in the makefile. At the time it didn't seem worth to add a
completely separate module given the size of the code and the overhead
associated with having a separate module.
Do you still want me to split it off into a separate module to clarify
that it isn't part of the core?
> So would be great if someone could invest a bit of time into cleaning this
> up. Writing proper api docs also helps a lot with achieving a clean and
> sensible split ;-)
There's a bit of API documentation for panels, but I'll see if I can
find some time to enhance it.
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/20141103/2fcbffa5/attachment-0001.sig>
tripled. For the example here(of_drm_panel, struct
> device_node *, struct drm_panel *) or similar. I might be hand-waving over
> a few too many details though ;-)
Okay, I'll take a stab at this and see if I can convert DRM panel to it.
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/20141103/d4a58cd3/attachment.sig>
Turned out to be much simpler on top of my latest atomic stuff than
what I've feared. Some details:
- Drop the modeset_lock_all snakeoil in drm_plane_init. Same
justification as for the equivalent change in drm_crtc_init done in
commit d0fa1af40e784aaf7ebb7ba8a17b229bb3fa4c21
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 driver merged first so I can even
compile it, on hold but
On Mon, Nov 03, 2014 at 05:12:14PM +0100, Daniel Vetter wrote:
> On Fri, Oct 31, 2014 at 03:53:43PM -0700, Steve Longerbeam wrote:
> > Hi, this affects only Freescale imx IPU and imx-drm staging drivers,
> > except for two patches that affect drm core (patch 53 and 63, see below).
> >
> > New
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 so
any runtime PM aware devices could resume.
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/20141103/726bce7c/attachment-0001.html>
On November 2, 2014 8:18:15 PM Daniel Vetter wrote:
> While writing atomic docs I've noticed that I don't get any errors
> for my screw-ups in drm_crtc.h. Fix this immediately.
>
> This just does the bare minimum to get starts, lots of stuff isn't
> properly documented yet unfortunately.
>
> v2:
Hi Dave,
This pull-request includes some bug fixes and code cleanups.
Especially, this fixes the bind failure issue occurred when it tries
to re-bind Exynos drm driver after unbound, and the modetest failure
issue incurred by not having a pair to vblank on and off requests.
Please
Turned out to be much simpler on top of my latest atomic stuff than
what I've feared. Some details:
- Drop the modeset_lock_all snakeoil in drm_plane_init. Same
justification as for the equivalent change in drm_crtc_init done in
commit d0fa1af40e784aaf7ebb7ba8a17b229bb3fa4c21
101 - 116 of 116 matches
Mail list logo
