hi,
Currently on Davinci platform, codec system clock & snd_soc_card parameter is decided
using machine_is_xxxx() api.
sound/soc/Davinci/davinci-evm.c, inside evm_hw_params() & evm_init(),
We have an upcoming board based on TI AM335x soc which has both codec system clock
And the codec name (because of i2c bus difference) different from previous am335x
based boards.
Using machine_is_xxx() is not sufficient because there are 2 other boards on same
Platform/machine but with different values.
So, how to specify these parameters for the new board?
Regards
Gururaja
From: Mark Brown <hidden> Date: 2012-07-04 13:17:50
On Wed, Jul 04, 2012 at 12:45:03PM +0000, Hebbar, Gururaja wrote:
You should fix your mailer to word wrap at less than 80 columns.
Using machine_is_xxx() is not sufficient because there are 2 other
boards on same Platform/machine but with different values.
So, how to specify these parameters for the new board?
What do you mean by "board"? If these are plugin modules for your
platform you need to either identify this at runtime and register a
different machine driver or select at compile time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120704/076061df/attachment-0001.sig>
On Wed, Jul 04, 2012 at 18:47:50, Mark Brown wrote:
On Wed, Jul 04, 2012 at 12:45:03PM +0000, Hebbar, Gururaja wrote:
You should fix your mailer to word wrap at less than 80 columns.
Sorry. Stupid outlook. Will take care of it manually.
quoted
Using machine_is_xxx() is not sufficient because there are 2 other
boards on same Platform/machine but with different values.
quoted
So, how to specify these parameters for the new board?
What do you mean by "board"? If these are plugin modules for your
platform you need to either identify this at runtime and register a
different machine driver or select at compile time.
By board I mean a new development board.
New board
sysclk = 24MHz
codec_name = "tlv320aic3x-codec.1-001b"
Previous Board
sysclk = 12MHz
.codec_name = "tlv320aic3x-codec.2-001b",
Both boards share the same machine is API (machine_is_am33xx()).
So, is there any mechanism/api to differentiate these 2 boards inside
Code?
Has anyone else faced such situation?
Regards,
Gururaja
From: Mark Brown <hidden> Date: 2012-07-04 14:01:18
On Wed, Jul 04, 2012 at 01:43:12PM +0000, Hebbar, Gururaja wrote:
On Wed, Jul 04, 2012 at 18:47:50, Mark Brown wrote:
quoted
What do you mean by "board"? If these are plugin modules for your
platform you need to either identify this at runtime and register a
different machine driver or select at compile time.
By board I mean a new development board.
New board
sysclk = 24MHz
codec_name = "tlv320aic3x-codec.1-001b"
Both boards share the same machine is API (machine_is_am33xx()).
So, is there any mechanism/api to differentiate these 2 boards inside
Code?
Has anyone else faced such situation?
If these are totally different boards they should have different machine
IDs set so machine_is_() should identify. If that isn't there then you
need to do something custom to your products to identify the boards
further.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120704/6089f919/attachment.sig>
On Wed, Jul 04, 2012 at 19:31:18, Mark Brown wrote:
On Wed, Jul 04, 2012 at 01:43:12PM +0000, Hebbar, Gururaja wrote:
quoted
On Wed, Jul 04, 2012 at 18:47:50, Mark Brown wrote:
quoted
quoted
What do you mean by "board"? If these are plugin modules for your
platform you need to either identify this at runtime and register a
different machine driver or select at compile time.
quoted
By board I mean a new development board.
quoted
New board
sysclk = 24MHz
codec_name = "tlv320aic3x-codec.1-001b"
Both boards share the same machine is API (machine_is_am33xx()).
quoted
So, is there any mechanism/api to differentiate these 2 boards inside
Code?
quoted
Has anyone else faced such situation?
If these are totally different boards they should have different machine
IDs set so machine_is_() should identify. If that isn't there then you
need to do something custom to your products to identify the boards
further.
They are different boards with same SoC (AM33xx). So they both are true for
machine_is_am33xx().
We have a means to detect the type of board but in arch/arm/mach-omap2/
board file. However, I believe it is not recommended to call boards api
inside drivers.
Can you give me more info about the "custom option" you suggested?
From: Mark Brown <hidden> Date: 2012-07-04 14:27:45
On Wed, Jul 04, 2012 at 02:17:48PM +0000, Hebbar, Gururaja wrote:
On Wed, Jul 04, 2012 at 19:31:18, Mark Brown wrote:
quoted
If these are totally different boards they should have different machine
IDs set so machine_is_() should identify. If that isn't there then you
need to do something custom to your products to identify the boards
further.
They are different boards with same SoC (AM33xx). So they both are true for
machine_is_am33xx().
That's not how this stuff is supposed to work - machine is the board,
you should have cpu_is_() for identifying the SoC.
We have a means to detect the type of board but in arch/arm/mach-omap2/
board file. However, I believe it is not recommended to call boards api
inside drivers.
Only for generic drivers, board specific drivers are obviously board
specific. The point is that you shouldn't make something that could run
on many boards depend on an API specific to a particular board.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120704/1c0b65e9/attachment-0001.sig>
On Wed, Jul 04, 2012 at 02:17:48PM +0000, Hebbar, Gururaja wrote:
quoted
On Wed, Jul 04, 2012 at 19:31:18, Mark Brown wrote:
quoted
quoted
If these are totally different boards they should have different machine
IDs set so machine_is_() should identify. If that isn't there then you
need to do something custom to your products to identify the boards
further.
quoted
They are different boards with same SoC (AM33xx). So they both are true for
machine_is_am33xx().
What if the device only supports Linux boot from DT, where we set
machine_desc.nr = ~0 ??
Does machine ID still gets set? May be I am missing something...
As part of my debugging, on AM335xEVM platform machine_is_am33xx()
returns false, since the value of machine_desc.nr is set to ~0.
Thanks,
Vaibhav
That's not how this stuff is supposed to work - machine is the board,
you should have cpu_is_() for identifying the SoC.
quoted
We have a means to detect the type of board but in arch/arm/mach-omap2/
board file. However, I believe it is not recommended to call boards api
inside drivers.
Only for generic drivers, board specific drivers are obviously board
specific. The point is that you shouldn't make something that could run
on many boards depend on an API specific to a particular board.
_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source at linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
On Wed, Jul 04, 2012 at 02:17:48PM +0000, Hebbar, Gururaja wrote:
quoted
On Wed, Jul 04, 2012 at 19:31:18, Mark Brown wrote:
quoted
quoted
If these are totally different boards they should have different machine
IDs set so machine_is_() should identify. If that isn't there then you
need to do something custom to your products to identify the boards
further.
quoted
They are different boards with same SoC (AM33xx). So they both are true for
machine_is_am33xx().
What if the device only supports Linux boot from DT, where we set
machine_desc.nr = ~0 ??
Does machine ID still gets set? May be I am missing something...
No, it doesn't.
As part of my debugging, on AM335xEVM platform machine_is_am33xx()
returns false, since the value of machine_desc.nr is set to ~0.
Correct. However, when you are booting using the device tree, parameters
such as the clock frequency of a device should be encoded in the device
tree itself, so you don't need to know which machine you are on.
Arnd
From: Mark Brown <hidden> Date: 2012-07-05 09:38:08
On Thu, Jul 05, 2012 at 08:32:16AM +0000, Arnd Bergmann wrote:
On Thursday 05 July 2012, Vaibhav Hiremath wrote:
quoted
Does machine ID still gets set? May be I am missing something...
No, it doesn't.
This is a *really* unfortunate decision, BTW - it means that if your
bootloader has a device tree available it needs to know if the kernel
it's booting is DT or non-DT which is just generally unhelpful. Sadly I
don't hold out much hope of being able to fix it, though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120705/302e1c8a/attachment.sig>