From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Jani Nikula <jani.nikula@intel.com>,
intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org, Daniel Vetter <daniel@ffwll.ch>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
David Airlie <airlied@gmail.com>
Subject: Re: [Intel-gfx] [PATCH v2 6/7] drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back
Date: Tue, 31 Oct 2023 18:21:43 +0200 [thread overview]
Message-ID: <ZUEplxH51geCyHdb@smile.fi.intel.com> (raw)
In-Reply-To: <b489675d-e9de-4bca-9622-78545aa8606d@redhat.com>
On Tue, Oct 31, 2023 at 05:07:39PM +0100, Hans de Goede wrote:
> On 10/24/23 18:11, Andy Shevchenko wrote:
> > On Tue, Oct 24, 2023 at 06:57:38PM +0300, Andy Shevchenko wrote:
> >> It's a dirty hack in the driver that pokes GPIO registers behind
> >> the driver's back. Moreoever it might be problematic as simultaneous
> >> I/O may hang the system, see the commit 0bd50d719b00 ("pinctrl:
> >> cherryview: prevent concurrent access to GPIO controllers") for
> >> the details. Taking all this into consideration replace the hack
> >> with proper GPIO APIs being used.
> >
> > Ah, just realised that this won't work if it happens to request to GPIOs with
> > the same index but different communities. I will fix that in v3, but will wait
> > for Hans to test VLV and it might even work in most of the cases on CHV as it
> > seems quite unlikely that the above mentioned assertion is going to happen in
> > real life.
>
> I have added patches 1-5 to my personal tree + a small debug patch on top
> which logs when soc_exec_opaque_gpio() actually gets called.
>
> So these patches will now get run every time I run some tests on
> one my tablets.
>
> I'll get back to you with testing results when I've found a device where
> the new soc_exec_opaque_gpio() actually gets called.
Thank you!
> As for the CHT support, I have not added that to my tree yet, I would
> prefer to directly test the correct/fixed patch.
Noted, I'll prepare a new version then.
--
With Best Regards,
Andy Shevchenko
WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
Jani Nikula <jani.nikula@intel.com>,
intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
dri-devel@lists.freedesktop.org,
Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [PATCH v2 6/7] drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back
Date: Tue, 31 Oct 2023 18:21:43 +0200 [thread overview]
Message-ID: <ZUEplxH51geCyHdb@smile.fi.intel.com> (raw)
In-Reply-To: <b489675d-e9de-4bca-9622-78545aa8606d@redhat.com>
On Tue, Oct 31, 2023 at 05:07:39PM +0100, Hans de Goede wrote:
> On 10/24/23 18:11, Andy Shevchenko wrote:
> > On Tue, Oct 24, 2023 at 06:57:38PM +0300, Andy Shevchenko wrote:
> >> It's a dirty hack in the driver that pokes GPIO registers behind
> >> the driver's back. Moreoever it might be problematic as simultaneous
> >> I/O may hang the system, see the commit 0bd50d719b00 ("pinctrl:
> >> cherryview: prevent concurrent access to GPIO controllers") for
> >> the details. Taking all this into consideration replace the hack
> >> with proper GPIO APIs being used.
> >
> > Ah, just realised that this won't work if it happens to request to GPIOs with
> > the same index but different communities. I will fix that in v3, but will wait
> > for Hans to test VLV and it might even work in most of the cases on CHV as it
> > seems quite unlikely that the above mentioned assertion is going to happen in
> > real life.
>
> I have added patches 1-5 to my personal tree + a small debug patch on top
> which logs when soc_exec_opaque_gpio() actually gets called.
>
> So these patches will now get run every time I run some tests on
> one my tablets.
>
> I'll get back to you with testing results when I've found a device where
> the new soc_exec_opaque_gpio() actually gets called.
Thank you!
> As for the CHT support, I have not added that to my tree yet, I would
> prefer to directly test the correct/fixed patch.
Noted, I'll prepare a new version then.
--
With Best Regards,
Andy Shevchenko
WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Jani Nikula <jani.nikula@intel.com>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org,
Jani Nikula <jani.nikula@linux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH v2 6/7] drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back
Date: Tue, 31 Oct 2023 18:21:43 +0200 [thread overview]
Message-ID: <ZUEplxH51geCyHdb@smile.fi.intel.com> (raw)
In-Reply-To: <b489675d-e9de-4bca-9622-78545aa8606d@redhat.com>
On Tue, Oct 31, 2023 at 05:07:39PM +0100, Hans de Goede wrote:
> On 10/24/23 18:11, Andy Shevchenko wrote:
> > On Tue, Oct 24, 2023 at 06:57:38PM +0300, Andy Shevchenko wrote:
> >> It's a dirty hack in the driver that pokes GPIO registers behind
> >> the driver's back. Moreoever it might be problematic as simultaneous
> >> I/O may hang the system, see the commit 0bd50d719b00 ("pinctrl:
> >> cherryview: prevent concurrent access to GPIO controllers") for
> >> the details. Taking all this into consideration replace the hack
> >> with proper GPIO APIs being used.
> >
> > Ah, just realised that this won't work if it happens to request to GPIOs with
> > the same index but different communities. I will fix that in v3, but will wait
> > for Hans to test VLV and it might even work in most of the cases on CHV as it
> > seems quite unlikely that the above mentioned assertion is going to happen in
> > real life.
>
> I have added patches 1-5 to my personal tree + a small debug patch on top
> which logs when soc_exec_opaque_gpio() actually gets called.
>
> So these patches will now get run every time I run some tests on
> one my tablets.
>
> I'll get back to you with testing results when I've found a device where
> the new soc_exec_opaque_gpio() actually gets called.
Thank you!
> As for the CHT support, I have not added that to my tree yet, I would
> prefer to directly test the correct/fixed patch.
Noted, I'll prepare a new version then.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2023-10-31 16:23 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-24 15:57 [Intel-gfx] [rft, PATCH v2 0/7] drm/i915/dsi: 2nd attempt to get rid of IOSF GPIO Andy Shevchenko
2023-10-24 15:57 ` Andy Shevchenko
2023-10-24 15:57 ` Andy Shevchenko
2023-10-24 15:57 ` [Intel-gfx] [PATCH v2 1/7] drm/i915/dsi: Replace while(1) with one with clear exit condition Andy Shevchenko
2023-10-24 15:57 ` Andy Shevchenko
2023-10-24 15:57 ` Andy Shevchenko
2023-10-25 9:15 ` [Intel-gfx] " Andi Shyti
2023-10-25 9:15 ` Andi Shyti
2023-10-25 9:15 ` Andi Shyti
2023-10-24 15:57 ` [Intel-gfx] [PATCH v2 2/7] drm/i915/dsi: Get rid of redundant 'else' Andy Shevchenko
2023-10-24 15:57 ` Andy Shevchenko
2023-10-24 15:57 ` Andy Shevchenko
2023-10-25 9:18 ` [Intel-gfx] " Andi Shyti
2023-10-25 9:18 ` Andi Shyti
2023-10-25 9:18 ` Andi Shyti
2023-10-24 15:57 ` [Intel-gfx] [PATCH v2 3/7] drm/i915/dsi: Replace check with a (missing) MIPI sequence name Andy Shevchenko
2023-10-24 15:57 ` Andy Shevchenko
2023-10-24 15:57 ` Andy Shevchenko
2023-10-25 9:24 ` [Intel-gfx] " Andi Shyti
2023-10-25 9:24 ` Andi Shyti
2023-10-25 9:24 ` Andi Shyti
2023-10-24 15:57 ` [Intel-gfx] [PATCH v2 4/7] drm/i915/dsi: Extract common soc_gpio_exec() helper Andy Shevchenko
2023-10-24 15:57 ` Andy Shevchenko
2023-10-24 15:57 ` Andy Shevchenko
2023-10-24 15:57 ` [Intel-gfx] [PATCH v2 5/7] drm/i915/dsi: Replace poking of VLV GPIOs behind the driver's back Andy Shevchenko
2023-10-24 15:57 ` Andy Shevchenko
2023-10-24 15:57 ` Andy Shevchenko
2023-10-24 15:57 ` [Intel-gfx] [PATCH v2 6/7] drm/i915/dsi: Replace poking of CHV " Andy Shevchenko
2023-10-24 15:57 ` Andy Shevchenko
2023-10-24 15:57 ` Andy Shevchenko
2023-10-24 16:11 ` [Intel-gfx] " Andy Shevchenko
2023-10-24 16:11 ` Andy Shevchenko
2023-10-24 16:11 ` Andy Shevchenko
2023-10-31 16:07 ` [Intel-gfx] " Hans de Goede
2023-10-31 16:07 ` Hans de Goede
2023-10-31 16:07 ` Hans de Goede
2023-10-31 16:21 ` Andy Shevchenko [this message]
2023-10-31 16:21 ` Andy Shevchenko
2023-10-31 16:21 ` Andy Shevchenko
2023-10-31 21:15 ` [Intel-gfx] " Hans de Goede
2023-10-31 21:15 ` Hans de Goede
2023-10-31 21:15 ` Hans de Goede
2023-11-01 9:32 ` [Intel-gfx] " Andy Shevchenko
2023-11-01 9:32 ` Andy Shevchenko
2023-11-01 9:32 ` Andy Shevchenko
2023-11-01 10:20 ` [Intel-gfx] " Hans de Goede
2023-11-01 10:20 ` Hans de Goede
2023-11-01 10:20 ` Hans de Goede
2023-11-01 10:34 ` [Intel-gfx] " Ville Syrjälä
2023-11-01 10:34 ` Ville Syrjälä
2023-11-01 10:34 ` Ville Syrjälä
2023-11-01 10:40 ` Hans de Goede
2023-11-01 10:40 ` Hans de Goede
2023-11-01 10:40 ` Hans de Goede
2023-11-01 11:01 ` Hans de Goede
2023-11-01 11:01 ` Hans de Goede
2023-11-01 11:01 ` Hans de Goede
2023-11-02 12:27 ` [Intel-gfx] " Andy Shevchenko
2023-11-02 12:27 ` Andy Shevchenko
2023-11-02 12:27 ` Andy Shevchenko
2023-11-02 14:19 ` [Intel-gfx] " Andy Shevchenko
2023-11-02 14:19 ` Andy Shevchenko
2023-11-02 14:19 ` Andy Shevchenko
2023-11-02 14:28 ` [Intel-gfx] " Hans de Goede
2023-11-02 14:28 ` Hans de Goede
2023-11-02 14:28 ` Hans de Goede
2023-10-24 15:57 ` [Intel-gfx] [PATCH v2 7/7] drm/i915/iosf: Drop unused APIs Andy Shevchenko
2023-10-24 15:57 ` Andy Shevchenko
2023-10-24 15:57 ` Andy Shevchenko
2023-10-25 1:46 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsi: 2nd attempt to get rid of IOSF GPIO Patchwork
2023-10-25 16:42 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2023-10-31 23:37 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/dsi: 2nd attempt to get rid of IOSF GPIO (rev2) Patchwork
2023-11-01 13:29 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/dsi: 2nd attempt to get rid of IOSF GPIO (rev4) Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZUEplxH51geCyHdb@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=airlied@gmail.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=hdegoede@redhat.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rodrigo.vivi@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.