Re: [RFC PATCH v2 7/8] media: video: introduce object detection driver module
Hi Sylwester, Thanks for your review. On Fri, Dec 30, 2011 at 1:16 AM, Sylwester Nawrocki snj...@gmail.com wrote: Hi Ming, On 12/14/2011 03:00 PM, Ming Lei wrote: This patch introduces object detection generic driver. The driver is responsible for all v4l2 stuff, buffer management and other general things, and doesn't touch object detection hardware directly. Several interfaces are exported to low level drivers (such as the coming omap4 FD driver) which will communicate with object detection hw module. So the driver will make driving object detection hw modules more easy. TODO: - implement object detection setting interfaces with v4l2 controls or ext controls Signed-off-by: Ming Lei ming@canonical.com --- v2: - extend face detection driver to object detection driver - introduce subdevice and media entity - provide support to detect object from media HW --- drivers/media/video/Kconfig | 2 + drivers/media/video/Makefile | 1 + drivers/media/video/odif/Kconfig | 7 + drivers/media/video/odif/Makefile | 1 + drivers/media/video/odif/odif.c | 890 + drivers/media/video/odif/odif.h | 157 +++ 6 files changed, 1058 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/odif/Kconfig create mode 100644 drivers/media/video/odif/Makefile create mode 100644 drivers/media/video/odif/odif.c create mode 100644 drivers/media/video/odif/odif.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 5684a00..8740ee9 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -1166,3 +1166,5 @@ config VIDEO_SAMSUNG_S5P_MFC MFC 5.1 driver for V4L2. endif # V4L_MEM2MEM_DRIVERS + +source drivers/media/video/odif/Kconfig diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index bc797f2..259c8d8 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -197,6 +197,7 @@ obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o obj-y += davinci/ obj-$(CONFIG_ARCH_OMAP) += omap/ +obj-$(CONFIG_ODIF) += odif/ ccflags-y += -Idrivers/media/dvb/dvb-core ccflags-y += -Idrivers/media/dvb/frontends diff --git a/drivers/media/video/odif/Kconfig b/drivers/media/video/odif/Kconfig new file mode 100644 index 000..5090bd6 --- /dev/null +++ b/drivers/media/video/odif/Kconfig @@ -0,0 +1,7 @@ +config ODIF + depends on VIDEO_DEV VIDEO_V4L2 + select VIDEOBUF2_PAGE + tristate Object Detection module + help + The ODIF is a object detection module, which can be integrated into + some SoCs to detect objects in images or video. diff --git a/drivers/media/video/odif/Makefile b/drivers/media/video/odif/Makefile new file mode 100644 index 000..a55ff66 --- /dev/null +++ b/drivers/media/video/odif/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_ODIF) += odif.o diff --git a/drivers/media/video/odif/odif.c b/drivers/media/video/odif/odif.c new file mode 100644 index 000..381ab9d --- /dev/null +++ b/drivers/media/video/odif/odif.c @@ -0,0 +1,890 @@ +/* + * odif.c -- object detection module driver + * + * Copyright (C) 2011 Ming Lei (ming@canonical.com) + * + * This file is based on drivers/media/video/vivi.c. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + * + */ + +/*/ + +#include linux/module.h +#include linux/fs.h +#include linux/mm.h +#include linux/signal.h +#include linux/wait.h +#include linux/poll.h +#include linux/mman.h +#include linux/pm_runtime.h +#include linux/delay.h +#include linux/platform_device.h +#include linux/interrupt.h +#include asm/uaccess.h +#include asm/byteorder.h +#include asm/io.h +#include odif.h + +#define input_from_user(dev) \ + (dev-input == OD_INPUT_FROM_USER_SPACE) + +#define DEFAULT_PENDING_RESULT_CNT 8 + +static unsigned debug = 0; +module_param(debug, uint, 0644); +MODULE_PARM_DESC(debug, activates debug info); + +static unsigned result_cnt_threshold = DEFAULT_PENDING_RESULT_CNT;
[PATCH V3 0/2] Add TI TPS65217 PMIC driver support
TPS65217 power management IC supports various features, like Battery charger, white LED driver along with basic regulator Functionality. This patch set adds support as an MFD device into the kernel to facilitate adding additional drivers on top of it. This device is used on one of AM335x platform (BeagleBone), and details about board can be accessed at - http://beagleboard.org/bone Device Spec and related documents can be accessed from - http://www.ti.com/product/tps65217b Changes form V2: - Incorporated all Mark Brown's review commets on V2 * clear/set bit API's moved to MFD driver * voltage range API's clean-up Changes form V1: - Incorporated all Mark Brown's review commets * MFD read/writes API's modifed to use regmap read/writes * kzalloc() changed to devm_kzalloc() * Converted voltage tables to function calls * set_voltage() changed to set_voltage_sel() - cleaned-up the code little bit AnilKumar Ch (2): MFD: TPS65217: Add new mfd device for TPS65217 regulator: tps65217: Add tps65217 regulator driver drivers/mfd/Kconfig| 15 ++ drivers/mfd/Makefile |1 + drivers/mfd/tps65217.c | 242 ++ drivers/regulator/Kconfig |9 + drivers/regulator/Makefile |1 + drivers/regulator/tps65217-regulator.c | 435 include/linux/mfd/tps65217.h | 275 7 files changed, 978 insertions(+), 0 deletions(-) create mode 100644 drivers/mfd/tps65217.c create mode 100644 drivers/regulator/tps65217-regulator.c create mode 100644 include/linux/mfd/tps65217.h -- 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 V3 1/2] MFD: TPS65217: Add new mfd device for TPS65217
The TPS65217 chip is a power management IC for Portable Navigation Systems
and Tablet Computing devices. It contains the following components:
- Regulators
- White LED
- USB battery charger
This patch adds support for tps65217 mfd device. At this time only
the regulator functionality is made available.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
drivers/mfd/Kconfig | 15 +++
drivers/mfd/Makefile |1 +
drivers/mfd/tps65217.c | 242 +
include/linux/mfd/tps65217.h | 275 ++
4 files changed, 533 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/tps65217.c
create mode 100644 include/linux/mfd/tps65217.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index f1391c2..d2c55e8 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -142,6 +142,21 @@ config TPS6507X
This driver can also be built as a module. If so, the module
will be called tps6507x.
+config MFD_TPS65217
+ tristate TPS65217 Power Management / White LED chips
+ depends on I2C
+ select MFD_CORE
+ select REGMAP_I2C
+ help
+ If you say yes here you get support for the TPS65217 series of
+ Power Management / White LED chips.
+ These include voltage regulators, lithium ion/polymer battery
+ charger, wled and other features that are often used in portable
+ devices.
+
+ This driver can also be built as a module. If so, the module
+ will be called tps65217.
+
config MFD_TPS6586X
bool TPS6586x Power Management chips
depends on I2C=y GPIOLIB GENERIC_HARDIRQS
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index b2292eb..7a6d111 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_MFD_WM8994) += wm8994-core.o wm8994-irq.o
obj-$(CONFIG_TPS6105X) += tps6105x.o
obj-$(CONFIG_TPS65010) += tps65010.o
obj-$(CONFIG_TPS6507X) += tps6507x.o
+obj-$(CONFIG_MFD_TPS65217) += tps65217.o
obj-$(CONFIG_MFD_TPS65910) += tps65910.o tps65910-irq.o
tps65912-objs := tps65912-core.o tps65912-irq.o
obj-$(CONFIG_MFD_TPS65912) += tps65912.o
diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
new file mode 100644
index 000..f7d854e
--- /dev/null
+++ b/drivers/mfd/tps65217.c
@@ -0,0 +1,242 @@
+/*
+ * tps65217.c
+ *
+ * TPS65217 chip family multi-function driver
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * 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/kernel.h
+#include linux/device.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/init.h
+#include linux/i2c.h
+#include linux/slab.h
+#include linux/regmap.h
+#include linux/err.h
+
+#include linux/mfd/core.h
+#include linux/mfd/tps65217.h
+
+/**
+ * tps65217_reg_read: Read a single tps65217 register.
+ *
+ * @tps: Device to read from.
+ * @reg: Register to read.
+ * @val: Contians the value
+ */
+int tps65217_reg_read(struct tps65217 *tps, unsigned int reg,
+ unsigned int *val)
+{
+ return regmap_read(tps-regmap, reg, val);
+}
+EXPORT_SYMBOL_GPL(tps65217_reg_read);
+
+/**
+ * tps65217_reg_write: Write a single tps65217 register.
+ *
+ * @tps65217: Device to write to.
+ * @reg: Register to write to.
+ * @val: Value to write.
+ * @level: Password protected level
+ */
+int tps65217_reg_write(struct tps65217 *tps, unsigned int reg,
+ unsigned int val, unsigned int level)
+{
+ int ret;
+ unsigned int xor_reg_val;
+
+ switch (level) {
+ case TPS65217_PROTECT_NONE:
+ return regmap_write(tps-regmap, reg, val);
+ case TPS65217_PROTECT_L1:
+ xor_reg_val = reg ^ TPS65217_PASSWORD_REGS_UNLOCK;
+ ret = regmap_write(tps-regmap, TPS65217_REG_PASSWORD,
+ xor_reg_val);
+ if (ret 0)
+ return ret;
+
+ return regmap_write(tps-regmap, reg, val);
+ case TPS65217_PROTECT_L2:
+ xor_reg_val = reg ^ TPS65217_PASSWORD_REGS_UNLOCK;
+ ret = regmap_write(tps-regmap, TPS65217_REG_PASSWORD,
+ xor_reg_val);
+ if (ret 0)
+ return ret;
+ ret = regmap_write(tps-regmap, reg, val);
+ if (ret 0)
+ return ret;
[PATCH V3 2/2] regulator: tps65217: Add tps65217 regulator driver
This patch adds tps65217 PMIC as a regulator
The regulator module consists of 3 DCDCs and 4 LDOs. The output
voltages are configurable and are meant to supply power to the
main processor and other components
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
drivers/regulator/Kconfig |9 +
drivers/regulator/Makefile |1 +
drivers/regulator/tps65217-regulator.c | 435
3 files changed, 445 insertions(+), 0 deletions(-)
create mode 100644 drivers/regulator/tps65217-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 9713b1b..529c591 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -259,6 +259,15 @@ config REGULATOR_TPS6507X
three step-down converters and two general-purpose LDO voltage
regulators.
It supports TI's software based Class-2 SmartReflex implementation.
+config REGULATOR_TPS65217
+ tristate TI TPS65217 Power regulators
+ depends on MFD_TPS65217
+ help
+ This driver supports TPS65217 voltage regulator chips. TPS65217
+ provides three step-down converters and four general-purpose LDO
+ voltage regulators. It supports software based voltage control
+ for different voltage domains
+
config REGULATOR_TPS65912
tristate TI TPS65912 Power regulator
depends on (MFD_TPS65912_I2C || MFD_TPS65912_SPI)
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 93a6318..aeae546 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_REGULATOR_AB3100) += ab3100.o
obj-$(CONFIG_REGULATOR_TPS6105X) += tps6105x-regulator.o
obj-$(CONFIG_REGULATOR_TPS65023) += tps65023-regulator.o
obj-$(CONFIG_REGULATOR_TPS6507X) += tps6507x-regulator.o
+obj-$(CONFIG_REGULATOR_TPS65217) += tps65217-regulator.o
obj-$(CONFIG_REGULATOR_TPS6524X) += tps6524x-regulator.o
obj-$(CONFIG_REGULATOR_TPS65912) += tps65912-regulator.o
obj-$(CONFIG_REGULATOR_88PM8607) += 88pm8607.o
diff --git a/drivers/regulator/tps65217-regulator.c
b/drivers/regulator/tps65217-regulator.c
new file mode 100644
index 000..a5d7d9f
--- /dev/null
+++ b/drivers/regulator/tps65217-regulator.c
@@ -0,0 +1,435 @@
+/*
+ * tps65217-regulator.c
+ *
+ * Regulator driver for TPS65217 PMIC
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * 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/kernel.h
+#include linux/module.h
+#include linux/device.h
+#include linux/init.h
+#include linux/err.h
+#include linux/platform_device.h
+
+#include linux/regulator/driver.h
+#include linux/regulator/machine.h
+#include linux/mfd/tps65217.h
+
+#define TPS65217_REGULATOR(_name, _id, _ops, _n) \
+ { \
+ .name = _name,\
+ .id = _id, \
+ .ops= _ops,\
+ .n_voltages = _n, \
+ .type = REGULATOR_VOLTAGE,\
+ .owner = THIS_MODULE, \
+ } \
+
+#define TPS65217_INFO(_name, _fun, _n, _emsk, _vreg, _vmsk)\
+ { \
+ .name = _name,\
+ .tps_range = _fun, \
+ .table_len = _n, \
+ .enable_mask= _emsk,\
+ .set_vout_reg = _vreg,\
+ .set_vout_mask = _vmsk,\
+ }
+
+static int tps65217_vsel_to_uv_range0(unsigned int vsel)
+{
+ int uV = 0;
+
+ if (vsel 63)
+ return -EINVAL;
+
+ if (vsel = 24)
+ uV = vsel * 25000 + 90;
+ else if (vsel = 52)
+ uV = (vsel - 24) * 5 + 150;
+ else if (vsel 56)
+ uV = (vsel - 52) * 10 + 290;
+ else
+ uV = 330;
+
+ return uV;
+}
+
+static int tps65217_vsel_to_uv_range1(unsigned int vsel)
+{
+ int uV = 0;
+
+ if (vsel 15)
+ return -EINVAL;
+
+ if (vsel = 2)
+ uV = vsel * 10 + 100;
+ else if (vsel = 6)
+ uV = (vsel - 2) * 5 + 120;
+ else if (vsel = 9)
+ uV = (vsel - 6) * 10 + 140;
+ else if (vsel == 10)
+ uV
[PATCH v3 0/4] OMAPDSS: HDMI: Improve the timings logic in HDMI
From: Mythri P K mythr...@ti.com There are some duplicate timing structure which are not needed thus removing them to clean the code. Also the static mapped timing structure is quite complicated to add new timings, so simplify it by using array indexed method. changes since v2: Incorporate changes in find_timing function changes since V1: change of hdmi_find_timing function to return pointer to the timing struct rather than deep copy to timing structure passed as parameter variable name change from temp to timing2 in comparator function. Mythri P K (4): OMAPDSS: HDMI: remove duplicate video interface code OMAPDSS: HDMI: update static timing table OMAPDSS: HDMI: change the timing match logic OMAPDSS: HDMI: remove duplicate code and mode parameter drivers/video/omap2/dss/hdmi.c| 257 + drivers/video/omap2/dss/ti_hdmi.h | 14 +- drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 47 ++ drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |7 - 4 files changed, 136 insertions(+), 189 deletions(-) -- 1.7.5.4 -- 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 v3 1/4] OMAPDSS: HDMI: remove duplicate video interface code
From: Mythri P K mythr...@ti.com
video interface structure is a duplicate structure with parameters which are
already present in ip_data config structure, Thus removing the structure and
modifying corresponding code.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 31 +++-
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h |7 --
2 files changed, 8 insertions(+), 30 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index e1a6ce5..403d6fc 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -629,8 +629,7 @@ static void hdmi_core_av_packet_config(struct hdmi_ip_data
*ip_data,
}
static void hdmi_wp_init(struct omap_video_timings *timings,
- struct hdmi_video_format *video_fmt,
- struct hdmi_video_interface *video_int)
+ struct hdmi_video_format *video_fmt)
{
pr_debug(Enter hdmi_wp_init\n);
@@ -645,12 +644,6 @@ static void hdmi_wp_init(struct omap_video_timings
*timings,
video_fmt-y_res = 0;
video_fmt-x_res = 0;
- video_int-vsp = 0;
- video_int-hsp = 0;
-
- video_int-interlacing = 0;
- video_int-tm = 0; /* HDMI_TIMING_SLAVE */
-
}
void ti_hdmi_4xxx_wp_video_start(struct hdmi_ip_data *ip_data, bool start)
@@ -687,17 +680,16 @@ static void hdmi_wp_video_config_format(struct
hdmi_ip_data *ip_data,
hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_SIZE, l);
}
-static void hdmi_wp_video_config_interface(struct hdmi_ip_data *ip_data,
- struct hdmi_video_interface *video_int)
+static void hdmi_wp_video_config_interface(struct hdmi_ip_data *ip_data)
{
u32 r;
pr_debug(Enter hdmi_wp_video_config_interface\n);
r = hdmi_read_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG);
- r = FLD_MOD(r, video_int-vsp, 7, 7);
- r = FLD_MOD(r, video_int-hsp, 6, 6);
- r = FLD_MOD(r, video_int-interlacing, 3, 3);
- r = FLD_MOD(r, video_int-tm, 1, 0);
+ r = FLD_MOD(r, ip_data-cfg.timings.vsync_pol, 7, 7);
+ r = FLD_MOD(r, ip_data-cfg.timings.hsync_pol, 6, 6);
+ r = FLD_MOD(r, ip_data-cfg.interlace, 3, 3);
+ r = FLD_MOD(r, 1, 1, 0); /* HDMI_TIMING_MASTER_24BIT */
hdmi_write_reg(hdmi_wp_base(ip_data), HDMI_WP_VIDEO_CFG, r);
}
@@ -725,15 +717,13 @@ void ti_hdmi_4xxx_basic_configure(struct hdmi_ip_data
*ip_data)
/* HDMI */
struct omap_video_timings video_timing;
struct hdmi_video_format video_format;
- struct hdmi_video_interface video_interface;
/* HDMI core */
struct hdmi_core_infoframe_avi avi_cfg;
struct hdmi_core_video_config v_core_cfg;
struct hdmi_core_packet_enable_repeat repeat_cfg;
struct hdmi_config *cfg = ip_data-cfg;
- hdmi_wp_init(video_timing, video_format,
- video_interface);
+ hdmi_wp_init(video_timing, video_format);
hdmi_core_init(v_core_cfg,
avi_cfg,
@@ -748,12 +738,7 @@ void ti_hdmi_4xxx_basic_configure(struct hdmi_ip_data
*ip_data)
hdmi_wp_video_config_format(ip_data, video_format);
- video_interface.vsp = cfg-timings.vsync_pol;
- video_interface.hsp = cfg-timings.hsync_pol;
- video_interface.interlacing = cfg-interlace;
- video_interface.tm = 1 ; /* HDMI_TIMING_MASTER_24BIT */
-
- hdmi_wp_video_config_interface(ip_data, video_interface);
+ hdmi_wp_video_config_interface(ip_data);
/*
* configure core video part
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index 2040956..914bec6 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -517,13 +517,6 @@ struct hdmi_video_format {
u32 x_res; /* pixel per line */
};
-struct hdmi_video_interface {
- int vsp;/* Vsync polarity */
- int hsp;/* Hsync polarity */
- int interlacing;
- int tm; /* Timing mode */
-};
-
struct hdmi_audio_format {
enum hdmi_stereo_channels stereo_channels;
u8 active_chnnls_msk;
--
1.7.5.4
--
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 v3 2/4] OMAPDSS: HDMI: update static timing table
From: Mythri P K mythr...@ti.com
Add the vsync polarity, hsync polarity, interlace to hdmi_video_timings.
Remove the now duplicate structure hdmi_timings.
update the static table structure in HDMI with CEA/VESA code and mode.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c| 96 ++--
drivers/video/omap2/dss/ti_hdmi.h | 14 ++---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 20 +++---
3 files changed, 63 insertions(+), 67 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index c56378c..f76ae47 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -88,42 +88,42 @@ static struct {
* map it to corresponding CEA or VESA index.
*/
-static const struct hdmi_timings cea_vesa_timings[OMAP_HDMI_TIMINGS_NB] = {
- { {640, 480, 25200, 96, 16, 48, 2, 10, 33} , 0 , 0},
- { {1280, 720, 74250, 40, 440, 220, 5, 5, 20}, 1, 1},
- { {1280, 720, 74250, 40, 110, 220, 5, 5, 20}, 1, 1},
- { {720, 480, 27027, 62, 16, 60, 6, 9, 30}, 0, 0},
- { {2880, 576, 108000, 256, 48, 272, 5, 5, 39}, 0, 0},
- { {1440, 240, 27027, 124, 38, 114, 3, 4, 15}, 0, 0},
- { {1440, 288, 27000, 126, 24, 138, 3, 2, 19}, 0, 0},
- { {1920, 540, 74250, 44, 528, 148, 5, 2, 15}, 1, 1},
- { {1920, 540, 74250, 44, 88, 148, 5, 2, 15}, 1, 1},
- { {1920, 1080, 148500, 44, 88, 148, 5, 4, 36}, 1, 1},
- { {720, 576, 27000, 64, 12, 68, 5, 5, 39}, 0, 0},
- { {1440, 576, 54000, 128, 24, 136, 5, 5, 39}, 0, 0},
- { {1920, 1080, 148500, 44, 528, 148, 5, 4, 36}, 1, 1},
- { {2880, 480, 108108, 248, 64, 240, 6, 9, 30}, 0, 0},
- { {1920, 1080, 74250, 44, 638, 148, 5, 4, 36}, 1, 1},
- /* VESA From Here */
- { {640, 480, 25175, 96, 16, 48, 2 , 11, 31}, 0, 0},
- { {800, 600, 4, 128, 40, 88, 4 , 1, 23}, 1, 1},
- { {848, 480, 33750, 112, 16, 112, 8 , 6, 23}, 1, 1},
- { {1280, 768, 79500, 128, 64, 192, 7 , 3, 20}, 1, 0},
- { {1280, 800, 83500, 128, 72, 200, 6 , 3, 22}, 1, 0},
- { {1360, 768, 85500, 112, 64, 256, 6 , 3, 18}, 1, 1},
- { {1280, 960, 108000, 112, 96, 312, 3 , 1, 36}, 1, 1},
- { {1280, 1024, 108000, 112, 48, 248, 3 , 1, 38}, 1, 1},
- { {1024, 768, 65000, 136, 24, 160, 6, 3, 29}, 0, 0},
- { {1400, 1050, 121750, 144, 88, 232, 4, 3, 32}, 1, 0},
- { {1440, 900, 106500, 152, 80, 232, 6, 3, 25}, 1, 0},
- { {1680, 1050, 146250, 176 , 104, 280, 6, 3, 30}, 1, 0},
- { {1366, 768, 85500, 143, 70, 213, 3, 3, 24}, 1, 1},
- { {1920, 1080, 148500, 44, 148, 80, 5, 4, 36}, 1, 1},
- { {1280, 768, 68250, 32, 48, 80, 7, 3, 12}, 0, 1},
- { {1400, 1050, 101000, 32, 48, 80, 4, 3, 23}, 0, 1},
- { {1680, 1050, 119000, 32, 48, 80, 6, 3, 21}, 0, 1},
- { {1280, 800, 79500, 32, 48, 80, 6, 3, 14}, 0, 1},
- { {1280, 720, 74250, 40, 110, 220, 5, 5, 20}, 1, 1}
+static const struct hdmi_config cea_vesa_timings[OMAP_HDMI_TIMINGS_NB] = {
+{ {640, 480, 25200, 96, 16, 48, 2, 10, 33, 0, 0, 0}, {1, HDMI_HDMI} },
+{ {720, 480, 27027, 62, 16, 60, 6, 9, 30, 0, 0, 0}, {2, HDMI_HDMI} },
+{ {1280, 720, 74250, 40, 110, 220, 5, 5, 20, 1, 1, 0}, {4, HDMI_HDMI} },
+{ {1920, 540, 74250, 44, 88, 148, 5, 2, 15, 1, 1, 1}, {5, HDMI_HDMI} },
+{ {1440, 240, 27027, 124, 38, 114, 3, 4, 15, 0, 0, 1}, {6, HDMI_HDMI} },
+{ {1920, 1080, 148500, 44, 88, 148, 5, 4, 36, 1, 1, 0}, {16, HDMI_HDMI} },
+{ {720, 576, 27000, 64, 12, 68, 5, 5, 39, 0, 0, 0}, {17, HDMI_HDMI} },
+{ {1280, 720, 74250, 40, 440, 220, 5, 5, 20, 1, 1, 0}, {19, HDMI_HDMI} },
+{ {1920, 540, 74250, 44, 528, 148, 5, 2, 15, 1, 1, 1}, {20, HDMI_HDMI} },
+{ {1440, 288, 27000, 126, 24, 138, 3, 2, 19, 0, 0, 1}, {21, HDMI_HDMI} },
+{ {1440, 576, 54000, 128, 24, 136, 5, 5, 39, 0, 0, 0}, {29, HDMI_HDMI} },
+{ {1920, 1080, 148500, 44, 528, 148, 5, 4, 36, 1, 1, 0}, {31, HDMI_HDMI} },
+{ {1920, 1080, 74250, 44, 638, 148, 5, 4, 36, 1, 1, 0}, {32, HDMI_HDMI} },
+{ {2880, 480, 108108, 248, 64, 240, 6, 9, 30, 0, 0, 0}, {35, HDMI_HDMI} },
+{ {2880, 576, 108000, 256, 48, 272, 5, 5, 39, 0, 0, 0}, {37, HDMI_HDMI} },
+/* VESA From Here */
+{ {640, 480, 25175, 96, 16, 48, 2 , 11, 31, 0, 0, 0}, {4, HDMI_DVI} },
+{ {800, 600, 4, 128, 40, 88, 4 , 1, 23, 1, 1, 0}, {9, HDMI_DVI} },
+{ {848, 480, 33750, 112, 16, 112, 8 , 6, 23, 1, 1, 0}, {0xE, HDMI_DVI} },
+{ {1280, 768, 79500, 128, 64, 192, 7 , 3, 20, 1, 0, 0}, {0x17, HDMI_DVI} },
+{ {1280, 800, 83500, 128, 72, 200, 6 , 3, 22, 1, 0, 0}, {0x1C, HDMI_DVI} },
+{ {1360, 768, 85500, 112, 64, 256, 6 , 3, 18, 1, 1, 0}, {0x27, HDMI_DVI} },
+{ {1280, 960, 108000, 112, 96, 312, 3 , 1, 36, 1, 1, 0}, {0x20, HDMI_DVI} },
+{ {1280, 1024, 108000, 112, 48, 248, 3 , 1, 38, 1, 1, 0}, {0x23, HDMI_DVI} },
+{ {1024, 768, 65000, 136, 24, 160, 6, 3, 29, 0, 0, 0}, {0x10, HDMI_DVI} },
+{ {1400, 1050, 121750, 144, 88, 232, 4, 3, 32, 1, 0, 0}, {0x2A, HDMI_DVI} },
+{ {1440, 900, 106500, 152, 80, 232, 6, 3,
[PATCH v3 3/4] OMAPDSS: HDMI: change the timing match logic
From: Mythri P K mythr...@ti.com
Change the timing match logic, Instead of the statically mapped method
to get the corresponding timings for a given code and mode, move to a
simpler array indexed method. It will help to scale up to add more
timings when needed.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 177 +--
1 files changed, 77 insertions(+), 100 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index f76ae47..78aa904 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -58,8 +58,6 @@
#define EDID_SIZE_BLOCK0_TIMING_DESCRIPTOR 4
#define EDID_SIZE_BLOCK1_TIMING_DESCRIPTOR 4
-#define OMAP_HDMI_TIMINGS_NB 34
-
#define HDMI_DEFAULT_REGN 16
#define HDMI_DEFAULT_REGM2 1
@@ -88,7 +86,7 @@ static struct {
* map it to corresponding CEA or VESA index.
*/
-static const struct hdmi_config cea_vesa_timings[OMAP_HDMI_TIMINGS_NB] = {
+static const struct hdmi_config cea_timings[] = {
{ {640, 480, 25200, 96, 16, 48, 2, 10, 33, 0, 0, 0}, {1, HDMI_HDMI} },
{ {720, 480, 27027, 62, 16, 60, 6, 9, 30, 0, 0, 0}, {2, HDMI_HDMI} },
{ {1280, 720, 74250, 40, 110, 220, 5, 5, 20, 1, 1, 0}, {4, HDMI_HDMI} },
@@ -104,6 +102,8 @@ static const struct hdmi_config
cea_vesa_timings[OMAP_HDMI_TIMINGS_NB] = {
{ {1920, 1080, 74250, 44, 638, 148, 5, 4, 36, 1, 1, 0}, {32, HDMI_HDMI} },
{ {2880, 480, 108108, 248, 64, 240, 6, 9, 30, 0, 0, 0}, {35, HDMI_HDMI} },
{ {2880, 576, 108000, 256, 48, 272, 5, 5, 39, 0, 0, 0}, {37, HDMI_HDMI} },
+};
+static const struct hdmi_config vesa_timings[] = {
/* VESA From Here */
{ {640, 480, 25175, 96, 16, 48, 2 , 11, 31, 0, 0, 0}, {4, HDMI_DVI} },
{ {800, 600, 4, 128, 40, 88, 4 , 1, 23, 1, 1, 0}, {9, HDMI_DVI} },
@@ -126,39 +126,6 @@ static const struct hdmi_config
cea_vesa_timings[OMAP_HDMI_TIMINGS_NB] = {
{ {1280, 720, 74250, 40, 110, 220, 5, 5, 20, 1, 1, 0}, {0x55, HDMI_DVI} }
};
-/*
- * This is a static mapping array which maps the timing values
- * with corresponding CEA / VESA code
- */
-static const int code_index[OMAP_HDMI_TIMINGS_NB] = {
- 1, 19, 4, 2, 37, 6, 21, 20, 5, 16, 17, 29, 31, 35, 32,
- /* --15 CEA 17-- vesa*/
- 4, 9, 0xE, 0x17, 0x1C, 0x27, 0x20, 0x23, 0x10, 0x2A,
- 0X2F, 0x3A, 0X51, 0X52, 0x16, 0x29, 0x39, 0x1B
-};
-
-/*
- * This is reverse static mapping which maps the CEA / VESA code
- * to the corresponding timing values
- */
-static const int code_cea[39] = {
- -1, 0, 3, 3, 2, 8, 5, 5, -1, -1,
- -1, -1, -1, -1, -1, -1, 9, 10, 10, 1,
- 7, 6, 6, -1, -1, -1, -1, -1, -1, 11,
- 11, 12, 14, -1, -1, 13, 13, 4, 4
-};
-
-static const int code_vesa[85] = {
- -1, -1, -1, -1, 15, -1, -1, -1, -1, 16,
- -1, -1, -1, -1, 17, -1, 23, -1, -1, -1,
- -1, -1, 29, 18, -1, -1, -1, 32, 19, -1,
- -1, -1, 21, -1, -1, 22, -1, -1, -1, 20,
- -1, 30, 24, -1, -1, -1, -1, 25, -1, -1,
- -1, -1, -1, -1, -1, -1, -1, 31, 26, -1,
- -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
- -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
- -1, 27, 28, -1, 33};
-
static int hdmi_runtime_get(void)
{
int r;
@@ -188,82 +155,86 @@ int hdmi_init_display(struct omap_dss_device *dssdev)
return 0;
}
-static int get_timings_index(void)
+static const struct hdmi_config *hdmi_find_timing(
+ const struct hdmi_config *timings_arr,
+ int len)
{
- int code;
+ int i;
+ const struct hdmi_config *timing = NULL;
- if (hdmi.mode == 0)
- code = code_vesa[hdmi.code];
- else
- code = code_cea[hdmi.code];
+ for (i = 0; i len; i++) {
+ if (timings_arr[i].cm.code == hdmi.code) {
+ timing = timings_arr[i];
+ return timing;
+ }
+ }
+ return timing;
+}
- if (code == -1) {
- /* HDMI code 4 corresponds to 640 * 480 VGA */
- hdmi.code = 4;
- /* DVI mode 1 corresponds to HDMI 0 to DVI */
- hdmi.mode = HDMI_DVI;
+static const struct hdmi_config *hdmi_get_timings(void)
+{
+ const struct hdmi_config *arr;
+ int len;
+
+ if (hdmi.mode == HDMI_DVI) {
+ arr = vesa_timings;
+ len = ARRAY_SIZE(vesa_timings);
+ } else {
+ arr = cea_timings;
+ len = ARRAY_SIZE(cea_timings);
+ }
+
+ return hdmi_find_timing(arr, len);
+}
+
+static bool hdmi_timings_compare(struct omap_video_timings *timing1,
+ const struct hdmi_video_timings *timing2)
+{
+ int timing1_vsync, timing1_hsync, timing2_vsync, timing2_hsync;
+
+ if ((timing2-pixel_clock == timing1-pixel_clock)
+ (timing2-x_res == timing1-x_res)
+ (timing2-y_res ==
[PATCH v3 4/4] OMAPDSS: HDMI: remove duplicate code and mode parameter
From: Mythri P K mythr...@ti.com
code and mode parameters are already a part of the ip_data structure
so no need to keep the same parameters again in hdmi global structure.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 78aa904..4bb7678 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -66,8 +66,6 @@ static struct {
struct omap_display_platform_data *pdata;
struct platform_device *pdev;
struct hdmi_ip_data ip_data;
- int code;
- int mode;
struct clk *sys_clk;
} hdmi;
@@ -163,7 +161,7 @@ static const struct hdmi_config *hdmi_find_timing(
const struct hdmi_config *timing = NULL;
for (i = 0; i len; i++) {
- if (timings_arr[i].cm.code == hdmi.code) {
+ if (timings_arr[i].cm.code == hdmi.ip_data.cfg.cm.code) {
timing = timings_arr[i];
return timing;
}
@@ -176,7 +174,7 @@ static const struct hdmi_config *hdmi_get_timings(void)
const struct hdmi_config *arr;
int len;
- if (hdmi.mode == HDMI_DVI) {
+ if (hdmi.ip_data.cfg.cm.mode == HDMI_DVI) {
arr = vesa_timings;
len = ARRAY_SIZE(vesa_timings);
} else {
@@ -314,9 +312,9 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
if (hdmi_get_timings() == NULL) {
/* HDMI code 4 corresponds to 640 * 480 VGA */
- hdmi.code = 4;
+ hdmi.ip_data.cfg.cm.code = 4;
/* DVI mode 1 corresponds to HDMI 0 to DVI */
- hdmi.mode = HDMI_DVI;
+ hdmi.ip_data.cfg.cm.mode = HDMI_DVI;
hdmi.ip_data.cfg = vesa_timings[0];
} else {
hdmi.ip_data.cfg = *(hdmi_get_timings());
@@ -340,8 +338,6 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
goto err;
}
- hdmi.ip_data.cfg.cm.mode = hdmi.mode;
- hdmi.ip_data.cfg.cm.code = hdmi.code;
hdmi.ip_data.ops-video_configure(hdmi.ip_data);
/* Make selection of HDMI in DSS */
@@ -401,8 +397,8 @@ void omapdss_hdmi_display_set_timing(struct omap_dss_device
*dssdev)
struct hdmi_cm cm;
cm = hdmi_get_code(dssdev-panel.timings);
- hdmi.code = cm.code;
- hdmi.mode = cm.mode;
+ hdmi.ip_data.cfg.cm.code = cm.code;
+ hdmi.ip_data.cfg.cm.mode = cm.mode;
if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE) {
int r;
@@ -668,7 +664,7 @@ static int hdmi_audio_hw_params(struct hdmi_ip_data
*ip_data,
static int hdmi_audio_startup(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
- if (!hdmi.mode) {
+ if (!hdmi.ip_data.cfg.cm.mode) {
pr_err(Current video settings do not support audio.\n);
return -EIO;
}
--
1.7.5.4
--
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 2/3] OMAPDSS: HDMI: Add quantization range support in IP lib
From: Mythri P K mythr...@ti.com
Configure the IP to support the limited range and full range quantization
mode. If the full range is configured HDMI transmitter will expand the range
of pixel data from 16-235 to full 8 bit 0-235.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi.h |7 +
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 40 +
2 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index 835cfb1..1b485ee 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -42,6 +42,11 @@ enum hdmi_clk_refsel {
HDMI_REFSEL_SYSCLK = 3
};
+enum hdmi_range {
+ HDMI_LIMITED_RANGE = 0,
+ HDMI_FULL_RANGE = 1,
+};
+
/* HDMI timing structure */
struct hdmi_video_timings {
u16 x_res;
@@ -159,6 +164,7 @@ struct hdmi_ip_data {
struct hdmi_config cfg;
struct hdmi_pll_info pll_data;
struct hdmi_core_infoframe_avi avi_cfg;
+ enum hdmi_range range;
};
int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data);
void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data);
@@ -172,5 +178,6 @@ void ti_hdmi_4xxx_wp_dump(struct hdmi_ip_data *ip_data,
struct seq_file *s);
void ti_hdmi_4xxx_pll_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
void ti_hdmi_4xxx_phy_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
+int ti_hdmi_4xxx_configure_range(struct hdmi_ip_data *ip_data);
#endif
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index b66d82e..a98ce8a 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -610,6 +610,46 @@ static void hdmi_core_aux_infoframe_avi_config(struct
hdmi_ip_data *ip_data)
hdmi_write_reg(av_base, HDMI_CORE_AV_AVI_CHSUM, checksum);
}
+int ti_hdmi_4xxx_configure_range(struct hdmi_ip_data *ip_data)
+{
+ int var;
+
+ switch (ip_data-range) {
+ /*
+* Setting the AVI infroframe to respective limited range
+* 0 if limited range 1 if full range
+*/
+ case HDMI_LIMITED_RANGE:
+ ip_data-avi_cfg.db3_q_range = HDMI_INFOFRAME_AVI_DB3Q_LR;
+ hdmi_core_aux_infoframe_avi_config(ip_data);
+ var = hdmi_read_reg(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_SYS_VID_ACEN);
+ var = FLD_MOD(var, 1, 1, 1);
+ hdmi_write_reg(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_SYS_VID_ACEN, var);
+ break;
+ case HDMI_FULL_RANGE:
+ default:
+ /* HDMI 1.3 section 6.6 YCBCR components shall
+* always be Limited Range
+*/
+ if (ip_data-avi_cfg.db1_format ==
+ HDMI_INFOFRAME_AVI_DB1Y_YUV422) {
+ pr_err(Only limited range is supported for YUV);
+ return -EINVAL;
+ }
+ ip_data-avi_cfg.db3_q_range = HDMI_INFOFRAME_AVI_DB3Q_FR;
+ hdmi_core_aux_infoframe_avi_config(ip_data);
+ var = hdmi_read_reg(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_SYS_VID_MODE);
+ var = FLD_MOD(var, 1, 4, 4);
+ hdmi_write_reg(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_SYS_VID_MODE, var);
+ break;
+ }
+ return 0;
+}
+
static void hdmi_core_av_packet_config(struct hdmi_ip_data *ip_data,
struct hdmi_core_packet_enable_repeat repeat_cfg)
{
--
1.7.5.4
--
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 3/3] OMAPDSS: HDMI: Sysfs support to configure quantization
From: Mythri P K mythr...@ti.com
Add sysfs support for the uset space to configure limited range or full range
quantization for HDMI.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/dss.h |2 +
drivers/video/omap2/dss/dss_features.c |1 +
drivers/video/omap2/dss/hdmi.c | 28 +
drivers/video/omap2/dss/hdmi_panel.c | 35 +++-
drivers/video/omap2/dss/ti_hdmi.h |2 +
5 files changed, 67 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 6308fc5..cf1f0f9 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -498,6 +498,8 @@ int omapdss_hdmi_display_check_timing(struct
omap_dss_device *dssdev,
struct omap_video_timings *timings);
int omapdss_hdmi_read_edid(u8 *buf, int len);
bool omapdss_hdmi_detect(void);
+int omapdss_hdmi_get_range(void);
+int omapdss_hdmi_set_range(int range);
int hdmi_panel_init(void);
void hdmi_panel_exit(void);
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index b402699..c7e71b9 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -465,6 +465,7 @@ static const struct ti_hdmi_ip_ops omap4_hdmi_functions = {
.dump_core = ti_hdmi_4xxx_core_dump,
.dump_pll = ti_hdmi_4xxx_pll_dump,
.dump_phy = ti_hdmi_4xxx_phy_dump,
+ .configure_range= ti_hdmi_4xxx_configure_range,
};
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 4bb7678..ae7918e 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -378,6 +378,34 @@ static void hdmi_power_off(struct omap_dss_device *dssdev)
hdmi_runtime_put();
}
+int omapdss_hdmi_set_range(int range)
+{
+ int r = 0;
+ enum hdmi_range old_range;
+
+ old_range = hdmi.ip_data.range;
+ hdmi.ip_data.range = range;
+
+ /* HDMI 1.3 section 6.6 VGA (640x480) format requires Full Range */
+ if ((range == 0)
+ ((hdmi.ip_data.cfg.cm.code == 4
+ hdmi.ip_data.cfg.cm.mode == HDMI_DVI) ||
+ (hdmi.ip_data.cfg.cm.code == 1
+ hdmi.ip_data.cfg.cm.mode == HDMI_HDMI)))
+ return -EINVAL;
+
+ r = hdmi.ip_data.ops-configure_range(hdmi.ip_data);
+ if (r)
+ hdmi.ip_data.range = old_range;
+
+ return r;
+}
+
+int omapdss_hdmi_get_range(void)
+{
+ return hdmi.ip_data.range;
+}
+
int omapdss_hdmi_display_check_timing(struct omap_dss_device *dssdev,
struct omap_video_timings *timings)
{
diff --git a/drivers/video/omap2/dss/hdmi_panel.c
b/drivers/video/omap2/dss/hdmi_panel.c
index 533d5dc..c0aa922 100644
--- a/drivers/video/omap2/dss/hdmi_panel.c
+++ b/drivers/video/omap2/dss/hdmi_panel.c
@@ -33,6 +33,33 @@ static struct {
struct mutex hdmi_lock;
} hdmi;
+static ssize_t hdmi_range_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int r;
+
+ r = omapdss_hdmi_get_range();
+ return snprintf(buf, PAGE_SIZE, %d\n, r);
+}
+
+static ssize_t hdmi_range_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ unsigned long range;
+ int r = kstrtoul(buf, 0, range);
+
+ if (r || range 1)
+ return -EINVAL;
+
+ r = omapdss_hdmi_set_range(range);
+ if (r)
+ return r;
+
+ return size;
+}
+
+static DEVICE_ATTR(range, S_IRUGO | S_IWUSR, hdmi_range_show,
hdmi_range_store);
static int hdmi_panel_probe(struct omap_dss_device *dssdev)
{
@@ -41,6 +68,12 @@ static int hdmi_panel_probe(struct omap_dss_device *dssdev)
dssdev-panel.config = OMAP_DSS_LCD_TFT |
OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS;
+ /* sysfs entry to provide user space control to set
+* quantization range
+*/
+ if (device_create_file(dssdev-dev, dev_attr_range))
+ DSSERR(failed to create sysfs file\n);
+
dssdev-panel.timings = (struct omap_video_timings){640, 480, 25175,
96, 16, 48, 2 , 11, 31};
DSSDBG(hdmi_panel_probe x_res= %d y_res = %d\n,
@@ -51,7 +84,7 @@ static int hdmi_panel_probe(struct omap_dss_device *dssdev)
static void hdmi_panel_remove(struct omap_dss_device *dssdev)
{
-
+ device_remove_file(dssdev-dev, dev_attr_range);
}
static int hdmi_panel_enable(struct omap_dss_device *dssdev)
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index 1b485ee..1f15d74 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -111,6 +111,8 @@ struct ti_hdmi_ip_ops {
void (*dump_phy)(struct
[PATCH v2 1/3] OMAPDSS: HDMI: Move Avi-infoframe struct to hdmi_ip_data
From: Mythri P K mythr...@ti.com
With AVI infoframe various parameters of video stream such as
aspect ratio, quantization range, videocode etc will be indicated
from source to sink.Thus AVI information needs to be set/accessed
by the middle ware based on the video content.
Thus this parameter is now moved to the ip_data structure.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi.h | 42 +
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |8 +++---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 40 ---
3 files changed, 46 insertions(+), 44 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index 3cf5198..835cfb1 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -108,6 +108,47 @@ struct ti_hdmi_ip_ops {
};
+/*
+ * Refer to section 8.2 in HDMI 1.3 specification for
+ * details about infoframe databytes
+ */
+struct hdmi_core_infoframe_avi {
+ /* Y0, Y1 rgb,yCbCr */
+ u8 db1_format;
+ /* A0 Active information Present */
+ u8 db1_active_info;
+ /* B0, B1 Bar info data valid */
+ u8 db1_bar_info_dv;
+ /* S0, S1 scan information */
+ u8 db1_scan_info;
+ /* C0, C1 colorimetry */
+ u8 db2_colorimetry;
+ /* M0, M1 Aspect ratio (4:3, 16:9) */
+ u8 db2_aspect_ratio;
+ /* R0...R3 Active format aspect ratio */
+ u8 db2_active_fmt_ar;
+ /* ITC IT content. */
+ u8 db3_itc;
+ /* EC0, EC1, EC2 Extended colorimetry */
+ u8 db3_ec;
+ /* Q1, Q0 Quantization range */
+ u8 db3_q_range;
+ /* SC1, SC0 Non-uniform picture scaling */
+ u8 db3_nup_scaling;
+ /* VIC0..6 Video format identification */
+ u8 db4_videocode;
+ /* PR0..PR3 Pixel repetition factor */
+ u8 db5_pixel_repeat;
+ /* Line number end of top bar */
+ u16 db6_7_line_eoftop;
+ /* Line number start of bottom bar */
+ u16 db8_9_line_sofbottom;
+ /* Pixel number end of left bar */
+ u16 db10_11_pixel_eofleft;
+ /* Pixel number start of right bar */
+ u16 db12_13_pixel_sofright;
+};
+
struct hdmi_ip_data {
void __iomem*base_wp; /* HDMI wrapper */
unsigned long core_sys_offset;
@@ -117,6 +158,7 @@ struct hdmi_ip_data {
const struct ti_hdmi_ip_ops *ops;
struct hdmi_config cfg;
struct hdmi_pll_info pll_data;
+ struct hdmi_core_infoframe_avi avi_cfg;
};
int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data);
void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data);
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index ccc6254..b66d82e 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -534,12 +534,12 @@ static void hdmi_core_video_config(struct hdmi_ip_data
*ip_data,
HDMI_CORE_SYS_TMDS_CTRL, cfg-tclk_sel_clkmult, 6, 5);
}
-static void hdmi_core_aux_infoframe_avi_config(struct hdmi_ip_data *ip_data,
- struct hdmi_core_infoframe_avi info_avi)
+static void hdmi_core_aux_infoframe_avi_config(struct hdmi_ip_data *ip_data)
{
u32 val;
char sum = 0, checksum = 0;
void __iomem *av_base = hdmi_av_base(ip_data);
+ struct hdmi_core_infoframe_avi info_avi = ip_data-avi_cfg;
sum += 0x82 + 0x002 + 0x00D;
hdmi_write_reg(av_base, HDMI_CORE_AV_AVI_TYPE, 0x082);
@@ -718,7 +718,7 @@ void ti_hdmi_4xxx_basic_configure(struct hdmi_ip_data
*ip_data)
struct omap_video_timings video_timing;
struct hdmi_video_format video_format;
/* HDMI core */
- struct hdmi_core_infoframe_avi avi_cfg;
+ struct hdmi_core_infoframe_avi avi_cfg = ip_data-avi_cfg;
struct hdmi_core_video_config v_core_cfg;
struct hdmi_core_packet_enable_repeat repeat_cfg;
struct hdmi_config *cfg = ip_data-cfg;
@@ -780,7 +780,7 @@ void ti_hdmi_4xxx_basic_configure(struct hdmi_ip_data
*ip_data)
avi_cfg.db10_11_pixel_eofleft = 0;
avi_cfg.db12_13_pixel_sofright = 0;
- hdmi_core_aux_infoframe_avi_config(ip_data, avi_cfg);
+ hdmi_core_aux_infoframe_avi_config(ip_data);
/* enable/repeat the infoframe */
repeat_cfg.avi_infoframe = HDMI_PACKETENABLE;
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
index 914bec6..21f1d82 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h
@@ -450,46 +450,6 @@ struct hdmi_core_video_config {
* Refer to section 8.2 in HDMI 1.3 specification for
* details about infoframe databytes
*/
-struct hdmi_core_infoframe_avi {
- /* Y0, Y1 rgb,yCbCr */
- u8 db1_format;
-
Re: [PATCH 1/3 REPOST] OMAPDSS: HDMI: Move Avi infoframe structure to
Hi Tomi,
On Tue, Jan 3, 2012 at 3:39 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hi,
Again the subjects are cut off in mid sentence. And the patch series
contains patch 1 two times.
Please use git-format-patch and git-send-email to send proper patches,
and please check the patches before sending.
I resent the patches with fixed header.
Thanks and regards,
Mythri.
Tomi
On Mon, 2012-01-02 at 14:28 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
With AVI infoframe various parameters of video stream such as
aspect ratio, quantization range, videocode etc will be indicated
from source to sink.Thus AVI information needs to be set/accessed
by the middle ware based on the video content.
Thus this parameter is now moved to the ip_data structure.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi.h | 42
+
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 8 +++---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.h | 40 ---
3 files changed, 46 insertions(+), 44 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index 3cf5198..835cfb1 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -108,6 +108,47 @@ struct ti_hdmi_ip_ops {
};
+/*
+ * Refer to section 8.2 in HDMI 1.3 specification for
+ * details about infoframe databytes
+ */
+struct hdmi_core_infoframe_avi {
+ /* Y0, Y1 rgb,yCbCr */
+ u8 db1_format;
+ /* A0 Active information Present */
+ u8 db1_active_info;
+ /* B0, B1 Bar info data valid */
+ u8 db1_bar_info_dv;
+ /* S0, S1 scan information */
+ u8 db1_scan_info;
+ /* C0, C1 colorimetry */
+ u8 db2_colorimetry;
+ /* M0, M1 Aspect ratio (4:3, 16:9) */
+ u8 db2_aspect_ratio;
+ /* R0...R3 Active format aspect ratio */
+ u8 db2_active_fmt_ar;
+ /* ITC IT content. */
+ u8 db3_itc;
+ /* EC0, EC1, EC2 Extended colorimetry */
+ u8 db3_ec;
+ /* Q1, Q0 Quantization range */
+ u8 db3_q_range;
+ /* SC1, SC0 Non-uniform picture scaling */
+ u8 db3_nup_scaling;
+ /* VIC0..6 Video format identification */
+ u8 db4_videocode;
+ /* PR0..PR3 Pixel repetition factor */
+ u8 db5_pixel_repeat;
+ /* Line number end of top bar */
+ u16 db6_7_line_eoftop;
+ /* Line number start of bottom bar */
+ u16 db8_9_line_sofbottom;
+ /* Pixel number end of left bar */
+ u16 db10_11_pixel_eofleft;
+ /* Pixel number start of right bar */
+ u16 db12_13_pixel_sofright;
+};
+
struct hdmi_ip_data {
void __iomem *base_wp; /* HDMI wrapper */
unsigned long core_sys_offset;
@@ -117,6 +158,7 @@ struct hdmi_ip_data {
const struct ti_hdmi_ip_ops *ops;
struct hdmi_config cfg;
struct hdmi_pll_info pll_data;
+ struct hdmi_core_infoframe_avi avi_cfg;
};
int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data);
void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data);
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index ccc6254..b66d82e 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -534,12 +534,12 @@ static void hdmi_core_video_config(struct hdmi_ip_data
*ip_data,
HDMI_CORE_SYS_TMDS_CTRL, cfg-tclk_sel_clkmult, 6, 5);
}
-static void hdmi_core_aux_infoframe_avi_config(struct hdmi_ip_data *ip_data,
- struct hdmi_core_infoframe_avi info_avi)
+static void hdmi_core_aux_infoframe_avi_config(struct hdmi_ip_data *ip_data)
{
u32 val;
char sum = 0, checksum = 0;
void __iomem *av_base = hdmi_av_base(ip_data);
+ struct hdmi_core_infoframe_avi info_avi = ip_data-avi_cfg;
sum += 0x82 + 0x002 + 0x00D;
hdmi_write_reg(av_base, HDMI_CORE_AV_AVI_TYPE, 0x082);
@@ -718,7 +718,7 @@ void ti_hdmi_4xxx_basic_configure(struct hdmi_ip_data
*ip_data)
struct omap_video_timings video_timing;
struct hdmi_video_format video_format;
/* HDMI core */
- struct hdmi_core_infoframe_avi avi_cfg;
+ struct hdmi_core_infoframe_avi avi_cfg = ip_data-avi_cfg;
struct hdmi_core_video_config v_core_cfg;
struct hdmi_core_packet_enable_repeat repeat_cfg;
struct hdmi_config *cfg = ip_data-cfg;
@@ -780,7 +780,7 @@ void ti_hdmi_4xxx_basic_configure(struct hdmi_ip_data
*ip_data)
avi_cfg.db10_11_pixel_eofleft = 0;
avi_cfg.db12_13_pixel_sofright = 0;
- hdmi_core_aux_infoframe_avi_config(ip_data, avi_cfg);
+ hdmi_core_aux_infoframe_avi_config(ip_data);
/* enable/repeat the infoframe */
repeat_cfg.avi_infoframe = HDMI_PACKETENABLE;
diff --git
Re: [PATCH v2 02/10] i2c: OMAP: Add DT support for i2c controller
Hi Kevin, On 12/14/2011 2:06 AM, Kevin Hilman wrote: Benoit Coussonb-cous...@ti.com writes: Add initial DT support to retrieve the frequency using a DT attribute instead of the pdata pointer if of_node exist. Add documentation for omap i2c controller binding. Based on original patches from Manju and Grant. Signed-off-by: Benoit Coussonb-cous...@ti.com Cc: Ben Dooksben-li...@fluff.org This seems indepenent from the rest of the series, and I can queue up for merge via the I2C tree. Benoit, please confirm that we shouldn't have any problems if this patch goes independently. Grant/Rob, with your ack on the bindings, I can queue this up for the I2C maintainers along with some other OMAP I2C changes for v3.3. I removed the nasty bindings and got the Reviewed-by: from Rob for the v4 [1]. Could you take it in your branch? I've just tried merging your for_3.3/i2c/misc on top of my for_3.3/3_omap_dt_i2c_twl branch and tested it successfully on OMAP4 DT boot. Thanks, Benoit [1] http://lkml.org/lkml/2011/12/22/176 -- 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: [linux-pm] [PATCH 1/3] cpuidle: refactor out cpuidle_enter_state
Hi Colin,
On Wed, Dec 21, 2011 at 1:09 AM, Colin Cross ccr...@android.com wrote:
Split the code to enter a state and update the stats into a helper
function, cpuidle_enter_state, and export it. This function will
be called by the coupled state code to handle entering the safe
state and the final coupled state.
Signed-off-by: Colin Cross ccr...@android.com
---
drivers/cpuidle/cpuidle.c | 43 +--
drivers/cpuidle/cpuidle.h | 2 ++
2 files changed, 31 insertions(+), 14 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 06ce268..1486b3c 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -54,6 +54,34 @@ static void cpuidle_kick_cpus(void) {}
static int __cpuidle_register_device(struct cpuidle_device *dev);
/**
+ * cpuidle_enter_state
+ *
+ * enter the state and update stats
+ */
+int cpuidle_enter_state(struct cpuidle_device *dev, struct cpuidle_driver
*drv,
+ int next_state)
+{
+ int entered_state;
+ struct cpuidle_state *target_state;
+
+ target_state = drv-states[next_state];
+
+ entered_state = target_state-enter(dev, drv, next_state);
+
+ if (entered_state = 0) {
+ /* Update cpuidle counters */
+ /* This can be moved to within driver enter routine
+ * but that results in multiple copies of same code.
+ */
+ dev-states_usage[entered_state].time +=
+ (unsigned long long)dev-last_residency;
+ dev-states_usage[entered_state].usage++;
+ }
+
+ return entered_state;
+}
+
+/**
* cpuidle_idle_call - the main idle loop
*
* NOTE: no locks or semaphores should be used here
@@ -63,7 +91,6 @@ int cpuidle_idle_call(void)
{
struct cpuidle_device *dev = __this_cpu_read(cpuidle_devices);
struct cpuidle_driver *drv = cpuidle_get_driver();
- struct cpuidle_state *target_state;
int next_state, entered_state;
if (off)
@@ -92,26 +119,14 @@ int cpuidle_idle_call(void)
return 0;
}
- target_state = drv-states[next_state];
-
trace_power_start(POWER_CSTATE, next_state, dev-cpu);
trace_cpu_idle(next_state, dev-cpu);
- entered_state = target_state-enter(dev, drv, next_state);
+ entered_state = cpuidle_enter_state(dev, drv, next_state);
trace_power_end(dev-cpu);
trace_cpu_idle(PWR_EVENT_EXIT, dev-cpu);
The cpu_idle traces are only present in this function and not in
cpuidle_enter_state. Is that expected? Can all the transitions from
all the cpus get traced that way?
Regards,
Jean
--
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/3] of/irq: Add interrupts-names property to name an irq resource
Hi Grant,
On 1/4/2012 8:17 AM, Grant Likely wrote:
On Mon, Dec 05, 2011 at 03:23:56PM +0100, Benoit Cousson wrote:
In a HW system, resources in general have name to identify them.
The is the case as well for IORESOURCE_IRQ resources filled by DT
interrupts entries.
The current DT mechanism is relying on the interrupts order to identify
the proper resource. This is error prone and not the natural way to
retrieve an information in general.
I do not agree with this assessment. interrupt property order has
worked quite well for a very long time. There are some uses cases
that want to access it by-name, but I expect accessing by-index to
continue to be the preferred method. I'm going to drop this paragraph
from the commit text.
OK, fair enough. My point was when the HW description is providing names
to list several IRQ resources, giving a number instead is error prone.
If, on the other side, the spec is providing something like IRQ_A, B or
C, then yes, the by-index is the natural one.
Considering that most IPs will anyway only have one IRQ line, the
by-index method will be the most widely used.
Moreover, the resource does support a name and an API is available to
allow a driver to retrieve the resource using the name instead of an
index.
Add a interrupts-names property to allow the possiblity to provide a name
to any interrupts entries.
If the name is available, use it to name the resource, otherwise
keep the legacy device full name.
Signed-off-by: Benoit Coussonb-cous...@ti.com
Cc: Grant Likelygrant.lik...@secretlab.ca
Cc: Rob Herringrob.herr...@calxeda.com
---
.../devicetree/bindings/interrupts-names.txt | 50
drivers/of/irq.c | 11 -
2 files changed, 60 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/interrupts-names.txt
diff --git a/Documentation/devicetree/bindings/interrupts-names.txt
b/Documentation/devicetree/bindings/interrupts-names.txt
new file mode 100644
index 000..d9a796d
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupts-names.txt
@@ -0,0 +1,50 @@
+interrupts-names property
+
+In a HW system, physical resources in general have name to identify them.
+The is the case as well for interrupt lines.
+The current DT mechanism is relying on the interrupts order to identify
+the proper resource. The interrupts-names is adding the possiblity to
+provide a name to interrupts entries.
+
+Usage:
+
+This attribute must be used along with a regular interrupts entry. If not
+it will be simply ignored.
This documentation is pretty much identical to the reg-names property
description. I'll merge the two into a single file.
OK.
+
+
+Example:
+
+
+l4-abe {
+ compatible = simple-bus;
+ #address-cells =2;
+ #size-cells =1;
+ ranges =0 0 0x4800 0x1000, /* MPU path */
+ 1 0 0x4900 0x1000; /* L3 path */
+ mcasp {
+ compatible = ti,mcasp;
+ reg =0 0x10 0x10,0 0x20 0x10,
+ 1 0x10 0x10,1 0x20 0x10;
+ reg-names = mpu, dat,
+ dma, dma_dat;
+ interrupts =11,12;
+ interrupts-names = rx, tx;
Nitpick: I'm going to change the property name to interrupt-names
(dropping the 's' from interrupts). After playing with the clock
binding (clocks vs. clock-names) and looking at what could be done
with the gpio binding (gpios vs. gpio-names), I think it 'feels' more
consistent to drop the s.
Fully agree, I made a comment on that in the cover-letter because I was
not fully happy with that either.
Merged, thanks.
Cool, thanks.
Regards,
Benoit
--
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 v4 3/6] clk: introduce the common clock framework
On 01/03/2012 08:15 PM, Richard Zhao wrote:
On Fri, Dec 16, 2011 at 04:45:48PM -0800, Turquette, Mike wrote:
On Wed, Dec 14, 2011 at 5:18 AM, Thomas Gleixner t...@linutronix.de wrote:
On Tue, 13 Dec 2011, Mike Turquette wrote:
snip
+/**
+ * clk_init - initialize the data structures in a struct clk
+ * @dev: device initializing this clk, placeholder for now
+ * @clk: clk being initialized
+ *
+ * Initializes the lists in struct clk, queries the hardware for the
+ * parent and rate and sets them both. Adds the clk to the sysfs tree
+ * topology.
+ *
+ * Caller must populate clk-name and clk-flags before calling
I'm not too happy about this construct. That leaves struct clk and its
members exposed to the world instead of making it a real opaque
cookie. I know from my own painful experience, that this will lead to
random fiddling in that data structure in drivers and arch code just
because the core code has a shortcoming.
Why can't we make struct clk a real cookie and confine the data
structure to the core code ?
That would change the init call to something like:
struct clk *clk_init(struct device *dev, const struct clk_hw *hw,
struct clk *parent)
And have:
struct clk_hw {
struct clk_hw_ops *ops;
const char*name;
unsigned long flags;
};
Implementers can do:
struct my_clk_hw {
struct clk_hwhw;
mydata;
};
And then change the clk ops callbacks to take struct clk_hw * as an
argument.
We have to define static clocks before we adopt DT binding.
If clk is opaque and allocate memory in clk core, it'll make hard
to define static clocks. And register/init will pass a long parameter
list.
DT is not a prerequisite for having dynamically created clocks. You can
make clock init dynamic without DT.
What data goes in struct clk vs. struct clk_hw could change over time.
So perhaps we can start with some data in clk_hw and plan to move it to
struct clk later. Even if almost everything ends up in clk_hw initially,
at least the structure is in place to have common, core-only data
separate from platform data.
What is the actual data you need to be static and accessible to the
platform code? A ptr to parent clk is the main thing I've seen for
static initialization. So make the parent ptr be struct clk_hw* and
allow the platforms to access.
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
Re: [PATCH] ARM: OMAP2+ i2c NACK without STP
I have found another circumstance in which the bus locks up which is possibly a
regression caused by this patch.
When performing a transfer with repeat starts, if one of the parts, that is is
NOT the last in the sequence AND is a master-write AND is NACKed by the remote
device, OMAP_I2C_CON_STP is never set and the bus is left in the busy state
when returning to user-land with an error-code.
This code responsible for this is towards the bottom of omap_i2c_xfer_msg()
generates OMAP_I2C_CON_STP only when the NACK occurs on the last part of a
repeat-start transfer.
if (dev-cmd_err OMAP_I2C_STAT_NACK) {
..
if (stop) {
w = omap_i2c_read_reg(dev, OMAP_I2C_CON_REG);
w |= OMAP_I2C_CON_STP;
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
}
return -EREMOTEIO;
The caller - omap_i2c_xfer() - quickly bails following the error and doesn't
attempt to try subsequent parts of the transfer.
I'm slight perplexed by the original intention here: was it to i) fail quickly
or ii) retry iii) continue with remaining parts of the transfer?
The first of these feels right to me - in which we case we need a
OMAP_I2C_CON_STP asserted following all NACKs
Anyone got any insight?
Mark
On Tue, Jun 14, 2011 at 4:24 PM, Jan Weitzel j.weit...@phytec.de wrote:
On OMAP4 OMAP_I2C_STAT_NACK is causing a timeout on the next access.
The isr cleans all flags in OMAP_I2C_CON_REG by setting OMAP_I2C_CON_STP
OMAP_I2C_CON_STP is also set in omap_i2c_xfer_msg on the last message.
According to the TI TSR the sequence for OMAP_I2C_STAT_NACK and
OMAP_I2C_STAT_AL are nearly the same.
Removing the OMAP_I2C_CON_STP part in the isr fix the problem.
Tested on OMAP4430 and OMAP3530 (here NACK was not a problem)
Fixes also booting on 2430sdp.
Signed-off-by: Jan Weitzel j.weit...@phytec.de
Acked-by: Tony Lindgren t...@atomide.com
Acked-by: Balaji T K balaj...@ti.com
Can you please queue this patch
This patch has been tested in linux-omap tree
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commit;h=464fca36d98b97ccd05e4f200ab7483d3acc8345
---
drivers/i2c/busses/i2c-omap.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 58a58c7..670f2a2 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -836,11 +836,9 @@ complete:
~(OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR |
OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR));
- if (stat OMAP_I2C_STAT_NACK) {
+ if (stat OMAP_I2C_STAT_NACK)
err |= OMAP_I2C_STAT_NACK;
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG,
- OMAP_I2C_CON_STP);
- }
+
if (stat OMAP_I2C_STAT_AL) {
dev_err(dev-dev, Arbitration lost\n);
err |= OMAP_I2C_STAT_AL;
--
1.7.0.4
--
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
--
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
--
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 0/3] coupled cpuidle state support
On Wed, Jan 4, 2012 at 1:41 AM, Kevin Hilman khil...@ti.com wrote: Colin Cross ccr...@android.com writes: This patch series implements an alternative solution, where each cpu will wait in the WFI state until all cpus are ready to enter a coupled state, at which point the coupled state function will be called on all cpus at approximately the same time. This looks great, and is certainly preferred to hotplug IMO. [...] None of the platforms I work with have an SMP idle implementation upstream, so I can't easily show a patch that converts a platform from hotplug governor to coupled cpuidle states. Basic OMAP4 CPUidle support is in now queued for v3.3 (see omap4 branch Tony's tree[1].) Can you (or Santosh) send a patch that adds coupled support to that driver so it can see some broader testing on OMAP4? I briefly attempted OMAP4 idle with this series but had some lock up related issues which we faced in the older development. Then I got busy into other activities which will keep me occupied for next few weeks. I will be happy to share the patches in case some one would like to have a look till then. Regards Santosh -- 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 v2 10/10] ARM: OMAP2+: board-generic: Remove i2c static init
On Fri, Dec 09, 2011 at 03:02:41PM +0100, Benoit Cousson wrote:
This mainly reverts the commit that was adding the i2c static init.
Since the i2c and twl nodes are now present, there is no need
for the static initialization anymore.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/mach-omap2/board-generic.c | 48 +-
1 files changed, 2 insertions(+), 46 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 16c301e..63a2495 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -15,7 +15,6 @@
#include linux/of_irq.h
#include linux/of_platform.h
#include linux/irqdomain.h
-#include linux/i2c/twl.h
#include mach/hardware.h
#include asm/hardware/gic.h
@@ -36,34 +35,6 @@ static void __init omap_init_irq(void)
of_irq_init(irq_match);
}
-/*
- * XXX: Still needed to boot until the i2c twl driver is adapted to
- * device-tree
- */
-#ifdef CONFIG_ARCH_OMAP4
-static struct twl4030_platform_data sdp4430_twldata = {
- .irq_base = TWL6030_IRQ_BASE,
- .irq_end= TWL6030_IRQ_END,
-};
-
-static void __init omap4_i2c_init(void)
-{
- omap4_pmic_init(twl6030, sdp4430_twldata);
-}
-#endif
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct twl4030_platform_data beagle_twldata = {
- .irq_base = TWL4030_IRQ_BASE,
- .irq_end= TWL4030_IRQ_END,
-};
-
-static void __init omap3_i2c_init(void)
-{
- omap3_pmic_init(twl4030, beagle_twldata);
-}
-#endif
-
static struct of_device_id omap_dt_match_table[] __initdata = {
{ .compatible = simple-bus, },
{ .compatible = ti,omap-infra, },
@@ -78,21 +49,6 @@ static void __init omap_generic_init(void)
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
}
-#ifdef CONFIG_ARCH_OMAP4
-static void __init omap4_init(void)
-{
- omap4_i2c_init();
- omap_generic_init();
-}
-#endif
-
-#ifdef CONFIG_ARCH_OMAP3
-static void __init omap3_init(void)
-{
- omap3_i2c_init();
- omap_generic_init();
-}
-#endif
#ifdef CONFIG_SOC_OMAP2420
static const char *omap242x_boards_compat[] __initdata = {
@@ -145,7 +101,7 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened
Device Tree))
.init_early = omap3430_init_early,
.init_irq = omap_init_irq,
.handle_irq = omap3_intc_handle_irq,
- .init_machine = omap3_init,
+ .init_machine = omap_generic_init,
.timer = omap3_timer,
.dt_compat = omap3_boards_compat,
MACHINE_END
@@ -164,7 +120,7 @@ DT_MACHINE_START(OMAP4_DT, Generic OMAP4 (Flattened
Device Tree))
.init_early = omap4430_init_early,
.init_irq = omap_init_irq,
.handle_irq = gic_handle_irq,
- .init_machine = omap4_init,
+ .init_machine = omap_generic_init,
.timer = omap4_timer,
.dt_compat = omap4_boards_compat,
MACHINE_END
--
1.7.0.4
--
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 v2 06/10] arm/dts: OMAP3: Add i2c controller nodes
On Fri, Dec 09, 2011 at 03:02:37PM +0100, Benoit Cousson wrote:
Add i2c controllers nodes into the main ocp bus.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/boot/dts/omap3.dtsi | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 6866dc7..81d8e2c 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -61,5 +61,33 @@
ti,intc-size = 96;
reg = 0x4820 0x1000;
};
+
+ /*
+ * Flags for all i2c instances: 0x118
+ * APPLY_ERRATA_I207 | RESET_REGS_POSTIDLE | BUS_SHIFT_2
+ */
+ i2c1: i2c@1 {
+ compatible = ti,omap3-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = i2c1;
+ ti,flags = 0x118;
+ };
+
+ i2c2: i2c@2 {
+ compatible = ti,omap3-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = i2c2;
+ ti,flags = 0x118;
+ };
+
+ i2c3: i2c@3 {
+ compatible = ti,omap3-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = i2c3;
+ ti,flags = 0x118;
+ };
};
};
--
1.7.0.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 v2 01/10] ARM: OMAP2+: pm: Do not init statically the SR and voltage layer with DT
On Fri, Dec 09, 2011 at 03:02:32PM +0100, Benoit Cousson wrote:
In the case of DT, the PMIC and SR initialization will be done using
a completely different mechanism.
Disable this part if a DT blob is available.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/pm.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 1881fe9..ad4f693 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -227,6 +227,14 @@ postcore_initcall(omap2_common_pm_init);
static int __init omap2_common_pm_late_init(void)
{
+ /*
+ * In the case of DT, the PMIC and SR initialization will be done using
+ * a completely different mechanism.
+ * Disable this part if a DT blob is available.
+ */
+ if (of_have_populated_dt())
+ return 0;
+
/* Init the voltage layer */
omap_pmic_late_init();
omap_voltage_late_init();
--
1.7.0.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 v2 05/10] arm/dts: OMAP4: Add i2c controller nodes
On Fri, Dec 09, 2011 at 03:02:36PM +0100, Benoit Cousson wrote:
Add i2c controllers nodes into the main ocp bus.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/boot/dts/omap4.dtsi | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index bede009..9872283 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -100,5 +100,33 @@
reg = 0x48241000 0x1000,
0x48240100 0x0100;
};
+
+ i2c1: i2c@1 {
+ compatible = ti,omap4-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = i2c1;
+ };
+
+ i2c2: i2c@2 {
+ compatible = ti,omap4-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = i2c2;
+ };
+
+ i2c3: i2c@3 {
+ compatible = ti,omap4-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = i2c3;
+ };
+
+ i2c4: i2c@4 {
+ compatible = ti,omap4-i2c;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = i2c4;
+ };
};
};
--
1.7.0.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 v2 02/10] i2c: OMAP: Add DT support for i2c controller
On Wed, Jan 04, 2012 at 02:36:24PM +0100, Cousson, Benoit wrote: Hi Kevin, On 12/14/2011 2:06 AM, Kevin Hilman wrote: Benoit Coussonb-cous...@ti.com writes: Add initial DT support to retrieve the frequency using a DT attribute instead of the pdata pointer if of_node exist. Add documentation for omap i2c controller binding. Based on original patches from Manju and Grant. Signed-off-by: Benoit Coussonb-cous...@ti.com Cc: Ben Dooksben-li...@fluff.org This seems indepenent from the rest of the series, and I can queue up for merge via the I2C tree. Benoit, please confirm that we shouldn't have any problems if this patch goes independently. Grant/Rob, with your ack on the bindings, I can queue this up for the I2C maintainers along with some other OMAP I2C changes for v3.3. I removed the nasty bindings and got the Reviewed-by: from Rob for the v4 [1]. Could you take it in your branch? I've just tried merging your for_3.3/i2c/misc on top of my for_3.3/3_omap_dt_i2c_twl branch and tested it successfully on OMAP4 DT boot. Acked-by: Grant Likely grant.lik...@secretlab.ca Thanks, Benoit [1] http://lkml.org/lkml/2011/12/22/176 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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 v2 04/10] rtc: rtc-twl: Add DT support for RTC inside twl4030/twl6030
On Fri, Dec 09, 2011 at 03:02:35PM +0100, Benoit Cousson wrote:
Add the DT support for the TI rtc-twl present in the twl4030
and twl6030 devices.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Alessandro Zummo a.zu...@towertech.it
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
Documentation/devicetree/bindings/rtc/twl-rtc.txt | 12
drivers/rtc/rtc-twl.c | 10 --
2 files changed, 20 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rtc/twl-rtc.txt
diff --git a/Documentation/devicetree/bindings/rtc/twl-rtc.txt
b/Documentation/devicetree/bindings/rtc/twl-rtc.txt
new file mode 100644
index 000..596e0c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/twl-rtc.txt
@@ -0,0 +1,12 @@
+* TI twl RTC
+
+The TWL family (twl4030/6030) contains a RTC.
+
+Required properties:
+- compatible : Should be twl4030-rtc
+
+Examples:
+
+rtc@0 {
+compatible = ti,twl4030-rtc;
+};
diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
index 20687d5..d43b4f6 100644
--- a/drivers/rtc/rtc-twl.c
+++ b/drivers/rtc/rtc-twl.c
@@ -550,6 +550,11 @@ static int twl_rtc_resume(struct platform_device *pdev)
#define twl_rtc_resume NULL
#endif
+static const struct of_device_id twl_rtc_of_match[] = {
+ {.compatible = ti,twl4030-rtc, },
+ { },
+};
+MODULE_DEVICE_TABLE(of, twl_rtc_of_match);
MODULE_ALIAS(platform:twl_rtc);
static struct platform_driver twl4030rtc_driver = {
@@ -559,8 +564,9 @@ static struct platform_driver twl4030rtc_driver = {
.suspend= twl_rtc_suspend,
.resume = twl_rtc_resume,
.driver = {
- .owner = THIS_MODULE,
- .name = twl_rtc,
+ .owner = THIS_MODULE,
+ .name = twl_rtc,
+ .of_match_table = twl_rtc_of_match,
},
};
--
1.7.0.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 v2 09/10] arm/dts: omap3-beagle: Add twl4030 and i2c EEPROM
On Fri, Dec 09, 2011 at 03:02:40PM +0100, Benoit Cousson wrote:
Add required clock frequencies for the i2c client devices existing
on beagle board.
Add the twl4030 basic description with only the twl_rtc module.
Add the EEPROM node.
Based on original patch from Manju:
http://www.spinics.net/lists/linux-omap/msg55831.html
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/boot/dts/omap3-beagle.dts | 38
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 9f72cd4..b648279 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -18,3 +18,41 @@
reg = 0x8000 0x2000; /* 512 MB */
};
};
+
+i2c1 {
+ clock-frequency = 260;
+
+ /*
+ * Integrated Power Management Chip
+ */
+ twl@48 {
+ compatible = ti,twl4030;
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-controller;
+ #interrupt-cells = 1;
+ interrupt-parent = intc;
+
+ twl_rtc {
+ compatible = ti,twl4030-rtc;
+ interrupts = 11;
+ };
+ };
+};
+
+i2c2 {
+ clock-frequency = 40;
+};
+
+i2c3 {
+ clock-frequency = 10;
+
+ /*
+ * Display monitor features are burnt in the EEPROM
+ * as EDID data.
+ */
+ eeprom@50 {
+ compatible = ti,eeprom;
+ reg = 0x50;
+ };
+};
--
1.7.0.4
--
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 v2 03/10] mfd: twl-core: Add initial DT support for twl4030/twl6030
On Fri, Dec 09, 2011 at 03:02:34PM +0100, Benoit Cousson wrote:
Add initial device-tree support for twl familly chips.
The current version is missing the regulator entries due
to the lack of DT regulator bindings for the moment.
Only the simple sub-modules that do not depend on
platform_data information can be initialized properly.
Add documentation for the Texas Instruments TWL Integrated Chip.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Balaji T K balaj...@ti.com
Cc: Graeme Gregory g...@slimlogic.co.uk
Cc: Samuel Ortiz sa...@linux.intel.com
---
.../devicetree/bindings/mfd/twl-familly.txt| 47 +
drivers/mfd/twl-core.c | 53
++--
2 files changed, 96 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/twl-familly.txt
diff --git a/Documentation/devicetree/bindings/mfd/twl-familly.txt
b/Documentation/devicetree/bindings/mfd/twl-familly.txt
new file mode 100644
index 000..ff4cacd
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/twl-familly.txt
@@ -0,0 +1,47 @@
+Texas Instruments TWL family
+
+The TWLs are Integrated Power Management Chips.
+Some version might contain much more analog function like
+USB transceiver or Audio amplifier.
+These chips are connected to an i2c bus.
+
+
+Required properties:
+- compatible : Must be ti,twl4030;
+ For Integrated power-management/audio CODEC device used in OMAP3
+ based boards
+- compatible : Must be ti,twl6030;
+ For Integrated power-management used in OMAP4 based boards
+- interrupts : This i2c device has an IRQ line connected to the main SoC
+- interrupt-controller : Since the twl support several interrupts internally,
+ it is considered as an interrupt controller cascaded to the SoC one.
+- #interrupt-cells = 1;
+- interrupt-parent : The parent interrupt controller.
+
+Optional node:
+- Child nodes contain in the twl. The twl family is made of severals variants
+ that support a different number of features.
+ The children nodes will thus depend of the capabilty of the variant.
+
+
+Example:
+/*
+ * Integrated Power Management Chip
+ * http://www.ti.com/lit/ds/symlink/twl6030.pdf
+ */
+twl@48 {
+compatible = ti,twl6030;
+reg = 0x48;
+interrupts = 39; /* IRQ_SYS_1N cascaded to gic */
+interrupt-controller;
+#interrupt-cells = 1;
+interrupt-parent = gic;
+#address-cells = 1;
+#size-cells = 0;
+
+twl_rtc {
+compatible = ti,twl_rtc;
+interrupts = 11;
+reg = 0;
+};
+};
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index bfbd660..524d9d8 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -34,6 +34,10 @@
#include linux/platform_device.h
#include linux/clk.h
#include linux/err.h
+#include linux/slab.h
+#include linux/of_irq.h
+#include linux/of_platform.h
+#include linux/irqdomain.h
#include linux/regulator/machine.h
@@ -1183,22 +1187,53 @@ twl_probe(struct i2c_client *client, const struct
i2c_device_id *id)
int status;
unsignedi;
struct twl4030_platform_data*pdata = client-dev.platform_data;
+ struct device_node *node = client-dev.of_node;
u8 temp;
int ret = 0;
+ if (node !pdata) {
+ /*
+ * XXX: Temporary fake pdata until the information
+ * is correctly retrieved by every TWL modules from DT.
+ */
+ pdata = kzalloc(sizeof(struct twl4030_platform_data),
+ GFP_KERNEL);
devm_kzalloc() so that it gets cleaned up on remove.
+ if (!pdata) {
+ status = -ENOMEM;
+ goto exit;
+ }
+
+ /*
+ * XXX: For the moment the IRQs for TWL seems to be encoded in
+ * the global OMAP space. That should be cleaned to allow
+ * dynamically adding a new IRQ controller.
+ */
+ if ((id-driver_data) TWL6030_CLASS) {
+ pdata-irq_base = TWL6030_IRQ_BASE;
+ pdata-irq_end = pdata-irq_base + TWL6030_BASE_NR_IRQS;
+ } else {
+ pdata-irq_base = TWL4030_IRQ_BASE;
+ pdata-irq_end = pdata-irq_base + TWL4030_BASE_NR_IRQS;
+ }
+ irq_domain_add_simple(node, pdata-irq_base);
Yes, you'll want a follow-up patch to convert to dynamically allocated
irqs... but I've got to merge the final irq_domain work first. :-)
Acked-by: Grant Likely grant.lik...@secretlab.ca
+ }
+
if (!pdata) {
dev_dbg(client-dev, no platform data?\n);
- return -EINVAL;
+ status = -EINVAL;
+ goto fail_free;
}
if (i2c_check_functionality(client-adapter,
Re: [PATCH v2 07/10] arm/dts: omap4-panda: Add twl6030 and i2c EEPROM
On Fri, Dec 09, 2011 at 03:02:38PM +0100, Benoit Cousson wrote:
Update pandaboard dts file with required clock frequencies
for the i2c client devices existing on pandaboard.
Add the twl6030 node in i2c1 controller.
This is the minimal support needed to boot OMAP4 boards
without any crash.
The support for all the features included in this MFD will be
added later.
Add a generic i2c EEPROM entry.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/boot/dts/omap4-panda.dts | 45
+
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 9755ad5..b66bcd6 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -18,3 +18,48 @@
reg = 0x8000 0x4000; /* 1 GB */
};
};
+
+i2c1 {
+ clock-frequency = 40;
+
+ /*
+ * Integrated Power Management Chip
+ * http://www.ti.com/lit/ds/symlink/twl6030.pdf
+ */
+ twl@48 {
+ compatible = ti,twl6030;
+ reg = 0x48;
+ /* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
+ interrupts = 0 7 4; /* IRQ_SYS_1N cascaded to gic */
+ interrupt-controller;
+ #interrupt-cells = 1;
+ interrupt-parent = gic;
+
+ /* twl is a MFD, so it will contain a bunch of sub-ips */
+ rtc {
+ compatible = ti,twl4030-rtc;
+ interrupts = 11;
+ };
+ };
+};
+
+i2c2 {
+ clock-frequency = 40;
+};
+
+i2c3 {
+ clock-frequency = 10;
+
+ /*
+ * Display monitor features are burnt in their EEPROM as EDID data.
+ * The EEPROM is connected as I2C slave device.
+ */
+ eeprom@50 {
+ compatible = ti,eeprom;
+ reg = 0x50;
+ };
+};
+
+i2c4 {
+ clock-frequency = 40;
+};
--
1.7.0.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 v2 08/10] arm/dts: omap4-sdp: Add twl6030, i2c3 and i2c4 devices
On Fri, Dec 09, 2011 at 03:02:39PM +0100, Benoit Cousson wrote:
Update DTS file with required clock frequencies
for the i2c client devices existing on sdp4430.
Add the twl6030 node inside the i2c1 controller node.
This is the minimal support needed to boot OMAP4 boards
without any crash.
The support for all the features included in this MFD will be
added later.
Add the RTC submodule inside the twl node.
Add tmp105 temperature sensor in i2c3
Add bh1780 Ambient Light Sensor in i2c3
Add hmc5843 3-Axis Digital Compass in i2c4
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/boot/dts/omap4-sdp.dts | 63
+++
1 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 63c6b2b..0ab14cb 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -18,3 +18,66 @@
reg = 0x8000 0x4000; /* 1 GB */
};
};
+
+i2c1 {
+ clock-frequency = 40;
+
+ /*
+ * Integrated Power Management Chip
+ * http://www.ti.com/lit/ds/symlink/twl6030.pdf
+ */
+ twl@48 {
+ compatible = ti,twl6030;
+ reg = 0x48;
+ /* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
+ interrupts = 0 7 4; /* IRQ_SYS_1N cascaded to gic */
+ interrupt-controller;
+ #interrupt-cells = 1;
+ interrupt-parent = gic;
+
+ /* twl is a MFD, so it will contain a bunch of sub-ips */
+ rtc {
+ compatible = ti,twl4030-rtc;
+ interrupts = 11;
+ };
+ };
+};
+
+i2c2 {
+ clock-frequency = 40;
+};
+
+i2c3 {
+ clock-frequency = 40;
+
+ /*
+ * Temperature Sensor
+ * http://www.ti.com/lit/ds/symlink/tmp105.pdf
+ */
+ tmp105@48 {
+ compatible = ti,tmp105;
+ reg = 0x48;
+ };
+
+ /*
+ * Ambient Light Sensor
+ * http://www.rohm.com/products/databook/sensor/pdf/bh1780gli-e.pdf
+ */
+ bh1780@29 {
+ compatible = rohm,bh1780;
+ reg = 0x29;
+ };
+};
+
+i2c4 {
+ clock-frequency = 40;
+
+ /*
+ * 3-Axis Digital Compass
+ * http://www.sparkfun.com/datasheets/Sensors/Magneto/HMC5843.pdf
+ */
+ hmc5843@1e {
+ compatible = honeywell,hmc5843;
+ reg = 0x1e;
+ };
+};
--
1.7.0.4
--
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 1/2] mt_ventoux: very basic support for TeeJet Mt.Ventoux board
On Tue, Dec 27, 2011 at 12:08:31AM +0100, Ilya Yanok wrote:
Very basic support for TeeJet Mt.Ventoux board. Able to boot via
board-generic and ramdisk/initramfs, however most of peripherals are
not supported. Produces tons of twl4030 related errors as this board
doesn't have twl4030 installed.
Signed-off-by: Ilya Yanok ya...@emcraft.com
Comment below, but otherwise:
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/boot/dts/am3517_mt_ventoux.dts | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/am3517_mt_ventoux.dts
diff --git a/arch/arm/boot/dts/am3517_mt_ventoux.dts
b/arch/arm/boot/dts/am3517_mt_ventoux.dts
new file mode 100644
index 000..5eb26d7
--- /dev/null
+++ b/arch/arm/boot/dts/am3517_mt_ventoux.dts
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, EmCraft Systems
+ *
+ * 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.
+ */
+/dts-v1/;
+
+/include/ omap3.dtsi
+
+/ {
+ model = TeeJet Mt.Ventoux;
+ compatible = teejet,mt_ventoux, ti,omap3;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+
+ /* AM35xx doesn't have IVA */
Perhaps the AM35xx should have a separate .dtsi file?
+ soc {
+ iva {
+ status = disabled;
+ };
+ };
+};
--
1.7.6.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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] arm/dts: OMAP: Remove bootargs node from board files
On Tue, Dec 06, 2011 at 05:49:08PM +0100, Benoit Cousson wrote:
Since 3.2, the CONFIG_ARM_ATAG_DTB_COMPAT config allows
an old bootloader to still use ATAG to provide cmdline.
Remove chosen/bootargs from the DTS board files.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/boot/dts/omap3-beagle.dts |9 -
arch/arm/boot/dts/omap4-panda.dts |9 -
arch/arm/boot/dts/omap4-sdp.dts|9 -
3 files changed, 0 insertions(+), 27 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 9486be6..9f72cd4 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -13,15 +13,6 @@
model = TI OMAP3 BeagleBoard;
compatible = ti,omap3-beagle, ti,omap3;
- /*
- * Since the initial device tree board file does not create any
- * devices (MMC, network...), the only way to boot is to provide a
- * ramdisk.
- */
- chosen {
- bootargs = root=/dev/ram0 rw console=ttyO2,115200n8
initrd=0x8160,20M ramdisk_size=20480 no_console_suspend debug
earlyprintk;
- };
-
memory {
device_type = memory;
reg = 0x8000 0x2000; /* 512 MB */
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index c702657..9755ad5 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -13,15 +13,6 @@
model = TI OMAP4 PandaBoard;
compatible = ti,omap4-panda, ti,omap4430, ti,omap4;
- /*
- * Since the initial device tree board file does not create any
- * devices (MMC, network...), the only way to boot is to provide a
- * ramdisk.
- */
- chosen {
- bootargs = root=/dev/ram0 rw console=ttyO2,115200n8
initrd=0x8160,20M ramdisk_size=20480 no_console_suspend debug;
- };
-
memory {
device_type = memory;
reg = 0x8000 0x4000; /* 1 GB */
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 066e28c..63c6b2b 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -13,15 +13,6 @@
model = TI OMAP4 SDP board;
compatible = ti,omap4-sdp, ti,omap4430, ti,omap4;
- /*
- * Since the initial device tree board file does not create any
- * devices (MMC, network...), the only way to boot is to provide a
- * ramdisk.
- */
- chosen {
- bootargs = root=/dev/ram0 rw console=ttyO2,115200n8
initrd=0x8160,20M ramdisk_size=20480 no_console_suspend debug;
- };
-
memory {
device_type = memory;
reg = 0x8000 0x4000; /* 1 GB */
--
1.7.0.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 1/3] ARM: OMAP2+: kconfig: Enable devicetree by default for OMAP2+ systems
On Tue, Dec 6, 2011 at 9:49 AM, Benoit Cousson b-cous...@ti.com wrote: devicetree will become the mandatory boot method for OMAP2+. In order to avoid cluttering the OMAP code with #ifdef CONFIG_OF, select USE_OF by default for every OMAP2+ systems. Select as well the APPENDED_DTB and ATAG_DTB_COMPAT to allow legacy boot loader to keep working properly. Enable PROC_DEVICETREE as well. Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Acked-by: Grant Likely grant.lik...@secretlab.ca --- arch/arm/mach-omap2/Kconfig | 1 - arch/arm/plat-omap/Kconfig | 4 2 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index e1293aa..056a812 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -109,7 +109,6 @@ comment OMAP Board Type config MACH_OMAP_GENERIC bool Generic OMAP2+ board depends on ARCH_OMAP2PLUS - select USE_OF default y help Support for generic TI OMAP2+ boards using Flattened Device Tree. diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index aa59f42..74f41dc 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -24,6 +24,10 @@ config ARCH_OMAP2PLUS select CLKDEV_LOOKUP select GENERIC_IRQ_CHIP select OMAP_DM_TIMER + select USE_OF + select ARM_APPENDED_DTB + select ARM_ATAG_DTB_COMPAT + select PROC_DEVICETREE help Systems based on OMAP2, OMAP3 or OMAP4 -- 1.7.0.4 ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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 v2 02/10] i2c: OMAP: Add DT support for i2c controller
Cousson, Benoit b-cous...@ti.com writes: Hi Kevin, On 12/14/2011 2:06 AM, Kevin Hilman wrote: Benoit Coussonb-cous...@ti.com writes: Add initial DT support to retrieve the frequency using a DT attribute instead of the pdata pointer if of_node exist. Add documentation for omap i2c controller binding. Based on original patches from Manju and Grant. Signed-off-by: Benoit Coussonb-cous...@ti.com Cc: Ben Dooksben-li...@fluff.org This seems indepenent from the rest of the series, and I can queue up for merge via the I2C tree. Benoit, please confirm that we shouldn't have any problems if this patch goes independently. Grant/Rob, with your ack on the bindings, I can queue this up for the I2C maintainers along with some other OMAP I2C changes for v3.3. I removed the nasty bindings and got the Reviewed-by: from Rob for the v4 [1]. Could you take it in your branch? I've just tried merging your for_3.3/i2c/misc on top of my for_3.3/3_omap_dt_i2c_twl branch and tested it successfully on OMAP4 DT boot. Yes, I'll add v4 to my i2c/misc branch and add Grant's ack and queue. Note that Ben Dooks has not responded to any of my queries or pull requests, either for v3.2 fixes or for the v3.3 merge window, so unfortunately it doesn't look like this will make it for v3.3 unless Ben starts responding. :( Kevin -- 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 v2 02/10] i2c: OMAP: Add DT support for i2c controller
On Wed, Jan 4, 2012 at 2:28 PM, Kevin Hilman khil...@ti.com wrote: Cousson, Benoit b-cous...@ti.com writes: Hi Kevin, On 12/14/2011 2:06 AM, Kevin Hilman wrote: Benoit Coussonb-cous...@ti.com writes: Add initial DT support to retrieve the frequency using a DT attribute instead of the pdata pointer if of_node exist. Add documentation for omap i2c controller binding. Based on original patches from Manju and Grant. Signed-off-by: Benoit Coussonb-cous...@ti.com Cc: Ben Dooksben-li...@fluff.org This seems indepenent from the rest of the series, and I can queue up for merge via the I2C tree. Benoit, please confirm that we shouldn't have any problems if this patch goes independently. Grant/Rob, with your ack on the bindings, I can queue this up for the I2C maintainers along with some other OMAP I2C changes for v3.3. I removed the nasty bindings and got the Reviewed-by: from Rob for the v4 [1]. Could you take it in your branch? I've just tried merging your for_3.3/i2c/misc on top of my for_3.3/3_omap_dt_i2c_twl branch and tested it successfully on OMAP4 DT boot. Yes, I'll add v4 to my i2c/misc branch and add Grant's ack and queue. Note that Ben Dooks has not responded to any of my queries or pull requests, either for v3.2 fixes or for the v3.3 merge window, so unfortunately it doesn't look like this will make it for v3.3 unless Ben starts responding. :( Kevin Get it into linux-next anyway. If Ben doesn't respond, then you can ask Linus to pull directly near the end of the merge window. I don't see any benefit in making this sit out for another cycle. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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] OMAP/I2C - Fix timeout problem during suspend.
+Felipe NeilBrown ne...@suse.de writes: On a board with OMAP3 processor and TWL4030 Power management, we need to talk to the TWL4030 during late suspend but cannot because the I2C interrupt is disabled (as late suspend disables interrupt). I'm not convinced this is the right solution to this problem. IMO, this problem is caused by the MUSB driver being broken for suspend/resume. I've reported this problem (and an RFC/PATCH) already[1], but I don't think the driver has been fixed. Can you try my patch[1] to see if it fixes your problem as well? Kevin [1] http://marc.info/?l=linux-omapm=132252827112721w=2 -- 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
How do I get slimbus hwmod information?
Currently omap_hwmod_44xx_data.c has slimbus1/slimbus2 included in the list of excluded IPs. Is it possible to get a version of omap_hwmod_44xx_data.c generated with slimbus1/2 included? I want this as I am currently working on a driver for the slimbus modules, based on the SLIMbus RFC patch posted last year. I am concerned that I do not understand how the pieces for such a driver should be put together: should such a driver be built from the ground up with hwmod interfaces, or should they be added in as the driver stabilizes? Thanks. -m -- 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 v4 3/6] clk: introduce the common clock framework
On Wed, Jan 4, 2012 at 6:32 AM, Rob Herring robherri...@gmail.com wrote:
On 01/03/2012 08:15 PM, Richard Zhao wrote:
On Fri, Dec 16, 2011 at 04:45:48PM -0800, Turquette, Mike wrote:
On Wed, Dec 14, 2011 at 5:18 AM, Thomas Gleixner t...@linutronix.de wrote:
On Tue, 13 Dec 2011, Mike Turquette wrote:
snip
+/**
+ * clk_init - initialize the data structures in a struct clk
+ * @dev: device initializing this clk, placeholder for now
+ * @clk: clk being initialized
+ *
+ * Initializes the lists in struct clk, queries the hardware for the
+ * parent and rate and sets them both. Adds the clk to the sysfs tree
+ * topology.
+ *
+ * Caller must populate clk-name and clk-flags before calling
I'm not too happy about this construct. That leaves struct clk and its
members exposed to the world instead of making it a real opaque
cookie. I know from my own painful experience, that this will lead to
random fiddling in that data structure in drivers and arch code just
because the core code has a shortcoming.
Why can't we make struct clk a real cookie and confine the data
structure to the core code ?
That would change the init call to something like:
struct clk *clk_init(struct device *dev, const struct clk_hw *hw,
struct clk *parent)
And have:
struct clk_hw {
struct clk_hw_ops *ops;
const char *name;
unsigned long flags;
};
Implementers can do:
struct my_clk_hw {
struct clk_hw hw;
mydata;
};
And then change the clk ops callbacks to take struct clk_hw * as an
argument.
We have to define static clocks before we adopt DT binding.
If clk is opaque and allocate memory in clk core, it'll make hard
to define static clocks. And register/init will pass a long parameter
list.
DT is not a prerequisite for having dynamically created clocks. You can
make clock init dynamic without DT.
Agreed.
What data goes in struct clk vs. struct clk_hw could change over time.
So perhaps we can start with some data in clk_hw and plan to move it to
struct clk later. Even if almost everything ends up in clk_hw initially,
at least the structure is in place to have common, core-only data
separate from platform data.
What is the point of this?
The original clk_hw was defined simply as:
struct clk_hw {
struct clk *clk;
};
It's only purpose in life was as a handle for navigation between the
opaque struct clk and the hardware-specific struct my_clk_hw. struct
clk_hw is defined in clk.h and everyone can see it. If we're suddenly
OK putting clk data in this structure then why bother with an opaque
struct clk at all?
What is the actual data you need to be static and accessible to the
platform code? A ptr to parent clk is the main thing I've seen for
static initialization. So make the parent ptr be struct clk_hw* and
allow the platforms to access.
To answer your question on what data we're trying to expose: platform
code commonly needs the parent pointer and the clk rate (and by
extension, the rate of the parent). For debug/error prints it is also
nice to have the clk name. Generic clk flags are also conceivably
something that platform code might want.
I'd like to spin the question around: if we're OK exposing some stuff
(in your example above, the parent pointer), then what clk data are
you trying to hide?
Regards,
Mike
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 0/7] ARM: OMAP: remove IP checks from SoC family detection
Currently, our SoC detection is based on SoC family detection (using die ID) and the presence of specific IP blocks (or feature.) This series begins the separation of the SoC family detection and specific IP detection. Applies on top of Tony's current master branch and so far, it has only been compile tested using omap2plus_defconfig. Kevin Kevin Hilman (7): ARM: OMAP: remove unused cpu_is macros that depend on specific IP checks ARM: OMAP3: clock data: replace 3503/3517 flag with AM35x flag for UART4 ARM: OMAP3: clock data: treat all AM35x devices the same ARM: OMAP: AM35x: remove redunant cpu_is checks for AM3505 ARM: OMAP: clock: remove unused CK_3505 flag ARM: OMAP: remove unused cpu_is_omap3505() ARM: OMAP: remove unused cpu_is_omap3530() arch/arm/mach-omap2/clock3xxx_data.c | 16 +- arch/arm/mach-omap2/hsmmc.c |8 +++--- arch/arm/mach-omap2/usb-musb.c|2 +- arch/arm/mach-omap2/voltagedomains3xxx_data.c |2 +- arch/arm/plat-omap/include/plat/clkdev_omap.h |3 +- arch/arm/plat-omap/include/plat/cpu.h | 26 + 6 files changed, 10 insertions(+), 47 deletions(-) -- 1.7.8.2 -- 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
[RFC/PATCH 1/7] ARM: OMAP: remove unused cpu_is macros that depend on specific IP checks
The cpu_is_omap35* macros for 3503, 3515, 3525) are unused. Remove them in order to start removing IP detection from SoC family detection. Signed-off-by: Kevin Hilman khil...@ti.com --- arch/arm/plat-omap/include/plat/cpu.h | 15 --- 1 files changed, 0 insertions(+), 15 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h index 428ccb1..bcad3dc 100644 --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -292,9 +292,6 @@ IS_OMAP_TYPE(3517, 0x3517) #define cpu_is_omap2422() 0 #define cpu_is_omap2423() 0 #define cpu_is_omap2430() 0 -#define cpu_is_omap3503() 0 -#define cpu_is_omap3515() 0 -#define cpu_is_omap3525() 0 #define cpu_is_omap3530() 0 #define cpu_is_omap3505() 0 #define cpu_is_omap3517() 0 @@ -350,9 +347,6 @@ IS_OMAP_TYPE(3517, 0x3517) #if defined(CONFIG_ARCH_OMAP3) # undef cpu_is_omap3430 -# undef cpu_is_omap3503 -# undef cpu_is_omap3515 -# undef cpu_is_omap3525 # undef cpu_is_omap3530 # undef cpu_is_omap3505 # undef cpu_is_omap3517 @@ -362,15 +356,6 @@ IS_OMAP_TYPE(3517, 0x3517) # undef cpu_is_am33xx # undef cpu_is_am335x # define cpu_is_omap3430() is_omap3430() -# define cpu_is_omap3503() (cpu_is_omap3430()\ - (!omap3_has_iva())\ - (!omap3_has_sgx())) -# define cpu_is_omap3515() (cpu_is_omap3430()\ - (!omap3_has_iva())\ - (omap3_has_sgx())) -# define cpu_is_omap3525() (cpu_is_omap3430()\ - (!omap3_has_sgx())\ - (omap3_has_iva())) # define cpu_is_omap3530() (cpu_is_omap3430()) # define cpu_is_omap3517() is_omap3517() # define cpu_is_omap3505() (cpu_is_omap3517()\ -- 1.7.8.2 -- 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
[RFC/PATCH 3/7] ARM: OMAP3: clock data: treat all AM35x devices the same
The init for 3505/3517 specific clocks depends on the ordering of
cpu_is checks, is error prone and confusing (there are 2 separate
checks for cpu_is_omap3505()).
Remove the 3505-specific checking since CK_3505 flag is not used, and
treat all AM35x clocks the same.
This means that the SGX clock (the only AM35x clkdev not currently
flagged for 3505) will now be registered on 3505, but that is
harmless. That can be cleaned up when the clkdev nodes are removed in
favor of them being registered by hwmod.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c | 14 +-
1 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index e09e506..26fb4d9 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3505,21 +3505,9 @@ int __init omap3xxx_clk_init(void)
struct omap_clk *c;
u32 cpu_clkflg = 0;
- /*
-* 3505 must be tested before 3517, since 3517 returns true
-* for both AM3517 chips and AM3517 family chips, which
-* includes 3505. Unfortunately there's no obvious family
-* test for 3517/3505 :-(
-*/
- if (cpu_is_omap3505()) {
- cpu_mask = RATE_IN_34XX;
- cpu_clkflg = CK_3505;
- } else if (cpu_is_omap3517()) {
+ if (cpu_is_omap3517()) {
cpu_mask = RATE_IN_34XX;
cpu_clkflg = CK_3517;
- } else if (cpu_is_omap3505()) {
- cpu_mask = RATE_IN_34XX;
- cpu_clkflg = CK_3505;
} else if (cpu_is_omap3630()) {
cpu_mask = (RATE_IN_34XX | RATE_IN_36XX);
cpu_clkflg = CK_36XX;
--
1.7.8.2
--
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
[RFC/PATCH 4/7] ARM: OMAP: AM35x: remove redunant cpu_is checks for AM3505
There are several checks for AM35x devices done using
if (cpu_is_omap3517() || cpu_is_omap3505())
However, since the 3505 is just a 3517 without an SGX, the 3505 check
is redundant because cpu_is_omap3517() will always be true whenever
cpu_is_omap3505() is true. From plat/cpu.h:
#define cpu_is_omap3505() (cpu_is_omap3517() !omap3_has_sgx())
Therefore, remove the redunant 3505 checks. This helps move towards
removal of SoC detection that depends on specific IP detection.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/hsmmc.c |8
arch/arm/mach-omap2/usb-musb.c|2 +-
arch/arm/mach-omap2/voltagedomains3xxx_data.c |2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index bd844af..c49a91d 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -353,7 +353,7 @@ static int __init omap_hsmmc_pdata_init(struct
omap2_hsmmc_info *c,
*
* temporary HACK: ocr_mask instead of fixed supply
*/
- if (cpu_is_omap3505() || cpu_is_omap3517())
+ if (cpu_is_omap3517())
mmc-slots[0].ocr_mask = MMC_VDD_165_195 |
MMC_VDD_26_27 |
MMC_VDD_27_28 |
@@ -363,7 +363,7 @@ static int __init omap_hsmmc_pdata_init(struct
omap2_hsmmc_info *c,
else
mmc-slots[0].ocr_mask = c-ocr_mask;
- if (!cpu_is_omap3517() !cpu_is_omap3505())
+ if (!cpu_is_omap3517())
mmc-slots[0].features |= HSMMC_HAS_PBIAS;
if (cpu_is_omap44xx() (omap_rev() OMAP4430_REV_ES1_0))
@@ -386,7 +386,7 @@ static int __init omap_hsmmc_pdata_init(struct
omap2_hsmmc_info *c,
}
}
- if (cpu_is_omap3517() || cpu_is_omap3505())
+ if (cpu_is_omap3517())
mmc-slots[0].set_power = nop_mmc_set_power;
/* OMAP3630 HSMMC1 supports only 4-bit */
@@ -398,7 +398,7 @@ static int __init omap_hsmmc_pdata_init(struct
omap2_hsmmc_info *c,
}
break;
case 2:
- if (cpu_is_omap3517() || cpu_is_omap3505())
+ if (cpu_is_omap3517())
mmc-slots[0].set_power = am35x_hsmmc2_set_power;
if (c-ext_clock)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 8d5ed77..bf33b4d 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -90,7 +90,7 @@ void __init usb_musb_init(struct omap_musb_board_data
*musb_board_data)
musb_plat.mode = board_data-mode;
musb_plat.extvbus = board_data-extvbus;
- if (cpu_is_omap3517() || cpu_is_omap3505()) {
+ if (cpu_is_omap3517()) {
oh_name = am35x_otg_hs;
name = musb-am35x;
} else if (cpu_is_ti81xx()) {
diff --git a/arch/arm/mach-omap2/voltagedomains3xxx_data.c
b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
index c005e2f..bdb82f1 100644
--- a/arch/arm/mach-omap2/voltagedomains3xxx_data.c
+++ b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
@@ -116,7 +116,7 @@ void __init omap3xxx_voltagedomains_init(void)
omap3_voltdm_core.volt_data = omap34xx_vddcore_volt_data;
}
- if (cpu_is_omap3517() || cpu_is_omap3505())
+ if (cpu_is_omap3517())
voltdms = voltagedomains_am35xx;
else
voltdms = voltagedomains_omap3;
--
1.7.8.2
--
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
[RFC/PATCH 5/7] ARM: OMAP: clock: remove unused CK_3505 flag
This flag is no longer used since clock init all AM35x devices
is now the same.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/include/plat/clkdev_omap.h |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/clkdev_omap.h
b/arch/arm/plat-omap/include/plat/clkdev_omap.h
index b299b8d..45afa4d 100644
--- a/arch/arm/plat-omap/include/plat/clkdev_omap.h
+++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h
@@ -34,7 +34,6 @@ struct omap_clk {
#define CK_243X(1 5)/* 243x, 253x */
#define CK_3430ES1 (1 6)/* 34xxES1 only */
#define CK_3430ES2PLUS (1 7)/* 34xxES2, ES3, non-Sitara 35xx only */
-#define CK_3505(1 8)
#define CK_3517(1 9)
#define CK_36XX(1 10) /* 36xx/37xx-specific clocks */
#define CK_443X(1 11)
@@ -44,7 +43,7 @@ struct omap_clk {
#define CK_34XX(CK_3430ES1 | CK_3430ES2PLUS)
-#define CK_AM35XX (CK_3505 | CK_3517) /* all Sitara AM35xx */
+#define CK_AM35XX CK_3517 /* all Sitara AM35xx */
#define CK_3XXX(CK_34XX | CK_AM35XX | CK_36XX)
--
1.7.8.2
--
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
[RFC/PATCH 7/7] ARM: OMAP: remove unused cpu_is_omap3530()
The cpu_is_omap3530() macro is unused, remove. Signed-off-by: Kevin Hilman khil...@ti.com --- arch/arm/plat-omap/include/plat/cpu.h |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h index 8d858c2..2c8e5ab 100644 --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -290,7 +290,6 @@ IS_OMAP_TYPE(3517, 0x3517) #define cpu_is_omap2422() 0 #define cpu_is_omap2423() 0 #define cpu_is_omap2430() 0 -#define cpu_is_omap3530() 0 #define cpu_is_omap3517() 0 #define cpu_is_omap3430() 0 #define cpu_is_omap4430() 0 @@ -344,7 +343,6 @@ IS_OMAP_TYPE(3517, 0x3517) #if defined(CONFIG_ARCH_OMAP3) # undef cpu_is_omap3430 -# undef cpu_is_omap3530 # undef cpu_is_omap3517 # undef cpu_is_ti81xx # undef cpu_is_ti816x @@ -352,7 +350,6 @@ IS_OMAP_TYPE(3517, 0x3517) # undef cpu_is_am33xx # undef cpu_is_am335x # define cpu_is_omap3430() is_omap3430() -# define cpu_is_omap3530() (cpu_is_omap3430()) # define cpu_is_omap3517() is_omap3517() # undef cpu_is_omap3630 # define cpu_is_omap3630() is_omap363x() -- 1.7.8.2 -- 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
[RFC/PATCH 6/7] ARM: OMAP: remove unused cpu_is_omap3505()
The 3505 check is now unused and can be removed. There are no longer any cpu_is_* checks that depend on specific IP detection. Signed-off-by: Kevin Hilman khil...@ti.com --- arch/arm/plat-omap/include/plat/cpu.h |8 +--- 1 files changed, 1 insertions(+), 7 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h index bcad3dc..8d858c2 100644 --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -251,8 +251,7 @@ IS_AM_SUBCLASS(335x, 0x335) * cpu_is_omap2430(): True for OMAP2430 * cpu_is_omap3430(): True for OMAP3430 * cpu_is_omap4430(): True for OMAP4430 - * cpu_is_omap3505(): True for OMAP3505 - * cpu_is_omap3517(): True for OMAP3517 + * cpu_is_omap3517(): True for AM35x: OMAP3517, OMAP3505 */ #define GET_OMAP_TYPE ((omap_rev() 16) 0x) @@ -276,7 +275,6 @@ IS_OMAP_TYPE(2422, 0x2422) IS_OMAP_TYPE(2423, 0x2423) IS_OMAP_TYPE(2430, 0x2430) IS_OMAP_TYPE(3430, 0x3430) -IS_OMAP_TYPE(3505, 0x3517) IS_OMAP_TYPE(3517, 0x3517) #define cpu_is_omap310() 0 @@ -293,7 +291,6 @@ IS_OMAP_TYPE(3517, 0x3517) #define cpu_is_omap2423() 0 #define cpu_is_omap2430() 0 #define cpu_is_omap3530() 0 -#define cpu_is_omap3505() 0 #define cpu_is_omap3517() 0 #define cpu_is_omap3430() 0 #define cpu_is_omap4430() 0 @@ -348,7 +345,6 @@ IS_OMAP_TYPE(3517, 0x3517) #if defined(CONFIG_ARCH_OMAP3) # undef cpu_is_omap3430 # undef cpu_is_omap3530 -# undef cpu_is_omap3505 # undef cpu_is_omap3517 # undef cpu_is_ti81xx # undef cpu_is_ti816x @@ -358,8 +354,6 @@ IS_OMAP_TYPE(3517, 0x3517) # define cpu_is_omap3430() is_omap3430() # define cpu_is_omap3530() (cpu_is_omap3430()) # define cpu_is_omap3517() is_omap3517() -# define cpu_is_omap3505() (cpu_is_omap3517()\ - !omap3_has_sgx()) # undef cpu_is_omap3630 # define cpu_is_omap3630() is_omap363x() # define cpu_is_ti81xx() is_ti81xx() -- 1.7.8.2 -- 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
[RFC/PATCH 2/7] ARM: OMAP3: clock data: replace 3503/3517 flag with AM35x flag for UART4
The AM35x UART4 is common to all AM35x devices, so use CK_AM35XX instead
of (CK_3505 | CK_3517), which is equivalent.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index d75e5f6..e09e506 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3411,7 +3411,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, per_48m_fck, per_48m_fck, CK_3XXX),
CLK(NULL, uart3_fck,uart3_fck, CK_3XXX),
CLK(NULL, uart4_fck,uart4_fck, CK_36XX),
- CLK(NULL, uart4_fck,uart4_fck_am35xx, CK_3505 | CK_3517),
+ CLK(NULL, uart4_fck,uart4_fck_am35xx, CK_AM35XX),
CLK(NULL, gpt2_fck, gpt2_fck, CK_3XXX),
CLK(NULL, gpt3_fck, gpt3_fck, CK_3XXX),
CLK(NULL, gpt4_fck, gpt4_fck, CK_3XXX),
--
1.7.8.2
--
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 v4 3/6] clk: introduce the common clock framework
On 01/04/2012 07:01 PM, Turquette, Mike wrote:
On Wed, Jan 4, 2012 at 6:32 AM, Rob Herring robherri...@gmail.com wrote:
On 01/03/2012 08:15 PM, Richard Zhao wrote:
On Fri, Dec 16, 2011 at 04:45:48PM -0800, Turquette, Mike wrote:
On Wed, Dec 14, 2011 at 5:18 AM, Thomas Gleixner t...@linutronix.de
wrote:
On Tue, 13 Dec 2011, Mike Turquette wrote:
snip
+/**
+ * clk_init - initialize the data structures in a struct clk
+ * @dev: device initializing this clk, placeholder for now
+ * @clk: clk being initialized
+ *
+ * Initializes the lists in struct clk, queries the hardware for the
+ * parent and rate and sets them both. Adds the clk to the sysfs tree
+ * topology.
+ *
+ * Caller must populate clk-name and clk-flags before calling
I'm not too happy about this construct. That leaves struct clk and its
members exposed to the world instead of making it a real opaque
cookie. I know from my own painful experience, that this will lead to
random fiddling in that data structure in drivers and arch code just
because the core code has a shortcoming.
Why can't we make struct clk a real cookie and confine the data
structure to the core code ?
That would change the init call to something like:
struct clk *clk_init(struct device *dev, const struct clk_hw *hw,
struct clk *parent)
And have:
struct clk_hw {
struct clk_hw_ops *ops;
const char*name;
unsigned long flags;
};
Implementers can do:
struct my_clk_hw {
struct clk_hwhw;
mydata;
};
And then change the clk ops callbacks to take struct clk_hw * as an
argument.
We have to define static clocks before we adopt DT binding.
If clk is opaque and allocate memory in clk core, it'll make hard
to define static clocks. And register/init will pass a long parameter
list.
DT is not a prerequisite for having dynamically created clocks. You can
make clock init dynamic without DT.
Agreed.
What data goes in struct clk vs. struct clk_hw could change over time.
So perhaps we can start with some data in clk_hw and plan to move it to
struct clk later. Even if almost everything ends up in clk_hw initially,
at least the structure is in place to have common, core-only data
separate from platform data.
What is the point of this?
To have a way forward. It would be nice to have a clk infrastructure
before I retire...
The original clk_hw was defined simply as:
struct clk_hw {
struct clk *clk;
};
It's only purpose in life was as a handle for navigation between the
opaque struct clk and the hardware-specific struct my_clk_hw. struct
clk_hw is defined in clk.h and everyone can see it. If we're suddenly
OK putting clk data in this structure then why bother with an opaque
struct clk at all?
What is the actual data you need to be static and accessible to the
platform code? A ptr to parent clk is the main thing I've seen for
static initialization. So make the parent ptr be struct clk_hw* and
allow the platforms to access.
To answer your question on what data we're trying to expose: platform
code commonly needs the parent pointer and the clk rate (and by
extension, the rate of the parent). For debug/error prints it is also
nice to have the clk name. Generic clk flags are also conceivably
something that platform code might want.
I agree with the need to have the parent and flags from a static init
perspective. There's not really a good reason the others can't be
accessed thru accessors though.
I'd like to spin the question around: if we're OK exposing some stuff
(in your example above, the parent pointer), then what clk data are
you trying to hide?
Well, everything from drivers which the current clk implementations do
hide. Catching abuse in with drivers coming in from all different trees
and lists will be impossible.
For platform code it is more fuzzy. I don't think platform code should
be allowed to muck with prepare/enable counts for example.
Rob
Regards,
Mike
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
Re: [PATCH v4 3/6] clk: introduce the common clock framework
On Wed, Jan 4, 2012 at 6:11 PM, Rob Herring robherri...@gmail.com wrote:
On 01/04/2012 07:01 PM, Turquette, Mike wrote:
On Wed, Jan 4, 2012 at 6:32 AM, Rob Herring robherri...@gmail.com wrote:
On 01/03/2012 08:15 PM, Richard Zhao wrote:
On Fri, Dec 16, 2011 at 04:45:48PM -0800, Turquette, Mike wrote:
On Wed, Dec 14, 2011 at 5:18 AM, Thomas Gleixner t...@linutronix.de
wrote:
On Tue, 13 Dec 2011, Mike Turquette wrote:
snip
+/**
+ * clk_init - initialize the data structures in a struct clk
+ * @dev: device initializing this clk, placeholder for now
+ * @clk: clk being initialized
+ *
+ * Initializes the lists in struct clk, queries the hardware for the
+ * parent and rate and sets them both. Adds the clk to the sysfs tree
+ * topology.
+ *
+ * Caller must populate clk-name and clk-flags before calling
I'm not too happy about this construct. That leaves struct clk and its
members exposed to the world instead of making it a real opaque
cookie. I know from my own painful experience, that this will lead to
random fiddling in that data structure in drivers and arch code just
because the core code has a shortcoming.
Why can't we make struct clk a real cookie and confine the data
structure to the core code ?
That would change the init call to something like:
struct clk *clk_init(struct device *dev, const struct clk_hw *hw,
struct clk *parent)
And have:
struct clk_hw {
struct clk_hw_ops *ops;
const char *name;
unsigned long flags;
};
Implementers can do:
struct my_clk_hw {
struct clk_hw hw;
mydata;
};
And then change the clk ops callbacks to take struct clk_hw * as an
argument.
We have to define static clocks before we adopt DT binding.
If clk is opaque and allocate memory in clk core, it'll make hard
to define static clocks. And register/init will pass a long parameter
list.
DT is not a prerequisite for having dynamically created clocks. You can
make clock init dynamic without DT.
Agreed.
What data goes in struct clk vs. struct clk_hw could change over time.
So perhaps we can start with some data in clk_hw and plan to move it to
struct clk later. Even if almost everything ends up in clk_hw initially,
at least the structure is in place to have common, core-only data
separate from platform data.
What is the point of this?
To have a way forward. It would be nice to have a clk infrastructure
before I retire...
Haha, agreed.
The original clk_hw was defined simply as:
struct clk_hw {
struct clk *clk;
};
It's only purpose in life was as a handle for navigation between the
opaque struct clk and the hardware-specific struct my_clk_hw. struct
clk_hw is defined in clk.h and everyone can see it. If we're suddenly
OK putting clk data in this structure then why bother with an opaque
struct clk at all?
What is the actual data you need to be static and accessible to the
platform code? A ptr to parent clk is the main thing I've seen for
static initialization. So make the parent ptr be struct clk_hw* and
allow the platforms to access.
To answer your question on what data we're trying to expose: platform
code commonly needs the parent pointer and the clk rate (and by
extension, the rate of the parent). For debug/error prints it is also
nice to have the clk name. Generic clk flags are also conceivably
something that platform code might want.
I agree with the need to have the parent and flags from a static init
perspective. There's not really a good reason the others can't be
accessed thru accessors though.
I'd like to spin the question around: if we're OK exposing some stuff
(in your example above, the parent pointer), then what clk data are
you trying to hide?
Well, everything from drivers which the current clk implementations do
hide. Catching abuse in with drivers coming in from all different trees
and lists will be impossible.
For platform code it is more fuzzy. I don't think platform code should
be allowed to muck with prepare/enable counts for example.
So there is a clear dichotomy: drivers shouldn't be exposed to any of
it and platform code should be exposed to some of it.
How about a drivers/clk/clk-private.h which will define struct clk and
must only be included by clk drivers in drivers/clk/*?
This establishes a bright line between those things which are allowed
to know the details of struct clk and those that are not: namely that
clk drivers in drivers/clk/ may use '#include clk-private.h'.
Obviously struct clk is opaque to the rest of the kernel (in the same
way it has been prior to the common clk patches) and there is no need
for struct clk_hw anymore. Also helper functions are no longer needed
for clock driver code, which I think *is* a manageable set of code to
review. Also clk drivers must live in drivers/clk/ for this to work
(without a big ugly path in someone's #include directive somewhere).
Thoughts?
Regards,
Mike
Rob
Re: [PATCH] OMAP/I2C - Fix timeout problem during suspend.
On Wed, 04 Jan 2012 14:19:48 -0800 Kevin Hilman khil...@ti.com wrote: +Felipe NeilBrown ne...@suse.de writes: On a board with OMAP3 processor and TWL4030 Power management, we need to talk to the TWL4030 during late suspend but cannot because the I2C interrupt is disabled (as late suspend disables interrupt). I'm not convinced this is the right solution to this problem. IMO, this problem is caused by the MUSB driver being broken for suspend/resume. I've reported this problem (and an RFC/PATCH) already[1], but I don't think the driver has been fixed. Can you try my patch[1] to see if it fixes your problem as well? Kevin [1] http://marc.info/?l=linux-omapm=132252827112721w=2 Yes... and no. I reverted my patch to confirm that the timeout messages come back which they did. I then applied your patch and the suspend was nice and smooth again with no timeouts. So that is good. However immediately after I wake it up I get: [ 109.193054] Powerdomain (core_pwrdm) didn't enter target state 1 [ 109.199310] Could not enter target state in pm_suspend whereas with my patch in place I get: [ 123.666046] Successfully put all powerdomains to target state Following this hint I looked into current draw. With my patch I get a suspend-time current draw of 60-80mA (which is still too high..). With your patch in place I get 120mA or more (about 4 tests, definitely at least 30mA difference). I measure this by checking the 'charge_now' reported by the bq27000 in the battery. This is without the usb cable plugged in. With usb plugged in your version has the positive effect that charging continues while in suspend while with mine it doesn't. But I don't think that justifies the extra current drain :-) So I'll be sticking with my patch for now. My next problem I need to resolve relates to i2c and the charger as well. When entering suspend the various twl4030 interrupts are disabled by not masked. This means they can still fire but are not handled until after suspend. This effectively blocks other interrupts from the twl4030 that I actually want (like the RTC alarm). I think there are at least 3 or 4 bugs in here making it rather hard to sort out. However I think I will want to mask interrupt sources when they are disabled. To mask the interrupts I need to talk to the twl4030 over i2c. And this means that I need the i2c interrupt to still be working. So I feel that my patch might be more generally useful. However I confess that there is a lot here that I don't completely understand, and I might have a different opinion tomorrow. Thanks, NeilBrown signature.asc Description: PGP signature
Re: [PATCH v2 3/3] OMAPDSS: HDMI: Sysfs support to configure quantization
On Wed, 2012-01-04 at 17:23 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
Add sysfs support for the uset space to configure limited range or full range
quantization for HDMI.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/dss.h |2 +
drivers/video/omap2/dss/dss_features.c |1 +
drivers/video/omap2/dss/hdmi.c | 28 +
drivers/video/omap2/dss/hdmi_panel.c | 35
+++-
drivers/video/omap2/dss/ti_hdmi.h |2 +
5 files changed, 67 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 6308fc5..cf1f0f9 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -498,6 +498,8 @@ int omapdss_hdmi_display_check_timing(struct
omap_dss_device *dssdev,
struct omap_video_timings *timings);
int omapdss_hdmi_read_edid(u8 *buf, int len);
bool omapdss_hdmi_detect(void);
+int omapdss_hdmi_get_range(void);
+int omapdss_hdmi_set_range(int range);
int hdmi_panel_init(void);
void hdmi_panel_exit(void);
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index b402699..c7e71b9 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -465,6 +465,7 @@ static const struct ti_hdmi_ip_ops omap4_hdmi_functions =
{
.dump_core = ti_hdmi_4xxx_core_dump,
.dump_pll = ti_hdmi_4xxx_pll_dump,
.dump_phy = ti_hdmi_4xxx_phy_dump,
+ .configure_range= ti_hdmi_4xxx_configure_range,
};
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 4bb7678..ae7918e 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -378,6 +378,34 @@ static void hdmi_power_off(struct omap_dss_device
*dssdev)
hdmi_runtime_put();
}
+int omapdss_hdmi_set_range(int range)
Range is an enum, not an int.
+{
+ int r = 0;
+ enum hdmi_range old_range;
+
+ old_range = hdmi.ip_data.range;
+ hdmi.ip_data.range = range;
+
+ /* HDMI 1.3 section 6.6 VGA (640x480) format requires Full Range */
+ if ((range == 0)
Range is an enum, not an int.
+ ((hdmi.ip_data.cfg.cm.code == 4
+ hdmi.ip_data.cfg.cm.mode == HDMI_DVI) ||
+ (hdmi.ip_data.cfg.cm.code == 1
+ hdmi.ip_data.cfg.cm.mode == HDMI_HDMI)))
+ return -EINVAL;
+
+ r = hdmi.ip_data.ops-configure_range(hdmi.ip_data);
+ if (r)
+ hdmi.ip_data.range = old_range;
+
+ return r;
+}
+
+int omapdss_hdmi_get_range(void)
Range is an enum, not an int... I won't comment on any more of these
cases, please check all uses of range.
+{
+ return hdmi.ip_data.range;
+}
+
int omapdss_hdmi_display_check_timing(struct omap_dss_device *dssdev,
struct omap_video_timings *timings)
{
diff --git a/drivers/video/omap2/dss/hdmi_panel.c
b/drivers/video/omap2/dss/hdmi_panel.c
index 533d5dc..c0aa922 100644
--- a/drivers/video/omap2/dss/hdmi_panel.c
+++ b/drivers/video/omap2/dss/hdmi_panel.c
@@ -33,6 +33,33 @@ static struct {
struct mutex hdmi_lock;
} hdmi;
+static ssize_t hdmi_range_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ int r;
+
+ r = omapdss_hdmi_get_range();
+ return snprintf(buf, PAGE_SIZE, %d\n, r);
+}
+
+static ssize_t hdmi_range_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ unsigned long range;
+ int r = kstrtoul(buf, 0, range);
+
+ if (r || range 1)
+ return -EINVAL;
+
+ r = omapdss_hdmi_set_range(range);
+ if (r)
+ return r;
+
+ return size;
+}
I don't like to add a new custom userspace API, but I guess we don't
have much choice.
However, I don't think using 0 and 1 in the API is very good. The
choices with range should probably be full and limited.
Btw, I tried to apply this patch set on top of dss master with and
without the improve the timings... patch set, and failed both. What
are these patches based on?
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH v3 3/4] OMAPDSS: HDMI: change the timing match logic
On Wed, 2012-01-04 at 16:39 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
Change the timing match logic, Instead of the statically mapped method
to get the corresponding timings for a given code and mode, move to a
simpler array indexed method. It will help to scale up to add more
timings when needed.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 177 +--
1 files changed, 77 insertions(+), 100 deletions(-)
-static int get_timings_index(void)
+static const struct hdmi_config *hdmi_find_timing(
+ const struct hdmi_config *timings_arr,
+ int len)
{
- int code;
+ int i;
+ const struct hdmi_config *timing = NULL;
- if (hdmi.mode == 0)
- code = code_vesa[hdmi.code];
- else
- code = code_cea[hdmi.code];
+ for (i = 0; i len; i++) {
+ if (timings_arr[i].cm.code == hdmi.code) {
+ timing = timings_arr[i];
+ return timing;
+ }
+ }
+ return timing;
You don't need the timing variable at all. Just return timings_arr[i]
or NULL.
@@ -341,9 +312,15 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
dssdev-panel.timings.x_res,
dssdev-panel.timings.y_res);
- code = get_timings_index();
- update_hdmi_timings(hdmi.ip_data.cfg, p, code);
-
+ if (hdmi_get_timings() == NULL) {
+ /* HDMI code 4 corresponds to 640 * 480 VGA */
+ hdmi.code = 4;
+ /* DVI mode 1 corresponds to HDMI 0 to DVI */
+ hdmi.mode = HDMI_DVI;
+ hdmi.ip_data.cfg = vesa_timings[0];
+ } else {
+ hdmi.ip_data.cfg = *(hdmi_get_timings());
+ }
Now you are searching for the timings twice... Do:
timings = hdmi_get_timings();
if (timings == NULL) {
/* default to VGA */
...
} else {
hdmi.ip_data.cfg = *timings;
}
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH v2 2/3] OMAPDSS: HDMI: Add quantization range support in IP lib
On Wed, 2012-01-04 at 17:23 +0530, mythr...@ti.com wrote:
From: Mythri P K mythr...@ti.com
Configure the IP to support the limited range and full range quantization
mode. If the full range is configured HDMI transmitter will expand the range
of pixel data from 16-235 to full 8 bit 0-235.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/ti_hdmi.h |7 +
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 40
+
2 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index 835cfb1..1b485ee 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -42,6 +42,11 @@ enum hdmi_clk_refsel {
HDMI_REFSEL_SYSCLK = 3
};
+enum hdmi_range {
+ HDMI_LIMITED_RANGE = 0,
+ HDMI_FULL_RANGE = 1,
+};
+
/* HDMI timing structure */
struct hdmi_video_timings {
u16 x_res;
@@ -159,6 +164,7 @@ struct hdmi_ip_data {
struct hdmi_config cfg;
struct hdmi_pll_info pll_data;
struct hdmi_core_infoframe_avi avi_cfg;
+ enum hdmi_range range;
};
int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data);
void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data);
@@ -172,5 +178,6 @@ void ti_hdmi_4xxx_wp_dump(struct hdmi_ip_data *ip_data,
struct seq_file *s);
void ti_hdmi_4xxx_pll_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
void ti_hdmi_4xxx_core_dump(struct hdmi_ip_data *ip_data, struct seq_file
*s);
void ti_hdmi_4xxx_phy_dump(struct hdmi_ip_data *ip_data, struct seq_file *s);
+int ti_hdmi_4xxx_configure_range(struct hdmi_ip_data *ip_data);
#endif
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index b66d82e..a98ce8a 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -610,6 +610,46 @@ static void hdmi_core_aux_infoframe_avi_config(struct
hdmi_ip_data *ip_data)
hdmi_write_reg(av_base, HDMI_CORE_AV_AVI_CHSUM, checksum);
}
+int ti_hdmi_4xxx_configure_range(struct hdmi_ip_data *ip_data)
+{
+ int var;
+
+ switch (ip_data-range) {
+ /*
+ * Setting the AVI infroframe to respective limited range
+ * 0 if limited range 1 if full range
+ */
+ case HDMI_LIMITED_RANGE:
+ ip_data-avi_cfg.db3_q_range = HDMI_INFOFRAME_AVI_DB3Q_LR;
+ hdmi_core_aux_infoframe_avi_config(ip_data);
+ var = hdmi_read_reg(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_SYS_VID_ACEN);
+ var = FLD_MOD(var, 1, 1, 1);
+ hdmi_write_reg(hdmi_core_sys_base(ip_data),
+ HDMI_CORE_SYS_VID_ACEN, var);
+ break;
+ case HDMI_FULL_RANGE:
+ default:
I don't think you should have HDMI_FULL_RANGE and default at the same
case. If the range is not limited or full, the value is illegal and you
should give an error.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] video/omap2. dispc_mgr_enable needs runtime PM
On Wed, 04 Jan 2012 09:50:56 +0200 Tomi Valkeinen tomi.valkei...@ti.com wrote: (dropping the Tony and Kevin, as they're probably not interested in this) Thanks takes a while to figure who cares about what :-) On Fri, 2011-12-30 at 12:37 +1100, NeilBrown wrote: When dispc_mgr_enable is called during shutdown the device might be asleep, which causes problems. So ensure it is awake. How does this problem happen? dispc_mgr_enable(channel, false) shouldn't be called if the device is asleep, and thus dispc_mgr_enable() shouldn't use dispc_runtime_get. Tomi The stack trace shows: [ 101.764556] [c0205b3c] (dispc_mgr_enable+0x40/0x2e0) from [c020c10c] (dss_mgr_disable+0x14/0x20) [ 101.774078] [c020c10c] (dss_mgr_disable+0x14/0x20) from [c020e500] (omapdss_dpi_display_disable+0x1c/0x88) [ 101.784484] [c020e500] (omapdss_dpi_display_disable+0x1c/0x88) from [c021efa4] (td028ttec1_panel_suspend+0x1c/0x88) [ 101.795684] [c021efa4] (td028ttec1_panel_suspend+0x1c/0x88) from [c021f03c] (td028ttec1_panel_disable+0x2c/0x50) [ 101.806640] [c021f03c] (td028ttec1_panel_disable+0x2c/0x50) from [c020ab6c] (dss_disable_device+0x20/0x2c) [ 101.817047] [c020ab6c] (dss_disable_device+0x20/0x2c) from [c024ad08] (bus_for_each_dev+0x4c/0x8c) [ 101.826751] [c024ad08] (bus_for_each_dev+0x4c/0x8c) from [c024ca0c] (platform_drv_shutdown+0x1c/0x24) [ 101.836700] [c024ca0c] (platform_drv_shutdown+0x1c/0x24) from [c0248164] (device_shutdown+0xcc/0x10c) [ 101.846679] [c0248164] (device_shutdown+0xcc/0x10c) from [c004c134] (kernel_power_off+0x10/0x4c) [ 101.856170] [c004c134] (kernel_power_off+0x10/0x4c) from [c004c420] (sys_reboot+0x124/0x1e0) [ 101.865325] [c004c420] (sys_reboot+0x124/0x1e0) from [c000e9c0] (ret_fast_syscall+0x0/0x3c) td028ttec1_panel_* are in a non-mainline driver that could well be buggy. . yep, that looks likely. The 'disable' routines of other panels only call omapdss_dpi_display_disable() if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE). This panel calls it unconditionally. I guess that is the real bug? (and putting an appropriate test in fixes it). Thanks for your help. (If/when I get this td028ttec driver cleaned up, would you be the one I send it to?) Thanks, NeilBrown signature.asc Description: PGP signature
Re: [PATCH] video/omap2. dispc_mgr_enable needs runtime PM
On Thu, 2012-01-05 at 18:32 +1100, NeilBrown wrote: On Wed, 04 Jan 2012 09:50:56 +0200 Tomi Valkeinen tomi.valkei...@ti.com wrote: yep, that looks likely. The 'disable' routines of other panels only call omapdss_dpi_display_disable() if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE). This panel calls it unconditionally. I guess that is the real bug? (and putting an appropriate test in fixes it). Yes, that's the bug then. The enable and disable calls must match. Thanks for your help. (If/when I get this td028ttec driver cleaned up, would you be the one I send it to?) Yep. However, I'm currently working on device tree support for omapdss, which will affect all panel drivers, and I may reject any new panel patches until the dev tree stuff is in. But please send anyway =). Tomi signature.asc Description: This is a digitally signed message part
