from:"Sebastian Reichel"

On Wed, Oct 09, 2013 at 05:43:13AM +, Paul Walmsley wrote:
 On Sun, 6 Oct 2013, Sebastian Reichel wrote:
 
  This patch adds Synchronous Serial Interface (SSI) hwmod support for
  OMAP34xx SoCs.
  
  Signed-off-by: Sebastian Reichel s...@debian.org
 
 Thanks, queued this one for v3.13.  You can drop it from any future 
 reposts of this series.

Thanks.

-- Sebastian


signature.asc
Description: Digital signature

Re: [RFCv3 0/7] OMAP SSI driver

Hi,

On Tue, Oct 08, 2013 at 10:28:15AM -0700, Tony Lindgren wrote:
 * Sebastian Reichel s...@debian.org [131006 13:36]:
  Here is the third round of the OMAP SSI driver patches.
 
 Thanks for updating these, they look good to me now:
 
 Acked-by: Tony Lindgren t...@atomide.com

Ok. I guess it's time to check how this gets included in the kernel.

The first patch has already been queued and the last patch could
probably go through Benoît once the DT people have reviewed the
updated patches. The other ones would normally go through the
hsi tree, but that one was maintained by Carlos Chinea and is 
now more or less orphaned.

My suggestion is:

1. I create another patch, which adds entries for hsi subsystem and
   ssi driver to MAINTAINERS.

   It would be nice to have some co-maintainers for the subsystem.
   Linus Walleij maybe? I think you created the launchpad blueprint [1]?
   Especially because I have no documentation/specification for HSI, which
   brings me to my next slightly off topic request.

   I would like to have access to SSI documentation and HSI specification.
   Can the guys from Texas Instruments please give me some pointers how I
   can get access to the NDA'd documentation? I couldn't find any hints
   on ti.com.

2. I create a patch adding Carlos Chinea to CREDITS

3. I create a git repository and put all of the patches in there, so
   that they can be pulled into linux-next.

4. I add a gpg/pgp signed tag with the key used to signed this mail.

Any issues with this or any other suggestions how to proceed? And if following 
this
- should I request an account on kernel.org to host the repository there,
or should I just upload it at a random place?

[0] 
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Next/Trees
[1] https://blueprints.launchpad.net/linux-linaro/+spec/hsi-subsystem-maint

-- Sebastian


signature.asc
Description: Digital signature

Re: [RFCv3 0/7] OMAP SSI driver

On Thu, Oct 10, 2013 at 09:28:01PM +0300, Aaro Koskinen wrote:
 On Thu, Oct 10, 2013 at 07:21:30PM +0200, Sebastian Reichel wrote:
  Any issues with this or any other suggestions how to proceed?
 
 Maybe you could provide some brief instructions/description of how this
 was tested?

Sure. I used Carlos' original patch, which has been tested to be
working. Then I checked with some debug prints and the debugfs
support what the registers and resources should look like.
Next I updated the patch to use the new kernel frameworks and
made sure everything is behaves as before.

For actually using the modem of the Nokia N900 three more drivers
are needed in the mainline kernel in addtion to this one:

1. cmt

 This is a small driver handling the modem's reset line, which
 is connected via a gpio pin to the system.

2. ssi_protocol
 
 This is an hsi client driver, which actually talks with the modem
 and exports an phonet interface for userspace access. It makes
 use of the cmt driver.

 I plan on porting these to the new kernel frameworks next. If
 I'm not mistaken this should be enough to communicate with the
 modem.

3. cmt_speech

 This is an hsi client driver, which takes care of interchanging
 speech data with the modem. This one is needed for calling. I
 will have a look at it once the basic stuff is working.

P.S.: You can get a mainline kernel status matrix for the Nokia
  N900 on this page: http://elinux.org/N900

-- Sebastian


signature.asc
Description: Digital signature

Re: [RFCv3 0/7] OMAP SSI driver

On Thu, Oct 10, 2013 at 11:19:14PM +0300, Aaro Koskinen wrote:
 On Thu, Oct 10, 2013 at 10:02:36PM +0200, Sebastian Reichel wrote:
  P.S.: You can get a mainline kernel status matrix for the Nokia
N900 on this page: http://elinux.org/N900
 
 Thanks for summary,

You're welcome.

 and the above page looks very useful. I wonder would it make sense
 to add also N9/N950 there (some functionality is shared)?

mh maybe. I haven't looked @ N9/N950 so far, since I don't own them.
I would be interested in a N950, but I don't own one and it's almost
impossible to get one :(

Apart from that I'm not sure if it's a good idea to make the table
even more complex. Maybe just add a new page?

 Also TWL4030 DT status could be updated, e.g. watchdog support
 was done already last year with 8899b8d93ec64b7a8e54807a68a958e1206535e2.

Yes. I only recently added the DT column and have not yet checked
all the drivers. Probably it's also a good idea to split this
column into driver supports DT and DT file supports it.

-- Sebastian


signature.asc
Description: Digital signature

Re: [000/118] 3.2.45-rc1 review

2013-05-12 Thread Sebastian Reichel

Hi Ben,

On Fri, May 10, 2013 at 02:39:39PM +0100, Ben Hutchings wrote:
 This is the start of the stable review cycle for the 3.2.45 release.
 There are 118 patches in this series, which will be posted as responses
 to this one.  If anyone has any issues with these being applied, please
 let me know.
 
 Responses should be made by Mon May 13 12:00:00 UTC 2013.
 Anything received after that time might be too late.

Please consider adding the patch ARM: OMAP: RX-51: change probe
order of touchscreen and panel SPI devices [0] to this or the next
3.2-stable update. It has already been added to the 3.0 and 3.4
stable queue [1].

-- Sebastian

[0] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e65f131a14726e5f1b880a528271a52428e5b3a5
[1] 
http://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git/tree/queue-3.0/arm-omap-rx-51-change-probe-order-of-touchscreen-and-panel-spi-devices.patch


signature.asc
Description: Digital signature

Re: [PATCH v2 0/9] wilink: add device tree support

2013-09-21 Thread Sebastian Reichel

On Sat, Sep 21, 2013 at 02:27:18PM +0200, Pavel Machek wrote:
 Hi!
 
This is a follow-up on a previous patch set that had a smaller
audience.  This time, I added the lists and people who were involved
in the review of the bindings documentation, since most of my changes
in v2 are coming from discussions there.
   
This patch series adds device tree support to the wlcore_sdio driver,
which is used by WiLink6, WiLink7 and WiLink8.
   
   Could you perhaps consider doing device tree conversion for wl1251
   too? With the knowledge you have from working on this series, it would
   be much easier for you to do it than for someone else, and I don't
   have much hope someone will do it at all. It's WiLink series chip
   after all. Without this pandora and N900 are going to lose wifi
   support after the switch to dt-only kernel.
  
  Unfortunately I don't have much time to work on wl1251.  I think it
  wouldn't be too difficult to do though, so patches are welcome. ;)
  
  Maybe you could try to make this change and I could support you if
  needed?
  
  
   I can offer you my help testing things on pandora and I'm sure someone
   here could try it on N900.
  
  I could try it on the N900, if it is still bootable easily with the
  mainline. ;)
 
 3.11 should be bootable on mainline, including device tree and
 video. (But excluding some other stuff, like MMC.)

I got external MMC (= µSD) working with some small modifications of
the omap3-n900.dts file. I have not yet tried internal MMC, since
its not important for me at the moment, but I guess its also just a
small change in the dts file.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v2 0/9] wilink: add device tree support

2013-09-22 Thread Sebastian Reichel

On Sun, Sep 22, 2013 at 03:36:32PM +0200, Pavel Machek wrote:
Unfortunately I don't have much time to work on wl1251.  I think it
wouldn't be too difficult to do though, so patches are welcome. ;)

Maybe you could try to make this change and I could support you if
needed?


 I can offer you my help testing things on pandora and I'm sure someone
 here could try it on N900.

I could try it on the N900, if it is still bootable easily with the
mainline. ;)
   
   3.11 should be bootable on mainline, including device tree and
   video. (But excluding some other stuff, like MMC.)
  
  I got external MMC (= µSD) working with some small modifications of
  the omap3-n900.dts file. I have not yet tried internal MMC, since
  its not important for me at the moment, but I guess its also just a
  small change in the dts file.
 
 Can we get the diff? :-).

I will sent a patchset for the omap3-n900.dts file in the next days.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

2013-09-23 Thread Sebastian Reichel

On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Rohár wrote:
 It is not as simple as it looks. This is reason why I submited 
 this patch long time after I submited bq2415x driver.
 
 Problem is that for rx51 is needed specific function which connect 
 to two drivers (bq2415x and isp1704) plus it call specific rx51 
 board functions.
 
 Something which cannot be in DT (unless DT support C/ASM code).

mh could isp1704 driver expose the data via the regulator framework?
Then the bq2415x chip can just use the regulator framework. This
should make converting to DT easy (by giving the bq2415x chip the
isp1704 as regulator) and uses existing standard interfaces.

 Patches for modem support are being prepared for upstreaming :-) 
 so after that it is up to you to create call script as you want

I'm on it. RFC round will be sent out this week. It seems
hwmod data is already finished, since i didn't get feedback for
that patch :)

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

2013-09-23 Thread Sebastian Reichel

On Mon, Sep 23, 2013 at 10:06:46PM +0200, Pali Rohár wrote:
 On Monday 23 September 2013 22:00:09 Sebastian Reichel wrote:
  On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Rohár wrote:
   It is not as simple as it looks. This is reason why I
   submited this patch long time after I submited bq2415x
   driver.
   
   Problem is that for rx51 is needed specific function which
   connect to two drivers (bq2415x and isp1704) plus it call
   specific rx51 board functions.
   
   Something which cannot be in DT (unless DT support C/ASM
   code).
  
  mh could isp1704 driver expose the data via the regulator
  framework?
 
 No, isp1704 is power supply driver and export data via power 
 supply (sysfs) interface. It is not regulator but charger driver.

well it does not charge the battery directly, but just provides a
power line with 5 Volt and a specified amount of current to the
system, doesn't it?

From my POV this is a candiate for the regulator framework:

https://www.kernel.org/doc/Documentation/power/regulator/overview.txt

-- Sebastian


signature.asc
Description: Digital signature

Re: [RFCv2 3/3] ARM: dts: N900: Add SSI information

2013-09-23 Thread Sebastian Reichel

Hi,

On Mon, Sep 23, 2013 at 02:35:35PM -0600, Stephen Warren wrote:
 On 09/15/2013 02:44 PM, Sebastian Reichel wrote:
  Add SSI device tree data for OMAP34xx and Nokia N900.
 
 What is an SSI device, ...

Synchronous Serial Interface (SSI), which is an interface from
the OMAP3 for modem connection. It's a legacy variant of
High-speed Synchronous Serial Interface (HSI). This in turn
is a standard from MIPI:

http://www.mipi.org/specifications/high-speed-synchronous-serial-interface-hsi

 
  diff --git a/Documentation/devicetree/bindings/hsi/omap_ssi.txt 
  b/Documentation/devicetree/bindings/hsi/omap_ssi.txt
 
 ... and what is the HSI subsystem?

A framework for HSI devices living in drivers/hsi.

  +OMAP SSI controller bindings
  +
  +Required properties:
  +- compatible:  Should be set to the following value
  +ti,omap3-ssi (applicable to OMAP34xx devices)
 
 I think that'd be better phrased as:
 
   Should include ti,omap3-ssi.
 
 The binding should not preclude other compatibel values being present
 (e.g. a SoC-specific compatible value, to allow SoC-specific quirks to
 be enabled later).

Right. Will be fixed in the next RFC.

  +- ti,hwmods:   Name of the hwmod associated to the controller, 
  which
  +   is ssi.
 
 I don't think we should add any more of that, for new bindings.

That basically means not adding new drivers until hwmod is completly
removed, since no new drivers not using DT are accepted anymore.

hwmod still holds some information, which are not yet mapped to DT.

  +- reg: Contains SSI register address range (base 
  address and
  +   length).
  +- reg-names:   Contains the names of the address ranges. It's
  +expected, that sys and gdd address ranges are
  +   provided.
 
 Why two entries in reg-names but only one in reg?
 
 I think it'd be better to write:
 
 reg-names:Contains the values sys and gdd.
 reg:  Contains a register specifier for each entry in
   reg-names.
 
 A similar re-ordering/-wording would apply to interrupts/interrupt-names.

OK. Will be fixed in the next RFC.

  +- ranges   Required as an empty node
 
 s/node/property/
 
 Why must ranges be empty? As long as the content correctly represents
 the bus setup, why does the content matter at all. How about:
 
 rangesRepresents the bus address mapping between the main
   controller node and the child nodes below.

OK. Will be fixed in the next RFC.

  +Each port is represented as a sub-node of the ti,omap3-ssi device.
  +
  +Required Port sub-node properties:
  +- compatible:  Should be set to the following value
  +ti,omap3-ssi-port (applicable to OMAP34xx devices)
 
 Hmm. Is it really the case that there is 1 controller with n ports?

Yes with n=2.

 Are the ports really dependent upon some shared resource?

Yes and runtime power management.

 Couldn't the ports be represented as separate top-level SSI
 controllers?

Maybe with some phandles. The current layout is cleaner IMHO.
The ports are part of the controller and actually most boards
only use one of them.

In the original driver only the controller hat platform data
with memory areas called port1_rx etc.

  +- interrupts:  Contains the interrupt information for the port.
  +- interrupt-names: Contains the names of the interrupts. It's expected,
  +   that mpu_irq0 and mpu_irq1 are provided.
 
 What exactly are those interrupts? MPU sounds like an external
 micro-controller/processor...
 
  +- ti,ssi-cawake-gpio:  Defines which GPIO pin is used to signify CAWAKE
  +   events for the port. This is an optional board-specific
  +   property. If it's missing the port will not be
  +   enabled.
 
 That also sounds like something that's a higher-level protocol, rather
 than whatever low-level transport SSI implements. Should this be part
 of a child node that represents the device attached to the SSI controller?

Both the interrupts and the cawake-gpio are used as irqs for
starting data transfers. As far as I understand it none of
them are specific to the attached device.

NOTE: I do not have documentation for the chip. I just ported the
old patch from Carlos Chinea (who developed the initial driver for
Nokia) to the new kernel frameworks, since I want to use the
modem of my Nokia N900.

 Does the SSI controller (or its ports) not need any clocks, resets,
 regulators, ...?

The only other stuff needed is taken care of by hwmod, which can
be seen in this patch:

https://lkml.org/lkml/2013/9/15/97

As far as I understand it, this kind of information is not yet
supported by DT on OMAP boards. On the other hand new OMAP drivers
are not allowed to add further board code, so temporarily the
ti,hwmod hack must be used.

-- Sebastian

Re: [PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

2013-09-24 Thread Sebastian Reichel

Hi,

On Tue, Sep 24, 2013 at 07:05:47PM +0200, Pali Rohár wrote:
 No, isp1704 driver is doing fastcharger detection (and then 
 export charger type via sysfs power supply) based on musb usb 
 events.
 
 Real charging (enabling/disabling and setting properties) is done 
 by bq24150a chip which has own power driver bq2415x_charger.
 
 As already wrote this is not simple and this is reason why I sent 
 board data and functions only now...

Yes, I'm aware of this. Technically the isp1704 does not provide the
5 volt line, but for the system as a whole that fact does not really
matter.

The isp1704 can provide its functionality via the regulator API
as a simple regulator device. It provides information about the
power it can supply.

The bq24150a on the other hand can just use the regulator via the
consumer interface.

The regulator framework provides capabilities for events:
Regulators can notify consumers of external events

-- Sebastian


signature.asc
Description: Digital signature

Re: N900 device tree conversion: how to do first step

2013-07-19 Thread Sebastian Reichel

Hi,

On Sun, Jun 09, 2013 at 03:59:44AM +0200, Pavel Machek wrote:
 I'd like to convert Nokia N900 to device tree.
 
 Unfortunately, serial port is not easily available (very special cable
 would be needed, does someone know where to get one?)

One way to get one is building it yourself. I finished mine yesterday:

http://elektranox.org/n900/adapter/index.html

-- Sebastian


signature.asc
Description: Digital signature

[PATCHv5 02/10] HSI: Add channel resource support to HSI clients

Make HSI channel ids platform data, which can be provided
by platform data.

Signed-off-by: Sebastian Reichel s...@kernel.org
Tested-By: Ivaylo Dimitrov ivo.g.dimitrov...@gmail.com
---
 drivers/hsi/clients/hsi_char.c | 12 +--
 drivers/hsi/hsi.c  | 46 +-
 include/linux/hsi/hsi.h| 24 ++
 3 files changed, 71 insertions(+), 11 deletions(-)

diff --git a/drivers/hsi/clients/hsi_char.c b/drivers/hsi/clients/hsi_char.c
index 3073320..57f70c2 100644
--- a/drivers/hsi/clients/hsi_char.c
+++ b/drivers/hsi/clients/hsi_char.c
@@ -367,7 +367,7 @@ static int hsc_rx_set(struct hsi_client *cl, struct 
hsc_rx_config *rxc)
return -EINVAL;
tmp = cl-rx_cfg;
cl-rx_cfg.mode = rxc-mode;
-   cl-rx_cfg.channels = rxc-channels;
+   cl-rx_cfg.num_hw_channels = rxc-channels;
cl-rx_cfg.flow = rxc-flow;
ret = hsi_setup(cl);
if (ret  0) {
@@ -383,7 +383,7 @@ static int hsc_rx_set(struct hsi_client *cl, struct 
hsc_rx_config *rxc)
 static inline void hsc_rx_get(struct hsi_client *cl, struct hsc_rx_config *rxc)
 {
rxc-mode = cl-rx_cfg.mode;
-   rxc-channels = cl-rx_cfg.channels;
+   rxc-channels = cl-rx_cfg.num_hw_channels;
rxc-flow = cl-rx_cfg.flow;
 }
 
@@ -402,7 +402,7 @@ static int hsc_tx_set(struct hsi_client *cl, struct 
hsc_tx_config *txc)
return -EINVAL;
tmp = cl-tx_cfg;
cl-tx_cfg.mode = txc-mode;
-   cl-tx_cfg.channels = txc-channels;
+   cl-tx_cfg.num_hw_channels = txc-channels;
cl-tx_cfg.speed = txc-speed;
cl-tx_cfg.arb_mode = txc-arb_mode;
ret = hsi_setup(cl);
@@ -417,7 +417,7 @@ static int hsc_tx_set(struct hsi_client *cl, struct 
hsc_tx_config *txc)
 static inline void hsc_tx_get(struct hsi_client *cl, struct hsc_tx_config *txc)
 {
txc-mode = cl-tx_cfg.mode;
-   txc-channels = cl-tx_cfg.channels;
+   txc-channels = cl-tx_cfg.num_hw_channels;
txc-speed = cl-tx_cfg.speed;
txc-arb_mode = cl-tx_cfg.arb_mode;
 }
@@ -435,7 +435,7 @@ static ssize_t hsc_read(struct file *file, char __user 
*buf, size_t len,
return -EINVAL;
if (len  max_data_size)
len = max_data_size;
-   if (channel-ch = channel-cl-rx_cfg.channels)
+   if (channel-ch = channel-cl-rx_cfg.num_hw_channels)
return -ECHRNG;
if (test_and_set_bit(HSC_CH_READ, channel-flags))
return -EBUSY;
@@ -492,7 +492,7 @@ static ssize_t hsc_write(struct file *file, const char 
__user *buf, size_t len,
return -EINVAL;
if (len  max_data_size)
len = max_data_size;
-   if (channel-ch = channel-cl-tx_cfg.channels)
+   if (channel-ch = channel-cl-tx_cfg.num_hw_channels)
return -ECHRNG;
if (test_and_set_bit(HSC_CH_WRITE, channel-flags))
return -EBUSY;
diff --git a/drivers/hsi/hsi.c b/drivers/hsi/hsi.c
index e96a987..de2ad8f 100644
--- a/drivers/hsi/hsi.c
+++ b/drivers/hsi/hsi.c
@@ -62,18 +62,36 @@ static struct bus_type hsi_bus_type = {
 
 static void hsi_client_release(struct device *dev)
 {
-   kfree(to_hsi_client(dev));
+   struct hsi_client *cl = to_hsi_client(dev);
+
+   kfree(cl-tx_cfg.channels);
+   kfree(cl-rx_cfg.channels);
+   kfree(cl);
 }
 
 static void hsi_new_client(struct hsi_port *port, struct hsi_board_info *info)
 {
struct hsi_client *cl;
+   size_t size;
 
cl = kzalloc(sizeof(*cl), GFP_KERNEL);
if (!cl)
return;
+
cl-tx_cfg = info-tx_cfg;
+   if (cl-tx_cfg.channels) {
+   size = cl-tx_cfg.num_channels * sizeof(*cl-tx_cfg.channels);
+   cl-tx_cfg.channels = kzalloc(size , GFP_KERNEL);
+   memcpy(cl-tx_cfg.channels, info-tx_cfg.channels, size);
+   }
+
cl-rx_cfg = info-rx_cfg;
+   if (cl-rx_cfg.channels) {
+   size = cl-rx_cfg.num_channels * sizeof(*cl-rx_cfg.channels);
+   cl-rx_cfg.channels = kzalloc(size , GFP_KERNEL);
+   memcpy(cl-rx_cfg.channels, info-rx_cfg.channels, size);
+   }
+
cl-device.bus = hsi_bus_type;
cl-device.parent = port-device;
cl-device.release = hsi_client_release;
@@ -502,6 +520,32 @@ int hsi_event(struct hsi_port *port, unsigned long event)
 }
 EXPORT_SYMBOL_GPL(hsi_event);
 
+/**
+ * hsi_get_channel_id_by_name - acquire channel id by channel name
+ * @cl: HSI client, which uses the channel
+ * @name: name the channel is known under
+ *
+ * Clients can call this function to get the hsi channel ids similar to
+ * requesting IRQs or GPIOs by name. This function assumes the same
+ * channel configuration is used for RX and TX.
+ *
+ * Returns -errno on error or channel id on success.
+ */
+int hsi_get_channel_id_by_name(struct hsi_client *cl, char *name)
+{
+   int i;
+
+   if (!cl-rx_cfg.channels

[PATCHv5 00/10] OMAP SSI driver / N900 modem support

Hi,

This is the ninth round of the OMAP SSI driver patches. I plan
to move all the whole patchset (except DTS changes) to for-next
on 2014-05-15 23:42 if nobody objects until then. @Tony: Is this
sufficiently early to get the DTS changes into 3.16 via your
tree?

Changes since PATCHv4 [0]:
 * Removed first three patches (HSI Documentation, MAINTAINER file
   update and hsi-char fix) from the patchset. I added them to
   for-next already.
 * Added module parameter pm to the nokia-modem kernel module, which
   can be used to disable requesting the gpios (needed by fremantle).
   The same parameter will be used later to enable full-kernel
   based power management. This is not yet implemented in the driver
   and would break all existing userspace applications.
 * Added Tested-By from Ivaylo Dimitrov, who successfully tested it
   with Maemo fremantle (with some additional patches not directly
   touching the modem, but needed to boot Maemo).
 * Export ssi-protocol reset function, so that nokia-n900 can call
   it if ssi-protocol is built as module.
 * Updated KConfig, so that n900-modem / ssi-protocol and omap-ssi
   can be built independently.
 * Updated KConfig omap-ssi entry to depend on omap3 or compile-test.
 * Fix build for disabled CONFIG_OF

For testing you can either apply this patchset to current mainline
kernel or use the n900-modem-support-4 branch available on [1].
Feedback is highly appreciated :)

For testing the patchset you should build the kernel with all config
entries in the HSI subsystem activated and boot using the updated
device tree information (platform data based booting is not
supported!). Testing the patchset with ofono works like this:

 # provide cmt device for ofono
 ln -sf /sys/bus/hsi/n900-modem /dev/cmt
 # start ofono
 ofono --nodetach --debug
 # enable the modem
 mdbus2 -s org.ofono /n900_0 org.ofono.Modem.SetProperty Powered true
 # enable modem's RF parts
 mdbus2 -s org.ofono /n900_0 org.ofono.Modem.SetProperty Online true
 # scan for available networks (takes some time)
 mdbus2 -s org.ofono /n900_0 org.ofono.NetworkRegistration.Scan

TODO (post-merge):
* Central Message Queue in HSI framework
* Remove the hwmod DT hack
* Implement proper context loss detection
* Implement full N900 modem PM (in-kernel)
* Remove wakeline checks (thus removing the FIXMEs)

[0] https://lkml.org/lkml/2014/4/25/520
[1] git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi.git

-- Sebastian

Sebastian Reichel (10):
  HSI: method to unregister clients from an hsi port
  HSI: Add channel resource support to HSI clients
  HSI: export method to (un)register clients
  HSI: Add common DT binding for HSI client devices
  HSI: Introduce OMAP SSI driver
  Documentation: DT: omap-ssi binding documentation
  HSI: Introduce driver for SSI Protocol
  HSI: Introduce Nokia N900 modem driver
  DTS: ARM: OMAP3-N900: Add SSI support
  DTS: ARM: OMAP3-N900: Add modem support

 .../devicetree/bindings/hsi/client-devices.txt |   44 +
 .../devicetree/bindings/hsi/nokia-modem.txt|   57 +
 Documentation/devicetree/bindings/hsi/omap-ssi.txt |   97 ++
 arch/arm/boot/dts/omap3-n900.dts   |   65 +
 arch/arm/boot/dts/omap3.dtsi   |   45 +
 arch/arm/boot/dts/omap34xx.dtsi|   11 +
 arch/arm/boot/dts/omap36xx.dtsi|   11 +
 drivers/hsi/Kconfig|1 +
 drivers/hsi/Makefile   |1 +
 drivers/hsi/clients/Kconfig|   17 +
 drivers/hsi/clients/Makefile   |4 +-
 drivers/hsi/clients/hsi_char.c |   12 +-
 drivers/hsi/clients/nokia-modem.c  |  285 
 drivers/hsi/clients/ssi_protocol.c | 1191 +
 drivers/hsi/controllers/Kconfig|   19 +
 drivers/hsi/controllers/Makefile   |6 +
 drivers/hsi/controllers/omap_ssi.c |  625 +
 drivers/hsi/controllers/omap_ssi.h |  166 +++
 drivers/hsi/controllers/omap_ssi_port.c| 1399 
 drivers/hsi/controllers/omap_ssi_regs.h|  171 +++
 drivers/hsi/hsi.c  |  275 +++-
 include/linux/hsi/hsi.h|   39 +-
 include/linux/hsi/ssi_protocol.h   |   42 +
 23 files changed, 4566 insertions(+), 17 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/hsi/client-devices.txt
 create mode 100644 Documentation/devicetree/bindings/hsi/nokia-modem.txt
 create mode 100644 Documentation/devicetree/bindings/hsi/omap-ssi.txt
 create mode 100644 drivers/hsi/clients/nokia-modem.c
 create mode 100644 drivers/hsi/clients/ssi_protocol.c
 create mode 100644 drivers/hsi/controllers/Kconfig
 create mode 100644 drivers/hsi/controllers/Makefile
 create mode 100644 drivers/hsi/controllers/omap_ssi.c
 create mode 100644 drivers/hsi/controllers/omap_ssi.h
 create

[PATCHv5 04/10] HSI: Add common DT binding for HSI client devices

Implement and document generic DT bindings for HSI clients.

Signed-off-by: Sebastian Reichel s...@kernel.org
Reviewed-by: Pavel Machek pa...@ucw.cz
Tested-By: Ivaylo Dimitrov ivo.g.dimitrov...@gmail.com
---
 .../devicetree/bindings/hsi/client-devices.txt |  44 +
 drivers/hsi/hsi.c  | 208 -
 include/linux/hsi/hsi.h|  11 ++
 3 files changed, 261 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/hsi/client-devices.txt

diff --git a/Documentation/devicetree/bindings/hsi/client-devices.txt 
b/Documentation/devicetree/bindings/hsi/client-devices.txt
new file mode 100644
index 000..104c9a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/hsi/client-devices.txt
@@ -0,0 +1,44 @@
+Each HSI port is supposed to have one child node, which
+symbols the remote device connected to the HSI port. The
+following properties are standardized for HSI clients:
+
+Required HSI configuration properties:
+
+- hsi-channel-ids: A list of channel ids
+
+- hsi-rx-mode: Receiver Bit transmission mode (stream or frame)
+- hsi-tx-mode: Transmitter Bit transmission mode (stream or frame)
+- hsi-mode:May be used instead hsi-rx-mode and hsi-tx-mode if
+   the transmission mode is the same for receiver and
+   transmitter
+- hsi-speed-kbps:  Max bit transmission speed in kbit/s
+- hsi-flow:RX flow type (synchronized or pipeline)
+- hsi-arb-mode:Arbitration mode for TX frame (round-robin, 
priority)
+
+Optional HSI configuration properties:
+
+- hsi-channel-names:   A list with one name per channel specified in the
+   hsi-channel-ids property
+
+
+Device Tree node example for an HSI client:
+
+hsi-controller {
+   hsi-port {
+   modem: hsi-client {
+   compatible = nokia,n900-modem;
+
+   hsi-channel-ids = 0, 1, 2, 3;
+   hsi-channel-names = mcsaab-control,
+   speech-control,
+   speech-data,
+   mcsaab-data;
+   hsi-speed-kbps = 55000;
+   hsi-mode = frame;
+   hsi-flow = synchronized;
+   hsi-arb-mode = round-robin;
+
+   /* more client specific properties */
+   };
+   };
+};
diff --git a/drivers/hsi/hsi.c b/drivers/hsi/hsi.c
index 834a2d6..fe93712 100644
--- a/drivers/hsi/hsi.c
+++ b/drivers/hsi/hsi.c
@@ -26,6 +26,8 @@
 #include linux/slab.h
 #include linux/string.h
 #include linux/notifier.h
+#include linux/of.h
+#include linux/of_device.h
 #include hsi_core.h
 
 static ssize_t modalias_show(struct device *dev,
@@ -50,7 +52,13 @@ static int hsi_bus_uevent(struct device *dev, struct 
kobj_uevent_env *env)
 
 static int hsi_bus_match(struct device *dev, struct device_driver *driver)
 {
-   return strcmp(dev_name(dev), driver-name) == 0;
+   if (of_driver_match_device(dev, driver))
+   return true;
+
+   if (strcmp(dev_name(dev), driver-name) == 0)
+   return true;
+
+   return false;
 }
 
 static struct bus_type hsi_bus_type = {
@@ -123,6 +131,202 @@ static void hsi_scan_board_info(struct hsi_controller 
*hsi)
}
 }
 
+#ifdef CONFIG_OF
+static struct hsi_board_info hsi_char_dev_info = {
+   .name = hsi_char,
+};
+
+static int hsi_of_property_parse_mode(struct device_node *client, char *name,
+ unsigned int *result)
+{
+   const char *mode;
+   int err;
+
+   err = of_property_read_string(client, name, mode);
+   if (err  0)
+   return err;
+
+   if (strcmp(mode, stream) == 0)
+   *result = HSI_MODE_STREAM;
+   else if (strcmp(mode, frame) == 0)
+   *result = HSI_MODE_FRAME;
+   else
+   return -EINVAL;
+
+   return 0;
+}
+
+static int hsi_of_property_parse_flow(struct device_node *client, char *name,
+ unsigned int *result)
+{
+   const char *flow;
+   int err;
+
+   err = of_property_read_string(client, name, flow);
+   if (err  0)
+   return err;
+
+   if (strcmp(flow, synchronized) == 0)
+   *result = HSI_FLOW_SYNC;
+   else if (strcmp(flow, pipeline) == 0)
+   *result = HSI_FLOW_PIPE;
+   else
+   return -EINVAL;
+
+   return 0;
+}
+
+static int hsi_of_property_parse_arb_mode(struct device_node *client,
+ char *name, unsigned int *result)
+{
+   const char *arb_mode;
+   int err;
+
+   err = of_property_read_string(client, name, arb_mode);
+   if (err  0)
+   return err;
+
+   if (strcmp(arb_mode, round-robin) == 0

[PATCHv5 03/10] HSI: export method to (un)register clients

Expose method for registering and unregistering HSI clients, so that
client drivers can register other client drivers.

This is useful for HSI drivers, which want to use the functionality
of other HSI drivers. For example the N900 modem driver can load HSI
drivers for mcsaab protocol and speech protocol.

Signed-off-by: Sebastian Reichel s...@kernel.org
Reviewed-by: Pavel Machek pa...@ucw.cz
Tested-By: Ivaylo Dimitrov ivo.g.dimitrov...@gmail.com
---
 drivers/hsi/hsi.c   | 11 ---
 include/linux/hsi/hsi.h |  3 +++
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/hsi/hsi.c b/drivers/hsi/hsi.c
index de2ad8f..834a2d6 100644
--- a/drivers/hsi/hsi.c
+++ b/drivers/hsi/hsi.c
@@ -69,14 +69,15 @@ static void hsi_client_release(struct device *dev)
kfree(cl);
 }
 
-static void hsi_new_client(struct hsi_port *port, struct hsi_board_info *info)
+struct hsi_client *hsi_new_client(struct hsi_port *port,
+   struct hsi_board_info *info)
 {
struct hsi_client *cl;
size_t size;
 
cl = kzalloc(sizeof(*cl), GFP_KERNEL);
if (!cl)
-   return;
+   return NULL;
 
cl-tx_cfg = info-tx_cfg;
if (cl-tx_cfg.channels) {
@@ -103,7 +104,10 @@ static void hsi_new_client(struct hsi_port *port, struct 
hsi_board_info *info)
pr_err(hsi: failed to register client: %s\n, info-name);
put_device(cl-device);
}
+
+   return cl;
 }
+EXPORT_SYMBOL_GPL(hsi_new_client);
 
 static void hsi_scan_board_info(struct hsi_controller *hsi)
 {
@@ -119,12 +123,13 @@ static void hsi_scan_board_info(struct hsi_controller 
*hsi)
}
 }
 
-static int hsi_remove_client(struct device *dev, void *data __maybe_unused)
+int hsi_remove_client(struct device *dev, void *data __maybe_unused)
 {
device_unregister(dev);
 
return 0;
 }
+EXPORT_SYMBOL_GPL(hsi_remove_client);
 
 static int hsi_remove_port(struct device *dev, void *data __maybe_unused)
 {
diff --git a/include/linux/hsi/hsi.h b/include/linux/hsi/hsi.h
index e3cff94..e20a399 100644
--- a/include/linux/hsi/hsi.h
+++ b/include/linux/hsi/hsi.h
@@ -296,6 +296,9 @@ struct hsi_controller *hsi_alloc_controller(unsigned int 
n_ports, gfp_t flags);
 void hsi_put_controller(struct hsi_controller *hsi);
 int hsi_register_controller(struct hsi_controller *hsi);
 void hsi_unregister_controller(struct hsi_controller *hsi);
+struct hsi_client *hsi_new_client(struct hsi_port *port,
+   struct hsi_board_info *info);
+int hsi_remove_client(struct device *dev, void *data);
 void hsi_port_unregister_clients(struct hsi_port *port);
 
 static inline void hsi_controller_set_drvdata(struct hsi_controller *hsi,
-- 
2.0.0.rc0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv5 07/10] HSI: Introduce driver for SSI Protocol

This adds a driver for the SSI McSAAB protocol as used in
the Nokia N900.

Signed-off-by: Carlos Chinea carlos.chi...@nokia.com
Signed-off-by: Sebastian Reichel s...@kernel.org
Tested-By: Ivaylo Dimitrov ivo.g.dimitrov...@gmail.com
---
 drivers/hsi/clients/Kconfig|8 +
 drivers/hsi/clients/Makefile   |3 +-
 drivers/hsi/clients/ssi_protocol.c | 1191 
 include/linux/hsi/ssi_protocol.h   |   42 ++
 4 files changed, 1243 insertions(+), 1 deletion(-)
 create mode 100644 drivers/hsi/clients/ssi_protocol.c
 create mode 100644 include/linux/hsi/ssi_protocol.h

diff --git a/drivers/hsi/clients/Kconfig b/drivers/hsi/clients/Kconfig
index 3bacd27..efd6288 100644
--- a/drivers/hsi/clients/Kconfig
+++ b/drivers/hsi/clients/Kconfig
@@ -4,6 +4,14 @@
 
 comment HSI clients
 
+config SSI_PROTOCOL
+   tristate SSI protocol
+   depends on HSI  PHONET
+   help
+   If you say Y here, you will enable the SSI protocol aka McSAAB.
+
+   If unsure, say N.
+
 config HSI_CHAR
tristate HSI/SSI character driver
depends on HSI
diff --git a/drivers/hsi/clients/Makefile b/drivers/hsi/clients/Makefile
index 327c0e2..ccbf768 100644
--- a/drivers/hsi/clients/Makefile
+++ b/drivers/hsi/clients/Makefile
@@ -2,4 +2,5 @@
 # Makefile for HSI clients
 #
 
-obj-$(CONFIG_HSI_CHAR) += hsi_char.o
+obj-$(CONFIG_SSI_PROTOCOL) += ssi_protocol.o
+obj-$(CONFIG_HSI_CHAR) += hsi_char.o
diff --git a/drivers/hsi/clients/ssi_protocol.c 
b/drivers/hsi/clients/ssi_protocol.c
new file mode 100644
index 000..ce4be37
--- /dev/null
+++ b/drivers/hsi/clients/ssi_protocol.c
@@ -0,0 +1,1191 @@
+/*
+ * ssi_protocol.c
+ *
+ * Implementation of the SSI McSAAB improved protocol.
+ *
+ * Copyright (C) 2010 Nokia Corporation. All rights reserved.
+ * Copyright (C) 2013 Sebastian Reichel s...@kernel.org
+ *
+ * Contact: Carlos Chinea carlos.chi...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * 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.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include linux/atomic.h
+#include linux/clk.h
+#include linux/device.h
+#include linux/err.h
+#include linux/gpio.h
+#include linux/if_ether.h
+#include linux/if_arp.h
+#include linux/if_phonet.h
+#include linux/init.h
+#include linux/irq.h
+#include linux/list.h
+#include linux/module.h
+#include linux/netdevice.h
+#include linux/notifier.h
+#include linux/scatterlist.h
+#include linux/skbuff.h
+#include linux/slab.h
+#include linux/spinlock.h
+#include linux/timer.h
+#include linux/hsi/hsi.h
+#include linux/hsi/ssi_protocol.h
+
+void ssi_waketest(struct hsi_client *cl, unsigned int enable);
+
+#define SSIP_TXQUEUE_LEN   100
+#define SSIP_MAX_MTU   65535
+#define SSIP_DEFAULT_MTU   4000
+#define PN_MEDIA_SOS   21
+#define SSIP_MIN_PN_HDR6   /* FIXME: Revisit */
+#define SSIP_WDTOUT2000/* FIXME: has to be 500 msecs */
+#define SSIP_KATOUT15  /* 15 msecs */
+#define SSIP_MAX_CMDS  5 /* Number of pre-allocated commands buffers */
+#define SSIP_BYTES_TO_FRAMES(x) x) - 1)  2) + 1)
+#define SSIP_CMT_LOADER_SYNC   0x11223344
+/*
+ * SSI protocol command definitions
+ */
+#define SSIP_COMMAND(data) ((data)  28)
+#define SSIP_PAYLOAD(data) ((data)  0xfff)
+/* Commands */
+#define SSIP_SW_BREAK  0
+#define SSIP_BOOTINFO_REQ  1
+#define SSIP_BOOTINFO_RESP 2
+#define SSIP_WAKETEST_RESULT   3
+#define SSIP_START_TRANS   4
+#define SSIP_READY 5
+/* Payloads */
+#define SSIP_DATA_VERSION(data)((data)  0xff)
+#define SSIP_LOCAL_VERID   1
+#define SSIP_WAKETEST_OK   0
+#define SSIP_WAKETEST_FAILED   1
+#define SSIP_PDU_LENGTH(data)  (((data)  8)  0x)
+#define SSIP_MSG_ID(data)  ((data)  0xff)
+/* Generic Command */
+#define SSIP_CMD(cmd, payload) (((cmd)  28) | ((payload)  0xfff))
+/* Commands for the control channel */
+#define SSIP_BOOTINFO_REQ_CMD(ver) \
+   SSIP_CMD(SSIP_BOOTINFO_REQ, SSIP_DATA_VERSION(ver))
+#define SSIP_BOOTINFO_RESP_CMD(ver) \
+   SSIP_CMD(SSIP_BOOTINFO_RESP, SSIP_DATA_VERSION(ver))
+#define SSIP_START_TRANS_CMD(pdulen, id) \
+   SSIP_CMD(SSIP_START_TRANS, (((pdulen)  8) | SSIP_MSG_ID(id)))
+#define SSIP_READY_CMD SSIP_CMD(SSIP_READY, 0)
+#define SSIP_SWBREAK_CMD   SSIP_CMD(SSIP_SW_BREAK, 0)
+
+/* Main state machine states */
+enum

[PATCHv5 06/10] Documentation: DT: omap-ssi binding documentation

Create device tree binding documentation for
OMAP Synchronous Serial Interface (SSI) device.

Signed-off-by: Sebastian Reichel s...@kernel.org
Reviewed-by: Pavel Machek pa...@ucw.cz
---
 Documentation/devicetree/bindings/hsi/omap-ssi.txt | 97 ++
 1 file changed, 97 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hsi/omap-ssi.txt

diff --git a/Documentation/devicetree/bindings/hsi/omap-ssi.txt 
b/Documentation/devicetree/bindings/hsi/omap-ssi.txt
new file mode 100644
index 000..f26625e
--- /dev/null
+++ b/Documentation/devicetree/bindings/hsi/omap-ssi.txt
@@ -0,0 +1,97 @@
+OMAP SSI controller bindings
+
+OMAP Synchronous Serial Interface (SSI) controller implements a legacy
+variant of MIPI's High Speed Synchronous Serial Interface (HSI).
+
+Required properties:
+- compatible:  Should include ti,omap3-ssi.
+- reg-names:   Contains the values sys and gdd (in this order).
+- reg: Contains a matching register specifier for each entry
+   in reg-names.
+- interrupt-names: Contains the value gdd_mpu.
+- interrupts:  Contains matching interrupt information for each entry
+   in interrupt-names.
+- ranges:  Represents the bus address mapping between the main
+   controller node and the child nodes below.
+- clock-names: Must include the following entries:
+  ssi_ssr_fck: The OMAP clock of that name
+  ssi_sst_fck: The OMAP clock of that name
+  ssi_ick: The OMAP clock of that name
+- clocks:  Contains a matching clock specifier for each entry in
+   clock-names.
+- #address-cells:  Should be set to 1
+- #size-cells: Should be set to 1
+
+Each port is represented as a sub-node of the ti,omap3-ssi device.
+
+Required Port sub-node properties:
+- compatible:  Should be set to the following value
+   ti,omap3-ssi-port (applicable to OMAP34xx devices)
+- reg-names:   Contains the values tx and rx (in this order).
+- reg: Contains a matching register specifier for each entry
+   in reg-names.
+- interrupt-parent Should be a phandle for the interrupt controller
+- interrupts:  Should contain interrupt specifiers for mpu interrupts
+   0 and 1 (in this order).
+- ti,ssi-cawake-gpio:  Defines which GPIO pin is used to signify CAWAKE
+   events for the port. This is an optional board-specific
+   property. If it's missing the port will not be
+   enabled.
+
+Example for Nokia N900:
+
+ssi-controller@48058000 {
+   compatible = ti,omap3-ssi;
+
+   /* needed until hwmod is updated to use the compatible string */
+   ti,hwmods = ssi;
+
+   reg = 0x48058000 0x1000,
+ 0x48059000 0x1000;
+   reg-names = sys,
+   gdd;
+
+   interrupts = 55;
+   interrupt-names = gdd_mpu;
+
+   clocks = ssi_ssr_fck,
+ssi_sst_fck,
+ssi_ick;
+   clock-names = ssi_ssr_fck,
+ ssi_sst_fck,
+ ssi_ick;
+
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+
+   ssi-port@4805a000 {
+   compatible = ti,omap3-ssi-port;
+
+   reg = 0x4805a000 0x800,
+ 0x4805a800 0x800;
+   reg-names = tx,
+   rx;
+
+   interrupt-parent = intc;
+   interrupts = 67,
+68;
+
+   ti,ssi-cawake-gpio = gpio5 23 GPIO_ACTIVE_HIGH; /* 151 */
+   }
+
+   ssi-port@4805a000 {
+   compatible = ti,omap3-ssi-port;
+
+   reg = 0x4805b000 0x800,
+ 0x4805b800 0x800;
+   reg-names = tx,
+   rx;
+
+   interrupt-parent = intc;
+   interrupts = 69,
+70;
+
+   status = disabled; /* second port is not used on N900 */
+   }
+}
-- 
2.0.0.rc0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv5 09/10] DTS: ARM: OMAP3-N900: Add SSI support

Add SSI device tree data for OMAP3 and Nokia N900.

Signed-off-by: Sebastian Reichel s...@kernel.org
Reviewed-by: Pavel Machek pa...@ucw.cz
Tested-By: Ivaylo Dimitrov ivo.g.dimitrov...@gmail.com
---
 arch/arm/boot/dts/omap3-n900.dts | 24 +
 arch/arm/boot/dts/omap3.dtsi | 45 
 arch/arm/boot/dts/omap34xx.dtsi  | 11 ++
 arch/arm/boot/dts/omap36xx.dtsi  | 11 ++
 4 files changed, 91 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 1a57b61..ef8b241 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -173,6 +173,19 @@
0x0da (PIN_OUTPUT | MUX_MODE1)   /* dss_data23.sdi_clkn 
*/
;
};
+
+   ssi_pins: pinmux_ssi {
+   pinctrl-single,pins = 
+   0x150 (PIN_INPUT_PULLUP | MUX_MODE1)/* ssi1_rdy_tx 
*/
+   0x14e (PIN_OUTPUT | MUX_MODE1)  /* ssi1_flag_tx 
*/
+   0x152 (PIN_INPUT | WAKEUP_EN | MUX_MODE4) /* 
ssi1_wake_tx (cawake) */
+   0x14c (PIN_OUTPUT | MUX_MODE1)  /* ssi1_dat_tx 
*/
+   0x154 (PIN_INPUT | MUX_MODE1)   /* ssi1_dat_rx 
*/
+   0x156 (PIN_INPUT | MUX_MODE1)   /* ssi1_flag_rx 
*/
+   0x158 (PIN_OUTPUT | MUX_MODE1)  /* ssi1_rdy_rx 
*/
+   0x15a (PIN_OUTPUT | MUX_MODE1)  /* ssi1_wake */
+   ;
+   };
 };
 
 i2c1 {
@@ -662,3 +675,14 @@
};
};
 };
+
+ssi_port1 {
+   pinctrl-names = default;
+   pinctrl-0 = ssi_pins;
+
+   ti,ssi-cawake-gpio = gpio5 23 GPIO_ACTIVE_HIGH; /* 151 */
+};
+
+ssi_port2 {
+   status = disabled;
+};
\ No newline at end of file
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index acb9019..b8cd2d7 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -757,6 +757,51 @@
clock-names = fck;
};
};
+
+   ssi: ssi-controller@48058000 {
+   compatible = ti,omap3-ssi;
+   ti,hwmods = ssi;
+
+   status = disabled;
+
+   reg = 0x48058000 0x1000,
+ 0x48059000 0x1000;
+   reg-names = sys,
+   gdd;
+
+   interrupts = 71;
+   interrupt-names = gdd_mpu;
+
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+
+   ssi_port1: ssi-port@4805a000 {
+   compatible = ti,omap3-ssi-port;
+
+   reg = 0x4805a000 0x800,
+ 0x4805a800 0x800;
+   reg-names = tx,
+   rx;
+
+   interrupt-parent = intc;
+   interrupts = 67,
+68;
+   };
+
+   ssi_port2: ssi-port@4805b000 {
+   compatible = ti,omap3-ssi-port;
+
+   reg = 0x4805b000 0x800,
+ 0x4805b800 0x800;
+   reg-names = tx,
+   rx;
+
+   interrupt-parent = intc;
+   interrupts = 69,
+70;
+   };
+   };
};
 };
 
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 2e92360..3819c1e 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -40,6 +40,17 @@
};
 };
 
+ssi {
+   status = ok;
+
+   clocks = ssi_ssr_fck,
+ssi_sst_fck,
+ssi_ick;
+   clock-names = ssi_ssr_fck,
+ ssi_sst_fck,
+ ssi_ick;
+};
+
 /include/ omap34xx-omap36xx-clocks.dtsi
 /include/ omap36xx-omap3430es2plus-clocks.dtsi
 /include/ omap36xx-am35xx-omap3430es2plus-clocks.dtsi
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 22cf464..541704a 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -78,6 +78,17 @@
clock-names = fck, tv_dac_clk;
 };
 
+ssi {
+   status = ok;
+
+   clocks = ssi_ssr_fck,
+ssi_sst_fck,
+ssi_ick;
+   clock-names = ssi_ssr_fck,
+ ssi_sst_fck,
+ ssi_ick;
+};
+
 /include/ omap34xx-omap36xx-clocks.dtsi
 /include/ omap36xx-omap3430es2plus-clocks.dtsi
 /include/ omap36xx-am35xx-omap3430es2plus

[PATCHv5 08/10] HSI: Introduce Nokia N900 modem driver

The Nokia N900's modem is connected via Synchronous Serial Interface (SSI),
which is a legacy version of MIPI's High-speed Synchronous Serial Interface
(HSI).

The handles the GPIOs for enabling and resetting the modem and instanciates
ssi-protocol for data exchange. It does not yet support exchanging voice data
with the modem.

Signed-off-by: Sebastian Reichel s...@kernel.org
Reviewed-by: Pavel Machek pa...@ucw.cz
Tested-By: Ivaylo Dimitrov ivo.g.dimitrov...@gmail.com
---
 .../devicetree/bindings/hsi/nokia-modem.txt|  57 +
 drivers/hsi/clients/Kconfig|   9 +
 drivers/hsi/clients/Makefile   |   1 +
 drivers/hsi/clients/nokia-modem.c  | 285 +
 4 files changed, 352 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hsi/nokia-modem.txt
 create mode 100644 drivers/hsi/clients/nokia-modem.c

diff --git a/Documentation/devicetree/bindings/hsi/nokia-modem.txt 
b/Documentation/devicetree/bindings/hsi/nokia-modem.txt
new file mode 100644
index 000..8a97978
--- /dev/null
+++ b/Documentation/devicetree/bindings/hsi/nokia-modem.txt
@@ -0,0 +1,57 @@
+Nokia modem client bindings
+
+The Nokia modem HSI client follows the common HSI client binding
+and inherits all required properties. The following additional
+properties are needed by the Nokia modem HSI client:
+
+Required properties:
+- compatible:  Should be one of
+  nokia,n900-modem
+- hsi-channel-names:   Should contain the following strings
+  mcsaab-control
+  speech-control
+  speech-data
+  mcsaab-data
+- gpios:   Should provide a GPIO handler for each GPIO listed in
+gpio-names
+- gpio-names:  Should contain the following strings
+  cmt_apeslpx
+  cmt_rst_rq
+  cmt_en
+  cmt_rst
+  cmt_bsi
+- interrupts:  Should be IRQ handle for modem's reset indication
+
+Example:
+
+ssi_port {
+   modem: hsi-client {
+   compatible = nokia,n900-modem;
+
+   pinctrl-names = default;
+   pinctrl-0 = modem_pins;
+
+   hsi-channel-ids = 0, 1, 2, 3;
+   hsi-channel-names = mcsaab-control,
+   speech-control,
+   speech-data,
+   mcsaab-data;
+   hsi-speed-kbps = 55000;
+   hsi-mode = frame;
+   hsi-flow = synchronized;
+   hsi-arb-mode = round-robin;
+
+   interrupts-extended = gpio3 8 IRQ_TYPE_EDGE_FALLING; /* 72 */
+
+   gpios = gpio3  6 GPIO_ACTIVE_HIGH, /* 70 */
+   gpio3  9 GPIO_ACTIVE_HIGH, /* 73 */
+   gpio3 10 GPIO_ACTIVE_HIGH, /* 74 */
+   gpio3 11 GPIO_ACTIVE_HIGH, /* 75 */
+   gpio5 29 GPIO_ACTIVE_HIGH; /* 157 */
+   gpio-names = cmt_apeslpx,
+cmt_rst_rq,
+cmt_en,
+cmt_rst,
+cmt_bsi;
+   };
+};
diff --git a/drivers/hsi/clients/Kconfig b/drivers/hsi/clients/Kconfig
index efd6288..600582a 100644
--- a/drivers/hsi/clients/Kconfig
+++ b/drivers/hsi/clients/Kconfig
@@ -4,6 +4,15 @@
 
 comment HSI clients
 
+config NOKIA_MODEM
+   tristate Nokia Modem
+   depends on HSI  SSI_PROTOCOL
+   help
+   Say Y here if you want to add support for the modem on Nokia
+   N900 (Nokia RX-51) hardware.
+
+   If unsure, say N.
+
 config SSI_PROTOCOL
tristate SSI protocol
depends on HSI  PHONET
diff --git a/drivers/hsi/clients/Makefile b/drivers/hsi/clients/Makefile
index ccbf768..4d5bc0e 100644
--- a/drivers/hsi/clients/Makefile
+++ b/drivers/hsi/clients/Makefile
@@ -2,5 +2,6 @@
 # Makefile for HSI clients
 #
 
+obj-$(CONFIG_NOKIA_MODEM)  += nokia-modem.o
 obj-$(CONFIG_SSI_PROTOCOL) += ssi_protocol.o
 obj-$(CONFIG_HSI_CHAR) += hsi_char.o
diff --git a/drivers/hsi/clients/nokia-modem.c 
b/drivers/hsi/clients/nokia-modem.c
new file mode 100644
index 000..363b780
--- /dev/null
+++ b/drivers/hsi/clients/nokia-modem.c
@@ -0,0 +1,285 @@
+/*
+ * nokia-modem.c
+ *
+ * HSI client driver for Nokia N900 modem.
+ *
+ * Copyright (C) 2014 Sebastian Reichel s...@kernel.org
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * 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.
+ *
+ * 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., 51 Franklin St, Fifth Floor

[PATCHv5 10/10] DTS: ARM: OMAP3-N900: Add modem support

Add modem device tree data to Nokia N900's DTS file.

Signed-off-by: Sebastian Reichel s...@kernel.org
Reviewed-by: Pavel Machek pa...@ucw.cz
Tested-By: Ivaylo Dimitrov ivo.g.dimitrov...@gmail.com
---
 arch/arm/boot/dts/omap3-n900.dts | 43 +++-
 1 file changed, 42 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index ef8b241..3cd899d 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -186,6 +186,17 @@
0x15a (PIN_OUTPUT | MUX_MODE1)  /* ssi1_wake */
;
};
+
+   modem_pins: pinmux_modem {
+   pinctrl-single,pins = 
+   0x0ac (PIN_OUTPUT | MUX_MODE4)  /* gpio 70 = 
cmt_apeslpx */
+   0x0b0 (PIN_INPUT | WAKEUP_EN | MUX_MODE4) /* gpio 72 = 
ape_rst_rq */
+   0x0b2 (PIN_OUTPUT | MUX_MODE4)  /* gpio 73 = 
cmt_rst_rq */
+   0x0b4 (PIN_OUTPUT | MUX_MODE4)  /* gpio 74 = 
cmt_en */
+   0x0b6 (PIN_OUTPUT | MUX_MODE4)  /* gpio 75 = 
cmt_rst */
+   0x15e (PIN_OUTPUT | MUX_MODE4)  /* gpio 157 = 
cmt_bsi */
+   ;
+   };
 };
 
 i2c1 {
@@ -681,8 +692,38 @@
pinctrl-0 = ssi_pins;
 
ti,ssi-cawake-gpio = gpio5 23 GPIO_ACTIVE_HIGH; /* 151 */
+
+   modem: hsi-client {
+   compatible = nokia,n900-modem;
+
+   pinctrl-names = default;
+   pinctrl-0 = modem_pins;
+
+   hsi-channel-ids = 0, 1, 2, 3;
+   hsi-channel-names = mcsaab-control,
+   speech-control,
+   speech-data,
+   mcsaab-data;
+   hsi-speed-kbps = 55000;
+   hsi-mode = frame;
+   hsi-flow = synchronized;
+   hsi-arb-mode = round-robin;
+
+   interrupts-extended = gpio3 8 IRQ_TYPE_EDGE_FALLING; /* 72 */
+
+   gpios = gpio3  6 GPIO_ACTIVE_HIGH, /* 70 */
+   gpio3  9 GPIO_ACTIVE_HIGH, /* 73 */
+   gpio3 10 GPIO_ACTIVE_HIGH, /* 74 */
+   gpio3 11 GPIO_ACTIVE_HIGH, /* 75 */
+   gpio5 29 GPIO_ACTIVE_HIGH; /* 157 */
+   gpio-names = cmt_apeslpx,
+cmt_rst_rq,
+cmt_en,
+cmt_rst,
+cmt_bsi;
+   };
 };
 
 ssi_port2 {
status = disabled;
-};
\ No newline at end of file
+};
-- 
2.0.0.rc0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv5 01/10] HSI: method to unregister clients from an hsi port

This exports a method to unregister all clients from
an hsi port.

Signed-off-by: Sebastian Reichel s...@kernel.org
Reviewed-by: Pavel Machek pa...@ucw.cz
Tested-By: Ivaylo Dimitrov ivo.g.dimitrov...@gmail.com
---
 drivers/hsi/hsi.c   | 10 ++
 include/linux/hsi/hsi.h |  1 +
 2 files changed, 11 insertions(+)

diff --git a/drivers/hsi/hsi.c b/drivers/hsi/hsi.c
index 749f7b5..e96a987 100644
--- a/drivers/hsi/hsi.c
+++ b/drivers/hsi/hsi.c
@@ -130,6 +130,16 @@ static void hsi_port_release(struct device *dev)
 }
 
 /**
+ * hsi_unregister_port - Unregister an HSI port
+ * @port: The HSI port to unregister
+ */
+void hsi_port_unregister_clients(struct hsi_port *port)
+{
+   device_for_each_child(port-device, NULL, hsi_remove_client);
+}
+EXPORT_SYMBOL_GPL(hsi_port_unregister_clients);
+
+/**
  * hsi_unregister_controller - Unregister an HSI controller
  * @hsi: The HSI controller to register
  */
diff --git a/include/linux/hsi/hsi.h b/include/linux/hsi/hsi.h
index 39bfd5b..5a9f121 100644
--- a/include/linux/hsi/hsi.h
+++ b/include/linux/hsi/hsi.h
@@ -282,6 +282,7 @@ struct hsi_controller *hsi_alloc_controller(unsigned int 
n_ports, gfp_t flags);
 void hsi_put_controller(struct hsi_controller *hsi);
 int hsi_register_controller(struct hsi_controller *hsi);
 void hsi_unregister_controller(struct hsi_controller *hsi);
+void hsi_port_unregister_clients(struct hsi_port *port);
 
 static inline void hsi_controller_set_drvdata(struct hsi_controller *hsi,
void *data)
-- 
2.0.0.rc0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv4 0/4] tsc2005 DT binding

Hi,

This adds device tree support for the tsc2005 touchscreen
controller, which is currently only used by the Nokia N900
board.

The patch does not update the reset pin handling for platform
data based probe to avoid merge conflicts. The n900 platform
code will be removed in the near future (3.17?) and the driver
can be simplified once that has happened.

Changes since v3 [0]:
 * Move common touchscreen DT handling code into its own file
 * Add regulator support to tsc2005 driver
 * Added N900 DTS patch for completeness. It should go via
   Tony's Tree of course.

[0] https://lkml.org/lkml/2014/4/25/694

-- Sebastian

Sebastian Reichel (4):
  Input: add common DT binding for touchscreens
  Input: tsc2005: add DT support
  Documentation: dt: Document TSC2005 DT binding
  DTS: ARM: OMAP3-N900: Add tsc2005 support

 .../bindings/input/touchscreen/touchscreen.txt |  27 +
 .../bindings/input/touchscreen/tsc2005.txt |  42 +++
 arch/arm/boot/dts/omap3-n900.dts   |  17 ++-
 drivers/input/touchscreen/Kconfig  |   4 +
 drivers/input/touchscreen/Makefile |   1 +
 drivers/input/touchscreen/of_touchscreen.c |  44 
 drivers/input/touchscreen/tsc2005.c| 122 +
 include/linux/input/touchscreen.h  |  22 
 8 files changed, 258 insertions(+), 21 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
 create mode 100644 drivers/input/touchscreen/of_touchscreen.c
 create mode 100644 include/linux/input/touchscreen.h

-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv4 2/4] Input: tsc2005: add DT support

This adds DT support to the tsc2005 touchscreen
driver. It also adds regulator support to the
driver if booted via DT.

Reviewed-by: Pavel Machek pa...@ucw.cz
Acked-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Sebastian Reichel s...@kernel.org
---
 drivers/input/touchscreen/tsc2005.c | 122 ++--
 1 file changed, 102 insertions(+), 20 deletions(-)

diff --git a/drivers/input/touchscreen/tsc2005.c 
b/drivers/input/touchscreen/tsc2005.c
index 9daaddd..731f0fd 100644
--- a/drivers/input/touchscreen/tsc2005.c
+++ b/drivers/input/touchscreen/tsc2005.c
@@ -25,11 +25,15 @@
 #include linux/kernel.h
 #include linux/module.h
 #include linux/input.h
+#include linux/input/touchscreen.h
 #include linux/interrupt.h
 #include linux/delay.h
 #include linux/pm.h
+#include linux/of.h
+#include linux/of_gpio.h
 #include linux/spi/spi.h
 #include linux/spi/tsc2005.h
+#include linux/regulator/consumer.h
 
 /*
  * The touchscreen interface operates as follows:
@@ -100,6 +104,11 @@
 TSC2005_CFR2_AVG_7)
 
 #define MAX_12BIT  0xfff
+#define TSC2005_DEF_X_FUZZ 4
+#define TSC2005_DEF_Y_FUZZ 8
+#define TSC2005_DEF_P_FUZZ 2
+#define TSC2005_DEF_RESISTOR   280
+
 #define TSC2005_SPI_MAX_SPEED_HZ   1000
 #define TSC2005_PENUP_TIME_MS  40
 
@@ -143,6 +152,9 @@ struct tsc2005 {
 
boolpen_down;
 
+   struct regulator*vio;
+
+   int reset_gpio;
void(*set_reset)(bool enable);
 };
 
@@ -337,6 +349,14 @@ static void tsc2005_stop_scan(struct tsc2005 *ts)
tsc2005_cmd(ts, TSC2005_CMD_STOP);
 }
 
+static void tsc2005_set_reset(struct tsc2005 *ts, bool enable)
+{
+   if (ts-reset_gpio = 0)
+   gpio_set_value(ts-reset_gpio, enable);
+   else if (ts-set_reset)
+   ts-set_reset(enable);
+}
+
 /* must be called with ts-mutex held */
 static void __tsc2005_disable(struct tsc2005 *ts)
 {
@@ -355,7 +375,7 @@ static void __tsc2005_enable(struct tsc2005 *ts)
 {
tsc2005_start_scan(ts);
 
-   if (ts-esd_timeout  ts-set_reset) {
+   if (ts-esd_timeout  (ts-set_reset || ts-reset_gpio)) {
ts-last_valid_interrupt = jiffies;
schedule_delayed_work(ts-esd_work,
round_jiffies_relative(
@@ -414,9 +434,9 @@ static ssize_t tsc2005_selftest_show(struct device *dev,
}
 
/* hardware reset */
-   ts-set_reset(false);
+   tsc2005_set_reset(ts, false);
usleep_range(100, 500); /* only 10us required */
-   ts-set_reset(true);
+   tsc2005_set_reset(ts, true);
 
if (!success)
goto out;
@@ -459,7 +479,7 @@ static umode_t tsc2005_attr_is_visible(struct kobject *kobj,
umode_t mode = attr-mode;
 
if (attr == dev_attr_selftest.attr) {
-   if (!ts-set_reset)
+   if (!ts-set_reset  !ts-reset_gpio)
mode = 0;
}
 
@@ -509,9 +529,9 @@ static void tsc2005_esd_work(struct work_struct *work)
 
tsc2005_update_pen_state(ts, 0, 0, 0);
 
-   ts-set_reset(false);
+   tsc2005_set_reset(ts, false);
usleep_range(100, 500); /* only 10us required */
-   ts-set_reset(true);
+   tsc2005_set_reset(ts, true);
 
enable_irq(ts-spi-irq);
tsc2005_start_scan(ts);
@@ -572,29 +592,47 @@ static void tsc2005_setup_spi_xfer(struct tsc2005 *ts)
 static int tsc2005_probe(struct spi_device *spi)
 {
const struct tsc2005_platform_data *pdata = dev_get_platdata(spi-dev);
+   struct device_node *np = spi-dev.of_node;
+
struct tsc2005 *ts;
struct input_dev *input_dev;
-   unsigned int max_x, max_y, max_p;
-   unsigned int fudge_x, fudge_y, fudge_p;
+   unsigned int max_x = MAX_12BIT;
+   unsigned int max_y = MAX_12BIT;
+   unsigned int max_p = MAX_12BIT;
+   unsigned int fudge_x = TSC2005_DEF_X_FUZZ;
+   unsigned int fudge_y = TSC2005_DEF_Y_FUZZ;
+   unsigned int fudge_p = TSC2005_DEF_P_FUZZ;
+   unsigned int x_plate_ohm = TSC2005_DEF_RESISTOR;
+   unsigned int esd_timeout;
int error;
 
-   if (!pdata) {
+   if (!np  !pdata) {
dev_err(spi-dev, no platform data\n);
return -ENODEV;
}
 
-   fudge_x = pdata-ts_x_fudge? : 4;
-   fudge_y = pdata-ts_y_fudge? : 8;
-   fudge_p = pdata-ts_pressure_fudge ? : 2;
-   max_x   = pdata-ts_x_max  ? : MAX_12BIT;
-   max_y   = pdata-ts_y_max  ? : MAX_12BIT;
-   max_p   = pdata-ts_pressure_max   ? : MAX_12BIT;
-
if (spi-irq = 0) {
dev_err(spi-dev, no irq\n);
return -ENODEV;
}
 
+   if (pdata) {
+   fudge_x = pdata-ts_x_fudge;
+   fudge_y = pdata-ts_y_fudge;
+   fudge_p = pdata

[PATCHv4 3/4] Documentation: dt: Document TSC2005 DT binding

Add devicetree binding documentation for TSC2005 touchscreen.

Reviewed-by: Pavel Machek pa...@ucw.cz
Acked-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Sebastian Reichel s...@kernel.org
---
 .../bindings/input/touchscreen/tsc2005.txt | 42 ++
 1 file changed, 42 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt

diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt 
b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
new file mode 100644
index 000..4b641c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
@@ -0,0 +1,42 @@
+* Texas Instruments tsc2005 touchscreen controller
+
+Required properties:
+ - compatible: ti,tsc2005
+ - reg   : SPI device address
+ - spi-max-frequency : Maximal SPI speed
+ - interrupts: IRQ specifier
+ - reset-gpios   : GPIO specifier
+ - vio-supply : Regulator specifier
+
+Optional properties:
+ - ti,x-plate-ohms   : integer, resistance of the touchscreen's X 
plates
+   in ohm (defaults to 280)
+ - ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond 
after
+   the configured time (in milli seconds), the 
driver
+   will reset it. This is disabled by default.
+ - properties defined in touchscreen.txt
+
+Example:
+
+mcspi1 {
+   tsc2005@0 {
+   compatible = ti,tsc2005;
+   spi-max-frequency = 600;
+   reg = 0;
+
+   vio-supply = vio;
+
+   reset-gpios = gpio4 8 GPIO_ACTIVE_HIGH; /* 104 */
+   interrupts-extended = gpio4 4 IRQ_TYPE_EDGE_RISING; /* 100 */
+
+   touchscreen-fuzz-x = 4;
+   touchscreen-fuzz-y = 7;
+   touchscreen-fuzz-pressure = 2;
+   touchscreen-max-x = 4096;
+   touchscreen-max-y = 4096;
+   touchscreen-max-pressure = 2048;
+
+   ti,x-plate-ohms = 280;
+   ti,esd-recovery-timeout-ms = 8000;
+   };
+}
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv4 4/4] DTS: ARM: OMAP3-N900: Add tsc2005 support

This adds support for the tsc2005 touchscreen
to the Nokia N900 DTS file.

Signed-off-by: Sebastian Reichel s...@kernel.org
---
 arch/arm/boot/dts/omap3-n900.dts | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 1a57b61..cb8ed2d5 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -580,9 +580,24 @@
 * Also... order in the device tree actually matters here.
 */
tsc2005@0 {
-   compatible = tsc2005;
+   compatible = ti,tsc2005;
spi-max-frequency = 600;
reg = 0;
+
+   vio-supply = vio;
+
+   reset-gpios = gpio4 8 GPIO_ACTIVE_HIGH; /* 104 */
+   interrupts-extended = gpio4 4 IRQ_TYPE_EDGE_RISING; /* 100 */
+
+   touchscreen-fuzz-x = 4;
+   touchscreen-fuzz-y = 7;
+   touchscreen-fuzz-pressure = 2;
+   touchscreen-max-x = 4096;
+   touchscreen-max-y = 4096;
+   touchscreen-max-pressure = 2048;
+
+   ti,x-plate-ohms = 280;
+   ti,esd-recovery-timeout-ms = 8000;
};
 
acx565akm@2 {
-- 
2.0.0.rc2

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv4 1/4] Input: add common DT binding for touchscreens

Add common DT binding documentation for touchscreen devices and
implement input_parse_touchscreen_of_params, which parses the common
properties and configures the input device accordingly.

The method currently does not interpret the axis inversion properties,
since there is no matching flag in the generic linux input device.

Reviewed-by: Pavel Machek pa...@ucw.cz
Acked-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Sebastian Reichel s...@kernel.org
---
 .../bindings/input/touchscreen/touchscreen.txt | 27 +
 drivers/input/touchscreen/Kconfig  |  4 ++
 drivers/input/touchscreen/Makefile |  1 +
 drivers/input/touchscreen/of_touchscreen.c | 44 ++
 include/linux/input/touchscreen.h  | 22 +++
 5 files changed, 98 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
 create mode 100644 drivers/input/touchscreen/of_touchscreen.c
 create mode 100644 include/linux/input/touchscreen.h

diff --git 
a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt 
b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
new file mode 100644
index 000..d8e0616
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
@@ -0,0 +1,27 @@
+General Touchscreen Properties:
+
+Optional properties for Touchscreens:
+ - touchscreen-size-x  : horizontal resolution of touchscreen
+ (in pixels)
+ - touchscreen-size-y  : vertical resolution of touchscreen
+ (in pixels)
+ - touchscreen-max-pressure: maximum reported pressure (arbitrary range
+ dependent on the controller)
+ - touchscreen-fuzz-x  : horizontal noise value of the absolute input
+ device (in pixels)
+ - touchscreen-fuzz-y  : vertical noise value of the absolute input
+ device (in pixels)
+ - touchscreen-fuzz-pressure   : pressure noise value of the absolute input
+ device (arbitrary range dependent on the
+ controller)
+ - touchscreen-inverted-x  : X axis is inverted (boolean)
+ - touchscreen-inverted-y  : Y axis is inverted (boolean)
+
+Deprecated properties for Touchscreens:
+ - x-size  : deprecated name for touchscreen-size-x
+ - y-size  : deprecated name for touchscreen-size-y
+ - moving-threshold: deprecated name for a combination of
+ touchscreen-fuzz-x and touchscreen-fuzz-y
+ - contact-threshold   : deprecated name for touchscreen-fuzz-pressure
+ - x-invert: deprecated name for touchscreen-inverted-x
+ - y-invert: deprecated name for touchscreen-inverted-y
diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index 68edc9d..b2a31ca 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -11,6 +11,10 @@ menuconfig INPUT_TOUCHSCREEN
 
 if INPUT_TOUCHSCREEN
 
+config OF_TOUCHSCREEN
+   def_tristate INPUT
+   depends on INPUT  OF
+
 config TOUCHSCREEN_88PM860X
tristate Marvell 88PM860x touchscreen
depends on MFD_88PM860X
diff --git a/drivers/input/touchscreen/Makefile 
b/drivers/input/touchscreen/Makefile
index 4bc954b..efa08ae 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -6,6 +6,7 @@
 
 wm97xx-ts-y := wm97xx-core.o
 
+obj-$(CONFIG_OF_TOUCHSCREEN)   += of_touchscreen.o
 obj-$(CONFIG_TOUCHSCREEN_88PM860X) += 88pm860x-ts.o
 obj-$(CONFIG_TOUCHSCREEN_AD7877)   += ad7877.o
 obj-$(CONFIG_TOUCHSCREEN_AD7879)   += ad7879.o
diff --git a/drivers/input/touchscreen/of_touchscreen.c 
b/drivers/input/touchscreen/of_touchscreen.c
new file mode 100644
index 000..0431b28
--- /dev/null
+++ b/drivers/input/touchscreen/of_touchscreen.c
@@ -0,0 +1,44 @@
+/*
+ *  Generic DT helper functions for touchscreen devices
+ *
+ *  Copyright (c) 2014 Sebastian Reichel s...@kernel.org
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ */
+
+#include linux/of.h
+#include linux/input.h
+
+/**
+ * touchscreen_parse_of_params - parse common touchscreen DT properties
+ * @dev: device that should be parsed
+ *
+ * This function parses common DT properties for touchscreens and setups the
+ * input device accordingly. The function keeps previously setuped default
+ * values if no value is specified via DT.
+ */
+void touchscreen_parse_of_params(struct input_dev *dev)
+{
+   struct device_node *np = dev-dev.parent-of_node;
+   struct input_absinfo *absinfo;
+
+   input_alloc_absinfo(dev

Re: [PATCHv5 09/10] DTS: ARM: OMAP3-N900: Add SSI support

Hi,

On Mon, May 19, 2014 at 05:35:39PM -0700, Tony Lindgren wrote:
 * Tony Lindgren t...@atomide.com [140514 14:57]:
  * Sebastian Reichel s...@kernel.org [140510 09:40]:
   Add SSI device tree data for OMAP3 and Nokia N900.
  
  Picking this patch into omap-for-v3.16/dt thanks.
 
 Just noticed that this patch seems to somehow break idle
 modes on n900, so dropping both dts changes for now.
 
 Basically the n900 debug LEDs won't ever go off with
 these two dts patches enabled, even without the modem
 drivers loaded. I did not dig deeper, but it's probably
 something related to hwmod using this data for some
 settings.

Is hwmod data interpreted at all without the DT entries?
The hwmod data may be wrong. The information from commit
398917ce161e10d3c66afaefdb89c73c64c4b02d was simply
interpolated from all information I found. The OMAP3
public TRM does not contain *any* information about the
ssi IP-Core.

 Sorry did not notice it earlier as I did not have the
 PM regression fix patches merged with my testing branch.

I hoped to see working modem in 3.16, which will probably
be used for the next Debian stable :(

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCHv5 09/10] DTS: ARM: OMAP3-N900: Add SSI support

Hi,

On Wed, May 21, 2014 at 11:43:19AM -0700, Tony Lindgren wrote:
   Just noticed that this patch seems to somehow break idle
   modes on n900, so dropping both dts changes for now.
   
   Basically the n900 debug LEDs won't ever go off with
   these two dts patches enabled, even without the modem
   drivers loaded. I did not dig deeper, but it's probably
   something related to hwmod using this data for some
   settings.
  
  Is hwmod data interpreted at all without the DT entries?
 
 Yes for autoidling unused devices. We parse that with
 omap_device_build_from_dt().

That function seems to parse DT stuff. What I meant was
not without the *driver*, but without the *DT entry*.

I think the hwmod entries are completly ignored until there
is a DT device?

  The hwmod data may be wrong. The information from commit
  398917ce161e10d3c66afaefdb89c73c64c4b02d was simply
  interpolated from all information I found. The OMAP3
  public TRM does not contain *any* information about the
  ssi IP-Core.
 
 It's probably something with the sysc or idlemodes that
 keeps things from idling. Maybe wrong address? Or wrong
 flags? I'm pretty sure it was the first .dts patch out of
 these two as the second one alone did not apply.
  
   Sorry did not notice it earlier as I did not have the
   PM regression fix patches merged with my testing branch.
  
  I hoped to see working modem in 3.16, which will probably
  be used for the next Debian stable :(
 
 That would indeed be nice, let's try to debug it as we
 still have few days.

I will have a look at it now.

 I'm finally able to test for PM regressions with DT patches,
 too  bad we did not have that earlier because of multiple issues.

Yes. More time would have been nice.

 Anyways, this dts issue should not prevent merging the
 driver changes, I'm all for that!

Of course, driver changes are unrelated. They are already
in linux-next btw.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCHv5 09/10] DTS: ARM: OMAP3-N900: Add SSI support

Hi,

On Wed, May 21, 2014 at 12:45:28PM -0700, Tony Lindgren wrote:
 * Tony Lindgren t...@atomide.com [140521 11:44]:
  * Sebastian Reichel s...@kernel.org [140521 11:26]:
   The hwmod data may be wrong. The information from commit
   398917ce161e10d3c66afaefdb89c73c64c4b02d was simply
   interpolated from all information I found. The OMAP3
   public TRM does not contain *any* information about the
   ssi IP-Core.
 
 Yeah seems to be just reserved..

Right. The only documentation of the SSI module is existing
code sent by Carlos / included in the maemo kernel.

  It's probably something with the sysc or idlemodes that
  keeps things from idling. Maybe wrong address? Or wrong
  flags? I'm pretty sure it was the first .dts patch out of
  these two as the second one alone did not apply.
 
 Hmm yeah below is probably how it should be, does this
 work for you? With this fix applied and your ssi dts
 patches n900 keeps hitting off-idle for me.

I can confirm, that the N900 hits idle states when the DT
patch and the hwmod patch is applied. I have not actually
tested if it also works without your hwmod patch.

There are still problems with the idle state if the driver is
actually loaded (and I see 100% runtime pm usage in powertop),
but that can be fixed later.

Feel free to add Tested-by/Acked-By to the hwmod patch.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCHv5 09/10] DTS: ARM: OMAP3-N900: Add SSI support

Hi,

On Wed, May 21, 2014 at 03:08:07PM -0700, Tony Lindgren wrote:
 * Sebastian Reichel s...@kernel.org [140521 14:51]:
  On Wed, May 21, 2014 at 12:45:28PM -0700, Tony Lindgren wrote:
  
  Right. The only documentation of the SSI module is existing
  code sent by Carlos / included in the maemo kernel.
 
 That's probably better than any documentation though :)

Both have their advantages. Just with the code its hard to add
features like context loss checks.

It's probably something with the sysc or idlemodes that
keeps things from idling. Maybe wrong address? Or wrong
flags? I'm pretty sure it was the first .dts patch out of
these two as the second one alone did not apply.
   
   Hmm yeah below is probably how it should be, does this
   work for you? With this fix applied and your ssi dts
   patches n900 keeps hitting off-idle for me.
  
  I can confirm, that the N900 hits idle states when the DT
  patch and the hwmod patch is applied. I have not actually
  tested if it also works without your hwmod patch.
  
  There are still problems with the idle state if the driver is
  actually loaded (and I see 100% runtime pm usage in powertop),
  but that can be fixed later.
  
  Feel free to add Tested-by/Acked-By to the hwmod patch.
 
 OK thanks for testing.

You are welcome.

 I'll apply your dts changes as soon as I have an ack from Paul on
 the hwmod changes. Probably best to queue them together to avoid
 PM breaking.

Ok. Sounds legit.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCHv3 0/5] tsc2005 DT binding

2014-05-15 Thread Sebastian Reichel

On Sat, Apr 26, 2014 at 01:56:14AM +0200, Sebastian Reichel wrote:
 This adds device tree support for the tsc2005 touchscreen
 controller, which is currently only used by the Nokia N900
 board.
 
 The patch does not update the reset pin handling for platform
 data based probe to avoid merge conflicts. The n900 platform
 code will be removed in the near future (3.16?) and the driver
 can be simplified once that has happened.

Ping. It would be nice to see this patchset in 3.16, since its
the last important hardware component missing for N900 DT boot.

-- Sebastian


signature.asc
Description: Digital signature

Status of Power Supply Subsystem

2014-05-16 Thread Sebastian Reichel

Hi,

It seems the maintainer of the power supply subsystem, Dmitry, has gone missing
in action since about mid-Feburary. I couldn't find any mail from him on the
usual mailinglists, he did not reply to any of my mails and the power supply
subsystem git tree mentioned in the MAINTAINERS file has not been touched since
2014-02-01 [0].

Is there a standard procedure to handle subsystem maintainers, who are missing
in action? I have patches for the power supply subsystem and have seen more
patches from other developers on the mailinglists.

[0] git://git.infradead.org/battery-2.6.git

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCHv4 0/4] tsc2005 DT binding

2014-05-29 Thread Sebastian Reichel

On Wed, May 21, 2014 at 07:36:10PM +0200, Sebastian Reichel wrote:
 This adds device tree support for the tsc2005 touchscreen
 controller, which is currently only used by the Nokia N900
 board.
 
 The patch does not update the reset pin handling for platform
 data based probe to avoid merge conflicts. The n900 platform
 code will be removed in the near future (3.17?) and the driver
 can be simplified once that has happened.
 
 Changes since v3 [0]:
  * Move common touchscreen DT handling code into its own file
  * Add regulator support to tsc2005 driver
  * Added N900 DTS patch for completeness. It should go via
Tony's Tree of course.

ping! It would be nice to have this in 3.16, since it makes
the N900 usable with the mainline kernel when booted in DT
mode. The DT bindings haven't changed for more than 3 weeks,
so we don't need to wait longer for feedback from the DT
maintainers AFAIK.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v4 2/8] OF: Introduce DT overlay support.

Hi,

On Mon, May 26, 2014 at 02:55:37PM +0300, Pantelis Antoniou wrote:
 On May 26, 2014, at 2:23 PM, Grant Likely wrote:
  On Mon, 26 May 2014 12:57:32 +0200, Geert Uytterhoeven 
  ge...@linux-m68k.org wrote:
  Heeheehee. We're back where we started. The original question is whether
  or not that is a valid approach. If the overlay represents something
  that can be hot plugged/unplugged, then passing it through to the second
  kernel would be the wrong thing to do. If it was a permenant addition,
  then it probably doesn't need to be removed.
  
  We do actually keep the overlay info in memory for the purpose of
  removal exactly so we can support hot unbinding of devices and drivers
  that make use of overlays.
 
 We can support either method. I am not feeling any wiser about which one 
 should be
 the default TBH, so what about exporting a property and let the platform 
 figure out which is more appropriate?

What about supporting negative overlays (so an overlay, that
removes DT entries)? That way one could reverse apply an overlay.
All the dependency stuff would basically be the users problem.  The
kernel only checks if it can apply an overlay (and return some error
code if it can't). This this code is needed anyway to check the
input from userspace.

As a result the overlay handling would basically have the same
behaviour as diff and patch :)

P.S.: Sorry if this has already been suggested. I have only read
mails from PATCHv4.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v4 2/8] OF: Introduce DT overlay support.

Hi,

On Mon, May 26, 2014 at 10:33:03PM +0100, Grant Likely wrote:
 After thinking about it more, I think it is very likely that removing
 all the overlays is the correct thing to do in the kexec use-case. When
 kexec-ing, it makes sense that we'd want the exact same behaviour from
 the kexec'ed kernel. That means we want the device drivers to do the
 same thing including loading whatever overlays they depend on.
 
 If the flattened tree was left applied, then the behaviour becomes
 different.
 
 I say always remove the overlays unless explicitly told not to, but I'm
 struggling to come up with use cases where keeping them applied is
 desirable.

I would assume, that I want them applied in most cases. DT describes
the hardware. If I kexec into a new kernel I change software, not
hardware.

Maybe I'm missing the main purpose of the feature. I currently see
two useful usecases for DT overlays:

1. The dtb the kernel is booted with cannot be changed for some
   reason, but the board has additional hardware attached (e.g.
   the user added a sensor on the i2c bus)
2. The hardware is changed on the fly (e.g. the user flashed the
   FPGA part of a zynq processor), sensors on i2c bus, ...

In both cases the kernel should be booted with the additional
overlay information IMHO. Though for the second case it should
be possible to remove the programmed hardware information
somehow.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v4 2/8] OF: Introduce DT overlay support.

Hi,

On Mon, May 26, 2014 at 08:14:08AM -0700, Guenter Roeck wrote:
 On 05/26/2014 08:09 AM, Sebastian Reichel wrote:
 On Mon, May 26, 2014 at 02:55:37PM +0300, Pantelis Antoniou wrote:
 On May 26, 2014, at 2:23 PM, Grant Likely wrote:
 On Mon, 26 May 2014 12:57:32 +0200, Geert Uytterhoeven 
 ge...@linux-m68k.org wrote:
 Heeheehee. We're back where we started. The original question is whether
 or not that is a valid approach. If the overlay represents something
 that can be hot plugged/unplugged, then passing it through to the second
 kernel would be the wrong thing to do. If it was a permenant addition,
 then it probably doesn't need to be removed.
 
 We do actually keep the overlay info in memory for the purpose of
 removal exactly so we can support hot unbinding of devices and drivers
 that make use of overlays.
 
 We can support either method. I am not feeling any wiser about which one 
 should be
 the default TBH, so what about exporting a property and let the platform
 figure out which is more appropriate?
 
 What about supporting negative overlays (so an overlay, that
 removes DT entries)? That way one could reverse apply an overlay.
 All the dependency stuff would basically be the users problem.  The
 kernel only checks if it can apply an overlay (and return some error
 code if it can't). This this code is needed anyway to check the
 input from userspace.
 
 
 Does that mean that I would need to describe such a negative overlay
 for each overlay to be able to get it removed ?
 
 This would introduce an endless source of problems with bad reverse
 overlay descriptions. Sure, that would be the users problem,
 but I don't think that would make it better.

I was thinking about supporting something like patch --reverse. So
you can try to undo the overlay by reverse applying it and you can
do it in arbitrary order.

Note: The dependency check must be done for all overlays coming from
userspace, so that's not a problem __here__. The reverse method can
simply reverse the overlay patch and apply it like a normal
overlay from userspace (and thus using the same dependency checks).

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v4 2/8] OF: Introduce DT overlay support.

On Mon, May 26, 2014 at 04:42:44PM -0700, Guenter Roeck wrote:
 On 05/26/2014 03:36 PM, Sebastian Reichel wrote:
 On Mon, May 26, 2014 at 10:33:03PM +0100, Grant Likely wrote:
 After thinking about it more, I think it is very likely that removing
 all the overlays is the correct thing to do in the kexec use-case. When
 kexec-ing, it makes sense that we'd want the exact same behaviour from
 the kexec'ed kernel. That means we want the device drivers to do the
 same thing including loading whatever overlays they depend on.
 
 If the flattened tree was left applied, then the behaviour becomes
 different.
 
 I say always remove the overlays unless explicitly told not to, but I'm
 struggling to come up with use cases where keeping them applied is
 desirable.
 
 I would assume, that I want them applied in most cases. DT describes
 the hardware. If I kexec into a new kernel I change software, not
 hardware.
 
 Maybe I'm missing the main purpose of the feature. I currently see
 two useful usecases for DT overlays:
 
 1. The dtb the kernel is booted with cannot be changed for some
 reason, but the board has additional hardware attached (e.g.
 the user added a sensor on the i2c bus)
 2. The hardware is changed on the fly (e.g. the user flashed the
 FPGA part of a zynq processor), sensors on i2c bus, ...
 
 In both cases the kernel should be booted with the additional
 overlay information IMHO. Though for the second case it should
 be possible to remove the programmed hardware information
 somehow.
 
 
 3. Some hot-plug device or card is inserted or removed.

Can you give a more specific example? I guess most hot-plug
devices are connected to busses, which are not described via
DT, but support auto-identification (USB, PCI, ...)

 I would argue that the kernel should _not_ be booted with the
 overlay in place.

well the device is still attached to the system when you kexec
into the new kernel, isn't it?

 Otherwise the code handling overlays would have to have special
 handling for the restart case, which is much more complex than
 just to re-insert the overlay when it is determined that the
 device or card is still there.

I assume, that the kernel cannot auto-detect the attached hardware.
Otherwise we don't need the DT entries, but can simply scan the bus.
So the restart case (or restart + kexec case if kexec behaves like a
restart) means, that userspace needs to provide the information
about device existence.

Removing the overlay is like dropping information supplied from the
user. Not something, which should be done carelessly.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCHv5 09/10] DTS: ARM: OMAP3-N900: Add SSI support

2014-05-27 Thread Sebastian Reichel

On Tue, May 27, 2014 at 01:35:44PM -0700, Tony Lindgren wrote:
 Based on chatting with Paul it seems that we most likely don't have
 bits for sysc_flags for SYSC_HAS_EMUFREE or SYSS_HAS_RESET_STATUS
 either. So applying the updated patch below, and the SSI dts changes
 into omap-for-v3.16/dt-v2.
 
 I'm keeping your previous ack Sebastian as the the idlemodes did
 not change from the previous version, hopefully that's OK with you.

Sure, go for it.

-- Sebastian


signature.asc
Description: Digital signature

[GIT PULL] HSI fixes for 3.16

Hi Linus,

The following changes since commit eafaebd987fcd001e2c123c050939a29c625d673:

  HSI: Introduce Nokia N900 modem driver (2014-05-16 00:55:42 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi.git 
tags/hsi-for-3.16-fixes1

for you to fetch changes up to b357d7b58f379ebe8038cd97b6204f2f5c52220d:

  hsi: omap_ssi_port: use normal module refcounting (2014-06-05 00:59:05 +0200)


HSI Fixes for the v3.16 series:

* Tighten Dependency between ssi-protocol and omap-ssi
  to fix build failures with randconfig.
* Use normal module refcounting in omap driver to fix
  build with disabled module support.


Arnd Bergmann (2):
  HSI: fix omap ssi driver dependency
  hsi: omap_ssi_port: use normal module refcounting

 drivers/hsi/clients/Kconfig | 2 +-
 drivers/hsi/controllers/omap_ssi_port.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

-- Sebastian


signature.asc
Description: Digital signature

Re: Status of Power Supply Subsystem

Hi Rafael,

 You can volunteer to take over the maintainership, but then I guess it would
 make sense to push this through the PM tree anyway, so please feel free to
 send a pull request with those fixes to me.

I waited a bit to see if maybe Dmitry or David want to give feedback. But I
haven't received anything, so I volunteer to take this subsystem over.

For now I have prepared a branch containing a single fix, which should be
applied to 3.16 and added a signed tag. Since linux-next still uses the
unmaintained power supply git tree the patch has not been in linux-next.
Apart from that I created a new branch for 3.17 stuff (DT support for
drivers, non-critical fixes, ...).

I will also send a patch for the MAINTAINERS file in a jiffy. I have not
included it in the branch, so that all involved persons get another chance
to complain.

-- Sebastian

The following changes since commit 951e273060d15b233a7f7ccaf76ba682b5b05a03:

  Merge branch 'perf-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2014-06-05 12:51:05 
-0700)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git 
tags/power-supply-for-3.16

for you to fetch changes up to 381078e8865725ee95efadf0d988d8e24cddf088:

  bq2415x_charger: Fix Atomic Sleep Bug (2014-06-08 14:46:16 +0200)


power supply changes for the 3.16 series:

- Just a fix for atomic sleep bug


Sebastian Reichel (1):
  bq2415x_charger: Fix Atomic Sleep Bug

 drivers/power/bq2415x_charger.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)


signature.asc
Description: Digital signature

[PATCH] MAINTAINERS: power_supply: update maintainership

Take over maintanence for orphaned power supply subsystem
and move the git tree to a new kernel.org based repository.

Signed-off-by: Sebastian Reichel s...@kernel.org
---
Hi,

As suggested by Rafael in [0] I volunteer to take over the orphaned
power supply subsystem.

[0] http://www.spinics.net/lists/kernel/msg1744793.html

-- Sebastian
---
 MAINTAINERS | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6c484ac..54d9cbf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6928,9 +6928,8 @@ F:include/linux/timer*
 F: kernel/*timer*
 
 POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
-M: Dmitry Eremin-Solenikov dbarysh...@gmail.com
-M: David Woodhouse dw...@infradead.org
-T: git git://git.infradead.org/battery-2.6.git
+M: Sebastian Reichel s...@kernel.org
+T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git
 S: Maintained
 F: include/linux/power_supply.h
 F: drivers/power/
-- 
2.0.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv2 1/2] rx51_battery: convert to iio consumer

On Sat, Jun 14, 2014 at 10:32:32AM +0200, Pavel Machek wrote:
  The problem is, that the power subsystem maintainers seem to be too
  busy with real life. The last change in their git [0] was 2014-02-01
  and I haven't seen any mail from them on the mailinglist since about
  the same time. I have just queried his status @ Google+ (there were
  some life-signs there).
 
 If there is still no life out there, you may want to ask
 Rafael W. to queue the patches...

Don't worry, I haven't forgotten the patches. I don't think they
make it into 3.16, but they will go into 3.17. For now I have
put them into a dev branch on [0] and requested to take over the
power supply subsystem (see thread [1] on LKML).

[0] https://git.kernel.org/cgit/linux/kernel/git/sre/linux-power-supply.git
[1] https://lkml.org/lkml/2014/5/16/504

-- Sebastian


signature.asc
Description: Digital signature

Re: Status of Power Supply Subsystem

On Sat, Jun 14, 2014 at 08:59:35PM +0400, Dmitry Eremin-Solenikov wrote:
 Hello, colleagues,

Hi, welcome back :)

 On Sat, Jun 14, 2014 at 7:53 PM, David Woodhouse dw...@infradead.org wrote:
  On Sat, 2014-06-14 at 17:36 +0200, Sebastian Reichel wrote:
 
  I waited a bit to see if maybe Dmitry or David want to give feedback.
  But I haven't received anything, so I volunteer to take this subsystem
  over.
 
 I'm sorry, I had too much trouble on my work to be able to think about
 community projects. My work load is now getting back to normal,
 so I will probably have more time.

No problem. It would be nice if you appoint somebody to be a
temporary maintainer for your subsystems next time.

  I've never really done much with the subsystem except getting Dmitry set
  up to maintain it. I certainly have no objection if you want to take it
  over and Dmitry isn't objecting.
 
 I'd welcome any help, team or co-maintenance of any kind. What do you
 think about patchwork?

 BTW, David, I remember several people (including myself) asking for
 a separate power-related ML to be set up on the infradead.org. Could you
 please set it up? I think it might help all of us.

I think having a power-supply mailinglist and patchwork would be
really helpful.

  If you like, you can send me a SSH public key and I'll give you access
  to the existing git tree on git.infradead.org to take it over.
 
  You can work in coordination with Dmitry if he comes back to life, that
  way.
 
 I'm doing a scan over my patches inbox during next few days (yes, huge
 task after so long time). I'll just base it on your kernel. After -rc1 we
 can think about something sane.

My patch [0] was the only fix suitable for -rc2+ from all power
supply related mails I could find on LKML. I have sent a pull
request for that one to Rafael.

You have a couple of weeks more time to catch up if you are fine
with him pulling the patch.

[0] 
https://git.kernel.org/cgit/linux/kernel/git/sre/linux-power-supply.git/commit/?h=next

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH] [RFC PATCH v2] power:reset: Add defer reset object to send board specific reset

2014-06-15 Thread Sebastian Reichel

Hi,

On Sun, Jun 15, 2014 at 03:11:29PM +0800, Houcheng Lin wrote:
 The Problem
 ---
 The reset signal on a hardware board is send either:
 - during machine initialization
 - during bus master's initialization
 
 In some hardware design, devices on bus need a non-standard and extra reset
 signal after bus is initialied. Most reason is to wake up device from hanging
 state.
 
 The board spefic reset code can not be put into machine init code, as it is
 too early. This code can not also be put onto chip's driver, as it is board
 specific and not suitable for a common chip driver.
 
 Defer Reset Object
 --
 The defer reset object is to resolve this issue, developer can put a defer-
 reset device on the board's dts file and enable DEFER RESET OBJECT CONFIG.
 During driver init-calls, a defer-reset object is created and issue reset 
 signal
 after the enclosing device is initialized.
 
 This eliminate the need to rewrite a driver module with only one purpose: 
 sending
 a board specific reset. This also allow mainstream kernel to support many 
 boards
 that modify the common drivers to send board specific reset. Configuring 
 defer-reset
 device in dts leave the board specific reset rules on board level and simple 
 to
 maintain.
 
 Example dts File
 
 usb-ehci-chip@1211000{
 usb-phy = usb2_phy;
 defer_reset_vbus {
 compatible = defer-reset;
 reset-gpios = gpx3 5 1;
 reset-init = 0;
 reset-end = 1;
 delay = 5;
 };
 };
 
 Block Diagram of dts File
 -
 +-+
 | usb-ehci-chip@1211000   |
 |   +-+   |
 |   | defer-reset(gpx3)   |   |
 |   +-+   |
 +-+
 
 Signed-off-by: Houcheng Lin houch...@gmail.com
 ---
  .../devicetree/bindings/gpio/gpio-defer-reset.txt  |  22 +++
  drivers/power/reset/Kconfig|   8 +
  drivers/power/reset/Makefile   |   1 +
  drivers/power/reset/gpio-defer-reset.c | 192 
 +

I think this belongs to drivers/reset and not to drivers/power/reset.
The drivers in drivers/power/reset are about board reboot / shutdown.
This driver seems to be used for periphals.

  4 files changed, 223 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/gpio/gpio-defer-reset.txt
  create mode 100644 drivers/power/reset/gpio-defer-reset.c
 
 diff --git a/Documentation/devicetree/bindings/gpio/gpio-defer-reset.txt 
 b/Documentation/devicetree/bindings/gpio/gpio-defer-reset.txt
 new file mode 100644
 index 000..5d55830
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/gpio/gpio-defer-reset.txt
 @@ -0,0 +1,22 @@
 +GPIO defer reset binding
 +
 +Put a defer-reset device in a device node and enable DEFER RESET OBJECT 
 CONFIG.
 +During driver init-calls, a defer-reset object will be created and issue 
 reset
 +signal after the enclosing device node's initialization complete.
 +
 +Required properties:
 +- compatible:
 +  - defer-reset for creating defer reset object
 +- reset-gpio: specify gpio pin, can be an array.
 +- reset-init: specify reset signal initial value, can be 0 or 1.

You can simply use GPIO's HIGH_ACTIVE / LOW_ACTIVE flag for the
initial value.

 +- reset-end: specify reset signal end value, can be 0 or 1.

You can use a property without a value for booleans. If the property
is there, the value is 1 and if its missing the value is 0.

For example in your case you could use

hold-reset-line;

to inform the system, that the reset signal should not be changed
back after the specified time.

 +- delay: specify reset duration in ms.

Alternatively you could do this via the duration. An infinite long
reset signal basically means, that the line is never changed back.

 +
 +Example:
 + defer_reset_vbus {
 + compatible = defer-reset;
 + reset-gpios = gpx3 5 1;
 + reset-init = 0;
 + reset-end = 1;
 + delay = 5;
 + };

To give a few examples for the above comments:

/* keep gpx3 5 low for 5ms, change back to high afterwards */
defer_reset_vbus {
compatible = defer-reset;
reset-gpios = gpx3 5 GPIO_ACTIVE_LOW;
duration = 5;
};

/* keep gpx3 5 high for 5ms, change back to low afterwards */
defer_reset_vbus {
compatible = defer-reset;
reset-gpios = gpx3 5 GPIO_ACTIVE_HIGH;
duration = 5;
};

/* keep gpx3 5 low */
defer_reset_vbus {
compatible = defer-reset;
reset-gpios = gpx3 5 GPIO_ACTIVE_LOW;
duration = 0;
};

 [...]

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH] MAINTAINERS: power_supply: update maintainership

2014-06-15 Thread Sebastian Reichel

Hi Stephen,

On Sun, Jun 15, 2014 at 11:20:42AM +1000, Stephen Rothwell wrote:
Hi Sebastian,

On Sat, 14 Jun 2014 17:32:09 +0200 Sebastian Reichel s...@kernel.org wrote:

Take over maintanence for orphaned power supply subsystem
and move the git tree to a new kernel.org based repository.

Signed-off-by: Sebastian Reichel s...@kernel.org
---
Hi,

As suggested by Rafael in [0] I volunteer to take over the orphaned
power supply subsystem.

[0] http://www.spinics.net/lists/kernel/msg1744793.html

POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
-M: Dmitry Eremin-Solenikov dbarysh...@gmail.com
-M: David Woodhouse dw...@infradead.org
-T: git git://git.infradead.org/battery-2.6.git

OK, the master branch of that tree is in linux-next as the battery
tree. My contact for that tree is Anton Vorontsov (cc'd) and its
latest commit is from January.

He switched with Dmitry Eremin-Solenikov in January:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/MAINTAINERS?id=573189354b7c97cd2256b87cf083ee435584594e

So should I dump that tree in favour of the one below with you as
the contact? If so, whatr branch of that tree should I fetch?
(And should I change its linux-next name?)

No. David Woodhouse offered me git access to the existing tree
yesterday and Dmitry suddenly gave a life sign again:

https://lkml.org/lkml/2014/6/14/94
https://lkml.org/lkml/2014/6/14/106

In short: ignore the patch. Probably your contact should be changed,
though.

-- Sebastian

signature.asc
Description: Digital signature

[GIT PULL] HSI changes for 3.16

2014-06-02 Thread Sebastian Reichel

Hi Linus,

Please pull the following changes for the HSI subsystem, which I
have taken over from Carlos Chinea carlos.chi...@nokia.com.

The below patches have been worked on in the linux-omap mailinglist
for 10 months and are well tested in linux-next (have been in there
for more than two weeks) without any problems arising. Apart from
that potential regressions are very limited, because the subsystem
is not yet used by any platform in the mainline kernel.

-- Sebastian

The following changes since commit d1db0eea852497762cab43b905b879dfcd3b8987:

  Linux 3.15-rc3 (2014-04-27 19:29:27 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi.git 
tags/hsi-for-3.16

for you to fetch changes up to eafaebd987fcd001e2c123c050939a29c625d673:

  HSI: Introduce Nokia N900 modem driver (2014-05-16 00:55:42 +0200)


HSI changes for the v3.16 series:

 - Add some documentation for the HSI subsystem

 - Add Device Tree support for the HSI subsystem

 - Add OMAP3 SSI driver (SSI is a legacy variant of HSI)

 - Add Nokia N900 Modem driver (without speech support for now)


Sebastian Reichel (11):
  Documentation: HSI: Add some general description for the HSI subsystem
  MAINTAINERS: update HSI entry
  HSI: hsi-char: fix driver for multiport scenarios
  HSI: method to unregister clients from an hsi port
  HSI: Add channel resource support to HSI clients
  HSI: export method to (un)register clients
  HSI: Add common DT binding for HSI client devices
  HSI: Introduce OMAP SSI driver
  Documentation: DT: omap-ssi binding documentation
  HSI: Introduce driver for SSI Protocol
  HSI: Introduce Nokia N900 modem driver

 Documentation/devicetree/bindings/hsi/client-devices.txt |   44 +++
 Documentation/devicetree/bindings/hsi/nokia-modem.txt|   57 
 Documentation/devicetree/bindings/hsi/omap-ssi.txt   |   97 ++
 Documentation/hsi.txt|   75 +
 MAINTAINERS  |4 +-
 drivers/hsi/Kconfig  |1 +
 drivers/hsi/Makefile |1 +
 drivers/hsi/clients/Kconfig  |   17 ++
 drivers/hsi/clients/Makefile |4 +-
 drivers/hsi/clients/hsi_char.c   |   14 +-
 drivers/hsi/clients/nokia-modem.c|  285 
++
 drivers/hsi/clients/ssi_protocol.c   | 1191 
++
 drivers/hsi/controllers/Kconfig  |   19 ++
 drivers/hsi/controllers/Makefile |6 +
 drivers/hsi/controllers/omap_ssi.c   |  625 
+++
 drivers/hsi/controllers/omap_ssi.h   |  166 +++
 drivers/hsi/controllers/omap_ssi_port.c  | 1399 
+++
 drivers/hsi/controllers/omap_ssi_regs.h  |  171 +++
 drivers/hsi/hsi.c|  275 
-
 include/linux/hsi/hsi.h  |   39 ++-
 include/linux/hsi/ssi_protocol.h |   42 +++
 21 files changed, 4513 insertions(+), 19 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/hsi/client-devices.txt
 create mode 100644 Documentation/devicetree/bindings/hsi/nokia-modem.txt
 create mode 100644 Documentation/devicetree/bindings/hsi/omap-ssi.txt
 create mode 100644 Documentation/hsi.txt
 create mode 100644 drivers/hsi/clients/nokia-modem.c
 create mode 100644 drivers/hsi/clients/ssi_protocol.c
 create mode 100644 drivers/hsi/controllers/Kconfig
 create mode 100644 drivers/hsi/controllers/Makefile
 create mode 100644 drivers/hsi/controllers/omap_ssi.c
 create mode 100644 drivers/hsi/controllers/omap_ssi.h
 create mode 100644 drivers/hsi/controllers/omap_ssi_port.c
 create mode 100644 drivers/hsi/controllers/omap_ssi_regs.h
 create mode 100644 include/linux/hsi/ssi_protocol.h


signature.asc
Description: Digital signature

Re: [PATCHv4 0/4] tsc2005 DT binding

2014-06-02 Thread Sebastian Reichel

Hi Dmitry,

On Fri, May 30, 2014 at 12:58:21PM -0700, Dmitry Torokhov wrote:
 On Thu, May 29, 2014 at 03:33:57PM +0200, Sebastian Reichel wrote:
  On Wed, May 21, 2014 at 07:36:10PM +0200, Sebastian Reichel wrote:
  ping! It would be nice to have this in 3.16, since it makes
  the N900 usable with the mainline kernel when booted in DT
  mode. The DT bindings haven't changed for more than 3 weeks,
  so we don't need to wait longer for feedback from the DT
  maintainers AFAIK.
 
 I applied the series, could you please take a peek at my 'next' branch
 to make sure I did not miss anything?

Patches look ok, I also tested the branch on the phone and get
events after running the selftest once (which resets the
controller). Without running the selftest no events get reported.
I will have a look at that in the next days.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v2] hsi: omap_ssi_port: use normal module refcounting

2014-06-04 Thread Sebastian Reichel

Hi,

On Wed, Jun 04, 2014 at 10:00:59AM +0200, Arnd Bergmann wrote:
 The ref_module() function is used for internal housekeeping of the
 module code, it's not normally used by subsystems or device drivers,
 and the use of ref_module in the omap_ssi_port driver causes a link
 build error when modules are disabled:
 
 hsi/controllers/omap_ssi_port.c: In function 'ssi_port_probe':
 hsi/controllers/omap_ssi_port.c:1119:2: error: implicit declaration of 
 function 'ref_module' [-Werror=implicit-function-declaration]
 
 This changes the omap_ssi_port driver to use try_module_get()
 and module_put() instead, which is the normal way to ensure that
 the driver providing a device used in another module does not
 go away.

Thanks, applied:

https://git.kernel.org/cgit/linux/kernel/git/sre/linux-hsi.git/commit/?h=for-nextid=b357d7b58f379ebe8038cd97b6204f2f5c52220d

-- Sebastian


signature.asc
Description: Digital signature

[PATCH] ARM: OMAP2+: Add support for thumb mode on DT booted N900

2014-02-05 Thread Sebastian Reichel

Without enabling the workaround for ARM errata 430973 thumb
compiled userland crashes randomly on the Nokia N900.

Signed-off-by: Sebastian Reichel s...@debian.org
---
Hi Tony,

I think this patch should be added into some fix branch for 3.14-rcX.

-- Sebastian
---
 arch/arm/mach-omap2/pdata-quirks.c | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index 3d5b24d..7929df3 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -22,6 +22,8 @@
 #include common-board-devices.h
 #include dss-common.h
 #include control.h
+#include omap-secure.h
+#include soc.h
 
 struct pdata_init {
const char *compatible;
@@ -169,6 +171,21 @@ static void __init am3517_evm_legacy_init(void)
omap_ctrl_writel(v, AM35XX_CONTROL_IP_SW_RESET);
omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET); /* OCP barrier */
 }
+
+static void __init nokia_n900_legacy_init(void)
+{
+   hsmmc2_internal_input_clk();
+
+   if (omap_type() == OMAP2_DEVICE_TYPE_SEC) {
+   if (IS_ENABLED(CONFIG_ARM_ERRATA_430973)) {
+   pr_info(RX-51: Enabling ARM errata 430973 
workaround\n);
+   /* set IBE to 1 */
+   rx51_secure_update_aux_cr(BIT(6), 0);
+   } else {
+   pr_warning(RX-51: Not enabling ARM errata 430973 
workaround\n);
+   }
+   }
+}
 #endif /* CONFIG_ARCH_OMAP3 */
 
 #ifdef CONFIG_ARCH_OMAP4
@@ -259,7 +276,7 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
 static struct pdata_init pdata_quirks[] __initdata = {
 #ifdef CONFIG_ARCH_OMAP3
{ compulab,omap3-sbc-t3730, omap3_sbc_t3730_legacy_init, },
-   { nokia,omap3-n900, hsmmc2_internal_input_clk, },
+   { nokia,omap3-n900, nokia_n900_legacy_init, },
{ nokia,omap3-n9, hsmmc2_internal_input_clk, },
{ nokia,omap3-n950, hsmmc2_internal_input_clk, },
{ isee,omap3-igep0020, omap3_igep0020_legacy_init, },
-- 
1.8.5.3

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: OMAP2+: Add support for thumb mode on DT booted N900

2014-02-05 Thread Sebastian Reichel

Hi Pali,

On Wed, Feb 05, 2014 at 02:12:56PM +0100, Pali Rohár wrote:
 1) Why are you using if (IS_ENABLED(CONFIG_ARM_ERRATA_430973)) instead #ifdef 
 ?

This is the preferred kernel style as far as I know.

 2) Why do you not write warning or info when omap type is not
 OMAP2_DEVICE_TYPE_SEC (e.g qemu) ?

I assumed, that the workaround is not needed for this device type.

I just added the warning for missing CONFIG_ARM_ERRATA_430973,
because its very likely a misconfigured kernel.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH] ARM: OMAP2+: Add support for thumb mode on DT booted N900

2014-02-05 Thread Sebastian Reichel

Hi,

On Wed, Feb 05, 2014 at 05:38:54PM +0100, Pali Rohár wrote:
  I assumed, that the workaround is not needed for this device type.
 
 That rx51 secure call must not be called on non secure devices (e.g.
 qemu), because it cause kernel crash. So I thought that kernel should
 write something like secure call is disabled on that device types.
 Kernel code for errata 430973 will update ibe bit for non secure
 devices.

Do you see any advantage in having that message?

  I just added the warning for missing CONFIG_ARM_ERRATA_430973,
  because its very likely a misconfigured kernel.
 
 Yes, it can be misconfigured kernel, but if you do not have any thumb
 binary (like stock Maemo 5 system), then it is safe and OK.

I think running this kernel may also be a potential security
problem. If I understand it right the ARM core is left in an
unstable state when you run Thumb code, so this may result in
funny effects in the kernel?

-- Sebastian


signature.asc
Description: Digital signature

Re: [11/11] system 1: Saving energy using DVFS

2014-01-20 Thread Sebastian Reichel

On Mon, Jan 20, 2014 at 06:54:32PM +0100, Pavel Machek wrote:
 On Mon 2014-01-20 17:10:29, Catalin Marinas wrote:
  On Mon, Jan 20, 2014 at 04:49:26PM +, Pavel Machek wrote:
To save energy, the higher frequencies should be avoided and only used
when the application performance requirements can not be satisfied
otherwise (e.g. spread tasks across more cpus if possible).
   
   I argue this is untrue for any task where user waits for its
   completion with screen on. (And that's quite important subset).
   
   Lets take Nokia n900 as an example. 
   
   (source http://wiki.maemo.org/N900_Hardware_Power_Consumption)
   
   Sleeping CPU: 2mA
   Screen on: 230mA
   CPU loaded: 250mA
   
   Now, lets believe your numbers and pretend system can operate at 33%
   of speed with 11% power consumption.
   
   Lets take task that takes 10 seconds on max frequency:
   
 ~ 10s * 470mA   = 4700mAs
   
   You suggest running at 33% speed, instead; that means 30 seconds on
   low requency.
   
   CPU on low: 25mA (assumed).
   
~ 30s * 255mA= 7650mAs
   
   Hmm. So race to idle is good thing on Intel machines, and it is good
   thing on ARM design I have access to.
  
  Race to idle doesn't mean that the screen goes off as well. Let's say
  the screen stays on for 1 min and the CPU needs to be running for 10s
  over this minute, in the first case you have:
 
 No, it does not. I just assumed user is continuing to use his
 machine. Obviously, waiting 60 seconds with screen on will make the
 difference look smaller. But your solution still means user has to
 wait longer _and_ you consume more battery doing so.
 
 And this is for any task where user waits for result with screen
 on. Like rendering a webpage. Like opening settings screen. Like
 installing application.
 
 There are not too many background tasks on a cellphone.
 
 But hey, maybe you are right and running at lowest possible frequency
 is right. Please provide concrete numbers like I did.

So what about using the display status information for power
management? Basically always using the lowest frequency should be ok
on phones if the display is disabled?

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCHv3] dt: binding documentation for bq2415x charger

2014-01-21 Thread Sebastian Reichel

Hi Dmitry,

 Add devicetree binding documentation for bq2415x charger.
 
 Signed-off-by: Sebastian Reichel s...@debian.org
 Acked-by: Pavel Machek pa...@ucw.cz

I've seen, that you just sent a pull request for the power supply
tree. Can you please add this patch [0] and send another pull
request? It should go into the kernel together with the bq2415x DT
support patch!

[0] http://www.spinics.net/lists/devicetree/msg18023.html

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCHv3] dt: binding documentation for bq2415x charger

2014-01-22 Thread Sebastian Reichel

On Wed, Jan 22, 2014 at 04:07:25PM +0400, Dmitry Eremin-Solenikov wrote:
 On Wed, Jan 22, 2014 at 12:48 AM, Sebastian Reichel s...@ring0.de wrote:
  Add devicetree binding documentation for bq2415x charger.
  [...]
 
  I've seen, that you just sent a pull request for the power supply
  tree. Can you please add this patch [0] and send another pull
  request? It should go into the kernel together with the bq2415x DT
  support patch!
 
 If that is fine with you, I will add this to a 'fixes' branch and
 send a pull request somewhere near -rc2/-rc3. Agreed?

Sounds fine to me.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCHv2 0/5] wl1251 device tree support

2014-01-06 Thread Sebastian Reichel

Hi John,

 The following patchset adds device tree support to
 the spi variant of the wl1251 driver.

 Luciano Coelho (1):
   wl1251: split wl251 platform data to a separate structure
 
 Sebastian Reichel (4):
   wl1251: move power GPIO handling into the driver
   wl1251: spi: add vio regulator support
   wl1251: spi: add device tree support
   Documentation: dt: wireless: Add wl1251

What's the status of this patchset? Tony prepared an immutable
branch for patches 1+2 [0]. I think the other patches are also ok
(at least there were no more complains from the DT binding
maintainers). It would be nice to have wl1251 DT support in 3.14.

[0] http://www.spinics.net/lists/linux-omap/msg101165.html

-- Sebastian


signature.asc
Description: Digital signature

Re: [RFC PATCH v1 2/5] misc: tda8026: Add NXP TDA8026 PHY driver

2014-01-07 Thread Sebastian Reichel

On Tue, Jan 07, 2014 at 12:06:37PM +0530, Satish Patel wrote:
  +   if (pdata-irq == 0) {
  +   /* look for the field irq-gpio in DT */
  +   irq_gpio = of_get_named_gpio(np, irq-gpio, 0);
  +   if (!gpio_is_valid(irq_gpio)) {
  +   dev_err(dev, Failed to get irq gpio,\n);
  +   return -EIO;
  +   }
  
  This is horrible. If the gpio controller can act as an irq controller
 
 No it's not true. Let me clarify the signal flow,
 
 Pins = GPIO = GPIO BANK = Interrupt controller = CPU/MPU

This is done automatically if you use the gpio controller as
interrupt source (here with GPIO line 22 as example):

device-tree-node {
interrupts-extended = gpio1 22;
};

alternatively, but then the irqs from the normal irq controller
can't be used:

device-tree-node {
interrupt-parent = gpio1;
interrupts = 22;
};

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v4 1/5] mfd: omap-usb-host: Update DT clock binding information

2014-01-08 Thread Sebastian Reichel

On Wed, Jan 08, 2014 at 11:45:38AM +0530, Roger Quadros wrote:
 diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt 
 b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
 index b381fa6..5635202 100644
 --- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
 +++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
 @@ -32,6 +32,10 @@ Optional properties:
  - single-ulpi-bypass: Must be present if the controller contains a single
ULPI bypass control bit. e.g. OMAP3 silicon = ES2.1
  
 +- clocks: phandle to 60MHz functional clock to the USB Host module.
 +
 +- clock-names: must be init_60m_fclk
 +
  Required properties if child node exists:
  
  - #address-cells: Must be 1

I have some questions:

What about the other clocks acquired in drivers/mfd/omap-usb-host.c? Shouldn't
all of those be provided by via the DT phandle?

Should the clk_get be changed to of_clk_get()/of_clk_get_by_name() in the
driver? This would potentially remove the need of the init_60m_fclk name.

$ grep clk_get drivers/mfd/omap-usb-host.c
omap-ehci_logic_fck = clk_get(dev, ehci_logic_fck);
omap-utmi_p1_gfclk = clk_get(dev, utmi_p1_gfclk);
omap-utmi_p2_gfclk = clk_get(dev, utmi_p2_gfclk);
omap-xclk60mhsp1_ck = clk_get(dev, xclk60mhsp1_ck);
omap-xclk60mhsp2_ck = clk_get(dev, xclk60mhsp2_ck);
omap-init_60m_fclk = clk_get(dev, init_60m_fclk);
omap-utmi_clk[i] = clk_get(dev, clkname);
omap-hsic480m_clk[i] = clk_get(dev, clkname);
omap-hsic60m_clk[i] = clk_get(dev, clkname);

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v4 1/5] mfd: omap-usb-host: Update DT clock binding information

2014-01-08 Thread Sebastian Reichel

Hi,

On Wed, Jan 08, 2014 at 03:39:36PM +0530, Roger Quadros wrote:
  What about the other clocks acquired in drivers/mfd/omap-usb-host.c? 
  Shouldn't
  all of those be provided by via the DT phandle?
 
 All those clocks are identically named across the OMAP SoCs and are unique 
 for each
 SoC, so providing DT phandle for all of them is not required.
 
 The init_60m_fclk was renamed to l3init_60m_fclk in OMAP5, and hence the need 
 for
 this binding.

I understand the intention of this patch. I was just wondering if
all the clocks should be referenced from DT even if that is not
strictly needed at the moment. This would make clocks similar to
other resources like regulators, gpios, irqs, ...

Having the clocks referenced from DT looks cleaner to me. It means I
can check the DT file for any resources used by a driver. It also
creates some kind of consistency in the kernel.

  Should the clk_get be changed to of_clk_get()/of_clk_get_by_name() in the
  driver? This would potentially remove the need of the init_60m_fclk name.
 
 If we use of_clk_xxx() then we'll need to update DT nodes for OMAP4 and OMAP3 
 as
 well to explicitly provide the clock phandle.

I'm aware of this.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v4] Bluetooth: Add hci_h4p driver

2014-01-09 Thread Sebastian Reichel

Hi Pavel,

On Fri, Jan 10, 2014 at 12:38:43AM +0100, Pavel Machek wrote:
  Here are some cleanup suggestions for probe, removal  module
  initialization functions.
 
 ...and here's the patch implementing those suggestions. Thanks!

That looks right, but you forgot to cleanup hci_h4p_remove. Also I
suggest to simply merge this as v5.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode

2014-01-19 Thread Sebastian Reichel

On Mon, Dec 02, 2013 at 02:45:06AM +0100, Michael Trimarchi wrote:
 On Mon, Dec 2, 2013 at 1:24 AM, Anton Vorontsov an...@enomsg.org wrote:
  On Mon, Dec 02, 2013 at 01:02:40AM +0100, Michael Trimarchi wrote:
  On Sun, Dec 1, 2013 at 11:37 PM, Anton Vorontsov an...@enomsg.org wrote:
   On Mon, Nov 25, 2013 at 08:16:34PM +0100, Michael Trimarchi wrote:
   ...
So you can read this value without any type of synchronization
with the power_supply_core
and sysfs implementation?
   ...
   https://lists.ubuntu.com/archives/kernel-team/2013-January/025206.html
  
   I found and equivalent scenario that I was trying to said
  
   That's a good question, actually. Even though in Pali's case the notifier
   is atomic (so that we are pretty confident that the object won't be
   unregistered), there is still a possiblity of a dead lock, for example. 
   So
 
  So if the get_property is a sleeping function it will be a deadlock. Right?
 
  All kind of bad things might happen, yes. But before that I would expect a
  bunch of warnings from might_sleep() stuff.
 
  I would recommend to test the patches using preempt/smp kernels + various
  DEBUG_ kernel options set.
 
 
 Is it more simple to make it not atomic and use a mutex in get_property?

I just built a kernel with CONFIG_DEBUG_ATOMIC_SLEEP to test another
driver and got the following output for bq2415x:

[7.667449] Workqueue: events power_supply_changed_work
[7.673034] [c0015c28] (unwind_backtrace+0x0/0xe0) from [c0011e1c] 
(show_stack+0x10/0x14)
[7.682098] [c0011e1c] (show_stack+0x10/0x14) from [c052cdd0] 
(dump_stack+0x78/0xac)
[7.690704] [c052cdd0] (dump_stack+0x78/0xac) from [c052a044] 
(__schedule_bug+0x48/0x60)
[7.699645] [c052a044] (__schedule_bug+0x48/0x60) from [c053071c] 
(__schedule+0x74/0x638)
[7.708618] [c053071c] (__schedule+0x74/0x638) from [c05301fc] 
(schedule_timeout+0x1dc/0x24c)
[7.718017] [c05301fc] (schedule_timeout+0x1dc/0x24c) from [c05316ec] 
(wait_for_common+0x138/0x17c)
[7.727966] [c05316ec] (wait_for_common+0x138/0x17c) from [c0362a70] 
(omap_i2c_xfer+0x340/0x4a0)
[7.737640] [c0362a70] (omap_i2c_xfer+0x340/0x4a0) from [c035d928] 
(__i2c_transfer+0x40/0x74)
[7.747039] [c035d928] (__i2c_transfer+0x40/0x74) from [c035e22c] 
(i2c_transfer+0x6c/0x90)
[7.756195] [c035e22c] (i2c_transfer+0x6c/0x90) from [c037ad24] 
(bq2415x_i2c_write+0x48/0x78)
[7.765563] [c037ad24] (bq2415x_i2c_write+0x48/0x78) from [c037ae60] 
(bq2415x_set_weak_battery_voltage+0x4c/0x50)
[7.776824] [c037ae60] (bq2415x_set_weak_battery_voltage+0x4c/0x50) from 
[c037bce8] (bq2415x_set_mode+0xdc/0x14c)
[7.788085] [c037bce8] (bq2415x_set_mode+0xdc/0x14c) from [c037bfb8] 
(bq2415x_notifier_call+0xa8/0xb4)
[7.798309] [c037bfb8] (bq2415x_notifier_call+0xa8/0xb4) from [c005f228] 
(notifier_call_chain+0x38/0x68)
[7.808715] [c005f228] (notifier_call_chain+0x38/0x68) from [c005f284] 
(__atomic_notifier_call_chain+0x2c/0x3c)
[7.819732] [c005f284] (__atomic_notifier_call_chain+0x2c/0x3c) from 
[c005f2a8] (atomic_notifier_call_chain+0x14/0x18)
[7.831420] [c005f2a8] (atomic_notifier_call_chain+0x14/0x18) from 
[c0378078] (power_supply_changed_work+0x6c/0xb8)
[7.842864] [c0378078] (power_supply_changed_work+0x6c/0xb8) from 
[c00556c0] (process_one_work+0x248/0x440)
[7.853546] [c00556c0] (process_one_work+0x248/0x440) from [c0055d6c] 
(worker_thread+0x208/0x350)
[7.863372] [c0055d6c] (worker_thread+0x208/0x350) from [c005b0ac] 
(kthread+0xc8/0xdc)
[7.872131] [c005b0ac] (kthread+0xc8/0xdc) from [c000e138] 
(ret_from_fork+0x14/0x3c)

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v2 2/3] bq2415x_charger: Use power_supply notifier for automode

2014-01-20 Thread Sebastian Reichel

On Mon, Jan 20, 2014 at 10:21:29AM +, Russell King - ARM Linux wrote:
 And another one using that evil mail-followup-to header:
 
 Mail-Followup-To: Pali Rohár pali.ro...@gmail.com,
 Anton Vorontsov an...@enomsg.org,
 Michael Trimarchi mich...@amarulasolutions.com,
 David Woodhouse dw...@infradead.org,
 Tony Lindgren t...@atomide.com,
 Russell King li...@arm.linux.org.uk, linux-kernel@vger.kernel.org,
 Linux OMAP Mailing List linux-o...@vger.kernel.org,
 freemangor...@abv.bg, aaro.koski...@iki.fi, pa...@ucw.cz
 
 which results in all the above being moved into the To: header by
 unsuspecting recipients who reply to your message.

Thanks for the hint. Should be fixed now.

-- Sebastian


signature.asc
Description: Digital signature

[RFCv4 02/11] HSI: hsi-char: add Device Tree support

Add of_match_table to hsi_char driver, so that it can
be referenced from Device Tree.

Signed-off-by: Sebastian Reichel s...@debian.org
---
 drivers/hsi/clients/hsi_char.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/hsi/clients/hsi_char.c b/drivers/hsi/clients/hsi_char.c
index e61e5f9..7f64bed 100644
--- a/drivers/hsi/clients/hsi_char.c
+++ b/drivers/hsi/clients/hsi_char.c
@@ -42,6 +42,7 @@
 #include linux/stat.h
 #include linux/hsi/hsi.h
 #include linux/hsi/hsi_char.h
+#include linux/of_device.h
 
 #define HSC_DEVS   16 /* Num of channels */
 #define HSC_MSGS   4
@@ -758,12 +759,22 @@ static int hsc_remove(struct device *dev)
return 0;
 }
 
+#ifdef CONFIG_OF
+static const struct of_device_id hsi_char_of_match[] = {
+   { .compatible = ssi-char, },
+   { .compatible = hsi-char, },
+   {},
+};
+MODULE_DEVICE_TABLE(of, hsi_char_of_match);
+#endif
+
 static struct hsi_client_driver hsc_driver = {
.driver = {
.name   = hsi_char,
.owner  = THIS_MODULE,
.probe  = hsc_probe,
.remove = hsc_remove,
+   .of_match_table = of_match_ptr(hsi_char_of_match),
},
 };
 
-- 
1.8.5.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFCv4 05/11] Documentation: DT: omap-ssi binding documentation

Create device tree binding documentation for
OMAP Synchronous Serial Interface (SSI) device.

Signed-off-by: Sebastian Reichel s...@debian.org
---
 Documentation/devicetree/bindings/hsi/omap_ssi.txt | 69 ++
 1 file changed, 69 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hsi/omap_ssi.txt

diff --git a/Documentation/devicetree/bindings/hsi/omap_ssi.txt 
b/Documentation/devicetree/bindings/hsi/omap_ssi.txt
new file mode 100644
index 000..0a9efd8
--- /dev/null
+++ b/Documentation/devicetree/bindings/hsi/omap_ssi.txt
@@ -0,0 +1,69 @@
+OMAP SSI controller bindings
+
+Required properties:
+- compatible:  Should include ti,omap3-ssi.
+- reg-names:   Contains the values sys and gdd.
+- reg: Contains a register specifier for each entry in
+   reg-names.
+- interrupt-names:  Contains the value gdd_mpu.
+- interrupts:  Contains interrupt information for each entry in
+   interrupt-names.
+- ranges   Represents the bus address mapping between the main
+   controller node and the child nodes below.
+- #address-cells   Should be set to 1
+- #size-cells  Should be set to 1
+
+Each port is represented as a sub-node of the ti,omap3-ssi device.
+
+Required Port sub-node properties:
+- compatible:  Should be set to the following value
+ti,omap3-ssi-port (applicable to OMAP34xx devices)
+- reg-names:   Contains the values rx and tx.
+- reg: Contains a register specifier for each entry in
+   reg-names.
+- interrupt-parent Should be a phandle for the interrupt controller
+- interrupt-names: Contains the values mpu_irq0 and mpu_irq1.
+- interrupts:  Contains interrupt information for each entry in
+   interrupt-names.
+- ti,ssi-cawake-gpio:  Defines which GPIO pin is used to signify CAWAKE
+   events for the port. This is an optional board-specific
+   property. If it's missing the port will not be
+   enabled.
+
+Example for Nokia N900:
+
+ssi-controller@48058000 {
+   compatible = ti,omap3-ssi;
+
+   /* needed until hwmod is updated to use the compatible string */
+   ti,hwmods = ssi;
+
+   reg = 0x48058000 0x1000,
+ 0x48059000 0x1000;
+   reg-names = sys,
+   gdd;
+
+   interrupts = 55;
+   interrupt-names = gdd_mpu;
+
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+
+   ssi-port@0 {
+   compatible = ti,omap3-ssi-port;
+
+   reg = 0x4805a000 0x800,
+ 0x4805a800 0x800;
+   reg-names = tx,
+   rx;
+
+   interrupt-parent = intc;
+   interrupts = 51,
+52;
+   interrupt-names = mpu_irq0,
+ mpu_irq1;
+
+   ti,ssi-cawake-gpio = gpio5 23 GPIO_ACTIVE_HIGH; /* 151 */
+   }
+}
-- 
1.8.5.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFCv4 11/11] DTS: ARM: OMAP3-N900: Add SSI protocol support

This adds support for the protocol used to communicate
with its cellular modem.

Signed-off-by: Sebastian Reichel s...@debian.org
---
 arch/arm/boot/dts/omap3-n900.dts | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index c557a77..576a95c 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -534,6 +534,7 @@
power = 50;
 };
 
+#include dt-bindings/hsi/hsi.h
 ssi_port1 {
pinctrl-names = default;
pinctrl-0 = ssi_pins;
@@ -543,6 +544,18 @@
ssi-char {
compatible = ssi-char;
};
+
+   ssi-protocol {
+   compatible = ssi-protocol;
+
+   hsi,mode = HSI_MODE_FRAME;
+   hsi,channels = 4;
+   hsi,speed = 55000;
+   hsi,flow = HSI_FLOW_SYNC;
+   hsi,arb_mode = HSI_ARB_RR;
+
+   nokia,cmt = cmt;
+   };
 };
 
 ssi_port2 {
-- 
1.8.5.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFCv4 09/11] DTS: ARM: OMAP3-N900: Add SSI support

Add SSI device tree data for OMAP3 and Nokia N900.

Signed-off-by: Sebastian Reichel s...@debian.org
---
 arch/arm/boot/dts/omap3-n900.dts | 28 
 arch/arm/boot/dts/omap3.dtsi | 47 
 2 files changed, 75 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 6fc85f9..52f5099 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -145,6 +145,19 @@
0x0d4 (PIN_OUTPUT | MUX_MODE4)  /* 
RX51_LCD_RESET_GPIO */
;
};
+
+   ssi_pins: pinmux_ssi {
+   pinctrl-single,pins = 
+   0x150 (PIN_INPUT_PULLUP | MUX_MODE1)/* ssi1_rdy_tx 
*/
+   0x14e (PIN_OUTPUT | MUX_MODE1)  /* ssi1_flag_tx 
*/
+   0x152 (PIN_INPUT | WAKEUP_EN | MUX_MODE4) /* 
ssi1_wake_tx (cawake) */
+   0x14c (PIN_OUTPUT | MUX_MODE1)  /* ssi1_dat_tx 
*/
+   0x154 (PIN_INPUT | MUX_MODE1)   /* ssi1_dat_rx 
*/
+   0x156 (PIN_INPUT | MUX_MODE1)   /* ssi1_flag_rx 
*/
+   0x158 (PIN_OUTPUT | MUX_MODE1)  /* ssi1_rdy_rx 
*/
+   0x15a (PIN_OUTPUT | MUX_MODE1)  /* ssi1_wake */
+   ;
+   };
 };
 
 i2c1 {
@@ -490,6 +503,21 @@
power = 50;
 };
 
+ssi_port1 {
+   pinctrl-names = default;
+   pinctrl-0 = ssi_pins;
+
+   ti,ssi-cawake-gpio = gpio5 23 GPIO_ACTIVE_HIGH; /* 151 */
+
+   ssi-char {
+   compatible = ssi-char;
+   };
+};
+
+ssi_port2 {
+   status = disabled;
+};
+
 uart1 {
status = disabled;
 };
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index daabf99..b7e485c 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -630,5 +630,52 @@
num-eps = 16;
ram-bits = 12;
};
+
+   ssi: ssi-controller@48058000 {
+   compatible = ti,omap3-ssi;
+   ti,hwmods = ssi;
+
+   reg = 0x48058000 0x1000,
+ 0x48059000 0x1000;
+   reg-names = sys,
+   gdd;
+
+   interrupts = 71;
+   interrupt-names = gdd_mpu;
+
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+
+   ssi_port1: ssi-port@0 {
+   compatible = ti,omap3-ssi-port;
+
+   reg = 0x4805a000 0x800,
+ 0x4805a800 0x800;
+   reg-names = tx,
+   rx;
+
+   interrupt-parent = intc;
+   interrupts = 67,
+68;
+   interrupt-names = mpu_irq0,
+ mpu_irq1;
+   };
+
+   ssi_port2: ssi-port@1 {
+   compatible = ti,omap3-ssi-port;
+
+   reg = 0x4805b000 0x800,
+ 0x4805b800 0x800;
+   reg-names = tx,
+   rx;
+
+   interrupt-parent = intc;
+   interrupts = 69,
+70;
+   interrupt-names = mpu_irq0,
+ mpu_irq1;
+   };
+   };
};
 };
-- 
1.8.5.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFCv4 07/11] Documentation: DT: nokia-cmt binding documentation

Create device tree binding documentation for
Nokia cellular modem GPIO handling.

Signed-off-by: Sebastian Reichel s...@debian.org
---
 .../devicetree/bindings/misc/nokia-cmt.txt | 28 ++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/misc/nokia-cmt.txt

diff --git a/Documentation/devicetree/bindings/misc/nokia-cmt.txt 
b/Documentation/devicetree/bindings/misc/nokia-cmt.txt
new file mode 100644
index 000..1c87793
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/nokia-cmt.txt
@@ -0,0 +1,28 @@
+Nokia Cellular Modem (CMT) bindings
+
+Required properties:
+- compatible:  Should include nokia,cmt.
+- interrupts:  Interrupt specifier for the cmt reset irq.
+- gpio-names:  Contains the values cmt_apeslpx, cmt_rst_rq,
+   cmt_en, cmt_rst and cmt_bsi.
+- gpios:   Contains gpio information for each entry in gpio-names.
+
+Example for Nokia N900:
+
+cmt: nokia-cmt {
+   compatible = nokia,cmt;
+
+   interrupt-parent = gpio3;
+   interrupts = 8 IRQ_TYPE_EDGE_FALLING; /* gpio line 72 */
+
+   gpios = gpio3  6 GPIO_ACTIVE_HIGH, /* 70 */
+   gpio3  9 GPIO_ACTIVE_HIGH, /* 73 */
+   gpio3 10 GPIO_ACTIVE_HIGH, /* 74 */
+   gpio3 11 GPIO_ACTIVE_HIGH, /* 75 */
+   gpio5 29 GPIO_ACTIVE_HIGH; /* 157 */
+   gpio-names = cmt_apeslpx,
+cmt_rst_rq,
+cmt_en,
+cmt_rst,
+cmt_bsi;
+};
-- 
1.8.5.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFCv4 10/11] DTS: ARM: OMAP3-N900: Add CMT support

This adds support for the Nokia N900 cellular modem.

Signed-off-by: Sebastian Reichel s...@debian.org
---
 arch/arm/boot/dts/omap3-n900.dts | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 52f5099..c557a77 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -74,6 +74,26 @@
};
};
 
+   cmt: nokia-cmt {
+   compatible = nokia,cmt;
+
+   pinctrl-names = default;
+   pinctrl-0 = cmt_pins;
+
+   interrupt-parent = gpio3;
+   interrupts = 8 IRQ_TYPE_EDGE_FALLING; /* gpio line 72 */
+
+   gpios = gpio3  6 GPIO_ACTIVE_HIGH, /* 70 */
+   gpio3  9 GPIO_ACTIVE_HIGH, /* 73 */
+   gpio3 10 GPIO_ACTIVE_HIGH, /* 74 */
+   gpio3 11 GPIO_ACTIVE_HIGH, /* 75 */
+   gpio5 29 GPIO_ACTIVE_HIGH; /* 157 */
+   gpio-names = cmt_apeslpx,
+cmt_rst_rq,
+cmt_en,
+cmt_rst,
+cmt_bsi;
+   };
 };
 
 omap3_pmx_core {
@@ -158,6 +178,17 @@
0x15a (PIN_OUTPUT | MUX_MODE1)  /* ssi1_wake */
;
};
+
+   cmt_pins: pinmux_cmt {
+   pinctrl-single,pins = 
+   0x0ac (PIN_OUTPUT | MUX_MODE4)  /* gpio 70 = 
cmt_apeslpx */
+   0x0b0 (PIN_INPUT | WAKEUP_EN | MUX_MODE4) /* gpio 72 = 
ape_rst_rq */
+   0x0b2 (PIN_OUTPUT | MUX_MODE4)  /* gpio 73 = 
cmt_rst_rq */
+   0x0b4 (PIN_OUTPUT | MUX_MODE4)  /* gpio 74 = 
cmt_en */
+   0x0b6 (PIN_OUTPUT | MUX_MODE4)  /* gpio 75 = 
cmt_rst */
+   0x15e (PIN_OUTPUT | MUX_MODE4)  /* gpio 157 = 
cmt_bsi */
+   ;
+   };
 };
 
 i2c1 {
-- 
1.8.5.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFCv4 06/11] misc: Introduce Nokia CMT driver

Add driver handling GPIO pins of Nokia modems. The
driver provides reset notifications, so that SSI
clients can subscribe to them easily.

Signed-off-by: Sebastian Reichel s...@debian.org
---
 drivers/misc/Kconfig  |   7 ++
 drivers/misc/Makefile |   1 +
 drivers/misc/nokia-cmt.c  | 298 ++
 include/linux/nokia-cmt.h |  46 +++
 4 files changed, 352 insertions(+)
 create mode 100644 drivers/misc/nokia-cmt.c
 create mode 100644 include/linux/nokia-cmt.h

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index a3e291d..74e96cc 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -515,6 +515,13 @@ config SRAM
  the genalloc API. It is supposed to be used for small on-chip SRAM
  areas found on many SoCs.
 
+config NOKIA_CMT
+   tristate Enable CMT support
+   help
+   If you say Y here, you will enable CMT support.
+
+   If unsure, say Y, or else you will not be able to use the CMT.
+
 source drivers/misc/c2port/Kconfig
 source drivers/misc/eeprom/Kconfig
 source drivers/misc/cb710/Kconfig
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index f45473e..b109e84 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -53,3 +53,4 @@ obj-$(CONFIG_VMWARE_VMCI) += vmw_vmci/
 obj-$(CONFIG_LATTICE_ECP3_CONFIG)  += lattice-ecp3-config.o
 obj-$(CONFIG_SRAM) += sram.o
 obj-y  += mic/
+obj-$(CONFIG_NOKIA_CMT)+= nokia-cmt.o
diff --git a/drivers/misc/nokia-cmt.c b/drivers/misc/nokia-cmt.c
new file mode 100644
index 000..9c40cf6
--- /dev/null
+++ b/drivers/misc/nokia-cmt.c
@@ -0,0 +1,298 @@
+/*
+ * CMT support.
+ *
+ * Copyright (C) 2009 Nokia Corporation. All rights reserved.
+ * Copyright (C) 2013 Sebastian Reichel s...@kernel.org
+ *
+ * Contact: Carlos Chinea carlos.chi...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * 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.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include asm/atomic.h
+#include linux/nokia-cmt.h
+#include linux/err.h
+#include linux/gpio.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/list.h
+#include linux/module.h
+#include linux/notifier.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/string.h
+#include linux/of.h
+#include linux/of_gpio.h
+
+/**
+ * struct cmt_gpio - GPIO with name
+ * @gpio: GPIO number
+ * @name: name for the GPIO
+ */
+struct cmt_gpio {
+   int gpio;
+   const char  *name;
+};
+
+/**
+ * struct cmt_device - CMT device data
+ * @cmt_rst_ind_tasklet: Bottom half for CMT reset line events
+ * @cmt_rst_ind_irq: IRQ number of the CMT reset line
+ * @n_head: List of notifiers registered to get CMT events
+ * @node: Link on the list of available CMTs
+ * @device: Reference to the CMT platform device
+ */
+struct cmt_device {
+   struct tasklet_struct   cmt_rst_ind_tasklet;
+   unsigned intcmt_rst_ind_irq;
+   struct atomic_notifier_head n_head;
+   struct list_headnode;
+   struct device   *device;
+   struct cmt_gpio *gpios;
+   int gpio_amount;
+};
+
+static LIST_HEAD(cmt_list);/* List of CMT devices */
+
+int cmt_notifier_register(struct cmt_device *cmtdev, struct notifier_block *nb)
+{
+   struct cmt_device *cmt;
+   int err = -ENODEV;
+
+   if ((!cmtdev) || (!nb))
+   return -EINVAL;
+
+   list_for_each_entry(cmt, cmt_list, node)
+   if (cmt == cmtdev) {
+   err = atomic_notifier_chain_register(cmt-n_head, nb);
+   break;
+   }
+
+   return err;
+}
+EXPORT_SYMBOL_GPL(cmt_notifier_register);
+
+int cmt_notifier_unregister(struct cmt_device *cmtdev,
+   struct notifier_block *nb)
+{
+   struct cmt_device *cmt;
+   int err = -ENODEV;
+
+   if ((!cmtdev) || (!nb))
+   return -EINVAL;
+
+   list_for_each_entry(cmt, cmt_list, node)
+   if (cmt == cmtdev) {
+   err = atomic_notifier_chain_unregister(cmt-n_head,
+   nb);
+   break;
+   }
+
+   return err

[RFCv4 08/11] HSI: Introduce driver for SSI Protocol

This adds a driver for the SSI McSAAB protocol as used in
the Nokia N900.

Signed-off-by: Sebastian Reichel s...@debian.org
---
 drivers/hsi/clients/Kconfig|8 +
 drivers/hsi/clients/Makefile   |3 +-
 drivers/hsi/clients/ssi_protocol.c | 1201 
 include/linux/hsi/ssi_protocol.h   |   41 ++
 4 files changed, 1252 insertions(+), 1 deletion(-)
 create mode 100644 drivers/hsi/clients/ssi_protocol.c
 create mode 100644 include/linux/hsi/ssi_protocol.h

diff --git a/drivers/hsi/clients/Kconfig b/drivers/hsi/clients/Kconfig
index 3bacd27..7103ffc 100644
--- a/drivers/hsi/clients/Kconfig
+++ b/drivers/hsi/clients/Kconfig
@@ -4,6 +4,14 @@
 
 comment HSI clients
 
+config SSI_PROTOCOL
+   tristate SSI protocol
+   depends on HSI  OMAP_SSI  NOKIA_CMT  PHONET
+   help
+   If you say Y here, you will enable the SSI protocol aka McSAAB.
+
+   If unsure, say N.
+
 config HSI_CHAR
tristate HSI/SSI character driver
depends on HSI
diff --git a/drivers/hsi/clients/Makefile b/drivers/hsi/clients/Makefile
index 327c0e2..ccbf768 100644
--- a/drivers/hsi/clients/Makefile
+++ b/drivers/hsi/clients/Makefile
@@ -2,4 +2,5 @@
 # Makefile for HSI clients
 #
 
-obj-$(CONFIG_HSI_CHAR) += hsi_char.o
+obj-$(CONFIG_SSI_PROTOCOL) += ssi_protocol.o
+obj-$(CONFIG_HSI_CHAR) += hsi_char.o
diff --git a/drivers/hsi/clients/ssi_protocol.c 
b/drivers/hsi/clients/ssi_protocol.c
new file mode 100644
index 000..5b23ab8
--- /dev/null
+++ b/drivers/hsi/clients/ssi_protocol.c
@@ -0,0 +1,1201 @@
+/*
+ * ssi_protocol.c
+ *
+ * Implementation of the SSI McSAAB improved protocol.
+ *
+ * Copyright (C) 2010 Nokia Corporation. All rights reserved.
+ * Copyright (C) 2013 Sebastian Reichel s...@kernel.org
+ *
+ * Contact: Carlos Chinea carlos.chi...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * 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.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include asm/atomic.h
+#include linux/clk.h
+#include linux/nokia-cmt.h
+#include linux/device.h
+#include linux/err.h
+#include linux/gpio.h
+#include linux/if_ether.h
+#include linux/if_arp.h
+#include linux/if_phonet.h
+#include linux/init.h
+#include linux/irq.h
+#include linux/list.h
+#include linux/module.h
+#include linux/netdevice.h
+#include linux/notifier.h
+#include linux/scatterlist.h
+#include linux/skbuff.h
+#include linux/slab.h
+#include linux/spinlock.h
+#include linux/timer.h
+#include linux/hsi/hsi.h
+#include linux/hsi/ssi_protocol.h
+#include linux/of_device.h
+
+void ssi_waketest(struct hsi_client *cl, unsigned int enable);
+
+#define SSIP_TXQUEUE_LEN   100
+#define SSIP_MAX_MTU   65535
+#define SSIP_DEFAULT_MTU   4000
+#define PN_MEDIA_SOS   21
+#define SSIP_MIN_PN_HDR6   /* FIXME: Revisit */
+#define SSIP_WDTOUT2000/* FIXME: has to be 500 msecs */
+#define SSIP_KATOUT15  /* 15 msecs */
+#define SSIP_MAX_CMDS  5 /* Number of pre-allocated commands buffers */
+#define SSIP_BYTES_TO_FRAMES(x) x) - 1)  2) + 1)
+#define SSIP_CMT_LOADER_SYNC   0x11223344
+/*
+ * SSI protocol command definitions
+ */
+#define SSIP_COMMAND(data) ((data)  28)
+#define SSIP_PAYLOAD(data) ((data)  0xfff)
+/* Commands */
+#define SSIP_SW_BREAK  0
+#define SSIP_BOOTINFO_REQ  1
+#define SSIP_BOOTINFO_RESP 2
+#define SSIP_WAKETEST_RESULT   3
+#define SSIP_START_TRANS   4
+#define SSIP_READY 5
+/* Payloads */
+#define SSIP_DATA_VERSION(data)((data)  0xff)
+#define SSIP_LOCAL_VERID   1
+#define SSIP_WAKETEST_OK   0
+#define SSIP_WAKETEST_FAILED   1
+#define SSIP_PDU_LENGTH(data)  (((data)  8)  0x)
+#define SSIP_MSG_ID(data)  ((data)  0xff)
+/* Generic Command */
+#define SSIP_CMD(cmd, payload) (((cmd)  28) | ((payload)  0xfff))
+/* Commands for the control channel */
+#define SSIP_BOOTINFO_REQ_CMD(ver) \
+   SSIP_CMD(SSIP_BOOTINFO_REQ, SSIP_DATA_VERSION(ver))
+#define SSIP_BOOTINFO_RESP_CMD(ver) \
+   SSIP_CMD(SSIP_BOOTINFO_RESP, SSIP_DATA_VERSION(ver))
+#define SSIP_START_TRANS_CMD(pdulen, id) \
+   SSIP_CMD(SSIP_START_TRANS, (((pdulen)  8) | SSIP_MSG_ID(id)))
+#define SSIP_READY_CMD SSIP_CMD(SSIP_READY, 0)
+#define SSIP_SWBREAK_CMD   SSIP_CMD(SSIP_SW_BREAK, 0)
+
+/* Main state machine states */
+enum {
+   INIT,
+   HANDSHAKE

[RFCv4 03/11] HSI: hsi-char: fix driver for multiport scenarios

Fix return code check of alloc_chrdev_region, which
returns 0 on success.

Signed-off-by: Sebastian Reichel s...@debian.org
---
 drivers/hsi/clients/hsi_char.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hsi/clients/hsi_char.c b/drivers/hsi/clients/hsi_char.c
index 7f64bed..f51cf45 100644
--- a/drivers/hsi/clients/hsi_char.c
+++ b/drivers/hsi/clients/hsi_char.c
@@ -706,7 +706,7 @@ static int hsc_probe(struct device *dev)
if (!hsc_major) {
ret = alloc_chrdev_region(hsc_dev, hsc_baseminor,
HSC_DEVS, devname);
-   if (ret  0)
+   if (ret == 0)
hsc_major = MAJOR(hsc_dev);
} else {
hsc_dev = MKDEV(hsc_major, hsc_baseminor);
-- 
1.8.5.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFCv4 01/11] HSI: method to unregister clients from an hsi port

This exports a method to unregister all clients from
an hsi port.

Signed-off-by: Sebastian Reichel s...@debian.org
---
 drivers/hsi/hsi.c   | 10 ++
 include/linux/hsi/hsi.h |  1 +
 2 files changed, 11 insertions(+)

diff --git a/drivers/hsi/hsi.c b/drivers/hsi/hsi.c
index 8bbc0f1..c7b842b 100644
--- a/drivers/hsi/hsi.c
+++ b/drivers/hsi/hsi.c
@@ -198,6 +198,16 @@ static void hsi_port_release(struct device *dev)
 }
 
 /**
+ * hsi_unregister_port - Unregister an HSI port
+ * @port: The HSI port to unregister
+ */
+void hsi_port_unregister_clients(struct hsi_port *port)
+{
+   device_for_each_child(port-device, NULL, hsi_remove_client);
+}
+EXPORT_SYMBOL_GPL(hsi_port_unregister_clients);
+
+/**
  * hsi_unregister_controller - Unregister an HSI controller
  * @hsi: The HSI controller to register
  */
diff --git a/include/linux/hsi/hsi.h b/include/linux/hsi/hsi.h
index fb07339..89cc6f2 100644
--- a/include/linux/hsi/hsi.h
+++ b/include/linux/hsi/hsi.h
@@ -284,6 +284,7 @@ int hsi_register_controller(struct hsi_controller *hsi);
 void hsi_unregister_controller(struct hsi_controller *hsi);
 void hsi_add_clients_from_dt(struct hsi_port *port,
struct device_node *clients);
+void hsi_port_unregister_clients(struct hsi_port *port);
 
 static inline void hsi_controller_set_drvdata(struct hsi_controller *hsi,
void *data)
-- 
1.8.5.1

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFCv4 00/11] OMAP SSI driver / N900 modem support

Hi,

This is the fourth round of the OMAP SSI driver patches.

I added some more patches on top of the actual OMAP SSI driver, so that one can
get the overall picture of the planned architecture. This patchset contains
everything, that is needed to get the N900's modem running (without audio
support, which requires another hsi client driver).

After applying the patches one can use ofono with the N900's modem.
This is what I did to test the modem:

 # get ofono and mdbus2 to send some dbus commands
 apt-get install ofono mdbus2
 # ofono assumes, that gpios are available in /dev/cmt. Previously
 # a init script exported the gpios and symlinked them to this
 # directory. I added support for the gpio export directly into
 # nokia-cmt and I plan to write a patch for ofono to check for
 # the cmt gpios directly in /sys. For now this hack can be used
 # to test the modem.
 ln -sf /sys/devices/nokia-cmt.5 /dev/cmt
 # start ofono in debug mode
 export OFONO_ISI_DEBUG
 export OFONO_AT_DEBUG=1
 ofono --nodetach --debug
 # enable the modem
 mdbus2 -s org.ofono /n900_0 org.ofono.Modem.SetProperty Powered true
 # enable modem's RF parts
 mdbus2 -s org.ofono /n900_0 org.ofono.Modem.SetProperty Online true
 # scan for available networks
 mdbus2 -s org.ofono /n900_0 org.ofono.NetworkRegistration.Scan

Changes since RFCv3 [0]:
* Added new patches for nokia-cmt driver
* Added new patches for ssi protocol driver
* Removal of ti,hwmods description from DT Documentation
* Removed the hwmod patch, since it has already been applied
* Misc. bug fixes

TODO (short-term):
* Find a DT maintainer, who has time to review the updated DT bindings
* Push nokia-cmt driver through gregkh's linux-misc queue
* Push hsi/ssi drivers through my new linux-hsi queue [1]
* Push DTS patches through benoits queue once the other patches are queued

TODO (long-term):
* Central Message Queue
  I did not yet implement a central message queue in the HSI framework.
  I will do this after Nokia N900 modem is working in the mainline kernel.
* Get clock data from DT
  This depends on a patchset, which is not yet part of any kernel tree.
  Apart from that I don't know which clocks will be needed. That depends
  on the implementation of the hwmod DTification (see next point)
* Remove the hwmod DT hack
  This depends on some future work merging hwmod data into DT.

[0] https://lkml.org/lkml/2013/10/6/127
[1] https://git.kernel.org/cgit/linux/kernel/git/sre/linux-hsi.git/

-- Sebastian

Sebastian Reichel (11):
  HSI: method to unregister clients from an hsi port
  HSI: hsi-char: add Device Tree support
  HSI: hsi-char: fix driver for multiport scenarios
  ARM: OMAP2+: HSI: Introduce OMAP SSI driver
  Documentation: DT: omap-ssi binding documentation
  misc: Introduce Nokia CMT driver
  Documentation: DT: nokia-cmt binding documentation
  HSI: Introduce driver for SSI Protocol
  DTS: ARM: OMAP3-N900: Add SSI support
  DTS: ARM: OMAP3-N900: Add CMT support
  DTS: ARM: OMAP3-N900: Add SSI protocol support

 Documentation/devicetree/bindings/hsi/omap_ssi.txt |   69 +
 .../devicetree/bindings/misc/nokia-cmt.txt |   28 +
 arch/arm/boot/dts/omap3-n900.dts   |   72 +
 arch/arm/boot/dts/omap3.dtsi   |   47 +
 drivers/hsi/Kconfig|1 +
 drivers/hsi/Makefile   |1 +
 drivers/hsi/clients/Kconfig|8 +
 drivers/hsi/clients/Makefile   |3 +-
 drivers/hsi/clients/hsi_char.c |   13 +-
 drivers/hsi/clients/ssi_protocol.c | 1201 +
 drivers/hsi/controllers/Kconfig|   19 +
 drivers/hsi/controllers/Makefile   |6 +
 drivers/hsi/controllers/omap_ssi.c |  619 +
 drivers/hsi/controllers/omap_ssi.h |  166 +++
 drivers/hsi/controllers/omap_ssi_port.c| 1401 
 drivers/hsi/controllers/omap_ssi_regs.h|  171 +++
 drivers/hsi/hsi.c  |   10 +
 drivers/misc/Kconfig   |7 +
 drivers/misc/Makefile  |1 +
 drivers/misc/nokia-cmt.c   |  298 +
 include/linux/hsi/hsi.h|1 +
 include/linux/hsi/ssi_protocol.h   |   41 +
 include/linux/nokia-cmt.h  |   46 +
 23 files changed, 4227 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/hsi/omap_ssi.txt
 create mode 100644 Documentation/devicetree/bindings/misc/nokia-cmt.txt
 create mode 100644 drivers/hsi/clients/ssi_protocol.c
 create mode 100644 drivers/hsi/controllers/Kconfig
 create mode 100644 drivers/hsi/controllers/Makefile
 create mode 100644 drivers/hsi/controllers/omap_ssi.c
 create mode 100644 drivers/hsi/controllers/omap_ssi.h
 create mode 100644 drivers/hsi/controllers/omap_ssi_port.c
 create mode

Re: [RFCv4 06/11] misc: Introduce Nokia CMT driver

2013-12-16 Thread Sebastian Reichel

Hi Linus,

On Mon, Dec 16, 2013 at 10:48:06AM +0100, Linus Walleij wrote:
 On Mon, Dec 16, 2013 at 12:27 AM, Sebastian Reichel s...@debian.org wrote:
  Add driver handling GPIO pins of Nokia modems. The
  driver provides reset notifications, so that SSI
  clients can subscribe to them easily.
 
  Signed-off-by: Sebastian Reichel s...@debian.org
 
 If the driver provides reset notifications, should it rather be
 in drivers/reset?
 
 I'm thinking of a generic GPIO reset driver with a generic
 notification mechanism, which seems to be what this is.
 
 I.e. it doesn't look device-specific at all, just like some
 generic glue code that could be useful to many such
 scenarios.

I like the idea.

Probably the remaining gpio exporting code can be converted into
some generic gpio-sysfs-export driver as well.

What do you think about the following?

/*
 * driver, which provides generic reset notifications
 */
cmt_reset: reset-notifier {
compatible = linux,reset-notification;

interrupts = gpio;
};

/*
 * driver, which exports the specified gpios in sysfs with the
 * supplied names. The device will be named according to the
 * label
 */
cmt_gpios: gpio-sysfs-export {
compatible = linux,gpio-sysfs-export;
label = nokia-cmt;

gpios = A, B, ...;
gpio-names = A, B, ...;
};

  +config NOKIA_CMT
  +   tristate Enable CMT support
  +   help
  +   If you say Y here, you will enable CMT support.
  +
  +   If unsure, say Y, or else you will not be able to use the CMT.
 
 None of this explains what this driver actually does and what
 CMT means, so please rewrite this a bit to be more helpful.
 The way it is written it could as well say enable FOO support.

I probably should have reviewed this better. This is the original
text from Nokia's driver.

  +++ b/drivers/misc/nokia-cmt.c
  @@ -0,0 +1,298 @@
  +/*
  + * CMT support.
 
 So CMT = ...?

CMT = Cellular Modem

  +/**
  + * struct cmt_device - CMT device data
  + * @cmt_rst_ind_tasklet: Bottom half for CMT reset line events
  + * @cmt_rst_ind_irq: IRQ number of the CMT reset line
  + * @n_head: List of notifiers registered to get CMT events
  + * @node: Link on the list of available CMTs
  + * @device: Reference to the CMT platform device
  + */
  +struct cmt_device {
  +   struct tasklet_struct   cmt_rst_ind_tasklet;
  +   unsigned intcmt_rst_ind_irq;
  +   struct atomic_notifier_head n_head;
  +   struct list_headnode;
  +   struct device   *device;
  +   struct cmt_gpio *gpios;
  +   int gpio_amount;
  +};
 
 The kerneldoc and and the struct are not in sync. Look
 this over.

I will fix this in v5 (in case that its not removed completly).

  +static LIST_HEAD(cmt_list);/* List of CMT devices */
 (...)
  +struct cmt_device *cmt_get(const char *name)
  +{
  +   struct cmt_device *p, *cmt = ERR_PTR(-ENODEV);
  +
  +   list_for_each_entry(p, cmt_list, node)
  +   if (strcmp(name, dev_name(p-device)) == 0) {
  +   cmt = p;
  +   break;
  +   }
  +
  +   return cmt;
  +}
  +EXPORT_SYMBOL_GPL(cmt_get);
 
 Is this driver used on non-DT platforms, or can we skip this
 struct device * referencing altogether?

 I would feel better if this driver looked more like
 drivers/mfd/syscon.c

Will be removed in v5.

  +static irqreturn_t cmt_rst_ind_isr(int irq, void *cmtdev)
  +{
  +   struct cmt_device *cmt = (struct cmt_device *)cmtdev;
  +
  +   tasklet_schedule(cmt-cmt_rst_ind_tasklet);
  +
  +   return IRQ_HANDLED;
  +}
 
 Why are you using a tasklet rather than a work
 for this?

No particular reason. I just took this over from Nokia's code.

-- Sebastian


signature.asc
Description: Digital signature

Re: [RFCv4 06/11] misc: Introduce Nokia CMT driver

2013-12-16 Thread Sebastian Reichel

Hi,

On Mon, Dec 16, 2013 at 02:31:53PM +0100, Linus Walleij wrote:
 I am very reluctant in letting device trees specify exports of GPIOs
 to userspace, not so much because it's Linux-specific but for
 the fact that people are doing things in userspace that should not
 be done in userspace.
 
 Last time it was proposed I asked to the specific usecase,
 exactly why userspace needed this handle on a physical
 GPIO line, and why it can't use another userspace interface
 (example: leds, keys etc.)

There are a couple of lines (cmt_apeslpx, cmt_rst_rq, cmt_en,
cmt_rst, cmt_bsi), which are handled by ofono to do the correct
power sequence for the modem. The relevant ofono code is here:

https://git.kernel.org/cgit/network/ofono/ofono.git/tree/plugins/nokia-gpio.c

In MeeGo etc. they have a little board specific init script, which
exports the gpio lines and setups some symlinks. IMHO at least the
board specific stuff should be handled by the kernel, thus I added
this code to the driver. I guess you prefer to move the power
sequencing completly to the kernel?

  What do you think about the following?
 
  /*
   * driver, which provides generic reset notifications
   */
  cmt_reset: reset-notifier {
  compatible = linux,reset-notification;
 
  interrupts = gpio;
  };
 
 Looks good to me.

Ok :) I will prepare something for the next patch.

  /*
   * driver, which exports the specified gpios in sysfs with the
   * supplied names. The device will be named according to the
   * label
   */
  cmt_gpios: gpio-sysfs-export {
  compatible = linux,gpio-sysfs-export;
  label = nokia-cmt;
 
  gpios = A, B, ...;
  gpio-names = A, B, ...;
  };
 
 Please follow the discussion on this topic:
 http://marc.info/?l=linux-gpiom=138201170431416w=2

Ok.

  Why are you using a tasklet rather than a work
  for this?
 
  No particular reason. I just took this over from Nokia's code.
 
 Can you try to use a work instead?

Yes. I will have a look at this.

-- Sebastian


signature.asc
Description: Digital signature

Re: Re: [RFCv4 06/11] misc: Introduce Nokia CMT driver

2013-12-17 Thread Sebastian Reichel

On Tue, Dec 17, 2013 at 07:58:56PM +0200, Ivajlo Dimitrov wrote:
 On Mon, Dec 16, 2013 at 02:31:53PM +0100, Linus Walleij wrote:
 I am very reluctant in letting device trees specify exports of GPIOs
 to userspace, not so much because it's Linux-specific but for
 the fact that people are doing things in userspace that should not
 be done in userspace.
 
 Last time it was proposed I asked to the specific usecase,
 exactly why userspace needed this handle on a physical
 GPIO line, and why it can't use another userspace interface
 (example: leds, keys etc.)
 There are a couple of lines (cmt_apeslpx, cmt_rst_rq, cmt_en,
 cmt_rst, cmt_bsi), which are handled by ofono to do the correct
 power sequence for the modem. The relevant ofono code is here:
 
 https://git.kernel.org/cgit/network/ofono/ofono.git/tree/plugins/nokia-gpio.c
 
 In MeeGo etc. they have a little board specific init script, which
 exports the gpio lines and setups some symlinks. IMHO at least the
 board specific stuff should be handled by the kernel, thus I added
 this code to the driver. I guess you prefer to move the power
 sequencing completly to the kernel?
 
 Don't forget there is not only ofono, but rtcom-call-ui and all the
 telephony stack in Maemo 5 :). However, power sequencing and control
 is specific not only to the modem model, but to the firmware version
 the modem is running as well (afaik). IMO you can't simply move the
 modem power/reset/sleep control to the kernel and hope for the best,
 I am not sure there is enough documentation (if any) for this to be
 done reliably, esp on n900 with its BB5 modem. The point is that
 those gpios are used not only for the initial power-up, but for
 control of the modem state and reset (if needed) during normal
 usage. The APE reset line is an example of stuff that can't be moved
 to the kernel without providing some interface/feedback to/from the
 userspace IMO - what if she is dialing 112 at the moment the modem
 decides it is too hot and wants a device reset (or whatever reason
 there could be for a modem to request a device reset)? The same goes
 for the APE sleep request line (cmt_apeslpx) - based on what should
 the kernel decide whether to put the modem in sleep?
 
 Sure, exporting gpios to userspace might not be the best way to
 achieve the required functionality, but every way could be argued if
 it is the best. And for sure labeling a modem LED won't make it
 such.

Yes, but as far as I know the kernel design rules are not bended for
nonfree userspace components. Using the nonfree Maemo stuff should
be supported by disabling the CMT driver and exporting the pins from
userspace using some board specific init script (= this is how its
done until now).

I had a look at both ofono's and freesmartphone.org's implementation
for the GPIO handling and both implementations are very similar. I
think it should be possible to move the state machine described in
[0] into the kernel and provide a simple sysfs/uevent interface.

I was thinking of something like /sys/devices/platform/nokia-cmt/state,
which accepts enable, disable and reset as input and outputs the
current state.

[0] 
https://git.kernel.org/cgit/network/ofono/ofono.git/tree/plugins/nokia-gpio.c

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v2] Bluetooth: Add hci_h4p driver

2013-12-30 Thread Sebastian Reichel

Hi,

On Mon, Dec 30, 2013 at 01:13:50PM +0100, Pavel Machek wrote:
 [...]

 Well, I can rename config option, but renaming the module would break
 existing userland, no?

Why is the userland depending on the module name?

   Can we also make this just depend on some device tree information
  and not on a specific architecture. I know that this driver is
  pretty much OMAP specific, but if we want this upstream, we should
  at least try to make it more generic.
 
 Nokia N900 is certainly moving towards device tree, but we are not
 ready, yet...

Tony plans to remove OMAP3 boardcode (incl. omap3-rx51) in 3.14.

   [...]
  
  Please do not introduce public includes for a driver. This
  should be all confined to the driver itself or if it platform
  data, it should go into the place for platform data.
 
 (Could you insert newlines after 80 or so characters?)
 
 Where would you like platform_data definition to go? That indeed is
 for platform data, and quick grep shows drivers normally do public
 header files for that.

Probably it can simply be removed, because it's not useful in 3.14?

 [...]

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v2] Bluetooth: Add hci_h4p driver

2013-12-30 Thread Sebastian Reichel

Hi,

On Mon, Dec 30, 2013 at 03:31:25PM +0100, Pali Rohár wrote:
[...] I think that correct commit message is not needed now.

Please add patch descriptions as early as possible. Patches without
descriptions are anoying for misc. reasons. It's not too much work
to do and helps everyone to understand what's going on. Especially
if the patch gets forgotten for some reason and somebody wants to
pick it up at a later time.

Wolfram Sang gave a talk about that at 30C3 yesterday. Official
recordings of his talk are not yet ready, but the live stream
has been recorded and uploaded to youtube:

http://www.youtube.com/watch?v=DjI7IFbvU0s (starting at 14:30)

diff --git a/drivers/bluetooth/Kconfig
b/drivers/bluetooth/Kconfig index 11a6104..95155c3 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -242,4 +242,14 @@ config BT_WILINK

Say Y here to compile support for Texas Instrument's
WiLink7 driver into the kernel or say M to compile it as
module.

+
+config BT_HCIH4P
+ tristate HCI driver with H4 Nokia extensions
+ depends on BT ARCH_OMAP

Since then we moved away from doing hci_* prefix of drivers
since that is misleading. See btusb.ko, btmrvl_sdio.ko etc.

So this might be better named BT_NOK_H4P or BT_NOKIA_H4P and
the module named btnok_h4p.ko or btnokia_h4p.ko.

I still never understood what “p” was for.

I do not know too, I did not invent that name. I just copied
kernel driver from nokia kernel and patched it to work with 3.12.

Maybe 'p' means plus (+) as H4+.

AFAIR there is a H4+ reference in the code, so I also guess H4P =
H4+. Apart from that I assume, that it's meant as a short for H4
plus some extensions

Can we also make this just depend on some device tree
information and not on a specific architecture. I know that
this driver is pretty much OMAP specific, but if we want this
upstream, we should at least try to make it more generic.

Sebastian, can you look at code how hard is to add DT support?

I already have it on my TODO list.

+MODULE_DESCRIPTION(Bluetooth h4 driver with nokia
extensions); +MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Ville Tervo);
+MODULE_FIRMWARE(FW_NAME_TI1271_PRELE);
+MODULE_FIRMWARE(FW_NAME_TI1271_LE);
+MODULE_FIRMWARE(FW_NAME_TI1271);
+MODULE_FIRMWARE(FW_NAME_BCM2048);
+MODULE_FIRMWARE(FW_NAME_CSR);

Do we actually have all these firmware files still available.
If not, then focus on the ones we have.

Firmware files are available for download from nemo project:

https://api.merproject.org/public/source/nemo:devel:hw:ti:omap3:n900/bcm-bt-firmware/bcm-bt-firmware-0.21rc3.tar.bz2
https://api.merproject.org/public/source/nemo:devel:hw:ti:omap3:n950-n9/ti-wl1273-bt-firmware/bt-firmware-ti1273_0.23+0m6.tar.gz

Would be nice to have them added to the linux-firmware.git.

-- Sebastian

signature.asc
Description: Digital signature

Re: [PATCH v2] Bluetooth: Add hci_h4p driver

2013-12-30 Thread Sebastian Reichel

Hi again,

On Mon, Dec 30, 2013 at 03:52:51PM +0100, Sebastian Reichel wrote:
 On Mon, Dec 30, 2013 at 03:31:25PM +0100, Pali Rohár wrote:
  [...] I think that correct commit message is not needed now.

 Wolfram Sang gave a talk about that at 30C3 yesterday. Official
 recordings of his talk are not yet ready, but the live stream
 has been recorded and uploaded to youtube: [...]

The official recording is now available from here:

http://media.ccc.de/browse/congress/2013/30C3_-_5446_-_en_-_saal_g_-_201312282200_-_the_good_the_bad_and_the_ugly_-_linux_kernel_patches_-_wsa.html

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH 3/7] iommu/omap: Convert to devicetree

2014-01-01 Thread Sebastian Reichel

Hi,

On Thu, Jan 02, 2014 at 01:13:42AM +0100, Laurent Pinchart wrote:
  +   .of_match_table = omap_iommu_of_match,
 
 If CONFIG_OF isn't defined (pretty unlikely I agree, but a possibility you 
 seem to be prepared for nonetheless given the above #if), this will fail to 
 compile.

FYI: This is avoided in other drivers by using
of_match_ptr(omap_iommu_of_match), which is replaced with NULL by
the preprocessor if CONFIG_OF is not defined.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v4] Bluetooth: Add hci_h4p driver

2014-01-02 Thread Sebastian Reichel

Hi,

On Fri, Jan 03, 2014 at 01:17:54AM +0100, Pavel Machek wrote:
 Changes from v3: Moved platform data into
 include/linux/platform_data/, something I missed before.

As I wrote before Tony plans to remove the boardcode for all
OMAP boards including the Nokia N900 for 3.14, so you cannot
boot without DT from 3.14 onwards.

The drivers can still be initialized the old way using pdata quirks
until all drivers are converted, but I think this driver can simply
be prepared for DT directly:

 [...]

 +struct hci_h4p_platform_data {
 + int chip_type;

This can be extracted from the compatible string.

 + int bt_sysclk;

This can be converted into a vendor property.

 + unsigned int bt_wakeup_gpio;
 + unsigned int host_wakeup_gpio;
 + unsigned int reset_gpio;

These can easily be acquired via DT.

 + int reset_gpio_shared;

This looks like a simple property in the DT structure.

You should use a boolean type for this btw.

 + unsigned int uart_irq;

This one can also simply be aquired via DT.

 + phys_addr_t uart_base;

I see multiple ways for this one:

 1. Just put the memory address into the dts file.
 2. Make this a phandle to the UART node and get
the memory address from the referenced node.
 3. Make the bluetooth node a subnode of the UART
node and get the address from the parent node.

IMHO solution 3 is the best solution, since the bluetooth
chip is basically connected to the system via the UART.

 + const char *uart_iclk;
 + const char *uart_fclk;

There is currently work going on to move OMAP's clock
data into DT. When that work is done the clocks can
be acquired via phandles. I think it's expected to
be merged into 3.14.

 + void (*set_pm_limits)(struct device *dev, bool set);

If I'm not mistaken set_pm_limits is only referenced by
hci_h4p_set_pm_limits(). The hci_h4p_set_pm_limits()
function is not referenced anywhere, thus both can be
removed.

 +};

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v4] Bluetooth: Add hci_h4p driver

2014-01-02 Thread Sebastian Reichel

Hi Pavel,

Here are some cleanup suggestions for probe, removal  module
initialization functions.

On Fri, Jan 03, 2014 at 01:17:54AM +0100, Pavel Machek wrote:
 +static int hci_h4p_probe(struct platform_device *pdev)
 +{
 + struct hci_h4p_platform_data *bt_plat_data;
 + struct hci_h4p_info *info;
 + int err;
 +
 + dev_info(pdev-dev, Registering HCI H4P device\n);
 + info = kzalloc(sizeof(struct hci_h4p_info), GFP_KERNEL);

info = devm_kzalloc(pdev-dev, sizeof(struct hci_h4p_info), GFP_KERNEL);

 + if (!info)
 + return -ENOMEM;
 +
 + info-dev = pdev-dev;
 + info-tx_enabled = 1;
 + info-rx_enabled = 1;
 + spin_lock_init(info-lock);
 + spin_lock_init(info-clocks_lock);
 + skb_queue_head_init(info-txq);
 +
 + if (pdev-dev.platform_data == NULL) {
 + dev_err(pdev-dev, Could not get Bluetooth config data\n);
 + kfree(info);
 + return -ENODATA;
 + }
 +
 + bt_plat_data = pdev-dev.platform_data;
 + info-chip_type = bt_plat_data-chip_type;
 + info-bt_wakeup_gpio = bt_plat_data-bt_wakeup_gpio;
 + info-host_wakeup_gpio = bt_plat_data-host_wakeup_gpio;
 + info-reset_gpio = bt_plat_data-reset_gpio;
 + info-reset_gpio_shared = bt_plat_data-reset_gpio_shared;
 + info-bt_sysclk = bt_plat_data-bt_sysclk;
 +
 + BT_DBG(RESET gpio: %d\n, info-reset_gpio);
 + BT_DBG(BTWU gpio: %d\n, info-bt_wakeup_gpio);
 + BT_DBG(HOSTWU gpio: %d\n, info-host_wakeup_gpio);
 + BT_DBG(sysclk: %d\n, info-bt_sysclk);
 +
 + init_completion(info-test_completion);
 + complete_all(info-test_completion);
 +
 + if (!info-reset_gpio_shared) {
 + err = gpio_request(info-reset_gpio, bt_reset);

err = devm_gpio_request_one(pdev-dev, info-reset_gpio, GPIOF_OUT_INIT_LOW, 
bt_reset);

 + if (err  0) {
 + dev_err(pdev-dev, Cannot get GPIO line %d\n,
 + info-reset_gpio);
 + goto cleanup_setup;
 + }
 + }
 +
 + err = gpio_request(info-bt_wakeup_gpio, bt_wakeup);

err = devm_gpio_request_one(pdev-dev, info-bt_wakeup_gpio, 
GPIOF_OUT_INIT_LOW, bt_wakeup);

 + if (err  0) {
 + dev_err(info-dev, Cannot get GPIO line 0x%d,
 + info-bt_wakeup_gpio);
 + if (!info-reset_gpio_shared)
 + gpio_free(info-reset_gpio);
 + goto cleanup_setup;
 + }
 +
 + err = gpio_request(info-host_wakeup_gpio, host_wakeup);

err = devm_gpio_request_one(pdev-dev, info-host_wakeup_gpio, GPIOF_DIR_IN, 
host_wakeup);

 + if (err  0) {
 + dev_err(info-dev, Cannot get GPIO line %d,
 +info-host_wakeup_gpio);
 + if (!info-reset_gpio_shared)
 + gpio_free(info-reset_gpio);
 + gpio_free(info-bt_wakeup_gpio);
 + goto cleanup_setup;
 + }
 +
 + gpio_direction_output(info-reset_gpio, 0);
 + gpio_direction_output(info-bt_wakeup_gpio, 0);
 + gpio_direction_input(info-host_wakeup_gpio);

You can remove these when you use the _request_one gpio_request
methods.

 + info-irq = bt_plat_data-uart_irq;
 + info-uart_base = ioremap(bt_plat_data-uart_base, SZ_2K);

info-uart_base = devm_ioremap(pdev-dev, bt_plat_data-uart_base, SZ_2K);

 + info-uart_iclk = clk_get(NULL, bt_plat_data-uart_iclk);
 + info-uart_fclk = clk_get(NULL, bt_plat_data-uart_fclk);

devm_clk_get(...)

 + err = request_irq(info-irq, hci_h4p_interrupt, IRQF_DISABLED, 
 hci_h4p,
 +   info);

devm_request_irq(...)

 + if (err  0) {
 + dev_err(info-dev, hci_h4p: unable to get IRQ %d\n, 
 info-irq);
 + goto cleanup;
 + }
 +
 + err = request_irq(gpio_to_irq(info-host_wakeup_gpio),
 +   hci_h4p_wakeup_interrupt,  IRQF_TRIGGER_FALLING |
 +   IRQF_TRIGGER_RISING | IRQF_DISABLED,
 +   hci_h4p_wkup, info);

devm_request_irq(...)

 + if (err  0) {
 + dev_err(info-dev, hci_h4p: unable to get wakeup IRQ %d\n,
 +   gpio_to_irq(info-host_wakeup_gpio));
 + free_irq(info-irq, info);
 + goto cleanup;
 + }
 +
 + err = irq_set_irq_wake(gpio_to_irq(info-host_wakeup_gpio), 1);
 + if (err  0) {
 + dev_err(info-dev, hci_h4p: unable to set wakeup for IRQ %d\n,
 + gpio_to_irq(info-host_wakeup_gpio));
 + free_irq(info-irq, info);
 + free_irq(gpio_to_irq(info-host_wakeup_gpio), info);
 + goto cleanup;
 + }
 +
 + init_timer_deferrable(info-lazy_release);
 + info-lazy_release.function = hci_h4p_lazy_clock_release;
 + info-lazy_release.data = (unsigned long)info;
 + hci_h4p_set_clk(info, info-tx_clocks_en, 1);
 + err = hci_h4p_reset_uart(info);
 + if (err  0)
 + goto cleanup_irq;
 +

Re: [PATCHv4 0/2] twl4030-keypad DT binding

2014-01-03 Thread Sebastian Reichel

Dmitry,

What's the status of this patch? Can you queue this for 3.14?

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCHv4 0/2] twl4030-keypad DT binding

2014-01-04 Thread Sebastian Reichel

On Sat, Jan 04, 2014 at 12:49:01AM -0800, Dmitry Torokhov wrote:
 On Sat, Jan 04, 2014 at 06:40:06AM +0100, Sebastian Reichel wrote:
  What's the status of this patch? Can you queue this for 3.14?
 
 I just queued it.

Thanks.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v4] Bluetooth: Add hci_h4p driver

2014-01-05 Thread Sebastian Reichel

On Sun, Jan 05, 2014 at 11:32:50PM +0100, Pavel Machek wrote:
   Changes from v3: Moved platform data into
   include/linux/platform_data/, something I missed before.
  
  As I wrote before Tony plans to remove the boardcode for all
  OMAP boards including the Nokia N900 for 3.14, so you cannot
  boot without DT from 3.14 onwards.
 
 Well, I believe it was agreed that DT should work for at least one
 version before platform support is removed. 

https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/tag/?id=omap-for-v3.14/omap3-board-removal-signed

There have been some discussion with RMK and iirc at the end
the plan still was to remove the boardcode for 3.14.

  The drivers can still be initialized the old way using pdata quirks
  until all drivers are converted, but I think this driver can simply
  be prepared for DT directly:
 
 Well, normally DT support means a bit of argumentation and bikeshed
 painting... I believe it would be better to get the driver in as-is
 and then work on adding DT support.

Maybe. Especially the UART reference may result in some discussion.
But having the discussion early means its finished earlier :)
Assuming this is not merged for 3.14 there is quite some time for
the DT binding discussion ;)

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH 2/2] Documentation: dt: Document TSC2005 DT binding

2013-12-09 Thread Sebastian Reichel

On Mon, Dec 09, 2013 at 09:46:38AM -0800, Tony Lindgren wrote:
  +Optional properties:
  + - ti,fuzz-x : integer, X noise value of the 
  touchscreen
  +   (defaults to 4)
  + - ti,fuzz-y : integer, Y noise value of the 
  touchscreen
  +   (defaults to 8)
  + - ti,fuzz-pressure  : integer, pressure noise value of the 
  touchscreen
  +   (defaults to 2)
  + - ti,max-x  : integer, maximum reported x value
  +   (defaults to 4096)
  + - ti,max-y  : integer, maximum reported y value
  +   (defaults to 4096)
  + - ti,max-pressure   : integer, maximum reported pressure
  +   (defaults to 4096)
  + - ti,x-plate-resistance  : integer, resistance of the touchscreen's X 
  plates
  +   in ohm (defaults to 280)
  + - ti,esd-recovery-timeout-ms : integer, if the touchscreen does not 
  respond after
  +   the configured time (in milli seconds), the 
  driver
  +   will reset it. This is disabled by default.
 
 Instead of adding these optional ti,* properties you can set them in the
 driver directly in the of_match table based on the compatible flag. Then
 you can pass compatible flag like ti,tsc2005-nokia-n900, or the name of
 the LCD panel. Most likely these depend on the LCD panel selected.

I could certainly do this, but it would move the board specific data
from the boardcode into the driver. That looks contra-productive to
me. Is there a good reason to do it this way?

-- Sebastian


signature.asc
Description: Digital signature

[RFC PATCH 0/3] OMAP SSI driver

2013-08-11 Thread Sebastian Reichel

Hi !

This patchset adds an OMAP SSI driver to the HSI framework.

After leaving Nokia Carlos Chinea had no more time to work on this patchset;
Thus I tried updating the driver to fix the mentioned issues.

I applied the following changes to the last patch from Carlos:

 * convert driver to use hwmod and add SSI information to hwmod database
 * convert driver to use runtime_pm
 * change platform data, so that it forwards the wake_gpio to avoid irq_to_gpio
 * move the ssi.h and rename to hsi-omap-ssi.h (multiplatform support)

The code compiles and is initialized on the RX51. I also verified, that it
does not break the boot on my Pandaboard.

The driver has been written by Carlos Chinea and has already been sent for
public review as part of the HSI framework RFC before:

 https://lkml.org/lkml/2011/6/10/280

-- Sebastian

Sebastian Reichel (3):
  ARM: OMAP2+: hwmod-data: Add SSI information
  ARM: OMAP2+: HSI: Introduce OMAP SSI driver
  ARM: OMAP2+: Add SSI driver configuration

 arch/arm/mach-omap2/Makefile |4 +
 arch/arm/mach-omap2/board-rx51-peripherals.c |   10 +-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c   |  104 ++
 arch/arm/mach-omap2/ssi.c|   82 ++
 drivers/hsi/Kconfig  |1 +
 drivers/hsi/Makefile |1 +
 drivers/hsi/controllers/Kconfig  |   23 +
 drivers/hsi/controllers/Makefile |5 +
 drivers/hsi/controllers/omap_ssi.c   | 1879 ++
 include/linux/platform_data/hsi-omap-ssi.h   |  202 +++
 10 files changed, 2310 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-omap2/ssi.c
 create mode 100644 drivers/hsi/controllers/Kconfig
 create mode 100644 drivers/hsi/controllers/Makefile
 create mode 100644 drivers/hsi/controllers/omap_ssi.c
 create mode 100644 include/linux/platform_data/hsi-omap-ssi.h

-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] ARM: OMAP2+: Add SSI driver configuration

2013-08-11 Thread Sebastian Reichel

From: Sebastian Reichel s...@ring0.de

This patch configures and activates the OMAP SSI driver on the RX-51.
---
 arch/arm/mach-omap2/Makefile |4 ++
 arch/arm/mach-omap2/board-rx51-peripherals.c |   10 +++-
 arch/arm/mach-omap2/ssi.c|   82 ++
 3 files changed, 95 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-omap2/ssi.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index d4f6715..ace860d 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -222,6 +222,10 @@ ifneq ($(CONFIG_DRM_OMAP),)
 obj-y  += drm.o
 endif
 
+# Synchronous Serial Interface (SSI)
+omap-ssi-$(CONFIG_OMAP_SSI):= ssi.o
+obj-y  += $(omap-ssi-m) $(omap-ssi-y)
+
 # Specific board support
 obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o
 obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 9c2dd10..e2ca155 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -27,6 +27,7 @@
 #include linux/power/isp1704_charger.h
 #include linux/platform_data/spi-omap2-mcspi.h
 #include linux/platform_data/mtd-onenand-omap2.h
+#include linux/platform_data/hsi-omap-ssi.h
 
 #include asm/system_info.h
 
@@ -73,6 +74,8 @@
 #define LIS302_IRQ1_GPIO 181
 #define LIS302_IRQ2_GPIO 180  /* Not yet in use */
 
+#define RX51_CAWAKE_GPIO 151
+
 /* List all SPI devices here. Note that the list/probe order seems to matter! 
*/
 enum {
RX51_SPI_WL1251,
@@ -265,6 +268,11 @@ static struct spi_board_info 
rx51_peripherals_spi_board_info[] __initdata = {
},
 };
 
+static struct omap_ssi_board_config ssi_board_config = {
+   .num_ports = 1,
+   .cawake_gpio = { RX51_CAWAKE_GPIO },
+};
+
 static struct platform_device rx51_battery_device = {
.name   = rx51-battery,
.id = -1,
@@ -1295,7 +1303,7 @@ void __init rx51_peripherals_init(void)
if (partition)
omap_hsmmc_init(mmc);
 
+   omap_ssi_config(ssi_board_config);
rx51_charger_init();
rx51_init_twl4030_hwmon();
 }
-
diff --git a/arch/arm/mach-omap2/ssi.c b/arch/arm/mach-omap2/ssi.c
new file mode 100644
index 000..a9d6eee
--- /dev/null
+++ b/arch/arm/mach-omap2/ssi.c
@@ -0,0 +1,82 @@
+/*
+ * linux/arch/arm/mach-omap2/ssi.c
+ *
+ * Copyright (C) 2010 Nokia Corporation. All rights reserved.
+ *
+ * Contact: Carlos Chinea carlos.chi...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * 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.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/err.h
+#include linux/gpio.h
+#include linux/platform_device.h
+#include linux/platform_data/hsi-omap-ssi.h
+#include omap_hwmod.h
+#include omap_device.h
+#include omap-pm.h
+
+static struct omap_ssi_platform_data ssi_pdata = {
+   .num_ports  = SSI_NUM_PORTS,
+   .cawake_gpio= {0},
+   .get_dev_context_loss_count  = omap_pm_get_dev_context_loss_count,
+};
+
+int __init omap_ssi_config(struct omap_ssi_board_config *ssi_config)
+{
+   unsigned int port, offset, cawake_gpio;
+   int err;
+
+   ssi_pdata.num_ports = ssi_config-num_ports;
+
+   for (port = 0, offset = 7; port  ssi_config-num_ports; port++, offset 
+= 5) {
+   cawake_gpio = ssi_config-cawake_gpio[port];
+   if (!cawake_gpio)
+   continue; /* Nothing to do */
+   err = gpio_request(cawake_gpio, cawake);
+   if (err  0)
+   goto rback;
+   gpio_direction_input(cawake_gpio);
+
+   ssi_pdata.cawake_gpio[port] = ssi_config-cawake_gpio[port];
+   }
+
+   return 0;
+
+rback:
+   pr_err(omap-ssi: Request cawake (gpio%d) failed\n, cawake_gpio);
+   while (port  0)
+   gpio_free(ssi_config-cawake_gpio[--port]);
+
+   return err;
+}
+
+static int __init omap_ssi_init(void)
+{
+   struct omap_hwmod *oh;
+   struct platform_device *pdev;
+
+   oh = omap_hwmod_lookup(ssi);
+   if (!oh)
+   return -EINVAL;
+
+   pdev = omap_device_build(omap_ssi, 0, oh, ssi_pdata, sizeof(struct 
omap_ssi_platform_data));
+   WARN(IS_ERR(pdev

[PATCH 1/3] ARM: OMAP2+: hwmod-data: Add SSI information

2013-08-11 Thread Sebastian Reichel

From: Sebastian Reichel s...@ring0.de

This patch adds Synchronous Serial Interface (SSI) hwmod support for
OMAP34xx SoCs.
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  104 
 1 file changed, 104 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 0c3a427..74006c4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3693,6 +3693,109 @@ static struct omap_hwmod_ocp_if omap3xxx_l4_core__aes = 
{
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/*
+ * 'ssi' class
+ * synchronous serial interface (multichannel and full-duplex serial if)
+ */
+
+static struct omap_hwmod_class_sysconfig omap34xx_ssi_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x0010,
+   .syss_offs  = 0x0014,
+   .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_EMUFREE |
+  SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE |
+  SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+  SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+  MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+   .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_ssi_hwmod_class = {
+   .name   = ssi,
+   .sysc   = omap34xx_ssi_sysc,
+};
+
+static struct omap_hwmod_irq_info omap34xx_ssi_irqs[] = {
+   { .name = ssi_p1_mpu_irq0, .irq = 67 },
+   { .name = ssi_p1_mpu_irq1, .irq = 68 },
+   { .name = ssi_p2_mpu_irq0, .irq = 69 },
+   { .name = ssi_p2_mpu_irq1, .irq = 70 },
+   { .name = ssi_gdd_mpu, .irq = 71 },
+   { .irq = -1 },
+};
+
+static struct omap_hwmod_addr_space omap34xx_ssi_addrs[] = {
+   {
+   .name   = sys,
+   .pa_start   = 0x48058000,
+   .pa_end = 0x48058fff,
+   .flags  = ADDR_TYPE_RT,
+   },
+   {
+   /* generic distributed DMA */
+   .name   = gdd,
+   .pa_start   = 0x48059000,
+   .pa_end = 0x48059fff,
+   .flags  = ADDR_TYPE_RT,
+   },
+   {
+   /* port 1: synchronous serial transmitter */
+   .name   = p1_sst,
+   .pa_start   = 0x4805a000,
+   .pa_end = 0x4805a7ff,
+   .flags  = ADDR_TYPE_RT,
+   },
+   {
+   /* port 1: synchronous serial receiver */
+   .name   = p1_ssr,
+   .pa_start   = 0x4805a800,
+   .pa_end = 0x4805afff,
+   .flags  = ADDR_TYPE_RT,
+   },
+   {
+   /* port 2: synchronous serial transmitter */
+   .name   = p2_sst,
+   .pa_start   = 0x4805b000,
+   .pa_end = 0x4805b7ff,
+   .flags  = ADDR_TYPE_RT,
+   },
+   {
+   /* port 2: synchronous serial receiver */
+   .name   = p2_ssr,
+   .pa_start   = 0x4805b800,
+   .pa_end = 0x4805bfff,
+   .flags  = ADDR_TYPE_RT,
+   },
+   {}
+};
+
+static struct omap_hwmod omap34xx_ssi_hwmod = {
+   .name   = ssi,
+   .class  = omap34xx_ssi_hwmod_class,
+   .clkdm_name = l3_init_clkdm,
+   .mpu_irqs   = omap34xx_ssi_irqs,
+   .main_clk   = ssi_ssr_fck,
+   .prcm   = {
+   .omap2 = {
+   .prcm_reg_id= 1,
+   .module_bit = OMAP3430_EN_SSI_SHIFT,
+   .module_offs= WKUP_MOD,
+   .idlest_reg_id  = 1,
+   .idlest_idle_bit= OMAP3430ES2_ST_SSI_IDLE_SHIFT,
+   },
+   },
+};
+
+/* SSI - l3 */
+static struct omap_hwmod_ocp_if omap34xx_l3__ssi = {
+   .master = omap3xxx_l3_main_hwmod,
+   .slave  = omap34xx_ssi_hwmod,
+   .clk= ssi_ick,
+   .addr   = omap34xx_ssi_addrs,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 static struct omap_hwmod_ocp_if *omap3xxx_hwmod_ocp_ifs[] __initdata = {
omap3xxx_l3_main__l4_core,
omap3xxx_l3_main__l4_per,
@@ -3818,6 +3921,7 @@ static struct omap_hwmod_ocp_if *omap34xx_hwmod_ocp_ifs[] 
__initdata = {
 #ifdef CONFIG_OMAP_IOMMU_IVA2
omap3xxx_l3_main__mmu_iva,
 #endif
+   omap34xx_l3__ssi,
NULL
 };
 
-- 
1.7.10.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv3 00/14] OMAP SSI driver / N900 modem support

Hi,

This is the seventh round of the OMAP SSI driver patches. The plan is
to get it merged into 3.16.

Changes since PATCHv2 [0]:
 * Readded generic HSI client binding and Nokia N900 modem support.
   They are also intended to be added in 3.16 and useful for testing
   the SSI driver, so I think it makes sense to keep them in one
   patchset.
 * Updated the DT binding for the modem. A HSI port has only a single
   child now, which describes the connected remote device. This better
   fits the DT model of strictly describing hardware, since a HSI port
   is a point2point interface.  The driver can instantiate other
   drivers as needed.
 * Moved channel description from the drivers into DT.
 * I added Signed-off-by: Carlos Chinea carlos.chi...@nokia.com to the
   omap-ssi and ssi-protocol driver addtions, since the initial driver
   was from him.
 * I updated my email address.
 * Added DTS changes to ease reviewing/testing the patchset.

I did *not* implement proper PM for the Nokia N900 modem in kernel
space, since that would break all existing userlands (ofono, fso-gsmd
and Nokia's closed source binaries). I think this should be implemented
later.

Please send feedback (e.g. Tested-By or Reviewed-By :)), so that I can
send a pull request for 3.16. You can either apply this patchset or
use the n900-modem-support branch available on [1].

For testing the patchset you should build the kernel with all config
entries in the HSI subsystem activated and boot using the updated
device tree information, since platform data based booting is not
supported. Testing the patchset with ofono works like this:

 # provide cmt device for ofono
 ln -sf /sys/bus/hsi/n900-modem /dev/cmt
 # start ofono
 ofono --nodetach --debug
 # enable the modem
 mdbus2 -s org.ofono /n900_0 org.ofono.Modem.SetProperty Powered true
 # enable modem's RF parts
 mdbus2 -s org.ofono /n900_0 org.ofono.Modem.SetProperty Online true
 # scan for available networks (takes some time)
 mdbus2 -s org.ofono /n900_0 org.ofono.NetworkRegistration.Scan

TODO (post-merge):
* Central Message Queue
  I did not yet implement a central message queue in the HSI framework.
  I will do this after Nokia N900 modem is working in the mainline kernel.
* Remove the hwmod DT hack
  This depends on some future work merging hwmod data into DT.
* Implement proper context loss detection
* Implement N900 modem PM

[0] https://lkml.org/lkml/2014/3/9/139
[1] git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi.git

-- Sebastian

Sebastian Reichel (14):
  Documentation: HSI: Add some general description for the HSI subsystem
  MAINTAINERS: update HSI entry
  HSI: hsi-char: fix driver for multiport scenarios
  HSI: method to unregister clients from an hsi port
  HSI: Add channel resource support to HSI clients
  HSI: export method to (un)register clients
  HSI: Add common DT binding for HSI client devices
  HSI: Introduce OMAP SSI driver
  Documentation: DT: omap-ssi binding documentation
  HSI: Introduce driver for SSI Protocol
  HSI: Introduce Nokia N900 modem driver
  ARM: dts: omap3 clocks: simplify ssi aliases
  DTS: ARM: OMAP3-N900: Add SSI support
  DTS: ARM: OMAP3-N900: Add modem support

 .../devicetree/bindings/hsi/client-devices.txt |   44 +
 .../devicetree/bindings/hsi/nokia-modem.txt|   58 +
 Documentation/devicetree/bindings/hsi/omap-ssi.txt |   85 ++
 Documentation/hsi.txt  |   75 ++
 MAINTAINERS|4 +-
 arch/arm/boot/dts/omap3-n900.dts   |   65 +
 arch/arm/boot/dts/omap3.dtsi   |   55 +
 arch/arm/boot/dts/omap3430es1-clocks.dtsi  |   10 +-
 arch/arm/boot/dts/omap34xx.dtsi|   11 +
 .../boot/dts/omap36xx-omap3430es2plus-clocks.dtsi  |   10 +-
 arch/arm/boot/dts/omap36xx.dtsi|   11 +
 drivers/hsi/Kconfig|1 +
 drivers/hsi/Makefile   |1 +
 drivers/hsi/clients/Kconfig|   17 +
 drivers/hsi/clients/Makefile   |4 +-
 drivers/hsi/clients/hsi_char.c |   14 +-
 drivers/hsi/clients/nokia-modem.c  |  272 
 drivers/hsi/clients/ssi_protocol.c | 1188 +
 drivers/hsi/controllers/Kconfig|   19 +
 drivers/hsi/controllers/Makefile   |6 +
 drivers/hsi/controllers/omap_ssi.c |  621 +
 drivers/hsi/controllers/omap_ssi.h |  166 +++
 drivers/hsi/controllers/omap_ssi_port.c| 1401 
 drivers/hsi/controllers/omap_ssi_regs.h|  171 +++
 drivers/hsi/hsi.c  |  267 +++-
 include/linux/hsi/hsi.h|   30 +-
 include/linux/hsi/ssi_protocol.h   |   42 +
 27 files changed, 4619 insertions(+), 29 deletions(-)
 create mode 100644 Documentation/devicetree

[PATCHv3 04/14] HSI: method to unregister clients from an hsi port

This exports a method to unregister all clients from
an hsi port.

Signed-off-by: Sebastian Reichel s...@kernel.org
---
 drivers/hsi/hsi.c   | 10 ++
 include/linux/hsi/hsi.h |  1 +
 2 files changed, 11 insertions(+)

diff --git a/drivers/hsi/hsi.c b/drivers/hsi/hsi.c
index 749f7b5..e96a987 100644
--- a/drivers/hsi/hsi.c
+++ b/drivers/hsi/hsi.c
@@ -130,6 +130,16 @@ static void hsi_port_release(struct device *dev)
 }
 
 /**
+ * hsi_unregister_port - Unregister an HSI port
+ * @port: The HSI port to unregister
+ */
+void hsi_port_unregister_clients(struct hsi_port *port)
+{
+   device_for_each_child(port-device, NULL, hsi_remove_client);
+}
+EXPORT_SYMBOL_GPL(hsi_port_unregister_clients);
+
+/**
  * hsi_unregister_controller - Unregister an HSI controller
  * @hsi: The HSI controller to register
  */
diff --git a/include/linux/hsi/hsi.h b/include/linux/hsi/hsi.h
index 0dca785..2b1912f 100644
--- a/include/linux/hsi/hsi.h
+++ b/include/linux/hsi/hsi.h
@@ -282,6 +282,7 @@ struct hsi_controller *hsi_alloc_controller(unsigned int 
n_ports, gfp_t flags);
 void hsi_put_controller(struct hsi_controller *hsi);
 int hsi_register_controller(struct hsi_controller *hsi);
 void hsi_unregister_controller(struct hsi_controller *hsi);
+void hsi_port_unregister_clients(struct hsi_port *port);
 
 static inline void hsi_controller_set_drvdata(struct hsi_controller *hsi,
void *data)
-- 
1.9.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv3 05/14] HSI: Add channel resource support to HSI clients

Make HSI channel ids platform data, which can be provided
by platform data.

Signed-off-by: Sebastian Reichel s...@kernel.org
---
 drivers/hsi/clients/hsi_char.c | 12 +--
 drivers/hsi/hsi.c  | 49 +-
 include/linux/hsi/hsi.h| 24 +
 3 files changed, 74 insertions(+), 11 deletions(-)

diff --git a/drivers/hsi/clients/hsi_char.c b/drivers/hsi/clients/hsi_char.c
index 3073320..57f70c2 100644
--- a/drivers/hsi/clients/hsi_char.c
+++ b/drivers/hsi/clients/hsi_char.c
@@ -367,7 +367,7 @@ static int hsc_rx_set(struct hsi_client *cl, struct 
hsc_rx_config *rxc)
return -EINVAL;
tmp = cl-rx_cfg;
cl-rx_cfg.mode = rxc-mode;
-   cl-rx_cfg.channels = rxc-channels;
+   cl-rx_cfg.num_hw_channels = rxc-channels;
cl-rx_cfg.flow = rxc-flow;
ret = hsi_setup(cl);
if (ret  0) {
@@ -383,7 +383,7 @@ static int hsc_rx_set(struct hsi_client *cl, struct 
hsc_rx_config *rxc)
 static inline void hsc_rx_get(struct hsi_client *cl, struct hsc_rx_config *rxc)
 {
rxc-mode = cl-rx_cfg.mode;
-   rxc-channels = cl-rx_cfg.channels;
+   rxc-channels = cl-rx_cfg.num_hw_channels;
rxc-flow = cl-rx_cfg.flow;
 }
 
@@ -402,7 +402,7 @@ static int hsc_tx_set(struct hsi_client *cl, struct 
hsc_tx_config *txc)
return -EINVAL;
tmp = cl-tx_cfg;
cl-tx_cfg.mode = txc-mode;
-   cl-tx_cfg.channels = txc-channels;
+   cl-tx_cfg.num_hw_channels = txc-channels;
cl-tx_cfg.speed = txc-speed;
cl-tx_cfg.arb_mode = txc-arb_mode;
ret = hsi_setup(cl);
@@ -417,7 +417,7 @@ static int hsc_tx_set(struct hsi_client *cl, struct 
hsc_tx_config *txc)
 static inline void hsc_tx_get(struct hsi_client *cl, struct hsc_tx_config *txc)
 {
txc-mode = cl-tx_cfg.mode;
-   txc-channels = cl-tx_cfg.channels;
+   txc-channels = cl-tx_cfg.num_hw_channels;
txc-speed = cl-tx_cfg.speed;
txc-arb_mode = cl-tx_cfg.arb_mode;
 }
@@ -435,7 +435,7 @@ static ssize_t hsc_read(struct file *file, char __user 
*buf, size_t len,
return -EINVAL;
if (len  max_data_size)
len = max_data_size;
-   if (channel-ch = channel-cl-rx_cfg.channels)
+   if (channel-ch = channel-cl-rx_cfg.num_hw_channels)
return -ECHRNG;
if (test_and_set_bit(HSC_CH_READ, channel-flags))
return -EBUSY;
@@ -492,7 +492,7 @@ static ssize_t hsc_write(struct file *file, const char 
__user *buf, size_t len,
return -EINVAL;
if (len  max_data_size)
len = max_data_size;
-   if (channel-ch = channel-cl-tx_cfg.channels)
+   if (channel-ch = channel-cl-tx_cfg.num_hw_channels)
return -ECHRNG;
if (test_and_set_bit(HSC_CH_WRITE, channel-flags))
return -EBUSY;
diff --git a/drivers/hsi/hsi.c b/drivers/hsi/hsi.c
index e96a987..9d1130d 100644
--- a/drivers/hsi/hsi.c
+++ b/drivers/hsi/hsi.c
@@ -62,18 +62,39 @@ static struct bus_type hsi_bus_type = {
 
 static void hsi_client_release(struct device *dev)
 {
-   kfree(to_hsi_client(dev));
+   struct hsi_client *cl = to_hsi_client(dev);
+
+   if (cl-tx_cfg.channels)
+   kfree(cl-tx_cfg.channels);
+   if (cl-rx_cfg.channels  cl-rx_cfg.channels != cl-tx_cfg.channels)
+   kfree(cl-rx_cfg.channels);
+
+   kfree(cl);
 }
 
 static void hsi_new_client(struct hsi_port *port, struct hsi_board_info *info)
 {
struct hsi_client *cl;
+   size_t size;
 
cl = kzalloc(sizeof(*cl), GFP_KERNEL);
if (!cl)
return;
+
cl-tx_cfg = info-tx_cfg;
+   if (cl-tx_cfg.channels) {
+   size = cl-tx_cfg.num_channels * sizeof(*cl-tx_cfg.channels);
+   cl-tx_cfg.channels = kzalloc(size , GFP_KERNEL);
+   memcpy(cl-tx_cfg.channels, info-tx_cfg.channels, size);
+   }
+
cl-rx_cfg = info-rx_cfg;
+   if (cl-rx_cfg.channels) {
+   size = cl-rx_cfg.num_channels * sizeof(*cl-rx_cfg.channels);
+   cl-rx_cfg.channels = kzalloc(size , GFP_KERNEL);
+   memcpy(cl-rx_cfg.channels, info-rx_cfg.channels, size);
+   }
+
cl-device.bus = hsi_bus_type;
cl-device.parent = port-device;
cl-device.release = hsi_client_release;
@@ -502,6 +523,32 @@ int hsi_event(struct hsi_port *port, unsigned long event)
 }
 EXPORT_SYMBOL_GPL(hsi_event);
 
+/**
+ * hsi_get_channel_id_by_name - acquire channel id by channel name
+ * @cl: HSI client, which uses the channel
+ * @name: name the channel is known under
+ *
+ * Clients can call this function to get the hsi channel ids similar to
+ * requesting IRQs or GPIOs by name. This function assumes the same
+ * channel configuration is used for RX and TX.
+ *
+ * Returns -errno on error or channel id on success.
+ */
+int hsi_get_channel_id_by_name(struct hsi_client *cl, char *name

[PATCHv3 03/14] HSI: hsi-char: fix driver for multiport scenarios

Fix return code check of alloc_chrdev_region, which
returns 0 on success.

Signed-off-by: Sebastian Reichel s...@kernel.org
---
 drivers/hsi/clients/hsi_char.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hsi/clients/hsi_char.c b/drivers/hsi/clients/hsi_char.c
index e61e5f9..3073320 100644
--- a/drivers/hsi/clients/hsi_char.c
+++ b/drivers/hsi/clients/hsi_char.c
@@ -705,7 +705,7 @@ static int hsc_probe(struct device *dev)
if (!hsc_major) {
ret = alloc_chrdev_region(hsc_dev, hsc_baseminor,
HSC_DEVS, devname);
-   if (ret  0)
+   if (ret == 0)
hsc_major = MAJOR(hsc_dev);
} else {
hsc_dev = MKDEV(hsc_major, hsc_baseminor);
-- 
1.9.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv3 06/14] HSI: export method to (un)register clients

Expose method for registering and unregistering HSI clients, so that
client drivers can register other client drivers.

This is useful for HSI drivers, which want to use the functionality
of other HSI drivers. For example the N900 modem driver can load HSI
drivers for mcsaab protocol and speech protocol.

Signed-off-by: Sebastian Reichel s...@kernel.org
---
 drivers/hsi/hsi.c   | 11 ---
 include/linux/hsi/hsi.h |  3 +++
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/hsi/hsi.c b/drivers/hsi/hsi.c
index 9d1130d..07e1639 100644
--- a/drivers/hsi/hsi.c
+++ b/drivers/hsi/hsi.c
@@ -72,14 +72,15 @@ static void hsi_client_release(struct device *dev)
kfree(cl);
 }
 
-static void hsi_new_client(struct hsi_port *port, struct hsi_board_info *info)
+struct hsi_client *hsi_new_client(struct hsi_port *port,
+   struct hsi_board_info *info)
 {
struct hsi_client *cl;
size_t size;
 
cl = kzalloc(sizeof(*cl), GFP_KERNEL);
if (!cl)
-   return;
+   return NULL;
 
cl-tx_cfg = info-tx_cfg;
if (cl-tx_cfg.channels) {
@@ -106,7 +107,10 @@ static void hsi_new_client(struct hsi_port *port, struct 
hsi_board_info *info)
pr_err(hsi: failed to register client: %s\n, info-name);
put_device(cl-device);
}
+
+   return cl;
 }
+EXPORT_SYMBOL_GPL(hsi_new_client);
 
 static void hsi_scan_board_info(struct hsi_controller *hsi)
 {
@@ -122,12 +126,13 @@ static void hsi_scan_board_info(struct hsi_controller 
*hsi)
}
 }
 
-static int hsi_remove_client(struct device *dev, void *data __maybe_unused)
+int hsi_remove_client(struct device *dev, void *data __maybe_unused)
 {
device_unregister(dev);
 
return 0;
 }
+EXPORT_SYMBOL_GPL(hsi_remove_client);
 
 static int hsi_remove_port(struct device *dev, void *data __maybe_unused)
 {
diff --git a/include/linux/hsi/hsi.h b/include/linux/hsi/hsi.h
index 50a85a9..57ee40f 100644
--- a/include/linux/hsi/hsi.h
+++ b/include/linux/hsi/hsi.h
@@ -296,6 +296,9 @@ struct hsi_controller *hsi_alloc_controller(unsigned int 
n_ports, gfp_t flags);
 void hsi_put_controller(struct hsi_controller *hsi);
 int hsi_register_controller(struct hsi_controller *hsi);
 void hsi_unregister_controller(struct hsi_controller *hsi);
+struct hsi_client *hsi_new_client(struct hsi_port *port,
+   struct hsi_board_info *info);
+int hsi_remove_client(struct device *dev, void *data);
 void hsi_port_unregister_clients(struct hsi_port *port);
 
 static inline void hsi_controller_set_drvdata(struct hsi_controller *hsi,
-- 
1.9.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv3 07/14] HSI: Add common DT binding for HSI client devices

Implement and document generic DT bindings for HSI clients.

Signed-off-by: Sebastian Reichel s...@kernel.org
---
 .../devicetree/bindings/hsi/client-devices.txt |  44 +
 drivers/hsi/hsi.c  | 197 -
 include/linux/hsi/hsi.h|   2 +
 3 files changed, 241 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/hsi/client-devices.txt

diff --git a/Documentation/devicetree/bindings/hsi/client-devices.txt 
b/Documentation/devicetree/bindings/hsi/client-devices.txt
new file mode 100644
index 000..7504cb1
--- /dev/null
+++ b/Documentation/devicetree/bindings/hsi/client-devices.txt
@@ -0,0 +1,44 @@
+Each HSI port is supposed to have one child node, which
+symbols the remote device connected to the HSI port. The
+following properties are standardized for HSI clients:
+
+Required HSI configuration properties:
+
+- reg: A list of channel ids
+
+- hsi-rx-mode: Receiver Bit transmission mode (stream or frame)
+- hsi-tx-mode: Transmitter Bit transmission mode (stream or frame)
+- hsi-mode:May be used instead hsi-rx-mode and hsi-tx-mode if
+   the transmission mode is the same for receiver and
+   transmitter
+- hsi-speed-kbps:  Max bit transmission speed in kbit/s
+- hsi-flow:RX flow type (synchronized or pipeline)
+- hsi-arb-mode:Arbitration mode for TX frame (round-robin, 
priority)
+
+Optional HSI configuration properties:
+
+- reg-names:   A list with one name per channel specified in the
+   reg property
+
+
+Device Tree node example for an HSI client:
+
+hsi-controller {
+   hsi-port {
+   modem: hsi-client {
+   compatible = nokia,n900-modem;
+
+   reg = 0, 1, 2, 3;
+   reg-names = mcsaab-control,
+   speech-control,
+   speech-data,
+   mcsaab-data;
+   hsi-speed-kbps = 55000;
+   hsi-mode = frame;
+   hsi-flow = synchronized;
+   hsi-arb-mode = round-robin;
+
+   /* more client specific properties */
+   };
+   };
+};
diff --git a/drivers/hsi/hsi.c b/drivers/hsi/hsi.c
index 07e1639..5973906 100644
--- a/drivers/hsi/hsi.c
+++ b/drivers/hsi/hsi.c
@@ -26,8 +26,14 @@
 #include linux/slab.h
 #include linux/string.h
 #include linux/notifier.h
+#include linux/of.h
+#include linux/of_device.h
 #include hsi_core.h
 
+static struct hsi_board_info hsi_char_dev_info = {
+   .name = hsi_char,
+};
+
 static ssize_t modalias_show(struct device *dev,
struct device_attribute *a __maybe_unused, char *buf)
 {
@@ -50,7 +56,13 @@ static int hsi_bus_uevent(struct device *dev, struct 
kobj_uevent_env *env)
 
 static int hsi_bus_match(struct device *dev, struct device_driver *driver)
 {
-   return strcmp(dev_name(dev), driver-name) == 0;
+   if (of_driver_match_device(dev, driver))
+   return true;
+
+   if (strcmp(dev_name(dev), driver-name) == 0)
+   return true;
+
+   return false;
 }
 
 static struct bus_type hsi_bus_type = {
@@ -126,6 +138,187 @@ static void hsi_scan_board_info(struct hsi_controller 
*hsi)
}
 }
 
+static int hsi_of_property_parse_mode(struct device_node *client, char *name,
+ unsigned int *result)
+{
+   const char *mode;
+   int err;
+
+   err = of_property_read_string(client, name, mode);
+   if (err  0)
+   return err;
+
+   if (strcmp(mode, stream) == 0)
+   *result = HSI_MODE_STREAM;
+   else if (strcmp(mode, frame) == 0)
+   *result = HSI_MODE_FRAME;
+   else
+   return -EINVAL;
+
+   return 0;
+}
+
+static int hsi_of_property_parse_flow(struct device_node *client, char *name,
+ unsigned int *result)
+{
+   const char *flow;
+   int err;
+
+   err = of_property_read_string(client, name, flow);
+   if (err  0)
+   return err;
+
+   if (strcmp(flow, synchronized) == 0)
+   *result = HSI_FLOW_SYNC;
+   else if (strcmp(flow, pipeline) == 0)
+   *result = HSI_FLOW_PIPE;
+   else
+   return -EINVAL;
+
+   return 0;
+}
+
+static int hsi_of_property_parse_arb_mode(struct device_node *client,
+ char *name, unsigned int *result)
+{
+   const char *arb_mode;
+   int err;
+
+   err = of_property_read_string(client, name, arb_mode);
+   if (err  0)
+   return err;
+
+   if (strcmp(arb_mode, round-robin) == 0)
+   *result = HSI_ARB_RR;
+   else if (strcmp(arb_mode, priority) == 0

[PATCHv3 09/14] Documentation: DT: omap-ssi binding documentation

Create device tree binding documentation for
OMAP Synchronous Serial Interface (SSI) device.

Signed-off-by: Sebastian Reichel s...@kernel.org
---
 Documentation/devicetree/bindings/hsi/omap-ssi.txt | 85 ++
 1 file changed, 85 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hsi/omap-ssi.txt

diff --git a/Documentation/devicetree/bindings/hsi/omap-ssi.txt 
b/Documentation/devicetree/bindings/hsi/omap-ssi.txt
new file mode 100644
index 000..709419b
--- /dev/null
+++ b/Documentation/devicetree/bindings/hsi/omap-ssi.txt
@@ -0,0 +1,85 @@
+OMAP SSI controller bindings
+
+OMAP Synchronous Serial Interface (SSI) controller implements a legacy
+variant of MIPI's High Speed Synchronous Serial Interface (HSI).
+
+Required properties:
+- compatible:  Should include ti,omap3-ssi.
+- reg-names:   Contains the values sys and gdd.
+- reg: Contains a register specifier for each entry in
+   reg-names.
+- interrupt-names:  Contains the value gdd_mpu.
+- interrupts:  Contains interrupt information for each entry in
+   interrupt-names.
+- ranges:  Represents the bus address mapping between the main
+   controller node and the child nodes below.
+- clocks:  Contains clock specifiers for each entry in
+clock-names.
+- clock-names: Must include the following entries:
+  ssi_ssr_fck: The OMAP clock of that name
+  ssi_sst_fck: The OMAP clock of that name
+  ssi_ick: The OMAP clock of that name
+- #address-cells:  Should be set to 1
+- #size-cells: Should be set to 1
+
+Each port is represented as a sub-node of the ti,omap3-ssi device.
+
+Required Port sub-node properties:
+- compatible:  Should be set to the following value
+ti,omap3-ssi-port (applicable to OMAP34xx devices)
+- reg-names:   Contains the values rx and tx.
+- reg: Contains a register specifier for each entry in
+   reg-names.
+- interrupt-parent Should be a phandle for the interrupt controller
+- interrupt-names: Contains the values mpu_irq0 and mpu_irq1.
+- interrupts:  Contains interrupt information for each entry in
+   interrupt-names.
+- ti,ssi-cawake-gpio:  Defines which GPIO pin is used to signify CAWAKE
+   events for the port. This is an optional board-specific
+   property. If it's missing the port will not be
+   enabled.
+
+Example for Nokia N900:
+
+ssi-controller@48058000 {
+   compatible = ti,omap3-ssi;
+
+   /* needed until hwmod is updated to use the compatible string */
+   ti,hwmods = ssi;
+
+   reg = 0x48058000 0x1000,
+ 0x48059000 0x1000;
+   reg-names = sys,
+   gdd;
+
+   interrupts = 55;
+   interrupt-names = gdd_mpu;
+
+   clocks = ssi_ssr_fck,
+ssi_sst_fck,
+ssi_ick;
+   clock-names = ssi_ssr_fck,
+ ssi_sst_fck,
+ ssi_ick;
+
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+
+   ssi-port@0 {
+   compatible = ti,omap3-ssi-port;
+
+   reg = 0x4805a000 0x800,
+ 0x4805a800 0x800;
+   reg-names = tx,
+   rx;
+
+   interrupt-parent = intc;
+   interrupts = 51,
+52;
+   interrupt-names = mpu_irq0,
+ mpu_irq1;
+
+   ti,ssi-cawake-gpio = gpio5 23 GPIO_ACTIVE_HIGH; /* 151 */
+   }
+}
-- 
1.9.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv3 12/14] ARM: dts: omap3 clocks: simplify ssi aliases

From: Sebastian Reichel s...@debian.org

update aliases for the ssi clocks ssi_ssr_fck, ssi_sst_fck and ssi_ick
to make them consistent for omap34xx and omap36xx. This makes it
possible to reference the clocks from generic omap3 dts files.

Signed-off-by: Sebastian Reichel s...@debian.org
Acked-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/boot/dts/omap3430es1-clocks.dtsi  | 10 +-
 arch/arm/boot/dts/omap36xx-omap3430es2plus-clocks.dtsi | 10 +-
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/omap3430es1-clocks.dtsi 
b/arch/arm/boot/dts/omap3430es1-clocks.dtsi
index 02f6c7f..6f31954 100644
--- a/arch/arm/boot/dts/omap3430es1-clocks.dtsi
+++ b/arch/arm/boot/dts/omap3430es1-clocks.dtsi
@@ -82,16 +82,16 @@
ti,dividers = 0, 1, 2, 3, 4, 0, 6, 0, 8;
};
 
-   ssi_ssr_fck_3430es1: ssi_ssr_fck_3430es1 {
+   ssi_ssr_fck: ssi_ssr_fck_3430es1 {
#clock-cells = 0;
compatible = ti,composite-clock;
clocks = ssi_ssr_gate_fck_3430es1, 
ssi_ssr_div_fck_3430es1;
};
 
-   ssi_sst_fck_3430es1: ssi_sst_fck_3430es1 {
+   ssi_sst_fck: ssi_sst_fck_3430es1 {
#clock-cells = 0;
compatible = fixed-factor-clock;
-   clocks = ssi_ssr_fck_3430es1;
+   clocks = ssi_ssr_fck;
clock-mult = 1;
clock-div = 2;
};
@@ -120,7 +120,7 @@
clock-div = 1;
};
 
-   ssi_ick_3430es1: ssi_ick_3430es1 {
+   ssi_ick: ssi_ick_3430es1 {
#clock-cells = 0;
compatible = ti,omap3-no-wait-interface-clock;
clocks = ssi_l4_ick;
@@ -203,6 +203,6 @@
 i2c1_ick, uart2_ick, uart1_ick, gpt11_ick,
 gpt10_ick, mcbsp5_ick, mcbsp1_ick,
 omapctrl_ick, aes2_ick, sha12_ick,
-fshostusb_fck, fac_ick, ssi_ick_3430es1;
+fshostusb_fck, fac_ick, ssi_ick;
};
 };
diff --git a/arch/arm/boot/dts/omap36xx-omap3430es2plus-clocks.dtsi 
b/arch/arm/boot/dts/omap36xx-omap3430es2plus-clocks.dtsi
index 8ed475d..877318c 100644
--- a/arch/arm/boot/dts/omap36xx-omap3430es2plus-clocks.dtsi
+++ b/arch/arm/boot/dts/omap36xx-omap3430es2plus-clocks.dtsi
@@ -25,16 +25,16 @@
ti,dividers = 0, 1, 2, 3, 4, 0, 6, 0, 8;
};
 
-   ssi_ssr_fck_3430es2: ssi_ssr_fck_3430es2 {
+   ssi_ssr_fck: ssi_ssr_fck_3430es2 {
#clock-cells = 0;
compatible = ti,composite-clock;
clocks = ssi_ssr_gate_fck_3430es2, 
ssi_ssr_div_fck_3430es2;
};
 
-   ssi_sst_fck_3430es2: ssi_sst_fck_3430es2 {
+   ssi_sst_fck: ssi_sst_fck_3430es2 {
#clock-cells = 0;
compatible = fixed-factor-clock;
-   clocks = ssi_ssr_fck_3430es2;
+   clocks = ssi_ssr_fck;
clock-mult = 1;
clock-div = 2;
};
@@ -55,7 +55,7 @@
clock-div = 1;
};
 
-   ssi_ick_3430es2: ssi_ick_3430es2 {
+   ssi_ick: ssi_ick_3430es2 {
#clock-cells = 0;
compatible = ti,omap3-ssi-interface-clock;
clocks = ssi_l4_ick;
@@ -193,6 +193,6 @@
 i2c1_ick, uart2_ick, uart1_ick, gpt11_ick,
 gpt10_ick, mcbsp5_ick, mcbsp1_ick,
 omapctrl_ick, aes2_ick, sha12_ick,
-ssi_ick_3430es2;
+ssi_ick;
};
 };
-- 
1.9.0

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv3 11/14] HSI: Introduce Nokia N900 modem driver

The Nokia N900's modem is connected via Synchronous Serial Interface (SSI),
which is a legacy version of MIPI's High-speed Synchronous Serial Interface
(HSI).

The handles the GPIOs for enabling and resetting the modem and instanciates
ssi-protocol for data exchange. It does not yet support exchanging voice data
with the modem.

Signed-off-by: Sebastian Reichel s...@kernel.org
---
 .../devicetree/bindings/hsi/nokia-modem.txt|  58 +
 drivers/hsi/clients/Kconfig|   9 +
 drivers/hsi/clients/Makefile   |   1 +
 drivers/hsi/clients/nokia-modem.c  | 272 +
 4 files changed, 340 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hsi/nokia-modem.txt
 create mode 100644 drivers/hsi/clients/nokia-modem.c

diff --git a/Documentation/devicetree/bindings/hsi/nokia-modem.txt 
b/Documentation/devicetree/bindings/hsi/nokia-modem.txt
new file mode 100644
index 000..a8b8b6b
--- /dev/null
+++ b/Documentation/devicetree/bindings/hsi/nokia-modem.txt
@@ -0,0 +1,58 @@
+Nokia modem client bindings
+
+The Nokia modem HSI client follows the common HSI
+client binding and inherits all required properties.
+The following additional properties are needed by
+the Nokia modem HSI client:
+
+Required properties:
+- compatible:  Should be one of
+  nokia,n900-modem
+- reg-names:   Should contain the following strings
+  mcsaab-control
+  speech-control
+  speech-data
+  mcsaab-data
+- gpios:   Should provide a GPIO handler for each GPIO listed in
+gpio-names
+- gpio-names:  Should contain the following strings
+  cmt_apeslpx
+  cmt_rst_rq
+  cmt_en
+  cmt_rst
+  cmt_bsi
+- interrupts:  Should be IRQ handle for modem's reset indication
+
+Example:
+
+ssi_port {
+   modem: hsi-client {
+   compatible = nokia,n900-modem;
+
+   pinctrl-names = default;
+   pinctrl-0 = modem_pins;
+
+   reg = 0, 1, 2, 3;
+   reg-names = mcsaab-control,
+   speech-control,
+   speech-data,
+   mcsaab-data;
+   hsi-speed-kbps = 55000;
+   hsi-mode = frame;
+   hsi-flow = synchronized;
+   hsi-arb-mode = round-robin;
+
+   interrupts-extended = gpio3 8 IRQ_TYPE_EDGE_FALLING; /* 72 */
+
+   gpios = gpio3  6 GPIO_ACTIVE_HIGH, /* 70 */
+   gpio3  9 GPIO_ACTIVE_HIGH, /* 73 */
+   gpio3 10 GPIO_ACTIVE_HIGH, /* 74 */
+   gpio3 11 GPIO_ACTIVE_HIGH, /* 75 */
+   gpio5 29 GPIO_ACTIVE_HIGH; /* 157 */
+   gpio-names = cmt_apeslpx,
+cmt_rst_rq,
+cmt_en,
+cmt_rst,
+cmt_bsi;
+   };
+};
diff --git a/drivers/hsi/clients/Kconfig b/drivers/hsi/clients/Kconfig
index 0c70861..6ce1ea2 100644
--- a/drivers/hsi/clients/Kconfig
+++ b/drivers/hsi/clients/Kconfig
@@ -4,6 +4,15 @@
 
 comment HSI clients
 
+config NOKIA_MODEM
+   tristate Nokia Modem
+   depends on SSI_PROTOCOL
+   help
+   Say Y here if you want to add support for the modem on Nokia
+   N900 (Nokia RX-51) hardware.
+
+   If unsure, say N.
+
 config SSI_PROTOCOL
tristate SSI protocol
depends on HSI  OMAP_SSI  PHONET
diff --git a/drivers/hsi/clients/Makefile b/drivers/hsi/clients/Makefile
index ccbf768..4d5bc0e 100644
--- a/drivers/hsi/clients/Makefile
+++ b/drivers/hsi/clients/Makefile
@@ -2,5 +2,6 @@
 # Makefile for HSI clients
 #
 
+obj-$(CONFIG_NOKIA_MODEM)  += nokia-modem.o
 obj-$(CONFIG_SSI_PROTOCOL) += ssi_protocol.o
 obj-$(CONFIG_HSI_CHAR) += hsi_char.o
diff --git a/drivers/hsi/clients/nokia-modem.c 
b/drivers/hsi/clients/nokia-modem.c
new file mode 100644
index 000..f12ec76
--- /dev/null
+++ b/drivers/hsi/clients/nokia-modem.c
@@ -0,0 +1,272 @@
+/*
+ * nokia-modem.c
+ *
+ * HSI client driver for Nokia N900 modem.
+ *
+ * Copyright (C) 2014 Sebastian Reichel s...@kernel.org
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * 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.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include linux/gpio/consumer.h
+#include linux/hsi/hsi.h
+#include linux/init.h
+#include linux

[PATCHv3 14/14] DTS: ARM: OMAP3-N900: Add modem support