msm: add single-wire serial bus interface (SSBI) driver

SSBI is the Qualcomm single-wire serial bus interface used to connect the MSM devices to the PMIC and other devices.

Since SSBI only supports a single slave, the driver gets the name of the slave device passed in from the board file through the master device's platform data.

SSBI registers pretty early (postcore), so that the PMIC can come up before the board init. This is useful if the board init requires the use of gpios that are connected through the PMIC.

Based on a patch by Dima Zavin <[email protected]> that can be found at:
http://android.git.kernel.org/?p=kernel/msm.git;a=commitdiff;h=eb060bac4

This patch adds PMIC Arbiter support for the MSM8660. The PMIC Arbiter is a hardware wrapper around the SSBI 2.0 controller that is designed to overcome concurrency issues and security limitations. A controller_type field is added to the platform data to specify the type of the SSBI controller (1.0, 2.0, or PMIC Arbiter).

---
 arch/arm/mach-msm/Kconfig                 |   16 ++
 arch/arm/mach-msm/Makefile                |    1 +
 arch/arm/mach-msm/include/mach/msm_ssbi.h |   38 +++
 arch/arm/mach-msm/ssbi.c                  |  376 +++++++++++++++++++++++++++++
 4 files changed, 431 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-msm/include/mach/msm_ssbi.h
 create mode 100644 arch/arm/mach-msm/ssbi.c

index 997c5bd..f35c3d9 100644
@@ -24,6 +24,7 @@ config ARCH_MSM7X30
 	select MSM_GPIOMUX
 	select MSM_PROC_COMM
 	select HAS_MSM_DEBUG_UART_PHYS
+	select HAS_MSM_SSBI
 
 config ARCH_QSD8X50
 	bool "QSD8X50"

@@ -46,6 +47,7 @@ config ARCH_MSM8X60
 	select MSM_V2_TLMM
 	select MSM_GPIOMUX
 	select MSM_SCM if SMP
+	select HAS_MSM_SSBI
 
 config ARCH_MSM8960
 	bool "MSM8960"

@@ -56,6 +58,7 @@ config ARCH_MSM8960
 	select MSM_V2_TLMM
 	select MSM_GPIOMUX
 	select MSM_SCM if SMP
+	select HAS_MSM_SSBI
 
 endchoice
 

@@ -190,6 +193,16 @@ choice
 endchoice
 endif
 
+config MSM_SSBI
+	bool "Qualcomm Single-wire Serial Bus Interface (SSBI)"
+	depends on HAS_MSM_SSBI
+	help
+	  If you say yes to this option, support will be included for the
+	  built-in SSBI interface on Qualcomm MSM family processors.
+
+	  This is required for communicating with Qualcomm PMICs and
+	  other devices that have the SSBI interface.
+
 config MSM_SMD_PKG3
 	bool
 

@@ -210,4 +223,7 @@ config IOMMU_API
 
 config MSM_SCM
 	bool
+
+config HAS_MSM_SSBI
+	bool
 endif

index 2099c97..94d46ff 100644
@@ -21,6 +21,7 @@ obj-$(CONFIG_MSM_SCM) += scm.o scm-boot.o
 
 obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
 obj-$(CONFIG_SMP) += headsmp.o platsmp.o
+obj-$(CONFIG_MSM_SSBI) += ssbi.o
 
 obj-$(CONFIG_MACH_TROUT) += board-trout.o board-trout-gpio.o board-trout-mmc.o devices-msm7x00.o
 obj-$(CONFIG_MACH_TROUT) += board-trout.o board-trout-gpio.o board-trout-mmc.o board-trout-panel.o devices-msm7x00.o

new file mode 100644
index 0000000..d0ed277
@@ -0,0 +1,38 @@
+/* Copyright (C) 2010 Google, Inc.
+ * Copyright (c) 2011, Code Aurora Forum. All rights reserved.
+ * Author: Dima Zavin <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ */
+
+#ifndef __ARCH_ARM_MACH_MSM_SSBI_H
+#define __ARCH_ARM_MACH_MSM_SSBI_H
+
+#include <linux/types.h>
+
+struct msm_ssbi_slave_info {
+	const char	*name;
+	void		*platform_data;
+};
+
+enum msm_ssbi_controller_type {
+	MSM_SBI_CTRL_SSBI = 0,
+	MSM_SBI_CTRL_SSBI2,
+	MSM_SBI_CTRL_PMIC_ARBITER,
+};
+
+struct msm_ssbi_platform_data {
+	struct msm_ssbi_slave_info	slave;
+	enum msm_ssbi_controller_type controller_type;
+};
+
+int msm_ssbi_write(struct device *dev, u16 addr, u8 *buf, int len);
+int msm_ssbi_read(struct device *dev, u16 addr, u8 *buf, int len);
+#endif

1.7.3.3

Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Where would you suggest? The initial attempt to model SSBI as an I2C bus didn't go anywhere. See http://lkml.org/lkml/2010/7/21/400. This functionality is specific to MSM. Plus, we're trying to maintain similarity to the Android MSM tree. That may not matter to people who don't use MSM, but is matters to us. Given these considerations, the current location seems as good a place as any.

- Bryan

Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

I don't know the driver well enough to be more detailed than suggesting drivers/ . In the thread you quoted Pavel (who I added to the CC line) suggested drivers/ssbi/ .

Daniel

Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

I'm not sure that knowing the driver would help. SSBI is a Qualcomm proprietary protocol that will only ever have one ssbi "host" driver in it. The slave is always the PMIC (maybe the audio codec too, but that's normally speaking i2c even in qualcomm's case). The slave PMIC drivers, however, will go under drivers/mfd for the core and the peripheral drivers into the appropriate drivers/xxx/ dirs, just like all the other pmic drivers. The audio codec would go into sound/soc/codecs. Thus, adding drivers/ssbi/ to just house ssbi.c doesn't really make sense to me.

What is the problem leaving it under arch/arm/mach-msm?

--Dima

Because it's a driver.

Daniel

There are a lot of other drivers currently under various arch subsystems. I'm not sure if a driver that is specific to only one arch has a strong reason to be elsewhere in the kernel. If there was a possibility of there being other devices that used SSBI, it might make sense to put it elsewhere. But, as far as I know, this device is only found on MSM chips.

It seems kind of unusual to create an entirely new directory under drivers to hold what will only ever be a single driver.

David

Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

There are lots of arch specific drivers under drivers/ . In fact I'm sure there are more arch specific drivers under drivers/ than anyplace else. That's how we organize things in Linux.

Then put it under another directory.

Daniel

And they are wrong. Probably because of some historical reasons.

You'll find plenty of examples for that, far more than drivers in arch specific directories.

That doesn't matter.

The main reasoning is that Linux has no stable internal API by design. When large scale driver API changes happen, it is the responsibility of the person doing that change to also fix up all the in-tree users of that API. And it is far more trouble for that person who probably has no knowledge about msm to go and hunt for all scattered drivers throughout the tree than it is for you to remember that all your drivers are under linux/drivers/.

And if someone else comes up with a SSBI interface, then it will be much easier to notice the already existing driver if it is in the driver directory rather than somewhere else in some unrelated (from that person's pov) obscure directory.

This was discussed in the past already. I would have liked to provide a link to some archived discussions (they do exist) but I can't find them at the moment.

Well, a couple examples exist already: drivers/dca, drivers/nfc, drivers/sn, drivers/tc, drivers/vlynq, etc. And if you expect to have more oddball msm drivers then you can create a drivers/msm directory, similar to the existing drivers/macintosh, drivers/parisc, drivers/s390, drivers/sh, drivers/video/omap, drivers/video/omap2, etc.

Nicolas

Well, I'm fairly sure that nobody would be making an SSBI interface, but point taken.

drivers/msm seems like a reasonable place. We already have other drivers that are in appropriate places.

So what kinds of things constitute drivers versus arch-specific code? Currently, iommu drivers seem to be sprinkled throughout arch.

We also have a shared-memory driver-type thing that is only used by other drivers. Does that make sense to be in drivers/msm?

Ken, do you mind moving this driver into 'drivers/msm' as the first one there?

Thanks,
David

Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

It's not necessarily the SSBI interface per se that is interesting to other people, but rather the fact that the code driving it might be relying upon generic kernel infrastructure, such as driver or bus registration, interrupt requests, resource allocation, etc.

Yes, and so are clock source and clock event "drivers". Some things fall into a gray area and this is not always clear what the proper location is for them. But as a rule of thumb you should follow what most other people did, and if there is no example to follow then just go with drivers/msm/ by default which should be a pretty safe bet.

Nicolas