[PATCH - v2] spi: davinci: add OF support for the spi controller
This adds OF support to DaVinci SPI controller to configure platform
data through device bindings. Also replaces clk_enable() with
of clk_prepare_enable() as well as clk_disable() with
clk_disable_unprepare().
Signed-off-by: Murali Karicheri m-kariche...@ti.com
Reviewed-by : Grant Likely grant.lik...@secretlab.ca
---
- Change log
- v2 - changed the compatibility strings to include soc name
- changed ti,davinci-num-cs to num-cs
v1 - removed attribute for spi version. instead, compatibility string is
modified to include version info.
- pdata ptr in davinci_spi_platform_data is replaced with struct itself.
- spi_davinci_get_pdata() now populates the pdata in the above structure
with parsed values from DT bindings.
- rebased to v3.7 rc7 of linux-next
- replaces clk_* APIs with their prepare/unprepare version
.../devicetree/bindings/spi/spi-davinci.txt| 51 ++
drivers/spi/spi-davinci.c | 102 +---
2 files changed, 139 insertions(+), 14 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/spi-davinci.txt
diff --git a/Documentation/devicetree/bindings/spi/spi-davinci.txt
b/Documentation/devicetree/bindings/spi/spi-davinci.txt
new file mode 100644
index 000..8cb3fee
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-davinci.txt
@@ -0,0 +1,51 @@
+Davinci SPI controller device bindings
+
+Required properties:
+- #address-cells: number of cells required to define a chip select
+ address on the SPI bus. Should be set to 1.
+- #size-cells: should be zero.
+- compatible:
+ - ti,dm644x-spi for SPI used similar to that on DM644x SoC family
+ - ti,da8xx-spi for SPI used similar to that on DA8xx SoC family
+- reg: Offset and length of SPI controller register space
+- num-cs: Number of chip selects
+- ti,davinci-spi-intr-line: interrupt line used to connect the SPI
+ IP to the interrupt controller withn the SoC. Possible values
+ are 0 and 1. Manual says one of the two possible interrupt
+ lines can be tied to the interrupt controller. Set this
+ based on a specifc SoC configuration.
+- interrupts: interrupt number offset at the irq parent
+- clocks: spi clk phandle
+
+Example of a NOR flash slave device (n25q032) connected to DaVinci
+SPI controller device over the SPI bus.
+
+spi0:spi@20BF {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = ti,dm644x-spi;
+ reg = 0x20BF 0x1000;
+ num-cs = 4;
+ ti,davinci-spi-intr-line= 0;
+ interrupts = 338;
+ clocks = clkspi;
+
+ flash: n25q032@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = st,m25p32;
+ spi-max-frequency = 2500;
+ reg = 0;
+
+ partition@0 {
+ label = u-boot-spl;
+ reg = 0x0 0x8;
+ read-only;
+ };
+
+ partition@1 {
+ label = test;
+ reg = 0x8 0x38;
+ };
+ };
+};
diff --git a/drivers/spi/spi-davinci.c b/drivers/spi/spi-davinci.c
index 147dfa8..e5d8489 100644
--- a/drivers/spi/spi-davinci.c
+++ b/drivers/spi/spi-davinci.c
@@ -28,6 +28,8 @@
#include linux/dmaengine.h
#include linux/dma-mapping.h
#include linux/edma.h
+#include linux/of.h
+#include linux/of_device.h
#include linux/spi/spi.h
#include linux/spi/spi_bitbang.h
#include linux/slab.h
@@ -135,7 +137,7 @@ struct davinci_spi {
int dma_rx_chnum;
int dma_tx_chnum;
- struct davinci_spi_platform_data *pdata;
+ struct davinci_spi_platform_data pdata;
void(*get_rx)(u32 rx_data, struct davinci_spi *);
u32 (*get_tx)(struct davinci_spi *);
@@ -213,7 +215,7 @@ static void davinci_spi_chipselect(struct spi_device *spi,
int value)
bool gpio_chipsel = false;
dspi = spi_master_get_devdata(spi-master);
- pdata = dspi-pdata;
+ pdata = dspi-pdata;
if (pdata-chip_sel chip_sel pdata-num_chipselect
pdata-chip_sel[chip_sel] != SPI_INTERN_CS)
@@ -392,7 +394,7 @@ static int davinci_spi_setup(struct spi_device *spi)
struct davinci_spi_platform_data *pdata;
dspi = spi_master_get_devdata(spi-master);
- pdata = dspi-pdata;
+ pdata = dspi-pdata;
/* if bits per word length is zero then set it default 8 */
if (!spi-bits_per_word)
@@ -534,7 +536,7 @@ static int davinci_spi_bufs(struct spi_device *spi, struct
spi_transfer *t)
struct scatterlist sg_rx, sg_tx;
dspi =
RE: [PATCH v3 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP
-Original Message-
From: Nori, Sekhar
Sent: Friday, November 30, 2012 2:51 AM
Hi Rob,
On 11/29/2012 7:08 AM, Tivy, Robert wrote:
Hi Sekhar,
Please see comments and noob questions below...
They can run a single image if the image supports overriding the
Kconfig settings with kernel command-line arguments.
The most basic solution is constants in the .c file itself. A better
solution is Kconfig settings used by the .c file. An even better
solution is Kconfig settings with kernel command-line overrides.
If you have kernel command line, you could default to some values which
are sane in most cases if they are not provided. No, need to have a
Kconfig as well. That will be too many hooks to control the same things
and probably not necessary.
If you want the remoteproc driver to allocate a certain area of
memory
to the dsp, why don't you take that value as a module parameter so
people who need different values can pass them differently? It is
not
clear to me why this memory management needs to be dealt with in
platform code.
Unfortunetly we need to reserve this dsp memory during early boot,
using CMA. Runtime module insertion is too late.
Then I guess most of the time the module would be built into the kernel
and will be initialized using an early enough initcall.
That's right, a .reserve function is assigned to the MACHINE_START structure,
and this function calls dma_declare_contiguous().
+
+static int __init early_rproc_mem(char *p) {
+ char *endp;
+
+ rproc_size = memparse(p, endp);
+ if (*endp == '@')
+ rproc_base = memparse(endp + 1, NULL);
+
+ return 0;
+}
+early_param(rproc_mem, early_rproc_mem);
Use of non-standard kernel parameters is discouraged. All kernel
parameters should be documented in Documentation/kernel-
parameters.txt
(this means each and every kernel parameter needs to be justified
well).
Can I use the kernel command-line (i.e., u-boot bootargs variable) to
specify non-kernel parameters? I guess my question is more one about
the terminology kernel parameter - is there a way to specify a module
parameter on the kernel command line (like, perhaps, rproc.membase and
rproc.memsize)?
Right. Module parameters are passed from kernel command line when the
module is built into the kernel.
Unfortunately, it seems that module parameters, when stated on the kernel
command line with module-name.var-name syntax, are not yet assigned when the
kernel calls the early init .reserve functions. For the char * I'm using, I
observed a NULL value during the early init call and the proper assigned value
during a later normal __init function.
Is there any other method that allows specifying a parameter for an early CMA
reservation without having to rebuild the kernel?
If not, is this a strong enough use case to justify a new kernel parameter?
I guess I don't understand why non-standard kernel parameters are discouraged.
I can adorn the name with enough module-specific naming to reduce the chances
of any namespace collisions to a minimum.
Regards,
- Rob
Thanks,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 2/5] media: davinci: fix return value check in vpbe_display_reqbufs().
Hi Cyril,
On Wed, Dec 12, 2012 at 5:54 AM, Cyril Roelandt tipec...@gmail.com wrote:
vb2_dma_contig_init_ctx() returns ERR_PTR and never returns NULL, so IS_ERR
should be used instead of a NULL check.
patch fixing this issue has been already posted with a better fix
https://patchwork.kernel.org/patch/1830231/
Regards,
--Prabhakar Lad
Signed-off-by: Cyril Roelandt tipec...@gmail.com
---
drivers/media/platform/davinci/vpbe_display.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/davinci/vpbe_display.c
b/drivers/media/platform/davinci/vpbe_display.c
index 2bfde79..2db4eff 100644
--- a/drivers/media/platform/davinci/vpbe_display.c
+++ b/drivers/media/platform/davinci/vpbe_display.c
@@ -1393,7 +1393,7 @@ static int vpbe_display_reqbufs(struct file *file, void
*priv,
}
/* Initialize videobuf queue as per the buffer type */
layer-alloc_ctx = vb2_dma_contig_init_ctx(vpbe_dev-pdev);
- if (!layer-alloc_ctx) {
+ if (IS_ERR(layer-alloc_ctx)) {
v4l2_err(vpbe_dev-v4l2_dev, Failed to get the context\n);
return -EINVAL;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] da8xx: Allow use by am33xx based devices
Hi Vaibhav, On Mon, Dec 10, 2012 at 14:32:06, Hiremath, Vaibhav wrote: On 12/6/2012 1:38 PM, Manjunathappa, Prakash wrote: Hi Tomi, On Wed, Oct 31, 2012 at 10:52:59, Manjunathappa, Prakash wrote: Hi, On Wed, Oct 31, 2012 at 21:26:08, Pantelis Antoniou wrote: This driver can be used for AM33xx devices, like the popular beaglebone. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- drivers/video/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 9791d10..e7868d8 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -2202,7 +2202,7 @@ config FB_SH7760 config FB_DA8XX tristate DA8xx/OMAP-L1xx Framebuffer support - depends on FB ARCH_DAVINCI_DA8XX + depends on FB (ARCH_DAVINCI_DA8XX || SOC_AM33XX) Agreed this is present on da8xx and am33xx, but moving forward for supporting DT, we should be avoiding these dependencies. So instead change this to remove machine dependencies. I could be wrong here, having dependency on platform seems to be right. Otherwise may lead to build errors for other platforms. No, it should not result in to build error unless driver uses some platform specific api's. Agreed, should not result in build error. But is it ok to show this option on the platforms which do not have this IP? Thanks, Prakash ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
