Il est temps de reduire vos impots!
-- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v3] mmc_spi.c: add support for the regulator framework
On Wed, May 11, 2011 at 10:53:37PM +0200, Antonio Ospite wrote:
> OK, avoiding some duplication will be good, I agree.
> I am resending a v4 with the equivalent code:
>
> if (host->vcc) {
> int ret;
>
> if (power_mode == MMC_POWER_OFF)
> vdd = 0;
>
This isn't really what I meant - what I meant was that all this logic
looks like it's generic to multiple drivers. We either set a regulator
or call a pdata callback to set power, both of which are completely
external to the controller.
--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 2/2] spi: spi_tegra: calling spi_unregister_master instead of spi_master_put in spi_tegra_remove
spi_master_put() should only be used in error handling. Once spi_register_master() returns success, we should call spi_unregister_master() instead. Signed-off-by: Axel Lin --- drivers/spi/spi_tegra.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/spi/spi_tegra.c b/drivers/spi/spi_tegra.c index 891e590..6c3aa6e 100644 --- a/drivers/spi/spi_tegra.c +++ b/drivers/spi/spi_tegra.c @@ -578,6 +578,7 @@ static int __devexit spi_tegra_remove(struct platform_device *pdev) master = dev_get_drvdata(&pdev->dev); tspi = spi_master_get_devdata(master); + spi_unregister_master(master); tegra_dma_free_channel(tspi->rx_dma); dma_free_coherent(&pdev->dev, sizeof(u32) * BB_LEN, @@ -586,7 +587,6 @@ static int __devexit spi_tegra_remove(struct platform_device *pdev) clk_put(tspi->clk); iounmap(tspi->base); - spi_master_put(master); r = platform_get_resource(pdev, IORESOURCE_MEM, 0); release_mem_region(r->start, (r->end - r->start) + 1); -- 1.7.1 -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 1/2] spi: spi_sh: calling spi_unregister_master instead of spi_master_put in spi_sh_remove
spi_master_put() should only be used in error handling.
Once spi_register_master() returns success, we should call
spi_unregister_master() instead.
Signed-off-by: Axel Lin
---
drivers/spi/spi_sh.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/spi_sh.c b/drivers/spi/spi_sh.c
index 869a07d..9eedd71 100644
--- a/drivers/spi/spi_sh.c
+++ b/drivers/spi/spi_sh.c
@@ -427,10 +427,10 @@ static int __devexit spi_sh_remove(struct platform_device
*pdev)
{
struct spi_sh_data *ss = dev_get_drvdata(&pdev->dev);
+ spi_unregister_master(ss->master);
destroy_workqueue(ss->workqueue);
free_irq(ss->irq, ss);
iounmap(ss->addr);
- spi_master_put(ss->master);
return 0;
}
--
1.7.1
--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v3] mmc_spi.c: add support for the regulator framework
On Wed, May 11, 2011 at 12:39:39PM +0200, Antonio Ospite wrote:
> Add support for powering up SD cards driven by regulators.
> This makes the mmc_spi driver work also with the Motorola A910 phone.
>
> Signed-off-by: Antonio Ospite
Reviwed-by: Mark Brown
but
> + switch (power_mode) {
> + case MMC_POWER_OFF:
> + if (host->vcc) {
> + int ret = mmc_regulator_set_ocr(host->mmc,
> + host->vcc, 0);
> + if (ret)
> + return ret;
> + } else {
> + host->pdata->setpower(&host->spi->dev, vdd);
> + }
> + break;
> +
> + case MMC_POWER_UP:
> + if (host->vcc) {
> + int ret = mmc_regulator_set_ocr(host->mmc,
> + host->vcc, vdd);
> + if (ret)
> + return ret;
> + } else {
> host->pdata->setpower(&host->spi->dev, vdd);
> - if (power_mode == MMC_POWER_UP)
> - msleep(host->powerup_msecs);
> }
> + msleep(host->powerup_msecs);
> + break;
This stuff all looks like it should be factored out.
--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH] spi: tle620x: add missing device_remove_file()
This patch includes below fixes: 1. Add missing device_remove_file for dev_attr_status_show in tle62x0_remove. 2. Fix tle62x0_probe error handling: Currently, if the error happens when ptr > 0, gpio_attrs[0] is not properly remove. Signed-off-by: Axel Lin --- drivers/spi/tle62x0.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/spi/tle62x0.c b/drivers/spi/tle62x0.c index a393895..32a4087 100644 --- a/drivers/spi/tle62x0.c +++ b/drivers/spi/tle62x0.c @@ -283,7 +283,7 @@ static int __devinit tle62x0_probe(struct spi_device *spi) return 0; err_gpios: - for (; ptr > 0; ptr--) + while (--ptr >= 0) device_remove_file(&spi->dev, gpio_attrs[ptr]); device_remove_file(&spi->dev, &dev_attr_status_show); @@ -301,6 +301,7 @@ static int __devexit tle62x0_remove(struct spi_device *spi) for (ptr = 0; ptr < st->nr_gpio; ptr++) device_remove_file(&spi->dev, gpio_attrs[ptr]); + device_remove_file(&spi->dev, &dev_attr_status_show); kfree(st); return 0; } -- 1.7.1 -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH v3] mmc_spi.c: add support for the regulator framework
Add support for powering up SD cards driven by regulators.
This makes the mmc_spi driver work also with the Motorola A910 phone.
Signed-off-by: Antonio Ospite
---
Changes since v2:
- Use IS_ERR_OR_NULL() to correctly handle the stub regulator_get()
Changes since v1:
- Remove the ifdef CONFIG_REGULATOR as regulator_get() degenerates to
a stub as well when the regulator framework is disabled.
- Release the regulator in mmc_spi_remove()
Chris if this one turns to be OK you could pick up patches 1-3 from previous
messages and patch 4 v3 from this one. Let me know if you want me to resend the
whole series instead.
Thanks,
Antonio
drivers/mmc/host/mmc_spi.c | 63 +++
1 files changed, 51 insertions(+), 12 deletions(-)
diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
index 0f3672d..70dd603 100644
--- a/drivers/mmc/host/mmc_spi.c
+++ b/drivers/mmc/host/mmc_spi.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -150,11 +151,13 @@ struct mmc_spi_host {
*/
void*ones;
dma_addr_t ones_dma;
+
+ struct regulator*vcc;
};
static inline int mmc_spi_canpower(struct mmc_spi_host *host)
{
- return host->pdata && host->pdata->setpower;
+ return (host->pdata && host->pdata->setpower) || host->vcc;
}
//
@@ -1225,17 +1228,35 @@ static inline int mmc_spi_setpower(struct mmc_spi_host
*host,
unsigned char power_mode,
unsigned int vdd)
{
+ if (!mmc_spi_canpower(host))
+ return -ENOSYS;
+
/* switch power on/off if possible, accounting for
* max 250msec powerup time if needed.
*/
- if (mmc_spi_canpower(host)) {
- switch (power_mode) {
- case MMC_POWER_OFF:
- case MMC_POWER_UP:
+ switch (power_mode) {
+ case MMC_POWER_OFF:
+ if (host->vcc) {
+ int ret = mmc_regulator_set_ocr(host->mmc,
+ host->vcc, 0);
+ if (ret)
+ return ret;
+ } else {
+ host->pdata->setpower(&host->spi->dev, vdd);
+ }
+ break;
+
+ case MMC_POWER_UP:
+ if (host->vcc) {
+ int ret = mmc_regulator_set_ocr(host->mmc,
+ host->vcc, vdd);
+ if (ret)
+ return ret;
+ } else {
host->pdata->setpower(&host->spi->dev, vdd);
- if (power_mode == MMC_POWER_UP)
- msleep(host->powerup_msecs);
}
+ msleep(host->powerup_msecs);
+ break;
}
return 0;
@@ -1420,12 +1441,27 @@ static int mmc_spi_probe(struct spi_device *spi)
* and power switching gpios.
*/
host->pdata = mmc_spi_get_pdata(spi);
- if (host->pdata)
- mmc->ocr_avail = host->pdata->ocr_mask;
- if (!mmc->ocr_avail) {
- dev_warn(&spi->dev, "ASSUMING 3.2-3.4 V slot power\n");
- mmc->ocr_avail = MMC_VDD_32_33|MMC_VDD_33_34;
+
+ host->vcc = regulator_get(mmc_dev(host->mmc), "vmmc");
+ if (IS_ERR_OR_NULL(host->vcc)) {
+ host->vcc = NULL;
+ } else {
+ host->mmc->ocr_avail = mmc_regulator_get_ocrmask(host->vcc);
+ if (host->pdata && host->pdata->ocr_mask)
+ dev_warn(mmc_dev(host->mmc),
+ "ocr_mask/setpower will not be used\n");
}
+
+ if (host->vcc == NULL) {
+ /* fall-back to platform data */
+ if (host->pdata)
+ mmc->ocr_avail = host->pdata->ocr_mask;
+ if (!mmc->ocr_avail) {
+ dev_warn(&spi->dev, "ASSUMING 3.2-3.4 V slot power\n");
+ mmc->ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
+ }
+ }
+
if (mmc_spi_canpower(host)) {
host->powerup_msecs = host->pdata->powerup_msecs;
if (!host->powerup_msecs || host->powerup_msecs > 250)
@@ -1523,6 +1559,9 @@ static int __devexit mmc_spi_remove(struct spi_device
*spi)
if (host->pdata && host->pdata->exit)
host->pdata->exit(&spi->dev, mmc);
+ if (host->vcc)
+ regulator_put(host->vcc);
+
mmc_remove_host(mmc);
if (host->dma_dev) {
--
1.7.5.1
--
Achieve unprecedented app performanc
[SPAM] 你好：税/票――代/开
您好： 我公司有一部分专用税――票/代开； 如: (1)普通商品销售税――票； (2)广告业、各类服务业税――票/等等。 贵公司如有需要，欢迎您的来电与我联系： 负责人：张先生(0)1353804 -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [QUERY] Behavior of spi slave memories w.r.t chip select signal.
On Wed, May 11, 2011 at 09:37:19AM +0530, viresh kumar wrote: > Following is what i understood after reading m25p80 driver and spi > master drivers in drivers/spi folder. > > "chip_select signal controls start and end of transfer. For ex: if we have to > read > status reg of spi memory, then we use write_and_then_read() routine. which > writes > 0x9F in one spi transfer and writes dummy bytes and reads rx reg in other > transfer. > And these two transfers are part of single spi_message. > > Now, it is controllable to handle cs, and if we send cs_change == 0, then > chip select > is activated at start of message and deactivated at end of message, instead > at end > of every transfer. > > Which means, even if there is a delay between command and dummy bytes > received at > spi memory, current transfer will not be terminated by memory as cs is low." > > Is this correct?? > > Actually i am seeing a different behavior by some of the spi memories, like > m25p10. > If there is a delay between read_sts_reg command and dummy bytes, then > 0xFF is > returned in response. If there is no delay then transfer always passes. What SPI controller are you using? I've seen a similar issue with the Synopsys DesignWare SPI controller where the controller manages the chip select itself, and once the FIFO is emptied the CS goes away, but the flash chip requires it to stay high for the whole transaction. In this case the workaround is to use a GPIO as a chip select and there are other controllers that do the same thing for the same reason (I think that pxa2xx_spi is one of them). Jamie -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [QUERY] Behavior of spi slave memories w.r.t chip select signal.
On 05/11/2011 12:47 PM, Jamie Iles wrote: > What SPI controller are you using? I've seen a similar issue with the > Synopsys DesignWare SPI controller where the controller manages the chip > select itself, and once the FIFO is emptied the CS goes away, but the > flash chip requires it to stay high for the whole transaction. In this > case the workaround is to use a GPIO as a chip select and there are > other controllers that do the same thing for the same reason (I think > that pxa2xx_spi is one of them). I am using amba pl022 controller and using external gpio's to control chip select signal. cs is kept low for entire message, but still i am facing this issue. -- viresh -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
