Re: Generic-xhci driver issue and changes for 64-but physical memory space
Date: Thu, 29 Jul 2021 14:13:32 UTC
On Thu, 29 Jul 2021 11:20:13 +0000 Sha Faisal via freebsd-hackers <freebsd-hackers@FreeBSD.org> wrote: > Mailing to freebsd-hackers, after adding my email id to subscriber list. > Please assist with the below query. > > Regards > Faisal > > From: Sha Faisal <sfaisal@juniper.net> > Date: Thursday, 29 July 2021 at 12:19 AM > To: "hackers@freebsd.org" <hackers@freebsd.org> > Cc: Justin Hibbits <jhibbits@juniper.net>, Kumara N Babu <bkumara@juniper.net>, Vikram M Gadagkar <vikramg@juniper.net> > Subject: Generic-xhci driver issue and changes for 64-but physical memory space > > Hello FreeBSD-hackers > > Inn one of our new platforms we have physical RAM placed above the 4GB mark. > And the eUSB device is capable of doing 64-bit DMA. > > The USBPHY uses the generic-xhci driver and when we were bringing-up we hit the issue below and the code panics > > xhci0: <Marvell Integrated USB 3.0 controller> mem 0x10243000-0x10243fff irq 15 on simplebus1 > xhci0: 64 bytes context size, 32-bit DMA > panic: vm_wait in early boot > > I modified the below function call , and the usb driver is up and it works fine. Please suggest if this change is fine and can be incorporated. > > > #define IS_DMA_32B 1 > > #define IS_DMA_64B 0 > > > err = xhci_init(sc, dev, IS_DMA_64B); > As a locally maintained patch this would be acceptable. But I greatly doubt that this change would make it into the source tree as written. Since the generic-xhci driver knows basically nothing about the hardware it takes the conservative approach of always using 32-bit DMA. Strangely enough, the code in xhci.c, which tries to determine the DMA size by reading a register in the controller, thinks that this controller only supports 32-bit DMA. If I were the maintainer of this code the only way I would allow this change would be if it used the pci register values unique to this controller to set the dma32 flag in xhci_init() to 0 and otherwise keep the default value of 1. -- Gary Jennejohn