How to handle parameter variation across different boards but same platform

How to handle parameter variation across different boards but same platform

[Hebbar, Gururaja]

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

How to handle parameter variation across different boards but same platform

[Hebbar, Gururaja]

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

Re: How to handle parameter variation across different boards but same platform

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 509 bytes --]

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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

How to handle parameter variation across different boards but same platform

[Mark Brown]

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>

Re: How to handle parameter variation across different boards but same platform

[Hebbar, Gururaja]

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

How to handle parameter variation across different boards but same platform

[Hebbar, Gururaja]

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

Re: How to handle parameter variation across different boards but same platform

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 958 bytes --]

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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

How to handle parameter variation across different boards but same platform

[Mark Brown]

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>

Re: How to handle parameter variation across different boards but same platform

[Hebbar, Gururaja]

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

How to handle parameter variation across different boards but same platform

[Hebbar, Gururaja]

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

Re: How to handle parameter variation across different boards but same platform

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 979 bytes --]

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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

How to handle parameter variation across different boards but same platform

[Mark Brown]

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>

Re: How to handle parameter variation across different boards but same platform

[Vaibhav Hiremath]

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-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
> 

How to handle parameter variation across different boards but same platform

[Vaibhav Hiremath]

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
> 

Re: How to handle parameter variation across different boards but same platform

[Arnd Bergmann]

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

How to handle parameter variation across different boards but same platform

[Arnd Bergmann]

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

Re: How to handle parameter variation across different boards but same platform

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 475 bytes --]

On Thu, Jul 05, 2012 at 08:32:16AM +0000, Arnd Bergmann wrote:
> On Thursday 05 July 2012, Vaibhav Hiremath wrote:

> > 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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

How to handle parameter variation across different boards but same platform

[Mark Brown]

On Thu, Jul 05, 2012 at 08:32:16AM +0000, Arnd Bergmann wrote:
> On Thursday 05 July 2012, Vaibhav Hiremath wrote:

> > 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>