[git pull] drm tree for 3.12-rc1
Hi Linus, this is the main drm pull request, I have some overlap with sound and arm-soc, the sound patch is acked and may conflict based on -next reports but should be a trivial fixup, which I'll leave to you! Highlights: new drivers: MSM driver from Rob Clark non-drm: switcheroo and hdmi audio driver support for secondary GPU poweroff, so drivers can use runtime PM to poweroff the GPUs. This can save 5 or 6W on some optimus laptops. drm core: combined GEM and TTM VMA manager, per-filp mmap permission tracking initial rendernode support (via a runtime enable for now, until we get api stable), remove old proc support, lots of cleanups of legacy code hdmi vendor infoframes and 4k modes lots of gem/prime locking and races fixes async pageflip scaffolding drm bridge objects i915: Haswell PC8+ support and eLLC support, HDMI 4K support, initial per-process VMA pieces, watermark reworks, convert to generic hdmi infoframes, encoder reworking, fastboot support, radeon: CIK PM support, remove 3d blit code in favour of DMA engines, Berlin GPU support, HDMI audio fixes nouveau: secondary GPU power down support for optimus laptops, lots of fixes, use MSI, VP3 engine support exynos: runtime pm support for g2d, DT support, remove non-DT, tda998x i2c driver: lots of fixes for sync issues, gma500: lots of cleanups, rcar: add LVDS support, fbdev emulation, tegra: just minor fixes Dave. The following changes since commit 6e4dcff3adbf25acb87e74500a58e3c07bdec40f: drm/vmwgfx: Split GMR2_REMAP commands if they are to large (2013-08-30 09:03:39 +1000) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-next for you to fetch changes up to 86a7e1224a68511d3a1ae0b7e11581b9d37723ae: Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next (2013-09-05 17:48:04 +1000) Alex Deucher (104): drm/edid: add quirk for Medion MD30217PG drm/radeon: switch r6xx+ to using CP DMA for the blit copy callback drm/radeon/kms: remove r6xx+ blit copy routines drm/radeon: add UVD->DPM helper function (v5) drm/radeon/dpm: use multiple UVD power states (v3) drm/radeon/dpm: rework thermal state handling drm/radeon: default to 1024M gart size on rv770+ drm/radeon/dpm: use performance state if no UVD state drm/radeon/kms: fix up dce8 display watermark calc for dpm drm/radeon/cik: implement some more atom helpers for DPM drm/radeon: switch CIK to use radeon_ucode.h drm/radeon/cik: add support for pcie gen1/2/3 switching drm/radeon: add support for ASPM on CIK asics drm/radeon/cik: restructure rlc setup drm/radeon: clean up sumo_rlc_init() for code sharing drm/radeon: convert SI,CIK to use sumo_rlc functions drm/radeon: implement clock and power gating for CIK (v3) drm/radeon: add indirect accessors for dift registers on CIK drm/radeon/sumo add helper to go from vid7 to vid2 drm/radeon: switch to pptable.h drm/radeon: add structs to store uvd clock voltage deps drm/radeon/cik: add rlc helpers for DPM drm/radeon: add support for thermal controller on KB/KV drm/radeon: add CI to r600_is_internal_thermal_sensor() drm/radeon: add KB/KV to r600_is_internal_thermal_sensor drm/radeon: add get_temperature() callbacks for CIK (v2) drm/radeon: adjust si_dpm function for code sharing drm/radeon/dpm: update cac leakage table parsing for CI drm/radeon/dpm: add support for parsing the atom powertune table drm/radeon/dpm: grab mvdd_dependency_on_mclk info from vbios drm/radeon: add structs to store vce clock voltage deps drm/radeon: add clock voltage dep tables for acp, samu drm/radeon: parse the vce clock voltage deps table drm/radeon: parse the uvd clock voltage deps table drm/radeon/dpm: clean up the extended table error pathes drm/radeon: parse the samu clock voltage deps table drm/radeon: parse the acp clock voltage deps table drm/radeon: add r600_get_pcie_lane_support helper drm/radeon/dpm: add vce clocks to radeon_ps drm/radeon/dpm: add a helper to encode pcie lane setting drm/radeon/dpm: add helper to fetch the vrefresh of the current mode drm/radeon/kms: add dpm support for KB/KV drm/radeon: add dpm support for CI dGPUs (v2) drm/radeon/dpm: add debugfs support for CI drm/radeon/dpm: implement force performance level for CI drm/radeon/dpm: implement vblank_too_short callback for CI drm/radeon/dpm: add debugfs support for KB/KV drm/radeon/dpm: implement force performance level for KB/KV drm/radeon/dpm: add new callback for powergating UVD (v4) drm/radeon: restructure UVD code to handle UVD PG (v2)
[PATCH] DRM: TTM: Fix memory leak issue in ttm_agp_tt_create().
From: Jeyaraman R jeyaraman.rangas...@lge.com
This patch adds kfree() in ttm_agp_tt_create() to avoide the
memory leak, without this there is a chance of memory leak in
ttm_tt_init() fail case.
Signed-off-by: Jeyaraman R jeyaraman.rangas...@lge.com
Signed-off-by: Manjunath Goudar manjunath.gou...@linaro.org
Cc: David Airlie airl...@linux.ie
Cc: Paul E. McKenney paul...@linux.vnet.ibm.com
Cc: David Howells dhowe...@redhat.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Dave Jones da...@redhat.com
Cc: Dave Airlie airl...@redhat.com
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
drivers/gpu/drm/ttm/ttm_agp_backend.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
b/drivers/gpu/drm/ttm/ttm_agp_backend.c
index 3302f99..764be36 100644
--- a/drivers/gpu/drm/ttm/ttm_agp_backend.c
+++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c
@@ -126,6 +126,7 @@ struct ttm_tt *ttm_agp_tt_create(struct ttm_bo_device *bdev,
agp_be-ttm.func = ttm_agp_func;
if (ttm_tt_init(agp_be-ttm, bdev, size, page_flags, dummy_read_page))
{
+ kfree(agp_be);
return NULL;
}
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC v3 08/19] video: display: Add MIPI DBI bus support
Hi Laurent,
On 9 August 2013 22:44, Laurent Pinchart
laurent.pinchart+rene...@ideasonboard.com wrote:
MIPI DBI is a configurable-width parallel display bus that transmits
commands and data.
Add a new DBI Linux bus type that implements the usual bus
infrastructure (including devices and drivers (un)registration and
matching, and bus configuration and access functions).
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/display/Kconfig| 8 ++
drivers/video/display/Makefile | 1 +
drivers/video/display/mipi-dbi-bus.c | 234
+++
include/video/display.h | 4 +
include/video/mipi-dbi-bus.h | 125 +++
5 files changed, 372 insertions(+)
create mode 100644 drivers/video/display/mipi-dbi-bus.c
create mode 100644 include/video/mipi-dbi-bus.h
diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
index 1d533e7..f7532c1 100644
--- a/drivers/video/display/Kconfig
+++ b/drivers/video/display/Kconfig
@@ -2,3 +2,11 @@ menuconfig DISPLAY_CORE
tristate Display Core
---help---
Support common display framework for graphics devices.
+
+if DISPLAY_CORE
+
+config DISPLAY_MIPI_DBI
+ tristate
+ default n
+
+endif # DISPLAY_CORE
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
index b907aad..59022d2 100644
--- a/drivers/video/display/Makefile
+++ b/drivers/video/display/Makefile
@@ -1,3 +1,4 @@
display-y := display-core.o \
display-notifier.o
obj-$(CONFIG_DISPLAY_CORE) += display.o
+obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o
diff --git a/drivers/video/display/mipi-dbi-bus.c
b/drivers/video/display/mipi-dbi-bus.c
new file mode 100644
index 000..791fb4d
--- /dev/null
+++ b/drivers/video/display/mipi-dbi-bus.c
@@ -0,0 +1,234 @@
+/*
+ * MIPI DBI Bus
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart laurent.pinch...@ideasonboard.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/device.h
+#include linux/export.h
+#include linux/kernel.h
+#include linux/list.h
+#include linux/module.h
+#include linux/mutex.h
+#include linux/pm.h
+#include linux/pm_runtime.h
+
+#include video/mipi-dbi-bus.h
+
+/*
-
+ * Bus operations
+ */
+
+int mipi_dbi_set_data_width(struct mipi_dbi_device *dev, unsigned int width)
+{
+ if (width != 8 width != 16)
+ return -EINVAL;
+
+ dev-data_width = width;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_set_data_width);
+
+int mipi_dbi_write_command(struct mipi_dbi_device *dev, u16 cmd)
+{
+ return dev-bus-ops-write_command(dev-bus, dev, cmd);
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_write_command);
+
+int mipi_dbi_write_data(struct mipi_dbi_device *dev, const u8 *data,
+ size_t len)
+{
+ return dev-bus-ops-write_data(dev-bus, dev, data, len);
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_write_data);
+
+int mipi_dbi_read_data(struct mipi_dbi_device *dev, u8 *data, size_t len)
+{
+ return dev-bus-ops-read_data(dev-bus, dev, data, len);
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_read_data);
+
+/*
-
+ * Bus type
+ */
+
+static const struct mipi_dbi_device_id *
+mipi_dbi_match_id(const struct mipi_dbi_device_id *id,
+ struct mipi_dbi_device *dev)
+{
+ while (id-name[0]) {
+ if (strcmp(dev-name, id-name) == 0) {
+ dev-id_entry = id;
+ return id;
+ }
+ id++;
+ }
+ return NULL;
+}
+
+static int mipi_dbi_match(struct device *_dev, struct device_driver *_drv)
+{
+ struct mipi_dbi_device *dev = to_mipi_dbi_device(_dev);
+ struct mipi_dbi_driver *drv = to_mipi_dbi_driver(_drv);
+
+ if (drv-id_table)
+ return mipi_dbi_match_id(drv-id_table, dev) != NULL;
+
+ return (strcmp(dev-name, _drv-name) == 0);
+}
+
+static ssize_t modalias_show(struct device *_dev, struct device_attribute *a,
+char *buf)
+{
+ struct mipi_dbi_device *dev = to_mipi_dbi_device(_dev);
+ int len = snprintf(buf, PAGE_SIZE, MIPI_DBI_MODULE_PREFIX %s\n,
+ dev-name);
+
+ return (len = PAGE_SIZE) ? (PAGE_SIZE - 1) : len;
+}
+
+static struct device_attribute mipi_dbi_dev_attrs[] = {
+ __ATTR_RO(modalias),
+ __ATTR_NULL,
+};
+
+static int
Re: [PATCH/RFC v3 08/19] video: display: Add MIPI DBI bus support
Hi Laurent,
On 9 August 2013 22:44, Laurent Pinchart
laurent.pinchart+rene...@ideasonboard.com wrote:
MIPI DBI is a configurable-width parallel display bus that transmits
commands and data.
Add a new DBI Linux bus type that implements the usual bus
infrastructure (including devices and drivers (un)registration and
matching, and bus configuration and access functions).
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/display/Kconfig| 8 ++
drivers/video/display/Makefile | 1 +
drivers/video/display/mipi-dbi-bus.c | 234
+++
include/video/display.h | 4 +
include/video/mipi-dbi-bus.h | 125 +++
5 files changed, 372 insertions(+)
create mode 100644 drivers/video/display/mipi-dbi-bus.c
create mode 100644 include/video/mipi-dbi-bus.h
diff --git a/drivers/video/display/Kconfig b/drivers/video/display/Kconfig
index 1d533e7..f7532c1 100644
--- a/drivers/video/display/Kconfig
+++ b/drivers/video/display/Kconfig
@@ -2,3 +2,11 @@ menuconfig DISPLAY_CORE
tristate Display Core
---help---
Support common display framework for graphics devices.
+
+if DISPLAY_CORE
+
+config DISPLAY_MIPI_DBI
+ tristate
+ default n
+
+endif # DISPLAY_CORE
diff --git a/drivers/video/display/Makefile b/drivers/video/display/Makefile
index b907aad..59022d2 100644
--- a/drivers/video/display/Makefile
+++ b/drivers/video/display/Makefile
@@ -1,3 +1,4 @@
display-y := display-core.o \
display-notifier.o
obj-$(CONFIG_DISPLAY_CORE) += display.o
+obj-$(CONFIG_DISPLAY_MIPI_DBI) += mipi-dbi-bus.o
diff --git a/drivers/video/display/mipi-dbi-bus.c
b/drivers/video/display/mipi-dbi-bus.c
new file mode 100644
index 000..791fb4d
--- /dev/null
+++ b/drivers/video/display/mipi-dbi-bus.c
@@ -0,0 +1,234 @@
+/*
+ * MIPI DBI Bus
+ *
+ * Copyright (C) 2012 Renesas Solutions Corp.
+ *
+ * Contacts: Laurent Pinchart laurent.pinch...@ideasonboard.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/device.h
+#include linux/export.h
+#include linux/kernel.h
+#include linux/list.h
+#include linux/module.h
+#include linux/mutex.h
+#include linux/pm.h
+#include linux/pm_runtime.h
+
+#include video/mipi-dbi-bus.h
+
+/*
-
+ * Bus operations
+ */
+
+int mipi_dbi_set_data_width(struct mipi_dbi_device *dev, unsigned int width)
+{
+ if (width != 8 width != 16)
+ return -EINVAL;
+
+ dev-data_width = width;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_set_data_width);
+
+int mipi_dbi_write_command(struct mipi_dbi_device *dev, u16 cmd)
+{
+ return dev-bus-ops-write_command(dev-bus, dev, cmd);
Can you help me in pointing out where these function pointer (
ops-write_command ) are assigned in case MIPI DBI.
In case of exynos ( drivers/video/exynos/exynos_mipi_dsi.c ), we
assign them as below and register DSI as a platform device
static struct mipi_dsim_master_ops master_ops = {
.cmd_read = exynos_mipi_dsi_rd_data,
.cmd_write = exynos_mipi_dsi_wr_data,
.get_dsim_frame_done= exynos_mipi_dsi_get_frame_done_status,
.clear_dsim_frame_done = exynos_mipi_dsi_clear_frame_done,
.set_early_blank_mode = exynos_mipi_dsi_early_blank_mode,
.set_blank_mode = exynos_mipi_dsi_blank_mode,
};
Since now you are saying to have it as linux BUS, how should we
register these ops and how we can configure the MIPI DSI hw itself if
we register it as bus. I could not find any help in mipi-dbi-bus.c,
how we actually configure the MIPI DBI h/w itself.
ideally mipi-dbi-bus.c should have done 2 things
==
1. provide a framework to register the DBI kind of panel = which is supported
2. provide a framework to register the actuall MIPI DBI H/W itself =
which i think is missing( correct me, if i am missing
anything )
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_write_command);
+
+int mipi_dbi_write_data(struct mipi_dbi_device *dev, const u8 *data,
+ size_t len)
+{
+ return dev-bus-ops-write_data(dev-bus, dev, data, len);
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_write_data);
+
+int mipi_dbi_read_data(struct mipi_dbi_device *dev, u8 *data, size_t len)
+{
+ return dev-bus-ops-read_data(dev-bus, dev, data, len);
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_read_data);
+
+/*
-
+
[PATCH] drm/i915: i915.quirks_set/quirks_mask overrides dmi match
Boot params quirks_set and quirks_mask allow the user to enable or
inhibit any dmi-matched quirks, overriding the dmi match table. Examples:
i915.quirks_set=0x2 - enables QUIRK_LVDS_SSC_DISABLE
i915.quirks_set=0x8 - enables QUIRK_NO_PCH_PWM_ENABLE
i915.quirks_mask=0x8 - disables QUIRK_NO_PCH_PWM_ENABLE
i915.quirks_mask=0xFF - disables all quirks
Signed-off-by: Kamal Mostafa ka...@canonical.com
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/intel_display.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d88057e..a6af11c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10028,8 +10028,19 @@ static struct intel_quirk intel_quirks[] = {
{ 0x0166, 0x1028, 0x058b, quirk_no_pcm_pwm_enable },
};
+unsigned long i915_quirks_set __read_mostly = 0;
+module_param_named(quirks_set, i915_quirks_set, ulong, 0600);
+MODULE_PARM_DESC(quirks_set,
+ Enable specified quirks bits.);
+
+unsigned long i915_quirks_mask __read_mostly = 0;
+module_param_named(quirks_mask, i915_quirks_mask, ulong, 0600);
+MODULE_PARM_DESC(quirks_mask,
+ Disable specified quirks bits (override dmi match).);
+
static void intel_init_quirks(struct drm_device *dev)
{
+ struct drm_i915_private *dev_priv = dev-dev_private;
struct pci_dev *d = dev-pdev;
int i;
@@ -10047,6 +10058,10 @@ static void intel_init_quirks(struct drm_device *dev)
if (dmi_check_system(*intel_dmi_quirks[i].dmi_id_list) != 0)
intel_dmi_quirks[i].hook(dev);
}
+
+ /* handle user-specified quirks overrides */
+ dev_priv-quirks |= i915_quirks_set;
+ dev_priv-quirks = ~i915_quirks_mask;
}
/* Disable the VGA plane that we never use */
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/6] host1x: hdmi: Enable Vdd earlier for hotplug/DDC
On 09/04/2013 09:44 PM, Stephen Warren wrote: On 08/28/2013 09:48 AM, Mikko Perttunen wrote: The Vdd regulator used to be enabled only at tegra_output_hdmi_enable, which is called after a sink is detected. However, the HDMI hotplug pin works by returning the voltage supplied by the Vdd pin, so this meant that the hotplug pin was never asserted and the sink was not detected unless the Vdd regulator was set to be always on. This patch moves the enable to the tegra_hdmi_drm_init function to make sure the regulator will get enabled. The DT binding document isn't very clear on this topic (and should be fixed): What is this regulator intended to control? If this regulator solely controls the supply to the hotplug detection circuit, this change makes sense. If the regulator mainly supplies something else (e.g. part of the HDMI core on the Tegra chip), then perhaps this change isn't correct. The correct approach might be to introduce another (optional) regulator specifically for the hotplug circuit. Presumably both DT properties vdd-supply and hotplug-supply could point at the same regulator if that's the way the HW was wired up. -- To unsubscribe from this list: send the line unsubscribe linux-tegra in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html AFAICT, it controls the Vdd pin on the HDMI port, so it just affects the hotplug pin and the DDC I2C bus power. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #107 from Bryan Quigley gquigs+b...@gmail.com --- Created attachment 85216 -- https://bugs.freedesktop.org/attachment.cgi?id=85216action=edit 3870/RV670 - dmesg manually loading radeon I'm also having the issue on a 3870/RV670 using Sept4 drm-next (d30645ae from Ubuntu's mainline builds) and previous builds. Disabling radeon.aspm=0 also didn't help. My machine is accessible via SSH so I can do further debugging. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #108 from Bryan Quigley gquigs+b...@gmail.com --- Created attachment 85217 -- https://bugs.freedesktop.org/attachment.cgi?id=85217action=edit 3870/RV670 - kern.log dpm on boot -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #109 from Bryan Quigley gquigs+b...@gmail.com --- Created attachment 85218 -- https://bugs.freedesktop.org/attachment.cgi?id=85218action=edit 3870/RV670 - vbios.rom -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #110 from Bryan Quigley gquigs+b...@gmail.com --- Also, the motherboard has a built-in HD4290 in it, that is BIOS disabled. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
ow...@vger.kernel.org] On Behalf Of Sean Paul
Sent: Wednesday, September 04, 2013 11:52 PM
To: Inki Dae
Cc: Rahul Sharma; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
Shirish S
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
On Wed, Sep 4, 2013 at 3:37 AM, Inki Dae inki@samsung.com wrote:
-Original Message-
From: Rahul Sharma [mailto:r.sh.o...@gmail.com]
Sent: Wednesday, September 04, 2013 2:48 PM
To: Sean Paul
Cc: Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim; sw0312.kim;
InKi Dae; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
shir...@chromium.org
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to
hdmiphy
driver
Thanks Sean,
On 3 September 2013 20:15, Sean Paul seanp...@chromium.org wrote:
A few comments.
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma
rahul.sha...@samsung.com
wrote:
Exynos hdmiphy operations and configs are kept inside
the hdmi driver. Hdmiphy related code is tightly coupled
with hdmi IP driver.
This patche moves hdmiphy related code to hdmiphy driver.
s/patche/patch
ok.
It will help in cleanly supporting the hdmiphy variations
in further SoCs.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
.../devicetree/bindings/video/exynos_hdmi.txt |2 +
drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 +
drivers/gpu/drm/exynos/exynos_hdmi.c | 343
+++
drivers/gpu/drm/exynos/exynos_hdmiphy.c| 438
+++-
drivers/gpu/drm/exynos/regs-hdmiphy.h | 35 ++
5 files changed, 533 insertions(+), 296 deletions(-)
create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 50decf8..240eca5 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -25,6 +25,7 @@ Required properties:
sclk_pixel.
- clock-names: aliases as per driver requirements for above clock
IDs:
hdmi, sclk_hdmi, sclk_pixel, sclk_hdmiphy and
mout_hdmi.
+- phy: it points to hdmiphy dt node.
Example:
hdmi {
@@ -32,4 +33,5 @@ Example:
reg = 0x1453 0x10;
interrupts = 0 95 0;
hpd-gpio = gpx3 7 1;
+ phy = hdmiphy;
};
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
index 724cab1..1c839f8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
@@ -64,4 +64,15 @@ void exynos_hdmi_drv_attach(struct
exynos_drm_hdmi_context *ctx);
void exynos_mixer_drv_attach(struct exynos_drm_hdmi_context *ctx);
void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops);
void exynos_mixer_ops_register(struct exynos_mixer_ops *ops);
+
+int exynos_hdmiphy_driver_register(void);
+void exynos_hdmiphy_driver_unregister(void);
+
+void exynos_hdmiphy_enable(struct device *dev);
+void exynos_hdmiphy_disable(struct device *dev);
+int exynos_hdmiphy_check_mode(struct device *dev,
+ struct drm_display_mode *mode);
+int exynos_hdmiphy_set_mode(struct device *dev,
+ struct drm_display_mode *mode);
+int exynos_hdmiphy_conf_apply(struct device *dev);
#endif
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index f67ffca..3af4e4c 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -34,6 +34,8 @@
#include linux/io.h
#include linux/of.h
#include linux/of_gpio.h
+#include linux/of_i2c.h
+#include linux/of_platform.h
#include drm/exynos_drm.h
@@ -172,7 +174,6 @@ struct hdmi_v14_conf {
};
struct hdmi_conf_regs {
- int pixel_clock;
int cea_video_id;
union {
struct hdmi_v13_conf v13_conf;
@@ -193,9 +194,9 @@ struct hdmi_context {
int irq;
struct i2c_client *ddc_port;
- struct i2c_client *hdmiphy_port;
+ struct device *hdmiphy_dev;
- /* current hdmiphy conf regs */
+ /* current hdmi ip configuration registers. */
struct hdmi_conf_regs mode_conf;
struct hdmi_resources res;
@@ -205,180 +206,6 @@ struct hdmi_context {
enum hdmi_type
Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
On 5 September 2013 09:46, Inki Dae inki@samsung.com wrote:
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
ow...@vger.kernel.org] On Behalf Of Sean Paul
Sent: Wednesday, September 04, 2013 11:52 PM
To: Inki Dae
Cc: Rahul Sharma; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
Shirish S
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
On Wed, Sep 4, 2013 at 3:37 AM, Inki Dae inki@samsung.com wrote:
-Original Message-
From: Rahul Sharma [mailto:r.sh.o...@gmail.com]
Sent: Wednesday, September 04, 2013 2:48 PM
To: Sean Paul
Cc: Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim; sw0312.kim;
InKi Dae; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
shir...@chromium.org
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to
hdmiphy
driver
Thanks Sean,
On 3 September 2013 20:15, Sean Paul seanp...@chromium.org wrote:
A few comments.
On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma
rahul.sha...@samsung.com
wrote:
Exynos hdmiphy operations and configs are kept inside
the hdmi driver. Hdmiphy related code is tightly coupled
with hdmi IP driver.
This patche moves hdmiphy related code to hdmiphy driver.
s/patche/patch
ok.
It will help in cleanly supporting the hdmiphy variations
in further SoCs.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
.../devicetree/bindings/video/exynos_hdmi.txt |2 +
drivers/gpu/drm/exynos/exynos_drm_hdmi.h | 11 +
drivers/gpu/drm/exynos/exynos_hdmi.c | 343
+++
drivers/gpu/drm/exynos/exynos_hdmiphy.c| 438
+++-
drivers/gpu/drm/exynos/regs-hdmiphy.h | 35 ++
5 files changed, 533 insertions(+), 296 deletions(-)
create mode 100644 drivers/gpu/drm/exynos/regs-hdmiphy.h
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 50decf8..240eca5 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -25,6 +25,7 @@ Required properties:
sclk_pixel.
- clock-names: aliases as per driver requirements for above clock
IDs:
hdmi, sclk_hdmi, sclk_pixel, sclk_hdmiphy and
mout_hdmi.
+- phy: it points to hdmiphy dt node.
Example:
hdmi {
@@ -32,4 +33,5 @@ Example:
reg = 0x1453 0x10;
interrupts = 0 95 0;
hpd-gpio = gpx3 7 1;
+ phy = hdmiphy;
};
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
index 724cab1..1c839f8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
@@ -64,4 +64,15 @@ void exynos_hdmi_drv_attach(struct
exynos_drm_hdmi_context *ctx);
void exynos_mixer_drv_attach(struct exynos_drm_hdmi_context *ctx);
void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops);
void exynos_mixer_ops_register(struct exynos_mixer_ops *ops);
+
+int exynos_hdmiphy_driver_register(void);
+void exynos_hdmiphy_driver_unregister(void);
+
+void exynos_hdmiphy_enable(struct device *dev);
+void exynos_hdmiphy_disable(struct device *dev);
+int exynos_hdmiphy_check_mode(struct device *dev,
+ struct drm_display_mode *mode);
+int exynos_hdmiphy_set_mode(struct device *dev,
+ struct drm_display_mode *mode);
+int exynos_hdmiphy_conf_apply(struct device *dev);
#endif
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index f67ffca..3af4e4c 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -34,6 +34,8 @@
#include linux/io.h
#include linux/of.h
#include linux/of_gpio.h
+#include linux/of_i2c.h
+#include linux/of_platform.h
#include drm/exynos_drm.h
@@ -172,7 +174,6 @@ struct hdmi_v14_conf {
};
struct hdmi_conf_regs {
- int pixel_clock;
int cea_video_id;
union {
struct hdmi_v13_conf v13_conf;
@@ -193,9 +194,9 @@ struct hdmi_context {
int irq;
struct i2c_client *ddc_port;
- struct i2c_client *hdmiphy_port;
+ struct device *hdmiphy_dev;
- /* current hdmiphy conf regs */
+ /* current hdmi ip configuration registers. */
struct hdmi_conf_regs mode_conf;
struct hdmi_resources res;
@@ -205,180 +206,6 @@
RE: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
+static struct hdmiphy_config hdmiphy_4210_configs[] = {
+ {
+ .pixel_clock = 2700,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30,
0x40,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 27027000,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C, 0x09,
0x64,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 74176000,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xef,
0x5B,
+ 0x6D, 0x10, 0x01, 0x51, 0xef, 0xF3, 0x54,
0xb9,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10,
0xE0,
+ 0x22, 0x40, 0xa5, 0x26, 0x01, 0x00, 0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 7425,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xd8, 0x10, 0x9c, 0xf8,
0x40,
+ 0x6a, 0x10, 0x01, 0x51, 0xff, 0xf1, 0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00, 0x08, 0x10,
0xe0,
+ 0x22, 0x40, 0xa4, 0x26, 0x01, 0x00, 0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 14850,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xf8,
0x40,
+ 0x6A, 0x18, 0x00, 0x51, 0xff, 0xF1, 0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00, 0x08, 0x10,
0xE0,
+ 0x22, 0x40, 0xa4, 0x26, 0x02, 0x00, 0x00,
0x00,
+ },
+ },
+};
+
Are you aware of the effort to move these to dt? Since these are
board-specific values, it seems incorrect to apply them
universally.
Shirish has uploaded a patch to the chromium review site to push
these
into dt (https://chromium-review.googlesource.com/#/c/65581).
Maybe
you can work that into your patch set?
Are these really board-specific values?
According to your hardware people:
If the signal pattern doesn't change for new board, the phy setting
is same as the current board. But if changed, you need to confirm with
measurement of signals, because it may vary slightly by resistance of
board pattern
Right. it seems that the phy configuration should be adjusted according
to
PCB environment: OSC clock rate, 24MHz or 27MHz, could be decided by PCB
even though most PCBs use 27MHz.
That indicates to me that we might need to tweak these on a per-board
basis.
In the 5420 datasheet, there are a few register descriptions available
for the phy. 0x145D0004 is CLK_SEL which seems like it would be
board-specific, same with TX_* registers.
And we can select HDMI Tx PHY internal PLL input clock by setting
CLK_SEL.
Ok, Shirish's patch set is reasonable to me. However, that patch set
should
be rebased on top of Rahul's patch set. Shirish and Rahul, please re-
post
your patch set after discussing how to rebase these patch set.
Thanks,
Inki Dae
In that case, we need to test the phy confs for all the exynos boards,
supported in
mainline. Probably needs a analyser as well to precisely compare the
deviation.
Shirish patch adds phy config data only to arndale and smdk5250 boards, and
these config data should have each board specific values. Therefore, for
other boards, shouldn't correct phy config data suitable to their boards be
added to their board dts files? Is the above analyzer really needed?
Shirish patch is only for 5420 Peach board. Else, to start with we can
mark
phyconf as optional property which overrides the default Phy Confs for
given SoC.
Hm you mean that hdmiphy driver use the default phy config data in
driver; most boards use the same data, and only in special case; a board
uses different OSC clock rate, the hdmiphy driver use phy config data from
dts file checking hdmiphy-confs property?
regards,
Rahul Sharma.
Sean
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] exynos-drm-next
Hi Dave, This pull request adds device tree and runtime pm supports, fixups, and code cleanups. Summary: - Consider fallback option to gem allocation fail . try to allocate physically non-contiguous memory if iommu is supported when physically contiguous memory allocation failed. - Add runtime pm support to g2d driver - Add device tree support . add device tree support to rotator driver, make fimd driver get signal polarities from device tree. - some fixups . correct pixel format setting to fimd driver, and consider pixel format checking to a particular window layer. - some cleanups . replace fb_videomode with videomode. . remove non-DT support And, there are two patch sets that have been reviewed yet. These update hdmiphy driver and add device tree support to it. I will requst pull one more time after reviewed enough. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit 3b28802e37bb1ca1cab584f679c42e72a7e384f8: drm/tda998x: BUG() on invalid audio format (2013-09-05 08:52:19 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos exynos-drm-next for you to fetch changes up to 6914262aa52ec2d23dd2cc9e439874ca1917cf82: drm/exynos: Fix build error with exynos_drm_connector.c (2013-09-05 13:43:46 +0900) Andrzej Hajda (3): drm/exynos: fimd: replace struct fb_videomode with videomode drm/exynos: fimd: get signal polarities from device tree drm/exynos: fimd: move platform data parsing to separate function Chanho Park (1): drm/exynos: add device tree support for rotator Inki Dae (3): drm/exynos: add runtime pm interfaces to g2d driver drm/exynos: fix fimd pixel format setting drm/exynos: check a pixel format to a particular window layer Mark Brown (1): drm/exynos: Add missing includes Sachin Kamat (11): drm/exynos: Remove redundant NULL check in exynos_drm_buf drm/exynos: Add missing of.h header include drm/exynos: Remove redundant error messages drm/exynos: Add NULL pointer check drm/exynos: Make Exynos DRM drivers depend on OF drm/exynos: Remove non-DT support in exynos_ddc drm/exynos: Remove non-DT support in exynos_hdmiphy drm/exynos: Remove non-DT support in exynos_drm_g2d drm/exynos: Remove non-DT support in exynos_hdmi drm/exynos: Remove non-DT support in exynos_drm_fimd drm/exynos: Fix build error with exynos_drm_connector.c Vikas Sajjan (2): drm/exynos: Add fallback option to get non physically contiguous memory for fb drm/exynos: Consider fallback option to allocation fail .../devicetree/bindings/gpu/samsung-rotator.txt| 27 ++ drivers/gpu/drm/exynos/Kconfig |6 +- drivers/gpu/drm/exynos/exynos_ddc.c| 13 +- drivers/gpu/drm/exynos/exynos_drm_buf.c|9 +- drivers/gpu/drm/exynos/exynos_drm_connector.c | 38 +-- drivers/gpu/drm/exynos/exynos_drm_crtc.c |5 +- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |2 +- drivers/gpu/drm/exynos/exynos_drm_drv.c|4 +- drivers/gpu/drm/exynos/exynos_drm_encoder.c|4 +- drivers/gpu/drm/exynos/exynos_drm_fb.c |8 +- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 20 +- drivers/gpu/drm/exynos/exynos_drm_fimc.c |6 +- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 263 +--- drivers/gpu/drm/exynos/exynos_drm_g2d.c| 60 +++-- drivers/gpu/drm/exynos/exynos_drm_gem.c| 17 +- drivers/gpu/drm/exynos/exynos_drm_gsc.c|5 +- drivers/gpu/drm/exynos/exynos_drm_hdmi.c |4 +- drivers/gpu/drm/exynos/exynos_drm_iommu.c |9 + drivers/gpu/drm/exynos/exynos_drm_ipp.c| 22 +- drivers/gpu/drm/exynos/exynos_drm_plane.c |5 +- drivers/gpu/drm/exynos/exynos_drm_rotator.c| 117 ++--- drivers/gpu/drm/exynos/exynos_drm_vidi.c |1 + drivers/gpu/drm/exynos/exynos_hdmi.c | 87 ++- drivers/gpu/drm/exynos/exynos_hdmiphy.c| 12 +- drivers/gpu/drm/exynos/exynos_mixer.c |9 +- include/drm/exynos_drm.h |3 +- 26 files changed, 357 insertions(+), 399 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpu/samsung-rotator.txt ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
On 5 September 2013 10:52, Inki Dae inki@samsung.com wrote:
+static struct hdmiphy_config hdmiphy_4210_configs[] = {
+ {
+ .pixel_clock = 2700,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30,
0x40,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 27027000,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C, 0x09,
0x64,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00, 0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 74176000,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xef,
0x5B,
+ 0x6D, 0x10, 0x01, 0x51, 0xef, 0xF3, 0x54,
0xb9,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08, 0x10,
0xE0,
+ 0x22, 0x40, 0xa5, 0x26, 0x01, 0x00, 0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 7425,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xd8, 0x10, 0x9c, 0xf8,
0x40,
+ 0x6a, 0x10, 0x01, 0x51, 0xff, 0xf1, 0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00, 0x08, 0x10,
0xe0,
+ 0x22, 0x40, 0xa4, 0x26, 0x01, 0x00, 0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 14850,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C, 0xf8,
0x40,
+ 0x6A, 0x18, 0x00, 0x51, 0xff, 0xF1, 0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00, 0x08, 0x10,
0xE0,
+ 0x22, 0x40, 0xa4, 0x26, 0x02, 0x00, 0x00,
0x00,
+ },
+ },
+};
+
Are you aware of the effort to move these to dt? Since these are
board-specific values, it seems incorrect to apply them
universally.
Shirish has uploaded a patch to the chromium review site to push
these
into dt (https://chromium-review.googlesource.com/#/c/65581).
Maybe
you can work that into your patch set?
Are these really board-specific values?
According to your hardware people:
If the signal pattern doesn't change for new board, the phy setting
is same as the current board. But if changed, you need to confirm with
measurement of signals, because it may vary slightly by resistance of
board pattern
Right. it seems that the phy configuration should be adjusted according
to
PCB environment: OSC clock rate, 24MHz or 27MHz, could be decided by PCB
even though most PCBs use 27MHz.
That indicates to me that we might need to tweak these on a per-board
basis.
In the 5420 datasheet, there are a few register descriptions available
for the phy. 0x145D0004 is CLK_SEL which seems like it would be
board-specific, same with TX_* registers.
And we can select HDMI Tx PHY internal PLL input clock by setting
CLK_SEL.
Ok, Shirish's patch set is reasonable to me. However, that patch set
should
be rebased on top of Rahul's patch set. Shirish and Rahul, please re-
post
your patch set after discussing how to rebase these patch set.
Thanks,
Inki Dae
In that case, we need to test the phy confs for all the exynos boards,
supported in
mainline. Probably needs a analyser as well to precisely compare the
deviation.
Shirish patch adds phy config data only to arndale and smdk5250 boards, and
these config data should have each board specific values. Therefore, for
other boards, shouldn't correct phy config data suitable to their boards be
added to their board dts files? Is the above analyzer really needed?
Sorry, I had only seen his patches for chromium tree. In mainline
version, he added for 5250 as well. But both sets (for arndale and
smdk) are exactly same as original 5250 configs which also works
with 4412 origen.
Some problem has been identified during conformance testing for
5420 peach board, which happens with analyser. It was always
working fine on the TV sets that I have. @Shirish/Sean please
correct me if wrong.
Shirish patch is only for 5420 Peach board. Else, to start with we can
mark
phyconf as optional property which overrides the default Phy Confs for
given SoC.
Hm you mean that hdmiphy driver use the default phy config data in
driver; most boards use the same data, and only in special case; a board
uses
RE: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
ow...@vger.kernel.org] On Behalf Of Rahul Sharma
Sent: Thursday, September 05, 2013 3:04 PM
To: Inki Dae
Cc: Sean Paul; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
Shirish S
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
On 5 September 2013 10:52, Inki Dae inki@samsung.com wrote:
+static struct hdmiphy_config hdmiphy_4210_configs[] = {
+ {
+ .pixel_clock = 2700,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C,
0x30,
0x40,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2,
0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 27027000,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C,
0x09,
0x64,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2,
0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 74176000,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C,
0xef,
0x5B,
+ 0x6D, 0x10, 0x01, 0x51, 0xef, 0xF3,
0x54,
0xb9,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xa5, 0x26, 0x01, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 7425,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xd8, 0x10, 0x9c,
0xf8,
0x40,
+ 0x6a, 0x10, 0x01, 0x51, 0xff, 0xf1,
0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00, 0x08,
0x10,
0xe0,
+ 0x22, 0x40, 0xa4, 0x26, 0x01, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 14850,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C,
0xf8,
0x40,
+ 0x6A, 0x18, 0x00, 0x51, 0xff, 0xF1,
0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xa4, 0x26, 0x02, 0x00,
0x00,
0x00,
+ },
+ },
+};
+
Are you aware of the effort to move these to dt? Since these
are
board-specific values, it seems incorrect to apply them
universally.
Shirish has uploaded a patch to the chromium review site to
push
these
into dt (https://chromium-review.googlesource.com/#/c/65581).
Maybe
you can work that into your patch set?
Are these really board-specific values?
According to your hardware people:
If the signal pattern doesn't change for new board, the phy setting
is same as the current board. But if changed, you need to confirm
with
measurement of signals, because it may vary slightly by resistance
of
board pattern
Right. it seems that the phy configuration should be adjusted
according
to
PCB environment: OSC clock rate, 24MHz or 27MHz, could be decided by
PCB
even though most PCBs use 27MHz.
That indicates to me that we might need to tweak these on a per-
board
basis.
In the 5420 datasheet, there are a few register descriptions
available
for the phy. 0x145D0004 is CLK_SEL which seems like it would be
board-specific, same with TX_* registers.
And we can select HDMI Tx PHY internal PLL input clock by setting
CLK_SEL.
Ok, Shirish's patch set is reasonable to me. However, that patch set
should
be rebased on top of Rahul's patch set. Shirish and Rahul, please re-
post
your patch set after discussing how to rebase these patch set.
Thanks,
Inki Dae
In that case, we need to test the phy confs for all the exynos boards,
supported in
mainline. Probably needs a analyser as well to precisely compare the
deviation.
Shirish patch adds phy config data only to arndale and smdk5250 boards,
and
these config data should have each board specific values. Therefore, for
other boards, shouldn't correct phy config data suitable to their boards
be
added to their board dts files? Is the above analyzer really needed?
Sorry, I had only seen his patches for chromium tree. In mainline
version, he added for 5250 as well. But both sets (for arndale and
smdk) are exactly
[PATCH] video/drm: Drop superfluous select VT_HW_CONSOLE_BINDING
commit 765d5b9c2b72f5b99722cdfcf4bf8f88c556cf92 (fbdev: fbcon: select VT_HW_CONSOLE_BINDING) made FRAMEBUFFER_CONSOLE always select VT_HW_CONSOLE_BINDING, but forgot to remove select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE from the individual drivers' sections that already did this before. Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org --- drivers/gpu/drm/exynos/Kconfig |1 - drivers/video/Kconfig |1 - 2 files changed, 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig index 772c62a..1344d34 100644 --- a/drivers/gpu/drm/exynos/Kconfig +++ b/drivers/gpu/drm/exynos/Kconfig @@ -5,7 +5,6 @@ config DRM_EXYNOS select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT - select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE help Choose this option if you have a Samsung SoC EXYNOS chipset. If M is selected the module will be called exynosdrm. diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 9788340..f60e3fa 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -2174,7 +2174,6 @@ config FB_PS3 select FB_SYS_COPYAREA select FB_SYS_IMAGEBLIT select FB_SYS_FOPS - select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE ---help--- Include support for the virtual frame buffer in the PS3 platform. -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video/drm: Drop superfluous select VT_HW_CONSOLE_BINDING
Hi On Thu, Sep 5, 2013 at 10:20 AM, Geert Uytterhoeven ge...@linux-m68k.org wrote: commit 765d5b9c2b72f5b99722cdfcf4bf8f88c556cf92 (fbdev: fbcon: select VT_HW_CONSOLE_BINDING) made FRAMEBUFFER_CONSOLE always select VT_HW_CONSOLE_BINDING, but forgot to remove select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE from the individual drivers' sections that already did this before. Yepp, looks good. Maybe we should just drop it entirely. It's 200 lines of code and no additional dependencies. Anyway, nice catch: Reviewed-by: David Herrmann dh.herrm...@gmail.com Thanks David Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org --- drivers/gpu/drm/exynos/Kconfig |1 - drivers/video/Kconfig |1 - 2 files changed, 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig index 772c62a..1344d34 100644 --- a/drivers/gpu/drm/exynos/Kconfig +++ b/drivers/gpu/drm/exynos/Kconfig @@ -5,7 +5,6 @@ config DRM_EXYNOS select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT - select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE help Choose this option if you have a Samsung SoC EXYNOS chipset. If M is selected the module will be called exynosdrm. diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 9788340..f60e3fa 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -2174,7 +2174,6 @@ config FB_PS3 select FB_SYS_COPYAREA select FB_SYS_IMAGEBLIT select FB_SYS_FOPS - select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE ---help--- Include support for the virtual frame buffer in the PS3 platform. -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] video/drm: Drop superfluous select VT_HW_CONSOLE_BINDING
-Original Message- From: Geert Uytterhoeven [mailto:ge...@linux-m68k.org] Sent: Thursday, September 05, 2013 5:21 PM To: David Herrmann; H. Peter Anvin Cc: Inki Dae; David Airlie; Geoff Levand; dri-devel@lists.freedesktop.org; linux-fb...@vger.kernel.org; linux-ker...@vger.kernel.org; Geert Uytterhoeven Subject: [PATCH] video/drm: Drop superfluous select VT_HW_CONSOLE_BINDING commit 765d5b9c2b72f5b99722cdfcf4bf8f88c556cf92 (fbdev: fbcon: select VT_HW_CONSOLE_BINDING) made FRAMEBUFFER_CONSOLE always select VT_HW_CONSOLE_BINDING, but forgot to remove select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE from the individual drivers' sections that already did this before. Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org --- drivers/gpu/drm/exynos/Kconfig |1 - drivers/video/Kconfig |1 - 2 files changed, 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig index 772c62a..1344d34 100644 --- a/drivers/gpu/drm/exynos/Kconfig +++ b/drivers/gpu/drm/exynos/Kconfig @@ -5,7 +5,6 @@ config DRM_EXYNOS select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT - select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE help Choose this option if you have a Samsung SoC EXYNOS chipset. If M is selected the module will be called exynosdrm. diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 9788340..f60e3fa 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -2174,7 +2174,6 @@ config FB_PS3 select FB_SYS_COPYAREA select FB_SYS_IMAGEBLIT select FB_SYS_FOPS - select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE ---help--- Include support for the virtual frame buffer in the PS3 platform. Signed-off-by: Inki Dae inki@samsung.com Thanks, Inki Dae -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60857] New: Unstable display with Radeon 760G (ASUS M4A78L-M LE)
https://bugzilla.kernel.org/show_bug.cgi?id=60857 Bug ID: 60857 Summary: Unstable display with Radeon 760G (ASUS M4A78L-M LE) Product: Drivers Version: 2.5 Kernel Version: 3.11 Hardware: i386 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: smf.li...@ntlworld.com Regression: No Created attachment 107428 -- https://bugzilla.kernel.org/attachment.cgi?id=107428action=edit Screen image, dmesg ,lspci and kernel config I have just upgraded this machine from kernel 3.8.13 to 3.11 and I have discovered that the VGA output has become unstable (see attached). The dmesg output shows a number of issues/warnings which may be associated with the problem but that may just be speculation on my part. Please advise. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linus-next: update to the drm-intel-fixes tree
On Wed, Sep 04, 2013 at 11:05:55AM +0200, Daniel Vetter wrote: Hi Stephen On Wed, Sep 4, 2013 at 1:45 AM, Stephen Rothwell s...@canb.auug.org.au Wrote: This morning after fetching the drm-intel-fixes tree, I have discovered that you have just added a whole set of patches on top of Dave's drm tree and made that the drm-intel-fixes tree. I understood that this tree was for fixes to Linus' tree for the current release cycle. Given that Dave's tree has not been merged by Linus (yet), this is a bit inconsistent. Not only that, but now if I merge your tree early (which is what I do with the -fixes trees), I will also merge all of Dave's tree. That in turn would mean that I would have missed the (what would have been automatically applied) merge for I am carrying for Dave's tree. :-( I am going to have to drop your -fixes tree for today. If these are fixes for stuff in Linus' tree, then they should have been based on Linus' tree - if they are fixes for Dave's tree, then they should have been in your drm-intel tree, right? (fetches more trees ...) And now, I discover that they are the latter :-) So your -fixes tree will be dropped, but all those patches will still be merged via you drm-intel tree. Hm, my workflow is to keep my feature queue branch open even through the merge window. To avoid pains I have the special for-linux-next tree which should only ever point at patches relevent for the current release cycle. Now when the upstream merge window opens I take that patch queue and split out all the features that haven't made it into drm-next in time so that I'm left with only the bugfixes. That I then push to my -fixes branch. Then I rebase my feature queue on top of that. So essentially as soon as the merge window upons my -fixes branch is for the current release and based on top of drm-next. And if there's any leftover fixes I just rebase them, too. While the merge window is open for-linux-next also points at the -fixes branch (but will switch back to the feature queue once -rc1 is out). I guess to make you happy I could create a for-linux-next-fixes branch which would only be used in the -rc phase to include my -fixes into linux-next. I don't want to delay the -fixes split until drm-next is merged upstream since that usually happens rather late in the merge window. Would that work for you? Ok I've implemented this and added a new for-linux-next-fixes branch which should only contain drm/i915 -fixes that apply on top of linus git and nothing from Dave's drm tree. Please yell if this branch contains stuff you don't want to see there. Atm it's just v3.11 since all the stuff on tops of Dave's drm-next is in for-linux-next (and drm-next also isn't yet merged). Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
On Thu, Sep 5, 2013 at 2:19 AM, Inki Dae inki@samsung.com wrote:
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
ow...@vger.kernel.org] On Behalf Of Rahul Sharma
Sent: Thursday, September 05, 2013 3:04 PM
To: Inki Dae
Cc: Sean Paul; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
Shirish S
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
On 5 September 2013 10:52, Inki Dae inki@samsung.com wrote:
+static struct hdmiphy_config hdmiphy_4210_configs[] = {
+ {
+ .pixel_clock = 2700,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C,
0x30,
0x40,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2,
0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 27027000,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C,
0x09,
0x64,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2,
0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 74176000,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C,
0xef,
0x5B,
+ 0x6D, 0x10, 0x01, 0x51, 0xef, 0xF3,
0x54,
0xb9,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xa5, 0x26, 0x01, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 7425,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xd8, 0x10, 0x9c,
0xf8,
0x40,
+ 0x6a, 0x10, 0x01, 0x51, 0xff, 0xf1,
0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00, 0x08,
0x10,
0xe0,
+ 0x22, 0x40, 0xa4, 0x26, 0x01, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 14850,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C,
0xf8,
0x40,
+ 0x6A, 0x18, 0x00, 0x51, 0xff, 0xF1,
0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xa4, 0x26, 0x02, 0x00,
0x00,
0x00,
+ },
+ },
+};
+
Are you aware of the effort to move these to dt? Since these
are
board-specific values, it seems incorrect to apply them
universally.
Shirish has uploaded a patch to the chromium review site to
push
these
into dt (https://chromium-review.googlesource.com/#/c/65581).
Maybe
you can work that into your patch set?
Are these really board-specific values?
According to your hardware people:
If the signal pattern doesn't change for new board, the phy setting
is same as the current board. But if changed, you need to confirm
with
measurement of signals, because it may vary slightly by resistance
of
board pattern
Right. it seems that the phy configuration should be adjusted
according
to
PCB environment: OSC clock rate, 24MHz or 27MHz, could be decided by
PCB
even though most PCBs use 27MHz.
That indicates to me that we might need to tweak these on a per-
board
basis.
In the 5420 datasheet, there are a few register descriptions
available
for the phy. 0x145D0004 is CLK_SEL which seems like it would be
board-specific, same with TX_* registers.
And we can select HDMI Tx PHY internal PLL input clock by setting
CLK_SEL.
Ok, Shirish's patch set is reasonable to me. However, that patch set
should
be rebased on top of Rahul's patch set. Shirish and Rahul, please re-
post
your patch set after discussing how to rebase these patch set.
Thanks,
Inki Dae
In that case, we need to test the phy confs for all the exynos boards,
supported in
mainline. Probably needs a analyser as well to precisely compare the
deviation.
Shirish patch adds phy config data only to arndale and smdk5250 boards,
and
these config data should have each board specific values. Therefore, for
other boards, shouldn't correct phy config data suitable to their boards
be
added to their board dts files? Is the above analyzer really needed?
Sorry, I had only seen his patches for chromium tree. In mainline
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #111 from Eugene ken20...@ukr.net --- (In reply to comment #106) Assuming that works you should have the dmesg.log in the root user directory that you can attach here. Here is my blind result (in attachment). -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #112 from Eugene ken20...@ukr.net --- Created attachment 85253 -- https://bugs.freedesktop.org/attachment.cgi?id=85253action=edit dmesg file Trying to load Radeon driver (for my HD2600XT card) blindly in single user mode - dmesg output. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60857] Unstable display with Radeon 760G (ASUS M4A78L-M LE)
https://bugzilla.kernel.org/show_bug.cgi?id=60857 Alex Deucher alexdeuc...@gmail.com changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher alexdeuc...@gmail.com --- Created attachment 107430 -- https://bugzilla.kernel.org/attachment.cgi?id=107430action=edit possible fix Does the attached patch fix the issue? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Attachment #85253|application/octet-stream|text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Fix kerneldoc of drm_crtc_convert_umode()
From the copy and paste of drm_crtc_convert_to_umode()'s kerneldoc, forgetting to update the symbol name (and they look so similar!). Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- drivers/gpu/drm/drm_crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index e92de2e..81046be 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -1290,7 +1290,7 @@ static void drm_crtc_convert_to_umode(struct drm_mode_modeinfo *out, } /** - * drm_crtc_convert_to_umode - convert a modeinfo into a drm_display_mode + * drm_crtc_convert_umode - convert a modeinfo into a drm_display_mode * @out: drm_display_mode to return to the user * @in: drm_mode_modeinfo to use * -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
-Original Message-
From: Sean Paul [mailto:seanp...@chromium.org]
Sent: Thursday, September 05, 2013 10:20 PM
To: Inki Dae
Cc: Rahul Sharma; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
Shirish S
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
On Thu, Sep 5, 2013 at 2:19 AM, Inki Dae inki@samsung.com wrote:
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-
soc-
ow...@vger.kernel.org] On Behalf Of Rahul Sharma
Sent: Thursday, September 05, 2013 3:04 PM
To: Inki Dae
Cc: Sean Paul; Rahul Sharma; linux-samsung-soc; dri-devel; kgene.kim;
sw0312.kim; Lucas Stach; Tomasz Figa; Sylwester Nawrocki; sunil joshi;
Shirish S
Subject: Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to
hdmiphy
driver
On 5 September 2013 10:52, Inki Dae inki@samsung.com wrote:
+static struct hdmiphy_config hdmiphy_4210_configs[] = {
+ {
+ .pixel_clock = 2700,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C,
0x30,
0x40,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2,
0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 27027000,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD4, 0x10, 0x9C,
0x09,
0x64,
+ 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2,
0x54,
0x87,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xE3, 0x26, 0x00, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 74176000,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C,
0xef,
0x5B,
+ 0x6D, 0x10, 0x01, 0x51, 0xef, 0xF3,
0x54,
0xb9,
+ 0x84, 0x00, 0x30, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xa5, 0x26, 0x01, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 7425,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xd8, 0x10, 0x9c,
0xf8,
0x40,
+ 0x6a, 0x10, 0x01, 0x51, 0xff, 0xf1,
0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00, 0x08,
0x10,
0xe0,
+ 0x22, 0x40, 0xa4, 0x26, 0x01, 0x00,
0x00,
0x00,
+ },
+ },
+ {
+ .pixel_clock = 14850,
+ .conf = {
+ 0x01, 0x05, 0x00, 0xD8, 0x10, 0x9C,
0xf8,
0x40,
+ 0x6A, 0x18, 0x00, 0x51, 0xff, 0xF1,
0x54,
0xba,
+ 0x84, 0x00, 0x10, 0x38, 0x00, 0x08,
0x10,
0xE0,
+ 0x22, 0x40, 0xa4, 0x26, 0x02, 0x00,
0x00,
0x00,
+ },
+ },
+};
+
Are you aware of the effort to move these to dt? Since these
are
board-specific values, it seems incorrect to apply them
universally.
Shirish has uploaded a patch to the chromium review site to
push
these
into dt
(https://chromium-review.googlesource.com/#/c/65581).
Maybe
you can work that into your patch set?
Are these really board-specific values?
According to your hardware people:
If the signal pattern doesn't change for new board, the phy
setting
is same as the current board. But if changed, you need to confirm
with
measurement of signals, because it may vary slightly by
resistance
of
board pattern
Right. it seems that the phy configuration should be adjusted
according
to
PCB environment: OSC clock rate, 24MHz or 27MHz, could be decided
by
PCB
even though most PCBs use 27MHz.
That indicates to me that we might need to tweak these on a per-
board
basis.
In the 5420 datasheet, there are a few register descriptions
available
for the phy. 0x145D0004 is CLK_SEL which seems like it would be
board-specific, same with TX_* registers.
And we can select HDMI Tx PHY internal PLL input clock by setting
CLK_SEL.
Ok, Shirish's patch set is reasonable to me. However, that patch
set
should
be rebased on top of Rahul's patch set. Shirish and Rahul, please
re-
post
your patch set after discussing how to rebase these patch set.
Thanks,
Inki Dae
[Bug 59649] [r600][RV635] GPU lockup CP stall / GPU resets over and over - Kernel 3.7, 3.8-rcX
https://bugs.freedesktop.org/show_bug.cgi?id=59649 --- Comment #7 from Shawn Starr shawn.st...@rogers.com --- Alex found some HW bug issues noted internally see patches: http://lists.x.org/archives/xorg-driver-ati/2013-September/025087.html http://lists.freedesktop.org/archives/mesa-dev/2013-September/044244.html I'm going to try them out -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39156] [r600g] minor glyph corruption seen in Second Life
https://bugs.freedesktop.org/show_bug.cgi?id=39156 Shawn Starr shawn.st...@rogers.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Shawn Starr shawn.st...@rogers.com --- I don't see this anymore, close it -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59721] [r600g] drm_mm_remove_node oops GPU hang while restoring firefox windows
https://bugs.freedesktop.org/show_bug.cgi?id=59721 Shawn Starr shawn.st...@rogers.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Shawn Starr shawn.st...@rogers.com --- Close it, dont see this issue -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59649] [r600][RV635] GPU lockup CP stall / GPU resets over and over - Kernel 3.7 to 3.11 inclusive
https://bugs.freedesktop.org/show_bug.cgi?id=59649 Shawn Starr shawn.st...@rogers.com changed: What|Removed |Added Summary|[r600][RV635] GPU lockup CP |[r600][RV635] GPU lockup CP |stall / GPU resets over and |stall / GPU resets over and |over - Kernel 3.7, 3.8-rcX |over - Kernel 3.7 to 3.11 ||inclusive -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #113 from Alex Deucher ag...@yahoo.com --- Created attachment 85256 -- https://bugs.freedesktop.org/attachment.cgi?id=85256action=edit add callback for UVD Hi Eugene, This patch should fix the crash you are seeing. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68775] RV635 (r600) 600_DEBUG=sb causes GPU reset playing Second Life
https://bugs.freedesktop.org/show_bug.cgi?id=68775 --- Comment #4 from Shawn Starr shawn.st...@rogers.com --- GPU Resets might be related to: https://bugs.freedesktop.org/show_bug.cgi?id=59649 GLSL mis-compilation however is separate issue -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Update: UVD status on loongson 3a platform
Hi all,
This thread is about
http://lists.freedesktop.org/archives/dri-devel/2013-April/037598.html.
We recently find some interesting thing about UVD based playback on
loongson 3a plaform, and also find a way to fix the problem.
First, we find memcpy in [mesa]src/gallium/drivers/radeon/radeon_uvd.c
caused the problem:
* If memcpy is implemented though 16B or 8B load/store instructions,
it will normally caused video mosaic. When insert a memcmp after the
copying code in memcpy, it will report the src and dest are not equal.
* If memcpy use 1B load/store instructions only, the memcmp after the
copying code reports equal.
Then we find the following changeset fixs out problem:
diff --git a/src/gallium/drivers/radeon/radeon_uvd.c
b/src/gallium/drivers/radeon/radeon_uvd.c
index 2f98de2..f9599b6 100644
--- a/src/gallium/drivers/radeon/radeon_uvd.c
+++ b/src/gallium/drivers/radeon/radeon_uvd.c
@@ -162,7 +162,7 @@ static bool create_buffer(struct ruvd_decoder *dec,
unsigned size)
{
buffer-buf = dec-ws-buffer_create(dec-ws, size, 4096, false,
- RADEON_DOMAIN_GTT | RADEON_DOMAIN_VRAM);
+ RADEON_DOMAIN_GTT);
if (!buffer-buf)
return false;
The VRAM is mapped to an uncached area in out platform, so, my
question is what could go wrong while using 4B load/store
instructions in UVD workflow? Any idea?
-- Regards,
Chen Jie
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #114 from Alex Deucher ag...@yahoo.com --- (In reply to comment #107) I'm also having the issue on a 3870/RV670 using Sept4 drm-next (d30645ae from Ubuntu's mainline builds) and previous builds. What sort of issue are you having? blank screen? currupt image? GPU hang? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60857] Unstable display with Radeon 760G (ASUS M4A78L-M LE)
https://bugzilla.kernel.org/show_bug.cgi?id=60857 --- Comment #2 from Stuart Foster smf.li...@ntlworld.com --- (In reply to Alex Deucher from comment #1) Created attachment 107430 [details] possible fix Does the attached patch fix the issue? Sorry Alex the patch made no difference. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60858] [radeon HD 4570m] Error setting UVD clocks
https://bugzilla.kernel.org/show_bug.cgi?id=60858 Christian König christian.koe...@amd.com changed: What|Removed |Added CC||christian.koe...@amd.com --- Comment #1 from Christian König christian.koe...@amd.com --- Does it work when you disable dpm? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60858] [radeon HD 4570m] Error setting UVD clocks
https://bugzilla.kernel.org/show_bug.cgi?id=60858 --- Comment #4 from Christian König christian.koe...@amd.com --- Can you get me a dump of the registers, 0x0718, 0x071c and 0x0720 using radeontool? Something like sudo radeontool regmatch 0x0718 should do it. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60857] Unstable display with Radeon 760G (ASUS M4A78L-M LE)
https://bugzilla.kernel.org/show_bug.cgi?id=60857 --- Comment #4 from Stuart Foster smf.li...@ntlworld.com --- (In reply to Alex Deucher from comment #3) Can you bisect? Also just to be sure, the monitor in qestion is connected to the integrated chip, not the dGPU correct? Does disabling dpm fix the issue? The monitor is connected to the integrated chip on the motherboard (760G [Radeon 3000]) Disabling dpm does fix the problem (radeon.dpm=0 on lilo append line, the patch is still included). dmesg now reports: [drm] radeon: power management initialized as apposed to [drm] radeon: dpm initialized There is no mention of any power mangement on the RV516 [Radeon X1300/X1550 Series] is that correct ? The problem is present in vanilla 3.11-rc1. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
Can you please quote only related part of e-mails when replying ? It discourages to read such discussions when you have to scroll through few pages of garbage before getting to the actual reply text. -- Thanks, Sylwester ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60857] Unstable display with Radeon 760G (ASUS M4A78L-M LE)
https://bugzilla.kernel.org/show_bug.cgi?id=60857 --- Comment #5 from Alex Deucher alexdeuc...@gmail.com --- (In reply to Stuart Foster from comment #4) (In reply to Alex Deucher from comment #3) Can you bisect? Also just to be sure, the monitor in qestion is connected to the integrated chip, not the dGPU correct? Does disabling dpm fix the issue? The monitor is connected to the integrated chip on the motherboard (760G [Radeon 3000]) Disabling dpm does fix the problem (radeon.dpm=0 on lilo append line, the patch is still included). So disabling pdm fixes the issue? It would be nice to know if it's also fixed with dpm disabled and without the patch. dmesg now reports: [drm] radeon: power management initialized as apposed to [drm] radeon: dpm initialized There is no mention of any power mangement on the RV516 [Radeon X1300/X1550 Series] is that correct ? Correct. dpm is only supported on r6xx and newer asics. The problem is present in vanilla 3.11-rc1. You mean 3.12-rc1? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm tree for 3.12-rc1
On Thu, Sep 5, 2013 at 3:41 AM, Dave Airlie airl...@linux.ie wrote: i915: Haswell PC8+ support and eLLC support, HDMI 4K support, initial per-process VMA pieces, watermark reworks, convert to generic hdmi infoframes, encoder reworking, fastboot support, Hmm. The first time I booted this, I just got a black screen on my Haswell desktop when X11 started up. I could ctrl-alt-BS and ctrl-alt-del to reboot the machine, and neither the Xorg.0.log nor the dmesg contained anything interesting. I was about to try to bisect it, but decided to see how repeatable it was, and it didn't happen again. But it also hasn't ever happened before, so I'm a bit worried. This is with the DP cable, which has made my other Haswell issues go away. I'm also a bit bummed that hw acceleration of video doesn't seem to work on Haswell, meaning that full-screen is now a jerky mess. I fear that that is user-space libraries/X.org, but I thought I'd mention it in the hope of getting a oh, it's working for us, you'll get a fix for it soon. Because my shiny new 65W haswell is really nice and does a make allmodconfig in half the time of my old machine, but the GPU side has been something of a step backwards... Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60381] AMD Radeon 7770 Ghz edition Crash with DPM active
https://bugzilla.kernel.org/show_bug.cgi?id=60381 --- Comment #36 from Alex Deucher alexdeuc...@gmail.com --- I guess this bug can be closed now? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm tree for 3.12-rc1
On Thu, 5 Sep 2013 12:18:32 -0700 Linus Torvalds torva...@linux-foundation.org wrote: On Thu, Sep 5, 2013 at 3:41 AM, Dave Airlie airl...@linux.ie wrote: i915: Haswell PC8+ support and eLLC support, HDMI 4K support, initial per-process VMA pieces, watermark reworks, convert to generic hdmi infoframes, encoder reworking, fastboot support, Hmm. The first time I booted this, I just got a black screen on my Haswell desktop when X11 started up. I could ctrl-alt-BS and ctrl-alt-del to reboot the machine, and neither the Xorg.0.log nor the dmesg contained anything interesting. Did the console come back after ctl-alt-bs? Or was it just a blind reboot? Troubling that it doesn't happen again... I was about to try to bisect it, but decided to see how repeatable it was, and it didn't happen again. But it also hasn't ever happened before, so I'm a bit worried. This is with the DP cable, which has made my other Haswell issues go away. I'm also a bit bummed that hw acceleration of video doesn't seem to work on Haswell, meaning that full-screen is now a jerky mess. I fear that that is user-space libraries/X.org, but I thought I'd mention it in the hope of getting a oh, it's working for us, you'll get a fix for it soon. AFAIK we have libva support out there for HSW. The trick is getting your stack to actually use it. Gwenole or Sean may be able to help. Because my shiny new 65W haswell is really nice and does a make allmodconfig in half the time of my old machine, but the GPU side has been something of a step backwards... Well we definitely don't want that... -- Jesse Barnes, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 --- Comment #43 from Nathan Jones crshbn...@gmail.com --- I can reproduce it in Gentoo with 3.11.0, GCC 4.6.3. GPU Temperature is 25C (as reported by lm-sensors) with any UVD accelerated media playing, and cat /sys/kernel/debug/dri/0/radeon_pm_info shows: uvdvclk: 5 dclk: 4 power level 2sclk: 4 mclk: 9 vddc: 950 vddci: 1100 As soon as I stop playing media, it stays at the lower power level, but even scrolling a web page makes it switch to: uvdvclk: 0 dclk: 0 power level 2sclk: 85000 mclk: 12 vddc: 1250 vddci: 1100 And the temperature creeps up to 34C. ASUS EAH5770 CUCore 2DI/1GD5 is the model of my GPU. This only happens with two monitors attached, and I tried the patch in Comment 39, but the behavior did not change. With a single monitor it drops to 157/300, and switches back and forth like it should. For me the problem is not so severe, since even extended GPU load at 100% still doesn't put me over 40C, but it would be nice if it worked with Multimonitor as well as with single.. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm tree for 3.12-rc1
On Fri, Sep 6, 2013 at 5:18 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Thu, Sep 5, 2013 at 3:41 AM, Dave Airlie airl...@linux.ie wrote: i915: Haswell PC8+ support and eLLC support, HDMI 4K support, initial per-process VMA pieces, watermark reworks, convert to generic hdmi infoframes, encoder reworking, fastboot support, Hmm. The first time I booted this, I just got a black screen on my Haswell desktop when X11 started up. I could ctrl-alt-BS and ctrl-alt-del to reboot the machine, and neither the Xorg.0.log nor the dmesg contained anything interesting. I was about to try to bisect it, but decided to see how repeatable it was, and it didn't happen again. But it also hasn't ever happened before, so I'm a bit worried. This is with the DP cable, which has made my other Haswell issues go away. I'm also a bit bummed that hw acceleration of video doesn't seem to work on Haswell, meaning that full-screen is now a jerky mess. I fear that that is user-space libraries/X.org, but I thought I'd mention it in the hope of getting a oh, it's working for us, you'll get a fix for it soon. Because my shiny new 65W haswell is really nice and does a make allmodconfig in half the time of my old machine, but the GPU side has been something of a step backwards... Welcome to new Intel HW :-P So did you reboot into the new kernel from the old, maybe try reproducing but booting an old kernel and booting into the new one from it, it might be some hw state getting left set across soft reset or something, I'm hoping Intel guys pipe up on the other HSW issues, I only have one HSW laptop with an eDP panel and no external outputs on the Intel GPU. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm tree for 3.12-rc1
On Thu, Sep 5, 2013 at 3:51 PM, Linus Torvalds torva...@linux-foundation.org wrote: I've booted a few times since (it's the merge window, so I boot fairly frequently), and it hasn't happened again... .. and of course, after I say that, on the very next boot it then happened three times in a row until it magically didn't happen. So I've decided I'm going to try to bisect this after all. I've done enough pulls for today anyway, I guess. Let's see if I can bisect it by just trying to boot many times each try. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60857] Unstable display with Radeon 760G (ASUS M4A78L-M LE)
https://bugzilla.kernel.org/show_bug.cgi?id=60857 --- Comment #6 from Stuart Foster smf.li...@ntlworld.com --- (In reply to Alex Deucher from comment #5) (In reply to Stuart Foster from comment #4) (In reply to Alex Deucher from comment #3) Can you bisect? Also just to be sure, the monitor in qestion is connected to the integrated chip, not the dGPU correct? Does disabling dpm fix the issue? The monitor is connected to the integrated chip on the motherboard (760G [Radeon 3000]) Disabling dpm does fix the problem (radeon.dpm=0 on lilo append line, the patch is still included). So disabling pdm fixes the issue? It would be nice to know if it's also fixed with dpm disabled and without the patch. dmesg now reports: [drm] radeon: power management initialized as apposed to [drm] radeon: dpm initialized There is no mention of any power mangement on the RV516 [Radeon X1300/X1550 Series] is that correct ? Correct. dpm is only supported on r6xx and newer asics. The problem is present in vanilla 3.11-rc1. You mean 3.12-rc1? No having found that turning dpm off fixed the problem I went back to the first 3.11-rc which introduced the radeon dpm code. The problem is fixed with the patch removed and with dpm turn off. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #118 from Alex Deucher ag...@yahoo.com --- (In reply to comment #117) Will it be in 3.11.1 or 3.12 next Monday ? Not likely. I haven't sent the patch upstream yet. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60381] AMD Radeon 7770 Ghz edition Crash with DPM active
https://bugzilla.kernel.org/show_bug.cgi?id=60381 --- Comment #37 from rafael castillo jrch2...@gmail.com --- i guess yes, the only issue i find after this, is that KMS hang if you compile the kernel with radeon kms with Y instead of M i can't findout why since is too early to see anything -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60858] [radeon HD 4570m] Error setting UVD clocks
https://bugzilla.kernel.org/show_bug.cgi?id=60858 --- Comment #6 from Christian König christian.koe...@amd.com --- (In reply to Pinak Ahuja from comment #5) # radeontool regmatch 0x071c 0x071c 0x021f (35586048) Well, that's no wonder those parameters doesn't work. Either you have a buggy BIOS or our clock calculation code has a bug, anyway I'm going to test that tomorrow with my RV710. Anyway thanks for the info. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60858] New: [radeon HD 4570m] Error setting UVD clocks
https://bugzilla.kernel.org/show_bug.cgi?id=60858 Bug ID: 60858 Summary: [radeon HD 4570m] Error setting UVD clocks Product: Drivers Version: 2.5 Kernel Version: 3.11 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: pinak.ah...@gmail.com Regression: No Created attachment 107431 -- https://bugzilla.kernel.org/attachment.cgi?id=107431action=edit generated using $dmesg dmesg.txt I'm using the dell studio 1555 laptop with radeon HD 4570m graphic card. Running the stable 3.11 kernel with the latest linux-firmware files. I am not able to play any video using VDPAU regardless of the codec. During boot up there are a few errors regarding setting UVD clocks [8.936898] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks! [9.983683] [drm:radeon_uvd_send_upll_ctlreq] *ERROR* Timeout setting UVD clocks! [9.983695] [drm:r600_uvd_ib_test] *ERROR* radeon: failed to raise UVD clocks (-110). I've attached the full dmesg. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Update: UVD status on loongson 3a platform
On Thu, Sep 05, 2013 at 10:14:32PM +0800, Chen Jie wrote:
Hi all,
This thread is about
http://lists.freedesktop.org/archives/dri-devel/2013-April/037598.html.
We recently find some interesting thing about UVD based playback on
loongson 3a plaform, and also find a way to fix the problem.
First, we find memcpy in [mesa]src/gallium/drivers/radeon/radeon_uvd.c
caused the problem:
* If memcpy is implemented though 16B or 8B load/store instructions,
it will normally caused video mosaic. When insert a memcmp after the
copying code in memcpy, it will report the src and dest are not equal.
* If memcpy use 1B load/store instructions only, the memcmp after the
copying code reports equal.
Then we find the following changeset fixs out problem:
diff --git a/src/gallium/drivers/radeon/radeon_uvd.c
b/src/gallium/drivers/radeon/radeon_uvd.c
index 2f98de2..f9599b6 100644
--- a/src/gallium/drivers/radeon/radeon_uvd.c
+++ b/src/gallium/drivers/radeon/radeon_uvd.c
@@ -162,7 +162,7 @@ static bool create_buffer(struct ruvd_decoder *dec,
unsigned size)
{
buffer-buf = dec-ws-buffer_create(dec-ws, size, 4096, false,
- RADEON_DOMAIN_GTT | RADEON_DOMAIN_VRAM);
+ RADEON_DOMAIN_GTT);
if (!buffer-buf)
return false;
The VRAM is mapped to an uncached area in out platform, so, my
question is what could go wrong while using 4B load/store
instructions in UVD workflow? Any idea?
How do you map the VRAM into user process mapping ? ie do you have
something like Intel PAT or something like MTRR or something else.
In other word, can you map into process address space a region of
io memory (GPU VRAM in this case) and mark it as uncached so that
none of the access to it goes through CPU cache.
Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60858] [radeon HD 4570m] Error setting UVD clocks
https://bugzilla.kernel.org/show_bug.cgi?id=60858 --- Comment #5 from Pinak pinak.ah...@gmail.com --- Here are the dumps of the required registers # radeontool regmatch 0x0718 0x0718 0x20010004 (536936452) # radeontool regmatch 0x071c 0x071c 0x021f (35586048) # radeontool regmatch 0x0720 0x0720 0x10050001 (268763137) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60858] [radeon HD 4570m] Error setting UVD clocks
https://bugzilla.kernel.org/show_bug.cgi?id=60858 --- Comment #3 from Christian König christian.koe...@amd.com --- No, not necessary. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #116 from Alex Deucher ag...@yahoo.com --- (In reply to comment #115) (In reply to comment #114) What sort of issue are you having? blank screen? currupt image? GPU hang? Screen goes to powersave when booted with dpm=1. Still able to ssh in, but seems frozen from keyboard. Does disabling any of the dpm features as per comment 94 help? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #117 from Eugene ken20...@ukr.net --- (In reply to comment #113) Created attachment 85256 [details] [review] add callback for UVD Hi Eugene, This patch should fix the crash you are seeing. Will it be in 3.11.1 or 3.12 next Monday ? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #119 from Eugene ken20...@ukr.net --- Then 3.11.2 ? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60858] [radeon HD 4570m] Error setting UVD clocks
https://bugzilla.kernel.org/show_bug.cgi?id=60858 --- Comment #2 from Pinak pinak.ah...@gmail.com --- (In reply to Christian König from comment #1) Does it work when you disable dpm? No, even with DPM disabled it doesn't work. Do you want a dmesg with DPM disabled? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Update: UVD status on loongson 3a platform
On Thu, Sep 05, 2013 at 03:29:52PM -0400, Jerome Glisse wrote:
On Thu, Sep 05, 2013 at 10:14:32PM +0800, Chen Jie wrote:
Hi all,
This thread is about
http://lists.freedesktop.org/archives/dri-devel/2013-April/037598.html.
We recently find some interesting thing about UVD based playback on
loongson 3a plaform, and also find a way to fix the problem.
First, we find memcpy in [mesa]src/gallium/drivers/radeon/radeon_uvd.c
caused the problem:
* If memcpy is implemented though 16B or 8B load/store instructions,
it will normally caused video mosaic. When insert a memcmp after the
copying code in memcpy, it will report the src and dest are not equal.
* If memcpy use 1B load/store instructions only, the memcmp after the
copying code reports equal.
Then we find the following changeset fixs out problem:
diff --git a/src/gallium/drivers/radeon/radeon_uvd.c
b/src/gallium/drivers/radeon/radeon_uvd.c
index 2f98de2..f9599b6 100644
--- a/src/gallium/drivers/radeon/radeon_uvd.c
+++ b/src/gallium/drivers/radeon/radeon_uvd.c
@@ -162,7 +162,7 @@ static bool create_buffer(struct ruvd_decoder *dec,
unsigned size)
{
buffer-buf = dec-ws-buffer_create(dec-ws, size, 4096, false,
- RADEON_DOMAIN_GTT | RADEON_DOMAIN_VRAM);
+ RADEON_DOMAIN_GTT);
if (!buffer-buf)
return false;
The VRAM is mapped to an uncached area in out platform, so, my
question is what could go wrong while using 4B load/store
instructions in UVD workflow? Any idea?
How do you map the VRAM into user process mapping ? ie do you have
something like Intel PAT or something like MTRR or something else.
In other word, can you map into process address space a region of
io memory (GPU VRAM in this case) and mark it as uncached so that
none of the access to it goes through CPU cache.
Cheers,
Jerome
Also it might be that you can't do write combining on your platform,
which would be a major drawback as it's assume by radeon userspace.
I would need to check the pcie specification, but write combining is
probably not mandatory meaning that your architecture might not have
it. This would explain why only memset with byte size copy works.
Don't think there is any easy way to work around that.
Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 66963] r600: linux v3.11.0-RC isn't booting with radeon.dpm=1 option in grub
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #115 from Bryan Quigley gquigs+b...@gmail.com --- (In reply to comment #114) What sort of issue are you having? blank screen? currupt image? GPU hang? Screen goes to powersave when booted with dpm=1. Still able to ssh in, but seems frozen from keyboard. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm tree for 3.12-rc1
On Thu, Sep 5, 2013 at 3:32 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Thu, 5 Sep 2013 12:18:32 -0700 The first time I booted this, I just got a black screen on my Haswell desktop when X11 started up. I could ctrl-alt-BS and ctrl-alt-del to reboot the machine, and neither the Xorg.0.log nor the dmesg contained anything interesting. Did the console come back after ctl-alt-bs? Or was it just a blind reboot? Troubling that it doesn't happen again... Blind reboot. And Dave's theory that it is a boot from old kernel to show the problem in case it's some missing hw setup is a good one, but doesn't match my experience: I did boot the old kernel in between (to see what went wrong), so both the working and nonworking setups were from warm-booting from an old kernel.. I've booted a few times since (it's the merge window, so I boot fairly frequently), and it hasn't happened again... Looking more closely at the log-file, I notice that the AFAIK we have libva support out there for HSW. The trick is getting your stack to actually use it. Gwenole or Sean may be able to help. Because my shiny new 65W haswell is really nice and does a make allmodconfig in half the time of my old machine, but the GPU side has been something of a step backwards... Well we definitely don't want that... There's another thing I've noticed with Haswell - while putting the screen to sleep works fine with DP, it comes back with odd corruption. Pressing enter to get the actual password prompt correctly repaints things, so it's not always noticeable - but using something else than the enter key to wake things up seems to show it consistently (also happens with xset dpms force off, you don't have to wait for locking) Of course, this may be old user-land, again. It's current F19, the intel module says compiled for 1.14.2, module version = 2.21.12. Maybe the problem I had with HDMI/DVI was just a different expression of this same bug. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60381] AMD Radeon 7770 Ghz edition Crash with DPM active
https://bugzilla.kernel.org/show_bug.cgi?id=60381 --- Comment #38 from Alex Deucher alexdeuc...@gmail.com --- (In reply to rafael castillo from comment #37) i guess yes, the only issue i find after this, is that KMS hang if you compile the kernel with radeon kms with Y instead of M i can't findout why since is too early to see anything If you build the driver into the kernel, you also need to build the ucode into the kernel. I suspect the hang it due to missing ucode in the kernel image. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm tree for 3.12-rc1
On Thu, Sep 5, 2013 at 3:51 PM, Linus Torvalds torva...@linux-foundation.org wrote: Looking more closely at the log-file, I notice that the oops, pressed the send-button a bit too early.. Anyway, looking more closely at the log-file, I notice that while it has zero errors, it does seem to end just where a successful log-file has the EDID information (for the second time). But that may be normal and not indicate anything wrong with EDID at all - looking at the timestamps that second EDID probe may happen when you log in, and I obviously never logged in due to being all blind. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Move nv30, nv50 and nvc0 to nouveau.
--- Sorry for annoying the mailing list but ... irc_dri-devel [Dienstag, 20. August 2013] [21:23:56] jobermayr calim: Would you accept such a patch: https://github.com/jobermayr/mesa/commit/b859d1d [Dienstag, 20. August 2013] [21:56:05] calim jobermayr: what's that good for ? [Dienstag, 20. August 2013] [21:56:33] calim ah, you moved everything into a nouveau subdir [Dienstag, 20. August 2013] [21:59:42] calim hm, I don't care, doesn't really have an effect other than requiring more key presses to reach the driver dir key_statement [Dienstag, 20. August 2013] [21:59:58] calim so, I'd accept it /key_statement [Dienstag, 20. August 2013] [22:01:00] calim but you remove the ability to not build nv30 support ... [Dienstag, 20. August 2013] [22:02:45] calim I mean, you could have kept the separate libnvXX.a note_from_today Depending targets (dri-nouveau, egl-static, pipe-loader, vdpau-nouveau, xorg-nouveau and xmvc-nouveau) require nv30_screen_create, nv50_screen_create and nvc0_screen_create in nouveau_drm_screen_create (libnouveaudrm.la). So it is not possible not to build nv30 and since all three former libnvXX.la are required it makes sense to build only one libnouveau.la ... /note_from_today [Dienstag, 20. August 2013] [22:38:05] jobermayr calim: It only builds one libnouveau library, a bit faster compile times on -jX and all things which go into it are better structured /irc_dri-devel email_in_german Am Dienstag, 20. August 2013, 23:27:59 schrieb Johannes Obermayr an Christoph Bumiller: Hallo Christoph, anbei der Patch zur Umstrukturierung (entpackt ~ 4 MB, deshalb nicht an die Liste ...). Falls mal aboll's und mein Wunsch in Erfüllung gehen sollte und wir die Shared-Libs-Patches einspielen dürfen, müssen dann in libnouveau.so nur die drei *_screen_create Symbole freigegeben werden. Wie vorhin auf der Liste angekündigt gibt es einen kleinen Geschwindigkeitsbonus beim Kompilieren obendrein Gruß Johannes /email_in_german irc_dri-devel [Sonntag, 1. September 2013] [23:23:37] jobermayr calim: This commit also contains whiteline and new blank line at EOF fixes: https://github.com/jobermayr/mesa/commit/5a677fc . Is it sth. you will push to master or must I maintain it in my branch? [Donnerstag, 5. September 2013] [17:56:33] jobermayr_ calim: What about pushing https://github.com/jobermayr/mesa/commit/def1781 and for 9.2: https://github.com/jobermayr/mesa/commit/03073db ? Don't you accept it anymore? /irc_dri-devel general_question Why is it so difficult to get an agreed patch in master? /general_question --- configure.ac |5 +- src/gallium/Android.mk |5 +- src/gallium/drivers/Makefile.am|2 +- src/gallium/drivers/nouveau/Android.mk |8 +- src/gallium/drivers/nouveau/Makefile.am| 14 +- src/gallium/drivers/nouveau/Makefile.sources | 91 + src/gallium/drivers/nouveau/codegen/nv50_ir.cpp| 1231 src/gallium/drivers/nouveau/codegen/nv50_ir.h | 1197 src/gallium/drivers/nouveau/codegen/nv50_ir_bb.cpp | 550 .../drivers/nouveau/codegen/nv50_ir_build_util.cpp | 614 .../drivers/nouveau/codegen/nv50_ir_build_util.h | 324 +++ .../drivers/nouveau/codegen/nv50_ir_driver.h | 220 ++ .../drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 1682 +++ .../drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp | 1962 + .../drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 2988 .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 2852 +++ .../drivers/nouveau/codegen/nv50_ir_graph.cpp | 436 +++ .../drivers/nouveau/codegen/nv50_ir_graph.h| 228 ++ .../drivers/nouveau/codegen/nv50_ir_inlines.h | 420 +++ .../nouveau/codegen/nv50_ir_lowering_nv50.cpp | 1101 .../nouveau/codegen/nv50_ir_lowering_nvc0.cpp | 1597 +++ .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 2464 .../drivers/nouveau/codegen/nv50_ir_print.cpp | 698 + src/gallium/drivers/nouveau/codegen/nv50_ir_ra.cpp | 2050 ++ .../drivers/nouveau/codegen/nv50_ir_ssa.cpp| 552 .../drivers/nouveau/codegen/nv50_ir_target.cpp | 469 +++ .../drivers/nouveau/codegen/nv50_ir_target.h | 235 ++ .../nouveau/codegen/nv50_ir_target_nv50.cpp| 552 .../drivers/nouveau/codegen/nv50_ir_target_nv50.h | 72 + .../nouveau/codegen/nv50_ir_target_nvc0.cpp| 604 .../drivers/nouveau/codegen/nv50_ir_target_nvc0.h | 74 + .../drivers/nouveau/codegen/nv50_ir_util.cpp | 390 +++ src/gallium/drivers/nouveau/codegen/nv50_ir_util.h | 788 ++ .../drivers/nouveau/codegen/target_lib_nvc0.asm| 96 + .../drivers/nouveau/codegen/target_lib_nvc0.asm.h | 112 + .../drivers/nouveau/codegen/target_lib_nve4.asm| 698 +
Discussion starters for ION session at Linux Plumbers Android+Graphics microconf
Hey everyone, In preparation for the Plumbers Android+Graphics microconf, I wanted to send out some background documentation to try to get all the context we can out there prior to the discussion, as time will be limited and it would be best to spend it discussing solutions rather then re-hashing problems and requirements. I'm sure many folks on this list could probably do a better job summarizing the issues, but I wanted to get this out there to try to enumerate the problems and the different perspectives on the issues that I'm aware of. The document is on LWN here: http://lwn.net/SubscriberLink/565469/9d88daa2282ef6c2/ But I wanted to start a discussion thread here, since the LWN comment threads (while *much* better then most comment sections) aren't really the right place for this sort of thing. So please feel free to reply to correct any inaccuracies in my summary, provide your thoughts on the various proposed solutions, or suggest new solutions that we should also discuss at the micro-conference! thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm tree for 3.12-rc1
On Thu, Sep 5, 2013 at 4:19 PM, Linus Torvalds torva...@linux-foundation.org wrote: So I've decided I'm going to try to bisect this after all. I've done enough pulls for today anyway, I guess. Let's see if I can bisect it by just trying to boot many times each try. Ok, it's not the recent drm pull at all. I can't find a good kernel in the bunch - they all fail eventually. It may have been going in for as long as I've had this Haswell machine, and I was just lucky (and not rebooting a lot until in the merge window - and 4/5 boots work fine). It may also be user-space and have come in with the mesa update I got through yum yesterday. So there might be multiple reasons why I saw it today after the drm pull for the first time. The black screen - when it happens - happens after the fedora logo has flashed, and gdm is supposed to start up. I tried reproducing it by logging out and back in again (to restart X), but that doesn't do it. Maybe timing-related with boot or just demand-loading of binaries the first time, whatever.. Or mayby it's something special that gdm does at startup? Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60381] AMD Radeon 7770 Ghz edition Crash with DPM active
https://bugzilla.kernel.org/show_bug.cgi?id=60381 --- Comment #39 from rafael castillo jrch2...@gmail.com --- yeap make sense, i thought i did but is very probable im missing a step or two in the process, i tried just cuz i wanted to see if KMS could start earlier in the boot process since my PC with systemd but too fast and i can't even see kmscon kicking in because once the module load kdm is there. anyway as this bug is concerned all is peachy and since im using drm-3.12-next it got even better in some spots. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60381] AMD Radeon 7770 Ghz edition Crash with DPM active
https://bugzilla.kernel.org/show_bug.cgi?id=60381 rafael castillo jrch2...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60381] AMD Radeon 7770 Ghz edition Crash with DPM active
https://bugzilla.kernel.org/show_bug.cgi?id=60381 --- Comment #40 from rafael castillo jrch2...@gmail.com --- many thanks for your time and some nice piece of awesome work -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Update: UVD status on loongson 3a platform
2013/9/6 Jerome Glisse j.gli...@gmail.com:
On Thu, Sep 05, 2013 at 03:29:52PM -0400, Jerome Glisse wrote:
On Thu, Sep 05, 2013 at 10:14:32PM +0800, Chen Jie wrote:
Hi all,
This thread is about
http://lists.freedesktop.org/archives/dri-devel/2013-April/037598.html.
We recently find some interesting thing about UVD based playback on
loongson 3a plaform, and also find a way to fix the problem.
First, we find memcpy in [mesa]src/gallium/drivers/radeon/radeon_uvd.c
caused the problem:
* If memcpy is implemented though 16B or 8B load/store instructions,
it will normally caused video mosaic. When insert a memcmp after the
copying code in memcpy, it will report the src and dest are not equal.
* If memcpy use 1B load/store instructions only, the memcmp after the
copying code reports equal.
Then we find the following changeset fixs out problem:
diff --git a/src/gallium/drivers/radeon/radeon_uvd.c
b/src/gallium/drivers/radeon/radeon_uvd.c
index 2f98de2..f9599b6 100644
--- a/src/gallium/drivers/radeon/radeon_uvd.c
+++ b/src/gallium/drivers/radeon/radeon_uvd.c
@@ -162,7 +162,7 @@ static bool create_buffer(struct ruvd_decoder *dec,
unsigned size)
{
buffer-buf = dec-ws-buffer_create(dec-ws, size, 4096, false,
- RADEON_DOMAIN_GTT | RADEON_DOMAIN_VRAM);
+ RADEON_DOMAIN_GTT);
if (!buffer-buf)
return false;
The VRAM is mapped to an uncached area in out platform, so, my
question is what could go wrong while using 4B load/store
instructions in UVD workflow? Any idea?
How do you map the VRAM into user process mapping ? ie do you have
something like Intel PAT or something like MTRR or something else.
In other word, can you map into process address space a region of
io memory (GPU VRAM in this case) and mark it as uncached so that
none of the access to it goes through CPU cache.
Cheers,
Jerome
Also it might be that you can't do write combining on your platform,
which would be a major drawback as it's assume by radeon userspace.
I would need to check the pcie specification, but write combining is
probably not mandatory meaning that your architecture might not have
it. This would explain why only memset with byte size copy works.
Don't think there is any easy way to work around that.
The original mesa code allows to allocate buffer in GTT and VRAM
domain. And we change it so that all buffers are allocated in GTT
domain, it seems fix our problem.
--
Regards,
- cee1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Update: UVD status on loongson 3a platform
2013/9/6 Jerome Glisse j.gli...@gmail.com:
On Thu, Sep 05, 2013 at 10:14:32PM +0800, Chen Jie wrote:
Hi all,
This thread is about
http://lists.freedesktop.org/archives/dri-devel/2013-April/037598.html.
We recently find some interesting thing about UVD based playback on
loongson 3a plaform, and also find a way to fix the problem.
First, we find memcpy in [mesa]src/gallium/drivers/radeon/radeon_uvd.c
caused the problem:
* If memcpy is implemented though 16B or 8B load/store instructions,
it will normally caused video mosaic. When insert a memcmp after the
copying code in memcpy, it will report the src and dest are not equal.
* If memcpy use 1B load/store instructions only, the memcmp after the
copying code reports equal.
Then we find the following changeset fixs out problem:
diff --git a/src/gallium/drivers/radeon/radeon_uvd.c
b/src/gallium/drivers/radeon/radeon_uvd.c
index 2f98de2..f9599b6 100644
--- a/src/gallium/drivers/radeon/radeon_uvd.c
+++ b/src/gallium/drivers/radeon/radeon_uvd.c
@@ -162,7 +162,7 @@ static bool create_buffer(struct ruvd_decoder *dec,
unsigned size)
{
buffer-buf = dec-ws-buffer_create(dec-ws, size, 4096, false,
- RADEON_DOMAIN_GTT | RADEON_DOMAIN_VRAM);
+ RADEON_DOMAIN_GTT);
if (!buffer-buf)
return false;
The VRAM is mapped to an uncached area in out platform, so, my
question is what could go wrong while using 4B load/store
instructions in UVD workflow? Any idea?
How do you map the VRAM into user process mapping ? ie do you have
something like Intel PAT or something like MTRR or something else.
In other word, can you map into process address space a region of
io memory (GPU VRAM in this case) and mark it as uncached so that
none of the access to it goes through CPU cache.
Yes, of course.
On mips, there's a specific range of address space that is used to
access IO memory directly, and the address of VRAM BOs is just in this
range.
--
Regards,
- cee1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
