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 *****************************************
