Re: [Intel-gfx] [PATCH] drm/mm: Support 4 GiB and larger ranges
On Tue, Jan 27, 2015 at 07:07:44AM +0100, Thomas Hellstrom wrote: > On 01/26/2015 11:51 PM, Dave Airlie wrote: > > On 23 January 2015 at 18:05, Thierry Reding > > wrote: > >> From: Thierry Reding > >> > >> The current implementation is limited by the number of addresses that > >> fit into an unsigned long. This causes problems on 32-bit Tegra where > >> unsigned long is 32-bit but drm_mm is used to manage an IOVA space of > >> 4 GiB. Given the 32-bit limitation, the range is limited to 4 GiB - 1 > >> (or 4 GiB - 4 KiB for page granularity). > >> > >> This commit changes the start and size of the range to be an unsigned > >> 64-bit integer, thus allowing much larger ranges to be supported. > > This seems fine to me, Chris, Daniel or Thomas, any objections? > > > > Dave. > > This is perfectly fine with me, although I'm a bit curious why the > allocation granularity of the IOVA space needs to be 1 byte? Are you referring to the 4 GiB - 1 comment? The point I was trying to make is not that the granularity of the IOVA space needs to be 1 byte but rather that using an unsigned long for a size on a 32-bit machine will give you 4 GiB - 1 addresses. The IOMMU page size is still 4 KiB for Tegra. Thierry pgpMf8OYOSedY.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/mm: Support 4 GiB and larger ranges
On 01/27/2015 09:15 AM, Thierry Reding wrote: > On Tue, Jan 27, 2015 at 07:07:44AM +0100, Thomas Hellstrom wrote: >> On 01/26/2015 11:51 PM, Dave Airlie wrote: >>> On 23 January 2015 at 18:05, Thierry Reding wrote: From: Thierry Reding The current implementation is limited by the number of addresses that fit into an unsigned long. This causes problems on 32-bit Tegra where unsigned long is 32-bit but drm_mm is used to manage an IOVA space of 4 GiB. Given the 32-bit limitation, the range is limited to 4 GiB - 1 (or 4 GiB - 4 KiB for page granularity). This commit changes the start and size of the range to be an unsigned 64-bit integer, thus allowing much larger ranges to be supported. >>> This seems fine to me, Chris, Daniel or Thomas, any objections? >>> >>> Dave. >> >> This is perfectly fine with me, although I'm a bit curious why the >> allocation granularity of the IOVA space needs to be 1 byte? > > Are you referring to the 4 GiB - 1 comment? The point I was trying to > make is not that the granularity of the IOVA space needs to be 1 byte > but rather that using an unsigned long for a size on a 32-bit machine > will give you 4 GiB - 1 addresses. The IOMMU page size is still 4 KiB > for Tegra. I was rather referring to that if the range manager (drm_mm) is set up to manage pages instead of bytes (like, for example, the TTM VM address space), you'd get 4G - 1 pages, which, I believe, is sufficient on most 32 bit systems? Thanks, /Thomas > > Thierry ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 05/12] drm/i915/dsi: remove unnecessary dsi device callbacks
On 01/23/2015 08:52 PM, Daniel Vetter wrote: On Fri, Jan 23, 2015 at 03:14:41PM +0530, Shobhit Kumar wrote: On 01/22/2015 06:53 PM, Jani Nikula wrote: On Thu, 22 Jan 2015, Shobhit Kumar wrote: There had been a instance where we had to drive different resolution (lower) than the native one. Also in VBT there is a field to make this generic at least from driver perspective to give the needed target resolution. In case target resolution is same as native, nothing gets changed, else mode_fixup function adjusts the mode accordingly keeping timing as same and enabling scalar. Might not be useful in general, but did find a use internally. Can we just have the driver return the desired mode from .get_modes in that case? Okay, I think I did not explain correctly. Get modes is modified to give the needed target mode only so that userspace creates buffer of the needed resolution, but in fixup which is called at modeset, we correct the adjusted_mode back to have native resolutions so that modeset is correctly done. if we do not do like this, during modeset resolutions will be wrong as per the timings. I'm confused. Can you please give an example in real numbers about the different resolution and how it's all fixed up in hw? E.g. 800x600 framebuffer -> pfit -> 1024x756 panel, get_modes gives 800x600, adjusted mode corrects to 1024x756. And please We had a 19x12 DSI panel which we needed to drive at 12x8 due to lack of 12x8 panels for testing purposes. So get_modes returned 12x8 so that user space gave 12x8 FBs, and internally in mode_fixup we adjusted correctly for the 19x12 panel timings and enabled pfit mention what vbt has to do in all this too. VBT allows to avoid panel specific and build specific hard coding in the code, which should work as is for normal 19x12 usage as well. Block #42 panel xres and yres are used to indicate this lower needed resolution when different from panel_fixed_mode. Regards Shobhit I think I need an example since I can't figure out what exactly your describing ... Thanks, Daniel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 07/12] drm/i915/dsi: switch to drm_panel interface
On 01/23/2015 09:01 PM, Daniel Vetter wrote:
On Fri, Jan 23, 2015 at 04:27:46PM +0530, Shobhit Kumar wrote:
On 01/16/2015 05:57 PM, Jani Nikula wrote:
@@ -881,13 +889,23 @@ void intel_dsi_init(struct drm_device *dev)
drm_connector_register(connector);
- fixed_mode = dsi->dev_ops->get_modes(&intel_dsi->dev);
+ drm_panel_attach(intel_dsi->panel, connector);
+ drm_panel_get_modes(intel_dsi->panel);
Should be inside the config mutex_lock below.
Why?
Because usually the drm_mode_probed_add gets called in the drm flow with
correct locking, but in this case calling get_modes here results in
drm_mode_probed_add being called which expects the lock to be taken.
Else we will see a big WARN dump. I agree with your comment below but
this was mainly to avoid the warning dump.
+
+ mutex_lock(&dev->mode_config.mutex);
+ list_for_each_entry(scan, &connector->probed_modes, head) {
+ if ((scan->type & DRM_MODE_TYPE_PREFERRED)) {
+ fixed_mode = drm_mode_duplicate(dev, scan);
+ break;
+ }
+ }
+ mutex_unlock(&dev->mode_config.mutex);
Generally this is single-threaded init code, no one else can touch it.
Which means you also never ever need locks. We tend to occasionally
sprinkle them around to satisfy general locking checks which are correct
at runtime. But at least in tricky cases that means we also stick a
comment next to them (see e.g. the various places in i915_irq.c).
Merged up to the previous patch, thanks a lot.
-Daniel
Regards
Shobhit
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/mm: Support 4 GiB and larger ranges
On Tue, Jan 27, 2015 at 08:51:12AM +1000, Dave Airlie wrote: > On 23 January 2015 at 18:05, Thierry Reding wrote: > > From: Thierry Reding > > > > The current implementation is limited by the number of addresses that > > fit into an unsigned long. This causes problems on 32-bit Tegra where > > unsigned long is 32-bit but drm_mm is used to manage an IOVA space of > > 4 GiB. Given the 32-bit limitation, the range is limited to 4 GiB - 1 > > (or 4 GiB - 4 KiB for page granularity). > > > > This commit changes the start and size of the range to be an unsigned > > 64-bit integer, thus allowing much larger ranges to be supported. > > This seems fine to me, Chris, Daniel or Thomas, any objections? None, lgtm. Would be worth just tidying the struct up for natural alignment (especially the drm_mm_node) to remove some holes. Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/10] drm/i915: Add i915.nuclear_pageflip command line param to force atomic (v4)
On Thu, Jan 22, 2015 at 04:53:12PM -0800, Matt Roper wrote:
> We don't have full atomic modeset support yet, but the "nuclear
> pageflip" subset of functionality (i.e., plane operations only) should
> be ready. Allow the user to force atomic on for debug purposes, or for
> fixed-purpose embedded devices that will only use atomic for plane
> updates.
>
> The term 'nuclear' is used here instead of 'atomic' to make it clear
> that this doesn't allow full atomic modeset support, just a (very
> useful) subset of the atomic functionality.
>
> We'll drop the kernel parameter and unconditionally enable atomic in a
> future patch once all of the necessary pieces are in.
>
> v2:
> - Use module_param_named_unsafe() (Daniel)
> - Simplify comment on DRIVER_ATOMIC guard (Daniel)
>
> v3:
> - Make the parameter "nuclear_pageflip" rather than just "nuclear"
>for clarity. (Ander)
>
> v4:
> - Make the internal variable "nuclear_pageflip" as well as the
>command-line option. (Ander)
>
> Signed-off-by: Matt Roper
> Reviewed-by: Ander Conselvan de Oliveira
Pulled in the entire series, thanks for patches&review.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.c| 8
> drivers/gpu/drm/i915/i915_drv.h| 1 +
> drivers/gpu/drm/i915/i915_params.c | 5 +
> 3 files changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 66c72bd..2a96656 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1637,6 +1637,14 @@ static int __init i915_init(void)
> #endif
> }
>
> + /*
> + * FIXME: Note that we're lying to the DRM core here so that we can get
> access
> + * to the atomic ioctl and the atomic properties. Only plane
> operations on
> + * a single CRTC will actually work.
> + */
> + if (i915.nuclear_pageflip)
> + driver.driver_features |= DRIVER_ATOMIC;
> +
> return drm_pci_init(&driver, &i915_pci_driver);
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 0d67b17..6a808a6 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2526,6 +2526,7 @@ struct i915_params {
> int use_mmio_flip;
> bool mmio_debug;
> bool verbose_state_checks;
> + bool nuclear_pageflip;
> };
> extern struct i915_params i915 __read_mostly;
>
> diff --git a/drivers/gpu/drm/i915/i915_params.c
> b/drivers/gpu/drm/i915/i915_params.c
> index 07252d8..44f2262 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -52,6 +52,7 @@ struct i915_params i915 __read_mostly = {
> .use_mmio_flip = 0,
> .mmio_debug = 0,
> .verbose_state_checks = 1,
> + .nuclear_pageflip = 0,
> };
>
> module_param_named(modeset, i915.modeset, int, 0400);
> @@ -178,3 +179,7 @@ MODULE_PARM_DESC(mmio_debug,
> module_param_named(verbose_state_checks, i915.verbose_state_checks, bool,
> 0600);
> MODULE_PARM_DESC(verbose_state_checks,
> "Enable verbose logs (ie. WARN_ON()) in case of unexpected hw state
> conditions.");
> +
> +module_param_named_unsafe(nuclear_pageflip, i915.nuclear_pageflip, bool,
> 0600);
> +MODULE_PARM_DESC(nuclear_pageflip,
> + "Force atomic modeset functionality; only planes work for now
> (default: false).");
> --
> 1.8.5.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v3 2/4] mfd: Add a new cell device for panel controlled by crystal cove pmic
On BYT-T configuration, panel enable/disable signals are routed through
PMIC. Add a cell device for the same.
Signed-off-by: Shobhit Kumar
---
drivers/mfd/intel_soc_pmic_crc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/intel_soc_pmic_crc.c b/drivers/mfd/intel_soc_pmic_crc.c
index c85e2ec..c8ccc24 100644
--- a/drivers/mfd/intel_soc_pmic_crc.c
+++ b/drivers/mfd/intel_soc_pmic_crc.c
@@ -109,6 +109,9 @@ static struct mfd_cell crystal_cove_dev[] = {
{
.name = "crystal_cove_pmic",
},
+ {
+ .name = "crystal_cove_panel",
+ },
};
static struct regmap_config crystal_cove_regmap_config = {
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v3 1/4] drm: Add support to find drm_panel by name
For scenarios where OF is not available, we can use panel identification by
name.
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/drm_panel.c | 18 ++
include/drm/drm_panel.h | 3 +++
2 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 2ef988e..e1cb8cf 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -95,6 +95,24 @@ struct drm_panel *of_drm_find_panel(struct device_node *np)
EXPORT_SYMBOL(of_drm_find_panel);
#endif
+struct drm_panel *drm_find_panel_by_name(const char *name)
+{
+ struct drm_panel *panel;
+
+ mutex_lock(&panel_lock);
+
+ list_for_each_entry(panel, &panel_list, list) {
+ if (strcmp(panel->name, name) == 0) {
+ mutex_unlock(&panel_lock);
+ return panel;
+ }
+ }
+
+ mutex_unlock(&panel_lock);
+ return NULL;
+}
+EXPORT_SYMBOL(drm_find_panel_by_name);
+
MODULE_AUTHOR("Thierry Reding ");
MODULE_DESCRIPTION("DRM panel infrastructure");
MODULE_LICENSE("GPL and additional rights");
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 1fbcc96..1ef9ff3 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -74,6 +74,7 @@ struct drm_panel {
struct drm_device *drm;
struct drm_connector *connector;
struct device *dev;
+ char name[NAME_MAX];
const struct drm_panel_funcs *funcs;
@@ -137,4 +138,6 @@ static inline struct drm_panel *of_drm_find_panel(struct
device_node *np)
}
#endif
+struct drm_panel *drm_find_panel_by_name(const char *name);
+
#endif
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v3 3/4] drm/i915: Add new panel driver based on crystal cove pmic
This driver provides support for the "crystal_cove_panel" cell device.
On BYT-T pmic has to be used to enable/disable panel.
v2: Addressed Jani's comments
- Moved inside i915
- Correct licensing
- Remove unused stuff
- Do not initialize prepare/unprepare as they are not needed as of now
- Correct backlight off delay
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i915/Kconfig | 12 ++
drivers/gpu/drm/i915/Makefile | 3 +
drivers/gpu/drm/i915/intel-panel-crystalcove.c | 159 +
3 files changed, 174 insertions(+)
create mode 100644 drivers/gpu/drm/i915/intel-panel-crystalcove.c
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 4e39ab3..0510ef0 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -69,3 +69,15 @@ config DRM_I915_PRELIMINARY_HW_SUPPORT
option changes the default for that module option.
If in doubt, say "N".
+
+config DRM_I915_PANEL_CRYSTALCOVE_PMIC
+ bool "Enable drm panel for crystal cove pmic based control"
+ depends on DRM_I915
+ depends on DRM_PANEL
+ default n
+ help
+ Choose this option if you have BYT-T based device with DSI panel. On
+ BYT-T there a crystal cove PMIC which controls the PANEL EN/DISABLE
+ signals.
+
+ If in doubt, say "N".
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 1849ffa..cc2f10d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -88,4 +88,7 @@ i915-y += i915_dma.o \
obj-$(CONFIG_DRM_I915) += i915.o
+# I915 DRM Panels
+obj-$(CONFIG_DRM_I915_PANEL_CRYSTALCOVE_PMIC) += intel-panel-crystalcove.o
+
CFLAGS_i915_trace_points.o := -I$(src)
diff --git a/drivers/gpu/drm/i915/intel-panel-crystalcove.c
b/drivers/gpu/drm/i915/intel-panel-crystalcove.c
new file mode 100644
index 000..a6aefa3
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel-panel-crystalcove.c
@@ -0,0 +1,159 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ * Shobhit Kumar
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PMIC_PANEL_EN 0x52
+#define PMIC_PWM_EN0x51
+#define PMIC_BKL_EN0x4B
+#define PMIC_PWM_LEVEL 0x4E
+
+struct crystalcove_panel {
+ struct drm_panel base;
+ bool enabled;
+
+ /* crystal cove pmic regmap */
+ struct regmap *regmap;
+};
+
+static inline struct crystalcove_panel *to_crystalcove_panel(struct drm_panel
*panel)
+{
+ return container_of(panel, struct crystalcove_panel, base);
+}
+
+static int crystalcove_panel_disable(struct drm_panel *panel)
+{
+ struct crystalcove_panel *p = to_crystalcove_panel(panel);
+
+ if (!p->enabled)
+ return 0;
+
+ DRM_DEBUG_KMS("\n");
+
+ /* invoke the pmic driver */
+ regmap_write(p->regmap, PMIC_PANEL_EN, 0x00);
+
+ /* Disable backlight as well */
+ regmap_write(p->regmap, PMIC_PWM_LEVEL, 0);
+ msleep(20);
+ regmap_write(p->regmap, PMIC_PWM_EN, 0x00);
+ regmap_write(p->regmap, PMIC_BKL_EN, 0x7F);
+
+ p->enabled = false;
+
+ return 0;
+}
+
+static int crystalcove_panel_enable(struct drm_panel *panel)
+{
+ struct crystalcove_panel *p = to_crystalcove_panel(panel);
+
+ if (p->enabled)
+ return 0;
+
+ DRM_DEBUG_KMS("\n");
+
+ /* invoke the pmic driver */
+ regmap_write(p->regmap, PMIC_PANEL_EN, 0x01);
+
+ /* Enable BKL as well */
+ regmap_write(p->regmap, PMIC_BKL_EN, 0xFF);
+ regmap_write(p->regmap, PMIC_PWM_EN, 0x01);
+ msleep(20);
+ regmap_write(p->regmap, PMIC_PWM_LEVEL, 255);
+
+ p->enabled = true;
+
+ return 0;
+}
+
+static const struct drm_panel_funcs cryst
[Intel-gfx] [RFC v3 0/4] Crystal Cove PMIC based Panel and Backlight Control
Hi All Please find modifed set of patches using regmap interface to accedd the PMIC registers. These patches implement a drm_panel as a platform driver for the mfd_cell device declared in intel_soc_pmic_core.c. DRM is extended to provide a find panel by name in absence of OF. Backlight control is pending. For now I am doing Backlight Enable/Disable also during panel/enable as this will at least save power. Regards Shobhit Shobhit Kumar (4): drm: Add support to find drm_panel by name mfd: Add a new cell device for panel controlled by crystal cove pmic drm/i915: Add new panel driver based on crystal cove pmic drm/i915: Enable DSI panel enable/disable based on PMIC drivers/gpu/drm/drm_panel.c| 18 +++ drivers/gpu/drm/i915/Kconfig | 13 ++ drivers/gpu/drm/i915/Makefile | 3 + drivers/gpu/drm/i915/intel-panel-crystalcove.c | 160 + drivers/gpu/drm/i915/intel_dsi.c | 16 +++ drivers/gpu/drm/i915/intel_dsi.h | 6 + drivers/mfd/intel_soc_pmic_crc.c | 3 + include/drm/drm_panel.h| 3 + 8 files changed, 222 insertions(+) create mode 100644 drivers/gpu/drm/i915/intel-panel-crystalcove.c -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v3 4/4] drm/i915: Enable DSI panel enable/disable based on PMIC
This allows for proper PPS during enable/disable of BYT-T platforms
where these signals are routed through PMIC. Needs DRM_PANEL to be
selected by default as well
v2: Adapt to panel find function name change in drm_panel
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/intel-panel-crystalcove.c | 1 +
drivers/gpu/drm/i915/intel_dsi.c | 16
drivers/gpu/drm/i915/intel_dsi.h | 6 ++
4 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 0510ef0..bacbc06 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -18,6 +18,7 @@ config DRM_I915
select INPUT if ACPI
select ACPI_VIDEO if ACPI
select ACPI_BUTTON if ACPI
+ select DRM_PANEL
help
Choose this option if you have a system that has "Intel Graphics
Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/intel-panel-crystalcove.c
b/drivers/gpu/drm/i915/intel-panel-crystalcove.c
index a6aefa3..0f129b2 100644
--- a/drivers/gpu/drm/i915/intel-panel-crystalcove.c
+++ b/drivers/gpu/drm/i915/intel-panel-crystalcove.c
@@ -154,6 +154,7 @@ static struct platform_driver crystalcove_panel_driver = {
module_platform_driver(crystalcove_panel_driver);
+MODULE_ALIAS();
MODULE_AUTHOR("Shobhit Kumar
#include
#include
+#include
#include
#include
#include "i915_drv.h"
@@ -230,6 +231,8 @@ static void intel_dsi_pre_enable(struct intel_encoder
*encoder)
DRM_DEBUG_KMS("\n");
+ drm_panel_enable(intel_dsi->panel);
+
/* Disable DPOunit clock gating, can stall pipe
* and we need DPLL REFA always enabled */
tmp = I915_READ(DPLL(pipe));
@@ -392,6 +395,8 @@ static void intel_dsi_post_disable(struct intel_encoder
*encoder)
msleep(intel_dsi->panel_off_delay);
msleep(intel_dsi->panel_pwr_cycle_delay);
+
+ drm_panel_disable(intel_dsi->panel);
}
static bool intel_dsi_get_hw_state(struct intel_encoder *encoder,
@@ -896,6 +901,17 @@ void intel_dsi_init(struct drm_device *dev)
fixed_mode->type |= DRM_MODE_TYPE_PREFERRED;
intel_panel_init(&intel_connector->panel, fixed_mode, NULL);
+ /* Initialize the PMIC based drm_panel if available on the platform */
+ if (dev_priv->vbt.dsi.config->pwm_blc == PPS_BLC_PMIC) {
+ intel_dsi->panel = drm_find_panel_by_name("crystal_cove_panel");
+ if (!intel_dsi->panel) {
+ DRM_ERROR("PMIC Panel control will not work !!\n");
+ return;
+ }
+
+ drm_panel_attach(intel_dsi->panel, connector);
+ }
+
return;
err:
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 8fe2064..4a9242d 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -33,6 +33,9 @@
#define DSI_DUAL_LINK_FRONT_BACK 1
#define DSI_DUAL_LINK_PIXEL_ALT2
+#define PPS_BLC_PMIC 0
+#define PPS_BLC_SOC1
+
struct intel_dsi_device {
unsigned int panel_id;
const char *name;
@@ -83,6 +86,8 @@ struct intel_dsi {
struct intel_connector *attached_connector;
+ struct drm_panel *panel;
+
/* bit mask of ports being driven */
u16 ports;
@@ -116,6 +121,7 @@ struct intel_dsi {
u32 dphy_reg;
u32 video_frmt_cfg_bits;
u16 lp_byte_clk;
+ u8 pps_blc;
/* timeouts in byte clocks */
u16 lp_rx_timeout;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drivers: gpu: drm: i915: intel_fifo_underrun.c: Fix a typo in comment
On Tue, Jan 27, 2015 at 09:56:49AM +0200, Jani Nikula wrote: > On Mon, 26 Jan 2015, Kumar Amit Mehta wrote: > > The comment for intel_cpu_fifo_underrun_irq_handler() is not consistent > > with the code and the rest of the comment for this routine. This patch > > fixes this typo in comment. > > > > Signed-off-by: Kumar Amit Mehta > > Reviewed-by: Jani Nikula Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Add gt_act_freq_mhz sysfs file
On Mon, Jan 26, 2015 at 08:42:56PM +, Chris Wilson wrote:
> On Mon, Jan 26, 2015 at 12:22:07PM -0800, O'Rourke, Tom wrote:
> > On Sun, Jan 25, 2015 at 09:34:33AM +, Chris Wilson wrote:
> > > On Fri, Jan 23, 2015 at 09:04:24PM +0200, ville.syrj...@linux.intel.com
> > > wrote:
> > > > From: Ville Syrjälä
> > > >
> > > > Currently the 'gt_cur_freq_mhz' file shows the actual GPU frequency on
> > > > VLV/CHV, and the last requested frequency on other platforms. Change the
> > > > meaning of the file on VLV/CHV to follow the the other platforms, and
> > > > introduce a new file 'gt_act_freq_mhz' which shows the actual frequency
> > > > on all platforms.
> > > >
> > > > Signed-off-by: Ville Syrjälä
> > > Reviewed-by: Chris Wilson
> > >
> > > > drivers/gpu/drm/i915/i915_sysfs.c | 35
> > > > ++-
> > > > 1 file changed, 34 insertions(+), 1 deletion(-)
> > > >
> > > > +static ssize_t gt_cur_freq_mhz_show(struct device *kdev,
> > > > + struct device_attribute *attr, char
> > > > *buf)
> > > > +{
> > > > + struct drm_minor *minor = dev_to_drm_minor(kdev);
> > > > + struct drm_device *dev = minor->dev;
> > > > + struct drm_i915_private *dev_priv = dev->dev_private;
> > > > + int ret;
> > > > +
> > > > + flush_delayed_work(&dev_priv->rps.delayed_resume_work);
> > >
> > > Is this required for querying the current value?
> > >
> > > Though probably better to keep it similar to the others.
> > > -Chris
> >
> > [TOR:] flush_delayed_work is needed to make sure rps.cur_freq
> > is valid for non VLV/CHV platforms.
>
> It is reporting the actual hw frequency. I still fail to see how
> flushing the pending work is important for reporting that instantaneous
> value.
Yeah, I suppose it's not really needed for act_freq, but I don't see any
real harm in having it there.
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Be consistent on printing seqnos
On Mon, Jan 26, 2015 at 06:03:06PM +0200, Mika Kuoppala wrote: > We have had %x and %u intermixed. Bring everything in line and > use %x > > Signed-off-by: Mika Kuoppala Thanks, these had been annoying me for ages. Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Remove nested work in gpu error handling
On Mon, Jan 26, 2015 at 06:03:05PM +0200, Mika Kuoppala wrote: > Now when we declare gpu errors only through our own dedicated > hangcheck workqueue there is no need to have a separate workqueue > for handling the resetting and waking up the clients as the deadlock > concerns are no more. > > The only exception is i915_debugfs::i915_set_wedged, which triggers > error handling through process context. However as this is only used through > test harness it is responsibility for test harness not to introduce hangs > through both debug interface and through hangcheck mechanism at the same time. > > Remove gpu_error.work and let the hangcheck work do the tasks it used to. > > Signed-off-by: Mika Kuoppala For our own sanity, we need to stick some form of that comment in i915_set_wedged(), so that when we do inevitably blow up, we can laugh at ourselves. Otherwise, lgtm. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] topic/atomic-core
Hi Dave, Mostly just small fixes and polish all over, plus the dpms-on-atomic stuff. Cheers, Daniel The following changes since commit 281d1bbd34b734e4f22b30b6f3b673dda46a7470: Merge remote-tracking branch 'origin/master' into drm-next (2015-01-22 10:44:41 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/atomic-core-2015-01-27 for you to fetch changes up to 9469244d869623e8b54d9f3d4d00737e377af273: drm/atomic: Fix potential use of state after free (2015-01-27 10:02:52 +0100) Ander Conselvan de Oliveira (1): drm/atomic: Fix potential use of state after free Daniel Vetter (6): drm: Add standardized boolean props drm/atomic: Add drm_crtc_state->active drm/atomic-helper: add connector->dpms() implementation drm/atomic-helpers: Recover full cursor plane behaviour drm/atomic-helpers: Saner encoder/crtc callbacks drm/atomic-helper: debug output for modesets Matt Roper (2): drm/plane-helper: Skip prepare_fb/cleanup_fb when newfb==oldfb drm/plane-helper: Fix transitional helper kerneldocs drivers/gpu/drm/drm_atomic.c| 21 - drivers/gpu/drm/drm_atomic_helper.c | 181 +--- drivers/gpu/drm/drm_crtc.c | 76 ++- drivers/gpu/drm/drm_plane_helper.c | 14 ++- include/drm/drm_atomic_helper.h | 2 + include/drm/drm_crtc.h | 7 ++ include/drm/drm_crtc_helper.h | 20 +++- 7 files changed, 300 insertions(+), 21 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/3] lib: print warning and critical messages when listing subtests
These messages are sent to stderr and could indicate an issue when enumerating subtests. Signed-off-by: Thomas Wood --- lib/igt_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/igt_core.c b/lib/igt_core.c index 2692fe4..bc588e2 100644 --- a/lib/igt_core.c +++ b/lib/igt_core.c @@ -1507,7 +1507,7 @@ void igt_vlog(const char *domain, enum igt_log_level level, const char *format, program_name = command_str; #endif - if (list_subtests) + if (list_subtests && level <= IGT_LOG_WARN) return; if (igt_log_level > level) -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 3/3] lib: validate subtest names
Subtest names should only contain '-', '_' and alphanumeric characters.
Signed-off-by: Thomas Wood
---
lib/igt_core.c | 12
1 file changed, 12 insertions(+)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index bc588e2..d74f6f8 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -54,6 +54,7 @@
#include
#include
#include
+#include
#include "drmtest.h"
#include "intel_chipset.h"
@@ -693,10 +694,21 @@ void igt_simple_init_parse_opts(int argc, char **argv,
*/
bool __igt_run_subtest(const char *subtest_name)
{
+ int i;
+
assert(!in_subtest);
assert(!in_fixture);
assert(test_with_subtests);
+ /* check the subtest name only contains a-z, A-Z, 0-9, '-' and '_' */
+ for (i = 0; subtest_name[i] != '\0'; i++)
+ if (subtest_name[i] != '_' && subtest_name[i] != '-'
+ && !isalnum(subtest_name[i])) {
+ igt_critical("Invalid subtest name \"%s\".\n",
+subtest_name);
+ igt_exit();
+ }
+
if (list_subtests) {
printf("%s\n", subtest_name);
return false;
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/3] lib: warning messages should be sent to stderr
This is a regression from commit df11a0f (lib: add a critical warning
level).
Signed-off-by: Thomas Wood
---
lib/igt_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 7b47b32..2692fe4 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -1522,7 +1522,7 @@ void igt_vlog(const char *domain, enum igt_log_level
level, const char *format,
return;
}
- if (level > IGT_LOG_WARN) {
+ if (level >= IGT_LOG_WARN) {
file = stderr;
fflush(stdout);
}
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v3] drm/i915: Android native sync support
From: Tvrtko Ursulin
Add Android native sync support with fences exported as file descriptors via
the execbuf ioctl (rsvd2 field is used).
This is a continuation of Jesse Barnes's previous work, squashed to arrive at
the final destination, cleaned up, with some fixes and preliminary light
testing.
GEM requests are extended with fence structures which are associated with
Android sync fences exported to user space via file descriptors. Fences which
are waited upon, and while exported to userspace, are referenced and added to
the irq_queue so they are signalled when requests are completed. There is no
overhead apart from the where fences are not requested.
Based on patches by Jesse Barnes:
drm/i915: Android sync points for i915 v3
drm/i915: add fences to the request struct
drm/i915: sync fence fixes/updates
To do:
* Extend driver data with context id / ring id (TBD).
v2:
* Code review comments. (Chris Wilson)
* ring->add_request() was a wrong thing to call - rebase on top of John
Harrison's (drm/i915: Early alloc request) to ensure correct request is
present before creating a fence.
* Take a request reference from signalling path as well to ensure request
sticks around while fence is on the request completion wait queue.
v3:
* Use worker to unreference on completion so it can lock the mutex from
interrupt context.
Signed-off-by: Tvrtko Ursulin
Cc: Jesse Barnes
Cc: John Harrison
---
drivers/gpu/drm/i915/Kconfig | 14 ++
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.h| 27 +++
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 24 +++
drivers/gpu/drm/i915/i915_sync.c | 254 +
include/uapi/drm/i915_drm.h| 8 +-
6 files changed, 325 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_sync.c
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 4e39ab3..abafe68 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -43,6 +43,20 @@ config DRM_I915_KMS
If in doubt, say "Y".
+config DRM_I915_SYNC
+ bool "Enable explicit sync support"
+ depends on DRM_I915
+ default y if STAGING
+ select STAGING
+ select ANDROID
+ select SYNC
+ help
+ Choose this option to enable Android native sync support and the
+ corresponding i915 driver code to expose it. Slightly increases
+ driver size and pulls in sync support from staging.
+
+ If in doubt, say "Y".
+
config DRM_I915_FBDEV
bool "Enable legacy fbdev support for the modesetting intel driver"
depends on DRM_I915
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 16e3dc3..bcff481 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -58,6 +58,7 @@ i915-y += intel_audio.o \
intel_sprite.o
i915-$(CONFIG_ACPI)+= intel_acpi.o intel_opregion.o
i915-$(CONFIG_DRM_I915_FBDEV) += intel_fbdev.o
+i915-$(CONFIG_DRM_I915_SYNC) += i915_sync.o
# modesetting output/encoder code
i915-y += dvo_ch7017.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 023f422..c4d254c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -49,6 +49,7 @@
#include
#include
#include
+#include
/* General customization:
*/
@@ -2092,6 +2093,15 @@ struct drm_i915_gem_request {
struct list_head client_list;
uint32_t uniq;
+
+#ifdef CONFIG_DRM_I915_SYNC
+ /* core fence obj for this request, may be exported */
+ struct fence fence;
+
+ wait_queue_t wait;
+
+ struct work_struct unref_work;
+#endif
};
void i915_gem_request_free(struct kref *req_ref);
@@ -2583,6 +2593,23 @@ void i915_init_vm(struct drm_i915_private *dev_priv,
void i915_gem_free_object(struct drm_gem_object *obj);
void i915_gem_vma_destroy(struct i915_vma *vma);
+/* i915_sync.c */
+struct sync_fence;
+
+#ifdef CONFIG_DRM_I915_SYNC
+int i915_create_sync_fence_ring(struct intel_engine_cs *ring,
+ struct intel_context *ctx,
+ struct sync_fence **sync_fence, int *fence_fd);
+#else
+static inline
+int i915_create_sync_fence_ring(struct intel_engine_cs *ring,
+ struct intel_context *ctx,
+ struct sync_fence **sync_fence, int *fence_fd)
+{
+ return -ENODEV;
+}
+#endif
+
#define PIN_MAPPABLE 0x1
#define PIN_NONBLOCK 0x2
#define PIN_GLOBAL 0x4
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 2a3d1a9..b04157a 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -32,6 +32,7 @@
#include "i915_trace.h"
#include "intel_drv.h"
#include
+#include "../../../staging/android/s
Re: [Intel-gfx] [RFC v3] drm/i915: Android native sync support
On Tue, Jan 27, 2015 at 11:29:36AM +, Tvrtko Ursulin wrote:
> +static void i915_gem_request_unreference_worker(struct work_struct *work)
> +{
> + struct drm_i915_gem_request *req =
> + container_of(work, struct drm_i915_gem_request, unref_work);
> + struct drm_device *dev = req->ring->dev;
> +
> + mutex_lock(&dev->struct_mutex);
> + i915_gem_request_unreference(req);
> + mutex_unlock(&dev->struct_mutex);
> +}
> +
> +static int
> +i915_fence_ring_check(wait_queue_t *wait, unsigned mode, int flags, void
> *key)
> +{
> + struct drm_i915_gem_request *req = wait->private;
> + struct intel_engine_cs *ring = req->ring;
> +
> + if (!i915_gem_request_completed(req, false))
> + return 0;
> +
> + fence_signal_locked(&req->fence);
> +
> + __remove_wait_queue(&ring->irq_queue, wait);
> + ring->irq_put(ring);
> +
> + INIT_WORK(&req->unref_work, i915_gem_request_unreference_worker);
> + schedule_work(&req->unref_work);
> +
> + return 0;
> +}
> +
> +static bool i915_fence_ring_enable_signaling(struct fence *fence)
> +{
> + struct drm_i915_gem_request *req = to_i915_request(fence);
> + struct intel_engine_cs *ring = req->ring;
> + struct drm_i915_private *dev_priv = ring->dev->dev_private;
> + wait_queue_t *wait = &req->wait;
> +
> + /* queue fence wait queue on irq queue and get fence */
> + if (i915_gem_request_completed(req, false) ||
> + i915_terminally_wedged(&dev_priv->gpu_error))
> + return false;
> +
> + if (!ring->irq_get(ring))
> + return false;
> +
> + if (i915_gem_request_completed(req, false)) {
> + ring->irq_put(ring);
> + return true;
> + }
> +
> + wait->flags = 0;
> + wait->private = req;
> + wait->func = i915_fence_ring_check;
> +
> + i915_gem_request_reference(req);
> +
> + __add_wait_queue(&ring->irq_queue, wait);
> +
> + return true;
> +}
Explain how fence_release interacts with enable_signalling. Presumably
either the core fence routines cleanup the outstanding signalling, or we
are expected to. Doing so will remove the requirement for the extra
ref/unref (including the worker).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v3] drm/i915: Android native sync support
On 01/27/2015 11:40 AM, Chris Wilson wrote:
On Tue, Jan 27, 2015 at 11:29:36AM +, Tvrtko Ursulin wrote:
+static void i915_gem_request_unreference_worker(struct work_struct *work)
+{
+ struct drm_i915_gem_request *req =
+ container_of(work, struct drm_i915_gem_request, unref_work);
+ struct drm_device *dev = req->ring->dev;
+
+ mutex_lock(&dev->struct_mutex);
+ i915_gem_request_unreference(req);
+ mutex_unlock(&dev->struct_mutex);
+}
+
+static int
+i915_fence_ring_check(wait_queue_t *wait, unsigned mode, int flags, void *key)
+{
+ struct drm_i915_gem_request *req = wait->private;
+ struct intel_engine_cs *ring = req->ring;
+
+ if (!i915_gem_request_completed(req, false))
+ return 0;
+
+ fence_signal_locked(&req->fence);
+
+ __remove_wait_queue(&ring->irq_queue, wait);
+ ring->irq_put(ring);
+
+ INIT_WORK(&req->unref_work, i915_gem_request_unreference_worker);
+ schedule_work(&req->unref_work);
+
+ return 0;
+}
+
+static bool i915_fence_ring_enable_signaling(struct fence *fence)
+{
+ struct drm_i915_gem_request *req = to_i915_request(fence);
+ struct intel_engine_cs *ring = req->ring;
+ struct drm_i915_private *dev_priv = ring->dev->dev_private;
+ wait_queue_t *wait = &req->wait;
+
+ /* queue fence wait queue on irq queue and get fence */
+ if (i915_gem_request_completed(req, false) ||
+ i915_terminally_wedged(&dev_priv->gpu_error))
+ return false;
+
+ if (!ring->irq_get(ring))
+ return false;
+
+ if (i915_gem_request_completed(req, false)) {
+ ring->irq_put(ring);
+ return true;
+ }
+
+ wait->flags = 0;
+ wait->private = req;
+ wait->func = i915_fence_ring_check;
+
+ i915_gem_request_reference(req);
+
+ __add_wait_queue(&ring->irq_queue, wait);
+
+ return true;
+}
Explain how fence_release interacts with enable_signalling. Presumably
either the core fence routines cleanup the outstanding signalling, or we
are expected to. Doing so will remove the requirement for the extra
ref/unref (including the worker).
I think normally we would be expected to use fence_get/put on the
signaling side of things but that is not possible here since struct
fence is embedded in the request.
So as it is, sync_fence_release will tear everything down with our
callback still on the irq_queue which is what taking a request reference
sorts out.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 01/24] drm/i915/trace: Fix offsets for 64b
Michel Thierry writes:
> From: Ben Widawsky
>
> Signed-off-by: Ben Widawsky
> Signed-off-by: Michel Thierry
> ---
> drivers/gpu/drm/i915/i915_trace.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_trace.h
> b/drivers/gpu/drm/i915/i915_trace.h
> index 6058a01..f004d3d 100644
> --- a/drivers/gpu/drm/i915/i915_trace.h
> +++ b/drivers/gpu/drm/i915/i915_trace.h
> @@ -115,7 +115,7 @@ TRACE_EVENT(i915_vma_bind,
> TP_STRUCT__entry(
>__field(struct drm_i915_gem_object *, obj)
>__field(struct i915_address_space *, vm)
> - __field(u32, offset)
> + __field(u64, offset)
>__field(u32, size)
>__field(unsigned, flags)
We seem to use uint64_t for flags in caller. Not that we are using
past a few currently so we good for now.
Reviewed-by: Mika Kuoppala
>),
> @@ -128,7 +128,7 @@ TRACE_EVENT(i915_vma_bind,
> __entry->flags = flags;
> ),
>
> - TP_printk("obj=%p, offset=%08x size=%x%s vm=%p",
> + TP_printk("obj=%p, offset=%016llx size=%x%s vm=%p",
> __entry->obj, __entry->offset, __entry->size,
> __entry->flags & PIN_MAPPABLE ? ", mappable" : "",
> __entry->vm)
> @@ -141,7 +141,7 @@ TRACE_EVENT(i915_vma_unbind,
> TP_STRUCT__entry(
>__field(struct drm_i915_gem_object *, obj)
>__field(struct i915_address_space *, vm)
> - __field(u32, offset)
> + __field(u64, offset)
>__field(u32, size)
>),
>
> @@ -152,7 +152,7 @@ TRACE_EVENT(i915_vma_unbind,
> __entry->size = vma->node.size;
> ),
>
> - TP_printk("obj=%p, offset=%08x size=%x vm=%p",
> + TP_printk("obj=%p, offset=%016llx size=%x vm=%p",
> __entry->obj, __entry->offset, __entry->size, __entry->vm)
> );
>
> --
> 2.1.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v3] drm/i915: Android native sync support
On Tue, Jan 27, 2015 at 12:13:14PM +, Tvrtko Ursulin wrote:
> On 01/27/2015 11:40 AM, Chris Wilson wrote:
> >On Tue, Jan 27, 2015 at 11:29:36AM +, Tvrtko Ursulin wrote:
> >>+static void i915_gem_request_unreference_worker(struct work_struct *work)
> >>+{
> >>+ struct drm_i915_gem_request *req =
> >>+ container_of(work, struct drm_i915_gem_request, unref_work);
> >>+ struct drm_device *dev = req->ring->dev;
> >>+
> >>+ mutex_lock(&dev->struct_mutex);
> >>+ i915_gem_request_unreference(req);
> >>+ mutex_unlock(&dev->struct_mutex);
> >>+}
> >>+
> >>+static int
> >>+i915_fence_ring_check(wait_queue_t *wait, unsigned mode, int flags, void
> >>*key)
> >>+{
> >>+ struct drm_i915_gem_request *req = wait->private;
> >>+ struct intel_engine_cs *ring = req->ring;
> >>+
> >>+ if (!i915_gem_request_completed(req, false))
> >>+ return 0;
> >>+
> >>+ fence_signal_locked(&req->fence);
> >>+
> >>+ __remove_wait_queue(&ring->irq_queue, wait);
> >>+ ring->irq_put(ring);
> >>+
> >>+ INIT_WORK(&req->unref_work, i915_gem_request_unreference_worker);
> >>+ schedule_work(&req->unref_work);
> >>+
> >>+ return 0;
> >>+}
> >>+
> >>+static bool i915_fence_ring_enable_signaling(struct fence *fence)
> >>+{
> >>+ struct drm_i915_gem_request *req = to_i915_request(fence);
> >>+ struct intel_engine_cs *ring = req->ring;
> >>+ struct drm_i915_private *dev_priv = ring->dev->dev_private;
> >>+ wait_queue_t *wait = &req->wait;
> >>+
> >>+ /* queue fence wait queue on irq queue and get fence */
> >>+ if (i915_gem_request_completed(req, false) ||
> >>+ i915_terminally_wedged(&dev_priv->gpu_error))
> >>+ return false;
> >>+
> >>+ if (!ring->irq_get(ring))
> >>+ return false;
> >>+
> >>+ if (i915_gem_request_completed(req, false)) {
> >>+ ring->irq_put(ring);
> >>+ return true;
> >>+ }
> >>+
> >>+ wait->flags = 0;
> >>+ wait->private = req;
> >>+ wait->func = i915_fence_ring_check;
> >>+
> >>+ i915_gem_request_reference(req);
> >>+
> >>+ __add_wait_queue(&ring->irq_queue, wait);
> >>+
> >>+ return true;
> >>+}
> >
> >Explain how fence_release interacts with enable_signalling. Presumably
> >either the core fence routines cleanup the outstanding signalling, or we
> >are expected to. Doing so will remove the requirement for the extra
> >ref/unref (including the worker).
>
> I think normally we would be expected to use fence_get/put on the
> signaling side of things but that is not possible here since struct
> fence is embedded in the request.
>
> So as it is, sync_fence_release will tear everything down with our
> callback still on the irq_queue which is what taking a request
> reference sorts out.
So you are saying that we have a callback for when the fence is
discarded by userspace and we ignore that opportunity for disabling
interrupt generation, and remove the extra request references?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 05/12] drm/i915/dsi: remove unnecessary dsi device callbacks
On Tue, Jan 27, 2015 at 02:11:18PM +0530, Shobhit Kumar wrote: > On 01/23/2015 08:52 PM, Daniel Vetter wrote: > >On Fri, Jan 23, 2015 at 03:14:41PM +0530, Shobhit Kumar wrote: > >>On 01/22/2015 06:53 PM, Jani Nikula wrote: > >>>On Thu, 22 Jan 2015, Shobhit Kumar wrote: > There had been a instance where we had to drive different resolution > (lower) than the native one. Also in VBT there is a field to make this > generic at least from driver perspective to give the needed target > resolution. In case target resolution is same as native, nothing gets > changed, else mode_fixup function adjusts the mode accordingly keeping > timing as same and enabling scalar. Might not be useful in general, but > did find a use internally. > >>> > >>>Can we just have the driver return the desired mode from .get_modes in > >>>that case? > >> > >>Okay, I think I did not explain correctly. Get modes is modified to give the > >>needed target mode only so that userspace creates buffer of the needed > >>resolution, but in fixup which is called at modeset, we correct the > >>adjusted_mode back to have native resolutions so that modeset is correctly > >>done. if we do not do like this, during modeset resolutions will be wrong as > >>per the timings. > > > >I'm confused. Can you please give an example in real numbers about the > >different resolution and how it's all fixed up in hw? > > > >E.g. 800x600 framebuffer -> pfit -> 1024x756 panel, > > > >get_modes gives 800x600, adjusted mode corrects to 1024x756. And please > > We had a 19x12 DSI panel which we needed to drive at 12x8 due to lack of > 12x8 panels for testing purposes. So get_modes returned 12x8 so that user > space gave 12x8 FBs, and internally in mode_fixup we adjusted correctly for > the 19x12 panel timings and enabled pfit Hm, is that a real use-case shipping to customers or just a hack for development? In the later case I think we can just hardcode the edid for edp ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 05/12] drm/i915/dsi: remove unnecessary dsi device callbacks
On Tue, Jan 27, 2015 at 02:09:21PM +0100, Daniel Vetter wrote: > On Tue, Jan 27, 2015 at 02:11:18PM +0530, Shobhit Kumar wrote: > > On 01/23/2015 08:52 PM, Daniel Vetter wrote: > > >On Fri, Jan 23, 2015 at 03:14:41PM +0530, Shobhit Kumar wrote: > > >>On 01/22/2015 06:53 PM, Jani Nikula wrote: > > >>>On Thu, 22 Jan 2015, Shobhit Kumar wrote: > > There had been a instance where we had to drive different resolution > > (lower) than the native one. Also in VBT there is a field to make this > > generic at least from driver perspective to give the needed target > > resolution. In case target resolution is same as native, nothing gets > > changed, else mode_fixup function adjusts the mode accordingly keeping > > timing as same and enabling scalar. Might not be useful in general, but > > did find a use internally. > > >>> > > >>>Can we just have the driver return the desired mode from .get_modes in > > >>>that case? > > >> > > >>Okay, I think I did not explain correctly. Get modes is modified to give > > >>the > > >>needed target mode only so that userspace creates buffer of the needed > > >>resolution, but in fixup which is called at modeset, we correct the > > >>adjusted_mode back to have native resolutions so that modeset is correctly > > >>done. if we do not do like this, during modeset resolutions will be wrong > > >>as > > >>per the timings. > > > > > >I'm confused. Can you please give an example in real numbers about the > > >different resolution and how it's all fixed up in hw? > > > > > >E.g. 800x600 framebuffer -> pfit -> 1024x756 panel, > > > > > >get_modes gives 800x600, adjusted mode corrects to 1024x756. And please > > > > We had a 19x12 DSI panel which we needed to drive at 12x8 due to lack of > > 12x8 panels for testing purposes. So get_modes returned 12x8 so that user > > space gave 12x8 FBs, and internally in mode_fixup we adjusted correctly for > > the 19x12 panel timings and enabled pfit > > Hm, is that a real use-case shipping to customers or just a hack for > development? In the later case I think we can just hardcode the edid for > edp ... Also how is this different from userspace creating a 800x600 mode and giving it to the kernel which then uses the pfitter to display it at native resolution. That is how it works today. This should also be possible with a video= parameter... -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v3] drm/i915: Android native sync support
On 01/27/2015 12:18 PM, Chris Wilson wrote: On Tue, Jan 27, 2015 at 12:13:14PM +, Tvrtko Ursulin wrote: On 01/27/2015 11:40 AM, Chris Wilson wrote: [snip] Explain how fence_release interacts with enable_signalling. Presumably either the core fence routines cleanup the outstanding signalling, or we are expected to. Doing so will remove the requirement for the extra ref/unref (including the worker). I think normally we would be expected to use fence_get/put on the signaling side of things but that is not possible here since struct fence is embedded in the request. So as it is, sync_fence_release will tear everything down with our callback still on the irq_queue which is what taking a request reference sorts out. So you are saying that we have a callback for when the fence is discarded by userspace and we ignore that opportunity for disabling interrupt generation, and remove the extra request references? I can change it to work like that sure, don't see anything obvious preventing this rework. Can use the fence lock to avoid wait queue removal race and that should be pretty much it. On a related not, do you have any ideas for submitting a batch which can either keep the GPU busy for a configurable time, or until signaled by something else (possibly another batch). Gen agnostic ideally? :) Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/2] lib: add subtest start and exit status code messages to debug output
Signed-off-by: Thomas Wood
---
lib/igt_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index d74f6f8..41f84bb 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -729,6 +729,7 @@ bool __igt_run_subtest(const char *subtest_name)
}
kmsg(KERN_INFO "%s: starting subtest %s\n", command_str, subtest_name);
+ igt_debug("Starting subtest: %s\n", subtest_name);
gettime(&subtest_time);
return (in_subtest = subtest_name);
@@ -972,6 +973,7 @@ void igt_exit(void)
exit(IGT_EXIT_SUCCESS);
kmsg(KERN_INFO "%s: exiting, ret=%d\n", command_str, igt_exitcode);
+ igt_debug("Exiting with status code %d\n", igt_exitcode);
if (!test_with_subtests)
exit(igt_exitcode);
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/2] lib: add exit status message to simple tests
Add an exit status message to simple tests, similar to the one printed
for subtests. This includes the test outcome and the time taken to run
the test.
Signed-off-by: Thomas Wood
---
lib/igt_core.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 41f84bb..0ae6918 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -591,6 +591,9 @@ out:
/* install exit handler, to ensure we clean up */
igt_install_exit_handler(common_exit_handler);
+ if (!test_with_subtests)
+ gettime(&subtest_time);
+
return ret;
}
@@ -975,8 +978,33 @@ void igt_exit(void)
kmsg(KERN_INFO "%s: exiting, ret=%d\n", command_str, igt_exitcode);
igt_debug("Exiting with status code %d\n", igt_exitcode);
- if (!test_with_subtests)
+ if (!test_with_subtests) {
+ struct timespec now;
+ double elapsed;
+ const char *result;
+
+ gettime(&now);
+ elapsed = now.tv_sec - subtest_time.tv_sec;
+ elapsed += (now.tv_nsec - subtest_time.tv_nsec) * 1e-9;
+
+ switch (igt_exitcode) {
+ case IGT_EXIT_SUCCESS:
+ result = "SUCCESS";
+ break;
+ case IGT_EXIT_TIMEOUT:
+ result = "TIMEOUT";
+ break;
+ case IGT_EXIT_SKIP:
+ result = "SKIP";
+ break;
+ default:
+ result = "FAIL";
+ }
+
+
+ printf("%s (%.3fs)\n", result, elapsed);
exit(igt_exitcode);
+ }
/* Calling this without calling one of the above is a failure */
assert(skipped_one || succeeded_one || failed_one);
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Handle CHV in vlv_set_rps_idle()
From: Ville Syrjälä
Move the CHV check into vlv_set_rps_idle() to simplify the caller a bit.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index dbeecb0..6ece663 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3799,8 +3799,8 @@ static void vlv_set_rps_idle(struct drm_i915_private
*dev_priv)
{
struct drm_device *dev = dev_priv->dev;
- /* Latest VLV doesn't need to force the gfx clock */
- if (dev->pdev->revision >= 0xd) {
+ /* CHV and latest VLV don't need to force the gfx clock */
+ if (IS_CHERRYVIEW(dev) || dev->pdev->revision >= 0xd) {
valleyview_set_rps(dev_priv->dev,
dev_priv->rps.min_freq_softlimit);
return;
}
@@ -3839,9 +3839,7 @@ void gen6_rps_idle(struct drm_i915_private *dev_priv)
mutex_lock(&dev_priv->rps.hw_lock);
if (dev_priv->rps.enabled) {
- if (IS_CHERRYVIEW(dev))
- valleyview_set_rps(dev_priv->dev,
dev_priv->rps.min_freq_softlimit);
- else if (IS_VALLEYVIEW(dev))
+ if (IS_VALLEYVIEW(dev))
vlv_set_rps_idle(dev_priv);
else
gen6_set_rps(dev_priv->dev,
dev_priv->rps.min_freq_softlimit);
--
2.0.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Introduce intel_set_rps()
From: Ville Syrjälä
Replace the valleyview_set_rps() and gen6_set_rps() calls with
intel_set_rps() which itself does the IS_VALLEYVIEW() check. The
code becomes simpler since the callers don't have to do this check
themselves.
Most of the change was performe with the following semantic patch:
@@
expression E1, E2;
@@
(
- valleyview_set_rps(E1, E2)
+ intel_set_rps(E1, E2)
|
- gen6_set_rps(E1, E2)
+ intel_set_rps(E1, E2)
)
@@
expression E1, E2, E3;
@@
- if (IS_VALLEYVIEW(E1)) {
- intel_set_rps(E2, E3);
- } else {
- intel_set_rps(E2, E3);
- }
+ intel_set_rps(E2, E3);
Adding intel_set_rps() and making valleyview_set_rps() and gen6_set_rps()
static was done manually.
Cc: Chris Wilson
Suggested-by: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_debugfs.c | 10 ++
drivers/gpu/drm/i915/i915_drv.h | 3 +--
drivers/gpu/drm/i915/i915_irq.c | 5 +
drivers/gpu/drm/i915/i915_sysfs.c | 10 ++
drivers/gpu/drm/i915/intel_pm.c | 32 ++--
5 files changed, 24 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index b315f01..ddb06e1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4168,10 +4168,7 @@ i915_max_freq_set(void *data, u64 val)
dev_priv->rps.max_freq_softlimit = val;
- if (IS_VALLEYVIEW(dev))
- valleyview_set_rps(dev, val);
- else
- gen6_set_rps(dev, val);
+ intel_set_rps(dev, val);
mutex_unlock(&dev_priv->rps.hw_lock);
@@ -4246,10 +4243,7 @@ i915_min_freq_set(void *data, u64 val)
dev_priv->rps.min_freq_softlimit = val;
- if (IS_VALLEYVIEW(dev))
- valleyview_set_rps(dev, val);
- else
- gen6_set_rps(dev, val);
+ intel_set_rps(dev, val);
mutex_unlock(&dev_priv->rps.hw_lock);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4179b90..30a6ac6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3182,8 +3182,7 @@ extern void i915_redisable_vga(struct drm_device *dev);
extern void i915_redisable_vga_power_on(struct drm_device *dev);
extern bool ironlake_set_drps(struct drm_device *dev, u8 val);
extern void intel_init_pch_refclk(struct drm_device *dev);
-extern void gen6_set_rps(struct drm_device *dev, u8 val);
-extern void valleyview_set_rps(struct drm_device *dev, u8 val);
+extern void intel_set_rps(struct drm_device *dev, u8 val);
extern void intel_set_memory_cxsr(struct drm_i915_private *dev_priv,
bool enable);
extern void intel_detect_pch(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 2399eae..2a8cb83 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1243,10 +1243,7 @@ static void gen6_pm_rps_work(struct work_struct *work)
dev_priv->rps.last_adj = new_delay - dev_priv->rps.cur_freq;
- if (IS_VALLEYVIEW(dev_priv->dev))
- valleyview_set_rps(dev_priv->dev, new_delay);
- else
- gen6_set_rps(dev_priv->dev, new_delay);
+ intel_set_rps(dev_priv->dev, new_delay);
mutex_unlock(&dev_priv->rps.hw_lock);
}
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index 49f5ade..cdc9da0 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -402,10 +402,7 @@ static ssize_t gt_max_freq_mhz_store(struct device *kdev,
/* We still need *_set_rps to process the new max_delay and
* update the interrupt limits and PMINTRMSK even though
* frequency request may be unchanged. */
- if (IS_VALLEYVIEW(dev))
- valleyview_set_rps(dev, val);
- else
- gen6_set_rps(dev, val);
+ intel_set_rps(dev, val);
mutex_unlock(&dev_priv->rps.hw_lock);
@@ -464,10 +461,7 @@ static ssize_t gt_min_freq_mhz_store(struct device *kdev,
/* We still need *_set_rps to process the new min_delay and
* update the interrupt limits and PMINTRMSK even though
* frequency request may be unchanged. */
- if (IS_VALLEYVIEW(dev))
- valleyview_set_rps(dev, val);
- else
- gen6_set_rps(dev, val);
+ intel_set_rps(dev, val);
mutex_unlock(&dev_priv->rps.hw_lock);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6ece663..2bad1e8 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3750,7 +3750,7 @@ static u32 gen6_rps_pm_mask(struct drm_i915_private
*dev_priv, u8 val)
/* gen6_set_rps is called to update the frequency request, but should also be
* called when the range (min_delay and max_delay) is modified so that we can
* update the GEN6_RP_INTERRUPT_LIMITS register acc
Re: [Intel-gfx] [PATCH v2] agp/intel: Serialise after GTT updates
On Mon, Jan 26, 2015 at 10:47:10AM +, Chris Wilson wrote:
> An interesting bug occurs on Pineview through which the root cause is
> that the writes of the PTE values into the GTT is not serialised with
> subsequent memory access through the GTT (when using WC updates of the
> PTE values). This is despite there being a posting read after the GTT
> update. However, by changing the address of the posting read, the memory
> access is indeed serialised correctly.
>
> Whilst we are manipulating the memory barriers, we can remove the
> compiler :memory restraint on the intermediate PTE writes knowing that
> we explicitly perform a posting read afterwards.
>
> v2: Replace posting reads with explicit write memory barriers - in
> particular this is advantages in case of single page objects. Update
> comments to mention this issue is only with WC writes.
>
> Testcase: igt/gem_exec_big #pnv
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88191
> Tested-by: huax...@intel.com (v1)
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
Reviewed-by: Daniel Vetter
Shouldn't we Cc: sta...@vger.kernel.org too?
-Daniel
> ---
> drivers/char/agp/intel-gtt.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
> index 92aa43fa8d70..0b4188b9af7c 100644
> --- a/drivers/char/agp/intel-gtt.c
> +++ b/drivers/char/agp/intel-gtt.c
> @@ -225,7 +225,7 @@ static int i810_insert_dcache_entries(struct agp_memory
> *mem, off_t pg_start,
> intel_private.driver->write_entry(addr,
> i, type);
> }
> - readl(intel_private.gtt+i-1);
> + wmb();
>
> return 0;
> }
> @@ -329,7 +329,7 @@ static void i810_write_entry(dma_addr_t addr, unsigned
> int entry,
> break;
> }
>
> - writel(addr | pte_flags, intel_private.gtt + entry);
> + writel_relaxed(addr | pte_flags, intel_private.gtt + entry);
> }
>
> static const struct aper_size_info_fixed intel_fake_agp_sizes[] = {
> @@ -735,7 +735,7 @@ static void i830_write_entry(dma_addr_t addr, unsigned
> int entry,
> if (flags == AGP_USER_CACHED_MEMORY)
> pte_flags |= I830_PTE_SYSTEM_CACHED;
>
> - writel(addr | pte_flags, intel_private.gtt + entry);
> + writel_relaxed(addr | pte_flags, intel_private.gtt + entry);
> }
>
> bool intel_enable_gtt(void)
> @@ -858,7 +858,7 @@ void intel_gtt_insert_sg_entries(struct sg_table *st,
> j++;
> }
> }
> - readl(intel_private.gtt+j-1);
> + wmb();
> }
> EXPORT_SYMBOL(intel_gtt_insert_sg_entries);
>
> @@ -875,7 +875,7 @@ static void intel_gtt_insert_pages(unsigned int
> first_entry,
> intel_private.driver->write_entry(addr,
> j, flags);
> }
> - readl(intel_private.gtt+j-1);
> + wmb();
> }
>
> static int intel_fake_agp_insert_entries(struct agp_memory *mem,
> @@ -938,7 +938,7 @@ void intel_gtt_clear_range(unsigned int first_entry,
> unsigned int num_entries)
>
> intel_private.driver->write_entry(intel_private.scratch_page_dma,
> i, 0);
> }
> - readl(intel_private.gtt+i-1);
> + wmb();
> }
> EXPORT_SYMBOL(intel_gtt_clear_range);
>
> @@ -1106,7 +1106,7 @@ static void i965_write_entry(dma_addr_t addr,
>
> /* Shift high bits down */
> addr |= (addr >> 28) & 0xf0;
> - writel(addr | pte_flags, intel_private.gtt + entry);
> + writel_relaxed(addr | pte_flags, intel_private.gtt + entry);
> }
>
> static int i9xx_setup(void)
> --
> 2.1.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915: Fallback to using CPU relocations for large batch buffers
On Wed, Jan 14, 2015 at 11:20:56AM +, Chris Wilson wrote:
> If the batch buffer is too large to fit into the aperture and we need a
> GTT mapping for relocations, we currently fail. This only applies to a
> subset of machines for a subset of environments, quite undesirable. We
> can simply check after failing to insert the batch into the GTT as to
> whether we only need a mappable binding for relocation and, if so, we can
> revert to using a non-mappable binding and an alternate relocation
> method. However, using relocate_entry_cpu() is excruciatingly slow for
> large buffers on non-LLC as the entire buffer requires clflushing before
> and after the relocation handling. Alternatively, we can implement a
> third relocation method that only clflushes around the relocation entry.
> This is still slower than updating through the GTT, so we prefer using
> the GTT where possible, but is orders of magnitude faster as we
> typically do not have to then clflush the entire buffer.
>
> An alternative idea of using a temporary WC mapping of the backing store
> is promising (it should be faster than using the GTT itself), but
> requires fairly extensive arch/x86 support - along the lines of
> kmap_atomic_prof_pfn() (which is not universally implemented even for
> x86).
>
> Testcase: igt/gem_exec_big #pnv,byt
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88392
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 84
> +-
> 1 file changed, 72 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index e3ef17783765..06bdf7670584 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -251,7 +251,6 @@ static inline int use_cpu_reloc(struct
> drm_i915_gem_object *obj)
> {
> return (HAS_LLC(obj->base.dev) ||
> obj->base.write_domain == I915_GEM_DOMAIN_CPU ||
> - !obj->map_and_fenceable ||
> obj->cache_level != I915_CACHE_NONE);
> }
>
> @@ -337,6 +336,51 @@ relocate_entry_gtt(struct drm_i915_gem_object *obj,
> return 0;
> }
>
> +static void
> +clflush_write32(void *addr, uint32_t value)
> +{
> + /* This is not a fast path, so KISS. */
> + drm_clflush_virt_range(addr, sizeof(uint32_t));
> + *(uint32_t *)addr = value;
> + drm_clflush_virt_range(addr, sizeof(uint32_t));
> +}
> +
> +static int
> +relocate_entry_clflush(struct drm_i915_gem_object *obj,
> +struct drm_i915_gem_relocation_entry *reloc,
> +uint64_t target_offset)
> +{
> + struct drm_device *dev = obj->base.dev;
> + uint32_t page_offset = offset_in_page(reloc->offset);
> + uint64_t delta = (int)reloc->delta + target_offset;
> + char *vaddr;
> + int ret;
> +
> + ret = i915_gem_object_set_to_gtt_domain(obj, true);
> + if (ret)
> + return ret;
> +
> + vaddr = kmap_atomic(i915_gem_object_get_page(obj,
> + reloc->offset >> PAGE_SHIFT));
> + clflush_write32(vaddr + page_offset, lower_32_bits(delta));
> +
> + if (INTEL_INFO(dev)->gen >= 8) {
> + page_offset = offset_in_page(page_offset + sizeof(uint32_t));
> +
> + if (page_offset == 0) {
> + kunmap_atomic(vaddr);
> + vaddr = kmap_atomic(i915_gem_object_get_page(obj,
> + (reloc->offset + sizeof(uint32_t)) >> PAGE_SHIFT));
> + }
> +
> + clflush_write32(vaddr + page_offset, upper_32_bits(delta));
> + }
> +
> + kunmap_atomic(vaddr);
> +
> + return 0;
> +}
> +
> static int
> i915_gem_execbuffer_relocate_entry(struct drm_i915_gem_object *obj,
> struct eb_vmas *eb,
> @@ -426,9 +470,12 @@ i915_gem_execbuffer_relocate_entry(struct
> drm_i915_gem_object *obj,
>
> if (use_cpu_reloc(obj))
> ret = relocate_entry_cpu(obj, reloc, target_offset);
> - else
> + else if (obj->map_and_fenceable)
> ret = relocate_entry_gtt(obj, reloc, target_offset);
> -
> + else if (cpu_has_clflush)
> + ret = relocate_entry_clflush(obj, reloc, target_offset);
> + else
> + ret = -ENODEV;
I think a DRM_ERROR here would be good since this should never happen. And
why don't we have an errno for -EKERNELBUG ...
> if (ret)
> return ret;
>
> @@ -525,6 +572,12 @@ i915_gem_execbuffer_relocate(struct eb_vmas *eb)
> return ret;
> }
>
> +static bool only_mappable_for_reloc(unsigned int flags)
> +{
> + return (flags & (EXEC_OBJECT_NEEDS_FENCE | __EXEC_OBJECT_NEEDS_MAP)) ==
> + __EXEC_OBJECT_NEEDS_MAP;
> +}
I'm slightly freaked out by us encoding this here without making it
explicit in the flags. But I couldn't come up with a better idea?
> +
> static int
> i915_gem_execbuffer_re
[Intel-gfx] infinite loop on shutdown
On shutdown, my sandy bridge laptop hangs in an infinite loop in:
xf86-video-intel/src/sna/sna_threads.c:
69 while (t->func == NULL)
70 pthread_cond_wait(&t->cond, &t->mutex);
Any idea on how to stop it waiting and just quit?
(Or what to look for if you aren't seeing this...)
FWIW
(gdb) print *t
$1 = {thread = 0x7f7ff7b68000, mutex = {ptm_magic = 858980355,
ptm_errorcheck = 0 '\000', ptm_pad1 = "\000\000",
ptm_interlock = 0 '\000', ptm_pad2 = "\000\000", ptm_owner = 0x0,
ptm_waiters = 0x0, ptm_recursed = 0, ptm_spare2 = 0x0}, cond = {
ptc_magic = 1431633925, ptc_lock = 0 '\000', ptc_waiters = {
ptqh_first = 0x7f7ff7b68000, ptqh_last = 0x7f7ff7b68230},
ptc_mutex = 0x7f7ff7b47338, ptc_private = 0x0}, func = 0x0, arg = 0x0}
Cheers,
Patrick
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] drm/i915: Add debugfs tunable for forcewake hysteresis
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 5640 -Summary- Platform Delta drm-intel-nightly Series Applied PNV 353/353 353/353 ILK -1 329/329 328/329 SNB 400/422 400/422 IVB +2 485/487 487/487 BYT 296/296 296/296 HSW +1-1 507/508 507/508 BDW 401/402 401/402 -Detailed- Platform Testdrm-intel-nightly Series Applied *ILK igt_gem_ringfill_blitter PASS(1, M26) INIT(1, M26) IVB igt_gem_pwrite_pread_snooped-pwrite-blt-cpu_mmap-performance DMESG_WARN(2, M34)PASS(2, M4) PASS(1, M34) IVB igt_gem_storedw_batches_loop_normal DMESG_WARN(2, M34M4)PASS(4, M34M4M21) PASS(1, M34) *HSW igt_gem_pwrite_pread_display-copy-performance PASS(2, M40) DMESG_WARN(1, M40) HSW igt_gem_pwrite_pread_snooped-pwrite-blt-cpu_mmap-performance DMESG_WARN(1, M40)PASS(5, M40M20) PASS(1, M40) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/bdw: Implement WaForceContextSaveRestoreNonCoherent
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ae8ea42..47bc4e2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5253,6 +5253,7 @@ enum punit_power_well {
/* GEN8 chicken */
#define HDC_CHICKEN0 0x7300
+#define HDC_FORCE_CONTEXT_SAVE_RESTORE_NON_COHERENT (1<<5)
#define HDC_FORCE_NON_COHERENT(1<<4)
#define HDC_DONOT_FETCH_MEM_WHEN_MASKED (1<<11)
#define HDC_FENCE_DEST_SLM_DISABLE(1<<14)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 36dad33..d393026 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -790,9 +790,11 @@ static int bdw_init_workarounds(struct intel_engine_cs
*ring)
*/
/* WaForceEnableNonCoherent:bdw */
/* WaHdcDisableFetchWhenMasked:bdw */
+ /* WaForceContextSaveRestoreNonCoherent:bdw */
/* WaDisableFenceDestinationToSLM:bdw (GT3 pre-production) */
WA_SET_BIT_MASKED(HDC_CHICKEN0,
HDC_FORCE_NON_COHERENT |
+ HDC_FORCE_CONTEXT_SAVE_RESTORE_NON_COHERENT |
HDC_DONOT_FETCH_MEM_WHEN_MASKED |
(IS_BDW_GT3(dev) ? HDC_FENCE_DEST_SLM_DISABLE : 0));
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/mm: Support 4 GiB and larger ranges
On Tue, Jan 27, 2015 at 09:31:26AM +0100, Thomas Hellstrom wrote: > On 01/27/2015 09:15 AM, Thierry Reding wrote: > > Are you referring to the 4 GiB - 1 comment? The point I was trying to > > make is not that the granularity of the IOVA space needs to be 1 byte > > but rather that using an unsigned long for a size on a 32-bit machine > > will give you 4 GiB - 1 addresses. The IOMMU page size is still 4 KiB > > for Tegra. > > I was rather referring to that if the range manager (drm_mm) is set up > to manage pages instead of bytes > (like, for example, the TTM VM address space), you'd get 4G - 1 pages, > which, I believe, is sufficient on most 32 bit systems? It'd probably also be more efficient on 32-bit systems rather than shifting them over to using 64-bit quantities. If the allocation granularity were to move to pages, would it be worth moving to a pfn-based addressing system too, rather than sticking with a byte address there too? -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] infinite loop on shutdown
On Tue, Jan 27, 2015 at 04:33:01PM +, Patrick Welche wrote: > On shutdown, my sandy bridge laptop hangs in an infinite loop in: > xf86-video-intel/src/sna/sna_threads.c: > > 69 while (t->func == NULL) > 70 pthread_cond_wait(&t->cond, &t->mutex); > > Any idea on how to stop it waiting and just quit? > (Or what to look for if you aren't seeing this...) The thread should be destroyed along with the parent process on termination. I guess your pthreads implementation prevents that? If so, and that is desirable, you will need to call pthread_kill() in the Xorg driver destructor - only there is not a suitable callback, so you would need to hack something into the resource system or add a counter. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915: Fallback to using CPU relocations for large batch buffers
On Tue, Jan 27, 2015 at 04:09:37PM +0100, Daniel Vetter wrote:
> On Wed, Jan 14, 2015 at 11:20:56AM +, Chris Wilson wrote:
> > static int
> > i915_gem_execbuffer_reserve_vma(struct i915_vma *vma,
> > struct intel_engine_cs *ring,
> > @@ -536,14 +589,21 @@ i915_gem_execbuffer_reserve_vma(struct i915_vma *vma,
> > int ret;
> >
> > flags = 0;
> > - if (entry->flags & __EXEC_OBJECT_NEEDS_MAP)
> > - flags |= PIN_GLOBAL | PIN_MAPPABLE;
> > - if (entry->flags & EXEC_OBJECT_NEEDS_GTT)
> > - flags |= PIN_GLOBAL;
> > - if (entry->flags & __EXEC_OBJECT_NEEDS_BIAS)
> > - flags |= BATCH_OFFSET_BIAS | PIN_OFFSET_BIAS;
> > + if (!drm_mm_node_allocated(&vma->node)) {
> > + if (entry->flags & __EXEC_OBJECT_NEEDS_MAP)
> > + flags |= PIN_GLOBAL | PIN_MAPPABLE;
> > + if (entry->flags & EXEC_OBJECT_NEEDS_GTT)
> > + flags |= PIN_GLOBAL;
> > + if (entry->flags & __EXEC_OBJECT_NEEDS_BIAS)
> > + flags |= BATCH_OFFSET_BIAS | PIN_OFFSET_BIAS;
> > + }
>
> Hm, aren't we always calling reserve un buffers we know we've just
> unbound? Keeping the flags computation would at least be a good selfcheck
> about the consistency of our placing decisions, so I'd like to keep it.
>
> >
> > ret = i915_gem_object_pin(obj, vma->vm, entry->alignment, flags);
> > + if ((ret == -ENOSPC || ret == -E2BIG) &&
> > + only_mappable_for_reloc(entry->flags))
> > + ret = i915_gem_object_pin(obj, vma->vm,
> > + entry->alignment,
> > + flags & ~(PIN_GLOBAL | PIN_MAPPABLE));
> > if (ret)
> > return ret;
> >
> > @@ -605,13 +665,13 @@ eb_vma_misplaced(struct i915_vma *vma)
> > vma->node.start & (entry->alignment - 1))
> > return true;
> >
> > - if (entry->flags & __EXEC_OBJECT_NEEDS_MAP && !obj->map_and_fenceable)
> > - return true;
> > -
> > if (entry->flags & __EXEC_OBJECT_NEEDS_BIAS &&
> > vma->node.start < BATCH_OFFSET_BIAS)
> > return true;
> >
> > + if (entry->flags & __EXEC_OBJECT_NEEDS_MAP && !obj->map_and_fenceable)
> > + return !only_mappable_for_reloc(entry->flags);
>
> Hm, this seems to contradict your commit message a bit since it'll result
> in a behavioural change of what we try to push into mappable for relocs.
>
> Shouldn't we instead just clear the NEEDS_MAP flag in reserve_vma when the
> mappable pin fails and we fall back?
This pair of chunks is required to prevent the ping-pong you just
described, which was very slow.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] agp/intel: Serialise after GTT updates
On Tue, Jan 27, 2015 at 03:58:05PM +0100, Daniel Vetter wrote: > On Mon, Jan 26, 2015 at 10:47:10AM +, Chris Wilson wrote: > > An interesting bug occurs on Pineview through which the root cause is > > that the writes of the PTE values into the GTT is not serialised with > > subsequent memory access through the GTT (when using WC updates of the > > PTE values). This is despite there being a posting read after the GTT > > update. However, by changing the address of the posting read, the memory > > access is indeed serialised correctly. > > > > Whilst we are manipulating the memory barriers, we can remove the > > compiler :memory restraint on the intermediate PTE writes knowing that > > we explicitly perform a posting read afterwards. > > > > v2: Replace posting reads with explicit write memory barriers - in > > particular this is advantages in case of single page objects. Update > > comments to mention this issue is only with WC writes. > > > > Testcase: igt/gem_exec_big #pnv > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88191 > > Tested-by: huax...@intel.com (v1) > > Signed-off-by: Chris Wilson > > Cc: Daniel Vetter > > Reviewed-by: Daniel Vetter > > Shouldn't we Cc: sta...@vger.kernel.org too? Yes, if we can narrow down a user bug it fixes, definitely. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] memcontrol.c BUG
https://bugzilla.redhat.com/show_bug.cgi?id=1165369 ov 18 09:23:22 elissa.gathman.org kernel: page:f5e36a40 count:2 mapcount:0 mapping: (null) index:0x0 Nov 18 09:23:22 elissa.gathman.org kernel: page flags: 0x80090029(locked|uptodate|lru|swapcache|swapbacked) Nov 18 09:23:22 elissa.gathman.org kernel: page dumped because: VM_BUG_ON_PAGE(!lrucare && PageLRU(oldpage)) Nov 18 09:23:23 elissa.gathman.org kernel: [ cut here ] Nov 18 09:23:23 elissa.gathman.org kernel: kernel BUG at mm/memcontrol.c:6733! Nov 18 09:23:23 elissa.gathman.org kernel: invalid opcode: [#1] SMP Nov 18 09:23:23 elissa.gathman.org kernel: Modules linked in: tcp_lp vfat fat fuse tun ccm bnep bluetooth ip6t_rpfilter ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw snd_hda_codec_idt snd_hda_codec_hdmi snd_hda_codec_generic mmc_block snd_hda_intel snd_hda_controller iTCO_wdt snd_hda_codec iTCO_vendor_support dell_wmi sdhci_pci gpio_ich sparse_keymap arc4 joydev iwl3945 snd_hwdep serio_raw sdhci snd_seq dell_laptop iwlegacy dcdbas mac80211 coretemp i2c_i801 r592 mmc_core snd_seq_device snd_pcm cfg80211 memstick rfkill snd_timer lpc_ich Nov 18 09:23:23 elissa.gathman.org kernel: snd soundcore wmi acpi_cpufreq hid_logitech_dj firewire_ohci firewire_core ata_generic i915 pata_acpi crc_itu_t i2c_algo_bit sky2 drm_kms_helper drm video Nov 18 09:23:23 elissa.gathman.org kernel: CPU: 0 PID: 966 Comm: Xorg Tainted: GW 3.17.2-200.fc20.i686 #1 Nov 18 09:23:23 elissa.gathman.org kernel: Hardware name: Dell Inc. Inspiron 1525 /0U990C, BIOS A16 10/16/2008 Nov 18 09:23:24 elissa.gathman.org kernel: task: e88adf80 ti: e88a2000 task.ti: e88a2000 Nov 18 09:23:24 elissa.gathman.org kernel: EIP: 0060:[] EFLAGS: 00013282 CPU: 0 Nov 18 09:23:24 elissa.gathman.org kernel: EIP is at mem_cgroup_migrate+0x14b/0x180 Nov 18 09:23:24 elissa.gathman.org kernel: EAX: EBX: f54eec40 ECX: f73d8ac8 EDX: Nov 18 09:23:24 elissa.gathman.org kernel: ESI: f5e36a40 EDI: c0cd3a40 EBP: e88a3b9c ESP: e88a3b84 Nov 18 09:23:24 elissa.gathman.org kernel: DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Nov 18 09:23:24 elissa.gathman.org kernel: CR0: 80050033 CR2: b69e6000 CR3: 2f3ab000 CR4: 07d0 Nov 18 09:23:24 elissa.gathman.org kernel: Stack: Nov 18 09:23:24 elissa.gathman.org kernel: c0d215c0 f54eec40 2a278f72 f54eec40 c0cd3a40 e88a3bc8 c053d71b Nov 18 09:23:24 elissa.gathman.org kernel: f54eec40 e88a3c20 8537 fffba000 c0cd3a40 f5e36a40 8537 ef3df828 Nov 18 09:23:24 elissa.gathman.org kernel: ffef e88a3c34 c053db59 e88a3c04 000214de ef3df8f8 e88adf80 e88a3c48 Nov 18 09:23:24 elissa.gathman.org kernel: Call Trace: Nov 18 09:23:25 elissa.gathman.org kernel: [] shmem_replace_page.isra.28+0x11b/0x200 Nov 18 09:23:25 elissa.gathman.org kernel: [] shmem_getpage_gfp+0x239/0x770 Nov 18 09:23:25 elissa.gathman.org kernel: [] shmem_read_mapping_page_gfp+0x3f/0x70 Nov 18 09:23:25 elissa.gathman.org kernel: [] ? sg_kfree+0x30/0x30 Nov 18 09:23:25 elissa.gathman.org kernel: [] i915_gem_object_get_pages_gtt+0x141/0x2c0 [i915] Nov 18 09:23:25 elissa.gathman.org kernel: [] ? nommu_map_sg+0x40/0xb0 Nov 18 09:23:25 elissa.gathman.org kernel: [] ? intel_gtt_insert_sg_entries+0x72/0xa0 Nov 18 09:23:25 elissa.gathman.org kernel: [] i915_gem_object_get_pages+0x66/0xa0 [i915] Nov 18 09:23:25 elissa.gathman.org kernel: [] i915_gem_object_pin+0x3ed/0x6e0 [i915] Nov 18 09:23:25 elissa.gathman.org kernel: [] i915_gem_execbuffer_reserve_vma.isra.11+0x75/0x130 [i915] Nov 18 09:23:25 elissa.gathman.org kernel: [] i915_gem_execbuffer_reserve+0x2a5/0x2d0 [i915] Nov 18 09:23:25 elissa.gathman.org kernel: [] i915_gem_do_execbuffer.isra.18+0x51e/0x11d0 [i915] Nov 18 09:23:25 elissa.gathman.org kernel: [] ? i915_gem_object_set_to_gtt_domain+0xfc/0x1b0 [i915] Nov 18 09:23:25 elissa.gathman.org kernel: [] ? i915_gem_object_ggtt_unpin+0x15/0x90 [i915] Nov 18 09:23:25 elissa.gathman.org kernel: [] ? i915_gem_execbuffer2+0x59/0x2b0 [i915] Nov 18 09:23:25 elissa.gathman.org kernel: [] i915_gem_execbuffer2+0x8b/0x2b0 [i915] Nov 18 09:23:25 elissa.gathman.org kernel: [] ? i915_gem_execbuffer+0x4e0/0x4e0 [i915] Nov 18 09:23:25 elissa.gathman.org kernel: [] drm_ioctl+0x1cf/0x520 [drm] Nov 18 09:23:25 elissa.gathman.org kernel: [] ? i915_gem_execbuffer+0x4e0/0x4e0 [i915] Nov 18 09:23:25 elissa.gathman.org kernel: [] ? timerqueue_add+0x50/0xb0 Nov 18 09:23:25 elissa.gathman.org kernel: [] ? ktime_get+0x45/0xe0 Nov 18 09:23:25 elissa.gathman.org kernel: [] ? drm_copy_field+0x70/0x70 [drm] Nov 18 09:23:25 elissa.gathman.org kernel: [] do_vfs_ioctl+0x2ea/0x4b0 Nov 18 09:23:25 elissa.gathman.org kernel: [] ? inode_has
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Use intel_gpu_freq() and intel_freq_opcode()
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 5641 -Summary- Platform Delta drm-intel-nightly Series Applied PNV -1 353/353 352/353 ILK 353/353 353/353 SNB +1-1 400/422 400/422 IVB +2-1 485/487 486/487 BYT 296/296 296/296 HSW +1-1 507/508 507/508 BDW 401/402 401/402 -Detailed- Platform Testdrm-intel-nightly Series Applied *PNV igt_gen3_render_linear_blits PASS(3, M25M23) CRASH(1, M23) *SNB igt_kms_flip_event_leak NSPT(3, M35M22) PASS(1, M22) *SNB igt_kms_flip_tiling_flip-changes-tiling PASS(2, M35M22) FAIL(1, M22) IVB igt_gem_pwrite_pread_snooped-pwrite-blt-cpu_mmap-performance DMESG_WARN(2, M34)PASS(3, M4) PASS(1, M4) IVB igt_gem_storedw_batches_loop_normal DMESG_WARN(2, M34M4)PASS(5, M34M4M21) PASS(1, M4) *IVB igt_gem_storedw_batches_loop_secure-dispatch PASS(2, M34M4) DMESG_WARN(1, M4) HSW igt_gem_pwrite_pread_snooped-pwrite-blt-cpu_mmap-performance DMESG_WARN(1, M40)PASS(5, M40M20) PASS(1, M20) HSW igt_gem_storedw_loop_vebox DMESG_WARN(1, M20)PASS(2, M40M20) DMESG_WARN(1, M20) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] gem_render_copy: Provide an all pixels check
Signed-off-by: Ben Widawsky
---
tests/gem_render_copy.c | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/tests/gem_render_copy.c b/tests/gem_render_copy.c
index 006b6f5..6348eee 100644
--- a/tests/gem_render_copy.c
+++ b/tests/gem_render_copy.c
@@ -69,6 +69,7 @@ typedef struct {
uint32_t linear[WIDTH * HEIGHT];
} data_t;
static int opt_dump_png = false;
+static int check_all_pixels = false;
static void scratch_buf_write_to_png(struct igt_buf *buf, const char *filename)
{
@@ -125,6 +126,10 @@ static int opt_handler(int opt, int opt_index)
opt_dump_png = true;
}
+ if (opt == 'a') {
+ check_all_pixels = true;
+ }
+
return 0;
}
@@ -136,7 +141,7 @@ int main(int argc, char **argv)
igt_render_copyfunc_t render_copy = NULL;
int opt_dump_aub = igt_aub_dump_enabled();
- igt_simple_init_parse_opts(argc, argv, "d", NULL, NULL, opt_handler);
+ igt_simple_init_parse_opts(argc, argv, "da", NULL, NULL, opt_handler);
igt_fixture {
data.drm_fd = drm_open_any_render();
@@ -170,6 +175,14 @@ int main(int argc, char **argv)
drm_intel_bufmgr_gem_set_aub_dump(data.bufmgr, true);
}
+ /* This will copy the src to the mid point of the dst buffer. Presumably
+* the out of bounds accesses will get clipped.
+* Resulting buffer should look like:
+*___
+* |dst|dst|
+* |dst|src|
+*---
+*/
render_copy(batch, NULL,
&src, 0, 0, WIDTH, HEIGHT,
&dst, WIDTH / 2, HEIGHT / 2);
@@ -183,6 +196,23 @@ int main(int argc, char **argv)
AUB_DUMP_BMP_FORMAT_ARGB_,
STRIDE, 0);
drm_intel_bufmgr_gem_set_aub_dump(data.bufmgr, false);
+ } else if (check_all_pixels) {
+ uint32_t val;
+ int i, j;
+ gem_read(data.drm_fd, dst.bo->handle, 0,
+data.linear, sizeof(data.linear));
+ for (i = 0; i < WIDTH; i++) {
+ for (j = 0; j < HEIGHT; j++) {
+ uint32_t color = DST_COLOR;
+ val = data.linear[j * WIDTH + i];
+ if (j >= HEIGHT/2 && i >= WIDTH/2)
+ color = SRC_COLOR;
+
+ igt_assert_f(val == color,
+"Expected 0x%08x, found 0x%08x at
(%d,%d)\n",
+color, val, i, j);
+ }
+ }
} else {
scratch_buf_check(&data, &dst, 10, 10, DST_COLOR);
scratch_buf_check(&data, &dst, WIDTH - 10, HEIGHT - 10,
SRC_COLOR);
--
2.2.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/mst: fix recursive sleep warning on qlock
From: Dave Airlie
With drm-next, we can get a backtrace like below,
this is due to the callback checking the txmsg state taking
the mutex, which can cause a sleep inside a sleep,
Fix this my creating a spinlock protecting the txmsg state
and locking it in appropriate places.
: [ cut here ]
: WARNING: CPU: 3 PID: 252 at kernel/sched/core.c:7300 __might_sleep+0xbd/0xd0()
: do not call blocking ops when !TASK_RUNNING; state=2 set at
[] prepare_to_wait_event+0x5d/0x110
: Modules linked in: i915 i2c_algo_bit drm_kms_helper drm e1000e ptp pps_core
i2c_core video
: CPU: 3 PID: 252 Comm: kworker/3:2 Not tainted 3.19.0-rc5+ #18
: Hardware name: LENOVO 20ARS25701/20ARS25701, BIOS GJET72WW (2.22 ) 02/21/2014
: Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper]
: 81a4027c 88030a763af8 81752699
: 88030a763b48 88030a763b38 810974ca 88030a763b38
: 81a41123 026d 0fa0
: Call Trace:
: [] dump_stack+0x4c/0x65
: [] warn_slowpath_common+0x8a/0xc0
: [] warn_slowpath_fmt+0x46/0x50
: [] ? prepare_to_wait_event+0x5d/0x110
: [] ? prepare_to_wait_event+0x5d/0x110
: [] __might_sleep+0xbd/0xd0
: [] mutex_lock_nested+0x2e/0x3e0
: [] ? prepare_to_wait_event+0x98/0x110
: [] drm_dp_mst_wait_tx_reply+0xa7/0x220 [drm_kms_helper]
: [] ? wait_woken+0xc0/0xc0
: [] drm_dp_send_link_address+0x61/0x240 [drm_kms_helper]
: [] ? process_one_work+0x14f/0x530
: [] drm_dp_check_and_send_link_address+0x8d/0xa0
[drm_kms_helper]
: [] drm_dp_mst_link_probe_work+0x1c/0x20 [drm_kms_helper]
: [] process_one_work+0x1c6/0x530
: [] ? process_one_work+0x14f/0x530
: [] worker_thread+0x6b/0x490
: [] ? rescuer_thread+0x350/0x350
: [] kthread+0x10a/0x120
: [] ? _raw_spin_unlock_irq+0x30/0x50
: [] ? kthread_create_on_node+0x220/0x220
: [] ret_from_fork+0x7c/0xb0
: [] ? kthread_create_on_node+0x220/0x220
: ---[ end trace bb11c9634a7217c6 ]---
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_dp_mst_topology.c | 15 +--
include/drm/drm_dp_mst_helper.h | 4 +++-
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 9a5b687..07662ae 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -733,10 +733,10 @@ static bool check_txmsg_state(struct
drm_dp_mst_topology_mgr *mgr,
struct drm_dp_sideband_msg_tx *txmsg)
{
bool ret;
- mutex_lock(&mgr->qlock);
+ spin_lock(&mgr->state_lock);
ret = (txmsg->state == DRM_DP_SIDEBAND_TX_RX ||
txmsg->state == DRM_DP_SIDEBAND_TX_TIMEOUT);
- mutex_unlock(&mgr->qlock);
+ spin_unlock(&mgr->state_lock);
return ret;
}
@@ -750,6 +750,7 @@ static int drm_dp_mst_wait_tx_reply(struct
drm_dp_mst_branch *mstb,
check_txmsg_state(mgr, txmsg),
(4 * HZ));
mutex_lock(&mstb->mgr->qlock);
+ spin_lock(&mgr->state_lock);
if (ret > 0) {
if (txmsg->state == DRM_DP_SIDEBAND_TX_TIMEOUT) {
ret = -EIO;
@@ -773,6 +774,7 @@ static int drm_dp_mst_wait_tx_reply(struct
drm_dp_mst_branch *mstb,
}
}
out:
+ spin_unlock(&mgr->state_lock);
mutex_unlock(&mgr->qlock);
return ret;
@@ -1318,10 +1320,12 @@ static int process_single_tx_qlock(struct
drm_dp_mst_topology_mgr *mgr,
memset(&hdr, 0, sizeof(struct drm_dp_sideband_msg_hdr));
+ spin_lock(&mgr->state_lock);
if (txmsg->state == DRM_DP_SIDEBAND_TX_QUEUED) {
txmsg->seqno = -1;
txmsg->state = DRM_DP_SIDEBAND_TX_START_SEND;
}
+ spin_unlock(&mgr->state_lock);
/* make hdr from dst mst - for replies use seqno
otherwise assign one */
@@ -1357,7 +1361,9 @@ static int process_single_tx_qlock(struct
drm_dp_mst_topology_mgr *mgr,
txmsg->cur_offset += tosend;
if (txmsg->cur_offset == txmsg->cur_len) {
+ spin_lock(&mgr->state_lock);
txmsg->state = DRM_DP_SIDEBAND_TX_SENT;
+ spin_unlock(&mgr->state_lock);
return 1;
}
return 0;
@@ -1386,7 +1392,9 @@ static void process_single_down_tx_qlock(struct
drm_dp_mst_topology_mgr *mgr)
list_del(&txmsg->next);
if (txmsg->seqno != -1)
txmsg->dst->tx_slots[txmsg->seqno] = NULL;
+ spin_lock(&mgr->state_lock);
txmsg->state = DRM_DP_SIDEBAND_TX_TIMEOUT;
+ spin_unlock(&mgr->state_lock);
wake_up(&mgr->tx_waitq);
}
if (list_empty(&mgr->tx_msg_downq)) {
@@ -2083,7 +2091,9 @@ static int drm_dp_mst_handle_down_rep(struct
drm_dp_mst_topology_mgr *mgr)
drm_dp_put_mst_branch_devic
Re: [Intel-gfx] [RFC PATCH 05/12] drm/i915/dsi: remove unnecessary dsi device callbacks
On 01/27/2015 06:43 PM, Chris Wilson wrote: On Tue, Jan 27, 2015 at 02:09:21PM +0100, Daniel Vetter wrote: On Tue, Jan 27, 2015 at 02:11:18PM +0530, Shobhit Kumar wrote: On 01/23/2015 08:52 PM, Daniel Vetter wrote: On Fri, Jan 23, 2015 at 03:14:41PM +0530, Shobhit Kumar wrote: On 01/22/2015 06:53 PM, Jani Nikula wrote: On Thu, 22 Jan 2015, Shobhit Kumar wrote: There had been a instance where we had to drive different resolution (lower) than the native one. Also in VBT there is a field to make this generic at least from driver perspective to give the needed target resolution. In case target resolution is same as native, nothing gets changed, else mode_fixup function adjusts the mode accordingly keeping timing as same and enabling scalar. Might not be useful in general, but did find a use internally. Can we just have the driver return the desired mode from .get_modes in that case? Okay, I think I did not explain correctly. Get modes is modified to give the needed target mode only so that userspace creates buffer of the needed resolution, but in fixup which is called at modeset, we correct the adjusted_mode back to have native resolutions so that modeset is correctly done. if we do not do like this, during modeset resolutions will be wrong as per the timings. I'm confused. Can you please give an example in real numbers about the different resolution and how it's all fixed up in hw? E.g. 800x600 framebuffer -> pfit -> 1024x756 panel, get_modes gives 800x600, adjusted mode corrects to 1024x756. And please We had a 19x12 DSI panel which we needed to drive at 12x8 due to lack of 12x8 panels for testing purposes. So get_modes returned 12x8 so that user space gave 12x8 FBs, and internally in mode_fixup we adjusted correctly for the 19x12 panel timings and enabled pfit Hm, is that a real use-case shipping to customers or just a hack for development? In the later case I think we can just hardcode the edid for edp ... Also how is this different from userspace creating a 800x600 mode and giving it to the kernel which then uses the pfitter to display it at native resolution. That is how it works today. This should also be possible with a video= parameter... Its different in a way, that user space changes will need a new system build which is not allowed as per the requirements that we had and hence no hard coding in code anywhere as well. As I said earlier also that this case might not be useful in general and I am okay to remove this callback. Regards Shobhit ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] dma-buf: cleanup dma_buf_export() to make it easily extensible
At present, dma_buf_export() takes a series of parameters, which
makes it difficult to add any new parameters for exporters, if required.
Make it simpler by moving all these parameters into a struct, and pass
the struct * as parameter to dma_buf_export().
While at it, unite dma_buf_export_named() with dma_buf_export(), and
change all callers accordingly.
Signed-off-by: Sumit Semwal
---
v2: add macro to zero out local struct, and fill KBUILD_MODNAME by default
drivers/dma-buf/dma-buf.c | 47 +-
drivers/gpu/drm/armada/armada_gem.c| 10 --
drivers/gpu/drm/drm_prime.c| 12 ---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 9 +++--
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 10 --
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 9 -
drivers/gpu/drm/tegra/gem.c| 10 --
drivers/gpu/drm/ttm/ttm_object.c | 9 +++--
drivers/gpu/drm/udl/udl_dmabuf.c | 9 -
drivers/media/v4l2-core/videobuf2-dma-contig.c | 8 -
drivers/media/v4l2-core/videobuf2-dma-sg.c | 8 -
drivers/media/v4l2-core/videobuf2-vmalloc.c| 8 -
drivers/staging/android/ion/ion.c | 9 +++--
include/linux/dma-buf.h| 35 +++
14 files changed, 143 insertions(+), 50 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 5be225c2ba98..6d3df3dd9310 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -265,7 +265,7 @@ static inline int is_dma_buf_file(struct file *file)
}
/**
- * dma_buf_export_named - Creates a new dma_buf, and associates an anon file
+ * dma_buf_export - Creates a new dma_buf, and associates an anon file
* with this buffer, so it can be exported.
* Also connect the allocator specific data and ops to the buffer.
* Additionally, provide a name string for exporter; useful in debugging.
@@ -277,31 +277,32 @@ static inline int is_dma_buf_file(struct file *file)
* @exp_name: [in]name of the exporting module - useful for debugging.
* @resv: [in]reservation-object, NULL to allocate default one.
*
+ * All the above info comes from struct dma_buf_export_info.
+ *
* Returns, on success, a newly created dma_buf object, which wraps the
* supplied private data and operations for dma_buf_ops. On either missing
* ops, or error in allocating struct dma_buf, will return negative error.
*
*/
-struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops *ops,
- size_t size, int flags, const char *exp_name,
- struct reservation_object *resv)
+struct dma_buf *dma_buf_export(struct dma_buf_export_info *exp_info)
{
struct dma_buf *dmabuf;
struct file *file;
size_t alloc_size = sizeof(struct dma_buf);
- if (!resv)
+ if (!exp_info->resv)
alloc_size += sizeof(struct reservation_object);
else
/* prevent &dma_buf[1] == dma_buf->resv */
alloc_size += 1;
- if (WARN_ON(!priv || !ops
- || !ops->map_dma_buf
- || !ops->unmap_dma_buf
- || !ops->release
- || !ops->kmap_atomic
- || !ops->kmap
- || !ops->mmap)) {
+ if (WARN_ON(!exp_info->priv
+ || !exp_info->ops
+ || !exp_info->ops->map_dma_buf
+ || !exp_info->ops->unmap_dma_buf
+ || !exp_info->ops->release
+ || !exp_info->ops->kmap_atomic
+ || !exp_info->ops->kmap
+ || !exp_info->ops->mmap)) {
return ERR_PTR(-EINVAL);
}
@@ -309,21 +310,22 @@ struct dma_buf *dma_buf_export_named(void *priv, const
struct dma_buf_ops *ops,
if (dmabuf == NULL)
return ERR_PTR(-ENOMEM);
- dmabuf->priv = priv;
- dmabuf->ops = ops;
- dmabuf->size = size;
- dmabuf->exp_name = exp_name;
+ dmabuf->priv = exp_info->priv;
+ dmabuf->ops = exp_info->ops;
+ dmabuf->size = exp_info->size;
+ dmabuf->exp_name = exp_info->exp_name;
init_waitqueue_head(&dmabuf->poll);
dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = &dmabuf->poll;
dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0;
- if (!resv) {
- resv = (struct reservation_object *)&dmabuf[1];
- reservation_object_init(resv);
+ if (!exp_info->resv) {
+ exp_info->resv = (struct reservation_object *)&dmabuf[1];
+ reservation_object_init(exp_info->resv);
}
- dmabuf->resv = resv;
+ dmabuf->resv = exp_info->resv;
- file = anon_inode_getfile("dmabuf", &dma_buf_fops, dmabuf, flags);
+
Re: [Intel-gfx] [PATCH v2] agp/intel: Serialise after GTT updates
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 5643 -Summary- Platform Delta drm-intel-nightly Series Applied PNV -1 353/353 352/353 ILK 353/353 353/353 SNB 400/422 400/422 IVB +1-1 485/487 485/487 BYT 296/296 296/296 HSW +1-2 507/508 506/508 BDW -3 401/402 398/402 -Detailed- Platform Testdrm-intel-nightly Series Applied *PNV igt_gem_concurrent_blit_cpu-bcs-overwrite-source-interruptible PASS(2, M25) NO_RESULT(1, M25) IVB igt_gem_storedw_batches_loop_normal DMESG_WARN(2, M34M4)PASS(5, M34M4M21) PASS(1, M34) *IVB igt_gem_userptr_blits_forked-unsync-swapping-mempressure-interruptible PASS(2, M34) NO_RESULT(1, M34) HSW igt_gem_pwrite_pread_snooped-pwrite-blt-cpu_mmap-performance DMESG_WARN(1, M40)PASS(7, M40M20) PASS(1, M20) HSW igt_gem_storedw_loop_vebox DMESG_WARN(1, M20)PASS(2, M40M20) DMESG_WARN(1, M20) *HSW igt_kms_flip_nonexisting-fb PASS(2, M40M20) NO_RESULT(1, M20) *BDW igt_template_B PASS(2, M30M28) NO_RESULT(1, M28) BDW igt_gem_pwrite_pread_display-pwrite-blt-gtt_mmap-performance DMESG_WARN(1, M28)PASS(1, M30) DMESG_WARN(1, M28) *BDW igt_gem_pwrite_pread_uncached-pwrite-blt-gtt_mmap-performance PASS(2, M30M28) DMESG_WARN(1, M28) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
