efikamx: Configure the pins as GPIOs prior to using gpio_get_value.

Configure the pins as GPIOs prior to using gpio_get_value

Cc Marek Vasut <[email protected]>

Signed-off-by Fabio Estevam <[email protected]>

---
 board/efikamx/efikamx.c |   13 +++++++++----
 1 files changed, 9 insertions(+), 4 deletions(-)

board/efikamx/efikamx.c +6 -2

index 3d2cc1a..b911891 100644
@@ -308,10 +308,14 @@ struct fsl_esdhc_cfg esdhc_cfg[2] = {
 
 static inline uint32_t efika_mmc_cd(void)
 {
-	if (machine_is_efikamx())
+	if (machine_is_efikamx()) {
+		mxc_request_iomux(MX51_PIN_GPIO1_0, IOMUX_CONFIG_ALT1);
 		return MX51_PIN_GPIO1_0;
-	else
+
+	} else {
+		mxc_request_iomux(MX51_PIN_EIM_CS2, IOMUX_CONFIG_ALT1);
 		return MX51_PIN_EIM_CS2;
+	}
 }
 
 int board_mmc_getcd(u8 *absent, struct mmc *mmc)

@@ -321,9 +325,10 @@ int board_mmc_getcd(u8 *absent, struct mmc *mmc)
 

board/efikamx/efikamx.c int board_mmc_getcd(u8 *absent, struct mmc *mmc) · line 333

Quoted 9 lines

Configure the pins as GPIOs prior to using gpio_get_value

board/efikamx/efikamx.c +3 -1

+	else {
+		mxc_request_iomux(MX51_PIN_GPIO1_8, IOMUX_CONFIG_ALT0);
 		*absent = gpio_get_value(IOMUX_TO_GPIO(MX51_PIN_GPIO1_8));
-
+	}
 	return 0;
 }

NAK. There should be some common function for setting up iomux of those pins. You souldn't set it in repeatedly called functions.

Quoted 10 lines

Quoted 10 lines

Configure the pins as GPIOs prior to using gpio_get_value

(quoted diff) +3 -1

+	else {
+		mxc_request_iomux(MX51_PIN_GPIO1_8, IOMUX_CONFIG_ALT0);
 
 		*absent = gpio_get_value(IOMUX_TO_GPIO(MX51_PIN_GPIO1_8));
 
-
+	}

Quoted 6 lines

Quoted 3 lines

return 0;

}

NAK. There should be some common function for setting up iomux of those pins. You souldn't set it in repeatedly called functions.

that's what gpio_request() is for

-mike

Quoted 12 lines · On Monday 21 November 2011 09:20:49 Marek Vasut wrote:

Quoted 10 lines

board/efikamx/efikamx.c int board_mmc_getcd(u8 *absent, struct mmc *mmc) · line 331

Quoted 7 lines

Configure the pins as GPIOs prior to using gpio_get_value

board/efikamx/efikamx.c +3 -1

+	else {
+		mxc_request_iomux(MX51_PIN_GPIO1_8, IOMUX_CONFIG_ALT0);
 		*absent = gpio_get_value(IOMUX_TO_GPIO(MX51_PIN_GPIO1_8));
-
+	}

NAK. There should be some common function for setting up iomux of those pins. You souldn't set it in repeatedly called functions.

Quoted 1 line

that's what gpio_request() is for

I mean in efika.c ... there should be a common place for these iomux configurations being done. This is unrelated to gpio ...

Quoted 7 lines

Quoted 7 lines · On Monday 21 November 2011 09:20:49 Marek Vasut wrote:

Quoted 6 lines

board/efikamx/efikamx.c int board_mmc_getcd(u8 *absent, struct mmc *mmc)

Quoted 6 lines

Configure the pins as GPIOs prior to using gpio_get_value

board/efikamx/efikamx.c +2 -0

+	else {
+		mxc_request_iomux(MX51_PIN_GPIO1_8, IOMUX_CONFIG_ALT0);
 
 		*absent = 

Quoted 7 lines

Quoted 7 lines

Quoted 6 lines

board/efikamx/efikamx.c int board_mmc_getcd(u8 *absent, struct mmc *mmc) · line 331

Quoted 3 lines

board/efikamx/efikamx.c +1 -1

-
+	}

NAK. There should be some common function for setting up iomux of those pins. You souldn't set it in repeatedly called functions.

Quoted 4 lines

Quoted 1 line

that's what gpio_request() is for

I mean in efika.c ... there should be a common place for these iomux configurations being done. This is unrelated to gpio ...

not really ... imo, if someone does gpio_request(PIN), the gpio core should take care of putting it into GPIO mode. people shouldn't have to pinmux_request(PIN, GPIO_MODE) before doing gpio_request(PIN).

Quoted 18 lines · On Monday 21 November 2011 14:29:50 Marek Vasut wrote:

Quoted 16 lines

Quoted 12 lines · On Monday 21 November 2011 09:20:49 Marek Vasut wrote:

Quoted 10 lines

board/efikamx/efikamx.c int board_mmc_getcd(u8 *absent, struct mmc *mmc) · line 331

Quoted 7 lines

Configure the pins as GPIOs prior to using gpio_get_value

board/efikamx/efikamx.c +3 -1

+	else {
+		mxc_request_iomux(MX51_PIN_GPIO1_8, IOMUX_CONFIG_ALT0);
 		*absent = gpio_get_value(IOMUX_TO_GPIO(MX51_PIN_GPIO1_8));
-
+	}

NAK. There should be some common function for setting up iomux of those pins. You souldn't set it in repeatedly called functions.

Quoted 1 line

that's what gpio_request() is for

I mean in efika.c ... there should be a common place for these iomux configurations being done. This is unrelated to gpio ...

Quoted 3 lines

not really ... imo, if someone does gpio_request(PIN), the gpio core should take care of putting it into GPIO mode. people shouldn't have to pinmux_request(PIN, GPIO_MODE) before doing gpio_request(PIN).

Of course ... considering there's always one correct setting for the pin to be in GPIO mode, which I suspect might not be completely true today anymore.

Quoted 3 lines

Of course ... considering there's always one correct setting for the pin to be in GPIO mode, which I suspect might not be completely true today anymore.

i find it hard to envision a pinmux system where individual pins would have different pinmux configurations to get it into GPIO mode. probably be saner to have gpio_request() do the right thing and wait for someone to come forward with the unusual setup -- worry about it then.

Quoted 9 lines · Mike Frysinger

Quoted 3 lines

Of course ... considering there's always one correct setting for the pin to be in GPIO mode, which I suspect might not be completely true today anymore.

i find it hard to envision a pinmux system where individual pins would have different pinmux configurations to get it into GPIO mode. probably be saner to have gpio_request() do the right thing and wait for someone to come forward with the unusual setup -- worry about it then.

In fact it would be nicer if gpio_request() takes care of the pinmux, in the way I can see on the davinci SOCs. However, on the IMXs a single GPIO can be connected (not at the same time, of course) to different PADs, depending on a general setup (GPR register) or if the daisy chain in the multiplexer is activated.

The second point I will arise is that, mainly due to the different internal layout but also for historical reasons, the setup and the provided function for the multiplexer is very different among the SOCs.

Only mx35 and mx5 expone the same interface (mxc_request_iomux), while mx31/mx25/mx27/mx28 have its own. Because we use and we want to use the GPIO framework, the gpio driver, common to all IMX SOCs, should be able to set up the multiplexer independently from the SOC type, that means we should have the same interface for the multiplexer, and we have not (yet ?).

Quoted 11 lines · On Tuesday 22 November 2011 03:15:47 Stefano Babic wrote:

Quoted 9 lines · Mike Frysinger

Quoted 3 lines

Of course ... considering there's always one correct setting for the pin to be in GPIO mode, which I suspect might not be completely true today anymore.

i find it hard to envision a pinmux system where individual pins would have different pinmux configurations to get it into GPIO mode. probably be saner to have gpio_request() do the right thing and wait for someone to come forward with the unusual setup -- worry about it then.

Quoted 5 lines

In fact it would be nicer if gpio_request() takes care of the pinmux, in the way I can see on the davinci SOCs. However, on the IMXs a single GPIO can be connected (not at the same time, of course) to different PADs, depending on a general setup (GPR register) or if the daisy chain in the multiplexer is activated.

if it's different physical pins, then perhaps it should be different GPIO numbers ?

Quoted 11 lines

The second point I will arise is that, mainly due to the different internal layout but also for historical reasons, the setup and the provided function for the multiplexer is very different among the SOCs.

Only mx35 and mx5 expone the same interface (mxc_request_iomux), while mx31/mx25/mx27/mx28 have its own. Because we use and we want to use the GPIO framework, the gpio driver, common to all IMX SOCs, should be able to set up the multiplexer independently from the SOC type, that means we should have the same interface for the multiplexer, and we have not (yet ?).

this is shaking out in Linux with the pinmux framework, so probably best to grit our teeth until that's done and then adopt what they implement.

Quoted 12 lines · Mike Frysinger

Quoted 11 lines · On Tuesday 22 November 2011 03:15:47 Stefano Babic wrote:

Quoted 9 lines · Mike Frysinger

Quoted 3 lines

Of course ... considering there's always one correct setting for the pin to be in GPIO mode, which I suspect might not be completely true today anymore.

i find it hard to envision a pinmux system where individual pins would have different pinmux configurations to get it into GPIO mode. probably be saner to have gpio_request() do the right thing and wait for someone to come forward with the unusual setup -- worry about it then.

Quoted 8 lines

Quoted 5 lines

In fact it would be nicer if gpio_request() takes care of the pinmux, in the way I can see on the davinci SOCs. However, on the IMXs a single GPIO can be connected (not at the same time, of course) to different PADs, depending on a general setup (GPR register) or if the daisy chain in the multiplexer is activated.

if it's different physical pins, then perhaps it should be different GPIO numbers ?

I think, currently, you are right, but if we look in some other AF (Alternate Functions) (not GPIO), same AF can be available on different physical pins. This means that in theory, same GPIO number can also be connected to different physical pins.
I think it should be board controllable instead of gpiolib hard coded, or of course pinmux controlled (which is board controllable).

Quoted 11 lines

Quoted 10 lines

The second point I will arise is that, mainly due to the different internal layout but also for historical reasons, the setup and the provided function for the multiplexer is very different among the SOCs.

Only mx35 and mx5 expone the same interface (mxc_request_iomux), while mx31/mx25/mx27/mx28 have its own. Because we use and we want to use the GPIO framework, the gpio driver, common to all IMX SOCs, should be able to set up the multiplexer independently from the SOC type, that means we should have the same interface for the multiplexer, and we have not (yet ?).

Quoted 2 lines

this is shaking out in Linux with the pinmux framework, so probably best to grit our teeth until that's done and then adopt what they implement.

This is probably the best way and correct me if I'm wrong, this means stick with board control over the pinmux instead of gpiolib.

if it's different physical pins, then perhaps it should be different GPIO numbers ?

this is shaking out in Linux with the pinmux framework, so probably best to grit our teeth until that's done and then adopt what they implement.

Quoted 2 lines · Mike Frysinger

if it's different physical pins, then perhaps it should be different GPIO numbers ?

No, they are not. Depending on the "daisy chain" functionality and based on different alternate function, a single GPIO can be routed to different physical pins.