[Nouveau] [PATCH REBASED 2/2] nouveau/bl: Do not register interface if Apple GMUX detected
Hi,
On Sun, Apr 17, 2016 at 09:57:42PM +0200, Pierre Moreau wrote:
> The Apple GMUX is the one managing the backlight, so there is no need for
> Nouveau to register its own backlight interface.
>
> Signed-off-by: Pierre Moreau
> ---
> drm/nouveau/nouveau_backlight.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drm/nouveau/nouveau_backlight.c b/drm/nouveau/nouveau_backlight.c
> index 41330e4..94ac3cb 100644
> --- a/drm/nouveau/nouveau_backlight.c
> +++ b/drm/nouveau/nouveau_backlight.c
> @@ -30,6 +30,7 @@
> * Register locations derived from NVClock by Roderick Colenbrander
> */
>
> +#include
> #include
> #include
>
> @@ -257,6 +258,12 @@ nouveau_backlight_init(struct drm_device *dev)
> struct nvif_device *device = &drm->device;
> struct drm_connector *connector;
>
> + if (apple_gmux_present()) {
> + NV_INFO(drm, "Apple GMUX detected: not registering Nouveau"
> + " backlight interface");
Small nit -- Documentation/CodingStyle, chapter 2 says:
"However, never break user-visible strings such as
printk messages, because that breaks the ability to grep for them."
Thanks,
Lukas
> + return 0;
> + }
> +
> INIT_LIST_HEAD(&drm->bl_connectors);
>
> list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
> --
> 2.8.0
[PATCH REBASED 2/2] nouveau/bl: Do not register interface if Apple GMUX detected
The Apple GMUX is the one managing the backlight, so there is no need for
Nouveau to register its own backlight interface.
Signed-off-by: Pierre Moreau
---
drm/nouveau/nouveau_backlight.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drm/nouveau/nouveau_backlight.c b/drm/nouveau/nouveau_backlight.c
index 41330e4..94ac3cb 100644
--- a/drm/nouveau/nouveau_backlight.c
+++ b/drm/nouveau/nouveau_backlight.c
@@ -30,6 +30,7 @@
* Register locations derived from NVClock by Roderick Colenbrander
*/
+#include
#include
#include
@@ -257,6 +258,12 @@ nouveau_backlight_init(struct drm_device *dev)
struct nvif_device *device = &drm->device;
struct drm_connector *connector;
+ if (apple_gmux_present()) {
+ NV_INFO(drm, "Apple GMUX detected: not registering Nouveau"
+ " backlight interface");
+ return 0;
+ }
+
INIT_LIST_HEAD(&drm->bl_connectors);
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
--
2.8.0
[PATCH v2 1/2] nouveau/bl: Assign different names to interfaces
Currently, every backlight interface created by Nouveau uses the same name,
nv_backlight. This leads to a sysfs warning as it tries to create an already
existing folder. This patch adds a incremented number to the name, but keeps
the initial name as nv_backlight, to avoid possibly breaking userspace; the
second interface will be named nv_backlight1, and so on.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86539
v2:
* Switch to using ida for generating unique IDs, as suggested by Ilia Mirkin;
* Allocate backlight name on the stack, as suggested by Ilia Mirkin;
* Move `nouveau_get_backlight_name()` to avoid forward declaration, as
suggested by Ilia Mirkin;
* Fix reference to bug report formatting, as reported by Nick Tenney.
Signed-off-by: Pierre Moreau
---
drm/nouveau/nouveau_backlight.c | 64 ++---
drm/nouveau/nouveau_display.h | 10 +++
drm/nouveau/nouveau_drm.c | 2 ++
drm/nouveau/nouveau_drm.h | 1 +
4 files changed, 73 insertions(+), 4 deletions(-)
diff --git a/drm/nouveau/nouveau_backlight.c b/drm/nouveau/nouveau_backlight.c
index 89eb460..41330e4 100644
--- a/drm/nouveau/nouveau_backlight.c
+++ b/drm/nouveau/nouveau_backlight.c
@@ -31,11 +31,31 @@
*/
#include
+#include
#include "nouveau_drm.h"
#include "nouveau_reg.h"
#include "nouveau_encoder.h"
+static struct ida bl_ida;
+
+struct backlight_connector {
+ struct list_head head;
+ int id;
+};
+
+static void
+nouveau_get_backlight_name(char backlight_name[15], struct backlight_connector
+ *connector)
+{
+ const int nb = ida_simple_get(&bl_ida, 0, 0, GFP_KERNEL);
+ if (nb > 0 && nb < 100)
+ sprintf(backlight_name, "nv_backlight%d", nb);
+ else
+ sprintf(backlight_name, "nv_backlight");
+ connector->id = nb;
+}
+
static int
nv40_get_intensity(struct backlight_device *bd)
{
@@ -74,6 +94,8 @@ nv40_backlight_init(struct drm_connector *connector)
struct nvif_object *device = &drm->device.object;
struct backlight_properties props;
struct backlight_device *bd;
+ struct backlight_connector bl_connector;
+ char backlight_name[15]; // 12 for name + 2 for digits + 1 for '\0'
if (!(nvif_rd32(device, NV40_PMC_BACKLIGHT) & NV40_PMC_BACKLIGHT_MASK))
return 0;
@@ -81,10 +103,16 @@ nv40_backlight_init(struct drm_connector *connector)
memset(&props, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
props.max_brightness = 31;
- bd = backlight_device_register("nv_backlight", connector->kdev, drm,
+ nouveau_get_backlight_name(backlight_name, &bl_connector);
+ bd = backlight_device_register(backlight_name , connector->kdev, drm,
&nv40_bl_ops, &props);
- if (IS_ERR(bd))
+
+ if (IS_ERR(bd)) {
+ if (bl_connector.id > 0)
+ ida_simple_remove(&bl_ida, bl_connector.id);
return PTR_ERR(bd);
+ }
+ list_add(&bl_connector.head, &drm->bl_connectors);
drm->backlight = bd;
bd->props.brightness = nv40_get_intensity(bd);
backlight_update_status(bd);
@@ -182,6 +210,8 @@ nv50_backlight_init(struct drm_connector *connector)
struct backlight_properties props;
struct backlight_device *bd;
const struct backlight_ops *ops;
+ struct backlight_connector bl_connector;
+ char backlight_name[15]; // 12 for name + 2 for digits + 1 for '\0'
nv_encoder = find_encoder(connector, DCB_OUTPUT_LVDS);
if (!nv_encoder) {
@@ -203,11 +233,17 @@ nv50_backlight_init(struct drm_connector *connector)
memset(&props, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
props.max_brightness = 100;
- bd = backlight_device_register("nv_backlight", connector->kdev,
+ nouveau_get_backlight_name(backlight_name, &bl_connector);
+ bd = backlight_device_register(backlight_name , connector->kdev,
nv_encoder, ops, &props);
- if (IS_ERR(bd))
+
+ if (IS_ERR(bd)) {
+ if (bl_connector.id > 0)
+ ida_simple_remove(&bl_ida, bl_connector.id);
return PTR_ERR(bd);
+ }
+ list_add(&bl_connector.head, &drm->bl_connectors);
drm->backlight = bd;
bd->props.brightness = bd->ops->get_brightness(bd);
backlight_update_status(bd);
@@ -221,6 +257,8 @@ nouveau_backlight_init(struct drm_device *dev)
struct nvif_device *device = &drm->device;
struct drm_connector *connector;
+ INIT_LIST_HEAD(&drm->bl_connectors);
+
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
if (connector->connector_type != DRM_MODE_CONNECTOR_LVDS &&
connector->connector_type != DRM_MODE_CONNECTOR_eDP)
@@ -246,9 +284,27 @@ void
[Bug 94984] XCom2 crashes with SIGSEGV on radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=94984 --- Comment #1 from kuehner.moritz at gmail.com --- Created attachment 123017 --> https://bugs.freedesktop.org/attachment.cgi?id=123017&action=edit glxinfo output -- 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/20160417/dfa77fc5/attachment.html>
[Bug 94984] XCom2 crashes with SIGSEGV on radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=94984 Bug ID: 94984 Summary: XCom2 crashes with SIGSEGV on radeonsi Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: kuehner.moritz at gmail.com QA Contact: dri-devel at lists.freedesktop.org Created attachment 123016 --> https://bugs.freedesktop.org/attachment.cgi?id=123016&action=edit gdb backtrace At the start of a mission XCom2 crashes the moment when the drop solders of cut scene ends. It doesn't happen in all maps only in this one as far as I can tell. I'm running Ubuntu 16.04 on an skylake CPU with a R9 380X. The crash happens with stock Ubuntu mesa (11.2) as well as with mesa git (git160414232200.eeff133) from padoka PPA. I tried to create a apitrace, but for some reason I can not get XCom2 to start with "apitrace trace" in front of it. Are there any apitrace ninja secrets to tracing steam games ;-)? (The game is 64bit so thats not the problem). -- 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/20160417/43c8b6f2/attachment.html>
[PATCH v3 0/7] drm/i2c: adv7511: ADV7533 support
Hi Archit, Thank you for the patches. On 9 March 2016 at 18:57, Archit Taneja wrote: > ADV7533 is a DSI to HDMI encoder chip. It's like ADV7511, but with an > additional DSI RX block that takes in DSI video mode output. > > Trying to get this driver merged has had some challenges: > > - ADV7533 has an I2C control bus, but acts as a DSI peripheral too. > After discussions, it was concluded that we'd want to provide an > API to create MIPI DSI devices, rather than expose two different > interfaces on DT. The first version [1] tried the former approach > the second version [2] showed how the driver would look like if > exposed 2 DT nodes. This lateset patchset relies on the MIPI DSI > device creation API provided by [3], this has been accepted and > should be merged for 4.6. > > - The driver was designed as an I2C slave encoder. When ADV7533 > patches were posted [1], it was modelled as a bridge, but ADV7511 > and others were still left as I2C slave encoders. This wasn't > accepted. After discussions, it was decided that ADV7511 too would > be converted into a bridge driver, and all the users of ADV7511 > should assume it is a bridge. This bridge conversion was done in > [4]. There is still some debate over whether the bridge driver be > involved in the connector creation, or the KMS driver that has > the whole view of the display pipeline. This discussion shouldn't > affect this patch set, though. I also agree with Laurent Pinchart that bridge driver shoudn't get involved in in the connector creation. It is better for KMS driver that has the whole view of the display pipeline. In this case, I mean creating bridge driver to support ADV7533. I think this is something look like panel driver. Maybe we need to add some callback to the bridge to avoid creating connector in bridge driver. We can refer to panel entity to see what callbacks to be added. One callback I can see is the get_modes callback might be need. > > This patch set enables ADV7533 support with the above two issues > now resolved. It also incorporates ADV7533 specific features and fixes > that we've discovered since the first version of this patch was posted. > > Tested on ADV7533 chips on DB410c. It should work on the Hikey board too. I have tested the this tracking branch : https://git.linaro.org/landing-teams/working/qualcomm/kernel.git/shortlog/refs/heads/tracking-qcomlt-adv7511 it works for HiKey. But it seems this patch set is a little different from the above branch. I think I need to tested this patch set. Thanks, -xinliang > I'd appreaciate if someone could test it on a ADV7511 platform since I > don't have one. > > [4] > https://lists.freedesktop.org/archives/dri-devel/2016-January/098287.html > > [3] > https://lkml.org/lkml/2016/2/12/67 > > [2] > https://lists.freedesktop.org/archives/dri-devel/2015-September/089884.html > > [1]: > https://lists.freedesktop.org/archives/dri-devel/2015-July/087088.html > > Archit Taneja (7): > drm/i2c: adv7511: Convert to drm_bridge > drm/i2c: adv7511: Fix mutex deadlock when interrupts are disabled > drm/i2c: adv7511: Initial support for ADV7533 > drm/i2c: adv7511: Create a MIPI DSI device > drm/i2c: adv7511: Use internal timing generator > drm/i2c: adv7511: Change number of DSI lanes dynamically > dt-bindings: drm/bridge: Update bindings for ADV7533 > > .../bindings/display/bridge/adi,adv7511.txt| 25 +- > drivers/gpu/drm/i2c/adv7511.c | 539 > + > 2 files changed, 476 insertions(+), 88 deletions(-) > > -- > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > hosted by The Linux Foundation >
[PATCH 2/2 v2] drm/amd/powerplay/hwmgr: don't add invalid voltage
if atomctrl_get_voltage_evv_on_sclk returns non zero (fail) in the expansion
of the PP_ASSERT_WITH_CODE macro the continue will actually do nothing
(The macro uses a do ... while(0) as scope, which eats the continue).
Based on the code I don't think this was the intent.
Unfortunately fixing this requires rewriting the control flow and
removing the macros.
v2: added signed of by
fixed error message print
Signed-off-by: Moritz Kühner
---
drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c | 54 +--
1 file changed, 30 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c
index 50afb02..0f264c4 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c
@@ -429,19 +429,22 @@ int tonga_get_evv_voltage(struct pp_hwmgr *hwmgr)
}
}
}
- PP_ASSERT_WITH_CODE(0 ==
atomctrl_get_voltage_evv_on_sclk
+ if(0 == atomctrl_get_voltage_evv_on_sclk
(hwmgr, VOLTAGE_TYPE_VDDGFX,
sclk,
-virtual_voltage_id, &vddgfx),
- "Error retrieving EVV voltage
value!", continue);
-
- /* need to make sure vddgfx is less than 2v or
else, it could burn the ASIC. */
- PP_ASSERT_WITH_CODE((vddgfx < 2000 && vddgfx !=
0), "Invalid VDDGFX value!", return -1);
-
- /* the voltage should not be zero nor equal to
leakage ID */
- if (vddgfx != 0 && vddgfx !=
virtual_voltage_id) {
-
data->vddcgfx_leakage.actual_voltage[data->vddcgfx_leakage.count] = vddgfx;
-
data->vddcgfx_leakage.leakage_id[data->vddcgfx_leakage.count] =
virtual_voltage_id;
- data->vddcgfx_leakage.count++;
+virtual_voltage_id, &vddgfx)) {
+ /* need to make sure vddgfx is less
than 2v or else, it could burn the ASIC. */
+ PP_ASSERT_WITH_CODE((vddgfx < 2000 &&
vddgfx != 0), "Invalid VDDGFX value!", return -1);
+
+ /* the voltage should not be zero nor
equal to leakage ID */
+ if (vddgfx != 0 && vddgfx !=
virtual_voltage_id) {
+
data->vddcgfx_leakage.actual_voltage[data->vddcgfx_leakage.count] = vddgfx;
+
data->vddcgfx_leakage.leakage_id[data->vddcgfx_leakage.count] =
virtual_voltage_id;
+ data->vddcgfx_leakage.count++;
+ }
+ }
+ else
+ {
+ DRM_ERROR("Error retrieving EVV voltage
value!\n");
}
}
} else {
@@ -449,19 +452,22 @@ int tonga_get_evv_voltage(struct pp_hwmgr *hwmgr)
if (0 == tonga_get_sclk_for_voltage_evv(hwmgr,
pptable_info->vddc_lookup_table,
virtual_voltage_id, &sclk)) {
- PP_ASSERT_WITH_CODE(0 ==
atomctrl_get_voltage_evv_on_sclk
+ if(0 == atomctrl_get_voltage_evv_on_sclk
(hwmgr, VOLTAGE_TYPE_VDDC, sclk,
-virtual_voltage_id, &vddc),
- "Error retrieving EVV voltage
value!", continue);
-
- /* need to make sure vddc is less than 2v or
else, it could burn the ASIC. */
- PP_ASSERT_WITH_CODE(vddc < 2000, "Invalid VDDC
value!", return -1);
-
- /* the voltage should not be zero nor equal to
leakage ID */
- if (vddc != 0 && vddc != virtual_voltage_id) {
-
data->vddc_leakage.actual_voltage[data->vddc_leakage.count] = vddc;
-
data->vddc_leakage.leakage_id[data->vddc_leakage.count] = virtual_voltage_id;
- data->vddc_leakage.count++;
+virtual_voltage_id, &vddc)) {
+ /* need to make sure vddc is less than
2v or else, it could burn the ASIC. */
+
[PATCH 1/2 v2] drm/amd/powerplay/hwmgr: prevent VDDC from exceeding 2V
If the tonga gpu is controlled by SVID2 tonga_get_evv_voltage will only print
an error if the voltage exceeds 2V although a comment clearly states that it
needs be less than 2V.
v2: added signed of by
Signed-off-by: Moritz Kühner
---
drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c
index 0d5d837..50afb02 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c
@@ -455,8 +455,7 @@ int tonga_get_evv_voltage(struct pp_hwmgr *hwmgr)
"Error retrieving EVV voltage
value!", continue);
/* need to make sure vddc is less than 2v or
else, it could burn the ASIC. */
- if (vddc > 2000)
- printk(KERN_ERR "[ powerplay ] Invalid
VDDC value! \n");
+ PP_ASSERT_WITH_CODE(vddc < 2000, "Invalid VDDC
value!", return -1);
/* the voltage should not be zero nor equal to
leakage ID */
if (vddc != 0 && vddc != virtual_voltage_id) {
--
2.7.4
[PATCH 0/2 v2] tonga_get_evv_voltage error handling fixes
I got myself a 380X recently and started reading random mesa and kernel code in the hopes that I would find something that I can fix or improve, and something actually caught my eye. Some of the error handling in tonga_get_evv_voltage just seemed of and based on the comments I think the patches provided will do the intended thing. While I did test the patch I have to admit that i did not try what happens when I apply 2V to my card ;-). PS: This is my first submission. So... please tell me if I did something wrong. v2: added signed of by fixed error message print Moritz Kühner (2): drm/amd/powerplay/hwmgr: prevent VDDC from exceeding 2V drm/amd/powerplay/hwmgr: don't add invalid voltage drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c | 55 --- 1 file changed, 30 insertions(+), 25 deletions(-) -- 2.7.4
[PATCH] hsakmt: allow building with gcc 4.x v2
On Wed, Mar 30, 2016 at 2:12 AM, Bridgman, John
wrote:
> The hsakmt code requires C99 compiler support, however gcc 4.x
> defaults to C89 (gcc 5 defaults to C11). v2 patch copies code
> from libdrm, using AC_PROG_CC_C99 and checking success.
>
> v1 used AC_PROG_CC_STDC and did not check C99 was enabled.
>
> Signed-off-by: John Bridgman
> ---
> configure.ac | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/configure.ac b/configure.ac
> index b8e9bea..0111067 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -66,6 +66,12 @@ AC_CANONICAL_HOST
> AC_PROG_AWK
> test_CFLAGS=${CFLAGS+set} # We may override autoconf default CFLAGS.
> AC_PROG_CC
> +AC_PROG_CC_C99
> +
> +if test "x$ac_cv_prog_cc_c99" = xno; then
> + AC_MSG_ERROR([Building hsakmt requires C99 enabled compiler])
> +fi
> +
> AC_PROG_INSTALL
> AC_PROG_LIBTOOL
> AC_PROG_MAKE_SET
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Thanks John,
Reviewed-by: Oded Gabbay
Can you push it to the repo ?
If you get permission error, we need to set-up permissions.
Oded
[Nouveau] [PATCH 1/2] nouveau/bl: Assign different names to interfaces
[â¦] > > > + const int nb = atomic_inc_return(&bl_interfaces_nb) - 1; > > This kinda sucks if you reload nouveau a bunch. How about using an > "ida". Have a look in drivers/gpu/drm/drm_crtc.c for how I use that > one. I had a quick look at drm_crtc.c. This seems to be exactly what I need, except that I do not see how I can enforce to have one of the active ones being named `nv_backlight`, to not break (possibly) existing userspace applications. (Iâm guessing that I would be doing the same as in drm_crtc.c: looping over all connectors and assigning them an ida, regardless of them being active or not, as they might become active later on.) There is another issue that I failed to address with this patch, and just realised about it. Each time `nvXX_backlight_init(connector)` is called on a connector, a new backlight device is created, and is stored in `drm->backlight`, which is unique at a device level, not connector level, meaning the old one just gets overriden (and leaked). Having a list `drm->backlights` should solve this issue. Would that be fine with you Ben? Pierre > > > + if (nb > 0 && nb < 100) > > + sprintf(backlight_name, "nv_backlight%d", nb); > > + else > > + sprintf(backlight_name, "nv_backlight"); > > + return backlight_name; > > +} > > -- > > 2.8.0 > > > > ___ > > Nouveau mailing list > > Nouveau at lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/nouveau -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160417/872a5f51/attachment.sig>
[Bug 94874] radeon: Failed to allocate virtual address for buffer
https://bugs.freedesktop.org/show_bug.cgi?id=94874 --- Comment #6 from Paulo Dias --- i get this when i try to run a game on steam, this error is after the first successful run as always: Abr 16 22:53:20 hydra kernel: WARNING: CPU: 1 PID: 5857 at drivers/gpu/drm/radeon/radeon_object.c:84 radeon_ttm_bo_destroy+0xea/0xf0 [radeon] Abr 16 22:53:20 hydra kernel: Modules linked in: uas usb_storage drbg ansi_cprng ctr ccm cmac rfcomm bnep rtsx_usb_ms memstick pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) binfmt_misc nls_iso8859_1 uvcvideo videobuf2_vmalloc dcdbas videobuf2_memops videobuf2_v4l2 videobuf2_core dell_smm_hwmon videodev ath3k btusb btrtl media btbcm btintel snd_hda_codec_realtek intel_rapl bluetooth snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp snd_hda_intel coretemp kvm_intel snd_hda_codec kvm irqbypass snd_hda_core snd_hwdep crct10dif_pclmul crc32_pclmul arc4 snd_pcm ghash_clmulni_intel aesni_intel ath9k aes_x86_64 lrw gf128mul snd_seq_midi ath9k_common glue_helper snd_seq_midi_event ablk_helper cryptd snd_rawmidi ath9k_hw ath input_leds joydev snd_seq mac80211 snd_seq_device snd_timer serio_raw snd Abr 16 22:53:20 hydra kernel: lpc_ich cfg80211 mei_me soundcore mei shpchp mac_hid soc_button_array dell_rbtn parport_pc ppdev lp parport autofs4 btrfs xor raid6_pq rtsx_usb_sdmmc rtsx_usb hid_generic usbhid hid amdkfd amd_iommu_v2 radeon i915 ttm i2c_algo_bit drm_kms_helper psmouse syscopyarea ahci sysfillrect sysimgblt libahci fb_sys_fops drm r8169 mii wmi video fjes Abr 16 22:53:20 hydra kernel: CPU: 1 PID: 5857 Comm: SatelliteReignL Tainted: G W OE 4.6.0-rc2-custom #4 Abr 16 22:53:20 hydra kernel: Hardware name: Dell Inc. Latitude 3540/02R0J9, BIOS A10 01/28/2015 Abr 16 22:53:20 hydra kernel: 0286 910ea653 8800c8a639a0 813ee293 Abr 16 22:53:20 hydra kernel: 8800c8a639e0 8108269b Abr 16 22:53:20 hydra kernel: 0054811db4e1 880115fe5068 880115fe5000 Abr 16 22:53:20 hydra kernel: Call Trace: Abr 16 22:53:20 hydra kernel: [] dump_stack+0x63/0x90 Abr 16 22:53:20 hydra kernel: [] __warn+0xcb/0xf0 Abr 16 22:53:20 hydra kernel: [] warn_slowpath_null+0x1d/0x20 Abr 16 22:53:20 hydra kernel: [] radeon_ttm_bo_destroy+0xea/0xf0 [radeon] Abr 16 22:53:20 hydra kernel: [] ttm_bo_release_list+0xa4/0x140 [ttm] Abr 16 22:53:20 hydra kernel: [] ttm_bo_release+0x1ee/0x2d0 [ttm] Abr 16 22:53:20 hydra kernel: [] ttm_bo_unref+0x24/0x30 [ttm] Abr 16 22:53:20 hydra kernel: [] radeon_bo_unref+0x39/0x70 [radeon] Abr 16 22:53:20 hydra kernel: [] radeon_gem_object_free+0x57/0x70 [radeon] Abr 16 22:53:20 hydra kernel: [] drm_gem_object_free+0x30/0x50 [drm] Abr 16 22:53:20 hydra kernel: [] drm_gem_object_handle_unreference_unlocked+0xc4/0x110 [drm] Abr 16 22:53:20 hydra kernel: [] drm_gem_object_release_handle+0x55/0xa0 [drm] Abr 16 22:53:20 hydra kernel: [] idr_for_each+0xae/0x110 Abr 16 22:53:20 hydra kernel: [] ? drm_gem_object_handle_unreference_unlocked+0x110/0x110 [drm] Abr 16 22:53:20 hydra kernel: [] drm_gem_release+0x20/0x30 [drm] Abr 16 22:53:20 hydra kernel: [] drm_release+0x3e3/0x4d0 [drm] Abr 16 22:53:20 hydra kernel: [] __fput+0xe7/0x230 Abr 16 22:53:20 hydra kernel: [] fput+0xe/0x10 Abr 16 22:53:20 hydra kernel: [] task_work_run+0x73/0x90 Abr 16 22:53:20 hydra kernel: [] do_exit+0x2e7/0xb50 Abr 16 22:53:20 hydra kernel: [] do_group_exit+0x43/0xb0 Abr 16 22:53:20 hydra kernel: [] get_signal+0x28f/0x600 Abr 16 22:53:20 hydra kernel: [] do_signal+0x37/0x770 Abr 16 22:53:20 hydra kernel: [] ? do_send_sig_info+0x6c/0xa0 Abr 16 22:53:20 hydra kernel: [] exit_to_usermode_loop+0x8c/0xd0 Abr 16 22:53:20 hydra kernel: [] syscall_return_slowpath+0x4e/0x60 Abr 16 22:53:20 hydra kernel: [] entry_SYSCALL_64_fastpath+0xa6/0xa8 Abr 16 22:53:20 hydra kernel: ---[ end trace 01c303ed186e23a9 ]--- -- 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/20160417/0b439c48/attachment.html>
[PATCH v2] drm/msm: Use 64-bit timekeeping
On Wednesday 13 April 2016 02:52:14 Tina Ruchandani wrote: > ktime_t rem = ktime_sub(*timeout, now); > - struct timespec ts = ktime_to_timespec(rem); > - remaining_jiffies = timespec_to_jiffies(&ts); > + struct timespec64 ts = ktime_to_timespec64(rem); > + > + remaining_jiffies = timespec64_to_jiffies(&ts); > Hi Tina, The change looks correct to me, but I wonder if we should optimize this code a little more, as it does two expensive 64-bit divisions. How about remaining_jiffies = msecs_to_jiffies(ktime_ms_delta(*timeout, now)); which only does one 64-bit division, and it's one that we can probably optimize out in the future (we can check in ktime_ms_delta whether the difference is more than 2^32 nanoseconds as the fast path). Arnd
[Y2038] [PATCH] drm/sti: Use 64-bit timestamps
On Wednesday 13 April 2016 02:28:02 Tina Ruchandani wrote:
> 'struct timespec' uses a 32-bit field for seconds, which
> will overflow in year 2038 and beyond. This patch is part
> of a larger attempt to remove instances of timeval, timespec
> and time_t, all of which suffer from the y2038 issue, from the
> kernel.
>
> Signed-off-by: Tina Ruchandani
Looks good in principle. Two small points:
> void sti_plane_update_fps(struct sti_plane *plane,
> bool new_frame,
> bool new_field)
> {
> - struct timespec now;
> + ktime_t now;
> struct sti_fps_info *fps;
> int fpks, fipks, ms_since_last, num_frames, num_fields;
>
> - getrawmonotonic(&now);
> + now = ktime_get();
It's unclear why the driver was using getrawmonotonic() here rather
than ktime_get_ts(). The code is fairly new, so Vincent can
probably explain this.
If it was intentional, we should use ktime_get_raw() instead of
ktime_get().
> @@ -76,7 +66,7 @@ void sti_plane_update_fps(struct sti_plane *plane,
> return;
>
> fps->curr_frame_counter++;
> - ms_since_last = sti_plane_timespec_ms_diff(now, fps->last_timestamp);
> + ms_since_last = ktime_to_ms(ktime_sub(now, fps->last_timestamp));
> num_frames = fps->curr_frame_counter - fps->last_frame_counter;
This could be expressed in a more compact way using ktime_ms_delta().
Arnd
