[rft,v4,00/16] drm/i915/dsi: 4th attempt to get rid of IOSF GPIO

  DSI code for VBT has a set of ugly GPIO hacks, one of which is direct
talking to GPIO IP behind the actual driver's back. A second attempt
to fix that is here.

If I understood correctly, my approach should work in the similar way as
the current IOSF GPIO.

Hans, I believe you have some devices that use this piece of code,
is it possible to give a test run on (one of) them?

In v4:
- fixed compile time errors in patch 14 (Hans, LKP)
- fixed cover letter Subject
- added patch 15 (as suggested by Ville)
- added Ack tag (Jani)

In v3:
- incorporated series by Jani
- incorporated couple of precursor patches by Hans
- added Rb tag for used to be first three patches (Andi)
- rebased on top of the above changes
- fixed indexing for multi-community devices, such as Cherry View

In v2:
- added a few cleanup patches
- reworked to use dynamic GPIO lookup tables
- converted CHV as well

Andy Shevchenko (9):
  drm/i915/dsi: Replace while(1) with one with clear exit condition
  drm/i915/dsi: Get rid of redundant 'else'
  drm/i915/dsi: Replace check with a (missing) MIPI sequence name
  drm/i915/dsi: Extract common soc_gpio_set_value() helper
  drm/i915/dsi: Replace poking of VLV GPIOs behind the driver's back
  drm/i915/dsi: Prepare soc_gpio_set_value() to distinguish GPIO
    communities
  drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back
  drm/i915/dsi: Combine checks in mipi_exec_gpio()
  drm/i915/iosf: Drop unused APIs

Hans de Goede (2):
  drm/i915/dsi: Remove GPIO lookup table at the end of
    intel_dsi_vbt_gpio_init()
  drm/i915/dsi: Fix wrong initial value for GPIOs in
    bxt_gpio_set_value()

Jani Nikula (5):
  drm/i915/dsi: assume BXT gpio works for non-native GPIO
  drm/i915/dsi: switch mipi_exec_gpio() from dev_priv to i915
  drm/i915/dsi: clarify GPIO exec sequence
  drm/i915/dsi: rename platform specific *_exec_gpio() to
    *_gpio_set_value()
  drm/i915/dsi: bxt/icl GPIO set value do not need gpio source

 drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 355 +++++++------------
 drivers/gpu/drm/i915/vlv_sideband.c          |  17 -
 drivers/gpu/drm/i915/vlv_sideband.h          |   3 -
 3 files changed, 136 insertions(+), 239 deletions(-)
  

Hi,

On 11/3/23 21:18, Andy Shevchenko wrote:
> DSI code for VBT has a set of ugly GPIO hacks, one of which is direct
> talking to GPIO IP behind the actual driver's back. A second attempt
> to fix that is here.
> 
> If I understood correctly, my approach should work in the similar way as
> the current IOSF GPIO.
> 
> Hans, I believe you have some devices that use this piece of code,
> is it possible to give a test run on (one of) them?

Ok, this now has been testen on both a BYT and a CHT device which
actually use GPIO controls in their MIPI sequences so this
series is:

Tested-by: Hans de Goede <hdegoede@redhat.com>

And the code of the entire series also looks good to me:

Reviewed-by: Hans de Goede <hdegoede@redhat.com>

for the series.

Regards,

Hans




> In v4:
> - fixed compile time errors in patch 14 (Hans, LKP)
> - fixed cover letter Subject
> - added patch 15 (as suggested by Ville)
> - added Ack tag (Jani)
> 
> In v3:
> - incorporated series by Jani
> - incorporated couple of precursor patches by Hans
> - added Rb tag for used to be first three patches (Andi)
> - rebased on top of the above changes
> - fixed indexing for multi-community devices, such as Cherry View
> 
> In v2:
> - added a few cleanup patches
> - reworked to use dynamic GPIO lookup tables
> - converted CHV as well
> 
> Andy Shevchenko (9):
>   drm/i915/dsi: Replace while(1) with one with clear exit condition
>   drm/i915/dsi: Get rid of redundant 'else'
>   drm/i915/dsi: Replace check with a (missing) MIPI sequence name
>   drm/i915/dsi: Extract common soc_gpio_set_value() helper
>   drm/i915/dsi: Replace poking of VLV GPIOs behind the driver's back
>   drm/i915/dsi: Prepare soc_gpio_set_value() to distinguish GPIO
>     communities
>   drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back
>   drm/i915/dsi: Combine checks in mipi_exec_gpio()
>   drm/i915/iosf: Drop unused APIs
> 
> Hans de Goede (2):
>   drm/i915/dsi: Remove GPIO lookup table at the end of
>     intel_dsi_vbt_gpio_init()
>   drm/i915/dsi: Fix wrong initial value for GPIOs in
>     bxt_gpio_set_value()
> 
> Jani Nikula (5):
>   drm/i915/dsi: assume BXT gpio works for non-native GPIO
>   drm/i915/dsi: switch mipi_exec_gpio() from dev_priv to i915
>   drm/i915/dsi: clarify GPIO exec sequence
>   drm/i915/dsi: rename platform specific *_exec_gpio() to
>     *_gpio_set_value()
>   drm/i915/dsi: bxt/icl GPIO set value do not need gpio source
> 
>  drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 355 +++++++------------
>  drivers/gpu/drm/i915/vlv_sideband.c          |  17 -
>  drivers/gpu/drm/i915/vlv_sideband.h          |   3 -
>  3 files changed, 136 insertions(+), 239 deletions(-)
>
  

On Thu, 16 Nov 2023, Hans de Goede <hdegoede@redhat.com> wrote:
> Ok, this now has been testen on both a BYT and a CHT device which
> actually use GPIO controls in their MIPI sequences so this
> series is:
>
> Tested-by: Hans de Goede <hdegoede@redhat.com>
>
> And the code of the entire series also looks good to me:
>
> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
>
> for the series.

Thanks Andy & Hans!

I'll merge this once the test results are in. The BAT results have been
a bit flaky recently, so needed to do a rerun.

That said, I'm not sure if we have any hardware in CI that would
actually exercise the modifications, so in that sense I trust Hans'
testing much more.

BR,
Jani.
  

On Thu, Nov 16, 2023 at 12:15:03PM +0200, Jani Nikula wrote:
> On Thu, 16 Nov 2023, Hans de Goede <hdegoede@redhat.com> wrote:
> > Ok, this now has been testen on both a BYT and a CHT device which
> > actually use GPIO controls in their MIPI sequences so this
> > series is:
> >
> > Tested-by: Hans de Goede <hdegoede@redhat.com>
> >
> > And the code of the entire series also looks good to me:
> >
> > Reviewed-by: Hans de Goede <hdegoede@redhat.com>
> >
> > for the series.
> 
> Thanks Andy & Hans!
> 
> I'll merge this once the test results are in. The BAT results have been
> a bit flaky recently, so needed to do a rerun.
> 
> That said, I'm not sure if we have any hardware in CI that would
> actually exercise the modifications, so in that sense I trust Hans'
> testing much more.

Thank you!
Should I fix checkpatch warnings CI reported about?
  

On Thu, Nov 16, 2023 at 09:58:06AM +0100, Hans de Goede wrote:
> On 11/3/23 21:18, Andy Shevchenko wrote:
> > DSI code for VBT has a set of ugly GPIO hacks, one of which is direct
> > talking to GPIO IP behind the actual driver's back. A second attempt
> > to fix that is here.
> > 
> > If I understood correctly, my approach should work in the similar way as
> > the current IOSF GPIO.
> > 
> > Hans, I believe you have some devices that use this piece of code,
> > is it possible to give a test run on (one of) them?
> 
> Ok, this now has been testen on both a BYT and a CHT device which
> actually use GPIO controls in their MIPI sequences so this
> series is:
> 
> Tested-by: Hans de Goede <hdegoede@redhat.com>
> 
> And the code of the entire series also looks good to me:
> 
> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
> 
> for the series.

Good news so far, thank you!
  

On Fri, 17 Nov 2023, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> On Thu, Nov 16, 2023 at 12:15:03PM +0200, Jani Nikula wrote:
>> On Thu, 16 Nov 2023, Hans de Goede <hdegoede@redhat.com> wrote:
>> > Ok, this now has been testen on both a BYT and a CHT device which
>> > actually use GPIO controls in their MIPI sequences so this
>> > series is:
>> >
>> > Tested-by: Hans de Goede <hdegoede@redhat.com>
>> >
>> > And the code of the entire series also looks good to me:
>> >
>> > Reviewed-by: Hans de Goede <hdegoede@redhat.com>
>> >
>> > for the series.
>> 
>> Thanks Andy & Hans!
>> 
>> I'll merge this once the test results are in. The BAT results have been
>> a bit flaky recently, so needed to do a rerun.
>> 
>> That said, I'm not sure if we have any hardware in CI that would
>> actually exercise the modifications, so in that sense I trust Hans'
>> testing much more.
>
> Thank you!
> Should I fix checkpatch warnings CI reported about?

Nah, they're benign.

BR,
Jani.