On Sat, Mar 02, 2024 at 10:23:16AM -0600, Sam Protsenko wrote: > On Sat, Mar 2, 2024 at 3:36 AM Tudor Ambarus <tudor.ambarus@xxxxxxxxxx> wrote: > > > > > > > > On 01.03.2024 22:42, Mark Brown wrote: > > > On Fri, Mar 01, 2024 at 01:28:35PM -0600, Sam Protsenko wrote: > > >> On Fri, Mar 1, 2024 at 5:55 AM Tudor Ambarus <tudor.ambarus@xxxxxxxxxx> wrote: > > > > > >>> Since the addition of the driver in 2009, the driver selects between DMA > > >>> and polling mode depending on the transfer length - DMA mode for > > >>> transfers bigger than the FIFO depth, polling mode otherwise. All > > >>> versions of the IP support polling mode, make the dma properties not > > >>> required. > > > > > >> AFAIU, the device tree has nothing to do with drivers, it's about > > >> hardware description. Does making DMA properties not required here > > > > correct > > > > >> mean that there are some HW out there which doesn't integrate DMA in > > > > no, to me it means that the IP can work without DMA, only in PIO mode, > > regardless if DMA is integrated or not. Not required means that the > > property is not mandatory, which is what I'm trying to achieve here. > > > > >> SPI blocks? Even if this change is ok (I'm not sure), the > > >> argumentation doesn't look sound to me. > > > > switching to PIO mode in the driver for sizes smaller than FIFO depths > > in the driver guarantees that all existing compatibles support PIO mode. > > > > Are you saying that if there is a physical line between an IP and DMA > > controller, then the DMA properties must always be specified in dt? I > > thought they can be marked as optional in this case, and that's what I > > did with this patch. > > > > No, I would wait for maintainers to clarify on that bit. Change itself > can be ok. But the commit message shouldn't mention the driver, > because the driver uses (depends on) device tree, not vice versa. The > device tree can be used in other projects as well (like U-Boot and > OP-TEE), so it should be designed to be universal and not depend on > kernel drivers. The commit message should be based on particular HW > layout features and how the patch makes the bindings describe that HW > better. It shouldn't rely on driver implementations. If the controller is DMA capable then it should have dma properties. The compatible should be enough to tell if it is a case of 'can only work with DMA'. Otherwise, it is going to be up to a specific user. Even within Linux, you may have a serial port that doesn't use DMA for the console, but uses it for the tty or serdev. Of course, if a new device is added without DMA properties and they are added later on, then they are going to be optional even though the DMA support is always there. I can't fully understand everyone's h/w. Rob
