Hi Rob,
On Lu, 2019-01-21 at 09:23 -0600, Rob Herring wrote:
On Fri, Jan 18, 2019 at 11:46:42AM -0800, Nicolin Chen wrote:
On Fri, Jan 18, 2019 at 01:16:24PM +0000, Viorel Suman wrote:
- Moved "dais" node from machine driver DTS node to device
driver DTS node as suggested by Rob.
That was not what I suggested. You still have a virtual node which looks to me to be unnecessary.
To me removing virtual node implies that AUDMIX machine driver (imx- audmix.c + virtual node) shall be removed and machine driver code merged into device driver (fsl_audmix.c + device node) - please let me know if my understanding is wrong.
We could use a non-DT configuration right? From the driver logic, DT just registers a device corresponding to the machine driver so that it can probe(). We could register one in fsl_audmix instead. Please refer to how fsl_ssi registers the sound card device. The machine driver can get audmix_np from the parent device pointer, and I think that's all you need.
Yes.
Thank you, sent V4 which implements the approach suggested by Nicolin.
Or maybe someone else would provide a better way. But it'd work.
Or the machine driver could create the audmix device. That probably makes less sense, but either way there doesn't have to be a 1-1 correspondence of DT nodes and (platform) devices.
I'm not an ASoC expert, but why can't the machine driver just control the audmix directly (with DAIs as separate drivers)? Is the audmix ever going to a be a component for a different machine driver?
Rob
Currently I'm not aware of any information with regard to if audmix is ever going to work with other DAIs than SAI. Howerver from audmix IP block integration perspective the only requirement is that the input DAI must be connected to audmix over I2S bus, possible DAI options are SAI, ESAI, etc - I think the approach to mix both device and machine drivers into a single entity is not the best way to go.
/Viorel