On 25.09.13 10:14, Ville Syrjälä wrote:
On Wed, Sep 25, 2013 at 04:35:56AM +0200, Mario Kleiner wrote:
On 23.09.13 13:48, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We have all the information we need in the mode structure, so going and
reading it
On Wed, Sep 25, 2013 at 6:45 AM, Mario Kleiner
mario.klei...@tuebingen.mpg.de wrote:
Mario, can you please take a look at these patches and ack them? I'd like
to slurp them in for -next.
Done in the other e-mails, with some comments. However, i'd like to test
these a bit and it might take a
On Wed, Sep 25, 2013 at 04:35:56AM +0200, Mario Kleiner wrote:
On 23.09.13 13:48, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We have all the information we need in the mode structure, so going and
reading it from the hardware is pointless, and
On 24.09.13 11:11, Daniel Vetter wrote:
...
Hooray, this rips out the racy pipe_to_cpu_transcoder deref, so I'm all in
favour \o/ Of course I still have that ugly itme on my todo about fix the
locking for kms vblank stuff ;-)
See the other e-mail i sent. Maybe pushing the time read into the
On 23.09.13 13:48, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We have all the information we need in the mode structure, so going and
reading it from the hardware is pointless, and slower.
We never populated -get_vblank_timestamp() in the UMS case,
From: Ville Syrjälä ville.syrj...@linux.intel.com
We have all the information we need in the mode structure, so going and
reading it from the hardware is pointless, and slower.
We never populated -get_vblank_timestamp() in the UMS case, and as that
is the only way we'd ever call
