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 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
>> > recursive d
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
[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 WARNING/
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:27,
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 17 August 2017 at 11:37, Colin King wrote:
> From: Colin Ian King
>
> The check to see if mstm->msto is null is redundant because it is
> an array and hence can never be null. Remove the redundant check.
>
> Detected by CoverityScan, CID#1375915 ("Array compared against 0")
>
> Signed-off-by:
On 19 June 2017 at 17:31, Krzysztof Kozlowski wrote:
> Although header is included only once but still having an include guard
> is a good practice. To avoid confusion, add SoC prefix to existing
> Exynos5433 header include guard.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> include/video/exy
On 20 June 2017 at 11:02, Krzysztof Kozlowski wrote:
> On Tue, Jun 20, 2017 at 11:53 AM, Emil Velikov
> wrote:
>> On 19 June 2017 at 17:31, Krzysztof Kozlowski wrote:
>>> Although header is included only once but still having an include guard
>>> is a good prac
On 15 October 2015 at 06:55, Mikko Rapeli wrote:
> Fixes userspace compile error since list_head is not exported to userspace
> headers.
>
> Suggested by Emil Velikov at
> https://lkml.org/lkml/2015/6/3/792
>
> Signed-off-by: Mikko Rapeli
We're safe as the only u
On 15 October 2015 at 06:55, Mikko Rapeli wrote:
> Fixes userspace compile error:
>
> drm/sis_drm.h:68:19: error: field ‘obj_list’ has incomplete type
> struct list_head obj_list;
>
> Suggested by Emil Velikov at
> https://lkml.org/lkml/2015/6/3/792
>
>
On 15 October 2015 at 06:55, Mikko Rapeli wrote:
> Fixes compiler error:
>
> drm/via_drm.h:36:27: fatal error: via_drmclient.h: No such file or directory
>
> Signed-off-by: Mikko Rapeli
> ---
> include/uapi/drm/via_drm.h | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/include/uapi/drm
e last few years we've been doing some ad-hoc 'synchronisation'
with the headers in libdrm, and this will get us one step closer to
doing things properly.
Fwiw I fully support these changes, as does Gustavo for exynos and Rob for msm.
Reviewed-by: Emil Velikov
Thanks
Emil
--
To unsubs
On 21 October 2015 at 16:18, Alex Deucher wrote:
> On Wed, Oct 21, 2015 at 11:09 AM, Emil Velikov
> wrote:
>> Hi Alex,
>>
>> On 15 October 2015 at 14:48, Mikko Rapeli wrote:
>>> On Thu, Oct 15, 2015 at 09:32:10AM -0400, Alex Deucher wrote:
>>>>
On 21 October 2015 at 16:33, Daniel Vetter wrote:
> On Wed, Oct 21, 2015 at 03:36:22PM +0100, Emil Velikov wrote:
>> On 15 October 2015 at 06:55, Mikko Rapeli wrote:
>> > Fixes userspace compile error since list_head is not exported to userspace
>> > headers.
>>
On 21 October 2015 at 17:27, Alex Deucher wrote:
> On Wed, Oct 21, 2015 at 12:21 PM, Emil Velikov
> wrote:
>> On 21 October 2015 at 16:18, Alex Deucher wrote:
>>> On Wed, Oct 21, 2015 at 11:09 AM, Emil Velikov
>>> wrote:
>>>> Hi Alex,
>>&
[Dropping the CC list]
Hi Yakir Yang,
On 1 September 2015 at 06:49, Yakir Yang wrote:
> Split the dp core driver from exynos directory to bridge
> directory, and rename the core driver to analogix_dp_*,
> leave the platform code to analogix_dp-exynos.
>
> Signed-off-by: Yakir Yang
> ---
> Chang
On 19 October 2015 at 15:50, Russell King - ARM Linux
wrote:
> On Mon, Oct 19, 2015 at 04:42:25PM +0200, Daniel Vetter wrote:
>> On Mon, Oct 19, 2015 at 02:26:38PM +0100, Russell King - ARM Linux wrote:
>> > On Mon, Oct 19, 2015 at 02:02:58PM +0100, Liviu Dudau wrote:
>> > > On Mon, Oct 19, 2015 a
Hi Liviu,
On 20 October 2015 at 10:23, Liviu Dudau wrote:
> A lot of component based DRM drivers use a variant of the same code
> as the probe function. They bind the crtc ports in the first iteration
> and then scan through the child nodes and bind the encoders attached
> to the remote endpoints
Hi Maciej,
On 2 October 2015 at 22:40, Maciej S. Szmigiero
wrote:
> Anybody here?
>
> I've already submitted this patch two times but received no response...
>
Seems that the maintainer (Thierry) isn't Cc'ed. You might want to
split the DT binding and vendor prefix to separate patches.
-Emil
--
On 7 August 2018 at 13:28, Daniel Vetter wrote:
> On Tue, Aug 07, 2018 at 12:01:50PM +0100, Emil Velikov wrote:
>> On 3 August 2018 at 20:50, Sean Paul wrote:
>> > On Fri, Aug 03, 2018 at 06:03:50PM +0100, Emil Velikov wrote:
>> >> On 3 August 2018 at 16:0
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 17 January 2018 at 14:01, Daniel Vetter wrote:
> Nothing in the entire tree ever sets this, which means this is dead
> code. Remove it.
>
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo Han
> Signed-off-by: Daniel Vetter
> ---
> drivers/video/backlight/generic_bl.c | 5 -
Fly-by com
On 17 January 2018 at 16:37, Daniel Thompson wrote:
>
>
> On 17/01/18 14:36, Emil Velikov wrote:
>>
>> On 17 January 2018 at 14:01, Daniel Vetter wrote:
>>>
>>> Nothing in the entire tree ever sets this, which means this is dead
>>> code. Remove it
On 20 March 2018 at 06:24, hl wrote:
> Hi Emil,
>
>
>
> On Monday, March 19, 2018 09:09 PM, Emil Velikov wrote:
>>
>> On 15 March 2018 at 02:35, hl wrote:
>>>
>>> Hi Emil,
>>>
>>>
>>>
>>> On Wednesday, March 14, 2
Hi Gustavo,
On 7 March 2018 at 19:54, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wvla, remove VLA and replace it
> with a fixed-length array instead. Also, remove variable 'len'.
>
What is the reason behind adding -Wvla? Is there a thread some that I
can read up on?
> Notice that n
s looks good to me:
> Reviewed-by: Eric Engestrom
>
Same here
Reviewed-by: Emil Velikov
-Emil
Hi Lin,
On 14 March 2018 at 09:12, Lin Huang wrote:
> From: huang lin
>
> Refactor Innolux P079ZCA panel driver, let it support
> multi panel.
>
> Change-Id: If89be5e56dba8cb498e2d50c1bbeb0e8016123a2
> Signed-off-by: Lin Huang
> ---
> Changes in v2:
> - Change regulator property name to meet th
On 14 March 2018 at 09:12, Lin Huang wrote:
> Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel, it reuse
> the Innolux P079ZCA panel driver.
>
> Change-Id: I97923aa3735f707332681691b0231c9421b427d0
> Signed-off-by: Lin Huang
> ---
> Changes in v2:
> - None
> Changes in v3:
> - None
> Changes
On 14 March 2018 at 09:12, Lin Huang wrote:
> From: huang lin
>
> The Innolux P097PFG panel is 9.7" panel with 1536X2048
> resolution, it reuse P079ZCA panel driver, so improve
> p079ZCA dt-binding to support P097PFG.
>
> Change-Id: I8704914898fe53b734d31fbe646df8aa5fd8b30d
> Signed-off-by: Lin H
Hi Lowry,
Small drive-by suggestion. Haven't checked if others have pointed it
out previously :-\
On 30 May 2018 at 12:23, Lowry Li wrote:
> +/**
> + * drm_plane_create_blend_mode_property - create a new blend mode property
> + * @plane: drm plane
> + * @supported_modes: bitmask of supported mo
On Tue, 30 Oct 2018 at 13:52, Gerd Hoffmann wrote:
>
> On Tue, Oct 30, 2018 at 11:31:04AM +, Emil Velikov wrote:
> > HI Gerd,
> >
> > On Tue, 30 Oct 2018 at 06:11, Gerd Hoffmann wrote:
> > >
> > > Hi,
> > >
> > > > The ex
Hi Shayenne,
Welcome to DRM.
As far as I can see you're a newcomer to kernel development, so I'd
recommend watch a recent talk from Marc [1]
He provides a very good introduction, both for newbies and for people
willing the know the deeper reasons behind.
That said, here's some suggestions:
On W
On 2024/08/21, Nathan Chancellor wrote:
> On Tue, Dec 19, 2023 at 05:37:31PM +0900, Masahiro Yamada wrote:
> > On Thu, Dec 7, 2023 at 3:37 AM Lucas De Marchi
> > wrote:
> > >
> > > On Fri, Nov 10, 2023 at 01:13:53PM +0100, Michal Suchanek wrote:
> > > >Hello,
> > > >
> > > >This is resend of the
Greetings everyone,
On Mon, 15 Feb 2021 at 08:52, Lee Jones wrote:
>
> On Fri, 12 Feb 2021, Krzysztof Kozlowski wrote:
>
> > Milo Kim's email in TI bounces with permanent error (550: Invalid
> > recipient). Last email from him on LKML was in 2017. Move Milo Kim to
> > credits and remove the sep
On 23/12/14 10:40, Vince Hsu wrote:
> This patch adds some checks in the suspend/resume functions to distinguish
> the dGPU and mobile GPU and exports some variables/functions so that the
> nouveau platform device can reuse them.
>
Hi Vince,
Afaiu one needs to export a symbol as it's used by anot
On 20 March 2015 at 11:14, Javi Merino wrote:
> We have grown a number of different implementations of
> DIV_ROUND_CLOSEST_ULL throughout the kernel. Move the i915 one to
> kernel.h so that it can be reused.
>
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: David Airlie
> Cc: Darrick J. Wong
> Cc
On 23 February 2015 at 10:35, Mikko Rapeli wrote:
> On Mon, Feb 23, 2015 at 10:26:58AM +0000, Emil Velikov wrote:
>> On 16/02/15 23:05, Mikko Rapeli wrote:
>> > Fixes compilation error:
>> >
>> > drm/drm.h:132:2: error: unknown type name ‘size_t’
>> &g
Hi Jilai,
Just a few questions, not really a review as I'm not that familiar
with the code.
> +++ b/drivers/gpu/drm/msm/Kconfig
> @@ -27,6 +27,16 @@ config DRM_MSM_FBDEV
> support. Note that this support also provide the linux console
> support on top of the MSM modesetting d
On 2 April 2015 at 19:07, wrote:
> Thanks Emil. Please check the comments embedded and for the rest I will
> update the code.
>
>> Hi Jilai,
>>
>> Just a few questions, not really a review as I'm not that familiar
>> with the code.
>>
>>
>>> +++ b/drivers/gpu/drm/msm/Kconfig
>>> @@ -27,6 +27,16 @
Hi Mikko
Pardon for the late response,
On 21 March 2015 at 12:17, Mikko Rapeli wrote:
> On Fri, Mar 20, 2015 at 08:25:40PM +0000, Emil Velikov wrote:
>> On 23 February 2015 at 10:35, Mikko Rapeli wrote:
>> > On Mon, Feb 23, 2015 at 10:26:58AM +, Emil Velikov wrote:
>&
Hi Dongxing Zhang,
On 11 June 2015 at 09:14, Dongxing Zhang wrote:
> unreferenced object 0x8800bd132fe8 (size 256):
> comm "Xorg", pid 1260, jiffies 4294901661 (age 660.504s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 e8 2f 13 bd 00 88 ff ff ./..
> 01 00 0
Hi Mikko,
On 30 May 2015 at 16:38, Mikko Rapeli wrote:
> Fixes compiler error since list_head is not exported to userspace headers.
>
> Signed-off-by: Mikko Rapeli
> ---
> include/uapi/drm/via_drm.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/uapi/drm/via_drm.h b/include/
Hi Mikko,
On 30 May 2015 at 16:38, Mikko Rapeli wrote:
> Fixes compiler error:
>
> drm/via_drm.h:36:27: fatal error: via_drmclient.h: No such file or directory
>
> Signed-off-by: Mikko Rapeli
> ---
> include/uapi/drm/via_drm.h | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff
On 30 May 2015 at 16:37, Mikko Rapeli wrote:
> Fixes userspace compilation error:
>
> drm/drm.h:132:2: error: unknown type name ‘size_t’
>
> Signed-off-by: Mikko Rapeli
> ---
> include/uapi/drm/drm.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/include/uapi/dr
On 3 June 2015 at 18:16, Emil Velikov wrote:
> Hi Mikko,
>
> On 30 May 2015 at 16:38, Mikko Rapeli wrote:
>> Fixes compiler error:
>>
>> drm/via_drm.h:36:27: fatal error: via_drmclient.h: No such file or directory
>>
>> Signed-off-by: Mikko Rapeli
&g
On Fri, 5 Feb 2021 at 22:01, Chris Wilson wrote:
>
> Userspace has discovered the functionality offered by SYS_kcmp and has
> started to depend upon it. In particular, Mesa uses SYS_kcmp for
> os_same_file_description() in order to identify when two fd (e.g. device
> or dmabuf)
As you rightfully
On Fri, 12 Feb 2021 at 13:14, Simon Ser wrote:
>
> On Friday, February 12th, 2021 at 1:57 PM, Emil Velikov
> wrote:
>
> > On Fri, 5 Feb 2021 at 22:01, Chris Wilson wrote:
> > >
> > > Userspace has discovered the functionality offered by SYS_kcmp and has
On Fri, 12 Feb 2021 at 14:01, Michel Dänzer wrote:
>
> On 2021-02-12 1:57 p.m., Emil Velikov wrote:
> > On Fri, 5 Feb 2021 at 22:01, Chris Wilson wrote:
> >>
> >> Userspace has discovered the functionality offered by SYS_kcmp and has
> >> started to d
ince. So I
> think it's safe to retire those export types now.
>
I believe you're spot on - based on reading through git log and
checking the ML archives.
Shame I didn't get to finish a similar series I had locally. Patches
11-13 match what I have here so:
Reviewed-by: Emil Velikov
HTH
-Emil
On Sun, 31 May 2020 at 14:12, Sidong Yang wrote:
>
> Optimize looping pixels in compute_crc() and blend(). Calculate
> src_offset in start of looping horizontally and increase it.
> It's better than calculating in every pixels.
>
When you say "optimize" have you observed any actual benefits of the
> `drm_atomic_helper_connector_duplicate_state'
> drivers/gpu/drm/rcar-du/rcar_lvds.o:(.rodata+0xe10): undefined reference to
> `drm_atomic_helper_connector_destroy_state'
>
> Signed-off-by: Daniel Gomez
Nicely spotted.
AFAICT the only way this ever worked is if people
On 12/02/14 05:38, Alexandre Courbot wrote:
> Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead
> of PCI to which Nouveau is tightly dependent. This patch allows Nouveau
> to handle platform devices by:
>
> - abstracting PCI-dependent functions that were typically used for
>
Hi Josh
On 05/09/14 18:19, Josh Boyer wrote:
> The userspace drm.h include doesn't prefix the drm directory. This can lead
> to compile failures as /usr/include/drm/ isn't in the standard gcc include
> paths. Fix it to be , which matches the rest of the driver drm
> header files that get install
On 08/09/14 13:14, Josh Boyer wrote:
> On Mon, Sep 8, 2014 at 8:01 AM, Emil Velikov wrote:
[snip]
>> Any objections if we update the libdrm header and drop the mesa/ddx copies ?
>>
>> Cheers,
>> Emil
>>
>> P.S. I'm against the patch in any way :)
>
On 08/09/14 13:15, Thomas Hellstrom wrote:
> Hi!
>
> On 09/08/2014 02:01 PM, Emil Velikov wrote:
[snip]
>>
>> To the VMware guys,
>>
>> Any objections if we update the libdrm header and drop the mesa/ddx copies ?
>>
>> Cheers,
>> Emil
> Hi!
&g
On 30 July 2015 at 16:02, Ilia Mirkin wrote:
> On Thu, Jul 30, 2015 at 10:56 AM, Bryan O'Donoghue
> wrote:
>> On 30/07/15 15:52, Bryan O'Donoghue wrote:
>>>
>>> On 30/07/15 15:49, Peter Hurley wrote:
On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
>
> Is this happening with libdrm 2.
On 17 August 2015 at 16:15, Liviu Dudau wrote:
> On Sun, Aug 16, 2015 at 09:56:33AM +0100, Emil Velikov wrote:
>> Hi Liviu,
>
> Hi Emil,
>
>>
>> On 5 August 2015 at 15:28, Liviu Dudau wrote:
>> > The HDLCD controller is a display controller that supports
On 13 August 2015 at 01:56, Eric Anholt wrote:
> This is the start of a full VC4 driver. Right now this just supports
> configuring the display using a pre-existing video mode (because
> changing the pixel clock isn't available yet, and doesn't work when it
> is). However, this is enough for fbc
Hi Liviu,
On 5 August 2015 at 15:28, Liviu Dudau wrote:
> The HDLCD controller is a display controller that supports resolutions
> up to 4096x4096 pixels. It is present on various development boards
> produced by ARM Ltd and emulated by the latest Fast Models from the
> company.
>
I believe there
Hi Enric,
On 14 April 2016 at 14:42, Enric Balletbo i Serra
wrote:
> The patch was implemented first without OR'ing error codes. The reason why I
> changed this is because I received the comments that checking the error on
> every regmap_* didn't help the readability of the driver and is likely t
On 15 April 2016 at 15:20, Julia Lawall wrote:
> On Fri, 15 Apr 2016, Christian König wrote:
>> Am 15.04.2016 um 09:15 schrieb Julia Lawall:
>> > Move constants to the right of binary operators.
>> >
>> > Generated by: scripts/coccinelle/misc/compare_const_fl.cocci
>> >
>> > Signed-off-by: Fenggua
On 22 May 2016 at 10:05, Geert Uytterhoeven wrote:
> Submitters of device tree binding documentation may forget to CC
> the subsystem maintainer if this is missing.
>
> Signed-off-by: Geert Uytterhoeven
> Cc: David Airlie
> Cc: dri-de...@lists.freedesktop.org
> ---
> Please apply this patch dire
Hi Liviu,
Humble request: For the future please split things into manageable
hunks. I doubt you wrote the whole thing in one go, right ?
At the very minimum you could have introduced DP500 support initially
and then DP550 and DP650 as follow up commits.
On 25 April 2016 at 15:19, Liviu Dudau wr
On 23 May 2016 at 13:35, Rob Herring wrote:
> On Mon, May 23, 2016 at 4:33 AM, Emil Velikov
> wrote:
>> On 22 May 2016 at 10:05, Geert Uytterhoeven wrote:
>>> Submitters of device tree binding documentation may forget to CC
>>> the subsystem maintainer if this is
Hi YT Shen,
On 12 May 2016 at 12:49, wrote:
> From: YT Shen
>
> This patch add support for the Mediatek MT2701 DISP subsystem.
> There is only one OVL engine in MT2701, and we have shadow
> register support here.
>
> Signed-off-by: YT Shen
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c |
On 17 May 2016 at 14:50, Benjamin Gaignard wrote:
> Hello Emil,
>
> thanks for your review.
> I have understand most of your remarks and I'm fixing them
> but some points aren't obvious for me...
>
Sure thing. Thanks for being honest.
>
> No because a device could attach itself on the buffer and
On 17 May 2016 at 22:29, Daniel Vetter wrote:
> Please don't use __kernel_size_t, it's only for backwards compat if you
> already botched an ioctl definition ;-)
>
That explains why I've not seen it in (m)any other UAPI headers but
our legacy ones.
Thank you !
Emil
not warn about this.
> I'm listing the merge commit as introducing the problem, because
> there are several patches in this branch that each do this for
> one file.
>
> Signed-off-by: Arnd Bergmann
> Fixes: 7c10ddf87472 ("Merge branch 'drm-uapi-extern-c-fixes
On 18 May 2016 at 09:33, YT Shen wrote:
>> > @@ -108,6 +108,10 @@ int mtk_drm_gem_dumb_create(struct drm_file
>> > *file_priv, struct drm_device *dev,
>> > int ret;
>> >
>> > args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
>> > + /*
>> > + * align to 8 bytes s
On 25 May 2016 at 17:40, Daniel Vetter wrote:
> On Mon, Mar 30, 2015 at 4:49 PM, Daniel Vetter wrote:
>> On Mon, Mar 30, 2015 at 02:23:47PM +0200, Gerd Hoffmann wrote:
>>> > > Signed-off-by: Dave Airlie
>>> > > Signed-off-by: Gerd Hoffmann
>>> >
>>> > Standard request from my side for new drm d
On 25 May 2016 at 17:13, Linus Torvalds wrote:
> On Wed, May 25, 2016 at 1:28 AM, Jani Nikula
> wrote:
>>
>> There may be better ones out there, but Artem's "aiaiai" has some
>> helpers [1] for diffing build logs, if you want something simple to
>> integrate into existing scripts.
>
> It would be
On 27 May 2016 at 08:31, YT Shen wrote:
> Hi CK,
>
>
> On Mon, 2016-05-23 at 17:43 +0800, CK Hu wrote:
>> Hi, YT:
>>
>> One comment below.
>>
>> On Fri, 2016-05-20 at 23:05 +0800, yt.s...@mediatek.com wrote:
>> > From: YT Shen
>> >
>> > There are some hardware settings changed, between MT8173 & M
On 20 May 2016 at 16:05, wrote:
> From: YT Shen
>
> Add MT8173 suffix for hardware related macros.
>
Why suffix ? Pretty much everyone else uses prefix.
-Emil
Hi YT Shen,
There's a typo in the commit summary - s/mediatke/mediatek/.
On 20 May 2016 at 16:05, wrote:
> From: YT Shen
>
> This patch add support for the Mediatek MT2701 DISP subsystem.
> There is only one OVL engine in MT2701.
>
As is you introduce a broken driver only to fix it up with pat
Hi Gustavo,
On 11 May 2016 at 14:45, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Add Gustavo as maintainer for the Sync File Framework. Sumit is
> co-maintainer as he maintains drivers/dma-buf/. It also uses Sumit's
> tree as base.
>
> Cc: Sumit Semwal
> Signed-off-by: Gustavo Padovan
>
Hi Benjamin,
I'd suspect you're interested in some feedback on these, so here is a few :-)
Sadly (ideally?) nothing serious, but a bunch minor suggestions, plus
the odd bug.
On 9 May 2016 at 16:07, Benjamin Gaignard wrote:
> --- /dev/null
> +++ b/drivers/smaf/smaf-core.c
> @@ -0,0 +1,794 @@
>
Hi Benjamin,
On 9 May 2016 at 16:07, Benjamin Gaignard wrote:
> SMAF CMA allocator implement helpers functions to allow SMAF
> to allocate contiguous memory.
>
> match() each if at least one of the attached devices have coherent_dma_mask
> set to DMA_BIT_MASK(32).
>
What is the idea behind the ha
Hi Benjamin,
On 9 May 2016 at 16:07, Benjamin Gaignard wrote:
> This module is allow testing secure calls of SMAF.
>
"Add fake secure module" does sound like something not (m)any people
want to hear ;-)
Have you considered calling it 'dummy', 'test' or similar ?
> --- /dev/null
> +++ b/drivers/
On 30 November 2015 at 14:10, Gabriel Laskar wrote:
> Signed-off-by: Gabriel Laskar
> CC: Emil Velikov
> CC: Mikko Rapeli
>
> ---
> include/uapi/drm/virtgpu_drm.h | 98
> +-
> 1 file changed, 49 insertions(+), 49 deletions(-)
&
Hi Eric,
A couple of suggestions/requests on the UAPI header side
On 1 December 2015 at 20:35, Eric Anholt wrote:
> --- /dev/null
> +++ b/include/uapi/drm/vc4_drm.h
> +#include
> +
Can we make this a "drm.h" ?
> +struct drm_vc4_create_bo {
> + uint32_t size;
> + uint32_t flags;
On 7 December 2015 at 12:11, Liviu Dudau wrote:
> Update MAINTAINERS file for HDLCD driver.
>
> Cc: Andrew Morton
> Cc: Arnd Bergmann
> Cc: Mauro Carvalho Chehab
> Cc: Greg KH
> Cc: Joe Perches
> Cc: Jiri Slaby
>
> Signed-off-by: Liviu Dudau
> ---
> MAINTAINERS | 6 ++
> 1 file changed
On 5 December 2015 at 21:03, Dave Airlie wrote:
> On 5 December 2015 at 00:22, Emil Velikov wrote:
>> On 30 November 2015 at 14:10, Gabriel Laskar wrote:
>>> Signed-off-by: Gabriel Laskar
>>> CC: Emil Velikov
>>> CC: Mikko Rapeli
>>>
>
On 19 November 2015 at 03:35, Chris Zhong wrote:
> The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller
> IP. This series adds support for a Synopsys DesignWare MIPI DSI host
> controller DRM bridge driver and a rockchip MIPI DSI specific DRM
> driver.
>
> This series also include
Hi Chris,
Missing Thierry from the To/Cc list ? His name/email should have
popped up when using the get_mainteiners.pl script.
On 19 November 2015 at 03:35, Chris Zhong wrote:
> This adds support for the BOE TV080WUM-NL0 1200x1920 mipi panel to the
> DRM simple panel driver.
>
> Signed-off-by: C
On 20 November 2015 at 07:02, Chris Zhong wrote:
> Hi Emil
>
> On 11/19/2015 10:41 PM, Emil Velikov wrote:
>>
>> On 19 November 2015 at 03:35, Chris Zhong wrote:
>>>
>>> The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller
>>
On 27 November 2015 at 15:10, Daniel Vetter wrote:
> This allows us to ditch a ton of ugly #ifdefs from a bunch of drm modeset
> drivers.
>
> v2: Make the dummy function actually return a sane value, spotted by
> Ville.
>
> Cc: Ville Syrjälä
> Cc: Andrew Morton
> Cc: Greg Kroah-Hartman
> Signed
On 27 November 2015 at 15:10, Daniel Vetter wrote:
> It only leads to bloodshed and tears - we don't bother to restore a
> working legacy vga hw setup.
>
> On haswell with the new dynamic power well code this leads to even
> more hilarity since for some configurations the hardware is simply no
> l
On 29 November 2015 at 12:47, Daniel Vetter wrote:
> On Fri, Nov 27, 2015 at 07:37:53PM -0500, Ilia Mirkin wrote:
>> On Fri, Nov 27, 2015 at 10:40 AM, Emil Velikov
>> wrote:
>> > On 27 November 2015 at 15:10, Daniel Vetter wrote:
>> >> It only leads to bloo
On 30 November 2015 at 19:47, Alex Deucher wrote:
> On Sat, Nov 28, 2015 at 4:01 PM, Pavel Machek wrote:
>>
>> Thinkpad T40p needs agpmode 1.
>>
>> Signed-off-by: Pavel Machek
>
> Seems odd that this wouldn't have been found earlier given how popular
> thinkpads are. Applied. Thanks,
>
Wonderi
Hi Eric,
On 1 December 2015 at 20:35, Eric Anholt wrote:
> The user submission is basically a pointer to a command list and a
> pointer to uniforms. We copy those in to the kernel, validate and
> relocate them, and store the result in a GPU BO which we queue for
> execution.
>
> Signed-off-by: E
Hi Eric,
On 1 December 2015 at 20:35, Eric Anholt wrote:
> Since we have no MMU, the kernel needs to validate that the submitted
> shader code won't make any accesses to memory that the user doesn't
> control, which involves banning some operations (general purpose DMA
> writes), and tracking whe
On 1 December 2015 at 20:35, Eric Anholt wrote:
> This can be parsed with vc4-gpu-tools tools for trying to figure out
> what was going on.
>
I might be pushing my luck here ... have you thought about basing
(forking) vc4-gpu-tools of intel-gpu-tools ? I'd imagine that the
macros and helpers will
On 2 December 2015 at 16:33, Alex Deucher wrote:
> On Wed, Dec 2, 2015 at 6:15 AM, Emil Velikov wrote:
>> On 30 November 2015 at 19:47, Alex Deucher wrote:
>>> On Sat, Nov 28, 2015 at 4:01 PM, Pavel Machek wrote:
>>>>
>>>> Thinkpad T40p needs agpmod
1 - 100 of 281 matches
Mail list logo
