On Tue, Jan 19, 2016 at 10:26:16AM +0200, Emil Velikov wrote:
> Hi Marcin,
>
> On 9 January 2016 at 17:05, Marcin Ålusarz
> wrote:
> > Currently with --disable-amdgpu --disable-valgrind --disable-cairo-tests
> > cunit, valgrind and cairo are still detected.
> >
> Doesn't this patch make 1/2 obs
eedesktop.org/archives/dri-devel/attachments/20160119/1fd2fc1e/attachment-0002.bin>
-- next part --
A non-text attachment was scrubbed...
Name: 0002-tests-Include-poll.h-rather-than-sys-poll.h.patch
Type: text/x-patch
Size: 1228 bytes
Desc: not available
URL:
<http://li
On Tue, Jan 19, 2016 at 06:10:40PM -0200, Gustavo Padovan wrote:
> 2016-01-19 Daniel Vetter :
> > - get_timeline_name and get_driver_name are imo too much indirection, just
> > add ->(drv_)name field to each of these.
>
> I don't think is a good idea to change that now as there are other fence
>
t was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160119/9b888025/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=88861
--- Comment #9 from Lukas Wunner ---
Hi Jani,
Paul Hordiienko, the reporter of this bug, successfully tested an earlier
version (v2) of the patch set, see the Tested-by: tags on these patches:
http://lists.freedesktop.org/archives/dri-devel/2015-
On Tue, Jan 19, 2016 at 03:52:26PM -0200, Gustavo Padovan wrote:
> 2016-01-19 John Harrison :
>
> > On 19/01/2016 15:23, Gustavo Padovan wrote:
> > >Hi Daniel,
> > >
> > >2016-01-19 Daniel Vetter :
> > >
> > >>On Fri, Jan 15, 2016 at 12:55:10PM -0200, Gustavo Padovan wrote:
> > >>>From: Gustavo Pa
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160119/d2c0d482/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160119/d7d5862c/attachment.html>
2016-01-19 Daniel Vetter :
> On Fri, Jan 15, 2016 at 12:55:10PM -0200, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > This patch series de-stage the sync framework, and in order to accomplish
> > that
> > a bunch of cleanups/improvements on the sync and fence were made.
> >
> > The s
Some edp screen do not have hpd signal, so we can't just return
failed when hpd plug in detect failed.
This is an hardware property, so we need add a devicetree property
"analogix,need-force-hpd" to indicate this sutiation.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
Tested-by: Javier Marti
Rockchip have three clocks for dp controller, we leave pclk_edp
to analogix_dp driver control, and keep the sclk_edp_24m and
sclk_edp in platform driver.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Rebase the whole patches on top of Dave's drm-next branch [0] (Heiko)
Chang
After exynos_dp have been split the common IP code into analogix_dp driver,
the analogix_dp driver have deprecated some Samsung platform properties which
could be dynamically parsed from EDID/MODE/DPCD message, so this is an update
for Exynos DTS file for dp-controller.
Beside the backward compati
Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
---
There is no
From: Michel Dänzer
It can be big, depending on the VM address space size, which is tunable
via the vm_size module parameter.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93721
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 7 +++
1 file changed, 3 in
Split the dp core driver from exynos directory to bridge directory,
and rename the core driver to analogix_dp_*, rename the platform
code to exynos_dp.
Beside the new analogix_dp driver would export six hooks.
"analogix_dp_bind()" and "analogix_dp_unbind()"
"analogix_dp_suspned()" and "analogix_dp
n HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160119/4ccdda0e/attachment-0001.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160119/5221e70b/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160119/793941fa/attachment.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160119/f9e44be8/attachment.html>
Hi,
Upgrading from 4.3 to 4.4 breaks my HDMI output on my G45 machine.
As soon as the intel driver is loaded, the monitor shuts off
(standby mode). Inspecting /sys/class/drm/card0-HDMI-A-1/status
reports "disconnected". When it is working, this attribute says
"connected".
There is nothing unus
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160119/bfbbd588/attachment.html>
On 01/15/2016 06:55 AM, Gustavo Padovan wrote:
> /**
> + * fence_timeline_create - create a new fence_timeline
> + * @num: [in]amount of contexts to allocate
[...]
> + */
> +struct fence_timeline *fence_timeline_create(unsigned num,
> + struct fenc
when i boot the kernel and connect the HDMI cable after booting i can retrieve
4 modes... :)
if i boot linux with the HDMI cable inserted the kernel hangs.
Possible relation with HPD?
Regards,
C.Palminha
# modetest -M drm-arcpgu -c
Connectors:
id encoder status typesize (mm)
/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160119/e2a63c5c/attachment.sig>
part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160119/8bb7d72b/attachment.sig>
Merge tag 'drm-intel-next-fixes-2016-01-14' of
git://anongit.freedesktop.org/drm-intel into drm-next (2016-01-18 07:02:19
+1000)
are available in the git repository at:
http://github.com/anholt/linux tags/drm-vc4-fixes-2015-01-19
for you to fetch changes up to 8483d152db61c5baf5452b844ef65
2016-01-19 Daniel Vetter :
> On Tue, Jan 19, 2016 at 03:52:26PM -0200, Gustavo Padovan wrote:
> > 2016-01-19 John Harrison :
> >
> > > On 19/01/2016 15:23, Gustavo Padovan wrote:
> > > >Hi Daniel,
> > > >
> > > >2016-01-19 Daniel Vetter :
> > > >
> > > >>On Fri, Jan 15, 2016 at 12:55:10PM -0200,
On 19/01/2016 15:23, Gustavo Padovan wrote:
> Hi Daniel,
>
> 2016-01-19 Daniel Vetter :
>
>> On Fri, Jan 15, 2016 at 12:55:10PM -0200, Gustavo Padovan wrote:
>>> From: Gustavo Padovan
>>>
>>> This patch series de-stage the sync framework, and in order to accomplish
>>> that
>>> a bunch of cleanup
Hi Xiang,
Its returning 0 modes... :(
Regards,
C.Palminha
# modetest -M drm-arcpgu -c
Connectors:
id encoder status typesize (mm) modes encoders
21 0 disconnectedHDMI-A 0x0 0 20
props:
1 EDID:
flags: immutable
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160119/3c37f188/attachment.html>
2016-01-19 John Harrison :
> On 19/01/2016 15:23, Gustavo Padovan wrote:
> >Hi Daniel,
> >
> >2016-01-19 Daniel Vetter :
> >
> >>On Fri, Jan 15, 2016 at 12:55:10PM -0200, Gustavo Padovan wrote:
> >>>From: Gustavo Padovan
> >>>
> >>>This patch series de-stage the sync framework, and in order to ac
2016ë
01ì 18ì¼ 19:12ì Andrzej Hajda ì´(ê°) ì´ ê¸:
> Hi Inki,
>
> On 01/18/2016 10:54 AM, Inki Dae wrote:
>>
>> 2016ë
01ì 18ì¼ 08:45ì Krzysztof Kozlowski ì´(ê°) ì´ ê¸:
>>> On 14.01.2016 19:49, Inki Dae wrote:
+ Rob Herring
2016ë
01ì 14ì¼ 19:36ì Andrzej
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160119/fc5396ff/attachment.html>
ed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160119/86200512/attachment-0001.html>
In places (e.g. i915.ko), the alignment is exported to userspace as u64
and there now exists hardware for which we can indeed utilize a u64
alignment. As such, we need to keep 64bit integers throughout when
handling alignment.
Testcase: igt/gem_exec_alignment
Signed-off-by: Chris Wilson
---
driv
Am 19.01.2016 um 09:59 schrieb Michel Dänzer:
> From: Michel Dänzer
>
> It can be big, depending on the VM address space size, which is tunable
> via the vm_size module parameter.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93721
> Signed-off-by: Michel Dänzer
I actually wanted
> I think Graham summed it up pretty well :)
Indeed, but there is a detail missing. The main problem for moving SI
and CIK support from radeon to amdgpu is that we can't break existing
userspace.
Fortunately amdgpu wasn't designed from scratch, instead it's rather a
evaluational successor of ra
Hi Daniel,
2016-01-19 Daniel Vetter :
> On Fri, Jan 15, 2016 at 12:55:10PM -0200, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > This patch series de-stage the sync framework, and in order to accomplish
> > that
> > a bunch of cleanups/improvements on the sync and fence were made.
>
On 19.01.2016 01:05, Emil Velikov wrote:
>
> A few of those are already implicit with either Wall or Wextra. Both
> of which, imho, are a must have for any serious project.
I think -Wextra is generally too noisy for that, but I guess we're now
deeply in arguing about taste territory.
> But seri
On Wed, Oct 15, 2014 at 5:06 PM, Thomas Hellstrom
wrote:
> On 10/15/2014 10:51 PM, Rob Clark wrote:
>> On Wed, Oct 15, 2014 at 4:44 PM, Thomas Hellstrom
>> wrote:
>>> On 10/15/2014 10:38 PM, Rob Clark wrote:
On Wed, Oct 15, 2014 at 4:35 PM, Rob Clark wrote:
> On Wed, Oct 15, 2014 at 4
On Tue, Jan 19, 2016 at 8:03 AM, Christian König
wrote:
> Am 19.01.2016 um 09:59 schrieb Michel Dänzer:
>>
>> From: Michel Dänzer
>>
>> It can be big, depending on the VM address space size, which is tunable
>> via the vm_size module parameter.
>>
>> Bugzilla: https://bugs.freedesktop.org/show
On Tue, Jan 19, 2016 at 10:46:58AM +, John Keeping wrote:
> The Rockchip driver cannot use drm_atomic_helper_wait_for_vblanks()
> because it has hardware counters for neither vblanks nor scanlines.
>
> In order to simplify re-implementing the functionality for this driver,
> export the framebu
The Innosilicon HDMI is a low power HDMI 1.4 transmitter
IP, and it have been integrated on some rockchip CPUs
(like RK3036, RK312x).
Signed-off-by: Yakir Yang
---
Changes in v5:
- Use hdmi_infoframe helper functions to packed the infoframe (Russell)
- Remove the unused double wait_for_completion
On Fri, Jan 15, 2016 at 12:55:10PM -0200, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> This patch series de-stage the sync framework, and in order to accomplish that
> a bunch of cleanups/improvements on the sync and fence were made.
>
> The sync framework contained some abstractions aroun
Here are a brief introduction to Innosilicon HDMI IP:
- Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant transmitter
- Support HDMI1.4 a/b 3D function defined in HDMI 1.4 a/b spec
- Digital video interface supports a pixel size of 24, 30, 36, 48bits color
depth in RGB
- S/PDIF out
Hi Russell,
Thanks for your comments :-D
On 01/19/2016 01:15 AM, Russell King - ARM Linux wrote:
> Hi,
>
> Some comments below...
>
> On Mon, Jan 18, 2016 at 10:42:20PM +0800, Yakir Yang wrote:
>> +static int inno_hdmi_config_video_avi(struct inno_hdmi *hdmi)
>> +{
>> +char info[HDMI_SIZE_AVI
ors reported connected with modes
> >> [drm] Cannot find any crtc or sizes - going 1024x768
> >> Console: switching to colour frame buffer device 128x48
> >> drm-arcpgu e0017000.pgu: fb0: frame buffer device
> >> [drm] Initialized drm-arcpgu 1.0.0 20151127 on minor 0
> >> --- boot log snippet ---
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe
> >> linux-fbdev" in
> >> the body of a message to majordomo at vger.kernel.org
> >> <mailto:majordomo at vger.kernel.org>
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>
> >>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160119/3a67df07/attachment-0001.html>
Hi Russell,
2016-01-19 10:18 GMT+01:00 Russell King :
> Export further minor feature bitmasks and the varyings count from
> the GPU specifications registers to userspace.
>
> Signed-off-by: Russell King
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 57
> ++-
>
2016-01-19 10:18 GMT+01:00 Russell King :
> Update the common and state_hi xml.h header files from the etnaviv
> repository.
>
> Signed-off-by: Russell King
> ---
> drivers/gpu/drm/etnaviv/common.xml.h | 48
> --
> drivers/gpu/drm/etnaviv/state_hi.xml.h | 26 +++
Signed-off-by: John Keeping
---
v2:
- Add more detail of the particular race that could happen if we used
drm_atomic_helper_wait_for_vblanks().
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_
As commented in drm_atomic_helper_wait_for_vblanks(), userspace relies
on cursor ioctls being unsynced. Converting the rockchip driver to
atomic has significantly impacted cursor performance by making every
cursor update wait for vblank.
By skipping the vblank sync when the framebuffer has not ch
The Rockchip driver cannot use drm_atomic_helper_wait_for_vblanks()
because it has hardware counters for neither vblanks nor scanlines.
In order to simplify re-implementing the functionality for this driver,
export the framebuffer_changed() helper so it can be reused.
Signed-off-by: John Keeping
The first two patches are unchanged since v1 but the comment in the
third has been expanded following Thierry's comments.
John Keeping (3):
drm/atomic-helper: Export framebuffer_changed()
drm/rockchip: don't wait for vblank if fb hasn't changed
drm/rockchip: explain why we can't wait_for_vbl
Hi Marcin,
On 9 January 2016 at 17:05, Marcin Ålusarz wrote:
> Currently with --disable-amdgpu --disable-valgrind --disable-cairo-tests
> cunit, valgrind and cairo are still detected.
>
Doesn't this patch make 1/2 obsolete ?
> Signed-off-by: Marcin Ålusarz
Reviewed-by: Emil Velikov
> ---
>
On Tue, Jan 19, 2016 at 11:09:57AM +0100, Christian Gmeiner wrote:
> Hi Russell,
>
> 2016-01-19 10:18 GMT+01:00 Russell King :
> > + /*
> > +* For some cores, two varyings are consumed for position, so the
> > +* maximum varying count needs to be reduced by one.
> > +
On Mon, 18 Jan 2016 11:18:27 +0100
Maxime Ripard wrote:
> > Then, the DE2 sources contain only:
> >
> > All Winner Tech, All Right Reserved. 2014-2015 Copyright (c)
> >
> > Eventually, there is no copyright/author/history in the HDMI sources.
>
> That one is nasty though :/
>
> It seems t
On Tue, Jan 19, 2016 at 09:26:48AM +0100, Marek Szyprowski wrote:
> When no console framebuffer is enabled, the default plane state is
> defined by plane reset function. If driver uses generic helper, then
> rotation property is set to zero. This is not a valid value for that
> enum. This patch set
2016-01-19 9:20 GMT+01:00 Lucas Stach :
> Am Dienstag, den 19.01.2016, 08:05 +0100 schrieb Christian Gmeiner:
>> The varyings count is stored as part of register VIVS_HI_CHIP_SPECS_3.
>> Userspace still needs to validate the returned values as it can be 0
>> like on the imx6q.
>>
> We already fix u
https://bugzilla.kernel.org/show_bug.cgi?id=108221
--- Comment #13 from Michel Dänzer ---
(In reply to Fred Santos from comment #0)
> The problem is present only since an update to the kernel 4.3.0-3, the first
> versions of 4.3.x were OK for me.
Can you find out what changed in 4.3.0-3 compare
When no console framebuffer is enabled, the default plane state is
defined by plane reset function. If driver uses generic helper, then
rotation property is set to zero. This is not a valid value for that
enum. This patch sets default rotation value to DRM_ROTATE_0.
Signed-off-by: Marek Szyprowski
Am Dienstag, den 19.01.2016, 08:05 +0100 schrieb Christian Gmeiner:
> The varyings count is stored as part of register VIVS_HI_CHIP_SPECS_3.
> Userspace still needs to validate the returned values as it can be 0
> like on the imx6q.
>
We already fix up some of those register values in the kernel i
Export further minor feature bitmasks and the varyings count from
the GPU specifications registers to userspace.
Signed-off-by: Russell King
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 57 ++-
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 9 ++
include/uapi/drm/etn
Update the common and state_hi xml.h header files from the etnaviv
repository.
Signed-off-by: Russell King
---
drivers/gpu/drm/etnaviv/common.xml.h | 48 --
drivers/gpu/drm/etnaviv/state_hi.xml.h | 26 --
2 files changed, 64 insertions(+), 10 del
Co-incidentally, I also have a patch series along these same lines
created last night, only with all the review points already addressed.
I'll send it out momentarily.
Not quite fully tested because the VG core causes the kernel to oops
when reading /sys/kernel/debug/dri/1/gpu, but tested apart fr
2016-01-19 8:05 GMT+01:00 Christian Gmeiner :
> Freescales v5 kernel driver reads stream count from SPECS_4 register
> and if that value is 0 it falls back to the value from CHIP_SPECS.
>
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 11 +--
> 1 file c
2016-01-19 8:16 GMT+01:00 Ilia Mirkin :
> On Tue, Jan 19, 2016 at 2:05 AM, Christian Gmeiner
> wrote:
>> The varyings count is stored as part of register VIVS_HI_CHIP_SPECS_3.
>> Userspace still needs to validate the returned values as it can be 0
>> like on the imx6q.
>>
>> Signed-off-by: Christi
On Mon, 18 Jan 2016 20:09:04 +0100
Maxime Ripard wrote:
> > +static const struct clk_ops clk_sun8i_pll3_fact_ops = {
> > + .recalc_rate = sun8i_pll3_recalc_rate,
> > + .round_rate = sun8i_pll3_round_rate,
> > + .set_rate = sun8i_pll3_set_rate,
> > +};
>
> We have the clk-factors stuff to h
a screenshot of the game window taken just after a freeze occurred.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160119/ddc13b2f/attachment.html>
Freescales v5 kernel driver reads stream count from SPECS_4 register
and if that value is 0 it falls back to the value from CHIP_SPECS.
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drive
The varyings count is stored as part of register VIVS_HI_CHIP_SPECS_3.
Userspace still needs to validate the returned values as it can be 0
like on the imx6q.
Signed-off-by: Christian Gmeiner
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 11 +-
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 3
||
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160119/ac52e668/attachment.html>
eam/apps/208580/ss_e2043ae5d872d5576fd160acb3aa1169a5d0222c.1920x1080.jpg?t=1451421385
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160119/e87ad644/attachment.html>
the problems I am getting in OP?
Thanks again!
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160119/71fd6aee/attachment.html>
display.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160119/3459265a/attachment.html>
On Tue, Jan 19, 2016 at 3:11 AM, Christian Gmeiner
wrote:
> 2016-01-19 8:16 GMT+01:00 Ilia Mirkin :
>> On Tue, Jan 19, 2016 at 2:05 AM, Christian Gmeiner
>> wrote:
>>> The varyings count is stored as part of register VIVS_HI_CHIP_SPECS_3.
>>> Userspace still needs to validate the returned values
/lists.freedesktop.org/archives/dri-devel/attachments/20160119/2f9e6336/attachment.html>
On Tue, Jan 19, 2016 at 2:05 AM, Christian Gmeiner
wrote:
> The varyings count is stored as part of register VIVS_HI_CHIP_SPECS_3.
> Userspace still needs to validate the returned values as it can be 0
> like on the imx6q.
>
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etna
.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160119/cec43906/attachment.html>
On 25.11.2015 16:07, Thierry Reding wrote:
> On Wed, Oct 07, 2015 at 10:59:53PM +0200, Maciej S. Szmigiero wrote:
>> This adds vendor prefix for United Radiant Technology Corporation,
>> a provider of liquid crystal display technologies.
>>
>> Signed-off-by: Maciej Szmigiero
>> ---
>> Documentati
80 matches
Mail list logo
