> From: Matthijs Kooijman [mailto:matthijs@xxxxxxxx] > > > These are the core parameters that I think are needed right now: > > > > dma_enable > > dma_desc_enable > > host_rx_fifo_size > > host_nperio_tx_fifo_size > > host_perio_tx_fifo_size > > max_transfer_size > > max_packet_count > > host_channels > > > > phy_type > > phy_utmi_width > > phy_ulpi_ddr > > phy_ulpi_ext_vbus > > i2c_enable > > ulpi_fs_ls > > host_support_fs_ls_low_power > > host_ls_low_power_phy_clk > > > > The last 8 are related to the Phy. I wonder if they should be in a > > separate Phy dt file? > > Looking at the dwc3 driver, it can have a "usb-phy" phandle property in > its dt node that points to a different phy node in the dt, possibly with > a different driver. However, all of the glue drivers default the phy to > a nop_usb_xceiv phy driver, which is basically a noop driver AFAICS. > > I'm not sure if the dwc2 hardware could ever be connected to an external > PHY that actually needs a driver? Or does the dwc2 core do all the > talking to the PHY and are these parameters just to tell the core how to > talk to the PHY? The Phy implementation is up to the system designer. But yes, the parameters we are talking about are to tell the core how to talk to the Phy. So maybe they do belong in the core's dt file. (I don't know anything about how the dt stuff is supposed to work.) > As you might gather from the above, I'm not really in the loop about how > the hardware works here, so I don't think I'm qualified to decide on the > best approach here... Perhaps I should adapt my patch to just the > non-phy related parameters and we can do the phy-stuff later when it is > clear how they should work? That won't work. The Phy parameters have to be set according to the type of Phy that is connected, and some of them cannot be autodetected. So they have to be defined somewhere. Felipe, do you have any ideas about this? -- Paul -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
