From: Gustavo Padovan
Document IN_FENCE_FD and OUT_FENCE_PTR properties.
v2: incorporate comments from Daniel Vetter
Signed-off-by: Gustavo Padovan
---
Documentation/gpu/drm-kms.rst | 6 +
drivers/gpu/drm/drm_atomic.c | 52 +++
2 files changed, 58
ri-devel/attachments/20161122/76f2c080/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/18229192/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=110421
Vedran MiletiÄ changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/0462e2b3/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=188091
--- Comment #5 from Greg White ---
I should also note this is easily reproducible but still intermittent. I'd say
80% of the time, I see this. It's also not always one monitor - it can be
either of them.
--
You are receiving this mail because
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/604f7048/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=188091
--- Comment #6 from Vedran MiletiÄ ---
(In reply to Greg White from comment #5)
> I should also note this is easily reproducible but still intermittent. I'd
> say 80% of the time, I see this. It's also not always one monitor - it can
> be eith
ubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/04d21508/attachment.html>
:0 52
An unintentional loss of pictures occurs! Exit
--
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/20161122/215ac
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/fe41ac0e/attachment.html>
2016-11-21 Daniel Vetter :
> I totally butcherd the job on typing the kernel-doc for these, and no
> one realized. Noticed by Russell. Maarten has a more complete approach
> to this confusion, by making it more explicit what the new/old state
> is, instead of this magic switching behaviour.
>
> v
Hi all,
After merging the drm-misc tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
In file included from include/linux/pci.h:30:0,
from drivers/gpu/vga/vgaarb.c:40:
drivers/gpu/vga/vgaarb.c: In function 'vga_arb_device_init':
include/linux/device.h:
Hi Dave,
No critial patch but it make sure to unmap the region
if HDMI probing failed, and it includes two trivial fixups.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit c2ee69d83b2b14d68ad7ee1773fc1d40e97f201d:
Merge tag 'drm-
On Mon, Nov 21, 2016 at 02:55:28PM +, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 02:30:53PM +, Russell King - ARM Linux wrote:
> > On Mon, Nov 21, 2016 at 01:24:19PM +, Russell King - ARM Linux wrote:
> > > On Mon, Nov 21, 2016 at 12:56:53PM +, Liviu Dudau wrote:
> >
On Tue, Nov 22, 2016 at 09:11:28AM +0900, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Document IN_FENCE_FD and OUT_FENCE_PTR properties.
>
> v2: incorporate comments from Daniel Vetter
>
> Signed-off-by: Gustavo Padovan
> ---
> Documentation/gpu/drm-kms.rst | 6 +
> drivers/gpu/dr
Hi John,
Thank you for the patch.
On Monday 21 Nov 2016 16:37:30 John Stultz wrote:
> In chasing down issues with EDID probing, I found some
> duplicated but incomplete logic used to power the chip on and
> off.
>
> This patch refactors the adv7511_power_on/off functions, so
> they can be used f
On Tue, Nov 22, 2016 at 12:14 AM, Laurent Pinchart
wrote:
> Hi John,
>
> Thank you for the patch.
>
> On Monday 21 Nov 2016 16:37:30 John Stultz wrote:
>> In chasing down issues with EDID probing, I found some
>> duplicated but incomplete logic used to power the chip on and
>> off.
>>
>> This patc
Hi John,
Thank you for the patch.
On Monday 21 Nov 2016 16:37:31 John Stultz wrote:
> Secton 4.1 of the adv7511 programming guide advises one waits
> 200ms after powering on the chip before trying to communicate
> with it via i2c. Not doing so can cause reliability issues when
> probing the EDID.
Hi John,
On Tuesday 22 Nov 2016 00:16:55 John Stultz wrote:
> On Tue, Nov 22, 2016 at 12:14 AM, Laurent Pinchart wrote:
> > On Monday 21 Nov 2016 16:37:30 John Stultz wrote:
> >> In chasing down issues with EDID probing, I found some
> >> duplicated but incomplete logic used to power the chip on a
Hi John,
Thank you for the patch.
On Monday 21 Nov 2016 16:37:32 John Stultz wrote:
> From: Archit Taneja
>
> On some adv7511 implementations, we can get some spurious
> disconnect signals which can cause monitor probing to fail.
>
> This patch enables HPD (hot plug detect) interrupt support
>
From: Michel Dänzer
Fixes the vblank interrupt being disabled when it should be on, which
can cause at least the following symptoms:
* Hangs when running 'xset dpms force off' in a GNOME session with
gnome-shell using DRI2.
* RandR 1.4 slave outputs freezing with garbage displayed using
xf8
Hi Rob,
On Monday 21 Nov 2016 10:48:15 Rob Herring wrote:
> On Sat, Nov 19, 2016 at 05:28:01AM +0200, Laurent Pinchart wrote:
> > Document properties common to several display panels in a central
> > location that can be referenced by the panel device tree bindings.
>
> Looks good. Just one comme
Hi Frank,
On Tuesday 22 November 2016 07:13 AM, Frank Rowand wrote:
> On 11/21/16 08:33, Sekhar Nori wrote:
>> On Monday 31 October 2016 08:15 PM, Bartosz Golaszewski wrote:
>>> +static int da8xx_ddrctl_probe(struct platform_device *pdev)
>>> +{
>>> + const struct da8xx_ddrctl_config_knob *knob;
The DT binding for tildc is not consistent with the driver code - the
option in the binding is called 'max-width' while the code expects
'ti,max-width'.
Make the driver code consistent with the binding.
Signed-off-by: Bartosz Golaszewski
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
1 file ch
It has been determined that the highest resolution supported correctly
by LCDC rev1 is 800x600 on da850 due to memory bandwidth constraints.
Set the max_width property in da850.dtsi to 800.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/boot/dts/da850.dtsi | 1 +
1 file changed, 1 insertion(+)
Changes:
* add myself as maintainer, so patches land in my inbox.
* add qemu-devel mailing list.
* add drm-qemu git repo.
* flip bochs and qxl status to "Maintained".
Signed-off-by: Gerd Hoffmann
---
MAINTAINERS | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --gi
Also update Kconfig help text, explaining things:
Cirrus is obsolete, the hardware was designed in the 90ies
and can't keep up with todays needs. More background:
https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/
Better alternatives are:
- stdvga (DRM_BOCHS, qemu -vga s
On Tue, Nov 22, 2016 at 05:35:12PM +0900, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Fixes the vblank interrupt being disabled when it should be on, which
> can cause at least the following symptoms:
>
> * Hangs when running 'xset dpms force off' in a GNOME session with
> gnome-shell usi
On Mon, Nov 21, 2016 at 06:18:02PM +0100, Daniel Vetter wrote:
> I totally butcherd the job on typing the kernel-doc for these, and no
> one realized. Noticed by Russell. Maarten has a more complete approach
> to this confusion, by making it more explicit what the new/old state
> is, instead of thi
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/6e711402/attachment.sig>
2016-11-22 11:27 GMT+01:00 Tomi Valkeinen :
> On 22/11/16 11:42, Bartosz Golaszewski wrote:
>> It has been determined that the highest resolution supported correctly
>> by LCDC rev1 is 800x600 on da850 due to memory bandwidth constraints.
>>
>> Set the max_width property in da850.dtsi to 800.
>>
>>
Sekhar noticed there's a section mismatch in the da8xx-mstpri and
da8xx-ddrctl drivers. This is caused by calling
of_flat_dt_get_machine_name() which has an __init annotation.
This series addresses this issue by introducing a new function that
allows to retrieve the compatible property of the root
Add a function allowing to retrieve the compatible string of the root
node of the device tree.
Signed-off-by: Bartosz Golaszewski
---
drivers/of/base.c | 22 ++
include/linux/of.h | 6 ++
2 files changed, 28 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/bas
In order to avoid a section mismatch use of_machine_get_compatible()
instead of of_flat_dt_get_machine_name() when printing the error
message.
Signed-off-by: Bartosz Golaszewski
---
drivers/bus/da8xx-mstpri.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bus/da8xx-m
In order to avoid a section mismatch use of_machine_get_compatible()
instead of of_flat_dt_get_machine_name() when printing the error
message.
Signed-off-by: Bartosz Golaszewski
---
drivers/memory/da8xx-ddrctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/memory/d
This adds the required boilerplate to allow direct mmap of exported
etnaviv BOs.
Signed-off-by: Lucas Stach
Tested-by: Philipp Zabel
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 1 +
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 2 ++
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 13
Hi Gustavo,
A little late to the party here, but I was blocked by our internal
contributions process...
I didn't see these end up in my checkout yet though, so I guess they
aren't picked up yet.
On Mon, Nov 14, 2016 at 06:59:21PM +0900, Gustavo Padovan wrote:
>From: Gustavo Padovan
>
>Add suppo
2016-11-22 11:53 GMT+01:00 Sudeep Holla :
>
>
> On 22/11/16 10:41, Bartosz Golaszewski wrote:
>>
>> Add a function allowing to retrieve the compatible string of the root
>> node of the device tree.
>>
>
> Rob has queued [1] and it's in -next today. You can reuse that if you
> are planning to target
2016-11-22 11:57 GMT+01:00 Bartosz Golaszewski :
> 2016-11-22 11:53 GMT+01:00 Sudeep Holla :
>>
>>
>> On 22/11/16 10:41, Bartosz Golaszewski wrote:
>>>
>>> Add a function allowing to retrieve the compatible string of the root
>>> node of the device tree.
>>>
>>
>> Rob has queued [1] and it's in -ne
I should go read the patch that introduces panel-common.txt
first...
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/a11ae106/attachment.sig>
y? That's also implied by the compatible string. Honestly, I thought
by now we had been over this often enough...
Thierry
-- next part ------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/ed0ff2df/attachment.sig>
On Tue, Nov 22, 2016 at 10:53:51AM +, Brian Starkey wrote:
> Hi Gustavo,
>
> A little late to the party here, but I was blocked by our internal
> contributions process...
>
> I didn't see these end up in my checkout yet though, so I guess they
> aren't picked up yet.
>
> On Mon, Nov 14, 2016
cation/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/88e3057c/attachment.sig>
Hi,
On Mon, Nov 14, 2016 at 06:59:20PM +0900, Gustavo Padovan wrote:
>From: Robert Foss
>
>Add support dor the IN_FENCE_FD property to enable setting in fences for atomic
>commits.
>
>Signed-off-by: Robert Foss
>---
> lib/igt_kms.c | 20
> lib/igt_kms.h | 5 +
> 2 files c
On Tue, Nov 22, 2016 at 11:06:00AM +, Chris Wilson wrote:
>On Tue, Nov 22, 2016 at 10:53:51AM +, Brian Starkey wrote:
>> Hi Gustavo,
>>
>> A little late to the party here, but I was blocked by our internal
>> contributions process...
>>
>> I didn't see these end up in my checkout yet though
On Tue, Nov 22, 2016 at 11:54:57AM +, Brian Starkey wrote:
> On Tue, Nov 22, 2016 at 11:06:00AM +, Chris Wilson wrote:
> >On Tue, Nov 22, 2016 at 10:53:51AM +, Brian Starkey wrote:
> >>Hi Gustavo,
> >>
> >>A little late to the party here, but I was blocked by our internal
> >>contributi
On Tue, Nov 22, 2016 at 12:10:52PM +, Chris Wilson wrote:
>On Tue, Nov 22, 2016 at 11:54:57AM +, Brian Starkey wrote:
>> On Tue, Nov 22, 2016 at 11:06:00AM +, Chris Wilson wrote:
>> >On Tue, Nov 22, 2016 at 10:53:51AM +, Brian Starkey wrote:
>> >>Hi Gustavo,
>> >>
>> >>A little late
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/5e585c27/attachment.html>
Sekhar noticed there's a section mismatch in the da8xx-mstpri and
da8xx-ddrctl drivers. This is caused by calling
of_flat_dt_get_machine_name() which has an __init annotation.
This series addresses this issue by open coding routines that return
the machine compatible string in both drivers. Once a
In order to avoid a section mismatch use a locally implemented routine
instead of of_flat_dt_get_machine_name() when printing the error
message.
Signed-off-by: Bartosz Golaszewski
---
drivers/bus/da8xx-mstpri.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff -
In order to avoid a section mismatch use a locally implemented routine
instead of of_flat_dt_get_machine_name() when printing the error
message.
Signed-off-by: Bartosz Golaszewski
---
drivers/memory/da8xx-ddrctl.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
dif
On Tue, Nov 22, 2016 at 12:37:47PM +, Brian Starkey wrote:
> On Tue, Nov 22, 2016 at 12:10:52PM +, Chris Wilson wrote:
> > On Tue, Nov 22, 2016 at 11:54:57AM +, Brian Starkey wrote:
> > > On Tue, Nov 22, 2016 at 11:06:00AM +, Chris Wilson wrote:
> > > >On Tue, Nov 22, 2016 at 10:53:
Hi Thierry,
On Tuesday 22 Nov 2016 12:05:48 Thierry Reding wrote:
> On Sat, Nov 19, 2016 at 05:28:01AM +0200, Laurent Pinchart wrote:
> > Document properties common to several display panels in a central
> > location that can be referenced by the panel device tree bindings.
> >
> > Signed-off-by:
Hi Thierry,
On Tuesday 22 Nov 2016 12:14:57 Thierry Reding wrote:
> On Sat, Nov 19, 2016 at 05:28:06AM +0200, Laurent Pinchart wrote:
> > This driver supports LVDS panels that don't require device-specific
> > handling of power supplies or control signals. It implements automatic
> > backlight han
Hi Thierry,
On Tuesday 22 Nov 2016 12:02:41 Thierry Reding wrote:
> On Sat, Nov 19, 2016 at 05:28:02AM +0200, Laurent Pinchart wrote:
> > LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
> > Multiple incompatible data link layers have been used over time to
> > transmit image
On Wed, Nov 09, 2016 at 08:00:06PM +, Matthew Auld wrote:
> On 7 November 2016 at 19:49, Robert Bragg wrote:
> > Adds base i915 perf infrastructure for Gen performance metrics.
> >
> > This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
> > properties to configure a stream
On Tue, Nov 22, 2016 at 02:29:18PM +0100, Daniel Vetter wrote:
> On Wed, Nov 09, 2016 at 08:00:06PM +, Matthew Auld wrote:
> > On 7 November 2016 at 19:49, Robert Bragg wrote:
> > > Adds base i915 perf infrastructure for Gen performance metrics.
> > >
> > > This adds a DRM_IOCTL_I915_PERF_OPEN
On Tue, Nov 08, 2016 at 12:51:48PM +, Robert Bragg wrote:
> This v2 patch bumps the command parser version so it can be referenced in
> corresponding i-g-t gem_exec_parse changes.
>
> --- >8 ---
Scissors cut everything below, not everything above, hence next time
around pls switch around your
From: Ville Syrjälä
Allow drivers to return a custom drm_format_info structure for special
fb layouts. We'll use this for the compression control surface in i915.
v2: Fix drm_get_format_info() kernel doc (Laurent)
Don't pass 'dev' to the new hook (Laurent)
Cc: Laurent Pinchart
Cc: Ben Wi
On Mon, Nov 07, 2016 at 07:49:57PM +, Robert Bragg wrote:
> In particular this tries to capture for posterity some of the early
> challenges we had with using the core perf infrastructure in case we
> ever want to revisit adapting perf for device metrics.
>
> Cc: Chris Wilson
> Signed-off-by:
On Mon, Nov 21, 2016 at 11:51:21AM +, Liviu Dudau wrote:
> On Fri, Nov 18, 2016 at 09:52:45PM +0200, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrjälä
> >
> > Add a local 'fb' variable to a few places to get rid of the
> > 'crtc->primary->fb' stuff. Looks neater and helps m
On Tue, Nov 22, 2016 at 02:12:59PM +0100, Daniel Vetter wrote:
>On Tue, Nov 22, 2016 at 12:37:47PM +, Brian Starkey wrote:
>> On Tue, Nov 22, 2016 at 12:10:52PM +, Chris Wilson wrote:
>> > On Tue, Nov 22, 2016 at 11:54:57AM +, Brian Starkey wrote:
>> > > On Tue, Nov 22, 2016 at 11:06:00
From: Ville Syrjälä
drm_framebuffer_init() will start to check that fb->dev is already
populated, so let's do that manually since vmwgfx isn't using
drm_helper_mode_fill_fb_struct().
v2: s/to/do/ (Sinclair)
Cc: linux-graphics-maintainer at vmware.com
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
Si
On Tue, Nov 22, 2016 at 01:50:53PM +, Brian Starkey wrote:
> On Tue, Nov 22, 2016 at 02:12:59PM +0100, Daniel Vetter wrote:
> > On Tue, Nov 22, 2016 at 12:37:47PM +, Brian Starkey wrote:
> > > On Tue, Nov 22, 2016 at 12:10:52PM +, Chris Wilson wrote:
> > > > On Tue, Nov 22, 2016 at 11:5
On Tue, Nov 22, 2016 at 03:48:50PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 21, 2016 at 11:51:21AM +, Liviu Dudau wrote:
> > On Fri, Nov 18, 2016 at 09:52:45PM +0200, ville.syrjala at linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Add a local 'fb' variable to a few pla
to be fixed, too.
>
> Another nitpick for the future: Enabling new features first and then
> fixing up the fallout is the wrong way round, if someone bisects over this
> range mesa might blow up in really bad ways.
>
> Oh well, this has been out there for way too long, so meh.
>
Fwiw I'm aware of this, and think I've ordered the patches correctly to
avoid bisect problems in Mesa / userspace. This infrastructure patch should
have no fallout to fix for userspace. The command parser changes that
affect userspace were done before adding oacontrol usage to i915-perf and
the cmd parser's EINVAL reporting for access failures was changed *before*
removing oacontrol from the whitelist.
Did I overlook something in particular?
- Robert
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/a04d5653/attachment.html>
On Tue, Nov 22, 2016 at 02:56:49PM +0100, Daniel Vetter wrote:
>On Tue, Nov 22, 2016 at 01:50:53PM +, Brian Starkey wrote:
>> On Tue, Nov 22, 2016 at 02:12:59PM +0100, Daniel Vetter wrote:
>> > On Tue, Nov 22, 2016 at 12:37:47PM +, Brian Starkey wrote:
>> > > On Tue, Nov 22, 2016 at 12:10:5
if (cmd >= batch_end) {
> > DRM_DEBUG_DRIVER("CMD: Got to the end of the buffer w/o a
> BBE cmd!\n");
> > ret = -EINVAL;
> > @@ -1336,6 +1302,8 @@ int i915_cmd_parser_get_version(struct
> drm_i915_private *dev_priv)
> >* 8. Don't report cmd_check() failures as EINVAL errors to
> userspace;
> >*rely on the HW to NOOP disallowed commands as it would
> without
> >*the parser enabled.
> > + * 9. Don't whitelist or handle oacontrol specially, as ownership
> > + *for oacontrol state is moving to i915-perf.
> >*/
> > - return 8;
> > + return 9;
> > }
> > --
> > 2.10.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/c29c546c/attachment.html>
On 16 November 2016 at 11:14, Nicolai Hähnle wrote:
> On 10.11.2016 18:43, Emil Velikov wrote:
>>
>> From: Emil Velikov
>>
>> The original version considered only card devices, while this will pick
>> the device/node name regardless - card, control, renderD, other...
>>
>> Current implementation
On 21 November 2016 at 19:55, Alex Deucher wrote:
> On Sun, Nov 20, 2016 at 1:25 PM, Grazvydas Ignotas
> wrote:
>> Just some trivial boring typo fixes all over the tree.
>> READMEs and comments only.
>>
>> Signed-off-by: Grazvydas Ignotas
>
> Reviewed-by: Alex Deucher
>
Thanks gents. Just push
We now pass the device to the debug messages, but on non-x86,
this is an invalid pointer in vga_arb_device_init:
drivers/gpu/vga/vgaarb.c: In function 'vga_arb_device_init':
drivers/gpu/vga/vgaarb.c:1467:4: error: 'dev' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
Thi
Changes since v3:
- "drm/tilcdc: Enable sync lost error and recovery handling for rev 1 LCDC"
- Fix broken irq enable/disble code for LCDC rev 1
- Add: "dt-bindings: Move "ti,tfp410.txt" from display/ti to display/bridge"
- "drm/bridge: Add ti-tfp410 DVI transmitter driver"
- Don't fail if eith
Move "ti,tfp410.txt" from display/ti to display/bridge before adding
generic (non omapdrm/dss specific) implementation and new features.
Signed-off-by: Jyri Sarha
---
.../bindings/display/bridge/ti,tfp410.txt | 41 ++
.../devicetree/bindings/display/ti/ti,tfp410.txt
Adds drm bride support for attaching drm bridge drivers to tilcdc. The
decision whether a video port leads to an external encoder or bridge
is made simply based on remote device's compatible string. The code
has been tested with BeagleBone-Black with and without BeagleBone
DVI-D Cape Rev A3 using t
Recover from sync lost error flood by resetting the LCDC instead of
turning off the SYNC_LOST error IRQ. When LCDC starves on limited
memory bandwidth it may sometimes result an error situation when the
picture may have shifted couple of pixels to right and SYNC_LOST
interrupt is generated on every
Add very basic ti-tfp410 DVI transmitter driver. The only feature
separating this from a completely dummy bridge is the EDID read
support trough DDC I2C. Even that functionality should be in a
separate generic connector driver. However, because of missing DRM
infrastructure support the connector is
On Tue, Nov 22, 2016 at 3:35 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Fixes the vblank interrupt being disabled when it should be on, which
> can cause at least the following symptoms:
>
> * Hangs when running 'xset dpms force off' in a GNOME session with
> gnome-shell using DRI2.
>
uild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 25159 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/7b21c6e5/attachment-0001.gz>
On Tue, Nov 22, 2016 at 02:02:38PM +, Robert Bragg wrote:
> On Tue, Nov 22, 2016 at 1:31 PM, Daniel Vetter wrote:
>
> > On Tue, Nov 22, 2016 at 02:29:18PM +0100, Daniel Vetter wrote:
> > > On Wed, Nov 09, 2016 at 08:00:06PM +, Matthew Auld wrote:
> > > > On 7 November 2016 at 19:49, Rober
On Tue, Nov 22, 2016 at 02:09:08PM +, Robert Bragg wrote:
> On Tue, Nov 22, 2016 at 1:34 PM, Daniel Vetter wrote:
>
> > On Tue, Nov 08, 2016 at 12:51:48PM +, Robert Bragg wrote:
> > > This v2 patch bumps the command parser version so it can be referenced in
> > > corresponding i-g-t gem_e
he display engine by default would be better?
> At least simplefb still works.
Yep, that works for me.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/65608cd9/attachment.sig>
On Tue, Nov 22, 2016 at 03:34:19PM +0100, Arnd Bergmann wrote:
> We now pass the device to the debug messages, but on non-x86,
> this is an invalid pointer in vga_arb_device_init:
>
> drivers/gpu/vga/vgaarb.c: In function 'vga_arb_device_init':
> drivers/gpu/vga/vgaarb.c:1467:4: error: 'dev' may b
Here are a few foundational patches to clean up some of the MSM code
and get ready for new and awesome things down the line.
Jordan Crouse (3):
drm/msm: gpu: Cut down the list of "generic" registers to the ones we use
drm/msm: gpu: Return error on hw_init failure
drm/msm: gpu Add
There are very few register accesses in the common code. Cut down
the list of common registers to just those that are used. This
saves const space and saves us the effort of maintaining registers
for A3XX and A4XX that don't exist or are unused.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/
When the GPU hardware init function fails (like say, ME_INIT timed
out) return error instead of blindly continuing on. This gives us
a small chance of saving the system before it goes boom.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 21 -
drive
Add some new functions to manipulate GPU registers. gpu_read64 and
gpu_write64 can read/write a 64 bit value to two 32 bit registers.
For 4XX and older these are normally perfcounter registers, but
future targets will use 64 bit addressing so there will be many
more spots where a 64 bit read and w
edded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161122/a28ed215/attachment.sig>
drm_get_format_name() de-references the buf parameter without checking
if the pointer was not NULL. Given that the function is EXPORT-ed, lets
sanitise the parameters before proceeding.
Fixes: b3c11ac267d461d3d5 ("drm: move allocation out of drm_get_format_name())
Cc: Eric Engestrom
Cc: Rob Clark
On Tue, Nov 22, 2016 at 04:41:06PM +, Liviu Dudau wrote:
> drm_get_format_name() de-references the buf parameter without checking
> if the pointer was not NULL. Given that the function is EXPORT-ed, lets
> sanitise the parameters before proceeding.
>
> Fixes: b3c11ac267d461d3d5 ("drm: move all
Hi Dave,
Just one small fix for amdgpu.
The following changes since commit 1da2c326e43b0834105993d13610647337bbad67:
drm/amdgpu:fix vpost_needed routine (2016-11-15 14:06:07 -0500)
are available in the git repository at:
git://people.freedesktop.org/~agd5f/linux drm-fixes-4.9
for you to f
From: Bartosz Golaszewski
Revision 1 of the IP doesn't work if we don't load the palette (even
if it's not used, which is the case for the RGB565 format).
Add a function called from tilcdc_crtc_enable() which performs all
required actions if we're dealing with a rev1 chip.
Signed-off-by: Bartos
Revision 1 LCDC support also sync lost errors and can benefit from
sync lost recovery routine.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 33 +
drivers/gpu/drm/tilcdc/tilcdc_regs.h | 1 +
2 files changed, 18 insertions(+), 16 deletions(-
The git branch bellow is updated.
Changes since v2:
- Add: "drm/tilcdc: Fix load mode bit-field setting in tilcdc_crtc_enable()"
- Drop: "drm/tilcdc: Free palette dma memory in tilcdc_crtc_destroy()"
- Add: "drm/tilcdc: Add timeout wait for palette loading to complete"
- Add: "drm/tilcdc: Call res
Set LCDC_PALETTE_LOAD_MODE bit-field with new tilcdc_write_mask()
instead of tilcdc_set(). Setting a bit-fields with tilcdc_set() is
fundamentally broken.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/dri
Load palette at the end of mode_set_nofb() and only if the palette has
not been loaded since last runtime resume. Moving the palette loading
to mode_set_nofb() saves us from storing and restoring of LCDC dma
addresses that were just recently updated.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm
We should wait for the last frame to complete before shutting things
down also on LCDC rev 1.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 34 +-
drivers/gpu/drm/tilcdc/tilcdc_regs.h | 1 +
2 files changed, 18 insertions(+), 17 deletions(-
Add tilcdc_write_mask() for handling register field wider than one bit
and mask values for those fields.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_regs.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_regs.h
b/drivers/gpu/drm/t
We need to use complete_all() to indicate completed palette loading in
stead of plain complete() if we want to test if the palette has
already been loaded with completion_done().
indicated with.
Signed-off-by: Jyri Sarha
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +-
1 file changed, 1 insertio
The palette loading does not work reliably without LCDC SW reset
before it. The AM335x TRM suggests this [1] after L3 clock domain has
been shut down. We have no knowledge of such events so we do it
always. The software reset will clear all the frame information in the
FIFO. Upon a restart, the L3
1 - 100 of 176 matches
Mail list logo
