| Message ID | 20210108160501.7638-1-rf@opensource.cirrus.com |
|---|---|
| Headers | show |
| Series | Add support for Rpi4b + Cirrus Lochnagar2 and CS47L15 | expand |
Hi Richard > Some codecs need plls and/or sysclks to be configured using the > snd_soc_component_set_[sysclk|pll] functions. These drivers cannot > necessarily be converted to use the clock framework. If the codec is on > a I2C/SPI bus, a nested clk_get would be needed to enable the bus clock. > But the clock framework does not support nested operations and this would > deadlock. > > This patch adds new dt properties that list phandles of components with > the pll/sysclk settings to be applied. Multiple settings can be given for > the same phandle to allow for components with multiple clocks and plls. > The plls and sysclks are enabled when the card bias level moves to STANDBY > and disabled when it moves to OFF. > > The implementation does not attempt to handle specifying complex clock > ordering interdependencies between components. The plls and sysclks are > applied to a component as it is passed to the card set_bias_level/ > set_bias_level_post callbacks. It follows from this that the order > components are configured is the order that they are passed to those > callbacks. > > Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> > --- As I mentioned in v3, adding *general* pll to common card driver is maybe difficult. Using your own customized audio-graph-card driver is better idea, instead of adding code to common driver. I think Sameer's Tegra driver (= [3/6]) is good sample for you ? https://lore.kernel.org/r/1606413823-19885-1-git-send-email-spujar@nvidia.com Thank you for your help !! Best regards --- Kuninori Morimoto
On 12/01/2021 01:35, Kuninori Morimoto wrote: > > Hi Richard > >> Some codecs need plls and/or sysclks to be configured using the >> snd_soc_component_set_[sysclk|pll] functions. These drivers cannot >> necessarily be converted to use the clock framework. If the codec is on >> a I2C/SPI bus, a nested clk_get would be needed to enable the bus clock. >> But the clock framework does not support nested operations and this would >> deadlock. >> >> This patch adds new dt properties that list phandles of components with >> the pll/sysclk settings to be applied. Multiple settings can be given for >> the same phandle to allow for components with multiple clocks and plls. >> The plls and sysclks are enabled when the card bias level moves to STANDBY >> and disabled when it moves to OFF. >> >> The implementation does not attempt to handle specifying complex clock >> ordering interdependencies between components. The plls and sysclks are >> applied to a component as it is passed to the card set_bias_level/ >> set_bias_level_post callbacks. It follows from this that the order >> components are configured is the order that they are passed to those >> callbacks. >> >> Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> >> --- > > As I mentioned in v3, adding *general* pll to common card driver is > maybe difficult. You did say that. But you did not say why. Can you be more specific about what problem you see with adding it to the generic driver? > Using your own customized audio-graph-card driver is better idea, > instead of adding code to common driver. I just don't want to duplicate code without good reason. > > I think Sameer's Tegra driver (= [3/6]) is good sample for you ? > > https://lore.kernel.org/r/1606413823-19885-1-git-send-email-spujar@nvidia.com > > Thank you for your help !! > > Best regards > --- > Kuninori Morimoto >
Hi Richard > > As I mentioned in v3, adding *general* pll to common card driver is > > maybe difficult. > > You did say that. But you did not say why. > Can you be more specific about what problem you see with adding it > to the generic driver? > > > Using your own customized audio-graph-card driver is better idea, > > instead of adding code to common driver. > > I just don't want to duplicate code without good reason. Ahh, sorry for my unclear comment. I think "PLL settings" is very board/platform specific, so, adding such code to common driver will be issue in the future. This is the reason why I don't want add it to audio-graph-card. But, as I mentioned above and Sameer is already doing, you can reuse audio-graph-card and customize it. Reuse audio-graph-card + Use your own PLL code = your own customized audio-graph-card You can reuse audio-graph-card code by calling graph_parse_of(), and customize before/after that. I think no duplicate code is needed. I hope it can help you. Thank you for your help !! Best regards --- Kuninori Morimoto
On Wed, Jan 13, 2021 at 09:00:19AM +0900, Kuninori Morimoto wrote: > Ahh, sorry for my unclear comment. > I think "PLL settings" is very board/platform specific, > so, adding such code to common driver will be issue in the future. > This is the reason why I don't want add it to audio-graph-card. I don't think it's *that* weird, they're a fairly common feature of devices and in terms of integration aren't particularly different to sysclks, though this is for more complex CODECs.