[PATCH 0/2] OMAP4: PM: Regulator state update
- There are few regulators (LDO's) which needs to be kept always ON in the system and few others can be handled by driver as per need basis. This series summarizes all the LDO's state and updates the default behavior. - As of today un-used regulators are not getting turned OFF. Need to specify explicitly that system has regulator constraints so that regulator core can disable unused resources after late init call (The one's which are not getting handled by any drivers). Changes done for 4430sdp and omap4panda. Girish S G (2): OMAP4:TWL6030: Regulator set the default behavior of LDO's OMAP: Regulator: Specify system has fully specified constraints arch/arm/mach-omap2/board-4430sdp.c|7 +++ arch/arm/mach-omap2/board-omap4panda.c |6 ++ 2 files changed, 13 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAP4 :TWL6030: Regulator set the default behavior of LDO's
TWL6030 below table shows the default state each LDO's can
be put into.
+---+
| LDO | Usage | state |
+---+
| VANA | sources internal | Always ON |
| | analog voltage| |
+---+
| VAUX1 | eMMC | MMC Driver needs to handle|
| | | |
+---+
| VAUX2 | A/V switch| Driver needs to handle|
+---+
| VAUX3 | 5MP CAMp | Driver needs to handle|
+---+
| VCXIO | supplies DPLL's | Can be put OFF when OMAP hits |
| | | OFF mode. |
+---+
| VDAC | HDMI, CDC chip| Always ON |
+---+
| VMMC | MMC | Driver needs to handle|
+---+
| VPP | VPP pins of OMAP | Used while burning fuses in |
| | | OMAP. This can be turned OFF |
| | | by default when kernel comes |
| | | up. |
+---+
| VRTC | VBRTC/RTC | Always ON |
+---+
| VUSB | USB OTG pins | Driver needs to handle|
+---+
| VUSIM | VDDS_SIM, SIM cage| Driver needs to handle. |
+---+
| CLK32K| 32KHz o/p clk | WIFI/BT/FM/GPS driver needs |
| | | to handle |
+---+
- VDAC, VANA, VCXIO and VRTC should be kept always ON. As per the table above.
Need REVISIT on below LDO's:
- VAUX1 kept ON now. MMC driver needs to take care of enabling/disabling
as needed. Issue seen with eMMC bootup with VAUX1 disabled by default.
- VAUX3 is kept ON now. CAM/syslink should handle this regulator. This
is only for 5MP camera on Blaze.
- CLK32KG is pseudo regulator, on Blaze/panda it supplies GPS/WIFI/BT/FM/GPS
Drivers should handle it. Keeping it always ON as of now.
Signed-off-by: Girish S G giris...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c|4
arch/arm/mach-omap2/board-omap4panda.c |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 63de2d3..04b7770 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -440,6 +440,7 @@ static struct regulator_init_data sdp4430_vmmc = {
.valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
+ .always_on = true,
},
.num_consumer_supplies = 1,
.consumer_supplies = sdp4430_vmmc_supply,
@@ -479,6 +480,7 @@ static struct regulator_init_data sdp4430_vana = {
| REGULATOR_MODE_STANDBY,
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
+ .always_on = true,
},
};
@@ -501,6 +503,7 @@ static struct regulator_init_data sdp4430_vdac = {
| REGULATOR_MODE_STANDBY,
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
+ .always_on = true,
},
};
@@ -519,6 +522,7 @@ static struct regulator_init_data sdp4430_vusb = {
static struct regulator_init_data sdp4430_clk32kg = {
.constraints = {
.valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ .always_on = true,
},
};
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 0cfe200..3415a5e 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch
[PATCH 2/2] OMAP4: Regulator: Specify system has fully specified constraints
As of now, the unused regulators are not getting disabled. Only those
regulators are disabled which are properly handled by drivers.
Calling regulator_has_full_constraints() will cause the regulator
core to disable all regulators which have a zero use count and don't
have always_on=true specified during registration.
Signed-off-by: Girish S G giris...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c|3 +++
arch/arm/mach-omap2/board-omap4panda.c |3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 04b7770..46f6800 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -560,6 +560,9 @@ static struct i2c_board_info __initdata
sdp4430_i2c_4_boardinfo[] = {
};
static int __init omap4_i2c_init(void)
{
+ /* This will allow unused regulator to be shutdown */
+ regulator_has_full_constraints();
+
omap4_pmic_init(twl6030, sdp4430_twldata);
omap_register_i2c_bus(2, 400, NULL, 0);
omap_register_i2c_bus(3, 400, sdp4430_i2c_3_boardinfo,
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 3415a5e..c425f9f 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -412,6 +412,9 @@ static struct i2c_board_info __initdata panda_i2c_eeprom[]
= {
static int __init omap4_panda_i2c_init(void)
{
+ /* This will allow unused regulator to be shutdown */
+ regulator_has_full_constraints();
+
omap4_pmic_init(twl6030, omap4_panda_twldata);
omap_register_i2c_bus(2, 400, NULL, 0);
/*
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: update: n8x0 idle power problem
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Felix Xiaozhu Lin Sent: Monday, October 26, 2009 5:36 PM To: linux-omap@vger.kernel.org Subject: update: n8x0 idle power problem Hi, All, Regarding the idle power problem I've mentioned in a mail last weekend: http://marc.info/?l=linux-omapm=125634121921583w=2 I have spent more efforts on this problem. By comparing with PM debug messages from Maemo kernel, it seems full-retention in linux-omap 2.6.28 has no problem on n810. Moreover, I've observed that l-o kernel consumes more power in other power states (e.g. when USB is plugged and the screen is dim but not off, Maemo kernel takes ~9...@3.8v while l-o kernel takes ~18...@3.8v). As a result, I think the extra power may not be consumed by OMAP processor core but by some device. I assume you are measuring at the battery level(?). If you have measurement done across different rails then it would help to understand who is consuming more. -Girish -- 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 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt controller
-Original Message-
From: Gopinath, Thara [mailto:th...@ti.com]
Sent: Tuesday, October 20, 2009 11:37 PM
To: Kevin Hilman; tero.kri...@nokia.com
Cc: Ghongdemath, Girish; Woodruff, Richard; linux-omap@vger.kernel.org;
jouni.hogan...@nokia.com
Subject: RE: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt
controller
OMAP3_PRM_VOLTCTRL_OFFSET);
}
+ /* Re-enable interrupt controller autoidle */
+ omap_writel(OMAP3430_AUTOIDLE, OMAP34XX_IC_BASE + INTC_SYSCONFIG);
Autoidle is being enabled inside the if (core_next_state PWRDM_POWER_ON).
This is a bug because it
is disabled irrespective of core pwr domain state. So if Core domain is on ,
this code will end up
not enabling INTC autoidle during resume.
It's outside if (core_next_state *) check in restore path. I see this patch
is dependent on some previous set of patches.
-Girish
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin
Hilman
Sent: Tuesday, October 20, 2009 10:02 PM
To: tero.kri...@nokia.com
Cc: Ghongdemath, Girish; Woodruff, Richard; linux-omap@vger.kernel.org;
jouni.hogan...@nokia.com
Subject: Re: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt
controller
tero.kri...@nokia.com writes:
[...]
Anyway, I guess the optimization would look something like this:
diff --git a/arch/arm/mach-omap2/pm34xx.c
b/arch/arm/mach-omap2/pm34xx.c
index 210a806..7a98321 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -93,6 +93,8 @@ u32 voltage_off_while_idle;
OMAP3430_ST_GPT5_MASK|OMAP3430_ST_GPT4_MASK|\
OMAP3430_ST_GPT3_MASK|OMAP3430_ST_GPT2_MASK)
+#define INTC_SYSCONFIG 0x10
+
struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
@@ -505,6 +507,12 @@ void omap_sram_idle(void)
prm_set_mod_reg_bits(OMAP3430_EN_IO,
WKUP_MOD, PM_WKEN);
omap3_enable_io_chain();
}
+ /*
+* Disable INTC autoidle as it can cause interrupt controller
+* to enter unknown state with right combination of
sleep / wakeup
+* transitions
+*/
+ omap_writel(0x0, OMAP34XX_IC_BASE + INTC_SYSCONFIG);
Except omap_write* functions are deprecated.
I see, will use __raw_writel here then.
I'd rather see a call into the interrupt code. Something like
omap_intc_prepare_idle()
Can do these changes to add the interface yes. Though name would be
omap3_intc_prepare_idle() /
...resume_idle() as this is only needed for OMAP3.
OK.
Also, isn't this only needed if CORE != ON?
I understood from the problem description that this is needed always when
we are entering WFI,
because we might have L3/L4 sleep/run transitions there even if CORE is on.
OK.
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
--
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] OMAP3 PM: sysfs vdd_opp change to use ConstraintFramework
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Tuesday, October 20, 2009 12:02 PM To: Kevin Hilman Cc: Sripathy, Vishwanath; linux-omap@vger.kernel.org Subject: Re: [RFC][Patch] OMAP3 PM: sysfs vdd_opp change to use ConstraintFramework * Kevin Hilman khil...@deeprootsystems.com [091020 08:51]: Sripathy, Vishwanath vishwanath...@ti.com writes: Sysfs entry vdd_opp currently does not use constraint framework. Because of this, even if you set the opp via this entry, it has no effect since it can be overridden by on demand governor any time. This patch has changes to make vdd_opp to use constraint framework. vdd_lock variable has to be used when application wants to disable DVFS altogether. This will override any other constraints and will lock the OPP to given value. Since we can do the equivalent with CPUFreq using the userspace governor, I don't see the point of having an additional interface. Comments? Total ack from me! Only thing what I think of is, L3 rate. -Girish -- 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/17] PM: fix suspend control for IVA2
-Original Message- From: tero.kri...@nokia.com [mailto:tero.kri...@nokia.com] Sent: Monday, October 19, 2009 4:23 AM To: giris...@ti.com; linux-omap@vger.kernel.org Subject: RE: [PATCH 01/17] PM: fix suspend control for IVA2 Agree, IVA2 pwrdm is handled autonomously by bridge. I think this needs some additional change to remove all the redundant configuration of iva pwdm. There are some inconsistencies like, - Say enable_off_mode is disabled. Before doing system wide suspend if DSP hibernates then IVA2 will be put to OFF. In that case we have IVA2 going to OFF and other domains in RET. This might not be an issue, but it's bad from sytem PM framework integrity perspective. This is an issue with bridge driver, and I am not sure how this should be fixed. Currently bridge driver does not care whether off mode is enabled or not. I have seen bridge considering enable_off_mode flag in suspend/resume path. But while hibernation (idle timeout) it goes to OFF, irrespective of the OFF flag. - enable_off_mode-omap3_pm_off_mode_enable will also touch IVA2 power domain next state. This we don't want to do if dsp bridge is already taking care of IVA2. IMO, we need to have some mechanism wherein if bridge PM takes care of IVA then PM framework should not configure the IVA powerstate. It should only do if bridge PM is disabled. Should we have a Kconfig option for this? Like CONFIG_OMAP3_BRIDGE_PM, and disable all iva2 controls from pm34xx.c if it is enabled? Otherwise control IVA2 as currently done. Yes, this looks ok to me. -Girish -- 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 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt controller
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
tero.kri...@nokia.com
Sent: Monday, October 19, 2009 5:19 AM
Anyway, I guess the optimization would look something like this:
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 210a806..7a98321 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -93,6 +93,8 @@ u32 voltage_off_while_idle;
OMAP3430_ST_GPT5_MASK|OMAP3430_ST_GPT4_MASK|\
OMAP3430_ST_GPT3_MASK|OMAP3430_ST_GPT2_MASK)
+#define INTC_SYSCONFIG 0x10
+
struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
@@ -505,6 +507,12 @@ void omap_sram_idle(void)
prm_set_mod_reg_bits(OMAP3430_EN_IO, WKUP_MOD, PM_WKEN);
omap3_enable_io_chain();
}
+ /*
+* Disable INTC autoidle as it can cause interrupt controller
+* to enter unknown state with right combination of sleep / wakeup
+* transitions
+*/
+ omap_writel(0x0, OMAP34XX_IC_BASE + INTC_SYSCONFIG);
/*
* On EMU/HS devices ROM code restores a SRDC value
@@ -561,6 +569,8 @@ void omap_sram_idle(void)
OMAP3430_GR_MOD,
OMAP3_PRM_VOLTCTRL_OFFSET);
}
+ /* Re-enable interrupt controller autoidle */
+ omap_writel(OMAP3430_AUTOIDLE, OMAP34XX_IC_BASE + INTC_SYSCONFIG);
/*
* Enable smartreflex after WFI. Only needed if we
Ack from me.
-Girish
--
1.5.4.3--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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/17] PM: fix suspend control for IVA2
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tero
Kristo
From: Tero Kristo tero.kri...@nokia.com
IVA2 controls its target power state individually, thus suspend should not
touch IVA2. Without this patch DSP suspend always fails.
Signed-off-by: Tero Kristo tero.kri...@nokia.com
Acked-by: Ameya Palande ameya.pala...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
static struct prm_setup_vc prm_setup = {
.clksetup = 0xff,
@@ -676,6 +676,12 @@ static int omap3_pm_suspend(void)
pwrst-saved_state = pwrdm_read_next_pwrst(pwrst-pwrdm);
/* Set ones wanted by suspend */
list_for_each_entry(pwrst, pwrst_list, node) {
+ /* Special handling for IVA2, just use current sleep state */
+ if (pwrst-pwrdm == iva2_pwrdm) {
+ state = pwrdm_read_pwrst(pwrst-pwrdm);
+ if (state PWRDM_POWER_ON)
+ pwrst-next_state = state;
+ }
Agree, IVA2 pwrdm is handled autonomously by bridge. I think this needs some
additional change to remove all the redundant
configuration of iva pwdm. There are some inconsistencies like,
- Say enable_off_mode is disabled. Before doing system wide suspend if
DSP hibernates then IVA2 will be put to OFF. In that
case we have IVA2 going to OFF and other domains in RET. This might not be an
issue, but it's bad from sytem PM framework integrity
perspective.
- enable_off_mode-omap3_pm_off_mode_enable will also touch IVA2 power
domain next state. This we don't want to do if dsp
bridge is already taking care of IVA2.
IMO, we need to have some mechanism wherein if bridge PM takes care of IVA then
PM framework should not configure the IVA
powerstate. It should only do if bridge PM is disabled.
-Girish
--
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 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt controller
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Woodruff, Richard Sent: Friday, October 16, 2009 9:40 AM To: Tero Kristo; linux-omap@vger.kernel.org Cc: Jouni Hogander Subject: RE: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt controller From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tero Kristo Sent: Friday, October 16, 2009 5:49 AM OMAP interrupt controller goes to unknown state when there is right combination of l3,l4 sleep/wake-up transitions, l4 autoidle in interrupt controller and some interrupt. When this happens, interrupts are not delivered to ARM anymore and ARM will remain in WFI (wait for interrupt) until interrupt controller is forced to wake-up (i.e. lauterbach). Disable AUTOIDLE in INTC for now. Optimal work around enables and disables this around WFI. On one of the custom board the power measured didn't show any major impact, with just one time disabling of INTC-AUTOIDL. However, optimizing this WA looks good though. I did give it a try, Disabling/enabling INTC autoidle around WFI on custom board, works well but didn't get chance to measure the numbers. Regards, -Girish -- 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 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt controller
-Original Message- From: Woodruff, Richard [mailto:r-woodru...@ti.com] Sent: Friday, October 16, 2009 1:04 PM To: Ghongdemath, Girish; 'Tero Kristo'; linux-omap@vger.kernel.org Cc: 'Jouni Hogander' Subject: RE: [PATCH 12/17] OMAP2/3: Do not enable AUTOIDLE in interrupt controller There was one report from a custom board when it made a difference. I've not tried to double check this data. I don't have the reporters setup so there is no guarantee I could reproduce anyway. In general optimization seemed to make sense. I second it. Regards, Girish -- 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][RFC] OMAP3: PM: Adding OSWR support
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Sripathy, Vishwanath Subject: RE: [PATCH][RFC] OMAP3: PM: Adding OSWR support OSWR stands for Open Switch With Retention. This is one of the target power states where logic is lost for all the modules in the power domain except for the ones with Built in retention Flip Flops. This is the main difference between OFF and So, this's supported for CORE, PER and MPU? -Girish -- 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 1/1] serial: OMAP driver
Hi,
* Girish. S. G. [EMAIL PROTECTED] [080822 15:42]:
Tony,
Hi,
arch/arm/configs/omap_3430sdp_defconfig | 12
arch/arm/mach-omap2/serial.c| 166 ++---
drivers/serial/Kconfig | 23
drivers/serial/Makefile |1
drivers/serial/omap-serial.c| 887
include/linux/serial_core.h |3
-static struct platform_device serial_device = {
- .name = serial8250,
- .id = PLAT8250_DEV_PLATFORM,
- .dev= {
- .platform_data = serial_platform_data,
- },
-};
What about powering UART on/off? I suggest you provide set_power()
function in platform_data. That way the UART power function can be
generic on later omaps, or external like the FPGA on omap1510.
There isn't any specific power on/off for UART as such(or any on omap1510?).
But yes we can have all the clk and pm related functions to be grouped under
uart_ops-pm().
Yeah I believe it's an external power for early omaps. So some board
specific function pointer should be available for that.
Ok, this can be done.
AFAIK using ttyS name will break hot-plug 8250 ports, such as CF ports.
How about using ttyO or something similar? I guess the minor number also
needs to be different then.
In general, will this driver also work on DaVinci? Maybe use name like
serial_ti or similar?
I don't think the name would conflict as only our uart instance would be up
and
working. Right now this driver is supported and tested only on OMAP2/OMAP3.
But
yes, once it's in it can be easily ported on other TI platforms.
The thing is this driver won't be accepted upstream if it conflicts
with hot-pluggable 8250 ports. AFAIK, you need to get a new id for it,
and call it something like ttyO instead.
In that case there should be a new id. I'll check on this and modify it
accordingly.
Regards,
Girish
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/1] serial: OMAP driver
Tony,
Hi,
Some comments below.
* Girish. S. G. [EMAIL PROTECTED] [080731 14:26]:
Serial driver for OMAP Uart controllers
Signed-off-by: Girish S G [EMAIL PROTECTED]
---
arch/arm/configs/omap_3430sdp_defconfig | 12
arch/arm/mach-omap2/serial.c| 166 ++---
drivers/serial/Kconfig | 23
drivers/serial/Makefile |1
drivers/serial/omap-serial.c| 887
include/linux/serial_core.h |3
6 files changed, 974 insertions(+), 118 deletions(-)
Index: linux-omap-2.6/arch/arm/configs/omap_3430sdp_defconfig
}
-}
-
-static struct platform_device serial_device = {
-.name = serial8250,
-.id = PLAT8250_DEV_PLATFORM,
-.dev= {
-.platform_data = serial_platform_data,
-},
-};
What about powering UART on/off? I suggest you provide set_power()
function in platform_data. That way the UART power function can be
generic on later omaps, or external like the FPGA on omap1510.
There isn't any specific power on/off for UART as such(or any on omap1510?).
But yes we can have all the clk and pm related functions to be grouped under
uart_ops-pm().
+static struct console serial_omap_console = {
+.name = ttyS,
+.write = serial_omap_console_write,
+.device = uart_console_device,
+.setup = serial_omap_console_setup,
+.flags = CON_PRINTBUFFER,
+.index = -1,
+.data = serial_omap_reg,
+};
+
AFAIK using ttyS name will break hot-plug 8250 ports, such as CF ports.
How about using ttyO or something similar? I guess the minor number also
needs to be different then.
In general, will this driver also work on DaVinci? Maybe use name like
serial_ti or similar?
I don't think the name would conflict as only our uart instance would be up and
working. Right now this driver is supported and tested only on OMAP2/OMAP3. But
yes, once it's in it can be easily ported on other TI platforms.
I will resend the patch with only OMAP2/OMAP3 support as of now.
Regards,
Girish
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][Resending: PATCH 1/1] serial: OMAP driver
Serial driver for OMAP Uart controllers for OMAP2/OMAP3. Tested only on
OMAP3430ES2.0
Signed-off-by: Girish S G [EMAIL PROTECTED]
---
arch/arm/configs/omap_3430sdp_defconfig | 12
arch/arm/mach-omap2/serial.c| 164 ++---
drivers/serial/Kconfig | 23
drivers/serial/Makefile |1
drivers/serial/omap-serial.c| 886
include/linux/serial_core.h |3
6 files changed, 972 insertions(+), 117 deletions(-)
Index: linux-omap-2.6/arch/arm/configs/omap_3430sdp_defconfig
===
--- linux-omap-2.6.orig/arch/arm/configs/omap_3430sdp_defconfig 2008-08-21
09:56:48.0 +0530
+++ linux-omap-2.6/arch/arm/configs/omap_3430sdp_defconfig 2008-08-21
10:00:15.0 +0530
@@ -683,19 +683,13 @@
#
# Serial drivers
#
-CONFIG_SERIAL_8250=y
-CONFIG_SERIAL_8250_CONSOLE=y
-CONFIG_SERIAL_8250_NR_UARTS=32
-CONFIG_SERIAL_8250_RUNTIME_UARTS=4
-CONFIG_SERIAL_8250_EXTENDED=y
-CONFIG_SERIAL_8250_MANY_PORTS=y
-CONFIG_SERIAL_8250_SHARE_IRQ=y
-CONFIG_SERIAL_8250_DETECT_IRQ=y
-CONFIG_SERIAL_8250_RSA=y
+# CONFIG_SERIAL_8250 is not set
#
# Non-8250 serial port support
#
+CONFIG_SERIAL_OMAP=y
+CONFIG_SERIAL_OMAP_CONSOLE=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
Index: linux-omap-2.6/arch/arm/mach-omap2/serial.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/serial.c2008-08-21
09:56:52.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/serial.c 2008-08-22 15:42:17.0
+0530
@@ -14,8 +14,9 @@
*/
#include linux/kernel.h
#include linux/init.h
-#include linux/serial_8250.h
#include linux/serial_reg.h
+#include linux/platform_device.h
+#include linux/serial.h
#include linux/clk.h
#include linux/io.h
@@ -23,85 +24,66 @@
#include mach/common.h
#include mach/board.h
-static struct clk *uart_ick[OMAP_MAX_NR_PORTS];
-static struct clk *uart_fck[OMAP_MAX_NR_PORTS];
-static struct plat_serial8250_port serial_platform_data[] = {
+static struct resource omap2_uart1_resources[] = {
{
- .membase= (__force void __iomem
*)IO_ADDRESS(OMAP_UART1_BASE),
- .mapbase= (unsigned long)OMAP_UART1_BASE,
- .irq= 72,
- .flags = UPF_BOOT_AUTOCONF,
- .iotype = UPIO_MEM,
- .regshift = 2,
- .uartclk= OMAP24XX_BASE_BAUD * 16,
+ .start = OMAP_UART1_BASE,
+ .end= OMAP_UART1_BASE + 0x3ff,
+ .flags = IORESOURCE_MEM,
}, {
- .membase= (__force void __iomem
*)IO_ADDRESS(OMAP_UART2_BASE),
- .mapbase= (unsigned long)OMAP_UART2_BASE,
- .irq= 73,
- .flags = UPF_BOOT_AUTOCONF,
- .iotype = UPIO_MEM,
- .regshift = 2,
- .uartclk= OMAP24XX_BASE_BAUD * 16,
- }, {
- .membase= (__force void __iomem
*)IO_ADDRESS(OMAP_UART3_BASE),
- .mapbase= (unsigned long)OMAP_UART3_BASE,
- .irq= 74,
- .flags = UPF_BOOT_AUTOCONF,
- .iotype = UPIO_MEM,
- .regshift = 2,
- .uartclk= OMAP24XX_BASE_BAUD * 16,
- }, {
- .flags = 0
+ .start = 72,
+ .flags = IORESOURCE_IRQ,
}
};
-static inline unsigned int serial_read_reg(struct plat_serial8250_port *up,
- int offset)
-{
- offset = up-regshift;
- return (unsigned int)__raw_readb(up-membase + offset);
-}
-
-static inline void serial_write_reg(struct plat_serial8250_port *p, int offset,
- int value)
-{
- offset = p-regshift;
- __raw_writeb(value, p-membase + offset);
-}
-
-/*
- * Internal UARTs need to be initialized for the 8250 autoconfig to work
- * properly. Note that the TX watermark initialization may not be needed
- * once the 8250.c watermark handling code is merged.
- */
-static inline void __init omap_serial_reset(struct plat_serial8250_port *p)
-{
- serial_write_reg(p, UART_OMAP_MDR1, 0x07);
- serial_write_reg(p, UART_OMAP_SCR, 0x08);
- serial_write_reg(p, UART_OMAP_MDR1, 0x00);
- serial_write_reg(p, UART_OMAP_SYSC, (0x02 3) | (1 2) | (1 0));
-}
+static struct resource omap2_uart2_resources[] = {
+ {
+ .start = OMAP_UART2_BASE,
+ .end= OMAP_UART2_BASE + 0x3ff,
+ .flags = IORESOURCE_MEM,
+ }, {
+ .start = 73,
+ .flags = IORESOURCE_IRQ,
+ }
+};
-void
Re: [RFC][PATCH 1/1] serial: OMAP driver
Hi, 2008/7/31 Girish. S. G. [EMAIL PROTECTED]: Serial driver for OMAP Uart controllers Signed-off-by: Girish S G [EMAIL PROTECTED] --- + /* Reset the UART */ + serial_out(up, UART_OMAP_MDR1, 0x07); + serial_out(up, UART_OMAP_SCR, 0x08); + serial_out(up, UART_OMAP_MDR1, 0x00); + serial_out(up, UART_OMAP_SYSC, (0x02 3) | (1 2) | (1 0)); Should this also work on older OMAPs? (The Kconfig allows building on omap1) OMAP15xx didn't have the SYSC register, instead MDR1 resets the module. I haven't checked the other registers used in this driver. That's good point. I don't have OMAP15xx and it would definitely help full if somebody in community validate it. I will send the patch with your comment included. Regards, Girish -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problem in McSPI (TXS timed out)
- Original Message - From: halli manjunatha [EMAIL PROTECTED] To: linux-omap@vger.kernel.org Sent: Monday, August 11, 2008 9:30 AM Subject: Problem in McSPI (TXS timed out) Hello All, I am working on OMAP3430 with 2.6.24 kernel, In that i am using McSPI2 for initializing the LCD and serializer, but while booting am getting the following messages In mcspi wakeup callback display spi2.0: TXS timed out In mcspi wakeup callback Check the pin mux of SPI2 including i/p enable bit. Can you dump what configuration you have set to SPI2? Regards, Girish -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH 0/1] serial: OMAP driver
Hi Tony, This patch brings in serial driver for OMAP uart. This patch is taken from earlier attempts of having serial driver specific for OMAP. Tested on 3430. Any issues please report. This Patch: 1. Adds support serial/debug uart 2. Fixes some of the bugs. TODO:(These features will be added eventually) 1. Add PM realted changes specific to OMAP UART 2. Add high speed non-dma support.(Oversampling 13x mode) 3. Add dma support. Regards, Girish -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] PM related changes:McSPI
PM related changes for McSPI
Signed-off-by: Girish S G [EMAIL PROTECTED]
---
arch/arm/mach-omap2/devices.c | 26 -
drivers/spi/omap2_mcspi.c | 195 ++
2 files changed, 204 insertions(+), 17 deletions(-)
Index: linux-omap-2.6/arch/arm/mach-omap2/devices.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/devices.c 2008-07-30
16:49:21.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/devices.c2008-07-30
16:57:53.0
+0530
@@ -168,6 +168,11 @@
.end= OMAP2_MCSPI1_BASE + 0xff,
.flags = IORESOURCE_MEM,
},
+
+ {
+ .start = INT_24XX_SPI1_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
};
static struct platform_device omap2_mcspi1 = {
@@ -190,6 +195,11 @@
.end= OMAP2_MCSPI2_BASE + 0xff,
.flags = IORESOURCE_MEM,
},
+
+ {
+ .start = INT_24XX_SPI2_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
};
static struct platform_device omap2_mcspi2 = {
@@ -209,9 +219,14 @@
static struct resource omap2_mcspi3_resources[] = {
{
- .start = OMAP2_MCSPI3_BASE,
- .end= OMAP2_MCSPI3_BASE + 0xff,
- .flags = IORESOURCE_MEM,
+ .start = OMAP2_MCSPI3_BASE,
+ .end= OMAP2_MCSPI3_BASE + 0xff,
+ .flags = IORESOURCE_MEM,
+ },
+
+ {
+ .start = INT_24XX_SPI3_IRQ,
+ .flags = IORESOURCE_IRQ,
},
};
@@ -237,6 +252,11 @@
.end= OMAP2_MCSPI4_BASE + 0xff,
.flags = IORESOURCE_MEM,
},
+
+ {
+ .start = INT_34XX_SPI4_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
};
static struct platform_device omap2_mcspi4 = {
Index: linux-omap-2.6/drivers/spi/omap2_mcspi.c
===
--- linux-omap-2.6.orig/drivers/spi/omap2_mcspi.c 2008-07-30
16:49:59.0
+0530
+++ linux-omap-2.6/drivers/spi/omap2_mcspi.c2008-07-30 17:11:23.0
+0530
@@ -35,6 +35,8 @@
#include linux/spi/spi.h
+#include asm/system.h
+#include asm/irq.h
#include asm/arch/dma.h
#include asm/arch/clock.h
@@ -61,8 +63,11 @@
#define OMAP2_MCSPI_SYSCONFIG_AUTOIDLE (1 0)
#define OMAP2_MCSPI_SYSCONFIG_SOFTRESET(1 1)
+#define OMAP2_AFTR_RST_SET_MASTER (0 2)
#define OMAP2_MCSPI_SYSSTATUS_RESETDONE(1 0)
+#define OMAP2_MCSPI_SYS_CON_LVL_1 1
+#define OMAP2_MCSPI_SYS_CON_LVL_2 2
#define OMAP2_MCSPI_MODULCTRL_SINGLE (1 0)
#define OMAP2_MCSPI_MODULCTRL_MS (1 2)
@@ -84,6 +89,11 @@
#define OMAP2_MCSPI_CHCONF_TURBO (1 19)
#define OMAP2_MCSPI_CHCONF_FORCE (1 20)
+#define OMAP2_MCSPI_SYSCFG_WKUP(1 2)
+#define OMAP2_MCSPI_SYSCFG_IDL (2 3)
+#define OMAP2_MCSPI_SYSCFG_CLK (2 8)
+#define OMAP2_MCSPI_WAKEUP_EN (1 1)
+#define OMAP2_MCSPI_IRQ_WKS(1 16)
#define OMAP2_MCSPI_CHSTAT_RXS (1 0)
#define OMAP2_MCSPI_CHSTAT_TXS (1 1)
#define OMAP2_MCSPI_CHSTAT_EOT (1 2)
@@ -128,6 +138,15 @@
int word_len;
};
+#if defined(CONFIG_OMAP34XX_OFFMODE) defined(CONFIG_OMAP3_PM)
+struct omap_mcspi_regs {
+ u32 sysconfig;
+ u32 modulctrl;
+ u32 chconf0;
+ u32 chconf1;
+};
+static struct omap_mcspi_regs mcspi_ctx[4];
+#endif /* #ifdef CONFIG_OMAP34XX_OFFMODE */
static struct workqueue_struct *omap2_mcspi_wq;
#define MOD_REG_BIT(val, mask, set) do { \
@@ -152,6 +171,14 @@
return __raw_readl(mcspi-base + idx);
}
+static inline void mcspi_write_wkup_reg(struct spi_master *master,
+ int idx, u32 val)
+{
+ struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
+
+ __raw_writel(val, mcspi-base + idx);
+}
+
static inline void mcspi_write_cs_reg(const struct spi_device *spi,
int idx, u32 val)
{
@@ -214,6 +241,99 @@
mcspi_write_reg(master, OMAP2_MCSPI_MODULCTRL, l);
}
+static void omap_mcspi_wakeup_enable(struct spi_master *spi_cntrl, int level)
+{
+ if (level == OMAP2_MCSPI_SYS_CON_LVL_1)
+ mcspi_write_wkup_reg(spi_cntrl, OMAP2_MCSPI_SYSCONFIG,
+ (mcspi_read_reg(spi_cntrl, OMAP2_MCSPI_SYSCONFIG) |
+OMAP2_MCSPI_SYSCFG_WKUP | OMAP2_MCSPI_SYSCFG_IDL |
+OMAP2_MCSPI_SYSCFG_CLK |
+ OMAP2_MCSPI_SYSCONFIG_AUTOIDLE));
+
+ if (level == OMAP2_MCSPI_SYS_CON_LVL_2)
+ mcspi_write_wkup_reg(spi_cntrl, OMAP2_MCSPI_SYSCONFIG,
+ (mcspi_read_reg(spi_cntrl, OMAP2_MCSPI_SYSCONFIG
[PATCH 0/2] IrDA support for 3430
Hi, Please find the patch series to enable IrDA on 3430 Patch 1/2 : Adds the driver specific changes. Patch 2/2 : Adds board specific changes. Regards, Girish -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM:OMAP2: irda support 3430
This adds board specific changes to support IrDA on 3430
Signed-off-by: Girish S G [EMAIL PROTECTED]
---
arch/arm/configs/omap_3430sdp_defconfig | 34 +++
arch/arm/mach-omap2/board-3430sdp.c | 145
arch/arm/mach-omap2/mux.c | 16 +++
include/asm-arm/arch-omap/gpio.h|3
include/asm-arm/arch-omap/mux.h |9 +
5 files changed, 204 insertions(+), 3 deletions(-)
Index: linux-omap-2.6/arch/arm/configs/omap_3430sdp_defconfig
===
--- linux-omap-2.6.orig/arch/arm/configs/omap_3430sdp_defconfig 2008-07-02
18:54:15.0 +0530
+++ linux-omap-2.6/arch/arm/configs/omap_3430sdp_defconfig 2008-07-02
18:56:41.0 +0530
@@ -392,7 +392,39 @@
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
-# CONFIG_IRDA is not set
+CONFIG_IRDA=y
+
+#
+# IrDA protocols
+#
+# CONFIG_IRLAN is not set
+CONFIG_IRCOMM=y
+# CONFIG_IRDA_ULTRA is not set
+
+#
+# IrDA options
+#
+CONFIG_IRDA_CACHE_LAST_LSAP=y
+CONFIG_IRDA_FAST_RR=y
+# CONFIG_IRDA_DEBUG is not set
+
+#
+# Infrared-port device drivers
+#
+
+#
+# SIR device drivers
+#
+# CONFIG_IRTTY_SIR is not set
+
+#
+# Dongle support
+#
+
+#
+# FIR device drivers
+#
+CONFIG_OMAP_IR=y
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
Index: linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/board-3430sdp.c 2008-07-02
18:54:15.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c 2008-07-02
18:56:41.0 +0530
@@ -32,6 +32,7 @@
#include asm/arch/mcspi.h
#include asm/arch/gpio.h
#include asm/arch/mux.h
+#include asm/arch/irda.h
#include asm/arch/board.h
#include asm/arch/usb-musb.h
#include asm/arch/usb-ehci.h
@@ -46,6 +47,9 @@
#defineSDP3430_SMC91X_CS 3
+#define ENABLE_VAUX1_DEDICATED 0x03
+#define ENABLE_VAUX1_DEV_GRP 0x20
+
#define ENABLE_VAUX3_DEDICATED 0x03
#define ENABLE_VAUX3_DEV_GRP 0x20
@@ -70,6 +74,146 @@
.resource = sdp3430_smc91x_resources,
};
+/* IrDA
+ */
+#if defined(CONFIG_OMAP_IR) || defined(CONFIG_OMAP_IR_MODULE)
+
+#defineIRDA_SD 164 /* gpio 164 */
+#defineIRDA_TX 166 /* gpio 166 */
+#defineIRDA_SD_PIN T21_3430_GPIO164
+#defineIRDA_TX_PIN V21_3430_GPIO166
+
+#define IRDA_VAUX_EN 1
+#define IRDA_VAUX_DIS 0
+
+/*
+ * This enable(1)/disable(0) the voltage for IrDA: uses twl4030 calls
+ */
+static int irda_vaux_control(int vaux_cntrl)
+{
+ int ret = 0;
+
+#ifdef CONFIG_TWL4030_CORE
+ /* check for return value of ldo_use: if success it returns 0 */
+ if (vaux_cntrl == IRDA_VAUX_EN) {
+ if (ret != twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ ENABLE_VAUX1_DEDICATED, TWL4030_VAUX1_DEDICATED))
+ return -EIO;
+ if (ret != twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ ENABLE_VAUX1_DEV_GRP, TWL4030_VAUX1_DEV_GRP))
+ return -EIO;
+ } else if (vaux_cntrl == IRDA_VAUX_DIS) {
+ if (ret != twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ 0x00, TWL4030_VAUX1_DEDICATED))
+ return -EIO;
+ if (ret != twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ 0x00, TWL4030_VAUX1_DEV_GRP))
+ return -EIO;
+ }
+#else
+ ret = -EIO;
+#endif
+ return ret;
+}
+
+static int select_irda(struct device *dev, int state)
+{
+ int err;
+ if (state == IR_SEL) {
+ err = irda_vaux_control(IRDA_VAUX_EN);
+ if (err != 0) {
+ printk(KERN_ERR OMAP: IrDA vaux enable failed\n);
+ return err;
+ }
+
+ omap_cfg_reg(R21_3430_UART3_CTS_RCTX);
+ omap_cfg_reg(T21_3430_UART3_RTS_SD);
+ omap_cfg_reg(U21_3430_UART3_RX_IRRX);
+ omap_cfg_reg(V21_3430_UART3_TX_IRTX);
+
+ omap_request_gpio(IRDA_SD);
+ omap_request_gpio(IRDA_TX);
+ omap_cfg_reg(IRDA_SD_PIN);
+ omap_set_gpio_direction(IRDA_SD, GPIO_DIR_OUTPUT);
+ omap_set_gpio_direction(IRDA_TX, GPIO_DIR_OUTPUT);
+ omap_set_gpio_dataout(IRDA_SD, 0);
+ } else {
+ omap_free_gpio(IRDA_SD);
+ omap_free_gpio(IRDA_TX);
+ err = irda_vaux_control(IRDA_VAUX_EN);
+ if (err != 0) {
+ printk(KERN_ERR OMAP: IrDA vaux Enable failed\n);
+ return err;
+ }
+ }
+
+ return 0;
+}
+
+static int transceiver_mode(struct device *dev, int mode)
+{
+ omap_cfg_reg(IRDA_SD_PIN);
+ omap_cfg_reg(IRDA_TX_PIN);
+
+ if (mode
[PATCH 1/2] driver: irda support 3430
Irda driver changes to support on 3430
Signed-off-by: Girish S G [EMAIL PROTECTED]
---
drivers/net/irda/omap-ir.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
Index: linux-omap-2.6_today/drivers/net/irda/omap-ir.c
===
--- linux-omap-2.6_today.orig/drivers/net/irda/omap-ir.c2008-07-03
10:33:57.0 +0530
+++ linux-omap-2.6_today/drivers/net/irda/omap-ir.c 2008-07-03
10:35:30.0 +0530
@@ -217,7 +217,7 @@
struct net_device *dev = data;
struct omap_irda *omap_ir = netdev_priv(dev);
- /*Stop DMA controller */
+ /* Stop DMA controller */
omap_stop_dma(omap_ir-tx_dma_channel);
}
@@ -378,8 +378,12 @@
skb_reserve(skb, 1);
- w = omap_get_dma_dst_pos(omap_ir-rx_dma_channel) -
- omap_ir-rx_buf_dma_phys;
+ w = OMAP_DMA4_CDAC(omap_ir-rx_dma_channel);
+
+ if (cpu_is_omap16xx())
+ w -= OMAP1_DMA_CDSA_L(omap_ir-rx_dma_channel);
+ if (cpu_is_omap24xx() || cpu_is_omap34xx())
+ w -= OMAP_DMA4_CDSA(omap_ir-rx_dma_channel);
if (!IS_FIR(omap_ir))
/* Copy DMA buffer to skb */
@@ -604,6 +608,8 @@
err_irlap:
omap_ir-open = 0;
omap_irda_shutdown(omap_ir);
+ if (omap_ir-pdata-select_irda)
+ omap_ir-pdata-select_irda(omap_ir-dev, ~IR_SEL);
err_startup:
dma_free_coherent(NULL, IRDA_SIR_MAX_FRAME,
omap_ir-tx_buf_dma_virt, omap_ir-tx_buf_dma_phys);
@@ -636,6 +642,8 @@
omap_ir-tx_buf_dma_phys);
omap_irda_shutdown(omap_ir);
+ if (omap_ir-pdata-select_irda)
+ omap_ir-pdata-select_irda(omap_ir-dev, ~IR_SEL);
/* Stop IrLAP */
if (omap_ir-irlap) {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM:OMAP2: irda support 3430
- Original Message -
From: Trilok Soni [EMAIL PROTECTED]
+static struct omap_irda_config irda_data = {
+ .transceiver_cap= IR_SIRMODE | IR_MIRMODE | IR_FIRMODE,
+ .transceiver_mode = transceiver_mode,
+ .select_irda= select_irda,
Please rename this hooks to 3430sdp_transceiver_mode and
3430sdp_select_irda. Check board_h4.c for example.
I think it can be made irda_transceiver_mode/irda_select. And, as this is in 3430 board file, prefixing it with 3430sdp serves no
purpose i guess.
+ .rx_channel = OMAP24XX_DMA_UART3_RX,
+ .tx_channel = OMAP24XX_DMA_UART3_TX,
+ .dest_start = OMAP_UART3_BASE,
+ .src_start = OMAP_UART3_BASE,
+ .tx_trigger = OMAP24XX_DMA_UART3_TX,
+ .rx_trigger = OMAP24XX_DMA_UART3_RX,
+};
Actually rx_channel to rx_trigger are not platform data and it is long
pending cleanup. It would great if we can convert this to
platform_resource, as it is chip specific not board specific.
Yes, I agree.
-girish
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Resending PATCH 2/2] ARM: OMAP2: RTC board specific code: rebased
This patch adds rtc-twl4030 driver specific code.
Signed-off-by: Girish S G [EMAIL PROTECTED]
---
arch/arm/configs/omap_3430sdp_defconfig | 17
arch/arm/mach-omap2/board-3430sdp.c | 64
2 files changed, 80 insertions(+), 1 deletion(-)
Index: linux-omap-2.6/arch/arm/configs/omap_3430sdp_defconfig
===
--- linux-omap-2.6.orig/arch/arm/configs/omap_3430sdp_defconfig 2008-06-26
17:24:52.0 +0530
+++ linux-omap-2.6/arch/arm/configs/omap_3430sdp_defconfig 2008-06-27
15:40:56.0 +0530
@@ -1061,8 +1061,23 @@
CONFIG_MMC_OMAP_HS=y
# CONFIG_MMC_SPI is not set
# CONFIG_NEW_LEDS is not set
+
+#
+# RTC interface
+#
CONFIG_RTC_LIB=y
-# CONFIG_RTC_CLASS is not set
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_HCTOSYS=y
+CONFIG_RTC_HCTOSYS_DEVICE=rtc0
+CONFIG_RTC_INTF_SYSFS=y
+CONFIG_RTC_INTF_PROC=y
+CONFIG_RTC_INTF_DEV=y
+
+#
+# I2C RTC driver
+#
+CONFIG_RTC_DRV_TWL4030=y
+
# CONFIG_UIO is not set
#
Index: linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/board-3430sdp.c 2008-06-26
17:24:52.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c 2008-06-27
15:49:37.0 +0530
@@ -40,9 +40,11 @@
#include asm/arch/keypad.h
#include asm/arch/dma.h
#include asm/arch/gpmc.h
+#include linux/i2c/twl4030-rtc.h
#include asm/io.h
#include asm/delay.h
+#include asm/arch/control.h
#defineSDP3430_SMC91X_CS 3
@@ -50,6 +52,8 @@
#define ENABLE_VAUX3_DEV_GRP 0x20
+#define TWL4030_MSECURE_GPIO 22
+
static struct resource sdp3430_smc91x_resources[] = {
[0] = {
.start = OMAP34XX_ETHR_START,
@@ -122,6 +126,63 @@
static int ts_gpio;
+#ifdef CONFIG_RTC_DRV_TWL4030
+static int twl4030_rtc_init(void)
+{
+ int ret = 0;
+
+ /* 3430ES2.0 doesn't have msecure/gpio-22 line connected to T2 */
+ if (is_device_type_gp() is_sil_rev_less_than(OMAP3430_REV_ES2_0)) {
+ u32 msecure_pad_config_reg = omap_ctrl_base_get() + 0xA3C;
+ int mux_mask = 0x04;
+ u16 tmp;
+
+ ret = omap_request_gpio(TWL4030_MSECURE_GPIO);
+ if (ret 0) {
+ printk(KERN_ERR twl4030_rtc_init: can't
+ reserve GPIO:%d !\n, TWL4030_MSECURE_GPIO);
+ goto out;
+ }
+ /*
+* TWL4030 will be in secure mode if msecure line from OMAP
+* is low. Make msecure line high in order to change the
+* TWL4030 RTC time and calender registers.
+*/
+ omap_set_gpio_direction(TWL4030_MSECURE_GPIO, 0);
+
+ tmp = omap_readw(msecure_pad_config_reg);
+ tmp = 0xF8; /* To enable mux mode 03/04 = GPIO_RTC */
+ tmp |= mux_mask;/* To enable mux mode 03/04 = GPIO_RTC */
+ omap_writew(tmp, msecure_pad_config_reg);
+
+ omap_set_gpio_dataout(TWL4030_MSECURE_GPIO, 1);
+ }
+out:
+ return ret;
+}
+
+static void twl4030_rtc_exit(void)
+{
+ if (is_device_type_gp()
+ is_sil_rev_less_than(OMAP3430_REV_ES2_0)) {
+ omap_free_gpio(TWL4030_MSECURE_GPIO);
+ }
+}
+
+static struct twl4030rtc_platform_data sdp3430_twl4030rtc_data = {
+ .init = twl4030_rtc_init,
+ .exit = twl4030_rtc_exit,
+};
+
+static struct platform_device sdp3430_twl4030rtc_device = {
+ .name = twl4030_rtc,
+ .id = -1,
+ .dev = {
+ .platform_data = sdp3430_twl4030rtc_data,
+ },
+};
+#endif
+
/**
* @brief ads7846_dev_init : Requests sets GPIO line for pen-irq
*
@@ -212,6 +273,9 @@
sdp3430_smc91x_device,
sdp3430_kp_device,
sdp3430_lcd_device,
+#ifdef CONFIG_RTC_DRV_TWL4030
+ sdp3430_twl4030rtc_device,
+#endif
};
static inline void __init sdp3430_init_smc91x(void)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
