Hi Tomi,
Thank you for the patches.
On Friday 26 February 2016 11:35:48 Tomi Valkeinen wrote:
> Hi,
>
> Here's a collection of patches for omapdrm. Some of them have been sent for
> review at some point, most of them haven't.
>
> There are two bigger features in the series: dmabuf import suppor
Hi Tomi,
Thank you for the patch.
On Friday 26 February 2016 11:36:08 Tomi Valkeinen wrote:
> On OMAP4 and OMAP5 ES1.0 the HDMI_WP_VIDEO_TIMING_H:HSW field is
> set directly to the HSW value. On later SoCs the field needs to be
> programmed with the value of HSW-1.
>
> Currently the driver alway
Hi Tomi,
Thank you for the patch.
On Friday 26 February 2016 11:35:59 Tomi Valkeinen wrote:
> If the panel's enable fails, omap_encoder silently ignores the failure.
> omapdrm should really handle the failure, but unfortunately the whole
> encoder enable codepath is expected to always succeed.
>
Hi Tomi,
Thank you for the patch.
On Friday 26 February 2016 11:35:58 Tomi Valkeinen wrote:
> omap_gem_dma_sync() calls dma_map_page() but does not check the possible
> error with dma_mapping_error(). If DMA-API debugging is enabled, the
> debug layer will give a warning if dma_mapping_error() ha
Hi Tomi,
Thank you for the patch.
On Friday 26 February 2016 11:35:49 Tomi Valkeinen wrote:
> We occasionally see DISPC sync-lost errors when enabling and disabling
> HDMI. Sometimes we get only a few, which get handled (ignored) by the
> driver, but sometimes there's a flood of the errors which
Hi Tomi,
Thank you for the patch.
On Friday 26 February 2016 11:35:57 Tomi Valkeinen wrote:
> omap_gem_attach_pages() calls dma_map_page() but does not check the
> possible error with dma_mapping_error(). If DMA-API debugging is
> enabled, the debug layer will give a warning if dma_mapping_error(
Hi Tomi,
Thank you for the patch.
On Friday 26 February 2016 11:35:50 Tomi Valkeinen wrote:
> The current driver uses non-blocking DMM fill when releasing memory.
> This gives us a small performance increase as we don't have to wait for
> the fill operation to finish.
>
> However, the driver doe
hment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160229/29226c50/attachment.html>
Hello Mario Kleiner,
The patch e1d09dc0ccc6: "drm/amdgpu: Don't hang in
amdgpu_flip_work_func on disabled crtc." from Feb 19, 2016, leads to
the following static checker warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:127 amdgpu_flip_work_func() warn:
should this be 'repcnt == -1'
drivers/g
vel/attachments/20160229/f6b453b2/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160229/ef802c9b/attachment.html>
On Fri, Feb 12, 2016 at 10:26:03AM +0100, Vincent Abriou wrote:
> Interlaced video can have different scan order:
> Top Field First or Bottom Field First
>
> In case of video with interlaced content, this information should be
> propagated from the userland to the DRM kernel driver that will proce
Hello,
I get a boot hang with vmwgfx on 4.5-rc6 (4.5.0-rc6-1.gb239884-default from
openSUSE). This happens on VMware Player 5.0.2.
Same VM works fine with kernel 4.4 but on 4.5-rc6 it hangs with
[drm] Initialized vmwgfx 2.9.0 20150810 for :00:0f.0 on minor 0
I am able to boot the system with
After the recent addition of drm_malloc_gfp(), it was noticed that
some callers of these functions has swapped the parameters in the
call - it's supposed to be 'number of members' and 'sizeof(element)',
but a few callers had got the size first and the count second. This
isn't otherwise detected bec
From: Chris Wilson
I have instances where I want to use drm_malloc_ab() but with a custom
gfp mask. And with those, where I want a temporary allocation, I want
to try a high-order kmalloc() before using a vmalloc().
So refactor my usage into drm_malloc_gfp().
Signed-off-by: Chris Wilson
Cc: dr
On Mon, Feb 29, 2016 at 7:47 PM, Thulasimani, Sivakumar
wrote:
>
>
> On 3/1/2016 5:03 AM, Rob Clark wrote:
>>
>> On Mon, Feb 29, 2016 at 11:12 AM, Daniel Vetter wrote:
>>>
>>> On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote:
On 2/24/2016 3:41 AM, Lyude wrote:
On Thu, Feb 25, 2016 at 04:15:06PM -0500, Rob Clark wrote:
> Add a new drm_debug bit for turning on DPCD logging, to aid debugging
> with troublesome monitors.
>
> v2: don't try to hexdump the universe if driver returns -errno, and
> change the "too many retries" traces to DRM_ERROR()
> v3: rename
2016-02-29 Alex Deucher :
> From: Christian König
>
> A fence is never later than itself. This caused a bunch of overhead for
> AMDGPU.
>
> v2: simplify check as suggested by Michel.
>
> Signed-off-by: Christian König
> Reviewed-by: Michel Dänzer
> Reviewed-by: Alex Deucher
> Signed-off
Hi Maarten,
2016-02-29 Maarten Lankhorst :
> Op 26-02-16 om 22:00 schreef Gustavo Padovan:
> > From: Gustavo Padovan
> >
> > Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
> > optimize buffer allocation. In the new approach the ioctl needs to be called
> > twice to retrieve t
On Mon, Feb 29, 2016 at 11:12 AM, Daniel Vetter wrote:
> On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote:
>>
>>
>> On 2/24/2016 3:41 AM, Lyude wrote:
>> >As it turns out, resuming DP MST is racey since we don't make sure MST
>> >is ready before we start modesetting, it just
On Mon, Feb 29, 2016 at 04:24:07PM +, Eric Engestrom wrote:
> 79e539453b34e35f39299a899d263b0a1f1670bd ("DRM: i915: add mode setting
> support") added those variables but never used them.
>
> Signed-off-by: Eric Engestrom
Both applied for 4.7, thanks.
-Daniel
> ---
> drivers/gpu/drm/i915/i
On Mon, Feb 29, 2016 at 03:41:59PM +, Sharma, Shashank wrote:
> No problems, I guessed the mail situation :)
Ok, caught up now, at least on dri-devel. There's 2 bug report mail
threads:
- A new one from Oleksandr, still being investigated.
- This one here where Sonika asked for some logs from
Picked it up.
Thanks,
Inki Dae
2016ë
02ì 17ì¼ 22:33ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> Core provides generic helper to create DSI packet, use it instead of
> custom code.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 69
> +++
On Mon, Feb 29, 2016 at 11:21:10AM +0800, Liu Ying wrote:
> The function __drm_framebuffer_unregister() has boilerplate code to drop idr
> reference. Let's replace it with drm_mode_object_put() to simplify the code.
>
> Signed-off-by: Liu Ying
Applied to drm-misc, thanks for the patch.
-Daniel
The original Raspberry Pi had the GPIO active high, but the later
models are active low. The DT GPIO bindings allow specifying the
active flag, except that it doesn't get propagated to the gpiodesc, so
you have to handle it yourself.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_hdmi.c
Fixes an error thrown every few seconds when we poll HPD when it's on
a I2C to GPIO expander.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index c6
These are for fixing the vc4 driver on the Pi 3. Note that patch 2
will also be necessary for fixing HPD on the Pi2, which we've been
carrying downstream patches to work around until now.
Eric Anholt (2):
drm/vc4: Let gpiolib know that we're OK with sleeping for HPD.
drm/vc4: Respect GPIO_ACT
For 1 and 2, picked it up.
Thanks,
Inki Dae
2016ë
02ì 18ì¼ 22:34ì Marek Szyprowski ì´(ê°) ì´ ê¸:
> This patch refactors driver and device registration by moving all drivers
> to the common array. This way additional flags can be added later for
> new features. #ifdef-based code has be
On Fri, Feb 26, 2016 at 09:50:15AM +0100, Benjamin Gaignard wrote:
> Thanks to "drm: prime: Honour O_RDWR during prime-handle-to-fd"
> commit we don't need to hack flags anymore.
>
> Signed-off-by: Benjamin Gaignard
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/sti/sti_drv.c | 11 +--
On Thu, Feb 25, 2016 at 04:15:05PM -0500, Rob Clark wrote:
> 1) don't let other threads trying to bang on aux channel interrupt the
> defer timeout/logic
> 2) don't let other threads interrupt the i2c over aux logic
>
> Technically, according to people who actually have the DP spec, this
> should
On Thu, Feb 25, 2016 at 12:18:25PM +0100, Lukas Wunner wrote:
> Hi,
>
> On Wed, Feb 24, 2016 at 11:32:15PM +0800, Drunkard Zhang wrote:
> > I may hit a bug, when enabled CONFIG_VGA_SWITCHEROO, run lspci command
> > on MSI GS60-070XCN will stuck, it eats 100% CPU of one core, and
> > CPU/memory all
On Mon, Feb 29, 2016 at 05:16:13PM +0100, Vincent ABRIOU wrote:
>
>
> On 02/29/2016 04:32 PM, Daniel Vetter wrote:
> > On Fri, Feb 26, 2016 at 11:33:08AM +0100, Vincent ABRIOU wrote:
> >> Hi,
> >>
> >> Have you any comment for this proposal?
> >
> > I guess since we don't really have userspace th
On Wed, Jan 27, 2016 at 03:44:42PM +0100, Marek Szyprowski wrote:
> This patch adds code and documentation for the following blending
> related properties: 'alpha', 'blending' and 'alpha_premult'.
>
> 'alpha' property defines plane's transparency used for some blending
> modes.
>
> 'alpha_premult
If the end of the system DMA window is farther away from the start of
physical RAM than the size of the GPU linear window, move the linear
window so that it ends at the same address than the system DMA window.
This allows to map command buffer from CMA, which is likely to reside
at the end of the
On 02/29/2016 04:32 PM, Daniel Vetter wrote:
> On Fri, Feb 26, 2016 at 11:33:08AM +0100, Vincent ABRIOU wrote:
>> Hi,
>>
>> Have you any comment for this proposal?
>
> I guess since we don't really have userspace that uses interlaced modes,
> much less actually bothers to get the fields correct I
From: Gaurav K Singh
New sequences are added in the mipi sequence block of the
VBT from version 3 onwards. The sequences are added to
make the code more generic as the panel related info
are placed in the VBT.
Cc: David Airlie
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Jani Nikula
Signed-off-
Currently there are few pair of functions which
are called during the panel enable/disable sequence.
To improve the granularity, adding few more wrapper
functions so that the functions are more specific
on what they are doing.
Cc: David Airlie
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Jani Niku
On Wed, Jan 27, 2016 at 03:44:41PM +0100, Marek Szyprowski wrote:
> This patch simplifies initialization of generic rotation property and
> aligns the code to match recently introduced function for intializing
> generic zpos property. It also adds missing documentation.
>
> Signed-off-by: Marek Sz
On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote:
>
>
> On 2/24/2016 3:41 AM, Lyude wrote:
> >As it turns out, resuming DP MST is racey since we don't make sure MST
> >is ready before we start modesetting, it just usually happens to be
> >ready in time. This isn't the case o
On Wed, Jan 27, 2016 at 03:44:39PM +0100, Marek Szyprowski wrote:
> This patch adds support for generic plane's zpos property property with
> well-defined semantics:
> - added zpos properties to drm core and plane state structures
> - added helpers for normalizing zpos properties of given set of pl
On Tue, Feb 23, 2016 at 06:46:26PM +0200, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> Try to detect the max TMDS clock limit for the DP++ adaptor (if any)
> and take it into account when checking the port clock.
>
> Note that as with the sink (HDMI vs. DVI) TMDS clock li
On 29 February 2016 at 16:16, Tvrtko Ursulin
wrote:
>
> On 29/02/16 11:13, Dave Gordon wrote:
>>
>> After the recent addition of drm_malloc_gfp(), it was noticed that
>> some callers of these functions has swapped the parameters in the
>> call - it's supposed to be 'number of members' and 'sizeof
Start to use dal by default on Carrizo, Tonga, and Fiji ASICs.
v3 changes:
- rebase on Alex's latest drm-next-4.6-wip
- export some functions to share with DAL
- remove has_dal_support macro and move logic into amdgpu_device_has_dal_support
Signed-off-by: Harry Wentland
Reviewed-by: Alex Deucher
Implements DRM's atomic KMS interfaces using DC.
v3 changes:
- use amdgpu's existing dce functions for some things, such as mc_access
- add stoney to dal check
- add missing hawaii and stoney case statements
- remove page work flip queue and use system queue instead
- minor dm_helpers function nam
Adds a logical representation of our hardware. Provides ability to
- dc_validate_resources - validate a display configuration
- dc_commit_targets - commit a display configuration
- dc_commit_surfaces_to_target - update surfaces
- dc_link_detect - detect displays at link
- dc_resume - resume display
Wrapper to access Video BIOS command and data tables
v3 changes:
- expose I2C through i2c_adapter and route dal i2c calls through this
Signed-off-by: Harry Wentland
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/dal/dc/bios/Makefile | 26 +
drivers/gpu/drm/amd/dal/dc/bios/bios_p
v3 changes:
- expose I2C through i2c_adapter and route dal i2c calls through this
Manages all DCE GPIO pins. The pins are represented as generic IO
handles as well as handles dedicated for certain functions, such as
DDC, HPD, and DVO.
Signed-off-by: Harry Wentland
Reviewed-by: Alex Deucher
---
v3 changes:
- expose I2C through i2c_adapter and route dal i2c calls through this
Signed-off-by: Harry Wentland
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/dal/dal_services.h | 266 ++
drivers/gpu/drm/amd/dal/dal_services_types.h | 62 ++
drivers/gpu/drm/amd/dal/dc/
Limitting v3 patches to only the modified patches, so as to reduce spam:
0001-drm-amd-dal-Add-dal-headers.patch
0005-drm-amd-dal-GPIO-General-Purpose-IO.patch
0007-drm-amd-dal-BIOS-Parser.patch
0024-drm-amd-dal-Add-display-core.patch
0025-drm-amd-dal-Adding-amdgpu_dm-for-dal.patch
0026-drm-amdgpu-U
On Mon, Feb 29, 2016 at 04:16:57PM +, Tvrtko Ursulin wrote:
> i915 cleanups are good but I am unsure of whether it is good to add
> this constant constraints. All current code seems to use it like
> that, true, but I am not sure that it should be a requirement.
The drm_mem_util allocators are
On Tue, Feb 23, 2016 at 11:04:57AM +0900, Michel Dänzer wrote:
> On 23.02.2016 04:32, Alex Deucher wrote:
> > From: Christian König
> >
> > A fence is never later than itself. This caused a bunch of overhead for
> > AMDGPU.
> >
> > v2: simplify check as suggested by Michel.
> >
> > Signed-of
On Mon, Feb 22, 2016 at 02:22:49PM -0500, Lyude wrote:
> These warnings still seem to be present with DP MST configurations. They
> don't actually indicate any impending doom, so we may as well use
> I915_STATE_WARN_ON() here to help quiet things down a little bit for
> distro kernel users.
>
> Si
On Mon, Feb 29, 2016 at 03:16:08PM +, Sharma, Shashank wrote:
> Please see the latest mail chain, Sonika has already started on it.
Ah ok, crawling through 1k mails after one week of vacation, so I'm still
catching up ;-) My apologies for the confusion.
Thanks, Daniel
>
> Regards
> Shashank
On Mon, 29 Feb 2016, Martin Kepplinger wrote:
> Am 2016-02-26 um 20:59 schrieb Takashi Iwai:
>> Sorry, Cc to Jani was missing mistakenly.
>>
>> Please check this. It's a regression in 4.5-rc.
>>
>>
>> thanks,
>>
>> Takashi
>>
>
> I can confirm that with -rc6 nothing changed and this fixes au
On Fri, Feb 19, 2016 at 03:58:24PM +0100, Christian König wrote:
> >If a minority of users need to opt out from MMU_NOTIFIER, then
> >DRM_RADEON_USERPTR and friends should default to y and be hidden behind
> >EXPERT. That way you avoid asking yet more questions to everyone else.
> >Would that work
On Fri, Feb 26, 2016 at 11:33:08AM +0100, Vincent ABRIOU wrote:
> Hi,
>
> Have you any comment for this proposal?
I guess since we don't really have userspace that uses interlaced modes,
much less actually bothers to get the fields correct I think just have
some (open-source) userspace somewhere
79e539453b34e35f39299a899d263b0a1f1670bd ("DRM: i915: add mode setting
support") added those variables but never used them.
Signed-off-by: Eric Engestrom
---
drivers/gpu/drm/i915/intel_tv.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers
ae80152ddad252f33893b92dd69f00cc53c5949f ("drm/i915: Rewrite VLV/CHV
watermark code") removed everything that would have used those vars.
Signed-off-by: Eric Engestrom
---
drivers/gpu/drm/i915/intel_pm.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/inte
On Mon, Feb 29, 2016 at 04:09:31PM +0100, Daniel Vetter wrote:
> On Mon, Feb 29, 2016 at 04:06:40PM +0100, Daniel Vetter wrote:
> > On Wed, Jan 27, 2016 at 03:44:41PM +0100, Marek Szyprowski wrote:
> > > This patch simplifies initialization of generic rotation property and
> > > aligns the code to
On 29/02/16 11:13, Dave Gordon wrote:
> After the recent addition of drm_malloc_gfp(), it was noticed that
> some callers of these functions has swapped the parameters in the
> call - it's supposed to be 'number of members' and 'sizeof(element)',
> but a few callers had got the size first and the
On Wed, Feb 24, 2016 at 06:07:25AM +, Sharma, Shashank wrote:
> Hi Ville,
> We will look into this in sometime. Right now team is slightly loaded due to
> project milestone.
> Last time I looked into this, we dint have this HW to reproduce this issue.
This is an upstream regression. Either
On Mon, Feb 29, 2016 at 04:06:40PM +0100, Daniel Vetter wrote:
> On Wed, Jan 27, 2016 at 03:44:41PM +0100, Marek Szyprowski wrote:
> > This patch simplifies initialization of generic rotation property and
> > aligns the code to match recently introduced function for intializing
> > generic zpos pro
On Wed, Jan 27, 2016 at 03:44:41PM +0100, Marek Szyprowski wrote:
> This patch simplifies initialization of generic rotation property and
> aligns the code to match recently introduced function for intializing
> generic zpos property. It also adds missing documentation.
>
> Signed-off-by: Marek Sz
On Thu, Feb 25, 2016 at 06:01:22PM +, Chris Wilson wrote:
> On Thu, Feb 11, 2016 at 08:04:51PM -0200, Tiago Vignatti wrote:
> > +static long dma_buf_ioctl(struct file *file,
> > + unsigned int cmd, unsigned long arg)
> > +{
> > + struct dma_buf *dmabuf;
> > + struct dma_
On Mon, Feb 29, 2016 at 07:38:21AM +0100, Thierry Reding wrote:
> On Tue, Dec 15, 2015 at 11:38:10AM +0100, Daniel Vetter wrote:
> > On Mon, Dec 14, 2015 at 01:56:03PM +0100, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > Store the AUX read interval from DPCD, so that it can be used
No problems, I guessed the mail situation :)
Regards
Shashank
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Monday, February 29, 2016 9:12 PM
To: Sharma, Shashank
Cc: Daniel Vetter; Ville Syrjälä; Oleksandr Natalenko; Vetter, Dani
Am 2016-02-26 um 20:59 schrieb Takashi Iwai:
> Sorry, Cc to Jani was missing mistakenly.
>
> Please check this. It's a regression in 4.5-rc.
>
>
> thanks,
>
> Takashi
>
I can confirm that with -rc6 nothing changed and this fixes audio over
HDMI for me. I added David Airlie and dri-devel to C
Please see the latest mail chain, Sonika has already started on it.
Regards
Shashank
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Monday, February 29, 2016 8:44 PM
To: Sharma, Shashank
Cc: Ville Syrjälä; Oleksandr Natalenko; Vet
On Mon, Feb 29, 2016 at 03:54:19PM +0100, Daniel Vetter wrote:
> On Thu, Feb 25, 2016 at 06:01:22PM +, Chris Wilson wrote:
> > On Thu, Feb 11, 2016 at 08:04:51PM -0200, Tiago Vignatti wrote:
> > > +static long dma_buf_ioctl(struct file *file,
> > > + unsigned int cmd, unsigned
[Dropping CCing the individual people, but adding the dri-devel mailing
list as well instead].
Am 29.02.2016 um 14:26 schrieb Michal Hocko:
> From: Michal Hocko
>
> radeon_mn_get which is called during ioct path relies on mmap_sem for
> write. If the waiting task gets killed by the oom killer it
Cc: Thierry the drm panel maintainer.
On Mon, 29 Feb 2016, Deepak M wrote:
> Currently there are few pair of functions which
> are called during the panel enable/disable sequence.
> To improve the granularity, adding few more wrapper
> functions so that the functions are more specific
> on what
ection of you xorg
config:
Option "ColorTiling" "false"
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160229/86ce2558/attachment.html>
On 02/26/16 13:21, Russell King - ARM Linux wrote:
> On Fri, Feb 26, 2016 at 12:14:44PM +0200, Jyri Sarha wrote:
>> On 02/26/16 02:43, Russell King - ARM Linux wrote:
>>> On Thu, Feb 25, 2016 at 03:42:50PM +0200, Jyri Sarha wrote:
On 02/18/16 16:35, Rob Herring wrote:
> This should be impl
On Wed, 24 Feb 2016, Joseph Salisbury wrote:
> Hi Sonika,
>
> A kernel bug report was opened against Ubuntu [0]. After a kernel
> bisect, it was found that reverting the following commit resolved this bug:
>
> commit 237ed86c693d8a8e4db476976aeb30df4deac74b
> Author: Sonika Jindal
> Date: Tue
The function __drm_framebuffer_unregister() has boilerplate code to drop idr
reference. Let's replace it with drm_mode_object_put() to simplify the code.
Signed-off-by: Liu Ying
---
drivers/gpu/drm/drm_crtc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm
On Feb 29 2016 or thereabouts, Daniel Vetter wrote:
> On Mon, Feb 22, 2016 at 02:22:49PM -0500, Lyude wrote:
> > These warnings still seem to be present with DP MST configurations. They
> > don't actually indicate any impending doom, so we may as well use
> > I915_STATE_WARN_ON() here to help quiet
After the recent addition of drm_malloc_gfp(), it was noticed that
some callers of these functions has swapped the parameters in the
call - it's supposed to be 'number of members' and 'sizeof(element)',
but a few callers had got the size first and the count second. This
isn't otherwise detected bec
From: Chris Wilson
I have instances where I want to use drm_malloc_ab() but with a custom
gfp mask. And with those, where I want a temporary allocation, I want
to try a high-order kmalloc() before using a vmalloc().
So refactor my usage into drm_malloc_gfp().
Signed-off-by: Chris Wilson
Cc: dr
On Mon, 29 Feb 2016, Thierry Reding wrote:
> On Sun, Jan 31, 2016 at 04:39:51PM +0200, Jani Nikula wrote:
>> On Mon, 14 Dec 2015, Thierry Reding wrote:
>> > From: Thierry Reding
>> >
>> > This helper chooses an appropriate configuration, according to the
>> > bitrate requirements of the video mo
From: Christian König
A fence is never later than itself. This caused a bunch of overhead for AMDGPU.
v2: simplify check as suggested by Michel.
Signed-off-by: Christian König
Reviewed-by: Michel Dänzer
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
---
include/linux/fence.h | 2
On 29 February 2016 at 00:58, lijianhua wrote:
> Add hibmc DRM master driver for hi1710 which used in arm64 board.
>
Would be nice to give examples of what "arm64 board" this hardware is
presently available. Some information about the device as seen in the
cover letter, and/or a link to the cover
Op 26-02-16 om 19:31 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> struct sync_merge_data already have documentation on top of the
> struct definition. No need to duplicate it.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/staging/android/uapi/sync.h | 6 +++---
> 1 file changed, 3 i
Op 26-02-16 om 19:31 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> Play safe and add flags member to all structs. So we don't need to
> break API or create new IOCTL in the future if new features that requires
> flags arises.
>
> v2: check if flags are valid (zero, in this case)
>
> Signed-
Hi Dave,
drm-intel-next-2016-02-14:
- lots and lots of fbc work from Paulo
- max pixel clock checks from Mika Kahola
- prep work for nv12 offset handling from Ville
- piles of small fixes and refactorings all around
I've forgotten to send you this one before I left for vacation, oops. So
there'll
Op 26-02-16 om 22:00 schreef Gustavo Padovan:
> From: Gustavo Padovan
>
> Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
> optimize buffer allocation. In the new approach the ioctl needs to be called
> twice to retrieve the array of fence_infos pointed by info->sync_fence_info.
Add maintainer for hibmc DRM driver.
Signed-off-by: lijianhua
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4978dc1..2bf23eb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3774,6 +3774,13 @@ S: Maintained
F: drivers/gpu/drm/
Add fbdev.
Signed-off-by: lijianhua
---
drivers/gpu/drm/hisilicon/hibmc/Makefile | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 5 +
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 2 +
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 290 ++
Add connector funcs and helper funcs for VDAC.
Signed-off-by: lijianhua
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 8 +++
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 1 +
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 89
3 files changed, 98 inse
Add encoder funcs and helpers for VDAC.
Signed-off-by: lijianhua
---
drivers/gpu/drm/hisilicon/hibmc/Makefile | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 6 ++
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 1 +
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 73
Add crtc funcs and helper funcs for DE.
Signed-off-by: lijianhua
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 279
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.h | 20 ++
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 6 +
drivers/gpu/drm/hisilicon/hibmc/
Add plane funcs and helper funcs for DE.
Signed-off-by: lijianhua
---
drivers/gpu/drm/hisilicon/hibmc/Makefile| 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 158
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 48 +++
drivers/gpu/drm/hisilicon
Add hibmc DRM master driver for hi1710 which used in arm64 board.
Signed-off-by: lijianhua
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile| 1 +
drivers/gpu/drm/hisilicon/Kconfig | 4 +
drivers/gpu/drm/hisilicon/Make
This patch set adds a new drm driver for Hisilicon hi1710.
hi1710 is an BMC controller, and now we use it in arm64 board.
In this patch set, we just support basic function for hi1710 display subsystem.
hi1710 display subsytem is connected to arm64 by PCIe as bellow:
+-++---
Hi Gustavo,
On 27 February 2016 at 15:25, Gustavo Padovan
wrote:
> Hi Emil,
>
> 2016-02-27 Emil Velikov :
>
>> Hi Gustavo,
>>
>> On 26 February 2016 at 21:00, Gustavo Padovan wrote:
>> > From: Gustavo Padovan
>> >
>> > Change SYNC_IOC_FILE_INFO behaviour to avoid future API breaks and
>> > opti
2016ë
01ì 27ì¼ 23:44ì Marek Szyprowski ì´(ê°) ì´ ê¸:
> This patch adds support for blending related properties to Exynos DRM
> core and Exynos Mixer CRTC device.
To drm-misc.
Acked-by : Inki Dae
Thanks,
Inki Dae
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/gpu/drm/exynos
On Sun, Jan 10, 2016 at 11:12 AM, Andy Lutomirski
wrote:
> On Sun, Jan 10, 2016 at 10:41 AM, Andy Lutomirski
> wrote:
>> On Wed, Nov 18, 2015 at 8:12 AM, Daniel Stone
>> wrote:
>>> Hi,
>>>
>>> On 18 November 2015 at 15:59, Andy Lutomirski
>>> wrote:
On Wed, Nov 18, 2015 at 2:59 AM, Vil
2016ë
01ì 27ì¼ 23:44ì Marek Szyprowski ì´(ê°) ì´ ê¸:
> This patch replaces zpos property handling custom code in Exynos DRM
> driver with calls to generic DRM code.
It'd be better to go to drm-misc.
Acked-by: Inki Dae
Thanks,
Inki Dae
>
> Signed-off-by: Marek Szyprowski
> ---
>
On 27 February 2016 at 15:27, Gustavo Padovan
wrote:
> Hi Emil,
>
> 2016-02-27 Emil Velikov :
>
>> Hi Gustavo,
>>
>> On 26 February 2016 at 18:31, Gustavo Padovan wrote:
>> > From: Gustavo Padovan
>> >
>> > Play safe and add flags member to all structs. So we don't need to
>> > break API or crea
interval (in microseconds) from the DPCD. Note that
> > the
> > + * TRAINING_AUX_RD_INTERVAL stores the value in units of 4 milliseconds.
> > + *
> > + * Returns:
> > + * The read AUX interval in microseconds.
> > + */
> > +static inline unsigned int
> > +drm_dp_aux_rd_interval(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
>
> We should use this one here in the 2 delay helpers for channel_eq and
> clock_recovery imo.
Agreed.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160229/3be6cf9b/attachment.sig>
osed to adjust the maximum values to account
for their limitations. Hence the name for struct drm_dp_*link*, because
it contains the negotiated parameters for the link between source and
sink.
That seems to me like the logical procedure when following the spec. Is
that not how i915 works?
Thierry
1 - 100 of 106 matches
Mail list logo
