Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On Thu, 2008-01-10 at 00:41 -0500, Jon Smirl wrote: ASOC v2 is sitting on a Wolfson server out of tree. I have been using it for several months without problem. The pace of it being merged could probably be sped up. I think we are probably looking at submission in the next 8 - 10 weeks. Currently most of the core code is complete, however some platforms and codecs still need porting. Liam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
Liam Girdwood wrote: I think we are probably looking at submission in the next 8 - 10 weeks. Currently most of the core code is complete, however some platforms and codecs still need porting. With that in mind, can I get some kind of consensus from the PPC side as to whether this ASoC V1 driver is okay? I want to get it into 2.6.25. Keep in mind: 1) ASoC V1 is not PowerPC-friendly, so it's impossible to make an ASoC V1 PowerPC driver 100% correct. 2) The CS4270 driver does not support I2C nodes in the device tree, so there's not point in adding any to the 8610 DTS. 3) Liam and I are working on porting this driver to ASoC V2 and resolving all open PPC issue, but that won't be done in time for 2.6.25. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On 1/10/08, Timur Tabi [EMAIL PROTECTED] wrote: Liam Girdwood wrote: I think we are probably looking at submission in the next 8 - 10 weeks. Currently most of the core code is complete, however some platforms and codecs still need porting. With that in mind, can I get some kind of consensus from the PPC side as to whether this ASoC V1 driver is okay? I want to get it into 2.6.25. Keep in mind: 1) ASoC V1 is not PowerPC-friendly, so it's impossible to make an ASoC V1 PowerPC driver 100% correct. The driver doesn't need to be 100% correct. Drivers are easy to change if they aren't quite right. There are no long term consequences. However, the device tree issues must be addressed before it is merged and deployed. Otherwise we end up having to support poorly designed trees over the long term. So, I'm okay with merging the driver *minus* the .dts and booting-without-of.txt changes. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On 1/10/08, Timur Tabi [EMAIL PROTECTED] wrote: Grant Likely wrote: The driver doesn't need to be 100% correct. Drivers are easy to change if they aren't quite right. There are no long term consequences. However, the device tree issues must be addressed before it is merged and deployed. Otherwise we end up having to support poorly designed trees over the long term. I agree. Correct me if I'm wrong, but I think the only device tree issue is the definition of the 'codec' node under the SSI node. If so, I'm not sure what other changes need to be mode. Isn't your codec is i2c controlled? Where does the main node for the code live, i2c bus or ssi bus? What does the link between the buses look like for pointing to the codec entry? What about fsl,ssi being too generic for a compatible type? -- Timur Tabi Linux kernel developer at Freescale -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On 1/10/08, Timur Tabi [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
Isn't your codec is i2c controlled? Where does the main node for the
code live, i2c bus or ssi bus? What does the link between the buses
look like for pointing to the codec entry?
The CS4270 driver is old style, which means it probes all possible I2C
addresses until it finds a hit, and then stops. This has all the obvious
drawbacks, but I'm stuck with that design for now.
What about fsl,ssi being too generic for a compatible type?
Already fixed:
[EMAIL PROTECTED] {
compatible = fsl,mpc8610-ssi;
Nit: node name should be either [EMAIL PROTECTED] (the mode that it is in), or
[EMAIL PROTECTED] (if you feel that this node encapsulates the concept of a
sound device enough).
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On 1/10/08, Timur Tabi [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
Isn't your codec is i2c controlled? Where does the main node for the
code live, i2c bus or ssi bus? What does the link between the buses
look like for pointing to the codec entry?
The CS4270 driver is old style, which means it probes all possible I2C
addresses until it finds a hit, and then stops. This has all the obvious
drawbacks, but I'm stuck with that design for now.
So the codec is controlled from the i2c bus and SSI is used to supply
it with data. Based on what has been said on this list, the device
tree node for the codec should be on the i2c bus with a link from the
ssi bus to it.
What about fsl,ssi being too generic for a compatible type?
Already fixed:
[EMAIL PROTECTED] {
compatible = fsl,mpc8610-ssi;
--
Timur Tabi
Linux kernel developer at Freescale
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
Jon Smirl wrote: So the codec is controlled from the i2c bus and SSI is used to supply it with data. Based on what has been said on this list, the device tree node for the codec should be on the i2c bus with a link from the ssi bus to it. I'm working on that now. I'll have a new patch with this exact change this afternoon. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
Grant Likely wrote: Nit: node name should be either [EMAIL PROTECTED] (the mode that it is in), or [EMAIL PROTECTED] (if you feel that this node encapsulates the concept of a sound device enough). Well, SSI stands for Synchronous Serial Interface (although it's capable of asynchronous communication as well). From the manual: The SSI is a full-duplex, serial port that allows the chip to communicate with a variety of serial devices. These serial devices can be standard CODer-DECoder (CODECs), Digital Signal Processors (DSPs), microprocessors, peripherals, and popular industry audio CODECs that implement the inter-IC sound bus standard (I2S) and Intel AC97 standard. It might an I2S device in this case, but it could be an AC97 device in some other case. It all depends on how the board is wired. Do we really want to change the name of an SOC device based on what it's connected to? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On Mon, Jan 07, 2008 at 06:28:54PM +, Mark Brown wrote: On Mon, Jan 07, 2008 at 09:52:03AM -0600, Timur Tabi wrote: David Gibson wrote: Ok, but couldn't you strucutre your I2S or fabric driver so that it only becomes fully operational once the codec driver has registered with it? Not in ASoC V1. You have to understand, ASoC V1 was designed without any consideration for runtime-bindings and other OF goodies. All connections between the drivers are static, literally. In fact, I wouldn't be surprised if some ASoC drivers cannot be compiled as modules. I'd just like to emphasise this point - ASoC v1 really doesn't understand the idea that the components of the sound subsystem might be probed separately. It's set up to handle bare hardware with everything being probed from code in the machine/fabric driver. This makes life very messy for platforms with something like the device tree. As has been said, handling this properly is one of the major motivations behind ASoC v2. Ick. Ok. Nonetheless, messing up the device tree to workaround ASoC V1's silly limitations is not a good idea. The device tree must represent the hardware as much as possible. If that means we have to have a bunch of platform-specific hacks to instatiate the drivers in the correct order / combination, that's unfortunate, but there you go. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On 1/9/08, David Gibson [EMAIL PROTECTED] wrote: On Mon, Jan 07, 2008 at 06:28:54PM +, Mark Brown wrote: On Mon, Jan 07, 2008 at 09:52:03AM -0600, Timur Tabi wrote: David Gibson wrote: Ok, but couldn't you strucutre your I2S or fabric driver so that it only becomes fully operational once the codec driver has registered with it? Not in ASoC V1. You have to understand, ASoC V1 was designed without any consideration for runtime-bindings and other OF goodies. All connections between the drivers are static, literally. In fact, I wouldn't be surprised if some ASoC drivers cannot be compiled as modules. I'd just like to emphasise this point - ASoC v1 really doesn't understand the idea that the components of the sound subsystem might be probed separately. It's set up to handle bare hardware with everything being probed from code in the machine/fabric driver. This makes life very messy for platforms with something like the device tree. As has been said, handling this properly is one of the major motivations behind ASoC v2. Ick. Ok. Nonetheless, messing up the device tree to workaround ASoC V1's silly limitations is not a good idea. The device tree must represent the hardware as much as possible. If that means we have to have a bunch of platform-specific hacks to instatiate the drivers in the correct order / combination, that's unfortunate, but there you go. ASOC v2 is sitting on a Wolfson server out of tree. I have been using it for several months without problem. The pace of it being merged could probably be sped up. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On Fri, Jan 04, 2008 at 08:43:17PM -0600, Timur Tabi wrote: Mark Brown wrote: In other words, ... clock1 = 0, bb8000 clock2 = 1, 653230 clock23 = 0, ab2372 Yes, something like that would cover it. I'm not sure what is idiomatic for the device tree. and of course the ordering matters. Ok, you got me there. But then, isn't this just another example where the device tree is incapable of describing a complex configuration, and so we need a platform driver? Yes, you could certainly do that - as you say, any device tree based configuration would be optional so it's not a blocker if some things aren't supported. It'd be nice to have some idea of how to handle it should someone want to do it but I wouldn't think it's essential. The most common case where specific ordering is required is that a PLL will need to have all its inputs configured before the PLL is activated so it'd probably cover a large proportion of cases to do that last. Indeed. Providing the device tree stuff doesn't get set in stone I'm not sure we need to nail this down perfectly for ASoC v1 when we're running into trouble working around it. I definitely agree with that. I'll be the first to admit that this driver, much like ASoC V1, is a prototype. Yes, from an ASoC point of view the driver looks good as it is. The only discussion is about the PowerPC probing stuff. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On Sun, Jan 06, 2008 at 11:46:37AM +1100, David Gibson wrote: Ok, but couldn't you strucutre your I2S or fabric driver so that it only becomes fully operational once the codec driver has registered with it? That's what ASoC v2 is doing, more or less (the core brings things on line rather than drivers doing it). For v1 so long as it doesn't cause any problems in practice I'm not sure I'd worry about it too much. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
David Gibson wrote: Ok, but couldn't you strucutre your I2S or fabric driver so that it only becomes fully operational once the codec driver has registered with it? Not in ASoC V1. You have to understand, ASoC V1 was designed without any consideration for runtime-bindings and other OF goodies. All connections between the drivers are static, literally. In fact, I wouldn't be surprised if some ASoC drivers cannot be compiled as modules. So all I'm trying to do now is get my driver, with warts and all, into the tree so that I can focus with Liam et al to get a real ASoC V2 up and running. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On Mon, Jan 07, 2008 at 09:52:03AM -0600, Timur Tabi wrote: David Gibson wrote: Ok, but couldn't you strucutre your I2S or fabric driver so that it only becomes fully operational once the codec driver has registered with it? Not in ASoC V1. You have to understand, ASoC V1 was designed without any consideration for runtime-bindings and other OF goodies. All connections between the drivers are static, literally. In fact, I wouldn't be surprised if some ASoC drivers cannot be compiled as modules. I'd just like to emphasise this point - ASoC v1 really doesn't understand the idea that the components of the sound subsystem might be probed separately. It's set up to handle bare hardware with everything being probed from code in the machine/fabric driver. This makes life very messy for platforms with something like the device tree. As has been said, handling this properly is one of the major motivations behind ASoC v2. So all I'm trying to do now is get my driver, with warts and all, into the tree so that I can focus with Liam et al to get a real ASoC V2 up and running. This is certainly the approach we want to take from an ASoC point of view. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
Liam Girdwood wrote: On Mon, 2008-01-07 at 09:52 -0600, Timur Tabi wrote: So all I'm trying to do now is get my driver, with warts and all, into the tree so that I can focus with Liam et al to get a real ASoC V2 up and running. I'll commit the MPC8610 into the ASoC (v1) dev tree soon (hopefully tonight). This will allow folks to use it in the meantime whilst we sort out any changes. I'm working on some minor updates, so hold off for now. I'll post a new patch later this afternoon. I'll then port (what I can) to V2, although I may need some assistance with some of the PPC sections. I'll be 100% available for that. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On Mon, 2008-01-07 at 09:52 -0600, Timur Tabi wrote: So all I'm trying to do now is get my driver, with warts and all, into the tree so that I can focus with Liam et al to get a real ASoC V2 up and running. I'll commit the MPC8610 into the ASoC (v1) dev tree soon (hopefully tonight). This will allow folks to use it in the meantime whilst we sort out any changes. I'll then port (what I can) to V2, although I may need some assistance with some of the PPC sections. Fwiw we are looking at submitting V2 in March/April time. Liam PS. Sorry for the silence lately. We've just moved to a new opensource server over the holidays and have been without some services i.e. mail. Privacy Confidentiality Notice - This message and any attachments contain privileged and confidential information that is intended solely for the person(s) to whom it is addressed. If you are not an intended recipient you must not: read; copy; distribute; discuss; take any action in or make any reliance upon the contents of this message; nor open or read any attachment. If you have received this message in error, please notify us as soon as possible on the following telephone number and destroy this message including any attachments. Thank you. - Wolfson Microelectronics plc Tel: +44 (0)131 272 7000 Fax: +44 (0)131 272 7001 Web: www.wolfsonmicro.com Registered in Scotland Company number SC089839 Registered office: Westfield House, 26 Westfield Road, Edinburgh, EH11 2QB, UK ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On Fri, Jan 04, 2008 at 08:39:54PM -0600, Timur Tabi wrote: David Gibson wrote: And what distinction are you drawing between first and second here? Oh, that's an easy one: The CS4270 can work without an I2C or SPI connection, but it will never work without an I2S connection. Why would the I2S need to scan for codecs? Wouldn't it be up to the codec driver to register with I2S? Not in ASoC V1. The codec driver registers with ASoC, but the actual connection to other devices (e.g. the I2S driver) is done either in the I2S driver or in the fabric driver, depending on your mood. And that connection is done via a pointer to a structure in the codec driver. Ok, but couldn't you strucutre your I2S or fabric driver so that it only becomes fully operational once the codec driver has registered with it? -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On Fri, Jan 04, 2008 at 10:47:25AM +1100, David Gibson wrote: On Thu, Jan 03, 2008 at 12:16:19PM -0600, Timur Tabi wrote: I'm no expert on this, but I think from the PowerPC point-of-view, the *ideal* situation would be if the ASoC fabric driver were generic, maybe even part of ASoC itself, and everything it needed could be obtained from the device tree. Nice idea in principle, and may be the way to go ultimately, but very tricky in practice. The whole reason the fabric driver concept exists (from other archs) is that there are an awful lot of variants on how to wire the sound components together. Devising a way of expressing those connections in the device tree that's sufficient will be very curly. Then we'd have to build the fabric driver that can parse and process them all. Yes, there's an issue with complexity here. Some of the individual components are going to have quite a lot of different things to configure by themselves even for static use and the choices made may depend on the usage at run time rather than being a static property of the hardware. It's also more than just connections - many machine drivers will provide control for components like analogue switches or simple amplifiers controlled through GPIO lines or memory mapped registers (these are generally specific to the board). As a result I would expect that you will always have systems using platform based drivers. I don't think that this is a bad thing - something that can completely replace them would be able to do anything that can be done in C in the kernel. And then, people will no doubt produce device trees with errors in the connection information, so we'll still need platform-specific workarounds. The other concern with this is that it risks turning the interface to the codec and controller drivers into an ABI which isn't expected at the minute and might cause problems in the future. At the minute the drivers export constants to their users defining the parameters they can configure and (for things like source selection) the possible values. These can currently be changed at will and there's no great consistency in their values between drivers. There would also be difficulties in writing the device tree - without the symbolic names you're going to end up with strings of numeric constants in the device tree which are not going to be terribly readable and will be error prone. If we want sound working any time soon, we'll want to stick with the platform based fabric drivers for the time being. Like I say, I would expect that you're always going to want to have platform based drivers. Even if a given board can be represented in a device tree some users will find it more straightforward or convenient to write C code for their platform and have the device tree specify more basic configuration options that correspond to the things they want to vary between boards. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
David Gibson wrote: And what distinction are you drawing between first and second here? Oh, that's an easy one: The CS4270 can work without an I2C or SPI connection, but it will never work without an I2S connection. Why would the I2S need to scan for codecs? Wouldn't it be up to the codec driver to register with I2S? Not in ASoC V1. The codec driver registers with ASoC, but the actual connection to other devices (e.g. the I2S driver) is done either in the I2S driver or in the fabric driver, depending on your mood. And that connection is done via a pointer to a structure in the codec driver. -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
Mark Brown wrote: Each individual call to set_sysclk() only takes three parameters but it can be called repeatedly and some configurations are going to require this. In other words, ... clock1 = 0, bb8000 clock2 = 1, 653230 clock23 = 0, ab2372 and of course the ordering matters. Ok, you got me there. But then, isn't this just another example where the device tree is incapable of describing a complex configuration, and so we need a platform driver? Indeed. Providing the device tree stuff doesn't get set in stone I'm not sure we need to nail this down perfectly for ASoC v1 when we're running into trouble working around it. I definitely agree with that. I'll be the first to admit that this driver, much like ASoC V1, is a prototype. -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
Mark Brown wrote: The machine support code (fabric driver in PowerPC terms, I think?) tells the core how everything is connected together by registering devices representing the links (eg, I2S) between the codecs, CPU and other devices. The ASoC core is then responsible for ensuring that all the required components are present before it registers with the ALSA core. I'm no expert on this, but I think from the PowerPC point-of-view, the *ideal* situation would be if the ASoC fabric driver were generic, maybe even part of ASoC itself, and everything it needed could be obtained from the device tree. -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
Mark Brown wrote: clock1 = 0, bb8000 Would that be better? To cover everything you'd need to be able to specify all the clocking parameters, especially a PLL configuration, and also specify more than one of each item. Even then you'd still have problems like... The ASoC V1 API for communicating clock data from the fabric driver to the codec driver only allows for three parameters. According to the documentation in your patch the bus frequency should already be optional My code does not currently support that configuration, and I don't have any hardware that works that way, so I don't know what it would look like. I'm just trying to make the driver as flexible as possible, given ASoC V1 constraints. -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On Thu, Jan 03, 2008 at 12:23:08PM -0600, Timur Tabi wrote: Mark Brown wrote: To cover everything you'd need to be able to specify all the clocking parameters, especially a PLL configuration, and also specify more than one of each item. Even then you'd still have problems like... The ASoC V1 API for communicating clock data from the fabric driver to the codec driver only allows for three parameters. Each individual call to set_sysclk() only takes three parameters but it can be called repeatedly and some configurations are going to require this. There's also the set_pll() call which will be required by some things too (and again that can support multiple PLLs). For example, something like this isn't unknown: - Set PLL input to pin A. - Configure PLL input/output frequencies. - Set codec system clock source to be the PLL and of course the ordering matters. You can also have other dividers and clock sources within the codec which need configuring and other components outside the codec which need configuring to supply the clocks to the codec. According to the documentation in your patch the bus frequency should already be optional My code does not currently support that configuration, and I don't have any hardware that works that way, so I don't know what it would look like. I'm just trying to make the driver as flexible as possible, given ASoC V1 constraints. Indeed. Providing the device tree stuff doesn't get set in stone I'm not sure we need to nail this down perfectly for ASoC v1 when we're running into trouble working around it. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On Thu, Jan 03, 2008 at 01:18:31PM -0600, Scott Wood wrote: Grant Likely wrote: Gah! Don't do that! Then you need to maintain both directions in the dts file. Software is good at generating reverse mappings. Software is, however, lousy at correctly wading through poorly-structured data (which device trees are full of) to figure out how to locate the link it wants to follow backwards. Thinking about that from an ASoC v2 perspective the approach that this immediately suggests is to represent the links between the devices in the device tree and then have those links reference the attached devices. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On Thu, Jan 03, 2008 at 12:16:19PM -0600, Timur Tabi wrote: Mark Brown wrote: The machine support code (fabric driver in PowerPC terms, I think?) tells the core how everything is connected together by registering devices representing the links (eg, I2S) between the codecs, CPU and other devices. The ASoC core is then responsible for ensuring that all the required components are present before it registers with the ALSA core. I'm no expert on this, but I think from the PowerPC point-of-view, the *ideal* situation would be if the ASoC fabric driver were generic, maybe even part of ASoC itself, and everything it needed could be obtained from the device tree. Nice idea in principle, and may be the way to go ultimately, but very tricky in practice. The whole reason the fabric driver concept exists (from other archs) is that there are an awful lot of variants on how to wire the sound components together. Devising a way of expressing those connections in the device tree that's sufficient will be very curly. Then we'd have to build the fabric driver that can parse and process them all. And then, people will no doubt produce device trees with errors in the connection information, so we'll still need platform-specific workarounds. If we want sound working any time soon, we'll want to stick with the platform based fabric drivers for the time being. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On Wed, Jan 02, 2008 at 09:10:44AM -0600, Timur Tabi wrote: Jon Smirl wrote: Does this need to be bus-frequency? It's always called MCLK in all of the literature. I'm trying to make this node as generic as possible. The fabric driver is the one that will parse this node and pass the data to the codec driver, so I can't use any codec-specific terms. The API from the fabric driver for passing clock information includes a clock ID, a direction, and a frequency. I can do something like this: clock1 = 0, bb8000 Would that be better? To cover everything you'd need to be able to specify all the clocking parameters, especially a PLL configuration, and also specify more than one of each item. Even then you'd still have problems like... In my case the MCLK comes from a chip on the i2c bus that is programmable How would that be encoded?. I'm going under the assumption that MCLK does not change once the board is up and running. In your case, you'd need to do something quite different, because you're not reading the clock info from the device tree and passing it to the codec at initialization once. If you want to define an extension to the 'codec' child node that handles that, I'll add it to the documentation. According to the documentation in your patch the bus frequency should already be optional (though I don't immediately see that in the code, but then I'm entirely unfamiliar with OpenFirmware device trees). Boards that reconfigure the clocking at run time can then provide code to set the clocking up at the appropriate times, which is probably what they want anyway. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On Wed, Jan 02, 2008 at 09:28:12AM -0700, Grant Likely wrote: On 1/2/08, Timur Tabi [EMAIL PROTECTED] wrote: However, it doesn't make sense to have a node in the device tree for the fabric driver, because there is no such device. The fabric driver is an abstraction. So I need to chose some other node to probe the fabric driver with. I chose the SSI, since each SSI can have only one codec. I'm not sure I'd go so far as to say that the fabric/machine driver is purely an abstraction. It does represent real hardware, often with software control. Does that mean with ASoC V2 you can instantiate it with the board specific platform code instead? I think that is the consensus we were leaning towards in the last discussion about this issue. With ASoC v2 rather than having a single monolithic ASoC device which probes everything ASoC is converted into a proper subsystem with each component (codec, SoC CPU port, whatever) having a sysfs-visible driver. These drivers register with the core as they are probed with the probing happening through whatever mechanism is appropriate for the driver. The machine support code (fabric driver in PowerPC terms, I think?) tells the core how everything is connected together by registering devices representing the links (eg, I2S) between the codecs, CPU and other devices. The ASoC core is then responsible for ensuring that all the required components are present before it registers with the ALSA core. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
Lee Revell wrote: Please use DMA_32BIT_MASK (see include/linux/dma-mapping.h) instead of 0x. No prob. But did you see this comment: /* * NOTE: do not use the below macros in new code and do not add new definitions * here. * * Instead, just open-code DMA_BIT_MASK(n) within your driver */ So I guess I should use DMA_BIT_MASK(32) instead. I've personally fixed a heisenbug in an ALSA driver caused by incorrectly typed DMA mask... Can you explain to me what all of this does? Is it okay to use a static u64 variable? Why do so many drivers do it that way? I don't even know if 0x is the right number for my platform. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
At Thu, 20 Dec 2007 08:24:35 -0600,
Timur Tabi wrote:
+static int fsl_dma_new(struct snd_card *card, struct snd_soc_codec_dai
*dai,
+ struct snd_pcm *pcm)
+{
+ static u64 fsl_dma_dmamask = 0x;
+ int ret;
+
+ if (!card-dev-dma_mask)
+ card-dev-dma_mask = fsl_dma_dmamask;
I haven't read how your channel allocation works, but providing a
pointer to a local static variable is a bit fishy no matter what.
I just copied this code from another module. All the ALSA drivers do this,
All? No, only a few...
For PCI, usually pci_set_dma_mask() and pci_set_consistent_dma_mask()
are used, of course.
Takashi
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
Takashi Iwai wrote: All? No, only a few... For PCI, usually pci_set_dma_mask() and pci_set_consistent_dma_mask() are used, of course. Hmm, ok I was wrong. I took this code from the ASoC at91 driver. Unfortunately, I don't understand what this code is trying to do. The AT91 driver isn't documented, so I don't even know if I need it. Can someone explain what all this is? What's the alternative to using a static global? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On Dec 20, 2007 8:54 AM, Takashi Iwai [EMAIL PROTECTED] wrote:
At Thu, 20 Dec 2007 08:24:35 -0600,
Timur Tabi wrote:
+static int fsl_dma_new(struct snd_card *card, struct snd_soc_codec_dai
*dai,
+ struct snd_pcm *pcm)
+{
+ static u64 fsl_dma_dmamask = 0x;
+ int ret;
+
+ if (!card-dev-dma_mask)
+ card-dev-dma_mask = fsl_dma_dmamask;
I haven't read how your channel allocation works, but providing a
pointer to a local static variable is a bit fishy no matter what.
I just copied this code from another module. All the ALSA drivers do this,
All? No, only a few...
For PCI, usually pci_set_dma_mask() and pci_set_consistent_dma_mask()
are used, of course.
Timur,
Nicely commented driver! I wish they were all like this ;-)
Please use DMA_32BIT_MASK (see include/linux/dma-mapping.h) instead of
0x. I've personally fixed a heisenbug in an ALSA driver
caused by incorrectly typed DMA mask...
Lee
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
