RE: [PATCH 1/9] omap3/4: uart: fix full-fifo write abort
Tony, > -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Tuesday, February 23, 2010 4:37 AM > To: Shilimkar, Santosh > Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > Woodruff, Richard; Ghorai, > Sukumar > Subject: Re: [PATCH 1/9] omap3/4: uart: fix full-fifo write abort > > * Tony Lindgren [100222 13:35]: > > * Shilimkar, Santosh [100218 21:22]: > > > Bye the way just to add bit more clarity, this patch addresses TX > > > hardware restriction in the new UART IP used on omap3630 and omap4430. > > > First part of the fix for RX is already in mainline, > > > Commit: "ce13d4716a276f4331d78ba28a5093a63822ab95" > > > > > > More details on this thread are here. > > > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg19447.html > > > > Thanks, I've updated the comments for this patch with the link above > > and added the whole series into omap for-next. > > Except patches 8 and 9 as they break compile for mach-omap1 > and need to be updated. > Patch 8 is alright and doesn't break omap1. Patch 7 and patch 9 needs update to fix the mach-omap1 build issue by moving irqs-44xx.h header file to plat-omap directory. Attached are updated 7 and 9. Build tested for omap1 (omap_generic_1710_defconfig and omap_h2_1610_defconfig) and boot tested with omap3_defconfig on omap4430sdp board. Thanks!! Regards, Santosh 0007-omap4-Add-auto-generated-irq-and-dma-headers.patch Description: 0007-omap4-Add-auto-generated-irq-and-dma-headers.patch 0009-omap4-Use-irq-line-defines-from-irq-44xx.h.patch Description: 0009-omap4-Use-irq-line-defines-from-irq-44xx.h.patch
[PATCH 1/2] can:ti_hecc: Enable CAN support on AM3517.
Modify the default kernel configuration on AM3517 to enable CAN. Signed-off-by: Sriramakrishnan Acked-by: Anant Gole --- arch/arm/configs/am3517_evm_defconfig | 22 ++ 1 files changed, 18 insertions(+), 4 deletions(-) diff --git a/arch/arm/configs/am3517_evm_defconfig b/arch/arm/configs/am3517_evm_defconfig index abe9966..d5e15ba 100644 --- a/arch/arm/configs/am3517_evm_defconfig +++ b/arch/arm/configs/am3517_evm_defconfig @@ -422,15 +422,29 @@ CONFIG_DEFAULT_TCP_CONG="cubic" # # CONFIG_NET_PKTGEN is not set # CONFIG_HAMRADIO is not set -# CONFIG_CAN is not set +CONFIG_CAN=y +CONFIG_CAN_RAW=y +CONFIG_CAN_BCM=y + +# +# CAN Device Drivers +# +CONFIG_CAN_VCAN=y +CONFIG_CAN_DEV=y +CONFIG_CAN_CALC_BITTIMING=y +CONFIG_CAN_TI_HECC=y +# CONFIG_CAN_SJA1000 is not set + +# +# CAN USB interfaces +# +# CONFIG_CAN_EMS_USB is not set +CONFIG_CAN_DEBUG_DEVICES=y # CONFIG_IRDA is not set # CONFIG_BT is not set # CONFIG_AF_RXRPC is not set CONFIG_WIRELESS=y # CONFIG_CFG80211 is not set -CONFIG_CFG80211_DEFAULT_PS_VALUE=0 -# CONFIG_WIRELESS_OLD_REGULATORY is not set -# CONFIG_WIRELESS_EXT is not set # CONFIG_LIB80211 is not set # -- 1.6.2.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] can:ti_hecc: board specific hookup on AM3517EVM
Add board specific hookup for TI HECC driver on
AM3517 EVM
Signed-off-by: Sriramakrishnan
Acked-by: Anant Gole
---
The driver requires that CAN_STB signal be driven low to enable
CAN PHY. Currently this is being managed from U-boot. Will submit a patch
for handling this as part of board init sequence.
arch/arm/mach-omap2/board-am3517evm.c | 38 +
arch/arm/mach-omap2/include/mach/am35xx.h | 10 +++
2 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index af99faf..42013b5 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -223,6 +224,42 @@ static struct omap_board_mux board_mux[] __initdata = {
#define board_mux NULL
#endif
+
+static struct resource am3517_hecc_resources[] = {
+ {
+ .start = AM35XX_IPSS_HECC_BASE,
+ .end= AM35XX_IPSS_HECC_BASE + 0x3FFF,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_35XX_HECC0_IRQ,
+ .end= INT_35XX_HECC0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device am3517_hecc_device = {
+ .name = "ti_hecc",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(am3517_hecc_resources),
+ .resource = am3517_hecc_resources,
+};
+
+static struct ti_hecc_platform_data am3517_evm_hecc_pdata = {
+ .scc_hecc_offset= AM35XX_HECC_SCC_HECC_OFFSET,
+ .scc_ram_offset = AM35XX_HECC_SCC_RAM_OFFSET,
+ .hecc_ram_offset= AM35XX_HECC_RAM_OFFSET,
+ .mbx_offset= AM35XX_HECC_MBOX_OFFSET,
+ .int_line = AM35XX_HECC_INT_LINE,
+ .version= AM35XX_HECC_VERSION,
+};
+
+static void am3517_evm_hecc_init(struct ti_hecc_platform_data *pdata)
+{
+ am3517_hecc_device.dev.platform_data = pdata;
+ platform_device_register(&am3517_hecc_device);
+}
+
static void __init am3517_evm_init(void)
{
am3517_evm_i2c_init();
@@ -233,6 +270,7 @@ static void __init am3517_evm_init(void)
omap_serial_init();
usb_ehci_init(&ehci_pdata);
+ am3517_evm_hecc_init(&am3517_evm_hecc_pdata);
/* DSS */
am3517_evm_display_init();
}
diff --git a/arch/arm/mach-omap2/include/mach/am35xx.h
b/arch/arm/mach-omap2/include/mach/am35xx.h
index a705f94..6d5429b 100644
--- a/arch/arm/mach-omap2/include/mach/am35xx.h
+++ b/arch/arm/mach-omap2/include/mach/am35xx.h
@@ -23,4 +23,14 @@
#define AM35XX_IPSS_HECC_BASE 0x5C05
#define AM35XX_IPSS_VPFE_BASE 0x5C06
+
+/* HECC module specifc offset definitions */
+#define AM35XX_HECC_SCC_HECC_OFFSET(0x0)
+#define AM35XX_HECC_SCC_RAM_OFFSET (0x3000)
+#define AM35XX_HECC_RAM_OFFSET (0x3000)
+#define AM35XX_HECC_MBOX_OFFSET(0x2000)
+#define AM35XX_HECC_INT_LINE (0x0)
+#define AM35XX_HECC_VERSION(0x1)
+
+
#endif /* __ASM_ARCH_AM35XX_H */
--
1.6.2.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Enable CAN peripheral support on AM3517
AM3517 platform includes the ti-hecc CAN peripheral. This patch series enables support for the ti-hecc peripheral on AM3517 platform. This patch series has been validated on AM3517EVM. The patch series is dependent on AM35x clock support patches submitted earlier. [1].http://marc.info/?l=linux-omap&m=126628362713703&w=2 [2].http://marc.info/?l=linux-omap&m=126628364013734&w=2 Sriramakrishnan (2): can:ti_hecc: Enable CAN support on AM3517. can:ti_hecc: board specific hookup on AM3517EVM arch/arm/configs/am3517_evm_defconfig | 22 +--- arch/arm/mach-omap2/board-am3517evm.c | 38 + arch/arm/mach-omap2/include/mach/am35xx.h | 10 +++ 3 files changed, 66 insertions(+), 4 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
RE: [PATCH] omap: i2c: Add i2c support on omap4 platform
Ben,
Did you happen to look at this ?
> -Original Message-
> From: Shilimkar, Santosh
> Sent: Friday, February 19, 2010 10:03 PM
> To: ben-li...@fluff.org
> Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org; Shilimkar,
> Santosh; Syed, Rafiuddin; Cory
> Maccarrone
> Subject: [PATCH] omap: i2c: Add i2c support on omap4 platform
>
> This patch is rebased version of earlier post to add I2C
> driver support to OMAP4 platform. On OMAP4, all
> I2C register address offsets are changed from OMAP1/2/3 I2C.
> In order to not have #ifdef's at various places in code,
> as well as to support multi-OMAP build, an array is created
> to hold the register addresses with it's offset.
>
> This patch was submitted, reviewed and acked on mailing list
> already. For more details refer below link
> http://www.mail-archive.com/linux-...@vger.kernel.org/msg02281.html
>
> This updated verion has a depedancy on "Add support for 16-bit registers"
> posted on linux-omap. Below is the patch-works link for the same
>
> http://patchwork.kernel.org/patch/72295/
>
> Signed-off-by: Syed Rafiuddin
> Signed-off-by: Santosh Shilimkar
> Acked-by: Kevin Hilman
> Reviewed-by: Paul Walmsley
> Reviewed-by: Tony Lindgren
> Cc: Ben Dooks
> Cc: Cory Maccarrone
> ---
> drivers/i2c/busses/i2c-omap.c | 146
> -
> 1 files changed, 114 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 9c3ce4d..7c15496 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -44,29 +44,37 @@
> /* I2C controller revisions present on specific hardware */
> #define OMAP_I2C_REV_ON_2430 0x36
> #define OMAP_I2C_REV_ON_3430 0x3C
> +#define OMAP_I2C_REV_ON_4430 0x40
>
> /* timeout waiting for the controller to respond */
> #define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
>
> -#define OMAP_I2C_REV_REG 0x00
> -#define OMAP_I2C_IE_REG 0x01
> -#define OMAP_I2C_STAT_REG0x02
> -#define OMAP_I2C_IV_REG 0x03
> /* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */
> -#define OMAP_I2C_WE_REG 0x03
> -#define OMAP_I2C_SYSS_REG0x04
> -#define OMAP_I2C_BUF_REG 0x05
> -#define OMAP_I2C_CNT_REG 0x06
> -#define OMAP_I2C_DATA_REG0x07
> -#define OMAP_I2C_SYSC_REG0x08
> -#define OMAP_I2C_CON_REG 0x09
> -#define OMAP_I2C_OA_REG 0x0a
> -#define OMAP_I2C_SA_REG 0x0b
> -#define OMAP_I2C_PSC_REG 0x0c
> -#define OMAP_I2C_SCLL_REG0x0d
> -#define OMAP_I2C_SCLH_REG0x0e
> -#define OMAP_I2C_SYSTEST_REG 0x0f
> -#define OMAP_I2C_BUFSTAT_REG 0x10
> +enum {
> + OMAP_I2C_REV_REG = 0,
> + OMAP_I2C_IE_REG,
> + OMAP_I2C_STAT_REG,
> + OMAP_I2C_IV_REG,
> + OMAP_I2C_WE_REG,
> + OMAP_I2C_SYSS_REG,
> + OMAP_I2C_BUF_REG,
> + OMAP_I2C_CNT_REG,
> + OMAP_I2C_DATA_REG,
> + OMAP_I2C_SYSC_REG,
> + OMAP_I2C_CON_REG,
> + OMAP_I2C_OA_REG,
> + OMAP_I2C_SA_REG,
> + OMAP_I2C_PSC_REG,
> + OMAP_I2C_SCLL_REG,
> + OMAP_I2C_SCLH_REG,
> + OMAP_I2C_SYSTEST_REG,
> + OMAP_I2C_BUFSTAT_REG,
> + OMAP_I2C_REVNB_LO,
> + OMAP_I2C_REVNB_HI,
> + OMAP_I2C_IRQSTATUS_RAW,
> + OMAP_I2C_IRQENABLE_SET,
> + OMAP_I2C_IRQENABLE_CLR,
> +};
>
> /* I2C Interrupt Enable Register (OMAP_I2C_IE): */
> #define OMAP_I2C_IE_XDR (1 << 14) /* TX Buffer drain int
> enable */
> @@ -169,6 +177,7 @@ struct omap_i2c_dev {
> u32 speed; /* Speed of bus in Khz */
> u16 cmd_err;
> u8 *buf;
> + u8 *regs;
> size_t buf_len;
> struct i2c_adapter adapter;
> u8 fifo_size; /* use as flag and value
> @@ -187,15 +196,64 @@ struct omap_i2c_dev {
> u16 westate;
> };
>
> +const static u8 reg_map[] = {
> + [OMAP_I2C_REV_REG] = 0x00,
> + [OMAP_I2C_IE_REG] = 0x01,
> + [OMAP_I2C_STAT_REG] = 0x02,
> + [OMAP_I2C_IV_REG] = 0x03,
> + [OMAP_I2C_WE_REG] = 0x03,
> + [OMAP_I2C_SYSS_REG] = 0x04,
> + [OMAP_I2C_BUF_REG] = 0x05,
> + [OMAP_I2C_CNT_REG] = 0x06,
> + [OMAP_I2C_DATA_REG] = 0x07,
> + [OMAP_I2C_SYSC_REG] = 0x08,
> + [OMAP_I2C_CON_REG] = 0x09,
> + [OMAP_I2C_OA_REG] = 0x0a,
> + [OMAP_I2C_SA_REG] = 0x0b,
> + [OMAP_I2C_PSC_REG] = 0x0c,
> + [OMAP_I2C_SCLL_REG] = 0x0d,
> + [OMAP_I2C_SCLH_REG] = 0x0e,
> + [OMAP_I2C_SYSTEST_REG] = 0x0f,
> + [OMAP_I2C_BUFSTAT_REG] = 0x10,
> +};
> +
> +const static u8 omap4_reg_map[] = {
> + [OMAP_I2C_REV_REG] = 0x04,
> + [OMAP_I2C_IE_REG] = 0x2c,
> + [OMAP_I2C_STAT_REG] = 0x28,
> + [OMAP_I2C_IV_REG] = 0x34,
> +
RE: [PATCH 1/9] omap3/4: uart: fix full-fifo write abort
Thanks Tony > -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Tuesday, February 23, 2010 4:37 AM > To: Shilimkar, Santosh > Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > Woodruff, Richard; Ghorai, > Sukumar > Subject: Re: [PATCH 1/9] omap3/4: uart: fix full-fifo write abort > > * Tony Lindgren [100222 13:35]: > > * Shilimkar, Santosh [100218 21:22]: > > > Bye the way just to add bit more clarity, this patch addresses TX > > > hardware restriction in the new UART IP used on omap3630 and omap4430. > > > First part of the fix for RX is already in mainline, > > > Commit: "ce13d4716a276f4331d78ba28a5093a63822ab95" > > > > > > More details on this thread are here. > > > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg19447.html > > > > Thanks, I've updated the comments for this patch with the link above > > and added the whole series into omap for-next. > > Except patches 8 and 9 as they break compile for mach-omap1 > and need to be updated. I will check these two patches tony and also boot test the OMAP1. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] PM-WIP-OPP: Fixing wrong target level being passed during Core DVFS.
> From: Aguirre, Sergio
> Sent: Tuesday, February 23, 2010 7:28 AM
> To: Menon, Nishanth; Gopinath, Thara
[...]
> >
> > >
> > > Signed-off-by: Thara Gopinath
> > > Cc: Kevin Hilman
> > > ---
> > > arch/arm/mach-omap2/resource34xx.c |4 +++-
> > > 1 files changed, 3 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-omap2/resource34xx.c b/arch/arm/mach-
> > omap2/resource34xx.c
> > > index 3604a38..d2336d8 100644
> > > --- a/arch/arm/mach-omap2/resource34xx.c
> > > +++ b/arch/arm/mach-omap2/resource34xx.c
> > > @@ -463,6 +463,7 @@ int set_opp(struct shared_resource *resp, u32
> > target_level)
> > > } else if (resp == vdd2_resp) {
> > > unsigned long req_l3_freq;
> > > struct omap_opp *oppx = NULL;
> > > + u8 opp;
> > >
> > > /* Convert the tput in KiB/s to Bus frequency in MHz */
> > > req_l3_freq = (target_level * 1000)/4;
> > > @@ -478,10 +479,11 @@ int set_opp(struct shared_resource *resp, u32
> > target_level)
> > > /* uh uh.. no OPPs?? */
> > > BUG_ON(IS_ERR(oppx));
> > >
> > If you do target_level = 0; here, the entire patch is a oneliner :)
>
> Actually, IMHO will be even more clean, to standardize all OPP value
> passing to be u8.
>
> Do you really need to be prepared for 2^32 opp values? ;)
>
Using OPP ID has to be completely removed from resource34xx.c -> this action is
still pending. In this case, using u8 OR initing the target_level to 0 has the
same impact. Why add code that will be removed later on anyways?
Regards,
Nishanth Menon
--
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] PM-WIP-OPP: Fixing wrong target level being passed during Core DVFS.
Nishanth,
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Menon, Nishanth
> Sent: Thursday, February 18, 2010 8:58 AM
> To: Gopinath, Thara
> Cc: linux-omap@vger.kernel.org; Kevin Hilman; Kristo Tero (Nokia-
> D/Tampere)
> Subject: Re: [PATCH] PM-WIP-OPP: Fixing wrong target level being passed
> during Core DVFS.
>
> Gopinath, Thara said the following on 02/18/2010 10:31 AM:
> > As per the current implementaion (u8*)&target_level is being passed
> > to freq_to_opp in set_opp. This would result in updating just the first
> > 8 bits of a u32 variable. Later target_level is passed to
> > resource_set_opp_level as a u32 parameter. This maens
> > a. Initially target_level was 0xabcdefgh.
> > b. freq_to_opp updates the lower eight bits of target_level
> > to 0xXX. Now target_level = 0xabcdefXX.
> > c. We pass 0xabcdefXX as target_level to resource_set_opp_level
> > when we want to pass just 0xXX.
> > This is leading to some corrupted bookkeeping later on in the
> > dvfs path.
> >
> > This patch ensures that target_level passed to resource_set_opp_level
> > is actually the level that is intended by freq_to_opp API.
>
> Thanks.. good catch.
> [PATCH] PM-WIP-OPP: Fixing wrong target level being passed during Core
> DVFS.
> Suggestion on the subject:
> could you put it something like the following so that git-am will
> throw away PM-WIP-OPP?
> [PATCH] [PM-WIP-OPP] omap3: pm: Fix wrong target level during core dvfs
>
> ?
> Some suggestion below.
>
> >
> > Signed-off-by: Thara Gopinath
> > Cc: Kevin Hilman
> > ---
> > arch/arm/mach-omap2/resource34xx.c |4 +++-
> > 1 files changed, 3 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/resource34xx.c b/arch/arm/mach-
> omap2/resource34xx.c
> > index 3604a38..d2336d8 100644
> > --- a/arch/arm/mach-omap2/resource34xx.c
> > +++ b/arch/arm/mach-omap2/resource34xx.c
> > @@ -463,6 +463,7 @@ int set_opp(struct shared_resource *resp, u32
> target_level)
> > } else if (resp == vdd2_resp) {
> > unsigned long req_l3_freq;
> > struct omap_opp *oppx = NULL;
> > + u8 opp;
> >
> > /* Convert the tput in KiB/s to Bus frequency in MHz */
> > req_l3_freq = (target_level * 1000)/4;
> > @@ -478,10 +479,11 @@ int set_opp(struct shared_resource *resp, u32
> target_level)
> > /* uh uh.. no OPPs?? */
> > BUG_ON(IS_ERR(oppx));
> >
> If you do target_level = 0; here, the entire patch is a oneliner :)
Actually, IMHO will be even more clean, to standardize all OPP value passing to
be u8.
Do you really need to be prepared for 2^32 opp values? ;)
Regards,
Sergio
>
> > - ret = freq_to_opp((u8 *)&target_level, OPP_L3, req_l3_freq);
> > + ret = freq_to_opp(&opp, OPP_L3, req_l3_freq);
> > /* we dont expect this to fail */
> > BUG_ON(ret);
> >
> > + target_level = opp;
> > ret = resource_set_opp_level(VDD2_OPP, target_level, 0);
> > }
> > return 0;
>
> --
> Regards,
> Nishanth Menon
> --
> 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
[PATCH 07/11] OMAP2/3 clock: combine OMAP2 & 3 boot-time MPU rate change code
The OMAP2 and OMAP3 boot-time MPU rate change code is almost
identical. Merge them into mach-omap2/clock.c, and add kerneldoc
documentation.
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clock.c | 85 +++
arch/arm/mach-omap2/clock.h |4 ++
arch/arm/mach-omap2/clock2xxx.c | 34
arch/arm/mach-omap2/clock3xxx.c | 59 ---
4 files changed, 107 insertions(+), 75 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 426d76f..d1f115d 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -17,6 +17,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -349,6 +351,89 @@ void omap2_clk_disable_unused(struct clk *clk)
}
#endif
+/**
+ * omap2_clk_switch_mpurate_at_boot - switch ARM MPU rate by boot-time argument
+ * @mpurate_ck_name: clk name of the clock to change rate
+ *
+ * Change the ARM MPU clock rate to the rate specified on the command
+ * line, if one was specified. @mpurate_ck_name should be
+ * "virt_prcm_set" on OMAP2xxx and "dpll1_ck" on OMAP34xx/OMAP36xx.
+ * XXX Does not handle voltage scaling - on OMAP2xxx this is currently
+ * handled by the virt_prcm_set clock, but this should be handled by
+ * the OPP layer. XXX This is intended to be handled by the OPP layer
+ * code in the near future and should be removed from the clock code.
+ * Returns -EINVAL if 'mpurate' is zero or if clk_set_rate() rejects
+ * the rate, -ENOENT if the struct clk referred to by @mpurate_ck_name
+ * cannot be found, or 0 upon success.
+ */
+int __init omap2_clk_switch_mpurate_at_boot(const char *mpurate_ck_name)
+{
+ struct clk *mpurate_ck;
+ int r;
+
+ if (!mpurate)
+ return -EINVAL;
+
+ mpurate_ck = clk_get(NULL, mpurate_ck_name);
+ if (WARN(IS_ERR(mpurate_ck), "Failed to get %s.\n", mpurate_ck_name))
+ return -ENOENT;
+
+ r = clk_set_rate(mpurate_ck, mpurate);
+ if (IS_ERR_VALUE(r)) {
+ WARN(1, "clock: %s: unable to set MPU rate to %d: %d\n",
+mpurate_ck->name, mpurate, r);
+ return -EINVAL;
+ }
+
+ calibrate_delay();
+ recalculate_root_clocks();
+
+ clk_put(mpurate_ck);
+
+ return 0;
+}
+
+/**
+ * omap2_clk_print_new_rates - print summary of current clock tree rates
+ * @hfclkin_ck_name: clk name for the off-chip HF oscillator
+ * @core_ck_name: clk name for the on-chip CORE_CLK
+ * @mpu_ck_name: clk name for the ARM MPU clock
+ *
+ * Prints a short message to the console with the HFCLKIN oscillator
+ * rate, the rate of the CORE clock, and the rate of the ARM MPU clock.
+ * Called by the boot-time MPU rate switching code. XXX This is intended
+ * to be handled by the OPP layer code in the near future and should be
+ * removed from the clock code. No return value.
+ */
+void __init omap2_clk_print_new_rates(const char *hfclkin_ck_name,
+ const char *core_ck_name,
+ const char *mpu_ck_name)
+{
+ struct clk *hfclkin_ck, *core_ck, *mpu_ck;
+ unsigned long hfclkin_rate;
+
+ mpu_ck = clk_get(NULL, mpu_ck_name);
+ if (WARN(IS_ERR(mpu_ck), "clock: failed to get %s.\n", mpu_ck_name))
+ return;
+
+ core_ck = clk_get(NULL, core_ck_name);
+ if (WARN(IS_ERR(core_ck), "clock: failed to get %s.\n", core_ck_name))
+ return;
+
+ hfclkin_ck = clk_get(NULL, hfclkin_ck_name);
+ if (WARN(IS_ERR(hfclkin_ck), "Failed to get %s.\n", hfclkin_ck_name))
+ return;
+
+ hfclkin_rate = clk_get_rate(hfclkin_ck);
+
+ pr_info("Switched to new clocking rate (Crystal/Core/MPU): "
+ "%ld.%01ld/%ld/%ld MHz\n",
+ (hfclkin_rate / 100),
+ ((hfclkin_rate / 10) % 10),
+ (clk_get_rate(core_ck) / 100),
+ (clk_get_rate(mpu_ck) / 100));
+}
+
/* Common data */
struct clk_functions omap2_clk_functions = {
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index ae626f7..49ad473 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -93,6 +93,10 @@ void omap2_clk_dflt_find_companion(struct clk *clk, void
__iomem **other_reg,
u8 *other_bit);
void omap2_clk_dflt_find_idlest(struct clk *clk, void __iomem **idlest_reg,
u8 *idlest_bit, u8 *idlest_val);
+int omap2_clk_switch_mpurate_at_boot(const char *mpurate_ck_name);
+void omap2_clk_print_new_rates(const char *hfclkin_ck_name,
+ const char *core_ck_name,
+ const char *mpu_ck_name);
extern u8 cpu_mask;
diff --git a/arch/arm/mach-omap2/clock2xxx.c b/arch/arm/mach-omap2/clock2xxx.c
index 7a2f5ad..80bb0f0 100644
--- a/arch/arm/mach-omap2/cl
[PATCH 04/11] OMAP hwmod: convert header files with static allocations into C files
Code should be able to #include any header file without the fear that
the header file will go allocating memory. This is a coding style
issue, similar to commit 82e9bd588563c4e22ebb55b684ebec7e310cc715.
Move the existing hwmod data from .h files to .c files.
While here, convert "omap34xx" to "omap3xxx" in the hwmod files, since
most of these structures should be reusable across all OMAP3 chips.
Signed-off-by: Paul Walmsley
Cc: Benoît Cousson
Cc: Rajendra Nayak
Cc: Kevin Hilman
---
arch/arm/mach-omap2/Makefile |5 +
arch/arm/mach-omap2/io.c | 21 +--
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 29 ++--
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 29 ++--
arch/arm/mach-omap2/omap_hwmod_34xx.h| 167 -
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 174 ++
arch/arm/plat-omap/include/plat/omap_hwmod.h |8 +
7 files changed, 226 insertions(+), 207 deletions(-)
rename arch/arm/mach-omap2/{omap_hwmod_2420.h => omap_hwmod_2420_data.c} (86%)
rename arch/arm/mach-omap2/{omap_hwmod_2430.h => omap_hwmod_2430_data.c} (86%)
delete mode 100644 arch/arm/mach-omap2/omap_hwmod_34xx.h
create mode 100644 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 679df5d..4aa621d 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -66,6 +66,11 @@ obj-$(CONFIG_ARCH_OMAP4) += $(clock-common)
clock44xx_data.o \
obj-$(CONFIG_ARCH_OMAP2420)+= opp2420_data.o
obj-$(CONFIG_ARCH_OMAP2430)+= opp2430_data.o
+# hwmod data
+obj-$(CONFIG_ARCH_OMAP2420)+= omap_hwmod_2420_data.o
+obj-$(CONFIG_ARCH_OMAP2430)+= omap_hwmod_2430_data.o
+obj-$(CONFIG_ARCH_OMAP34XX)+= omap_hwmod_3xxx_data.o
+
# EMU peripherals
obj-$(CONFIG_OMAP3_EMU)+= emu.o
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 1b951af..c3223b6 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -46,9 +46,6 @@
#include
#include "clockdomains.h"
#include
-#include "omap_hwmod_2420.h"
-#include "omap_hwmod_2430.h"
-#include "omap_hwmod_34xx.h"
/*
* The machine specific code may provide the extra mapping besides the
@@ -305,21 +302,17 @@ static int __init _omap2_init_reprogram_sdrc(void)
void __init omap2_init_common_hw(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1)
{
- struct omap_hwmod **hwmods = NULL;
-
- if (cpu_is_omap2420())
- hwmods = omap2420_hwmods;
- else if (cpu_is_omap2430())
- hwmods = omap2430_hwmods;
- else if (cpu_is_omap34xx())
- hwmods = omap34xx_hwmods;
-
pwrdm_init(powerdomains_omap);
clkdm_init(clockdomains_omap, clkdm_autodeps);
#ifndef CONFIG_ARCH_OMAP4 /* FIXME: Remove this once the clkdev is ready */
- /* The OPP tables have to be registered before a clk init */
- omap_hwmod_init(hwmods);
+ if (cpu_is_omap242x())
+ omap2420_hwmod_init();
+ else if (cpu_is_omap243x())
+ omap2430_hwmod_init();
+ else if (cpu_is_omap34xx())
+ omap3xxx_hwmod_init();
omap2_mux_init();
+ /* The OPP tables have to be registered before a clk init */
omap_pm_if_early_init(mpu_opps, dsp_opps, l3_opps);
#endif
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420.h
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
similarity index 86%
rename from arch/arm/mach-omap2/omap_hwmod_2420.h
rename to arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 5932c1d..a1c5839 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420.h
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -1,7 +1,7 @@
/*
- * omap_hwmod_2420.h - hardware modules present on the OMAP2420 chips
+ * omap_hwmod_2420_data.c - hardware modules present on the OMAP2420 chips
*
- * Copyright (C) 2009 Nokia Corporation
+ * Copyright (C) 2009-2010 Nokia Corporation
* Paul Walmsley
*
* This program is free software; you can redistribute it and/or modify
@@ -9,13 +9,8 @@
* published by the Free Software Foundation.
*
* XXX handle crossbar/shared link difference for L3?
- *
+ * XXX these should be marked initdata for multi-OMAP kernels
*/
-#ifndef __ARCH_ARM_PLAT_OMAP_INCLUDE_MACH_OMAP_HWMOD2420_H
-#define __ARCH_ARM_PLAT_OMAP_INCLUDE_MACH_OMAP_HWMOD2420_H
-
-#ifdef CONFIG_ARCH_OMAP2420
-
#include
#include
#include
@@ -23,6 +18,15 @@
#include "prm-regbits-24xx.h"
+/*
+ * OMAP2420 hardware module integration data
+ *
+ * ALl of the data in this section should be autogeneratable from the
+ * TI hardware database or other technical documentation. Data that
+ * is driver-specific or driver-kernel integration-specific belongs
+ * elsewhere.
+ */
+
static struct omap_hwmod omap2420_mpu_hwmod;
static struct omap_hwmod omap2420_l3_hwmod;
s
[PATCH 09/11] OMAP4: clock: Rename leaf clock nodes to end with a _ick or _fck
From: Rajendra Nayak
All leaf clock nodes are renamed for OMAP4 to have a clk name which
end with a _ick or a _fck. This is done so that the naming convention
is same as that followed on older OMAPs.
Signed-off-by: Rajendra Nayak
Signed-off-by: Benoit Cousson
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clock44xx_data.c | 561 ++
1 files changed, 297 insertions(+), 264 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 6deca1e..c0825cf 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -1,8 +1,8 @@
/*
* OMAP4 Clock data
*
- * Copyright (C) 2009 Texas Instruments, Inc.
- * Copyright (C) 2009 Nokia Corporation
+ * Copyright (C) 2009-2010 Texas Instruments, Inc.
+ * Copyright (C) 2009-2010 Nokia Corporation
*
* Paul Walmsley (p...@pwsan.com)
* Rajendra Nayak (rna...@ti.com)
@@ -1254,8 +1254,8 @@ static struct clk syc_clk_div_ck = {
/* Leaf clocks controlled by modules */
-static struct clk aes1_ck = {
- .name = "aes1_ck",
+static struct clk aes1_fck = {
+ .name = "aes1_fck",
.ops= &clkops_omap2_dflt,
.enable_reg = OMAP4430_CM_L4SEC_AES1_CLKCTRL,
.enable_bit = OMAP4430_MODULEMODE_SWCTRL,
@@ -1264,8 +1264,8 @@ static struct clk aes1_ck = {
.recalc = &followparent_recalc,
};
-static struct clk aes2_ck = {
- .name = "aes2_ck",
+static struct clk aes2_fck = {
+ .name = "aes2_fck",
.ops= &clkops_omap2_dflt,
.enable_reg = OMAP4430_CM_L4SEC_AES2_CLKCTRL,
.enable_bit = OMAP4430_MODULEMODE_SWCTRL,
@@ -1274,8 +1274,8 @@ static struct clk aes2_ck = {
.recalc = &followparent_recalc,
};
-static struct clk aess_ck = {
- .name = "aess_ck",
+static struct clk aess_fck = {
+ .name = "aess_fck",
.ops= &clkops_omap2_dflt,
.enable_reg = OMAP4430_CM1_ABE_AESS_CLKCTRL,
.enable_bit = OMAP4430_MODULEMODE_SWCTRL,
@@ -1284,8 +1284,8 @@ static struct clk aess_ck = {
.recalc = &followparent_recalc,
};
-static struct clk cust_efuse_ck = {
- .name = "cust_efuse_ck",
+static struct clk cust_efuse_fck = {
+ .name = "cust_efuse_fck",
.ops= &clkops_omap2_dflt,
.enable_reg = OMAP4430_CM_CEFUSE_CEFUSE_CLKCTRL,
.enable_bit = OMAP4430_MODULEMODE_SWCTRL,
@@ -1294,8 +1294,8 @@ static struct clk cust_efuse_ck = {
.recalc = &followparent_recalc,
};
-static struct clk des3des_ck = {
- .name = "des3des_ck",
+static struct clk des3des_fck = {
+ .name = "des3des_fck",
.ops= &clkops_omap2_dflt,
.enable_reg = OMAP4430_CM_L4SEC_DES3DES_CLKCTRL,
.enable_bit = OMAP4430_MODULEMODE_SWCTRL,
@@ -1329,9 +1329,9 @@ static const struct clksel func_dmic_abe_gfclk_sel[] = {
{ .parent = NULL },
};
-/* Merged func_dmic_abe_gfclk into dmic_ck */
-static struct clk dmic_ck = {
- .name = "dmic_ck",
+/* Merged func_dmic_abe_gfclk into dmic */
+static struct clk dmic_fck = {
+ .name = "dmic_fck",
.parent = &dmic_sync_mux_ck,
.clksel = func_dmic_abe_gfclk_sel,
.init = &omap2_init_clksel_parent,
@@ -1344,8 +1344,8 @@ static struct clk dmic_ck = {
.clkdm_name = "abe_clkdm",
};
-static struct clk dss_ck = {
- .name = "dss_ck",
+static struct clk dss_fck = {
+ .name = "dss_fck",
.ops= &clkops_omap2_dflt,
.enable_reg = OMAP4430_CM_DSS_DSS_CLKCTRL,
.enable_bit = OMAP4430_MODULEMODE_SWCTRL,
@@ -1354,8 +1354,8 @@ static struct clk dss_ck = {
.recalc = &followparent_recalc,
};
-static struct clk ducati_ck = {
- .name = "ducati_ck",
+static struct clk ducati_ick = {
+ .name = "ducati_ick",
.ops= &clkops_omap2_dflt,
.enable_reg = OMAP4430_CM_DUCATI_DUCATI_CLKCTRL,
.enable_bit = OMAP4430_MODULEMODE_HWCTRL,
@@ -1364,8 +1364,8 @@ static struct clk ducati_ck = {
.recalc = &followparent_recalc,
};
-static struct clk emif1_ck = {
- .name = "emif1_ck",
+static struct clk emif1_ick = {
+ .name = "emif1_ick",
.ops= &clkops_omap2_dflt,
.enable_reg = OMAP4430_CM_MEMIF_EMIF_1_CLKCTRL,
.enable_bit = OMAP4430_MODULEMODE_HWCTRL,
@@ -1374,8 +1374,8 @@ static struct clk emif1_ck = {
.recalc = &followparent_recalc,
};
-static struct clk emif2_ck = {
- .name = "emif2_ck",
+static struct clk emif2_ick = {
+ .name = "emif2_ick",
.ops= &clkops_omap2_dflt,
[PATCH 08/11] OMAP2+ clock: revise omap2_clk_{disable,enable}()
Simplify the code in the omap2_clk_disable() and omap2_clk_enable()
functions, reducing levels of indentation. This makes the code easier
to read. Add some additional debugging pr_debug()s here also to help
others understand what is going on.
Revise the omap2_clk_disable() logic so that it now attempts to
disable the clock's clockdomain before recursing up the clock tree.
Simultaneously, ensure that omap2_clk_enable() is called on parent
clocks first, before enabling the clockdomain. This ensures that a
parent clock's clockdomain is enabled before the child clock's
clockdomain. These sequences should be the inverse of each other.
Revise the omap2_clk_enable() logic so that it now cleans up after
itself upon encountering an error. Previously, an error enabling a
parent clock could have resulted in inconsistent usecounts on the
enclosing clockdomain.
Remove the trivial _omap2_clk_disable() and _omap2_clk_enable() static
functions, and replace it with the clkops calls that they were
executing.
For all this to work, the clockdomain omap2_clkdm_clk_enable() and
omap2_clkdm_clk_disable() code must not return an error on clockdomains
without CLKSTCTRL registers; so modify those functions to simply return 0
in that case.
While here, add some basic kerneldoc documentation on both functions,
and get rid of some old non-CodingStyle-compliant comments that have
existed since the dawn of time (at least, the OMAP clock framework's
time).
Signed-off-by: Paul Walmsley
Cc: Richard Woodruff
Cc: Rajendra Nayak
---
arch/arm/mach-omap2/clock.c | 135 +
arch/arm/mach-omap2/clockdomain.c | 10 ++-
2 files changed, 99 insertions(+), 46 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index d1f115d..a6d0b34 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -37,9 +37,9 @@
u8 cpu_mask;
-/*-
- * OMAP2/3/4 specific clock functions
- *-*/
+/*
+ * OMAP2+ specific clock functions
+ */
/* Private functions */
@@ -71,20 +71,6 @@ static void _omap2_module_wait_ready(struct clk *clk)
clk->name);
}
-/* Enables clock without considering parent dependencies or use count
- * REVISIT: Maybe change this to use clk->enable like on omap1?
- */
-static int _omap2_clk_enable(struct clk *clk)
-{
- return clk->ops->enable(clk);
-}
-
-/* Disables clock without considering parent dependencies or use count */
-static void _omap2_clk_disable(struct clk *clk)
-{
- clk->ops->disable(clk);
-}
-
/* Public functions */
/**
@@ -245,46 +231,106 @@ const struct clkops clkops_omap2_dflt = {
.disable= omap2_dflt_clk_disable,
};
+/**
+ * omap2_clk_disable - disable a clock, if the system is not using it
+ * @clk: struct clk * to disable
+ *
+ * Decrements the usecount on struct clk @clk. If there are no users
+ * left, call the clkops-specific clock disable function to disable it
+ * in hardware. If the clock is part of a clockdomain (which they all
+ * should be), request that the clockdomain be disabled. (It too has
+ * a usecount, and so will not be disabled in the hardware until it no
+ * longer has any users.) If the clock has a parent clock (most of
+ * them do), then call ourselves, recursing on the parent clock. This
+ * can cause an entire branch of the clock tree to be powered off by
+ * simply disabling one clock. Intended to be called with the clockfw_lock
+ * spinlock held. No return value.
+ */
void omap2_clk_disable(struct clk *clk)
{
- if (clk->usecount > 0 && !(--clk->usecount)) {
- _omap2_clk_disable(clk);
- if (clk->parent)
- omap2_clk_disable(clk->parent);
- if (clk->clkdm)
- omap2_clkdm_clk_disable(clk->clkdm, clk);
-
+ if (clk->usecount == 0) {
+ WARN(1, "clock: %s: omap2_clk_disable() called, but usecount "
+"already 0?", clk->name);
+ return;
}
+
+ pr_debug("clock: %s: decrementing usecount\n", clk->name);
+
+ clk->usecount--;
+
+ if (clk->usecount > 0)
+ return;
+
+ pr_debug("clock: %s: disabling in hardware\n", clk->name);
+
+ clk->ops->disable(clk);
+
+ if (clk->clkdm)
+ omap2_clkdm_clk_disable(clk->clkdm, clk);
+
+ if (clk->parent)
+ omap2_clk_disable(clk->parent);
}
+/**
+ * omap2_clk_enable - request that the system enable a clock
+ * @clk: struct clk * to enable
+ *
+ * Increments the usecount on struct clk @clk. If there were no users
+ * previously, then recurse up the clock tree, enabling all of the
+ * clock's parents and all of the parent clockdomains, and finally,
+ * enabling @clk's clockdomain, and @clk itself. Intended to be
+ * called with th
[PATCH 06/11] OMAP clockdomain: if no autodeps exist, don't try to add or remove them
_clkdm_add_autodeps() and _clkdm_del_autodeps() will attempt to dereference
a NULL pointer if no autodeps were supplied to clkdm_init().
Based on a patch from Roel Kluin - thanks Roel.
Signed-off-by: Paul Walmsley
Cc: Roel Kluin
---
arch/arm/mach-omap2/clockdomain.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index de4278c..b26d30a 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -173,6 +173,9 @@ static void _clkdm_add_autodeps(struct clockdomain *clkdm)
{
struct clkdm_autodep *autodep;
+ if (!autodeps)
+ return;
+
for (autodep = autodeps; autodep->clkdm.ptr; autodep++) {
if (IS_ERR(autodep->clkdm.ptr))
continue;
@@ -201,6 +204,9 @@ static void _clkdm_del_autodeps(struct clockdomain *clkdm)
{
struct clkdm_autodep *autodep;
+ if (!autodeps)
+ return;
+
for (autodep = autodeps; autodep->clkdm.ptr; autodep++) {
if (IS_ERR(autodep->clkdm.ptr))
continue;
--
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 05/11] OMAP hwmod: add hwmod class support
Add support for categorizing and iterating over hardware IP blocks by
the "class" of the IP block. The class is the type of the IP block:
e.g., "timer", "timer1ms", etc. Move the OCP_SYSCONFIG/SYSSTATUS data
from the struct omap_hwmod into the struct omap_hwmod_class, since
it's expected to stay consistent for each class. While here, fix some
comments.
The hwmod_class structures in this patch were designed and proposed by
Benoît Cousson and were refined in a discussion
between Thara Gopinath , Kevin Hilman
, and myself.
This patch uses WARN() lines that are longer than 80 characters, as
Kevin noted a broader lkml consensus to increase greppability by
keeping the messages all on one line.
Signed-off-by: Paul Walmsley
Signed-off-by: Benoît Cousson
Cc: Thara Gopinath
Cc: Kevin Hilman
---
arch/arm/mach-omap2/Makefile |7 -
arch/arm/mach-omap2/omap_hwmod.c | 222 --
arch/arm/mach-omap2/omap_hwmod_2420_data.c |6 +
arch/arm/mach-omap2/omap_hwmod_2430_data.c |6 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |7 +
arch/arm/mach-omap2/omap_hwmod_common_data.c | 24 +++
arch/arm/mach-omap2/omap_hwmod_common_data.h | 24 +++
arch/arm/plat-omap/include/plat/omap_hwmod.h | 37 +++-
8 files changed, 234 insertions(+), 99 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap_hwmod_common_data.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 4aa621d..162294e 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -5,15 +5,16 @@
# Common support
obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o
-omap-2-3-common= irq.o sdrc.o omap_hwmod.o \
+omap-2-3-common= irq.o sdrc.o
+hwmod-common = omap_hwmod.o \
omap_hwmod_common_data.o
prcm-common= prcm.o powerdomain.o
clock-common = clock.o clock_common_data.o \
clockdomain.o clkt_dpll.o \
clkt_clksel.o
-obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(prcm-common)
-obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(prcm-common)
+obj-$(CONFIG_ARCH_OMAP2) += $(omap-2-3-common) $(prcm-common) $(hwmod-common)
+obj-$(CONFIG_ARCH_OMAP3) += $(omap-2-3-common) $(prcm-common) $(hwmod-common)
obj-$(CONFIG_ARCH_OMAP4) += $(prcm-common)
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 501660a..c664947 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -84,17 +84,16 @@ static u8 inited;
*/
static int _update_sysc_cache(struct omap_hwmod *oh)
{
- if (!oh->sysconfig) {
- WARN(!oh->sysconfig, "omap_hwmod: %s: cannot read "
-"OCP_SYSCONFIG: not defined on hwmod\n", oh->name);
+ if (!oh->class->sysc) {
+ WARN(1, "omap_hwmod: %s: cannot read OCP_SYSCONFIG: not defined
on hwmod's class\n", oh->name);
return -EINVAL;
}
/* XXX ensure module interface clock is up */
- oh->_sysc_cache = omap_hwmod_readl(oh, oh->sysconfig->sysc_offs);
+ oh->_sysc_cache = omap_hwmod_readl(oh, oh->class->sysc->sysc_offs);
- if (!(oh->sysconfig->sysc_flags & SYSC_NO_CACHE))
+ if (!(oh->class->sysc->sysc_flags & SYSC_NO_CACHE))
oh->_int_flags |= _HWMOD_SYSCONFIG_LOADED;
return 0;
@@ -105,14 +104,13 @@ static int _update_sysc_cache(struct omap_hwmod *oh)
* @v: OCP_SYSCONFIG value to write
* @oh: struct omap_hwmod *
*
- * Write @v into the module OCP_SYSCONFIG register, if it has one. No
- * return value.
+ * Write @v into the module class' OCP_SYSCONFIG register, if it has
+ * one. No return value.
*/
static void _write_sysconfig(u32 v, struct omap_hwmod *oh)
{
- if (!oh->sysconfig) {
- WARN(!oh->sysconfig, "omap_hwmod: %s: cannot write "
-"OCP_SYSCONFIG: not defined on hwmod\n", oh->name);
+ if (!oh->class->sysc) {
+ WARN(1, "omap_hwmod: %s: cannot write OCP_SYSCONFIG: not
defined on hwmod's class\n", oh->name);
return;
}
@@ -120,7 +118,7 @@ static void _write_sysconfig(u32 v, struct omap_hwmod *oh)
if (oh->_sysc_cache != v) {
oh->_sysc_cache = v;
- omap_hwmod_writel(v, oh, oh->sysconfig->sysc_offs);
+ omap_hwmod_writel(v, oh, oh->class->sysc->sysc_offs);
}
}
@@ -140,17 +138,16 @@ static int _set_master_standbymode(struct omap_hwmod *oh,
u8 standbymode,
u32 mstandby_mask;
u8 mstandby_shift;
- if (!oh->sysconfig ||
- !(oh->sysconfig->sysc_flags & SYSC_HAS_MIDLEMODE))
+ if (!oh->class->sysc ||
+ !(oh->class->sysc
[PATCH 11/11] OMAP4: clock: Remove clock hacks from timer-gp.c
From: Santosh Shilimkar
Now the omap4 clock framework is in mainline and clk_get_rate()
is functional. Hence reomve the hardcoded clock hacks.
This patch also fixes
Division by zero in kernel.
Backtrace:
[] (dump_backtrace+0x0/0x110) from [] (dump_stack+0x18/0x1c)
r7:6093 r6:c0641050 r5:c0223e78 r4:c02126b4
[] (dump_stack+0x0/0x1c) from [] (__div0+0x18/0x20)
[] (__div0+0x0/0x20) from [] (Ldiv0+0x8/0x10)
[] (omap_dm_timer_stop+0x0/0xb0) from []
(omap2_gp_timer_set_mode+0x1c/0x68)
r5:c0223e78 r4:
[] (omap2_gp_timer_set_mode+0x0/0x68) from []
(clockevents_set_mode+0x30/0x64)
r5:c020cae0 r4:
[] (clockevents_set_mode+0x0/0x64) from []
(clockevents_exchange_device+0x30/0x9c)
r5:c020cae0 r4:c02146e0
[] (clockevents_exchange_device+0x0/0x9c) from []
(tick_notify+0x17c/0x404)
r7: r6:c0641050 r5: r4:c020cae0
[] (tick_notify+0x0/0x404) from []
(notifier_call_chain+0x34/0x78)
[] (notifier_call_chain+0x0/0x78) from []
(__raw_notifier_call_chain+0x1c/0x24)
[] (__raw_notifier_call_chain+0x0/0x24) from []
(raw_notifier_call_chain+0x20/0x28)
[] (raw_notifier_call_chain+0x0/0x28) from []
(clockevents_do_notify+0x1c/0x24)
[] (clockevents_do_notify+0x0/0x24) from []
(clockevents_register_device+0x98/0xd0)
[] (clockevents_register_device+0x0/0xd0) from []
(percpu_timer_setup+0x80/0x9c)
r7: r6:0002 r5:0002 r4:0003
[] (percpu_timer_setup+0x0/0x9c) from []
(smp_prepare_cpus+0xb0/0xe8)
[] (smp_prepare_cpus+0x0/0xe8) from []
(kernel_init+0x5c/0x1fc)
r7: r6: r5: r4:c001b8a4
[] (kernel_init+0x0/0x1fc) from [] (do_exit+0x0/0x604)
r7: r6: r5: r4:
Signed-off-by: Santosh Shilimkar
Signed-off-by: Paul Walmsley
---
arch/arm/configs/omap_4430sdp_defconfig |7 ---
arch/arm/mach-omap2/timer-gp.c |5 -
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/arm/configs/omap_4430sdp_defconfig
b/arch/arm/configs/omap_4430sdp_defconfig
index 3de640a..7ac3fbf 100644
--- a/arch/arm/configs/omap_4430sdp_defconfig
+++ b/arch/arm/configs/omap_4430sdp_defconfig
@@ -199,7 +199,7 @@ CONFIG_ARCH_OMAP4=y
#
# CONFIG_OMAP_RESET_CLOCKS is not set
# CONFIG_OMAP_MUX is not set
-# CONFIG_OMAP_MCBSP is not set
+CONFIG_OMAP_MCBSP=y
# CONFIG_OMAP_MBOX_FWK is not set
# CONFIG_OMAP_MPU_TIMER is not set
CONFIG_OMAP_32K_TIMER=y
@@ -304,7 +304,7 @@ CONFIG_ALIGNMENT_TRAP=y
#
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
-CONFIG_CMDLINE="root=/dev/ram0 rw mem=128M console=ttyS0,115200n8
initrd=0x8160,20M ramdisk_size=20480"
+CONFIG_CMDLINE="root=/dev/ram0 rw mem=128M console=ttyS2,115200n8
initrd=0x8160,20M ramdisk_size=20480"
# CONFIG_XIP_KERNEL is not set
# CONFIG_KEXEC is not set
@@ -488,7 +488,8 @@ CONFIG_GPIOLIB=y
# CONFIG_POWER_SUPPLY is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
-# CONFIG_WATCHDOG is not set
+CONFIG_WATCHDOG=y
+CONFIG_OMAP_WATCHDOG=y
CONFIG_SSB_POSSIBLE=y
#
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
index cd04dea..74fbed8 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -85,8 +85,6 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode
mode,
case CLOCK_EVT_MODE_PERIODIC:
period = clk_get_rate(omap_dm_timer_get_fclk(gptimer)) / HZ;
period -= 1;
- if (cpu_is_omap44xx())
- period = 0xff; /* FIXME: */
omap_dm_timer_set_load_start(gptimer, 1, 0x - period);
break;
case CLOCK_EVT_MODE_ONESHOT:
@@ -150,9 +148,6 @@ static void __init omap2_gp_clockevent_init(void)
"timer-gp: omap_dm_timer_set_source() failed\n");
tick_rate = clk_get_rate(omap_dm_timer_get_fclk(gptimer));
- if (cpu_is_omap44xx())
- /* Assuming 32kHz clk is driving GPT1 */
- tick_rate = 32768; /* FIXME: */
pr_info("OMAP clockevent source: GPTIMER%d at %u Hz\n",
gptimer_id, tick_rate);
--
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 10/11] OMAP4: clock: Add dummy clock nodes for interface clocks
From: Santosh Shilimkar
On OMAP4 platform the iclk control is completly under hardware control
and no software control is available.
This difference w.r.t previous OMAP's needs all the common driver
accross OMAP's , cpu_is_() checks. To avoid poulluting the
drivers dummy clock nodes are created (The autogeneration
script has been updated accordingly).
Signed-off-by: Santosh Shilimkar
Signed-off-by: Rajendra Nayak
Signed-off-by: Benoit Cousson
[p...@pwsan.com: made OMAP1 dummy_ck common and edited patch to reuse that]
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap1/clock.c | 14
arch/arm/mach-omap1/clock_data.c|6 -
arch/arm/mach-omap2/clock.h |1 +
arch/arm/mach-omap2/clock44xx_data.c| 35 +++
arch/arm/plat-omap/clock.c | 10 +
arch/arm/plat-omap/include/plat/clock.h |2 ++
6 files changed, 48 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap1/clock.c b/arch/arm/mach-omap1/clock.c
index 0ba044d..e0aec10 100644
--- a/arch/arm/mach-omap1/clock.c
+++ b/arch/arm/mach-omap1/clock.c
@@ -38,20 +38,6 @@ struct clk *api_ck_p, *ck_dpll1_p, *ck_ref_p;
* Omap1 specific clock functions
*-*/
-static int clk_omap1_dummy_enable(struct clk *clk)
-{
- return 0;
-}
-
-static void clk_omap1_dummy_disable(struct clk *clk)
-{
-}
-
-const struct clkops clkops_dummy = {
- .enable = clk_omap1_dummy_enable,
- .disable= clk_omap1_dummy_disable,
-};
-
unsigned long omap1_uart_recalc(struct clk *clk)
{
unsigned int val = __raw_readl(clk->enable_reg);
diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index 8b1d14d..aa8558a 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -27,12 +27,6 @@
* Omap1 clocks
*-*/
-/* XXX is this necessary? */
-static struct clk dummy_ck = {
- .name = "dummy",
- .ops= &clkops_dummy,
-};
-
static struct clk ck_ref = {
.name = "ck_ref",
.ops= &clkops_null,
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 49ad473..816d932 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -101,6 +101,7 @@ void omap2_clk_print_new_rates(const char *hfclkin_ck_name,
extern u8 cpu_mask;
extern const struct clkops clkops_omap2_dflt_wait;
+extern const struct clkops clkops_dummy;
extern const struct clkops clkops_omap2_dflt;
extern struct clk_functions omap2_clk_functions;
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index c0825cf..28b1079 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -2645,6 +2645,41 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, "usim_fclk",&usim_fclk,
CK_443X),
CLK(NULL, "utmi_p1_gfclk_ck", &utmi_p1_gfclk_ck,
CK_443X),
CLK(NULL, "utmi_p2_gfclk_ck", &utmi_p2_gfclk_ck,
CK_443X),
+ CLK(NULL, "gpio1_dbck", &dummy_ck,
CK_443X),
+ CLK(NULL, "gpio2_dbck", &dummy_ck,
CK_443X),
+ CLK(NULL, "gpio3_dbck", &dummy_ck,
CK_443X),
+ CLK(NULL, "gpio4_dbck", &dummy_ck,
CK_443X),
+ CLK(NULL, "gpio5_dbck", &dummy_ck,
CK_443X),
+ CLK(NULL, "gpio6_dbck", &dummy_ck,
CK_443X),
+ CLK(NULL, "gpmc_ck", &dummy_ck,
CK_443X),
+ CLK(NULL, "gpt1_ick", &dummy_ck,
CK_443X),
+ CLK(NULL, "gpt2_ick", &dummy_ck,
CK_443X),
+ CLK(NULL, "gpt3_ick", &dummy_ck,
CK_443X),
+ CLK(NULL, "gpt4_ick", &dummy_ck,
CK_443X),
+ CLK(NULL, "gpt5_ick", &dummy_ck,
CK_443X),
+ CLK(NULL, "gpt6_ick", &dummy_ck,
CK_443X),
+ CLK(NULL, "gpt7_ick", &dummy_ck,
CK_443X),
+ CLK(NULL, "gpt8_ick", &dummy_ck,
CK_443X),
+ CLK(NULL, "gpt9_ick", &dummy_ck,
CK_443X),
+ CLK(NULL, "gpt10_ick",&dummy_ck,
CK_443X),
+ CLK(NULL, "gpt11_ick",&dummy_ck,
CK_443X),
+ CLK("i2c_omap.1", "ick", &dummy_ck,
CK_443X),
+ CLK("i2c_omap.2", "ick", &dummy_ck,
CK_443X),
+ CLK("i2c_omap.3", "ick",
[PATCH 03/11] OMAP hwmod: convert hwmod to use hardware clock names rather than clkdev dev+con
The OMAP hwmod core code is intended to use SoC IP block description
structures that are autogenerated from TI's OMAP hardware database.
Currently the hwmod code uses clkdev device + connection addressing to
identify clocks. This causes problems in the hwmod autogeneration
process, since the TI hardware database doesn't use platform_device or
clkdev addressing; it uses a single clock signal name string, which
tends to bear some resemblance to what is used in the OMAP TRMs. This
patch converts the hwmod code and existing data to use omap_clk_get_by_name(),
introduced in the previous patch.
Signed-off-by: Paul Walmsley
Cc: Benoît Cousson
Cc: Kevin Hilman
---
arch/arm/mach-omap2/omap_hwmod.c | 22 ++
arch/arm/mach-omap2/omap_hwmod_2420.h|3 +--
arch/arm/mach-omap2/omap_hwmod_2430.h|3 +--
arch/arm/mach-omap2/omap_hwmod_34xx.h|3 +--
arch/arm/plat-omap/include/plat/omap_hwmod.h | 26 ++
5 files changed, 23 insertions(+), 34 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index fb11ec1..501660a 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -416,18 +416,18 @@ static int _init_main_clk(struct omap_hwmod *oh)
struct clk *c;
int ret = 0;
- if (!oh->clkdev_con_id)
+ if (!oh->main_clk)
return 0;
- c = clk_get_sys(oh->clkdev_dev_id, oh->clkdev_con_id);
- WARN(IS_ERR(c), "omap_hwmod: %s: cannot clk_get main_clk %s.%s\n",
-oh->name, oh->clkdev_dev_id, oh->clkdev_con_id);
+ c = omap_clk_get_by_name(oh->main_clk);
+ WARN(IS_ERR(c), "omap_hwmod: %s: cannot clk_get main_clk %s\n",
+oh->name, oh->main_clk);
if (IS_ERR(c))
ret = -EINVAL;
oh->_clk = c;
WARN(!c->clkdm, "omap_hwmod: %s: missing clockdomain for %s.\n",
-oh->clkdev_con_id, c->name);
+oh->main_clk, c->name);
return ret;
}
@@ -450,13 +450,12 @@ static int _init_interface_clks(struct omap_hwmod *oh)
return 0;
for (i = 0, os = *oh->slaves; i < oh->slaves_cnt; i++, os++) {
- if (!os->clkdev_con_id)
+ if (!os->clk)
continue;
- c = clk_get_sys(os->clkdev_dev_id, os->clkdev_con_id);
+ c = omap_clk_get_by_name(os->clk);
WARN(IS_ERR(c), "omap_hwmod: %s: cannot clk_get "
-"interface_clk %s.%s\n", oh->name,
-os->clkdev_dev_id, os->clkdev_con_id);
+"interface_clk %s\n", oh->name, os->clk);
if (IS_ERR(c))
ret = -EINVAL;
os->_clk = c;
@@ -480,10 +479,9 @@ static int _init_opt_clks(struct omap_hwmod *oh)
int ret = 0;
for (i = oh->opt_clks_cnt, oc = oh->opt_clks; i > 0; i--, oc++) {
- c = clk_get_sys(oc->clkdev_dev_id, oc->clkdev_con_id);
+ c = omap_clk_get_by_name(oc->clk);
WARN(IS_ERR(c), "omap_hwmod: %s: cannot clk_get opt_clk "
-"%s.%s\n", oh->name, oc->clkdev_dev_id,
-oc->clkdev_con_id);
+"%s\n", oh->name, oc->clk);
if (IS_ERR(c))
ret = -EINVAL;
oc->_clk = c;
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420.h
b/arch/arm/mach-omap2/omap_hwmod_2420.h
index a9ca1b9..5932c1d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420.h
+++ b/arch/arm/mach-omap2/omap_hwmod_2420.h
@@ -117,8 +117,7 @@ static struct omap_hwmod_ocp_if *omap2420_mpu_masters[] = {
/* MPU */
static struct omap_hwmod omap2420_mpu_hwmod = {
.name = "mpu_hwmod",
- .clkdev_dev_id = NULL,
- .clkdev_con_id = "mpu_ck",
+ .main_clk = "mpu_ck",
.masters= omap2420_mpu_masters,
.masters_cnt= ARRAY_SIZE(omap2420_mpu_masters),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430.h
b/arch/arm/mach-omap2/omap_hwmod_2430.h
index 59a208b..91f79c0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430.h
+++ b/arch/arm/mach-omap2/omap_hwmod_2430.h
@@ -119,8 +119,7 @@ static struct omap_hwmod_ocp_if *omap2430_mpu_masters[] = {
/* MPU */
static struct omap_hwmod omap2430_mpu_hwmod = {
.name = "mpu_hwmod",
- .clkdev_dev_id = NULL,
- .clkdev_con_id = "mpu_ck",
+ .main_clk = "mpu_ck",
.masters= omap2430_mpu_masters,
.masters_cnt= ARRAY_SIZE(omap2430_mpu_masters),
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
diff --git a/arch/arm/mach-omap2/omap_hwmod_34xx.h
b/arch/arm/mach-omap2/omap_hwmod_34xx.h
index b6076b9..4aea5b9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_34xx.h
+++ b/arch/arm/mach-omap2/omap_hwmod_34xx.h
@@ -143,8 +143,7 @@ static struct omap_hwmod_oc
[PATCH 01/11] OMAP3: clock: add capability to change rate of dpll4_m5_ck_3630
From: Vimarsh Zutshi
Add necessary clk_sel definitions to clock framework to allow changing
dpll4_m5_ck_3630 rate. This is used by the ISP driver.
Signed-off-by: Vimarsh Zutshi
[p...@pwsan.com: updated to apply]
Signed-off-by: Paul Walmsley
---
arch/arm/mach-omap2/clock3xxx_data.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index fd83230..d5153b6 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -927,6 +927,8 @@ static struct clk dpll4_m5_ck_3630 __initdata = {
.clksel_mask= OMAP3630_CLKSEL_CAM_MASK,
.clksel = div32_dpll4_clksel,
.clkdm_name = "dpll4_clkdm",
+ .set_rate = &omap2_clksel_set_rate,
+ .round_rate = &omap2_clksel_round_rate,
.recalc = &omap2_clksel_recalc,
};
--
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 02/11] OMAP clock: add omap_clk_get_by_name() for use by OMAP hwmod core code
The OMAP hwmod core code is intended to use SoC IP block description
structures that are autogenerated from TI's OMAP hardware database.
Currently the hwmod code uses clkdev device + connection addressing to
identify clocks. This causes problems in the hwmod autogeneration
process, since the TI hardware database doesn't use platform_device or
clkdev addressing; it uses a single clock signal name string, which
tends to bear some resemblance to what is used in the OMAP TRMs. This
patch adds a non-exported function to the OMAP clock code,
omap_clk_get_by_name(). A subsequent patch will convert the hwmod
code to use this function.
This function is for use only by core code, and practically, no other
code outside the hwmod code should need it. Device driver code in the
kernel must not use this function, which is why it is not exported.
Drivers should use the appropriate clock alias provided by the clkdev
data structures, so driver code can be completely SoC-independent.
Signed-off-by: Paul Walmsley
Cc: Benoît Cousson
Cc: Kevin Hilman
---
arch/arm/plat-omap/clock.c | 27 +++
arch/arm/plat-omap/include/plat/clock.h |1 +
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index f244b17..6cc13e7 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -313,6 +313,33 @@ void clk_enable_init_clocks(void)
}
}
+/**
+ * omap_clk_get_by_name - locate OMAP struct clk by its name
+ * @name: name of the struct clk to locate
+ *
+ * Locate an OMAP struct clk by its name. Assumes that struct clk
+ * names are unique. Returns NULL if not found or a pointer to the
+ * struct clk if found.
+ */
+struct clk *omap_clk_get_by_name(const char *name)
+{
+ struct clk *c;
+ struct clk *ret = NULL;
+
+ mutex_lock(&clocks_mutex);
+
+ list_for_each_entry(c, &clocks, node) {
+ if (!strcmp(c->name, name)) {
+ ret = c;
+ break;
+ }
+ }
+
+ mutex_unlock(&clocks_mutex);
+
+ return ret;
+}
+
/*
* Low level helpers
*/
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index 5e1c035..6a32ac1 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -184,6 +184,7 @@ unsigned long omap_fixed_divisor_recalc(struct clk *clk);
extern void clk_init_cpufreq_table(struct cpufreq_frequency_table **table);
extern void clk_exit_cpufreq_table(struct cpufreq_frequency_table **table);
#endif
+extern struct clk *omap_clk_get_by_name(const char *name);
extern const struct clkops clkops_null;
--
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 00/11] OMAP clock/hwmod: final set of 2.6.34 patches
Hello,
Here are a few more OMAP clock and hwmod patches intended for 2.6.34,
posted in case anyone has any review comments.
These patches have been boot-tested on OSK5912, N800, 2430SDP,
Overo; and compile-tested on 4430SDP.
- Paul
---
size:
textdata bss dec hex filename
2882000 127872 88872 3098744 2f4878 vmlinux.osk5912.orig
2882016 127872 88872 3098760 2f4888 vmlinux.osk5912.patched
2324953 121440 63728 2510121 264d29 vmlinux.n8x0.orig
2325885 121536 63728 2511149 26512d vmlinux.n8x0.patched
3422044 176928 146928 3745900 39286c vmlinux.2430sdp.orig
3423048 177024 146928 3747000 392cb8 vmlinux.2430sdp.patched
6060161 1797424 5800396 13657981 d0677d vmlinux.omap3.orig
6061113 1797488 5800396 13658997 d06b75 vmlinux.omap3.patched
2049131 168736 65412 2283279 22d70f vmlinux.4430sdp.orig
2050167 169632 65412 2285211 22de9b vmlinux.4430sdp.patched
Paul Walmsley (7):
OMAP clock: add omap_clk_get_by_name() for use by OMAP hwmod core code
OMAP hwmod: convert hwmod to use hardware clock names rather than clkdev
dev+con
OMAP hwmod: convert header files with static allocations into C files
OMAP hwmod: add hwmod class support
OMAP clockdomain: if no autodeps exist, don't try to add or remove them
OMAP2/3 clock: combine OMAP2 & 3 boot-time MPU rate change code
OMAP2+ clock: revise omap2_clk_{disable,enable}()
Rajendra Nayak (1):
OMAP4: clock: Rename leaf clock nodes to end with a _ick or _fck
Santosh Shilimkar (2):
OMAP4: clock: Add dummy clock nodes for interface clocks
OMAP4: clock: Remove clock hacks from timer-gp.c
Vimarsh Zutshi (1):
From 5c87e27fd557a56aca72cd10529c3bdcb0c8a517 Mon Sep 17 00:00:00 2001
arch/arm/configs/omap_4430sdp_defconfig |7
arch/arm/mach-omap1/clock.c | 14 -
arch/arm/mach-omap1/clock_data.c |6
arch/arm/mach-omap2/Makefile | 12 -
arch/arm/mach-omap2/clock.c | 220 --
arch/arm/mach-omap2/clock.h |5
arch/arm/mach-omap2/clock2xxx.c | 34 -
arch/arm/mach-omap2/clock3xxx.c | 59 ---
arch/arm/mach-omap2/clock3xxx_data.c |2
arch/arm/mach-omap2/clock44xx_data.c | 596 ++
arch/arm/mach-omap2/clockdomain.c| 16 +
arch/arm/mach-omap2/io.c | 21 -
arch/arm/mach-omap2/omap_hwmod.c | 244 ++-
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 38 +-
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 38 +-
arch/arm/mach-omap2/omap_hwmod_34xx.h| 168 ---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 181
arch/arm/mach-omap2/omap_hwmod_common_data.c | 24 +
arch/arm/mach-omap2/omap_hwmod_common_data.h | 24 +
arch/arm/mach-omap2/timer-gp.c |5
arch/arm/plat-omap/clock.c | 37 ++
arch/arm/plat-omap/include/plat/clock.h |3
arch/arm/plat-omap/include/plat/omap_hwmod.h | 71 ++-
23 files changed, 1073 insertions(+), 752 deletions(-)
rename arch/arm/mach-omap2/{omap_hwmod_2420.h => omap_hwmod_2420_data.c} (82%)
rename arch/arm/mach-omap2/{omap_hwmod_2430.h => omap_hwmod_2430_data.c} (83%)
delete mode 100644 arch/arm/mach-omap2/omap_hwmod_34xx.h
create mode 100644 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
create mode 100644 arch/arm/mach-omap2/omap_hwmod_common_data.h
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap: mailbox: unregister correct mbox device for omap2420
Hi Aguilar, > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Aguilar Pena, Leed > Sent: Monday, February 22, 2010 5:55 PM > To: linux-omap@vger.kernel.org > Cc: t...@atomide.com; Hiroshi DOYU > Subject: [PATCH] omap: mailbox: unregister correct mbox device for > omap2420 > > label err_iva1 is defined to unregister the mbox device > for omap2420 which is contained in mbox_iva_info struct > > mbox_dsp_info is not being used by the omap2420 > > Signed-off-by: Leed Aguilar > --- > arch/arm/mach-omap2/mailbox.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > Index: omap/arch/arm/mach-omap2/mailbox.c > === > --- omap.orig/arch/arm/mach-omap2/mailbox.c 2010-02-22 > 17:41:24.0 -0600 > +++ omap/arch/arm/mach-omap2/mailbox.c2010-02-22 17:51:31.0 - > 0600 > @@ -420,7 +420,7 @@ > return 0; > > err_iva1: > - omap_mbox_unregister(&mbox_dsp_info); > + omap_mbox_unregister(&mbox_iva_info); The err_iva1 label is indicating that the iva1 registration has failed, and you need to free the previously registered dsp. So, this patch is not valid. > > err_dsp: > iounmap(mbox_base); > -- > 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 Regards Suman -- 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: [RESEND] [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning
On 2/22/2010 5:57 PM, Ramirez Luna, Omar wrote: why not moving omap_mbox_unregister to the block containing the ifdefs? at least you won't be adding an ifdef and if(cpu_xx) i take this back... both statements are needed because of previous registration. - omar -- 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: [RESEND] [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning
On 2/22/2010 5:41 PM, Anna, Suman wrote:
From 657358cd06a3f20bef2472945991749bacef12e6 Mon Sep 17 00:00:00 2001
From: Suman Anna
Date: Mon, 25 Jan 2010 18:27:21 -0600
Subject: [PATCH] omap2/3/4: mailbox: remove compiler warning
Remove a compiler warning in device-specific
mailbox module.
Signed-off-by: Suman Anna
---
arch/arm/mach-omap2/mailbox.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 2c9fd1c..8b5fc2a 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -419,8 +419,11 @@ static int __devinit omap2_mbox_probe(struct
platform_device *pdev)
#endif
return 0;
+#if defined(CONFIG_ARCH_OMAP2420) /* IVA */
err_iva1:
- omap_mbox_unregister(&mbox_dsp_info);
+ if (cpu_is_omap2420())
+ omap_mbox_unregister(&mbox_dsp_info);
+#endif
why not moving omap_mbox_unregister to the block containing the ifdefs?
at least you won't be adding an ifdef and if(cpu_xx)
from mailbox.c:
#if defined(CONFIG_ARCH_OMAP2420) /* IVA */
if (cpu_is_omap2420()) {
/* IVA IRQ */
res = platform_get_resource(pdev, IORESOURCE_IRQ, 1);
if (unlikely(!res)) {
dev_err(&pdev->dev, "invalid irq resource\n");
ret = -ENODEV;
goto err_iva1;
this is not even needed because at this point mailbox has not been
registered (unless i'm missing something)
}
mbox_iva_info.irq = res->start;
ret = omap_mbox_register(&pdev->dev, &mbox_iva_info);
if (ret)
goto err_iva1;
this should be omap_mbox_unregister... I haven't looked to the code to
comment if its needed to call omap_mbox_unregister when
omap_mbox_register fails.
}
#endif
Regards,
- omar
--
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: mailbox: unregister correct mbox device for omap2420
label err_iva1 is defined to unregister the mbox device for omap2420 which is contained in mbox_iva_info struct mbox_dsp_info is not being used by the omap2420 Signed-off-by: Leed Aguilar --- arch/arm/mach-omap2/mailbox.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Index: omap/arch/arm/mach-omap2/mailbox.c === --- omap.orig/arch/arm/mach-omap2/mailbox.c 2010-02-22 17:41:24.0 -0600 +++ omap/arch/arm/mach-omap2/mailbox.c 2010-02-22 17:51:31.0 -0600 @@ -420,7 +420,7 @@ return 0; err_iva1: - omap_mbox_unregister(&mbox_dsp_info); + omap_mbox_unregister(&mbox_iva_info); err_dsp: iounmap(mbox_base); -- 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
[RESEND] [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning
>From 657358cd06a3f20bef2472945991749bacef12e6 Mon Sep 17 00:00:00 2001 From: Suman Anna Date: Mon, 25 Jan 2010 18:27:21 -0600 Subject: [PATCH] omap2/3/4: mailbox: remove compiler warning Remove a compiler warning in device-specific mailbox module. Signed-off-by: Suman Anna --- arch/arm/mach-omap2/mailbox.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c index 2c9fd1c..8b5fc2a 100644 --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -419,8 +419,11 @@ static int __devinit omap2_mbox_probe(struct platform_device *pdev) #endif return 0; +#if defined(CONFIG_ARCH_OMAP2420) /* IVA */ err_iva1: - omap_mbox_unregister(&mbox_dsp_info); + if (cpu_is_omap2420()) + omap_mbox_unregister(&mbox_dsp_info); +#endif err_dsp: iounmap(mbox_base); -- 1.6.6.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 1/5] omap2/3/4: mailbox: remove compiler warning
* Anna, Suman [100222 13:41]:
> Tony,
>
>
> > -Original Message-
> > From: Tony Lindgren [mailto:t...@atomide.com]
> > Sent: Monday, February 22, 2010 3:37 PM
> > To: Anna, Suman
> > Cc: Shilimkar, Santosh; linux-omap@vger.kernel.org;
> > hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, Subramaniam
> > Subject: Re: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning
> >
> > * Anna, Suman [100222 11:53]:
> > > Hi Santosh,
> > >
> > > > -Original Message-
> > > > From: Shilimkar, Santosh
> > > > Sent: Saturday, February 20, 2010 12:47 PM
> > > > To: Anna, Suman; linux-omap@vger.kernel.org
> > > > Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A,
> > Subramaniam
> > > > Subject: RE: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning
> > > >
> > > > > -Original Message-
> > > > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > > > ow...@vger.kernel.org] On Behalf Of Anna,
> > > > > Suman
> > > > > Sent: Friday, February 19, 2010 2:37 AM
> > > > > To: linux-omap@vger.kernel.org
> > > > > Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A,
> > Subramaniam
> > > > > Subject: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning
> > > > >
> > > > > From 78d00b562548e1d95ad12a4d8121be67950daf68 Mon Sep 17 00:00:00
> > 2001
> > > > > From: Suman Anna
> > > > > Date: Mon, 25 Jan 2010 18:27:21 -0600
> > > > > Subject: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning
> > > > >
> > > > > Remove a compiler warning in device-specific
> > > > > mailbox module.
> > > > >
> > > > > Signed-off-by: Suman Anna
> > > > > ---
> > > > > arch/arm/mach-omap2/mailbox.c |2 ++
> > > > > 1 files changed, 2 insertions(+), 0 deletions(-)
> > > > >
> > > > > diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-
> > > > omap2/mailbox.c
> > > > > index 2c9fd1c..c970cf6 100644
> > > > > --- a/arch/arm/mach-omap2/mailbox.c
> > > > > +++ b/arch/arm/mach-omap2/mailbox.c
> > > > > @@ -419,8 +419,10 @@ static int __devinit omap2_mbox_probe(struct
> > > > platform_device *pdev)
> > > > > #endif
> > > > > return 0;
> > > > >
> > > > > +#if defined(CONFIG_ARCH_OMAP2420) /* IVA */
> > > > > err_iva1:
> > > > > omap_mbox_unregister(&mbox_dsp_info);
> > > > > +#endif
> > > > Can't we avoid the #ifdef here? Is this "omap_mbox_unregister" omap2
> > > > specific?
> > >
> > > Yes, this #ifdef is specific to 2420. There are other places in the
> > mailbox code which also utilize a similar #ifdef. I have merely added it
> > to remove the compile warning. I think it needs a separate patch to remove
> > all the 2420 specific #ifdefs.
> >
>
>
> > Let's drop this patch for now. We should fix this with something like
> > this in mailbox.h:
> >
> > #ifdef CONFIG_ARCH_OMAP2420
> > int omap_mbox_unregister(struct omap_mbox *);
> > #else
> > static inline int omap_mbox_unregister(struct omap_mbox *mbox)
> > {
> > return 0;
> > }
> > #endif
> >
> > That way we can get rid of the ifdefs in other places too.
> >
> > Tony
>
> Sorry, my statement is a little bit misleading. The omap_mbox_unregister
> function itself is not specific to 2420, but rather the call is. It should be
> called only for 2420, and hence the #ifdef.
OK, maybe you can update to just test for if (cpu_is_omap2420())
there?
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] omap3/4: uart: fix full-fifo write abort
* Tony Lindgren [100222 13:35]: > * Shilimkar, Santosh [100218 21:22]: > > Bye the way just to add bit more clarity, this patch addresses TX > > hardware restriction in the new UART IP used on omap3630 and omap4430. > > First part of the fix for RX is already in mainline, > > Commit: "ce13d4716a276f4331d78ba28a5093a63822ab95" > > > > More details on this thread are here. > > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg19447.html > > Thanks, I've updated the comments for this patch with the link above > and added the whole series into omap for-next. Except patches 8 and 9 as they break compile for mach-omap1 and need to be updated. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/9] omap4: Use dma line defines from dma-44xx.h
* Santosh Shilimkar [100218 00:56]: > This patch removes all the omap4 specific dma request > lines defines from plat/dma.h and includes dma-44xx.h > > The defines are aligned so no driver should be impacted > because of this change. Dropped this and the next patch as they break compile for _all_ omap1 machines: arch/arm/plat-omap/dma.c: In function 'omap_init_dma': arch/arm/plat-omap/dma.c:2135: error: 'OMAP44XX_IRQ_SDMA_0' undeclared (first use in this function) arch/arm/plat-omap/dma.c:2135: error: (Each undeclared identifier is reported only once arch/arm/plat-omap/dma.c:2135: error: for each function it appears in.) Suspect the next patch will too, not even going to try to build test that. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning
Tony,
> -Original Message-
> From: Tony Lindgren [mailto:t...@atomide.com]
> Sent: Monday, February 22, 2010 3:37 PM
> To: Anna, Suman
> Cc: Shilimkar, Santosh; linux-omap@vger.kernel.org;
> hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, Subramaniam
> Subject: Re: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning
>
> * Anna, Suman [100222 11:53]:
> > Hi Santosh,
> >
> > > -Original Message-
> > > From: Shilimkar, Santosh
> > > Sent: Saturday, February 20, 2010 12:47 PM
> > > To: Anna, Suman; linux-omap@vger.kernel.org
> > > Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A,
> Subramaniam
> > > Subject: RE: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning
> > >
> > > > -Original Message-
> > > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > > ow...@vger.kernel.org] On Behalf Of Anna,
> > > > Suman
> > > > Sent: Friday, February 19, 2010 2:37 AM
> > > > To: linux-omap@vger.kernel.org
> > > > Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A,
> Subramaniam
> > > > Subject: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning
> > > >
> > > > From 78d00b562548e1d95ad12a4d8121be67950daf68 Mon Sep 17 00:00:00
> 2001
> > > > From: Suman Anna
> > > > Date: Mon, 25 Jan 2010 18:27:21 -0600
> > > > Subject: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning
> > > >
> > > > Remove a compiler warning in device-specific
> > > > mailbox module.
> > > >
> > > > Signed-off-by: Suman Anna
> > > > ---
> > > > arch/arm/mach-omap2/mailbox.c |2 ++
> > > > 1 files changed, 2 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-
> > > omap2/mailbox.c
> > > > index 2c9fd1c..c970cf6 100644
> > > > --- a/arch/arm/mach-omap2/mailbox.c
> > > > +++ b/arch/arm/mach-omap2/mailbox.c
> > > > @@ -419,8 +419,10 @@ static int __devinit omap2_mbox_probe(struct
> > > platform_device *pdev)
> > > > #endif
> > > > return 0;
> > > >
> > > > +#if defined(CONFIG_ARCH_OMAP2420) /* IVA */
> > > > err_iva1:
> > > > omap_mbox_unregister(&mbox_dsp_info);
> > > > +#endif
> > > Can't we avoid the #ifdef here? Is this "omap_mbox_unregister" omap2
> > > specific?
> >
> > Yes, this #ifdef is specific to 2420. There are other places in the
> mailbox code which also utilize a similar #ifdef. I have merely added it
> to remove the compile warning. I think it needs a separate patch to remove
> all the 2420 specific #ifdefs.
>
> Let's drop this patch for now. We should fix this with something like
> this in mailbox.h:
>
> #ifdef CONFIG_ARCH_OMAP2420
> int omap_mbox_unregister(struct omap_mbox *);
> #else
> static inline int omap_mbox_unregister(struct omap_mbox *mbox)
> {
> return 0;
> }
> #endif
>
> That way we can get rid of the ifdefs in other places too.
>
> Tony
Sorry, my statement is a little bit misleading. The omap_mbox_unregister
function itself is not specific to 2420, but rather the call is. It should be
called only for 2420, and hence the #ifdef.
Regards
Suman
--
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/9] omap3/4: uart: fix full-fifo write abort
* Shilimkar, Santosh [100218 21:22]:
> Bye the way just to add bit more clarity, this patch addresses TX
> hardware restriction in the new UART IP used on omap3630 and omap4430.
> First part of the fix for RX is already in mainline,
> Commit: "ce13d4716a276f4331d78ba28a5093a63822ab95"
>
> More details on this thread are here.
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg19447.html
Thanks, I've updated the comments for this patch with the link above
and added the whole series into omap for-next.
Regards,
Tony
> > -Original Message-
> > From: Shilimkar, Santosh
> > Sent: Thursday, February 18, 2010 2:29 PM
> > To: t...@atomide.com
> > Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > Shilimkar, Santosh; Woodruff,
> > Richard; Ghorai, Sukumar
> > Subject: [PATCH 1/9] omap3/4: uart: fix full-fifo write abort
> >
> > This patch is addition to the already merged commit on non-empty
> > uart fifo read abort. "ce13d4716a276f4331d78ba28a5093a63822ab95"
> >
> > OMAP3630 and OMAP4430 UART IP blocks have a restriction on TX FIFO
> > too. If you try to write to the tx fifo when it is full, the system aborts.
> >
> > This can be easily reproducible by not suppressing interconnect errors or
> > long duration testing where continuous prints over console from multiple
> > threads. This patch is addressing the issue by ensuring that write is
> > not issued while fifo is full. A timeout is added to avoid any hang
> > on fifo-full for 10 mS which is unlikely case.
> >
> > Patch is validated on OMAP3630 and OMAP4 SDP.
> >
> > V2 version removed the additional 1 uS on every TX as per
> > Tony's suggestion
> >
> > Signed-off-by: Woodruff Richard
> > Signed-off-by: Santosh Shilimkar
> > CC: Ghorai Sukumar
> > ---
> > arch/arm/mach-omap2/serial.c | 31 ---
> > 1 files changed, 28 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> > index 5f3035e..b79bc89 100644
> > --- a/arch/arm/mach-omap2/serial.c
> > +++ b/arch/arm/mach-omap2/serial.c
> > @@ -23,6 +23,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > @@ -160,6 +161,13 @@ static inline unsigned int serial_read_reg(struct
> > plat_serial8250_port *up,
> > return (unsigned int)__raw_readb(up->membase + offset);
> > }
> >
> > +static inline void __serial_write_reg(struct uart_port *up, int offset,
> > + int value)
> > +{
> > + offset <<= up->regshift;
> > + __raw_writeb(value, up->membase + offset);
> > +}
> > +
> > static inline void serial_write_reg(struct plat_serial8250_port *p, int
> > offset,
> > int value)
> > {
> > @@ -620,6 +628,20 @@ static unsigned int serial_in_override(struct
> > uart_port *up, int offset)
> > return __serial_read_reg(up, offset);
> > }
> >
> > +static void serial_out_override(struct uart_port *up, int offset, int
> > value)
> > +{
> > + unsigned int status, tmout = 1;
> > +
> > + status = __serial_read_reg(up, UART_LSR);
> > + while (!(status & UART_LSR_THRE)) {
> > + /* Wait up to 10ms for the character(s) to be sent. */
> > + if (--tmout == 0)
> > + break;
> > + udelay(1);
> > + status = __serial_read_reg(up, UART_LSR);
> > + }
> > + __serial_write_reg(up, offset, value);
> > +}
> > void __init omap_serial_early_init(void)
> > {
> > int i;
> > @@ -721,11 +743,14 @@ void __init omap_serial_init_port(int port)
> > * omap3xxx: Never read empty UART fifo on UARTs
> > * with IP rev >=0x52
> > */
> > - if (cpu_is_omap44xx())
> > + if (cpu_is_omap44xx()) {
> > uart->p->serial_in = serial_in_override;
> > - else if ((serial_read_reg(uart->p, UART_OMAP_MVER) & 0xFF)
> > - >= UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV)
> > + uart->p->serial_out = serial_out_override;
> > + } else if ((serial_read_reg(uart->p, UART_OMAP_MVER) & 0xFF)
> > + >= UART_OMAP_NO_EMPTY_FIFO_READ_IP_REV) {
> > uart->p->serial_in = serial_in_override;
> > + uart->p->serial_out = serial_out_override;
> > + }
> > }
> >
> > /**
> > --
> > 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: [PATCH 2/5] omap: mailbox: correct OMAP4 reset logic
* Tony Lindgren [100222 12:11]:
> * Anna, Suman [100222 12:04]:
> > Hi Santosh,
> >
> > > -Original Message-
> > > From: Shilimkar, Santosh
> > > Sent: Saturday, February 20, 2010 12:53 PM
> > > To: Anna, Suman; linux-omap@vger.kernel.org
> > > Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, Subramaniam
> > > Subject: RE: [PATCH 2/5] omap: mailbox: correct OMAP4 reset logic
> > >
> > > > -Original Message-
> > > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > > ow...@vger.kernel.org] On Behalf Of Anna,
> > > > Suman
> > > > Sent: Friday, February 19, 2010 2:37 AM
> > > > To: linux-omap@vger.kernel.org
> > > > Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, Subramaniam
> > > > Subject: [PATCH 2/5] omap: mailbox: correct OMAP4 reset logic
> > > >
> > > > From 2488815a9facca29e2da3ddd279de441a5de6a58 Mon Sep 17 00:00:00 2001
> > > > From: Suman Anna
> > > > Date: Tue, 26 Jan 2010 16:55:29 -0600
> > > > Subject: [PATCH 2/5] omap: mailbox: correct OMAP4 reset logic
> > > >
> > > > OMAP4 mailbox has a different register set. There is
> > > > no MAILBOX_SYSSTATUS register. The reset is indicated
> > > > with the SOFTRESET bit of the MAILBOX_SYSCONFIG register
> > > > itself. This bit should read 0 for a successful Reset.
> > > > Also, the SOFTRESET bit occupies bit0 and not bit1 as with
> > > > previous generations.
> > > >
> > > > Signed-off-by: Suman Anna
> > > > ---
> > > > arch/arm/mach-omap2/mailbox.c | 38 +++---
> > >
> > > > 1 files changed, 27 insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-
> > > omap2/mailbox.c
> > > > index c970cf6..88e9043 100644
> > > > --- a/arch/arm/mach-omap2/mailbox.c
> > > > +++ b/arch/arm/mach-omap2/mailbox.c
> > > > @@ -40,6 +40,7 @@
> > > > #define AUTOIDLE (1 << 0)
> > > > #define SOFTRESET (1 << 1)
> > > > #define SMARTIDLE (2 << 3)
> > > > +#define OMAP4_SOFTRESET(1 << 0)
> > > >
> > > > /* SYSSTATUS: register bit definition */
> > > > #define RESETDONE (1 << 0)
> > > > @@ -99,17 +100,32 @@ static int omap2_mbox_startup(struct omap_mbox
> > > *mbox)
> > > > }
> > > > clk_enable(mbox_ick_handle);
> > > >
> > > > - mbox_write_reg(SOFTRESET, MAILBOX_SYSCONFIG);
> > > > - timeout = jiffies + msecs_to_jiffies(20);
> > > > - do {
> > > > - l = mbox_read_reg(MAILBOX_SYSSTATUS);
> > > > - if (l & RESETDONE)
> > > > - break;
> > > > - } while (!time_after(jiffies, timeout));
> > > > -
> > > > - if (!(l & RESETDONE)) {
> > > > - pr_err("Can't take mmu out of reset\n");
> > > > - return -ENODEV;
> > > > + if (cpu_is_omap44xx()) {
> > > Not so strong opinion but can we make use of mailbox ip revision instead
> > > of cpu_is_() check.
> > >
> >
> > This may be a better option in the longer-run, but the current mailbox
> > registers are assigned based on the cpu_is_() macro, and I have used
> > this readily available macro rather doing a new one. Also, note that the IP
> > revision value is not published in the TRM.
>
> In the long run the most flexible option is to check the revision
> for each device during init.
>
> Anyways, sounds like that's another patch on top of these patches.
As we probably won't have the hwmod patch done for this merge window,
I've added these except for the one to fix compile warning.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] omap updates for 2.6.34, part 4
* Shilimkar, Santosh [100220 00:27]: > Tony, > > > -Original Message- > > From: linux-omap-ow...@vger.kernel.org > > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony > > Lindgren > > Sent: Saturday, February 20, 2010 5:00 AM > > To: linux-arm-ker...@lists.infradead.org > > Cc: linux-omap@vger.kernel.org > > Subject: [PATCH 00/11] omap updates for 2.6.34, part 4 > > > > Hi all, > > > > Here are few USB platform init patches that have been already > > posted to linux-usb and linux-omap and have been sitting in for-next. > > > > Posting them one more time to make sure people on linux-arm-kernel > > have seen these too. > > > > Regards, > > > > Tony > > > > --- > > > > Felipe Balbi (7): > > arm: omap: musb: ioremap only what's ours > > omap: musb: remove unused data > > arm: omap: musb: we can use clk framework > > omap: musb: remove unused soft_con field > > omap: musb: remove unused dma data > > omap: musb: remove unnecessary return > > omap: musb: get rid of dyn_fifo > > > > Maulik Mankad (4): > > USB: Add empty functions in otg.h > > omap: musb: Remove #ifdef from board-omap3evm.c > > omap: musb: Pass board specific data from board file > > omap: musb: Add USB support to 4430 SDP board file > > > We need attached patch to keep multi-omap build booting on omap4 > on top of this series. Thanks, I'll add it. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning
* Anna, Suman [100222 11:53]:
> Hi Santosh,
>
> > -Original Message-
> > From: Shilimkar, Santosh
> > Sent: Saturday, February 20, 2010 12:47 PM
> > To: Anna, Suman; linux-omap@vger.kernel.org
> > Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, Subramaniam
> > Subject: RE: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning
> >
> > > -Original Message-
> > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > ow...@vger.kernel.org] On Behalf Of Anna,
> > > Suman
> > > Sent: Friday, February 19, 2010 2:37 AM
> > > To: linux-omap@vger.kernel.org
> > > Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, Subramaniam
> > > Subject: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning
> > >
> > > From 78d00b562548e1d95ad12a4d8121be67950daf68 Mon Sep 17 00:00:00 2001
> > > From: Suman Anna
> > > Date: Mon, 25 Jan 2010 18:27:21 -0600
> > > Subject: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning
> > >
> > > Remove a compiler warning in device-specific
> > > mailbox module.
> > >
> > > Signed-off-by: Suman Anna
> > > ---
> > > arch/arm/mach-omap2/mailbox.c |2 ++
> > > 1 files changed, 2 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-
> > omap2/mailbox.c
> > > index 2c9fd1c..c970cf6 100644
> > > --- a/arch/arm/mach-omap2/mailbox.c
> > > +++ b/arch/arm/mach-omap2/mailbox.c
> > > @@ -419,8 +419,10 @@ static int __devinit omap2_mbox_probe(struct
> > platform_device *pdev)
> > > #endif
> > > return 0;
> > >
> > > +#if defined(CONFIG_ARCH_OMAP2420) /* IVA */
> > > err_iva1:
> > > omap_mbox_unregister(&mbox_dsp_info);
> > > +#endif
> > Can't we avoid the #ifdef here? Is this "omap_mbox_unregister" omap2
> > specific?
>
> Yes, this #ifdef is specific to 2420. There are other places in the mailbox
> code which also utilize a similar #ifdef. I have merely added it to remove
> the compile warning. I think it needs a separate patch to remove all the 2420
> specific #ifdefs.
Let's drop this patch for now. We should fix this with something like
this in mailbox.h:
#ifdef CONFIG_ARCH_OMAP2420
int omap_mbox_unregister(struct omap_mbox *);
#else
static inline int omap_mbox_unregister(struct omap_mbox *mbox)
{
return 0;
}
#endif
That way we can get rid of the ifdefs in other places too.
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: Dereference of NULL autodep in _autodep_lookup()
Hi Roel,
On Sun, 14 Feb 2010, Roel Kluin wrote:
> Don't dereference autodep when it's NULL. In _autodep_lookup() an
> ERR_PTR(-ENOENT) is assigned to autodep->pwrdm.ptr if pwrdm_lookup() fails.
>
> Signed-off-by: Roel Kluin
Thanks for the patch, but I don't understand what problem you're
pointing out. If autodeps is NULL entering clkdm_init(), then the
for-loop won't even be entered.
It looks like there may be a problem, however, in _clkdm_add_autodeps()
and _clkdm_del_autodeps() if no autodeps were passed in. What do you
think about something like the following instead?
- Paul
From: Paul Walmsley
Date: Mon, 22 Feb 2010 14:01:45 -0700
Subject: [PATCH] OMAP clockdomain: if no autodeps exist, don't try to add or
remove them
_clkdm_add_autodeps() and _clkdm_del_autodeps() will attempt to dereference
a NULL pointer if no autodeps were supplied to clkdm_init().
Based on a patch from Roel Kluin - thanks Roel.
Signed-off-by: Paul Walmsley
Cc: Roel Kluin
---
arch/arm/mach-omap2/clockdomain.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c
b/arch/arm/mach-omap2/clockdomain.c
index de4278c..b26d30a 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -173,6 +173,9 @@ static void _clkdm_add_autodeps(struct clockdomain *clkdm)
{
struct clkdm_autodep *autodep;
+ if (!autodeps)
+ return;
+
for (autodep = autodeps; autodep->clkdm.ptr; autodep++) {
if (IS_ERR(autodep->clkdm.ptr))
continue;
@@ -201,6 +204,9 @@ static void _clkdm_del_autodeps(struct clockdomain *clkdm)
{
struct clkdm_autodep *autodep;
+ if (!autodeps)
+ return;
+
for (autodep = autodeps; autodep->clkdm.ptr; autodep++) {
if (IS_ERR(autodep->clkdm.ptr))
continue;
--
1.6.6.GIT
--
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: [PATCHv5] OMAP3: Serial: Improved sleep logic
* Tero Kristo [100217 06:01]:
> From: Tero Kristo
>
> This patch contains following improvements:
> - Only RX interrupt will now kick the sleep prevent timer
> - TX fifo status is checked before disabling clocks, this will prevent
> on-going transmission to be cut
> - Smartidle is now enabled/disabled only while switching clocks, as having
> smartidle enabled while RX/TX prevents any interrupts from being
> received from UART module
> - Sleep prevent timer is changed to use timespec instead of a jiffy timer
> as jiffy timers are not valid within idle loop (tick scheduler is stopped)
> - Added RX ignore timer for ignoring the first character received during
> first millisecond of wakeup, this prevents garbage character to be receive
> in low sleep states
>
> Signed-off-by: Tero Kristo
Kevin, do you have any comments on this?
Regards,
Tony
> ---
> arch/arm/mach-omap2/serial.c | 98 +
> 1 files changed, 69 insertions(+), 29 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index 5f3035e..f49c465 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -29,6 +29,8 @@
> #include
> #include
>
> +#include
> +
> #include "prm.h"
> #include "pm.h"
> #include "prm-regbits-34xx.h"
> @@ -42,13 +44,14 @@
> * disabled via sysfs. This also causes that any deeper omap sleep states are
> * blocked.
> */
> -#define DEFAULT_TIMEOUT 0
> +#define DEFAULT_TIMEOUT (0LL * NSEC_PER_SEC)
>
> struct omap_uart_state {
> int num;
> int can_sleep;
> - struct timer_list timer;
> - u32 timeout;
> + struct timespec expire_time;
> + struct timespec garbage_time;
> + u64 timeout;
>
> void __iomem *wk_st;
> void __iomem *wk_en;
> @@ -243,6 +246,9 @@ static inline void omap_uart_save_context(struct
> omap_uart_state *uart) {}
> static inline void omap_uart_restore_context(struct omap_uart_state *uart) {}
> #endif /* CONFIG_PM && CONFIG_ARCH_OMAP3 */
>
> +static void omap_uart_smart_idle_enable(struct omap_uart_state *uart,
> + int enable);
> +
> static inline void omap_uart_enable_clocks(struct omap_uart_state *uart)
> {
> if (uart->clocked)
> @@ -250,8 +256,13 @@ static inline void omap_uart_enable_clocks(struct
> omap_uart_state *uart)
>
> clk_enable(uart->ick);
> clk_enable(uart->fck);
> + omap_uart_smart_idle_enable(uart, 0);
> uart->clocked = 1;
> omap_uart_restore_context(uart);
> +
> + /* Set up garbage timer to ignore RX during first 1ms */
> + getrawmonotonic(&uart->garbage_time);
> + timespec_add_ns(&uart->garbage_time, NSEC_PER_MSEC);
> }
>
> #ifdef CONFIG_PM
> @@ -263,6 +274,7 @@ static inline void omap_uart_disable_clocks(struct
> omap_uart_state *uart)
>
> omap_uart_save_context(uart);
> uart->clocked = 0;
> + omap_uart_smart_idle_enable(uart, 1);
> clk_disable(uart->ick);
> clk_disable(uart->fck);
> }
> @@ -320,12 +332,11 @@ static void omap_uart_block_sleep(struct
> omap_uart_state *uart)
> {
> omap_uart_enable_clocks(uart);
>
> - omap_uart_smart_idle_enable(uart, 0);
> uart->can_sleep = 0;
> - if (uart->timeout)
> - mod_timer(&uart->timer, jiffies + uart->timeout);
> - else
> - del_timer(&uart->timer);
> + if (uart->timeout) {
> + getrawmonotonic(&uart->expire_time);
> + timespec_add_ns(&uart->expire_time, uart->timeout);
> + }
> }
>
> static void omap_uart_allow_sleep(struct omap_uart_state *uart)
> @@ -338,25 +349,24 @@ static void omap_uart_allow_sleep(struct
> omap_uart_state *uart)
> if (!uart->clocked)
> return;
>
> - omap_uart_smart_idle_enable(uart, 1);
> uart->can_sleep = 1;
> - del_timer(&uart->timer);
> -}
> -
> -static void omap_uart_idle_timer(unsigned long data)
> -{
> - struct omap_uart_state *uart = (struct omap_uart_state *)data;
> -
> - omap_uart_allow_sleep(uart);
> }
>
> void omap_uart_prepare_idle(int num)
> {
> struct omap_uart_state *uart;
> + struct timespec t;
>
> list_for_each_entry(uart, &uart_list, node) {
> + if (num == uart->num && !uart->can_sleep && uart->timeout) {
> + getrawmonotonic(&t);
> + if (timespec_compare(&t, &uart->expire_time) > 0)
> + uart->can_sleep = 1;
> + }
> if (num == uart->num && uart->can_sleep) {
> - omap_uart_disable_clocks(uart);
> + if (serial_read_reg(uart->p, UART_LSR) &
> + UART_LSR_TEMT)
> + omap_uart_disable_clocks(uart);
> return;
> }
> }
> @@ -381,6 +391,7 @@ void omap_uart_resume_idle(int num)
> /* Check for normal UART wakeup */
>
[PATCH] omap: i2c: Fix muxing for command line enabled bus
The commit b63128e81214cc2db2995d690438055c26d213a5 broke the pin muxing
for I2C busses that are enabled from the kernel command line.
Fix this by defining the board registration function omap_register_i2c_bus
in common platform code as it was before but keep the muxing in architecture
dependent files.
Signed-off-by: Jarkko Nikula
---
arch/arm/mach-omap1/i2c.c |6 +-
arch/arm/mach-omap2/i2c.c |6 +-
arch/arm/plat-omap/i2c.c | 10 --
arch/arm/plat-omap/include/plat/i2c.h |5 ++---
4 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap1/i2c.c b/arch/arm/mach-omap1/i2c.c
index 1bf4735..5446c99 100644
--- a/arch/arm/mach-omap1/i2c.c
+++ b/arch/arm/mach-omap1/i2c.c
@@ -23,9 +23,7 @@
#include
#include
-int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
- struct i2c_board_info const *info,
- unsigned len)
+void __init omap1_i2c_mux_pins(int bus_id)
{
if (cpu_is_omap7xx()) {
omap_cfg_reg(I2C_7XX_SDA);
@@ -34,6 +32,4 @@ int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
omap_cfg_reg(I2C_SDA);
omap_cfg_reg(I2C_SCL);
}
-
- return omap_plat_register_i2c_bus(bus_id, clkrate, info, len);
}
diff --git a/arch/arm/mach-omap2/i2c.c b/arch/arm/mach-omap2/i2c.c
index 789ca8c..7951ae1 100644
--- a/arch/arm/mach-omap2/i2c.c
+++ b/arch/arm/mach-omap2/i2c.c
@@ -25,9 +25,7 @@
#include "mux.h"
-int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
- struct i2c_board_info const *info,
- unsigned len)
+void __init omap2_i2c_mux_pins(int bus_id)
{
if (cpu_is_omap24xx()) {
const int omap24xx_pins[][2] = {
@@ -51,6 +49,4 @@ int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
sprintf(mux_name, "i2c%i_sda.i2c%i_sda", bus_id, bus_id);
omap_mux_init_signal(mux_name, OMAP_PIN_INPUT);
}
-
- return omap_plat_register_i2c_bus(bus_id, clkrate, info, len);
}
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index 96d2781..624e262 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#define OMAP_I2C_SIZE 0x3f
#define OMAP1_I2C_BASE 0xfffb3800
@@ -117,6 +118,11 @@ static int __init omap_i2c_add_bus(int bus_id)
res[1].start = irq;
}
+ if (cpu_class_is_omap1())
+ omap1_i2c_mux_pins(bus_id);
+ if (cpu_class_is_omap2())
+ omap2_i2c_mux_pins(bus_id);
+
return platform_device_register(pdev);
}
@@ -169,7 +175,7 @@ out:
subsys_initcall(omap_register_i2c_bus_cmdline);
/**
- * omap_plat_register_i2c_bus - register I2C bus with device descriptors
+ * omap_register_i2c_bus - register I2C bus with device descriptors
* @bus_id: bus id counting from number 1
* @clkrate: clock rate of the bus in kHz
* @info: pointer into I2C device descriptor table or NULL
@@ -177,7 +183,7 @@ subsys_initcall(omap_register_i2c_bus_cmdline);
*
* Returns 0 on success or an error code.
*/
-int __init omap_plat_register_i2c_bus(int bus_id, u32 clkrate,
+int __init omap_register_i2c_bus(int bus_id, u32 clkrate,
struct i2c_board_info const *info,
unsigned len)
{
diff --git a/arch/arm/plat-omap/include/plat/i2c.h
b/arch/arm/plat-omap/include/plat/i2c.h
index 585d9ca..87f6bf2 100644
--- a/arch/arm/plat-omap/include/plat/i2c.h
+++ b/arch/arm/plat-omap/include/plat/i2c.h
@@ -34,6 +34,5 @@ static inline int omap_register_i2c_bus(int bus_id, u32
clkrate,
}
#endif
-int omap_plat_register_i2c_bus(int bus_id, u32 clkrate,
-struct i2c_board_info const *info,
-unsigned len);
+void __init omap1_i2c_mux_pins(int bus_id);
+void __init omap2_i2c_mux_pins(int bus_id);
--
1.6.6.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/5] omap: mailbox: correct OMAP4 reset logic
* Anna, Suman [100222 12:04]:
> Hi Santosh,
>
> > -Original Message-
> > From: Shilimkar, Santosh
> > Sent: Saturday, February 20, 2010 12:53 PM
> > To: Anna, Suman; linux-omap@vger.kernel.org
> > Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, Subramaniam
> > Subject: RE: [PATCH 2/5] omap: mailbox: correct OMAP4 reset logic
> >
> > > -Original Message-
> > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > ow...@vger.kernel.org] On Behalf Of Anna,
> > > Suman
> > > Sent: Friday, February 19, 2010 2:37 AM
> > > To: linux-omap@vger.kernel.org
> > > Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, Subramaniam
> > > Subject: [PATCH 2/5] omap: mailbox: correct OMAP4 reset logic
> > >
> > > From 2488815a9facca29e2da3ddd279de441a5de6a58 Mon Sep 17 00:00:00 2001
> > > From: Suman Anna
> > > Date: Tue, 26 Jan 2010 16:55:29 -0600
> > > Subject: [PATCH 2/5] omap: mailbox: correct OMAP4 reset logic
> > >
> > > OMAP4 mailbox has a different register set. There is
> > > no MAILBOX_SYSSTATUS register. The reset is indicated
> > > with the SOFTRESET bit of the MAILBOX_SYSCONFIG register
> > > itself. This bit should read 0 for a successful Reset.
> > > Also, the SOFTRESET bit occupies bit0 and not bit1 as with
> > > previous generations.
> > >
> > > Signed-off-by: Suman Anna
> > > ---
> > > arch/arm/mach-omap2/mailbox.c | 38 +++---
> >
> > > 1 files changed, 27 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-
> > omap2/mailbox.c
> > > index c970cf6..88e9043 100644
> > > --- a/arch/arm/mach-omap2/mailbox.c
> > > +++ b/arch/arm/mach-omap2/mailbox.c
> > > @@ -40,6 +40,7 @@
> > > #define AUTOIDLE (1 << 0)
> > > #define SOFTRESET(1 << 1)
> > > #define SMARTIDLE(2 << 3)
> > > +#define OMAP4_SOFTRESET (1 << 0)
> > >
> > > /* SYSSTATUS: register bit definition */
> > > #define RESETDONE(1 << 0)
> > > @@ -99,17 +100,32 @@ static int omap2_mbox_startup(struct omap_mbox
> > *mbox)
> > > }
> > > clk_enable(mbox_ick_handle);
> > >
> > > - mbox_write_reg(SOFTRESET, MAILBOX_SYSCONFIG);
> > > - timeout = jiffies + msecs_to_jiffies(20);
> > > - do {
> > > - l = mbox_read_reg(MAILBOX_SYSSTATUS);
> > > - if (l & RESETDONE)
> > > - break;
> > > - } while (!time_after(jiffies, timeout));
> > > -
> > > - if (!(l & RESETDONE)) {
> > > - pr_err("Can't take mmu out of reset\n");
> > > - return -ENODEV;
> > > + if (cpu_is_omap44xx()) {
> > Not so strong opinion but can we make use of mailbox ip revision instead
> > of cpu_is_() check.
> >
>
> This may be a better option in the longer-run, but the current mailbox
> registers are assigned based on the cpu_is_() macro, and I have used this
> readily available macro rather doing a new one. Also, note that the IP
> revision value is not published in the TRM.
In the long run the most flexible option is to check the revision
for each device during init.
Anyways, sounds like that's another patch on top of these patches.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/5] omap: mailbox: correct OMAP4 reset logic
Hi Benoit, > -Original Message- > From: Cousson, Benoit > Sent: Sunday, February 21, 2010 7:36 AM > To: Shilimkar, Santosh; Anna, Suman; linux-omap@vger.kernel.org > Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, Subramaniam > Subject: RE: [PATCH 2/5] omap: mailbox: correct OMAP4 reset logic > > Hi Suman, > > > > Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve > Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 > > -Original Message- > > >From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > >ow...@vger.kernel.org] On Behalf Of Shilimkar, Santosh > >Sent: Saturday, February 20, 2010 7:53 PM > >To: Anna, Suman; linux-omap@vger.kernel.org > >Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, Subramaniam > >Subject: RE: [PATCH 2/5] omap: mailbox: correct OMAP4 reset logic > > > >> -Original Message- > >> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > >ow...@vger.kernel.org] On Behalf Of Anna, > >> Suman > >> Sent: Friday, February 19, 2010 2:37 AM > >> To: linux-omap@vger.kernel.org > >> Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, > Subramaniam > >> Subject: [PATCH 2/5] omap: mailbox: correct OMAP4 reset logic > >> > >> From 2488815a9facca29e2da3ddd279de441a5de6a58 Mon Sep 17 00:00:00 2001 > >> From: Suman Anna > >> Date: Tue, 26 Jan 2010 16:55:29 -0600 > >> Subject: [PATCH 2/5] omap: mailbox: correct OMAP4 reset logic > >> > >> OMAP4 mailbox has a different register set. There is > >> no MAILBOX_SYSSTATUS register. The reset is indicated > >> with the SOFTRESET bit of the MAILBOX_SYSCONFIG register > >> itself. This bit should read 0 for a successful Reset. > >> Also, the SOFTRESET bit occupies bit0 and not bit1 as with > >> previous generations. > > This is due to the new standard defined for OMAP4 IPs and well explain by > Thara in a recently posted patch to handle that smoothly using hwmod. > [PATCH V4] OMAP3: hwmod: support to specify the offset position of various > SYSCONFIG register bits. > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg23509.html > > Is there a reason to not convert the mailbox driver to use hwmod? > It will avoid you to handle that in the mailbox driver code, whereas the > hwmod framework is already taking care of that. > > Regards, > Benoit > Thanks for the reference. Mailbox driver is yet to migrate to use the new hwmod. It is still based on the old framework. Regards Suman -- 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/5] omap: mailbox: correct OMAP4 reset logic
Hi Santosh,
> -Original Message-
> From: Shilimkar, Santosh
> Sent: Saturday, February 20, 2010 12:53 PM
> To: Anna, Suman; linux-omap@vger.kernel.org
> Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, Subramaniam
> Subject: RE: [PATCH 2/5] omap: mailbox: correct OMAP4 reset logic
>
> > -Original Message-
> > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Anna,
> > Suman
> > Sent: Friday, February 19, 2010 2:37 AM
> > To: linux-omap@vger.kernel.org
> > Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, Subramaniam
> > Subject: [PATCH 2/5] omap: mailbox: correct OMAP4 reset logic
> >
> > From 2488815a9facca29e2da3ddd279de441a5de6a58 Mon Sep 17 00:00:00 2001
> > From: Suman Anna
> > Date: Tue, 26 Jan 2010 16:55:29 -0600
> > Subject: [PATCH 2/5] omap: mailbox: correct OMAP4 reset logic
> >
> > OMAP4 mailbox has a different register set. There is
> > no MAILBOX_SYSSTATUS register. The reset is indicated
> > with the SOFTRESET bit of the MAILBOX_SYSCONFIG register
> > itself. This bit should read 0 for a successful Reset.
> > Also, the SOFTRESET bit occupies bit0 and not bit1 as with
> > previous generations.
> >
> > Signed-off-by: Suman Anna
> > ---
> > arch/arm/mach-omap2/mailbox.c | 38 +++---
>
> > 1 files changed, 27 insertions(+), 11 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-
> omap2/mailbox.c
> > index c970cf6..88e9043 100644
> > --- a/arch/arm/mach-omap2/mailbox.c
> > +++ b/arch/arm/mach-omap2/mailbox.c
> > @@ -40,6 +40,7 @@
> > #define AUTOIDLE (1 << 0)
> > #define SOFTRESET (1 << 1)
> > #define SMARTIDLE (2 << 3)
> > +#define OMAP4_SOFTRESET(1 << 0)
> >
> > /* SYSSTATUS: register bit definition */
> > #define RESETDONE (1 << 0)
> > @@ -99,17 +100,32 @@ static int omap2_mbox_startup(struct omap_mbox
> *mbox)
> > }
> > clk_enable(mbox_ick_handle);
> >
> > - mbox_write_reg(SOFTRESET, MAILBOX_SYSCONFIG);
> > - timeout = jiffies + msecs_to_jiffies(20);
> > - do {
> > - l = mbox_read_reg(MAILBOX_SYSSTATUS);
> > - if (l & RESETDONE)
> > - break;
> > - } while (!time_after(jiffies, timeout));
> > -
> > - if (!(l & RESETDONE)) {
> > - pr_err("Can't take mmu out of reset\n");
> > - return -ENODEV;
> > + if (cpu_is_omap44xx()) {
> Not so strong opinion but can we make use of mailbox ip revision instead
> of cpu_is_() check.
>
This may be a better option in the longer-run, but the current mailbox
registers are assigned based on the cpu_is_() macro, and I have used this
readily available macro rather doing a new one. Also, note that the IP revision
value is not published in the TRM.
Regards
Suman
--
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/5] omap2/3/4: mailbox: remove compiler warning
Hi Santosh, > -Original Message- > From: Shilimkar, Santosh > Sent: Saturday, February 20, 2010 12:47 PM > To: Anna, Suman; linux-omap@vger.kernel.org > Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, Subramaniam > Subject: RE: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning > > > -Original Message- > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Anna, > > Suman > > Sent: Friday, February 19, 2010 2:37 AM > > To: linux-omap@vger.kernel.org > > Cc: hiroshi.d...@nokia.com; Clark, Rob; Kanigeri, Hari; C.A, Subramaniam > > Subject: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning > > > > From 78d00b562548e1d95ad12a4d8121be67950daf68 Mon Sep 17 00:00:00 2001 > > From: Suman Anna > > Date: Mon, 25 Jan 2010 18:27:21 -0600 > > Subject: [PATCH 1/5] omap2/3/4: mailbox: remove compiler warning > > > > Remove a compiler warning in device-specific > > mailbox module. > > > > Signed-off-by: Suman Anna > > --- > > arch/arm/mach-omap2/mailbox.c |2 ++ > > 1 files changed, 2 insertions(+), 0 deletions(-) > > > > diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach- > omap2/mailbox.c > > index 2c9fd1c..c970cf6 100644 > > --- a/arch/arm/mach-omap2/mailbox.c > > +++ b/arch/arm/mach-omap2/mailbox.c > > @@ -419,8 +419,10 @@ static int __devinit omap2_mbox_probe(struct > platform_device *pdev) > > #endif > > return 0; > > > > +#if defined(CONFIG_ARCH_OMAP2420) /* IVA */ > > err_iva1: > > omap_mbox_unregister(&mbox_dsp_info); > > +#endif > Can't we avoid the #ifdef here? Is this "omap_mbox_unregister" omap2 > specific? Yes, this #ifdef is specific to 2420. There are other places in the mailbox code which also utilize a similar #ifdef. I have merely added it to remove the compile warning. I think it needs a separate patch to remove all the 2420 specific #ifdefs. > > Regards, > Santosh Regards Suman -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] backlight: mark struct backlight_ops const
On Sat, Feb 20, 2010 at 18:18, Bruno Prémont wrote: > drivers/video/bf54x-lq043fb.c | 2 +- > drivers/video/bfin-t350mcqb-fb.c | 2 +- Acked-by: Mike Frysinger -mike
Re: [PATCHv5 0/2] McBSP: OMAP3: Add sidetone feature
On Mon, 22 Feb 2010 10:35:26 -0800 Tony Lindgren wrote: > > Both patches > > > > Acked-by: Mark Brown > > > > too. > > OK, I'll add them into omap for-next. > No need to re-commit if you have done it already, but here's my ack too just in case :-) Acked-by: Jarkko Nikula or Tested-by: Jarkko Nikula -- 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: [PATCHv5 0/2] McBSP: OMAP3: Add sidetone feature
* Mark Brown [100222 06:36]: > On Mon, Feb 22, 2010 at 02:21:10PM +0200, Ilkka Koskinen wrote: > > The first patch implements McBSP sidetone feature on OMAP3 while the second > > one provides ALSA interface for using it. > > > > The patch set is based on the patch Eduardo Valentin sent to alsa-devel > > mailing list in October 2009. Channel gain control and enabling the sidetone > > have been moved to ALSA interface as suggested in comments. > > > > These patches apply on top of Janusz Krzysztofik's McBSP register cache > > patches in linux-omap-2.6.git > > Both patches > > Acked-by: Mark Brown > > too. OK, I'll add them into omap for-next. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] MFD: TWL4030: introduce remove_script function
From: Mike Turquette
New function twl4030_remove_script(u8 flags) takes a script type as
defined in twl.h and prevents any script already loaded in that position
from running. This is accomplished by programming SEQ_ADD_* to 0x3f,
the END_OF_SCRIPT value, where SEQ_ADD_* is determined by flags.
Signed-off-by: Mike Turquette
---
Based on MFD for-next branch.
Future users of this function include OMAP board files for machines
facing a race condition between sleep and warm reset.
drivers/mfd/twl4030-power.c | 50 +++
include/linux/i2c/twl.h |1 +
2 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 5b045ff..7efa878 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -461,6 +461,56 @@ out:
return err;
}
+int twl4030_remove_script(u8 flags)
+{
+ int err = 0;
+
+ err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, R_KEY_1,
+ R_PROTECT_KEY);
+ if (err) {
+ pr_err("twl4030: unable to unlock PROTECT_KEY\n");
+ return err;
+ }
+
+ err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, R_KEY_2,
+ R_PROTECT_KEY);
+ if (err) {
+ pr_err("twl4030: unable to unlock PROTECT_KEY\n");
+ return err;
+ }
+
+ if (flags & TWL4030_WRST_SCRIPT) {
+ err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, END_OF_SCRIPT,
+ R_SEQ_ADD_WARM);
+ if (err)
+ return err;
+ }
+ if (flags & TWL4030_WAKEUP12_SCRIPT) {
+ if (err)
+ err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, END_OF_SCRIPT,
+ R_SEQ_ADD_S2A12);
+ return err;
+ }
+ if (flags & TWL4030_WAKEUP3_SCRIPT) {
+ err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, END_OF_SCRIPT,
+ R_SEQ_ADD_S2A3);
+ if (err)
+ return err;
+ }
+ if (flags & TWL4030_SLEEP_SCRIPT) {
+ err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, END_OF_SCRIPT,
+ R_SEQ_ADD_A2S);
+ if (err)
+ return err;
+ }
+
+ err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, 0, R_PROTECT_KEY);
+ if (err)
+ pr_err("TWL4030 Unable to relock registers\n");
+
+ return err;
+}
+
void __init twl4030_power_init(struct twl4030_power_data *twl4030_scripts)
{
int err = 0;
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 33d9d5c..d4baff8 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -550,6 +550,7 @@ struct twl4030_power_data {
};
extern void twl4030_power_init(struct twl4030_power_data *triton2_scripts);
+extern int twl4030_remove_script(u8 flags);
struct twl4030_codec_audio_data {
unsigned intaudio_mclk;
--
1.6.3.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 0/2] mmc: omap_hsmmc: support SDIO cards (#2)
On Mon, Feb 22, 2010 at 5:11 PM, David Vrabel wrote: > Felipe Contreras wrote: >> On Mon, Feb 22, 2010 at 4:24 PM, 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. >> >> Can't you get the source code with 'apt-get source' in Maemo SDK? It's >> a tarball but at least it's something. > > I have SDIO cards tested and working on the N900 with the Fremantle > kernel but that's a modified 2.6.28 kernel. These patches are for > mainline and there are differences between mainline and the fremantle > kernel that means they need different patches. Ah, got it. I was wondering how exactly did you test the patches. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)
Felipe Contreras wrote: > On Mon, Feb 22, 2010 at 4:24 PM, 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. > > Can't you get the source code with 'apt-get source' in Maemo SDK? It's > a tarball but at least it's something. I have SDIO cards tested and working on the N900 with the Fremantle kernel but that's a modified 2.6.28 kernel. These patches are for mainline and there are differences between mainline and the fremantle kernel that means they need different patches. David -- David Vrabel, Senior Software Engineer, Drivers CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562 Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/ Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)
On Mon, Feb 22, 2010 at 4:24 PM, 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. Can't you get the source code with 'apt-get source' in Maemo SDK? It's a tarball but at least it's something. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCHv5 0/2] McBSP: OMAP3: Add sidetone feature
On Mon, 2010-02-22 at 16:18 +0200, Peter Ujfalusi wrote: > On Monday 22 February 2010 14:21:10 Koskinen Ilkka (Nokia-D/Tampere) wrote: > > The first patch implements McBSP sidetone feature on OMAP3 while the second > > one provides ALSA interface for using it. > > > > The patch set is based on the patch Eduardo Valentin sent to alsa-devel > > mailing list in October 2009. Channel gain control and enabling the > > sidetone have been moved to ALSA interface as suggested in comments. > > > > These patches apply on top of Janusz Krzysztofik's McBSP register cache > > patches in linux-omap-2.6.git > > > > Since the version 4, ASoC part has been modified to deal with McBSP ids > > consistently (zero based indexing). > > > > Eero Nurkkala (1): > > McBSP: OMAP3: Add sidetone feature > > > > Ilkka Koskinen (1): > > ASoC: OMAP-McBSP: ASoC interface for McBSP sidetone > > > > arch/arm/mach-omap2/mcbsp.c |2 + > > arch/arm/plat-omap/include/plat/mcbsp.h | 60 + > > arch/arm/plat-omap/mcbsp.c | 402 > > ++- sound/soc/omap/omap-mcbsp.c | > > 138 +++ > > sound/soc/omap/omap-mcbsp.h |2 + > > 5 files changed, 603 insertions(+), 1 deletions(-) > > Both looks OK for me: > > Acked-by: Peter Ujfalusi Acked-by: Liam Girdwood -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk -- 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: [PATCHv5 0/2] McBSP: OMAP3: Add sidetone feature
On Mon, Feb 22, 2010 at 02:21:10PM +0200, Ilkka Koskinen wrote: > The first patch implements McBSP sidetone feature on OMAP3 while the second > one provides ALSA interface for using it. > > The patch set is based on the patch Eduardo Valentin sent to alsa-devel > mailing list in October 2009. Channel gain control and enabling the sidetone > have been moved to ALSA interface as suggested in comments. > > These patches apply on top of Janusz Krzysztofik's McBSP register cache > patches in linux-omap-2.6.git Both patches Acked-by: Mark Brown too. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
Madhusudhan wrote: > > A little bit of rearranging the David's changes to the irq handler gets the > MMC/SD cards to work fine again. Changes are shown in the attached patch for > now and it should not hurt the CIRQ handling as well. This breaks detecting card interrupts unless a command is in progress. >>> + status = OMAP_HSMMC_READ(host->base, STAT); >>> + OMAP_HSMMC_WRITE(host->base, STAT, status); >>> + OMAP_HSMMC_READ(host->base, STAT); /* Flush posted write. */ >>> + >>> + if (status & CIRQ) >>> + card_irq = true; >>> + >>> + if (host->mrq == NULL) >>> + goto out; >>> >>> data = host->data; >>> status = OMAP_HSMMC_READ(host->base, STAT); This line is the real problem. We re-read MMCi_STAT after acknowledging (clearing) it. Please see the version #2 of the patchset. David -- David Vrabel, Senior Software Engineer, Drivers CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562 Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/ Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom -- 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] mmc: omap_hsmmc: enable SDIO card interrupts
Enable the use of SDIO card interrupts.
FCLK must be enabled while SDIO interrupts are enabled or the MMC
module won't wake-up (even though ENAWAKEUP in SYSCONFIG and IWE in
HTCL have been set). Enabling the MMC module to wake-up would require
configuring the MMC module (and the mmci_dat[1] GPIO when the CORE
power domain is OFF) as wake-up sources in the PRCM.
The writes to STAT and ISE when starting a command are unnecessary and
have been removed.
Signed-off-by: David Vrabel
---
drivers/mmc/host/omap_hsmmc.c | 102
1 files changed, 71 insertions(+), 31 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 323a0e8..278b551 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -64,6 +64,7 @@
#define SDVS_MASK 0x0E00
#define SDVSCLR0xF1FF
#define SDVSDET0x0400
+#define ENAWAKEUP (1 << 2)
#define AUTOIDLE 0x1
#define SDBP (1 << 8)
#define DTO0xe
@@ -74,9 +75,11 @@
#define CLKD_SHIFT 6
#define DTO_MASK 0x000F
#define DTO_SHIFT 16
+#define CIRQ_ENABLE(1 << 8)
#define INT_EN_MASK0x307F0033
#define BWR_ENABLE (1 << 4)
#define BRR_ENABLE (1 << 5)
+#define CTPL (1 << 11)
#define INIT_STREAM(1 << 1)
#define DP_SELECT (1 << 21)
#define DDIR (1 << 4)
@@ -84,10 +87,12 @@
#define MSBS (1 << 5)
#define BCE(1 << 1)
#define FOUR_BIT (1 << 1)
+#define IWE(1 << 24)
#define DW8(1 << 5)
#define CC 0x1
#define TC 0x02
#define OD 0x1
+#define CIRQ (1 << 8)
#define ERR(1 << 15)
#define CMD_TIMEOUT(1 << 16)
#define DATA_TIMEOUT (1 << 20)
@@ -227,7 +232,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
;
OMAP_HSMMC_WRITE(host->base, SYSCONFIG,
- OMAP_HSMMC_READ(host->base, SYSCONFIG) | AUTOIDLE);
+ OMAP_HSMMC_READ(host->base, SYSCONFIG) | AUTOIDLE |
ENAWAKEUP);
if (host->id == OMAP_MMC1_DEVID) {
if (host->power_mode != MMC_POWER_OFF &&
@@ -242,7 +247,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
}
OMAP_HSMMC_WRITE(host->base, HCTL,
- OMAP_HSMMC_READ(host->base, HCTL) | hctl);
+ OMAP_HSMMC_READ(host->base, HCTL) | hctl | IWE);
OMAP_HSMMC_WRITE(host->base, CAPA,
OMAP_HSMMC_READ(host->base, CAPA) | capa);
@@ -256,7 +261,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
;
OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
- OMAP_HSMMC_WRITE(host->base, ISE, INT_EN_MASK);
+ OMAP_HSMMC_WRITE(host->base, ISE, INT_EN_MASK | CIRQ);
OMAP_HSMMC_WRITE(host->base, IE, INT_EN_MASK);
/* Do not initialize card-specific things if the power is off */
@@ -425,12 +430,6 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host,
struct mmc_command *cmd,
mmc_hostname(host->mmc), cmd->opcode, cmd->arg);
host->cmd = cmd;
- /*
-* Clear status bits and enable interrupts
-*/
- OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
- OMAP_HSMMC_WRITE(host->base, ISE, INT_EN_MASK);
-
if (host->use_dma)
OMAP_HSMMC_WRITE(host->base, IE,
INT_EN_MASK & ~(BRR_ENABLE | BWR_ENABLE));
@@ -637,23 +636,26 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
{
struct omap_hsmmc_host *host = dev_id;
struct mmc_data *data;
- int end_cmd = 0, end_trans = 0, status;
+ u32 status;
+ int end_cmd = 0, end_trans = 0;
+ bool card_irq = false;
spin_lock(&host->irq_lock);
- if (host->mrq == NULL) {
- OMAP_HSMMC_WRITE(host->base, STAT,
- OMAP_HSMMC_READ(host->base, STAT));
- /* Flush posted write */
- OMAP_HSMMC_READ(host->base, STAT);
- spin_unlock(&host->irq_lock);
- return IRQ_HANDLED;
- }
-
- data = host->data;
status = OMAP_HSMMC_READ(host->base, STAT);
+ OMAP_HSMMC_WRITE(host->base, STAT, status);
+ OMAP_HSMMC_READ(host->base, STAT); /* Flush posted write. */
+
dev_dbg(mmc_dev(host->mmc), "IRQ Status is %x\n", status);
+ if (status & CIRQ)
+ card_irq = true;
+
+ if (host->mrq == NULL)
+ goto out;
+
+ data = host->data;
+
if (status & ERR) {
#ifdef CONFIG_MMC_DEBUG
[PATCH 1/2] mmc: omap_hsmmc: don't turn SDIO cards off when idle
Don't turn SDIO cards off to save power. Doing so will lose all
internal state in the card.
Signed-off-by: David Vrabel
---
drivers/mmc/host/omap_hsmmc.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4b23225..323a0e8 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1366,8 +1367,12 @@ static int omap_hsmmc_sleep_to_off(struct
omap_hsmmc_host *host)
mmc_slot(host).card_detect ||
(mmc_slot(host).get_cover_state &&
mmc_slot(host).get_cover_state(host->dev, host->slot_id {
- mmc_release_host(host->mmc);
- return 0;
+ goto out;
+ }
+
+ /* Don't turn SDIO cards off. */
+ if (host->mmc->card && mmc_card_sdio(host->mmc->card)) {
+ goto out;
}
mmc_slot(host).set_power(host->dev, host->slot_id, 0, 0);
@@ -1378,9 +1383,8 @@ static int omap_hsmmc_sleep_to_off(struct omap_hsmmc_host
*host)
host->dpm_state == CARDSLEEP ? "CARDSLEEP" : "REGSLEEP");
host->dpm_state = OFF;
-
+out:
mmc_release_host(host->mmc);
-
return 0;
}
--
1.6.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)
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 drivers/mmc/host/omap_hsmmc.c | 114 - 1 files changed, 79 insertions(+), 35 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
Re: [PATCHv5 0/2] McBSP: OMAP3: Add sidetone feature
On Monday 22 February 2010 14:21:10 Koskinen Ilkka (Nokia-D/Tampere) wrote: > The first patch implements McBSP sidetone feature on OMAP3 while the second > one provides ALSA interface for using it. > > The patch set is based on the patch Eduardo Valentin sent to alsa-devel > mailing list in October 2009. Channel gain control and enabling the > sidetone have been moved to ALSA interface as suggested in comments. > > These patches apply on top of Janusz Krzysztofik's McBSP register cache > patches in linux-omap-2.6.git > > Since the version 4, ASoC part has been modified to deal with McBSP ids > consistently (zero based indexing). > > Eero Nurkkala (1): > McBSP: OMAP3: Add sidetone feature > > Ilkka Koskinen (1): > ASoC: OMAP-McBSP: ASoC interface for McBSP sidetone > > arch/arm/mach-omap2/mcbsp.c |2 + > arch/arm/plat-omap/include/plat/mcbsp.h | 60 + > arch/arm/plat-omap/mcbsp.c | 402 > ++- sound/soc/omap/omap-mcbsp.c | > 138 +++ > sound/soc/omap/omap-mcbsp.h |2 + > 5 files changed, 603 insertions(+), 1 deletions(-) Both looks OK for me: Acked-by: Peter Ujfalusi -- 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
pin muxing
Hello, I need to add a couple of mux entries and am refer to arch/arm/mach-omap2/mux.c file. I would like to what is the differences between BALLNUM_34XX_ and BALLNUM_3430_ entries. I could not find any mux entries specific to BALLNUM_35XX_. How does one decide if a pin needs to be pulled up or pulldown. Warm Regards, Ryan -- 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
[PATCHv5 0/2] McBSP: OMAP3: Add sidetone feature
The first patch implements McBSP sidetone feature on OMAP3 while the second one provides ALSA interface for using it. The patch set is based on the patch Eduardo Valentin sent to alsa-devel mailing list in October 2009. Channel gain control and enabling the sidetone have been moved to ALSA interface as suggested in comments. These patches apply on top of Janusz Krzysztofik's McBSP register cache patches in linux-omap-2.6.git Since the version 4, ASoC part has been modified to deal with McBSP ids consistently (zero based indexing). Eero Nurkkala (1): McBSP: OMAP3: Add sidetone feature Ilkka Koskinen (1): ASoC: OMAP-McBSP: ASoC interface for McBSP sidetone arch/arm/mach-omap2/mcbsp.c |2 + arch/arm/plat-omap/include/plat/mcbsp.h | 60 + arch/arm/plat-omap/mcbsp.c | 402 ++- sound/soc/omap/omap-mcbsp.c | 138 +++ sound/soc/omap/omap-mcbsp.h |2 + 5 files changed, 603 insertions(+), 1 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
[PATCHv5 1/2] McBSP: OMAP3: Add sidetone feature
From: Eero Nurkkala
Add sidetone feature to McBSP instances 2 and 3 on OMAP3 based devices.
Signed-off-by: Ilkka Koskinen
---
arch/arm/mach-omap2/mcbsp.c |2 +
arch/arm/plat-omap/include/plat/mcbsp.h | 60 +
arch/arm/plat-omap/mcbsp.c | 402 ++-
3 files changed, 463 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index d601f94..be8fce3 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -136,6 +136,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
},
{
.phys_base = OMAP34XX_MCBSP2_BASE,
+ .phys_base_st = OMAP34XX_MCBSP2_ST_BASE,
.dma_rx_sync= OMAP24XX_DMA_MCBSP2_RX,
.dma_tx_sync= OMAP24XX_DMA_MCBSP2_TX,
.rx_irq = INT_24XX_MCBSP2_IRQ_RX,
@@ -145,6 +146,7 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
},
{
.phys_base = OMAP34XX_MCBSP3_BASE,
+ .phys_base_st = OMAP34XX_MCBSP3_ST_BASE,
.dma_rx_sync= OMAP24XX_DMA_MCBSP3_RX,
.dma_tx_sync= OMAP24XX_DMA_MCBSP3_TX,
.rx_irq = INT_24XX_MCBSP3_IRQ_RX,
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h
b/arch/arm/plat-omap/include/plat/mcbsp.h
index 4df957b..3974835 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -49,6 +49,9 @@
#define OMAP34XX_MCBSP1_BASE 0x48074000
#define OMAP34XX_MCBSP2_BASE 0x49022000
+#define OMAP34XX_MCBSP2_ST_BASE0x49028000
+#define OMAP34XX_MCBSP3_BASE 0x49024000
+#define OMAP34XX_MCBSP3_ST_BASE0x4902A000
#define OMAP34XX_MCBSP3_BASE 0x49024000
#define OMAP34XX_MCBSP4_BASE 0x49026000
#define OMAP34XX_MCBSP5_BASE 0x48096000
@@ -146,6 +149,15 @@
#define OMAP_MCBSP_REG_WAKEUPEN0xA8
#define OMAP_MCBSP_REG_XCCR0xAC
#define OMAP_MCBSP_REG_RCCR0xB0
+#define OMAP_MCBSP_REG_SSELCR 0xBC
+
+#define OMAP_ST_REG_REV0x00
+#define OMAP_ST_REG_SYSCONFIG 0x10
+#define OMAP_ST_REG_IRQSTATUS 0x18
+#define OMAP_ST_REG_IRQENABLE 0x1C
+#define OMAP_ST_REG_SGAINCR0x24
+#define OMAP_ST_REG_SFIRCR 0x28
+#define OMAP_ST_REG_SSELCR 0x2C
#define AUDIO_MCBSP_DATAWRITE (OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DXR1)
#define AUDIO_MCBSP_DATAREAD (OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR1)
@@ -264,6 +276,24 @@
#define ENAWAKEUP 0x0004
#define SOFTRST0x0002
+/** McBSP SSELCR bit definitions ***/
+#define SIDETONEEN 0x0400
+
+/** McBSP Sidetone SYSCONFIG bit definitions ***/
+#define ST_AUTOIDLE0x0001
+
+/** McBSP Sidetone SGAINCR bit definitions */
+#define ST_CH1GAIN(value) ((value<<16)) /* Bits 16:31 */
+#define ST_CH0GAIN(value) (value) /* Bits 0:15 */
+
+/** McBSP Sidetone SFIRCR bit definitions **/
+#define ST_FIRCOEFF(value) (value) /* Bits 0:15 */
+
+/** McBSP Sidetone SSELCR bit definitions **/
+#define ST_COEFFWRDONE 0x0004
+#define ST_COEFFWREN 0x0002
+#define ST_SIDETONEEN 0x0001
+
/** McBSP DMA operating modes **/
#define MCBSP_DMA_MODE_ELEMENT 0
#define MCBSP_DMA_MODE_THRESHOLD 1
@@ -374,10 +404,22 @@ struct omap_mcbsp_platform_data {
u16 rx_irq, tx_irq;
struct omap_mcbsp_ops *ops;
#ifdef CONFIG_ARCH_OMAP3
+ /* Sidetone block for McBSP 2 and 3 */
+ unsigned long phys_base_st;
u16 buffer_size;
#endif
};
+struct omap_mcbsp_st_data {
+ void __iomem *io_base_st;
+ bool running;
+ bool enabled;
+ s16 taps[128]; /* Sidetone filter coefficients */
+ int nr_taps;/* Number of filter coefficients in use */
+ s16 ch0gain;
+ s16 ch1gain;
+};
+
struct omap_mcbsp {
struct device *dev;
unsigned long phys_base;
@@ -410,6 +452,7 @@ struct omap_mcbsp {
struct clk *iclk;
struct clk *fclk;
#ifdef CONFIG_ARCH_OMAP3
+ struct omap_mcbsp_st_data *st_data;
int dma_op_mode;
u16 max_tx_thres;
u16 max_rx_thres;
@@ -459,4 +502,21 @@ int omap_mcbsp_pollread(unsigned int id, u16 * buf);
int omap_mcbsp_pollwrite(unsigned int id, u16 buf);
int omap_mcbsp_set_io_type(unsigned int id, omap_mcbsp_io_type_t io_type);
+#ifdef CONFIG_ARCH_OMAP3
+/* Sidetone specific API */
+int omap_st_set_chgain(unsigned int id, int channel, s16 chgain);
+int omap_st_get_chgain(unsigned int id, int channel, s16 *chgain);
+int omap_st_enable(unsigned int id);
+int omap_st_disable(unsigned int id);
+int omap_st_is_enabled(unsigned int id);
+#else
+static inlin
[PATCHv5 2/2] ASoC: OMAP-McBSP: ASoC interface for McBSP sidetone
Add ASoC interface for OMAP McBSP2 and McBSP3 sidetones.
Signed-off-by: Ilkka Koskinen
---
sound/soc/omap/omap-mcbsp.c | 138 +++
sound/soc/omap/omap-mcbsp.h |2 +
2 files changed, 140 insertions(+), 0 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index c0039b3..8da14f5 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -39,6 +39,14 @@
#define OMAP_MCBSP_RATES (SNDRV_PCM_RATE_8000_96000)
+#define OMAP_MCBSP_SOC_SINGLE_S16_EXT(xname, xmin, xmax, \
+ xhandler_get, xhandler_put) \
+{ .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = xname, \
+ .info = omap_mcbsp_st_info_volsw, \
+ .get = xhandler_get, .put = xhandler_put, \
+ .private_value = (unsigned long) &(struct soc_mixer_control) \
+ {.min = xmin, .max = xmax} }
+
struct omap_mcbsp_data {
unsigned intbus_id;
struct omap_mcbsp_reg_cfg regs;
@@ -637,6 +645,136 @@ struct snd_soc_dai omap_mcbsp_dai[] = {
EXPORT_SYMBOL_GPL(omap_mcbsp_dai);
+int omap_mcbsp_st_info_volsw(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_info *uinfo)
+{
+ struct soc_mixer_control *mc =
+ (struct soc_mixer_control *)kcontrol->private_value;
+ int max = mc->max;
+ int min = mc->min;
+
+ uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER;
+ uinfo->count = 1;
+ uinfo->value.integer.min = min;
+ uinfo->value.integer.max = max;
+ return 0;
+}
+
+#define OMAP_MCBSP_ST_SET_CHANNEL_VOLUME(id, channel) \
+static int \
+omap_mcbsp##id##_set_st_ch##channel##_volume(struct snd_kcontrol *kc, \
+ struct snd_ctl_elem_value *uc) \
+{ \
+ struct soc_mixer_control *mc = \
+ (struct soc_mixer_control *)kc->private_value; \
+ int max = mc->max; \
+ int min = mc->min; \
+ int val = uc->value.integer.value[0]; \
+ \
+ if (val < min || val > max) \
+ return -EINVAL; \
+ \
+ /* OMAP McBSP implementation uses index values 0..4 */ \
+ return omap_st_set_chgain((id)-1, channel, val);\
+}
+
+#define OMAP_MCBSP_ST_GET_CHANNEL_VOLUME(id, channel) \
+static int \
+omap_mcbsp##id##_get_st_ch##channel##_volume(struct snd_kcontrol *kc, \
+ struct snd_ctl_elem_value *uc) \
+{ \
+ s16 chgain; \
+ \
+ if (omap_st_get_chgain((id)-1, channel, &chgain)) \
+ return -EAGAIN; \
+ \
+ uc->value.integer.value[0] = chgain;\
+ return 0; \
+}
+
+OMAP_MCBSP_ST_SET_CHANNEL_VOLUME(2, 0)
+OMAP_MCBSP_ST_SET_CHANNEL_VOLUME(2, 1)
+OMAP_MCBSP_ST_SET_CHANNEL_VOLUME(3, 0)
+OMAP_MCBSP_ST_SET_CHANNEL_VOLUME(3, 1)
+OMAP_MCBSP_ST_GET_CHANNEL_VOLUME(2, 0)
+OMAP_MCBSP_ST_GET_CHANNEL_VOLUME(2, 1)
+OMAP_MCBSP_ST_GET_CHANNEL_VOLUME(3, 0)
+OMAP_MCBSP_ST_GET_CHANNEL_VOLUME(3, 1)
+
+static int omap_mcbsp_st_put_mode(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct soc_mixer_control *mc =
+ (struct soc_mixer_control *)kcontrol->private_value;
+ u8 value = ucontrol->value.integer.value[0];
+
+ if (value == omap_st_is_enabled(mc->reg))
+ return 0;
+
+ if (value)
+ omap_st_enable(mc->reg);
+ else
+ omap_st_disable(mc->reg);
+
+ return 1;
+}
+
+static int omap_mcbsp_st_get_mode(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct soc_mixer_control *mc =
+ (struct soc_mixer_control *)kcontrol->private_value;
+
+ ucontrol->value.integer.value[0] = omap_st_is_enabled(mc->reg);
+ return 0;
+}
+
+static const struct snd_kcontrol_new omap_mcbsp2_st_controls[] = {
+ SOC_SINGLE_EXT("McBSP2 Sidetone Switch", 1, 0, 1, 0,
+ omap_mcbsp_
RE: [PATCHv4 2/2] ASoC: OMAP-McBSP: ASoC interface for McBSP sidetone
>From: Nurkkala Eero.An (EXT-Offcode/Oulu) >Sent: 19 February, 2010 21:04 > >> Oops, I seemed to copy Q1.14 instead of Q14.1, but isn't it >still the same. >> When I added some debug messages it still seemed to be corret. >> >> Lowest number (-32768) is represented with 16th bit '1' and >the rest are >> zeros, right? That is 0x8000. >> -1 has all the bits set (0x) and 0 has all the bit >cleared (0x). >> Highest positive value has 16th bit cleared and the rest set >(0x7fff). >> >> Or did I interpret something wrong? >> >> Cheers, Ilkka > >I guess it's just fine, but let's see. Maybe I was lost in the >Q1.14: m + n + 1 ~ >binary: [sign bit, (m), (n)] where m is the integer portion, 0 >or 1, n is 14 bits.. >so if your input was [-32768... 32767] -> [-2,2] then, for example, >-32768 is in hex: 0x8000, but the 2nd most significant bit is >zero, which means >the integer portion (m) is not 1, which makes me doubt the >gain -32768 is >actually -1 (or 0), not -2. But then, as it's a two's >complement, it maybe just correct. > >So most likely it's just fine; I just had a thinko. Ok, now I got your point :) However, as far as I can understand the Q notation right, it basically defines how to interpret the value. That is, where is the decimal point. Thus, I would say that the code should work fine and based on quick tests, the gain control seems to behave ok too. Cheers, Ilkka-- 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] AM35x: Enable OMAP_MUX in defconfig
Enabling OMAP_MUX in defconfig as it is required for EHCI to work. Signed-off-by: Ajay Kumar Gupta --- arch/arm/configs/am3517_evm_defconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/am3517_evm_defconfig b/arch/arm/configs/am3517_evm_defconfig index abe9966..edae1c2 100644 --- a/arch/arm/configs/am3517_evm_defconfig +++ b/arch/arm/configs/am3517_evm_defconfig @@ -201,7 +201,7 @@ CONFIG_ARCH_OMAP3=y # CONFIG_OMAP_DEBUG_POWERDOMAIN is not set # CONFIG_OMAP_DEBUG_CLOCKDOMAIN is not set CONFIG_OMAP_RESET_CLOCKS=y -# CONFIG_OMAP_MUX is not set +CONFIG_OMAP_MUX=y # CONFIG_OMAP_MCBSP is not set # CONFIG_OMAP_MBOX_FWK is not set # CONFIG_OMAP_MPU_TIMER is not set -- 1.6.2.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] AM35x: Add missing GPIO mux config for EHCI port
Adding GPIO mux config used for PHY reset of EHCI port on base board. We get below failure message without this patch, "hub 1-0:1.0: unable to enumerate USB device on port 1" Signed-off-by: Ajay Kumar Gupta --- arch/arm/mach-omap2/board-am3517evm.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c index af99faf..c78a4d0 100644 --- a/arch/arm/mach-omap2/board-am3517evm.c +++ b/arch/arm/mach-omap2/board-am3517evm.c @@ -232,6 +232,9 @@ static void __init am3517_evm_init(void) ARRAY_SIZE(am3517_evm_devices)); omap_serial_init(); + + /* Configure GPIO for EHCI port */ + omap_mux_init_gpio(57, OMAP_PIN_OUTPUT); usb_ehci_init(&ehci_pdata); /* DSS */ am3517_evm_display_init(); -- 1.6.2.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
