On Wed, May 27, 2015 at 10:26 AM, Mark Brown broonie@kernel.org wrote:
On Tue, May 26, 2015 at 09:22:53PM -0700, Dylan Reid wrote:
On Tue, May 26, 2015 at 1:14 PM, Mark Brown broonie@kernel.org wrote:
The only things that concerned me particularly were the name (which I did agree on once you mentioned it) and the use of a bitmask to describe what's being reported but it's hard to think of anything much better than that.
Is just "audio-jack" too generic? There are a lot of audio jacks that wouldn't be described by this binding, such as those reported by the 227e or 5650. The original goal here was to describe a jack that has
I think it's fine - I think we can use this as a jack object and have other things reference it to supply additional detection mechanism. Lars' point about jacks not just being for audio is a valid one, though.
one or more gpios, each representing a particular type of device being attached. This doesn't overlap with the binding for a jack that is handled by a headset detect chip. Does this seem like the right goal, or is there a benefit to having an "audio-jack" binding that tries to cover all different types of jacks?
So like I say I was thinking that either the jack object has a list of detection method phandles which point to other devices or the other devices point at the jack object.
I might not be completely following this. Do we want to create a binding for the physical plug and another for the method used to detect the if a device is attached?
What is the benefit in separating the plug from the detection method, these seem pretty tightly bound to me. There are three main types of detection for headsets, gpio, ADC measurement, and offload to a codec or HP chip. Are there situations where those would change separate from how the jack is connected?