On Mon, Jul 22, 2013 at 06:55:55AM +0200, Knut Petersen wrote:
On 11.07.2013 19:22, Daniel Vetter wrote:
On Thu, Jul 11, 2013 at 06:29:15PM +0200, Knut Petersen wrote:
On 11.07.2013 13:49, Chris Wilson wrote:
On Thu, Jul 11, 2013 at 01:35:40PM +0200, Daniel Vetter wrote:
It's in the
On 11.07.2013 19:22, Daniel Vetter wrote:
On Thu, Jul 11, 2013 at 06:29:15PM +0200, Knut Petersen wrote:
On 11.07.2013 13:49, Chris Wilson wrote:
On Thu, Jul 11, 2013 at 01:35:40PM +0200, Daniel Vetter wrote:
It's in the PFIT_CONTROL register, but very much associated with the
lvds encoder.
It's in the PFIT_CONTROL register, but very much associated with the
lvds encoder. So move the readout for it (in the case of an otherwise
disabled pfit) from the pipe to the lvds encoder's get_config
function.
Otherwise we get a pipe state mismatch if we use pipe B for a non-lvds
output and
It's in the PFIT_CONTROL register, but very much associated with the
lvds encoder. So move the readout for it (in the case of an otherwise
disabled pfit) from the pipe to the lvds encoder's get_config
function.
Otherwise we get a pipe state mismatch if we use pipe B for a non-lvds
output and
On Thu, Jul 11, 2013 at 01:35:40PM +0200, Daniel Vetter wrote:
It's in the PFIT_CONTROL register, but very much associated with the
lvds encoder. So move the readout for it (in the case of an otherwise
disabled pfit) from the pipe to the lvds encoder's get_config
function.
Otherwise we get
Hi Knut,
When you test this patch please grab a dmesg with drm.debug=0xe
regardless of outcome, I'd like to check a few other odd things with
your system (which seem to not be directly related to the issue at
hand).
Thanks, Daniel
On Thu, Jul 11, 2013 at 1:35 PM, Daniel Vetter
On Thu, Jul 11, 2013 at 06:29:15PM +0200, Knut Petersen wrote:
On 11.07.2013 13:49, Chris Wilson wrote:
On Thu, Jul 11, 2013 at 01:35:40PM +0200, Daniel Vetter wrote:
It's in the PFIT_CONTROL register, but very much associated with the
lvds encoder. So move the readout for it (in the case of
