Re: [PATCH 1/2] atmel/spi: fix missing probe
On 11/03/2011 06:41 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> Commit 940ab889 "drivercore: Add helper macro for platform_driver boilerplate"
> converted this driver to use module_platform_driver, but due to the use
> of platform_driver_probe(), this resulted in the call to atmel_spi_probe being
> lost. Place the call to this function into the driver structure.
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
> Cc: Greg Kroah-Hartman
> Cc: Grant Likely
> Cc: Russell King - ARM Linux
> ---
> v3:
>
> update commit message
> drivers/spi/spi-atmel.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
> index 79665e2..3cd4f49 100644
> --- a/drivers/spi/spi-atmel.c
> +++ b/drivers/spi/spi-atmel.c
> @@ -1072,6 +1072,7 @@ static struct platform_driver atmel_spi_driver = {
> },
> .suspend= atmel_spi_suspend,
> .resume = atmel_spi_resume,
> + .prove = atmel_spi_probe,
^
This is certainly a typo. Didn't you even compile-test this?
Daniel
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
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-gpio: Add DT bindings
This patch adds DT bindings to the spi-gpio driver and some
documentation about how to use it.
Signed-off-by: Daniel Mack
---
Documentation/devicetree/bindings/spi/spi-gpio.txt | 29 ++
drivers/spi/spi-gpio.c | 99 +++-
2 files changed, 125 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/spi-gpio.txt
diff --git a/Documentation/devicetree/bindings/spi/spi-gpio.txt
b/Documentation/devicetree/bindings/spi/spi-gpio.txt
new file mode 100644
index 000..8a824be
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-gpio.txt
@@ -0,0 +1,29 @@
+SPI-GPIO devicetree bindings
+
+Required properties:
+
+ - compatible: should be set to "spi-gpio"
+ - #address-cells: should be set to <0x1>
+ - ranges
+ - gpio-sck: GPIO spec for the SCK line to use
+ - gpio-miso: GPIO spec for the MISO line to use
+ - gpio-mosi: GPIO spec for the MOSI line to use
+ - cs-gpios: GPIOs to use for chipselect lines
+ - num-chipselects: number of chipselect lines
+
+Example:
+
+ spi {
+ compatible = "spi-gpio";
+ #address-cells = <0x1>;
+ ranges;
+
+ gpio-sck = <&gpio 95 0>;
+ gpio-miso = <&gpio 98 0>;
+ gpio-mosi = <&gpio 97 0>;
+ cs-gpios = <&gpio 125 0>;
+ num-chipselects = <1>;
+
+ /* clients */
+ };
+
diff --git a/drivers/spi/spi-gpio.c b/drivers/spi/spi-gpio.c
index e79e311..c57a267 100644
--- a/drivers/spi/spi-gpio.c
+++ b/drivers/spi/spi-gpio.c
@@ -22,6 +22,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -232,13 +234,27 @@ static void spi_gpio_chipselect(struct spi_device *spi,
int is_active)
static int spi_gpio_setup(struct spi_device *spi)
{
- unsigned intcs = (unsigned int) spi->controller_data;
+ unsigned intcs;
int status = 0;
struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
+ struct device_node *np = spi->master->dev.of_node;
if (spi->bits_per_word > 32)
return -EINVAL;
+ if (np) {
+ /*
+* In DT environments, the CS GPIOs have already been
+* initialized from the "cs-gpios" property of the node.
+*/
+ cs = spi_gpio->cs_gpios[spi->chip_select];
+ } else {
+ /*
+* ... otherwise, take it from spi->controller_data
+*/
+ cs = (unsigned int) spi->controller_data;
+ }
+
if (!spi->controller_state) {
if (cs != SPI_GPIO_NO_CHIPSELECT) {
status = gpio_request(cs, dev_name(&spi->dev));
@@ -249,6 +265,7 @@ static int spi_gpio_setup(struct spi_device *spi)
}
if (!status) {
status = spi_bitbang_setup(spi);
+ /* in case it was initialized from static board data */
spi_gpio->cs_gpios[spi->chip_select] = cs;
}
@@ -325,6 +342,55 @@ done:
return value;
}
+#ifdef CONFIG_OF
+static struct of_device_id spi_gpio_dt_ids[] = {
+ { .compatible = "spi-gpio" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, spi_gpio_dt_ids);
+
+static int spi_gpio_probe_dt(struct platform_device *pdev)
+{
+ int ret;
+ u32 tmp;
+ struct spi_gpio_platform_data *pdata;
+ struct device_node *np = pdev->dev.of_node;
+ const struct of_device_id *of_id =
+ of_match_device(spi_gpio_dt_ids, &pdev->dev);
+
+ if (!of_id)
+ return 0;
+
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ pdata->sck = of_get_named_gpio(np, "gpio-sck", 0);
+ pdata->miso = of_get_named_gpio(np, "gpio-miso", 0);
+ pdata->mosi = of_get_named_gpio(np, "gpio-mosi", 0);
+
+ ret = of_property_read_u32(np, "num-chipselects", &tmp);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "num-chipselects property not found\n");
+ goto error_free;
+ }
+
+ pdata->num_chipselect = tmp;
+ pdev->dev.platform_data = pdata;
+
+ return 1;
+
+error_free:
+ devm_kfree(&pdev->dev, pdata);
+ return ret;
+}
+#else
+static inline int spi_probe_dt(struct platform_device *)
+{
+ return 0;
+}
+#endif
+
static int __devinit spi_gpio_probe(struct platform_device *pdev)
{
int status;
@@ -332,6 +398,13 @@ static int __devinit spi_gpio_probe(struct platform_device
*pdev)
struct spi_gpio *spi_gpio;
struct spi_gpio_p
[PATCH 1/2] SPI: spi-gpio: store chipselect information in private structure
The spi-gpio driver currently assumes the chipselect gpio number is
stored in ->controller_data of the device's static board information.
In devicetree environments, this information is unavailable and has to
be derived from the DT node.
This patch moves the gpio storage to the controller's private data so
the DT bindings can easily build upon the driver.
Signed-off-by: Daniel Mack
---
drivers/spi/spi-gpio.c | 34 --
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/drivers/spi/spi-gpio.c b/drivers/spi/spi-gpio.c
index 0094c64..e79e311 100644
--- a/drivers/spi/spi-gpio.c
+++ b/drivers/spi/spi-gpio.c
@@ -46,6 +46,7 @@ struct spi_gpio {
struct spi_bitbang bitbang;
struct spi_gpio_platform_data pdata;
struct platform_device *pdev;
+ int cs_gpios[0];
};
/*--*/
@@ -89,15 +90,21 @@ struct spi_gpio {
/*--*/
-static inline const struct spi_gpio_platform_data * __pure
-spi_to_pdata(const struct spi_device *spi)
+static inline struct spi_gpio * __pure
+spi_to_spi_gpio(const struct spi_device *spi)
{
const struct spi_bitbang*bang;
- const struct spi_gpio *spi_gpio;
+ struct spi_gpio *spi_gpio;
bang = spi_master_get_devdata(spi->master);
spi_gpio = container_of(bang, struct spi_gpio, bitbang);
- return &spi_gpio->pdata;
+ return spi_gpio;
+}
+
+static inline struct spi_gpio_platform_data * __pure
+spi_to_pdata(const struct spi_device *spi)
+{
+ return &spi_to_spi_gpio(spi)->pdata;
}
/* this is #defined to avoid unused-variable warnings when inlining */
@@ -210,7 +217,8 @@ static u32 spi_gpio_spec_txrx_word_mode3(struct spi_device
*spi,
static void spi_gpio_chipselect(struct spi_device *spi, int is_active)
{
- unsigned long cs = (unsigned long) spi->controller_data;
+ struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
+ unsigned int cs = spi_gpio->cs_gpios[spi->chip_select];
/* set initial clock polarity */
if (is_active)
@@ -224,8 +232,9 @@ static void spi_gpio_chipselect(struct spi_device *spi, int
is_active)
static int spi_gpio_setup(struct spi_device *spi)
{
- unsigned long cs = (unsigned long) spi->controller_data;
- int status = 0;
+ unsigned intcs = (unsigned int) spi->controller_data;
+ int status = 0;
+ struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
if (spi->bits_per_word > 32)
return -EINVAL;
@@ -238,8 +247,11 @@ static int spi_gpio_setup(struct spi_device *spi)
status = gpio_direction_output(cs, spi->mode &
SPI_CS_HIGH);
}
}
- if (!status)
+ if (!status) {
status = spi_bitbang_setup(spi);
+ spi_gpio->cs_gpios[spi->chip_select] = cs;
+ }
+
if (status) {
if (!spi->controller_state && cs != SPI_GPIO_NO_CHIPSELECT)
gpio_free(cs);
@@ -249,7 +261,8 @@ static int spi_gpio_setup(struct spi_device *spi)
static void spi_gpio_cleanup(struct spi_device *spi)
{
- unsigned long cs = (unsigned long) spi->controller_data;
+ struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
+ unsigned int cs = spi_gpio->cs_gpios[spi->chip_select];
if (cs != SPI_GPIO_NO_CHIPSELECT)
gpio_free(cs);
@@ -330,7 +343,8 @@ static int __devinit spi_gpio_probe(struct platform_device
*pdev)
if (status < 0)
return status;
- master = spi_alloc_master(&pdev->dev, sizeof *spi_gpio);
+ master = spi_alloc_master(&pdev->dev, sizeof(*spi_gpio) +
+ (sizeof(int) * SPI_N_CHIPSEL));
if (!master) {
status = -ENOMEM;
goto gpio_free;
--
1.7.10.4
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 2/2] SPI: spi-gpio: Add DT bindings
On 25.07.2012 14:11, Wolfram Sang wrote:
> On Wed, Jul 25, 2012 at 01:44:12PM +0200, Daniel Mack wrote:
>> This patch adds DT bindings to the spi-gpio driver and some
>> documentation about how to use it.
>>
>> Signed-off-by: Daniel Mack
>> ---
>> Documentation/devicetree/bindings/spi/spi-gpio.txt | 29 ++
>> drivers/spi/spi-gpio.c | 99
>> +++-
>> 2 files changed, 125 insertions(+), 3 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/spi/spi-gpio.txt
>>
>> diff --git a/Documentation/devicetree/bindings/spi/spi-gpio.txt
>> b/Documentation/devicetree/bindings/spi/spi-gpio.txt
>> new file mode 100644
>> index 000..8a824be
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/spi/spi-gpio.txt
>> @@ -0,0 +1,29 @@
>> +SPI-GPIO devicetree bindings
>> +
>> +Required properties:
>> +
>> + - compatible: should be set to "spi-gpio"
>> + - #address-cells: should be set to <0x1>
>> + - ranges
>> + - gpio-sck: GPIO spec for the SCK line to use
>> + - gpio-miso: GPIO spec for the MISO line to use
>> + - gpio-mosi: GPIO spec for the MOSI line to use
>> + - cs-gpios: GPIOs to use for chipselect lines
>> + - num-chipselects: number of chipselect lines
>> +
>> +Example:
>> +
>> +spi {
>> +compatible = "spi-gpio";
>> +#address-cells = <0x1>;
>> +ranges;
>> +
>> +gpio-sck = <&gpio 95 0>;
>> +gpio-miso = <&gpio 98 0>;
>> +gpio-mosi = <&gpio 97 0>;
>> +cs-gpios = <&gpio 125 0>;
>> +num-chipselects = <1>;
>
> Can't we use of_gpio_named_count() instead of this property?
I thought so too, but it's probably also a good idea to keep this driver
in line to what other drivers do, no? Anyway, I can of course change it
if desired.
>> +
>> +/* clients */
>
> Minor: A simple example is helpful for people new to devicetree as I
> experienced in the last days.
Hmm, aren't there enough examples in a) the full dts files in the kernel
and b) in the documenation of spi clients?
Thanks,
Daniel
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 2/2] SPI: spi-gpio: Add DT bindings
On 25.07.2012 14:32, Wolfram Sang wrote:
>
+Example:
+
+ spi {
+ compatible = "spi-gpio";
+ #address-cells = <0x1>;
+ ranges;
+
+ gpio-sck = <&gpio 95 0>;
+ gpio-miso = <&gpio 98 0>;
+ gpio-mosi = <&gpio 97 0>;
+ cs-gpios = <&gpio 125 0>;
+ num-chipselects = <1>;
>>>
>>> Can't we use of_gpio_named_count() instead of this property?
>>
>> I thought so too, but it's probably also a good idea to keep this driver
>> in line to what other drivers do, no?
>
> I'd prefer to drop it unless there is a real need for it. CCing Shawn to
> ask why "fsl,spi-num-chipselects" was added to the spi-imx driver
> instead of using of_gpio_{named_}count(). Was there a reason?
>
+
+ /* clients */
>>>
>>> Minor: A simple example is helpful for people new to devicetree as I
>>> experienced in the last days.
>>
>> Hmm, aren't there enough examples in a) the full dts files in the kernel
>> and b) in the documenation of spi clients?
>
> Many, yes; enough, don't know :) I just experienced that people
> missed this information in some of the i2c host controller binding
> descriptions, despite it was available elsewhere.
I would rather say specific examples in the documenation for generic bus
drivers cause more confusion than they clear :)
Daniel
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 1/2] SPI: spi-gpio: store chipselect information in private structure
On 25.07.2012 21:33, Mark Brown wrote: > On Wed, Jul 25, 2012 at 01:44:11PM +0200, Daniel Mack wrote: >> The spi-gpio driver currently assumes the chipselect gpio number is >> stored in ->controller_data of the device's static board information. > > Always CC maintainers on things... you've not CCed Grant or Linus W, > and for now I'm handling SPI patches (though I'm not in MAINTAINERS so > missing me is less surprising). I *did* Cc: Grant and all other people that get_maintainer.pl listed. For some reason, Grant was dropped from the list on Wolfram's reply, and I just did't see that. $ scripts/get_maintainer.pl -f drivers/spi/spi-gpio.c (0) [21:35:24] Grant Likely (maintainer:SPI SUBSYSTEM) Rob Herring (maintainer:OPEN FIRMWARE AND...) spi-devel-general@lists.sourceforge.net (open list:SPI SUBSYSTEM) linux-ker...@vger.kernel.org (open list) devicetree-disc...@lists.ozlabs.org (moderated list:OPEN FIRMWARE AND...) And I didn't know about you being in charge for SPI (saw that only today when you sent your pull request to lkml). So, sorry. Anyway - let's rather discuss about the patchset :) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 1/2] SPI: spi-gpio: store chipselect information in private structure
On 25.07.2012 21:52, Mark Brown wrote: > On Wed, Jul 25, 2012 at 09:38:58PM +0200, Daniel Mack wrote: >> On 25.07.2012 21:33, Mark Brown wrote: > >>> Always CC maintainers on things... you've not CCed Grant or Linus W, >>> and for now I'm handling SPI patches (though I'm not in MAINTAINERS so >>> missing me is less surprising). > >> I *did* Cc: Grant and all other people that get_maintainer.pl listed. >> For some reason, Grant was dropped from the list on Wolfram's reply, and >> I just did't see that. > > Grant's not in the CCs for the message I replied to which was one of > your patches. I don't know what's wrong here, but clearly, the message in my inbox has To: spi-devel-general@lists.sourceforge.net Cc: grant.lik...@secretlab.ca, rob.herr...@calxeda.com, devicetree-disc...@lists.ozlabs.org, Daniel Mack And I sent them off with git "send-email --to spi-devel-general@lists.sourceforge.net --cc grant.lik...@secretlab.ca ..." Sorry if that's my mistake, I just don't see it. >> Anyway - let's rather discuss about the patchset :) > > Part of the reason I'm being grumpy is I'm not likely to look at it > right now and my workflow is heavily based on things hitting my inbox > (I use a totally different account for generic list mail I'm not CCed on > and it's annoying to move stuff from one to the other). Ok, no hurries. I'm aware that it was a bad time to publish the patches just after the merge window opened. I'll ping you next week. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 1/2] SPI: spi-gpio: store chipselect information in private structure
On 25.07.2012 22:12, Mark Brown wrote: > On Wed, Jul 25, 2012 at 10:00:18PM +0200, Daniel Mack wrote: > >> I don't know what's wrong here, but clearly, the message in my inbox has > >> To: spi-devel-general@lists.sourceforge.net >> Cc: grant.lik...@secretlab.ca, >> rob.herr...@calxeda.com, >> devicetree-disc...@lists.ozlabs.org, >> Daniel Mack > >> And I sent them off with git "send-email --to >> spi-devel-general@lists.sourceforge.net --cc grant.lik...@secretlab.ca ..." > >> Sorry if that's my mistake, I just don't see it. > > I forwarded <1343216652-1463-1-git-send-email-zon...@gmail.com> to you > under separate cover. > Yes, you're right - I also saw that on the devicetree-discuss archives. Still, I can't see the reason. My MTA's log states: Jul 25 13:44:18 rambrand postfix/smtp[17884]: 84613C0081: to=, relay=127.0.0.1[127.0.0.1]:10024, delay=0.7, delays=0.35/0/0.01/0.34, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as ED410C029D) Jul 25 13:44:19 rambrand postfix/smtp[17898]: ED410C029D: to=, relay=aspmx.l.google.com[173.194.78.26]:25, delay=1.3, delays=0.06/0.19/0.5/0.57, dsn=2.0.0, status=sent (250 2.0.0 OK 1343216659 e19si24125620wec.111) (Each queue ID matches one of the two original patches' Message-ID) As you appearantly received the mail via spi-devel-general, is it possible that that list dropped it? Must be. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 1/2] SPI: spi-gpio: store chipselect information in private structure
Mark,
could you have another look at these patches maybe? They aren't urgent,
I just want to avoid the get lost.
Thanks for your time,
Daniel
On 25.07.2012 13:44, Daniel Mack wrote:
> The spi-gpio driver currently assumes the chipselect gpio number is
> stored in ->controller_data of the device's static board information.
>
> In devicetree environments, this information is unavailable and has to
> be derived from the DT node.
>
> This patch moves the gpio storage to the controller's private data so
> the DT bindings can easily build upon the driver.
>
> Signed-off-by: Daniel Mack
> ---
> drivers/spi/spi-gpio.c | 34 --
> 1 file changed, 24 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/spi/spi-gpio.c b/drivers/spi/spi-gpio.c
> index 0094c64..e79e311 100644
> --- a/drivers/spi/spi-gpio.c
> +++ b/drivers/spi/spi-gpio.c
> @@ -46,6 +46,7 @@ struct spi_gpio {
> struct spi_bitbang bitbang;
> struct spi_gpio_platform_data pdata;
> struct platform_device *pdev;
> + int cs_gpios[0];
> };
>
> /*--*/
> @@ -89,15 +90,21 @@ struct spi_gpio {
>
> /*--*/
>
> -static inline const struct spi_gpio_platform_data * __pure
> -spi_to_pdata(const struct spi_device *spi)
> +static inline struct spi_gpio * __pure
> +spi_to_spi_gpio(const struct spi_device *spi)
> {
> const struct spi_bitbang*bang;
> - const struct spi_gpio *spi_gpio;
> + struct spi_gpio *spi_gpio;
>
> bang = spi_master_get_devdata(spi->master);
> spi_gpio = container_of(bang, struct spi_gpio, bitbang);
> - return &spi_gpio->pdata;
> + return spi_gpio;
> +}
> +
> +static inline struct spi_gpio_platform_data * __pure
> +spi_to_pdata(const struct spi_device *spi)
> +{
> + return &spi_to_spi_gpio(spi)->pdata;
> }
>
> /* this is #defined to avoid unused-variable warnings when inlining */
> @@ -210,7 +217,8 @@ static u32 spi_gpio_spec_txrx_word_mode3(struct
> spi_device *spi,
>
> static void spi_gpio_chipselect(struct spi_device *spi, int is_active)
> {
> - unsigned long cs = (unsigned long) spi->controller_data;
> + struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
> + unsigned int cs = spi_gpio->cs_gpios[spi->chip_select];
>
> /* set initial clock polarity */
> if (is_active)
> @@ -224,8 +232,9 @@ static void spi_gpio_chipselect(struct spi_device *spi,
> int is_active)
>
> static int spi_gpio_setup(struct spi_device *spi)
> {
> - unsigned long cs = (unsigned long) spi->controller_data;
> - int status = 0;
> + unsigned intcs = (unsigned int) spi->controller_data;
> + int status = 0;
> + struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
>
> if (spi->bits_per_word > 32)
> return -EINVAL;
> @@ -238,8 +247,11 @@ static int spi_gpio_setup(struct spi_device *spi)
> status = gpio_direction_output(cs, spi->mode &
> SPI_CS_HIGH);
> }
> }
> - if (!status)
> + if (!status) {
> status = spi_bitbang_setup(spi);
> + spi_gpio->cs_gpios[spi->chip_select] = cs;
> + }
> +
> if (status) {
> if (!spi->controller_state && cs != SPI_GPIO_NO_CHIPSELECT)
> gpio_free(cs);
> @@ -249,7 +261,8 @@ static int spi_gpio_setup(struct spi_device *spi)
>
> static void spi_gpio_cleanup(struct spi_device *spi)
> {
> - unsigned long cs = (unsigned long) spi->controller_data;
> + struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
> + unsigned int cs = spi_gpio->cs_gpios[spi->chip_select];
>
> if (cs != SPI_GPIO_NO_CHIPSELECT)
> gpio_free(cs);
> @@ -330,7 +343,8 @@ static int __devinit spi_gpio_probe(struct
> platform_device *pdev)
> if (status < 0)
> return status;
>
> - master = spi_alloc_master(&pdev->dev, sizeof *spi_gpio);
> + master = spi_alloc_master(&pdev->dev, sizeof(*spi_gpio) +
> + (sizeof(int) * SPI_N_CHIPSEL));
> if (!master) {
> status = -ENOMEM;
> goto gpio_free;
>
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH resend 1/2] SPI: spi-gpio: store chipselect information in private structure
The spi-gpio driver currently assumes the chipselect gpio number is
stored in ->controller_data of the device's static board information.
In devicetree environments, this information is unavailable and has to
be derived from the DT node.
This patch moves the gpio storage to the controller's private data so
the DT bindings can easily build upon the driver.
Signed-off-by: Daniel Mack
Cc: Mark Brown
Cc: Grant Likely
Cc: Linus Walleij
---
drivers/spi/spi-gpio.c | 34 --
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/drivers/spi/spi-gpio.c b/drivers/spi/spi-gpio.c
index 0b56cfc..ff7263c 100644
--- a/drivers/spi/spi-gpio.c
+++ b/drivers/spi/spi-gpio.c
@@ -46,6 +46,7 @@ struct spi_gpio {
struct spi_bitbang bitbang;
struct spi_gpio_platform_data pdata;
struct platform_device *pdev;
+ int cs_gpios[0];
};
/*--*/
@@ -89,15 +90,21 @@ struct spi_gpio {
/*--*/
-static inline const struct spi_gpio_platform_data * __pure
-spi_to_pdata(const struct spi_device *spi)
+static inline struct spi_gpio * __pure
+spi_to_spi_gpio(const struct spi_device *spi)
{
const struct spi_bitbang*bang;
- const struct spi_gpio *spi_gpio;
+ struct spi_gpio *spi_gpio;
bang = spi_master_get_devdata(spi->master);
spi_gpio = container_of(bang, struct spi_gpio, bitbang);
- return &spi_gpio->pdata;
+ return spi_gpio;
+}
+
+static inline struct spi_gpio_platform_data * __pure
+spi_to_pdata(const struct spi_device *spi)
+{
+ return &spi_to_spi_gpio(spi)->pdata;
}
/* this is #defined to avoid unused-variable warnings when inlining */
@@ -210,7 +217,8 @@ static u32 spi_gpio_spec_txrx_word_mode3(struct spi_device
*spi,
static void spi_gpio_chipselect(struct spi_device *spi, int is_active)
{
- unsigned long cs = (unsigned long) spi->controller_data;
+ struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
+ unsigned int cs = spi_gpio->cs_gpios[spi->chip_select];
/* set initial clock polarity */
if (is_active)
@@ -224,8 +232,9 @@ static void spi_gpio_chipselect(struct spi_device *spi, int
is_active)
static int spi_gpio_setup(struct spi_device *spi)
{
- unsigned long cs = (unsigned long) spi->controller_data;
- int status = 0;
+ unsigned intcs = (unsigned int) spi->controller_data;
+ int status = 0;
+ struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
if (spi->bits_per_word > 32)
return -EINVAL;
@@ -239,8 +248,11 @@ static int spi_gpio_setup(struct spi_device *spi)
!(spi->mode & SPI_CS_HIGH));
}
}
- if (!status)
+ if (!status) {
status = spi_bitbang_setup(spi);
+ spi_gpio->cs_gpios[spi->chip_select] = cs;
+ }
+
if (status) {
if (!spi->controller_state && cs != SPI_GPIO_NO_CHIPSELECT)
gpio_free(cs);
@@ -250,7 +262,8 @@ static int spi_gpio_setup(struct spi_device *spi)
static void spi_gpio_cleanup(struct spi_device *spi)
{
- unsigned long cs = (unsigned long) spi->controller_data;
+ struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
+ unsigned int cs = spi_gpio->cs_gpios[spi->chip_select];
if (cs != SPI_GPIO_NO_CHIPSELECT)
gpio_free(cs);
@@ -331,7 +344,8 @@ static int __devinit spi_gpio_probe(struct platform_device
*pdev)
if (status < 0)
return status;
- master = spi_alloc_master(&pdev->dev, sizeof *spi_gpio);
+ master = spi_alloc_master(&pdev->dev, sizeof(*spi_gpio) +
+ (sizeof(int) * SPI_N_CHIPSEL));
if (!master) {
status = -ENOMEM;
goto gpio_free;
--
1.7.11.2
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH resend 2/2] SPI: spi-gpio: Add DT bindings
This patch adds DT bindings to the spi-gpio driver and some
documentation about how to use it.
Signed-off-by: Daniel Mack
Cc: Mark Brown
Cc: Grant Likely
Cc: Linus Walleij
---
Documentation/devicetree/bindings/spi/spi-gpio.txt | 29 +++
drivers/spi/spi-gpio.c | 99 +-
2 files changed, 125 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/spi-gpio.txt
diff --git a/Documentation/devicetree/bindings/spi/spi-gpio.txt
b/Documentation/devicetree/bindings/spi/spi-gpio.txt
new file mode 100644
index 000..8a824be
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-gpio.txt
@@ -0,0 +1,29 @@
+SPI-GPIO devicetree bindings
+
+Required properties:
+
+ - compatible: should be set to "spi-gpio"
+ - #address-cells: should be set to <0x1>
+ - ranges
+ - gpio-sck: GPIO spec for the SCK line to use
+ - gpio-miso: GPIO spec for the MISO line to use
+ - gpio-mosi: GPIO spec for the MOSI line to use
+ - cs-gpios: GPIOs to use for chipselect lines
+ - num-chipselects: number of chipselect lines
+
+Example:
+
+ spi {
+ compatible = "spi-gpio";
+ #address-cells = <0x1>;
+ ranges;
+
+ gpio-sck = <&gpio 95 0>;
+ gpio-miso = <&gpio 98 0>;
+ gpio-mosi = <&gpio 97 0>;
+ cs-gpios = <&gpio 125 0>;
+ num-chipselects = <1>;
+
+ /* clients */
+ };
+
diff --git a/drivers/spi/spi-gpio.c b/drivers/spi/spi-gpio.c
index ff7263c..aed1615 100644
--- a/drivers/spi/spi-gpio.c
+++ b/drivers/spi/spi-gpio.c
@@ -22,6 +22,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -232,13 +234,27 @@ static void spi_gpio_chipselect(struct spi_device *spi,
int is_active)
static int spi_gpio_setup(struct spi_device *spi)
{
- unsigned intcs = (unsigned int) spi->controller_data;
+ unsigned intcs;
int status = 0;
struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
+ struct device_node *np = spi->master->dev.of_node;
if (spi->bits_per_word > 32)
return -EINVAL;
+ if (np) {
+ /*
+* In DT environments, the CS GPIOs have already been
+* initialized from the "cs-gpios" property of the node.
+*/
+ cs = spi_gpio->cs_gpios[spi->chip_select];
+ } else {
+ /*
+* ... otherwise, take it from spi->controller_data
+*/
+ cs = (unsigned int) spi->controller_data;
+ }
+
if (!spi->controller_state) {
if (cs != SPI_GPIO_NO_CHIPSELECT) {
status = gpio_request(cs, dev_name(&spi->dev));
@@ -250,6 +266,7 @@ static int spi_gpio_setup(struct spi_device *spi)
}
if (!status) {
status = spi_bitbang_setup(spi);
+ /* in case it was initialized from static board data */
spi_gpio->cs_gpios[spi->chip_select] = cs;
}
@@ -326,6 +343,55 @@ done:
return value;
}
+#ifdef CONFIG_OF
+static struct of_device_id spi_gpio_dt_ids[] = {
+ { .compatible = "spi-gpio" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, spi_gpio_dt_ids);
+
+static int spi_gpio_probe_dt(struct platform_device *pdev)
+{
+ int ret;
+ u32 tmp;
+ struct spi_gpio_platform_data *pdata;
+ struct device_node *np = pdev->dev.of_node;
+ const struct of_device_id *of_id =
+ of_match_device(spi_gpio_dt_ids, &pdev->dev);
+
+ if (!of_id)
+ return 0;
+
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ pdata->sck = of_get_named_gpio(np, "gpio-sck", 0);
+ pdata->miso = of_get_named_gpio(np, "gpio-miso", 0);
+ pdata->mosi = of_get_named_gpio(np, "gpio-mosi", 0);
+
+ ret = of_property_read_u32(np, "num-chipselects", &tmp);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "num-chipselects property not found\n");
+ goto error_free;
+ }
+
+ pdata->num_chipselect = tmp;
+ pdev->dev.platform_data = pdata;
+
+ return 1;
+
+error_free:
+ devm_kfree(&pdev->dev, pdata);
+ return ret;
+}
+#else
+static inline int spi_probe_dt(struct platform_device *)
+{
+ return 0;
+}
+#endif
+
static int __devinit spi_gpio_probe(struct platform_device *pdev)
{
int status;
@@ -333,6 +399,13 @@ static int __devinit spi_gpio_probe(struct platform_device
*pdev)
struct spi_gpio
Re: [PATCH 1/2] SPI: spi-gpio: store chipselect information in private structure
On 01.08.2012 22:51, Mark Brown wrote: > On Wed, Aug 01, 2012 at 10:45:19PM +0200, Daniel Mack wrote: > >> could you have another look at these patches maybe? They aren't urgent, >> I just want to avoid the get lost. > > Can you please resend them with me in the CCs? My process for handling > patches is very heavily based on my inbox. > Sure. This time, I added you, Grant and Linus W to the patch using Cc: lines. Let's see if that works better :) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH resend 2/2] SPI: spi-gpio: Add DT bindings
On 05.08.2012 02:14, Linus Walleij wrote: > On Wed, Aug 1, 2012 at 10:57 PM, Daniel Mack wrote: > >> This patch adds DT bindings to the spi-gpio driver and some >> documentation about how to use it. >> >> Signed-off-by: Daniel Mack >> Cc: Mark Brown >> Cc: Grant Likely >> Cc: Linus Walleij > > From a GPIO point of view this looks good to me. > > Acked-by: Linus Walleij Ok, thanks. Mark, did the patches reach you this time? I think they should go thru the SPI tree. Thanks, Daniel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH resend 1/2] SPI: spi-gpio: store chipselect information in private structure
On 04.08.2012 13:12, Mark Brown wrote: > On Wed, Aug 01, 2012 at 10:57:17PM +0200, Daniel Mack wrote: >> The spi-gpio driver currently assumes the chipselect gpio number is >> stored in ->controller_data of the device's static board information. > > Applied both, thanks. It's a bit sad that we need an explict property > for num-chipselects though. > We don't need that, and a patch to change it would be trivial. IIRC, there was just no agreement on deriving that information implicitly via the count of given GPIOs, and I don't know what should be considered more important - resemblance between drivers bindings or simplicity. We could of course change that for all SPI master drivers at once. Daniel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v3 0/3] DaVinci DMA engine conversion
Hi Matt, On 23.08.2012 03:09, Matt Porter wrote: > This series begins the conversion of the DaVinci private EDMA API > implementation to a DMA engine driver and converts two of the three > in-kernel users of the private EDMA API to DMA engine. > > The approach taken is similar to the recent OMAP DMA Engine > conversion. The EDMA DMA Engine driver is a wrapper around the existing > private EDMA implementation and registers the platform device within > the driver. This allows the conversion series to stand alone with just > the drivers and no changes to platform code. It also allows peripheral > drivers to continue to use the private EDMA implementation until they > are converted. > > The EDMA DMA Engine driver supports slave transfers only at this time. It > is planned to add cyclic transfers in support of audio peripherals. > > There are three users of the private EDMA API in the kernel now: > davinci_mmc, spi-davinci, and davinci-mcasp. This series provides DMA > Engine conversions for the davinci_mmc and spi-davinci drivers which > use the supported slave transfers. > > This series has been tested on an AM18x EVM and Hawkboard with > driver performance comparable to that of the private EDMA API > implementations. Both MMC0 and MMC1 are tested which handles the > DA850/OMAP-L138/AM18x specific case where MMC1 uses DMA channels on > a second EDMA channel controller. All other platforms have a simpler > design with just a single EDMA channel controller. > > For those wanting to easily test this series, I've pushed a branch for > each version to my github tree at https://github.com/ohporter/linux. The > current branch is edma-dmaengine-v3. > > After this series, the current plan is to complete the mcasp driver > conversion which includes adding cyclic dma support. This will then > enable the removal and refactoring of the private EDMA API functionality > into the EDMA DMA Engine driver. Since EDMA is also used on the AM33xx > family of parts in mach-omap2/, the plan is to enable this driver on > that platform as well. Once you have a patch for the McASP driver conversion, I can happily test this on a AM33xx board, together with Gururaja's latest McASP refactoring series. Let me know how I can help you here. Thanks, Daniel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH resend 2/2] SPI: spi-gpio: Add DT bindings
On 05.08.2012 21:12, Linus Walleij wrote: > On Sun, Aug 5, 2012 at 1:57 PM, Daniel Mack wrote: > >>> Acked-by: Linus Walleij >> >> Ok, thanks. Mark, did the patches reach you this time? I think they >> should go thru the SPI tree. > > Yeah no problem, Mark is always faster than me ... Hmm, I don't know whether anyone took those patches yet? Mark? Thanks, Daniel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH resend 2/2] SPI: spi-gpio: Add DT bindings
On 05.09.2012 05:24, Mark Brown wrote: > On Mon, Sep 03, 2012 at 01:50:34PM +0200, Linus Walleij wrote: >> On Sun, Sep 2, 2012 at 10:17 PM, Daniel Mack wrote: > >>> Hmm, I don't know whether anyone took those patches yet? Mark? > >> Mark better take them, ping on Mark. > > IIRC I did reply saying that the patches didn't apply for me, in any > case I don't have them any more - can you please check that they apply > against my -next branch and resend? Sure, will do. They applied cleanly on top of the spi-next branch though. Nevermind :) Daniel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH RESEND-2 1/2] SPI: spi-gpio: store chipselect information in private structure
The spi-gpio driver currently assumes the chipselect gpio number is
stored in ->controller_data of the device's static board information.
In devicetree environments, this information is unavailable and has to
be derived from the DT node.
This patch moves the gpio storage to the controller's private data so
the DT bindings can easily build upon the driver.
Signed-off-by: Daniel Mack
---
drivers/spi/spi-gpio.c | 34 --
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/drivers/spi/spi-gpio.c b/drivers/spi/spi-gpio.c
index 0b56cfc..ff7263c 100644
--- a/drivers/spi/spi-gpio.c
+++ b/drivers/spi/spi-gpio.c
@@ -46,6 +46,7 @@ struct spi_gpio {
struct spi_bitbang bitbang;
struct spi_gpio_platform_data pdata;
struct platform_device *pdev;
+ int cs_gpios[0];
};
/*--*/
@@ -89,15 +90,21 @@ struct spi_gpio {
/*--*/
-static inline const struct spi_gpio_platform_data * __pure
-spi_to_pdata(const struct spi_device *spi)
+static inline struct spi_gpio * __pure
+spi_to_spi_gpio(const struct spi_device *spi)
{
const struct spi_bitbang*bang;
- const struct spi_gpio *spi_gpio;
+ struct spi_gpio *spi_gpio;
bang = spi_master_get_devdata(spi->master);
spi_gpio = container_of(bang, struct spi_gpio, bitbang);
- return &spi_gpio->pdata;
+ return spi_gpio;
+}
+
+static inline struct spi_gpio_platform_data * __pure
+spi_to_pdata(const struct spi_device *spi)
+{
+ return &spi_to_spi_gpio(spi)->pdata;
}
/* this is #defined to avoid unused-variable warnings when inlining */
@@ -210,7 +217,8 @@ static u32 spi_gpio_spec_txrx_word_mode3(struct spi_device
*spi,
static void spi_gpio_chipselect(struct spi_device *spi, int is_active)
{
- unsigned long cs = (unsigned long) spi->controller_data;
+ struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
+ unsigned int cs = spi_gpio->cs_gpios[spi->chip_select];
/* set initial clock polarity */
if (is_active)
@@ -224,8 +232,9 @@ static void spi_gpio_chipselect(struct spi_device *spi, int
is_active)
static int spi_gpio_setup(struct spi_device *spi)
{
- unsigned long cs = (unsigned long) spi->controller_data;
- int status = 0;
+ unsigned intcs = (unsigned int) spi->controller_data;
+ int status = 0;
+ struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
if (spi->bits_per_word > 32)
return -EINVAL;
@@ -239,8 +248,11 @@ static int spi_gpio_setup(struct spi_device *spi)
!(spi->mode & SPI_CS_HIGH));
}
}
- if (!status)
+ if (!status) {
status = spi_bitbang_setup(spi);
+ spi_gpio->cs_gpios[spi->chip_select] = cs;
+ }
+
if (status) {
if (!spi->controller_state && cs != SPI_GPIO_NO_CHIPSELECT)
gpio_free(cs);
@@ -250,7 +262,8 @@ static int spi_gpio_setup(struct spi_device *spi)
static void spi_gpio_cleanup(struct spi_device *spi)
{
- unsigned long cs = (unsigned long) spi->controller_data;
+ struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
+ unsigned int cs = spi_gpio->cs_gpios[spi->chip_select];
if (cs != SPI_GPIO_NO_CHIPSELECT)
gpio_free(cs);
@@ -331,7 +344,8 @@ static int __devinit spi_gpio_probe(struct platform_device
*pdev)
if (status < 0)
return status;
- master = spi_alloc_master(&pdev->dev, sizeof *spi_gpio);
+ master = spi_alloc_master(&pdev->dev, sizeof(*spi_gpio) +
+ (sizeof(int) * SPI_N_CHIPSEL));
if (!master) {
status = -ENOMEM;
goto gpio_free;
--
1.7.11.4
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH RESEND-2 2/2] SPI: spi-gpio: Add DT bindings
This patch adds DT bindings to the spi-gpio driver and some
documentation about how to use it.
Signed-off-by: Daniel Mack
---
Documentation/devicetree/bindings/spi/spi-gpio.txt | 29 +++
drivers/spi/spi-gpio.c | 99 +-
2 files changed, 125 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/spi-gpio.txt
diff --git a/Documentation/devicetree/bindings/spi/spi-gpio.txt
b/Documentation/devicetree/bindings/spi/spi-gpio.txt
new file mode 100644
index 000..8a824be
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-gpio.txt
@@ -0,0 +1,29 @@
+SPI-GPIO devicetree bindings
+
+Required properties:
+
+ - compatible: should be set to "spi-gpio"
+ - #address-cells: should be set to <0x1>
+ - ranges
+ - gpio-sck: GPIO spec for the SCK line to use
+ - gpio-miso: GPIO spec for the MISO line to use
+ - gpio-mosi: GPIO spec for the MOSI line to use
+ - cs-gpios: GPIOs to use for chipselect lines
+ - num-chipselects: number of chipselect lines
+
+Example:
+
+ spi {
+ compatible = "spi-gpio";
+ #address-cells = <0x1>;
+ ranges;
+
+ gpio-sck = <&gpio 95 0>;
+ gpio-miso = <&gpio 98 0>;
+ gpio-mosi = <&gpio 97 0>;
+ cs-gpios = <&gpio 125 0>;
+ num-chipselects = <1>;
+
+ /* clients */
+ };
+
diff --git a/drivers/spi/spi-gpio.c b/drivers/spi/spi-gpio.c
index ff7263c..aed1615 100644
--- a/drivers/spi/spi-gpio.c
+++ b/drivers/spi/spi-gpio.c
@@ -22,6 +22,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -232,13 +234,27 @@ static void spi_gpio_chipselect(struct spi_device *spi,
int is_active)
static int spi_gpio_setup(struct spi_device *spi)
{
- unsigned intcs = (unsigned int) spi->controller_data;
+ unsigned intcs;
int status = 0;
struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
+ struct device_node *np = spi->master->dev.of_node;
if (spi->bits_per_word > 32)
return -EINVAL;
+ if (np) {
+ /*
+* In DT environments, the CS GPIOs have already been
+* initialized from the "cs-gpios" property of the node.
+*/
+ cs = spi_gpio->cs_gpios[spi->chip_select];
+ } else {
+ /*
+* ... otherwise, take it from spi->controller_data
+*/
+ cs = (unsigned int) spi->controller_data;
+ }
+
if (!spi->controller_state) {
if (cs != SPI_GPIO_NO_CHIPSELECT) {
status = gpio_request(cs, dev_name(&spi->dev));
@@ -250,6 +266,7 @@ static int spi_gpio_setup(struct spi_device *spi)
}
if (!status) {
status = spi_bitbang_setup(spi);
+ /* in case it was initialized from static board data */
spi_gpio->cs_gpios[spi->chip_select] = cs;
}
@@ -326,6 +343,55 @@ done:
return value;
}
+#ifdef CONFIG_OF
+static struct of_device_id spi_gpio_dt_ids[] = {
+ { .compatible = "spi-gpio" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, spi_gpio_dt_ids);
+
+static int spi_gpio_probe_dt(struct platform_device *pdev)
+{
+ int ret;
+ u32 tmp;
+ struct spi_gpio_platform_data *pdata;
+ struct device_node *np = pdev->dev.of_node;
+ const struct of_device_id *of_id =
+ of_match_device(spi_gpio_dt_ids, &pdev->dev);
+
+ if (!of_id)
+ return 0;
+
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ pdata->sck = of_get_named_gpio(np, "gpio-sck", 0);
+ pdata->miso = of_get_named_gpio(np, "gpio-miso", 0);
+ pdata->mosi = of_get_named_gpio(np, "gpio-mosi", 0);
+
+ ret = of_property_read_u32(np, "num-chipselects", &tmp);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "num-chipselects property not found\n");
+ goto error_free;
+ }
+
+ pdata->num_chipselect = tmp;
+ pdev->dev.platform_data = pdata;
+
+ return 1;
+
+error_free:
+ devm_kfree(&pdev->dev, pdata);
+ return ret;
+}
+#else
+static inline int spi_probe_dt(struct platform_device *)
+{
+ return 0;
+}
+#endif
+
static int __devinit spi_gpio_probe(struct platform_device *pdev)
{
int status;
@@ -333,6 +399,13 @@ static int __devinit spi_gpio_probe(struct platform_device
*pdev)
struct spi_gpio *spi_gpio;
struct spi_gpio_platform
Re: [PATCH v3 0/3] DaVinci DMA engine conversion
Hi Matt, On 27.08.2012 17:33, Daniel Mack wrote: > On 23.08.2012 03:09, Matt Porter wrote: >> This series begins the conversion of the DaVinci private EDMA API >> implementation to a DMA engine driver and converts two of the three >> in-kernel users of the private EDMA API to DMA engine. >> >> The approach taken is similar to the recent OMAP DMA Engine >> conversion. The EDMA DMA Engine driver is a wrapper around the existing >> private EDMA implementation and registers the platform device within >> the driver. This allows the conversion series to stand alone with just >> the drivers and no changes to platform code. It also allows peripheral >> drivers to continue to use the private EDMA implementation until they >> are converted. >> >> The EDMA DMA Engine driver supports slave transfers only at this time. It >> is planned to add cyclic transfers in support of audio peripherals. >> >> There are three users of the private EDMA API in the kernel now: >> davinci_mmc, spi-davinci, and davinci-mcasp. This series provides DMA >> Engine conversions for the davinci_mmc and spi-davinci drivers which >> use the supported slave transfers. >> >> This series has been tested on an AM18x EVM and Hawkboard with >> driver performance comparable to that of the private EDMA API >> implementations. Both MMC0 and MMC1 are tested which handles the >> DA850/OMAP-L138/AM18x specific case where MMC1 uses DMA channels on >> a second EDMA channel controller. All other platforms have a simpler >> design with just a single EDMA channel controller. >> >> For those wanting to easily test this series, I've pushed a branch for >> each version to my github tree at https://github.com/ohporter/linux. The >> current branch is edma-dmaengine-v3. >> >> After this series, the current plan is to complete the mcasp driver >> conversion which includes adding cyclic dma support. This will then >> enable the removal and refactoring of the private EDMA API functionality >> into the EDMA DMA Engine driver. Since EDMA is also used on the AM33xx >> family of parts in mach-omap2/, the plan is to enable this driver on >> that platform as well. > > Once you have a patch for the McASP driver conversion, I can happily > test this on a AM33xx board, together with Gururaja's latest McASP > refactoring series. Let me know how I can help you here. Did you find some time yet to continue on this side? I don't want to appear pushy, but as I need to finish some DT transition on a AM33xx-based board, I would much like to help out here, in case I can do anything to help speed things along. Many thanks for your work! Daniel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH] SPI: McSPI: allow configuration of pin directions
Allow D0 to be an input and D1 to be an output, configurable via
platform data and a new DT property.
Based on a patch from Matus Ujhelyi
Signed-off-by: Daniel Mack
Cc: Matus Ujhelyi
Cc: Mark Brown
Cc: Grant Likely
Cc: Linus Walleij
Cc: Samuel Ortiz
Cc: Juha Yrjola
---
Documentation/devicetree/bindings/spi/omap-spi.txt | 3 +++
arch/arm/plat-omap/include/plat/mcspi.h| 4
drivers/spi/spi-omap2-mcspi.c | 25 --
3 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt
b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 11aff04..bf4cec8 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -15,6 +15,9 @@ Optional properties:
1:1 with the ordered pairs in dmas. The string naming is
to be "rxN" and "txN" for RX and TX requests,
respectively, where N equals the chip select number.
+- ti,pindir-d0-in-d1-out: Select the D0 pin as input and D1 as
+ output. The default is D0 as output and
+ D1 as input.
Examples:
diff --git a/arch/arm/plat-omap/include/plat/mcspi.h
b/arch/arm/plat-omap/include/plat/mcspi.h
index a357eb2..ce70f7b 100644
--- a/arch/arm/plat-omap/include/plat/mcspi.h
+++ b/arch/arm/plat-omap/include/plat/mcspi.h
@@ -7,9 +7,13 @@
#define OMAP4_MCSPI_REG_OFFSET 0x100
+#define MCSPI_PINDIR_D0_OUT_D1_IN 0
+#define MCSPI_PINDIR_D0_IN_D1_OUT 1
+
struct omap2_mcspi_platform_config {
unsigned short num_cs;
unsigned int regs_offset;
+ unsigned int pin_dir:1;
};
struct omap2_mcspi_dev_attr {
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 1cf1072..d4588ef 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -134,6 +134,7 @@ struct omap2_mcspi {
struct omap2_mcspi_dma *dma_channels;
struct device *dev;
struct omap2_mcspi_regs ctx;
+ unsigned intpin_dir:1;
};
struct omap2_mcspi_cs {
@@ -747,8 +748,15 @@ static int omap2_mcspi_setup_transfer(struct spi_device
*spi,
/* standard 4-wire master mode: SCK, MOSI/out, MISO/in, nCS
* REVISIT: this controller could support SPI_3WIRE mode.
*/
- l &= ~(OMAP2_MCSPI_CHCONF_IS|OMAP2_MCSPI_CHCONF_DPE1);
- l |= OMAP2_MCSPI_CHCONF_DPE0;
+ if (mcspi->pin_dir == MCSPI_PINDIR_D1_IN_D0_OUT) {
+ l &= ~OMAP2_MCSPI_CHCONF_IS;
+ l &= ~OMAP2_MCSPI_CHCONF_DPE1;
+ l |= OMAP2_MCSPI_CHCONF_DPE0;
+ } else {
+ l |= OMAP2_MCSPI_CHCONF_IS;
+ l |= OMAP2_MCSPI_CHCONF_DPE1;
+ l &= ~OMAP2_MCSPI_CHCONF_DPE0;
+ }
/* wordlength */
l &= ~OMAP2_MCSPI_CHCONF_WL_MASK;
@@ -1159,6 +1167,11 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
master->cleanup = omap2_mcspi_cleanup;
master->dev.of_node = node;
+ dev_set_drvdata(&pdev->dev, master);
+
+ mcspi = spi_master_get_devdata(master);
+ mcspi->master = master;
+
match = of_match_device(omap_mcspi_of_match, &pdev->dev);
if (match) {
u32 num_cs = 1; /* default number of chipselect */
@@ -1167,19 +1180,17 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
of_property_read_u32(node, "ti,spi-num-cs", &num_cs);
master->num_chipselect = num_cs;
master->bus_num = bus_num++;
+ if (of_get_property(node, "ti,pindir-d0-in-d1-out", NULL))
+ mcspi->pin_dir = MCSPI_PINDIR_D0_IN_D1_OUT;
} else {
pdata = pdev->dev.platform_data;
master->num_chipselect = pdata->num_cs;
if (pdev->id != -1)
master->bus_num = pdev->id;
+ mcspi->pin_dir = pdata->pin_dir;
}
regs_offset = pdata->regs_offset;
- dev_set_drvdata(&pdev->dev, master);
-
- mcspi = spi_master_get_devdata(master);
- mcspi->master = master;
-
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (r == NULL) {
status = -ENODEV;
--
1.7.11.4
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH v2] SPI: McSPI: allow configuration of pin directions
Allow D0 to be an input and D1 to be an output, configurable via
platform data and a new DT property.
Based on a patch from Matus Ujhelyi
Signed-off-by: Daniel Mack
Cc: Matus Ujhelyi
Cc: Mark Brown
Cc: Grant Likely
Cc: Linus Walleij
Cc: Samuel Ortiz
Cc: Juha Yrjola
---
changes from v1: forgot to stage one hunk.
Documentation/devicetree/bindings/spi/omap-spi.txt | 3 +++
arch/arm/plat-omap/include/plat/mcspi.h| 4
drivers/spi/spi-omap2-mcspi.c | 25 --
3 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt
b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 11aff04..bf4cec8 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -15,6 +15,9 @@ Optional properties:
1:1 with the ordered pairs in dmas. The string naming is
to be "rxN" and "txN" for RX and TX requests,
respectively, where N equals the chip select number.
+- ti,pindir-d0-in-d1-out: Select the D0 pin as input and D1 as
+ output. The default is D0 as output and
+ D1 as input.
Examples:
diff --git a/arch/arm/plat-omap/include/plat/mcspi.h
b/arch/arm/plat-omap/include/plat/mcspi.h
index a357eb2..ce70f7b 100644
--- a/arch/arm/plat-omap/include/plat/mcspi.h
+++ b/arch/arm/plat-omap/include/plat/mcspi.h
@@ -7,9 +7,13 @@
#define OMAP4_MCSPI_REG_OFFSET 0x100
+#define MCSPI_PINDIR_D0_OUT_D1_IN 0
+#define MCSPI_PINDIR_D0_IN_D1_OUT 1
+
struct omap2_mcspi_platform_config {
unsigned short num_cs;
unsigned int regs_offset;
+ unsigned int pin_dir:1;
};
struct omap2_mcspi_dev_attr {
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 1cf1072..c2834d6 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -134,6 +134,7 @@ struct omap2_mcspi {
struct omap2_mcspi_dma *dma_channels;
struct device *dev;
struct omap2_mcspi_regs ctx;
+ unsigned intpin_dir:1;
};
struct omap2_mcspi_cs {
@@ -747,8 +748,15 @@ static int omap2_mcspi_setup_transfer(struct spi_device
*spi,
/* standard 4-wire master mode: SCK, MOSI/out, MISO/in, nCS
* REVISIT: this controller could support SPI_3WIRE mode.
*/
- l &= ~(OMAP2_MCSPI_CHCONF_IS|OMAP2_MCSPI_CHCONF_DPE1);
- l |= OMAP2_MCSPI_CHCONF_DPE0;
+ if (mcspi->pin_dir == MCSPI_PINDIR_D0_OUT_D1_IN) {
+ l &= ~OMAP2_MCSPI_CHCONF_IS;
+ l &= ~OMAP2_MCSPI_CHCONF_DPE1;
+ l |= OMAP2_MCSPI_CHCONF_DPE0;
+ } else {
+ l |= OMAP2_MCSPI_CHCONF_IS;
+ l |= OMAP2_MCSPI_CHCONF_DPE1;
+ l &= ~OMAP2_MCSPI_CHCONF_DPE0;
+ }
/* wordlength */
l &= ~OMAP2_MCSPI_CHCONF_WL_MASK;
@@ -1159,6 +1167,11 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
master->cleanup = omap2_mcspi_cleanup;
master->dev.of_node = node;
+ dev_set_drvdata(&pdev->dev, master);
+
+ mcspi = spi_master_get_devdata(master);
+ mcspi->master = master;
+
match = of_match_device(omap_mcspi_of_match, &pdev->dev);
if (match) {
u32 num_cs = 1; /* default number of chipselect */
@@ -1167,19 +1180,17 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
of_property_read_u32(node, "ti,spi-num-cs", &num_cs);
master->num_chipselect = num_cs;
master->bus_num = bus_num++;
+ if (of_get_property(node, "ti,pindir-d0-in-d1-out", NULL))
+ mcspi->pin_dir = MCSPI_PINDIR_D0_IN_D1_OUT;
} else {
pdata = pdev->dev.platform_data;
master->num_chipselect = pdata->num_cs;
if (pdev->id != -1)
master->bus_num = pdev->id;
+ mcspi->pin_dir = pdata->pin_dir;
}
regs_offset = pdata->regs_offset;
- dev_set_drvdata(&pdev->dev, master);
-
- mcspi = spi_master_get_devdata(master);
- mcspi->master = master;
-
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (r == NULL) {
status = -ENODEV;
--
1.7.11.4
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH v3] SPI: McSPI: allow configuration of pin directions
Allow D0 to be an input and D1 to be an output, configurable via
platform data and a new DT property.
Based on a patch from Matus Ujhelyi
Signed-off-by: Daniel Mack
Cc: Matus Ujhelyi
Cc: Mark Brown
Cc: Grant Likely
Cc: Linus Walleij
Cc: Samuel Ortiz
Cc: Juha Yrjola
---
changes from v1: added a forgotten hunk
changes from v2: rebased to current spi-master.
Sorry for the noise. I shouldn't be working on sundays :)
Documentation/devicetree/bindings/spi/omap-spi.txt | 4 +++-
drivers/spi/spi-omap2-mcspi.c | 25 --
include/linux/platform_data/spi-omap2-mcspi.h | 4
3 files changed, 25 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt
b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 81df374..2ef0a6b 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -6,7 +6,9 @@ Required properties:
- "ti,omap4-spi" for OMAP4+.
- ti,spi-num-cs : Number of chipselect supported by the instance.
- ti,hwmods: Name of the hwmod associated to the McSPI
-
+- ti,pindir-d0-in-d1-out: Select the D0 pin as input and D1 as
+ output. The default is D0 as output and
+ D1 as input.
Example:
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 474e217..1ec7e772 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -131,6 +131,7 @@ struct omap2_mcspi {
struct omap2_mcspi_dma *dma_channels;
struct device *dev;
struct omap2_mcspi_regs ctx;
+ unsigned intpin_dir:1;
};
struct omap2_mcspi_cs {
@@ -766,8 +767,15 @@ static int omap2_mcspi_setup_transfer(struct spi_device
*spi,
/* standard 4-wire master mode: SCK, MOSI/out, MISO/in, nCS
* REVISIT: this controller could support SPI_3WIRE mode.
*/
- l &= ~(OMAP2_MCSPI_CHCONF_IS|OMAP2_MCSPI_CHCONF_DPE1);
- l |= OMAP2_MCSPI_CHCONF_DPE0;
+ if (mcspi->pin_dir == MCSPI_PINDIR_D0_OUT_D1_IN) {
+ l &= ~OMAP2_MCSPI_CHCONF_IS;
+ l &= ~OMAP2_MCSPI_CHCONF_DPE1;
+ l |= OMAP2_MCSPI_CHCONF_DPE0;
+ } else {
+ l |= OMAP2_MCSPI_CHCONF_IS;
+ l |= OMAP2_MCSPI_CHCONF_DPE1;
+ l &= ~OMAP2_MCSPI_CHCONF_DPE0;
+ }
/* wordlength */
l &= ~OMAP2_MCSPI_CHCONF_WL_MASK;
@@ -1168,6 +1176,11 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
master->cleanup = omap2_mcspi_cleanup;
master->dev.of_node = node;
+ dev_set_drvdata(&pdev->dev, master);
+
+ mcspi = spi_master_get_devdata(master);
+ mcspi->master = master;
+
match = of_match_device(omap_mcspi_of_match, &pdev->dev);
if (match) {
u32 num_cs = 1; /* default number of chipselect */
@@ -1176,19 +1189,17 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
of_property_read_u32(node, "ti,spi-num-cs", &num_cs);
master->num_chipselect = num_cs;
master->bus_num = bus_num++;
+ if (of_get_property(node, "ti,pindir-d0-in-d1-out", NULL))
+ mcspi->pin_dir = MCSPI_PINDIR_D0_IN_D1_OUT;
} else {
pdata = pdev->dev.platform_data;
master->num_chipselect = pdata->num_cs;
if (pdev->id != -1)
master->bus_num = pdev->id;
+ mcspi->pin_dir = pdata->pin_dir;
}
regs_offset = pdata->regs_offset;
- dev_set_drvdata(&pdev->dev, master);
-
- mcspi = spi_master_get_devdata(master);
- mcspi->master = master;
-
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (r == NULL) {
status = -ENODEV;
diff --git a/include/linux/platform_data/spi-omap2-mcspi.h
b/include/linux/platform_data/spi-omap2-mcspi.h
index a357eb2..ce70f7b 100644
--- a/include/linux/platform_data/spi-omap2-mcspi.h
+++ b/include/linux/platform_data/spi-omap2-mcspi.h
@@ -7,9 +7,13 @@
#define OMAP4_MCSPI_REG_OFFSET 0x100
+#define MCSPI_PINDIR_D0_OUT_D1_IN 0
+#define MCSPI_PINDIR_D0_IN_D1_OUT 1
+
struct omap2_mcspi_platform_config {
unsigned short num_cs;
unsigned int regs_offset;
+ unsigned int pin_dir:1;
};
struct omap2_mcspi_dev_attr {
--
1.7.11.4
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt to
[PATCH RESEND] SPI: McSPI: allow configuration of pin directions
Allow D0 to be an input and D1 to be an output, configurable via
platform data and a new DT property.
Based on a patch from Matus Ujhelyi
Signed-off-by: Daniel Mack
Cc: Matus Ujhelyi
Cc: Mark Brown
Cc: Grant Likely
Cc: Linus Walleij
Cc: Samuel Ortiz
Cc: Juha Yrjola
Cc: Vaibhav Hiremath
Cc: Shubhrajyoti D
---
Resending with more people in cc
Documentation/devicetree/bindings/spi/omap-spi.txt | 4 +++-
drivers/spi/spi-omap2-mcspi.c | 25 --
include/linux/platform_data/spi-omap2-mcspi.h | 4
3 files changed, 25 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt
b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 81df374..2ef0a6b 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -6,7 +6,9 @@ Required properties:
- "ti,omap4-spi" for OMAP4+.
- ti,spi-num-cs : Number of chipselect supported by the instance.
- ti,hwmods: Name of the hwmod associated to the McSPI
-
+- ti,pindir-d0-in-d1-out: Select the D0 pin as input and D1 as
+ output. The default is D0 as output and
+ D1 as input.
Example:
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 3542fdc..5104633 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -130,6 +130,7 @@ struct omap2_mcspi {
struct omap2_mcspi_dma *dma_channels;
struct device *dev;
struct omap2_mcspi_regs ctx;
+ unsigned intpin_dir:1;
};
struct omap2_mcspi_cs {
@@ -765,8 +766,15 @@ static int omap2_mcspi_setup_transfer(struct spi_device
*spi,
/* standard 4-wire master mode: SCK, MOSI/out, MISO/in, nCS
* REVISIT: this controller could support SPI_3WIRE mode.
*/
- l &= ~(OMAP2_MCSPI_CHCONF_IS|OMAP2_MCSPI_CHCONF_DPE1);
- l |= OMAP2_MCSPI_CHCONF_DPE0;
+ if (mcspi->pin_dir == MCSPI_PINDIR_D0_OUT_D1_IN) {
+ l &= ~OMAP2_MCSPI_CHCONF_IS;
+ l &= ~OMAP2_MCSPI_CHCONF_DPE1;
+ l |= OMAP2_MCSPI_CHCONF_DPE0;
+ } else {
+ l |= OMAP2_MCSPI_CHCONF_IS;
+ l |= OMAP2_MCSPI_CHCONF_DPE1;
+ l &= ~OMAP2_MCSPI_CHCONF_DPE0;
+ }
/* wordlength */
l &= ~OMAP2_MCSPI_CHCONF_WL_MASK;
@@ -1167,6 +1175,11 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
master->cleanup = omap2_mcspi_cleanup;
master->dev.of_node = node;
+ dev_set_drvdata(&pdev->dev, master);
+
+ mcspi = spi_master_get_devdata(master);
+ mcspi->master = master;
+
match = of_match_device(omap_mcspi_of_match, &pdev->dev);
if (match) {
u32 num_cs = 1; /* default number of chipselect */
@@ -1175,19 +1188,17 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
of_property_read_u32(node, "ti,spi-num-cs", &num_cs);
master->num_chipselect = num_cs;
master->bus_num = bus_num++;
+ if (of_get_property(node, "ti,pindir-d0-in-d1-out", NULL))
+ mcspi->pin_dir = MCSPI_PINDIR_D0_IN_D1_OUT;
} else {
pdata = pdev->dev.platform_data;
master->num_chipselect = pdata->num_cs;
if (pdev->id != -1)
master->bus_num = pdev->id;
+ mcspi->pin_dir = pdata->pin_dir;
}
regs_offset = pdata->regs_offset;
- dev_set_drvdata(&pdev->dev, master);
-
- mcspi = spi_master_get_devdata(master);
- mcspi->master = master;
-
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (r == NULL) {
status = -ENODEV;
diff --git a/include/linux/platform_data/spi-omap2-mcspi.h
b/include/linux/platform_data/spi-omap2-mcspi.h
index a357eb2..ce70f7b 100644
--- a/include/linux/platform_data/spi-omap2-mcspi.h
+++ b/include/linux/platform_data/spi-omap2-mcspi.h
@@ -7,9 +7,13 @@
#define OMAP4_MCSPI_REG_OFFSET 0x100
+#define MCSPI_PINDIR_D0_OUT_D1_IN 0
+#define MCSPI_PINDIR_D0_IN_D1_OUT 1
+
struct omap2_mcspi_platform_config {
unsigned short num_cs;
unsigned int regs_offset;
+ unsigned int pin_dir:1;
};
struct omap2_mcspi_dev_attr {
--
1.7.11.4
--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH] SPI: McSPI: fix D0/D1 direction confusion
0384e90b8 ("spi/mcspi: allow configuration of pin directions") did what
it claimed to do the wrong way around. D0/D1 is configured as output by
*clearing* the bits in the conf registers, hence also breaking the
former default behaviour.
Fix this before that change is merged to mainline.
Signed-off-by: Daniel Mack
---
This breakage went unnoticed due to a flaw in my schematic parsing.
Mark, as long as your mcspi branch is not merged, you can also squash
it into the other one.
Sorry,
Daniel
Documentation/devicetree/bindings/spi/omap-spi.txt | 6 +++---
drivers/spi/spi-omap2-mcspi.c | 6 +++---
include/linux/platform_data/spi-omap2-mcspi.h | 4 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt
b/Documentation/devicetree/bindings/spi/omap-spi.txt
index bf4cec8..8178792 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -15,9 +15,9 @@ Optional properties:
1:1 with the ordered pairs in dmas. The string naming is
to be "rxN" and "txN" for RX and TX requests,
respectively, where N equals the chip select number.
-- ti,pindir-d0-in-d1-out: Select the D0 pin as input and D1 as
- output. The default is D0 as output and
- D1 as input.
+- ti,pindir-d0-out-d1-in: Select the D0 pin as output and D1 as
+ input. The default is D0 as input and
+ D1 as output.
Examples:
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index d17bb43..d1c5828 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -769,7 +769,7 @@ static int omap2_mcspi_setup_transfer(struct spi_device
*spi,
/* standard 4-wire master mode: SCK, MOSI/out, MISO/in, nCS
* REVISIT: this controller could support SPI_3WIRE mode.
*/
- if (mcspi->pin_dir == MCSPI_PINDIR_D0_OUT_D1_IN) {
+ if (mcspi->pin_dir == MCSPI_PINDIR_D0_IN_D1_OUT) {
l &= ~OMAP2_MCSPI_CHCONF_IS;
l &= ~OMAP2_MCSPI_CHCONF_DPE1;
l |= OMAP2_MCSPI_CHCONF_DPE0;
@@ -1200,8 +1200,8 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
of_property_read_u32(node, "ti,spi-num-cs", &num_cs);
master->num_chipselect = num_cs;
master->bus_num = bus_num++;
- if (of_get_property(node, "ti,pindir-d0-in-d1-out", NULL))
- mcspi->pin_dir = MCSPI_PINDIR_D0_IN_D1_OUT;
+ if (of_get_property(node, "ti,pindir-d0-out-d1-in", NULL))
+ mcspi->pin_dir = MCSPI_PINDIR_D0_OUT_D1_IN;
} else {
pdata = pdev->dev.platform_data;
master->num_chipselect = pdata->num_cs;
diff --git a/include/linux/platform_data/spi-omap2-mcspi.h
b/include/linux/platform_data/spi-omap2-mcspi.h
index ce70f7b..a65572d 100644
--- a/include/linux/platform_data/spi-omap2-mcspi.h
+++ b/include/linux/platform_data/spi-omap2-mcspi.h
@@ -7,8 +7,8 @@
#define OMAP4_MCSPI_REG_OFFSET 0x100
-#define MCSPI_PINDIR_D0_OUT_D1_IN 0
-#define MCSPI_PINDIR_D0_IN_D1_OUT 1
+#define MCSPI_PINDIR_D0_IN_D1_OUT 0
+#define MCSPI_PINDIR_D0_OUT_D1_IN 1
struct omap2_mcspi_platform_config {
unsigned short num_cs;
--
1.7.11.7
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH resend] SPI: McSPI: fix D0/D1 direction confusion
0384e90b8 ("spi/mcspi: allow configuration of pin directions") did what
it claimed to do the wrong way around. D0/D1 is configured as output by
*clearing* the bits in the conf registers, hence also breaking the
former default behaviour.
Fix this before that change is merged to mainline.
Signed-off-by: Daniel Mack
---
Resent to apply directly on top of original commit.
Documentation/devicetree/bindings/spi/omap-spi.txt | 6 +++---
drivers/spi/spi-omap2-mcspi.c | 6 +++---
include/linux/platform_data/spi-omap2-mcspi.h | 4 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt
b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 2ef0a6b..938809c 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -6,9 +6,9 @@ Required properties:
- "ti,omap4-spi" for OMAP4+.
- ti,spi-num-cs : Number of chipselect supported by the instance.
- ti,hwmods: Name of the hwmod associated to the McSPI
-- ti,pindir-d0-in-d1-out: Select the D0 pin as input and D1 as
- output. The default is D0 as output and
- D1 as input.
+- ti,pindir-d0-out-d1-in: Select the D0 pin as output and D1 as
+ input. The default is D0 as input and
+ D1 as output.
Example:
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 5104633..89f73c4 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -766,7 +766,7 @@ static int omap2_mcspi_setup_transfer(struct spi_device
*spi,
/* standard 4-wire master mode: SCK, MOSI/out, MISO/in, nCS
* REVISIT: this controller could support SPI_3WIRE mode.
*/
- if (mcspi->pin_dir == MCSPI_PINDIR_D0_OUT_D1_IN) {
+ if (mcspi->pin_dir == MCSPI_PINDIR_D0_IN_D1_OUT) {
l &= ~OMAP2_MCSPI_CHCONF_IS;
l &= ~OMAP2_MCSPI_CHCONF_DPE1;
l |= OMAP2_MCSPI_CHCONF_DPE0;
@@ -1188,8 +1188,8 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
of_property_read_u32(node, "ti,spi-num-cs", &num_cs);
master->num_chipselect = num_cs;
master->bus_num = bus_num++;
- if (of_get_property(node, "ti,pindir-d0-in-d1-out", NULL))
- mcspi->pin_dir = MCSPI_PINDIR_D0_IN_D1_OUT;
+ if (of_get_property(node, "ti,pindir-d0-out-d1-in", NULL))
+ mcspi->pin_dir = MCSPI_PINDIR_D0_OUT_D1_IN;
} else {
pdata = pdev->dev.platform_data;
master->num_chipselect = pdata->num_cs;
diff --git a/include/linux/platform_data/spi-omap2-mcspi.h
b/include/linux/platform_data/spi-omap2-mcspi.h
index ce70f7b..a65572d 100644
--- a/include/linux/platform_data/spi-omap2-mcspi.h
+++ b/include/linux/platform_data/spi-omap2-mcspi.h
@@ -7,8 +7,8 @@
#define OMAP4_MCSPI_REG_OFFSET 0x100
-#define MCSPI_PINDIR_D0_OUT_D1_IN 0
-#define MCSPI_PINDIR_D0_IN_D1_OUT 1
+#define MCSPI_PINDIR_D0_IN_D1_OUT 0
+#define MCSPI_PINDIR_D0_OUT_D1_IN 1
struct omap2_mcspi_platform_config {
unsigned short num_cs;
--
1.7.11.7
--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] spi-gpio: init CS before spi_bitbang_setup()
Cc: Mark
On 09.04.2013 18:40, Josef Ahmad wrote:
> spi_bitbang_setup() deasserts the chip select line to initialise
> the device. The chip select GPIO line is obtained from
> spi_gpio->cs_gpios[] private data.
> Currently, devices that are not registered under devicetree
> environment will call into spi_bitbang_setup() with stale
> cs_gpios[].
>
> This patch ensures spi_gpio->cs_gpios[] is always initialised prior
> to calling spi_bitbang_setup().
>
> Reviewed-by: Daniel Mack
> Signed-off-by: Josef Ahmad
> ---
> drivers/spi/spi-gpio.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/spi/spi-gpio.c b/drivers/spi/spi-gpio.c
> index c7cf0b7..0fa345c 100644
> --- a/drivers/spi/spi-gpio.c
> +++ b/drivers/spi/spi-gpio.c
> @@ -265,9 +265,9 @@ static int spi_gpio_setup(struct spi_device *spi)
> }
> }
> if (!status) {
> - status = spi_bitbang_setup(spi);
> /* in case it was initialized from static board data */
> spi_gpio->cs_gpios[spi->chip_select] = cs;
> + status = spi_bitbang_setup(spi);
> }
>
> if (status) {
>
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] spi-gpio: init CS before spi_bitbang_setup()
On 09.04.2013 19:08, Mark Brown wrote: > On Tue, Apr 09, 2013 at 07:06:32PM +0200, Daniel Mack wrote: >> Cc: Mark >> >> On 09.04.2013 18:40, Josef Ahmad wrote: >>> spi_bitbang_setup() deasserts the chip select line to initialise >>> the device. The chip select GPIO line is obtained from > > Please resend the patch - git am doesn't know how to strip off quotation > stuff! > The reply was fyi only, as the patch also went to spi-devel-general. Can you pick it from there or should Josef send it again with your address in Cc:? -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] i.MX SPI driver
On Wed, Jun 17, 2009 at 12:40:18PM +0200, Sascha Hauer wrote: > The new i.MX SPI driver has been posted twice on the list, I received no > objections from anyone, so please consider pulling the following branch What happened to these patches, have they been picked up? I just tested them on a Lilly1131 board and they seem to work fine. Thanks, Daniel > The following changes since commit 65795efbd380a832ae508b04dba8f8e53f0b84d9: > Linus Torvalds (1): > Merge branch 'next-i2c' of git://aeryn.fluff.org.uk/bjdooks/linux > > are available in the git repository at: > > git://git.pengutronix.de/git/sha/linux-2.6.git for-david > > Sascha Hauer (2): > remove i.MX SPI driver > SPI: Add SPI driver for most known i.MX SoCs > > arch/arm/plat-mxc/include/mach/spi.h | 27 + > drivers/spi/Kconfig |7 +- > drivers/spi/Makefile |2 +- > drivers/spi/mxc_spi.c| 685 + > drivers/spi/spi_imx.c| 1779 > -- > 5 files changed, 717 insertions(+), 1783 deletions(-) > create mode 100644 arch/arm/plat-mxc/include/mach/spi.h > create mode 100644 drivers/spi/mxc_spi.c > delete mode 100644 drivers/spi/spi_imx.c -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[spi-devel-general] [PATCH] drivers/misc: add driver for Texas Instruments DAC7512
This is actually too trivial to publish, but to export the function of
that chip to the userspace, a module like this is needed.
Signed-off-by: Daniel Mack
Cc: Andrew Morton
Cc: David Brownell
Cc: spi-devel-general@lists.sourceforge.net
---
drivers/misc/Kconfig | 10
drivers/misc/Makefile |1 +
drivers/misc/ti_dac7512.c | 102 +
3 files changed, 113 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/ti_dac7512.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index df1f86b..1191446 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -246,6 +246,16 @@ config EP93XX_PWM
To compile this driver as a module, choose M here: the module will
be called ep93xx_pwm.
+config TI_DAC7512
+ tristate "Texas Instruments DAC7512"
+ depends on SPI && SYSFS
+ help
+ If you say yes here you get support for the Texas Instruments
+ DAC7512 16-bit digital-to-analog converter.
+
+ This driver can also be built as a module. If so, the module
+ will be calles ti_dac7512.
+
source "drivers/misc/c2port/Kconfig"
source "drivers/misc/eeprom/Kconfig"
source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index f982d2e..d59830e 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_SGI_GRU) += sgi-gru/
obj-$(CONFIG_HP_ILO) += hpilo.o
obj-$(CONFIG_ISL29003) += isl29003.o
obj-$(CONFIG_EP93XX_PWM) += ep93xx_pwm.o
+obj-$(CONFIG_TI_DAC7512) += ti_dac7512.o
obj-$(CONFIG_C2PORT) += c2port/
obj-y += eeprom/
obj-y += cb710/
diff --git a/drivers/misc/ti_dac7512.c b/drivers/misc/ti_dac7512.c
new file mode 100644
index 000..3c60dcf
--- /dev/null
+++ b/drivers/misc/ti_dac7512.c
@@ -0,0 +1,102 @@
+/*
+ * dac7512.c - Linux kernel module for
+ * Texas Instruments DAC7512
+ *
+ * Copyright (c) 2009 Daniel Mack
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include
+#include
+#include
+
+#define DAC7512_DRV_NAME "dac7512"
+#define DRIVER_VERSION "1.0"
+
+static ssize_t dac7512_store_val(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct spi_device *spi = to_spi_device(dev);
+ unsigned char tmp[2];
+ unsigned long val;
+
+ if (strict_strtoul(buf, 10, &val) < 0)
+ return -EINVAL;
+
+ tmp[0] = val >> 8;
+ tmp[1] = val & 0xff;
+ spi_write(spi, tmp, sizeof(tmp));
+ return count;
+}
+
+static DEVICE_ATTR(value, S_IWUSR | S_IRUGO,
+ NULL, dac7512_store_val);
+
+static struct attribute *dac7512_attributes[] = {
+ &dev_attr_value.attr,
+ NULL
+};
+
+static const struct attribute_group dac7512_attr_group = {
+ .attrs = dac7512_attributes,
+};
+
+static int __devinit dac7512_probe(struct spi_device *spi)
+{
+ int ret;
+
+ spi->bits_per_word = 8;
+ spi->mode = SPI_MODE_0;
+ ret = spi_setup(spi);
+ if (ret < 0)
+ return ret;
+
+ return sysfs_create_group(&spi->dev.kobj, &dac7512_attr_group);
+}
+
+static int __devexit dac7512_remove(struct spi_device *spi)
+{
+ sysfs_remove_group(&spi->dev.kobj, &dac7512_attr_group);
+ return 0;
+}
+
+static struct spi_driver dac7512_driver = {
+ .driver = {
+ .name = DAC7512_DRV_NAME,
+ .owner = THIS_MODULE,
+ },
+ .probe = dac7512_probe,
+ .remove = __devexit_p(dac7512_remove),
+};
+
+static int __init dac7512_init(void)
+{
+ return spi_register_driver(&dac7512_driver);
+}
+
+static void __exit dac7512_exit(void)
+{
+ spi_unregister_driver(&dac7512_driver);
+}
+
+MODULE_AUTHOR("Daniel Mack ");
+MODULE_DESCRIPTION("DAC7512 16-bit DAC");
+MODULE_LICENSE("GPL v2");
+MODULE_VERSION(DRIVER_VERSION);
+
+module_init(dac7512_init);
+module_exit(dac7512_exit);
--
1.6.0.4
--
Re: [spi-devel-general] [PATCH] drivers/misc: add driver for TexasInstruments DAC7512
On Mon, Oct 12, 2009 at 12:31:46PM -0400, H Hartley Sweeten wrote:
> On Wednesday, October 07, 2009 1:01 PM, Daniel Mack wrote:
> > This is actually too trivial to publish, but to export the function of
> > that chip to the userspace, a module like this is needed.
> >
> > Signed-off-by: Daniel Mack
> > Cc: Andrew Morton
> > Cc: David Brownell
> > Cc: spi-devel-general@lists.sourceforge.net
> > ---
>
> [snip]
>
> > +static ssize_t dac7512_store_val(struct device *dev,
> > +struct device_attribute *attr,
> > +const char *buf, size_t count)
> > +{
> > + struct spi_device *spi = to_spi_device(dev);
> > + unsigned char tmp[2];
> > + unsigned long val;
> > +
> > + if (strict_strtoul(buf, 10, &val) < 0)
> > + return -EINVAL;
> > +
> > + tmp[0] = val >> 8;
> > + tmp[1] = val & 0xff;
> > + spi_write(spi, tmp, sizeof(tmp));
> > + return count;
> > +}
> > +
> > +static DEVICE_ATTR(value, S_IWUSR | S_IRUGO,
> > + NULL, dac7512_store_val);
>
> You have declared the "value" device attribute with mode S_IWUSR | S_IRUGO
> but have not provided a show callback.
That's true, and acutally on purpose. I would have needed a private data
structure to allocate which I didn't do because I didn't need that. The
approach is purely write-only, especially beacuse the hardware also does
not provide a way to read back the current value.
Daniel
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] [PATCH] drivers/misc: add driver for TexasInstruments DAC7512
On Mon, Oct 12, 2009 at 12:31:46PM -0400, H Hartley Sweeten wrote:
> On Wednesday, October 07, 2009 1:01 PM, Daniel Mack wrote:
> > This is actually too trivial to publish, but to export the function of
> > that chip to the userspace, a module like this is needed.
> >
> > Signed-off-by: Daniel Mack
> > Cc: Andrew Morton
> > Cc: David Brownell
> > Cc: spi-devel-general@lists.sourceforge.net
> > ---
>
> [snip]
>
> > +static ssize_t dac7512_store_val(struct device *dev,
> > +struct device_attribute *attr,
> > +const char *buf, size_t count)
> > +{
> > + struct spi_device *spi = to_spi_device(dev);
> > + unsigned char tmp[2];
> > + unsigned long val;
> > +
> > + if (strict_strtoul(buf, 10, &val) < 0)
> > + return -EINVAL;
> > +
> > + tmp[0] = val >> 8;
> > + tmp[1] = val & 0xff;
> > + spi_write(spi, tmp, sizeof(tmp));
> > + return count;
> > +}
> > +
> > +static DEVICE_ATTR(value, S_IWUSR | S_IRUGO,
> > + NULL, dac7512_store_val);
>
> You have declared the "value" device attribute with mode S_IWUSR | S_IRUGO
> but have not provided a show callback.
Sorry, forget my last mail, I got you wrong. You're of course right,
S_IRUGO shouldn't be set for write-only attributes. Updates patch below.
Thanks,
Daniel
>From ab18a967e55d2bb1d39559333bca81a01c2838f0 Mon Sep 17 00:00:00 2001
From: Daniel Mack
Date: Thu, 8 Oct 2009 03:55:46 +0800
Subject: [PATCH] drivers/misc: add driver for Texas Instruments DAC7512
This is actually too trivial to publish, but to export the function of
that chip to the userspace, a module like this is needed.
Signed-off-by: Daniel Mack
Cc: Andrew Morton
Cc: David Brownell
Cc: spi-devel-general@lists.sourceforge.net
---
drivers/misc/Kconfig | 10
drivers/misc/Makefile |1 +
drivers/misc/ti_dac7512.c | 101 +
3 files changed, 112 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/ti_dac7512.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index df1f86b..1191446 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -246,6 +246,16 @@ config EP93XX_PWM
To compile this driver as a module, choose M here: the module will
be called ep93xx_pwm.
+config TI_DAC7512
+ tristate "Texas Instruments DAC7512"
+ depends on SPI && SYSFS
+ help
+ If you say yes here you get support for the Texas Instruments
+ DAC7512 16-bit digital-to-analog converter.
+
+ This driver can also be built as a module. If so, the module
+ will be calles ti_dac7512.
+
source "drivers/misc/c2port/Kconfig"
source "drivers/misc/eeprom/Kconfig"
source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index f982d2e..d59830e 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_SGI_GRU) += sgi-gru/
obj-$(CONFIG_HP_ILO) += hpilo.o
obj-$(CONFIG_ISL29003) += isl29003.o
obj-$(CONFIG_EP93XX_PWM) += ep93xx_pwm.o
+obj-$(CONFIG_TI_DAC7512) += ti_dac7512.o
obj-$(CONFIG_C2PORT) += c2port/
obj-y += eeprom/
obj-y += cb710/
diff --git a/drivers/misc/ti_dac7512.c b/drivers/misc/ti_dac7512.c
new file mode 100644
index 000..d3f229a
--- /dev/null
+++ b/drivers/misc/ti_dac7512.c
@@ -0,0 +1,101 @@
+/*
+ * dac7512.c - Linux kernel module for
+ * Texas Instruments DAC7512
+ *
+ * Copyright (c) 2009 Daniel Mack
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include
+#include
+#include
+
+#define DAC7512_DRV_NAME "dac7512"
+#define DRIVER_VERSION "1.0"
+
+static ssize_t dac7512_store_val(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct spi_device *spi = to_spi_device(dev);
+ unsigned char tmp[2];
+
[spi-devel-general] [PATCH] SPI: drain MXC SPI transfer buffer when probing device
On the MX31litekit, the bootloader seems to communicate with the MC13783 PMIC chip before booting Linux. However, it does not flush all the buffers properly after that, which makes the imx-spi driver read bogus data when probing the MC13783. Fix that by draining the SPI buffer on startup. Signed-off-by: Daniel Mack Cc: David Brownell Cc: Andrew Morton Cc: Sascha Hauer Cc: Uwe Kleine-König Cc: spi-devel-general@lists.sourceforge.net --- drivers/spi/spi_imx.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/drivers/spi/spi_imx.c b/drivers/spi/spi_imx.c index 89c22ef..a3894fd 100644 --- a/drivers/spi/spi_imx.c +++ b/drivers/spi/spi_imx.c @@ -42,8 +42,11 @@ #define MXC_CSPITXDATA 0x04 #define MXC_CSPICTRL 0x08 #define MXC_CSPIINT0x0c +#define MXC_CSPISTAT 0x14 #define MXC_RESET 0x1c +#define MXC_CSPISTAT_RR(1 << 3) + /* generic defines to abstract from the different register layouts */ #define MXC_INT_RR (1 << 0) /* Receive data ready interrupt */ #define MXC_INT_TE (1 << 1) /* Transmit FIFO empty interrupt */ @@ -593,6 +596,10 @@ static int __init spi_imx_probe(struct platform_device *pdev) if (!cpu_is_mx31() || !cpu_is_mx35()) writel(1, spi_imx->base + MXC_RESET); + /* drain the buffer */ + while (readl(spi_imx->base + MXC_CSPISTAT) & MXC_CSPISTAT_RR) + readl(spi_imx->base + MXC_CSPIRXDATA); + spi_imx->intctrl(spi_imx, 0); ret = spi_bitbang_start(&spi_imx->bitbang); -- 1.6.5.2 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [spi-devel-general] [PATCH] SPI: drain MXC SPI transfer buffer when probing device
Hi Uwe, On Thu, Nov 19, 2009 at 07:49:51PM +0100, Uwe Kleine-König wrote: > On Thu, Nov 19, 2009 at 11:44:47AM +0100, Daniel Mack wrote: > > On the MX31litekit, the bootloader seems to communicate with the MC13783 > > PMIC chip before booting Linux. However, it does not flush all the > > buffers properly after that, which makes the imx-spi driver read > > bogus data when probing the MC13783. > > > > Fix that by draining the SPI buffer on startup. > > > > Signed-off-by: Daniel Mack > > Cc: David Brownell > > Cc: Andrew Morton > > Cc: Sascha Hauer > > Cc: Uwe Kleine-König > > Cc: spi-devel-general@lists.sourceforge.net > > --- > > drivers/spi/spi_imx.c |7 +++ > > 1 files changed, 7 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/spi/spi_imx.c b/drivers/spi/spi_imx.c > > index 89c22ef..a3894fd 100644 > > --- a/drivers/spi/spi_imx.c > > +++ b/drivers/spi/spi_imx.c > > @@ -42,8 +42,11 @@ > > #define MXC_CSPITXDATA 0x04 > > #define MXC_CSPICTRL 0x08 > > #define MXC_CSPIINT0x0c > > +#define MXC_CSPISTAT 0x14 > On imx27 the register at offset 0x14 is called PERIODREG ... > > > #define MXC_RESET 0x1c > > > > +#define MXC_CSPISTAT_RR(1 << 3) > ... and bits 0..14 are called WAIT. > > > > + > > /* generic defines to abstract from the different register layouts */ > > #define MXC_INT_RR (1 << 0) /* Receive data ready interrupt */ > > #define MXC_INT_TE (1 << 1) /* Transmit FIFO empty interrupt */ > > @@ -593,6 +596,10 @@ static int __init spi_imx_probe(struct platform_device > > *pdev) > > if (!cpu_is_mx31() || !cpu_is_mx35()) > > writel(1, spi_imx->base + MXC_RESET); > > > > + /* drain the buffer */ > > + while (readl(spi_imx->base + MXC_CSPISTAT) & MXC_CSPISTAT_RR) > > + readl(spi_imx->base + MXC_CSPIRXDATA); > > + > So this needs protection by > > if (cpu_is_mx31() || cpu_is_mx35()) Oh, I wasn't aware of such differences, thanks for checking! > (note, I didn't check the mx35 reference!). But I did now, and mx35 seems to be compatible. I also changed the register define names to avoid confusion. New patch below. Thanks, Daniel >From 965180664e33f972409fb8ae00372902406c1c22 Mon Sep 17 00:00:00 2001 From: Daniel Mack Date: Thu, 19 Nov 2009 11:39:45 +0100 Subject: [PATCH] SPI: drain MXC SPI transfer buffer when probing device MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On the MX31litekit, the bootloader seems to communicate with the MC13783 PMIC chip before booting Linux. However, it does not flush all the buffers properly after that, which makes the imx-spi driver read bogus data when probing the MC13783. Fix that by draining the SPI receive buffer on startup. Signed-off-by: Daniel Mack Cc: David Brownell Cc: Andrew Morton Cc: Sascha Hauer Cc: Uwe Kleine-König Cc: spi-devel-general@lists.sourceforge.net --- drivers/spi/spi_imx.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/spi/spi_imx.c b/drivers/spi/spi_imx.c index 89c22ef..1b17f44 100644 --- a/drivers/spi/spi_imx.c +++ b/drivers/spi/spi_imx.c @@ -44,6 +44,9 @@ #define MXC_CSPIINT0x0c #define MXC_RESET 0x1c +#define MX3_CSPISTAT 0x14 +#define MX3_CSPISTAT_RR(1 << 3) + /* generic defines to abstract from the different register layouts */ #define MXC_INT_RR (1 << 0) /* Receive data ready interrupt */ #define MXC_INT_TE (1 << 1) /* Transmit FIFO empty interrupt */ @@ -593,6 +596,11 @@ static int __init spi_imx_probe(struct platform_device *pdev) if (!cpu_is_mx31() || !cpu_is_mx35()) writel(1, spi_imx->base + MXC_RESET); + /* drain receive buffer */ + if (cpu_is_mx31() || cpu_is_mx35()) + while (readl(spi_imx->base + MX3_CSPISTAT) & MX3_CSPISTAT_RR) + readl(spi_imx->base + MXC_CSPIRXDATA); + spi_imx->intctrl(spi_imx, 0); ret = spi_bitbang_start(&spi_imx->bitbang); -- 1.6.5.2 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
