the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150327/2920f885/attachment.html>
https://bugs.freedesktop.org/show_bug.cgi?id=89734
--- Comment #7 from poub365-bugzilla at yahoo.com ---
This is what I did (main commands)
git clone git://kernel.ubuntu.com/ubuntu/ubuntu-vivid.git
patch -p1
http://lists.freedesktop.org/archives/dri-devel/attachments/20150327/38379207
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150327/2c02e866/attachment.html>
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150327/9d286c68/attachment.html>
Hello Krzysztof,
On 03/27/2015 05:08 PM, Krzysztof Kozlowski wrote:
> After adding display power domain for Exynos5250 in commit
> 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the
> display on Chromebook Snow and others stopped working after boot.
>
> The reason for this sug
On Fri, Mar 27, 2015 at 07:40:43PM +0200, Tommi Rantala wrote:
> 2015-03-27 18:42 GMT+02:00 Jani Nikula :
> > On Fri, 27 Mar 2015, Daniel Vetter wrote:
> >> On Fri, Mar 27, 2015 at 09:10:02AM +0100, Daniel Vetter wrote:
> >>> It's completely unused and Tommi noticed that the #define is borked
> >>
2015-03-27 18:42 GMT+02:00 Jani Nikula :
> On Fri, 27 Mar 2015, Daniel Vetter wrote:
>> On Fri, Mar 27, 2015 at 09:10:02AM +0100, Daniel Vetter wrote:
>>> It's completely unused and Tommi noticed that the #define is borked
>>> since forever. I've done a git search in userspace and only found
>>> b
drivers/gpu/drm/i915/i915_gem_gtt.c:1349:1-4: WARNING: end returns can be
simpified and declaration on line 1347 can be dropped
Simplify a trivial if-return sequence. Possibly combine with a
preceding function call.
Generated by: scripts/coccinelle/misc/simple_return.cocci
CC: Michel Thierry
game works on Intel,
Nvidia (blob), and OSX drivers if it has broken GLSL shaders.
--
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/attach
On Fri, 27 Mar 2015, Daniel Vetter wrote:
> On Fri, Mar 27, 2015 at 09:10:02AM +0100, Daniel Vetter wrote:
>> It's completely unused and Tommi noticed that the #define is borked
>> since forever. I've done a git search in userspace and only found
>> broken definitions and no users anywhere.
>>
>>
On Fri, 27 Mar 2015, Alex Deucher wrote:
> On Fri, Mar 27, 2015 at 8:08 AM, Jani Nikula wrote:
>> On Thu, 26 Mar 2015, Daniel Vetter wrote:
>>> On Thu, Mar 26, 2015 at 10:42:00AM +0200, Jani Nikula wrote:
If the user supplies EDID through firmware or debugfs override, the
driver callba
Hello Daniel Vetter,
This is a semi-automatic email about new static checker warnings.
The patch 76b58b03806b: "drm/atomic-helpers: Properly avoid full
modeset dance" from Mar 26, 2015, leads to the following Smatch
complaint:
drivers/gpu/drm/drm_atomic_helper.c:615 disable_outputs()
After adding display power domain for Exynos5250 in commit
2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the
display on Chromebook Snow and others stopped working after boot.
The reason for this suggested Andrzej Hajda: the DP clock was disabled.
This clock is required by Disp
After adding display power domain for Exynos5250 in commit
2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the
display on Chromebook Snow and others stopped working after boot.
The reason for this suggested Andrzej Hajda: the DP clock was disabled.
This clock is required by Disp
On Fri, Mar 27, 2015 at 05:33:00PM +0300, Dan Carpenter wrote:
> Hello Daniel Vetter,
>
> This is a semi-automatic email about new static checker warnings.
>
> The patch 76b58b03806b: "drm/atomic-helpers: Properly avoid full
> modeset dance" from Mar 26, 2015, leads to the following Smatch
> co
On Fri, Mar 27, 2015 at 03:51:54PM +0200, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> In response to a recently noticed fumble with some i915 ioctls, I
> proceeded to read the ioctl code again and didn't really like what
> I saw. So I tried to clean it up a bit to make it
From: Ville Syrjälä
Use the same logic when checking for valid ioctl range in
drm_ioctl_flags() that is used in drm_ioctl() to avoid
confusion.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_ioctl.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/dri
From: Ville Syrjälä
Use max() to make the code to determine the allocation size for
the ioctl data easier to read.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_ioctl.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu
From: Ville Syrjälä
Now that cmd_drv is gone the handling for core and driver ioctls is
mostly identical, so eliminate the duplication. Also take the
opportunity to simplify the range checks to be less cluttered.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_ioctl.c | 39 +++
From: Ville Syrjälä
DRM_IOCTL_DEF_DRV is now identical to VMW_IOCTL_DEF (apart from the
.name assignment), so just replace the use of the latter with the former.
With .name now assigned this should also make decoding kernel logs a
bit easier.
Cc: Jakob Bornecrantz
Cc: Thomas Hellstrom
Signe
From: Ville Syrjälä
ioctl->cmd_drv is pointless and we can just as well stick the full ioctl
definition into ioctl->cmd.
Cc: Jakob Bornecrantz
Cc: Thomas Hellstrom
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_ioctl.c | 6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 4 ++-
From: Ville Syrjälä
Currently DRM_IOCTL_DEF_DRV does '[DRM_IOCTL_NR(DRM_##ioctl)]' which
doesn't make much sense since DRM_##ioctl is already a the raw ioctl
number. So change it to 'DRM_IOCTL_NR(DRM_IOCTL_##ioctl) - DRM_COMMAND_BASE'
which means the DRM_IOCTL_NR() now makes sense, and also thi
From: Ville Syrjälä
In response to a recently noticed fumble with some i915 ioctls, I
proceeded to read the ioctl code again and didn't really like what
I saw. So I tried to clean it up a bit to make it less confusing.
grep also tells me the drm_ioctl pattern has been dutifully copied
into amd
Hi Ville,
On 27 March 2015 at 13:51, wrote:
> From: Ville Syrjälä
>
> Currently DRM_IOCTL_DEF_DRV does '[DRM_IOCTL_NR(DRM_##ioctl)]' which
> doesn't make much sense since DRM_##ioctl is already a the raw ioctl
> number. So change it to 'DRM_IOCTL_NR(DRM_IOCTL_##ioctl) - DRM_COMMAND_BASE'
> wh
On Fri, Mar 27, 2015 at 07:26:35PM +0800, kbuild test robot wrote:
> drivers/gpu/drm/i915/i915_gem_gtt.c:1349:1-4: WARNING: end returns can be
> simpified and declaration on line 1347 can be dropped
>
> Simplify a trivial if-return sequence. Possibly combine with a
> preceding function call.
>
Legacy setCrtc has a nice fastpath for just updating the frontbuffer
when the output routing doesn't change. Which I of course tried to
keep working, except that I fumbled the job: The helpers correctly
compute ->mode_changed, CRTC updates get correctly skipped but
connector functions are called un
On Thu, 26 Mar 2015, Daniel Vetter wrote:
> On Thu, Mar 26, 2015 at 10:42:00AM +0200, Jani Nikula wrote:
>> If the user supplies EDID through firmware or debugfs override, the
>> driver callbacks are bypassed and the connector ELD does not get
>> updated, and audio fails. Set ELD for firmware and
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150327/df99ccdd/attachment.html>
u 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/20150327/c1d28922/attachment.html>
btw, if no one has a problem with this, I can include it with msm pull
req when I send that.. one way or another we need it prior to the msm
dsi patches
BR,
-R
On Fri, Mar 27, 2015 at 1:04 PM, Rob Clark wrote:
> Normally these are called from within drm core, from the EDID parsing
> code. But
Normally these are called from within drm core, from the EDID parsing
code. But for dual-dsi in some drivers (at least drm/msm) we need to
call these from the driver. So they should be exported.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_crtc.c | 2 ++
1 file changed, 2 insertions(+)
di
From: Gustavo Padovan
Now that no one is using the functions exported by exynos_drm_plane due
to the atomic conversion we can make remove some of the them or make them
static.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 91 +--
dri
From: Gustavo Padovan
PageFlips now use the atomic helper to work through the atomic modesetting
API. Async page flips are not supported yet.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 63 +---
drivers/gpu/drm/exynos/exynos_drm_fb.
From: Gustavo Padovan
Now that phase 1 and 2 are complete switch .set_config helper to
use the atomic one.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b
From: Gustavo Padovan
Now that phase 1 and 2 are complete we can switch the update/disable_plane
callbacks to their atomic version.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_fb.c| 3 +++
drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 ++--
2 files changed, 5 inser
From: Gustavo Padovan
Use drm_atomic_set_fb_for_plane() in the legacy page_flip path to keep
track of the framebuffer pointer and reference.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/exynos
From: Gustavo Padovan
Set CRTC, planes and connectors to use the default implementations from
the atomic helper library. The helpers will work to keep track of state
for each DRM object.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/bridge/ptn3460.c | 4
drivers/gpu/drm/
From: Gustavo Padovan
The new atomic infrastructure needs the .mode_set_nofb() callback to
update CRTC timings before setting any plane.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 60 +---
1 file changed, 9 insertions(+), 51 deleti
From: Gustavo Padovan
The atomic helper to disable planes also uses the optional
.atomic_disable() helper. The unique operation it does is calling
.win_disable()
exynos_drm_fb_get_buf_cnt() needs a fb check too to avoid a null pointer.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos
From: Gustavo Padovan
Rip out the check from exynos_update_plane() and create
exynos_check_plane() for the check phase enabling use to use
the atomic helpers to call our check and update phases when updating
planes.
Update all users of exynos_update_plane() accordingly to call
exynos_check_plane
From: Gustavo Padovan
Hi,
Here goes the full support for atomic modesetting on exynos. I've
split the patches in the various phases of atomic support.
These patches sits on top of the clean up patches I've sent yesterday
to this mailing list[1].
Gustavo
[1] http://lists.freedesktop.or
2015-03-27 Daniel Vetter :
> Legacy setCrtc has a nice fastpath for just updating the frontbuffer
> when the output routing doesn't change. Which I of course tried to
> keep working, except that I fumbled the job: The helpers correctly
> compute ->mode_changed, CRTC updates get correctly skipped b
From: Thierry Reding
Instead of duplicating the code, make use of the newly introduced atomic
state duplicate and destroy helpers. This allows changes to the base
atomic state handling to automatically propagate to the Tegra driver and
thereby prevent breakage resulting from both copies going out
From: Thierry Reding
Drivers that subclass CRTC, plane or connector state need to carefully
duplicate the code that the atomic helpers have. This is bound to cause
breakage eventually because it requires auditing all drivers and update
them when code is added to the helpers.
In order to avoid th
amp; install
--
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/20150327/9b82cac0/attachment.html>
On Fri, Mar 27, 2015 at 12:02 PM, Jani Nikula wrote:
> On Fri, 27 Mar 2015, Alex Deucher wrote:
>> On Fri, Mar 27, 2015 at 8:08 AM, Jani Nikula
>> wrote:
>>> On Thu, 26 Mar 2015, Daniel Vetter wrote:
On Thu, Mar 26, 2015 at 10:42:00AM +0200, Jani Nikula wrote:
> If the user supplies E
On 27 March 2015 at 08:10, Daniel Vetter wrote:
> It's completely unused and Tommi noticed that the #define is borked
> since forever. I've done a git search in userspace and only found
> broken definitions and no users anywhere.
>
With this said, have you seen any userspace that uses the uapi/drm
Hello Inki,
On Fri, Mar 27, 2015 at 2:47 AM, Inki Dae wrote:
>
> Right, this is not documented but if you have ever checked exynos drm
> driver tree, then I think you could know how we use the prefix. Of
> course, I don't like to force the use of this prefix but if you and
> other people use pref
Patch derived from one from Yakir Yang. Yakir Yang says:
For Designerware HDMI, the following write sequence is recommended:
1. aud_n3 (set bit ncts_atomic_write if desired)
2. aud_cts3 (set CTS_manual and CTS value if desired/enabled)
3. aud_cts2 (required in CTS_manual)
4. aud_cts1 (required in
The HDMI n/cts settings need to be updated whenever the audio sample
rate or the video pixel clock changes. This needs to be protected
against concurrency as there is no synchronisation between these two
operations. Introduce a mutex (called audio_mutex) to protect against
two threads trying to u
Combine these two functions into a single implementation. These two
functions are called consecutively anyway. Idea from a patch by
Yakir Yang.
Signed-off-by: Russell King
---
drivers/gpu/drm/bridge/dw_hdmi.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a
All,
This is a mini-series to try and move audio support for the Designware
HDMI bridge along.
There are two known versions of the Designware HDMI audio:
- The Rockchip version, which is based upon feeding the HDMI block I2S
stream(s), which doesn't have any on-board DMA support.
- The Freesca
cation/pgp-signature
Size: 818 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150327/8e66e3dc/attachment.sig>
Hi Daniel,
On 2015ë
03ì 26ì¼ 23:48, Daniel Stone wrote:
> Hi Inki,
>
> On Thu, 26 Mar, 2015 at 2:32 PM, Inki Dae wrote:
>> Applied.
>
> Thanks very much.
>
>> Could you use right prefix of the subject like below when you post patch?
>>
>> 'drm/exynos: ...', not 'drm: Exynos: ...'
>>
>> Yo
Hi Dave,
A few more fixes for 4.0 for radeon. Sorry for the delay, I was
a little under the weather this week and time got away from me.
The following changes since commit 9822393d23ba9129396ab9308dbb8ce10ae74751:
Merge tag 'drm-intel-fixes-2015-03-26' of
git://anongit.freedesktop.org/drm-in
On 2015ë
03ì 27ì¼ 09:15, Tobias Jakobi wrote:
> Inki Dae wrote:
>> Hello Javier,
>>
>> Applied.
>>
>> Could you use right prefix of the subject like below when you post patch?
>>
>> 'drm/exynos: ...', not 'drm: Exynos: ...'
>>
>> Your email will be filtered from my mailbox if you don't use the
On Fri, Mar 27, 2015 at 8:08 AM, Jani Nikula wrote:
> On Thu, 26 Mar 2015, Daniel Vetter wrote:
>> On Thu, Mar 26, 2015 at 10:42:00AM +0200, Jani Nikula wrote:
>>> If the user supplies EDID through firmware or debugfs override, the
>>> driver callbacks are bypassed and the connector ELD does not
Hi Tobias,
2015-03-27 Tobias Jakobi :
> Hello!
>
>
> Gustavo Padovan wrote:
> > I would keep calling these two vars x_ratio and y_ratio. I don't see a
> > reason
> > to change the name here.
> Right, I'm going to change this. Also I was thinking of basing the patch
> on your latest cleanup ser
Hi Mark,
On 2015å¹´03æ27æ¥ 02:16, Mark Brown wrote:
> On Sat, Feb 28, 2015 at 10:04:30PM -0500, Yakir Yang wrote:
>
>> +ret = snd_soc_dai_set_fmt(cpu_dai, dai_fmt);
>> +if (ret < 0) {
>> +dev_err(cpu_dai->dev, "failed to set cpu_dai fmt.\n");
>> +return ret;
>> +
On Fri, Mar 27, 2015 at 09:10:02AM +0100, Daniel Vetter wrote:
> It's completely unused and Tommi noticed that the #define is borked
> since forever. I've done a git search in userspace and only found
> broken definitions and no users anywhere.
>
> Cc: Tommi Rantala
> Signed-off-by: Daniel Vetter
It's completely unused and Tommi noticed that the #define is borked
since forever. I've done a git search in userspace and only found
broken definitions and no users anywhere.
Cc: Tommi Rantala
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 2 +-
drivers/gpu/drm/i915/in
Hi,
> >
> > Completely different thing crossing my mind: I think we can make
> > virtio-vga fully compatible with stdvga. stdvga has two bars, memory
> > (#0) and mmio (#2). We can make the mmio bar larger and place all the
> > virtio regions there.
> >
>
> Full compatibility with some sta
On Fri, Mar 27, 2015 at 08:39:56AM +0200, Jani Nikula wrote:
> On Thu, 26 Mar 2015, Tommi Rantala wrote:
> > Fix definition of the DRM_IOCTL_I915_GET_SPRITE_COLORKEY ioctl, so that it
> > is different from the DRM_IOCTL_I915_SET_SPRITE_COLORKEY ioctl.
> >
> > Signed-off-by: Tommi Rantala
>
> Who
On Thu, 26 Mar 2015, Tommi Rantala wrote:
> Fix definition of the DRM_IOCTL_I915_GET_SPRITE_COLORKEY ioctl, so that it
> is different from the DRM_IOCTL_I915_SET_SPRITE_COLORKEY ioctl.
>
> Signed-off-by: Tommi Rantala
Whoa. Broken since its introduction in
commit 8ea30864229e54b01ac0e9fe88c4b73
On 03/27/2015 01:04 AM, Daniel Vetter wrote:
> On Fri, Mar 27, 2015 at 08:39:56AM +0200, Jani Nikula wrote:
>> On Thu, 26 Mar 2015, Tommi Rantala wrote:
>>> Fix definition of the DRM_IOCTL_I915_GET_SPRITE_COLORKEY ioctl, so that it
>>> is different from the DRM_IOCTL_I915_SET_SPRITE_COLORKEY ioctl
On 03/26/2015 11:39 PM, Jani Nikula wrote:
> On Thu, 26 Mar 2015, Tommi Rantala wrote:
>> Fix definition of the DRM_IOCTL_I915_GET_SPRITE_COLORKEY ioctl, so that it
>> is different from the DRM_IOCTL_I915_SET_SPRITE_COLORKEY ioctl.
>>
>> Signed-off-by: Tommi Rantala
>
> Whoa. Broken since its in
Inki Dae wrote:
> Hello Javier,
>
> Applied.
>
> Could you use right prefix of the subject like below when you post patch?
>
> 'drm/exynos: ...', not 'drm: Exynos: ...'
>
> Your email will be filtered from my mailbox if you don't use the right
> prefix so I couldn't check and take care of your
nd attach that file here after the hang.
--
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/20150327/c5250a2a/attachment.html>
crubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150327/2230a325/attachment.html>
Hello!
Gustavo Padovan wrote:
> I would keep calling these two vars x_ratio and y_ratio. I don't see a reason
> to change the name here.
Right, I'm going to change this. Also I was thinking of basing the patch
on your latest cleanup series (the 'drm/exynos: remove struct *_win_data
abstraction on
On 24 March 2015 at 17:53, Connor Behan wrote:
> This one is a bit harder to notice.
>
Plus not so widely used any more :-)
Mildly related - with EXA support for the r128 ddx done for a while
now, do you have any plans on updating the dri module to dri2 ?
> Signed-off-by: Connor Behan
Reviewed-
71 matches
Mail list logo
