On 10 March 2015 at 22:55, Thomas Hellstrom wrote:
> On 03/09/2015 09:25 PM, Dave Airlie wrote:
>> On 10 March 2015 at 02:02, Thomas Hellstrom wrote:
>>> On 03/09/2015 04:22 PM, Daniel Vetter wrote:
On Mon, Mar 09, 2015 at 11:04:01AM +0100, Thomas Hellstrom wrote:
> Hi,
>
> I'm n
Hi Tobias and Emil
On 2015ë
03ì 11ì¼ 04:36, Emil Velikov wrote:
> On 08/03/15 23:12, Tobias Jakobi wrote:
>> Hello Emil,
>> Emil Velikov wrote:
>>> I'm planning to push the above mentioned patches around lunchtime this
>>> Tuesday. If anyone has objections please speak up.
>> I doubt you're g
Hi Dan,
(CC'ing Daniel Vetter)
On Tuesday 10 March 2015 23:30:45 Dan Carpenter wrote:
> Hello Laurent Pinchart,
>
> The patch eca93e28c256: "drm: Check in setcrtc if the primary plane
> supports the fb pixel format" from Mar 9, 2015, leads to the
> following static checker warning:
>
> dr
Add devicetree bindings for IT6151 MIPI to eDP bridge chip driver.
---
Documentation/devicetree/bindings/drm/bridge/it6151.txt | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/bridge/it6151.txt
diff --git a/Documentation/devicetree/b
This patch adds a drm_bridge driver for the IT6151 MIPI to eDP
bridge chip.
Signed-off-by: CK Hu
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/bridge/Kconfig | 10 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/it6151.c | 601
include
On 03/10/2015 04:24 PM, Philipp Zabel wrote:
> Hi Archit,
>
> thanks for the cleanup!
>
> Am Dienstag, den 10.03.2015, 15:11 +0530 schrieb Archit Taneja:
>> DRM_IMX_FB_HELPER config is currently used to enable/disable fbdev emulation
>> for
>> the imx kms driver.
>>
>> Remove this local config o
On 03/10/2015 09:03 PM, Jani Nikula wrote:
> On Tue, 10 Mar 2015, Archit Taneja wrote:
>> On 03/10/2015 03:35 PM, Daniel Vetter wrote:
>>> On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote:
On 03/10/2015 03:17 PM, Daniel Vetter wrote:
> On Tue, Mar 10, 2015 at 03:1
Add devicetree bindings for IT6151 MIPI to eDP bridge chip driver.
Signed-off-by: CK Hu
Signed-off-by: Jitao Shi
---
Documentation/devicetree/bindings/drm/bridge/it6151.txt | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/bridge/it
This patch adds a drm_bridge driver for the IT6151 MIPI to eDP
bridge chip.
Signed-off-by: CK Hu
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/bridge/Kconfig | 10 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/it6151.c | 601
include
> +
> +#define fourcc_mod_code(vendor, val) \
> + u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val &
> 0x00ffL))
eh, yeah no,
/home/airlied/kernel/drm-2.6/drivers/gpu/drm/i915/intel_pm.c: In
function âskl_wm_method2â:
/home/airlied/kernel/drm-2.6/drivers/gpu/drm/i915/
On 03/10/2015 10:05 PM, Dave Airlie wrote:
> On 10 March 2015 at 22:55, Thomas Hellstrom wrote:
>> On 03/09/2015 09:25 PM, Dave Airlie wrote:
>>> On 10 March 2015 at 02:02, Thomas Hellstrom
>>> wrote:
On 03/09/2015 04:22 PM, Daniel Vetter wrote:
> On Mon, Mar 09, 2015 at 11:04:01AM +010
Hello,
On Sun, Mar 08, 2015 at 10:05:29PM +0100, Arnd Bergmann wrote:
> +static inline bool clk_is_match(struct clk *p, struct clk *q)
> +{
> + return p == q ? true : false;
OK, this is only a move, but I wonder why Russell's comment that this is
equivalent to the easier
return p ==
On Tue, Mar 10, 2015 at 01:06:44PM -0700, Jeff McGee wrote:
> On Tue, Mar 10, 2015 at 07:47:03PM +0100, Daniel Vetter wrote:
> > On Tue, Mar 10, 2015 at 01:58:52PM -0400, Rob Clark wrote:
> > > On Tue, Mar 10, 2015 at 12:59 PM, Jeff McGee
> > > wrote:
> > > > On Tue, Mar 10, 2015 at 08:37:30AM +0
>>
>> I think with modesetting driver it shouldn't be a problem anymore.
>>
>> Dave.
>
> So what's the preferred remedy here? should I file a bug against the
> above commit or should we go ahead modifying
> the DRM drivers?
I'd file against that first, and maybe see why it clears the value.
Dave.
I have no idea about the exact rules, but this angered Dave's 32bit
rhel gcc.
Reported-by: Dave Airlie
Signed-off-by: Daniel Vetter
---
include/uapi/drm/drm_fourcc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
Without this Dave's 32bit rhel compiler is annoyed. Don't ask me about
the exact rules for this stuff though, but this should be safe.
Reported-by: Dave Airlie
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_vgpu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/d
On Tue, Mar 10, 2015 at 05:34:35PM +0200, Ville Syrjälä wrote:
> On Tue, Mar 10, 2015 at 05:14:58PM +0200, Jani Nikula wrote:
> > On Tue, 10 Mar 2015, ville.syrjala at linux.intel.com wrote:
> > > Make the helper function pointer structs const to make it clear they
> > > should not be modified.
>
I somehow manage to screw up applying Laurent's patch in eca93e28c256:
"drm: Check in setcrtc if the primary plane supports the fb pixel
format". It was a conflict with
commit 3461b30b3e171e16498f3d7bc59ab703aec475c8
Author: Daniel Vetter
Date: Thu Mar 5 10:32:44 2015 +0100
drm/plane-helpe
[cc'ing lists]
On Tue, Mar 10, 2015 at 07:17:22PM +0100, Krzysztof Kolasa wrote:
> System ( 32bit, Intel 945GM ) hangs after some short time, oops:
>
> [ cut here ]
> kernel BUG at drivers/gpu/drm/drm_mm.c:305!
> invalid opcode: [#1] SMP
> Modules linked in: arc4 md4
On 03/10/2015 05:47 PM, Daniel Vetter wrote:
> On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote:
>> On 03/10/2015 03:35 PM, Daniel Vetter wrote:
>>> On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote:
On 03/10/2015 03:17 PM, Daniel Vetter wrote:
> On Tue, Mar 10,
hanks,
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/20150311/e169ce59/attachment.html>
ri-devel/attachments/20150311/0125e425/attachment.html>
L:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/247b47e6/attachment.html>
On 03/11/2015 08:22 AM, Dave Airlie wrote:
>>> I think with modesetting driver it shouldn't be a problem anymore.
>>>
>>> Dave.
>> So what's the preferred remedy here? should I file a bug against the
>> above commit or should we go ahead modifying
>> the DRM drivers?
> I'd file against that first,
Hi Heiko,
Am Dienstag, den 10.03.2015, 22:45 +0100 schrieb Heiko Stuebner:
> At least the Rockchip variant of the dw_hdmi can have controllable power
> supplies
> providing 1.0 and 1.8V. Therefore add the possibility for the generic bridge
> driver to enable supplies provided by the hw-specific d
Per driver and core constification with cocci, final patch
manually. Inspired by Ville in [1].
BR,
Jani.
[1] http://mid.gmane.org/1425990920-17379-1-git-send-email-ville.syrjala at
linux.intel.com
Jani Nikula (9):
drm/exynos: constify all struct drm_*_helper funcs pointers
drm/mgag200: con
They are not to be modified.
Generated using the semantic patch:
@@
@@
(
const struct drm_crtc_helper_funcs *
|
- struct drm_crtc_helper_funcs *
+ const struct drm_crtc_helper_funcs *
)
@@
@@
(
const struct drm_encoder_helper_funcs *
|
- struct drm_encoder_helper_funcs *
+ const struct drm_e
They are not to be modified.
Generated using the semantic patch:
@@
@@
(
const struct drm_crtc_helper_funcs *
|
- struct drm_crtc_helper_funcs *
+ const struct drm_crtc_helper_funcs *
)
@@
@@
(
const struct drm_encoder_helper_funcs *
|
- struct drm_encoder_helper_funcs *
+ const struct drm_e
They are not to be modified.
Generated using the semantic patch:
@@
@@
(
const struct drm_crtc_helper_funcs *
|
- struct drm_crtc_helper_funcs *
+ const struct drm_crtc_helper_funcs *
)
@@
@@
(
const struct drm_encoder_helper_funcs *
|
- struct drm_encoder_helper_funcs *
+ const struct drm_e
They are not to be modified.
Generated using the semantic patch:
@@
@@
(
const struct drm_crtc_helper_funcs *
|
- struct drm_crtc_helper_funcs *
+ const struct drm_crtc_helper_funcs *
)
@@
@@
(
const struct drm_encoder_helper_funcs *
|
- struct drm_encoder_helper_funcs *
+ const struct drm_e
They are not to be modified.
Generated using the semantic patch:
@@
@@
(
const struct drm_crtc_helper_funcs *
|
- struct drm_crtc_helper_funcs *
+ const struct drm_crtc_helper_funcs *
)
@@
@@
(
const struct drm_encoder_helper_funcs *
|
- struct drm_encoder_helper_funcs *
+ const struct drm_e
Hi Philipp,
Am Mittwoch, 11. März 2015, 10:28:29 schrieb Philipp Zabel:
> Am Dienstag, den 10.03.2015, 22:45 +0100 schrieb Heiko Stuebner:
> > At least the Rockchip variant of the dw_hdmi can have controllable power
> > supplies providing 1.0 and 1.8V. Therefore add the possibility for the
> > ge
They are not to be modified.
Generated using the semantic patch:
@@
@@
(
const struct drm_crtc_helper_funcs *
|
- struct drm_crtc_helper_funcs *
+ const struct drm_crtc_helper_funcs *
)
@@
@@
(
const struct drm_encoder_helper_funcs *
|
- struct drm_encoder_helper_funcs *
+ const struct drm_e
They are not to be modified.
Generated using the semantic patch:
@@
@@
(
const struct drm_crtc_helper_funcs *
|
- struct drm_crtc_helper_funcs *
+ const struct drm_crtc_helper_funcs *
)
@@
@@
(
const struct drm_encoder_helper_funcs *
|
- struct drm_encoder_helper_funcs *
+ const struct drm_e
They are not to be modified.
Generated using the semantic patch:
@@
@@
(
const struct drm_crtc_helper_funcs *
|
- struct drm_crtc_helper_funcs *
+ const struct drm_crtc_helper_funcs *
)
@@
@@
(
const struct drm_encoder_helper_funcs *
|
- struct drm_encoder_helper_funcs *
+ const struct drm_e
They're only used to store const pointers anyway. This helps to keep
Ville and the compiler happy.
Signed-off-by: Jani Nikula
---
include/drm/drm_crtc.h | 8
include/drm/drm_crtc_helper.h | 6 +++---
include/drm/drm_plane_helper.h | 2 +-
3 files changed, 8 insertions(+), 8 del
On Sun, Mar 08, 2015 at 10:05:29PM +0100, Arnd Bergmann wrote:
> ARM randconfig build tests found a new error for configurations
> with COMMON_CLK disabled but HAS_CLK selected by the platform:
>
> ERROR: "clk_is_match" [sound/soc/fsl/snd-soc-fsl-spdif.ko] undefined!
>
> This moves the declaratio
Sounds logical to me to do so. Patch #4 and #9 are Reviewed-by:
Christian König
Regards,
Christian.
On 11.03.2015 10:50, Jani Nikula wrote:
> Per driver and core constification with cocci, final patch
> manually. Inspired by Ville in [1].
>
> BR,
> Jani.
>
> [1] http://mid.gmane.org/1425990920
+-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Thierry Reding
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/8ec93d5f/attachment.sig>
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/20150311/02132629/attachment.html>
Hey Russell,
On Wed, Mar 11, 2015 at 10:22:09AM +, Russell King - ARM Linux wrote:
> On Sun, Mar 08, 2015 at 10:05:29PM +0100, Arnd Bergmann wrote:
> > ARM randconfig build tests found a new error for configurations
> > with COMMON_CLK disabled but HAS_CLK selected by the platform:
> >
> > ER
On Wed, Mar 11, 2015 at 10:51 AM, Jani Nikula wrote:
> They are not to be modified.
>
> Generated using the semantic patch:
>
> @@
> @@
> (
> const struct drm_crtc_helper_funcs *
> |
> - struct drm_crtc_helper_funcs *
> + const struct drm_crtc_helper_funcs *
> )
>
> @@
> @@
> (
> const struct
Hi Mauro,
I have some more comments/questions below.
From: Mauro Carvalho Chehab [mailto:mche...@osg.samsung.com]
Sent: Sunday, March 08, 2015 3:21 PM
>
> Em Thu, 22 Jan 2015 17:04:34 +0100
> Kamil Debski escreveu:
>
> (c/c linux-input ML)
>
> > Add cec protocol handling the RC framework.
>
On Wed, Mar 11, 2015 at 12:17:55PM +0100, Uwe Kleine-König wrote:
> Hey Russell,
>
> On Wed, Mar 11, 2015 at 10:22:09AM +, Russell King - ARM Linux wrote:
> > On Sun, Mar 08, 2015 at 10:05:29PM +0100, Arnd Bergmann wrote:
> > > ARM randconfig build tests found a new error for configurations
>
Hi Tobias,
On 2015ë
02ì 24ì¼ 23:20, Tobias Jakobi wrote:
> The coefficient mode enables use of global color, not alpha.
>
> Signed-off-by: Tobias Jakobi
> ---
> exynos/exynos_fimg2d.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/exynos/exynos_fimg2d.h b/exynos/
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/85b5870d/attachment.html>
.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/8f162572/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/2ae89be6/attachment.html>
Hi,
On 2015ë
02ì 24ì¼ 23:20, Tobias Jakobi wrote:
> Hello,
>
> here are some miscellaneous improvements (small features, bugfixes, spelling
> fixes, etc.) for the exynos component of libdrm. The general idea is to let
> userspace use the G2D engine functionality more
> efficiently.
>
> I
On 2015ë
03ì 07ì¼ 06:23, Rob Clark wrote:
> Signed-off-by: Rob Clark
Signed-off-by : Inki Dae
Thanks,
Inki Dae
> ---
> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> b/d
rg <http://www.linaro.org/> *â *Open source software for ARM SoCs
Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> | Twitter
<http://twitter.com/#!/linaroorg> | Blog
<http://www.linaro.org/linaro-blog/>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/cd86a7b4/attachment.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/bbd504fa/attachment.html>
ed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/868c449f/attachment.html>
In the process of fixing fb_width/fb_height problems with tiled displays
(such as DP MST), I realized there were a few drivers having confusion
about drm_fb_helper_surface_size.
So, document the struct, fix the drivers, simplify the logic in
drm_fb_helper_single_fb_probe() that figures out the siz
There has been some confusion about this struct. Lack of documentation
probably didn't help.
Signed-off-by: Rob Clark
---
include/drm/drm_fb_helper.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 21b944c.
Signed-off-by: Rob Clark
---
include/drm/drm_crtc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index adc9ea5..7b5c661 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -915,7 +915,7 @@ struct drm_bridge {
What is passed to drm_fb_helper_fill_var() should be fb_width/fb_height,
rather than the surface size.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_fb_cma_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_f
What is passed to drm_fb_helper_fill_var() should be fb_width/fb_height,
rather than the surface size.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/driv
What is passed to drm_fb_helper_fill_var() should be fb_width/fb_height,
rather than the surface size.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
b/d
Flip conditional to reduce indentation level of rest of fxn, and use
min/max to make the code clearer.
v2: surface_width -> surface_height typo
Signed-off-by: Rob Clark
Reviewed-by: Daniel Kurtz
---
drivers/gpu/drm/drm_fb_helper.c | 28 +++-
1 file changed, 15 insertion
We don't want tile 0,0 to artificially constrain the size of the legacy
fbdev device. Instead when reducing fb_size to be the minimum of all
displays, only consider the rightmost and bottommost tiles.
Signed-off-by: Rob Clark
Tested-by: Hai Li
---
drivers/gpu/drm/drm_fb_helper.c | 26 +
This patch does the minimum to make sti driver use atomic helpers.
No big bang, only adapt some functions to new call order.
Later it will allow to clean the mess around sti_mixer_* functions
which are use either in plane and crtc.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_co
On Wed, Mar 11, 2015 at 01:51:02PM +0530, Archit Taneja wrote:
>
>
> On 03/10/2015 05:47 PM, Daniel Vetter wrote:
> >On Tue, Mar 10, 2015 at 03:52:41PM +0530, Archit Taneja wrote:
> >>On 03/10/2015 03:35 PM, Daniel Vetter wrote:
> >>>On Tue, Mar 10, 2015 at 03:22:49PM +0530, Archit Taneja wrote:
On 03/11/2015 02:51 AM, Jani Nikula wrote:
> They are not to be modified.
>
> Generated using the semantic patch:
>
> @@
> @@
> (
> const struct drm_crtc_helper_funcs *
> |
> - struct drm_crtc_helper_funcs *
> + const struct drm_crtc_helper_funcs *
> )
>
> @@
> @@
> (
> const struct drm_enco
radeon_bo_create() calls radeon_ttm_placement_from_domain()
before ttm_bo_init() is called. radeon_ttm_placement_from_domain()
uses the ttm bo size to determine when to select top down
allocation but since the ttm bo is not initialized yet the
check is always false.
Noticed-by: Oded Gabbay
Signe
On Wed, Mar 11, 2015 at 10:23 AM, Rob Clark wrote:
> In the process of fixing fb_width/fb_height problems with tiled displays
> (such as DP MST), I realized there were a few drivers having confusion
> about drm_fb_helper_surface_size.
>
> So, document the struct, fix the drivers, simplify the logi
achment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/5521e900/attachment.html>
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/202c3206/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/66a4123c/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/74273960/attachment.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/620f8b29/attachment.html>
re the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/6273da69/attachment.html>
||
--
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/20150311/c79af503/attachment-0001.html>
ent was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/c36d5308/attachment.html>
Hi Rob,
Thank you for the patch.
On Wednesday 11 March 2015 10:23:13 Rob Clark wrote:
> Flip conditional to reduce indentation level of rest of fxn, and use
> min/max to make the code clearer.
>
> v2: surface_width -> surface_height typo
>
> Signed-off-by: Rob Clark
> Reviewed-by: Daniel Kurtz
Hi Rob,
Thank you for the patches.
On Wednesday 11 March 2015 10:23:07 Rob Clark wrote:
> In the process of fixing fb_width/fb_height problems with tiled displays
> (such as DP MST), I realized there were a few drivers having confusion
> about drm_fb_helper_surface_size.
>
> So, document the str
Hi Daniel,
Thank you for the patch.
On Wednesday 11 March 2015 09:00:26 Daniel Vetter wrote:
> I somehow manage to screw up applying Laurent's patch in eca93e28c256:
> "drm: Check in setcrtc if the primary plane supports the fb pixel
> format". It was a conflict with
>
> commit 3461b30b3e171e164
ed -> NotOurBug".
--
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/20150311/05b16043/attachment.html>
On 11.03.2015 16:44, Alex Deucher wrote:
> radeon_bo_create() calls radeon_ttm_placement_from_domain()
> before ttm_bo_init() is called. radeon_ttm_placement_from_domain()
> uses the ttm bo size to determine when to select top down
> allocation but since the ttm bo is not initialized yet the
> che
Hi Emil,
Thank you for the patch.
On Tuesday 10 March 2015 18:12:28 Emil Velikov wrote:
> With commit d7c0a08bc57(modetest: Allocate dumb buffers with the correct
> bpp) we moved away from the libkms dependency. As such we are safe with
> including the Makefile/subdir, even as we opt out of build
Hi, Dave.
A couple of fixes for vmwgfx.
The following changes since commit cd961bb9eebb630452f49dcbf3e5f0059428614a:
drm/mst: fix recursive sleep warning on qlock (2015-03-10 13:44:31 +1000)
are available in the git repository at:
git://people.freedesktop.org/~thomash/linux
for you to fe
On 11 March 2015 at 13:31, Inki Dae wrote:
> Hi,
>
> On 2015ë
02ì 24ì¼ 23:20, Tobias Jakobi wrote:
>> Hello,
>>
>> here are some miscellaneous improvements (small features, bugfixes, spelling
>> fixes, etc.) for the exynos component of libdrm. The general idea is to let
>> userspace use the
Dave,
The first pull request for 4.1. Mainly Sinclair's screen target work.
The following changes since commit 03be70050c85768e9ce7c0d0887110d1b629e127:
Merge tag 'topic/drm-misc-2015-03-10' of
git://anongit.freedesktop.org/drm-intel into drm-next (2015-03-11 12:15:06
+1000)
are available i
On Wed, Feb 11, 2015 at 02:05:21PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 10, 2015 at 06:38:08PM +, Simon Farnsworth wrote:
> > Older DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs
> > in their I2C over AUX implementation (fixed in newer revisions). They work
> > fin
icted from VRAM
>> */
>> radeon_ttm_placement_from_domain(rbo,
>> RADEON_GEM_DOMAIN_VRAM |
>> -
>> RADEON_GEM_DOMAIN_GTT);
>> +
>> RADEON_GEM_DOMAIN_GTT,
>> +
>> rbo->tbo.mem.size);
>> rbo->placement.num_busy_placement = 0;
>> for (i = 0; i < rbo->placement.num_placement; i++)
>> {
>> if (rbo->placements[i].flags &
>> TTM_PL_FLAG_VRAM) {
>> @@ -222,11 +224,13 @@ static void radeon_evict_flags(struct
>> ttm_buffer_object *bo,
>> }
>> }
>> } else
>> - radeon_ttm_placement_from_domain(rbo,
>> RADEON_GEM_DOMAIN_GTT);
>> + radeon_ttm_placement_from_domain(rbo,
>> RADEON_GEM_DOMAIN_GTT,
>> +
>> rbo->tbo.mem.size);
>> break;
>> case TTM_PL_TT:
>> default:
>> - radeon_ttm_placement_from_domain(rbo,
>> RADEON_GEM_DOMAIN_CPU);
>> + radeon_ttm_placement_from_domain(rbo,
>> RADEON_GEM_DOMAIN_CPU,
>> +rbo->tbo.mem.size);
>> }
>> *placement = rbo->placement;
>> }
>
>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-fix-TOPDOWN-handling-for-bo_create-v2.patch
Type: text/x-patch
Size: 9510 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150311/a386eb08/attachment-0001.bin>
On Wed, Mar 11, 2015 at 09:28:20PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 11, 2015 at 02:05:21PM +0200, Ville Syrjälä wrote:
> > On Tue, Feb 10, 2015 at 06:38:08PM +, Simon Farnsworth wrote:
> > > Older DisplayPort to DVI-D Dual Link adapters designed by Bizlink have
> > > bugs
> > > in
On Wed, Mar 11, 2015 at 10:23:14AM -0400, Rob Clark wrote:
> We don't want tile 0,0 to artificially constrain the size of the legacy
> fbdev device. Instead when reducing fb_size to be the minimum of all
> displays, only consider the rightmost and bottommost tiles.
>
> Signed-off-by: Rob Clark
>
t;>> RADEON_GEM_DOMAIN_CPU,
>>> +
>>> rbo->tbo.mem.size);
>>> else if (rbo->rdev->mc.visible_vram_size <
>>> rbo->rdev->mc.real_vram_size &&
>>> bo->mem.start < (rbo->rdev-&g
On Wed, Mar 11, 2015 at 5:13 PM, Daniel Vetter wrote:
> On Wed, Mar 11, 2015 at 10:23:14AM -0400, Rob Clark wrote:
>> We don't want tile 0,0 to artificially constrain the size of the legacy
>> fbdev device. Instead when reducing fb_size to be the minimum of all
>> displays, only consider the righ
This is a combination of g2d_copy_with_scale and g2d_scale.
It is a pretty common operation to scale one buffer and then
blend it on top of another, so provide a direct way to that
operation.
Signed-off-by: Tobias Jakobi
Reviewed-by: Inki Dae
Tested-by: Joonyoung Shim
---
exynos/exynos_fimg2d.
The reason for this change is to let userspace use the header.
Currently 'make install' does not install it.
Signed-off-by: Tobias Jakobi
Reviewed-by: Inki Dae
Tested-by: Joonyoung Shim
---
exynos/Makefile.am | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/exynos/Makefile
On 2015-03-11 19:56, Emil Velikov wrote:
> Tobias,
> Can you please re-spin the remaining patches on top of master, and
> address Inki's comment.
> Also please add Inki's and Joonyoung Shim's tags.
Done. I hope I did the tagging correctly.
With best wishes,
Tobias
On 03/11/15 05:29, Russell King - ARM Linux wrote:
> On Wed, Mar 11, 2015 at 12:17:55PM +0100, Uwe Kleine-König wrote:
>> Hey Russell,
>>
>> On Wed, Mar 11, 2015 at 10:22:09AM +, Russell King - ARM Linux wrote:
>>> On Sun, Mar 08, 2015 at 10:05:29PM +0100, Arnd Bergmann wrote:
ARM randcon
Em Wed, 11 Mar 2015 12:24:53 +0100
Kamil Debski escreveu:
> Hi Mauro,
>
> I have some more comments/questions below.
>
> From: Mauro Carvalho Chehab [mailto:mchehab at osg.samsung.com]
> Sent: Sunday, March 08, 2015 3:21 PM
> >
> > Em Thu, 22 Jan 2015 17:04:34 +0100
> > Kamil Debski escreveu:
Hi Ben,
Since 3.19 the NV BIOS can no longer be loaded via ACPI. This breaks my HP
laptop.
Looking at the recent changes (ad4a3626 split out shadow methods) in the bios
shadow code, I think
this happens:
- nvbios_shadow loops over all possible bios sources
- shadow_method
- shadow_score
- shad
This makes it easier to spot memory corruptions which don't become
visible when using a plain buffer filled with a solid color (so
corruptions that are just a permutation of the bytes in the buffer).
Signed-off-by: Tobias Jakobi
Reviewed-by: Inki Dae
Tested-by: Joonyoung Shim
---
tests/exynos/
This is useful when the default repeat mode, which is 'repeat'
produces artifacts at the borders of the copied image.
Choose the 'pad' mode to make use of the color of the destination
image.
In my usage case the destination is the framebuffer, which is
solid filled with a background color. Scaling
Keeps the code cleaner, since the structs have to be initialized
once anyway.
Signed-off-by: Tobias Jakobi
Reviewed-by: Inki Dae
Tested-by: Joonyoung Shim
---
exynos/exynos_fimg2d.c| 4 +---
tests/exynos/exynos_fimg2d_test.c | 15 ---
2 files changed, 5 insertions(+),
Signed-off-by: Tobias Jakobi
Reviewed-by: Inki Dae
Tested-by: Joonyoung Shim
---
exynos/Makefile.am| 2 +-
exynos/exynos_fimg2d.c| 2 +-
exynos/exynos_fimg2d.h| 322 ++
exynos/fimg2d.h | 322 --
Also add the register field formatting info provided by
Inki Dae .
Signed-off-by: Tobias Jakobi
Reviewed-by: Inki Dae
Tested-by: Joonyoung Shim
---
exynos/exynos_fimg2d.h | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/exynos/exynos_fimg2d.h b/exynos/exynos_fimg2d.h
1 - 100 of 101 matches
Mail list logo
