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
> -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
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>
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
On 12/05/2016 09:51 PM, Thierry Reding wrote:
> On Thu, Nov 10, 2016 at 08:23:37PM +0200, Mikko Perttunen wrote:
>> This series adds IOMMU support to Host1x and TegraDRM
>> and adds support for the VIC host1x client so that
>> host1x can be tested on modern Tegra platforms.
>> It depends on the pre
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 a NULL pointer
dereference.
Fix this by omitting the drm_debugfs_
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
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
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>
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
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>
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,
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
))
> + 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>
> -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
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>
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>
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>
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
://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
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>
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
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/03e72bed/attachment-0001.html>
On Thu, Dec 01, 2016 at 10:05:59AM +0100, Neil Armstrong wrote:
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Neil Armstrong
> ---
> .../bindings/display/amlogic,meson-vpu.txt | 112
> +
> 1 file changed, 112 insertions(+)
> create mode 100644
> Documentation/de
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 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
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
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>
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:
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 12/02/2016 05:48 AM, Boris Brezillon wrote:
> The VEC IP is a TV DAC, providing support for PAL and NTSC standards.
>
> Signed-off-by: Boris Brezillon
> ---
> diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
> new file mode 100644
> index ..2d4256fcc6f2
>
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>
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
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: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 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
From: Sourab Gupta
In the current scenario, the relay API fit well only with debugfs, due to
availability of parent dentry. Any other existing filesystem was not feasible
for
holding guc logs, due to incompatibility with relay. But this makes the guc_log
file unavailable on the production kerne
From: Sourab Gupta
A driver specific directory is created inside drmfs root, and dentry of
this directory is saved for subsequent use by the driver (e.g. i915).
The driver can then create files/directories inside this root directory
directly.
In case of i915 driver, the top directory is created
From: Sourab Gupta
The drmfs filesystem will not be registered standalone during kernel init time,
instead it is intended to be initialized/registered during drm initialization.
Signed-off-by: Sourab Gupta
Signed-off-by: Swati Dhingra
---
drivers/gpu/drm/drm_drv.c | 6 ++
1 file changed,
From: Sourab Gupta
The patch introduces a new pseudo filesystem type, named 'drmfs' which is
intended to house the files for the data generated by drm subsystem that
cannot be accommodated by any of the existing filesystems.
The filesystem is modelled on the lines of existing pseudo-filesystems s
From: Swati Dhingra
Currently, we don't have a stable ABI which can be used for the purpose of
providing output debug/loggging/crc and other such data from DRM.
The ABI in current use (filesystems, ioctls, et al.) have their own
constraints and are intended to output a particular type of data.
Fe
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
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
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
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
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
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
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
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
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/544f6240/attachment.html>
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 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
Bump
On 10.11.2016 20:23, Mikko Perttunen wrote:
> This series adds IOMMU support to Host1x and TegraDRM
> and adds support for the VIC host1x client so that
> host1x can be tested on modern Tegra platforms.
> It depends on the previous fix series. The whole thing
> (modulo patch order) is availab
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
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 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
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
Hi Thierry,
On 05-12-2016 11:14, Thierry Reding wrote:
> On Mon, Dec 05, 2016 at 11:06:15AM +, Jose Abreu wrote:
>> Hi Thierry,
>>
>>
>> Do you think while you are at it you could implement a
>> set_scrambling() callback? It should be pretty straight forward:
>> you read the SCDC_TMDS_CONFIG
Hi,
On 05-12-2016 13:31, Ville Syrjälä wrote:
> 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 SCD
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
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
|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>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161205/28b599f3/attachment-0001.html>
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
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/
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
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
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
On Tue 29 Nov 01:11 PST 2016, Laurent Pinchart wrote:
> Hi Archit,
>
> (CC'ing Mark Brown)
>
> 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:
> > >> Add the regulator supply prope
On 05/12/16 12:46 PM, Jason Gunthorpe wrote:
> NVMe might have to deal with pci-e hot-unplug, which is a similar
> problem-class to the GPU case..
Sure, but if the NVMe device gets hot-unplugged it means that all the
CMB mappings are useless and need to be torn down. This probably means
killin
On Mon, Dec 05, 2016 at 12:27:20PM -0700, Logan Gunthorpe wrote:
>
>
> On 05/12/16 12:14 PM, Jason Gunthorpe wrote:
> >But CMB sounds much more like the GPU case where there is a
> >specialized allocator handing out the BAR to consumers, so I'm not
> >sure a general purpose chardev makes a lot of
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
Hi Laurent,
On 05-12-2016 11:32, Laurent Pinchart wrote:
> 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 Pincha
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 05/12/16 12:14 PM, Jason Gunthorpe wrote:
> But CMB sounds much more like the GPU case where there is a
> specialized allocator handing out the BAR to consumers, so I'm not
> sure a general purpose chardev makes a lot of sense?
I don't think it will ever need to be as complicated as the GPU c
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>
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>
On Mon, Dec 05, 2016 at 10:48:58AM -0800, Dan Williams wrote:
> 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 thin
> > > 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>
On Mon 05 Dec 11:57 PST 2016, Bjorn Andersson wrote:
[..]
> You should rather add a struct device zap_dev to your adreno context, do
> minimal initialization (name and a parent I think is enough), call
> device_register(&zap_dev);, of_reserved_mem_device_init() and then use
> that for your dma all
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
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
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.
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
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>
On Mon 28 Nov 11:28 PST 2016, Jordan Crouse wrote:
> In order to switch the GPU out of secure mode on most systems we
> need to load a zap shader into memory and get it authenticated
> and into the secure world. All the bits and pieces to do
> the load are scattered throughout the kernel, but we
On Mon 28 Nov 11:28 PST 2016, Jordan Crouse wrote:
> The A5XX GPU powers on in "secure" mode. In secure mode the GPU can
> only render to buffers that are marked as secure and inaccessible
> to the kernel and user through a series of hardware protections. In
> practice secure mode is used to draw
chives/dri-devel/attachments/20161205/80396acc/attachment.html>
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 its bars this way can
> register the memory region with the devi
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
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>
Hi Thierry,
Do you think while you are at it you could implement a
set_scrambling() callback? It should be pretty straight forward:
you read the SCDC_TMDS_CONFIG reg, do a mask, and then write it
again.
I think this is an important feature that we should have.
Best regards,
Jose Miguel Abreu
ubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161205/37dc8bcf/attachment.html>
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 can just mmap
> > /sys/../pci/../resourceX to get a user handle t
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
Hi Laurent,
On 02-12-2016 15:43, Laurent Pinchart wrote:
> Hi Russell,
>
> 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 driver declares a dev_type to distinguish pl
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
..
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 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 wanted to propose we include this as a topic for LFS/MM
> becaus
Hi Thierry,
On 02-12-2016 19:24, Thierry Reding wrote:
> From: Thierry Reding
>
> SCDC is a mechanism defined in the HDMI 2.0 specification that allows
> the source and sink devices to communicate.
>
> This commit introduces helpers to access the SCDC and provides the
> symbolic names for the va
1 - 100 of 129 matches
Mail list logo
