Re: [Intel-gfx] [PATCH 1/3] intel_reg_read: add support for getopt
Dear Eugeni,
Am Dienstag, den 28.02.2012, 17:55 -0300 schrieb Eugeni Dodonov:
> This will allow us to pass more options to it in the future.
>
> Signed-off-by: Eugeni Dodonov
> ---
> tools/intel_reg_read.c | 44 +++-
> 1 file changed, 35 insertions(+), 9 deletions(-)
>
> diff --git a/tools/intel_reg_read.c b/tools/intel_reg_read.c
> index cad30ff..c3e559b 100644
> --- a/tools/intel_reg_read.c
> +++ b/tools/intel_reg_read.c
> @@ -41,21 +41,45 @@ static void dump_range(uint32_t start, uint32_t end)
> *(volatile uint32_t *)((volatile char*)mmio + i));
> }
>
> +static void usage(char *cmdname)
> +{
> + printf("Usage: %s [-f | addr]\n", cmdname);
> + printf("\t -f : read back full range of registers.\n");
> + printf("\t WARNING! This could be danger to hang the machine!\n");
I know you just copied this sentence, but could a native English speaker
proof read it? It sounds strange to me.
> + printf("\t addr : in 0x format\n");
> +}
> +
> int main(int argc, char** argv)
> {
> + int ret=0;
Coding style seems to differ, does not it? There are some occurrences
where `=` does have spaces around. Care to send a patch cleaning that up
beforehand?
> uint32_t reg;
> + int ch;
> + char *cmdname = strdup(argv[0]);
> + int full_dump=0;
> +
> + while ((ch = getopt(argc, argv, "fh")) != -1) {
I did not check further. But I guess no headers need to be included for
`getopt`.
> + switch(ch) {
> + case 'f':
> + full_dump=1;
> + break;
Indentation seems to differ in the line `full_dump = 1`.
> + case 'h':
> + usage(cmdname);
> + ret=1;
> + goto out;
> + }
> + }
> + argc -= optind;
> + argv += optind;
>
> - if (argc != 2) {
> - printf("Usage: %s [-f | addr]\n", argv[0]);
> - printf("\t -f : read back full range of registers.\n");
> - printf("\t WARNING! This could be danger to hang the
> machine!\n");
> - printf("\t addr : in 0x format\n");
> - exit(1);
> + if (argc != 1) {
> + usage(cmdname);
> + ret=1;
> + goto out;
> }
>
> intel_register_access_init(intel_get_pci_device(), 0);
>
> - if (!strcmp(argv[1], "-f")) {
> + if (full_dump) {
> dump_range(0x0, 0x00fff); /* VGA registers */
> dump_range(0x02000, 0x02fff); /* instruction, memory,
> interrupt control registers */
> dump_range(0x03000, 0x031ff); /* FENCE and PPGTT control
> registers */
> @@ -71,12 +95,14 @@ int main(int argc, char** argv)
> dump_range(0x7, 0x72fff); /* display and cursor registers
> */
> dump_range(0x73000, 0x73fff); /* performance counters */
> } else {
> - sscanf(argv[1], "0x%x", ®);
> + sscanf(argv[0], "0x%x", ®);
> dump_range(reg, reg + 4);
> }
>
> intel_register_access_fini();
>
> - return 0;
> +out:
> + free(cmdname);
> + return ret;
> }
Otherwise you can add
Reviewed-by: Paul Menzel
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] intel_reg_read: add a flag to simplify bit decoding
This allows to specify '-d' parameter which will decode individual bits in
each register being read.
The register bits are printed horizontally for space reasons. This
requires more than 80x25 terminal to see them all. An alternative solution
would be to print them vertically, but this will become much more
difficult to read when printing multiple registers at the same time.
Signed-off-by: Eugeni Dodonov
---
tools/intel_reg_read.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/tools/intel_reg_read.c b/tools/intel_reg_read.c
index 50b3d39..8abe3b5 100644
--- a/tools/intel_reg_read.c
+++ b/tools/intel_reg_read.c
@@ -32,6 +32,19 @@
#include
#include "intel_gpu_tools.h"
+static void bit_decode(uint32_t reg)
+{
+ int i;
+
+ for (i=31; i >= 0; i--)
+ printf(" %2d", i);
+ printf("\n");
+
+ for (i=31; i >= 0; i--)
+ printf(" %2d", (reg & (1 << i)) && 1);
+ printf("\n");
+}
+
static void dump_range(uint32_t start, uint32_t end)
{
int i;
@@ -43,9 +56,10 @@ static void dump_range(uint32_t start, uint32_t end)
static void usage(char *cmdname)
{
- printf("Usage: %s [-f] [addr1] [addr2] .. [addrN]\n", cmdname);
+ printf("Usage: %s [-f|-d] [addr1] [addr2] .. [addrN]\n", cmdname);
printf("\t -f : read back full range of registers.\n");
printf("\t WARNING! This could be danger to hang the machine!\n");
+ printf("\t -d : decode register bits.\n");
printf("\t addr : in 0x format\n");
}
@@ -56,9 +70,13 @@ int main(int argc, char** argv)
int i, ch;
char *cmdname = strdup(argv[0]);
int full_dump=0;
+ int decode_bits=0;
- while ((ch = getopt(argc, argv, "fh")) != -1) {
+ while ((ch = getopt(argc, argv, "dfh")) != -1) {
switch(ch) {
+ case 'd':
+ decode_bits=1;
+ break;
case 'f':
full_dump=1;
break;
@@ -98,6 +116,9 @@ int main(int argc, char** argv)
for (i=0; i < argc; i++) {
sscanf(argv[i], "0x%x", ®);
dump_range(reg, reg + 4);
+
+ if (decode_bits)
+ bit_decode(*(volatile uint32_t *)((volatile
char*)mmio + reg));
}
}
--
1.7.9.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] intel_reg_read: support reading multiple registers
The registers must be passed on the command line and will be read
sequentially, one at a time.
Signed-off-by: Eugeni Dodonov
---
tools/intel_reg_read.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/tools/intel_reg_read.c b/tools/intel_reg_read.c
index c3e559b..50b3d39 100644
--- a/tools/intel_reg_read.c
+++ b/tools/intel_reg_read.c
@@ -43,7 +43,7 @@ static void dump_range(uint32_t start, uint32_t end)
static void usage(char *cmdname)
{
- printf("Usage: %s [-f | addr]\n", cmdname);
+ printf("Usage: %s [-f] [addr1] [addr2] .. [addrN]\n", cmdname);
printf("\t -f : read back full range of registers.\n");
printf("\t WARNING! This could be danger to hang the machine!\n");
printf("\t addr : in 0x format\n");
@@ -53,7 +53,7 @@ int main(int argc, char** argv)
{
int ret=0;
uint32_t reg;
- int ch;
+ int i, ch;
char *cmdname = strdup(argv[0]);
int full_dump=0;
@@ -71,7 +71,7 @@ int main(int argc, char** argv)
argc -= optind;
argv += optind;
- if (argc != 1) {
+ if (argc < 1) {
usage(cmdname);
ret=1;
goto out;
@@ -95,8 +95,10 @@ int main(int argc, char** argv)
dump_range(0x7, 0x72fff); /* display and cursor registers
*/
dump_range(0x73000, 0x73fff); /* performance counters */
} else {
- sscanf(argv[0], "0x%x", ®);
- dump_range(reg, reg + 4);
+ for (i=0; i < argc; i++) {
+ sscanf(argv[i], "0x%x", ®);
+ dump_range(reg, reg + 4);
+ }
}
intel_register_access_fini();
--
1.7.9.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] intel_reg_read: add support for getopt
This will allow us to pass more options to it in the future.
Signed-off-by: Eugeni Dodonov
---
tools/intel_reg_read.c | 44 +++-
1 file changed, 35 insertions(+), 9 deletions(-)
diff --git a/tools/intel_reg_read.c b/tools/intel_reg_read.c
index cad30ff..c3e559b 100644
--- a/tools/intel_reg_read.c
+++ b/tools/intel_reg_read.c
@@ -41,21 +41,45 @@ static void dump_range(uint32_t start, uint32_t end)
*(volatile uint32_t *)((volatile char*)mmio + i));
}
+static void usage(char *cmdname)
+{
+ printf("Usage: %s [-f | addr]\n", cmdname);
+ printf("\t -f : read back full range of registers.\n");
+ printf("\t WARNING! This could be danger to hang the machine!\n");
+ printf("\t addr : in 0x format\n");
+}
+
int main(int argc, char** argv)
{
+ int ret=0;
uint32_t reg;
+ int ch;
+ char *cmdname = strdup(argv[0]);
+ int full_dump=0;
+
+ while ((ch = getopt(argc, argv, "fh")) != -1) {
+ switch(ch) {
+ case 'f':
+ full_dump=1;
+ break;
+ case 'h':
+ usage(cmdname);
+ ret=1;
+ goto out;
+ }
+ }
+ argc -= optind;
+ argv += optind;
- if (argc != 2) {
- printf("Usage: %s [-f | addr]\n", argv[0]);
- printf("\t -f : read back full range of registers.\n");
- printf("\t WARNING! This could be danger to hang the
machine!\n");
- printf("\t addr : in 0x format\n");
- exit(1);
+ if (argc != 1) {
+ usage(cmdname);
+ ret=1;
+ goto out;
}
intel_register_access_init(intel_get_pci_device(), 0);
- if (!strcmp(argv[1], "-f")) {
+ if (full_dump) {
dump_range(0x0, 0x00fff); /* VGA registers */
dump_range(0x02000, 0x02fff); /* instruction, memory,
interrupt control registers */
dump_range(0x03000, 0x031ff); /* FENCE and PPGTT control
registers */
@@ -71,12 +95,14 @@ int main(int argc, char** argv)
dump_range(0x7, 0x72fff); /* display and cursor registers
*/
dump_range(0x73000, 0x73fff); /* performance counters */
} else {
- sscanf(argv[1], "0x%x", ®);
+ sscanf(argv[0], "0x%x", ®);
dump_range(reg, reg + 4);
}
intel_register_access_fini();
- return 0;
+out:
+ free(cmdname);
+ return ret;
}
--
1.7.9.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Up/downclock LVDS on vblanks
Jesse mentioned that we had reports of flickering due to switching
clocks for powersaving and that would be a useful task to be run at
vblank.
TODO: The modification of DPLL requires some guards to prevent concurrent
access during vblank and modeset. Flushing the vblank handler before
modeset sounds like the safest approach.
---
drivers/gpu/drm/i915/intel_display.c | 102 ++
1 files changed, 55 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6c2101e..2d96394 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2240,7 +2240,6 @@ intel_pipe_set_base_atomic(struct drm_crtc *crtc, struct
drm_framebuffer *fb,
return ret;
intel_update_fbc(dev);
- intel_increase_pllclock(crtc);
return 0;
}
@@ -2319,6 +2318,7 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
mutex_unlock(&dev->struct_mutex);
+ intel_increase_pllclock(crtc);
if (!dev->primary->master)
return 0;
@@ -7065,73 +7065,85 @@ static void intel_crtc_idle_timer(unsigned long arg)
queue_work(dev_priv->wq, &dev_priv->idle_work);
}
-static void intel_increase_pllclock(struct drm_crtc *crtc)
+static void __intel_crtc_increase_pllclock(struct intel_crtc *crtc)
{
- struct drm_device *dev = crtc->dev;
- drm_i915_private_t *dev_priv = dev->dev_private;
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- int pipe = intel_crtc->pipe;
- int dpll_reg = DPLL(pipe);
+ drm_i915_private_t *dev_priv = crtc->base.dev->dev_private;
+ int dpll_reg = DPLL(crtc->pipe);
int dpll;
- if (HAS_PCH_SPLIT(dev))
- return;
-
- if (!dev_priv->lvds_downclock_avail)
- return;
-
dpll = I915_READ(dpll_reg);
- if (!HAS_PIPE_CXSR(dev) && (dpll & DISPLAY_RATE_SELECT_FPA1)) {
+ if (dpll & DISPLAY_RATE_SELECT_FPA1) {
DRM_DEBUG_DRIVER("upclocking LVDS\n");
- assert_panel_unlocked(dev_priv, pipe);
-
- dpll &= ~DISPLAY_RATE_SELECT_FPA1;
- I915_WRITE(dpll_reg, dpll);
- intel_wait_for_vblank(dev, pipe);
-
- dpll = I915_READ(dpll_reg);
- if (dpll & DISPLAY_RATE_SELECT_FPA1)
- DRM_DEBUG_DRIVER("failed to upclock LVDS!\n");
+ assert_panel_unlocked(dev_priv, crtc->pipe);
+ I915_WRITE(dpll_reg, dpll & ~DISPLAY_RATE_SELECT_FPA1);
}
/* Schedule downclock */
- mod_timer(&intel_crtc->idle_timer, jiffies +
- msecs_to_jiffies(CRTC_IDLE_TIMEOUT));
+ mod_timer(&crtc->idle_timer,
+ jiffies + msecs_to_jiffies(CRTC_IDLE_TIMEOUT));
}
-static void intel_decrease_pllclock(struct drm_crtc *crtc)
+static void intel_restore_pllclock(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ drm_i915_private_t *dev_priv = dev->dev_private;
+ int reg;
+
+ if (HAS_PCH_SPLIT(dev) || HAS_PIPE_CXSR(dev))
+ return;
+
+ reg = DPLL(to_intel_crtc(crtc)->pipe);
+ I915_WRITE(reg, I915_READ(reg) & ~DISPLAY_RATE_SELECT_FPA1);
+}
+
+static void intel_increase_pllclock(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
drm_i915_private_t *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- int pipe = intel_crtc->pipe;
- int dpll_reg = DPLL(pipe);
- int dpll = I915_READ(dpll_reg);
- if (HAS_PCH_SPLIT(dev))
+ if (HAS_PCH_SPLIT(dev) || HAS_PIPE_CXSR(dev))
return;
if (!dev_priv->lvds_downclock_avail)
return;
+ if (intel_crtc_add_vblank_task(intel_crtc,
+ __intel_crtc_increase_pllclock))
+ __intel_crtc_increase_pllclock(intel_crtc);
+}
+
+static void __intel_crtc_decrease_pllclock(struct intel_crtc *crtc)
+{
+ drm_i915_private_t *dev_priv = crtc->base.dev->dev_private;
+ int dpll_reg = DPLL(crtc->pipe);
+
/*
* Since this is called by a timer, we should never get here in
* the manual case.
*/
- if (!HAS_PIPE_CXSR(dev) && intel_crtc->lowfreq_avail) {
- DRM_DEBUG_DRIVER("downclocking LVDS\n");
+ DRM_DEBUG_DRIVER("downclocking LVDS\n");
- assert_panel_unlocked(dev_priv, pipe);
+ assert_panel_unlocked(dev_priv, crtc->pipe);
+ I915_WRITE(dpll_reg, I915_READ(dpll_reg) | DISPLAY_RATE_SELECT_FPA1);
+}
- dpll |= DISPLAY_RATE_SELECT_FPA1;
- I915_WRITE(dpll_reg, dpll);
- intel_wait_for_vblank(dev, pipe);
- dpll = I915_READ(dpll_reg);
- if (!(dpll & DISPLAY_RATE_SELECT_FPA1))
- DRM_DEBUG_DRIVER("failed to downclock LVDS!\
[Intel-gfx] [PATCH] drm/i915: Synchronize userspace palette LUT (i.e. gamma) changes to vblank
Adam Jackson was watching the screensaver fade out and expressed a
desire for the gamma updates to be synchronized to vblank to avoid the
unsightly tears.
Reported-by: Adam Jackson
Cc: Adam Jackson
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 108 +-
drivers/gpu/drm/i915/intel_drv.h |9 +++
2 files changed, 102 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 66b19d3..6c2101e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -47,6 +47,7 @@ bool intel_pipe_has_type(struct drm_crtc *crtc, int type);
static void intel_update_watermarks(struct drm_device *dev);
static void intel_increase_pllclock(struct drm_crtc *crtc);
static void intel_crtc_update_cursor(struct drm_crtc *crtc, bool on);
+static void __intel_crtc_load_lut(struct intel_crtc *crtc);
typedef struct {
/* given values */
@@ -3094,7 +3095,7 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
* On ILK+ LUT must be loaded before the pipe is running but with
* clocks enabled
*/
- intel_crtc_load_lut(crtc);
+ __intel_crtc_load_lut(to_intel_crtc(crtc));
intel_enable_pipe(dev_priv, pipe, is_pch_port);
intel_enable_plane(dev_priv, plane, pipe);
@@ -6258,29 +6259,100 @@ void intel_write_eld(struct drm_encoder *encoder,
dev_priv->display.write_eld(connector, crtc);
}
-/** Loads the palette/gamma unit for the CRTC with the prepared values */
-void intel_crtc_load_lut(struct drm_crtc *crtc)
+static void __intel_crtc_load_lut(struct intel_crtc *crtc)
{
- struct drm_device *dev = crtc->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- int palreg = PALETTE(intel_crtc->pipe);
+ struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
+ int reg;
int i;
- /* The clocks have to be on to load the palette. */
- if (!crtc->enabled || !intel_crtc->active)
+ if (!crtc->base.enabled || !crtc->active)
return;
/* use legacy palette for Ironlake */
- if (HAS_PCH_SPLIT(dev))
- palreg = LGC_PALETTE(intel_crtc->pipe);
+ reg = PALETTE(crtc->pipe);
+ if (HAS_PCH_SPLIT(crtc->base.dev))
+ reg = LGC_PALETTE(crtc->pipe);
for (i = 0; i < 256; i++) {
- I915_WRITE(palreg + 4 * i,
- (intel_crtc->lut_r[i] << 16) |
- (intel_crtc->lut_g[i] << 8) |
- intel_crtc->lut_b[i]);
+ I915_WRITE(reg + 4 * i,
+ crtc->lut_r[i] << 16 |
+ crtc->lut_g[i] << 8 |
+ crtc->lut_b[i]);
+ }
+}
+
+struct intel_crtc_vblank_task {
+ struct list_head list;
+ void (*func)(struct intel_crtc *);
+};
+
+static void intel_crtc_vblank_work_fn(struct work_struct *_work)
+{
+ struct intel_crtc_vblank_work *work =
+ container_of(_work, struct intel_crtc_vblank_work, work);
+ struct intel_crtc *crtc = work->crtc;
+
+ intel_wait_for_vblank(crtc->base.dev, crtc->pipe);
+
+ mutex_lock(&crtc->vblank_mutex);
+ while (!list_empty(&work->tasks)) {
+ struct intel_crtc_vblank_task *task
+ = list_first_entry(&work->tasks, struct
intel_crtc_vblank_task, list);
+
+ task->func(crtc);
+ list_del(&task->list);
+ kfree(task);
}
+ crtc->vblank_work = NULL;
+ mutex_unlock(&crtc->vblank_mutex);
+
+ kfree(work);
+}
+
+static int intel_crtc_add_vblank_task(struct intel_crtc *crtc,
+ void (*func)(struct intel_crtc *))
+{
+ struct intel_crtc_vblank_task *task;
+ struct intel_crtc_vblank_work *work;
+
+ task = kzalloc(sizeof *task, GFP_KERNEL);
+ if (task == NULL)
+ return -ENOMEM;
+ task->func = func;
+
+ mutex_lock(&crtc->vblank_mutex);
+ work = crtc->vblank_work;
+ if (work == NULL) {
+ work = kzalloc(sizeof *work, GFP_KERNEL);
+ if (work == NULL) {
+ mutex_unlock(&crtc->vblank_mutex);
+ kfree(task);
+ return -ENOMEM;
+ }
+
+ work->crtc = crtc;
+ INIT_LIST_HEAD(&work->tasks);
+ INIT_WORK(&work->work, intel_crtc_vblank_work_fn);
+ schedule_work(&work->work);
+ crtc->vblank_work = work;
+ }
+ list_add(&task->list, &work->tasks);
+ mutex_unlock(&crtc->vblank_mutex);
+
+ return 0;
+}
+
+/** Loads the palette/gamma unit for the CRTC with the prepared values */
+void intel_crtc_load_lut(struct drm_crtc *crtc)
+{
Re: [Intel-gfx] HDMI colour space and depth questions (YCbCr, xvYCC, Deep Colour)
On Tue, 28 Feb 2012 13:53:20 + Paul Owen wrote: > Okay so back to this question of broadcast rgb/limited/full range > colour. I'm not so sure it is working at all under Sandybridge. I use > XBMC under Linux (Ubuntu) and do not see any difference in the picture > when I do either of the following: > > 1) Set BROADCAST_RGB = 1 (or 0) in the xorg.conf - in fact the X log > shows the setting is ignored seemingly wherever I put it > 2) type on the command line, xrandr -d :0 --output --set > "Broadcast RGB" "Limited 16:235" > > and: > > 3) type on the command line, xrandr -d :0 --output --set > "BROADCAST_RGB" 1 - this just errors as previously noted here and in > other related topics There are several places we need to set extended vs normal range: DSP*CNTR (bit 25) PIPE*CONF (bits 26 and 13) TRANS*CONF (bit 10, for xvYCC DP configs) DVS*CNTR (for sprites, bit 21) I assume you're on HDMI and not using sprites, so can you confirm the DSP*CNTR and PIPE*CONF bits with intel_reg_read? You can try setting the range bits by hand with intel_reg_write, but that might not work (you may need a full pipe shutdown and restart to change them, in which case you'd need to hack intel_display.c to do it for you). > It seems to me it outputs full range colour regardless of this setting > - are the above methods "potentially" correct? As such it limits the > usefulness of the platform to htpc users - under Linux that is. Under > Windows it seems to automatically detect that a TV is connected and > switch to 16-235 (using EDID info and manufacturer data maybe?). Is it > at all possible to manage this under Linux in a similar way maybe, any > future plans perhaps? This is, aside from the fractional framerate > issue probably the last major issue limiting the platform under Linux > and in my case XBMC. Yeah defaulting to the limited range for TVs may make sense. Paulo has been looking at TV detection and HDMI infoframes a bit, so may be able to whip up a patch. We probably just have a bug here and don't set all the bits we need to... -- Jesse Barnes, Intel Open Source Technology Center signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] HDMI colour space and depth questions (YCbCr, xvYCC, Deep Colour)
On 16 January 2012 22:12, Jesse Barnes wrote: > > On Mon, 16 Jan 2012 21:50:22 + > Andy Burns wrote: > > > Jesse Barnes wrote: > > > > > Andy Burns wrote: > > > > > > There is a way to configure the gamut to be compressed (default) or > > > expanded (up to 255). But that's not exposed either. > > > > I see the following from the man page > > > > "DVI/HDMI outputs. Avaliable common properties include: > > BROADCAST_RGB - method used to set RGB color range(full range 0-255, > > not full range 16-235) > > Adjusting this propertie allows you to set RGB color range on each > > channel in order to match HDTV requirment(default 0 for full range). > > Setting 1 means RGB color range is 16-235, 0 means RGB color range is > > 0-255 on each channel. > > SDVO and DVO TV outputs are not supported by the driver at this time." > > > > Does that mean I *can* toggle the studio colour range on the fly, or > > is the doc wrong? > > Ah maybe we do expose it; I'm out of date. Yeah that should change the > color range handling... Hi - I just wanted to revisit this particular topic. Firstly I should say I'm subscribed to the list to try and stay up to date with the cutting edge you guys are working on. I'm not a developer or anything, just an interested user. Okay so back to this question of broadcast rgb/limited/full range colour. I'm not so sure it is working at all under Sandybridge. I use XBMC under Linux (Ubuntu) and do not see any difference in the picture when I do either of the following: 1) Set BROADCAST_RGB = 1 (or 0) in the xorg.conf - in fact the X log shows the setting is ignored seemingly wherever I put it 2) type on the command line, xrandr -d :0 --output --set "Broadcast RGB" "Limited 16:235" and: 3) type on the command line, xrandr -d :0 --output --set "BROADCAST_RGB" 1 - this just errors as previously noted here and in other related topics It seems to me it outputs full range colour regardless of this setting - are the above methods "potentially" correct? As such it limits the usefulness of the platform to htpc users - under Linux that is. Under Windows it seems to automatically detect that a TV is connected and switch to 16-235 (using EDID info and manufacturer data maybe?). Is it at all possible to manage this under Linux in a similar way maybe, any future plans perhaps? This is, aside from the fractional framerate issue probably the last major issue limiting the platform under Linux and in my case XBMC. For reference I've tried this on various kernels from 3.0 through to the 3.3 RC's. The hardware in question is a Pentium G620T on an Intel DH67CF motherboard. Also for reference in case you guys are interested the following topic at XBMC's forum details setting up the platform under Linux, http://forum.xbmc.org/showthread.php?t=114368 including my comments about full/limited range colour. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Handle request to map a very large buffer object
Dear Anuj,
thank you for your patch with the great explanation in the commit
message. I found one typo in the code comment and while at it point out
some grammar issue in the commit message.
Am Montag, den 27.02.2012, 12:28 -0800 schrieb Anuj Phogat:
> This patch sets an upper limit on the size of buffer object which can be
> mapped safely. Following bugs reported segmentation fault / assertion
reported *a* segmentation fault / *an* assertion …
> failure with large textures:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=44970
> https://bugs.freedesktop.org/show_bug.cgi?id=46303
>
> This patch along with another patch which I posted on mesa-dev
> (intel: Fix a case when mapping large texture fails) [1] resolve
You could add the URL.
> above mentioned bugs. Recently posted piglit test case (large-textures)
*The* recently …
> also passes with these patches.
[1] http://lists.freedesktop.org/archives/mesa-dev/2012-February/019488.html
> Signed-off-by: Anuj Phogat
> ---
> This fix doesn't limit developers to create very large texture but it
> restricts them to map it. I am not very confident about this patch and
> setting 128 MB as the upper limit on size of buffer object. So, please
> provide your views.
>
> Chris Wilson's views on this issue:
> http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg08585.html
>
> intel/intel_bufmgr_gem.c | 11 +++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index 0f33b71..8b05de9 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -1191,6 +1191,17 @@ int drm_intel_gem_bo_map_gtt(drm_intel_bo *bo)
>
> pthread_mutex_lock(&bufmgr_gem->lock);
>
> + /* Set am upper limit on the size of buffer which can be mapped
> +safely
s/am/an/
Maybe add full stop ».« at the end of the sentence.
> + */
> + if (bo->size > 128 * 1024 * 1024) {
It seems strange for me that the upper buffer size is always the same
and not dependent on the chipset(?). But I guess you have checked that.
> + DBG("%s:%d: Reached buffer map limit.\n",
> + __FILE__, __LINE__);
> + bo->virtual = NULL;
> + pthread_mutex_unlock(&bufmgr_gem->lock);
> + return -1;
> + }
> +
> if (bo_gem->map_count++ == 0)
> drm_intel_gem_bo_open_vma(bufmgr_gem, bo_gem);
Reviewed-by: Paul Menzel
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
