e the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/8f57effb/attachment.html>
..
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/9b21b23d/attachment.sig>
On 12/02/2016 09:33 PM, Sean Paul wrote:
> On Thu, Dec 1, 2016 at 10:54 PM, Archit Taneja
> wrote:
>> Hi,
>>
>> On 12/02/2016 08:02 AM, zain wang wrote:
>>>
>>> We will ignored PSR setting if panel not support it. So, in this case, we
>>> should
>>> return from analogix_dp_enable/disable_psr()
Hi Vladimir,
On Saturday 03 Dec 2016 23:10:35 Vladimir Zapolskiy wrote:
> On 12/03/2016 07:16 PM, Laurent Pinchart wrote:
> > On Friday 25 Nov 2016 13:29:37 Fabio Estevam wrote:
> >> On Fri, Nov 25, 2016 at 1:22 PM, Laurent Pinchart wrote:
> I got the clock name from I.MX6Q TRM, I also checke
On Fri, Dec 02, 2016 at 09:48:59AM -0800, Manasi Navare wrote:
> On Fri, Dec 02, 2016 at 05:26:35PM +0100, Daniel Vetter wrote:
> > On Tue, Nov 29, 2016 at 11:30:31PM -0800, Manasi Navare wrote:
> > > At the time userspace does setcrtc, we've already promised the mode
> > > would work. The promise
They're gone since 8a357d10043c ("drm: Nerf DRM_CONTROL nodes").
Spotted while doing a full audit when revieng a similar patch from
Nicolai for radeon.
Cc: Dave Airlie
Fixes: 8a357d10043c ("drm: Nerf DRM_CONTROL nodes")
Cc: Nicolai Stange
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/qxl/qx
On Sat, Dec 03, 2016 at 03:47:00PM +0100, Nicolai Stange wrote:
> Since commit 8a357d10043c ("drm: Nerf DRM_CONTROL nodes"), a
> struct drm_device's ->control member is always NULL.
>
> In the case of CONFIG_DEBUG_FS=y, radeon_debugfs_add_files() accesses
> ->control->debugfs_root though. This res
They're gone since 8a357d10043c ("drm: Nerf DRM_CONTROL nodes").
Spotted while doing a full audit when revieng a similar patch from
Nicolai for radeon.
v2: Drink coffee first aka don't forget the unregister side.
Cc: Dave Airlie
Fixes: 8a357d10043c ("drm: Nerf DRM_CONTROL nodes")
Cc: Nicolai Sta
y
-- 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/20161205/3a9bd9e7/attachment.sig>
Hi,
here are the patches that remain to be merged in this series. They have
been rebased and I have also addressed two smaller comments:
- Move locking into drm_crtc_add_crc_entry (Daniel Vetter).
- Define intel_crtc_set_crc_source as NULL if !CONFIG_DEBUG_FS (Jani
Nikula).
Thanks,
Tomeu
To
In preparation to using a generic API in the DRM core for continuous CRC
generation, move the related code out of i915_debugfs.c into a new file.
Eventually, only the Intel-specific code will remain in this new file.
v2: Rebased.
v6: Rebased.
v7: Fix whitespace issue.
v9: Have intel_display_cr
The core provides now an ABI to userspace for generation of frame CRCs,
so implement the ->set_crc_source() callback and reuse as much code as
possible with the previous ABI implementation.
When handling the pageflip interrupt, we skip 1 or 2 frames depending on
the HW because they contain wrong v
There's no reason any more for callers of this function to take the lock
themselves, so just move the lock to the function to avoid confusion and
bugs when more callers are contributed.
Signed-off-by: Tomeu Vizoso
---
drivers/gpu/drm/drm_debugfs_crc.c | 9 +++--
1 file changed, 7 insertions
Use drm_accurate_vblank_count so we have the full 32 bit to represent
the frame counter and userspace has a simpler way of knowing when the
counter wraps around.
Signed-off-by: Tomeu Vizoso
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/i915/i915_irq.c | 6 +++---
1 file changed, 3 insertions(+
uiltin, but your justification
sounds like a bit of a lame excuse rather than a good technical reason.
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/20161205/63772752/attachment.sig>
The patch below added regulator supplies to the ADV533 HDMI bridge
on the DB410c, but the corresponding DT binding doc wasn't updated
to list them:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=28546b09551190c727c94d1c5c96ca609065beb2
The first patch adds the regulato
Add the regulator supply properties needed by ADV7511 and ADV7533.
Cc: devicetree at vger.kernel.org
Acked-by: Laurent Pinchart
Signed-off-by: Archit Taneja
---
Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt | 8
1 file changed, 8 insertions(+)
diff --git a/Documenta
Maintain a table of regulator names expect by ADV7511 and ADV7533.
Use regulator_bulk_* api to configure these.
Initialize and enable the regulators during probe itself. Controlling
these dynamically is left for later.
Reviewed-by: Laurent Pinchart
Signed-off-by: Archit Taneja
---
drivers/gpu/
>
> #define HDMI_IEEE_OUI 0x000c03
> +#define HDMI_FORUM_IEEE_OUI 0xc45dd8
> #define HDMI_INFOFRAME_HEADER_SIZE 4
> #define HDMI_AVI_INFOFRAME_SIZE13
> #define HDMI_SPD_INFOFRAME_SIZE25
> --
> 2.10.2
>
-- 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/20161205/77ac536b/attachment.sig>
Am 05.12.2016 um 08:27 schrieb Daniel Vetter:
> On Sat, Dec 03, 2016 at 03:47:00PM +0100, Nicolai Stange wrote:
>> Since commit 8a357d10043c ("drm: Nerf DRM_CONTROL nodes"), a
>> struct drm_device's ->control member is always NULL.
>>
>> In the case of CONFIG_DEBUG_FS=y, radeon_debugfs_add_files()
On Mon, Dec 05, 2016 at 08:42:49AM +0100, Christian König wrote:
> Am 05.12.2016 um 08:27 schrieb Daniel Vetter:
> > On Sat, Dec 03, 2016 at 03:47:00PM +0100, Nicolai Stange wrote:
> > > Since commit 8a357d10043c ("drm: Nerf DRM_CONTROL nodes"), a
> > > struct drm_device's ->control member is alwa
On Thu, Dec 01, 2016 at 09:46:06AM -0500, Alex Deucher wrote:
> On Thu, Dec 1, 2016 at 2:37 AM, Michel Dänzer wrote:
> > From: Michel Dänzer
> >
> > This is an attempt to make the previous fix a bit more robust going
> > forward.
> >
> > v2:
> > * Only allow DRM_CAP_TIMESTAMP_MONOTONIC with UMS
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/2a47813c/attachment.html>
On Mon, Dec 05, 2016 at 08:57:43AM +0100, Thierry Reding wrote:
> On Sat, Dec 03, 2016 at 04:35:24AM +, Sharma, Shashank wrote:
> > Hi Thierry,
> >
> > If you can please have a look on this patch, I had written one to parse
> > HF-VSDB, which was covering SCDC detection too.
> > https://pat
Hi,
On 05-12-16 08:46, Thierry Reding wrote:
> On Fri, Dec 02, 2016 at 11:17:35AM +0100, Hans de Goede wrote:
>> The primary consumer of the lpss pwm is the i915 kms driver, but
>> currently that driver cannot get the pwm because i915 platforms are
>> not using devicetree and pwm-lpss does not cal
Am 05.12.2016 um 09:39 schrieb Nicolai Stange:
> Christian König writes:
>
>> Am 05.12.2016 um 08:27 schrieb Daniel Vetter:
>>> On Sat, Dec 03, 2016 at 03:47:00PM +0100, Nicolai Stange wrote:
Since commit 8a357d10043c ("drm: Nerf DRM_CONTROL nodes"), a
struct drm_device's ->control memb
On 05/12/16 05:48 PM, Christian König wrote:
> Am 05.12.2016 um 09:39 schrieb Nicolai Stange:>>
>> I'll send compile-only tested patches either tonight or tomorrow. Shall
>> they cover the oopses only or the dead code as well?
>
> Please start with the ops, cause we certainly will get complains a
On 03/12/16 01:32 AM, Emil Velikov wrote:
> From: Emil Velikov
>
> Pass along DRM_DEVICE_GET_PCI_REVISION only when the individual nodes
> are opened and update the printed messages accordingly.
>
> v2: Attribute for the flag rename, call drmGetDevices2 w/o the flag.
>
> Signed-off-by: Emil Vel
e assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/e400a384/attachment.html>
On Mon, Dec 05, 2016 at 09:48:02AM +0100, Christian König wrote:
> Am 05.12.2016 um 09:39 schrieb Nicolai Stange:
> > Christian König writes:
> >
> > > Am 05.12.2016 um 08:27 schrieb Daniel Vetter:
> > > > On Sat, Dec 03, 2016 at 03:47:00PM +0100, Nicolai Stange wrote:
> > > > > Since commit 8a
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/20161205/b4e59d06/attachment.html>
wn words
that's exactly what the PWM is used for. Obfuscating this by turning the
name into something unrecognizable such as pwm_lpss0 isn't going to
change any of the above.
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/20161205/fe3da6c5/attachment.sig>
Hi Jyri,
I pulled your recent tilcdc pull request on top of v4.9 and Sekhar's
davinci branch (+ vga dac DT)[1].
I'm getting "vblank wait timed out" errors when running simple modetest[2].
This error happened before with the drm_bridge series[3], but went
away at one of the subsequent patch versi
Hi Dave,
this tag fixes a regression in the imx-drm YUV plane support [1] that
was introduced in v4.9-rc4, as well as an error returned when changing
U/V offsets of an active plane to otherwise valid values.
[1] https://lkml.org/lkml/2016/11/17/133
Both commits are already contained in drm-next.
ubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/37dc8bcf/attachment.html>
> > > drm_detect_hdmi_monitor(struct edid *edid);
> > > +bool drm_detect_hdmi_scdc(struct edid *edid);
> > > bool drm_detect_monitor_audio(struct edid *edid); bool
> > > drm_rgb_quant_range_selectable(struct edid *edid); int
> > > drm_add_modes_noedid(struct drm_connector *connector, diff --git
> > > a/include/linux/hdmi.h b/include/linux/hdmi.h index
> > > edbb4fc674ed..d271ff23984f 100644
> > > --- a/include/linux/hdmi.h
> > > +++ b/include/linux/hdmi.h
> > > @@ -35,6 +35,7 @@ enum hdmi_infoframe_type { };
> > >
> > > #define HDMI_IEEE_OUI 0x000c03
> > > +#define HDMI_FORUM_IEEE_OUI 0xc45dd8
> > > #define HDMI_INFOFRAME_HEADER_SIZE 4
> > > #define HDMI_AVI_INFOFRAME_SIZE13
> > > #define HDMI_SPD_INFOFRAME_SIZE25
> > > --
> > > 2.10.2
> > >
>
>
>
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
-- 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/20161205/0e84bba0/attachment-0001.sig>
ruct drm_display_mode
> > *to_match);
> > enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code);
> > bool drm_detect_hdmi_monitor(struct edid *edid);
> > bool drm_detect_hdmi_scdc(struct edid *edid);
> > +bool drm_detect_hdmi_scdc_rr_capable(struct edid *edid);
> > bool drm_detect_monitor_audio(struct edid *edid);
> > bool drm_rgb_quant_range_selectable(struct edid *edid);
> > int drm_add_modes_noedid(struct drm_connector *connector,
>
-- 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/20161205/fc80b324/attachment.sig>
eration. It looks as if the
above should work, but it's probably best to test it a little more
widely to make sure we're not running into cases where it breaks.
Have you by any chance verified that it works on your hardware?
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/20161205/25f08c7f/attachment.sig>
l, but this seems extreme.
--
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/20161205/959ee195/attachment.html>
Forgot to send to dri-devel when I first sent this out...
The few times I've looked at using DRM_DEBUG messages, I haven't found
them very helpful considering how noisy some of the categories are. More
than once now I've preferred to go in and modify individual files to
affect what messages I see
Hi Jose,
On Monday 05 Dec 2016 10:50:19 Jose Abreu wrote:
> On 02-12-2016 15:43, Laurent Pinchart wrote:
> > On Friday 02 Dec 2016 14:24:01 Russell King - ARM Linux wrote:
> >> On Fri, Dec 02, 2016 at 01:43:28AM +0200, Laurent Pinchart wrote:
> >>> From: Kieran Bingham
> >>>
> >>> The dw-hdmi dr
chives/dri-devel/attachments/20161205/80396acc/attachment.html>
Hello,
On Friday 02 Dec 2016 18:45:46 Laurent Pinchart wrote:
> On Friday 02 Dec 2016 16:08:17 Russell King - ARM Linux wrote:
> > On Fri, Dec 02, 2016 at 05:43:43PM +0200, Laurent Pinchart wrote:
> >> DW_HDMI_QUIRK_FC_INVIDCONF is indeed a bad name, I'll fix that.
> >>
> >> Do you know why this
The drm_atomic_helper_connector_dpms
will set the connector back the old DPMS state
before returning. This makes it impossible to change
DPMS state of the connector.
Fixes: 0853695c3ba46f97dfc0b5885f7b7e640ca212dd
v2: edit of commit message
Cc: Chris Wilson
Cc: Daniel Vetter
Cc: Eric Engestrom
Hi CK,
On Wed, 2016-11-30 at 15:58 +0800, CK Hu wrote:
> Hi, YT:
>
> some comments inline.
>
> On Fri, 2016-11-25 at 18:34 +0800, YT Shen wrote:
> > This patch update enable/disable flow of DSI module.
> > Original flow works on there is a bridge chip: DSI -> bridge -> panel.
> > In this case: D
Hi Jose,
On Monday 05 Dec 2016 12:31:30 Jose Abreu wrote:
> On 05-12-2016 11:32, Laurent Pinchart wrote:
> > On Monday 05 Dec 2016 10:50:19 Jose Abreu wrote:
> >> On 02-12-2016 15:43, Laurent Pinchart wrote:
> >>> On Friday 02 Dec 2016 14:24:01 Russell King - ARM Linux wrote:
> On Fri, Dec 02
what is the display_in supposed to present?
It's the first node in the "display chain", so it has no input.
Also, don't touch da850.dtsi here, just add the "ports" node in the
da850-lcdk.dts file.
If the da850.dtsi has not been merged yet, I'd change the name of the
lcdc node to something else than "display". It's rather vague. If it's
named "lcdc", reading da850-lcdk.dts becomes much easier, as you'll
refer to "lcdc".
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/8a7836a6/attachment-0001.sig>
Hi Daniel,
On Wed, 2016-11-30 at 14:42 +0800, Daniel Kurtz wrote:
> Hi YT,
>
>
> On Fri, Nov 25, 2016 at 6:34 PM, YT Shen wrote:
> >
> > There are some hardware settings changed, between MT8173 & MT2701:
> > DISP_OVL address offset changed, color format definition changed.
> > DISP_RDMA fifo si
On Wed, 2016-11-30 at 15:03 +0100, Matthias Brugger wrote:
>
> On 25/11/16 11:34, YT Shen wrote:
>
> > static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
> > + { .compatible = "mediatek,mt2701-disp-rdma",
> > + .data = &mt2701_rdma_driver_data},
> > { .compatible = "m
Hi,
On 05-12-16 11:59, Thierry Reding wrote:
> On Mon, Dec 05, 2016 at 09:18:03AM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 05-12-16 08:46, Thierry Reding wrote:
>>> On Fri, Dec 02, 2016 at 11:17:35AM +0100, Hans de Goede wrote:
The primary consumer of the lpss pwm is the i915 kms driver, b
On Mon, Dec 05, 2016 at 12:16:52PM +0100, Thierry Reding wrote:
> On Mon, Dec 05, 2016 at 10:12:39AM +, Jose Abreu wrote:
> > On 02-12-2016 19:24, Thierry Reding wrote:
> [...]
> > > +/**
> > > + * drm_scdc_write - write a block of data to SCDC
> > > + * @adapter: I2C controller
> > > + * @offs
On Mon, Dec 05, 2016 at 12:11:46PM +0100, Thierry Reding wrote:
> On Mon, Dec 05, 2016 at 09:16:27AM +0100, Daniel Vetter wrote:
> > On Mon, Dec 05, 2016 at 08:57:43AM +0100, Thierry Reding wrote:
> > > On Sat, Dec 03, 2016 at 04:35:24AM +, Sharma, Shashank wrote:
> > > > Hi Thierry,
> > > >
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161205/28b599f3/attachment-0001.html>
|RESOLVED
--
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/20161205/d25b20e1/attachment.html>
From: Gustavo Padovan
We now support nonblocking commits on drm_atomic_helper_commit()
so the comment is not valid anymore.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/drm_atomic_helper.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/driver
On Tue, Nov 29, 2016 at 5:57 AM, Bartosz Golaszewski
wrote:
> Add the dumb-vga-dac node to the board DT together with corresponding
> ports and vga connector. This allows to retrieve the edid info from
> the display automatically.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> arch/arm/boot/dts/
These patches fix HQVDP plane performance issues
- [PATCH 1/2] drm/sti: load XP70 firmware only once
- [PATCH 2/2] drm/sti: do not post HQVDP command if no update
Fabien
When a plane is enabled, after having been disabled, do not reload XP70
firmware again, but only register VTG again
Signed-off-by: Fabien Dessenne
---
drivers/gpu/drm/sti/sti_hqvdp.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/dri
Do not process update requests with unmodified parameters.
Since the HQVDP command queue is limited to 2, we shall take care of
not posting unneeded commands, which would abusively fill the command
queue leading to frame update skip.
This typically happens when the driver is called with legacy
(no
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/544f6240/attachment.html>
On Mon, Dec 05, 2016 at 02:04:08PM +0200, Marta Lofstedt wrote:
> The drm_atomic_helper_connector_dpms
> will set the connector back the old DPMS state
> before returning. This makes it impossible to change
> DPMS state of the connector.
>
> Fixes: 0853695c3ba46f97dfc0b5885f7b7e640ca212dd
> v2: ed
On Mon, Dec 05, 2016 at 12:11:46PM +0100, Thierry Reding wrote:
> On Mon, Dec 05, 2016 at 09:16:27AM +0100, Daniel Vetter wrote:
> > On Mon, Dec 05, 2016 at 08:57:43AM +0100, Thierry Reding wrote:
> > > On Sat, Dec 03, 2016 at 04:35:24AM +, Sharma, Shashank wrote:
> > > > Hi Thierry,
> > > >
On Mon, Dec 05, 2016 at 11:24:44AM +, Robert Bragg wrote:
> Forgot to send to dri-devel when I first sent this out...
>
> The few times I've looked at using DRM_DEBUG messages, I haven't found
> them very helpful considering how noisy some of the categories are. More
> than once now I've prefe
On Mon, Dec 05, 2016 at 12:03:46PM -0200, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> We now support nonblocking commits on drm_atomic_helper_commit()
> so the comment is not valid anymore.
>
> Signed-off-by: Gustavo Padovan
Oops. Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm
add one.
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/20161205/0dae8e12/attachment.sig>
ex 38eabf6..5df8b9c 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -212,6 +212,11 @@ struct detailed_timing {
> #define DRM_EDID_HDMI_DC_30 (1 << 4)
> #define DRM_EDID_HDMI_DC_Y444 (1 << 3)
>
> +/* YUV 420 deep color modes */
> +#define DRM_EDID_YUV420_DC_48 (1 << 6)
> +#define DRM_EDID_YUV420_DC_36 (1 << 5)
> +#define DRM_EDID_YUV420_DC_30 (1 << 5)
36- and 30-bit depths have the same value. That probably wasn't
intended.
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/20161205/4d0149c1/attachment.sig>
2016-12-05 12:01 GMT+01:00 Bartosz Golaszewski :
> Hi Jyri,
>
> I pulled your recent tilcdc pull request on top of v4.9 and Sekhar's
> davinci branch (+ vga dac DT)[1].
>
> I'm getting "vblank wait timed out" errors when running simple modetest[2].
>
> This error happened before with the drm_bridge
On Mon, Dec 05, 2016 at 05:21:24PM +0100, Daniel Vetter wrote:
> On Mon, Dec 05, 2016 at 12:11:46PM +0100, Thierry Reding wrote:
> > On Mon, Dec 05, 2016 at 09:16:27AM +0100, Daniel Vetter wrote:
> > > On Mon, Dec 05, 2016 at 08:57:43AM +0100, Thierry Reding wrote:
> > > > On Sat, Dec 03, 2016 at 0
On Sun, Dec 4, 2016 at 10:13 PM, Archit Taneja
wrote:
>
>
> On 12/02/2016 09:33 PM, Sean Paul wrote:
>>
>> On Thu, Dec 1, 2016 at 10:54 PM, Archit Taneja
>> wrote:
>>>
>>> Hi,
>>>
>>> On 12/02/2016 08:02 AM, zain wang wrote:
We will ignored PSR setting if panel not support it. So,
On Mon, Dec 5, 2016 at 9:18 AM, Jason Gunthorpe
wrote:
> On Sun, Dec 04, 2016 at 07:23:00AM -0600, Stephen Bates wrote:
>> Hi All
>>
>> This has been a great thread (thanks to Alex for kicking it off) and I
>> wanted to jump in and maybe try and put some summary around the
>> discussion. I also wa
On 1 December 2016 at 04:18, Jonathan Gray wrote:
> DRI devices on OpenBSD are not in their own directory. They reside in
> /dev with a large number of statically generated /dev nodes.
>
> Avoid stat'ing all of /dev on OpenBSD by implementing this custom path.
>
> v2:
>- use drmGetMinorType t
On Mon, Dec 5, 2016 at 10:02 AM, Jason Gunthorpe
wrote:
> On Mon, Dec 05, 2016 at 09:40:38AM -0800, Dan Williams wrote:
>
>> > If it is kernel only with physical addresess we don't need a uAPI for
>> > it, so I'm not sure #1 is at all related to iopmem.
>> >
>> > Most people who want #1 probably c
On Sat, Dec 3, 2016 at 10:11 AM, Pan Bian wrote:
> In function qxl_release_alloc(), when kmalloc() returns a NULL pointer,
> it returns value 0 and parameter *ret is uninitialized. 0 means no error
> to the callers of qxl_release_alloc(). The callers keep going and will
> try to reference the unin
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/03e72bed/attachment-0001.html>
ddress physical memory
> + * directly.
> + */
> + *iova = virt_to_phys(virt);
> + return virt;
> + }
> +
> + shift = iova_shift(&tegra->iova);
> + alloc = alloc_iova(&tegra->iova, size >> shift,
> +tegra->domain->geometry.aperture_end >> shift, true);
This is fairly cumbersome to use. Maybe a drm_mm would be easier in this
case? If not, could we at least store the upper limit of the carveout so
that we don't have to use the really long expression above?
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/20161205/090b6341/attachment.sig>
ierry
-- 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/20161205/ebea832e/attachment.sig>
On Mon, Dec 5, 2016 at 10:39 AM, Logan Gunthorpe wrote:
> On 05/12/16 11:08 AM, Dan Williams wrote:
>>
>> I've already recommended that iopmem not be a block device and instead
>> be a device-dax instance. I also don't think it should claim the PCI
>> ID, rather the driver that wants to map one of
On Fri, Dec 02, 2016 at 03:29:04PM +0100, Hans de Goede wrote:
> On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading
> i915 at boot 1 out of every 3 boots, resulting in a non functional LCD.
> Once the i915 driver has successfully loaded, the panel can be disabled /
> enabled
://packages.debian.org/sid/dosbox
https://packages.debian.org/sid/rtcw
--
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/20161
IMEM_SCRUBBING (1 << 2)
> +
> +#define FALCON_DMATRFBASE0x1110
> +
> +#define FALCON_DMATRFMOFFS 0x00001114
> +
> +#define FALCON_DMATRFCMD 0x1118
> +#define FALCON_DMATRFCMD_IDLE(1 << 1)
> +#define FALCON_DMATRFCMD_IMEM(1 << 4)
> +#define FALCON_DMATRFCMD_SIZE_256B (6 << 8)
> +
> +#define FALCON_DMATRFFBOFFS 0x111c
> +
> +struct falcon_firmware_bin_header_v1 {
> + u32 bin_magic; /* 0x10de */
> + u32 bin_ver;/* cya, versioning of bin format (1) */
Not sure everyone understands what cya means, here. Perhaps just drop
it?
> + u32 bin_size; /* entire image size including this header */
> + u32 os_bin_header_offset;
> + u32 os_bin_data_offset;
> + u32 os_bin_size;
> +};
> +
> +struct falcon_firmware_os_app_v1 {
> + u32 offset;
> + u32 size;
> +};
> +
> +struct falcon_firmware_os_header_v1 {
> + u32 os_code_offset;
> + u32 os_code_size;
> + u32 os_data_offset;
> + u32 os_data_size;
> + u32 num_apps;
> + struct falcon_firmware_os_app_v1 *app_code;
> + struct falcon_firmware_os_app_v1 *app_data;
The above two seem to be completel unused. Should we drop them?
> + u32 *os_ovl_offset;
> + u32 *os_ovl_size;
> +};
Can we in general sanitize the names of these a little? It's redundent
to add a os_ prefix in a structure that contains an _os_ infix.
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/20161205/30b6599a/attachment.sig>
Tahvanainen ---
Closing resolved+Fixed. Verified by Reporter.
--
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/20161205/67d73
))
> + return PTR_ERR(vic->regs);
> +
> + vic->clk = devm_clk_get(dev, NULL);
> + if (IS_ERR(vic->clk)) {
> + dev_err(&pdev->dev, "failed to get clock\n");
> + return PTR_ERR(vic->clk);
> + }
> +
> + platform_set_drvdata(pdev, vic);
> +
> + INIT_LIST_HEAD(&vic->client.base.list);
> + vic->client.base.ops = &vic_client_ops;
> + vic->client.base.dev = dev;
> + vic->client.base.class = HOST1X_CLASS_VIC;
> + vic->client.base.syncpts = syncpts;
> + vic->client.base.num_syncpts = 1;
> + vic->dev = dev;
> + vic->config = vic_config;
> +
> + INIT_LIST_HEAD(&vic->client.list);
> + vic->client.ops = &vic_ops;
> +
> + err = host1x_client_register(&vic->client.base);
> + if (err < 0) {
> + dev_err(dev, "failed to register host1x client: %d\n", err);
> + platform_set_drvdata(pdev, NULL);
> + return err;
> + }
> +
> + pm_runtime_enable(&pdev->dev);
> + if (!pm_runtime_enabled(&pdev->dev)) {
> + err = vic_runtime_resume(&pdev->dev);
> + if (err < 0)
> + goto unregister_client;
> + }
That's a slightly ugly construct, but I can't think of an easy way to
get rid of it (other than to depend on PM, which actually might be the
right thing to do here, it's already selected by ARCH_TEGRA on 64-bit
ARM). I can't think of a scenario where we'd want to run without runtime
PM.
> +
> + dev_info(&pdev->dev, "initialized");
Again, no need for this.
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/20161205/f141df14/attachment-0001.sig>
Hi,
On 05-12-16 19:52, Ville Syrjälä wrote:
> On Fri, Dec 02, 2016 at 03:29:04PM +0100, Hans de Goede wrote:
>> On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading
>> i915 at boot 1 out of every 3 boots, resulting in a non functional LCD.
>> Once the i915 driver has succes
t; + struct iova *alloc;
> + unsigned long shift;
> + int j;
There should be no blank line between blocks of variable declarations.
Also, make j an unsigned int.
> +
> g->bo = host1x_bo_get(g->bo);
> - if (!g->bo)
> + if (!g->bo) {
> + err = -EINVAL;
> goto unpin;
> + }
>
> phys_addr = host1x_bo_pin(g->bo, &sgt);
> - if (!phys_addr)
> + if (!phys_addr) {
> + err = -EINVAL;
> goto unpin;
> + }
> +
> + if (!IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL) && host->domain) {
> + for_each_sg(sgt->sgl, sg, sgt->nents, j) {
> + gather_size += sg->length;
> + }
No need for curly brackets here.
> + gather_size = iova_align(&host->iova, gather_size);
> +
> + shift = iova_shift(&host->iova);
> + alloc = alloc_iova(
> + &host->iova, gather_size >> shift,
> + host->domain->geometry.aperture_end >> shift,
> + true);
This could be made a little more compact as well.
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/20161205/59910d4a/attachment.sig>
s for Tegra124 we should also have a userspace test program to
exercise it.
Thanks,
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/20161205/aef4b768/attachment.sig>
On Mon, Dec 05, 2016 at 12:46:14PM -0700, Jason Gunthorpe wrote:
> In any event the allocator still needs to track which regions are in
> use and be able to hook 'free' from userspace. That does suggest it
> should be integrated into the nvme driver and not a bolt on driver..
Two totally different
Since commit 8a357d10043c ("drm: Nerf DRM_CONTROL nodes"), a
struct drm_device's ->control member is always NULL.
In the case of CONFIG_DEBUG_FS=y, amdgpu_debugfs_add_files() accesses
->control->debugfs_root though. This results in the following Oops:
[9.627636] BUG: unable to handle kernel N
On Fri, Dec 02, 2016 at 05:26:35PM +0100, Daniel Vetter wrote:
> On Tue, Nov 29, 2016 at 11:30:31PM -0800, Manasi Navare wrote:
> > At the time userspace does setcrtc, we've already promised the mode
> > would work. The promise is based on the theoretical capabilities of
> > the link, but it's poss
> -Original Message-
> From: Nicolai Stange [mailto:nicstange at gmail.com]
> Sent: Monday, December 05, 2016 3:30 PM
> To: Daniel Vetter
> Cc: Deucher, Alexander; Koenig, Christian; Michel Dänzer; linux-
> kernel at vger.kernel.org; dri-devel at lists.freedesktop.org; Nicolai Stange
> Sub
Hi Bjorn,
On Monday 05 Dec 2016 13:11:51 Bjorn Andersson wrote:
> On Tue 29 Nov 01:11 PST 2016, Laurent Pinchart wrote:
> > On Tuesday 29 Nov 2016 13:41:33 Archit Taneja wrote:
> >> On 11/29/2016 12:03 PM, Laurent Pinchart wrote:
> >>> On Tuesday 29 Nov 2016 11:37:41 Archit Taneja wrote:
> Ad
files as opposed to symlinks. The latter can cause issues in
many scenarios. Thanks
--
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/attach
own will be appreciated.
--
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/20161205/94170e17/attachment.html>
Following appears with kernel 4.4.36 .
Maybe as a result of following patch ?
drm/radeon: Ensure vblank interrupt is enabled on DPMS transition to on
[5.331666] Can't enable IRQ/MSI because no handler is installed
[5.331842] [ cut here ]
[5.331847] WARNING:
> -Original Message-
> From: Julian Margetson [mailto:runaway at candw.ms]
> Sent: Monday, December 05, 2016 4:59 PM
> To: Maling list - DRI developers
> Cc: Deucher, Alexander; Daenzer, Michel; daniel.vetter at ffwll.ch
> Subject: [Powerpc] Sam460ex Canyonlands issue -Kernel 4.4.36
>
> Fo
4] ret_from_kernel_thread+0x5c/0x64
>> [5.332230] Instruction dump:
>> [5.332241] 7c0803a6 4bb7c1ec 9421ffa0 7c0802a6 bdc10018 90010064
>> 894313d0 2f8a
>> [5.332251] 40be001c 3c60c0c7 38631c16 483ea6c5 <0fe0> 3860ffea
>> 480009ac 89431aa8
>> [5.332274] ---[ end trace 3fbb08226210324a ]---
>> [5.413526] Console: switching to colour frame buffer device 240x67
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/b58b1493/attachment.html>
Sink's capabilities are advertised through DPCD registers and get
updated only on hotplug. So they should be computed only once in the
long pulse handler and saved off in intel_dp structure for the use
later. For this reason two new fields max_sink_lane_count and
max_sink_link_bw are added to intel
If link training fails, then we need to fallback to lower
link rate first and if link training fails at RBR, then
fallback to lower lane count.
This function finds the next lower link rate/lane count
value after link training failure and limits the max
link_rate and lane_count values to these fallb
This patch series is a final revision of previous patch series for handling
link training failure. This has been polished in terms of the kernel
documentation
based on review feedback.
One more patch is added to move sink's max link rate and lane count
to intel_dp and compute it at hotplug and on
If link training at a link rate optimal for a particular
mode fails during modeset's atomic commit phase, then we
let the modeset complete and then retry. We save the link rate
value at which link training failed, update the link status property
to "BAD" and use a lower link rate to prune the modes
At the time userspace does setcrtc, we've already promised the mode
would work. The promise is based on the theoretical capabilities of
the link, but it's possible we can't reach this in practice. The DP
spec describes how the link should be reduced, but we can't reduce
the link below the requireme
1 - 100 of 129 matches
Mail list logo
