Understood Mark, I apologize for any erroneous comments, as I am the hardware engineer not the driver author. I will stay out of the actual driver implementation as some of the notes I added may have been platform specific implementation (integration) and not core driver functionality. Our software engineer can clarify any questions or concerns with the core driver (I believe he is currently reviewing the proposed patch).
The key information I needed to add from a hardware side was the full functionality of the digital microphone enable bits. I was concerned, and wanted to insure any changes reflected that they are primarily enables (and are not just MUX control bits) and that they need to operate in tandem for proper hardware configuration. To that end I hope the valid use cases are helpful to the continuing development. Thank you for your feedback, and I apologize for any odd formatting. It looks like all correspondence is in plain text and I was using HTML. Matthew Mowdy -----Original Message----- From: Mark Brown [mailto:broo...@kernel.org] Sent: Thursday, May 16, 2013 10:53 AM To: Matthew Mowdy Cc: abres...@chromium.org; lgirdw...@gmail.com; pe...@perex.cz; ti...@suse.de; Sachin Kamat; Kuninori Morimoto; Dylan Reid; linux-kernel@vger.kernel.org; Ralph Birt; Evan Ragsdale Subject: Re: [PATCH] ASoC: max98090: add digital mic mux to record path On Wed, May 15, 2013 at 09:10:23PM -0700, Matthew Mowdy wrote: Sorry, didn't manage to find the content I meant to reply to in here due to the formatting issues I mentioned in my mail and the enormous reams of datsheet that were pasted in. Anyway.... > Default Routing: > Of note (software can confirm) I believe the default DAPM routing for the > driver was intentional setup such that : This indicates that the driver is broken, the driver should be using the chip defaults. > Record: > o If a headset MIC is present, record from it. > > o If not, digital MIC is the default record input. This is a bug, the driver should not be making any automatic routing decisions. The behaviour you describe would break some fairly obvious use cases like speakerphone while headset is connected. > Playback: > o When headphones are detected, playback is through the headphone output. > o When headphones are not present, playback was through the speaker outputs. Similarly here, this is junk. > The defaults can be modified by each end user as needed (for analog > microphones, line inputs, etc.). Please insure any patch to the > baseline driver reflects the correct operation of the digital > microphone enable bits, and preserves the intended default operation. No, this is stupid and will be buggy. The register default values need to reflect the silicon defaults, the frameworks (both ASoC and regmap) do things like suppress writes that have no effect and rely on knowing the silicon defaults for that. The framework already allows the application layer to configure the device through the controls exposed to userspace, if people need to modify a CODEC driver for their system that reflects a problem in the CODEC driver. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
