Re: [rft, PATCH v1 0/2] drm/i915/dsi: An attempt to get rid of IOSF GPIO on VLV

2023-10-24 Thread Andy Shevchenko
On Wed, Oct 18, 2023 at 03:52:36PM +0300, Andy Shevchenko wrote: > On Wed, Oct 18, 2023 at 11:09:35AM +0200, Hans de Goede wrote: > > On 10/18/23 07:10, Andy Shevchenko wrote: ... > > Yes I should be able to find a device or 2 which poke GPIOs from the > > VBT MIPI sequences. Unfortunately I

Re: [rft, PATCH v1 0/2] drm/i915/dsi: An attempt to get rid of IOSF GPIO on VLV

2023-10-18 Thread Andy Shevchenko
On Wed, Oct 18, 2023 at 11:09:35AM +0200, Hans de Goede wrote: > On 10/18/23 07:10, 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. An attempt to fix > > that is here. > > > > If I understood

Re: [rft, PATCH v1 0/2] drm/i915/dsi: An attempt to get rid of IOSF GPIO on VLV

2023-10-18 Thread Hans de Goede
Hi Andy, On 10/18/23 07:10, 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. An attempt to fix > that is here. > > If I understood correctly, my approach should work in the similar way as > the

[rft, PATCH v1 0/2] drm/i915/dsi: An attempt to get rid of IOSF GPIO on VLV

2023-10-17 Thread Andy Shevchenko
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. An 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