[Intel-gfx] [PATCH] drm/i915: Make DRM_I915_WERROR depend on !COMPILE_TEST
With allyesconfig/allmodconfig, kbuild enables all the options it can, including DRM_I915_WERROR. That's not really what we want with -Werror, and this was breaking the build for Andrew. Andrew suggested to use COMPILE_TEST as a way to 'detect' these configurations. An alternative would be to inverse the condition of the option: DRM_I915_NO_WERROR. Setting that one to Y would have no effect, at the price of a bit of confusion. Another alternative would be to introduce a allyesmodconfig_n property to config entries, like the allnoconfig_y one we have today: - "allnoconfig_y" This declares the symbol as one that should have the value y when using "allnoconfig". Used for symbols that hide other symbols. Of course, allyesmodconfig_n would set the value to n when using "allmodconfig" or "allmodconfig". That alternative needs a bit more work though and may not be desirable, given that even allnoconfig_y is used only once today. Reported-by: Andrew Morton Suggested-by: Andrew Morton Cc: Andrew Morton Cc: Chris Wilson Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/Kconfig.debug | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/Kconfig.debug b/drivers/gpu/drm/i915/Kconfig.debug index 070a035..9d6ec64 100644 --- a/drivers/gpu/drm/i915/Kconfig.debug +++ b/drivers/gpu/drm/i915/Kconfig.debug @@ -1,5 +1,8 @@ config DRM_I915_WERROR bool "Force GCC to throw an error instead of a warning when compiling" + # We use the dependency on !COMPILE_TEST to not be enabled in + # allmodconfig or allyesconfig configurations + depends on !COMPILE_TEST default n ---help--- Add -Werror to the build flags for (and only for) i915.ko -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Fwd: EDID problem
Hello, I want to use custom EDID for one of my monitors. This because the monitor has a broken EDID structure. I have been trying to use a custom EDID (a binary message was saved before) within Xorg.conf. Is this possible? I have installed the drivers by using : Intel(R) Graphics Installer for Linux* 1.0.7 and the operating system is Ubuntu 14.04 64bit. Regards. -- *Engin FIRAT* Adoniss Yazılım Bilişim Elektronik Araştırma Geliştirme Limited Şirketi +90 506 884 82 07 (Mobile) ODTÜ Teknokent, ODTÜ-Halıcı Yazılımevi İnönü Bulvarı / ANKARA (Address) -- *Engin FIRAT* Adoniss Yazılım Bilişim Elektronik Araştırma Geliştirme Limited Şirketi +90 506 884 82 07 (Mobile) ODTÜ Teknokent, ODTÜ-Halıcı Yazılımevi İnönü Bulvarı / ANKARA (Address) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Fwd: EDID problem
On Sun, May 24, 2015 at 10:54:44PM +0300, Engin Firat wrote: >Hello, > >I want to use custom EDID for one of my monitors. This because the monitor >has a broken EDID structure. I have been trying to use a custom EDID (a >binary message was saved before) within Xorg.conf. Is this possible? No, you need to tell the kernel to load the custom edid (userspace is not allowed to modify it otherwise). Look at the drm_kms_helper.edid_firmware= module parameter. You basically save the edid you want to use into /lib/firmware/my-edid.bin, then tell the kernel to load it for your connector like drm_kms_helper.edid_firmware=HDMI-A-1:my-edid.bin Hope this helps, -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] EDID problem
Engin Firat composed on 2015-05-24 22:54 (UTC+0300): > I want to use custom EDID for one of my monitors. This because the monitor > has a broken EDID structure. I have been trying to use a custom EDID (a > binary message was saved before) within Xorg.conf. Is this possible? Xorg is usually smart enough to automatically produce an appropriate modeline if you simply use xorg.conf to provide the resolution you want and your diplay's HorizSync and VertRefresh specifications. IOW, manufacturing a valid EDID is usually a lot of unnecessary work. Here, it has never been a necessary workaround to oft-encountered invalid EDID. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drivers/gpu/drm/i915/i915_gem_gtt.c
On Sat, 23 May 2015, Andrew Morton wrote: > On Sat, 23 May 2015 14:30:09 +0100 Damien Lespiau > wrote: > >> On Fri, May 22, 2015 at 02:17:32PM -0700, Andrew Morton wrote: >> > I'm not sure what's happened to the drm code in linux-next - it's >> > exploding all over the place. Did someone turn on -Werror without >> > doing anywhere near enough testing? >> > >> > Anyway, I don't know how to fix this i386 build error: >> >> Seems like you have CONFIG_DRM_I915_WERROR set? > > Yes. > >> We explicitely made sure to not enable -Werror by default, > > `make allmodconfig' enables CONFIG_DRM_I915_WERROR. Right. > I'm not sure what is the approved way of fixing this. Perhaps > disabling CONFIG_DRM_I915_WERROR when CONFIG_COMPILE_TEST=y. Maybe the answer right now is to just drop that config. Daniel? BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3.5 02.5/22] drm/i915: add intel_display_suspend
Op 23-05-15 om 01:03 schreef Matt Roper:
> On Thu, May 21, 2015 at 02:33:31PM +0200, Maarten Lankhorst wrote:
>> This is a function used to disable all crtc's. This makes it clearer
>> to distinguish between when mode needs to be preserved and when
>> it can be trashed.
> To clarify, when you talk about mode being preserved or trashed here,
> you're talking about the hardware's idea of the mode, not the driver's
> software state, right? I.e., because when we shut down a power well the
> registers vanish and whatever was programmed in them is lost?
>
> See my comments farther down.
>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> Oops, I was trashing all state during suspend and on gpu reset.
>> I will send an amended intel_crtc_control patch too with the
>> suspend and prepare_reset parts taken out.
>>
>> drivers/gpu/drm/i915/i915_drv.c | 4 +---
>> drivers/gpu/drm/i915/intel_display.c | 29 +++--
>> drivers/gpu/drm/i915/intel_drv.h | 1 +
>> 3 files changed, 21 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c
>> b/drivers/gpu/drm/i915/i915_drv.c
>> index 5cc57f2ec192..d1a090a9f653 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -600,7 +600,6 @@ static int skl_resume_prepare(struct drm_i915_private
>> *dev_priv);
>> static int i915_drm_suspend(struct drm_device *dev)
>> {
>> struct drm_i915_private *dev_priv = dev->dev_private;
>> -struct drm_crtc *crtc;
>> pci_power_t opregion_target_state;
>> int error;
>>
>> @@ -631,8 +630,7 @@ static int i915_drm_suspend(struct drm_device *dev)
>> * for _thaw. Also, power gate the CRTC power wells.
>> */
>> drm_modeset_lock_all(dev);
>> -for_each_crtc(dev, crtc)
>> -intel_crtc_control(crtc, false);
>> +intel_display_suspend(dev);
> I'm not terribly familiar with the power well details, but it looks like
> part of the motivation of commit
>
> commit b04c5bd6fda54703e56f29569e4bca489d6c5a5c
> Author: Borun Fu
> Date: Sat Jul 12 10:02:27 2014 +0530
>
> drm/i915: Power gating display wells during i915_pm_suspend
>
> which added intel_crtc_control() was to ensure the power wells were
> gated at this point; by replacing the intel_crtc_control() with
> intel_display_suspend() here, you're removing that power well
> programming...is that intentional (and is it going to cause the display
> to stay in D0 state)?
>
> If it is intentional, the comment above this block is out of date now.
> Since this patch (and the following one) seem to change the semantics of
> when we're touching power wells at various points in the code, maybe you
> can elaborate a little bit on that in the commit message of one or both
> commits.
>
You're right, I'm not touching power wells here. For the hang case that doesn't
matter but for pm_suspend it probably does.
The followup patch that converts intel_display_suspend to atomic modeset should
restore the old behavior.
I'll respin with some changes that I'll undo when converting
intel_display_suspend to atomic modeset.
One thing that also seems to unintentionally change behavior is
intel_display_set_init_power being unset by modeset_update_crtc_power_domains.
I'll fix that in the followup patch that converts this function to atomic.
~Maarten
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
