[git pull] drm for v4.8
On Mon, Aug 1, 2016 at 9:32 PM, Dave Airlie wrote: > > This is the main drm pull request for 4.8, I'm down with a cold at the moment > so hopefully this isn't in too bad a state, I finished pulling stuff last > week mostly (nouveau fixes just went in today), so only this message should > be influenced by illness. Apologies to anyone who's major feature I missed :-) > > i915: > BXT support enabled by default > GVT-g infrastructure > GuC command submission and fixes > BXT workarounds > SKL/BKL workarounds > Demidlayering device registration > Thundering herd fixes > Missing pci ids > Atomic updates Hmm. I did the merge and pushed it out, but testing it on my laptop shows some very annoying flickering problem. The screen goes dark for a very short while (one frame? Who knows? Seems longer occasionally). I have no idea what triggers it, but it happens quite a lot when it happens. Like once every second or two. And it seems to happen most of the time, although right now it happens to be behaving nicely, so sometimes it goes for a while without the flickering. Things *work*, but the flickering is nasty enough to make the end result painful to use. The only thing I see in dmesg that looks bad is [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe A [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun but I've seen that before, and it happens a couple of times during boot. Not once per second. This is my old Vaio 11 Pro, now running Fedora 24 (up-to-date as of today). So it's bog-standard intel graphics (i5-4200U - Haswell ULT). Suggestions to try? Linus
Why drm-mipi-dsi is built-in only?
On 08/01/2016 03:59 PM, Jani Nikula wrote: > Cc Andrzej, Thierry > > On Fri, 22 Jul 2016, Daniel Vetter wrote: >> On Fri, Jul 22, 2016 at 04:30:24PM +0200, Takashi Iwai wrote: >>> Hi, >>> >>> is there any reason drm-mipi-dsi can't be a module? It's fixed as a >>> built-in since its Kconfig is bool. >> Probably none except embedded folks eshew modules ;-) Submit patch, I'll >> apply. > Possibly this? > > postcore_initcall(mipi_dsi_bus_init); If I remember correctly, the only reason for this is to have mipi_dsi bus registered before mipi_dsi drivers, which usually are registered at module initcall. But maybe bus registration can be performed at first mipi_dsi driver registration. This way we could modularize it. Regards Andrzej > > > BR, > Jani. >
[PATCH v4 5/7] PM / devfreq: event: support rockchip dfi controller
Hi Lin,
On 2016ë
08ì 01ì¼ 17:27, hl wrote:
> Hi Chanwoo Choi,
>
> On 2016å¹´08æ01æ¥ 16:08, Chanwoo Choi wrote:
>> Hi Lin,
>>
>> I add the one minor comment for full name of 'DRI'.
>>
>> On 2016ë
08ì 01ì¼ 16:41, Chanwoo Choi wrote:
>>> Hi Lin,
>>>
>>> Because you remove the 'RFC' prefix on patch title,
>>> I think that you better to make the documentation as following:
>>> - Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
>>>
>>> Regards,
>>> Chanwoo Choi
>>>
>>> On 2016ë
07ì 29ì¼ 16:56, Lin Huang wrote:
on rk3399 platform, there is dfi conroller can monitor
ddr load, base on this result, we can do ddr freqency
scaling.
Signed-off-by: Lin Huang
Acked-by: Chanwoo Choi
---
Changes in v4:
- None
Changes in v3:
- None
Changes in v2:
- use clk_disable_unprepare and clk_enable_prepare
- remove clk_enable_prepare in probe
- remove rockchip_dfi_remove function
Changes in v1:
- None
drivers/devfreq/event/Kconfig| 7 +
drivers/devfreq/event/Makefile | 1 +
drivers/devfreq/event/rockchip-dfi.c | 253
+++
3 files changed, 261 insertions(+)
create mode 100644 drivers/devfreq/event/rockchip-dfi.c
diff --git a/drivers/devfreq/event/Kconfig b/drivers/devfreq/event/Kconfig
index a11720a..ff9279f 100644
--- a/drivers/devfreq/event/Kconfig
+++ b/drivers/devfreq/event/Kconfig
@@ -22,4 +22,11 @@ config DEVFREQ_EVENT_EXYNOS_PPMU
(Platform Performance Monitoring Unit) counters to estimate the
utilization of each module.
+config DEVFREQ_EVENT_ROCKCHIP_DFI
+tristate "ROCKCHIP DFI DEVFREQ event Driver"
+depends on ARCH_ROCKCHIP
+help
+ This add the devfreq-event driver for Rockchip SoC. It provides DFI
+ (DDR Monitor Module) driver to count ddr load.
>> The DFI is "DDR Monitor Module" full name? I need the correct abbreviation
>> and full name.
> We just call this module DFI in datasheet, and this module function is ddr
> monitor module,
> yes, it is do not fit the full name, but i think it is better follow the
> datasheet name.
Are there any full name of DFI? If the people who don't know the detailed
history about
this workd (DFI), it causes the confusion and they don't understand it.
I think that if you want to use the DFI work, you need to add the more detailed
description
why DFI word is used.
>>
+
endif # PM_DEVFREQ_EVENT
diff --git a/drivers/devfreq/event/Makefile
b/drivers/devfreq/event/Makefile
index be146ea..e3f88fc 100644
--- a/drivers/devfreq/event/Makefile
+++ b/drivers/devfreq/event/Makefile
@@ -1,2 +1,3 @@
# Exynos DEVFREQ Event Drivers
obj-$(CONFIG_DEVFREQ_EVENT_EXYNOS_PPMU) += exynos-ppmu.o
+obj-$(CONFIG_DEVFREQ_EVENT_ROCKCHIP_DFI) += rockchip-dfi.o
diff --git a/drivers/devfreq/event/rockchip-dfi.c
b/drivers/devfreq/event/rockchip-dfi.c
new file mode 100644
index 000..96a0307
--- /dev/null
+++ b/drivers/devfreq/event/rockchip-dfi.c
@@ -0,0 +1,253 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
+ * Author: Lin Huang
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
for
+ * more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define RK3399_DMC_NUM_CH2
+
+/* DDRMON_CTRL */
+#define DDRMON_CTRL0x04
+#define CLR_DDRMON_CTRL(0x1f << 0)
+#define LPDDR4_EN(0x10001 << 4)
+#define HARDWARE_EN(0x10001 << 3)
+#define LPDDR3_EN(0x10001 << 2)
+#define SOFTWARE_EN(0x10001 << 1)
+#define TIME_CNT_EN(0x10001 << 0)
[snip]
+};
+module_platform_driver(rockchip_dfi_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Lin Huang ");
+MODULE_DESCRIPTION("Rockchip dfi driver");
>> s/dfi -> DFI
You should use the capital letter.
Regards,
Chanwoo Choi
[PATCH v4 6/7] PM / devfreq: rockchip: add devfreq driver for rk3399 dmc
Hi Lin,
As I mentioned on patch5, you better to make the documentation as following:
- Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
And, I add the comments.
On 2016ë
07ì 29ì¼ 16:57, Lin Huang wrote:
> base on dfi result, we do ddr frequency scaling, register
> dmc driver to devfreq framework, and use simple-ondemand
> policy.
>
> Signed-off-by: Lin Huang
> ---
> Changes in v4:
> - use arm_smccc_smc() function talk to bl31
> - delete rockchip_dmc.c file and config
> - delete dmc_notify
> - adjust probe order
>
> Changes in v3:
> - operate dram setting through sip call
> - imporve set rate flow
>
> Changes in v2:
> - None
>
> Changes in v1:
> - move dfi controller to event
> - fix set voltage sequence when set rate fail
> - change Kconfig type from tristate to bool
> - move unuse EXPORT_SYMBOL_GPL()
>
> drivers/devfreq/Kconfig | 1 +
> drivers/devfreq/Makefile | 1 +
> drivers/devfreq/rockchip/Kconfig | 8 +
> drivers/devfreq/rockchip/Makefile | 1 +
> drivers/devfreq/rockchip/rk3399_dmc.c | 473
> ++
> 5 files changed, 484 insertions(+)
> create mode 100644 drivers/devfreq/rockchip/Kconfig
> create mode 100644 drivers/devfreq/rockchip/Makefile
> create mode 100644 drivers/devfreq/rockchip/rk3399_dmc.c
>
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index 64281bb..acb2a57 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -99,5 +99,6 @@ config ARM_TEGRA_DEVFREQ
> operating frequencies and voltages with OPP support.
>
> source "drivers/devfreq/event/Kconfig"
> +source "drivers/devfreq/rockchip/Kconfig"
This patch include the only one patch. So, I think that
you don't need to create the 'rockchip' directory.
>
> endif # PM_DEVFREQ
> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
> index 5134f9e..d844e23 100644
> --- a/drivers/devfreq/Makefile
> +++ b/drivers/devfreq/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_DEVFREQ_GOV_USERSPACE) += governor_userspace.o
> obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ)+= exynos/
> obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ)+= exynos/
> obj-$(CONFIG_ARM_TEGRA_DEVFREQ) += tegra-devfreq.o
> +obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
ditto.
>
> # DEVFREQ Event Drivers
> obj-$(CONFIG_PM_DEVFREQ_EVENT) += event/
> diff --git a/drivers/devfreq/rockchip/Kconfig
> b/drivers/devfreq/rockchip/Kconfig
> new file mode 100644
> index 000..d8f9e66
> --- /dev/null
> +++ b/drivers/devfreq/rockchip/Kconfig
> @@ -0,0 +1,8 @@
> +config ARM_RK3399_DMC_DEVFREQ
> + tristate "ARM RK3399 DMC DEVFREQ Driver"
> + select PM_OPP
> + select DEVFREQ_GOV_SIMPLE_ONDEMAND
> + help
> + This adds the DEVFREQ driver for the RK3399 dmc. It sets the
> frequency
If you add the full description for 'dmc' as following,
it is easy to understand the operation of this device driver.
- DMC (Dynamic Memory Controller)
> + for the memory controller and reads the usage counts from hardware.
> +
> diff --git a/drivers/devfreq/rockchip/Makefile
> b/drivers/devfreq/rockchip/Makefile
> new file mode 100644
> index 000..c62c105
> --- /dev/null
> +++ b/drivers/devfreq/rockchip/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ) += rk3399_dmc.o
> diff --git a/drivers/devfreq/rockchip/rk3399_dmc.c
> b/drivers/devfreq/rockchip/rk3399_dmc.c
> new file mode 100644
> index 000..527aa11
> --- /dev/null
> +++ b/drivers/devfreq/rockchip/rk3399_dmc.c
> @@ -0,0 +1,473 @@
> +/*
> + * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
You miss the '.' at the end of the copylight.
When you use an abbreviation, you should add '.' for Ltd.
- s/Ltd/Ltd.
> + * Author: Lin Huang
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + */
> +
> +#include
> +#include
> +#include
You don't need to include the "completion.h".
Without "completion.h", the build is working.
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
You don't need to include the "syscore_ops.h".
Without "syscore_ops.h", the build is working.
> +
> +#include
> +
> +struct dram_timing {
> + unsigned int ddr3_speed_bin;
> + unsigned int pd_idle;
> + unsigned int sr_idle;
> + unsigned int sr_mc_gate_idle;
> + unsigned int srpd_lite_idle;
> + unsigned int standby_idle;
> + unsigned int dram_dll_dis_freq;
> + unsigned
[PATCH 1/3] drm: bridge: add DesignWare HDMI I2S audio support
On Mon, Aug 01, 2016 at 04:57:07AM +, Kuninori Morimoto wrote: > Mark, Thierry, Daniel > I wonder who can be maintainer for this patch ?? It's a DRM patch so I'd expect someone in the DRM subsystem. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160801/e843072f/attachment-0001.sig>
[PATCH 0/9] drm: Store clipped coordinates in drm_plane_state
On Mon, Aug 01, 2016 at 11:12:05AM -0400, Sean Paul wrote:
> On Tue, Jul 26, 2016 at 12:06 PM, wrote:
> > From: Ville Syrjälä
> >
> > Moving the clipped plane coordinates into drm_plane_state has been
> > discussed a few times, but as no patches seems to have materialized,
> > I decoded to do it myself. I also added a new helper function
> > like drm_plane_helper_check_update() that takes a plane state instead.
> >
> > I converted i915, rockchip, and mediatek over to the new stuff. rockchip
> > already looked pretty solid, mediatek had some bugs in there that I
> > hopefully fixed. The rest of the non-x86 drivers seem to entirely lack
> > any plane clipping code, so I decided that I don't care enough to
> > write it from scratch. I also converted drm_simple_kms_helper, but
> > there are no drivers using it so far.
> >
> > I've only actually tested i915, the rest are just compile tested.
> >
> > Entire series available here:
> > git://github.com/vsyrjala/linux.git plane_state_rects
> >
> > Ville Syrjälä (9):
> > drm: Warn about negative sizes when calculating scale factor
> > drm: Store clipped src/dst coordinatee in drm_plane_state
> > drm/plane-helper: Add drm_plane_helper_check_state()
> > drm/i915: Use drm_plane_state.{src,dst,visible}
> > drm/i915: Use drm_plane_helper_check_state()
> > drm/rockchip: Use drm_plane_state.{src,dst}
> > drm/rockchip: Use drm_plane_helper_check_state()
> > drm/mediatek: Use drm_plane_helper_check_state()
> > drm/simple_kms_helper: Use drm_plane_helper_check_state()
>
>
> Looks good to me, all patches have been reviewed.
>
> It seems like the only consumer of drm_plane_helper_check_update()
> left is armada. Are you planning on converting it as well? Then we can
> nuke the function.
IIRC that driver isn't atomic enough for the new function.
>
> Sean
>
> >
> > drivers/gpu/drm/drm_plane_helper.c | 136
> > +--
> > drivers/gpu/drm/drm_rect.c | 2 +-
> > drivers/gpu/drm/drm_simple_kms_helper.c | 27 ++
> > drivers/gpu/drm/i915/intel_atomic_plane.c | 18 +---
> > drivers/gpu/drm/i915/intel_display.c| 140
> > ++--
> > drivers/gpu/drm/i915/intel_drv.h| 3 -
> > drivers/gpu/drm/i915/intel_fbc.c| 12 +--
> > drivers/gpu/drm/i915/intel_pm.c | 60 ++--
> > drivers/gpu/drm/i915/intel_sprite.c | 94 ++-
> > drivers/gpu/drm/mediatek/mtk_drm_plane.c| 72 --
> > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 31 ++
> > include/drm/drm_crtc.h | 13 +++
> > include/drm/drm_plane_helper.h | 5 +
> > 13 files changed, 315 insertions(+), 298 deletions(-)
> >
> > --
> > 2.7.4
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
[Bug 96866] REGRESSION System frozen after resume
https://bugs.freedesktop.org/show_bug.cgi?id=96866 --- Comment #3 from Alex Deucher --- You can set amdgpu.runpm=0 on the kernel command line in grub or try the latest drm-next kernel code. -- 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/20160801/2dcb169f/attachment.html>
[Bug 96866] REGRESSION System frozen after resume
https://bugs.freedesktop.org/show_bug.cgi?id=96866 --- Comment #2 from manof --- I have the same problem with Linux kernel 4.4.8 on my fresh (bought 4 days ago) HP notebook 17-y011nc, with AMD/ATI Topaz XT [Radeon R7 M260/M265]. The interesting thing is, that originally I had the 4.4.0 kernel from Ubuntu 16.04.1 LTS but it sometimes got frozen during suspending. Not everytime, just sometimes. However, it was a way too often, so it was pretty annoying. Then I have found somewhere in forums, that this bug was resolved in newer kernels, so I switched from 4.4.0 to 4.4.8. And it surely was resolved, however after resume from suspend, it ALWAYS got frozen, so my problem in fact got much worse with the kernel upgrade 4.4.0 => 4.4.8. -- 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/20160801/7529c1f0/attachment.html>
[Bug 95474] Bioshock Infinite and DiRT Showdown perform very poorly on any GPU with GCN >=1.1
https://bugs.freedesktop.org/show_bug.cgi?id=95474 --- Comment #14 from Marek Olšák --- I've done some profiling. Bioshock Infinite: - the game is CPU-bound most of the time - some small performance enhancements have landed already - the FenceSync optimization is a work in progress, expect a 30% improvement - most of the scratch buffer usage is for private memory, not VGPR spilling (this may be a defect in our indirect indexing) - if I'm not taking private memory usage into account, it's still in top 2 of the worst VGPR spilling apps DiRT Showdown: - the game is GPU-bound - there are a bunch of very slow pixel shaders using while loops, it's unclear how to make them faster - most of the scratch buffer usage is for VGPR spilling - it's in top 2 of the worst VGPR spilling apps -- 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/20160801/be41328b/attachment.html>
[PATCH] drm/gma500: remove comment for non-existent parameter
Remove comment for non-existent parameter in psbfb_alloc(). Signed-off-by: Jiang Biao --- drivers/gpu/drm/gma500/framebuffer.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/gma500/framebuffer.c b/drivers/gpu/drm/gma500/framebuffer.c index 7440bf9..f323989 100644 --- a/drivers/gpu/drm/gma500/framebuffer.c +++ b/drivers/gpu/drm/gma500/framebuffer.c @@ -308,7 +308,6 @@ static struct drm_framebuffer *psb_framebuffer_create * psbfb_alloc - allocate frame buffer memory * @dev: the DRM device * @aligned_size: space needed - * @force: fall back to GEM buffers if need be * * Allocate the frame buffer. In the usual case we get a GTT range that * is stolen memory backed and life is simple. If there isn't sufficient -- 2.1.0
[PATCH v4 5/7] PM / devfreq: event: support rockchip dfi controller
Hi Lin,
I add the one minor comment for full name of 'DRI'.
On 2016ë
08ì 01ì¼ 16:41, Chanwoo Choi wrote:
> Hi Lin,
>
> Because you remove the 'RFC' prefix on patch title,
> I think that you better to make the documentation as following:
> - Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
>
> Regards,
> Chanwoo Choi
>
> On 2016ë
07ì 29ì¼ 16:56, Lin Huang wrote:
>> on rk3399 platform, there is dfi conroller can monitor
>> ddr load, base on this result, we can do ddr freqency
>> scaling.
>>
>> Signed-off-by: Lin Huang
>> Acked-by: Chanwoo Choi
>> ---
>> Changes in v4:
>> - None
>>
>> Changes in v3:
>> - None
>>
>> Changes in v2:
>> - use clk_disable_unprepare and clk_enable_prepare
>> - remove clk_enable_prepare in probe
>> - remove rockchip_dfi_remove function
>>
>> Changes in v1:
>> - None
>>
>> drivers/devfreq/event/Kconfig| 7 +
>> drivers/devfreq/event/Makefile | 1 +
>> drivers/devfreq/event/rockchip-dfi.c | 253
>> +++
>> 3 files changed, 261 insertions(+)
>> create mode 100644 drivers/devfreq/event/rockchip-dfi.c
>>
>> diff --git a/drivers/devfreq/event/Kconfig b/drivers/devfreq/event/Kconfig
>> index a11720a..ff9279f 100644
>> --- a/drivers/devfreq/event/Kconfig
>> +++ b/drivers/devfreq/event/Kconfig
>> @@ -22,4 +22,11 @@ config DEVFREQ_EVENT_EXYNOS_PPMU
>>(Platform Performance Monitoring Unit) counters to estimate the
>>utilization of each module.
>>
>> +config DEVFREQ_EVENT_ROCKCHIP_DFI
>> +tristate "ROCKCHIP DFI DEVFREQ event Driver"
>> +depends on ARCH_ROCKCHIP
>> +help
>> + This add the devfreq-event driver for Rockchip SoC. It provides DFI
>> + (DDR Monitor Module) driver to count ddr load.
The DFI is "DDR Monitor Module" full name? I need the correct abbreviation
and full name.
>> +
>> endif # PM_DEVFREQ_EVENT
>> diff --git a/drivers/devfreq/event/Makefile b/drivers/devfreq/event/Makefile
>> index be146ea..e3f88fc 100644
>> --- a/drivers/devfreq/event/Makefile
>> +++ b/drivers/devfreq/event/Makefile
>> @@ -1,2 +1,3 @@
>> # Exynos DEVFREQ Event Drivers
>> obj-$(CONFIG_DEVFREQ_EVENT_EXYNOS_PPMU) += exynos-ppmu.o
>> +obj-$(CONFIG_DEVFREQ_EVENT_ROCKCHIP_DFI) += rockchip-dfi.o
>> diff --git a/drivers/devfreq/event/rockchip-dfi.c
>> b/drivers/devfreq/event/rockchip-dfi.c
>> new file mode 100644
>> index 000..96a0307
>> --- /dev/null
>> +++ b/drivers/devfreq/event/rockchip-dfi.c
>> @@ -0,0 +1,253 @@
>> +/*
>> + * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
>> + * Author: Lin Huang
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms and conditions of the GNU General Public License,
>> + * version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope it will be useful, but WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
>> + * more details.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define RK3399_DMC_NUM_CH 2
>> +
>> +/* DDRMON_CTRL */
>> +#define DDRMON_CTRL 0x04
>> +#define CLR_DDRMON_CTRL (0x1f << 0)
>> +#define LPDDR4_EN (0x10001 << 4)
>> +#define HARDWARE_EN (0x10001 << 3)
>> +#define LPDDR3_EN (0x10001 << 2)
>> +#define SOFTWARE_EN (0x10001 << 1)
>> +#define TIME_CNT_EN (0x10001 << 0)
>> +
>> +#define DDRMON_CH0_COUNT_NUM0x28
>> +#define DDRMON_CH0_DFI_ACCESS_NUM 0x2c
>> +#define DDRMON_CH1_COUNT_NUM0x3c
>> +#define DDRMON_CH1_DFI_ACCESS_NUM 0x40
>> +
>> +/* pmu grf */
>> +#define PMUGRF_OS_REG2 0x308
>> +#define DDRTYPE_SHIFT 13
>> +#define DDRTYPE_MASK7
>> +
>> +enum {
>> +DDR3 = 3,
>> +LPDDR3 = 6,
>> +LPDDR4 = 7,
>> +UNUSED = 0xFF
>> +};
>> +
>> +struct dmc_usage {
>> +u32 access;
>> +u32 total;
>> +};
>> +
>> +struct rockchip_dfi {
>> +struct devfreq_event_dev *edev;
>> +struct devfreq_event_desc *desc;
>> +struct dmc_usage ch_usage[RK3399_DMC_NUM_CH];
>> +struct device *dev;
>> +void __iomem *regs;
>> +struct regmap *regmap_pmu;
>> +struct clk *clk;
>> +};
>> +
>> +static void rockchip_dfi_start_hardware_counter(struct devfreq_event_dev
>> *edev)
>> +{
>> +struct rockchip_dfi *info = devfreq_event_get_drvdata(edev);
>> +void __iomem *dfi_regs = info->regs;
>> +u32 val;
>> +u32 ddr_type;
>> +
>> +/* get ddr type */
>> +regmap_read(info->regmap_pmu, PMUGRF_OS_REG2, );
>> +ddr_type = (val >> DDRTYPE_SHIFT) & DDRTYPE_MASK;
>> +
>> +/* clear DDRMON_CTRL setting */
>> +writel_relaxed(CLR_DDRMON_CTRL, dfi_regs + DDRMON_CTRL);
>> +
>> +/* set ddr type to dfi */
>> +if (ddr_type == LPDDR3)
>> +
Why drm-mipi-dsi is built-in only?
Cc Andrzej, Thierry On Fri, 22 Jul 2016, Daniel Vetter wrote: > On Fri, Jul 22, 2016 at 04:30:24PM +0200, Takashi Iwai wrote: >> Hi, >> >> is there any reason drm-mipi-dsi can't be a module? It's fixed as a >> built-in since its Kconfig is bool. > > Probably none except embedded folks eshew modules ;-) Submit patch, I'll > apply. Possibly this? postcore_initcall(mipi_dsi_bus_init); BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
[PATCH v4 0/7] rk3399 support ddr frequency scaling
Hi Lin, On 2016ë 08ì 01ì¼ 16:46, hl wrote: > Hi Chanwoo Choi, > > Ah, i am base on > https://chromium.googlesource.com/chromiumos/third_party/kernel/v4.4, > and forget to rebase on > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git, i will > fix it in next version. > I am sorry about that. And can you help to review the devfreq patch first, if > something need to update, > i will do it together. Thanks. Sure. I'm now reviewing the devfreq patches. Regards, Chanwoo Choi > > On 2016å¹´08æ01æ¥ 15:39, Chanwoo Choi wrote: >> Hi Lin, >> >> On 2016ë 07ì 29ì¼ 16:56, Lin Huang wrote: >>> rk3399 platform have dfi controller can monitor ddr load, >>> and dcf controller to handle ddr register so we can get the >>> right ddr frequency and make ddr controller happy work(which >>> will implement in bl31). So we do ddr frequency scaling with >>> following flow: >>> >>> kernelbl31 >>> >>> monitor ddr load >>> | >>> | >>> get_target_rate >>> | >>> | pass rate to bl31 >>> clk_set_rate(ddr) ->run dcf flow >>> | | >>> | | >>> wait dcf interrupt<---trigger dcf interrupt >>> | >>> | >>> return >>> >>> Lin Huang (6): >>>clk: rockchip: add new clock-type for the ddrclk >>>clk: rockchip: rk3399: add SCLK_DDRCLK ID for ddrc >>>clk: rockchip: rk3399: add ddrc clock support >>>PM / devfreq: event: support rockchip dfi controller >>>PM / devfreq: rockchip: add devfreq driver for rk3399 dmc >>>drm/rockchip: Add dmc notifier in vop driver >>> >>> >>> Heiko Stübner (1): >>>clk: rockchip: add clock flag parameter when register pll >>> >>> Lin Huang (6): >>>clk: rockchip: add new clock-type for the ddrclk >>>clk: rockchip: rk3399: add SCLK_DDRCLK ID for ddrc >>>clk: rockchip: rk3399: add ddrc clock support >>>PM / devfreq: event: support rockchip dfi controller >>>PM / devfreq: rockchip: add devfreq driver for rk3399 dmc >>>drm/rockchip: Add dmc notifier in vop driver >> The cover-letter includes the duplicate list of patches. >> >> Also, I want to test the build test. but, When I apply these patches, >> merge conflict happen. Could you give the information about base git >> repository? >> >> Regards, >> Chanwoo Choi >> >> >>> drivers/clk/rockchip/Makefile | 1 + >>> drivers/clk/rockchip/clk-ddr.c | 146 + >>> drivers/clk/rockchip/clk-pll.c | 4 +- >>> drivers/clk/rockchip/clk-rk3399.c | 19 ++ >>> drivers/clk/rockchip/clk.c | 11 +- >>> drivers/clk/rockchip/clk.h | 29 +- >>> drivers/devfreq/Kconfig | 1 + >>> drivers/devfreq/Makefile| 1 + >>> drivers/devfreq/event/Kconfig | 7 + >>> drivers/devfreq/event/Makefile | 1 + >>> drivers/devfreq/event/rockchip-dfi.c| 253 +++ >>> drivers/devfreq/rockchip/Kconfig| 8 + >>> drivers/devfreq/rockchip/Makefile | 1 + >>> drivers/devfreq/rockchip/rk3399_dmc.c | 473 >>> >>> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 124 +++- >>> include/dt-bindings/clock/rk3399-cru.h | 1 + >>> include/soc/rockchip/rockchip_sip.h | 27 ++ >>> 17 files changed, 1098 insertions(+), 9 deletions(-) >>> create mode 100644 drivers/clk/rockchip/clk-ddr.c >>> create mode 100644 drivers/devfreq/event/rockchip-dfi.c >>> create mode 100644 drivers/devfreq/rockchip/Kconfig >>> create mode 100644 drivers/devfreq/rockchip/Makefile >>> create mode 100644 drivers/devfreq/rockchip/rk3399_dmc.c >>> create mode 100644 include/soc/rockchip/rockchip_sip.h >>> >> >> >> >
[PATCH] drm/analogix_dp: Ensure the panel is properly prepared/unprepared
On Mon, Aug 1, 2016 at 4:20 PM, Sean Paul wrote:
> On Sun, Jul 31, 2016 at 11:27 PM, Yakir Yang wrote:
>> Sean,
>>
>> On 07/30/2016 03:16 AM, Sean Paul wrote:
>>>
>>> Instead of just preparing the panel on bind, actually prepare/unprepare
>>> during modeset/disable. The panel must be prepared in order to read hpd
>>> status, so we need to refcount the prepares in order to ensure we don't
>>> accidentally turn the panel off at the wrong time.
>>>
>>> Signed-off-by: Sean Paul
>>> ---
>>>
>>>
>>> Hi Yakir,
>>> This is what I was talking about upthread. I've tested it and it seems to
>>> be working.
>>>
>>> What do you think?
>>
>>
>> Thanks for your patch, and it works. But I have introduced two questions,
>> and I haven't found a way to fixed them.
>>
>>
>>> Sean
>>>
>>>
>>>
>>> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 48
>>> +-
>>> 1 file changed, 37 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> index 32715da..7b764a4 100644
>>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> @@ -960,11 +960,27 @@ enum drm_connector_status
>>> analogix_dp_detect(struct drm_connector *connector, bool force)
>>> {
>>> struct analogix_dp_device *dp = to_dp(connector);
>>> + enum drm_connector_status status = connector_status_disconnected;
>>> + int ret;
>>> - if (analogix_dp_detect_hpd(dp))
>>> - return connector_status_disconnected;
>>> + if (dp->plat_data->panel && dp->dpms_mode != DRM_MODE_DPMS_ON) {
>>> + ret = drm_panel_prepare(dp->plat_data->panel);
>>> + if (ret) {
>>> + DRM_ERROR("failed to setup panel (%d)\n", ret);
>>> + return connector_status_disconnected;
>>> + }
>>> + }
>>> +
>>> + if (!analogix_dp_detect_hpd(dp))
>>> + status = connector_status_connected;
>>> +
>>> + if (dp->plat_data->panel && dp->dpms_mode != DRM_MODE_DPMS_ON) {
>>> + ret = drm_panel_unprepare(dp->plat_data->panel);
>>> + if (ret)
>>> + DRM_ERROR("failed to setup the panel ret = %d\n",
>>> ret);
>>> + }
>>> - return connector_status_connected;
>>> + return status;
>>
>>
>> 1. Panel would flicker at system boot time. Your patch would flash the panel
>> power in connector->detect() function when dp->dpms_mode isn't
>> DRM_MODE_DPMS_OFF. So when userspace keep detect the connector status in
>> boot time, we could see panel would flicker (light up for a while, and turn
>> off again, and keep loop for several time). I have copied some kernel logs:
>>
>
>
> Hmm, yeah, the backlight does seem to flash. It seems like backlight
> shouldn't be on if the panel isn't enabled. this would also fix the
> issue below since you could add panel prepare/unprepare in get_modes.
>
> Alternatively, have you played around with moving things around in
> prepare/unprepare? Perhaps just enabling the supply regulator (without
> the enable gpio set) is sufficient to read HPD/EDID, but will still
> prevent the original backlight flicker/burn-in issue?
>
To answer my own question, the enable_gpio isn't populated in the dts,
so reordering things in prepare isn't feasible.
Sean
> Sean
>
>
>
>>
>> [ 11.065267] YKK - analogix_dp_detect:1052
>> [ 11.729596] YKK - analogix_dp_get_modes:1016
>> [ 11.737608] rockchip-dp ff97.edp: analogix_dp_read_bytes_from_dpcd:
>> Aux Transaction fail!
>> [ 11.749229] rockchip-dp ff97.edp: analogix_dp_read_bytes_from_dpcd:
>> Aux Transaction fail!
>> [ 11.760799] rockchip-dp ff97.edp: analogix_dp_read_bytes_from_dpcd:
>> Aux Transaction fail!
>> [ 13.315962] YKK - analogix_dp_detect:1052
>> [ 13.984702] YKK - analogix_dp_get_modes:1016
>> [ 13.992977] rockchip-dp ff97.edp: analogix_dp_read_bytes_from_dpcd:
>> Aux Transaction fail!
>> [ 14.004414] rockchip-dp ff97.edp: analogix_dp_read_bytes_from_dpcd:
>> Aux Transaction fail!
>> [ 14.015842] rockchip-dp ff97.edp: analogix_dp_read_bytes_from_dpcd:
>> Aux Transaction fail!
>> [ 14.183109] YKK - analogix_dp_bridge_pre_enable:1147
>> [ 14.306301] rockchip-dp ff97.edp: Link Training Clock Recovery
>> success
>> [ 14.319130] rockchip-dp ff97.edp: Link Training success!
>> [ 14.326388] rockchip-dp ff97.edp: wait SYS_CTL_2.
>> [ 14.437247] rockchip-dp ff97.edp: Timeout of video streamclk ok
>> [ 14.443585] rockchip-dp ff97.edp: unable to config video
>>
>>
>>> }
>>> static void analogix_dp_connector_destroy(struct drm_connector
>>> *connector)
>>> @@ -1035,6 +1051,18 @@ static int analogix_dp_bridge_attach(struct
>>> drm_bridge *bridge)
>>> return 0;
>>> }
>>> +static void analogix_dp_bridge_pre_enable(struct
[PATCH v4 5/7] PM / devfreq: event: support rockchip dfi controller
Hi Lin,
Because you remove the 'RFC' prefix on patch title,
I think that you better to make the documentation as following:
- Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
Regards,
Chanwoo Choi
On 2016ë
07ì 29ì¼ 16:56, Lin Huang wrote:
> on rk3399 platform, there is dfi conroller can monitor
> ddr load, base on this result, we can do ddr freqency
> scaling.
>
> Signed-off-by: Lin Huang
> Acked-by: Chanwoo Choi
> ---
> Changes in v4:
> - None
>
> Changes in v3:
> - None
>
> Changes in v2:
> - use clk_disable_unprepare and clk_enable_prepare
> - remove clk_enable_prepare in probe
> - remove rockchip_dfi_remove function
>
> Changes in v1:
> - None
>
> drivers/devfreq/event/Kconfig| 7 +
> drivers/devfreq/event/Makefile | 1 +
> drivers/devfreq/event/rockchip-dfi.c | 253
> +++
> 3 files changed, 261 insertions(+)
> create mode 100644 drivers/devfreq/event/rockchip-dfi.c
>
> diff --git a/drivers/devfreq/event/Kconfig b/drivers/devfreq/event/Kconfig
> index a11720a..ff9279f 100644
> --- a/drivers/devfreq/event/Kconfig
> +++ b/drivers/devfreq/event/Kconfig
> @@ -22,4 +22,11 @@ config DEVFREQ_EVENT_EXYNOS_PPMU
> (Platform Performance Monitoring Unit) counters to estimate the
> utilization of each module.
>
> +config DEVFREQ_EVENT_ROCKCHIP_DFI
> + tristate "ROCKCHIP DFI DEVFREQ event Driver"
> + depends on ARCH_ROCKCHIP
> + help
> + This add the devfreq-event driver for Rockchip SoC. It provides DFI
> + (DDR Monitor Module) driver to count ddr load.
> +
> endif # PM_DEVFREQ_EVENT
> diff --git a/drivers/devfreq/event/Makefile b/drivers/devfreq/event/Makefile
> index be146ea..e3f88fc 100644
> --- a/drivers/devfreq/event/Makefile
> +++ b/drivers/devfreq/event/Makefile
> @@ -1,2 +1,3 @@
> # Exynos DEVFREQ Event Drivers
> obj-$(CONFIG_DEVFREQ_EVENT_EXYNOS_PPMU) += exynos-ppmu.o
> +obj-$(CONFIG_DEVFREQ_EVENT_ROCKCHIP_DFI) += rockchip-dfi.o
> diff --git a/drivers/devfreq/event/rockchip-dfi.c
> b/drivers/devfreq/event/rockchip-dfi.c
> new file mode 100644
> index 000..96a0307
> --- /dev/null
> +++ b/drivers/devfreq/event/rockchip-dfi.c
> @@ -0,0 +1,253 @@
> +/*
> + * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
> + * Author: Lin Huang
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define RK3399_DMC_NUM_CH2
> +
> +/* DDRMON_CTRL */
> +#define DDRMON_CTRL 0x04
> +#define CLR_DDRMON_CTRL (0x1f << 0)
> +#define LPDDR4_EN(0x10001 << 4)
> +#define HARDWARE_EN (0x10001 << 3)
> +#define LPDDR3_EN(0x10001 << 2)
> +#define SOFTWARE_EN (0x10001 << 1)
> +#define TIME_CNT_EN (0x10001 << 0)
> +
> +#define DDRMON_CH0_COUNT_NUM 0x28
> +#define DDRMON_CH0_DFI_ACCESS_NUM0x2c
> +#define DDRMON_CH1_COUNT_NUM 0x3c
> +#define DDRMON_CH1_DFI_ACCESS_NUM0x40
> +
> +/* pmu grf */
> +#define PMUGRF_OS_REG2 0x308
> +#define DDRTYPE_SHIFT13
> +#define DDRTYPE_MASK 7
> +
> +enum {
> + DDR3 = 3,
> + LPDDR3 = 6,
> + LPDDR4 = 7,
> + UNUSED = 0xFF
> +};
> +
> +struct dmc_usage {
> + u32 access;
> + u32 total;
> +};
> +
> +struct rockchip_dfi {
> + struct devfreq_event_dev *edev;
> + struct devfreq_event_desc *desc;
> + struct dmc_usage ch_usage[RK3399_DMC_NUM_CH];
> + struct device *dev;
> + void __iomem *regs;
> + struct regmap *regmap_pmu;
> + struct clk *clk;
> +};
> +
> +static void rockchip_dfi_start_hardware_counter(struct devfreq_event_dev
> *edev)
> +{
> + struct rockchip_dfi *info = devfreq_event_get_drvdata(edev);
> + void __iomem *dfi_regs = info->regs;
> + u32 val;
> + u32 ddr_type;
> +
> + /* get ddr type */
> + regmap_read(info->regmap_pmu, PMUGRF_OS_REG2, );
> + ddr_type = (val >> DDRTYPE_SHIFT) & DDRTYPE_MASK;
> +
> + /* clear DDRMON_CTRL setting */
> + writel_relaxed(CLR_DDRMON_CTRL, dfi_regs + DDRMON_CTRL);
> +
> + /* set ddr type to dfi */
> + if (ddr_type == LPDDR3)
> + writel_relaxed(LPDDR3_EN, dfi_regs + DDRMON_CTRL);
> + else if (ddr_type == LPDDR4)
> + writel_relaxed(LPDDR4_EN, dfi_regs + DDRMON_CTRL);
> +
> + /* enable count, use software mode */
> + writel_relaxed(SOFTWARE_EN, dfi_regs + DDRMON_CTRL);
> +}
> +
> +static void rockchip_dfi_stop_hardware_counter(struct
[PATCH v4 0/7] rk3399 support ddr frequency scaling
Hi Lin, On 2016ë 07ì 29ì¼ 16:56, Lin Huang wrote: > rk3399 platform have dfi controller can monitor ddr load, > and dcf controller to handle ddr register so we can get the > right ddr frequency and make ddr controller happy work(which > will implement in bl31). So we do ddr frequency scaling with > following flow: > >kernelbl31 > > monitor ddr load > | > | > get_target_rate > | > | pass rate to bl31 > clk_set_rate(ddr) ->run dcf flow > | | > | | > wait dcf interrupt<---trigger dcf interrupt > | > | > return > > Lin Huang (6): > clk: rockchip: add new clock-type for the ddrclk > clk: rockchip: rk3399: add SCLK_DDRCLK ID for ddrc > clk: rockchip: rk3399: add ddrc clock support > PM / devfreq: event: support rockchip dfi controller > PM / devfreq: rockchip: add devfreq driver for rk3399 dmc > drm/rockchip: Add dmc notifier in vop driver > > > Heiko Stübner (1): > clk: rockchip: add clock flag parameter when register pll > > Lin Huang (6): > clk: rockchip: add new clock-type for the ddrclk > clk: rockchip: rk3399: add SCLK_DDRCLK ID for ddrc > clk: rockchip: rk3399: add ddrc clock support > PM / devfreq: event: support rockchip dfi controller > PM / devfreq: rockchip: add devfreq driver for rk3399 dmc > drm/rockchip: Add dmc notifier in vop driver The cover-letter includes the duplicate list of patches. Also, I want to test the build test. but, When I apply these patches, merge conflict happen. Could you give the information about base git repository? Regards, Chanwoo Choi > drivers/clk/rockchip/Makefile | 1 + > drivers/clk/rockchip/clk-ddr.c | 146 + > drivers/clk/rockchip/clk-pll.c | 4 +- > drivers/clk/rockchip/clk-rk3399.c | 19 ++ > drivers/clk/rockchip/clk.c | 11 +- > drivers/clk/rockchip/clk.h | 29 +- > drivers/devfreq/Kconfig | 1 + > drivers/devfreq/Makefile| 1 + > drivers/devfreq/event/Kconfig | 7 + > drivers/devfreq/event/Makefile | 1 + > drivers/devfreq/event/rockchip-dfi.c| 253 +++ > drivers/devfreq/rockchip/Kconfig| 8 + > drivers/devfreq/rockchip/Makefile | 1 + > drivers/devfreq/rockchip/rk3399_dmc.c | 473 > > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 124 +++- > include/dt-bindings/clock/rk3399-cru.h | 1 + > include/soc/rockchip/rockchip_sip.h | 27 ++ > 17 files changed, 1098 insertions(+), 9 deletions(-) > create mode 100644 drivers/clk/rockchip/clk-ddr.c > create mode 100644 drivers/devfreq/event/rockchip-dfi.c > create mode 100644 drivers/devfreq/rockchip/Kconfig > create mode 100644 drivers/devfreq/rockchip/Makefile > create mode 100644 drivers/devfreq/rockchip/rk3399_dmc.c > create mode 100644 include/soc/rockchip/rockchip_sip.h >
[Bug 90481] Radeonsi driver, X crash while playing "Spec ops: the line"
https://bugs.freedesktop.org/show_bug.cgi?id=90481 --- Comment #15 from Marek Olšák --- You can try to test with: GALLIUM_DDEBUG="pipelined 1" -- 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/20160801/bb3f3bfc/attachment.html>
[PATCH v4 5/7] PM / devfreq: event: support rockchip dfi controller
Hi Chanwoo Choi,
On 2016å¹´08æ01æ¥ 16:08, Chanwoo Choi wrote:
> Hi Lin,
>
> I add the one minor comment for full name of 'DRI'.
>
> On 2016ë
08ì 01ì¼ 16:41, Chanwoo Choi wrote:
>> Hi Lin,
>>
>> Because you remove the 'RFC' prefix on patch title,
>> I think that you better to make the documentation as following:
>> - Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
>>
>> Regards,
>> Chanwoo Choi
>>
>> On 2016ë
07ì 29ì¼ 16:56, Lin Huang wrote:
>>> on rk3399 platform, there is dfi conroller can monitor
>>> ddr load, base on this result, we can do ddr freqency
>>> scaling.
>>>
>>> Signed-off-by: Lin Huang
>>> Acked-by: Chanwoo Choi
>>> ---
>>> Changes in v4:
>>> - None
>>>
>>> Changes in v3:
>>> - None
>>>
>>> Changes in v2:
>>> - use clk_disable_unprepare and clk_enable_prepare
>>> - remove clk_enable_prepare in probe
>>> - remove rockchip_dfi_remove function
>>>
>>> Changes in v1:
>>> - None
>>>
>>> drivers/devfreq/event/Kconfig| 7 +
>>> drivers/devfreq/event/Makefile | 1 +
>>> drivers/devfreq/event/rockchip-dfi.c | 253
>>> +++
>>> 3 files changed, 261 insertions(+)
>>> create mode 100644 drivers/devfreq/event/rockchip-dfi.c
>>>
>>> diff --git a/drivers/devfreq/event/Kconfig b/drivers/devfreq/event/Kconfig
>>> index a11720a..ff9279f 100644
>>> --- a/drivers/devfreq/event/Kconfig
>>> +++ b/drivers/devfreq/event/Kconfig
>>> @@ -22,4 +22,11 @@ config DEVFREQ_EVENT_EXYNOS_PPMU
>>> (Platform Performance Monitoring Unit) counters to estimate the
>>> utilization of each module.
>>>
>>> +config DEVFREQ_EVENT_ROCKCHIP_DFI
>>> + tristate "ROCKCHIP DFI DEVFREQ event Driver"
>>> + depends on ARCH_ROCKCHIP
>>> + help
>>> + This add the devfreq-event driver for Rockchip SoC. It provides DFI
>>> + (DDR Monitor Module) driver to count ddr load.
> The DFI is "DDR Monitor Module" full name? I need the correct abbreviation
> and full name.
We just call this module DFI in datasheet, and this module function is
ddr monitor module,
yes, it is do not fit the full name, but i think it is better follow the
datasheet name.
>
>>> +
>>> endif # PM_DEVFREQ_EVENT
>>> diff --git a/drivers/devfreq/event/Makefile b/drivers/devfreq/event/Makefile
>>> index be146ea..e3f88fc 100644
>>> --- a/drivers/devfreq/event/Makefile
>>> +++ b/drivers/devfreq/event/Makefile
>>> @@ -1,2 +1,3 @@
>>> # Exynos DEVFREQ Event Drivers
>>> obj-$(CONFIG_DEVFREQ_EVENT_EXYNOS_PPMU) += exynos-ppmu.o
>>> +obj-$(CONFIG_DEVFREQ_EVENT_ROCKCHIP_DFI) += rockchip-dfi.o
>>> diff --git a/drivers/devfreq/event/rockchip-dfi.c
>>> b/drivers/devfreq/event/rockchip-dfi.c
>>> new file mode 100644
>>> index 000..96a0307
>>> --- /dev/null
>>> +++ b/drivers/devfreq/event/rockchip-dfi.c
>>> @@ -0,0 +1,253 @@
>>> +/*
>>> + * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
>>> + * Author: Lin Huang
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify it
>>> + * under the terms and conditions of the GNU General Public License,
>>> + * version 2, as published by the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope it will be useful, but WITHOUT
>>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
>>> for
>>> + * more details.
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +#define RK3399_DMC_NUM_CH 2
>>> +
>>> +/* DDRMON_CTRL */
>>> +#define DDRMON_CTRL0x04
>>> +#define CLR_DDRMON_CTRL(0x1f << 0)
>>> +#define LPDDR4_EN (0x10001 << 4)
>>> +#define HARDWARE_EN(0x10001 << 3)
>>> +#define LPDDR3_EN (0x10001 << 2)
>>> +#define SOFTWARE_EN(0x10001 << 1)
>>> +#define TIME_CNT_EN(0x10001 << 0)
>>> +
>>> +#define DDRMON_CH0_COUNT_NUM 0x28
>>> +#define DDRMON_CH0_DFI_ACCESS_NUM 0x2c
>>> +#define DDRMON_CH1_COUNT_NUM 0x3c
>>> +#define DDRMON_CH1_DFI_ACCESS_NUM 0x40
>>> +
>>> +/* pmu grf */
>>> +#define PMUGRF_OS_REG2 0x308
>>> +#define DDRTYPE_SHIFT 13
>>> +#define DDRTYPE_MASK 7
>>> +
>>> +enum {
>>> + DDR3 = 3,
>>> + LPDDR3 = 6,
>>> + LPDDR4 = 7,
>>> + UNUSED = 0xFF
>>> +};
>>> +
>>> +struct dmc_usage {
>>> + u32 access;
>>> + u32 total;
>>> +};
>>> +
>>> +struct rockchip_dfi {
>>> + struct devfreq_event_dev *edev;
>>> + struct devfreq_event_desc *desc;
>>> + struct dmc_usage ch_usage[RK3399_DMC_NUM_CH];
>>> + struct device *dev;
>>> + void __iomem *regs;
>>> + struct regmap *regmap_pmu;
>>> + struct clk *clk;
>>> +};
>>> +
>>> +static void rockchip_dfi_start_hardware_counter(struct devfreq_event_dev
>>> *edev)
>>> +{
>>> + struct rockchip_dfi *info = devfreq_event_get_drvdata(edev);
>>> + void __iomem
[PATCH] drm/analogix_dp: Ensure the panel is properly prepared/unprepared
On Sun, Jul 31, 2016 at 11:27 PM, Yakir Yang wrote:
> Sean,
>
> On 07/30/2016 03:16 AM, Sean Paul wrote:
>>
>> Instead of just preparing the panel on bind, actually prepare/unprepare
>> during modeset/disable. The panel must be prepared in order to read hpd
>> status, so we need to refcount the prepares in order to ensure we don't
>> accidentally turn the panel off at the wrong time.
>>
>> Signed-off-by: Sean Paul
>> ---
>>
>>
>> Hi Yakir,
>> This is what I was talking about upthread. I've tested it and it seems to
>> be working.
>>
>> What do you think?
>
>
> Thanks for your patch, and it works. But I have introduced two questions,
> and I haven't found a way to fixed them.
>
>
>> Sean
>>
>>
>>
>> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 48
>> +-
>> 1 file changed, 37 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> index 32715da..7b764a4 100644
>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> @@ -960,11 +960,27 @@ enum drm_connector_status
>> analogix_dp_detect(struct drm_connector *connector, bool force)
>> {
>> struct analogix_dp_device *dp = to_dp(connector);
>> + enum drm_connector_status status = connector_status_disconnected;
>> + int ret;
>> - if (analogix_dp_detect_hpd(dp))
>> - return connector_status_disconnected;
>> + if (dp->plat_data->panel && dp->dpms_mode != DRM_MODE_DPMS_ON) {
>> + ret = drm_panel_prepare(dp->plat_data->panel);
>> + if (ret) {
>> + DRM_ERROR("failed to setup panel (%d)\n", ret);
>> + return connector_status_disconnected;
>> + }
>> + }
>> +
>> + if (!analogix_dp_detect_hpd(dp))
>> + status = connector_status_connected;
>> +
>> + if (dp->plat_data->panel && dp->dpms_mode != DRM_MODE_DPMS_ON) {
>> + ret = drm_panel_unprepare(dp->plat_data->panel);
>> + if (ret)
>> + DRM_ERROR("failed to setup the panel ret = %d\n",
>> ret);
>> + }
>> - return connector_status_connected;
>> + return status;
>
>
> 1. Panel would flicker at system boot time. Your patch would flash the panel
> power in connector->detect() function when dp->dpms_mode isn't
> DRM_MODE_DPMS_OFF. So when userspace keep detect the connector status in
> boot time, we could see panel would flicker (light up for a while, and turn
> off again, and keep loop for several time). I have copied some kernel logs:
>
Hmm, yeah, the backlight does seem to flash. It seems like backlight
shouldn't be on if the panel isn't enabled. this would also fix the
issue below since you could add panel prepare/unprepare in get_modes.
Alternatively, have you played around with moving things around in
prepare/unprepare? Perhaps just enabling the supply regulator (without
the enable gpio set) is sufficient to read HPD/EDID, but will still
prevent the original backlight flicker/burn-in issue?
Sean
>
> [ 11.065267] YKK - analogix_dp_detect:1052
> [ 11.729596] YKK - analogix_dp_get_modes:1016
> [ 11.737608] rockchip-dp ff97.edp: analogix_dp_read_bytes_from_dpcd:
> Aux Transaction fail!
> [ 11.749229] rockchip-dp ff97.edp: analogix_dp_read_bytes_from_dpcd:
> Aux Transaction fail!
> [ 11.760799] rockchip-dp ff97.edp: analogix_dp_read_bytes_from_dpcd:
> Aux Transaction fail!
> [ 13.315962] YKK - analogix_dp_detect:1052
> [ 13.984702] YKK - analogix_dp_get_modes:1016
> [ 13.992977] rockchip-dp ff97.edp: analogix_dp_read_bytes_from_dpcd:
> Aux Transaction fail!
> [ 14.004414] rockchip-dp ff97.edp: analogix_dp_read_bytes_from_dpcd:
> Aux Transaction fail!
> [ 14.015842] rockchip-dp ff97.edp: analogix_dp_read_bytes_from_dpcd:
> Aux Transaction fail!
> [ 14.183109] YKK - analogix_dp_bridge_pre_enable:1147
> [ 14.306301] rockchip-dp ff97.edp: Link Training Clock Recovery
> success
> [ 14.319130] rockchip-dp ff97.edp: Link Training success!
> [ 14.326388] rockchip-dp ff97.edp: wait SYS_CTL_2.
> [ 14.437247] rockchip-dp ff97.edp: Timeout of video streamclk ok
> [ 14.443585] rockchip-dp ff97.edp: unable to config video
>
>
>> }
>> static void analogix_dp_connector_destroy(struct drm_connector
>> *connector)
>> @@ -1035,6 +1051,18 @@ static int analogix_dp_bridge_attach(struct
>> drm_bridge *bridge)
>> return 0;
>> }
>> +static void analogix_dp_bridge_pre_enable(struct drm_bridge *bridge)
>> +{
>> + struct analogix_dp_device *dp = bridge->driver_private;
>> + int ret;
>> +
>> + if (dp->plat_data->panel) {
>> + ret = drm_panel_prepare(dp->plat_data->panel);
>> + if (ret)
>> + DRM_ERROR("failed to setup the
[Bug 94860] [radeonsi/amdgpu][DCC] screen is corrupted when logging out of kde
https://bugs.freedesktop.org/show_bug.cgi?id=94860 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Marek Olšák --- (In reply to Laurent carlier from comment #10) > I can't reproduce this anymore. Possible fix: https://cgit.freedesktop.org/mesa/mesa/commit/?id=095803a37aa67361fc68604e81f858f31ae59b1b Closing. -- 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/20160801/34d870f9/attachment.html>
[Bug 97166] lockup during gameplay of Batman series of games
https://bugs.freedesktop.org/show_bug.cgi?id=97166 --- Comment #4 from smoki --- At least AMD listing 00, F0, F1 revs... so pci-ids project might try to differinate descriptions somehow by revs too: http://developer.amd.com/resources/ati-catalyst-pc-vendor-id-1002-li/ For the bug, i suspect it is one of those "as soon as threading is pushed lockup happens" ;) -- 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/20160801/177358a7/attachment.html>
[PATCH v4 0/7] rk3399 support ddr frequency scaling
Hi Chanwoo Choi, Ah, i am base on https://chromium.googlesource.com/chromiumos/third_party/kernel/v4.4, and forget to rebase on https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git, i will fix it in next version. I am sorry about that. And can you help to review the devfreq patch first, if something need to update, i will do it together. Thanks. On 2016å¹´08æ01æ¥ 15:39, Chanwoo Choi wrote: > Hi Lin, > > On 2016ë 07ì 29ì¼ 16:56, Lin Huang wrote: >> rk3399 platform have dfi controller can monitor ddr load, >> and dcf controller to handle ddr register so we can get the >> right ddr frequency and make ddr controller happy work(which >> will implement in bl31). So we do ddr frequency scaling with >> following flow: >> >> kernelbl31 >> >> monitor ddr load >> | >> | >> get_target_rate >> | >> | pass rate to bl31 >> clk_set_rate(ddr) ->run dcf flow >> | | >> | | >> wait dcf interrupt<---trigger dcf interrupt >> | >> | >>return >> >> Lin Huang (6): >>clk: rockchip: add new clock-type for the ddrclk >>clk: rockchip: rk3399: add SCLK_DDRCLK ID for ddrc >>clk: rockchip: rk3399: add ddrc clock support >>PM / devfreq: event: support rockchip dfi controller >>PM / devfreq: rockchip: add devfreq driver for rk3399 dmc >>drm/rockchip: Add dmc notifier in vop driver >> >> >> Heiko Stübner (1): >>clk: rockchip: add clock flag parameter when register pll >> >> Lin Huang (6): >>clk: rockchip: add new clock-type for the ddrclk >>clk: rockchip: rk3399: add SCLK_DDRCLK ID for ddrc >>clk: rockchip: rk3399: add ddrc clock support >>PM / devfreq: event: support rockchip dfi controller >>PM / devfreq: rockchip: add devfreq driver for rk3399 dmc >>drm/rockchip: Add dmc notifier in vop driver > The cover-letter includes the duplicate list of patches. > > Also, I want to test the build test. but, When I apply these patches, > merge conflict happen. Could you give the information about base git > repository? > > Regards, > Chanwoo Choi > > >> drivers/clk/rockchip/Makefile | 1 + >> drivers/clk/rockchip/clk-ddr.c | 146 + >> drivers/clk/rockchip/clk-pll.c | 4 +- >> drivers/clk/rockchip/clk-rk3399.c | 19 ++ >> drivers/clk/rockchip/clk.c | 11 +- >> drivers/clk/rockchip/clk.h | 29 +- >> drivers/devfreq/Kconfig | 1 + >> drivers/devfreq/Makefile| 1 + >> drivers/devfreq/event/Kconfig | 7 + >> drivers/devfreq/event/Makefile | 1 + >> drivers/devfreq/event/rockchip-dfi.c| 253 +++ >> drivers/devfreq/rockchip/Kconfig| 8 + >> drivers/devfreq/rockchip/Makefile | 1 + >> drivers/devfreq/rockchip/rk3399_dmc.c | 473 >> >> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 124 +++- >> include/dt-bindings/clock/rk3399-cru.h | 1 + >> include/soc/rockchip/rockchip_sip.h | 27 ++ >> 17 files changed, 1098 insertions(+), 9 deletions(-) >> create mode 100644 drivers/clk/rockchip/clk-ddr.c >> create mode 100644 drivers/devfreq/event/rockchip-dfi.c >> create mode 100644 drivers/devfreq/rockchip/Kconfig >> create mode 100644 drivers/devfreq/rockchip/Makefile >> create mode 100644 drivers/devfreq/rockchip/rk3399_dmc.c >> create mode 100644 include/soc/rockchip/rockchip_sip.h >> > > > -- Lin Huang
[PATCH 1/3] drm: bridge: add DesignWare HDMI I2S audio support
On Fri, Jun 24, 2016 at 11:40:44AM +0900, Kuninori Morimoto wrote:
> +static int snd_dw_hdmi_probe(struct platform_device *pdev)
> +{
> + struct dw_hdmi_i2s_audio_data *audio = pdev->dev.platform_data;
> + struct platform_device_info pdevinfo;
> + struct hdmi_codec_pdata pdata;
> +
> + pdata.ops = _hdmi_i2s_ops;
> + pdata.i2s = 1;
> + pdata.max_i2s_channels = 6;
> + pdata.data = audio;
> +
> + memset(, 0, sizeof(pdevinfo));
> + pdevinfo.parent = pdev->dev.parent;
> + pdevinfo.id = PLATFORM_DEVID_AUTO;
> + pdevinfo.name = HDMI_CODEC_DRV_NAME;
> + pdevinfo.data =
> + pdevinfo.size_data = sizeof(pdata);
> + pdevinfo.dma_mask = DMA_BIT_MASK(32);
> +
> + return IS_ERR_OR_NULL(platform_device_register_full());
This is certainly wrong. You're returning a 0/1 value rather than
an error code when platform_device_register_full() fails.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
[Bug 97166] lockup during gameplay of Batman series of games
https://bugs.freedesktop.org/show_bug.cgi?id=97166 --- Comment #3 from Vedran MiletiÄ --- (In reply to smoki from comment #2) > Mobile Tonga it seems. Desktop and mobile chip have the same PCI ID, that's why I ask [1]. I might be able to test Batman on my 380X to confirm the issue. [1] https://pci-ids.ucw.cz/read/PC/1002/6938 -- 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/20160801/9183cd5f/attachment.html>
[Bug 97166] lockup during gameplay of Batman series of games
https://bugs.freedesktop.org/show_bug.cgi?id=97166 --- Comment #2 from smoki --- Mobile Tonga it seems. @farmboy0 Does lockups happens with regular wine? I remember cases when Catalyst can lockup using wine-csmt too... just a note that wine-csmt isn't perfect always so check regular wine too. -- 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/20160801/aa2cf5fe/attachment-0001.html>
[Bug 97166] lockup during gameplay of Batman series of games
https://bugs.freedesktop.org/show_bug.cgi?id=97166 --- Comment #1 from Vedran MiletiÄ --- Is this Tonga (380/380X) or some other card? -- 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/20160801/f9372b92/attachment.html>
[Intel-gfx] [PATCH v4 0/6] Finally fix watermarks
On Fri, Jul 29, 2016 at 01:41:26PM -0700, Matt Roper wrote: > On Fri, Jul 29, 2016 at 10:26:20PM +0300, Ville Syrjälä wrote: > > On Fri, Jul 29, 2016 at 02:48:09PM -0400, Lyude wrote: > > > So I've been working on trying to fix this entirely again (e.g. writing > > > the ddb properly), since from bug reports it still doesn't sound like > > > we've got enough workarounds to make this tolerable. I've shown this to > > > matt roper, but I should probably post what I've been trying to do for > > > you as well. > > > > > > So the approach I came up with is here > > > > > > https://github.com/lyude/linux/tree/wip/skl-fix-wms-v5r2 > > > > > > My approach differs a little bit from what the bspec recommends, but I > > > think it's going to be a bit easier to implement. At the end of all the > > > changes I'm attempting it should look like this: > > > > > > * We no longer have a global watermark update for skl > > > * A new hook called "update_ddbs" is added to i915_display_funcs. This > > >gets called in intel_atomic_commit_tail() after we've disabled any > > >CRTCs that needed disabling, and before we begin enabling/updating > > >CRTCs > > > * Because pipe ddb allocations (not the inner-pipe ddb allocations > > >that apply to each pipe's planes) only change while > > >enabling/disabling crtcs: > > > * Pass 1: Find which pipe's new ddb allocation won't overlap with > > > another pipe's previous allocation, and update that pipe first > > > * Pass 2: Update the allocation of the remaining pipe > > > > > > Here's an illustration of what this looks like. Parts of the ddb not > > > being used by any CRTCs are marked out with 'x's: > > > > > > With pipe A enabled, we enable pipe B: > > > Initial DDB:   |      A      | > > > update_ddbs:   |   A   |xxx| Pass 1 > > > Enable pipe B:  |   A   |   B   | > > > > > > With pipes B and A active, we enable pipe C: > > > > > > Initial DDB:   |   B   |   A   | > > > update_ddbs:   |  B  |xxx|   A   | Pass 1 > > > update_ddbs:   |  B  |  A  |xxx| Pass 2 > > > Enable pipe C:  |  B  |  A  |  C  | > > > > > > With pipes A, B, and C active, we disable B: > > > Initial DDB:   |  A  |  B  |  C  | > > > Disable pipe B: |  A  |xxx|  C  | > > > update_ddbs:   |   A   |   C   | Pass 1 > > > Since neither pipe's new allocation overlapped, we skip pass 2 > > > > > > Another allocation with A, B, and C active, disabling A: > > > Initial DDB:   |  A  |  B  |  C  | > > > Disable pipe A: |xxx|  B  |  C  | > > > update_ddbs:   |   B   |xxx|  C  | Pass 1 > > > update_ddbs:   |   B   |   C   | Pass 2 > > > > > > This should ensure we can always move around the allocations of pipes > > > without them ever overlapping and exploding. > > > > That's what the current flush thing does, or at least that what it used > > to do at least. Not sure it's really doing it anymore, but I'm pretty > > sure the order in which it did things was sound at some point. > > > > > > > > This branch doesn't entirely fix underrun issues, but I'm mostly sure > > > that's the fault of still not having removed the global wm update hook > > > yet (which is leading to additional pipe flushes in places they > > > shouldn't be): > > > > Well it should basically boil down to s/update_wm/update_ddb/ > > Only DDB reallocation really warrants a global hook. Everything else > > should be handled via per-crtc hooks, on all platforms. > > I don't think we want even update_ddb. We want *calculate_ddb* to be a > global hook during the atomic check phase (and we do have that today), > but when we get around to the commit phase and start writing stuff to > hardware, we want to program the per-pipe DDB entries at the same time > we program the WM's and regular plane registers (since they should be > double buffered and flushed out the same way). We just need to make > sure that the order we process pipes in follows the special flushing > rules noted above, which is what my pseudo-patches were trying to > describe. My comments are w.r.t. the scheme where we don't lock down all the crtcs for every DDB update. > > > > > > > > > https://github.com/lyude/linux/tree/wip/skl-fix-wms-v5r2 > > > > > > As for updating inner-pipe ddb allocations for each plane on a pipe, we > > > should be able to just do that at the same time we update each pipe's > > > watermarks > > > > Yes. > > > > None of that changes what I said before though. Either you need to > > lock down everything when the DDB needs to be repartitioned, or you > > do what I outlined in the previous mail. Otherwise a plane update > > etc. happening in parallel will still blow up on account of the DDB > > state changing underneath the plane update somewhere between compute > > and commit. I can't really think
[Intel-gfx] [PATCH v4 0/6] Finally fix watermarks
On Mon, Aug 01, 2016 at 10:48:37AM +0200, Maarten Lankhorst wrote: > Op 29-07-16 om 22:33 schreef Matt Roper: > > On Fri, Jul 29, 2016 at 12:39:05PM +0300, Ville Syrjälä wrote: > >> On Thu, Jul 28, 2016 at 05:03:52PM -0700, Matt Roper wrote: > >>> This is completely untested (and probably horribly broken/buggy), but > >>> here's a quick mockup of the general approach I was thinking for > >>> ensuring DDB & WM's can be updated together while ensuring the > >>> three-step pipe flushing process is honored: > >>> > >>> https://github.com/mattrope/kernel/commits/experimental/lyude_ddb > >>> > >>> Basically the idea is to take note of what's happening to the pipe's DDB > >>> allocation (shrinking, growing, unchanged, etc.) during the atomic check > >>> phase; > >> Didn't look too closely, but I think you can't actually do that unless > >> you lock all the crtcs whenever the number of active pipes is goind to > >> change. Meaning we'd essentially be back to the one-big-modeset-lock > >> apporach, which will cause missed flips and whanot on the other pipes. > >> > >> The alternative I think would consist of: > >> - make sure level 0 watermark never exceeds total_ddb_size/max_pipes, > >> so that a modeset doesn't have to care about the wms for the other > >> pipes not fitting in > > Unfortunately this part is the problem. You might get away with doing > > this on SKL/KBL which only have three planes max per pipe and a large > > (896 block) DDB, but on BXT you have up to four planes (we don't > > actually enable the topmost plane in a full-featured manner just yet, > > but need to soon), yet the total DDB is only 512 blocks. Sadly, the > > platform with more planes was given a smaller DDB... :-( > > We're already in trouble because users that are running setups like 3x > > 4K with most/all planes in use at large sizes can't find level 0 > > watermarks that satisfy their needs and we have to reject the whole > > configuration. If we further limit each pipe's usage to total/maxpipes > > (i.e., 170 blocks per pipe on BXT), then we're going to hit similar > > issues when only driving one or two displays with with all of the planes > > in use, even though we should have had more DDB space to work with. > > > > I guess serious plane usage isn't too common in desktop setups today, > > but it's a very critical feature in the embedded world; we can't really > > afford to cripple plane usage further. Unfortunately, as you point out > > above, this means that we have to follow the bspec's DDB allocation > > method, which in turn means we need to grab _all_ CRTC locks any time > > _any_ CRTC is being turned on or turned off which is a BKL-style way of > > doing things. > Meh, I'm running into a similar issue on vlv/chv. I don't see a way around > it. :( Now are you hitting it w/ vlv/chv? They don't even have a shared DDB. > Only thing we could do is split up the state to make the non-modeset > crtc's complete early. -- Ville Syrjälä Intel OTC
[Bug 96326] Heavy screen flickering in OpenGL apps on R9 390
https://bugs.freedesktop.org/show_bug.cgi?id=96326
--- Comment #8 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> ---
(In reply to Alex Deucher from comment #7)
> (In reply to Jan Ziak from comment #6)
> > (In reply to Alex Deucher from comment #3)
> > > Please attach your xorg log and dmesg output.
> >
> > Upstream Linux kernel does not support variable mclk on R9 390. I enabled
> > variable mclk by patching some code in drivers/gpu/drm/amd/amdgpu/ (mostly
> > ci_dpm.c).
>
> What patch(es) did you use?
I added a function based on ci_dpm_force_state_mclk() in ci_dpm.c.
mask is 0x3.
static int ci_dpm_force_state_mclk_mask(struct amdgpu_device *adev, u32 mask) {
struct ci_power_info *pi = ci_get_pi(adev);
if (!pi->mclk_dpm_key_disabled) {
PPSMC_Result smc_result =
amdgpu_ci_send_msg_to_smc_with_parameter(adev,
PPSMC_MSG_MCLKDPM_SetEnabledMask, mask);
printk("[atomsymbol] %s:%d: mask=0x%X, ok=%d\n", __FUNCTION__,
__LINE__, mask, smc_result == PPSMC_Result_OK);
if (smc_result != PPSMC_Result_OK)
return -EINVAL;
}
return 0;
}
/sys/class/drm/card?/device/power_dpm_force_performance_level is set to "auto".
--
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/20160801/5b45b4e5/attachment-0001.html>
[PATCH v3 09/12] gpu: ipu-v3: Add Video Deinterlacer unit
On 08/01/2016 02:13 AM, Philipp Zabel wrote: > > Please remove the unused headers. I think you can remove all but > export.h, types.h, errno.h, and io.h. > Other than that, the patch now looks fine to me. > I was able to prune all but io.h, the rest is provided by ipu-prv.h. Steve
[Bug 97157] MST displays fail to wake
https://bugs.freedesktop.org/show_bug.cgi?id=97157 --- Comment #1 from Dan Doel --- Created attachment 125465 --> https://bugs.freedesktop.org/attachment.cgi?id=125465=edit dmesg output with drm.debug=0xe Adding (compressed) dmesg output with drm.debug=0xe on the kernel boot line. Careful extracting it, it's 502MB decompressed. Unfortunately, I couldn't seem to make the problem happen faster than over night. Don't know if this will help or not, but it can't hurt, I suppose. -- 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/20160801/856a9152/attachment.html>
[Bug 96326] Heavy screen flickering in OpenGL apps on R9 390
https://bugs.freedesktop.org/show_bug.cgi?id=96326 --- Comment #7 from Alex Deucher --- (In reply to Jan Ziak from comment #6) > (In reply to Alex Deucher from comment #3) > > Please attach your xorg log and dmesg output. > > Upstream Linux kernel does not support variable mclk on R9 390. I enabled > variable mclk by patching some code in drivers/gpu/drm/amd/amdgpu/ (mostly > ci_dpm.c). What patch(es) did you use? > > dmesg output contains some logging messages I added to my copy of Linux > kernel source code. > > > What resolution and refresh rate are you using on your monitor? > > 1920x1080 60Hz > > > Also are you using radeon or amdgpu? > > Currently amdgpu.ko, radeon.ko in the past. -- 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/20160801/86c8d3ea/attachment.html>
[PATCH] drm/ast: Fix incorrect memory size detection with analog VGA
On mainboards with analog VGA output the memory size is incorrectly
detected due to an invalid register probe. This leads to a corrupted
and unusable framebuffer on the analog VGA output.
Do not probe the DP501-related VGA scratch register if the DP501
device was not detected.
Tested-on: ASUS KGPE-D16 (AST2050) w/ 8MB VRAM.
Signed-off-by: Timothy Pearson
---
drivers/gpu/drm/ast/ast_main.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 7bc3aa6..090b571 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -372,17 +372,19 @@ static u32 ast_get_vram_info(struct drm_device *dev)
case 3: vram_size = AST_VIDMEM_SIZE_64M; break;
}
- jreg = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0x99, 0xff);
- switch (jreg & 0x03) {
- case 1:
- vram_size -= 0x10;
- break;
- case 2:
- vram_size -= 0x20;
- break;
- case 3:
- vram_size -= 0x40;
- break;
+ if (ast->tx_chip_type == AST_TX_DP501) {
+ jreg = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0x99,
0xff);
+ switch (jreg & 0x03) {
+ case 1:
+ vram_size -= 0x10;
+ break;
+ case 2:
+ vram_size -= 0x20;
+ break;
+ case 3:
+ vram_size -= 0x40;
+ break;
+ }
}
return vram_size;
--
2.8.1
[PATCH v3 10/12] gpu: ipu-v3: Add FSU channel linking support
On 08/01/2016 02:13 AM, Philipp Zabel wrote: > Am Sonntag, den 31.07.2016, 12:42 -0700 schrieb Steve Longerbeam: >> Adds functions to link and unlink source channels to sink >> channels in the FSU: >> >> int ipu_fsu_link(struct ipu_soc *ipu, int src_ch, int sink_ch); >> int ipu_fsu_unlink(struct ipu_soc *ipu, int src_ch, int sink_ch); >> >> The channels numbers are usually IDMAC channels, but they can also be >> channels that do not transfer data to or from memory. The following >> convenience functions can be used in place of ipu_fsu_link/unlink() >> when both source and sink channels are IDMAC channels: >> >> int ipu_idmac_link(struct ipuv3_channel *src, struct ipuv3_channel *sink); >> int ipu_idmac_unlink(struct ipuv3_channel *src, struct ipuv3_channel *sink); >> >> So far the following links are supported: >> >> IPUV3_CHANNEL_IC_PRP_ENC_MEM -> IPUV3_CHANNEL_MEM_ROT_ENC >> PUV3_CHANNEL_IC_PRP_VF_MEM -> IPUV3_CHANNEL_MEM_ROT_VF >> IPUV3_CHANNEL_IC_PP_MEM -> IPUV3_CHANNEL_MEM_ROT_PP >> IPUV3_CHANNEL_CSI_DIRECT -> IPUV3_CHANNEL_CSI_VDI_PREV > Looks good to me, thanks. Are you sure though that the target of the CSI > direct channel is VDI_PREV? I would have assumed the CSI input is fed > into VDI_NEXT, while CUR and PREV are read from memory. Reprinting from the TRM: 37.4.11.4 Real Time Mode In Real Time Mode the F(n-1) are coming from CSI. The CSI write to FIFO1. The DI sub-block read F(n-1) from processing. In addition IDMAC read the field from FIFO1 and store in external memory. Then stored frames are used as F(n) and F(n+1). Steve
Re: [PATCH V3 2/5] dts/imx6q-b850v3: Configure IPU assignment order
Hi Lucas,
Thank you for the prompt review.
On Monday, August 1, 2016 10:54 CEST, Lucas Stach
wrote:
> Am Sonntag, den 31.07.2016, 21:55 +0200 schrieb Peter Senna Tschudin:
> > As the IPU has combined limitations across multiple crtcs, and as that
> > can't be communicated to userspace at the moment, reorder the crtcs to
> > allow support to two Full-HD monitors by avoiding assigning two
> > monitors to a single IPU.
> >
> > Cc: Enric Balletbo i Serra
> > Cc: Philipp Zabel
> > Cc: Rob Herring
> > Cc: Fabio Estevam
> > Signed-off-by: Peter Senna Tschudin
>
> NACK. This is a userspace issue. Changing the assignment order of the
> CRTCs just shifts the failure to a userspace that want to use CRTC 0 and
> 2 now.
Err, yeah user space issue... But how the kernel is currently telling user
space about what exactly went wrong and how user space might fix it? How
Weston(our user space) is going to know that reshuffling crtcs is going to
lead to success; how could it? I guess some platform-specific code in user
space is needed for this to work...
>
> imx-drm just got atomic support and with the atomic check it should be
> possible to inform userspace in a reasonable way about such issues.
Should be possible, but I guess it isn't, and wont be until a considerable
effort is put on both kernel and user space. Or am I missing something? What do
you propose?
I got inspiration from: arch/arm/boot/dts/imx6q.dtsi
...
display-subsystem {
compatible = "fsl,imx-display-subsystem";
ports = <_di0>, <_di1>, <_di0>, <_di1>;
};
...
This is there for more than 2 years now, and I get that the idea here is not
ordering, but just declaring.
However even if this patch is not the perfect solution, it allows us to stay
close to upstream now without creating problems(does it create any issue?).
Can you reconsider or propose a concrete solution that is not more complex than
our entire driver?
Thanks a lot!
[PATCH -next] drm/amdgpu: use kmemdup rather than duplicating its implementation
On 29.07.2016 20:38, Deucher, Alexander wrote: >> -Original Message- >> From: Sean Paul [mailto:seanpaul at google.com] >> Sent: Friday, July 29, 2016 3:35 PM >> To: Wei Yongjun >> Cc: Deucher, Alexander; Koenig, Christian; Dave Airlie; Jiang, Sonny; Liu, >> Leo; >> Nath, Arindam; Zhou, David(ChunMing); Zhou, Jammy; Liu, Monk; dri-devel; >> Linux Kernel Mailing List >> Subject: Re: [PATCH -next] drm/amdgpu: use kmemdup rather than >> duplicating its implementation >> >> On Thu, Jul 28, 2016 at 12:18 PM, Wei Yongjun wrote: >>> Use kmemdup rather than duplicating its implementation. >>> >>> Generated by: scripts/coccinelle/api/memdup.cocci >>> >>> Signed-off-by: Wei Yongjun >> >> >> Thanks for the patch. I'll apply this to -misc once the merge window is >> closed. >> >> Acked-by: Sean Paul > > Unless you've already applied this to the misc tree, I'd prefer to take it > via the amdgpu tree. I recall Christian NAKing an almost identical patch some time ago. Something about needing memcpy_fromio()? Yup, it's here: https://lkml.org/lkml/2016/5/19/235 Cheers, Nicolai > > Alex > >> >> >>> --- >>> drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 4 +--- >>> 1 file changed, 1 insertion(+), 3 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c >>> index a46a64c..b779b5f 100644 >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c >>> @@ -296,12 +296,10 @@ int amdgpu_uvd_suspend(struct amdgpu_device >> *adev) >>> size = amdgpu_bo_size(adev->uvd.vcpu_bo); >>> ptr = adev->uvd.cpu_addr; >>> >>> - adev->uvd.saved_bo = kmalloc(size, GFP_KERNEL); >>> + adev->uvd.saved_bo = kmemdup(ptr, size, GFP_KERNEL); >>> if (!adev->uvd.saved_bo) >>> return -ENOMEM; >>> >>> - memcpy(adev->uvd.saved_bo, ptr, size); >>> - >>> return 0; >>> } >>> >>> >>> >>> > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel >
[PATCH v3 01/12] gpu: ipu-cpmem: Add ipu_cpmem_set_uv_offset()
On 08/01/2016 02:13 AM, Philipp Zabel wrote: > Am Sonntag, den 31.07.2016, 12:42 -0700 schrieb Steve Longerbeam: >> Adds ipu_cpmem_set_uv_offset(), to set planar U/V offsets. >> >> Signed-off-by: Steve Longerbeam > There is no need to resend already applied patches. > Ok, I wasn't sure whether to include or not, you said you applied these, should have read that as an implicit Ack. Steve
[Bug 97166] lockup during gameplay of Batman series of games
https://bugs.freedesktop.org/show_bug.cgi?id=97166 Bug ID: 97166 Summary: lockup during gameplay of Batman series of games Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: farmboy0+freedesktop at googlemail.com QA Contact: dri-devel at lists.freedesktop.org The games in question are: Batman Arkham Asylum GotY Edition Batman Arkham City GotY Edition Batman Arkham Origins The lockups are kind of random but happen not long after playing one of the games. I have tried the nine tracker and CSMT with opengl. Both exhibit the problem. I tried different kernel versions and also the andgpu-pro module and the lockup always happens. The lockups dont happen with Catalyst 15.12 and wine CSMT. There is never anything in dmesg or the X.org log. Hardware is: 001:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Amethyst XT [Radeon R9 M295X Mac Edition] [1002:6938] (rev f1) Subsystem: PC Partner Limited / Sapphire Technology Amethyst XT [Radeon R9 M295X Mac Edition] [174b:e308] Kernel driver in use: amdgpu I am using LLVM git and Mesa git. -- 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/20160801/6c955ee4/attachment.html>
[RFC 0/3] drm: Add DRM text mode
Den 30.07.2016 17:48, skrev Noralf Trønnes:
>
> Den 29.07.2016 10:23, skrev Daniel Vetter:
>> Actually adding David.
>> -Daniel
>>
>> On Fri, Jul 29, 2016 at 10:20:51AM +0200, Daniel Vetter wrote:
>>> On Thu, Jul 28, 2016 at 04:15:04PM +0200, Noralf Trønnes wrote:
This patchset explores the idea of adding a DRM text mode
(like VGA text mode) to get an alternative to fbcon/fbdev.
David Hermann has done alot of work on a fbcon replacement:
- drm: add kernel-log renderer (Mar 2014)[1]
- kmscon:
development started Nov 2011
added to systemd Oct 2014
removed from systemd Jul 2015[2]
Since this work seems to have stalled, I propose an alternative
solution
to this problem that will also give VT console support while we're
waiting
for a userspace console.
The idea is that the driver provides a modeset like with the fbdev
emulation
code, and from this a text buffer representation is made. The
console code
can now write to this text buffer and ask for the text buffer to be
flushed/rendered to the pixel buffer.
In this hack/implementation of the idea, I have just hijacked a CMA
backed
fbdev framebuffer to keep it simple.
I have reused the default buffer format that VT uses.
Getting panic handling to actually work, seems to be a challenge as
Daniel
describes on the DRMJanitors page[3].
Is this idea of a DRM text mode worth developing further?
>>> I guess some simpler drm console with vt support which would allow
>>> us to
>>> get rid of fbdev could make sense. And there's definitely going to be a
>>> lot of overlap with a full userspace solution using something like
>>> kmscon.
>>>
>>> But we can't just add a new drm text console, there's a pile of prep
>>> work
>>> needed that David started for either approach:
>>> - Nuking fbdev means no more fbdev drivers for firmware consoles
>>> (uboot,
>>>uefi, vga, ...). The simpledrm driver would cover this, would be
>>> great
>>>to get that landed (especially now that we have the simple pipe
>>>helpers!).
>
> I have rebased simpledrm on drm_simple_display_pipe and have it
> working on
> a Raspberry Pi. modetest gives me a wrong picture, but that is probably
> because of some wrong format conversion since fbdev using the native
> rgb565 format works fine.
>
> I could finish this up and send a patch unless David is working on
> something?
>
> I have used this version of simpledrm: [PATCH 09/11] drm: add
> SimpleDRM driver
> https://lists.freedesktop.org/archives/dri-devel/2014-January/052594.html
>
I have solved the format conversion problem.
Is there any reason why simpledrm can't use drm_gem_cma_helper?
This is how it allocates memory:
int sdrm_gem_get_pages(struct sdrm_gem_object *obj)
{
[...]
num = obj->base.size >> PAGE_SHIFT;
obj->pages = drm_malloc_ab(num, sizeof(*obj->pages));
[...]
for (i = 0; i < num; ++i) {
obj->pages[i] = alloc_page(GFP_KERNEL | __GFP_ZERO);
[...]
obj->vmapping = vmap(obj->pages, num, 0, PAGE_KERNEL);
[...]
}
The simpledrm driver has this set_config:
static int sdrm_crtc_set_config(struct drm_mode_set *set)
{
struct drm_device *ddev;
struct sdrm_device *sdrm;
struct sdrm_framebuffer *fb;
[...]
ddev = set->crtc->dev;
sdrm = ddev->dev_private;
[...]
fb = to_sdrm_fb(set->fb);
[...]
if (set->mode->hdisplay != sdrm->fb_width ||
set->mode->vdisplay != sdrm->fb_height)
return -EINVAL;
if (fb->base.width <= set->x ||
fb->base.height <= set->y ||
fb->base.width - set->x < sdrm->fb_width ||
fb->base.height - set->y < sdrm->fb_height)
return -EINVAL;
[...]
}
Do I need to perform any of these checks in the new check function?
And if so, how?
static int sdrm_display_pipe_check(struct drm_simple_display_pipe *pipe,
struct drm_plane_state *plane_state,
struct drm_crtc_state *crtc_state)
{
struct sdrm_device *sdrm = pipe_to_sdrm(pipe);
return 0;
}
Noralf.
[PATCH V3 1/5] drm/imx-ldb: Add support to drm-bridge
Am Sonntag, den 31.07.2016, 21:55 +0200 schrieb Peter Senna Tschudin:
> Add support to attach a drm_bridge to imx-ldb in addition to
> existing support to attach a LVDS panel.
>
> This patch does a simple code refactoring by moving code
> from for_each_child_of_node iterator to a new function named
> imx_ldb_panel_ddc(). This was necessary to allow the panel ddc
> code to run only when the imx_ldb is not attached to a bridge.
>
> Cc: Enric Balletbo i Serra
> Cc: Philipp Zabel
> Cc: Rob Herring
> Cc: Fabio Estevam
> Cc: David Airlie
> Cc: Thierry Reding
> Cc: Thierry Reding
> Signed-off-by: Peter Senna Tschudin
> ---
> Changes from V2:
> - Updated to be aplied on top of Liu Ying changes that made imx-ldb atomic.
> - Tested on next-20160729.
[...]
> @@ -469,19 +473,28 @@ static int imx_ldb_register(struct drm_device *drm,
> drm_encoder_init(drm, encoder, _ldb_encoder_funcs,
>DRM_MODE_ENCODER_LVDS, NULL);
>
> - drm_connector_helper_add(_ldb_ch->connector,
> - _ldb_connector_helper_funcs);
> - drm_connector_init(drm, _ldb_ch->connector,
> -_ldb_connector_funcs, DRM_MODE_CONNECTOR_LVDS);
> -
> if (imx_ldb_ch->panel) {
> + drm_connector_helper_add(_ldb_ch->connector,
> + _ldb_connector_helper_funcs);
> + drm_connector_init(drm, _ldb_ch->connector,
> + _ldb_connector_funcs,
> + DRM_MODE_CONNECTOR_LVDS);
This is still not right. We want to add the connector whenever there is
no bridge that brings its own, not only when there is a panel. For
historical reasons, the ldb driver can also work without a panel.
> ret = drm_panel_attach(imx_ldb_ch->panel,
> -_ldb_ch->connector);
> + _ldb_ch->connector);
What is the purpose of this change?
> if (ret)
> return ret;
> }
>
> - drm_mode_connector_attach_encoder(_ldb_ch->connector, encoder);
Where is this gone?
> + if (imx_ldb_ch->bridge) {
> + imx_ldb_ch->bridge->encoder = encoder;
> +
> + imx_ldb_ch->encoder.bridge = imx_ldb_ch->bridge;
> + ret = drm_bridge_attach(drm, imx_ldb_ch->bridge);
> + if (ret) {
> + DRM_ERROR("Failed to initialize bridge with drm\n");
> + return ret;
> + }
> + }
>
> return 0;
> }
regards
Philipp
[Bug 97122] list of 12 dEQP-GLES2 tests causing systematic GPU lockups
https://bugs.freedesktop.org/show_bug.cgi?id=97122 --- Comment #4 from Nicolai Hähnle --- Hi Mauro, thanks for the report - sounds like a control flow lowering bug. Note that the 'nosb' option will have no effect, it applies to r600 only. Which version of LLVM are you using? glxinfo shows this. Does the lockup happen with LLVM trunk? -- 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/20160801/64d3d0d8/attachment.html>
[PATCH V3 3/5] Documentation/devicetree/bindings: b850v3_lvds_dp
On Sun, Jul 31, 2016 at 09:55:36PM +0200, Peter Senna Tschudin wrote: > Devicetree bindings documentation for the GE B850v3 LVDS/DP++ > display bridge. > > Cc: Javier Martinez Canillas > Cc: Enric Balletbo i Serra > Cc: Philipp Zabel > Cc: Rob Herring > Cc: Fabio Estevam > Signed-off-by: Peter Senna Tschudin > --- > Unchanged from V2. > > Changes from V1: > - Replaced '_' by '-' in node names or compatible strings > - Added missing @73 to the example > > .../devicetree/bindings/ge/b850v3-lvds-dp.txt | 37 > ++ > 1 file changed, 37 insertions(+) > create mode 100644 Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt Acked-by: Rob Herring
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #142 from Marek Olšák --- I've seen plenty of GPU hangs with XCOM: Enemy Within. It's basically the same game with a little more content, but not much. The reproducibility is random. The hangs usually happen between 1 minutes and 8 hours. In my case, this is the data I've been able to obtain: - Reproduced on everything I was testing on: Hawaii (radeon), Tonga, Polaris11 (amdgpu) - It occurs with many different shaders, among which there are a few very simple ones. (no scratch or spills, a few ifs, no loops) - Disabling HyperZ has no effect. - Disabling CE has no effect. - VM faults never occur. - The hangs don't seem to have anything in common. Action items: - Reproduce the hang and do a hardware scan dump (it can only be done in the AMD office AFAIK), and send it to hardware teams. -- 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/20160801/0d1c0f57/attachment.html>
[PATCH v2 11/13] gpu: ipu-ic: Add complete image conversion support with tiling
Am Donnerstag, den 28.07.2016, 16:09 -0700 schrieb Steve Longerbeam: > > Now split the frame in half and suddenly pixel x' = 640 is the start of > > a new tile, so it is sampled at x = 160, and pixel x' = 1279 will be > > sampled at x = 160 + (1279 - 640) * 8192/32846. = 319.37, reading over > > the edge of the source image. > > Here's where we part. > > The 320x200 --> 1280x800 conversion is split into two 160x200 --> > 640x800 conversions. The DMA controller and ipu_ic_task_init() are given > those width/height dimensions, not the dimensions of the original images. > So this is simply two separate 160x200 --> 640x800 conversions. The only > difference from a true 160x200 --> 640x800 image conversion is that the DMA > controller must be given the stride lengths of the original 320x200 and > 1280x800 > images. > > The rsc for the 160x200 --> 640x800 conversions is > > x = x' * (160-1)/(640-1) = x' * 8192/rsc, so rsc = 32923 > > > So original horizontal position 640 is really x' = 0 of the second > conversion, > which is sampled at x = 0 of the second conversion. And the pixel at x' > = 1279 > is really x' = 639 of the second conversion, which is sampled at x = 639 > * 8192/32923 > = 158.98, which does not read over the edge of the source tile. My bad, I somehow thought that the scaling factor is calculated per image (as it IMHO should be), not just per tile. Of course in that case you won't ever read over the edge, but on the other hand the visual problems are worse because you underestimate the scaling factor and introduce a sharp edge at the center: even if the source pixel step per target pixel step is a fraction, between pixels width/2-1 and width/2 there's always a whole source pixel step. Take the extreme example of scaling 32x32 to 1080x1080 pixels. The ideal source pixels for x' = 519 and 520 should be x = 14.911 and 14.939, respectively. Due to tiling they will be x = 15 and 16, introducing a sharp seam in the otherwise blurry mess. > > This problem gets worse if you start using arbitrary frame sizes and YUV > > planar images and consider that tile start addresses are (currently) > > limited to 8 byte boundaries, to the point that there are very visible > > seams in the center of the image, depending on scaling factor and image > > sizes. > > Indeed there could be other parameters that would cause the resizer to > read past the edge of the source tiles, I will need to try and find such > cases. > But not in the above case. Ok. > That said, I _have_ noticed seams, but I have always attributed them to the > fact that we have a discontinuity in color-space conversion and/or resize > interpolation at the boundary between tiles. > > I've also found that the seams are quite noticeable when rendered to a > display overlay, but become significantly less pronounced if the images are > converted to a back buffer, and then page-flipped to front buffer when the > conversion (all tiles) completes. I don't know what to make of this. Maybe it is a timing issue and what you are actually seeing is tearing between tiles of different frames? regards Philipp
[PATCH] drm/analogix_dp: Ensure the panel is properly prepared/unprepared
Sean,
On 07/30/2016 03:16 AM, Sean Paul wrote:
> Instead of just preparing the panel on bind, actually prepare/unprepare
> during modeset/disable. The panel must be prepared in order to read hpd
> status, so we need to refcount the prepares in order to ensure we don't
> accidentally turn the panel off at the wrong time.
>
> Signed-off-by: Sean Paul
> ---
>
>
> Hi Yakir,
> This is what I was talking about upthread. I've tested it and it seems to be
> working.
>
> What do you think?
Thanks for your patch, and it works. But I have introduced two
questions, and I haven't found a way to fixed them.
> Sean
>
>
>
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 48 +-
> 1 file changed, 37 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 32715da..7b764a4 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -960,11 +960,27 @@ enum drm_connector_status
> analogix_dp_detect(struct drm_connector *connector, bool force)
> {
> struct analogix_dp_device *dp = to_dp(connector);
> + enum drm_connector_status status = connector_status_disconnected;
> + int ret;
>
> - if (analogix_dp_detect_hpd(dp))
> - return connector_status_disconnected;
> + if (dp->plat_data->panel && dp->dpms_mode != DRM_MODE_DPMS_ON) {
> + ret = drm_panel_prepare(dp->plat_data->panel);
> + if (ret) {
> + DRM_ERROR("failed to setup panel (%d)\n", ret);
> + return connector_status_disconnected;
> + }
> + }
> +
> + if (!analogix_dp_detect_hpd(dp))
> + status = connector_status_connected;
> +
> + if (dp->plat_data->panel && dp->dpms_mode != DRM_MODE_DPMS_ON) {
> + ret = drm_panel_unprepare(dp->plat_data->panel);
> + if (ret)
> + DRM_ERROR("failed to setup the panel ret = %d\n", ret);
> + }
>
> - return connector_status_connected;
> + return status;
1. Panel would flicker at system boot time. Your patch would flash the
panel power in connector->detect() function when dp->dpms_mode isn't
DRM_MODE_DPMS_OFF. So when userspace keep detect the connector status in
boot time, we could see panel would flicker (light up for a while, and
turn off again, and keep loop for several time). I have copied some
kernel logs:
[ 11.065267] YKK - analogix_dp_detect:1052
[ 11.729596] YKK - analogix_dp_get_modes:1016
[ 11.737608] rockchip-dp ff97.edp:
analogix_dp_read_bytes_from_dpcd: Aux Transaction fail!
[ 11.749229] rockchip-dp ff97.edp:
analogix_dp_read_bytes_from_dpcd: Aux Transaction fail!
[ 11.760799] rockchip-dp ff97.edp:
analogix_dp_read_bytes_from_dpcd: Aux Transaction fail!
[ 13.315962] YKK - analogix_dp_detect:1052
[ 13.984702] YKK - analogix_dp_get_modes:1016
[ 13.992977] rockchip-dp ff97.edp:
analogix_dp_read_bytes_from_dpcd: Aux Transaction fail!
[ 14.004414] rockchip-dp ff97.edp:
analogix_dp_read_bytes_from_dpcd: Aux Transaction fail!
[ 14.015842] rockchip-dp ff97.edp:
analogix_dp_read_bytes_from_dpcd: Aux Transaction fail!
[ 14.183109] YKK - analogix_dp_bridge_pre_enable:1147
[ 14.306301] rockchip-dp ff97.edp: Link Training Clock Recovery
success
[ 14.319130] rockchip-dp ff97.edp: Link Training success!
[ 14.326388] rockchip-dp ff97.edp: wait SYS_CTL_2.
[ 14.437247] rockchip-dp ff97.edp: Timeout of video streamclk ok
[ 14.443585] rockchip-dp ff97.edp: unable to config video
> }
>
> static void analogix_dp_connector_destroy(struct drm_connector *connector)
> @@ -1035,6 +1051,18 @@ static int analogix_dp_bridge_attach(struct drm_bridge
> *bridge)
> return 0;
> }
>
> +static void analogix_dp_bridge_pre_enable(struct drm_bridge *bridge)
> +{
> + struct analogix_dp_device *dp = bridge->driver_private;
> + int ret;
> +
> + if (dp->plat_data->panel) {
> + ret = drm_panel_prepare(dp->plat_data->panel);
> + if (ret)
> + DRM_ERROR("failed to setup the panel ret = %d\n", ret);
> + }
2. Driver would failed to read EDID in some case. Panel would only be
powered up in bridge->pre_enable() function which later than
connector->get_modes() function, and this would caused DPCD transfer
failed in analogix_dp_handle_edid(). This seem won't caused too big
issue, cause userspace would read EDID again after bridge/encoder is
enabled. But it's better to avoid this potential bug.
[ 11.065267] YKK - analogix_dp_detect:1052
[ 11.729596] YKK - analogix_dp_get_modes:1016
[ 11.737608] rockchip-dp ff97.edp:
analogix_dp_read_bytes_from_dpcd: Aux Transaction fail!
[ 11.749229] rockchip-dp ff97.edp:
[PATCH] drm/analogix_dp: Ensure the panel is properly prepared/unprepared
Sean,
On 07/30/2016 03:16 AM, Sean Paul wrote:
> Instead of just preparing the panel on bind, actually prepare/unprepare
> during modeset/disable. The panel must be prepared in order to read hpd
> status, so we need to refcount the prepares in order to ensure we don't
> accidentally turn the panel off at the wrong time.
>
> Signed-off-by: Sean Paul
> ---
>
>
> Hi Yakir,
> This is what I was talking about upthread. I've tested it and it seems to be
> working.
>
> What do you think?
Thanks for your patch, and it works. But I have introduced two
questions, and I haven't found a way to fixed them.
> Sean
>
>
>
> drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 48 +-
> 1 file changed, 37 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 32715da..7b764a4 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -960,11 +960,27 @@ enum drm_connector_status
> analogix_dp_detect(struct drm_connector *connector, bool force)
> {
> struct analogix_dp_device *dp = to_dp(connector);
> + enum drm_connector_status status = connector_status_disconnected;
> + int ret;
>
> - if (analogix_dp_detect_hpd(dp))
> - return connector_status_disconnected;
> + if (dp->plat_data->panel && dp->dpms_mode != DRM_MODE_DPMS_ON) {
> + ret = drm_panel_prepare(dp->plat_data->panel);
> + if (ret) {
> + DRM_ERROR("failed to setup panel (%d)\n", ret);
> + return connector_status_disconnected;
> + }
> + }
> +
> + if (!analogix_dp_detect_hpd(dp))
> + status = connector_status_connected;
> +
> + if (dp->plat_data->panel && dp->dpms_mode != DRM_MODE_DPMS_ON) {
> + ret = drm_panel_unprepare(dp->plat_data->panel);
> + if (ret)
> + DRM_ERROR("failed to setup the panel ret = %d\n", ret);
> + }
>
> - return connector_status_connected;
> + return status;
1. Panel would flicker at system boot time. Your patch would flash the
panel power in connector->detect() function when dp->dpms_mode isn't
DRM_MODE_DPMS_OFF. So when userspace keep detect the connector status in
boot time, we could see panel would flicker (light up for a while, and
turn off again, and keep loop for several time). I have copied some
kernel logs:
[ 11.065267] YKK - analogix_dp_detect:1052
[ 11.729596] YKK - analogix_dp_get_modes:1016
[ 11.737608] rockchip-dp ff97.edp:
analogix_dp_read_bytes_from_dpcd: Aux Transaction fail!
[ 11.749229] rockchip-dp ff97.edp:
analogix_dp_read_bytes_from_dpcd: Aux Transaction fail!
[ 11.760799] rockchip-dp ff97.edp:
analogix_dp_read_bytes_from_dpcd: Aux Transaction fail!
[ 13.315962] YKK - analogix_dp_detect:1052
[ 13.984702] YKK - analogix_dp_get_modes:1016
[ 13.992977] rockchip-dp ff97.edp:
analogix_dp_read_bytes_from_dpcd: Aux Transaction fail!
[ 14.004414] rockchip-dp ff97.edp:
analogix_dp_read_bytes_from_dpcd: Aux Transaction fail!
[ 14.015842] rockchip-dp ff97.edp:
analogix_dp_read_bytes_from_dpcd: Aux Transaction fail!
[ 14.183109] YKK - analogix_dp_bridge_pre_enable:1147
[ 14.306301] rockchip-dp ff97.edp: Link Training Clock Recovery
success
[ 14.319130] rockchip-dp ff97.edp: Link Training success!
[ 14.326388] rockchip-dp ff97.edp: wait SYS_CTL_2.
[ 14.437247] rockchip-dp ff97.edp: Timeout of video streamclk ok
[ 14.443585] rockchip-dp ff97.edp: unable to config video
> }
>
> static void analogix_dp_connector_destroy(struct drm_connector *connector)
> @@ -1035,6 +1051,18 @@ static int analogix_dp_bridge_attach(struct drm_bridge
> *bridge)
> return 0;
> }
>
> +static void analogix_dp_bridge_pre_enable(struct drm_bridge *bridge)
> +{
> + struct analogix_dp_device *dp = bridge->driver_private;
> + int ret;
> +
> + if (dp->plat_data->panel) {
> + ret = drm_panel_prepare(dp->plat_data->panel);
> + if (ret)
> + DRM_ERROR("failed to setup the panel ret = %d\n", ret);
> + }
2. Driver would failed to read EDID in some case. Panel would only be
powered up in bridge->pre_enable() function which later than
connector->get_modes() function, and this would caused DPCD transfer
failed in analogix_dp_handle_edid(). This seem won't caused too big
issue, cause userspace would read EDID again after bridge/encoder is
enabled. But it's better to avoid this potential bug.
[ 11.065267] YKK - analogix_dp_detect:1052
[ 11.729596] YKK - analogix_dp_get_modes:1016
[ 11.737608] rockchip-dp ff97.edp:
analogix_dp_read_bytes_from_dpcd: Aux Transaction fail!
[ 11.749229] rockchip-dp ff97.edp:
[PATCH 0/7] drm/mediatek: cleaning up and refine
On Fri, Jul 29, 2016 at 5:04 AM, Bibby Hsieh wrote: > These patches based on 4.7-rc1 to clean up unused function & variable > and use drm core function instead. > > The following patches are needed to cleanly apply on top of v4.7-rc1: > - https://patchwork.kernel.org/patch/8044001/ >(drm: Deal with rotation in drm_plane_helper_check_update()) > - https://patchwork.kernel.org/patch/9248373/ >(drm: Warn about negative sizes when calculating scale factor) > - https://patchwork.kernel.org/patch/9248371/ >(drm: Store clipped src/dst coordinatee in drm_plane_state) > - https://patchwork.kernel.org/patch/9248363/ >(drm/plane-helper: Add drm_plane_helper_check_state()) > - https://patchwork.kernel.org/patch/9248361/ >(drm/mediatek: Use drm_plane_helper_check_state()) > > Bibby Hsieh (2): > drm/mediatek: Use drm_atomic destroy_state helpers > drm/mediatek: Fix mtk_atomic_complete for runtime_pm > > Daniel Kurtz (5): > drm/mediatek: Remove mtk_drm_crtc_check_flush > drm/mediatek: plane: Remove plane zpos/index > drm/mediatek: Remove mtk_drm_plane > drm/mediatek: plane: Merge mtk_plane_enable into > mtk_plane_atomic_update > drm/mediatek: plane: Use FB's format's cpp to compute x offset > The whole set looks good to me. Reviewed-by: Sean Paul > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 21 > drivers/gpu/drm/mediatek/mtk_drm_crtc.h |1 - > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 17 ++- > drivers/gpu/drm/mediatek/mtk_drm_plane.c | 80 > +++--- > drivers/gpu/drm/mediatek/mtk_drm_plane.h | 15 +- > 5 files changed, 56 insertions(+), 78 deletions(-) > > -- > 1.7.9.5 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 10/12] gpu: ipu-v3: Add FSU channel linking support
Am Sonntag, den 31.07.2016, 12:42 -0700 schrieb Steve Longerbeam: > Adds functions to link and unlink source channels to sink > channels in the FSU: > > int ipu_fsu_link(struct ipu_soc *ipu, int src_ch, int sink_ch); > int ipu_fsu_unlink(struct ipu_soc *ipu, int src_ch, int sink_ch); > > The channels numbers are usually IDMAC channels, but they can also be > channels that do not transfer data to or from memory. The following > convenience functions can be used in place of ipu_fsu_link/unlink() > when both source and sink channels are IDMAC channels: > > int ipu_idmac_link(struct ipuv3_channel *src, struct ipuv3_channel *sink); > int ipu_idmac_unlink(struct ipuv3_channel *src, struct ipuv3_channel *sink); > > So far the following links are supported: > > IPUV3_CHANNEL_IC_PRP_ENC_MEM -> IPUV3_CHANNEL_MEM_ROT_ENC > PUV3_CHANNEL_IC_PRP_VF_MEM -> IPUV3_CHANNEL_MEM_ROT_VF > IPUV3_CHANNEL_IC_PP_MEM -> IPUV3_CHANNEL_MEM_ROT_PP > IPUV3_CHANNEL_CSI_DIRECT -> IPUV3_CHANNEL_CSI_VDI_PREV Looks good to me, thanks. Are you sure though that the target of the CSI direct channel is VDI_PREV? I would have assumed the CSI input is fed into VDI_NEXT, while CUR and PREV are read from memory. regards Philipp
[PATCH v3 09/12] gpu: ipu-v3: Add Video Deinterlacer unit
Am Sonntag, den 31.07.2016, 12:42 -0700 schrieb Steve Longerbeam: > Adds the Video Deinterlacer (VDIC) unit. > > Signed-off-by: Steve Longerbeam > > --- > > v3: > - renamed and exported ipu_vdi_set_top_field_man() to > ipu_vdi_set_field_order(). Args include std and field to determine > correct field order. > - exported ipu_vdi_set_motion(). > - ipu_vdi_setup() does not need to call ipu_vdi_set_top_field_man() or > ipu_vdi_set_motion(), since latter are exported. This simplifies args. > - removed ipu_vdi_toggle_top_field_man(). > - removed ipu_vdi_set_src(). [...] > --- /dev/null > +++ b/drivers/gpu/ipu-v3/ipu-vdi.c > @@ -0,0 +1,254 @@ > +/* > + * Copyright (C) 2012-2016 Mentor Graphics Inc. > + * Copyright (C) 2005-2009 Freescale Semiconductor, Inc. > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License as published by the > + * Free Software Foundation; either version 2 of the License, or (at your > + * option) any later version. > + * > + * This program is distributed in the hope that it will be useful, but > + * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY > + * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * for more details. > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include Please remove the unused headers. I think you can remove all but export.h, types.h, errno.h, and io.h. Other than that, the patch now looks fine to me. regards Philipp
[PATCH v3 01/12] gpu: ipu-cpmem: Add ipu_cpmem_set_uv_offset()
Am Sonntag, den 31.07.2016, 12:42 -0700 schrieb Steve Longerbeam: > Adds ipu_cpmem_set_uv_offset(), to set planar U/V offsets. > > Signed-off-by: Steve Longerbeam There is no need to resend already applied patches. regards Philipp
[PATCH 0/9] drm: Store clipped coordinates in drm_plane_state
On Tue, Jul 26, 2016 at 12:06 PM, wrote:
> From: Ville Syrjälä
>
> Moving the clipped plane coordinates into drm_plane_state has been
> discussed a few times, but as no patches seems to have materialized,
> I decoded to do it myself. I also added a new helper function
> like drm_plane_helper_check_update() that takes a plane state instead.
>
> I converted i915, rockchip, and mediatek over to the new stuff. rockchip
> already looked pretty solid, mediatek had some bugs in there that I
> hopefully fixed. The rest of the non-x86 drivers seem to entirely lack
> any plane clipping code, so I decided that I don't care enough to
> write it from scratch. I also converted drm_simple_kms_helper, but
> there are no drivers using it so far.
>
> I've only actually tested i915, the rest are just compile tested.
>
> Entire series available here:
> git://github.com/vsyrjala/linux.git plane_state_rects
>
> Ville Syrjälä (9):
> drm: Warn about negative sizes when calculating scale factor
> drm: Store clipped src/dst coordinatee in drm_plane_state
> drm/plane-helper: Add drm_plane_helper_check_state()
> drm/i915: Use drm_plane_state.{src,dst,visible}
> drm/i915: Use drm_plane_helper_check_state()
> drm/rockchip: Use drm_plane_state.{src,dst}
> drm/rockchip: Use drm_plane_helper_check_state()
> drm/mediatek: Use drm_plane_helper_check_state()
> drm/simple_kms_helper: Use drm_plane_helper_check_state()
Looks good to me, all patches have been reviewed.
It seems like the only consumer of drm_plane_helper_check_update()
left is armada. Are you planning on converting it as well? Then we can
nuke the function.
Sean
>
> drivers/gpu/drm/drm_plane_helper.c | 136 +--
> drivers/gpu/drm/drm_rect.c | 2 +-
> drivers/gpu/drm/drm_simple_kms_helper.c | 27 ++
> drivers/gpu/drm/i915/intel_atomic_plane.c | 18 +---
> drivers/gpu/drm/i915/intel_display.c| 140
> ++--
> drivers/gpu/drm/i915/intel_drv.h| 3 -
> drivers/gpu/drm/i915/intel_fbc.c| 12 +--
> drivers/gpu/drm/i915/intel_pm.c | 60 ++--
> drivers/gpu/drm/i915/intel_sprite.c | 94 ++-
> drivers/gpu/drm/mediatek/mtk_drm_plane.c| 72 --
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 31 ++
> include/drm/drm_crtc.h | 13 +++
> include/drm/drm_plane_helper.h | 5 +
> 13 files changed, 315 insertions(+), 298 deletions(-)
>
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 9/9] drm/simple_kms_helper: Use drm_plane_helper_check_state()
On Tue, Jul 26, 2016 at 12:07 PM, wrote:
> From: Ville Syrjälä
>
> Replace the use of drm_plane_helper_check_update() with
> drm_plane_helper_check_state() since we have a plane state.
>
> I don't see any actual users of drm_simple_kms_helper yet, so
> no actual plane clipping bugs to fix.
>
> Cc: Noralf Trønnes
> Signed-off-by: Ville Syrjälä
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/drm_simple_kms_helper.c | 27 ++-
> 1 file changed, 6 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index 0db36d27e90b..0a02efe978ee 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -73,22 +73,9 @@ static const struct drm_crtc_funcs
> drm_simple_kms_crtc_funcs = {
> static int drm_simple_kms_plane_atomic_check(struct drm_plane *plane,
> struct drm_plane_state *plane_state)
> {
> - struct drm_rect src = {
> - .x1 = plane_state->src_x,
> - .y1 = plane_state->src_y,
> - .x2 = plane_state->src_x + plane_state->src_w,
> - .y2 = plane_state->src_y + plane_state->src_h,
> - };
> - struct drm_rect dest = {
> - .x1 = plane_state->crtc_x,
> - .y1 = plane_state->crtc_y,
> - .x2 = plane_state->crtc_x + plane_state->crtc_w,
> - .y2 = plane_state->crtc_y + plane_state->crtc_h,
> - };
> struct drm_rect clip = { 0 };
> struct drm_simple_display_pipe *pipe;
> struct drm_crtc_state *crtc_state;
> - bool visible;
> int ret;
>
> pipe = container_of(plane, struct drm_simple_display_pipe, plane);
> @@ -102,17 +89,15 @@ static int drm_simple_kms_plane_atomic_check(struct
> drm_plane *plane,
>
> clip.x2 = crtc_state->adjusted_mode.hdisplay;
> clip.y2 = crtc_state->adjusted_mode.vdisplay;
> - ret = drm_plane_helper_check_update(plane, >crtc,
> - plane_state->fb,
> - , , ,
> - plane_state->rotation,
> - DRM_PLANE_HELPER_NO_SCALING,
> - DRM_PLANE_HELPER_NO_SCALING,
> - false, true, );
> +
> + ret = drm_plane_helper_check_state(plane_state, ,
> + DRM_PLANE_HELPER_NO_SCALING,
> + DRM_PLANE_HELPER_NO_SCALING,
> + false, true);
> if (ret)
> return ret;
>
> - if (!visible)
> + if (!plane_state->visible)
> return -EINVAL;
>
> if (!pipe->funcs || !pipe->funcs->check)
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Intel-gfx] [PATCH 8/9] drm/mediatek: Use drm_plane_helper_check_state()
On Tue, Jul 26, 2016 at 12:07 PM, wrote:
> From: Ville Syrjälä
>
> Replace the use of drm_plane_helper_check_update() with
> drm_plane_helper_check_state() since we have a plane state.
>
> This also eliminates the double clipping the driver was doing
> in both check and commit phases). And it should fix src coordinate
> addr adjustement. Previously the driver was expecting negative dst
> coordinates after clipping, which is not going happen, so any clipping
> induced addr adjustment simply didn't happen. Neither did the driver
> respect any user configured src coordinates, so panning and such would
> have been totally broken. It should be all good now.
>
> Cc: CK Hu
> Cc: linux-mediatek at lists.infradead.org
> Signed-off-by: Ville Syrjälä
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/mediatek/mtk_drm_plane.c | 72
> +---
> 1 file changed, 20 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index 3995765a90dc..5f2516fca079 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -30,15 +30,20 @@ static const u32 formats[] = {
> DRM_FORMAT_RGB565,
> };
>
> -static void mtk_plane_enable(struct mtk_drm_plane *mtk_plane, bool enable,
> -dma_addr_t addr, struct drm_rect *dest)
> +static void mtk_plane_enable(struct mtk_drm_plane *mtk_plane,
> +dma_addr_t addr)
> {
> struct drm_plane *plane = _plane->base;
> struct mtk_plane_state *state = to_mtk_plane_state(plane->state);
> unsigned int pitch, format;
> - int x, y;
> + bool enable;
>
> - if (WARN_ON(!plane->state || (enable && !plane->state->fb)))
> + if (WARN_ON(!plane->state))
> + return;
> +
> + enable = state->base.visible;
> +
> + if (WARN_ON(enable && !plane->state->fb))
> return;
>
> if (plane->state->fb) {
> @@ -49,27 +54,17 @@ static void mtk_plane_enable(struct mtk_drm_plane
> *mtk_plane, bool enable,
> format = DRM_FORMAT_RGBA;
> }
>
> - x = plane->state->crtc_x;
> - y = plane->state->crtc_y;
> -
> - if (x < 0) {
> - addr -= x * 4;
> - x = 0;
> - }
> -
> - if (y < 0) {
> - addr -= y * pitch;
> - y = 0;
> - }
> + addr += (state->base.src.x1 >> 16) * 4;
> + addr += (state->base.src.y1 >> 16) * pitch;
>
> state->pending.enable = enable;
> state->pending.pitch = pitch;
> state->pending.format = format;
> state->pending.addr = addr;
> - state->pending.x = x;
> - state->pending.y = y;
> - state->pending.width = dest->x2 - dest->x1;
> - state->pending.height = dest->y2 - dest->y1;
> + state->pending.x = state->base.dst.x1;
> + state->pending.y = state->base.dst.y1;
> + state->pending.width = drm_rect_width(>base.dst);
> + state->pending.height = drm_rect_height(>base.dst);
> wmb(); /* Make sure the above parameters are set before update */
> state->pending.dirty = true;
> }
> @@ -134,20 +129,6 @@ static int mtk_plane_atomic_check(struct drm_plane
> *plane,
> {
> struct drm_framebuffer *fb = state->fb;
> struct drm_crtc_state *crtc_state;
> - bool visible;
> - struct drm_rect dest = {
> - .x1 = state->crtc_x,
> - .y1 = state->crtc_y,
> - .x2 = state->crtc_x + state->crtc_w,
> - .y2 = state->crtc_y + state->crtc_h,
> - };
> - struct drm_rect src = {
> - /* 16.16 fixed point */
> - .x1 = state->src_x,
> - .y1 = state->src_y,
> - .x2 = state->src_x + state->src_w,
> - .y2 = state->src_y + state->src_h,
> - };
> struct drm_rect clip = { 0, };
>
> if (!fb)
> @@ -168,12 +149,10 @@ static int mtk_plane_atomic_check(struct drm_plane
> *plane,
> clip.x2 = crtc_state->mode.hdisplay;
> clip.y2 = crtc_state->mode.vdisplay;
>
> - return drm_plane_helper_check_update(plane, state->crtc, fb,
> -, , ,
> -state->rotation,
> -DRM_PLANE_HELPER_NO_SCALING,
> -DRM_PLANE_HELPER_NO_SCALING,
> -true, true, );
> + return drm_plane_helper_check_state(state, ,
> + DRM_PLANE_HELPER_NO_SCALING,
> + DRM_PLANE_HELPER_NO_SCALING,
> + true, true);
> }
>
> static void mtk_plane_atomic_update(struct drm_plane *plane,
> @@ -184,24 +163,13 @@ static void
[Intel-gfx] [PATCH 7/9] drm/rockchip: Use drm_plane_helper_check_state()
On Tue, Jul 26, 2016 at 12:07 PM, wrote: > From: Ville Syrjälä > > Replace the use of drm_plane_helper_check_update() with > drm_plane_helper_check_state() since we have a plane state. > > Rockchip looks to handling plane clipping rather well already > (unlikje most arm drm drivers) so there are no function changes > here. > > Cc: Yao > Cc: linux-rockchip at lists.infradead.org > Signed-off-by: Ville Syrjälä Reviewed-by: Sean Paul > --- > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 25 + > 1 file changed, 5 insertions(+), 20 deletions(-) > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > index c566c740ab49..31744fe99b38 100644 > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c > @@ -591,10 +591,7 @@ static int vop_plane_atomic_check(struct drm_plane > *plane, > struct vop_win *vop_win = to_vop_win(plane); > struct vop_plane_state *vop_plane_state = to_vop_plane_state(state); > const struct vop_win_data *win = vop_win->data; > - bool visible; > int ret; > - struct drm_rect *dest = >dst; > - struct drm_rect *src = >src; > struct drm_rect clip; > int min_scale = win->phy->scl ? FRAC_16_16(1, 8) : > DRM_PLANE_HELPER_NO_SCALING; > @@ -608,30 +605,18 @@ static int vop_plane_atomic_check(struct drm_plane > *plane, > if (WARN_ON(!crtc_state)) > return -EINVAL; > > - src->x1 = state->src_x; > - src->y1 = state->src_y; > - src->x2 = state->src_x + state->src_w; > - src->y2 = state->src_y + state->src_h; > - dest->x1 = state->crtc_x; > - dest->y1 = state->crtc_y; > - dest->x2 = state->crtc_x + state->crtc_w; > - dest->y2 = state->crtc_y + state->crtc_h; > - > clip.x1 = 0; > clip.y1 = 0; > clip.x2 = crtc_state->adjusted_mode.hdisplay; > clip.y2 = crtc_state->adjusted_mode.vdisplay; > > - ret = drm_plane_helper_check_update(plane, crtc, state->fb, > - src, dest, , > - state->rotation, > - min_scale, > - max_scale, > - true, true, ); > + ret = drm_plane_helper_check_state(state, , > + min_scale, max_scale, > + true, true); > if (ret) > return ret; > > - if (!visible) > + if (!state->visible) > goto out_disable; > > vop_plane_state->format = vop_convert_format(fb->pixel_format); > @@ -642,7 +627,7 @@ static int vop_plane_atomic_check(struct drm_plane *plane, > * Src.x1 can be odd when do clip, but yuv plane start point > * need align with 2 pixel. > */ > - if (is_yuv_support(fb->pixel_format) && ((src->x1 >> 16) % 2)) > + if (is_yuv_support(fb->pixel_format) && ((state->src.x1 >> 16) % 2)) > return -EINVAL; > > vop_plane_state->enable = true; > -- > 2.7.4 > > ___ > Intel-gfx mailing list > Intel-gfx at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/9] drm/rockchip: Use drm_plane_state.{src, dst}
On Tue, Jul 26, 2016 at 12:07 PM, wrote:
> From: Ville Syrjälä
>
> Replace the private drm_rects in vop_plane_state with
> the ones now living in drm_plane_state.
>
> Cc: Yao
> Cc: linux-rockchip at lists.infradead.org
> Signed-off-by: Ville Syrjälä
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 91305eb7d312..c566c740ab49 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -87,8 +87,6 @@
> struct vop_plane_state {
> struct drm_plane_state base;
> int format;
> - struct drm_rect src;
> - struct drm_rect dest;
> dma_addr_t yrgb_mst;
> bool enable;
> };
> @@ -595,8 +593,8 @@ static int vop_plane_atomic_check(struct drm_plane *plane,
> const struct vop_win_data *win = vop_win->data;
> bool visible;
> int ret;
> - struct drm_rect *dest = _plane_state->dest;
> - struct drm_rect *src = _plane_state->src;
> + struct drm_rect *dest = >dst;
> + struct drm_rect *src = >src;
> struct drm_rect clip;
> int min_scale = win->phy->scl ? FRAC_16_16(1, 8) :
> DRM_PLANE_HELPER_NO_SCALING;
> @@ -694,8 +692,8 @@ static void vop_plane_atomic_update(struct drm_plane
> *plane,
> unsigned int actual_w, actual_h;
> unsigned int dsp_stx, dsp_sty;
> uint32_t act_info, dsp_info, dsp_st;
> - struct drm_rect *src = _plane_state->src;
> - struct drm_rect *dest = _plane_state->dest;
> + struct drm_rect *src = >src;
> + struct drm_rect *dest = >dst;
> struct drm_gem_object *obj, *uv_obj;
> struct rockchip_gem_object *rk_obj, *rk_uv_obj;
> unsigned long offset;
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[PATCH 5/9] drm/i915: Use drm_plane_helper_check_state()
On Tue, Jul 26, 2016 at 12:07 PM, wrote:
> From: Ville Syrjälä
>
> Replace the use of drm_plane_helper_check_update() with
> drm_plane_helper_check_state() since we have a plane state.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/i915/intel_atomic_plane.c | 14 --
> drivers/gpu/drm/i915/intel_display.c | 26 +-
> drivers/gpu/drm/i915/intel_sprite.c | 10 ++
> 3 files changed, 19 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index 14d40261db21..2d831dd43d44 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -134,20 +134,6 @@ static int intel_plane_atomic_check(struct drm_plane
> *plane,
>
> crtc_state = to_intel_crtc_state(drm_crtc_state);
>
> - /*
> -* The original src/dest coordinates are stored in state->base, but
> -* we want to keep another copy internal to our driver that we can
> -* clip/modify ourselves.
> -*/
> - intel_state->base.src.x1 = state->src_x;
> - intel_state->base.src.y1 = state->src_y;
> - intel_state->base.src.x2 = state->src_x + state->src_w;
> - intel_state->base.src.y2 = state->src_y + state->src_h;
> - intel_state->base.dst.x1 = state->crtc_x;
> - intel_state->base.dst.y1 = state->crtc_y;
> - intel_state->base.dst.x2 = state->crtc_x + state->crtc_w;
> - intel_state->base.dst.y2 = state->crtc_y + state->crtc_h;
> -
> /* Clip all planes to CRTC size, or 0x0 if CRTC is disabled */
> intel_state->clip.x1 = 0;
> intel_state->clip.y1 = 0;
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 4f67b7c19b75..eae8a72bad5a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14126,7 +14126,6 @@ intel_check_primary_plane(struct drm_plane *plane,
> struct intel_plane_state *state)
> {
> struct drm_crtc *crtc = state->base.crtc;
> - struct drm_framebuffer *fb = state->base.fb;
> int min_scale = DRM_PLANE_HELPER_NO_SCALING;
> int max_scale = DRM_PLANE_HELPER_NO_SCALING;
> bool can_position = false;
> @@ -14140,14 +14139,10 @@ intel_check_primary_plane(struct drm_plane *plane,
> can_position = true;
> }
>
> - return drm_plane_helper_check_update(plane, crtc, fb,
> ->base.src,
> ->base.dst,
> ->base.clip,
> -state->base.rotation,
> -min_scale, max_scale,
> -can_position, true,
> ->base.visible);
> + return drm_plane_helper_check_state(>base,
> + >clip,
> + min_scale, max_scale,
> + can_position, true);
> }
>
> static void intel_begin_crtc_commit(struct drm_crtc *crtc,
> @@ -14327,20 +14322,17 @@ intel_check_cursor_plane(struct drm_plane *plane,
> struct intel_crtc_state *crtc_state,
> struct intel_plane_state *state)
> {
> - struct drm_crtc *crtc = crtc_state->base.crtc;
> struct drm_framebuffer *fb = state->base.fb;
> struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> enum pipe pipe = to_intel_plane(plane)->pipe;
> unsigned stride;
> int ret;
>
> - ret = drm_plane_helper_check_update(plane, crtc, fb, >base.src,
> - >base.dst,
> - >base.clip,
> - state->base.rotation,
> - DRM_PLANE_HELPER_NO_SCALING,
> - DRM_PLANE_HELPER_NO_SCALING,
> - true, true, >base.visible);
> + ret = drm_plane_helper_check_state(>base,
> + >clip,
> + DRM_PLANE_HELPER_NO_SCALING,
> + DRM_PLANE_HELPER_NO_SCALING,
> + true, true);
> if (ret)
> return ret;
>
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 10f10915c0bc..b38956624f04 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -785,6 +785,16 @@ intel_check_sprite_plane(struct drm_plane *plane,
> int max_scale, min_scale;
>
[PATCH 4/9] drm/i915: Use drm_plane_state.{src,dst,visible}
On Tue, Jul 26, 2016 at 12:06 PM, wrote: > From: Ville Syrjälä > > Replace the private drm_rects/flags in intel_plane_state > with the ones now living in drm_plane_state. > > Signed-off-by: Ville Syrjälä Reviewed-by: Sean Paul > --- > drivers/gpu/drm/i915/intel_atomic_plane.c | 20 ++--- > drivers/gpu/drm/i915/intel_display.c | 132 > +++--- > drivers/gpu/drm/i915/intel_drv.h | 3 - > drivers/gpu/drm/i915/intel_fbc.c | 12 +-- > drivers/gpu/drm/i915/intel_pm.c | 60 +++--- > drivers/gpu/drm/i915/intel_sprite.c | 84 +-- > 6 files changed, 156 insertions(+), 155 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c > b/drivers/gpu/drm/i915/intel_atomic_plane.c > index 7de7721f65bc..14d40261db21 100644 > --- a/drivers/gpu/drm/i915/intel_atomic_plane.c > +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c > @@ -139,14 +139,14 @@ static int intel_plane_atomic_check(struct drm_plane > *plane, > * we want to keep another copy internal to our driver that we can > * clip/modify ourselves. > */ > - intel_state->src.x1 = state->src_x; > - intel_state->src.y1 = state->src_y; > - intel_state->src.x2 = state->src_x + state->src_w; > - intel_state->src.y2 = state->src_y + state->src_h; > - intel_state->dst.x1 = state->crtc_x; > - intel_state->dst.y1 = state->crtc_y; > - intel_state->dst.x2 = state->crtc_x + state->crtc_w; > - intel_state->dst.y2 = state->crtc_y + state->crtc_h; > + intel_state->base.src.x1 = state->src_x; > + intel_state->base.src.y1 = state->src_y; > + intel_state->base.src.x2 = state->src_x + state->src_w; > + intel_state->base.src.y2 = state->src_y + state->src_h; > + intel_state->base.dst.x1 = state->crtc_x; > + intel_state->base.dst.y1 = state->crtc_y; > + intel_state->base.dst.x2 = state->crtc_x + state->crtc_w; > + intel_state->base.dst.y2 = state->crtc_y + state->crtc_h; > > /* Clip all planes to CRTC size, or 0x0 if CRTC is disabled */ > intel_state->clip.x1 = 0; > @@ -180,7 +180,7 @@ static int intel_plane_atomic_check(struct drm_plane > *plane, > } > } > > - intel_state->visible = false; > + intel_state->base.visible = false; > ret = intel_plane->check_plane(plane, crtc_state, intel_state); > if (ret) > return ret; > @@ -196,7 +196,7 @@ static void intel_plane_atomic_update(struct drm_plane > *plane, > to_intel_plane_state(plane->state); > struct drm_crtc *crtc = plane->state->crtc ?: old_state->crtc; > > - if (intel_state->visible) > + if (intel_state->base.visible) > intel_plane->update_plane(plane, > to_intel_crtc_state(crtc->state), > intel_state); > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 78beb7e9d384..4f67b7c19b75 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -2565,7 +2565,7 @@ intel_find_initial_plane_obj(struct intel_crtc > *intel_crtc, > * simplest solution is to just disable the primary plane now and > * pretend the BIOS never had it enabled. > */ > - to_intel_plane_state(plane_state)->visible = false; > + to_intel_plane_state(plane_state)->base.visible = false; > crtc_state->plane_mask &= ~(1 << drm_plane_index(primary)); > intel_pre_disable_primary_noatomic(_crtc->base); > intel_plane->disable_plane(primary, _crtc->base); > @@ -2583,14 +2583,14 @@ valid_fb: > plane_state->crtc_w = fb->width; > plane_state->crtc_h = fb->height; > > - intel_state->src.x1 = plane_state->src_x; > - intel_state->src.y1 = plane_state->src_y; > - intel_state->src.x2 = plane_state->src_x + plane_state->src_w; > - intel_state->src.y2 = plane_state->src_y + plane_state->src_h; > - intel_state->dst.x1 = plane_state->crtc_x; > - intel_state->dst.y1 = plane_state->crtc_y; > - intel_state->dst.x2 = plane_state->crtc_x + plane_state->crtc_w; > - intel_state->dst.y2 = plane_state->crtc_y + plane_state->crtc_h; > + intel_state->base.src.x1 = plane_state->src_x; > + intel_state->base.src.y1 = plane_state->src_y; > + intel_state->base.src.x2 = plane_state->src_x + plane_state->src_w; > + intel_state->base.src.y2 = plane_state->src_y + plane_state->src_h; > + intel_state->base.dst.x1 = plane_state->crtc_x; > + intel_state->base.dst.y1 = plane_state->crtc_y; > + intel_state->base.dst.x2 = plane_state->crtc_x + plane_state->crtc_w; > + intel_state->base.dst.y2 = plane_state->crtc_y + plane_state->crtc_h; > > obj = intel_fb_obj(fb); > if (obj->tiling_mode !=
[Intel-gfx] [PATCH v2 3/9] drm/plane-helper: Add drm_plane_helper_check_state()
On Tue, Jul 26, 2016 at 1:34 PM, wrote:
> From: Ville Syrjälä
>
> Add a version of drm_plane_helper_check_update() which takes a plane
> state instead of having the caller pass in everything.
>
> And to reduce code duplication, let's reimplement
> drm_plane_helper_check_update() in terms of the new function, by
> having a tempororary plane state on the stack.
>
> v2: Add a note that the functions modifies the state (Chris)
>
> Cc: Chris Wilson
> Signed-off-by: Ville Syrjälä
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/drm_plane_helper.c | 139
> -
> include/drm/drm_plane_helper.h | 5 ++
> 2 files changed, 112 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_plane_helper.c
> b/drivers/gpu/drm/drm_plane_helper.c
> index 16c4a7bd7465..ca02997b1c36 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -108,14 +108,9 @@ static int get_connectors_for_crtc(struct drm_crtc *crtc,
> }
>
> /**
> - * drm_plane_helper_check_update() - Check plane update for validity
> - * @plane: plane object to update
> - * @crtc: owning CRTC of owning plane
> - * @fb: framebuffer to flip onto plane
> - * @src: source coordinates in 16.16 fixed point
> - * @dest: integer destination coordinates
> + * drm_plane_helper_check_state() - Check plane state for validity
> + * @state: plane state to check
> * @clip: integer clipping coordinates
> - * @rotation: plane rotation
> * @min_scale: minimum @src:@dest scaling factor in 16.16 fixed point
> * @max_scale: maximum @src:@dest scaling factor in 16.16 fixed point
> * @can_position: is it legal to position the plane such that it
> @@ -123,10 +118,9 @@ static int get_connectors_for_crtc(struct drm_crtc *crtc,
> *only be false for primary planes.
> * @can_update_disabled: can the plane be updated while the crtc
> * is disabled?
> - * @visible: output parameter indicating whether plane is still visible after
> - * clipping
> *
> - * Checks that a desired plane update is valid. Drivers that provide
> + * Checks that a desired plane update is valid, and updates various
> + * bits of derived state (clipped coordinates etc.). Drivers that provide
> * their own plane handling rather than helper-provided implementations may
> * still wish to call this function to avoid duplication of error checking
> * code.
> @@ -134,29 +128,38 @@ static int get_connectors_for_crtc(struct drm_crtc
> *crtc,
> * RETURNS:
> * Zero if update appears valid, error code on failure
> */
> -int drm_plane_helper_check_update(struct drm_plane *plane,
> - struct drm_crtc *crtc,
> - struct drm_framebuffer *fb,
> - struct drm_rect *src,
> - struct drm_rect *dest,
> - const struct drm_rect *clip,
> - unsigned int rotation,
> - int min_scale,
> - int max_scale,
> - bool can_position,
> - bool can_update_disabled,
> - bool *visible)
> +int drm_plane_helper_check_state(struct drm_plane_state *state,
> +const struct drm_rect *clip,
> +int min_scale,
> +int max_scale,
> +bool can_position,
> +bool can_update_disabled)
> {
> + struct drm_crtc *crtc = state->crtc;
> + struct drm_framebuffer *fb = state->fb;
> + struct drm_rect *src = >src;
> + struct drm_rect *dst = >dst;
> + unsigned int rotation = state->rotation;
> int hscale, vscale;
>
> + src->x1 = state->src_x;
> + src->y1 = state->src_y;
> + src->x2 = state->src_x + state->src_w;
> + src->y2 = state->src_y + state->src_h;
> +
> + dst->x1 = state->crtc_x;
> + dst->y1 = state->crtc_y;
> + dst->x2 = state->crtc_x + state->crtc_w;
> + dst->y2 = state->crtc_y + state->crtc_h;
> +
> if (!fb) {
> - *visible = false;
> + state->visible = false;
> return 0;
> }
>
> /* crtc should only be NULL when disabling (i.e., !fb) */
> if (WARN_ON(!crtc)) {
> - *visible = false;
> + state->visible = false;
> return 0;
> }
>
> @@ -168,20 +171,20 @@ int drm_plane_helper_check_update(struct drm_plane
> *plane,
> drm_rect_rotate(src, fb->width << 16, fb->height << 16, rotation);
>
> /* Check scaling */
> - hscale = drm_rect_calc_hscale(src, dest, min_scale, max_scale);
> - vscale = drm_rect_calc_vscale(src, dest, min_scale, max_scale);
> + hscale =
[Intel-gfx] [PATCH 2/9] drm: Store clipped src/dst coordinatee in drm_plane_state
On Tue, Jul 26, 2016 at 12:06 PM, wrote:
> From: Ville Syrjälä
>
> Pretty much all driver will have need for the clipped plane
> coordinates, so let's stuff then into drm_plane_state.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Sean Paul
> ---
> include/drm/drm_crtc.h | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 3edeaf88ebc0..00a1868940b8 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -35,6 +35,7 @@
> #include
> #include
> #include
> +#include
>
> struct drm_device;
> struct drm_mode_set;
> @@ -1409,6 +1410,9 @@ struct drm_connector {
> * @src_w: width of visible portion of plane (in 16.16)
> * @src_h: height of visible portion of plane (in 16.16)
> * @rotation: rotation of the plane
> + * @src: clipped source coordinates of the plane (in 16.16)
> + * @dst: clipped destination coordinates of the plane
> + * @visible: visibility of the plane
> * @state: backpointer to global drm_atomic_state
> */
> struct drm_plane_state {
> @@ -1429,6 +1433,15 @@ struct drm_plane_state {
> /* Plane rotation */
> unsigned int rotation;
>
> + /* Clipped coordinates */
> + struct drm_rect src, dst;
> +
> + /*
> +* Is the plane actually visible? Can be false even
> +* if fb!=NULL and crtc!=NULL, due to clipping.
> +*/
> + bool visible;
> +
> struct drm_atomic_state *state;
> };
>
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[PATCH V3 2/5] dts/imx6q-b850v3: Configure IPU assignment order
Am Sonntag, den 31.07.2016, 21:55 +0200 schrieb Peter Senna Tschudin:
> As the IPU has combined limitations across multiple crtcs, and as that
> can't be communicated to userspace at the moment, reorder the crtcs to
> allow support to two Full-HD monitors by avoiding assigning two
> monitors to a single IPU.
>
> Cc: Enric Balletbo i Serra
> Cc: Philipp Zabel
> Cc: Rob Herring
> Cc: Fabio Estevam
> Signed-off-by: Peter Senna Tschudin
NACK. This is a userspace issue. Changing the assignment order of the
CRTCs just shifts the failure to a userspace that want to use CRTC 0 and
2 now.
imx-drm just got atomic support and with the atomic check it should be
possible to inform userspace in a reasonable way about such issues.
Regards,
Lucas
> ---
> Unchanged from V2.
>
> Changes from V1:
> - New commit message
>
> arch/arm/boot/dts/imx6q-b850v3.dts | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6q-b850v3.dts
> b/arch/arm/boot/dts/imx6q-b850v3.dts
> index 167f744..88a70de 100644
> --- a/arch/arm/boot/dts/imx6q-b850v3.dts
> +++ b/arch/arm/boot/dts/imx6q-b850v3.dts
> @@ -51,6 +51,11 @@
> chosen {
> stdout-path =
> };
> +
> + display-subsystem {
> + compatible = "fsl,imx-display-subsystem";
> + ports = <_di0>, <_di0>, <_di1>, <_di1>;
> + };
> };
>
> {
[Intel-gfx] [PATCH v4 0/6] Finally fix watermarks
Op 29-07-16 om 22:33 schreef Matt Roper: > On Fri, Jul 29, 2016 at 12:39:05PM +0300, Ville Syrjälä wrote: >> On Thu, Jul 28, 2016 at 05:03:52PM -0700, Matt Roper wrote: >>> This is completely untested (and probably horribly broken/buggy), but >>> here's a quick mockup of the general approach I was thinking for >>> ensuring DDB & WM's can be updated together while ensuring the >>> three-step pipe flushing process is honored: >>> >>> https://github.com/mattrope/kernel/commits/experimental/lyude_ddb >>> >>> Basically the idea is to take note of what's happening to the pipe's DDB >>> allocation (shrinking, growing, unchanged, etc.) during the atomic check >>> phase; >> Didn't look too closely, but I think you can't actually do that unless >> you lock all the crtcs whenever the number of active pipes is goind to >> change. Meaning we'd essentially be back to the one-big-modeset-lock >> apporach, which will cause missed flips and whanot on the other pipes. >> >> The alternative I think would consist of: >> - make sure level 0 watermark never exceeds total_ddb_size/max_pipes, >> so that a modeset doesn't have to care about the wms for the other >> pipes not fitting in > Unfortunately this part is the problem. You might get away with doing > this on SKL/KBL which only have three planes max per pipe and a large > (896 block) DDB, but on BXT you have up to four planes (we don't > actually enable the topmost plane in a full-featured manner just yet, > but need to soon), yet the total DDB is only 512 blocks. Sadly, the > platform with more planes was given a smaller DDB... :-( > We're already in trouble because users that are running setups like 3x > 4K with most/all planes in use at large sizes can't find level 0 > watermarks that satisfy their needs and we have to reject the whole > configuration. If we further limit each pipe's usage to total/maxpipes > (i.e., 170 blocks per pipe on BXT), then we're going to hit similar > issues when only driving one or two displays with with all of the planes > in use, even though we should have had more DDB space to work with. > > I guess serious plane usage isn't too common in desktop setups today, > but it's a very critical feature in the embedded world; we can't really > afford to cripple plane usage further. Unfortunately, as you point out > above, this means that we have to follow the bspec's DDB allocation > method, which in turn means we need to grab _all_ CRTC locks any time > _any_ CRTC is being turned on or turned off which is a BKL-style way of > doing things. Meh, I'm running into a similar issue on vlv/chv. I don't see a way around it. :( Only thing we could do is split up the state to make the non-modeset crtc's complete early.
[Bug 91281] Tonga VCE 2160p encode fails with BO to small for addr
https://bugs.freedesktop.org/show_bug.cgi?id=91281 --- Comment #2 from Andy Furniss --- More debugging and size 24883200 works fine in the working case, it's mapping->it.last that varies between working and failing. size mapping->it.last 0x0108fde000 14 13 24883200 1101026 = OK 0x0108fde000 14 13 24883200 1088786 = fail -- 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/20160801/1d7a4e78/attachment.html>
[PATCH v14 0/17] Add Analogix Core Display Port Driver
On 07/29/2016 04:38 PM, Tomeu Vizoso wrote:
> On 5 April 2016 at 04:06, Yakir Yang wrote:
>> Hi Daniel,
>>
>>
>> On 03/31/2016 06:15 PM, Daniel Vetter wrote:
>>> On Mon, Feb 15, 2016 at 07:08:05PM +0800, Yakir Yang wrote:
Hi all,
The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
share the same IP, so a lot of parts can be re-used. I split the common
code into bridge directory, then rk3288 and exynos only need to keep
some platform code. Cause I can't find the exact IP name of exynos dp
controller, so I decide to name dp core driver with "analogix" which I
find in rk3288 eDP TRM
But there are still three light registers setting different between
exynos and rk3288.
1. RK3288 have five special pll registers which not indicate in exynos
dp controller.
2. The address of DP_PHY_PD(dp phy power manager register) are different
between rk3288 and exynos.
3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp
debug
register).
Due to Mark Yao have introduced the ATOMIC support to Rockchip drm, so
it's
okay to use the ATOMIC helpers functions in connector_funcs. No need to
splict
the connector init to platform driver anymore, and this is the biggest
change
since version 11.
This v14 didn't have lots of new changes which seems not the correct time
to
upgrade the version number, but I have changed ordering of patches
(adding 2
more, and removing 2 out). Especially to prevent confusing people, so I
updated
the whole series.
>>> So I'm jumping into this part way late, but just noticed (well Thierry
>>> pointed this out to me) that the exynos dp driver reinvents all the dp and
>>> dp-aux helpers we already. That's somewhat okish for a private driver (and
>>> exynos has a reputation for that kind of stuff), but imo not ok for a
>>> shared driver.
>>>
>>> Not saying this should block merging this patch, but it really needs to be
>>> addressed. All the dp aux and edid read code in the current
>>> exynos_dp_core/reg.c files needs to be replaced with dp helpers and the
>>> core i2c edid reading code.
>>>
>>> Who's going to sign up to do this?
>>
>> Volunteer to that, after finish this thread, I would send new series to
>> switch to take use of dp helper.
> Hi Yakir,
>
> do you have plans to do this work in the short term? If not, I can tackle it.
Wow, that would be great if you like to tackle it :-D
I always keep this in my mind, but haven't found an chance
to finish it. I would like to sit in your Cc list when you post
them out ;)
Best Regards,
- Yakir
> Regards,
>
> Tomeu
>
>> :-D
>> - Yakir
>>
>>
>>> -Daniel
>>>
Thanks,
- Yakir
Changes in v14:
- Rebase the new changes in imx-dp driver
- Split up this patch into 3 parts, make this easy to review (Heiko)
- Remove the Rockchip DP PHY to an separate thread (Heiko)
https://patchwork.kernel.org/patch/8312701/
Changes in v13:
- Use .enable instead of preprare/commit in encoder_helper_funcs (Heiko)
- Fix the missing parameters with drm_encoder_init() helper function.
(Heiko)
Changes in v12:
- Move the connector init to analogix_dp driver, and using ATOMIC helper
(Heiko)
- Add the ack from Jingoo
- Remove the enum link_rate_type struct, using the marcos in
drm_dp_helper.h (Jingoo)
Changes in v11:
- Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
- Add the ack from Rob Herring
- Revert parts of Gustavo Padovan's changes in commit:
drm/exynos: do not start enabling DP at bind() phase
Add dp phy poweron function in bind time.
- Move the panel prepare from get_modes time to bind time, and move
the panel unprepare from bridge->disable to unbind time. (Heiko)
Changes in v10:
- Add the ack from Rob Herring
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here
(Heiko)
- Add the ack from Rob Herring
- Remove the surplus "plat_data" check. (Heiko)
- switch (dp->plat_data && dp->plat_data->dev_type) {
+ switch (dp->plat_data->dev_type) {
Changes in v9:
- Document more details for 'ports' property.
Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)
- Modify the commit subject name. (Heiko)
Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
to avoid -EOVERFLOW error (Krzysztof)
Changes in v6:
- Fix the Kconfig recursive dependency (Javier)
- Fix Peach Pit hpd
[PATCH 1/3] drm: bridge: add DesignWare HDMI I2S audio support
Hi, On 01-08-2016 05:57, Kuninori Morimoto wrote: > Hi Jose > Cc: Mark, Thierry, Daniel > >>> From: Kuninori Morimoto >>> >>> Current dw-hdmi is supporting sound via AHB bus, but it has >>> I2S audio feature too. This patch adds I2S audio support to dw-hdmi. >>> This HDMI I2S is supported by using ALSA SoC common HDMI encoder >>> driver. >>> >>> Signed-off-by: Kuninori Morimoto >>> --- >>> >> I just tested this patch and everything seems ok. Should I give >> my tested-by? > Thank you for your test. I'm happy if it could have it. > > Mark, Thierry, Daniel > I wonder who can be maintainer for this patch ?? > > Best regards > --- > Kuninori Morimoto Tested-by: Jose Abreu Best regards, Jose Miguel Abreu
virglrenderer regression in commit ad4f0f1941677c
On Mon, Aug 1, 2016 at 1:30 AM, Marc-André Lureau wrote: > > Hi > > - Original Message - >> On Fri, Jul 29, 2016 at 3:57 PM, Rob Herring wrote: >> > Hi, >> > >> > This commit in virglrenderer causes a regression in Android for me. >> > The parameters that get passed in are last_level = 8, width = 1. I'm >> > not really sure if this is valid (I'm guessing there should be some >> > min width?), or where I should be looking to fix this. Any ideas? >> >> what is the height? last mip-map level is basically the number of >> times you could half the width+height (round up to 1) until it is 1x1. >> So something like 1x512 would have last_level=8. (I might be off by >> one right-shift..) >> >> Try this: >> >> - if (args->last_level > (floor(log2(MAX2(args->width, args->width))) + 1)) >> + if (args->last_level > (floor(log2(MAX2(args->width, args->height))) + 1)) > > Oh, looks like what I wanted but I wouldn't see the typo even after > re-reading... > > please send a patch on the virgl mailing list. tbh, I don't even have a virgl setup (psuedo-patch was just from looking at cgit).. so I'd be more than happy if someone else could actually test that change and send a patch. BR, -R
[PATCH 1/3] drm: bridge: add DesignWare HDMI I2S audio support
Hi Jose Cc: Mark, Thierry, Daniel > > From: Kuninori Morimoto > > > > Current dw-hdmi is supporting sound via AHB bus, but it has > > I2S audio feature too. This patch adds I2S audio support to dw-hdmi. > > This HDMI I2S is supported by using ALSA SoC common HDMI encoder > > driver. > > > > Signed-off-by: Kuninori Morimoto > > --- > > > > I just tested this patch and everything seems ok. Should I give > my tested-by? Thank you for your test. I'm happy if it could have it. Mark, Thierry, Daniel I wonder who can be maintainer for this patch ?? Best regards --- Kuninori Morimoto
virglrenderer regression in commit ad4f0f1941677c
Hi - Original Message - > On Fri, Jul 29, 2016 at 3:57 PM, Rob Herring wrote: > > Hi, > > > > This commit in virglrenderer causes a regression in Android for me. > > The parameters that get passed in are last_level = 8, width = 1. I'm > > not really sure if this is valid (I'm guessing there should be some > > min width?), or where I should be looking to fix this. Any ideas? > > what is the height? last mip-map level is basically the number of > times you could half the width+height (round up to 1) until it is 1x1. > So something like 1x512 would have last_level=8. (I might be off by > one right-shift..) > > Try this: > > - if (args->last_level > (floor(log2(MAX2(args->width, args->width))) + 1)) > + if (args->last_level > (floor(log2(MAX2(args->width, args->height))) + 1)) Oh, looks like what I wanted but I wouldn't see the typo even after re-reading... please send a patch on the virgl mailing list.
