MMC SPI support for OpenFirmware platforms
Subsystems (5)
cover MMC SPI support for OpenFirmware platforms
Hi all,
Here are the bindings, again. Still RFC.
This patch series depends on:
http://lkml.org/lkml/2008/10/16/250
http://lkml.org/lkml/2008/10/24/416
+ of_gpio_flags enum (Trent Piepho will post an updated patch soon, I believe).
Pierre, the approach is somewhat similar to this one:
http://lkml.org/lkml/2008/5/26/135
Posted few months ago.
I know you don't like it, but I ask you to reconsider it. The I2C and SPI cases are similar, and recently we tried to write bindings for some I2C GPIO controllers.
There we've learned that we:
1. Don't like the bus notifiers approach b/c we can't place the OF code into the module.
http://lkml.org/lkml/2008/10/21/425
Hacks are possible, but they're are ugly.
2. Don't want to write new drivers to solely handle the platform data:
http://lkml.org/lkml/2008/10/28/257
http://lkml.org/lkml/2008/10/28/268
And personally I don't want to do refactoring for every driver that we'd want to use with the OpenFirmware...
If I understood correctly, for GPIO controllers David agreed that we can live with the platform data accessors, at least for now:
http://lkml.org/lkml/2008/10/23/24
And when/if we'll find something better I'll be the first who will offer help to convert the bindings code to this "something better".
Thanks,
Signature · 3 lines
Anton Vorontsov email: [email protected] irc://irc.freenode.net/bd2
PATCH 1/3 powerpc: Add mmc-spi-slot bindings
The bindings describes a case where MMC/SD/SDIO slot directly connected to a SPI bus. Such setups are widely used on embedded PowerPC boards.
The patch also adds the mmc-spi-slot entry to the OpenFirmware modalias table.
--- .../powerpc/dts-bindings/mmc-spi-slot.txt | 23 ++++++++++++++++++++ drivers/of/base.c | 1 + 2 files changed, 24 insertions(+), 0 deletions(-) create mode 100644 Documentation/powerpc/dts-bindings/mmc-spi-slot.txt
Documentation/powerpc/dts-bindings/mmc-spi-slot.txt new file +23 -0
@@ -0,0 +1,23 @@ +MMC/SD/SDIO slot directly connected to a SPI bus + +Required properties: +- compatible : should be "mmc-spi-slot". +- reg : should specify SPI address (chip-select number). +- spi-max-frequency : maximum frequency for this device (Hz). +- voltage-ranges : two cells are required, first cell specifies minimum + slot voltage (mV), second cell specifies maximum slot voltage (mV). + Several ranges could be specified. +- gpios : (optional) may specify GPIOs in this order: Card-Detect GPIO, + Write-Protect GPIO. + +Example: + + mmc-slot@0 { + compatible = "fsl,mpc8323rdb-mmc-slot", + "mmc-spi-slot"; + reg = <0>; + gpios = <&qe_pio_d 14 1 + &qe_pio_d 15 0>; + voltage-ranges = <3300 3300>; + spi-max-frequency = <50000000>; + };
drivers/of/base.c +1 -0
@@ -411,6 +411,7 @@ struct of_modalias_table { };static struct of_modalias_table of_modalias_table[] = { {"fsl,mcu-mpc8349emitx" ,"mcu-mpc8349emitx" }, + {"mmc-spi-slot" ,"mmc_spi" }, };/**
Signature · 1 line
1.5.6.3
Re: [PATCH 1/3] powerpc: Add mmc-spi-slot bindings
Quoted 7 lines · Anton Vorontsov
The bindings describes a case where MMC/SD/SDIO slot directly connected to a SPI bus. Such setups are widely used on embedded PowerPC boards.
The patch also adds the mmc-spi-slot entry to the OpenFirmware modalias table.
Signed-off-by Anton Vorontsov <[email protected]>
Mostly looks good to me. A few comments below.
Quoted 13 lines
--- .../powerpc/dts-bindings/mmc-spi-slot.txt | 23 ++++++++++++++++++++ drivers/of/base.c | 1 + 2 files changed, 24 insertions(+), 0 deletions(-) create mode 100644 Documentation/powerpc/dts-bindings/mmc-spi-slot.txtDocumentation/powerpc/dts-bindings/mmc-spi-slot.txt new file +1
-0@@ -0,0 +1,23 @@ +MMC/SD/SDIO slot directly connected to a SPI bus
Documentation/powerpc/dts-bindings/mmc-spi-slot.txt line 11
Quoted 10 lines
Documentation/powerpc/dts-bindings/mmc-spi-slot.txt new file +10
-0+ +Required properties: +- compatible : should be "mmc-spi-slot". +- reg : should specify SPI address (chip-select number). +- spi-max-frequency : maximum frequency for this device (Hz). +- voltage-ranges : two cells are required, first cell specifies minimum + slot voltage (mV), second cell specifies maximum slot voltage (mV). + Several ranges could be specified. +- gpios : (optional) may specify GPIOs in this order: Card-Detect GPIO, + Write-Protect GPIO.
I wonder if we're following the example of irq mappings too closely for the gpios property. I like the layout of the property (<controller> <specifier>), but I think the 'gpios' name is getting too overloaded. In this case a single property 'gpios' is being used to encode 2 unrelated bits of information; the write protect pin and the card detect pins.
In this particular case I think it is better to use 2 properties in this case; something like 'spi-writeprotect-gpio' and 'spi-carddetect-gpio' using the same specifier format. Doing so adds a bit more clarity to the purpose of the properties.
I my mind I differentiate this from other examples (for instance a series of CS pins) based on how closely related the pin functions are.
So I would say for the following examples...
1) GPIO data bus (SPI, MDIO and I2C are great examples); all pins must be present - single gpio property
2) This MMC case (pins are optional and unrelated); separate gpio properties
3) LCD with backlight and contrast control pins; one gpio property for backlight pins, one for constrast pins.
Thoughts?
Quoted 28 lines
Documentation/powerpc/dts-bindings/mmc-spi-slot.txt new file +12
-0+ +Example: + + mmc-slot@0 { + compatible = "fsl,mpc8323rdb-mmc-slot", + "mmc-spi-slot"; + reg = <0>; + gpios = <&qe_pio_d 14 1 + &qe_pio_d 15 0>; + voltage-ranges = <3300 3300>; + spi-max-frequency = <50000000>; + };drivers/of/base.c +1
-1@@ -411,6 +411,7 @@ struct of_modalias_table { };static struct of_modalias_table of_modalias_table[] = { {"fsl,mcu-mpc8349emitx" ,"mcu-mpc8349emitx" }, + {"mmc-spi-slot" ,"mmc_spi" }, };/** -- 1.5.6.3
Signature · 2 lines
Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.
Re: [PATCH 1/3] powerpc: Add mmc-spi-slot bindings
On Thu, Oct 30, 2008 at 02:37:31PM -0600, Grant Likely wrote:
[...]
Quoted 24 lines
Quoted 2 lines
+- gpios : (optional) may specify GPIOs in this order: Card-Detect GPIO, + Write-Protect GPIO.I wonder if we're following the example of irq mappings too closely for the gpios property. I like the layout of the property (<controller> <specifier>), but I think the 'gpios' name is getting too overloaded. In this case a single property 'gpios' is being used to encode 2 unrelated bits of information; the write protect pin and the card detect pins.
In this particular case I think it is better to use 2 properties in this case; something like 'spi-writeprotect-gpio' and 'spi-carddetect-gpio' using the same specifier format. Doing so adds a bit more clarity to the purpose of the properties.
I my mind I differentiate this from other examples (for instance a series of CS pins) based on how closely related the pin functions are.
So I would say for the following examples...
1) GPIO data bus (SPI, MDIO and I2C are great examples); all pins must be present - single gpio property
2) This MMC case (pins are optional and unrelated); separate gpio properties
3) LCD with backlight and contrast control pins; one gpio property for backlight pins, one for constrast pins.
Quoted 1 line
Thoughts?
It's pretty trivial to implement (of_get_named_gpio() -- could be just factored out of of_get_gpio()).
Though,
1. The idea is quite extreme. It needs discussion, and furthermore, we need to define when do we use gpios = <> and when something-gpio = <>; We need to be consistent, and to be consistent, the rules should be clear and written.
2. We should think about it very very carefully. Do we want to lose the track of gpios? For example, there are quite defined rules when (and in what properties) you may encounter memory addresses, when and where you can encounter interrupt specifiers. We do the same for gpios, and so far it works great. We need to think about any possible drawbacks of the scheme you purpose (we would never know where to expect gpios - it isn't a problem per se, but maybe it could lead to some problem in future? I don't know.)
Quite honestly I don't like the idea... maybe I just used to interrupts = <>, reg = <>, ranges = <>, interrupt-map = <> and so forth, and now my subconsciousness tells me "it's wrong to do something-interrupt = <> stuff." ;-)
Anyway, your proposal is forward and backward compatible with the existing scheme, and can even coexist. Thus I'd prefer to stay with the today's gpios = <>. We can always start use the new scheme when it will be thought out enough.
Thanks,
p.s. I'd prefer a new thread for this discussion, somewhere in [email protected], so that it won't relate to this particular patch.
Signature · 3 lines
Anton Vorontsov email: [email protected] irc://irc.freenode.net/bd2
Re: [PATCH 1/3] powerpc: Add mmc-spi-slot bindings
Quoted 47 lines · Anton Vorontsov
On Thu, Oct 30, 2008 at 02:37:31PM -0600, Grant Likely wrote:
[...]Quoted 24 lines
Quoted 2 lines
+- gpios : (optional) may specify GPIOs in this order: Card-Detect GPIO, + Write-Protect GPIO.I wonder if we're following the example of irq mappings too closely for the gpios property. I like the layout of the property (<controller> <specifier>), but I think the 'gpios' name is getting too overloaded. In this case a single property 'gpios' is being used to encode 2 unrelated bits of information; the write protect pin and the card detect pins.
In this particular case I think it is better to use 2 properties in this case; something like 'spi-writeprotect-gpio' and 'spi-carddetect-gpio' using the same specifier format. Doing so adds a bit more clarity to the purpose of the properties.
I my mind I differentiate this from other examples (for instance a series of CS pins) based on how closely related the pin functions are.
So I would say for the following examples...
1) GPIO data bus (SPI, MDIO and I2C are great examples); all pins must be present - single gpio property
2) This MMC case (pins are optional and unrelated); separate gpio properties
3) LCD with backlight and contrast control pins; one gpio property for backlight pins, one for constrast pins.Quoted 1 line
Thoughts?
It's pretty trivial to implement (
of_get_named_gpio()-- could be just factored out ofof_get_gpio()).Though,
1. The idea is quite extreme. It needs discussion, and furthermore, we need to define when do we use gpios = <> and when something-gpio = <>; We need to be consistent, and to be consistent, the rules should be clear and written.
2. We should think about it very very carefully. Do we want to lose the track of gpios? For example, there are quite defined rules when (and in what properties) you may encounter memory addresses, when and where you can encounter interrupt specifiers. We do the same for gpios, and so far it works great. We need to think about any possible drawbacks of the scheme you purpose (we would never know where to expect gpios - it isn't a problem per se, but maybe it could lead to some problem in future? I don't know.)
Quoted 4 lines
Quite honestly I don't like the idea... maybe I just used to interrupts = <>, reg = <>, ranges = <>, interrupt-map = <> and so forth, and now my subconsciousness tells me "it's wrong to do something-interrupt = <> stuff." ;-)
Fwiw, I agree. The current scheme works, adding new places to look for gpio specifiers will just complexify things. Long lists of gpios may be somewhat awkward to work with, but I don't think it's sufficiently bad to warrant another scheme.
Signature · 4 lines
David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Re: [PATCH 1/3] powerpc: Add mmc-spi-slot bindings
In reply to Anton VorontsovOn Fri, Oct 31, 2008 at 02:02:53AM +0300, Anton Vorontsov wrote:
[...]
Quoted 19 lines
It's pretty trivial to implement (
of_get_named_gpio()-- could be just factored out ofof_get_gpio()).Though,
1. The idea is quite extreme. It needs discussion, and furthermore, we need to define when do we use gpios = <> and when something-gpio = <>; We need to be consistent, and to be consistent, the rules should be clear and written.
2. We should think about it very very carefully. Do we want to lose the track of gpios? For example, there are quite defined rules when (and in what properties) you may encounter memory addresses, when and where you can encounter interrupt specifiers. We do the same for gpios, and so far it works great. We need to think about any possible drawbacks of the scheme you purpose (we would never know where to expect gpios - it isn't a problem per se, but maybe it could lead to some problem in future? I don't know.)
Quoted 4 lines
Quite honestly I don't like the idea... maybe I just used to interrupts = <>, reg = <>, ranges = <>, interrupt-map = <> and so forth, and now my subconsciousness tells me "it's wrong to do something-interrupt = <> stuff." ;-)
Btw, not that I hate this new scheme, sometimes the scheme is even inevitable. For example when we have gpios with two or more ellipsis:
gpios = <... ...>.
But this should be a separate discussion, really.
Signature · 3 lines
Anton Vorontsov email: [email protected] irc://irc.freenode.net/bd2
PATCH 2/3 mmc: Add mmc_vddrange_to_ocrmask() helper function
In reply to Anton VorontsovThis function sets the OCR mask bits according to provided voltage ranges. Will be used by the mmc_spi OpenFirmware bindings.
--- drivers/mmc/core/core.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++ include/linux/mmc/core.h | 3 ++ 2 files changed, 58 insertions(+), 0 deletions(-)
drivers/mmc/core/core.c +55 -0
@@ -20,6 +20,7 @@#include <linux/err.h> #include <linux/leds.h> #include <linux/scatterlist.h> +#include <linux/log2.h> #include <linux/mmc/card.h> #include <linux/mmc/host.h>
@@ -444,6 +445,60 @@ void mmc_set_bus_width(struct mmc_host *host, unsigned int width)mmc_set_ios (host); } +static int mmc_vdd_to_ocrbit (int vdd) +{ +int bit; +const int max_bit =ilog2 (MMC_VDD_35_36 ); + +if (vdd <1650 || vdd >3600 ) +return -EINVAL ; + +if (vdd >=1650 && vdd <=1950 ) +return ilog2 (MMC_VDD_165_195 ); + +/* base 2000 mV, step 100 mV, bit's base 8 */ + bit = (vdd -2000 ) /100 +8 ; +if (bit > max_bit) +return max_bit; +return bit; +} + +/** +* mmc_vddrange_to_ocrmask - Convert a voltage range to the OCR mask +* @vdd_min: minimum voltage value (mV) +* @vdd_max: maximum voltage value (mV) +* @mask: pointer to the mask +* +* This function sets the OCR mask bits according to the provided @vdd_min +* and @vdd_max values. +* +* NOTE: You _must_ set the mask value to 0 before calling this function the +* first time. This is done so that you can call this function several +* times to set OCR mask for discontinuous voltage ranges. +* +* The function returns 0 on success and a negative errno value when +* a conversion is not possible. +*/ +int mmc_vddrange_to_ocrmask (int vdd_min,int vdd_max,unsigned int *mask) +{ +if (vdd_max < vdd_min) +return -EINVAL ; + + vdd_max =mmc_vdd_to_ocrbit (vdd_max); +if (vdd_max <0 ) +return -EINVAL ; + + vdd_min =mmc_vdd_to_ocrbit (vdd_min); +if (vdd_min <0 ) +return -EINVAL ; + +/* fill the mask, from max bit to min bit */ +while (vdd_max >= vdd_min) + *mask |=1 << vdd_max--; +return 0 ; +} +EXPORT_SYMBOL (mmc_vddrange_to_ocrmask); +/* * Mask off any voltages we don't support and select * the lowest voltage
include/linux/mmc/core.h +3 -0
@@ -151,4 +151,7 @@ static inline void mmc_claim_host(struct mmc_host *host) __mmc_claim_host(host, NULL); } +extern int mmc_vddrange_to_ocrmask (int vdd_min,int vdd_max, +unsigned int *mask); +#endif
Signature · 1 line
1.5.6.3
Re: [PATCH 2/3] mmc: Add mmc_vddrange_to_ocrmask() helper function
Quoted 6 lines · On Thu, 30 Oct 2008 22:56:32 +0300 Anton Vorontsov <[email protected]>…
+/**
+ *mmc_vddrange_to_ocrmask- Convert a voltage range to the OCR mask
+ * @vdd_min: minimum voltage value (mV)
+ * @vdd_max: maximum voltage value (mV)
+ * @mask: pointer to the mask
+ *
Why the pointer? Why not let the caller handle the aggregation? That would be a lot safer.
drivers/mmc/core/core.c void mmc_set_bus_width(struct mmc_host *host, unsigned int width) · line 498
Quoted 4 lines
drivers/mmc/core/core.c +4
-0+/* fill the mask, from max bit to min bit */ +while (vdd_max >= vdd_min) + *mask |=1 << vdd_max--; +return 0 ;
Many cards get a bit uppity with a single bit set. If possible, try to make this function set two bits when the voltage is right on the boundary (e.g. 3.3V).
Rgds
Signature · 9 lines
-- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org rdesktop, core developer http://www.rdesktop.org WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption.
PATCH v2 1/1 mmc: Add mmc_vddrange_to_ocrmask() helper function
This function sets the OCR mask bits according to provided voltage ranges. Will be used by the mmc_spi OpenFirmware bindings.
---
Hi Pierre,
Sorry for the delay.
Quoted 10 lines · Pierre Ossman
Quoted 6 lines · On Thu, 30 Oct 2008 22:56:32 +0300 Anton Vorontsov <[email protected]>…
+/**
+ *mmc_vddrange_to_ocrmask- Convert a voltage range to the OCR mask
+ * @vdd_min: minimum voltage value (mV)
+ * @vdd_max: maximum voltage value (mV)
+ * @mask: pointer to the mask
+ *
Quoted 2 lines
Why the pointer? Why not let the caller handle the aggregation? That would be a lot safer.
Yeah, makes sense. Now the function returns OCR mask, or 0 on error.
Quoted 8 lines
Review
Quoted 4 lines
(quoted diff) +4
-0+ /* fill the mask, from max bit to min bit */ + while (vdd_max >= vdd_min) + *mask |= 1 << vdd_max--; + return 0;Many cards get a bit uppity with a single bit set. If possible, try to make this function set two bits when the voltage is right on the boundary (e.g. 3.3V).
Something like this patch (the boundary cases are documented now)?
p.s. If the patch is OK I'll respin the whole patchset.
drivers/mmc/core/core.c | 75 ++++++++++++++++++++++++++++++++++++++++++++++ include/linux/mmc/core.h | 2 + 2 files changed, 77 insertions(+), 0 deletions(-)
drivers/mmc/core/core.c +75 -0
@@ -20,6 +20,7 @@#include <linux/err.h> #include <linux/leds.h> #include <linux/scatterlist.h> +#include <linux/log2.h> #include <linux/mmc/card.h> #include <linux/mmc/host.h>
@@ -444,6 +445,80 @@ void mmc_set_bus_width(struct mmc_host *host, unsigned int width)mmc_set_ios (host); } +/** +* mmc_vdd_to_ocrbitnum - Convert a voltage to the OCR bit number +* @vdd: voltage (mV) +* @low_bits: prefer low bits in boundary cases +* +* This function returns the OCR bit number according to the provided @vdd +* value. If conversion is not possible a negative errno value returned. +* +* Depending on the @low_bits flag the function prefers low or high OCR bits +* on boundary voltages. For example, +* with @low_bits = true, 3300 mV translates to ilog2(MMC_VDD_32_33); +* with @low_bits = false, 3300 mV translates to ilog2(MMC_VDD_33_34); +* +* Any value in the [1951:1999] range translates to the ilog2(MMC_VDD_20_21). +*/ +static int mmc_vdd_to_ocrbitnum (int vdd,bool low_bits) +{ +const int max_bit =ilog2 (MMC_VDD_35_36 ); +int bit; + +if (vdd <1650 || vdd >3600 ) +return -EINVAL ; + +if (vdd >=1650 && vdd <=1950 ) +return ilog2 (MMC_VDD_165_195 ); + +if (low_bits) + vdd -=1 ; + +/* Base 2000 mV, step 100 mV, bit's base 8. */ + bit = (vdd -2000 ) /100 +8 ; +if (bit > max_bit) +return max_bit; +return bit; +} + +/** +* mmc_vddrange_to_ocrmask - Convert a voltage range to the OCR mask +* @vdd_min: minimum voltage value (mV) +* @vdd_max: maximum voltage value (mV) +* +* This function returns the OCR mask bits according to the provided @vdd_min +* and @vdd_max values. If conversion is not possible the function returns 0. +* +* Notes wrt boundary cases: +* This function sets the OCR bits for all boundary voltages, for example +* [3300:3400] range is translated to MMC_VDD_32_33 | MMC_VDD_33_34 | +* MMC_VDD_34_35 mask. +*/ +u32 mmc_vddrange_to_ocrmask (int vdd_min,int vdd_max) +{ +u32 mask =0 ; + +if (vdd_max < vdd_min) +return 0 ; + +/* Prefer high bits for the boundary vdd_max values. */ + vdd_max =mmc_vdd_to_ocrbitnum (vdd_max, false); +if (vdd_max <0 ) +return 0 ; + +/* Prefer low bits for the boundary vdd_min values. */ + vdd_min =mmc_vdd_to_ocrbitnum (vdd_min, true); +if (vdd_min <0 ) +return 0 ; + +/* Fill the mask, from max bit to min bit. */ +while (vdd_max >= vdd_min) + mask |=1 << vdd_max--; + +return mask; +} +EXPORT_SYMBOL (mmc_vddrange_to_ocrmask); +/* * Mask off any voltages we don't support and select * the lowest voltage
include/linux/mmc/core.h +2 -0
@@ -151,4 +151,6 @@ static inline void mmc_claim_host(struct mmc_host *host) __mmc_claim_host(host, NULL); } +extern u32 mmc_vddrange_to_ocrmask (int vdd_min,int vdd_max); +#endif
Signature · 1 line
1.5.6.5
Re: [PATCH v2] mmc: Add mmc_vddrange_to_ocrmask() helper function
Quoted 10 lines · On Wed, 26 Nov 2008 22:54:17 +0300 Anton Vorontsov <[email protected]>…
This function sets the OCR mask bits according to provided voltage ranges. Will be used by the
mmc_spiOpenFirmware bindings.Signed-off-by Anton Vorontsov <[email protected]>---
Hi Pierre,
Sorry for the delay.
This looks perfect. Just tell me when you want me to queue it up.
Rgds
Signature · 9 lines
-- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org rdesktop, core developer http://www.rdesktop.org WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption.
Re: [PATCH v2] mmc: Add mmc_vddrange_to_ocrmask() helper function
Quoted 9 lines · Pierre Ossman
Quoted 6 lines · On Wed, 26 Nov 2008 22:54:17 +0300 Anton Vorontsov <[email protected]>…
This function sets the OCR mask bits according to provided voltage ranges. Will be used by the
mmc_spiOpenFirmware bindings.Signed-off-by Anton Vorontsov <[email protected]>---
Quoted 6 lines
Quoted 4 lines
Hi Pierre,
Sorry for the delay.
This looks perfect. Just tell me when you want me to queue it up.
I plan resend the series (OF MMC SPI) some time between 2.6.28-rc0 and -rc1, that is, when all needed powerpc patches will be merged into the Linus' tree.
Though, the $subject patch could be merged anytime as it doesn't depend on anything else. So, if you'll merge it earlier, that will make things a bit easier: -1 patch to resend. ;-)
Thanks,
Signature · 3 lines
Anton Vorontsov email: [email protected] irc://irc.freenode.net/bd2
Re: [PATCH v2] mmc: Add mmc_vddrange_to_ocrmask() helper function
Quoted 5 lines · On Mon, 1 Dec 2008 14:53:20 +0300 Anton Vorontsov <[email protected]>…
Though, the $subject patch could be merged anytime as it doesn't depend on anything else. So, if you'll merge it earlier, that will make things a bit easier: -1 patch to resend. ;-)
Queued up. Will be sent once the merge window opens up.
Rgds
Signature · 9 lines
-- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org rdesktop, core developer http://www.rdesktop.org WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption.
PATCH 3/3 mmc_spi: Add support for OpenFirmware bindings
In reply to Anton VorontsovThe support is implemented via platform data accessors, new module (of_mmc_spi) will be created automatically when the driver compiles on OpenFirmware platforms. Link-time dependency will load the module automatically.
--- drivers/mmc/host/Makefile | 3 + drivers/mmc/host/mmc_spi.c | 4 +- drivers/mmc/host/of_mmc_spi.c | 147 +++++++++++++++++++++++++++++++++++++++++ include/linux/spi/mmc_spi.h | 8 ++ 4 files changed, 161 insertions(+), 1 deletions(-) create mode 100644 drivers/mmc/host/of_mmc_spi.c
drivers/mmc/host/Makefile +3 -0
@@ -19,6 +19,9 @@ obj-$(CONFIG_MMC_AT91) += at91_mci.o obj-$(CONFIG_MMC_ATMELMCI) += atmel-mci.o obj-$(CONFIG_MMC_TIFM_SD) += tifm_sd.o obj-$(CONFIG_MMC_SPI) += mmc_spi.o +ifeq ($(CONFIG_OF),y) +obj-$(CONFIG_MMC_SPI) += of_mmc_spi.o +endif obj-$(CONFIG_MMC_S3C) += s3cmci.o obj-$(CONFIG_MMC_SDRICOH_CS) += sdricoh_cs.o obj-$(CONFIG_MMC_TMIO) += tmio_mmc.o
drivers/mmc/host/mmc_spi.c +3 -1
@@ -1285,7 +1285,7 @@ static int mmc_spi_probe(struct spi_device *spi)/* Platform data is used to hook up things like card sensing * and power switching gpios. */ - host->pdata = spi->dev.platform_data; + host->pdata =mmc_spi_get_pdata (spi);if (host->pdata) mmc->ocr_avail = host->pdata->ocr_mask;if (!mmc->ocr_avail) {
@@ -1368,6 +1368,7 @@ fail_glue_init: fail_nobuf1:mmc_free_host (mmc); +mmc_spi_put_pdata (spi);dev_set_drvdata (&spi->dev,NULL ); nomem:
@@ -1402,6 +1403,7 @@ static int __devexit mmc_spi_remove(struct spi_device *spi) spi->max_speed_hz = mmc->f_max;mmc_free_host (mmc); +mmc_spi_put_pdata (spi);dev_set_drvdata (&spi->dev,NULL ); }return 0 ;
drivers/mmc/host/of_mmc_spi.c new file +147 -0
147 lines not on this page · raw message
include/linux/spi/mmc_spi.h +8 -0
@@ -41,4 +41,12 @@ struct mmc_spi_platform_data { void (*setpower)(struct device *, unsigned int maskval); }; +#ifdef CONFIG_OF +extern struct mmc_spi_platform_data *mmc_spi_get_pdata (struct spi_device *spi); +extern void mmc_spi_put_pdata (struct spi_device *spi); +#else +#define mmc_spi_get_pdata (spi) ((spi)->dev.platform_data) +#define mmc_spi_put_pdata (spi) +#endif /* CONFIG_OF */ +#endif /* __LINUX_SPI_MMC_SPI_H */
Signature · 1 line
1.5.6.3
Quoted 9 lines · On Thu, 30 Oct 2008 22:55:46 +0300 Anton Vorontsov <[email protected]>…
Pierre, the approach is somewhat similar to this one:
http://lkml.org/lkml/2008/5/26/135
Posted few months ago.I know you don't like it, but I ask you to reconsider it. The I2C and SPI cases are similar, and recently we tried to write bindings for some I2C GPIO controllers.
This new version is a bit better in that you've generalised thing more. I'd still prefer if we can have an interface where the driver doesn't have to know that it is on an ACPI/OF/EFI/whatnot host, but I can live with this model for now.
Rgds
Signature · 9 lines
-- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org rdesktop, core developer http://www.rdesktop.org WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses encryption for SMTP traffic and consider using PGP for end-to-end encryption.