Hello Gustavo!
Gustavo Padovan wrote:
> Hi Tobias,
>
> 2015-04-15 Tobias Jakobi :
>
>> This struct encapsulates the configuration for a plane
>> object. The pixel format config is currently unused.
>>
>> Signed-off-by: Tobias Jakobi
>> ---
>> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 17
Gustavo Padovan wrote:
> Hi Tobias,
>
> 2015-04-15 Tobias Jakobi :
>
>> Signed-off-by: Tobias Jakobi
>
> I think you mean "unused" in the commit subject. And would also be good to
> have some commit message as well. Other than that:
Right, I'm going to change that and respin the series!
With
No component of Exynos DRM uses this field. Perhaps it was
once meant to provide more fine-grained information in
addition to the status stored in the 'enabled' field.
Reviewed-by: Gustavo Padovan
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 --
1 file changed,
Move the defines for the pixelformats that the mixer supports out
of mixer_graph_buffer() to the top of the source.
Also add handling of RGB565 and exit if the pixelformat is not
supported.
Reviewed-by: Gustavo Padovan
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 24
Hello,
I've dropped the remaining patches. Going to resend them once Gustavo's
cleanups have landed.
So this leaves just the small fry. Series is still based on [1].
With best wishes,
Tobias
[1] http://www.spinics.net/lists/linux-samsung-soc/msg43103.html
P.S.: I'm not sure if the two
On 04/15/2015 05:26 PM, Mario Kleiner wrote:
> A couple of questions to educate me and one review comment.
>
> On 04/15/2015 07:34 PM, Daniel Vetter wrote:
>> This was a bit too much cargo-culted, so lets make it solid:
>> - vblank->count doesn't need to be an atomic, writes are always done
>>
ext part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/5010926f/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=96361
--- Comment #5 from servuswiegehtz at yahoo.de ---
is there anything else I can provide? logs, try some modified kernels etc?
--
You are receiving this mail because:
You are watching the assignee of the bug.
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/845ced9d/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=96721
Bug ID: 96721
Summary: radeon: unable to handle kernel paging request with
counter strike: go
Product: Drivers
Version: 2.5
Kernel Version: 4.0
Hardware: All
This was a bit too much cargo-culted, so lets make it solid:
- vblank->count doesn't need to be an atomic, writes are always done
under the protection of dev->vblank_time_lock. Switch to an unsigned
long instead and update comments. Note that atomic_read is just a
normal read of a volatile
On Wed, Apr 15, 2015 at 09:00:04AM -0400, Peter Hurley wrote:
> Hi Daniel,
>
> On 04/15/2015 03:17 AM, Daniel Vetter wrote:
> > This was a bit too much cargo-culted, so lets make it solid:
> > - vblank->count doesn't need to be an atomic, writes are always done
> > under the protection of
On Wed, Apr 15, 2015 at 07:34:43PM +0200, Daniel Vetter wrote:
> This was a bit too much cargo-culted, so lets make it solid:
> - vblank->count doesn't need to be an atomic, writes are always done
> under the protection of dev->vblank_time_lock. Switch to an unsigned
> long instead and update
On 04/02/15 01:20, Russell King - ARM Linux wrote:
> This is where the DRM model is weak - we don't really have a way to
> say "this is the set of CRTCs which/can/ be associated with this
> connector, can any of the CRTCs accept this mode?" and eliminate
> modes which fail that check.
>
> This
On Wed, Apr 15, 2015 at 02:24:14PM +, Xie, William wrote:
> Oh, I tried it on BDW.
> So we need to use other way to scale the video to full screen?
Yes, unfortunately.
>
> William
>
>
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com]
> Sent:
errors, rerun with: -v
==5476== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
--
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-de
2015-04-15 14:15 GMT-03:00 Todd Previte :
> Displayport compliance test 4.2.2.6 requires that a source device be capable
> of
> detecting a corrupt EDID. The test specification states that the sink device
> sets up the EDID with an invalid checksum. To do this, the sink sets up an
> invalid EDID
The mixer natively support RGB565, ARGB and ARGB1555
so expose these formats. Also, since being of 16-bit size,
these formats have a lower bandwidth requirement, making
them useful in situations where this is a bottleneck.
Signed-off-by: Tobias Jakobi
---
The mixer itself can't handle 'video' formats like NV12 or
NV21. It needs the VP (video processor) for this task.
With the previous patch we ensure that DRM planes with
a NV12 format can only be created when this setup is
supported. Hence the check now reduces to checking the
pixel format
Currently the pixel formats that are supported by a plane
object are hard-coded to three entries.
This is not correct since depending on the particular
hardware block (DECON7, FIMD, VP, etc.) the supported
formats are different.
Let each block specify its own list of formats.
Signed-off-by:
This struct encapsulates the configuration for a plane
object. The pixel format config is currently unused.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 17 ++---
drivers/gpu/drm/exynos/exynos_drm_drv.h| 19 +++
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 6a849cf..4c14a89 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++
Move the defines for the pixelformats that the mixer supports out
of mixer_graph_buffer() to the top of the source.
Also add handling of RGB565 and exit if the pixelformat is not
supported.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_mixer.c | 24 ++--
1
Hello,
this is an attempt to somewhat improve the handling for supported
pixel formats in the Exynos DRM. Currently DRM planes are always
created with XRGB, ARGB and NV12 as supported formats,
even though the formats depend on the 'consumer' (mixer, FIMD,
video processor, etc.).
This
Hi Tobias,
2015-04-15 Tobias Jakobi :
> Hello Gustavo!
>
> Gustavo Padovan wrote:
> > Hi Tobias,
> >
> > 2015-04-15 Tobias Jakobi :
> >
> >> This struct encapsulates the configuration for a plane
> >> object. The pixel format config is currently unused.
> >>
> >> Signed-off-by: Tobias Jakobi
Signed-off-by: Hai Li
---
Documentation/devicetree/bindings/drm/msm/edp.txt | 61 +++
1 file changed, 61 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/msm/edp.txt
diff --git a/Documentation/devicetree/bindings/drm/msm/edp.txt
Signed-off-by: Hai Li
---
Documentation/devicetree/bindings/drm/msm/dsi.txt | 97 +++
1 file changed, 97 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/msm/dsi.txt
diff --git a/Documentation/devicetree/bindings/drm/msm/dsi.txt
Hi Tobias,
2015-04-15 Tobias Jakobi :
> This struct encapsulates the configuration for a plane
> object. The pixel format config is currently unused.
>
> Signed-off-by: Tobias Jakobi
> ---
> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 17 ++---
>
On 15.04.2015 02:41, Mario Kleiner wrote:
> For a kms driver to support immediate disable of vblank
> irq's reliably without introducing off by one errors or
> other mayhem for clients, it must not only support a
> hardware vblank counter query, but also high precision
> vblank timestamping, so
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/9e128c89/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/68b5efc6/attachment.html>
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Sonika Jindal
---
Documentation/DocBook/drm.tmpl |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index f4976cd..266d50a 100644
---
Hi Tobias,
2015-04-15 Tobias Jakobi :
> Signed-off-by: Tobias Jakobi
I think you mean "unused" in the commit subject. And would also be good to
have some commit message as well. Other than that:
Reviewed-by: Gustavo Padovan
Gustavo
Hi Tobias,
2015-04-15 Tobias Jakobi :
> Move the defines for the pixelformats that the mixer supports out
> of mixer_graph_buffer() to the top of the source.
> Also add handling of RGB565 and exit if the pixelformat is not
> supported.
>
> Signed-off-by: Tobias Jakobi
> ---
>
||
--
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/20150415/5a455d4f/attachment.html>
Hi Dave -
As promised, here's a batch of fixes for drm-next/4.1.
BR,
Jani.
The following changes since commit 6e0aa8018f9c676b115b7ca6c20a056fc57c68a9:
Merge tag 'v4.0-rc6' into drm-intel-next (2015-03-30 16:37:08 +0200)
are available in the git repository at:
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/2bb93f98/attachment.html>
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/c5c6fdcd/attachment.html>
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/1f6d4ba4/attachment.html>
Displayport compliance test 4.2.2.6 requires that a source device be capable of
detecting a corrupt EDID. The test specification states that the sink device
sets up the EDID with an invalid checksum. To do this, the sink sets up an
invalid EDID header, expecting the source device to generate the
On 4/15/2015 1:25 PM, Paulo Zanoni wrote:
> 2015-04-15 14:15 GMT-03:00 Todd Previte :
>> Displayport compliance test 4.2.2.6 requires that a source device be capable
>> of
>> detecting a corrupt EDID. The test specification states that the sink device
>> sets up the EDID with an invalid
https://bugs.freedesktop.org/show_bug.cgi?id=89971
--- Comment #9 from Adrian Gabor ---
Comment on attachment 115000
--> https://bugs.freedesktop.org/attachment.cgi?id=115000
dmesg
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00]
ext part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/64106d75/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/d7d0d42c/attachment.html>
Oh, I tried it on BDW.
So we need to use other way to scale the video to full screen?
William
-Original Message-
From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
Sent: Wednesday, April 15, 2015 7:23 PM
To: Xie, William
Cc: DRI Development
Subject: Re: Help on
On Wed, Apr 15, 2015 at 08:49:39AM +, Xie, William wrote:
> To make it more specific,
>
> For example:
> 1: video frame size is 1280x720,
> 2: screen resolution is 3200x1800,
>
> How can I set crtc and src parameters?
>
> 1: crtc (0, 0, 3200, 1800) src (0, 0, 3200<<16, 1800<<16)
> 2: crtc
Hi Dave,
One more drm-misch pull for 4.1 with mostly simple stuff and boring
refactoring. Even the cursor fix from Matt is just to make a really anal
igt happy.
Cheers, Daniel
The following changes since commit 502e95c6678505474f1056480310cd9382bacbac:
drm/vgem: implement virtual GEM
On 14.04.2015 23:21, Chris Wilson wrote:
> On Tue, Apr 14, 2015 at 06:42:03PM +0900, Michel Dänzer wrote:
>> Also, the two patches should have different and more specific shortlogs.
>
> Second patch:
>
> drm: Query vblank counters directly for known accurate state
>
> ?
Sounds good to me.
This was a bit too much cargo-culted, so lets make it solid:
- vblank->count doesn't need to be an atomic, writes are always done
under the protection of dev->vblank_time_lock. Switch to an unsigned
long instead and update comments. Note that atomic_read is just a
normal read of a volatile
On Wed, Apr 15, 2015 at 09:17:03AM +0100, Chris Wilson wrote:
> On Wed, Apr 15, 2015 at 09:17:02AM +0200, Daniel Vetter wrote:
> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > index c8a34476570a..23bfbc61a494 100644
> > --- a/drivers/gpu/drm/drm_irq.c
> > +++
On Wed, Apr 15, 2015 at 11:25:00AM +0200, Daniel Vetter wrote:
> On Wed, Apr 15, 2015 at 09:17:03AM +0100, Chris Wilson wrote:
> > On Wed, Apr 15, 2015 at 09:17:02AM +0200, Daniel Vetter wrote:
> > > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > > index
On 2015ë
04ì 10ì¼ 14:55, Hyungwon Hwang wrote:
> This patch renames pll_clk to sclk_clk. The clock referenced by pll_clk
> is actually not the pll input clock for dsi. The pll input clock comes
> from the board's oscillator directly.
>
> Signed-off-by: Hyungwon Hwang
> ---
> Changes for v3:
Displayport compliance test 4.2.2.6 requires that a source device be capable of
detecting a corrupt EDID. The test specification states that the sink device
sets up the EDID with an invalid checksum. To do this, the sink sets up an
invalid EDID header, expecting the source device to generate the
,
Christian.
--
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/20150415/bb60b427/attachment.html>
Hi Stefan,
> -Original Message-
> From: Stefan Agner [mailto:stefan at agner.ch]
> Sent: Wednesday, April 08, 2015 3:57 PM
> To: Wang Jianwei-B52261
> Cc: Wood Scott-B07421; airlied at linux.ie; dri-devel at
> lists.freedesktop.org;
> devicetree at vger.kernel.org; Xiubo Li; Wang
On Wed, Apr 15, 2015 at 09:17:02AM +0200, Daniel Vetter wrote:
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index c8a34476570a..23bfbc61a494 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -74,6 +74,33 @@ module_param_named(vblankoffdelay,
This was a bit too much cargo-culted, so lets make it solid:
- vblank->count doesn't need to be an atomic, writes are always done
under the protection of dev->vblank_time_lock. Switch to an unsigned
long instead and update comments. Note that atomic_read is just a
normal read of a volatile
Hi Daniel,
On 04/15/2015 03:17 AM, Daniel Vetter wrote:
> This was a bit too much cargo-culted, so lets make it solid:
> - vblank->count doesn't need to be an atomic, writes are always done
> under the protection of dev->vblank_time_lock. Switch to an unsigned
> long instead and update
uint32_t src_w, uint32_t src_h)
My problem is, whatever value I set, the video is not full screen mode,
Anything I missed?
Thanks
William
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/a
hives/dri-devel/attachments/20150415/ac48b60e/attachment.html>
The debug message is missing a newline at the end and it makes the
logs hard to read when a device defers a lot. Simple 2-character fix
adds the newline at the end.
Signed-off-by: Todd Previte
Cc: dri-devel at lists.freedesktop.org
Reviewed-by: Paulo Zanoni
Reviewed-by: Alex Deucher
---
For test 4.2.2.5 to pass per the Link CTS Core 1.2 rev1.1 spec, the source
device must attempt at least 7 times to read the EDID when it receives an
I2C defer. The normal DRM code makes only 7 retries, regardless of whether
or not the response is a native defer or an I2C defer. Test 4.2.2.5 fails
Displayport compliance test 4.2.2.6 requires that a source device be capable of
detecting a corrupt EDID. The test specification states that the sink device
sets up the EDID with an invalid checksum. To do this, the sink sets up an
invalid EDID header, expecting the source device to generate the
On Tue, Apr 14, 2015 at 08:43:12PM +0200, Mario Kleiner wrote:
> On 04/05/2015 05:40 PM, Chris Wilson wrote:
> >Bypass all the spinlocks and return the last timestamp and counter from
> >the last vblank if the driver delcares that it is accurate (and stable
> >across on/off), and the vblank is
?
Thanks
William
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/da829596/attachment.html>
Hi.
It's a generic interface for stuff that needs to be global across all
devices. Currently I think it's only used for
ttm memory accounting.
Thanks,
Thomas
On 04/15/2015 07:13 AM, z f wrote:
> hi, I am start reading the DRM code in Linux.
> drm_core_init() -> drm_global_init()
> the later
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/20150415/779661c6/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150415/3420ba08/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/46749d31/attachment.html>
TV is plugged in.
--
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/20150415/89f283a8/attachment.html>
chment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150415/f2e9fd1b/attachment.html>
ect initial domain for shared resources
Weird. Marek, any ideas?
--
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/20150415/3f7cd281/attachment.html>
On 04/02/2015 01:34 PM, Chris Wilson wrote:
> On vblank instant-off systems, we can get into a situation where the cost
> of enabling and disabling the vblank IRQ around a drmWaitVblank query
> dominates. However, we know that if the user wants the current vblank
> counter, they are also very
On 13/04/2015 02:42, Alex Deucher wrote:
> On Sat, Apr 11, 2015 at 5:52 AM, Martin Peres wrote:
>> On 05/02/2015 11:49, Christian König wrote:
>>> Am 04.02.2015 um 23:27 schrieb Alex Deucher:
0-255 seems to be the preferred range for the pwm interface.
Signed-off-by: Alex Deucher
On 4/13/15 3:18 PM, Paulo Zanoni wrote:
> 2015-04-13 11:53 GMT-03:00 Todd Previte :
>> Displayport compliance test 4.2.2.6 requires that a source device be capable
>> of
>> detecting a corrupt EDID. The test specification states that the sink device
>> sets up the EDID with an invalid checksum.
75 matches
Mail list logo
