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@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.