On Fri, Oct 27, 2023 at 04:47:24PM +0200, Elinor Montmasson wrote: > Hello, > > This is the v2 of the series of patch aiming to make the machine driver fsl-asoc-card compatible with use cases where there is no real codec driver. It proposes to use the spdif_receiver and spdif_transmitter drivers instead of the dummy codec. Please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to. > * Part of the dai_fmt variable hold information on the codec provider > or consumer status for bit/frame clocks. In patch 03/10, as we add > compatibility for multiple codecs, we make the test about bit/frame > clock provider only check with codec[0]. That way we assure > compatibility with all already existing compatibles. As it was never > intended before to have multiple codecs for this test, is there a > better way to handle it ? Should we make this test check if any codec > is clock provider ? Or should we let codec[0] be the default > possibility ? That way, future compatibles that could encounter this > specific case with multi-codecs should adapt the test for their needs. Yes, we should be checking all the CODECs - existing bindings that only have a single CODEC should work fine since they shouldn't have additional CODECs but it's possible that a device other than the first one found may be providing the clocks. > Documentation: fsl-asoc-card: add documentation for generic codec case Please submit patches using subject lines reflecting the style for the subsystem, this makes it easier for people to identify relevant patches. Look at what existing commits in the area you're changing are doing and make sure your subject lines visually resemble what they're doing. There's no need to resubmit to fix this alone.
Attachment:
signature.asc
Description: PGP signature
