The valies are unsigned long, thus we should use %lu.
v2: Drop old printf statement. (Jan)
Signed-off-by: Emil Velikov
---
xf86drmHash.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xf86drmHash.c b/xf86drmHash.c
index 199a2a3..f287e61 100644
--- a/xf86drmHash.c
+++ b/
... and remove the useless SL_DEBUG and RANDOM_DEBUG
v2: Rebase on earlier changes.
Signed-off-by: Emil Velikov
---
xf86drmHash.c | 5 ++---
xf86drmRandom.c | 1 -
xf86drmSL.c | 1 -
3 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/xf86drmHash.c b/xf86drmHash.c
index f7d7f73
... and wire it up to make check
v2: s/rand - state->check/rand != state->check/. (Jan)
Signed-off-by: Emil Velikov
---
tests/Makefile.am | 6 +++---
tests/random.c| 6 --
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index e3443df.
With follow up commits we can clear it up and wire to
make check
v2:
- Use xf86drmRandom.h for common struct.(Jan)
- Add test to .gitignore.
Signed-off-by: Emil Velikov
---
.gitignore| 1 +
Makefile.sources | 1 +
tests/Makefile.am | 3 +-
tests/random.c| 118 ++
... and wire up to `make check' now that it's useful.
v2: Really return non-zero on failure.
Signed-off-by: Emil Velikov
---
tests/Makefile.am | 10 ++
tests/hash.c | 26 +++---
2 files changed, 21 insertions(+), 15 deletions(-)
diff --git a/tests/Makefile.am b
v2: Rebase on earlier changes. Keep count initialisation as is.
Signed-off-by: Emil Velikov
Reviewed-by: Jan Vesely
---
tests/hash.c | 90
1 file changed, 54 insertions(+), 36 deletions(-)
diff --git a/tests/hash.c b/tests/hash.c
ind
Get the test from completely broken to working like a charm.
- Use the same variable type for both HashInsert and HashLookup.
- Use correct storage type for the HashLookup return value.
- Remove useless backward iteration of HashLookup(i).
v2:
- Use void * instead of unsigned long.
- Change
This way with follow up commits we can fix it and wire it up to
make check
v2:
- Use xf86drmHash.h for common structs.(Jan)
- Add test to .gitignore.
Signed-off-by: Emil Velikov
---
.gitignore| 1 +
Makefile.sources | 1 +
tests/Makefile.am | 3 +-
tests/hash.c | 198 +
Hi Emil,
On Thu, Mar 26, 2015 at 11:12 PM, Emil Velikov
wrote:
>
> Hi Daniel,
> On 25/03/15 01:01, Daniel Kurtz wrote:
> > Unfortunately, there are some users of libdrm installed headers that like
> > to be built with -std=c89 -pedantic, which does not like "inline".
> >
> > However, __inline wo
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 patch.
Thanks,
Inki Dae
On 2015ë
://lists.freedesktop.org/archives/dri-devel/attachments/20150326/f2a9ddf3/attachment.html>
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
drivers/gpu/drm/i915/intel_pm.c:2913:4-5: Unneeded semicolon
Removes unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
CC: Tvrtko Ursulin
Signed-off-by: Fengguang Wu
---
intel_pm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/i915/
viewed-by: Emil Velikov
>
> Thanks !
> Emil
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150326/7ee67ef8/attachment-0001.sig>
Hello,
Trinity discovered oopses with the i915 colorkey ioctls, reproducible
on my system with this:
#include
#include
#include
#include
#include
#include
#include
#include
#define GET DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GET_SPRITE_COLORKEY,
struct drm_intel_sprite_colorkey)
int main(i
Hi Linus,
here is the complete set of i915 bug/warn/refcounting fixes.
Dave.
The following changes since commit 90a5a895cc8b284ac522757a01de15e36710c2b9:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2015-03-23
10:16:13 -0700)
are available in the git repository at:
git
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
---
include/uapi/drm/i915_drm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/drm/i915_drm.h
On some board, TE GPIO should be configured properly thoughout pinctrl driver
as an wakeup interrupt. So this gpio should be configurable in the board's DT,
not being requested as a input pin.
Signed-off-by: Hyungwon Hwang
---
Changes for v2:
- None
Changes for v3:
- None
drivers/gpu/drm/exy
MIC must be initilized by MIPI DSI when it is being bound.
Signed-off-by: Hyungwon Hwang
---
Changes for v2:
- None
Changes for v3:
- None
.../devicetree/bindings/video/exynos_dsim.txt | 23 ++---
drivers/gpu/drm/exynos/exynos_drm_dsi.c| 24 ++
This patch adds support for Exynos5433 mipi dsi.
Signed-off-by: Hyungwon Hwang
---
Changes for v2:
- change the author of "drm/exynos: dsi: add support for Exynos5433 SoC" to
Hyungwon Hwang by the previous author's will
Changes for v3:
- Separated from the patch "drm/exynos: dsi: add support f
This patch makes the driver use arrays for clocks, register address,
and values. By doing this, it becomes easier to add support for another
SoC.
Signed-off-by: Hyungwon Hwang
---
Changes for v3:
- Separated from the patch "drm/exynos: dsi: add support for Exynos5433 SoC"
in version 2.
drivers
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:
- Newly added
.../devicetree/bindings/video/exynos_dsim.txt
MIC(Mobile image compressor) is newly added IP in Exynos5433. MIC
resides between decon and mipi dsim, and compresses frame data by 50%.
With dsi, not display port, to send frame data to the panel, the
bandwidth is not enough. That is why this compressor is introduced.
Signed-off-by: Hyungwon Hwan
When there are multiple ports or multiple endpoints in a port, they have to be
distinguished by the value of reg property. It is common. The drivers can get
the specific endpoint in the specific port via this function. Now the drivers
have to implement this code in themselves or have to force the o
From: Joonyoung Shim
DECON(Display and Enhancement Controller) is new IP replacing FIMD in
Exynos5433. This patch adds Exynos5433 decon driver.
Signed-off-by: Joonyoung Shim
Signed-off-by: Hyungwon Hwang
---
Changes for v2:
- change file names and variable names of decon to represnt exynos543
This patchset is based on the git(branch name: exynos-drm-next) which is
maintained by Inki Dae.
https://kernel.googlesource.com/pub/scm/linux/kernel/git/...
This patchset adds 2 new device drivers, decon and mic, and adds support for
Exynos5433 mipi dsi. To enable display in a Exynos5433 board, d
Dear Daniel,
On Wed, 18 Mar 2015 09:52:33 +
Daniel Stone wrote:
> Hi,
>
> On 18 March 2015 at 08:16, Hyungwon Hwang
> wrote:
> > +#define REG(dsi, reg) ((dsi)->reg_base +
> > dsi->driver_data->regs[(reg)])
>
> This seems like a good change in general, but please split it up: it
> makes b
This change adds the support in mdp5 kms driver for single
and dual DSI. Dual DSI case depends on the framework API
and sequence change to support dual data path.
v1: Initial change
v2: Address Rob Clark's comment
- Separate command mode encoder to a new file mdp5_cmd_encoder.c
- Rebase to not dep
This change adds the DSI connector support in msm drm driver.
v1: Initial change
v2:
- Address comments from Archit + minor clean-ups
- Rebase to not depend on msm_drm_sub_dev change [Rob's comment]
Signed-off-by: Hai Li
---
drivers/gpu/drm/msm/Kconfig | 11 +
drivers/gpu/drm/msm/Ma
This change is to add an interface to MDP for connector devices
setting split display information.
Signed-off-by: Hai Li
---
drivers/gpu/drm/msm/msm_kms.h | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
index 3a78cb4..a9f17bd
This change is to make the content in construct_encoder reflect its
name.
Also, DSI connector may be connected to video mode or command mode
encoder, so that 2 different encoders need to be constructed for DSI.
Signed-off-by: Hai Li
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 89 ++
Resending initial MSM DSI patches
DSI is supported by both mdp4 and mdp5. This patch series adds the common DSI
controller driver and also enable it in mdp5.
Hai Li (4):
drm/msm/mdp5: Move *_modeset_init out of construct_encoder function
drm/msm: Add split display interface
drm/msm: Initial
Hello Randy
On 26/03/15 16:56, randyf at sibernet.com wrote:
>>
>> Was honestly hoping that patch #1 is not required as:
>> - Getting the drm.h header in sync with the kernel will be annoying.
>
> Indeed.
>
> I have a version of drm.h that works with Solaris and *should* still
> work with al
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150326/e573d738/attachment.html>
t; do you mean that when I take devm_snd_soc_register_card() to register card,
> then I do not need unregister card any more(destroy with device) ?
Yes, that is the whole point of the devm_ APIs.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
On Thu, Mar 26, 2015 at 04:07:16PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > I don't know. This seems exactly like the kind of thing
> > we had in mind when we added the virtio pci capability.
> > For example, we have text in spec that requires drivers
> > to skip unknown capabilities.
> >
> > An
> It's not about virtio at all. It's about vga compatibility, so we have
> a simple framebuffer as boot display. Only used when virtio is *not*
> enabled.
VGA can be a separate device altogether.
In fact there were *real* PCI graphics cards that did this and had a
register than flipped the outp
On 03/26/2015 at 07:32 AM, Xi Ruoyao wrote:
> On 03/26/2015 at 03:40 AM, Josh Boyer wrote:
>> drm-Fixup-racy-refcounting-in-plane_force_disable.patch
>> drm-i915-Don-t-try-to-reference-the-fb-in-get_initia.patch
>>
>> and this patch:
I hide the patch since it has been managled by Thunderbird.
(BT
aning to
add some gui to switch between gpus and choose what programms to run with which
gpu?
--
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/archiv
On Thu, Mar 26, 2015 at 10:30:21PM +0800, kbuild test robot wrote:
> drivers/gpu/drm/i915/intel_pm.c:2913:4-5: Unneeded semicolon
>
>
> Removes unneeded semicolon.
>
> Generated by: scripts/coccinelle/misc/semicolon.cocci
>
> CC: Tvrtko Ursulin
> Signed-off-by: Fengguang Wu
Oops, somehow di
On 26/03/15 15:38, Daniel Kurtz wrote:
> Hi Emil,
>
> On Thu, Mar 26, 2015 at 11:12 PM, Emil Velikov
> wrote:
>>
>> Hi Daniel,
>> On 25/03/15 01:01, Daniel Kurtz wrote:
>>> Unfortunately, there are some users of libdrm installed headers that like
>>> to be built with -std=c89 -pedantic, which do
correct
session and times out when there are multiple users (uid) using it.
--
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/20150
Hi,
> I don't know. This seems exactly like the kind of thing
> we had in mind when we added the virtio pci capability.
> For example, we have text in spec that requires drivers
> to skip unknown capabilities.
>
> And yes, if bios pokes at a specific bar then we do
> need to list this info in t
||
--
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/20150326/b5daa067/attachment.html>
the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150326/7139c58a/attachment.html>
org/archives/dri-devel/attachments/20150326/ccd514a9/attachment.html>
8154313
Mesa 10.4
3.18 kernel
LLVM 3.5
Radeon 290
--
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/20150326/33d79a8b/attachment.html>
On 23/03/15 01:46, Alan Coopersmith wrote:
> On 03/ 9/15 05:37 AM, Emil Velikov wrote:
>> The former does not imply the latter and vice-versa. One such example is
>> the Sun compiler.
>>
>> Cc: Alan Coopersmith
>> Cc: Thierry Reding
>> Signed-off-by: Emil Velikov
>> ---
>>
>> Hi Alan,
>> Can you
On 25/03/15 16:48, Tobias Jakobi wrote:
> Currently only fast solid color clear performance is measured.
> A large buffer is allocated and solid color clear operations
> are executed on it with randomly chosen properties (position
> and size of the region, clear color). Execution time is
> measured
what happens during GPU lockup
http://savepic.su/5493290.png
--
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/20150326/04421
On 25/03/15 18:27, Tobias Jakobi wrote:
> Hello,
>
> the new version should fix most of the mentioned issues.
>
> Tobias Jakobi wrote:
>>> As a general note I would recommend keeping statements on separate lines
>>> (none of if (foo) far()) as it makes debugging easier.
>> OK, changing this.
> Ex
On 24/03/15 23:20, Jan Vesely wrote:
> On Sun, 2015-03-22 at 22:03 +, Emil Velikov wrote:
>> This series covers
>> - Remove the hackish "include xf86drmfoo.c" from dristat
>> - Extract the remaining two xf86drmfoo.c tests to standalone ones
>> - beat them into shape, and
>> - wire them up t
Hi Daniel,
On 25/03/15 01:01, Daniel Kurtz wrote:
> Unfortunately, there are some users of libdrm installed headers that like
> to be built with -std=c89 -pedantic, which does not like "inline".
>
> However, __inline works.
>
> Signed-off-by: Daniel Kurtz
> ---
> xf86drmMode.h | 2 +-
> 1 file
On 23/03/15 22:10, Jan Vesely wrote:
> On Sun, 2015-03-22 at 22:03 +, Emil Velikov wrote:
>> Remove the hack of including C files, by reworking the only requirement
>> drmOpenMinor() to an open(buf...). After all we do know the exact name
>> of the device we're going to open, so might as well u
On 24/03/15 23:16, Jan Vesely wrote:
> Commit e4a519635f75bde38aeb5b09f2ff4efbf73453e9:
> Tidy up compile warnings by cleaning up types.
>
> removed call to SLLocate which gutted the function of all functionality.
> This patch restores the original behavior, with an additional fix
> that zeros
On 24/03/15 23:06, Jan Vesely wrote:
> v2: merge tests creation and xf86drmSL cleanup
> rename tests/drmsltest -> tests/drmsl
> move the test out of libudev test block
>
> Signed-off-by: Jan Vesely
> ---
>
> Hi Emil,
> I know you send your R-b on the earlier version, but I thought the ch
atch? It would be great to pick this sooner
>> rather than later since it fixes (at least) display output on Snow
>> and
>> HDMI output on Peach Pit/Pi.
>>
>> Best regards,
>> Javier
>>
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150326/63a3243c/attachment.html>
On Thu, 26 Mar 2015, Daniel Vetter wrote:
> On Thu, Mar 26, 2015 at 4:29 AM, Dave Airlie wrote:
>> I've pushed a drm-fixes-staging branch that backport's Daniel's
>> drm-next fix from 9 hours ago,
>>
>> However it isn't tested yet, so if you want to give it a whirl grab it.
>>
>> Hopefully when D
On Wed, 25 Mar 2015, Daniel Vetter wrote:
> This is a very similar bug in the load detect code fixed in
>
> commit 9128b040eb774e04bc23777b005ace2b66ab2a85
> Author: Daniel Vetter
> Date: Tue Mar 3 17:31:21 2015 +0100
>
> drm/i915: Fix modeset state confusion in the load detect code
>
> But
On Wed, 25 Mar 2015, Josh Boyer wrote:
> On Wed, Mar 25, 2015 at 1:17 PM, Daniel Vetter wrote:
>> On Wed, Mar 25, 2015 at 12:42:46PM -0400, Josh Boyer wrote:
>>> > I'll try that a bit later today. Out of sheer curiosity, I folded
>>> > commit5ba76c41e55c (drm/i915: Put update_state_fb() next to
On Wed, 25 Mar 2015, Daniel Vetter wrote:
> On Tue, Mar 24, 2015 at 12:10:28PM -0400, Josh Boyer wrote:
>> OK, with that commit applied I no longer get the kref.h splat and the
>> NUC machine boots headless. I still see the backtrace below on both
>> the NUC and the macbook. I have a copy of it
Hi Dave -
This should cover the final warnings in -rc5 with two more backports
from our development branch (drm-intel-next-queued). They're the ones
from Daniel and Damien, with references to the reports.
This is on top of drm-fixes because of the dependency on the two earlier
fixes not yet in L
Add a required display-timings node for the TFT LCD panel
the TFT LCD panel is WQVGA "480x272", and the bpp is 24.
Signed-off-by: Alison Wang
Signed-off-by: Xiubo Li
Signed-off-by: Jianwei Wang
---
arch/arm/boot/dts/ls1021a-twr.dts | 26 ++
1 file changed, 26 insertions
Add DCU node, DCU is a display controller of Freescale
named 2D-ACE.
Signed-off-by: Alison Wang
Signed-off-by: Xiubo Li
Signed-off-by: Jianwei Wang
---
arch/arm/boot/dts/ls1021a.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/
Enable DCU pixel clock when platform devices initinalizing and
provide enable and disable pixel clock functions for drm driver
Signed-off-by: Alison Wang
Signed-off-by: Xiubo Li
Signed-off-by: Jianwei Wang
---
arch/arm/mach-imx/mach-ls1021a.c | 36
include/
This patch add support for Two Dimensional Animation and Compositing
Engine (2D-ACE) on the Freescale SoCs.
2D-ACE is a Freescale display controller. 2D-ACE describes
the functionality of the module extremely well its name is a value
that cannot be used as a token in programming languages.
Instead
edesktop.org/archives/dri-devel/attachments/20150326/8ffe4691/attachment.html>
On 26 March 2015 at 13:04, Linus Torvalds
wrote:
> On Wed, Mar 25, 2015 at 3:43 PM, Linus Torvalds
> wrote:
>>
>> I'm going to wait a bit more with this, since clearly things are still
>> in flux, and these two commits don't actually fix everything at all.
>>
>> There's apparently at least one m
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150326/2277227e/attachment-0001.html>
On Thu, Mar 26, 2015 at 12:38:43PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > Absolutely, it's pretty common to mix regions in a BAR.
> > For example, we have virtio kick (ioeventfd backed,
> > handled in kernel) in same BAR as common and device
> > specific configuration.
>
> > We did the same th
Hi,
> Absolutely, it's pretty common to mix regions in a BAR.
> For example, we have virtio kick (ioeventfd backed,
> handled in kernel) in same BAR as common and device
> specific configuration.
> We did the same thing you are now doing with the
> virtio BAR, and now we have to maintain two co
25.03.2015 11:59, Tomeu Vizoso пиÑеÑ:
> As there isn't a way for the firmware on the Nyan chromebooks to hand
> over the display to the kernel, and the kernel isn't redoing the whole
> configuration at present.
>
> With this patch, the SOR is brought to a known state and we get correct
> displ
Dear Inki dae,
Sorry for the previous mail which is not completed. I typed something
and it was the shortcut for maybe.
On Tue, 24 Mar 2015 14:51:31 +0900
Inki Dae wrote:
> On 2015ë
03ì 18ì¼ 17:16, Hyungwon Hwang wrote:
> > MIC(Mobile image compressor) is newly added IP in Exynos5433. MIC
Dear Inki dae,
On Tue, 24 Mar 2015 14:51:31 +0900
Inki Dae wrote:
> On 2015ë
03ì 18ì¼ 17:16, Hyungwon Hwang wrote:
> > MIC(Mobile image compressor) is newly added IP in Exynos5433. MIC
> > resides between decon and mipi dsim, and compresses frame data by
> > 50%. With dsi, not display port,
Hi Tobias,
2015-03-26 Tobias Jakobi :
> While the VP (video processor) supports arbitrary scaling
> of its input, the mixer just supports a simple 2x (line
> doubling) scaling. Expose this functionality and exit
> early when an unsupported scaling configuration is
> encountered.
>
> This was tes
ment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150326/62978135/attachment-0001.sig>
Dear Daniel,
On Wed, 18 Mar 2015 12:24:40 +
Daniel Stone wrote:
> Hi,
> Some feedback comments - most of these are not unique to your 5433
> DECON driver but endemic throughout Exynos, so I don't blame you for
> them - but they should be fixed anyway.
>
> On 18 March 2015 at 08:16, Hyungwon
-
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150326/b8ae3c07/attachment.sig>
From: Mandeep Singh Baines
The goal of the change is to make sure we send the vblank event on the
current vblank. My hope is to fix any races that might be causing flicker.
After this change I only see a flicker in the transition plymouth and
X11.
Simplified the code by tracking vblank events on
From: Gustavo Padovan
These functions were already removed by previous cleanup work, but these
ones were left behind.
Signed-off-by: Gustavo Padovan
Acked-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/e
From: Gustavo Padovan
The .destroy() callback for exynos can be replaced by drm_plane_cleanup().
The only extra operation on exynos_plane_destroy() was a call to
exynos_plane_disable() but the plane is already disabled by a earlier call
to drm_framebuffer_remove().
Signed-off-by: Gustavo Padovan
From: Gustavo Padovan
We already set each plane zpos at init, after that changes to zpos are
not expected. This patch turns zpos into a read-only property so now it is
impossible to set zpos.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 21 ++--
From: Gustavo Padovan
Usually userspace don't want to have two overlay planes on the same zpos
so this change assign a different zpos for each plane. Before this change
a zpos of value zero was created for all planes so the userspace had to
set up the zpos of every plane it wanted to use.
Also a
From: Gustavo Padovan
struct {fimd,mixer,vidi}_win_data was just keeping the same data
as struct exynos_drm_plane thus get ride of it and use exynos_drm_plane
directly.
It changes how planes are created and remove .win_mode_set() callback
that was only filling all *_win_data structs.
Signed-off
From: Gustavo Padovan
None of the exynos crtc drivers implements win_enable() so remove it for
better clarity of the code.
Signed-off-by: Gustavo Padovan
---
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/
From: Gustavo Padovan
XR24 planes were not shown properly, so now set the right registers
to correctly enable displaying these planes.
It also moves the alpha register settings to fimd_win_set_pixfmt()
to keep all pixel format stuff together.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm
From: Gustavo Padovan
Hi,
Here goes some clean ups to the exynos drivers. The main clean ups is
the presetting and zpos making the property immutable and the removal
of *_win_data structures.
v2 contains a extra patch to fix alpha setting for planes in fimd, so
now fimd works fine even after th
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 debugfs EDIDs too.
There should be no harm in gratuitously doing this for non HDMI/DP
connectors, as it's still up
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 debugfs EDIDs too.
>
> There should be no harm
On Thu, Mar 26, 2015 at 09:42:47AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > And is it possible to use offset within BAR and/or memory BARs?
> > If yes I'd strongly prefer this.
>
> What is the point? Do you want place virtio regions and vga framebuffer
> in the same pci bar? Why? virtio is mm
>
>> Alternatively can we:
>> (1) move the wrapper to xf86drmMode.h itself, or
>> (2) move this inline helper function out of xf86drmMode.h and into
>> the two libdrm tests that use it (or a shared test helper .h [0])
>> (3) remove the inline and make drm_property_type_is a non-inline
>> functi
>
> Was honestly hoping that patch #1 is not required as:
> - Getting the drm.h header in sync with the kernel will be annoying.
Indeed.
I have a version of drm.h that works with Solaris and *should* still
work with all other consumers, but as I still have a ways to get fully to
speed, am
On Wed, Mar 25, 2015 at 03:53:09PM +0100, Gerd Hoffmann wrote:
> > > Signed-off-by: Dave Airlie
> > > Signed-off-by: Gerd Hoffmann
> >
> > Standard request from my side for new drm drivers (especially if they're
> > this simple): Can you please update the drivers to latest drm internal
> > inter
Hi,
> And is it possible to use offset within BAR and/or memory BARs?
> If yes I'd strongly prefer this.
What is the point? Do you want place virtio regions and vga framebuffer
in the same pci bar? Why? virtio is mmio and traps into qemu on
access, whereas the vga framebuffer is memory-backe
On Thu, Mar 26, 2015 at 08:12:39AM +0100, Gerd Hoffmann wrote:
> On Mi, 2015-03-25 at 18:09 +0100, Michael S. Tsirkin wrote:
> > On Wed, Mar 25, 2015 at 04:37:16PM +0100, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > BTW can we teach virtio-gpu to look for framebuffer using
> > > > virtio pci cap
On Thu, Mar 26, 2015 at 4:29 AM, Dave Airlie wrote:
> I've pushed a drm-fixes-staging branch that backport's Daniel's
> drm-next fix from 9 hours ago,
>
> However it isn't tested yet, so if you want to give it a whirl grab it.
>
> Hopefully when Daniel comes on line he can provide assurance that m
signee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150326/709909cb/attachment-0001.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150326/2113d44c/attachment.html>
ceiving 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/20150326/a7fe5f38/attachment.html>
On Mi, 2015-03-25 at 18:09 +0100, Michael S. Tsirkin wrote:
> On Wed, Mar 25, 2015 at 04:37:16PM +0100, Gerd Hoffmann wrote:
> > Hi,
> >
> > > BTW can we teach virtio-gpu to look for framebuffer using
> > > virtio pci caps?
> >
> > The virtio-gpu driver doesn't matter much here, it doesn't use
1 - 100 of 108 matches
Mail list logo
