[PATCH v4 01/12] misc: add driver for sequencer serial port

2010-11-02 Thread Cyril Chemparathy
TI's sequencer serial port (TI-SSP) is a jack-of-all-trades type of serial port
device.  It has a built-in programmable execution engine that can be programmed
to operate as almost any serial bus (I2C, SPI, EasyScale, and others).

This patch adds a driver for this controller device.  The driver does not
expose a user-land interface.  Protocol drivers built on top of this layer are
expected to remain in-kernel.

Signed-off-by: Cyril Chemparathy cy...@ti.com
---
 arch/arm/mach-davinci/include/mach/ti_ssp.h |   89 +
 drivers/misc/Kconfig|   10 +
 drivers/misc/Makefile   |1 +
 drivers/misc/ti_ssp.c   |  492 +++
 4 files changed, 592 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-davinci/include/mach/ti_ssp.h
 create mode 100644 drivers/misc/ti_ssp.c

diff --git a/arch/arm/mach-davinci/include/mach/ti_ssp.h 
b/arch/arm/mach-davinci/include/mach/ti_ssp.h
new file mode 100644
index 000..c98d0f2
--- /dev/null
+++ b/arch/arm/mach-davinci/include/mach/ti_ssp.h
@@ -0,0 +1,89 @@
+/*
+ * Sequencer Serial Port (SSP) driver for Texas Instruments' SoCs
+ *
+ * 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
+ */
+
+#ifndef __TI_SSP_H__
+#define __TI_SSP_H__
+
+struct ti_ssp_dev_data {
+   const char  *dev_name;
+   unsigned long   iosel; /* see note below */
+   unsigned long   config;
+   const void  *pdata;
+   size_t  pdata_size;
+};
+
+struct ti_ssp_data {
+   unsigned long   out_clock;
+   struct ti_ssp_dev_data  dev_data[2];
+};
+
+/*
+ * 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,
+ * and is therefore not a direct map to register space.  It is best to use the
+ * macros below to construct iosel values.
+ *
+ * least significant 16 bits -- iosel1
+ * most significant 16 bits  -- iosel2
+ */
+
+#define SSP_IN 0x
+#define SSP_DATA   0x0001
+#define SSP_CLOCK  0x0002
+#define SSP_CHIPSEL0x0003
+#define SSP_OUT0x0004
+#define SSP_PIN_SEL(pin, v)((v)  ((pin) * 3))
+#define SSP_PIN_MASK(pin)  SSP_PIN_SEL(pin, 0x7)
+#define SSP_INPUT_SEL(pin) ((pin)  16)
+
+/* Sequencer port config bits */
+#define SSP_EARLY_DIN  BIT(8)
+#define SSP_DELAY_DOUT BIT(9)
+
+/* Sequence map definitions */
+#define SSP_CLK_HIGH   BIT(0)
+#define SSP_CLK_LOW0
+#define SSP_DATA_HIGH  BIT(1)
+#define SSP_DATA_LOW   0
+#define SSP_CS_HIGHBIT(2)
+#define SSP_CS_LOW 0
+#define SSP_OUT_MODE   BIT(3)
+#define SSP_IN_MODE0
+#define SSP_DATA_REG   BIT(4)
+#define SSP_ADDR_REG   0
+
+#define SSP_OPCODE_DIRECT  ((0x0)  5)
+#define SSP_OPCODE_TOGGLE  ((0x1)  5)
+#define SSP_OPCODE_SHIFT   ((0x2)  5)
+#define SSP_OPCODE_BRANCH0 ((0x4)  5)
+#define SSP_OPCODE_BRANCH1 ((0x5)  5)
+#define SSP_OPCODE_BRANCH  ((0x6)  5)
+#define SSP_OPCODE_STOP((0x7)  5)
+#define SSP_BRANCH(addr)   ((addr)  8)
+#define SSP_COUNT(cycles)  ((cycles)  8)
+
+int ti_ssp_raw_read(struct device *dev);
+int ti_ssp_raw_write(struct device *dev, u32 val);
+int ti_ssp_load(struct device *dev, int offs, u32* prog, int len);
+int ti_ssp_run(struct device *dev, u32 pc, u32 input, u32 *output);
+int ti_ssp_set_mode(struct device *dev, int mode);
+int ti_ssp_set_iosel(struct device *dev, u32 iosel);
+
+#endif /* __TI_SSP_H__ */
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index b743312..a8b7ce3 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -390,6 +390,16 @@ config BMP085
  To compile this driver as a module, choose M here: the
  module will be called bmp085.
 
+config TI_SSP
+   tristate Sequencer Serial Port support
+   depends on ARCH_DAVINCI_TNETV107X
+   ---help---
+ Say Y here if you want support for the Sequencer Serial Port
+ in a Texas Instruments TNETV107X SoC.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ti_ssp.
+
 source 

Re: [PATCH v4 01/12] misc: add driver for sequencer serial port

2010-11-02 Thread Cyril Chemparathy
On 10/28/2010 11:49 AM, Linus Walleij wrote:
 2010/10/26 Cyril Chemparathy cy...@ti.com:
 
 TI's sequencer serial port (TI-SSP) is a jack-of-all-trades type of serial 
 port
 device.  It has a built-in programmable execution engine that can be 
 programmed
 to operate as almost any serial bus (I2C, SPI, EasyScale, and others).

 This patch adds a driver for this controller device.  The driver does not
 expose a user-land interface.  Protocol drivers built on top of this layer 
 are
 expected to remain in-kernel.
 
 Why is this thing in drivers/misc?
 
 drivers/mfd is IMHO the apropriate place for a driver like this, and
 the subdrivers should be migrated to use mfd cells and platform
 drivers for the subdevices.
 
 All functions and abstractions you create here look suspiciously
 lot like other MFD devices.
 
 But please, beat me up if I'm wrong!

Alan had raised the same concern earlier, and my response was:

 Unlike MFDs, this device doesn't have cells with differing
 functionality.  Instead it has functionally identical ports that can
 operate in a variety of modes.  That said, does this still fit in with
 other MFD drivers?  If so, I don't see a problem with moving it there.

I don't see a problem with moving this into MFD, but this won't be able
to use any of the functionality provided by mfd-core.

Thanks
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 01/12] misc: add driver for sequencer serial port

2010-11-02 Thread Linus Walleij
2010/10/26 Cyril Chemparathy cy...@ti.com:

 TI's sequencer serial port (TI-SSP) is a jack-of-all-trades type of serial 
 port
 device.  It has a built-in programmable execution engine that can be 
 programmed
 to operate as almost any serial bus (I2C, SPI, EasyScale, and others).

 This patch adds a driver for this controller device.  The driver does not
 expose a user-land interface.  Protocol drivers built on top of this layer are
 expected to remain in-kernel.

Why is this thing in drivers/misc?

drivers/mfd is IMHO the apropriate place for a driver like this, and
the subdrivers should be migrated to use mfd cells and platform
drivers for the subdevices.

All functions and abstractions you create here look suspiciously
lot like other MFD devices.

But please, beat me up if I'm wrong!

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 01/12] misc: add driver for sequencer serial port

2010-11-02 Thread Linus Walleij
2010/10/28 Cyril Chemparathy cy...@ti.com:
 On 10/28/2010 11:49 AM, Linus Walleij wrote:
 Why is this thing in drivers/misc?
 drivers/mfd is IMHO the apropriate place for a driver like this, (...)

 Alan had raised the same concern earlier, and my response was:

[Cyril]
 Unlike MFDs, this device doesn't have cells with differing
 functionality.  Instead it has functionally identical ports that can
 operate in a variety of modes.  That said, does this still fit in with
 other MFD drivers?  If so, I don't see a problem with moving it there.

 I don't see a problem with moving this into MFD, but this won't be able
 to use any of the functionality provided by mfd-core.

I think they do have differing functionality, though not in their
essence (hardware), they do get a clearly defined role at
run-time.

Sam will tell, but since you have subdrivers in other
subsystems MFD fits best IMHO.

What about the platform data passed into the MFD driver defines
what type of functionality will be assigned to each physical
block, from that you create the array of MFD cells to be spawn
and spawn it off. Then you have platform_driver:s in each
subsystem attaching to said cells. Shouldn't be too hard.

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