All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Benjamin Berg <bberg@redhat.com>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/7] usb: typec: ucsi: Polling the alt modes and PDOs
Date: Thu, 10 Jun 2021 15:07:35 +0300	[thread overview]
Message-ID: <YMIAh1uDgeglJYNN@kuha.fi.intel.com> (raw)
In-Reply-To: <0bf4d8fc6d64ac553a319b8c5af49a3d7705842d.camel@redhat.com>

On Wed, Jun 09, 2021 at 07:39:41PM +0200, Benjamin Berg wrote:
> My thought when I first ran into the issue was that the PPM simply
> resets the change bitfield on ACK, effectively discarding any changes
> that happened after the last GET_CONNECTOR_STATUS call. I believed to
> have confirmed this by inserting an msleep in between.
> However, I have to admit that I have never really looked for
> alternative explanations.

Thanks a lot for testing these. I now have pretty good idea about the
problem. The problem is not what you though it is, but the driver is
also not too slow like I suspected.

I'm quite certain now that the PPM simply does not create the event at
all in this case, regardless of what the driver does. We do need to
workaround that problem, but I think we can do it in a better way. I
have an idea for that.

thanks,

-- 
heikki

      reply	other threads:[~2021-06-10 12:07 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-07 13:14 [RFC PATCH 0/7] usb: typec: ucsi: Polling the alt modes and PDOs Heikki Krogerus
2021-06-07 13:14 ` [RFC PATCH 1/7] usb: typec: ucsi: Always cancel the command if PPM reports BUSY condition Heikki Krogerus
2021-06-07 13:14 ` [RFC PATCH 2/7] usb: typec: ucsi: Don't stop alt mode registration on busy condition Heikki Krogerus
2021-06-08  9:31   ` Sergei Shtylyov
2021-06-08 13:18     ` Heikki Krogerus
2021-06-07 13:14 ` [RFC PATCH 3/7] usb: typec: ucsi: Add poll worker for alternate modes Heikki Krogerus
2021-06-07 13:14 ` [RFC PATCH 4/7] usb: typec: ucsi: acpi: Reduce the command completion timeout Heikki Krogerus
2021-06-07 13:14 ` [RFC PATCH 5/7] usb: typec: ucsi: Process every connector change as unique connector state Heikki Krogerus
2021-06-07 13:14 ` [RFC PATCH 6/7] usb: typec: ucsi: Filter out spurious events Heikki Krogerus
2021-06-07 13:14 ` [RFC PATCH 7/7] usb: typec: ucsi: Read the PDOs in separate work Heikki Krogerus
2021-06-07 20:09 ` [RFC PATCH 0/7] usb: typec: ucsi: Polling the alt modes and PDOs Benjamin Berg
2021-06-08  6:42   ` Heikki Krogerus
2021-06-08  6:54     ` Heikki Krogerus
2021-06-08 19:32       ` Benjamin Berg
2021-06-09 11:25         ` Heikki Krogerus
2021-06-09 12:18           ` Heikki Krogerus
2021-06-09 12:56             ` Heikki Krogerus
2021-06-09 17:39               ` Benjamin Berg
2021-06-10 12:07                 ` Heikki Krogerus [this message]

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=YMIAh1uDgeglJYNN@kuha.fi.intel.com \
    --to=heikki.krogerus@linux.intel.com \
    --cc=bberg@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /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.