drivers: usb: udc: Add UDPHS driver by MCHP-MPU-Solutions-SHA · Pull Request #99620 · zephyrproject-rtos/zephyr

MCHP-MPU-Solutions-SHA · 2025-11-19T01:57:54Z

Add driver support for Sama7g5 USB UDC (UDPHS).

Many thanks.
Xing.

tmon-nordic · 2025-11-19T09:55:58Z

+	  USB packets system data bursts will be locked for
+	  maximum optimization of the bus bandwidth usage.


I have no idea what this really means. From code it seems that you set some bit. Is it essentially affecting DMA operation/memory access arbitrage?

Hi, this is a chip related feature, for more details please refer to the datasheet, see bit BURST_LCK in register UDPHS_DMACONTROL.
This will allow the UDPHS DMA channel has max burst length when accessing the bus.

And I made a switch for this feature in the Kconfig, customer can enable it for higher USB bandwidth under heavy system load.

nandojve

Add a report from sample/subsys/usb/testusb HS. FS is it should work like that too.
A full report usually tests from 0 up to 29.

nandojve · 2025-11-20T14:32:02Z

 			};
 		};
+
+		udphsa: usbd@200000 {


Convention is order by address.

The devices in sama7g5.dtsi have been listed in alphabetical order, so I put the udphs device at the end of it.
Do you still need me order the udphs devices by space address?

nandojve · 2025-11-20T14:35:33Z

+
+compatible: "microchip,sam-udphs"
+
+include: [usb-ep.yaml, pinctrl-device.yaml]


zephyr/dts/bindings/ethernet/atmel,gmac-common.yaml

Lines 5 to 7 in db0c34d

include:

- name: ethernet-controller.yaml

- name: pinctrl-device.yaml

-include: [usb-ep.yaml, pinctrl-device.yaml] +include: + - name: usb-ep.yaml + - name: pinctrl-device.yaml

MCHP-MPU-Solutions-SHA · 2025-11-24T09:54:05Z

Add a report from sample/subsys/usb/testusb HS. FS is it should work like that too. A full report usually tests from 0 up to 29.

Hi Gerson,
It looks like I have find a driver bug via testusb tool (in test 10), so I just remove the previous comment.
I will fix it and updated here.

Many thanks.
Xing.

nandojve · 2025-11-24T17:26:30Z

Add a report from sample/subsys/usb/testusb HS. FS is it should work like that too. A full report usually tests from 0 up to 29.

Hi Gerson, It looks like I have find a driver bug via testusb tool (in test 10), so I just remove the previous comment. I will fix it and updated here.

Many thanks. Xing.

If I'm not mistake, 10 is about data out in control EP. The below could give you some hints.
Make sure you have the correct EP size too.
68b57ea

jfischer-no · 2025-11-25T15:04:34Z

+ * Copyright (C) 2025 Microchip Technology Inc. and its subsidiaries
+ *
+ * SPDX-License-Identifier: Apache-2.0


SPDX-FileCopyrightText: Copyright Microchip Technology Inc. and its subsidiaries

https://docs.zephyrproject.org/latest/contribute/guidelines.html#copyright-and-license-notices

jfischer-no · 2025-11-25T15:17:44Z

+#define ENABLE	1
+#define DISABLE	0
+
+#define SETUP_PKT_SIZE	sizeof(struct usb_setup_packet)
+
+#define EP(addr)	USB_EP_GET_IDX(addr)


I do not see any benefits having these macros, please remove them and use 1, 0, true, false, sizeof(struct usb_setup_packet), sizeof(*setup).

jfischer-no · 2025-11-25T15:22:01Z

+#define DMA(addr)	(EP(addr) - 1)
+#define MAX_DMA_LEN	((UDPHS_DMACONTROL_BUFF_LENGTH_Msk >> UDPHS_DMACONTROL_BUFF_LENGTH_Pos) + 1)
+#define BYTE_COUNT(x)	(((x) & UDPHS_EPTSTA_BYTE_COUNT_Msk) >> UDPHS_EPTSTA_BYTE_COUNT_Pos)
+#define BUSY_BANKS(x)	(((x) & UDPHS_EPTSTA_BUSY_BANK_STA_Msk) >> UDPHS_EPTSTA_BUSY_BANK_STA_Pos)
+#define BUFF_COUNT(x)	(((x) & UDPHS_DMASTATUS_BUFF_COUNT_Msk) >> UDPHS_DMASTATUS_BUFF_COUNT_Pos)


Prefix them with UDC_SAM, for those that are too long, please use following style

#define UDC_SAM_MAX_DMA_LEN \ ((UDPHS_DMACONTROL_BUFF_LENGTH_Msk >> UDPHS_DMACONTROL_BUFF_LENGTH_Pos) + 1)

jfischer-no · 2025-11-25T16:24:57Z

+	ept->UDPHS_EPTCTLENB = UDPHS_EPTCTLENB_RX_SETUP_Msk;
+}
+
+static void udphs_ep_fifo_in(udphs_ept_registers_t *const ept, int enable)


bool enable

jfischer-no · 2025-11-25T16:25:17Z

+	}
+}
+
+static void udphs_ep_fifo_out(udphs_ept_registers_t *const ept, int enable)


bool enable

jfischer-no · 2025-11-25T16:27:14Z

+static void udphs_ep_set_halt(udphs_ept_registers_t *const ept)
+{
+	ept->UDPHS_EPTSETSTA = UDPHS_EPTSETSTA_FRCESTALL_Msk;
+}
+
+static void udphs_ep_clear_halt(udphs_ept_registers_t *const ept)
+{
+	ept->UDPHS_EPTCLRSTA = UDPHS_EPTCLRSTA_TOGGLESQ_Msk |
+			       UDPHS_EPTCLRSTA_FRCESTALL_Msk;
+}


move to udc_sam_ep_set_halt/udc_sam_ep_clear_halt

Please may I keep these lines in udphs_ function?
The idea is put all register accessing related codes in the udphs_ prefixed function, and the udphs_ functions works like HAL interface function.

^ not addressed.

jfischer-no · 2025-11-25T16:29:58Z

+					   udc_ep_buf_has_zlp(buf) ? "zlp" : "");
+
+	if (buf->len == 0) {
+		udc_ep_buf_set_zlp(buf);


Why? Drivers should not use it.

I use "bi->zlp" to notify handle_ep_irq() to send a ZLP when an IN packet with "buf->len == 0" comes up.
(I don't anticipate that "buf->len == 0" and "bi->zlp == true" will come up at the same time in an IN packet.)
Or should I create a new variable to use for the notification?

I did not get it, why should a driver do something like that? There is nothing wrong with zero length IN transfer, ZLP flag is set by the stack in special cases like for control transfer handling.

Yes, it's weird to set the ZLP flag in a UDC controller driver, I have remove these code, and added the xfer_zero flag for internal use in the driver.

jfischer-no · 2025-11-25T16:30:54Z

+	return 0;
+}
+
+static void udc_ep0_internal(const struct device *dev, int enable)


static void udc_ep0_internal(const struct device *dev, const bool enable)

MCHP-MPU-Solutions-SHA · 2025-11-26T09:27:12Z

Add a report from sample/subsys/usb/testusb HS. FS is it should work like that too. A full report usually tests from 0 up to 29.

Hi Gerson, It looks like I have find a driver bug via testusb tool (in test 10), so I just remove the previous comment. I will fix it and updated here.

Many thanks. Xing.

Hi Gerson,
Is it mandatory to pass all tests?

For example, this is the test result of FIFO transfer:
(.venv) user@202:~/prj/zephyr/zephyr$ sudo /home/user/repo/linux/tools/usb/testusb -D /dev/bus/usb/001/092
/home/user/repo/linux/tools/usb/testusb: /dev/bus/usb/001/092 may see only control tests
high speed /dev/bus/usb/001/092 0
/dev/bus/usb/001/092 test 0, 0.000008 secs
/dev/bus/usb/001/092 test 1, 0.099870 secs
/dev/bus/usb/001/092 test 2, 0.041728 secs
/dev/bus/usb/001/092 test 3, 0.099842 secs
/dev/bus/usb/001/092 test 4, 0.041985 secs
/dev/bus/usb/001/092 test 5, 3.124345 secs
/dev/bus/usb/001/092 test 6, 1.549064 secs
/dev/bus/usb/001/092 test 7, 3.128929 secs
/dev/bus/usb/001/092 test 8, 1.540605 secs
/dev/bus/usb/001/092 test 9, 3.000013 secs
/dev/bus/usb/001/092 test 10, 14.000101 secs
/dev/bus/usb/001/092 test 11, 0.808519 secs
/dev/bus/usb/001/092 test 12, 3.366337 secs
/dev/bus/usb/001/092 test 13, 4.374783 secs
/dev/bus/usb/001/092 test 14 --> 22 (error 22)
/dev/bus/usb/001/092 test 17, 0.099847 secs
/dev/bus/usb/001/092 test 18, 0.041663 secs
/dev/bus/usb/001/092 test 19, 0.099832 secs
/dev/bus/usb/001/092 test 20, 0.042021 secs
/dev/bus/usb/001/092 test 21 --> 22 (error 22)
/dev/bus/usb/001/092 test 24, 2.998797 secs
/dev/bus/usb/001/092 test 27, 2.889642 secs
/dev/bus/usb/001/092 test 28, 1.256671 secs
/dev/bus/usb/001/092 test 29, 0.500043 secs

I got two errors (test 14 and 21) in the test.

Many thanks.
Xing.

nandojve · 2025-11-26T11:58:57Z

Hi Xing,

Is it mandatory to pass all tests?
Yes, you need to fix them. There is no point to introduce a driver that we already know that have problems.

MCHP-MPU-Solutions-SHA · 2025-11-30T12:50:40Z

Hi Xing,

Is it mandatory to pass all tests?
Yes, you need to fix them. There is no point to introduce a driver that we already know that have problems.

Hi Gerson,

Many thanks for your comments.
Have found the reasons for test failures:

Test 10 failure --> caused by the incorrect register setting for halting.
Test 14 & 21 failure --> testusb program internal return error, fixed by add "-v 512" parameter.

Now I passed all the tests for FS and HS, here are the logs:
(.venv) user@202:~/prj/zephyr/zephyr$ sudo ~/repo/linux/tools/usb/testusb -v 512 -D /dev/bus/usb/001/007
/home/user/repo/linux/tools/usb/testusb: /dev/bus/usb/001/007 may see only control tests
full speed /dev/bus/usb/001/007 0
/dev/bus/usb/001/007 test 0, 0.000009 secs
/dev/bus/usb/001/007 test 1, 1.125035 secs
/dev/bus/usb/001/007 test 2, 0.888940 secs
/dev/bus/usb/001/007 test 3, 0.600519 secs
/dev/bus/usb/001/007 test 4, 0.471248 secs
/dev/bus/usb/001/007 test 5, 34.465619 secs
/dev/bus/usb/001/007 test 6, 28.769883 secs
/dev/bus/usb/001/007 test 7, 17.947533 secs
/dev/bus/usb/001/007 test 8, 14.998845 secs
/dev/bus/usb/001/007 test 9, 22.000039 secs
/dev/bus/usb/001/007 test 10, 108.000363 secs
/dev/bus/usb/001/007 test 11, 3.245539 secs
/dev/bus/usb/001/007 test 12, 1.375460 secs
/dev/bus/usb/001/007 test 13, 32.000573 secs
/dev/bus/usb/001/007 test 14, 7.000321 secs
/dev/bus/usb/001/007 test 17, 1.125039 secs
/dev/bus/usb/001/007 test 18, 0.888951 secs
/dev/bus/usb/001/007 test 19, 1.124971 secs
/dev/bus/usb/001/007 test 20, 0.888945 secs
/dev/bus/usb/001/007 test 21, 7.000431 secs
/dev/bus/usb/001/007 test 24, 32.044953 secs
/dev/bus/usb/001/007 test 27, 34.133375 secs
/dev/bus/usb/001/007 test 28, 28.444466 secs
/dev/bus/usb/001/007 test 29, 4.000185 secs

(.venv) user@202:~/prj/zephyr/zephyr$ sudo ~/repo/linux/tools/usb/testusb -v 512 -D /dev/bus/usb/001/005
/home/user/repo/linux/tools/usb/testusb: /dev/bus/usb/001/005 may see only control tests
high speed /dev/bus/usb/001/005 0
/dev/bus/usb/001/005 test 0, 0.000007 secs
/dev/bus/usb/001/005 test 1, 0.097618 secs
/dev/bus/usb/001/005 test 2, 0.041882 secs
/dev/bus/usb/001/005 test 3, 0.050016 secs
/dev/bus/usb/001/005 test 4, 0.035835 secs
/dev/bus/usb/001/005 test 5, 3.108013 secs
/dev/bus/usb/001/005 test 6, 1.249468 secs
/dev/bus/usb/001/005 test 7, 1.707652 secs
/dev/bus/usb/001/005 test 8, 0.640008 secs
/dev/bus/usb/001/005 test 9, 3.000012 secs
/dev/bus/usb/001/005 test 10, 14.000102 secs
/dev/bus/usb/001/005 test 11, 3.126937 secs
/dev/bus/usb/001/005 test 12, 3.056364 secs
/dev/bus/usb/001/005 test 13, 4.373909 secs
/dev/bus/usb/001/005 test 14, 0.875131 secs
/dev/bus/usb/001/005 test 17, 0.097583 secs
/dev/bus/usb/001/005 test 18, 0.041976 secs
/dev/bus/usb/001/005 test 19, 0.097641 secs
/dev/bus/usb/001/005 test 20, 0.041673 secs
/dev/bus/usb/001/005 test 21, 0.876388 secs
/dev/bus/usb/001/005 test 24, 2.930028 secs
/dev/bus/usb/001/005 test 27, 2.859341 secs
/dev/bus/usb/001/005 test 28, 1.234557 secs
/dev/bus/usb/001/005 test 29, 0.500052 secs

Please help check.

Many thanks.
Xing.

addressed

nandojve

@jfischer-no , @JarmouniA

Is there anything open from your side?

jfischer-no · 2026-02-25T16:14:53Z

+			clocks = <&pmc PMC_TYPE_PERIPHERAL 105>, <&usb_clk>;
+			clock-names = "pclk", "hclk";
+			maximum-speed = "high-speed";
+			num-bidir-endpoints = <16>;


If the number of endpoints always 16, then do not use num-bidir-endpoints property and do not include usb-ep.yaml

This cannot be guaranteed (it is not always 16); different IP instances on the same chip may have different EP values.
I have add num_of_eps variable in udc_sam_config for taking over the "num-bidir-endpoints" from the DTS.

jfischer-no · 2026-02-25T16:19:25Z

+	.lock = udc_sam_lock,
+	.unlock = udc_sam_unlock,
+	.device_speed = udc_sam_device_speed,
+	.init = udc_sam_init,
+	.enable = udc_sam_enable,
+	.disable = udc_sam_disable,
+	.shutdown = udc_sam_shutdown,
+	.set_address = udc_sam_set_address,
+	.host_wakeup = udc_sam_host_wakeup,
+	.ep_enable = udc_sam_ep_enable,
+	.ep_disable = udc_sam_ep_disable,
+	.ep_set_halt = udc_sam_ep_set_halt,
+	.ep_clear_halt = udc_sam_ep_clear_halt,
+	.ep_enqueue = udc_sam_ep_enqueue,
+	.ep_dequeue = udc_sam_ep_dequeue,
+};


test_mode implementation is missed, 4e90b4b#r2560534330

test_mode function has been implemented.

jfischer-no · 2026-02-25T16:20:20Z

+	udphs->UDPHS_CTRL &= ~UDPHS_CTRL_DEV_ADDR_Msk;
+	if (addr != 0) {
+		udphs->UDPHS_CTRL |= UDPHS_CTRL_FADDR_EN_Msk |
+				     UDPHS_CTRL_DEV_ADDR(addr);
+	}


^ not addressed.

jfischer-no · 2026-02-25T16:20:34Z

+
+static void udphs_send_wakeup(udphs_registers_t *const udphs)
+{
+	udphs->UDPHS_CTRL |= UDPHS_CTRL_REWAKEUP_Msk;


^ not addressed.

jfischer-no · 2026-02-25T16:20:53Z

+{
+	udphs_ept_registers_t *const ept =  &udphs->UDPHS_EPT[0];
+
+	ept->UDPHS_EPTCTLENB = UDPHS_EPTCTLENB_RX_SETUP_Msk;


^ not addressed.

jfischer-no · 2026-02-25T16:29:28Z

+
+		udc_ep0_internal(dev, 1);
+		udc_submit_event(dev, UDC_EVT_RESET, 0);
+	}


SOF interrupts are missed.

SOF event report function has been added.

jfischer-no · 2026-02-25T16:34:04Z

+		data->caps.hs = true;
+	}
+
+	for (i = 0; i < UDPHS_EPT_NUMBER / 2; i++) {


How I understood, there are 16 "hw endpoint blocks".
Each of these "hw" endpoints can be IN or OUT?
Or are there 8 dedicated IN endpoints and 8 dedicated OUT endpoints?
Or are there 16 "hw" endpoints that can handle up to 16 IN and 16 OUT endpoints?

Yes, I DO want to discuss about these weird codes.
There are 16 EPs in an UDPHS instance:
EP0 --> control endpoint, Bidirectional (IN and OUT)
EP1 ~ EP15 --> data endpoint, Unidirectional (IN or OUT), must be configured as IN or OUT before using.
(May I say that the EP0 is full-duplex and EP1 ~ EP15 is half-duplex?)

For EP1 ~ EP15, once an EP has been configured as IN, then it can not be used as OUT at the same time, the reverse is also true.
So I have to register these EPs in this way.

Please what does the "num-bidir-endpoints" mean in the usb-ep.yaml?
Does it mean the number of bidirectional EPs?
Or it means the number of EPs which can be configured as IN or OUT?

Many thanks.

jfischer-no · 2026-02-25T16:37:06Z

+		}
+	}
+
+	if (udc_ctrl_stage_is_setup(dev)) {


That does not seem to be right. Why do you need to always check it?

In the last commit, the Setup package cannot be processed in time, so I disable the Setup package interrupt until the current one is finished.

With this rebase, issue cannot be reproduced anymore, and this code has been removed.

jfischer-no · 2026-02-25T16:37:42Z

+			}
+		}
+
+		if ((udc_ctrl_stage_is_setup(dev)) && (buf->data)) {


What happens here?

caps.out_ack has bee set to "true" in this UDC driver, in the last commit, the udc_ctrl_update_stage() won't help to free the allocated buffer, then I have to free it manually.

With this rebase, issue cannot be reproduced anymore, and this code has been removed.

jfischer-no · 2026-02-25T16:43:17Z

 	return udc_submit_ep_event(dev, buf, 0);
 }

+bool udc_ctrl_stage_is_setup(const struct device *dev)


I looked how you used it in the driver and it looks a bit fishy. I doubt this function is needed. You could move it to your driver for now. This part is likely to be reworked anyway.

This code has been removed.

github-actions · 2026-03-28T00:54:26Z

This pull request has been marked as stale because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 7 days. Note, that you can always re-open a closed pull request at any time.

nandojve · 2026-03-29T09:10:34Z

Hi @MCHP-MPU-Solutions-SHA ,

Could you rebase and address the messages?
Now, you need adapt the driver to due to the #103493 and #100876

Update mmu region for udphsa and udphsb, add usb phy clock configuration Signed-off-by: CHEN Xing <xing.chen@microchip.com>

MCHP-MPU-Solutions-SHA · 2026-04-14T09:50:30Z

Hi @MCHP-MPU-Solutions-SHA ,

Could you rebase and address the messages? Now, you need adapt the driver to due to the #103493 and #100876

Hi Gerson,

This PR has been rebase and re-fine for #103493 and #100876.
Please help to review again.
Many thanks.

MCHP-MPU-Solutions-SHA · 2026-04-14T10:52:32Z

Hi @jfischer-no,

Thank you very much for the very good reference driver udc_sam0.c, it has greatly accelerated our progress.
This PR has bee rebase, please help to review again.
Many thanks.

nandojve

Is the the same UDPHS from Arduino Due?
If that is the case, could you add the entries for that board too?

nandojve · 2026-04-19T14:12:03Z

+# SPDX-License-Identifier: Apache-2.0
+#
+
+description: Microchip SAM UDPHS USB Device High Speed Port


Add examples entry:

zephyr/dts/bindings/usb/atmel,sam-udp.yaml

Lines 21 to 40 in 7bbe9da

examples:

- |

Example devicetree configuration:

&pinctrl {

udp_default: udp_default {

group1 {

pinmux = <PB10S_UDP_DDM>,

<PB11S_UDP_DDP>;

};

};

};

zephyr_udc0: &udp {

status = "okay";

pinctrl-0 = <&udp_default>;

pinctrl-names = "default";

};

Example for dts file has been added.

Add udphsa udphsb udc devices to sama7g5 Signed-off-by: CHEN Xing <xing.chen@microchip.com>

Add driver for sama7g5 UDPHS Signed-off-by: CHEN Xing <xing.chen@microchip.com>

Add udphs udc devices and enable udphsa Signed-off-by: CHEN Xing <xing.chen@microchip.com>

MCHP-MPU-Solutions-SHA · 2026-04-20T03:38:43Z

Is the the same UDPHS from Arduino Due? If that is the case, could you add the entries for that board too?
I google it and found that SAM3X8E was used on this board, then downloaded the SAM3X8E datasheet from microchip.com.
In the datasheet, I couldn't found a USB controller with name UDPHS.
And UOTGHS was used by SAM3X8E, but its registers are not compatible with UDPHS.

Please correct me if there is issue.

sonarqubecloud · 2026-04-20T03:55:04Z

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
1.6% Duplication on New Code

See analysis details on SonarQube Cloud

nandojve

LGTM!

zephyrbot added platform: Microchip MEC Microchip MEC Platform area: USB Universal Serial Bus area: Devicetree Bindings area: Boards/SoCs platform: Microchip SAM Microchip SAM Platform (formerly Atmel SAM) labels Nov 19, 2025

zephyrbot requested review from ArunMCHP, VenkatKotakonda, albertofloyd, jfischer-no, josuah, jvasanth1, nandojve, pdgendt, stephanosio and tmon-nordic November 19, 2025 01:59

zephyrbot assigned jfischer-no Nov 19, 2025

tmon-nordic reviewed Nov 19, 2025

View reviewed changes

MCHP-MPU-Solutions-SHA force-pushed the sama7g5_udphs branch 2 times, most recently from 347563c to 5a56317 Compare November 20, 2025 07:08

nandojve added this to the v4.4.0 milestone Nov 20, 2025

nandojve requested changes Nov 20, 2025

View reviewed changes

MCHP-MPU-Solutions-SHA force-pushed the sama7g5_udphs branch from 5a56317 to 9ca0f9a Compare November 24, 2025 06:40

MCHP-MPU-Solutions-SHA requested a review from nandojve November 24, 2025 06:41

jfischer-no requested changes Nov 25, 2025

View reviewed changes

MCHP-MPU-Solutions-SHA force-pushed the sama7g5_udphs branch from 9ca0f9a to e0daa34 Compare November 30, 2025 12:20

nandojve mentioned this pull request Feb 13, 2026

samples: subsystem: usb: udc: Add multi-instance initialization #103844

Closed

nandojve changed the title ~~Sama7g5 USB UDC (UDPHS) driver~~ drivers: usb: udc: Add UDPHS driver Feb 14, 2026

nandojve previously approved these changes Feb 14, 2026

View reviewed changes

jfischer-no requested changes Feb 25, 2026

View reviewed changes

github-actions Bot added the Stale label Mar 28, 2026

nandojve removed the Stale label Mar 28, 2026

nandojve modified the milestones: v4.4.0, v4.5.0 Mar 29, 2026

soc: microchip: sam: sama7g5: update mmu for udphs

9db9f09

Update mmu region for udphsa and udphsb, add usb phy clock configuration Signed-off-by: CHEN Xing <xing.chen@microchip.com>

MCHP-MPU-Solutions-SHA dismissed nandojve’s stale review via cad6a5e April 14, 2026 09:28

MCHP-MPU-Solutions-SHA force-pushed the sama7g5_udphs branch from be8eb81 to cad6a5e Compare April 14, 2026 09:28

zephyrbot added the platform: Microchip PIC32 label Apr 14, 2026

zephyrbot requested review from NhMchp, jfischer-no and nandojve April 14, 2026 09:30

MCHP-MPU-Solutions-SHA force-pushed the sama7g5_udphs branch from cad6a5e to 98ff77b Compare April 14, 2026 09:43

nandojve requested changes Apr 19, 2026

View reviewed changes

MCHP-MPU-Solutions-SHA added 3 commits April 20, 2026 11:16

dts: arm: microchip: sam: add udc device to sama7g5

015a003

Add udphsa udphsb udc devices to sama7g5 Signed-off-by: CHEN Xing <xing.chen@microchip.com>

driver: usb: udc: add support for sama7g5 UDPHS

f4f866d

Add driver for sama7g5 UDPHS Signed-off-by: CHEN Xing <xing.chen@microchip.com>

boards: microchip: sam: sama7g54_ek: enable udc device

0f08eb4

Add udphs udc devices and enable udphsa Signed-off-by: CHEN Xing <xing.chen@microchip.com>

MCHP-MPU-Solutions-SHA force-pushed the sama7g5_udphs branch from 98ff77b to 0f08eb4 Compare April 20, 2026 03:23

zephyrbot requested a review from nandojve April 20, 2026 03:24

nandojve approved these changes Apr 20, 2026

View reviewed changes

		USB packets system data bursts will be locked for
		maximum optimization of the bus bandwidth usage.


		compatible: "microchip,sam-udphs"

		include: [usb-ep.yaml, pinctrl-device.yaml]

	include:
	- name: ethernet-controller.yaml
	- name: pinctrl-device.yaml

	examples:
	- \|
	Example devicetree configuration:

	&pinctrl {
	udp_default: udp_default {
	group1 {
	pinmux = <PB10S_UDP_DDM>,
	<PB11S_UDP_DDP>;
	};
	};
	};

	zephyr_udc0: &udp {
	status = "okay";

	pinctrl-0 = <&udp_default>;
	pinctrl-names = "default";
	};

Conversation

MCHP-MPU-Solutions-SHA commented Nov 19, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nandojve left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

MCHP-MPU-Solutions-SHA commented Nov 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nandojve commented Nov 24, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MCHP-MPU-Solutions-SHA commented Nov 26, 2025

Uh oh!

nandojve commented Nov 26, 2025

Uh oh!

MCHP-MPU-Solutions-SHA commented Nov 30, 2025

Uh oh!

nandojve left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

MCHP-MPU-Solutions-SHA commented Nov 24, 2025 •

edited

Loading

MCHP-MPU-Solutions-SHA Apr 14, 2026 •

edited

Loading