Re: [PATCH v2] usb: typec: tcpm: Migrate workqueue to RT priority for processing events

2020-07-30 Thread Guenter Roeck 
On 7/29/20 8:37 PM, Badhri Jagan Sridharan wrote:
> Hi Guenter,
> 
> I see that Hans is saying that he has submitted some patch here.
> https://lore.kernel.org/lkml/65f27abc-69c8-3877-be5b-e5e478153...@redhat.com/
> But, haven't found the actual patches yet !
> 

https://patchwork.kernel.org/project/linux-usb/list/?series=318719

Guenter

> Thanks,
> Badhri
> 
> On Wed, Jul 29, 2020 at 8:03 PM Guenter Roeck  wrote:
>>
>> On 7/29/20 7:28 PM, Badhri Jagan Sridharan wrote:
>>> Hi Greg,
>>>
>>> Sure just sent the new patch v3.
>>>
>>> Patch applies cleanly on my end. So wondering what I am missing.
>>
>> I expected your patch to conflict with Hans' patch series.
>> Maybe those are in a different tree/branch ?
>>
>> Guenter
>>
>>> Just in case if you are still noticing merge conflicts.
>>>
>>> Here is the git log of my local tree:
>>> 633198cd2945b7 (HEAD -> usb-next-1) usb: typec: tcpm: Migrate workqueue to 
>>> RT priority for processing events
>>> fa56dd9152ef95 (origin/usb-next) Merge tag 'usb-serial-5.9-rc1' of 
>>> https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into 
>>> usb-next
>>> 25252919a1050e xhci: dbgtty: Make some functions static
>>> b0e02550346e67 xhci: dbc: Make function xhci_dbc_ring_alloc() static
>>> ca6377900974c3 Revert "usb: dwc2: override PHY input signals with usb role 
>>> switch support"
>>> 09df709cb5aeb2 Revert "usb: dwc2: don't use ID/Vbus detection if 
>>> usb-role-switch on STM32MP15 SoCs"
>>> 17a82716587e9d USB: iowarrior: fix up report size handling for some devices
>>> e98ba8cc3f8a89 Merge tag 'usb-for-v5.9' of 
>>> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb 
>>>  into usb-next
>>> c97793089b11f7 Merge 5.8-rc7 into usb-next
>>> 92ed301919932f (tag: v5.8-rc7, origin/usb-linus, origin/main) Linux 5.8-rc7
>>>
>>> Was comparing against 
>>> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/log/?h=usb-next
>>>
>>> Thanks,
>>> Badhri
>>>
>>> On Wed, Jul 29, 2020 at 7:53 AM Greg Kroah-Hartman 
>>> mailto:gre...@linuxfoundation.org>> wrote:
>>>
>>> On Thu, Jul 23, 2020 at 07:05:51PM -0700, Badhri Jagan Sridharan wrote:
>>> > "tReceiverResponse 15 ms Section 6.6.2
>>> > The receiver of a Message requiring a response Shall respond
>>> > within tReceiverResponse in order to ensure that the
>>> > sender’s SenderResponseTimer does not expire."
>>> >
>>> > When the cpu complex is busy running other lower priority
>>> > work items, TCPM's work queue sometimes does not get scheduled
>>> > on time to meet the above requirement from the spec.
>>> > Moving to kthread_work apis to run with real time priority.
>>> > Just lower than the default threaded irq priority,
>>> > MAX_USER_RT_PRIO/2 + 1. (Higher number implies lower priority).
>>> >
>>> > Further, as observed in 1ff688209e2e, moving to hrtimers to
>>> > overcome scheduling latency while scheduling the delayed work.
>>> >
>>> > TCPM has three work streams:
>>> > 1. tcpm_state_machine
>>> > 2. vdm_state_machine
>>> > 3. event_work
>>> >
>>> > tcpm_state_machine and vdm_state_machine both schedule work in
>>> > future i.e. delayed. Hence each of them have a corresponding
>>> > hrtimer, tcpm_state_machine_timer & vdm_state_machine_timer.
>>> >
>>> > When work is queued right away kthread_queue_work is used.
>>> > Else, the relevant timer is programmed and made to queue
>>> > the kthread_work upon timer expiry.
>>> >
>>> > kthread_create_worker only creates one kthread worker thread,
>>> > hence single threadedness of workqueue is retained.
>>> >
>>> > Signed-off-by: Badhri Jagan Sridharan >> >
>>>
>>> This doesn't apply against my usb-next branch at all.
>>>
>>> Can you rebase and resend?
>>>
>>> Remember to collect the reviewed-by tags as well when you do so.
>>>
>>> thanks,
>>>
>>> greg k-h
>>>
>>

Re: [PATCH v2] usb: typec: tcpm: Migrate workqueue to RT priority for processing events

2020-07-29 Thread Badhri Jagan Sridharan 
Hi Guenter,

I see that Hans is saying that he has submitted some patch here.
https://lore.kernel.org/lkml/65f27abc-69c8-3877-be5b-e5e478153...@redhat.com/
But, haven't found the actual patches yet !

Thanks,
Badhri

On Wed, Jul 29, 2020 at 8:03 PM Guenter Roeck  wrote:
>
> On 7/29/20 7:28 PM, Badhri Jagan Sridharan wrote:
> > Hi Greg,
> >
> > Sure just sent the new patch v3.
> >
> > Patch applies cleanly on my end. So wondering what I am missing.
>
> I expected your patch to conflict with Hans' patch series.
> Maybe those are in a different tree/branch ?
>
> Guenter
>
> > Just in case if you are still noticing merge conflicts.
> >
> > Here is the git log of my local tree:
> > 633198cd2945b7 (HEAD -> usb-next-1) usb: typec: tcpm: Migrate workqueue to 
> > RT priority for processing events
> > fa56dd9152ef95 (origin/usb-next) Merge tag 'usb-serial-5.9-rc1' of 
> > https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into 
> > usb-next
> > 25252919a1050e xhci: dbgtty: Make some functions static
> > b0e02550346e67 xhci: dbc: Make function xhci_dbc_ring_alloc() static
> > ca6377900974c3 Revert "usb: dwc2: override PHY input signals with usb role 
> > switch support"
> > 09df709cb5aeb2 Revert "usb: dwc2: don't use ID/Vbus detection if 
> > usb-role-switch on STM32MP15 SoCs"
> > 17a82716587e9d USB: iowarrior: fix up report size handling for some devices
> > e98ba8cc3f8a89 Merge tag 'usb-for-v5.9' of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb 
> >  into usb-next
> > c97793089b11f7 Merge 5.8-rc7 into usb-next
> > 92ed301919932f (tag: v5.8-rc7, origin/usb-linus, origin/main) Linux 5.8-rc7
> >
> > Was comparing against 
> > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/log/?h=usb-next
> >
> > Thanks,
> > Badhri
> >
> > On Wed, Jul 29, 2020 at 7:53 AM Greg Kroah-Hartman 
> > mailto:gre...@linuxfoundation.org>> wrote:
> >
> > On Thu, Jul 23, 2020 at 07:05:51PM -0700, Badhri Jagan Sridharan wrote:
> > > "tReceiverResponse 15 ms Section 6.6.2
> > > The receiver of a Message requiring a response Shall respond
> > > within tReceiverResponse in order to ensure that the
> > > sender’s SenderResponseTimer does not expire."
> > >
> > > When the cpu complex is busy running other lower priority
> > > work items, TCPM's work queue sometimes does not get scheduled
> > > on time to meet the above requirement from the spec.
> > > Moving to kthread_work apis to run with real time priority.
> > > Just lower than the default threaded irq priority,
> > > MAX_USER_RT_PRIO/2 + 1. (Higher number implies lower priority).
> > >
> > > Further, as observed in 1ff688209e2e, moving to hrtimers to
> > > overcome scheduling latency while scheduling the delayed work.
> > >
> > > TCPM has three work streams:
> > > 1. tcpm_state_machine
> > > 2. vdm_state_machine
> > > 3. event_work
> > >
> > > tcpm_state_machine and vdm_state_machine both schedule work in
> > > future i.e. delayed. Hence each of them have a corresponding
> > > hrtimer, tcpm_state_machine_timer & vdm_state_machine_timer.
> > >
> > > When work is queued right away kthread_queue_work is used.
> > > Else, the relevant timer is programmed and made to queue
> > > the kthread_work upon timer expiry.
> > >
> > > kthread_create_worker only creates one kthread worker thread,
> > > hence single threadedness of workqueue is retained.
> > >
> > > Signed-off-by: Badhri Jagan Sridharan  > >
> >
> > This doesn't apply against my usb-next branch at all.
> >
> > Can you rebase and resend?
> >
> > Remember to collect the reviewed-by tags as well when you do so.
> >
> > thanks,
> >
> > greg k-h
> >
>

Re: [PATCH v2] usb: typec: tcpm: Migrate workqueue to RT priority for processing events

2020-07-29 Thread Guenter Roeck 
On 7/29/20 7:28 PM, Badhri Jagan Sridharan wrote:
> Hi Greg,
> 
> Sure just sent the new patch v3.
> 
> Patch applies cleanly on my end. So wondering what I am missing.

I expected your patch to conflict with Hans' patch series.
Maybe those are in a different tree/branch ?

Guenter

> Just in case if you are still noticing merge conflicts.
> 
> Here is the git log of my local tree:
> 633198cd2945b7 (HEAD -> usb-next-1) usb: typec: tcpm: Migrate workqueue to RT 
> priority for processing events
> fa56dd9152ef95 (origin/usb-next) Merge tag 'usb-serial-5.9-rc1' of 
> https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next
> 25252919a1050e xhci: dbgtty: Make some functions static
> b0e02550346e67 xhci: dbc: Make function xhci_dbc_ring_alloc() static
> ca6377900974c3 Revert "usb: dwc2: override PHY input signals with usb role 
> switch support"
> 09df709cb5aeb2 Revert "usb: dwc2: don't use ID/Vbus detection if 
> usb-role-switch on STM32MP15 SoCs"
> 17a82716587e9d USB: iowarrior: fix up report size handling for some devices
> e98ba8cc3f8a89 Merge tag 'usb-for-v5.9' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb 
>  into usb-next
> c97793089b11f7 Merge 5.8-rc7 into usb-next
> 92ed301919932f (tag: v5.8-rc7, origin/usb-linus, origin/main) Linux 5.8-rc7
> 
> Was comparing against 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/log/?h=usb-next
> 
> Thanks,
> Badhri
> 
> On Wed, Jul 29, 2020 at 7:53 AM Greg Kroah-Hartman 
> mailto:gre...@linuxfoundation.org>> wrote:
> 
> On Thu, Jul 23, 2020 at 07:05:51PM -0700, Badhri Jagan Sridharan wrote:
> > "tReceiverResponse 15 ms Section 6.6.2
> > The receiver of a Message requiring a response Shall respond
> > within tReceiverResponse in order to ensure that the
> > sender’s SenderResponseTimer does not expire."
> >
> > When the cpu complex is busy running other lower priority
> > work items, TCPM's work queue sometimes does not get scheduled
> > on time to meet the above requirement from the spec.
> > Moving to kthread_work apis to run with real time priority.
> > Just lower than the default threaded irq priority,
> > MAX_USER_RT_PRIO/2 + 1. (Higher number implies lower priority).
> >
> > Further, as observed in 1ff688209e2e, moving to hrtimers to
> > overcome scheduling latency while scheduling the delayed work.
> >
> > TCPM has three work streams:
> > 1. tcpm_state_machine
> > 2. vdm_state_machine
> > 3. event_work
> >
> > tcpm_state_machine and vdm_state_machine both schedule work in
> > future i.e. delayed. Hence each of them have a corresponding
> > hrtimer, tcpm_state_machine_timer & vdm_state_machine_timer.
> >
> > When work is queued right away kthread_queue_work is used.
> > Else, the relevant timer is programmed and made to queue
> > the kthread_work upon timer expiry.
> >
> > kthread_create_worker only creates one kthread worker thread,
> > hence single threadedness of workqueue is retained.
> >
> > Signed-off-by: Badhri Jagan Sridharan  >
> 
> This doesn't apply against my usb-next branch at all.
> 
> Can you rebase and resend?
> 
> Remember to collect the reviewed-by tags as well when you do so.
> 
> thanks,
> 
> greg k-h
>

Re: [PATCH v2] usb: typec: tcpm: Migrate workqueue to RT priority for processing events

2020-07-29 Thread Badhri Jagan Sridharan 
Hi Greg,

Sure just sent the new patch v3.

Patch applies cleanly on my end. So wondering what I am missing.
Just in case if you are still noticing merge conflicts.

Here is the git log of my local tree:
633198cd2945b7 (HEAD -> usb-next-1) usb: typec: tcpm: Migrate
workqueue to RT priority for processing events
fa56dd9152ef95 (origin/usb-next) Merge tag 'usb-serial-5.9-rc1' of
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into
usb-next
25252919a1050e xhci: dbgtty: Make some functions static
b0e02550346e67 xhci: dbc: Make function xhci_dbc_ring_alloc() static
ca6377900974c3 Revert "usb: dwc2: override PHY input signals with usb
role switch support"
09df709cb5aeb2 Revert "usb: dwc2: don't use ID/Vbus detection if
usb-role-switch on STM32MP15 SoCs"
17a82716587e9d USB: iowarrior: fix up report size handling for some devices
e98ba8cc3f8a89 Merge tag 'usb-for-v5.9' of
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next
c97793089b11f7 Merge 5.8-rc7 into usb-next
92ed301919932f (tag: v5.8-rc7, origin/usb-linus, origin/main) Linux 5.8-rc7

Was comparing against
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/log/?h=usb-next

Thanks,
Badhri


On Wed, Jul 29, 2020 at 7:53 AM Greg Kroah-Hartman
 wrote:
>
> On Thu, Jul 23, 2020 at 07:05:51PM -0700, Badhri Jagan Sridharan wrote:
> > "tReceiverResponse 15 ms Section 6.6.2
> > The receiver of a Message requiring a response Shall respond
> > within tReceiverResponse in order to ensure that the
> > sender’s SenderResponseTimer does not expire."
> >
> > When the cpu complex is busy running other lower priority
> > work items, TCPM's work queue sometimes does not get scheduled
> > on time to meet the above requirement from the spec.
> > Moving to kthread_work apis to run with real time priority.
> > Just lower than the default threaded irq priority,
> > MAX_USER_RT_PRIO/2 + 1. (Higher number implies lower priority).
> >
> > Further, as observed in 1ff688209e2e, moving to hrtimers to
> > overcome scheduling latency while scheduling the delayed work.
> >
> > TCPM has three work streams:
> > 1. tcpm_state_machine
> > 2. vdm_state_machine
> > 3. event_work
> >
> > tcpm_state_machine and vdm_state_machine both schedule work in
> > future i.e. delayed. Hence each of them have a corresponding
> > hrtimer, tcpm_state_machine_timer & vdm_state_machine_timer.
> >
> > When work is queued right away kthread_queue_work is used.
> > Else, the relevant timer is programmed and made to queue
> > the kthread_work upon timer expiry.
> >
> > kthread_create_worker only creates one kthread worker thread,
> > hence single threadedness of workqueue is retained.
> >
> > Signed-off-by: Badhri Jagan Sridharan 
>
> This doesn't apply against my usb-next branch at all.
>
> Can you rebase and resend?
>
> Remember to collect the reviewed-by tags as well when you do so.
>
> thanks,
>
> greg k-h

Re: [PATCH v2] usb: typec: tcpm: Migrate workqueue to RT priority for processing events

2020-07-29 Thread Greg Kroah-Hartman 
On Thu, Jul 23, 2020 at 07:05:51PM -0700, Badhri Jagan Sridharan wrote:
> "tReceiverResponse 15 ms Section 6.6.2
> The receiver of a Message requiring a response Shall respond
> within tReceiverResponse in order to ensure that the
> sender’s SenderResponseTimer does not expire."
> 
> When the cpu complex is busy running other lower priority
> work items, TCPM's work queue sometimes does not get scheduled
> on time to meet the above requirement from the spec.
> Moving to kthread_work apis to run with real time priority.
> Just lower than the default threaded irq priority,
> MAX_USER_RT_PRIO/2 + 1. (Higher number implies lower priority).
> 
> Further, as observed in 1ff688209e2e, moving to hrtimers to
> overcome scheduling latency while scheduling the delayed work.
> 
> TCPM has three work streams:
> 1. tcpm_state_machine
> 2. vdm_state_machine
> 3. event_work
> 
> tcpm_state_machine and vdm_state_machine both schedule work in
> future i.e. delayed. Hence each of them have a corresponding
> hrtimer, tcpm_state_machine_timer & vdm_state_machine_timer.
> 
> When work is queued right away kthread_queue_work is used.
> Else, the relevant timer is programmed and made to queue
> the kthread_work upon timer expiry.
> 
> kthread_create_worker only creates one kthread worker thread,
> hence single threadedness of workqueue is retained.
> 
> Signed-off-by: Badhri Jagan Sridharan 

This doesn't apply against my usb-next branch at all.

Can you rebase and resend?

Remember to collect the reviewed-by tags as well when you do so.

thanks,

greg k-h

Re: [PATCH v2] usb: typec: tcpm: Migrate workqueue to RT priority for processing events

2020-07-28 Thread Heikki Krogerus 
On Thu, Jul 23, 2020 at 07:05:51PM -0700, Badhri Jagan Sridharan wrote:
> "tReceiverResponse 15 ms Section 6.6.2
> The receiver of a Message requiring a response Shall respond
> within tReceiverResponse in order to ensure that the
> sender’s SenderResponseTimer does not expire."
> 
> When the cpu complex is busy running other lower priority
> work items, TCPM's work queue sometimes does not get scheduled
> on time to meet the above requirement from the spec.
> Moving to kthread_work apis to run with real time priority.
> Just lower than the default threaded irq priority,
> MAX_USER_RT_PRIO/2 + 1. (Higher number implies lower priority).
> 
> Further, as observed in 1ff688209e2e, moving to hrtimers to
> overcome scheduling latency while scheduling the delayed work.
> 
> TCPM has three work streams:
> 1. tcpm_state_machine
> 2. vdm_state_machine
> 3. event_work
> 
> tcpm_state_machine and vdm_state_machine both schedule work in
> future i.e. delayed. Hence each of them have a corresponding
> hrtimer, tcpm_state_machine_timer & vdm_state_machine_timer.
> 
> When work is queued right away kthread_queue_work is used.
> Else, the relevant timer is programmed and made to queue
> the kthread_work upon timer expiry.
> 
> kthread_create_worker only creates one kthread worker thread,
> hence single threadedness of workqueue is retained.
> 
> Signed-off-by: Badhri Jagan Sridharan 

Reviewed-by: Heikki Krogerus 

> ---
> 
> Changes since v1:(Guenter's suggestions)
> - Remove redundant call to hrtimer_cancel while calling
>   hrtimer_start.
> 
> ---
>  drivers/usb/typec/tcpm/tcpm.c | 140 ++
>  1 file changed, 92 insertions(+), 48 deletions(-)
> 
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index ff1cbd2147ca8a..fa9002944dc766 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -8,8 +8,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -28,7 +30,8 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +
> +#include 
>  
>  #define FOREACH_STATE(S) \
>   S(INVALID_STATE),   \
> @@ -195,7 +198,7 @@ struct tcpm_port {
>   struct device *dev;
>  
>   struct mutex lock;  /* tcpm state machine lock */
> - struct workqueue_struct *wq;
> + struct kthread_worker *wq;
>  
>   struct typec_capability typec_caps;
>   struct typec_port *typec_port;
> @@ -239,15 +242,17 @@ struct tcpm_port {
>   enum tcpm_state prev_state;
>   enum tcpm_state state;
>   enum tcpm_state delayed_state;
> - unsigned long delayed_runtime;
> + ktime_t delayed_runtime;
>   unsigned long delay_ms;
>  
>   spinlock_t pd_event_lock;
>   u32 pd_events;
>  
> - struct work_struct event_work;
> - struct delayed_work state_machine;
> - struct delayed_work vdm_state_machine;
> + struct kthread_work event_work;
> + struct hrtimer state_machine_timer;
> + struct kthread_work state_machine;
> + struct hrtimer vdm_state_machine_timer;
> + struct kthread_work vdm_state_machine;
>   bool state_machine_running;
>  
>   struct completion tx_complete;
> @@ -332,7 +337,7 @@ struct tcpm_port {
>  };
>  
>  struct pd_rx_event {
> - struct work_struct work;
> + struct kthread_work work;
>   struct tcpm_port *port;
>   struct pd_message msg;
>  };
> @@ -906,6 +911,27 @@ static int tcpm_pd_send_sink_caps(struct tcpm_port *port)
>   return tcpm_pd_transmit(port, TCPC_TX_SOP, );
>  }
>  
> +static void mod_tcpm_delayed_work(struct tcpm_port *port, unsigned int 
> delay_ms)
> +{
> + if (delay_ms) {
> + hrtimer_start(>state_machine_timer, 
> ms_to_ktime(delay_ms), HRTIMER_MODE_REL);
> + } else {
> + hrtimer_cancel(>state_machine_timer);
> + kthread_queue_work(port->wq, >state_machine);
> + }
> +}
> +
> +static void mod_vdm_delayed_work(struct tcpm_port *port, unsigned int 
> delay_ms)
> +{
> + if (delay_ms) {
> + hrtimer_start(>vdm_state_machine_timer, 
> ms_to_ktime(delay_ms),
> +   HRTIMER_MODE_REL);
> + } else {
> + hrtimer_cancel(>vdm_state_machine_timer);
> + kthread_queue_work(port->wq, >vdm_state_machine);
> + }
> +}
> +
>  static void tcpm_set_state(struct tcpm_port *port, enum tcpm_state state,
>  unsigned int delay_ms)
>  {
> @@ -914,9 +940,8 @@ static void tcpm_set_state(struct tcpm_port *port, enum 
> tcpm_state state,
>tcpm_states[port->state], tcpm_states[state],
>delay_ms);
>   port->delayed_state = state;
> - mod_delayed_work(port->wq, >state_machine,
> -  msecs_to_jiffies(delay_ms));
> - port->delayed_runtime = jiffies + msecs_to_jiffies(delay_ms);
> +

Re: [PATCH v2] usb: typec: tcpm: Migrate workqueue to RT priority for processing events

2020-07-24 Thread Guenter Roeck 
On 7/23/20 7:05 PM, Badhri Jagan Sridharan wrote:
> "tReceiverResponse 15 ms Section 6.6.2
> The receiver of a Message requiring a response Shall respond
> within tReceiverResponse in order to ensure that the
> sender’s SenderResponseTimer does not expire."
> 
> When the cpu complex is busy running other lower priority
> work items, TCPM's work queue sometimes does not get scheduled
> on time to meet the above requirement from the spec.
> Moving to kthread_work apis to run with real time priority.
> Just lower than the default threaded irq priority,
> MAX_USER_RT_PRIO/2 + 1. (Higher number implies lower priority).
> 
> Further, as observed in 1ff688209e2e, moving to hrtimers to
> overcome scheduling latency while scheduling the delayed work.
> 
> TCPM has three work streams:
> 1. tcpm_state_machine
> 2. vdm_state_machine
> 3. event_work
> 
> tcpm_state_machine and vdm_state_machine both schedule work in
> future i.e. delayed. Hence each of them have a corresponding
> hrtimer, tcpm_state_machine_timer & vdm_state_machine_timer.
> 
> When work is queued right away kthread_queue_work is used.
> Else, the relevant timer is programmed and made to queue
> the kthread_work upon timer expiry.
> 
> kthread_create_worker only creates one kthread worker thread,
> hence single threadedness of workqueue is retained.
> 
> Signed-off-by: Badhri Jagan Sridharan 

Reviewed-by: Guenter Roeck 

Thanks,
Guenter

> ---
> 
> Changes since v1:(Guenter's suggestions)
> - Remove redundant call to hrtimer_cancel while calling
>   hrtimer_start.
> 
> ---
>  drivers/usb/typec/tcpm/tcpm.c | 140 ++
>  1 file changed, 92 insertions(+), 48 deletions(-)
> 
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index ff1cbd2147ca8a..fa9002944dc766 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -8,8 +8,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -28,7 +30,8 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +
> +#include 
>  
>  #define FOREACH_STATE(S) \
>   S(INVALID_STATE),   \
> @@ -195,7 +198,7 @@ struct tcpm_port {
>   struct device *dev;
>  
>   struct mutex lock;  /* tcpm state machine lock */
> - struct workqueue_struct *wq;
> + struct kthread_worker *wq;
>  
>   struct typec_capability typec_caps;
>   struct typec_port *typec_port;
> @@ -239,15 +242,17 @@ struct tcpm_port {
>   enum tcpm_state prev_state;
>   enum tcpm_state state;
>   enum tcpm_state delayed_state;
> - unsigned long delayed_runtime;
> + ktime_t delayed_runtime;
>   unsigned long delay_ms;
>  
>   spinlock_t pd_event_lock;
>   u32 pd_events;
>  
> - struct work_struct event_work;
> - struct delayed_work state_machine;
> - struct delayed_work vdm_state_machine;
> + struct kthread_work event_work;
> + struct hrtimer state_machine_timer;
> + struct kthread_work state_machine;
> + struct hrtimer vdm_state_machine_timer;
> + struct kthread_work vdm_state_machine;
>   bool state_machine_running;
>  
>   struct completion tx_complete;
> @@ -332,7 +337,7 @@ struct tcpm_port {
>  };
>  
>  struct pd_rx_event {
> - struct work_struct work;
> + struct kthread_work work;
>   struct tcpm_port *port;
>   struct pd_message msg;
>  };
> @@ -906,6 +911,27 @@ static int tcpm_pd_send_sink_caps(struct tcpm_port *port)
>   return tcpm_pd_transmit(port, TCPC_TX_SOP, );
>  }
>  
> +static void mod_tcpm_delayed_work(struct tcpm_port *port, unsigned int 
> delay_ms)
> +{
> + if (delay_ms) {
> + hrtimer_start(>state_machine_timer, 
> ms_to_ktime(delay_ms), HRTIMER_MODE_REL);
> + } else {
> + hrtimer_cancel(>state_machine_timer);
> + kthread_queue_work(port->wq, >state_machine);
> + }
> +}
> +
> +static void mod_vdm_delayed_work(struct tcpm_port *port, unsigned int 
> delay_ms)
> +{
> + if (delay_ms) {
> + hrtimer_start(>vdm_state_machine_timer, 
> ms_to_ktime(delay_ms),
> +   HRTIMER_MODE_REL);
> + } else {
> + hrtimer_cancel(>vdm_state_machine_timer);
> + kthread_queue_work(port->wq, >vdm_state_machine);
> + }
> +}
> +
>  static void tcpm_set_state(struct tcpm_port *port, enum tcpm_state state,
>  unsigned int delay_ms)
>  {
> @@ -914,9 +940,8 @@ static void tcpm_set_state(struct tcpm_port *port, enum 
> tcpm_state state,
>tcpm_states[port->state], tcpm_states[state],
>delay_ms);
>   port->delayed_state = state;
> - mod_delayed_work(port->wq, >state_machine,
> -  msecs_to_jiffies(delay_ms));
> - port->delayed_runtime = jiffies + msecs_to_jiffies(delay_ms);
> +