wlcore: add device-tree support

From: Luciano Coelho <[email protected]>

Instead of defining an enumeration with the FW specific values for the different clock rates, use the actual frequency instead. Also add a boolean to specify whether the clock is XTAL or not.

Change all board files to reflect this.

Signed-off-by Luciano Coelho <[email protected]>

[Eliad - small fixes, update board file changes]

Signed-off-by Eliad Peller <[email protected]>

---
 arch/arm/mach-davinci/board-da850-evm.c |  3 +-
 arch/arm/mach-omap2/pdata-quirks.c      | 29 ++++++++--------
 drivers/net/wireless/ti/wl12xx/main.c   | 60 ++++++++++++++++++++++++++++++---
 drivers/net/wireless/ti/wl12xx/wl12xx.h | 28 +++++++++++++++
 include/linux/wl12xx.h                  | 27 ++-------------
 5 files changed, 103 insertions(+), 44 deletions(-)

arch/arm/mach-davinci/board-da850-evm.c +2 -1

index 916589c..853b941 100644
@@ -1386,7 +1386,8 @@ static const short da850_wl12xx_pins[] __initconst = {
 static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
 	.irq			= -1,
 	.irq_trigger		= IRQ_TYPE_EDGE_RISING,
-	.board_ref_clock	= WL12XX_REFCLOCK_38,
+	.ref_clock_freq		= 38400000,
+	.ref_clock_xtal		= false,
 };
 
 static __init int da850_wl12xx_init(void)

arch/arm/mach-omap2/pdata-quirks.c +14 -15

index 4449f4c..337cc22 100644
@@ -39,14 +39,14 @@ static struct twl4030_gpio_platform_data twl_gpio_auxdata;
 
 static struct wl12xx_platform_data wl12xx __initdata;
 
-static void __init __used legacy_init_wl12xx(unsigned ref_clock,
-					     unsigned tcxo_clock,
+static void __init __used legacy_init_wl12xx(u32 ref_clock_freq,
+					     u32 tcxo_clock_freq,
 					     int gpio)
 {
 	int res;
 
-	wl12xx.board_ref_clock = ref_clock;
-	wl12xx.board_tcxo_clock = tcxo_clock;
+	wl12xx.ref_clock_freq = ref_clock_freq;
+	wl12xx.tcxo_clock_freq = tcxo_clock_freq;
 	wl12xx.irq = gpio_to_irq(gpio);
 	wl12xx.irq_trigger = IRQ_TYPE_LEVEL_HIGH;
 

@@ -57,8 +57,8 @@ static void __init __used legacy_init_wl12xx(unsigned ref_clock,
 	}
 }
 #else
-static inline void legacy_init_wl12xx(unsigned ref_clock,
-				      unsigned tcxo_clock,
+static inline void legacy_init_wl12xx(u32 ref_clock_freq,
+				      u32 tcxo_clock_freq,
 				      int gpio)
 {
 }

@@ -130,7 +130,7 @@ static void __init omap3_sbc_t3730_twl_init(void)
 static void __init omap3_sbc_t3730_legacy_init(void)
 {
 	omap3_sbc_t3x_usb_hub_init(167, "sb-t35 usb hub");
-	legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 136);
+	legacy_init_wl12xx(38400000, 0, 136);
 }
 
 static void __init omap3_sbc_t3530_legacy_init(void)

@@ -174,12 +174,12 @@ static void __init omap3_igep0030_rev_g_legacy_init(void)
 
 static void __init omap3_evm_legacy_init(void)
 {
-	legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 149);
+	legacy_init_wl12xx(38400000, 0, 149);
 }
 
 static void __init omap3_zoom_legacy_init(void)
 {
-	legacy_init_wl12xx(WL12XX_REFCLOCK_26, 0, 162);
+	legacy_init_wl12xx(26000000, 0, 162);
 }
 
 static void am35xx_enable_emac_int(void)

@@ -246,7 +246,7 @@ static void __init omap3_sbc_t3517_legacy_init(void)
 	am35xx_emac_reset();
 	hsmmc2_internal_input_clk();
 	omap3_sbc_t3517_wifi_init();
-	legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 145);
+	legacy_init_wl12xx(38400000, 0, 145);
 }
 
 static void __init am3517_evm_legacy_init(void)

@@ -291,18 +291,17 @@ static void __init omap3_tao3530_legacy_init(void)
 #ifdef CONFIG_ARCH_OMAP4
 static void __init omap4_sdp_legacy_init(void)
 {
-	legacy_init_wl12xx(WL12XX_REFCLOCK_26,
-			   WL12XX_TCXOCLOCK_26, 53);
+	legacy_init_wl12xx(26000000, 26000000, 53);
 }
 
 static void __init omap4_panda_legacy_init(void)
 {
-	legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
+	legacy_init_wl12xx(38400000, 0, 53);
 }
 
 static void __init var_som_om44_legacy_init(void)
 {
-	legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 41);
+	legacy_init_wl12xx(38400000, 0, 41);
 }
 #endif
 

@@ -317,7 +316,7 @@ static struct iommu_platform_data omap4_iommu_pdata = {
 #ifdef CONFIG_SOC_AM33XX
 static void __init am335x_evmsk_legacy_init(void)
 {
-	legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 31);
+	legacy_init_wl12xx(38400000, 0, 31);
 }
 #endif
 

drivers/net/wireless/ti/wl12xx/main.c +56 -4

index 144d1f8..b3f751f 100644
@@ -1770,6 +1770,40 @@ wl12xx_iface_combinations[] = {
 	},
 };
 
+static const struct wl12xx_clock wl12xx_refclock_table[] = {
+	{ 19200000,	false,	WL12XX_REFCLOCK_19	},
+	{ 26000000,	false,	WL12XX_REFCLOCK_26	},
+	{ 26000000,	true,	WL12XX_REFCLOCK_26_XTAL	},
+	{ 38400000,	false,	WL12XX_REFCLOCK_38	},
+	{ 38400000,	true,	WL12XX_REFCLOCK_38_XTAL	},
+	{ 52000000,	false,	WL12XX_REFCLOCK_52	},
+	{ 0,		false,	0 }
+};
+
+static const struct wl12xx_clock wl12xx_tcxoclock_table[] = {
+	{ 16368000,	true,	WL12XX_TCXOCLOCK_16_368	},
+	{ 16800000,	true,	WL12XX_TCXOCLOCK_16_8	},
+	{ 19200000,	true,	WL12XX_TCXOCLOCK_19_2	},
+	{ 26000000,	true,	WL12XX_TCXOCLOCK_26	},
+	{ 32736000,	true,	WL12XX_TCXOCLOCK_32_736	},
+	{ 33600000,	true,	WL12XX_TCXOCLOCK_33_6	},
+	{ 38400000,	true,	WL12XX_TCXOCLOCK_38_4	},
+	{ 52000000,	true,	WL12XX_TCXOCLOCK_52	},
+	{ 0,		false,	0 }
+};
+
+static int wl12xx_get_clock_idx(const struct wl12xx_clock *table,
+				u32 freq, bool xtal)
+{
+	int i;
+
+	for (i = 0; table[i].freq != 0; i++)
+		if ((table[i].freq == freq) && (table[i].xtal == xtal))
+			return table[i].hw_idx;
+
+	return -EINVAL;
+}
+
 static int wl12xx_setup(struct wl1271 *wl)
 {
 	struct wl12xx_priv *priv = wl->priv;

@@ -1799,7 +1833,17 @@ static int wl12xx_setup(struct wl1271 *wl)
 	wl12xx_conf_init(wl);
 
 	if (!fref_param) {
-		priv->ref_clock = pdata->board_ref_clock;
+		priv->ref_clock = wl12xx_get_clock_idx(wl12xx_refclock_table,
+						       pdata->ref_clock_freq,
+						       pdata->ref_clock_xtal);
+		if (priv->ref_clock < 0) {
+			wl1271_error("Invalid ref_clock frequency (%d Hz, %s)",
+				     pdata->ref_clock_freq,
+				     pdata->ref_clock_xtal ?
+				     "XTAL" : "not XTAL");
+
+			return priv->ref_clock;
+		}
 	} else {
 		if (!strcmp(fref_param, "19.2"))
 			priv->ref_clock = WL12XX_REFCLOCK_19;

@@ -1817,9 +1861,17 @@ static int wl12xx_setup(struct wl1271 *wl)
 			wl1271_error("Invalid fref parameter %s", fref_param);
 	}
 
-	if (!tcxo_param) {
-		priv->tcxo_clock = pdata->board_tcxo_clock;
-	} else {
+	if (!tcxo_param && pdata->tcxo_clock_freq) {
+		priv->tcxo_clock = wl12xx_get_clock_idx(wl12xx_tcxoclock_table,
+							pdata->tcxo_clock_freq,
+							true);
+		if (priv->tcxo_clock < 0) {
+			wl1271_error("Invalid tcxo_clock frequency (%d Hz)",
+				     pdata->tcxo_clock_freq);
+
+			return priv->tcxo_clock;
+		}
+	} else if (tcxo_param) {
 		if (!strcmp(tcxo_param, "19.2"))
 			priv->tcxo_clock = WL12XX_TCXOCLOCK_19_2;
 		else if (!strcmp(tcxo_param, "26"))

drivers/net/wireless/ti/wl12xx/wl12xx.h +28 -0

index 75c9265..5952e99a 100644
@@ -82,6 +82,34 @@ struct wl12xx_priv {
 	struct wl127x_rx_mem_pool_addr *rx_mem_addr;
 };
 
+/* Reference clock values */
+enum {
+	WL12XX_REFCLOCK_19	= 0, /* 19.2 MHz */
+	WL12XX_REFCLOCK_26	= 1, /* 26 MHz */
+	WL12XX_REFCLOCK_38	= 2, /* 38.4 MHz */
+	WL12XX_REFCLOCK_52	= 3, /* 52 MHz */
+	WL12XX_REFCLOCK_38_XTAL = 4, /* 38.4 MHz, XTAL */
+	WL12XX_REFCLOCK_26_XTAL = 5, /* 26 MHz, XTAL */
+};
+
+/* TCXO clock values */
+enum {
+	WL12XX_TCXOCLOCK_19_2	= 0, /* 19.2MHz */
+	WL12XX_TCXOCLOCK_26	= 1, /* 26 MHz */
+	WL12XX_TCXOCLOCK_38_4	= 2, /* 38.4MHz */
+	WL12XX_TCXOCLOCK_52	= 3, /* 52 MHz */
+	WL12XX_TCXOCLOCK_16_368	= 4, /* 16.368 MHz */
+	WL12XX_TCXOCLOCK_32_736	= 5, /* 32.736 MHz */
+	WL12XX_TCXOCLOCK_16_8	= 6, /* 16.8 MHz */
+	WL12XX_TCXOCLOCK_33_6	= 7, /* 33.6 MHz */
+};
+
+struct wl12xx_clock {
+	u32	freq;
+	bool	xtal;
+	u8	hw_idx;
+};
+
 struct wl12xx_fw_packet_counters {
 	/* Cumulative counter of released packets per AC */
 	u8 tx_released_pkts[NUM_TX_QUEUES];

include/linux/wl12xx.h +3 -24

index 3876b67..eea1e6d 100644
@@ -26,28 +26,6 @@
 
 #include <linux/err.h>
 
-/* Reference clock values */
-enum {
-	WL12XX_REFCLOCK_19	= 0, /* 19.2 MHz */
-	WL12XX_REFCLOCK_26	= 1, /* 26 MHz */
-	WL12XX_REFCLOCK_38	= 2, /* 38.4 MHz */
-	WL12XX_REFCLOCK_52	= 3, /* 52 MHz */
-	WL12XX_REFCLOCK_38_XTAL = 4, /* 38.4 MHz, XTAL */
-	WL12XX_REFCLOCK_26_XTAL = 5, /* 26 MHz, XTAL */
-};
-
-/* TCXO clock values */
-enum {
-	WL12XX_TCXOCLOCK_19_2	= 0, /* 19.2MHz */
-	WL12XX_TCXOCLOCK_26	= 1, /* 26 MHz */
-	WL12XX_TCXOCLOCK_38_4	= 2, /* 38.4MHz */
-	WL12XX_TCXOCLOCK_52	= 3, /* 52 MHz */
-	WL12XX_TCXOCLOCK_16_368	= 4, /* 16.368 MHz */
-	WL12XX_TCXOCLOCK_32_736	= 5, /* 32.736 MHz */
-	WL12XX_TCXOCLOCK_16_8	= 6, /* 16.8 MHz */
-	WL12XX_TCXOCLOCK_33_6	= 7, /* 33.6 MHz */
-};
-
 struct wl1251_platform_data {
 	int power_gpio;
 	/* SDIO only: IRQ number if WLAN_IRQ line is used, 0 for SDIO IRQs */

@@ -58,8 +36,9 @@ struct wl1251_platform_data {
 struct wl12xx_platform_data {
 	int irq;
 	u32 irq_trigger;
-	int board_ref_clock;
-	int board_tcxo_clock;
+	bool ref_clock_xtal;	/* specify whether the clock is XTAL or not */
+	u32 ref_clock_freq;	/* in Hertz */
+	u32 tcxo_clock_freq;	/* in Hertz, tcxo is always XTAL */
 	bool pwr_in_suspend;
 };
 

Signature · 1 line

1.8.5.2.229.g4448466.dirty

Quoted 5 lines · Eliad Peller

From: Luciano Coelho <[email protected]>

Instead of defining an enumeration with the FW specific values for the different clock rates, use the actual frequency instead. Also add a boolean to specify whether the clock is XTAL or not.

Thanks for doing this. Just one comment on how we're going to get this all merged. Chances are this will cause merge conflicts between the wireless tree and the omap tree for the platform data and dts changes.

Can you please separate the wireless changes in this series so we can do this in the following sets:

1. Add support for new things to wireless driver

2. Switch platform code to use the new support

3. Remove support for platform data with a follow-up patch

The other option would be to have the whole series in a immutable branch against v3.0-rc1 that can be merged into both wirelss tree and omap tree.

Quoted 5 lines

The other option would be to have the whole series in a immutable branch against v3.0-rc1 that can be merged into both wirelss tree and omap tree.

i think that could be easier.

or maybe you can just take them all through the omap tree? the wlcore tree is not under active development, so i don't expect conflicts there.

Quoted 5 lines · On Sunday 15 March 2015 10:43:35 Eliad Peller wrote:

Quoted 5 lines

The other option would be to have the whole series in a immutable branch against v3.0-rc1 that can be merged into both wirelss tree and omap tree.

Quoted 5 lines

i think that could be easier.

or maybe you can just take them all through the omap tree? the wlcore tree is not under active development, so i don't expect conflicts there.

I'm fine with both these approaches.

Quoted 12 lines · Arnd Bergmann

Quoted 10 lines · On Sunday 15 March 2015 10:43:35 Eliad Peller wrote:

Quoted 5 lines

The other option would be to have the whole series in a immutable branch against v3.0-rc1 that can be merged into both wirelss tree and omap tree.

i think that could be easier.

or maybe you can just take them all through the omap tree? the wlcore tree is not under active development, so i don't expect conflicts there.

Quoted 1 line

I'm fine with both these approaches.

I prefer these going through the omap tree. Like Eliad said, drivers/net/wireless/ti does not get that many changes nowadays so the chances of this patchset conflicting with something is very small.

Quoted 3 lines

I prefer these going through the omap tree. Like Eliad said, drivers/net/wireless/ti does not get that many changes nowadays so the chances of this patchset conflicting with something is very small.

OK great. In that case no need to rearrange the patches, I can apply them into an immutable branch once the pending issues have been fixed if Kalle acks them.

To avoid merge conflicts that branch is easiest done against v4.0-rc4. Kalle and Arnd, does that work for you guys?

I can also base it on 5b7610f23562 ("ARM: OMAP2+: Fix wl12xx on dm3730-evm with mainline u-boot") that's on top of -rc2 plus few other fixes now merged to -rc4 mainline if we need a branch based on an earlier tag.

Quoted 8 lines · Tony Lindgren

Quoted 3 lines

I prefer these going through the omap tree. Like Eliad said, drivers/net/wireless/ti does not get that many changes nowadays so the chances of this patchset conflicting with something is very small.

OK great. In that case no need to rearrange the patches, I can apply them into an immutable branch once the pending issues have been fixed if Kalle acks them.

Quoted 7 lines

To avoid merge conflicts that branch is easiest done against v4.0-rc4. Kalle and Arnd, does that work for you guys?

I can also base it on 5b7610f23562 ("ARM: OMAP2+: Fix wl12xx on dm3730-evm with mainline u-boot") that's on top of -rc2 plus few other fixes now merged to -rc4 mainline if we need a branch based on an earlier tag.

Sorry, it seems I forgot to answer this one:

Either baseline is good for me, I can't think of any problems with either one. But please do remember that I'm a new maintainer, I might very well miss something ;)

Replace all the pdata-quirks for setting wl12xx/wl18xx platform data with proper DT definitions.

The patch was compile-tested only.

Signed-off-by Eliad Peller <[email protected]>

---

Hello Eliad,

Quoted 7 lines · Eliad Peller

Replace all the pdata-quirks for setting wl12xx/wl18xx platform data with proper DT definitions.

The patch was compile-tested only.

Signed-off-by Eliad Peller <[email protected]>

---

I wanted to test your series but I realized that the IGEPv2 I've access is the old revision that has another SDIO wlan module instead of a Wilink8.

Maybe Enric have the new revision? I also added to Pau Pajuel as cc who still works in the company manufacturing these boards so he should be able to test it.

But in any case, your patch looks good to me so for the arch/arm/boot/dts/omap3-igep00* changes:

Acked-by Javier Martinez Canillas <[email protected]>

Best regards,
Javier

Hello,

2015-03-13 9:01 GMT+01:00 Javier Martinez Canillas <[email protected]>:

Quoted 11 lines

Hello Eliad,

Quoted 7 lines · Eliad Peller

Replace all the pdata-quirks for setting wl12xx/wl18xx platform data with proper DT definitions.

The patch was compile-tested only.

Signed-off-by Eliad Peller <[email protected]>

---

Quoted 8 lines

I wanted to test your series but I realized that the IGEPv2 I've access is the old revision that has another SDIO wlan module instead of a Wilink8.

Maybe Enric have the new revision? I also added to Pau Pajuel as cc who still works in the company manufacturing these boards so he should be able to test it.

Sorry, now I only have an old revision too, so I can't test, cc'ing Agustí that has access to the hardware, maybe he can test it or he can provide to us a board ;)

Quoted 5 lines

But in any case, your patch looks good to me so for the arch/arm/boot/dts/omap3-igep00* changes:

Acked-by Javier Martinez Canillas <[email protected]>

For my part also looks good.

Acked-by Enric Balletbo i Serra <[email protected]>

Best regards,
Enric

Quoted 2 lines

Best regards,
Javier

Hi,

2015-03-13 9:17 GMT+01:00 Enric Balletbo Serra <[email protected]>:

Quoted 34 lines

Hello,

2015-03-13 9:01 GMT+01:00 Javier Martinez Canillas <[email protected]>:

Quoted 11 lines

Hello Eliad,

Quoted 7 lines · Eliad Peller

Replace all the pdata-quirks for setting wl12xx/wl18xx platform data with proper DT definitions.

The patch was compile-tested only.

Signed-off-by Eliad Peller <[email protected]>

---

Quoted 8 lines

I wanted to test your series but I realized that the IGEPv2 I've access is the old revision that has another SDIO wlan module instead of a Wilink8.

Maybe Enric have the new revision? I also added to Pau Pajuel as cc who still works in the company manufacturing these boards so he should be able to test it.

Sorry, now I only have an old revision too, so I can't test, cc'ing Agust? that has access to the hardware, maybe he can test it or he can provide to us a board ;)

Quoted 5 lines

But in any case, your patch looks good to me so for the arch/arm/boot/dts/omap3-igep00* changes:

Acked-by Javier Martinez Canillas <[email protected]>

Quoted 9 lines

For my part also looks good.

Acked-by Enric Balletbo i Serra <[email protected]>

Best regards,
Enric

Quoted 2 lines

Best regards,
Javier

I'm gonna test it this week. I added Eduard Gavin as cc too.

Cheers!

arch/arm/mach-omap2/pdata-quirks.c static struct platform_device btwilink_device = { · line 178

Quoted 7 lines · Eliad Peller

arch/arm/mach-omap2/pdata-quirks.c +0 -4

 
-static void __init omap3_evm_legacy_init(void)
-{
-     legacy_init_wl12xx(38400000, 0, 149);
-}

FYI, at least this part conflicts with the fixes in the arm-soc tree for the v4.0-rc series as omap3 evm also needs the copy clock quirk.

arch/arm/mach-omap2/pdata-quirks.c static struct pdata_init pdata_quirks[] __initdata = { · line 422

Quoted 5 lines

arch/arm/mach-omap2/pdata-quirks.c +0 -1

@@ -419,20 +351,9 @@ static struct pdata_init pdata_quirks[] __initdata = {
      { "nokia,omap3-n950", hsmmc2_internal_input_clk, },
      { "isee,omap3-igep0020-rev-f", omap3_igep0020_rev_f_legacy_init, },
      { "isee,omap3-igep0030-rev-g", omap3_igep0030_rev_g_legacy_init, },
-     { "ti,omap3-evm-37xx", omap3_evm_legacy_init, },

So this function cannot be yet removed.

With that fixed, I was able to iw dev wlan0 scan with series on omap3 evm :)

Now that we have wlcore device-tree bindings in place (for both wl12xx and wl18xx), remove the legacy wl12xx_platform_data struct, and move its members into the platform device data (that is passed to wlcore)

Davinci 850 is the only platform that still set the platform data in the legacy way (and doesn't have DT bindings), so remove the relevant code/Kconfig option from the board file (as suggested by Sekhar Nori)

Signed-off-by Luciano Coelho <[email protected]>

Signed-off-by Eliad Peller <[email protected]>

---
 arch/arm/mach-davinci/Kconfig                  |  11 ---
 arch/arm/mach-davinci/board-da850-evm.c        | 113 -------------------------
 drivers/net/wireless/ti/wilink_platform_data.c |  25 ------
 drivers/net/wireless/ti/wl12xx/main.c          |  19 ++---
 drivers/net/wireless/ti/wlcore/boot.c          |   1 -
 drivers/net/wireless/ti/wlcore/main.c          |   4 +-
 drivers/net/wireless/ti/wlcore/sdio.c          |  75 +++++-----------
 drivers/net/wireless/ti/wlcore/wlcore_i.h      |   8 +-
 include/linux/wl12xx.h                         |  25 ------
 9 files changed, 36 insertions(+), 245 deletions(-)

Quoted 13 lines · Eliad Peller

Now that we have wlcore device-tree bindings in place (for both wl12xx and wl18xx), remove the legacy wl12xx_platform_data struct, and move its members into the platform device data (that is passed to wlcore)

Davinci 850 is the only platform that still set the platform data in the legacy way (and doesn't have DT bindings), so remove the relevant code/Kconfig option from the board file (as suggested by Sekhar Nori)

Signed-off-by Luciano Coelho <[email protected]>

Signed-off-by Eliad Peller <[email protected]>

Quoted 11 lines

---
 arch/arm/mach-davinci/Kconfig                  |  11 ---
 arch/arm/mach-davinci/board-da850-evm.c        | 113 -------------------------
 drivers/net/wireless/ti/wilink_platform_data.c |  25 ------
 drivers/net/wireless/ti/wl12xx/main.c          |  19 ++---
 drivers/net/wireless/ti/wlcore/boot.c          |   1 -
 drivers/net/wireless/ti/wlcore/main.c          |   4 +-
 drivers/net/wireless/ti/wlcore/sdio.c          |  75 +++++-----------
 drivers/net/wireless/ti/wlcore/wlcore_i.h      |   8 +-
 include/linux/wl12xx.h                         |  25 ------
 9 files changed, 36 insertions(+), 245 deletions(-)

I got a build error related to the SPI driver with this series, probably need to update this patch:

drivers/net/wireless/ti/wlcore/spi.c: In function ?wl1271_probe?:
drivers/net/wireless/ti/wlcore/spi.c:334:11: error: ?struct wlcore_platdev_data? has no member named ?pdata?

  pdev_data.pdata = dev_get_platdata(&spi->dev);
           ^

drivers/net/wireless/ti/wlcore/spi.c:335:16: error: ?struct wlcore_platdev_data? has no member named ?pdata?
if (!pdev_data.pdata) {

yeah, i missed it :/

looks like there's no platform that defines platform data for it. i'll replace the dev_get_platdata() with a function that only parses the clock-frequency properties (the irq is taken in this case from the spi_device).
(or maybe i should just drop it, as no one actually uses it?)

Quoted 7 lines · On Sunday 15 March 2015 10:50:42 Eliad Peller wrote:

yeah, i missed it :/

looks like there's no platform that defines platform data for it. i'll replace the dev_get_platdata() with a function that only parses the clock-frequency properties (the irq is taken in this case from the spi_device).
(or maybe i should just drop it, as no one actually uses it?)

I don't think we should drop the driver, but dropping the platform_data support sounds reasonable. New users of this driver should all be using DT, and if there is a good reason to use platform_data, it's easily put back.

Quoted 9 lines · Arnd Bergmann

Quoted 7 lines · On Sunday 15 March 2015 10:50:42 Eliad Peller wrote:

yeah, i missed it :/

looks like there's no platform that defines platform data for it. i'll replace the dev_get_platdata() with a function that only parses the clock-frequency properties (the irq is taken in this case from the spi_device).
(or maybe i should just drop it, as no one actually uses it?)

Quoted 4 lines

I don't think we should drop the driver, but dropping the platform_data support sounds reasonable. New users of this driver should all be using DT, and if there is a good reason to use platform_data, it's easily put back.

Well we have n8x0 and n900 using the spi driver. For those, n8x0 boot all in dts mode, but n900 still also boots in legacy mode. It seems the board-rx51-peripherals.c only passes the power_gpio though, so that should be easy to keep around.

We should keep things still working for n900 in legacy mode until the pending regressions with device tree based booting have been cleared for at least one merge cycle. I believe the last pending issues is the support for ATAG_REVISION in device tree mode as posted by Pali.

Hi,

Quoted 20 lines · Tony Lindgren

Quoted 9 lines · Arnd Bergmann

Quoted 7 lines · On Sunday 15 March 2015 10:50:42 Eliad Peller wrote:

yeah, i missed it :/

looks like there's no platform that defines platform data for it. i'll replace the dev_get_platdata() with a function that only parses the clock-frequency properties (the irq is taken in this case from the spi_device).
(or maybe i should just drop it, as no one actually uses it?)

Quoted 4 lines

I don't think we should drop the driver, but dropping the platform_data support sounds reasonable. New users of this driver should all be using DT, and if there is a good reason to use platform_data, it's easily put back.

Well we have n8x0 and n900 using the spi driver. For those, n8x0 boot all in dts mode, but n900 still also boots in legacy mode. It seems the board-rx51-peripherals.c only passes the power_gpio though, so that should be easy to keep around.

Quoted 4 lines

We should keep things still working for n900 in legacy mode until the pending regressions with device tree based booting have been cleared for at least one merge cycle. I believe the last pending issues is the support for ATAG_REVISION in device tree mode as posted by Pali.

mh by migrating to newer gpiod interface platform data is no longer needed (instead the boardfile would need a gpiod_lookup_table). That way all of the dirty code is in the board file and will be removed once the time comes. See for example rx51_fmtx_gpios_table.

Note: This is independent of wl12xx changes, since N900 uses wl1251.

Quoted 33 lines · Sebastian Reichel

Hi,

Quoted 20 lines · Tony Lindgren

Quoted 9 lines · Arnd Bergmann

Quoted 7 lines · On Sunday 15 March 2015 10:50:42 Eliad Peller wrote:

yeah, i missed it :/

looks like there's no platform that defines platform data for it. i'll replace the dev_get_platdata() with a function that only parses the clock-frequency properties (the irq is taken in this case from the spi_device).
(or maybe i should just drop it, as no one actually uses it?)

Quoted 4 lines

I don't think we should drop the driver, but dropping the platform_data support sounds reasonable. New users of this driver should all be using DT, and if there is a good reason to use platform_data, it's easily put back.

Well we have n8x0 and n900 using the spi driver. For those, n8x0 boot all in dts mode, but n900 still also boots in legacy mode. It seems the board-rx51-peripherals.c only passes the power_gpio though, so that should be easy to keep around.

Quoted 4 lines

We should keep things still working for n900 in legacy mode until the pending regressions with device tree based booting have been cleared for at least one merge cycle. I believe the last pending issues is the support for ATAG_REVISION in device tree mode as posted by Pali.

mh by migrating to newer gpiod interface platform data is no longer needed (instead the boardfile would need a gpiod_lookup_table). That way all of the dirty code is in the board file and will be removed once the time comes. See for example rx51_fmtx_gpios_table.

Quoted 1 line

Note: This is independent of wl12xx changes, since N900 uses wl1251.

Oh sorry yes sounds like that's different platform data then. In that case I see no reasons to drop the platform data for wl12xx.

I believe the last pending issues is the support for ATAG_REVISION in device tree mode as posted by Pali.

Quoted 3 lines · On Monday 16 March 2015 16:29:39 Tony Lindgren wrote:

I believe the last pending issues is the support for ATAG_REVISION in device tree mode as posted by Pali.

No. In DT boot there is missing /proc/atags file (readable by userspace processes).

And also broken AES/SHA/MD5 support. Fix for crypto DT stuff I already sent.

Quoted 6 lines · Pali Roh?r

Quoted 2 lines · On Monday 16 March 2015 16:29:39 Tony Lindgren wrote:

I believe the last pending issues is the support for ATAG_REVISION in device tree mode as posted by Pali.

No. In DT boot there is missing /proc/atags file (readable by userspace processes).

Oh OK thanks for the update.

Quoted 2 lines

And also broken AES/SHA/MD5 support. Fix for crypto DT stuff I already sent.

But this is not a regression in mainline with legacy boot vs device tree based booting, right? Sounds like it never worked in the mainline or am thinking of some other set of patches?

Regards,

Tony

Quoted 17 lines · On Monday 16 March 2015 22:01:43 Tony Lindgren wrote:

Quoted 6 lines · Pali Roh?r

Quoted 2 lines · On Monday 16 March 2015 16:29:39 Tony Lindgren wrote:

I believe the last pending issues is the support for ATAG_REVISION in device tree mode as posted by Pali.

No. In DT boot there is missing /proc/atags file (readable by userspace processes).

Oh OK thanks for the update.

Quoted 2 lines

And also broken AES/SHA/MD5 support. Fix for crypto DT stuff I already sent.

But this is not a regression in mainline with legacy boot vs device tree based booting, right? Sounds like it never worked in the mainline or am thinking of some other set of patches?

Quoted 3 lines

Regards,

Tony

In legacy board code are DMA channels defined. In DT files not. So I think this is regression. Omap secure devices are broken in both legacy & DT code, but non secure could work with legacy code. But all devices booted with DT are broken.

NOTE: all the platform patches were compile-tested only. I'm looking for some wl12xx card (that i should have somewhere) to test the wl12xx changes (wrt. clocks), but haven't found it yet.

Hello,

Quoted 6 lines · Eliad Peller

NOTE: all the platform patches were compile-tested only. I'm looking for some wl12xx card (that i should have somewhere) to test the wl12xx changes (wrt. clocks), but haven't found it yet.

I have tested this series on a APF6 board, i.MX6 based board with a Jorjin WG7311-0A Wifi/BT module which is based on the wl1271l.

It works. I was able to power up the wlan0 interface and ping google.