On 08/02/2024 22:20, Frank Li wrote: > On Tue, Jan 30, 2024 at 05:10:54PM +0100, Krzysztof Kozlowski wrote: >> On 30/01/2024 16:20, Frank Li wrote: >>> On Tue, Jan 30, 2024 at 08:40:29AM +0100, Krzysztof Kozlowski wrote: >>>> On 29/01/2024 18:41, Frank Li wrote: >>>>> On Mon, Jan 29, 2024 at 04:49:21PM +0000, Conor Dooley wrote: >>>>>> On Mon, Jan 29, 2024 at 10:19:24AM -0500, Frank Li wrote: >>>>>>> On Tue, Jan 23, 2024 at 05:23:53PM -0500, Frank Li wrote: >>>>>>>> On Tue, Jan 23, 2024 at 10:46:39PM +0100, Krzysztof Kozlowski wrote: >>>>>>>>> On 23/01/2024 20:22, Frank Li wrote: >>>>>>>>>> On Tue, Jan 23, 2024 at 06:42:27PM +0000, Conor Dooley wrote: >>>>>>>>>>> On Tue, Jan 23, 2024 at 01:02:21PM -0500, Frank Li wrote: >>>>>>>>>>>> On Tue, Jan 23, 2024 at 05:51:48PM +0000, Conor Dooley wrote: >>>>>>>>>>>>> On Tue, Jan 23, 2024 at 12:49:27PM -0500, Frank Li wrote: >>>>>>>>>>>>>> On Tue, Jan 23, 2024 at 05:27:13PM +0000, Conor Dooley wrote: >>>>>>>>>>>>>>> On Tue, Jan 23, 2024 at 12:02:05PM -0500, Frank Li wrote: >>>>>>>>>>>>>>>> Add device tree binding allow platform overwrite default value of *REQIN in >>>>>>>>>>>>>>>> GSBUSCFG0. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Why might a platform actually want to do this? Why does this need to be >>>>>>>>>>>>>>> set at the board level and being aware of which SoC is in use is not >>>>>>>>>>>>>>> sufficient for the driver to set the correct values? >>>>>>>>>>>>>> >>>>>>>>>>>>>> In snps,dwc3.yaml, there are already similary proptery, such as >>>>>>>>>>>>>> snps,incr-burst-type-adjustment. Use this method can keep whole dwc3 usb >>>>>>>>>>>>>> driver keep consistent. And not all platform try enable hardware >>>>>>>>>>>>>> dma_cohenrence. It is configable for difference platform. >>>>>>>>>>>>> >>>>>>>>>>>>> When you say "platform", what do you mean? I understand that term to >>>>>>>>>>>>> mean a combination of board, soc and firmware. >>>>>>>>>>>> >>>>>>>>>>>> In my company's environment, "platform" is "board". I will use "board" in >>>>>>>>>>>> future. Is it big difference here? >>>>>>>>>>> >>>>>>>>>>> Nah, that's close enough that it makes no difference here. >>>>>>>>>>> >>>>>>>>>>> I'd still like an explanation for why a platform would need to actually >>>>>>>>>>> set these properties though, and why information about coherency cannot >>>>>>>>>>> be determined from whether or not the boss the usb controller is on is >>>>>>>>>>> communicated to be dma coherent via the existing devicetree properties >>>>>>>>>>> for that purpose. >>>>>>>>>> >>>>>>>>>> Actually, I am not very clear about reason. I guest maybe treat off power >>>>>>>>>> consumption and performance. >>>>>>>>>> >>>>>>>>>> What's your judgement about proptery, which should be in dts. Such as >>>>>>>>>> reg, clk, reset, dma and irq, which is tighted with SOC. It is the fixed >>>>>>>>>> value for every SOC. The board dts never change these. >>>>>>>>> >>>>>>>>> Then it can be deduced from the compatible and there is no need for new >>>>>>>>> properties. >>>>>>>> >>>>>>>> Okay, I think "*reqinfo" match this. When new Soc(using compatible dwc usb >>>>>>>> controller) appear regardless dma-cohorence or not, connect by AXI3 or >>>>>>>> AXI4, needn't add new propterties. >>>>>>> >>>>>>> Anyone have objection? I will prepare v2 to fix rob's bot error. >>>>>> >>>>>> I'm not sure what you want me to object to/not object to. >>>>>> Your last message said "needn't add new propterties", seemingly in >>>>>> agreement with Krzysztoff saying that it can be deduced from the >>>>>> compatible. That seems like a good way forward for me. >>>>> >>>>> Okay, let me clear it again. dwc usb is quite common IP. The below is >>>>> what reason why need "*reginfo* instead of using compatible string. >>>>> >>>>> 1. *reginfo* property is decscript hardware behevior, which will be changed >>>>> at difference SOC. >>>>> 2. it may change at board level according to if enable dma coherence. >>>> >>>> dma coherence is not a board property. Anyway, you said it will never >>>> change in the board. >>> >>> Sorry, let's correct what my previous said. There are two kinds bus in >>> system, one is dma_coherence, the other is none dma_coherence. There are >>> some dwc usb core ip, which is the exact the same. Some connect to >>> dma_coherence bus, some connect to non-dma_coherence bus. >>> >>> So dma_coherence will be varible for this case. we need set *reginfo* for >>> dwc usb core, which connnect to dma_coherence bus. not set "reginfo* for >>> the dwc usb core, which connect to none dma_coherence bus. >> >> OK, that makes sense. Please provide link to upstream DTS >> (mainline/next/lore link/other upstream projects) showing this. > > Look like I still have not found the real case yet. But I think it is > existed (maybe not upstream yet). Can I forward using this method? No, because downstream code does things wrong and does not follow basic principles... Best regards, Krzysztof
