Since this is run in the compute config stage we need to check
the new_ pointers, not the current modeset layout. Also there
was a little logic bug in properly skipping connectors. This has
been broken when moving the pipe bpp selection in
commit 4e53c2e010e531b4a014692199e978482d471c7e
Author: Da
Since this is run in the compute config stage we need to check
the new_ pointers, not the current modeset layout. Also there
was a little logic bug in properly skipping connectors. This has
been broken when moving the pipe bpp selection in
commit 4e53c2e010e531b4a014692199e978482d471c7e
Author: Da
On Sat, Jun 01, 2013 at 06:52:39PM +0100, Chris Wilson wrote:
> On Sat, Jun 01, 2013 at 07:45:55PM +0200, Daniel Vetter wrote:
> > Since this is run in the compute config stage we need to check
> > the new_ pointers, not the current modeset layout. Also there
> > was a little logic bug in properly
On Sat, Jun 01, 2013 at 07:45:55PM +0200, Daniel Vetter wrote:
> Since this is run in the compute config stage we need to check
> the new_ pointers, not the current modeset layout. Also there
> was a little logic bug in properly skipping connectors. This has
> been broken when moving the pipe bpp s
Since this is run in the compute config stage we need to check
the new_ pointers, not the current modeset layout. Also there
was a little logic bug in properly skipping connectors. This has
been broken when moving the pipe bpp selection in
commit 4e53c2e010e531b4a014692199e978482d471c7e
Author: Da
We always limited the link bw calculations to 24bpp. Tested with
my shiny new high-bpc screen, seems to work as advertised.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drive
Incomplete since ilk+ support needs proper pch dpll tracking first.
SDVO get_config parts based on a patch from Jesse Barnes, but fixed up
to actually work.
Cc: Jesse Barnes
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 25 +
drivers/gpu/drm/i91
This way we can simplify the code quite a bit.
Also add a WARN in the sdvo code to complain about a bogus value
and kill the readout code in intel_ddi.c that Jesse sneaked in.
HW state readout for the pixel multiplier will work a bit differently
in the end.
v2: Rebase on top of the fdi pixel mutl
Panel fitters on ivb/hsw are not created equal since not all of them
support the new high-quality upscaling mode. To offset this the hw
allows us to freely assign the pfits to pipes.
Since our code currently doesn't support this we might fall over when
taking over firmware state. So check for this
We can get at this easily through intel_crtc->config now.
v2: Drop more stuff gcc spotted.
v3: Drop even more stuff gcc spotted.
v4: Yet more ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 24
1 file changed, 8 insertions(+), 16 deletions(
This prepares a bit for the next big patch, where we switch the
semantics of the different clocks in the pipe config around.
Since I've broken cpu eDP PLL handling in the first version I've
figured some refactoring is in order.
Split out on request from Paulo Zanoni.
Signed-off-by: Daniel Vetter
... not the port clock. This allows us to kill the funny semantics
around pixel_target_clock.
Since the dpll code still needs the real port clock, add a new
port_clock field to the pipe configuration. Handling the default case
for that one is a bit tricky, since encoders might not consistently
ove
Now that the DP madness is cleared out, this is all only per-platform.
So move it out from the intel clock limits structure.
While at it drop the intel prefix on the static functions, call the
vtable entry find_dpll (since it's for the display pll) and rip out
the now unnecessary forward declarati
We currently mutliply the link_bw of the fdi link with the pixel
multiplier, which is wrong: The FDI link doesn't suddenly grow more
bandwidth. In reality the pixel mutliplication only happens in the PCH,
before the pixels are fed into the port.
But since we our code treats the uses the target clo
Pineview is just different.
Also split out i9xx_clock from intel_clock and drop the now redundant
struct device * parameter.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 92 ++--
1 file changed, 77 insertions(+), 15 deletions(-)
diff -
Hi all,
So Paulo asked me to split out two prep patches and I've figured I might as well
reorder the series a bit to make more sense.
The check for strange pfit assignements is still in here, but still for Mika to
review. Otherwise I think Paulo volunteered himself to have a good look at this.
C
On Sat, Jun 1, 2013 at 1:34 PM, Chris Wilson wrote:
> On Sat, Jun 01, 2013 at 11:17:10AM +0200, Daniel Vetter wrote:
>> On Sat, Jun 1, 2013 at 1:51 AM, Chris Wilson
>> wrote:
>> > That neatly explains the WARN. Not too happy about accumulating lots of
>> > backing storage specific processing int
On Sat, Jun 01, 2013 at 11:17:10AM +0200, Daniel Vetter wrote:
> On Sat, Jun 1, 2013 at 1:51 AM, Chris Wilson wrote:
> > That neatly explains the WARN. Not too happy about accumulating lots of
> > backing storage specific processing into free_object, but that can be
> > fixed up later (there is an
On Sat, Jun 1, 2013 at 1:51 AM, Chris Wilson wrote:
> On Fri, May 31, 2013 at 02:46:20PM -0700, Ben Widawsky wrote:
>> The way the stolen handling works is we take a pin on the backing pages,
>> but we never actually get a reference to the bo. On freeing objects
>> allocated with stolen memory, th
19 matches
Mail list logo
