Re: [RFC PATCH 05/12] drm/i915/dsi: remove unnecessary dsi device callbacks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 27, 2015 at 02:11:18PM +0530, Shobhit Kumar wrote:
> On 01/23/2015 08:52 PM, Daniel Vetter wrote:
> >On Fri, Jan 23, 2015 at 03:14:41PM +0530, Shobhit Kumar wrote:
> >>On 01/22/2015 06:53 PM, Jani Nikula wrote:
> >>>On Thu, 22 Jan 2015, Shobhit Kumar <shobhit.kumar@xxxxxxxxxxxxxxx> wrote:
> >>>>There had been a instance where we had to drive different resolution
> >>>>(lower) than the native one. Also in VBT there is a field to make this
> >>>>generic at least from driver perspective to give the needed target
> >>>>resolution. In case target resolution is same as native, nothing gets
> >>>>changed, else mode_fixup function adjusts the mode accordingly keeping
> >>>>timing as same and enabling scalar. Might not be useful in general, but
> >>>>did find a use internally.
> >>>
> >>>Can we just have the driver return the desired mode from .get_modes in
> >>>that case?
> >>
> >>Okay, I think I did not explain correctly. Get modes is modified to give the
> >>needed target mode only so that userspace creates buffer of the needed
> >>resolution, but in fixup which is called at modeset, we correct the
> >>adjusted_mode back to have native resolutions so that modeset is correctly
> >>done. if we do not do like this, during modeset resolutions will be wrong as
> >>per the timings.
> >
> >I'm confused. Can you please give an example in real numbers about the
> >different resolution and how it's all fixed up in hw?
> >
> >E.g. 800x600 framebuffer -> pfit -> 1024x756 panel,
> >
> >get_modes gives 800x600, adjusted mode corrects to 1024x756. And please
> 
> We had a 19x12 DSI panel which we needed to drive at 12x8 due to lack of
> 12x8 panels for testing purposes. So get_modes returned 12x8 so that user
> space gave 12x8 FBs, and internally in mode_fixup we adjusted correctly for
> the 19x12 panel timings and enabled pfit

Hm, is that a real use-case shipping to customers or just a hack for
development? In the later case I think we can just hardcode the edid for
edp ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux