[Intel-gfx] [PATCH 0/3] BYT DSI Dual Link Support

[Singh, Gaurav K]

On 11/24/2014 2:31 PM, Jani Nikula wrote:
> On Mon, 24 Nov 2014, "Singh, Gaurav K" <gaurav.k.singh at intel.com> wrote:
>> Hi Jani,
>>
>> Thanks for the review comments.
>>
>> Regarding the first 2 patches, I was doing almost the same thing in my
>> 3rd and 4th patch. But your patches are more generic.
>>
>> Regarding the 3rd patch, I have a comment:
>>
>> Since in case of dual link panels, few panels may require sequence to be
>> sent only on Port A or Port C or both. In that case,
>> for_each_dsi_port(port, intel_dsi->ports) will cause it to be sent to
>> both ports.
>> To resolve this, in the earlier patches, intel_dsi->port was used which
>> gets calculated to either 0 or 1 in mipi_exec_send_packet(). This value
>> of 0 or 1 is dependent on sequence block#53.
>>
>>   From now on as we will be using the _PORT3() macro for using proper
>> MIPI regs, then for this scenario, we may need to have some
>> workaround/hardcode type of code again. May I know your suggestion on this?
> Perhaps patch 3/3 was a bad place for the for_each_dsi_port example - it
> should have been put into intel_dsi.c. Maybe you'll need to add the port
> as parameter to the functions in intel_dsi_cmd.c, and let the caller
> decide which port should be used? I want to avoid any platform/panel
> specific special casing in intel_dsi.c and intel_dsi_cmd.c.
>
> I think the general case for for_each_dsi_port is in intel_dsi.c anyway.
>
> BR,
> Jani.
Jani,

I have taken care of this in the next version of dual link patches. 
PATCH 3/3 need not be merged as it has already been taken care as part 
of dual link implementation. Once your first two patches gets merged in 
drm-intel-nightly branch, I can push the next version of dual link 
patches for review.

With regards,
Gaurav
>
>> With regards,
>> Gaurav
>>
>> On 11/14/2014 8:24 PM, Jani Nikula wrote:
>>> Hi Shobhit and Gaurav -
>>>
>>> I've been pondering this whole MIPI DSI pipes vs. ports thing and
>>> discussing with Ville and others. Rather than try and fail in explaining
>>> the ideas, here are some concrete patches to describe what I'd like to
>>> be done first.
>>>
>>> The most important thing is that we don't confuse the pipes and
>>> ports. Getting confused was easy with the pipe B mapping to port C, and
>>> the register defines being very confused/confusing about it. These
>>> patches attempt to fix that. Before adding dual link support, there's a
>>> simple function mapping the pipe to port.
>>>
>>> Next up is expanding that to handle multiple ports driven from one
>>> pipe. That's handled by adding intel_dsi->ports bitmap that has the bit
>>> set for each port that is to be driven. I've added the bitmap and some
>>> helpers to iterate over the configured ports, but there's no actual
>>> support for doing the configuration. I'm hoping you could take over from
>>> here. There's a sample patch about the usage.
>>>
>>> I'm sorry it's taken me so long to reply. With the new stuff coming in,
>>> I really think it's important to get the foundation right
>>> first. Especially because I'm to blame for getting some of the port/pipe
>>> stuff confused in the first place...
>>>
>>> BR,
>>> Jani.
>>>
>>>
>>>
>>> Jani Nikula (3):
>>>     drm/i915/dsi: clean up MIPI DSI pipe vs. port usage
>>>     drm/i915/dsi: add ports to intel_dsi to describe the ports being
>>>       driven
>>>     drm/i915/dsi: an example how to handle dual link for each port
>>>
>>>    drivers/gpu/drm/i915/i915_reg.h      | 303 ++++++++++++++++++-----------------
>>>    drivers/gpu/drm/i915/intel_dsi.c     | 151 ++++++++---------
>>>    drivers/gpu/drm/i915/intel_dsi.h     |  19 +++
>>>    drivers/gpu/drm/i915/intel_dsi_cmd.c |  76 ++++-----
>>>    4 files changed, 290 insertions(+), 259 deletions(-)
>>>