Skip to contentSkip to conversation

add xhci hooks for USB offload

PATCH In review Howard Yen 5 participants 16 messages Jan 19, 2021 – Feb 9, 2021

Subsystems (3)
lore
Share & tools
lore

Howard Yen

author
#0 lore raw

cover add xhci hooks for USB offload

To let the xhci driver support USB offload, add hooks for vendor to have customized behavior for the initialization, memory allocation, irq work, and device context synchronization. Detail is in each patch commit message.

Howard Yen (4):
usb: host: add xhci hooks for USB offload
usb: host: export symbols for xhci hooks usage
usb: xhci-plat: add xhci_plat_priv_overwrite
dt-bindings: usb: usb-xhci: add USB offload support

 .../devicetree/bindings/usb/usb-xhci.txt      |  1 +
 drivers/usb/host/xhci-hub.c                   |  5 +
 drivers/usb/host/xhci-mem.c                   | 99 ++++++++++++++++---
 drivers/usb/host/xhci-plat.c                  | 45 ++++++++-
 drivers/usb/host/xhci-plat.h                  |  9 ++
 drivers/usb/host/xhci-ring.c                  | 19 +++-
 drivers/usb/host/xhci.c                       | 89 +++++++++++++++++
 drivers/usb/host/xhci.h                       | 38 +++++++
 8 files changed, 289 insertions(+), 16 deletions(-)
Signature · 1 line
2.30.0.284.gd98b1dd5eaa7-goog
author
#1 lore raw

PATCH 1/4 usb: host: add xhci hooks for USB offload

To enable supporting for USB offload, define "offload" in usb controller node of device tree. "offload" value can be used to determine which type of offload was been enabled in the SoC.

For example:

&usbdrd_dwc3 {
	...
	/* support usb offloading, 0: disabled, 1: audio */
	offload = <1>;
	...
};

There are several vendor_ops introduced by this patch:

struct xhci_vendor_ops - function callbacks for vendor specific operations {
@vendor_init:
- called for vendor init process during xhci-plat-hcd probe.
@vendor_cleanup:
- called for vendor cleanup process during xhci-plat-hcd remove.
@is_usb_offload_enabled:
- called to check if usb offload enabled.
@queue_irq_work:
- called to queue vendor specific irq work.
@alloc_dcbaa:
- called when allocating vendor specific dcbaa during memory initializtion.
@free_dcbaa:
- called to free vendor specific dcbaa when cleanup the memory.
@alloc_transfer_ring:
- called when vendor specific transfer ring allocation is required
@free_transfer_ring:
- called to free vendor specific transfer ring
@sync_dev_ctx:
- called when synchronization for device context is required
}

The xhci hooks with prefix "xhci_vendor_" on the ops in xhci_vendor_ops. For example, vendor_init ops will be invoked by xhci_vendor_init() hook, is_usb_offload_enabled ops will be invoked by xhci_vendor_is_usb_offload_enabled(), and so on.

---
 drivers/usb/host/xhci-hub.c  |  5 ++
 drivers/usb/host/xhci-mem.c  | 96 +++++++++++++++++++++++++++++++-----
 drivers/usb/host/xhci-plat.c | 25 +++++++++-
 drivers/usb/host/xhci-plat.h |  2 +
 drivers/usb/host/xhci-ring.c | 13 +++++
 drivers/usb/host/xhci.c      | 89 +++++++++++++++++++++++++++++++++
 drivers/usb/host/xhci.h      | 38 ++++++++++++++
 7 files changed, 254 insertions(+), 14 deletions(-)
drivers/usb/host/xhci-hub.c +5 -0
index f37316d2c8fa..0eda5bb23ed8 100644
@@ -448,8 +448,13 @@ static int xhci_stop_device(struct xhci_hcd *xhci, int slot_id, int suspend)
 	    cmd->status == COMP_COMMAND_RING_STOPPED) {
 		xhci_warn(xhci, "Timeout while waiting for stop endpoint command\n");
 		ret = -ETIME;
+		goto cmd_cleanup;
 	}
 
+	ret = xhci_vendor_sync_dev_ctx(xhci, slot_id);
+	if (ret)
+		xhci_warn(xhci, "Sync device context failed, ret=%d\n", ret);
+
 cmd_cleanup:
 	xhci_free_command(xhci, cmd);
 	return ret;
drivers/usb/host/xhci-mem.c +83 -13

141 lines not on this page · raw message

drivers/usb/host/xhci-plat.c +24 -1
index f6b4089bfc4a..5f8e69089654 100644
@@ -163,6 +163,23 @@ static const struct of_device_id usb_xhci_of_match[] = {
 MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
 #endif
 
+static int xhci_vendor_init(struct xhci_hcd *xhci)
+{
+	struct xhci_vendor_ops *ops = xhci_vendor_get_ops(xhci);
+
+	if (ops && ops->vendor_init)
+		return ops->vendor_init(xhci);
+	return 0;
+}
+
+static void xhci_vendor_cleanup(struct xhci_hcd *xhci)
+{
+	struct xhci_vendor_ops *ops = xhci_vendor_get_ops(xhci);
+
+	if (ops && ops->vendor_cleanup)
+		ops->vendor_cleanup(xhci);
+}
+
 static int xhci_plat_probe(struct platform_device *pdev)
 {
 	const struct xhci_plat_priv *priv_match;
@@ -314,6 +331,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
 			goto put_usb3_hcd;
 	}
 
+	ret = xhci_vendor_init(xhci);
+	if (ret)
+		goto disable_usb_phy;
+
 	hcd->tpl_support = of_usb_host_tpl_support(sysdev->of_node);
 	xhci->shared_hcd->tpl_support = hcd->tpl_support;
 	ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
@@ -380,8 +401,10 @@ static int xhci_plat_remove(struct platform_device *dev)
 	usb_phy_shutdown(hcd->usb_phy);
 
 	usb_remove_hcd(hcd);
-	usb_put_hcd(shared_hcd);
 
+	xhci_vendor_cleanup(xhci);
+
+	usb_put_hcd(shared_hcd);
 	clk_disable_unprepare(clk);
 	clk_disable_unprepare(reg_clk);
 	usb_put_hcd(hcd);
drivers/usb/host/xhci-plat.h +2 -0
index b49f6447bd3a..2b2d090c4c01 100644
@@ -13,6 +13,8 @@
 struct xhci_plat_priv {
 	const char *firmware_name;
 	unsigned long long quirks;
+	struct xhci_vendor_ops *vendor_ops;
+	struct xhci_vendor_data *vendor_data;
 	void (*plat_start)(struct usb_hcd *);
 	int (*init_quirk)(struct usb_hcd *);
 	int (*resume_quirk)(struct usb_hcd *);
drivers/usb/host/xhci-ring.c +13 -0
index 2c255d0620b0..bfd653a1e5f6 100644
@@ -2823,6 +2823,15 @@ static void xhci_update_erst_dequeue(struct xhci_hcd *xhci,
 	xhci_write_64(xhci, temp_64, &xhci->ir_set->erst_dequeue);
 }
 
+static irqreturn_t xhci_vendor_queue_irq_work(struct xhci_hcd *xhci)
+{
+	struct xhci_vendor_ops *ops = xhci_vendor_get_ops(xhci);
+
+	if (ops && ops->queue_irq_work)
+		return ops->queue_irq_work(xhci);
+	return IRQ_NONE;
+}
+
 /*
  * xHCI spec says we can get an interrupt, and if the HC has an error condition,
  * we might get bad data out of the event ring.  Section 4.10.2.7 has a list of
@@ -2857,6 +2866,10 @@ irqreturn_t xhci_irq(struct usb_hcd *hcd)
 		goto out;
 	}
 
+	ret = xhci_vendor_queue_irq_work(xhci);
+	if (ret == IRQ_HANDLED)
+		goto out;
+
 	/*
 	 * Clear the op reg interrupt status first,
 	 * so we can receive interrupts from other MSI-X interrupters.
drivers/usb/host/xhci.c +89 -0

155 lines not on this page · raw message

drivers/usb/host/xhci.h +38 -0
index 2c6c4f8d1ee1..4b110590561b 100644
@@ -2177,6 +2177,44 @@ static inline struct xhci_ring *xhci_urb_to_transfer_ring(struct xhci_hcd *xhci,
 					urb->stream_id);
 }
 
+/**
+ * struct xhci_vendor_ops - function callbacks for vendor specific operations
+ * @vendor_init: called for vendor init process
+ * @vendor_cleanup: called for vendor cleanup process
+ * @is_usb_offload_enabled: called to check if usb offload enabled
+ * @queue_irq_work: called to queue vendor specific irq work
+ * @alloc_dcbaa: called when allocating vendor specific dcbaa
+ * @free_dcbaa: called to free vendor specific dcbaa
+ * @alloc_transfer_ring: called when remote transfer ring allocation is required
+ * @free_transfer_ring: called to free vendor specific transfer ring
+ * @sync_dev_ctx: called when synchronization for device context is required
+ */
+struct xhci_vendor_ops {
+	int (*vendor_init)(struct xhci_hcd *xhci);
+	void (*vendor_cleanup)(struct xhci_hcd *xhci);
+	bool (*is_usb_offload_enabled)(struct xhci_hcd *xhci,
+				       struct xhci_virt_device *vdev,
+				       unsigned int ep_index);
+	irqreturn_t (*queue_irq_work)(struct xhci_hcd *xhci);
+
+	struct xhci_device_context_array *(*alloc_dcbaa)(struct xhci_hcd *xhci,
+							 gfp_t flags);
+	void (*free_dcbaa)(struct xhci_hcd *xhci);
+
+	struct xhci_ring *(*alloc_transfer_ring)(struct xhci_hcd *xhci,
+			u32 endpoint_type, enum xhci_ring_type ring_type,
+			gfp_t mem_flags);
+	void (*free_transfer_ring)(struct xhci_hcd *xhci,
+			struct xhci_virt_device *virt_dev, unsigned int ep_index);
+	int (*sync_dev_ctx)(struct xhci_hcd *xhci, unsigned int slot_id);
+	bool (*usb_offload_skip_urb)(struct xhci_hcd *xhci, struct urb *urb);
+};
+
+struct xhci_vendor_ops *xhci_vendor_get_ops(struct xhci_hcd *xhci);
+
+int xhci_vendor_sync_dev_ctx(struct xhci_hcd *xhci, unsigned int slot_id);
+bool xhci_vendor_usb_offload_skip_urb(struct xhci_hcd *xhci, struct urb *urb);
+
 /*
  * TODO: As per spec Isochronous IDT transmissions are supported. We bypass
  * them anyways as we where unable to find a device that matches the
Signature · 1 line
2.30.0.284.gd98b1dd5eaa7-goog
maintainer
#2 lore raw

Re: [PATCH 1/4] usb: host: add xhci hooks for USB offload

Quoted 4 lines · Howard Yen

To enable supporting for USB offload, define "offload" in usb controller node of device tree. "offload" value can be used to determine which type of offload was been enabled in the SoC.

Quoted 8 lines

For example:

&usbdrd_dwc3 {
	...
	/* support usb offloading, 0: disabled, 1: audio */
	offload = <1>;
	...
};

This patch doesn't require this change, right? That's only necessary for your DT change later on, from what I can tell, so maybe it's not needed to list this here, as the xhci core changes do not seem to require dt at all.

thanks,

greg k-h

author
#3 lore raw

PATCH 2/4 usb: host: export symbols for xhci hooks usage

In reply to Howard Yen

Export symbols for xhci hooks usage:
xhci_ring_free
- Allow xhci hook to free xhci_ring.
xhci_get_slot_ctx
- Allow xhci hook to get slot_ctx from the xhci_container_ctx for getting the slot_ctx information to know which slot is offloading and compare the context in remote subsystem memory if needed.
xhci_get_ep_ctx
- Allow xhci hook to get ep_ctx from the xhci_container_ctx for getting the ep_ctx information to know which ep is offloading and comparing the context in remote subsystem memory if needed.
xhci_handle_event
- Allow xhci hook to handle the xhci events from the USB controller.
xhci_update_erst_dequeue
- If xhci events was handle by xhci hook, it needs to update the erst dequeue pointer to let the USB controller know the events was handled.

---
 drivers/usb/host/xhci-mem.c  | 3 +++
 drivers/usb/host/xhci-ring.c | 6 ++++--
 2 files changed, 7 insertions(+), 2 deletions(-)
drivers/usb/host/xhci-mem.c +3 -0
index f3dbc5956290..69f19774b914 100644
@@ -289,6 +289,7 @@ void xhci_ring_free(struct xhci_hcd *xhci, struct xhci_ring *ring)
 
 	kfree(ring);
 }
+EXPORT_SYMBOL_GPL(xhci_ring_free);
 
 static void xhci_initialize_ring_info(struct xhci_ring *ring,
 					unsigned int cycle_state)
@@ -545,6 +546,7 @@ struct xhci_slot_ctx *xhci_get_slot_ctx(struct xhci_hcd *xhci,
 	return (struct xhci_slot_ctx *)
 		(ctx->bytes + CTX_SIZE(xhci->hcc_params));
 }
+EXPORT_SYMBOL_GPL(xhci_get_slot_ctx);
 
 struct xhci_ep_ctx *xhci_get_ep_ctx(struct xhci_hcd *xhci,
 				    struct xhci_container_ctx *ctx,
@@ -558,6 +560,7 @@ struct xhci_ep_ctx *xhci_get_ep_ctx(struct xhci_hcd *xhci,
 	return (struct xhci_ep_ctx *)
 		(ctx->bytes + (ep_index * CTX_SIZE(xhci->hcc_params)));
 }
+EXPORT_SYMBOL_GPL(xhci_get_ep_ctx);
 
 
 /***************** Streams structures manipulation *************************/
drivers/usb/host/xhci-ring.c +4 -2
index bfd653a1e5f6..f3b387e2fcb3 100644
@@ -2717,7 +2717,7 @@ static int handle_tx_event(struct xhci_hcd *xhci,
  * Returns >0 for "possibly more events to process" (caller should call again),
  * otherwise 0 if done.  In future, <0 returns should indicate error code.
  */
-static int xhci_handle_event(struct xhci_hcd *xhci)
+int xhci_handle_event(struct xhci_hcd *xhci)
 {
 	union xhci_trb *event;
 	int update_ptrs = 1;
@@ -2786,13 +2786,14 @@ static int xhci_handle_event(struct xhci_hcd *xhci)
 	 */
 	return 1;
 }
+EXPORT_SYMBOL_GPL(xhci_handle_event);
 
 /*
  * Update Event Ring Dequeue Pointer:
  * - When all events have finished
  * - To avoid "Event Ring Full Error" condition
  */
-static void xhci_update_erst_dequeue(struct xhci_hcd *xhci,
+void xhci_update_erst_dequeue(struct xhci_hcd *xhci,
 		union xhci_trb *event_ring_deq)
 {
 	u64 temp_64;
@@ -2822,6 +2823,7 @@ static void xhci_update_erst_dequeue(struct xhci_hcd *xhci,
 	temp_64 |= ERST_EHB;
 	xhci_write_64(xhci, temp_64, &xhci->ir_set->erst_dequeue);
 }
+EXPORT_SYMBOL_GPL(xhci_update_erst_dequeue);
 
 static irqreturn_t xhci_vendor_queue_irq_work(struct xhci_hcd *xhci)
 {
Signature · 1 line
2.30.0.284.gd98b1dd5eaa7-goog
author
#4 lore raw

PATCH 3/4 usb: xhci-plat: add xhci_plat_priv_overwrite

In reply to Howard Yen

Add an overwrite to platform specific callback for setting up the xhci_vendor_ops, allow vendor to store the xhci_vendor_ops and overwrite them when xhci_plat_probe invoked.

This change is depend on Commit in this patch series
("usb: host: add xhci hooks for USB offload"), vendor needs to invoke xhci_plat_register_vendor_ops() to register the vendor specific vendor_ops. And the vendor_ops will overwrite the vendor_ops inside xhci_plat_priv in xhci_vendor_init() during xhci-plat-hcd probe.

---
 drivers/usb/host/xhci-plat.c | 20 ++++++++++++++++++++
 drivers/usb/host/xhci-plat.h |  7 +++++++
 2 files changed, 27 insertions(+)
drivers/usb/host/xhci-plat.c +20 -0
index 5f8e69089654..a8e217494831 100644
@@ -163,9 +163,26 @@ static const struct of_device_id usb_xhci_of_match[] = {
 MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
 #endif
 
+static struct xhci_plat_priv_overwrite xhci_plat_vendor_overwrite;
+
+int xhci_plat_register_vendor_ops(struct xhci_vendor_ops *vendor_ops)
+{
+	if (vendor_ops == NULL)
+		return -EINVAL;
+
+	xhci_plat_vendor_overwrite.vendor_ops = vendor_ops;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(xhci_plat_register_vendor_ops);
+
 static int xhci_vendor_init(struct xhci_hcd *xhci)
 {
 	struct xhci_vendor_ops *ops = xhci_vendor_get_ops(xhci);
+	struct xhci_plat_priv *priv = xhci_to_priv(xhci);
+
+	if (xhci_plat_vendor_overwrite.vendor_ops)
+		ops = priv->vendor_ops = xhci_plat_vendor_overwrite.vendor_ops;
 
 	if (ops && ops->vendor_init)
 		return ops->vendor_init(xhci);
@@ -175,9 +192,12 @@ static int xhci_vendor_init(struct xhci_hcd *xhci)
 static void xhci_vendor_cleanup(struct xhci_hcd *xhci)
 {
 	struct xhci_vendor_ops *ops = xhci_vendor_get_ops(xhci);
+	struct xhci_plat_priv *priv = xhci_to_priv(xhci);
 
 	if (ops && ops->vendor_cleanup)
 		ops->vendor_cleanup(xhci);
+
+	priv->vendor_ops = NULL;
 }
 
 static int xhci_plat_probe(struct platform_device *pdev)
drivers/usb/host/xhci-plat.h +7 -0
index 2b2d090c4c01..d85802725208 100644
@@ -22,4 +22,11 @@ struct xhci_plat_priv {
 
 #define hcd_to_xhci_priv(h) ((struct xhci_plat_priv *)hcd_to_xhci(h)->priv)
 #define xhci_to_priv(x) ((struct xhci_plat_priv *)(x)->priv)
+
+struct xhci_plat_priv_overwrite {
+	struct xhci_vendor_ops *vendor_ops;
+};
+
+int xhci_plat_register_vendor_ops(struct xhci_vendor_ops *vendor_ops);
+
 #endif	/* _XHCI_PLAT_H */
Signature · 1 line
2.30.0.284.gd98b1dd5eaa7-goog
author
#5 lore raw

PATCH 4/4 dt-bindings: usb: usb-xhci: add USB offload support

In reply to Howard Yen

Document USB offload support for usb-xhci.

For example:

&usbdrd_dwc3 {
	...
	/* support usb offloading, 0: disabled, 1: audio */
	offload = <1>;
	...
};
---
 Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
 1 file changed, 1 insertion(+)
Documentation/devicetree/bindings/usb/usb-xhci.txt +1 -0
index b120dd6612a2..aab1fd499f15 100644
@@ -46,6 +46,7 @@ Optional properties:
   - quirk-broken-port-ped: set if the controller has broken port disable mechanism
   - imod-interval-ns: default interrupt moderation interval is 5000ns
   - phys : see usb-hcd.yaml in the current directory
+  - offload: supporting USB offload feature, 0: disabled, 1: audio
 
 additionally the properties from usb-hcd.yaml (in the current directory) are
 supported.
Signature · 1 line
2.30.0.284.gd98b1dd5eaa7-goog
maintainer
#6 lore raw

Re: [PATCH 4/4] dt-bindings: usb: usb-xhci: add USB offload support

Quoted 21 lines · Howard Yen

Document USB offload support for usb-xhci.

For example:

&usbdrd_dwc3 {
	...
	/* support usb offloading, 0: disabled, 1: audio */
	offload = <1>;
	...
};
---
 Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
 1 file changed, 1 insertion(+)
Documentation/devicetree/bindings/usb/usb-xhci.txt +0 -0
index b120dd6612a2..aab1fd499f15 100644

Documentation/devicetree/bindings/usb/usb-xhci.txt Optional properties: · line 49

Quoted 4 lines
Documentation/devicetree/bindings/usb/usb-xhci.txt +1 -0
@@ -46,6 +46,7 @@ Optional properties:
   - quirk-broken-port-ped: set if the controller has broken port disable mechanism
   - imod-interval-ns: default interrupt moderation interval is 5000ns
   - phys : see usb-hcd.yaml in the current directory
+  - offload: supporting USB offload feature, 0: disabled, 1: audio

Why does the "type" of offload matter, shouldn't it just be:
0: disabled, 1: enabled
?

And in thinking about it some more, why does this need to be a binding at all, shouldn't this just be an issue if the platform-specific ops are available or not, meaning no DT change should be needed at all?

thanks,

greg k-h

maintainer
#7 lore raw

Re: [PATCH 4/4] dt-bindings: usb: usb-xhci: add USB offload support

In reply to Howard Yen
Quoted 1 line · Howard Yen

Document USB offload support for usb-xhci.

Is this a standard XHCI capability or specific to certain implementations? Do all versions of DWC3 support it?

Quoted 20 lines

For example:

&usbdrd_dwc3 {
	...
	/* support usb offloading, 0: disabled, 1: audio */
	offload = <1>;
	...
};
---
 Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
 1 file changed, 1 insertion(+)
Documentation/devicetree/bindings/usb/usb-xhci.txt +0 -0
index b120dd6612a2..aab1fd499f15 100644

Documentation/devicetree/bindings/usb/usb-xhci.txt Optional properties: · line 49

Quoted 4 lines
Documentation/devicetree/bindings/usb/usb-xhci.txt +1 -0
@@ -46,6 +46,7 @@ Optional properties:
   - quirk-broken-port-ped: set if the controller has broken port disable mechanism
   - imod-interval-ns: default interrupt moderation interval is 5000ns
   - phys : see usb-hcd.yaml in the current directory
+  - offload: supporting USB offload feature, 0: disabled, 1: audio

What does not present mean? Unless you need 'keep the h/w default', then this can be boolean instead.

Quoted 6 lines
Documentation/devicetree/bindings/usb/usb-xhci.txt +0 -0
 additionally the properties from usb-hcd.yaml (in the current directory) are
 supported.
Signature · 1 line
2.30.0.284.gd98b1dd5eaa7-goog
maintainer
#8 lore raw
In reply to Howard Yen
Quoted 10 lines · Howard Yen

To let the xhci driver support USB offload, add hooks for vendor to have customized behavior for the initialization, memory allocation, irq work, and device context synchronization. Detail is in each patch commit message.

Howard Yen (4):
usb: host: add xhci hooks for USB offload
usb: host: export symbols for xhci hooks usage
usb: xhci-plat: add xhci_plat_priv_overwrite
dt-bindings: usb: usb-xhci: add USB offload support

Quoted 9 lines
 .../devicetree/bindings/usb/usb-xhci.txt      |  1 +
 drivers/usb/host/xhci-hub.c                   |  5 +
 drivers/usb/host/xhci-mem.c                   | 99 ++++++++++++++++---
 drivers/usb/host/xhci-plat.c                  | 45 ++++++++-
 drivers/usb/host/xhci-plat.h                  |  9 ++
 drivers/usb/host/xhci-ring.c                  | 19 +++-
 drivers/usb/host/xhci.c                       | 89 +++++++++++++++++
 drivers/usb/host/xhci.h                       | 38 +++++++
 8 files changed, 289 insertions(+), 16 deletions(-)

Thanks so much for posting this.

A bit of background for the lists. I helped review previous versions of this patchset from Howard as he worked to convert the hacks from a previous vendor into something that would be semi-sane. It would be great if we can take the previously-submitted Samsung usb-audio hooks (as published in their kernel sources for their last-year phones) and get it into something mergable with this scheme as well, as this is the "correct" way to do what they were wanting to do.

Although I know that is outside of the work you probably have time for, maybe I will work on that over the next few weeks...

thanks,

greg k-h

maintainer
#9 lore raw
In reply to Howard Yen
Quoted 3 lines · Howard Yen

To let the xhci driver support USB offload, add hooks for vendor to have customized behavior for the initialization, memory allocation, irq work, and device context synchronization. Detail is in each patch commit message.

Is this related to the usb audio sideband capability that was added to the xHCI specification? If yes, then we should probably implement the generic parts first, and then add the vendor specific hooks.

-Mathias

author
#10 lore raw
Quoted 6 lines · Mathias Nyman
Quoted 3 lines · Howard Yen

To let the xhci driver support USB offload, add hooks for vendor to have customized behavior for the initialization, memory allocation, irq work, and device context synchronization. Detail is in each patch commit message.

Quoted 7 lines

Is this related to the usb audio sideband capability that was added to the xHCI specification? If yes, then we should probably implement the generic parts first, and then add the vendor specific hooks.

-Mathias

This is for offloading, no matter what type of offloading. I made the hooks generically and can be used for usb audio on the xhci which is not including the usb audio sideband capability.

- Howard

#11 lore raw
Quoted 11 lines · Howard Yen
Quoted 10 lines · Mathias Nyman
Quoted 3 lines · Howard Yen

To let the xhci driver support USB offload, add hooks for vendor to have customized behavior for the initialization, memory allocation, irq work, and device context synchronization. Detail is in each patch commit message.

Is this related to the usb audio sideband capability that was added to the xHCI specification? If yes, then we should probably implement the generic parts first, and then add the vendor specific hooks.

Quoted 8 lines
Quoted 3 lines

-Mathias

This is for offloading, no matter what type of offloading. I made the hooks generically and can be used for usb audio on the xhci which is not including the usb audio sideband capability.

Ok, before adding hooks like this I think we need to see how they are used. Do you have the rest of the patches that go on top of this series?

Maybe it could make sense to use overrides for the functions in struct hc_driver instead in some cases? There is support for that already.

Thanks
-Mathias

maintainer
#12 lore raw
Quoted 21 lines · Mathias Nyman
Quoted 11 lines · Howard Yen
Quoted 10 lines · Mathias Nyman
Quoted 3 lines · Howard Yen

To let the xhci driver support USB offload, add hooks for vendor to have customized behavior for the initialization, memory allocation, irq work, and device context synchronization. Detail is in each patch commit message.

Is this related to the usb audio sideband capability that was added to the xHCI specification? If yes, then we should probably implement the generic parts first, and then add the vendor specific hooks.

Quoted 8 lines
Quoted 3 lines

-Mathias

This is for offloading, no matter what type of offloading. I made the hooks generically and can be used for usb audio on the xhci which is not including the usb audio sideband capability.

Quoted 5 lines

Ok, before adding hooks like this I think we need to see how they are used. Do you have the rest of the patches that go on top of this series?

Maybe it could make sense to use overrides for the functions in struct hc_driver instead in some cases? There is support for that already.

What overrides could be done for these changes? At first glance that would seem to require a lot of duplicated code in whatever override happens to be needed.

thanks,

greg k-h

author
#13 lore raw
Quoted 29 lines · Greg KH
Quoted 21 lines · Mathias Nyman
Quoted 11 lines · Howard Yen
Quoted 10 lines · Mathias Nyman
Quoted 3 lines · Howard Yen

To let the xhci driver support USB offload, add hooks for vendor to have customized behavior for the initialization, memory allocation, irq work, and device context synchronization. Detail is in each patch commit message.

Is this related to the usb audio sideband capability that was added to the xHCI specification? If yes, then we should probably implement the generic parts first, and then add the vendor specific hooks.

Quoted 8 lines
Quoted 3 lines

-Mathias

This is for offloading, no matter what type of offloading. I made the hooks generically and can be used for usb audio on the xhci which is not including the usb audio sideband capability.

Quoted 5 lines

Ok, before adding hooks like this I think we need to see how they are used. Do you have the rest of the patches that go on top of this series?

Maybe it could make sense to use overrides for the functions in struct hc_driver instead in some cases? There is support for that already.

Quoted 7 lines

What overrides could be done for these changes? At first glance that would seem to require a lot of duplicated code in whatever override happens to be needed.

thanks,

greg k-h

This patch series is all the changes for the offload hooks currently.

I thought about this, but if I tried to override the functions in struct hc_driver, that'll need to
copy many code to the override function, and it won't follow the latest change in the core
xhci driver.

- Howard

#14 lore raw
Quoted 20 lines · Howard Yen
Quoted 9 lines · Greg KH
Quoted 6 lines · Mathias Nyman

Ok, before adding hooks like this I think we need to see how they are used. Do you have the rest of the patches that go on top of this series?

Maybe it could make sense to use overrides for the functions in struct hc_driver instead in some cases? There is support for that already.

Quoted 7 lines

What overrides could be done for these changes? At first glance that would seem to require a lot of duplicated code in whatever override happens to be needed.

thanks,

greg k-h

This patch series is all the changes for the offload hooks currently.

Quoted 8 lines

I thought about this, but if I tried to override the functions in struct hc_driver, that'll need to
copy many code to the override function, and it won't follow the latest change in the core
xhci driver.

- Howard

Ok, I see.

The point I'm trying to make is that there is no way for me to know if these hooks are the right solution before I see any code using them.

Is the offloading code ready and public somewhere?

Thanks
-Mathias

maintainer
#15 lore raw
Quoted 28 lines · Mathias Nyman
Quoted 27 lines · Howard Yen
Quoted 9 lines · Greg KH
Quoted 6 lines · Mathias Nyman

Ok, before adding hooks like this I think we need to see how they are used. Do you have the rest of the patches that go on top of this series?

Maybe it could make sense to use overrides for the functions in struct hc_driver instead in some cases? There is support for that already.

Quoted 7 lines

What overrides could be done for these changes? At first glance that would seem to require a lot of duplicated code in whatever override happens to be needed.

thanks,

greg k-h

This patch series is all the changes for the offload hooks currently.

I thought about this, but if I tried to override the functions in struct hc_driver, that'll need to
copy many code to the override function, and it won't follow the latest change in the core
xhci driver.

Quoted 8 lines
Quoted 1 line

- Howard

Ok, I see.

The point I'm trying to make is that there is no way for me to know if these hooks are the right solution before I see any code using them.

Is the offloading code ready and public somewhere?

There is offload code published in the last few Samsung phone kernels, I want to get that ported to these hooks to see if that works properly.

Give me a few days and I'll see if I can get it working, I had a half-finished port around here somewhere...

thanks,

greg k-h