mbox series

[00/17] Add Headphone Detection to TLV320AIC31xx Driver

Message ID 20171109002741.10897-1-afd@ti.com
Headers show
Series Add Headphone Detection to TLV320AIC31xx Driver | expand

Message

Andrew Davis Nov. 9, 2017, 12:27 a.m. UTC
Hello all,

This series has the end goal of adding headphone detection to
the tlv320aic31xx driver. The first few patches are mostly cleanups.
Then a couple bug fixes I noticed. Followed by adding interrupt
handling and finally headphone detection.

The last two, as their commit name recommends, should not be taken and
are included in-case someone wants to evaluate headphone detection
using the EVM for this device wired to a Beaglebone Black.

This series (or at least patch #5) depend on this DT fix[0].

Thanks,
Andrew

[0]https://www.spinics.net/lists/kernel/msg2644651.html

Andrew F. Davis (17):
  ASoC: tlv320aic31xx: General source formatting cleanup
  ASoC: tlv320aic31xx: Reformat header file using GENMASK and BIT macros
  ASoC: tlv320aic31xx: Fix GPIO1 register definition
  ASoC: tlv320aic31xx: Merge init function into probe
  ASoC: tlv320aic31xx: Switch GPIO handling to use gpiod_* API
  ASoC: tlv320aic31xx: Remove platform data
  ASoC: tlv320aic31xx: Add MICBIAS off setting
  ASoC: tlv320aic31xx: Check clock and divider before division
  ASoC: tlv320aic31xx: Add CODEC clock slave support
  ASoC: tlv320aic31xx: Fix inverted BCLK handling
  ASoC: tlv320aic31xx: Reset registers during probe
  ASoC: tlv320aic31xx: Add short circuit detection support
  ASoC: tlv320aic31xx: Add overflow detection support
  ASoC: tlv320aic31xx: Add headphone/headset detection
  ASoC: tlv320aic31xx: Add button press detection
  NOT FOR MERGING: Add TLV320DAC3101 to BBB for testing
  NOT FOR MERGING: Add demo jack detection policy for testing

 .../devicetree/bindings/sound/tlv320aic31xx.txt    |   1 +
 arch/arm/boot/dts/am335x-boneblack.dts             | 106 +++++
 include/dt-bindings/sound/tlv320aic31xx-micbias.h  |   1 +
 sound/soc/codecs/tlv320aic31xx.c                   | 400 +++++++++++-----
 sound/soc/codecs/tlv320aic31xx.h                   | 504 ++++++++++-----------
 5 files changed, 623 insertions(+), 389 deletions(-)
 rewrite sound/soc/codecs/tlv320aic31xx.h (83%)

Comments

Mark Brown Nov. 9, 2017, 12:41 p.m. UTC | #1
On Wed, Nov 08, 2017 at 06:27:25PM -0600, Andrew F. Davis wrote:
> Simple non-functional changes including:
> 
>  * Fix header copyright tags
>  * Fix spelling errors
>  * Reformat code for easier reading
>  * Move some code blocks to a more natural ordering
>  * Remove unneeded code
>  * Remove assignments that are always overridden
>  * Normalize function return paths
> 
> Signed-off-by: Andrew F. Davis <afd@ti.com>

There's other things in here like adding error reporting...  please
don't send changes like this, if you want to do cleanups you should
split them up in the same way you would other changes.  Bigger patches
are harder to review especially if they're not repetitive examples of
the same pattern.
Mark Brown Nov. 9, 2017, 12:45 p.m. UTC | #2
On Wed, Nov 08, 2017 at 06:27:27PM -0600, Andrew F. Davis wrote:
> GPIO1 control register is number 51, fix this here.
> 
> Fixes: bafcbfe429eb ("ASoC: tlv320aic31xx: Make the register values human readable")
> Signed-off-by: Andrew F. Davis <afd@ti.com>
> ---

We should send this as a bug fix to stable but this depends on your
reformatting :(
Andrew Davis Nov. 9, 2017, 2:13 p.m. UTC | #3
On 11/09/2017 06:41 AM, Mark Brown wrote:
> On Wed, Nov 08, 2017 at 06:27:25PM -0600, Andrew F. Davis wrote:
>> Simple non-functional changes including:
>>
>>  * Fix header copyright tags
>>  * Fix spelling errors
>>  * Reformat code for easier reading
>>  * Move some code blocks to a more natural ordering
>>  * Remove unneeded code
>>  * Remove assignments that are always overridden
>>  * Normalize function return paths
>>
>> Signed-off-by: Andrew F. Davis <afd@ti.com>
> 
> There's other things in here like adding error reporting...  please
> don't send changes like this, if you want to do cleanups you should
> split them up in the same way you would other changes.  Bigger patches
> are harder to review especially if they're not repetitive examples of
> the same pattern.  
> 

I'm never really sure with these where the split point should be, almost
every change in here could be its own patch if I really wanted to pad my
kernel patch count, but this series is already 17 patches long and I
usually see these all as the same logical action: non-functional cleanups.

I agree the added error message isn't purely non-functional and so
should be broken out, I'll break out a couple other changes for v2.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Andrew Davis Nov. 9, 2017, 2:32 p.m. UTC | #4
On 11/09/2017 06:45 AM, Mark Brown wrote:
> On Wed, Nov 08, 2017 at 06:27:27PM -0600, Andrew F. Davis wrote:
>> GPIO1 control register is number 51, fix this here.
>>
>> Fixes: bafcbfe429eb ("ASoC: tlv320aic31xx: Make the register values human readable")
>> Signed-off-by: Andrew F. Davis <afd@ti.com>
>> ---
> 
> We should send this as a bug fix to stable but this depends on your
> reformatting :(
> 

I put it after the reformatting as an example of its value, now that you
have seen it, I'll move it before the reformatting so it can be taken
independently.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Brown Nov. 9, 2017, 4:15 p.m. UTC | #5
On Thu, Nov 09, 2017 at 08:13:17AM -0600, Andrew F. Davis wrote:
> On 11/09/2017 06:41 AM, Mark Brown wrote:

> > There's other things in here like adding error reporting...  please
> > don't send changes like this, if you want to do cleanups you should
> > split them up in the same way you would other changes.  Bigger patches
> > are harder to review especially if they're not repetitive examples of
> > the same pattern.  

> I'm never really sure with these where the split point should be, almost
> every change in here could be its own patch if I really wanted to pad my
> kernel patch count, but this series is already 17 patches long and I
> usually see these all as the same logical action: non-functional cleanups.

> I agree the added error message isn't purely non-functional and so
> should be broken out, I'll break out a couple other changes for v2.

This is why cleanups don't happen :)

A separate cleanup series would probably cover it, when they're split up
well they're quick and easy to review.