On Tue, Dec 18, 2012 at 10:25:05PM +0100, Daniel Vetter wrote:
> And do a quick pass to adjust them to the last few (years?) of changes
> ...
>
> This time actually compile-tested ;-)
>
> Signed-off-by: Daniel Vetter
> ---
> Documentation/DocBook/drm.tmpl |4 ++
> drivers/gpu/drm/drm_crtc.c
spin_unlock(&bdev->fence_lock);
>
> atomic_set(&bo->reserved, 0);
Acked-by: Paul Menzel
Thanks,
Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121219/1a1d7db2/attachment.pgp>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121219/d84f23c1/attachment-0001.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121219/de5e10d9/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121219/d0c955d8/attachment.html>
> Here you go :)
>
> I managed to reproduce the issue. Please test this patch!
Okay switching to automatic mode when pwm1 == 100 now gradually (in a
few seconds, it is not cut down to 35 suddenly) lowers it down to 35.
Switching to automatic mode while in manual mode doesn't make the pwm
increase
On Mon, Dec 17, 2012 at 10:21 PM, Rob Clark wrote:
> On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie wrote:
>>>
>>> Many developers showed interest in the first RFC, and I've had the
>>> opportunity
>>> to discuss it with most of them. I would like to thank (in no particular
>>> order) Tomi Valkei
On Tue, Dec 18, 2012 at 1:38 AM, Inki Dae wrote:
>
>
> 2012/12/18 Daniel Vetter
>>
>> On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark wrote:
>> >> The other thing I'd like you guys to do is kill the idea of fbdev and
>> >> v4l drivers that are "shared" with the drm codebase, really just
>> >> impleme
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121219/b27ef553/attachment.html>
First patch adds PM capabilities for omapdrm. Second patch adds
OMAP5 support to DMM driver component.
Series was build tested and based on linux-next.
v2: Updated commit msg for PM patch
Andy Gross (2):
drm/omap: Add PM capabilities
drm/omap: Add OMAP5 support
drivers/staging/omapdrm/oma
Add support for OMAP5 processor. The main differences are that the OMAP5
has 2 containers, one for 1D and one for 2D. Each container is 128MiB in
size.
Signed-off-by: Andy Gross
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_dmm_priv.h |5 +
drivers/staging/omapdrm/omap_dmm_ti
Added power management capabilities into the omapdrm and DMM drivers.
During suspend, we don't need to do anything to maintain the state of
the LUT. We have all the necessary information to recreate the mappings
of the GEM object list maintained by the omapdrm driver.
On resume, the DMM resume ha
On 12/18/2012 04:33 PM, Paul Menzel wrote:
> I am sorry for the trouble caused by this. As a work around, you could
> also specify the QUIRKS on the Linux command line.
Those patches never made it in. I gave up when I was asked to rewrite
everything without using unions.
--
Some small fixes and cleanups for the tegradrm driver.
This is potentially 3.8-fixes material.
Lucas Stach (6):
drm: tegra: fix front_porch <-> back_porch mixup
drm: tegra: don't leave clients host1x member uninitialized
drm: tegra: protect DC register access with mutex
drm: tegra: remove
Fixes wrong picture offset observed when using HDMI output with a
Technisat HD TV.
Signed-off-by: Lucas Stach
Acked-by: Mark Zhang
Tested-by: Mark Zhang
---
Captions are a bit confusing here. As the porch is always relative to
the sync pulse, the left picture margin is actually the back_porch.
No real problem for now, as nothing is using this, but leaving it
unitialized is asking for trouble later on.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/tegra/host1x.c | 2 ++
1 Datei ge?ndert, 2 Zeilen hinzugef?gt(+)
diff --git a/drivers/gpu/drm/tegra/host1x.c b/drivers/gpu/drm/tegra/host1
Window properties are programmed through a shared aperture and have to
happen atomically. Also we do the read-update-write dance on some of the
shared regs.
To make sure that different functions don't stumble over each other
protect the register access with a mutex.
Signed-off-by: Lucas Stach
---
The 720p and 1080p entries are completely redundant, as we are matching
the table entries against <=pclk.
Also generalize the comment, as we are using those table entries even
when driving other modes than the standard TV ones.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/tegra/hdmi.c | 19 +++
There is no gem.c anymore, those functions are implemented by the
drm_cma_helpers now.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/tegra/drm.h | 18 --
1 Datei ge?ndert, 18 Zeilen entfernt(-)
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index eae1f56
The intention is to program exactly WIN_A, not WIN_A and possibly
others.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/tegra/dc.c | 3 +--
1 Datei ge?ndert, 1 Zeile hinzugef?gt(+), 2 Zeilen entfernt(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index b256574..3475bd9
Hi Linus,
just a single urgent regression fix, seeing a few wierd behaviours I'd
like not to persist.
Dave.
The following changes since commit 55bde6b1442fed8af67b92d21acce67db454c9f9:
Merge branch 'drm-intel-fixes' of
git://people.freedesktop.org/~danvet/drm-intel into drm-next (2012-12-1
On 12/17/2012 03:58 PM, Daniel Vetter wrote:
> All drivers which implement this need to have some sort of refcount to
> allow concurrent vmap usage. Hence implement this in the dma-buf core.
>
> To protect against concurrent calls we need a lock, which potentially
> causes new funny locking inversi
On Wed, Dec 19, 2012 at 12:06 AM, Rahul Sharma wrote:
> On Tue, Dec 18, 2012 at 8:35 PM, Sean Paul wrote:
>> On Tue, Dec 18, 2012 at 9:12 AM, Rahul Sharma
>> wrote:
>>> Program the core and timing generator registers using the timing data
>>> provided in drm_display_mode instead of using hardco
e
perhaps simpler to implement for the one handling the video source ops,
so...
> The DVI and DSI operations model proposed by Tomi in this patch series will
> be
> kept.
>
> Points that we forgot to discuss
>
>
> - DISPLAY_ENTITY_STREAM_SINGLE_SHOT vs. update() operation
Ah, yes, we missed that. I think it's possible to use SINGLE_SHOT, but
then it requires some kind of system to inform about finished update. Or
we could, of course, decide that informing about the update is done in
dispc-specific code, like handling VSYNC.
Hmm, except that won't probably work, as the panel (or any DSI device)
may need to know if the DSI bus is currently used or not.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121219/03f53d95/attachment-0001.pgp>
op.org/archives/dri-devel/attachments/20121219/c3f691a0/attachment-0001.jpg>
s scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121219/4f2f77d6/attachment-0001.pgp>
for other purposes than with DRM.
He had an example of a board, that (if I understood right) gets video
signal from somewhere outside the board, processes the signal with some
IPs/chips, and then outputs the signal. So there's no framebuffer, and
the image is not stored anywhere. I think the
101 - 127 of 127 matches
Mail list logo
