2013/10/29 Kukjin Kim :
> On 10/28/13 06:42, Inki Dae wrote:
>>
>> Hi Tomasz,
>>
>> I have merged the re-factoring patch set from Sean Paul. Can you
>> re-base your patch set at top of exynos-drm-next?
>>
> Basically, RFC is not patch for merge. So Tomasz needs to re-submit after
> addressing comme
Hi,
On Wednesday 23 of October 2013 12:09:06 Sean Paul wrote:
> On Wed, Oct 23, 2013 at 11:53 AM, Dave Airlie wrote:
> > I think we need to start considering a framework where subdrivers
> > just
> > add drm objects themselves, then the toplevel node is responsible
> > for
> >
The current code writing SADs to the audio registers seems to assume
that there is at most a single SAD per audio format.
However, that is not the case. Especially for PCM it is somewhat common
for sinks to have two SADs, one for 8-channel and one for 2-channel
audio, which may have different supp
dn't return an error value if the rest of the clock
> code doesn NULL checks.
Yes, that would seem to be more consistent. Then again, one could argue
that if somebody got an invalid (ERR_PTR()) clock from clk_get(), they
shouldn't be calling clk_get_parent() on it in the first place. But the
same would be true for NULL, so...
Looping in Mike.
Thierry
-- next part --
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/20131029/6034dd9b/attachment-0001.pgp>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131029/e590cf9c/attachment.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131029/a471889c/attachment.html>
2013/10/28 Sean Paul :
> On Mon, Oct 28, 2013 at 9:35 AM, Inki Dae wrote:
>> This patch makes callback funtions of each sub driver to be called
>> with device object instead of display and manager.
>>
>> Exynos drm framework doesn't need to pass a manager or a display
>> when calling callback func
Hi,
2013/10/29 Olof Johansson :
> On Mon, Oct 28, 2013 at 6:35 AM, Inki Dae wrote:
>> This patch makes callback funtions of each sub driver to be called
>> with device object instead of display and manager.
>>
>> Exynos drm framework doesn't need to pass a manager or a display
>> when calling cal
On 28 October 2013 19:10, Inki Dae wrote:
> Hi Rahul,
>
> I have merged the re-factoring patch set from Sean Paul to
> exynos-drm-next except eDP related patch set that these need more
> reviews. Can you re-base at top of exynos-drm-next?
>
Ok. I will rebase and post it again.
regards,
Rahul Sha
On Tue, Oct 29, 2013 at 12:56 PM, Inki Dae wrote:
> Hi,
>
> 2013/10/29 Olof Johansson :
>> On Mon, Oct 28, 2013 at 6:35 AM, Inki Dae wrote:
>>> This patch makes callback funtions of each sub driver to be called
>>> with device object instead of display and manager.
>>>
>>> Exynos drm framework do
So we had a sessions at kernel summit to discuss the driver model and
DT interactions for a display pipeline,
we had good attendance from a few sides and I hope to summarise the
recommendations below,
a) Device Tree bindings
We should create a top-level virtual device binding that a top level
dr
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131029/49db0274/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131029/9792ba4b/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=63941
Jani Nikula changed:
What|Removed |Added
Component|Video(DRI - Intel) |Video(DRI - non Intel)
Assignee|i
2013/10/28 Sean Paul :
> On Mon, Oct 28, 2013 at 9:35 AM, Inki Dae wrote:
>> This patch fixes build error incurred by the re-factoring patch applying.
>>
>> The re-factoring patch set from Sean missed to apply the update to vidi
>> module so this patch applies the update so that vidi module is als
Hi Dave,
2013/10/29 Dave Airlie :
> On Tue, Oct 29, 2013 at 12:56 PM, Inki Dae wrote:
>> Hi,
>>
>> 2013/10/29 Olof Johansson :
>>> On Mon, Oct 28, 2013 at 6:35 AM, Inki Dae wrote:
This patch makes callback funtions of each sub driver to be called
with device object instead of display
>
>> to DT nodes, but it isn't essential. So I'd like to move away from the
>> 1:1 DT node/driver
>> model as it seriously over complicates things. We have agreed we
>> should possibly add
>> a display virtual node in the DT bindings for a single driver to use
>> as a binding point.
>
> Got it and
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131029/9c781b99/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=60659
--- Comment #9 from Alexey Brodkin ---
I have exactly the same laptop - HP Elitebook 8560w with a nVidia Quadro 1000M,
NVC1 (GF108) in nouveau slang - and used to suffer from similar issue.
But I've just tried Fedora 20 image for Graphics test da
When a second process opens the device and master transferrence is
complete, we walk the list of open devices and remove their
authentication. This also revokes our root privilege. Instead of simply
dropping the authentication, this patch reverts the authenticated state
back to its original value.
Replace the sparse array of booleans with a bitfield.
Signed-off-by: Chris Wilson
---
include/drm/drmP.h | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3a90857bd0ee..02c685f70a72 100644
--- a/include/drm/drmP.h
+++
For various revisions of a chipset if the signal pattern is changed for every
revision, then the phy setting need to be updated correspondingly by measuring
the signal.
For getting correct signals the clock level and data de-emphasis
levels needs to be adjusted.
Since only these 2 values matter,we
This patch moves the hdmi phy setting to smdk5250
dts,as its more of a per board configuration and
also shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 75 +
1 file changed, 75 insertions(+)
d
This patch adds dt support to hdmiphy config settings
as it is board specific and depends on the signal pattern
of board.
Signed-off-by: Shirish S
---
.../devicetree/bindings/video/exynos_hdmi.txt | 34 +
drivers/gpu/drm/exynos/exynos_hdmi.c | 79 ++
This patch moves the hdmi phy setting to arndale dts,
as its more of a per board configuration and also
shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/cros5250-common.dtsi | 75
1 file changed, 75 insertions(+)
d
drivers/gpu/drm/exynos/exynos_hdmi.c | 76
> ++-
> > -
> > 4 files changed, 240 insertions(+), 4 deletions(-)
> >
> > --
> > 1.7.9.5
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131029/a8cea800/attachment-0001.html>
On 10/28/2013 04:09 PM, Jani Nikula wrote:
> On Mon, 28 Oct 2013, Aaron Lu wrote:
>> +static int __init video_set_use_native_backlight(const struct dmi_system_id
>> *d)
>> +{
>> +use_native_backlight = true;
>> +return 0;
>> +}
>
> Hi Aaron, it might be beneficial to make use_native_back
On Tue, Oct 29, 2013 at 4:08 AM, Mark Rutland wrote:
> On Mon, Oct 28, 2013 at 10:15:00AM +, Shirish S wrote:
>> Hi Mark,
>> Firstly thanks for reviewing.
>
> Hi,
>
> Please could you refrain from replying in HTML and use plaintext, it's rather
> difficult to respond sensibly.
>
Sorry for your
This patch moves the hdmi phy setting to arndale dts,
as its more of a per board configuration and also
shall be easier for supporting future chipsets.
Signed-off-by: Shirish S
---
arch/arm/boot/dts/exynos5250-arndale.dts | 75 ++
1 file changed, 75 insertions(+)
d
My build system picked up on this failure:
drivers/built-in.o: In function `shmob_drm_backlight_init':
fmc-chardev.c:(.text+0x9f2d0): undefined reference to
`backlight_device_register'
drivers/built-in.o: In function `shmob_drm_backlight_exit':
fmc-chardev.c:(.text+0x9f370): undefined reference t
On Mon, Oct 28, 2013 at 08:49:45AM +0100, Daniel Vetter wrote:
> Hi Dave,
>
> Please do _not_ pull this. The pipe bpp readout stuff this crucially
> relies on is only partially backported from -next to -fixes and apparently
> missing bits on Haswell.
Ok, updated pull request. I wanted to wait a b
When there are unconsumed pending events, the events are
destroyed by calling destroy callback, but the events list
are remained, because there is no list_del().
It is possible that the page flip request is handled after
drm_events_release() is called and before drm_fb_release().
In this case a dr
2013/10/28 Sean Paul :
> Hi Inki,
> I noticed that you merged "drm/exynos: change callback argument of sub
> driver with device" to your tree without posting it to me, or
> dri-devel, first. I think it would have been prudent to send for
> review/comments considering that:
>
> a) we don't agree on
ad already commented about that, and my patch has already be
> removed from exynos-drm-next. Please re-post that fixup. :)
>
> Thanks,
> Inki Dae
>
> >
> > Sean
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
>
On Tue, Oct 29, 2013 at 11:29:29AM +0100, Daniel Vetter wrote:
> On Mon, Oct 28, 2013 at 08:49:45AM +0100, Daniel Vetter wrote:
> > Hi Dave,
> >
> > Please do _not_ pull this. The pipe bpp readout stuff this crucially
> > relies on is only partially backported from -next to -fixes and apparently
>
On Sun, Oct 27, 2013 at 11:01 PM, Robert Hancock
wrote:
> On 10/27/2013 09:54 AM, Ilia Mirkin wrote:
>>
>> Certain combinations of hardware can't actually support the maximum
>> detected speed. Add a quirk list that lists pairs of hostbridge/chip pci
>> ids and the mode that they should work with
https://bugzilla.kernel.org/show_bug.cgi?id=63941
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #4 fr
https://bugzilla.kernel.org/show_bug.cgi?id=63941
--- Comment #5 from Nikolay Amiantov ---
Is there any way to trace ACPI calls and Intel card state (enabled or not)
on Windows? It works there, so maybe I can get some information.
29.10.2013 17:32 ???:
> https://bugzilla.kernel
https://bugzilla.kernel.org/show_bug.cgi?id=63941
--- Comment #6 from Nikolay Amiantov ---
Comment on attachment 112661
--> https://bugzilla.kernel.org/attachment.cgi?id=112661
attachment-21199-0.html
Replied from GMail and this happened, sorry.
--
You are receiving this mail because:
You ar
On Thu, Oct 10, 2013 at 8:22 PM, Thomas Hellstrom
wrote:
> NO_EVICT bos that are not idle when all references are dropped are put on
> the delayed destroy list. However, since they are not on LRU lists, they
> are not available to shrinkers at that point, and buffers on the delayed
> destroy list
On Thu, Oct 10, 2013 at 8:22 PM, Thomas Hellstrom
wrote:
> Make use of the FAULT_FLAG_ALLOW_RETRY flag to allow dropping the
> mmap_sem while waiting for bo idle.
>
> FAULT_FLAG_ALLOW_RETRY appears to be primarily designed for disk waits
> but should work just as fine for GPU waits..
>
> Signed-o
https://bugzilla.kernel.org/show_bug.cgi?id=63941
Jani Nikula changed:
What|Removed |Added
Attachment #112661|0 |1
is obsolete|
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20131029/7f7d7fab/attachment.html>
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_crtc_helper.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index b06a6c4..65f3658 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helpe
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_crtc_helper.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index dbcd687..d0ac595 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/dr
The following patch series fixes the mutex corruption problem
due to bit-copying of drm_crtc structure that happens when
drm_crtc_helper_set_config function takes the error-recovery
path. The patch series is the alternative solution for the
patch that was proposed and NACK-ed two weeks ago [1].
Th
There is no need to save or restore hwmode field, because by
the time this function sets this field, it cannot fail any more.
However, we should save old enabled field because if
the function fails, we want to return with unchanged CRTC.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_crtc_h
Old framebuffer is stored in save_set.fb and it is
the same value that is later stored in old_fb.
This makes old_fb redundant so we can replace
it with save_set.fb.
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/drm_crtc_helper.c | 12
1 file changed, 4 insertions(+), 8 deletions(-
There is no need to set crtc->enabled field in
drm_crtc_helper_set_config. This is already done (and
properly restored in case of failure) in
drm_crtc_helper_set_mode that is called by
drm_crtc_helper_set_config. Doing it at only one
place makes restoration in case of failure easier.
Signed-off-by
Bit-copying restoration of CRTC structure in failure-recovery
path of drm_crtc_helper_set_config function evokes a
subtle and rare, but very dangerous, corruption of
CRTC mutex structure.
Namely, if drm_crtc_helper_set_config takes the path under
'fail:' label *and* some other process has attempte
This patchset refactors parts of the exynos driver to move it closer to a proper
drm driver (rather than just implementing a drm layer on top of the hardware
drivers). The hope is to get to a point where the dp/hdmi drivers can implement
drm_connector/drm_encoder directly, and fimd/mixer can direct
From: St?phane Marchesin
Signed-off-by: St?phane Marchesin
Signed-off-by: Sean Paul
---
Changes in v2: None
Changes in v3: None
drivers/video/exynos/exynos_dp_core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/exynos/exynos_dp_core.c
b/drivers/video/exynos/exynos_dp_cor
This patch merges overlay_ops into manager_ops. In all cases,
overlay_ops is implemented in the same place as manager ops, it doesn't
serve a functional purpose, and doesn't make things more clear.
Signed-off-by: Sean Paul
---
Changes in v2: None
Changes in v3: None
drivers/gpu/drm/exynos/exyn
This patch implements the intitialize manager op in fimd.
Signed-off-by: Sean Paul
---
Changes in v2: None
Changes in v3: None
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fim
This patch implements the initialize callback in the hdmi and mixer
manager. This allows us to get rid of drm_dev in the drm_hdmi level and
track it in the mixer and hdmi drivers. This is one of the things
holding back the complete removal of the drm_hdmi layer.
Signed-off-by: Sean Paul
---
Chan
This patch changes the manager ops callbacks from accepting the subdrv
device pointer to taking a pointer to the manager. This will allow us
to move closer to decoupling manager/display from subdrv, and subsequently
decoupling the crtc/plane from the encoder.
Signed-off-by: Sean Paul
---
Changes
This patch removes the apply() manager callback in favor of putting the
relevant commits in the individual drivers. This will mitigate some of
the difference between the suspend/resume path and the dpms path
Signed-off-by: Sean Paul
---
Changes in v2:
- This was previously in another pat
This patch removes the call from encoder dpms into connector dpms (which
will then call back into encoder dpms through the helper function). The
callback is likely to keep connector->dpms in the right state when
initiating dpms from crtc or encoder, but this isn't the right way to do
it. This patch
Change all instances of possible_crtcs in the exynos drm driver to be
unsigned long. This matches the type used in the drm layer.
Signed-off-by: Sean Paul
---
Changes in v2: None
Changes in v3: None
drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_encoder.c
From: Daniel Kurtz
The i2c client was previously being passed into the hdmi driver via a
dedicated i2c driver, and then a global variable. This patch removes all
of that and just uses the device tree to get the i2c_client. This patch
also properly references the client so we don't lose it before
This patch trims exynos_drm_hdmi out of the driver. The reason it
existed in the first place was to make up for the mixture of
display/overlay/manager ops being spread across hdmi and mixer. With
that code now rationalized, mixer and hdmi map directly to
exynos_drm_crtc and exynos_drm_encoder, resp
This patch moves the exynos_drm_display implementation from fimd into
the dp driver. This will allow for tighter integration of the dp driver
into the exynos drm driver.
Signed-off-by: Sean Paul
---
Changes in v2: None
Changes in v3: None
.../devicetree/bindings/video/exynos_dp.txt| 1
This patch moves the display-timings node from fimd to dp to reflect the
device tree bindings change.
Signed-off-by: Sean Paul
---
Changes in v2: None
Changes in v3: None
arch/arm/boot/dts/exynos5250-arndale.dts | 7 ---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 7 ---
arch/arm/boot
This patch implements the dpms display callback for the DP driver.
Signed-off-by: Sean Paul
---
Changes in v2:
- Added to the patchset
Changes in v3: None
drivers/gpu/drm/exynos/exynos_dp_core.c | 173
drivers/gpu/drm/exynos/exynos_dp_core.h | 1 +
2
This patch adds an initialize function to the manager and display
operations. This allows them to keep track of drm_device in their
local context, as well as adds an initialization hook right after
the encoder is created.
Signed-off-by: Sean Paul
---
Changes in v2: None
Changes in v3: None
dri
This patch splits display and manager from subdrv. The result is that
crtc functions can directly call into manager callbacks and encoder
functions can directly call into display callbacks. This will allow
us to remove the exynos_drm_hdmi shim and support mixer/hdmi & fimd/dp
with common code.
Sig
This patch changes the manual copying of mode to adjusted_mode in
mode_fixup to use drm_mode_copy instead of handling things manually.
Signed-off-by: Sean Paul
---
Changes in v2: None
Changes in v3: None
drivers/gpu/drm/exynos/exynos_hdmi.c | 10 +-
1 file changed, 1 insertion(+), 9 de
This patch implements drm_connector directly in the vidi
driver, this will allow us to move away from the exynos_drm_connector
layer.
Signed-off-by: Sean Paul
---
Changes in v3:
- Added to the patchset
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 163 ---
1 fi
This patch implements drm_connector directly in the dp driver, this will
allow us to move away from the exynos_drm_connector layer.
Signed-off-by: Sean Paul
---
Changes in v3:
- Added to the patchset
drivers/gpu/drm/exynos/exynos_dp_core.c | 99 ++---
driver
This patch renames the display_op power_on to dpms to accurately reflect
what the function does.
The side-effect of this patch is that the new hdmi dpms callback is now
invoked twice in the dpms path. This is safe and will be dealt with when
the exynos_drm shim goes away.
Signed-off-by: Sean Paul
This patch removes the dpms state tracking in encoder. This
state is at best confusing and at worst incorrect since the display
drivers can turn on and off without propagating the value.
Signed-off-by: Sean Paul
---
Changes in v2: None
Changes in v3: None
drivers/gpu/drm/exynos/exynos_drm_enco
This patch moves the code which disables unused crtc planes from the
encoder to the crtc. Since there is a 1:1 encoder/crtc mapping in
exynos, the only valid crtc change the pre-existing code could catch is
disconnecting an active crtc from the encoder. Thus it is functionally
equivalent to just di
This patch adds a mode_set callback to the manager operations which
sets the crtc's current mode to the manager driver.
Signed-off-by: Sean Paul
---
Changes in v2: None
Changes in v3: None
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4
drivers/gpu/drm/exynos/exynos_drm_drv.h | 3 +++
2 fi
This patch adds a new manager callback for mode_fixup and pipes it
through exynos_drm_crtc.
Signed-off-by: Sean Paul
---
Changes in v2: None
Changes in v3: None
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 7 ++-
drivers/gpu/drm/exynos/exynos_drm_drv.h | 4
2 files changed, 10 insertio
This patch uses the mode passed into mode_set to configure fimd instead
of directly using the panel from context. This will allow us to move
the exynos_drm_display implementation from fimd into the DP driver
where it belongs.
Signed-off-by: Sean Paul
---
Changes in v2: None
Changes in v3: None
This patch removes a few fimd_context members which are either entirely
unused or unneeded.
Signed-off-by: Sean Paul
---
Changes in v2: None
Changes in v3: None
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gp
This patch moves the code from video/ to drm/
Signed-off-by: Sean Paul
---
Changes in v2: None
Changes in v3: None
drivers/gpu/drm/exynos/Kconfig |7 +
drivers/gpu/drm/exynos/Makefile |1 +
drivers/gpu/drm/exynos/exynos_dp_core.c | 1213 ++
This patch separates the fimd_activate function into poweron/poweroff
functions to be more consistent with the other drivers in exynos drm. It
also properly cleans up after failures in poweron. The functions have
also been shuffled around such that they are all in the same
spot in the file and powe
This patch removes all of the suspend/resume logic from the individual
drivers and consolidates it in drm_drv. This consolidation reduces the
number of functions which enable/disable the hardware to just one -- the
dpms callback. This ensures that we always power up/down in a consistent
manner.
Si
This creates a new display hook called create_connector. The purpose is
to allow the display driver to create its own drm_connector instead of
using the exynos_drm_connector. This moves things closer to completely
removing the exynos_drm_connector abstraction.
Signed-off-by: Sean Paul
---
Change
This patch implements drm_connector in the hdmi driver directly, instead
of using exynos_drm_connector.
Signed-off-by: Sean Paul
---
Changes in v3:
- Added to the patchset
drivers/gpu/drm/exynos/exynos_hdmi.c | 126 +++
1 file changed, 85 insertions(+),
This patch moves the lvds bridge discovery and connector pre-emption
code from exynos common code into the dp driver (since the bridge is
only applicable for dp).
Signed-off-by: Sean Paul
---
Changes in v3:
- Added to the patchset
drivers/gpu/drm/exynos/exynos_dp_core.c | 41 +
This path removes the exynos_drm_connector code since it was just
passing hooks through display_ops. The individual device drivers are now
responsible for implementing drm_connector directly.
Signed-off-by: Sean Paul
---
Changes in v3:
- Added to the patchset
drivers/gpu/drm/exynos/Mak
Hi Russell,
On Tuesday 29 October 2013 10:04:13 Russell King - ARM Linux wrote:
> My build system picked up on this failure:
>
> drivers/built-in.o: In function `shmob_drm_backlight_init':
> fmc-chardev.c:(.text+0x9f2d0): undefined reference to
> `backlight_device_register' drivers/built-in.o: In
From: Laurent Pinchart
The driver registers a backlight device and thus requires
BACKLIGHT_CLASS_DEVICE to be selected to avoid compilation breakages.
Cc: stable at vger.kernel.org
Reported-by: Russell King
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/shmobile/Kconfig | 1 +
1 file cha
So I took another look at the vblank timestamping code, and got a bit
excited. The result is this patchset.
Summary of changes:
- kill crtc->hwmode dependency
- eliminate a bunch of 64bit math
- fix timestamps for stereo and interlaced modes (on i915 at least)
- move the "early vbl irq" hack into
From: Ville Syrj?l?
We don't really use hwmode anymore in i915, so eliminating its use
from the core code seems prudent. Just pass the appropriate mode
to drm_calc_timestamping_constants().
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_crtc_helper.c| 2 +-
drivers/gpu/drm/drm_irq.c
From: Ville Syrj?l?
Rather than using crtc->hwmode, just pass the relevant mode to
drm_calc_vbltimestamp_from_scanoutpos(). This removes the last hwmode
usage from core drm.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_irq.c | 6 +++---
drivers/gpu/drm/i915/i915_irq.c | 3
From: Ville Syrj?l?
drm core no longer uses crtc->hwmode, and neither does i915, so we can totally
ignore it
in i915.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_display.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i
From: Ville Syrj?l?
Update the pixel/line/frame duration information when we switch to the
new pipe config. This will keep the timestamping constants in better
sync with the real hardware state.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_display.c | 17 -
1 fil
From: Ville Syrj?l?
drm_calc_timestamping_constants() makes the math more complex
than necessary.
- multipying the dotclock by 1000 is pointless, just makes all the
numbers bigger
- div64_u64() is also pointless, div_u64 is enough
- pixeldur_ns doesn't need any 64bit math
Signed-off-by: Ville
From: Ville Syrj?l?
crtc_clock is now supposed to be the actual pixel clock corresponding to
the other crtc_ timing values. Populate crtc_clock appropriately in
radeon_atom_get_tv_timings().
This was the only obvious place where we frob with the crtc_ timigns
directly instead of calling drm_mode
From: Ville Syrj?l?
drm_calc_timestamping_constants() computes the pixel/line/frame
durations based on the crtc_ timing values. The corresponding pixel
clock is in mode->crtc_clock, so we need to use that instead of
mode->clock.
This should fix drm_calc_timestamping_constants() for frame packing
From: Ville Syrj?l?
Using s64 for the timestamping constants is wasteful. Signed 32bit
integers get us a range of over +-2 seconds. Presuming that no-one
wants to a vrefresh rate less than 0.5, we can switch to using int
for the timestamping constants. We save a few bytes in drm_crtc and
avoid a
From: Ville Syrj?l?
The scanline counter counts lines in the current field, not the entire
frame. But the crtc_ timings are the values for the entire frame. Divide
the vertical timings by 2 to make them match the scanline counter.
The rounding was carefully chosen to make it do the right thing w
From: Ville Syrj?l?
Preparation for moving the early vblank IRQ logic into
radeon_get_crtc_scanoutpos().
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_irq.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 3 ++-
drivers/gpu/drm/radeon/radeon_display.c | 7 ---
driver
From: Ville Syrj?l?
Move the long blurp to into the body of the comment, leaving only
a short summary line at the top.
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm_irq.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/driver
From: Ville Syrj?l?
We're currently miscalculating the line and pixel durations for
interlaced modes. crtc_htotal and crtc_vtotal are the full frame
timings, and so is crtc_clock, so we can compute the line
and pixel durations from those w/o any extra adjustments. But
we actually want framedur_ns
From: Ville Syrj?l?
On pre-PCH platforms ISR doesn't seem to be an actual ISR, at least as
far as display interrupts are concerned. Instead it sort of looks like
some ISR bits just directly reflect the corresponding bit from PIPESTAT.
The bit appears in the ISR only if the PIPESTAT interrupt is e
From: Ville Syrj?l?
i915 doesn't need this kludge for most platforms. Although we do
appear to need something similar on certain platforms, but we can
be more accurate when we apply the adjustment since we know exactly
why the scanline counter doesn't always quite match the vblank
status.
Also t
1 - 100 of 128 matches
Mail list logo
