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. If use difference compatible string, that's means using difference compatible string to descript one same hardware. You reject this method at my svc-i3c-master\svc-i3c-target patches. Frank > > > 3. dwc core part is quite common, all SOC using common "snps, dwc3" as > > core-part, all soc specific "nxp, dwc3 *", "qcom, dwc3*" is used for glue > > logic part. > > And all should be having dedicated compatibles. > > > 4. using *reginfo* can reduce add more strange compatible string such as > > "nxp, dwc3-core" ... > > 5. *reginfo* property likes "reg", "clk", and align what Kryzystoff said. > > "reg", "clk" is fixed for specfic SOC. These can help reduce "compatible" > > string number. "reginfo" do the same work as "reg", "clk" .. > > So again, reginfo is fixed for specific SoC? So it can be deduced from > compatible. > > I don't know what to say more here... so let's be clear that you > understood me: > > NAK > > Best regards, > Krzysztof >
