On 11/22/2017 10:24 AM, Mathias Nyman wrote: > On 22.11.2017 02:07, Adam Wallis wrote: >> On 11/21/2017 3:06 PM, Rob Herring wrote: >> >> [..] >> >>>> I like where you are going with this. Are you saying that I could read for a >>>> device property read from firmware (for DTB or ACPI) like DWC3 does for >>>> "snps,hird-threshold"? >>> >>> Is that for the same thing? If so, drop the vendor prefix and use >>> that. Otherwise, a separate property should really be something that >>> is per board rather than per SoC. >> >> I don't think that's exactly the same property, but it's the same idea I would >> prefer to go with. That way, an integer can be passed in via the firmware tables. >> >>> >>>> If you mean this, where do you recommend I store the >>>> desired IRQ_CONTROL value - in struct xhci_hcd ? >>> >>> No idea. >>> >>>> Or by "compatible" strings, did you mean storing hard-coded values in the >>>> of_device_id usb_xhci_of_match[] array? This would still be hard-coding >>>> (which I >>>> would like to avoid) and also would not work for the ACPI case. >>> >>> ACPI has match tables too? >>> >> >> Yes, you can use DSD in a way that is similar to OF properties >> >>> It would only be hardcoded per compatible which should be per SoC. Do >>> you need per board/device tuning? If so, use a property. >>> >> >> The reason why I think it should dynamic via firmware tables is that >> >> * It's much less invasive for vendors to update their DT tables if they need to >> adjust on a per device/controller/family/etc basis then to adjust a properties >> table in xhci-plat >> * This would lead to less polluting in xhci-plat code >> >>> Rob >>> -- >>> 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 >>> >> >> I will provide an updated proposed patch sometime this week. I also hope to get >> some feedback from Mathias to see what he prefers. > > We know have at least two hosts/platforms that need custom interrupt moderation > values > > How about adding a u32 device property for xhci with the interrupt moderation > interval in > nanoseconds? And also add a u32 imod_interval variable to struct xhci_hcd? > > imod_interval can be set to the current default 40000ns (160*250ns) and > overwritten if > device_property_read_u32() returns something else. > > XHCI_MTK_HOST could then use whatever preferred device propery interval value, > and we can get rid of using XHCI_MTK_HOST quirk flag when setting up the IMODI > > -Mathias > This sounds excellent Mathias. Let me put together a patch along these lines. Thanks for the feedback! Adam > > -- > 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 -- Adam Wallis Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- 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
