Re: [PATCH/RFC v3 08/19] video: display: Add MIPI DBI bus support
Hi Laurent,
On 9 August 2013 22:44, Laurent Pinchart
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
> ---
> 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
> + *
> + * 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
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +/*
> -
> + * 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 mipi_dbi_uevent(struct device *_dev, struct kobj_uevent_env *env)
>
Re: [PATCH/RFC v3 08/19] video: display: Add MIPI DBI bus support
Hi Laurent,
On 9 August 2013 22:44, Laurent Pinchart
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
> ---
> 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
> + *
> + * 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
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +/*
> -
> + * 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);
> +
> +/*
> -
> + * Bus type
> + */
> +
> +static const struct mipi_dbi_device_id *
> +mipi_dbi_match_id(const struct mipi_db
[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
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 --- Created attachment 85216 --> https://bugs.freedesktop.org/attachment.cgi?id=85216&action=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 --- Created attachment 85217 --> https://bugs.freedesktop.org/attachment.cgi?id=85217&action=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 --- Created attachment 85218 --> https://bugs.freedesktop.org/attachment.cgi?id=85218&action=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 --- 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 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 wrote:
> >> > A few comments.
> >> >
> >> > On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma
>
> >> 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
> >> >> ---
> >> >> .../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
> >> >> #include
> >> >> #include
> >> >> +#include
> >> >> +#include
> >> >>
> >> >> #include
> >> >>
> >> >> @@ -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
Re: [PATCH 1/7] drm/exynos: move hdmiphy related code to hdmiphy driver
On 5 September 2013 09:46, Inki Dae 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 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 wrote:
>> >> > A few comments.
>> >> >
>> >> > On Fri, Aug 30, 2013 at 2:59 AM, Rahul Sharma
>>
>> >> 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
>> >> >> ---
>> >> >> .../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
>> >> >> #include
>> >> >> #include
>> >> >> +#include
>> >> >> +#include
>> >> >>
>> >> >> #include
>> >> >>
>> >> >> @@ -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 {
>> >> >>
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
[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 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 arn
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 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
[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
---
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
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
Thanks
David
> Signed-off-by: Geert Uytterhoeven
> ---
> 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
> ---
> 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
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=107428&action=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 > 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 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 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 se
[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 --- (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 --- Created attachment 85253 --> https://bugs.freedesktop.org/attachment.cgi?id=85253&action=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 changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher --- Created attachment 107430 --> https://bugzilla.kernel.org/attachment.cgi?id=107430&action=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 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 --- 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 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 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 p
[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 --- 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 changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Shawn Starr --- 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 changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Shawn Starr --- 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 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 --- Created attachment 85256 --> https://bugs.freedesktop.org/attachment.cgi?id=85256&action=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 --- 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
Re: [PATCH] drm: Fix kerneldoc of drm_crtc_convert_umode()
On Thu, Sep 05, 2013 at 02:40:44PM +0100, Damien Lespiau wrote: > >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 Reviewed-by: Ville Syrjälä Although maybe renaming to drm_crtc_convert_from_umode() might make the difference easier to spot. But it's only used in one place only so it's not a big deal. > --- > 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 -- Ville Syrjälä Intel OTC ___ 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 #3 from Alex Deucher --- 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? -- 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
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 --- (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 --- (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 changed: What|Removed |Added CC||christian.koe...@amd.com --- Comment #1 from Christian König --- 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 --- 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 --- (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 --- (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 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 --- 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 wrote: > On Thu, Sep 5, 2013 at 3:41 AM, Dave Airlie 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 --- 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 wrote: > On Thu, Sep 5, 2013 at 3:41 AM, Dave Airlie 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 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 --- (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 --- (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 --- 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 --- (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=107431&action=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 --- 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 --- 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 --- (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 --- (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 --- 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 --- (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 --- (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 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 --- (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 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 ... [Dienstag, 20. August 2013] [21:23:56] calim: Would you accept such a patch: https://github.com/jobermayr/mesa/commit/b859d1d [Dienstag, 20. August 2013] [21:56:05] jobermayr: what's that good for ? [Dienstag, 20. August 2013] [21:56:33] ah, you moved everything into a nouveau subdir [Dienstag, 20. August 2013] [21:59:42] hm, I don't care, doesn't really have an effect other than requiring more key presses to reach the driver dir [Dienstag, 20. August 2013] [21:59:58] so, I'd accept it [Dienstag, 20. August 2013] [22:01:00] but you remove the ability to not build nv30 support ... [Dienstag, 20. August 2013] [22:02:45] I mean, you could have kept the separate libnvXX.a 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 ... [Dienstag, 20. August 2013] [22:38:05] calim: It only builds one libnouveau library, a bit faster compile times on -jX and all things which go into it are better structured 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 [Sonntag, 1. September 2013] [23:23:37] 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] 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? Why is it so difficult to get an agreed patch in master? --- 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 + .../drivers/nouveau/codegen/target_lib_nve4.asm.h | 592 .../drivers/nouveau/codegen/target_lib_nvf0.asm.h | 13 + src/gallium/drivers/nouveau/nouveau_mm.c |1 - src/gallium/drivers/nouveau/nouveau_screen.c |4 +- src
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 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 --- 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 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 --- 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 :
> 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 :
> 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
[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)
