Re: [rft, PATCH v1 0/2] drm/i915/dsi: An attempt to get rid of IOSF GPIO on VLV
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 don't know from the top of my head > > which devices actually use this, so I may need to try quite a few devices > > before finding one which actually uses this. > > > > I'll try to get this series tested sometime the coming weeks, > > depending on when I can schedule some time for this. > > No hurry. maybe you simply can add into your usual tree you run on your > devices? FYI, I have just sent a v2, which includes CHV conversion. -- With Best Regards, Andy Shevchenko
Re: [rft, PATCH v1 0/2] drm/i915/dsi: An attempt to get rid of IOSF GPIO on VLV
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 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? > > Yes I should be able to find a device or 2 which poke GPIOs from the > VBT MIPI sequences. Unfortunately I don't know from the top of my head > which devices actually use this, so I may need to try quite a few devices > before finding one which actually uses this. > > I'll try to get this series tested sometime the coming weeks, > depending on when I can schedule some time for this. No hurry. maybe you simply can add into your usual tree you run on your devices? -- With Best Regards, Andy Shevchenko
Re: [rft, PATCH v1 0/2] drm/i915/dsi: An attempt to get rid of IOSF GPIO on VLV
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 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? Yes I should be able to find a device or 2 which poke GPIOs from the VBT MIPI sequences. Unfortunately I don't know from the top of my head which devices actually use this, so I may need to try quite a few devices before finding one which actually uses this. I'll try to get this series tested sometime the coming weeks, depending on when I can schedule some time for this. Regards, Hans > > Andy Shevchenko (2): > drm/i915/dsi: Extract common soc_gpio_exec() helper > drm/i915/dsi: Replace poking of VLV GPIOs behind the driver's back > > drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 150 +++ > 1 file changed, 58 insertions(+), 92 deletions(-) >
[rft, PATCH v1 0/2] drm/i915/dsi: An attempt to get rid of IOSF GPIO on VLV
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 use this piece of code, is it possible to give a test run on (one of) them? Andy Shevchenko (2): drm/i915/dsi: Extract common soc_gpio_exec() helper drm/i915/dsi: Replace poking of VLV GPIOs behind the driver's back drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 150 +++ 1 file changed, 58 insertions(+), 92 deletions(-) -- 2.40.0.1.gaa8946217a0b
