[PATCH] DRM: TTM: Fix memory leak issue in ttm_agp_tt_create().
From: Jeyaraman R
This patch adds kfree() in ttm_agp_tt_create() to avoide the
memory leak, without this there is a chance of memory leak in
ttm_tt_init() fail case.
Signed-off-by: Jeyaraman R
Signed-off-by: Manjunath Goudar
Cc: David Airlie
Cc: "Paul E. McKenney"
Cc: David Howells
Cc: Thomas Gleixner
Cc: Dave Jones
Cc: Dave Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
drivers/gpu/drm/ttm/ttm_agp_backend.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
b/drivers/gpu/drm/ttm/ttm_agp_backend.c
index 3302f99..764be36 100644
--- a/drivers/gpu/drm/ttm/ttm_agp_backend.c
+++ b/drivers/gpu/drm/ttm/ttm_agp_backend.c
@@ -126,6 +126,7 @@ struct ttm_tt *ttm_agp_tt_create(struct ttm_bo_device *bdev,
agp_be->ttm.func = &ttm_agp_func;
if (ttm_tt_init(&agp_be->ttm, bdev, size, page_flags, dummy_read_page))
{
+ kfree(agp_be);
return NULL;
}
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60182] X.Org Server terminate when I close video player
https://bugs.freedesktop.org/show_bug.cgi?id=60182 --- Comment #19 from Weber K. --- Hi! This error is happening here also... Slackware64 linux on AMD Phenom II 1055T, with XFX Radeon HD6850 and open source drivers radeon. The X server crash after second close of programs... The first execution goes fine... Then second crashes... When mplayer -vo gl2 exits or when I try to execute my own Open GL programs using SDL calls. The error dont occur with the game warzone 2100, with I think is strange. Ill try gdb the X server... If I succeed Ill post the logs. Thanks! [ 9852.952] (WW) RADEON(0): Attempted to destroy previously destroyed buffer. This is a programming error [ 9852.952] [ 9852.952] Backtrace: [ 9852.953] 0: /usr/bin/X (xorg_backtrace+0x36) [0x55d526] [ 9852.953] 1: /usr/bin/X (0x40+0x160ee9) [0x560ee9] [ 9852.953] 2: /lib64/libpthread.so.0 (0x7fc155cf6000+0xf4e0) [0x7fc155d054e0] [ 9852.953] 3: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7fc152ce1000+0xd12e6) [0x7fc152db22e6] [ 9852.953] 4: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7fc152ce1000+0xd1c19) [0x7fc152db2c19] [ 9852.953] 5: /usr/bin/X (_CallCallbacks+0x34) [0x439434] [ 9852.953] 6: /usr/bin/X (CloseDownClient+0x52) [0x434212] [ 9852.953] 7: /usr/bin/X (0x40+0x34d95) [0x434d95] [ 9852.953] 8: /usr/bin/X (0x40+0x23f05) [0x423f05] [ 9852.953] 9: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7fc1540cda95] [ 9852.953] 10: /usr/bin/X (0x40+0x241dd) [0x4241dd] [ 9852.953] [ 9852.953] Segmentation fault at address 0x18 [ 9852.953] Fatal server error: [ 9852.953] Caught signal 11 (Segmentation fault). Server aborting [ 9852.953] [ 9852.953] Please consult the The X.Org Foundation support at http://wiki.x.org for 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
Re: [PATCH v2 3/6] host1x: hdmi: Enable Vdd earlier for hotplug/DDC
On 09/04/2013 04:03 PM, Mikko Perttunen wrote: > 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. Ah OK, then this code change makes sense. It'd be useful to put what you just wrote into the binding doc. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/6] host1x: hdmi: Detect whether display is connected with HDMI or DVI
On Wed, Sep 04, 2013 at 12:40:58PM -0600, Stephen Warren wrote: > On 08/28/2013 09:48 AM, Mikko Perttunen wrote: > > Use EDID data to determine whether the display supports HDMI or just DVI. > > This used to be hardcoded to be HDMI, which broke support for DVI displays > > that couldn't understand the interspersed audio/other data. > > > > If the EDID data isn't available, default to DVI, which should be a safer > > choice. > > This seems like a bug-fix that might even be worth CC: stable? Possibly. The patch reaches deeply into some DRM structures, which I'd like to avoid. I'll have another look to see if it can be done in a slightly different way. Thierry pgp3LgC3YjCdj.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/6] host1x: hdmi: Add Tegra114 support
On Wed, Sep 04, 2013 at 12:39:59PM -0600, Stephen Warren wrote:
> On 08/28/2013 09:48 AM, Mikko Perttunen wrote:
> > Add Tegra114 TMDS configuration, add new peak_current field and
> > use new place for drive current override bit on Tegra114 platform.
>
> > diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
>
> > static struct of_device_id host1x_of_match[] = {
> > + { .compatible = "nvidia,tegra114-host1x", .data = &host1x01_info, },
>
> We should add that value to the host1x DT binding documentation.
That should be superseeded by a patch from my Tegra114 DSI series. Note
that Tegra114 also uses a slightly updated version of host1x.
> > diff --git a/drivers/gpu/host1x/drm/hdmi.c b/drivers/gpu/host1x/drm/hdmi.c
>
> > static const struct tegra_hdmi_audio_config *
> > tegra_hdmi_get_audio_config(unsigned int audio_freq, unsigned int pclk)
> > {
> > @@ -593,8 +673,20 @@ static void tegra_hdmi_setup_tmds(struct tegra_hdmi
> > *hdmi,
> > tegra_hdmi_writel(hdmi, tmds->pll1, HDMI_NV_PDISP_SOR_PLL1);
> > tegra_hdmi_writel(hdmi, tmds->pe_current, HDMI_NV_PDISP_PE_CURRENT);
> >
> > - value = tmds->drive_current | DRIVE_CURRENT_FUSE_OVERRIDE;
> > - tegra_hdmi_writel(hdmi, value, HDMI_NV_PDISP_SOR_LANE_DRIVE_CURRENT);
> > + if (of_device_is_compatible(hdmi->dev->of_node,
> > + "nvidia,tegra114-hdmi")) {
>
> We shouldn't do this at run-time. Rather, set tegra_hdmi_of_match[]'s
> .data field to a structure that represents the various features of the
> HW, and then make this code conditional upon a feature flag in that
> structure.
I'll take a look at how this could be done. There are a few other places
where we do this check at runtime, so that should be converted at the
same time.
Thierry
pgppfikJd59FS.pgp
Description: PGP signature
___
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 #106 from Alex Deucher --- Assuming that works you should have the dmesg.log in the root user directory that you can attach here. -- 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 #105 from Alex Deucher --- (In reply to comment #104) > with > > linux /boot/ radeon.modeset=0 1 > it seems it's booting but I can't see command line - only black screen or > text line: "kernel booting... bla-bla-bla" and also no command line. Trying > to enter anything gives nothing. But if a enter "reboot" and press Enter it > restarts. So it gets the commands but I can't see any display output. can you blindly type: modprobe -r radeon modprobe radeon modeset=1 dpm=1 dmesg > dmesg.log reboot -- 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 #104 from Eugene --- (In reply to comment #103) > (In reply to comment #102) > > If you could explain me where is kernel command line (when I'm seeing GRUB > > menu push "e" or "c"; and if "c" what to do after I entered radeon.modeset=0 > > in there?), I would try it. I'm just a newbie using kubuntu a few months. > > in the grub menu select the kernel you want to boot and press 'e' then move > to the end of the line that starts: > linux /boot/ > and append the options to the end of that line. e.g., >linux /boot/ radeon.modeset=0 1 > The '1' means boot into single user mode rather than X. > > Also, if you haven't already, try disabling aspm: >linux /boot/ radeon.aspm=0 radeon.dpm=1 Thanks for your explanations. Recently tried it. But...: with > linux /boot/ radeon.aspm=0 radeon.dpm=1 still blank screen after starting kernel loading with > linux /boot/ radeon.modeset=0 1 it seems it's booting but I can't see command line - only black screen or text line: "kernel booting... bla-bla-bla" and also no command line. Trying to enter anything gives nothing. But if a enter "reboot" and press Enter it restarts. So it gets the commands but I can't see any display 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 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 #103 from Alex Deucher --- (In reply to comment #102) > If you could explain me where is kernel command line (when I'm seeing GRUB > menu push "e" or "c"; and if "c" what to do after I entered radeon.modeset=0 > in there?), I would try it. I'm just a newbie using kubuntu a few months. in the grub menu select the kernel you want to boot and press 'e' then move to the end of the line that starts: linux /boot/ and append the options to the end of that line. e.g., linux /boot/ radeon.modeset=0 1 The '1' means boot into single user mode rather than X. Also, if you haven't already, try disabling aspm: linux /boot/ radeon.aspm=0 radeon.dpm=1 -- 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 #102 from Eugene --- If you could explain me where is kernel command line (when I'm seeing GRUB menu push "e" or "c"; and if "c" what to do after I entered radeon.modeset=0 in there?), I would try it. I'm just a newbie using kubuntu a few months. -- 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 v2 5/6] ARM: tegra: Add host1x, DC and HDMI to Tegra114 device tree
On 08/28/2013 09:48 AM, Mikko Perttunen wrote: > Add host1x, DC (display controller) and HDMI devices to Tegra114 > device tree. Patches 5 and 6 should be sent separately to the Tegra maintainer (me) to be taken through the Tegra tree. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/6] clk: tegra114: Initialize clocks needed for HDMI
On 08/28/2013 09:48 AM, Mikko Perttunen wrote: > Add host1x, disp1 and disp2 clocks to the clock initialization table. > These clocks are required for HDMI support. This patch should be sent to Mike Turquette so it can be taken through the clock tree. ___ 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 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. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/6] host1x: hdmi: Detect whether display is connected with HDMI or DVI
On 08/28/2013 09:48 AM, Mikko Perttunen wrote: > Use EDID data to determine whether the display supports HDMI or just DVI. > This used to be hardcoded to be HDMI, which broke support for DVI displays > that couldn't understand the interspersed audio/other data. > > If the EDID data isn't available, default to DVI, which should be a safer > choice. This seems like a bug-fix that might even be worth CC: stable? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/6] host1x: hdmi: Add Tegra114 support
On 08/28/2013 09:48 AM, Mikko Perttunen wrote:
> Add Tegra114 TMDS configuration, add new peak_current field and
> use new place for drive current override bit on Tegra114 platform.
> diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
> static struct of_device_id host1x_of_match[] = {
> + { .compatible = "nvidia,tegra114-host1x", .data = &host1x01_info, },
We should add that value to the host1x DT binding documentation.
> diff --git a/drivers/gpu/host1x/drm/hdmi.c b/drivers/gpu/host1x/drm/hdmi.c
> static const struct tegra_hdmi_audio_config *
> tegra_hdmi_get_audio_config(unsigned int audio_freq, unsigned int pclk)
> {
> @@ -593,8 +673,20 @@ static void tegra_hdmi_setup_tmds(struct tegra_hdmi
> *hdmi,
> tegra_hdmi_writel(hdmi, tmds->pll1, HDMI_NV_PDISP_SOR_PLL1);
> tegra_hdmi_writel(hdmi, tmds->pe_current, HDMI_NV_PDISP_PE_CURRENT);
>
> - value = tmds->drive_current | DRIVE_CURRENT_FUSE_OVERRIDE;
> - tegra_hdmi_writel(hdmi, value, HDMI_NV_PDISP_SOR_LANE_DRIVE_CURRENT);
> + if (of_device_is_compatible(hdmi->dev->of_node,
> + "nvidia,tegra114-hdmi")) {
We shouldn't do this at run-time. Rather, set tegra_hdmi_of_match[]'s
.data field to a structure that represents the various features of the
HW, and then make this code conditional upon a feature flag in that
structure.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60827] X under radeon driver crashes after resuming from hibernation
https://bugzilla.kernel.org/show_bug.cgi?id=60827 --- Comment #5 from Alex Deucher --- Make sure your kernel has this patch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=022374c02e357ac82e98dd2689fb2efe05723d69 make sure you power off the system completely between kernel tests. -- 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/RFC v3 06/19] video: display: OF support
Hi Laurent,
Am Samstag, den 10.08.2013, 01:03 +0200 schrieb Laurent Pinchart:
> Extend the notifier with DT node matching support, and add helper functions to
> build the notifier and link entities based on a graph representation in
> DT.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/video/display/display-core.c | 334
> +++
> drivers/video/display/display-notifier.c | 187 +
> include/video/display.h | 45 +
> 3 files changed, 566 insertions(+)
>
> diff --git a/drivers/video/display/display-core.c
> b/drivers/video/display/display-core.c
> index c3b47d3..328ead7 100644
> --- a/drivers/video/display/display-core.c
> +++ b/drivers/video/display/display-core.c
[...]
> @@ -420,6 +599,161 @@ int display_entity_link_graph(struct device *dev,
> struct list_head *entities)
> }
> EXPORT_SYMBOL_GPL(display_entity_link_graph);
>
> +#ifdef CONFIG_OF
> +
> +static int display_of_entity_link_entity(struct device *dev,
> + struct display_entity *entity,
> + struct list_head *entities,
> + struct display_entity *root)
> +{
> + u32 link_flags = MEDIA_LNK_FL_IMMUTABLE | MEDIA_LNK_FL_ENABLED;
> + const struct device_node *node = entity->dev->of_node;
the current device tree matching implementation only allows one display
entity per linux device. How about adding an of_node pointer to struct
display_entity directly and allow multiple display entity nodes below in
a single device node in the device tree?
lvds-encoder {
channel@0 {
port@0 {
lvds0_input: endpoint {
};
};
port@1 {
lvds0_output: endpoint {
};
};
};
channel@1 {
port@0 {
lvds1_input: endpoint {
};
};
lvds1: port@1 {
lvds1_output: endpoint {
};
};
};
};
> + struct media_entity *local = &entity->entity;
> + struct device_node *ep = NULL;
> + int ret = 0;
> +
> + dev_dbg(dev, "creating links for entity %s\n", local->name);
> +
> + while (1) {
> + struct media_entity *remote = NULL;
> + struct media_pad *remote_pad;
> + struct media_pad *local_pad;
> + struct display_of_link link;
> + struct display_entity *ent;
> + struct device_node *next;
> +
> + /* Get the next endpoint and parse its link. */
> + next = display_of_get_next_endpoint(node, ep);
> + if (next == NULL)
> + break;
> +
> + of_node_put(ep);
> + ep = next;
> +
> + dev_dbg(dev, "processing endpoint %s\n", ep->full_name);
> +
> + ret = display_of_parse_link(ep, &link);
> + if (ret < 0) {
> + dev_err(dev, "failed to parse link for %s\n",
> + ep->full_name);
> + continue;
> + }
> +
> + /* Skip source pads, they will be processed from the other end
> of
> + * the link.
> + */
> + if (link.local_port >= local->num_pads) {
> + dev_err(dev, "invalid port number %u on %s\n",
> + link.local_port, link.local_node->full_name);
> + display_of_put_link(&link);
> + ret = -EINVAL;
> + break;
> + }
> +
> + local_pad = &local->pads[link.local_port];
> +
> + if (local_pad->flags & MEDIA_PAD_FL_SOURCE) {
> + dev_dbg(dev, "skipping source port %s:%u\n",
> + link.local_node->full_name, link.local_port);
> + display_of_put_link(&link);
> + continue;
> + }
> +
> + /* Find the remote entity. If not found, just skip the link as
> + * it goes out of scope of the entities handled by the notifier.
> + */
> + list_for_each_entry(ent, entities, list) {
> + if (ent->dev->of_node == link.remote_node) {
> + remote = &ent->entity;
> + break;
> + }
> + }
> +
> + if (root->dev->of_node == link.remote_node)
> + remote = &root->entity;
> +
> + if (remote == NULL) {
> + dev_dbg(dev, "no entity found for %s\n",
> + link.remote_node->full_name);
> + display_of_put_link(&link);
> + continue;
> + }
> +
> + if (link.remo
[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.
https://bugs.freedesktop.org/show_bug.cgi?id=64201 --- Comment #44 from Aaron Watry --- I just retested on my CEDAR with fresh git mesa/llvm. bfgminer is still working correctly for 5+ minutes without a single lock-up on my machine. Kernel is 3.11 final with DPM enabled. The following are the only patches that I have applied that are not yet upstream: LLVM: http://llvm-reviews.chandlerc.com/D1449 Mesa: http://lists.freedesktop.org/archives/mesa-dev/2013-August/043932.html http://lists.freedesktop.org/archives/mesa-dev/2013-August/043951.html http://lists.freedesktop.org/archives/mesa-dev/2013-August/043686.html You probably don't need that last patch, since it's targeted at Southern Islands. I honestly don't know if any of those patches would improve anything for you, but it's what I just successfully tested my evergreen with. You may need to do some slight re-basing of the first patch to take into account some of the recent changes in r600g. I do have my 6850 installed in an old Athlon 64 machine at home. I was already thinking of hooking that machine back up (it's in storage at the moment), so I may be able to re-test this on my 6850 in the next few days... assuming I don't get sidetracked by house maintenance issues. -- 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: signedness bug in kv_dpm.c
On Wed, Sep 4, 2013 at 5:31 AM, Dan Carpenter wrote:
> The problem here is that "unsigned i" is always greater than or equal to
> zero. These loops mostly have a second check for "(i == 0)" so only the
> last two are actually buggy. The rest is just cleanup.
>
> Bug 1: kv_force_dpm_highest() doesn't have an "(i == 0)" check so it's
> a potential forever loop.
>
> Bug 2: In kv_get_sleep_divider_id_from_clock() there is a typo and the
> test is reversed "<=" vs ">" so we never enter the loop. That means
> normally we return KV_MAX_DEEPSLEEP_DIVIDER_ID (5). The return value
> from here is saved in ->DeepSleepDivId and I wasn't able to determine
> how that is used. This is a static checker fix and I have not tested
> it.
>
> Signed-off-by: Dan Carpenter
Applied. thanks!
Alex
> ---
> I considered making "i" signed but that doesn't actually change anything
> because the tests have to end on zero anyway.
>
> diff --git a/drivers/gpu/drm/radeon/kv_dpm.c b/drivers/gpu/drm/radeon/kv_dpm.c
> index ecd6080..c499daf 100644
> --- a/drivers/gpu/drm/radeon/kv_dpm.c
> +++ b/drivers/gpu/drm/radeon/kv_dpm.c
> @@ -667,9 +667,8 @@ static int kv_program_bootup_state(struct radeon_device
> *rdev)
> &rdev->pm.dpm.dyn_state.vddc_dependency_on_sclk;
>
> if (table && table->count) {
> - for (i = pi->graphics_dpm_level_count - 1; i >= 0; i--) {
> - if ((table->entries[i].clk == pi->boot_pl.sclk) ||
> - (i == 0))
> + for (i = pi->graphics_dpm_level_count - 1; i > 0; i--) {
> + if (table->entries[i].clk == pi->boot_pl.sclk)
> break;
> }
>
> @@ -682,9 +681,8 @@ static int kv_program_bootup_state(struct radeon_device
> *rdev)
> if (table->num_max_dpm_entries == 0)
> return -EINVAL;
>
> - for (i = pi->graphics_dpm_level_count - 1; i >= 0; i--) {
> - if ((table->entries[i].sclk_frequency ==
> pi->boot_pl.sclk) ||
> - (i == 0))
> + for (i = pi->graphics_dpm_level_count - 1; i > 0; i--) {
> + if (table->entries[i].sclk_frequency ==
> pi->boot_pl.sclk)
> break;
> }
>
> @@ -1588,13 +1586,11 @@ static void kv_set_valid_clock_range(struct
> radeon_device *rdev,
> }
> }
>
> - for (i = pi->graphics_dpm_level_count - 1; i >= 0; i--) {
> - if ((table->entries[i].clk <=
> new_ps->levels[new_ps->num_levels -1].sclk) ||
> - (i == 0)) {
> - pi->highest_valid = i;
> + for (i = pi->graphics_dpm_level_count - 1; i > 0; i--) {
> + if (table->entries[i].clk <=
> new_ps->levels[new_ps->num_levels - 1].sclk)
> break;
> - }
> }
> + pi->highest_valid = i;
>
> if (pi->lowest_valid > pi->highest_valid) {
> if ((new_ps->levels[0].sclk -
> table->entries[pi->highest_valid].clk) >
> @@ -1615,14 +1611,12 @@ static void kv_set_valid_clock_range(struct
> radeon_device *rdev,
> }
> }
>
> - for (i = pi->graphics_dpm_level_count - 1; i >= 0; i--) {
> + for (i = pi->graphics_dpm_level_count - 1; i > 0; i--) {
> if (table->entries[i].sclk_frequency <=
> - new_ps->levels[new_ps->num_levels - 1].sclk ||
> - i == 0) {
> - pi->highest_valid = i;
> + new_ps->levels[new_ps->num_levels - 1].sclk)
> break;
> - }
> }
> + pi->highest_valid = i;
>
> if (pi->lowest_valid > pi->highest_valid) {
> if ((new_ps->levels[0].sclk -
> @@ -1871,7 +1865,7 @@ static int kv_force_dpm_highest(struct radeon_device
> *rdev)
> if (ret)
> return ret;
>
> - for (i = SMU7_MAX_LEVELS_GRAPHICS - 1; i >= 0; i--) {
> + for (i = SMU7_MAX_LEVELS_GRAPHICS - 1; i > 0; i--) {
> if (enable_mask & (1 << i))
> break;
> }
> @@ -1911,9 +1905,9 @@ static u8 kv_get_sleep_divider_id_from_clock(struct
> radeon_device *rdev,
> if (!pi->caps_sclk_ds)
> return 0;
>
> - for (i = KV_MAX_DEEPSLEEP_DIVIDER_ID; i <= 0; i--) {
> + for (i = KV_MAX_DEEPSLEEP_DIVIDER_ID; i > 0; i--) {
> temp = sclk / sumo_get_sleep_divider_from_id(i);
> - if ((temp >= min) || (i == 0))
> + if (temp >= min)
> break;
> }
>
> ___
> dri-devel m
Re: [PATCH v4 0/6] SimpleDRM Driver
Hi On Sun, Sep 1, 2013 at 3:36 PM, David Herrmann wrote: > Hi > > With the upcoming 3.12 merge-window, I thought people might find themselves > with > nothing to do, so here's a new SimpleDRM series. Comments welcome! > > This depends on the tip/x86/fb series in the x86-tip tree: > http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=x86/fb > Which, as far as I understood, will be pushed into 3.12 by the x86 people. FYI, this is now merged in Linus' tree. See: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=228abe73ad67665d71eacd6a8a347dd76b0115ae So hopefully we can get SimpleDRM ready for 3.13. Cheers David ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60827] X under radeon driver crashes after resuming from hibernation
https://bugzilla.kernel.org/show_bug.cgi?id=60827 --- Comment #4 from archie...@gmail.com --- I am sorry, I cannot completely bisect : I am running Archlinux on a production machine and I have only a few set of kernel packages saved. I can tell you that : - 3.11.1 has the very same problem - The problem was already present in 3.10.9 This kernel shows also corrupted graphics in Gnome-Shell - 3.9.9 is ok (no corrupted graphics, no problem with hibernation). I have a RV740 graphics card on a Dell Precision M6500 notebook. -- 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] drm/radeon: clean up r600_free_extended_power_table()
On Wed, Sep 4, 2013 at 5:32 AM, Dan Carpenter wrote:
> kfree() can accept NULL pointers so I have removed the checks. Also
> I've used a pointer to shorten the lines.
>
> Signed-off-by: Dan Carpenter
I've added this to my tree. thanks!
Alex
>
> diff --git a/drivers/gpu/drm/radeon/r600_dpm.c
> b/drivers/gpu/drm/radeon/r600_dpm.c
> index fa0de46..e65f211 100644
> --- a/drivers/gpu/drm/radeon/r600_dpm.c
> +++ b/drivers/gpu/drm/radeon/r600_dpm.c
> @@ -1219,30 +1219,20 @@ int r600_parse_extended_power_table(struct
> radeon_device *rdev)
>
> void r600_free_extended_power_table(struct radeon_device *rdev)
> {
> - if (rdev->pm.dpm.dyn_state.vddc_dependency_on_sclk.entries)
> - kfree(rdev->pm.dpm.dyn_state.vddc_dependency_on_sclk.entries);
> - if (rdev->pm.dpm.dyn_state.vddci_dependency_on_mclk.entries)
> -
> kfree(rdev->pm.dpm.dyn_state.vddci_dependency_on_mclk.entries);
> - if (rdev->pm.dpm.dyn_state.vddc_dependency_on_mclk.entries)
> - kfree(rdev->pm.dpm.dyn_state.vddc_dependency_on_mclk.entries);
> - if (rdev->pm.dpm.dyn_state.mvdd_dependency_on_mclk.entries)
> - kfree(rdev->pm.dpm.dyn_state.mvdd_dependency_on_mclk.entries);
> - if (rdev->pm.dpm.dyn_state.cac_leakage_table.entries)
> - kfree(rdev->pm.dpm.dyn_state.cac_leakage_table.entries);
> - if (rdev->pm.dpm.dyn_state.phase_shedding_limits_table.entries)
> -
> kfree(rdev->pm.dpm.dyn_state.phase_shedding_limits_table.entries);
> - if (rdev->pm.dpm.dyn_state.ppm_table)
> - kfree(rdev->pm.dpm.dyn_state.ppm_table);
> - if (rdev->pm.dpm.dyn_state.cac_tdp_table)
> - kfree(rdev->pm.dpm.dyn_state.cac_tdp_table);
> - if (rdev->pm.dpm.dyn_state.vce_clock_voltage_dependency_table.entries)
> -
> kfree(rdev->pm.dpm.dyn_state.vce_clock_voltage_dependency_table.entries);
> - if (rdev->pm.dpm.dyn_state.uvd_clock_voltage_dependency_table.entries)
> -
> kfree(rdev->pm.dpm.dyn_state.uvd_clock_voltage_dependency_table.entries);
> - if
> (rdev->pm.dpm.dyn_state.samu_clock_voltage_dependency_table.entries)
> -
> kfree(rdev->pm.dpm.dyn_state.samu_clock_voltage_dependency_table.entries);
> - if (rdev->pm.dpm.dyn_state.acp_clock_voltage_dependency_table.entries)
> -
> kfree(rdev->pm.dpm.dyn_state.acp_clock_voltage_dependency_table.entries);
> + struct radeon_dpm_dynamic_state *dyn_state = &rdev->pm.dpm.dyn_state;
> +
> + kfree(dyn_state->vddc_dependency_on_sclk.entries);
> + kfree(dyn_state->vddci_dependency_on_mclk.entries);
> + kfree(dyn_state->vddc_dependency_on_mclk.entries);
> + kfree(dyn_state->mvdd_dependency_on_mclk.entries);
> + kfree(dyn_state->cac_leakage_table.entries);
> + kfree(dyn_state->phase_shedding_limits_table.entries);
> + kfree(dyn_state->ppm_table);
> + kfree(dyn_state->cac_tdp_table);
> + kfree(dyn_state->vce_clock_voltage_dependency_table.entries);
> + kfree(dyn_state->uvd_clock_voltage_dependency_table.entries);
> + kfree(dyn_state->samu_clock_voltage_dependency_table.entries);
> + kfree(dyn_state->acp_clock_voltage_dependency_table.entries);
> }
>
> enum radeon_pcie_gen r600_get_pcie_gen_support(struct radeon_device *rdev,
> ___
> 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
Re: [PATCH] drm/nouveau: do not move buffers when not needed
Op 04-09-13 03:24, Ben Skeggs schreef:
> On Mon, Jul 15, 2013 at 6:39 PM, Maarten Lankhorst
> wrote:
>> Op 15-07-13 08:05, Ben Skeggs schreef:
>>> On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst
>>> wrote:
I have no idea what this bogus restriction on placement is, but it breaks
decoding 1080p
VDPAU at boot speed. With this patch applied I only need to bump the vdec
clock to
get real-time 1080p decoding. It prevents a lot of VRAM <-> VRAM buffer
moves.
>>> It's not bogus, and is required for pre-GF8 boards with VRAM > BAR size.
>>>
>>> What configuration does the buffer that's getting moved here have
>>> exactly? The placement restriction isn't necessary on GF8, the rest
>>> of the restrictions may currently be required still however.
>>>
>>> = vdpau on NVC0 with tiling. I upload the raw bitstream to a tiling bo.
>>> This is ok because
>> the vm hides all the tiling translations, and the engines will read the raw
>> bitstream correctly.
> Why would you be doing such a thing in the first place? It seems
> pointless, and quite possibly counter-productive to use a tiled layout
> for a linear data structure...
Initially I just allocated everything I didn't need to access directly tiled,
and it seems I did the same for
the bitstream bo. I only found out later about the bug with excessive moves
causing a major slowdown.
>> 8<---
>> This prevents buffer moves from being done on NV50+, where remapping is not
>> needed because
>> the bar has its own VM, instead of only having the first BAR1-size chunk of
>> VRAM accessible.
>> nouveau_bo_tile_layout is always 0 on < NV_50.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
>> b/drivers/gpu/drm/nouveau/nouveau_bo.c
>> index d506da5..762bfcd 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
>> @@ -1346,14 +1361,13 @@ nouveau_ttm_fault_reserve_notify(struct
>> ttm_buffer_object *bo)
>> struct nouveau_device *device = nv_device(drm->device);
>> u32 mappable = pci_resource_len(device->pdev, 1) >> PAGE_SHIFT;
>>
>> - /* as long as the bo isn't in vram, and isn't tiled, we've got
>> -* nothing to do here.
>> + /*
>> +* if the bo is not in vram, or remapping can be done (nv50+)
>> +* do not worry about placement, any location is valid
>> */
>> - if (bo->mem.mem_type != TTM_PL_VRAM) {
>> - if (nv_device(drm->device)->card_type < NV_50 ||
>> - !nouveau_bo_tile_layout(nvbo))
>> - return 0;
>> - }
>> + if (nv_device(drm->device)->card_type >= NV_50 ||
>> + bo->mem.mem_type != TTM_PL_VRAM)
>> + return 0;
> I get what you're trying to do here, and we should definitely avoid
> the "mappable vram" check on GF8, but I suspect this condition is too
> broad. I'll think about it more after I finish reviewing the rest of
> the patches on the list..
>
I think this relaxed check is fine. If it's !VRAM, the host can always access
it because it has direct access to the
pages without needing anything from the gpu. On >= NV50 the move can always be
skipped too because the
memory is mapped to the vm, and always accessible.
~Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60827] X under radeon driver crashes after resuming from hibernation
https://bugzilla.kernel.org/show_bug.cgi?id=60827 --- Comment #6 from archie...@gmail.com --- I powered off completely the system between each test. The patch is included starting from kernel 3.10.10 -- 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 68857] SNU OpenCL NAS Parallel Benchmarks don't work
https://bugs.freedesktop.org/show_bug.cgi?id=68857 --- Comment #2 from Nat Tuck --- This should build and run the EP benchmark: make veryclean make ep CLASS=A cd bin ./run_ocl_gpu.sh ep A If that doesn't work, you might have to edit config/make.def first to make it link to -lOpenCL. -- 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 2/3] drm/panel: Add simple panel support
On Tue, Sep 03, 2013 at 12:52:36PM -0600, Stephen Warren wrote: > On 08/30/2013 09:25 AM, Thierry Reding wrote: > > Add a driver for simple panels. Such panels can have a regulator that > > provides the supply voltage and a separate GPIO to enable the panel. > > Optionally the panels can have a backlight associated with them so it > > can be enabled or disabled according to the panel's power management > > mode. > > > diff --git a/Documentation/devicetree/bindings/panel/panel-simple.txt > > b/Documentation/devicetree/bindings/panel/panel-simple.txt > > > +Simple display panel > > + > > +Required properties: > > +- compatible: should be one of: > > + - "auo,b101aw03": AU Optronics Corporation 10.1" WSVGA TFT LCD panel > > + - "cptt,claa101wb03": Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD > > panel > > + - "pc,vvx10f004b00": Panasonic Corporation 10.1" WUXGA TFT LCD panel > > + > > +Optional properties: > > +- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing > > +- power-supply: regulator to provide the supply voltage > > +- enable-gpios: GPIO pin to enable or disable the panel > > +- backlight: phandle of the backlight device attached to the panel > > Do we need to represent the timing requirements e.g. between panel > enable and backlight enable, or do you expect the driver to hard-code > this based on the compatible value? Yes, I'd expect the driver to hard-code that, similar to how the video mode is hardcoded. ddc-i2c-bus support hasn't even been implemented yet. I was planning to do that because one of the panels (the Chunghwa I think) actually is connected via DDC. What I was going to do was prefer a hardcoded mode over EDID to allow a driver to override a faulty EDID. > Looking at the driver code, it seems that it has direct knowledge of the > video mode that each panel supports, so DDC is actually optional unlike > what I asserted/assumed in my previous response. As such, I guess we > should have a separate DT binding document for each of the three panels > (compatible values) listed above that pretty much just says "go look at > simple-panel.txt". Okay, I suppose that makes sense. Thierry pgpGdbKFasKUZ.pgp Description: PGP signature ___ 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 Wed, Sep 4, 2013 at 1:47 AM, Rahul Sharma wrote:
> 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_port;
>>> + struct device *hdmiphy_dev;
>>>
>>> - /* current hdmiphy conf regs */
>>> + /* current hdmi ip configuration registers. */
>>> struct hdmi_conf_regs mode_conf;
>>>
>>> struct hdmi_resources res;
>>> @@ -205,180 +206,6 @@ struct hdmi_context {
>>> enum hdmi_type type;
>>> };
>>>
>>> -struct hdmiphy_config {
>>> - int pixel_clock;
>>> - u8 conf[32];
>>> -};
>>> -
>>> -/* list of phy config settings */
>>> -static const struct hdmiphy_config hdmiphy_v13_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,
>>> -
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_port;
>> >> + struct device *hdmiphy_dev;
>> >>
>> >> - /* current hdmiphy conf regs */
>> >> + /* current hdmi ip configuration registers. */
>> >> struct hdmi_conf_regs mode_conf;
>> >>
>> >> struct hdmi_resources res;
>> >> @@ -205,180 +206,6 @@ struct hdmi_context {
>> >> enum hdmi_type type;
>> >> };
>> >>
>> >> -struct hdmiphy_config {
>> >> - int pixel_clock;
>> >> - u8 conf[32];
>> >> -};
>> >> -
>> >> -/* list of phy config settings */
>> >> -static const struct hdmiphy_config hdmiphy_v13_configs[] = {
>> >> - {
>> >> - .pixel_clock = 2700,
>> >>
Re: [PATCH] drm/nv84-: write fence value on exit, and restore value on init.
Op 04-09-13 05:21, Ben Skeggs schreef: > On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst > wrote: >> This increases the chance slightly that recovery from lockup can happen >> succesfully. > I'd *really* love to see proof of this. When channels die, all > outstanding fences are marked as signalled. This should do absolutely > nothing... nv84+ heavily rely on fences though, and a race like this is possible: - channel 0 uses a bo from channel 1, queues a wait somewhere in the command stream for it. - channel 1 dies cleanly, but userspace creates a new channel in its place, fence counter is reset to 0. - channel 0 reaches the NV84_SUBCHAN_SEMAPHORE_TRIGGER.ACQUIRE_GEQUAL op, waits on fence in channel 1 to signal forever. Channel 0 could be the global drm channel used for buffer moves, which would result in a hang. This may seem unlikely, but I believe that parallel piglit runs could trigger it. If not, simply creating an operation that takes a few seconds in channel 0 and then queuing a command that uses a bo from channel 1 while chan1 is still busy, then deleting/recreating chan1 could trigger it. ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Expose buffer size to userspace (v2)
Le 04/09/2013 14:05, Daniel Vetter a écrit : On Wed, Sep 04, 2013 at 12:24:27PM +0200, Martin Peres wrote: Hi Christopher, Le 04/09/2013 05:15, Christopher James Halse Rogers a écrit : Each dma-buf has an associated size and it's reasonable for userspace to want to know what it is. Since userspace already has an fd, expose the size using the size = lseek(fd, SEEK_END, 0); lseek(fd, SEEK_CUR, 0); idiom. v2: Added Daniel's sugeested documentation, with minor fixups Signed-off-by: Christopher James Halse Rogers Reviewed-by: Daniel Vetter Tested-by: Daniel Vetter --- Documentation/dma-buf-sharing.txt | 12 drivers/base/dma-buf.c| 28 2 files changed, 40 insertions(+) diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 0b23261..849e982 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -407,6 +407,18 @@ Being able to mmap an export dma-buf buffer object has 2 main use-cases: interesting ways depending upong the exporter (if userspace starts depending upon this implicit synchronization). +Other Interfaces Exposed to Userspace on the dma-buf FD +-- + +- Since kernel 3.12 the dma-buf FD supports the llseek system call, but only + with offset=0 and whence=SEEK_END|SEEK_SET. SEEK_SET is supported to allow + the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other + llseek operation will report -EINVAL. + + If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all Shouldn't it be "supported" instead of "support"? Anyway, I'm just curious, in which case is it important to know the size? Do we already have a way to get the dimensions (x, y and stripe)? Size is an invariant part of a dma-buf. Everything else wrt metadata isn't tracked in the kernel, so doesn't make much sense to expose it ;-) -Daniel ACK, thanks Daniel. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/nouveau: fix command submission to use vmalloc for big allocations
Op 04-09-13 05:31, Ben Skeggs schreef: > On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst > wrote: >> 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. > I've picked up this patch with a minor modification (see below) > >> Also limit size more aggressively to 256 KiB. > I dropped this, it's *completely* useless, the sizes are already > enforced right at the beginning of the ioctl (shockingly, the max size > is going to be 256KiB already)... > Thanks, I wonder how I missed that. :-) ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Expose buffer size to userspace (v2)
On Wed, Sep 04, 2013 at 12:24:27PM +0200, Martin Peres wrote: > Hi Christopher, > Le 04/09/2013 05:15, Christopher James Halse Rogers a écrit : > >Each dma-buf has an associated size and it's reasonable for userspace > >to want to know what it is. > > > >Since userspace already has an fd, expose the size using the > >size = lseek(fd, SEEK_END, 0); lseek(fd, SEEK_CUR, 0); > >idiom. > > > >v2: Added Daniel's sugeested documentation, with minor fixups > > > >Signed-off-by: Christopher James Halse Rogers > > > >Reviewed-by: Daniel Vetter > >Tested-by: Daniel Vetter > >--- > > Documentation/dma-buf-sharing.txt | 12 > > drivers/base/dma-buf.c| 28 > > 2 files changed, 40 insertions(+) > > > >diff --git a/Documentation/dma-buf-sharing.txt > >b/Documentation/dma-buf-sharing.txt > >index 0b23261..849e982 100644 > >--- a/Documentation/dma-buf-sharing.txt > >+++ b/Documentation/dma-buf-sharing.txt > >@@ -407,6 +407,18 @@ Being able to mmap an export dma-buf buffer object has > >2 main use-cases: > > interesting ways depending upong the exporter (if userspace starts > > depending > > upon this implicit synchronization). > >+Other Interfaces Exposed to Userspace on the dma-buf FD > >+-- > >+ > >+- Since kernel 3.12 the dma-buf FD supports the llseek system call, but only > >+ with offset=0 and whence=SEEK_END|SEEK_SET. SEEK_SET is supported to allow > >+ the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every > >other > >+ llseek operation will report -EINVAL. > >+ > >+ If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for > >all > Shouldn't it be "supported" instead of "support"? > > Anyway, I'm just curious, in which case is it important to know the size? > Do we already have a way to get the dimensions (x, y and stripe)? Size is an invariant part of a dma-buf. Everything else wrt metadata isn't tracked in the kernel, so doesn't make much sense to expose it ;-) -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] drm/nouveau: force alignment to 0x1000 for gpu objects
Op 04-09-13 05:34, Ben Skeggs schreef: > On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst > wrote: >> 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. > This is wrong. Where are the places you think you need this? > All the calls to nouveau_gpuobj_map_vm for example in core/engine/graph/nvc0.c. engctx_create is usually called with alignment = 0x100 too, which seems like it would break in the fifo_context_attach calls too. ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC 01/10] drm: ADV7511 i2c HDMI encoder driver
[...]
>> +
>> +/**
>> + * enum adv7511_input_color_depth - Selects the input format color depth
>> + * @ADV7511_INPUT_COLOR_DEPTH_8BIT: Input format color depth is 8 bits per
> channel
>> + * @ADV7511_INPUT_COLOR_DEPTH_10BIT: Input format color dpeth is 10 bits
> per channel
>> + * @ADV7511_INPUT_COLOR_DEPTH_12BIT: Input format color depth is 12 bits
> per channel
>> + **/
>> +enum adv7511_input_color_depth {
>> +ADV7511_INPUT_COLOR_DEPTH_8BIT = 3,
>> +ADV7511_INPUT_COLOR_DEPTH_10BIT = 1,
>> +ADV7511_INPUT_COLOR_DEPTH_12BIT = 2,
>> +};
>
> Those enums describe the video format at the chip input. This can be
> configured statically from platform data or DT, but some platforms might need
> to setup formats dynamically at runtime. For instance the ADV7511 could be
> driven by a mux with two inputs using different formats.
>
> For these reasons I would combine all those enums in a single one that lists
> all possible input formats. The formats should be standardized and moved to a
> separate header file. Get and set format operations will be needed (this is
> something CDF will address :-)).
Since most these settings are orthogonal to each other putting them in one
enum gives you 3 * 3 * 6 * 3 = 162 entries. These enums configure to which
pins of the ADV7511 what signal is connected. Standardizing this would
require that other chips use the same layouts for connecting the pins.
[...]
>> +
>> +/**
>> + * enum adv7511_up_conversion - Selects the upscaling conversion method
>> + * @ADV7511_UP_CONVERSION_ZERO_ORDER: Use zero order up conversion
>> + * @ADV7511_UP_CONVERSION_FIRST_ORDER: Use first order up conversion
>> + *
>> + * This used when converting from a 4:2:2 format to a 4:4:4 format.
>> + **/
>> +enum adv7511_up_conversion {
>> +ADV7511_UP_CONVERSION_ZERO_ORDER = 0,
>> +ADV7511_UP_CONVERSION_FIRST_ORDER = 1,
>> +};
>
> How is the upscaling conversion method supposed to be selected ? What does it
> depend on ?
>
It's probably up to the system designer to say which method yields better
results for their system.
[...]
>> +/**
>> + * struct adv7511_video_config - Describes adv7511 hardware configuration
>> + * @csc_enable: Whether to enable color space conversion
>> + * @csc_scaling_factor: Color space conversion scaling factor
>> + * @csc_coefficents:Color space conversion coefficents
>> + * @hdmi_mode: Whether to use HDMI or DVI output mode
>> + * @avi_infoframe: HDMI infoframe
>> + **/
>> +struct adv7511_video_config {
>> +bool csc_enable;
>
> Shouldn't this be automatically computed based on the input and output
> formats
> ?
If the driver knew the input and output colorspaces and had coefficient
tables for all possible combinations built in that could be done. This is
maybe something that could be done in the framework.
>
>> +enum adv7511_csc_scaling csc_scaling_factor;
>> +const uint16_t *csc_coefficents;
>
> Do the coefficients need to be configured freely, or could presets do ?
>
>> +bool hdmi_mode;
>> +struct hdmi_avi_infoframe avi_infoframe;
>> +};
[...]
>> +static void adv7511_set_config(struct drm_encoder *encoder, void *c)
>
> Now we're getting to the controversial point.
>
> What bothers me about the DRM encoder slave API is that the display
> controller
> driver needs to be aware of the details of the slave encoder, as it needs to
> pass an encoder-specific configuration structure to the .set_config()
> operation. The question would thus be, what about using the Common Display
> Framework ?
Well, as I said I'd prefer using the CDF for this driver. But even then the
display controller driver might need to know about the details of the
encoder. I think we talked about this during the FOSDEM meeting. The
graphics fabric on the board can easily get complex enough to require a
board custom driver, similar to what we have in ASoC. I think this
drm_bridge patchset[1] tries to address a similar issue.
[1] http://lists.freedesktop.org/archives/dri-devel/2013-August/043237.html
[...]
>> +
>> +for (i = 0; i < 4; ++i) {
>> +ret = i2c_transfer(adv7511->i2c_edid->adapter, xfer,
> ARRAY_SIZE(xfer));
>> +if (ret < 0)
>> +return ret;
>> +else if (ret != 2)
>> +return -EIO;
>> +
>> +xfer[1].buf += 64;
>> +offset += 64;
>> +}
>
> Shouldn't you read two times 64 bytes per block, not four times ?
The controller on the ADV7511 always reads two blocks at once, so it is 256
bytes.
>
>> +
>> +adv7511->current_edid_segment = block / 2;
>> +}
>> +
>> +if (block % 2 == 0)
>> +memcpy(buf, adv7511->edid_buf, len);
>> +else
>> +memcpy(buf, adv7511->edid_buf + 128, len);
>> +
>> +return 0;
>> +}
>> +
[...]
>> +
>> +struct edid *adv7511_get_ed
Re: [PATCH] dma-buf: Expose buffer size to userspace (v2)
Hi Christopher, Le 04/09/2013 05:15, Christopher James Halse Rogers a écrit : Each dma-buf has an associated size and it's reasonable for userspace to want to know what it is. Since userspace already has an fd, expose the size using the size = lseek(fd, SEEK_END, 0); lseek(fd, SEEK_CUR, 0); idiom. v2: Added Daniel's sugeested documentation, with minor fixups Signed-off-by: Christopher James Halse Rogers Reviewed-by: Daniel Vetter Tested-by: Daniel Vetter --- Documentation/dma-buf-sharing.txt | 12 drivers/base/dma-buf.c| 28 2 files changed, 40 insertions(+) diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 0b23261..849e982 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -407,6 +407,18 @@ Being able to mmap an export dma-buf buffer object has 2 main use-cases: interesting ways depending upong the exporter (if userspace starts depending upon this implicit synchronization). +Other Interfaces Exposed to Userspace on the dma-buf FD +-- + +- Since kernel 3.12 the dma-buf FD supports the llseek system call, but only + with offset=0 and whence=SEEK_END|SEEK_SET. SEEK_SET is supported to allow + the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other + llseek operation will report -EINVAL. + + If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all Shouldn't it be "supported" instead of "support"? Anyway, I'm just curious, in which case is it important to know the size? Do we already have a way to get the dimensions (x, y and stripe)? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 3.11-rc7: i915: stuck on render ring
On Tue, Sep 03, 2013 at 09:06:47PM +0200, Pavel Machek wrote: > Hi! > > I was happily using X... and then screen froze. Mouse still > moves. Switching to text console still worked, good. It is first time > in a while, normally this machine works well. > > i915_error_state is attached. > > Any ideas? It's a bug in the ddx, that was fixed in 2.14.902 (2011-03-29). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[patch] drm/radeon: clean up r600_free_extended_power_table()
kfree() can accept NULL pointers so I have removed the checks. Also
I've used a pointer to shorten the lines.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/radeon/r600_dpm.c
b/drivers/gpu/drm/radeon/r600_dpm.c
index fa0de46..e65f211 100644
--- a/drivers/gpu/drm/radeon/r600_dpm.c
+++ b/drivers/gpu/drm/radeon/r600_dpm.c
@@ -1219,30 +1219,20 @@ int r600_parse_extended_power_table(struct
radeon_device *rdev)
void r600_free_extended_power_table(struct radeon_device *rdev)
{
- if (rdev->pm.dpm.dyn_state.vddc_dependency_on_sclk.entries)
- kfree(rdev->pm.dpm.dyn_state.vddc_dependency_on_sclk.entries);
- if (rdev->pm.dpm.dyn_state.vddci_dependency_on_mclk.entries)
- kfree(rdev->pm.dpm.dyn_state.vddci_dependency_on_mclk.entries);
- if (rdev->pm.dpm.dyn_state.vddc_dependency_on_mclk.entries)
- kfree(rdev->pm.dpm.dyn_state.vddc_dependency_on_mclk.entries);
- if (rdev->pm.dpm.dyn_state.mvdd_dependency_on_mclk.entries)
- kfree(rdev->pm.dpm.dyn_state.mvdd_dependency_on_mclk.entries);
- if (rdev->pm.dpm.dyn_state.cac_leakage_table.entries)
- kfree(rdev->pm.dpm.dyn_state.cac_leakage_table.entries);
- if (rdev->pm.dpm.dyn_state.phase_shedding_limits_table.entries)
-
kfree(rdev->pm.dpm.dyn_state.phase_shedding_limits_table.entries);
- if (rdev->pm.dpm.dyn_state.ppm_table)
- kfree(rdev->pm.dpm.dyn_state.ppm_table);
- if (rdev->pm.dpm.dyn_state.cac_tdp_table)
- kfree(rdev->pm.dpm.dyn_state.cac_tdp_table);
- if (rdev->pm.dpm.dyn_state.vce_clock_voltage_dependency_table.entries)
-
kfree(rdev->pm.dpm.dyn_state.vce_clock_voltage_dependency_table.entries);
- if (rdev->pm.dpm.dyn_state.uvd_clock_voltage_dependency_table.entries)
-
kfree(rdev->pm.dpm.dyn_state.uvd_clock_voltage_dependency_table.entries);
- if (rdev->pm.dpm.dyn_state.samu_clock_voltage_dependency_table.entries)
-
kfree(rdev->pm.dpm.dyn_state.samu_clock_voltage_dependency_table.entries);
- if (rdev->pm.dpm.dyn_state.acp_clock_voltage_dependency_table.entries)
-
kfree(rdev->pm.dpm.dyn_state.acp_clock_voltage_dependency_table.entries);
+ struct radeon_dpm_dynamic_state *dyn_state = &rdev->pm.dpm.dyn_state;
+
+ kfree(dyn_state->vddc_dependency_on_sclk.entries);
+ kfree(dyn_state->vddci_dependency_on_mclk.entries);
+ kfree(dyn_state->vddc_dependency_on_mclk.entries);
+ kfree(dyn_state->mvdd_dependency_on_mclk.entries);
+ kfree(dyn_state->cac_leakage_table.entries);
+ kfree(dyn_state->phase_shedding_limits_table.entries);
+ kfree(dyn_state->ppm_table);
+ kfree(dyn_state->cac_tdp_table);
+ kfree(dyn_state->vce_clock_voltage_dependency_table.entries);
+ kfree(dyn_state->uvd_clock_voltage_dependency_table.entries);
+ kfree(dyn_state->samu_clock_voltage_dependency_table.entries);
+ kfree(dyn_state->acp_clock_voltage_dependency_table.entries);
}
enum radeon_pcie_gen r600_get_pcie_gen_support(struct radeon_device *rdev,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[patch] drm/radeon: signedness bug in kv_dpm.c
The problem here is that "unsigned i" is always greater than or equal to
zero. These loops mostly have a second check for "(i == 0)" so only the
last two are actually buggy. The rest is just cleanup.
Bug 1: kv_force_dpm_highest() doesn't have an "(i == 0)" check so it's
a potential forever loop.
Bug 2: In kv_get_sleep_divider_id_from_clock() there is a typo and the
test is reversed "<=" vs ">" so we never enter the loop. That means
normally we return KV_MAX_DEEPSLEEP_DIVIDER_ID (5). The return value
from here is saved in ->DeepSleepDivId and I wasn't able to determine
how that is used. This is a static checker fix and I have not tested
it.
Signed-off-by: Dan Carpenter
---
I considered making "i" signed but that doesn't actually change anything
because the tests have to end on zero anyway.
diff --git a/drivers/gpu/drm/radeon/kv_dpm.c b/drivers/gpu/drm/radeon/kv_dpm.c
index ecd6080..c499daf 100644
--- a/drivers/gpu/drm/radeon/kv_dpm.c
+++ b/drivers/gpu/drm/radeon/kv_dpm.c
@@ -667,9 +667,8 @@ static int kv_program_bootup_state(struct radeon_device
*rdev)
&rdev->pm.dpm.dyn_state.vddc_dependency_on_sclk;
if (table && table->count) {
- for (i = pi->graphics_dpm_level_count - 1; i >= 0; i--) {
- if ((table->entries[i].clk == pi->boot_pl.sclk) ||
- (i == 0))
+ for (i = pi->graphics_dpm_level_count - 1; i > 0; i--) {
+ if (table->entries[i].clk == pi->boot_pl.sclk)
break;
}
@@ -682,9 +681,8 @@ static int kv_program_bootup_state(struct radeon_device
*rdev)
if (table->num_max_dpm_entries == 0)
return -EINVAL;
- for (i = pi->graphics_dpm_level_count - 1; i >= 0; i--) {
- if ((table->entries[i].sclk_frequency ==
pi->boot_pl.sclk) ||
- (i == 0))
+ for (i = pi->graphics_dpm_level_count - 1; i > 0; i--) {
+ if (table->entries[i].sclk_frequency ==
pi->boot_pl.sclk)
break;
}
@@ -1588,13 +1586,11 @@ static void kv_set_valid_clock_range(struct
radeon_device *rdev,
}
}
- for (i = pi->graphics_dpm_level_count - 1; i >= 0; i--) {
- if ((table->entries[i].clk <=
new_ps->levels[new_ps->num_levels -1].sclk) ||
- (i == 0)) {
- pi->highest_valid = i;
+ for (i = pi->graphics_dpm_level_count - 1; i > 0; i--) {
+ if (table->entries[i].clk <=
new_ps->levels[new_ps->num_levels - 1].sclk)
break;
- }
}
+ pi->highest_valid = i;
if (pi->lowest_valid > pi->highest_valid) {
if ((new_ps->levels[0].sclk -
table->entries[pi->highest_valid].clk) >
@@ -1615,14 +1611,12 @@ static void kv_set_valid_clock_range(struct
radeon_device *rdev,
}
}
- for (i = pi->graphics_dpm_level_count - 1; i >= 0; i--) {
+ for (i = pi->graphics_dpm_level_count - 1; i > 0; i--) {
if (table->entries[i].sclk_frequency <=
- new_ps->levels[new_ps->num_levels - 1].sclk ||
- i == 0) {
- pi->highest_valid = i;
+ new_ps->levels[new_ps->num_levels - 1].sclk)
break;
- }
}
+ pi->highest_valid = i;
if (pi->lowest_valid > pi->highest_valid) {
if ((new_ps->levels[0].sclk -
@@ -1871,7 +1865,7 @@ static int kv_force_dpm_highest(struct radeon_device
*rdev)
if (ret)
return ret;
- for (i = SMU7_MAX_LEVELS_GRAPHICS - 1; i >= 0; i--) {
+ for (i = SMU7_MAX_LEVELS_GRAPHICS - 1; i > 0; i--) {
if (enable_mask & (1 << i))
break;
}
@@ -1911,9 +1905,9 @@ static u8 kv_get_sleep_divider_id_from_clock(struct
radeon_device *rdev,
if (!pi->caps_sclk_ds)
return 0;
- for (i = KV_MAX_DEEPSLEEP_DIVIDER_ID; i <= 0; i--) {
+ for (i = KV_MAX_DEEPSLEEP_DIVIDER_ID; i > 0; i--) {
temp = sclk / sumo_get_sleep_divider_from_id(i);
- if ((temp >= min) || (i == 0))
+ if (temp >= min)
break;
}
___
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
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? 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
> -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_port;
> >> + struct device *hdmiphy_dev;
> >>
> >> - /* current hdmiphy conf regs */
> >> + /* current hdmi ip configuration registers. */
> >> struct hdmi_conf_regs mode_conf;
> >>
> >> struct hdmi_resources res;
> >> @@ -205,180 +206,6 @@ struct hdmi_context {
> >> enum hdmi_type type;
> >> };
> >>
> >> -struct hdmiphy_config {
> >> - int pixel_clock;
> >> - u8 conf[32];
> >> -};
> >> -
> >> -/* list of phy config settings */
> >> -static const struct hdmiphy_config hdmiphy_v13_configs[] = {
> >> - {
> >> - .pixel_clock = 2700,
> >> - .conf = {
> >> - 0x01, 0x05, 0x00, 0xD8, 0x10, 0x1C, 0x30, 0x40,
> >> - 0x6B, 0x10, 0x02, 0x51, 0xDF, 0xF2, 0x54, 0x87,
>
Re: [PATCH] drm/nouveau: avoid null deref on bad arguments to nouveau_vma_getmap
Op 04-09-13 05:41, Ben Skeggs schreef:
> On Thu, Aug 22, 2013 at 5:12 PM, Maarten Lankhorst
> wrote:
>> Op 22-08-13 02:10, Ilia Mirkin schreef:
>>> The code expects non-VRAM mem nodes to have a pages list. If that's not
>>> set, it will do a null deref down the line. Warn on that condition and
>>> return an error.
>>>
>>> See https://bugs.freedesktop.org/show_bug.cgi?id=64774
>>>
>>> Reported-by: Pasi Kärkkäinen
>>> Tested-by: Pasi Kärkkäinen
>>> Signed-off-by: Ilia Mirkin
>>> Cc: # 3.8+
>>> ---
>>>
>>> I don't exactly understand what's going on, but this is just a
>>> straightforward way to avoid a null deref that you see happens in the
>>> bug. I haven't figured out the root cause of this, but it's getting
>>> well into the "I have no idea how TTM works" space. However this seems
>>> like a bit of defensive programming -- nouveau_vm_map_sg will pass
>>> node->pages as a list down, which will be dereferenced by
>>> nvc0_vm_map_sg. Perhaps the other arguments should make that
>>> dereferencing not happen, but it definitely was happening here, as you
>>> can see in the bug.
>>>
>>> Ben/Maarten, I'll let you judge whether this check is appropriate,
>>> since like I hope I was able to convey above, I'm just not really sure :)
>> Not it really isn't appropriate..
>>
>> You'd have to call call nouveau_vm_map_sg_table instead, the only place that
>> doesn't handle that correctly
>> is where it's not expected to be called.
>>
>> Here, have a completely untested patch to fix things...
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
>> b/drivers/gpu/drm/nouveau/nouveau_display.c
>> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
>> @@ -138,17 +143,26 @@ nouveau_user_framebuffer_create(struct drm_device *dev,
>> {
>> struct nouveau_framebuffer *nouveau_fb;
>> struct drm_gem_object *gem;
>> + struct nouveau_bo *nvbo;
>> int ret = -ENOMEM;
>>
>> gem = drm_gem_object_lookup(dev, file_priv, mode_cmd->handles[0]);
>> if (!gem)
>> return ERR_PTR(-ENOENT);
>>
>> + nvbo = nouveau_gem_object(gem);
>> + if (!(nvbo->valid_domains & NOUVEAU_GEM_DOMAIN_VRAM)) {
>> + nv_warn(nouveau_drm(dev), "Trying to create a fb in vram
>> with"
>> + " valid_domains=%08x\n", nvbo->valid_domains);
>> + ret = -EINVAL;
>> + goto err_unref;
>> + }
>> +
> Definitely the right idea, we can't handle this case right now.
> However, we may someday want/need to be able to scan out of system
> memory, so this is the wrong place.
>
> I suspect the correct thing to do (which'll also handle the
> "defensive" part) is to bail in nouveau_bo_move() on attempts to move
> a DMA-BUF backed object into VRAM.
>
> Sound OK?
>
If it has a WARN_ON or something that would be ok, I didn't find any other
places that attempt to move buffers to VRAM though, so it's probably harmless.
When looking into this bug I noticed that nouveau_bo_vma_add needs to have a
check for nvbo->page_shift == vma->vm->vmm->spg_shift,
and only if the check is true it should map the page in TTM_PL_TT. Patch below.
Should probably also be cc'd to stable.
~Maarten
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 89b992e..355a1b7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1560,7 +1560,8 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struct
nouveau_vm *vm,
if (nvbo->bo.mem.mem_type == TTM_PL_VRAM)
nouveau_vm_map(vma, nvbo->bo.mem.mm_node);
- else if (nvbo->bo.mem.mem_type == TTM_PL_TT) {
+ else if (nvbo->bo.mem.mem_type == TTM_PL_TT &&
+nvbo->page_shift == vma->vm->vmm->spg_shift) {
if (node->sg)
nouveau_vm_map_sg_table(vma, 0, size, node);
else
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
