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. > 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
