Re: [PATCH 1/3] omap4 hsmmc : Adding card detect support for MMC1
Oops my fault will correct it and repost ...
Regards,
Kishore
On Tue, Aug 31, 2010 at 11:25 AM, Matt Fleming m...@console-pimps.org wrote:
On Mon, Aug 30, 2010 at 11:18:23PM +0530, kishore kadiyala wrote:
Adding card detect callback function and card detect configuration
function for MMC1 Controller.
Card detect configuration function does initial configuration of the
MMC Control PullUp-PullDown registers of Phoenix.
For MMC1 Controller, Card detect interrupt source is
twl6030 and the card detect call back function provides card present/absent
status by reading MMC Control register.
Cc: Tony Lindgren t...@atomide.com
Cc: Adrian Hunter adrian.hun...@nokia.com
Cc: Madhusudhan Chikkature madhu...@ti.com
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
[...]
@@ -223,6 +224,81 @@ int twl6030_interrupt_mask(u8 bit_mask, u8 offset)
}
EXPORT_SYMBOL(twl6030_interrupt_mask);
+int twl6030_mmc_card_detect_config(void)
+{
+ int ret;
+ u8 reg_val = 0;
+
+ /* Unmasking the Card detect Interrupt line for MMC1 from Phoenix */
+ if (twl_class_is_6030()) {
+ twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
+ REG_INT_MSK_LINE_B);
+ twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
+ REG_INT_MSK_STS_B);
+ }
+
+ /*
+ * Intially Configuring MMC_CTRL for receving interrupts
+ * Card status on TWL6030 for MMC1
+ */
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, reg_val, TWL6030_MMCCTRL);
+ if (ret 0) {
+ pr_err(twl6030: Failed to read MMCCTRL, error %d\n, ret);
+ return ret;
+ }
+ reg_val = ~VMMC_AUTO_OFF;
+ reg_val |= SW_FC;
+ ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val, TWL6030_MMCCTRL);
+ if (ret 0) {
+ return ret;
+ pr_err(twl6030: Failed to write MMCCTRL, error %d\n, ret);
+ }
Shouldn't this be
pr_err(twl6030: Failed to write MMCCTRL, error %d\n, ret);
return ret;
?
+
+ /* Configuring PullUp-PullDown register */
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, reg_val,
+ TWL6030_CFG_INPUT_PUPD3);
+ if (ret 0) {
+ return ret;
+ pr_err(twl6030: Failed to read CFG_INPUT_PUPD3, error %d\n,
+ ret);
Shouldn't this be,
pr_err(twl6030: Failed to read CFG_INPUT_PUPD3, error %d\n,
ret);
return ret;
?
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 6/8 v2] usb: musb: Offmode fix for idle path
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, August 26, 2010 5:40 AM
To: Kalliguddi, Hema
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
Mankad, Maulik Ojas; Felipe Balbi; Tony Lindgren; Cousson,
Benoit; Paul Walmsley
Subject: Re: [PATCH 6/8 v2] usb: musb: Offmode fix for idle path
Hema HK hem...@ti.com writes:
With OMAP core-off support musb was not functional as
context was getting
lost after wakeup from core-off. And also musb was blocking
the core-off
after loading the gadget driver even with no cable connected
sometimes.
Added the conext save/restore api in the platform layer which will
be called in the idle and wakeup path.
Changed the usb sysconfig settings as per the usbotg functional spec.
When the device is not used, configure to force idle and
force standby mode.
When it is being used, configure in smart standby and smart
idle mode.
So while attempting to coreoff the usb is configured to
force standby and
force idle mode, after wakeup configured in smart idle and
smart standby.
You don't describe the new .clk_autogated field added here. That part
should be a separate patch as it's not directly related to
$SUBJECT patch.
In OMAP for USB there is no need to disable the interface clock. But for the
other
platforms like davinci which uses mentor USB IP clock is not auto gated so
There is a need to disbale the clock when .suspend API defined in the driver is
called.
So introduced a flag in the platform to enable/disable the clock
In .supend and .resume APIs appropriately in the driver code.
Yes. It may not be directly related to $SUBJECT patch, but I am reusing
.suspend and .resume APIs for context save and restore during idle path.
Because of that this fix as part of the patch.
Signed-off-by: Hema HK hem...@ti.com
Signed-off-by: Maulik Mankad x0082...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/pm34xx.c |5 +++
arch/arm/mach-omap2/usb-musb.c| 42
-
arch/arm/plat-omap/include/plat/usb.h |2 +
drivers/usb/musb/musb_core.c | 10 +++
drivers/usb/musb/musb_core.h |1 -
drivers/usb/musb/omap2430.c | 48
++---
include/linux/usb/musb.h |6
7 files changed, 102 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index fb4994a..7b34201 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -39,6 +39,7 @@
#include plat/gpmc.h
#include plat/dma.h
#include plat/dmtimer.h
+#include plat/usb.h
#include asm/tlbflush.h
@@ -416,6 +417,8 @@ void omap_sram_idle(void)
if (core_next_state == PWRDM_POWER_OFF) {
omap3_core_save_context();
omap3_prcm_save_context();
+/* Save MUSB context */
+musb_context_save_restore(1);
}
}
@@ -458,6 +461,8 @@ void omap_sram_idle(void)
omap3_prcm_restore_context();
omap3_sram_restore_context();
omap2_sms_restore_context();
+/* restore MUSB context */
+musb_context_save_restore(0);
}
omap_uart_resume_idle(0);
omap_uart_resume_idle(1);
diff --git a/arch/arm/mach-omap2/usb-musb.c
b/arch/arm/mach-omap2/usb-musb.c
index c228cc0..9d10440 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -35,6 +35,7 @@
static const char name[] = musb_hdrc;
#define MAX_OMAP_MUSB_HWMOD_NAME_LEN16
+struct omap_hwmod *oh_p =NULL;
static struct musb_hdrc_config musb_config = {
.multipoint = 1,
@@ -59,6 +60,9 @@ static struct musb_hdrc_platform_data musb_plat = {
* mode, and should be passed to usb_musb_init().
*/
.power = 50, /* up to 100 mA */
+
+/* supports clock autogating */
+.clk_autogated = 1,
This appears unrelated, and should be a separate patch.
};
static u64 musb_dmamask = DMA_BIT_MASK(32);
@@ -97,7 +101,7 @@ void __init usb_musb_init(struct
omap_musb_board_data *board_data)
musb_plat.mode = board_data-mode;
musb_plat.extvbus = board_data-extvbus;
pdata = musb_plat;
-
+oh_p = oh;
od = omap_device_build(name, bus_id, oh, pdata,
sizeof(struct musb_hdrc_platform_data),
omap_musb_latency,
@@ -116,8 +120,44 @@ void __init usb_musb_init(struct
omap_musb_board_data *board_data)
}
+void musb_context_save_restore(int save)
+{
+struct omap_hwmod *oh
Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement
On Tue, Aug 31, 2010 at 10:28 AM, Sripathy, Vishwanath vishwanath...@ti.com wrote: -Original Message- From: Silesh C V [mailto:sailes...@gmail.com] Sent: Tuesday, August 31, 2010 9:53 AM To: Sripathy, Vishwanath Cc: Kevin Hilman; vishwanath.sripa...@linaro.org; linux-omap@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement Hi Vishwa, On Mon, Aug 30, 2010 at 6:29 PM, Sripathy, Vishwanath vishwanath...@ti.com wrote: Kevin, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Saturday, August 28, 2010 12:45 AM To: vishwanath.sripa...@linaro.org Cc: linux-omap@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement vishwanath.sripa...@linaro.org writes: From: Vishwanath BS vishwanath.sripa...@linaro.org This patch has instrumentation code for measuring latencies for various CPUIdle C states for OMAP. Idea here is to capture the timestamp at various phases of CPU Idle and then compute the sw latency for various c states. For OMAP, 32k clock is chosen as reference clock this as is an always on clock. wkup domain memory (scratchpad memory) is used for storing timestamps. One can see the worstcase latencies in below sysfs entries (after enabling CONFIG_CPU_IDLE_PROF in .config). This information can be used to correctly configure cpu idle latencies for various C states after adding HW latencies for each of these sw latencies. /sys/devices/system/cpu/cpu0/cpuidle/staten/actual_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/sleep_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/wkup_latency THis patch is tested on OMAP ZOOM3 using kevin's pm branch. Signed-off-by: Vishwanath BS vishwanath.sripa...@linaro.org Cc: linaro-...@lists.linaro.org While I have many problems with the implementation details, I won't go into them because in general this is the wrong direction for kernel instrumentation. This approach adds quite a bit overhead to the idle path itself. With all the reads/writes from/to the scratchpad(?) and all the multiplications and divides in every idle path, as well as the wait-for-idlest in both the sleep and resume paths. The additional overhead added is non trivial. Basically, I'd like get away from custom instrumentation and measurement coded inside the kernel itself. This kind of code never stops growing and morphing into ugliness, and rarely scales well when new SoCs are added. With ftrace/perf, we can add tracepoints at specific points and use external tools to extract and analyze the delays, latencys etc. The point is to keep the minimum possible in the kernel: just the tracepoints we're interested in. The rest (calculations, averages, analysis, etc.) does not need to be in the kernel and can be done easier and with more powerful tools outside the kernel. The challenge here is that we need to take time stamp at the fag end of CPU Idle which means we have no access to DDR, MMU/Caches are disabled etc (on OMAP3). So I am not sure if we will be able to use ftrace/perf kind of tools here. If we choose to exclude assembly code part for measurement, then we will be omitting major contributor to CPU Idle latency namely ARM context save/restoration part. Also these calculations are done only when we enable CPUIDLE profiling feature. In the normal production system, these will not come into picture at all. So I am not sure latencies involved in these calculations are still an issue when we are just doing profiling. There are two other issues when we use 32k timer for latency measurement. snip + + /* take care of overflow */ + if (postidle_time preidle_time) + postidle_time += (u32) 0x; + if (wkup_time sleep_time) + wkup_time += (u32) 0x; + snip 1.We are checking postidle_time preidle_time to find out whether there had been an over flow or not. There can be situations in which the timer overflows and still we have a greater postidle_time. 2. We are doing the correction for one overflow. What happens if the timer overflows for a second or third time. Can we keep track of the number of overflows and then do the correction accordingly? Unfortunately, there is no way to check if overflow happens more than once in 32k timer and as you said, theoretically it's possible that if timer overflows more than once, these calculation will wrong. Having said that, do you really see any usecase where system will idle for more than 37 hours in single cpuidle execution to cause timer overflow? I am not sure. But can we completely write off such a possibility ? Regards, Silesh Vishwa Regards, Silesh Regards Vishwa
Re: [PATCH 11/11] TWL4030: Codec: Fix fucntion declaration error
On Thursday 26 August 2010 23:56:49 ext G, Manjunath Kondaiah wrote:
From: Manjunatha GK manj...@ti.com
Fixes sparse warning for the below error
drivers/mfd/twl4030-codec.c:118:5: error: symbol
'twl4030_codec_disable_resource' redeclared with different type
(originally declared at include/linux/mfd/twl4030- codec.h:268) -
incompatible argument 1 (different signedness)
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Nishanth Menon n...@ti.com
---
include/linux/mfd/twl4030-codec.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/mfd/twl4030-codec.h
b/include/linux/mfd/twl4030-codec.h index 2ec317c..0f7300e 100644
--- a/include/linux/mfd/twl4030-codec.h
+++ b/include/linux/mfd/twl4030-codec.h
@@ -265,7 +265,7 @@ enum twl4030_codec_res {
TWL4030_CODEC_RES_MAX,
};
-int twl4030_codec_disable_resource(enum twl4030_codec_res id);
+int twl4030_codec_disable_resource(unsigned id);
int twl4030_codec_enable_resource(enum twl4030_codec_res id);
unsigned int twl4030_codec_get_mclk(void);
I have no idea how this happened, but it would be better to correct the driver
instead the header.
--
Péter
--
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 06/11] OMAP: McBSP: Fix static function warning
Hi,
this is audio related file, so use the alsa-devel for this patch, and also CC
the maintainers (Jarkko, Liam, Mark, and me).
On Thursday 26 August 2010 23:56:44 ext G, Manjunath Kondaiah wrote:
From: Manjunatha GK manj...@ti.com
This patch fixes sparse warning due non declaration of static function
sound/soc/omap/omap-mcbsp.c:783:5: warning: symbol
'omap_mcbsp_st_info_volsw' was not declared. Should it be static?
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Nishanth Menon n...@ti.com
---
sound/soc/omap/omap-mcbsp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index 86f2139..5768381 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -780,7 +780,7 @@ struct snd_soc_dai omap_mcbsp_dai[] = {
EXPORT_SYMBOL_GPL(omap_mcbsp_dai);
-int omap_mcbsp_st_info_volsw(struct snd_kcontrol *kcontrol,
+static int omap_mcbsp_st_info_volsw(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_info *uinfo)
{
struct soc_mixer_control *mc =
Thanks,
Péter
--
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] OMAP: McBSP: Do not enable SRG in slave mode
McBSP SRG (Sample Rate Generator) and FSG (Frame Sync
Generator) is only needed to be enabled, when McBSP
is master.
In McBSP slave mode, the SRG, and FSG can be kept disabled,
which might save some power at the end in this configuration.
Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com
---
Hello Jarkko,
I have tested this on OMAP3, but I think this should be
applicable for other OMAP versions as well.
When McBSP was slave the audio worked fine, when I left
the SRG, and FSG disabled.
arch/arm/plat-omap/mcbsp.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index e31496e..ecbfe39 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -878,7 +878,7 @@ EXPORT_SYMBOL(omap_mcbsp_free);
void omap_mcbsp_start(unsigned int id, int tx, int rx)
{
struct omap_mcbsp *mcbsp;
- int idle;
+ int enable_srg = 0;
u16 w;
if (!omap_mcbsp_check_valid_id(id)) {
@@ -893,10 +893,13 @@ void omap_mcbsp_start(unsigned int id, int tx, int rx)
mcbsp-rx_word_length = (MCBSP_READ_CACHE(mcbsp, RCR1) 5) 0x7;
mcbsp-tx_word_length = (MCBSP_READ_CACHE(mcbsp, XCR1) 5) 0x7;
- idle = !((MCBSP_READ_CACHE(mcbsp, SPCR2) |
- MCBSP_READ_CACHE(mcbsp, SPCR1)) 1);
+ /* Only enable SRG, if McBSP is master */
+ w = MCBSP_READ_CACHE(mcbsp, PCR0);
+ if (w (FSXM | FSRM | CLKXM | CLKRM))
+ enable_srg = !((MCBSP_READ_CACHE(mcbsp, SPCR2) |
+ MCBSP_READ_CACHE(mcbsp, SPCR1)) 1);
- if (idle) {
+ if (enable_srg) {
/* Start the sample generator */
w = MCBSP_READ_CACHE(mcbsp, SPCR2);
MCBSP_WRITE(mcbsp, SPCR2, w | (1 6));
@@ -919,7 +922,7 @@ void omap_mcbsp_start(unsigned int id, int tx, int rx)
*/
udelay(500);
- if (idle) {
+ if (enable_srg) {
/* Start frame sync */
w = MCBSP_READ_CACHE(mcbsp, SPCR2);
MCBSP_WRITE(mcbsp, SPCR2, w | (1 7));
--
1.7.2.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] omap: 4430sdp board support for the the GPIO keys
-Original Message-
From: Gopinath, Thara
Subject: RE: [PATCH v2] omap: 4430sdp board support for the the GPIO keys
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of
Shubhrajyoti D
Sent: Tuesday, August 24, 2010 10:58 AM
To: linux-omap@vger.kernel.org
Cc: Datta, Shubhrajyoti
Subject: [PATCH v2] omap: 4430sdp board support for the the GPIO keys
omap 4430sdp board support for the GPIO keys.
The proximity sensor is connected to GPIO and is registered as a
GPIO key.
- Making the default state of the sensor off at bootup
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 61
+++
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
omap2/board-4430sdp.c
index 9447644..85b0e0c 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -20,6 +20,7 @@
#include linux/usb/otg.h
#include linux/spi/spi.h
#include linux/i2c/twl.h
+#include linux/gpio_keys.h
#include linux/regulator/machine.h
#include linux/leds.h
@@ -40,6 +41,8 @@
#define ETH_KS8851_IRQ 34
#define ETH_KS8851_POWER_ON48
#define ETH_KS8851_QUART 138
+#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO 184
+#define OMAP4_SFH7741_ENABLE_GPIO 188
static struct gpio_led sdp4430_gpio_leds[] = {
{
@@ -77,11 +80,47 @@ static struct gpio_led sdp4430_gpio_leds[] = {
};
+static struct gpio_keys_button sdp4430_gpio_keys[] = {
+ {
+ .desc = Proximity Sensor,
+ .type = EV_SW,
+ .code = SW_FRONT_PROXIMITY,
+ .gpio = OMAP4_SFH7741_SENSOR_OUTPUT_GPIO,
+ .active_low = 0,
+ }
+};
+
static struct gpio_led_platform_data sdp4430_led_data = {
.leds = sdp4430_gpio_leds,
.num_leds = ARRAY_SIZE(sdp4430_gpio_leds),
};
+static int omap_prox_activate(struct device *dev)
+{
+ gpio_set_value(OMAP4_SFH7741_ENABLE_GPIO , 1);
+ return 0;
+}
+
+static void omap_prox_deactivate(struct device *dev)
+{
+ gpio_set_value(OMAP4_SFH7741_ENABLE_GPIO , 0);
+}
+
+static struct gpio_keys_platform_data sdp4430_gpio_keys_data = {
+ .buttons= sdp4430_gpio_keys,
+ .nbuttons = ARRAY_SIZE(sdp4430_gpio_keys),
+ .enable = omap_prox_activate,
+ .disable= omap_prox_deactivate,
+};
+
+static struct platform_device sdp4430_gpio_keys_device = {
+ .name = gpio-keys,
+ .id = -1,
+ .dev= {
+ .platform_data = sdp4430_gpio_keys_data,
+ },
+};
+
static struct platform_device sdp4430_leds_gpio = {
.name = leds-gpio,
.id = -1,
@@ -161,6 +200,7 @@ static struct platform_device sdp4430_lcd_device = {
static struct platform_device *sdp4430_devices[] __initdata = {
sdp4430_lcd_device,
+ sdp4430_gpio_keys_device,
sdp4430_leds_gpio,
};
@@ -426,6 +466,26 @@ static int __init omap4_i2c_init(void)
omap_register_i2c_bus(4, 400, NULL, 0);
return 0;
}
+
+static void __init omap_sfh7741prox_init(void)
+{
+ int error;
+
+ error = gpio_request(OMAP4_SFH7741_ENABLE_GPIO, sfh7741);
+ if (error 0) {
+ pr_err(%s:failed to request GPIO %d, error %d\n,
+ __func__, OMAP4_SFH7741_ENABLE_GPIO, error);
+ return;
+ }
+
+ error = gpio_direction_output(OMAP4_SFH7741_ENABLE_GPIO , 0);
+ if (error 0) {
+ pr_err(%s: GPIO configuration failed: GPIO %d,error %d\n,
+__func__, OMAP4_SFH7741_ENABLE_GPIO, error);
+ gpio_free(OMAP4_SFH7741_ENABLE_GPIO);
+ }
+}
+
static void __init omap_4430sdp_init(void)
{
int status;
@@ -448,6 +508,7 @@ static void __init omap_4430sdp_init(void)
spi_register_board_info(sdp4430_spi_board_info,
ARRAY_SIZE(sdp4430_spi_board_info));
}
+ omap_sfh7741prox_init();
Hello Shubro,
I believe you are calling omap_sfh7741prox_init at the end of
omap_4430sdp_init
which means your sdp4430_gpio_keys_device is registered much before this.
This could mean that the probe of your gpio-keys driver could get called
before
omap_sfh7741prox_init. Assume this is the case and your probe calls into
pdata-enable
or pdata-disable which is omap_prox_activate/omap_prox_deactivate as per
this
patch, these API's will try accessing gpio APIs for
OMAP4_SFH7741_ENABLE_GPIO without
a gpio_request happening for this pin as omap_sfh7741prox_init is called
later.
Maybe such a case might never arise. But I would say you should do a
request_gpio for
OMAP4_SFH7741_ENABLE_GPIO before the driver probe is called.
Hi Thara,
Thanks for your review. Will send another patch.
Regards
Thara
Re: [PATCH 1/2] crypto: updates to enable omap aes
Hi,
Does anyone want to comment on this?
Thanks,
Dmitry
On 20/08/10 16:44, Kasatkin Dmitry (Nokia-MS/Helsinki) wrote:
Signed-off-by: Dmitry Kasatkin dmitry.kasat...@nokia.com
---
arch/arm/mach-omap2/clock2420_data.c |2 +-
arch/arm/mach-omap2/clock2430_data.c |2 +-
arch/arm/mach-omap2/clock3xxx_data.c |2 +-
arch/arm/mach-omap2/devices.c| 71
++
4 files changed, 74 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index 37d65d6..5f2066a 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1838,7 +1838,7 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, des_ick, des_ick, CK_242X),
CLK(omap-sham,ick, sha_ick, CK_242X),
CLK(omap_rng, ick, rng_ick, CK_242X),
- CLK(NULL, aes_ick, aes_ick, CK_242X),
+ CLK(omap-aes, ick, aes_ick, CK_242X),
CLK(NULL, pka_ick, pka_ick, CK_242X),
CLK(NULL, usb_fck, usb_fck, CK_242X),
CLK(musb_hdrc,fck, osc_ck,CK_242X),
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index b33118f..701a171 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -1926,7 +1926,7 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, des_ick, des_ick, CK_243X),
CLK(omap-sham,ick, sha_ick, CK_243X),
CLK(omap_rng, ick, rng_ick, CK_243X),
- CLK(NULL, aes_ick, aes_ick, CK_243X),
+ CLK(omap-aes, ick, aes_ick, CK_243X),
CLK(NULL, pka_ick, pka_ick, CK_243X),
CLK(NULL, usb_fck, usb_fck, CK_243X),
CLK(musb_hdrc,ick, usbhs_ick, CK_243X),
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index dfdce2d..c73906d 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3288,7 +3288,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, usbtll_ick, usbtll_ick,CK_3430ES2 | CK_AM35XX),
CLK(mmci-omap-hs.2, ick, mmchs3_ick,CK_3430ES2 | CK_AM35XX),
CLK(NULL, icr_ick, icr_ick, CK_343X),
- CLK(NULL, aes2_ick, aes2_ick, CK_343X),
+ CLK(omap-aes, ick, aes2_ick, CK_343X),
CLK(omap-sham,ick, sha12_ick, CK_343X),
CLK(NULL, des2_ick, des2_ick, CK_343X),
CLK(mmci-omap-hs.1, ick, mmchs2_ick,CK_3XXX),
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2dbb265..b27e7cb 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -498,6 +498,76 @@ static void omap_init_sham(void)
static inline void omap_init_sham(void) { }
#endif
+#if defined(CONFIG_CRYPTO_DEV_OMAP_AES) ||
defined(CONFIG_CRYPTO_DEV_OMAP_AES_MODULE)
+
+#ifdef CONFIG_ARCH_OMAP24XX
+static struct resource omap2_aes_resources[] = {
+ {
+ .start = OMAP24XX_SEC_AES_BASE,
+ .end= OMAP24XX_SEC_AES_BASE + 0x4C,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP24XX_DMA_AES_TX,
+ .flags = IORESOURCE_DMA,
+ },
+ {
+ .start = OMAP24XX_DMA_AES_RX,
+ .flags = IORESOURCE_DMA,
+ }
+};
+static int omap2_aes_resources_sz = ARRAY_SIZE(omap2_aes_resources);
+#else
+#define omap2_aes_resources NULL
+#define omap2_aes_resources_sz 0
+#endif
+
+#ifdef CONFIG_ARCH_OMAP34XX
+static struct resource omap3_aes_resources[] = {
+ {
+ .start = OMAP34XX_SEC_AES_BASE,
+ .end= OMAP34XX_SEC_AES_BASE + 0x4C,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = OMAP34XX_DMA_AES2_TX,
+ .flags = IORESOURCE_DMA,
+ },
+ {
+ .start = OMAP34XX_DMA_AES2_RX,
+ .flags = IORESOURCE_DMA,
+ }
+};
+static int omap3_aes_resources_sz = ARRAY_SIZE(omap3_aes_resources);
+#else
+#define omap3_aes_resources NULL
+#define omap3_aes_resources_sz 0
+#endif
+
+static struct platform_device aes_device = {
+ .name = omap-aes,
+ .id = -1,
+};
+
+static void omap_init_aes(void)
+{
+ if (cpu_is_omap24xx()) {
+ aes_device.resource = omap2_aes_resources;
+ aes_device.num_resources = omap2_aes_resources_sz;
+ } else if (cpu_is_omap34xx()) {
+ aes_device.resource = omap3_aes_resources;
+ aes_device.num_resources = omap3_aes_resources_sz;
+ } else {
+ pr_err(%s: platform not supported\n,
RE: [PATCH 8/8 v2] usb : musb: Using runtime pm apis for musb.
Hi,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, August 26, 2010 5:44 AM
To: Kalliguddi, Hema
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
Basak, Partha; Felipe Balbi; Tony Lindgren; Cousson, Benoit;
Paul Walmsley
Subject: Re: [PATCH 8/8 v2] usb : musb: Using runtime pm apis for musb.
Hema HK hem...@ti.com writes:
Calling runtime pm APIs pm_runtime_put_sync() and
pm_runtime_get_sync()
for enabling/disabling the clocks,sysconfig settings.
used omap_hwmod_enable_wakeup omap_hwmod_disable_wakeup
apis to set/clear
the wakeup enable bit.
Also need to put the USB in force standby and force idle
mode when usb not used
and set it back to smart idle and smart stndby after wakeup.
these cases are handled using the oh flags.
For omap3430 auto idle bit has to be disabled because of the
errata.So using
HWMOD_NO_OCP_AUTOIDLE flag for OMAP3430.
Signed-off-by: Hema HK hem...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/pm34xx.c |8 ++-
arch/arm/mach-omap2/usb-musb.c| 86
++--
arch/arm/plat-omap/include/plat/usb.h |9 +++-
drivers/usb/musb/musb_core.c | 12 +
drivers/usb/musb/omap2430.c | 65
+
include/linux/usb/musb.h |8 +++
6 files changed, 127 insertions(+), 61 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index 7b34201..0eb39b3 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -418,7 +418,9 @@ void omap_sram_idle(void)
omap3_core_save_context();
omap3_prcm_save_context();
/* Save MUSB context */
-musb_context_save_restore(1);
+musb_context_save_restore(save_context);
+} else {
+musb_context_save_restore(disable_clk);
Presumably the 'disable_clk' is meant to mean no need to save context,
just disable clock, in which case the function name is not really
accurate anymore.
What is needed is just a general function that takes the next power
state and let the function internals make the decision. The idle loop
should not have IP-specific logic in it.
I don't really want any IP specific logic in this part of the
idle loop.
What I really would like to see is all of this driver specific stuff
moved out of the core idle path and done before interrupts are
disabled.
If we can do this before interrups are disabled (a bit earlier in the
CPUidle path), then we can just use the normal runtime PM API and not
have to handle the special cases of doing all this black magic inside
the core idle path.
This can be done. I will have a generic usb idle and wakeup functions defined
and will be called with next/previous core state as parameter and call
Before/after the interrupts are disabled/enabled as you suggested, and handle
the required
cases in the musb module.
I will post the patch with changes after testing.
}
}
@@ -462,7 +464,9 @@ void omap_sram_idle(void)
omap3_sram_restore_context();
omap2_sms_restore_context();
/* restore MUSB context */
-musb_context_save_restore(0);
+musb_context_save_restore(restore_context);
+} else {
+musb_context_save_restore(enable_clk);
}
omap_uart_resume_idle(0);
omap_uart_resume_idle(1);
diff --git a/arch/arm/mach-omap2/usb-musb.c
b/arch/arm/mach-omap2/usb-musb.c
index 9d10440..b7736d2 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -23,6 +23,7 @@
#include linux/clk.h
#include linux/dma-mapping.h
#include linux/io.h
+#include linux/pm_runtime.h
#include linux/usb/musb.h
@@ -64,13 +65,32 @@ static struct musb_hdrc_platform_data
musb_plat = {
/* supports clock autogating */
.clk_autogated = 1,
};
+static int usb_idle_hwmod(struct omap_device *od)
+{
+struct omap_hwmod *oh = *od-hwmods;
+if (irqs_disabled())
+_omap_hwmod_idle(oh);
+else
+omap_device_idle_hwmods(od);
+return 0;
+}
+
+static int usb_enable_hwmod(struct omap_device *od)
+{
+struct omap_hwmod *oh = *od-hwmods;
+if (irqs_disabled())
+_omap_hwmod_enable(oh);
+else
+omap_device_enable_hwmods(od);
+return 0;
+}
see above. Please move the musb pre-idle outside of the interrupts
disabled part of the idle loop and you can get rid of this special
handling.
Agreed.
static u64 musb_dmamask = DMA_BIT_MASK(32);
static
RE: [PATCH 7/8 v2] OMAP: Hwmod api changes
Hi,
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, August 26, 2010 5:12 AM
To: Kalliguddi, Hema
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
Basak, Partha; Felipe Balbi; Tony Lindgren; Cousson, Benoit;
Paul Walmsley
Subject: Re: [PATCH 7/8 v2] OMAP: Hwmod api changes
Hema HK hem...@ti.com writes:
OMAP USBOTG modules has a requirement to set the auto idle
bit only after
setting smart idle bit. Modified the _sys_enable api to set
the smart idle
first and then the autoidle bit. Setting this will not have
any impact on the
other modules.
Added 2 wrapper APIs in the omap device layer for wakeup
enable/disable
and sidle/mstandby settings.
This should be a separate patch, with an description of who
the users of
this API would be and why.
Ok. I can post it as separate patch also. But I think there was plan from
Rajendra to
Enable the wakeup as part of the sysc_enable() if smart idle/standby is
configured.
If that implementation is done then there is no need of this patch.
Signed-off-by: Hema HK hem...@ti.com
Signed-off-by: Basak, Partha p-bas...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod.c | 18 +++---
arch/arm/plat-omap/include/plat/omap_device.h |2 +
arch/arm/plat-omap/omap_device.c | 43
+
3 files changed, 57 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 9bd99ad..55507a6 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -654,12 +654,6 @@ static void _sysc_enable(struct omap_hwmod *oh)
_set_master_standbymode(oh, idlemode, v);
}
-if (sf SYSC_HAS_AUTOIDLE) {
-idlemode = (oh-flags HWMOD_NO_OCP_AUTOIDLE) ?
-0 : 1;
-_set_module_autoidle(oh, idlemode, v);
-}
-
/* XXX OCP ENAWAKEUP bit? */
/*
@@ -672,6 +666,18 @@ static void _sysc_enable(struct omap_hwmod *oh)
_set_clockactivity(oh, oh-class-sysc-clockact, v);
_write_sysconfig(v, oh);
+
+/* Set the auto idle bit only after setting the smartidle bit
+ * as this is requirement for some modules like USBOTG
+ * setting this will not have any impact on the other modues.
+ */
Please fix multi-line comment style. (search for multi-line in
Documentation/CodingStyle)
Sure I will fix it.
Kevin
+if (sf SYSC_HAS_AUTOIDLE) {
+idlemode = (oh-flags HWMOD_NO_OCP_AUTOIDLE) ?
+0 : 1;
+_set_module_autoidle(oh, idlemode, v);
+}
+_write_sysconfig(v, oh);
}
/**
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 25cd9ac..c3eb07e 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -116,6 +116,8 @@ int omap_device_enable_hwmods(struct
omap_device *od);
int omap_device_disable_clocks(struct omap_device *od);
int omap_device_enable_clocks(struct omap_device *od);
+int omap_device_enable_wakeup(struct platform_device *pdev);
+int omap_device_disable_wakeup(struct platform_device *pdev);
/*
* Entries should be kept in latency order ascending
diff --git a/arch/arm/plat-omap/omap_device.c
b/arch/arm/plat-omap/omap_device.c
index d2b1609..10182b1 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -757,3 +757,46 @@ int omap_device_enable_clocks(struct
omap_device *od)
/* XXX pass along return value here? */
return 0;
}
+
+/**
+ * omap_device_enable_wakeup - Enable the wakeup bit
+ * @od: struct omap_device *od
+ *
+ * Enable the wakup bit for omap_hwmods associated
+ * with the omap_device. Returns 0.
+ */
+int omap_device_enable_wakeup(struct platform_device *pdev)
+{
+struct omap_hwmod *oh;
+struct omap_device *od = _find_by_pdev(pdev);
+int i;
+
+for (i = 0, oh = *od-hwmods; i od-hwmods_cnt; i++, oh++)
+omap_hwmod_enable_wakeup(oh);
+
+/* XXX pass along return value here? */
+return 0;
+}
+
+/**
+ * omap_device_disable_wakeup -Disable the wakeup bit
+ * @od: struct omap_device *od
+ *
+ * Disable the wakup bit for omap_hwmods associated
+ * with the omap_device. Returns 0.
+ */
+
+
+int omap_device_disable_wakeup(struct platform_device *pdev)
+{
+struct omap_hwmod *oh;
+struct omap_device *od = _find_by_pdev(pdev);
+int i;
+
+for (i = 0, oh = *od-hwmods; i od-hwmods_cnt; i++, oh++)
+omap_hwmod_disable_wakeup(oh);
+
+/* XXX pass along return value here? */
+return 0;
+}
+
--
To unsubscribe from
Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)
On 27/08/2010 20:22, Chris Ball wrote: Hi David, On Mon, Feb 22, 2010 at 02:24:17PM +, David Vrabel wrote: These patches add support for SDIO cards to the omap_hsmmc driver. Power management changes to prevent SDIO cards from being turned off and losing all state, and card interrupts. I've been unable to test these exact patches as I only have an N900 for testing and the N900 support in mainline is incomplete. Changes since v1: - (hopefully) get all cards working again by removing a second call to read MMCi_STAT in the interrupt handler. - flush posted writes after enabling/disabling SDIO interrupts. - tweak the FIXME commit on disabling FCLK to better match what really going on (at least I think so anyway). David Vrabel (2): mmc: omap_hsmmc: don't turn SDIO cards off when idle mmc: omap_hsmmc: enable SDIO card interrupts Looks like this patchset wasn't merged. Mike Rapoport replied with a fix for libertas. Would you like to resubmit it? I thought Madhu had picked this up and was going to submit it. Regardless of whether that is the case, I think it needs to be submitted by someone who can run mainline kernels (I can't) and ideally someone who can test it with SDIO cards. David -- 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 CPUIDLE: CPU Idle latency measurement
-Original Message- From: sailes...@gmail.com [mailto:sailes...@gmail.com] On Behalf Of C V, Silesh Sent: Tuesday, August 31, 2010 12:27 PM To: Sripathy, Vishwanath Cc: Kevin Hilman; vishwanath.sripa...@linaro.org; linux-omap@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement On Tue, Aug 31, 2010 at 10:28 AM, Sripathy, Vishwanath vishwanath...@ti.com wrote: -Original Message- From: Silesh C V [mailto:sailes...@gmail.com] Sent: Tuesday, August 31, 2010 9:53 AM To: Sripathy, Vishwanath Cc: Kevin Hilman; vishwanath.sripa...@linaro.org; linux-omap@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement Hi Vishwa, On Mon, Aug 30, 2010 at 6:29 PM, Sripathy, Vishwanath vishwanath...@ti.com wrote: Kevin, -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Saturday, August 28, 2010 12:45 AM To: vishwanath.sripa...@linaro.org Cc: linux-omap@vger.kernel.org; linaro-...@lists.linaro.org Subject: Re: [PATCH] OMAP CPUIDLE: CPU Idle latency measurement vishwanath.sripa...@linaro.org writes: From: Vishwanath BS vishwanath.sripa...@linaro.org This patch has instrumentation code for measuring latencies for various CPUIdle C states for OMAP. Idea here is to capture the timestamp at various phases of CPU Idle and then compute the sw latency for various c states. For OMAP, 32k clock is chosen as reference clock this as is an always on clock. wkup domain memory (scratchpad memory) is used for storing timestamps. One can see the worstcase latencies in below sysfs entries (after enabling CONFIG_CPU_IDLE_PROF in .config). This information can be used to correctly configure cpu idle latencies for various C states after adding HW latencies for each of these sw latencies. /sys/devices/system/cpu/cpu0/cpuidle/staten/actual_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/sleep_latency /sys/devices/system/cpu/cpu0/cpuidle/staten/wkup_latency THis patch is tested on OMAP ZOOM3 using kevin's pm branch. Signed-off-by: Vishwanath BS vishwanath.sripa...@linaro.org Cc: linaro-...@lists.linaro.org While I have many problems with the implementation details, I won't go into them because in general this is the wrong direction for kernel instrumentation. This approach adds quite a bit overhead to the idle path itself. With all the reads/writes from/to the scratchpad(?) and all the multiplications and divides in every idle path, as well as the wait-for-idlest in both the sleep and resume paths. The additional overhead added is non trivial. Basically, I'd like get away from custom instrumentation and measurement coded inside the kernel itself. This kind of code never stops growing and morphing into ugliness, and rarely scales well when new SoCs are added. With ftrace/perf, we can add tracepoints at specific points and use external tools to extract and analyze the delays, latencys etc. The point is to keep the minimum possible in the kernel: just the tracepoints we're interested in. The rest (calculations, averages, analysis, etc.) does not need to be in the kernel and can be done easier and with more powerful tools outside the kernel. The challenge here is that we need to take time stamp at the fag end of CPU Idle which means we have no access to DDR, MMU/Caches are disabled etc (on OMAP3). So I am not sure if we will be able to use ftrace/perf kind of tools here. If we choose to exclude assembly code part for measurement, then we will be omitting major contributor to CPU Idle latency namely ARM context save/restoration part. Also these calculations are done only when we enable CPUIDLE profiling feature. In the normal production system, these will not come into picture at all. So I am not sure latencies involved in these calculations are still an issue when we are just doing profiling. There are two other issues when we use 32k timer for latency measurement. snip + + /* take care of overflow */ + if (postidle_time preidle_time) + postidle_time += (u32) 0x; + if (wkup_time sleep_time) + wkup_time += (u32) 0x; + snip 1.We are checking postidle_time preidle_time to find out whether there had been an over flow or not. There can be situations in which the timer overflows and still we have a greater postidle_time. 2. We are doing the correction for one overflow. What happens if the timer overflows for a second or third time. Can we keep track of the number of overflows and then do the correction accordingly? Unfortunately,
RE: [PATCH 02/20] Move DSS driver register from board to mach_omap2
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
Sent: Wednesday, August 25, 2010 2:01 PM
To: Guruswamy, Senthilvadivu
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Hilman, Kevin
Subject: Re: [PATCH 02/20] Move DSS driver register from
board to mach_omap2
On Mon, 2010-08-23 at 17:57 +0200, ext Guruswamy Senthilvadivu wrote:
From: Senthilvadivu Guruswamy svad...@ti.com
Move the DSS driver register from board file to devices.c.
Regulator initialisation done with driver name instead of
the device name.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
/*
---*/
+#ifdef CONFIG_OMAP2_DSS
+
+static struct platform_device omap_display_device = {
+ .name = omapdss,
+ .id= -1,
+ .dev= {
+ .platform_data = NULL,
+ },
+};
Could we call these dss instead of display. Display sounds that it
could include panel.
This includes panel data, as we assign board_data to the platform_data in the
below function.
In fact we could even change the .name = omapdisplay instead of omapdss.
+
+void __init omap_display_init(struct omap_dss_board_info
+ *board_data)
+{
+
+ omap_display_device.dev.platform_data = board_data;
+
+ if (platform_device_register(omap_display_device) 0)
+ printk(KERN_ERR Unable to register
OMAP-Display device\n);
+
+
+ return ;
+}
+
+#else
+void __init omap_display_init(struct omap_dss_board_info
*board_data)
+{
+}
+#endif
+
+
+/*---
*/
#if defined(CONFIG_VIDEO_OMAP2_VOUT) || \
defined(CONFIG_VIDEO_OMAP2_VOUT_MODULE)
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index 1c529ce..f5da4ae 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -23,6 +23,7 @@
#include linux/list.h
#include linux/kobject.h
#include linux/device.h
+#include linux/platform_device.h
#include asm/atomic.h
#define DISPC_IRQ_FRAMEDONE(1 0)
@@ -251,6 +252,9 @@ struct omap_dss_board_info {
struct omap_dss_device *default_device;
};
+/* Init with the board info */
+extern void omap_display_init(struct omap_dss_board_info
*board_data);
+
struct omap_video_timings {
/* Unit: pixels */
u16 x_res;
diff --git a/drivers/video/omap2/dss/core.c
b/drivers/video/omap2/dss/core.c
index b3a498f..bcbb077 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -52,6 +52,7 @@ static struct {
struct regulator *vdds_dsi_reg;
struct regulator *vdds_sdi_reg;
struct regulator *vdda_dac_reg;
+ struct omap_dss_board_info *pdata;
} core;
static void dss_clk_enable_all_no_ctx(void);
@@ -501,6 +502,7 @@ static int omap_dss_probe(struct
platform_device *pdev)
int i;
core.pdev = pdev;
+ core.pdata = pdev-dev.platform_data;
Why is pdata stored? It is available through pdev anyway.
Yes, could be avoided.
Tomi
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH 16/20] Get DISPC base addr with platform device
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
Sent: Wednesday, August 25, 2010 6:43 PM
To: Guruswamy, Senthilvadivu
Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Hilman, Kevin
Subject: Re: [PATCH 16/20] Get DISPC base addr with platform device
On Mon, 2010-08-23 at 17:58 +0200, ext Guruswamy Senthilvadivu wrote:
From: Senthilvadivu Guruswamy svad...@ti.com
DISPC Base addr got from the platform device. Hadrcoding of base
addr removed.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/dss/dispc.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c
b/drivers/video/omap2/dss/dispc.c
index ae18b5f..8a7a086 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -40,7 +40,6 @@
#include dss.h
/* DISPC */
-#define DISPC_BASE 0x48050400
#define DISPC_SZ_REGS SZ_1K
I guess *_SZ_REGS are not needed anymore for any of the blocks.
Its still needed for the definition of array size used for save/restore,
Unless we go for pointers to do dynamic allocation of register size.
Tomi
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH 05/20] Move dss platform driver to dss.c
-Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] Sent: Wednesday, August 25, 2010 2:20 PM To: Guruswamy, Senthilvadivu Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Hilman, Kevin Subject: Re: [PATCH 05/20] Move dss platform driver to dss.c On Mon, 2010-08-23 at 17:57 +0200, ext Guruswamy Senthilvadivu wrote: From: Senthilvadivu Guruswamy svad...@ti.com dsshw_probe and remove functions are moved to dss.c To maintain the order of init, through the dsshw_probe, omap_dss_init2 is made as device_init_call_sync. Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com Why is the omap_dsshw_driver moved to dss.c, but the hw_driver for other blocks stay in core.c? Ideally the plan is to move all the IP blocks to its corresponding files. As I mentioned in the TODO list I will try to move dispc, venc, rfbi, dsi in the next versions. And generally about dss.c: There are confusingly two things DSS may refer to: 1) the whole display subsystem, including DSI/RFBI etc 2) the small main block inside DSS, meaning the few DSS_* registers. It would be good to have different names for those, but at the time being they are both DSS. In some patch I saw names like dss_dispc. Perhaps we could have dss_dss there too. Although it looks a bit confusing too =). dss.c is meant to handle the DSS_* registers, so it's about case 2. And so it doesn't contain general DSS stuff, like clock allocation etc., those have been in core.c. I'm not sure if this comment is valid for this patch, but at least [PATCH 07/20] Move clock functions from core driver to dss driver sounds like dss.c is used like case 1. Once opt clocks are available for each of the DSS IP blocks like venc, Dsi also, then I should be able to move the clocks to the respective files Leaving only dss related clocks in dss.c. So the aim is to maintain dss.c restricted to few DSS_* registers. Tomi
Re: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
1. Input transport via evdev is very convenient 2. There is no other standard alternative Once there is standard interface for such sensors they will happily use it and will not look back. I think the fact that most of the interest in IIO is how do we make an IIO/Input bridge speaks volumes. Sure, for a particular cell phone there is no ambiguity, the sensor has certain functionality assigned that is well known. But does this mean that we should not expect parts being reused at all anymore? If non-input uses later need non-input interfaces they can switch to that with an input bridge when there is one and when it happens, which probably won't. I am unsure how you would play a game with GPS as an input device. In a non-game context take a look at things like the British Museum application that allows you to view wherever you are and as it was long ago by fishing out a relevant photograph as you walk around. In a game context can I suggest the Zombies game is an example ? Alan -- 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: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
IIO which is currently in staging. Except we had ALS before that as a layer and Linus vetoed it. So there is zero faith in IIO ever going anywhere. Instead we now have about ten different light sensor APIs to the point developers are writing a toolkit userspace plugin for *each* sensor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] crypto: omap-aes: OMAP2/3 AES hw accelerator driver
To this actually.
Thanks
On 20/08/10 16:44, Kasatkin Dmitry (Nokia-MS/Helsinki) wrote:
Signed-off-by: Dmitry Kasatkin dmitry.kasat...@nokia.com
---
drivers/crypto/Kconfig|8 +
drivers/crypto/Makefile |1 +
drivers/crypto/omap-aes.c | 948
+
3 files changed, 957 insertions(+), 0 deletions(-)
create mode 100644 drivers/crypto/omap-aes.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index ea0b386..742089b 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -243,4 +243,12 @@ config CRYPTO_DEV_OMAP_SHAM
OMAP processors have SHA1/MD5 hw accelerator. Select this if you
want to use the OMAP module for SHA1/MD5 algorithms.
+config CRYPTO_DEV_OMAP_AES
+ tristate Support for OMAP AES hw engine
+ depends on ARCH_OMAP2 || ARCH_OMAP3
+ select CRYPTO_AES
+ help
+ OMAP processors have AES module accelerator. Select this if you
+ want to use the OMAP module for AES algorithms.
+
endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 6dbbe00..64289c6 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -9,4 +9,5 @@ obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
obj-$(CONFIG_CRYPTO_DEV_IXP4XX) += ixp4xx_crypto.o
obj-$(CONFIG_CRYPTO_DEV_PPC4XX) += amcc/
obj-$(CONFIG_CRYPTO_DEV_OMAP_SHAM) += omap-sham.o
+obj-$(CONFIG_CRYPTO_DEV_OMAP_AES) += omap-aes.o
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
new file mode 100644
index 000..799ca51
--- /dev/null
+++ b/drivers/crypto/omap-aes.c
@@ -0,0 +1,948 @@
+/*
+ * Cryptographic API.
+ *
+ * Support for OMAP AES HW acceleration.
+ *
+ * Copyright (c) 2010 Nokia Corporation
+ * Author: Dmitry Kasatkin dmitry.kasat...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
published
+ * by the Free Software Foundation.
+ *
+ */
+
+#define pr_fmt(fmt) %s: fmt, __func__
+
+#include linux/err.h
+#include linux/module.h
+#include linux/init.h
+#include linux/errno.h
+#include linux/kernel.h
+#include linux/clk.h
+#include linux/platform_device.h
+#include linux/scatterlist.h
+#include linux/dma-mapping.h
+#include linux/io.h
+#include linux/crypto.h
+#include linux/interrupt.h
+#include crypto/scatterwalk.h
+#include crypto/aes.h
+
+#include plat/cpu.h
+#include plat/dma.h
+
+/* OMAP TRM gives bitfields as start:end, where start is the higher bit
+ number. For example 7:0 */
+#define FLD_MASK(start, end) (((1 ((start) - (end) + 1)) - 1) (end))
+#define FLD_VAL(val, start, end) (((val) (end)) FLD_MASK(start, end))
+
+#define AES_REG_KEY(x) (0x1C - ((x ^ 0x01) * 0x04))
+#define AES_REG_IV(x) (0x20 + ((x) * 0x04))
+
+#define AES_REG_CTRL 0x30
+#define AES_REG_CTRL_CTR_WIDTH (1 7)
+#define AES_REG_CTRL_CTR (1 6)
+#define AES_REG_CTRL_CBC (1 5)
+#define AES_REG_CTRL_KEY_SIZE (3 3)
+#define AES_REG_CTRL_DIRECTION (1 2)
+#define AES_REG_CTRL_INPUT_READY (1 1)
+#define AES_REG_CTRL_OUTPUT_READY (1 0)
+
+#define AES_REG_DATA 0x34
+#define AES_REG_DATA_N(x) (0x34 + ((x) * 0x04))
+
+#define AES_REG_REV0x44
+#define AES_REG_REV_MAJOR 0xF0
+#define AES_REG_REV_MINOR 0x0F
+
+#define AES_REG_MASK 0x48
+#define AES_REG_MASK_SIDLE (1 6)
+#define AES_REG_MASK_START (1 5)
+#define AES_REG_MASK_DMA_OUT_EN(1 3)
+#define AES_REG_MASK_DMA_IN_EN (1 2)
+#define AES_REG_MASK_SOFTRESET (1 1)
+#define AES_REG_AUTOIDLE (1 0)
+
+#define AES_REG_SYSSTATUS 0x4C
+#define AES_REG_SYSSTATUS_RESETDONE(1 0)
+
+#define DEFAULT_TIMEOUT(5*HZ)
+
+#define FLAGS_MODE_MASK0x000f
+#define FLAGS_ENCRYPT BIT(0)
+#define FLAGS_CBC BIT(1)
+#define FLAGS_GIV BIT(2)
+
+#define FLAGS_NEW_KEY BIT(4)
+#define FLAGS_NEW_IV BIT(5)
+#define FLAGS_INIT BIT(6)
+#define FLAGS_FAST BIT(7)
+#define FLAGS_BUSY 8
+
+struct omap_aes_ctx {
+ struct omap_aes_dev *dd;
+
+ int keylen;
+ u32 key[AES_KEYSIZE_256 / sizeof(u32)];
+ unsigned long flags;
+};
+
+struct omap_aes_reqctx {
+ unsigned long mode;
+};
+
+#define OMAP_AES_QUEUE_LENGTH 1
+#define OMAP_AES_CACHE_SIZE0
+
+struct omap_aes_dev {
+ struct list_headlist;
+ unsigned long phys_base;
+ void __iomem*io_base;
+ struct clk *iclk;
+ struct omap_aes_ctx *ctx;
+
Re: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
My hope is that we can make use of a well known and uniform API for all input devices in a device, be it a keypad, touchscreen, accelerometer, magnetometer, gyro, or whatever. If only we could agree what input devices are... Is that the right test for some of these devices. Surely the question is what devices can be meaningfully represented by the input API. The device range is always going to be quite large and people want to use the API because it means things just work. They can wire their home made surfboard unit and tilt sensors up to the PC and tuxracer just goes. They can wire pedals and a current meter to it and use it as the speed input in bzflag to simulate bicycle tanks etc.. Alan -- 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] cbus: Fix compile by converting ioctl calls to unlocked_ioctl calls
Locked .ioctl is gone from struct file_operations by commit b19dd42
so these cbus drivers don't compile. Also it seems there is no need for BKL
anyway in these drivers.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
Cc: Felipe Balbi m...@felipebalbi.com
---
drivers/cbus/retu-user.c |5 ++---
drivers/cbus/retu-wdt.c |6 +++---
drivers/cbus/tahvo-user.c |5 ++---
3 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/cbus/retu-user.c b/drivers/cbus/retu-user.c
index 953d92a..c36f356 100644
--- a/drivers/cbus/retu-user.c
+++ b/drivers/cbus/retu-user.c
@@ -270,8 +270,7 @@ static int retu_close(struct inode *inode, struct file
*filp)
/*
* Device control (ioctl)
*/
-static int retu_ioctl(struct inode *inode, struct file *filp,
- unsigned int cmd, unsigned long arg)
+static long retu_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
struct retu_tahvo_write_parms par;
int ret;
@@ -360,7 +359,7 @@ static unsigned retu_poll(struct file *filp, struct
poll_table_struct *pt)
static struct file_operations retu_user_fileops = {
.owner = THIS_MODULE,
- .ioctl = retu_ioctl,
+ .unlocked_ioctl = retu_ioctl,
.read = retu_read,
.release = retu_close,
.poll = retu_poll
diff --git a/drivers/cbus/retu-wdt.c b/drivers/cbus/retu-wdt.c
index 6070a05..3d83cdc 100644
--- a/drivers/cbus/retu-wdt.c
+++ b/drivers/cbus/retu-wdt.c
@@ -184,8 +184,8 @@ static ssize_t retu_wdt_write(struct file *file, const char
__user *data,
return len;
}
-static int retu_wdt_ioctl(struct inode *inode, struct file *file,
- unsigned int cmd, unsigned long arg)
+static long retu_wdt_ioctl(struct file *file, unsigned int cmd,
+ unsigned long arg)
{
int new_margin;
@@ -246,7 +246,7 @@ static int __devinit retu_wdt_ping(void)
static const struct file_operations retu_wdt_fops = {
.owner = THIS_MODULE,
.write = retu_wdt_write,
- .ioctl = retu_wdt_ioctl,
+ .unlocked_ioctl = retu_wdt_ioctl,
.open = retu_wdt_open,
.release= retu_wdt_release,
};
diff --git a/drivers/cbus/tahvo-user.c b/drivers/cbus/tahvo-user.c
index bd30f06..9cfc71c 100644
--- a/drivers/cbus/tahvo-user.c
+++ b/drivers/cbus/tahvo-user.c
@@ -254,8 +254,7 @@ static int tahvo_close(struct inode *inode, struct file
*filp)
/*
* Device control (ioctl)
*/
-static int tahvo_ioctl(struct inode *inode, struct file *filp,
- unsigned int cmd, unsigned long arg)
+static long tahvo_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
struct retu_tahvo_write_parms par;
int ret;
@@ -342,7 +341,7 @@ static unsigned tahvo_poll(struct file *filp, struct
poll_table_struct *pt)
static struct file_operations tahvo_user_fileops = {
.owner = THIS_MODULE,
- .ioctl = tahvo_ioctl,
+ .unlocked_ioctl = tahvo_ioctl,
.read = tahvo_read,
.release = tahvo_close,
.poll = tahvo_poll
--
1.7.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/2] omap2: McBSP: Remove mux code for OMAP2420 McBSP2 and do cleanups
This 'legacy' OMAP2420 McBSP2 muxing code is currently broken after recent
conversion to new mux code. The omap_mcbsp_request calling this code is
usually called after booting whereas the omap_mux_init_signal is __init
marked so null pointer dereference would occur.
Fix this by removing the muxing code and let the bootloader or board file to
do it if necessary. Remove also omap2_mcbsp_ops as there is no use for it.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
---
This is v2. No any other changes than based on top of commit 451fd82 that
came from ASoC tree for 2.6.36 and which causes conflicts with v1.
---
arch/arm/mach-omap2/mcbsp.c | 39 ---
1 files changed, 0 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 467aae2..88b8790 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -23,29 +23,6 @@
#include plat/cpu.h
#include plat/mcbsp.h
-#include mux.h
-
-static void omap2_mcbsp2_mux_setup(void)
-{
- omap_mux_init_signal(eac_ac_sclk.mcbsp2_clkx, OMAP_PULL_ENA);
- omap_mux_init_signal(eac_ac_fs.mcbsp2_fsx, OMAP_PULL_ENA);
- omap_mux_init_signal(eac_ac_din.mcbsp2_dr, OMAP_PULL_ENA);
- omap_mux_init_signal(eac_ac_dout.mcbsp2_dx, OMAP_PULL_ENA);
- omap_mux_init_gpio(117, OMAP_PULL_ENA);
- /*
-* TODO: Need to add MUX settings for OMAP 2430 SDP
-*/
-}
-
-static void omap2_mcbsp_request(unsigned int id)
-{
- if (cpu_is_omap2420() (id == OMAP_MCBSP2))
- omap2_mcbsp2_mux_setup();
-}
-
-static struct omap_mcbsp_ops omap2_mcbsp_ops = {
- .request= omap2_mcbsp_request,
-};
#ifdef CONFIG_ARCH_OMAP2420
static struct omap_mcbsp_platform_data omap2420_mcbsp_pdata[] = {
@@ -55,7 +32,6 @@ static struct omap_mcbsp_platform_data omap2420_mcbsp_pdata[]
= {
.dma_tx_sync= OMAP24XX_DMA_MCBSP1_TX,
.rx_irq = INT_24XX_MCBSP1_IRQ_RX,
.tx_irq = INT_24XX_MCBSP1_IRQ_TX,
- .ops= omap2_mcbsp_ops,
},
{
.phys_base = OMAP24XX_MCBSP2_BASE,
@@ -63,7 +39,6 @@ static struct omap_mcbsp_platform_data omap2420_mcbsp_pdata[]
= {
.dma_tx_sync= OMAP24XX_DMA_MCBSP2_TX,
.rx_irq = INT_24XX_MCBSP2_IRQ_RX,
.tx_irq = INT_24XX_MCBSP2_IRQ_TX,
- .ops= omap2_mcbsp_ops,
},
};
#define OMAP2420_MCBSP_PDATA_SZARRAY_SIZE(omap2420_mcbsp_pdata)
@@ -82,7 +57,6 @@ static struct omap_mcbsp_platform_data omap2430_mcbsp_pdata[]
= {
.dma_tx_sync= OMAP24XX_DMA_MCBSP1_TX,
.rx_irq = INT_24XX_MCBSP1_IRQ_RX,
.tx_irq = INT_24XX_MCBSP1_IRQ_TX,
- .ops= omap2_mcbsp_ops,
},
{
.phys_base = OMAP24XX_MCBSP2_BASE,
@@ -90,7 +64,6 @@ static struct omap_mcbsp_platform_data omap2430_mcbsp_pdata[]
= {
.dma_tx_sync= OMAP24XX_DMA_MCBSP2_TX,
.rx_irq = INT_24XX_MCBSP2_IRQ_RX,
.tx_irq = INT_24XX_MCBSP2_IRQ_TX,
- .ops= omap2_mcbsp_ops,
},
{
.phys_base = OMAP2430_MCBSP3_BASE,
@@ -98,7 +71,6 @@ static struct omap_mcbsp_platform_data omap2430_mcbsp_pdata[]
= {
.dma_tx_sync= OMAP24XX_DMA_MCBSP3_TX,
.rx_irq = INT_24XX_MCBSP3_IRQ_RX,
.tx_irq = INT_24XX_MCBSP3_IRQ_TX,
- .ops= omap2_mcbsp_ops,
},
{
.phys_base = OMAP2430_MCBSP4_BASE,
@@ -106,7 +78,6 @@ static struct omap_mcbsp_platform_data
omap2430_mcbsp_pdata[] = {
.dma_tx_sync= OMAP24XX_DMA_MCBSP4_TX,
.rx_irq = INT_24XX_MCBSP4_IRQ_RX,
.tx_irq = INT_24XX_MCBSP4_IRQ_TX,
- .ops= omap2_mcbsp_ops,
},
{
.phys_base = OMAP2430_MCBSP5_BASE,
@@ -114,7 +85,6 @@ static struct omap_mcbsp_platform_data
omap2430_mcbsp_pdata[] = {
.dma_tx_sync= OMAP24XX_DMA_MCBSP5_TX,
.rx_irq = INT_24XX_MCBSP5_IRQ_RX,
.tx_irq = INT_24XX_MCBSP5_IRQ_TX,
- .ops= omap2_mcbsp_ops,
},
};
#define OMAP2430_MCBSP_PDATA_SZARRAY_SIZE(omap2430_mcbsp_pdata)
@@ -133,7 +103,6 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
.dma_tx_sync= OMAP24XX_DMA_MCBSP1_TX,
.rx_irq = INT_24XX_MCBSP1_IRQ_RX,
.tx_irq = INT_24XX_MCBSP1_IRQ_TX,
- .ops= omap2_mcbsp_ops,
.buffer_size= 0x80, /* The FIFO has 128 locations */
},
{
@@ -143,7 +112,6 @@ static struct
Re: [PATCH] OMAP: McBSP: Do not enable SRG in slave mode
On Tue, 31 Aug 2010 11:11:44 +0300 Peter Ujfalusi peter.ujfal...@nokia.com wrote: McBSP SRG (Sample Rate Generator) and FSG (Frame Sync Generator) is only needed to be enabled, when McBSP is master. In McBSP slave mode, the SRG, and FSG can be kept disabled, which might save some power at the end in this configuration. Signed-off-by: Peter Ujfalusi peter.ujfal...@nokia.com --- Hello Jarkko, I have tested this on OMAP3, but I think this should be applicable for other OMAP versions as well. When McBSP was slave the audio worked fine, when I left the SRG, and FSG disabled. Sounds logical if there is no need to keep SRG and FSG active when McBSP is slave. I tested this on N810. Acked-by: Jarkko Nikula jhnik...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] omap2: McBSP: Remove mux code for OMAP2420 McBSP2 and do cleanups
On Tuesday 31 August 2010 13:12:56 ext Jarkko Nikula wrote: This 'legacy' OMAP2420 McBSP2 muxing code is currently broken after recent conversion to new mux code. The omap_mcbsp_request calling this code is usually called after booting whereas the omap_mux_init_signal is __init marked so null pointer dereference would occur. Fix this by removing the muxing code and let the bootloader or board file to do it if necessary. Remove also omap2_mcbsp_ops as there is no use for it. Signed-off-by: Jarkko Nikula jhnik...@gmail.com Sounds reasonable. Acked-by: Peter Ujfalusi peter.ujfal...@nokia.com -- 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] I2C: Fix for suspend/resume issue in i2c-core
On Mon, Aug 30, 2010 at 11:43:23AM -0700, Kevin Hilman wrote:
Vishwanath BS vishwanath...@ti.com writes:
In current i2c core driver, pm_runtime_set_active call from
i2c_device_pm_resume
is not balanced by pm_runtime_set_suspended call from i2c_device_pm_suspend.
pm_runtime_set_active called from resume path will increase the child_count
of
the device's parent. However, matching pm_runtime_set_suspended is not
called
in suspend routine because of which child_count of the device's parent
is not balanced, preventing the parent device to idle.
Issue has been fixed by adding pm_runtime_set_suspended call inside suspend
reoutine which will make sure that child_counts are balanced.
This fix has been tested on OMAP4430.
Signed-off-by: Partha Basak p-bas...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Ben Dooks ben-li...@fluff.org
Also Cc'ing Mark Brown as original author of runtime PM for i2-core.
Also Jean Delvare who maintains the I2C core. To be honest Rafael did
all the actual work here (and has since rewritten the code anyway).
---
drivers/i2c/i2c-core.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 6649176..3146bff
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -196,14 +196,22 @@ static int i2c_legacy_resume(struct device *dev)
static int i2c_device_pm_suspend(struct device *dev)
{
const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm : NULL;
+ int ret;
if (pm_runtime_suspended(dev))
return 0;
if (pm)
- return pm-suspend ? pm-suspend(dev) : 0;
+ ret = pm-suspend ? pm-suspend(dev) : 0;
+ else
+ ret = i2c_legacy_suspend(dev, PMSG_SUSPEND);
- return i2c_legacy_suspend(dev, PMSG_SUSPEND);
+ if (!ret) {
+ pm_runtime_disable(dev);
+ pm_runtime_set_suspended(dev);
+ pm_runtime_enable(dev);
+ }
+ return ret;
}
static int i2c_device_pm_resume(struct device *dev)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] cbus: Fix compile by converting ioctl calls to unlocked_ioctl calls
On Tue, 31 Aug 2010 13:09:11 +0300, Jarkko Nikula jhnik...@gmail.com wrote: Locked .ioctl is gone from struct file_operations by commit b19dd42 so these cbus drivers don't compile. Also it seems there is no need for BKL anyway in these drivers. Signed-off-by: Jarkko Nikula jhnik...@gmail.com Cc: Felipe Balbi m...@felipebalbi.com FWIW, Acked-by: Felipe Balbi m...@felipebalbi.com -- balbi -- 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: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
On 08/31/10 10:44, Alan Cox wrote: 1. Input transport via evdev is very convenient 2. There is no other standard alternative Once there is standard interface for such sensors they will happily use it and will not look back. I think the fact that most of the interest in IIO is how do we make an IIO/Input bridge speaks volumes. It isn't. Most of the interest on LKML might be, but that is because all of those interested in the 'industrial' side of things are keeping their discussion on linux-...@vger list. Most of the noise on LKML may be on the input bridge side, but most of the actual work and current developers / users are not. The needs we have are not all met by input, (and nor should they be) hence the reason IIO exists. Take a look at the work Analog have been doing with it. There are few devices in their set that would fall into the blurred area we are debating here. 3 phase energy meters for input anyone? Sure, for a particular cell phone there is no ambiguity, the sensor has certain functionality assigned that is well known. But does this mean that we should not expect parts being reused at all anymore? If non-input uses later need non-input interfaces they can switch to that with an input bridge when there is one and when it happens, which probably won't. I guess I'll just have to write the bridge :) To put in userspace code for a particular device should be trivial. It may take a little more time and thought to get a configurable general version in place. It may not be the right option for some devices, but it will provide a means if someone wants to take one of Analog's rather nice IMU's or a 200G accelerometer and use it to drive their gaming rig ;) Also, there are always devices using analog sensors connected to much more general purpose ADCs to further blur the boundaries. There has to be divide somewhere. Dmitry is merely trying to avoid a flood of inappropriate drivers. I am unsure how you would play a game with GPS as an input device. In a non-game context take a look at things like the British Museum application that allows you to view wherever you are and as it was long ago by fishing out a relevant photograph as you walk around. In a game context can I suggest the Zombies game is an example ? Alan Jonathan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] crypto: updates to enable omap aes
On Tue, Aug 31, 2010 at 11:52:27AM +0300, Dmitry Kasatkin wrote: Hi, Does anyone want to comment on this? Please be patient. Your patches are still in my queue. Resending them is only going to slow them down. Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
On 08/31/10 10:46, Alan Cox wrote: IIO which is currently in staging. Except we had ALS before that as a layer and Linus vetoed it. So there is zero faith in IIO ever going anywhere. I have more faith - those developing it have limited time, but we will get there. (another plug for anyone interested to get involved!) IIRC Linus and others disliked ALS for two reasons... * It was too specific. They didn't want to fragment sensors types that much. * Userspace is used to dealing input and in some cases a light sensor can look like a switch. The first certainly doesn't apply to IIO, the second will be fixed via an input bridge. If Linus isn't happy we'll just have to work on convincing him. Instead we now have about ten different light sensor APIs to the point developers are writing a toolkit userspace plugin for *each* sensor. I agree. This is a big problem. We have in the past talked about allowing interfaces to be standardized even if the underlying subsystem is still open to debate. We did openly debate the interface for some time with ALS... After we went over this with IIO we decided to match / extend hwmon where ever possible. Obviously that only covers sysfs interfaces, but it is a start. We also openly debate all new elements (and in theory at least keep the admittedly huge abi document up to date). A large set of doc updates and code fixes relating to the interface from Manuel Stahl went to Greg KH this morning as result of his work on general userspace tools. On the chrdev side of things life is much more complex as performance and overheads become an issue. Jonathan p.s. Matthias Nyman's email address is bouncing so I've removed it from the cc list. -- 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 10/20] Move rfbi init to rfbi probe
-Original Message-
From: Cousson, Benoit
Sent: Friday, August 27, 2010 7:25 PM
To: Guruswamy, Senthilvadivu
Cc: linux-omap@vger.kernel.org; tomi.valkei...@nokia.com;
p...@pwsan.com; Hilman, Kevin
Subject: Re: [PATCH 10/20] Move rfbi init to rfbi probe
On 8/23/2010 5:57 PM, Guruswamy, Senthilvadivu wrote:
From: Senthilvadivu Guruswamysvad...@ti.com
[...]
@@ -199,12 +199,6 @@ static int omap_dss_probe(struct
platform_device *pdev)
dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
- r = rfbi_init();
- if (r) {
- DSSERR(Failed to initialize rfbi\n);
- goto err_rfbi;
- }
-
r = dpi_init(pdev);
if (r) {
DSSERR(Failed to initialize dpi\n);
@@ -278,8 +272,6 @@ err_venc:
err_dispc:
dpi_exit();
err_dpi:
- rfbi_exit();
-err_rfbi:
dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
return r;
@@ -296,7 +288,6 @@ static int omap_dss_remove(struct
platform_device *pdev)
venc_exit();
dispc_exit();
dpi_exit();
- rfbi_exit();
if (cpu_is_omap34xx()) {
dsi_exit();
sdi_exit();
@@ -357,11 +348,21 @@ static int omap_dsi1hw_remove(struct
platform_device *pdev)
/* RFBI HW IP initialisation */
static int omap_rfbihw_probe(struct platform_device *pdev)
{
- return 0;
+ int r;
+ dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
+ r = rfbi_init();
+ if (r) {
+ DSSERR(Failed to initialize rfbi\n);
+ goto err_rfbi;
+ }
+err_rfbi:
+ dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
+ return r;
There is probably something wrong in this sequence? The same thing is
done whatever the return state (except the error log).
You should probably return 0 and not disable the clocks if
the rfbi_init
is successful.
[Senthil] I don't see any wrong in functionality, but creates confusion.
Let me init r =0. dss_clk_disable has to be called at the end of probe
irrespective of error. I can remove err_rfbi: since no specific error handling
is getting done now.
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 15/20] Use platform device to get DSS base addr
-Original Message-
From: Cousson, Benoit
Sent: Tuesday, August 24, 2010 3:13 AM
To: Guruswamy, Senthilvadivu
Cc: linux-omap@vger.kernel.org; tomi.valkei...@nokia.com;
p...@pwsan.com; Hilman, Kevin
Subject: Re: [PATCH 15/20] Use platform device to get DSS base addr
On 8/23/2010 5:58 PM, Guruswamy, Senthilvadivu wrote:
From: Senthilvadivu Guruswamysvad...@ti.com
[...]
+ struct resource *dss_mem;
- dss.base = ioremap(DSS_BASE, DSS_SZ_REGS);
+ dss_mem = platform_get_resource(dss.pdev, IORESOURCE_MEM, 0);
platform_get_resource can fail, so you have to check the
returned value.
Please note that this comment applies as well to all the
other patches
from 16 to 19.
[Senthil] Yes, I would incorporate in my next version.
Benoit
+ dss.base = ioremap(dss_mem-start, resource_size(dss_mem));
if (!dss.base) {
DSSERR(can't ioremap DSS\n);
r = -ENOMEM;
--
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 00/20] HWMOD Adaptation for DSS
-Original Message-
From: Cousson, Benoit
Sent: Tuesday, August 24, 2010 3:10 AM
To: Guruswamy, Senthilvadivu
Cc: linux-omap@vger.kernel.org; tomi.valkei...@nokia.com;
p...@pwsan.com; Hilman, Kevin
Subject: Re: [RFC PATCH 00/20] HWMOD Adaptation for DSS
On 8/23/2010 5:57 PM, Guruswamy, Senthilvadivu wrote:
From: Senthilvadivu Guruswamysvad...@ti.com
[...]
2) Usage of regulators by different drivers needs to implemented.
For Eg: Regulator used by VENC is moved to venc driver.
But vdda_dac would be
needed by DPI and DSI as well. Need to verify if a patch
like this would work.
/* VPLL2 for digital video outputs */
static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
REGULATOR_SUPPLY(vdds_dsi, omapdss),
+ REGULATOR_SUPPLY(vdds_dsi, dss_dsi1),
You can add any consumer you want for a given regulator
supply as soon
as you have a valid dev or dev_name.
[Senthil] Thanks. I will try this out.
};
3) SYSCONFIG of each of the dss HW IP has to be removed
from the driver.
HWMOD framework is supposed to take care of it. This
change would be done in
the next version of the patch series.
4) OMAP2 HWMOD database is yet to be generated.
5) Number of DSS HW IPs in a silicon are hardcoded in devices.c.
It is not evident from HWMOD database. Need to find a
cleaner way to register for OMAP2,3,4.
What does that mean exactly? Could you elaborate?
[Senthil] From HWMOD database, it is not possible to find out how many of the
DSS related HW Ips are present. Say in OMAP3 one DSI is present and HDMI is
not.
In OMAP4 2 DSI is present and HDMI is.
So in devices.c if I have to do a omaphwmod_lookup(), I have to hardcode the
lookup names for omap3 and omap4 explicitly.
6) Module support for omapdss driver as per current DSS2 design.
What about the usage of clock framework, or the management of DSS
features, we already discussed?
What about OMAP4?
[Senthil] DSS internal clocks generated from internal DPLLs are to planned to
be
in separate patch series.
The DSS_FEATURES like number of pipelines in omap3/omap4, tiler/vrfb support,
are being posted as separate patch series by Taneja Archit.
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
--
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 04/20] Create platform_driver for each DSS HW IP
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, August 27, 2010 5:22 AM
To: Guruswamy, Senthilvadivu
Cc: linux-omap@vger.kernel.org; tomi.valkei...@nokia.com;
p...@pwsan.com
Subject: Re: [PATCH 04/20] Create platform_driver for each DSS HW IP
Guruswamy Senthilvadivu svad...@ti.com writes:
From: Senthilvadivu Guruswamy svad...@ti.com
Platform driver of DSS HW IP are to be registered in sequence before
the omapdss platform driver is registered.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
---
drivers/video/omap2/dss/core.c | 121
1 files changed, 121 insertions(+), 0 deletions(-)
+/* DSS HW IP initialisation */
+static int omap_dsshw_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int omap_dsshw_remove(struct platform_device *pdev)
+{
+ return 0;
+}
It's not customary to create dummy, empty functions in one patch and
then fill them in later. In this case, you create them here,
move them
in PATCH 05/20, then fill them in later.
It would be easier to review if you created the platform_drivers when
needed.
Anyways, I'm not crazy about this approach, but Tomi can decide.
[Senthil] As I mentioned in my TODO list, I will try to move all the
probe/remove to
the corresponding driver files as directly in my next version.
+/* DISPC HW IP initialisation */
+static int omap_dispchw_probe(struct platform_device *pdev)
+{
+ return 0;
+}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 03/20] Build omap_device for each DSS HW IP
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, August 27, 2010 5:03 AM
To: Guruswamy, Senthilvadivu
Cc: linux-omap@vger.kernel.org; tomi.valkei...@nokia.com;
p...@pwsan.com
Subject: Re: [PATCH 03/20] Build omap_device for each DSS HW IP
Guruswamy Senthilvadivu svad...@ti.com writes:
From: Senthilvadivu Guruswamy svad...@ti.com
Looks up the HWMOD database for each of the given DSS HW IP
and builds omap_device which inturn does the platform device
register for each of DSS HW IP
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
[...]
+ for (i = 0; i 5; i++) {
+ l = snprintf(oh_name[i], MAX_OMAP_DSS_HWMOD_NAME_LEN,
+oh_name[i]);
+ WARN(l = MAX_OMAP_DSS_HWMOD_NAME_LEN,
+ String buffer overflow in DSS device setup\n);
+
+ oh = omap_hwmod_lookup(oh_name[i]);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name[i]);
+ return ;
+ }
+ strcpy(pdata.name, oh_name[i]);
+ pdata.board_data= board_data;
+ pdata.board_data-get_last_off_on_transaction_id = NULL;
+ pdata.device_enable= omap_device_enable;
+ pdata.device_idle = omap_device_idle;
+ pdata.device_shutdown = omap_device_shutdown;
Please use runtime PM API in driver instead of calling these
using pdata
function pointers.
[Senthil] when I used pm_runtime API, the clocks were not getting enabled.
Probably the complete support is not yet in this pm branch.
Once available I would change to pm_runtime and discard the use_count variable
too.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 01/20] DSS HWMOD database generation for OMAP3
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, August 27, 2010 5:01 AM To: Guruswamy, Senthilvadivu Cc: linux-omap@vger.kernel.org; tomi.valkei...@nokia.com; p...@pwsan.com Subject: Re: [PATCH 01/20] DSS HWMOD database generation for OMAP3 Guruswamy Senthilvadivu svad...@ti.com writes: From: Senthilvadivu Guruswamy svad...@ti.com OMAP3 HWMOD database for DSS is added and is applicable for 34xx and 36xx. Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com minor nit Re: $SUBJECT. Please title the hwmod data patches using something like this: OMAP3: hwmod data: add DSS, DISPC, DSI, RFBI, VENC [Senthil] Thanks, I would change it. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH 00/20] HWMOD Adaptation for DSS
-Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, August 27, 2010 5:28 AM To: Guruswamy, Senthilvadivu Cc: linux-omap@vger.kernel.org; tomi.valkei...@nokia.com; p...@pwsan.com Subject: Re: [RFC PATCH 00/20] HWMOD Adaptation for DSS Guruswamy Senthilvadivu svad...@ti.com writes: RFC focus on the proposed design of the HWMOD adaptation to the current DSS driver. DSS, DISPC, DSI, RFBI, VENC are made as platform drivers each corresponding to the HWMOD class in the HWMOD database. Hi Senthi, Nice job on this series. I have a handful of small comments on the individual patches, but I also wanted to say thanks for doing an excellent job of breaking this up into small, self-contained patches. It makes it so much easier to review small patches with well-written changelogs. [Senthil] Thanks! Thanks! Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC: PATCH] OMAP: hwmod: New API to modify the autoidle bits of sysconfig register
On Tuesday 31 August 2010 01:43 PM, Felipe Balbi wrote:
On Tue, 31 Aug 2010 10:53:36 +0530, kishona0393...@ti.com wrote:
Though driver shouldn't be using hwmod directly, there is no
corresponding API in omap_device to do the same. So we are planning to
store the omap_hwmod structure in platform_data during
arch_initcall (in the callback to omap_hwmod_for_each_by_class). So
whenever the
AUTOIDLE bits need to be reset or set, we pass the stored
omap_hwmod structure to this API. Currently, the functions that needs
AUTOIDLE
bit to be modified (omap_st_on, omap_st_off) resides in plat-omap.
couldn't your API instead be something like:
int omap_hwmod_set_autoidle(struct device *dev, u8 autoidle)
{
struct omap_hwmod *oh = dev_to_hwmod(dev);
if (!oh)
return -ENODEV;
[...]
return 0;
}
Balbi,
I couldn't find dev_to_hwmod() function. Do you actually mean
implementing dev_to_hwmod() function?
I created this API based on omap_hwmod_set_slave_idlemode()
present in lo (omap_hwmod.c) for changing the smart idle bit
of SYSCONFIG register.
-Kishon
--
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 6/8 v2] usb: musb: Offmode fix for idle path
Kalliguddi, Hema hem...@ti.com writes:
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, August 26, 2010 5:40 AM
To: Kalliguddi, Hema
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
Mankad, Maulik Ojas; Felipe Balbi; Tony Lindgren; Cousson,
Benoit; Paul Walmsley
Subject: Re: [PATCH 6/8 v2] usb: musb: Offmode fix for idle path
Hema HK hem...@ti.com writes:
With OMAP core-off support musb was not functional as
context was getting
lost after wakeup from core-off. And also musb was blocking
the core-off
after loading the gadget driver even with no cable connected
sometimes.
Added the conext save/restore api in the platform layer which will
be called in the idle and wakeup path.
Changed the usb sysconfig settings as per the usbotg functional spec.
When the device is not used, configure to force idle and
force standby mode.
When it is being used, configure in smart standby and smart
idle mode.
So while attempting to coreoff the usb is configured to
force standby and
force idle mode, after wakeup configured in smart idle and
smart standby.
You don't describe the new .clk_autogated field added here. That part
should be a separate patch as it's not directly related to
$SUBJECT patch.
In OMAP for USB there is no need to disable the interface clock. But for the
other
platforms like davinci which uses mentor USB IP clock is not auto gated so
There is a need to disbale the clock when .suspend API defined in the driver
is called.
So introduced a flag in the platform to enable/disable the clock
In .supend and .resume APIs appropriately in the driver code.
Yes, I understand why it's there, and just suggested that it should be
documented and done as a separate patch.
Yes. It may not be directly related to $SUBJECT patch, but I am reusing
.suspend and .resume APIs for context save and restore during idle path.
Because of that this fix as part of the patch.
Signed-off-by: Hema HK hem...@ti.com
Signed-off-by: Maulik Mankad x0082...@ti.com
Cc: Felipe Balbi felipe.ba...@nokia.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/pm34xx.c |5 +++
arch/arm/mach-omap2/usb-musb.c| 42
-
arch/arm/plat-omap/include/plat/usb.h |2 +
drivers/usb/musb/musb_core.c | 10 +++
drivers/usb/musb/musb_core.h |1 -
drivers/usb/musb/omap2430.c | 48
++---
include/linux/usb/musb.h |6
7 files changed, 102 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index fb4994a..7b34201 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -39,6 +39,7 @@
#include plat/gpmc.h
#include plat/dma.h
#include plat/dmtimer.h
+#include plat/usb.h
#include asm/tlbflush.h
@@ -416,6 +417,8 @@ void omap_sram_idle(void)
if (core_next_state == PWRDM_POWER_OFF) {
omap3_core_save_context();
omap3_prcm_save_context();
+ /* Save MUSB context */
+ musb_context_save_restore(1);
}
}
@@ -458,6 +461,8 @@ void omap_sram_idle(void)
omap3_prcm_restore_context();
omap3_sram_restore_context();
omap2_sms_restore_context();
+ /* restore MUSB context */
+ musb_context_save_restore(0);
}
omap_uart_resume_idle(0);
omap_uart_resume_idle(1);
diff --git a/arch/arm/mach-omap2/usb-musb.c
b/arch/arm/mach-omap2/usb-musb.c
index c228cc0..9d10440 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -35,6 +35,7 @@
static const char name[] = musb_hdrc;
#define MAX_OMAP_MUSB_HWMOD_NAME_LEN 16
+struct omap_hwmod *oh_p =NULL;
static struct musb_hdrc_config musb_config = {
.multipoint = 1,
@@ -59,6 +60,9 @@ static struct musb_hdrc_platform_data musb_plat = {
* mode, and should be passed to usb_musb_init().
*/
.power = 50, /* up to 100 mA */
+
+ /* supports clock autogating */
+ .clk_autogated = 1,
This appears unrelated, and should be a separate patch.
};
static u64 musb_dmamask = DMA_BIT_MASK(32);
@@ -97,7 +101,7 @@ void __init usb_musb_init(struct
omap_musb_board_data *board_data)
musb_plat.mode = board_data-mode;
musb_plat.extvbus = board_data-extvbus;
pdata = musb_plat;
-
+ oh_p = oh;
od = omap_device_build(name, bus_id, oh, pdata,
sizeof(struct musb_hdrc_platform_data),
omap_musb_latency,
@@ -116,8 +120,44 @@ void __init
Re: [PATCH 8/8 v2] usb : musb: Using runtime pm apis for musb.
Kalliguddi, Hema hem...@ti.com writes:
static int musb_platform_resume(struct musb *musb)
{
u32 l;
+struct device *dev = musb-controller;
+struct musb_hdrc_platform_data *pdata = dev-platform_data;
+struct platform_device *pdev = to_platform_device(dev);
if (!musb-clock)
return 0;
otg_set_suspend(musb-xceiv, 0);
-
-if (musb-set_clock)
-musb-set_clock(musb-clock, 1);
-else
-clk_enable(musb-clock);
-
-l = musb_readl(musb-mregs, OTG_SYSCONFIG);
-l = ~ENABLEWAKEUP; /* disable wakeup */
-musb_writel(musb-mregs, OTG_SYSCONFIG, l);
-
+pm_runtime_enable(dev);
+pm_runtime_get_sync(dev);
+pdata-enable_wakeup(pdev);
I think you mean -disable_wakeup() here, right?
No I meant enable_wakeup only here. When smart idle/standby is enabled,
wakeup bit has to be set to generate the s-wakeup when the devie is in idle
and system is in ret.
OK, I'm confused.
The code being removed just above disables wakeups and the new code
enables wakeups.
Also, you don't ever call -disable_wakeup() elsewhere in the patch.
You call pdata-enable_wakeup() both in suspend and resume.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/20] Create platform_driver for each DSS HW IP
Guruswamy, Senthilvadivu svad...@ti.com writes:
[...]
+/* DSS HW IP initialisation */
+static int omap_dsshw_probe(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static int omap_dsshw_remove(struct platform_device *pdev)
+{
+ return 0;
+}
It's not customary to create dummy, empty functions in one patch and
then fill them in later. In this case, you create them here,
move them
in PATCH 05/20, then fill them in later.
It would be easier to review if you created the platform_drivers when
needed.
Anyways, I'm not crazy about this approach, but Tomi can decide.
[Senthil] As I mentioned in my TODO list, I will try to move all the
probe/remove to
the corresponding driver files as directly in my next version.
Sorry, I missed that in your TODO list.
Thanks,
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/20] Build omap_device for each DSS HW IP
Guruswamy, Senthilvadivu svad...@ti.com writes:
[...]
From: Senthilvadivu Guruswamy svad...@ti.com
Looks up the HWMOD database for each of the given DSS HW IP
and builds omap_device which inturn does the platform device
register for each of DSS HW IP
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
[...]
+ for (i = 0; i 5; i++) {
+ l = snprintf(oh_name[i], MAX_OMAP_DSS_HWMOD_NAME_LEN,
+ oh_name[i]);
+ WARN(l = MAX_OMAP_DSS_HWMOD_NAME_LEN,
+ String buffer overflow in DSS device setup\n);
+
+ oh = omap_hwmod_lookup(oh_name[i]);
+ if (!oh) {
+ pr_err(Could not look up %s\n, oh_name[i]);
+ return ;
+ }
+ strcpy(pdata.name, oh_name[i]);
+ pdata.board_data= board_data;
+ pdata.board_data-get_last_off_on_transaction_id = NULL;
+ pdata.device_enable= omap_device_enable;
+ pdata.device_idle = omap_device_idle;
+ pdata.device_shutdown = omap_device_shutdown;
Please use runtime PM API in driver instead of calling these using
pdata function pointers.
[Senthil] when I used pm_runtime API, the clocks were not getting enabled.
Probably the complete support is not yet in this pm branch.
Once available I would change to pm_runtime and discard the use_count
variable too.
Runtime PM is available and working in current pm-core branch
(a.k.a. pm-wip/hwmods-omap4) Several other hwmod conversions are using
that branch to get working runtime PM.
Rather than use the pdata- methods, please debug why runtime PM isn't
working for your driver.
Thanks,
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: 4430sdp board support for the the GPIO keys
omap 4430sdp board support for the GPIO keys.
The proximity sensor is connected to GPIO and is registered as a
GPIO key.
- Making the default state of the sensor off at bootup
- The init is called before platform_add_devices
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 61 +++
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 9447644..f31d68e 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -20,6 +20,7 @@
#include linux/usb/otg.h
#include linux/spi/spi.h
#include linux/i2c/twl.h
+#include linux/gpio_keys.h
#include linux/regulator/machine.h
#include linux/leds.h
@@ -40,6 +41,8 @@
#define ETH_KS8851_IRQ 34
#define ETH_KS8851_POWER_ON48
#define ETH_KS8851_QUART 138
+#define OMAP4_SFH7741_SENSOR_OUTPUT_GPIO 184
+#define OMAP4_SFH7741_ENABLE_GPIO 188
static struct gpio_led sdp4430_gpio_leds[] = {
{
@@ -77,11 +80,47 @@ static struct gpio_led sdp4430_gpio_leds[] = {
};
+static struct gpio_keys_button sdp4430_gpio_keys[] = {
+ {
+ .desc = Proximity Sensor,
+ .type = EV_SW,
+ .code = SW_FRONT_PROXIMITY,
+ .gpio = OMAP4_SFH7741_SENSOR_OUTPUT_GPIO,
+ .active_low = 0,
+ }
+};
+
static struct gpio_led_platform_data sdp4430_led_data = {
.leds = sdp4430_gpio_leds,
.num_leds = ARRAY_SIZE(sdp4430_gpio_leds),
};
+static int omap_prox_activate(struct device *dev)
+{
+ gpio_set_value(OMAP4_SFH7741_ENABLE_GPIO , 1);
+ return 0;
+}
+
+static void omap_prox_deactivate(struct device *dev)
+{
+ gpio_set_value(OMAP4_SFH7741_ENABLE_GPIO , 0);
+}
+
+static struct gpio_keys_platform_data sdp4430_gpio_keys_data = {
+ .buttons= sdp4430_gpio_keys,
+ .nbuttons = ARRAY_SIZE(sdp4430_gpio_keys),
+ .enable = omap_prox_activate,
+ .disable= omap_prox_deactivate,
+};
+
+static struct platform_device sdp4430_gpio_keys_device = {
+ .name = gpio-keys,
+ .id = -1,
+ .dev= {
+ .platform_data = sdp4430_gpio_keys_data,
+ },
+};
+
static struct platform_device sdp4430_leds_gpio = {
.name = leds-gpio,
.id = -1,
@@ -161,6 +200,7 @@ static struct platform_device sdp4430_lcd_device = {
static struct platform_device *sdp4430_devices[] __initdata = {
sdp4430_lcd_device,
+ sdp4430_gpio_keys_device,
sdp4430_leds_gpio,
};
@@ -426,11 +466,32 @@ static int __init omap4_i2c_init(void)
omap_register_i2c_bus(4, 400, NULL, 0);
return 0;
}
+
+static void __init omap_sfh7741prox_init(void)
+{
+ int error;
+
+ error = gpio_request(OMAP4_SFH7741_ENABLE_GPIO, sfh7741);
+ if (error 0) {
+ pr_err(%s:failed to request GPIO %d, error %d\n,
+ __func__, OMAP4_SFH7741_ENABLE_GPIO, error);
+ return;
+ }
+
+ error = gpio_direction_output(OMAP4_SFH7741_ENABLE_GPIO , 0);
+ if (error 0) {
+ pr_err(%s: GPIO configuration failed: GPIO %d,error %d\n,
+__func__, OMAP4_SFH7741_ENABLE_GPIO, error);
+ gpio_free(OMAP4_SFH7741_ENABLE_GPIO);
+ }
+}
+
static void __init omap_4430sdp_init(void)
{
int status;
omap4_i2c_init();
+ omap_sfh7741prox_init();
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
omap_serial_init();
omap4_twl6030_hsmmc_init(mmc);
--
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: 4430sdp board support for the the GPIO keys
Shubhrajyoti D shubhrajy...@ti.com writes: omap 4430sdp board support for the GPIO keys. The proximity sensor is connected to GPIO and is registered as a GPIO key. - Making the default state of the sensor off at bootup - The init is called before platform_add_devices Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com I still think the subject is wrong: You're adding support for the proximity sensor *using* GPIO keys, not adding support for GPIO keys: OMAP: 4430SDP: add proximity sensor via GPIO keys or something like that. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC: PATCH] OMAP: hwmod: New API to modify the autoidle bits of sysconfig register
On 8/31/2010 4:41 PM, ABRAHAM, KISHON VIJAY wrote:
On Tuesday 31 August 2010 01:43 PM, Felipe Balbi wrote:
On Tue, 31 Aug 2010 10:53:36 +0530, kishona0393...@ti.com wrote:
Though driver shouldn't be using hwmod directly, there is no
corresponding API in omap_device to do the same. So we are planning to
store the omap_hwmod structure in platform_data during
arch_initcall (in the callback to omap_hwmod_for_each_by_class). So
whenever the
AUTOIDLE bits need to be reset or set, we pass the stored
omap_hwmod structure to this API. Currently, the functions that needs
AUTOIDLE
bit to be modified (omap_st_on, omap_st_off) resides in plat-omap.
couldn't your API instead be something like:
int omap_hwmod_set_autoidle(struct device *dev, u8 autoidle)
{
struct omap_hwmod *oh = dev_to_hwmod(dev);
if (!oh)
return -ENODEV;
[...]
return 0;
}
Balbi,
I couldn't find dev_to_hwmod() function. Do you actually mean
implementing dev_to_hwmod() function?
I created this API based on omap_hwmod_set_slave_idlemode()
present in lo (omap_hwmod.c) for changing the smart idle bit
of SYSCONFIG register.
-Kishon
That API does not exist. And since a device can contains several hwmods,
like in your case, this API cannot exist in that form.
The real issue is that we do not want to expose any API relative to PRCM
management to the driver. Even if you hide that behind some pdata, it is
still the driver that will call it.
I know that some IPs like MUSB or McBSP requires some unusual idle mode
change due to HW bugs, but in general, you should try to find a better
way to handle that in the core framework if possible.
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: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
On Tue, Aug 31, 2010 at 10:44:46AM +0100, Alan Cox wrote: 1. Input transport via evdev is very convenient 2. There is no other standard alternative Once there is standard interface for such sensors they will happily use it and will not look back. I think the fact that most of the interest in IIO is how do we make an IIO/Input bridge speaks volumes. Like Jonathan mentioned, we so far only hear from mobile users here on LKML. Sure, for a particular cell phone there is no ambiguity, the sensor has certain functionality assigned that is well known. But does this mean that we should not expect parts being reused at all anymore? If non-input uses later need non-input interfaces they can switch to that with an input bridge when there is one and when it happens, which probably won't. Would there even be an argument which subsystem to use if IIO-input bridge existed today? Because if the answer is no then push into input is driven by convenience and not because it is the right solution. I am unsure how you would play a game with GPS as an input device. In a non-game context take a look at things like the British Museum application that allows you to view wherever you are and as it was long ago by fishing out a relevant photograph as you walk around. If application does take something as an input it does not make it necessarily a human interface device. By this reasoning cameras should be represented as an input devices (why, some applications take input from it), hwmon should be input as well (detect your move from Arkhangelsk to Cairo by changes in your chassis temperature while under the same load?). Serial ports? Input. Sound - speech recognition should be implemented as an input device converting microphone input directly into EV_KEY/KEY_x stream bypassing sound subsystem completely? And if someone decides to use it differently - why, let's just write a second driver. This way is madness. I really believe that input should represent purely human interface devices, not arbitrary data acquisition devices. In a game context can I suggest the Zombies game is an example ? I am not familiar with this game, sorry. -- Dmitry -- 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 10/20] Move rfbi init to rfbi probe
On 8/31/2010 2:57 PM, Guruswamy, Senthilvadivu wrote:
-Original Message-
From: Cousson, Benoit
Sent: Friday, August 27, 2010 7:25 PM
To: Guruswamy, Senthilvadivu
Cc: linux-omap@vger.kernel.org; tomi.valkei...@nokia.com;
p...@pwsan.com; Hilman, Kevin
Subject: Re: [PATCH 10/20] Move rfbi init to rfbi probe
On 8/23/2010 5:57 PM, Guruswamy, Senthilvadivu wrote:
From: Senthilvadivu Guruswamysvad...@ti.com
[...]
@@ -199,12 +199,6 @@ static int omap_dss_probe(struct
platform_device *pdev)
dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
- r = rfbi_init();
- if (r) {
- DSSERR(Failed to initialize rfbi\n);
- goto err_rfbi;
- }
-
r = dpi_init(pdev);
if (r) {
DSSERR(Failed to initialize dpi\n);
@@ -278,8 +272,6 @@ err_venc:
err_dispc:
dpi_exit();
err_dpi:
- rfbi_exit();
-err_rfbi:
dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
return r;
@@ -296,7 +288,6 @@ static int omap_dss_remove(struct
platform_device *pdev)
venc_exit();
dispc_exit();
dpi_exit();
- rfbi_exit();
if (cpu_is_omap34xx()) {
dsi_exit();
sdi_exit();
@@ -357,11 +348,21 @@ static int omap_dsi1hw_remove(struct
platform_device *pdev)
/* RFBI HW IP initialisation */
static int omap_rfbihw_probe(struct platform_device *pdev)
{
- return 0;
+ int r;
+ dss_clk_enable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
+ r = rfbi_init();
+ if (r) {
+ DSSERR(Failed to initialize rfbi\n);
+ goto err_rfbi;
+ }
+err_rfbi:
+ dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK1 | DSS_CLK_54M);
+ return r;
There is probably something wrong in this sequence? The same thing is
done whatever the return state (except the error log).
You should probably return 0 and not disable the clocks if
the rfbi_init
is successful.
[Senthil] I don't see any wrong in functionality, but creates confusion.
Let me init r =0. dss_clk_disable has to be called at the end of probe
irrespective of error. I can remove err_rfbi: since no specific error handling
is getting done now.
It is indeed very confusing, so in that case you can just remove the label.
You don't have to initialize r to zero, since you are always calling
rfbi_init that will initialize 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: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
If non-input uses later need non-input interfaces they can switch to that with an input bridge when there is one and when it happens, which probably won't. Would there even be an argument which subsystem to use if IIO-input bridge existed today? Because if the answer is no then push into input is driven by convenience and not because it is the right solution. Probably because most of these devices have nothing to do with industrial I/O at all. If application does take something as an input it does not make it necessarily a human interface device. By this reasoning cameras should be represented as an input devices (why, some applications take input That's not what I asked. I really believe that input should represent purely human interface devices, not arbitrary data acquisition devices. That tends to make little sense where the API is the same and applications benefit enormously from consistency. I'd rather have an input-IIO bridge because that is the real world today ! The question is what does the API make *sense* for. Not what can you use the API for. Unix (and Linux) are enormously powerful because of the use of common interfaces and APIs. So a voltmeter really makes no sense. It's not a set of keys and it doesn't give X/Y/Z style readings. Nor does a camera. But a lot of things do fit this to varying degrees. I'm actually more dubious than Linus about ALS - because ALS tends not produce 'events' but to be sampled, and there are significant power implications to unnecessary polling. See it as a curse of success - because you got the API right and made it flexible people want to use it. And the more it's used the less special code is needed in user or kernel space for PDAs and phones - instead they just work. In a game context can I suggest the Zombies game is an example ? I am not familiar with this game, sorry. It uses GPS and networking to stage an 'in real world' zombie dodging game. Alan -- 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: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
On Tue, Aug 31, 2010 at 05:59:37PM +0100, Alan Cox wrote: If non-input uses later need non-input interfaces they can switch to that with an input bridge when there is one and when it happens, which probably won't. Would there even be an argument which subsystem to use if IIO-input bridge existed today? Because if the answer is no then push into input is driven by convenience and not because it is the right solution. Probably because most of these devices have nothing to do with industrial I/O at all. Data acquisition devices then? If application does take something as an input it does not make it necessarily a human interface device. By this reasoning cameras should be represented as an input devices (why, some applications take input That's not what I asked. I really believe that input should represent purely human interface devices, not arbitrary data acquisition devices. That tends to make little sense where the API is the same and applications benefit enormously from consistency. I'd rather have an input-IIO bridge because that is the real world today ! The question is what does the API make *sense* for. Not what can you use the API for. Unix (and Linux) are enormously powerful because of the use of common interfaces and APIs. So a voltmeter really makes no sense. It's not a set of keys and it doesn't give X/Y/Z style readings. Nor does a camera. But a lot of things do fit this to varying degrees. I'm actually more dubious than Linus about ALS - because ALS tends not produce 'events' but to be sampled, and there are significant power implications to unnecessary polling. See it as a curse of success - because you got the API right and made it flexible people want to use it. I knew it! Its all Vojtech's fault. And the more it's used the less special code is needed in user or kernel space for PDAs and phones - instead they just work. OK, so let's say we start moving some of the devices into input. Which ones we consider suitable for input? I guess some 3-digit accelerometers, what else? Also, what new event types would we need? Let's take GPS - I do not think that ABS_X and ABS_Y are the best events to be used for such devices: I am trying to allow applications being ignorant of what exact device they are talking to and rather concentrate on device capabilities (list of events supported). GPS is sufficiently different from a tablet/touchscreen; while some might want to use both as inputs to a game most applications would want to know which one which. Also, GPS, liek ALS, would probably be polling, no? -- Dmitry -- 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: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
IMHO I think sensors no more can be considered as non-input-devices. Things changed too much in recent years. Input sources have now a very different use as before (smartphones, Tablets and handheld devices...) They all have much inputs that come mostly from sensors. So the definition of an input device is something that the user can interact on it ? Maybe we should consider input devices to be made from 1 to N sensors with some filtering blocks which only expose the useful data. If we think like this an input device can be made from sub parts which can be bare sensors. (Many sensors are exposed as Human.Interface.Devices which are mainly input devices) i -- 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: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
linux-iio cc'd for comments on the code dump at end of email..
On 08/31/10 17:59, Alan Cox wrote:
If non-input uses later need non-input interfaces they can switch to that
with an input bridge when there is one and when it happens, which
probably won't.
Would there even be an argument which subsystem to use if IIO-input
bridge existed today? Because if the answer is no then push into input
is driven by convenience and not because it is the right solution.
Probably because most of these devices have nothing to do with industrial
I/O at all.
Hmm.. The 'industrial' bit is somewhat misleading. Ultimately it was the
best name anyone came up with a while ago. Happy to change it if someone
gives me a better suggestion!
If application does take something as an input it does not make it
necessarily a human interface device. By this reasoning cameras should
be represented as an input devices (why, some applications take input
That's not what I asked.
I really believe that input should represent purely human interface
devices, not arbitrary data acquisition devices.
That tends to make little sense where the API is the same and
applications benefit enormously from consistency. I'd rather have an
input-IIO bridge because that is the real world today !
Really basic proof of concept at bottom of this email...
It's nasty and not remotely general. General version will be a bit
longer. This is just a hack combining the lis3l02dqbuffersimple.c example
and a uinput example googling gave me... I have no idea if I got the uinput
stuff right, but it's spitting out data that looks about right...
The question is what does the API make *sense* for. Not what can you use
the API for. Unix (and Linux) are enormously powerful because of the use
of common interfaces and APIs.
So a voltmeter really makes no sense. It's not a set of keys and it
doesn't give X/Y/Z style readings. Nor does a camera. But a lot of things
do fit this to varying degrees.
I'm actually more dubious than Linus about ALS - because ALS tends not
produce 'events' but to be sampled, and there are significant power
implications to unnecessary polling.
It covered the drivers we had at the time. Sadly most ALS sensors don't
produce trivial, 'the light level has changed'. Actually the only one I think
did was the ACPI interface. They do provide interrupts, just one has to reset
suitable thresholds about the current light level. A game that isn't trivial
to get right in a driver. Not sure anyone has taken this on as yet
See it as a curse of success - because you got the API right and made it
flexible people want to use it. And the more it's used the less special
code is needed in user or kernel space for PDAs and phones - instead they
just work.
In a game
context can I suggest the Zombies game is an example ?
I am not familiar with this game, sorry.
It uses GPS and networking to stage an 'in real world' zombie dodging
game.
Anyhow, here is a code dump of a very nasty proof of concept for an IIO
to input bridge in userspace. If I'd known it would be this easy I'd
have done this ages ago. I'm away for next couple of days, so a more
general version won't occur until next week unless someone else picks it
up.
---
/* IIO to uinput userspace bridge example for specific device.
*
* Copyright (c) 2010 Jonathan Cameron
* Sometime in the past Luke Casson (or at least it is on his website)
*
* 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 to illustrate how an IIO to input bridge would more or less
* work.
* Some comments in line to say where there have been short cuts taken. Denote
S:
*/
#include dirent.h
#include fcntl.h
#include stdio.h
#include errno.h
#include sys/stat.h
#include sys/dir.h
#include linux/types.h
#include iio_utils.h
#include linux/input.h
#include linux/uinput.h
int send_event(int fd, __u16 type, __u16 code, __s32 value)
{
struct input_event event;
memset(event, 0, sizeof(event));
event.type = type;
event.code = code;
event.value = value;
if (write(fd, event, sizeof(event)) != sizeof(event)) {
fprintf(stderr, Error on send_event);
return -1;
}
return 0;
}
/* S: these would need to provided as configuration so
* that the bridge would know which devices to bridge to input
*/
const char *device_name = lis3l02dq;
const char *trigger_name_base = lis3l02dq-dev;
/*
* S: obtain these from combination of configuration file for
* bridge and buffer description in sysfs for the IIO device
*/
const int num_vals = 3;
/* S: not actually using the timestamp as I couldn't be bothered
* to check what format uinput needed
*/
const int scan_ts = 1;
/* S: this is way to long as it means you only get data a couple
* of times a second.
*/
const int buf_len = 128;
/*
*
Re: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
On 08/31/10 18:24, Mohamed Ikbel Boulabiar wrote: IMHO I think sensors no more can be considered as non-input-devices. Things changed too much in recent years. Input sources have now a very different use as before (smartphones, Tablets and handheld devices...) They all have much inputs that come mostly from sensors. So the definition of an input device is something that the user can interact on it ? Sadly it is no where near as clean a definition as we would like. There are too many fuzzy regions. Lots of the devices are used for both consumer devices and for other forms of high end input. A lot of consumer devices use general purpose ADCs at a tiny percentage of their maximum data rates because they are cheap and standard. Maybe we should consider input devices to be made from 1 to N sensors with some filtering blocks which only expose the useful data. That's what you get via input (to a certain extent). But a lot of what people want in applications is derived data and some of the algorithms to do that are very complex and certainly should not be in the kernel. Again this may be a case for using uinput to push your derived data back into kernel space. (Did I mention that I rather like uinput now I've started playing with it :) If we think like this an input device can be made from sub parts which can be bare sensors. (Many sensors are exposed as Human.Interface.Devices which are mainly input devices) HID is just fine if the aggregation is nicely handled by a separate processor on the device (which is what is actually happening). It is large, messy and an enormous number of devices abuse it for things that aren't input. They have exactly the same issue that Dmitry is trying to avoid. Just because you can use an interface to handle your data, doesn't make it the right thing to do! Hence HID is a very nice illustration in lots of ways ;) Jonathan -- 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: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
On Mon, 30 Aug 2010, Linus Torvalds wrote: On Monday, August 30, 2010, Dmitry Torokhov dmitry.torok...@gmail.com wrote: But do you believe that input should be the primary residence for the devices when they are only _sometimes_ used as input devices? Or it would make sense to employ a converter from XXX to input (either purely in-kernel or userspace over uinput)? Umm... You've brought that up before as an objection, but what _is_ that other model that you would convert from? IOW what *is* that XXX that you talk about? So I think accelerometers etc should be seen as input devices for the simple reason that (a) They really *are* input devices in all the most common cases. If you have a phone with an accelerometer, it really is used as an input device quite like a joystick. At least some of the time, an accelerometer is more like part of a joystick. You can have phones with accelerometers at both ends, where the input events produced depend on the combination of the readings, with each of the individual accelerometers being a device that is also available by itself. You can have phones which can be used in various orientations, where the logical left direction depends on the orientation. With a joystick, the device that the driver is for has the assignment of motions to inputs; for an accelerometer in a phone, the assignment is outside the scope of the chip, and it would make sense to have a second driver that takes non-chip-specific accelerometer output (per-accelerometer, per-axis) and maps it to input events based on how the user holds the box the chip is in. It's like having a whole bunch of button devices; you want them to be exposed as a keyboard, and the sensor hardware reports press and release, but something else is needed to know which hardware button is which key. Similarly, you want to know about how the user is moving the device, and you may need to process various sorts of raw data to produce anything meaningful to applications. -Daniel *This .sig left intentionally blank* -- 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: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
snip
Anyhow, here is a code dump of a very nasty proof of concept for an IIO
to input bridge in userspace. If I'd known it would be this easy I'd
have done this ages ago. I'm away for next couple of days, so a more
general version won't occur until next week unless someone else picks it
up.
One thing I forgot to mention. IIO uses two different paths for what
become events in input. The main data stream (which is predictable)
comes via the buffer interface handled here. Threshold type events
(and all the weird and wonderful variants) come via a second chrdev
if the device supports them. These are trivial to add to the below
and I'll put them in the generalized version (basically a second fd
and a call to select + a big translation table - which may want to
be configurable...)
---
/* IIO to uinput userspace bridge example for specific device.
*
* Copyright (c) 2010 Jonathan Cameron
* Sometime in the past Luke Casson (or at least it is on his website)
*
* 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 to illustrate how an IIO to input bridge would more or less
* work.
* Some comments in line to say where there have been short cuts taken.
Denote S:
*/
#include dirent.h
#include fcntl.h
#include stdio.h
#include errno.h
#include sys/stat.h
#include sys/dir.h
#include linux/types.h
#include iio_utils.h
#include linux/input.h
#include linux/uinput.h
int send_event(int fd, __u16 type, __u16 code, __s32 value)
{
struct input_event event;
memset(event, 0, sizeof(event));
event.type = type;
event.code = code;
event.value = value;
if (write(fd, event, sizeof(event)) != sizeof(event)) {
fprintf(stderr, Error on send_event);
return -1;
}
return 0;
}
/* S: these would need to provided as configuration so
* that the bridge would know which devices to bridge to input
*/
const char *device_name = lis3l02dq;
const char *trigger_name_base = lis3l02dq-dev;
/*
* S: obtain these from combination of configuration file for
* bridge and buffer description in sysfs for the IIO device
*/
const int num_vals = 3;
/* S: not actually using the timestamp as I couldn't be bothered
* to check what format uinput needed
*/
const int scan_ts = 1;
/* S: this is way to long as it means you only get data a couple
* of times a second.
*/
const int buf_len = 128;
/*
* Obviously this would be infinite
*/
const int num_loops = 40;
/* S: Calculate this form sysfs params */
int size_from_scanmode(int num_vals, int timestamp)
{
if (num_vals timestamp)
return 16;
else if (timestamp)
return 8;
else
return num_vals*2;
}
int main(int argc, char **argv)
{
int ret;
int i, j, k, toread;
FILE *fp_ev;
int fp;
char *trigger_name, *dev_dir_name, *buf_dir_name;
char *data;
size_t read_size;
struct iio_event_data dat;
int dev_num, trig_num;
char *buffer_access, *buffer_event;
const char *iio_dir = /sys/bus/iio/devices/;
int scan_size;
float gain = 1;
/* New uinput stuff */
int fd;
struct uinput_user_dev device;
memset(device, 0, sizeof device);
fd=open(/dev/input/uinput, O_WRONLY);
strcpy(device.name, lis3l02dq accelerometer);
/* No idea what sort of bus I should use... */
device.id.bustype = BUS_VIRTUAL;
device.id.vendor = 1;
device.id.product = 1;
device.id.version = 1;
for (i=0; i ABS_MAX; i++) {
device.absmax[i] = -1;
device.absmin[i] = -1;
device.absfuzz[i] = -1;
device.absflat[i] = -1;
}
/* S: These can all be derived from sysfs attributes,
* though we need the format spec Manuel suggested the
* other day. Typically IIO never cares about range,
* just format.
*/
device.absmin[ABS_X] = -2048;
device.absmax[ABS_X] = 2047;
device.absfuzz[ABS_X] = 0;
device.absflat[ABS_X] = 0;
device.absmin[ABS_Y] = -2048;
device.absmax[ABS_Y] = 2047;
device.absfuzz[ABS_Y] = 0;
device.absflat[ABS_Y] = 0;
device.absmin[ABS_Z] = -2048;
device.absmax[ABS_Z] = 2047;
device.absfuzz[ABS_Z] = 0;
device.absflat[ABS_Z] = 0;
if (write(fd, device, sizeof(device)) != sizeof(device)) {
fprintf(stderr, error setup\n);
return -1;
}
if (ioctl(fd, UI_SET_EVBIT, EV_ABS) 0) {
fprintf(stderr, error evbit abs\n);
return -1;
}
for(i = REL_X; i = REL_Z; i++)
if (ioctl(fd, UI_SET_ABSBIT, i) 0) {
RE: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)
OK, so let's say we start moving some of the devices into input. Which ones we consider suitable for input? I guess some 3-digit accelerometers, what else? Also, what new event types would we need? Let's take GPS - I do not think that ABS_X and ABS_Y are the best events to be used for such devices: I am trying to allow applications being ignorant of what exact device they are talking to and rather concentrate on device capabilities (list of events supported). GPS is sufficiently different from a tablet/touchscreen; while some might want to use both as inputs to a game most applications would want to know which one which. Also, GPS, liek ALS, would probably be polling, no? -- Dmitry -- Hello Dmitry, Current-generation accelerometers typically have some functions built-in that provide an interrupt signal under certain conditions. For instance, orientation and motion detection can be calculated at the hardware level to reduce the need for constant polling and software to handle the algorithms. Some devices have built-in tap detection, which can require data at several hundred samples per second, something that is certainly not efficiently supported in software. I have been using ABS_MISC to pack 4 bytes of interrupt status information, but it might be a good idea to consider having a separate field for: Orientation (screen rotation) Motion Detection (or sleep detection) Tap Detection Regards, Chris Hudson -- 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] I2C: Fix for suspend/resume issue in i2c-core
On Tuesday, August 31, 2010, Mark Brown wrote:
On Mon, Aug 30, 2010 at 11:43:23AM -0700, Kevin Hilman wrote:
Vishwanath BS vishwanath...@ti.com writes:
In current i2c core driver, pm_runtime_set_active call from
i2c_device_pm_resume
is not balanced by pm_runtime_set_suspended call from
i2c_device_pm_suspend.
pm_runtime_set_active called from resume path will increase the
child_count of
the device's parent. However, matching pm_runtime_set_suspended is not
called
in suspend routine because of which child_count of the device's parent
is not balanced, preventing the parent device to idle.
Issue has been fixed by adding pm_runtime_set_suspended call inside
suspend
reoutine which will make sure that child_counts are balanced.
This fix has been tested on OMAP4430.
Signed-off-by: Partha Basak p-bas...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Ben Dooks ben-li...@fluff.org
Also Cc'ing Mark Brown as original author of runtime PM for i2-core.
Also Jean Delvare who maintains the I2C core. To be honest Rafael did
all the actual work here (and has since rewritten the code anyway).
Sorry for the delay.
The fix looks reasonable to me.
Thanks,
Rafael
---
drivers/i2c/i2c-core.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 6649176..3146bff
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -196,14 +196,22 @@ static int i2c_legacy_resume(struct device *dev)
static int i2c_device_pm_suspend(struct device *dev)
{
const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm : NULL;
+ int ret;
if (pm_runtime_suspended(dev))
return 0;
if (pm)
- return pm-suspend ? pm-suspend(dev) : 0;
+ ret = pm-suspend ? pm-suspend(dev) : 0;
+ else
+ ret = i2c_legacy_suspend(dev, PMSG_SUSPEND);
- return i2c_legacy_suspend(dev, PMSG_SUSPEND);
+ if (!ret) {
+ pm_runtime_disable(dev);
+ pm_runtime_set_suspended(dev);
+ pm_runtime_enable(dev);
+ }
+ return ret;
}
static int i2c_device_pm_resume(struct device *dev)
--
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] Revert OMAP: omap_device: add omap_device_is_valid()
From: Kevin Hilman khil...@ti.com
This reverts commit 0007122ad85cc36b1c18c0b59344093ca210d206.
The dereference method of checking for a valid omap_device when
wrapping a platform_device is rather unsafe and dangerous.
Instead, a better way of checking for a valid omap-device is
to use a common parent device for all omap_devices, then a check
can simply be made using the device parent. The only user of this
API was the initial version of the runtime PM core for OMAP. This
has now been switched to check device parent, so there are no more
users of this API.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h |2 --
arch/arm/plat-omap/omap_device.c | 20
2 files changed, 0 insertions(+), 22 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index 25cd9ac..bad4c3d 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -62,7 +62,6 @@
*
*/
struct omap_device {
- u32 magic;
struct platform_device pdev;
struct omap_hwmod **hwmods;
struct omap_device_pm_latency *pm_lats;
@@ -82,7 +81,6 @@ int omap_device_shutdown(struct platform_device *pdev);
/* Core code interface */
-bool omap_device_is_valid(struct omap_device *od);
int omap_device_count_resources(struct omap_device *od);
int omap_device_fill_resources(struct omap_device *od, struct resource *res);
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index d2b1609..7f05f49 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -90,12 +90,6 @@
#define USE_WAKEUP_LAT 0
#define IGNORE_WAKEUP_LAT 1
-/*
- * OMAP_DEVICE_MAGIC: used to determine whether a struct omap_device
- * obtained via container_of() is in fact a struct omap_device
- */
-#define OMAP_DEVICE_MAGIC 0xf00dcafe
-
/* Private functions */
/**
@@ -414,8 +408,6 @@ struct omap_device *omap_device_build_ss(const char
*pdev_name, int pdev_id,
od-pm_lats = pm_lats;
od-pm_lats_cnt = pm_lats_cnt;
- od-magic = OMAP_DEVICE_MAGIC;
-
if (is_early_device)
ret = omap_early_device_register(od);
else
@@ -627,18 +619,6 @@ int omap_device_align_pm_lat(struct platform_device *pdev,
}
/**
- * omap_device_is_valid - Check if pointer is a valid omap_device
- * @od: struct omap_device *
- *
- * Return whether struct omap_device pointer @od points to a valid
- * omap_device.
- */
-bool omap_device_is_valid(struct omap_device *od)
-{
- return (od od-magic == OMAP_DEVICE_MAGIC);
-}
-
-/**
* omap_device_get_pwrdm - return the powerdomain * associated with @od
* @od: struct omap_device *
*
--
1.7.2.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/2] OMAP: omap_device: make all devices a child of a new omap_bus device
From: Kevin Hilman khil...@ti.com
In order to help differentiate omap_devices from normal
platform_devices, make them all a parent of a new omap_bus device.
Then, in order to determine if a platform_device is also an
omap_device, checking the parent is all that is needed.
Users of this feature are the runtime PM core for OMAP, where we need
to know if a device being passed in is an omap_device or not in order
to know whether to call the omap_device API with it.
In addition, all omap_devices will now show up under /sys/devices/omap
instead of /sys/devices/platform
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h |2 ++
arch/arm/plat-omap/omap_device.c | 18 ++
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
b/arch/arm/plat-omap/include/plat/omap_device.h
index bad4c3d..26d0c10 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -36,6 +36,8 @@
#include plat/omap_hwmod.h
+extern struct device omap_bus;
+
/* omap_device._state values */
#define OMAP_DEVICE_STATE_UNKNOWN 0
#define OMAP_DEVICE_STATE_ENABLED 1
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 7f05f49..3e215fa 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -463,8 +463,11 @@ int omap_early_device_register(struct omap_device *od)
*/
int omap_device_register(struct omap_device *od)
{
+ struct platform_device *pdev = od-pdev;
+
pr_debug(omap_device: %s: registering\n, od-pdev.name);
+ pdev-dev.parent = omap_bus;
return platform_device_register(od-pdev);
}
@@ -737,3 +740,18 @@ int omap_device_enable_clocks(struct omap_device *od)
/* XXX pass along return value here? */
return 0;
}
+
+struct device omap_bus = {
+ .init_name = omap,
+};
+
+static int __init omap_device_init(void)
+{
+ int error = 0;
+
+ printk(%s:\n, __func__);
+ error = device_register(omap_bus);
+
+ return error;
+}
+core_initcall(omap_device_init);
--
1.7.2.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: [PATCH 2/2] OMAP: omap_device: make all devices a child of a new omap_bus device
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin
Hilman
Sent: Wednesday, September 01, 2010 5:33 AM
To: linux-omap@vger.kernel.org
Cc: p...@pwsan.com
Subject: [PATCH 2/2] OMAP: omap_device: make all devices a child of a new
omap_bus device
From: Kevin Hilman khil...@ti.com
In order to help differentiate omap_devices from normal
platform_devices, make them all a parent of a new omap_bus device.
Then, in order to determine if a platform_device is also an
omap_device, checking the parent is all that is needed.
Users of this feature are the runtime PM core for OMAP, where we need
to know if a device being passed in is an omap_device or not in order
to know whether to call the omap_device API with it.
In addition, all omap_devices will now show up under /sys/devices/omap
instead of /sys/devices/platform
Hello Kevin,
Couple of minor queries/comments below.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h |2 ++
arch/arm/plat-omap/omap_device.c | 18 ++
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_device.h b/arch/arm/plat-
omap/include/plat/omap_device.h
index bad4c3d..26d0c10 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -36,6 +36,8 @@
#include plat/omap_hwmod.h
+extern struct device omap_bus;
+
Why is this extern declaration needed? Is it later on
to check in runtime pm code pdev-dev.parent == omap_bus??
/* omap_device._state values */
#define OMAP_DEVICE_STATE_UNKNOWN0
#define OMAP_DEVICE_STATE_ENABLED1
diff --git a/arch/arm/plat-omap/omap_device.c
b/arch/arm/plat-omap/omap_device.c
index 7f05f49..3e215fa 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -463,8 +463,11 @@ int omap_early_device_register(struct omap_device *od)
*/
int omap_device_register(struct omap_device *od)
{
+ struct platform_device *pdev = od-pdev;
+
pr_debug(omap_device: %s: registering\n, od-pdev.name);
+ pdev-dev.parent = omap_bus;
What if device_register(omap_bus) has returned an
error? Do we still go ahead with assigning omap_bus
as parent?
return platform_device_register(od-pdev);
}
@@ -737,3 +740,18 @@ int omap_device_enable_clocks(struct omap_device *od)
/* XXX pass along return value here? */
return 0;
}
+
+struct device omap_bus = {
+ .init_name = omap,
+};
+
+static int __init omap_device_init(void)
+{
+ int error = 0;
Is the initialization to 0 needed?
+
+ printk(%s:\n, __func__);
Spurious printk???
Regards
Thara
+ error = device_register(omap_bus);
+
+ return error;
+}
+core_initcall(omap_device_init);
--
1.7.2.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
--
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
