[alsa-devel] [PATCH] ASoC: nau8825: Add driver for headset chip Nuvoton 8825

[Mark Brown]

On Thu, Aug 13, 2015 at 12:44:33PM -0700, Anatol Pomozov wrote:
> On Thu, Aug 13, 2015 at 4:26 AM, Mark Brown <broonie at kernel.org> wrote:

> > No, that is not the case at all - what makes you claim that devm_clk_get()
> > is DT specific?

> clk_dev uses of_clk_get_by_name() that is implemented for DTS only.
> See include/linux/clk.h.

That means that the clock API can work with DT, not that DT is
mandatory - notice how there are stubs for the non-DT case.

> ACPI has a compatible API for getting simple properties
> (strings/numbers), but no API for dealing with clocks.

So ACPI based platforms have to deal with providing clocks in some other
way, that's something that is abstracted away by the clock API.  There
are a number of drivers for both board file based and ACPI based systems
already in tree which manage to make use of the clock API.

> > I very much doubt that this will be a problem for all boards.  To repeat
> > what I said in my previous reply:

> > | The assumption would be that if the system doesn't have or need jack
> > | detection then the jack pins won't be reconfigurable anyway.

> > Your board may be wired up with jack detection configured in a way that
> > needs this, I would be surprised if all boards were.

> I am still trying to understand the use-case for NAU8825 without jack
> detection functionality. Are you talking about a board configuration
> that does not wire jack to JKDET codec pin and (maybe) statically
> connects output to speakers?

I'm not specifically familiar with this CODEC, however this sort of
detection circuitry is all pretty standard.  I'm thinking of the sort of
straightforward configurations where the detection inputs and any
outputs required to flip polarity of the jack are just not wired up.

> If platform driver does not enable jack detection, what NAU8825
> functionality suppose to work? Does output (HPL/HPR) suppose to work?
> Does mic suppose to work? Is OMTP/CTIA mic detection functionality
> needed?

I'd expect the detection functionality wouldn't work without being wired
up as expected but I'd expect it to be perfectly possible to support the
headphones with the default ground confirguration.  I'd also expect mics
to work, either connected to the headset with a fixed polarity or just
elsewhere in the system.  If the device is capable of supprorting
headphones it must be capable of supporting them with a fixed ground,
and similarly for microphones.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20150813/d6d08c83/attachment.sig>