Intel-gfx Digest, Vol 61, Issue 10

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Can you remove me from this mailing list?

Thanks,

Florence

-----Original Message-----
From: intel-gfx-bounces+florence.geisler=intel.com at lists.freedesktop.org [mailto:intel-gfx-bounces+florence.geisler=intel.com at lists.freedesktop.org] On Behalf Of intel-gfx-request at lists.freedesktop.org
Sent: Sunday, February 03, 2013 12:01 PM
To: intel-gfx at lists.freedesktop.org
Subject: Intel-gfx Digest, Vol 61, Issue 10

Send Intel-gfx mailing list submissions to
	intel-gfx at lists.freedesktop.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.freedesktop.org/mailman/listinfo/intel-gfx
or, via email, send a message with subject or body 'help' to
	intel-gfx-request at lists.freedesktop.org

You can reach the person managing the list at
	intel-gfx-owner at lists.freedesktop.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of Intel-gfx digest..."


Today's Topics:

   1. Re: [PATCH] PM: make VT switching to the suspend	console
      optional v2 (Rafael J. Wysocki)
   2. Re: Advanced Deinterlacers (Jochen Heuer)
   3. Re: [PATCH 00/10] [RFC v2] quick dump (Ben Widawsky)
   4. Re: [PATCH 09/10] quick_dump: Connect libpciaccess and	other
      utils (Ben Widawsky)


----------------------------------------------------------------------

Message: 1
Date: Sun, 03 Feb 2013 13:59:49 +0100
From: "Rafael J. Wysocki" <rjw at sisk.pl>
To: Jesse Barnes <jbarnes at virtuousgeek.org>
Cc: intel-gfx at lists.freedesktop.org, linux-kernel at vger.kernel.org,
	Linux PM list <linux-pm at vger.kernel.org>
Subject: Re: [PATCH] PM: make VT switching to the suspend
	console optional v2
Message-ID: <2642200.VLPEM056qV at vostro.rjw.lan>
Content-Type: text/plain; charset="utf-8"

On Sunday, February 03, 2013 09:56:09 AM Jesse Barnes wrote:
> On Sat, 02 Feb 2013 21:50:35 +0100
> "Rafael J. Wysocki" <rjw at sisk.pl> wrote:
> > > > + * Drivers can indicate support for switchless suspend/resume, 
> > > > + which can
> > > > + * save time and flicker, by using this routine and passing 
> > > > + 'false' as
> > > > + * the argument.  If any loaded driver needs VT switching, or 
> > > > + the
> > > > + * no_console_suspend argument has been passed on the command 
> > > > + line, VT
> > > > + * switches will occur.
> > > > + */
> > > 
> > > It seems to me that we'll need a separate counter for the number 
> > > of registered drivers and do the switch if that number is equal to 
> > > the number of drivers that have passed false to this thing.
> > > 
> > > In which case we can simplify this slightly and introduce
> > > pm_vt_swtich_not_required(void)
> > 
> > Sorry, that won't be sufficient.  Rather something like 
> > pm_vt_switch_get() (indicating "I'll do the switch, thanks") and 
> > pm_vt_switch_put() (indicating "now you need to do the switch yourself").
> 
> I thought of both of your approaches before posting this one, but each 
> have other problems.  And I found a bug in mine last night.
> 
> So I think I need a separate count of drivers that need the switch, 
> and ones that don't.  Then if either no driver has registered or if 
> the need_switch count is nonzero, we'll do the switch.  Otherwise, if 
> the dont_need_switch is nonzero, we can avoid the switch.  I think 
> that'll handle all the cases I outlined.

Yes, it should cover them all I think.

> My code as posted will fail if one driver needs a switch but then two 
> switch free drivers register.

I see.

Thanks,
Rafael


--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.


------------------------------

Message: 2
Date: Sun, 3 Feb 2013 15:37:45 +0100
From: Jochen Heuer <jogi-intel-gfx at planetzork.ping.de>
To: Mario Schulz <tf5a at arcor.de>
Cc: intel-gfx at lists.freedesktop.org
Subject: Re: Advanced Deinterlacers
Message-ID: <20130203143745.GA8533 at planetzork.ping.de>
Content-Type: text/plain; charset=us-ascii

Hello,

> As far as I have seen you have successfully implementeted the API
> technology to select interlacers in the video pipeline as video
> postprocessor since middle of last year.
> 
> The VDR community is still waiting for MotionAdaptive or MotionCompensated.
> 
> Could you comment on your schedule for that?
> - Is it for some reason technologically impossible to get it implemented?
> - Are the plans for IVB or SBR to make it available?

I am very interested in this also since I probably have to replace my old VDR
in the near future and I need to know if I have to go the NVidia route because
of working VDPAU support for advanced deinterlacers (although I would not like
it since it's closed source) or if I can expect working advanced deinterlacers
in the near future in the Intel stack. Because I would prefer to go the Intel
route instead.

Thanks and best regards,

   Jogi


------------------------------

Message: 3
Date: Sun, 3 Feb 2013 10:13:10 -0800
From: Ben Widawsky <ben at bwidawsk.net>
To: Chris Wilson <chris at chris-wilson.co.uk>,	Jesse Barnes
	<jbarnes at virtuousgeek.org>,	intel-gfx at lists.freedesktop.org,
	vincent.beng.keat.cheah at intel.com,	alan.previn.teres.alexis at intel.com
Subject: Re: [PATCH 00/10] [RFC v2] quick dump
Message-ID: <20130203181310.GA22639 at lundgren.kumite>
Content-Type: text/plain; charset=us-ascii

On Sun, Feb 03, 2013 at 12:22:25PM +0000, Chris Wilson wrote:
> On Sun, Feb 03, 2013 at 10:29:15AM +0100, Jesse Barnes wrote:
> > On Sat,  2 Feb 2013 16:07:52 -0800
> > Ben Widawsky <ben at bwidawsk.net> wrote:
> > 
> > > This is my second attempt at winning approval for the series. First one
> > > was: https://patchwork.kernel.org/patch/1493131/
> > > 
> > > In spending the time to rework this tool, I've begun to lose my belief
> > > in some of the original motivations I had.  Even if you don't want to
> > > review, but just like (or dislike) what you see, I'd appreciate such
> > > comments.
> > 
> > I'd like to see it land in i-g-t.  Having the regs defined in a text or
> > xml file is an improvement over what we have today, and is easier to
> > extend.  At first the advantage of reg_dumper was that it parsed out
> > the bitfields of the various regs.  But we didn't keep up with that,
> > and also haven't kept up with the regs on new platforms as well as we
> > could.  Text files would make that easier, and xml files might bring
> > back the bit field parsing, which would be extra nice.
> 
> Completely agree. For me the big improvement would be being able to use
> the bspec register names or our internal approximation thereof rather
> than having to loop up the actual addresses every time. 
> 
> Having the name database available in python should make building
> integrated little snippets to parse traces which are also python
> accessible.
> -Chris

It's really nice to get support from you. A mix of fever and staring at
the same code too long can really make someone go crazy. Still, a few
concerns left from me, one of which I accidentally left out of the
description.

- Someone needs to give me a yes or no on the m4 extension macros. This
  will block any pushing.
- The build kind of sucks on Arch because of Arch's choices regarding
  python libraries. To build this on Arch, you must run something like:
  ./autogen.sh PYTHON_LDFLAGS="-L/usr/lib/python3.3 -lpython3.3m"
  I really don't like autogen not working out of the box. Perhaps I need
  to add an AC_ flag to default this tool to off? What do others think?
  Does it work properly on other distros? How to handle this?
- Ideally, I'd like someone to send me some fixes for valleyview
  definitions if they're needed. I am not sure.

Jesse, if you can send me a list of DPIO offsets to read, I'll add the
appropriate patch. (It can wait until you get back).

-- 
Ben Widawsky, Intel Open Source Technology Center


------------------------------

Message: 4
Date: Sun, 3 Feb 2013 10:15:58 -0800
From: Ben Widawsky <ben at bwidawsk.net>
To: intel-gfx at lists.freedesktop.org
Cc: vincent.beng.keat.cheah at intel.com,
	alan.previn.teres.alexis at intel.com
Subject: Re: [PATCH 09/10] quick_dump: Connect
	libpciaccess and	other utils
Message-ID: <20130203181557.GB22639 at lundgren.kumite>
Content-Type: text/plain; charset=us-ascii

On Sat, Feb 02, 2013 at 04:08:01PM -0800, Ben Widawsky wrote:
> Make a register access library with sample to do register reads
> 
> Signed-off-by: Ben Widawsky <ben at bwidawsk.net>
> ---
>  tools/quick_dump/Makefile.am     | 14 +++++++++-----
>  tools/quick_dump/chipset.i       | 16 ++++++++++++++--
>  tools/quick_dump/intel_chipset.c |  7 +++++++
>  tools/quick_dump/quick_dump.py   |  5 ++---
>  tools/quick_dump/reg_access.py   | 25 +++++++++++++++++++++++++
>  5 files changed, 57 insertions(+), 10 deletions(-)
>  create mode 100755 tools/quick_dump/reg_access.py
> 
> diff --git a/tools/quick_dump/Makefile.am b/tools/quick_dump/Makefile.am
> index 6c04dd5..4711830 100644
> --- a/tools/quick_dump/Makefile.am
> +++ b/tools/quick_dump/Makefile.am
> @@ -1,14 +1,18 @@
>  BUILT_SOURCES = chipset_wrap_python.c
>  
> -bin_SCRIPTS = quick_dump.py chipset.py
> +bin_SCRIPTS = quick_dump.py chipset.py reg_access.py
>  
>  lib_LTLIBRARIES = I915ChipsetPython.la
> -I915ChipsetPython_la_CFLAGS = -I$(top_srcdir)/lib $(PYTHON_CPPFLAGS)
> -I915ChipsetPython_la_LDFLAGS = -module -avoid-version $(PYTHON_LDFLAGS)
> -I915ChipsetPython_la_SOURCES = chipset_wrap_python.c intel_chipset.c
> +I915ChipsetPython_la_CFLAGS = -I$(top_srcdir)/lib $(PYTHON_CPPFLAGS) $(CFLAGS) -I/usr/include/libdrm/
> +I915ChipsetPython_la_LDFLAGS = -module -avoid-version $(PYTHON_LDFLAGS) -lpciaccess
> +I915ChipsetPython_la_SOURCES = chipset_wrap_python.c intel_chipset.c \
> +			       ../../lib/intel_drm.c  \
> +			       ../../lib/intel_pci.c  \
> +			       ../../lib/intel_reg_map.c  \
> +			       ../../lib/intel_mmio.c

I should probably $(top_srcdir)/lib these sources. Fixed locally.

>  
>  chipset_wrap_python.c: chipset.i
> -	$(SWIG) $(AX_SWIG_PYTHON_OPT) -I$(top_srcdir)/lib -o $@ $<
> +	$(SWIG) $(AX_SWIG_PYTHON_OPT) -I/usr/include -I$(top_srcdir)/lib -o $@ $<
>  
>  all-local: I915ChipsetPython.la
>  	$(LN_S) -f .libs/I915ChipsetPython.so _chipset.so
> diff --git a/tools/quick_dump/chipset.i b/tools/quick_dump/chipset.i
> index 16c4932..2f4f5ef 100644
> --- a/tools/quick_dump/chipset.i
> +++ b/tools/quick_dump/chipset.i
> @@ -1,12 +1,24 @@
> -%module chipset 
> +%module chipset
> +%include "stdint.i"
>  %{
> +#include <pciaccess.h>
> +#include <stdint.h>
>  #include "intel_chipset.h"
>  extern int is_sandybridge(unsigned short pciid);
>  extern int is_ivybridge(unsigned short pciid);
>  extern int is_valleyview(unsigned short pciid);
> +extern struct pci_device *intel_get_pci_device();
> +extern int intel_register_access_init(struct pci_device *pci_dev, int safe);
> +extern uint32_t intel_register_read(uint32_t reg);
> +extern void intel_register_access_fini();
> +extern unsigned short pcidev_to_devid(struct pci_device *pci_dev);
>  %}
>  
> -%include "intel_chipset.h"
>  extern int is_sandybridge(unsigned short pciid);
>  extern int is_ivybridge(unsigned short pciid);
>  extern int is_valleyview(unsigned short pciid);
> +extern struct pci_device *intel_get_pci_device();
> +extern int intel_register_access_init(struct pci_device *pci_dev, int safe);
> +extern uint32_t intel_register_read(uint32_t reg);
> +extern void intel_register_access_fini();
> +extern unsigned short pcidev_to_devid(struct pci_device *pci_dev);
> diff --git a/tools/quick_dump/intel_chipset.c b/tools/quick_dump/intel_chipset.c
> index b242ffc..d6e7f91 100644
> --- a/tools/quick_dump/intel_chipset.c
> +++ b/tools/quick_dump/intel_chipset.c
> @@ -1,3 +1,4 @@
> +#include <pciaccess.h>
>  #include "intel_chipset.h"
>  
>  int is_sandybridge(unsigned short pciid)
> @@ -14,3 +15,9 @@ int is_valleyview(unsigned short pciid)
>  {
>  	return IS_VALLEYVIEW(pciid);
>  }
> +
> +/* Simple helper because I couldn't make this work in the script */
> +unsigned short pcidev_to_devid(struct pci_device *pdev)
> +{
> +	return pdev->device_id;
> +}
> diff --git a/tools/quick_dump/quick_dump.py b/tools/quick_dump/quick_dump.py
> index 59cae1f..44aa2ba 100755
> --- a/tools/quick_dump/quick_dump.py
> +++ b/tools/quick_dump/quick_dump.py
> @@ -32,9 +32,8 @@ if args.baseless == False:
>  				parse_file(file)
>  
>  if args.autodetect:
> -	sysfs_file = open('/sys/class/drm/card0/device/device', 'r')
> -	devid_str = sysfs_file.read()
> -	devid = int(devid_str, 16)
> +	pci_dev = chipset.intel_get_pci_device()
> +	devid = chipset.pcidev_to_devid(pci_dev)
>  	if chipset.is_sandybridge(devid):
>  		args.profile = open('sandybridge', 'r')
>  	elif chipset.is_ivybridge(devid):
> diff --git a/tools/quick_dump/reg_access.py b/tools/quick_dump/reg_access.py
> new file mode 100755
> index 0000000..0f63424
> --- /dev/null
> +++ b/tools/quick_dump/reg_access.py
> @@ -0,0 +1,25 @@
> +#!/usr/bin/env python3
> +import chipset
> +
> +def read(reg):
> +	reg = int(reg, 16)
> +	val = chipset.intel_register_read(reg)
> +	return val
> +
> +def init():
> +	pci_dev = chipset.intel_get_pci_device()
> +	ret = chipset.intel_register_access_init(pci_dev, 0)
> +	if ret != 0:
> +		print("Register access init failed");
> +		return False
> +	return True
> +
> +if __name__ == "__main__":
> +	import sys
> +
> +	if init() == False:
> +		sys.exit()
> +
> +	reg = sys.argv[1]
> +	print(hex(read(reg)))
> +	chipset.intel_register_access_fini()
> -- 
> 1.8.1.2
> 

-- 
Ben Widawsky, Intel Open Source Technology Center


------------------------------

_______________________________________________
Intel-gfx mailing list
Intel-gfx at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


End of Intel-gfx Digest, Vol 61, Issue 10
*****************************************


[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux