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. Best regards, Krzysztof
