Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46 |
|
#
11e756cc |
| 13-Aug-2023 |
Guiting Shen <aarongt.shen@gmail.com> |
ASoC: tlv320aic32x4: Fix the divide by zero
The value of register(NDAC,MDAC,NADC,MADC,BCLKN) maybe zero lead to divide by zero in clk_aic32x4_div_recalc_rate().And the rate should be divide by 128 i
ASoC: tlv320aic32x4: Fix the divide by zero
The value of register(NDAC,MDAC,NADC,MADC,BCLKN) maybe zero lead to divide by zero in clk_aic32x4_div_recalc_rate().And the rate should be divide by 128 if the value was zero in this function according to the datasheet.
Add the macro AIC32X4_DIV_MAX to present the 128 and return 0 if failing to read the value of register.
Signed-off-by: Guiting Shen <aarongt.shen@gmail.com> Link: https://lore.kernel.org/r/20230813125520.11067-1-aarongt.shen@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34 |
|
#
3e253b21 |
| 12-Jun-2023 |
Stephen Boyd <sboyd@kernel.org> |
ASoC: tlv320aic32x4: pll: Remove impossible condition in clk_aic32x4_pll_determine_rate()
Smatch warns:
sound/soc/codecs/tlv320aic32x4-clk.c:219 clk_aic32x4_pll_determine_rate() warn: unsigned 'rat
ASoC: tlv320aic32x4: pll: Remove impossible condition in clk_aic32x4_pll_determine_rate()
Smatch warns:
sound/soc/codecs/tlv320aic32x4-clk.c:219 clk_aic32x4_pll_determine_rate() warn: unsigned 'rate' is never less than zero.
Cc: Maxime Ripard <maxime@cerno.tech> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202306101217.08CRVGcK-lkp@intel.com/ Fixes: 25d43ec352ea ("ASoC: tlv320aic32x4: pll: Switch to determine_rate") Signed-off-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/20230613011201.1166753-1-sboyd@kernel.org Reviewed-by: Maxime Ripard <mripard@kernel.org>
show more ...
|
Revision tags: v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28 |
|
#
2b6c9b0e |
| 05-May-2023 |
Maxime Ripard <maxime@cerno.tech> |
ASoC: tlv320aic32x4: div: Switch to determine_rate
The tlv320aic32x4 divider clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd,
ASoC: tlv320aic32x4: div: Switch to determine_rate
The tlv320aic32x4 divider clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
Cc: Jaroslav Kysela <perex@perex.cz> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Takashi Iwai <tiwai@suse.com> Cc: alsa-devel@alsa-project.org Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-67-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
show more ...
|
#
25d43ec3 |
| 05-May-2023 |
Maxime Ripard <maxime@cerno.tech> |
ASoC: tlv320aic32x4: pll: Switch to determine_rate
The tlv320aic32x4 PLL clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, sinc
ASoC: tlv320aic32x4: pll: Switch to determine_rate
The tlv320aic32x4 PLL clocks implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidate to trigger that parent change is a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The driver does implement round_rate() though, which means that we can change the rate of the clock, but we will never get to change the parent.
However, It's hard to tell whether it's been done on purpose or not.
Since we'll start mandating a determine_rate() implementation, let's convert the round_rate() implementation to a determine_rate(), which will also make the current behavior explicit. And if it was an oversight, the clock behaviour can be adjusted later on.
Cc: Jaroslav Kysela <perex@perex.cz> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Takashi Iwai <tiwai@suse.com> Cc: alsa-devel@alsa-project.org Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-66-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
show more ...
|
#
218b95ba |
| 05-May-2023 |
Maxime Ripard <maxime@cerno.tech> |
ASoC: tlv320aic32x4: Add a determine_rate hook
The tlv320aic32x4 clkin clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since s
ASoC: tlv320aic32x4: Add a determine_rate hook
The tlv320aic32x4 clkin clock implements a mux with a set_parent hook, but doesn't provide a determine_rate implementation.
This is a bit odd, since set_parent() is there to, as its name implies, change the parent of a clock. However, the most likely candidates to trigger that parent change are either the assigned-clock-parents device tree property or a call to clk_set_rate(), with determine_rate() figuring out which parent is the best suited for a given rate.
The other trigger would be a call to clk_set_parent(), but it's far less used, and it doesn't look like there's any obvious user for that clock.
Similarly, it doesn't look like the device tree using that clock driver uses any of the assigned-clock properties on that clock.
So, the set_parent hook is effectively unused, possibly because of an oversight. However, it could also be an explicit decision by the original author to avoid any reparenting but through an explicit call to clk_set_parent().
The latter case would be equivalent to setting the determine_rate implementation to clk_hw_determine_rate_no_reparent(). Indeed, if no determine_rate implementation is provided, clk_round_rate() (through clk_core_round_rate_nolock()) will call itself on the parent if CLK_SET_RATE_PARENT is set, and will not change the clock rate otherwise.
And if it was an oversight, then we are at least explicit about our behavior now and it can be further refined down the line.
Cc: Jaroslav Kysela <perex@perex.cz> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Takashi Iwai <tiwai@suse.com> Cc: alsa-devel@alsa-project.org Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20221018-clk-range-checks-fixes-v4-46-971d5077e7d2@cerno.tech Signed-off-by: Stephen Boyd <sboyd@kernel.org>
show more ...
|
Revision tags: v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9 |
|
#
5b4458eb |
| 11-Sep-2020 |
Miquel Raynal <miquel.raynal@bootlin.com> |
ASoC: tlv320aic32x4: Ensure a minimum delay before clock stabilization
As indicated in the datasheet, a 10ms delay must be observed after programming the divisors.
The lack of delay prevents the co
ASoC: tlv320aic32x4: Ensure a minimum delay before clock stabilization
As indicated in the datasheet, a 10ms delay must be observed after programming the divisors.
The lack of delay prevents the codec to work properly and the playback appears extremely slow and totally un-audible on a custom sama5 based board.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20200911173140.29984-2-miquel.raynal@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8 |
|
#
a23e34c0 |
| 08-Apr-2019 |
Annaliese McDermond <nh6z@nh6z.net> |
ASoC: tlv320aic32x4: Fix potential uninitialized variable
Fix compiler warning about uninitialized variable reported by Stephen Rothwell <sfr@canb.auug.org.au>.
Signed-off-by: Annaliese McDermond <
ASoC: tlv320aic32x4: Fix potential uninitialized variable
Fix compiler warning about uninitialized variable reported by Stephen Rothwell <sfr@canb.auug.org.au>.
Signed-off-by: Annaliese McDermond <nh6z@nh6z.net> Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
#
daae4c58 |
| 05-Apr-2019 |
Annaliese McDermond <nh6z@nh6z.net> |
ASoC: tlv320aic32x4: Fix spacing
Fix some cosmetic spacing issues reported by Julia Lawall <julia.lawall@lip6.fr>.
Signed-off-by: Annaliese McDermond <nh6z@nh6z.net> Signed-off-by: Mark Brown <broo
ASoC: tlv320aic32x4: Fix spacing
Fix some cosmetic spacing issues reported by Julia Lawall <julia.lawall@lip6.fr>.
Signed-off-by: Annaliese McDermond <nh6z@nh6z.net> Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.0.7, v5.0.6, v5.0.5, v5.0.4 |
|
#
9b484124 |
| 21-Mar-2019 |
Annaliese McDermond <nh6z@nh6z.net> |
ASoC: tlv320aic32x4: Model BDIV divider in CCF
Model and manage BDIV divider as components in the Core Clock Framework. This should allow us to do some more complex clock management and power contr
ASoC: tlv320aic32x4: Model BDIV divider in CCF
Model and manage BDIV divider as components in the Core Clock Framework. This should allow us to do some more complex clock management and power control. Also, some of the on-board chip clocks can be exposed to the outside, and this change will make those clocks easier to consume by other parts of the kernel.
Signed-off-by: Annaliese McDermond <nh6z@nh6z.net> Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
#
a51b5006 |
| 21-Mar-2019 |
Annaliese McDermond <nh6z@nh6z.net> |
ASoC: tlv320aic32x4: Model DAC/ADC dividers in CCF
Model and manage DAC/ADC dividers as components in the Core Clock Framework. This should allow us to do some more complex clock management and pow
ASoC: tlv320aic32x4: Model DAC/ADC dividers in CCF
Model and manage DAC/ADC dividers as components in the Core Clock Framework. This should allow us to do some more complex clock management and power control. Also, some of the on-board chip clocks can be exposed to the outside, and this change will make those clocks easier to consume by other parts of the kernel.
Signed-off-by: Annaliese McDermond <nh6z@nh6z.net> Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
#
fd2df3ae |
| 21-Mar-2019 |
Annaliese McDermond <nh6z@nh6z.net> |
ASoC: tlv320aic32x4: Model CODEC_CLKIN in CCF
Model and manage codec clock input as a component in the Core Clock Framework. This should allow us to do some more complex clock management and power
ASoC: tlv320aic32x4: Model CODEC_CLKIN in CCF
Model and manage codec clock input as a component in the Core Clock Framework. This should allow us to do some more complex clock management and power control. Also, some of the on-board chip clocks can be exposed to the outside, and this change will make those clocks easier to consume by other parts of the kernel.
Signed-off-by: Annaliese McDermond <nh6z@nh6z.net> Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
#
514b044c |
| 21-Mar-2019 |
Annaliese McDermond <nh6z@nh6z.net> |
ASoC: tlv320aic32x4: Model PLL in CCF
Model and manage the on-board PLL as a component in the Core Clock Framework. This should allow us to do some more complex clock management and power control.
ASoC: tlv320aic32x4: Model PLL in CCF
Model and manage the on-board PLL as a component in the Core Clock Framework. This should allow us to do some more complex clock management and power control. Also, some of the on-board chip clocks can be exposed to the outside, and this change will make those clocks easier to consume by other parts of the kernel.
Signed-off-by: Annaliese McDermond <nh6z@nh6z.net> Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9 |
|
#
5b4458eb |
| 11-Sep-2020 |
Miquel Raynal <miquel.raynal@bootlin.com> |
ASoC: tlv320aic32x4: Ensure a minimum delay before clock stabilization As indicated in the datasheet, a 10ms delay must be observed after programming the divisors. The lack of d
ASoC: tlv320aic32x4: Ensure a minimum delay before clock stabilization As indicated in the datasheet, a 10ms delay must be observed after programming the divisors. The lack of delay prevents the codec to work properly and the playback appears extremely slow and totally un-audible on a custom sama5 based board. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/r/20200911173140.29984-2-miquel.raynal@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8 |
|
#
a23e34c0 |
| 08-Apr-2019 |
Annaliese McDermond <nh6z@nh6z.net> |
ASoC: tlv320aic32x4: Fix potential uninitialized variable Fix compiler warning about uninitialized variable reported by Stephen Rothwell <sfr@canb.auug.org.au>. Signed-off-by: A
ASoC: tlv320aic32x4: Fix potential uninitialized variable Fix compiler warning about uninitialized variable reported by Stephen Rothwell <sfr@canb.auug.org.au>. Signed-off-by: Annaliese McDermond <nh6z@nh6z.net> Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
#
daae4c58 |
| 05-Apr-2019 |
Annaliese McDermond <nh6z@nh6z.net> |
ASoC: tlv320aic32x4: Fix spacing Fix some cosmetic spacing issues reported by Julia Lawall <julia.lawall@lip6.fr>. Signed-off-by: Annaliese McDermond <nh6z@nh6z.net> Signed-
ASoC: tlv320aic32x4: Fix spacing Fix some cosmetic spacing issues reported by Julia Lawall <julia.lawall@lip6.fr>. Signed-off-by: Annaliese McDermond <nh6z@nh6z.net> Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
Revision tags: v5.0.7, v5.0.6, v5.0.5, v5.0.4 |
|
#
9b484124 |
| 21-Mar-2019 |
Annaliese McDermond <nh6z@nh6z.net> |
ASoC: tlv320aic32x4: Model BDIV divider in CCF Model and manage BDIV divider as components in the Core Clock Framework. This should allow us to do some more complex clock management
ASoC: tlv320aic32x4: Model BDIV divider in CCF Model and manage BDIV divider as components in the Core Clock Framework. This should allow us to do some more complex clock management and power control. Also, some of the on-board chip clocks can be exposed to the outside, and this change will make those clocks easier to consume by other parts of the kernel. Signed-off-by: Annaliese McDermond <nh6z@nh6z.net> Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
#
a51b5006 |
| 21-Mar-2019 |
Annaliese McDermond <nh6z@nh6z.net> |
ASoC: tlv320aic32x4: Model DAC/ADC dividers in CCF Model and manage DAC/ADC dividers as components in the Core Clock Framework. This should allow us to do some more complex clock ma
ASoC: tlv320aic32x4: Model DAC/ADC dividers in CCF Model and manage DAC/ADC dividers as components in the Core Clock Framework. This should allow us to do some more complex clock management and power control. Also, some of the on-board chip clocks can be exposed to the outside, and this change will make those clocks easier to consume by other parts of the kernel. Signed-off-by: Annaliese McDermond <nh6z@nh6z.net> Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
#
fd2df3ae |
| 21-Mar-2019 |
Annaliese McDermond <nh6z@nh6z.net> |
ASoC: tlv320aic32x4: Model CODEC_CLKIN in CCF Model and manage codec clock input as a component in the Core Clock Framework. This should allow us to do some more complex clock manag
ASoC: tlv320aic32x4: Model CODEC_CLKIN in CCF Model and manage codec clock input as a component in the Core Clock Framework. This should allow us to do some more complex clock management and power control. Also, some of the on-board chip clocks can be exposed to the outside, and this change will make those clocks easier to consume by other parts of the kernel. Signed-off-by: Annaliese McDermond <nh6z@nh6z.net> Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|
#
514b044c |
| 21-Mar-2019 |
Annaliese McDermond <nh6z@nh6z.net> |
ASoC: tlv320aic32x4: Model PLL in CCF Model and manage the on-board PLL as a component in the Core Clock Framework. This should allow us to do some more complex clock management and
ASoC: tlv320aic32x4: Model PLL in CCF Model and manage the on-board PLL as a component in the Core Clock Framework. This should allow us to do some more complex clock management and power control. Also, some of the on-board chip clocks can be exposed to the outside, and this change will make those clocks easier to consume by other parts of the kernel. Signed-off-by: Annaliese McDermond <nh6z@nh6z.net> Signed-off-by: Mark Brown <broonie@kernel.org>
show more ...
|