On Tue, Nov 22, 2016 at 08:51:11AM +0900, Gustavo Padovan wrote:
> 2016-11-21 Daniel Vetter :
> > /**
> > * drm_atomic_helper_commit_tail - commit atomic update to hardware
> > - * @state: new modeset state to be committed
> > + * @old_state: atomic state object with old state structures
> > *
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161121/e7d526d6/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=188321
Bug ID: 188321
Summary: i915: black screen after disconnecting HDMI monitor
Product: Drivers
Version: 2.5
Kernel Version: 4.x
Hardware: x86-64
OS: Linux
Tree:
-dev/2016-November/136065.html
https://lists.freedesktop.org/archives/mesa-dev/2016-November/136066.html
--
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/20161121/0e5f97bd/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=188091
--- Comment #4 from Greg White ---
Note that those two files were grabbed after I switched to a VT (since the UI
was in a pretty whacked state.)
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=188091
--- Comment #3 from Greg White ---
Created attachment 245471
--> https://bugzilla.kernel.org/attachment.cgi?id=245471&action=edit
dmesg
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=188091
--- Comment #2 from Greg White ---
Created attachment 245461
--> https://bugzilla.kernel.org/attachment.cgi?id=245461&action=edit
Xorg log
--
You are receiving this mail because:
You are watching the assignee of the bug.
Hi Daniel,
On Fri, 2016-11-18 at 12:56 +0800, Daniel Kurtz wrote:
> Hi YT,
>
> I don't see a reason to handle device_data in such a generic way at
> the generic mtk_ddp_comp layer.
> The device data is very component specific, so just define different
> structs for different comp types, ie:
>
>
https://bugzilla.kernel.org/show_bug.cgi?id=188091
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 f
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;
> + const struct da8xx_ddrctl_setting *setting;
> + struct device_node *node;
> + struct resource *res;
Nevermind, the cbr issue was reproduced and fixed. Please try the latest patch
I just send.
--
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/20161121/20a63e85/attachment.html>
Hi Daniel,
Thanks for the review.
On Fri, 2016-11-18 at 11:21 +0800, Daniel Kurtz wrote:
> Hi YT,
>
> Sorry for the very late review.
>
> My biggest problem with this patch is it describes itself as adding
> support for a new use case "DSI -> panel", but makes many changes to
> the existing wor
On Mon, Nov 21, 2016 at 11:00:52AM -0800, Manasi Navare wrote:
> On Mon, Nov 21, 2016 at 04:48:07PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 21, 2016 at 11:10:45AM +0100, Daniel Vetter wrote:
> > > On Mon, Nov 21, 2016 at 09:42:57AM +, Chris Wilson wrote:
> > > > On Mon, Nov 21, 2016 at 10:3
This is certainly not the first time this has been brought up, but I'd like to
try and get some consensus on the best way to move this forward. Allowing
devices to talk directly improves performance and reduces latency by avoiding
the use of staging buffers in system memory. Also in cases wher
Hi,
> Also I think one shared git repo for all of them would be
> good.
Yep, I'm doing that (see today's drm-qemu pull req @ dri-devel).
But, yes, I can place the git repo link in MAINTAINERS too.
cheers,
Gerd
On Mon, Nov 21, 2016 at 07:24:34PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> I'm busy updating the MAINTAINERS file for the linux kernel, making sure
> I'm listed for all qemu drm drivers (cirrus, bochs, qxl, virtio), so
> patches land in my inbox.
>
> While being at it: I'm wondering whenever it
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161121/3c865668/attachment.html>
there's one difference I noted. v5 says dpms
is Off, while v6 says dpms is On.
> Which resolution do you expect?
>
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161121/1453ca53/attachment-0001.sig>
On 11/21/16 19:16, Bartosz Golaszewski wrote:
> It has been determined that the highest resolution supported correctly
> by LCDC rev1 is 800x600. Reduce the max_width value for rev1 to 800 in
> crtc_max_width().
>
I don't think this is the right way to limit the supported video modes.
There is te
Hi,
I'm busy updating the MAINTAINERS file for the linux kernel, making sure
I'm listed for all qemu drm drivers (cirrus, bochs, qxl, virtio), so
patches land in my inbox.
While being at it: I'm wondering whenever it makes sense to also
include the qemu-devel list there. I think it would be u
On Mon, 21 Nov 2016 01:54:53 +0100
OndÅej Jirman wrote:
> Dne 20.11.2016 v 12:32 Jean-Francois Moine napsal(a):
> > This patchset series adds HDMI video support to the Allwinner
> > sun8i SoCs which include the display engine 2 (DE2).
> > The driver contains the code for the A83T and H3, but it
Hi Dave,
Here are the drm-qemu updates for 4.10.
please pull,
Gerd
The following changes since commit
a25f0944ba9b1d8a6813fd6f1a86f1bd59ac25a6:
Linux 4.9-rc5 (2016-11-13 10:32:32 -0800)
are available in the git repository at:
git://git.kraxel.org/linux tags/drm-qemu-20161121
for you
On Mon, Nov 21, 2016 at 06:23:24PM +, Liviu Dudau wrote:
> On Mon, Nov 21, 2016 at 05:56:02PM +, Russell King - ARM Linux wrote:
> > For me, the image shift was 100% reproducable. With the above patch
> > and a call to drm_crtc_vblank_on() in the enable path, it seems to
> > behave correct
2016-11-21 18:26 GMT+01:00 Jyri Sarha :
> On 11/21/16 19:16, Bartosz Golaszewski wrote:
>> It has been determined that the highest resolution supported correctly
>> by LCDC rev1 is 800x600. Reduce the max_width value for rev1 to 800 in
>> crtc_max_width().
>>
>
> I don't think this is the right way
On Mon, Nov 21, 2016 at 06:16:16PM +, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 05:56:02PM +, Russell King - ARM Linux wrote:
> > For me, the image shift was 100% reproducable. With the above patch
> > and a call to drm_crtc_vblank_on() in the enable path, it seems to
> > b
On Mon, Nov 21, 2016 at 05:56:02PM +, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 05:32:32PM +, Liviu Dudau wrote:
> > On Mon, Nov 21, 2016 at 02:03:49PM +, Russell King - ARM Linux wrote:
> > > On Mon, Nov 21, 2016 at 01:50:31PM +, Liviu Dudau wrote:
> > > > On Mon, N
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.
v2:
- Liviu pointed out that wait_for_fen
It has been determined that the highest resolution supported correctly
by LCDC rev1 is 800x600. Reduce the max_width value for rev1 to 800 in
crtc_max_width().
Signed-off-by: Bartosz Golaszewski
---
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
While debugging the drm_bridge support for revision 1 I noticed the
driver was selecting the 1024x768 resolution as default from the set
retrieved from EDID. The following patch reduces the max_width for
rev1 in tilcdc.
Bartosz Golaszewski (1):
drm: tilcdc: reduce max_width for revision 1
driv
On Mon, Nov 21, 2016 at 05:56:02PM +, Russell King - ARM Linux wrote:
> For me, the image shift was 100% reproducable. With the above patch
> and a call to drm_crtc_vblank_on() in the enable path, it seems to
> behave correctly - I can alternately switch between 1920x1080 and
> 1280x1024 and i
Hi Robin,
On 21/11/16 17:47, Robin Murphy wrote:
> Hi Bartosz, Sekhar,
>
> On 21/11/16 16:48, Bartosz Golaszewski wrote:
[...]
>> Hi Sekhar,
>>
>> thanks for spotting that.
>>
>> I think we should introduce this function right away, rather than
>> having two static functions doing the same thing
On Mon, Nov 21, 2016 at 05:32:32PM +, Liviu Dudau wrote:
> On Mon, Nov 21, 2016 at 02:03:49PM +, Russell King - ARM Linux wrote:
> > On Mon, Nov 21, 2016 at 01:50:31PM +, Liviu Dudau wrote:
> > > On Mon, Nov 21, 2016 at 01:24:19PM +, Russell King - ARM Linux wrote:
> > > > On Mon, N
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.
v2:
- Liviu pointed out that wait_for_fen
We need to call drm_helper_hpd_irq_event() on resume to properly detect
monitor connection / disconnection on some laptops, use hpd_work for
this to avoid deadlocks.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 11 ++-
1 file changed, 10 insertions(+), 1 delet
We need to call drm_helper_hpd_irq_event() on resume to properly detect
monitor connection / disconnection on some laptops. For runtime-resume
(which gets called on resume from normal suspend too) we must call
drm_helper_hpd_irq_event() from a workqueue to avoid a deadlock.
Rename acpi_work to hpd
2016-11-21 17:33 GMT+01:00 Sekhar Nori :
> 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;
>> + const struct da8xx_ddrctl_setting *setting;
>> + struct
Hi Bartosz, Sekhar,
On 21/11/16 16:48, Bartosz Golaszewski wrote:
> 2016-11-21 17:33 GMT+01:00 Sekhar Nori :
>> 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 *kn
Hi Sekhar,
(And adding Sudeep since he becomes involved in this further
down thread and at that point says he will re-work this
proposed work around in a manner that is incorrect in a
manner that is similar to this proposed work around.)
On 11/21/16 08:33, Sekhar Nori wrote:
> On Monday 31 Octobe
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.
Cc: Liviu Dudau
Reported-by: Russell Kin
On Mon, Nov 21, 2016 at 02:03:49PM +, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 01:50:31PM +, Liviu Dudau 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:
> > > > That is m
https://bugzilla.kernel.org/show_bug.cgi?id=188271
--- Comment #6 from Vadim Markovtsev ---
Created attachment 245411
--> https://bugzilla.kernel.org/attachment.cgi?id=245411&action=edit
uname -a
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=188271
--- Comment #5 from Vadim Markovtsev ---
Created attachment 245401
--> https://bugzilla.kernel.org/attachment.cgi?id=245401&action=edit
cat /proc/cmdline
Added intel_iommu=off
--
You are receiving this mail because:
You are watching the assi
https://bugzilla.kernel.org/show_bug.cgi?id=188271
--- Comment #4 from Vadim Markovtsev ---
Created attachment 245391
--> https://bugzilla.kernel.org/attachment.cgi?id=245391&action=edit
nvidia-smi proto -m
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=188271
--- Comment #3 from Vadim Markovtsev ---
Created attachment 245381
--> https://bugzilla.kernel.org/attachment.cgi?id=245381&action=edit
lspci -knnv
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=188271
--- Comment #2 from Vadim Markovtsev ---
Created attachment 245371
--> https://bugzilla.kernel.org/attachment.cgi?id=245371&action=edit
lscpu
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=188271
--- Comment #1 from Vadim Markovtsev ---
Created attachment 245361
--> https://bugzilla.kernel.org/attachment.cgi?id=245361&action=edit
dmidecode -t 2
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=188271
Bug ID: 188271
Summary: IOMMU DMAR fault with NVIDIA CUDA peer to peer
Product: Drivers
Version: 2.5
Kernel Version: 4.8.6
Hardware: x86-64
OS: Linux
Tree: Ma
On Mon, Nov 21, 2016 at 05:52:57PM +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
On Mon, Nov 21, 2016 at 11:10:45AM +0100, Daniel Vetter wrote:
> On Mon, Nov 21, 2016 at 09:42:57AM +, Chris Wilson wrote:
> > On Mon, Nov 21, 2016 at 10:38:20AM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 18, 2016 at 09:44:49AM -0800, Manasi Navare wrote:
> > > > On Fri, Nov 18, 2016 at 06:2
On Mon, Nov 21, 2016 at 05:35:20PM +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
On Fri, Nov 18, 2016 at 03:31:48PM -0800, Ben Widawsky wrote:
> On 16-11-18 21:53:13, Ville Syrjälä wrote:
> >From: Ville Syrjälä
> >
> >By providing our own format information for the CCS formats, we should
> >be able to make framebuffer_check() do the right thing for the CCS
> >surface as we
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
which allows the monitor to be properly re-initialized when
the spurious disconnect signal goes awa
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.
See:
http://www.analog.com/media/en/technical-documentation/user-guides/ADV7511_Programming_
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 for internal needs, and replaces duplicative
logic that powers the chip on and off around the EDID
I had been seeing some EDID probing issues with the adv7511 driver
on HiKey recently. After talking with Archit and spending some time
reading the programming guide, I put together the following patch
set which seems to resolve the EDID probing issues.
I wanted to send these out for some early rev
On Mon, Nov 21, 2016 at 03:42:34PM +0200, Laurent Pinchart wrote:
> Hi Ville,
>
> On Monday 21 Nov 2016 15:31:57 Ville Syrjälä wrote:
> > On Mon, Nov 21, 2016 at 03:23:19PM +0200, Laurent Pinchart wrote:
> > > On Monday 21 Nov 2016 15:18:23 Ville Syrjälä wrote:
> > >> On Sun, Nov 20, 2016 at 1
Renamed to avoid the seemingly redundant 'context_' infix and note that it's
been reviewed by Matthew Auld.
--- >8 ---
Exposing the u32 context ID makes it possible to define new drm kernel
interfaces based on the same IDs that e.g. execbuf uses to identify a
gem context, that aren't themselves a
From: Gustaf Lindström
The Sharp 15" LQ150X1LG11 panel is an XGA TFT LCD panel.
The simple-panel driver is used to get support for essential
functionality of the panel.
Signed-off-by: Gustaf Lindström
Signed-off-by: Peter Rosin
---
drivers/gpu/drm/panel/panel-simple.c | 27
The Sharp 15" LQ150X1LG11 panel is an XGA TFT LCD panel.
Signed-off-by: Peter Rosin
---
.../bindings/display/panel/sharp,lq150x1lg11.txt | 36 ++
1 file changed, 36 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt
dif
Hi!
This patch seems to have been forgotten? Thierry said that a
resend was not needed, but time is passing and the merge window
is nearing, so I'm resending anyway with the squashed .bpc-fix.
v4 -> v5 changes:
- change sharp_lq150x1lg11.bpc to 6 as noted by Thierry
- rebased onto v4.9-rc6
v3 ->
Hi Ville,
On Monday 21 Nov 2016 15:31:57 Ville Syrjälä wrote:
> On Mon, Nov 21, 2016 at 03:23:19PM +0200, Laurent Pinchart wrote:
> > On Monday 21 Nov 2016 15:18:23 Ville Syrjälä wrote:
> >> On Sun, Nov 20, 2016 at 10:13:10AM +0200, Laurent Pinchart wrote:
> >>> On Friday 18 Nov 2016 21:53:12
On Mon, Nov 21, 2016 at 03:23:19PM +0200, Laurent Pinchart wrote:
> Hi Ville,
>
> On Monday 21 Nov 2016 15:18:23 Ville Syrjälä wrote:
> > On Sun, Nov 20, 2016 at 10:13:10AM +0200, Laurent Pinchart wrote:
> > > On Friday 18 Nov 2016 21:53:12 ville.syrjala at linux.intel.com wrote:
> > >> From: Vi
Hi Ville,
On Fri, 2016-11-18 at 21:52 +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 me with my ppor
> coccinelle skills later.
>
> Cc: Alexey Brodkin
>
On Mon, Nov 21, 2016 at 08:42:13AM +, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 18/11/2016 19:53, ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > By providing our own format information for the CCS formats, we should
> > be able to make framebuffer_check() do the right t
Hi Ville,
On Monday 21 Nov 2016 15:18:23 Ville Syrjälä wrote:
> On Sun, Nov 20, 2016 at 10:13:10AM +0200, Laurent Pinchart wrote:
> > On Friday 18 Nov 2016 21:53:12 ville.syrjala at linux.intel.com wrote:
> >> From: Ville Syrjälä
> >>
> >> Allow drivers to return a custom drm_format_info str
On Sun, Nov 20, 2016 at 10:13:10AM +0200, Laurent Pinchart wrote:
> Hi Ville,
>
> Thank you for the patch.
>
> On Friday 18 Nov 2016 21:53:12 ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Allow drivers to return a custom drm_format_info structure for special
> > fb l
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
> ---
> README| 2 +-
> include/drm/README| 2 +-
> inte
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:
> > > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > > r
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161121/5905e967/attachment.html>
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:
> > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > remove, I've added it because I was getting a ->disable() hook call
> > before any
On 21/11/2016 13:27, Ville Syrjälä wrote:
> On Mon, Nov 21, 2016 at 08:42:13AM +, Tvrtko Ursulin wrote:
>>
>> Hi,
>>
>> On 18/11/2016 19:53, ville.syrjala at linux.intel.com wrote:
>>> From: Ville Syrjälä
>>>
>>> By providing our own format information for the CCS formats, we should
>>> b
On Mon, Nov 21, 2016 at 01:50:31PM +, Liviu Dudau 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:
> > > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > > remove, I've a
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:
> > That is mostly due to the check in hdlcd_crtc_disable() which I should
> > remove, I've added it because I was getting a ->disable() hook call
> > before any
On Mon, Nov 21, 2016 at 12:56:53PM +, Liviu Dudau wrote:
> That is mostly due to the check in hdlcd_crtc_disable() which I should
> remove, I've added it because I was getting a ->disable() hook call
> before any ->enable() was called at startup time. I need to revisit
> this as I remember Dani
On Thu, Nov 17, 2016 at 7:26 AM, Brian Starkey wrote:
> On Thu, Nov 17, 2016 at 11:41:29AM +, Liviu Dudau wrote:
>>
>> Cleanup the debugfs entries created by commit 6559c901cb48 when
>> the driver's minor gets un-registered. Without it, DRM drivers
>> compiled as modules cannot be rmmod-ed and
On Mon, Nov 21, 2016 at 08:46:19PM +, Chris Wilson wrote:
> On Mon, Nov 21, 2016 at 11:00:52AM -0800, Manasi Navare wrote:
> > On Mon, Nov 21, 2016 at 04:48:07PM +0100, Daniel Vetter wrote:
> > > On Mon, Nov 21, 2016 at 11:10:45AM +0100, Daniel Vetter wrote:
> > > > On Mon, Nov 21, 2016 at 09:4
On Mon, Nov 21, 2016 at 12:25:56PM +, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 11:32:12AM +, Liviu Dudau wrote:
> > On Mon, Nov 21, 2016 at 11:20:30AM +, Russell King - ARM Linux wrote:
> > > I first noticed it when booting with the buggy I2C EDID reading, so
> > > DRM
From: Gustavo Padovan
Document IN_FENCE_FD and OUT_FENCE_PTR properties.
Signed-off-by: Gustavo Padovan
---
Documentation/gpu/drm-kms.rst | 6 ++
drivers/gpu/drm/drm_atomic.c | 31 +++
2 files changed, 37 insertions(+)
diff --git a/Documentation/gpu/drm-kms.r
The plane base address needs to be calculated using the source
coordinates to position the source correctly - it's possible to have
a larger source buffer than the CRTC size, and have several CRTCs
reading from different parts of the buffer.
In such a case, the pitch may be larger, and we will use
On Mon, Nov 21, 2016 at 11:32:12AM +, Liviu Dudau wrote:
> On Mon, Nov 21, 2016 at 11:20:30AM +, Russell King - ARM Linux wrote:
> > I first noticed it when booting with the buggy I2C EDID reading, so
> > DRM wasn't seeing a valid EDID. Then when Xorg started up and shut
> > down, I notice
On 11/18/16 18:57, Bartosz Golaszewski wrote:
> 2016-11-02 16:57 GMT+01:00 Jyri Sarha :
>> Use unload to handle initialization failures instead of complex goto
>> label mess. To do this the initialization sequence needed slight
>> reordering and some unload functions needed to become conditional.
>
Patches #2 and #3 are Reviewed-by: Christian König
.
The rest is Acked-by: Christian König .
Regards,
Christian.
Am 18.11.2016 um 20:52 schrieb ville.syrjala at linux.intel.com:
> From: Ville Syrjälä
>
> Second installment of my effort to remove the duplicated
> depth/bpp/pixel_format from
Hi Geert,
On Monday 21 Nov 2016 10:23:46 Geert Uytterhoeven wrote:
> On Mon, Nov 21, 2016 at 10:19 AM, Laurent Pinchart wrote:
> > On Monday 21 Nov 2016 09:36:22 Geert Uytterhoeven wrote:
> >> On Sat, Nov 19, 2016 at 4:28 AM, Laurent Pinchart wrote:
> >>> The panel backlight is controlled through
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 me with my ppor
> coccinelle skills later.
>
> In some places the local v
2016-11-21 11:24 GMT+01:00 Jyri Sarha :
> On 11/18/16 18:57, Bartosz Golaszewski wrote:
>> 2016-11-02 16:57 GMT+01:00 Jyri Sarha :
>>> Use unload to handle initialization failures instead of complex goto
>>> label mess. To do this the initialization sequence needed slight
>>> reordering and some un
On Mon, Nov 21, 2016 at 04:00:48PM +0100, Peter Rosin wrote:
> The Sharp 15" LQ150X1LG11 panel is an XGA TFT LCD panel.
>
> Signed-off-by: Peter Rosin
> ---
> .../bindings/display/panel/sharp,lq150x1lg11.txt | 36
> ++
> 1 file changed, 36 insertions(+)
> create mode 1006
On Mon, Nov 21, 2016 at 11:20:30AM +, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 11:06:04AM +, Liviu Dudau wrote:
> > On Fri, Nov 18, 2016 at 11:37:33PM +, Russell King - ARM Linux wrote:
> > > Hi,
> >
> > Hi Russell,
> >
> > >
> > > While testing HDMI with Xorg on the
On Mon, Nov 21, 2016 at 11:06:04AM +, Liviu Dudau wrote:
> On Fri, Nov 18, 2016 at 11:37:33PM +, Russell King - ARM Linux wrote:
> > Hi,
>
> Hi Russell,
>
> >
> > While testing HDMI with Xorg on the Juno board, I find that when Xorg
> > starts up or shuts down, the display is shifted sig
Hi Geert,
On Monday 21 Nov 2016 09:36:22 Geert Uytterhoeven wrote:
> On Sat, Nov 19, 2016 at 4:28 AM, Laurent Pinchart wrote:
> > The panel backlight is controlled through a GPIO and a PWM channel.
> >
> > Signed-off-by: Laurent Pinchart
> >
>
> Reviewed-by: Geert Uytterhoeven
>
> > --- a/arc
On Mon, Nov 21, 2016 at 09:42:57AM +, Chris Wilson wrote:
> On Mon, Nov 21, 2016 at 10:38:20AM +0100, Daniel Vetter wrote:
> > On Fri, Nov 18, 2016 at 09:44:49AM -0800, Manasi Navare wrote:
> > > On Fri, Nov 18, 2016 at 06:21:21PM +0200, Ville Syrjälä wrote:
> > > > On Fri, Nov 18, 2016 at 04
On Sun, Nov 20, 2016 at 10:56:23AM +0100, Jean-Francois Moine wrote:
> This patch adds a HDMI video driver to the Allwinner's SoCs A83T and H3.
>
> Signed-off-by: Jean-Francois Moine
> ---
> .../devicetree/bindings/display/sunxi/hdmi.txt | 53 ++
> drivers/gpu/drm/sun8i/Kconfig
On Fri, Nov 18, 2016 at 11:37:33PM +, Russell King - ARM Linux wrote:
> Hi,
Hi Russell,
>
> While testing HDMI with Xorg on the Juno board, I find that when Xorg
> starts up or shuts down, the display is shifted significantly to the
> right and wrapped in the active region. (No sync bars ar
On Mon, Nov 21, 2016 at 04:48:07PM +0100, Daniel Vetter wrote:
> On Mon, Nov 21, 2016 at 11:10:45AM +0100, Daniel Vetter wrote:
> > On Mon, Nov 21, 2016 at 09:42:57AM +, Chris Wilson wrote:
> > > On Mon, Nov 21, 2016 at 10:38:20AM +0100, Daniel Vetter wrote:
> > > > On Fri, Nov 18, 2016 at 09:4
On Sun, Nov 20, 2016 at 10:53:25AM +0100, Jean-Francois Moine wrote:
> Allwinner's recent SoCs, as A64, A83T and H3, contain a new display
> engine, DE2.
> This patch adds a DRM video driver for this device.
>
> Signed-off-by: Jean-Francois Moine
> ---
> .../bindings/display/sunxi/sun8i-de2.txt
On Mon, Nov 21, 2016 at 12:48:13PM +0900, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Document IN_FENCE_FD and OUT_FENCE_PTR properties.
>
> Signed-off-by: Gustavo Padovan
> ---
> Documentation/gpu/drm-kms.rst | 6 ++
> drivers/gpu/drm/drm_atomic.c | 31 +++
On Sat, Nov 19, 2016 at 05:28:03AM +0200, Laurent Pinchart wrote:
> The AA104XD12 and AA121TD01 are LVDS display panels. Their bindings are
> modelled on the the LVS panel bindings.
s/LVS/LVDS/
>
> Signed-off-by: Laurent Pinchart
> ---
> .../display/panel/mitsubishi,aa104xd12.txt | 47
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 data to LVDS panels. This binding supports display panels
> compatible with
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 comment...
[...]
> +Connectivity
> +
> +
> +- ports: Pane
On Fri, Nov 18, 2016 at 11:37:33PM +, Russell King - ARM Linux wrote:
> Hi,
>
> While testing HDMI with Xorg on the Juno board, I find that when Xorg
> starts up or shuts down, the display is shifted significantly to the
> right and wrapped in the active region. (No sync bars are visible.)
>
On Fri, Nov 18, 2016 at 09:44:49AM -0800, Manasi Navare wrote:
> On Fri, Nov 18, 2016 at 06:21:21PM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 18, 2016 at 04:35:25PM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 18, 2016 at 05:28:54PM +0200, Ville Syrjälä wrote:
> > > > On Fri, Nov 18, 2016 at
1 - 100 of 118 matches
Mail list logo
