[PATCH] rnndb/mdp5: Add some CTL flush bits

2015-03-24 Thread Stephane Viau
Some upcoming targets have more bits to set in CTL_FLUSH registers.

Example: msm8x16 needs to set TIMING1 bit so that some of the
INTF1's interface registers get flushed.

Signed-off-by: Stephane Viau sv...@codeaurora.org
---
 rnndb/mdp/mdp5.xml | 8 
 1 file changed, 8 insertions(+)

diff --git a/rnndb/mdp/mdp5.xml b/rnndb/mdp/mdp5.xml
index 423249a..03dcc3a 100644
--- a/rnndb/mdp/mdp5.xml
+++ b/rnndb/mdp/mdp5.xml
@@ -250,11 +250,19 @@ xsi:schemaLocation=http://nouveau.freedesktop.org/ 
rules-ng.xsd
bitfield name=DSPP0 pos=13 type=boolean/
bitfield name=DSPP1 pos=14 type=boolean/
bitfield name=DSPP2 pos=15 type=boolean/
+   bitfield name=WB   pos=16 type=boolean/
bitfield name=CTL   pos=17 type=boolean/
bitfield name=VIG3 pos=18  type=boolean/
bitfield name=RGB3 pos=19  type=boolean/
bitfield name=LM5  pos=20  type=boolean/
bitfield name=DSPP3 pos=21 type=boolean/
+   bitfield name=CURSOR_0 pos=22 type=boolean/
+   bitfield name=CURSOR_1 pos=23 type=boolean/
+   bitfield name=CHROMADOWN_0 pos=26 type=boolean/
+   bitfield name=TIMING_3 pos=28 type=boolean/
+   bitfield name=TIMING_2 pos=29 type=boolean/
+   bitfield name=TIMING_1 pos=30 type=boolean/
+   bitfield name=TIMING_0 pos=31 type=boolean/
/reg32
reg32 offset=0x01C name=START/
reg32 offset=0x020 name=PACK_3D/
-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/2] drm/msm/mdp5: Remove CTL flush dummy bits

2015-03-24 Thread Stephane Viau
This TODO can now be removed and replaced by the previous patch
drm/msm/mdp5: Update headers (add CTL flush bits)

Signed-off-by: Stephane Viau sv...@codeaurora.org
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
index 0fa7fce..5488b687 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
@@ -316,13 +316,6 @@ int mdp5_ctl_blend(struct mdp5_ctl *ctl, u32 lm, u32 
blend_cfg)
 
 u32 mdp_ctl_flush_mask_encoder(struct mdp5_interface *intf)
 {
-   /* these are dummy bits for now, but will appear in next chipsets: */
-#define MDP5_CTL_FLUSH_TIMING_00x8000
-#define MDP5_CTL_FLUSH_TIMING_10x4000
-#define MDP5_CTL_FLUSH_TIMING_20x2000
-#define MDP5_CTL_FLUSH_TIMING_30x1000
-#define MDP5_CTL_FLUSH_WB  0x0001
-
if (intf-type == INTF_WB)
return MDP5_CTL_FLUSH_WB;
 
@@ -337,10 +330,6 @@ u32 mdp_ctl_flush_mask_encoder(struct mdp5_interface *intf)
 
 u32 mdp_ctl_flush_mask_cursor(int cursor_id)
 {
-   /* these are dummy bits for now, but will appear in next chipsets: */
-#define MDP5_CTL_FLUSH_CURSOR_00x0040
-#define MDP5_CTL_FLUSH_CURSOR_10x0080
-
switch (cursor_id) {
case 0: return MDP5_CTL_FLUSH_CURSOR_0;
case 1: return MDP5_CTL_FLUSH_CURSOR_1;
-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 0/2] Implement CTL flush dummy bits

2015-03-24 Thread Stephane Viau
This patchset proposes in a couple of changes (separate generated header)
to remove the temporary defined symbols in the code and place them into
the generated header file.

Stephane Viau (2):
  drm/msm/mdp5: Update headers (add CTL flush bits)
  drm/msm/mdp5: Remove CTL flush dummy bits

 drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 12 ++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 11 ---
 2 files changed, 10 insertions(+), 13 deletions(-)

-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/2] drm/msm/mdp5: Update headers (add CTL flush bits)

2015-03-24 Thread Stephane Viau
Some upcoming targets have more bits to set in CTL_FLUSH
registers.

Example: msm8x16 needs to set TIMING1 bit so that some of the
INTF1's interface registers get flushed.

Signed-off-by: Stephane Viau sv...@codeaurora.org
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
index b4e2624..b9a4ded 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
@@ -8,9 +8,9 @@ http://github.com/freedreno/envytools/
 git clone https://github.com/freedreno/envytools.git
 
 The rules-ng-ng source files this header was generated from are:
-- /local/mnt2/workspace2/sviau/envytools/rnndb/mdp/mdp5.xml(  
28872 bytes, from 2015-03-09 12:40:51)
+- /local/mnt2/workspace2/sviau/envytools/rnndb/mdp/mdp5.xml(  
29312 bytes, from 2015-03-23 21:18:48)
 - /local/mnt2/workspace2/sviau/envytools/rnndb/freedreno_copyright.xml (   
1453 bytes, from 2014-06-02 18:31:15)
-- /local/mnt2/workspace2/sviau/envytools/rnndb/mdp/mdp_common.xml  (   
2357 bytes, from 2015-01-23 16:20:19)
+- /local/mnt2/workspace2/sviau/envytools/rnndb/mdp/mdp_common.xml  (   
2357 bytes, from 2015-03-23 20:38:49)
 
 Copyright (C) 2013-2015 by the following authors:
 - Rob Clark robdcl...@gmail.com (robclark)
@@ -458,11 +458,19 @@ static inline uint32_t REG_MDP5_CTL_FLUSH(uint32_t i0) { 
return 0x0018 + __o
 #define MDP5_CTL_FLUSH_DSPP0   0x2000
 #define MDP5_CTL_FLUSH_DSPP1   0x4000
 #define MDP5_CTL_FLUSH_DSPP2   0x8000
+#define MDP5_CTL_FLUSH_WB  0x0001
 #define MDP5_CTL_FLUSH_CTL 0x0002
 #define MDP5_CTL_FLUSH_VIG30x0004
 #define MDP5_CTL_FLUSH_RGB30x0008
 #define MDP5_CTL_FLUSH_LM5 0x0010
 #define MDP5_CTL_FLUSH_DSPP3   0x0020
+#define MDP5_CTL_FLUSH_CURSOR_0
0x0040
+#define MDP5_CTL_FLUSH_CURSOR_1
0x0080
+#define MDP5_CTL_FLUSH_CHROMADOWN_00x0400
+#define MDP5_CTL_FLUSH_TIMING_3
0x1000
+#define MDP5_CTL_FLUSH_TIMING_2
0x2000
+#define MDP5_CTL_FLUSH_TIMING_1
0x4000
+#define MDP5_CTL_FLUSH_TIMING_0
0x8000
 
 static inline uint32_t REG_MDP5_CTL_START(uint32_t i0) { return 0x001c + 
__offset_CTL(i0); }
 
-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 1/9] regmap: Introduce regmap_get_max_register.

2015-03-24 Thread Srinivas Kandagatla



On 24/03/15 22:36, Mark Brown wrote:

On Tue, Mar 24, 2015 at 10:29:39PM +, Srinivas Kandagatla wrote:


This patch introduces regmap_get_max_register() function which would be
used by the infrastructures like eeprom framework built on top of
regmap.


In what way would it be used?

Its used in 2 purposes
1 It is used for sanity check purposes of the register ranges provided 
via DT/non-DT eeprom data cells.


2 To stop user reading when eeprom binary from /sys/class/eeprom/*/eeprom




+int regmap_get_max_register(struct regmap *map)
+{
+   return map-max_register ? : -EINVAL;
+}


Please write the logic out properly, don't abuse the ternery operator.
Am happy to change it to your preference in next version, but this GNU 
extensions widely used in the kernel


$  grep -rR return.*? : ./linux | wc -l

115





--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 1/9] regmap: Introduce regmap_get_max_register.

2015-03-24 Thread Srinivas Kandagatla
This patch introduces regmap_get_max_register() function which would be
used by the infrastructures like eeprom framework built on top of
regmap.

Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
 drivers/base/regmap/regmap.c | 12 
 include/linux/regmap.h   |  7 +++
 2 files changed, 19 insertions(+)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index d2f8a81..6fd234b 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -2616,6 +2616,18 @@ int regmap_get_val_bytes(struct regmap *map)
 }
 EXPORT_SYMBOL_GPL(regmap_get_val_bytes);
 
+/*
+ * regmap_get_max_register(): Report the max register value
+ *
+ * Report the max register value, mainly intended to for use by
+ * generic infrastructure built on top of regmap.
+ */
+int regmap_get_max_register(struct regmap *map)
+{
+   return map-max_register ? : -EINVAL;
+}
+EXPORT_SYMBOL_GPL(regmap_get_max_register);
+
 int regmap_parse_val(struct regmap *map, const void *buf,
unsigned int *val)
 {
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index 4419b99..c46dbf3 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -433,6 +433,7 @@ int regmap_update_bits_check_async(struct regmap *map, 
unsigned int reg,
   unsigned int mask, unsigned int val,
   bool *change);
 int regmap_get_val_bytes(struct regmap *map);
+int regmap_get_max_register(struct regmap *map);
 int regmap_async_complete(struct regmap *map);
 bool regmap_can_raw_write(struct regmap *map);
 
@@ -676,6 +677,12 @@ static inline int regmap_get_val_bytes(struct regmap *map)
return -EINVAL;
 }
 
+static inline int regmap_get_max_register(struct regmap *map)
+{
+   WARN_ONCE(1, regmap API is disabled);
+   return -EINVAL;
+}
+
 static inline int regcache_sync(struct regmap *map)
 {
WARN_ONCE(1, regmap API is disabled);
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 3/9] eeprom: Add a simple EEPROM framework for eeprom providers

2015-03-24 Thread Srinivas Kandagatla
This patch adds just providers part of the framework just to enable easy
review.

Up until now, EEPROM drivers were stored in drivers/misc, where they all had to
duplicate pretty much the same code to register a sysfs file, allow in-kernel
users to access the content of the devices they were driving, etc.

This was also a problem as far as other in-kernel users were involved, since
the solutions used were pretty much different from on driver to another, there
was a rather big abstraction leak.

This introduction of this framework aims at solving this. It also introduces DT
representation for consumer devices to go get the data they require (MAC
Addresses, SoC/Revision ID, part numbers, and so on) from the EEPROMs.

Having regmap interface to this framework would give much better
abstraction for eeproms on different buses.

Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
[Maxime Ripard: intial version of eeprom framework]
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
 drivers/Kconfig |   2 +
 drivers/Makefile|   1 +
 drivers/eeprom/Kconfig  |  11 ++
 drivers/eeprom/Makefile |   6 ++
 drivers/eeprom/core.c   | 227 
 include/linux/eeprom-provider.h |  42 
 6 files changed, 289 insertions(+)
 create mode 100644 drivers/eeprom/Kconfig
 create mode 100644 drivers/eeprom/Makefile
 create mode 100644 drivers/eeprom/core.c
 create mode 100644 include/linux/eeprom-provider.h

diff --git a/drivers/Kconfig b/drivers/Kconfig
index c70d6e4..d7afc82 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -184,4 +184,6 @@ source drivers/thunderbolt/Kconfig
 
 source drivers/android/Kconfig
 
+source drivers/eeprom/Kconfig
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 527a6da..57eb5b0 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -165,3 +165,4 @@ obj-$(CONFIG_RAS)   += ras/
 obj-$(CONFIG_THUNDERBOLT)  += thunderbolt/
 obj-$(CONFIG_CORESIGHT)+= coresight/
 obj-$(CONFIG_ANDROID)  += android/
+obj-$(CONFIG_EEPROM)   += eeprom/
diff --git a/drivers/eeprom/Kconfig b/drivers/eeprom/Kconfig
new file mode 100644
index 000..21e1847
--- /dev/null
+++ b/drivers/eeprom/Kconfig
@@ -0,0 +1,11 @@
+menuconfig EEPROM
+   tristate EEPROM Support
+   depends on OF
+   select REGMAP
+   help
+ Support for EEPROM alike devices.
+
+ This framework is designed to provide a generic interface to EEPROM
+ from both the Linux Kernel and the userspace.
+
+ If unsure, say no.
diff --git a/drivers/eeprom/Makefile b/drivers/eeprom/Makefile
new file mode 100644
index 000..51a727f
--- /dev/null
+++ b/drivers/eeprom/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for eeprom drivers.
+#
+
+obj-$(CONFIG_EEPROM)   += eeprom_core.o
+eeprom_core-y  := core.o
diff --git a/drivers/eeprom/core.c b/drivers/eeprom/core.c
new file mode 100644
index 000..9fd556c
--- /dev/null
+++ b/drivers/eeprom/core.c
@@ -0,0 +1,227 @@
+/*
+ * EEPROM framework core.
+ *
+ * Copyright (C) 2015 Srinivas Kandagatla srinivas.kandaga...@linaro.org
+ * Copyright (C) 2013 Maxime Ripard maxime.rip...@free-electrons.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 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/device.h
+#include linux/eeprom-provider.h
+#include linux/export.h
+#include linux/fs.h
+#include linux/idr.h
+#include linux/init.h
+#include linux/regmap.h
+#include linux/module.h
+#include linux/of.h
+#include linux/slab.h
+#include linux/uaccess.h
+
+struct eeprom_device {
+   struct regmap   *regmap;
+   int stride;
+   size_t  size;
+
+   struct module   *owner;
+   struct device   dev;
+   int id;
+   int users;
+};
+
+static DEFINE_MUTEX(eeprom_mutex);
+static DEFINE_IDA(eeprom_ida);
+
+#define to_eeprom(d) container_of(d, struct eeprom_device, dev)
+
+static ssize_t bin_attr_eeprom_read(struct file *filp, struct kobject *kobj,
+   struct bin_attribute *attr,
+   char *buf, loff_t offset, size_t count)
+{
+   struct device *dev = container_of(kobj, struct device, kobj);
+   struct eeprom_device *eeprom = to_eeprom(dev);
+   int rc;
+
+   if (offset  eeprom-size)
+   return -EINVAL;
+
+   if (offset + count  eeprom-size)
+   count = eeprom-size - offset;
+
+   rc = 

[PATCH v3 9/9] eeprom: Add to MAINTAINERS for eeprom framework

2015-03-24 Thread Srinivas Kandagatla
This patch adds MAINTAINERS to eeprom framework.

Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index d66a97d..ee7ba92 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3657,6 +3657,15 @@ T:   git git://git.alsa-project.org/alsa-kernel.git
 S: Maintained
 F: sound/usb/misc/ua101.c
 
+EEPROM FRAMEWORK
+M: Srinivas Kandagatla srinivas.kandaga...@linaro.org
+M: Maxime Ripard maxime.rip...@free-electrons.com
+S: Maintained
+F: drivers/eeprom/
+F: Documentation/devicetree/bindings/eeprom/
+F: include/linux/eeprom-provider.h
+F: include/linux/eeprom-consumer.h
+
 EXTENSIBLE FIRMWARE INTERFACE (EFI)
 M: Matt Fleming matt.flem...@intel.com
 L: linux-...@vger.kernel.org
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 2/9] regmap: Introduce regmap_get_reg_stride.

2015-03-24 Thread Mark Brown
On Tue, Mar 24, 2015 at 10:30:00PM +, Srinivas Kandagatla wrote:

 + /* regmap_get_reg_stride(): Report the register address stride
 + *
 + * Report the register address stride, mainly intended to for use by
 + * generic infrastructure built on top of regmap.
 + */
 +int regmap_get_reg_stride(struct regmap *map)

Please fix the indentation for the comment block and add kerneldoc for
the argument.  This is an exported function so it should also be /** not
/*


signature.asc
Description: Digital signature


[PATCH v3 0/9] Add simple EEPROM Framework via regmap.

2015-03-24 Thread Srinivas Kandagatla
Thankyou all for providing inputs and comments on previous versions of this 
patchset.
Here is the v3 of the patchset addressing all the issues raised as
part of previous versions review.

This patchset adds a new simple EEPROM framework to kernel.

Up until now, EEPROM drivers were stored in drivers/misc, where they all had to
duplicate pretty much the same code to register a sysfs file, allow in-kernel
users to access the content of the devices they were driving, etc.

This was also a problem as far as other in-kernel users were involved, since
the solutions used were pretty much different from on driver to another, there
was a rather big abstraction leak.

This introduction of this framework aims at solving this. It also introduces DT
representation for consumer devices to go get the data they require (MAC
Addresses, SoC/Revision ID, part numbers, and so on) from the EEPROMs.

Having regmap interface to this framework would give much better
abstraction for eeproms on different buses.

patch 1-2 Introduces two regmap helper functions.
patch 3-5 Introduces the EEPROM framework.
Patch 6 migrates an existing driver to eeprom framework.
Patch 7-8 Adds Qualcomm specific qfprom driver.
Patch 9 adds entry in MAINTAINERS.

Its also possible to migrate other eeprom drivers to this framework.
Patch 6 can also be made a generic mmio-eeprom driver.

Providers APIs:
eeprom_register/unregister();

Consumers APIs:
eeprom_cell_get()/of_eeprom_cell_get()/of_eeprom_cell_get_byname();
eeprom_cell_put();
eeprom_cell_read()/eeprom_cell_write();

Device Tree:

/* Provider */
qfprom: qfprom@0070 {
compatible  = qcom,qfprom;
reg = 0x0070 0x1000;
...

/* Data cells */
tsens_calibration: calib@404 {
reg = 0x404 0x10;
};

serial_number: sn {
reg = 0x104 0x4, 0x204 0x4, 0x30c 0x4;

};
...
};

/* Consumer node */
tsens: tsens {
...
eeproms = tsens_calibration;
eeprom-names = calib;
...
};

userspace interface:

hexdump /sys/class/eeprom/qfprom0/eeprom


  
000        
*
0a0 db10 2240  e000 0c00 0c00  0c00
000        
...
*
0001000

Changes since v2(https://lkml.org/lkml/2015/3/13/168)
 * Fixed error handling in eeprom_register spotted by Mark Brown
 * Added new regmap_get_max_register() and regmap_get_reg_stride().
 * Fixed module build errors reported by kbuild robot.
 * recycle the ids when eeprom provider is released.

Changes since v1(https://lkml.org/lkml/2015/3/5/153)
 * Fix various Licencing issues spotted by Paul Bolle and Mark Brown
 * Allow eeprom core to build as module spotted by Paul Bolle.
 * Fix various kconfig issues spotted by Paul Bolle.
 * remove unessary atomic varible spotted by Mark Brown.
 * Few cleanups and common up some of the code in core.
 * Add qfprom bindings.

Changes since RFC(https://lkml.org/lkml/2015/2/19/307)
 * Fix documentation and error checks in read/write spotted by Andrew Lunn
 * Kconfig fix suggested by Stephen Boyd.
 * Add module owner suggested by Stephen Boyd and others.
 * Fix unsafe handling of eeprom in unregister spotted by Russell and Mark 
Brown.
 * seperate bindings patch as suggested by Rob.
 * Add MAINTAINERS as suggested by Rob.
 * Added support to allow reading eeprom for things like serial number which
 * canbe scatters across.
 * Added eeprom data using reg property suggested by Sascha and Stephen.
 * Added non-DT support.
 * Move kerneldoc to the src files spotted by Mark Brown.
 * Remove local list and do eeprom lookup by using class_find_device()


Thanks,
srini

Maxime Ripard (1):
  eeprom: sunxi: Move the SID driver to the eeprom framework

Srinivas Kandagatla (8):
  regmap: Introduce regmap_get_max_register.
  regmap: Introduce regmap_get_reg_stride.
  eeprom: Add a simple EEPROM framework for eeprom providers
  eeprom: Add a simple EEPROM framework for eeprom consumers
  eeprom: Add bindings for simple eeprom framework
  eeprom: qfprom: Add Qualcomm QFPROM support.
  eeprom: qfprom: Add bindings for qfprom
  eeprom: Add to MAINTAINERS for eeprom framework

 Documentation/ABI/testing/sysfs-driver-sunxi-sid   |  22 -
 .../bindings/eeprom/allwinner,sunxi-sid.txt|  21 +
 .../devicetree/bindings/eeprom/eeprom.txt  |  70 +++
 .../devicetree/bindings/eeprom/qfprom.txt  |  23 +
 .../bindings/misc/allwinner,sunxi-sid.txt  |  17 -
 MAINTAINERS|   

Re: [PATCH v3 3/9] eeprom: Add a simple EEPROM framework for eeprom providers

2015-03-24 Thread Mark Brown
On Tue, Mar 24, 2015 at 10:30:08PM +, Srinivas Kandagatla wrote:

 +static ssize_t bin_attr_eeprom_write(struct file *filp, struct kobject *kobj,
 +  struct bin_attribute *attr,
 +  char *buf, loff_t offset, size_t count)
 +{
 + struct device *dev = container_of(kobj, struct device, kobj);
 + struct eeprom_device *eeprom = to_eeprom(dev);
 + int rc;
 +
 + if (offset  eeprom-size)
 + return -EINVAL;
 +
 + if (offset + count  eeprom-size)
 + count = eeprom-size - offset;
 +
 + rc = regmap_bulk_write(eeprom-regmap, offset,
 +buf, count/eeprom-stride);

Are you sure that this and the read interface should be using the bulk
interface and not the raw interface - do we want the byte swapping that
the bulk interface provides?

I'm also not entirely able to convince myself that the above error
checks and code line up with what I'd expect the userspace ABI to be, we
seem to be treating offset as both a byte offset into the data (which is
what I'd expect the userspace ABI to do) and a word based index into the
data (which is what the regmap API is doing).  For example with 16 bit
words offset 2 will start at the 5th byte of data but if userspace seeks
to offset 5 it will get the 11th byte and onwards.

The stride and the word size are separate, they will frequently line up
for memory mapped devices but typically won't for other devices.  I
think you need more data mangling to handle this robustly.


signature.asc
Description: Digital signature


Re: [PATCH v3 2/9] regmap: Introduce regmap_get_reg_stride.

2015-03-24 Thread Srinivas Kandagatla



On 24/03/15 22:37, Mark Brown wrote:

On Tue, Mar 24, 2015 at 10:30:00PM +, Srinivas Kandagatla wrote:


+ /* regmap_get_reg_stride(): Report the register address stride
+ *
+ * Report the register address stride, mainly intended to for use by
+ * generic infrastructure built on top of regmap.
+ */
+int regmap_get_reg_stride(struct regmap *map)


Please fix the indentation for the comment block and add kerneldoc for
the argument.  This is an exported function so it should also be /** not
/*


My bad.. I will fix it in next version.
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 1/9] regmap: Introduce regmap_get_max_register.

2015-03-24 Thread Joe Perches
On Tue, 2015-03-24 at 23:05 +, Srinivas Kandagatla wrote:
 On 24/03/15 22:36, Mark Brown wrote:
  +int regmap_get_max_register(struct regmap *map)
  +{
  +  return map-max_register ? : -EINVAL;
  +}
 
  Please write the logic out properly, don't abuse the ternery operator.
 Am happy to change it to your preference in next version, but this GNU 
 extensions widely used in the kernel
 
 $  grep -rR return.*? : ./linux | wc -l
 115

Double that when you add the ?: variants

$ git grep -E return.*\?\s*: | wc -l
253

There are ~530 uses like:

return foo ? foo :

--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 4/9] eeprom: Add a simple EEPROM framework for eeprom consumers

2015-03-24 Thread Srinivas Kandagatla
This patch adds just consumers part of the framework just to enable easy
review.

Up until now, EEPROM drivers were stored in drivers/misc, where they all had to
duplicate pretty much the same code to register a sysfs file, allow in-kernel
users to access the content of the devices they were driving, etc.

This was also a problem as far as other in-kernel users were involved, since
the solutions used were pretty much different from on driver to another, there
was a rather big abstraction leak.

This introduction of this framework aims at solving this. It also introduces DT
representation for consumer devices to go get the data they require (MAC
Addresses, SoC/Revision ID, part numbers, and so on) from the EEPROMs.

Having regmap interface to this framework would give much better
abstraction for eeproms on different buses.

Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
[Maxime Ripard: intial version of the framework]
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
 drivers/eeprom/core.c   | 304 
 include/linux/eeprom-consumer.h |  67 +
 2 files changed, 371 insertions(+)
 create mode 100644 include/linux/eeprom-consumer.h

diff --git a/drivers/eeprom/core.c b/drivers/eeprom/core.c
index 9fd556c..43d03ef 100644
--- a/drivers/eeprom/core.c
+++ b/drivers/eeprom/core.c
@@ -16,6 +16,7 @@
 
 #include linux/device.h
 #include linux/eeprom-provider.h
+#include linux/eeprom-consumer.h
 #include linux/export.h
 #include linux/fs.h
 #include linux/idr.h
@@ -37,6 +38,13 @@ struct eeprom_device {
int users;
 };
 
+struct eeprom_cell {
+   struct eeprom_device*eeprom;
+   int nblocks;
+   int size;
+   struct eeprom_block blocks[0];
+};
+
 static DEFINE_MUTEX(eeprom_mutex);
 static DEFINE_IDA(eeprom_ida);
 
@@ -125,6 +133,37 @@ static struct class eeprom_class = {
.dev_release= eeprom_release,
 };
 
+static int of_eeprom_match(struct device *dev, const void *eeprom_np)
+{
+   return dev-of_node == eeprom_np;
+}
+
+static struct eeprom_device *of_eeprom_find(struct device_node *eeprom_np)
+{
+   struct device *d;
+
+   if (!eeprom_np)
+   return NULL;
+
+   d = class_find_device(eeprom_class, NULL, eeprom_np, of_eeprom_match);
+
+   return d ? to_eeprom(d) : NULL;
+}
+
+static int eeprom_match(struct device *dev, const void *data)
+{
+   return !strcmp(dev_name(dev), (const char *)data);
+}
+
+static struct eeprom_device *eeprom_find(const char *name)
+{
+   struct device *d;
+
+   d = class_find_device(eeprom_class, NULL, (void *)name, eeprom_match);
+
+   return d ? to_eeprom(d) : NULL;
+}
+
 /**
  * eeprom_register(): Register a eeprom device for given eeprom.
  * Also creates an binary entry in /sys/class/eeprom/name-id/eeprom
@@ -208,6 +247,271 @@ int eeprom_unregister(struct eeprom_device *eeprom)
 }
 EXPORT_SYMBOL_GPL(eeprom_unregister);
 
+static int eeprom_cell_sanity_check(struct eeprom_cell *cell)
+{
+   struct eeprom_device *eeprom = cell-eeprom;
+   int i;
+
+   /* byte aligned, no need to check for stride sanity */
+   if (eeprom-stride == 1)
+   return 0;
+
+   for (i = 0; i  cell-nblocks; i++) {
+   if (!IS_ALIGNED(cell-blocks[i].offset, eeprom-stride) ||
+   !IS_ALIGNED(cell-blocks[i].count, eeprom-stride)) {
+   dev_err(eeprom-dev,
+   cell unaligned to eeprom stride %d\n,
+   eeprom-stride);
+   return -EINVAL;
+   }
+   }
+
+   return 0;
+}
+
+static struct eeprom_cell *__eeprom_cell_get(struct device_node *cell_np,
+const char *ename,
+struct eeprom_block *blocks,
+int nblocks)
+{
+   struct eeprom_cell *cell;
+   struct eeprom_device *eeprom = NULL;
+   struct property *prop;
+   const __be32 *vp;
+   u32 pv;
+   int i, rval;
+
+   mutex_lock(eeprom_mutex);
+
+   eeprom = cell_np ? of_eeprom_find(cell_np-parent) : eeprom_find(ename);
+   if (!eeprom) {
+   mutex_unlock(eeprom_mutex);
+   return ERR_PTR(-EPROBE_DEFER);
+   }
+
+   eeprom-users++;
+   mutex_unlock(eeprom_mutex);
+
+   if (!try_module_get(eeprom-owner)) {
+   dev_err(eeprom-dev,
+   could not increase module refcount for cell %s\n,
+   ename);
+   rval = -EINVAL;
+   goto err_mod;
+   }
+
+   if (cell_np)
+   nblocks = of_property_count_u32_elems(cell_np, reg) / 2;
+
+   cell = kzalloc(sizeof(*cell) + nblocks * sizeof(*blocks), GFP_KERNEL);
+   if (!cell) {
+   rval = -ENOMEM;
+   goto 

[PATCH v3 6/9] eeprom: sunxi: Move the SID driver to the eeprom framework

2015-03-24 Thread Srinivas Kandagatla
From: Maxime Ripard maxime.rip...@free-electrons.com

Now that we have the EEPROM framework, we can consolidate the common driver
code. Move the driver to the framework, and hopefully, it will fix the sysfs
file creation race.

Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
[srinivas.kandagatla: Moved to regmap based EEPROM framework]
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
 Documentation/ABI/testing/sysfs-driver-sunxi-sid   |  22 ---
 .../bindings/eeprom/allwinner,sunxi-sid.txt|  21 +++
 .../bindings/misc/allwinner,sunxi-sid.txt  |  17 ---
 drivers/eeprom/Kconfig |  15 ++
 drivers/eeprom/Makefile|   4 +
 drivers/eeprom/sunxi-sid.c | 136 ++
 drivers/misc/eeprom/Kconfig|  13 --
 drivers/misc/eeprom/Makefile   |   1 -
 drivers/misc/eeprom/sunxi_sid.c| 156 -
 9 files changed, 176 insertions(+), 209 deletions(-)
 delete mode 100644 Documentation/ABI/testing/sysfs-driver-sunxi-sid
 create mode 100644 
Documentation/devicetree/bindings/eeprom/allwinner,sunxi-sid.txt
 delete mode 100644 
Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
 create mode 100644 drivers/eeprom/sunxi-sid.c
 delete mode 100644 drivers/misc/eeprom/sunxi_sid.c

diff --git a/Documentation/ABI/testing/sysfs-driver-sunxi-sid 
b/Documentation/ABI/testing/sysfs-driver-sunxi-sid
deleted file mode 100644
index ffb9536..000
--- a/Documentation/ABI/testing/sysfs-driver-sunxi-sid
+++ /dev/null
@@ -1,22 +0,0 @@
-What:  /sys/devices/*/our-device/eeprom
-Date:  August 2013
-Contact:   Oliver Schinagl oli...@schinagl.nl
-Description:   read-only access to the SID (Security-ID) on current
-   A-series SoC's from Allwinner. Currently supports A10, A10s, A13
-   and A20 CPU's. The earlier A1x series of SoCs exports 16 bytes,
-   whereas the newer A20 SoC exposes 512 bytes split into sections.
-   Besides the 16 bytes of SID, there's also an SJTAG area,
-   HDMI-HDCP key and some custom keys. Below a quick overview, for
-   details see the user manual:
-   0x000  128 bit root-key (sun[457]i)
-   0x010  128 bit boot-key (sun7i)
-   0x020   64 bit security-jtag-key (sun7i)
-   0x028   16 bit key configuration (sun7i)
-   0x02b   16 bit custom-vendor-key (sun7i)
-   0x02c  320 bit low general key (sun7i)
-   0x040   32 bit read-control access (sun7i)
-   0x064  224 bit low general key (sun7i)
-   0x080 2304 bit HDCP-key (sun7i)
-   0x1a0  768 bit high general key (sun7i)
-Users: any user space application which wants to read the SID on
-   Allwinner's A-series of CPU's.
diff --git a/Documentation/devicetree/bindings/eeprom/allwinner,sunxi-sid.txt 
b/Documentation/devicetree/bindings/eeprom/allwinner,sunxi-sid.txt
new file mode 100644
index 000..cceaaf6
--- /dev/null
+++ b/Documentation/devicetree/bindings/eeprom/allwinner,sunxi-sid.txt
@@ -0,0 +1,21 @@
+Allwinner sunxi-sid
+
+Required properties:
+- compatible: allwinner,sun4i-a10-sid or allwinner,sun7i-a20-sid
+- reg: Should contain registers location and length
+
+= Data cells =
+Are child nodes of qfprom, bindings of which as described in
+bindings/eeprom/eeprom.txt
+
+Example for sun4i:
+   sid@01c23800 {
+   compatible = allwinner,sun4i-a10-sid;
+   reg = 0x01c23800 0x10
+   };
+
+Example for sun7i:
+   sid@01c23800 {
+   compatible = allwinner,sun7i-a20-sid;
+   reg = 0x01c23800 0x200
+   };
diff --git a/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt 
b/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
deleted file mode 100644
index fabdf64..000
--- a/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-Allwinner sunxi-sid
-
-Required properties:
-- compatible: allwinner,sun4i-a10-sid or allwinner,sun7i-a20-sid
-- reg: Should contain registers location and length
-
-Example for sun4i:
-   sid@01c23800 {
-   compatible = allwinner,sun4i-a10-sid;
-   reg = 0x01c23800 0x10
-   };
-
-Example for sun7i:
-   sid@01c23800 {
-   compatible = allwinner,sun7i-a20-sid;
-   reg = 0x01c23800 0x200
-   };
diff --git a/drivers/eeprom/Kconfig b/drivers/eeprom/Kconfig
index 21e1847..ad396c1 100644
--- a/drivers/eeprom/Kconfig
+++ b/drivers/eeprom/Kconfig
@@ -9,3 +9,18 @@ menuconfig EEPROM
  from both the Linux Kernel and the userspace.
 
  If unsure, say no.
+
+if EEPROM
+
+config EEPROM_SUNXI_SID
+   tristate Allwinner SoCs SID support
+   depends on ARCH_SUNXI
+   select REGMAP_MMIO
+   help
+ 

[PATCH v3 7/9] eeprom: qfprom: Add Qualcomm QFPROM support.

2015-03-24 Thread Srinivas Kandagatla
This patch adds QFPROM support driver which is used by other drivers
like thermal sensor and cpufreq.

On MSM parts there are some efuses (called qfprom) these fuses store things like
calibration data, speed bins.. etc. Drivers like cpufreq, thermal sensors would
read out this data for configuring the driver.

Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
 drivers/eeprom/Kconfig  | 11 +++
 drivers/eeprom/Makefile |  2 ++
 drivers/eeprom/qfprom.c | 87 +
 3 files changed, 100 insertions(+)
 create mode 100644 drivers/eeprom/qfprom.c

diff --git a/drivers/eeprom/Kconfig b/drivers/eeprom/Kconfig
index ad396c1..8fc14d3 100644
--- a/drivers/eeprom/Kconfig
+++ b/drivers/eeprom/Kconfig
@@ -23,4 +23,15 @@ config EEPROM_SUNXI_SID
  This driver can also be built as a module. If so, the module
  will be called eeprom-sunxi-sid.
 
+config QCOM_QFPROM
+   tristate QCOM QFPROM Support
+   depends on ARCH_QCOM
+   select REGMAP_MMIO
+   help
+ Say y here to enable QFPROM support. The QFPROM provides access
+ functions for QFPROM data to rest of the drivers via eeprom interface.
+
+ This driver can also be built as a module. If so, the module
+ will be called eeprom-qfprom.
+
 endif
diff --git a/drivers/eeprom/Makefile b/drivers/eeprom/Makefile
index 184aa53..4ac437e 100644
--- a/drivers/eeprom/Makefile
+++ b/drivers/eeprom/Makefile
@@ -8,3 +8,5 @@ eeprom_core-y   := core.o
 # Devices
 obj-$(CONFIG_EEPROM_SUNXI_SID) += eeprom-sunxi-sid.o
 eeprom-sunxi-sid-y := sunxi-sid.o
+obj-$(CONFIG_QCOM_QFPROM)  += eeprom_qfprom.o
+eeprom_qfprom-y:= qfprom.o
diff --git a/drivers/eeprom/qfprom.c b/drivers/eeprom/qfprom.c
new file mode 100644
index 000..8d5d4d8
--- /dev/null
+++ b/drivers/eeprom/qfprom.c
@@ -0,0 +1,87 @@
+/*
+ * Copyright (C) 2015 Srinivas Kandagatla srinivas.kandaga...@linaro.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 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/device.h
+#include linux/module.h
+#include linux/err.h
+#include linux/of.h
+#include linux/regmap.h
+#include linux/platform_device.h
+#include linux/eeprom-provider.h
+
+static struct regmap_config qfprom_regmap_config = {
+   .reg_bits = 32,
+   .val_bits = 8,
+   .reg_stride = 1,
+};
+
+static struct eeprom_config econfig = {
+   .name = qfprom,
+};
+
+static int qfprom_remove(struct platform_device *pdev)
+{
+   struct eeprom_device *eeprom = platform_get_drvdata(pdev);
+
+   return eeprom_unregister(eeprom);
+}
+
+static int qfprom_probe(struct platform_device *pdev)
+{
+   struct resource *res;
+   void __iomem *base;
+   struct device *dev = pdev-dev;
+   struct eeprom_device *eeprom;
+   struct regmap *regmap;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(base))
+   return PTR_ERR(base);
+
+   qfprom_regmap_config.max_register = resource_size(res) - 1;
+
+   regmap = devm_regmap_init_mmio(dev, base,
+  qfprom_regmap_config);
+   if (IS_ERR(regmap)) {
+   dev_err(dev, regmap init failed\n);
+   return PTR_ERR(regmap);
+   }
+   econfig.owner = THIS_MODULE;
+   econfig.dev = dev;
+   eeprom = eeprom_register(econfig);
+   if (IS_ERR(eeprom))
+   return PTR_ERR(eeprom);
+
+   platform_set_drvdata(pdev, eeprom);
+   return 0;
+}
+
+static const struct of_device_id qfprom_of_match[] = {
+   { .compatible = qcom,qfprom},
+   {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, qfprom_of_match);
+
+static struct platform_driver qfprom_driver = {
+   .probe = qfprom_probe,
+   .remove = qfprom_remove,
+   .driver = {
+   .name = qcom,qfprom,
+   .of_match_table = qfprom_of_match,
+   },
+};
+module_platform_driver(qfprom_driver);
+MODULE_AUTHOR(Srinivas Kandagatla srinivas.kandaga...@linaro.org);
+MODULE_DESCRIPTION(Qualcomm QFPROM driver);
+MODULE_LICENSE(GPL v2);
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 8/9] eeprom: qfprom: Add bindings for qfprom

2015-03-24 Thread Srinivas Kandagatla
This patch adds bindings for qfprom found in QCOM SOCs. QFPROM driver
is based on simple eeprom framework.

Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
 .../devicetree/bindings/eeprom/qfprom.txt  | 23 ++
 1 file changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/eeprom/qfprom.txt

diff --git a/Documentation/devicetree/bindings/eeprom/qfprom.txt 
b/Documentation/devicetree/bindings/eeprom/qfprom.txt
new file mode 100644
index 000..d5baed6
--- /dev/null
+++ b/Documentation/devicetree/bindings/eeprom/qfprom.txt
@@ -0,0 +1,23 @@
+= Qualcomm QFPROM device tree bindings =
+
+This binding is intended to represent QFPROM which is found in most QCOM SOCs.
+
+Required properties:
+- compatible: should be qcom,qfprom
+- reg: Should contain registers location and length
+
+= Data cells =
+Are child nodes of qfprom, bindings of which as described in
+bindings/eeprom/eeprom.txt
+
+Example:
+
+   qfprom: qfprom@0070 {
+   compatible  = qcom,qfprom;
+   reg = 0x0070 0x1000;
+   ...
+   /* Data cells */
+   tsens_calibration: calib@404 {
+   reg = 0x404 0x10;
+   };
+   };
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 5/9] eeprom: Add bindings for simple eeprom framework

2015-03-24 Thread Srinivas Kandagatla
This patch adds bindings for simple eeprom framework which allows eeprom
consumers to talk to eeprom providers to get access to eeprom cell data.

Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
[Maxime Ripard: intial version of eeprom framework]
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
 .../devicetree/bindings/eeprom/eeprom.txt  | 70 ++
 1 file changed, 70 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/eeprom/eeprom.txt

diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt 
b/Documentation/devicetree/bindings/eeprom/eeprom.txt
new file mode 100644
index 000..8348d18
--- /dev/null
+++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
@@ -0,0 +1,70 @@
+= EEPROM Data Device Tree Bindings =
+
+This binding is intended to represent the location of hardware
+configuration data stored in EEPROMs.
+
+On a significant proportion of boards, the manufacturer has stored
+some data on an EEPROM-like device, for the OS to be able to retrieve
+these information and act upon it. Obviously, the OS has to know
+about where to retrieve these data from, and where they are stored on
+the storage device.
+
+This document is here to document this.
+
+= Data providers =
+Contains bindings specific to provider drivers and data cells as children
+to this node.
+
+= Data cells =
+These are the child nodes of the provider which contain data cell
+information like offset and size in eeprom provider.
+
+Required properties:
+reg:   specifies the offset in byte within that storage device, and the length
+   in bytes of the data we care about.
+   There could be more then one offset-length pairs in this property.
+
+Optional properties:
+As required by specific data parsers/interpreters.
+
+For example:
+
+   /* Provider */
+   qfprom: qfprom@0070 {
+   compatible  = qcom,qfprom;
+   reg = 0x0070 0x1000;
+   ...
+
+   /* Data cells */
+   tsens_calibration: calib@404 {
+   reg = 0x404 0x10;
+   };
+
+   serial_number: sn {
+   reg = 0x104 0x4, 0x204 0x4, 0x30c 0x4;
+
+   };
+   ...
+   };
+
+= Data consumers =
+Are device nodes which consume eeprom data cells.
+
+Required properties:
+
+eeproms: List of phandle and data cell the device might be interested in.
+
+Optional properties:
+
+eeprom-names: List of data cell name strings sorted in the same order
+ as the eeproms property. Consumers drivers will use
+ eeprom-names to differentiate between multiple cells,
+ and hence being able to know what these cells are for.
+
+For example:
+
+   tsens {
+   ...
+   eeproms = tsens_calibration;
+   eeprom-names = calibration;
+   };
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 1/9] regmap: Introduce regmap_get_max_register.

2015-03-24 Thread Mark Brown
On Tue, Mar 24, 2015 at 10:29:39PM +, Srinivas Kandagatla wrote:

 This patch introduces regmap_get_max_register() function which would be
 used by the infrastructures like eeprom framework built on top of
 regmap.

In what way would it be used?

 +int regmap_get_max_register(struct regmap *map)
 +{
 + return map-max_register ? : -EINVAL;
 +}

Please write the logic out properly, don't abuse the ternery operator.


signature.asc
Description: Digital signature


[PATCH v3 2/9] regmap: Introduce regmap_get_reg_stride.

2015-03-24 Thread Srinivas Kandagatla
This patch introduces regmap_get_reg_stride() function which would
be used by the infrastructures like eeprom framework built on top of
regmap. Mostly this function would be used for sanity checks on inputs
within such infrastructure.

Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
 drivers/base/regmap/regmap.c | 11 +++
 include/linux/regmap.h   |  7 +++
 2 files changed, 18 insertions(+)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 6fd234b..44d3d94 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -2628,6 +2628,17 @@ int regmap_get_max_register(struct regmap *map)
 }
 EXPORT_SYMBOL_GPL(regmap_get_max_register);
 
+ /* regmap_get_reg_stride(): Report the register address stride
+ *
+ * Report the register address stride, mainly intended to for use by
+ * generic infrastructure built on top of regmap.
+ */
+int regmap_get_reg_stride(struct regmap *map)
+{
+   return map-reg_stride;
+}
+EXPORT_SYMBOL_GPL(regmap_get_reg_stride);
+
 int regmap_parse_val(struct regmap *map, const void *buf,
unsigned int *val)
 {
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index c46dbf3..b58067c 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -434,6 +434,7 @@ int regmap_update_bits_check_async(struct regmap *map, 
unsigned int reg,
   bool *change);
 int regmap_get_val_bytes(struct regmap *map);
 int regmap_get_max_register(struct regmap *map);
+int regmap_get_reg_stride(struct regmap *map);
 int regmap_async_complete(struct regmap *map);
 bool regmap_can_raw_write(struct regmap *map);
 
@@ -683,6 +684,12 @@ static inline int regmap_get_max_register(struct regmap 
*map)
return -EINVAL;
 }
 
+static inline int regmap_get_reg_stride(struct regmap *map)
+{
+   WARN_ONCE(1, regmap API is disabled);
+   return -EINVAL;
+}
+
 static inline int regcache_sync(struct regmap *map)
 {
WARN_ONCE(1, regmap API is disabled);
-- 
1.9.1

--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 8/9] eeprom: qfprom: Add bindings for qfprom

2015-03-24 Thread Bjorn Andersson
On Tue, Mar 24, 2015 at 11:31 PM, Srinivas Kandagatla
srinivas.kandaga...@linaro.org wrote:
 This patch adds bindings for qfprom found in QCOM SOCs. QFPROM driver
 is based on simple eeprom framework.

 Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
 ---
  .../devicetree/bindings/eeprom/qfprom.txt  | 23 
 ++
  1 file changed, 23 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/eeprom/qfprom.txt

 diff --git a/Documentation/devicetree/bindings/eeprom/qfprom.txt 
 b/Documentation/devicetree/bindings/eeprom/qfprom.txt
 new file mode 100644
 index 000..d5baed6
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/eeprom/qfprom.txt
 @@ -0,0 +1,23 @@
 += Qualcomm QFPROM device tree bindings =
 +
 +This binding is intended to represent QFPROM which is found in most QCOM 
 SOCs.
 +
 +Required properties:
 +- compatible: should be qcom,qfprom
 +- reg: Should contain registers location and length
 +
 += Data cells =
 +Are child nodes of qfprom, bindings of which as described in
 +bindings/eeprom/eeprom.txt
 +
 +Example:
 +
 +   qfprom: qfprom@0070 {
 +   compatible  = qcom,qfprom;
 +   reg = 0x0070 0x1000;

The qfprom block starts at 0x70 and is 0x8000 long.

The registers at the beginning of this block are raw R/W fuse bits and
should not be read directly. Instead there is an ecc corrected shadow
copy of these registers at 0x4000.

 +   ...
 +   /* Data cells */
 +   tsens_calibration: calib@404 {
 +   reg = 0x404 0x10;
 +   };
 +   };

Regards,
Bjorn
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] regulator: Defer lookup of supply to regulator_get

2015-03-24 Thread Bjorn Andersson
Instead of resolving regulator supplies during registration move this to
the time of a consumer retrieving a handle. The benefit is that it's
possible for one driver to register regulators with internal
dependencies out of order.

Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
 drivers/regulator/core.c | 92 
 include/linux/regulator/driver.h |  1 +
 2 files changed, 57 insertions(+), 36 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index f245214..52ddb73 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1325,6 +1325,54 @@ static struct regulator_dev *regulator_dev_lookup(struct 
device *dev,
return NULL;
 }
 
+static int regulator_resolve_supply(struct regulator_dev *rdev)
+{
+   struct regulator_dev *r;
+   struct device *dev = rdev-dev.parent;
+   int ret;
+
+   /* No supply to resovle? */
+   if (!rdev-supply_name)
+   return 0;
+
+   /* Supply already resolved? */
+   if (rdev-supply)
+   return 0;
+
+   r = regulator_dev_lookup(dev, rdev-supply_name, ret);
+   if (ret == -ENODEV) {
+   /*
+* No supply was specified for this regulator and
+* there will never be one.
+*/
+   return 0;
+   }
+
+   if (!r) {
+   dev_err(dev, Failed to resolve %s-supply for %s\n,
+   rdev-supply_name, rdev-desc-name);
+   return -EPROBE_DEFER;
+   }
+
+   /* Recursively resolve the supply of the supply */
+   ret = regulator_resolve_supply(r);
+   if (ret  0)
+   return ret;
+
+   ret = set_supply(rdev, r);
+   if (ret  0)
+   return ret;
+
+   /* Cascade always-on state to supply */
+   if (_regulator_is_enabled(rdev)) {
+   ret = regulator_enable(rdev-supply);
+   if (ret  0)
+   return ret;
+   }
+
+   return 0;
+}
+
 /* Internal regulator request function */
 static struct regulator *_regulator_get(struct device *dev, const char *id,
bool exclusive, bool allow_dummy)
@@ -1394,6 +1442,12 @@ found:
goto out;
}
 
+   ret = regulator_resolve_supply(rdev);
+   if (ret  0) {
+   regulator = ERR_PTR(ret);
+   goto out;
+   }
+
if (!try_module_get(rdev-owner))
goto out;
 
@@ -3545,7 +3599,6 @@ regulator_register(const struct regulator_desc 
*regulator_desc,
struct regulator_dev *rdev;
struct device *dev;
int ret, i;
-   const char *supply = NULL;
 
if (regulator_desc == NULL || cfg == NULL)
return ERR_PTR(-EINVAL);
@@ -3659,41 +3712,10 @@ regulator_register(const struct regulator_desc 
*regulator_desc,
goto scrub;
 
if (init_data  init_data-supply_regulator)
-   supply = init_data-supply_regulator;
+   rdev-supply_name = init_data-supply_regulator;
else if (regulator_desc-supply_name)
-   supply = regulator_desc-supply_name;
-
-   if (supply) {
-   struct regulator_dev *r;
-
-   r = regulator_dev_lookup(dev, supply, ret);
+   rdev-supply_name = regulator_desc-supply_name;
 
-   if (ret == -ENODEV) {
-   /*
-* No supply was specified for this regulator and
-* there will never be one.
-*/
-   ret = 0;
-   goto add_dev;
-   } else if (!r) {
-   dev_err(dev, Failed to find supply %s\n, supply);
-   ret = -EPROBE_DEFER;
-   goto scrub;
-   }
-
-   ret = set_supply(rdev, r);
-   if (ret  0)
-   goto scrub;
-
-   /* Enable supply if rail is enabled */
-   if (_regulator_is_enabled(rdev)) {
-   ret = regulator_enable(rdev-supply);
-   if (ret  0)
-   goto scrub;
-   }
-   }
-
-add_dev:
/* add consumers devices */
if (init_data) {
for (i = 0; i  init_data-num_consumer_supplies; i++) {
@@ -3720,8 +3742,6 @@ unset_supplies:
unset_regulator_supplies(rdev);
 
 scrub:
-   if (rdev-supply)
-   _regulator_put(rdev-supply);
regulator_ena_gpio_free(rdev);
kfree(rdev-constraints);
 wash:
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index 0f86a182..a15c59d 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -371,6 +371,7 @@ struct regulator_dev {
struct device dev;
struct regulation_constraints *constraints;
struct 

Re: [PATCH v2 2/2] drm/msm/mdp4: Support NV12MT format in mdp4

2015-03-24 Thread Seung-Woo Kim
Hello,

On 2015년 03월 25일 03:32, Rob Clark wrote:
 On Mon, Mar 16, 2015 at 4:05 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Fri, Mar 13, 2015 at 03:12:10PM -0400, Stephane Viau wrote:
 From: Beeresh Gopal gbeer...@codeaurora.org

 Using fb modifier flag, support NV12MT format in MDP4.

 v2:
 - rework the modifier's description [Daniel Vetter's comment]
 - drop .set_mode_config() callback [Rob Clark's comment]

 Signed-off-by: Beeresh Gopal gbeer...@codeaurora.org
 Signed-off-by: Stephane Viau sv...@codeaurora.org
 ---
  drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c   |  2 ++
  drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 22 ++
  include/uapi/drm/drm_fourcc.h |  5 +
  3 files changed, 29 insertions(+)


snip.

 diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
 index 188e61f..2ff79cb 100644
 --- a/include/uapi/drm/drm_fourcc.h
 +++ b/include/uapi/drm/drm_fourcc.h
 @@ -161,4 +161,9 @@
   * authoritative source for all of these.
   */

 +/* Samsung framebuffer modifiers */
 +
 +/* Tiled: 64x32 pixel macroblocks */

 Since this seems shared by a lot of vendors (I still don't believe Samsung
 invented this really ...) can you please describe this thing a bit in more
 detail? Somewhat important how macroblocks are laid out and pixels within.
 Also with a planar format like NV12 pixel is a bit unclear, e.g. what
 happens if you throw 10bit plane formats at this? So maybe also add a note
 that for now this is only used together with NV12T.
 
 + a couple folks from Samsung, since I expect they want this for
 exynos as well (and might be able to help with the description)

Yes, I have a plan to apply fb_modifier for exynos with kms interface of
hdmi.

 
 vl4 also has this format, but last I looked was rather light on the details.

I am not sure msm mdp uses exactly same format with exynos, but anyway
v4l2 NV12MT format was introduced for exynos hw video codec.

macro blocks for the format is laid z-order and each pixel data in each
macro block is just normal NV12 style.

I think Marek and Sylwester can help understanding the format.

 
 http://linuxtv.org/downloads/v4l-dvb-apis/re31.html
 
 I know up in userspace, GStreamer seems to have some support for this format:
 
 http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=f8d3b9b4fcc5e08b771314fa95e9ed8f750b54e6
 
 Then there's the question of validating the input - stride should probably
 be a full multiple of the macroblock size. Since this is a shared format
 imo this kind of checking should be done in drm core.
 
 afaiu, stride (and maybe even width?) should be a multiple of the
 block size (but height does not)
 
 BR,
 -R
 
 
 -Daniel


 +#define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE fourcc_mod_code(SAMSUNG, 1)
 +
  #endif /* DRM_FOURCC_H */
 --
 Qualcomm Innovation Center, Inc.

 The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, 
 a Linux Foundation Collaborative Project


 --
 Daniel Vetter
 Software Engineer, Intel Corporation
 +41 (0) 79 365 57 48 - http://blog.ffwll.ch
 

-- 
Seung-Woo Kim
Samsung Software RD Center
--

--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] regulator: Defer lookup of supply to regulator_get

2015-03-24 Thread Mark Brown
On Tue, Mar 24, 2015 at 06:56:05PM -0700, Bjorn Andersson wrote:
 Instead of resolving regulator supplies during registration move this to
 the time of a consumer retrieving a handle. The benefit is that it's
 possible for one driver to register regulators with internal
 dependencies out of order.

This looks basically sensible (as we discussed in person) - I'd like to
poke at this on some systems I've got back home to make sure I'm happy
with the debugging output and so on but I'm not expecting any problems.


signature.asc
Description: Digital signature


Re: [PATCH v2 1/7] eeprom: Add a simple EEPROM framework for eeprom providers

2015-03-24 Thread Srinivas Kandagatla



On 23/03/15 22:05, Srinivas Kandagatla wrote:



On 23/03/15 21:09, Mark Brown wrote:

On Fri, Mar 13, 2015 at 09:50:14AM +, Srinivas Kandagatla wrote:

A couple of *very* minor points below, otherwise this looks OK to me.


Thankyou for the review.


+struct eeprom_device *eeprom_register(struct eeprom_config *config)
+{
+struct eeprom_device *eeprom;
+int rval;
+
+if (!config-regmap || !config-size) {
+dev_err(config-dev, Regmap not found\n);
+return ERR_PTR(-EINVAL);
+}


You have a struct device in the config and the regmap API has
dev_get_regmap() which for most devices that don't have multiple regmaps
will give the right regmap.  It would be nice to support this as a
convenience for users.

Yes, sure that makes sense, I will give it a try.

I did try your suggestion, by which I could remove the regmap from 
config. One thing I did not like was eeprom-core getting size/stride 
info directly from providers and regmap from regmap apis. I was 
wondering if we could take a step further and introduce new regmap 
helpers like


regmap_get_size(regmap)
regmap_get_stride(regmap)

Which would be give eeprom-core the size and stride info, doing this way 
would cut down regmap related things from eeprom_config structure to 
minimal and also the source of information would come from just regmap apis.



--srini




+eeprom = kzalloc(sizeof(*eeprom), GFP_KERNEL);
+if (!eeprom)
+return ERR_PTR(-ENOMEM);


...


+rval = device_add(eeprom-dev);
+if (rval)
+return ERR_PTR(rval);


Don't you need a kfree() if device_add() fails?

I will fix it in next version.

--srini



--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 2/2] drm/msm/mdp4: Support NV12MT format in mdp4

2015-03-24 Thread Rob Clark
On Mon, Mar 16, 2015 at 4:05 AM, Daniel Vetter dan...@ffwll.ch wrote:
 On Fri, Mar 13, 2015 at 03:12:10PM -0400, Stephane Viau wrote:
 From: Beeresh Gopal gbeer...@codeaurora.org

 Using fb modifier flag, support NV12MT format in MDP4.

 v2:
 - rework the modifier's description [Daniel Vetter's comment]
 - drop .set_mode_config() callback [Rob Clark's comment]

 Signed-off-by: Beeresh Gopal gbeer...@codeaurora.org
 Signed-off-by: Stephane Viau sv...@codeaurora.org
 ---
  drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c   |  2 ++
  drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 22 ++
  include/uapi/drm/drm_fourcc.h |  5 +
  3 files changed, 29 insertions(+)

 diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c 
 b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
 index d81e19d..6387881 100644
 --- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
 +++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
 @@ -119,6 +119,8 @@ static int mdp4_hw_init(struct msm_kms *kms)
   if (mdp4_kms-rev  1)
   mdp4_write(mdp4_kms, REG_MDP4_RESET_STATUS, 1);

 + dev-mode_config.allow_fb_modifiers = true;
 +
  out:
   pm_runtime_put_sync(dev-dev);

 diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c 
 b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
 index cde2500..2c2d6a5 100644
 --- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
 +++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c
 @@ -33,6 +33,21 @@ struct mdp4_plane {
  };
  #define to_mdp4_plane(x) container_of(x, struct mdp4_plane, base)

 +/* MDP format helper functions */
 +static inline
 +enum mdp4_frame_format mdp4_get_frame_format(struct drm_framebuffer *fb)
 +{
 + bool is_tile = false;
 +
 + if (fb-modifier[1] == DRM_FORMAT_MOD_SAMSUNG_64_32_TILE)
 + is_tile = true;
 +
 + if (fb-pixel_format == DRM_FORMAT_NV12  is_tile)
 + return FRAME_TILE_YCBCR_420;
 +
 + return FRAME_LINEAR;
 +}
 +
  static void mdp4_plane_set_scanout(struct drm_plane *plane,
   struct drm_framebuffer *fb);
  static int mdp4_plane_mode_set(struct drm_plane *plane,
 @@ -203,6 +218,7 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
   uint32_t op_mode = 0;
   uint32_t phasex_step = MDP4_VG_PHASE_STEP_DEFAULT;
   uint32_t phasey_step = MDP4_VG_PHASE_STEP_DEFAULT;
 + enum mdp4_frame_format frame_type = mdp4_get_frame_format(fb);

   if (!(crtc  fb)) {
   DBG(%s: disabled!, mdp4_plane-name);
 @@ -302,6 +318,7 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
   MDP4_PIPE_SRC_FORMAT_UNPACK_COUNT(format-unpack_count 
 - 1) |
   MDP4_PIPE_SRC_FORMAT_FETCH_PLANES(format-fetch_type) |
   
 MDP4_PIPE_SRC_FORMAT_CHROMA_SAMP(format-chroma_sample) |
 + MDP4_PIPE_SRC_FORMAT_FRAME_FORMAT(frame_type) |
   COND(format-unpack_tight, 
 MDP4_PIPE_SRC_FORMAT_UNPACK_TIGHT));

   mdp4_write(mdp4_kms, REG_MDP4_PIPE_SRC_UNPACK(pipe),
 @@ -322,6 +339,11 @@ static int mdp4_plane_mode_set(struct drm_plane *plane,
   mdp4_write(mdp4_kms, REG_MDP4_PIPE_PHASEX_STEP(pipe), phasex_step);
   mdp4_write(mdp4_kms, REG_MDP4_PIPE_PHASEY_STEP(pipe), phasey_step);

 + if (frame_type != FRAME_LINEAR)
 + mdp4_write(mdp4_kms, REG_MDP4_PIPE_SSTILE_FRAME_SIZE(pipe),
 + MDP4_PIPE_SSTILE_FRAME_SIZE_WIDTH(src_w) |
 + MDP4_PIPE_SSTILE_FRAME_SIZE_HEIGHT(src_h));
 +
   return 0;
  }

 diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
 index 188e61f..2ff79cb 100644
 --- a/include/uapi/drm/drm_fourcc.h
 +++ b/include/uapi/drm/drm_fourcc.h
 @@ -161,4 +161,9 @@
   * authoritative source for all of these.
   */

 +/* Samsung framebuffer modifiers */
 +
 +/* Tiled: 64x32 pixel macroblocks */

 Since this seems shared by a lot of vendors (I still don't believe Samsung
 invented this really ...) can you please describe this thing a bit in more
 detail? Somewhat important how macroblocks are laid out and pixels within.
 Also with a planar format like NV12 pixel is a bit unclear, e.g. what
 happens if you throw 10bit plane formats at this? So maybe also add a note
 that for now this is only used together with NV12T.

+ a couple folks from Samsung, since I expect they want this for
exynos as well (and might be able to help with the description)

vl4 also has this format, but last I looked was rather light on the details.

http://linuxtv.org/downloads/v4l-dvb-apis/re31.html

I know up in userspace, GStreamer seems to have some support for this format:

http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/?id=f8d3b9b4fcc5e08b771314fa95e9ed8f750b54e6

 Then there's the question of validating the input - stride should probably
 be a full multiple of the macroblock size. Since this is a shared format
 imo this kind of checking should be done in drm core.

afaiu, stride (and maybe even width?) should be a multiple of the
block 

Re: [PATCH v2 1/7] eeprom: Add a simple EEPROM framework for eeprom providers

2015-03-24 Thread Srinivas Kandagatla



On 24/03/15 17:23, Mark Brown wrote:

On Tue, Mar 24, 2015 at 09:18:14AM +, Srinivas Kandagatla wrote:


I did try your suggestion, by which I could remove the regmap from config.
One thing I did not like was eeprom-core getting size/stride info directly
from providers and regmap from regmap apis. I was wondering if we could take
a step further and introduce new regmap helpers like



regmap_get_size(regmap)


This is already there.
Sorry, I can't see any such api atleast in v4.0-rc5 and linux-next? Are 
you referring to another api which does the same job?





regmap_get_stride(regmap)



Which would be give eeprom-core the size and stride info, doing this way
would cut down regmap related things from eeprom_config structure to minimal
and also the source of information would come from just regmap apis.


Documentation/SubmittingPatches...

Am not sure what you meant here, Am guessing that you asked me to keep 
the respective maintainers in the loop and follow the guide, when I 
resend the patch?


--srini
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 0/2] Qualcomm PM8941 power key driver

2015-03-24 Thread Dmitry Torokhov
On Fri, Mar 20, 2015 at 02:54:33AM +0100, Bjorn Andersson wrote:
 On Mon, Feb 16, 2015 at 10:55 AM, Ivan T. Ivanov iiva...@mm-sol.com wrote:
 
  On Fri, 2015-01-23 at 16:19 -0800, Bjorn Andersson wrote:
  These patches add dt bindings and a device driver for the power key block 
  in
  the Qualcomm PM8941 pmic.
 
  Changes since v1:
   * Use a reboot_notifier to set power off/reboot mode
   * Use irq flags from devicetree
   * Some style fixes
 
  Courtney Cavin (2):
input: Add Qualcomm PM8941 power key driver
input: pm8941-pwrkey: Add DT binding documentation
 
  Tested-by: Ivan T. Ivanov iiva...@mm-sol.com
 
 
 Thanks for your testing Ivan.
 
 Dmitry, can you apply this? (It still applies cleanly to linux-next)
 

Queued for 4.1, thank you.

-- 
Dmitry
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] drm/msm: Refactor msm drm driver by introducing msm_drm_sub_dev

2015-03-24 Thread jilaiw
 On Tue, Mar 24, 2015 at 11:18 AM,  jil...@codeaurora.org wrote:

 On Thu, Mar 12, 2015 at 4:48 PM, Jilai Wang jil...@codeaurora.org
 wrote:
 Introduce msm_drm_sub_dev for each mdp interface component such as
 HDMI/eDP/DSI to contain common information shared with MDP.

 Signed-off-by: Jilai Wang jil...@codeaurora.org
 ---
  drivers/gpu/drm/msm/edp/edp.c   | 18 +--
  drivers/gpu/drm/msm/edp/edp.h   |  1 +
  drivers/gpu/drm/msm/hdmi/hdmi.c | 22 ++---
  drivers/gpu/drm/msm/hdmi/hdmi.h |  1 +
  drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c |  3 +-
  drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 56
 -
  drivers/gpu/drm/msm/msm_drv.h   | 23 +-
  7 files changed, 80 insertions(+), 44 deletions(-)

 So a couple comments..

 1) I kinda prefer having some to_hdmi/to_edp/etc macros rather than
 just open coding container_of().. I guess kind of a minor thing, but
 it keeps things consistent with how inheritance is handled elsewhere
 (like to_mdp5_crtc(), etc)

 2) I'd be a bit more enthused by this when it actually results in a
 negative diffstat, rather than a positive one.  Not saying it isn't
 something we should do at some point, but at this point I'm leaning
 towards rebasing the DSI patcheset to not depend on this for now.
 Actually most of the negative diffstat is in mdp5_kms.c which moves the
 modeset_init out of construct encoder. And it is required by DSI change.


 What I meant is that it adds more lines of code than it removes.. for
 refactoring/cleanup type things, I'd generally prefer things that work
 out the other way around (removing more lines than they add)..
 Anyways, if I drop this patch, I'll rebase the DSI patches.. that is
 fine.

 By the time I get DSI also working on mdp4, it might get to the point
 where this sort of change actually removes more lines than it adds, so
 that might be the time to revisit.  We may also be able to simplify it
 a bit..  I'm still thinking about it, I haven't completely decided
 yet.
ok.

 BR,
 -R



 BR,
 -R


 diff --git a/drivers/gpu/drm/msm/edp/edp.c
 b/drivers/gpu/drm/msm/edp/edp.c
 index 0940e84..8d8b7e9 100644
 --- a/drivers/gpu/drm/msm/edp/edp.c
 +++ b/drivers/gpu/drm/msm/edp/edp.c
 @@ -14,6 +14,9 @@
  #include linux/of_irq.h
  #include edp.h

 +static int msm_edp_modeset_init(struct msm_drm_sub_dev *base,
 +   struct drm_device *dev);
 +
  static irqreturn_t edp_irq(int irq, void *dev_id)
  {
 struct msm_edp *edp = dev_id;
 @@ -63,6 +66,8 @@ static struct msm_edp *edp_init(struct
 platform_device
 *pdev)
 if (ret)
 goto fail;

 +   edp-base.modeset_init = msm_edp_modeset_init;
 +
 return edp;

  fail:
 @@ -82,7 +87,8 @@ static int edp_bind(struct device *dev, struct
 device
 *master, void *data)
 edp = edp_init(to_platform_device(dev));
 if (IS_ERR(edp))
 return PTR_ERR(edp);
 -   priv-edp = edp;
 +
 +   priv-edp = edp-base;

 return 0;
  }
 @@ -144,13 +150,19 @@ void __exit msm_edp_unregister(void)
  }

  /* Second part of initialization, the drm/kms level modeset_init */
 -int msm_edp_modeset_init(struct msm_edp *edp, struct drm_device *dev,
 -   struct drm_encoder *encoder)
 +static int msm_edp_modeset_init(struct msm_drm_sub_dev *base,
 +   struct drm_device *dev)
  {
 +   struct msm_edp *edp = container_of(base, struct msm_edp,
 base);
 struct platform_device *pdev = edp-pdev;
 struct msm_drm_private *priv = dev-dev_private;
 +   struct drm_encoder *encoder;
 int ret;

 +   if (WARN_ON(base-num_encoders != 1))
 +   return -EINVAL;
 +
 +   encoder = base-encoders[0];
 edp-encoder = encoder;
 edp-dev = dev;

 diff --git a/drivers/gpu/drm/msm/edp/edp.h
 b/drivers/gpu/drm/msm/edp/edp.h
 index ba5bedd..00eff68 100644
 --- a/drivers/gpu/drm/msm/edp/edp.h
 +++ b/drivers/gpu/drm/msm/edp/edp.h
 @@ -31,6 +31,7 @@ struct edp_aux;
  struct edp_phy;

  struct msm_edp {
 +   struct msm_drm_sub_dev base;
 struct drm_device *dev;
 struct platform_device *pdev;

 diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c
 b/drivers/gpu/drm/msm/hdmi/hdmi.c
 index 9a8a825..9e886ec 100644
 --- a/drivers/gpu/drm/msm/hdmi/hdmi.c
 +++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
 @@ -19,6 +19,9 @@
  #include linux/of_irq.h
  #include hdmi.h

 +static int hdmi_modeset_init(struct msm_drm_sub_dev *base,
 +   struct drm_device *dev);
 +
  void hdmi_set_mode(struct hdmi *hdmi, bool power_on)
  {
 uint32_t ctrl = 0;
 @@ -197,6 +200,8 @@ static struct hdmi *hdmi_init(struct
 platform_device
 *pdev)
 goto fail;
 }

 +   hdmi-base.modeset_init = hdmi_modeset_init;
 +
 return hdmi;

  fail:
 @@ -214,13 +219,19 @@ fail:
   * should be handled in hdmi_init() so that failure happens from
   * hdmi sub-device's probe.
   */
 -int 

[PATCH v8 1/2] DT: hwspinlock: Add binding documentation for Qualcomm hwmutex

2015-03-24 Thread Bjorn Andersson
Add binding documentation for the Qualcomm Hardware Mutex.

Reviewed-by: Andy Gross agr...@codeaurora.org
Reviewed-by: Jeffrey Hugo jh...@codeaurora.org
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---

Changes since v7:
- Corrected address, compatible and naming of the tcsr block

Changes since v6:
- Corrected indentation error in example

Changes since v5:
- Extracted the dt binding documentation into a separate patch
- Moved the driver to consume a syscon
- Dropped previously suggested generic hwlock dt bindings

 .../devicetree/bindings/hwlock/qcom-hwspinlock.txt | 39 ++
 1 file changed, 39 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt

diff --git a/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt 
b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt
new file mode 100644
index 000..4563f52
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/qcom-hwspinlock.txt
@@ -0,0 +1,39 @@
+Qualcomm Hardware Mutex Block:
+
+The hardware block provides mutexes utilized between different processors on
+the SoC as part of the communication protocol used by these processors.
+
+- compatible:
+   Usage: required
+   Value type: string
+   Definition: must be one of:
+   qcom,sfpb-mutex,
+   qcom,tcsr-mutex
+
+- syscon:
+   Usage: required
+   Value type: prop-encoded-array
+   Definition: one cell containing:
+   syscon phandle
+   offset of the hwmutex block within the syscon
+   stride of the hwmutex registers
+
+- #hwlock-cells:
+   Usage: required
+   Value type: u32
+   Definition: must be 1, the specified cell represent the lock id
+   (hwlock standard property, see hwlock.txt)
+
+Example:
+
+   tcsr_mutex_block: syscon@fd484000 {
+   compatible = syscon;
+   reg = 0xfd484000 0x2000;
+   };
+
+   hwlock@fd484000 {
+   compatible = qcom,tcsr-mutex;
+   syscon = tcsr_mutex_block 0 0x80;
+
+   #hwlock-cells = 1;
+   };
-- 
1.8.2.2

--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v8 2/2] hwspinlock: qcom: Add support for Qualcomm HW Mutex block

2015-03-24 Thread Bjorn Andersson
Add driver for Qualcomm Hardware Mutex block found in many Qualcomm
SoCs.

Based on initial effort by Kumar Gala ga...@codeaurora.org

Reviewed-by: Andy Gross agr...@codeaurora.org
Reviewed-by: Jeffrey Hugo jh...@codeaurora.org
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---

Changes since v7:
- None (DT binding only)

Changes since v6:
- Added missing select of MFD_SYSCON

Changes since v5:
- Dropped all but hwspinlock specific dt bindings
- Hardcoded the number of locks (there is 32)
- Rework to sit ontop of syscon

Changes since v4:
- Aligned with devicetree support in hwlock framework and hence depends on [1]

Changes since v3:
- Reverted back to getting stride from of_match, per Kumars request

Changes since v2:
- MODULE_DEVICE_TABLE
- Changed prefix to qcom
- Cleaned up includes
- Rely on reg and num-locks to figure out stride, instead of of_match data

Changes since v1:
- Added the pm_runtime calls needed to be able to boot a kernel with
  pm_runtime and this driver, patch from Courtney.
- Added sfpb-mutex compatible, for re-use of the driver in family A platforms.
- Updated formatting of DT binding documentation, while adding the extra
  compatible.
- Dropped Stephen Boyds Reviewed-by due to these changes.

 drivers/hwspinlock/Kconfig   |  12 +++
 drivers/hwspinlock/Makefile  |   1 +
 drivers/hwspinlock/qcom_hwspinlock.c | 181 +++
 3 files changed, 194 insertions(+)
 create mode 100644 drivers/hwspinlock/qcom_hwspinlock.c

diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
index 3612cb5..b5b4f52 100644
--- a/drivers/hwspinlock/Kconfig
+++ b/drivers/hwspinlock/Kconfig
@@ -18,6 +18,18 @@ config HWSPINLOCK_OMAP
 
  If unsure, say N.
 
+config HWSPINLOCK_QCOM
+   tristate Qualcomm Hardware Spinlock device
+   depends on ARCH_QCOM
+   select HWSPINLOCK
+   select MFD_SYSCON
+   help
+ Say y here to support the Qualcomm Hardware Mutex functionality, which
+ provides a synchronisation mechanism for the various processors on
+ the SoC.
+
+ If unsure, say N.
+
 config HSEM_U8500
tristate STE Hardware Semaphore functionality
depends on ARCH_U8500
diff --git a/drivers/hwspinlock/Makefile b/drivers/hwspinlock/Makefile
index 93eb64b..68f95d9 100644
--- a/drivers/hwspinlock/Makefile
+++ b/drivers/hwspinlock/Makefile
@@ -4,4 +4,5 @@
 
 obj-$(CONFIG_HWSPINLOCK)   += hwspinlock_core.o
 obj-$(CONFIG_HWSPINLOCK_OMAP)  += omap_hwspinlock.o
+obj-$(CONFIG_HWSPINLOCK_QCOM)  += qcom_hwspinlock.o
 obj-$(CONFIG_HSEM_U8500)   += u8500_hsem.o
diff --git a/drivers/hwspinlock/qcom_hwspinlock.c 
b/drivers/hwspinlock/qcom_hwspinlock.c
new file mode 100644
index 000..93b62e0
--- /dev/null
+++ b/drivers/hwspinlock/qcom_hwspinlock.c
@@ -0,0 +1,181 @@
+/*
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2015, Sony Mobile Communications AB
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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.
+ */
+
+#include linux/hwspinlock.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/mfd/syscon.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+#include linux/regmap.h
+
+#include hwspinlock_internal.h
+
+#define QCOM_MUTEX_APPS_PROC_ID1
+#define QCOM_MUTEX_NUM_LOCKS   32
+
+static int qcom_hwspinlock_trylock(struct hwspinlock *lock)
+{
+   struct regmap_field *field = lock-priv;
+   u32 lock_owner;
+   int ret;
+
+   ret = regmap_field_write(field, QCOM_MUTEX_APPS_PROC_ID);
+   if (ret)
+   return ret;
+
+   ret = regmap_field_read(field, lock_owner);
+   if (ret)
+   return ret;
+
+   return lock_owner == QCOM_MUTEX_APPS_PROC_ID;
+}
+
+static void qcom_hwspinlock_unlock(struct hwspinlock *lock)
+{
+   struct regmap_field *field = lock-priv;
+   u32 lock_owner;
+   int ret;
+
+   ret = regmap_field_read(field, lock_owner);
+   if (ret) {
+   pr_err(%s: unable to query spinlock owner\n, __func__);
+   return;
+   }
+
+   if (lock_owner != QCOM_MUTEX_APPS_PROC_ID) {
+   pr_err(%s: spinlock not owned by us (actual owner is %d)\n,
+   __func__, lock_owner);
+   }
+
+   ret = regmap_field_write(field, 0);
+   if (ret)
+   pr_err(%s: failed to unlock spinlock\n, __func__);
+}
+
+static const struct hwspinlock_ops 

Re: [PATCH v2 1/7] eeprom: Add a simple EEPROM framework for eeprom providers

2015-03-24 Thread Mark Brown
On Tue, Mar 24, 2015 at 09:18:14AM +, Srinivas Kandagatla wrote:

 I did try your suggestion, by which I could remove the regmap from config.
 One thing I did not like was eeprom-core getting size/stride info directly
 from providers and regmap from regmap apis. I was wondering if we could take
 a step further and introduce new regmap helpers like

 regmap_get_size(regmap)

This is already there.

 regmap_get_stride(regmap)

 Which would be give eeprom-core the size and stride info, doing this way
 would cut down regmap related things from eeprom_config structure to minimal
 and also the source of information would come from just regmap apis.

Documentation/SubmittingPatches...


signature.asc
Description: Digital signature


Re: [PATCH v2 1/7] eeprom: Add a simple EEPROM framework for eeprom providers

2015-03-24 Thread Mark Brown
On Tue, Mar 24, 2015 at 06:34:32PM +, Srinivas Kandagatla wrote:
 On 24/03/15 17:23, Mark Brown wrote:

 regmap_get_size(regmap)

 This is already there.

 Sorry, I can't see any such api atleast in v4.0-rc5 and linux-next? Are you
 referring to another api which does the same job?

regmap_get_val_bytes()

 Which would be give eeprom-core the size and stride info, doing this way
 would cut down regmap related things from eeprom_config structure to minimal
 and also the source of information would come from just regmap apis.

 Documentation/SubmittingPatches...

 Am not sure what you meant here, Am guessing that you asked me to keep the
 respective maintainers in the loop and follow the guide, when I resend the
 patch?

I'm saying that you should send patches if you want to add features.


signature.asc
Description: Digital signature


[PATCH v2 3/5] drm/msm/mdp5: Update headers (remove enum mdp5_client_id)

2015-03-24 Thread Stephane Viau
This patch contains the generated header file of the following
change drm/msm/mdp5: Get SMP client list from mdp5_cfg.

Signed-off-by: Stephane Viau sv...@codeaurora.org
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 41 ++---
 1 file changed, 7 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
index cb931ca..b4e2624 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
@@ -8,7 +8,7 @@ http://github.com/freedreno/envytools/
 git clone https://github.com/freedreno/envytools.git
 
 The rules-ng-ng source files this header was generated from are:
-- /local/mnt2/workspace2/sviau/envytools/rnndb/mdp/mdp5.xml(  
29843 bytes, from 2015-03-09 12:32:38)
+- /local/mnt2/workspace2/sviau/envytools/rnndb/mdp/mdp5.xml(  
28872 bytes, from 2015-03-09 12:40:51)
 - /local/mnt2/workspace2/sviau/envytools/rnndb/freedreno_copyright.xml (   
1453 bytes, from 2014-06-02 18:31:15)
 - /local/mnt2/workspace2/sviau/envytools/rnndb/mdp/mdp_common.xml  (   
2357 bytes, from 2015-01-23 16:20:19)
 
@@ -97,33 +97,6 @@ enum mdp5_pipe_bwc {
BWC_Q_MED = 2,
 };
 
-enum mdp5_client_id {
-   CID_UNUSED = 0,
-   CID_VIG0_Y = 1,
-   CID_VIG0_CR = 2,
-   CID_VIG0_CB = 3,
-   CID_VIG1_Y = 4,
-   CID_VIG1_CR = 5,
-   CID_VIG1_CB = 6,
-   CID_VIG2_Y = 7,
-   CID_VIG2_CR = 8,
-   CID_VIG2_CB = 9,
-   CID_DMA0_Y = 10,
-   CID_DMA0_CR = 11,
-   CID_DMA0_CB = 12,
-   CID_DMA1_Y = 13,
-   CID_DMA1_CR = 14,
-   CID_DMA1_CB = 15,
-   CID_RGB0 = 16,
-   CID_RGB1 = 17,
-   CID_RGB2 = 18,
-   CID_VIG3_Y = 19,
-   CID_VIG3_CR = 20,
-   CID_VIG3_CB = 21,
-   CID_RGB3 = 22,
-   CID_MAX = 23,
-};
-
 enum mdp5_cursor_format {
CURSOR_FMT_ARGB = 0,
CURSOR_FMT_ARGB1555 = 2,
@@ -276,19 +249,19 @@ static inline uint32_t REG_MDP5_MDP_SMP_ALLOC_W(uint32_t 
i0, uint32_t i1) { retu
 static inline uint32_t REG_MDP5_MDP_SMP_ALLOC_W_REG(uint32_t i0, uint32_t i1) 
{ return 0x0080 + __offset_MDP(i0) + 0x4*i1; }
 #define MDP5_MDP_SMP_ALLOC_W_REG_CLIENT0__MASK 0x00ff
 #define MDP5_MDP_SMP_ALLOC_W_REG_CLIENT0__SHIFT0
-static inline uint32_t MDP5_MDP_SMP_ALLOC_W_REG_CLIENT0(enum mdp5_client_id 
val)
+static inline uint32_t MDP5_MDP_SMP_ALLOC_W_REG_CLIENT0(uint32_t val)
 {
return ((val)  MDP5_MDP_SMP_ALLOC_W_REG_CLIENT0__SHIFT)  
MDP5_MDP_SMP_ALLOC_W_REG_CLIENT0__MASK;
 }
 #define MDP5_MDP_SMP_ALLOC_W_REG_CLIENT1__MASK 0xff00
 #define MDP5_MDP_SMP_ALLOC_W_REG_CLIENT1__SHIFT8
-static inline uint32_t MDP5_MDP_SMP_ALLOC_W_REG_CLIENT1(enum mdp5_client_id 
val)
+static inline uint32_t MDP5_MDP_SMP_ALLOC_W_REG_CLIENT1(uint32_t val)
 {
return ((val)  MDP5_MDP_SMP_ALLOC_W_REG_CLIENT1__SHIFT)  
MDP5_MDP_SMP_ALLOC_W_REG_CLIENT1__MASK;
 }
 #define MDP5_MDP_SMP_ALLOC_W_REG_CLIENT2__MASK 0x00ff
 #define MDP5_MDP_SMP_ALLOC_W_REG_CLIENT2__SHIFT16
-static inline uint32_t MDP5_MDP_SMP_ALLOC_W_REG_CLIENT2(enum mdp5_client_id 
val)
+static inline uint32_t MDP5_MDP_SMP_ALLOC_W_REG_CLIENT2(uint32_t val)
 {
return ((val)  MDP5_MDP_SMP_ALLOC_W_REG_CLIENT2__SHIFT)  
MDP5_MDP_SMP_ALLOC_W_REG_CLIENT2__MASK;
 }
@@ -298,19 +271,19 @@ static inline uint32_t REG_MDP5_MDP_SMP_ALLOC_R(uint32_t 
i0, uint32_t i1) { retu
 static inline uint32_t REG_MDP5_MDP_SMP_ALLOC_R_REG(uint32_t i0, uint32_t i1) 
{ return 0x0130 + __offset_MDP(i0) + 0x4*i1; }
 #define MDP5_MDP_SMP_ALLOC_R_REG_CLIENT0__MASK 0x00ff
 #define MDP5_MDP_SMP_ALLOC_R_REG_CLIENT0__SHIFT0
-static inline uint32_t MDP5_MDP_SMP_ALLOC_R_REG_CLIENT0(enum mdp5_client_id 
val)
+static inline uint32_t MDP5_MDP_SMP_ALLOC_R_REG_CLIENT0(uint32_t val)
 {
return ((val)  MDP5_MDP_SMP_ALLOC_R_REG_CLIENT0__SHIFT)  
MDP5_MDP_SMP_ALLOC_R_REG_CLIENT0__MASK;
 }
 #define MDP5_MDP_SMP_ALLOC_R_REG_CLIENT1__MASK 0xff00
 #define MDP5_MDP_SMP_ALLOC_R_REG_CLIENT1__SHIFT8
-static inline uint32_t MDP5_MDP_SMP_ALLOC_R_REG_CLIENT1(enum mdp5_client_id 
val)
+static inline uint32_t MDP5_MDP_SMP_ALLOC_R_REG_CLIENT1(uint32_t val)
 {
return ((val)  MDP5_MDP_SMP_ALLOC_R_REG_CLIENT1__SHIFT)  
MDP5_MDP_SMP_ALLOC_R_REG_CLIENT1__MASK;
 }
 #define MDP5_MDP_SMP_ALLOC_R_REG_CLIENT2__MASK 0x00ff
 #define MDP5_MDP_SMP_ALLOC_R_REG_CLIENT2__SHIFT16
-static inline uint32_t MDP5_MDP_SMP_ALLOC_R_REG_CLIENT2(enum mdp5_client_id 
val)
+static inline uint32_t MDP5_MDP_SMP_ALLOC_R_REG_CLIENT2(uint32_t val)
 {
return ((val)  MDP5_MDP_SMP_ALLOC_R_REG_CLIENT2__SHIFT)  
MDP5_MDP_SMP_ALLOC_R_REG_CLIENT2__MASK;
 }
-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of 

[PATCH v2 4/5] drm/msm/mdp5: Get SMP client list from mdp5_cfg

2015-03-24 Thread Stephane Viau
SMP blocks are configured for specific client IDs (ports).
These client IDs can be different from one chip to another for a
given pipe.

e.g.: DMA0 pipe fetch Y component is connected to:
 - port #10 for MDP5 v1.3
 - port #4 for MDP5 v1.6

In order to be compatible for upcoming versions of MDP5, the
client ID list is passed through the MDP5 config module rather
than using a list of hard-coded enum values.

Signed-off-by: Stephane Viau sv...@codeaurora.org
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 20 ---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h |  1 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c | 44 ++---
 3 files changed, 41 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index f786c70..96ea6dd 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -31,6 +31,11 @@ const struct mdp5_cfg_hw msm8x74_config = {
.smp = {
.mmb_count = 22,
.mmb_size = 4096,
+   .clients = {
+   [SSPP_VIG0] =  1, [SSPP_VIG1] =  4, [SSPP_VIG2] =  7,
+   [SSPP_DMA0] = 10, [SSPP_DMA1] = 13,
+   [SSPP_RGB0] = 16, [SSPP_RGB1] = 17, [SSPP_RGB2] = 18,
+   },
},
.ctl = {
.count = 5,
@@ -86,11 +91,18 @@ const struct mdp5_cfg_hw apq8084_config = {
.smp = {
.mmb_count = 44,
.mmb_size = 8192,
+   .clients = {
+   [SSPP_VIG0] =  1, [SSPP_VIG1] =  4,
+   [SSPP_VIG2] =  7, [SSPP_VIG3] = 19,
+   [SSPP_DMA0] = 10, [SSPP_DMA1] = 13,
+   [SSPP_RGB0] = 16, [SSPP_RGB1] = 17,
+   [SSPP_RGB2] = 18, [SSPP_RGB3] = 22,
+   },
.reserved_state[0] = GENMASK(7, 0), /* first 8 MMBs */
-   .reserved[CID_RGB0] = 2,
-   .reserved[CID_RGB1] = 2,
-   .reserved[CID_RGB2] = 2,
-   .reserved[CID_RGB3] = 2,
+   .reserved = {
+   /* Two SMP blocks are statically tied to RGB pipes: */
+   [16] = 2, [17] = 2, [18] = 2, [22] = 2,
+   },
},
.ctl = {
.count = 5,
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
index 11f3e86..3a551b0 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
@@ -52,6 +52,7 @@ struct mdp5_ctl_block {
 struct mdp5_smp_block {
int mmb_count;  /* number of SMP MMBs */
int mmb_size;   /* MMB: size in bytes */
+   uint32_t clients[MAX_CLIENTS];  /* SMP port allocation /pipe */
mdp5_smp_state_t reserved_state;/* SMP MMBs statically allocated */
int reserved[MAX_CLIENTS];  /* # of MMBs allocated per client */
 };
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c
index 361c064..16702ae 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c
@@ -74,7 +74,7 @@ struct mdp5_smp {
spinlock_t state_lock;
mdp5_smp_state_t state; /* to track smp allocation amongst pipes: */
 
-   struct mdp5_client_smp_state client_state[CID_MAX];
+   struct mdp5_client_smp_state client_state[MAX_CLIENTS];
 };
 
 static inline
@@ -85,27 +85,31 @@ struct mdp5_kms *get_kms(struct mdp5_smp *smp)
return to_mdp5_kms(to_mdp_kms(priv-kms));
 }
 
-static inline enum mdp5_client_id pipe2client(enum mdp5_pipe pipe, int plane)
+static inline u32 pipe2client(enum mdp5_pipe pipe, int plane)
 {
-   WARN_ON(plane = pipe2nclients(pipe));
-   switch (pipe) {
-   case SSPP_VIG0: return CID_VIG0_Y + plane;
-   case SSPP_VIG1: return CID_VIG1_Y + plane;
-   case SSPP_VIG2: return CID_VIG2_Y + plane;
-   case SSPP_RGB0: return CID_RGB0;
-   case SSPP_RGB1: return CID_RGB1;
-   case SSPP_RGB2: return CID_RGB2;
-   case SSPP_DMA0: return CID_DMA0_Y + plane;
-   case SSPP_DMA1: return CID_DMA1_Y + plane;
-   case SSPP_VIG3: return CID_VIG3_Y + plane;
-   case SSPP_RGB3: return CID_RGB3;
-   default:return CID_UNUSED;
-   }
+#define CID_UNUSED 0
+
+   if (WARN_ON(plane = pipe2nclients(pipe)))
+   return CID_UNUSED;
+
+   /*
+* Note on SMP clients:
+* For ViG pipes, fetch Y/Cr/Cb-components clients are always
+* consecutive, and in that order.
+*
+* e.g.:
+* if mdp5_cfg-smp.clients[SSPP_VIG0] = N,
+*  Y  plane's client ID is N
+*  Cr plane's client ID is N + 1
+*  Cb plane's client ID is N + 2
+*/
+
+   return mdp5_cfg-smp.clients[pipe] + plane;
 }
 
 /* step #1: update # of blocks pending for the client: 

[PATCH v2 1/5] drm/msm/mdp5: Update headers (introduce MDP5 domain)

2015-03-24 Thread Stephane Viau
This change contains the generated header file for the following
change drm/msm/mdp5: Separate MDP5 domain from MDSS domain.

Signed-off-by: Stephane Viau sv...@codeaurora.org
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 203 +++-
 1 file changed, 118 insertions(+), 85 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
index b4d8716..cb931ca 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h
@@ -8,7 +8,7 @@ http://github.com/freedreno/envytools/
 git clone https://github.com/freedreno/envytools.git
 
 The rules-ng-ng source files this header was generated from are:
-- /local/mnt2/workspace2/sviau/envytools/rnndb/mdp/mdp5.xml(  
27094 bytes, from 2015-01-23 16:27:31)
+- /local/mnt2/workspace2/sviau/envytools/rnndb/mdp/mdp5.xml(  
29843 bytes, from 2015-03-09 12:32:38)
 - /local/mnt2/workspace2/sviau/envytools/rnndb/freedreno_copyright.xml (   
1453 bytes, from 2014-06-02 18:31:15)
 - /local/mnt2/workspace2/sviau/envytools/rnndb/mdp/mdp_common.xml  (   
2357 bytes, from 2015-01-23 16:20:19)
 
@@ -174,139 +174,172 @@ enum mdp5_data_format {
 #define MDP5_IRQ_INTF2_VSYNC   0x2000
 #define MDP5_IRQ_INTF3_UNDER_RUN   0x4000
 #define MDP5_IRQ_INTF3_VSYNC   0x8000
-#define REG_MDP5_HW_VERSION0x
+#define REG_MDSS_HW_VERSION0x
+#define MDSS_HW_VERSION_STEP__MASK 0x
+#define MDSS_HW_VERSION_STEP__SHIFT0
+static inline uint32_t MDSS_HW_VERSION_STEP(uint32_t val)
+{
+   return ((val)  MDSS_HW_VERSION_STEP__SHIFT)  
MDSS_HW_VERSION_STEP__MASK;
+}
+#define MDSS_HW_VERSION_MINOR__MASK0x0fff
+#define MDSS_HW_VERSION_MINOR__SHIFT   16
+static inline uint32_t MDSS_HW_VERSION_MINOR(uint32_t val)
+{
+   return ((val)  MDSS_HW_VERSION_MINOR__SHIFT)  
MDSS_HW_VERSION_MINOR__MASK;
+}
+#define MDSS_HW_VERSION_MAJOR__MASK0xf000
+#define MDSS_HW_VERSION_MAJOR__SHIFT   28
+static inline uint32_t MDSS_HW_VERSION_MAJOR(uint32_t val)
+{
+   return ((val)  MDSS_HW_VERSION_MAJOR__SHIFT)  
MDSS_HW_VERSION_MAJOR__MASK;
+}
+
+#define REG_MDSS_HW_INTR_STATUS
0x0010
+#define MDSS_HW_INTR_STATUS_INTR_MDP   0x0001
+#define MDSS_HW_INTR_STATUS_INTR_DSI0  0x0010
+#define MDSS_HW_INTR_STATUS_INTR_DSI1  0x0020
+#define MDSS_HW_INTR_STATUS_INTR_HDMI  0x0100
+#define MDSS_HW_INTR_STATUS_INTR_EDP   0x1000
 
-#define REG_MDP5_HW_INTR_STATUS
0x0010
-#define MDP5_HW_INTR_STATUS_INTR_MDP   0x0001
-#define MDP5_HW_INTR_STATUS_INTR_DSI0  0x0010
-#define MDP5_HW_INTR_STATUS_INTR_DSI1  0x0020
-#define MDP5_HW_INTR_STATUS_INTR_HDMI  0x0100
-#define MDP5_HW_INTR_STATUS_INTR_EDP   0x1000
+static inline uint32_t __offset_MDP(uint32_t idx)
+{
+   switch (idx) {
+   case 0: return (mdp5_cfg-mdp.base[0]);
+   default: return INVALID_IDX(idx);
+   }
+}
+static inline uint32_t REG_MDP5_MDP(uint32_t i0) { return 0x + 
__offset_MDP(i0); }
 
-#define REG_MDP5_MDP_VERSION   0x0100
-#define MDP5_MDP_VERSION_MINOR__MASK   0x00ff
-#define MDP5_MDP_VERSION_MINOR__SHIFT  16
-static inline uint32_t MDP5_MDP_VERSION_MINOR(uint32_t val)
+static inline uint32_t REG_MDP5_MDP_HW_VERSION(uint32_t i0) { return 
0x + __offset_MDP(i0); }
+#define MDP5_MDP_HW_VERSION_STEP__MASK 0x
+#define MDP5_MDP_HW_VERSION_STEP__SHIFT0
+static inline uint32_t MDP5_MDP_HW_VERSION_STEP(uint32_t val)
+{
+   return ((val)  MDP5_MDP_HW_VERSION_STEP__SHIFT)  
MDP5_MDP_HW_VERSION_STEP__MASK;
+}
+#define MDP5_MDP_HW_VERSION_MINOR__MASK
0x0fff
+#define MDP5_MDP_HW_VERSION_MINOR__SHIFT   16
+static inline uint32_t MDP5_MDP_HW_VERSION_MINOR(uint32_t val)
 {
-   return ((val)  MDP5_MDP_VERSION_MINOR__SHIFT)  
MDP5_MDP_VERSION_MINOR__MASK;
+   return ((val)  MDP5_MDP_HW_VERSION_MINOR__SHIFT)  
MDP5_MDP_HW_VERSION_MINOR__MASK;
 }
-#define MDP5_MDP_VERSION_MAJOR__MASK   0xf000
-#define MDP5_MDP_VERSION_MAJOR__SHIFT  28
-static inline uint32_t MDP5_MDP_VERSION_MAJOR(uint32_t val)
+#define 

[PATCH v2 0/5] drm/msm: Add display configuration for msm8x16

2015-03-24 Thread Stephane Viau
This patch set contains a couple modifications of the MDP5 register
description, followed by the MDP hw configuration of the msm8016 and
msm8916 chipsets.

v2: add CTL flush register's hardware mask [pointed by Archit]

Stephane Viau (5):
  drm/msm/mdp5: Update headers (introduce MDP5 domain)
  drm/msm/mdp5: Separate MDP5 domain from MDSS domain
  drm/msm/mdp5: Update headers (remove enum mdp5_client_id)
  drm/msm/mdp5: Get SMP client list from mdp5_cfg
  drm/msm/mdp5: Add hardware configuration for msm8x16

 drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h | 230 
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c |  80 ++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h |   2 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c |  20 +--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c |  26 ++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c |   9 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |   2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c |  64 -
 8 files changed, 258 insertions(+), 175 deletions(-)

-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 5/5] drm/msm/mdp5: Add hardware configuration for msm8x16

2015-03-24 Thread Stephane Viau
This change adds the hw configuration for msm8x16 chipsets in
mdp5_cfg module.

Note that only one external display interface is present in this
configuration (DSI) but has not been enabled yet. It will be enabled
once drm/msm driver supports DSI connectors.

v2: add CTL flush register's hardware mask [pointed by Archit]

Signed-off-by: Stephane Viau sv...@codeaurora.org
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 52 -
 1 file changed, 51 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index 96ea6dd..3d963cc 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2014 The Linux Foundation. All rights reserved.
+ * Copyright (c) 2014-2015 The Linux Foundation. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
@@ -150,10 +150,60 @@ const struct mdp5_cfg_hw apq8084_config = {
.max_clk = 32000,
 };
 
+const struct mdp5_cfg_hw msm8x16_config = {
+   .name = msm8x16,
+   .mdp = {
+   .count = 1,
+   .base = { 0x01000 },
+   },
+   .smp = {
+   .mmb_count = 8,
+   .mmb_size = 8192,
+   .clients = {
+   [SSPP_VIG0] = 1, [SSPP_DMA0] = 4,
+   [SSPP_RGB0] = 7, [SSPP_RGB1] = 8,
+   },
+   },
+   .ctl = {
+   .count = 5,
+   .base = { 0x02000, 0x02200, 0x02400, 0x02600, 0x02800 },
+   .flush_hw_mask = 0x4003,
+   },
+   .pipe_vig = {
+   .count = 1,
+   .base = { 0x05000 },
+   },
+   .pipe_rgb = {
+   .count = 2,
+   .base = { 0x15000, 0x17000 },
+   },
+   .pipe_dma = {
+   .count = 1,
+   .base = { 0x25000 },
+   },
+   .lm = {
+   .count = 2, /* LM0 and LM3 */
+   .base = { 0x45000, 0x48000 },
+   .nb_stages = 5,
+   },
+   .dspp = {
+   .count = 1,
+   .base = { 0x55000 },
+
+   },
+   .intf = {
+   .count = 1, /* INTF_1 */
+   .base = { 0x6B800 },
+   },
+   /* TODO enable .intfs[] with [1] = INTF_DSI, once DSI is implemented */
+   .max_clk = 32000,
+};
+
 static const struct mdp5_cfg_handler cfg_handlers[] = {
{ .revision = 0, .config = { .hw = msm8x74_config } },
{ .revision = 2, .config = { .hw = msm8x74_config } },
{ .revision = 3, .config = { .hw = apq8084_config } },
+   { .revision = 6, .config = { .hw = msm8x16_config } },
 };
 
 
-- 
Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/7] eeprom: Add a simple EEPROM framework for eeprom providers

2015-03-24 Thread Srinivas Kandagatla



On 24/03/15 19:02, Mark Brown wrote:

On Tue, Mar 24, 2015 at 06:34:32PM +, Srinivas Kandagatla wrote:

On 24/03/15 17:23, Mark Brown wrote:

 regmap_get_size(regmap)

 This is already there.

Sorry, I can't see any such api atleast in v4.0-rc5 and linux-next? Are you
referring to another api which does the same job?

regmap_get_val_bytes()

This would return value bytes, but I wanted is the regmap-max_register 
value which would be used for sanity checks in eeprom-core.


--srini

--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 2/5] drm/msm/mdp5: Separate MDP5 domain from MDSS domain

2015-03-24 Thread Stephane Viau
MDP block is actually contained inside the MDSS block. For some
chipsets, the base address of the MDP registers is different from the
current (assumed) 0x100 offset.

Like CTL and LM blocks, this changes introduce a dynamic offset
for the MDP instance, which can be found out at runtime, once the
MDSS HW version is read.

Signed-off-by: Stephane Viau sv...@codeaurora.org
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c |  8 
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h |  1 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c | 20 ++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c | 26 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c |  9 +
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h |  2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c | 20 ++--
 7 files changed, 48 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index 6c467fb..f786c70 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -24,6 +24,10 @@ const struct mdp5_cfg_hw *mdp5_cfg = NULL;
 
 const struct mdp5_cfg_hw msm8x74_config = {
.name = msm8x74,
+   .mdp = {
+   .count = 1,
+   .base = { 0x00100 },
+   },
.smp = {
.mmb_count = 22,
.mmb_size = 4096,
@@ -75,6 +79,10 @@ const struct mdp5_cfg_hw msm8x74_config = {
 
 const struct mdp5_cfg_hw apq8084_config = {
.name = apq8084,
+   .mdp = {
+   .count = 1,
+   .base = { 0x00100 },
+   },
.smp = {
.mmb_count = 44,
.mmb_size = 8192,
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
index 93bee92..11f3e86 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h
@@ -61,6 +61,7 @@ struct mdp5_smp_block {
 struct mdp5_cfg_hw {
char  *name;
 
+   struct mdp5_sub_block mdp;
struct mdp5_smp_block smp;
struct mdp5_ctl_block ctl;
struct mdp5_sub_block pipe_vig;
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
index 7c0adf5..0fa7fce 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_ctl.c
@@ -112,31 +112,31 @@ static void set_display_intf(struct mdp5_kms *mdp5_kms,
u32 intf_sel;
 
spin_lock_irqsave(mdp5_kms-resource_lock, flags);
-   intf_sel = mdp5_read(mdp5_kms, REG_MDP5_DISP_INTF_SEL);
+   intf_sel = mdp5_read(mdp5_kms, REG_MDP5_MDP_DISP_INTF_SEL(0));
 
switch (intf-num) {
case 0:
-   intf_sel = ~MDP5_DISP_INTF_SEL_INTF0__MASK;
-   intf_sel |= MDP5_DISP_INTF_SEL_INTF0(intf-type);
+   intf_sel = ~MDP5_MDP_DISP_INTF_SEL_INTF0__MASK;
+   intf_sel |= MDP5_MDP_DISP_INTF_SEL_INTF0(intf-type);
break;
case 1:
-   intf_sel = ~MDP5_DISP_INTF_SEL_INTF1__MASK;
-   intf_sel |= MDP5_DISP_INTF_SEL_INTF1(intf-type);
+   intf_sel = ~MDP5_MDP_DISP_INTF_SEL_INTF1__MASK;
+   intf_sel |= MDP5_MDP_DISP_INTF_SEL_INTF1(intf-type);
break;
case 2:
-   intf_sel = ~MDP5_DISP_INTF_SEL_INTF2__MASK;
-   intf_sel |= MDP5_DISP_INTF_SEL_INTF2(intf-type);
+   intf_sel = ~MDP5_MDP_DISP_INTF_SEL_INTF2__MASK;
+   intf_sel |= MDP5_MDP_DISP_INTF_SEL_INTF2(intf-type);
break;
case 3:
-   intf_sel = ~MDP5_DISP_INTF_SEL_INTF3__MASK;
-   intf_sel |= MDP5_DISP_INTF_SEL_INTF3(intf-type);
+   intf_sel = ~MDP5_MDP_DISP_INTF_SEL_INTF3__MASK;
+   intf_sel |= MDP5_MDP_DISP_INTF_SEL_INTF3(intf-type);
break;
default:
BUG();
break;
}
 
-   mdp5_write(mdp5_kms, REG_MDP5_DISP_INTF_SEL, intf_sel);
+   mdp5_write(mdp5_kms, REG_MDP5_MDP_DISP_INTF_SEL(0), intf_sel);
spin_unlock_irqrestore(mdp5_kms-resource_lock, flags);
 }
 
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
index a940710..33bd4c6 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_irq.c
@@ -23,7 +23,7 @@
 
 void mdp5_set_irqmask(struct mdp_kms *mdp_kms, uint32_t irqmask)
 {
-   mdp5_write(to_mdp5_kms(mdp_kms), REG_MDP5_INTR_EN, irqmask);
+   mdp5_write(to_mdp5_kms(mdp_kms), REG_MDP5_MDP_INTR_EN(0), irqmask);
 }
 
 static void mdp5_irq_error_handler(struct mdp_irq *irq, uint32_t irqstatus)
@@ -35,8 +35,8 @@ void mdp5_irq_preinstall(struct msm_kms *kms)
 {
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
mdp5_enable(mdp5_kms);
-   mdp5_write(mdp5_kms, REG_MDP5_INTR_CLEAR, 0x);
-   mdp5_write(mdp5_kms, REG_MDP5_INTR_EN, 0x);
+   mdp5_write(mdp5_kms, 

[PATCH] drm/msm: Initial add DSI connector support (v2)

2015-03-24 Thread Hai Li
This change adds the DSI connector support in msm drm driver.

v1: Initial change
v2: Address comments from Archit + minor clean-ups

Signed-off-by: Hai Li h...@codeaurora.org
---
 drivers/gpu/drm/msm/Kconfig   |   11 +
 drivers/gpu/drm/msm/Makefile  |4 +
 drivers/gpu/drm/msm/dsi/dsi.c |  214 
 drivers/gpu/drm/msm/dsi/dsi.h |  118 ++
 drivers/gpu/drm/msm/dsi/dsi_host.c| 1992 +
 drivers/gpu/drm/msm/dsi/dsi_manager.c |  699 
 drivers/gpu/drm/msm/dsi/dsi_phy.c |  352 ++
 drivers/gpu/drm/msm/msm_drv.h |   20 +
 8 files changed, 3410 insertions(+)
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi.c
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi.h
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_host.c
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_manager.c
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_phy.c

diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 1e6a907..5ba5631 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -35,3 +35,14 @@ config DRM_MSM_REGISTER_LOGGING
  Compile in support for logging register reads/writes in a format
  that can be parsed by envytools demsm tool.  If enabled, register
  logging can be switched on via msm.reglog=y module param.
+
+config DRM_MSM_DSI
+   bool Enable DSI support in MSM DRM driver
+   depends on DRM_MSM
+   select DRM_PANEL
+   select DRM_MIPI_DSI
+   default y
+   help
+ Choose this option if you have a need for MIPI DSI connector
+ support.
+
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 674a132..5c144cc 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -50,5 +50,9 @@ msm-y := \
 
 msm-$(CONFIG_DRM_MSM_FBDEV) += msm_fbdev.o
 msm-$(CONFIG_COMMON_CLK) += mdp/mdp4/mdp4_lvds_pll.o
+msm-$(CONFIG_DRM_MSM_DSI) += dsi/dsi.o \
+   dsi/dsi_host.o \
+   dsi/dsi_manager.o \
+   dsi/dsi_phy.o
 
 obj-$(CONFIG_DRM_MSM)  += msm.o
diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
new file mode 100644
index 000..1125264
--- /dev/null
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -0,0 +1,214 @@
+/*
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include dsi.h
+
+struct drm_encoder *msm_dsi_get_encoder(struct msm_dsi *msm_dsi)
+{
+   if (!msm_dsi || !msm_dsi-panel)
+   return NULL;
+
+   return (msm_dsi-panel_flags  MIPI_DSI_MODE_VIDEO) ?
+   msm_dsi-base.encoders[MSM_DSI_VIDEO_ENCODER_ID] :
+   msm_dsi-base.encoders[MSM_DSI_CMD_ENCODER_ID];
+}
+
+static int dsi_modeset_init(struct msm_drm_sub_dev *base,
+   struct drm_device *dev)
+{
+   struct msm_dsi *msm_dsi = container_of(base, struct msm_dsi, base);
+   struct msm_drm_private *priv = dev-dev_private;
+   int ret, i;
+
+   if (WARN_ON((base-num_encoders != MSM_DSI_ENCODER_NUM) ||
+   !base-encoders[MSM_DSI_VIDEO_ENCODER_ID] ||
+   !base-encoders[MSM_DSI_CMD_ENCODER_ID]))
+   return -EINVAL;
+
+   msm_dsi-dev = dev;
+
+   ret = msm_dsi_host_modeset_init(msm_dsi-host, dev);
+   if (ret) {
+   dev_err(dev-dev, failed to modeset init host: %d\n, ret);
+   goto fail;
+   }
+
+   msm_dsi-bridge = msm_dsi_manager_bridge_init(msm_dsi-id);
+   if (IS_ERR(msm_dsi-bridge)) {
+   ret = PTR_ERR(msm_dsi-bridge);
+   dev_err(dev-dev, failed to create dsi bridge: %d\n, ret);
+   msm_dsi-bridge = NULL;
+   goto fail;
+   }
+
+   msm_dsi-connector = msm_dsi_manager_connector_init(msm_dsi-id);
+   if (IS_ERR(msm_dsi-connector)) {
+   ret = PTR_ERR(msm_dsi-connector);
+   dev_err(dev-dev, failed to create dsi connector: %d\n, ret);
+   msm_dsi-connector = NULL;
+   goto fail;
+   }
+
+   for (i = 0; i  base-num_encoders; i++)
+   base-encoders[i]-bridge = msm_dsi-bridge;
+
+   priv-bridges[priv-num_bridges++]   = msm_dsi-bridge;
+   priv-connectors[priv-num_connectors++] = msm_dsi-connector;
+
+   return 0;
+fail:
+   if (msm_dsi) {
+   /* bridge/connector are normally destroyed by drm: */
+   if (msm_dsi-bridge) {
+   

Re: [PATCH v2 1/7] eeprom: Add a simple EEPROM framework for eeprom providers

2015-03-24 Thread Mark Brown
On Tue, Mar 24, 2015 at 07:26:45PM +, Srinivas Kandagatla wrote:
 On 24/03/15 19:02, Mark Brown wrote:
 On Tue, Mar 24, 2015 at 06:34:32PM +, Srinivas Kandagatla wrote:
 On 24/03/15 17:23, Mark Brown wrote:

  regmap_get_size(regmap)

  This is already there.

 Sorry, I can't see any such api atleast in v4.0-rc5 and linux-next? Are you
 referring to another api which does the same job?

 regmap_get_val_bytes()

 This would return value bytes, but I wanted is the regmap-max_register
 value which would be used for sanity checks in eeprom-core.

Then you *really* want to pick a better name then, I'd never have
inferred that meaning from size (consider sparse register maps for
example).  Like I said, send patches (preferrably showing the users as
well).


signature.asc
Description: Digital signature