[Intel-gfx] [PATCH 2/2] drm/i915: GPIO for CHT generic MIPI

Deepak, M m.deepak at intel.com
Mon Feb 29 15:07:42 UTC 2016



> -----Original Message-----
> From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com]
> Sent: Monday, February 29, 2016 7:20 PM
> To: Deepak, M <m.deepak at intel.com>
> Cc: intel-gfx at lists.freedesktop.org; Mohan Marimuthu, Yogesh
> <yogesh.mohan.marimuthu at intel.com>; Nikula, Jani
> <jani.nikula at intel.com>
> Subject: Re: [PATCH 2/2] drm/i915: GPIO for CHT generic MIPI
> 
> On Mon, Feb 29, 2016 at 11:00:34AM +0000, Deepak, M wrote:
> >
> >
> > > -----Original Message-----
> > > From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com]
> > > Sent: Thursday, February 25, 2016 9:07 PM
> > > To: Deepak, M <m.deepak at intel.com>
> > > Cc: intel-gfx at lists.freedesktop.org; Mohan Marimuthu, Yogesh
> > > <yogesh.mohan.marimuthu at intel.com>; Nikula, Jani
> > > <jani.nikula at intel.com>
> > > Subject: Re: [PATCH 2/2] drm/i915: GPIO for CHT generic MIPI
> > >
> > > On Wed, Feb 24, 2016 at 07:13:46PM +0530, Deepak M wrote:
> > > > From: Yogesh Mohan Marimuthu
> <yogesh.mohan.marimuthu at intel.com>
> > > >
> > > > The GPIO configuration and register offsets are different from
> > > > baytrail for cherrytrail. Port the gpio programming accordingly
> > > > for cherrytrail in this patch.
> > > >
> > > > v2: Removing the duplication of parsing
> > > >
> > > > v3: Moved the macro def to panel_vbt.c file
> > > >
> > > > Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > Cc: Jani Nikula <jani.nikula at intel.com>
> > > > Signed-off-by: Yogesh Mohan Marimuthu
> > > > <yogesh.mohan.marimuthu at intel.com>
> > > > Signed-off-by: Deepak M <m.deepak at intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 123
> > > > +++++++++++++++++++++++------
> > > >  1 file changed, 98 insertions(+), 25 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> > > > b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> > > > index 794bd1f..6b9a1f7 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> > > > @@ -58,6 +58,28 @@ static inline struct vbt_panel
> > > > *to_vbt_panel(struct drm_panel *panel)
> > > >
> > > >  #define NS_KHZ_RATIO 1000000
> > > >
> > > > +#define CHV_IOSF_PORT_GPIO_N                 0x13
> > > > +#define CHV_IOSF_PORT_GPIO_SE                0x48
> > > > +#define CHV_IOSF_PORT_GPIO_SW                0xB2
> > > > +#define CHV_IOSF_PORT_GPIO_E                 0xA8
> > >
> > > These should have remained where the other ports were defined.
> > >
> > > > +#define CHV_MAX_GPIO_NUM_N                   72
> > > > +#define CHV_MAX_GPIO_NUM_SE                  99
> > > > +#define CHV_MAX_GPIO_NUM_SW                  197
> > > > +#define CHV_MIN_GPIO_NUM_SE                  73
> > > > +#define CHV_MIN_GPIO_NUM_SW                  100
> > > > +#define CHV_MIN_GPIO_NUM_E                   198
> > >
> > > I never got any explanation where the block sizes came from on VLV.
> > > IIRC when I checked them against configdb they didn't match the
> > > actual number of pins in the hardware block. And the same story
> continues here.
> > > Eg. if I check configfb the number of pins in each block is:
> > > N 59, SE 55, SW 56, E 24.
> > >
> > > So I can't review this until someone explains where this stuff comes from.
> > > And there should probably be a comment next to the defines to remind
> > > the next guy who gets totally confused by this.
> > >
> > > Also I don't like the fact that VLV and CHV are now implemented in
> > > two totally different ways. Can you eliminate the massive gpio table
> > > from the VLV code to make it more similar to this?
> > >
> > [Deepak, M] In CHV the GPIO numberings are sequential but in VLV that
> > is not the case, hence the complete table is copied here. I have
> > attached the VLV GPIO mapping table which can clear your doubts. Pfa,
> 
> Any chance someone could try to get this table included in the spec, or at
> least have a link to it? Having the information spread around this way is not
> productive.
[Deepak, M] Sure, will try to put this doc in sharepoint. 
> 
> --
> Ville Syrjälä
> Intel OTC


More information about the Intel-gfx mailing list