ckchip/rockchipdrm.ko]
> undefined!
>
> Fixes: 3190e58dafaf ("drm/rockchip: Implement CRC debugfs API")
> Reported-by: Emil Velikov
> Cc: Tomeu Vizoso
> Cc: Mark Yao
> Cc: Sean Paul
> Cc: Heiko Stuebner
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-a
On 22 January 2017 at 18:48, Emil Velikov wrote:
> All one needs is to establish if dev->fd is the flink (primary/card)
> node, rather than use DRM_IOCTL_GET_CLIENT to query the auth status.
>
> The latter is [somewhat] deprecated and incorrect. We need to know [and
> store] t
On 7 March 2017 at 00:45, Emil Velikov wrote:
> I have another ~20 patch series that builds on top ;-)
>
Correction - those are xf86-video-amdgpu ones independent of this series.
Pardon for the noise.
Emil
___
dri-devel mailing list
dri
Hi Chih-Wei,
On 9 March 2017 at 02:12, Chih-Wei Huang wrote:
> To avoid the warning:
>
> external/libdrm/intel/intel_bufmgr.c:362:20: warning: more '%' conversions
> than data arguments [-Wformat]
> fprintf(stderr, "%s: Mappable aperture size hardcoded to 64MiB\n");
>
struct platform_device *platform_device);
>
I wouldn't bother with the re-wrap, but regardless
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 13 March 2017 at 17:00, Rob Clark wrote:
> On Mon, Mar 13, 2017 at 12:43 PM, Arnd Bergmann wrote:
>> The newly added a5xx support fails to build when debugfs is diabled:
>>
>> drivers/gpu/drm/msm/adreno/a5xx_gpu.c:849:4: error: 'struct msm_gpu_funcs'
>> has no member named 'show'
>> drivers/g
Hi Dave,
Barring the other discussions, allow me to put a couple of trivial suggestions:
Please re-wrap the long lines to follow existing code style.
On 14 March 2017 at 00:50, Dave Airlie wrote:
> @@ -882,6 +894,12 @@ int amdgpu_cs_submit(amdgpu_context_handle context,
>
On 16 March 2017 at 13:56, Eric Engestrom wrote:
> GCC 7 complains about major(), minor() and makedev():
> warning: In the GNU C Library, "major" is defined by .
> For historical compatibility, it is currently defined by as
> well, but we plan to remove this soon. To use "major", incl
On 16 March 2017 at 17:00, Eric Engestrom wrote:
> On Thursday, 2017-03-16 15:09:15 +0000, Emil Velikov wrote:
>> On 16 March 2017 at 13:56, Eric Engestrom wrote:
>> > GCC 7 complains about major(), minor() and makedev():
>> > warning: In the GNU C Lib
Hi Dylan,
On 16 March 2017 at 21:25, Dylan Baker wrote:
> Why bother, and why would we want this?
>│~
>
> First it's written in python, which means the potential developer base
> is massive. And it provides a recursive view for humans
On 17 March 2017 at 00:21, Dylan Baker wrote:
> Hi Emil,
>
> Quoting Emil Velikov (2017-03-16 16:35:33)
>> While I can see you're impressed by Meson, I would kindly urge you to
>> not use it here. As you look closely you can see that one could
>> trivially improve
[+ Lionel]
On 16 March 2017 at 16:46, Eric Engestrom wrote:
> On Thursday, 2017-03-16 00:08:59 +, Eric Engestrom wrote:
>> According to the kernel documentation:
>> Returns non-zero if @v was not @u, and zero otherwise.
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100077
>>
Hi Philipp,
I think you patch is OK, just a small question about the existing code.
It might be better suited for Eric... not sure.
On 17 March 2017 at 17:00, Philipp Zabel wrote:
> Use platform_register_drivers instead of open coding the iteration over
> component platform drivers in the vc4_dr
Hi Seung-Woo Kim,
On 16 March 2017 at 02:00, Seung-Woo Kim wrote:
> This patch fixes memory issues including NULL deference and leak
> in g2d test in error path.
>
> Signed-off-by: Seung-Woo Kim
> ---
> tests/exynos/exynos_fimg2d_test.c | 13 +++--
> 1 files changed, 7 insertions(+),
Seems like we ended up all over the place, so let me try afresh.
Above all:
- Saying "I don't care" about your users is arrogant - let us _not_
do that, please ?
Even Linux distribution maintainers have responded that "upstream does
not care us", which is indicative that we should be more careful
On 20 March 2017 at 18:30, Matt Turner wrote:
> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov
> wrote:
>> Seems like we ended up all over the place, so let me try afresh.
>>
>> Above all:
>> - Saying "I don't care" about your users is arrogant - l
On 21 March 2017 at 15:57, Matt Turner wrote:
> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov
> wrote:
>> On 20 March 2017 at 18:30, Matt Turner wrote:
>>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov
>>> wrote:
>>>> Seems like we ended u
On 21 March 2017 at 18:06, Matt Turner wrote:
> On Tue, Mar 21, 2017 at 10:16 AM, Emil Velikov
> wrote:
>> On 21 March 2017 at 15:57, Matt Turner wrote:
>>> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov
>>> wrote:
>>>> On 20 March 2017 at 18:30
Hi Sean,
On 16 March 2017 at 22:08, Sean Paul wrote:
> This series pulls out the power-sequencing code from panel-simple into a
> panel-common helper library. This allows drivers that cannot leverage
> panel-simple to share some code.
>
> I've converted the 2 sharp mipi drivers, and Chris Zhong's
On 21 March 2017 at 19:10, Matt Turner wrote:
> On Tue, Mar 21, 2017 at 11:56 AM, Emil Velikov
> wrote:
>> On 21 March 2017 at 18:06, Matt Turner wrote:
>>> (1) Non-recursive automake is necessary for parallel build performance
>> Fully agree
>>
>>>
On 22 March 2017 at 20:10, Dylan Baker wrote:
> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher wrote:
>> I guess I'm a little late to the party here, but I haven't had time to
>> really let all of this sink in and actually look at meson. It doesn't
>> seem so bad with a quick look and I think I
On 21 March 2017 at 05:00, Jonathan Gray wrote:
> On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote:
>>
>>
>> On 21/03/17 06:39, Emil Velikov wrote:
>> > On 20 March 2017 at 18:30, Matt Turner wrote:
>> > > On Mon, Mar 20, 2017 at 6:55 AM, E
On 22 March 2017 at 15:06, Sean Paul wrote:
> On Wed, Mar 22, 2017 at 02:36:27PM +0000, Emil Velikov wrote:
>> Hi Sean,
>>
>> On 16 March 2017 at 22:08, Sean Paul wrote:
>> > This series pulls out the power-sequencing code from panel-simple into a
>> > p
Hi Sean,
Something small that stood out while skimming through the design.
On 16 March 2017 at 22:08, Sean Paul wrote:
> struct panel_simple {
> struct drm_panel base;
> + struct panel_common common;
> +
> bool prepared;
> bool enabled;
>
There two should go ?
>
On 16 March 2017 at 22:08, Sean Paul wrote:
> static const struct drm_display_mode default_mode = {
> @@ -259,14 +238,14 @@ static const struct drm_panel_funcs
> sharp_nt_panel_funcs = {
> static int sharp_nt_panel_add(struct sharp_nt_panel *sharp_nt)
> {
> struct device *dev = &sharp
Hi Chad,
On 24 March 2017 at 20:44, Chad Versace wrote:
> On Tue 21 Mar 2017, Matt Turner wrote:
>> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov
>> wrote:
>> > On 20 March 2017 at 18:30, Matt Turner wrote:
>> >> On Mon, Mar 20, 2017 at 6:55 AM, Emil V
s on, and export.
>
> Signed-off-by: Adam Jackson
Makes sense.
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
M_EXTENSIONS
> AC_SYS_LARGEFILE
> AC_FUNC_ALLOCA
>
> +save_CFLAGS="$CFLAGS"
> +export CFLAGS="$CFLAGS -Werror"
> AC_HEADER_MAJOR
> +CFLAGS="$save_CFLAGS"
> +
IIRC the Sun compiler supports (albei
Hi Christophe,
s/fix some error handling in 'ls_ucode_img_load_gr/plug memory leak in
ls_ucode_img_load_gr() error path/
On 8 May 2017 at 08:46, Christophe JAILLET
wrote:
> The last goto looks spurious because it releases less resources than the
> previous one.
> Add a new label in order to free
Hi Marek,
A couple of small nitpicks from UAPI POV.
On 8 May 2017 at 10:11, Marek Szyprowski wrote:
> --- a/include/uapi/drm/exynos_drm.h
> +++ b/include/uapi/drm/exynos_drm.h
> +struct drm_exynos_pp_get_res {
> + __u64 pp_id_ptr;
> + __u32 count_pps;
Add __u32 pad - sizeof(struct
Hi Rob,
On 14 May 2017 at 18:26, Robert Foss wrote:
> Add DRM_ROTATE_ and DRM_REFLECT_ defines to the UAPI as a convenience.
>
> Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up
> through the atomic API, but realizing that userspace is likely to take
> shortcuts and assume that
On 15 May 2017 at 18:13, Robert Foss wrote:
>
>
> On 2017-05-15 09:23 AM, Emil Velikov wrote:
>>
>> Hi Rob,
>>
>> On 14 May 2017 at 18:26, Robert Foss wrote:
>>>
>>> Add DRM_ROTATE_ and DRM_REFLECT_ defines to the UAPI as a convenience.
>&g
wsky
> Reviewed-by: Daniel Stone
I think this is almost perfect, barring the UAPI nitpick.
The rest is somewhat of a bikeshedding.
With the UAPI resolved, regardless of the rest
Reviewed-by: Emil Velikov
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> +
Hi Ben,
A couple of small questions/suggestions that I hope you find useful.
Please don't block any of this work based on my comments.
On 16 May 2017 at 22:31, Ben Widawsky wrote:
> +static bool intel_primary_plane_format_mod_supported(struct drm_plane *plane,
> +
Hi Qiang Yu,
On 17 May 2017 at 10:26, Qiang Yu wrote:
> error log:
> xf86drm.c: In function 'parse_separate_sysfs_files':
> xf86drm.c:3104:5: error: 'for' loop initial declarations are only allowed in
> C99 mode
> for (unsigned i = ignore_revision ? 1 : 0; i < ARRAY_SIZE(attrs); i++) {
>
On 17 May 2017 at 14:58, Yu, Qiang wrote:
> Hi Emil,
>
> I didn't modify the code. I'm using Ubuntu 14.04 gcc 4.8.4, the configure
> pass but
> fail when compile.
>
> I think my gcc support c99 but needs adding "-std=c99" to enable it, and the
> configure
> script add it into CC variable. When j
PROP_
> - Updated uses of the defines to the new prefix
> - Removed include from drm_rect.c
> - Stopped using the BIT() macro
>
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 18 May 2017 at 01:46, Ben Widawsky wrote:
>>> + blob_size += modifiers_size;
>>> +
>>> + blob = drm_property_create_blob(dev, blob_size, NULL);
>>> + if (IS_ERR(blob))
>>> + return -1;
>>> +
>>
>> Maybe propagate the exact error... Hmm we don't seem to check if
On 18 May 2017 at 02:14, Ben Widawsky wrote:
> On 17-05-17 01:20:50, Emil Velikov wrote:
>>
>> Hi Ben,
>>
>> A couple of small questions/suggestions that I hope you find useful.
>> Please don't block any of this work based on my comments.
>>
>
On 17 May 2017 at 19:16, Eric Engestrom wrote:
> On Wednesday, 2017-05-17 13:58:42 +, Yu, Qiang wrote:
>> Hi Emil,
>>
>> I didn't modify the code. I'm using Ubuntu 14.04 gcc 4.8.4, the configure
>> pass but
>> fail when compile.
>>
>> I think my gcc support c99 but needs adding "-std=c99" to
On 18 May 2017 at 13:47, Eric Engestrom wrote:
>> > Yes, I think you should change your build command. It's a shame that
>> > autotools has this bug, but we'd like to avoid changing our codebase to
>> > work around these, and in this case, it would mean dropping the C99
>> > requirement and havin
On 18 May 2017 at 14:46, Emil Velikov wrote:
> On 18 May 2017 at 13:47, Eric Engestrom wrote:
>
>>> > Yes, I think you should change your build command. It's a shame that
>>> > autotools has this bug, but we'd like to avoid changing our codebase to
>&
On 20 May 2017 at 19:24, enh wrote:
> Bug: https://github.com/android-ndk/ndk/issues/398
> ---
> Android.common.mk | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Android.common.mk b/Android.common.mk
> index 35c0f02c..b45ca10f 100644
> --- a/Android.common.mk
> +++ b/Android.common.mk
>
On 28 May 2017 at 15:38, Rob Herring wrote:
> On Mon, May 22, 2017 at 11:06 AM, Emil Velikov
> wrote:
>> On 20 May 2017 at 19:24, enh wrote:
>>> Bug: https://github.com/android-ndk/ndk/issues/398
>>> ---
>>> Android.common.mk | 1 +
>>> 1 f
On 1 June 2017 at 14:00, Chris Wilson wrote:
> Daniel started a crusade a few years back to move control over the
> initialisation and teardown into the driver rather than drm core, for
> greater control and far fewer surprises. Help in that fight by adding
> compiler warnings to the stale functio
Hi Marco,
Disclaimer: I'm mostly lurking around, barring the occasional patch so
please take my input with a grain of salt.
On 1 June 2017 at 23:46, Marco Diego Aurélio Mesquita
wrote:
> Hi Devs!
>
> On Thu, Jun 1, 2017 at 8:59 AM, Hans de Goede wrote:
>> Hi All,
>>
>> This is a resend of a pat
; Signed-off-by: Eric Engestrom
Looks spot-on. Thanks!
For the series
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Noralf,
Small drive-by comment, noticed while going through my morning coffee.
By no means a full review.
On 2 June 2017 at 12:49, Noralf Trønnes wrote:
> +/* pixels on display are numbered from 1 */
> +static void repaper_all_pixels(struct repaper_epd *epd, u8 **pp,
> +
On 2 June 2017 at 17:39, Marco Diego Aurélio Mesquita
wrote:
> Hi Emil!
>
> On Fri, Jun 2, 2017 at 1:14 PM, Emil Velikov wrote:
>> As Daniel mentioned in the earlier thread, factoring out things can be
>> done as a follow-up.
>> On the other hand, I _think_ that the b
On 7 June 2017 at 12:52, Noralf Trønnes wrote:
> Hi Emil,
>
>
> Den 07.06.2017 11.30, skrev Emil Velikov:
>>
>> Hi Noralf,
>>
>> Small drive-by comment, noticed while going through my morning coffee.
>> By no means a full review.
>>
&
On 21 October 2016 at 18:12, Eric Anholt wrote:
> From: Rob Herring
>
> Fixes crashes in Mesa on platform device, which expected *device to
> have a device when 0 was returned.
>
> (code from a paste by Rob, commit message by anholt)
>
> Signed-off-by: Eric Anholt
R
On 21 October 2016 at 18:12, Eric Anholt wrote:
> glxgears was spamming this 12 times at startup because of Mesa's
> probing of the DRM device code, which doesn't support platform
> devices.
>
Better option is to add support for platform devices. Can we get
anyone interested in that ?
If we drop (
From: Emil Velikov
If the C runtime doesn't provide the pthread stubs itself, pthread-stubs
will create a library which although it might work is quite fragile and
can cause issues like https://bugs.freedesktop.org/show_bug.cgi?id=98048
Consider the following:
Foo uses pthread-stubs l
From: Emil Velikov
As per last commit, we only use the package to check if the runtime is
pthread (stub) aware or not. We don't want to use the contents of the
variables, if any.
Signed-off-by: Emil Velikov
---
We can ignore this patch if we consider doing the
PTHREADSTUBS_{CFLAGS
On 31 October 2016 at 13:44, Rob Clark wrote:
> From: Rob Clark
>
> Rather than cut/pasting these couple ioctl wrappers everywhere, just
> stuff them as static-inline into a header.
>
> Signed-off-by: Rob Clark
> ---
> This is probably mostly used from mesa, but some drivers, test apps, etc
> ma
On 31 October 2016 at 16:39, Rob Clark wrote:
> On Mon, Oct 31, 2016 at 11:25 AM, Emil Velikov
> wrote:
>> On 31 October 2016 at 13:44, Rob Clark wrote:
>>> From: Rob Clark
>>>
>>> Rather than cut/pasting these couple ioctl wrappers everywhere, just
On 31 October 2016 at 17:44, Rob Clark wrote:
> On Mon, Oct 31, 2016 at 1:15 PM, Emil Velikov
> wrote:
>> On 31 October 2016 at 16:39, Rob Clark wrote:
>>> On Mon, Oct 31, 2016 at 11:25 AM, Emil Velikov >> gmail.com> wrote:
>>>> On 31 October 2016 a
On 1 September 2016 at 02:48, Nicolas Boichat wrote:
> From: Daniel Kurtz
>
> There is a mediatek drm kms driver: Add "mediatek" to the static
> lists of driver names.
>
Pushed as well as the modetest patch. Thanks !
Can I interest you in adding support for platform devices in the DRM
device API
On 1 September 2016 at 20:08, Christian Gmeiner
wrote:
> Hi Emil,
>
> thanks a lot for the review.
>
> 2016-08-30 15:03 GMT+02:00 Emil Velikov :
>> On 30 August 2016 at 08:14, Christian Gmeiner
>> wrote:
>>> From: The etnaviv authors
>>>
>>>
On 1 September 2016 at 20:03, Harry Wentland wrote:
> Bumping this one up again. This patch is fairly contained and is a
> pre-requisite for drivers that want 4k at 60 mode support on HDMI.
>
Afaics Daniel Vetter replied ~4 months ago [1] with a link to a (imho)
more comprehensive series + a reque
Hi Tomeu,
On 5 August 2016 at 11:45, Tomeu Vizoso wrote:
> +#ifdef CONFIG_DEBUG_FS
> + spin_lock_init(&crtc->crc.lock);
> + init_waitqueue_head(&crtc->crc.wq);
> + crtc->crc.source = kstrdup("auto", GFP_KERNEL);
Pedantic: kstrdup() can never fail ?
> +#endif
> +
> if (
Hi Tomeu,
IMHO it would be better to split out the refactoring into preparatory
patch. It brings a minor change which (not 100% sure on that) should
not cause issues but is worth pointing out.
On 5 August 2016 at 11:45, Tomeu Vizoso wrote:
> +static int do_set_crc_source(struct drm_device *dev,
On 5 September 2016 at 10:45, Tomeu Vizoso
wrote:
> On 2 September 2016 at 17:18, Emil Velikov
> wrote:
>> Hi Tomeu,
>>
>> IMHO it would be better to split out the refactoring into preparatory
>> patch. It brings a minor change which (not 100% sure on that) sho
[Trimming down the CC list]
Hi Baoyou,
On 7 September 2016 at 12:05, Baoyou Xie wrote:
> We get 2 warnings when building kernel with W=1:
As you're going through DRM I was wondering if you have a rough number
of warnings we get at the various W levels 1,2,...
Hope you'll have the time/interest
Hi Tomeu,
A couple of small nitpicks and a rather nasty looking bug, related to
your earlier question.
On 7 September 2016 at 11:27, Tomeu Vizoso
wrote:
> +static ssize_t crc_control_write(struct file *file, const char __user *ubuf,
> +size_t len, loff_t *offp)
's known that they contain wrong
> data.
Even if the frames are only skipped in the new code, it doesn't
explain why one'd need it in the first place and/or how it isn't
required with the current code. Might be worth poking the original
authors and/or adding a big
suggestions Tomeu. I think
I've spotted a bug in 2/4, plus there's a couple of trivial nitpicks
in 2/4 and 3/4 - either of which can be fixed as a follow up (if I
haven't lost it of course).
With the bug trivially fixed the series is:
Reviewed-by: Emil Velikov
-Emil
On 8 September 2016 at 15:49, Tomeu Vizoso
wrote:
> On 8 September 2016 at 15:24, Emil Velikov
> wrote:
>> Hi Tomeu,
>>
>> A couple of small nitpicks and a rather nasty looking bug, related to
>> your earlier question.
>>
>> On 7 September 2016 at 11:2
On 8 September 2016 at 10:56, Arnd Bergmann wrote:
> On Thursday, September 8, 2016 10:35:17 AM CEST Emil Velikov wrote:
>> On 7 September 2016 at 12:05, Baoyou Xie wrote:
>> > We get 2 warnings when building kernel with W=1:
>> As you're going through DRM I was
On 9 September 2016 at 12:24, Christian König
wrote:
> Hi Hawking,
>
>> Removing the flag will make ttm_mem_type_from_place skip counting the
>> corresponding placement and thus have impact on mem region create and bo
>> movement.
>
> And that is exactly the reason why I want to remove the unuse
On 9 September 2016 at 15:30, Christian König
wrote:
> Am 09.09.2016 um 15:54 schrieb Emil Velikov:
>>
>> On 9 September 2016 at 12:24, Christian König
>> wrote:
>>>
>>> Hi Hawking,
>>>
>>>> Removing the flag will make ttm_mem_type_f
Hi Robert,
I think I've spotted one interesting, yet trivial bit.
On 14 September 2016 at 15:19, Robert Bragg wrote:
> Adds base i915 perf infrastructure for Gen performance metrics.
>
> This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
> properties to configure a stream o
On 19 September 2016 at 14:33, wrote:
> --- a/drivers/gpu/drm/msm/msm_fb.c
> +++ b/drivers/gpu/drm/msm/msm_fb.c
> @@ -132,7 +132,7 @@ const struct msm_format *msm_framebuffer_format(struct
> drm_framebuffer *fb)
> struct drm_framebuffer *msm_framebuffer_create(struct drm_device *dev,
>
On 19 September 2016 at 16:33, Jani Nikula
wrote:
> On Mon, 19 Sep 2016, Emil Velikov wrote:
>> On 19 September 2016 at 14:33, wrote:
>>
>>> --- a/drivers/gpu/drm/msm/msm_fb.c
>>> +++ b/drivers/gpu/drm/msm/msm_fb.c
>>> @@ -132,7 +132,7 @@ const struct
On 5 September 2016 at 14:16, Peter Griffin wrote:
> ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> recursive dependency.
>
>From a humble skim through remoteproc, drm and a few other subsystems
I think the above is wrong. All the drivers (outside of remoteproc),
that I'v
On Monday, 19 September 2016, Peter Griffin
wrote:
> ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
> recursive dependency.
>
> It must not select, it must depend? Did you miss my earlier
question/suggestion that mentions that ?
Regards,
Emil
-- next part
On Tuesday, 20 September 2016, Emil Velikov
wrote:
> Did you miss my earlier question/suggestion that mentions that ?
>
Please scratch that. Just noticed the timestamps.
Emil
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freede
On 20 September 2016 at 09:32, Peter Griffin
wrote:
> Hi Emil,
>
> On Tue, 20 Sep 2016, Emil Velikov wrote:
>
>> On 5 September 2016 at 14:16, Peter Griffin
>> wrote:
>> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the following
>> >
On 21 September 2016 at 15:59, Tom Gundersen wrote:
> If passing name == NULL to drm_drv_set_unique() we now get -ENOMEM
> as kstrdup() returns NULL. Instead check for this explicitly and
> return -EINVAL if no name is provided.
>
> Signed-off-by: Tom Gundersen
> ---
> drivers/gpu/drm/drm_drv.c
On 23 September 2016 at 09:50, SF Markus Elfring
wrote:
>> Markus, please contact the list in advance in future before posting a bunch
>> of patches that don't fix any problems.
>
> I am trying to improve various open issues also in Linux source files.
>
That the fact that you see issues (in these
On 27 September 2016 at 17:04, Joe Perches wrote:
> On Tue, 2016-09-27 at 11:58 -0400, Sean Paul wrote:
>> > On Sun, Sep 25, 2016 at 10:18 PM, Joe Perches wrote:
>> > Use a bit more consistent style with kernel loglevels
>> > I'm not convinced this is worth doing if we're going to keep the
>> WAR
On 27 September 2016 at 17:43, Joe Perches wrote:
> On Tue, 2016-09-27 at 17:36 +0100, Emil Velikov wrote:
>> On 27 September 2016 at 17:04, Joe Perches wrote:
>> > On Tue, 2016-09-27 at 11:58 -0400, Sean Paul wrote:
>> > > On Sun, Sep 25, 2016 at 10:18 PM, Joe Perc
>> > registering drm_minor in
>> >
>> > 'commit 48c787899882 ("drm: Add API for capturing frame CRCs")'
>> >
>> > caused kernel oops. So, let's add CRC debugfs files
>> > only for those drivers that do modeset.
>&g
Hi all
On 30 September 2016 at 04:09, Laszlo Ersek wrote:
> Hello Daniel,
>
> On 06/21/16 14:08, daniel.vetter at ffwll.ch (Daniel Vetter) wrote:
>> We already have a fallback in place to fill out the unique from
>> dev->unique, which is set to something reasonable in drm_dev_alloc.
>>
>> Which m
On 30 September 2016 at 10:55, Emil Velikov wrote:
> Hi all
>
> On 30 September 2016 at 04:09, Laszlo Ersek wrote:
>> Hello Daniel,
>>
>> On 06/21/16 14:08, daniel.vetter at ffwll.ch (Daniel Vetter) wrote:
>>> We already have a fallback in place to fill out th
Hi Shawn,
A couple of fly-by suggestions, which I hope you'll find useful :-)
On 24 September 2016 at 15:26, Shawn Guo wrote:
> +
> + val = ((vm.hsync_len - 1) << SYNC_WIDE_SHIFT) & SYNC_WIDE_MASK;
To save some writing/minimise the chances to typos getting, in you can
have single/collect
On 2 January 2017 at 13:26, Thierry Reding wrote:
> On Sat, Dec 24, 2016 at 04:38:04PM +0000, Emil Velikov wrote:
>> Hi Thierry,
>>
>> On 23 December 2016 at 17:49, Thierry Reding
>> wrote:
>> > Allow DRM/KMS devices hosted on USB to be detected
On 2 January 2017 at 13:53, Thierry Reding wrote:
> On Sat, Dec 24, 2016 at 05:00:27PM +0000, Emil Velikov wrote:
>> On 23 December 2016 at 17:49, Thierry Reding
>> wrote:
>> > From: Thierry Reding
>> >
>> > ARM SoCs usually have their DRM/KMS device
more flexible using a format string
>>
>> Signed-off-by: Thierry Reding
>
> All this sysfs parsing stuff is highly Linux-specific and should
> probably be #ifdef __linux__. Returning -EINVAL on non-Linux
> platforms for usb and host1x should be fine.
>
Nicely spotted. Th
On 12 January 2017 at 21:35, Thierry Reding wrote:
> From: Thierry Reding
>
> Signed-off-by: Thierry Reding
This and 2/2 are
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freede
ict-aliasing rules [-Wstrict-aliasing]
>e = (struct drm_event *)(&buffer[i]);
>^
>
> Signed-off-by: Thierry Reding
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99350
Reviewed-by: Emil Velikov
-Emil
On 13 January 2017 at 21:11, Nicholas Miell wrote:
> On 01/13/2017 09:57 AM, Emil Velikov wrote:
>>
>> On 13 January 2017 at 11:34, Jan Vesely wrote:
>>>
>>> On Thu, 2017-01-12 at 18:16 -0800, Nicholas Miell wrote:
>>>>
>>>> From 714d07f6
On 16 January 2017 at 01:09, Fabio Estevam wrote:
> Fix two grammar issues:
>
> - "standard autotools packages ---> "standard autotools package"
> - "If you are install" ---> "If you are installing"
>
> Signed-off-by: Fabio Estevam
R-b and pushed to master.
Thanks !
Emil
On 18 January 2017 at 09:02, Thierry Reding wrote:
> From: Thierry Reding
>
> ARM SoCs usually have their DRM/KMS devices on the platform bus, so add
> support for that to enable these devices to be used with the drmDevice
> infrastructure.
>
> NVIDIA Tegra SoCs have an additional level in the hi
On 19 January 2017 at 09:19, Thierry Reding wrote:
> On Wed, Jan 18, 2017 at 02:59:21PM +0100, Neil Armstrong wrote:
>> Add support for Amlogic Meson DRM driver merged for Linux 4.10.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> tests/util/kms.c | 1 +
>> 1 file changed, 1 insertion(+)
>
> Appl
On 20 January 2017 at 16:17, Thierry Reding wrote:
> On Fri, Jan 20, 2017 at 02:13:00PM +0000, Emil Velikov wrote:
>> On 19 January 2017 at 09:19, Thierry Reding wrote:
>> > On Wed, Jan 18, 2017 at 02:59:21PM +0100, Neil Armstrong wrote:
>> >> Add support for Amlog
Seems to be the default option. Fleshed out from a larger commit in the
AOSP repo/fork.
Cc: Dan Willemsen
Cc: Chih-Wei Huang
Cc: Rob Herring
Signed-off-by: Emil Velikov
---
Dan a couple of humble requests:
- can we get a reference when (Android vX) this is the default ?
- there's a bun
IRS, which shouldn't be an issue.
Cc: Chih-Wei Huang
Cc: Rob Herring
Signed-off-by: Emil Velikov
---
Android.common.mk | 6 ++
Android.mk| 17 ++---
amdgpu/Android.mk | 7 ++-
etnaviv/Android.mk| 7 ++-
freedreno/Andro
Cc: Chih-Wei Huang
Cc: Rob Herring
Signed-off-by: Emil Velikov
---
Android.common.mk | 1 +
1 file changed, 1 insertion(+)
diff --git a/Android.common.mk b/Android.common.mk
index ffe92198..71f14ec3 100644
--- a/Android.common.mk
+++ b/Android.common.mk
@@ -1,3 +1,4 @@
+# XXX: Consider moving
Analogous to the autoconf build add the following to the build
-Wno-unused-parameter
-Wno-missing-field-initializers
Cc: Chih-Wei Huang
Cc: Rob Herring
Signed-off-by: Emil Velikov
---
According to Rob's jenkins build there's still some 26 libdrm warnings
libdrm most of which
601 - 700 of 2172 matches
Mail list logo
