Re: [beagleboard] EHCI softirq kernel panic
On Wed, Aug 10, 2011 at 4:35 PM, Felipe Balbi wrote: > Hi, > > On Wed, Aug 10, 2011 at 10:11:48AM -0400, Alan Stern wrote: >> On Wed, 10 Aug 2011, Felipe Balbi wrote: >> >> > Hi, >> > >> > On Tue, Aug 09, 2011 at 02:30:14PM -0400, Jason Kridner wrote: >> > > On Tue, Aug 9, 2011 at 1:51 PM, Joel A Fernandes >> > > wrote: >> > > > Anyone seen this before? >> > > >> > > A lot of the kernel developers don't frequent the beagleboard list. >> > > If you think it is a general kernel bug, I suspect you want to copy >> > > linux-omap. >> > >> > and linux-usb, and Alan Stern as he's the EHCI maintainer and myself for >> > the OMAP USB part ;-) >> > >> > > > Trying to boot 3.0.0 with OE patches from an SD Card, and with a >> > > > network cable connected results in the following traceback. >> > > > Not connecting a network cable makes the errors go away. >> >> > > > [ ? 99.084899] Unable to handle kernel NULL pointer dereference at >> > > > virtual address >> > > > [ ? 99.093383] pgd = c0004000 >> > > > [ ? 99.096191] [] *pgd= >> > > > [ ? 99.099945] Internal error: Oops: 17 [#2] >> > > > [ ? 99.104125] Modules linked in: ipv6 >> > > > [ ? 99.107788] CPU: 0 ? ?Tainted: G ? ? ?D ? ? ?(3.0.0+ #1) >> > > > [ ? 99.113342] PC is at ehci_quiesce+0xc/0x94 >> > > > [ ? 99.117614] LR is at ehci_stop+0x34/0x8c >> > > > [ ? 99.121734] pc : [] ? ?lr : [] ? ?psr: 21d3 >> > > > [ ? 99.121734] sp : c064de70 ?ip : 0108 ?fp : c06b8624 >> > > > [ ? 99.133728] r10: c064dec0 ?r9 : ?r8 : dee08504 >> > > > [ ? 99.139190] r7 : c0328b94 ?r6 : 0100 ?r5 : dee08504 ?r4 : >> > > > dee08608 >> > > > [ ? 99.145996] r3 : ?r2 : dee086ec ?r1 : dee086b8 ?r0 : >> > > > dee08608 >> > > > [ ? 99.152832] Flags: nzCv ?IRQs off ?FIQs off ?Mode SVC_32 ?ISA ARM >> > > > Segment kernel >> > > > [ ? 99.160644] Control: 10c5387d ?Table: 9d804019 ?DAC: 0015 >> > > > [ ? 99.166656] Process swapper (pid: 0, stack limit = 0xc064c2f0) >> > > > [ ? 99.172760] Stack: (0xc064de70 to 0xc064e000) >> >> > > > [ ? 99.288482] [] (ehci_quiesce+0xc/0x94) from [] >> > > > (ehci_stop+0x34/0x8c) >> > > > [ ? 99.296936] [] (ehci_stop+0x34/0x8c) from [] >> > > > (run_timer_softirq+0x15c/0x1f8) >> > > > [ ? 99.306121] [] (run_timer_softirq+0x15c/0x1f8) from >> > > > [] (0xc064dec0) >> > > > [ ? 99.314483] Code: c05d7f9a e92d4073 e1a04000 e5903004 (e5933000) >> > > > [ ? 99.320892] ---[ end trace 4ae88755f08e391f ]--- >> > > > [ ? 99.325714] Kernel panic - not syncing: Fatal exception in interrupt >> >> I'm puzzled. Why is ehci_stop getting called in a softirq context? >> That should never happen. It should get called only when the driver is >> unbound from the controller. > > Maybe some OpenEmbedded patch which changed the behavior and ended up > breaking the driver ? > Hi Felipe, Thanks for looking into this. It could be the 1GHz OPP patch in OE, after reverting it [1] I haven't seen this issue since. Thanks, Joel [1] https://github.com/joelagnel/meta-texasinstruments/commit/95fc251b1aeafc1ef774659a8e8654e11b620778 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Fixes to twl4030-madc and add BeagleBoard support
These patches add basic functionality to the twl4030-madc driver to make it work on the BeagleBoard xM. These patches were also tested on a OMAP3EVM. Kyle Manna (3): twl4030-madc: copy the device pointer twl4030-madc: turn on the MADC clock BeagleBoard: add support for the twl4030-madc arch/arm/mach-omap2/board-omap3beagle.c | 11 +++ drivers/mfd/twl4030-madc.c | 27 ++- include/linux/i2c/twl4030-madc.h|4 3 files changed, 41 insertions(+), 1 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] twl4030-madc: turn on the MADC clock
Without turning the MADC clock on, no MADC conversions occur.
$ cat /sys/class/hwmon/hwmon0/device/in8_input
[ 53.428436] twl4030_madc twl4030_madc: conversion timeout!
cat: read error: Resource temporarily unavailable
Signed-off-by: Kyle Manna
---
drivers/mfd/twl4030-madc.c | 22 ++
include/linux/i2c/twl4030-madc.h |4
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c
index 8ef7801..75040b4 100644
--- a/drivers/mfd/twl4030-madc.c
+++ b/drivers/mfd/twl4030-madc.c
@@ -740,6 +740,28 @@ static int __devinit twl4030_madc_probe(struct
platform_device *pdev)
TWL4030_BCI_BCICTL1);
goto err_i2c;
}
+
+ /* Check that MADC clock is on */
+ ret = twl_i2c_read_u8(TWL4030_MODULE_INTBR, ®val, TWL4030_REG_GPBR1);
+ if (ret) {
+ dev_err(&pdev->dev, "unable to read reg GPBR1 0x%X\n",
+ TWL4030_REG_GPBR1);
+ }
+
+ /* If MADC clk is not on, turn it on */
+ if (!(regval & TWL4030_GPBR1_MADC_HFCLK_EN)) {
+ dev_info(&pdev->dev, "clk disabled, enabling\n");
+ regval |= TWL4030_GPBR1_MADC_HFCLK_EN;
+ ret = twl_i2c_write_u8(TWL4030_MODULE_INTBR, regval,
+ TWL4030_REG_GPBR1);
+ if (ret) {
+ dev_err(&pdev->dev, "unable to write reg GPBR1 0x%X\n",
+ TWL4030_REG_GPBR1);
+ goto err_i2c;
+ }
+ }
+
+
platform_set_drvdata(pdev, madc);
mutex_init(&madc->lock);
ret = request_threaded_irq(platform_get_irq(pdev, 0), NULL,
diff --git a/include/linux/i2c/twl4030-madc.h b/include/linux/i2c/twl4030-madc.h
index 6427d29..530e11b 100644
--- a/include/linux/i2c/twl4030-madc.h
+++ b/include/linux/i2c/twl4030-madc.h
@@ -129,6 +129,10 @@ enum sample_type {
#define REG_BCICTL2 0x024
#define TWL4030_BCI_ITHSENS0x007
+/* Register and bits for GPBR1 register */
+#define TWL4030_REG_GPBR1 0x0c
+#define TWL4030_GPBR1_MADC_HFCLK_EN(1 << 7)
+
struct twl4030_madc_user_parms {
int channel;
int average;
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] twl4030-madc: copy the device pointer
Worst case this fixes the following error:
[ 72.086212] (NULL device *): conversion timeout!
Best case it prevents a crash
Signed-off-by: Kyle Manna
---
drivers/mfd/twl4030-madc.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c
index b5d598c..8ef7801 100644
--- a/drivers/mfd/twl4030-madc.c
+++ b/drivers/mfd/twl4030-madc.c
@@ -706,6 +706,9 @@ static int __devinit twl4030_madc_probe(struct
platform_device *pdev)
if (!madc)
return -ENOMEM;
+ /* Copy the pointer to device struct */
+ madc->dev = &pdev->dev;
+
/*
* Phoenix provides 2 interrupt lines. The first one is connected to
* the OMAP. The other one can be connected to the other processor such
@@ -733,7 +736,7 @@ static int __devinit twl4030_madc_probe(struct
platform_device *pdev)
ret = twl_i2c_write_u8(TWL4030_MODULE_MAIN_CHARGE,
regval, TWL4030_BCI_BCICTL1);
if (ret) {
- dev_err(&pdev->dev, "unable to write reg BCI Ctl1 0x%X\n",
+ dev_err(&pdev->dev, "unable to write reg BCI CTL1 0x%X\n",
TWL4030_BCI_BCICTL1);
goto err_i2c;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] BeagleBoard: add support for the twl4030-madc
Signed-off-by: Kyle Manna
---
arch/arm/mach-omap2/board-omap3beagle.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 3ae16b4..a82d53b 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -362,11 +362,16 @@ static struct regulator_init_data beagle_vsim = {
.consumer_supplies = beagle_vsim_supply,
};
+static struct twl4030_madc_platform_data beagle_madc = {
+ .irq_line = 1,
+};
+
static struct twl4030_platform_data beagle_twldata = {
/* platform_data for children goes here */
.gpio = &beagle_gpio_data,
.vmmc1 = &beagle_vmmc1,
.vsim = &beagle_vsim,
+ .madc = &beagle_madc,
};
static struct i2c_board_info __initdata beagle_i2c_eeprom[] = {
@@ -456,9 +461,15 @@ static void __init omap3_beagle_init_irq(void)
omap3_init_irq();
}
+static struct platform_device madc_hwmon = {
+ .name = "twl4030_madc_hwmon",
+ .id = -1,
+};
+
static struct platform_device *omap3_beagle_devices[] __initdata = {
&leds_gpio,
&keys_gpio,
+ &madc_hwmon,
};
static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
--
1.7.4.1
--
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] rtc: twl: Fix registration vs. init order
Only register as an RTC device after the hardware has been
successfully initialized. The RTC class driver will call
back to this driver to read a pending alarm, and other
drivers watching for new devices on the RTC class may
read the RTC time upon registration. Such access might
occur while the RTC is stopped, prior to clearing
pending alarms, etc.
The new ordering also avoids leaving the platform
device drvdata set to an unregistered struct rtc_device *
on probe errors.
Signed-off-by: Todd Poynor
---
This version generated after applying:
[PATCH] rtc-twl: Switch to using threaded irq
http://patchwork.ozlabs.org/patch/97978/
drivers/rtc/rtc-twl.c | 52 ++--
1 files changed, 24 insertions(+), 28 deletions(-)
diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
index 9677bbc..20687d5 100644
--- a/drivers/rtc/rtc-twl.c
+++ b/drivers/rtc/rtc-twl.c
@@ -420,24 +420,12 @@ static struct rtc_class_ops twl_rtc_ops = {
static int __devinit twl_rtc_probe(struct platform_device *pdev)
{
struct rtc_device *rtc;
- int ret = 0;
+ int ret = -EINVAL;
int irq = platform_get_irq(pdev, 0);
u8 rd_reg;
if (irq <= 0)
- return -EINVAL;
-
- rtc = rtc_device_register(pdev->name,
- &pdev->dev, &twl_rtc_ops, THIS_MODULE);
- if (IS_ERR(rtc)) {
- ret = PTR_ERR(rtc);
- dev_err(&pdev->dev, "can't register RTC device, err %ld\n",
- PTR_ERR(rtc));
- goto out0;
-
- }
-
- platform_set_drvdata(pdev, rtc);
+ goto out1;
ret = twl_rtc_read_u8(&rd_reg, REG_RTC_STATUS_REG);
if (ret < 0)
@@ -454,14 +442,6 @@ static int __devinit twl_rtc_probe(struct platform_device
*pdev)
if (ret < 0)
goto out1;
- ret = request_threaded_irq(irq, NULL, twl_rtc_interrupt,
- IRQF_TRIGGER_RISING,
- dev_name(&rtc->dev), rtc);
- if (ret < 0) {
- dev_err(&pdev->dev, "IRQ is not free.\n");
- goto out1;
- }
-
if (twl_class_is_6030()) {
twl6030_interrupt_unmask(TWL6030_RTC_INT_MASK,
REG_INT_MSK_LINE_A);
@@ -472,28 +452,44 @@ static int __devinit twl_rtc_probe(struct platform_device
*pdev)
/* Check RTC module status, Enable if it is off */
ret = twl_rtc_read_u8(&rd_reg, REG_RTC_CTRL_REG);
if (ret < 0)
- goto out2;
+ goto out1;
if (!(rd_reg & BIT_RTC_CTRL_REG_STOP_RTC_M)) {
dev_info(&pdev->dev, "Enabling TWL-RTC.\n");
rd_reg = BIT_RTC_CTRL_REG_STOP_RTC_M;
ret = twl_rtc_write_u8(rd_reg, REG_RTC_CTRL_REG);
if (ret < 0)
- goto out2;
+ goto out1;
}
/* init cached IRQ enable bits */
ret = twl_rtc_read_u8(&rtc_irq_bits, REG_RTC_INTERRUPTS_REG);
if (ret < 0)
+ goto out1;
+
+ rtc = rtc_device_register(pdev->name,
+ &pdev->dev, &twl_rtc_ops, THIS_MODULE);
+ if (IS_ERR(rtc)) {
+ ret = PTR_ERR(rtc);
+ dev_err(&pdev->dev, "can't register RTC device, err %ld\n",
+ PTR_ERR(rtc));
+ goto out1;
+ }
+
+ ret = request_threaded_irq(irq, NULL, twl_rtc_interrupt,
+ IRQF_TRIGGER_RISING,
+ dev_name(&rtc->dev), rtc);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "IRQ is not free.\n");
goto out2;
+ }
- return ret;
+ platform_set_drvdata(pdev, rtc);
+ return 0;
out2:
- free_irq(irq, rtc);
-out1:
rtc_device_unregister(rtc);
-out0:
+out1:
return ret;
}
--
1.7.3.1
--
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: [RFC PATCH 4/6] OMAP4: Temperature sensor device support
On Wed, Aug 10, 2011 at 6:06 PM, Felipe Balbi wrote:
> Hi,
>
> (you should Cc Tony, as he's OMAP maintainer)
>
> On Wed, Aug 10, 2011 at 05:55:20PM +0530, Keerthy wrote:
>> The device file adds the device support for OMAP4
>> on die temperature sensor.
>>
>> Signed-off-by: Keerthy
>> ---
>> arch/arm/mach-omap2/Makefile | 3 +-
>> arch/arm/mach-omap2/temp_sensor_device.c | 85
>> +++
>> arch/arm/plat-omap/Kconfig | 12 +++
>> .../plat-omap/include/plat/temperature_sensor.h | 87
>>
>> 4 files changed, 186 insertions(+), 1 deletions(-)
>> create mode 100644 arch/arm/mach-omap2/temp_sensor_device.c
>> create mode 100644 arch/arm/plat-omap/include/plat/temperature_sensor.h
>>
>> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
>> index fb02937..5812fb4 100644
>> --- a/arch/arm/mach-omap2/Makefile
>> +++ b/arch/arm/mach-omap2/Makefile
>> @@ -18,6 +18,7 @@ obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common)
>>
>> obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
>>
>> +obj-$(CONFIG_OMAP_TEMP_SENSOR) += temp_sensor_device.o
>> obj-$(CONFIG_TWL4030_CORE) += omap_twl.o
>>
>> # SMP support ONLY available for OMAP4
>> @@ -86,7 +87,7 @@ obj-$(CONFIG_ARCH_OMAP3) += prcm.o
>> cm2xxx_3xxx.o prm2xxx_3xxx.o \
>> obj-$(CONFIG_ARCH_OMAP4) += prcm.o cm2xxx_3xxx.o cminst44xx.o \
>> cm44xx.o prcm_mpu44xx.o \
>> prminst44xx.o vc44xx_data.o \
>> - vp44xx_data.o
>> + vp44xx_data.o temp_sensor4460_data.o
>>
>> # OMAP voltage domains
>> ifeq ($(CONFIG_PM),y)
>> diff --git a/arch/arm/mach-omap2/temp_sensor_device.c
>> b/arch/arm/mach-omap2/temp_sensor_device.c
>> new file mode 100644
>> index 000..5d5e92f
>> --- /dev/null
>> +++ b/arch/arm/mach-omap2/temp_sensor_device.c
>> @@ -0,0 +1,85 @@
>> +/*
>> + * OMAP on die Temperature sensor device file
>> + *
>> + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
>> + * Author: J Keerthy
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * version 2 as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful, but
>> + * WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> + * General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
>> + * 02110-1301 USA
>> + *
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include "control.h"
>> +#include "pm.h"
>> +#include
>> +
>> +static struct omap_device_pm_latency omap_temp_sensor_latency[] = {
>> + {
>> + .deactivate_func = omap_device_idle_hwmods,
>> + .activate_func = omap_device_enable_hwmods,
>> + .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
>> + }
>
> wrong indentation.
>
Ok. I will correct this.
>> +};
>> +
>> +static int temp_sensor_dev_init(struct omap_hwmod *oh, void *user)
>> +{
>> + struct omap_temp_sensor_pdata *temp_sensor_pdata;
>> + struct omap_device *od;
>> + struct omap_temp_sensor_dev_attr *temp_sensor_dev_attr;
>> + int ret;
>> + static int device_count;
>
> use an IDR here (see include/linux/idr.h)
Ok. I will check this.
>
>> + ret = 0;
>
> initialize on the declarion and you can avoid this line.
Ok
>
>> + temp_sensor_pdata =
>> + kzalloc(sizeof(*temp_sensor_pdata), GFP_KERNEL);
>> + if (!temp_sensor_pdata) {
>> + dev_err(&oh->od->pdev.dev,
>> + "Unable to allocate memory for temp sensor pdata\n");
>> + return -ENOMEM;
>> + }
>> +
>> + temp_sensor_dev_attr = oh->dev_attr;
>> + if (!strcmp(temp_sensor_dev_attr->name, "mpu"))
>> + temp_sensor_pdata->registers = &omap_mpu_temp_sensor_registers;
>> +
>> + od = omap_device_build("omap_temp_sensor", device_count++,
>> + oh, temp_sensor_pdata, sizeof(*temp_sensor_pdata),
>> + omap_temp_sensor_latency,
>> + ARRAY_SIZE(omap_temp_sensor_latency), 0);
>> + if (IS_ERR(od)) {
>> + dev_warn(&oh->od->pdev.dev,
>> + "Could not build omap_device for %s\n", oh->name);
>> + ret = PTR_ERR(od);
>> + }
>> +
>> + kfree(temp_sensor_pdata);
>> +
>> + return ret;
>> +}
>> +
>> +int __init omap_devinit_temp_sensor(void)
>> +{
>> + if (!cpu_is_omap4
Re: tidspbridge issue with omap_dm_timer_free
On Wed, Aug 10, 2011 at 9:42 PM, Felipe Contreras
wrote:
> I am trying to use a more recent version of the tidspbridge code in
> the Nokia N9, but I'm stuck with this warning that is caused by using
> the dm timer framework.
Actually, the problem only happens on the 'dspbridge' branch, which
has some unmerged patches. These patches introduce some new mutexes
that trigger this.
My proposed solution is to request the dm timers at initialization
time, and just enable/disable them on wake/hibernate, which is a bit
similar to what was happening before, and probably more efficient and
proper.
I'm attaching the patch.
--
Felipe Contreras
From cd7f245ba42eb0d18bdfc3f29e2856f09227528e Mon Sep 17 00:00:00 2001
From: Felipe Contreras
Date: Thu, 11 Aug 2011 01:28:08 +0300
Subject: [PATCH] staging: tidspbridge: split gpt requests
Otherwise I get this:
BUG: sleeping function called from invalid context at kernel/mutex.c:287
in_atomic(): 1, irqs_disabled(): 0, pid: 305, name: mboxd/0
3 locks held by mboxd/0/305:
#0: (mboxd){+.+...}, at: [] worker_thread+0x154/0x2bc
#1: (&mq->work){+.+...}, at: [] worker_thread+0x154/0x2bc
#2: (pwr_lock){+.}, at: [] handle_hibernation_from_dsp+0x1c/0x158 [bridgedriver]
[] (unwind_backtrace+0x0/0xd4) from [] (mutex_lock_nested+0x30/0x32c)
[] (mutex_lock_nested+0x30/0x32c) from [] (clk_set_parent+0x34/0xf8)
[] (clk_set_parent+0x34/0xf8) from [] (omap_dm_timer_set_source+0x34/0x58)
[] (omap_dm_timer_set_source+0x34/0x58) from [] (omap_dm_timer_reset+0x78/0xd0)
[] (omap_dm_timer_reset+0x78/0xd0) from [] (omap_dm_timer_free+0x14/0x48)
[] (omap_dm_timer_free+0x14/0x48) from [] (dsp_clk_disable+0x98/0x15c [bridgedriver])
[] (dsp_clk_disable+0x98/0x15c [bridgedriver]) from [] (dsp_clock_disable_all+0x24/0x34 [bridgedriver])
[] (dsp_clock_disable_all+0x24/0x34 [bridgedriver]) from [] (handle_hibernation_from_dsp+0xc0/0x158 [bridgedriver])
[] (handle_hibernation_from_dsp+0xc0/0x158 [bridgedriver]) from [] (io_mbox_msg+0x8c/0x100 [bridgedriver])
[] (io_mbox_msg+0x8c/0x100 [bridgedriver]) from [] (mbox_rx_work+0x3c/0xa0 [mailbox])
[] (mbox_rx_work+0x3c/0xa0 [mailbox]) from [] (worker_thread+0x1c0/0x2bc)
[] (worker_thread+0x1c0/0x2bc) from [] (kthread+0x7c/0x84)
[] (kthread+0x7c/0x84) from [] (kernel_thread_exit+0x0/0x8)
[ cut here ]
WARNING: at kernel/mutex.c:214 mutex_lock_nested+0xb0/0x32c()
Signed-off-by: Felipe Contreras
---
drivers/staging/tidspbridge/core/dsp-clock.c | 49 ++-
drivers/staging/tidspbridge/core/tiomap3430.c |3 +
.../staging/tidspbridge/include/dspbridge/clk.h|4 ++
3 files changed, 53 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/dsp-clock.c b/drivers/staging/tidspbridge/core/dsp-clock.c
index aac06c0..b0aa831 100644
--- a/drivers/staging/tidspbridge/core/dsp-clock.c
+++ b/drivers/staging/tidspbridge/core/dsp-clock.c
@@ -115,6 +115,7 @@ static s8 get_clk_type(u8 id)
void dsp_clk_exit(void)
{
dsp_clock_disable_all(dsp_clocks);
+ dsp_clock_release_all();
clk_put(iva2_clk);
clk_put(ssi.sst_fck);
@@ -146,6 +147,45 @@ void dsp_clk_init(void)
ssi.sst_fck, ssi.ssr_fck, ssi.ick);
}
+int dsp_clk_request(enum dsp_clk_id clk_id)
+{
+ struct omap_dm_timer *t;
+
+ if (get_clk_type(clk_id) != GPT_CLK)
+ return -EPERM;
+
+ t = omap_dm_timer_request_specific(DMT_ID(clk_id));
+ if (!t)
+ return -EPERM;
+ timer[clk_id - 1] = t;
+
+ return 0;
+}
+
+int dsp_clk_release(enum dsp_clk_id clk_id)
+{
+ if (get_clk_type(clk_id) != GPT_CLK)
+ return -EPERM;
+
+ omap_dm_timer_free(timer[clk_id - 1]);
+ timer[clk_id - 1] = NULL;
+
+ return 0;
+}
+
+void dsp_clock_release_all(void)
+{
+ int i;
+
+ /* release dm timer clocks */
+ for (i = 0; i < ARRAY_SIZE(timer); i++) {
+ if (!timer[i])
+ continue;
+ omap_dm_timer_free(timer[i]);
+ timer[i] = NULL;
+ }
+}
+
#ifdef CONFIG_OMAP_MCBSP
static void mcbsp_clk_prepare(bool flag, u8 id)
{
@@ -252,8 +292,9 @@ int dsp_clk_enable(enum dsp_clk_id clk_id)
clk_enable(iva2_clk);
break;
case GPT_CLK:
- timer[clk_id - 1] =
-omap_dm_timer_request_specific(DMT_ID(clk_id));
+ if (!timer[clk_id - 1])
+ return -EINVAL;
+ omap_dm_timer_enable(timer[clk_id - 1]);
break;
#ifdef CONFIG_OMAP_MCBSP
case MCBSP_CLK:
@@ -330,7 +371,9 @@ int dsp_clk_disable(enum dsp_clk_id clk_id)
clk_disable(iva2_clk);
break;
case GPT_CLK:
- omap_dm_timer_free(timer[clk_id - 1]);
+ if (!timer[clk_id - 1])
+ return -EINVAL;
+ omap_dm_timer_disable(timer[clk_id - 1]);
break;
#ifdef CONFIG_OMAP_MCBSP
case MCBSP_CLK:
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c b/drivers/staging/tidspbridge/core/tiomap3430.c
index ecd865b..fbcea0b 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -512,6 +512,7 @@ static int bridge_brd_start(struct bridge_dev_context *dev_ctxt,
if (ul_load_monitor_timer != 0x) {
clk_cmd = (BPWR_ENAB
Re: [PATCH] rtc-twl: Switch to using threaded irq
On Mon, 2011-06-27 at 18:45 +0200, Sebastian Reichel wrote: > On Tue, May 31, 2011 at 10:51:39AM +0200, Sebastian Reichel wrote: > > > The driver is accessing to i2c bus in interrupt handler. > > > Therefore, it should use threaded irq. > > I think the patch should also remove the local_irq_enable() call in > > twl_rtc_interrupt, since it's no longer needed with threaded irq. At > > least on the Pandaboard the RTC is still working with the appended > > patch. > > ping. > > Currently the kernel prints a stacktrace for each rtc-twl interrupt, > because its interrupt handler enables interrupts. I've queued both changes. Thanks for the reminder. thanks -john -- 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: [RFC PATCH 4/6] OMAP4: Temperature sensor device support
Hi,
On Wed, Aug 10, 2011 at 04:17:05PM +0200, Cousson, Benoit wrote:
> On 8/10/2011 2:48 PM, Balbi, Felipe wrote:
> >Hi,
> >
> >On Wed, Aug 10, 2011 at 05:41:02AM -0700, Tony Lindgren wrote:
> >>* Felipe Balbi [110810 05:31]:
> >>>
> >>>On Wed, Aug 10, 2011 at 05:55:20PM +0530, Keerthy wrote:
> +
> +int __init omap_devinit_temp_sensor(void)
> +{
> + if (!cpu_is_omap446x())
> + return 0;
> +
> + return omap_hwmod_for_each_by_class("temperature_sensor",
> + temp_sensor_dev_init, NULL);
> +}
> +
> +arch_initcall(omap_devinit_temp_sensor);
> >>>
> >>>I really dislike people adding more and more *initcall() to their pieces
> >>>of code. But Tony is the final Judge.
> >>
> >>Yes how about making this just a regular device driver and have it
> >>live under drivers/ somewhere?
> >>
> >>Or is there some reason why this could not be a loadable module?
> >
> >driver is loadable, this is just creating the platform_device, but still
> >I don't think it deserves its own arch_initcall(), it could very well be
> >something which is called after we know we're running at omap4, or
> >called by each board...
>
> Funny, because I thought we were trying to get rid of the ugly init
> devices from board file to use *initcall() from a dedicated device
> file.
> The advantage is that you do not have anymore a central place that
> everybody will change and that is thus subject to merge conflicts.
>
> The drawback is that you do not know where an when the devices are created.
>
> That being said, device-tree will provide a nice way to build all
> this devices without any initcall or board hacks.
> This is just a temporary issue :-)
Temporary or not, I would rather have this device created based on CPU
detection as it ought to be. But since we're moving to DT anyway, I
agree it might not be worth spending the time.
--
balbi
signature.asc
Description: Digital signature
Re: [beagleboard] EHCI softirq kernel panic
Hi, On Wed, Aug 10, 2011 at 10:11:48AM -0400, Alan Stern wrote: > On Wed, 10 Aug 2011, Felipe Balbi wrote: > > > Hi, > > > > On Tue, Aug 09, 2011 at 02:30:14PM -0400, Jason Kridner wrote: > > > On Tue, Aug 9, 2011 at 1:51 PM, Joel A Fernandes > > > wrote: > > > > Anyone seen this before? > > > > > > A lot of the kernel developers don't frequent the beagleboard list. > > > If you think it is a general kernel bug, I suspect you want to copy > > > linux-omap. > > > > and linux-usb, and Alan Stern as he's the EHCI maintainer and myself for > > the OMAP USB part ;-) > > > > > > Trying to boot 3.0.0 with OE patches from an SD Card, and with a > > > > network cable connected results in the following traceback. > > > > Not connecting a network cable makes the errors go away. > > > > > [ ? 99.084899] Unable to handle kernel NULL pointer dereference at > > > > virtual address > > > > [ ? 99.093383] pgd = c0004000 > > > > [ ? 99.096191] [] *pgd= > > > > [ ? 99.099945] Internal error: Oops: 17 [#2] > > > > [ ? 99.104125] Modules linked in: ipv6 > > > > [ ? 99.107788] CPU: 0 ? ?Tainted: G ? ? ?D ? ? ?(3.0.0+ #1) > > > > [ ? 99.113342] PC is at ehci_quiesce+0xc/0x94 > > > > [ ? 99.117614] LR is at ehci_stop+0x34/0x8c > > > > [ ? 99.121734] pc : [] ? ?lr : [] ? ?psr: 21d3 > > > > [ ? 99.121734] sp : c064de70 ?ip : 0108 ?fp : c06b8624 > > > > [ ? 99.133728] r10: c064dec0 ?r9 : ?r8 : dee08504 > > > > [ ? 99.139190] r7 : c0328b94 ?r6 : 0100 ?r5 : dee08504 ?r4 : > > > > dee08608 > > > > [ ? 99.145996] r3 : ?r2 : dee086ec ?r1 : dee086b8 ?r0 : > > > > dee08608 > > > > [ ? 99.152832] Flags: nzCv ?IRQs off ?FIQs off ?Mode SVC_32 ?ISA ARM > > > > Segment kernel > > > > [ ? 99.160644] Control: 10c5387d ?Table: 9d804019 ?DAC: 0015 > > > > [ ? 99.166656] Process swapper (pid: 0, stack limit = 0xc064c2f0) > > > > [ ? 99.172760] Stack: (0xc064de70 to 0xc064e000) > > > > > [ ? 99.288482] [] (ehci_quiesce+0xc/0x94) from [] > > > > (ehci_stop+0x34/0x8c) > > > > [ ? 99.296936] [] (ehci_stop+0x34/0x8c) from [] > > > > (run_timer_softirq+0x15c/0x1f8) > > > > [ ? 99.306121] [] (run_timer_softirq+0x15c/0x1f8) from > > > > [] (0xc064dec0) > > > > [ ? 99.314483] Code: c05d7f9a e92d4073 e1a04000 e5903004 (e5933000) > > > > [ ? 99.320892] ---[ end trace 4ae88755f08e391f ]--- > > > > [ ? 99.325714] Kernel panic - not syncing: Fatal exception in interrupt > > I'm puzzled. Why is ehci_stop getting called in a softirq context? > That should never happen. It should get called only when the driver is > unbound from the controller. Maybe some OpenEmbedded patch which changed the behavior and ended up breaking the driver ? -- balbi signature.asc Description: Digital signature
Re: How to handle named resources with DT?
On Wed, Aug 10, 2011 at 1:57 PM, David Brown wrote: > On Wed, Aug 10, 2011 at 01:22:16PM -0600, Grant Likely wrote: > >> Please, stick with the established convention and explicitly order >> 'reg' and 'interrupts' properties. If there is a specific use case >> where this doesn't work, then bring it up, but I haven't seen any yet. >> The current users of _byname that I've looked seem to only use it for >> convenience, not because a register range may be optional. ie. they >> all fail out if a reg resource isn't present. > > The msm_serial driver uses the presence of one of it's _byname reg > regions to distinguish between two different types of the controller. > Fortunately, it is the last register range that has this. > > It's probably best to make the DT code depend on compatible (or some > attribute) to determine if this functionality is available, or in this > case, even make it a separate memory region. I'm not sure what the > cleanest way is to implement this, and still have the driver work with > non-DT systems. You can use the .data field in the match table to add in compatible-specific configuration data. g. -- 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: How to handle named resources with DT?
On Wed, Aug 10, 2011 at 01:22:16PM -0600, Grant Likely wrote: > Please, stick with the established convention and explicitly order > 'reg' and 'interrupts' properties. If there is a specific use case > where this doesn't work, then bring it up, but I haven't seen any yet. > The current users of _byname that I've looked seem to only use it for > convenience, not because a register range may be optional. ie. they > all fail out if a reg resource isn't present. The msm_serial driver uses the presence of one of it's _byname reg regions to distinguish between two different types of the controller. Fortunately, it is the last register range that has this. It's probably best to make the DT code depend on compatible (or some attribute) to determine if this functionality is available, or in this case, even make it a separate memory region. I'm not sure what the cleanest way is to implement this, and still have the driver work with non-DT systems. Patches coming soon... David -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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: How to handle named resources with DT?
On Tue, Aug 9, 2011 at 7:52 PM, David Gibson wrote: > On Tue, Aug 09, 2011 at 11:53:32PM +0200, Cousson, Benoit wrote: >> On 8/9/2011 11:49 PM, Grant Likely wrote: >> >That won't work either because that also breaks the existing 'reg' >> >binding. Anything you do will need to supplement the existing >> >binding without changing it in an incompatible way. >> >> OK, but can we add a new attribute then? reg2, reg_ng, reg_plusplus, >> reg_named...? > > He already suggested reg-names to be interpreted in parallel with the > existing reg property. The (serious) problem with replacing the reg > property is that it will break all existing OSes (including old Linux > versions) that don't understand the new property. > > Of course, the problem with reg-names is that it will be ignored by > older OSes, and so 'reg' must still be in the correct order. In which > case you could argue it's more sensible to just have a static place to > name mapping in the Linux driver. > > In short, yes, named reg elements in the DT would be nice in theory, > but I'm not convinced it's worth a DT flag day to accomplish it. I'm inclined the same way, though I agree with the replies that point out it wouldn't result in a 'flag day' because existing bindings cannot become incompatible. The problem I have is that adding reg-names or similar implies that ordering of the reg property is no longer defined which I absolutely do not think is a good idea. Please, stick with the established convention and explicitly order 'reg' and 'interrupts' properties. If there is a specific use case where this doesn't work, then bring it up, but I haven't seen any yet. The current users of _byname that I've looked seem to only use it for convenience, not because a register range may be optional. ie. they all fail out if a reg resource isn't present. So, the original answer stands, don't use _byname for DT bindings. g. -- 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
tidspbridge issue with omap_dm_timer_free
Hi,
I am trying to use a more recent version of the tidspbridge code in
the Nokia N9, but I'm stuck with this warning that is caused by using
the dm timer framework.
[ 30.883636] BUG: sleeping function called from invalid context at
kernel/mutex.c:287
[ 30.885925] in_atomic(): 1, irqs_disabled(): 0, pid: 305, name: mboxd/0
[ 30.892517] 3 locks held by mboxd/0/305:
[ 30.896392] #0: (mboxd){+.+...}, at: [] worker_thread+0x154/0x2bc
[ 30.903533] #1: (&mq->work){+.+...}, at: []
worker_thread+0x154/0x2bc
[ 30.911041] #2: (pwr_lock){+.}, at: []
handle_hibernation_from_dsp+0x1c/0x158 [bridgedriver]
[ 30.920959] [] (unwind_backtrace+0x0/0xd4) from
[] (mutex_lock_nested+0x30/0x32c)
[ 30.930175] [] (mutex_lock_nested+0x30/0x32c) from
[] (clk_set_parent+0x34/0xf8)
[ 30.939361] [] (clk_set_parent+0x34/0xf8) from
[] (omap_dm_timer_set_source+0x34/0x58)
[ 30.949035] [] (omap_dm_timer_set_source+0x34/0x58) from
[] (omap_dm_timer_reset+0x78/0xd0)
[ 30.959136] [] (omap_dm_timer_reset+0x78/0xd0) from
[] (omap_dm_timer_free+0x14/0x48)
[ 30.968780] [] (omap_dm_timer_free+0x14/0x48) from
[] (dsp_clk_disable+0x98/0x15c [bridgedriver])
[ 30.979492] [] (dsp_clk_disable+0x98/0x15c
[bridgedriver]) from [] (dsp_clock_disable_all+0x24/0x34
[bridgedriver])
[ 30.991668] [] (dsp_clock_disable_all+0x24/0x34
[bridgedriver]) from []
(handle_hibernation_from_dsp+0xc0/0x158 [bridgedriver])
[ 31.004913] [] (handle_hibernation_from_dsp+0xc0/0x158
[bridgedriver]) from [] (io_mbox_msg+0x8c/0x100
[bridgedriver])
[ 31.017364] [] (io_mbox_msg+0x8c/0x100 [bridgedriver])
from [] (mbox_rx_work+0x3c/0xa0 [mailbox])
[ 31.027954] [] (mbox_rx_work+0x3c/0xa0 [mailbox]) from
[] (worker_thread+0x1c0/0x2bc)
[ 31.037536] [] (worker_thread+0x1c0/0x2bc) from
[] (kthread+0x7c/0x84)
[ 31.045806] [] (kthread+0x7c/0x84) from []
(kernel_thread_exit+0x0/0x8)
[ 31.054290] [ cut here ]
[ 31.058837] WARNING: at kernel/mutex.c:214 mutex_lock_nested+0xb0/0x32c()
[ 31.065643] Modules linked in: ramzswap dm_crypt omaplfb
bridgedriver(C) dm_mod omap_aes mtdswap g_file_storage cmt_speech
ssi_protocol hsi_char phonet pvrsrvkm omap_ssi mailbox_mach mailbox
lis3lv02d_i2c radio_wl1273 ak8974 lis3lv02d bcm4751_gps leds_lp5523
bhsfh rtc_twl4030 twl5031_aci twl4030_keypad twl4030_pwrbutton
hid_twl4030_vibra hci_h4p cmt
[ 31.096649] [] (unwind_backtrace+0x0/0xd4) from
[] (warn_slowpath_common+0x48/0x60)
[ 31.106079] [] (warn_slowpath_common+0x48/0x60) from
[] (mutex_lock_nested+0xb0/0x32c)
[ 31.115753] [] (mutex_lock_nested+0xb0/0x32c) from
[] (clk_set_parent+0x34/0xf8)
[ 31.124908] [] (clk_set_parent+0x34/0xf8) from
[] (omap_dm_timer_set_source+0x34/0x58)
[ 31.134613] [] (omap_dm_timer_set_source+0x34/0x58) from
[] (omap_dm_timer_reset+0x78/0xd0)
[ 31.144714] [] (omap_dm_timer_reset+0x78/0xd0) from
[] (omap_dm_timer_free+0x14/0x48)
[ 31.154357] [] (omap_dm_timer_free+0x14/0x48) from
[] (dsp_clk_disable+0x98/0x15c [bridgedriver])
[ 31.165039] [] (dsp_clk_disable+0x98/0x15c
[bridgedriver]) from [] (dsp_clock_disable_all+0x24/0x34
[bridgedriver])
[ 31.177215] [] (dsp_clock_disable_all+0x24/0x34
[bridgedriver]) from []
(handle_hibernation_from_dsp+0xc0/0x158 [bridgedriver])
[ 31.190490] [] (handle_hibernation_from_dsp+0xc0/0x158
[bridgedriver]) from [] (io_mbox_msg+0x8c/0x100
[bridgedriver])
[ 31.202911] [] (io_mbox_msg+0x8c/0x100 [bridgedriver])
from [] (mbox_rx_work+0x3c/0xa0 [mailbox])
[ 31.213531] [] (mbox_rx_work+0x3c/0xa0 [mailbox]) from
[] (worker_thread+0x1c0/0x2bc)
[ 31.223114] [] (worker_thread+0x1c0/0x2bc) from
[] (kthread+0x7c/0x84)
[ 31.231414] [] (kthread+0x7c/0x84) from []
(kernel_thread_exit+0x0/0x8)
[ 31.239746] ---[ end trace e14f2f8770932c43 ]---
>From what I can see this could be triggered in upstream by enabling PM
and debug mutex stuff right after loading the baseimage.
Any ideas?
--
Felipe Contreras
--
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: [RFC/PATCH 09/14] dt: omap: prepare hwmod to support dt
On 8/10/2011 8:03 PM, G, Manjunath Kondaiah wrote: On Wed, Aug 10, 2011 at 10:41 PM, Cousson, Benoit wrote: On 8/10/2011 6:28 PM, G, Manjunath Kondaiah wrote: On Wed, Aug 10, 2011 at 01:51:47PM +0200, Cousson, Benoit wrote: Hi Manju, On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote: The omap dt requires new omap hwmod api to be added for in order to support omap dt. Both the subject and the changelog are misleading. You are not doing any hwmod stuff in it. You are just passing an "of_node" pointer during omap_device_build_ss. The subject should start with OMAP: omap_device: because it does not belong to the DT subsystem. The same comment apply to most patches in that series. The goal of this patch is to make omap-hwmod ready for dt adaptation hence I used the title "dt: omap: prepare hwmod to support dt" and "of_node" pointer is passed from dt and it is required for dt build. I think that the goal of this patch is to update the omap_device_build_ss API in order to provide a device tree node pointer to pdev. For the moment there is nothing related to hwmod. yes. it is to update *_ss api with device node pointer and introduce new api exported for dt builds. I can update with this description. And as you mentioned, patch does not do anything related to omap_device. You meant omap_hwmod? Yes. It should be "omap: omap_hwmod: add device node pointer" ... "OMAP: omap_device: Add device tree node pointer" -- 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: [RFC/PATCH 09/14] dt: omap: prepare hwmod to support dt
On Wed, Aug 10, 2011 at 10:41 PM, Cousson, Benoit wrote: > On 8/10/2011 6:28 PM, G, Manjunath Kondaiah wrote: >> >> On Wed, Aug 10, 2011 at 01:51:47PM +0200, Cousson, Benoit wrote: >>> >>> Hi Manju, >>> >>> On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote: The omap dt requires new omap hwmod api to be added for in order to support omap dt. >>> >>> Both the subject and the changelog are misleading. You are not doing >>> any hwmod stuff in it. >>> You are just passing an "of_node" pointer during omap_device_build_ss. >>> >>> The subject should start with OMAP: omap_device: because it does not >>> belong to the DT subsystem. >>> The same comment apply to most patches in that series. >> >> The goal of this patch is to make omap-hwmod ready for dt adaptation hence >> I used the title "dt: omap: prepare hwmod to support dt" and "of_node" >> pointer >> is passed from dt and it is required for dt build. > > I think that the goal of this patch is to update the omap_device_build_ss > API in order to provide a device tree node pointer to pdev. For the moment > there is nothing related to hwmod. yes. it is to update *_ss api with device node pointer and introduce new api exported for dt builds. I can update with this description. > >> And as you mentioned, patch does not do anything related to omap_device. > > You meant omap_hwmod? Yes. It should be "omap: omap_hwmod: add device node pointer" -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: [RFC/PATCH 11/14] dt: omap3: add soc file for handling i2c controllers
+ Tony
On 8/10/2011 6:57 PM, G, Manjunath Kondaiah wrote:
On Wed, Aug 10, 2011 at 02:36:50PM +0200, Cousson, Benoit wrote:
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
Add omap3 soc file for handling omap3 soc i2c controllers existing
on l4-core bus.
Signed-off-by: G, Manjunath Kondaiah
---
arch/arm/boot/dts/omap3-soc.dtsi | 62 ++
1 files changed, 62 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-soc.dtsi
diff --git a/arch/arm/boot/dts/omap3-soc.dtsi b/arch/arm/boot/dts/omap3-soc.dtsi
new file mode 100644
index 000..85de92f
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-soc.dtsi
@@ -0,0 +1,62 @@
+/*
+ * Device Tree Source for OMAP3 SoC
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "skeleton.dtsi"
+
+/ {
+ #address-cells =<1>;
+ #size-cells =<1>;
+ model = "ti,omap3";
+
+ aliases {
+ i2c1 =&i2c1;
+ i2c2 =&i2c2;
+ i2c3 =&i2c3;
+ };
+
+ l4-core {
That comment is probably subject to discussion, but even if this
interconnect is there physically, I'm not sure of the added value to
add it.
It will add an extra level of indentation and that all. Moreover, it
will mess up the physical address that are expressed using absolute
value in the TRM with a less readable offset value.
In fact, most DTS files in the ARM directory are using a purely flat
representation of the interconnect.
This is as per alignment with Tony and Grant:
http://permalink.gmane.org/gmane.linux.ports.arm.omap/60391
So I'm asking the same question to Grant and Tony then:-)
+ compatible = "ti,omap3-l4-core";
Assuming we will keep that, you should probably add a more generic
compatible name after that one. Like "ti,s3220" or even
"sonics,s3220", assuming that this IP is generic enough for other
SoC.
will check this. I don't remember any generic names.
+ #address-cells =<1>;
+ #size-cells =<1>;
+ ranges =<0 0x4800 0x100>;
+
+ i2c1: i2c@7 {
+ #address-cells =<1>;
+ #size-cells =<0>;
+ compatible = "ti,omap3-i2c";
The I2C IP and thus the driver is generic across OMAP generations
and is even potentially used by other non-OMAP TI chips like DSP or
Davinci. So having an extra compatible entry with "ti,i2c" or "ti,
omap-i2c" seems mandatory.
This can be updated as and when new soc/board adaptations are done.
As of now, it is omap3 and when we have omap4 it will be appended with
"ti,omap4-i2c" etc
To infinity and beyond?
There is no need, and we should absolutely not update the driver each
time we introduce a new SoC version/revision.
The driver should match with the generic device name in that case. Until
we change the IP and potentially introduce a new driver.
BTW, even omap3 should not be in the name in theory. It should be
potentially "ti,i2c-v3" or whatever HW version the IP is using.
But for some reason, most devices are using such convention in existing
DTS:-(
This is probably due to the lack of well identified IP version in most
SoC... including OMAP:-)
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: [RFC/PATCH 09/14] dt: omap: prepare hwmod to support dt
On 8/10/2011 6:28 PM, G, Manjunath Kondaiah wrote:
On Wed, Aug 10, 2011 at 01:51:47PM +0200, Cousson, Benoit wrote:
Hi Manju,
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
The omap dt requires new omap hwmod api to be added for in order
to support omap dt.
Both the subject and the changelog are misleading. You are not doing
any hwmod stuff in it.
You are just passing an "of_node" pointer during omap_device_build_ss.
The subject should start with OMAP: omap_device: because it does not
belong to the DT subsystem.
The same comment apply to most patches in that series.
The goal of this patch is to make omap-hwmod ready for dt adaptation hence
I used the title "dt: omap: prepare hwmod to support dt" and "of_node" pointer
is passed from dt and it is required for dt build.
I think that the goal of this patch is to update the
omap_device_build_ss API in order to provide a device tree node pointer
to pdev. For the moment there is nothing related to hwmod.
And as you mentioned, patch does not do anything related to omap_device.
You meant omap_hwmod?
Benoit
The new api is added and new parameter "np" is added for existing
api.
I don't think np is not a super meaningful name. Some more
explanation are needed as well.
ok. I can expand it.
The users of hwmod api is changed accrodingly.
omap_device API + typo.
Build and boot tested on omap3 beagle for both dt and not dt build.
Signed-off-by: G, Manjunath Kondaiah
---
arch/arm/mach-omap2/devices.c |2 +-
arch/arm/mach-omap2/mcbsp.c |2 +-
arch/arm/plat-omap/include/plat/omap_device.h | 11 +-
arch/arm/plat-omap/omap_device.c | 53 ++---
4 files changed, 59 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 458f7be..d7ff1ae 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -92,7 +92,7 @@ static int __init omap4_l3_init(void)
pr_err("could not look up %s\n", oh_name);
}
- pdev = omap_device_build_ss("omap_l3_noc", 0, oh, 3, NULL,
+ pdev = omap_device_build_ss(NULL, "omap_l3_noc", 0, oh, 3, NULL,
0, NULL, 0, 0);
OK, maybe that is just me, but in order to extend an API, I'd rather
add the new parameter at the end.
I feel it's fine since node pointer is first parameter is all dt api's.
WARN(IS_ERR(pdev), "could not build omap_device for %s\n", oh_name);
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 7a42f32..98eb95d 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -144,7 +144,7 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void
*unused)
(struct omap_mcbsp_dev_attr *)(oh->dev_attr))->sidetone);
count++;
}
- pdev = omap_device_build_ss(name, id, oh_device, count, pdata,
+ pdev = omap_device_build_ss(NULL, name, id, oh_device, count, pdata,
sizeof(*pdata), omap2_mcbsp_latency,
ARRAY_SIZE(omap2_mcbsp_latency), false);
kfree(pdata);
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 7a3ec4f..5e2424b 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -33,6 +33,7 @@
#include
#include
+#include
#include
@@ -89,12 +90,20 @@ struct platform_device *omap_device_build(const char
*pdev_name, int pdev_id,
struct omap_device_pm_latency *pm_lats,
int pm_lats_cnt, int is_early_device);
-struct platform_device *omap_device_build_ss(const char *pdev_name, int
pdev_id,
+struct platform_device *omap_device_build_ss(struct device_node *np,
+const char *pdev_name, int pdev_id,
struct omap_hwmod **oh, int oh_cnt,
void *pdata, int pdata_len,
struct omap_device_pm_latency *pm_lats,
int pm_lats_cnt, int is_early_device);
+struct platform_device *omap_device_build_dt(struct device_node *np,
+ const char *pdev_name, int pdev_id,
+ struct omap_hwmod *oh, void *pdata,
+ int pdata_len,
+ struct omap_device_pm_latency *pm_lats,
+ int pm_lats_cnt, int is_early_device);
+
void __iomem *omap_device_get_rt_va(struct omap_device *od);
/* OMAP PM interface */
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 7d5e76b..fa49168 100644
--- a/arch/arm/plat-omap/omap_device.c
Re: [RFC/PATCH 11/14] dt: omap3: add soc file for handling i2c controllers
On Wed, Aug 10, 2011 at 02:36:50PM +0200, Cousson, Benoit wrote:
> On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
> >
> >Add omap3 soc file for handling omap3 soc i2c controllers existing
> >on l4-core bus.
> >
> >Signed-off-by: G, Manjunath Kondaiah
> >---
> > arch/arm/boot/dts/omap3-soc.dtsi | 62
> > ++
> > 1 files changed, 62 insertions(+), 0 deletions(-)
> > create mode 100644 arch/arm/boot/dts/omap3-soc.dtsi
> >
> >diff --git a/arch/arm/boot/dts/omap3-soc.dtsi
> >b/arch/arm/boot/dts/omap3-soc.dtsi
> >new file mode 100644
> >index 000..85de92f
> >--- /dev/null
> >+++ b/arch/arm/boot/dts/omap3-soc.dtsi
> >@@ -0,0 +1,62 @@
> >+/*
> >+ * Device Tree Source for OMAP3 SoC
> >+ *
> >+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
> >+ *
> >+ * This file is licensed under the terms of the GNU General Public License
> >+ * version 2. This program is licensed "as is" without any warranty of any
> >+ * kind, whether express or implied.
> >+ */
> >+
> >+/dts-v1/;
> >+/include/ "skeleton.dtsi"
> >+
> >+/ {
> >+#address-cells =<1>;
> >+#size-cells =<1>;
> >+model = "ti,omap3";
> >+
> >+aliases {
> >+i2c1 =&i2c1;
> >+i2c2 =&i2c2;
> >+i2c3 =&i2c3;
> >+};
> >+
> >+l4-core {
>
> That comment is probably subject to discussion, but even if this
> interconnect is there physically, I'm not sure of the added value to
> add it.
> It will add an extra level of indentation and that all. Moreover, it
> will mess up the physical address that are expressed using absolute
> value in the TRM with a less readable offset value.
> In fact, most DTS files in the ARM directory are using a purely flat
> representation of the interconnect.
This is as per alignment with Tony and Grant:
http://permalink.gmane.org/gmane.linux.ports.arm.omap/60391
>
> >+compatible = "ti,omap3-l4-core";
>
> Assuming we will keep that, you should probably add a more generic
> compatible name after that one. Like "ti,s3220" or even
> "sonics,s3220", assuming that this IP is generic enough for other
> SoC.
will check this. I don't remember any generic names.
>
> >+#address-cells =<1>;
> >+#size-cells =<1>;
> >+ranges =<0 0x4800 0x100>;
> >+
> >+i2c1: i2c@7 {
> >+#address-cells =<1>;
> >+#size-cells =<0>;
> >+compatible = "ti,omap3-i2c";
>
> The I2C IP and thus the driver is generic across OMAP generations
> and is even potentially used by other non-OMAP TI chips like DSP or
> Davinci. So having an extra compatible entry with "ti,i2c" or "ti,
> omap-i2c" seems mandatory.
This can be updated as and when new soc/board adaptations are done.
As of now, it is omap3 and when we have omap4 it will be appended with
"ti,omap4-i2c" etc
-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: [RFC/PATCH 12/14] dt: omap3: beagle board: set clock freq for i2c devices
On Wed, Aug 10, 2011 at 02:42:56PM +0200, Cousson, Benoit wrote:
> On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
> >
> >Update omap3 beagle dts file with required clock frequencies for the i2c
> >client devices existing on beagle board.
> >
> >Beagle custom board dts file is cleaned up so that it can coexist with omap3
> >soc dts file.
> >
> >Signed-off-by: G, Manjunath Kondaiah
> >---
> > arch/arm/boot/dts/omap3-beagle-nunchuck.dts | 11 +--
> > arch/arm/boot/dts/omap3-beagle.dts | 18 +++---
> > 2 files changed, 16 insertions(+), 13 deletions(-)
> >
> >diff --git a/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
> >b/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
> >index 2607be5..324ff86 100644
> >--- a/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
> >+++ b/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
> >@@ -1,16 +1,7 @@
> > /include/ "omap3-beagle.dts"
> >
> > / {
> >-i2c@48072000 {
> >-compatible = "ti,omap3-i2c";
> >-reg =<0x48072000 0x80>;
> >-#address-cells =<1>;
> >-#size-cells =<0>;
> >-
> >-eeprom@50 {
> >-compatible = "at,at24c01";
> >-reg =< 0x50>;
> >-};
>
> This change should probably not be there.
>
> >+i2c@2 {
> > joystick@52 {
> > compatible = "sparkfun,wiichuck";
>
> It looks like someone is having fun with a beagle connected to a Wii
> nunchuck:-)
It's custom beagle belong to grant :)
>
> > reg =< 0x52>;
> >diff --git a/arch/arm/boot/dts/omap3-beagle.dts
> >b/arch/arm/boot/dts/omap3-beagle.dts
> >index 4439466..49a5ac7 100644
> >--- a/arch/arm/boot/dts/omap3-beagle.dts
> >+++ b/arch/arm/boot/dts/omap3-beagle.dts
> >@@ -1,7 +1,19 @@
> >-/dts-v1/;
> >-/include/ "skeleton.dtsi"
> >+/include/ "omap3-soc.dtsi"
>
> There is no need for the "-soc" postfix, otherwise all the other
> SoCs inside DTS directory should have it.
ok.
-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: [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver
Hi, > -Original Message- > From: lm-sensors-boun...@lm-sensors.org [mailto:lm-sensors-bounces@lm- > sensors.org] On Behalf Of Keerthy > Sent: Wednesday, August 10, 2011 5:55 PM > To: lm-sens...@lm-sensors.org > Cc: vishwanath...@ti.com; linux-omap@vger.kernel.org; b-cous...@ti.com; > rna...@ti.com > Subject: [lm-sensors] [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor > driver > > On chip temperature sensor driver. The driver monitors the temperature of > the MPU subsystem of the OMAP4. It sends notifications to the user space if > the temperature crosses user defined thresholds via kobject_uevent interface. > The user is allowed to configure the temperature thresholds vis sysfs nodes > exposed using hwmon interface. > > Signed-off-by: Keerthy > --- > drivers/hwmon/Kconfig| 11 + > drivers/hwmon/Makefile |1 + > drivers/hwmon/omap_temp_sensor.c | 950 > ++ > 3 files changed, 962 insertions(+), 0 deletions(-) > create mode 100644 drivers/hwmon/omap_temp_sensor.c > > diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig > index 5f888f7..9c9cd8b 100644 > --- a/drivers/hwmon/Kconfig > +++ b/drivers/hwmon/Kconfig > @@ -323,6 +323,17 @@ config SENSORS_F71805F > This driver can also be built as a module. If so, the module > will be called f71805f. > > +config SENSORS_OMAP_BANDGAP_TEMP_SENSOR > + bool "OMAP on-die temperature sensor hwmon driver" > + depends on HWMON && ARCH_OMAP && OMAP_TEMP_SENSOR > + help > + If you say yes here you get support for hardware > + monitoring features of the OMAP on die temperature > + sensor. > + > + Continuous conversion programmable delay > + mode is used for temperature conversion. > + > config SENSORS_F71882FG > tristate "Fintek F71882FG and compatibles" > help > diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile > index 28061cf..d0f89f5 100644 > --- a/drivers/hwmon/Makefile > +++ b/drivers/hwmon/Makefile > @@ -91,6 +91,7 @@ obj-$(CONFIG_SENSORS_MAX6639) += max6639.o > obj-$(CONFIG_SENSORS_MAX6642)+= max6642.o > obj-$(CONFIG_SENSORS_MAX6650)+= max6650.o > obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o > +obj-$(CONFIG_SENSORS_OMAP_BANDGAP_TEMP_SENSOR) += omap_temp_sensor.o > obj-$(CONFIG_SENSORS_PC87360)+= pc87360.o > obj-$(CONFIG_SENSORS_PC87427)+= pc87427.o > obj-$(CONFIG_SENSORS_PCF8591)+= pcf8591.o > diff --git a/drivers/hwmon/omap_temp_sensor.c > b/drivers/hwmon/omap_temp_sensor.c > new file mode 100644 > index 000..15e2559 > --- /dev/null > +++ b/drivers/hwmon/omap_temp_sensor.c > @@ -0,0 +1,950 @@ > +/* > + * OMAP4 Temperature sensor driver file > + * > + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/ > + * Author: J Keerthy > + * Author: Moiz Sonasath > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * version 2 as published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, but > + * WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA > + * 02110-1301 USA > + * > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define TSHUT_THRESHOLD_HOT 122000 /* 122 deg C */ > +#define TSHUT_THRESHOLD_COLD 10 /* 100 deg C */ > +#define BGAP_THRESHOLD_T_HOT 73000 /* 73 deg C */ > +#define BGAP_THRESHOLD_T_COLD71000 /* 71 deg C */ > +#define OMAP_ADC_START_VALUE 530 > +#define OMAP_ADC_END_VALUE 923 > + > +/* > + * omap_temp_sensor structure > + * @hwmon_dev - device pointer > + * @clock - Clock pointer > + * @registers - Pointer to structure with register offsets and bitfields > + * @sensor_mutex - Mutex for sysfs, irq and PM > + * @irq - MPU Irq number for thermal alert > + * @phy_base - Physical base of the temp I/O > + * @clk_rate - Holds current clock rate > + * @temp_sensor_ctrl - temp sensor control register value > + * @bg_ctrl - bandgap ctrl register value > + * @bg_counter - bandgap counter value > + * @bg_threshold - bandgap threshold register value > + * @temp_sensor_tshut_threshold - bandgap tshut register value > + * @is_efuse_valid - Flag to determine if efuse is valid or not > + * @clk_on - Manages the current clock state > + */
Re: [PATCH 5/5 v4] mfd: omap: usb: Runtime PM support
On Tue, Aug 09, 2011 at 07:45:09PM +0530, Keshava Munegowda wrote: > From: Keshava Munegowda > > The usbhs core driver does not enable/disable the intefrace and typo: interface > fucntional clocks; These clocks are handled by hwmod and runtime pm, typo: functional > hence insted of the clock enable/disable, the runtime pm APIS are > used. however,the port clocks are handled by the usbhs core. > > Signed-off-by: Keshava Munegowda ... > @@ -913,12 +598,15 @@ static int usbhs_enable(struct device *dev) > (pdata->ehci_data->reset_gpio_port[1], 1); > } > > -end_count: > - omap->count++; > + pm_runtime_put_sync(dev); > spin_unlock_irqrestore(&omap->lock, flags); Is pm_runtime_irq_safe() needed (else I think runtime PM callbacks may re-enable IRQs... or there's the new *_suspend runtime PM calls that may avoid this)? ... > @@ -266,10 +261,12 @@ static int ehci_hcd_omap_remove(struct platform_device > *pdev) > struct usb_hcd *hcd = dev_get_drvdata(dev); > > usb_remove_hcd(hcd); > - omap_usbhs_disable(dev); > disable_put_regulator(dev->platform_data); > - iounmap(hcd->regs); > usb_put_hcd(hcd); > + iounmap(hcd->regs); usb_put_hcd may release the hcd, needs to be after the deref for iounmap. > + pm_runtime_put_sync(dev); > + pm_runtime_disable(dev); Todd -- 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: [RFC/PATCH 09/14] dt: omap: prepare hwmod to support dt
On Wed, Aug 10, 2011 at 01:51:47PM +0200, Cousson, Benoit wrote:
> Hi Manju,
>
> On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
> >
> >The omap dt requires new omap hwmod api to be added for in order
> >to support omap dt.
>
> Both the subject and the changelog are misleading. You are not doing
> any hwmod stuff in it.
> You are just passing an "of_node" pointer during omap_device_build_ss.
>
> The subject should start with OMAP: omap_device: because it does not
> belong to the DT subsystem.
> The same comment apply to most patches in that series.
The goal of this patch is to make omap-hwmod ready for dt adaptation hence
I used the title "dt: omap: prepare hwmod to support dt" and "of_node" pointer
is passed from dt and it is required for dt build.
And as you mentioned, patch does not do anything related to omap_device.
>
> >The new api is added and new parameter "np" is added for existing
> >api.
>
> I don't think np is not a super meaningful name. Some more
> explanation are needed as well.
ok. I can expand it.
>
> >The users of hwmod api is changed accrodingly.
>
> omap_device API + typo.
>
> >Build and boot tested on omap3 beagle for both dt and not dt build.
> >
> >Signed-off-by: G, Manjunath Kondaiah
> >---
> > arch/arm/mach-omap2/devices.c |2 +-
> > arch/arm/mach-omap2/mcbsp.c |2 +-
> > arch/arm/plat-omap/include/plat/omap_device.h | 11 +-
> > arch/arm/plat-omap/omap_device.c | 53
> > ++---
> > 4 files changed, 59 insertions(+), 9 deletions(-)
> >
> >diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> >index 458f7be..d7ff1ae 100644
> >--- a/arch/arm/mach-omap2/devices.c
> >+++ b/arch/arm/mach-omap2/devices.c
> >@@ -92,7 +92,7 @@ static int __init omap4_l3_init(void)
> > pr_err("could not look up %s\n", oh_name);
> > }
> >
> >-pdev = omap_device_build_ss("omap_l3_noc", 0, oh, 3, NULL,
> >+pdev = omap_device_build_ss(NULL, "omap_l3_noc", 0, oh, 3, NULL,
> > 0, NULL, 0, 0);
>
> OK, maybe that is just me, but in order to extend an API, I'd rather
> add the new parameter at the end.
I feel it's fine since node pointer is first parameter is all dt api's.
>
> > WARN(IS_ERR(pdev), "could not build omap_device for %s\n", oh_name);
> >diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
> >index 7a42f32..98eb95d 100644
> >--- a/arch/arm/mach-omap2/mcbsp.c
> >+++ b/arch/arm/mach-omap2/mcbsp.c
> >@@ -144,7 +144,7 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void
> >*unused)
> > (struct omap_mcbsp_dev_attr *)(oh->dev_attr))->sidetone);
> > count++;
> > }
> >-pdev = omap_device_build_ss(name, id, oh_device, count, pdata,
> >+pdev = omap_device_build_ss(NULL, name, id, oh_device, count, pdata,
> > sizeof(*pdata), omap2_mcbsp_latency,
> > ARRAY_SIZE(omap2_mcbsp_latency), false);
> > kfree(pdata);
> >diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
> >b/arch/arm/plat-omap/include/plat/omap_device.h
> >index 7a3ec4f..5e2424b 100644
> >--- a/arch/arm/plat-omap/include/plat/omap_device.h
> >+++ b/arch/arm/plat-omap/include/plat/omap_device.h
> >@@ -33,6 +33,7 @@
> >
> > #include
> > #include
> >+#include
> >
> > #include
> >
> >@@ -89,12 +90,20 @@ struct platform_device *omap_device_build(const char
> >*pdev_name, int pdev_id,
> > struct omap_device_pm_latency *pm_lats,
> > int pm_lats_cnt, int is_early_device);
> >
> >-struct platform_device *omap_device_build_ss(const char *pdev_name, int
> >pdev_id,
> >+struct platform_device *omap_device_build_ss(struct device_node *np,
> >+ const char *pdev_name, int pdev_id,
> > struct omap_hwmod **oh, int oh_cnt,
> > void *pdata, int pdata_len,
> > struct omap_device_pm_latency *pm_lats,
> > int pm_lats_cnt, int is_early_device);
> >
> >+struct platform_device *omap_device_build_dt(struct device_node *np,
> >+ const char *pdev_name, int pdev_id,
> >+ struct omap_hwmod *oh, void *pdata,
> >+ int pdata_len,
> >+ struct omap_device_pm_latency *pm_lats,
> >+ int pm_lats_cnt, int is_early_device);
> >+
> > void __iomem *omap_device_get_rt_va(struct omap_device *od);
> >
> > /* OMAP PM interface */
> >diff --git a/arch/arm/plat-omap/omap_device.c
> >b/arch/arm/plat-omap/omap_device.c
> >index 7d5e76b..fa49168 100644
> >--- a/arch/arm/plat-omap/omap_device.c
> >+++ b/arch/arm/plat-omap/omap_device.c
> >@@ -85,6 +85,7 @@
>
Re: [RFC/PATCH 04/14] OMAP: McBSP: use existing macros for converting between devices
On Wed, Aug 10, 2011 at 12:15:50PM +0200, Cousson, Benoit wrote: > Manju, > > On 8/10/2011 9:07 AM, Jarkko Nikula wrote: > >Hi > > > >On Tue, 09 Aug 2011 19:10:22 +0500 > >"G, Manjunath Kondaiah" wrote: > > > >>From: Kevin Hilman > >> > >>For converting from struct device to platform_device, and from > >>platform_device to struct device, there are existing macros. Use > >>them instead of manual use of container_of(). > >> > >>Signed-off-by: Kevin Hilman > >>--- > >> arch/arm/plat-omap/mcbsp.c |6 +++--- > >> 1 files changed, 3 insertions(+), 3 deletions(-) > >> > >Kevin dropped this patch and used mine that does more cleanups: > > > >http://marc.info/?l=linux-omap&m=131255627918065&w=2 > > > >Worth to check also other patches since Kevin's updated set seems to > >have other differences too: > > > >http://marc.info/?l=linux-omap&m=131258997416300&w=2 > > In fact, you'd better point to the lastest Kevin's tree and not > included the patches in this series. Yes. I have already mentioned this in PATCH 00/14 and it will be rebased during rework for review comments. Main focus here is on dt-hwmod binding and omap-i2c dt adaptation. -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: [RFC/PATCH 10/14] dt: Add pd_size to AUXDATA structure
On Wed, Aug 10, 2011 at 07:16:30AM -0600, Grant Likely wrote: > On Wed, Aug 10, 2011 at 5:57 AM, Cousson, Benoit wrote: > > On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote: > >> > >> Add pd_size in the AUXDATA structure so that device drivers which require > >> platform_data size can pass along with AUXDATA. > > > > It is really needed by device driver? Or is it because omap_device_build is > > using platform_device_add_data that is doing a copy of the pdata and thus > > require the size? > > Yes, I have the same question. What is the reason for needing the > platform data size? Yes. It is required by "omap_device_build" which in turn calls "platform_device_add_data" and copies using "kmemdup" and original pdata pointer memory will get freed. It is required by hwmod and not device driver. I can change description. > > g. > > > > >> Signed-off-by: G, Manjunath Kondaiah > >> --- > >> drivers/of/platform.c | 2 ++ > >> include/linux/of_platform.h | 5 + > >> 2 files changed, 7 insertions(+), 0 deletions(-) > >> > >> diff --git a/drivers/of/platform.c b/drivers/of/platform.c > >> index ebbbf42..4b27286 100644 > >> --- a/drivers/of/platform.c > >> +++ b/drivers/of/platform.c > >> @@ -565,6 +565,7 @@ static int of_platform_bus_create(struct device_node > >> *bus, > >> struct platform_device *dev; > >> const char *bus_id = NULL; > >> void *platform_data = NULL; > >> + int pd_size; > > > > Maybe platform_data_size will be a little bit more consistent? Thought shorter name is better and still it should be readable. -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: How to handle named resources with DT?
On 8/10/2011 5:18 PM, Scott Wood wrote: On 08/09/2011 08:52 PM, David Gibson wrote: Of course, the problem with reg-names is that it will be ignored by older OSes, and so 'reg' must still be in the correct order. In which case you could argue it's more sensible to just have a static place to name mapping in the Linux driver. I think the intent was just to use this for some new bindings -- not to change existing ones. Yes, indeed. I've just realized it was maybe not clear in my email. Thanks, 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: How to handle named resources with DT?
On 08/09/2011 08:52 PM, David Gibson wrote: > Of course, the problem with reg-names is that it will be ignored by > older OSes, and so 'reg' must still be in the correct order. In which > case you could argue it's more sensible to just have a static place to > name mapping in the Linux driver. I think the intent was just to use this for some new bindings -- not to change existing ones. -Scott -- 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: [RFC PATCH 5/6] OMAP4460: Temperature sensor data
On Wed, Aug 10, 2011 at 6:07 PM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Aug 10, 2011 at 05:55:21PM +0530, Keerthy wrote:
>> The register set and the
>> bit fields might vary across OMAP versions. Hence
>> creating a structure comprising of all the registers
>> and bit fields to make the driver uniform for all the
>> versions with different register sets. The data file
>> contains the structure populated with register offsets
>> and bit fields corresponding to OMAP4460 on die sensor.
>>
>> Signed-off-by: Keerthy
>> ---
>> arch/arm/mach-omap2/temp_sensor4460_data.c | 63
>>
>> 1 files changed, 63 insertions(+), 0 deletions(-)
>> create mode 100644 arch/arm/mach-omap2/temp_sensor4460_data.c
>>
>> diff --git a/arch/arm/mach-omap2/temp_sensor4460_data.c
>> b/arch/arm/mach-omap2/temp_sensor4460_data.c
>> new file mode 100644
>> index 000..294963d
>> --- /dev/null
>> +++ b/arch/arm/mach-omap2/temp_sensor4460_data.c
>> @@ -0,0 +1,63 @@
>> +/*
>> + * OMAP4460 on die Temperature sensor data file
>> + *
>> + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
>> + * Author: J Keerthy
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * version 2 as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful, but
>> + * WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> + * General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
>> + * 02110-1301 USA
>> + *
>> + */
>> +
>> +#include
>> +#include "control.h"
>> +#include
>> +
>> +/*
>> + * OMAP4460 has one instance of thermal sensor for MPU
>> + * need to describe the individual bit fields
>> + */
>> +struct omap_temp_sensor_registers omap_mpu_temp_sensor_registers = {
>
> this is used on previous patch, so you have a compilation error.
I will reorder the patches.
>
> --
> balbi
>
--
Regards and Thanks,
Keerthy
--
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: How to handle named resources with DT?
On 8/10/2011 3:52 AM, David Gibson wrote:
On Tue, Aug 09, 2011 at 11:53:32PM +0200, Cousson, Benoit wrote:
On 8/9/2011 11:49 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 11:44:35PM +0200, Cousson, Benoit wrote:
On 8/9/2011 11:17 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 11:08:09PM +0200, Cousson, Benoit wrote:
On 8/9/2011 10:57 PM, Grant Likely wrote:
On Tue, Aug 09, 2011 at 01:26:29PM -0500, Scott Wood wrote:
On 08/09/2011 12:47 PM, Cousson, Benoit wrote:
On 8/9/2011 7:23 PM, Grant Likely wrote:
There is no analogous mechanism for _byname in the device tree. The
DT binding for a device must explicitly state what order the register
ranges are in. The driver will need to be adapted.
That seems to be a small regression for my point of view. Relying on the
order is not super safe. This is not very readable either. That's for
that exact reason that we changed our drivers to use
platform_get_resource_byname. That's probably the reason why that API is
there as well.
For the same IP, the number of entries can vary depending of the SoC
revision.
By using the _byname, we can check if the resource is there or not
without having to care about the position.
You could have a named u32 property that contains the reg index, e.g.:
dev {
reg =<0x2 0x200 0x24000 0x200>;
foo-reg =<0>;
bar-reg =<1>;
};
That's a little nasty. A reg-names = "foo", "bar"; would probably be
better.
Yep, I agree.
And what about something like that?
reg =<0x2 0x200>, "foo",
<0x2 0x200>, "bar" ;
It is doable?
Definitely not. It would break all existing 'reg' parsing
implementations quite badly.
OK, so what about extending the reg attribute to be a reg node?
dev {
reg {
name = "foo_wrapper";
start =<0x1>;
end =<0x200>;
}
reg {
name = "foo";
start =<0x2>;
end =<0x200>;
}
}
A little bit more verbose, but at least we can add any attribute we want.
That won't work either because that also breaks the existing 'reg'
binding. Anything you do will need to supplement the existing
binding without changing it in an incompatible way.
OK, but can we add a new attribute then? reg2, reg_ng, reg_plusplus,
reg_named...?
He already suggested reg-names to be interpreted in parallel with the
existing reg property. The (serious) problem with replacing the reg
property is that it will break all existing OSes (including old Linux
versions) that don't understand the new property.
That's why I was proposing a new extended node for that. Legacy tag will
still be there for legacy HW.
Adding reg-names is doable easily, but not super nice. And the same
trick will be needed for IRQs and then DMAs (not yet in core DT anyway).
Having a more scalable mechanism to allow further improvement will be good.
Of course, the problem with reg-names is that it will be ignored by
older OSes, and so 'reg' must still be in the correct order. In which
case you could argue it's more sensible to just have a static place to
name mapping in the Linux driver.
In short, yes, named reg elements in the DT would be nice in theory,
but I'm not convinced it's worth a DT flag day to accomplish it.
Sorry, but I'm not sure to understand the meaning of that last sentence.
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 v2] omap: timer: Set dmtimer used as clocksource in autoreload mode
* Hemant Pedanekar [110810 06:14]:
> If CONFIG_OMAP_32K_TIMER is not selected and dmtimer is used as clocksource,
> the
> timer stops counting once overflow occurs as it was not set in autoreload
> mode.
> This results into timekeeping failure: for example, 'sleep 1' at the shell
> after
> the timer counter overflow would hang.
>
> This patch sets up autoreload when starting the clocksource timer which fixes
> the above issue.
Thanks for updating this, will apply into fixes.
Tony
>
> Signed-off-by: Hemant Pedanekar
> ---
> arch/arm/mach-omap2/timer.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index e964072..cf1de7d 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -293,7 +293,8 @@ static void __init omap2_gp_clocksource_init(int
> gptimer_id,
> pr_info("OMAP clocksource: GPTIMER%d at %lu Hz\n",
> gptimer_id, clksrc.rate);
>
> - __omap_dm_timer_load_start(clksrc.io_base, OMAP_TIMER_CTRL_ST, 0, 1);
> + __omap_dm_timer_load_start(clksrc.io_base,
> + OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
> init_sched_clock(&cd, dmtimer_update_sched_clock, 32, clksrc.rate);
>
> if (clocksource_register_hz(&clocksource_gpt, clksrc.rate))
> --
> 1.7.3.5
>
--
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: [RFC PATCH 4/6] OMAP4: Temperature sensor device support
On 8/10/2011 2:48 PM, Balbi, Felipe wrote:
Hi,
On Wed, Aug 10, 2011 at 05:41:02AM -0700, Tony Lindgren wrote:
* Felipe Balbi [110810 05:31]:
On Wed, Aug 10, 2011 at 05:55:20PM +0530, Keerthy wrote:
+
+int __init omap_devinit_temp_sensor(void)
+{
+ if (!cpu_is_omap446x())
+ return 0;
+
+ return omap_hwmod_for_each_by_class("temperature_sensor",
+ temp_sensor_dev_init, NULL);
+}
+
+arch_initcall(omap_devinit_temp_sensor);
I really dislike people adding more and more *initcall() to their pieces
of code. But Tony is the final Judge.
Yes how about making this just a regular device driver and have it
live under drivers/ somewhere?
Or is there some reason why this could not be a loadable module?
driver is loadable, this is just creating the platform_device, but still
I don't think it deserves its own arch_initcall(), it could very well be
something which is called after we know we're running at omap4, or
called by each board...
Funny, because I thought we were trying to get rid of the ugly init
devices from board file to use *initcall() from a dedicated device file.
The advantage is that you do not have anymore a central place that
everybody will change and that is thus subject to merge conflicts.
The drawback is that you do not know where an when the devices are created.
That being said, device-tree will provide a nice way to build all this
devices without any initcall or board hacks.
This is just a temporary issue :-)
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: [beagleboard] EHCI softirq kernel panic
On Wed, 10 Aug 2011, Felipe Balbi wrote: > Hi, > > On Tue, Aug 09, 2011 at 02:30:14PM -0400, Jason Kridner wrote: > > On Tue, Aug 9, 2011 at 1:51 PM, Joel A Fernandes > > wrote: > > > Anyone seen this before? > > > > A lot of the kernel developers don't frequent the beagleboard list. > > If you think it is a general kernel bug, I suspect you want to copy > > linux-omap. > > and linux-usb, and Alan Stern as he's the EHCI maintainer and myself for > the OMAP USB part ;-) > > > > Trying to boot 3.0.0 with OE patches from an SD Card, and with a > > > network cable connected results in the following traceback. > > > Not connecting a network cable makes the errors go away. > > > [ � 99.084899] Unable to handle kernel NULL pointer dereference at > > > virtual address > > > [ � 99.093383] pgd = c0004000 > > > [ � 99.096191] [] *pgd= > > > [ � 99.099945] Internal error: Oops: 17 [#2] > > > [ � 99.104125] Modules linked in: ipv6 > > > [ � 99.107788] CPU: 0 � �Tainted: G � � �D � � �(3.0.0+ #1) > > > [ � 99.113342] PC is at ehci_quiesce+0xc/0x94 > > > [ � 99.117614] LR is at ehci_stop+0x34/0x8c > > > [ � 99.121734] pc : [] � �lr : [] � �psr: 21d3 > > > [ � 99.121734] sp : c064de70 �ip : 0108 �fp : c06b8624 > > > [ � 99.133728] r10: c064dec0 �r9 : �r8 : dee08504 > > > [ � 99.139190] r7 : c0328b94 �r6 : 0100 �r5 : dee08504 �r4 : dee08608 > > > [ � 99.145996] r3 : �r2 : dee086ec �r1 : dee086b8 �r0 : dee08608 > > > [ � 99.152832] Flags: nzCv �IRQs off �FIQs off �Mode SVC_32 �ISA ARM > > > Segment kernel > > > [ � 99.160644] Control: 10c5387d �Table: 9d804019 �DAC: 0015 > > > [ � 99.166656] Process swapper (pid: 0, stack limit = 0xc064c2f0) > > > [ � 99.172760] Stack: (0xc064de70 to 0xc064e000) > > > [ � 99.288482] [] (ehci_quiesce+0xc/0x94) from [] > > > (ehci_stop+0x34/0x8c) > > > [ � 99.296936] [] (ehci_stop+0x34/0x8c) from [] > > > (run_timer_softirq+0x15c/0x1f8) > > > [ � 99.306121] [] (run_timer_softirq+0x15c/0x1f8) from > > > [] (0xc064dec0) > > > [ � 99.314483] Code: c05d7f9a e92d4073 e1a04000 e5903004 (e5933000) > > > [ � 99.320892] ---[ end trace 4ae88755f08e391f ]--- > > > [ � 99.325714] Kernel panic - not syncing: Fatal exception in interrupt I'm puzzled. Why is ehci_stop getting called in a softirq context? That should never happen. It should get called only when the driver is unbound from the controller. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] omap3: ISP: Kernel crash when attempting suspend
From: Abhilash K V
This patch fixes the kernel crash introduced by the previous
patch:
omap3: ISP: Fix the failure of CCDC capture during
suspend/resume.
This null pointer exception happens when attempting suspend
while the ISP driver is not being used. The current patch
fixes this by deferring the code (as introduced in the
aforementioned patch) to handle buffer-starvation to get
called only if the ISP reference count is non-zero.
An additional safety check is also added to ensure that
buffer-starvation logic kicks in for an empty dmaqueue only
if the ISP pipeline is not in the stopped state.
Signed-off-by: Abhilash K V
Signed-off-by: Deepthy Ravi
---
drivers/media/video/omap3isp/isp.c | 12 ++--
drivers/media/video/omap3isp/ispvideo.c |4 +++-
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index 6604fbd..6acdedc 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -1573,6 +1573,9 @@ static int isp_pm_prepare(struct device *dev)
unsigned long flags;
WARN_ON(mutex_is_locked(&isp->isp_mutex));
+ if (isp->ref_count == 0)
+ return 0;
+
spin_lock_irqsave(&pipe->lock, flags);
pipe->state |= ISP_PIPELINE_PREPARE_SUSPEND;
spin_unlock_irqrestore(&pipe->lock, flags);
@@ -1581,9 +1584,6 @@ static int isp_pm_prepare(struct device *dev)
if (err < 0)
return err;
- if (isp->ref_count == 0)
- return 0;
-
reset = isp_suspend_modules(isp);
isp_disable_interrupts(isp);
isp_save_ctx(isp);
@@ -1613,13 +1613,13 @@ static int isp_pm_resume(struct device *dev)
struct isp_pipeline *pipe = to_isp_pipeline(&video->video.entity);
unsigned long flags;
+ if (isp->ref_count == 0)
+ return 0;
+
spin_lock_irqsave(&pipe->lock, flags);
pipe->state &= ~ISP_PIPELINE_PREPARE_SUSPEND;
spin_unlock_irqrestore(&pipe->lock, flags);
- if (isp->ref_count == 0)
- return 0;
-
return isp_enable_clocks(isp);
}
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c
index bf149a7..ffb339c 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -726,8 +726,10 @@ int isp_video_handle_buffer_starvation(struct isp_video
*video)
struct isp_video_queue *queue = video->queue;
struct isp_video_buffer *buf;
struct list_head *head = &video->dmaqueue;
+ struct isp_ccdc_device *ccdc = &video->isp->isp_ccdc;
- if (list_empty(&video->dmaqueue)) {
+ if (list_empty(&video->dmaqueue)
+ && ccdc->state != ISP_PIPELINE_STREAM_STOPPED) {
err = isp_video_deq_enq(queue);
} else if (head->next->next == head) {
/* only one buffer is left on dmaqueue */
--
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
[PATCH 1/2] omap3: ISP: Fix the failure of CCDC capture during suspend/resume
From: Abhilash K V
While resuming from the "suspended to memory" state,
occasionally CCDC fails to get enabled and thus fails
to capture frames any more till the next suspend/resume
is issued.
This is a race condition which happens only when a CCDC
frame-completion ISR is pending even as ISP device's
isp_pm_prepare() is getting called and only one buffer
is left on the DMA queue.
The DMA queue buffers are thus depleted which results in
its underrun.So when ISP resumes there are no buffers on
the queue (as the application which can issue buffers is
yet to resume) to start video capture.
This fix addresses this issue by dequeuing and enqueing
the last buffer in isp_pm_prepare() after its DMA gets
completed. Thus,when ISP resumes it always finds atleast
one buffer on the DMA queue - this is true if application
uses only 3 buffers.
Reviewed-by: Vaibhav Hiremath
Signed-off-by: Abhilash K V
Signed-off-by: Deepthy Ravi
---
drivers/media/video/omap3isp/isp.c | 20 +++
drivers/media/video/omap3isp/isp.h |4 ++
drivers/media/video/omap3isp/ispvideo.c | 56 ++-
drivers/media/video/omap3isp/ispvideo.h |2 +
4 files changed, 81 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index 94b6ed8..6604fbd 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -1566,8 +1566,20 @@ static int isp_pm_prepare(struct device *dev)
{
struct isp_device *isp = dev_get_drvdata(dev);
int reset;
+ int err = 0;
+ struct isp_ccdc_device *ccdc = &isp->isp_ccdc;
+ struct isp_video *video = &ccdc->video_out;
+ struct isp_pipeline *pipe = to_isp_pipeline(&video->video.entity);
+ unsigned long flags;
WARN_ON(mutex_is_locked(&isp->isp_mutex));
+ spin_lock_irqsave(&pipe->lock, flags);
+ pipe->state |= ISP_PIPELINE_PREPARE_SUSPEND;
+ spin_unlock_irqrestore(&pipe->lock, flags);
+
+ err = isp_video_handle_buffer_starvation(video);
+ if (err < 0)
+ return err;
if (isp->ref_count == 0)
return 0;
@@ -1596,6 +1608,14 @@ static int isp_pm_suspend(struct device *dev)
static int isp_pm_resume(struct device *dev)
{
struct isp_device *isp = dev_get_drvdata(dev);
+ struct isp_ccdc_device *ccdc = &isp->isp_ccdc;
+ struct isp_video *video = &ccdc->video_out;
+ struct isp_pipeline *pipe = to_isp_pipeline(&video->video.entity);
+ unsigned long flags;
+
+ spin_lock_irqsave(&pipe->lock, flags);
+ pipe->state &= ~ISP_PIPELINE_PREPARE_SUSPEND;
+ spin_unlock_irqrestore(&pipe->lock, flags);
if (isp->ref_count == 0)
return 0;
diff --git a/drivers/media/video/omap3isp/isp.h
b/drivers/media/video/omap3isp/isp.h
index 841870f..e391974 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -349,6 +349,10 @@ int omap3isp_register_entities(struct platform_device
*pdev,
struct v4l2_device *v4l2_dev);
void omap3isp_unregister_entities(struct platform_device *pdev);
+#ifdef CONFIG_PM
+int isp_video_handle_buffer_starvation(struct isp_video *video);
+#endif
+
/*
* isp_reg_readl - Read value of an OMAP3 ISP register
* @dev: Device pointer specific to the OMAP3 ISP.
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c
index 5833a0e..bf149a7 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -523,6 +523,26 @@ static int isp_video_buffer_prepare(struct
isp_video_buffer *buf)
return 0;
}
+#ifdef CONFIG_PM
+static int isp_video_deq_enq(struct isp_video_queue *queue)
+{
+ int err = 0;
+ struct v4l2_buffer vbuf;
+
+ vbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+ /* blocking dequeue to ensure DMA is done */
+ err = omap3isp_video_queue_dqbuf(queue, &vbuf, 0);
+ if (err < 0)
+ return err;
+ else {
+ err = omap3isp_video_queue_qbuf(queue, &vbuf);
+ if (err < 0)
+ return err;
+ }
+ return err;
+}
+#endif
+
/*
* isp_video_buffer_queue - Add buffer to streaming queue
* @buf: Video buffer
@@ -546,7 +566,7 @@ static void isp_video_buffer_queue(struct isp_video_buffer
*buf)
empty = list_empty(&video->dmaqueue);
list_add_tail(&buffer->buffer.irqlist, &video->dmaqueue);
- if (empty) {
+ if (empty && !(pipe->state & ISP_PIPELINE_PREPARE_SUSPEND)) {
if (video->type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
state = ISP_PIPELINE_QUEUE_OUTPUT;
else
@@ -687,6 +707,40 @@ void omap3isp_video_resume(struct isp_video *video, int
continuous)
}
}
+#ifdef CONFIG_PM
+
+/*
+ * isp_video_handle_buffer_starvation - Handles the case when there are only 1
+ * or les
[PATCH 0/2] omap3: ISP: Fix the failure of CCDC capture during suspend/resume
This patchset fixes the occasional failure of CCDC capture during suspend/resume. Cc: Vaibhav Hiremath Cc: Abhilash K V --- Abhilash K V (2): omap3: ISP: Fix the failure of CCDC capture during suspend/resume omap3: ISP: Kernel crash when attempting suspend drivers/media/video/omap3isp/isp.c | 22 +++- drivers/media/video/omap3isp/isp.h |4 ++ drivers/media/video/omap3isp/ispvideo.c | 58 ++- drivers/media/video/omap3isp/ispvideo.h |2 + 4 files changed, 84 insertions(+), 2 deletions(-) -- 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] omap: timer: Set dmtimer used as clocksource in autoreload mode
If CONFIG_OMAP_32K_TIMER is not selected and dmtimer is used as clocksource, the
timer stops counting once overflow occurs as it was not set in autoreload mode.
This results into timekeeping failure: for example, 'sleep 1' at the shell after
the timer counter overflow would hang.
This patch sets up autoreload when starting the clocksource timer which fixes
the above issue.
Signed-off-by: Hemant Pedanekar
---
arch/arm/mach-omap2/timer.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index e964072..cf1de7d 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -293,7 +293,8 @@ static void __init omap2_gp_clocksource_init(int gptimer_id,
pr_info("OMAP clocksource: GPTIMER%d at %lu Hz\n",
gptimer_id, clksrc.rate);
- __omap_dm_timer_load_start(clksrc.io_base, OMAP_TIMER_CTRL_ST, 0, 1);
+ __omap_dm_timer_load_start(clksrc.io_base,
+ OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
init_sched_clock(&cd, dmtimer_update_sched_clock, 32, clksrc.rate);
if (clocksource_register_hz(&clocksource_gpt, clksrc.rate))
--
1.7.3.5
--
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: [RFC/PATCH 10/14] dt: Add pd_size to AUXDATA structure
On Wed, Aug 10, 2011 at 5:57 AM, Cousson, Benoit wrote:
> On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
>>
>> Add pd_size in the AUXDATA structure so that device drivers which require
>> platform_data size can pass along with AUXDATA.
>
> It is really needed by device driver? Or is it because omap_device_build is
> using platform_device_add_data that is doing a copy of the pdata and thus
> require the size?
Yes, I have the same question. What is the reason for needing the
platform data size?
g.
>
>> Signed-off-by: G, Manjunath Kondaiah
>> ---
>> drivers/of/platform.c | 2 ++
>> include/linux/of_platform.h | 5 +
>> 2 files changed, 7 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>> index ebbbf42..4b27286 100644
>> --- a/drivers/of/platform.c
>> +++ b/drivers/of/platform.c
>> @@ -565,6 +565,7 @@ static int of_platform_bus_create(struct device_node
>> *bus,
>> struct platform_device *dev;
>> const char *bus_id = NULL;
>> void *platform_data = NULL;
>> + int pd_size;
>
> Maybe platform_data_size will be a little bit more consistent?
>
> Regards,
> Benoit
>
>> int id = -1;
>> int rc = 0;
>>
>> @@ -588,6 +589,7 @@ static int of_platform_bus_create(struct device_node
>> *bus,
>> bus_id = auxdata->name;
>> id = auxdata->id;
>> platform_data = auxdata->platform_data;
>> + pd_size = auxdata->pd_size;
>> }
>>
>> if (of_device_is_compatible(bus, "arm,primecell")) {
>> diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
>> index 252246c..a3be980 100644
>> --- a/include/linux/of_platform.h
>> +++ b/include/linux/of_platform.h
>> @@ -47,6 +47,7 @@ struct of_dev_auxdata {
>> char *name;
>> int id;
>> void *platform_data;
>> + int pd_size;
>> };
>>
>> /* Macro to simplify populating a lookup table */
>> @@ -58,6 +59,10 @@ struct of_dev_auxdata {
>> { .compatible = _compat, .phys_addr = _phys, .name = _name, \
>> .id = _id, .platform_data = _pdata }
>>
>> +#define OF_DEV_AUXDATA_ID_PDSIZE(_compat,_phys,_name,_id,_pdata,_pd_size)
>> \
>> + { .compatible = _compat, .phys_addr = _phys, .name = _name, \
>> + .id = _id, .platform_data = _pdata, .pd_size = _pd_size }
>> +
>> /**
>> * of_platform_driver - Legacy of-aware driver for platform devices.
>> *
>
>
> ___
> 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: [RFC/PATCH 14/14] dt: omap3: enable dt support for i2c1 controller
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
Adapt dt for omap i2c1 controller and remove legacy i2c
initilization in omap3 generic board file.
Tested on omap3 beagle board for dt and non-dt builds.
Signed-off-by: G, Manjunath Kondaiah
---
arch/arm/boot/dts/omap3-soc.dtsi |6 ++--
arch/arm/mach-omap2/board-omap3-dt.c | 14 +-
drivers/i2c/busses/i2c-omap.c| 23 --
drivers/of/platform.c| 41 +-
It looks like this patch is doing a lot of things. You should probably
hack the DT core first and then update the driver and the DTS.
4 files changed, 70 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-soc.dtsi b/arch/arm/boot/dts/omap3-soc.dtsi
index 85de92f..bcff63b 100644
--- a/arch/arm/boot/dts/omap3-soc.dtsi
+++ b/arch/arm/boot/dts/omap3-soc.dtsi
@@ -31,7 +31,7 @@
i2c1: i2c@7 {
#address-cells =<1>;
#size-cells =<0>;
- compatible = "ti,omap3-i2c";
+ compatible = "ti,omap3-i2c", "ti,omap3-device";
In that case the compatible is just a tagto identify an OMAP type of
devices. You should use a more generic "ti,omap-device" entry.
This is similar to the "arm,primecell" used to tag the primecell IPs.
reg =<0x7 0x100>;
interrupts =< 88>;
};
@@ -39,7 +39,7 @@
i2c2: i2c@72000 {
#address-cells =<1>;
#size-cells =<0>;
- compatible = "ti,omap3-i2c";
+ compatible = "ti,omap3-i2c", "ti,omap3-device";
reg =<0x72000 0x100>;
interrupts =< 89>;
};
@@ -47,7 +47,7 @@
i2c3: i2c@6 {
#address-cells =<1>;
#size-cells =<0>;
- compatible = "ti,omap3-i2c";
+ compatible = "ti,omap3-i2c", "ti,omap3-device";
reg =<0x6 0x100>;
interrupts =< 93>;
};
diff --git a/arch/arm/mach-omap2/board-omap3-dt.c
b/arch/arm/mach-omap2/board-omap3-dt.c
index 4b76e19..16cf283 100644
--- a/arch/arm/mach-omap2/board-omap3-dt.c
+++ b/arch/arm/mach-omap2/board-omap3-dt.c
@@ -36,11 +36,11 @@ static struct twl4030_platform_data beagle_twldata = {
/* platform_data for children goes here */
};
-static int __init omap3_beagle_i2c_init(void)
-{
- omap3_pmic_init("twl4030",&beagle_twldata);
- return 0;
-}
+struct of_dev_auxdata omap3_auxdata_lookup[] __initdata = {
+ OF_DEV_AUXDATA_ID_PDSIZE("ti,omap3-i2c", 0x4807, "i2c1", 1,\
+ &beagle_twldata, sizeof(beagle_twldata)),
+ {}
+};
static void __init omap3_init_early(void)
{
@@ -70,11 +70,11 @@ static struct of_device_id omap_dt_match_table[] __initdata
= {
static void __init omap3_init(void)
{
- omap3_beagle_i2c_init();
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap_serial_init();
- of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+ of_platform_populate(NULL, omap_dt_match_table, omap3_auxdata_lookup,
+NULL);
}
static const char *omap3_dt_match[] __initdata = {
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index ae1545b..5167737 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -972,6 +973,16 @@ static const struct i2c_algorithm omap_i2c_algo = {
.functionality = omap_i2c_func,
};
+#if defined(CONFIG_OF)
+static const struct of_device_id omap_i2c_of_match[] = {
+ {.compatible = "ti,omap3-i2c", },.
This is a generic OMAP driver, so a "ti,omap-i2c" is probably much more
appropriate. We should always avoid adding OMAP version information into
a generic driver. Only the IP version should matter for a driver.
+ {},
+}
+MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
+#else
+#define omap_i2c_of_match NULL
+#endif
+
static int __devinit
omap_i2c_probe(struct platform_device *pdev)
{
@@ -1008,12 +1019,17 @@ omap_i2c_probe(struct platform_device *pdev)
goto err_release_region;
}
+ speed = 100;/* Default speed */
if (pdata != NULL) {
speed = pdata->clkrate;
dev->set_mpu_wkup_lat = pdata->set_mpu_wkup_lat;
- } else {
- speed = 100;/* Default speed */
- dev->set_mpu_wkup_lat = NULL;
+#if defined(CONFIG_OF)
+ } else if (pdev->dev.of_node) {
+ u32 prop;
+ if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency",
+
Re: [RFC PATCH 4/6] OMAP4: Temperature sensor device support
Hi,
On Wed, Aug 10, 2011 at 05:41:02AM -0700, Tony Lindgren wrote:
> * Felipe Balbi [110810 05:31]:
> >
> > On Wed, Aug 10, 2011 at 05:55:20PM +0530, Keerthy wrote:
> > > +
> > > +int __init omap_devinit_temp_sensor(void)
> > > +{
> > > + if (!cpu_is_omap446x())
> > > + return 0;
> > > +
> > > + return omap_hwmod_for_each_by_class("temperature_sensor",
> > > + temp_sensor_dev_init, NULL);
> > > +}
> > > +
> > > +arch_initcall(omap_devinit_temp_sensor);
> >
> > I really dislike people adding more and more *initcall() to their pieces
> > of code. But Tony is the final Judge.
>
> Yes how about making this just a regular device driver and have it
> live under drivers/ somewhere?
>
> Or is there some reason why this could not be a loadable module?
driver is loadable, this is just creating the platform_device, but still
I don't think it deserves its own arch_initcall(), it could very well be
something which is called after we know we're running at omap4, or
called by each board...
--
balbi
signature.asc
Description: Digital signature
Re: [RFC PATCH 6/6] hwmon: OMAP4: On die temperature sensor driver
Hi, (why aren't below in Cc ? HARDWARE MONITORING M: Jean Delvare M: Guenter Roeck L: lm-sens...@lm-sensors.org W: http://www.lm-sensors.org/ T: quilt kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-hwmon/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git S: Maintained F: Documentation/hwmon/ F: drivers/hwmon/ F: include/linux/hwmon*.h) On Wed, Aug 10, 2011 at 05:55:22PM +0530, Keerthy wrote: > On chip temperature sensor driver. The driver monitors the temperature of > the MPU subsystem of the OMAP4. It sends notifications to the user space if > the temperature crosses user defined thresholds via kobject_uevent interface. > The user is allowed to configure the temperature thresholds vis sysfs nodes > exposed using hwmon interface. > > Signed-off-by: Keerthy > --- > drivers/hwmon/Kconfig| 11 + > drivers/hwmon/Makefile |1 + > drivers/hwmon/omap_temp_sensor.c | 950 > ++ > 3 files changed, 962 insertions(+), 0 deletions(-) > create mode 100644 drivers/hwmon/omap_temp_sensor.c > > diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig > index 5f888f7..9c9cd8b 100644 > --- a/drivers/hwmon/Kconfig > +++ b/drivers/hwmon/Kconfig > @@ -323,6 +323,17 @@ config SENSORS_F71805F > This driver can also be built as a module. If so, the module > will be called f71805f. > > +config SENSORS_OMAP_BANDGAP_TEMP_SENSOR > + bool "OMAP on-die temperature sensor hwmon driver" > + depends on HWMON && ARCH_OMAP && OMAP_TEMP_SENSOR > + help > + If you say yes here you get support for hardware > + monitoring features of the OMAP on die temperature > + sensor. > + > + Continuous conversion programmable delay > + mode is used for temperature conversion. > + > config SENSORS_F71882FG > tristate "Fintek F71882FG and compatibles" > help > diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile > index 28061cf..d0f89f5 100644 > --- a/drivers/hwmon/Makefile > +++ b/drivers/hwmon/Makefile > @@ -91,6 +91,7 @@ obj-$(CONFIG_SENSORS_MAX6639) += max6639.o > obj-$(CONFIG_SENSORS_MAX6642)+= max6642.o > obj-$(CONFIG_SENSORS_MAX6650)+= max6650.o > obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o > +obj-$(CONFIG_SENSORS_OMAP_BANDGAP_TEMP_SENSOR) += omap_temp_sensor.o > obj-$(CONFIG_SENSORS_PC87360)+= pc87360.o > obj-$(CONFIG_SENSORS_PC87427)+= pc87427.o > obj-$(CONFIG_SENSORS_PCF8591)+= pcf8591.o > diff --git a/drivers/hwmon/omap_temp_sensor.c > b/drivers/hwmon/omap_temp_sensor.c > new file mode 100644 > index 000..15e2559 > --- /dev/null > +++ b/drivers/hwmon/omap_temp_sensor.c > @@ -0,0 +1,950 @@ > +/* > + * OMAP4 Temperature sensor driver file > + * > + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/ > + * Author: J Keerthy > + * Author: Moiz Sonasath > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * version 2 as published by the Free Software Foundation. > + * > + * This program is distributed in the hope that it will be useful, but > + * WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA > + * 02110-1301 USA > + * > + */ > + > +#include > +#include why ?? > +#include > +#include why ?? > +#include > +#include > +#include > +#include > +#include why ?? > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include why ? > +#include why ? > +#include why ? > +#include linux/gpio.h for crying out loud... how many times Russell has to say the exact same thing ?? > +#define TSHUT_THRESHOLD_HOT 122000 /* 122 deg C */ > +#define TSHUT_THRESHOLD_COLD 10 /* 100 deg C */ > +#define BGAP_THRESHOLD_T_HOT 73000 /* 73 deg C */ > +#define BGAP_THRESHOLD_T_COLD71000 /* 71 deg C */ > +#define OMAP_ADC_START_VALUE 530 > +#define OMAP_ADC_END_VALUE 923 > + > +/* > + * omap_temp_sensor structure > + * @hwmon_dev - device pointer > + * @clock - Clock pointer > + * @registers - Pointer to structure with register offsets and bitfields > + * @sensor_mutex - Mutex for sysfs, irq and PM > + * @irq - MPU Irq number for thermal alert > + * @phy_base - Physical base of the temp I/O > + * @clk_rate - Holds current clock rate > + * @temp_sensor_ctrl - temp sensor control register value > + * @bg_ctrl - bandgap ctrl register value > + * @bg_counter - bandgap counter
Re: [RFC/PATCH 12/14] dt: omap3: beagle board: set clock freq for i2c devices
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
Update omap3 beagle dts file with required clock frequencies for the i2c
client devices existing on beagle board.
Beagle custom board dts file is cleaned up so that it can coexist with omap3
soc dts file.
Signed-off-by: G, Manjunath Kondaiah
---
arch/arm/boot/dts/omap3-beagle-nunchuck.dts | 11 +--
arch/arm/boot/dts/omap3-beagle.dts | 18 +++---
2 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
b/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
index 2607be5..324ff86 100644
--- a/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
+++ b/arch/arm/boot/dts/omap3-beagle-nunchuck.dts
@@ -1,16 +1,7 @@
/include/ "omap3-beagle.dts"
/ {
- i2c@48072000 {
- compatible = "ti,omap3-i2c";
- reg =<0x48072000 0x80>;
- #address-cells =<1>;
- #size-cells =<0>;
-
- eeprom@50 {
- compatible = "at,at24c01";
- reg =< 0x50>;
- };
This change should probably not be there.
+ i2c@2 {
joystick@52 {
compatible = "sparkfun,wiichuck";
It looks like someone is having fun with a beagle connected to a Wii
nunchuck:-)
reg =< 0x52>;
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 4439466..49a5ac7 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -1,7 +1,19 @@
-/dts-v1/;
-/include/ "skeleton.dtsi"
+/include/ "omap3-soc.dtsi"
There is no need for the "-soc" postfix, otherwise all the other SoCs
inside DTS directory should have it.
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: [RFC PATCH 4/6] OMAP4: Temperature sensor device support
* Felipe Balbi [110810 05:31]:
>
> On Wed, Aug 10, 2011 at 05:55:20PM +0530, Keerthy wrote:
> > +
> > +int __init omap_devinit_temp_sensor(void)
> > +{
> > + if (!cpu_is_omap446x())
> > + return 0;
> > +
> > + return omap_hwmod_for_each_by_class("temperature_sensor",
> > + temp_sensor_dev_init, NULL);
> > +}
> > +
> > +arch_initcall(omap_devinit_temp_sensor);
>
> I really dislike people adding more and more *initcall() to their pieces
> of code. But Tony is the final Judge.
Yes how about making this just a regular device driver and have it
live under drivers/ somewhere?
Or is there some reason why this could not be a loadable module?
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 5/6] OMAP4460: Temperature sensor data
Hi,
On Wed, Aug 10, 2011 at 05:55:21PM +0530, Keerthy wrote:
> The register set and the
> bit fields might vary across OMAP versions. Hence
> creating a structure comprising of all the registers
> and bit fields to make the driver uniform for all the
> versions with different register sets. The data file
> contains the structure populated with register offsets
> and bit fields corresponding to OMAP4460 on die sensor.
>
> Signed-off-by: Keerthy
> ---
> arch/arm/mach-omap2/temp_sensor4460_data.c | 63
>
> 1 files changed, 63 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-omap2/temp_sensor4460_data.c
>
> diff --git a/arch/arm/mach-omap2/temp_sensor4460_data.c
> b/arch/arm/mach-omap2/temp_sensor4460_data.c
> new file mode 100644
> index 000..294963d
> --- /dev/null
> +++ b/arch/arm/mach-omap2/temp_sensor4460_data.c
> @@ -0,0 +1,63 @@
> +/*
> + * OMAP4460 on die Temperature sensor data file
> + *
> + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
> + * Author: J Keerthy
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
> + * 02110-1301 USA
> + *
> + */
> +
> +#include
> +#include "control.h"
> +#include
> +
> +/*
> + * OMAP4460 has one instance of thermal sensor for MPU
> + * need to describe the individual bit fields
> + */
> +struct omap_temp_sensor_registers omap_mpu_temp_sensor_registers = {
this is used on previous patch, so you have a compilation error.
--
balbi
signature.asc
Description: Digital signature
Re: [RFC/PATCH 11/14] dt: omap3: add soc file for handling i2c controllers
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
Add omap3 soc file for handling omap3 soc i2c controllers existing
on l4-core bus.
Signed-off-by: G, Manjunath Kondaiah
---
arch/arm/boot/dts/omap3-soc.dtsi | 62 ++
1 files changed, 62 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-soc.dtsi
diff --git a/arch/arm/boot/dts/omap3-soc.dtsi b/arch/arm/boot/dts/omap3-soc.dtsi
new file mode 100644
index 000..85de92f
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-soc.dtsi
@@ -0,0 +1,62 @@
+/*
+ * Device Tree Source for OMAP3 SoC
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ "skeleton.dtsi"
+
+/ {
+ #address-cells =<1>;
+ #size-cells =<1>;
+ model = "ti,omap3";
+
+ aliases {
+ i2c1 =&i2c1;
+ i2c2 =&i2c2;
+ i2c3 =&i2c3;
+ };
+
+ l4-core {
That comment is probably subject to discussion, but even if this
interconnect is there physically, I'm not sure of the added value to add it.
It will add an extra level of indentation and that all. Moreover, it
will mess up the physical address that are expressed using absolute
value in the TRM with a less readable offset value.
In fact, most DTS files in the ARM directory are using a purely flat
representation of the interconnect.
+ compatible = "ti,omap3-l4-core";
Assuming we will keep that, you should probably add a more generic
compatible name after that one. Like "ti,s3220" or even "sonics,s3220",
assuming that this IP is generic enough for other SoC.
+ #address-cells =<1>;
+ #size-cells =<1>;
+ ranges =<0 0x4800 0x100>;
+
+ i2c1: i2c@7 {
+ #address-cells =<1>;
+ #size-cells =<0>;
+ compatible = "ti,omap3-i2c";
The I2C IP and thus the driver is generic across OMAP generations and is
even potentially used by other non-OMAP TI chips like DSP or Davinci. So
having an extra compatible entry with "ti,i2c" or "ti, omap-i2c" seems
mandatory.
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: [RFC PATCH 4/6] OMAP4: Temperature sensor device support
Hi,
(you should Cc Tony, as he's OMAP maintainer)
On Wed, Aug 10, 2011 at 05:55:20PM +0530, Keerthy wrote:
> The device file adds the device support for OMAP4
> on die temperature sensor.
>
> Signed-off-by: Keerthy
> ---
> arch/arm/mach-omap2/Makefile |3 +-
> arch/arm/mach-omap2/temp_sensor_device.c | 85 +++
> arch/arm/plat-omap/Kconfig | 12 +++
> .../plat-omap/include/plat/temperature_sensor.h| 87
>
> 4 files changed, 186 insertions(+), 1 deletions(-)
> create mode 100644 arch/arm/mach-omap2/temp_sensor_device.c
> create mode 100644 arch/arm/plat-omap/include/plat/temperature_sensor.h
>
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index fb02937..5812fb4 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -18,6 +18,7 @@ obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common)
>
> obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
>
> +obj-$(CONFIG_OMAP_TEMP_SENSOR) += temp_sensor_device.o
> obj-$(CONFIG_TWL4030_CORE) += omap_twl.o
>
> # SMP support ONLY available for OMAP4
> @@ -86,7 +87,7 @@ obj-$(CONFIG_ARCH_OMAP3)+= prcm.o cm2xxx_3xxx.o
> prm2xxx_3xxx.o \
> obj-$(CONFIG_ARCH_OMAP4) += prcm.o cm2xxx_3xxx.o cminst44xx.o \
> cm44xx.o prcm_mpu44xx.o \
> prminst44xx.o vc44xx_data.o \
> -vp44xx_data.o
> +vp44xx_data.o temp_sensor4460_data.o
>
> # OMAP voltage domains
> ifeq ($(CONFIG_PM),y)
> diff --git a/arch/arm/mach-omap2/temp_sensor_device.c
> b/arch/arm/mach-omap2/temp_sensor_device.c
> new file mode 100644
> index 000..5d5e92f
> --- /dev/null
> +++ b/arch/arm/mach-omap2/temp_sensor_device.c
> @@ -0,0 +1,85 @@
> +/*
> + * OMAP on die Temperature sensor device file
> + *
> + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
> + * Author: J Keerthy
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
> + * 02110-1301 USA
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "control.h"
> +#include "pm.h"
> +#include
> +
> +static struct omap_device_pm_latency omap_temp_sensor_latency[] = {
> + {
> + .deactivate_func = omap_device_idle_hwmods,
> + .activate_func = omap_device_enable_hwmods,
> + .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
> + }
wrong indentation.
> +};
> +
> +static int temp_sensor_dev_init(struct omap_hwmod *oh, void *user)
> +{
> + struct omap_temp_sensor_pdata *temp_sensor_pdata;
> + struct omap_device *od;
> + struct omap_temp_sensor_dev_attr *temp_sensor_dev_attr;
> + int ret;
> + static int device_count;
use an IDR here (see include/linux/idr.h)
> + ret = 0;
initialize on the declarion and you can avoid this line.
> + temp_sensor_pdata =
> + kzalloc(sizeof(*temp_sensor_pdata), GFP_KERNEL);
> + if (!temp_sensor_pdata) {
> + dev_err(&oh->od->pdev.dev,
> + "Unable to allocate memory for temp sensor pdata\n");
> + return -ENOMEM;
> + }
> +
> + temp_sensor_dev_attr = oh->dev_attr;
> + if (!strcmp(temp_sensor_dev_attr->name, "mpu"))
> + temp_sensor_pdata->registers = &omap_mpu_temp_sensor_registers;
> +
> + od = omap_device_build("omap_temp_sensor", device_count++,
> + oh, temp_sensor_pdata, sizeof(*temp_sensor_pdata),
> +omap_temp_sensor_latency,
> + ARRAY_SIZE(omap_temp_sensor_latency), 0);
> + if (IS_ERR(od)) {
> + dev_warn(&oh->od->pdev.dev,
> + "Could not build omap_device for %s\n", oh->name);
> + ret = PTR_ERR(od);
> + }
> +
> + kfree(temp_sensor_pdata);
> +
> + return ret;
> +}
> +
> +int __init omap_devinit_temp_sensor(void)
> +{
> + if (!cpu_is_omap446x())
> + return 0;
> +
> + return omap_hwmod_for_each_by_class("temperature_sensor",
> + temp_sensor_dev_init, NULL);
> +}
> +
> +arch_initcall(omap_devinit_temp_sensor);
I really dislike people adding more
[RFC PATCH 1/6] OMAP4: Clock: Associate clocks for OMAP temperature sensor
div_ts_ck feeds only the temperature sensor functional clock
and also has a clksel associated (for divider selection). Mapping this
as the functional clock for the temperature sensor in clkdev table,
so a clk_set_rate() in the driver would have the effect of changing the
temperature sensor clock rate indirectly.
Reviewd-by: Rajendra Nayak
Signed-off-by: Keerthy
---
arch/arm/mach-omap2/clock44xx_data.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 2af0e3f..4a788f4 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3187,7 +3187,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, "bandgap_fclk", &bandgap_fclk,
CK_443X),
CLK(NULL, "bandgap_ts_fclk", &bandgap_ts_fclk,
CK_446X),
CLK(NULL, "des3des_fck", &des3des_fck,
CK_443X),
- CLK(NULL, "div_ts_ck",&div_ts_ck,
CK_446X),
+ CLK("omap_temp_sensor.0", "fck", &div_ts_ck,
CK_446X),
CLK(NULL, "dmic_sync_mux_ck", &dmic_sync_mux_ck,
CK_443X),
CLK(NULL, "dmic_fck", &dmic_fck,
CK_443X),
CLK(NULL, "dsp_fck", &dsp_fck,
CK_443X),
--
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
[RFC PATCH 5/6] OMAP4460: Temperature sensor data
The register set and the
bit fields might vary across OMAP versions. Hence
creating a structure comprising of all the registers
and bit fields to make the driver uniform for all the
versions with different register sets. The data file
contains the structure populated with register offsets
and bit fields corresponding to OMAP4460 on die sensor.
Signed-off-by: Keerthy
---
arch/arm/mach-omap2/temp_sensor4460_data.c | 63
1 files changed, 63 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/temp_sensor4460_data.c
diff --git a/arch/arm/mach-omap2/temp_sensor4460_data.c
b/arch/arm/mach-omap2/temp_sensor4460_data.c
new file mode 100644
index 000..294963d
--- /dev/null
+++ b/arch/arm/mach-omap2/temp_sensor4460_data.c
@@ -0,0 +1,63 @@
+/*
+ * OMAP4460 on die Temperature sensor data file
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: J Keerthy
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include
+#include "control.h"
+#include
+
+/*
+ * OMAP4460 has one instance of thermal sensor for MPU
+ * need to describe the individual bit fields
+ */
+struct omap_temp_sensor_registers omap_mpu_temp_sensor_registers = {
+ .temp_sensor_ctrl = OMAP4460_TEMP_SENSOR_CTRL_OFFSET,
+ .bgap_tempsoff_mask = OMAP4460_BGAP_TEMPSOFF_MASK,
+ .bgap_soc_mask = OMAP4460_BGAP_TEMP_SENSOR_SOC_MASK,
+ .bgap_eocz_mask = OMAP4460_BGAP_TEMP_SENSOR_EOCZ_MASK,
+ .bgap_dtemp_mask= OMAP4460_BGAP_TEMP_SENSOR_DTEMP_MASK,
+
+ .bgap_mask_ctrl = OMAP4460_BGAP_CTRL_OFFSET,
+ .mask_hot_mask = OMAP4460_MASK_HOT_MASK,
+ .mask_cold_mask = OMAP4460_MASK_COLD_MASK,
+
+ .bgap_mode_ctrl = OMAP4460_BGAP_CTRL_OFFSET,
+ .mode_ctrl_mask = OMAP4460_SINGLE_MODE_MASK,
+
+ .bgap_counter = OMAP4460_BGAP_COUNTER_OFFSET,
+ .counter_mask = OMAP4460_COUNTER_MASK,
+
+ .bgap_threshold = OMAP4460_BGAP_THRESHOLD_OFFSET,
+ .threshold_thot_mask= OMAP4460_T_HOT_MASK,
+ .threshold_tcold_mask = OMAP4460_T_COLD_MASK,
+
+ .thsut_threshold= OMAP4460_BGAP_TSHUT_OFFSET,
+ .tshut_hot_mask = OMAP4460_TSHUT_HOT_MASK,
+ .tshut_cold_mask= OMAP4460_TSHUT_COLD_MASK,
+
+ .bgap_status= OMAP4460_BGAP_STATUS_OFFSET,
+ .status_clean_stop_mask = OMAP4460_CLEAN_STOP_MASK,
+ .status_bgap_alert_mask = OMAP4460_BGAP_ALERT_MASK,
+ .status_hot_mask= OMAP4460_HOT_FLAG_MASK,
+ .status_cold_mask = OMAP4460_COLD_FLAG_MASK,
+
+ .bgap_efuse = OMAP4460_FUSE_OPP_BGAP,
+};
--
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
[RFC PATCH 4/6] OMAP4: Temperature sensor device support
The device file adds the device support for OMAP4
on die temperature sensor.
Signed-off-by: Keerthy
---
arch/arm/mach-omap2/Makefile |3 +-
arch/arm/mach-omap2/temp_sensor_device.c | 85 +++
arch/arm/plat-omap/Kconfig | 12 +++
.../plat-omap/include/plat/temperature_sensor.h| 87
4 files changed, 186 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/temp_sensor_device.c
create mode 100644 arch/arm/plat-omap/include/plat/temperature_sensor.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fb02937..5812fb4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common)
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
+obj-$(CONFIG_OMAP_TEMP_SENSOR) += temp_sensor_device.o
obj-$(CONFIG_TWL4030_CORE) += omap_twl.o
# SMP support ONLY available for OMAP4
@@ -86,7 +87,7 @@ obj-$(CONFIG_ARCH_OMAP3) += prcm.o cm2xxx_3xxx.o
prm2xxx_3xxx.o \
obj-$(CONFIG_ARCH_OMAP4) += prcm.o cm2xxx_3xxx.o cminst44xx.o \
cm44xx.o prcm_mpu44xx.o \
prminst44xx.o vc44xx_data.o \
- vp44xx_data.o
+ vp44xx_data.o temp_sensor4460_data.o
# OMAP voltage domains
ifeq ($(CONFIG_PM),y)
diff --git a/arch/arm/mach-omap2/temp_sensor_device.c
b/arch/arm/mach-omap2/temp_sensor_device.c
new file mode 100644
index 000..5d5e92f
--- /dev/null
+++ b/arch/arm/mach-omap2/temp_sensor_device.c
@@ -0,0 +1,85 @@
+/*
+ * OMAP on die Temperature sensor device file
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: J Keerthy
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "control.h"
+#include "pm.h"
+#include
+
+static struct omap_device_pm_latency omap_temp_sensor_latency[] = {
+ {
+.deactivate_func = omap_device_idle_hwmods,
+.activate_func = omap_device_enable_hwmods,
+.flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+ }
+};
+
+static int temp_sensor_dev_init(struct omap_hwmod *oh, void *user)
+{
+ struct omap_temp_sensor_pdata *temp_sensor_pdata;
+ struct omap_device *od;
+ struct omap_temp_sensor_dev_attr *temp_sensor_dev_attr;
+ int ret;
+ static int device_count;
+
+ ret = 0;
+ temp_sensor_pdata =
+ kzalloc(sizeof(*temp_sensor_pdata), GFP_KERNEL);
+ if (!temp_sensor_pdata) {
+ dev_err(&oh->od->pdev.dev,
+ "Unable to allocate memory for temp sensor pdata\n");
+ return -ENOMEM;
+ }
+
+ temp_sensor_dev_attr = oh->dev_attr;
+ if (!strcmp(temp_sensor_dev_attr->name, "mpu"))
+ temp_sensor_pdata->registers = &omap_mpu_temp_sensor_registers;
+
+ od = omap_device_build("omap_temp_sensor", device_count++,
+ oh, temp_sensor_pdata, sizeof(*temp_sensor_pdata),
+ omap_temp_sensor_latency,
+ ARRAY_SIZE(omap_temp_sensor_latency), 0);
+ if (IS_ERR(od)) {
+ dev_warn(&oh->od->pdev.dev,
+ "Could not build omap_device for %s\n", oh->name);
+ ret = PTR_ERR(od);
+ }
+
+ kfree(temp_sensor_pdata);
+
+ return ret;
+}
+
+int __init omap_devinit_temp_sensor(void)
+{
+ if (!cpu_is_omap446x())
+ return 0;
+
+ return omap_hwmod_for_each_by_class("temperature_sensor",
+ temp_sensor_dev_init, NULL);
+}
+
+arch_initcall(omap_devinit_temp_sensor);
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 6e6735f..8fd8e80 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -115,6 +115,18 @@ config OMAP_MCBSP
Say Y here if you want support for the OMAP Multichannel
Buffered Serial Port.
+config OMAP_TEMP_SENSOR
+ bool "OMAP Temp Sensor Support"
+ depends on ARCH_OMAP
+ default n
+ help
+
[RFC PATCH 0/6] OMAP4: Temperature sensor driver
Hello, The rfc patch series for the on die temperature sensor driver. I need feedback on the overall structure of the driver. The rfc patch set has the device file, omap4 on die temperature sensor hwmon driver. hwmod, clk support. The patch set compiles on top of LO tree Master branch. This patch series is tested for boot-up on OMAP4460. The temperature reading and the interrupts generation on crossing the temperature thresholds also tested. Keerthy (6): OMAP4: Clock: Associate clocks for OMAP temperature sensor OMAP4: Adding the temperature sensor register set bit fields OMAP4: Hwmod: OMAP temperature sensor OMAP4: Temperature sensor device support OMAP4460: Temperature sensor data OMAP4: On die temperature sensor driver arch/arm/mach-omap2/Makefile |3 +- arch/arm/mach-omap2/clock44xx_data.c |2 +- .../include/mach/ctrl_module_core_44xx.h | 70 ++- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 61 ++ arch/arm/mach-omap2/temp_sensor4460_data.c | 63 ++ arch/arm/mach-omap2/temp_sensor_device.c | 85 ++ arch/arm/plat-omap/Kconfig | 12 + .../plat-omap/include/plat/temperature_sensor.h| 87 ++ drivers/hwmon/Kconfig | 11 + drivers/hwmon/Makefile |1 + drivers/hwmon/omap_temp_sensor.c | 950 11 files changed, 1330 insertions(+), 15 deletions(-) create mode 100644 arch/arm/mach-omap2/temp_sensor4460_data.c create mode 100644 arch/arm/mach-omap2/temp_sensor_device.c create mode 100644 arch/arm/plat-omap/include/plat/temperature_sensor.h create mode 100644 drivers/hwmon/omap_temp_sensor.c -- 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/6] OMAP4: Adding the temperature sensor register set bit fields
OMAP4460 specific temperature sensor register bit fields are added. Signed-off-by: Keerthy --- .../include/mach/ctrl_module_core_44xx.h | 70 1 files changed, 57 insertions(+), 13 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/ctrl_module_core_44xx.h b/arch/arm/mach-omap2/include/mach/ctrl_module_core_44xx.h index 2f7ac70..725c1e1 100644 --- a/arch/arm/mach-omap2/include/mach/ctrl_module_core_44xx.h +++ b/arch/arm/mach-omap2/include/mach/ctrl_module_core_44xx.h @@ -256,19 +256,63 @@ #define OMAP4_LDOSRAMCORE_ACTMODE_VSET_OUT_SHIFT 0 #define OMAP4_LDOSRAMCORE_ACTMODE_VSET_OUT_MASK(0x1f << 0) -/* TEMP_SENSOR */ -#define OMAP4_BGAP_TEMPSOFF_SHIFT 12 -#define OMAP4_BGAP_TEMPSOFF_MASK (1 << 12) -#define OMAP4_BGAP_TSHUT_SHIFT 11 -#define OMAP4_BGAP_TSHUT_MASK (1 << 11) -#define OMAP4_BGAP_TEMP_SENSOR_CONTCONV_SHIFT 10 -#define OMAP4_BGAP_TEMP_SENSOR_CONTCONV_MASK (1 << 10) -#define OMAP4_BGAP_TEMP_SENSOR_SOC_SHIFT 9 -#define OMAP4_BGAP_TEMP_SENSOR_SOC_MASK(1 << 9) -#define OMAP4_BGAP_TEMP_SENSOR_EOCZ_SHIFT 8 -#define OMAP4_BGAP_TEMP_SENSOR_EOCZ_MASK (1 << 8) -#define OMAP4_BGAP_TEMP_SENSOR_DTEMP_SHIFT 0 -#define OMAP4_BGAP_TEMP_SENSOR_DTEMP_MASK (0xff << 0) +/* TEMP_SENSOR OMAP4430 */ +#define OMAP4430_BGAP_TEMPSOFF_SHIFT 12 +#define OMAP4430_BGAP_TEMPSOFF_MASK(1 << 12) +#define OMAP4430_BGAP_TSHUT_SHIFT 11 +#define OMAP4430_BGAP_TSHUT_MASK (1 << 11) +#define OMAP4430_BGAP_TEMP_SENSOR_CONTCONV_SHIFT 10 +#define OMAP4430_BGAP_TEMP_SENSOR_CONTCONV_MASK(1 << 10) +#define OMAP4430_BGAP_TEMP_SENSOR_SOC_SHIFT9 +#define OMAP4430_BGAP_TEMP_SENSOR_SOC_MASK (1 << 9) +#define OMAP4430_BGAP_TEMP_SENSOR_EOCZ_SHIFT 8 +#define OMAP4430_BGAP_TEMP_SENSOR_EOCZ_MASK(1 << 8) +#define OMAP4430_BGAP_TEMP_SENSOR_DTEMP_SHIFT 0 +#define OMAP4430_BGAP_TEMP_SENSOR_DTEMP_MASK (0x3ff << 0) + +/* TEMP_SENSOR OMAP4460 */ +#define OMAP4460_BGAP_TEMPSOFF_SHIFT 13 +#define OMAP4460_BGAP_TEMPSOFF_MASK(1 << 13) +#define OMAP4460_BGAP_TEMP_SENSOR_SOC_SHIFT11 +#define OMAP4460_BGAP_TEMP_SENSOR_SOC_MASK (1 << 11) +#define OMAP4460_BGAP_TEMP_SENSOR_EOCZ_SHIFT 10 +#define OMAP4460_BGAP_TEMP_SENSOR_EOCZ_MASK(1 << 10) +#define OMAP4460_BGAP_TEMP_SENSOR_DTEMP_SHIFT 0 +#define OMAP4460_BGAP_TEMP_SENSOR_DTEMP_MASK (0x3ff << 0) + +/* BANDGAP_CTRL */ +#define OMAP4460_SINGLE_MODE_SHIFT 31 +#define OMAP4460_SINGLE_MODE_MASK (1 << 31) +#define OMAP4460_MASK_HOT_SHIFT1 +#define OMAP4460_MASK_HOT_MASK (1 << 1) +#define OMAP4460_MASK_COLD_SHIFT 0 +#define OMAP4460_MASK_COLD_MASK(1 << 0) + +/* BANDGAP_COUNTER */ +#define OMAP4460_COUNTER_SHIFT 0 +#define OMAP4460_COUNTER_MASK (0xff << 0) + +/* BANDGAP_THRESHOLD */ +#define OMAP4460_T_HOT_SHIFT 16 +#define OMAP4460_T_HOT_MASK(0x3ff << 16) +#define OMAP4460_T_COLD_SHIFT 0 +#define OMAP4460_T_COLD_MASK (0x3ff << 0) + +/* TSHUT_THRESHOLD */ +#define OMAP4460_TSHUT_HOT_SHIFT 16 +#define OMAP4460_TSHUT_HOT_MASK(0x3ff << 16) +#define OMAP4460_TSHUT_COLD_SHIFT 0 +#define OMAP4460_TSHUT_COLD_MASK (0x3ff << 0) + +/* BANDGAP_STATUS */ +#define OMAP4460_CLEAN_STOP_SHIFT 3 +#define OMAP4460_CLEAN_STOP_MASK (1 << 3) +#define OMAP4460_BGAP_ALERT_SHIFT 2 +#define OMAP4460_BGAP_ALERT_MASK (1 << 2) +#define OMAP4460_HOT_FLAG_SHIFT1 +#define OMAP4460_HOT_FLAG_MASK (1 << 1) +#define OMAP4460_COLD_FLAG_SHIFT 0 +#define OMAP4460_COLD_FLAG_MASK(1 << 0) /* DPLL_NWELL_TRIM_0 */ #define OMAP4_DPLL_ABE_NWELL_TRIM_MUX_CTRL_SHIFT 29 -- 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
[RFC PATCH 3/6] OMAP4: Hwmod: OMAP temperature sensor
From: Benoit Cousson
OMAP4460 temperature sensor hwmod cannot be auto generated
since it is part of ctrl module. Hence populating the
necessary hwmod info manually.
Signed-off-by: Benoit Cousson
Signed-off-by: Keerthy
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 61
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6201422..28bf6d3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include "omap_hwmod_common_data.h"
@@ -832,6 +833,63 @@ static struct omap_hwmod omap44xx_aess_hwmod = {
};
/*
+ * 'temperature_sensor' class
+ * temperature sensor module inside the bandgap / control module
+ */
+
+static struct omap_hwmod_class omap44xx_temperature_sensor_hwmod_class = {
+ .name = "temperature_sensor",
+};
+
+static struct omap_hwmod_irq_info omap44xx_temperature_sensor_irqs[] = {
+ { .name = "thermal_alert", .irq = 126 + OMAP44XX_IRQ_GIC_START },
+};
+
+static struct omap_hwmod_addr_space omap44xx_temperature_sensor_addrs[] = {
+ {
+ .pa_start = 0x4a00232c,
+ .pa_end = 0x4a00238b,
+ },
+};
+
+static struct omap_hwmod omap44xx_temperature_sensor_hwmod;
+/* l4_cfg -> ctrl_module_core */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__temperature_sensor = {
+ .master = &omap44xx_l4_cfg_hwmod,
+ .slave = &omap44xx_temperature_sensor_hwmod,
+ .clk= "l4_div_ck",
+ .addr = omap44xx_temperature_sensor_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* ctrl_module_core slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_temperature_sensor_slaves[] = {
+ &omap44xx_l4_cfg__temperature_sensor,
+};
+
+/* temperature sensor dev_attr */
+static struct omap_temp_sensor_dev_attr temp_sensor_dev_attr = {
+ .name = "mpu",
+};
+
+static struct omap_hwmod omap44xx_temperature_sensor_hwmod = {
+ .name = "temperature_sensor_mpu",
+ .class = &omap44xx_temperature_sensor_hwmod_class,
+ .mpu_irqs = omap44xx_temperature_sensor_irqs,
+ .main_clk = "bandgap_ts_fclk",
+ .slaves = omap44xx_temperature_sensor_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_temperature_sensor_slaves),
+ .clkdm_name = "l4_wkup_clkdm",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_WKUP_BANDGAP_CLKCTRL_OFFSET,
+ },
+ },
+ .dev_attr = &temp_sensor_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/*
* 'bandgap' class
* bangap reference for ldo regulators
*/
@@ -5469,6 +5527,9 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
&omap44xx_timer10_hwmod,
&omap44xx_timer11_hwmod,
+ /* temperature sensor hwmod */
+ &omap44xx_temperature_sensor_hwmod,
+
/* uart class */
&omap44xx_uart1_hwmod,
&omap44xx_uart2_hwmod,
--
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] omap: timer: Set dmtimer used as clocksource in autoreload mode
Tony Lindgren wrote on Wednesday, August 10, 2011 5:21 PM:
> * Hemant Pedanekar [110809 20:46]:
>> If CONFIG_OMAP_32K_TIMER is not selected and dmtimer is used as
>> clocksource, the timer stops counting once overflow occurs as it was not
>> set in autoreload mode. This results into timekeeping failure: for
>> example, 'sleep 1' at the shell after the timer counter overflow would
>> hang.
>>
>> This patch sets up autoreload when starting the clocksource timer which
>> fixes the above issue.
>>
>> Signed-off-by: Hemant Pedanekar
>> ---
>> arch/arm/mach-omap2/timer.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
>> index e964072..796b935 100644 --- a/arch/arm/mach-omap2/timer.c
>> +++ b/arch/arm/mach-omap2/timer.c
>> @@ -293,7 +293,7 @@ static void __init
> omap2_gp_clocksource_init(int gptimer_id,
>> pr_info("OMAP clocksource: GPTIMER%d at %lu Hz\n",
>> gptimer_id,
>> clksrc.rate);
>>
>> -__omap_dm_timer_load_start(clksrc.io_base, OMAP_TIMER_CTRL_ST, 0, 1);
>> +omap_dm_timer_set_load_start(&clksrc, 1, 0);
>> init_sched_clock(&cd, dmtimer_update_sched_clock, 32, clksrc.rate);
>>
>> if (clocksource_register_hz(&clocksource_gpt, clksrc.rate))
>
> You should be able to just set the autoreload mode by changing to use
> OMAP_TIMER_CTRL_POSTED | OMAP_TIMER_CTRL_AR in the
> __omap_dm_timer_load_start
> above.
>
> This avoids calling something that might be a loadable module eventually.
>
> Regards,
>
> Tony
Yes, that would be better - I didn't think about loadable module option.
Thanks.
Hemant--
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/6] hwmon: OMAP4: On die temperature sensor driver
On chip temperature sensor driver. The driver monitors the temperature of
the MPU subsystem of the OMAP4. It sends notifications to the user space if
the temperature crosses user defined thresholds via kobject_uevent interface.
The user is allowed to configure the temperature thresholds vis sysfs nodes
exposed using hwmon interface.
Signed-off-by: Keerthy
---
drivers/hwmon/Kconfig| 11 +
drivers/hwmon/Makefile |1 +
drivers/hwmon/omap_temp_sensor.c | 950 ++
3 files changed, 962 insertions(+), 0 deletions(-)
create mode 100644 drivers/hwmon/omap_temp_sensor.c
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 5f888f7..9c9cd8b 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -323,6 +323,17 @@ config SENSORS_F71805F
This driver can also be built as a module. If so, the module
will be called f71805f.
+config SENSORS_OMAP_BANDGAP_TEMP_SENSOR
+ bool "OMAP on-die temperature sensor hwmon driver"
+ depends on HWMON && ARCH_OMAP && OMAP_TEMP_SENSOR
+ help
+ If you say yes here you get support for hardware
+ monitoring features of the OMAP on die temperature
+ sensor.
+
+ Continuous conversion programmable delay
+ mode is used for temperature conversion.
+
config SENSORS_F71882FG
tristate "Fintek F71882FG and compatibles"
help
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 28061cf..d0f89f5 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -91,6 +91,7 @@ obj-$(CONFIG_SENSORS_MAX6639) += max6639.o
obj-$(CONFIG_SENSORS_MAX6642) += max6642.o
obj-$(CONFIG_SENSORS_MAX6650) += max6650.o
obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o
+obj-$(CONFIG_SENSORS_OMAP_BANDGAP_TEMP_SENSOR) += omap_temp_sensor.o
obj-$(CONFIG_SENSORS_PC87360) += pc87360.o
obj-$(CONFIG_SENSORS_PC87427) += pc87427.o
obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
diff --git a/drivers/hwmon/omap_temp_sensor.c b/drivers/hwmon/omap_temp_sensor.c
new file mode 100644
index 000..15e2559
--- /dev/null
+++ b/drivers/hwmon/omap_temp_sensor.c
@@ -0,0 +1,950 @@
+/*
+ * OMAP4 Temperature sensor driver file
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: J Keerthy
+ * Author: Moiz Sonasath
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define TSHUT_THRESHOLD_HOT122000 /* 122 deg C */
+#define TSHUT_THRESHOLD_COLD 10 /* 100 deg C */
+#define BGAP_THRESHOLD_T_HOT 73000 /* 73 deg C */
+#define BGAP_THRESHOLD_T_COLD 71000 /* 71 deg C */
+#define OMAP_ADC_START_VALUE 530
+#define OMAP_ADC_END_VALUE 923
+
+/*
+ * omap_temp_sensor structure
+ * @hwmon_dev - device pointer
+ * @clock - Clock pointer
+ * @registers - Pointer to structure with register offsets and bitfields
+ * @sensor_mutex - Mutex for sysfs, irq and PM
+ * @irq - MPU Irq number for thermal alert
+ * @phy_base - Physical base of the temp I/O
+ * @clk_rate - Holds current clock rate
+ * @temp_sensor_ctrl - temp sensor control register value
+ * @bg_ctrl - bandgap ctrl register value
+ * @bg_counter - bandgap counter value
+ * @bg_threshold - bandgap threshold register value
+ * @temp_sensor_tshut_threshold - bandgap tshut register value
+ * @is_efuse_valid - Flag to determine if efuse is valid or not
+ * @clk_on - Manages the current clock state
+ */
+struct omap_temp_sensor {
+ struct device *hwmon_dev;
+ struct clk *clock;
+ struct omap_temp_sensor_registers *registers;
+ struct mutexsensor_mutex; /* Mutex for sysfs, irq and PM */
+ unsigned intirq;
+ void __iomem*phy_base;
+ u32 clk_rate;
+ u32 temp_sensor_ctrl;
+ u32 bg_ctrl;
+ u32 bg_counter;
+ u32 bg_threshold;
+ u32 temp_sensor_tshut_threshold;
+ boolis_efuse_valid;
+
Re: Remaining omap pull requests
* Kevin Hilman [110802 17:00]: > On 08/02/2011 04:14 PM, Kevin Hilman wrote: > [...] > >> > >>Looks like I forgot the i2c driver changes that also should be > >>merged by us. Those are acked by Ben Dooks, Kevin's pull request > >>for that is at: > >> > >>http://marc.info/?l=linux-omap&m=131014213007667&w=2 > >> > > > >I thought this was already pulled, but looking now I see that this was > >never pulled into the arm-soc tree. > > > >Can you pull this for v3.1 please? I'll send a pull request for Ben Dooks for this as now the conflicting parts have been merged. > Oops, I had to rebase this branch as Paul had picked up a few of > these patches for his fixes (which are now part of > arm-soc/next/fixes2.) Updated pull request below. > > Also, I noticed there's a minor conflict with something coming from the > trivial tree[1]. Looks like i2c-andy-2 still fails to merge cleanly on top of v3.1-rc1. Will resolve for Ben and proxy the pull request while you're on vacation. Regards, Tony > The following changes since commit 6d3c55fd4f0f94a9455d30df9414ddb0f755f402: > > OMAP: hwmod: fix the i2c-reset timeout during bootup (2011-07-10 > 05:27:16 -0600) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git > for_3.1/i2c-andy-2 > > Andy Green (12): > I2C: OMAP2+: Name registers in I2C IP V2 only accordingly > I2C: OMAP: add rev to omap i2c platform data > I2C: OMAP1: set IP revision in platform data > I2C: OMAP2+: Pass hwmod rev knowledge via platform_data when > i2c bus added > I2C: OMAP2+: use platform_data ip revision to select register map > I2C: OMAP2+: Solve array bounds overflow error on i2c idle > I2C: OMAP2+: address confused probed version naming > I2C: OMAP1/OMAP2+: add flags field to omap i2c platform data > I2C: OMAP2+: Pass flags up to omap i2c platform_data as well > I2C: OMAP1: set i2c unit feature implementation flags in > platform data > I2C: OMAP2+: Convert omap I2C driver to use feature > implementation flags from platform data > I2C: OMAP1/OMAP2+: prepend I2C IP version to probed version > shown in dev_info > > arch/arm/plat-omap/i2c.c | 27 +++ > drivers/i2c/busses/i2c-omap.c | 100 > ++-- > include/linux/i2c-omap.h |2 + > 3 files changed, 84 insertions(+), 45 deletions(-) > > > [1] > commit 32575a9183c82a5ea0f9ed1bcf13c17189ea1118 > Author: Jesper Juhl > Date: Sat Jul 9 23:20:42 2011 +0200 > > drivers/i2c: static should be at beginning of declaration > > Make sure that the 'static' keywork is at the beginning of declaration > for drivers/i2c/busses/i2c-omap.c > > This gets rid of warnings like > warning: ‘static’ is not at beginning of declaration > when building with -Wold-style-declaration (and/or -Wextra which also > enables it). > > Signed-off-by: Jesper Juhl > Signed-off-by: Jiri Kosina -- 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: [RFC/PATCH 10/14] dt: Add pd_size to AUXDATA structure
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
Add pd_size in the AUXDATA structure so that device drivers which require
platform_data size can pass along with AUXDATA.
It is really needed by device driver? Or is it because omap_device_build
is using platform_device_add_data that is doing a copy of the pdata and
thus require the size?
Signed-off-by: G, Manjunath Kondaiah
---
drivers/of/platform.c |2 ++
include/linux/of_platform.h |5 +
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index ebbbf42..4b27286 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -565,6 +565,7 @@ static int of_platform_bus_create(struct device_node *bus,
struct platform_device *dev;
const char *bus_id = NULL;
void *platform_data = NULL;
+ int pd_size;
Maybe platform_data_size will be a little bit more consistent?
Regards,
Benoit
int id = -1;
int rc = 0;
@@ -588,6 +589,7 @@ static int of_platform_bus_create(struct device_node *bus,
bus_id = auxdata->name;
id = auxdata->id;
platform_data = auxdata->platform_data;
+ pd_size = auxdata->pd_size;
}
if (of_device_is_compatible(bus, "arm,primecell")) {
diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
index 252246c..a3be980 100644
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -47,6 +47,7 @@ struct of_dev_auxdata {
char *name;
int id;
void *platform_data;
+ int pd_size;
};
/* Macro to simplify populating a lookup table */
@@ -58,6 +59,10 @@ struct of_dev_auxdata {
{ .compatible = _compat, .phys_addr = _phys, .name = _name, \
.id = _id, .platform_data = _pdata }
+#define OF_DEV_AUXDATA_ID_PDSIZE(_compat,_phys,_name,_id,_pdata,_pd_size) \
+ { .compatible = _compat, .phys_addr = _phys, .name = _name, \
+ .id = _id, .platform_data = _pdata, .pd_size = _pd_size }
+
/**
* of_platform_driver - Legacy of-aware driver for platform devices.
*
--
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] OMAP3: am3517crane: remove NULL board_mux from board file
* Johan Hovold [110809 09:23]: > Since 7203f8a48bb63015ebe58a6f2a38aec1cb208b9d (arm: mach-omap2: remove > NULL board_mux from board files) NULL board_mux is defined in mux.h. Thanks applying to fixes. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: mach-omap2: mux: use kstrdup()
* Thomas Meyer [110806 02:24]: > From: Thomas Meyer > > Use kstrdup rather than duplicating its implementation Thanks applying to fixes. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 09/14] dt: omap: prepare hwmod to support dt
Hi Manju,
On 8/9/2011 4:10 PM, G, Manjunath Kondaiah wrote:
The omap dt requires new omap hwmod api to be added for in order
to support omap dt.
Both the subject and the changelog are misleading. You are not doing any
hwmod stuff in it.
You are just passing an "of_node" pointer during omap_device_build_ss.
The subject should start with OMAP: omap_device: because it does not
belong to the DT subsystem.
The same comment apply to most patches in that series.
The new api is added and new parameter "np" is added for existing
api.
I don't think np is not a super meaningful name. Some more explanation
are needed as well.
The users of hwmod api is changed accrodingly.
omap_device API + typo.
Build and boot tested on omap3 beagle for both dt and not dt build.
Signed-off-by: G, Manjunath Kondaiah
---
arch/arm/mach-omap2/devices.c |2 +-
arch/arm/mach-omap2/mcbsp.c |2 +-
arch/arm/plat-omap/include/plat/omap_device.h | 11 +-
arch/arm/plat-omap/omap_device.c | 53 ++---
4 files changed, 59 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 458f7be..d7ff1ae 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -92,7 +92,7 @@ static int __init omap4_l3_init(void)
pr_err("could not look up %s\n", oh_name);
}
- pdev = omap_device_build_ss("omap_l3_noc", 0, oh, 3, NULL,
+ pdev = omap_device_build_ss(NULL, "omap_l3_noc", 0, oh, 3, NULL,
0, NULL, 0, 0);
OK, maybe that is just me, but in order to extend an API, I'd rather add
the new parameter at the end.
WARN(IS_ERR(pdev), "could not build omap_device for %s\n", oh_name);
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 7a42f32..98eb95d 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -144,7 +144,7 @@ static int omap_init_mcbsp(struct omap_hwmod *oh, void
*unused)
(struct omap_mcbsp_dev_attr *)(oh->dev_attr))->sidetone);
count++;
}
- pdev = omap_device_build_ss(name, id, oh_device, count, pdata,
+ pdev = omap_device_build_ss(NULL, name, id, oh_device, count, pdata,
sizeof(*pdata), omap2_mcbsp_latency,
ARRAY_SIZE(omap2_mcbsp_latency), false);
kfree(pdata);
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 7a3ec4f..5e2424b 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -33,6 +33,7 @@
#include
#include
+#include
#include
@@ -89,12 +90,20 @@ struct platform_device *omap_device_build(const char
*pdev_name, int pdev_id,
struct omap_device_pm_latency *pm_lats,
int pm_lats_cnt, int is_early_device);
-struct platform_device *omap_device_build_ss(const char *pdev_name, int
pdev_id,
+struct platform_device *omap_device_build_ss(struct device_node *np,
+const char *pdev_name, int pdev_id,
struct omap_hwmod **oh, int oh_cnt,
void *pdata, int pdata_len,
struct omap_device_pm_latency *pm_lats,
int pm_lats_cnt, int is_early_device);
+struct platform_device *omap_device_build_dt(struct device_node *np,
+ const char *pdev_name, int pdev_id,
+ struct omap_hwmod *oh, void *pdata,
+ int pdata_len,
+ struct omap_device_pm_latency *pm_lats,
+ int pm_lats_cnt, int is_early_device);
+
void __iomem *omap_device_get_rt_va(struct omap_device *od);
/* OMAP PM interface */
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 7d5e76b..fa49168 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -85,6 +85,7 @@
#include
#include
#include
+#include
#include
#include
@@ -377,6 +378,7 @@ static int omap_device_fill_resources(struct omap_device
*od,
/**
* omap_device_build - build and register an omap_device with one omap_hwmod
Need to update the kerneldoc.
* @pdev_name: name of the platform_device driver to use
+ * @np: device node pointer for attaching it to of_node pointer
* @pdev_id: this platform_device's connection ID
* @oh: ptr to the single omap_hwmod that backs this omap_device
* @pdata: platform_data ptr to associate with the platform_device
@@ -391,7 +393,8 @@ static int omap_device_fill_resources(struct omap_device
Re: [PATCH] omap: timer: Set dmtimer used as clocksource in autoreload mode
* Hemant Pedanekar [110809 20:46]:
> If CONFIG_OMAP_32K_TIMER is not selected and dmtimer is used as clocksource,
> the
> timer stops counting once overflow occurs as it was not set in autoreload
> mode.
> This results into timekeeping failure: for example, 'sleep 1' at the shell
> after
> the timer counter overflow would hang.
>
> This patch sets up autoreload when starting the clocksource timer which fixes
> the above issue.
>
> Signed-off-by: Hemant Pedanekar
> ---
> arch/arm/mach-omap2/timer.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index e964072..796b935 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -293,7 +293,7 @@ static void __init omap2_gp_clocksource_init(int
> gptimer_id,
> pr_info("OMAP clocksource: GPTIMER%d at %lu Hz\n",
> gptimer_id, clksrc.rate);
>
> - __omap_dm_timer_load_start(clksrc.io_base, OMAP_TIMER_CTRL_ST, 0, 1);
> + omap_dm_timer_set_load_start(&clksrc, 1, 0);
> init_sched_clock(&cd, dmtimer_update_sched_clock, 32, clksrc.rate);
>
> if (clocksource_register_hz(&clocksource_gpt, clksrc.rate))
You should be able to just set the autoreload mode by changing to use
OMAP_TIMER_CTRL_POSTED | OMAP_TIMER_CTRL_AR in the __omap_dm_timer_load_start
above.
This avoids calling something that might be a loadable module eventually.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arch:arm:plat-omap:iovmm: remove unused variable 'va'
* Maxin B John [110810 04:06]:
> ping.
Sorry I've been on vacation, applying to fixes.
Regards,
Tony
> On Mon, Aug 8, 2011 at 1:15 PM, Maxin B. John wrote:
> > The pointer "va" returned from "phys_to_virt(pa)" is never used in
> > "sgtable_fill_kmalloc()".So,it is safe to remove this set-but-unused
> > variable.
> >
> > Signed-off-by: Maxin B. John
> > ---
> > diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
> > index c60737c..79e7fed 100644
> > --- a/arch/arm/plat-omap/iovmm.c
> > +++ b/arch/arm/plat-omap/iovmm.c
> > @@ -423,9 +423,6 @@ static void sgtable_fill_kmalloc(struct sg_table *sgt,
> > u32 pa, u32 da,
> > {
> > unsigned int i;
> > struct scatterlist *sg;
> > - void *va;
> > -
> > - va = phys_to_virt(pa);
> >
> > for_each_sg(sgt->sgl, sg, sgt->nents, i) {
> > unsigned bytes;
> >
--
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] arch:arm:plat-omap:iovmm: remove unused variable 'va'
ping.
On Mon, Aug 8, 2011 at 1:15 PM, Maxin B. John wrote:
> The pointer "va" returned from "phys_to_virt(pa)" is never used in
> "sgtable_fill_kmalloc()".So,it is safe to remove this set-but-unused variable.
>
> Signed-off-by: Maxin B. John
> ---
> diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
> index c60737c..79e7fed 100644
> --- a/arch/arm/plat-omap/iovmm.c
> +++ b/arch/arm/plat-omap/iovmm.c
> @@ -423,9 +423,6 @@ static void sgtable_fill_kmalloc(struct sg_table *sgt,
> u32 pa, u32 da,
> {
> unsigned int i;
> struct scatterlist *sg;
> - void *va;
> -
> - va = phys_to_virt(pa);
>
> for_each_sg(sgt->sgl, sg, sgt->nents, i) {
> unsigned bytes;
>
--
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/6] OMAP: misc. PM-related fixes for v3.1-rc
* Tony Lindgren [110809 04:09]: > * Kevin Hilman [110804 08:38]: > > Hi Tony, > > > > Here's my current collection of PM-related fixes for the -rc cycle. > > > > They are based on the next/board branch of Arnd's arm-soc tree (which > > has already been merged by Linus) and are also available in the > > for_3.1/pm-fixes branch of my tree: > > git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git > > Thanks, based on your comment looks like you want to modify at least > one of them. I'll pick the ones that should get merged immediately > while you're on vacation. Hmm as it looks like you already dropped the last patch, I'll pull the first five into fixes. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] AM3517: Booting up
Am 04.08.2011 17:59, schrieb Abhilash K V: > This patch-set gets the kernel booting up on a AM3517 EVM. > The board is able to boot with ramdisk after this,but the MMC and Ethernet > drivers are not up yet. Lots of warnings remain which will be addressed in > subsequent patches. Are there some more patches for testing? USB OTG in host mode seems to find my cardreader and USB memory stick, but no sdx devices were allocated. Yegor -- 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: when to submit new board support
* Michael Jones [110810 03:14]: > I would like to submit some patches to add support for a new OMAP board... > > Is there a right or wrong time to post such patches to this list? How > does the kernel merge window effect what kind of patches are expected > here on the OMAP list? Well this is the right time, however we're moving things to device tree and coalescing code. So you may need to be prepared to update the patches a few times before we get them to mainline. > What should I use as the base for my patches? At > http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git, > at the moment 'master' hasn't been updated for 4 weeks. Should I base it > on v3.1-rc1 instead (as an example, since I won't manage to submit it > while v3.1-rc1 is the most recent tag)? Yes v3.1-rc1 should be used as the base. I've been on vacation and have not updated the omap tree for a while, will updated it soonish, but will be just v3.1-rc1 + bug fixes. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
when to submit new board support
I would like to submit some patches to add support for a new OMAP board... Is there a right or wrong time to post such patches to this list? How does the kernel merge window effect what kind of patches are expected here on the OMAP list? What should I use as the base for my patches? At http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git, at the moment 'master' hasn't been updated for 4 weeks. Should I base it on v3.1-rc1 instead (as an example, since I won't manage to submit it while v3.1-rc1 is the most recent tag)? thanks, Michael MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier -- 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: [RFC/PATCH 04/14] OMAP: McBSP: use existing macros for converting between devices
Manju, On 8/10/2011 9:07 AM, Jarkko Nikula wrote: Hi On Tue, 09 Aug 2011 19:10:22 +0500 "G, Manjunath Kondaiah" wrote: From: Kevin Hilman For converting from struct device to platform_device, and from platform_device to struct device, there are existing macros. Use them instead of manual use of container_of(). Signed-off-by: Kevin Hilman --- arch/arm/plat-omap/mcbsp.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) Kevin dropped this patch and used mine that does more cleanups: http://marc.info/?l=linux-omap&m=131255627918065&w=2 Worth to check also other patches since Kevin's updated set seems to have other differences too: http://marc.info/?l=linux-omap&m=131258997416300&w=2 In fact, you'd better point to the lastest Kevin's tree and not included the patches in this series. 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: Build failure: bisected: v3.1-rc1 with config ARCH_OMAP && !ARCH_OMAP4 fails with linker error
On Wed, 10 Aug 2011, Tony Lindgren wrote: > Thanks yes that does the trick. I'd like to queue this immediately so we > have more time to look at the other fixes if you don't mind. That's fine, feel free to send this first. Will try to have the rest of my 3.1-rc fixes ready to go in a few days. > I noticed some checkpatch warnings, updated patch below. Does that look > OK to you? Fine by me. - Paul -- 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: Build failure: bisected: v3.1-rc1 with config ARCH_OMAP && !ARCH_OMAP4 fails with linker error
* Paul Walmsley [110809 23:51]:
> On Tue, 9 Aug 2011, Paul Walmsley wrote:
>
> > On Tue, 9 Aug 2011, Tony Lindgren wrote:
> >
> > > Hmm, there are also these when CONFIG_ARCH_OMAP4 is not selected:
> > >
> > > arch/arm/mach-omap2/built-in.o: In function `_enable_module':
> > > arch/arm/mach-omap2/omap_hwmod.c:701: undefined reference to
> > > `omap4_cminst_module_enable'
> > > arch/arm/mach-omap2/built-in.o: In function `_disable_module':
> > > arch/arm/mach-omap2/omap_hwmod.c:726: undefined reference to
> > > `omap4_cminst_module_disable'
> > > arch/arm/mach-omap2/built-in.o: In function `_wait_target_disable':
> > > arch/arm/mach-omap2/omap_hwmod.c:1179: undefined reference to
> > > `omap4_cminst_wait_module_idle'
> > > distcc[27594] ERROR: compile (null) on localhost failed
> > > make: *** [.tmp_vmlinux1] Error 1
> > >
> > > Care to take a look?
> >
> > Weird, those don't show up on my n800 config (below) with CodeSourcery
> > 2010.09-50. Looks like something isn't removing the dead code. will post
> > a patch for this.
> >
> > If you post which compiler you're using, I'll add it to my build tests
> > too...
>
> Hmmm, playing around with this further, this is probably not a
> compiler problem. Looks like what triggers this is the MULTI_OMAP2
> preprocessor trickery in arch/arm/plat-omap/include/plat/cpu.h, which
> would cause something like cpu_is_omap24xx() to be resolved at runtime
> rather than by the preprocessor.
>
> This should fix the immediate issue. Will include in a 3.1-rc fixes branch.
Thanks yes that does the trick. I'd like to queue this immediately so we
have more time to look at the other fixes if you don't mind.
I noticed some checkpatch warnings, updated patch below. Does that look
OK to you?
Tony
From: Paul Walmsley
Date: Wed, 10 Aug 2011 00:57:42 -0600
Subject: [PATCH] OMAP: hwmod: fix build break on non-OMAP4 multi-OMAP2 builds
Builds for multi-OMAP2 (e.g., OMAP2420 with OMAP2430) with
CONFIG_ARCH_OMAP4=n fail with the following errors:
arch/arm/mach-omap2/built-in.o: In function `_enable_module':
arch/arm/mach-omap2/omap_hwmod.c:701: undefined reference to
`omap4_cminst_module_enable'
arch/arm/mach-omap2/built-in.o: In function `_disable_module':
arch/arm/mach-omap2/omap_hwmod.c:726: undefined reference to
`omap4_cminst_module_disable'
arch/arm/mach-omap2/built-in.o: In function `_wait_target_disable':
arch/arm/mach-omap2/omap_hwmod.c:1179: undefined reference to
`omap4_cminst_wait_module_idle'
This is probably due to the preprocessor directives in
arch/arm/plat-omap/include/plat/cpu.h that convert some cpu_is_omap*()
expressions from preprocessor directives into something that is only
resolvable during runtime, if multiple OMAP2 build targets are
selected.
Thanks to Tony Lindgren for reporting.
Signed-off-by: Paul Walmsley
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap2/cminst44xx.h b/arch/arm/mach-omap2/cminst44xx.h
index f2ea645..a018a73 100644
--- a/arch/arm/mach-omap2/cminst44xx.h
+++ b/arch/arm/mach-omap2/cminst44xx.h
@@ -18,13 +18,36 @@ extern void omap4_cminst_clkdm_force_sleep(u8 part, s16
inst, u16 cdoffs);
extern void omap4_cminst_clkdm_force_wakeup(u8 part, s16 inst, u16 cdoffs);
extern int omap4_cminst_wait_module_ready(u8 part, u16 inst, s16 cdoffs, u16
clkctrl_offs);
-extern int omap4_cminst_wait_module_idle(u8 part, u16 inst, s16 cdoffs, u16
clkctrl_offs);
+
+# ifdef CONFIG_ARCH_OMAP4
+extern int omap4_cminst_wait_module_idle(u8 part, u16 inst, s16 cdoffs,
+u16 clkctrl_offs);
extern void omap4_cminst_module_enable(u8 mode, u8 part, u16 inst, s16 cdoffs,
u16 clkctrl_offs);
extern void omap4_cminst_module_disable(u8 part, u16 inst, s16 cdoffs,
u16 clkctrl_offs);
+# else
+
+static inline int omap4_cminst_wait_module_idle(u8 part, u16 inst, s16 cdoffs,
+ u16 clkctrl_offs)
+{
+ return 0;
+}
+
+static inline void omap4_cminst_module_enable(u8 mode, u8 part, u16 inst,
+ s16 cdoffs, u16 clkctrl_offs)
+{
+}
+
+static inline void omap4_cminst_module_disable(u8 part, u16 inst, s16 cdoffs,
+u16 clkctrl_offs)
+{
+}
+
+# endif
+
/*
* In an ideal world, we would not export these low-level functions,
* but this will probably take some time to fix properly
--
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: OMAP3 kernels fail to build
* Russell King - ARM Linux [110810 00:21]:
> On Tue, Aug 09, 2011 at 11:26:16PM -0600, Paul Walmsley wrote:
> > On Mon, 8 Aug 2011, Russell King - ARM Linux wrote:
> >
> > > On Mon, Aug 08, 2011 at 04:39:32PM +0530, Santosh wrote:
> > > > On Monday 08 August 2011 04:30 PM, Russell King - ARM Linux wrote:
> > > >> With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this:
> > > >>
> > > >> arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to
> > > >> `omap4430_phy_init'
> > > >> arch/arm/mach-omap2/built-in.o:(.data+0xf9a0): undefined reference to
> > > >> `omap4430_phy_exit'
> > > >> arch/arm/mach-omap2/built-in.o:(.data+0xf9a4): undefined reference to
> > > >> `omap4430_phy_power'
> > > >> arch/arm/mach-omap2/built-in.o:(.data+0xf9a8): undefined reference to
> > > >> `omap4430_phy_set_clk'
> > > >> arch/arm/mach-omap2/built-in.o:(.data+0xf9ac): undefined reference to
> > > >> `omap4430_phy_suspend'
> > > >>
> > > > I thought below patch was suppose to fix it.
> > > > https://patchwork.kernel.org/patch/963462/
> > >
> > > So, the problem has been known about for around a month. Yet the broken
> > > patch still went upstream.
> >
> > Which known "broken patch still went upstream" ?
> >
> > The problem commits were 208466dc10083e734a8af71d10f923ee4bff950c ("usb:
> > otg: OMAP4430: Powerdown the internal PHY when USB is disabled") and
> > fb91cde49c327ff957c55d91805bc6abda59b311 ("usb: musb: OMAP4430: Power down
> > the PHY during board init"). The above link makes this clear.
>
> The fact that there are _build_ _errors_ indicate that a patch which
> introduced this crap _was_ _broken_. The fact that it was _reported_
> as broken well before the merge window and still went in during the
> merge window indicates that the OMAP workflow with regard to patches
> is simply BROKEN.
Or people go on vacation and just drop the ball like I did :)
Anyways, the best way to detect issues like this would be to get
make randconfig working for ARM.. And then have some machines doing
that with next tree.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: Fix linking error in twl-common.c for OMAP2/3/4 only builds
* Peter Ujfalusi [110809 05:31]:
> Avoid compiling code for OMAP arch which is not selected by the
> config.
>
> Fixes issues like:
> With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this:
>
> arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to
> `omap4430_phy_init'
> arch/arm/mach-omap2/built-in.o:(.data+0xf9a0): undefined reference to
> `omap4430_phy_exit'
> arch/arm/mach-omap2/built-in.o:(.data+0xf9a4): undefined reference to
> `omap4430_phy_power'
> arch/arm/mach-omap2/built-in.o:(.data+0xf9a8): undefined reference to
> `omap4430_phy_set_clk'
> arch/arm/mach-omap2/built-in.o:(.data+0xf9ac): undefined reference to
> `omap4430_phy_suspend'
>
> Signed-off-by: Peter Ujfalusi
>
> Hi Russel, Tony,
>
> This patch fixes the linking error caused by the twl-common.c file,
> when the kernel is built for OMAP2/3/4 only.
Thanks, I'll queue this one as a fix with updated comments as below.
Regards,
Tony
From: Peter Ujfalusi
Date: Tue, 9 Aug 2011 15:36:50 +0300
Subject: [PATCH] OMAP: Fix linking error in twl-common.c for OMAP2/3/4 only
builds
Commit b22f954 (OMAP4: Move common twl6030 configuration to twl-common)
caused compile failures for code for OMAP arch which is not selected by
the config.
Fixes issues like:
With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this:
arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to
`omap4430_phy_init'
arch/arm/mach-omap2/built-in.o:(.data+0xf9a0): undefined reference to
`omap4430_phy_exit'
arch/arm/mach-omap2/built-in.o:(.data+0xf9a4): undefined reference to
`omap4430_phy_power'
arch/arm/mach-omap2/built-in.o:(.data+0xf9a8): undefined reference to
`omap4430_phy_set_clk'
arch/arm/mach-omap2/built-in.o:(.data+0xf9ac): undefined reference to
`omap4430_phy_suspend'
Fix the problem by moving the code to ifdef sections for omap3 and omap4.
Signed-off-by: Peter Ujfalusi
[t...@atomide.com: updated comments]
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 2543342..daa056e 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -48,14 +48,7 @@ void __init omap_pmic_init(int bus, u32 clkrate,
omap_register_i2c_bus(bus, clkrate, &pmic_i2c_board_info, 1);
}
-static struct twl4030_usb_data omap4_usb_pdata = {
- .phy_init = omap4430_phy_init,
- .phy_exit = omap4430_phy_exit,
- .phy_power = omap4430_phy_power,
- .phy_set_clock = omap4430_phy_set_clk,
- .phy_suspend= omap4430_phy_suspend,
-};
-
+#if defined(CONFIG_ARCH_OMAP3)
static struct twl4030_usb_data omap3_usb_pdata = {
.usb_mode = T2_USB_MODE_ULPI,
};
@@ -122,6 +115,45 @@ static struct regulator_init_data omap3_vpll2_idata = {
.consumer_supplies = omap3_vpll2_supplies,
};
+void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
+ u32 pdata_flags, u32 regulators_flags)
+{
+ if (!pmic_data->irq_base)
+ pmic_data->irq_base = TWL4030_IRQ_BASE;
+ if (!pmic_data->irq_end)
+ pmic_data->irq_end = TWL4030_IRQ_END;
+
+ /* Common platform data configurations */
+ if (pdata_flags & TWL_COMMON_PDATA_USB && !pmic_data->usb)
+ pmic_data->usb = &omap3_usb_pdata;
+
+ if (pdata_flags & TWL_COMMON_PDATA_BCI && !pmic_data->bci)
+ pmic_data->bci = &omap3_bci_pdata;
+
+ if (pdata_flags & TWL_COMMON_PDATA_MADC && !pmic_data->madc)
+ pmic_data->madc = &omap3_madc_pdata;
+
+ if (pdata_flags & TWL_COMMON_PDATA_AUDIO && !pmic_data->audio)
+ pmic_data->audio = &omap3_audio_pdata;
+
+ /* Common regulator configurations */
+ if (regulators_flags & TWL_COMMON_REGULATOR_VDAC && !pmic_data->vdac)
+ pmic_data->vdac = &omap3_vdac_idata;
+
+ if (regulators_flags & TWL_COMMON_REGULATOR_VPLL2 && !pmic_data->vpll2)
+ pmic_data->vpll2 = &omap3_vpll2_idata;
+}
+#endif /* CONFIG_ARCH_OMAP3 */
+
+#if defined(CONFIG_ARCH_OMAP4)
+static struct twl4030_usb_data omap4_usb_pdata = {
+ .phy_init = omap4430_phy_init,
+ .phy_exit = omap4430_phy_exit,
+ .phy_power = omap4430_phy_power,
+ .phy_set_clock = omap4430_phy_set_clk,
+ .phy_suspend= omap4430_phy_suspend,
+};
+
static struct regulator_init_data omap4_vdac_idata = {
.constraints = {
.min_uV = 180,
@@ -273,32 +305,4 @@ void __init omap4_pmic_get_config(struct
twl4030_platform_data *pmic_data,
!pmic_data->clk32kg)
pmic_data->clk32kg = &omap4_clk32kg_idata;
}
-
-void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
- u32 pdata_flags, u32 regulators_flags)
-{
- if (!pmic_data->irq_base)
- pmic_data->irq_base = TWL4030_IRQ_BASE;
-
Re: Build failure: bisected: v3.1-rc1 with config ARCH_OMAP && !ARCH_OMAP4 fails with linker error
* Paul Walmsley [110809 20:01]: > On Tue, 9 Aug 2011, Tony Lindgren wrote: > > > Hmm, there are also these when CONFIG_ARCH_OMAP4 is not selected: > > > > arch/arm/mach-omap2/built-in.o: In function `_enable_module': > > arch/arm/mach-omap2/omap_hwmod.c:701: undefined reference to > > `omap4_cminst_module_enable' > > arch/arm/mach-omap2/built-in.o: In function `_disable_module': > > arch/arm/mach-omap2/omap_hwmod.c:726: undefined reference to > > `omap4_cminst_module_disable' > > arch/arm/mach-omap2/built-in.o: In function `_wait_target_disable': > > arch/arm/mach-omap2/omap_hwmod.c:1179: undefined reference to > > `omap4_cminst_wait_module_idle' > > distcc[27594] ERROR: compile (null) on localhost failed > > make: *** [.tmp_vmlinux1] Error 1 > > > > Care to take a look? > > Weird, those don't show up on my n800 config (below) with CodeSourcery > 2010.09-50. Looks like something isn't removing the dead code. will post > a patch for this. > > If you post which compiler you're using, I'll add it to my build tests > too... Happens at least with this one: gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/13] ARM: gpio: consolidate trivial gpiolib implementations
2011/8/9 Russell King - ARM Linux : > Consolidate 24 trivial gpiolib implementions out of mach/gpio.h > into asm/gpio.h. This is basically the include of asm-generic/gpio.h > and the definition of gpio_get_value, gpio_set_value, and gpio_cansleep > as described in Documentation/gpio.txt > > Signed-off-by: Russell King reaks compile of plat-nomadik due to missing u32, feel free to fold in the below fix. With that it's Tested-by: Linus Walleij for Nomadik, U300 and Ux500. >From 2e4496fc7643d804ccf50a8efe1a0304210176d1 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Wed, 10 Aug 2011 09:51:16 +0200 Subject: [PATCH] plat-nomadik: small fixup for gpio.h Removing the generic gpio.h broke compilation of the Nomadik GPIO driver since it implicitly got u32 from it. Explicitly include so we get u32 defined. Signed-off-by: Linus Walleij --- arch/arm/plat-nomadik/include/plat/gpio.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/plat-nomadik/include/plat/gpio.h b/arch/arm/plat-nomadik/include/plat/gpio.h index cf0b78b..b894a53 100644 --- a/arch/arm/plat-nomadik/include/plat/gpio.h +++ b/arch/arm/plat-nomadik/include/plat/gpio.h @@ -12,6 +12,8 @@ #ifndef __ASM_PLAT_GPIO_H #define __ASM_PLAT_GPIO_H +#include + /* * "nmk_gpio" and "NMK_GPIO" stand for "Nomadik GPIO", leaving * the "gpio" namespace for generic and cross-machine functions -- 1.7.3.2 Thanks, Linus Walleij -- 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: OMAP3 kernels fail to build
On Tue, Aug 09, 2011 at 11:26:16PM -0600, Paul Walmsley wrote:
> On Mon, 8 Aug 2011, Russell King - ARM Linux wrote:
>
> > On Mon, Aug 08, 2011 at 04:39:32PM +0530, Santosh wrote:
> > > On Monday 08 August 2011 04:30 PM, Russell King - ARM Linux wrote:
> > >> With CONFIG_ARCH_OMAP3=y and CONFIG_ARCH_OMAP4=n, I'm getting this:
> > >>
> > >> arch/arm/mach-omap2/built-in.o:(.data+0xf99c): undefined reference to
> > >> `omap4430_phy_init'
> > >> arch/arm/mach-omap2/built-in.o:(.data+0xf9a0): undefined reference to
> > >> `omap4430_phy_exit'
> > >> arch/arm/mach-omap2/built-in.o:(.data+0xf9a4): undefined reference to
> > >> `omap4430_phy_power'
> > >> arch/arm/mach-omap2/built-in.o:(.data+0xf9a8): undefined reference to
> > >> `omap4430_phy_set_clk'
> > >> arch/arm/mach-omap2/built-in.o:(.data+0xf9ac): undefined reference to
> > >> `omap4430_phy_suspend'
> > >>
> > > I thought below patch was suppose to fix it.
> > > https://patchwork.kernel.org/patch/963462/
> >
> > So, the problem has been known about for around a month. Yet the broken
> > patch still went upstream.
>
> Which known "broken patch still went upstream" ?
>
> The problem commits were 208466dc10083e734a8af71d10f923ee4bff950c ("usb:
> otg: OMAP4430: Powerdown the internal PHY when USB is disabled") and
> fb91cde49c327ff957c55d91805bc6abda59b311 ("usb: musb: OMAP4430: Power down
> the PHY during board init"). The above link makes this clear.
The fact that there are _build_ _errors_ indicate that a patch which
introduced this crap _was_ _broken_. The fact that it was _reported_
as broken well before the merge window and still went in during the
merge window indicates that the OMAP workflow with regard to patches
is simply BROKEN.
And the fact that you can't recognise that makes _you_ part of the
problem.
There are no excuses for this.
And more - wtf those commit IDs you mention have to do with my build
error with twl-common.c I've no idea. The breakage was not introduced
by either of the commits you mention, but b22f954 (OMAP4: Move common
twl6030 configuration to twl-common).
So please, stop this disinformation right now and get more of a clue.
Thanks.
--
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: How to handle named resources with DT?
On Wed, 10 Aug 2011, David Gibson wrote: > Of course, the problem with reg-names is that it will be ignored by > older OSes, and so 'reg' must still be in the correct order. Most ARM SoC Linux ports aren't using DT now, so there isn't really an older OS case here. Might as well try to get something implemented in a clean way while there's still some chance for it. A more persuasive case could probably be made about DT bootloader-related issues. Those would have to be converted to use reg-names, also. - Paul -- 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: [RFC/PATCH 04/14] OMAP: McBSP: use existing macros for converting between devices
Hi On Tue, 09 Aug 2011 19:10:22 +0500 "G, Manjunath Kondaiah" wrote: > From: Kevin Hilman > > For converting from struct device to platform_device, and from > platform_device to struct device, there are existing macros. Use > them instead of manual use of container_of(). > > Signed-off-by: Kevin Hilman > --- > arch/arm/plat-omap/mcbsp.c |6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > Kevin dropped this patch and used mine that does more cleanups: http://marc.info/?l=linux-omap&m=131255627918065&w=2 Worth to check also other patches since Kevin's updated set seems to have other differences too: http://marc.info/?l=linux-omap&m=131258997416300&w=2 -- Jarkko -- 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
