[PATCH 2/2] ARM: u300: switch SSP/SPI clock name to "SSPCLK"
As noted in recent discussions the name of the core clock for the PL022 derived SPI blocks is erroneously named in the U300 device tree. The kernel doesn't currently use the name, but may do so soon so let use rename all these clocks in accordance with the name given in the PL022 TRM (ARM DDI 0194G). Signed-off-by: Linus Walleij --- arch/arm/boot/dts/ste-u300.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/ste-u300.dts b/arch/arm/boot/dts/ste-u300.dts index a9da4800daf0..6fe688e9e4da 100644 --- a/arch/arm/boot/dts/ste-u300.dts +++ b/arch/arm/boot/dts/ste-u300.dts @@ -457,7 +457,7 @@ interrupt-parent = <&vica>; interrupts = <23>; clocks = <&spi_clk>, <&spi_clk>; - clock-names = "apb_pclk", "spi_clk"; + clock-names = "SSPCLK", "apb_pclk"; dmas = <&dmac 27 &dmac 28>; dma-names = "tx", "rx"; num-cs = <3>; -- 1.8.5.3 -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 1/2] ARM: ux500: switch SSP/SPI clock name to "SSPCLK"
As noted in recent discussions the name of the core clock for the PL022 derived SPI blocks is erroneously named in the Ux500 device trees. The kernel doesn't currently use the name, but may do so soon so let use rename all these clocks in accordance with the name given in the PL022 TRM (ARM DDI 0194G). Signed-off-by: Linus Walleij --- arch/arm/boot/dts/ste-dbx5x0.dtsi | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm/boot/dts/ste-dbx5x0.dtsi b/arch/arm/boot/dts/ste-dbx5x0.dtsi index e0853ea02df2..e41eedca3ce3 100644 --- a/arch/arm/boot/dts/ste-dbx5x0.dtsi +++ b/arch/arm/boot/dts/ste-dbx5x0.dtsi @@ -705,7 +705,7 @@ #address-cells = <1>; #size-cells = <0>; clocks = <&prcc_kclk 3 1>, <&prcc_pclk 3 1>; - clock-names = "ssp0clk", "apb_pclk"; + clock-names = "SSPCLK", "apb_pclk"; dmas = <&dma 8 0 0x2>, /* Logical - DevToMem */ <&dma 8 0 0x0>; /* Logical - MemToDev */ dma-names = "rx", "tx"; @@ -718,7 +718,7 @@ #address-cells = <1>; #size-cells = <0>; clocks = <&prcc_kclk 3 2>, <&prcc_pclk 3 2>; - clock-names = "ssp1clk", "apb_pclk"; + clock-names = "SSPCLK", "apb_pclk"; dmas = <&dma 9 0 0x2>, /* Logical - DevToMem */ <&dma 9 0 0x0>; /* Logical - MemToDev */ dma-names = "rx", "tx"; @@ -732,7 +732,7 @@ #size-cells = <0>; /* Same clock wired to kernel and pclk */ clocks = <&prcc_pclk 2 8>, <&prcc_pclk 2 8>; - clock-names = "spi0clk", "apb_pclk"; + clock-names = "SSPCLK", "apb_pclk"; dmas = <&dma 0 0 0x2>, /* Logical - DevToMem */ <&dma 0 0 0x0>; /* Logical - MemToDev */ dma-names = "rx", "tx"; @@ -746,7 +746,7 @@ #size-cells = <0>; /* Same clock wired to kernel and pclk */ clocks = <&prcc_pclk 2 2>, <&prcc_pclk 2 2>; - clock-names = "spi1clk", "apb_pclk"; + clock-names = "SSPCLK", "apb_pclk"; dmas = <&dma 35 0 0x2>, /* Logical - DevToMem */ <&dma 35 0 0x0>; /* Logical - MemToDev */ dma-names = "rx", "tx"; @@ -760,7 +760,7 @@ #size-cells = <0>; /* Same clock wired to kernel and pclk */ clocks = <&prcc_pclk 2 1>, <&prcc_pclk 2 1>; - clock-names = "spi2clk", "apb_pclk"; + clock-names = "SSPCLK", "apb_pclk"; dmas = <&dma 33 0 0x2>, /* Logical - DevToMem */ <&dma 33 0 0x0>; /* Logical - MemToDev */ dma-names = "rx", "tx"; @@ -774,7 +774,7 @@ #size-cells = <0>; /* Same clock wired to kernel and pclk */ clocks = <&prcc_pclk 1 7>, <&prcc_pclk 1 7>; - clock-names = "spi3clk", "apb_pclk"; + clock-names = "SSPCLK", "apb_pclk"; dmas = <&dma 40 0 0x2>, /* Logical - DevToMem */ <&dma 40 0 0x0>; /* Logical - MemToDev */ dma-names = "rx", "tx"; -- 1.8.5.3 -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: Depreciated spi_master.transfer and "prepared spi messages" for an optimized pipelined-SPI-DMA-driver
On Mon, Oct 28, 2013 at 11:42 AM, Martin Sperl wrote: > (... ) I thought of moving away from spi_transfer_one_message and back to > the simpler transfer interface, where the preprocessing would get done > (DMA control block-chain generation) and then appending it to the > existing (possibly running) DMA chain. OK quite a cool idea. But I hope that you have the necessary infrastructure using the dmaengine subsystem for this, or that changes requires will be proposed to that first or together with these changes. As you will be using dmaengine (I guess?) maybe a lot of this can actually be handled directly in the core since that code should be pretty generic, or in a separate file like spi-dmaengine-chain.c? > But just yesterday I was looking thru the code and came to the message: > "master is unqueued, this is depreciated" (drivers/spi/spi.c Line 1167). > This came in with commit ffbbdd21329f3e15eeca6df2d4bc11c04d9d91c0 and got > included in 3.4. > > So I am wondering why you would depreciate this interface Simply because none of the in-kernel users was doing what you are trying to do now. And noone said anything about such future usecases, so how could we know? > Now this brings me to different question: > Could we implement some additional "functions" for preparing > an SPI message (...) > The interface could looks something like this: > int spi_prepare_message(struct_spi_dev*, struct spi_message *); > int spi_unprepare_message(struct_spi_dev*, struct spi_message *); Maybe? I cannot tell from the above how this would look so I think it is better if you send a patch showing how this improves efficiency. Yours, Linus Walleij -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 20/23] ARM: u300: add SPI PL022 to the device tree
From: Linus Walleij
This registers the PL022 PrimeCell from the U300 device
tree. We make a new copy of the platform data for the
device tree boot path, as the old platform data is in an
older file which will be going away.
Signed-off-by: Linus Walleij
---
arch/arm/boot/dts/ste-u300.dts | 7 +++
arch/arm/mach-u300/core.c | 19 +++
2 files changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/ste-u300.dts b/arch/arm/boot/dts/ste-u300.dts
index cdffeb9..979d96c 100644
--- a/arch/arm/boot/dts/ste-u300.dts
+++ b/arch/arm/boot/dts/ste-u300.dts
@@ -214,5 +214,12 @@
cd-inverted;
vmmc-supply = <&ab3100_ldo_g_reg>;
};
+
+ spi: ssp@c0006000 {
+ compatible = "arm,pl022", "arm,primecell";
+ reg = <0xc0006000 0x1000>;
+ interrupt-parent = <&vica>;
+ interrupts = <23>;
+ };
};
};
diff --git a/arch/arm/mach-u300/core.c b/arch/arm/mach-u300/core.c
index 98d4dbe..9467ffe 100644
--- a/arch/arm/mach-u300/core.c
+++ b/arch/arm/mach-u300/core.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -703,6 +704,22 @@ MACHINE_END
#ifdef CONFIG_OF
+static struct pl022_ssp_controller spi_plat_data = {
+ /* If you have several SPI buses this varies, we have only bus 0 */
+ .bus_id = 0,
+ /*
+* On the APP CPU GPIO 4, 5 and 6 are connected as generic
+* chip selects for SPI. (Same on U330, U335 and U365.)
+* TODO: make sure the GPIO driver can select these properly
+* and do padmuxing accordingly too.
+*/
+ .num_chipselect = 3,
+ .enable_dma = 1,
+ .dma_filter = coh901318_filter_id,
+ .dma_rx_param = (void *) U300_DMA_SPI_RX,
+ .dma_tx_param = (void *) U300_DMA_SPI_TX,
+};
+
/* These are mostly to get the right device names for the clock lookups */
static struct of_dev_auxdata u300_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("stericsson,pinctrl-u300", U300_SYSCON_BASE,
@@ -719,6 +736,8 @@ static struct of_dev_auxdata u300_auxdata_lookup[]
__initdata = {
"uart0", &uart0_plat_data),
OF_DEV_AUXDATA("arm,primecell", U300_UART1_BASE,
"uart1", &uart1_plat_data),
+ OF_DEV_AUXDATA("arm,primecell", U300_SPI_BASE,
+ "pl022", &spi_plat_data),
OF_DEV_AUXDATA("st,ddci2c", U300_I2C0_BASE,
"stu300.0", NULL),
OF_DEV_AUXDATA("st,ddci2c", U300_I2C1_BASE,
--
1.7.11.3
--
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
[PATCH 21/23] ARM: u300: probe the U300 dummy-spichip from device tree
From: Linus Walleij
This probes the U300 dummy-spichip from the device tree
and adds the apropriate node to the tree.
Signed-off-by: Linus Walleij
---
arch/arm/boot/dts/ste-u300.dts| 5 +
arch/arm/mach-u300/dummyspichip.c | 6 ++
2 files changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/ste-u300.dts b/arch/arm/boot/dts/ste-u300.dts
index 979d96c..9a163e1 100644
--- a/arch/arm/boot/dts/ste-u300.dts
+++ b/arch/arm/boot/dts/ste-u300.dts
@@ -220,6 +220,11 @@
reg = <0xc0006000 0x1000>;
interrupt-parent = <&vica>;
interrupts = <23>;
+ spi-dummy@1 {
+ compatible = "arm,pl022-dummy";
+ reg = <1>;
+ spi-max-frequency = <2000>;
+ };
};
};
};
diff --git a/arch/arm/mach-u300/dummyspichip.c
b/arch/arm/mach-u300/dummyspichip.c
index 2785cb6..52962bf 100644
--- a/arch/arm/mach-u300/dummyspichip.c
+++ b/arch/arm/mach-u300/dummyspichip.c
@@ -263,10 +263,16 @@ static int pl022_dummy_remove(struct spi_device *spi)
return 0;
}
+static const struct of_device_id pl022_dummy_dt_match[] = {
+ { .compatible = "arm,pl022-dummy" },
+ {},
+};
+
static struct spi_driver pl022_dummy_driver = {
.driver = {
.name = "spi-dummy",
.owner = THIS_MODULE,
+ .of_match_table = pl022_dummy_dt_match,
},
.probe = pl022_dummy_probe,
.remove = pl022_dummy_remove,
--
1.7.11.3
--
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: s3c64xx: let device core setup the default pin configuration
On Mon, Apr 15, 2013 at 7:23 PM, Doug Anderson wrote: > Mark, (...) > Is this something you would pick up? It looks like you weren't copied > on the original email thread, unfortunately. Resend the patch with collected ACKs and Mark+Grant explitly on the To: line and I think it'll be picked up. Yours, Linus Walleij -- 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 v4] gpio: mcp23s08: convert driver to DT
On Thu, Apr 4, 2013 at 12:02 PM, Lars Poeschel wrote: > From: Lars Poeschel > > This converts the mcp23s08 driver to be able to be used with device > tree. > There is a "spi-present-mask" device tree property, that allows to > use multiple of this spi chips on the same chipselect. > > Signed-off-by: Lars Poeschel > --- > v4: > - removed the ability to specify the pullup from device tree > - updated binding doc Patch applied! Thanks, Linus Walleij -- 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 v4] gpio: mcp23s08: convert driver to DT
On Thu, Apr 4, 2013 at 12:02 PM, Lars Poeschel wrote:
> From: Lars Poeschel
>
> This converts the mcp23s08 driver to be able to be used with device
> tree.
> There is a "spi-present-mask" device tree property, that allows to
> use multiple of this spi chips on the same chipselect.
>
> Signed-off-by: Lars Poeschel
> ---
> v4:
> - removed the ability to specify the pullup from device tree
> - updated binding doc
(...)
> @@ -668,6 +742,7 @@ static struct spi_driver mcp23s08_driver = {
> .driver = {
> .name = "mcp23s08",
> .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(mcp23s08_spi_of_match),
Will this compile if CONFIG_OF is not enabled?
Yours,
Linus Walleij
--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire
the most talented Cisco Certified professionals. Visit the
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v3] gpio: mcp23s08: convert driver to DT
On Wed, Mar 27, 2013 at 12:35 PM, Lars Poeschel wrote: > On Friday 22 March 2013 at 09:33:10, Linus Walleij wrote: >> I would currently feel a lot better if you did not include this >> flag. How would you control this the day drivers need to >> enable/disable pull-up at runtime? > > For me it would also be easier to remove the flag (for DT boot case). I don't > need the pullups. I did only include it, because this is how the driver is > designed to work and what it did already. What I wanted was to make a good > transfer from what the features of the driver are and how it works to be able > to use it with device tree. If it now turns out that's bad for some reason, I > have no problem to remove this from the patch completely. > You're right: Runtime config is not possible this way. > What should I do now ? Remove it ? Remove. The less complicated binding, the better. >> > +- gpio-controller : Marks the device node as a GPIO controller. >> > +- reg : For an address on its bus >> >> On the I2C/SPI bus? > > Yes, both. For I2C it's the I2C address, for SPI it's the chip select to use > for this chip. OK please write these specifics in the binding doc. >> Please state here what kind of buses it can be. Explain if multiple >> buses are supported. > > Ok, I will add a line about it. Thx. >> > +Required device specific properties (only for SPI chips): >> > +- mcp,spi-present-mask : This is a present flag, that makes only sense >> > for SPI +chips - as the name suggests. >> >> AFAIK this is not how we disable/enable devices in the device tree. >> >> Istead we include a property on the node called "status" and set it >> to "disabled" if the device is not there. > > This would require multiple instances with the same reg property as up to 8 > chips can live on the same chip select. I wonder if this is possible ? If there is not one instance/device node per chip things are very wrong anyway. Maybe I don't understand fully... each device on the system should have a node, you can't have a node spanning several devices unless it's a bus node. > Grant had the idea with the bitfield. You have the reg property specifying > the chip select line. This bitfield is then used to indicate which of the 8 > possible chips on this same chip select line is really present. Not beeing > able to support more than 8 devices is not problem, because it is a hardware > limitation, that not more than 8 devices can share the same SPI chip select. > This is again how the driver worked so far. > >> What about just using a number? > > This would again require multiple instances with the same reg property for > SPI. Is this really possible ? If Grant is OK with this then so am I, he surely know this better than me. But you nee to trick him to come out and review it. Yours, Linus Walleij -- Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v3] gpio: mcp23s08: convert driver to DT
Hi Lars,
sorry for taking eternities to review stuff :-(
I recommend that you include SPI co-maintainer Mark Brown on subsequent
postings.
On Mon, Mar 4, 2013 at 5:34 PM, Lars Poeschel wrote:
> This converts the mcp23s08 driver to be able to be used with device
> tree.
OK!
> +++ b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
> @@ -0,0 +1,43 @@
> +Microchip MCP2308/MCP23S08/MCP23017/MCP23S17 driver for
> +8-/16-bit I/O expander with serial interface (I2C/SPI)
> +
> +Required properties:
> +- compatible : Should be
> +- "mcp,mcp23s08" for 8 GPIO SPI version
> +- "mcp,mcp23s17" for 16 GPIO SPI version
> +- "mcp,mcp23008" for 8 GPIO I2C version or
> +- "mcp,mcp23017" for 16 GPIO I2C version of the chip
> +- #gpio-cells : Should be two.
> + - first cell is the pin number
> + - second cell is used to specify flags. Flags currently used:
> +bit0 : activate a ~100k pullup
Pullup is basically about pin config. This is sort of sneaking
behind the subsystems, but I know I might be overzealous.
Can the electronics do more things than pull-up?
Like pull-down, open drain, drive strength...
If it's a lot it's better to consider pinctrl from the start.
I'm saying this because the DT bindings will be maintained
perpetually and need to set a good example.
I would currently feel a lot better if you did not include this
flag. How would you control this the day drivers need to
enable/disable pull-up at runtime?
> +- gpio-controller : Marks the device node as a GPIO controller.
> +- reg : For an address on its bus
On the I2C/SPI bus?
Please state here what kind of buses it can be. Explain if multiple
buses are supported.
> +Required device specific properties (only for SPI chips):
> +- mcp,spi-present-mask : This is a present flag, that makes only sense for
> SPI
> +chips - as the name suggests.
AFAIK this is not how we disable/enable devices in the device tree.
Istead we include a property on the node called "status" and set it
to "disabled" if the device is not there.
> +Multiple chips can share the same
> +SPI chipselect. Set bit 0-7 in this mask to 1 if there is a chip
> +connected with this spi address. If you have a chip with address 3
> +connected, you have to set bit3 to 1, which is 0x08. mcp23s08 only
> +supports bits 0-3. It is not possible to mix mcp23s08 and mcp23s17
> +on the same chipselect. Set at least one bit to 1 for SPI chips.
This looks awkward, why are you using a bitfield for this? Then you
can only ever support 8 devices, since the text also implies that the
value is 8bit (this should be stated).
What about just using a number?
> diff --git a/drivers/gpio/gpio-mcp23s08.c b/drivers/gpio/gpio-mcp23s08.c
> index 3cea0ea..a8ca469 100644
> --- a/drivers/gpio/gpio-mcp23s08.c
> +++ b/drivers/gpio/gpio-mcp23s08.c
> @@ -12,6 +12,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> /**
> * MCP types supported by driver
> @@ -21,6 +23,11 @@
> #define MCP_TYPE_008 2
> #define MCP_TYPE_017 3
>
> +/**
> + * Flags used in device tree
> + */
> +#define MCP_DT_FLAG_PULLUP 0x01
So I'm sceptical here. Is this already supported using platform data?
> /* Registers are all 8 bits wide.
> *
> * The mcp23s17 has twice as many bits, and can be configured to work
> @@ -75,6 +82,25 @@ struct mcp23s08_driver_data {
> struct mcp23s08 chip[];
> };
>
> +#ifdef CONFIG_OF
> +static int mcp23s08_of_xlate(struct gpio_chip *gc,
> + const struct of_phandle_args *gpiospec, u32 *flags);
> +
> +static int mcp23s08_set_pullup(struct mcp23s08 *mcp, unsigned offset)
> +{
> + int status;
> + u16 value;
> +
> + mutex_lock(&mcp->lock);
> + value = mcp->cache[MCP_GPPU] | (1 << offset);
> + status = mcp->ops->write(mcp, MCP_GPPU, value);
> + if (!status)
> + mcp->cache[MCP_GPPU] = value;
> + mutex_unlock(&mcp->lock);
> +
> + return status;
> +}
The pull-up business actually looks like new functionality that
has nothing to do with adding device tree support and should be
a separate patch.
Yours,
Linus Walleij
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] spi: s3c64xx: let device core setup the default pin configuration
On Wed, Mar 6, 2013 at 12:42 PM, Thomas Abraham wrote: > With device core now able to setup the default pin configuration, > the pin configuration code based on the deprecated Samsung specific > gpio bindings is removed. > > Signed-off-by: Thomas Abraham Acked-by: Linus Walleij Yours, Linus Walleij -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v2] gpio: mcp23s08: convert driver to DT
On Thu, Feb 14, 2013 at 1:22 PM, Lars Poeschel wrote: > On Wednesday 13 February 2013 at 13:51:12, Linus Walleij wrote: >> Have you considered this [pinctrl] approach? > > No, I haven't. And although this doesn't solve all my problems, I like the > idea very much! Thank you for this! But at the moment it looks to me that > this could be a bit overkill for setting this single register and I don't > think this is, what Grant meant me to do. So there is this corner case where some GPIO driver does some pinctrl business, I mean, really really little of it. And then it may be overkill. Sometimes though, the hardware actually can do a lot of this biasing and muxing it just wasn't part of the driver yet or done in e.g. boot loaders, and then it's usually better to use pinctrl. Adding custom APIs to the GPIO drivers will however always cause a maintenance burden on the GPIO maintainers, so that's why pinctrl & GPIO is nice. I don't know which case this would be though. Yours, Linus Walleij -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v2] gpio: mcp23s08: convert driver to DT
On Wed, Feb 13, 2013 at 12:13 PM, Lars Poeschel wrote: > On Monday 11 February 2013 at 22:25:51, Grant Likely wrote: >> >> However, is the pullup selection per-gpio line? If so, then why not >> encode it into the flags field of the gpio specifier? > > Yes, the pullup is per-gpio line. I am working on that. It turns out, that > this is a bit difficult for me, as there is no real documentation and no > other driver is doing it or something similar yet. Exception are very few > gpio soc drivers where situation is a bit different. They seem to rely an > fixed global gpio numbers and they are always memory mapped. > But as I said I am working on it... Part of your problem is that pull-up is pin control territory. We invented that subsystem for a reason, and that reason was that the GPIO subsystem had a hard time accomodating things like this. If you look in drivers/pinctrl/pinctrl-abx500.c which is my latest submitted pinctrl driver you can see that this is basically a quite simple GPIO chip, we just model it as a pin controller with a GPIO front-end too exactly because it can do things like multiplexing, pull-up and pull-down. Have you considered this approach? Yours, Linus Walleij -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 2/5] spi: pl022: use generic DMA slave configuration if possible
On Fri, Feb 8, 2013 at 5:28 PM, Arnd Bergmann wrote: > On Friday 08 February 2013 16:22:48 Russell King - ARM Linux wrote: >> If it's DMA _to_ a device, then we will only ever clean the lines prior to >> a transfer, never invalidate them. So that's not really a concern. (There >> better not be any dirty cache lines associated with the empty zero page >> either.) > > Right, makes sense. I thought I had read about a CPU that > could not flush a cache line without also invalidating > it, but that must have been something other than ARM, > or maybe I'm misremembering it. I don't think it matters one bit. The page can contain a bitmap of Donald Duck or zero FWIW. It's just that the DMA controller just neeeds to read *something* that does not cause a bus stall. It's due to the syncronous nature of the SPI protocol, to get something out you need to put something in. So when reading, this is a way to feed in some junk. So this goes on my TODO... Yours, Linus Walleij -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 2/5] spi: pl022: use generic DMA slave configuration if possible
On Thu, Feb 7, 2013 at 8:42 PM, Arnd Bergmann wrote: > On Thursday 07 February 2013, Linus Walleij wrote: >> Actually I once read about a feature where the kernel provides >> a static page full of zeroes or something like this, that would be >> ideal to use in cases like this, then all of this dummy page >> allocation and freeing can be deleted. > > You mean empty_zero_page? That only works if this page is > read-only from the perspective of the DMA controller, but > then it would be a good fit, yes. That's actually how it's used. SPI is symmetric, and in the DMA case we're not poking data into the buffers from the CPU so the controller need something - anything - to stream to the block. If we can use that page we'll even save a few remaps. Yours, Linus Walleij -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 2/5] spi: pl022: use generic DMA slave configuration if possible
On Tue, Jan 29, 2013 at 2:13 PM, Arnd Bergmann wrote: > On Tuesday 29 January 2013, Andy Shevchenko wrote: >> > + pl022->dummypage = kmalloc(PAGE_SIZE, GFP_KERNEL); >> >> Where this memory will be freed? >> In dependence of the answer could you consider to use >> devm_kmalloc or __get_free_page? > > There is another function like this called pl022_dma_probe() > that has the same allocation, and it gets freed in the same place. > > It's probably worth changing this into something different, but > I felt that it didn't belong into this patch. I was also not > sure if the best option would be dmam_alloc_coherent, dev_kzalloc, > or __get_free_page. Actually I once read about a feature where the kernel provides a static page full of zeroes or something like this, that would be ideal to use in cases like this, then all of this dummy page allocation and freeing can be deleted. Yours, Linus Walleij -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 2/5] spi: pl022: use generic DMA slave configuration if possible
On Mon, Jan 28, 2013 at 6:57 PM, Arnd Bergmann wrote: > With the new OF DMA binding, it is possible to completely avoid the > need for platform_data for configuring a DMA channel. In cases where the > platform has already been converted, calling dma_request_slave_channel > should get all the necessary information from the device tree. > > Like the patch that converts the dw_dma controller, this is completely > untested and is looking for someone to try it out. > > Signed-off-by: Arnd Bergmann This looks correct to me atleast: Acked-by: Linus Walleij Yours, Linus Walleij -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH RFC 1/1] gpio: mcp23s08: convert driver to DT
On Wed, Feb 6, 2013 at 10:31 AM, Lars Poeschel wrote: > The thing that confused me was, that the platform_data for the chip has a > mandatory "base" member, that sets the linux global gpio number at which the > chip should appear. Yes this is common. I think you should look at other drivers under drivers/gpio using device tree, and how they work around this. As stated, as a last resort you can use AUXDATA to anyway assign a piece of platform data per instance. In the Nomadik driver, we use the block instance ID and multiply by a factor of the numbers of GPIOs on each instance. And luckily the base is zero. Not elegant maybe, but the global GPIO numberspace is not elegant by nature. Yours, Linus Walleij -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Tue, Feb 5, 2013 at 6:14 PM, Russell King - ARM Linux wrote: > On Tue, Feb 05, 2013 at 04:30:45PM +0100, Linus Walleij wrote: >> So put them on a wait list? Surely you will have a list of pending >> cookies and pick from the front of the queue if there isn't a hole on >> queue position 0. > > Not quite. The key is the cookie system DMA engine employs to indicate > when a cookie is complete. > > Cookies between the "issued sequence" and "completed sequence" are defined > to be in progress, everything else is defined to be completed. > > This means that if "completed sequence" is 1, and "issued sequence" is 5, > then cookies with values 2, 3, 4, 5 are in progress. You can't mark > sequence 4 as being complete until 2 and 3 have completed. Yes that is true. DMA transfers on a certain channel are defined as progressing linearly per-cookie. I wonder if that is a problem in this case though (actually it seems the reverse, this helps in Cyril's case.) > If we need out-of-order completion, then that's a problem for the DMA > engine API, because you'd need to radically change the way "completion" > is marked. True. I wonder if this usecase is ever going to be applicable however. It could maybe be useful in some instances of memcpy() I could dream up, whereas for device transfers it seems unlikely to me. Yours, Linus Walleij -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Tue, Feb 5, 2013 at 5:47 PM, Mark Brown wrote: > On Tue, Feb 05, 2013 at 05:21:48PM +0100, Linus Walleij wrote: > >> For IRQ mode, use the completion callback to push each cookie >> to NAPI, and thus let the IRQ drive the traffic. > > The whole purpose of NAPI is to avoid taking interrupts for completion > of transfers. Anything that generates interrupts when NAPI is in > polling mode is defeating the point. So what I was trying to get across is that when you're in polling mode you do not set DMA_PREP_INTERRUPT on your transfers, just throw the obtained struct dma_async_tx_descriptor on some list and then when polling use dma_async_is_tx_complete() on the channel and the cookie inside the descriptor. I was trying to describe that you can move from IRQ mode to polling mode and back again by selectively choosing to set/not set the DMA_PREP_INTERRUPT flag. If polling is all you want you never set it. Then there is the fact that the transfer needs to have been flagged complete and it is indeed something that needs to be set in some bytes somewhere. By something. But it doesn't have to be an interrupt from the DMA controller. In such cases we use dma_async_is_tx_complete() with channel and cookies as parameter. This will call down into the driver chan->device->device_tx_status() and there we can actually poll the hardware to see if the transfer happens to be complete, and if it is flag it complete. Which is likely what we want. No interrupts, only function calls as far as I can see. (I bet Russell will poke a hole in my reasoning, but it's worth a try.) Yours, Linus Walleij -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
buffer emtied and then we can decide what to do next. This could just as well have been some API calling in and saying "give me your buffer NOW". I think we need to look at an NAPI driver that does this trick so we understand what you want from the API. Yours, Linus Walleij -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Mon, Feb 4, 2013 at 10:54 PM, Cyril Chemparathy wrote: > On 02/04/2013 04:11 PM, Linus Walleij wrote: >> Cyril, just stack up the cookies and take a sweep over them to see >> which ones are baked when the NAPI poll comes in -> problem >> solved. > > You're assuming that cookies complete in order. That is not necessarily > true. So put them on a wait list? Surely you will have a list of pending cookies and pick from the front of the queue if there isn't a hole on queue position 0. Yours, Linus Walleij -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Mon, Feb 4, 2013 at 9:33 PM, Mark Brown wrote: > On Mon, Feb 04, 2013 at 09:29:46PM +0100, Linus Walleij wrote: >> On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy wrote: > >> > Based on our experience with fitting multiple subsystems on top of this >> > DMA-Engine driver, I must say that the DMA-Engine interface has proven >> > to be a less than ideal fit for the network driver use case. > >> > The first problem is that the DMA-Engine interface expects to "push" >> > completed traffic up into the upper layer as a part of its callback. >> > This doesn't fit cleanly with NAPI, which expects to "pull" completed >> > traffic from below in the NAPI poll. We've somehow kludged together a >> > solution around this, but it isn't very elegant. > >> I cannot understand the actual technical problem from the above >> paragraphs though. dmaengine doesn't have a concept of pushing >> nor polling, it basically copies streams of words from A to B, where >> A/B can be a device or a buffer, nothing else. > >> The thing you're looking for sounds more like an adapter on top >> of dmaengine, which can surely be constructed, some >> drivers/dma/dmaengine-napi.c or whatever. > > Broadly speaking what NAPI wants is to never get any callbacks from the > hardware (or DMAs). It wants to wake up periodically, take a look at > what packets have been read by the hardware and process them. The goal > is to have the DMAs sitting and running without disturbing the processor > at all after the first packet has been handled. OK we should definately be able to encompass that in dmaengine quite easily. So I think the above concerns are moot. The callback we can set on cookies is entirely optional, and it's even implemented by each DMA engine, and some may not even support it but *require* polling, and then it won't even be implemented by the driver. Which probably stems from the original design of the dmaengine API, which was for TCP networking acceleration, mainly. Cyril, just stack up the cookies and take a sweep over them to see which ones are baked when the NAPI poll comes in -> problem solved. Yours, Linus Walleij -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common
On Mon, Feb 4, 2013 at 8:22 PM, Cyril Chemparathy wrote: > Based on our experience with fitting multiple subsystems on top of this > DMA-Engine driver, I must say that the DMA-Engine interface has proven > to be a less than ideal fit for the network driver use case. > > The first problem is that the DMA-Engine interface expects to "push" > completed traffic up into the upper layer as a part of its callback. > This doesn't fit cleanly with NAPI, which expects to "pull" completed > traffic from below in the NAPI poll. We've somehow kludged together a > solution around this, but it isn't very elegant. I cannot understand the actual technical problem from the above paragraphs though. dmaengine doesn't have a concept of pushing nor polling, it basically copies streams of words from A to B, where A/B can be a device or a buffer, nothing else. The thing you're looking for sounds more like an adapter on top of dmaengine, which can surely be constructed, some drivers/dma/dmaengine-napi.c or whatever. > The second problem is one of binding fixed DMA resources to fixed users. > AFAICT, the stock DMA-Engine mechanism works best when one DMA > resource is as good as any other. The filter function picks a channel for whatever reason. That reason can be, well whatever. Some engines have a clever mechanism to select resources on the other end. Then for tying devices to channels we have the dmaengine DT branch: http://git.infradead.org/users/vkoul/slave-dma.git/shortlog/refs/heads/topic/dmaengine_dt This stuff didn't go into v3.8 but you can *sure* expect it to be in v3.9. Or are you referring to a multi-engine scenario? Say if there is engine A and B and depending on circumstances A or B may be preferred in some order (and permutations of this problem). That is currently identified as a shortcoming that we need help to address. > To get over this problem, we've added > support for named channels, and drivers specifically request for a DMA > resource by name. Again, this is less than ideal. Jon Hunter has been working on a mechanism to look up DMA channels from struct device *, dev_name() or a device tree node for example. Just like we do with clocks or regulators. Look at this patch from the dmaengine_dt branch: http://git.infradead.org/users/vkoul/slave-dma.git/commitdiff/528499a7037ebec0636d928f88cd783c618df3c5 Looks up an optionally named channel for a certain device. It currently only supports device tree, but you are free to patch in whatever mechanism you need there. Static tables in platform data works too. Just nobody did it. So go ahead and hack on dma_request_slave_channel(). (I would just branch of the DT branch.) > We found that virtio devices offer a more elegant solution to this > problem. First, the virtqueue interface is a much better fit into NAPI > (callback --> napi schedule, napi poll --> get_buf), and this eliminates > the need for aforementioned kludges in the code. Second, the virtio > device infrastructure nicely uses the device model to solve the problem > of binding DMA users to specific DMA resources. Not that I understand the polling issue, but it sounds to me like what Jon is doing is similar. Surely the way to look up resources cannot be paramount in this discussion, I think the real problem must be your specific networking usecase, so we need to drill into that. Yours, Linus Walleij -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v2 2/6] of: Return -ENXIO from of_parse_phandle_with_args for too large index and return errors from of_gpio_named_count
On Tue, Jan 29, 2013 at 3:53 PM, Andreas Larsson wrote: > This lets of_gpio_named_count return an errno on errors by being able to > distinguish between reaching the end of the phandle list and getting some > other > error from of_parse_phandle_with_args. > > Return error from of_spi_register_master when there is an "cs-gpios" list for > which gp_gpio_named_count fails. > > Adjust various drivers cope with error return from of_gpio_named_count, > including via of_gpio_count. > > Signed-off-by: Andreas Larsson > --- > Changes since v1: > - Handle error return values from calls to of_gpio_count Looks correct to me, but I'm no DT-ninja. For the GPIO portions: Acked-by: Linus Walleij Yours, Linus Walleij -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH RFC 1/1] gpio: mcp23s08: convert driver to DT
On Thu, Jan 31, 2013 at 4:58 PM, Lars Poeschel wrote: > --- /dev/null > +++ b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt > @@ -0,0 +1,27 @@ > +Microchip MCP2308/MCP23S08/MCP23017/MCP23S17 driver for > +8-/16-bit I/O expander with serial interface (I2C/SPI) > + > +Required properties: > +- compatible : Should be "mcp,mcp23s08-gpio", "mcp,mcp23s17-gpio", > + "mcp,mcp23008-gpio" or "mcp,mcp23017-gpio" > +- base : The first gpio number that should be assigned by this chip. No. We do not tie the global GPIO numbers into the device tree. In the DT GPIOs are referenced by ampersand <&gpio0 1 2> notation referring to the instance, so as you realize DT itself has no need for that number. Further it is not OS-neutral. You have to find another way to handle this in the driver code. In worst case: use AUXDATA. Yours, Linus Walleij -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v2 2/2] spi: bitbang: convert to using core message queue
On Wed, Jan 9, 2013 at 3:44 PM, Guennadi Liakhovetski wrote: > [ 79.968000] mmc0: new SD card on SPI > [ 79.976000] mmcblk0: mmc0: SU02G 1.84 GiB > [ 80.024000] mmcblk0: p1 > [ 80.132000] mmcblk0: error -38 sending status command, retrying > [ 80.136000] mmcblk0: error -38 sending status command, retrying > [ 80.14] mmcblk0: error -38 sending status command, aborting > [ 81.028000] mmc0: SPI card removed > [ 81.572000] mmc0: error -110 whilst initialising SD card The queue mechanism has not changed. This *could* be the card itself. So it doesn't appear before the patch? Yours, Linus Walleij -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v2 1/2] spi: bitbang: simplify pointer arithmetics
On Wed, Jan 9, 2013 at 3:08 PM, Guennadi Liakhovetski wrote: > Add a pointer variable to make spi_bitbang_start() look simpler. > > Signed-off-by: Guennadi Liakhovetski Acked-by: Linus Walleij I think Mark Brown is still backing up Grant sometimes, so include him on CC. Yours, Linus Walleij -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] SPI: SSP SPI Controller driver
On Wed, Jan 9, 2013 at 5:25 AM, Vinod Koul wrote: > Also I have some questions on this approach. Is this driver for SSP ip or SPI > ip, looks like latter. In both the cases there are some existing drivers in > kernel and adding one more IMHO doesnt make sense. What we really need a > common core for dw IP and SSP IP (i think pxa uses same stuff). That way lot > of > code will get reduced from driver +1 on this comment, I didn't even notice :-( Linus Walleij -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 3/3] spi: bitbang: convert to using core message queue
On Sat, May 26, 2012 at 1:29 AM, Grant Likely wrote: > On Mon, 21 May 2012 13:25:23 +0200 (CEST), Guennadi Liakhovetski > wrote: >> The SPI subsystem core now manages message queues internally. Remove the >> local message queue implementation from the spi-bitbang driver and >> migrate to the common one. >> >> Signed-off-by: Guennadi Liakhovetski > > Okay, I'm going to be really nitpicky here. The change is fine, but the > diff is too big; particularly for anyone trying to figure out what has > changed if it causes breakage. I wouldn't worry about this as much > for an individual driver, but spi_bitbang is common infrastructure. Did this ever get around to get fixed? I guess not Guennadi, are you going to fix the patch according to Grant's requests or should I try to clean it and resubmit? The problem is that I have no real way of testing this. But if I break something I guess people will notice :-D Yours, Linus Walleij -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] SPI: SSP SPI Controller driver
is this? >> >> Note the comment says "get base address", you're not getting it at >> all, you're hardcoding it. Resources like this should be passed in from >> the outside. >> > > Ok, the address is fixed for current platform, I'll define the address > at beginning and here just refer to the macro, if other platform, this > address should be defined as other value. That really does not answer the question why it is not passed as a resource from the outside. >> > +#define MAX_TRAILING_BYTE_RETRY 16 >> > +#define MAX_TRAILING_BYTE_LOOP 100 >> >> Max iterations? >> >> > +#define DELAY_TO_GET_A_WORD 3 >> > +#define DFLT_TIMEOUT_VAL 500 >> >> milliseconds? > > It depends on peripheral clock frequency. So then write in a comment that it's the number of clock cycles or something? >> > +#define SRAM_BASE_ADDR 0xfffdc000 >> >> Should be passed as resource, se above reasoning for the >> "I2C" base address. What happens on next ASIC spin when >> the engineer move this base offset etc, don't you have any >> system discovery? > > This is fix value for Moorestown & Medfield platforms as what is > declared in the file header. If any hardware change, the address should > be changed accordantly. I don't get it. That's not how we usually do this kind of things. We usually pass it as a resource. Doesn't the Moorestown/Medfield devices have a central resource registry of any kind? We've got all kind of crap for encoding things into the ARM plaforms like this, so let's not repeat that mistake. Yours, Linus Walleij -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] SPI: SSP SPI Controller driver
nsmit */
> +#define SSCR1_TRAIL (1 << 22) /* Trailing Byte */
> +#define SSCR1_TSRE (1 << 21) /* Transmit Service Request Enable */
> +#define SSCR1_RSRE (1 << 20) /* Receive Service Request Enable */
> +#define SSCR1_TINTE (1 << 19) /* Receiver Time-out Interrupt enable */
> +#define SSCR1_PINTE (1 << 18) /* Trailing Byte Interupt Enable */
> +#define SSCR1_STRF (1 << 15) /* Select FIFO or EFWR */
> +#define SSCR1_EFWR (1 << 14) /* Enable FIFO Write/Read */
> +#define SSCR1_IFS(1 << 16) /* Invert Frame Signal */
> +
> +#define SSSR_BCE (1 << 23) /* Bit Count Error */
> +#define SSSR_CSS (1 << 22) /* Clock Synchronisation Status */
> +#define SSSR_TUR (1 << 21) /* Transmit FIFO Under Run */
> +#define SSSR_EOC (1 << 20) /* End Of Chain */
> +#define SSSR_TINT(1 << 19) /* Receiver Time-out Interrupt */
> +#define SSSR_PINT(1 << 18) /* Peripheral Trailing Byte Interrupt */
Use BIT() macro throughout.
> +#define SSPSP_FSRT (1 << 25) /* Frame Sync Relative Timing */
> +#define SSPSP_DMYSTOP(x) ((x) << 23) /* Dummy Stop */
> +#define SSPSP_SFRMWDTH(x)((x) << 16) /* Serial Frame Width */
> +#define SSPSP_SFRMDLY(x) ((x) << 9) /* Serial Frame Delay */
> +#define SSPSP_DMYSTRT(x) ((x) << 7) /* Dummy Start */
> +#define SSPSP_STRTDLY(x) ((x) << 4) /* Start Delay */
> +#define SSPSP_ETDS (1 << 3)/* End of Transfer data State */
> +#define SSPSP_SFRMP (1 << 2)/* Serial Frame Polarity */
> +#define SSPSP_SCMODE(x) ((x) << 0) /* Serial Bit Rate Clock Mode */
(...)
> +/*
> + * For testing SSCR1 changes that require SSP restart, basically
> + * everything except the service and interrupt enables
> + */
> +
> +#define SSCR1_CHANGE_MASK (SSCR1_TTELP | SSCR1_TTE | SSCR1_SCFR \
> + | SSCR1_ECRA | SSCR1_ECRB | SSCR1_SCLKDIR \
> + | SSCR1_SFRMDIR | SSCR1_RWOT | SSCR1_TRAIL \
> + | SSCR1_IFS | SSCR1_STRF | SSCR1_EFWR \
> + | SSCR1_RFT | SSCR1_TFT | SSCR1_MWDS \
> + | SSCR1_SPH | SSCR1_SPO | SSCR1_LBM)
> +
> +struct callback_param {
> + void *drv_context;
> + u32 direction;
> +};
> +
Convert the inline documentation below to use kerneldoc.
> +struct ssp_driver_context {
> + /* Driver model hookup */
> + struct pci_dev *pdev;
> +
> + /* SPI framework hookup */
> + struct spi_master *master;
> +
> + /* SSP register addresses */
> + unsigned long paddr;
> + void *ioaddr;
> + int irq;
> +
> + /* I2C registers */
> + dma_addr_t I2C_paddr;
> + void *I2C_ioaddr;
Skip the caps.
i2c_paddr, i2c_ioaddr is fine.
But I think "paddr" is a bad name because it probably spells
out "physical address", "daddr" is more to the point, because
dma address is not necessarily == physical address.
> + /* SSP masks*/
> + u32 cr1_sig;
> + u32 cr1;
> + u32 clear_sr;
> + u32 mask_sr;
> +
> + /* PM_QOS request */
> + struct pm_qos_request pm_qos_req;
> +
> + struct tasklet_struct poll_transfer;
> +
> + spinlock_t lock;
> +
> + /* Current message transfer state info */
> + struct spi_message *cur_msg;
> + size_t len;
> + size_t len_dma_rx;
> + size_t len_dma_tx;
> + void *tx;
> + void *tx_end;
> + void *rx;
> + void *rx_end;
> + bool dma_initialized;
> + int dma_mapped;
> + dma_addr_t rx_dma;
> + dma_addr_t tx_dma;
> + u8 n_bytes;
> + int (*write)(struct ssp_driver_context *drv_context);
> + int (*read)(struct ssp_driver_context *drv_context);
> +
> + struct intel_mid_dma_slavedmas_tx;
> + struct intel_mid_dma_slavedmas_rx;
> + struct dma_chan*txchan;
> + struct dma_chan*rxchan;
> + struct workqueue_struct *dma_wq;
> + struct work_struct complete_work;
> +
> + u8 __iomem *virt_addr_sram_tx;
> + u8 __iomem *virt_addr_sram_rx;
> +
> + int txdma_done;
> + int rxdma_done;
> + struct callback_param tx_param;
> + struct callback_param rx_param;
With kerneldoc it's easier to tell what the usecase is for these
callbacks.
> + struct pci_dev *dmac1;
It seems that something like a pci_dev * should be used
to refer to the I2C and SRAM as well?
> +
> + unsigned long quirks;
> + u32 rx_fifo_threshold;
> +};
> +
> +struct chip_data {
> + u32 cr0;
> + u32 cr1;
> + u32 timeout;
> + u8 n_bytes;
> + u8 dma_enabled;
bool?
> + u8 bits_per_word;
> + u32 speed_hz;
Should that be u32? unsigned int seems more apropriate for a frequency.
> + int (*write)(struct ssp_driver_context *drv_context);
> + int (*read)(struct ssp_driver_context *drv_context);
> +};
kerneldoc me.
> +enum intel_mid_ssp_spi_fifo_burst {
> + IMSS_FIFO_BURST_1,
> + IMSS_FIFO_BURST_4,
> + IMSS_FIFO_BURST_8
> +};
> +
> +/* spi_board_info.controller_data for SPI slave devices,
> + * copied to spi_device.platform_data ... mostly for dma tuning
> + */
> +struct intel_mid_ssp_spi_chip {
> + enum intel_mid_ssp_spi_fifo_burst burst_size;
> + u32 timeout;
> + u8 enable_loopback;
> + u8 dma_enabled;
The last two entries looks like they should be bool.
> +};
kerneldoc.
> +#define SPI_DIB_NAME_LEN 16
> +#define SPI_DIB_SPEC_INFO_LEN 10
> +
> +struct spi_dib_header {
> + u32 signature;
> + u32 length;
> + u8 rev;
> + u8 checksum;
> + u8 dib[0];
> +} __packed;
Why is this packed?
Yours,
Linus Walleij
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] SPI: SSP SPI Controller driver
On Tue, Dec 11, 2012 at 9:58 AM, chao bi wrote: > 1. I understand the workqueue in spi core is for driving message > transfer, so SPI driver should not create new workqueue for this usage. > However, the workqueue created here is not for this usage it's to call > back to SPI protocol driver (ifx6x60.c) when DMA data transfer is > finished, so it seems not conflict with spi core. Am I right? So a single message can contain several transfers, and if this is some per-transfer DMA thing, it could be valid. I need to go in and look closer at the patch. I've considered trying to also generalize parts of the transfer handling but ran out of energy. Yours, Linus Walleij -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] spi/pl022: Activate resourses before deactivate them in suspend
On Sat, Oct 27, 2012 at 11:46 PM, Mark Brown wrote: > On Fri, Oct 05, 2012 at 09:43:32AM +0200, Ulf Hansson wrote: > >> To be able to deactivate resourses in suspend, the resourses must >> first be surely active. This is done with a pm_runtime_get_sync. >> Once the resourses are restored to active state again in resume, >> the runtime pm usage count can be decreased with a pm_runtime_put. > > The PM core will ensure devices are runtime resumed before we enter > suspend precisely due to this sort of issue. I asked the very same question to Ulf (in speech, sorry so you couldn't see it...) So I guess we are talking about drivers/base/main.c in device_prepare() pm_runtime_get_noresume() is called and in device_complete() pm_runtime_put_sync() is called. Both put into current for in commit 88d26136a256576e444db312179e17af6dd0ea87 on sep 19th. Yes it seems like it will do the job. Ulf can you comment on this... Yours, Linus Walleij -- WINDOWS 8 is here. Millions of people. Your app in 30 days. Visit The Windows 8 Center at Sourceforge for all your go to resources. http://windows8center.sourceforge.net/ join-generation-app-and-make-money-coding-fast/ ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 2/2] Revert "spi/pl022: enable runtime PM"
On Tue, Oct 23, 2012 at 1:41 PM, Mark Brown wrote: > I have to say I had been under the impression that Linus' series that I > applied the other day dealt with all the outstanding stuff here; the > issues with this have been the awful changelogs and the overalapping > sets of patches. It did I think it was patch [1/4] (same subject as this thread), http://sourceforge.net/mailarchive/forum.php?thread_name=1350476818-13056-1-git-send-email-linus.walleij%40stericsson.com&forum_name=spi-devel-general to which you replied: > This was already applied, applied the rest thanks. So it probably wasn't and it's just some mishap so that 2,3,4 /4 were applied while 1/4 was actually needed to. Yours, Linus Walleij -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 2/4 v2] spi: spi-pl022: Minor simplification for runtime pm
From: Ulf Hansson
In probe pm_runtime_put_autosuspend has the same effect as doing
pm_runtime_put.
Signed-off-by: Ulf Hansson
Signed-off-by: Linus Walleij
---
drivers/spi/spi-pl022.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index a1db91a..51b7a95 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -2246,10 +2246,9 @@ pl022_probe(struct amba_device *adev, const struct
amba_id *id)
pm_runtime_set_autosuspend_delay(dev,
platform_info->autosuspend_delay);
pm_runtime_use_autosuspend(dev);
- pm_runtime_put_autosuspend(dev);
- } else {
- pm_runtime_put(dev);
}
+ pm_runtime_put(dev);
+
return 0;
err_spi_register:
--
1.7.11.3
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 2/4] spi: spi-pl022: Minor simplification for runtime pm
On Wed, Oct 17, 2012 at 4:39 PM, Ulf Hansson wrote: > We have discussed this patch previously. I think we shall use it, but > we should change the commit msg since it does not reflect the truth. > It is no more true that "upper layer in driver core is preventing the > device from being runtime suspended by a pm_runtime_get*". This was > the case earlier. OK I'll update the commit message and respin this one *only* as [PATCH 2/4 v2] hold on... Yours, Linus Walleij -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 4/4] spi/pl022: add IDLE state pin management
From: Patrice Chotard
This commit allow to put pins in IDLE state in
runtime_suspend and in SLEEP state in suspend, corresponding
to defined semantics in .
To do this, just add a boolean parameter runtime
to pl022_resume_resources/pl022_suspend_resources which
indicates if it's called from PM_RUNTIME callbacks or not.
Signed-off-by: Patrice Chotard
Signed-off-by: Linus Walleij
---
drivers/spi/spi-pl022.c | 44 +++-
1 file changed, 31 insertions(+), 13 deletions(-)
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index 51329b2..1361868 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -371,6 +371,7 @@ struct pl022 {
/* Two optional pin states - default & sleep */
struct pinctrl *pinctrl;
struct pinctrl_state*pins_default;
+ struct pinctrl_state*pins_idle;
struct pinctrl_state*pins_sleep;
struct spi_master *master;
struct pl022_ssp_controller *master_info;
@@ -2116,6 +2117,11 @@ pl022_probe(struct amba_device *adev, const struct
amba_id *id)
} else
dev_err(dev, "could not get default pinstate\n");
+ pl022->pins_idle = pinctrl_lookup_state(pl022->pinctrl,
+ PINCTRL_STATE_IDLE);
+ if (IS_ERR(pl022->pins_idle))
+ dev_dbg(dev, "could not get idle pinstate\n");
+
pl022->pins_sleep = pinctrl_lookup_state(pl022->pinctrl,
PINCTRL_STATE_SLEEP);
if (IS_ERR(pl022->pins_sleep))
@@ -2302,35 +2308,47 @@ pl022_remove(struct amba_device *adev)
* the runtime counterparts to handle external resources like
* clocks, pins and regulators when going to sleep.
*/
-static void pl022_suspend_resources(struct pl022 *pl022)
+static void pl022_suspend_resources(struct pl022 *pl022, bool runtime)
{
int ret;
+ struct pinctrl_state *pins_state;
clk_disable(pl022->clk);
+ pins_state = runtime ? pl022->pins_idle : pl022->pins_sleep;
/* Optionally let pins go into sleep states */
- if (!IS_ERR(pl022->pins_sleep)) {
- ret = pinctrl_select_state(pl022->pinctrl,
- pl022->pins_sleep);
+ if (!IS_ERR(pins_state)) {
+ ret = pinctrl_select_state(pl022->pinctrl, pins_state);
if (ret)
- dev_err(&pl022->adev->dev,
- "could not set pins to sleep state\n");
+ dev_err(&pl022->adev->dev, "could not set %s pins\n",
+ runtime ? "idle" : "sleep");
}
}
-static void pl022_resume_resources(struct pl022 *pl022)
+static void pl022_resume_resources(struct pl022 *pl022, bool runtime)
{
int ret;
/* Optionaly enable pins to be muxed in and configured */
+ /* First go to the default state */
if (!IS_ERR(pl022->pins_default)) {
- ret = pinctrl_select_state(pl022->pinctrl,
- pl022->pins_default);
+ ret = pinctrl_select_state(pl022->pinctrl, pl022->pins_default);
if (ret)
dev_err(&pl022->adev->dev,
"could not set default pins\n");
}
+ if (!runtime) {
+ /* Then let's idle the pins until the next transfer happens */
+ if (!IS_ERR(pl022->pins_idle)) {
+ ret = pinctrl_select_state(pl022->pinctrl,
+ pl022->pins_idle);
+ if (ret)
+ dev_err(&pl022->adev->dev,
+ "could not set idle pins\n");
+ }
+ }
+
clk_enable(pl022->clk);
}
#endif
@@ -2348,7 +2366,7 @@ static int pl022_suspend(struct device *dev)
}
pm_runtime_get_sync(dev);
- pl022_suspend_resources(pl022);
+ pl022_suspend_resources(pl022, false);
dev_dbg(dev, "suspended\n");
return 0;
@@ -2359,7 +2377,7 @@ static int pl022_resume(struct device *dev)
struct pl022 *pl022 = dev_get_drvdata(dev);
int ret;
- pl022_resume_resources(pl022);
+ pl022_resume_resources(pl022, false);
pm_runtime_put(dev);
/* Start the queue running */
@@ -2378,7 +2396,7 @@ static int pl022_runtime_suspend(struct device *dev)
{
struct pl022 *pl022 = dev_get_drvdata(dev);
- pl022_suspend_resources(pl022);
+ pl022_suspend_resources(pl022, true);
return 0;
}
@@ -2386,7 +2404,7 @@ static int pl022_runtime
[PATCH 3/4] spi/pl022: Activate resourses before deactivate them in suspend
From: Ulf Hansson To be able to deactivate resourses in suspend, the resourses must first be surely active. This is done with a pm_runtime_get_sync. Once the resourses are restored to active state again in resume, the runtime pm usage count can be decreased with a pm_runtime_put. Signed-off-by: Ulf Hansson Signed-off-by: Linus Walleij --- drivers/spi/spi-pl022.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c index 51b7a95..51329b2 100644 --- a/drivers/spi/spi-pl022.c +++ b/drivers/spi/spi-pl022.c @@ -2346,6 +2346,8 @@ static int pl022_suspend(struct device *dev) dev_warn(dev, "cannot suspend master\n"); return ret; } + + pm_runtime_get_sync(dev); pl022_suspend_resources(pl022); dev_dbg(dev, "suspended\n"); @@ -2358,6 +2360,7 @@ static int pl022_resume(struct device *dev) int ret; pl022_resume_resources(pl022); + pm_runtime_put(dev); /* Start the queue running */ ret = spi_master_resume(pl022->master); -- 1.7.11.3 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 2/4] spi: spi-pl022: Minor simplification for runtime pm
From: Ulf Hansson
In probe pm_runtime_put_autosuspend has the same effect as doing
pm_runtime_put. This due to upper layer in driver core is preventing
the device from being runtime suspended by a pm_runtime_get*.
Signed-off-by: Ulf Hansson
Signed-off-by: Linus Walleij
---
drivers/spi/spi-pl022.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index a1db91a..51b7a95 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -2246,10 +2246,9 @@ pl022_probe(struct amba_device *adev, const struct
amba_id *id)
pm_runtime_set_autosuspend_delay(dev,
platform_info->autosuspend_delay);
pm_runtime_use_autosuspend(dev);
- pm_runtime_put_autosuspend(dev);
- } else {
- pm_runtime_put(dev);
}
+ pm_runtime_put(dev);
+
return 0;
err_spi_register:
--
1.7.11.3
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 1/4] Revert "spi/pl022: enable runtime PM"
From: Ulf Hansson
This reverts commit 2fb30d1147c599f5657e8c62c862f9a0f58d9d99.
This patch is reverted due to wrong runtime PM code.
Conflicts:
drivers/spi/spi-pl022.c
Signed-off-by: Ulf Hansson
Signed-off-by: Linus Walleij
---
drivers/spi/spi-pl022.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index 5cf0643..a1db91a 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -2186,9 +2186,6 @@ pl022_probe(struct amba_device *adev, const struct
amba_id *id)
printk(KERN_INFO "pl022: mapped registers from 0x%08x to %p\n",
adev->res.start, pl022->virtbase);
- pm_runtime_enable(dev);
- pm_runtime_resume(dev);
-
pl022->clk = devm_clk_get(&adev->dev, NULL);
if (IS_ERR(pl022->clk)) {
status = PTR_ERR(pl022->clk);
@@ -2293,7 +2290,6 @@ pl022_remove(struct amba_device *adev)
clk_disable(pl022->clk);
clk_unprepare(pl022->clk);
- pm_runtime_disable(&adev->dev);
amba_release_regions(adev);
tasklet_disable(&pl022->pump_transfers);
spi_unregister_master(pl022->master);
--
1.7.11.3
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH 0/4] PL022 patch queue
Hi Mark, it turns out the reason that the IDLE state patch did not apply was due to this dependency chain, all tested by me. So I signed them all off and rebased on top of spi-next, hope this works out. Patrice Chotard (1): spi/pl022: add IDLE state pin management Ulf Hansson (3): Revert "spi/pl022: enable runtime PM" spi: spi-pl022: Minor simplification for runtime pm spi/pl022: Activate resourses before deactivate them in suspend drivers/spi/spi-pl022.c | 56 +++-- 1 file changed, 36 insertions(+), 20 deletions(-) -- 1.7.11.3 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] spi/pl022: add IDLE state pin management
On Wed, Oct 17, 2012 at 9:24 AM, Mark Brown wrote: > On Thu, Oct 11, 2012 at 02:03:51PM +0200, Linus Walleij wrote: >> From: Patrice Chotard >> >> This commit allow to put pins in IDLE state in >> runtime_suspend and in SLEEP state in suspend, corresponding >> to defined semantics in . > > Not sure what tree this is against but it doesn't apply to v3.7-rc1. OK I'll rebase and respin. Yours, Linus Walleij -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH] spi/pl022: add IDLE state pin management
From: Patrice Chotard
This commit allow to put pins in IDLE state in
runtime_suspend and in SLEEP state in suspend, corresponding
to defined semantics in .
To do this, just add a boolean parameter runtime
to pl022_resume_resources/pl022_suspend_resources which
indicates if it's called from PM_RUNTIME callbacks or not.
Signed-off-by: Patrice Chotard
Signed-off-by: Linus Walleij
---
drivers/spi/spi-pl022.c | 44 +++-
1 file changed, 31 insertions(+), 13 deletions(-)
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index 51329b2..1361868 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -371,6 +371,7 @@ struct pl022 {
/* Two optional pin states - default & sleep */
struct pinctrl *pinctrl;
struct pinctrl_state*pins_default;
+ struct pinctrl_state*pins_idle;
struct pinctrl_state*pins_sleep;
struct spi_master *master;
struct pl022_ssp_controller *master_info;
@@ -2116,6 +2117,11 @@ pl022_probe(struct amba_device *adev, const struct
amba_id *id)
} else
dev_err(dev, "could not get default pinstate\n");
+ pl022->pins_idle = pinctrl_lookup_state(pl022->pinctrl,
+ PINCTRL_STATE_IDLE);
+ if (IS_ERR(pl022->pins_idle))
+ dev_dbg(dev, "could not get idle pinstate\n");
+
pl022->pins_sleep = pinctrl_lookup_state(pl022->pinctrl,
PINCTRL_STATE_SLEEP);
if (IS_ERR(pl022->pins_sleep))
@@ -2302,35 +2308,47 @@ pl022_remove(struct amba_device *adev)
* the runtime counterparts to handle external resources like
* clocks, pins and regulators when going to sleep.
*/
-static void pl022_suspend_resources(struct pl022 *pl022)
+static void pl022_suspend_resources(struct pl022 *pl022, bool runtime)
{
int ret;
+ struct pinctrl_state *pins_state;
clk_disable(pl022->clk);
+ pins_state = runtime ? pl022->pins_idle : pl022->pins_sleep;
/* Optionally let pins go into sleep states */
- if (!IS_ERR(pl022->pins_sleep)) {
- ret = pinctrl_select_state(pl022->pinctrl,
- pl022->pins_sleep);
+ if (!IS_ERR(pins_state)) {
+ ret = pinctrl_select_state(pl022->pinctrl, pins_state);
if (ret)
- dev_err(&pl022->adev->dev,
- "could not set pins to sleep state\n");
+ dev_err(&pl022->adev->dev, "could not set %s pins\n",
+ runtime ? "idle" : "sleep");
}
}
-static void pl022_resume_resources(struct pl022 *pl022)
+static void pl022_resume_resources(struct pl022 *pl022, bool runtime)
{
int ret;
/* Optionaly enable pins to be muxed in and configured */
+ /* First go to the default state */
if (!IS_ERR(pl022->pins_default)) {
- ret = pinctrl_select_state(pl022->pinctrl,
- pl022->pins_default);
+ ret = pinctrl_select_state(pl022->pinctrl, pl022->pins_default);
if (ret)
dev_err(&pl022->adev->dev,
"could not set default pins\n");
}
+ if (!runtime) {
+ /* Then let's idle the pins until the next transfer happens */
+ if (!IS_ERR(pl022->pins_idle)) {
+ ret = pinctrl_select_state(pl022->pinctrl,
+ pl022->pins_idle);
+ if (ret)
+ dev_err(&pl022->adev->dev,
+ "could not set idle pins\n");
+ }
+ }
+
clk_enable(pl022->clk);
}
#endif
@@ -2348,7 +2366,7 @@ static int pl022_suspend(struct device *dev)
}
pm_runtime_get_sync(dev);
- pl022_suspend_resources(pl022);
+ pl022_suspend_resources(pl022, false);
dev_dbg(dev, "suspended\n");
return 0;
@@ -2359,7 +2377,7 @@ static int pl022_resume(struct device *dev)
struct pl022 *pl022 = dev_get_drvdata(dev);
int ret;
- pl022_resume_resources(pl022);
+ pl022_resume_resources(pl022, false);
pm_runtime_put(dev);
/* Start the queue running */
@@ -2378,7 +2396,7 @@ static int pl022_runtime_suspend(struct device *dev)
{
struct pl022 *pl022 = dev_get_drvdata(dev);
- pl022_suspend_resources(pl022);
+ pl022_suspend_resources(pl022, true);
return 0;
}
@@ -2386,7 +2404,7 @@ static int pl022_runtime
Re: [PATCH V2 0/3] spi: spi-pl022: Fixup use of runtime pm
On Thu, Oct 4, 2012 at 10:04 AM, Ulf Hansson wrote: > From: Ulf Hansson > > Some old runtime pm patches got merged whiched messed up things. > These are now reverted. Additionaly one patch do a simplification > of the use of runtime pm functions. > > V2: > Rebased patches and updated commit messages. > > Ulf Hansson (3): > Revert "spi/pl022: fix spi-pl022 pm enable at probe" > Revert "spi/pl022: enable runtime PM" > spi: spi-pl022: Minor simplification for runtime pm I think patch 1/3 and 2/3 needs to go into the -rc fixes. Who's funneling this now? Grant or Mark? Yours, Linus Walleij -- 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
Re: [PATCH V2 3/3] spi: spi-pl022: Minor simplification for runtime pm
On Thu, Oct 4, 2012 at 11:07 AM, Ulf Hansson wrote:
> Mark, I am not sure this particular patch is actually wanted. Realized
> that when reading up on the driver/base/* patches for PM changes this
> summer. Especially how device probe/suspend/shutdown etc. has been
> changed for runtime PM point of view.
Mark will get you for top-posting ;-)
>> From: Ulf Hansson
>>
>> In probe pm_runtime_put_autosuspend has the same effect as doing
>> pm_runtime_put. This due to upper layer in driver core is preventing
>> the device from being runtime suspended by a pm_runtime_get*.
>>
>> Signed-off-by: Ulf Hansson
>> Reviewed-by: Linus Walleij
>> ---
>> drivers/spi/spi-pl022.c |5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
>> index a1db91a..51b7a95 100644
>> --- a/drivers/spi/spi-pl022.c
>> +++ b/drivers/spi/spi-pl022.c
>> @@ -2246,10 +2246,9 @@ pl022_probe(struct amba_device *adev, const struct
>> amba_id *id)
>> pm_runtime_set_autosuspend_delay(dev,
>> platform_info->autosuspend_delay);
>> pm_runtime_use_autosuspend(dev);
>> - pm_runtime_put_autosuspend(dev);
>> - } else {
>> - pm_runtime_put(dev);
>> }
>> + pm_runtime_put(dev);
>> +
>> return 0;
I'm paging Rafael and Magnus for their comments so we don't
overload Mark with runtime PM semantics...
Yours,
Linus Walleij
--
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
Re: [PATCH 3/3] spi: spi-pl022: Minor simplification for runtime pm
On Fri, Sep 28, 2012 at 1:21 PM, Ulf Hansson wrote: > From: Ulf Hansson > > In probe pm_runtime_put_autosuspend has the same effect as doing > pm_runtime_put. This due to upper layer in driver core is preventing > the device from being runtime suspended by a pm_runtime_get*. > > Signed-off-by: Ulf Hansson Reviewed-by: Linus Walleij Yours, Linus Walleij -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 2/3] Revert "spi/pl022: enable runtime PM"
On Fri, Sep 28, 2012 at 1:21 PM, Ulf Hansson wrote: > From: Ulf Hansson > > This reverts commit 2fb30d1147c599f5657e8c62c862f9a0f58d9d99. > > Signed-off-by: Ulf Hansson Reviewed-by: Linus Walleij Thanks for fixing my stupid mistakes ... Linus Walleij -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 1/3] Revert "spi/pl022: fix spi-pl022 pm enable at probe"
On Sun, Sep 30, 2012 at 12:14 PM, Russell King - ARM Linux wrote: > The real answer is to revert both commits to get the driver back to a > sane state, before then progressing with the driver in a sane manner. > This is what Ulf is doing. Aha, mea culpa. Acked-by: Linus Walleij For all of them, I'll read up on this exploding backlog and then Ulf will hammer me at the office until I understand this stuff properly... Yours, Linus Walleij -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH 1/3] Revert "spi/pl022: fix spi-pl022 pm enable at probe"
On Fri, Sep 28, 2012 at 1:21 PM, Ulf Hansson wrote: > From: Ulf Hansson > > This reverts commit 6887237cd7da904184dab2750504040c68f3a080. > > Signed-off-by: Ulf Hansson Why? It was removed in this commit, is it wrong? Author: Michel JAOUEN Date: Fri Aug 17 17:28:41 2012 +0200 spi/pl022: fix spi-pl022 pm enable at probe amba drivers does not need to enable pm runtime at probe. amba_probe already enables pm runtime. This rids this warning in the ux500 boot log: ssp-pl022 ssp0: Unbalanced pm_runtime_enable! Signed-off-by: Michel JAOUEN Signed-off-by: Linus Walleij Signed-off-by: Mark Brown Yours, Linus Walleij -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH v2] spi/pl022: get/put resources on suspend/resume
On Thu, Sep 27, 2012 at 6:27 AM, vipul kumar samar
wrote:
>> + clk_enable(pl022->clk);
>
> What happen in case clk_enable returns an error??
Same as today, it gets ignored. This is not uncommon among drivers,
there are just too many things to check. On many platforms the
clk_enable() just cannot return anything but 0,
For example in the SPEAr ultimately a gate clock seems to
be registered for this clock and the code handling enable
looks like this (drivers/clk/clk-gate.c):
static int clk_gate_enable(struct clk_hw *hw)
{
clk_gate_endisable(hw, 1);
return 0;
}
Yours,
Linus Walleij
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH v2] spi/pl022: get/put resources on suspend/resume
This factors out the resource handling in runtime
suspend/resume and also calls it from the ordinary suspend
and resume hooks.
The semantics require that ordinary PM op suspend is called
with runtime PM in resumed mode, so that ordinary suspend
can assume that it will e.g. decrease the clock reference
counter to 0, runtime resume having previously increased it
to 1.
Cc: Vipul Kumar Samar
Cc: Viresh Kumar
Acked-by: Ulf Hansson
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Add more #ifdef for the case where we have neither normal
PM nor runtime PM.
---
drivers/spi/spi-pl022.c | 66 -
1 file changed, 44 insertions(+), 22 deletions(-)
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index 15737bc..9194641 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -2300,6 +2300,45 @@ pl022_remove(struct amba_device *adev)
return 0;
}
+#if defined(CONFIG_SUSPEND) || defined(CONFIG_PM_RUNTIME)
+/*
+ * These two functions are used from both suspend/resume and
+ * the runtime counterparts to handle external resources like
+ * clocks, pins and regulators when going to sleep.
+ */
+static void pl022_suspend_resources(struct pl022 *pl022)
+{
+ int ret;
+
+ clk_disable(pl022->clk);
+
+ /* Optionally let pins go into sleep states */
+ if (!IS_ERR(pl022->pins_sleep)) {
+ ret = pinctrl_select_state(pl022->pinctrl,
+ pl022->pins_sleep);
+ if (ret)
+ dev_err(&pl022->adev->dev,
+ "could not set pins to sleep state\n");
+ }
+}
+
+static void pl022_resume_resources(struct pl022 *pl022)
+{
+ int ret;
+
+ /* Optionaly enable pins to be muxed in and configured */
+ if (!IS_ERR(pl022->pins_default)) {
+ ret = pinctrl_select_state(pl022->pinctrl,
+ pl022->pins_default);
+ if (ret)
+ dev_err(&pl022->adev->dev,
+ "could not set default pins\n");
+ }
+
+ clk_enable(pl022->clk);
+}
+#endif
+
#ifdef CONFIG_SUSPEND
static int pl022_suspend(struct device *dev)
{
@@ -2311,6 +2350,7 @@ static int pl022_suspend(struct device *dev)
dev_warn(dev, "cannot suspend master\n");
return ret;
}
+ pl022_suspend_resources(pl022);
dev_dbg(dev, "suspended\n");
return 0;
@@ -2321,6 +2361,8 @@ static int pl022_resume(struct device *dev)
struct pl022 *pl022 = dev_get_drvdata(dev);
int ret;
+ pl022_resume_resources(pl022);
+
/* Start the queue running */
ret = spi_master_resume(pl022->master);
if (ret)
@@ -2336,36 +2378,16 @@ static int pl022_resume(struct device *dev)
static int pl022_runtime_suspend(struct device *dev)
{
struct pl022 *pl022 = dev_get_drvdata(dev);
- int status = 0;
-
- clk_disable(pl022->clk);
-
- /* Optionally let pins go into sleep states */
- if (!IS_ERR(pl022->pins_sleep)) {
- status = pinctrl_select_state(pl022->pinctrl,
- pl022->pins_sleep);
- if (status)
- dev_err(dev, "could not set pins to sleep state\n");
- }
+ pl022_suspend_resources(pl022);
return 0;
}
static int pl022_runtime_resume(struct device *dev)
{
struct pl022 *pl022 = dev_get_drvdata(dev);
- int status = 0;
-
- /* Optionaly enable pins to be muxed in and configured */
- if (!IS_ERR(pl022->pins_default)) {
- status = pinctrl_select_state(pl022->pinctrl,
- pl022->pins_default);
- if (status)
- dev_err(dev, "could not set default pins\n");
- }
-
- clk_enable(pl022->clk);
+ pl022_resume_resources(pl022);
return 0;
}
#endif
--
1.7.11.3
--
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219672;13503038;z?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
Re: [PATCH] spi/pl022: get/put resources on suspend/resume
On Wed, Sep 26, 2012 at 5:23 PM, Ulf Hansson wrote: > You will have compile warnings when not having CONFIG_SUSPEND and > CONFIG_RUNTIME_PM, due to unused code/functions. Argh the evil #fidefs... I'll put in even more of them then. > Otherwise you have my ack. Thanks! Yours, Linus Walleij -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ spi-devel-general mailing list spi-devel-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH] spi/pl022: get/put resources on suspend/resume
This factors out the resource handling in runtime
suspend/resume and also calls it from the ordinary suspend
and resume hooks.
The semantics require that ordinary PM op suspend is called
with runtime PM in resumed mode, so that ordinary suspend
can assume that it will e.g. decrease the clock reference
counter to 0, runtime resume having previously increased it
to 1.
Cc: Ulf Hansson
Cc: Vipul Kumar Samar
Cc: Viresh Kumar
Signed-off-by: Linus Walleij
---
Vipin: can you confirm that this approach works for your
case with only suspend/resume but no runtime PM?
Question: can I be sure that the above semantics is taken
care of by runtime PM, or will I have to add kludges to
the ordinary suspend/resume hooks to make sure that the
device is out of runtime suspend before suspending?
---
drivers/spi/spi-pl022.c | 64 -
1 file changed, 42 insertions(+), 22 deletions(-)
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index 15737bc..63cd7c6 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -2300,6 +2300,43 @@ pl022_remove(struct amba_device *adev)
return 0;
}
+/*
+ * These two functions are used from both suspend/resume and
+ * the runtime counterparts to handle external resources like
+ * clocks, pins and regulators when going to sleep.
+ */
+static void pl022_suspend_resources(struct pl022 *pl022)
+{
+ int ret;
+
+ clk_disable(pl022->clk);
+
+ /* Optionally let pins go into sleep states */
+ if (!IS_ERR(pl022->pins_sleep)) {
+ ret = pinctrl_select_state(pl022->pinctrl,
+ pl022->pins_sleep);
+ if (ret)
+ dev_err(&pl022->adev->dev,
+ "could not set pins to sleep state\n");
+ }
+}
+
+static void pl022_resume_resources(struct pl022 *pl022)
+{
+ int ret;
+
+ /* Optionaly enable pins to be muxed in and configured */
+ if (!IS_ERR(pl022->pins_default)) {
+ ret = pinctrl_select_state(pl022->pinctrl,
+ pl022->pins_default);
+ if (ret)
+ dev_err(&pl022->adev->dev,
+ "could not set default pins\n");
+ }
+
+ clk_enable(pl022->clk);
+}
+
#ifdef CONFIG_SUSPEND
static int pl022_suspend(struct device *dev)
{
@@ -2311,6 +2348,7 @@ static int pl022_suspend(struct device *dev)
dev_warn(dev, "cannot suspend master\n");
return ret;
}
+ pl022_suspend_resources(pl022);
dev_dbg(dev, "suspended\n");
return 0;
@@ -2321,6 +2359,8 @@ static int pl022_resume(struct device *dev)
struct pl022 *pl022 = dev_get_drvdata(dev);
int ret;
+ pl022_resume_resources(pl022);
+
/* Start the queue running */
ret = spi_master_resume(pl022->master);
if (ret)
@@ -2336,36 +2376,16 @@ static int pl022_resume(struct device *dev)
static int pl022_runtime_suspend(struct device *dev)
{
struct pl022 *pl022 = dev_get_drvdata(dev);
- int status = 0;
-
- clk_disable(pl022->clk);
-
- /* Optionally let pins go into sleep states */
- if (!IS_ERR(pl022->pins_sleep)) {
- status = pinctrl_select_state(pl022->pinctrl,
- pl022->pins_sleep);
- if (status)
- dev_err(dev, "could not set pins to sleep state\n");
- }
+ pl022_suspend_resources(pl022);
return 0;
}
static int pl022_runtime_resume(struct device *dev)
{
struct pl022 *pl022 = dev_get_drvdata(dev);
- int status = 0;
-
- /* Optionaly enable pins to be muxed in and configured */
- if (!IS_ERR(pl022->pins_default)) {
- status = pinctrl_select_state(pl022->pinctrl,
- pl022->pins_default);
- if (status)
- dev_err(dev, "could not set default pins\n");
- }
-
- clk_enable(pl022->clk);
+ pl022_resume_resources(pl022);
return 0;
}
#endif
--
1.7.11.3
--
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/pl022: use more managed resources
This switches the PL022 SPI driver to use devm_* managed resources
for IRQ, clocks, ioremap and GPIO. Prior to this, the GPIOs would
even leak.
Signed-off-by: Linus Walleij
---
drivers/spi/spi-pl022.c | 31 ++-
1 file changed, 10 insertions(+), 21 deletions(-)
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index f8568b4..15737bc 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -1,7 +1,7 @@
/*
* A driver for the ARM PL022 PrimeCell SSP/SPI bus master.
*
- * Copyright (C) 2008-2009 ST-Ericsson AB
+ * Copyright (C) 2008-2012 ST-Ericsson AB
* Copyright (C) 2006 STMicroelectronics Pvt. Ltd.
*
* Author: Linus Walleij
@@ -2074,24 +2074,21 @@ pl022_probe(struct amba_device *adev, const struct
amba_id *id)
if (!platform_info) {
dev_err(dev, "probe: no platform data defined\n");
- status = -ENODEV;
- goto err_no_pdata;
+ return -ENODEV;
}
if (platform_info->num_chipselect) {
num_cs = platform_info->num_chipselect;
} else {
dev_err(dev, "probe: no chip select defined\n");
- status = -ENODEV;
- goto err_no_pdata;
+ return -ENODEV;
}
/* Allocate master with space for data */
master = spi_alloc_master(dev, sizeof(struct pl022));
if (master == NULL) {
dev_err(&adev->dev, "probe - cannot alloc SPI master\n");
- status = -ENOMEM;
- goto err_no_master;
+ return -ENOMEM;
}
pl022 = spi_master_get_devdata(master);
@@ -2153,7 +2150,7 @@ pl022_probe(struct amba_device *adev, const struct
amba_id *id)
pl022->chipselects[i] = cs_gpio;
if (gpio_is_valid(cs_gpio)) {
- if (gpio_request(cs_gpio, "ssp-pl022"))
+ if (devm_gpio_request(dev, cs_gpio,
"ssp-pl022"))
dev_err(&adev->dev,
"could not request %d gpio\n",
cs_gpio);
@@ -2180,7 +2177,8 @@ pl022_probe(struct amba_device *adev, const struct
amba_id *id)
goto err_no_ioregion;
pl022->phybase = adev->res.start;
- pl022->virtbase = ioremap(adev->res.start, resource_size(&adev->res));
+ pl022->virtbase = devm_ioremap(dev, adev->res.start,
+ resource_size(&adev->res));
if (pl022->virtbase == NULL) {
status = -ENOMEM;
goto err_no_ioremap;
@@ -2190,7 +2188,7 @@ pl022_probe(struct amba_device *adev, const struct
amba_id *id)
pm_runtime_resume(dev);
- pl022->clk = clk_get(&adev->dev, NULL);
+ pl022->clk = devm_clk_get(&adev->dev, NULL);
if (IS_ERR(pl022->clk)) {
status = PTR_ERR(pl022->clk);
dev_err(&adev->dev, "could not retrieve SSP/SPI bus clock\n");
@@ -2218,8 +2216,8 @@ pl022_probe(struct amba_device *adev, const struct
amba_id *id)
SSP_CR1(pl022->virtbase));
load_ssp_default_config(pl022);
- status = request_irq(adev->irq[0], pl022_interrupt_handler, 0, "pl022",
-pl022);
+ status = devm_request_irq(dev, adev->irq[0], pl022_interrupt_handler,
+ 0, "pl022", pl022);
if (status < 0) {
dev_err(&adev->dev, "probe - cannot get IRQ (%d)\n", status);
goto err_no_irq;
@@ -2259,24 +2257,18 @@ pl022_probe(struct amba_device *adev, const struct
amba_id *id)
err_spi_register:
if (platform_info->enable_dma)
pl022_dma_remove(pl022);
-
- free_irq(adev->irq[0], pl022);
err_no_irq:
clk_disable(pl022->clk);
err_no_clk_en:
clk_unprepare(pl022->clk);
err_clk_prep:
- clk_put(pl022->clk);
err_no_clk:
- iounmap(pl022->virtbase);
err_no_ioremap:
amba_release_regions(adev);
err_no_ioregion:
err_no_gpio:
err_no_pinctrl:
spi_master_put(master);
- err_no_master:
- err_no_pdata:
return status;
}
@@ -2298,12 +2290,9 @@ pl022_remove(struct amba_device *adev)
if (pl022->master_info->enable_dma)
pl022_dma_remove(pl022);
- free_irq(adev->irq[0], pl022);
clk_disable(pl022->clk);
clk_unprepare(pl022->clk);
- clk_put(pl022->clk);
pm_runtime_disable(&adev->dev);
- iounmap(pl022->virtbase);
amba_release_regions(adev);
tasklet_disable(&pl022->pump_transfers);
spi_unre
Re: [PATCH 1/2] spi:pl022: Disable/Enable functional clock from suspend/resume
On Wed, Sep 26, 2012 at 4:08 PM, viresh kumar wrote: > On Wed, Sep 26, 2012 at 5:49 PM, Mark Brown > wrote: >> On Wed, Sep 26, 2012 at 02:17:36PM +0200, Linus Walleij wrote: >>> On Wed, Sep 26, 2012 at 1:24 PM, Vipul Kumar Samar >> >>> > SPI functional clock must be disalble/enable in non RTPM suspend/resume >>> > hooks. Currently it is only done for RTPM cases. >> >>> > This patch add support to disable/enbale clock for conventional >>> > suspend/resume calls. >> >>> Cross dependency between runtime suspend/resume and >>> common suspend/resume. Oh the horror ... >> >> This should be fine, we runtime resume before we suspend. > > I believe Vipul sent this patch for the cases where RTPM in not > enabled in the configs. OK so we need to handle the cases where either, both or just one of them is enabled... Mark says the defined semantics is that runtime PM is resumed across suspend/resume but I'd just like to understand the overall mechanism that makes sure this happens and I'm go... However there is another problem with the patch, because in -next there is also pin control handling in the runtime hooks, so we need to duplicate not only clocks but also that in each of the functions. Maybe we can first make a patch that breaks out resource handling so we can call that from each of the suspend/resume calls? (I'll try.) Yours, Linus Walleij -- 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:pl022: Disable/Enable functional clock from suspend/resume
On Wed, Sep 26, 2012 at 2:19 PM, Mark Brown wrote: > On Wed, Sep 26, 2012 at 02:17:36PM +0200, Linus Walleij wrote: >> On Wed, Sep 26, 2012 at 1:24 PM, Vipul Kumar Samar > >> > SPI functional clock must be disalble/enable in non RTPM suspend/resume >> > hooks. Currently it is only done for RTPM cases. > >> > This patch add support to disable/enbale clock for conventional >> > suspend/resume calls. > >> Cross dependency between runtime suspend/resume and >> common suspend/resume. Oh the horror ... > > This should be fine, we runtime resume before we suspend. (...) > This was clarified at some point relatively recently with the above > (which is essentially the same as the solution you describe). Oh. How come that whenever I poke my nose into this stuff I feel like a compleat n00b X-D Can you point me to the relevant posts/doc so I can read up on it, would be much appreciated! Yours, Linus Walleij -- 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] ARM: ABMA: Disable/Enable interface clock from suspend/resume
On Wed, Sep 26, 2012 at 1:24 PM, Vipul Kumar Samar wrote: > AMBA devices interface clock is disabled in RTPM suspend/resume hooks > but not in conventional hooks. > > This patch adds support to disable/enable clock for conventional > suspend/resume calls. (...) > + struct amba_device *pcdev = to_amba_device(dev); > int ret = 0; > > if (!drv) > @@ -132,16 +133,27 @@ static int amba_pm_suspend(struct device *dev) > ret = amba_legacy_suspend(dev, PMSG_SUSPEND); > } > > + if (!ret) > + clk_disable(pcdev->pclk); > + > return ret; > } You're not accounting for the case where pcdev->pclk is an error pointer (as happens if pclk lookup fails at probe). I think you can simplify some of the code using the external accessors from : amba_pclk_enable(); amba_pclk_disable(); But: Again this is a case where you have a race between runtime suspend/resume and ordinary suspend/resume. These ordinary suspend/resume operations should probably wait for runtime suspend to happen *first* if and only if runtime PM is enabled, and then the block will be gated off. So we really need to figure out how we can make sure that this happens. If just ordinary PM is enabled, the above makes sense but in that case I think we should have that #ifdef:ed as an alternative or something. So something like: suspend(): #ifdef CONFIG_PM_RUNTIME /* Wait for runtime PM to hammer down the pclk */ #elif CONFIG_PM amba_pclk_disable(); #endif resume(): #if defined(CONFIG_PM) && !defined(CONFIG_PM_RUNTIME) amba_pclk_enable(); #endif /* Let runtime PM lazily enable the clock when needed */ To complicate things further the bus operations can be overridden by e.g. voltage domains. In this case we (ux500) have choosen to call out to the AMBA level to make sure semantics are preserved. Yours, Linus Walleij -- 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:pl022: Disable/Enable functional clock from suspend/resume
On Wed, Sep 26, 2012 at 1:24 PM, Vipul Kumar Samar
wrote:
> SPI functional clock must be disalble/enable in non RTPM suspend/resume
> hooks. Currently it is only done for RTPM cases.
>
> This patch add support to disable/enbale clock for conventional
> suspend/resume calls.
>
> Signed-off-by: Vipul Kumar Samar
Cross dependency between runtime suspend/resume and
common suspend/resume. Oh the horror ...
Ulf Hansson has experienced pain with this as well, let's
discuss this a bit.
> @@ -2310,6 +2310,8 @@ static int pl022_suspend(struct device *dev)
> }
>
> dev_dbg(dev, "suspended\n");
> + clk_disable(pl022->clk);
> +
> return 0;
> }
>
> @@ -2318,6 +2320,12 @@ static int pl022_resume(struct device *dev)
> struct pl022 *pl022 = dev_get_drvdata(dev);
> int ret;
>
> + ret = clk_enable(pl022->clk);
> + if (ret) {
> + dev_err(dev, "could not enable SSP/SPI bus clock\n");
> + return ret;
> + }
> +
There is a potential race between the runtime
suspend/resume and ordinary suspend/resume hooks here
I'm afraid.
I think in this case since we're not reading nor writing
registers, we should just wait for the device to
go down to runtime suspend in the ordinary suspend
hook, just wait for runtime suspend to happen in
suspend, do nothing in resume (and wait for the device
to wake itself as needed).
So something like:
while (!pm_runtime_status_suspended(&dev))
cpu_relax(); // or usleep_range()?
/* Here you know the block is gated off */
Or is this better:
pm_runtime_get_sync();
/* Now we know for sure it's on! */
pm_runtime_put_sync();
/* Now we know for sure it's off! */
Is there a *good* way to await runtime suspend?
I don't know if any of this is the proper solution so let
Rafael and Magnus comment on how it's supposed
to be done.
Ramblings:
The semantics between runtime suspend/resume and
ordinary suspend/resume are unclear to me, it seems like
this is all up to the drivers and busses to figure out. Like
you weren't supposed to use both at the same time.
What we've done in other drivers here at ST-Ericsson is
to make the .suspend hook actually do a runtime get so that
runtime PM is "running", then hammer off all resources
and go to suspend with PM runtime actually enabled.
Something like this:
suspend()
pm_runtime_get_sync()
/* Maybe poke some registers here */
clk_disable();
resume():
clk_enable();
/* Maybe poke some registers here */
pm_runtime_put();
This is to be sure that there is not a race between runtime
suspend/resume and ordinary suspend/resume.
I don't like it since it actually turns things upside-down
completely, during ordinary suspend the device is
"runtime resumed" for example.
Rafael, Magnus: help.
Yours,
Linus Walleij
--
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] spi: pl022: Add clk_{un}prepare() support in runtime PM
On Wed, Sep 19, 2012 at 5:31 AM, viresh kumar wrote:
> On Tue, Sep 18, 2012 at 5:20 PM, Linus Walleij
> wrote:
>> On Tue, Sep 18, 2012 at 6:09 AM, viresh kumar
>> wrote:
>
>>> The amba layer is taking care of interface clock only and not
>>> functional clock. So
>>> i believe that's not the magic code. :)
>>
>> This clock is the one for the external bus. In some designs these two
>> clocks are one and the same, and these won't currently get into any clock
>> disabled states, sadly. (We need to fix that some day.)
>
> I went through the code and found following in amba/bus.c:
>
>
> static int amba_pm_runtime_suspend(struct device *dev)
> {
> struct amba_device *pcdev = to_amba_device(dev);
> int ret = pm_generic_runtime_suspend(dev);
>
> if (ret == 0 && dev->driver)
> clk_disable(pcdev->pclk);
>
> return ret;
> }
>
> static int amba_pm_runtime_resume(struct device *dev)
> {
> struct amba_device *pcdev = to_amba_device(dev);
> int ret;
>
> if (dev->driver) {
> ret = clk_enable(pcdev->pclk);
> /* Failure is probably fatal to the system, but... */
> if (ret)
> return ret;
> }
>
> return pm_generic_runtime_resume(dev);
> }
>
> If i am not wrong, these routines also get called with runtiime suspend/resume
> of pl022?
Maybe. And that is part of the problem. Check this in
drivers/base/power/runtime.c, rpm_suspend():
if (dev->pm_domain)
callback = dev->pm_domain->ops.runtime_suspend;
else if (dev->type && dev->type->pm)
callback = dev->type->pm->runtime_suspend;
else if (dev->class && dev->class->pm)
callback = dev->class->pm->runtime_suspend;
else if (dev->bus && dev->bus->pm)
callback = dev->bus->pm->runtime_suspend;
else
callback = NULL;
So as you see the AMBA bus-level runtime PM callbacks will be
called UNLESS there is a class and UNLESS there is a type
and UNLESS there is a voltage domain for this device.
In Ux500 we solved this by calling the AMBA bus-level code
from the voltage domain so it's not completely overridden,
but the semantics are complex here. :-/
(And then we have yet to bring common suspend/resume
into the picture ... which makes is ever more complex.)
If the SPEAr is not using any voltage domains for example,
it'll be unaffected and work fine.
> If that is the case, the even the interface clock of pl022 is getting
> disabled when not in used.
Yes, hopefully...
> And so for Architectures like SPEAr (where functional and interface
> clock are controlled
> by a single bit), we don't need anything else for power saving, with
> respect to clocks.
> Isn't it so?
If you have no power domains I hope the ref goes down to
zero and gates off the clock, so yes!
Yours,
Linus Walleij
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
[PATCH] spi/pl022: adopt pinctrl support
From: Patrice Chotard
Amend the PL022 pin controller to optionally take a pin control
handle and set the state of the pins to "default" on boot and
runtime resume, and to "sleep" at runtime suspend. This way we
will dynamically save power on the SPI busses, for example some
electronic designs may be able to ground the pins when unused
instead of pull-up. Some pin controllers may want to set the
pins as wake-up sources when sleeping.
Effect on platforms using the PL022 driver:
- If the platform does not use pin control - no semantic effect,
the pinctrl stubs will kick in and resolve the situation.
- Platforms using this driver and have pin control but no
function defined for the PL022 need to either supply a
"default" function in their map or enable pinctrl dummies
so the driver is satisfied.
- Platforms using this driver with hogs for setting up the PL022
pin control - stop using hogs to take the pl022 pin control
handle, let the driver handle this.
I'be looked at some platforms that may be affected:
- SPEAr: appears to define the proper functions in their device
trees and not hogging them, so things should be smooth, the
driver will simply start to take its pins.
- Ux500: the proper function is defined and will be taken properly
by the driver. New sleep states introduced by a separate patch to
ux500 but no regression, since the default state is sufficient.
- U300: old hog deleted as part of this patch.
- LPC32xx: does not appear to be using pinctrl.
- ARM Integrator IMPD1, RealView & Versatile: does not use pinctrl.
Cc: Pawel Moll
Cc: Roland Stigge
Cc: Shiraz Hashim
Cc: Mark Brown
Cc: Vinit Kamalaksha Shenoy
Cc: Viresh Kumar
Signed-off-by: Patrice Chotard
Signed-off-by: Linus Walleij
---
arch/arm/mach-u300/core.c | 3 ---
drivers/spi/spi-pl022.c | 46 ++
2 files changed, 46 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-u300/core.c b/arch/arm/mach-u300/core.c
index 03acf18..281292e 100644
--- a/arch/arm/mach-u300/core.c
+++ b/arch/arm/mach-u300/core.c
@@ -1605,9 +1605,6 @@ static struct u300_mux_hog u300_mux_hogs[] = {
.dev = &uart0_device.dev,
},
{
- .dev = &pl022_device.dev,
- },
- {
.dev = &mmcsd_device.dev,
},
};
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index e43b610..423513c 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
/*
* This macro is used to define some register default values.
@@ -367,6 +368,10 @@ struct pl022 {
resource_size_t phybase;
void __iomem*virtbase;
struct clk *clk;
+ /* Two optional pin states - default & sleep */
+ struct pinctrl *pinctrl;
+ struct pinctrl_state*pins_default;
+ struct pinctrl_state*pins_sleep;
struct spi_master *master;
struct pl022_ssp_controller *master_info;
/* Message per-transfer pump */
@@ -2068,6 +2073,28 @@ pl022_probe(struct amba_device *adev, const struct
amba_id *id)
pl022->chipselects = devm_kzalloc(dev, num_cs * sizeof(int),
GFP_KERNEL);
+ pl022->pinctrl = devm_pinctrl_get(dev);
+ if (IS_ERR(pl022->pinctrl)) {
+ status = PTR_ERR(pl022->pinctrl);
+ goto err_no_pinctrl;
+ }
+
+ pl022->pins_default = pinctrl_lookup_state(pl022->pinctrl,
+PINCTRL_STATE_DEFAULT);
+ /* enable pins to be muxed in and configured */
+ if (!IS_ERR(pl022->pins_default)) {
+ status = pinctrl_select_state(pl022->pinctrl,
+ pl022->pins_default);
+ if (status)
+ dev_err(dev, "could not set default pins\n");
+ } else
+ dev_err(dev, "could not get default pinstate\n");
+
+ pl022->pins_sleep = pinctrl_lookup_state(pl022->pinctrl,
+ PINCTRL_STATE_SLEEP);
+ if (IS_ERR(pl022->pins_sleep))
+ dev_dbg(dev, "could not get sleep pinstate\n");
+
/*
* Bus Number Which has been Assigned to this SSP controller
* on this board
@@ -2217,6 +2244,7 @@ pl022_probe(struct amba_device *adev, const struct
amba_id *id)
amba_release_regions(adev);
err_no_ioregion:
err_no_gpio:
+ err_no_pinctrl:
spi_master_put(master);
err_no_master:
err_no_pdata:
@@ -2290,15 +2318,33 @@ static int pl022_resume(struct device *dev)
static int pl022_runtime_suspend(struct device *dev)
{
struct pl022 *pl022 = dev_get_drvdata(dev);
+ int st
Re: [PATCH v2 2/2] ARM: OMAP2+: Enable pinctrl dummy states
On Mon, Sep 17, 2012 at 7:22 PM, Matt Porter wrote: > Enable pinctrl dummy states for all OMAP platforms that don't > populate DT. This allows drivers to be converted to pinctrl > and not generate new warnings on platforms that do not provide > pinctrl data. These platforms already have pinmuxes configured > before the drivers probe. > > Signed-off-by: Matt Porter Looks like a good idea, so FWIW: Acked-by: Linus Walleij Yours, Linus Walleij -- 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 09/19] ARM: ux500: Enable SSP (SPI) for HREF when booting Device Tree
On Mon, Sep 17, 2012 at 7:03 PM, Roland Stigge wrote: > On 09/10/2012 01:11 PM, Linus Walleij wrote: >> >> It appears Roland has written his bindings such that DT >> data augments platform data (yes, I am also getting crazy >> about this prioritization, mea culpa for ACKing this without >> proper discussion) so it appears that you could actually >> use AUXDATA and some stuff in the DT at the same >> time. > > Sorry for the incompleteness of the devicetree conversion. I'm sending a > patch (separately) that makes it possible to specify everything via > devicetree, so you can choose between dt and platform data. OK it was not such a big deal, but many many thanks for fixing this up! :-) > Except in case of callback specification (dma_filter()), you need to > provide platform data. OK. > Interestingly, when I removed the actual platform data from the board > file, I noticed that I still needed to specify a device name (like > dev:ssp0) to make it work. But this seems to be expected according to > the documentation of OF_DEV_AUXDATA(). Are there any plans or ideas how > to fix this? This is very likely because the clock tree has a name like "dev:ssp0" encoded for this device, and if you don't nail it down like that the device name will be the same as the node in your device tree and then clock lookup will fail. The "real fix" is to convert the clock drivers to use device tree so the drivers can just refer to the phandles to figure out what clock node they need. Along with the DMA channel mapping this is one of the major roadblocks to finalizing the device tree adoptions. > When we have sorted out this driver change (please check the new pl022 > specific dt property names!), I will provide patches for arm-soc to > actually use this new interface via dts files. OK cool I guess you will do this for the LPC32xx? Or are you testing this on some other platforms? Yours, Linus Walleij -- 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] spi: pl022: Add clk_{un}prepare() support in runtime PM
On Tue, Sep 18, 2012 at 6:09 AM, viresh kumar wrote: > Yes, we don't need to call prepare() again atleast for SPEAr. You are correct. > I saw the driver after a long time :) I'm asking because it's actually OK to do this, I was more asking whether it was really needed by any platforms... > Can you please elaborate, why can't i see any clk_disable/enable calls > anywhere > else from probe. If i remember correctly, earlier we used to enable/disable > clk after transfers and also during suspend/resume. We clk_disable() at runtime_suspend() and clk_enable() at runtime resume, and the driver gives hints to the runtime PM layer to autosuspend the driver whenever it's unused. Check the pm_runtime_* calls. > The amba layer is taking care of interface clock only and not > functional clock. So > i believe that's not the magic code. :) This clock is the one for the external bus. In some designs these two clocks are one and the same, and these won't currently get into any clock disabled states, sadly. (We need to fix that some day.) Yours, Linus Walleij -- 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] spi: pl022: Add clk_{un}prepare() support in runtime PM
On Mon, Sep 17, 2012 at 12:37 PM, Vipul Kumar Samar
wrote:
> clk_{un}prepare is mandatory for platforms using common clock framework. Add
> clk_{un}prepare() support for spi-pl022 runtime PM.
>
> Signed-off-by: Vipul Kumar Samar
This driver does clk_prepare/unprepare at probe
and removed, so I guess what you're trying to say is that
on your platform the clk_unprepare() process context call
is needed to save power?
Please elaborate...
Yours,
Linus Walleij
--
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 Sun, Sep 2, 2012 at 10:17 PM, Daniel Mack wrote: > 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? Mark better take them, ping on Mark. Yours, Linus Walleij -- 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] spi/pl022: Fix chipselects pointer computation
On Mon, Sep 3, 2012 at 10:14 AM, Roland Stigge wrote: > The new chip select handling via GPIO introduced a pointer computation bug: > > (int *) pl022 + sizeof(struct pl022) > > doesn't point to the data immediately after the actual struct pl022 (as was > intended) but to a multiple of bytes after it because of the (int *) type. > > Replacing the kludgy pointer arithmetic with managed memory allocation for the > chip selects. > > Signed-off-by: Roland Stigge Reviewed-by: Linus Walleij Thanks for fixing this! And thanks to Shiraz for spotting the problem, Mark you could add a: Reported-by: Shiraz Hashim when applying this. Yours, Linus Walleij -- 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 v6 1/3] spi/pl022: Add chip select handling via GPIO
On Sun, Sep 2, 2012 at 3:12 PM, shiraz hashim wrote: > Hi Linus, >> Yes that is why the allocation looks like this: >> >> + master = spi_alloc_master(dev, sizeof(struct pl022) + sizeof(int) * >> + platform_info->num_chipselect); >> > > The allocation is such because type of chipselects is int. > > The statement for allocation is correct, but > >pl022->chipselects = (int *) pl022 + sizeof(struct pl022); > > is not adding sizeof(struct pl022) bytes to pl022 base (which we want), > but infact 4 times the size of pl022 (because type of pl022 is now int *). > > Do you get my point ? This would go way beyond memory allocated > for chipselects. Yes of course ... how could I not see this. Sorry! Yours, Linus Walleij -- 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 v6 1/3] spi/pl022: Add chip select handling via GPIO
On Sat, Sep 1, 2012 at 1:14 PM, shiraz hashim wrote: > Hi Roland, > > On Wed, Aug 22, 2012 at 7:19 PM, Roland Stigge wrote: >> @@ -2016,6 +2030,8 @@ pl022_probe(struct amba_device *adev, co >> pl022->master_info = platform_info; >> pl022->adev = adev; >> pl022->vendor = id->data; >> + /* Point chipselects to allocated memory beyond the main struct */ >> + pl022->chipselects = (int *) pl022 + sizeof(struct pl022); > > This is going beyond memory allocated for chipselects > as it adds 4 * sizeof(struct pl022) bytes to pl022. Yes that is why the allocation looks like this: + master = spi_alloc_master(dev, sizeof(struct pl022) + sizeof(int) * + platform_info->num_chipselect); > pl022->chipselects = (int *) &pl022[1]; > can be musch safer. I see absolutely no sematic difference between these two methods to reach the first position beyond the first struct. If we're gonna be debating this it's a safe sign that this is not a good design pattern at all, so then it is better to simply devm_kzalloc(sizeof(int) * platform_info->num_chipselect); separately. (But I'm happy with the patch as it is. And the other way too, since I'm not very picky.) Yours, Linus Walleij -- 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 v6 2/3] spi/pl022: Add devicetree support
On Wed, Aug 22, 2012 at 3:49 PM, Roland Stigge wrote: > This patch adds device tree support to the spi-pl022 driver. > > Based on the initial patch by Alexandre Pereira da Silva > > > Signed-off-by: Roland Stigge > Acked-by: Alexandre Pereira da Silva Reviewed-by: Linus Walleij Yours, Linus Walleij -- 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 v6 3/3] DT bindings documentation: "num-cs" property for SPI controllers
On Wed, Aug 22, 2012 at 3:49 PM, Roland Stigge wrote: > Several SPI controller drivers have defined differently named properties for > the number of chip selects. Now adding "num-cs" as a reference name for new > bindings. > > Signed-off-by: Roland Stigge Reviewed-by: Linus Walleij Yours, Linus Walleij -- 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 v6 1/3] spi/pl022: Add chip select handling via GPIO
On Wed, Aug 22, 2012 at 3:49 PM, Roland Stigge wrote: > This patch adds the ability for the driver to control the chip select > directly. > This enables independence from cs_control callbacks. Configurable via > platform_data, to be extended as DT in the following patch. > > Based on the initial patch by Alexandre Pereira da Silva > > > Signed-off-by: Roland Stigge > Acked-by: Alexandre Pereira da Silva Thanks Roland, excellent work! Reviewed-by: Linus Walleij Yours, Linus Walleij -- 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 v5 2/2] spi/pl022: Add devicetree support
On Tue, Aug 21, 2012 at 6:01 PM, Roland Stigge wrote: > This patch adds device tree support to the spi-pl022 driver. (...) > --- linux-2.6.orig/Documentation/devicetree/bindings/spi/spi_pl022.txt > +++ linux-2.6/Documentation/devicetree/bindings/spi/spi_pl022.txt > @@ -6,7 +6,22 @@ Required properties: > - interrupts : Should contain SPI controller interrupt > > Optional properties: > +- num-cs : total number of chipselects I don't know if it's proper to duplicate but atleast *also* patch Documentation/devicetree/bindings/gpio/gpio.txt to indicate that this is a generic property on all GPIO drivers. The rest looks good. Yours, Linus Walleij -- 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 v5 1/2] spi/pl022: Add chip select handling via GPIO
On Tue, Aug 21, 2012 at 6:00 PM, Roland Stigge wrote:
> This patch adds the ability for the driver to control the chip select
> directly.
> This enables independence from cs_control callbacks. Configurable via
> platform_data, to be extended as DT in the following patch.
>
> Based on the initial patch by Alexandre Pereira da Silva
>
>
> Signed-off-by: Roland Stigge
(...)
> /*
> * This macro is used to define some register default values.
> @@ -356,6 +357,8 @@ struct vendor_data {
> * @sgt_rx: scattertable for the RX transfer
> * @sgt_tx: scattertable for the TX transfer
> * @dummypage: a dummy page used for driving data on the bus with DMA
> + * @cur_cs: current chip select (gpio)
> + * @chipselect: list of chipselects (gpios)
> */
> struct pl022 {
> struct amba_device *adev;
> @@ -389,6 +392,8 @@ struct pl022 {
> char*dummypage;
> booldma_running;
> #endif
> + int cur_cs;
> + int *chipselect;
Since this is an array, it should be named "chipselects" (plural).
(...)
> @@ -1840,8 +1852,9 @@ static int pl022_setup(struct spi_device
> chip->xfer_type = chip_info->com_mode;
> if (!chip_info->cs_control) {
> chip->cs_control = null_cs_control;
> - dev_warn(&spi->dev,
> -"chip select function is NULL for this chip\n");
> + if (!gpio_is_valid(pl022->chipselect[spi->chip_select]))
> + dev_warn(&spi->dev,
> +"chip select function is NULL for this
> chip\n");
This dev_warn() is wrong. Alter to a proper warning message.
> @@ -2016,6 +2030,7 @@ pl022_probe(struct amba_device *adev, co
> pl022->master_info = platform_info;
> pl022->adev = adev;
> pl022->vendor = id->data;
> + pl022->chipselect = (int *)&master[1];
That last thing looks pretty awkward, atleast a comment
explaining what is going on is necessary. I would have done
it like this:
/* Point chipselects to allocated memory beyond the main struct */
pl022->chipselects = (int *) pl022 + sizeof(struct pl022);
Maybe it's simpler to just devm_kzalloc() this array.
Thanks,
Linus Walleij
--
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] spi/pl022: Fill master->dev.of_node to get spi devices registered via DT
On Wed, Aug 22, 2012 at 11:16 AM, Viresh Kumar wrote: > On 19 August 2012 03:56, Linus Walleij wrote: >> On Sat, Aug 18, 2012 at 4:25 AM, Viresh Kumar >> Isn't this one of those things that *have* to be #ifdef CONFIG_OF? >> >> Next iteration, remember to add Mark Brown on To: because je's taking >> care of SPI patches for the moment. > > Ahh!! Forgot to reply :( > > Dropping this patch as it is already fixed in Roland's patches No problem, I was probably wrong anyway. It appears that part of the device struct is no longer ifdef:ed, so it will compile nicely. Yours, Linus Walleij -- 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 v4] spi/pl022: add devicetree support
On Mon, Aug 20, 2012 at 4:22 PM, Rob Herring wrote: > On 08/20/2012 06:39 AM, Alexandre Pereira da Silva wrote: >> +- pl022,hierarchy : master or slave interface > > Is attaching a master and using the pl022 as a slave really a supported > use case? No not currently. People doing this crazy stuff need to have the kernel with the hard real-time patches and lightening response first. But it's in the platform data because it's a feature supported by the hardware. > The DT spi bindings are really designed for a master node with > N slave nodes. So there is more general question of how to describe a > spi controller as a slave. It's not really one I care to answer as the > Linux spi framework isn't designed to act as a slave. Currently the code should hardwire this to master and not define a binding for it I think. >> +- pl022,slave-tx-disable : disconnect tx line in slave mode Applies also to this, then. >> +- pl022,com-mode : polling, interrupt or dma >> +- pl022,rx-level-trig : Rx FIFO watermark level >> +- pl022,tx-level-trig : Tx FIFO watermark level >> +- pl022,ctrl-len : Microwire interface: Control length >> +- pl022,wait-state : Microwire interface: Wait state >> +- pl022,duplex : Microwire interface: Full/Half duplex > > Most of these properties aren't used anywhere in the kernel other than > u300 and I'm not sure what to purpose of dummy_chip_info is. It is used for loopback-testing of the PL022. They're probably not necessary there either. > Perhaps > Linus has some input? I think either they can be decided by the spi > controller (com-mode, fifo watermark) or should be standard properties > (microwire settings). I would argue they should be removed if the spi > framework doesn't have support in a standard way. Uncertain about this, others would need to comment. At some point there has been a chip needing these to be set to some magic values. Yours, Linus Walleij -- 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 v4] spi/pl022: add devicetree support
fault controller_data settings\n");
> + }
Goes into second patch.
> @@ -1835,8 +1874,9 @@ static int pl022_setup(struct spi_device *spi)
> chip->xfer_type = chip_info->com_mode;
> if (!chip_info->cs_control) {
> chip->cs_control = null_cs_control;
> - dev_warn(&spi->dev,
> -"chip select function is NULL for this chip\n");
> + if (!gpio_is_valid(pl022->chipselect[spi->chip_select]))
> + dev_warn(&spi->dev,
> +"chip select function is NULL for this
> chip\n");
> } else
> chip->cs_control = chip_info->cs_control;
Goes into first patch.
> @@ -1988,7 +2028,8 @@ pl022_probe(struct amba_device *adev, const struct
> amba_id *id)
> struct pl022_ssp_controller *platform_info = adev->dev.platform_data;
> struct spi_master *master;
> struct pl022 *pl022 = NULL; /*Data for this driver */
> - int status = 0;
> + struct device_node *np = adev->dev.of_node;
Does this compile without CONFIG_OF?
(Second patch)
> + int status = 0, i, num_cs;
>
> dev_info(&adev->dev,
> "ARM PL022 driver, device ID: 0x%08x\n", adev->periphid);
> @@ -1998,8 +2039,14 @@ pl022_probe(struct amba_device *adev, const struct
> amba_id *id)
> goto err_no_pdata;
> }
>
> + num_cs = platform_info->num_chipselect;
> + if (IS_ENABLED(CONFIG_OF))
> + of_property_read_u32(np, "pl022,num-chipselects", &num_cs);
> +
> +
Shouldn't it be the other way around: platform data overrides
DT data. Attempt DT and if platform_info->num_chipselect
!= 0 let it override.
(Second patch.)
> /* Allocate master with space for data */
> - master = spi_alloc_master(dev, sizeof(struct pl022));
> + master = spi_alloc_master(dev,
> + sizeof(struct pl022) + sizeof(int) * num_cs);
First patch.
> if (master == NULL) {
> dev_err(&adev->dev, "probe - cannot alloc SPI master\n");
> status = -ENOMEM;
> @@ -2017,13 +2064,41 @@ pl022_probe(struct amba_device *adev, const struct
> amba_id *id)
> * on this board
> */
> master->bus_num = platform_info->bus_id;
> - master->num_chipselect = platform_info->num_chipselect;
> + master->num_chipselect = num_cs;
OK first patch.
> master->cleanup = pl022_cleanup;
> master->setup = pl022_setup;
> master->prepare_transfer_hardware = pl022_prepare_transfer_hardware;
> master->transfer_one_message = pl022_transfer_one_message;
> master->unprepare_transfer_hardware =
> pl022_unprepare_transfer_hardware;
> master->rt = platform_info->rt;
> + master->dev.of_node = dev->of_node;
Does this compile without CONFIG_OF?
Second patch.
> + if (IS_ENABLED(CONFIG_OF)) {
> + for (i = 0; i < num_cs; i++) {
> + int cs_gpio = of_get_named_gpio(np, "cs-gpios", i);
> +
> + if (cs_gpio == -EPROBE_DEFER) {
> + status = -EPROBE_DEFER;
> + goto err_no_gpio;
> + }
> +
> + pl022->chipselect[i] = cs_gpio;
> +
> + if (gpio_is_valid(cs_gpio)) {
> + if (gpio_request(cs_gpio, "ssp-pl022"))
> + dev_err(&adev->dev,
> + "could not request %d gpio\n",
> + cs_gpio);
> + else if (gpio_direction_output(cs_gpio, 1))
> + dev_err(&adev->dev,
> + "could set gpio %d as
> output\n",
> + cs_gpio);
> + }
> + }
> + } else {
> + for (i = 0; i < num_cs; i++)
> + pl022->chipselect[i] = -EINVAL;
Why? Instead, add a int *chipselects; field to the struct pl022_ssp_controller
platform data in include/linux/amba/pl022.h and copy it from there if
num_chipselects in the same data != 0.
(First patch.)
Yours,
Linus Walleij
--
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] spi/pl022: Fill master->dev.of_node to get spi devices registered via DT
On Sat, Aug 18, 2012 at 4:25 AM, Viresh Kumar wrote: > spi_register_master() calls of_register_spi_devices() to register spi devices. > This routine expects master->dev.of_node to be a valid pointer. This is > responsibility of master driver to fill this field, which wasn't done for > pl022. > Fix it to get devices added to pl022. OK... > master->rt = platform_info->rt; > + master->dev.of_node = dev->of_node; Isn't this one of those things that *have* to be #ifdef CONFIG_OF? Next iteration, remember to add Mark Brown on To: because je's taking care of SPI patches for the moment. Yours, Linus Walleij -- 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/pl022: fix spi-pl022 pm enable at probe
From: Michel JAOUEN amba drivers does not need to enable pm runtime at probe. amba_probe already enables pm runtime. This rids this warning in the ux500 boot log: ssp-pl022 ssp0: Unbalanced pm_runtime_enable! Signed-off-by: Michel JAOUEN Signed-off-by: Linus Walleij --- drivers/spi/spi-pl022.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c index aab518e..6abbe23 100644 --- a/drivers/spi/spi-pl022.c +++ b/drivers/spi/spi-pl022.c @@ -2053,7 +2053,6 @@ pl022_probe(struct amba_device *adev, const struct amba_id *id) printk(KERN_INFO "pl022: mapped registers from 0x%08x to %p\n", adev->res.start, pl022->virtbase); - pm_runtime_enable(dev); pm_runtime_resume(dev); pl022->clk = clk_get(&adev->dev, NULL); -- 1.7.11.3 -- 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 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 ... Yours, Linus Walleij -- 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 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 Yours, Linus Walleij -- 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
Fwd: [GIT PULL] PL022 patches for v3.6
Hi Mark, Can you please pull in these PL022 patches to your spi-next tree? Yours, Linus Walleij -- Forwarded message -- From: Linus Walleij Date: Thu, Jul 5, 2012 at 4:27 PM Subject: [GIT PULL] PL022 patches for v3.6 To: Wolfram Sang Cc: spi mailing list , Alexandre Pereira , Virupax Sadashivpetimath Hi Wolfram, since I guess you're gonna harvest SPI patches for the next merge window could you please pull this set of PL022 patches? The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678: Linux 3.5-rc5 (2012-06-30 16:08:57 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git pl022 for you to fetch changes up to 5b063b87deba33ed1676db9d16c52ede662132d8: spi/pl022: cleanup pl022 header documentation (2012-07-02 13:55:36 +0200) Alexandre Pereira da Silva (1): spi/pl022: cleanup pl022 header documentation Linus Walleij (2): spi/pl022: delete DB5500 support spi/pl022: enable runtime PM Virupax Sadashivpetimath (1): spi/pl022: disable port when unused drivers/spi/spi-pl022.c| 23 +-- include/linux/amba/pl022.h |9 + 2 files changed, 10 insertions(+), 22 deletions(-) Thanks, Linus Walleij -- 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 RFC] spi/gpio: start with CS non-active
On Mon, Jul 9, 2012 at 2:08 PM, Mark Brown wrote: > On Thu, Jul 05, 2012 at 09:45:40AM +0200, Uwe Kleine-K?nig wrote: >> On Thu, Feb 09, 2012 at 10:21:45PM +0100, Uwe Kleine-K?nig wrote: >> > The chip select line was configured as output with the initial value >> > being active explicitly. It was later deasserted during >> > spi_bitbang_setup() without any clock activity in between. So it makes >> > no sense to activate the device at all and the chip select line can >> > better start non-active. >> > >> > Signed-off-by: Uwe Kleine-K?nig >> > --- >> > Hello, >> > >> > I'm not sure if an active chip select line without any clock activity can >> > confuse a device. If so, this patch might qualify as fix. But with my >> > limited knowledge about spi it's also possible that I just miss why the >> > active chip select is important. For the devices I have it doesn't seem >> > to make a difference. >> ping > > You probably want to resend this with Linus W in the CCs. It all makes sense to me so: Acked-by: Linus Walleij Now the SPI maintainer needs to pick it up though, if your proposal to pick it up goes through this patch is all yours now. Yours, Linus Walleij -- 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
[GIT PULL] PL022 patches for v3.6
Hi Wolfram, since I guess you're gonna harvest SPI patches for the next merge window could you please pull this set of PL022 patches? The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678: Linux 3.5-rc5 (2012-06-30 16:08:57 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git pl022 for you to fetch changes up to 5b063b87deba33ed1676db9d16c52ede662132d8: spi/pl022: cleanup pl022 header documentation (2012-07-02 13:55:36 +0200) Alexandre Pereira da Silva (1): spi/pl022: cleanup pl022 header documentation Linus Walleij (2): spi/pl022: delete DB5500 support spi/pl022: enable runtime PM Virupax Sadashivpetimath (1): spi/pl022: disable port when unused drivers/spi/spi-pl022.c| 23 +-- include/linux/amba/pl022.h |9 + 2 files changed, 10 insertions(+), 22 deletions(-) Thanks, Linus Walleij -- 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/s3c64xx: Expand S3C64XX_SPI_{DE,}ACT macros at call sites
On Thu, Jun 28, 2012 at 3:23 PM, Mark Brown wrote: > They have very few users and they're both just doing a single register > write so the advantage of having the macro is a bit limited. An inline > function might make sense but it's as easy to just do the writes directly. > > Signed-off-by: Mark Brown Much clearer. Acked-by: Linus Walleij Yours, Linus Walleij -- 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/s3c64xx: Convert to devm_request_and_ioremap()
On Thu, Jun 28, 2012 at 3:23 PM, Mark Brown wrote: > Saves some error handling and a small amount of code. > > Signed-off-by: Mark Brown Elegant, monsieur. Acked-by: Linus Walleij I'm starting to wonder if it would not be possible to mass-convert these using coccinelle. Yours, Linus Walleij -- 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] spi: Unlock a spinlock before calling into the controller driver.
On Sat, Jun 23, 2012 at 7:53 AM, Bryan Freed wrote: > spi_pump_messages() calls into a controller driver with > unprepare_transfer_hardware() which is documented as "This may sleep". > As in the prepare_transfer_hardware() call below, we should release the > queue_lock spinlock before making the call. > Rework the logic a bit to hold queue_lock to protect the 'busy' flag, > then release it to call unprepare_transfer_hardware(). > > Signed-off-by: Bryan Freed Yes, this looks correct to me! Good catch. Acked-by: Linus Walleij Yours, Linus Walleij -- 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] spi: Unlock a spinlock before calling into the controller driver.
On Tue, Jun 26, 2012 at 1:07 AM, Doug Anderson wrote: > Specifically there should be only one instance of spi_pump_messages() > running at a time per master. That's because it's a kthread work > function. ...so we can't possibly get a prepare in the middle of the > unprepare when prepare is called because the only caller to > prepare/unprepare is spi_pump_messages(). Yes that's how the message pump is designed. > I can't comment on whether it's better to do something like add a > workqueue (which might be more obvious / less fragile) or just to add > a comment. I will let others comment on that. :) The message pump initially used a workqueue, but was converted to a kthread because we needed to push the queue to run as realtime for some important low-latency workloads across SPI. The code is basically a tweaked workqueue if you dive down in the implementation. Yours, Linus Walleij -- 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] spi: spi-pl022: Adjust probe() to of_get_named_gpio() returning -EPROBE_DEFER
On Mon, Jun 18, 2012 at 11:20 AM, Roland Stigge wrote: > The patch to gpiolib-of.c providing -EPROBE_DEFER as a hint to defer > of_get_named_gpio*() to a later probe() breaks spi-pl022.c. > > This patch adjusts to this change, using -EPROBE_DEFER as indication to defer. > > Signed-off-by: Roland Stigge Acked-by: Linus Walleij > Should this patch be joined with gpiolib-of's patch to of_get_named_gpio()? Or > should they just be issued as a series? If it's not bisectable unless you change this in the same patch then join them. Else I'd put them in a series and try to figure out a good tree for merging them. Yours, Linus Walleij -- 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] spi/pl022: cleanup pl022 header documentation
On Thu, Jun 14, 2012 at 3:10 PM, Alexandre Pereira da Silva wrote: > Remove the unused fields from struct ssp_config_chip that was removed > before > Add bus_id documentation to pl022_ssp_controller > > Signed-off-by: Alexandre Pereira da Silva > Signed-off-by: Roland Stigge Reviewed-by: Linus Walleij Thanks for fixing this! Grant, will you please pick this to the SPI tree. Yours, Linus Walleij -- 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 v2] RFC: spi/sa1100: rewrite the SA1100 SPI driver
This heavily rewrites the SA1100 SPI driver and moves it to the
SPI subsystem. I seriously doubt it will work (though you're
encouraged to give it a spin). It is meant as a starting
point for others who are able to pick up on it. I discussed
this with Kristoffer some time back.
The Jornada 720 seems to be the only in-kernel user of the SSP,
so the MCU driver (now called jornada720_ssp.c) is now an
SPI device on the SPI bus, and the jornada720_ssp is just
"some SPI device". Anything generic (like GPIO toggling to
sync to the other side) is now in the SPI driver. The
spinlock across transfers found in jornada720_ssp is probably
not going to play well with the SPI subsystem so this has
been replaced by a mutex.
Cc: Kristoffer Ericson
Cc: Nicolas Pitre
Cc: Russell King
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Rebase to v3.5-rc1
- Move SA1100 SSP platform data to
- Store bits per word (bpw) for the device in the state holder.
- Rewrite to use the new transfer queue.
- Delete reference to the FIFO data register from SA-1100.h since
SA1100 now uses dmaengine and the device tells the engine what
register to use.
- Use devm_* family for iomap, irq request etc.
Kristoffer, can you test this on the Jornada? I suspect you're
the only one who can actually take the SSP driver for a ride on
real hardware.
---
arch/arm/include/asm/hardware/ssp.h | 28 --
arch/arm/mach-sa1100/Kconfig| 10 +-
arch/arm/mach-sa1100/Makefile |1 -
arch/arm/mach-sa1100/include/mach/SA-1100.h | 83 +-
arch/arm/mach-sa1100/jornada720.c | 52 +++-
arch/arm/mach-sa1100/jornada720_ssp.c | 79 ++---
arch/arm/mach-sa1100/ssp.c | 243 --
drivers/spi/Kconfig |7 +
drivers/spi/Makefile|1 +
drivers/spi/spi-sa1100.c| 470 +++
include/linux/platform_data/sa1100-ssp.h| 15 +
11 files changed, 574 insertions(+), 415 deletions(-)
delete mode 100644 arch/arm/include/asm/hardware/ssp.h
delete mode 100644 arch/arm/mach-sa1100/ssp.c
create mode 100644 drivers/spi/spi-sa1100.c
create mode 100644 include/linux/platform_data/sa1100-ssp.h
diff --git a/arch/arm/include/asm/hardware/ssp.h
b/arch/arm/include/asm/hardware/ssp.h
deleted file mode 100644
index 3b42e18..000
--- a/arch/arm/include/asm/hardware/ssp.h
+++ /dev/null
@@ -1,28 +0,0 @@
-/*
- * ssp.h
- *
- * Copyright (C) 2003 Russell King, All Rights Reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#ifndef SSP_H
-#define SSP_H
-
-struct ssp_state {
- unsigned intcr0;
- unsigned intcr1;
-};
-
-int ssp_write_word(u16 data);
-int ssp_read_word(u16 *data);
-int ssp_flush(void);
-void ssp_enable(void);
-void ssp_disable(void);
-void ssp_save_state(struct ssp_state *ssp);
-void ssp_restore_state(struct ssp_state *ssp);
-int ssp_init(void);
-void ssp_exit(void);
-
-#endif
diff --git a/arch/arm/mach-sa1100/Kconfig b/arch/arm/mach-sa1100/Kconfig
index 42625e4..cb1c115 100644
--- a/arch/arm/mach-sa1100/Kconfig
+++ b/arch/arm/mach-sa1100/Kconfig
@@ -95,7 +95,8 @@ config SA1100_JORNADA720
config SA1100_JORNADA720_SSP
bool "HP Jornada 720 Extended SSP driver"
- select SA1100_SSP
+ select SPI
+ select SPI_SA1100
depends on SA1100_JORNADA720
help
Say Y here if you have a HP Jornada 7xx handheld computer and you
@@ -157,13 +158,6 @@ config SA1100_SIMPAD
like CL4 in additional it has a PCMCIA-Slot. For more information
visit <http://www.usa.siemens.com/> or <http://www.siemens.ch/>.
-config SA1100_SSP
- tristate "Generic PIO SSP"
- help
- Say Y here to enable support for the generic PIO SSP driver.
- This isn't for audio support, but for attached sensors and
- other devices, eg for BadgePAD 4 sensor support.
-
endmenu
endif
diff --git a/arch/arm/mach-sa1100/Makefile b/arch/arm/mach-sa1100/Makefile
index 60b97ec..b7f348e 100644
--- a/arch/arm/mach-sa1100/Makefile
+++ b/arch/arm/mach-sa1100/Makefile
@@ -51,5 +51,4 @@ obj-$(CONFIG_LEDS) += $(led-y)
# Miscellaneous functions
obj-$(CONFIG_PM) += pm.o sleep.o
-obj-$(CONFIG_SA1100_SSP) += ssp.o
diff --git a/arch/arm/mach-sa1100/include/mach/SA-1100.h
b/arch/arm/mach-sa1100/include/mach/SA-1100.h
index 3f2d1b6..b6310b2 100644
--- a/arch/arm/mach-sa1100/include/mach/SA-1100.h
+++ b/arch/arm/mach-sa1100/include/mach/SA-1100.h
@@ -727,86 +727,8 @@
#define MCCR1_F10MHz (MCCR1_CFS*1) /* Freq. (fmc) = ~ 10 MHz */
/* (9.585 MHz)*/
-
-/*
- * Synchronous Serial Port (SSP) control regis
[PATCH 3/3] spi/pl022: enable runtime PM
From: Linus Walleij
If we're gonna use runtime PM it's a pretty good idea to actually
enable it in probe() and disable it in remove() too, so it
gets used for real. Up until now we only fooled around with the
reference count.
Cc: Vinit Shenoy
Signed-off-by: Linus Walleij
---
drivers/spi/spi-pl022.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index 5eab281..aab518e 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -2053,6 +2053,9 @@ pl022_probe(struct amba_device *adev, const struct
amba_id *id)
printk(KERN_INFO "pl022: mapped registers from 0x%08x to %p\n",
adev->res.start, pl022->virtbase);
+ pm_runtime_enable(dev);
+ pm_runtime_resume(dev);
+
pl022->clk = clk_get(&adev->dev, NULL);
if (IS_ERR(pl022->clk)) {
status = PTR_ERR(pl022->clk);
@@ -2163,6 +2166,7 @@ pl022_remove(struct amba_device *adev)
clk_disable(pl022->clk);
clk_unprepare(pl022->clk);
clk_put(pl022->clk);
+ pm_runtime_disable(&adev->dev);
iounmap(pl022->virtbase);
amba_release_regions(adev);
tasklet_disable(&pl022->pump_transfers);
--
1.7.9.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 1/3] spi/pl022: disable port when unused
From: Virupax Sadashivpetimath Commit ffbbdd21329f3e15eeca6df2d4bc11c04d9d91c0 "spi: create a message queueing infrastructure" Accidentally deleted the logic to disable the port when unused leading to higher power consumption. Fix this up. Cc: sta...@kernel.org Cc: Vinit Shenoy Signed-off-by: Virupax Sadashivpetimath Signed-off-by: Linus Walleij --- drivers/spi/spi-pl022.c |5 + 1 file changed, 5 insertions(+) diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c index 400ae21..469eb28 100644 --- a/drivers/spi/spi-pl022.c +++ b/drivers/spi/spi-pl022.c @@ -489,6 +489,11 @@ static void giveback(struct pl022 *pl022) pl022->cur_transfer = NULL; pl022->cur_chip = NULL; spi_finalize_current_message(pl022->master); + + /* disable the SPI/SSP operation */ + writew((readw(SSP_CR1(pl022->virtbase)) & + (~SSP_CR1_MASK_SSE)), SSP_CR1(pl022->virtbase)); + } /** -- 1.7.9.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 2/3] spi/pl022: delete DB5500 support
From: Linus Walleij
This ASIC variant has been deleted from the ARM tree, no need
to keep support around.
Cc: Vinit Shenoy
Signed-off-by: Linus Walleij
---
drivers/spi/spi-pl022.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index 469eb28..5eab281 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -2256,15 +2256,6 @@ static struct vendor_data vendor_st_pl023 = {
.loopback = false,
};
-static struct vendor_data vendor_db5500_pl023 = {
- .fifodepth = 32,
- .max_bpw = 32,
- .unidir = false,
- .extended_cr = true,
- .pl023 = true,
- .loopback = true,
-};
-
static struct amba_id pl022_ids[] = {
{
/*
@@ -2296,11 +2287,6 @@ static struct amba_id pl022_ids[] = {
.mask = 0x,
.data = &vendor_st_pl023,
},
- {
- .id = 0x10080023,
- .mask = 0x,
- .data = &vendor_db5500_pl023,
- },
{ 0, 0 },
};
--
1.7.9.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
Re: [PATCH 2/9] SPI: Refactor spi-orion to use SPI framework queue.
On Sun, Jun 10, 2012 at 12:31 PM, Andrew Lunn wrote: > Replace the deprecated master->transfer with transfer_one_message() > and allow the SPI subsystem handle all the queuing of messages. > > Signed-off-by: Andrew Lunn > Acked-by: Linus Walleij Looks good to me: Acked-by: Linus Walleij Yours, Linus Walleij -- 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: [CFT 07/11] spi: omap2-mcspi: add DMA engine support
On Thu, Jun 7, 2012 at 1:08 PM, Russell King wrote: > Add DMA engine support to the OMAP SPI driver. This supplements the > private DMA API implementation contained within this driver, and the > driver can be independently switched at build time between using DMA > engine and the private DMA API for the transmit and receive sides. > > Tested-by: Shubhrajyoti > Acked-by: Grant Likely > Signed-off-by: Russell King This looks very good, Acked-by: Linus Walleij Thanks, Linus Walleij -- 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 3/3] spi: bitbang: convert to using core message queue
On Mon, May 21, 2012 at 1:25 PM, Guennadi Liakhovetski wrote: > The SPI subsystem core now manages message queues internally. Remove the > local message queue implementation from the spi-bitbang driver and > migrate to the common one. > > Signed-off-by: Guennadi Liakhovetski Acked-by: Linus Walleij Thanks, Linus Walleij -- 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] spi: bitbang: convert to using core message queue
On Sat, Mar 17, 2012 at 12:39 AM, Guennadi Liakhovetski wrote: > The SPI subsystem core now manages message queues internally. Remove the > local message queue implementation from the spi-bitbang driver and > migrate to the common one. > > Signed-off-by: Guennadi Liakhovetski Grant have you picked this patch? It arrived pretty early so should be quite ripe by now... Yours, Linus Walleij -- 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] SPI: PRIMA2: use the newest APIs of PINCTRL to fix compiling errors
On Tue, May 15, 2012 at 4:21 AM, Barry Song wrote: > From: Barry Song > > Fix the compiling errors: > drivers/spi/spi-sirf.c: In function 'spi_sirfsoc_probe': > drivers/spi/spi-sirf.c:563: error: implicit declaration of function > 'pinmux_get' > drivers/spi/spi-sirf.c:563: warning: assignment makes pointer from integer > without a cast > drivers/spi/spi-sirf.c:568: error: implicit declaration of function > 'pinmux_enable' > drivers/spi/spi-sirf.c:602: error: implicit declaration of function > 'pinmux_disable' > drivers/spi/spi-sirf.c:603: error: implicit declaration of function > 'pinmux_put' > make[3]: *** [drivers/spi/spi-sirf.o] Error 1 > > Signed-off-by: Barry Song > Cc: Guennadi Liakhovetski > Cc: Linus Walleij Acked-by: Linus Walleij Counting on Grant to pick this up... Yours, Linus Walleij -- 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] spi/omap2-mcspi: convert to the pump message infrastructure
On Thu, May 10, 2012 at 2:57 PM, Shubhrajyoti D wrote: > This patch converts the OMAP SPI driver to use the SPI infrastructure > pump message queue.Also fixes the below warning. > master is unqueued, this is deprecated > > Signed-off-by: Shubhrajyoti D Final version of the patch? Acked-by: Linus Walleij Yours, Linus Walleij -- 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
