Re: [PATCH v4 08/12] gpio: add ti-ssp gpio driver
Hi Cyril, I am referring the SSP driver to implement the PRU MFD driver. I had a few concerns regarding this. First of all, does the SSP support multiple execution units, in a sense that its able to run multiple serial devices at once, like multiple channels. If so, then its definitely a MFD. But, on the other hand, the PRU is only a single execution unit i.e it can execute only a single firmware/protocol at a time. Secondly, since even PRU is multi-driver or so to say multi functional, will that be a reason good enough to categorize it as a MFD, even if there is only one execution unit. Thanks subhasish -- View this message in context: http://davinci-linux-open-source.1494791.n2.nabble.com/PATCH-v4-00-12-tnetv107x-ssp-driver-stack-tp5697400p5935432.html Sent from the davinci-linux-open-source mailing list archive at Nabble.com. ___ 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 v4 08/12] gpio: add ti-ssp gpio driver
On 01/18/2011 08:22 AM, Subhasish Ghosh wrote: Hi Cyril, I am referring the SSP driver to implement the PRU MFD driver. I had a few concerns regarding this. First of all, does the SSP support multiple execution units, in a sense that its able to run multiple serial devices at once, like multiple channels. If so, then its definitely a MFD. Yes, the SSP IP has two execution units (aka ports/cells) which can be programmed to run distinct protocols simultaneously. But, on the other hand, the PRU is only a single execution unit i.e it can execute only a single firmware/protocol at a time. Secondly, since even PRU is multi-driver or so to say multi functional, will that be a reason good enough to categorize it as a MFD, even if there is only one execution unit. Could you elaborate on the PRU usage scenario? Is the function fixed at init time, or will your drivers allow functions to be accessed in an interleaved fashion? In my opinion, if the function is fixed at init, MFD may be inappropriate. Sam and Dave (copied) may have better inputs on this. You can also dig up background discussions on the same topic from the ML archives. Regards - Cyril. ___ 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 v4 08/12] gpio: add ti-ssp gpio driver
Hi Cyril, PRU is basically a micro-controller embedded inside of da8xx processors. To emulate any protocol on it, we need to implement the protocol and download the firmware into the instruction RAM. Hence, if the firmware is implemented in such a was that its able to run different protocols simultaneously, then it can. But, still its only a single execution unit. On the other hand, we have two functionally identical PRUs inside da850, hence resulting in two execution units. We have implemented 4 different full duplex uarts utilizing both PRUs and also a single CAN controller utilizing both PRUs. But, its either UART or CAN, and not CAN and UART together, this decision being fixed init time. Again, as with any other micro controller, we can always stop the PRU and download another firmware to run another protocol/peripheral. Best Regards, Subhasish Ghosh On Tue, Jan 18, 2011 at 8:52 PM, Cyril Chemparathy cy...@ti.com wrote: On 01/18/2011 08:22 AM, Subhasish Ghosh wrote: Hi Cyril, I am referring the SSP driver to implement the PRU MFD driver. I had a few concerns regarding this. First of all, does the SSP support multiple execution units, in a sense that its able to run multiple serial devices at once, like multiple channels. If so, then its definitely a MFD. Yes, the SSP IP has two execution units (aka ports/cells) which can be programmed to run distinct protocols simultaneously. But, on the other hand, the PRU is only a single execution unit i.e it can execute only a single firmware/protocol at a time. Secondly, since even PRU is multi-driver or so to say multi functional, will that be a reason good enough to categorize it as a MFD, even if there is only one execution unit. Could you elaborate on the PRU usage scenario? Is the function fixed at init time, or will your drivers allow functions to be accessed in an interleaved fashion? In my opinion, if the function is fixed at init, MFD may be inappropriate. Sam and Dave (copied) may have better inputs on this. You can also dig up background discussions on the same topic from the ML archives. Regards - Cyril. ___ 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 v4 08/12] gpio: add ti-ssp gpio driver
On 11/10/2010 01:23 AM, Grant Likely wrote: On Tue, Nov 09, 2010 at 10:16:22PM -0800, David Brownell wrote: I thought the point of this device was that a single [SSP] device hosted a pair of multi-function serial interfaces, with each implementing a separate function. function chosen based on what the board needs. Codec interface, SPI, GPIO, etc. If so, then it makes sense for the base driver to register child devices of the appropriate kinds. I'd normally say board setup registers them; a coredriver can't know what children would be needed. But the point I was making was about code factoring not driver setup. When the functions don't have much commonality, they might as well just write to the relevant registers instead of expecting to have a non-register programming interface (of dubious generality of a core driver, but much complexity). Easier just to have children use registers directly, in several similar cases. Less overhead, too. I guess it depends on how much overlap/interlock there is between the multiple channels. If there is shared context, then that is a stronger argument for a shared api. Cyril, what say you? The channels (or ports) in this case are not very well separated out. The registers for these ports are interleaved, and in some cases different bits of the same register are meant for different ports. Second, with the exception of GPIO (which essentially bit bangs), all other functions would follow the same flow, i.e. set stuff up (mode, iosel), load up a sequence, kick off execution, and wait for completion. I thought it made sense to provide these pieces in a shared driver. Regards Cyril. ___ 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 v4 08/12] gpio: add ti-ssp gpio driver
On Tue, Nov 02, 2010 at 07:15:16PM -0700, David Brownell wrote: --- On Tue, 10/26/10, Cyril Chemparathy cy...@ti.com wrote: From: Cyril Chemparathy cy...@ti.com Subject: [PATCH v4 08/12] gpio: add ti-ssp gpio driver On the assumptions you've tested this *AND* will resubmit with the previously-requested change of removing all references to non-existent virtualness in the driver ... I'll likely add my ack to that resubmitted version Also, chip2gpio seems an excessively generic name; maybe chip2_ti_ssp_gpio or somesuch? I'd still be happier seeing this stack packaged as a hardware library called by various drivers (like GPIO, SPI, etc) rather than a core driver that's called by other drivers. That seems like a better structure for various vendors' SSP hardware (multifunction serial interface logic) since most function drivers just need to poke the registers a bit differently, and don't have much to share with a core driver beyond a few setup routines (if that). I thought the point of this device was that a single device hosted a pair of multi-function serial interfaces, with each implementing a separate function. If so, then it makes sense for the base driver to register child devices of the appropriate kinds. g. ___ 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 v4 08/12] gpio: add ti-ssp gpio driver
I thought the point of this device was that a single [SSP] device hosted a pair of multi-function serial interfaces, with each implementing a separate function. function chosen based on what the board needs. Codec interface, SPI, GPIO, etc. If so, then it makes sense for the base driver to register child devices of the appropriate kinds. I'd normally say board setup registers them; a coredriver can't know what children would be needed. But the point I was making was about code factoring not driver setup. When the functions don't have much commonality, they might as well just write to the relevant registers instead of expecting to have a non-register programming interface (of dubious generality of a core driver, but much complexity). Easier just to have children use registers directly, in several similar cases. Less overhead, too. - Dave ___ 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 v4 08/12] gpio: add ti-ssp gpio driver
On Tue, Nov 09, 2010 at 10:16:22PM -0800, David Brownell wrote: I thought the point of this device was that a single [SSP] device hosted a pair of multi-function serial interfaces, with each implementing a separate function. function chosen based on what the board needs. Codec interface, SPI, GPIO, etc. If so, then it makes sense for the base driver to register child devices of the appropriate kinds. I'd normally say board setup registers them; a coredriver can't know what children would be needed. But the point I was making was about code factoring not driver setup. When the functions don't have much commonality, they might as well just write to the relevant registers instead of expecting to have a non-register programming interface (of dubious generality of a core driver, but much complexity). Easier just to have children use registers directly, in several similar cases. Less overhead, too. I guess it depends on how much overlap/interlock there is between the multiple channels. If there is shared context, then that is a stronger argument for a shared api. Cyril, what say you? g. ___ 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 v4 08/12] gpio: add ti-ssp gpio driver
--- On Wed, 11/3/10, Linus Walleij linus.ml.wall...@gmail.com wrote: \ Date: Wednesday, November 3, 2010, 3:18 AM 2010/11/3 David Brownell davi...@pacbell.net: That seems like a better structure for various vendors' SSP hardware (multifunction serial interface logic) Incidentally the ARM PrimeCell PL022 is called SSP, Synchronous Serial Port and is not multifunction at all. ISTR coming across that IP module; are you sure that it only supports a single serial protocol, instead of just a small variety (multi)? Unless the hardware only supports one protocol, my point holds. I wasn't implying that modules named SSP have more in common than tending to support more than a single serial protocol. If they only support one, they get names likeUSART or sometimes CODEC. - Dave ___ 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 v4 08/12] gpio: add ti-ssp gpio driver
2010/11/3 David Brownell davi...@pacbell.net: That seems like a better structure for various vendors' SSP hardware (multifunction serial interface logic) Incidentally the ARM PrimeCell PL022 is called SSP, Synchronous Serial Port and is not multifunction at all. Just to add to the confusion... Yours, Linus Walleij ___ 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 v4 08/12] gpio: add ti-ssp gpio driver
2010/11/3 David Brownell davi...@pacbell.net:
--- On Wed, 11/3/10, Linus Walleij linus.ml.wall...@gmail.com wrote:
Incidentally the ARM PrimeCell PL022 is called SSP,
Synchronous Serial Port and is not multifunction at all.
ISTR coming across that IP module; are you sure
that it only supports a single serial protocol,
instead of just a small variety (multi)?
Unless the hardware only supports one protocol,
my point holds.
Yeah well:
/**
* enum ssp_interface - interfaces allowed for this SSP Controller
* @SSP_INTERFACE_MOTOROLA_SPI: Motorola Interface
* @SSP_INTERFACE_TI_SYNC_SERIAL: Texas Instrument Synchronous Serial
* interface
* @SSP_INTERFACE_NATIONAL_MICROWIRE: National Semiconductor Microwire
* interface
* @SSP_INTERFACE_UNIDIRECTIONAL: Unidirectional interface (STn8810
* STn8815 only)
*/
enum ssp_interface {
SSP_INTERFACE_MOTOROLA_SPI,
SSP_INTERFACE_TI_SYNC_SERIAL,
SSP_INTERFACE_NATIONAL_MICROWIRE,
SSP_INTERFACE_UNIDIRECTIONAL
};
If that is what you mean then yes. All of the protols are
SPI type though.
Yours,
Linus Walleij
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v4 08/12] gpio: add ti-ssp gpio driver
TI's SSP controller pins can be directly read and written to behave like a
GPIO. This patch adds a GPIO driver that exposes such functionality.
Acked-by: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Cyril Chemparathy cy...@ti.com
---
arch/arm/mach-davinci/include/mach/ti_ssp.h |4 +
drivers/gpio/Kconfig| 10 ++
drivers/gpio/Makefile |1 +
drivers/gpio/ti-ssp-gpio.c | 200 +++
4 files changed, 215 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/ti-ssp-gpio.c
diff --git a/arch/arm/mach-davinci/include/mach/ti_ssp.h
b/arch/arm/mach-davinci/include/mach/ti_ssp.h
index bff8ef6..8fed5ab 100644
--- a/arch/arm/mach-davinci/include/mach/ti_ssp.h
+++ b/arch/arm/mach-davinci/include/mach/ti_ssp.h
@@ -39,6 +39,10 @@ struct ti_ssp_spi_data {
void(*select)(int cs);
};
+struct ti_ssp_gpio_data {
+ int start;
+};
+
/*
* Sequencer port IO pin configuration bits. These do not correlate 1-1 with
* the hardware. The iosel field in the port data combines iosel1 and iosel2,
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 510aa20..e400761 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -111,6 +111,16 @@ config GPIO_SCH
This driver can also be built as a module. If so, the module
will be called sch-gpio.
+config GPIO_TI_SSP
+ tristate TI SSP Controller GPIO Driver
+ depends on GPIOLIB TI_SSP
+ help
+ Say yes here to support a virtual GPIO interface on TI SSP ports.
+ Each SSP port translates into 4 GPIOs, with no IRQ support.
+
+ This driver can also be built as a module. If so, the module
+ will be called ti-ssp-gpio.
+
comment I2C GPIO expanders:
config GPIO_MAX7300
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index fc6019d..98b4551 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_GPIO_PL061) += pl061.o
obj-$(CONFIG_GPIO_STMPE) += stmpe-gpio.o
obj-$(CONFIG_GPIO_TC35892) += tc35892-gpio.o
obj-$(CONFIG_GPIO_TIMBERDALE) += timbgpio.o
+obj-$(CONFIG_GPIO_TI_SSP) += ti-ssp-gpio.o
obj-$(CONFIG_GPIO_TWL4030) += twl4030-gpio.o
obj-$(CONFIG_GPIO_UCB1400) += ucb1400_gpio.o
obj-$(CONFIG_GPIO_XILINX) += xilinx_gpio.o
diff --git a/drivers/gpio/ti-ssp-gpio.c b/drivers/gpio/ti-ssp-gpio.c
new file mode 100644
index 000..c046713
--- /dev/null
+++ b/drivers/gpio/ti-ssp-gpio.c
@@ -0,0 +1,200 @@
+/*
+ * Sequencer Serial Port (SSP) based virtual GPIO driver
+ *
+ * Copyright (C) 2010 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/init.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/io.h
+#include linux/err.h
+#include linux/slab.h
+#include linux/gpio.h
+#include linux/platform_device.h
+
+#include mach/ti_ssp.h
+
+struct ti_ssp_gpio {
+ struct gpio_chipchip;
+#define chip2gpio(chip)container_of(chip, struct ti_ssp_gpio, chip)
+ struct device *dev;
+ spinlock_t lock;
+ u8 out;
+ u32 iosel;
+};
+
+static int direction_in(struct gpio_chip *chip, unsigned gpio_num)
+{
+ struct ti_ssp_gpio *gpio = chip2gpio(chip);
+ int error = 0;
+
+ spin_lock(gpio-lock);
+
+ gpio-iosel = ~SSP_PIN_MASK(gpio_num);
+ gpio-iosel |= SSP_PIN_SEL(gpio_num, SSP_IN);
+
+ error = ti_ssp_set_iosel(gpio-dev, gpio-iosel);
+
+ spin_unlock(gpio-lock);
+
+ return error;
+}
+
+static int direction_out(struct gpio_chip *chip, unsigned gpio_num, int val)
+{
+ struct ti_ssp_gpio *gpio = chip2gpio(chip);
+ int error;
+
+ spin_lock(gpio-lock);
+
+ gpio-iosel = ~SSP_PIN_MASK(gpio_num);
+ gpio-iosel |= SSP_PIN_SEL(gpio_num, SSP_OUT);
+
+ error = ti_ssp_set_iosel(gpio-dev, gpio-iosel);
+
+ if (error 0)
+ goto error;
+
+ if (val)
+ gpio-out |= BIT(gpio_num);
+ else
+ gpio-out = ~BIT(gpio_num);
+
+ error = ti_ssp_raw_write(gpio-dev, gpio-out);
+
+error:
+ spin_unlock(gpio-lock);
Re: [PATCH v4 08/12] gpio: add ti-ssp gpio driver
--- On Tue, 10/26/10, Cyril Chemparathy cy...@ti.com wrote: From: Cyril Chemparathy cy...@ti.com Subject: [PATCH v4 08/12] gpio: add ti-ssp gpio driver On the assumptions you've tested this *AND* will resubmit with the previously-requested change of removing all references to non-existent virtualness in the driver ... I'll likely add my ack to that resubmitted version Also, chip2gpio seems an excessively generic name; maybe chip2_ti_ssp_gpio or somesuch? I'd still be happier seeing this stack packaged as a hardware library called by various drivers (like GPIO, SPI, etc) rather than a core driver that's called by other drivers. That seems like a better structure for various vendors' SSP hardware (multifunction serial interface logic) since most function drivers just need to poke the registers a bit differently, and don't have much to share with a core driver beyond a few setup routines (if that). - Dave ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
