[PATCH] add omap34xx temperature monitoring support

[Pavel Machek]

Signed-off-by: Pavel Machek pa...@ucw.cz

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 6529c09..9007ca9 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -28,6 +28,10 @@ config HWMON_VID
tristate
default n
 
+config SENSORS_OMAP34XX
+   bool TI OMAP34xx internal temperature sensor
+   depends on ARCH_OMAP3  HIGH_RES_TIMERS
+
 config HWMON_DEBUG_CHIP
bool Hardware Monitoring Chip debugging messages
default n
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 6728064..5c3b5d1 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -120,6 +120,7 @@ obj-$(CONFIG_SENSORS_NCT6683)   += nct6683.o
 obj-$(CONFIG_SENSORS_NCT6775)  += nct6775.o
 obj-$(CONFIG_SENSORS_NCT7802)  += nct7802.o
 obj-$(CONFIG_SENSORS_NTC_THERMISTOR)   += ntc_thermistor.o
+obj-$(CONFIG_SENSORS_OMAP34XX)  += omap34xx_temp.o
 obj-$(CONFIG_SENSORS_PC87360)  += pc87360.o
 obj-$(CONFIG_SENSORS_PC87427)  += pc87427.o
 obj-$(CONFIG_SENSORS_PCF8591)  += pcf8591.o
diff --git a/drivers/hwmon/omap34xx_temp.c b/drivers/hwmon/omap34xx_temp.c
new file mode 100644
index 000..bc7a72f
--- /dev/null
+++ b/drivers/hwmon/omap34xx_temp.c
@@ -0,0 +1,263 @@
+/*
+ * omap34xx_temp.c - Linux kernel module for OMAP34xx hardware monitoring
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ *
+ * Written by Peter De Schrijver peter.de-schrij...@nokia.com
+ *
+ * Inspired by k8temp.c
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * 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/clk.h
+#include linux/hrtimer.h
+#include linux/module.h
+#include linux/hwmon.h
+#include linux/hwmon-sysfs.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/slab.h
+
+#include ../../arch/arm/mach-omap2/control.h
+
+#define TEMP_SENSOR_SOC BIT(8)
+#define TEMP_SENSOR_EOCZ BIT(7)
+
+/* minimum delay for EOCZ rise after SOC rise is
+ * 11 cycles of the 32.768Khz clock */
+#define EOCZ_MIN_RISING_DELAY (11 * 30518)
+
+/* maximum delay for EOCZ rise after SOC rise is
+ * 14 cycles of the 32.768Khz clock */
+#define EOCZ_MAX_RISING_DELAY (14 * 30518)
+
+/* minimum delay for EOCZ falling is
+ * 36 cycles of the 32.768Khz clock */
+#define EOCZ_MIN_FALLING_DELAY (36 * 30518)
+
+/* maximum delay for EOCZ falling is
+ * 40 cycles of the 32.768Khz clock */
+#define EOCZ_MAX_FALLING_DELAY (40 * 30518)
+
+struct omap34xx_data {
+   struct device *hwmon_dev;
+   struct clk *clk_32k;
+   struct mutex update_lock;
+   const char *name;
+   char valid;
+   unsigned long last_updated;
+   u32 temp;
+};
+
+static struct platform_device omap34xx_temp_device = {
+   .name   = omap34xx_temp,
+   .id = -1,
+};
+
+static int adc_to_temp[] = {
+   -40, -40, -40, -40, -40, -39, -38, -36, -34, -32, -31, -29, -28, -26,
+   -25, -24, -22, -21, -19, -18, -17, -15, -14, -12, -11, -9, -8, -7, -5,
+   -4, -2, -1, 0, 1, 3, 4, 5, 7, 8, 10, 11, 13, 14, 15, 17, 18, 20, 21,
+   22, 24, 25, 27, 28, 30, 31, 32, 34, 35, 37, 38, 39, 41, 42, 44, 45,
+   47, 48, 49, 51, 52, 53, 55, 56, 58, 59, 60, 62, 63, 65, 66, 67, 69,
+   70, 72, 73, 74, 76, 77, 79, 80, 81, 83, 84, 85, 87, 88, 89, 91, 92,
+   94, 95, 96, 98, 99, 100, 102, 103, 105, 106, 107, 109, 110, 111, 113,
+   114, 116, 117, 118, 120, 121, 122, 124, 124, 125, 125, 125, 125, 125};
+
+static inline u32 wait_for_eocz(int min_delay, int max_delay, u32 level)
+{
+   struct timespec timeout;
+   ktime_t expire;
+   u32 temp_sensor_reg;
+
+   level = 1;
+   level *= TEMP_SENSOR_EOCZ;
+
+   expire = ktime_add_ns(ktime_get(), max_delay);
+   timeout = ns_to_timespec(min_delay);
+   hrtimer_nanosleep(timeout, NULL, HRTIMER_MODE_REL, CLOCK_MONOTONIC);
+   do {
+   temp_sensor_reg = omap_ctrl_readl(OMAP343X_CONTROL_TEMP_SENSOR);
+   if ((temp_sensor_reg  TEMP_SENSOR_EOCZ) == level)
+   break;
+   } while (ktime_us_delta(expire, ktime_get())  0);
+
+   return (temp_sensor_reg  TEMP_SENSOR_EOCZ) == level;
+}
+
+static void omap34xx_update(struct omap34xx_data *data)
+{
+   u32 temp_sensor_reg;
+
+   mutex_lock(data-update_lock);
+
+   if (!data-valid
+   || time_after(jiffies, data-last_updated + HZ)) {
+   clk_prepare_enable(data-clk_32k);
+
+   temp_sensor_reg = omap_ctrl_readl(OMAP343X_CONTROL_TEMP_SENSOR);
+   temp_sensor_reg |= TEMP_SENSOR_SOC;
+   omap_ctrl_writel(temp_sensor_reg, OMAP343X_CONTROL_TEMP_SENSOR);
+
+   if 

Re: [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig

[Igor Grinberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/26/14 06:42, Felipe Balbi wrote:
 Hi,
 
 On Thu, Dec 25, 2014 at 12:13:07PM +0200, Igor Grinberg wrote:
 Hi Tony,

 On 12/24/14 21:04, Tony Lindgren wrote:
 * Felipe Balbi ba...@ti.com [141224 07:52]:
 Hi,

 On Wed, Dec 24, 2014 at 01:53:46PM +0200, Igor Grinberg wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 12/23/14 18:19, Felipe Balbi wrote:
 On Tue, Dec 23, 2014 at 09:30:45AM +0200, Igor Grinberg wrote:
 Hi Felipe,

 On 12/22/14 20:05, Felipe Balbi wrote:

 [...]

  CONFIG_SCSI_SCAN_ASYNC=y
 -CONFIG_ATA=y
 -CONFIG_SATA_AHCI_PLATFORM=y
 -CONFIG_MD=y
 +CONFIG_ATA=m
 +CONFIG_SATA_AHCI_PLATFORM=m

 Isn't this needed for the rootfs on SATA devices?

 there's no known boards with rootfs on SATA. Until then, we can reduce
 the size.

 What makes you say so?
 The decision for rootfs on SATA is taken dynamically.
 OMAP5 boards (specifically cm-t54) can have rootfs on SATA...

 I'll leave the decision to Tony. Even though they _can_, they really
 don't and IIRC, OMAP5's SATA has so many silicon errata that it'd be
 annoying to find that special device which works (e.g it can't negotiate
 lower speeds with SATA III devices and it won't support SATA I).

 Yet, it is not that buggy and at least until now, I di not get any
 reports about badly working SATA from customers...


 As of today, we don't know of anybody really shipping anything with
 rootfs on SATA and distros would rather ship initiramfs than a giant
 zImage anyway.

 So, you just continue to ignore what I'm saying... even after I point
 to a device...
 
 you pointed a device which *can* have rootfs on SATA, not one which
 *has* rootfs on SATA, there's a very big difference there.

Yeah, I thought you will parse me in that way...

 
 Is it SATA that makes it so giant?
 Because I find it worth having in SATA than spare some more k's...
 
 that's your point of view. As Tony mentioned, we have a very standard
 way of dealing with this which is initramfs and x86 has been using that
 for the past 15+ years.

may be, but no... x86 has SATA built in...

 
 Tony, your call.

 I think we should move omap2plus_defconfig to be mostly modular and
 usable for distros as a base. Most distros prefer to build almost
 everything as loadable modules. And my preference is that we should
 only keep the minimum rootfs for devices and serial support as
 built-in and rely on initramfs for most drivers. And slowly move
 also the remaining built-in drivers to be loadable modules.

 The reasons for having drivers as loadable modules are many. It
 allows distros to use the same kernel for all the devices without
 bloating the kernel. It makes developing drivers easier as just the
 module needs to be reloaded. And loadable modules protect us from
 cross-framework spaghetti calls in the kernel as the interfaces are 
 clearly defined.

 Are there people really using SATA as rootfs right now on omaps?

 Yes. That is exactly my point.
 
 read your email, you said it *CAN* have rootfs on SATA.

yep, it also *CAN* have rootfs on MMC and NFS and ...

 
 If it's only something that will be more widely used in the future,
 then I suggest we make it into a loadable module, and presume
 initramfs and loadable module also for any new devices. The same
 way x86 has been doing with distros for years.

 The difference from x86 is that we're in embedded here and
 
 bullshit, you would never ship a product with omap2plus_defconfig. You'd
 build your own at which point you would switch SATA to built-in.

Yep, that is one of the options indeed, but I'm not asking you to
deal with my problems, right?
I'm feeling like you are trying to insult me.
Are you angry with me? Why?
Is it because I have a different opinion?

 
 although initramfs is a kind of option, but it means, you need to
 load even more data during the boot process... it is annoying and
 I would not want to use it on embedded.
 
 make your own defconfig.

This sounds like: mind your own business...
Is that what you want to say?

 
 (BTW, x86_64_defconfig has it compiled in...)

 We can also, split the defconfig as it was some time ago... but I
 would not want to go that direction...

 If we go the initramfs way, then why not also load MMC from it?
 That will also reduce kernel size... (but add initramfs size)
 
 I'm fine with that. The difference is that people have been relying on
 MMC built-in for the past 10+ years, since the old OMAP1 MMC driver,
 changing that now is likely to cause some my board won't boot anymore
 bug reports.

Yep. So there are exceptions, right?

 
 I'm sure you will find making the MMC a loadable module inconvenient.
 That how I find making the SATA a loadable module...

 Right now, we tell our customers that they can use mainline with
 omap2plus_defconfig.
 
 that's the worst thing you can do.

Hmmm... Interesting, so people should not use mainline.

 You should at a minimum provide your
 customers with a more minimal rootfs. Why would you have 

Re: [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig

[Igor Grinberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/26/14 06:37, Felipe Balbi wrote:
 Hi,
 
 On Wed, Dec 24, 2014 at 11:04:01AM -0800, Tony Lindgren wrote:
 * Felipe Balbi ba...@ti.com [141224 07:52]:
 Hi,

 On Wed, Dec 24, 2014 at 01:53:46PM +0200, Igor Grinberg wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 12/23/14 18:19, Felipe Balbi wrote:
 On Tue, Dec 23, 2014 at 09:30:45AM +0200, Igor Grinberg wrote:
 Hi Felipe,

 On 12/22/14 20:05, Felipe Balbi wrote:

 [...]

  CONFIG_SCSI_SCAN_ASYNC=y
 -CONFIG_ATA=y
 -CONFIG_SATA_AHCI_PLATFORM=y
 -CONFIG_MD=y
 +CONFIG_ATA=m
 +CONFIG_SATA_AHCI_PLATFORM=m

 Isn't this needed for the rootfs on SATA devices?

 there's no known boards with rootfs on SATA. Until then, we can reduce
 the size.

 What makes you say so?
 The decision for rootfs on SATA is taken dynamically.
 OMAP5 boards (specifically cm-t54) can have rootfs on SATA...

 I'll leave the decision to Tony. Even though they _can_, they really
 don't and IIRC, OMAP5's SATA has so many silicon errata that it'd be
 annoying to find that special device which works (e.g it can't negotiate
 lower speeds with SATA III devices and it won't support SATA I).

 As of today, we don't know of anybody really shipping anything with
 rootfs on SATA and distros would rather ship initiramfs than a giant
 zImage anyway.

 Tony, your call.

 I think we should move omap2plus_defconfig to be mostly modular and
 usable for distros as a base. Most distros prefer to build almost
 everything as loadable modules. And my preference is that we should
 only keep the minimum rootfs for devices and serial support as
 built-in and rely on initramfs for most drivers. And slowly move
 also the remaining built-in drivers to be loadable modules.

 The reasons for having drivers as loadable modules are many. It
 allows distros to use the same kernel for all the devices without
 bloating the kernel. It makes developing drivers easier as just the
 module needs to be reloaded. And loadable modules protect us from
 cross-framework spaghetti calls in the kernel as the interfaces are 
 clearly defined.

 Are there people really using SATA as rootfs right now on omaps?
 
 not that we know :-) The only platforms available today with SATA are
 OMAP5432 uEVM and DRA7x EVM,

I'm sorry... that is not true.

 the latter being mostly used by TIers as of
 now (at least from mainline point of view).

the keyword is mostly... And I'm also not sure this is true these days...

But, really, don't mind me. We will find our solutions (we always did).
I mean, Felipe wants it out so badly...
Who am I to say anything...

 
 If it's only something that will be more widely used in the future,
 then I suggest we make it into a loadable module, and presume
 initramfs and loadable module also for any new devices. The same
 way x86 has been doing with distros for years.
 
 alright, as a module it shall remain.
 

- -- 
Regards,
Igor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJUnU+qAAoJEBDE8YO64Efa8IgP/jQlP5nHLK8aWXpNIrRH3dri
IzIDvWqUC+zYqIgg1JcPmxgfZ+5vhYgjCVx+q0m/81qk164QK4zGs6gDr8sDjK8O
Q8rqujAbVFO2nmJHmq8VhTpapqTDtG5sH/HvtaWPtBxmBoA5yLdA8KObV9Gf2871
GvlP1WS/CUu6ClzEERsdWJkfpkqrJ1My1Ox7zCkL80uqM5z6jmje2sam4AiuGWSK
Kb/Kdkmqae1lizjSnyW0ZckTyCuLUPdzvV+OCq3JrDDJV9W3hrA0KmYKUe4gO0JI
Z2PNMKvbBuA9miY0IPsbILYkQ01OoKOwZXfDrhhK0k5FLPxSujc9NbfwqByTK2gi
Ca5zZKoTaUN8A2YoxdNv+m9gILnlgDCtRjvc6elEYZBLZd+03TsxgWAB+aYfx03d
1W5+qp8jSGBRzsDg5o8ir6mS8xYM3Hpy7xDPT46BqjKzczMCdeXH5MqibL34kqtC
mMhMw1UzZ5qGOyHXqYE9bosgfpbf+WxmVta7/RRgaJJwo7N41pf1sDyoJjczAfPo
cAQNeIwPd1DxiS2nO46i4w8FUq10Lf3I7mXxabXIsU3YD81QpjxL5arlFXlPfDVg
Ki8GW1yE81RepD5xuhhz3/U9pKvozSewH5BlHBo6h9rSBkyyBPs2NbxSxjSNct1H
MKEG/rYHptCRIntrZ8pm
=w62Y
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3] OMAP3 temperature sensor

[Sebastian Reichel]

Hi,

I've prepared an updated variant of the omap34xx temperature monitor driver.
It's based on the N9 driver instead of the N900 driver (and thus has omap36xx
support).

The differences compared to the original driver are:

 * DT based
 * No includes from arch, instead uses syscon DT node + regmap
 * Removed support for raw temperature reading
  - I assume this was used for debugging and regmap can be used
instead with newer kernels.
 * Introduction of managed resources where possible
 * Usage of module_platform_driver() macro
 * Added some comments referencing the TRM

So far the patchset is _compile-tested only_. I will test it on my N900 in
the next days.

-- Sebastian

Sebastian Reichel (3):
  DT Binding for omap3 temperature sensor
  hwmon: Driver for OMAP3 temperature sensor
  ARM: dts: OMAP34xx/36xx: Add temperature sensor

 .../bindings/hwmon/omap3-temperature.txt   |  25 ++
 arch/arm/boot/dts/omap34xx.dtsi|   7 +
 arch/arm/boot/dts/omap36xx.dtsi|   7 +
 drivers/hwmon/Kconfig  |   8 +
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/omap3-temp.c | 307 +
 6 files changed, 355 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
 create mode 100644 drivers/hwmon/omap3-temp.c

-- 
2.1.3

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

[PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor

[Sebastian Reichel]

OMAP34xx and OMAP36xx processors contain a register in the syscon area,
which can be used to determine the SoCs temperature. This patch provides
a DT based driver for the temperature sensor based on an older driver
written by Peter De Schrijver for the Nokia N900 and N9.

Signed-off-by: Sebastian Reichel s...@kernel.org
---
 drivers/hwmon/Kconfig  |   8 ++
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/omap3-temp.c | 307 +
 3 files changed, 316 insertions(+)
 create mode 100644 drivers/hwmon/omap3-temp.c

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 6529c09..749748d 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1135,6 +1135,14 @@ config SENSORS_NCT7802
  This driver can also be built as a module.  If so, the module
  will be called nct7802.
 
+config SENSORS_OMAP3_TEMP
+   tristate OMAP3 Temperature Sensor
+   depends on OF  (ARCH_OMAP3 || COMPILE_TEST)
+   select MFD_SYSCON
+   help
+ If you say yes here you get support for the temperature sensor
+ built into OMAP3 processors.
+
 config SENSORS_PCF8591
tristate Philips PCF8591 ADC/DAC
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 6728064..5a69773 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -120,6 +120,7 @@ obj-$(CONFIG_SENSORS_NCT6683)   += nct6683.o
 obj-$(CONFIG_SENSORS_NCT6775)  += nct6775.o
 obj-$(CONFIG_SENSORS_NCT7802)  += nct7802.o
 obj-$(CONFIG_SENSORS_NTC_THERMISTOR)   += ntc_thermistor.o
+obj-$(CONFIG_SENSORS_OMAP3_TEMP)   += omap3-temp.o
 obj-$(CONFIG_SENSORS_PC87360)  += pc87360.o
 obj-$(CONFIG_SENSORS_PC87427)  += pc87427.o
 obj-$(CONFIG_SENSORS_PCF8591)  += pcf8591.o
diff --git a/drivers/hwmon/omap3-temp.c b/drivers/hwmon/omap3-temp.c
new file mode 100644
index 000..5c331c5
--- /dev/null
+++ b/drivers/hwmon/omap3-temp.c
@@ -0,0 +1,307 @@
+/*
+ * omap3-temp.c - driver for OMAP34xx and OMAP36xx temperature sensor
+ *
+ * Copyright (c) 2014 Sebastian Reichel s...@kernel.org
+ * Copyright (C) 2008, 2009, 2010 Nokia Corporation
+ *
+ * based on Peter De Schrijver's driver for N9
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include linux/clk.h
+#include linux/hrtimer.h
+#include linux/hwmon.h
+#include linux/hwmon-sysfs.h
+#include linux/mfd/syscon.h
+#include linux/module.h
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/regmap.h
+#include linux/sched.h
+#include linux/stat.h
+
+/* 32.768Khz clock speed in nano seconds */
+#define CLOCK_32K_SPEED_NS 30518
+
+/* minimum delay for EOCZ rise after SOC rise is
+ * 11 cycles of the 32.768Khz clock */
+#define EOCZ_MIN_RISING_DELAY (11 * CLOCK_32K_SPEED_NS)
+
+/* From docs, maximum delay for EOCZ rise after SOC rise is
+ * 14 cycles of the 32.768Khz clock. But after some experiments,
+ * 24 cycles as maximum is safer. */
+#define EOCZ_MAX_RISING_DELAY (24 * CLOCK_32K_SPEED_NS)
+
+/* minimum delay for EOCZ falling is
+ * 36 cycles of the 32.768Khz clock */
+#define EOCZ_MIN_FALLING_DELAY (36 * CLOCK_32K_SPEED_NS)
+
+/* maximum delay for EOCZ falling is
+ * 40 cycles of the 32.768Khz clock */
+#define EOCZ_MAX_FALLING_DELAY (40 * CLOCK_32K_SPEED_NS)
+
+/* temperature register offset in the syscon register area */
+#define SYSCON_TEMP_REG 0x02B4
+
+/* TRM: Table 7-11. ADC Codes Versus Temperature */
+static const int adc_to_temp_3430[] = {
+   -400, -400, -400, -400, -400, -390, -380, -360, -340, -320, -310,
+   -290, -280, -260, -250, -240, -220, -210, -190, -180, -170, -150,
+   -140, -120, -110, -90, -80, -70, -50, -40, -20, -10, 00, 10, 30,
+   40, 50, 70, 80, 100, 110, 130, 140, 150, 170, 180, 200, 210, 220,
+   240, 250, 270, 280, 300, 310, 320, 340, 350, 370, 380, 390, 410, 420,
+   440, 450, 470, 480, 490, 510, 520, 530, 550, 560, 580, 590, 600, 620,
+   630, 650, 660, 670, 690, 700, 720, 730, 740, 760, 770, 790, 800, 810,
+   830, 840, 850, 870, 880, 890, 910, 920, 940, 950, 960, 980, 990, 1000,
+   1020, 1030, 1050, 1060, 1070, 1090, 1100, 1110, 1130, 1140, 1160,
+   1170, 1180, 1200, 1210, 1220, 1240, 1240, 1250, 1250, 1250, 1250,
+   1250};
+
+/* TRM: Table 13-11. ADC Code Versus Temperature */
+static const int adc_to_temp_3630[] = {
+   -400, -400, -400, -400, -400, -400, -400, -400, -400, 

[PATCH 1/3] DT Binding for omap3 temperature sensor

[Sebastian Reichel]

OMAP34xx and OMAP36xx processors contain a register in the syscon area,
which can be used to determine the SoCs temperature. This provides a
DT binding specification for the temperature monitor.

Signed-off-by: Sebastian Reichel s...@kernel.org
---
 .../bindings/hwmon/omap3-temperature.txt   | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/hwmon/omap3-temperature.txt

diff --git a/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt 
b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
new file mode 100644
index 000..99631ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
@@ -0,0 +1,25 @@
+* OMAP3 temperature sensor
+
+The OMAP34xx and OMAP36xx processors contain a register in the syscon area,
+which can be used to determine the SoCs temperature.
+
+Requires node properties:
+- compatible : should contain one of
+   - ti,omap34xx-temperature-sensor for OMAP34xx
+   - ti,omap36xx-temperature-sensor for OMAP36xx
+- syscon : Should be a phandle to system configuration node which
+   encompases the temperature register
+- clocks : Should contain 32KHz fclk clock specifier
+- clock-names :Should contain clock names
+   - fck for the 32KHz fclk clock specifier
+
+Example for omap34xx:
+
+/ {
+   temperature-sensor {
+   compatible = ti,omap34xx-temperature-sensor;
+   syscon = omap3_scm_general;
+   clocks = ts_fck;
+   clock-names = fck;
+   };
+};
-- 
2.1.3

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

[PATCH 3/3] ARM: dts: OMAP34xx/36xx: Add temperature sensor

[Sebastian Reichel]

OMAP34xx and OMAP36xx processors contain a register in the
syscon area, which can be used to determine the SoCs temperature.

Signed-off-by: Sebastian Reichel s...@kernel.org
---
 arch/arm/boot/dts/omap34xx.dtsi | 7 +++
 arch/arm/boot/dts/omap36xx.dtsi | 7 +++
 2 files changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 3819c1e..64679ee 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -38,6 +38,13 @@
pinctrl-single,function-mask = 0xff1f;
};
};
+
+   omap3_temperature_sensor: temperature-sensor {
+   compatible = ti,omap34xx-temperature-sensor;
+   syscon = omap3_scm_general;
+   clocks = ts_fck;
+   clock-names = fck;
+   };
 };
 
 ssi {
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 541704a..be9ee1d 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -70,6 +70,13 @@
pinctrl-single,function-mask = 0xff1f;
};
};
+
+   omap3_temperature_sensor: temperature-sensor {
+   compatible = ti,omap36xx-temperature-sensor;
+   syscon = omap3_scm_general;
+   clocks = ts_fck;
+   clock-names = fck;
+   };
 };
 
 /* OMAP3630 needs dss_96m_fck for VENC */
-- 
2.1.3

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

Re: [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig

[grygorii.stras...@linaro.org]

On 12/25/2014 12:13 PM, Igor Grinberg wrote:
 Hi Tony,
 
 On 12/24/14 21:04, Tony Lindgren wrote:
 * Felipe Balbi ba...@ti.com [141224 07:52]:
 Hi,

 On Wed, Dec 24, 2014 at 01:53:46PM +0200, Igor Grinberg wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 12/23/14 18:19, Felipe Balbi wrote:
 On Tue, Dec 23, 2014 at 09:30:45AM +0200, Igor Grinberg wrote:
 Hi Felipe,

 On 12/22/14 20:05, Felipe Balbi wrote:

 [...]

   CONFIG_SCSI_SCAN_ASYNC=y
 -CONFIG_ATA=y
 -CONFIG_SATA_AHCI_PLATFORM=y
 -CONFIG_MD=y
 +CONFIG_ATA=m
 +CONFIG_SATA_AHCI_PLATFORM=m

 Isn't this needed for the rootfs on SATA devices?

 there's no known boards with rootfs on SATA. Until then, we can reduce
 the size.

 What makes you say so?
 The decision for rootfs on SATA is taken dynamically.
 OMAP5 boards (specifically cm-t54) can have rootfs on SATA...

 I'll leave the decision to Tony. Even though they _can_, they really
 don't and IIRC, OMAP5's SATA has so many silicon errata that it'd be
 annoying to find that special device which works (e.g it can't negotiate
 lower speeds with SATA III devices and it won't support SATA I).
 
 Yet, it is not that buggy and at least until now, I di not get any
 reports about badly working SATA from customers...
 

 As of today, we don't know of anybody really shipping anything with
 rootfs on SATA and distros would rather ship initiramfs than a giant
 zImage anyway.
 
 So, you just continue to ignore what I'm saying... even after I point
 to a device...
 
 Is it SATA that makes it so giant?
 Because I find it worth having in SATA than spare some more k's...
 

SATA code occupies ~179Kbytes - checked on 3.19-rc1
CONFIG_ATA=y
CONFIG_SATA_AHCI_PLATFORM=y
CONFIG_MD=y (seems it will give +-0K)


 Tony, your call

May be it will be good thing to split this patch. That way more information
will be stored in commit log about which set of options gives us what benefits.
And also, It will allow to continue with agreed changes.
?


 I think we should move omap2plus_defconfig to be mostly modular and
 usable for distros as a base. Most distros prefer to build almost
 everything as loadable modules. And my preference is that we should
 only keep the minimum rootfs for devices and serial support as
 built-in and rely on initramfs for most drivers. And slowly move
 also the remaining built-in drivers to be loadable modules.

 The reasons for having drivers as loadable modules are many. It
 allows distros to use the same kernel for all the devices without
 bloating the kernel. It makes developing drivers easier as just the
 module needs to be reloaded. And loadable modules protect us from
 cross-framework spaghetti calls in the kernel as the interfaces are
 clearly defined.

 Are there people really using SATA as rootfs right now on omaps?
 
 Yes. That is exactly my point.
 

From my side I'd like to note that I know about few ongoing projects on DRA7x 
EVM
where SATA is used as rootfs - now It is the fast possible way to start Android.

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

Re: [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig

[Javier Martinez Canillas]

Hello all,

On Fri, Dec 26, 2014 at 12:56 PM, Igor Grinberg grinb...@compulab.co.il wrote:
 Tony, your call.

 I think we should move omap2plus_defconfig to be mostly modular and
 usable for distros as a base. Most distros prefer to build almost
 everything as loadable modules. And my preference is that we should
 only keep the minimum rootfs for devices and serial support as
 built-in and rely on initramfs for most drivers. And slowly move
 also the remaining built-in drivers to be loadable modules.

 The reasons for having drivers as loadable modules are many. It
 allows distros to use the same kernel for all the devices without
 bloating the kernel. It makes developing drivers easier as just the
 module needs to be reloaded. And loadable modules protect us from
 cross-framework spaghetti calls in the kernel as the interfaces are
 clearly defined.


I do agree with Tony and Felipe that we should try to build as much
stuff as possible as a module instead of built-in to match what
distros do and what has been done for x86 for years.

However, if that's the case I wonder what's the point of having both
an omap2plus_defconfig and a multi_v7_defconfig? Would it make sense
to get rid of the SoC specific configs then and just use the single
ARMv7 defconfig for all SoCs with most of the options enabled as a
module?

FYI, some time ago I posted a patch to enable SBS-compliant batteries
support as a module for Exynos defconfig and was told to re-spin the
patch and enabling it as built-in instead since the most popular use
case for exynos_defconfig was development and people usually just copy
the kernel binary and not the modules [0].

So it seems that each ARM SoC community has a different opinion about
how things should be configured and do it differently.


 bullshit, you would never ship a product with omap2plus_defconfig. You'd
 build your own at which point you would switch SATA to built-in.


There are different opinions but let please try to keep the discussion
constructive and use a polite tone.


 Right now, we tell our customers that they can use mainline with
 omap2plus_defconfig.

 that's the worst thing you can do.


I'm confused, Felipe said that customers should not base their config
from omap2plus_defconfig but AFAUI Tony's argument is exactly the
opposite, that everything should be configured as a module so distros
can use omap2plus_defconfig as a base. So, is or is not expected that
people will use omap2plus_defconfig as a base for their own config?

I think the problem is that there isn't an agreement about what is the
purpose of the per SoC (e.g: oma2plus_defconfig) and the multi_v7
defconfigs (or at least is not well documented since I could not find
it). So, IMHO this concern should be raised to the ARM SoC maintainers
and there should be an agreement in the ARM community as a whole about
how things should be configured on each defconfig, and all SoCs should
follow the agreed rule.

Otherwise it seems that the motivation for each kconfig symbol enabled
is just to make the workflow of the developer posting the patches
easier and wins whoever shouts louder.

Thanks a lot and best regards,
Javier

[0]: http://www.spinics.net/lists/arm-kernel/msg353808.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig

[Felipe Balbi]

Hi,

On Fri, Dec 26, 2014 at 01:56:26PM +0200, Igor Grinberg wrote:
  Tony, your call.
 
  I think we should move omap2plus_defconfig to be mostly modular and
  usable for distros as a base. Most distros prefer to build almost
  everything as loadable modules. And my preference is that we should
  only keep the minimum rootfs for devices and serial support as
  built-in and rely on initramfs for most drivers. And slowly move
  also the remaining built-in drivers to be loadable modules.
 
  The reasons for having drivers as loadable modules are many. It
  allows distros to use the same kernel for all the devices without
  bloating the kernel. It makes developing drivers easier as just the
  module needs to be reloaded. And loadable modules protect us from
  cross-framework spaghetti calls in the kernel as the interfaces are 
  clearly defined.
 
  Are there people really using SATA as rootfs right now on omaps?
 
  Yes. That is exactly my point.
  
  read your email, you said it *CAN* have rootfs on SATA.
 
 yep, it also *CAN* have rootfs on MMC and NFS and ...

those we *know* people are using as rootfs. We know of several users who
are actually using it :-)

  If it's only something that will be more widely used in the future,
  then I suggest we make it into a loadable module, and presume
  initramfs and loadable module also for any new devices. The same
  way x86 has been doing with distros for years.
 
  The difference from x86 is that we're in embedded here and
  
  bullshit, you would never ship a product with omap2plus_defconfig. You'd
  build your own at which point you would switch SATA to built-in.
 
 Yep, that is one of the options indeed, but I'm not asking you to
 deal with my problems, right?
 I'm feeling like you are trying to insult me.
 Are you angry with me? Why?
 Is it because I have a different opinion?

heh, cute :-)

  although initramfs is a kind of option, but it means, you need to
  load even more data during the boot process... it is annoying and
  I would not want to use it on embedded.
  
  make your own defconfig.
 
 This sounds like: mind your own business...
 Is that what you want to say?

nope, not really. Just saying that if you're really concerned about
being embedded and that initramfs takes that much more time to load,
you'd just make your own defconfig and maintain it out-of-tree.

RMK does that for quite a few boards, I do it for my boards and also for
my x86 desktops/laptops.

It's not really rocket science.

  (BTW, x86_64_defconfig has it compiled in...)
 
  We can also, split the defconfig as it was some time ago... but I
  would not want to go that direction...
 
  If we go the initramfs way, then why not also load MMC from it?
  That will also reduce kernel size... (but add initramfs size)
  
  I'm fine with that. The difference is that people have been relying on
  MMC built-in for the past 10+ years, since the old OMAP1 MMC driver,
  changing that now is likely to cause some my board won't boot anymore
  bug reports.
 
 Yep. So there are exceptions, right?

never claimed the contrary.

  I'm sure you will find making the MMC a loadable module inconvenient.
  That how I find making the SATA a loadable module...
 
  Right now, we tell our customers that they can use mainline with
  omap2plus_defconfig.
  
  that's the worst thing you can do.
 
 Hmmm... Interesting, so people should not use mainline.

now you're reading what you want to read ;-) Using my statements out of
context.

It's clear (actually s/rootfs/defconfig below) that I meant defconfig.

  You should at a minimum provide your
  customers with a more minimal rootfs. Why would you have your customers

oh wait, not rootfs, defconfig.

  build MUSB on an OMAP5 board ? Why would they build 5 different
  network device drivers ? Why would they build almost every single PMIC
  we ever used ? The list goes on and on.
 
 That is their decision to make. I'm just saying that they can use it.

right, and they can switch SATA to built-in if they want to ship an
initramfs-less product, don't you think ?

Or they can append initramfs to the kernel image and not even have a
root filesystem anywhere (been there, done that), but that's not
relevant to this discussion.

Anyway, I'll leave it to Tony.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig

[Felipe Balbi]

Hi,

On Fri, Dec 26, 2014 at 02:42:07PM +0100, Javier Martinez Canillas wrote:
 Hello all,
 
 On Fri, Dec 26, 2014 at 12:56 PM, Igor Grinberg grinb...@compulab.co.il 
 wrote:
  Tony, your call.
 
  I think we should move omap2plus_defconfig to be mostly modular and
  usable for distros as a base. Most distros prefer to build almost
  everything as loadable modules. And my preference is that we should
  only keep the minimum rootfs for devices and serial support as
  built-in and rely on initramfs for most drivers. And slowly move
  also the remaining built-in drivers to be loadable modules.
 
  The reasons for having drivers as loadable modules are many. It
  allows distros to use the same kernel for all the devices without
  bloating the kernel. It makes developing drivers easier as just the
  module needs to be reloaded. And loadable modules protect us from
  cross-framework spaghetti calls in the kernel as the interfaces are
  clearly defined.
 
 
 I do agree with Tony and Felipe that we should try to build as much
 stuff as possible as a module instead of built-in to match what
 distros do and what has been done for x86 for years.
 
 However, if that's the case I wonder what's the point of having both
 an omap2plus_defconfig and a multi_v7_defconfig? Would it make sense

I wonder the same thing, but look at multi_v7_defconfig today. Almost
everything is built-in, which makes the kernel image enormous (5.5MiB).

 to get rid of the SoC specific configs then and just use the single
 ARMv7 defconfig for all SoCs with most of the options enabled as a
 module?

if people accept switching some of those as modules, sure. I don't mind
that at all. I'll still continue to maintain my out-of-tree defconfigs
for my boards anyway. It's also very good to have a generic defconfig
which will just work with everything I have.

 FYI, some time ago I posted a patch to enable SBS-compliant batteries
 support as a module for Exynos defconfig and was told to re-spin the
 patch and enabling it as built-in instead since the most popular use
 case for exynos_defconfig was development and people usually just copy
 the kernel binary and not the modules [0].

lol, that's the reason why I don't use multi_v7_defconfig.

 So it seems that each ARM SoC community has a different opinion about
 how things should be configured and do it differently.

I wouldn't be surprised.

  bullshit, you would never ship a product with omap2plus_defconfig. You'd
  build your own at which point you would switch SATA to built-in.
 
 
 There are different opinions but let please try to keep the discussion
 constructive and use a polite tone.
 
 
  Right now, we tell our customers that they can use mainline with
  omap2plus_defconfig.
 
  that's the worst thing you can do.
 
 
 I'm confused, Felipe said that customers should not base their config
 from omap2plus_defconfig but AFAUI Tony's argument is exactly the
 opposite, that everything should be configured as a module so distros

basing on omap2plus_defconfig is never an issue. Claiming that you're
concerned about the extra KiBs for loading initramfs and then saying you
ship embedded products with omap2plus_defconfig is BS.

 can use omap2plus_defconfig as a base. So, is or is not expected that
 people will use omap2plus_defconfig as a base for their own config?

I never claimed that people should not use it as a *base*, rather it
should not be used to build a product's kernel/modules. Imagine you
shipping an embedded product based off of OMAP5 and you add CPSW, QSPI,
MUSB, a ton of touchscreen drivers you don't use, several PMIC drivers
built-in, etc. It's a waste of space and just bloats that product's
zImage.

 I think the problem is that there isn't an agreement about what is the
 purpose of the per SoC (e.g: oma2plus_defconfig) and the multi_v7
 defconfigs (or at least is not well documented since I could not find
 it). So, IMHO this concern should be raised to the ARM SoC maintainers
 and there should be an agreement in the ARM community as a whole about
 how things should be configured on each defconfig, and all SoCs should
 follow the agreed rule.

OTOH, the OMAP defconfig is part of the OMAP port and Tony will have the
final saying about it, right ?

 Otherwise it seems that the motivation for each kconfig symbol enabled
 is just to make the workflow of the developer posting the patches
 easier and wins whoever shouts louder.

it is just to make things easier. In fact, I only enabled AM437x SK's
drivers on o2+_dc because I got tired of people telling me that board
doesn't work with mainline and being completely reluctant to change
their defconfig. At that point I talked to Tony and he said as long as
things are added as modules, I don't mind.

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig

[Felipe Balbi]

Hi,

On Fri, Dec 26, 2014 at 02:08:10PM +0200, Igor Grinberg wrote:
  I think we should move omap2plus_defconfig to be mostly modular and
  usable for distros as a base. Most distros prefer to build almost
  everything as loadable modules. And my preference is that we should
  only keep the minimum rootfs for devices and serial support as
  built-in and rely on initramfs for most drivers. And slowly move
  also the remaining built-in drivers to be loadable modules.
 
  The reasons for having drivers as loadable modules are many. It
  allows distros to use the same kernel for all the devices without
  bloating the kernel. It makes developing drivers easier as just the
  module needs to be reloaded. And loadable modules protect us from
  cross-framework spaghetti calls in the kernel as the interfaces are 
  clearly defined.
 
  Are there people really using SATA as rootfs right now on omaps?
  
  not that we know :-) The only platforms available today with SATA are
  OMAP5432 uEVM and DRA7x EVM,
 
 I'm sorry... that is not true.

That's not what you have said thus far. So far you only said it *can*
have, you have not explicitly said a customer really *is* using rootfs
on SATA.

Personally, I really don't care. It's just a defconfig patch and
kernel configuration is very, very easy to change at any time. You can
even have an out of tree config fragment just turning SATA=y again.

Have a look at scripts/kconfig/merge_config.sh

  the latter being mostly used by TIers as of
  now (at least from mainline point of view).
 
 the keyword is mostly... And I'm also not sure this is true these days...
 
 But, really, don't mind me. We will find our solutions (we always did).
 I mean, Felipe wants it out so badly...
 Who am I to say anything...

cute :-)

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig

[Felipe Balbi]

Hi,

On Fri, Dec 26, 2014 at 03:04:00PM +0200, grygorii.stras...@linaro.org wrote:
 
  Tony, your call
 
 May be it will be good thing to split this patch. That way more
 information will be stored in commit log about which set of options
 gives us what benefits.  And also, It will allow to continue with
 agreed changes.  ?

can be done, but then again, it's just a defconfig change. Tony, your
call.

  I think we should move omap2plus_defconfig to be mostly modular and
  usable for distros as a base. Most distros prefer to build almost
  everything as loadable modules. And my preference is that we should
  only keep the minimum rootfs for devices and serial support as
  built-in and rely on initramfs for most drivers. And slowly move
  also the remaining built-in drivers to be loadable modules.
 
  The reasons for having drivers as loadable modules are many. It
  allows distros to use the same kernel for all the devices without
  bloating the kernel. It makes developing drivers easier as just the
  module needs to be reloaded. And loadable modules protect us from
  cross-framework spaghetti calls in the kernel as the interfaces are
  clearly defined.
 
  Are there people really using SATA as rootfs right now on omaps?
  
  Yes. That is exactly my point.
  
 
 From my side I'd like to note that I know about few ongoing projects
 on DRA7x EVM where SATA is used as rootfs - now It is the fast
 possible way to start Android.

now this is something different. This is evidence that there are people
relying on SATA on rootfs. I'll leave to Tony again.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] add omap34xx temperature monitoring support

[Tony Lindgren]

* Pavel Machek pa...@ucw.cz [141226 02:32]:
 --- /dev/null
 +++ b/drivers/hwmon/omap34xx_temp.c
 @@ -0,0 +1,263 @@
 +/*
 + * omap34xx_temp.c - Linux kernel module for OMAP34xx hardware monitoring
 + *
 + * Copyright (C) 2008 Nokia Corporation
 + *
 + * Written by Peter De Schrijver peter.de-schrij...@nokia.com
 + *
 + * Inspired by k8temp.c
 + *
 + * This file is subject to the terms and conditions of the GNU General
 + * Public License. See the file COPYING in the main directory of this
 + * archive for more details.
 + *
 + * 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/clk.h
 +#include linux/hrtimer.h
 +#include linux/module.h
 +#include linux/hwmon.h
 +#include linux/hwmon-sysfs.h
 +#include linux/err.h
 +#include linux/platform_device.h
 +#include linux/io.h
 +#include linux/slab.h
 +
 +#include ../../arch/arm/mach-omap2/control.h

No need to do this, you can use syscon here like pbias-regulator.c
is doing.

Regards,

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

Re: [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig

[Tony Lindgren]

* Felipe Balbi ba...@ti.com [141226 07:29]:
 On Fri, Dec 26, 2014 at 03:04:00PM +0200, grygorii.stras...@linaro.org wrote:
  
   Tony, your call
  
  May be it will be good thing to split this patch. That way more
  information will be stored in commit log about which set of options
  gives us what benefits.  And also, It will allow to continue with
  agreed changes.  ?
 
 can be done, but then again, it's just a defconfig change. Tony, your
 call.
 
   I think we should move omap2plus_defconfig to be mostly modular and
   usable for distros as a base. Most distros prefer to build almost
   everything as loadable modules. And my preference is that we should
   only keep the minimum rootfs for devices and serial support as
   built-in and rely on initramfs for most drivers. And slowly move
   also the remaining built-in drivers to be loadable modules.
  
   The reasons for having drivers as loadable modules are many. It
   allows distros to use the same kernel for all the devices without
   bloating the kernel. It makes developing drivers easier as just the
   module needs to be reloaded. And loadable modules protect us from
   cross-framework spaghetti calls in the kernel as the interfaces are
   clearly defined.
  
   Are there people really using SATA as rootfs right now on omaps?
   
   Yes. That is exactly my point.
   
  
  From my side I'd like to note that I know about few ongoing projects
  on DRA7x EVM where SATA is used as rootfs - now It is the fast
  possible way to start Android.
 
 now this is something different. This is evidence that there are people
 relying on SATA on rootfs. I'll leave to Tony again.

OK sounds like people are really using SATA as rootfs, so we might as
well keep it built in then. And it does not affect the PM on the devices
that do have PM working, that has been a problem with having some
drivers built-in.

We can still work towards making the current rootfs device drivers
into loadable modules in the long term :)

Regards,

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

Re: [PATCH] add omap34xx temperature monitoring support

[Tony Lindgren]

* Tony Lindgren t...@atomide.com [141226 07:57]:
 * Pavel Machek pa...@ucw.cz [141226 02:32]:
  --- /dev/null
  +++ b/drivers/hwmon/omap34xx_temp.c
  @@ -0,0 +1,263 @@
  +/*
  + * omap34xx_temp.c - Linux kernel module for OMAP34xx hardware monitoring
  + *
  + * Copyright (C) 2008 Nokia Corporation
  + *
  + * Written by Peter De Schrijver peter.de-schrij...@nokia.com
  + *
  + * Inspired by k8temp.c
  + *
  + * This file is subject to the terms and conditions of the GNU General
  + * Public License. See the file COPYING in the main directory of this
  + * archive for more details.
  + *
  + * 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/clk.h
  +#include linux/hrtimer.h
  +#include linux/module.h
  +#include linux/hwmon.h
  +#include linux/hwmon-sysfs.h
  +#include linux/err.h
  +#include linux/platform_device.h
  +#include linux/io.h
  +#include linux/slab.h
  +
  +#include ../../arch/arm/mach-omap2/control.h
 
 No need to do this, you can use syscon here like pbias-regulator.c
 is doing.

Oh looks like you're already using syscon, nice. What defines do you
need from control.h?

Those should be in the driver if private to the driver, or else we
should have some minimal header in include/linux somewhere if some
control.h defines really need to be exposed.

Regards,

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

Re: [PATCH] add omap34xx temperature monitoring support

[Pali Rohár]

On Friday 26 December 2014 17:17:57 Tony Lindgren wrote:
 * Tony Lindgren t...@atomide.com [141226 07:57]:
  * Pavel Machek pa...@ucw.cz [141226 02:32]:
   --- /dev/null
   +++ b/drivers/hwmon/omap34xx_temp.c
   @@ -0,0 +1,263 @@
   +/*
   + * omap34xx_temp.c - Linux kernel module for OMAP34xx
   hardware monitoring + *
   + * Copyright (C) 2008 Nokia Corporation
   + *
   + * Written by Peter De Schrijver
   peter.de-schrij...@nokia.com + *
   + * Inspired by k8temp.c
   + *
   + * This file is subject to the terms and conditions of
   the GNU General + * Public License. See the file
   COPYING in the main directory of this + * archive for
   more details.
   + *
   + * 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/clk.h
   +#include linux/hrtimer.h
   +#include linux/module.h
   +#include linux/hwmon.h
   +#include linux/hwmon-sysfs.h
   +#include linux/err.h
   +#include linux/platform_device.h
   +#include linux/io.h
   +#include linux/slab.h
   +
   +#include ../../arch/arm/mach-omap2/control.h
  
  No need to do this, you can use syscon here like
  pbias-regulator.c is doing.
 
 Oh looks like you're already using syscon, nice. What defines
 do you need from control.h?
 
 Those should be in the driver if private to the driver, or
 else we should have some minimal header in include/linux
 somewhere if some control.h defines really need to be
 exposed.
 
 Regards,
 
 Tony

Hi Tony,

Sebastian Reichel has already sent new version of temperature 
driver. See email thread with subject:

[PATCH 0/3] OMAP3 temperature sensor

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig

[Felipe Balbi]

On Fri, Dec 26, 2014 at 08:13:49AM -0800, Tony Lindgren wrote:
 * Felipe Balbi ba...@ti.com [141226 07:29]:
  On Fri, Dec 26, 2014 at 03:04:00PM +0200, grygorii.stras...@linaro.org 
  wrote:
   
Tony, your call
   
   May be it will be good thing to split this patch. That way more
   information will be stored in commit log about which set of options
   gives us what benefits.  And also, It will allow to continue with
   agreed changes.  ?
  
  can be done, but then again, it's just a defconfig change. Tony, your
  call.
  
I think we should move omap2plus_defconfig to be mostly modular and
usable for distros as a base. Most distros prefer to build almost
everything as loadable modules. And my preference is that we should
only keep the minimum rootfs for devices and serial support as
built-in and rely on initramfs for most drivers. And slowly move
also the remaining built-in drivers to be loadable modules.
   
The reasons for having drivers as loadable modules are many. It
allows distros to use the same kernel for all the devices without
bloating the kernel. It makes developing drivers easier as just the
module needs to be reloaded. And loadable modules protect us from
cross-framework spaghetti calls in the kernel as the interfaces are
clearly defined.
   
Are there people really using SATA as rootfs right now on omaps?

Yes. That is exactly my point.

   
   From my side I'd like to note that I know about few ongoing projects
   on DRA7x EVM where SATA is used as rootfs - now It is the fast
   possible way to start Android.
  
  now this is something different. This is evidence that there are people
  relying on SATA on rootfs. I'll leave to Tony again.
 
 OK sounds like people are really using SATA as rootfs, so we might as
 well keep it built in then. And it does not affect the PM on the devices
 that do have PM working, that has been a problem with having some
 drivers built-in.
 
 We can still work towards making the current rootfs device drivers
 into loadable modules in the long term :)

Here's v3:

8---

From 7e6d99cedb12004bad1205bbaf556ebf3db0f730 Mon Sep 17 00:00:00 2001
From: Felipe Balbi ba...@ti.com
Date: Mon, 22 Dec 2014 11:56:27 -0600
Subject: [PATCH v3] arm: omap: reduce zImage size on omap2plus_defconfig

By converting a few drivers to modules because they
won't be needed during boot anyways, we can shave off
about 700KiB of text.

Note that while at that, and after discussions with Tony
Lindgren, a few extra drivers were either removed because
they weren't needed, or added because they're useful for
debugging/testing.

Below is output of size for pre and post vmlinux binaries:

   textdata bss dec hex filename
8514799  765532 8416064 1769639510e068b vmlinux-post-patch
9069110  800316 8419072 182884981170f72 vmlinux-pre-patch

Signed-off-by: Felipe Balbi ba...@ti.com
---

changes since v1:
- leave TWL4030 gpio alone

changes since v2:
- leave SATA as built-in

 arch/arm/configs/omap2plus_defconfig | 116 ++-
 1 file changed, 72 insertions(+), 44 deletions(-)

diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index c2c3a85..efb0810 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -13,7 +13,6 @@ CONFIG_CGROUP_FREEZER=y
 CONFIG_CGROUP_DEVICE=y
 CONFIG_CPUSETS=y
 CONFIG_CGROUP_CPUACCT=y
-CONFIG_RESOURCE_COUNTERS=y
 CONFIG_MEMCG=y
 CONFIG_MEMCG_SWAP=y
 CONFIG_MEMCG_KMEM=y
@@ -68,7 +67,6 @@ CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
 CONFIG_CPU_FREQ_GOV_POWERSAVE=y
 CONFIG_CPU_FREQ_GOV_USERSPACE=y
 CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
-CONFIG_GENERIC_CPUFREQ_CPU0=y
 # CONFIG_ARM_OMAP2PLUS_CPUFREQ is not set
 CONFIG_CPU_IDLE=y
 CONFIG_BINFMT_MISC=y
@@ -103,7 +101,7 @@ CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 CONFIG_DMA_CMA=y
 CONFIG_OMAP_OCP2SCP=y
-CONFIG_CONNECTOR=y
+CONFIG_CONNECTOR=m
 CONFIG_MTD=y
 CONFIG_MTD_CMDLINE_PARTS=y
 CONFIG_MTD_BLOCK=y
@@ -122,14 +120,12 @@ CONFIG_BLK_DEV_RAM=y
 CONFIG_BLK_DEV_RAM_SIZE=16384
 CONFIG_SENSORS_TSL2550=m
 CONFIG_BMP085_I2C=m
-CONFIG_SENSORS_LIS3_I2C=m
 CONFIG_SRAM=y
-CONFIG_SCSI=y
+CONFIG_SENSORS_LIS3_I2C=m
 CONFIG_BLK_DEV_SD=y
 CONFIG_SCSI_SCAN_ASYNC=y
 CONFIG_ATA=y
 CONFIG_SATA_AHCI_PLATFORM=y
-CONFIG_MD=y
 CONFIG_NETDEVICES=y
 # CONFIG_NET_VENDOR_ARC is not set
 # CONFIG_NET_CADENCE is not set
@@ -154,8 +150,8 @@ CONFIG_TI_CPSW=y
 # CONFIG_NET_VENDOR_WIZNET is not set
 CONFIG_AT803X_PHY=y
 CONFIG_SMSC_PHY=y
-CONFIG_USB_USBNET=y
-CONFIG_USB_NET_SMSC95XX=y
+CONFIG_USB_USBNET=m
+CONFIG_USB_NET_SMSC95XX=m
 CONFIG_USB_ALI_M5632=y
 CONFIG_USB_AN2720=y
 CONFIG_USB_EPSON2888=y
@@ -172,18 +168,22 @@ CONFIG_WLCORE_SDIO=m
 CONFIG_MWIFIEX=m
 CONFIG_MWIFIEX_SDIO=m
 CONFIG_MWIFIEX_USB=m
-CONFIG_INPUT_JOYDEV=y
-CONFIG_INPUT_EVDEV=y
-CONFIG_KEYBOARD_GPIO=y

Re: [PATCH] add omap34xx temperature monitoring support

[Tony Lindgren]

* Pali Rohár pali.ro...@gmail.com [141226 08:29]:
 On Friday 26 December 2014 17:17:57 Tony Lindgren wrote:
+
+#include ../../arch/arm/mach-omap2/control.h
   
   No need to do this, you can use syscon here like
   pbias-regulator.c is doing.
  
  Oh looks like you're already using syscon, nice. What defines
  do you need from control.h?
  
  Those should be in the driver if private to the driver, or
  else we should have some minimal header in include/linux
  somewhere if some control.h defines really need to be
  exposed.
  
  Regards,
  
  Tony
 
 Hi Tony,
 
 Sebastian Reichel has already sent new version of temperature 
 driver. See email thread with subject:
 
 [PATCH 0/3] OMAP3 temperature sensor

Yeah great, looks like I was also reading Sebastian's patch
with the syscon comments above :)

Regards,

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

Re: [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig

[Igor Grinberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/26/14 17:09, Felipe Balbi wrote:
 Hi,
 
 On Fri, Dec 26, 2014 at 01:56:26PM +0200, Igor Grinberg wrote:
 Tony, your call.

 I think we should move omap2plus_defconfig to be mostly modular and
 usable for distros as a base. Most distros prefer to build almost
 everything as loadable modules. And my preference is that we should
 only keep the minimum rootfs for devices and serial support as
 built-in and rely on initramfs for most drivers. And slowly move
 also the remaining built-in drivers to be loadable modules.

 The reasons for having drivers as loadable modules are many. It
 allows distros to use the same kernel for all the devices without
 bloating the kernel. It makes developing drivers easier as just the
 module needs to be reloaded. And loadable modules protect us from
 cross-framework spaghetti calls in the kernel as the interfaces are 
 clearly defined.

 Are there people really using SATA as rootfs right now on omaps?

 Yes. That is exactly my point.

 read your email, you said it *CAN* have rootfs on SATA.

 yep, it also *CAN* have rootfs on MMC and NFS and ...
 
 those we *know* people are using as rootfs. We know of several users who
 are actually using it :-)

I think we've had enough of the *can* or *cannot* stuff...
So, just accept that people are using SATA as rootfs and will be using
it in the future products too.

 
 If it's only something that will be more widely used in the future,
 then I suggest we make it into a loadable module, and presume
 initramfs and loadable module also for any new devices. The same
 way x86 has been doing with distros for years.

 The difference from x86 is that we're in embedded here and

 bullshit, you would never ship a product with omap2plus_defconfig. You'd
 build your own at which point you would switch SATA to built-in.

 Yep, that is one of the options indeed, but I'm not asking you to
 deal with my problems, right?
 I'm feeling like you are trying to insult me.
 Are you angry with me? Why?
 Is it because I have a different opinion?
 
 heh, cute :-)

so this is what it takes to calm you down? good!

 
 although initramfs is a kind of option, but it means, you need to
 load even more data during the boot process... it is annoying and
 I would not want to use it on embedded.

 make your own defconfig.

 This sounds like: mind your own business...
 Is that what you want to say?
 
 nope, not really.

good!

 Just saying that if you're really concerned about
 being embedded and that initramfs takes that much more time to load,
 you'd just make your own defconfig and maintain it out-of-tree.
 
 RMK does that for quite a few boards, I do it for my boards and also for
 my x86 desktops/laptops.
 
 It's not really rocket science.

Yes indeed. We do this *all* the time.
To understand what is this about, first you need to make yourself
familiar with the case.

 
 (BTW, x86_64_defconfig has it compiled in...)

 We can also, split the defconfig as it was some time ago... but I
 would not want to go that direction...

 If we go the initramfs way, then why not also load MMC from it?
 That will also reduce kernel size... (but add initramfs size)

 I'm fine with that. The difference is that people have been relying on
 MMC built-in for the past 10+ years, since the old OMAP1 MMC driver,
 changing that now is likely to cause some my board won't boot anymore
 bug reports.

 Yep. So there are exceptions, right?
 
 never claimed the contrary.

So, those exactly kind of bug reports I'm expecting to get, once you
compile out SATA...

 
 I'm sure you will find making the MMC a loadable module inconvenient.
 That how I find making the SATA a loadable module...

 Right now, we tell our customers that they can use mainline with
 omap2plus_defconfig.

 that's the worst thing you can do.

 Hmmm... Interesting, so people should not use mainline.
 
 now you're reading what you want to read ;-) Using my statements out of
 context.

I'm sorry, but you seemed to not care about the context, but just call
stuff a BS or worst thing to do... and that is w/o even understanding
the case.

 
 It's clear (actually s/rootfs/defconfig below) that I meant defconfig.
 

Well, no, I'm sorry it is not clear, but I accept the amendment.

 You should at a minimum provide your
 customers with a more minimal rootfs. Why would you have your customers
 
 oh wait, not rootfs, defconfig.
 
 build MUSB on an OMAP5 board ? Why would they build 5 different
 network device drivers ? Why would they build almost every single PMIC
 we ever used ? The list goes on and on.

 That is their decision to make. I'm just saying that they can use it.
 
 right, and they can switch SATA to built-in if they want to ship an
 initramfs-less product, don't you think ?

no. It *very* depends on who your customer is and sometimes compiling
kernel with provided defaults is fine, but changing those is not.
You can say, come on... if they build the kernel, they can also change

Re: [PATCH 1/3] DT Binding for omap3 temperature sensor

[Pavel Machek]

On Fri 2014-12-26 13:34:52, Sebastian Reichel wrote:
 OMAP34xx and OMAP36xx processors contain a register in the syscon area,
 which can be used to determine the SoCs temperature. This provides a
 DT binding specification for the temperature monitor.
 
 Signed-off-by: Sebastian Reichel s...@kernel.org
 ---
  .../bindings/hwmon/omap3-temperature.txt   | 25 
 ++
  1 file changed, 25 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
 
 diff --git a/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt 
 b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
 new file mode 100644
 index 000..99631ad
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
 @@ -0,0 +1,25 @@
 +* OMAP3 temperature sensor
 +
 +The OMAP34xx and OMAP36xx processors contain a register in the syscon area,
 +which can be used to determine the SoCs temperature.
 +
 +Requires node properties:
 +- compatible :   should contain one of
 + - ti,omap34xx-temperature-sensor for OMAP34xx
 + - ti,omap36xx-temperature-sensor for OMAP36xx
 +- syscon :   Should be a phandle to system configuration node which
 + encompases the temperature register
 +- clocks :   Should contain 32KHz fclk clock specifier
 +- clock-names :  Should contain clock names
 + - fck for the 32KHz fclk clock specifier

I don't quite get it. The temperature sensor is internal on the CPU,
right? Why do we need device tree to describe it? As soon as we have
CPU that is compatible to ti,omap3430, we know everything we need to
know, no?

 +Example for omap34xx:
 +
 +/ {
 + temperature-sensor {
 + compatible = ti,omap34xx-temperature-sensor;
 + syscon = omap3_scm_general;
 + clocks = ts_fck;
 + clock-names = fck;
 + };
 +};

Or is there something that depends on the board there? Or do we want
to do it like this to be consistent with existing bindings?

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] hwmon: Driver for OMAP3 temperature sensor

[Pavel Machek]

On Fri 2014-12-26 13:34:53, Sebastian Reichel wrote:
 OMAP34xx and OMAP36xx processors contain a register in the syscon area,
 which can be used to determine the SoCs temperature. This patch provides
 a DT based driver for the temperature sensor based on an older driver
 written by Peter De Schrijver for the Nokia N900 and N9.
 
 Signed-off-by: Sebastian Reichel s...@kernel.org

 + if (!data-valid || time_after(jiffies, data-last_updated + HZ)) {
 + clk_enable(data-clk_32k);

This needs to be clk_prepare_enable()

 + regmap_update_bits(data-syscon, SYSCON_TEMP_REG,
 +soc_mask, soc_mask);
 +
 + if (!wait_for_eocz(EOCZ_MIN_RISING_DELAY,
 + EOCZ_MAX_RISING_DELAY, 1, data)) {
 + e = -EIO;
 + goto err;
 + }
 +
 + regmap_update_bits(data-syscon, SYSCON_TEMP_REG, soc_mask, 0);
 +
 + if (!wait_for_eocz(EOCZ_MIN_FALLING_DELAY,
 + EOCZ_MAX_FALLING_DELAY, 0, data)) {
 + e = -EIO;
 + goto err;
 + }
 +
 + regmap_read(data-syscon, SYSCON_TEMP_REG, temp_sensor_reg);
 + data-temperature = temp_sensor_reg  ((17) - 1);
 + data-last_updated = jiffies;
 + data-valid = true;
 +
 +err:
 + clk_disable(data-clk_32k);

And this clk_disable_unprepare().

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] media: i2c/adp1653: devicetree support for adp1653

[Rob Herring]

On Wed, Dec 24, 2014 at 4:34 PM, Pavel Machek pa...@ucw.cz wrote:

 We are moving to device tree support on OMAP3, but that currently
 breaks ADP1653 driver. This adds device tree support, plus required
 documentation.

 Signed-off-by: Pavel Machek pa...@ucw.cz

 ---

 Changed -microsec to -us, as requested by devicetree people.

 Fixed checkpatch issues.

 diff --git a/Documentation/devicetree/bindings/leds/common.txt 
 b/Documentation/devicetree/bindings/leds/common.txt
 index 2d88816..2c6c7c5 100644
 --- a/Documentation/devicetree/bindings/leds/common.txt
 +++ b/Documentation/devicetree/bindings/leds/common.txt
 @@ -14,6 +14,15 @@ Optional properties for child nodes:
   ide-disk - LED indicates disk activity
   timer - LED flashes at a fixed, configurable rate

 +- max-microamp : maximum intensity in microamperes of the LED
 +(torch LED for flash devices)
 +- flash-max-microamp : maximum intensity in microamperes of the
 +   flash LED; it is mandatory if the LED should
 +  support the flash mode
 +- flash-timeout-microsec : timeout in microseconds after which the flash
 +   LED is turned off

Doesn't all this go in your flash led binding patch?

 +
 +
  Examples:

  system-status {
 @@ -21,3 +30,10 @@ system-status {
 linux,default-trigger = heartbeat;
 ...
  };
 +
 +camera-flash {
 +   label = Flash;
 +   max-microamp = 5;
 +   flash-max-microamp = 32;
 +   flash-timeout-microsec = 50;
 +}
 diff --git a/Documentation/devicetree/bindings/media/i2c/adp1653.txt 
 b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
 new file mode 100644
 index 000..3c7065f
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
 @@ -0,0 +1,38 @@
 +* Analog Devices ADP1653 flash LED driver
 +
 +Required Properties:
 +
 +  - compatible: Must contain one of the following
 +- adi,adp1653
 +
 +  - reg: I2C slave address
 +
 +  - gpios: References to the GPIO that controls the power for the chip.
 +
 +There are two led outputs available - flash and indicator. One led is
 +represented by one child node, nodes need to be named flash and 
 indicator.
 +
 +Required properties of the LED child node:
 +- max-microamp : see Documentation/devicetree/bindings/leds/common.txt
 +
 +Required properties of the flash LED child node:
 +
 +- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
 +- flash-timeout-us : see Documentation/devicetree/bindings/leds/common.txt
 +
 +Example:
 +
 +adp1653: led-controller@30 {
 +compatible = adi,adp1653;
 +   reg = 0x30;
 +gpios = gpio3 24 GPIO_ACTIVE_HIGH; /* 88 */
 +
 +   flash {
 +flash-timeout-us = 50;
 +flash-max-microamp = 32;
 +max-microamp = 5;
 +   };
 +indicator {

These are different LEDs or different modes?

 +max-microamp = 17500;

This is a bit inconsistent. The binding says this is for flash LEDs
torch mode, but I see no reason why it can't be common. Can you update
the binding doc to be clear here.

Also, aren't you missing label properties?

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

[PATCH 5/5] arm: omap2plus_defconfig: enable TPS65218 power button

[Felipe Balbi]

Enable tps65218 power button driver by default as
a dynamically linked module so AM437x SK can report
power button presses.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 arch/arm/configs/omap2plus_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index c2c3a85..f4a4b2f 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -183,6 +183,7 @@ CONFIG_TOUCHSCREEN_EDT_FT5X06=m
 CONFIG_TOUCHSCREEN_TSC2005=m
 CONFIG_TOUCHSCREEN_TSC2007=m
 CONFIG_INPUT_MISC=y
+CONFIG_INPUT_TPS65218_PWRBUTTON=m
 CONFIG_INPUT_TWL4030_PWRBUTTON=y
 # CONFIG_LEGACY_PTYS is not set
 CONFIG_SERIAL_8250=y
-- 
2.2.0

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

[PATCH 0/5] AM437x SK: Add power-button support

[Felipe Balbi]

Hi,

the following patches add tps65218 power button support and
make it usable with AM437x SK.

Developed and tested on top of v3.19-rc1. Logs at [1]

[1] http://hastebin.com/ecopenuqot

Felipe Balbi (5):
  mfd: tps65218: make INT[12] and STATUS registers volatile
  mfd: tps65218: make INT1 our status_base register
  input: misc: add tps65218 power button driver
  arm: boot: dts: am437x-sk: add power button binding
  arm: omap2plus_defconfig: enable TPS65218 power button

 arch/arm/boot/dts/am437x-sk-evm.dts |   5 ++
 arch/arm/configs/omap2plus_defconfig|   1 +
 drivers/input/misc/Kconfig  |  10 +++
 drivers/input/misc/Makefile |   1 +
 drivers/input/misc/tps65218-pwrbutton.c | 135 
 drivers/mfd/tps65218.c  |  12 +++
 6 files changed, 164 insertions(+)
 create mode 100644 drivers/input/misc/tps65218-pwrbutton.c

-- 
2.2.0

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

[PATCH 1/5] mfd: tps65218: make INT[12] and STATUS registers volatile

[Felipe Balbi]

STATUS register can be modified by the HW, so we
should bypass cache because of that.

In the case of INT[12] registers, they are the ones
that actually clear the IRQ source at the time they
are read. If we rely on the cache for them, we will
never be able to clear the interrupt, which will cause
our IRQ line to be disabled due to IRQ throttling.

Fixes: 44b4dc6 mfd: tps65218: Add driver for the TPS65218 PMIC
Cc: sta...@vger.kernel.org # v3.15+
Cc: Keerthy j-keer...@ti.com
Cc: Lee Jones lee.jo...@linaro.org
Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/mfd/tps65218.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
index 0d256cb..2243f75 100644
--- a/drivers/mfd/tps65218.c
+++ b/drivers/mfd/tps65218.c
@@ -125,10 +125,21 @@ int tps65218_clear_bits(struct tps65218 *tps, unsigned 
int reg,
 }
 EXPORT_SYMBOL_GPL(tps65218_clear_bits);
 
+static const struct regmap_range tps65218_yes_ranges[] = {
+   regmap_reg_range(TPS65218_REG_INT1, TPS65218_REG_INT2),
+   regmap_reg_range(TPS65218_REG_STATUS, TPS65218_REG_STATUS),
+};
+
+static const struct regmap_access_table tps65218_volatile_table = {
+   .yes_ranges = tps65218_yes_ranges,
+   .n_yes_ranges = ARRAY_SIZE(tps65218_yes_ranges),
+};
+
 static struct regmap_config tps65218_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
.cache_type = REGCACHE_RBTREE,
+   .volatile_table = tps65218_volatile_table,
 };
 
 static const struct regmap_irq tps65218_irqs[] = {
-- 
2.2.0

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

[PATCH 2/5] mfd: tps65218: make INT1 our status_base register

[Felipe Balbi]

If we don't tell regmap-irq that our first status
register is at offset 1, it will try to read offset
zero, which is the chipid register.

Fixes: 44b4dc6 mfd: tps65218: Add driver for the TPS65218 PMIC
Cc: sta...@vger.kernel.org # v3.15+
Cc: Keerthy j-keer...@ti.com
Cc: Lee Jones lee.jo...@linaro.org
Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/mfd/tps65218.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mfd/tps65218.c b/drivers/mfd/tps65218.c
index 2243f75..d6b7643 100644
--- a/drivers/mfd/tps65218.c
+++ b/drivers/mfd/tps65218.c
@@ -204,6 +204,7 @@ static struct regmap_irq_chip tps65218_irq_chip = {
 
.num_regs = 2,
.mask_base = TPS65218_REG_INT_MASK1,
+   .status_base = TPS65218_REG_INT1,
 };
 
 static const struct of_device_id of_tps65218_match_table[] = {
-- 
2.2.0

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

[PATCH 3/5] input: misc: add tps65218 power button driver

[Felipe Balbi]

With this driver, we can report KEY_POWER on
AM437x SK. This patch has been tested with said
board.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 drivers/input/misc/Kconfig  |  10 +++
 drivers/input/misc/Makefile |   1 +
 drivers/input/misc/tps65218-pwrbutton.c | 135 
 3 files changed, 146 insertions(+)
 create mode 100644 drivers/input/misc/tps65218-pwrbutton.c

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 23297ab..364cfb8 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -404,6 +404,16 @@ config INPUT_RETU_PWRBUTTON
  To compile this driver as a module, choose M here. The module will
  be called retu-pwrbutton.
 
+config INPUT_TPS65218_PWRBUTTON
+   tristate TPS65218 Power button driver
+   depends on MFD_TPS65218
+   help
+ Say Y here if you want to enable power buttong reporting for
+ the TPS65218 Power Management IC device.
+
+ To compile this driver as a module, choose M here. The module will
+ be called tps65218-pwrbutton.
+
 config INPUT_TWL4030_PWRBUTTON
tristate TWL4030 Power button Driver
depends on TWL4030_CORE
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 19c7603..a923753 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -59,6 +59,7 @@ obj-$(CONFIG_INPUT_SGI_BTNS)  += sgi_btns.o
 obj-$(CONFIG_INPUT_SIRFSOC_ONKEY)  += sirfsoc-onkey.o
 obj-$(CONFIG_INPUT_SOC_BUTTON_ARRAY)   += soc_button_array.o
 obj-$(CONFIG_INPUT_SPARCSPKR)  += sparcspkr.o
+obj-$(CONFIG_INPUT_TPS65218_PWRBUTTON) += tps65218-pwrbutton.o
 obj-$(CONFIG_INPUT_TWL4030_PWRBUTTON)  += twl4030-pwrbutton.o
 obj-$(CONFIG_INPUT_TWL4030_VIBRA)  += twl4030-vibra.o
 obj-$(CONFIG_INPUT_TWL6040_VIBRA)  += twl6040-vibra.o
diff --git a/drivers/input/misc/tps65218-pwrbutton.c 
b/drivers/input/misc/tps65218-pwrbutton.c
new file mode 100644
index 000..a1f8a19
--- /dev/null
+++ b/drivers/input/misc/tps65218-pwrbutton.c
@@ -0,0 +1,135 @@
+/*
+ * Texas Instruments' TPS65218 Power Button Input Driver
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: Felipe Balbi ba...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/init.h
+#include linux/input.h
+#include linux/interrupt.h
+#include linux/kernel.h
+#include linux/mfd/tps65218.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/slab.h
+
+struct tps65218_pwrbutton {
+   struct device *dev;
+   struct tps65218 *tps;
+   struct input_dev *idev;
+   int irq;
+
+   unsigned int pressed:1;
+};
+
+static irqreturn_t tps65218_pwr_irq(int irq, void *_pwr)
+{
+   struct tps65218_pwrbutton *pwr = _pwr;
+   unsigned int reg;
+   int ret;
+
+   ret = tps65218_reg_read(pwr-tps, TPS65218_REG_STATUS, reg);
+   if (ret) {
+   dev_err(pwr-dev, can't read register -- %d\n, ret);
+   goto out;
+   }
+
+   if (reg  TPS65218_STATUS_PB_STATE) {
+   input_report_key(pwr-idev, KEY_POWER, 1);
+   pm_wakeup_event(pwr-dev, 0);
+   pwr-pressed = true;
+   } else {
+   /*
+* we don't want to report KEY_POWER releases on any of the
+* other IRQ sources. Only when button was previously pressed
+*/
+   if (pwr-pressed) {
+   input_report_key(pwr-idev, KEY_POWER, 0);
+   pwr-pressed = false;
+   }
+   }
+
+   input_sync(pwr-idev);
+
+out:
+   return IRQ_HANDLED;
+}
+
+static int tps65218_pwron_probe(struct platform_device *pdev)
+{
+   struct tps65218 *tps = dev_get_drvdata(pdev-dev.parent);
+   struct device *dev = pdev-dev;
+   struct tps65218_pwrbutton *pwr;
+   struct input_dev *idev;
+   int ret;
+
+   pwr = devm_kzalloc(dev, sizeof(*pwr), GFP_KERNEL);
+   if (!pwr)
+   return -ENOMEM;
+
+   idev = devm_input_allocate_device(dev);
+   if (!idev)
+   return -ENOMEM;
+
+   idev-name = tps65218_pwrbutton;
+   idev-phys = tps65218_pwrbutton/input0;
+   idev-dev.parent = dev;
+   idev-id.bustype = BUS_I2C;
+
+   input_set_capability(idev, EV_KEY, KEY_POWER);
+
+   pwr-tps = tps;
+   pwr-dev = dev;
+   pwr-idev = idev;
+   pwr-irq = platform_get_irq(pdev, 0);
+   platform_set_drvdata(pdev, pwr);
+   

[PATCH 4/5] arm: boot: dts: am437x-sk: add power button binding

[Felipe Balbi]

Let this board report KEY_POWER so upper layers
can decide what to do when power button is pressed.

Signed-off-by: Felipe Balbi ba...@ti.com
---
 arch/arm/boot/dts/am437x-sk-evm.dts | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts 
b/arch/arm/boot/dts/am437x-sk-evm.dts
index 53bbfc9..c53840c 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -386,6 +386,11 @@
regulator-always-on;
};
 
+   power-button {
+   compatible = ti,tps65218-pwrbutton;
+   status = okay;
+   interrupts = 3 IRQ_TYPE_EDGE_BOTH;
+   };
};
 
at24@50 {
-- 
2.2.0

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

Re: [PATCH 3/5] input: misc: add tps65218 power button driver

[Felipe Balbi]

Hi,

On Fri, Dec 26, 2014 at 01:28:22PM -0600, Felipe Balbi wrote:
 +static struct of_device_id of_tps65218_pwr_match[] = {
 + { .compatible = ti,tps65218-pwrbutton },

forgot to document this compatible. I'll add it localy but still wait a
a few days before resending so people have time to review.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig

[Javier Martinez Canillas]

Hello Felipe,

On Fri, Dec 26, 2014 at 4:19 PM, Felipe Balbi ba...@ti.com wrote:

 I wonder the same thing, but look at multi_v7_defconfig today. Almost
 everything is built-in, which makes the kernel image enormous (5.5MiB).

 to get rid of the SoC specific configs then and just use the single
 ARMv7 defconfig for all SoCs with most of the options enabled as a
 module?

 if people accept switching some of those as modules, sure. I don't mind
 that at all. I'll still continue to maintain my out-of-tree defconfigs
 for my boards anyway. It's also very good to have a generic defconfig
 which will just work with everything I have.

 FYI, some time ago I posted a patch to enable SBS-compliant batteries
 support as a module for Exynos defconfig and was told to re-spin the
 patch and enabling it as built-in instead since the most popular use
 case for exynos_defconfig was development and people usually just copy
 the kernel binary and not the modules [0].

 lol, that's the reason why I don't use multi_v7_defconfig.


Agreed, on its current form I wonder what's the use case for
multi_v7_defconfig. I guess most options will slowly be changed to be
built as a module though to be similar to what distros do.

 can use omap2plus_defconfig as a base. So, is or is not expected that
 people will use omap2plus_defconfig as a base for their own config?

 I never claimed that people should not use it as a *base*, rather it
 should not be used to build a product's kernel/modules. Imagine you
 shipping an embedded product based off of OMAP5 and you add CPSW, QSPI,
 MUSB, a ton of touchscreen drivers you don't use, several PMIC drivers
 built-in, etc. It's a waste of space and just bloats that product's
 zImage.


Got it, thanks for the clarification. I agree that omap2plus_defconfig
is very bloated to be used for products as-is. I also have custom
defconfig to test the OMAP boards I maintain which is basically
omap2plus_defconfig + a merged config fragment (using merge_config.sh)
that disables and enables needed options.

 I think the problem is that there isn't an agreement about what is the
 purpose of the per SoC (e.g: oma2plus_defconfig) and the multi_v7
 defconfigs (or at least is not well documented since I could not find
 it). So, IMHO this concern should be raised to the ARM SoC maintainers
 and there should be an agreement in the ARM community as a whole about
 how things should be configured on each defconfig, and all SoCs should
 follow the agreed rule.

 OTOH, the OMAP defconfig is part of the OMAP port and Tony will have the
 final saying about it, right ?


Sorry, I didn't mean that Tony doesn't have the last word for omap
defconfig. My point was that it should be nice to get a consensus
about this and specially document it to make life easier for everyone.
People posting defconfig changes will know what the rule is and we can
avoid having these kind of discussions which I have had many times in
the past when posting defconfig changes and I'm sure I will have more
in the future again.

But I don't really mind tbh, I will keep maintaining my custom
defconfigs anyways and post wnen I think that enabling a config option
in a mainline defconfig makes sense and will do as a module or
built-in depending of what the SoC maintainer tells me to use.

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

Re: [PATCH] arm: omap: reduce zImage size on omap2plus_defconfig

[Felipe Balbi]

Hi,

On Fri, Dec 26, 2014 at 08:38:10PM +0100, Javier Martinez Canillas wrote:
  I wonder the same thing, but look at multi_v7_defconfig today. Almost
  everything is built-in, which makes the kernel image enormous (5.5MiB).
 
  to get rid of the SoC specific configs then and just use the single
  ARMv7 defconfig for all SoCs with most of the options enabled as a
  module?
 
  if people accept switching some of those as modules, sure. I don't mind
  that at all. I'll still continue to maintain my out-of-tree defconfigs
  for my boards anyway. It's also very good to have a generic defconfig
  which will just work with everything I have.
 
  FYI, some time ago I posted a patch to enable SBS-compliant batteries
  support as a module for Exynos defconfig and was told to re-spin the
  patch and enabling it as built-in instead since the most popular use
  case for exynos_defconfig was development and people usually just copy
  the kernel binary and not the modules [0].
 
  lol, that's the reason why I don't use multi_v7_defconfig.
 
 
 Agreed, on its current form I wonder what's the use case for
 multi_v7_defconfig. I guess most options will slowly be changed to be
 built as a module though to be similar to what distros do.

that's the idea with omap2plus_defconfig, at least. Last I talked with
Tony, the idea was let's have a defconfig which distros can just use
and almost everything is built as a module.

  can use omap2plus_defconfig as a base. So, is or is not expected that
  people will use omap2plus_defconfig as a base for their own config?
 
  I never claimed that people should not use it as a *base*, rather it
  should not be used to build a product's kernel/modules. Imagine you
  shipping an embedded product based off of OMAP5 and you add CPSW, QSPI,
  MUSB, a ton of touchscreen drivers you don't use, several PMIC drivers
  built-in, etc. It's a waste of space and just bloats that product's
  zImage.
 
 
 Got it, thanks for the clarification. I agree that omap2plus_defconfig
 is very bloated to be used for products as-is. I also have custom
 defconfig to test the OMAP boards I maintain which is basically
 omap2plus_defconfig + a merged config fragment (using merge_config.sh)
 that disables and enables needed options.

right, I used to that too. But right now I just have a set of
config-$board which I maintain locally. Slowly moving to
omap2plus_defconfig only as I move all my boards to NFS root.

  I think the problem is that there isn't an agreement about what is the
  purpose of the per SoC (e.g: oma2plus_defconfig) and the multi_v7
  defconfigs (or at least is not well documented since I could not find
  it). So, IMHO this concern should be raised to the ARM SoC maintainers
  and there should be an agreement in the ARM community as a whole about
  how things should be configured on each defconfig, and all SoCs should
  follow the agreed rule.
 
  OTOH, the OMAP defconfig is part of the OMAP port and Tony will have the
  final saying about it, right ?
 
 
 Sorry, I didn't mean that Tony doesn't have the last word for omap
 defconfig. My point was that it should be nice to get a consensus
 about this and specially document it to make life easier for everyone.

definitely, we need at least some documentation. No questions there.

 People posting defconfig changes will know what the rule is and we can
 avoid having these kind of discussions which I have had many times in
 the past when posting defconfig changes and I'm sure I will have more
 in the future again.

right.

 But I don't really mind tbh, I will keep maintaining my custom
 defconfigs anyways and post wnen I think that enabling a config option
 in a mainline defconfig makes sense and will do as a module or
 built-in depending of what the SoC maintainer tells me to use.

yeah, that's the downside, really. One maintainer prefers small zImage
with several modules (which I very much like the idea) while another
prefers giant zImage with virtually no modules :-)

cheers

-- 
balbi


signature.asc
Description: Digital signature

[PATCH] ARM: OMAP: DTS: N950/N9: add twl_power

[Aaro Koskinen]

Add twl_power for N950/N9. Start with the simplest configuration to just
enable power off.

Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
 arch/arm/boot/dts/omap3-n950-n9.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi 
b/arch/arm/boot/dts/omap3-n950-n9.dtsi
index 1e49dfe..c41db94 100644
--- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
+++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
@@ -60,6 +60,11 @@
 
 twl {
compatible = ti,twl5031;
+
+   twl_power: power {
+   compatible = ti,twl4030-power;
+   ti,use_poweroff;
+   };
 };
 
 twl_gpio {
-- 
2.2.0

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

Re: [PATCHv2] media: i2c/adp1653: devicetree support for adp1653

[Pavel Machek]

Hi!

  We are moving to device tree support on OMAP3, but that currently
  breaks ADP1653 driver. This adds device tree support, plus required
  documentation.
 
  Signed-off-by: Pavel Machek pa...@ucw.cz
 
  ---
 
  Changed -microsec to -us, as requested by devicetree people.
 
  Fixed checkpatch issues.
 
  diff --git a/Documentation/devicetree/bindings/leds/common.txt 
  b/Documentation/devicetree/bindings/leds/common.txt
  index 2d88816..2c6c7c5 100644
  --- a/Documentation/devicetree/bindings/leds/common.txt
  +++ b/Documentation/devicetree/bindings/leds/common.txt
  @@ -14,6 +14,15 @@ Optional properties for child nodes:
ide-disk - LED indicates disk activity
timer - LED flashes at a fixed, configurable rate
 
  +- max-microamp : maximum intensity in microamperes of the LED
  +(torch LED for flash devices)
  +- flash-max-microamp : maximum intensity in microamperes of the
  +   flash LED; it is mandatory if the LED should
  +  support the flash mode
  +- flash-timeout-microsec : timeout in microseconds after which the flash
  +   LED is turned off
 
 Doesn't all this go in your flash led binding patch?

No, I should not have included this part.

  +Example:
  +
  +adp1653: led-controller@30 {
  +compatible = adi,adp1653;
  +   reg = 0x30;
  +gpios = gpio3 24 GPIO_ACTIVE_HIGH; /* 88 */
  +
  +   flash {
  +flash-timeout-us = 50;
  +flash-max-microamp = 32;
  +max-microamp = 5;
  +   };
  +indicator {
 
 These are different LEDs or different modes?

flash  indicator are different LEDs. One is white, one is red. Flash
can be used as a flash and as a torch.

  +max-microamp = 17500;
 
 This is a bit inconsistent. The binding says this is for flash LEDs
 torch mode, but I see no reason why it can't be common. Can you update
 the binding doc to be clear here.

By inconsisnent, you mean you want patch below?

 Also, aren't you missing label properties?

label is optional, and as my driver does not yet use it, I forgot
about it.

Signed-off-by: Pavel Machek pa...@ucw.cz

index 2c6c7c5..92d4dac 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -15,7 +15,6 @@ Optional properties for child nodes:
  timer - LED flashes at a fixed, configurable rate
 
 - max-microamp : maximum intensity in microamperes of the LED
-(torch LED for flash devices)
 - flash-max-microamp : maximum intensity in microamperes of the
flash LED; it is mandatory if the LED should
   support the flash mode


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] arm: boot: dts: am437x-idk: add gpio-based power key

[Felipe Balbi]

AM437x IDK board has a User Switch which we can
program to whatever we want. Because this board
doesn't have a PMIC which can give us power button
presses, let's use this user switch as a gpio-keys
power button.

Signed-off-by: Felipe Balbi ba...@ti.com
---

depends on [1]. Boot logs at [2]. Note that this can rather easily
be folded into the original patch if so desired.

[1] http://marc.info/?l=linux-omapm=141928747902983w=2
[2] http://hastebin.com/xasuyinizu

 arch/arm/boot/dts/am437x-idk-evm.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/am437x-idk-evm.dts 
b/arch/arm/boot/dts/am437x-idk-evm.dts
index b52dd0a..86f6219 100644
--- a/arch/arm/boot/dts/am437x-idk-evm.dts
+++ b/arch/arm/boot/dts/am437x-idk-evm.dts
@@ -96,6 +96,18 @@
regulator-boot-on;
vin-supply = v1_5dreg;
};
+
+   gpio_keys: gpio_keys {
+   compatible = gpio-keys;
+   #address-cells = 1;
+   #size-cells = 0;
+
+   switch@0 {
+   label = power-button;
+   linux,code = KEY_POWER;
+   gpios = gpio4 2 GPIO_ACTIVE_LOW;
+   };
+   };
 };
 
 am43xx_pinmux {
-- 
2.2.0

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

Re: [PATCHv2] media: i2c/adp1653: devicetree support for adp1653

[Rob Herring]

On Fri, Dec 26, 2014 at 2:33 PM, Pavel Machek pa...@ucw.cz wrote:
 Hi!

  We are moving to device tree support on OMAP3, but that currently
  breaks ADP1653 driver. This adds device tree support, plus required
  documentation.
 
  Signed-off-by: Pavel Machek pa...@ucw.cz
 
  ---
 
  Changed -microsec to -us, as requested by devicetree people.
 
  Fixed checkpatch issues.
 
  diff --git a/Documentation/devicetree/bindings/leds/common.txt 
  b/Documentation/devicetree/bindings/leds/common.txt
  index 2d88816..2c6c7c5 100644
  --- a/Documentation/devicetree/bindings/leds/common.txt
  +++ b/Documentation/devicetree/bindings/leds/common.txt
  @@ -14,6 +14,15 @@ Optional properties for child nodes:
ide-disk - LED indicates disk activity
timer - LED flashes at a fixed, configurable rate
 
  +- max-microamp : maximum intensity in microamperes of the LED
  +(torch LED for flash devices)
  +- flash-max-microamp : maximum intensity in microamperes of the
  +   flash LED; it is mandatory if the LED should
  +  support the flash mode
  +- flash-timeout-microsec : timeout in microseconds after which the flash
  +   LED is turned off

 Doesn't all this go in your flash led binding patch?

 No, I should not have included this part.

  +Example:
  +
  +adp1653: led-controller@30 {
  +compatible = adi,adp1653;
  +   reg = 0x30;
  +gpios = gpio3 24 GPIO_ACTIVE_HIGH; /* 88 */
  +
  +   flash {
  +flash-timeout-us = 50;
  +flash-max-microamp = 32;
  +max-microamp = 5;
  +   };
  +indicator {

 These are different LEDs or different modes?

 flash  indicator are different LEDs. One is white, one is red. Flash
 can be used as a flash and as a torch.

  +max-microamp = 17500;

 This is a bit inconsistent. The binding says this is for flash LEDs
 torch mode, but I see no reason why it can't be common. Can you update
 the binding doc to be clear here.

 By inconsisnent, you mean you want patch below?

Yes.

 Also, aren't you missing label properties?

 label is optional, and as my driver does not yet use it, I forgot
 about it.

Based on your node names, there are obviously user defined functions
for them already. So they should have labels whether or not the driver
uses them.

Rob

 Signed-off-by: Pavel Machek pa...@ucw.cz

 index 2c6c7c5..92d4dac 100644
 --- a/Documentation/devicetree/bindings/leds/common.txt
 +++ b/Documentation/devicetree/bindings/leds/common.txt
 @@ -15,7 +15,6 @@ Optional properties for child nodes:
   timer - LED flashes at a fixed, configurable rate

  - max-microamp : maximum intensity in microamperes of the LED
 -(torch LED for flash devices)
  - flash-max-microamp : maximum intensity in microamperes of the
 flash LED; it is mandatory if the LED should
support the flash mode


 --
 (english) http://www.livejournal.com/~pavelmachek
 (cesky, pictures) 
 http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] arm: boot: dts: am437x-idk: add gpio-based power key

[Felipe Balbi]

AM437x IDK board has a User Switch which we can
program to whatever we want. Because this board
doesn't have a PMIC which can give us power button
presses, let's use this user switch as a gpio-keys
power button.

Signed-off-by: Felipe Balbi ba...@ti.com
---

Changes since v1:
- Add explicit pinctrl data.
  (note that ball reset state is already MUX_MODE7, and even
   though it was already working before, as can be seen from
   v1's boot logs, it's best that we cope with possibly broken
   bootloaders)

depends on [1]. Boot logs at [2]. Note that this can rather easily
be folded into the original patch if so desired.

[1] http://marc.info/?l=linux-omapm=141928747902983w=2
[2] http://hastebin.com/qezicehunu

 arch/arm/boot/dts/am437x-idk-evm.dts | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/am437x-idk-evm.dts 
b/arch/arm/boot/dts/am437x-idk-evm.dts
index b52dd0a..f9a17e2 100644
--- a/arch/arm/boot/dts/am437x-idk-evm.dts
+++ b/arch/arm/boot/dts/am437x-idk-evm.dts
@@ -96,9 +96,29 @@
regulator-boot-on;
vin-supply = v1_5dreg;
};
+
+   gpio_keys: gpio_keys {
+   compatible = gpio-keys;
+   pinctrl-names = default;
+   pinctrl-0 = gpio_keys_pins_default;
+   #address-cells = 1;
+   #size-cells = 0;
+
+   switch@0 {
+   label = power-button;
+   linux,code = KEY_POWER;
+   gpios = gpio4 2 GPIO_ACTIVE_LOW;
+   };
+   };
 };
 
 am43xx_pinmux {
+   gpio_keys_pins_default: gpio_keys_pins_default {
+   pinctrl-single,pins = 
+   0x1b8 (PIN_INPUT | MUX_MODE7)   /* cam0_field.gpio4_2 */
+   ;
+   };
+
i2c0_pins_default: i2c0_pins_default {
pinctrl-single,pins = 
0x188 (PIN_INPUT | SLEWCTRL_FAST | MUX_MODE0) /* 
i2c0_sda.i2c0_sda */
@@ -282,6 +302,10 @@
status = okay;
 };
 
+gpio4 {
+   status = okay;
+};
+
 gpio5 {
status = okay;
 };
-- 
2.2.0

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

Re: [PATCH 3/5] input: misc: add tps65218 power button driver

[Dmitry Torokhov]

Hi Felipe,

On Fri, Dec 26, 2014 at 01:28:22PM -0600, Felipe Balbi wrote:
 With this driver, we can report KEY_POWER on
 AM437x SK. This patch has been tested with said
 board.
 
 Signed-off-by: Felipe Balbi ba...@ti.com
 ---
  drivers/input/misc/Kconfig  |  10 +++
  drivers/input/misc/Makefile |   1 +
  drivers/input/misc/tps65218-pwrbutton.c | 135 
 
  3 files changed, 146 insertions(+)
  create mode 100644 drivers/input/misc/tps65218-pwrbutton.c
 
 diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
 index 23297ab..364cfb8 100644
 --- a/drivers/input/misc/Kconfig
 +++ b/drivers/input/misc/Kconfig
 @@ -404,6 +404,16 @@ config INPUT_RETU_PWRBUTTON
 To compile this driver as a module, choose M here. The module will
 be called retu-pwrbutton.
  
 +config INPUT_TPS65218_PWRBUTTON
 + tristate TPS65218 Power button driver
 + depends on MFD_TPS65218
 + help
 +   Say Y here if you want to enable power buttong reporting for
 +   the TPS65218 Power Management IC device.
 +
 +   To compile this driver as a module, choose M here. The module will
 +   be called tps65218-pwrbutton.
 +
  config INPUT_TWL4030_PWRBUTTON
   tristate TWL4030 Power button Driver
   depends on TWL4030_CORE
 diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
 index 19c7603..a923753 100644
 --- a/drivers/input/misc/Makefile
 +++ b/drivers/input/misc/Makefile
 @@ -59,6 +59,7 @@ obj-$(CONFIG_INPUT_SGI_BTNS)+= sgi_btns.o
  obj-$(CONFIG_INPUT_SIRFSOC_ONKEY)+= sirfsoc-onkey.o
  obj-$(CONFIG_INPUT_SOC_BUTTON_ARRAY) += soc_button_array.o
  obj-$(CONFIG_INPUT_SPARCSPKR)+= sparcspkr.o
 +obj-$(CONFIG_INPUT_TPS65218_PWRBUTTON)   += tps65218-pwrbutton.o
  obj-$(CONFIG_INPUT_TWL4030_PWRBUTTON)+= twl4030-pwrbutton.o
  obj-$(CONFIG_INPUT_TWL4030_VIBRA)+= twl4030-vibra.o
  obj-$(CONFIG_INPUT_TWL6040_VIBRA)+= twl6040-vibra.o
 diff --git a/drivers/input/misc/tps65218-pwrbutton.c 
 b/drivers/input/misc/tps65218-pwrbutton.c
 new file mode 100644
 index 000..a1f8a19
 --- /dev/null
 +++ b/drivers/input/misc/tps65218-pwrbutton.c
 @@ -0,0 +1,135 @@
 +/*
 + * Texas Instruments' TPS65218 Power Button Input Driver
 + *
 + * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
 + * Author: Felipe Balbi ba...@ti.com
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + *
 + * This program is distributed as is WITHOUT ANY WARRANTY of any
 + * kind, whether express or implied; without even the implied warranty
 + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + */
 +
 +#include linux/init.h
 +#include linux/input.h
 +#include linux/interrupt.h
 +#include linux/kernel.h
 +#include linux/mfd/tps65218.h
 +#include linux/module.h
 +#include linux/of.h
 +#include linux/platform_device.h
 +#include linux/slab.h
 +
 +struct tps65218_pwrbutton {
 + struct device *dev;
 + struct tps65218 *tps;
 + struct input_dev *idev;
 + int irq;

You do not need to store IRQ since you are not using it outside of
probe().

 +
 + unsigned int pressed:1;

You probably can remove 'pressed' as well and send events directly to
input core and rely on it to filter out duplicates so there won't be
release event without press event. If you prefer to keep it please use
bool instead of bit field.

 +};
 +
 +static irqreturn_t tps65218_pwr_irq(int irq, void *_pwr)
 +{
 + struct tps65218_pwrbutton *pwr = _pwr;
 + unsigned int reg;
 + int ret;
 +
 + ret = tps65218_reg_read(pwr-tps, TPS65218_REG_STATUS, reg);
 + if (ret) {
 + dev_err(pwr-dev, can't read register -- %d\n, ret);
 + goto out;
 + }
 +
 + if (reg  TPS65218_STATUS_PB_STATE) {
 + input_report_key(pwr-idev, KEY_POWER, 1);
 + pm_wakeup_event(pwr-dev, 0);
 + pwr-pressed = true;
 + } else {
 + /*
 +  * we don't want to report KEY_POWER releases on any of the
 +  * other IRQ sources. Only when button was previously pressed
 +  */
 + if (pwr-pressed) {
 + input_report_key(pwr-idev, KEY_POWER, 0);
 + pwr-pressed = false;
 + }
 + }
 +
 + input_sync(pwr-idev);
 +
 +out:
 + return IRQ_HANDLED;
 +}
 +
 +static int tps65218_pwron_probe(struct platform_device *pdev)
 +{
 + struct tps65218 *tps = dev_get_drvdata(pdev-dev.parent);
 + struct device *dev = pdev-dev;
 + struct tps65218_pwrbutton *pwr;
 + struct input_dev *idev;
 + int ret;
 +
 + pwr = devm_kzalloc(dev, sizeof(*pwr), GFP_KERNEL);
 + if (!pwr)
 + return -ENOMEM;
 +
 + idev = 

Re: [PATCH 1/3] DT Binding for omap3 temperature sensor

[Sebastian Reichel]

Hi Pavel,

On Fri, Dec 26, 2014 at 06:19:44PM +0100, Pavel Machek wrote:
 On Fri 2014-12-26 13:34:52, Sebastian Reichel wrote:
  OMAP34xx and OMAP36xx processors contain a register in the syscon area,
  which can be used to determine the SoCs temperature. This provides a
  DT binding specification for the temperature monitor.
  
  Signed-off-by: Sebastian Reichel s...@kernel.org
  ---
   .../bindings/hwmon/omap3-temperature.txt   | 25 
  ++
   1 file changed, 25 insertions(+)
   create mode 100644 
  Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
  
  diff --git a/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt 
  b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
  new file mode 100644
  index 000..99631ad
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/hwmon/omap3-temperature.txt
  @@ -0,0 +1,25 @@
  +* OMAP3 temperature sensor
  +
  +The OMAP34xx and OMAP36xx processors contain a register in the syscon area,
  +which can be used to determine the SoCs temperature.
  +
  +Requires node properties:
  +- compatible : should contain one of
  +   - ti,omap34xx-temperature-sensor for OMAP34xx
  +   - ti,omap36xx-temperature-sensor for OMAP36xx
  +- syscon : Should be a phandle to system configuration node which
  +   encompases the temperature register
  +- clocks : Should contain 32KHz fclk clock specifier
  +- clock-names :Should contain clock names
  +   - fck for the 32KHz fclk clock specifier
 
 I don't quite get it. The temperature sensor is internal on the CPU,
 right? Why do we need device tree to describe it? As soon as we have
 CPU that is compatible to ti,omap3430, we know everything we need to
 know, no?

Lots of stuff is SoC internal and described in the DT (e.g. serial
controllers). Just have a look in omap3.dtsi or omap34xx.dtsi.

I put the temperature sensor into its own node for the following
reasons:

 * syscon reference
 * clock reference

I first thought about loading the driver from the syscon driver,
but omap uses a generic one, so that's not an option. Apart from
that one would still need the clock reference.

  +Example for omap34xx:
  +
  +/ {
  +   temperature-sensor {
  +   compatible = ti,omap34xx-temperature-sensor;
  +   syscon = omap3_scm_general;
  +   clocks = ts_fck;
  +   clock-names = fck;
  +   };
  +};
 
 Or is there something that depends on the board there? Or do we want
 to do it like this to be consistent with existing bindings?

This is SoC specific and should go into the omap34xx.dtsi and
omap36xx.dtsi files. See also PATCH 3/3.

-- Sebastian


signature.asc
Description: Digital signature

[PATCH v2 3/5] input: misc: add tps65218 power button driver

[Felipe Balbi]

With this driver, we can report KEY_POWER on
AM437x SK. This patch has been tested with said
board.

Signed-off-by: Felipe Balbi ba...@ti.com
---

Changes since v1:
- Add device tree documentation
- s/ret/error
- removed 'pressed' as input core will filter events
- use a saner name when requesting IRQ. dev_name(dev) will return
$i2c_bus_address.i2c-omap:0-0024:tps65218-pwrbutton
- remove blank line before MODULE_DEVICE_TABLE()

 .../bindings/input/tps65218-pwrbutton.txt  |  17 +++
 drivers/input/misc/Kconfig |  10 ++
 drivers/input/misc/Makefile|   1 +
 drivers/input/misc/tps65218-pwrbutton.c| 124 +
 4 files changed, 152 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt
 create mode 100644 drivers/input/misc/tps65218-pwrbutton.c

diff --git a/Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt 
b/Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt
new file mode 100644
index 000..e30e0b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/tps65218-pwrbutton.txt
@@ -0,0 +1,17 @@
+Texas Instruments TPS65218 power button
+
+This driver provides a simple power button event via an Interrupt.
+
+Required properties:
+- compatible: should be ti,tps65218-pwrbutton
+- interrupts: should be one of the following
+   - 3 IRQ_TYPE_EDGE_BOTH: For controllers compatible with tps65218
+
+Example:
+
+tps {
+   power-button {
+   compatible = ti,tps65218-pwrbutton;
+   interrupts = 3 IRQ_TYPE_EDGE_BOTH;
+   };
+};
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 23297ab..364cfb8 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -404,6 +404,16 @@ config INPUT_RETU_PWRBUTTON
  To compile this driver as a module, choose M here. The module will
  be called retu-pwrbutton.
 
+config INPUT_TPS65218_PWRBUTTON
+   tristate TPS65218 Power button driver
+   depends on MFD_TPS65218
+   help
+ Say Y here if you want to enable power buttong reporting for
+ the TPS65218 Power Management IC device.
+
+ To compile this driver as a module, choose M here. The module will
+ be called tps65218-pwrbutton.
+
 config INPUT_TWL4030_PWRBUTTON
tristate TWL4030 Power button Driver
depends on TWL4030_CORE
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 19c7603..a923753 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -59,6 +59,7 @@ obj-$(CONFIG_INPUT_SGI_BTNS)  += sgi_btns.o
 obj-$(CONFIG_INPUT_SIRFSOC_ONKEY)  += sirfsoc-onkey.o
 obj-$(CONFIG_INPUT_SOC_BUTTON_ARRAY)   += soc_button_array.o
 obj-$(CONFIG_INPUT_SPARCSPKR)  += sparcspkr.o
+obj-$(CONFIG_INPUT_TPS65218_PWRBUTTON) += tps65218-pwrbutton.o
 obj-$(CONFIG_INPUT_TWL4030_PWRBUTTON)  += twl4030-pwrbutton.o
 obj-$(CONFIG_INPUT_TWL4030_VIBRA)  += twl4030-vibra.o
 obj-$(CONFIG_INPUT_TWL6040_VIBRA)  += twl6040-vibra.o
diff --git a/drivers/input/misc/tps65218-pwrbutton.c 
b/drivers/input/misc/tps65218-pwrbutton.c
new file mode 100644
index 000..2f85e2e
--- /dev/null
+++ b/drivers/input/misc/tps65218-pwrbutton.c
@@ -0,0 +1,124 @@
+/*
+ * Texas Instruments' TPS65218 Power Button Input Driver
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: Felipe Balbi ba...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/init.h
+#include linux/input.h
+#include linux/interrupt.h
+#include linux/kernel.h
+#include linux/mfd/tps65218.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/slab.h
+
+struct tps65218_pwrbutton {
+   struct device *dev;
+   struct tps65218 *tps;
+   struct input_dev *idev;
+};
+
+static irqreturn_t tps65218_pwr_irq(int irq, void *_pwr)
+{
+   struct tps65218_pwrbutton *pwr = _pwr;
+   unsigned int reg;
+   int error;
+
+   error = tps65218_reg_read(pwr-tps, TPS65218_REG_STATUS, reg);
+   if (error) {
+   dev_err(pwr-dev, can't read register -- %d\n, error);
+   goto out;
+   }
+
+   if (reg  TPS65218_STATUS_PB_STATE) {
+   input_report_key(pwr-idev, KEY_POWER, 1);
+   pm_wakeup_event(pwr-dev, 0);
+   } else {
+   input_report_key(pwr-idev, KEY_POWER, 0);
+   }
+
+   input_sync(pwr-idev);
+
+out:
+   

Re: [PATCH 1/4] usb: dwc3: gadget: Fix TRB preparation during SG

[Amit Virdi]

On Mon, Dec 22, 2014 at 9:34 PM, Felipe Balbi ba...@ti.com wrote:
 On Fri, Dec 19, 2014 at 12:40:15PM +0530, Amit Virdi wrote:
 When scatter gather is used, multiple TRBs are prepared from one DWC3 
 request.
 Hence, we must set the 'last' flag when the SG is last as well as the TRB is
 last. The current implementation uses list_is_last to check if the 
 dwc3_request
 is the last request in the request_list.

 This doesn't work when SG is used. This is because, when it is the last 
 request,
 the first TRB preparation (in dwc3_prepare_one_trb) modifies the dwc3_request
 list's next and prev pointers while moving the URB to req_queued.

 Hence, list_is_last always return false no matter what. The correct way is 
 not
 to access the modified pointers of dwc3_request but to use list_empty macro
 instead.

 Fixes: e5ba5ec833aa4a76980b512d6a6779643516b850 (usb: dwc3: gadget: fix 
 scatter
 gather implementation

 Signed-off-by: Amit Virdi amit.vi...@st.com

 you need to Cc stable here and make sure you point out which kernel
 versions this should be backported to. Looks like this sould be:

 Cc: sta...@vger.kernel.org # v3.9+

Okay. I checked the git log. The commit (usb: dwc3: gadget: fix
scatter gather implementation) was introduced in v3.8-rc5, hence
v3.8, so I need to

Cc: sta...@vger.kernel.org # v3.8+


 Also, how have you tested this ? I need a test case to make sure it
 fails here and this patch really fixes the problem.


This bug can be easily reproduced/tested if the gadget driver submits
a urb having number of sg entries mapped to DMA more than 1 on bulk
endpoint. Following is the log snippet once this bug is reproduced:

dwc3 dwc3.0: ep2in-bulk: Transfer Not Ready
dwc3 dwc3.0: queing request 24cc5780 to ep2in-bulk length 960002
dwc3 dwc3.0: ep2in-bulk: req 24cc5780 dma 24eb6400 length 2 chain
dwc3 dwc3.0: ep2in-bulk: req 24cc5780 dma 25901800 length 96
dwc3 dwc3.0: queing request 24cc5000 to ep2in-bulk length 960002
dwc3 dwc3.0: ep2in-bulk: Transfer Not Ready
dwc3 dwc3.0: queing request 24cc5900 to ep2in-bulk length 960002
-

Without this fix, the hardware never generates Transfer Complete
event for the corresponding EP and goes into an unknown state.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] usb: dwc3: gadget: Stop TRB preparation after limit is reached

[Amit Virdi]

On Mon, Dec 22, 2014 at 9:36 PM, Felipe Balbi ba...@ti.com wrote:
 On Fri, Dec 19, 2014 at 12:40:16PM +0530, Amit Virdi wrote:
 When SG is used, there are two loops iterating to prepare TRBs:
  - Outer loop over the request_list
  - Inner loop over the SG list

 The driver must stop preparing TRBs when the max TRBs have been prepared. The
 code was missing break to get out of the outer loop.

 Signed-off-by: Amit Virdi amit.vi...@st.com

 which bug is this fixing ? Which kernels are affected ? This need to be
 backported to which kernel ? Which commit introduced this bug ? How can
 I validate this to be a valid fix ?


Problem description:
DWC3 gadget sets up a pool of 32 TRBs for each EP during
initialization. This means, the max TRBs that can be submitted for an
EP is fixed to 32. Since the request queue for an EP is a linked list,
any number of requests can be queued to it by the gadget layer.
However, the dwc3 driver must not submit TRBs more than the pool it
has created for. This limit wasn't respected when SG was used
resulting in submitting more than the max TRBs, eventually leading to
non-transfer of the TRBs submitted over the max limit.

Commit that introduced this bug:
This bug is present from the day support for sg list was added to dwc3
gadget., i.e. since commit eeb720fb21d61dfc3aac780e721150998ef603af
(usb: dwc3: gadget: add support for SG lists) - kernel version
v3.2-rc7, hence v3.2

Kernels affected:
It is best to backport this fix to kernel v3.8+ as there were many
enhancements/bug fixes from v3.2..v3.8

Generic setup to reproduce/test this fix:
This bug is reproduced whenever the number of TRBs that need to be
submitted to the hardware from the software queue (request_list)
becomes more than 32 on bulk endpoint. eg. if num_mapped_sgs is 2 and
the request_list has 17 entries (hence, 34 potential TRBs), the
scenario is reproduced.

My setup details:
For reproducing and testing the patches [1/4 and 2/4], I used an
inhouse developed user space application that run on device side. This
user space application interacts with the customized uvc webcam gadget
to submit the video data to the DWC3 driver. The host side was running
standard webcam application (cheese).
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html