dri-devel February 2015

dri-devel@lists.freedesktop.org

152 participants
1073 discussions

[Bug 86089] [r600g] shader failure - r600_sb::bc_finalizer::cf_peephole() when starting Second Life
by bugzilla-daemon＠freedesktop.org 02 Feb '15

02 Feb '15

https://bugs.freedesktop.org/show_bug.cgi?id=86089 Bug ID: 86089 Summary: [r600g] shader failure - r600_sb::bc_finalizer::cf_peephole() when starting Second Life Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel(a)lists.freedesktop.org Reporter: shawn.starr(a)rogers.com Compiling November 10th build of git master for rv6xx: kernel: 3.18.0-0.rc3.git2.2.fc22.1.x86_64 mesa-dri-drivers-10.4-0.devel.100.20141110.fc21.x86_64 (custom using Fedora's .spec file) I am using R600_DEBUG=hyperz I get the following crash: Program received signal SIGSEGV, Segmentation fault. 0x00007fffe916bb4e in r600_sb::bc_finalizer::cf_peephole (this=this@entry=0x7fffffffb350) at sb/sb_bc_finalize.cpp:877 877 c->jump_target = static_cast<cf_node*>(c->jump_target->next); Full stack dump attached -- You are receiving this mail because: You are the assignee for the bug.

1 12

Re: [Intel-gfx] [RFC 2/6] drm/i915: Add tiled framebuffer modifiers
by Daniel Vetter 02 Feb '15

02 Feb '15

On Fri, Jan 30, 2015 at 05:36:54PM +0000, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> > > To be used from the new addfb2 extension. > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> > --- > include/uapi/drm/i915_drm.h | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h > index 6eed16b..a7327fd 100644 > --- a/include/uapi/drm/i915_drm.h > +++ b/include/uapi/drm/i915_drm.h > @@ -28,6 +28,7 @@ > #define _UAPI_I915_DRM_H_ > > #include <drm/drm.h> > +#include <uapi/drm/drm_fourcc.h> > > /* Please note that modifications to all structs defined here are > * subject to backwards-compatibility constraints. > @@ -1101,4 +1102,16 @@ struct drm_i915_gem_context_param { > __u64 value; > }; > > +/** @{ > + * Intel framebuffer modifiers > + * > + * Tiling modes supported by the display hardware > + * to be passed in via the DRM addfb2 ioctl. > + */ > +/** None */ > +#define I915_FORMAT_MOD_NONE fourcc_mod_code(INTEL, 0x00000000000000L) > +/** X tiling */ > +#define I915_FORMAT_MOD_X_TILED fourcc_mod_code(INTEL, 0x00000000000001L) One thing I wonder here is whether we should have a modifier for each physical layout (tiling modes do change slightly between hw) or whether we should just continue to assume that this is Intel-specific and add a disclaimer that the precise layout depends upon the actual intel box you're running on? Leaning towards your approach, worst case we get to write some code to de-alias layout modifiers with established cross-vendor layouts (if they ever happen). Just want to make sure that we've thought about this. Adding Rob&dri-devel for this. -Daniel > +/** @} */ > + > #endif /* _UAPI_I915_DRM_H_ */ > -- > 2.2.2 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx(a)lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

3 9

[pull] radeon drm-fixes-3.19
by Alex Deucher 02 Feb '15

02 Feb '15

Hi Dave, One last round of fixes for radeon for 3.19: - fix some fallout from the reservation object integration on the test/benchmark options - fix a crash in the gpu vm code if gfx init fails - fix a pll issue that leads to a blank screen on older IGP parts The following changes since commit a78b80f51e57273961c397b5e9e224860228b965: Merge tag 'drm-intel-fixes-2015-01-29' of git://anongit.freedesktop.org/drm-intel into drm-fixes (2015-01-30 13:32:24 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.19 for you to fetch changes up to 92b712b739811e4aa7c0e1af339d0098989ea024: drm/radeon: fix the crash in test functions (2015-02-02 11:39:36 -0500) ---------------------------------------------------------------- Alex Deucher (2): drm/radeon: don't init gpuvm if accel is disabled (v3) drm/radeon: properly set vm fragment size for TN/RL Christian König (1): drm/radeon: fix PLLs on RS880 and older v2 Ilija Hadzic (2): drm/radeon: fix the crash in benchmark functions drm/radeon: fix the crash in test functions drivers/gpu/drm/radeon/radeon_benchmark.c | 13 ++++++++----- drivers/gpu/drm/radeon/radeon_display.c | 3 +++ drivers/gpu/drm/radeon/radeon_gem.c | 6 ++++-- drivers/gpu/drm/radeon/radeon_kms.c | 16 ++++++++-------- drivers/gpu/drm/radeon/radeon_test.c | 8 ++++---- drivers/gpu/drm/radeon/radeon_vm.c | 6 ++++-- 6 files changed, 31 insertions(+), 21 deletions(-)

1 0

Re: [RESEND PATCH v2] [media] Add RGB444_1X12 and RGB565_1X16 media bus formats
by Boris Brezillon 02 Feb '15

02 Feb '15

Hi Mauro, On Mon, 02 Feb 2015 12:57:55 -0200 Mauro Carvalho Chehab <m.chehab(a)samsung.com> wrote: > Em Tue, 6 Jan 2015 12:43:35 +0100 > Boris Brezillon <boris.brezillon(a)free-electrons.com> escreveu: > > > Add RGB444_1X12 and RGB565_1X16 format definitions and update the > > documentation. > > > > Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com> > > Acked-by: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com> > > Acked-by: Sakari Ailus <sakari.ailus(a)linux.intel.com> > > --- > > Hi Mauro, Sakari, > > > > This patch has been rejected as 'Not Applicable'. > > Is there anyting wrong in it ? > > I was expecting that this patch would be merged together with the > remaining series, via the DRM tree. That's basically why I gave > my ack: > https://lkml.org/lkml/2014/11/3/661 > > HINT: when a subsystem maintainer gives an ack, that likely means that > he expects that the patch will be applied via some other tree. My bad, I thought this would go into the media tree since this single patch is not exactly related to a DRM feature (except the fact that I was planning to use it in my DRM driver). Actually, I didn't send it to the DRM maintainer or dri-devel ML in the first place :-(. Can you reconsider taking it in the media tree ? I you can't, I'll ask Dave (just added him in Cc) to take it into the DRM tree. Thanks. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com

2 1

[PATCH v4 0/9] Enable HDMI support on Exynos platforms
by Marek Szyprowski 02 Feb '15

02 Feb '15

Hi all, This is yet another approach to submit patches, which enables HDMI support for two Exynos based platforms: UniversalC210 and Odroid X2/U3. Beside DTS changes, this patchset adds parent domain support for Exynos PM domains. This was the most controversial patch in the previous attempts, but I hope I fixes all reported issues and made it really generic. For more details see individual patches. The patchset is based on my previous patch: 'ARM: DTS: Exynos: convert to generic power domain bindings' (http://www.spinics.net/lists/linux-samsung-soc/msg40584.html) and 'PM / Domains: Export of_genpd_get_from_provider function' patch merged as commit 7496fcbe8a643097efc061160e1c3b65ee2fa350 to v3.19-rc4. Thanks to Tobias Jakobi for testing and finding out that the already merged exynos4 clocks hierarchy fixup (commit df019a5c0f7083001cb694f44821ca506425bda2 'clk: samsung: exynos4: set parent of sclk_hdmiphy to hdmi') doesn't work in all cases. To finlly solve the power on/off issues I've decided to simply add 'hdmi' clock handling also to mixer module. Regards Marek Szyprowski Changelog: v4: - added patches, which add 'hdmi' clock handling to mixed block, this finally solves the initialization related issues, thanks for Tobias Jakobi for testing - added acks/reviewed/tested by tags v3: (http://www.spinics.net/lists/linux-samsung-soc/msg41020.html) - added a note on defining subdomains to generic PM domain binding documentation (requested by Ulf Hansson) v2: (http://www.spinics.net/lists/linux-samsung-soc/msg40980.html) - rewrote subdomains patch according to suggestions from Geert Uytterhoeven and Amit Daniel Kachhap. v1 resend: (http://www.spinics.net/lists/linux-samsung-soc/msg39428.html) - added handling of generic 'power-domains' binding in subdomains v1: (http://www.spinics.net/lists/linux-samsung-soc/msg38914.html) - resolved power domain on/off issue with 'clk: samsung: exynos4: set parent of mixer gate clock to hdmi' patch v0: (http://www.spinics.net/lists/linux-samsung-soc/msg33498.html) - first attempt, used 'always on' power domains hack Patch summary: Andrzej Hajda (1): ARM: dts: exynos5250: add display power domain Marek Szyprowski (7): PM / Domains: Add a note about power domain subdomains ARM: Exynos: add support for sub-power domains ARM: dts: exynos4: add hdmi related nodes ARM: dts: exynos4: add dependency between TV and LCD0 power domains ARM: dts: exynos4412-odroid: enable hdmi support ARM: dts: Exynos: add 'hdmi' clock to mixer nodes drm/exynos: fix mixer start sequence Tomasz Stanislawski (1): ARM: dts: exynos4210-universal_c210: enable hdmi support .../bindings/arm/exynos/power_domain.txt | 2 + .../devicetree/bindings/power/power_domain.txt | 29 +++++++++++ arch/arm/boot/dts/exynos4.dtsi | 41 ++++++++++++++++ arch/arm/boot/dts/exynos4210-universal_c210.dts | 57 ++++++++++++++++++++++ arch/arm/boot/dts/exynos4210.dtsi | 8 +++ arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 44 +++++++++++++++++ arch/arm/boot/dts/exynos4x12.dtsi | 11 +++++ arch/arm/boot/dts/exynos5250.dtsi | 15 +++++- arch/arm/boot/dts/exynos5420.dtsi | 5 +- arch/arm/mach-exynos/pm_domains.c | 28 +++++++++++ drivers/gpu/drm/exynos/exynos_mixer.c | 9 ++++ 11 files changed, 245 insertions(+), 4 deletions(-) -- 1.9.2

3 17

[PATCH v3] drm/dp: Use large transactions for I2C over AUX
by Simon Farnsworth 02 Feb '15

02 Feb '15

DisplayPort to DVI-D Dual Link adapters designed by Bizlink have bugs in their I2C over AUX implementation. They work fine with Windows, but fail with Linux. It turns out that they cannot keep an I2C transaction open unless the previous read was 16 bytes; shorter reads can only be followed by a zero byte transfer ending the I2C transaction. Copy Windows's behaviour, and read 16 bytes at a time. If we get a short reply, assume that there's a hardware bottleneck, and shrink our read size to match. For this purpose, use the algorithm in the DisplayPort 1.2 spec, in the hopes that it'll be closest to what Windows does, as no sink I've found actually gives short replies. Also provide a module parameter for testing smaller transfer sizes, in case there are sinks out there that cannot work with Windows. Signed-off-by: Simon Farnsworth <simon.farnsworth(a)onelan.co.uk> --- v3 changes, after feedback from Ville and more testing of Windows: * Change the short reply algorithm to match Ville's description of the DisplayPort 1.2 spec wording. * Add a module parameter to set the default transfer size for experiments. Requested over IRC by Ville. No-one's been able to find a device that does short replies, but experiments show that bigger reads are faster on most devices. Ville got: DP->DVI (OUI 001cf8): 40ms -> 35ms DP->VGA (OUI 0022b9): 45ms -> 38ms Zotac DP->2xHDMI: 25ms -> 4ms v2 changes, after feedback from Thierry and Ville: * Handle short replies. I've decided (arbitrarily) that a short reply results in us dropping back to the newly chosen size for the rest of this I2C transaction. Thus, given an attempt to read the first 16 bytes of EDID, and a sink that only does 4 bytes of buffering, we will see the following AUX transfers for the EDID read (after address is set): <set address, block etc> Read 16 bytes from I2C over AUX. Reply with 4 bytes Read 4 bytes Reply with 4 bytes Read 4 bytes Reply with 4 bytes Read 4 bytes Reply with 4 bytes <end I2C transaction> Note that I've not looked at MST support - I have neither the DP 1.2 spec nor any MST branch devices, so I can't test anything I write or check it against a spec. It looks from the code, however, as if MST has the branch device do the split from a big request into small transactions. drivers/gpu/drm/drm_dp_helper.c | 91 ++++++++++++++++++++++++++++++++--------- include/drm/drm_dp_helper.h | 5 +++ 2 files changed, 77 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index 79968e3..3db116c 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -396,11 +396,13 @@ static u32 drm_dp_i2c_functionality(struct i2c_adapter *adapter) * retrying the transaction as appropriate. It is assumed that the * aux->transfer function does not modify anything in the msg other than the * reply field. + * + * Returns bytes transferred on success, or a negative error code on failure. */ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg) { unsigned int retry; - int err; + int ret; /* * DP1.2 sections 2.7.7.1.5.6.1 and 2.7.7.1.6.6.1: A DP Source device @@ -409,14 +411,14 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg) */ for (retry = 0; retry < 7; retry++) { mutex_lock(&aux->hw_mutex); - err = aux->transfer(aux, msg); + ret = aux->transfer(aux, msg); mutex_unlock(&aux->hw_mutex); - if (err < 0) { - if (err == -EBUSY) + if (ret < 0) { + if (ret == -EBUSY) continue; - DRM_DEBUG_KMS("transaction failed: %d\n", err); - return err; + DRM_DEBUG_KMS("transaction failed: %d\n", ret); + return ret; } @@ -457,9 +459,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg) * Both native ACK and I2C ACK replies received. We * can assume the transfer was successful. */ - if (err < msg->size) - return -EPROTO; - return 0; + return ret; case DP_AUX_I2C_REPLY_NACK: DRM_DEBUG_KMS("I2C nack\n"); @@ -482,14 +482,67 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg) return -EREMOTEIO; } +/* + * Keep retrying drm_dp_i2c_do_msg until all data has been transferred. + * + * Returns an error code on failure, or a recommended transfer size on success. + */ +static int drm_dp_i2c_drain_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg) +{ + int ret; + struct drm_dp_aux_msg drain_msg; + int drain_bytes; + + ret = drm_dp_i2c_do_msg(aux, msg); + + if (ret == msg->size || ret <= 0) + return ret == 0 ? -EPROTO : ret; + + /* + * We had a partial reply. Drain out the rest of the bytes we + * originally requested, then return the size of the partial + * reply. In theory, this should match DP 1.2's desired behaviour + * for I2C over AUX. + */ + DRM_DEBUG_KMS("Partial I2C reply: requested %zu bytes got %d bytes\n", msg->size, ret); + drain_msg = *msg; + drain_msg.size -= ret; + drain_msg.buffer += ret; + while (drain_msg.size != 0) { + drain_bytes = drm_dp_i2c_do_msg(aux, &drain_msg); + if (drain_bytes <= 0) + return drain_bytes == 0 ? -EPROTO : drain_bytes; + drain_msg.size -= drain_bytes; + drain_msg.buffer += drain_bytes; + } + return ret; +} + +/* + * Bizlink designed DP->DVI-D Dual Link adapters require the I2C over AUX + * packets to be as large as possible. If not, the I2C transactions never + * succeed. Hence the default is maximum. + */ +static int dp_aux_i2c_transfer_size __read_mostly = DP_AUX_MAX_PAYLOAD_BYTES; +module_param_named(dp_aux_i2c_transfer_size, dp_aux_i2c_transfer_size, int, 0600); +MODULE_PARM_DESC(dp_aux_i2c_transfer_size, + "Number of bytes to transfer in a single I2C over DP AUX CH message, (1-16, default 16)"); + static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, int num) { struct drm_dp_aux *aux = adapter->algo_data; unsigned int i, j; + int transfer_size; struct drm_dp_aux_msg msg; int err = 0; + if (dp_aux_i2c_transfer_size < 1 || dp_aux_i2c_transfer_size > DP_AUX_MAX_PAYLOAD_BYTES) { + DRM_ERROR("dp_aux_i2c_transfer_size invalid - changing from %d to %d\n", + dp_aux_i2c_transfer_size, DP_AUX_MAX_PAYLOAD_BYTES); + dp_aux_i2c_transfer_size = DP_AUX_MAX_PAYLOAD_BYTES; + } + memset(&msg, 0, sizeof(msg)); for (i = 0; i < num; i++) { @@ -507,20 +560,20 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, struct i2c_msg *msgs, err = drm_dp_i2c_do_msg(aux, &msg); if (err < 0) break; - /* - * Many hardware implementations support FIFOs larger than a - * single byte, but it has been empirically determined that - * transferring data in larger chunks can actually lead to - * decreased performance. Therefore each message is simply - * transferred byte-by-byte. + /* We want each transaction to be as large as possible, but + * we'll go to smaller sizes if the hardware gives us a + * short reply. */ - for (j = 0; j < msgs[i].len; j++) { + transfer_size = dp_aux_i2c_transfer_size; + for (j = 0; j < msgs[i].len; j += msg.size) { msg.buffer = msgs[i].buf + j; - msg.size = 1; + msg.size = min((unsigned)transfer_size, msgs[i].len - j); - err = drm_dp_i2c_do_msg(aux, &msg); - if (err < 0) + transfer_size = drm_dp_i2c_drain_msg(aux, &msg); + if (transfer_size < 0) { + err = transfer_size; break; + } } if (err < 0) break; diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 11f8c84..444d51b 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -42,6 +42,8 @@ * 1.2 formally includes both eDP and DPI definitions. */ +#define DP_AUX_MAX_PAYLOAD_BYTES 16 + #define DP_AUX_I2C_WRITE 0x0 #define DP_AUX_I2C_READ 0x1 #define DP_AUX_I2C_STATUS 0x2 @@ -519,6 +521,9 @@ struct drm_dp_aux_msg { * transactions. The drm_dp_aux_register_i2c_bus() function registers an * I2C adapter that can be passed to drm_probe_ddc(). Upon removal, drivers * should call drm_dp_aux_unregister_i2c_bus() to remove the I2C adapter. + * The I2C adapter uses long transfers by default; if a partial response is + * received, the adapter will drop down to the size given by the partial + * response for this transaction only. * * Note that the aux helper code assumes that the .transfer() function * only modifies the reply field of the drm_dp_aux_msg structure. The -- 2.1.0

4 9

[PULL] drm-amdkfd-fixes
by Oded Gabbay 02 Feb '15

02 Feb '15

Hi Dave, Final pull request for 3.19. Three small fixes that came up during last week, nothing scary: - Accidently incremented a counter instead of decrementing it (copy-paste error) - Module parameter of max num of queues must be at least 1 and not 0 - Don't do BUG() as a result from wrong user input Thanks, Oded The following changes since commit e36f014edff70fc02b3d3d79cead1d58f289332e: Linux 3.19-rc7 (2015-02-01 20:07:21 -0800) are available in the git repository at: git://people.freedesktop.org/~gabbayo/linux tags/drm-amdkfd-fixes-2015-02-02 for you to fetch changes up to b9dce23ddc949faa8ba138f8a0811e177c991bf1: drm/amdkfd: Don't create BUG due to incorrect user parameter (2015-02-02 09:45:24 +0200) ---------------------------------------------------------------- Oded Gabbay (3): drm/amdkfd: Fix bug in accounting of queues drm/amdkfd: max num of queues can't be 0 drm/amdkfd: Don't create BUG due to incorrect user parameter drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 2 +- drivers/gpu/drm/amd/amdkfd/kfd_module.c | 4 ++-- drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 6 +++++- 3 files changed, 8 insertions(+), 4 deletions(-)

1 0

Re: [PATCH] drm/exynos: don' disable hdmi clocks for exynos5420
by Joonyoung Shim 02 Feb '15

02 Feb '15

+Cc dri-devel ML, Hi, On 01/31/2015 06:45 AM, Gustavo Padovan wrote: > From: Prathyush K <prathyush.k(a)samsung.com> > > When VPLL clock of less than 140 MHz was used and all the three > clocks - hdmiphy, hdmi, sclk_hdmi are disabled, the system hangs > during S2R when HDMI is connected. Since we want to use a vpll > clock of 70.5 MHz, we cannot disable these 3 clocks before suspending. > This patch moves the clk enable/disable of hdmi and sclk_hdmi > outside of the pm ops. Now system suspends and resumes with HDMI > connected with VPLL set at 70.5 MHz. > I think commit messages should be updated because it is different with prior posting codes. Thanks. > Signed-off-by: Prathyush K <prathyush.k(a)samsung.com> > Signed-off-by: Andrew Bresticker <abrestic(a)chromium.org> > Signed-off-by: Gustavo Padovan <gustavo.padovan(a)collabora.co.uk> > --- > drivers/gpu/drm/exynos/exynos_hdmi.c | 19 +++++++++++++++++++ > 1 file changed, 19 insertions(+) > > diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c > index 6aa0d65..0be6921 100644 > --- a/drivers/gpu/drm/exynos/exynos_hdmi.c > +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c > @@ -2254,6 +2254,20 @@ static int hdmi_resources_init(struct hdmi_context *hdata) > } else > res->reg_hdmi_en = NULL; > > + /* > + * For these two clocks exynos5420 fails to suspend if VPLL clock of > + * 70.5 MHz is used and these clocks are disabled before suspend. So > + * enable them here. > + * Note that this will keep the clocks enabled for the entire > + * lifetime of the driver and waste energy when it is suspended. > + * However it prevents the system crash until a better solution is > + * found > + */ > + if (of_machine_is_compatible("samsung,exynos5420")) { I'm not sure it's ok to use SoC compatible in driver and doesn't exynos5800 also have same issue? How about just use driver_data? Thanks. > + clk_prepare_enable(res->sclk_hdmi); > + clk_prepare_enable(res->hdmi); > + } > + > return ret; > fail: > DRM_ERROR("HDMI resource init - failed\n"); > @@ -2516,6 +2530,11 @@ static int hdmi_remove(struct platform_device *pdev) > if (hdata->res.reg_hdmi_en) > regulator_disable(hdata->res.reg_hdmi_en); > > + if (of_machine_is_compatible("samsung,exynos5420")) { > + clk_disable_unprepare(hdata->res.sclk_hdmi); > + clk_disable_unprepare(hdata->res.hdmi); > + } > + > if (hdata->hdmiphy_port) > put_device(&hdata->hdmiphy_port->dev); > put_device(&hdata->ddc_adpt->dev); >

1 0

[PATCH v3] drm/rockchip: vop: power off until vop standby take effect
by Mark Yao 02 Feb '15

02 Feb '15

Vop standby will take effect at end of current frame, if dsp_hold_valid_irq happen, it means vop standby complete. we must wait standby complete when we want to disable aclk, if not, memory bus maybe dead. Reviewed-by: Heiko Stuebner <heiko(a)sntech.de> Reviewed-by: Daniel Kurtz <djkurtz(a)chromium.org> Signed-off-by: Mark Yao <mark.yao(a)rock-chips.com> --- Changes in v3: - if vop write vop regs when vop clocks is disabled, WARN_ON maybe have no chance to do crash dump, so reuse BUG_ON. - dsp hold irq only happen when standby bit 0->1 take effect, no need to do completion check. Changes in v2: - use WARN_ON instead of BUG_ON. drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 75 ++++++++++++++++++++++----- 1 file changed, 62 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c index fb25836..68036c8 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c @@ -89,6 +89,7 @@ struct vop { /* mutex vsync_ work */ struct mutex vsync_mutex; bool vsync_work_pending; + struct completion dsp_hold_completion; const struct vop_data *data; @@ -382,6 +383,34 @@ static bool is_alpha_support(uint32_t format) } } +static void vop_dsp_hold_valid_irq_enable(struct vop *vop) +{ + unsigned long flags; + + BUG_ON(!vop->is_enabled); + + spin_lock_irqsave(&vop->irq_lock, flags); + + vop_mask_write(vop, INTR_CTRL0, DSP_HOLD_VALID_INTR_MASK, + DSP_HOLD_VALID_INTR_EN(1)); + + spin_unlock_irqrestore(&vop->irq_lock, flags); +} + +static void vop_dsp_hold_valid_irq_disable(struct vop *vop) +{ + unsigned long flags; + + BUG_ON(!vop->is_enabled); + + spin_lock_irqsave(&vop->irq_lock, flags); + + vop_mask_write(vop, INTR_CTRL0, DSP_HOLD_VALID_INTR_MASK, + DSP_HOLD_VALID_INTR_EN(0)); + + spin_unlock_irqrestore(&vop->irq_lock, flags); +} + static void vop_enable(struct drm_crtc *crtc) { struct vop *vop = to_vop(crtc); @@ -454,26 +483,36 @@ static void vop_disable(struct drm_crtc *crtc) drm_vblank_off(crtc->dev, vop->pipe); - disable_irq(vop->irq); - /* - * TODO: Since standby doesn't take effect until the next vblank, - * when we turn off dclk below, the vop is probably still active. + * Vop standby will take effect until at end of current frame, + * if dsp hold valid irq happen, it means standby complete. + * + * we must wait standby complete when we want to disable aclk, + * if not, memory bus maybe dead. */ + reinit_completion(&vop->dsp_hold_completion); + vop_dsp_hold_valid_irq_enable(vop); + spin_lock(&vop->reg_lock); VOP_CTRL_SET(vop, standby, 1); spin_unlock(&vop->reg_lock); + wait_for_completion(&vop->dsp_hold_completion); + + vop_dsp_hold_valid_irq_disable(vop); + + disable_irq(vop->irq); + vop->is_enabled = false; + /* - * disable dclk to stop frame scan, so we can safely detach iommu, + * vop standby complete, so iommu detach is safe. */ - clk_disable(vop->dclk); - rockchip_drm_dma_detach_device(vop->drm_dev, vop->dev); + clk_disable(vop->dclk); clk_disable(vop->aclk); clk_disable(vop->hclk); } @@ -1086,6 +1125,7 @@ static irqreturn_t vop_isr(int irq, void *data) struct vop *vop = data; uint32_t intr0_reg, active_irqs; unsigned long flags; + int ret = IRQ_NONE; /* * INTR_CTRL0 register has interrupt status, enable and clear bits, we @@ -1104,15 +1144,23 @@ static irqreturn_t vop_isr(int irq, void *data) if (!active_irqs) return IRQ_NONE; - /* Only Frame Start Interrupt is enabled; other irqs are spurious. */ - if (!(active_irqs & FS_INTR)) { - DRM_ERROR("Unknown VOP IRQs: %#02x\n", active_irqs); - return IRQ_NONE; + if (active_irqs & DSP_HOLD_VALID_INTR) { + complete(&vop->dsp_hold_completion); + active_irqs &= ~DSP_HOLD_VALID_INTR; + ret = IRQ_HANDLED; } - drm_handle_vblank(vop->drm_dev, vop->pipe); + if (active_irqs & FS_INTR) { + drm_handle_vblank(vop->drm_dev, vop->pipe); + active_irqs &= ~FS_INTR; + ret = (vop->vsync_work_pending) ? IRQ_WAKE_THREAD : IRQ_HANDLED; + } - return (vop->vsync_work_pending) ? IRQ_WAKE_THREAD : IRQ_HANDLED; + /* Unhandled irqs are spurious. */ + if (active_irqs) + DRM_ERROR("Unknown VOP IRQs: %#02x\n", active_irqs); + + return ret; } static int vop_create_crtc(struct vop *vop) @@ -1194,6 +1242,7 @@ static int vop_create_crtc(struct vop *vop) goto err_cleanup_crtc; } + init_completion(&vop->dsp_hold_completion); crtc->port = port; vop->pipe = drm_crtc_index(crtc); rockchip_register_crtc_funcs(drm_dev, &private_crtc_funcs, vop->pipe); -- 1.7.9.5

1 0

[PATCH] drm/rockchip: fix clk enable disable mismatch in vop_crtc_mode_set
by Heiko Stübner 02 Feb '15

02 Feb '15

The function disables the dclk at the beginning, so don't simply return when an error happens, but instead enable the clock again, so that enable and disable calls are balanced. ret_clk is introduced to hold the clk_enable result and not mangle the original error code. Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> --- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c index 04b619a..c0387f7 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c @@ -852,7 +852,7 @@ static int vop_crtc_mode_set(struct drm_crtc *crtc, u16 vsync_len = adjusted_mode->vsync_end - adjusted_mode->vsync_start; u16 vact_st = adjusted_mode->vtotal - adjusted_mode->vsync_start; u16 vact_end = vact_st + vdisplay; - int ret; + int ret, ret_clk; uint32_t val; /* @@ -874,7 +874,8 @@ static int vop_crtc_mode_set(struct drm_crtc *crtc, default: DRM_ERROR("unsupport connector_type[%d]\n", vop->connector_type); - return -EINVAL; + ret = -EINVAL; + goto out; }; VOP_CTRL_SET(vop, out_mode, vop->connector_out_mode); @@ -897,7 +898,7 @@ static int vop_crtc_mode_set(struct drm_crtc *crtc, ret = vop_crtc_mode_set_base(crtc, x, y, fb); if (ret) - return ret; + goto out; /* * reset dclk, take all mode config affect, so the clk would run in @@ -908,13 +909,14 @@ static int vop_crtc_mode_set(struct drm_crtc *crtc, reset_control_deassert(vop->dclk_rst); clk_set_rate(vop->dclk, adjusted_mode->clock * 1000); - ret = clk_enable(vop->dclk); - if (ret < 0) { - dev_err(vop->dev, "failed to enable dclk - %d\n", ret); - return ret; +out: + ret_clk = clk_enable(vop->dclk); + if (ret_clk < 0) { + dev_err(vop->dev, "failed to enable dclk - %d\n", ret_clk); + return ret_clk; } - return 0; + return ret; } static void vop_crtc_commit(struct drm_crtc *crtc) -- 2.1.1

2 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2015