Now that MMIO has been split up into gen specific functions it is
obvious when HAS_FPGA_DBG_UNCLAIMED, HAS_FORCE_WAKE are needed. As such,
we can remove this extraneous condition.
As a result of this, as well as previously existing function pointers
for forcewake, we no longer need the has_force_w
On Sun, Oct 6, 2013 at 1:04 AM, Thomas Richter wrote:
> That is, edit intel_display.c, function i8xx_update_dll(), and insert the
> following lines to setup the PLL value:
>
> if (inten_pipe_has_type(&crtc->base,INTEL_OUTPUT_DVO)) {
> dpll |= DPLL_DVO_HIGH_SPEED;
>
On Sun, Oct 6, 2013 at 1:09 AM, Thomas Richter wrote:
>> Now if you follow the callchains around the dvo->dpms callbacks the DVO
>> port and DPLL are always enabled at that point in time, so I think we
>> should be able to fix this all by moving the modeset code around to that
>> place.
>
>
> True
On Mon, Aug 26, 2013 at 09:45:50AM +, Cui, Dexuan wrote:
> Hi all, I'm using haswell with linux-3.8.13.4:
> http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=commitdiff;h=d1baa1360260b5a01938674fc518109a4e5a148d
> and I find the CAGF showed by i915_cur_delayinfo is always twice as
> gt_cur_fre
Hi Daniel,
btw I've just read through your dvo code again and I think we can fix this
easier. If I read your enable hack correctly then we need to have the dpll
running and the DVO port on. The problem now is that in the dvo ->modeset
callback this is explicitly _not_ the case.
Please also che
Hi Daniel, hi folks,
after another evening of debugging, I believe I know now how to prevent
the ns2501 DVO from locking up. It rather seems that this is due to a
bug in the intel_display module, in specific in the pll update function.
That is, edit intel_display.c, function i8xx_update_dll()
Hi Thomas,
btw I've just read through your dvo code again and I think we can fix this
easier. If I read your enable hack correctly then we need to have the dpll
running and the DVO port on. The problem now is that in the dvo ->modeset
callback this is explicitly _not_ the case.
This is not a big
On Sat, Oct 5, 2013 at 6:47 PM, Thomas Richter wrote:
>
>> The CRT port can only be driven by pipe A, so I think that explains why
>> your hacks may go bad when a CRT monitor is used.
>
>
> Understood, this makes sense. Thus, DVO would then be at pipe B. How is this
> switch made, and where? There
Hi Ville, hi Daniel,
Thus, here my questions:
*) Can I, within the dvo driver code, somehow detect to which display
pipe the DVO and thus the TFT is actually connected
to?
Something like this:
intel_dvo = container_of(dvo, struct intel_dvo, dev);
pipe = to_intel_ctrc(intel_dvo.base.base.crtc)
On Sat, Oct 05, 2013 at 04:13:56PM +0300, Jani Nikula wrote:
> If channel equalization succeeds, there's no indication something went
> wrong in clock recovery (unless debug is enabled). We should shout about
> the failures and fix them instead of hiding them under the carpet.
>
> This has allowed
If channel equalization succeeds, there's no indication something went
wrong in clock recovery (unless debug is enabled). We should shout about
the failures and fix them instead of hiding them under the carpet.
This has allowed bugs like [1] stay dormant for a long time.
[1] https://bugs.freedesk
On Fri, Oct 04, 2013 at 09:22:55PM -0700, Ben Widawsky wrote:
> Now that MMIO has been split up into gen specific functions it is
> obvious when HAS_FPGA_DBG_UNCLAIMED, HAS_FORCE_WAKE are needed.
>
> I'm a bit on the fence whether or not to even have the checks at all.
> For now I am leaving them
On Sat, Oct 05, 2013 at 10:33:44AM +0200, Thomas Richter wrote:
> Hi Daniel, hi folks,
>
> just playing again with the support code for the NS2501 DVO in my old
> laptop. Despite finding one bug I'll send a patch
> for soon, there is something else that makes we wonder, and that is the
> connect
On Fri, Oct 4, 2013 at 9:42 PM, Jesse Barnes wrote:
> On VLV/BYT, backlight controls a per-pipe, so when adjusting the
> backlight we need to pass the correct info. So make the externally
> visible backlight functions take a connector argument, which can be used
> internally to figure out the pip
On Fri, Oct 4, 2013 at 9:42 PM, Jesse Barnes wrote:
> And Ville is right that these bits need to be pushed into the connector.
> What I'd like to do is make them virtual functions of the connector,
> with the VLV, gen4, and PCH bits split out. We can save/restore the
> state there too from modese
Hi Daniel, hi folks,
just playing again with the support code for the NS2501 DVO in my old
laptop. Despite finding one bug I'll send a patch
for soon, there is something else that makes we wonder, and that is the
connection to external monitors.
Just to remind you, the NS2501 in this specific
16 matches
Mail list logo
