Re: [Intel-gfx] [PATCH 13/19] arch/riscv: rename internal name __xchg to __arch_xchg
On Thu, 22 Dec 2022 03:46:29 PST (-0800), andrzej.ha...@intel.com wrote:
__xchg will be used for non-atomic xchg macro.
Signed-off-by: Andrzej Hajda
---
arch/riscv/include/asm/atomic.h | 2 +-
arch/riscv/include/asm/cmpxchg.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/include/asm/atomic.h b/arch/riscv/include/asm/atomic.h
index 0dfe9d857a762b..bba472928b5393 100644
--- a/arch/riscv/include/asm/atomic.h
+++ b/arch/riscv/include/asm/atomic.h
@@ -261,7 +261,7 @@ c_t arch_atomic##prefix##_xchg_release(atomic##prefix##_t
*v, c_t n)\
static __always_inline \
c_t arch_atomic##prefix##_xchg(atomic##prefix##_t *v, c_t n) \
{ \
- return __xchg(&(v->counter), n, size); \
+ return __arch_xchg(&(v->counter), n, size); \
} \
static __always_inline \
c_t arch_atomic##prefix##_cmpxchg_relaxed(atomic##prefix##_t *v, \
diff --git a/arch/riscv/include/asm/cmpxchg.h b/arch/riscv/include/asm/cmpxchg.h
index 12debce235e52d..2f4726d3cfcc25 100644
--- a/arch/riscv/include/asm/cmpxchg.h
+++ b/arch/riscv/include/asm/cmpxchg.h
@@ -114,7 +114,7 @@
_x_, sizeof(*(ptr))); \
})
-#define __xchg(ptr, new, size) \
+#define __arch_xchg(ptr, new, size)\
({ \
__typeof__(ptr) __ptr = (ptr); \
__typeof__(new) __new = (new); \
@@ -143,7 +143,7 @@
#define arch_xchg(ptr, x) \
({ \
__typeof__(*(ptr)) _x_ = (x); \
- (__typeof__(*(ptr))) __xchg((ptr), _x_, sizeof(*(ptr)));\
+ (__typeof__(*(ptr))) __arch_xchg((ptr), _x_, sizeof(*(ptr))); \
})
#define xchg32(ptr, x) \
Acked-by: Palmer Dabbelt
Re: [Intel-gfx] [PATCH 13/19] arch/riscv: rename internal name __xchg to __arch_xchg
On Thu, 22 Dec 2022 03:46:29 PST (-0800), andrzej.ha...@intel.com wrote:
__xchg will be used for non-atomic xchg macro.
Signed-off-by: Andrzej Hajda
---
arch/riscv/include/asm/atomic.h | 2 +-
arch/riscv/include/asm/cmpxchg.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/include/asm/atomic.h b/arch/riscv/include/asm/atomic.h
index 0dfe9d857a762b..bba472928b5393 100644
--- a/arch/riscv/include/asm/atomic.h
+++ b/arch/riscv/include/asm/atomic.h
@@ -261,7 +261,7 @@ c_t arch_atomic##prefix##_xchg_release(atomic##prefix##_t
*v, c_t n)\
static __always_inline \
c_t arch_atomic##prefix##_xchg(atomic##prefix##_t *v, c_t n) \
{ \
- return __xchg(&(v->counter), n, size); \
+ return __arch_xchg(&(v->counter), n, size); \
} \
static __always_inline \
c_t arch_atomic##prefix##_cmpxchg_relaxed(atomic##prefix##_t *v, \
diff --git a/arch/riscv/include/asm/cmpxchg.h b/arch/riscv/include/asm/cmpxchg.h
index 12debce235e52d..2f4726d3cfcc25 100644
--- a/arch/riscv/include/asm/cmpxchg.h
+++ b/arch/riscv/include/asm/cmpxchg.h
@@ -114,7 +114,7 @@
_x_, sizeof(*(ptr))); \
})
-#define __xchg(ptr, new, size) \
+#define __arch_xchg(ptr, new, size)\
({ \
__typeof__(ptr) __ptr = (ptr); \
__typeof__(new) __new = (new); \
@@ -143,7 +143,7 @@
#define arch_xchg(ptr, x) \
({ \
__typeof__(*(ptr)) _x_ = (x); \
- (__typeof__(*(ptr))) __xchg((ptr), _x_, sizeof(*(ptr)));\
+ (__typeof__(*(ptr))) __arch_xchg((ptr), _x_, sizeof(*(ptr))); \
})
#define xchg32(ptr, x) \
Acked-by: Palmer Dabbelt
Thanks!
Re: [Intel-gfx] [PATCH] drm/i915: Perform link quality check unconditionally during long pulse
On Thu, Feb 16, 2017 at 9:46 AM, Ville Syrjälä
<ville.syrj...@linux.intel.com> wrote:
> On Thu, Feb 16, 2017 at 09:24:09AM -0800, Manasi Navare wrote:
>> On Thu, Feb 16, 2017 at 07:18:57PM +0200, Ville Syrjälä wrote:
>> > On Thu, Feb 16, 2017 at 09:07:53AM -0800, Manasi Navare wrote:
>> > > On Thu, Feb 16, 2017 at 05:30:07PM +0200, ville.syrj...@linux.intel.com
>> > > wrote:
>> > > > From: Ville Syrjälä <ville.syrj...@linux.intel.com>
>> > > >
>> > > > Apparently some DP sinks are a little nuts and cause HPD to drop
>> > > > intermittently during modesets. This happens eg. on an ASUS PB287Q.
>> > > > In oder to recover from this we can't really use the previous
>> > > > connector status to determine if the link needs retraining, so let's
>> > > > just ignore that piece of information and do the retrain
>> > > > unconditionally. We do of course still check whether the link is
>> > > > supposed to be running or not.
>> > > >
>> > > > Cc: sta...@vger.kernel.org
>> > > > Cc: Palmer Dabbelt <pal...@dabbelt.com>
>> > > > Reported-by: Palmer Dabbelt <pal...@dabbelt.com>
>> > > > References:
>> > > > https://lists.freedesktop.org/archives/intel-gfx/2017-February/119779.html
>> > > > Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
>> > > > ---
>> > > > drivers/gpu/drm/i915/intel_dp.c | 15 +++
>> > > > 1 file changed, 11 insertions(+), 4 deletions(-)
>> > > >
>> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> > > > b/drivers/gpu/drm/i915/intel_dp.c
>> > > > index 024798a9c016..37a746f7fbc3 100644
>> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
>> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
>> > > > @@ -4648,11 +4648,18 @@ intel_dp_long_pulse(struct intel_connector
>> > > > *intel_connector)
>> > > > */
>> > > > status = connector_status_disconnected;
>> > > > goto out;
>> > > > - } else if (connector->status == connector_status_connected) {
>> > > > + } else {
>> > > > /*
>> > > > -* If display was connected already and is still
>> > > > connected
>> > > > -* check links status, there has been known issues of
>> > > > -* link loss triggerring long pulse
>> > > > +* If display is now connected check links status,
>> > > > +* there has been known issues of link loss triggerring
>> > > > +* long pulse.
>> > > > +*
>> > > > +* Some sinks (eg. ASUS PB287Q) seem to perform some
>> > > > +* weird HPD ping pong during modesets. So we can
>> > > > apparely
>> > > > +* end up with HPD going low during a modeset, and then
>> > > > +* going back up soon after. And once that happens we
>> > > > must
>> > > > +* retrain the link to get a picture. That's in case no
>> > > > +* userspace component reacted to intermittent HPD dip.
>> > > > */
>> > > > drm_modeset_lock(>mode_config.connection_mutex,
>> > > > NULL);
>> > > > intel_dp_check_link_status(intel_dp);
>> > > > --
>> > >
>> > > So here we basically just ignore the connector status and retrain
>> > > irrespectively.
>> >
>> > We ignore the _previous_ connector status.
>> >
>> > > But that means even if we have newer values now for max link rate/lane
>> > > count from
>> > > DPCD, during this retrain we are just using the stale value of
>> > > intel_dp->link_rate
>> > > and intel_dp->lane_count. I think intel_dp->link_rate and lane count
>> > > values
>> > > should be set to 0 on HPD pulse, they would be set only during a modeset.
>> >
>> > The DPCD has already been parsed by this time.
>> >
>> > --
>> > Ville Syrjälä
>> > Intel OTC
>>
>> Yes, we have parsed the DPCD but we dont write to intel_dp->link-rate and
>> intel_dp->lane_count
>> until we do a modeset (these get written during pre_enable) and these values
>> get used
>> during the retraining of the link. So at this point we will still use stale
>> values.
>
> They're not stale. They're exactly what we used when we set up the
> mode that's still being drive out. This is just retraining the link
> at the same parameters.
>
>> Shouldnt we set the link status to BAD and send a hotplug event, like the
>> solution we implemneted
>> for retraining?
>>
>> Regards
>> Manasi
>>
>> Regards
>> Manasi
>
> --
> Ville Syrjälä
> Intel OTC
Sorry, I forgot about this. A log is attached of my machine booting
with the monitor attached, me detaching the monitor, and then plugging
it back in.
log.gz
Description: GNU Zip compressed data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Perform link quality check unconditionally during long pulse
On Thu, 16 Feb 2017 07:30:07 PST (-0800), ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
>
> Apparently some DP sinks are a little nuts and cause HPD to drop
> intermittently during modesets. This happens eg. on an ASUS PB287Q.
> In oder to recover from this we can't really use the previous
> connector status to determine if the link needs retraining, so let's
> just ignore that piece of information and do the retrain
> unconditionally. We do of course still check whether the link is
> supposed to be running or not.
With this patch on top of linux-4.9 I have DPMS on/off working again, but I
don't have the correct resolutions on my monitor. I just see
DP1 connected 1024x768+2880+0 (normal left inverted right x axis y axis) 0mm x
0mm
1024x768 60.00*
800x600 60.3256.25
848x480 60.00
640x480 59.94
>
> Cc: sta...@vger.kernel.org
> Cc: Palmer Dabbelt <pal...@dabbelt.com>
> Reported-by: Palmer Dabbelt <pal...@dabbelt.com>
> References:
> https://lists.freedesktop.org/archives/intel-gfx/2017-February/119779.html
> Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
> ---
> drivers/gpu/drm/i915/intel_dp.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 024798a9c016..37a746f7fbc3 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4648,11 +4648,18 @@ intel_dp_long_pulse(struct intel_connector
> *intel_connector)
>*/
> status = connector_status_disconnected;
> goto out;
> - } else if (connector->status == connector_status_connected) {
> + } else {
> /*
> - * If display was connected already and is still connected
> - * check links status, there has been known issues of
> - * link loss triggerring long pulse
> + * If display is now connected check links status,
> + * there has been known issues of link loss triggerring
> + * long pulse.
> + *
> + * Some sinks (eg. ASUS PB287Q) seem to perform some
> + * weird HPD ping pong during modesets. So we can apparely
> + * end up with HPD going low during a modeset, and then
> + * going back up soon after. And once that happens we must
> + * retrain the link to get a picture. That's in case no
> + * userspace component reacted to intermittent HPD dip.
>*/
> drm_modeset_lock(>mode_config.connection_mutex, NULL);
> intel_dp_check_link_status(intel_dp);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix DisplayPort Hotplug
On Tue, Feb 14, 2017 at 11:00 AM, Ville Syrjälä
<ville.syrj...@linux.intel.com> wrote:
> On Tue, Feb 14, 2017 at 10:48:10AM -0800, Palmer Dabbelt wrote:
>> On Tue, 14 Feb 2017 07:01:54 PST (-0800), ville.syrj...@linux.intel.com
>> wrote:
>> > On Fri, Feb 10, 2017 at 02:44:20PM -0800, Palmer Dabbelt wrote:
>> >> DisplayPort no longer hotplugs on my machine (a 2014 MacBook Pro
>> >> attached to an ASUS PB287Q). I believe the problem is that long pulses
>> >> are no longer triggering intel_dp_check_link_status.
>> >
>> > That shouldn't itsefl cause problems with hotplugs. It could cause
>> > problems if you hotplug displays without a proper randr client running
>> > in which case the link is left running when you unplug the displays and
>> > then gets retrained when you plug a display back in.
>>
>> Maybe it's a problem with my setup, as I don't think I have any randr client
>> running: I just run xrandr via my xinitrc and via some scripts linked from
>> udev
>> for DRM hotplug events for when I move the laptop around.
>
> That should more or less work. Well, depends on what you do in your
> udev scripts. But that's pretty much what your typical xrandr clients
> do, except the udev event gets first converted into a randr event by the
> X server.
>
>> Is it required that
>> I have more stuff running in order to make DPMS events work?
>
> Not sure what you mean by DPMS events. "xset dpms" just turns things
> on/off, there are no events involved really.
I guess my "dpms event" I meant "the monitor going on and off".
>> IIRC my setup has
>> looked like this for years now, but if it's broken because it's wacky then I
>> can change it.
>>
>> Regardless, I think something is still broken here. I don't need to actaully
>> unplug anything for this to break, if I just run "xset dpms force off" to
>> turn
>> the screen off and then wake it back up my eDP laptop display comes back fine
>> but my DP monitor doesn't.
>
> That is definitely a bug somewhere. Can you boot your machine with
> drm.debug=0xe passed to the kernel, then reproduce this dpms problem,
> and then post the full dmesg. Maybe the log will show something
> interesting.
Attached. There's two copies: one from after I boot and start X, and
the second from after I do a DPMS cycle:
$ xset dpms force off
$ sleep 10s # wait for the monitor to go to sleep
# press ctrl to wake the monitor back up
One item of interest: when I ran this on my work monitor (a newer Dell
DisplayPort monitor) I didn't have any DPMS problems, but when I ran
it on my ASUS PB287Q the monitor doesn't come back from sleep.
>> I'd expect eDP and DP to behave the same here.
>> IIRC the link doesn't come back up even if I twiddle some xrandr stuff, but I
>> might getting this confused with the previous similar bug. If you want I can
>> boot back into the broken kernel and run some experiments, but it'd be great
>> if
>> you could suggest some for me.
>>
>> > That doesn't explain why intel_dp_check_link_status() wouldn't get
>> > called though. It should be called via intel_dp_detect() ->
>> > intel_dp_long_pulse().
>>
>> Sorry, I don't actually know anything about DRM so I'm not sure what's going
>> on. I just generated this patch by looking at the bug from last time my DP
>> monitor stopped working, looking at the last few things that touched that
>> function, and then adding back in the thing that looks like it would make
>> link
>> detection work again :).
>
> Well, it should already work. Somehting is hinky.
>
>>
>> The last time I did this I got it wrong as well -- looking at
>> <https://bugs.freedesktop.org/show_bug.cgi?id=89453> I see that I suggested
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index d714a4b5711e..274bd293d9e9 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -4625,7 +4625,9 @@ static const struct drm_encoder_funcs
>> intel_dp_enc_funcs = {
>>void
>>intel_dp_hot_plug(struct intel_encoder *intel_encoder)
>>{
>> - return;
>> + struct intel_dp *intel_dp = enc_to_intel_dp(_encoder->base);
>> +
>> + intel_dp_check_link_status(intel_dp);
>>}
>>
>> enum irqreturn
>>
>> but the correct solution (d14e7b6d1 "drm/i915: Check DP link status on long
>> hpd
>> too") was very different
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.
Re: [Intel-gfx] [PATCH] drm/i915: Fix DisplayPort Hotplug
On Tue, 14 Feb 2017 07:01:54 PST (-0800), ville.syrj...@linux.intel.com wrote:
> On Fri, Feb 10, 2017 at 02:44:20PM -0800, Palmer Dabbelt wrote:
>> DisplayPort no longer hotplugs on my machine (a 2014 MacBook Pro
>> attached to an ASUS PB287Q). I believe the problem is that long pulses
>> are no longer triggering intel_dp_check_link_status.
>
> That shouldn't itsefl cause problems with hotplugs. It could cause
> problems if you hotplug displays without a proper randr client running
> in which case the link is left running when you unplug the displays and
> then gets retrained when you plug a display back in.
Maybe it's a problem with my setup, as I don't think I have any randr client
running: I just run xrandr via my xinitrc and via some scripts linked from udev
for DRM hotplug events for when I move the laptop around. Is it required that
I have more stuff running in order to make DPMS events work? IIRC my setup has
looked like this for years now, but if it's broken because it's wacky then I
can change it.
Regardless, I think something is still broken here. I don't need to actaully
unplug anything for this to break, if I just run "xset dpms force off" to turn
the screen off and then wake it back up my eDP laptop display comes back fine
but my DP monitor doesn't. I'd expect eDP and DP to behave the same here.
IIRC the link doesn't come back up even if I twiddle some xrandr stuff, but I
might getting this confused with the previous similar bug. If you want I can
boot back into the broken kernel and run some experiments, but it'd be great if
you could suggest some for me.
> That doesn't explain why intel_dp_check_link_status() wouldn't get
> called though. It should be called via intel_dp_detect() ->
> intel_dp_long_pulse().
Sorry, I don't actually know anything about DRM so I'm not sure what's going
on. I just generated this patch by looking at the bug from last time my DP
monitor stopped working, looking at the last few things that touched that
function, and then adding back in the thing that looks like it would make link
detection work again :).
The last time I did this I got it wrong as well -- looking at
<https://bugs.freedesktop.org/show_bug.cgi?id=89453> I see that I suggested
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d714a4b5711e..274bd293d9e9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4625,7 +4625,9 @@ static const struct drm_encoder_funcs
intel_dp_enc_funcs = {
void
intel_dp_hot_plug(struct intel_encoder *intel_encoder)
{
- return;
+ struct intel_dp *intel_dp = enc_to_intel_dp(_encoder->base);
+
+ intel_dp_check_link_status(intel_dp);
}
enum irqreturn
but the correct solution (d14e7b6d1 "drm/i915: Check DP link status on long hpd
too") was very different
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3781cd3..94686cb 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4961,9 +4961,12 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
intel_dp_probe_oui(intel_dp);
- if (!intel_dp_probe_mst(intel_dp))
+ if (!intel_dp_probe_mst(intel_dp)) {
+ drm_modeset_lock(>mode_config.connection_mutex,
NULL);
+ intel_dp_check_link_status(intel_dp);
+
drm_modeset_unlock(>mode_config.connection_mutex);
goto mst_fail;
-
+ }
my fix for this new bug (which might just be another workaround) was copied
from the correct fix from last time.
>
>> I bisected the
>> problem down to (7d23e3c37 "drm/i915: Cleaning up intel_dp_hpd_pulse")
>> and it appears the only material change there was to remove one of those
>> calls.
>>
>> This commit adds the check_link_status call back in, which causes hotplug to
>> work again for me. I test this via a "xset dpms force off". Note that this
>> is
>> very similar to <https://bugs.freedesktop.org/show_bug.cgi?id=89453>, but
>> it's
>> back again.
>>
>> I've tested this against 4.9, and it applies against the current head.
>>
>> See <https://bugs.freedesktop.org/show_bug.cgi?id=99766>.
>>
>> Here's the commit that triggered the regression:
>>
>> commit 7d23e3c37bb3fc6952dc84007ee60cb533fd2d5c
>> Author: Shubhangi Shrivastava <shubhangi.shrivast...@intel.com>
>> Date: Wed Mar 30 18:05:23 2016 +0530
>>
>> drm/i915: Cleaning up intel_dp_hpd_pulse
>>
>> Current DP detection has DPCD operations split across
>> intel_dp_hpd_pulse and intel_dp_detect which contains
>&
[Intel-gfx] [PATCH] drm/i915: Fix DisplayPort Hotplug
DisplayPort no longer hotplugs on my machine (a 2014 MacBook Pro
attached to an ASUS PB287Q). I believe the problem is that long pulses
are no longer triggering intel_dp_check_link_status. I bisected the
problem down to (7d23e3c37 "drm/i915: Cleaning up intel_dp_hpd_pulse")
and it appears the only material change there was to remove one of those
calls.
This commit adds the check_link_status call back in, which causes hotplug to
work again for me. I test this via a "xset dpms force off". Note that this is
very similar to <https://bugs.freedesktop.org/show_bug.cgi?id=89453>, but it's
back again.
I've tested this against 4.9, and it applies against the current head.
See <https://bugs.freedesktop.org/show_bug.cgi?id=99766>.
Here's the commit that triggered the regression:
commit 7d23e3c37bb3fc6952dc84007ee60cb533fd2d5c
Author: Shubhangi Shrivastava <shubhangi.shrivast...@intel.com>
Date: Wed Mar 30 18:05:23 2016 +0530
drm/i915: Cleaning up intel_dp_hpd_pulse
Current DP detection has DPCD operations split across
intel_dp_hpd_pulse and intel_dp_detect which contains
duplicates as well. Also intel_dp_detect is called
during modes enumeration as well which will result
in multiple dpcd operations. So this patch tries
to solve both these by bringing all DPCD operations
in one single function and make intel_dp_detect
use existing values instead of repeating same steps.
Signed-off-by: Palmer Dabbelt <pal...@dabbelt.com>
---
drivers/gpu/drm/i915/intel_dp.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0b8e8eb..32ca4be 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4831,6 +4831,10 @@ intel_dp_hpd_pulse(struct intel_digital_port
*intel_dig_port, bool long_hpd)
long_hpd ? "long" : "short");
if (long_hpd) {
+ drm_modeset_lock(>mode_config.connection_mutex, NULL);
+ intel_dp_check_link_status(intel_dp);
+ drm_modeset_unlock(>mode_config.connection_mutex);
+
intel_dp->detect_done = false;
return IRQ_NONE;
}
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
