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

From: Daniel Vetter <daniel@ffwll.ch>
To: Shobhit Kumar <shobhit.kumar@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>,
	Shobhit Kumar <shobhit.kumar@intel.com>,
	intel-gfx@lists.freedesktop.org,
	Thierry Reding <thierry.reding@gmail.com>
Subject: Re: [RFC PATCH 05/12] drm/i915/dsi: remove unnecessary dsi device callbacks
Date: Wed, 28 Jan 2015 10:17:21 +0100	[thread overview]
Message-ID: <20150128091721.GI4764@phenom.ffwll.local> (raw)
In-Reply-To: <54C86EDD.1030604@linux.intel.com>

On Wed, Jan 28, 2015 at 10:38:45AM +0530, Shobhit Kumar wrote:
> On 01/27/2015 06:43 PM, Chris Wilson wrote:
> >On Tue, Jan 27, 2015 at 02:09:21PM +0100, Daniel Vetter wrote:
> >>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@linux.intel.com> 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 ...
> >
> >Also how is this different from userspace creating a 800x600 mode and
> >giving it to the kernel which then uses the pfitter to display it at
> >native resolution. That is how it works today. This should also be
> >possible with a video= parameter...
> 
> Its different in a way, that user space changes will need a new system build
> which is not allowed as per the requirements that we had and hence no hard
> coding in code anywhere as well.
> 
> As I said earlier also that this case might not be useful in general and I
> am okay to remove this callback.

Yeah I think if rebuilding vbt for testing is ok, but rebuilding the
kernel isn't then that just smells like needless red tape. I'll reconsider
as soon as we need this for shipping systems of course.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx