Re: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy driver
On 2 September 2013 10:38, Inki Dae inki@samsung.com wrote:
Hi Rahul,
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc-
ow...@vger.kernel.org] On Behalf Of Rahul Sharma
Sent: Friday, August 30, 2013 7:06 PM
To: Inki Dae
Cc: Rahul Sharma; linux-samsung-soc; dri-devel@lists.freedesktop.org;
Kukjin Kim; sw0312.kim; Sean Paul; Lucas Stach; Tomasz Figa; Sylwester
Nawrocki; sunil joshi
Subject: Re: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
Thanks Mr. Dae,
I have some points for discussion.
On 30 August 2013 14:03, Inki Dae inki@samsung.com wrote:
Hi Rahul.
Thanks for your patch set.
I had just quick review to all patch series. And I think we could fully
hide
hdmiphy interfaces,
exynos_hdmiphy_enable/disable/check_mode/set_mode/conf_apply, from hdmi
driver.
That may be prototyped like below,
at exynos_hdmi.h
/* Define hdmiphy callbacks. */
struct exynos_hdmiphy_ops {
void (*enable)(struct device *dev);
void (*disable)(struct device *dev);
int (*check_mode)(struct device *dev, struct drm_display_mode
*mode);
int (*set_mode)(struct device *dev, struct drm_display_mode
*mode);
int (*apply)(struct device *dev);
};
Above looks fine to me. I will hide the ops as you suggested.
at exynos_hdmi.c
/*
* Add a new structure for hdmi driver data.
* type could be HDMI_TYPE13 or HDMI_TYPE14.
* i2c_hdmiphy could be true or false: true means that current hdmi
device
uses i2c
* based hdmiphy device, otherwise platform device based one.
*/
struct hdmi_drv_data {
unsigned int type;
unsigned int i2c_hdmiphy;
};
...
/* Add new members to hdmi context. */
struct hdmi_context {
...
struct hdmi_drv_data *drv_data;
struct hdmiphy_ops *ops;
...
};
/* Add hdmi device data according Exynos SoC. */
static struct hdmi_drv_data exynos4212_hdmi_drv_data = {
.type = HDMI_TYPE14,
.i2c_hdmiphy = true
};
static struct hdmi_drv_data exynos5420_hdmi_drv_data = {
.type = HDMI_TYPE14,
.i2c_hdmiphy = false
};
static struct of_device_id hdmi_match_types[] = {
{
.compatible = samsung,exynos4212-hdmi,
.data = (void *)exynos4212_hdmi_drv_data,
}, {
...
.compatible = samsung,exynos5420-hdmi,
.data = (void *)exynos5420_hdmi_drv_data,
}, {
}
};
/* the below example function shows how hdmiphy interfaces can be hided
from
hdmi driver. */
static void hdmi_mode_set(...)
{
...
hdata-ops-set_mode(hdata-hdmiphy_dev, mode);
This looks fine.
}
static int hdmi_get_phy_device(struct hdmi_context *hdata)
{
struct hdmi_drv_data *data = hdata-drv_data;
...
/* Register hdmiphy driver according to i2c_hdmiphy value. */
ret = exynos_hdmiphy_driver_register(data-i2c_hdmiphy);
...
/* Get hdmiphy driver ops according to i2c_hdmiphy value. */
hdata-ops = exynos_hdmiphy_get_ops(data-i2c_hdmiphy);
...
}
at exynos_hdmiphy.c
/* Define hdmiphy ops respectively. */
struct exynos_hdmiphy_ops hdmiphy_i2c_ops = {
.enable = exynos_hdmiphy_i2c_enable,
.disable = exynos_hdmiphy_i2c_disable,
...
};
struct exynos_hdmiphy_ops hdmiphy_platdev_ops = {
.enable = exynos_hdmiphy_platdev_enable,
.disable = exynos_hdmiphy_platdev_disable,
...
};
Actually, Ops for Hdmiphy I2c and platform devices are exactly
same. We don't need 2 sets. Only difference is in static function to
write configuration values to phy. Based on i2c_verify_client(hdata-dev),
we use i2c_master_send or writeb.
struct exynos_hdmiphy_ops *exynos_hdmiphy_get_ops(unsigned int
i2c_hdmiphy)
{
/* Return hdmiphy ops appropriately according to i2c_hdmiphy. */
if (i2c_hdmiphy)
return hdmiphy_i2c_ops;
return hdmiphy_platdev_ops;
}
We don't need i2c_hdmiphy flag from the hdmi driver. After probe,
this information is available in hdmiphy driver itself.
int exynos_hdmiphy_driver_register(unsigned int i2c_hdmiphy)
{
...
/* Register hdmiphy driver appropriately according to
i2c_hdmiphy.
*/
if (i2c_hdmiphy) {
ret = i2c_add_driver(hdmiphy_i2c_driver);
...
} else {
ret =
platform_driver_register(hdmiphy_platform_driver);
...
}
Here i2c_hdmiphy flag helps in avoiding registering both i2c
and platform drivers for phy. But is it a concern that we should
not register 2 drivers on different buses for single hw device. I am
still not clear on this.
Re: [git pull] drm fixes
On Sat, Aug 31, 2013 at 04:02:16PM -0700, Linus Torvalds wrote: Hmm. I just updated my machine to a i7-4770S (kept everything else the same, just switched out motherboards), and now when my display goes to sleep, it seems to never come back. Sleep as in dpms off ($ xset dpms force off) or sleep as in system suspend? Any known issues with DVI on Haswell (it seems to show up as HDMI1 as the output, but it's a DVI cable)? I need to get a DP cable anyway (right now I'm driving my 2560x1440 display at 32Hz due to DVI crap) and maybe that will fix things, but this happens even if I don't force that odd mode (so it maxes out at 1920x1200 or whatever). I doubt this is new, but I've only ever run current -git on this machine, so who knows.. The machine ends up being kind of unusable. I guess I can just turn off power save. Hm, doesn't ring a bell here. Adding Paulo, our residential hsw display expert. Aside hsw hdmi ports support 300MHz dotclocks, but still only single-link. So I guess your dvi screen is still out of luck since it likely wants a dual-link dvi signal. But if you have a hdmi port it should work a bit better (hdmi pumped up the max dotclock a bit already a while ago ...). Cheers, 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 0/7] drm/exynos: move hdmiphy related code to hdmiphy driver
-Original Message-
From: Rahul Sharma [mailto:r.sh.o...@gmail.com]
Sent: Monday, September 02, 2013 3:28 PM
To: Inki Dae
Cc: Rahul Sharma; linux-samsung-soc; dri-devel@lists.freedesktop.org;
Kukjin Kim; sw0312.kim; Sean Paul; Lucas Stach; Tomasz Figa; Sylwester
Nawrocki; sunil joshi
Subject: Re: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
On 2 September 2013 10:38, Inki Dae inki@samsung.com wrote:
Hi Rahul,
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-
soc-
ow...@vger.kernel.org] On Behalf Of Rahul Sharma
Sent: Friday, August 30, 2013 7:06 PM
To: Inki Dae
Cc: Rahul Sharma; linux-samsung-soc; dri-devel@lists.freedesktop.org;
Kukjin Kim; sw0312.kim; Sean Paul; Lucas Stach; Tomasz Figa; Sylwester
Nawrocki; sunil joshi
Subject: Re: [PATCH 0/7] drm/exynos: move hdmiphy related code to
hdmiphy
driver
Thanks Mr. Dae,
I have some points for discussion.
On 30 August 2013 14:03, Inki Dae inki@samsung.com wrote:
Hi Rahul.
Thanks for your patch set.
I had just quick review to all patch series. And I think we could
fully
hide
hdmiphy interfaces,
exynos_hdmiphy_enable/disable/check_mode/set_mode/conf_apply, from
hdmi
driver.
That may be prototyped like below,
at exynos_hdmi.h
/* Define hdmiphy callbacks. */
struct exynos_hdmiphy_ops {
void (*enable)(struct device *dev);
void (*disable)(struct device *dev);
int (*check_mode)(struct device *dev, struct drm_display_mode
*mode);
int (*set_mode)(struct device *dev, struct drm_display_mode
*mode);
int (*apply)(struct device *dev);
};
Above looks fine to me. I will hide the ops as you suggested.
at exynos_hdmi.c
/*
* Add a new structure for hdmi driver data.
* type could be HDMI_TYPE13 or HDMI_TYPE14.
* i2c_hdmiphy could be true or false: true means that current hdmi
device
uses i2c
* based hdmiphy device, otherwise platform device based one.
*/
struct hdmi_drv_data {
unsigned int type;
unsigned int i2c_hdmiphy;
};
...
/* Add new members to hdmi context. */
struct hdmi_context {
...
struct hdmi_drv_data *drv_data;
struct hdmiphy_ops *ops;
...
};
/* Add hdmi device data according Exynos SoC. */
static struct hdmi_drv_data exynos4212_hdmi_drv_data = {
.type = HDMI_TYPE14,
.i2c_hdmiphy = true
};
static struct hdmi_drv_data exynos5420_hdmi_drv_data = {
.type = HDMI_TYPE14,
.i2c_hdmiphy = false
};
static struct of_device_id hdmi_match_types[] = {
{
.compatible = samsung,exynos4212-hdmi,
.data = (void *)exynos4212_hdmi_drv_data,
}, {
...
.compatible = samsung,exynos5420-hdmi,
.data = (void *)exynos5420_hdmi_drv_data,
}, {
}
};
/* the below example function shows how hdmiphy interfaces can be
hided
from
hdmi driver. */
static void hdmi_mode_set(...)
{
...
hdata-ops-set_mode(hdata-hdmiphy_dev, mode);
This looks fine.
}
static int hdmi_get_phy_device(struct hdmi_context *hdata)
{
struct hdmi_drv_data *data = hdata-drv_data;
...
/* Register hdmiphy driver according to i2c_hdmiphy value. */
ret = exynos_hdmiphy_driver_register(data-i2c_hdmiphy);
...
/* Get hdmiphy driver ops according to i2c_hdmiphy value. */
hdata-ops = exynos_hdmiphy_get_ops(data-i2c_hdmiphy);
...
}
at exynos_hdmiphy.c
/* Define hdmiphy ops respectively. */
struct exynos_hdmiphy_ops hdmiphy_i2c_ops = {
.enable = exynos_hdmiphy_i2c_enable,
.disable = exynos_hdmiphy_i2c_disable,
...
};
struct exynos_hdmiphy_ops hdmiphy_platdev_ops = {
.enable = exynos_hdmiphy_platdev_enable,
.disable = exynos_hdmiphy_platdev_disable,
...
};
Actually, Ops for Hdmiphy I2c and platform devices are exactly
same. We don't need 2 sets. Only difference is in static function to
write configuration values to phy. Based on i2c_verify_client(hdata-
dev),
we use i2c_master_send or writeb.
struct exynos_hdmiphy_ops *exynos_hdmiphy_get_ops(unsigned int
i2c_hdmiphy)
{
/* Return hdmiphy ops appropriately according to i2c_hdmiphy.
*/
if (i2c_hdmiphy)
return hdmiphy_i2c_ops;
return hdmiphy_platdev_ops;
}
We don't need i2c_hdmiphy flag from the hdmi driver. After probe,
this information is available in hdmiphy driver itself.
int exynos_hdmiphy_driver_register(unsigned int i2c_hdmiphy)
{
Re: [RFC 0/4] Atomic Display Framework
On Fri, Aug 30, 2013 at 10:00:28AM -0400, Rob Clark wrote: On Thu, Aug 29, 2013 at 7:34 PM, Greg Hackmann ghackm...@google.com wrote: On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark robdcl...@gmail.com wrote: I guess if you have multiple encoders + multiple connectors for the ganging case, then it probably just looks like 2x displays, and nothing more really needed? I'm a bit fuzzy on what the hw looks like in this ganging scenario, so I'm not completely sure what the best approach is. But if we do have hw like this, then it makes sense to support it *somehow* in KMS. I don't have the hardware anymore so this is all working from memory, it didn't look like two independent displays. You had to explicitly set up connections between the two mixers to deal with things like scaled overlays that spanned both mixers (there was some in-hardware magic to make sure there wasn't a visible seam where the two mixers met). Ok, sounds like mixer == crtc (ie. the thing the combines one or more planes)? So it sounds maybe a bit like: plane0_0 -\ ...+--- CRTC -\ plane0_n -/ | +-- encoder - connector plane1_0 -\ | ...+--- CRTC -/ plane1_n -/ More than one crtc to the same encoder feels funny. Can't we just keep this mixer thing internal to the kms driver by making the failure conditions a bit more obtuse to userspace? Either way we need highly special userspace to get this thing going, since a generic modesetting driver probably can't figure out that it needs to split up the logical framebuffer into smaller planes to be able to actually shovel all the pixels to the screen. Thus far the assumption we've backed into all dumb kms drivers is that the crtc/plane limit is also the limit for the maximum output resolution ... Could we have a notch more details on how this is exactly wired up? Another approach would be a set of encoders for each part of the display and some metadata (like left/right-of, ...) so that userspace understands how the aggregate display is stitched togeter. Cheers, 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 v4 5/6] drm/i915: use new drm_kick_out_firmware()
On Sun, Sep 01, 2013 at 03:36:51PM +0200, David Herrmann wrote: Use the new DRM infrastructure to kick out firmware DRM drivers before loading i915. Cc: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: David Herrmann dh.herrm...@gmail.com --- drivers/gpu/drm/i915/i915_dma.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 3e4e607..9d375a6 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1414,9 +1414,9 @@ static void i915_kick_out_firmware_fb(struct drm_i915_private *dev_priv) primary = pdev-resource[PCI_ROM_RESOURCE].flags IORESOURCE_ROM_SHADOW; - remove_conflicting_framebuffers(ap, inteldrmfb, primary); - - kfree(ap); + drm_kick_out_firmware(ap, primary); + dev_priv-dev-apertures = ap; + dev_priv-dev-apert_boot = primary; What about passing dev to drm_kick_out_firmware and shovelling these two assignments in there? I've check your nouveau/radeon patches and I think this would work ... -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
[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 #95 from Francisco Pina Martins f.pinamart...@gmail.com --- After using DPM for a while I car report that it did cause some random crashes. I never figured out what caused them, and was never able to reproduce them. However, after having updated mesa to 9.2, I have had no crashes at all, so that might have solves whatever was causing the issues. Just tossing in my 0,02€: It works! Thanks for all the hard work on this one. -- 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 0/7] drm/exynos: move hdmiphy related code to hdmiphy driver
On 2 September 2013 12:52, Inki Dae inki@samsung.com wrote:
-Original Message-
From: Rahul Sharma [mailto:r.sh.o...@gmail.com]
Sent: Monday, September 02, 2013 3:28 PM
To: Inki Dae
Cc: Rahul Sharma; linux-samsung-soc; dri-devel@lists.freedesktop.org;
Kukjin Kim; sw0312.kim; Sean Paul; Lucas Stach; Tomasz Figa; Sylwester
Nawrocki; sunil joshi
Subject: Re: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
On 2 September 2013 10:38, Inki Dae inki@samsung.com wrote:
Hi Rahul,
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-
soc-
ow...@vger.kernel.org] On Behalf Of Rahul Sharma
Sent: Friday, August 30, 2013 7:06 PM
To: Inki Dae
Cc: Rahul Sharma; linux-samsung-soc; dri-devel@lists.freedesktop.org;
Kukjin Kim; sw0312.kim; Sean Paul; Lucas Stach; Tomasz Figa; Sylwester
Nawrocki; sunil joshi
Subject: Re: [PATCH 0/7] drm/exynos: move hdmiphy related code to
hdmiphy
driver
Thanks Mr. Dae,
I have some points for discussion.
On 30 August 2013 14:03, Inki Dae inki@samsung.com wrote:
Hi Rahul.
Thanks for your patch set.
I had just quick review to all patch series. And I think we could
fully
hide
hdmiphy interfaces,
exynos_hdmiphy_enable/disable/check_mode/set_mode/conf_apply, from
hdmi
driver.
That may be prototyped like below,
at exynos_hdmi.h
/* Define hdmiphy callbacks. */
struct exynos_hdmiphy_ops {
void (*enable)(struct device *dev);
void (*disable)(struct device *dev);
int (*check_mode)(struct device *dev, struct drm_display_mode
*mode);
int (*set_mode)(struct device *dev, struct drm_display_mode
*mode);
int (*apply)(struct device *dev);
};
Above looks fine to me. I will hide the ops as you suggested.
at exynos_hdmi.c
/*
* Add a new structure for hdmi driver data.
* type could be HDMI_TYPE13 or HDMI_TYPE14.
* i2c_hdmiphy could be true or false: true means that current hdmi
device
uses i2c
* based hdmiphy device, otherwise platform device based one.
*/
struct hdmi_drv_data {
unsigned int type;
unsigned int i2c_hdmiphy;
};
...
/* Add new members to hdmi context. */
struct hdmi_context {
...
struct hdmi_drv_data *drv_data;
struct hdmiphy_ops *ops;
...
};
/* Add hdmi device data according Exynos SoC. */
static struct hdmi_drv_data exynos4212_hdmi_drv_data = {
.type = HDMI_TYPE14,
.i2c_hdmiphy = true
};
static struct hdmi_drv_data exynos5420_hdmi_drv_data = {
.type = HDMI_TYPE14,
.i2c_hdmiphy = false
};
static struct of_device_id hdmi_match_types[] = {
{
.compatible = samsung,exynos4212-hdmi,
.data = (void *)exynos4212_hdmi_drv_data,
}, {
...
.compatible = samsung,exynos5420-hdmi,
.data = (void *)exynos5420_hdmi_drv_data,
}, {
}
};
/* the below example function shows how hdmiphy interfaces can be
hided
from
hdmi driver. */
static void hdmi_mode_set(...)
{
...
hdata-ops-set_mode(hdata-hdmiphy_dev, mode);
This looks fine.
}
static int hdmi_get_phy_device(struct hdmi_context *hdata)
{
struct hdmi_drv_data *data = hdata-drv_data;
...
/* Register hdmiphy driver according to i2c_hdmiphy value. */
ret = exynos_hdmiphy_driver_register(data-i2c_hdmiphy);
...
/* Get hdmiphy driver ops according to i2c_hdmiphy value. */
hdata-ops = exynos_hdmiphy_get_ops(data-i2c_hdmiphy);
...
}
at exynos_hdmiphy.c
/* Define hdmiphy ops respectively. */
struct exynos_hdmiphy_ops hdmiphy_i2c_ops = {
.enable = exynos_hdmiphy_i2c_enable,
.disable = exynos_hdmiphy_i2c_disable,
...
};
struct exynos_hdmiphy_ops hdmiphy_platdev_ops = {
.enable = exynos_hdmiphy_platdev_enable,
.disable = exynos_hdmiphy_platdev_disable,
...
};
Actually, Ops for Hdmiphy I2c and platform devices are exactly
same. We don't need 2 sets. Only difference is in static function to
write configuration values to phy. Based on i2c_verify_client(hdata-
dev),
we use i2c_master_send or writeb.
struct exynos_hdmiphy_ops *exynos_hdmiphy_get_ops(unsigned int
i2c_hdmiphy)
{
/* Return hdmiphy ops appropriately according to i2c_hdmiphy.
*/
if (i2c_hdmiphy)
return hdmiphy_i2c_ops;
return hdmiphy_platdev_ops;
}
We don't need i2c_hdmiphy flag from the hdmi driver. After probe,
this information is available in hdmiphy driver itself.
int
RE: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy driver
-Original Message-
From: Rahul Sharma [mailto:r.sh.o...@gmail.com]
Sent: Monday, September 02, 2013 6:06 PM
To: Inki Dae
Cc: Rahul Sharma; linux-samsung-soc; dri-devel@lists.freedesktop.org;
Kukjin Kim; sw0312.kim; Sean Paul; Lucas Stach; Tomasz Figa; Sylwester
Nawrocki; sunil joshi
Subject: Re: [PATCH 0/7] drm/exynos: move hdmiphy related code to hdmiphy
driver
On 2 September 2013 12:52, Inki Dae inki@samsung.com wrote:
-Original Message-
From: Rahul Sharma [mailto:r.sh.o...@gmail.com]
Sent: Monday, September 02, 2013 3:28 PM
To: Inki Dae
Cc: Rahul Sharma; linux-samsung-soc; dri-devel@lists.freedesktop.org;
Kukjin Kim; sw0312.kim; Sean Paul; Lucas Stach; Tomasz Figa; Sylwester
Nawrocki; sunil joshi
Subject: Re: [PATCH 0/7] drm/exynos: move hdmiphy related code to
hdmiphy
driver
On 2 September 2013 10:38, Inki Dae inki@samsung.com wrote:
Hi Rahul,
-Original Message-
From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-
soc-
ow...@vger.kernel.org] On Behalf Of Rahul Sharma
Sent: Friday, August 30, 2013 7:06 PM
To: Inki Dae
Cc: Rahul Sharma; linux-samsung-soc;
dri-devel@lists.freedesktop.org;
Kukjin Kim; sw0312.kim; Sean Paul; Lucas Stach; Tomasz Figa;
Sylwester
Nawrocki; sunil joshi
Subject: Re: [PATCH 0/7] drm/exynos: move hdmiphy related code to
hdmiphy
driver
Thanks Mr. Dae,
I have some points for discussion.
On 30 August 2013 14:03, Inki Dae inki@samsung.com wrote:
Hi Rahul.
Thanks for your patch set.
I had just quick review to all patch series. And I think we could
fully
hide
hdmiphy interfaces,
exynos_hdmiphy_enable/disable/check_mode/set_mode/conf_apply, from
hdmi
driver.
That may be prototyped like below,
at exynos_hdmi.h
/* Define hdmiphy callbacks. */
struct exynos_hdmiphy_ops {
void (*enable)(struct device *dev);
void (*disable)(struct device *dev);
int (*check_mode)(struct device *dev, struct
drm_display_mode
*mode);
int (*set_mode)(struct device *dev, struct
drm_display_mode
*mode);
int (*apply)(struct device *dev);
};
Above looks fine to me. I will hide the ops as you suggested.
at exynos_hdmi.c
/*
* Add a new structure for hdmi driver data.
* type could be HDMI_TYPE13 or HDMI_TYPE14.
* i2c_hdmiphy could be true or false: true means that current
hdmi
device
uses i2c
* based hdmiphy device, otherwise platform device based one.
*/
struct hdmi_drv_data {
unsigned int type;
unsigned int i2c_hdmiphy;
};
...
/* Add new members to hdmi context. */
struct hdmi_context {
...
struct hdmi_drv_data *drv_data;
struct hdmiphy_ops *ops;
...
};
/* Add hdmi device data according Exynos SoC. */
static struct hdmi_drv_data exynos4212_hdmi_drv_data = {
.type = HDMI_TYPE14,
.i2c_hdmiphy = true
};
static struct hdmi_drv_data exynos5420_hdmi_drv_data = {
.type = HDMI_TYPE14,
.i2c_hdmiphy = false
};
static struct of_device_id hdmi_match_types[] = {
{
.compatible = samsung,exynos4212-hdmi,
.data = (void
*)exynos4212_hdmi_drv_data,
}, {
...
.compatible = samsung,exynos5420-hdmi,
.data = (void
*)exynos5420_hdmi_drv_data,
}, {
}
};
/* the below example function shows how hdmiphy interfaces can be
hided
from
hdmi driver. */
static void hdmi_mode_set(...)
{
...
hdata-ops-set_mode(hdata-hdmiphy_dev, mode);
This looks fine.
}
static int hdmi_get_phy_device(struct hdmi_context *hdata)
{
struct hdmi_drv_data *data = hdata-drv_data;
...
/* Register hdmiphy driver according to i2c_hdmiphy value.
*/
ret = exynos_hdmiphy_driver_register(data-i2c_hdmiphy);
...
/* Get hdmiphy driver ops according to i2c_hdmiphy value.
*/
hdata-ops = exynos_hdmiphy_get_ops(data-i2c_hdmiphy);
...
}
at exynos_hdmiphy.c
/* Define hdmiphy ops respectively. */
struct exynos_hdmiphy_ops hdmiphy_i2c_ops = {
.enable = exynos_hdmiphy_i2c_enable,
.disable = exynos_hdmiphy_i2c_disable,
...
};
struct exynos_hdmiphy_ops hdmiphy_platdev_ops = {
.enable = exynos_hdmiphy_platdev_enable,
.disable = exynos_hdmiphy_platdev_disable,
...
};
Actually, Ops for Hdmiphy I2c and platform devices are exactly
same. We don't need 2 sets. Only difference is in static function to
[Bug 68805] 48 fps and 50 fps video decoding is stutter on UVD
https://bugs.freedesktop.org/show_bug.cgi?id=68805 --- Comment #4 from Grigori Goronzy g...@chown.ath.cx --- There are some known performance problems with UVD. I don't believe we know why it is slower than fglrx yet. Maybe something subtle related to UVD setup. Tiling is also disabled for UVD surfaces at the moment. This slightly reduces throughput, especially on GPUs with little memory bandwidth (such as APUs). -- 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 v4 5/6] drm/i915: use new drm_kick_out_firmware()
Hi On Mon, Sep 2, 2013 at 9:43 AM, Daniel Vetter dan...@ffwll.ch wrote: On Sun, Sep 01, 2013 at 03:36:51PM +0200, David Herrmann wrote: Use the new DRM infrastructure to kick out firmware DRM drivers before loading i915. Cc: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: David Herrmann dh.herrm...@gmail.com --- drivers/gpu/drm/i915/i915_dma.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 3e4e607..9d375a6 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1414,9 +1414,9 @@ static void i915_kick_out_firmware_fb(struct drm_i915_private *dev_priv) primary = pdev-resource[PCI_ROM_RESOURCE].flags IORESOURCE_ROM_SHADOW; - remove_conflicting_framebuffers(ap, inteldrmfb, primary); - - kfree(ap); + drm_kick_out_firmware(ap, primary); + dev_priv-dev-apertures = ap; + dev_priv-dev-apert_boot = primary; What about passing dev to drm_kick_out_firmware and shovelling these two assignments in there? I've check your nouveau/radeon patches and I think this would work ... Yepp, that sounds reasonable. And I guess the kfree() of apertures can also be done in drm_put_dev(). Maybe we can even to the whole stuff in drm_pci.c, I will have a look. Thanks David ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68845] New: VDPAU/UVD regression
https://bugs.freedesktop.org/show_bug.cgi?id=68845 Priority: medium Bug ID: 68845 Assignee: dri-devel@lists.freedesktop.org Summary: VDPAU/UVD regression Severity: normal Classification: Unclassified OS: Linux (All) Reporter: sl...@ac.auone-net.jp Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Mplayer with VDPAU shows garbage for some videos. The same videos play fine with older mesa. So I bisected mesa and the result is: 53e20b8b418cc85e13d70f41ce160e17847a5096 is the first bad commit commit 53e20b8b418cc85e13d70f41ce160e17847a5096 Author: Christian König christian.koe...@amd.com Date: Mon Jul 15 01:50:24 2013 -0600 vl: use a template for create_video_decoder Signed-off-by: Christian König christian.koe...@amd.com :04 04 44292598330b8e3aba03bf8acd325e46d48f45dc a77402a17cfcdd893cc8f11805437e4d6eb0af22 Msrc Steps to reproduce: 1. Download 854x480 H.264 video from http://www.bigbuckbunny.org/index.php/download/ 2. Play it with mplayer using VDPAU. That is to say, mplayer -vo vdpau -vc ffh264vdpau big_buck_bunny_480p_h264.mov -- 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 68845] VDPAU/UVD regression
https://bugs.freedesktop.org/show_bug.cgi?id=68845 --- Comment #1 from Kusanagi Kouichi sl...@ac.auone-net.jp --- Created attachment 85059 -- https://bugs.freedesktop.org/attachment.cgi?id=85059action=edit screenshot with mesa snb-magic-17559-gd13003f -- 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 68845] VDPAU/UVD regression
https://bugs.freedesktop.org/show_bug.cgi?id=68845 --- Comment #2 from Kusanagi Kouichi sl...@ac.auone-net.jp --- Created attachment 85060 -- https://bugs.freedesktop.org/attachment.cgi?id=85060action=edit screenshot with mesa snb-magic-17560-g53e20b8 -- 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: [RFC 0/4] Atomic Display Framework
On Mon, Sep 2, 2013 at 3:39 AM, Daniel Vetter dan...@ffwll.ch wrote: On Fri, Aug 30, 2013 at 10:00:28AM -0400, Rob Clark wrote: On Thu, Aug 29, 2013 at 7:34 PM, Greg Hackmann ghackm...@google.com wrote: On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark robdcl...@gmail.com wrote: I guess if you have multiple encoders + multiple connectors for the ganging case, then it probably just looks like 2x displays, and nothing more really needed? I'm a bit fuzzy on what the hw looks like in this ganging scenario, so I'm not completely sure what the best approach is. But if we do have hw like this, then it makes sense to support it *somehow* in KMS. I don't have the hardware anymore so this is all working from memory, it didn't look like two independent displays. You had to explicitly set up connections between the two mixers to deal with things like scaled overlays that spanned both mixers (there was some in-hardware magic to make sure there wasn't a visible seam where the two mixers met). Ok, sounds like mixer == crtc (ie. the thing the combines one or more planes)? So it sounds maybe a bit like: plane0_0 -\ ...+--- CRTC -\ plane0_n -/ | +-- encoder - connector plane1_0 -\ | ...+--- CRTC -/ plane1_n -/ More than one crtc to the same encoder feels funny. Can't we just keep this mixer thing internal to the kms driver by making the failure conditions a bit more obtuse to userspace? If there is not also a case where you'd want userspace to be able to use the two CRTC's independently, then I guess we can hide it in kernel. Otherwise, it seems that would get a bit awkward. Either way we need highly special userspace to get this thing going, since a generic modesetting driver probably can't figure out that it needs to split up the logical framebuffer into smaller planes to be able to actually shovel all the pixels to the screen. Thus far the assumption we've backed into all dumb kms drivers is that the crtc/plane limit is also the limit for the maximum output resolution ... Yeah, that is the case today. But seems like we should be able to expose crtc/plane limits so that userspace can figure it out in a generic way. Note that nothing actually has to split up fb's, but just setup planes to scanout a single fb at the appropriate x/y offsets. Could we have a notch more details on how this is exactly wired up? Another approach would be a set of encoders for each part of the display and some metadata (like left/right-of, ...) so that userspace understands how the aggregate display is stitched togeter. yeah, I think understanding the hw better should help understand whether N CRTCs to one encoder, or N encoders to one connector, or ?? BR, -R Cheers, 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
[Bug 68845] VDPAU/UVD regression
https://bugs.freedesktop.org/show_bug.cgi?id=68845 Christian König deathsim...@vodafone.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Christian König deathsim...@vodafone.de --- Thanks for the info, accidentally removed the width/height alignment with this commit. So any video not aligned to 16 in it's width/height showed this problem. -- 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 v4 5/6] drm/i915: use new drm_kick_out_firmware()
On Mon, Sep 02, 2013 at 02:02:06PM +0200, David Herrmann wrote: Hi On Mon, Sep 2, 2013 at 9:43 AM, Daniel Vetter dan...@ffwll.ch wrote: On Sun, Sep 01, 2013 at 03:36:51PM +0200, David Herrmann wrote: Use the new DRM infrastructure to kick out firmware DRM drivers before loading i915. Cc: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: David Herrmann dh.herrm...@gmail.com --- drivers/gpu/drm/i915/i915_dma.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 3e4e607..9d375a6 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1414,9 +1414,9 @@ static void i915_kick_out_firmware_fb(struct drm_i915_private *dev_priv) primary = pdev-resource[PCI_ROM_RESOURCE].flags IORESOURCE_ROM_SHADOW; - remove_conflicting_framebuffers(ap, inteldrmfb, primary); - - kfree(ap); + drm_kick_out_firmware(ap, primary); + dev_priv-dev-apertures = ap; + dev_priv-dev-apert_boot = primary; What about passing dev to drm_kick_out_firmware and shovelling these two assignments in there? I've check your nouveau/radeon patches and I think this would work ... Yepp, that sounds reasonable. And I guess the kfree() of apertures can also be done in drm_put_dev(). Maybe we can even to the whole stuff in drm_pci.c, I will have a look. I like the helper approach used here since it allows drivers to pick an appropriate spot. Moving it into drm_pci.c could be a bit ugly. Aside: I'm pondering ideas to weed out the midlayer smell from the drm device init sequence. I've played around with a few things and it looks like we're really close to doing the Right Thing ;-) Cheers, 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
[PATCH] drm/nv84-: write fence value on exit, and restore value on init.
This increases the chance slightly that recovery from lockup can happen
succesfully.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/nouveau/nv84_fence.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nv84_fence.c
b/drivers/gpu/drm/nouveau/nv84_fence.c
index 2cf0ade..daf4b18 100644
--- a/drivers/gpu/drm/nouveau/nv84_fence.c
+++ b/drivers/gpu/drm/nouveau/nv84_fence.c
@@ -122,8 +122,11 @@ nv84_fence_context_del(struct nouveau_channel *chan)
struct drm_device *dev = chan-drm-dev;
struct nv84_fence_priv *priv = chan-drm-fence;
struct nv84_fence_chan *fctx = chan-fence;
+ struct nouveau_fifo_chan *fifo = (void *)chan-object;
int i;
+ nouveau_bo_wr32(priv-bo, fifo-chid * 16/4, fctx-base.sequence);
+
for (i = 0; i dev-mode_config.num_crtc; i++) {
struct nouveau_bo *bo = nv50_display_crtc_sema(dev, i);
nouveau_bo_vma_del(bo, fctx-dispc_vma[i]);
@@ -168,7 +171,7 @@ nv84_fence_context_new(struct nouveau_channel *chan)
ret = nouveau_bo_vma_add(bo, client-vm, fctx-dispc_vma[i]);
}
- nouveau_bo_wr32(priv-bo, fifo-chid * 16/4, 0x);
+ fctx-base.sequence = nouveau_bo_rd32(priv-bo, fifo-chid * 16/4);
if (ret)
nv84_fence_context_del(chan);
--
1.8.3.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nv50-: fix tiled memory layout checks
nv50_bo_move_m2mf might copy to tiled gart, in which case linear copy is not
appropriate.
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 42
1 file changed, 24 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 88f0c45..0daf3f0 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -176,8 +176,8 @@ nouveau_bo_fixup_align(struct nouveau_bo *nvbo, u32 flags,
*size = roundup(*size, 32 * nvbo-tile_mode);
}
} else {
- *size = roundup(*size, (1 nvbo-page_shift));
- *align = max((1 nvbo-page_shift), *align);
+ *align = 1 nvbo-page_shift;
+ *size = roundup(*size, *align);
}
*size = roundup(*size, PAGE_SIZE);
@@ -713,6 +713,8 @@ nvc0_bo_move_m2mf(struct nouveau_channel *chan, struct
ttm_buffer_object *bo,
u32 page_count = new_mem-num_pages;
int ret, last_count = 0;
+ nv_error(chan-drm, Evicting %#x bytes from %u/%#Lx to %u/%#Lx\n,
page_count PAGE_SHIFT, old_mem-mem_type, src_offset, new_mem-mem_type,
dst_offset);
+
ret = RING_SPACE(chan, (page_count + 2046) / 2047 * 7 + 2);
if (ret)
return ret;
@@ -834,19 +836,17 @@ static int
nv50_bo_move_m2mf(struct nouveau_channel *chan, struct ttm_buffer_object *bo,
struct ttm_mem_reg *old_mem, struct ttm_mem_reg *new_mem)
{
- struct nouveau_mem *node = old_mem-mm_node;
+ struct nouveau_mem *old_node = old_mem-mm_node;
+ struct nouveau_mem *new_node = new_mem-mm_node;
struct nouveau_bo *nvbo = nouveau_bo(bo);
u64 length = (new_mem-num_pages PAGE_SHIFT);
- u64 src_offset = node-vma[0].offset;
- u64 dst_offset = node-vma[1].offset;
+ u64 src_offset = old_node-vma[0].offset;
+ u64 dst_offset = old_node-vma[1].offset;
u32 size;
int ret;
size = 18;
- if (nouveau_bo_tile_layout(nvbo)) {
- size += 6 * (old_mem-mem_type == TTM_PL_VRAM);
- size += 6 * (new_mem-mem_type == TTM_PL_VRAM);
- }
+ size += 6 * (!!old_node-memtype + !!new_node-memtype);
size *= (length + (4 * 1024 * 1024) - 1) / (4 * 1024 * 1024);
ret = RING_SPACE(chan, size);
if (ret)
@@ -859,8 +859,7 @@ nv50_bo_move_m2mf(struct nouveau_channel *chan, struct
ttm_buffer_object *bo,
stride = 16 * 4;
height = amount / stride;
- if (old_mem-mem_type == TTM_PL_VRAM
- nouveau_bo_tile_layout(nvbo)) {
+ if (old_node-memtype) {
BEGIN_NV04(chan, NvSubCopy, 0x0200, 7);
OUT_RING (chan, 0);
OUT_RING (chan, 0);
@@ -873,8 +872,7 @@ nv50_bo_move_m2mf(struct nouveau_channel *chan, struct
ttm_buffer_object *bo,
BEGIN_NV04(chan, NvSubCopy, 0x0200, 1);
OUT_RING (chan, 1);
}
- if (new_mem-mem_type == TTM_PL_VRAM
- nouveau_bo_tile_layout(nvbo)) {
+ if (new_node-memtype) {
BEGIN_NV04(chan, NvSubCopy, 0x021c, 7);
OUT_RING (chan, 0);
OUT_RING (chan, 0);
@@ -1051,8 +1049,8 @@ nouveau_bo_move_init(struct nouveau_drm *drm)
} _methods[] = {
{ COPY, 4, 0xa0b5, nve0_bo_move_copy, nve0_bo_move_init },
{ GRCE, 0, 0xa0b5, nve0_bo_move_copy, nve0_bo_move_init },
- { COPY1, 5, 0x90b8, nvc0_bo_move_copy, nvc0_bo_copy_init },
- { COPY0, 4, 0x90b5, nvc0_bo_move_copy, nvc0_bo_copy_init },
+// { COPY1, 5, 0x90b8, nvc0_bo_move_copy, nvc0_bo_copy_init },
+// { COPY0, 4, 0x90b5, nvc0_bo_move_copy, nvc0_bo_copy_init },
{ COPY, 0, 0x85b5, nva3_bo_move_copy, nv50_bo_move_init },
{ CRYPT, 0, 0x74c1, nv84_bo_move_exec, nv50_bo_move_init },
{ M2MF, 0, 0x9039, nvc0_bo_move_m2mf, nvc0_bo_m2mf_init },
@@ -1166,13 +1164,23 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo,
struct ttm_mem_reg *new_mem)
{
struct nouveau_bo *nvbo = nouveau_bo(bo);
struct nouveau_vma *vma;
+ struct ttm_mem_reg *old_mem = bo-mem;
/* ttm can now (stupidly) pass the driver bos it didn't create... */
if (bo-destroy != nouveau_bo_del_ttm)
return;
list_for_each_entry(vma, nvbo-vma_list, head) {
- if (new_mem new_mem-mem_type == TTM_PL_VRAM) {
+ if (!new_mem ||
+ old_mem-mem_type == TTM_PL_VRAM ||
+ (old_mem-mem_type == TTM_PL_TT
+nvbo-page_shift == vma-vm-vmm-spg_shift))
+ nouveau_vm_unmap(vma);
+
+ if (!new_mem)
+
[PATCH] drm/nv50-: make dma-objects read-only where appropriate
I don't see why the display engine would need write access to the entirety of
vram, when read-only access is enough.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/nouveau/nv50_display.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_display.c
index aab72f5..eac6b2a 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -159,7 +159,7 @@ nv50_dmac_create_fbdma(struct nouveau_object *core, u32
parent)
NV_DMA_IN_MEMORY_CLASS,
(struct nv_dma_class) {
.flags = NV_DMA_TARGET_VRAM |
-NV_DMA_ACCESS_RDWR,
+NV_DMA_ACCESS_RD,
.start = 0,
.limit = pfb-ram-size - 1,
.conf0 = NV50_DMA_CONF0_ENABLE |
@@ -172,7 +172,7 @@ nv50_dmac_create_fbdma(struct nouveau_object *core, u32
parent)
NV_DMA_IN_MEMORY_CLASS,
(struct nv_dma_class) {
.flags = NV_DMA_TARGET_VRAM |
-NV_DMA_ACCESS_RDWR,
+NV_DMA_ACCESS_RD,
.start = 0,
.limit = pfb-ram-size - 1,
.conf0 = NV50_DMA_CONF0_ENABLE | 0x70 |
@@ -185,7 +185,7 @@ nv50_dmac_create_fbdma(struct nouveau_object *core, u32
parent)
NV_DMA_IN_MEMORY_CLASS,
(struct nv_dma_class) {
.flags = NV_DMA_TARGET_VRAM |
-NV_DMA_ACCESS_RDWR,
+NV_DMA_ACCESS_RD,
.start = 0,
.limit = pfb-ram-size - 1,
.conf0 = NV50_DMA_CONF0_ENABLE | 0x7a |
@@ -204,7 +204,7 @@ nvc0_dmac_create_fbdma(struct nouveau_object *core, u32
parent)
NV_DMA_IN_MEMORY_CLASS,
(struct nv_dma_class) {
.flags = NV_DMA_TARGET_VRAM |
-NV_DMA_ACCESS_RDWR,
+NV_DMA_ACCESS_RD,
.start = 0,
.limit = pfb-ram-size - 1,
.conf0 = NVC0_DMA_CONF0_ENABLE,
@@ -216,7 +216,7 @@ nvc0_dmac_create_fbdma(struct nouveau_object *core, u32
parent)
NV_DMA_IN_MEMORY_CLASS,
(struct nv_dma_class) {
.flags = NV_DMA_TARGET_VRAM |
-NV_DMA_ACCESS_RDWR,
+NV_DMA_ACCESS_RD,
.start = 0,
.limit = pfb-ram-size - 1,
.conf0 = NVC0_DMA_CONF0_ENABLE | 0xfe,
@@ -228,7 +228,7 @@ nvc0_dmac_create_fbdma(struct nouveau_object *core, u32
parent)
NV_DMA_IN_MEMORY_CLASS,
(struct nv_dma_class) {
.flags = NV_DMA_TARGET_VRAM |
-NV_DMA_ACCESS_RDWR,
+NV_DMA_ACCESS_RD,
.start = 0,
.limit = pfb-ram-size - 1,
.conf0 = NVC0_DMA_CONF0_ENABLE | 0xfe,
@@ -246,7 +246,7 @@ nvd0_dmac_create_fbdma(struct nouveau_object *core, u32
parent)
NV_DMA_IN_MEMORY_CLASS,
(struct nv_dma_class) {
.flags = NV_DMA_TARGET_VRAM |
-NV_DMA_ACCESS_RDWR,
+NV_DMA_ACCESS_RD,
.start = 0,
.limit = pfb-ram-size - 1,
.conf0 = NVD0_DMA_CONF0_ENABLE |
@@ -259,7 +259,7 @@ nvd0_dmac_create_fbdma(struct nouveau_object *core, u32
parent)
NV_DMA_IN_MEMORY_CLASS,
(struct nv_dma_class) {
.flags =
[PATCH] drm/nouveau: fix command submission to use vmalloc for big allocations
I was getting a order 4 allocation failure from kmalloc when testing some game
after a few days uptime with some suspend/resumes. For big allocations vmalloc
should be used instead.
Also limit size more aggressively to 256 KiB.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 177b86d5..779d702 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -584,18 +584,34 @@ nouveau_gem_pushbuf_validate(struct nouveau_channel *chan,
return 0;
}
+static inline void
+u_free(void *addr)
+{
+ if (!is_vmalloc_addr(addr))
+ kfree(addr);
+ else
+ vfree(addr);
+}
+
static inline void *
u_memcpya(uint64_t user, unsigned nmemb, unsigned size)
{
void *mem;
void __user *userptr = (void __force __user *)(uintptr_t)user;
- mem = kmalloc(nmemb * size, GFP_KERNEL);
+ if (nmemb 256 * 1024 / size)
+ return ERR_PTR(-ENOMEM);
+
+ size *= nmemb;
+
+ mem = kmalloc(size, GFP_KERNEL | __GFP_NOWARN);
+ if (!mem)
+ mem = vmalloc(size);
if (!mem)
return ERR_PTR(-ENOMEM);
- if (DRM_COPY_FROM_USER(mem, userptr, nmemb * size)) {
- kfree(mem);
+ if (DRM_COPY_FROM_USER(mem, userptr, size)) {
+ u_free(mem);
return ERR_PTR(-EFAULT);
}
@@ -681,7 +697,7 @@ nouveau_gem_pushbuf_reloc_apply(struct nouveau_cli *cli,
nouveau_bo_wr32(nvbo, r-reloc_bo_offset 2, data);
}
- kfree(reloc);
+ u_free(reloc);
return ret;
}
@@ -743,7 +759,7 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void
*data,
bo = u_memcpya(req-buffers, req-nr_buffers, sizeof(*bo));
if (IS_ERR(bo)) {
- kfree(push);
+ u_free(push);
return nouveau_abi16_put(abi16, PTR_ERR(bo));
}
@@ -854,8 +870,8 @@ out:
nouveau_fence_unref(fence);
out_prevalid:
- kfree(bo);
- kfree(push);
+ u_free(bo);
+ u_free(push);
out_next:
if (chan-dma.ib_max) {
--
1.8.3.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: force alignment to 0x1000 for gpu objects
There are a lot of places that allocate multiples of 1000,
but do not set alignment correctly and still require this
alignment implicitly or explicitly.
---
drivers/gpu/drm/nouveau/core/core/gpuobj.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/core/core/gpuobj.c
b/drivers/gpu/drm/nouveau/core/core/gpuobj.c
index 7595506..7bcae1d 100644
--- a/drivers/gpu/drm/nouveau/core/core/gpuobj.c
+++ b/drivers/gpu/drm/nouveau/core/core/gpuobj.c
@@ -65,6 +65,14 @@ nouveau_gpuobj_create_(struct nouveau_object *parent,
int ret, i;
u64 addr;
+ /*
+* There are a lot of places that allocate multiples of 1000,
+* but do not set alignment correctly and still require this
+* alignment implicitly or explicitly.
+*/
+ if (size = 0x1000 align 0x1000)
+ align = 0x1000;
+
*pobject = NULL;
if (pargpu) {
--
1.8.3.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 0/4] Atomic Display Framework
On Mon, Sep 2, 2013 at 9:19 AM, Rob Clark robdcl...@gmail.com wrote: On Mon, Sep 2, 2013 at 3:39 AM, Daniel Vetter dan...@ffwll.ch wrote: On Fri, Aug 30, 2013 at 10:00:28AM -0400, Rob Clark wrote: On Thu, Aug 29, 2013 at 7:34 PM, Greg Hackmann ghackm...@google.com wrote: On Thu, Aug 29, 2013 at 5:54 AM, Rob Clark robdcl...@gmail.com wrote: I guess if you have multiple encoders + multiple connectors for the ganging case, then it probably just looks like 2x displays, and nothing more really needed? I'm a bit fuzzy on what the hw looks like in this ganging scenario, so I'm not completely sure what the best approach is. But if we do have hw like this, then it makes sense to support it *somehow* in KMS. I don't have the hardware anymore so this is all working from memory, it didn't look like two independent displays. You had to explicitly set up connections between the two mixers to deal with things like scaled overlays that spanned both mixers (there was some in-hardware magic to make sure there wasn't a visible seam where the two mixers met). Ok, sounds like mixer == crtc (ie. the thing the combines one or more planes)? So it sounds maybe a bit like: plane0_0 -\ ...+--- CRTC -\ plane0_n -/ | +-- encoder - connector plane1_0 -\ | ...+--- CRTC -/ plane1_n -/ More than one crtc to the same encoder feels funny. Can't we just keep this mixer thing internal to the kms driver by making the failure conditions a bit more obtuse to userspace? If there is not also a case where you'd want userspace to be able to use the two CRTC's independently, then I guess we can hide it in kernel. Otherwise, it seems that would get a bit awkward. Either way we need highly special userspace to get this thing going, since a generic modesetting driver probably can't figure out that it needs to split up the logical framebuffer into smaller planes to be able to actually shovel all the pixels to the screen. Thus far the assumption we've backed into all dumb kms drivers is that the crtc/plane limit is also the limit for the maximum output resolution ... Yeah, that is the case today. But seems like we should be able to expose crtc/plane limits so that userspace can figure it out in a generic way. Note that nothing actually has to split up fb's, but just setup planes to scanout a single fb at the appropriate x/y offsets. Could we have a notch more details on how this is exactly wired up? Another approach would be a set of encoders for each part of the display and some metadata (like left/right-of, ...) so that userspace understands how the aggregate display is stitched togeter. yeah, I think understanding the hw better should help understand whether N CRTCs to one encoder, or N encoders to one connector, or ?? On our hardware there is basically a crossbar between the crtcs and the encoders: GRPH -\ +--- CRTC -| OVL -/ | +-- encoder - connector GRPH -\ | +--- CRTC -| OVL -/ | +-- encoder - connector GRPH -\ | +--- CRTC -| OVL -/ | +-- encoder - connector GRPH -\ | +--- CRTC -| OVL -/ Encoders are hardcoded to connectors, planes (GRPH and OVL) are hardcoded to crtcs, but crtcs can be routed between encoders. There are also cases where you can gang crtcs (e.g., map multiple crtcs to a single encoder) for handling certain corner cases. Alex BR, -R Cheers, 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 ___ 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 #96 from Eugene ken20...@ukr.net --- Not so fast fellas. Recently checked 3.11RC7 and DRM-Next (current). The result is the same: it still can't boot with my Radeon HD 2600 XT :( -- 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 #97 from Alex Deucher ag...@yahoo.com --- (In reply to comment #96) Not so fast fellas. Recently checked 3.11RC7 and DRM-Next (current). The result is the same: it still can't boot with my Radeon HD 2600 XT :( Can you attach a copy of your vbios? (as root) (use lspci to get the bus id) cd /sys/bus/pci/devices/pci bus id echo 1 rom cat rom /tmp/vbios.rom echo 0 rom Also, can you get a copy of the dmesg output from the driver after it loads? Try booting into a non-X runlevel without loading radeon (either blacklist it, or set radeon.modeset=0 on the kernel command line in grub) and then manually load it. E.g., modprobe -r radeon modprobe radeon modeset=1 dpm=1 If possible, try and do it over ssh from a second machine so you can still access it if you lose the display. -- 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 #98 from Eugene ken20...@ukr.net --- Created attachment 85079 -- https://bugs.freedesktop.org/attachment.cgi?id=85079action=edit Radeon HD2600XT vbios -- 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 fixes
On Sun, Sep 1, 2013 at 11:54 PM, Daniel Vetter dan...@ffwll.ch wrote: On Sat, Aug 31, 2013 at 04:02:16PM -0700, Linus Torvalds wrote: Hmm. I just updated my machine to a i7-4770S (kept everything else the same, just switched out motherboards), and now when my display goes to sleep, it seems to never come back. Sleep as in dpms off ($ xset dpms force off) or sleep as in system suspend? Just dpms off. Aside hsw hdmi ports support 300MHz dotclocks, but still only single-link. So I guess your dvi screen is still out of luck since it likely wants a dual-link dvi signal. But if you have a hdmi port it should work a bit better (hdmi pumped up the max dotclock a bit already a while ago ...). Well, with DP everything works without playing with refresh rates, and dpms off works too. So it's DVI-specific (I haven't tested an actual hdmi cable, I don't think I have any around), and it also happens even if I *don't* set odd refresh rates. But if others haven't seen it, it's probably not universal, I can't imagine that I'm the only one still using DVI (well, up until yesterday). This is a bog-standard micro-atx Intel motherboard: DH87RL with a i7-4770S CPU. Everything else seems to be just peachy. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68856] New: Rendering artefacts with Unvanquished
https://bugs.freedesktop.org/show_bug.cgi?id=68856 Priority: medium Bug ID: 68856 Assignee: dri-devel@lists.freedesktop.org Summary: Rendering artefacts with Unvanquished Severity: normal Classification: Unclassified OS: Linux (All) Reporter: audi...@live.fr Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 85083 -- https://bugs.freedesktop.org/attachment.cgi?id=85083action=edit In Game I have some artefacts when I try to play on Unvanquished (last build). I use the Oibaf PPA wich provided Mesa 9.3.0-devel on an RS880. This is the log when I launch the game: Unvanquished 0.19.0 x86_64 Sep 1 2013 +set fs_libpath /usr/lib/games/unvanquished +set fs_basepath /var/games/unvanquished --enable-debug Have SSE support pk3: /var/games/unvanquished/main/map-arachnid2-gpp.pk3 ( 67 files ) pk3: /var/games/unvanquished/main/map-atcshd-gpp2.pk3 ( 91 files ) pk3: /var/games/unvanquished/main/map-citadel.pk3 ( 143 files ) pk3: /var/games/unvanquished/main/map-cruz-b6.pk3 ( 130 files ) pk3: /var/games/unvanquished/main/map-Eden-b3.pk3 ( 111 files ) pk3: /var/games/unvanquished/main/map-karith-gpp.pk3 ( 118 files ) pk3: /var/games/unvanquished/main/map-methane-beta1.pk3 ( 196 files ) pk3: /var/games/unvanquished/main/map-nano.pk3 ( 108 files ) pk3: /var/games/unvanquished/main/map-nexus6-gpp.pk3 ( 151 files ) pk3: /var/games/unvanquished/main/map-niveus-gpp.pk3 ( 134 files ) pk3: /var/games/unvanquished/main/map-orion-beta2.pk3 ( 101 files ) pk3: /var/games/unvanquished/main/map-parpax-d02.pk3 ( 391 files ) pk3: /var/games/unvanquished/main/map-perseus-b3.pk3 ( 94 files ) pk3: /var/games/unvanquished/main/map-plat23-b10.pk3 ( 124 files ) pk3: /var/games/unvanquished/main/map-procyon-r1.pk3 ( 108 files ) pk3: /var/games/unvanquished/main/map-sirius.pk3 ( 134 files ) pk3: /var/games/unvanquished/main/map-spacetracks-r1.pk3 ( 207 files ) pk3: /var/games/unvanquished/main/map-station15-r1.pk3 ( 205 files ) pk3: /var/games/unvanquished/main/map-thunder-b3.pk3 ( 232 files ) pk3: /var/games/unvanquished/main/map-transit-gpp.pk3 ( 135 files ) pk3: /var/games/unvanquished/main/map-tremor-gpp.pk3 ( 47 files ) pk3: /var/games/unvanquished/main/map-UTCSfinal.pk3 ( 82 files ) pk3: /var/games/unvanquished/main/map-veddak-final.pk3 ( 294 files ) pk3: /var/games/unvanquished/main/map-wrecktify_b2.pk3 ( 13 files ) pk3: /var/games/unvanquished/main/map-yocto-b1a.pk3 ( 230 files ) pk3: /var/games/unvanquished/main/pak0.pk3 ( 1590 files ) pk3: /var/games/unvanquished/main/pak1.pk3 ( 981 files ) pk3: /var/games/unvanquished/main/pak2.pk3 ( 166 files ) pk3: /var/games/unvanquished/main/pak3.pk3 ( 117 files ) pk3: /var/games/unvanquished/main/pak4.pk3 ( 148 files ) pk3: /var/games/unvanquished/main/pak5.pk3 ( 143 files ) pk3: /var/games/unvanquished/main/pak6.pk3 ( 148 files ) pk3: /var/games/unvanquished/main/pak7.pk3 ( 268 files ) pk3: /var/games/unvanquished/main/pak8.pk3 ( 132 files ) pk3: /var/games/unvanquished/main/pak9.pk3 ( 122 files ) pk3: /var/games/unvanquished/main/pakA.pk3 ( 31 files ) pk3: /var/games/unvanquished/main/pakB.pk3 ( 226 files ) pk3: /var/games/unvanquished/main/pakC.pk3 ( 19 files ) pk3: /var/games/unvanquished/main/pakD.pk3 ( 140 files ) pk3: /var/games/unvanquished/main/pakE.pk3 ( 20 files ) pk3: /var/games/unvanquished/main/pakF.pk3 ( 70 files ) pk3: /var/games/unvanquished/main/pakG.pk3 ( 227 files ) pk3: /var/games/unvanquished/main/pakH.pk3 ( 185 files ) pk3: /var/games/unvanquished/main/pakI.pk3 ( 125 files ) pk3: /var/games/unvanquished/main/vms-0.11.0.pk3 ( 8 files ) pk3: /var/games/unvanquished/main/vms-0.19.0.pk3 ( 3 files ) FS_AddGameDirectory(/var/games/unvanquished, main) found 46 .pk3 and 0 .pk3dir FS_AddGameDirectory(/usr/lib/games/unvanquished, main) found 0 .pk3 and 0 .pk3dir FS_AddGameDirectory(/home/jeremy/.Unvanquished, main) found 0 .pk3 and 0 .pk3dir Loaded 7 languages execing default.cfg execing profiles/Tankypon/autogen.cfg execing profiles/Tankypon/keybindings.cfg couldn't exec profiles/Tankypon/autoexec.cfg Définir la langue comme French Impossible de lire conhistory. - Initialisation du client - - Initialisation du client complète - - Initialisation du moteur de rendu - Loading /usr/lib/games/unvanquished/librendererGL3.so…done Appel de GetRefAPI… SDL_Init( SDL_INIT_VIDEO )... SDL using driver x11 Initializing OpenGL display Estimated display aspect: 1.779 ...setting mode -1: 1366 768 Using 8/8/8 Color bits, 24 depth, 8 stencil display. Using GLEW 1.8.0 Using enhanced (GL3) Renderer in GL 2.x mode... Available modes: '1280x720 1366x768 848x480 720x480 1152x768 640x480 800x600
[Bug 68856] Rendering artefacts with Unvanquished
https://bugs.freedesktop.org/show_bug.cgi?id=68856 audi...@live.fr changed: What|Removed |Added Attachment #85083|text/plain |image/png 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
[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 #99 from Eugene ken20...@ukr.net --- Can you attach a copy of your vbios? (as root) (use lspci to get the bus id) cd /sys/bus/pci/devices/pci bus id echo 1 rom cat rom /tmp/vbios.rom echo 0 rom Yes, here it is, in attachment. Also, can you get a copy of the dmesg output from the driver after it loads? Try booting into a non-X runlevel without loading radeon (either blacklist it, or set radeon.modeset=0 on the kernel command line in grub) and then manually load it. E.g., modprobe -r radeon modprobe radeon modeset=1 dpm=1 I'm sorry I don't understand fully how to do this. If possible, try and do it over ssh from a second machine so you can still access it if you lose the display. Also there is no possibility to connect to my pc through ssh. -- 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 68857] New: SNU OpenCL NAS Parallel Benchmarks don't work
https://bugs.freedesktop.org/show_bug.cgi?id=68857 Priority: medium Bug ID: 68857 Assignee: dri-devel@lists.freedesktop.org Summary: SNU OpenCL NAS Parallel Benchmarks don't work Severity: normal Classification: Unclassified OS: Linux (All) Reporter: n...@ferrus.net Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/DRI/R600 Product: Mesa None of the benchmarks in the SNU OpenCL NAS Parallel Benchmarks are working. They're available from http://aces.snu.ac.kr/Center_for_Manycore_Programming/SNU_NPB_Suite.html I've got a Radeon 5830 and have installed Mesa from git using the instructions at http://dri.freedesktop.org/wiki/GalliumCompute/ Most of the benchmarks fail at Running pass 'AMDGPU DAG-DAG Pattern Instruction Selection' on function The FFT benchmark fails at error: parameter may not be qualified with an address space I do have some other test cases that are working for me, including the ones from http://cgit.freedesktop.org/~tstellar/opencl-example/ -- 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 68857] SNU OpenCL NAS Parallel Benchmarks don't work
https://bugs.freedesktop.org/show_bug.cgi?id=68857 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Component|Drivers/DRI/R600|Drivers/Gallium/r600 -- 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/radeon/dpm: implement force performance levels for rs780 (v2)
On Sun, Sep 1, 2013 at 1:34 PM, Anthoine Bourgeois
anthoine.bourge...@gmail.com wrote:
Allows you to limit the selected power levels via sysfs.
Force the feedback divider to select a power level.
v2: fix checking in rs780_force_fbdiv,
drop a duplicate divider structure in rs780_dpm_force_performance_level,
Force the voltage level too.
Signed-off-by: Anthoine Bourgeois anthoine.bourge...@gmail.com
Patch looks good. Thanks for doing this. I'll add it to my queue.
Alex
---
drivers/gpu/drm/radeon/radeon_asic.c | 1 +
drivers/gpu/drm/radeon/radeon_asic.h | 2 +
drivers/gpu/drm/radeon/rs780_dpm.c | 89
++--
3 files changed, 77 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index f8f8b31..437d357 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -1272,6 +1272,7 @@ static struct radeon_asic rs780_asic = {
.get_mclk = rs780_dpm_get_mclk,
.print_power_state = rs780_dpm_print_power_state,
.debugfs_print_current_performance_level =
rs780_dpm_debugfs_print_current_performance_level,
+ .force_performance_level =
rs780_dpm_force_performance_level,
},
.pflip = {
.pre_page_flip = rs600_pre_page_flip,
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index 3d61d5a..0d81dbd 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -437,6 +437,8 @@ void rs780_dpm_print_power_state(struct radeon_device
*rdev,
struct radeon_ps *ps);
void rs780_dpm_debugfs_print_current_performance_level(struct radeon_device
*rdev,
struct seq_file *m);
+int rs780_dpm_force_performance_level(struct radeon_device *rdev,
+ enum radeon_dpm_forced_level level);
/* uvd */
int r600_uvd_init(struct radeon_device *rdev);
diff --git a/drivers/gpu/drm/radeon/rs780_dpm.c
b/drivers/gpu/drm/radeon/rs780_dpm.c
index d1a1ce7..625d6ea 100644
--- a/drivers/gpu/drm/radeon/rs780_dpm.c
+++ b/drivers/gpu/drm/radeon/rs780_dpm.c
@@ -376,9 +376,8 @@ static void rs780_disable_vbios_powersaving(struct
radeon_device *rdev)
WREG32_P(CG_INTGFX_MISC, 0, ~0xFFF0);
}
-static void rs780_force_voltage_to_high(struct radeon_device *rdev)
+static void rs780_force_voltage(struct radeon_device *rdev, u16 voltage)
{
- struct igp_power_info *pi = rs780_get_pi(rdev);
struct igp_ps *current_state =
rs780_get_ps(rdev-pm.dpm.current_ps);
if ((current_state-max_voltage == RS780_VDDC_LEVEL_HIGH)
@@ -390,7 +389,7 @@ static void rs780_force_voltage_to_high(struct
radeon_device *rdev)
udelay(1);
WREG32_P(FVTHROT_PWM_CTRL_REG0,
-STARTING_PWM_HIGHTIME(pi-max_voltage),
+STARTING_PWM_HIGHTIME(voltage),
~STARTING_PWM_HIGHTIME_MASK);
WREG32_P(FVTHROT_PWM_CTRL_REG0,
@@ -404,6 +403,26 @@ static void rs780_force_voltage_to_high(struct
radeon_device *rdev)
WREG32_P(GFX_MACRO_BYPASS_CNTL, 0, ~SPLL_BYPASS_CNTL);
}
+static void rs780_force_fbdiv(struct radeon_device *rdev, u32 fb_div)
+{
+ struct igp_ps *current_state =
rs780_get_ps(rdev-pm.dpm.current_ps);
+
+ if (current_state-sclk_low == current_state-sclk_high)
+ return;
+
+ WREG32_P(GFX_MACRO_BYPASS_CNTL, SPLL_BYPASS_CNTL,
~SPLL_BYPASS_CNTL);
+
+ WREG32_P(FVTHROT_FBDIV_REG2, FORCED_FEEDBACK_DIV(fb_div),
+~FORCED_FEEDBACK_DIV_MASK);
+ WREG32_P(FVTHROT_FBDIV_REG1, STARTING_FEEDBACK_DIV(fb_div),
+~STARTING_FEEDBACK_DIV_MASK);
+ WREG32_P(FVTHROT_FBDIV_REG1, FORCE_FEEDBACK_DIV,
~FORCE_FEEDBACK_DIV);
+
+ udelay(100);
+
+ WREG32_P(GFX_MACRO_BYPASS_CNTL, 0, ~SPLL_BYPASS_CNTL);
+}
+
static int rs780_set_engine_clock_scaling(struct radeon_device *rdev,
struct radeon_ps *new_ps,
struct radeon_ps *old_ps)
@@ -432,17 +451,7 @@ static int rs780_set_engine_clock_scaling(struct
radeon_device *rdev,
if (ret)
return ret;
- WREG32_P(GFX_MACRO_BYPASS_CNTL, SPLL_BYPASS_CNTL,
~SPLL_BYPASS_CNTL);
-
- WREG32_P(FVTHROT_FBDIV_REG2,
FORCED_FEEDBACK_DIV(max_dividers.fb_div),
-~FORCED_FEEDBACK_DIV_MASK);
- WREG32_P(FVTHROT_FBDIV_REG1,
STARTING_FEEDBACK_DIV(max_dividers.fb_div),
-~STARTING_FEEDBACK_DIV_MASK);
- WREG32_P(FVTHROT_FBDIV_REG1, FORCE_FEEDBACK_DIV,
~FORCE_FEEDBACK_DIV);
-
- udelay(100);
-
- WREG32_P(GFX_MACRO_BYPASS_CNTL, 0, ~SPLL_BYPASS_CNTL);
+ rs780_force_fbdiv(rdev, max_dividers.fb_div);
if
[Bug 60791] Display corruption with Radeon driver during boot and on desktop
https://bugzilla.kernel.org/show_bug.cgi?id=60791 --- Comment #16 from Brian Hall hal...@gmail.com --- Cannot reproduce the problem by modifying drivers/gpu/drm/radeon/atom.c, apparently my bisect was incorrect. Problem does not occur even if I undo all the code changes for that commit. I did reconfirm the basic problem still occurs with 3.10.5 but not 3.10.4. Will attempt to re-bisect at the next opportunity. -- 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 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #9 from Alexandre Demers alexandre.f.dem...@gmail.com --- Still the same with kernel 3.11.0. Tried with VM=0, aspm=0, disconnected my UPC (just in case it was something with a battery state or something similar), tried Gnome 3 and XFCE, all the same. The only thing working for now is to set dpm=0 or to force ret=1 in ni_dpm_set_power_state when checking what ni_restrict_performance_levels_before_switch answered. However, I don't know if the problem is with ni_dpm_set_power_state or with something executed after, so I'll play in there. -- 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 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1
https://bugs.freedesktop.org/show_bug.cgi?id=68235 --- Comment #10 from Alexandre Demers alexandre.f.dem...@gmail.com --- If ret=1 just after ni_restrict_performance_levels_before_switch(), ni_dpm_set_power_state() doesn't go any further and there is no hang. So, it seems like if the problem is not with ni_restrict_performance_levels_before_switch() but instead with a combination of some sort. -- 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/RFC v3 02/19] video: Add Common Display Framework core
Hi, On 09/08/13 20:14, Laurent Pinchart wrote: The Common Display Framework (CDF) splits display devices in entities that interact through an abstract API. Each entity is managed by its own driver independently of the other entities, with the framework orchestrating interactions. This commit introduces the CDF core with entity (un)registration and core control operations support. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com The media entity code used in CDF needs (at least) MEDIA_CAMERA_SUPPORT and MEDIA_CONTROLLER to be enabled in the kernel config. These are not selected/depended upon currently. And while MEDIA_CONTROLLER makes sense, MEDIA_CAMERA_SUPPORT doesn't, so maybe there's some tuning needed for the media code. Tomi signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC v3 00/19] Common Display Framework
On 09/08/13 20:14, Laurent Pinchart wrote: Hi everybody, Here's the third RFC of the Common Display Framework. I won't repeat all the background information from the versions one and two here, you can read it at http://lwn.net/Articles/512363/ and http://lwn.net/Articles/526965/. This RFC isn't final. Given the high interest in CDF and the urgent tasks that kept delaying the next version of the patch set, I've decided to release v3 before completing all parts of the implementation. Known missing items are - documentation: kerneldoc and this cover letter should provide basic information, more extensive documentation will likely make it to v4. - pipeline configuration and control: generic code to configure and control display pipelines (in a nutshell, translating high-level mode setting and DPMS calls to low-level entity operations) is missing. Video and stream control operations have been carried over from v2, but will need to be revised for v4. - DSI support: I still have no DSI hardware I can easily test the code on. Special thanks go to - Renesas for inviting me to LinuxCon Japan 2013 where I had the opportunity to validate the CDF v3 concepts with Alexandre Courbot (NVidia) and Tomasz Figa (Samsung). - Tomi Valkeinen (TI) for taking the time to deeply brainstorm v3 with me. - Linaro for inviting me to Linaro Connect Europe 2013, the discussions we had there greatly helped moving CDF forward. - And of course all the developers who showed interest in CDF and spent time sharing ideas, reviewing patches and testing code. I have to confess I was a bit lost and discouraged after all the CDF-related meetings during which we have discussed how to move from v2 to v3. With every meeting I was hoping to run the implementation through use cases of various interesting parties and narrow down the scope of the huge fuzzy beast that CDF was. With every meeting the scope actually broadened, with no clear path at sight anywhere. Earlier this year I was about to drop one of the requirements on which I had based CDF v2: sharing drivers between DRM/KMS and V4L2. With only two HDMI transmitters as use cases for that feature (with only out-of-tree drivers so far), I just thought the involved completely wasn't worth it and that I should implement CDF v3 as a DRM/KMS-only helper framework. However, a seemingly unrelated discussion with Xilinx developers showed me that hybrid SoC-FPGA platforms such as the Xilinx Zynq 7000 have a larger library of IP cores that can be used in camera capture pipelines and in display pipelines. The two use cases suddenly became tens or even hundreds of use cases that I couldn't ignore anymore. Should this be Common Video Framework then? ;) CDF v3 is thus userspace API agnostic. It isn't tied to DRM/KMS or V4L2 and can be used by any kernel subsystem, potentially including FBDEV (although I won't personally wrote FBDEV support code, as I've already advocated for FBDEV to be deprecated). The code you are about to read is based on the concept of display entities introduced in v2. Diagrams related to the explanations below are available at http://ideasonboard.org/media/cdf/20130709-lce-cdf.pdf. Display Entities A display entity abstracts any hardware block that sources, processes or sinks display-related video streams. It offers an abstract API, implemented by display entity drivers, that is used by master drivers (such as the main display driver) to query, configure and control display pipelines. Display entities are connected to at least one video data bus, and optionally to a control bus. The video data busses carry display-related video data out of sources (such as a CRTC in a display controller) to sinks (such as a panel or a monitor), optionally going through transmitters, encoders, decoders, bridges or other similar devices. A CRTC or a panel will usually be connected to a single data bus, while an encoder or a transmitter will be connected to two data busses. The simple linear display pipelines we find in most embedded platforms at the moment are expected to grow more complex with time. CDF needs to accomodate those needs from the start to be, if not future-proof, at least present-proof at the time it will get merged in to mainline. For this reason display entities have data ports through which video streams flow in or out, with link objects representing the connections between those ports. A typical entity in a linear display pipeline will have one (for video source and video sink entities such as CRTCs or panels) or two ports (for video processing entities such as encoders), but more ports are allowed, and entities can be linked in complex non-linear pipelines. Readers might think that this model if extremely similar to the media controller graph model. They would be right, and given my background this is most probably not a coincidence.
Re: [PATCH] drm/i2c: Fix broken TDA998x audio (was: Re: [PATCH v2 5/8] drm/i2c: tda998x: add video and audio input configuration)
On Wed, Aug 14, 2013 at 09:43:30PM +0200, Sebastian Hesselbarth wrote:
From: Russell King rmk+ker...@arm.linux.org.uk
This patch adds tda998x specific parameters to allow it to be configured
for different boards using it. Also, this implements rudimentary audio
support for S/PDIF attached controllers.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Tested-by: Darren Etheridge detheri...@ti.com
---
It looks like there's been a bug introduced in this patch (which wasn't
in my original).
@@ -445,8 +681,7 @@ tda998x_encoder_dpms(struct drm_encoder *encoder, int
mode)
switch (mode) {
case DRM_MODE_DPMS_ON:
- /* enable audio and video ports */
- reg_write(encoder, REG_ENA_AP, 0xff);
+ /* enable video ports, audio will be enabled later */
reg_write(encoder, REG_ENA_VP_0, 0xff);
reg_write(encoder, REG_ENA_VP_1, 0xff);
reg_write(encoder, REG_ENA_VP_2, 0xff);
I also disabled the writing to REG_ENA_AP in the DPMS off path as well,
which clears this register.
That seems to be missing from this patch, and it means that when the
display is placed into DPMS-off mode, the audio inputs are disabled,
never to be re-enabled. There is no need to disable the audio input
in DPMS-off mode.
8=
From: Russell King rmk+ker...@arm.linux.org.uk
Subject: [PATCH] drm/i2c: Fix broken TDA998x audio
In patch drm/i2c: tda998x: add video and audio input configuration in
its original version, disabling the audio input port was removed. The
version which was submitted for merging had this change deleted, which
results in audio being non-functional. Fix this by removing the write.
While here, update the comment too.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
drivers/gpu/drm/i2c/tda998x_drv.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 5742cfc..59878af 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -705,8 +705,7 @@ tda998x_encoder_dpms(struct drm_encoder *encoder, int mode)
reg_write(encoder, REG_VIP_CNTRL_2, priv-vip_cntrl_2);
break;
case DRM_MODE_DPMS_OFF:
- /* disable audio and video ports */
- reg_write(encoder, REG_ENA_AP, 0x00);
+ /* disable video ports */
reg_write(encoder, REG_ENA_VP_0, 0x00);
reg_write(encoder, REG_ENA_VP_1, 0x00);
reg_write(encoder, REG_ENA_VP_2, 0x00);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 1/3] drm: Add panel support
Hi Thierry,
On 08/31/2013 12:25 AM, Thierry Reding wrote:
Add a very simple framework to register and lookup panels. Panel drivers
can initialize a DRM panel and register it with the framework, allowing
them to be retrieved and used by display drivers. Currently only support
for DPMS and obtaining panel modes is provided. However it should be
sufficient to enable a large number of panels. The framework should also
be easily extensible to support more sophisticated kinds of panels such
as DSI.
The framework hasn't been tied into the DRM core, even though it should
be easily possible to do so if that's what we want. In the current
implementation, display drivers can simple make use of it to retrieve a
panel, obtain its modes and control its DPMS mode.
Note that this is currently only tested on systems that boot from a
device tree. No glue code has been written yet for systems that use
platform data, but it should be easy to add.
Really like this. It's simple and to the point, and much needed since I
guess many vendors have come with their own custom solution to handle
panels. Do you know if it would be possible to convert these
implementations to use your framework instead and consolidate the code
around it?
Eventually this might be superseeded by the CDF, but if this happens it
should not be too hard to convert the code, and we need something to use
panels conveniently in the meantime.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_panel.c | 96 +++
drivers/gpu/drm/panel/Kconfig | 4 ++
include/drm/drm_panel.h | 65 +
5 files changed, 168 insertions(+)
create mode 100644 drivers/gpu/drm/drm_panel.c
create mode 100644 drivers/gpu/drm/panel/Kconfig
create mode 100644 include/drm/drm_panel.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 95d..b4d8402 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -236,3 +236,5 @@ source drivers/gpu/drm/tilcdc/Kconfig
source drivers/gpu/drm/qxl/Kconfig
source drivers/gpu/drm/msm/Kconfig
+
+source drivers/gpu/drm/panel/Kconfig
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f089adf..9b009c7 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,6 +18,7 @@ drm-y :=drm_auth.o drm_buffer.o drm_bufs.o
drm_cache.o \
drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
drm-$(CONFIG_PCI) += ati_pcigart.o
+drm-$(CONFIG_DRM_PANEL) += drm_panel.o
drm-usb-y := drm_usb.o
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
new file mode 100644
index 000..ff6e459
--- /dev/null
+++ b/drivers/gpu/drm/drm_panel.c
@@ -0,0 +1,96 @@
+/*
+ * Copyright (C) 2013, NVIDIA Corporation. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sub license,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include linux/err.h
+#include linux/export.h
+
+#include drm/drm_crtc.h
+#include drm/drm_panel.h
+
+static DEFINE_MUTEX(panel_lock);
+static LIST_HEAD(panel_list);
+
+void drm_panel_init(struct drm_panel *panel)
+{
+ INIT_LIST_HEAD(panel-list);
+}
+EXPORT_SYMBOL(drm_panel_init);
+
+int drm_panel_add(struct drm_panel *panel)
+{
+ mutex_lock(panel_lock);
+ list_add_tail(panel-list, panel_list);
+ mutex_unlock(panel_lock);
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_panel_add);
+
+void drm_panel_remove(struct drm_panel *panel)
+{
+ mutex_lock(panel_lock);
+ list_del_init(panel-list);
+ mutex_unlock(panel_lock);
+}
+EXPORT_SYMBOL(drm_panel_remove);
+
+int drm_panel_attach(struct drm_panel *panel, struct drm_connector *connector)
+{
+ if (panel-connector)
+ return -EBUSY;
+
+ panel-connector = connector;
+ panel-drm =
