[PATCH] Allow kmscon to be cross-compiled
On Mon, Sep 09, 2013 at 12:48:08PM +0200, David Herrmann wrote: > Hi > > On Mon, Sep 9, 2013 at 12:27 PM, Thierry Reding > wrote: > > The genshader and genunifont utilities are run during the build process > > to generate source files. In order for that to work when cross-compiling > > the files need to be built using the native compiler instead of the > > cross-compiler. > > > > Add the AX_PROG_CC_FOR_BUILD m4 macro which defines various *_FOR_BUILD > > variables that are the native equivalents of CC, CFLAGS, LDFLAGS, etc. > > Override CC, CFLAGS and LDFLAGS for genshader and genunifont and their > > object files so that they will be built natively and can be executed > > during the build. > > Thanks a lot! Looks all good, few comments below. I think I will apply > it as is, anyway. New bugfix-release is planned for this week, too. > > > Signed-off-by: Thierry Reding > > --- > > Makefile.am| 16 -- > > configure.ac | 3 +- > > m4/ax_prog_cc_for_build.m4 | 125 > > + > > 3 files changed, 139 insertions(+), 5 deletions(-) > > create mode 100644 m4/ax_prog_cc_for_build.m4 > > > > diff --git a/Makefile.am b/Makefile.am > > index 7019290..f1b4435 100644 > > --- a/Makefile.am > > +++ b/Makefile.am > > @@ -445,8 +445,12 @@ EXTRA_DIST += $(SHADERS) > > CLEANFILES += src/static_shaders.c > > genshader_SOURCES = src/genshader.c > > > > -src/static_shaders.c: $(SHADERS) genshader$(EXEEXT) > > - $(AM_V_GEN)./genshader$(EXEEXT) src/static_shaders.c $(SHADERS) > > +src/static_shaders.c: $(SHADERS) genshader$(BUILD_EXEEXT) > > + $(AM_V_GEN)./genshader$(BUILD_EXEEXT) src/static_shaders.c > > $(SHADERS) > > + > > +genshader$(BUILD_EXEEXT) $(genshader_OBJECTS): CC = $(CC_FOR_BUILD) > > +genshader$(BUILD_EXEEXT) $(genshader_OBJECTS): CFLAGS = $(CFLAGS_FOR_BUILD) > > +genshader$(BUILD_EXEEXT): LDFLAGS = $(LDFLAGS_FOR_BUILD) > > Just wondering, isn't this going to break if $BUILD_EXEEXT != $EXEEXT > I mean, noinst_PROGRAMS generates build-rules for $EXEEXT, not for > $BUILD_EXEEXT, so a dependency on "genshader$(BUILD_EXEEXT)" won't do > anything if it differs from $EXEEXT. But maybe I am just missing > something and automake creates rules for both? That's a good point. And yes, I think it would break if both extensions differed. On the other hand I have no idea on how to make automake generate rules for $(BUILD_EXEEXT). I don't think it can. Interestingly, I mistakenly used genshader$(EXEEXT) initially, but that causes automake to spew out warnings that these "rules" (which aren't really rules at all) were overriding previous commands for the same target. So while $(BUILD_EXEEXT) is the right extension to use, it also works around a shortcoming in automake. Another shortcoming of automake will cause this to break when doing MinGW->Unix and Unix->MinGW cross- builds... A different approach of this patch was to move genshader and genunifont to a tools subdirectory with a separate Makefile.am and overwrite the CC, CFLAGS and LDFLAGS variables in that directory only, but automake doesn't accept that either because CFLAGS is considered a user variable and therefore can't be overwritten. I think this is as good as it gets for now. I've tried to fix this kind of problem in automake several times but never managed to. Perhaps it's time to move on to something like SCons... Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130909/ff680367/attachment.pgp>
[PATCH] Allow kmscon to be cross-compiled
Hi
On Mon, Sep 9, 2013 at 12:27 PM, Thierry Reding
wrote:
> The genshader and genunifont utilities are run during the build process
> to generate source files. In order for that to work when cross-compiling
> the files need to be built using the native compiler instead of the
> cross-compiler.
>
> Add the AX_PROG_CC_FOR_BUILD m4 macro which defines various *_FOR_BUILD
> variables that are the native equivalents of CC, CFLAGS, LDFLAGS, etc.
> Override CC, CFLAGS and LDFLAGS for genshader and genunifont and their
> object files so that they will be built natively and can be executed
> during the build.
Thanks a lot! Looks all good, few comments below. I think I will apply
it as is, anyway. New bugfix-release is planned for this week, too.
> Signed-off-by: Thierry Reding
> ---
> Makefile.am| 16 --
> configure.ac | 3 +-
> m4/ax_prog_cc_for_build.m4 | 125
> +
> 3 files changed, 139 insertions(+), 5 deletions(-)
> create mode 100644 m4/ax_prog_cc_for_build.m4
>
> diff --git a/Makefile.am b/Makefile.am
> index 7019290..f1b4435 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -445,8 +445,12 @@ EXTRA_DIST += $(SHADERS)
> CLEANFILES += src/static_shaders.c
> genshader_SOURCES = src/genshader.c
>
> -src/static_shaders.c: $(SHADERS) genshader$(EXEEXT)
> - $(AM_V_GEN)./genshader$(EXEEXT) src/static_shaders.c $(SHADERS)
> +src/static_shaders.c: $(SHADERS) genshader$(BUILD_EXEEXT)
> + $(AM_V_GEN)./genshader$(BUILD_EXEEXT) src/static_shaders.c $(SHADERS)
> +
> +genshader$(BUILD_EXEEXT) $(genshader_OBJECTS): CC = $(CC_FOR_BUILD)
> +genshader$(BUILD_EXEEXT) $(genshader_OBJECTS): CFLAGS = $(CFLAGS_FOR_BUILD)
> +genshader$(BUILD_EXEEXT): LDFLAGS = $(LDFLAGS_FOR_BUILD)
Just wondering, isn't this going to break if $BUILD_EXEEXT != $EXEEXT
I mean, noinst_PROGRAMS generates build-rules for $EXEEXT, not for
$BUILD_EXEEXT, so a dependency on "genshader$(BUILD_EXEEXT)" won't do
anything if it differs from $EXEEXT. But maybe I am just missing
something and automake creates rules for both?
Otherwise, looks good.
Thanks
David
> #
> # Unifont Generator
> @@ -461,8 +465,12 @@ EXTRA_DIST += $(UNIFONT)
> CLEANFILES += $(UNIFONT_BIN)
> genunifont_SOURCES = src/genunifont.c
>
> -$(UNIFONT_BIN): $(UNIFONT) genunifont$(EXEEXT)
> - $(AM_V_GEN)./genunifont$(EXEEXT) $(UNIFONT_BIN) $(UNIFONT)
> +genunifont$(BUILD_EXEEXT) $(genunifont_OBJECTS): CC = $(CC_FOR_BUILD)
> +genunifont$(BUILD_EXEEXT) $(genunifont_OBJECTS): CFLAGS = $(CFLAGS_FOR_BUILD)
> +genunifont$(BUILD_EXEEXT): LDFLAGS = $(LDFLAGS_FOR_BUILD)
> +
> +$(UNIFONT_BIN): $(UNIFONT) genunifont$(BUILD_EXEEXT)
> + $(AM_V_GEN)./genunifont$(BUILD_EXEEXT) $(UNIFONT_BIN) $(UNIFONT)
>
> #
> # Kmscon Modules
> diff --git a/configure.ac b/configure.ac
> index bf3c89c..b5d9513 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -17,7 +17,7 @@ AC_CONFIG_HEADER(config.h)
> AC_USE_SYSTEM_EXTENSIONS
> AC_SYS_LARGEFILE
> AC_PREFIX_DEFAULT([/usr])
> -AC_CANONICAL_HOST
> +AC_CANONICAL_SYSTEM
>
> AM_INIT_AUTOMAKE([foreign 1.11 subdir-objects dist-xz no-dist-gzip tar-pax
> -Wall -Werror -Wno-portability])
> AM_SILENT_RULES([yes])
> @@ -31,6 +31,7 @@ AM_SILENT_RULES([yes])
> : ${CFLAGS=""}
>
> AC_PROG_CC
> +AX_PROG_CC_FOR_BUILD
> AC_PROG_CC_C99
> AM_PROG_CC_C_O
> m4_ifdef([AM_PROG_AR], [AM_PROG_AR])
> diff --git a/m4/ax_prog_cc_for_build.m4 b/m4/ax_prog_cc_for_build.m4
> new file mode 100644
> index 000..6369809
> --- /dev/null
> +++ b/m4/ax_prog_cc_for_build.m4
> @@ -0,0 +1,125 @@
> +# ===
> +# http://www.gnu.org/software/autoconf-archive/ax_prog_cc_for_build.html
> +# ===
> +#
> +# SYNOPSIS
> +#
> +# AX_PROG_CC_FOR_BUILD
> +#
> +# DESCRIPTION
> +#
> +# This macro searches for a C compiler that generates native executables,
> +# that is a C compiler that surely is not a cross-compiler. This can be
> +# useful if you have to generate source code at compile-time like for
> +# example GCC does.
> +#
> +# The macro sets the CC_FOR_BUILD and CPP_FOR_BUILD macros to anything
> +# needed to compile or link (CC_FOR_BUILD) and preprocess (CPP_FOR_BUILD).
> +# The value of these variables can be overridden by the user by specifying
> +# a compiler with an environment variable (like you do for standard CC).
> +#
> +# It also sets BUILD_EXEEXT and BUILD_OBJEXT to the executable and object
> +# file extensions for the build platform, and GCC_FOR_BUILD to `yes' if
> +# the compiler we found is GCC. All these variables but GCC_FOR_BUILD are
> +# substituted in the Makefile.
> +#
> +# LICENSE
> +#
> +# Copyright (c) 2008 Paolo Bonzini
> +#
> +# Copying and distribution of this file, with or without modification, are
> +# permitted in any medium without royalty provided the copyright notice
> +# and this
[Bug 60182] X.Org Server terminate when I close video player
https://bugs.freedesktop.org/show_bug.cgi?id=60182
--- Comment #20 from Weber K. weber...@yahoo.com.br ---
Here is what Ive got!
If this dont help, please give me more details and I will try my best!
Thanks in advance!
xf86-video-ati 6.14.4
xorg-server 1.12.4
Program received signal SIGSEGV, Segmentation fault.
0x7ff17f1ad465 in radeon_dri2_destroy_buffer (drawable=0x343bbb0,
buffers=0x342cc40) at radeon_dri2.c:419
419xf86DrvMsg(scrn-scrnIndex, X_WARNING,
(gdb) bt f
#0 0x7ff17f1ad465 in radeon_dri2_destroy_buffer (drawable=0x343bbb0,
buffers=0x342cc40) at radeon_dri2.c:419
scrn = 0x0
pScreen = 0x30a0300
private = 0x343d8f0
#1 0x7ff17f1ad845 in radeon_dri2_unref_buffer (buffer=0x342cc40)
at radeon_dri2.c:585
private = 0x343d8f0
#2 0x7ff17f1ad8ec in radeon_dri2_client_state_changed (
ClientStateCallback=0x860c20 ClientStateCallback, data=0x0,
calldata=0x7fff2094cb90) at radeon_dri2.c:610
pClientEventsPriv = 0x345a4d0
ref = 0x353ca60
clientinfo = 0x7fff2094cb90
pClient = 0x345a410
#3 0x0043fd67 in _CallCallbacks (pcbl=0x860c20 ClientStateCallback,
call_data=0x7fff2094cb90) at dixutils.c:715
cbl = 0x2880a40
cbr = 0x2881050
pcbr = 0x0
#4 0x004311fb in CallCallbacks (pcbl=0x860c20 ClientStateCallback,
call_data=0x7fff2094cb90) at ../include/callback.h:83
No locals.
#5 0x0043926b in CloseDownClient (client=0x345a410) at dispatch.c:3380
clientinfo = {client = 0x345a410, prefix = 0x0, setup = 0x0}
really_close_down = 1
#6 0x004317ab in Dispatch () at dispatch.c:402
clientReady = 0x2ff5ee0
result = -1
client = 0x345a410
nready = 0
icheck = 0x860c30 checkForInput
start_tick = 320
#7 0x00422911 in main (argc=4, argv=0x7fff2094cd58,
envp=0x7fff2094cd80) at main.c:288
i = 2
alwaysCheckForInput = {0, 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 60858] [radeon HD 4570m] Error setting UVD clocks
https://bugzilla.kernel.org/show_bug.cgi?id=60858 --- Comment #7 from Pinak Ahuja pinak.ah...@gmail.com --- Is there anything i can do to check that my BIOS is buggy. -- 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 60858] [radeon HD 4570m] Error setting UVD clocks
https://bugzilla.kernel.org/show_bug.cgi?id=60858 --- Comment #8 from Christian König christian.koe...@amd.com --- You could dig into the code and try to figure out why the post dividers (vclk_div and dclk_div) turn out as 0. The two involved functions are rv770_set_uvd_clocks which can be found here drivers/gpu/drm/radeon/rv770.c and radeon_uvd_calc_upll_dividers which can be found here drivers/gpu/drm/radeon/radeon_uvd.c. The most interesting value is rdev-clock.spll.reference_freq, it is the reference clock frequency coming from a bios table. If that is wrong the whole calculation doesn't work any more and the UPLL generates an invalid frequency. Insert something like DRM_ERROR(Test %d\n, rdev-clock.spll.reference_freq) into the code and see what it spits out on the next reboot. Unfortunately I currently don't have much time to look into this and it seems to still work fine with my RV710, so it must be something special with your laptop. -- 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 0/3] drm/radeon kexec fixes
On 2013.09.08 at 17:32 -0700, Eric W. Biederman wrote: Markus Trippelsdorf mar...@trippelsdorf.de writes: Here are a couple of patches that get kexec working with radeon devices. I've tested this on my RS780. Comments or flames are welcome. Thanks. A couple of high level comments. This looks promising for the usual case. Removing the printk at the end of the kexec path seems a little dubious, what of other cpus, interrupt handlers, etc. Basically estabilishing a new rule on when printk is allowed seems a little dubious at this point, even if it is a useful debugging trick. OK. I will drop this patch. It doesn't seem to be necessary, because I cannot reproduce the printk related hang anymore. Having a clean shutdown of the radeon definitely seems worth doing, because the cases where we care abouty video are when a person is in front of the system. Yes. But please note that even with radeon_pci_shutdown implemented, I still get ring test failures on roughly every eighth kexec boot: [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD) radeon :01:05.0: disabling GPU acceleration That's definitely better than the current state of affairs, with ring test failures on every second boot. But I haven't figured out the reason for these failures yet. It's curious that once a ring test failure occurs, it will reliably fail after each kexec invocation, no matter how often repeated. Only a reboot brings the machine back to normal. I don't know if you want to remove the sanity checks. They seem cheap and safe regardless. Are they expensive or ineffective? Moreover if they work a reasonable amount of the time that means that the kexec on panic case (where we don't shut anything down) can actually use the video, and that in general the driver will be more robust. I don't expect anyone much cares as kexec on panic is mostly used to just write a core file to the network, or the local disk. But if it is easy to keep that case working most of the time, why not. IIRC Alex said the sanity checks are expensive and boot-time could be improved by dropping them. Maybe he can chime in? -- Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
Hi Aaaron,
Have we grown any clue meanwhile about which Intel boxes need this and for
which we still need to keep the acpi backlight around? I've grown _very_
reluctant to just adding tons of quirks to our driver for the backlight.
Almost all the quirks we have added recently (or that have been proposed
to be added) are for the backlight. Imo that indicates we get something
fundamentally wrong ...
Cheers, Daniel
On Mon, Sep 09, 2013 at 04:42:20PM +0800, Aaron Lu wrote:
According to Matthew Garrett, Windows 8 leaves backlight control up
to individual graphics drivers rather than making ACPI calls itself.
There's plenty of evidence to suggest that the Intel driver for
Windows [8] doesn't use the ACPI interface, including the fact that
it's broken on a bunch of machines when the OS claims to support
Windows 8. The simplest thing to do appears to be to disable the
ACPI backlight interface on these systems.
There's a problem with that approach, however, because simply
avoiding to register the ACPI backlight interface if the firmware
calls _OSI for Windows 8 may not work in the following situations:
(1) The ACPI backlight interface actually works on the given system
and the i915 driver is not loaded (e.g. another graphics driver
is used).
(2) The ACPI backlight interface doesn't work on the given system,
but there is a vendor platform driver that will register its
own, equally broken, backlight interface if not prevented from
doing so by the ACPI subsystem.
Therefore we need to allow the ACPI backlight interface to be
registered until the i915 driver is loaded which then will unregister
it if the firmware has called _OSI for Windows 8 (or will register
the ACPI video driver without backlight support if not already
present).
For this reason, introduce an alternative function for registering
ACPI video, __acpi_video_register(bool), that if ture is passed,
will check whether or not the ACPI video driver has already been
registered and whether or not the backlight Windows 8 quirk has to
be applied. If the quirk has to be applied, it will block the ACPI
backlight support and either unregister the backlight interface if
the ACPI video driver has already been registered, or register the
ACPI video driver without the backlight interface otherwise. Make
the i915 driver use __acpi_video_register() instead of
acpi_video_register() in i915_driver_load(), and the param passed
there is controlled by the i915 module level parameter
i915_take_over_backlight, which is set to false by default.
This change is evolved from earlier patches of Matthew Garrett,
Chun-Yi Lee and Seth Forshee and is heavily based on two patches
from Rafael:
https://lkml.org/lkml/2013/7/17/720
https://lkml.org/lkml/2013/7/24/806
Signed-off-by: Aaron Lu aaron...@intel.com
---
drivers/acpi/internal.h | 2 ++
drivers/acpi/video.c| 24
drivers/acpi/video_detect.c | 15 ++-
drivers/gpu/drm/i915/i915_dma.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 5 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
include/acpi/video.h| 9 +++--
include/linux/acpi.h| 1 +
8 files changed, 47 insertions(+), 12 deletions(-)
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 20f4233..a53832e 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -170,8 +170,10 @@ int acpi_create_platform_device(struct acpi_device *adev,
--
*/
#if defined(CONFIG_ACPI_VIDEO) || defined(CONFIG_ACPI_VIDEO_MODULE)
bool acpi_video_backlight_quirks(void);
+bool acpi_video_verify_backlight_support(void);
#else
static inline bool acpi_video_backlight_quirks(void) { return false; }
+static inline bool acpi_video_verify_backlight_support(void) { return false;
}
#endif
#endif /* _ACPI_INTERNAL_H_ */
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 5ad5a71..cc709a7 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -1256,8 +1256,8 @@ acpi_video_switch_brightness(struct acpi_video_device
*device, int event)
unsigned long long level_current, level_next;
int result = -EINVAL;
- /* no warning message if acpi_backlight=vendor is used */
- if (!acpi_video_backlight_support())
+ /* no warning message if acpi_backlight=vendor or a quirk is used */
+ if (!acpi_video_verify_backlight_support())
return 0;
if (!device-brightness)
@@ -1558,7 +1558,7 @@ acpi_video_bus_match(acpi_handle handle, u32 level,
void *context,
static void acpi_video_dev_register_backlight(struct acpi_video_device
*device)
{
- if (acpi_video_backlight_support()) {
+ if (acpi_video_verify_backlight_support()) {
struct backlight_properties props;
struct pci_dev *pdev;
Re: [PATCH 0/3] drm/radeon kexec fixes
Am 09.09.2013 11:21, schrieb Markus Trippelsdorf: On 2013.09.08 at 17:32 -0700, Eric W. Biederman wrote: Markus Trippelsdorf mar...@trippelsdorf.de writes: Here are a couple of patches that get kexec working with radeon devices. I've tested this on my RS780. Comments or flames are welcome. Thanks. A couple of high level comments. This looks promising for the usual case. Removing the printk at the end of the kexec path seems a little dubious, what of other cpus, interrupt handlers, etc. Basically estabilishing a new rule on when printk is allowed seems a little dubious at this point, even if it is a useful debugging trick. OK. I will drop this patch. It doesn't seem to be necessary, because I cannot reproduce the printk related hang anymore. Having a clean shutdown of the radeon definitely seems worth doing, because the cases where we care abouty video are when a person is in front of the system. Yes. But please note that even with radeon_pci_shutdown implemented, I still get ring test failures on roughly every eighth kexec boot: [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD) radeon :01:05.0: disabling GPU acceleration That's definitely better than the current state of affairs, with ring test failures on every second boot. But I haven't figured out the reason for these failures yet. It's curious that once a ring test failure occurs, it will reliably fail after each kexec invocation, no matter how often repeated. Only a reboot brings the machine back to normal. The main problem here is that the AMD gfx hardware doesn't really support being reinitialized once booted (for various reasons). It's a (intended) limitation of the hardware design that you can only initialize certain blocks once every power cycle, so the whole approach actually will never work 100% reliable. All you can hope for is that stopping the hardware while shutting down the old kernel and starting it again results in exactly the same hardware parameters (offsets, clock etc...) otherwise starting the blocks will just fail and you end up with disabled acceleration like above. Sorry, but there isn't much we can do about this, Christian. I don't know if you want to remove the sanity checks. They seem cheap and safe regardless. Are they expensive or ineffective? Moreover if they work a reasonable amount of the time that means that the kexec on panic case (where we don't shut anything down) can actually use the video, and that in general the driver will be more robust. I don't expect anyone much cares as kexec on panic is mostly used to just write a core file to the network, or the local disk. But if it is easy to keep that case working most of the time, why not. IIRC Alex said the sanity checks are expensive and boot-time could be improved by dropping them. Maybe he can chime in? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC v3 08/19] video: display: Add MIPI DBI bus support
Hi Tomi, On Monday 26 August 2013 14:10:50 Tomi Valkeinen wrote: On 09/08/13 20:14, Laurent Pinchart wrote: MIPI DBI is a configurable-width parallel display bus that transmits commands and data. Add a new DBI Linux bus type that implements the usual bus infrastructure (including devices and drivers (un)registration and matching, and bus configuration and access functions). This has been discussed before, but I don't remember that the issue would have been cleared, so I'm bringing it up again. What benefit does a real Linux DBI (or DSI) bus give us, compared to representing the DBI the same way as DPI? DBI DSI are in practice point- to-point buses, and they do not support probing. Is it just that because DBI and DSI can be used to control a device, they have to be Linux buses? The idea was to reuse the Linux bus infrastructure to benefit from features such as power management. Implementing DBI/DSI control functions using a DBI/DSI bus is also pretty easy, and would allow controlling DBI/DSI entities much like we control I2C entities. I don't like the idea of using an I2C bus with I2C access functions on one side, and embedding the DBI/DSI access functions as part of CDF entity operations on the other side very much. This being said, this isn't the part of CDF that matters the most to me (it's actually not part of CDF strictly speaking). If your model works well enough it won't be too hard to convince me :-) How do you see handling the devices where DBI or DSI is used for video only, and the control is handled via, say, i2c? The module has to register two drivers, and try to keep those in sync? I feel that could get rather hacky. If DBI or DSI is used for video only you don't need DBI/DSI control operations, right ? So the entity driver will just be a regular I2C device driver. A real Linux bus would be necessary if we had devices that used DBI or DSI only for control, and some other video bus for video data. But that sounds so silly that I think we can just forget about the case. I certainly hope so :-) Thus DBI and DSI are used either for video only, or video and control. -- Regards, Laurent Pinchart signature.asc Description: This is a digitally signed message part. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] ACPI / video: seperate backlight control and event interface
The backlight control and event delivery functionality provided by ACPI
video module is mixed together and registered all during video device
enumeration time. As a result, the two functionality are also removed
together on module unload time or by the acpi_video_unregister function.
The two functionalities are actually independent and one may be useful
while the other one may be broken, so it is desirable to seperate the
two functionalities such that it is clear and easy to disable one
functionality without affecting the other one. This patch does the
seperation and as a result, a new video_bus_head list is introduced to
store all registered video bus structure and a new function
acpi_video_unregister_backlight is introduced to unregister backlight
interfaces for all video devices belonging to stored video buses.
Currently, there is no need to unregister ACPI video's event delivery
functionality alone so the function acpi_video_remove_notify_handler is
not introduced, it can be easily added when needed.
Signed-off-by: Aaron Lu aaron...@intel.com
---
drivers/acpi/video.c | 451 ++-
include/acpi/video.h | 2 +
2 files changed, 264 insertions(+), 189 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index aebcf63..5ad5a71 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -89,6 +89,8 @@ static bool use_bios_initial_backlight = 1;
module_param(use_bios_initial_backlight, bool, 0644);
static int register_count;
+static struct mutex video_list_lock;
+static struct list_head video_bus_head;
static int acpi_video_bus_add(struct acpi_device *device);
static int acpi_video_bus_remove(struct acpi_device *device);
static void acpi_video_bus_notify(struct acpi_device *device, u32 event);
@@ -157,6 +159,7 @@ struct acpi_video_bus {
struct acpi_video_bus_flags flags;
struct list_head video_device_list;
struct mutex device_list_lock; /* protects video_device_list */
+ struct list_head entry;
struct input_dev *input;
char phys[32]; /* for input device */
struct notifier_block pm_nb;
@@ -884,79 +887,6 @@ static void acpi_video_device_find_cap(struct
acpi_video_device *device)
if (acpi_has_method(device-dev-handle, _DDC))
device-cap._DDC = 1;
-
- if (acpi_video_backlight_support()) {
- struct backlight_properties props;
- struct pci_dev *pdev;
- acpi_handle acpi_parent;
- struct device *parent = NULL;
- int result;
- static int count;
- char *name;
-
- result = acpi_video_init_brightness(device);
- if (result)
- return;
- name = kasprintf(GFP_KERNEL, acpi_video%d, count);
- if (!name)
- return;
- count++;
-
- acpi_get_parent(device-dev-handle, acpi_parent);
-
- pdev = acpi_get_pci_dev(acpi_parent);
- if (pdev) {
- parent = pdev-dev;
- pci_dev_put(pdev);
- }
-
- memset(props, 0, sizeof(struct backlight_properties));
- props.type = BACKLIGHT_FIRMWARE;
- props.max_brightness = device-brightness-count - 3;
- device-backlight = backlight_device_register(name,
- parent,
- device,
-
acpi_backlight_ops,
- props);
- kfree(name);
- if (IS_ERR(device-backlight))
- return;
-
- /*
-* Save current brightness level in case we have to restore it
-* before acpi_video_device_lcd_set_level() is called next time.
-*/
- device-backlight-props.brightness =
- acpi_video_get_brightness(device-backlight);
-
- device-cooling_dev = thermal_cooling_device_register(LCD,
- device-dev, video_cooling_ops);
- if (IS_ERR(device-cooling_dev)) {
- /*
-* Set cooling_dev to NULL so we don't crash trying to
-* free it.
-* Also, why the hell we are returning early and
-* not attempt to register video output if cooling
-* device registration failed?
-* -- dtor
-*/
- device-cooling_dev = NULL;
- return;
- }
-
- dev_info(device-dev-dev, registered as cooling_device%d\n,
-
Re: [PATCH/RFC v3 08/19] video: display: Add MIPI DBI bus support
Hi Vikas,
On Wednesday 04 September 2013 16:20:59 Vikas Sajjan wrote:
On 9 August 2013 22:44, Laurent Pinchart wrote:
MIPI DBI is a configurable-width parallel display bus that transmits
commands and data.
Add a new DBI Linux bus type that implements the usual bus
infrastructure (including devices and drivers (un)registration and
matching, and bus configuration and access functions).
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/display/Kconfig| 8 ++
drivers/video/display/Makefile | 1 +
drivers/video/display/mipi-dbi-bus.c | 234 ++
include/video/display.h | 4 +
include/video/mipi-dbi-bus.h | 125 +++
5 files changed, 372 insertions(+)
create mode 100644 drivers/video/display/mipi-dbi-bus.c
create mode 100644 include/video/mipi-dbi-bus.h
[snip]
diff --git a/drivers/video/display/mipi-dbi-bus.c
b/drivers/video/display/mipi-dbi-bus.c new file mode 100644
index 000..791fb4d
--- /dev/null
+++ b/drivers/video/display/mipi-dbi-bus.c
[snip]
+/* --
+ * Device and driver (un)registration
+ */
+
+/**
+ * mipi_dbi_device_register - register a DBI device
+ * @dev: DBI device we're registering
+ */
+int mipi_dbi_device_register(struct mipi_dbi_device *dev,
+ struct mipi_dbi_bus *bus)
+{
+ device_initialize(dev-dev);
+
+ dev-bus = bus;
+ dev-dev.bus = mipi_dbi_bus_type;
+ dev-dev.parent = bus-dev;
+
+ if (dev-id != -1)
+ dev_set_name(dev-dev, %s.%d, dev-name, dev-id);
+ else
+ dev_set_name(dev-dev, %s, dev-name);
+
+ return device_add(dev-dev);
+}
The function looks very much specific to NON-DT case where you will be
calling mipi_dbi_device_register() in the machine file.
You're absolutely right.
I was actually trying to migrate to CDFv3 and adding MIPI DSI support
for exynos5250,
but in my case where exynos5250 is fully DT based, in which case we
need something like ./drivers/of/platform.c for MIPI DBI and MIPI DSI
to add the MIPI DBI/DSI device via DT way, ./drivers/of/mipi_dbi.c and
./drivers/of/mipi_dsi.c
may look like below,
int of_mipi_dbi_device_register(struct device_node *np,
const char *bus_id,
struct device *parent)
{
struct mipi_dbi_device *dev;
dev = of_device_alloc(np, bus_id, parent);
if (!dev)
return NULL;
device_initialize(dev);
dev-bus = mipi_dbi_bus_type;
dev-parent = parent;
return of_device_add(dev);
}
Correct me if I am wrong.
You're correct, but the implementation will need to be a little bit more
complex than that. From an API point of view, something like
of_i2c_register_devices() (drivers/of/of_i2c.c) would probably make sense. the
function should iterate over child nodes, and call
of_mipi_dbi_device_register() (we could maybe rename that to
of_mipi_dbi_device_create() to mimic the platform device code) for each child.
In your above code, you should replace of_device_alloc() with
of_mipi_dbi_device_alloc(), as of_device_alloc() allocates a struct
platform_device. You should also call mipi_dsi_device_put() on the device if
of_device_add() returns a failure.
Would you like to send a patch on top of 08/19 to implement this ?
+EXPORT_SYMBOL_GPL(mipi_dbi_device_register);
+
+/**
+ * mipi_dbi_device_unregister - unregister a DBI device
+ * @dev: DBI device we're unregistering
+ */
+void mipi_dbi_device_unregister(struct mipi_dbi_device *dev)
+{
+ device_del(dev-dev);
+ put_device(dev-dev);
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_device_unregister);
+
+static int mipi_dbi_drv_probe(struct device *_dev)
+{
+ struct mipi_dbi_driver *drv = to_mipi_dbi_driver(_dev-driver);
+ struct mipi_dbi_device *dev = to_mipi_dbi_device(_dev);
Here we are assuming that mipi_dbi_device can be obtained by using
_dev pointer, which may NOT be true in DT case, i think.
Why wouldn't it be true (if we create the devices as explained above) ?
let me know if i am missing something.
if you can give me a example for DT case, that would be helpful.
I'm afraid I don't have any, as the DBI drivers I wrote are used by a platform
that doesn't support DT.
+
+ return drv-probe(dev);
+}
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC v3 08/19] video: display: Add MIPI DBI bus support
Hi Vikas,
On Wednesday 04 September 2013 18:22:45 Vikas Sajjan wrote:
On 9 August 2013 22:44, Laurent Pinchart wrote:
MIPI DBI is a configurable-width parallel display bus that transmits
commands and data.
Add a new DBI Linux bus type that implements the usual bus
infrastructure (including devices and drivers (un)registration and
matching, and bus configuration and access functions).
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/display/Kconfig| 8 ++
drivers/video/display/Makefile | 1 +
drivers/video/display/mipi-dbi-bus.c | 234 ++
include/video/display.h | 4 +
include/video/mipi-dbi-bus.h | 125 +++
5 files changed, 372 insertions(+)
create mode 100644 drivers/video/display/mipi-dbi-bus.c
create mode 100644 include/video/mipi-dbi-bus.h
[snip]
diff --git a/drivers/video/display/mipi-dbi-bus.c
b/drivers/video/display/mipi-dbi-bus.c new file mode 100644
index 000..791fb4d
--- /dev/null
+++ b/drivers/video/display/mipi-dbi-bus.c
[snip]
+/* --
+ * Bus operations
+ */
+
+int mipi_dbi_set_data_width(struct mipi_dbi_device *dev, unsigned int
width)
+{
+ if (width != 8 width != 16)
+ return -EINVAL;
+
+ dev-data_width = width;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(mipi_dbi_set_data_width);
+
+int mipi_dbi_write_command(struct mipi_dbi_device *dev, u16 cmd)
+{
+ return dev-bus-ops-write_command(dev-bus, dev, cmd);
Can you help me in pointing out where these function pointer
(ops-write_command) are assigned in case MIPI DBI.
In case of exynos (drivers/video/exynos/exynos_mipi_dsi.c), we
assign them as below and register DSI as a platform device
static struct mipi_dsim_master_ops master_ops = {
.cmd_read = exynos_mipi_dsi_rd_data,
.cmd_write = exynos_mipi_dsi_wr_data,
.get_dsim_frame_done=
exynos_mipi_dsi_get_frame_done_status,
.clear_dsim_frame_done = exynos_mipi_dsi_clear_frame_done,
.set_early_blank_mode = exynos_mipi_dsi_early_blank_mode,
.set_blank_mode = exynos_mipi_dsi_blank_mode, };
Since now you are saying to have it as linux BUS, how should we
register these ops and how we can configure the MIPI DSI hw itself if
we register it as bus. I could not find any help in mipi-dbi-bus.c,
how we actually configure the MIPI DBI h/w itself.
ideally mipi-dbi-bus.c should have done 2 things
==
1. provide a framework to register the DBI kind of panel = which is
supported
2. provide a framework to register the actuall MIPI DBI H/W itself =
which i think is missing (correct me, if i am missing anything)
Indeed, you're right... I'll go hide in a dark corner now.
Thinking about it, I should instead implement the missing code, that would
more helpful.
The patch is missing MIPI DBI bus registration. If you have already written
bus registration code feel free to send a patch, otherwise I'll fix it (I'll
wait for your confirmation first).
+}
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC v3 08/19] video: display: Add MIPI DBI bus support
On 06/09/13 17:09, Laurent Pinchart wrote: Hi Tomi, On Monday 26 August 2013 14:10:50 Tomi Valkeinen wrote: On 09/08/13 20:14, Laurent Pinchart wrote: MIPI DBI is a configurable-width parallel display bus that transmits commands and data. Add a new DBI Linux bus type that implements the usual bus infrastructure (including devices and drivers (un)registration and matching, and bus configuration and access functions). This has been discussed before, but I don't remember that the issue would have been cleared, so I'm bringing it up again. What benefit does a real Linux DBI (or DSI) bus give us, compared to representing the DBI the same way as DPI? DBI DSI are in practice point- to-point buses, and they do not support probing. Is it just that because DBI and DSI can be used to control a device, they have to be Linux buses? The idea was to reuse the Linux bus infrastructure to benefit from features such as power management. Implementing DBI/DSI control functions using a DBI/DSI bus is also pretty easy, and would allow controlling DBI/DSI entities much like we control I2C entities. I don't like the idea of using an I2C bus with I2C access functions on one side, and embedding the DBI/DSI access functions as part of CDF entity operations on the other side very much. While I somewhat like the thought of having DBI and DSI as Linux buses, I just don't see how it would work. Well, I'm mostly thinking about DSI here, I have not used DBI for years. Also, I might remember wrong, but I think I saw Linus expressing his opinion at some point that he doesn't really like the idea of having a Linux bus for simple point-to-point buses, which don't have probing support, and so there isn't much bus to speak of, just a point to point link. And I think we get the same power management with just having a device as a child device of another. This being said, this isn't the part of CDF that matters the most to me (it's actually not part of CDF strictly speaking). If your model works well enough it won't be too hard to convince me :-) How do you see handling the devices where DBI or DSI is used for video only, and the control is handled via, say, i2c? The module has to register two drivers, and try to keep those in sync? I feel that could get rather hacky. If DBI or DSI is used for video only you don't need DBI/DSI control operations, right ? So the entity driver will just be a regular I2C device driver. Well, DSI can't be used just like that. You need to configure it. The thing is, DSI is used for both control and video. They are really the same thing, both are sent as DSI packets. Both need similar kind of configuration for the bus. If the DSI peripheral sits on a DSI bus, I imagine this configuration is done via the DSI bus support. But if there's no DSI bus, how is the configuration done? I guess a possibility is to have a fixed configuration that cannot be changed dynamically. But I have a feeling that it'll be a bit limiting for some cases. And even with fixed configuration, I think the configuration would somehow be passed as DSI bus parameters from the board files or in the DT data (the same way as, say i2c bus speed). If there's no DSI bus, as the DSI peripheral sits on the i2c bus, where are the parameters? Tomi signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: Tree for Aug 30 (nouveau)
On 08/30/13 12:59, Randy Dunlap wrote: On 08/29/13 03:00, Stephen Rothwell wrote: Hi all, on x86_64: ERROR: nouveau_switcheroo_optimus_dsm [drivers/gpu/drm/nouveau/nouveau.ko] undefined! Full randconfig file is attached. This build error still happens in linux-next of 20130906. -- ~Randy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC v3 00/19] Common Display Framework
Hi Rob and Sascha, On Wednesday 21 August 2013 08:22:59 Rob Clark wrote: On Wed, Aug 21, 2013 at 3:09 AM, Sascha Hauer wrote: On Tue, Aug 20, 2013 at 02:40:55PM -0400, Rob Clark wrote: On Tue, Aug 20, 2013 at 11:24 AM, Laurent Pinchart wrote: Hi Rob, Or maybe, put another way, I still think we should still optimize for the common case. I mean I'm sure you *can* design hw that has an LVDS-DP bridge in the capture path, and if you had something like an FPGA where that was cheap to do maybe you even would (for fun). But if in the real world, there are only one or two cases of actual hw using the same bridge in a capture pipeline which is normally used in display pipelines, then duplicating some small bit of code for that abnormal case if it makes things easier for the common case, seems like a reasonable trade-off to me. That was my opinion as well until I started working on a Xilinx platform. There's dozens of IP cores there that are used in both capture and display pipelines. or maybe just some helper lib's to handling the register level programming? Many chips and IP cores in KMS and V4L2 pipelines are pretty simple, and the bulk of the driver is just an API implementation. Register poking is usually a small percentage of the code (that's of course not the case for the more complex IP cores, but those are usually not shared). Anyways, I guess you can call it a worse is better thing, but if you can get 90% of the desired effect for 10% of the work, take the simpler solution. I don't think we should make things more layered or more difficult for one exceptional case. The point is I believe they will become less and less exceptional over time. One might argue that CDF is a revolutionary approach as opposed to an evolutionary approach, but looking at the future I believe we'll need a much bigger disruption if we wait too long. Furthermore, FPGA display pipelines being made of individual IP cores, we need a way to write one driver per IP core and make them all interact. The recently proposed drm_bridge is one possible solution to this issue (and to a different but similar issue that trigerred the development of drm_bridge), but it's in my opinion not generic enough. We're facing several problems that are related, it would really be a shame not to solve them with a good enough framework. well, I've been working on DSI panel support in msm drm, and also been looking at the patches to add DSI support in i915. And the panel interface ends up looking basically like the drm_bridge interface. Perhaps the only thing not generic there is the name. Don't get me wrong, drm_bridge is an interesting idea, but I think it's a bit limited. I mean, take a DSI panel driver, for example.. anything but a trivial panel driver, you are going to want to expose some custom properties on the connector for controlling non-standard features. So you end up with both cdf_foo for the common part, and drm_foo for gluing in the properties. And now these two parts which otherwise would be one, end up having to stay in sync merged through different trees, etc. It seems a lot like making my life more difficult for a fairly hypothetical gain ;-) The DSI panel driver should not be split into two parts. It should implement a CDF entity, any glue needed for DRM will not be part of the panel driver. right, but that glue ends up needing to be *somewhere*, which makes it the 2nd part. Or, take an hdmi or DP bridge. To use any of the common infrastructure/helpers in drm, you end up implementing a generic interface, where both the producer and consumer is inside drm. Which just seems a bit pointless and extra hoops to jump through. Especially when we discover that we need to extend/enhance the common interface outside of drm to make it work. (I'm thinking of display_entity_control_ops::get_modes() here, but I'm sure there are more examples.) And I think we'll run into similar issues with display_entity_control_ops::set_state(), since the on-off sequencing can get hairy when the upstream/downstream entity is fed a clk by the downstream/upstream entity. And similarly, I think we'll go through a few revisions of DSI panel/bus params before we have everything that everyone needs. I don't see where needing multiple revisions of a patch set would be bad :-) I mean over multiple kernel revisions, as people start adding support for new hw and run into limitations of the framework. A framework can be changed, extended and fixed. In the end we talking about a completely in-kernel framework for which we do not have to maintain a stable API. oh sure, this is why I'd be absolutely against exposing this to userspace currently.. At least we agree on that, good :-) But my only point here was that an in-drm framework, all the fix-ups due to
8086:0166 [ThinkPad Twist S230u 3347] REGRESSION: Mirroring display works only with 1024x768 (4:3) whereas my laptop has 1366x768 (16:9) external monitor 1920x1080 (16:9)
See the following Ubuntu bug report https://bugs.launchpad.net/bugs/1167301 Original bug report --- I have a Lenovo Thinkpad Twist with an internal 1366x768 (16:9) display and I have connected and external 1920x1080 (16:9) monitor via HDMI. By default the display gets mirrored with only 1024x768 (4:3) because this is the highest common resolution of the two reported by xrandr. I can switch to a large desktop formed by the two screens with the System Settings (section Display) with each screen using its native resolution. This is a kernel regression from 3.8.0-7-generic to 3.8.0-19. I can mirror with a higher resolution running the commands: xrandr --addmode HDMI1 1366x768 xrandr --output HDMI1 --mode 1366x768 xrandr --output HDMI1 --mode 1366x768 --same-as LVDS1 This is rather awkward when using a projector. The problem also persists when connecting the external screen to the Mini DisplayPort (with adapter) instead of to the HDMI. I did not test with 12.10 by myself, but according to the comment from Gizmo Chicken below this worked correctly under 12.10, so this is a regression and not a feature request. The output of xrandr --prop with both screens connected in large-desktop-over-both-screens mode (no mirroring): Screen 0: minimum 320 x 200, current 3286 x 1080, maximum 32767 x 32767 LVDS1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 277mm x 156mm EDID: 000030e47a03 00160103801c10780adce5975a559227 1d50540001010101010101010101 010101010101241d56d4500016303020 2500159c101b 00fe004c 4720446973706c61790a202000fe 004c503132355748322d534c54310025 BACKLIGHT: 1054 (0x041e) range: (0,1054) Backlight: 1054 (0x041e) range: (0,1054) scaling mode: Full aspect supported: None Full Center Full aspect 1366x768 59.8*+ 1360x768 59.8 60.0 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 connected 1920x1080+1366+0 (normal left inverted right x axis y axis) 510mm x 287mm EDID: 000015c3692001010101 2d14010380331d78eaee95a3544c9926 0f5054a1080081808140b30081c00101 010101010101023a801871382d40582c 4500fe1f111e00ff00353732 32393131300a2020202000fc0045 563233570a202020202000fd 003b3d1f440f000a2020202020200153 02031b41468102031112042309070783 0167030c001300881e8c0ad08a20 e02d10103e9600040300188c0ad0 8a20e02d10103e9600100900188c 0ad090204031200c405500040300 188c0ad090204031200c405500100900 18011d007251d01e206e28550010 09001e5c Broadcast RGB: Automatic supported: Automatic Full Limited 16:2 audio: auto supported: force-dvi off auto on 1920x1080 60.0*+ 1680x1050 59.9 1280x1024 60.0 1280x960 60.0 1280x720 60.0 1024x768 60.0 800x600 60.3 720x576 50.0 720x480 59.9 640x480 60.0 59.9 720x400 70.1 DP1 disconnected (normal left inverted right x axis y axis) Broadcast RGB: Automatic supported: Automatic Full Limited 16:2 audio: auto supported: force-dvi off auto on HDMI2 disconnected (normal left inverted right x axis y axis) Broadcast RGB: Automatic supported: Automatic Full Limited 16:2 audio: auto supported: force-dvi off auto on DP2 disconnected (normal left inverted right x axis y axis) Broadcast RGB: Automatic supported: Automatic Full Limited 16:2 audio: auto supported: force-dvi off auto on Additional information -- The problem occurs on both Ubuntu Raring and Saucy systems and (see the comments in the bug report) I have tried several mainline kernels from 3.8.1 to 3.11: 3.11.0-rc3, 3.11.0, and also 3.10.0, 3.9.0, 3.8.1. They all show the problem. Mainline kernel 3.8.0 is the newest where the problem does not occur. Bisect result on upstream kernel Then I have done a bisect based on git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git finding that the following patch is the culprit: till@till-twist:~/kernel/linux-stable$ git bisect good 740922ee575f8ee4daa2bfd3db5f69dd7573fc76 is the first bad commit commit 740922ee575f8ee4daa2bfd3db5f69dd7573fc76 Author: Paulo Zanoni paulo.r.zan...@intel.com Date: Fri Feb 15 13:36:27 2013 -0200 drm: don't add inferred modes for monitors that don't support them commit 196e077dc165a307efbd9e7569f81bbdbcf18f65 upstream. If bit 0 of the features byte (0x18) is set to 0, then, according to the EDID spec, the display is non-continuous frequency (multi-mode) and is only specified to accept the video timing formats that are listed in Base EDID and certain Extension Blocks. For more information, please see the EDID spec, check the notes of the table that explains the Feature Support byte (18h) and also the notes on the tables of the section that explains Display Range Limits Additional Timing
Re: [PATCH/RFC v3 08/19] video: display: Add MIPI DBI bus support
On 06/09/13 18:43, Tomi Valkeinen wrote: On 06/09/13 17:09, Laurent Pinchart wrote: Hi Tomi, On Monday 26 August 2013 14:10:50 Tomi Valkeinen wrote: On 09/08/13 20:14, Laurent Pinchart wrote: MIPI DBI is a configurable-width parallel display bus that transmits commands and data. Add a new DBI Linux bus type that implements the usual bus infrastructure (including devices and drivers (un)registration and matching, and bus configuration and access functions). This has been discussed before, but I don't remember that the issue would have been cleared, so I'm bringing it up again. What benefit does a real Linux DBI (or DSI) bus give us, compared to representing the DBI the same way as DPI? DBI DSI are in practice point- to-point buses, and they do not support probing. Is it just that because DBI and DSI can be used to control a device, they have to be Linux buses? The idea was to reuse the Linux bus infrastructure to benefit from features such as power management. Implementing DBI/DSI control functions using a DBI/DSI bus is also pretty easy, and would allow controlling DBI/DSI entities much like we control I2C entities. I don't like the idea of using an I2C bus with I2C access functions on one side, and embedding the DBI/DSI access functions as part of CDF entity operations on the other side very much. While I somewhat like the thought of having DBI and DSI as Linux buses, I just don't see how it would work. Well, I'm mostly thinking about DSI here, I have not used DBI for years. Also, I might remember wrong, but I think I saw Linus expressing his opinion at some point that he doesn't really like the idea of having a Linux bus for simple point-to-point buses, which don't have probing support, and so there isn't much bus to speak of, just a point to point link. And I think we get the same power management with just having a device as a child device of another. This being said, this isn't the part of CDF that matters the most to me (it's actually not part of CDF strictly speaking). If your model works well enough it won't be too hard to convince me :-) How do you see handling the devices where DBI or DSI is used for video only, and the control is handled via, say, i2c? The module has to register two drivers, and try to keep those in sync? I feel that could get rather hacky. If DBI or DSI is used for video only you don't need DBI/DSI control operations, right ? So the entity driver will just be a regular I2C device driver. Well, DSI can't be used just like that. You need to configure it. The thing is, DSI is used for both control and video. They are really the same thing, both are sent as DSI packets. Both need similar kind of configuration for the bus. If the DSI peripheral sits on a DSI bus, I imagine this configuration is done via the DSI bus support. But if there's no DSI bus, how is the configuration done? I guess a possibility is to have a fixed configuration that cannot be changed dynamically. But I have a feeling that it'll be a bit limiting for some cases. And even with fixed configuration, I think the configuration would somehow be passed as DSI bus parameters from the board files or in the DT data (the same way as, say i2c bus speed). If there's no DSI bus, as the DSI peripheral sits on the i2c bus, where are the parameters? Continuing my thoughts on the bus issue, I think there's a fundamental difference between real buses like i2c and DSI/DBI: i2c peripherals are designed with the mind set that there are other peripherals on the bus, whereas DSI/DBI peripherals are known to be alone, and the DSI/DBI peripheral may thus require the bus parameters to be changed according to the whims of the peripheral. Some examples coming to my mind from the hardware I know are the need to change the DBI bus width depending on what is being sent, changing the DSI bus clock speed, changing DSI return packet size. It's ok for the DBI/DSI peripheral HW designers to require things like that, because the spec doesn't say those can't be done, and the peripheral is alone on the bus. We can support those kinds of operations both with the bus model you have, and my no-bus model. But with your bus model, I believe at least some of those operations may be needed even when the peripheral is controlled via i2c/spi. This also is related to the control model. I'm not sure of the details of the pipeline controller, but I fear that having the controller be the entity that knows about the strange needs of individual video peripherals will lead to lots of customized controllers for individual boards. That said, I agree that it's difficult to embed all the information into individual device drivers (although that's where it should be), because sometimes a wider view of the pipeline is needed to properly configure things. Tomi signature.asc Description: OpenPGP digital signature ___ dri-devel
Patch for quirking Asus tx300 and others incorrect edp bpp value
Patch against Linus' latest git, fixing bug 59841 reported at
https://bugzilla.kernel.org/show_bug.cgi?id=59841
The Intel HD Graphics 4000 PCI display controller id 0x0166 appears to
return an incorrect edp bpp value 16 instead of the correct 24. This
patch adds a quirk for the controller.
Date: Sat, 7 Sep 2013 12:18:31 +0300
Subject: [PATCH] i915: add quirk to ignore incorrect edp_bpp value on Asus
TX300 and others
Signed-off-by: Jyrki Kuoppala j...@iki.fi
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 16
drivers/gpu/drm/i915/intel_dp.c | 3 ++-
3 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 52a3785..3784be1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -651,6 +651,7 @@ enum intel_sbi_destination {
#define QUIRK_LVDS_SSC_DISABLE (11)
#define QUIRK_INVERT_BRIGHTNESS (12)
#define QUIRK_NO_PCH_PWM_ENABLE (13)
+#define QUIRK_IGNORE_EDP_BPP (14)
struct intel_fbdev;
struct intel_fbc_work;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 38452d8..2a8cec3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9907,6 +9907,17 @@ static void quirk_no_pcm_pwm_enable(struct
drm_device *dev)
DRM_INFO(applying no-PCH_PWM_ENABLE quirk\n);
}
+/*
+ * Some machines (e.g. Asus TX300) incorrectly return 18bpp in UEFI mode
+ * from vbe edp data
+ */
+static void quirk_no_edp_bpp_enable(struct drm_device *dev)
+{
+struct drm_i915_private *dev_priv = dev-dev_private;
+dev_priv-quirks |= QUIRK_IGNORE_EDP_BPP;
+DRM_INFO(applying IGNORE_EDP_BPP quirk\n);
+}
+
struct intel_quirk {
int device;
int subsystem_vendor;
@@ -9981,6 +9992,11 @@ static struct intel_quirk intel_quirks[] = {
{ 0x0116, 0x1028, 0x052e, quirk_no_pcm_pwm_enable },
/* Dell XPS13 HD and XPS13 FHD Ivy Bridge */
{ 0x0166, 0x1028, 0x058b, quirk_no_pcm_pwm_enable },
+
+/* at least Asus TX300 (0x1042 0x15b7),
+ UX32VD (0x1042 0x1507), Dell XPS13 and Toshiba Kirabook,
+ see https://bugzilla.kernel.org/show_bug.cgi?id=59841 */
+{ 0x0166, PCI_ANY_ID, PCI_ANY_ID, quirk_no_edp_bpp_enable },
};
static void intel_init_quirks(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index 2151d13..0e0fc37 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -731,7 +731,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
/* Walk through all bpp values. Luckily they're all nicely spaced
with 2
* bpc in between. */
bpp = pipe_config-pipe_bpp;
-if (is_edp(intel_dp) dev_priv-vbt.edp_bpp) {
+if (is_edp(intel_dp) dev_priv-vbt.edp_bpp
+ !(dev_priv-quirks QUIRK_IGNORE_EDP_BPP)) {
DRM_DEBUG_KMS(clamping bpp for eDP panel to BIOS-provided %i\n,
dev_priv-vbt.edp_bpp);
bpp = min_t(int, bpp, dev_priv-vbt.edp_bpp);
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Patch for i915 module load parameter to igore edp bpp value
Patch against Linus' latest git, fixing bug 59841 reported at
https://bugzilla.kernel.org/show_bug.cgi?id=59841 for the cases where
a quirk has not been added to the kernel for specific hardware.
At least one Intel HD Graphics 4000 PCI display controller hardware with
PCI id 0x0166 appears to return an incorrect edp bpp value 18 instead of
the correct 24. This patch allows user to set a flag at
module load time to ignore the incorrect edp bpp value.
Correction to previous patch notes: the edp bpp value returned is 18,
not 16 as erroneusly claimed in previous patch (quirking the feature).
Date: Sat, 7 Sep 2013 13:17:59 +0300
Subject: [PATCH] i915: add module load parameter to ignore incorrect edp_bpp
value
Signed-off-by: Jyrki Kuoppala j...@iki.fi
---
drivers/gpu/drm/i915/i915_drv.c | 4
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_dp.c | 1 +
3 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index ccb28ea..debb785 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -136,6 +136,10 @@ int i915_enable_ips __read_mostly = 1;
module_param_named(enable_ips, i915_enable_ips, int, 0600);
MODULE_PARM_DESC(enable_ips, Enable IPS (default: true));
+bool i915_ignore_edp_bpp __read_mostly;
+module_param_named(i915_ignore_edp_bpp, i915_ignore_edp_bpp, bool, 0600);
+MODULE_PARM_DESC(i915_ignore_edp_bpp, Ignore BDB edp BPP value
(default: false));
+
bool i915_fastboot __read_mostly = 0;
module_param_named(fastboot, i915_fastboot, bool, 0600);
MODULE_PARM_DESC(fastboot, Try to skip unnecessary mode sets at boot
time
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 3784be1..95b1abe 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1707,6 +1707,7 @@ extern int i915_enable_psr __read_mostly;
extern unsigned int i915_preliminary_hw_support __read_mostly;
extern int i915_disable_power_well __read_mostly;
extern int i915_enable_ips __read_mostly;
+extern bool i915_ignore_edp_bpp __read_mostly;
extern bool i915_fastboot __read_mostly;
extern int i915_enable_pc8 __read_mostly;
extern int i915_pc8_timeout __read_mostly;
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index 0e0fc37..a3442cd 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -732,6 +732,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
* bpc in between. */
bpp = pipe_config-pipe_bpp;
if (is_edp(intel_dp) dev_priv-vbt.edp_bpp
+!i915_ignore_edp_bpp
!(dev_priv-quirks QUIRK_IGNORE_EDP_BPP)) {
DRM_DEBUG_KMS(clamping bpp for eDP panel to BIOS-provided
%i\n,
dev_priv-vbt.edp_bpp);
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] nouveau: fix reclocking on nv40
On Wednesday 21 August 2013 02:24:01 Ben Skeggs wrote: On Mon, Aug 19, 2013 at 4:59 PM, Pali Rohár pali.ro...@gmail.com wrote: On Friday 16 August 2013 14:57:07 Pali Rohár wrote: In commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was introduced error which cause that reclocking on nv40 not working anymore. There is missing assigment of return value from pll_calc to ret. Signed-off-by: Pali Rohár pali.ro...@gmail.com Signed-off-by: Martin Peres martin.pe...@labri.fr --- drivers/gpu/drm/nouveau/nv40_pm.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c b/drivers/gpu/drm/nouveau/nv40_pm.c index 3af5bcd..625f80d 100644 --- a/drivers/gpu/drm/nouveau/nv40_pm.c +++ b/drivers/gpu/drm/nouveau/nv40_pm.c @@ -131,7 +131,7 @@ nv40_calc_pll(struct drm_device *dev, u32 reg, struct nvbios_pll *pll, if (clk pll-vco1.max_freq) pll-vco2.max_freq = 0; - pclk-pll_calc(pclk, pll, clk, coef); + ret = pclk-pll_calc(pclk, pll, clk, coef); if (ret == 0) return -ERANGE; Hello, it is possible to include this patch in 3.11? Or it is too late now and need to wait for 3.12? I've picked up the patch and will submit it in my next 3.11-fixes pull request. Thanks, Ben. Hello, now I see that patch is in 3.11, thanks! Ben, what do you think, can be this patch backported to older kernels? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/radeon kexec fixes
Markus Trippelsdorf mar...@trippelsdorf.de writes: Here are a couple of patches that get kexec working with radeon devices. I've tested this on my RS780. Comments or flames are welcome. Thanks. A couple of high level comments. This looks promising for the usual case. Removing the printk at the end of the kexec path seems a little dubious, what of other cpus, interrupt handlers, etc. Basically estabilishing a new rule on when printk is allowed seems a little dubious at this point, even if it is a useful debugging trick. Having a clean shutdown of the radeon definitely seems worth doing, because the cases where we care abouty video are when a person is in front of the system. I don't know if you want to remove the sanity checks. They seem cheap and safe regardless. Are they expensive or ineffective? Moreover if they work a reasonable amount of the time that means that the kexec on panic case (where we don't shut anything down) can actually use the video, and that in general the driver will be more robust. I don't expect anyone much cares as kexec on panic is mostly used to just write a core file to the network, or the local disk. But if it is easy to keep that case working most of the time, why not. Eric Markus Trippelsdorf (3): kexec: get rid of late printk drm/radeon: Implement radeon_pci_shutdown drm/radeon: get rid of r100_restore_sanity hack drivers/gpu/drm/radeon/r100.c| 27 --- drivers/gpu/drm/radeon/r300.c| 2 -- drivers/gpu/drm/radeon/r420.c| 2 -- drivers/gpu/drm/radeon/r520.c| 2 -- drivers/gpu/drm/radeon/radeon_asic.h | 1 - drivers/gpu/drm/radeon/radeon_drv.c | 10 ++ drivers/gpu/drm/radeon/rs400.c | 2 -- drivers/gpu/drm/radeon/rs600.c | 2 -- drivers/gpu/drm/radeon/rs690.c | 2 -- drivers/gpu/drm/radeon/rv515.c | 2 -- kernel/kexec.c | 1 - 11 files changed, 10 insertions(+), 43 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] Rework ACPI video driver
The ACPI video module provides two functionalities: backlight control and backlight hotkey event delivery. It is possible the backlight control interface is broken while the system still needs its event delivery, so it's worth to seperate the two interfaces clearly. This patchset has two patches, the first is to sepeate the two interfaces in the ACPI video module and the second one solves some Win8 backlight control problems by removing ACPI video's backlight interface while still keeping its event delivery functionality. Due to some systems whose firmware claims win8 compatible have problems with i915's backlight control interface, a module param is introduced to give user a chance to select if they want to remove ACPI video's backlight control interface. The param is set to false by default. Aaron Lu (2): ACPI / video: seperate backlight control and event interface ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8 drivers/acpi/internal.h | 2 + drivers/acpi/video.c| 473 +++- drivers/acpi/video_detect.c | 15 +- drivers/gpu/drm/i915/i915_dma.c | 2 +- drivers/gpu/drm/i915/i915_drv.c | 5 + drivers/gpu/drm/i915/i915_drv.h | 1 + include/acpi/video.h| 11 +- include/linux/acpi.h| 1 + 8 files changed, 310 insertions(+), 200 deletions(-) -- 1.8.4.12.g2ea3df6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
According to Matthew Garrett, Windows 8 leaves backlight control up
to individual graphics drivers rather than making ACPI calls itself.
There's plenty of evidence to suggest that the Intel driver for
Windows [8] doesn't use the ACPI interface, including the fact that
it's broken on a bunch of machines when the OS claims to support
Windows 8. The simplest thing to do appears to be to disable the
ACPI backlight interface on these systems.
There's a problem with that approach, however, because simply
avoiding to register the ACPI backlight interface if the firmware
calls _OSI for Windows 8 may not work in the following situations:
(1) The ACPI backlight interface actually works on the given system
and the i915 driver is not loaded (e.g. another graphics driver
is used).
(2) The ACPI backlight interface doesn't work on the given system,
but there is a vendor platform driver that will register its
own, equally broken, backlight interface if not prevented from
doing so by the ACPI subsystem.
Therefore we need to allow the ACPI backlight interface to be
registered until the i915 driver is loaded which then will unregister
it if the firmware has called _OSI for Windows 8 (or will register
the ACPI video driver without backlight support if not already
present).
For this reason, introduce an alternative function for registering
ACPI video, __acpi_video_register(bool), that if ture is passed,
will check whether or not the ACPI video driver has already been
registered and whether or not the backlight Windows 8 quirk has to
be applied. If the quirk has to be applied, it will block the ACPI
backlight support and either unregister the backlight interface if
the ACPI video driver has already been registered, or register the
ACPI video driver without the backlight interface otherwise. Make
the i915 driver use __acpi_video_register() instead of
acpi_video_register() in i915_driver_load(), and the param passed
there is controlled by the i915 module level parameter
i915_take_over_backlight, which is set to false by default.
This change is evolved from earlier patches of Matthew Garrett,
Chun-Yi Lee and Seth Forshee and is heavily based on two patches
from Rafael:
https://lkml.org/lkml/2013/7/17/720
https://lkml.org/lkml/2013/7/24/806
Signed-off-by: Aaron Lu aaron...@intel.com
---
drivers/acpi/internal.h | 2 ++
drivers/acpi/video.c| 24
drivers/acpi/video_detect.c | 15 ++-
drivers/gpu/drm/i915/i915_dma.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 5 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
include/acpi/video.h| 9 +++--
include/linux/acpi.h| 1 +
8 files changed, 47 insertions(+), 12 deletions(-)
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 20f4233..a53832e 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -170,8 +170,10 @@ int acpi_create_platform_device(struct acpi_device *adev,
-- */
#if defined(CONFIG_ACPI_VIDEO) || defined(CONFIG_ACPI_VIDEO_MODULE)
bool acpi_video_backlight_quirks(void);
+bool acpi_video_verify_backlight_support(void);
#else
static inline bool acpi_video_backlight_quirks(void) { return false; }
+static inline bool acpi_video_verify_backlight_support(void) { return false; }
#endif
#endif /* _ACPI_INTERNAL_H_ */
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index 5ad5a71..cc709a7 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -1256,8 +1256,8 @@ acpi_video_switch_brightness(struct acpi_video_device
*device, int event)
unsigned long long level_current, level_next;
int result = -EINVAL;
- /* no warning message if acpi_backlight=vendor is used */
- if (!acpi_video_backlight_support())
+ /* no warning message if acpi_backlight=vendor or a quirk is used */
+ if (!acpi_video_verify_backlight_support())
return 0;
if (!device-brightness)
@@ -1558,7 +1558,7 @@ acpi_video_bus_match(acpi_handle handle, u32 level, void
*context,
static void acpi_video_dev_register_backlight(struct acpi_video_device *device)
{
- if (acpi_video_backlight_support()) {
+ if (acpi_video_verify_backlight_support()) {
struct backlight_properties props;
struct pci_dev *pdev;
acpi_handle acpi_parent;
@@ -1933,14 +1933,22 @@ static int __init intel_opregion_present(void)
return opregion;
}
-int acpi_video_register(void)
+int __acpi_video_register(bool backlight_quirks)
{
- int result = 0;
+ bool no_backlight;
+ int result;
+
+ no_backlight = backlight_quirks ? acpi_video_backlight_quirks() : false;
+
if (register_count) {
/*
-* if the function of acpi_video_register is already called,
-* don't register the acpi_vide_bus again and return
Re: i915_stolen_to_physical() broken in 3.11+
On Mon, Sep 9, 2013 at 11:39 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Mon, Sep 09, 2013 at 11:34:19AM +0200, Knut Petersen wrote: Problem: === Your changes to i915_stolen_to_physical() (commit: eaba1b8f3379b5d100bd146b9a41d28348bdfd09) expose the following problem [2.272218] [drm:i915_stolen_to_physical] *ERROR* conflict detected with stolen region: [0x7f80 - 0x8000] The fix, to reserve the stolen region in early x86 init, should be upstream already. Atm it's stuck in drm-intel-fixes, but the pull request is already sent to Dave. So hopefully it'll land in upstream in a few days ... Poking Dave to speed stuff up ;-) -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
[PATCH] Allow kmscon to be cross-compiled
The genshader and genunifont utilities are run during the build process
to generate source files. In order for that to work when cross-compiling
the files need to be built using the native compiler instead of the
cross-compiler.
Add the AX_PROG_CC_FOR_BUILD m4 macro which defines various *_FOR_BUILD
variables that are the native equivalents of CC, CFLAGS, LDFLAGS, etc.
Override CC, CFLAGS and LDFLAGS for genshader and genunifont and their
object files so that they will be built natively and can be executed
during the build.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
Makefile.am| 16 --
configure.ac | 3 +-
m4/ax_prog_cc_for_build.m4 | 125 +
3 files changed, 139 insertions(+), 5 deletions(-)
create mode 100644 m4/ax_prog_cc_for_build.m4
diff --git a/Makefile.am b/Makefile.am
index 7019290..f1b4435 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -445,8 +445,12 @@ EXTRA_DIST += $(SHADERS)
CLEANFILES += src/static_shaders.c
genshader_SOURCES = src/genshader.c
-src/static_shaders.c: $(SHADERS) genshader$(EXEEXT)
- $(AM_V_GEN)./genshader$(EXEEXT) src/static_shaders.c $(SHADERS)
+src/static_shaders.c: $(SHADERS) genshader$(BUILD_EXEEXT)
+ $(AM_V_GEN)./genshader$(BUILD_EXEEXT) src/static_shaders.c $(SHADERS)
+
+genshader$(BUILD_EXEEXT) $(genshader_OBJECTS): CC = $(CC_FOR_BUILD)
+genshader$(BUILD_EXEEXT) $(genshader_OBJECTS): CFLAGS = $(CFLAGS_FOR_BUILD)
+genshader$(BUILD_EXEEXT): LDFLAGS = $(LDFLAGS_FOR_BUILD)
#
# Unifont Generator
@@ -461,8 +465,12 @@ EXTRA_DIST += $(UNIFONT)
CLEANFILES += $(UNIFONT_BIN)
genunifont_SOURCES = src/genunifont.c
-$(UNIFONT_BIN): $(UNIFONT) genunifont$(EXEEXT)
- $(AM_V_GEN)./genunifont$(EXEEXT) $(UNIFONT_BIN) $(UNIFONT)
+genunifont$(BUILD_EXEEXT) $(genunifont_OBJECTS): CC = $(CC_FOR_BUILD)
+genunifont$(BUILD_EXEEXT) $(genunifont_OBJECTS): CFLAGS = $(CFLAGS_FOR_BUILD)
+genunifont$(BUILD_EXEEXT): LDFLAGS = $(LDFLAGS_FOR_BUILD)
+
+$(UNIFONT_BIN): $(UNIFONT) genunifont$(BUILD_EXEEXT)
+ $(AM_V_GEN)./genunifont$(BUILD_EXEEXT) $(UNIFONT_BIN) $(UNIFONT)
#
# Kmscon Modules
diff --git a/configure.ac b/configure.ac
index bf3c89c..b5d9513 100644
--- a/configure.ac
+++ b/configure.ac
@@ -17,7 +17,7 @@ AC_CONFIG_HEADER(config.h)
AC_USE_SYSTEM_EXTENSIONS
AC_SYS_LARGEFILE
AC_PREFIX_DEFAULT([/usr])
-AC_CANONICAL_HOST
+AC_CANONICAL_SYSTEM
AM_INIT_AUTOMAKE([foreign 1.11 subdir-objects dist-xz no-dist-gzip tar-pax
-Wall -Werror -Wno-portability])
AM_SILENT_RULES([yes])
@@ -31,6 +31,7 @@ AM_SILENT_RULES([yes])
: ${CFLAGS=}
AC_PROG_CC
+AX_PROG_CC_FOR_BUILD
AC_PROG_CC_C99
AM_PROG_CC_C_O
m4_ifdef([AM_PROG_AR], [AM_PROG_AR])
diff --git a/m4/ax_prog_cc_for_build.m4 b/m4/ax_prog_cc_for_build.m4
new file mode 100644
index 000..6369809
--- /dev/null
+++ b/m4/ax_prog_cc_for_build.m4
@@ -0,0 +1,125 @@
+# ===
+# http://www.gnu.org/software/autoconf-archive/ax_prog_cc_for_build.html
+# ===
+#
+# SYNOPSIS
+#
+# AX_PROG_CC_FOR_BUILD
+#
+# DESCRIPTION
+#
+# This macro searches for a C compiler that generates native executables,
+# that is a C compiler that surely is not a cross-compiler. This can be
+# useful if you have to generate source code at compile-time like for
+# example GCC does.
+#
+# The macro sets the CC_FOR_BUILD and CPP_FOR_BUILD macros to anything
+# needed to compile or link (CC_FOR_BUILD) and preprocess (CPP_FOR_BUILD).
+# The value of these variables can be overridden by the user by specifying
+# a compiler with an environment variable (like you do for standard CC).
+#
+# It also sets BUILD_EXEEXT and BUILD_OBJEXT to the executable and object
+# file extensions for the build platform, and GCC_FOR_BUILD to `yes' if
+# the compiler we found is GCC. All these variables but GCC_FOR_BUILD are
+# substituted in the Makefile.
+#
+# LICENSE
+#
+# Copyright (c) 2008 Paolo Bonzini bonz...@gnu.org
+#
+# Copying and distribution of this file, with or without modification, are
+# permitted in any medium without royalty provided the copyright notice
+# and this notice are preserved. This file is offered as-is, without any
+# warranty.
+
+#serial 5
+
+AU_ALIAS([AC_PROG_CC_FOR_BUILD], [AX_PROG_CC_FOR_BUILD])
+AC_DEFUN([AX_PROG_CC_FOR_BUILD], [dnl
+AC_REQUIRE([AC_PROG_CC])dnl
+AC_REQUIRE([AC_PROG_CPP])dnl
+AC_REQUIRE([AC_EXEEXT])dnl
+AC_REQUIRE([AC_CANONICAL_SYSTEM])dnl
+
+dnl Use the standard macros, but make them use other variable names
+dnl
+pushdef([ac_cv_prog_CPP], ac_cv_build_prog_CPP)dnl
+pushdef([ac_cv_prog_gcc], ac_cv_build_prog_gcc)dnl
+pushdef([ac_cv_prog_cc_works], ac_cv_build_prog_cc_works)dnl
+pushdef([ac_cv_prog_cc_cross], ac_cv_build_prog_cc_cross)dnl
+pushdef([ac_cv_prog_cc_g], ac_cv_build_prog_cc_g)dnl
+pushdef([ac_cv_exeext], ac_cv_build_exeext)dnl
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
Hi, On Monday, September 09, 2013 11:32:10 AM Daniel Vetter wrote: Hi Aaaron, Have we grown any clue meanwhile about which Intel boxes need this and for which we still need to keep the acpi backlight around? First of all, there is a bunch of boxes where ACPI backlight works incorrectly because of the Win8 compatibility issue. [In short, if we say we are compatible with Win8, the backlight AML goes into a special code path that is broken on those machines. Presumably Win8 uses native backlight control on them and that AML code path is never executed there.] The collection of machines with this problem appears to be kind of random (various models from various vendors), but I *think* they are machines that originally shipped with Win7 with a Win8 upgrade option (which in practice requires the BIOS to be updated anyway). Because of that, last time we tried to switch all of the systems using i915 and telling the BIOS that they are compatible with Win8 over to native backlight control, but that didn't work for two reasons. The first reason is that some user space doesn't know how to use intel_backlight and needs to be taught about that (so some systems are just not ready for that switch). The second and more fundamental reason is that the native backlight control simply doesn't work on some machines and we don't seem to have any idea why and how to debug this particular problem (mostly because we don't have enough information and we don't know what to ask for). I've grown _very_ reluctant to just adding tons of quirks to our driver for the backlight. Almost all the quirks we have added recently (or that have been proposed to be added) are for the backlight. Imo that indicates we get something fundamentally wrong ... This thing isn't really a quirk. It rather is an option for the users of the systems where ACPI backlight doesn't work to switch over to the native backlight control using a command line switch. This way they can at least *see* if the native backlight control works for them and (hopefully) report problems if that's not the case. This gives us a chance to get more information about what the problem is and possibly to make some progress without making changes for everyone, reverting those changes when they don't work etc. An alternative for them is to pass acpi_osi=!Windows 2012 which will probably make the ACPI backlight work for them again, but this rather is a step back, because we can't possibly learn anything new from that. Kind regards, Rafael On Mon, Sep 09, 2013 at 04:42:20PM +0800, Aaron Lu wrote: According to Matthew Garrett, Windows 8 leaves backlight control up to individual graphics drivers rather than making ACPI calls itself. There's plenty of evidence to suggest that the Intel driver for Windows [8] doesn't use the ACPI interface, including the fact that it's broken on a bunch of machines when the OS claims to support Windows 8. The simplest thing to do appears to be to disable the ACPI backlight interface on these systems. There's a problem with that approach, however, because simply avoiding to register the ACPI backlight interface if the firmware calls _OSI for Windows 8 may not work in the following situations: (1) The ACPI backlight interface actually works on the given system and the i915 driver is not loaded (e.g. another graphics driver is used). (2) The ACPI backlight interface doesn't work on the given system, but there is a vendor platform driver that will register its own, equally broken, backlight interface if not prevented from doing so by the ACPI subsystem. Therefore we need to allow the ACPI backlight interface to be registered until the i915 driver is loaded which then will unregister it if the firmware has called _OSI for Windows 8 (or will register the ACPI video driver without backlight support if not already present). For this reason, introduce an alternative function for registering ACPI video, __acpi_video_register(bool), that if ture is passed, will check whether or not the ACPI video driver has already been registered and whether or not the backlight Windows 8 quirk has to be applied. If the quirk has to be applied, it will block the ACPI backlight support and either unregister the backlight interface if the ACPI video driver has already been registered, or register the ACPI video driver without the backlight interface otherwise. Make the i915 driver use __acpi_video_register() instead of acpi_video_register() in i915_driver_load(), and the param passed there is controlled by the i915 module level parameter i915_take_over_backlight, which is set to false by default. This change is evolved from earlier patches of Matthew Garrett, Chun-Yi Lee and Seth Forshee and is heavily based on two patches from Rafael: https://lkml.org/lkml/2013/7/17/720 https://lkml.org/lkml/2013/7/24/806 Signed-off-by: Aaron Lu
Re: i915_stolen_to_physical() broken in 3.11+
On 09.09.2013 11:53, Daniel Vetter wrote: On Mon, Sep 9, 2013 at 11:39 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Mon, Sep 09, 2013 at 11:34:19AM +0200, Knut Petersen wrote: Problem: === Your changes to i915_stolen_to_physical() (commit: eaba1b8f3379b5d100bd146b9a41d28348bdfd09) expose the following problem [2.272218] [drm:i915_stolen_to_physical] *ERROR* conflict detected with stolen region: [0x7f80 - 0x8000] The fix, to reserve the stolen region in early x86 init, should be upstream already. Atm it's stuck in drm-intel-fixes, but the pull request is already sent to Dave. So hopefully it'll land in upstream in a few days ... Poking Dave to speed stuff up ;-) -Daniel Well, at least those two patches do fix the problem: 0010-7f7e : System RAM 0010-005492f1 : Kernel code 005492f2-007d2fbf : Kernel data 0084e000-00dacfff : Kernel bss 7f7f-7f7f2fff : ACPI Non-volatile Storage 7f7f3000-7f7f : ACPI Tables 7f80-7fff : reserved 7f80-7fff : Graphics Stolen Memory cu, Knut ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #8 from Alex Deucher ag...@yahoo.com --- Please attach your dmesg 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
Re: [PATCH 0/3] drm/radeon kexec fixes
On Mon, Sep 9, 2013 at 5:21 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2013.09.08 at 17:32 -0700, Eric W. Biederman wrote: Markus Trippelsdorf mar...@trippelsdorf.de writes: Here are a couple of patches that get kexec working with radeon devices. I've tested this on my RS780. Comments or flames are welcome. Thanks. A couple of high level comments. This looks promising for the usual case. Removing the printk at the end of the kexec path seems a little dubious, what of other cpus, interrupt handlers, etc. Basically estabilishing a new rule on when printk is allowed seems a little dubious at this point, even if it is a useful debugging trick. OK. I will drop this patch. It doesn't seem to be necessary, because I cannot reproduce the printk related hang anymore. Having a clean shutdown of the radeon definitely seems worth doing, because the cases where we care abouty video are when a person is in front of the system. Yes. But please note that even with radeon_pci_shutdown implemented, I still get ring test failures on roughly every eighth kexec boot: [drm:r600_dma_ring_test] *ERROR* radeon: ring 3 test failed (0xCAFEDEAD) radeon :01:05.0: disabling GPU acceleration That's definitely better than the current state of affairs, with ring test failures on every second boot. But I haven't figured out the reason for these failures yet. It's curious that once a ring test failure occurs, it will reliably fail after each kexec invocation, no matter how often repeated. Only a reboot brings the machine back to normal. I don't know if you want to remove the sanity checks. They seem cheap and safe regardless. Are they expensive or ineffective? Moreover if they work a reasonable amount of the time that means that the kexec on panic case (where we don't shut anything down) can actually use the video, and that in general the driver will be more robust. I don't expect anyone much cares as kexec on panic is mostly used to just write a core file to the network, or the local disk. But if it is easy to keep that case working most of the time, why not. IIRC Alex said the sanity checks are expensive and boot-time could be improved by dropping them. Maybe he can chime in? They shouldn't be necessary with a proper shutdown, but in this particular case, they are not very expensive. What is expensive is having a separate sanity check functions for all the various hw blocks to teardown everything on startup prior to starting it up in case kexec, etc. left the system in a bad state. It ends up amounting to a full tear down sequence followed by a full start up sequence every time you load the driver. I can't really comment on the first patch, but the rest seem fine. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/radeon: Implement radeon_pci_shutdown
On Sun, Sep 08, 2013 at 02:10:58PM +0200, Markus Trippelsdorf wrote:
Currently radeon devices are not properbly shutdown during kexec. This
properly
cases a varity of issues, e.g. dpm initialization failures.
Fix this by implementing a radeon_pci_shutdown function, that unloads
the driver cleanly.
Signed-off-by: Markus Trippelsdorf mar...@trippelsdorf.de
---
drivers/gpu/drm/radeon/radeon_drv.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index cb4445f..d71edee 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -380,6 +380,15 @@ static const struct file_operations
radeon_driver_kms_fops = {
#endif
};
+
+static void
+radeon_pci_shutdown(struct pci_dev *pdev)
+{
+ struct drm_device *dev = pci_get_drvdata(pdev);
+
+ radeon_driver_unload_kms(dev);
+}
+
static struct drm_driver kms_driver = {
.driver_features =
DRIVER_USE_AGP |
@@ -453,6 +462,7 @@ static struct pci_driver radeon_kms_pci_driver = {
.remove = radeon_pci_remove,
.suspend = radeon_pci_suspend,
.resume = radeon_pci_resume,
+ .shutdown = radeon_pci_shutdown,
};
static int __init radeon_init(void)
--
Markus
___
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
[Bug 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 --- Comment #9 from John john.etted...@gmail.com --- Created attachment 85496 -- https://bugs.freedesktop.org/attachment.cgi?id=85496action=edit John's dmesg -- 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 69120] With dpm=1 vdpau is not usable
https://bugs.freedesktop.org/show_bug.cgi?id=69120 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Attachment #85496|application/octet-stream|text/plain mime type|| -- 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 60791] Display corruption with Radeon driver during boot and on desktop
https://bugzilla.kernel.org/show_bug.cgi?id=60791 --- Comment #22 from Alex Deucher alexdeuc...@gmail.com --- Created attachment 107911 -- https://bugzilla.kernel.org/attachment.cgi?id=107911action=edit possible fix Does this patch fix the issue? Please apply without your patch. -- 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 00/19] Common Display Framework
On Mon, Sep 9, 2013 at 10:58 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 09/09/13 17:17, Rob Clark wrote: On Mon, Sep 9, 2013 at 8:12 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 21/08/13 15:22, Rob Clark wrote: And just to be clear, part of my negative experience about this is the omapdss/omapdrm split. I just see cfd outside of drm as encouraging others to make the same mistake. Feel free to disagree, but I think the omapdss/omapdrm split is a bit different matter. The main problem there was splitting the control of a single device (OMAP DSS, and more specifically, DISPC) into two. I don't completely care about the *device* split (we have drm drivers that are multiple devices), as much as the directory and code layout split. We have helper code for edid probing, DP, etc in drm. Drivers should be using this to avoid duplicating code unnecessarily. But that gets difficult when the drivers are outside of drm. (That is the best case scenario, assuming we avoid any impedance mismatch between CDF and KMS, that we come up with a way to share property code, etc.) Ok, I thought you were referring to the apply etc. stuff we spent lots of time solving for omapdss/omapdrm. That all was caused by the split we have for the control for DISPC. yeah, I wasn't particularly referring to that (although it would have been quicker to fix if it was all in drm) I, on the other hand, don't so much care about duplicating code. Sure, I always try to avoid it. But if I need a helper in non-DRM context that does the same thing as a helper DRM already has, I don't see any issue in implementing it. In fact, I'd prefer at least some of the helpers DRM has (say, videomode related and EDID parsing) to be moved out from DRM. There's no reason to tie them to DRM. That would avoid code duplication. If there are easy / non-intrusive ways to make helpers more generic, I don't mind. But for better or for worse, drm/kms is the modern display framework for the kernel, so moving helpers outside of drm isn't something I'm going to go out of my way to do. And, speaking with my distro-hat on, dependencies outside of drm make my work harder to backport new hw support of bugfixes to long-term supported distro kernels.. but that doesn't stop us, when there is good reason to do so (see ww_mutex, for example), but it doesn't make me super excited about increasing dependencies outside of drm when there is no good reason. I suppose the folks porting drm/kms drivers to *BSD probably feel the same way. BR, -R Tomi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69062] Corrupted visuals in Gnome3 (A6-4400M)
https://bugs.freedesktop.org/show_bug.cgi?id=69062 --- Comment #4 from LRN lrn1...@gmail.com --- (In reply to comment #3) Is this a regression? If by regression you mean it worked before, but doesn't work now - yes. Does disabling tiling help? Add: Option ColorTiling False Option ColorTiling2D False in the device section of your xorg.conf I've added this: Section Device Identifier Device0 Driver radeon Option ColorTiling False Option ColorTiling2D False EndSection to my /etc/X11/xorg.conf.d/00-git-xorg.conf. After rebooting and looking at Xorg log, i can see that it groks these options, and later says that KMS Color Tiling and Color Tiling 2D are disabled. However, this does not offer any visible improvements. -- 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 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Mon, Sep 09, 2013 at 02:16:12PM +0200, Rafael J. Wysocki wrote: Hi, On Monday, September 09, 2013 11:32:10 AM Daniel Vetter wrote: Hi Aaaron, Have we grown any clue meanwhile about which Intel boxes need this and for which we still need to keep the acpi backlight around? First of all, there is a bunch of boxes where ACPI backlight works incorrectly because of the Win8 compatibility issue. [In short, if we say we are compatible with Win8, the backlight AML goes into a special code path that is broken on those machines. Presumably Win8 uses native backlight control on them and that AML code path is never executed there.] The collection of machines with this problem appears to be kind of random (various models from various vendors), but I *think* they are machines that originally shipped with Win7 with a Win8 upgrade option (which in practice requires the BIOS to be updated anyway). Because of that, last time we tried to switch all of the systems using i915 and telling the BIOS that they are compatible with Win8 over to native backlight control, but that didn't work for two reasons. The first reason is that some user space doesn't know how to use intel_backlight and needs to be taught about that (so some systems are just not ready for that switch). The second and more fundamental reason is that the native backlight control simply doesn't work on some machines and we don't seem to have any idea why and how to debug this particular problem (mostly because we don't have enough information and we don't know what to ask for). I've grown _very_ reluctant to just adding tons of quirks to our driver for the backlight. Almost all the quirks we have added recently (or that have been proposed to be added) are for the backlight. Imo that indicates we get something fundamentally wrong ... This thing isn't really a quirk. It rather is an option for the users of the systems where ACPI backlight doesn't work to switch over to the native backlight control using a command line switch. This way they can at least *see* if the native backlight control works for them and (hopefully) report problems if that's not the case. This gives us a chance to get more information about what the problem is and possibly to make some progress without making changes for everyone, reverting those changes when they don't work etc. An alternative for them is to pass acpi_osi=!Windows 2012 which will probably make the ACPI backlight work for them again, but this rather is a step back, because we can't possibly learn anything new from that. If Win8 is as broken as we are I'm ok with the module option. It just sounded to me like right now we don't know of a way to make all machines somewhat happy, combined with the other pile of random backlight issues the assumption that we do something (maybe something a bit racy) that windows doesn't do isn't too far-fetched. So I'm not wary of the machines where the aml is busted for acpi_os=win8, but for the others where this broke stuff. Or do I miss something here? Cheers, 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/RFC v3 00/19] Common Display Framework
On Mon, Sep 9, 2013 at 8:12 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 21/08/13 15:22, Rob Clark wrote: And just to be clear, part of my negative experience about this is the omapdss/omapdrm split. I just see cfd outside of drm as encouraging others to make the same mistake. Feel free to disagree, but I think the omapdss/omapdrm split is a bit different matter. The main problem there was splitting the control of a single device (OMAP DSS, and more specifically, DISPC) into two. I don't completely care about the *device* split (we have drm drivers that are multiple devices), as much as the directory and code layout split. We have helper code for edid probing, DP, etc in drm. Drivers should be using this to avoid duplicating code unnecessarily. But that gets difficult when the drivers are outside of drm. (That is the best case scenario, assuming we avoid any impedance mismatch between CDF and KMS, that we come up with a way to share property code, etc.) I don't see any way that putting it outside of drm/kms makes anything any easier.. and I see plenty of potential for making things harder. I have enough other work to do, hence I vote for 'easier' ;-) That all said, I don't think CDF really changes anything from the perspective of needing drm_bridge, drm_panel, etc. I suppose they can co-exist, possibly in some cases drm/kms objects are just wrappers for CDF objects. But if I do see new driver code that is duplicating what can be done w/ helpers in drm (see drivers/video/exynos/*dp*), or with unnecessary complexity, I would nak it.. just the same as I would do with new drivers in drm which aren't using the appropriate helpers, etc. BR, -R I don't see CDF causing anything similar. A single DRM driver should manage the DISPC in OMAP's case, and it should (probably) also control the external encoders and panel, even if those are independent CDF drivers. Tomi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC v3 00/19] Common Display Framework
On 09/09/13 17:17, Rob Clark wrote: On Mon, Sep 9, 2013 at 8:12 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 21/08/13 15:22, Rob Clark wrote: And just to be clear, part of my negative experience about this is the omapdss/omapdrm split. I just see cfd outside of drm as encouraging others to make the same mistake. Feel free to disagree, but I think the omapdss/omapdrm split is a bit different matter. The main problem there was splitting the control of a single device (OMAP DSS, and more specifically, DISPC) into two. I don't completely care about the *device* split (we have drm drivers that are multiple devices), as much as the directory and code layout split. We have helper code for edid probing, DP, etc in drm. Drivers should be using this to avoid duplicating code unnecessarily. But that gets difficult when the drivers are outside of drm. (That is the best case scenario, assuming we avoid any impedance mismatch between CDF and KMS, that we come up with a way to share property code, etc.) Ok, I thought you were referring to the apply etc. stuff we spent lots of time solving for omapdss/omapdrm. That all was caused by the split we have for the control for DISPC. I, on the other hand, don't so much care about duplicating code. Sure, I always try to avoid it. But if I need a helper in non-DRM context that does the same thing as a helper DRM already has, I don't see any issue in implementing it. In fact, I'd prefer at least some of the helpers DRM has (say, videomode related and EDID parsing) to be moved out from DRM. There's no reason to tie them to DRM. That would avoid code duplication. Tomi signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Mon, 2013-09-09 at 16:42 +0800, Aaron Lu wrote:
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index f466980..75fba17 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1650,7 +1650,7 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
if (INTEL_INFO(dev)-num_pipes) {
/* Must be done after probing outputs */
intel_opregion_init(dev);
- acpi_video_register();
+ __acpi_video_register(i915_take_over_backlight);
}
if (IS_GEN5(dev))
I can't compile:
DEBUG: drivers/gpu/drm/i915/i915_dma.c: In function 'i915_driver_load':
DEBUG: drivers/gpu/drm/i915/i915_dma.c:1661:3: error: implicit
declaration of function
'__acpi_video_register' [-Werror=implicit-function-declaration]
DEBUG:__acpi_video_register(i915_take_over_backlight);
DEBUG:^
DEBUG: cc1: some warnings being treated as errors
DEBUG: make[4]: *** [drivers/gpu/drm/i915/i915_dma.o] Error 1
DEBUG: make[3]: *** [drivers/gpu/drm/i915] Error 2
DEBUG: make[2]: *** [drivers/gpu/drm] Error 2
DEBUG: make[1]: *** [drivers/gpu] Error 2
DEBUG: make: *** [drivers] Error 2
--
Igor Gnatenko
Fedora release 20 (Heisenbug)
Linux 3.11.0-3.fc20.x86_64
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC v3 00/19] Common Display Framework
On 21/08/13 15:22, Rob Clark wrote: And just to be clear, part of my negative experience about this is the omapdss/omapdrm split. I just see cfd outside of drm as encouraging others to make the same mistake. Feel free to disagree, but I think the omapdss/omapdrm split is a bit different matter. The main problem there was splitting the control of a single device (OMAP DSS, and more specifically, DISPC) into two. I don't see CDF causing anything similar. A single DRM driver should manage the DISPC in OMAP's case, and it should (probably) also control the external encoders and panel, even if those are independent CDF drivers. Tomi signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69062] Corrupted visuals in Gnome3 (A6-4400M)
https://bugs.freedesktop.org/show_bug.cgi?id=69062 --- Comment #3 from Alex Deucher ag...@yahoo.com --- Is this a regression? Does disabling tiling help? Add: Option ColorTiling False Option ColorTiling2D False in the device section of your xorg.conf -- 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 69062] Corrupted visuals in Gnome3 (A6-4400M)
https://bugs.freedesktop.org/show_bug.cgi?id=69062 --- Comment #5 from Alex Deucher ag...@yahoo.com --- How about setting env var R600_DEBUG=nodma? Try adding that to /etc/environment . -- 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
drm/radeon: ring test failed on PA-RISC Linux
Folks, We (people at linux-parisc @ vger.kernel.org mail list) are trying to make native video options of the latest PA-RISC servers and workstations (these are ATIs, most of which are based on R100/R300/R420 chips) work correctly on this platform (big endian pa-risc). However, we hadn't much success. DRM fails every time with ring test failed for both AGP PCI. Maybe you would give us some suggestions that we could check? Topic started here: http://www.spinics.net/lists/linux-parisc/msg04908.html And continued there: http://www.spinics.net/lists/linux-parisc/msg04995.html http://www.spinics.net/lists/linux-parisc/msg05006.html Problems we've already resolved without any signs of progress: - Checked the successful microcode load parisc AGP GART code writes IOMMU entries in the wrong byte order and doesn't add the coherency information SBA code adds our PCI BAR setup doesn't really work very well together with the Radeon DRM address setup. DRM will generate addresses, which are even outside of the connected LBA Things planned for a check: The drivers/video/aty uses an endian config bit DRM doesn't use, but I haven't tested whether this makes a difference and how it is connected to the overall picture. The Rage128 product revealed a weakness in some motherboard chipsets in that there is no mechanism to guarantee that data written by the CPU to memory is actually in a readable state before the Graphics Controller receives an update to its copy of the Write Pointer. In an effort to alleviate this problem, we‟ve introduced a mechanism into the Graphics Controller that will delay the actual write to the Write Pointer for some programmable amount of time, in order to give the chipset time to flush its internal write buffers to memory. There are two register fields that control this mechanism: PRE_WRITE_TIMER and PRE_WRITE_LIMIT. In the radeon DRM codebase I didn't found anyone using/setting those registers. Maybe PA-RISC has some problem here?... Thanks. Пересылаемое сообщение 04.08.2013, 15:06, Alex Ivanov gnido...@p0n4ik.tk: 11.07.2013, 23:48, Helge Deller del...@gmx.de: adding linux parisc mailing list...: On 07/11/2013 09:46 PM, Helge Deller wrote: On 07/10/2013 11:29 PM, Alex Ivanov wrote: 11.07.2013, 01:14, Matt Turner matts...@gmail.com: On Wed, Jul 10, 2013 at 1:19 PM, Alex Ivanov gnido...@p0n4ik.tk wrote: Thank you so much! Your guess looks to be right. After applying of your patch there was no more KP and X just worked. Nice! Does DRI work? Not on my side. Plus i can't visually jump over 8bit depth, although Xorg states 24bit in it's log. As for DRI, i'm experiencing ring test failed (scratch(0x15E4)=0xCAFEDEAD) with a firegl x3. FWIW, I'm seeing the same failure on my FireGL X1: 80:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Radeon R300 NG [FireGL X1] (rev 80) [drm] radeon: irq initialized. [drm] Loading R300 Microcode [drm] radeon: ring at 0x60001000 [drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD) [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). radeon :80:00.0: failed initializing CP (-22). radeon :80:00.0: Disabling GPU acceleration [drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP. [drm] radeon: cp finalized [drm] radeon: cp finalized I still have no clue why this happens. Broken SBA IOMMU / DRM code? Missing syncing primitives? Should we forward this to dri-devel mail list? -- To unsubscribe from this list: send the line unsubscribe linux-parisc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Завершение пересылаемого сообщения ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 69062] Corrupted visuals in Gnome3 (A6-4400M)
https://bugs.freedesktop.org/show_bug.cgi?id=69062 --- Comment #6 from LRN lrn1...@gmail.com --- (In reply to comment #5) How about setting env var R600_DEBUG=nodma? Try adding that to /etc/environment . Added to /etc/environment, rebooted - no visible improvements (should the fact that this variable is set be mentioned in Xorg log or dmesg? i don't see anything specific there). Do you want logs with more verbosity? I remember that there's a boot parameter that gives verbose logs for radeon driver. Another bit of info (may be related): lightspark has huge problems playing youtube videos (frames jump around in time, , some parts of the picture are corrupted, and the whole thing looks choppy). Iceweasel's stderr is full of GL error 1282 -- 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 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Mon, 2013-09-09 at 17:21 +0200, Daniel Vetter wrote: If Win8 is as broken as we are I'm ok with the module option. It just sounded to me like right now we don't know of a way to make all machines somewhat happy, combined with the other pile of random backlight issues the assumption that we do something (maybe something a bit racy) that windows doesn't do isn't too far-fetched. So I'm not wary of the machines where the aml is busted for acpi_os=win8, but for the others where this broke stuff. Windows 8 isn't broken because (as far as we can tell) the Intel drivers under Windows 8 never use the ACPI backlight set function. Of course, it would be nice to have that confirmed by Intel. -- Matthew Garrett matthew.garr...@nebula.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60791] Display corruption with Radeon driver during boot and on desktop
https://bugzilla.kernel.org/show_bug.cgi?id=60791 --- Comment #23 from hams...@freenet.de --- Sadly it doesn't fix the issue on my setup. I applied it on the 3.11.0 release without previous patches. -- 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 60791] Display corruption with Radeon driver during boot and on desktop
https://bugzilla.kernel.org/show_bug.cgi?id=60791 --- Comment #24 from Alex Deucher alexdeuc...@gmail.com --- (In reply to Hamsi2k from comment #23) Sadly it doesn't fix the issue on my setup. I applied it on the 3.11.0 release without previous patches. Can you attach a copy of your vbios and dump the broken and working registers as per comment 13? -- 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 60858] [radeon HD 4570m] Error setting UVD clocks
https://bugzilla.kernel.org/show_bug.cgi?id=60858 --- Comment #9 from Pinak Ahuja pinak.ah...@gmail.com --- (In reply to Christian König from comment #8) You could dig into the code and try to figure out why the post dividers (vclk_div and dclk_div) turn out as 0. The two involved functions are rv770_set_uvd_clocks which can be found here drivers/gpu/drm/radeon/rv770.c and radeon_uvd_calc_upll_dividers which can be found here drivers/gpu/drm/radeon/radeon_uvd.c. I'll go through the code a little later and see if i can find something useful. The most interesting value is rdev-clock.spll.reference_freq, it is the reference clock frequency coming from a bios table. If that is wrong the whole calculation doesn't work any more and the UPLL generates an invalid frequency. Insert something like DRM_ERROR(Test %d\n, rdev-clock.spll.reference_freq) into the code and see what it spits out on the next reboot. I did this, heres the output: [8.346601] [drm:radeon_uvd_calc_upll_dividers] *ERROR* Test 2700 here's the full log: http://pastebin.com/31Pe119f -- 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 60791] Display corruption with Radeon driver during boot and on desktop
https://bugzilla.kernel.org/show_bug.cgi?id=60791 --- Comment #27 from Quallenauge hams...@freenet.de --- Created attachment 107961 -- https://bugzilla.kernel.org/attachment.cgi?id=107961action=edit copy of video bios -- 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: drm/radeon: ring test failed on PA-RISC Linux
On Mon, Sep 9, 2013 at 12:44 PM, Alex Ivanov gnido...@p0n4ik.tk wrote: Folks, We (people at linux-parisc @ vger.kernel.org mail list) are trying to make native video options of the latest PA-RISC servers and workstations (these are ATIs, most of which are based on R100/R300/R420 chips) work correctly on this platform (big endian pa-risc). However, we hadn't much success. DRM fails every time with ring test failed for both AGP PCI. Maybe you would give us some suggestions that we could check? Topic started here: http://www.spinics.net/lists/linux-parisc/msg04908.html And continued there: http://www.spinics.net/lists/linux-parisc/msg04995.html http://www.spinics.net/lists/linux-parisc/msg05006.html Problems we've already resolved without any signs of progress: - Checked the successful microcode load parisc AGP GART code writes IOMMU entries in the wrong byte order and doesn't add the coherency information SBA code adds our PCI BAR setup doesn't really work very well together with the Radeon DRM address setup. DRM will generate addresses, which are even outside of the connected LBA Things planned for a check: The drivers/video/aty uses an endian config bit DRM doesn't use, but I haven't tested whether this makes a difference and how it is connected to the overall picture. I don't think that will any difference. radeon kms works fine on other big endian platforms such as powerpc. The Rage128 product revealed a weakness in some motherboard chipsets in that there is no mechanism to guarantee that data written by the CPU to memory is actually in a readable state before the Graphics Controller receives an update to its copy of the Write Pointer. In an effort to alleviate this problem, weve introduced a mechanism into the Graphics Controller that will delay the actual write to the Write Pointer for some programmable amount of time, in order to give the chipset time to flush its internal write buffers to memory. There are two register fields that control this mechanism: PRE_WRITE_TIMER and PRE_WRITE_LIMIT. In the radeon DRM codebase I didn't found anyone using/setting those registers. Maybe PA-RISC has some problem here?... I doubt it. If you are using AGP, I'd suggest disabling it and first try to get things working using the on chip gart rather than AGP. Load radeon with agpmode=-1. The on chip gart always uses cache snooped pci transactions and the driver assumes pci is cache coherent. On AGP/PCI chips, the on-chip gart mechanism stores the gart table in system ram. On PCIE asics, the gart table is stored in vram. The gart page table maps system pages to a contiguous aperture in the GPU's address space. The ring lives in gart memory. The GPU sees a contiguous buffer and the gart mechanism handles the access to the backing pages via the page table. I'd suggest verifying that the entries written to the gart page table are valid and then the information written to the ring buffer is valid before updating the ring's wptr in radeon_ring_unlock_commit(). Changing the wptr is what causes the CP to start fetching data from the ring. Alex Thanks. Пересылаемое сообщение 04.08.2013, 15:06, Alex Ivanov gnido...@p0n4ik.tk: 11.07.2013, 23:48, Helge Deller del...@gmx.de: adding linux parisc mailing list...: On 07/11/2013 09:46 PM, Helge Deller wrote: On 07/10/2013 11:29 PM, Alex Ivanov wrote: 11.07.2013, 01:14, Matt Turner matts...@gmail.com: On Wed, Jul 10, 2013 at 1:19 PM, Alex Ivanov gnido...@p0n4ik.tk wrote: Thank you so much! Your guess looks to be right. After applying of your patch there was no more KP and X just worked. Nice! Does DRI work? Not on my side. Plus i can't visually jump over 8bit depth, although Xorg states 24bit in it's log. As for DRI, i'm experiencing ring test failed (scratch(0x15E4)=0xCAFEDEAD) with a firegl x3. FWIW, I'm seeing the same failure on my FireGL X1: 80:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Radeon R300 NG [FireGL X1] (rev 80) [drm] radeon: irq initialized. [drm] Loading R300 Microcode [drm] radeon: ring at 0x60001000 [drm:r100_ring_test] *ERROR* radeon: ring test failed (scratch(0x15E4)=0xCAFEDEAD) [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). radeon :80:00.0: failed initializing CP (-22). radeon :80:00.0: Disabling GPU acceleration [drm:r100_cp_fini] *ERROR* Wait for CP idle timeout, shutting down CP. [drm] radeon: cp finalized [drm] radeon: cp finalized I still have no clue why this happens. Broken SBA IOMMU / DRM code? Missing syncing primitives? Should we forward this to dri-devel mail list? -- To unsubscribe from this list: send the line unsubscribe linux-parisc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Завершение пересылаемого сообщения
Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if firmware expects Windows 8
On Monday, September 09, 2013 05:21:18 PM Daniel Vetter wrote: On Mon, Sep 09, 2013 at 02:16:12PM +0200, Rafael J. Wysocki wrote: Hi, On Monday, September 09, 2013 11:32:10 AM Daniel Vetter wrote: Hi Aaaron, Have we grown any clue meanwhile about which Intel boxes need this and for which we still need to keep the acpi backlight around? First of all, there is a bunch of boxes where ACPI backlight works incorrectly because of the Win8 compatibility issue. [In short, if we say we are compatible with Win8, the backlight AML goes into a special code path that is broken on those machines. Presumably Win8 uses native backlight control on them and that AML code path is never executed there.] The collection of machines with this problem appears to be kind of random (various models from various vendors), but I *think* they are machines that originally shipped with Win7 with a Win8 upgrade option (which in practice requires the BIOS to be updated anyway). Because of that, last time we tried to switch all of the systems using i915 and telling the BIOS that they are compatible with Win8 over to native backlight control, but that didn't work for two reasons. The first reason is that some user space doesn't know how to use intel_backlight and needs to be taught about that (so some systems are just not ready for that switch). The second and more fundamental reason is that the native backlight control simply doesn't work on some machines and we don't seem to have any idea why and how to debug this particular problem (mostly because we don't have enough information and we don't know what to ask for). I've grown _very_ reluctant to just adding tons of quirks to our driver for the backlight. Almost all the quirks we have added recently (or that have been proposed to be added) are for the backlight. Imo that indicates we get something fundamentally wrong ... This thing isn't really a quirk. It rather is an option for the users of the systems where ACPI backlight doesn't work to switch over to the native backlight control using a command line switch. This way they can at least *see* if the native backlight control works for them and (hopefully) report problems if that's not the case. This gives us a chance to get more information about what the problem is and possibly to make some progress without making changes for everyone, reverting those changes when they don't work etc. An alternative for them is to pass acpi_osi=!Windows 2012 which will probably make the ACPI backlight work for them again, but this rather is a step back, because we can't possibly learn anything new from that. If Win8 is as broken as we are I'm ok with the module option. It just sounded to me like right now we don't know of a way to make all machines somewhat happy, combined with the other pile of random backlight issues the assumption that we do something (maybe something a bit racy) that windows doesn't do isn't too far-fetched. So I'm not wary of the machines where the aml is busted for acpi_os=win8, but for the others where this broke stuff. Or do I miss something here? The ACPI video driver doesn't do anything new now. It only does things that did work before we started to tell BIOSes we're compatible with Win8. The reason why they don't work on some machines now is not related to whether or not Win8 is broken, but to what is there in the ACPI tables on those machines. That *is* pure garbage, but Win8 users don't see that (presumably, because Win8 does't execute the AML in question). We don't see that either with acpi_osi=!Windows 2012 (because then we don't execute that AML either). Whether or not Win8 is broken doesn't matter here. What matters is that we have to deal with broken AML somehow. One way may be to tell everyone affected by this to pass acpi_osi=!Windows 2012 in the kernel command line or possibly create a blacklist of those machines in the kernel (which Felipe has been pushing for recently) and wash our hands clean of this, but that leaves some exceptionally bad taste in my mouth. The alternative is to try to use native backlight in i915, which we did, but that didn't work on some machines. I don't think we will know why it didn't work there before we collect some more information and that's not possible without user testing. So, the idea is to make that testing possible without hacking the kernel and that's why we're introducing the new command line switch. And we're going to ask users to try it and report back. Thanks, Rafael ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60791] Display corruption with Radeon driver during boot and on desktop
https://bugzilla.kernel.org/show_bug.cgi?id=60791 --- Comment #25 from hams...@freenet.de --- Created attachment 107941 -- https://bugzilla.kernel.org/attachment.cgi?id=107941action=edit 3.11.0 Working register dump -- 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 60791] Display corruption with Radeon driver during boot and on desktop
https://bugzilla.kernel.org/show_bug.cgi?id=60791 Quallenauge hams...@freenet.de changed: What|Removed |Added Attachment #107951|3.0.11 Non-Working register |3.11.0 Non-Working register description|dump|dump -- 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 60791] Display corruption with Radeon driver during boot and on desktop
https://bugzilla.kernel.org/show_bug.cgi?id=60791 --- Comment #26 from hams...@freenet.de --- Created attachment 107951 -- https://bugzilla.kernel.org/attachment.cgi?id=107951action=edit 3.0.11 Non-Working register dump -- 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/nouveau: force alignment to 0x1000 for gpu objects
On Wed, Sep 4, 2013 at 9:59 PM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: Op 04-09-13 05:34, Ben Skeggs schreef: On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst maarten.lankho...@canonical.com 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. All the places I can see with a too small alignment are not suballocated, so the backend will force alignment to minimum GPU page size anyway. If someone wants to go through all these calls and fix them up explicitly too, then, patches welcome. The posted patch, however, isn't the right way to go about this, and I couldn't find an example yet that'd cause an actual breakage. Ben. ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60791] Display corruption with Radeon driver during boot and on desktop
https://bugzilla.kernel.org/show_bug.cgi?id=60791 --- Comment #28 from Brian Hall hal...@gmail.com --- (In reply to Alex Deucher from comment #22) Created attachment 107911 [details] possible fix Does this patch fix the issue? Please apply without your patch. Patch 0001-drm-radeon-atom-workaround-vbios-bug-in-transmitter-.patch did fix my issue, on 3.11.0 without the fix_radeon_dvi_corruption.patch. I had some trouble getting the atom-workaround patch to apply, so I just manually modified atombios_encoders.c as per the patch: /* some early dce3.2 boards have a bug in their transmitter control table */ // if ((rdev-family != CHIP_RV710) (rdev-family != CHIP_RV730)) /* some dce3.x boards have a bug in their transmitter control table. * ACTION_ENABLE_OUTPUT can probably be dropped since ACTION_ENABLE * does the same thing and more. */ if ((rdev-family != CHIP_RV710) (rdev-family != CHIP_RV730) (rdev-family != CHIP_RS780)) atombios_dig_transmitter_setup(encoder, ATOM_TRANSMITTER_ACTION_ENABLE_OUTPUT, 0, 0); -- 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 2/2] modetest: allow setting a scaling factor when showing plane
On Sat, Sep 7, 2013 at 9:36 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Reviewed-by: Rob Clark robdcl...@gmail.com
---
tests/modetest/modetest.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 9d6e279..51c4e6d 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -707,6 +707,7 @@ struct plane_arg {
bool has_position;
int32_t x, y;
uint32_t w, h;
+ double scale;
unsigned int fb_id;
char format_str[5]; /* need to leave room for terminating \0 */
unsigned int fourcc;
@@ -988,16 +989,16 @@ static int set_plane(struct device *dev, struct
plane_arg *p)
return -1;
}
+ crtc_w = p-w * p-scale;
+ crtc_h = p-h * p-scale;
if (!p-has_position) {
/* Default to the middle of the screen */
- crtc_x = (crtc-mode-hdisplay - p-w) / 2;
- crtc_y = (crtc-mode-vdisplay - p-h) / 2;
+ crtc_x = (crtc-mode-hdisplay - crtc_w) / 2;
+ crtc_y = (crtc-mode-vdisplay - crtc_h) / 2;
} else {
crtc_x = p-x;
crtc_y = p-y;
}
- crtc_w = p-w;
- crtc_h = p-h;
/* note src coords (last 4 args) are in Q16 format */
if (drmModeSetPlane(dev-fd, plane_id, crtc-crtc-crtc_id, p-fb_id,
@@ -1271,6 +1272,15 @@ static int parse_plane(struct plane_arg *plane, const
char *p)
plane-has_position = true;
}
+ if (*end == '*') {
+ p = end + 1;
+ plane-scale = strtod(p, end);
+ if (plane-scale = 0.0)
+ return -EINVAL;
+ } else {
+ plane-scale = 1.0;
+ }
+
if (*end == '@') {
p = end + 1;
if (strlen(p) != 4)
@@ -1312,7 +1322,7 @@ static void usage(char *name)
fprintf(stderr, \t-p\tlist CRTCs and planes (pipes)\n);
fprintf(stderr, \n Test options:\n\n);
- fprintf(stderr, \t-P crtc_id:wxh[+x+y][@format]\tset a
plane\n);
+ fprintf(stderr, \t-P
crtc_id:wxh[+x+y][*scale][@format]\tset a plane\n);
fprintf(stderr, \t-s
connector_id[,connector_id][@crtc_id]:mode[@format]\tset a mode\n);
fprintf(stderr, \t-v\ttest vsynced page flipping\n);
fprintf(stderr, \t-w obj_id:prop_name:value\tset property\n);
--
1.8.1.5
___
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 1/2] modetest: add a -D option to specify a device to be used
On Sat, Sep 7, 2013 at 9:36 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
This is helpful for differentiating between multiple devices that use
the same module.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Reviewed-by: Rob Clark robdcl...@gmail.com
---
tests/modetest/modetest.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index f0ed56b..9d6e279 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -1303,7 +1303,7 @@ static int parse_property(struct property_arg *p, const
char *arg)
static void usage(char *name)
{
- fprintf(stderr, usage: %s [-cdefMmPpsvw]\n, name);
+ fprintf(stderr, usage: %s [-cDdefMPpsvw]\n, name);
fprintf(stderr, \n Query options:\n\n);
fprintf(stderr, \t-c\tlist connectors\n);
@@ -1320,6 +1320,7 @@ static void usage(char *name)
fprintf(stderr, \n Generic options:\n\n);
fprintf(stderr, \t-d\tdrop master after mode set\n);
fprintf(stderr, \t-M module\tuse the given driver\n);
+ fprintf(stderr, \t-D device\tuse the given device\n);
fprintf(stderr, \n\tDefault is to dump all info.\n);
exit(0);
@@ -1346,7 +1347,7 @@ static int page_flipping_supported(void)
#endif
}
-static char optstr[] = cdefM:P:ps:vw:;
+static char optstr[] = cdD:efM:P:ps:vw:;
int main(int argc, char **argv)
{
@@ -1357,6 +1358,7 @@ int main(int argc, char **argv)
int drop_master = 0;
int test_vsync = 0;
const char *modules[] = { i915, radeon, nouveau, vmwgfx,
omapdrm, exynos, tilcdc, msm };
+ char *device = NULL;
char *module = NULL;
unsigned int i;
int count = 0, plane_count = 0;
@@ -1377,6 +1379,10 @@ int main(int argc, char **argv)
case 'c':
connectors = 1;
break;
+ case 'D':
+ device = optarg;
+ args--;
+ break;
case 'd':
drop_master = 1;
break;
@@ -1447,7 +1453,7 @@ int main(int argc, char **argv)
encoders = connectors = crtcs = planes = framebuffers = 1;
if (module) {
- dev.fd = drmOpen(module, NULL);
+ dev.fd = drmOpen(module, device);
if (dev.fd 0) {
fprintf(stderr, failed to open device '%s'.\n,
module);
return 1;
@@ -1455,7 +1461,7 @@ int main(int argc, char **argv)
} else {
for (i = 0; i ARRAY_SIZE(modules); i++) {
printf(trying to open device '%s'..., modules[i]);
- dev.fd = drmOpen(modules[i], NULL);
+ dev.fd = drmOpen(modules[i], device);
if (dev.fd 0) {
printf(failed.\n);
} else {
--
1.8.1.5
___
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 2/2] modetest: allow setting a scaling factor when showing plane
On Tue, Sep 10, 2013 at 12:08 PM, Rob Clark robdcl...@gmail.com wrote:
On Sat, Sep 7, 2013 at 9:36 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Reviewed-by: Rob Clark robdcl...@gmail.com
Reviewed-and-tested-by: Ben Skeggs bske...@redhat.com
---
tests/modetest/modetest.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 9d6e279..51c4e6d 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -707,6 +707,7 @@ struct plane_arg {
bool has_position;
int32_t x, y;
uint32_t w, h;
+ double scale;
unsigned int fb_id;
char format_str[5]; /* need to leave room for terminating \0 */
unsigned int fourcc;
@@ -988,16 +989,16 @@ static int set_plane(struct device *dev, struct
plane_arg *p)
return -1;
}
+ crtc_w = p-w * p-scale;
+ crtc_h = p-h * p-scale;
if (!p-has_position) {
/* Default to the middle of the screen */
- crtc_x = (crtc-mode-hdisplay - p-w) / 2;
- crtc_y = (crtc-mode-vdisplay - p-h) / 2;
+ crtc_x = (crtc-mode-hdisplay - crtc_w) / 2;
+ crtc_y = (crtc-mode-vdisplay - crtc_h) / 2;
} else {
crtc_x = p-x;
crtc_y = p-y;
}
- crtc_w = p-w;
- crtc_h = p-h;
/* note src coords (last 4 args) are in Q16 format */
if (drmModeSetPlane(dev-fd, plane_id, crtc-crtc-crtc_id, p-fb_id,
@@ -1271,6 +1272,15 @@ static int parse_plane(struct plane_arg *plane, const
char *p)
plane-has_position = true;
}
+ if (*end == '*') {
+ p = end + 1;
+ plane-scale = strtod(p, end);
+ if (plane-scale = 0.0)
+ return -EINVAL;
+ } else {
+ plane-scale = 1.0;
+ }
+
if (*end == '@') {
p = end + 1;
if (strlen(p) != 4)
@@ -1312,7 +1322,7 @@ static void usage(char *name)
fprintf(stderr, \t-p\tlist CRTCs and planes (pipes)\n);
fprintf(stderr, \n Test options:\n\n);
- fprintf(stderr, \t-P crtc_id:wxh[+x+y][@format]\tset a
plane\n);
+ fprintf(stderr, \t-P
crtc_id:wxh[+x+y][*scale][@format]\tset a plane\n);
fprintf(stderr, \t-s
connector_id[,connector_id][@crtc_id]:mode[@format]\tset a
mode\n);
fprintf(stderr, \t-v\ttest vsynced page flipping\n);
fprintf(stderr, \t-w obj_id:prop_name:value\tset property\n);
--
1.8.1.5
___
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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
