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

From: Shobhit Kumar <shobhit.kumar@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Daniel Vetter <daniel@ffwll.ch>,
	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:38:45 +0530	[thread overview]
Message-ID: <54C86EDD.1030604@linux.intel.com> (raw)
In-Reply-To: <20150127131346.GB28132@nuc-i3427.alporthouse.com>

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.

Regards
Shobhit
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx