summaryrefslogtreecommitdiff
path: root/arch/arm64/Makefile
diff options
context:
space:
mode:
authorBadhri Jagan Sridharan <badhri@google.com>2020-08-18 12:27:58 -0700
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2020-08-28 09:50:29 +0200
commit3ed8e1c2ac9914a2fcb08ec13476b85319536cea (patch)
tree85f8dca16a0179b883583bfcea35343a02a92951 /arch/arm64/Makefile
parentaefc66afe42bcae01743c0b3c5addd089263801b (diff)
usb: typec: tcpm: Migrate workqueue to RT priority for processing events
"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. 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 <badhri@google.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200818192758.2562908-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'arch/arm64/Makefile')
0 files changed, 0 insertions, 0 deletions