https://bugzilla.kernel.org/show_bug.cgi?id=116101
Joe P. changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 2016-04-11 18:38, Shawn Guo wrote:
> On Mon, Apr 04, 2016 at 10:28:33PM -0700, Stefan Agner wrote:
>> Similar to an earlier fix for the SAI clocks, the DCU clock hierarchy
>> mixes the bus clock with the display controllers pixel clock. Tests
>> have shown that the gates in CCM_CCGR3/9 registers
ves/dri-devel/attachments/20160412/93ac/attachment.html>
ves/dri-devel/attachments/20160412/753c3495/attachment-0001.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160412/95a62b15/attachment.html>
On Tue, Apr 12, 2016 at 06:16:54PM +0100, Liviu Dudau wrote:
> On Tue, Apr 12, 2016 at 05:58:11PM +0200, Daniel Vetter wrote:
> > On Fri, Apr 01, 2016 at 05:21:52PM +0100, Liviu Dudau wrote:
> > > Add support for the new family of Display Processors from ARM Ltd.
> > > This commit adds basic suppor
On Tue, Apr 12, 2016 at 06:13:49PM +0100, Liviu Dudau wrote:
> On Tue, Apr 12, 2016 at 05:47:57PM +0200, Daniel Vetter wrote:
> > On Fri, Apr 01, 2016 at 05:21:52PM +0100, Liviu Dudau wrote:
> > > +static int malidp_enable_vblank(struct drm_device *drm, unsigned int
> > > crtc)
> > > +{
> > > + re
On 04/12/2016 06:39 PM, Felix Kuehling wrote:
> This is the implementation of ttm_round_pot:
>
> size_t ttm_round_pot(size_t size)
> {
> if ((size & (size - 1)) == 0)
> return size;
> else if (size > PAGE_SIZE)
> return PAGE_ALIGN(size);
> els
On 04/12/2016 04:53 AM, Rob Herring wrote:
> Android needs XBGR format. Add all the missing 32-bpp formats
> without alpha for completeness.
>
Reviewed-by: Archit Taneja
> Cc: Archit Taneja
> Cc: Rob Clark
> Signed-off-by: Rob Herring
> ---
> drivers/gpu/drm/msm/mdp/mdp_format.c | 6
On 04/12/2016 05:57 PM, Alex Deucher wrote:
> From: Felix Kuehling
>
> TTM BO accounting is out of sync with how memory is really allocated
> in ttm[_dma]_tt_alloc_page_directory. This resulted in excessive
> estimated overhead with many small allocations.
>
> ttm_dma_tt_alloc_page_directory makes
On Tue, Apr 12, 2016 at 05:58:11PM +0200, Daniel Vetter wrote:
> On Fri, Apr 01, 2016 at 05:21:52PM +0100, Liviu Dudau wrote:
> > Add support for the new family of Display Processors from ARM Ltd.
> > This commit adds basic support for Mali DP500, DP550 and DP650
> > parts, with only the display en
On Tue, Apr 12, 2016 at 12:57:45PM +, Hwang, Dongseong wrote:
> Follow-up of the kernel patch:
> https://lists.freedesktop.org/archives/dri-devel/2015-July/086041.html
>
> The Kodi/XBMC and ChromeOS developers want to transcode NV12 to RGB
> with OpenGL shaders, importing the two source plane
On Tue, Apr 12, 2016 at 05:47:57PM +0200, Daniel Vetter wrote:
> On Fri, Apr 01, 2016 at 05:21:52PM +0100, Liviu Dudau wrote:
> > Add support for the new family of Display Processors from ARM Ltd.
> > This commit adds basic support for Mali DP500, DP550 and DP650
> > parts, with only the display en
On Mon, Apr 11, 2016 at 07:46:31PM +0300, Jyri Sarha wrote:
> Add tilcdc_crtc_mode_set_nofb(). The mode_set_nofb() semantics do not
> fit well to LCDC, because of the mandatory framebuffer. However, when
> the primary plane is required in the check phase, it and the
> framebuffer can be found from
On Mon, Apr 11, 2016 at 04:55:33PM +0800, Xinliang Liu wrote:
> This patch set adds a new drm driver for HiSilicon Kirin hi6220 SoC.
> Current testing and support board is Hikey board which is one of Linaro
> 96boards. It is an arm64 open source board. For more information about
> this board, pleas
On Tue, Apr 12, 2016 at 01:51:02PM +0100, Lionel Landwerlin wrote:
> On 12/04/16 12:57, Daniel Vetter wrote:
> >On Mon, Apr 11, 2016 at 02:43:39PM +0100, Lionel Landwerlin wrote:
> >>Color management properties are a bit of an odd use case because
> >>they're not marked as atomic properties. Curren
On Tue, Apr 12, 2016 at 04:32:19PM +0200, Maarten Lankhorst wrote:
> This function is useful for gen2 intel devices which have no frame
> counter, but need a way to determine the current vblank count without
> racing with the vblank interrupt handler.
>
> intel_pipe_update_start checks if no vblan
On Tue, Apr 05, 2016 at 04:50:39PM +0800, Liu Ying wrote:
> Transitional drivers might access the NULL pointer plane->state in
> drm_helper_crtc_mode_set_base(), which causes NULL pointer dereference.
> So, let's reset it before handing it over to those drivers.
> commit e4f31ad2b713 ("drm: reset e
On Fri, Apr 01, 2016 at 05:21:52PM +0100, Liviu Dudau wrote:
> Add support for the new family of Display Processors from ARM Ltd.
> This commit adds basic support for Mali DP500, DP550 and DP650
> parts, with only the display engine being supported at the moment.
>
> Cc: David Brown
> Cc: Brian S
. So I'm leaving the report open.
--
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/20160412/5a2fda64/attachment.html>
On Fri, Apr 01, 2016 at 05:21:52PM +0100, Liviu Dudau wrote:
> Add support for the new family of Display Processors from ARM Ltd.
> This commit adds basic support for Mali DP500, DP550 and DP650
> parts, with only the display engine being supported at the moment.
>
> Cc: David Brown
> Cc: Brian S
+ if ((version_major >= 0x01) && (version_minor >= 0x37))
+ rdev->uvd.max_handles = RADEON_MAX_UVD_HANDLES;
If major version greater than 01 no need to verify for minor version.
Can we modify like this?
if ((version_major
2016ë
04ì 12ì¼ 16:33ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> On 04/12/2016 04:25 AM, Inki Dae wrote:
>> Hi Andrzej,
>>
>> 2016ë
03ì 23ì¼ 22:15ì Andrzej Hajda ì´(ê°) ì´ ê¸:
>>> DECON should be updated after un-protecting windows and after changing
>>> output parameters, otherwise imag
This function is useful for gen2 intel devices which have no frame
counter, but need a way to determine the current vblank count without
racing with the vblank interrupt handler.
intel_pipe_update_start checks if no vblank interrupt will occur
during vblank evasion, but cannot check whether the vb
On Tue, 12 Apr 2016, Emil Velikov wrote:
> On 30 March 2016 at 10:51, Daniel Vetter wrote:
> > No need to confuse userspace like this.
> >
> > Cc: Gerd Hoffmann
> > Cc: Dave Airlie
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/virtio/virtgpu_display.c | 9 -
> > 1 fil
Am 12.04.2016 um 15:14 schrieb Emil Velikov:
> On 12 April 2016 at 12:46, Christian König
> wrote:
>> From: Arindam Nath
>>
>> Change History
>> --
>>
>> v2:
>> - Make firmware version check correctly. Firmware
>>versions >= 1.80 should all support 40 UVD
>>instances.
> Fwiw
This patch cleans up interface type relevant codes.
Trigger mode is determinded only by i80 mode, which isn't
related to Display types - HDMI or Display controller.
So this patch makes the trigger mode to be set only in case of
i80 mode - For DECON-TV, HW Trigger mode is flaged mandatorily
because
2016ë
04ì 12ì¼ 14:55ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> Hi Inki,
>
> On 04/12/2016 02:40 AM, Inki Dae wrote:
>> Hi Andrzej,
>>
>> 2016ë
04ì 05ì¼ 21:52ì Inki Dae ì´(ê°) ì´ ê¸:
>>> Hi Andrzej,
>>>
>>> 2016-04-05 20:07 GMT+09:00 Andrzej Hajda :
Hi Inki,
On 04/05/20
On 30 March 2016 at 10:51, Daniel Vetter wrote:
> No need to confuse userspace like this.
>
> Cc: Gerd Hoffmann
> Cc: Dave Airlie
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/virtio/virtgpu_display.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/vir
On 12 April 2016 at 12:46, Christian König wrote:
> From: Arindam Nath
>
> Change History
> --
>
> v2:
> - Make firmware version check correctly. Firmware
> versions >= 1.80 should all support 40 UVD
> instances.
Fwiw, this is the type of information that people [unfamiliar with
On Mon, Apr 11, 2016 at 02:43:39PM +0100, Lionel Landwerlin wrote:
> Color management properties are a bit of an odd use case because
> they're not marked as atomic properties. Currently we're not updating
> the non atomic values so the drm_crtc_state is out of sync with the
> values stored in the
Warning during compilation after git pull:
tgsi/tgsi_exec.c: In function 'exec_atomop_buf':
tgsi/tgsi_exec.c:4060:8: warning: array subscript is above array bounds
[-Warray-bounds]
r[3].f[j] = rgba[3][j];
^
Any hints where I should look?
Dieter
* Sebastian Reichel [160324 17:16]:
> On Thu, Mar 24, 2016 at 05:11:15PM +0200, Jani Nikula wrote:
> > > I _think_, that your HW team decided to cover the first and the
> > > last few pixels of the 864 display with plastic. So technically
> > > it's a 864 display, but effectively it's 854.
Sebast
On 12/04/16 12:57, Daniel Vetter wrote:
> On Mon, Apr 11, 2016 at 02:43:39PM +0100, Lionel Landwerlin wrote:
>> Color management properties are a bit of an odd use case because
>> they're not marked as atomic properties. Currently we're not updating
>> the non atomic values so the drm_crtc_state is
From: Arindam Nath
Change History
--
v2:
- Make firmware version check correctly. Firmware
versions >= 1.80 should all support 40 UVD
instances.
- Replace AMDGPU_MAX_UVD_HANDLES with max_handles
variable.
v1:
- The firmware can handle upto 40 UVD sessions.
Signed-off-by: Arin
On Mon, 28 Mar 2016, Lyude wrote:
> Resending this because it looks like replying to my previous series of patches
> causes patchwork to pick up patches from the original version of this and
> try to apply them along with this one.
Lyude, these don't seem to apply cleanly, please rebase and repos
On Fri, Apr 01, 2016 at 10:38:09AM +0200, Gerd Hoffmann wrote:
> On Mi, 2016-03-30 at 11:51 +0200, Daniel Vetter wrote:
> > No need to confuse userspace like this.
>
> Reviewed-by: Gerd Hoffmann
This and the bochs one applied to drm-misc, thanks for your review.
-Daniel
--
Daniel Vetter
Softwar
Follow-up of the kernel patch:
https://lists.freedesktop.org/archives/dri-devel/2015-July/086041.html
The Kodi/XBMC and ChromeOS developers want to transcode NV12 to RGB
with OpenGL shaders, importing the two source planes through
EGL_EXT_image_dma_buf_import. That requires importing the Y plane
On Fri, Apr 01, 2016 at 11:04:10PM +0300, Ville Syrjälä wrote:
> On Tue, Mar 22, 2016 at 04:08:39PM +0100, Maarten Lankhorst wrote:
> > Op 22-03-16 om 15:58 schreef Ville Syrjälä:
> > > On Tue, Mar 22, 2016 at 03:42:14PM +0100, Maarten Lankhorst wrote:
> > >> __drm_atomic_helper_plane_destroy_s
On Thu, Mar 31, 2016 at 01:26:03PM +0200, Maarten Lankhorst wrote:
> It turns out that preserving framebuffers after the rmfb call breaks
> vmwgfx userspace. This was originally introduced because it was thought
> nobody relied on the behavior, but unfortunately it seems there are
> exceptions.
>
On Fri, Apr 01, 2016 at 09:15:45PM +0200, Noralf Trønnes wrote:
> Den 29.03.2016 09:27, skrev Daniel Vetter:
> >I was wondering whether we couldn't avoid the _with_funcs here by setting
> >up fbdefio iff ->dirty is set. Then you could add the generic defio setup
> >code to drm_fbdev_cma_create aft
This is the implementation of ttm_round_pot:
size_t ttm_round_pot(size_t size)
{
if ((size & (size - 1)) == 0)
return size;
else if (size > PAGE_SIZE)
return PAGE_ALIGN(size);
else {
size_t tmp_size = 4;
while
On Mon, 11 Apr 2016, Jim Bride wrote:
> In order to include monitor name information in debugfs
> output we needed to add a function that would extract the
> monitor name from the EDID, and that function needed to
> reside in the file where the rest of the EDID helper
> functions are implemented.
Sounds good, I'll have the rebased versions posted in a bit
On Tue, 2016-04-12 at 13:17 +0300, Jani Nikula wrote:
> On Mon, 28 Mar 2016, Lyude wrote:
> >
> > Resending this because it looks like replying to my previous series
> > of patches
> > causes patchwork to pick up patches from the origin
From: Felix Kuehling
TTM BO accounting is out of sync with how memory is really allocated
in ttm[_dma]_tt_alloc_page_directory. This resulted in excessive
estimated overhead with many small allocations.
ttm_dma_tt_alloc_page_directory makes a single allocation for three
arrays: pages, DMA and CP
On Tue, Apr 12, 2016 at 06:54:35AM +0100, Mark Brown wrote:
> On Tue, Apr 12, 2016 at 07:43:59AM +0200, Takashi Iwai wrote:
>
> > But the problem is more complicated because you're changing drm stuff,
> > too. This is usually managed in drm tree. So this cross over three
> > different trees.
>
Hi Andrzej,
2016ë
03ì 23ì¼ 22:15ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> DECON should be updated after un-protecting windows and after changing
> output parameters, otherwise image is not displayed in case of HDMI path.
I'm not sure why STANDALONE_UPDATE_F bit should be updated after un-protect
Applied, thanks!
Alex
On Tue, Apr 12, 2016 at 7:46 AM, Christian König
wrote:
> From: Arindam Nath
>
> Change History
> --
>
> v2:
> - Make firmware version check correctly. Firmware
> versions >= 1.80 should all support 40 UVD
> instances.
> - Replace AMDGPU_MAX_UVD_HANDLES wi
Hi Luis,
On 12 April 2016 at 04:03, Luis de Bethencourt
wrote:
> On 11/04/16 21:09, Gustavo Padovan wrote:
>> Hi Luis,
>>
>> 2016-04-11 Luis de Bethencourt :
>>
>>> The members child_list and active_list were added to the fence struct
>>> without descriptions for the Documentation. Adding these
On 04/11/16 19:46, Jyri Sarha wrote:
> Set DRIVER_ATOMIC and use atomic helpers and rename commit and prepare
> crtc helpers to enable and disable. This makes the final jump to mode
> setting, but there is lot of obsolete code to clean up.
>
> Signed-off-by: Jyri Sarha
> ---
> drivers/gpu/drm/ti
Signed-off-by: Subhransu S. Prusty
Signed-off-by: Vinod Koul
Cc: Jani Nikula
Cc: David Airlie
Cc: dri-devel at lists.freedesktop.org
Cc: Daniel Vetter
---
include/drm/drm_edid.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index
This series parses ELD to identify multichannel capability of the
sync, and uses HDA framework to programs codec's channel map
registers.
Channel map controls are registered in patch 8, with which user
can specify a specific channel order. chmap controls are
registered inside jack_init callback. A
This patch removes suffixes from I80 relevant register definitions,
which are misleading.
This is based on top of below patch set,
http://www.spinics.net/lists/dri-devel/msg104057.html
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 +-
drivers/gpu/drm/exynos
Hi Sjoerd,
On Wed, Apr 6, 2016 at 11:45 AM, Sjoerd Simons
wrote:
> Simply calling rcar_du_remove on any error can cause unbalanced calls to
> various functions (e.g. drm_connector_register/unregister,
> drm_dev_register/drm_dev_unref).
>
> This can be seen at bootup of my Porter boards with curre
Hi Andrzej,
2016ë
04ì 05ì¼ 21:52ì Inki Dae ì´(ê°) ì´ ê¸:
> Hi Andrzej,
>
> 2016-04-05 20:07 GMT+09:00 Andrzej Hajda :
>> Hi Inki,
>>
>> On 04/05/2016 10:27 AM, Inki Dae wrote:
>>> This patch cleans up interface type relevant codes.
>>>
>>> Trigger mode is determinded only by i80 mode,
On Mon, Apr 04, 2016 at 10:28:33PM -0700, Stefan Agner wrote:
> Similar to an earlier fix for the SAI clocks, the DCU clock hierarchy
> mixes the bus clock with the display controllers pixel clock. Tests
> have shown that the gates in CCM_CCGR3/9 registers do not control
> the DCU pixel clock, but
On 04/12/2016 04:25 AM, Inki Dae wrote:
> Hi Andrzej,
>
> 2016ë
03ì 23ì¼ 22:15ì Andrzej Hajda ì´(ê°) ì´ ê¸:
>> DECON should be updated after un-protecting windows and after changing
>> output parameters, otherwise image is not displayed in case of HDMI path.
> I'm not sure why STANDALONE
Hi Inki,
On 04/12/2016 02:40 AM, Inki Dae wrote:
> Hi Andrzej,
>
> 2016ë
04ì 05ì¼ 21:52ì Inki Dae ì´(ê°) ì´ ê¸:
>> Hi Andrzej,
>>
>> 2016-04-05 20:07 GMT+09:00 Andrzej Hajda :
>>> Hi Inki,
>>>
>>> On 04/05/2016 10:27 AM, Inki Dae wrote:
This patch cleans up interface type relevant
On Tue, 12 Apr 2016 07:01:22 +0200,
Subhransu S. Prusty wrote:
>
> This series parses ELD to identify multichannel capability of the
> sync, and uses HDA framework to programs codec's channel map
> registers.
>
> Channel map controls are registered in patch 8, with which user
> can specify a spec
- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160412/bb32bec4/attachment.sig>
On 12 April 2016 at 07:11, Dave Airlie wrote:
> From: Dave Airlie
Oh ignore these, I see Nils has sent some that do the same and a lot more!
Dave.
From: Dave Airlie
This makes these non-global and constant.
before:
1213447 182251532 1233204 12d134 drivers/gpu/drm/amd/amdgpu/amdgpu.ko
after:
1213447 181931532 1233172 12d114 drivers/gpu/drm/amd/amdgpu/amdgpu.ko
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/powerplay/hwm
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160412/c3b72c87/attachment.html>
From: Dave Airlie
On my otherly hacked up kernel module this does:
1090519 1411691532 1233220 12d144 drivers/gpu/drm/amd/amdgpu/amdgpu.ko
1213447 182251532 1233204 12d134 drivers/gpu/drm/amd/amdgpu/amdgpu.ko
clearly having less data is better.
Signed-off-by: Dave Airlie
---
driv
ELD_SPAEKER];
That'd make things even easier of course.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160412/1eb22089/attachment.sig>
terward.
--
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/20160412/683a84ce/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160412/3565e9d7/attachment.html>
Hi,
> > We've fixed piles of those in recent kernels, but didn't backport all the
> > fixes (since usually it's a silent failure, but it can correlate with
> > black screens).
>
> Not quite completely, it seems ...
>
> I have built drm-intel-nightly (f261f82359), and I'm getting this:
[...]
pin
bbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160412/a845345e/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=67681
--- Comment #41 from KernelBug <3fdd1e5d at opayq.com> ---
Can someone PLEASE be kind enough to tell me if the kernel now has the support
for these functions for this laptop?
thank you
--
You are receiving this mail because:
You are watching the
Hi Thierry,
On Wed, 30 Mar 2016 22:03:23 +0200
Boris Brezillon wrote:
> Hello,
>
> This series adds support for atomic PWM update, or IOW, the capability
> to update all the parameters of a PWM device (enabled/disabled, period,
> duty and polarity) in one go.
>
> It also adds support for initi
71 matches
Mail list logo
