* How to handle parameter variation across different boards but same platform
@ 2012-07-04 12:45 Hebbar, Gururaja
2012-07-04 13:17 ` Mark Brown
0 siblings, 1 reply; 9+ messages in thread
From: Hebbar, Gururaja @ 2012-07-04 12:45 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* How to handle parameter variation across different boards but same platform
2012-07-04 12:45 How to handle parameter variation across different boards but same platform Hebbar, Gururaja
@ 2012-07-04 13:17 ` Mark Brown
2012-07-04 13:43 ` Hebbar, Gururaja
0 siblings, 1 reply; 9+ messages in thread
From: Mark Brown @ 2012-07-04 13:17 UTC (permalink / raw)
To: linux-arm-kernel
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>
^ permalink raw reply [flat|nested] 9+ messages in thread
* How to handle parameter variation across different boards but same platform
2012-07-04 13:17 ` Mark Brown
@ 2012-07-04 13:43 ` Hebbar, Gururaja
2012-07-04 14:01 ` Mark Brown
0 siblings, 1 reply; 9+ messages in thread
From: Hebbar, Gururaja @ 2012-07-04 13:43 UTC (permalink / raw)
To: linux-arm-kernel
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.
>
> > 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.
>
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* How to handle parameter variation across different boards but same platform
2012-07-04 13:43 ` Hebbar, Gururaja
@ 2012-07-04 14:01 ` Mark Brown
2012-07-04 14:17 ` Hebbar, Gururaja
0 siblings, 1 reply; 9+ messages in thread
From: Mark Brown @ 2012-07-04 14:01 UTC (permalink / raw)
To: linux-arm-kernel
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:
> > 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?
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>
^ permalink raw reply [flat|nested] 9+ messages in thread
* How to handle parameter variation across different boards but same platform
2012-07-04 14:01 ` Mark Brown
@ 2012-07-04 14:17 ` Hebbar, Gururaja
2012-07-04 14:27 ` Mark Brown
0 siblings, 1 reply; 9+ messages in thread
From: Hebbar, Gururaja @ 2012-07-04 14:17 UTC (permalink / raw)
To: linux-arm-kernel
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:
> > On Wed, Jul 04, 2012 at 18:47:50, Mark Brown wrote:
>
> > > 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?
>
> 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?
>
Regards,
Gururaja
^ permalink raw reply [flat|nested] 9+ messages in thread
* How to handle parameter variation across different boards but same platform
2012-07-04 14:17 ` Hebbar, Gururaja
@ 2012-07-04 14:27 ` Mark Brown
2012-07-05 5:42 ` Vaibhav Hiremath
0 siblings, 1 reply; 9+ messages in thread
From: Mark Brown @ 2012-07-04 14:27 UTC (permalink / raw)
To: linux-arm-kernel
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:
> > 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>
^ permalink raw reply [flat|nested] 9+ messages in thread
* How to handle parameter variation across different boards but same platform
2012-07-04 14:27 ` Mark Brown
@ 2012-07-05 5:42 ` Vaibhav Hiremath
2012-07-05 8:32 ` Arnd Bergmann
0 siblings, 1 reply; 9+ messages in thread
From: Vaibhav Hiremath @ 2012-07-05 5:42 UTC (permalink / raw)
To: linux-arm-kernel
On 7/4/2012 7:57 PM, Mark Brown wrote:
> 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:
>
>>> 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().
>
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.
>
>> 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
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* How to handle parameter variation across different boards but same platform
2012-07-05 5:42 ` Vaibhav Hiremath
@ 2012-07-05 8:32 ` Arnd Bergmann
2012-07-05 9:38 ` Mark Brown
0 siblings, 1 reply; 9+ messages in thread
From: Arnd Bergmann @ 2012-07-05 8:32 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 05 July 2012, Vaibhav Hiremath wrote:
> On 7/4/2012 7:57 PM, Mark Brown wrote:
> > 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:
> >
> >>> 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().
> >
>
> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-07-05 9:38 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-07-04 12:45 How to handle parameter variation across different boards but same platform Hebbar, Gururaja
2012-07-04 13:17 ` Mark Brown
2012-07-04 13:43 ` Hebbar, Gururaja
2012-07-04 14:01 ` Mark Brown
2012-07-04 14:17 ` Hebbar, Gururaja
2012-07-04 14:27 ` Mark Brown
2012-07-05 5:42 ` Vaibhav Hiremath
2012-07-05 8:32 ` Arnd Bergmann
2012-07-05 9:38 ` Mark Brown
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).