arm-soc randconfig fixes

at91x40 is different from all the other at91 machines, and it is impossible to build a kernel that works on both this SoC and any of the others, even though it is possible to build a noMMU kernel for any at91 machine.

By turning at91x40 into a separate top-level option, we explicitly forbid enabling invalid configurations that include mutually exclusive machines.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Andrew Victor <[email protected]>

Cc Nicolas Ferre <[email protected]>

Cc Jean-Christophe Plagniol-Villard <[email protected]>

---
 arch/arm/mach-at91/Kconfig        | 22 ++++++++++++++++++----
 arch/arm/mach-at91/Kconfig.non_dt |  8 +-------
 2 files changed, 19 insertions(+), 11 deletions(-)

arch/arm/mach-at91/Kconfig +0 -0

index ae6617e..7209c5b 100644

arch/arm/mach-at91/Kconfig +6 -3

 	help
-	  Select this if you are using one of Atmel's AT91SAM9, AT91RM9200
-	  or AT91X40 SoC.
+	  Select this if you are using one of Atmel's AT91SAM9 or
+	  AT91RM9200 SoC.
 
 config SOC_SAM_V7
 	bool "Cortex A5"

@@ -177,9 +188,12 @@ config SOC_AT91SAM9N12
 	  Select this if you are using Atmel's AT91SAM9N12 SoC.
 
 # ----------------------------------------------------------
+endif # SOC_SAM_V4_V5
+
 
+if SOC_SAM_V4_V5 || ARCH_AT91X40
 source arch/arm/mach-at91/Kconfig.non_dt
-endif # SOC_SAM_V4_V5
+endif
 
 comment "Generic Board Type"
 

arch/arm/mach-at91/Kconfig.non_dt +1 -7

index 1f73e9b..44ace32 100644
@@ -5,6 +5,7 @@ config HAVE_AT91_DATAFLASH_CARD
 
 choice
 	prompt "Atmel AT91 Processor Devices for non DT boards"
+	depends on !ARCH_AT91X40
 
 config ARCH_AT91_NONE
 	bool "None"

@@ -39,13 +40,6 @@ config ARCH_AT91SAM9G45
 	select SOC_AT91SAM9G45
 	select AT91_USE_OLD_CLK
 
-config ARCH_AT91X40
-	bool "AT91x40"
-	depends on !MMU
-	select ARCH_USES_GETTIMEOFFSET
-	select MULTI_IRQ_HANDLER
-	select SPARSE_IRQ
-
 endchoice
 
 config ARCH_AT91SAM9G20

On 19/03/2014 20:28, Arnd Bergmann :

Quoted 5 lines

at91x40 is different from all the other at91 machines, and it is impossible to build a kernel that works on both this SoC and any of the others, even though it is possible to build a noMMU kernel for any at91 machine.

Quoted 7 lines

By turning at91x40 into a separate top-level option, we explicitly forbid enabling invalid configurations that include mutually exclusive machines.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Andrew Victor <[email protected]>

Cc Nicolas Ferre <[email protected]>

I added below little modifications to the comments, now that the AT91X40 is another entry.

Otherwise:

Acked-by Nicolas Ferre <[email protected]>

at91x40 has no support for device tree, but Kconfig allows us to enable CONFIG_OF anyway, causing a link error in the at91 reset controller initialization.

The easiest fix is to adapt the existing #ifdef to omit the broken code on at91x40 where it is never called anyway.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Andrew Victor <[email protected]>

Cc Nicolas Ferre <[email protected]>

Cc Jean-Christophe Plagniol-Villard <[email protected]>

---
 arch/arm/mach-at91/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm/mach-at91/setup.c +1 -1

index f7ca97b..f7a07a5 100644
@@ -351,7 +351,7 @@ void __init at91_ioremap_matrix(u32 base_addr)
 		panic("Impossible to ioremap at91_matrix_base\n");
 }
 
-#if defined(CONFIG_OF)
+#if defined(CONFIG_OF) && !defined(CONFIG_ARCH_AT91X40)
 static struct of_device_id rstc_ids[] = {
 	{ .compatible = "atmel,at91sam9260-rstc", .data = at91sam9_alt_restart },
 	{ .compatible = "atmel,at91sam9g45-rstc", .data = at91sam9g45_restart },

The pata_at91 driver uses interfaces defined in the sam9_smc platform code. Since the pata driver can be a loadable module, we have to export those symbols in order to link cleanly.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Andrew Victor <[email protected]>

Cc Nicolas Ferre <[email protected]>

Cc Jean-Christophe Plagniol-Villard <[email protected]>

---
 arch/arm/mach-at91/sam9_smc.c | 3 +++
 1 file changed, 3 insertions(+)

arch/arm/mach-at91/sam9_smc.c +3 -0

index b26156b..826315a 100644
@@ -36,6 +36,7 @@ void sam9_smc_write_mode(int id, int cs,
 {
 	sam9_smc_cs_write_mode(AT91_SMC_CS(id, cs), config);
 }
+EXPORT_SYMBOL_GPL(sam9_smc_write_mode);
 
 static void sam9_smc_cs_configure(void __iomem *base,
 					struct sam9_smc_config *config)

@@ -69,6 +70,7 @@ void sam9_smc_configure(int id, int cs,
 {
 	sam9_smc_cs_configure(AT91_SMC_CS(id, cs), config);
 }
+EXPORT_SYMBOL_GPL(sam9_smc_configure);
 
 static void sam9_smc_cs_read_mode(void __iomem *base,
 					struct sam9_smc_config *config)

@@ -84,6 +86,7 @@ void sam9_smc_read_mode(int id, int cs,
 {
 	sam9_smc_cs_read_mode(AT91_SMC_CS(id, cs), config);
 }
+EXPORT_SYMBOL_GPL(sam9_smc_read_mode);
 
 static void sam9_smc_cs_read(void __iomem *base,
 					struct sam9_smc_config *config)

If CONFIG_PATA_AT91 is disabled, the code in at91_add_device_cf is turned into invalid C statements due to the lack of an expression before the 'else' clause.

This moves the first half of the condition inside of the #ifdef, which seems to be what the author intended.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Andrew Victor <[email protected]>

Cc Nicolas Ferre <[email protected]>

Cc Jean-Christophe Plagniol-Villard <[email protected]>

---
 arch/arm/mach-at91/at91sam9260_devices.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

arch/arm/mach-at91/at91sam9260_devices.c +2 -2

index 2ae7715..4222a7d 100644
@@ -1263,13 +1263,13 @@ void __init at91_add_device_cf(struct at91_cf_data *data)
 	at91_set_A_periph(AT91_PIN_PC10, 0);    /* CFRNW */
 	at91_set_A_periph(AT91_PIN_PC15, 1);    /* NWAIT */
 
-	if (data->flags & AT91_CF_TRUE_IDE)
 #if defined(CONFIG_PATA_AT91) || defined(CONFIG_PATA_AT91_MODULE)
+	if (data->flags & AT91_CF_TRUE_IDE)
 		pdev->name = "pata_at91";
+	else
 #else
 #warning "board requires AT91_CF_TRUE_IDE: enable pata_at91"
 #endif
-	else
 		pdev->name = "at91_cf";
 
 	platform_device_register(pdev);

If CONFIG_PATA_AT91 is disabled, the code in at91_add_device_cf is turned into invalid C statements due to the lack of an expression before the 'else' clause.

This moves the first half of the condition inside of the #ifdef, which seems to be what the author intended.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Andrew Victor <[email protected]>

Cc Nicolas Ferre <[email protected]>

Cc Jean-Christophe Plagniol-Villard <[email protected]>

---
arch/arm/mach-at91/at91sam9260_devices.c | 4 ++--

1 file changed, 2 insertions(+), 2 deletions(-)

arch/arm/mach-at91/at91sam9260_devices.c +0 -0

index 2ae7715..4222a7d 100644

arch/arm/mach-at91/at91sam9260_devices.c +0 -1

 #endif
-	else
 		pdev->name = "at91_cf";
 
 	platform_device_register(pdev);

Signature · 1 line

1.8.3.2

Review

Quoted 3 lines · Arnd Bergmann

(quoted diff) +0 -1

-	if (data->flags & AT91_CF_TRUE_IDE)

#if defined(CONFIG_PATA_AT91) || defined(CONFIG_PATA_AT91_MODULE)

(quoted diff) +1 -0

+	if (data->flags & AT91_CF_TRUE_IDE)

I prefer if (IS_ENABLED())

Quoted 4 lines

		pdev->name = "pata_at91";

(quoted diff) +1 -0

+	else

#else
#warning "board requires AT91_CF_TRUE_IDE: enable pata_at91?

but this means drop this warning

Quoted 1 line

#endif

From ce916f429091f98cc53ee9cf11e6e02b4dc3dc25 Mon Sep 17 00:00:00 2001

It makes no sense for sama5 support to be enabled if we don't also enable USE_OF. Making this automatic in Kconfig avoids a possible randconfig conflict between the old and new clock support code.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Andrew Victor <[email protected]>

Cc Nicolas Ferre <[email protected]>

Cc Jean-Christophe Plagniol-Villard <[email protected]>

---
 arch/arm/mach-at91/Kconfig | 1 +
 1 file changed, 1 insertion(+)

arch/arm/mach-at91/Kconfig +1 -0

index 7209c5b..5ec1da1 100644
@@ -57,6 +57,7 @@ config SOC_SAMA5
 	select GENERIC_CLOCKEVENTS
 	select MULTI_IRQ_HANDLER
 	select SPARSE_IRQ
+	select USE_OF
 
 menu "Atmel AT91 System-on-Chip"
 

It makes no sense for sama5 support to be enabled if we don't also enable USE_OF. Making this automatic in Kconfig avoids a possible randconfig conflict between the old and new clock support code.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Andrew Victor <[email protected]>

Cc Nicolas Ferre <[email protected]>

---
arch/arm/mach-at91/Kconfig | 1 +

1 file changed, 1 insertion(+)

arch/arm/mach-at91/Kconfig +1 -0

index 7209c5b..5ec1da1 100644
@@ -57,6 +57,7 @@ config SOC_SAMA5
 	select GENERIC_CLOCKEVENTS
 	select MULTI_IRQ_HANDLER
 	select SPARSE_IRQ
+	select USE_OF
 

menu "Atmel AT91 System-on-Chip"

Signature · 1 line

1.8.3.2

The ohci-da8xx driver uses the DA8XX_SYSCFG0_VIRT macro to access the CFGCHIP2 register for controlling its PHY.

The macro in turn relies on the da8xx_syscfg0_base global variable. Since the OHCI driver can be a loadable module, this requires the symbol to be exported from platform code.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Sekhar Nori <[email protected]>

Cc Kevin Hilman <[email protected]>

Cc davinci-linux-open-source at linux.davincidsp.com

---
  arch/arm/mach-davinci/devices-da8xx.c | 1 +
  1 file changed, 1 insertion(+)

arch/arm/mach-davinci/devices-da8xx.c +0 -0

index 0486cdf..4da868a 100644

Quoted 22 lines · Arnd Bergmann

The ohci-da8xx driver uses the DA8XX_SYSCFG0_VIRT macro to access the CFGCHIP2 register for controlling its PHY.

The macro in turn relies on the da8xx_syscfg0_base global variable. Since the OHCI driver can be a loadable module, this requires the symbol to be exported from platform code.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Sekhar Nori <[email protected]>

Cc Kevin Hilman <[email protected]>

Cc davinci-linux-open-source at linux.davincidsp.com

---
  arch/arm/mach-davinci/devices-da8xx.c | 1 +
  1 file changed, 1 insertion(+)

arch/arm/mach-davinci/devices-da8xx.c +0 -0

index 0486cdf..4da868a 100644
@@ -66,6 +66,7 @@
  #define DA850_DMA_MMCSD1_TX EDMA_CTLR_CHAN(1, 29)
 

arch/arm/mach-davinci/devices-da8xx.c line 69

Quoted 2 lines

arch/arm/mach-davinci/devices-da8xx.c +1 -0

  void __iomem *da8xx_syscfg0_base;
+EXPORT_SYMBOL_GPL(da8xx_syscfg0_base); /* used by OHCI_HCD */

I have submitted such patch years ago and it was turned down.

Quoted 22 lines

Quoted 22 lines

The ohci-da8xx driver uses the DA8XX_SYSCFG0_VIRT macro to access the CFGCHIP2 register for controlling its PHY.

The macro in turn relies on the da8xx_syscfg0_base global variable. Since the OHCI driver can be a loadable module, this requires the symbol to be exported from platform code.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Sekhar Nori <[email protected]>

Cc Kevin Hilman <[email protected]>

Cc davinci-linux-open-source at linux.davincidsp.com

---
   arch/arm/mach-davinci/devices-da8xx.c | 1 +
   1 file changed, 1 insertion(+)

arch/arm/mach-davinci/devices-da8xx.c +0 -0

index 0486cdf..4da868a 100644
@@ -66,6 +66,7 @@
   #define DA850_DMA_MMCSD1_TX EDMA_CTLR_CHAN(1, 29)
 

Quoted 4 lines

arch/arm/mach-davinci/devices-da8xx.c line 69

Quoted 2 lines

arch/arm/mach-davinci/devices-da8xx.c +1 -0

   void __iomem *da8xx_syscfg0_base;
+EXPORT_SYMBOL_GPL(da8xx_syscfg0_base); /* used by OHCI_HCD */

I have submitted such patch years ago and it was turned down.

The question is whether there is anyone who would do this properly.

Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2)

to control the clock, phy

and host/gadget mode switch.

In the modern world, we'd probably want to have a clock driver and

a phy driver for these,

based on a syscon driver.

In all honesty I don't see that happening on davinci.

A somewhat better approach would be to export a set of exported functions to access the one register from the platform, e.g.

u32 da8xx_cfgchip2_get(void);
void da8xx_cfgchip2_set(u32);

That interface would still be a bit ugly, but much better than what we have today, and easy to implement.

Arnd

Quoted 1 line · Arnd Bergmann

The question is whether there is anyone who would do this properly.

Nobody cares, it seems. As you can imagine, I stopped to care enough after
being switched to other projects.

Quoted 1 line

Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2)

The idea at the time was to just ioremap() this register but I was not
very eager.

There was no USB PHY driver subsystem yet.

Quoted 1 line

to control the clock, phy

Note that it only controls PHY clock (PLL) which could be covered by an
USB PHY driver.

Quoted 1 line

and host/gadget mode switch.

The main mode the USB 2.0 PHY should function now is OTG. The host/gadged
modes are forced overrides of the ID pin. Unfortunately, the board code has to force host mode when host-only driver config is selected (these MUSB's host/gadget only modes were removed at one point but got reintroduced again).

Quoted 1 line

In the modern world, we'd probably want to have a clock driver and

Not sure about the clock driver...

Quoted 1 line

a phy driver for these,

Yes, that's what the MUSB maintainer wants too. The issue is the driver
should somehow differ which USB controller it's bound too and do different things depending on that (at least that's how it looks now). I'm not sure it's possible, so probably should be rethought.

Quoted 1 line

based on a syscon driver.

I don't know what syscon is...

Quoted 1 line

In all honesty I don't see that happening on davinci.

I don't think people use USB 1.1 controllers these days, especially when
there is USB 2.0 in the same SoC. For MUSB, there were recent attempt to get the DA8xx driver out of the broken state but it was turned down as well, IIRC, since it didn't offer a PHY driver.

Quoted 5 lines · On Thursday 20 March 2014 01:36:13 Sergei Shtylyov wrote:

Quoted 1 line · Arnd Bergmann

The question is whether there is anyone who would do this properly.

Nobody cares, it seems. As you can imagine, I stopped to care enough after
being switched to other projects.

I only care about it because I have the intention to get all 'randconfig' kernels to build eventually. For stuff that is definitely 'legacy' and won't get cleaned up properly, I'm fine with a hack.

Quoted 4 lines

Quoted 1 line

Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2)

The idea at the time was to just ioremap() this register but I was not
very eager.

Yes, that would work, too. However, that would cause problems later if we ever try to make the davinci platform "multiplatform", unless we also pass the physical address in a platform resource and make this a larger

The syscon (system controller) framework helps share a set of registers across multiple drivers. If all accesses to the CFGCHIP2 register are in a single PHY driver, we wouldn't need it.

Quoted 16 lines · Arnd Bergmann

Quoted 5 lines · On Thursday 20 March 2014 01:36:13 Sergei Shtylyov wrote:

Quoted 1 line · Arnd Bergmann

The question is whether there is anyone who would do this properly.

Nobody cares, it seems. As you can imagine, I stopped to care enough after
being switched to other projects.

I only care about it because I have the intention to get all 'randconfig' kernels to build eventually. For stuff that is definitely 'legacy' and won't get cleaned up properly, I'm fine with a hack.

Quoted 4 lines

Quoted 1 line

Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2)

The idea at the time was to just ioremap() this register but I was not
very eager.

Quoted 3 lines

Yes, that would work, too. However, that would cause problems later if we ever try to make the davinci platform "multiplatform", unless we also pass the physical address in a platform resource and make this a larger

Some SATA driver work done by Bartlomiej Zolnierkiewicz needed driver access to syscfg registers too and I just asked him to pass the physical addresses using platform resource. I think thats the best bet we have in the absence of a modern interface.

Quoted 3 lines

The syscon (system controller) framework helps share a set of registers across multiple drivers. If all accesses to the CFGCHIP2 register are in a single PHY driver, we wouldn't need it.

CFGCHIP2 has controls both for USB 1.1 (OHCI) and USB 2.0 (MUSB). Not sure if there can be a single PHY driver for both.

Quoted 17 lines

Quoted 17 lines

Quoted 4 lines

Quoted 1 line

The question is whether there is anyone who would do this properly.

Nobody cares, it seems. As you can imagine, I stopped to care enough after
being switched to other projects.

I only care about it because I have the intention to get all 'randconfig' kernels to build eventually. For stuff that is definitely 'legacy' and won't get cleaned up properly, I'm fine with a hack.

Quoted 4 lines

Quoted 1 line

Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2)

The idea at the time was to just ioremap() this register but I was not
very eager.

Yes, that would work, too. However, that would cause problems later if we ever try to make the davinci platform "multiplatform", unless we also pass the physical address in a platform resource and make this a larger

Quoted 4 lines

Some SATA driver work done by Bartlomiej Zolnierkiewicz needed driver access to syscfg registers too and I just asked him to pass the physical addresses using platform resource. I think thats the best bet we have in the absence of a modern interface.

Ok.

Quoted 6 lines

Quoted 3 lines

The syscon (system controller) framework helps share a set of registers across multiple drivers. If all accesses to the CFGCHIP2 register are in a single PHY driver, we wouldn't need it.

CFGCHIP2 has controls both for USB 1.1 (OHCI) and USB 2.0 (MUSB). Not sure if there can be a single PHY driver for both.

The phy infrastructure explicitly supports multiple consumers for one phy, if I'm reading the code correctly.

Arnd

Yes, it does. The issue is that the PHY code is different in MUSB and OHCI
drivers. I don't think the PHY driver knows what device binds to it.

Quoted 2 lines

Yes, it does. The issue is that the PHY code is different in MUSB and OHCI
drivers. I don't think the PHY driver knows what device binds to it.

At least in the DT case, it can get that information from DT, when you set #phy-cells=<1>. I don't know how it would be done for platform_data, but I assume one could find a way too.

Arnd

Quoted 4 lines

Quoted 1 line

Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2)

The idea at the time was to just ioremap() this register but I was not
very eager.

Yes, that would work, too. However, that would cause problems later if we ever try to make the davinci platform "multiplatform", unless we also pass the physical address in a platform resource and make this a larger driver.

I think we can reasonably have an exported set of functions declared in the platform data header file for these drivers, but passing the physical address through a header file

wouldn't be much of an improvement
over passing the virtual address.

Quoted 6 lines

There was no USB PHY driver subsystem yet.

Quoted 1 line

to control the clock, phy

Note that it only controls PHY clock (PLL) which could be covered by an
USB PHY driver.

Good point.

Quoted 1 line

Quoted 1 line

and host/gadget mode switch.

Quoted 4 lines

The main mode the USB 2.0 PHY should function now is OTG. The host/gadged
modes are forced overrides of the ID pin. Unfortunately, the board code has to force host mode when host-only driver config is selected (these MUSB's host/gadget only modes were removed at one point but got reintroduced again).

I think they are also required for 'randconfig' builds to some degree, because you can build a kernel without host mode for instance.

Quoted 3 lines

Quoted 1 line

In the modern world, we'd probably want to have a clock driver and

Not sure about the clock driver...

Quoted 6 lines

Quoted 1 line

a phy driver for these,

Yes, that's what the MUSB maintainer wants too. The issue is the driver
should somehow differ which USB controller it's bound too and do different things depending on that (at least that's how it looks now). I'm not sure it's possible, so probably should be rethought.

Yes, a phy driver seems the right approach if we can find someone to do it.

Ideally that should let us use generic versions of the ohci and musb drivers even, if that's the only davinci specific part of these drivers.

Quoted 3 lines

Quoted 1 line

based on a syscon driver.

I don't know what syscon is...

The syscon (system controller) framework helps share a set of registers across multiple drivers. If all accesses to the CFGCHIP2 register are in a single PHY driver, we wouldn't need it.

Quoted 6 lines

Quoted 1 line

In all honesty I don't see that happening on davinci.

I don't think people use USB 1.1 controllers these days, especially when
there is USB 2.0 in the same SoC. For MUSB, there were recent attempt to get the DA8xx driver out of the broken state but it was turned down as well, IIRC, since it didn't offer a PHY driver.

For USB 2.0 compliance you actually need to provide something to handle the low speed modes. A lot of people use a hub to do that nowadays rather than an OHCI or UHCI, but I don't know if that works with OTG.

Arnd

Quoted 3 lines

The syscon (system controller) framework helps share a set of registers across multiple drivers. If all accesses to the CFGCHIP2 register are in a single PHY driver, we wouldn't need it.

Where can I find it in the kernel tree?

Quoted 24 lines · On Wednesday 19 March 2014 23:53:18 Sergei Shtylyov wrote:

Quoted 22 lines · Arnd Bergmann

The ohci-da8xx driver uses the DA8XX_SYSCFG0_VIRT macro to access the CFGCHIP2 register for controlling its PHY.

The macro in turn relies on the da8xx_syscfg0_base global variable. Since the OHCI driver can be a loadable module, this requires the symbol to be exported from platform code.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Sekhar Nori <[email protected]>

Cc Kevin Hilman <[email protected]>

Cc davinci-linux-open-source at linux.davincidsp.com

---
  arch/arm/mach-davinci/devices-da8xx.c | 1 +
  1 file changed, 1 insertion(+)

arch/arm/mach-davinci/devices-da8xx.c +0 -0

index 0486cdf..4da868a 100644
@@ -66,6 +66,7 @@
  #define DA850_DMA_MMCSD1_TX EDMA_CTLR_CHAN(1, 29)
 

Quoted 5 lines

arch/arm/mach-davinci/devices-da8xx.c line 69

Quoted 2 lines

arch/arm/mach-davinci/devices-da8xx.c +1 -0

  void __iomem *da8xx_syscfg0_base;
+EXPORT_SYMBOL_GPL(da8xx_syscfg0_base); /* used by OHCI_HCD */

I have submitted such patch years ago and it was turned down.

The question is whether there is anyone who would do this properly.

Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2) to control the clock, phy and host/gadget mode switch.

In the modern world, we'd probably want to have a clock driver and a phy driver for these, based on a syscon driver.

In all honesty I don't see that happening on davinci.

A somewhat better approach would be to export a set of exported functions to access the one register from the platform, e.g.

u32 da8xx_cfgchip2_get(void);
void da8xx_cfgchip2_set(u32);

That interface would still be a bit ugly, but much better than what we have today, and easy to implement.

There is another thing we can do albeit in the driver (see patch). Not sure how the USB maintainer will feel about it but I think this has the advantage of not creating any hacky interfaces. And it leaves me with the hope that someone will find the time to convert to phy driver based on syscon at some point.

drivers/usb/host/ohci-hcd.c +0 -0

index 3586460..c807d3f 100644

Quoted 5 lines · Sekhar Nori

drivers/usb/host/ohci-hcd.c +0 -0

index 3586460..c807d3f 100644

drivers/usb/host/ohci-hcd.c MODULE_LICENSE ("GPL"); · line 1185

Quoted 9 lines

drivers/usb/host/ohci-hcd.c +2 -1

@@ -1178,7 +1178,8 @@ MODULE_LICENSE ("GPL");
 #define SA1111_DRIVER          ohci_hcd_sa1111_driver
 #endif
 
-#ifdef CONFIG_ARCH_DAVINCI_DA8XX
+/* DA8XX uses platform internal symbols. Cannot be built as module. */
+#if defined(CONFIG_ARCH_DAVINCI_DA8XX) && !defined(CONFIG_USB_OHCI_HCD_MODULE)
 #include "ohci-da8xx.c"
 #define DAVINCI_PLATFORM_DRIVER        ohci_hcd_da8xx_driver
 #endif

I wouldn't want to submit that patch to GregKH ;-)

How about doing the same thing in a somewhat less sneaky way?

Signed-off-by Arnd Bergmann <[email protected]>

We cannot call phy_register_fixup_for_uid() if CONFIG_PHYLIB is not built into the kernel, and we should not enforce that to be built into vmlinux either, because one might want to disable the entire network stack.

This change uses a compile-time condition on CONFIG_PHYLIB to remove the call in the cases where it cannot work.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Sekhar Nori <[email protected]>

Cc Kevin Hilman <[email protected]>

Cc davinci-linux-open-source at linux.davincidsp.com

The DAVINCI_DA850_EVM board uses an unusual method to enable the GPIO_PCA953X and KEYBOARD_GPIO_POLLED symbols, which leads to the dependencies on these symbols being ignored. As GPIO_PCA953X actually requires I2C, that can lead to build failures when I2C is disabled.

This patch removes the duplicate symbol definitions

and instead adds equivalent 'select' statements that are conditional on the underlying dependencies.

A different question whether we actually want to automatically enable them at all or rather put them into defconfig, but that should be a separate patch.

Quoted 7 lines · Arnd Bergmann

The DAVINCI_DA850_EVM board uses an unusual method to enable the GPIO_PCA953X and KEYBOARD_GPIO_POLLED symbols, which leads to the dependencies on these symbols being ignored. As GPIO_PCA953X actually requires I2C, that can lead to build failures when I2C is disabled.

This patch removes the duplicate symbol definitions

I am okay with this..

Quoted 2 lines

and instead adds equivalent 'select' statements that are conditional on the underlying dependencies.

.. but not sure this is needed. The PCA953X was defaulted to y mainly because the IO expander was used to detect presence of daughter cards. Even then, I don't think there is any need to force its selection.

Quoted 1 line

Quoted 3 lines

A different question whether we actually want to automatically enable them at all or rather put them into defconfig, but that should be a separate patch.

It can be enabled through defconfig as you said. I agree that can be a separate patch. For now, just dropping the replicated Kconfig symbols should be okay.

From 5eaf7fdfe7c831d3aa24428a6e8d4509ac160db6 Mon Sep 17 00:00:00 2001

From 5eaf7fdfe7c831d3aa24428a6e8d4509ac160db6 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <[email protected]>
Date: Tue, 18 Feb 2014 12:23:19 +0100
Subject: [PATCH] ARM: davinci: use explicit 'select' for DA850_EVM

The DAVINCI_DA850_EVM board uses an unusual method to enable the GPIO_PCA953X and KEYBOARD_GPIO_POLLED symbols, which leads to the dependencies on these symbols being ignored. As GPIO_PCA953X actually requires I2C, that can lead to build failures when I2C is disabled.

This patch removes the duplicate symbol definitions and instead enables them from the davinci_all_defconfig file.

A different question whether we actually want to automatically enable them at all or rather put them into defconfig, but that should be a separate patch.

Signed-off-by Arnd Bergmann <[email protected]>

Acked-by Sekhar Nori <[email protected]>

Cc Kevin Hilman <[email protected]>

Cc davinci-linux-open-source at linux.davincidsp.com

efm32 has no mach/uncompress.h, but we can trivially use the fallback to the ll_debug code by just allowing this option in Kconfig.

Found during randconfig testing.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Uwe Kleine-K?nig <[email protected]>

The efm32 platform does not provide a zreladdr-y line its Makefile.boot, so we always have to use CONFIG_AUTO_ZRELADDR in order to successfully build and link a zImage.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Uwe Kleine-K?nig <[email protected]>

---
 arch/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

arch/arm/Kconfig +1 -0

index 62ede9b..5776c12 100644
@@ -422,6 +422,7 @@ config ARCH_EFM32
 	bool "Energy Micro efm32"
 	depends on !MMU
 	select ARCH_REQUIRE_GPIOLIB
+	select AUTO_ZRELADDR
 	select ARM_NVIC
 	select CLKSRC_OF
 	select COMMON_CLK

Signature · 1 line

1.8.3.2

Quoted 3 lines · Arnd Bergmann

The efm32 platform does not provide a zreladdr-y line its Makefile.boot, so we always have to use CONFIG_AUTO_ZRELADDR in order to successfully build and link a zImage.

I wonder why you need to AUTO_ZRELADDR (which is there to guess zreladdr) while efm32 doesn't have an MMU and so there is nothing to guess. So I think this patch fixes a build problem, but it's not a good change.

Quoted 9 lines · On Thursday 20 March 2014 21:48:47 Uwe Kleine-K?nig wrote:

Quoted 3 lines · Arnd Bergmann

The efm32 platform does not provide a zreladdr-y line its Makefile.boot, so we always have to use CONFIG_AUTO_ZRELADDR in order to successfully build and link a zImage.

I wonder why you need to AUTO_ZRELADDR (which is there to guess zreladdr) while efm32 doesn't have an MMU and so there is nothing to guess. So I think this patch fixes a build problem, but it's not a good change.

It is required in order to build a compressed zImage file. You mentioned before that your system does not have enough RAM to support this, but the compile-time option exists, and there is no dependency on MMU support for it, nor should there be.

Quoted 11 lines · Arnd Bergmann

Quoted 9 lines · On Thursday 20 March 2014 21:48:47 Uwe Kleine-K?nig wrote:

Quoted 3 lines · Arnd Bergmann

The efm32 platform does not provide a zreladdr-y line its Makefile.boot, so we always have to use CONFIG_AUTO_ZRELADDR in order to successfully build and link a zImage.

I wonder why you need to AUTO_ZRELADDR (which is there to guess zreladdr) while efm32 doesn't have an MMU and so there is nothing to guess. So I think this patch fixes a build problem, but it's not a good change.

Quoted 4 lines

It is required in order to build a compressed zImage file. You mentioned before that your system does not have enough RAM to support this, but the compile-time option exists, and there is no dependency on MMU support for it, nor should there be.

My objection isn't about having only little RAM. AUTO_ZRELADDR is about guessing the physical address corresponding to PAGE_OFFSET. But without an MMU there is nothing to guess. So I wonder if the better change would be to do:

        #ifdef CONFIG_MMU
        #ifdef CONFIG_AUTO_ZRELADDR
                ... guess zreladdress based on instruction pointer
        #else
                ... use zreladdr from Makefile.boot
        #endif
        #else
                ... use zreladdr = PAGE_OFFSET
        #endif

Quoted 21 lines · On Friday 21 March 2014 15:32:24 Uwe Kleine-K?nig wrote:

Quoted 11 lines · Arnd Bergmann

Quoted 9 lines · On Thursday 20 March 2014 21:48:47 Uwe Kleine-K?nig wrote:

Quoted 3 lines · Arnd Bergmann

The efm32 platform does not provide a zreladdr-y line its Makefile.boot, so we always have to use CONFIG_AUTO_ZRELADDR in order to successfully build and link a zImage.

I wonder why you need to AUTO_ZRELADDR (which is there to guess zreladdr) while efm32 doesn't have an MMU and so there is nothing to guess. So I think this patch fixes a build problem, but it's not a good change.

Quoted 4 lines

It is required in order to build a compressed zImage file. You mentioned before that your system does not have enough RAM to support this, but the compile-time option exists, and there is no dependency on MMU support for it, nor should there be.

My objection isn't about having only little RAM. AUTO_ZRELADDR is about guessing the physical address corresponding to PAGE_OFFSET. But without an MMU there is nothing to guess. So I wonder if the better change would be to do:

Quoted 10 lines

        #ifdef CONFIG_MMU
        #ifdef CONFIG_AUTO_ZRELADDR
                ... guess zreladdress based on instruction pointer
        #else
                ... use zreladdr from Makefile.boot
        #endif
        #else
                ... use zreladdr = PAGE_OFFSET
        #endif

I don't see a reason to change the existing logic, it works for both MMU and NOMMU kernels, and you are talking about *three* instructions here.

Hello Arnd,

Quoted 33 lines · Arnd Bergmann

Quoted 21 lines · On Friday 21 March 2014 15:32:24 Uwe Kleine-K?nig wrote:

Quoted 11 lines · Arnd Bergmann

Quoted 9 lines · On Thursday 20 March 2014 21:48:47 Uwe Kleine-K?nig wrote:

Quoted 3 lines · Arnd Bergmann

The efm32 platform does not provide a zreladdr-y line its Makefile.boot, so we always have to use CONFIG_AUTO_ZRELADDR in order to successfully build and link a zImage.

I wonder why you need to AUTO_ZRELADDR (which is there to guess zreladdr) while efm32 doesn't have an MMU and so there is nothing to guess. So I think this patch fixes a build problem, but it's not a good change.

Quoted 4 lines

It is required in order to build a compressed zImage file. You mentioned before that your system does not have enough RAM to support this, but the compile-time option exists, and there is no dependency on MMU support for it, nor should there be.

My objection isn't about having only little RAM. AUTO_ZRELADDR is about guessing the physical address corresponding to PAGE_OFFSET. But without an MMU there is nothing to guess. So I wonder if the better change would be to do:

Quoted 10 lines

        #ifdef CONFIG_MMU
        #ifdef CONFIG_AUTO_ZRELADDR
                ... guess zreladdress based on instruction pointer
        #else
                ... use zreladdr from Makefile.boot
        #endif
        #else
                ... use zreladdr = PAGE_OFFSET
        #endif

Quoted 3 lines

I don't see a reason to change the existing logic, it works for both MMU and NOMMU kernels, and you are talking about *three* instructions here.

it doesn't matter how many instructions are involved. The relevant difference is that with my approach you fix the problem for all no-MMU platforms, with yours you only fix efm32. (OK, I think there are not too many no-MMU platforms, but still.) An even easier implementation would be to add something like:

ifeq($(zreladdr-y)$(CONFIG_MMU),) zreladdr-y := CONFIG_PAGE_OFFSET + CONFIG_TEXT_OFFSET endif

to arch/arm/boot/Makefile.

But I don't care much, if you still want to make EFM32 select AUTO_ZRELADDR go ahead.

Quoted 10 lines · Uwe Kleine-K?nig

Quoted 3 lines · Arnd Bergmann

I don't see a reason to change the existing logic, it works for both MMU and NOMMU kernels, and you are talking about three instructions here.

it doesn't matter how many instructions are involved. The relevant difference is that with my approach you fix the problem for all no-MMU platforms, with yours you only fix efm32. (OK, I think there are not too many no-MMU platforms, but still.) An even easier implementation would be to add something like:

Quoted 5 lines

ifeq($(zreladdr-y)$(CONFIG_MMU),) zreladdr-y := CONFIG_PAGE_OFFSET + CONFIG_TEXT_OFFSET endif

to arch/arm/boot/Makefile.

Quoted 2 lines

But I don't care much, if you still want to make EFM32 select AUTO_ZRELADDR go ahead.

How about a kconfig fix:

bool "Auto calculation of the decompressed kernel image address" if MMU default y if !MMU

Quoted 15 lines · Rob Herring

Quoted 14 lines · Uwe Kleine-K?nig

Quoted 3 lines · Arnd Bergmann

I don't see a reason to change the existing logic, it works for both MMU and NOMMU kernels, and you are talking about three instructions here.

it doesn't matter how many instructions are involved. The relevant difference is that with my approach you fix the problem for all no-MMU platforms, with yours you only fix efm32. (OK, I think there are not too many no-MMU platforms, but still.) An even easier implementation would be to add something like:

ifeq($(zreladdr-y)$(CONFIG_MMU),) zreladdr-y := CONFIG_PAGE_OFFSET + CONFIG_TEXT_OFFSET endif

Quoted 1 line

Quoted 1 line

to arch/arm/boot/Makefile.

This makes sense, we can add it as soon as we have a use for it. At the moment, the only problem we have is a randconfig build error, and the obvious change I proposed should work just fine.

ep93xx_chip_revision is used by the pata_ep93xx driver, which can be a loadable module. Exporting the symbol avoids a link error in this case.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Hartley Sweeten <[email protected]>

Cc Ryan Mallon <[email protected]>

---
 arch/arm/mach-ep93xx/core.c | 1 +
 1 file changed, 1 insertion(+)

arch/arm/mach-ep93xx/core.c +0 -0

index 6c70547..0e571f1 100644

The hisi SMP code always uses the hi3xxx_set_cpu() function defined in the hotplug.c file, so we cannot build without this when CONFIG_SMP is enabled. This patch slightly restructures the code so we always build the parts of hotplug.c that we need but just leave out the CPU disable logic if CONFIG_HOTPLUG_CPU is turned off.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Haojian Zhuang <[email protected]>

---
 arch/arm/mach-hisi/Makefile  | 3 +--
 arch/arm/mach-hisi/hotplug.c | 2 ++
 2 files changed, 3 insertions(+), 2 deletions(-)

arch/arm/mach-hisi/Makefile +1 -2

index 6870058..2ae1b59 100644
@@ -3,5 +3,4 @@
 #
 
 obj-y  += hisilicon.o
-obj-$(CONFIG_SMP)              += platsmp.o
-obj-$(CONFIG_HOTPLUG_CPU)      += hotplug.o
+obj-$(CONFIG_SMP)              += platsmp.o hotplug.o

arch/arm/mach-hisi/hotplug.c +2 -1

index b909854..abd441b 100644
@@ -178,6 +178,7 @@ static inline void cpu_enter_lowpower(void)
          : "cc");
 }
 
+#ifdef CONFIG_HOTPLUG_CPU
 void hi3xxx_cpu_die(unsigned int cpu)
 {
        cpu_enter_lowpower();

@@ -198,3 +199,4 @@ int hi3xxx_cpu_kill(unsigned int cpu)
        hi3xxx_set_cpu(cpu, false);
        return 1;
 }
+#endif
--

1.8.3.2

The SCU code does not build unless we are compiling an SMP kernel. This does the same as every other platform with an SCU.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Haojian Zhuang <[email protected]>

---
 arch/arm/mach-hisi/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/arm/mach-hisi/Kconfig +1 -2

index 9d0a87b..feee4db 100644
@@ -4,7 +4,7 @@ config ARCH_HI3xxx
        select ARM_GIC
        select ARM_TIMER_SP804
        select CACHE_L2X0
-       select HAVE_ARM_SCU
+       select HAVE_ARM_SCU if SMP
        select HAVE_ARM_TWD if SMP
        select PINCTRL
        select PINCTRL_SINGLE
--

1.8.3.2

This ensures that we only call imx6q_set_lpm if CONFIG_PM is enabled and we are building the pm-imx6q.c file.

Another fix that has been suggested for this is to always build this file conditionally build only the parts of it that are relevant only to CONFIG_PM.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Shawn Guo <[email protected]>

Cc Sascha Hauer <[email protected]>

---
 arch/arm/mach-imx/clk-imx6q.c      | 3 ++-
 arch/arm/mach-imx/clk-imx6sl.c     | 3 ++-
 arch/arm/mach-imx/cpuidle-imx6sl.c | 3 +++
 3 files changed, 7 insertions(+), 2 deletions(-)

arch/arm/mach-imx/clk-imx6q.c +2 -1

index b0e7f9d..133b23e 100644
@@ -478,7 +478,8 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
 		clk_set_parent(clk[lvds1_sel], clk[sata_ref]);
 
 	/* Set initial power mode */
-	imx6q_set_lpm(WAIT_CLOCKED);
+	if (IS_ENABLED(CONFIG_PM))
+		imx6q_set_lpm(WAIT_CLOCKED);
 
 	np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-gpt");
 	base = of_iomap(np, 0);

arch/arm/mach-imx/clk-imx6sl.c +2 -1

index f7073c0..a882bdf 100644
@@ -382,7 +382,8 @@ static void __init imx6sl_clocks_init(struct device_node *ccm_node)
 	clk_set_parent(clks[IMX6SL_CLK_SPDIF0_SEL], clks[IMX6SL_CLK_PLL3_PFD3]);
 
 	/* Set initial power mode */
-	imx6q_set_lpm(WAIT_CLOCKED);
+	if (IS_ENABLED(CONFIG_PM))
+		imx6q_set_lpm(WAIT_CLOCKED);
 
 	np = of_find_compatible_node(NULL, NULL, "fsl,imx6sl-gpt");
 	base = of_iomap(np, 0);

arch/arm/mach-imx/cpuidle-imx6sl.c +3 -0

index d4b6b81..c9a6aa8 100644
@@ -53,5 +53,8 @@ static struct cpuidle_driver imx6sl_cpuidle_driver = {
 
 int __init imx6sl_cpuidle_init(void)
 {
+	if (!IS_ENABLED(CONFIG_PM))
+		return -ENOSYS;
+
 	return cpuidle_register(&imx6sl_cpuidle_driver, NULL);
 }

Signature · 1 line

1.8.3.2

The omixp board code unconditionally defines a gpio-led device, but for some reason includes the header file for this only if CONFIG_LEDS_CLASS is enabled, causing a build error otherwise.

Removing the #ifdef fixes the build error with no downsides whatsoever.

When using CONFIG_IXP4XX_INDIRECT_PCI, we run into a recursive header file dependency between mach/io.h and asm/pci.h, resulting in a build failure:

+++ b/arch/arm/mach-ixp4xx/include/mach/io.h

Commit 098e30f6558f8 "ARM: ixp4xx: stop broadcasting the custom GPIO API" changed the internal gpio code of ixp4xx to be accessible only from common.c, but unfortunately that broke the Goramo MultiLink code, which uses this API.

This tries to restore the previous state without exposing the API globally again. A better solution might be needed.

The 'og' machine tries to always initialized the PCI code, but that may be disabled in Kconfig, leading to a build error.

This patch changes the code to use the same Kconfig symbol to decide about calling the ks8695_init_pci function at build time that we use to decide about building the ks8695 PCI support.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Greg Ungerer <[email protected]>

 arch/arm/mach-ks8695/board-og.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

arch/arm/mach-ks8695/board-og.c +2 -1

index 002bc61..f265816 100644
@@ -44,7 +44,8 @@ static void __init og_register_pci(void)
 	if (machine_is_im4004())
 		ks8695_gpio_interrupt(KS8695_GPIO_1, IRQ_TYPE_LEVEL_LOW);
 
-	ks8695_init_pci(&og_pci);
+	if (IS_ENABLED(CONFIG_PCI))
+		ks8695_init_pci(&og_pci);
 }
 
 /*

This symbol is used by the lpc_eth driver, which may be a loadable module.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Roland Stigge <[email protected]>

---
 arch/arm/mach-lpc32xx/common.c | 1 +
 1 file changed, 1 insertion(+)

arch/arm/mach-lpc32xx/common.c +0 -0

index d7aa54c..de03620 100644

After the restructuring of the module.h and init.h headers, we now need to include this explicitly here.

Signed-off-by Arnd Bergmann <[email protected]>

Cc David Brown <[email protected]>

Cc Daniel Walker <[email protected]>

Cc Bryan Huntsman <[email protected]>

---
arch/arm/mach-msm/dma.c | 1 +

1 file changed, 1 insertion(+)

arch/arm/mach-msm/dma.c +1 -0

index f8f6adf..ba62f02 100644
@@ -18,6 +18,7 @@
 #include <linux/io.h>
 #include <linux/interrupt.h>
 #include <linux/completion.h>
+#include <linux/module.h>
 #include <mach/dma.h>
 #include <mach/msm_iomap.h>
 

Signature · 1 line

1.8.3.2

MSM7X00A has an open-coded version of debug_ll_io_init so it can use MT_DEVICE_NONSHARED as required by the platform.

However, this fails to build on no-MMU kernels because the debug_ll_addr function is not available. Since the iotable_init function doesn't actually do anyting in this configuration, we can simply get away by enclosing the broken function call in an #ifdef, which seems to be the least ugly workaround.

Signed-off-by Arnd Bergmann <[email protected]>

Cc David Brown <[email protected]>

Cc Daniel Walker <[email protected]>

Cc Bryan Huntsman <[email protected]>

---
arch/arm/mach-msm/io.c | 2 ++

1 file changed, 2 insertions(+)

arch/arm/mach-msm/io.c +2 -0

index adc8971..34e0947 100644
@@ -78,8 +78,10 @@ void __init msm_map_common_io(void)
 	asm("mcr p15, 0, %0, c15, c2, 4" : : "r" (0));
 #if defined(CONFIG_DEBUG_MSM_UART1) || defined(CONFIG_DEBUG_MSM_UART2) || \
 		defined(CONFIG_DEBUG_MSM_UART3)
+#ifdef CONFIG_MMU
 	debug_ll_addr(&msm_io_desc[size - 1].pfn,
 		      &msm_io_desc[size - 1].virtual);
+#endif
 	msm_io_desc[size - 1].pfn = __phys_to_pfn(msm_io_desc[size - 1].pfn);
 #endif
 	iotable_init(msm_io_desc, size);

Signature · 1 line

1.8.3.2

The msm_sdcc MMC driver and the msm_serial_hs uart driver both use the pre-dmaengine interfaces provided by the MSM platform.

Since these drivers can be loadable modules, we should export the functions used in the drivers.

Signed-off-by Arnd Bergmann <[email protected]>

Cc David Brown <[email protected]>

Cc Daniel Walker <[email protected]>

Cc Bryan Huntsman <[email protected]>

---
arch/arm/mach-msm/dma.c | 2 ++

1 file changed, 2 insertions(+)

If we enable CONFIG_OMAP_MPU_TIMER and CONFIG_OMAP_DM_TIMER but not CONFIG_OMAP_32K_TIMER on OMAP1, we currently get this build error:

mach-omap1/pm.c: In function 'omap1_pm_idle':
mach-omap1/pm.c:123:9: error: 'enable_dyn_sleep' undeclared (first use in this function)

  while (enable_dyn_sleep) {
         ^

mach-omap1/pm.c:123:9: note: each undeclared identifier is reported only once for each function it appears in

This attempts to fix the #ifdef logic to deal with all combinations of timers.

Signed-off-by Arnd Bergmann <[email protected]>

Cc linux-omap at vger.kernel.org

Cc Tony Lindgren <[email protected]>

---
 arch/arm/mach-omap1/pm.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

arch/arm/mach-omap1/pm.c +4 -4

index 40a1ae3..7dff68e 100644
@@ -71,10 +71,10 @@ static unsigned int mpui7xx_sleep_save[MPUI7XX_SLEEP_SAVE_SIZE];
 static unsigned int mpui1510_sleep_save[MPUI1510_SLEEP_SAVE_SIZE];
 static unsigned int mpui1610_sleep_save[MPUI1610_SLEEP_SAVE_SIZE];
 
-#ifdef CONFIG_OMAP_32K_TIMER
-
 static unsigned short enable_dyn_sleep = 1;
 
+#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
+
 static ssize_t idle_show(struct kobject *kobj, struct kobj_attribute *attr,
 			 char *buf)
 {

@@ -643,7 +643,7 @@ static const struct platform_suspend_ops omap_pm_ops = {
 static int __init omap_pm_init(void)
 {
 
-#ifdef CONFIG_OMAP_32K_TIMER
+#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
 	int error;
 #endif
 

@@ -700,7 +700,7 @@ static int __init omap_pm_init(void)
 	omap_pm_init_debugfs();
 #endif
 
-#ifdef CONFIG_OMAP_32K_TIMER
+#if defined(CONFIG_OMAP_32K_TIMER) || defined(CONFIG_OMAP_MPU_TIMER)
 	error = sysfs_create_file(power_kobj, &sleep_while_idle_attr.attr);
 	if (error)
 		printk(KERN_ERR "sysfs_create_file failed: %d\n", error);

Signature · 6 lines

1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi,

Quoted 9 lines · Arnd Bergmann

If we enable CONFIG_OMAP_MPU_TIMER and CONFIG_OMAP_DM_TIMER but not CONFIG_OMAP_32K_TIMER on OMAP1, we currently get this build error:

mach-omap1/pm.c: In function 'omap1_pm_idle':
mach-omap1/pm.c:123:9: error: 'enable_dyn_sleep' undeclared (first use in this function)

  while (enable_dyn_sleep) {
         ^

mach-omap1/pm.c:123:9: note: each undeclared identifier is reported only once for each function it appears in

Quoted 6 lines

This attempts to fix the #ifdef logic to deal with all combinations of timers.

Signed-off-by Arnd Bergmann <[email protected]>

Cc linux-omap at vger.kernel.org

Cc Tony Lindgren <[email protected]>

I had sent a fix for months and months ago, what happened to it ?

Quoted 19 lines · Felipe Balbi

Hi,

Quoted 15 lines · Arnd Bergmann

If we enable CONFIG_OMAP_MPU_TIMER and CONFIG_OMAP_DM_TIMER but not CONFIG_OMAP_32K_TIMER on OMAP1, we currently get this build error:

mach-omap1/pm.c: In function 'omap1_pm_idle':
mach-omap1/pm.c:123:9: error: 'enable_dyn_sleep' undeclared (first use in this function)

  while (enable_dyn_sleep) {
         ^

mach-omap1/pm.c:123:9: note: each undeclared identifier is reported only once for each function it appears in

This attempts to fix the #ifdef logic to deal with all combinations of timers.

Signed-off-by Arnd Bergmann <[email protected]>

Cc linux-omap at vger.kernel.org

Cc Tony Lindgren <[email protected]>

Quoted 1 line

I had sent a fix for months and months ago, what happened to it ?

Here

http://marc.info/?l=linux-omap&m=138963632408031&w=2

Tony, did you forget to send a pull request ?

Quoted 8 lines · Felipe Balbi

Quoted 1 line · Felipe Balbi

I had sent a fix for months and months ago, what happened to it ?

Here

http://marc.info/?l=linux-omap&m=138963632408031&w=2

Tony, did you forget to send a pull request ?

Hmm yes weird, can't see it in my omap-for-v3.14/fixes branch.

I must have gotten interrupted while applying and then probably ran git reset --hard before committing.

Arnd, maybe pick up Felipe's earlier patch instead?

Acked-by Tony Lindgren <[email protected]>

From 64cdcf550319a37d1419aa6a87903e67b9d3d031 Mon Sep 17 00:00:00 2001

The OMAP H2, OSK and OSIRIS machines cannot build without I2C and TPS65010 both enabled unconditionally.

In each case, failing to enable CONFIG_I2C results in a build or link error, so most consistent solution is to ensure that it is impossible to disable those options.

It would be nice to leave CONFIG_I2C as user-selectable, but doing that properly would require more work.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Tony Lindgren <[email protected]>

Cc linux-omap at vger.kernel.org

---
 arch/arm/mach-omap1/Kconfig | 4 ++++
 1 file changed, 4 insertions(+)

arch/arm/mach-omap1/Kconfig +4 -0

index cdd05f2..23ab1d5 100644
@@ -44,6 +44,8 @@ config MACH_OMAP_INNOVATOR
 config MACH_OMAP_H2
 	bool "TI H2 Support"
 	depends on ARCH_OMAP1 && ARCH_OMAP16XX
+	select TPS65010
+	select I2C
     	help
 	  TI OMAP 1610/1611B H2 board support. Say Y here if you have such
 	  a board.

@@ -64,6 +66,8 @@ config MACH_HERALD
 config MACH_OMAP_OSK
 	bool "TI OSK Support"
 	depends on ARCH_OMAP1 && ARCH_OMAP16XX
+	select TPS65010
+	select I2C
     	help
 	  TI OMAP 5912 OSK (OMAP Starter Kit) board support. Say Y here
           if you have such a board.

Signature · 1 line

1.8.3.2

Quoted 7 lines · Arnd Bergmann

The OMAP H2, OSK and OSIRIS machines cannot build without I2C and TPS65010 both enabled unconditionally.

In each case, failing to enable CONFIG_I2C results in a build or link error, so most consistent solution is to ensure that it is impossible to disable those options.

Quoted 2 lines

It would be nice to leave CONFIG_I2C as user-selectable, but doing that properly would require more work.

We should not select drivers. How about let's just have the tps65010 stuff behind an ifdef CONFIG_TPS65010 for those boards?

Quoted 8 lines · On Wednesday 19 March 2014 13:46:19 Tony Lindgren wrote:

Quoted 7 lines · Arnd Bergmann

The OMAP H2, OSK and OSIRIS machines cannot build without I2C and TPS65010 both enabled unconditionally.

In each case, failing to enable CONFIG_I2C results in a build or link error, so most consistent solution is to ensure that it is impossible to disable those options.

Quoted 6 lines

Quoted 2 lines

It would be nice to leave CONFIG_I2C as user-selectable, but doing that properly would require more work.

We should not select drivers. How about let's just have the tps65010 stuff behind an ifdef CONFIG_TPS65010 for those boards?

Good idea. Like this?

arch/arm/mach-omap1/board-h2.c +3 -0

index fd90caf..65d2acb 100644
@@ -318,6 +318,9 @@ static void __init h2_init_smc91x(void)
 
 static int tps_setup(struct i2c_client *client, void *context)
 {
+	if (!IS_BUILTIN(CONFIG_TPS65010))
+		return -ENOSYS;
+	
 	tps65010_config_vregs1(TPS_LDO2_ENABLE | TPS_VLDO2_3_0V |
 				TPS_LDO1_ENABLE | TPS_VLDO1_3_0V);
 

arch/arm/mach-omap1/board-osk.c +3 -1

index d68909b..3a02621 100644
@@ -191,6 +191,9 @@ static struct platform_device osk5912_tps_leds = {
 
 static int osk_tps_setup(struct i2c_client *client, void *context)
 {
+	if (!IS_BUILTIN(CONFIG_TPS65010))
+		return -ENOSYS;
+
 	/* Set GPIO 1 HIGH to disable VBUS power supply;
 	 * OHCI driver powers it up/down as needed.
 	 */
 
--

To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

The definition for SIGBUS may not be visible without including linux/signal.h, as I found during randconfig testing.

Adding an explicit include is certainly the right thing to do.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Jason Cooper <[email protected]>

Cc Andrew Lunn <[email protected]>

Cc Gregory Clement <[email protected]>

Cc Sebastian Hesselbarth <[email protected]>

---
 arch/arm/mach-mvebu/board-v7.c | 1 +
 1 file changed, 1 insertion(+)

The definition for SIGBUS may not be visible without including linux/signal.h, as I found during randconfig testing.

Adding an explicit include is certainly the right thing to do.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Jason Cooper <[email protected]>

Cc Andrew Lunn <[email protected]>

Cc Gregory Clement <[email protected]>

Cc Sebastian Hesselbarth <[email protected]>

---
 arch/arm/mach-mvebu/board-v7.c | 1 +
 1 file changed, 1 insertion(+)

arch/arm/mach-mvebu/board-v7.c +1 -0

index 746134e..333fca8 100644
@@ -21,6 +21,7 @@
 #include <linux/clocksource.h>
 #include <linux/dma-mapping.h>
 #include <linux/mbus.h>
+#include <linux/signal.h>
 #include <linux/slab.h>
 #include <asm/hardware/cache-l2x0.h>
 #include <asm/mach/arch.h>

CONFIG_NEON is meant to be user-selectable. Turning it on unconditionally means we can't build a smaller kernel when we don't need it, and causes build errors if CONFIG_VFP is not also enabled.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Jason Cooper <[email protected]>

Cc Andrew Lunn <[email protected]>

Cc Gregory Clement <[email protected]>

Cc Sebastian Hesselbarth <[email protected]>

---
 arch/arm/mach-mvebu/Kconfig | 2 --
 1 file changed, 2 deletions(-)

Quoted 5 lines · Arnd Bergmann

CONFIG_NEON is meant to be user-selectable. Turning it on unconditionally means we can't build a smaller kernel when we don't need it, and causes build errors if CONFIG_VFP is not also enabled.

Quoted 8 lines

Signed-off-by Arnd Bergmann <[email protected]>

Cc Jason Cooper <[email protected]>

Cc Andrew Lunn <[email protected]>

Cc Gregory Clement <[email protected]>

Cc Sebastian Hesselbarth <[email protected]>

---
 arch/arm/mach-mvebu/Kconfig | 2 --
 1 file changed, 2 deletions(-)

Acked-by Jason Cooper <[email protected]>

Gregory, Thomas, Ezequiel,

Care to spin a patch adding NEON to mvebu_v7_defconfig? (If you want it)

thx,

Jason.

Quoted 15 lines · Jason Cooper

Quoted 13 lines · Arnd Bergmann

CONFIG_NEON is meant to be user-selectable. Turning it on unconditionally means we can't build a smaller kernel when we don't need it, and causes build errors if CONFIG_VFP is not also enabled.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Jason Cooper <[email protected]>

Cc Andrew Lunn <[email protected]>

Cc Gregory Clement <[email protected]>

Cc Sebastian Hesselbarth <[email protected]>

---
 arch/arm/mach-mvebu/Kconfig | 2 --
 1 file changed, 2 deletions(-)

Quoted 1 line

Acked-by Jason Cooper <[email protected]>

Acked-by Gregory CLEMENT <[email protected]>

From 59532706506c0b3bf9f46499e7ba6c0f169e3802 Mon Sep 17 00:00:00 2001

The D-Link DNS-323 machine tries to unconditionally select CONFIG_PHYLIB, but that has other dependencies that might not necessarily be enabled, causing random build errors.

To work around this, this patch removes the 'select' statement and instead uses a compile-time check to skip the phy_register_fixup_for_uid() call if PHYLIB is not available in the kernel.

Signed-off-by Arnd Bergmann <[email protected]>

Cc Jason Cooper <[email protected]>

Cc Andrew Lunn <[email protected]>

Cc Gregory Clement <[email protected]>

Cc Sebastian Hesselbarth <[email protected]>

---
 arch/arm/mach-orion5x/Kconfig        | 1 -
 arch/arm/mach-orion5x/dns323-setup.c | 2 ++
 2 files changed, 2 insertions(+), 1 deletion(-)

The pxa platform code directly calls into the W100 framebuffer driver for eseries. This means it cannot be a loadable module and we also have to ensure that the core framebuffer code is built-in.

arch/arm/mach-pxa/Kconfig +1 -0

index 96100db..562b17f 100644
@@ -556,6 +556,7 @@ config MACH_ICONTROL
 config ARCH_PXA_ESERIES
 	bool "PXA based Toshiba e-series PDAs"
 	select FB_W100
+	select FB
 	select PXA25x
 
 config MACH_E330

drivers/video/Kconfig +2 -2

index dade5b7..86873ff 100644
@@ -1996,8 +1996,8 @@ config FB_FSL_DIU
 	  Framebuffer driver for the Freescale SoC DIU
 
 config FB_W100
-	tristate "W100 frame buffer support"
-	depends on FB && ARCH_PXA
+	bool "W100 frame buffer support"
+	depends on FB=y && ARCH_PXA
  	select FB_CFB_FILLRECT
  	select FB_CFB_COPYAREA
  	select FB_CFB_IMAGEBLIT

Signature · 1 line

1.8.3.2