[Intel-gfx] Intel-gfx Digest, Vol 61, Issue 10
Geisler, Florence
florence.geisler at intel.com
Sun Feb 3 21:40:35 CET 2013
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: [Intel-gfx] [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: [Intel-gfx] 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: [Intel-gfx] [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: [Intel-gfx] [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
*****************************************
More information about the Intel-gfx
mailing list