Re: [alsa-devel] [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID
On 22/04/16 14:52, Peter Ujfalusi wrote: On 04/22/16 01:29, Stephen Boyd wrote: The first issue with converting the McASP to use CCF internally for clock selection, muxing and rate configuration is that the daVinci platform does not use CCF at all. Given that the davinci-mcasp driver is used by daVinci, we need to have non CCF way supported in ASoC... Well, at least long term we do need daVinci converting to CCF - this is going to continue to cause problems, devices not part of the SoC can and do contain clocks and are going to end up being supported via the clock API. Does anyone here know what's involved in converting daVinci to CCF? It doesn't look too far off from what is in the CCF today, so I'm not sure what's blocking the transition. Not entirely sure, but most likely new clk driver(s) for daVinci under drivers/clk/ti/ new set of structures to describe the clocks if the ti_clk* is not applicable I guess for starter. Support for DT, non DT boots as most of daVinci is not booting with DT and most likely never will. It might help to have different daVinci boards for testing the transition. I only have OMAP-L138-evm. I don't think it is enough for testing an entire architecture for this big change... Tero might have better estimates on what is involved when switching an architecture to CCF from custom, but at least synchronized API - so we don't need to convert drivers at least. Davinci is currently a mutant architecture, it is overriding the common clk APIs and using its own. Converting these to CCF may open a can of worms in many ways. All the clock data should be converted to support CCF, (from arch/arm/mach-davinci/), along with whatever Peter said. This also in a situation where many/most upstream people don't even have davinci devices... Personally I have a grand total of zero davinci boards on my desk so at least I am unable to work on this right now. -Tero
Re: [alsa-devel] [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID
On 22/04/16 14:52, Peter Ujfalusi wrote: On 04/22/16 01:29, Stephen Boyd wrote: The first issue with converting the McASP to use CCF internally for clock selection, muxing and rate configuration is that the daVinci platform does not use CCF at all. Given that the davinci-mcasp driver is used by daVinci, we need to have non CCF way supported in ASoC... Well, at least long term we do need daVinci converting to CCF - this is going to continue to cause problems, devices not part of the SoC can and do contain clocks and are going to end up being supported via the clock API. Does anyone here know what's involved in converting daVinci to CCF? It doesn't look too far off from what is in the CCF today, so I'm not sure what's blocking the transition. Not entirely sure, but most likely new clk driver(s) for daVinci under drivers/clk/ti/ new set of structures to describe the clocks if the ti_clk* is not applicable I guess for starter. Support for DT, non DT boots as most of daVinci is not booting with DT and most likely never will. It might help to have different daVinci boards for testing the transition. I only have OMAP-L138-evm. I don't think it is enough for testing an entire architecture for this big change... Tero might have better estimates on what is involved when switching an architecture to CCF from custom, but at least synchronized API - so we don't need to convert drivers at least. Davinci is currently a mutant architecture, it is overriding the common clk APIs and using its own. Converting these to CCF may open a can of worms in many ways. All the clock data should be converted to support CCF, (from arch/arm/mach-davinci/), along with whatever Peter said. This also in a situation where many/most upstream people don't even have davinci devices... Personally I have a grand total of zero davinci boards on my desk so at least I am unable to work on this right now. -Tero
Re: [alsa-devel] [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID
On 04/22/16 01:29, Stephen Boyd wrote: >>> The first issue with converting the McASP to use CCF internally for clock >>> selection, muxing and rate configuration is that the daVinci platform does >>> not >>> use CCF at all. Given that the davinci-mcasp driver is used by daVinci, we >>> need to have non CCF way supported in ASoC... >> >> Well, at least long term we do need daVinci converting to CCF - this is >> going to continue to cause problems, devices not part of the SoC can and >> do contain clocks and are going to end up being supported via the clock >> API. > > Does anyone here know what's involved in converting daVinci to > CCF? It doesn't look too far off from what is in the CCF today, > so I'm not sure what's blocking the transition. Not entirely sure, but most likely new clk driver(s) for daVinci under drivers/clk/ti/ new set of structures to describe the clocks if the ti_clk* is not applicable I guess for starter. Support for DT, non DT boots as most of daVinci is not booting with DT and most likely never will. It might help to have different daVinci boards for testing the transition. I only have OMAP-L138-evm. I don't think it is enough for testing an entire architecture for this big change... Tero might have better estimates on what is involved when switching an architecture to CCF from custom, but at least synchronized API - so we don't need to convert drivers at least. -- Péter
Re: [alsa-devel] [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID
On 04/22/16 01:29, Stephen Boyd wrote: >>> The first issue with converting the McASP to use CCF internally for clock >>> selection, muxing and rate configuration is that the daVinci platform does >>> not >>> use CCF at all. Given that the davinci-mcasp driver is used by daVinci, we >>> need to have non CCF way supported in ASoC... >> >> Well, at least long term we do need daVinci converting to CCF - this is >> going to continue to cause problems, devices not part of the SoC can and >> do contain clocks and are going to end up being supported via the clock >> API. > > Does anyone here know what's involved in converting daVinci to > CCF? It doesn't look too far off from what is in the CCF today, > so I'm not sure what's blocking the transition. Not entirely sure, but most likely new clk driver(s) for daVinci under drivers/clk/ti/ new set of structures to describe the clocks if the ti_clk* is not applicable I guess for starter. Support for DT, non DT boots as most of daVinci is not booting with DT and most likely never will. It might help to have different daVinci boards for testing the transition. I only have OMAP-L138-evm. I don't think it is enough for testing an entire architecture for this big change... Tero might have better estimates on what is involved when switching an architecture to CCF from custom, but at least synchronized API - so we don't need to convert drivers at least. -- Péter
Re: [alsa-devel] [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID
On 04/18, Mark Brown wrote: > On Mon, Apr 18, 2016 at 06:50:52PM +0300, Peter Ujfalusi wrote: > > On 02/17/2016 09:52 PM, Peter Ujfalusi wrote: > > > > On the other hand this ABI is backwards compatible since if it is missing > > > it > > > will default to the configuration we right now have regarding to > > > sysclk_dir > > > and sysclk_id. > > > > I will look at the CCF implementation for McASP first then for aic3x. > > > The first issue with converting the McASP to use CCF internally for clock > > selection, muxing and rate configuration is that the daVinci platform does > > not > > use CCF at all. Given that the davinci-mcasp driver is used by daVinci, we > > need to have non CCF way supported in ASoC... > > Well, at least long term we do need daVinci converting to CCF - this is > going to continue to cause problems, devices not part of the SoC can and > do contain clocks and are going to end up being supported via the clock > API. Does anyone here know what's involved in converting daVinci to CCF? It doesn't look too far off from what is in the CCF today, so I'm not sure what's blocking the transition. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [alsa-devel] [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID
On 04/18, Mark Brown wrote: > On Mon, Apr 18, 2016 at 06:50:52PM +0300, Peter Ujfalusi wrote: > > On 02/17/2016 09:52 PM, Peter Ujfalusi wrote: > > > > On the other hand this ABI is backwards compatible since if it is missing > > > it > > > will default to the configuration we right now have regarding to > > > sysclk_dir > > > and sysclk_id. > > > > I will look at the CCF implementation for McASP first then for aic3x. > > > The first issue with converting the McASP to use CCF internally for clock > > selection, muxing and rate configuration is that the daVinci platform does > > not > > use CCF at all. Given that the davinci-mcasp driver is used by daVinci, we > > need to have non CCF way supported in ASoC... > > Well, at least long term we do need daVinci converting to CCF - this is > going to continue to cause problems, devices not part of the SoC can and > do contain clocks and are going to end up being supported via the clock > API. Does anyone here know what's involved in converting daVinci to CCF? It doesn't look too far off from what is in the CCF today, so I'm not sure what's blocking the transition. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [alsa-devel] [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID
On Mon, Apr 18, 2016 at 06:50:52PM +0300, Peter Ujfalusi wrote: > On 02/17/2016 09:52 PM, Peter Ujfalusi wrote: > > On the other hand this ABI is backwards compatible since if it is missing it > > will default to the configuration we right now have regarding to sysclk_dir > > and sysclk_id. > > I will look at the CCF implementation for McASP first then for aic3x. > The first issue with converting the McASP to use CCF internally for clock > selection, muxing and rate configuration is that the daVinci platform does not > use CCF at all. Given that the davinci-mcasp driver is used by daVinci, we > need to have non CCF way supported in ASoC... Well, at least long term we do need daVinci converting to CCF - this is going to continue to cause problems, devices not part of the SoC can and do contain clocks and are going to end up being supported via the clock API. signature.asc Description: PGP signature
Re: [alsa-devel] [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID
On Mon, Apr 18, 2016 at 06:50:52PM +0300, Peter Ujfalusi wrote: > On 02/17/2016 09:52 PM, Peter Ujfalusi wrote: > > On the other hand this ABI is backwards compatible since if it is missing it > > will default to the configuration we right now have regarding to sysclk_dir > > and sysclk_id. > > I will look at the CCF implementation for McASP first then for aic3x. > The first issue with converting the McASP to use CCF internally for clock > selection, muxing and rate configuration is that the daVinci platform does not > use CCF at all. Given that the davinci-mcasp driver is used by daVinci, we > need to have non CCF way supported in ASoC... Well, at least long term we do need daVinci converting to CCF - this is going to continue to cause problems, devices not part of the SoC can and do contain clocks and are going to end up being supported via the clock API. signature.asc Description: PGP signature
Re: [alsa-devel] [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID
On 02/17/2016 09:52 PM, Peter Ujfalusi wrote: > On 02/17/2016 02:07 PM, Mark Brown wrote: >> On Wed, Feb 17, 2016 at 10:13:35AM +0200, Peter Ujfalusi wrote: >> >>> With this change we don't need to write custom machine drivers for setup not >>> using sysclk_id == 0. >>> I do think this is reasonable change by itself. >> >>> However I do think that the current simple-card is flawed regarding to clock >>> selection and the change Jyri and me are proposing is reasonable. >> >> But you define a new ABI to specify it in the process, I'd rather fix >> the flaws by using the common clock ABI than extend any device stuff. >> If it didn't define a new ABI I'd probably not worry about it but one of >> the issues we have with DT is that we do end up making ABIs every time >> we put something in DT. > > I understand. This should have been supported by simple-card since the > beginning. When we tried to move all boards to use simple-card, we hit the > wall by not being able to select and configure other sysclk_id than 0. > I don't want to create yet another simple card which handles only sysclk_id 1 > ;) > On the other hand this ABI is backwards compatible since if it is missing it > will default to the configuration we right now have regarding to sysclk_dir > and sysclk_id. > > I will look at the CCF implementation for McASP first then for aic3x. The first issue with converting the McASP to use CCF internally for clock selection, muxing and rate configuration is that the daVinci platform does not use CCF at all. Given that the davinci-mcasp driver is used by daVinci, we need to have non CCF way supported in ASoC... -- Péter
Re: [alsa-devel] [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID
On 02/17/2016 09:52 PM, Peter Ujfalusi wrote: > On 02/17/2016 02:07 PM, Mark Brown wrote: >> On Wed, Feb 17, 2016 at 10:13:35AM +0200, Peter Ujfalusi wrote: >> >>> With this change we don't need to write custom machine drivers for setup not >>> using sysclk_id == 0. >>> I do think this is reasonable change by itself. >> >>> However I do think that the current simple-card is flawed regarding to clock >>> selection and the change Jyri and me are proposing is reasonable. >> >> But you define a new ABI to specify it in the process, I'd rather fix >> the flaws by using the common clock ABI than extend any device stuff. >> If it didn't define a new ABI I'd probably not worry about it but one of >> the issues we have with DT is that we do end up making ABIs every time >> we put something in DT. > > I understand. This should have been supported by simple-card since the > beginning. When we tried to move all boards to use simple-card, we hit the > wall by not being able to select and configure other sysclk_id than 0. > I don't want to create yet another simple card which handles only sysclk_id 1 > ;) > On the other hand this ABI is backwards compatible since if it is missing it > will default to the configuration we right now have regarding to sysclk_dir > and sysclk_id. > > I will look at the CCF implementation for McASP first then for aic3x. The first issue with converting the McASP to use CCF internally for clock selection, muxing and rate configuration is that the daVinci platform does not use CCF at all. Given that the davinci-mcasp driver is used by daVinci, we need to have non CCF way supported in ASoC... -- Péter
Re: [alsa-devel] [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID
On Wed, Feb 17, 2016 at 03:18:57PM +0100, Ricard Wanderlof wrote: > It makes sense to use an already existing clock framework, but I'm > wondering, how do we model the clock select function? Using a clock mux? Yes, that looks like a mux to me. signature.asc Description: PGP signature
Re: [alsa-devel] [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID
On Wed, Feb 17, 2016 at 03:18:57PM +0100, Ricard Wanderlof wrote: > It makes sense to use an already existing clock framework, but I'm > wondering, how do we model the clock select function? Using a clock mux? Yes, that looks like a mux to me. signature.asc Description: PGP signature
Re: [alsa-devel] [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID
Quoting Mark Brown (2016-02-16 05:42:33) > On Tue, Feb 16, 2016 at 11:46:52AM +0200, Peter Ujfalusi wrote: > > > As for codecs, tlv320aic3106 is also pretty simple device from the outside, > > it > > can receive it's reference clock via: > > MCLK pin, GPIO2 pin or it can use the BCLK from the bus. Based on the > > incoming > > frequency it can use it directly or it needs to use the internal PLL to > > generate the cocks. > > It can output generated clock via GPIO1 > > That already sounds like there is room for configuration and hooking > into a wider clock tree - we've got three different source options and > an output plus a PLL that can presumably take in non-audio rates. It makes sense to use an already existing clock framework, but I'm wondering, how do we model the clock select function? Using a clock mux? Somewhere, somehow, something needs to look at the setup and decide which pin on the codec should be the clock source (e.g. MCLK, GPIO2, or BCLK in the case of the tlv320aic3106). /Ricard -- Ricard Wolf Wanderlöf ricardw(at)axis.com Axis Communications AB, Lund, Swedenwww.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30
Re: [alsa-devel] [PATCH 4/4] ASoC: simple-card: Support for selecting system clocks by ID
Quoting Mark Brown (2016-02-16 05:42:33) > On Tue, Feb 16, 2016 at 11:46:52AM +0200, Peter Ujfalusi wrote: > > > As for codecs, tlv320aic3106 is also pretty simple device from the outside, > > it > > can receive it's reference clock via: > > MCLK pin, GPIO2 pin or it can use the BCLK from the bus. Based on the > > incoming > > frequency it can use it directly or it needs to use the internal PLL to > > generate the cocks. > > It can output generated clock via GPIO1 > > That already sounds like there is room for configuration and hooking > into a wider clock tree - we've got three different source options and > an output plus a PLL that can presumably take in non-audio rates. It makes sense to use an already existing clock framework, but I'm wondering, how do we model the clock select function? Using a clock mux? Somewhere, somehow, something needs to look at the setup and decide which pin on the codec should be the clock source (e.g. MCLK, GPIO2, or BCLK in the case of the tlv320aic3106). /Ricard -- Ricard Wolf Wanderlöf ricardw(at)axis.com Axis Communications AB, Lund, Swedenwww.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30
