On Mon, 15 Apr 2013, Libin wrote:
> diff --git a/drivers/char/mspec.c b/drivers/char/mspec.c
> index e1f60f9..ed0703f 100644
> --- a/drivers/char/mspec.c
> +++ b/drivers/char/mspec.c
> @@ -168,7 +168,7 @@ mspec_close(struct vm_area_struct *vma)
> if (!atomic_dec_and_test(&vdata->refcnt))
>
On Wed, Apr 17, 2013 at 02:38:02PM +1000, Dave Airlie wrote:
> Currently we have a problem with this:
> 1. i915: create gem object
> 2. i915: export gem object to prime
> 3. radeon: import gem object
> 4. close prime fd
> 5. radeon: unref object
> 6. i915: unref object
>
> i915 has an imported obj
https://bugs.freedesktop.org/show_bug.cgi?id=63579
--- Comment #10 from Erik Faye-Lund ---
Another data-point: My AMD driver also does not support line continuation
characters by default, although they do *after* a "#version 420" line.
So in conclusion, I think blindly supporting line-continuati
On 04/17/2013 06:02 AM, Sachin Kamat wrote:
> Hi Sylwester,
>
> On 16 April 2013 23:01, Sylwester Nawrocki wrote:
>> @@ -1835,16 +1859,19 @@ static int fimc_probe(struct platform_device *pdev)
>> ret = exynos_drm_ippdrv_register(ippdrv);
>> if (ret < 0) {
>> dev_er
We have a similar problem: A HD6570(TURKS) card with RS780E chipset. When
booting, DVI output is good, but VGA output is black screen; after X
started, DVI is still good and VGA blinks forever. We have tried
3.4~3.9-rc7 kernel, all kernels after the commit "drm/radeon: properly
handle mc_stop/mc_re
Hi Inki,
This small patch series adds device tree support for the DRM FIMC driver.
The binding documentation can be found in -next at Documentation/devicetree/
bindings/media/samsung-fimc.txt.
It will make the driver dependent on OF. This patch series is needed in
3.10 to ensure simultaneous opera
There is no need for explicit calls of devm_kfree(), as
the allocated memory will be freed during driver's detach.
Remove the redundant devm_kfree() calls from probe() and
remove() callbacks.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fi
The clocks handling is refactored and a "mux" clock handling is
added to account for changes in the clocks driver. After switching
to the common clock framework the sclk_fimc clock is now split
into two clocks: a gate and a mux clock. In order to retain the
exisiting functionality two additional co
This patch adds OF initialization support for the FIMC driver.
The binding documentation can be found at Documentation/devicetree/
bindings/media/samsung-fimc.txt.
The syscon regmap interface is used to serialize access to the
shared CAMBLK registers from within the V4L2 FIMC-IS and the DRM
FIMC d
https://bugs.freedesktop.org/show_bug.cgi?id=63632
Priority: medium
Bug ID: 63632
Assignee: dri-devel@lists.freedesktop.org
Summary: RS880 + mesa/llvm heads - segfault
Severity: normal
Classification: Unclassified
OS: Linux (
On Wed, Feb 20, 2013 at 07:56:33PM +0100, Borislav Petkov wrote:
> On Tue, Feb 05, 2013 at 05:22:06PM +0100, Borislav Petkov wrote:
> > On Tue, Feb 05, 2013 at 04:38:35PM +0100, Maarten Lankhorst wrote:
> > > Argh, next attempt, based on i915's Kconfig.
> > >
> > > It seems that not only I have to
On Tuesday 16 April 2013, Nishanth Menon wrote:
> On 12:50-20130416, Arnd Bergmann wrote:
> > On Tuesday 16 April 2013 12:48:28 Paul Sokolovsky wrote:
> > > > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> > > > index 8d1e2bb..73a99e4 100644
> > > > --- a/include/uapi/drm/drm.h
> >
On Wed, Apr 17, 2013 at 6:43 AM, Arnd Bergmann wrote:
>> drivers/scsi/aic7xxx/aicasm/aicasm_symbol.c:#ifdef __linux__
>> drivers/scsi/aic7xxx/aicasm/aicasm_symbol.h:#ifdef __linux__
>> drivers/scsi/dpt/osd_defs.h:#if (defined(__linux__))
>> drivers/staging/ced1401/machine.h:#if (defined(__linux__)
On 04/12/2013 01:38 PM, Bjorn Helgaas wrote:
On Thu, Apr 11, 2013 at 7:13 AM, Lucas Kannebley Tavares
wrote:
radeon currently uses a drm function to get the speed capabilities for
the bus. However, this is a non-standard method of performing this
detection and this patch changes it to use the
On 04/15/2013 02:00 AM, Michael Ellerman wrote:
On Thu, Apr 11, 2013 at 10:13:13AM -0300, Lucas Kannebley Tavares wrote:
On pseries machines the detection for max_bus_speed should be done
through an OpenFirmware property. This patch adds a function to perform this
detection and a hook to perform
On 04/15/2013 08:42 AM, Michael Ellerman wrote:
On Thu, Apr 11, 2013 at 10:13:13AM -0300, Lucas Kannebley Tavares wrote:
On pseries machines the detection for max_bus_speed should be done
through an OpenFirmware property. This patch adds a function to perform this
detection and a hook to perform
On Tue, 2013-04-16 at 12:50 +0200, Arnd Bergmann wrote:
> On Tuesday 16 April 2013 12:48:28 Paul Sokolovsky wrote:
> > > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> > > index 8d1e2bb..73a99e4 100644
> > > --- a/include/uapi/drm/drm.h
> > > +++ b/include/uapi/drm/drm.h
> > > @@ -3
On Wed, 2013-04-17 at 10:21 +0200, Daniel Vetter wrote:
> On Wed, Apr 17, 2013 at 02:38:02PM +1000, Dave Airlie wrote:
> > Currently we have a problem with this:
> > 1. i915: create gem object
> > 2. i915: export gem object to prime
> > 3. radeon: import gem object
> > 4. close prime fd
> > 5. rade
https://bugs.freedesktop.org/show_bug.cgi?id=63579
--- Comment #11 from Ian Romanick ---
(In reply to comment #9)
> I don't know where you have the retroactive-story from, but the
> specification does not mention it being retroactive, and even goes as far as
> to say:
I have the story from being
From: Ville Syrjälä
Instead of locking all modeset locks during plane updates, use just
a single CRTC mutex. To make that work, track the CRTC that "owns"
the plane currently. During enable/update that means the new
CRTC, and during disable it means the old CRTC.
Since the plane state is no long
https://bugs.freedesktop.org/show_bug.cgi?id=63579
--- Comment #12 from Erik Faye-Lund ---
Well, Khronos meetings don't define the spec, the specification does. And the
specification is pretty clear here.
--
You are receiving this mail because:
You are the assignee for the bug.
This series attempts to make our CEA mode matching recognize both the
60Hz and 59.94Hz variants of the modes (and similarly for 24/23.97,
30/29.97, etc.).
The benefits should include:
- Send the correct VIC in the AVI infoframe
- Pick the correct RGB quantization range in automatic mode
__
From: Ville Syrjälä
No need to zero initialize .vrefresh in DRM_MODE() since it's using
desgignated initializers.
This will also avoid some duplicate initialization warnings later.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_crtc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
From: Ville Syrjälä
drm_mode_equal_no_clocks() is like drm_mode_equal() except it doesn't
compare the clock or vrefresh values. drm_mode_equal() is now
implemented by first doing the clock checks, and then calling
drm_mode_equal_no_clocks().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm
From: Ville Syrjälä
Well have use for the vrefresh information of CEA modes later. Just
populate the information into the table to avoid having to calculate
it.
I'm too lazy to check if someone relies on newly allocated CEA
modes having 0 vrefresh, so just clear vrefresh back to 0 when
adding th
From: Ville Syrjälä
drm_match_cea_mode() should be able to match both the 60Hz version,
and the 59.94Hz version of modes.
We only store one pixel clock value per mode in edid_cea_modes, so the
other value must be calculated. Depending on the mode, edid_cea_modes
contains the pixel clock for eith
On Wed, Apr 17, 2013 at 08:04:52PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Instead of locking all modeset locks during plane updates, use just
> a single CRTC mutex. To make that work, track the CRTC that "owns"
> the plane currently. During enable/update that means
https://bugs.freedesktop.org/show_bug.cgi?id=63579
--- Comment #13 from Ian Romanick ---
Comment on attachment 78052
--> https://bugs.freedesktop.org/attachment.cgi?id=78052
[PATCH] gallium: handle drirc disable_glsl_line_continuations option
You'll probably want review from someone that actua
https://bugs.freedesktop.org/show_bug.cgi?id=63579
--- Comment #14 from Ian Romanick ---
(In reply to comment #12)
> Well, Khronos meetings don't define the spec, the specification does. And
> the specification is pretty clear here.
The discussion was at the time of the vote, and I stand by that
On Wed, Apr 10, 2013 at 12:28 AM, Steven Rostedt wrote:
> On Thu, Apr 04, 2013 at 06:41:02PM +0200, Peter Zijlstra wrote:
>> On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
>> > The thing is now that you're not expected to hold these locks for a
>> > long
>> > time - if you need to synchro
From: Ville Syrjälä
libkms only has the xrgb format, so we're overallocating the bo by
quite a lot in some cases. But we still need to get the pitch from the
libkms since it's the driver that decides how to align it.
Signed-off-by: Ville Syrjälä
---
tests/modetest/buffers.c | 34 ++
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
tests/modetest/modetest.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index c91bb9d..27cd2ce 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modet
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
tests/modetest/buffers.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
index 5086381..6b117b4 100644
--- a/tests/modetest/buffers.c
+++ b/tests/modetest/buffer
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
tests/modetest/buffers.c | 120 +--
1 file changed, 115 insertions(+), 5 deletions(-)
diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
index 7f534a1..3b1685c 100644
--- a/tests/mode
From: Ville Syrjälä
Spelling out eDP or DP make for a ridicilously long string which plays
havoc with formatting. Just say eDP or DP.
Signed-off-by: Ville Syrjälä
---
tests/modetest/modetest.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/modetest/modetest.c b/t
Hi
2013/4/17 :
> From: Ville Syrjälä
>
> drm_mode_equal_no_clocks() is like drm_mode_equal() except it doesn't
> compare the clock or vrefresh values. drm_mode_equal() is now
> implemented by first doing the clock checks, and then calling
> drm_mode_equal_no_clocks().
>
> Signed-off-by: Ville Sy
https://bugs.freedesktop.org/show_bug.cgi?id=63579
--- Comment #15 from Erik Faye-Lund ---
Thanks for the clarification, but I'm still not entirely convinced.
I agree that this per-spec for OpenGL ES 3.0 (although I'm a bit disappointed
that the ES3-group missed that we in the ES2-group had made
On Wed, Apr 17, 2013 at 8:38 AM, Lucas Kannebley Tavares
wrote:
> On 04/12/2013 01:38 PM, Bjorn Helgaas wrote:
>>
>> On Thu, Apr 11, 2013 at 7:13 AM, Lucas Kannebley Tavares
>> wrote:
>>>
>>> radeon currently uses a drm function to get the speed capabilities for
>>> the bus. However, this is a n
On Wed, Apr 17, 2013 at 2:04 PM, Alex Deucher wrote:
> On Wed, Apr 17, 2013 at 8:38 AM, Lucas Kannebley Tavares
> wrote:
>> On 04/12/2013 01:38 PM, Bjorn Helgaas wrote:
>>>
>>> On Thu, Apr 11, 2013 at 7:13 AM, Lucas Kannebley Tavares
>>> wrote:
radeon currently uses a drm function to
On Wed, Apr 17, 2013 at 4:11 PM, Bjorn Helgaas wrote:
> On Wed, Apr 17, 2013 at 2:04 PM, Alex Deucher wrote:
>> On Wed, Apr 17, 2013 at 8:38 AM, Lucas Kannebley Tavares
>> wrote:
>>> On 04/12/2013 01:38 PM, Bjorn Helgaas wrote:
On Thu, Apr 11, 2013 at 7:13 AM, Lucas Kannebley Tavares
>
On Wed, Apr 17, 2013 at 2:17 PM, Alex Deucher wrote:
> On Wed, Apr 17, 2013 at 4:11 PM, Bjorn Helgaas wrote:
>> On Wed, Apr 17, 2013 at 2:04 PM, Alex Deucher wrote:
>>> On Wed, Apr 17, 2013 at 8:38 AM, Lucas Kannebley Tavares
>>> wrote:
On 04/12/2013 01:38 PM, Bjorn Helgaas wrote:
>
>>
2013/4/17 :
> This series attempts to make our CEA mode matching recognize both the
> 60Hz and 59.94Hz variants of the modes (and similarly for 24/23.97,
> 30/29.97, etc.).
>
> The benefits should include:
> - Send the correct VIC in the AVI infoframe
> - Pick the correct RGB quantization range in
https://bugs.freedesktop.org/show_bug.cgi?id=63579
--- Comment #16 from Ian Romanick ---
(In reply to comment #15)
> Thanks for the clarification, but I'm still not entirely convinced.
>
> I agree that this per-spec for OpenGL ES 3.0 (although I'm a bit
> disappointed that the ES3-group missed t
https://bugs.freedesktop.org/show_bug.cgi?id=63532
--- Comment #14 from Ian Romanick ---
(In reply to comment #13)
> I managed to start the game and it seems there are different problems with
> water rendering, and I don't see framebuffer-related errors in the game.
> Possibly I was wrong, I'll l
It appears exynos is passing the generic flags from the dumb ioctls
straight into the the GEM creation code.
The dumb flags are NOT driver specific, and are NOT to be used in this
fashion. Please remove this use of the flags from your driver.
I was going to add one new flag to the interface for S
https://bugs.freedesktop.org/show_bug.cgi?id=63579
--- Comment #17 from Erik Faye-Lund ---
(In reply to comment #16)
> (In reply to comment #15)
> > Thanks for the clarification, but I'm still not entirely convinced.
> >
> > I've just tested the latter. So apparently, Mesa is the only major
> >
https://bugs.freedesktop.org/show_bug.cgi?id=63579
--- Comment #18 from Ian Romanick ---
(In reply to comment #17)
> (In reply to comment #16)
> > Making the support general (instead of just for preprocessor directives)
> > simplified the code greatly. Since I'm responsible for maintaining this
On Wed, Apr 17, 2013 at 7:57 PM, Kero wrote:
>> > 4) when using modules, initialization from hibernation is not good enough:
>> >my screen stays black; without using modules, the kernel boots
>> > normally, and everything is fine.
>> > 5) initialization from suspend is not good enough: my Asu
https://bugs.freedesktop.org/show_bug.cgi?id=49981
--- Comment #33 from Benjamin Lee ---
Sorry, my previous patch was bogus -- TURKS mobility actually needs
POWER_STATE_TYPE_PERFORMANCE. radeon_pm_get_type_index() currently fails to
find the requested state (POWER_STATE_TYPE_BATTERY).
Here is a
https://bugs.freedesktop.org/show_bug.cgi?id=63532
--- Comment #15 from Vadim Girlin ---
(In reply to comment #14)
> > #2 0x7f4485b7a63e in glBindTexture (target=0, texture=2079)
>
> That's definitely no good. 0 isn't a valid target, and 2079 (0x081F) isn't
> either. Weird.
I tested it w
On Wed, Apr 17, 2013 at 6:44 PM, Randy Dunlap wrote:
> On 04/17/13 16:03, a...@linux-foundation.org wrote:
>> The mm-of-the-moment snapshot 2013-04-17-16-02 has been uploaded to
>>
>>http://www.ozlabs.org/~akpm/mmotm/
>>
>
>
> I saw this in linux-next a few days ago and forgot to post it.
>
>
Hi, Dave
2013/4/18 Dave Airlie
> It appears exynos is passing the generic flags from the dumb ioctls
> straight into the the GEM creation code.
>
> The dumb flags are NOT driver specific, and are NOT to be used in this
> fashion. Please remove this use of the flags from your driver.
>
>
Got it
This patch removes the use of dumb flags from driver.
As Dave pointed out, the dumb flags are not driver specific
so this should be removed from driver.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_gem.c |3 ++-
1 files changed, 2 insertions(+)
Hi Daniel,
On Tuesday 16 April 2013 21:06:43 Daniel Vetter wrote:
> On Tue, Apr 16, 2013 at 01:12:21PM +1000, Dave Airlie wrote:
> > On Mon, Apr 15, 2013 at 11:37 PM, Laurent Pinchart wrote:
> > > Property blob objects need to be destroyed when cleaning up to avoid
> > > memory leaks. Go through t
s/dri-devel/attachments/20130417/b2104e25/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=43751
John Paul Funk changed:
What|Removed |Added
CC||funk at funktronix.com
--- Comment #
Currently we have a problem with this:
1. i915: create gem object
2. i915: export gem object to prime
3. radeon: import gem object
4. close prime fd
5. radeon: unref object
6. i915: unref object
i915 has an imported object reference in its file priv, that isn't
cleaned up properly until fd close.
Currently we have a problem with this:
1. i915: create gem object
2. i915: export gem object to prime
3. radeon: import gem object
4. close prime fd
5. radeon: unref object
6. i915: unref object
i915 has an imported object reference in its file priv, that isn't
cleaned up properly until fd close.
Hi Sylwester,
On 16 April 2013 23:01, Sylwester Nawrocki wrote:
> @@ -1835,16 +1859,19 @@ static int fimc_probe(struct platform_device *pdev)
> ret = exynos_drm_ippdrv_register(ippdrv);
> if (ret < 0) {
> dev_err(dev, "failed to register drm fimc device.\n");
> -
Hi Dave,
This is initial pull request for Exynos. It includes a big change
that it makes drm_display_mode for timings parameters to be used
for exynos4 and exynos5 commonly and cleans up unnecessary codes.
And also it adds device tree support for fimd to get timing values
and interr
On Mon, 15 Apr 2013, Libin wrote:
> diff --git a/drivers/char/mspec.c b/drivers/char/mspec.c
> index e1f60f9..ed0703f 100644
> --- a/drivers/char/mspec.c
> +++ b/drivers/char/mspec.c
> @@ -168,7 +168,7 @@ mspec_close(struct vm_area_struct *vma)
> if (!atomic_dec_and_test(&vdata->refcnt))
>
On Wed, Apr 17, 2013 at 02:38:02PM +1000, Dave Airlie wrote:
> Currently we have a problem with this:
> 1. i915: create gem object
> 2. i915: export gem object to prime
> 3. radeon: import gem object
> 4. close prime fd
> 5. radeon: unref object
> 6. i915: unref object
>
> i915 has an imported obj
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130417/2804cbac/attachment.html>
On 04/17/2013 06:02 AM, Sachin Kamat wrote:
> Hi Sylwester,
>
> On 16 April 2013 23:01, Sylwester Nawrocki wrote:
>> @@ -1835,16 +1859,19 @@ static int fimc_probe(struct platform_device *pdev)
>> ret = exynos_drm_ippdrv_register(ippdrv);
>> if (ret < 0) {
>> dev_er
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130417/a75d4971/attachment.html>
Hi Inki,
This small patch series adds device tree support for the DRM FIMC driver.
The binding documentation can be found in -next at Documentation/devicetree/
bindings/media/samsung-fimc.txt.
It will make the driver dependent on OF. This patch series is needed in
3.10 to ensure simultaneous opera
There is no need for explicit calls of devm_kfree(), as
the allocated memory will be freed during driver's detach.
Remove the redundant devm_kfree() calls from probe() and
remove() callbacks.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fi
The clocks handling is refactored and a "mux" clock handling is
added to account for changes in the clocks driver. After switching
to the common clock framework the sclk_fimc clock is now split
into two clocks: a gate and a mux clock. In order to retain the
exisiting functionality two additional co
This patch adds OF initialization support for the FIMC driver.
The binding documentation can be found at Documentation/devicetree/
bindings/media/samsung-fimc.txt.
The syscon regmap interface is used to serialize access to the
shared CAMBLK registers from within the V4L2 FIMC-IS and the DRM
FIMC d
ving 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/20130417/068de0ad/attachment-0001.html>
On Wed, Feb 20, 2013 at 07:56:33PM +0100, Borislav Petkov wrote:
> On Tue, Feb 05, 2013 at 05:22:06PM +0100, Borislav Petkov wrote:
> > On Tue, Feb 05, 2013 at 04:38:35PM +0100, Maarten Lankhorst wrote:
> > > Argh, next attempt, based on i915's Kconfig.
> > >
> > > It seems that not only I have to
On Tuesday 16 April 2013, Nishanth Menon wrote:
> On 12:50-20130416, Arnd Bergmann wrote:
> > On Tuesday 16 April 2013 12:48:28 Paul Sokolovsky wrote:
> > > > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> > > > index 8d1e2bb..73a99e4 100644
> > > > --- a/include/uapi/drm/drm.h
> >
On Wed, Apr 17, 2013 at 6:43 AM, Arnd Bergmann wrote:
>> drivers/scsi/aic7xxx/aicasm/aicasm_symbol.c:#ifdef __linux__
>> drivers/scsi/aic7xxx/aicasm/aicasm_symbol.h:#ifdef __linux__
>> drivers/scsi/dpt/osd_defs.h:#if (defined(__linux__))
>> drivers/staging/ced1401/machine.h:#if (defined(__linux__)
On 04/12/2013 01:38 PM, Bjorn Helgaas wrote:
> On Thu, Apr 11, 2013 at 7:13 AM, Lucas Kannebley Tavares
> wrote:
>> radeon currently uses a drm function to get the speed capabilities for
>> the bus. However, this is a non-standard method of performing this
>> detection and this patch changes it t
On 04/15/2013 02:00 AM, Michael Ellerman wrote:
> On Thu, Apr 11, 2013 at 10:13:13AM -0300, Lucas Kannebley Tavares wrote:
>> On pseries machines the detection for max_bus_speed should be done
>> through an OpenFirmware property. This patch adds a function to perform this
>> detection and a hook to
On 04/15/2013 08:42 AM, Michael Ellerman wrote:
> On Thu, Apr 11, 2013 at 10:13:13AM -0300, Lucas Kannebley Tavares wrote:
>> On pseries machines the detection for max_bus_speed should be done
>> through an OpenFirmware property. This patch adds a function to perform this
>> detection and a hook to
On Tue, 2013-04-16 at 12:50 +0200, Arnd Bergmann wrote:
> On Tuesday 16 April 2013 12:48:28 Paul Sokolovsky wrote:
> > > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> > > index 8d1e2bb..73a99e4 100644
> > > --- a/include/uapi/drm/drm.h
> > > +++ b/include/uapi/drm/drm.h
> > > @@ -3
On Wed, 2013-04-17 at 10:21 +0200, Daniel Vetter wrote:
> On Wed, Apr 17, 2013 at 02:38:02PM +1000, Dave Airlie wrote:
> > Currently we have a problem with this:
> > 1. i915: create gem object
> > 2. i915: export gem object to prime
> > 3. radeon: import gem object
> > 4. close prime fd
> > 5. rade
the story from being in the Khronos meetings.
--
You 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/20130417/3e318931/attachment.html>
From: Ville Syrj?l?
Instead of locking all modeset locks during plane updates, use just
a single CRTC mutex. To make that work, track the CRTC that "owns"
the plane currently. During enable/update that means the new
CRTC, and during disable it means the old CRTC.
Since the plane state is no long
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130417/9f8cac0d/attachment.html>
This series attempts to make our CEA mode matching recognize both the
60Hz and 59.94Hz variants of the modes (and similarly for 24/23.97,
30/29.97, etc.).
The benefits should include:
- Send the correct VIC in the AVI infoframe
- Pick the correct RGB quantization range in automatic mode
From: Ville Syrj?l?
No need to zero initialize .vrefresh in DRM_MODE() since it's using
desgignated initializers.
This will also avoid some duplicate initialization warnings later.
Signed-off-by: Ville Syrj?l?
---
include/drm/drm_crtc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
From: Ville Syrj?l?
drm_mode_equal_no_clocks() is like drm_mode_equal() except it doesn't
compare the clock or vrefresh values. drm_mode_equal() is now
implemented by first doing the clock checks, and then calling
drm_mode_equal_no_clocks().
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/drm
From: Ville Syrj?l?
Well have use for the vrefresh information of CEA modes later. Just
populate the information into the table to avoid having to calculate
it.
I'm too lazy to check if someone relies on newly allocated CEA
modes having 0 vrefresh, so just clear vrefresh back to 0 when
adding th
From: Ville Syrj?l?
drm_match_cea_mode() should be able to match both the 60Hz version,
and the 59.94Hz version of modes.
We only store one pixel clock value per mode in edid_cea_modes, so the
other value must be calculated. Depending on the mode, edid_cea_modes
contains the pixel clock for eith
On Wed, Apr 17, 2013 at 08:04:52PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> Instead of locking all modeset locks during plane updates, use just
> a single CRTC mutex. To make that work, track the CRTC that "owns"
> the plane currently. During enable/update that me
tachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130417/d26336f4/attachment.html>
should fail to compile because it contains an invalid
character. :)
--
You 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/20130417/6fee35f4/attachment.html>
On Wed, Apr 10, 2013 at 12:28 AM, Steven Rostedt wrote:
> On Thu, Apr 04, 2013 at 06:41:02PM +0200, Peter Zijlstra wrote:
>> On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
>> > The thing is now that you're not expected to hold these locks for a
>> > long
>> > time - if you need to synchro
From: Ville Syrj?l?
libkms only has the xrgb format, so we're overallocating the bo by
quite a lot in some cases. But we still need to get the pitch from the
libkms since it's the driver that decides how to align it.
Signed-off-by: Ville Syrj?l?
---
tests/modetest/buffers.c | 34 ++
From: Ville Syrj?l?
Signed-off-by: Ville Syrj?l?
---
tests/modetest/modetest.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index c91bb9d..27cd2ce 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modet
From: Ville Syrj?l?
Signed-off-by: Ville Syrj?l?
---
tests/modetest/buffers.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
index 5086381..6b117b4 100644
--- a/tests/modetest/buffers.c
+++ b/tests/modetest/buffer
From: Ville Syrj?l?
Signed-off-by: Ville Syrj?l?
---
tests/modetest/buffers.c | 120 +--
1 file changed, 115 insertions(+), 5 deletions(-)
diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
index 7f534a1..3b1685c 100644
--- a/tests/mode
From: Ville Syrj?l?
Spelling out eDP or DP make for a ridicilously long string which plays
havoc with formatting. Just say eDP or DP.
Signed-off-by: Ville Syrj?l?
---
tests/modetest/modetest.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/modetest/modetest.c b/t
Hi
2013/4/17 :
> From: Ville Syrj?l?
>
> drm_mode_equal_no_clocks() is like drm_mode_equal() except it doesn't
> compare the clock or vrefresh values. drm_mode_equal() is now
> implemented by first doing the clock checks, and then calling
> drm_mode_equal_no_clocks().
>
> Signed-off-by: Ville Sy
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130417/bef34017/attachment.html>
On Wed, Apr 17, 2013 at 8:38 AM, Lucas Kannebley Tavares
wrote:
> On 04/12/2013 01:38 PM, Bjorn Helgaas wrote:
>>
>> On Thu, Apr 11, 2013 at 7:13 AM, Lucas Kannebley Tavares
>> wrote:
>>>
>>> radeon currently uses a drm function to get the speed capabilities for
>>> the bus. However, this is a n
On Wed, Apr 17, 2013 at 2:04 PM, Alex Deucher wrote:
> On Wed, Apr 17, 2013 at 8:38 AM, Lucas Kannebley Tavares
> wrote:
>> On 04/12/2013 01:38 PM, Bjorn Helgaas wrote:
>>>
>>> On Thu, Apr 11, 2013 at 7:13 AM, Lucas Kannebley Tavares
>>> wrote:
radeon currently uses a drm function to
On Wed, Apr 17, 2013 at 4:11 PM, Bjorn Helgaas wrote:
> On Wed, Apr 17, 2013 at 2:04 PM, Alex Deucher
> wrote:
>> On Wed, Apr 17, 2013 at 8:38 AM, Lucas Kannebley Tavares
>> wrote:
>>> On 04/12/2013 01:38 PM, Bjorn Helgaas wrote:
On Thu, Apr 11, 2013 at 7:13 AM, Lucas Kannebley Tavare
1 - 100 of 121 matches
Mail list logo
