Re: [PATCH 10/10] spi: s3c64xx: add device tree support
On Wed, May 09, 2012 at 03:34:54AM +0530, Thomas Abraham wrote: +- gpios: The gpio specifier for clock, mosi and miso interface lines (in no + particular order). The format of the gpio specifier depends on the gpio + controller. This seems odd... This isn't a bitbanging controller, and surely the driver will need to know which signal is which? I suspect this is actually for pinmux rather than to identify the signals but that should at least be made clear and really should be being done using the pinmux API. + - samsung,spi-cs-gpio: A gpio specifier that specifies the gpio line used as +the slave select line by the spi controller. The format of the gpio +specifier depends on the gpio controller. We should really have a binding for this at the SPI level (and ideally some code to manage setting the GPIO too) - it's pretty common to use a GPIO as /CS. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/10] spi: s3c64xx: add device tree support
On 9 May 2012 17:07, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Wed, May 09, 2012 at 03:34:54AM +0530, Thomas Abraham wrote: +- gpios: The gpio specifier for clock, mosi and miso interface lines (in no + particular order). The format of the gpio specifier depends on the gpio + controller. This seems odd... This isn't a bitbanging controller, and surely the driver will need to know which signal is which? I suspect this is actually for pinmux rather than to identify the signals but that should at least be made clear and really should be being done using the pinmux API. The driver retrieves the list of gpio's that it is allowed to use. The gpio numbers for miso, mosi and clk are mandatory but the order in which they are specified is not important since the driver never needs to which gpio is which interface line. I agree the pinmux api should be used here, but the call to pinmux api would be a incremental change here, not changing the code this patch is adding. + - samsung,spi-cs-gpio: A gpio specifier that specifies the gpio line used as + the slave select line by the spi controller. The format of the gpio + specifier depends on the gpio controller. We should really have a binding for this at the SPI level (and ideally some code to manage setting the GPIO too) - it's pretty common to use a GPIO as /CS. The existing implementations vary in the way the nCS gpio lines are specified. For some controllers, the nCS gpio's are included in the spi device node whereas in this implementation, the nCS gpio is listed in the spi slave device node. Thanks, Thomas. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/10] spi: s3c64xx: add device tree support
On Wed, May 09, 2012 at 10:13:28PM +0800, Thomas Abraham wrote: On 9 May 2012 17:07, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Wed, May 09, 2012 at 03:34:54AM +0530, Thomas Abraham wrote: +- gpios: The gpio specifier for clock, mosi and miso interface lines (in no + particular order). The format of the gpio specifier depends on the gpio + controller. This seems odd... This isn't a bitbanging controller, and surely the driver will need to know which signal is which? I suspect this is actually for pinmux rather than to identify the signals but that should at least be made clear and really should be being done using the pinmux API. The driver retrieves the list of gpio's that it is allowed to use. The gpio numbers for miso, mosi and clk are mandatory but the order in which they are specified is not important since the driver never needs to which gpio is which interface line. I agree the pinmux api should be used here, but the call to pinmux api would be a incremental change here, not changing the code this patch is adding. I'd suggest just specifying the order - someone might want to use it later for some reason and it's not really a hardship for someone to use it. Avoids any how does that work? questions like I had. + - samsung,spi-cs-gpio: A gpio specifier that specifies the gpio line used as + the slave select line by the spi controller. The format of the gpio + specifier depends on the gpio controller. We should really have a binding for this at the SPI level (and ideally some code to manage setting the GPIO too) - it's pretty common to use a GPIO as /CS. The existing implementations vary in the way the nCS gpio lines are specified. For some controllers, the nCS gpio's are included in the spi device node whereas in this implementation, the nCS gpio is listed in the spi slave device node. Yeah, I know. I'm saying we should try to come up with a binding for this that can be used by new SPI contollers going forward so things are consistent. signature.asc Description: Digital signature
Re: [PATCH 10/10] spi: s3c64xx: add device tree support
On 9 May 2012 22:32, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Wed, May 09, 2012 at 10:13:28PM +0800, Thomas Abraham wrote: On 9 May 2012 17:07, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Wed, May 09, 2012 at 03:34:54AM +0530, Thomas Abraham wrote: +- gpios: The gpio specifier for clock, mosi and miso interface lines (in no + particular order). The format of the gpio specifier depends on the gpio + controller. This seems odd... This isn't a bitbanging controller, and surely the driver will need to know which signal is which? I suspect this is actually for pinmux rather than to identify the signals but that should at least be made clear and really should be being done using the pinmux API. The driver retrieves the list of gpio's that it is allowed to use. The gpio numbers for miso, mosi and clk are mandatory but the order in which they are specified is not important since the driver never needs to which gpio is which interface line. I agree the pinmux api should be used here, but the call to pinmux api would be a incremental change here, not changing the code this patch is adding. I'd suggest just specifying the order - someone might want to use it later for some reason and it's not really a hardship for someone to use it. Avoids any how does that work? questions like I had. Ok. I will add the order of the gpios as you have suggested. + - samsung,spi-cs-gpio: A gpio specifier that specifies the gpio line used as + the slave select line by the spi controller. The format of the gpio + specifier depends on the gpio controller. We should really have a binding for this at the SPI level (and ideally some code to manage setting the GPIO too) - it's pretty common to use a GPIO as /CS. The existing implementations vary in the way the nCS gpio lines are specified. For some controllers, the nCS gpio's are included in the spi device node whereas in this implementation, the nCS gpio is listed in the spi slave device node. Yeah, I know. I'm saying we should try to come up with a binding for this that can be used by new SPI contollers going forward so things are consistent. Ok. For this patch series, I will continue with the samsung specific binding for the nCS line. Thanks, Thomas. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/10] spi: s3c64xx: add device tree support
On Thu, May 10, 2012 at 12:39:29AM +0800, Thomas Abraham wrote: On 9 May 2012 22:32, Mark Brown broo...@opensource.wolfsonmicro.com wrote: Yeah, I know. I'm saying we should try to come up with a binding for this that can be used by new SPI contollers going forward so things are consistent. Ok. For this patch series, I will continue with the samsung specific binding for the nCS line. How about just renaming your binding to a generic one and documenting it separately? It looks like a sensible binding which other people should be able to use so may as well have something there already. signature.asc Description: Digital signature
Re: [PATCH 10/10] spi: s3c64xx: add device tree support
On 10 May 2012 00:47, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Thu, May 10, 2012 at 12:39:29AM +0800, Thomas Abraham wrote: On 9 May 2012 22:32, Mark Brown broo...@opensource.wolfsonmicro.com wrote: Yeah, I know. I'm saying we should try to come up with a binding for this that can be used by new SPI contollers going forward so things are consistent. Ok. For this patch series, I will continue with the samsung specific binding for the nCS line. How about just renaming your binding to a generic one and documenting it separately? It looks like a sensible binding which other people should be able to use so may as well have something there already. Ok. I will replace the samsung specific binding with a generic binding in the next version of this patch series. Thanks, Thomas. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/10] spi: s3c64xx: add device tree support
Add support for device based discovery.
Cc: Jaswinder Singh jaswinder.si...@linaro.org
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
.../devicetree/bindings/spi/spi-samsung.txt| 113
drivers/spi/spi-s3c64xx.c | 277 +---
2 files changed, 358 insertions(+), 32 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/spi-samsung.txt
diff --git a/Documentation/devicetree/bindings/spi/spi-samsung.txt
b/Documentation/devicetree/bindings/spi/spi-samsung.txt
new file mode 100644
index 000..2046c30
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-samsung.txt
@@ -0,0 +1,113 @@
+* Samsung SPI Controller
+
+The Samsung SPI controller is used to interface with various devices such as
flash
+and display controllers using the SPI communication interface.
+
+Required SoC Specific Properties:
+
+- compatible: should be one of the following.
+- samsung,s3c2443-spi: for s3c2443, s3c2416 and s3c2450 platforms
+- samsung,s3c6410-spi: for s3c6410 platforms
+- samsung,s5p6440-spi: for s5p6440 and s5p6450 platforms
+- samsung,s5pv210-spi: for s5pv210 and s5pc110 platforms
+- samsung,exynos4210-spi: for exynos4 and exynos5 platforms
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- interrupts: The interrupt number to the cpu. The interrupt specifier format
+ depends on the interrupt controller.
+
+- tx-dma-channel: The dma channel specifier for tx operations. The format of
+ the dma specifier depends on the dma controller.
+
+- rx-dma-channel: The dma channel specifier for rx operations. The format of
+ the dma specifier depends on the dma controller.
+
+Required Board Specific Properties:
+
+- #address-cells: should be 1.
+- #size-cells: should be 0.
+- gpios: The gpio specifier for clock, mosi and miso interface lines (in no
+ particular order). The format of the gpio specifier depends on the gpio
+ controller.
+
+Optional Board Specific Properties:
+
+- samsung,spi-src-clk: If the spi controller includes a internal clock mux to
+ select the clock source for the spi bus clock, this property can be used to
+ indicate the clock to be used for driving the spi bus clock. If not
specified,
+ the clock number 0 is used as default.
+
+- samsung,spi-num-cs: Specifies the number of chip select lines supported. If
+ not specified, the default number of chip select lines is set to 1.
+
+SPI Controller specific data in SPI slave nodes:
+
+- The spi slave nodes should provide the following information which is
required
+ by the spi controller.
+
+ - samsung,spi-cs-gpio: A gpio specifier that specifies the gpio line used as
+the slave select line by the spi controller. The format of the gpio
+specifier depends on the gpio controller.
+
+ - samsung,spi-feedback-delay: The sampling phase shift to be applied on the
+miso line (to account for any lag in the miso line). The following are the
+valid values.
+
+ - 0: No phase shift.
+ - 1: 90 degree phase shift sampling.
+ - 2: 180 degree phase shift sampling.
+ - 3: 270 degree phase shift sampling.
+
+Aliases:
+
+- All the SPI controller nodes should be represented in the aliases node using
+ the following format 'spi{n}' where n is a unique number for the alias.
+
+
+Example:
+
+- SoC Specific Portion:
+
+ spi_0: spi@12d2 {
+ compatible = samsung,exynos4210-spi;
+ reg = 0x12d2 0x100;
+ interrupts = 0 66 0;
+ tx-dma-channel = pdma0 5;
+ rx-dma-channel = pdma0 4;
+ };
+
+- Board Specific Portion:
+
+ spi_0: spi@12d2 {
+ #address-cells = 1;
+ #size-cells = 0;
+ gpios = gpa2 4 2 3 0,
+ gpa2 6 2 3 0,
+ gpa2 7 2 3 0;
+
+ w25q80bw@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = w25x80;
+ reg = 0;
+ spi-max-frequency = 1;
+
+ controller-data {
+ samsung,spi-cs-gpio = gpa2 5 1 0 3;
+ samsung,spi-feedback-delay = 0;
+ };
+
+ partition@0 {
+ label = U-Boot;
+ reg = 0x0 0x4;
+ read-only;
+ };
+
+ partition@4 {
+ label = Kernel;
+ reg = 0x4 0xc;
+ };
+ };
+ };
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index d84ce7f..8bc838d 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -27,6 +27,8 @@
#include linux/platform_device.h
#include linux/pm_runtime.h
