QUERY: How to handle SOC Configuration (Peripheral Multiplexing) in linux

In our SOC's (SPEArxxx), we have many peripheral sharing PL_GPIO pins and so only few peripherals can be selected in a configuration. This is configurable using a set of registers. Now the problem is to make following work:

1. How to do this selection in kernel in a simple way?
2. Based on this selection hardware registers needs to be configured.

Quoted 4 lines · Viresh KUMAR

In our SOC's (SPEArxxx), we have many peripheral sharing PL_GPIO pins and so only few peripherals can be selected in a configuration. This is configurable using a set of registers. Now the problem is to make following work:

Quoted 2 lines

1. How to do this selection in kernel in a simple way?
2. Based on this selection hardware registers needs to be configured.

Why can't you make the drivers acquire and setup the necessary pins during probe?
Among other benefits, it enables you to use the same kernel image and device drivers as modules -- if a GPIO can be used by two different device controllers, you
can switch the 'mode' of the board by simple rmmod-insmod

Hello Jassi,

Quoted 5 lines · jassi brar

Quoted 4 lines · Viresh KUMAR

In our SOC's (SPEArxxx), we have many peripheral sharing PL_GPIO pins and so only few peripherals can be selected in a configuration. This is configurable using a set of registers. Now the problem is to make following work:

Quoted 8 lines

Quoted 2 lines

1. How to do this selection in kernel in a simple way?
2. Based on this selection hardware registers needs to be configured.

Why can't you make the drivers acquire and setup the necessary pins during probe?
Among other benefits, it enables you to use the same kernel image and device drivers as modules -- if a GPIO can be used by two different device controllers, you
can switch the 'mode' of the board by simple rmmod-insmod

I think the problem is we cannot change the standard drivers (already in the mainline). So if the standard driver doesn't support this in its probe, then how should we manage this?

Further these configurations are board dependent, so I think driver must be independent of this.

Quoted 17 lines · Shiraz HASHIM

Hello Jassi,

Quoted 5 lines · jassi brar

Quoted 4 lines · Viresh KUMAR

In our SOC's (SPEArxxx), we have many peripheral sharing PL_GPIO pins and so only few peripherals can be selected in a configuration. This is configurable using a set of registers. Now the problem is to make following work:

Quoted 8 lines

Quoted 2 lines

1. How to do this selection in kernel in a simple way?
2. Based on this selection hardware registers needs to be configured.

Why can't you make the drivers acquire and setup the necessary pins during probe?
Among other benefits, it enables you to use the same kernel image and device drivers as modules -- if a GPIO can be used by two different device controllers, you
can switch the 'mode' of the board by simple rmmod-insmod

Quoted 3 lines

I think the problem is we cannot change the standard drivers (already in the mainline). So if the standard driver doesn't support this in its probe, then how should we manage this?

Though the drivers should already have done that, but still you can always submit patches to improve.

Quoted 2 lines

Further these configurations are board dependent, so I think driver must be independent of this.

Don't really understand this. Viresh said that the SoC can configure GPIOs for a controller or the other, which is quite common and is handled during probe. Also, it's desirable to have one kernel image run on many machines with the same SOC.

Quoted 26 lines · jassi brar

Quoted 17 lines · Shiraz HASHIM

Hello Jassi,

Quoted 5 lines · jassi brar

Quoted 4 lines · Viresh KUMAR

In our SOC's (SPEArxxx), we have many peripheral sharing PL_GPIO pins and so only few peripherals can be selected in a configuration. This is configurable using a set of registers. Now the problem is to make following work:

Quoted 8 lines

Quoted 2 lines

1. How to do this selection in kernel in a simple way?
2. Based on this selection hardware registers needs to be configured.

Why can't you make the drivers acquire and setup the necessary pins during probe?
Among other benefits, it enables you to use the same kernel image and device drivers as modules -- if a GPIO can be used by two different device controllers, you
can switch the 'mode' of the board by simple rmmod-insmod

Quoted 3 lines

I think the problem is we cannot change the standard drivers (already in the mainline). So if the standard driver doesn't support this in its probe, then how should we manage this?

Though the drivers should already have done that, but still you can always submit patches to improve.

Quoted 2 lines

Further these configurations are board dependent, so I think driver must be independent of this.

Quoted 5 lines

Don't really understand this. Viresh said that the SoC can configure GPIOs for a controller or the other, which is quite common and is handled during probe. Also, it's desirable to have one kernel image run on many machines with the same SOC.

Actually, different peripherals share IO Pads (PL_GPIOs) and GPIO lines. Sending patch for drivers to support this doesn't look a great idea to me.

Further this
may cause problems to users, for example: User have entered a inserted a module and by mistake or lack of knowledge, he disables already working IP. Now with Kconfig concept this is taken care of at the beginning only. User can't select peripherals which can't be enabled simultaneously.

Actually, different peripherals share IO Pads (PL_GPIOs) and GPIO lines. Sending patch for drivers to support this doesn't look a great idea to me. Further this may cause problems to users, for example: User have entered a inserted a module and by mistake or lack of knowledge, he disables already working IP. Now with Kconfig concept this is taken care of at the beginning only. User can't select peripherals which can't be enabled simultaneously.

Actually, different peripherals share IO Pads (PL_GPIOs) and GPIO lines. Sending patch for drivers to support this doesn't look a great idea to me. Further this may cause problems to users, for example: User have entered a inserted a module and by mistake or lack of knowledge, he disables already working IP.

Most normal boards dedicate the function of pins at board design time;

On Mon, Mar 15, 2010 at 12:02:14PM +0530, Viresh KUMAR wrote:
That means if you leave the configuration of pins to modular drivers, pins are left unconfigured, and you could have some of them floating increasing your power consumption.

I think the problem is we cannot change the standard drivers (already in the mainline). So if the standard driver doesn't support this in its probe, then how should we manage this?

Further these configurations are board dependent, so I think driver must be independent of this.

What I think you really want is for your board-specific code (or some helper code elsewhere in your mach-* directory) to do the pin assignments, and the drivers just assume that the pins are all right. That's the approach used in OMAP2 and AT91, among others, and it seems to work out just fine.

If you assume that the driver "just knows" what the multiplexer settings need to be, then sooner or later that same peripheral gets used in a different SoC and that assumption has to get tossed out. That's happening some with the AT91 drivers that can also be used on AVR32 chips. Best to avoid that extra work by putting the platform-specific knowledge where it belongs: in the platform-specific code.

Quoted 7 lines

What I think you really want is for your board-specific code (or some helper code elsewhere in your mach-* directory) to do the pin assignments, and the drivers just assume that the pins are all right. That's the approach used in OMAP2 and AT91, among others, and it seems to work out just fine.

Bill,

What you and Russell are saying is a little bit different from what I got since
now, with people suggesting to implement a single linux image which is then configured at runtime thru (for example) bootargs.

Now you both are saying that compile time options are better, correct?

So, we have two choices:

1. Stay as it is, which means to use menuconfig options.
2. Provide board-specific code in the mach-spear directory.

You are suggesting 2, which also seems to be the pin_config stuff inside mach-pxa. Am I aligned?

Now you both are saying that compile time options are better, correct?

So, we have two choices:

1. Stay as it is, which means to use menuconfig options.
2. Provide board-specific code in the mach-spear directory.

You are suggesting 2, which also seems to be the pin_config stuff inside mach-pxa. Am I aligned?

Quoted 7 lines

If you assume that the driver "just knows" what the multiplexer settings need to be, then sooner or later that same peripheral gets used in a different SoC and that assumption has to get tossed out. That's happening some with the AT91 drivers that can also be used on AVR32 chips. Best to avoid that extra work by putting the platform-specific knowledge where it belongs: in the platform-specific code.

Correct.

I think this has never been our intention anyway.
The drivers shouldn't know anything about platform-specific stuff, as they are expected to work across multiple platform.

It's true that for a specific SoC, you *do* know such things. So you handle that the way the at91 guys have done: you provide a at91sam9263_devices.c:at91_add_device_usbh(struct at91_usbh_data *data), and _that_ function sets up pins, etc. before it registers the generic platform device. The driver is always a generic platform one, and gets

Quoted 5 lines · Bill Gatliff

It's true that for a specific SoC, you *do* know such things. So you handle that the way the at91 guys have done: you provide a at91sam9263_devices.c:at91_add_device_usbh(struct at91_usbh_data *data), and _that_ function sets up pins, etc. before it registers the generic platform device. The driver is always a generic platform one, and gets

That does depend on the SoC, at least for the pin muxing - with some SoCs there's a lot of options for where the signals are brought out so the pin mux configuration really does need to be board specific.

Quoted 4 lines · Mark Brown

That does depend on the SoC, at least for the pin muxing - with some SoCs there's a lot of options for where the signals are brought out so the pin mux configuration really does need to be board specific.

Additionally the muxing needs to be done dynamically in some cases.

For example, the GPIO pins need to be dynamically remuxed for the PM idle modes on omaps.

Quoted 7 lines

What I think you really want is for your board-specific code (or some helper code elsewhere in your mach-* directory) to do the pin assignments, and the drivers just assume that the pins are all right. That's the approach used in OMAP2 and AT91, among others, and it seems to work out just fine.

Bill,

What you and Russell are saying is a little bit different from what I got since
now, with people suggesting to implement a single linux image which is then configured at runtime thru (for example) bootargs.

Now you both are saying that compile time options are better, correct?

-----Original Message-----
From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-arm-kernel- bounces at lists.infradead.org] On Behalf Of Viresh KUMAR
Sent: Monday, March 15, 2010 10:02 AM
To: linux-arm-kernel at lists.infradead.org
Cc: Armando VISCONTI; 'Shiraz HASHIM'
Subject: QUERY: How to handle SOC Configuration (Peripheral Multiplexing) in linux

Hello everybody,

In our SOC's (SPEArxxx), we have many peripheral sharing PL_GPIO pins and so only few peripherals can be selected in a configuration. This is configurable using a set of registers. Now the problem is to make following work:

1. How to do this selection in kernel in a simple way?
2. Based on this selection hardware registers needs to be configured.

I propose following solution to solve this issue, but i am not sure if it is acceptable by community.

Please see if it is fine. Or if there is any other way people may already be following for similar issues.

I have provided this selection from "make menuconfig", based on selection I configure hardware at initialization time. Basically these selections will decide which device is present in the system when it boots.

There are modes in which SOC can be configured and in these modes peripherals can be selected.

Quoted 27 lines

-----Original Message-----
From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-arm-kernel- bounces at lists.infradead.org] On Behalf Of Viresh KUMAR
Sent: Monday, March 15, 2010 10:02 AM
To: linux-arm-kernel at lists.infradead.org
Cc: Armando VISCONTI; 'Shiraz HASHIM'
Subject: QUERY: How to handle SOC Configuration (Peripheral Multiplexing) in linux

Hello everybody,

In our SOC's (SPEArxxx), we have many peripheral sharing PL_GPIO pins and so only few peripherals can be selected in a configuration. This is configurable using a set of registers. Now the problem is to make following work:

1. How to do this selection in kernel in a simple way?
2. Based on this selection hardware registers needs to be configured.

I propose following solution to solve this issue, but i am not sure if it is acceptable by community.

Please see if it is fine. Or if there is any other way people may already be following for similar issues.

I have provided this selection from "make menuconfig", based on selection I configure hardware at initialization time. Basically these selections will decide which device is present in the system when it boots.

Quoted 3 lines

There are modes in which SOC can be configured and in these modes peripherals can be selected.

Since the data is board dependent, why don't you make this information as platform data for devices and pass that information from board files depending on board type.

This gives you flexibility as well and you don't need unnecessary cluttering of Kconfig entries.

-----Original Message-----
From: Shiraz HASHIM [mailto:shiraz.hashim at st.com]
Sent: Monday, March 15, 2010 10:46 AM
To: Shilimkar, Santosh
Cc: Viresh KUMAR; linux-arm-kernel at lists.infradead.org; Armando VISCONTI
Subject: Re: QUERY: How to handle SOC Configuration (Peripheral Multiplexing) in linux

Hello Santosh,

Quoted 30 lines · Santosh

Quoted 30 lines

-----Original Message-----
From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-arm-kernel- bounces at lists.infradead.org] On Behalf Of Viresh KUMAR
Sent: Monday, March 15, 2010 10:02 AM
To: linux-arm-kernel at lists.infradead.org
Cc: Armando VISCONTI; 'Shiraz HASHIM'
Subject: QUERY: How to handle SOC Configuration (Peripheral Multiplexing) in linux

Hello everybody,

In our SOC's (SPEArxxx), we have many peripheral sharing PL_GPIO pins and so only few peripherals can be selected in a configuration. This is configurable using a set of registers. Now the problem is to make following work:

1. How to do this selection in kernel in a simple way?
2. Based on this selection hardware registers needs to be configured.

I propose following solution to solve this issue, but i am not sure if it is acceptable by community.

Please see if it is fine. Or if there is any other way people may already be following for similar issues.

I have provided this selection from "make menuconfig", based on selection I configure hardware at initialization time. Basically these selections will decide which device is present in the system when it boots.

There are modes in which SOC can be configured and in these modes peripherals can be selected.

Quoted 5 lines

Since the data is board dependent, why don't you make this information as platform data for devices and pass that information from board files depending on board type.

This gives you flexibility as well and you don't need unnecessary cluttering of Kconfig entries.

But the standard drivers which are already in mainline may not support these platform data.

Quoted 3 lines

Quoted 3 lines

But the standard drivers which are already in mainline may not support these platform data.

Driver won't change major way. I was saying passing additional information via platform data to drivers. Even with Kconfig stuff, you need to touch drivers to take care of your exceptions.

Am I missing something?

Hello everybody,

In our SOC's (SPEArxxx), we have many peripheral sharing PL_GPIO pins and so only few peripherals can be selected in a configuration. This is configurable using a set of registers. Now the problem is to make following work:

1. How to do this selection in kernel in a simple way?
2. Based on this selection hardware registers needs to be configured.

I propose following solution to solve this issue, but i am not sure if it is acceptable by community.

Please see if it is fine. Or if there is any other way people may already be following for similar issues.

I have provided this selection from "make menuconfig", based on selection I configure hardware at initialization time. Basically these selections will decide which device is present in the system when it boots.

There are modes in which SOC can be configured and in these modes peripherals can be selected.

file: arch/arm/mach-spear3xx/Kconfig300

#
# SPEAr300 machine configuration file
#
if MACH_SPEAR300

choice
prompt "SPEAr300 Boards"
default BOARD_SPEAR300_EVB

config BOARD_SPEAR300_EVB
bool "SPEAr300 Evaluation Board"
help
Supports ST SPEAr300 Evaluation Board

endchoice

# SOC configuration for SPEAr 300 machine
menu "SPEAr300 SOC Configuration"

# Operation modes
choice
prompt "Select Operation Mode"
default PHOTO_FRAME_MODE

config NAND_MODE
bool "NAND Mode"
help
This mode will enable NAND Mode of SPEAr300 SOC.

config NOR_MODE
bool "NOR Mode"
help
This mode will enable NOR Mode of SPEAr300 SOC.

config PHOTO_FRAME_MODE
bool "PHOTO FRAME Mode"
help
This mode will enable PHOTO FRAME Mode of SPEAr300 SOC.

config LEND_IP_PHONE_MODE
bool "LEND IP PHONE (LOW END IP PHONE mode)" help
This mode will enable LEND IP PHONE Mode of SPEAr300 SOC.

config HEND_IP_PHONE_MODE
bool "HEND IP PHONE (HIGH END IP PHONE mode)" help
This mode will enable HEND IP PHONE Mode of SPEAr300 SOC.

config LEND_WIFI_PHONE_MODE
bool "LEND WIFI PHONE (LOW END WI-FI PHONE mode)" help
This mode will enable LEND WIFI PHONE Mode of SPEAr300 SOC.

config HEND_WIFI_PHONE_MODE
bool "HEND WIFI PHONE (HIGH END WI-FI PHONE mode)" help
This mode will enable HEND WIFI PHONE Mode of SPEAr300 SOC.

config ATA_PABX_wI2S_MODE
bool "ATA PABX wI2S (ATA PABX without I2S) mode" help
This mode will enable ATA PABX wI2S Mode of SPEAr300 SOC.

config ATA_PABX_I2S_MODE
bool "ATA PABX I2S (ATA PABX with I2S) Mode" help
This mode will enable ATA PABX I2S Mode of SPEAr300 SOC.

config CAMl_LCDw_MODE
bool "CAMl LCDw (8 bit CAMERA without LCD) Mode" help
This mode will enable CAMl LCDw Mode of SPEAr300 SOC.

config CAMu_LCD_MODE
bool "CAMu LCD (14 bit CAMERA with LCD) Mode" help
This mode will enable CAMu LCD Mode of SPEAr300 SOC.

config CAMu_wLCD_MODE
bool "CAMu wLCD (14 bit CAMERA without LCD) Mode" help
This mode will enable CAMu wLCD Mode of SPEAr300 SOC.

config CAMl_LCD_MODE
bool "CAMl LCD (8 bit CAMERA with LCD) Mode" help
This mode will enable CAMl LCD Mode of SPEAr300 SOC.

endchoice #Select Operation Mode

#mode specific peripherals
#FSMC
config FSMC_2_CHIPS

	bool "FSMC 2 CHIPS - Disables FIRDA"
	depends on NAND_MODE || NOR_MODE || PHOTO_FRAME_MODE || \
	ATA_PABX_wI2S_MODE || ATA_PABX_I2S_MODE
	depends on !FSMC_4_CHIPS
	default n

config FSMC_4_CHIPS

	bool "FSMC 4 CHIPS - Disables UART and FIRDA"
	depends on NAND_MODE || NOR_MODE || PHOTO_FRAME_MODE || \
	ATA_PABX_wI2S_MODE || ATA_PABX_I2S_MODE
	default n

#Keyboard
config KEYBOARD

	bool "Keyboard"
	depends on LEND_IP_PHONE_MODE || HEND_IP_PHONE_MODE || \
	LEND_WIFI_PHONE_MODE || HEND_WIFI_PHONE_MODE || CAMl_LCDw_MODE || \
	CAMu_LCD_MODE || CAMu_wLCD_MODE || CAMl_LCD_MODE
	default y

#CLCD
config CLCD_1
bool "CLCD - Disables TIMER 1-2 and TIMER 3-4" depends on PHOTO_FRAME_MODE
default n

config CLCD_2

	bool "CLCD - Disables TIMER 3-4"
	depends on HEND_IP_PHONE_MODE || HEND_WIFI_PHONE_MODE || \
	CAMu_LCD_MODE || CAMl_LCD_MODE
	default n

#Telecom_GPIO Combinations
config TL_GPIO_1

	bool "Telecom GPIO - Disables GMAC"
	depends on PHOTO_FRAME_MODE || CAMu_LCD_MODE || CAMl_LCD_MODE
	default n

config TL_GPIO_2

	bool "Telecom GPIO - Disables TIMER 1-2, Timer 3-4 and GMAC"
	depends on LEND_IP_PHONE_MODE || LEND_WIFI_PHONE_MODE
	default n

config TL_GPIO_3

	bool "Telecom GPIO - Disables TIMER 3-4 and GMAC"
	depends on ATA_PABX_I2S_MODE || CAMl_LCDw_MODE || CAMu_wLCD_MODE
	default n

config TL_GPIO_4

	bool "Telecom GPIO - Disables TIMER 1-2 and GMAC"
	depends on HEND_IP_PHONE_MODE || HEND_WIFI_PHONE_MODE
	default n

config TL_GPIO_5
bool "Telecom GPIO - Disables TIMER 1-2-3-4, UART MODEM and GMAC" depends on ATA_PABX_wI2S_MODE
default n

#TL_TDM Combinations
config TL_TDM

	bool "Telecom TDM - Disables UART MODEM and SSP CHIP SELECTS"
	depends on PHOTO_FRAME_MODE || LEND_IP_PHONE_MODE || \
	HEND_IP_PHONE_MODE || LEND_WIFI_PHONE_MODE || HEND_WIFI_PHONE_MODE || \
	ATA_PABX_wI2S_MODE || ATA_PABX_I2S_MODE || CAMl_LCDw_MODE || \
	CAMu_LCD_MODE || CAMu_wLCD_MODE || CAMl_LCD_MODE
	default n

#TL_SPI_I2C Combinations
config TL_SPI_I2C

	bool "Telecom SPI-CS I2C-CLK - Disables TIMER 1-2 and TIMER 3-4"
	depends on LEND_IP_PHONE_MODE || HEND_IP_PHONE_MODE || \
	LEND_WIFI_PHONE_MODE || HEND_WIFI_PHONE_MODE || ATA_PABX_wI2S_MODE || \
	ATA_PABX_I2S_MODE || CAMl_LCDw_MODE || CAMl_LCD_MODE
	default n

#TL_CAMERA Combinations
config TL_CAMERA_1

	bool "Telecom CAMERA - Disables GMAC"
	depends on CAMl_LCDw_MODE || CAMl_LCD_MODE
	default n

config TL_CAMERA_2

	bool "Telecom CAMERA - Disables TIMER 1-2, TIMER 3-4 and GMAC"
	depends on CAMu_LCD_MODE || CAMu_wLCD_MODE
	default n

#TL_DAC Combinations
config TL_DAC

	bool "Telecom DAC - Disables Timer A"
	depends on ATA_PABX_I2S_MODE || CAMl_LCDw_MODE || \
	CAMu_LCD_MODE || CAMu_wLCD_MODE || CAMl_LCD_MODE
	default n

#TL_I2S Combinations
config TL_I2S

	bool "Telecom I2S - Disables UART MODEM and SDIO"
	depends on LEND_IP_PHONE_MODE || HEND_IP_PHONE_MODE || \
	LEND_WIFI_PHONE_MODE || HEND_WIFI_PHONE_MODE || \
	ATA_PABX_I2S_MODE || CAMl_LCDw_MODE || CAMu_LCD_MODE || \
	CAMu_wLCD_MODE || CAMl_LCD_MODE
	depends on !SDIO_1_4 && !SDIO_8
	default n

#Boot Pins Combinations
config BOOT_PINS

	bool "BOOT PINS - Disables UART MODEM, TIMER 1-2 and TIMER 3-4"
	depends on NAND_MODE || NOR_MODE
	default n

#SDIO Combinations
config SDIO_1_4

	bool "SDIO 1-4 Bit - Enable GPIO1 and Disables GPIO0 Pin 0 TO 5 and I2S"
	depends on PHOTO_FRAME_MODE || LEND_IP_PHONE_MODE || \
	HEND_IP_PHONE_MODE || LEND_WIFI_PHONE_MODE || \
	HEND_WIFI_PHONE_MODE || CAMl_LCDw_MODE || \
	CAMu_LCD_MODE || CAMu_wLCD_MODE || CAMl_LCD_MODE || \
	ATA_PABX_wI2S_MODE || ATA_PABX_I2S_MODE
	depends on !SDIO_8
	select GPIO1
	default n

config SDIO_8

	bool "SDIO 8 bit - Enable GPIO1 and Disables GPIO0 Pin 0 TO 5, GMAC and I2S"
	depends on PHOTO_FRAME_MODE || LEND_IP_PHONE_MODE || \
	HEND_IP_PHONE_MODE || LEND_WIFI_PHONE_MODE || \
	HEND_WIFI_PHONE_MODE || CAMl_LCDw_MODE || \
	CAMu_LCD_MODE || CAMu_wLCD_MODE || CAMl_LCD_MODE
	select GPIO1
	default n

#GPIO Combinations
config GPIO1
bool "GPIO1 - Disables UART MODEM, TIMER 1-2 and TIMER 3-4" depends on PHOTO_FRAME_MODE
default n

#peripherals available in all modes
config FIRDA

	bool "FIRDA"
	depends on !FSMC_4_CHIPS && !FSMC_2_CHIPS
	default y

config I2C

	bool "I2C"
	default y

config SSP
bool "SSP"
default y

config SSP_CHIP_SELECTS
bool "SSP CHIP SELECTS"
depends on !TL_TDM
default y

config GMAC

	bool "GMAC"
	depends on !TL_GPIO_1 && !TL_GPIO_2 && !TL_GPIO_3 && !TL_GPIO_4 && \
	!TL_GPIO_5 && !TL_CAMERA_1 && !TL_CAMERA_2 && !SDIO_8
	default y

config GPIO0_PIN_0_TO_5

	bool "GPIO0 Pin 0 TO 5"
	depends on !SDIO_1_4 && !SDIO_8
	default y

config UART
bool "UART"
depends on !FSMC_4_CHIPS
default y

config UART_MODEM

	bool "UART MODEM"
	depends on !TL_GPIO_5 && !TL_TDM && !TL_I2S && !BOOT_PINS && !GPIO1
	default y

config TIMER_1_2

	bool "TIMER 1-2"
	depends on !CLCD_1 && !TL_GPIO_2 && !TL_GPIO_4 && !TL_GPIO_5 && \
	!TL_SPI_I2C && !TL_CAMERA_2 && !TL_DAC && !BOOT_PINS && !GPIO1
	default y

config TIMER_3_4

	bool "TIMER 3-4"
	depends on !CLCD_1 && !CLCD_2 && !TL_GPIO_2 && !TL_GPIO_3 && \
	!TL_GPIO_5 && !TL_SPI_I2C && !BOOT_PINS && !GPIO1 && !TL_CAMERA_2
	default y

endmenu #SOC Configuration

endif #MACH_SPEAR300

file: arch/arm/mach-spear3xx/spear300.c

/* macros with configuration values for modes */
#define S300_NAND_MODE 1
#define S300_NOR_MODE 2
#define S300_PHOTO_FRAME_MODE 3
#define S300_LEND_IP_PHONE_MODE 4
#define S300_HEND_IP_PHONE_MODE 5
#define S300_LEND_WIFI_PHONE_MODE 6
#define S300_HEND_WIFI_PHONE_MODE 7
#define S300_ATA_PABX_wI2S_MODE 8
#define S300_ATA_PABX_I2S_MODE 9
#define S300_CAMl_LCDw_MODE 10
#define S300_CAMu_LCD_MODE 11
#define S300_CAMu_LCDw_MODE 12
#define S300_CAMl_LCD_MOD 13

/* macros with configuration values for peripherals */
#define S300_FIRDA ~0x00004000
#define S300_I2C ~0x00002000
#define S300_SSP_ENHANCED ~0x00001000
#define S300_SSP_BASIC ~0x00000800
#define S300_MII ~0x00000400
#define S300_LEG_GPIO ~0x000003f0
#define S300_UART_ENHANCED ~0x00000008
#define S300_UART_BASIC ~0x00000004
#define S300_TIMER_B ~0x00000002
#define S300_TIMER_A ~0x00000000

void spear300_configure(void)

{
	/* two variables to temporarily store values of two registers */
	volatile unsigned int *config_reg1;
	volatile unsigned int *config_reg2;

#ifndef CONFIG_FIRDA
	*config_reg1 &= FIRDA;
#endif
#ifndef CONFIG_I2C
	*config_reg1 &= I2C;
#endif
#ifndef CONFIG_SSP_CHIP_SELECTS
	*config_reg1 &= SSP_CHIP_SELECTS;
#endif
#ifndef CONFIG_SSP
	*config_reg1 &= SSP;
#endif
#ifndef CONFIG_GMAC
	*config_reg1 &= GMAC;
#endif
#ifndef CONFIG_GPIO0_PIN_0_TO_5
	*config_reg1 &= GPIO0_PIN_0_TO_5;
#endif
#ifndef CONFIG_UART_MODEM
	*config_reg1 &= UART_MODEM;
#endif
#ifndef CONFIG_UART
	*config_reg1 &= UART;
#endif
#ifndef CONFIG_TIMER_3_4
	*config_reg1 &= TIMER_3_4;
#endif
#ifndef CONFIG_TIMER_1_2
	*config_reg1 &= TIMER_1_2;

#endif

#ifdef CONFIG_NAND_MODE
	*config_reg2 = NAND_MODE;
#endif
#ifdef CONFIG_NOR_MODE
	*config_reg2 = NOR_MODE;
#endif
#ifdef CONFIG_PHOTO_FRAME_MODE
	*config_reg2 = PHOTO_FRAME_MODE;
#endif
#ifdef CONFIG_LEND_IP_PHONE_MODE
	*config_reg2 = LEND_IP_PHONE_MODE;
#endif
#ifdef CONFIG_HEND_IP_PHONE_MODE
	*config_reg2 = HEND_IP_PHONE_MODE;
#endif
#ifdef CONFIG_LEND_WIFI_PHONE_MODE
	*config_reg2 = LEND_WIFI_PHONE_MODE;
#endif
#ifdef CONFIG_HEND_WIFI_PHONE_MODE
	*config_reg2 = HEND_WIFI_PHONE_MODE;
#endif
#ifdef CONFIG_ATA_PABX_wI2S_MODE
	*config_reg2 = ATA_PABX_wI2S_MODE;
#endif
#ifdef CONFIG_ATA_PABX_I2S_MODE
	*config_reg2 = ATA_PABX_I2S_MODE;
#endif
#ifdef CONFIG_CAMl_LCDw_MODE
	*config_reg2 = CAMl_LCDw_MODE;
#endif
#ifdef CONFIG_CAMu_LCD_MODE
	*config_reg2 = CAMu_LCD_MODE;
#endif
#ifdef CONFIG_CAMu_wLCD_MODE
	*config_reg2 = CAMu_LCDw_MODE;
#endif
#ifdef CONFIG_CAMl_LCD_MODE
	*config_reg2 = CAMl_LCD_MODE;

#endif

	/* At the end we can write these values to actual registers */
}

regards,
viresh kumar.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 3 lines

Quoted 3 lines

I have provided this selection from "make menuconfig", based on selection I configure hardware at initialization time. Basically these selections will decide which device is present in the system when it boots.

This is really bad idea, what happens if you have a selection of boards with mutually-exclusive peripheral sets? Making these sorts of decisions at compile time is always a bad idea, it leaves people making distributitions a lot of extra work.

My first idea would be to add a function which is given a bitmap or list of devices to register, and this function sorts out what hardware bits to set as needed and then register if the selection is possible.

Now, For this we need some interface or channel through which we provide this information to kernel. This is what precisely i have done. The channel i provided is through Kconfig and the function "s300_configure", accepts this bitmap and configures hardware.

Quoted 6 lines

Now, For this we need some interface or channel through which we provide this information to kernel. This is what precisely i have done. The channel i
provided is through Kconfig and the function "s300_configure", accepts this bitmap and configures hardware.

I'm not getting this point.

If you do it thru Kconfig still it would be fixed a compilation time. Do you agree or am I missing something?

So, probably the correct way is passing peripheral selection information thru
bootargs.
What do you think?

yes, and if you see, should any one require it dynamically? Each user would have his own board with static devices. This configuration (of selecting multiplexed devices) depends on his board configuration, which is the responsibility of the board configuration file.

Quoted 4 lines · Shiraz HASHIM

Quoted 4 lines

yes, and if you see, should any one require it dynamically? Each user would have his own board with static devices. This configuration (of selecting multiplexed devices) depends on his board configuration, which is the responsibility of the board configuration file.

sorry for barging in but ...

usually device makers(that release product versions with same SoC but different devices)
want a single kernel image that detects the machine type and accordingly populate the
device support. Managing separate images for similar devices is considered inefficient.

Quoted 6 lines

usually device makers(that release product versions with same SoC but different devices)
want a single kernel image that detects the machine type and accordingly populate the
device support. Managing separate images for similar devices is considered inefficient.

Actually you have pointed to right thing and this is really important. Some architectures (I think ppc) have device tree option to pass the hardware configuration to the kernel from bootloader.
I dont know such option exists for arm. Lets hear others' opinions.

Quoted 7 lines · Shiraz HASHIM

Quoted 6 lines

usually device makers(that release product versions with same SoC but different devices)
want a single kernel image that detects the machine type and accordingly populate the
device support. Managing separate images for similar devices is considered inefficient.

Quoted 4 lines

Actually you have pointed to right thing and this is really important. Some architectures (I think ppc) have device tree option to pass the hardware configuration to the kernel from bootloader.
I dont know such option exists for arm. Lets hear others' opinions.

I don't think you can't do without device-trees.

Actually you have pointed to right thing and this is really important. Some architectures (I think ppc) have device tree option to pass the hardware configuration to the kernel from bootloader.
I dont know such option exists for arm. Lets hear others' opinions.

Quoted 3 lines

If you do it thru Kconfig still it would be fixed a compilation time. Do you agree or am I missing something?

yes, and if you see, should any one require it dynamically? Each user would have his own board with static devices. This configuration (of selecting multiplexed devices) depends on his board configuration, which is the responsibility of the board configuration file.

Quoted 5 lines

So, probably the correct way is passing peripheral selection information thru
bootargs.
What do you think?

This is very specific to how an SoC provides multiplexing options and will vary greatly. Which option of bootargs are you talking about?

Armando,

Quoted 9 lines · Armando VISCONTI

Quoted 7 lines

Now, For this we need some interface or channel through which we provide this information to kernel. This is what precisely i have done. The channel i
provided is through Kconfig and the function "s300_configure", accepts this bitmap and configures hardware.

I'm not getting this point.

yes, Actually this is what we are saying. Seemingly the best option is to do it during compilation time, except if we have some standard way at booting.

Quoted 3 lines

If you do it thru Kconfig still it would be fixed a compilation time. Do you agree or am I missing something?

yes, and if you see, should any one require it dynamically? Each user would have his own board with static devices. This configuration (of selecting multiplexed devices) depends on his board configuration, which is the responsibility of the board configuration file.

Quoted 5 lines

So, probably the correct way is passing peripheral selection information thru
bootargs.
What do you think?

This is very specific to how an SoC provides multiplexing options and will vary greatly. Which option of bootargs are you talking about?

regards
Shiraz

Quoted 10 lines

Quoted 5 lines

So, probably the correct way is passing peripheral selection information thru
bootargs.
What do you think?

This is very specific to how an SoC provides multiplexing options and will
vary greatly. Which option of bootargs are you talking about?

Of course not a standard bootargs option.
I was more talking about a new specific option that is passed thru bootargs and directed to a specific SPEAr function that can apply the proper cfg and register setting, like someone (Ben?) was suggesting.

In this option you should pass a bitmap or something like that.

Let me know your opinion on it.

Quoted 3 lines

Quoted 3 lines

I have provided this selection from "make menuconfig", based on selection I configure hardware at initialization time. Basically these selections will decide which device is present in the system when it boots.

This is really bad idea, what happens if you have a selection of boards with mutually-exclusive peripheral sets?

Making these sorts of
decisions at compile time is always a bad idea, it leaves people making distributitions a lot of extra work.

Ben,

Quoted 5 lines · Ben Dooks

Quoted 3 lines

Quoted 3 lines

I have provided this selection from "make menuconfig", based on selection I configure hardware at initialization time. Basically these selections will decide which device is present in the system when it boots.

This is really bad idea, what happens if you have a selection of boards with mutually-exclusive peripheral sets?

In this case, we can have different defconfig files for different boards.

Quoted 4 lines

Making these sorts of
decisions at compile time is always a bad idea, it leaves people making distributitions a lot of extra work.

I agree with this point but what is the other way for this.

Doing this at runtime will have following issue:

User have inserted a module and by mistake or lack of knowledge,
he disabled already working IP(due to multiplexing). Now with Kconfig concept this is taken care of at the beginning only. User can't select peripherals which can't be enabled simultaneously.

Quoted 10 lines · Viresh KUMAR

Ben,

Quoted 5 lines · Ben Dooks

Quoted 3 lines

Quoted 3 lines

I have provided this selection from "make menuconfig", based on selection I configure hardware at initialization time. Basically these selections will decide which device is present in the system when it boots.

This is really bad idea, what happens if you have a selection of boards with mutually-exclusive peripheral sets?

In this case, we can have different defconfig files for different boards.

That is not acceptable, it makes life difficult for things like the autobuilder (more configurations to process), for people trying to package software distributions (each kernel requires a package, a set of modules, requiring time to build and space to store).

The configuration is known to the board initialisation code in the kernel, and thus it should be requesting a set of features from the core SoC implementation saying what it wants. This can then ensure that the configuration is mutually exclusive, ensure any resources such as GPIO are correctly configured, etc.

Note, currently the s3c2410_defconfig builds 123Mbyte of modules. Think about having m-machines' worth of those littering your development system.

Quoted 5 lines

Quoted 4 lines

Making these sorts of
decisions at compile time is always a bad idea, it leaves people making distributitions a lot of extra work.

Quoted 8 lines

I agree with this point but what is the other way for this.

Doing this at runtime will have following issue:

User have inserted a module and by mistake or lack of knowledge,
he disabled already working IP(due to multiplexing). Now with Kconfig concept this is taken care of at the beginning only. User can't select peripherals which can't be enabled simultaneously.

Generally, all devices are registered at initialisation time. If there is the chance of dynamically loading drivers afterwards, either you'll have to do one of the following:

1) Change the driver to call the SoC code in the probe() code to ensure that it can get the required SoC resources

2) Ensure the board has reseved the SoC resources for the device at start time

Note, also unless you have very specific modules, your Kconfig approach will break down if you forget to update the root-fs when changing the kernel, otherwise modules you can't load will be left around.

Generally, runtime controls are much better than build time.

In our SOC's (SPEArxxx), we have many peripheral sharing PL_GPIO pins and so only few peripherals can be selected in a configuration. This is configurable using a set of registers. Now the problem is to make following work:

1. How to do this selection in kernel in a simple way?
2. Based on this selection hardware registers needs to be configured.

Please contemplate arch/arm/mach-u300/padmux.[c|h] if you have time. We have there a runtime padmuxing API similar to what is used for regulators and clocks. E.g in arch/arm/mach-u300/mmc.c:

/*
* Setup padmuxing for MMC. Since this must always be
* compiled into the kernel, pmx is never released. */
pmx = pmx_get(mmcsd_device, U300_APP_PMX_MMC_SETTING);

if (IS_ERR(pmx))

      pr_warning("Could not get padmux handle\n");
else {
    ret = pmx_activate(mmcsd_device, pmx);
    if (IS_ERR_VALUE(ret))
         pr_warning("Could not activate padmuxing\n");
}

This API can be used to switch in/out padmux settings in runtime. I think these things will always be platform-specific because people will always have their favourite way of configuring GPIO pins etc. (Note: we're not *just* muxing GPIO with this framework, far from, as you see above also the entire MMC/SD block connections can be muxed in/out.)

We've actually seen usecases where you need to dynamically remux while drivers are running but these have been rare and on older chips I think.

I was trying to go through u300 code and it looks clean enough. I need your help in understanding it better. In your case you try to configure the pin mux and then, even if it fails the device (through amba_device_register) is registered. Now if the driver is enabled in the kernel (or it is insmod) then the driver in its "probe" would stuck somewhere.

Do we need to handle such scenarios. Am I missing something?

Further, if you can describe what is onmask field (of pmx) and what devices/options are multiplexed with (say) spi, it would help me better understand the code.

Quoted 2 lines

We've actually seen usecases where you need to dynamically remux while drivers are running but these have been rare and on older chips I think.

You mean to say dynamically remapping pins to achieve some function with the same driver? or taking out one driver and inserting another after changing mux config.

In any case one of the objective is to keep same linux image for different configurations/boards. Isn't it ?