Re: [PATCH v2 0/7] drm/i915: Baytrail MIPI DSI support Updated

Re: [PATCH v2 0/7] drm/i915: Baytrail MIPI DSI support Updated

[Daniel Vetter]

On Sat, Nov 09, 2013 at 03:19:01PM +0530, Shobhit Kumar wrote:
> Hi All - 
> These patches enhance the current support for MIPI DSI for Baytrail. They
> continue on the sub-encoder design and adds few more dev_ops to handle
> sequence correctly. Major changes are -
> 
> 1. DSI Clock calculation based on pixel clock
> 2. Add new dev_ops for better sequencing the enable/disable path
> 3. Parameterized the hardcoded DSI parameters. These also forms building
>    block for the generic MIPI driver to come in future based on enhancements
>    in VBT. All these parameters are initialized or computed in the sub-encoder
>    driver. Some of them might look unneccesary for now.
> 
>  I am also aware of the drm_bridge support now comming in and will in future
>  migrate from sub-encoder design to drm_bridge.

Just a quick aside: Thierry Reding from nvidia is also working on a DSI
design for the tegra driver. Atm he seems to aim for a full-blown DSI bus
based on his drm_panel patches for getting the panel metadata out of an
ARM DT (we'd use VBT instead). Iirc there's no patches anywhere yet, but
maybe Thierry could share a git branch somewhere with the wip stuff?

Cc'ing Thierry and dri-devel in case a bigger discussion develops.

Cheers, Daniel

> 
> This DSI sequence has been validated with couple of test panels and is working now.
> Still no sub-encoder driver is included and this support will be mostly be disabled
> untill a panel sub-encoder driver is added. Proper detection or VBT is still pending.
> 
> v2: Mostly changes from review comments from Jani Nikula and Ville Syrjala
>     - Split the parameters into new patch
>     - Split the dsi_clk computation and m-n-p modification in separate patches
>     - The DSI sequence refactoring has been splitted into multiple patches and also
>       few code changes are not needed after reworking/relooking at them and have been
>       removed
>     - Backlight enabling has been removed as that depends on platform PMIC driver which
>       is not yet there in upstream kernel. Will be added later.
>     - Other general code cleanup as suggested
>     - drm/i915: Use FLISDSI interface for band gap reset - has no changes and is included 
>       for completeness of the patch set
> 
> Regards
> Shobhit
> 
> Shobhit Kumar (7):
>   drm/i915: Add more dev ops for MIPI sub encoder
>   drm/i915: Use FLISDSI interface for band gap reset
>   drm/i915: Compute dsi_clk from pixel clock
>   drm/i915: Try harder to get best m,n,p values with minimal error
>   drm/i915: Reorganize the DSI enable/disable sequence
>   drm/i915: Remove redundant DSI PLL enabling
>   drm/i915: Parametrize the dphy and other spec specific parameters
> 
>  drivers/gpu/drm/i915/i915_drv.h       |   13 +++
>  drivers/gpu/drm/i915/i915_reg.h       |    1 +
>  drivers/gpu/drm/i915/intel_dsi.c      |  187 ++++++++++++++++++---------------
>  drivers/gpu/drm/i915/intel_dsi.h      |   21 ++++
>  drivers/gpu/drm/i915/intel_dsi_pll.c  |   72 ++++++++++---
>  drivers/gpu/drm/i915/intel_sideband.c |   14 +++
>  6 files changed, 209 insertions(+), 99 deletions(-)
> 
> -- 
> 1.7.9.5
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Intel-gfx] [PATCH v2 0/7] drm/i915: Baytrail MIPI DSI support Updated

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 2185 bytes --]

On Sat, Nov 09, 2013 at 11:28:16AM +0100, Daniel Vetter wrote:
> On Sat, Nov 09, 2013 at 03:19:01PM +0530, Shobhit Kumar wrote:
> > Hi All - 
> > These patches enhance the current support for MIPI DSI for Baytrail. They
> > continue on the sub-encoder design and adds few more dev_ops to handle
> > sequence correctly. Major changes are -
> > 
> > 1. DSI Clock calculation based on pixel clock
> > 2. Add new dev_ops for better sequencing the enable/disable path
> > 3. Parameterized the hardcoded DSI parameters. These also forms building
> >    block for the generic MIPI driver to come in future based on enhancements
> >    in VBT. All these parameters are initialized or computed in the sub-encoder
> >    driver. Some of them might look unneccesary for now.
> > 
> >  I am also aware of the drm_bridge support now comming in and will in future
> >  migrate from sub-encoder design to drm_bridge.
> 
> Just a quick aside: Thierry Reding from nvidia is also working on a DSI
> design for the tegra driver. Atm he seems to aim for a full-blown DSI bus
> based on his drm_panel patches for getting the panel metadata out of an
> ARM DT (we'd use VBT instead). Iirc there's no patches anywhere yet, but
> maybe Thierry could share a git branch somewhere with the wip stuff?
> 
> Cc'ing Thierry and dri-devel in case a bigger discussion develops.

I've been cleaning up the patches and was going to post them today. The
implementation really isn't as "full-blown" as you make it sound =),
primarily because the DSI panel that I have doesn't support things such
as reading out the DDB, so I cannot test most of the functionality that
I planned to.

However I think introducing a DSI bus type is the right thing and it's
been suggested recently that we have too few bus types. Furthermore it
seems to be playing out rather nicely with the DRM panel work, so it
would be really nice if Intel could test-drive this within their driver
to see if it's good enough for their purposes as well.

Is everyone working on that subscribed to dri-devel or should I Cc the
intel-gfx mailing list (or someone in particular) when posting the
patches?

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 0/7] drm/i915: Baytrail MIPI DSI support Updated

[Shobhit Kumar]

On 11/11/2013 02:20 PM, Thierry Reding wrote:
> On Sat, Nov 09, 2013 at 11:28:16AM +0100, Daniel Vetter wrote:
>> On Sat, Nov 09, 2013 at 03:19:01PM +0530, Shobhit Kumar wrote:
>>> Hi All -
>>> These patches enhance the current support for MIPI DSI for Baytrail. They
>>> continue on the sub-encoder design and adds few more dev_ops to handle
>>> sequence correctly. Major changes are -
>>>
>>> 1. DSI Clock calculation based on pixel clock
>>> 2. Add new dev_ops for better sequencing the enable/disable path
>>> 3. Parameterized the hardcoded DSI parameters. These also forms building
>>>     block for the generic MIPI driver to come in future based on enhancements
>>>     in VBT. All these parameters are initialized or computed in the sub-encoder
>>>     driver. Some of them might look unneccesary for now.
>>>
>>>   I am also aware of the drm_bridge support now comming in and will in future
>>>   migrate from sub-encoder design to drm_bridge.
>>
>> Just a quick aside: Thierry Reding from nvidia is also working on a DSI
>> design for the tegra driver. Atm he seems to aim for a full-blown DSI bus
>> based on his drm_panel patches for getting the panel metadata out of an
>> ARM DT (we'd use VBT instead). Iirc there's no patches anywhere yet, but
>> maybe Thierry could share a git branch somewhere with the wip stuff?
>>
>> Cc'ing Thierry and dri-devel in case a bigger discussion develops.
>
> I've been cleaning up the patches and was going to post them today. The
> implementation really isn't as "full-blown" as you make it sound =),
> primarily because the DSI panel that I have doesn't support things such
> as reading out the DDB, so I cannot test most of the functionality that
> I planned to.
>
> However I think introducing a DSI bus type is the right thing and it's
> been suggested recently that we have too few bus types. Furthermore it
> seems to be playing out rather nicely with the DRM panel work, so it
> would be really nice if Intel could test-drive this within their driver
> to see if it's good enough for their purposes as well.

Interesting. Would be nice to have a look.

>
> Is everyone working on that subscribed to dri-devel or should I Cc the
> intel-gfx mailing list (or someone in particular) when posting the
> patches?
>

Will keep an eye for your patches in dri-devel.

Regards
Shobhit