Re: [PATCH v6 3/4] ASoC: dt-bindings: fsl-sai: allow only one dma-names

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Fri, Mar 08, 2024 at 03:21:14PM -0500, Frank Li wrote:
> On Fri, Mar 08, 2024 at 02:06:08PM -0500, Frank Li wrote:
> > On Fri, Mar 08, 2024 at 04:58:16PM +0000, Conor Dooley wrote:
> > > On Fri, Mar 08, 2024 at 10:30:52AM -0500, Frank Li wrote:
> > > > Some sai only connect one direction dma (rx/tx) in SOC. For example:
> > > > imx8qxp sai5 only connect tx dma channel. So allow only one "rx" or "tx"
> > > > for dma-names.
> > > > 
> > > > Remove description under dmas because no user use index to get dma channel.
> > > > All user use 'dma-names' to get correct dma channel. dma-names already in
> > > > 'required' list.
> > > > 
> > > > Acked-by: Conor Dooley <conor.dooley@xxxxxxxxxxxxx>
> > > > Signed-off-by: Frank Li <Frank.Li@xxxxxxx>
> > > 
> > > Please drop my ack from this, this isn't the patch I acked originally
> > > and we were having a conversation as recently as yesterday on v4 about
> > > this patch because Rob didn't like this approach. His suggestion is
> > > better than the one I gave on v4 that you have used here.
> 
> I paste your comments here
> 
> "What I suggested is different, it is more permissive than what you have
> or what Rob suggested. Your original one allows
> "rx", "tx" OR "rx" OR "tx"
> Rob's allows the same but with a nicer syntax. What that stm binding I
> mentioned allows is
> "rx", "tx" OR "tx", "rx" OR "rx" OR "tx"
> "
> 
> Actually:
> 
> "rx", "tx" OR "tx", "rx" OR "rx" OR "tx" is exactly what we want.

No, it is not.

> "rx", "tx" OR "rx" OR "tx" is only feasible, but not perfect. Why need
> limited "rx" and "tx" order? 

First, that's exactly what the binding already had. Why loosen it? 
Second, defined order is just the DT way. There is less reason to 
support both ways. It is simpler for a client to read properties if it 
knows the position of entries.


> It just bring us some noise and no actual
> value to do that.
> 
> Frank
> 
> 
> > 
> > Why do you think Rob don't like this approach? He just said this is 3rd
> > method. And it is simple enough and match all restriction.

I don't like the approach. Clear enough?

Rob




[Index of Archives]     [Pulseaudio]     [Linux Audio Users]     [ALSA Devel]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux