Re: [PATCH v2 3/5] OMAP4-HSMMC: Adding MMC-TWL regulator changes
On Wed, May 5, 2010 at 12:27 PM, G, Manjunath Kondaiah wrote:
>
>
>> -Original Message-
>> From: kishore kadiyala [mailto:kishorek.kadiy...@gmail.com]
>> Sent: Wednesday, May 05, 2010 12:19 PM
>> To: G, Manjunath Kondaiah
>> Cc: Kadiyala, Kishore; linux-...@vger.kernel.org;
>> linux-omap@vger.kernel.org; t...@atomide.com; Chikkature
>> Rajashekar, Madhusudhan; jarkko.lavi...@nokia.com;
>> r...@arm.linux.org.uk; p...@pwsan.com
>> Subject: Re: [PATCH v2 3/5] OMAP4-HSMMC: Adding MMC-TWL
>> regulator changes
>>
>> On Wed, May 5, 2010 at 8:53 AM, G, Manjunath Kondaiah
>> wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: linux-omap-ow...@vger.kernel.org
>> >> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
>> >> kishore kadiyala
>> >> Sent: Tuesday, May 04, 2010 9:32 PM
>> >> To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
>> >> Cc: t...@atomide.com; Chikkature Rajashekar, Madhusudhan;
>> >> jarkko.lavi...@nokia.com; r...@arm.linux.org.uk; p...@pwsan.com
>> >> Subject: [PATCH v2 3/5] OMAP4-HSMMC: Adding MMC-TWL
>> regulator changes
>> >>
>> >> This patch adds PBIAS Configuration during POWER ON and OFF.
>> >> Also it adds MMC1 Card detect configuration on Phoenix
>> >>
>> >> Signed-off-by: Kishore Kadiyala
>> >> ---
>> >> arch/arm/mach-omap2/hsmmc.c | 121
>> >> ++---
>> >> arch/arm/plat-omap/include/plat/control.h | 17
>> >> include/linux/i2c/twl.h | 42 +-
>> >> 3 files changed, 166 insertions(+), 14 deletions(-)
>> >>
>> >> diff --git a/arch/arm/mach-omap2/hsmmc.c
>> b/arch/arm/mach-omap2/hsmmc.c
>> >> index f5ca16c..a73f011 100644
>> >> --- a/arch/arm/mach-omap2/hsmmc.c
>> >> +++ b/arch/arm/mach-omap2/hsmmc.c
>> >> @@ -14,6 +14,7 @@
>> >> #include
>> >> #include
>> >> #include
>> >> +#include
>> >> #include
>> >> #include
>> >> #include
>> >> @@ -25,6 +26,7 @@
>> >>
>> >> static u16 control_pbias_offset;
>> >> static u16 control_devconf1_offset;
>> >> +static u16 control_mmc1;
>> >>
>> >> #define HSMMC_NAME_LEN 9
>> >>
>> >> @@ -43,7 +45,7 @@ static int hsmmc_get_context_loss(struct
>> >> device *dev)
>> >> #define hsmmc_get_context_loss NULL
>> >> #endif
>> >>
>> >> -static void hsmmc1_before_set_reg(struct device *dev, int slot,
>> >> +static void omap_hsmmc1_before_set_reg(struct device
>> *dev, int slot,
>> >> int power_on, int vdd)
>> >> {
>> >> u32 reg, prog_io;
>> >> @@ -96,7 +98,7 @@ static void hsmmc1_before_set_reg(struct
>> >> device *dev, int slot,
>> >> }
>> >> }
>> >>
>> >> -static void hsmmc1_after_set_reg(struct device *dev, int slot,
>> >> +static void omap_hsmmc1_after_set_reg(struct device *dev,
>> int slot,
>> >> int power_on, int vdd)
>> >> {
>> >> u32 reg;
>> >> @@ -120,6 +122,61 @@ static void hsmmc1_after_set_reg(struct
>> >> device *dev, int slot,
>> >> }
>> >> }
>> >>
>> >> +static void omap4_hsmmc1_before_set_reg(struct device
>> *dev, int slot,
>> >> + int power_on, int vdd)
>> >> +{
>> >> + u32 reg;
>> >> +
>> >> + /*
>> >> + * Assume we power both OMAP VMMC1 (for CMD, CLK,
>> >> DAT0..3) and the
>> >> + * card with Vcc regulator (from twl4030 or whatever).
>> >> OMAP has both
>> >> + * 1.8V and 3.0V modes, controlled by the PBIAS register.
>> >> + *
>> >> + * In 8-bit modes, OMAP VMMC1A (for DAT4..7) needs a
>> >> supply, which
>> >> + * is most naturally TWL VSIM; those pins also use PBIAS.
>> >> + *
>> >> + * FIXME handle VMMC1A as needed ...
>> >> + */
>> >> + if (power_on) {
>> >> + reg = omap_ctrl_readl(control_pbias_offset);
>> >> + reg &= ~(OMAP4_MMC1_PBIASLITE_PWRDNZ |
>> >> OMAP4_MMC1_PWRDNZ);
>> >> + omap_ctrl_writel(reg, control_pbias_offset);
>> >> + } else {
>> >> + reg = omap_ctrl_readl(control_pbias_offset);
>> >> + reg &= ~(OMAP4_MMC1_PBIASLITE_PWRDNZ |
>> >> OMAP4_MMC1_PWRDNZ);
>> >> + omap_ctrl_writel(reg, control_pbias_offset);
>> >> + }
>> >> +}
>> >> +
>> >> +static void omap4_hsmmc1_after_set_reg(struct device
>> *dev, int slot,
>> >> + int power_on, int vdd)
>> >> +{
>> >> + u32 reg;
>> >> +
>> >> + /* 100ms delay required for PBIAS configuration */
>> >> + msleep(100);
>> >> +
>> >> + if (power_on) {
>> >> + reg = omap_ctrl_readl(control_pbias_offset);
>> >> + reg |= OMAP4_MMC1_PBIASLITE_PWRDNZ;
>> >> + if ((1 << vdd) <= MMC_VDD_165_195) {
>> >> + reg &= ~OMAP4_MMC1_PBIASLITE_VMODE;
>> >> + reg |= (OMAP4_MMC1_PBIASLITE_PWRDNZ |
>> >> + OMAP4_MMC1_PWRDNZ);
>> >> + } else {
>> >> + reg |= (OMAP4_MMC1_PBIASLITE_VMODE |
>> >> + OMAP4_MMC1_PBIASLITE
RE: [PATCH v2 3/5] OMAP4-HSMMC: Adding MMC-TWL regulator changes
> -Original Message-
> From: kishore kadiyala [mailto:kishorek.kadiy...@gmail.com]
> Sent: Wednesday, May 05, 2010 12:19 PM
> To: G, Manjunath Kondaiah
> Cc: Kadiyala, Kishore; linux-...@vger.kernel.org;
> linux-omap@vger.kernel.org; t...@atomide.com; Chikkature
> Rajashekar, Madhusudhan; jarkko.lavi...@nokia.com;
> r...@arm.linux.org.uk; p...@pwsan.com
> Subject: Re: [PATCH v2 3/5] OMAP4-HSMMC: Adding MMC-TWL
> regulator changes
>
> On Wed, May 5, 2010 at 8:53 AM, G, Manjunath Kondaiah
> wrote:
> >
> >
> >> -Original Message-
> >> From: linux-omap-ow...@vger.kernel.org
> >> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
> >> kishore kadiyala
> >> Sent: Tuesday, May 04, 2010 9:32 PM
> >> To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
> >> Cc: t...@atomide.com; Chikkature Rajashekar, Madhusudhan;
> >> jarkko.lavi...@nokia.com; r...@arm.linux.org.uk; p...@pwsan.com
> >> Subject: [PATCH v2 3/5] OMAP4-HSMMC: Adding MMC-TWL
> regulator changes
> >>
> >> This patch adds PBIAS Configuration during POWER ON and OFF.
> >> Also it adds MMC1 Card detect configuration on Phoenix
> >>
> >> Signed-off-by: Kishore Kadiyala
> >> ---
> >> arch/arm/mach-omap2/hsmmc.c | 121
> >> ++---
> >> arch/arm/plat-omap/include/plat/control.h | 17
> >> include/linux/i2c/twl.h | 42 +-
> >> 3 files changed, 166 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-omap2/hsmmc.c
> b/arch/arm/mach-omap2/hsmmc.c
> >> index f5ca16c..a73f011 100644
> >> --- a/arch/arm/mach-omap2/hsmmc.c
> >> +++ b/arch/arm/mach-omap2/hsmmc.c
> >> @@ -14,6 +14,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include
> >> #include
> >> #include
> >> @@ -25,6 +26,7 @@
> >>
> >> static u16 control_pbias_offset;
> >> static u16 control_devconf1_offset;
> >> +static u16 control_mmc1;
> >>
> >> #define HSMMC_NAME_LEN 9
> >>
> >> @@ -43,7 +45,7 @@ static int hsmmc_get_context_loss(struct
> >> device *dev)
> >> #define hsmmc_get_context_loss NULL
> >> #endif
> >>
> >> -static void hsmmc1_before_set_reg(struct device *dev, int slot,
> >> +static void omap_hsmmc1_before_set_reg(struct device
> *dev, int slot,
> >> int power_on, int vdd)
> >> {
> >> u32 reg, prog_io;
> >> @@ -96,7 +98,7 @@ static void hsmmc1_before_set_reg(struct
> >> device *dev, int slot,
> >> }
> >> }
> >>
> >> -static void hsmmc1_after_set_reg(struct device *dev, int slot,
> >> +static void omap_hsmmc1_after_set_reg(struct device *dev,
> int slot,
> >> int power_on, int vdd)
> >> {
> >> u32 reg;
> >> @@ -120,6 +122,61 @@ static void hsmmc1_after_set_reg(struct
> >> device *dev, int slot,
> >> }
> >> }
> >>
> >> +static void omap4_hsmmc1_before_set_reg(struct device
> *dev, int slot,
> >> + int power_on, int vdd)
> >> +{
> >> + u32 reg;
> >> +
> >> + /*
> >> + * Assume we power both OMAP VMMC1 (for CMD, CLK,
> >> DAT0..3) and the
> >> + * card with Vcc regulator (from twl4030 or whatever).
> >> OMAP has both
> >> + * 1.8V and 3.0V modes, controlled by the PBIAS register.
> >> + *
> >> + * In 8-bit modes, OMAP VMMC1A (for DAT4..7) needs a
> >> supply, which
> >> + * is most naturally TWL VSIM; those pins also use PBIAS.
> >> + *
> >> + * FIXME handle VMMC1A as needed ...
> >> + */
> >> + if (power_on) {
> >> + reg = omap_ctrl_readl(control_pbias_offset);
> >> + reg &= ~(OMAP4_MMC1_PBIASLITE_PWRDNZ |
> >> OMAP4_MMC1_PWRDNZ);
> >> + omap_ctrl_writel(reg, control_pbias_offset);
> >> + } else {
> >> + reg = omap_ctrl_readl(control_pbias_offset);
> >> + reg &= ~(OMAP4_MMC1_PBIASLITE_PWRDNZ |
> >> OMAP4_MMC1_PWRDNZ);
> >> + omap_ctrl_writel(reg, control_pbias_offset);
> >> + }
> >> +}
> >> +
> >> +static void omap4_hsmmc1_after_set_reg(struct device
> *dev, int slot,
> >> + int power_on, int vdd)
> >> +{
> >> + u32 reg;
> >> +
> >> + /* 100ms delay required for PBIAS configuration */
> >> + msleep(100);
> >> +
> >> + if (power_on) {
> >> + reg = omap_ctrl_readl(control_pbias_offset);
> >> + reg |= OMAP4_MMC1_PBIASLITE_PWRDNZ;
> >> + if ((1 << vdd) <= MMC_VDD_165_195) {
> >> + reg &= ~OMAP4_MMC1_PBIASLITE_VMODE;
> >> + reg |= (OMAP4_MMC1_PBIASLITE_PWRDNZ |
> >> + OMAP4_MMC1_PWRDNZ);
> >> + } else {
> >> + reg |= (OMAP4_MMC1_PBIASLITE_VMODE |
> >> + OMAP4_MMC1_PBIASLITE_PWRDNZ |
> >> + OMAP4_MMC1_PWRDNZ);
> >> + }
> >> + omap_ctrl_writel(reg, control_pbias_offset);
> >> + } else {
> >> +
Re: [PATCH v2 3/5] OMAP4-HSMMC: Adding MMC-TWL regulator changes
On Wed, May 5, 2010 at 8:53 AM, G, Manjunath Kondaiah wrote:
>
>
>> -Original Message-
>> From: linux-omap-ow...@vger.kernel.org
>> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
>> kishore kadiyala
>> Sent: Tuesday, May 04, 2010 9:32 PM
>> To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
>> Cc: t...@atomide.com; Chikkature Rajashekar, Madhusudhan;
>> jarkko.lavi...@nokia.com; r...@arm.linux.org.uk; p...@pwsan.com
>> Subject: [PATCH v2 3/5] OMAP4-HSMMC: Adding MMC-TWL regulator changes
>>
>> This patch adds PBIAS Configuration during POWER ON and OFF.
>> Also it adds MMC1 Card detect configuration on Phoenix
>>
>> Signed-off-by: Kishore Kadiyala
>> ---
>> arch/arm/mach-omap2/hsmmc.c | 121
>> ++---
>> arch/arm/plat-omap/include/plat/control.h | 17
>> include/linux/i2c/twl.h | 42 +-
>> 3 files changed, 166 insertions(+), 14 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
>> index f5ca16c..a73f011 100644
>> --- a/arch/arm/mach-omap2/hsmmc.c
>> +++ b/arch/arm/mach-omap2/hsmmc.c
>> @@ -14,6 +14,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -25,6 +26,7 @@
>>
>> static u16 control_pbias_offset;
>> static u16 control_devconf1_offset;
>> +static u16 control_mmc1;
>>
>> #define HSMMC_NAME_LEN 9
>>
>> @@ -43,7 +45,7 @@ static int hsmmc_get_context_loss(struct
>> device *dev)
>> #define hsmmc_get_context_loss NULL
>> #endif
>>
>> -static void hsmmc1_before_set_reg(struct device *dev, int slot,
>> +static void omap_hsmmc1_before_set_reg(struct device *dev, int slot,
>> int power_on, int vdd)
>> {
>> u32 reg, prog_io;
>> @@ -96,7 +98,7 @@ static void hsmmc1_before_set_reg(struct
>> device *dev, int slot,
>> }
>> }
>>
>> -static void hsmmc1_after_set_reg(struct device *dev, int slot,
>> +static void omap_hsmmc1_after_set_reg(struct device *dev, int slot,
>> int power_on, int vdd)
>> {
>> u32 reg;
>> @@ -120,6 +122,61 @@ static void hsmmc1_after_set_reg(struct
>> device *dev, int slot,
>> }
>> }
>>
>> +static void omap4_hsmmc1_before_set_reg(struct device *dev, int slot,
>> + int power_on, int vdd)
>> +{
>> + u32 reg;
>> +
>> + /*
>> + * Assume we power both OMAP VMMC1 (for CMD, CLK,
>> DAT0..3) and the
>> + * card with Vcc regulator (from twl4030 or whatever).
>> OMAP has both
>> + * 1.8V and 3.0V modes, controlled by the PBIAS register.
>> + *
>> + * In 8-bit modes, OMAP VMMC1A (for DAT4..7) needs a
>> supply, which
>> + * is most naturally TWL VSIM; those pins also use PBIAS.
>> + *
>> + * FIXME handle VMMC1A as needed ...
>> + */
>> + if (power_on) {
>> + reg = omap_ctrl_readl(control_pbias_offset);
>> + reg &= ~(OMAP4_MMC1_PBIASLITE_PWRDNZ |
>> OMAP4_MMC1_PWRDNZ);
>> + omap_ctrl_writel(reg, control_pbias_offset);
>> + } else {
>> + reg = omap_ctrl_readl(control_pbias_offset);
>> + reg &= ~(OMAP4_MMC1_PBIASLITE_PWRDNZ |
>> OMAP4_MMC1_PWRDNZ);
>> + omap_ctrl_writel(reg, control_pbias_offset);
>> + }
>> +}
>> +
>> +static void omap4_hsmmc1_after_set_reg(struct device *dev, int slot,
>> + int power_on, int vdd)
>> +{
>> + u32 reg;
>> +
>> + /* 100ms delay required for PBIAS configuration */
>> + msleep(100);
>> +
>> + if (power_on) {
>> + reg = omap_ctrl_readl(control_pbias_offset);
>> + reg |= OMAP4_MMC1_PBIASLITE_PWRDNZ;
>> + if ((1 << vdd) <= MMC_VDD_165_195) {
>> + reg &= ~OMAP4_MMC1_PBIASLITE_VMODE;
>> + reg |= (OMAP4_MMC1_PBIASLITE_PWRDNZ |
>> + OMAP4_MMC1_PWRDNZ);
>> + } else {
>> + reg |= (OMAP4_MMC1_PBIASLITE_VMODE |
>> + OMAP4_MMC1_PBIASLITE_PWRDNZ |
>> + OMAP4_MMC1_PWRDNZ);
>> + }
>> + omap_ctrl_writel(reg, control_pbias_offset);
>> + } else {
>> + reg = omap_ctrl_readl(control_pbias_offset);
>> + reg |= (OMAP4_MMC1_PBIASLITE_PWRDNZ |
>> + OMAP4_MMC1_PBIASLITE_VMODE | OMAP4_MMC1_PWRDNZ);
>> + omap_ctrl_writel(reg, control_pbias_offset);
>> + }
>> +}
>> +
>> static void hsmmc23_before_set_reg(struct device *dev, int slot,
>> int power_on, int vdd)
>> {
>> @@ -140,6 +197,24 @@ static void
>> hsmmc23_before_set_reg(struct device *dev, int slot,
>> }
>> }
>>
>> +static int mmc_twl_late_init(struct device *dev)
>> +{
>> + int ret = 0;
>> + struct platform_device *pdev = container_of(dev,
>> + struct platform_device, d
Re: [PATCH v9] board-omap3-beagle: add DSS2 support
Tony,
Would it be possible to get this applied in the next merge window?
regards,
Koen
Op 3 mei 2010, om 16:15 heeft Tomi Valkeinen het volgende geschreven:
> On Thu, 2010-04-22 at 10:23 +0200, ext Koen Kooi wrote:
>> This patch adds DSS2 support to the beagleboard boardfile. DVI and TV-out
>> are supported.
>>
>> Signed-off-by: Koen Kooi
>
> Acked-by: Tomi Valkeinen
>
>
>> ---
>> Changes since v1:
>>* removed beagle_panel_enable_tv() and beagle_panel_disable_tv()
>> Changes since v2:
>>* changed to REGULATOR_SUPPLY(_name, _dev_name) for dss regulators
>> Changes since v3:
>>* really remove beagle_panel_enable_tv() and beagle_panel_disable_tv()
>>* moved comments to this section
>> Changes since v4:
>>* remove trailing whitespace
>> Changes since v5:
>>* fix semicolon typo
>> Changes since v6:
>>* use gpio_is_valid(dssdev->reset_gpio)
>> Changes since v8:
>>* fix missing whitespace before __init omap3_beagle_map_io(){}
>>
>> arch/arm/mach-omap2/board-omap3beagle.c | 101
>> +++
>> 1 files changed, 75 insertions(+), 26 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
>> b/arch/arm/mach-omap2/board-omap3beagle.c
>> index 962d377..69b154c 100644
>> --- a/arch/arm/mach-omap2/board-omap3beagle.c
>> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
>> @@ -39,6 +39,7 @@
>>
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -106,6 +107,77 @@ static struct platform_device omap3beagle_nand_device =
>> {
>> .resource = &omap3beagle_nand_resource,
>> };
>>
>> +/* DSS */
>> +
>> +static int beagle_enable_dvi(struct omap_dss_device *dssdev)
>> +{
>> +if (gpio_is_valid(dssdev->reset_gpio))
>> +gpio_set_value(dssdev->reset_gpio, 1);
>> +
>> +return 0;
>> +}
>> +
>> +static void beagle_disable_dvi(struct omap_dss_device *dssdev)
>> +{
>> +if (gpio_is_valid(dssdev->reset_gpio))
>> +gpio_set_value(dssdev->reset_gpio, 0);
>> +}
>> +
>> +static struct omap_dss_device beagle_dvi_device = {
>> +.type = OMAP_DISPLAY_TYPE_DPI,
>> +.name = "dvi",
>> +.driver_name = "generic_panel",
>> +.phy.dpi.data_lines = 24,
>> +.reset_gpio = 170,
>> +.platform_enable = beagle_enable_dvi,
>> +.platform_disable = beagle_disable_dvi,
>> +};
>> +
>> +static struct omap_dss_device beagle_tv_device = {
>> +.name = "tv",
>> +.driver_name = "venc",
>> +.type = OMAP_DISPLAY_TYPE_VENC,
>> +.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
>> +};
>> +
>> +static struct omap_dss_device *beagle_dss_devices[] = {
>> +&beagle_dvi_device,
>> +&beagle_tv_device,
>> +};
>> +
>> +static struct omap_dss_board_info beagle_dss_data = {
>> +.num_devices = ARRAY_SIZE(beagle_dss_devices),
>> +.devices = beagle_dss_devices,
>> +.default_device = &beagle_dvi_device,
>> +};
>> +
>> +static struct platform_device beagle_dss_device = {
>> +.name = "omapdss",
>> +.id= -1,
>> +.dev= {
>> +.platform_data = &beagle_dss_data,
>> +},
>> +};
>> +
>> +static struct regulator_consumer_supply beagle_vdac_supply =
>> +REGULATOR_SUPPLY("vdda_dac", "omapdss");
>> +
>> +static struct regulator_consumer_supply beagle_vdvi_supply =
>> +REGULATOR_SUPPLY("vdds_dsi", "omapdss");
>> +
>> +static void __init beagle_display_init(void)
>> +{
>> +int r;
>> +
>> +r = gpio_request(beagle_dvi_device.reset_gpio, "DVI reset");
>> +if (r < 0) {
>> +printk(KERN_ERR "Unable to get DVI reset GPIO\n");
>> +return;
>> +}
>> +
>> +gpio_direction_output(beagle_dvi_device.reset_gpio, 0);
>> +}
>> +
>> #include "sdram-micron-mt46h32m32lf-6.h"
>>
>> static struct omap2_hsmmc_info mmc[] = {
>> @@ -117,15 +189,6 @@ static struct omap2_hsmmc_info mmc[] = {
>> {} /* Terminator */
>> };
>>
>> -static struct platform_device omap3_beagle_lcd_device = {
>> -.name = "omap3beagle_lcd",
>> -.id = -1,
>> -};
>> -
>> -static struct omap_lcd_config omap3_beagle_lcd_config __initdata = {
>> -.ctrl_name = "internal",
>> -};
>> -
>> static struct regulator_consumer_supply beagle_vmmc1_supply = {
>> .supply = "vmmc",
>> };
>> @@ -181,16 +244,6 @@ static struct twl4030_gpio_platform_data
>> beagle_gpio_data = {
>> .setup = beagle_twl_gpio_setup,
>> };
>>
>> -static struct regulator_consumer_supply beagle_vdac_supply = {
>> -.supply = "vdac",
>> -.dev= &omap3_beagle_lcd_device.dev,
>> -};
>> -
>> -static struct regulator_consumer_supply beagle_vdvi_supply = {
>> -.supply = "vdvi",
>> -.dev= &omap3_beagle_lcd_device.dev,
>> -};
>> -
>> /* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA)
>> */
>> static struct regulator_init_data beagle_vmmc1 = {
>> .constraints = {
>> @@ -349,14 +402,8 @@ static struct platform_device
Re: [PATCH v2 3/5] OMAP4-HSMMC: Adding MMC-TWL regulator changes
On Wed, May 5, 2010 at 4:41 AM, Paul Walmsley wrote:
> Hello,
>
> On Tue, 4 May 2010, kishore kadiyala wrote:
>
>> This patch adds PBIAS Configuration during POWER ON and OFF.
>> Also it adds MMC1 Card detect configuration on Phoenix
>>
>> Signed-off-by: Kishore Kadiyala
>> ---
>> arch/arm/mach-omap2/hsmmc.c | 121
>> ++---
>> arch/arm/plat-omap/include/plat/control.h | 17
>> include/linux/i2c/twl.h | 42 +-
>> 3 files changed, 166 insertions(+), 14 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
>> index f5ca16c..a73f011 100644
>> --- a/arch/arm/mach-omap2/hsmmc.c
>> +++ b/arch/arm/mach-omap2/hsmmc.c
>> @@ -14,6 +14,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -25,6 +26,7 @@
>>
>> static u16 control_pbias_offset;
>> static u16 control_devconf1_offset;
>> +static u16 control_mmc1;
>>
>> #define HSMMC_NAME_LEN 9
>>
>> @@ -43,7 +45,7 @@ static int hsmmc_get_context_loss(struct device *dev)
>> #define hsmmc_get_context_loss NULL
>> #endif
>>
>> -static void hsmmc1_before_set_reg(struct device *dev, int slot,
>> +static void omap_hsmmc1_before_set_reg(struct device *dev, int slot,
>> int power_on, int vdd)
>> {
>> u32 reg, prog_io;
>> @@ -96,7 +98,7 @@ static void hsmmc1_before_set_reg(struct device *dev, int
>> slot,
>> }
>> }
>>
>> -static void hsmmc1_after_set_reg(struct device *dev, int slot,
>> +static void omap_hsmmc1_after_set_reg(struct device *dev, int slot,
>> int power_on, int vdd)
>> {
>> u32 reg;
>> @@ -120,6 +122,61 @@ static void hsmmc1_after_set_reg(struct device *dev,
>> int slot,
>> }
>> }
>>
>> +static void omap4_hsmmc1_before_set_reg(struct device *dev, int slot,
>> + int power_on, int vdd)
>> +{
>> + u32 reg;
>> +
>> + /*
>> + * Assume we power both OMAP VMMC1 (for CMD, CLK, DAT0..3) and the
>> + * card with Vcc regulator (from twl4030 or whatever). OMAP has both
>> + * 1.8V and 3.0V modes, controlled by the PBIAS register.
>> + *
>> + * In 8-bit modes, OMAP VMMC1A (for DAT4..7) needs a supply, which
>> + * is most naturally TWL VSIM; those pins also use PBIAS.
>> + *
>> + * FIXME handle VMMC1A as needed ...
>> + */
>> + if (power_on) {
>> + reg = omap_ctrl_readl(control_pbias_offset);
>> + reg &= ~(OMAP4_MMC1_PBIASLITE_PWRDNZ | OMAP4_MMC1_PWRDNZ);
>> + omap_ctrl_writel(reg, control_pbias_offset);
>> + } else {
>> + reg = omap_ctrl_readl(control_pbias_offset);
>> + reg &= ~(OMAP4_MMC1_PBIASLITE_PWRDNZ | OMAP4_MMC1_PWRDNZ);
>> + omap_ctrl_writel(reg, control_pbias_offset);
>> + }
>
> If the code in both branches of the conditional is identical, what's the
> point of keeping the conditional?
Agree and will correct
>
>> +}
>> +
>> +static void omap4_hsmmc1_after_set_reg(struct device *dev, int slot,
>> + int power_on, int vdd)
>> +{
>> + u32 reg;
>> +
>> + /* 100ms delay required for PBIAS configuration */
>> + msleep(100);
>> +
>> + if (power_on) {
>> + reg = omap_ctrl_readl(control_pbias_offset);
>> + reg |= OMAP4_MMC1_PBIASLITE_PWRDNZ;
>> + if ((1 << vdd) <= MMC_VDD_165_195) {
>> + reg &= ~OMAP4_MMC1_PBIASLITE_VMODE;
>> + reg |= (OMAP4_MMC1_PBIASLITE_PWRDNZ |
>> + OMAP4_MMC1_PWRDNZ);
>> + } else {
>> + reg |= (OMAP4_MMC1_PBIASLITE_VMODE |
>> + OMAP4_MMC1_PBIASLITE_PWRDNZ |
>> + OMAP4_MMC1_PWRDNZ);
>> + }
>> + omap_ctrl_writel(reg, control_pbias_offset);
>> + } else {
>> + reg = omap_ctrl_readl(control_pbias_offset);
>> + reg |= (OMAP4_MMC1_PBIASLITE_PWRDNZ |
>> + OMAP4_MMC1_PBIASLITE_VMODE | OMAP4_MMC1_PWRDNZ);
>> + omap_ctrl_writel(reg, control_pbias_offset);
>> + }
>> +}
>> +
>> static void hsmmc23_before_set_reg(struct device *dev, int slot,
>> int power_on, int vdd)
>> {
>> @@ -140,6 +197,24 @@ static void hsmmc23_before_set_reg(struct device *dev,
>> int slot,
>> }
>> }
>>
>> +static int mmc_twl_late_init(struct device *dev)
>> +{
>> + int ret = 0;
>> + struct platform_device *pdev = container_of(dev,
>> + struct platform_device, dev);
>> +
>> + if (cpu_is_omap44xx()) {
>> + /* MMC1 Card detect Configuration */
>> + if (pdev->id == 0) {
>> + ret = omap4_hsmmc1_card_detect_config();
>> + if (ret < 0)
>> + pr_err("
RE: [PATCH 2/4] OMAP4: SPI: Fix Driver Kconfig
Hi Tony, > > config SPI_OMAP24XX > > - tristate "McSPI driver for OMAP24xx/OMAP34xx" > > - depends on ARCH_OMAP2 || ARCH_OMAP3 > > + tristate "McSPI driver for OMAP24xx/OMAP34xx/OMAP44xx" > > + depends on ARCH_OMAP24XX || ARCH_OMAP34XX || ARCH_OMAP4 > > help > > - SPI master controller for OMAP24xx/OMAP34xx Multichannel SPI > > + SPI master controller for OMAP24xx/OMAP34xx/OMAP44xx Multichannel SPI > > (McSPI) modules. > > > > config SPI_OMAP_100K > > You can simplify this and make it more future proof with something like: > > config SPI_OMAP24XX > tristate "McSPI driver for OMAP" > depends on ARCH_OMAP2PLUS > help > SPI master controller for OMAP24XX and later Changed as suggested... ARCH_OMAP2PLUS "Systems based on omap24xx, omap34xx or omap44xx" Best Regards Abraham -- 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: Upcoming merge window and omap NAND patches
On Wed, May 5, 2010 at 10:19 AM, Artem Bityutskiy wrote: > On Wed, 2010-05-05 at 00:08 +0200, ext Tony Lindgren wrote: >> Hi all, >> >> There are several omap NAND patches pending, but some basic things >> should be fixed first. >> >> 1. The NAND driver needs to stop tinkering with the GPMC registers >> >> The omap General Purpose Memory Controller (GPMC) registers are omap >> specific, and not driver specific. Tinkering with these registers >> can cause issues with the other devices on the GPMC. >> >> To find out what needs to disappear fomr the NAND driver, just do: >> >> $ grep baseaddr drivers/mtd/nand/omap2.c >> >> Any GPMC register tinkering needs to happen in arch/arm/mach-omap2/gpmc.c. >> If there are not currently GPMC functions to do something in gpmc.c, then >> let's add the necessary support there. >> >> 2. Passing hardcoded GPMC_CS0_BASE needs to go from the board files >> >> Passing hardcoded GPMC virtual addressess is sure way to mess up >> things. This should all become unnecessary once the NAND drivers >> stops messing with the GPMC registers directly. >> >> So, as a result, I'm not planning on pushing any omap NAND related >> patches until these basic issues are fixed. I'll mark these patches >> as "Changes requested" in patchwork.kernel.org even if these patches >> don't have anything else wrong with them. >> >> Let's fix the basic things for good, and put the other patches on >> hold for a while. Sorry if this causes problems! > > Hi, > > fair enough. I guess Vimal should address this, as he seems to be the TI > mr. NAND, right? :-) Hi All, Sorry again. I am no more with TI and I don't have any board with me too. So, I'm unable to fix these. :( I hope someone else from TI can take care of it. -- Regards, Vimal Singh -- 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: Possible bug in onenand_base ?
Probably Adrian could comment on this?
On Fri, 2010-04-30 at 12:05 +0200, Enric Balletbò i Serra wrote:
> Hello all,
>
> After commit 5988af2319781bc8e0ce418affec4e09cfa77907 (mtd:
> Flex-OneNAND support) the onenand support for my device is broken.
>
> Before this commit when I run the nandtest program all is ok
> ---
> # nandtest /dev/mtd3
> ECC corrections: 0
> ECC failures : 0
> Bad blocks : 0
> BBT blocks : 0
> 002c: checking...
> Finished pass 1 successfully
> --
>
> Introduced commit 5988af2319781bc8e0ce418affec4e09cfa7790 the nandtest
> fails with:
> ---
> # nandtest /dev/mtd3
> ECC corrections: 0
> ECC failures : 0
> Bad blocks : 0
> BBT blocks : 0
> : reading...
> [ 299.092041] onenand_wait: ECC error = 0x8488
> ( ... lots of ECC errors ... )
> [ 299.092041] onenand_wait: ECC error = 0x8488
> ECC failed at
> : checking...
> compare failed. seed 1804289383
> Byte 0x1 is 5a should be da
> Byte 0x3 is 82 should be 92
> Byte 0x4 is 10 should be 1a
> ( ... )
> ---
>
> Investigating a little I see a significant difference introduced by
> this patch. In line
>
> 347:page = (int) (addr - onenand_addr(this, block)) >>
> this->page_shift; (patch applied)
>
> instead of
>
> 347:page = (int) (addr >> this->page_shift); (without patch)
>
> I applied commit 5988af2319781bc8e0ce418affec4e09cfa7790 and replaced
> the line 347 and now works again. Fantastic, but I suspect this is not
> the proper solution (probably this breaks other onenands devices, I
> can't test).
>
> I'm just introducing in OneNAND devices so anyone can help me to
> understand and solve the problem ? Note that my device is a Numonyx
> 4-Gbit DDP (DUAL DIE PLAN) OneNAND flash memory ( 2 dice of 2Gb, 2KB
> page )
>
> Thanks in advance,
>
> ///:~Enric
>
> ---
> diff --git a/drivers/mtd/onenand/onenand_base.c
> b/drivers/mtd/onenand/onenand_base.c
> index 081f97d..b1d50a3 100644
> --- a/drivers/mtd/onenand/onenand_base.c
> +++ b/drivers/mtd/onenand/onenand_base.c
> @@ -344,7 +344,7 @@ static int onenand_command(struct mtd_info *mtd,
> int cmd, loff_t addr, size_t le
>
> default:
> block = (int) onenand_block(this, addr);
> - page = (int) (addr - onenand_addr(this, block)) >>
> this->page_shift;
> + page = (int) (addr >> this->page_shift);
>
> if (ONENAND_IS_2PLANE(this)) {
> /* Make the even block number */
> ---
>
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
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: DSS2: GFX FIFO UNDERFLOW issue fixed
> -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@nokia.com] > Sent: Tuesday, May 04, 2010 7:15 PM > To: Hiremath, Vaibhav > Cc: Valkeinen Tomi (Nokia-D/Helsinki); linux-omap@vger.kernel.org > Subject: Re: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed > > On Tue, May 04, 2010 at 03:23:10PM +0200, ext Hiremath, Vaibhav wrote: > > > > I found the bug which is causing tearing effect, I tested it here with > both, mine and your applications and for me it is working fine. > > > > Can you please check at your end? > > (Sorry for the attachment) > > You should really avoid that. I can't quote the patch. [Hiremath, Vaibhav] I completely understand, actually the intention of this patch is to test so avoided "git send-email". > > What are those CW<->CCW swaps that you do in the patch? [Hiremath, Vaibhav] Did you observed how the rotation comes on the screen? Does it rotate the image clockwise of anti-clockwise direction? This is required to get clockwise rotation. > > Also I think the ioremap stuff is a bit broken since AFAICS it will > leave the old angle still mapped when you rotate to another angle. > [Hiremath, Vaibhav] Why do you say that? Are you referring to changing rotation from sysfs here? I hope you understand the change here, we are now mapping the write buffer to user space and overlay DMA is configured to 0 degree address map. So when you change the only rotation without writing anything to buffer (mapping is important here, since it will map newly configured rotated view) the display will stay intact. I have tested with both SYSFS and FBIO_PUTVSCREENINFO ioctl, the only difference in behavior is you have to write it buffer to see rotated image. Thanks, Vaibhav > -- > Ville Syrjälä -- 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: Upcoming merge window and omap NAND patches
On Wed, 2010-05-05 at 00:08 +0200, ext Tony Lindgren wrote: > Hi all, > > There are several omap NAND patches pending, but some basic things > should be fixed first. > > 1. The NAND driver needs to stop tinkering with the GPMC registers > > The omap General Purpose Memory Controller (GPMC) registers are omap > specific, and not driver specific. Tinkering with these registers > can cause issues with the other devices on the GPMC. > > To find out what needs to disappear fomr the NAND driver, just do: > > $ grep baseaddr drivers/mtd/nand/omap2.c > > Any GPMC register tinkering needs to happen in arch/arm/mach-omap2/gpmc.c. > If there are not currently GPMC functions to do something in gpmc.c, then > let's add the necessary support there. > > 2. Passing hardcoded GPMC_CS0_BASE needs to go from the board files > > Passing hardcoded GPMC virtual addressess is sure way to mess up > things. This should all become unnecessary once the NAND drivers > stops messing with the GPMC registers directly. > > So, as a result, I'm not planning on pushing any omap NAND related > patches until these basic issues are fixed. I'll mark these patches > as "Changes requested" in patchwork.kernel.org even if these patches > don't have anything else wrong with them. > > Let's fix the basic things for good, and put the other patches on > hold for a while. Sorry if this causes problems! Hi, fair enough. I guess Vimal should address this, as he seems to be the TI mr. NAND, right? :-) -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- 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 v8 0/2] sDMA descriptor autoloading feature
On Wed, May 5, 2010 at 4:45 AM, Madhusudhan wrote: >> -Original Message- >> From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of >> Venkatraman S >> Sent: Thursday, April 29, 2010 12:35 PM >> To: linux-omap@vger.kernel.org; linux-...@vger.kernel.org; linux-arm- >> ker...@lists.infradead.org >> Cc: Madhusudhan Chikkature; Tony Lindgren; Adrian Hunter; Santosh >> Shilimkar >> Subject: [PATCH v8 0/2] sDMA descriptor autoloading feature >> >> This patch series is the introduction of new sDMA feature: descriptor >> autoloading (v8) and it's adoption by the OMAP HSMMC driver. >> >> The previous version (v7) was blocked on achieving proper interrupt >> syncronisation >> between the MMC and DMA callback in the HSMMC driver. >> Thanks to Adrian Hunter's patch, >> https://patchwork.kernel.org/patch/94670/ >> this has been cleaned up. >> >> Current version is based on for-next branch + Adrian Hunter's >> interrupt syncronisation patch >> (https://patchwork.kernel.org/patch/94670) >> >> Changes since v7: >> * Removed the 'fix race condition between DMA and HSMMC callback' >> part of the series >> * Added memory barries in start and resume sglist transfer for cpu >> buffer syncronization >> * Cleanup and comments >> >> This has been tested on OMAP3430, OMAP3630 and OMAP4430 SDP >> for MMC file transfer and as boot file system. >> > > The HSMMC driver changes look good to me. I can ACK that but am not a DMA > expert to review your changes to the DMA driver. > Thanks. Can you please add your acked-by to 2/2 of this series so that patchworks can pick it up. Regards, Venkat. -- 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: [Resubmit: PATCH-V2] AM3517: Add VPFE Capture driver support
> -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Wednesday, May 05, 2010 4:48 AM > To: Hiremath, Vaibhav > Cc: linux-omap@vger.kernel.org; linux-me...@vger.kernel.org > Subject: Re: [Resubmit: PATCH-V2] AM3517: Add VPFE Capture driver support > > * hvaib...@ti.com [100319 02:34]: > > From: Vaibhav Hiremath > > > > AM3517 and DM644x uses same CCDC IP, so reusing the driver > > for AM3517. > > > > Signed-off-by: Vaibhav Hiremath > > --- > > arch/arm/mach-omap2/board-am3517evm.c | 160 > + > > 1 files changed, 160 insertions(+), 0 deletions(-) > > > > diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach- > omap2/board-am3517evm.c > > index f04311f..d2d2ced 100644 > > --- a/arch/arm/mach-omap2/board-am3517evm.c > > +++ b/arch/arm/mach-omap2/board-am3517evm.c > > @@ -30,11 +30,164 @@ > > > > #include > > #include > > +#include > > #include > > #include > > > > +#include > > +#include > > + > > At least the mainline kernel does not seem to have media/ti-media/, > so I'm not taking this. > > Looks like it should be safe to merge via linux-media from omap > point of view. [Hiremath, Vaibhav] Tony, This patch needs to rework, I will have to remove ti-media directory dependency since as of now we have decided not to include ti-media directory, instead we will use SoC name. > > Acked-by: Tony Lindgren [Hiremath, Vaibhav] Thanks for ack, I will resubmit it and ask Mauro to pull this. Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 3/5] OMAP4-HSMMC: Adding MMC-TWL regulator changes
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
> kishore kadiyala
> Sent: Tuesday, May 04, 2010 9:32 PM
> To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
> Cc: t...@atomide.com; Chikkature Rajashekar, Madhusudhan;
> jarkko.lavi...@nokia.com; r...@arm.linux.org.uk; p...@pwsan.com
> Subject: [PATCH v2 3/5] OMAP4-HSMMC: Adding MMC-TWL regulator changes
>
> This patch adds PBIAS Configuration during POWER ON and OFF.
> Also it adds MMC1 Card detect configuration on Phoenix
>
> Signed-off-by: Kishore Kadiyala
> ---
> arch/arm/mach-omap2/hsmmc.c | 121
> ++---
> arch/arm/plat-omap/include/plat/control.h | 17
> include/linux/i2c/twl.h | 42 +-
> 3 files changed, 166 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
> index f5ca16c..a73f011 100644
> --- a/arch/arm/mach-omap2/hsmmc.c
> +++ b/arch/arm/mach-omap2/hsmmc.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -25,6 +26,7 @@
>
> static u16 control_pbias_offset;
> static u16 control_devconf1_offset;
> +static u16 control_mmc1;
>
> #define HSMMC_NAME_LEN 9
>
> @@ -43,7 +45,7 @@ static int hsmmc_get_context_loss(struct
> device *dev)
> #define hsmmc_get_context_loss NULL
> #endif
>
> -static void hsmmc1_before_set_reg(struct device *dev, int slot,
> +static void omap_hsmmc1_before_set_reg(struct device *dev, int slot,
> int power_on, int vdd)
> {
> u32 reg, prog_io;
> @@ -96,7 +98,7 @@ static void hsmmc1_before_set_reg(struct
> device *dev, int slot,
> }
> }
>
> -static void hsmmc1_after_set_reg(struct device *dev, int slot,
> +static void omap_hsmmc1_after_set_reg(struct device *dev, int slot,
>int power_on, int vdd)
> {
> u32 reg;
> @@ -120,6 +122,61 @@ static void hsmmc1_after_set_reg(struct
> device *dev, int slot,
> }
> }
>
> +static void omap4_hsmmc1_before_set_reg(struct device *dev, int slot,
> + int power_on, int vdd)
> +{
> + u32 reg;
> +
> + /*
> + * Assume we power both OMAP VMMC1 (for CMD, CLK,
> DAT0..3) and the
> + * card with Vcc regulator (from twl4030 or whatever).
> OMAP has both
> + * 1.8V and 3.0V modes, controlled by the PBIAS register.
> + *
> + * In 8-bit modes, OMAP VMMC1A (for DAT4..7) needs a
> supply, which
> + * is most naturally TWL VSIM; those pins also use PBIAS.
> + *
> + * FIXME handle VMMC1A as needed ...
> + */
> + if (power_on) {
> + reg = omap_ctrl_readl(control_pbias_offset);
> + reg &= ~(OMAP4_MMC1_PBIASLITE_PWRDNZ |
> OMAP4_MMC1_PWRDNZ);
> + omap_ctrl_writel(reg, control_pbias_offset);
> + } else {
> + reg = omap_ctrl_readl(control_pbias_offset);
> + reg &= ~(OMAP4_MMC1_PBIASLITE_PWRDNZ |
> OMAP4_MMC1_PWRDNZ);
> + omap_ctrl_writel(reg, control_pbias_offset);
> + }
> +}
> +
> +static void omap4_hsmmc1_after_set_reg(struct device *dev, int slot,
> + int power_on, int vdd)
> +{
> + u32 reg;
> +
> + /* 100ms delay required for PBIAS configuration */
> + msleep(100);
> +
> + if (power_on) {
> + reg = omap_ctrl_readl(control_pbias_offset);
> + reg |= OMAP4_MMC1_PBIASLITE_PWRDNZ;
> + if ((1 << vdd) <= MMC_VDD_165_195) {
> + reg &= ~OMAP4_MMC1_PBIASLITE_VMODE;
> + reg |= (OMAP4_MMC1_PBIASLITE_PWRDNZ |
> + OMAP4_MMC1_PWRDNZ);
> + } else {
> + reg |= (OMAP4_MMC1_PBIASLITE_VMODE |
> + OMAP4_MMC1_PBIASLITE_PWRDNZ |
> + OMAP4_MMC1_PWRDNZ);
> + }
> + omap_ctrl_writel(reg, control_pbias_offset);
> + } else {
> + reg = omap_ctrl_readl(control_pbias_offset);
> + reg |= (OMAP4_MMC1_PBIASLITE_PWRDNZ |
> + OMAP4_MMC1_PBIASLITE_VMODE | OMAP4_MMC1_PWRDNZ);
> + omap_ctrl_writel(reg, control_pbias_offset);
> + }
> +}
> +
> static void hsmmc23_before_set_reg(struct device *dev, int slot,
> int power_on, int vdd)
> {
> @@ -140,6 +197,24 @@ static void
> hsmmc23_before_set_reg(struct device *dev, int slot,
> }
> }
>
> +static int mmc_twl_late_init(struct device *dev)
> +{
> + int ret = 0;
> + struct platform_device *pdev = container_of(dev,
> + struct platform_device, dev);
> +
> + if (cpu_is_omap44xx()) {
> + /* MMC1 Card detect Configuration */
> + if (pdev->id == 0) {
> + ret = omap4_hsmmc1_car
RE: [PATCH 1/2] ARM: McBSP: Fix request for irq in OMAP4
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Jorge
> Eduardo Candelaria
> Sent: Wednesday, May 05, 2010 5:08 AM
> To: linux-omap@vger.kernel.org
> Cc: Candelaria Villarreal, Jorge
> Subject: [PATCH 1/2] ARM: McBSP: Fix request for irq in OMAP4
>
> In OMAP4, there is only one irq line for TX and RX paths. Use
> the correct irq line to avoid errors at runtime.
>
> Also, request irq line only once (instead of requesting for TX
> and RX).
>
> Signed-off-by: Jorge Eduardo Candelaria
> ---
> arch/arm/mach-omap2/mcbsp.c | 12
> arch/arm/plat-omap/mcbsp.c | 20
> 2 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
> index 2f3cad6..6b550ec 100644
> --- a/arch/arm/mach-omap2/mcbsp.c
> +++ b/arch/arm/mach-omap2/mcbsp.c
> @@ -187,32 +187,28 @@ static struct omap_mcbsp_platform_data
> omap44xx_mcbsp_pdata[] = {
> .phys_base = OMAP44XX_MCBSP1_BASE,
> .dma_rx_sync= OMAP44XX_DMA_MCBSP1_RX,
> .dma_tx_sync= OMAP44XX_DMA_MCBSP1_TX,
> - .rx_irq = INT_24XX_MCBSP1_IRQ_RX,
> - .tx_irq = INT_24XX_MCBSP1_IRQ_TX,
> + .tx_irq = INT_44XX_MCBSP1_IRQ,
> .ops= &omap2_mcbsp_ops,
> },
> {
> .phys_base = OMAP44XX_MCBSP2_BASE,
> .dma_rx_sync= OMAP44XX_DMA_MCBSP2_RX,
> .dma_tx_sync= OMAP44XX_DMA_MCBSP2_TX,
> - .rx_irq = INT_24XX_MCBSP2_IRQ_RX,
> - .tx_irq = INT_24XX_MCBSP2_IRQ_TX,
> + .tx_irq = INT_44XX_MCBSP2_IRQ,
> .ops= &omap2_mcbsp_ops,
> },
> {
> .phys_base = OMAP44XX_MCBSP3_BASE,
> .dma_rx_sync= OMAP44XX_DMA_MCBSP3_RX,
> .dma_tx_sync= OMAP44XX_DMA_MCBSP3_TX,
> - .rx_irq = INT_24XX_MCBSP3_IRQ_RX,
> - .tx_irq = INT_24XX_MCBSP3_IRQ_TX,
> + .tx_irq = INT_44XX_MCBSP3_IRQ,
> .ops= &omap2_mcbsp_ops,
> },
> {
> .phys_base = OMAP44XX_MCBSP4_BASE,
> .dma_rx_sync= OMAP44XX_DMA_MCBSP4_RX,
> .dma_tx_sync= OMAP44XX_DMA_MCBSP4_TX,
> - .rx_irq = INT_24XX_MCBSP4_IRQ_RX,
> - .tx_irq = INT_24XX_MCBSP4_IRQ_TX,
> + .tx_irq = INT_44XX_MCBSP4_IRQ,
> .ops= &omap2_mcbsp_ops,
> },
> };
> diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
> index e1d0440..6e9660d 100644
> --- a/arch/arm/plat-omap/mcbsp.c
> +++ b/arch/arm/plat-omap/mcbsp.c
> @@ -724,14 +724,17 @@ int omap_mcbsp_request(unsigned int id)
> goto err_clk_disable;
> }
>
> - init_completion(&mcbsp->rx_irq_completion);
> - err = request_irq(mcbsp->rx_irq,
> omap_mcbsp_rx_irq_handler,
> + if (!cpu_is_omap44xx) {
> + init_completion(&mcbsp->rx_irq_completion);
> + err = request_irq(mcbsp->rx_irq,
> + omap_mcbsp_rx_irq_handler,
> 0, "McBSP", (void *)mcbsp);
How about using request_threaded_irq?
Refer to: http://lwn.net/Articles/302043/
-Manjunath--
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] ARM: OMAP4: Add support for omap4 in McBSP driver
McBSP module in OMAP4 needs to be able to set its tx/rx threshold
and enable the transmitter/receiver when starting an audio stream.
Signed-off-by: Jorge Eduardo Candelaria
Signed-off-by: Margarita Olaya Cabrera
---
arch/arm/plat-omap/mcbsp.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index 6e9660d..ea0c364 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -489,7 +489,7 @@ void omap_mcbsp_set_tx_threshold(unsigned int id, u16
threshold)
{
struct omap_mcbsp *mcbsp;
- if (!cpu_is_omap34xx())
+ if (!cpu_is_omap34xx() && !cpu_is_omap44xx())
return;
if (!omap_mcbsp_check_valid_id(id)) {
@@ -511,7 +511,7 @@ void omap_mcbsp_set_rx_threshold(unsigned int id, u16
threshold)
{
struct omap_mcbsp *mcbsp;
- if (!cpu_is_omap34xx())
+ if (!cpu_is_omap34xx() && !cpu_is_omap44xx())
return;
if (!omap_mcbsp_check_valid_id(id)) {
@@ -587,7 +587,7 @@ static inline void omap34xx_mcbsp_request(struct omap_mcbsp
*mcbsp)
* Enable wakup behavior, smart idle and all wakeups
* REVISIT: some wakeups may be unnecessary
*/
- if (cpu_is_omap34xx()) {
+ if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
u16 syscon;
syscon = MCBSP_READ(mcbsp, SYSCON);
@@ -610,7 +610,7 @@ static inline void omap34xx_mcbsp_free(struct omap_mcbsp
*mcbsp)
/*
* Disable wakup behavior, smart idle and all wakeups
*/
- if (cpu_is_omap34xx()) {
+ if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
u16 syscon;
syscon = MCBSP_READ(mcbsp, SYSCON);
@@ -859,7 +859,7 @@ void omap_mcbsp_start(unsigned int id, int tx, int rx)
MCBSP_WRITE(mcbsp, SPCR2, w | (1 << 7));
}
- if (cpu_is_omap2430() || cpu_is_omap34xx()) {
+ if (cpu_is_omap2430() || cpu_is_omap34xx() || cpu_is_omap44xx()) {
/* Release the transmitter and receiver */
w = MCBSP_READ_CACHE(mcbsp, XCCR);
w &= ~(tx ? XDISABLE : 0);
@@ -889,7 +889,7 @@ void omap_mcbsp_stop(unsigned int id, int tx, int rx)
/* Reset transmitter */
tx &= 1;
- if (cpu_is_omap2430() || cpu_is_omap34xx()) {
+ if (cpu_is_omap2430() || cpu_is_omap34xx() || cpu_is_omap44xx()) {
w = MCBSP_READ_CACHE(mcbsp, XCCR);
w |= (tx ? XDISABLE : 0);
MCBSP_WRITE(mcbsp, XCCR, w);
@@ -899,7 +899,7 @@ void omap_mcbsp_stop(unsigned int id, int tx, int rx)
/* Reset receiver */
rx &= 1;
- if (cpu_is_omap2430() || cpu_is_omap34xx()) {
+ if (cpu_is_omap2430() || cpu_is_omap34xx() || cpu_is_omap44xx) {
w = MCBSP_READ_CACHE(mcbsp, RCCR);
w |= (rx ? RDISABLE : 0);
MCBSP_WRITE(mcbsp, RCCR, w);
--
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/0] McBSP changes for OMAP4 platform
The following patches enable McBSP driver to be used along with the audio driver in SDP4430 and other OMAP4 based boards. Jorge Eduardo Candelaria (2): ARM: McBSP: Fix request for irq in OMAP4 ARM: OMAP4: Add support for omap4 in McBSP driver arch/arm/mach-omap2/mcbsp.c | 12 arch/arm/plat-omap/mcbsp.c | 34 +++--- 2 files changed, 23 insertions(+), 23 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: McBSP: Fix request for irq in OMAP4
In OMAP4, there is only one irq line for TX and RX paths. Use
the correct irq line to avoid errors at runtime.
Also, request irq line only once (instead of requesting for TX
and RX).
Signed-off-by: Jorge Eduardo Candelaria
---
arch/arm/mach-omap2/mcbsp.c | 12
arch/arm/plat-omap/mcbsp.c | 20
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index 2f3cad6..6b550ec 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -187,32 +187,28 @@ static struct omap_mcbsp_platform_data
omap44xx_mcbsp_pdata[] = {
.phys_base = OMAP44XX_MCBSP1_BASE,
.dma_rx_sync= OMAP44XX_DMA_MCBSP1_RX,
.dma_tx_sync= OMAP44XX_DMA_MCBSP1_TX,
- .rx_irq = INT_24XX_MCBSP1_IRQ_RX,
- .tx_irq = INT_24XX_MCBSP1_IRQ_TX,
+ .tx_irq = INT_44XX_MCBSP1_IRQ,
.ops= &omap2_mcbsp_ops,
},
{
.phys_base = OMAP44XX_MCBSP2_BASE,
.dma_rx_sync= OMAP44XX_DMA_MCBSP2_RX,
.dma_tx_sync= OMAP44XX_DMA_MCBSP2_TX,
- .rx_irq = INT_24XX_MCBSP2_IRQ_RX,
- .tx_irq = INT_24XX_MCBSP2_IRQ_TX,
+ .tx_irq = INT_44XX_MCBSP2_IRQ,
.ops= &omap2_mcbsp_ops,
},
{
.phys_base = OMAP44XX_MCBSP3_BASE,
.dma_rx_sync= OMAP44XX_DMA_MCBSP3_RX,
.dma_tx_sync= OMAP44XX_DMA_MCBSP3_TX,
- .rx_irq = INT_24XX_MCBSP3_IRQ_RX,
- .tx_irq = INT_24XX_MCBSP3_IRQ_TX,
+ .tx_irq = INT_44XX_MCBSP3_IRQ,
.ops= &omap2_mcbsp_ops,
},
{
.phys_base = OMAP44XX_MCBSP4_BASE,
.dma_rx_sync= OMAP44XX_DMA_MCBSP4_RX,
.dma_tx_sync= OMAP44XX_DMA_MCBSP4_TX,
- .rx_irq = INT_24XX_MCBSP4_IRQ_RX,
- .tx_irq = INT_24XX_MCBSP4_IRQ_TX,
+ .tx_irq = INT_44XX_MCBSP4_IRQ,
.ops= &omap2_mcbsp_ops,
},
};
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index e1d0440..6e9660d 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -724,14 +724,17 @@ int omap_mcbsp_request(unsigned int id)
goto err_clk_disable;
}
- init_completion(&mcbsp->rx_irq_completion);
- err = request_irq(mcbsp->rx_irq, omap_mcbsp_rx_irq_handler,
+ if (!cpu_is_omap44xx) {
+ init_completion(&mcbsp->rx_irq_completion);
+ err = request_irq(mcbsp->rx_irq,
+ omap_mcbsp_rx_irq_handler,
0, "McBSP", (void *)mcbsp);
- if (err != 0) {
- dev_err(mcbsp->dev, "Unable to request RX IRQ %d "
- "for McBSP%d\n", mcbsp->rx_irq,
- mcbsp->id);
- goto err_free_irq;
+ if (err != 0) {
+ dev_err(mcbsp->dev, "Unable to request RX IRQ
%d "
+ "for McBSP%d\n", mcbsp->rx_irq,
+ mcbsp->id);
+ goto err_free_irq;
+ }
}
}
@@ -781,7 +784,8 @@ void omap_mcbsp_free(unsigned int id)
if (mcbsp->io_type == OMAP_MCBSP_IRQ_IO) {
/* Free IRQs */
- free_irq(mcbsp->rx_irq, (void *)mcbsp);
+ if (!cpu_is_omap44xx())
+ free_irq(mcbsp->rx_irq, (void *)mcbsp);
free_irq(mcbsp->tx_irq, (void *)mcbsp);
}
--
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
[APPLIED] [PATCH] omap1: amsdelta: defconfig updates
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next Initial commit ID (Likely to change): a460e7aabb42c8dc6083dde6c21f49dd5806503a PatchWorks http://patchwork.kernel.org/patch/91091/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=a460e7aabb42c8dc6083dde6c21f49dd5806503a -- 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
[APPLIED] [PATCH 2/2] OMAP2/3: Add V4L2 DSS driver support in device.c
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next Initial commit ID (Likely to change): df8a77d5a4b80dbcbd5c401875e7427e0bb37450 PatchWorks http://patchwork.kernel.org/patch/90106/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=df8a77d5a4b80dbcbd5c401875e7427e0bb37450 -- 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: [Resubmit: PATCH-V2] AM3517: Add VPFE Capture driver support
* hvaib...@ti.com [100319 02:34]: > From: Vaibhav Hiremath > > AM3517 and DM644x uses same CCDC IP, so reusing the driver > for AM3517. > > Signed-off-by: Vaibhav Hiremath > --- > arch/arm/mach-omap2/board-am3517evm.c | 160 > + > 1 files changed, 160 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-omap2/board-am3517evm.c > b/arch/arm/mach-omap2/board-am3517evm.c > index f04311f..d2d2ced 100644 > --- a/arch/arm/mach-omap2/board-am3517evm.c > +++ b/arch/arm/mach-omap2/board-am3517evm.c > @@ -30,11 +30,164 @@ > > #include > #include > +#include > #include > #include > > +#include > +#include > + At least the mainline kernel does not seem to have media/ti-media/, so I'm not taking this. Looks like it should be safe to merge via linux-media from omap point of view. Acked-by: Tony Lindgren -- 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 v8 0/2] sDMA descriptor autoloading feature
> -Original Message- > From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of > Venkatraman S > Sent: Thursday, April 29, 2010 12:35 PM > To: linux-omap@vger.kernel.org; linux-...@vger.kernel.org; linux-arm- > ker...@lists.infradead.org > Cc: Madhusudhan Chikkature; Tony Lindgren; Adrian Hunter; Santosh > Shilimkar > Subject: [PATCH v8 0/2] sDMA descriptor autoloading feature > > This patch series is the introduction of new sDMA feature: descriptor > autoloading (v8) and it's adoption by the OMAP HSMMC driver. > >The previous version (v7) was blocked on achieving proper interrupt > syncronisation > between the MMC and DMA callback in the HSMMC driver. > Thanks to Adrian Hunter's patch, > https://patchwork.kernel.org/patch/94670/ > this has been cleaned up. > > Current version is based on for-next branch + Adrian Hunter's > interrupt syncronisation patch > (https://patchwork.kernel.org/patch/94670) > > Changes since v7: > * Removed the 'fix race condition between DMA and HSMMC callback' > part of the series > * Added memory barries in start and resume sglist transfer for cpu > buffer syncronization > * Cleanup and comments > > This has been tested on OMAP3430, OMAP3630 and OMAP4430 SDP > for MMC file transfer and as boot file system. > The HSMMC driver changes look good to me. I can ACK that but am not a DMA expert to review your changes to the DMA driver. > Venkatraman S: > sDMA: descriptor autoloading feature > MMC: omap hsmmc adoption of descriptor autoloading feature > > arch/arm/plat-omap/dma.c | 289 > - > arch/arm/plat-omap/include/plat/dma.h | 170 +++ > drivers/mmc/host/omap_hsmmc.c | 148 ++--- > 3 files changed, 583 insertions(+), 24 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
[APPLIED] [PATCH 4/4] AM3517 defconfig update : enable EMAC support
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next Initial commit ID (Likely to change): 08f6edf343289846d1c04fd53949cdf5f5ea4fc2 PatchWorks http://patchwork.kernel.org/patch/84920/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=08f6edf343289846d1c04fd53949cdf5f5ea4fc2 -- 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
[APPLIED] [PATCH 3/4] OMAP3 : clock data: Update name string for EMAC clocks.
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next Initial commit ID (Likely to change): 6cf3b367fffb3c56baa8fbb7e1f29718ff197dc7 PatchWorks http://patchwork.kernel.org/patch/84922/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=6cf3b367fffb3c56baa8fbb7e1f29718ff197dc7 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/5] OMAP4-HSMMC: Adding MMC-TWL regulator changes
Hello,
On Tue, 4 May 2010, kishore kadiyala wrote:
> This patch adds PBIAS Configuration during POWER ON and OFF.
> Also it adds MMC1 Card detect configuration on Phoenix
>
> Signed-off-by: Kishore Kadiyala
> ---
> arch/arm/mach-omap2/hsmmc.c | 121
> ++---
> arch/arm/plat-omap/include/plat/control.h | 17
> include/linux/i2c/twl.h | 42 +-
> 3 files changed, 166 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
> index f5ca16c..a73f011 100644
> --- a/arch/arm/mach-omap2/hsmmc.c
> +++ b/arch/arm/mach-omap2/hsmmc.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -25,6 +26,7 @@
>
> static u16 control_pbias_offset;
> static u16 control_devconf1_offset;
> +static u16 control_mmc1;
>
> #define HSMMC_NAME_LEN 9
>
> @@ -43,7 +45,7 @@ static int hsmmc_get_context_loss(struct device *dev)
> #define hsmmc_get_context_loss NULL
> #endif
>
> -static void hsmmc1_before_set_reg(struct device *dev, int slot,
> +static void omap_hsmmc1_before_set_reg(struct device *dev, int slot,
> int power_on, int vdd)
> {
> u32 reg, prog_io;
> @@ -96,7 +98,7 @@ static void hsmmc1_before_set_reg(struct device *dev, int
> slot,
> }
> }
>
> -static void hsmmc1_after_set_reg(struct device *dev, int slot,
> +static void omap_hsmmc1_after_set_reg(struct device *dev, int slot,
>int power_on, int vdd)
> {
> u32 reg;
> @@ -120,6 +122,61 @@ static void hsmmc1_after_set_reg(struct device *dev, int
> slot,
> }
> }
>
> +static void omap4_hsmmc1_before_set_reg(struct device *dev, int slot,
> + int power_on, int vdd)
> +{
> + u32 reg;
> +
> + /*
> + * Assume we power both OMAP VMMC1 (for CMD, CLK, DAT0..3) and the
> + * card with Vcc regulator (from twl4030 or whatever). OMAP has both
> + * 1.8V and 3.0V modes, controlled by the PBIAS register.
> + *
> + * In 8-bit modes, OMAP VMMC1A (for DAT4..7) needs a supply, which
> + * is most naturally TWL VSIM; those pins also use PBIAS.
> + *
> + * FIXME handle VMMC1A as needed ...
> + */
> + if (power_on) {
> + reg = omap_ctrl_readl(control_pbias_offset);
> + reg &= ~(OMAP4_MMC1_PBIASLITE_PWRDNZ | OMAP4_MMC1_PWRDNZ);
> + omap_ctrl_writel(reg, control_pbias_offset);
> + } else {
> + reg = omap_ctrl_readl(control_pbias_offset);
> + reg &= ~(OMAP4_MMC1_PBIASLITE_PWRDNZ | OMAP4_MMC1_PWRDNZ);
> + omap_ctrl_writel(reg, control_pbias_offset);
> + }
If the code in both branches of the conditional is identical, what's the
point of keeping the conditional?
> +}
> +
> +static void omap4_hsmmc1_after_set_reg(struct device *dev, int slot,
> + int power_on, int vdd)
> +{
> + u32 reg;
> +
> + /* 100ms delay required for PBIAS configuration */
> + msleep(100);
> +
> + if (power_on) {
> + reg = omap_ctrl_readl(control_pbias_offset);
> + reg |= OMAP4_MMC1_PBIASLITE_PWRDNZ;
> + if ((1 << vdd) <= MMC_VDD_165_195) {
> + reg &= ~OMAP4_MMC1_PBIASLITE_VMODE;
> + reg |= (OMAP4_MMC1_PBIASLITE_PWRDNZ |
> + OMAP4_MMC1_PWRDNZ);
> + } else {
> + reg |= (OMAP4_MMC1_PBIASLITE_VMODE |
> + OMAP4_MMC1_PBIASLITE_PWRDNZ |
> + OMAP4_MMC1_PWRDNZ);
> + }
> + omap_ctrl_writel(reg, control_pbias_offset);
> + } else {
> + reg = omap_ctrl_readl(control_pbias_offset);
> + reg |= (OMAP4_MMC1_PBIASLITE_PWRDNZ |
> + OMAP4_MMC1_PBIASLITE_VMODE | OMAP4_MMC1_PWRDNZ);
> + omap_ctrl_writel(reg, control_pbias_offset);
> + }
> +}
> +
> static void hsmmc23_before_set_reg(struct device *dev, int slot,
> int power_on, int vdd)
> {
> @@ -140,6 +197,24 @@ static void hsmmc23_before_set_reg(struct device *dev,
> int slot,
> }
> }
>
> +static int mmc_twl_late_init(struct device *dev)
> +{
> + int ret = 0;
> + struct platform_device *pdev = container_of(dev,
> + struct platform_device, dev);
> +
> + if (cpu_is_omap44xx()) {
> + /* MMC1 Card detect Configuration */
> + if (pdev->id == 0) {
> + ret = omap4_hsmmc1_card_detect_config();
> + if (ret < 0)
> + pr_err("Unable to configure"
> + "Card detect for MMC1\n");
> + }
> + }
> + return ret;
> +}
> +
> static struct omap_mmc_platform_data *hsmmc_data[OMAP34XX_NR_M
Re: [PATCH 02b/11] omap2/3: Fix DEBUG_LL for omap zoom2/3
* Pandita, Vikram [100504 10:29]: > > Tony > > >-Original Message- > >From: Tony Lindgren [mailto:t...@atomide.com] > >Sent: Monday, May 03, 2010 7:59 PM > >To: Pandita, Vikram > >Cc: Kevin Hilman; linux-arm-ker...@lists.infradead.org; linux- > >o...@vger.kernel.org; Pais, Allen > >Subject: [PATCH 02b/11] omap2/3: Fix DEBUG_LL for omap zoom2/3 > > > >And here's this patch one more time. Both 2a and 2b are needed > >for zoom debug uart to work. > > Test 1: > Tested on Zoom3 with 02a and 02b applied. Enabled DEBUG_LL. > Booted fine. > > Test 2: > Applied Hack printk.patch (attached) > Booted fine and duplicate logs can be seen on console => printascii is > working. > > Ack-by: Vikram Pandita Good to hear it works for you now, thanks for testing. 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 v2 4/5] OMAP4-HSMMC: Adds Dummy Interface clock's for MMC controllers
On Tue, 4 May 2010, kishore kadiyala wrote:
> This patch adds dummy Interface clocks for MMC controllers
>
> Signed-off-by: Kishore Kadiyala
Acked-by: Paul Walmsley
> ---
> arch/arm/mach-omap2/clock44xx_data.c |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock44xx_data.c
> b/arch/arm/mach-omap2/clock44xx_data.c
> index a5c0c9c..0280422 100644
> --- a/arch/arm/mach-omap2/clock44xx_data.c
> +++ b/arch/arm/mach-omap2/clock44xx_data.c
> @@ -2675,6 +2675,11 @@ static struct omap_clk omap44xx_clks[] = {
> CLK("omap2_mcspi.2","ick", &dummy_ck,
> CK_443X),
> CLK("omap2_mcspi.3","ick", &dummy_ck,
> CK_443X),
> CLK("omap2_mcspi.4","ick", &dummy_ck,
> CK_443X),
> + CLK("mmci-omap-hs.0", "ick", &dummy_ck, CK_443X),
> + CLK("mmci-omap-hs.1", "ick", &dummy_ck, CK_443X),
> + CLK("mmci-omap-hs.2", "ick", &dummy_ck, CK_443X),
> + CLK("mmci-omap-hs.3", "ick", &dummy_ck, CK_443X),
> + CLK("mmci-omap-hs.4", "ick", &dummy_ck, CK_443X),
> CLK(NULL, "uart1_ick",&dummy_ck,
> CK_443X),
> CLK(NULL, "uart2_ick",&dummy_ck,
> CK_443X),
> CLK(NULL, "uart3_ick",&dummy_ck,
> CK_443X),
- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add support for OMAP3Stalker boards
Hi,
Sorry for the delay in replying. Few comments, see below.
* Jason [100303 06:16]:
> This patche add omap3 board support for the EMA-Tech StalkerBoards. Base on
> TI's EVM.
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -82,6 +82,26 @@ config MACH_OMAP3517EVM
> depends on ARCH_OMAP3
> select OMAP_PACKAGE_CBB
>
> +config MACH_SBC3530
> + bool "OMAP3 SBC STALKER board"
> + depends on ARCH_OMAP3
> +
> +choice
> + prompt STALKER_BOARD_TYPE
> + depends on MACH_SBC3530
> + default STALKER_EVM
> +
> +config STALKER_BOARD_TYPE_EVM
> + bool "Stalker EVM board"
> + help
> + Select this option if you have a Stalker EVM board
> +
> +config STALKER_BOARD_TYPE_LK_S
> + bool "Stalker LK-S board"
> + help
> + Select this option if you have a Stalker LK-S board
> +endchoice
> +
> config MACH_OMAP3_PANDORA
> bool "OMAP3 Pandora"
> depends on ARCH_OMAP3
Things like this are best done by looking at the ATAG_REVISION passed by
the bootloader. Then you can dynamically initialize the platform data
based on the revision.
> --- /dev/null
> +++ b/arch/arm/mach-omap2/board-omap3stalker.c
> @@ -0,0 +1,922 @@
> +/*
> + * linux/arch/arm/mach-omap2/board-omap3evm.c
> + *
> + * Copyright (C) 2008 Guangzhou EMA-Tech
> + *
> + * Modified from mach-omap2/board-omap3evm.c
> + *
> + * Initial code: Syed Mohammed Khasim
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#if defined(CONFIG_STALKER_BOARD_TYPE_EVM)
> +#include
> +#elif defined(CONFIG_STALKER_BOARD_TYPE_LK_S)
We should not ifdef includes, it should be OK to include them automatically.
> +#include
> +#include
> +#include
> +#endif
> +
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "mux.h"
> +#include "sdram-micron-mt46h32m32lf-6.h"
> +#include "hsmmc.h"
> +#include "pm.h"
That's a lot of include files, are they all needed?
> +static struct mtd_partition omap3stalker_nand_partitions[] = {
> + /* All the partition sizes are listed in terms of NAND block size */
> + {
> + .name = "X-Loader",
> + .offset = 0,
> + .size = 4 * (SZ_128K),
> + .mask_flags = MTD_WRITEABLE,
> + },
> + {
> + .name = "U-Boot",
> + .offset = MTDPART_OFS_APPEND,
> + .size = 15 * (SZ_128K),
> + .mask_flags = MTD_WRITEABLE,
> + },
> + {
> + .name = "U-Boot Env",
> + .offset = MTDPART_OFS_APPEND,
> + .size = 1 * (SZ_128K)},
> + {
> + .name = "Kernel",
> + .offset = MTDPART_OFS_APPEND,
> + .size = 32 * (SZ_128K)},
> + {
> + .name = "File System",
> + .size = MTDPART_SIZ_FULL,
> + .offset = MTDPART_OFS_APPEND,
> + },
> +};
Please use tabs instead of spaces.
> +void __init omap3stalker_flash_init(void)
> +{
> + u8 cs = 0;
> + u8 nandcs = GPMC_CS_NUM + 1;
> + u32 gpmc_base_add = OMAP34XX_GPMC_VIRT;
Please leave out the NAND stuff for now, we need to first fix the
NAND driver before adding more of the OMAP34XX_GPMC_VIRT..
> +static struct resource omap3stalker_smsc911x_resources[] = {
> + [0] = {
> +.start = OMAP3STALKER_ETHR_START,
> +.end =
> +(OMAP3STALKER_ETHR_START + OMAP3STALKER_ETHR_SIZE - 1),
> +.flags = IORESOURCE_MEM,
> +},
> + [1] = {
> +.start = OMAP_GPIO_IRQ(OMAP3STALKER_ETHR_GPIO_IRQ),
> +.end = OMAP_GPIO_IRQ(OMAP3STALKER_ETHR_GPIO_IRQ),
> +.flags = (IORESOURCE_IRQ | IRQF_TRIGGER_LOW),
> +},
> +};
Please use tabs here too instead of spaces.
> +static struct omap2_hsmmc_info mmc[] = {
> + {
> + .mmc = 1,
> + .wires = 4,
> + .gpio_cd = -EINVAL,
> + .gpio_wp = 23,
> + },
> + {} /* Terminator */
> +};
> +
> +#if defined(CONFIG_STALKER_BOARD_TYPE_LK_S)
> +static struct gpio_keys_button gpio_buttons[] = {
> + {
> + .code = BTN_EXTRA,
> + .gpio = 18,
> + .desc = "user",
> + .wakeup = 1,
> + },
> +};
Here too.
> + .irq_base = TWL4030_IRQ_BASE,
> + .irq_end = TWL4030_IRQ_END,
> +
> + /* platform_data for children goes here */
> + .keypad = &omap3stalker_kp_data,
> + .madc = &omap3stalker_madc_data,
> + .usb = &omap3stalker_usb_data,
> + .gpio = &omap3stalker_gpio_data,
> + .codec = &omap3stalker_codec_data,
> + .vd
Re: [RFC/PATCHv2 1/4] gpiolib: introduce set_debounce method
* Mark Brown [100402 05:30]: > On Wed, Mar 31, 2010 at 06:35:09PM +0300, Felipe Balbi wrote: > > Few architectures, like OMAP, allow you to set > > a debouncing time for the gpio before generating > > the IRQ. Teach gpiolib about that. > > > > Signed-off-by: Felipe Balbi > > This looks useful - for what it's worth > > Acked-by: Mark Brown Ping, looks like this series is pretty close to being mergeable. Felipe, care to repost one more time without RFC and with the acks if you think you have updated version that's ready for the upcoming merge window. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/2] 32k-sync timer patches
* Felipe Balbi [100331 04:02]: > The following patches convert 32k-sync timer into a platform_driver > and also remove dead code from timer32k.c > > If anyone has a good idea on how to fix-up timer-gp.c, I'll be > glad to hear. Currently I can't move it to platform_driver > because it's used the system timer during machine start so I can't > find a proper location to register the platform_device. If we don't > register a system timer, we will loop forever trying to calibrate > the delay loop. > > The patches were boot tested on rx51 and compile tested with > omap_h2_1610_defconfig. Ping, looks like this series is pretty close to being mergeable? Marking as RFC and archived in patchwork, please repost to get without RFC flags and the acks if you think we're should merge these changes. 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
[APPLIED] [PATCH v2 2/2] can:ti_hecc: Enable CAN support on AM3517.
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next Initial commit ID (Likely to change): 7241145120e803b600fc5aa1ef911c80ab68d1d5 PatchWorks http://patchwork.kernel.org/patch/82312/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=7241145120e803b600fc5aa1ef911c80ab68d1d5 -- 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
Upcoming merge window and omap NAND patches
Hi all, There are several omap NAND patches pending, but some basic things should be fixed first. 1. The NAND driver needs to stop tinkering with the GPMC registers The omap General Purpose Memory Controller (GPMC) registers are omap specific, and not driver specific. Tinkering with these registers can cause issues with the other devices on the GPMC. To find out what needs to disappear fomr the NAND driver, just do: $ grep baseaddr drivers/mtd/nand/omap2.c Any GPMC register tinkering needs to happen in arch/arm/mach-omap2/gpmc.c. If there are not currently GPMC functions to do something in gpmc.c, then let's add the necessary support there. 2. Passing hardcoded GPMC_CS0_BASE needs to go from the board files Passing hardcoded GPMC virtual addressess is sure way to mess up things. This should all become unnecessary once the NAND drivers stops messing with the GPMC registers directly. So, as a result, I'm not planning on pushing any omap NAND related patches until these basic issues are fixed. I'll mark these patches as "Changes requested" in patchwork.kernel.org even if these patches don't have anything else wrong with them. Let's fix the basic things for good, and put the other patches on hold for a while. Sorry if this causes problems! Cheers, 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 v2 3/3] omap: gpmc-nand: add ability to keep timings defined by the bootloader
* Mike Rapoport [100504 06:19]: > Tony Lindgren wrote: > >* Mike Rapoport [100503 13:28]: > > >>So it comes down to what provides better tolerance, the explicit NAND > >>timings in nanosecs or (rounded) timings in ticks derived from > >>bootloader settings... > > > >My experience is that you can get the nanosec timings from the device > >datasheet(s) and that just should work for any L3 frequency. > > And what about boards that can have different NAND flash chips > assembled? What datasheet should be used to get the nanosecs? Note, > that detecting NAND ID in the bootloader and adjusting timings > appropriately is not that big deal, and doing it in the kernel seems > to me really impractical. Hmm, if there are different variations of the same board, the best way is to pass ATAG_REVISION from the bootloader. Then you can set the selected NAND platform data based on the revision. > >My experience is also that trying to do it the other way around won't work > >because of rounding errors. Trying to produce nanosecond values out > >of the tick values just is not accurate enough. > > I'm still not convinced. Similar approach worked for me with several > devices attached to sort of GPMC controllers on different SoC. There > always was a way to set timings once in the bootloader and then > detect the timings in the kernel and update them during cpu-freq > transitions... Not based on my experience with GPMC and L3.. When converting from GPMC ticks to nanosecond timings, you're losing accuracy so things won't scale the right way if you scale L3 frequency. > >That's why gpmc-onenand.c and usb-tusb6010.c timings are done the way > >they are, and they're known to work at various L3 frequencies. > > I'm not really familiar with OneNAND, but looking at gpmc-onenand.c I > see hardcoded timings. Moreover, the nanosecs values seem to get > adjusted for different L3 frequencies. Yeah, you need to look at the L3 frequency to calculate the timings. > So, for NAND it would mean that platform would have to supply > several timing sets for different L3 freqs? Not needed if the GPMC tick timings are calculated based on the device datasheet nanosecond timings and omap L3 frequency. Then it scales for all L3 frequencies. In any case, we still need to also allow using hardcoded bootloader timings for people who don't care about the L3 scaling. But there are other more serious things badly broken with the whole gpmc-nand and drivers/mtd/nand/omap2.c, I'll send another email about that shortly. 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 v4 4/5(7)] input: serio: add support for Amstrad Delta serial keyboard port
On Tue, May 04, 2010 at 09:48:36PM +0100, Russell King - ARM Linux wrote: > On Tue, May 04, 2010 at 01:40:41PM -0700, Tony Lindgren wrote: > > * Janusz Krzysztofik [100427 18:09]: > > > The patch introduces a serio driver that supports a keyboard serial port > > > found > > > on the Amstrad Delta videophone board. > > > > > > After initializing the hardware, the driver reads its input data from a > > > buffer > > > filled in by the board FIQ (Fast Interrupt Request) handler. > > > > > > Standard AT keyboard driver (atkbd) will be used on top of the serio > > > layer for > > > handling the E3 keyboard (called mailboard) connected to the port. Since > > > the > > > device generated scancodes differ from what the atkbd expects, a custom > > > key > > > code to scan code table must be loaded from userspace for the keyboard to > > > be > > > useable. > > What's the rationale for this approach? There's no requirement for the > atkbd driver to be used for all keyboards. It seems very obscure (and > backward) way to do things. > > Why not implement the serio driver for the IO level, and a separate > keyboard driver which can handle the protocol and interpret the > scancodes? Because it is AT-like keyboard with messed up scancodes, it responds to our probes as a regular keyboard so we can't auto-select proper keymap. If you were to connect a standard PS/2 keyboard to E3 port it would work without any special keymap. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/5(7)] input: serio: add support for Amstrad Delta serial keyboard port
On Tue, May 04, 2010 at 01:40:41PM -0700, Tony Lindgren wrote: > * Janusz Krzysztofik [100427 18:09]: > > The patch introduces a serio driver that supports a keyboard serial port > > found > > on the Amstrad Delta videophone board. > > > > After initializing the hardware, the driver reads its input data from a > > buffer > > filled in by the board FIQ (Fast Interrupt Request) handler. > > > > Standard AT keyboard driver (atkbd) will be used on top of the serio layer > > for > > handling the E3 keyboard (called mailboard) connected to the port. Since > > the > > device generated scancodes differ from what the atkbd expects, a custom key > > code to scan code table must be loaded from userspace for the keyboard to > > be > > useable. What's the rationale for this approach? There's no requirement for the atkbd driver to be used for all keyboards. It seems very obscure (and backward) way to do things. Why not implement the serio driver for the IO level, and a separate keyboard driver which can handle the protocol and interpret the scancodes? -- 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
[APPLIED] [PATCH 9/9] OMAP: Devkit8000: Update default configuration
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next Initial commit ID (Likely to change): ee013946a0498f58271d88af417c033accb4ecae PatchWorks http://patchwork.kernel.org/patch/87903/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=ee013946a0498f58271d88af417c033accb4ecae -- 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
[APPLIED] [PATCH 8/9] OMAP: Devkit8000: Add mux initialization
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Branch in linux-omap: for-next Initial commit ID (Likely to change): 4725af90aa4076cdaed975a5a13b4fc512635265 PatchWorks http://patchwork.kernel.org/patch/87902/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=4725af90aa4076cdaed975a5a13b4fc512635265 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/5(7)] input: serio: add support for Amstrad Delta serial keyboard port
* Janusz Krzysztofik [100427 18:09]: > The patch introduces a serio driver that supports a keyboard serial port found > on the Amstrad Delta videophone board. > > After initializing the hardware, the driver reads its input data from a buffer > filled in by the board FIQ (Fast Interrupt Request) handler. > > Standard AT keyboard driver (atkbd) will be used on top of the serio layer > for > handling the E3 keyboard (called mailboard) connected to the port. Since the > device generated scancodes differ from what the atkbd expects, a custom key > code to scan code table must be loaded from userspace for the keyboard to be > useable. > > Compiles and works on top of PATCH v4 3/5(7), "OMAP1: Amstrad Delta: use FIQ > for processing GPIO interrupts". I'll add this series into omap for-next. Will also add Dmitry's ack from the earlier series to this patch. 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/4] OMAP4: SPI: Fix Driver Kconfig
* Arce, Abraham [100422 07:39]: > From: Syed Rafiuddin > > Add OMAP4 data to allow McSPI driver built > > Signed-off-by: Syed Rafiuddin > Signed-off-by: Shubhro > Signed-off-by: Santosh Shilimkar > Signed-off-by: Abraham Arce > --- > drivers/spi/Kconfig |6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig > index a191fa2..5f54235 100644 > --- a/drivers/spi/Kconfig > +++ b/drivers/spi/Kconfig > @@ -180,10 +180,10 @@ config SPI_OMAP_UWIRE > This hooks up to the MicroWire controller on OMAP1 chips. > > config SPI_OMAP24XX > - tristate "McSPI driver for OMAP24xx/OMAP34xx" > - depends on ARCH_OMAP2 || ARCH_OMAP3 > + tristate "McSPI driver for OMAP24xx/OMAP34xx/OMAP44xx" > + depends on ARCH_OMAP24XX || ARCH_OMAP34XX || ARCH_OMAP4 > help > - SPI master controller for OMAP24xx/OMAP34xx Multichannel SPI > + SPI master controller for OMAP24xx/OMAP34xx/OMAP44xx Multichannel SPI > (McSPI) modules. > > config SPI_OMAP_100K You can simplify this and make it more future proof with something like: config SPI_OMAP24XX tristate "McSPI driver for OMAP" depends on ARCH_OMAP2PLUS help SPI master controller for OMAP24XX and later 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 11/11] omap2/3/4: Disable CONFIG_FB_OMAP in omap3_defconfig
* Tomi Valkeinen [100504 07:45]: > On Tue, 2010-05-04 at 16:40 +0200, ext Tony Lindgren wrote: > > * Tomi Valkeinen [100504 00:21]: > > > Hi, > > > > > > On Tue, 2010-05-04 at 02:52 +0200, ext Tony Lindgren wrote: > > > > * Tony Lindgren [100430 13:47]: > > > > > * Tony Lindgren [100430 13:32]: > > > > > > Looks like CONFIG_FB_OMAP prevents somehow mounting root on MMC > > > > > > at least on zoom3 for multi-omap. Disable CONFIG_FB until the > > > > > > omap FB code is fixed. > > > > > > > > > > This one I'll drop as soon as the problem is sorted out with > > > > > CONFIG_FB_OMAP. > > > > > > > > This one seems to be something under drivers/video/omap, so > > > > I'll change CONFIG_FB_OMAP to be a module now. Updated patch > > > > below. > > > > > > > > I'll update omap for-next accordingly, then Tomi can figure > > > > it out :) > > > > > > This sounds... interesting... =) Any more info on what happens? Does it > > > also affect new omapfb driver? > > > > Yeah this is interesting, it seems like the kernel cmdline gets > > somehow corrupted for zoom3 with the omap3_defconfig if CONFIG_FB_OMAP=y. > > Some options seem to be there, but for example rootwait option is > > ignored and the root on MMC never mounts. This is in the current > > omap for-next branch. > > Ok, so the cmdline parsing in omapfb could be broken. I'll check it out. OK thanks. Hmm, it could be that it works on n8x0 and n900 because they are using the kernel built in cmdline. > > Hmm, what do you mean with "new omapfb" driver, the stuff you have > > queued up? > > No, I mean the DSS2 version. drivers/video/omap is the old one, written > mostly by Imre, and drivers/video/omap2 is the new one, written mostly > by me. > > I guess most boards are still using the old omapfb driver. Ah I see, it does not have CONFIG_FB_OMAP2 set. I did a quick test with that and the bootloader passed cmdline on zoom3 works just fine. I used the options below. Nothing on the LCD panel on zoom or n900 though, I guess some updates are still needed for that. Regards, Tony --- a/arch/arm/configs/omap3_defconfig +++ b/arch/arm/configs/omap3_defconfig @@ -1385,17 +1385,36 @@ CONFIG_FB_TILEBLITTING=y # CONFIG_FB_METRONOME is not set # CONFIG_FB_MB862XX is not set # CONFIG_FB_BROADSHEET is not set -CONFIG_FB_OMAP=y CONFIG_FB_OMAP_LCD_VGA=y # CONFIG_FB_OMAP_031M3R is not set # CONFIG_FB_OMAP_048M3R is not set -CONFIG_FB_OMAP_079M3R=y +# CONFIG_FB_OMAP_079M3R is not set # CONFIG_FB_OMAP_092M9R is not set -# CONFIG_FB_OMAP_LCDC_EXTERNAL is not set -# CONFIG_FB_OMAP_LCD_MIPID is not set # CONFIG_FB_OMAP_BOOTLOADER_INIT is not set -CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE=2 -# CONFIG_OMAP2_DSS is not set +CONFIG_OMAP2_VRAM=y +CONFIG_OMAP2_VRFB=y +CONFIG_OMAP2_DSS=y +CONFIG_OMAP2_VRAM_SIZE=0 +CONFIG_OMAP2_DSS_DEBUG_SUPPORT=y +# CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS is not set +# CONFIG_OMAP2_DSS_RFBI is not set +CONFIG_OMAP2_DSS_VENC=y +# CONFIG_OMAP2_DSS_SDI is not set +# CONFIG_OMAP2_DSS_DSI is not set +# CONFIG_OMAP2_DSS_FAKE_VSYNC is not set +CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK=0 +CONFIG_FB_OMAP2=y +CONFIG_FB_OMAP2_DEBUG_SUPPORT=y +CONFIG_FB_OMAP2_NUM_FBS=3 + +# +# OMAP2/3 Display Device Drivers +# +CONFIG_PANEL_GENERIC=y +CONFIG_PANEL_SHARP_LS037V7DW01=y +CONFIG_PANEL_SHARP_LQ043T1DG01=y +CONFIG_PANEL_TOPPOLY_TDO35S=y +CONFIG_PANEL_TPO_TD043MTEA1=y CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=y # CONFIG_LCD_L4F00242T03 is not set
Re: [PATCH v2 1/2] omap: pm34xx: Enable IO / IO-CHAIN wakeups for PER
Mike Chan writes: > On Mon, May 3, 2010 at 4:35 PM, Kevin Hilman > wrote: >> Mike Chan writes: >> >>> IO events can also come from GPIO modules, which reside in the PER domain. >>> It is possible for the PER to enter RET while CORE is still in ON. >>> If GPIO 2-6 are enabled for IO-pad wakeups, the PER domain will not >>> wakeup in this case, unless we enable it. >>> >>> Signed-off-by: Mike Chan >> >> Thanks, adding both patches to PM branch (pm-fixes branch) and will >> queue for 2.6.35. >> > > Thanks, with this patch looking good, I was hoping for some feedback > from people on the 2nd patch in the series. It makes sense to me since > PER will be woken up now, not just CORE, but I wanted to double check. It makes sense to me too, I've applied both to the pm-fixes branch. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: new PM branch: OPP layer included
On Fri, 2010-04-23 at 16:23 -0700, Kevin Hilman wrote: [...] > Smart Reflex: > > Thara's v3 series available as pm-wip-sr. This is now based directly > on the new PM branch instead of on pm-wip-opp. > > NOTE: the hwmod patches are now merged into l-o (omap-fixes branch) > so they are no longer in pm-wip-sr. Just to clarify... The hwmod patches I was referring to here are the hwmod fixes from Thara, not the pm-wip/hwmods branch. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 02b/11] omap2/3: Fix DEBUG_LL for omap zoom2/3
Tony >-Original Message- >From: Tony Lindgren [mailto:t...@atomide.com] >Sent: Monday, May 03, 2010 7:59 PM >To: Pandita, Vikram >Cc: Kevin Hilman; linux-arm-ker...@lists.infradead.org; linux- >o...@vger.kernel.org; Pais, Allen >Subject: [PATCH 02b/11] omap2/3: Fix DEBUG_LL for omap zoom2/3 > >And here's this patch one more time. Both 2a and 2b are needed >for zoom debug uart to work. Test 1: Tested on Zoom3 with 02a and 02b applied. Enabled DEBUG_LL. Booted fine. Test 2: Applied Hack printk.patch (attached) Booted fine and duplicate logs can be seen on console => printascii is working. Ack-by: Vikram Pandita > >Regards, > >Tony printk.patch Description: printk.patch
[PATCH v2 5/5] OMAP4-HSMMC: Enabling MMC support in OMAP4430SDP defconfig
Enabling MMC support on OMAP4430 defconfig Signed-off-by: Kishore Kadiyala --- arch/arm/configs/omap_4430sdp_defconfig | 19 ++- 1 files changed, 18 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/omap_4430sdp_defconfig b/arch/arm/configs/omap_4430sdp_defconfig index babf4c2..db85cd6 100644 --- a/arch/arm/configs/omap_4430sdp_defconfig +++ b/arch/arm/configs/omap_4430sdp_defconfig @@ -706,7 +706,24 @@ CONFIG_DUMMY_CONSOLE=y # CONFIG_SOUND is not set # CONFIG_HID_SUPPORT is not set # CONFIG_USB_SUPPORT is not set -# CONFIG_MMC is not set +CONFIG_MMC=y +# CONFIG_MMC_DEBUG is not set +# CONFIG_MMC_UNSAFE_RESUME is not set + +# +# MMC/SD/SDIO Card Drivers +# +CONFIG_MMC_BLOCK=y +CONFIG_MMC_BLOCK_BOUNCE=y +# CONFIG_SDIO_UART is not set +# CONFIG_MMC_TEST is not set + +# +# MMC/SD/SDIO Host Controller Drivers +# +# CONFIG_MMC_SDHCI is not set +# CONFIG_MMC_OMAP is not set +CONFIG_MMC_OMAP_HS=y # CONFIG_MEMSTICK is not set # CONFIG_NEW_LEDS is not set # CONFIG_ACCESSIBILITY is not set -- 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 v2 4/5] OMAP4-HSMMC: Adds Dummy Interface clock's for MMC controllers
This patch adds dummy Interface clocks for MMC controllers
Signed-off-by: Kishore Kadiyala
---
arch/arm/mach-omap2/clock44xx_data.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index a5c0c9c..0280422 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -2675,6 +2675,11 @@ static struct omap_clk omap44xx_clks[] = {
CLK("omap2_mcspi.2","ick", &dummy_ck,
CK_443X),
CLK("omap2_mcspi.3","ick", &dummy_ck,
CK_443X),
CLK("omap2_mcspi.4","ick", &dummy_ck,
CK_443X),
+ CLK("mmci-omap-hs.0", "ick", &dummy_ck, CK_443X),
+ CLK("mmci-omap-hs.1", "ick", &dummy_ck, CK_443X),
+ CLK("mmci-omap-hs.2", "ick", &dummy_ck, CK_443X),
+ CLK("mmci-omap-hs.3", "ick", &dummy_ck, CK_443X),
+ CLK("mmci-omap-hs.4", "ick", &dummy_ck, CK_443X),
CLK(NULL, "uart1_ick",&dummy_ck,
CK_443X),
CLK(NULL, "uart2_ick",&dummy_ck,
CK_443X),
CLK(NULL, "uart3_ick",&dummy_ck,
CK_443X),
--
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 v2 3/5] OMAP4-HSMMC: Adding MMC-TWL regulator changes
This patch adds PBIAS Configuration during POWER ON and OFF.
Also it adds MMC1 Card detect configuration on Phoenix
Signed-off-by: Kishore Kadiyala
---
arch/arm/mach-omap2/hsmmc.c | 121 ++---
arch/arm/plat-omap/include/plat/control.h | 17
include/linux/i2c/twl.h | 42 +-
3 files changed, 166 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index f5ca16c..a73f011 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -25,6 +26,7 @@
static u16 control_pbias_offset;
static u16 control_devconf1_offset;
+static u16 control_mmc1;
#define HSMMC_NAME_LEN 9
@@ -43,7 +45,7 @@ static int hsmmc_get_context_loss(struct device *dev)
#define hsmmc_get_context_loss NULL
#endif
-static void hsmmc1_before_set_reg(struct device *dev, int slot,
+static void omap_hsmmc1_before_set_reg(struct device *dev, int slot,
int power_on, int vdd)
{
u32 reg, prog_io;
@@ -96,7 +98,7 @@ static void hsmmc1_before_set_reg(struct device *dev, int
slot,
}
}
-static void hsmmc1_after_set_reg(struct device *dev, int slot,
+static void omap_hsmmc1_after_set_reg(struct device *dev, int slot,
int power_on, int vdd)
{
u32 reg;
@@ -120,6 +122,61 @@ static void hsmmc1_after_set_reg(struct device *dev, int
slot,
}
}
+static void omap4_hsmmc1_before_set_reg(struct device *dev, int slot,
+ int power_on, int vdd)
+{
+ u32 reg;
+
+ /*
+* Assume we power both OMAP VMMC1 (for CMD, CLK, DAT0..3) and the
+* card with Vcc regulator (from twl4030 or whatever). OMAP has both
+* 1.8V and 3.0V modes, controlled by the PBIAS register.
+*
+* In 8-bit modes, OMAP VMMC1A (for DAT4..7) needs a supply, which
+* is most naturally TWL VSIM; those pins also use PBIAS.
+*
+* FIXME handle VMMC1A as needed ...
+*/
+ if (power_on) {
+ reg = omap_ctrl_readl(control_pbias_offset);
+ reg &= ~(OMAP4_MMC1_PBIASLITE_PWRDNZ | OMAP4_MMC1_PWRDNZ);
+ omap_ctrl_writel(reg, control_pbias_offset);
+ } else {
+ reg = omap_ctrl_readl(control_pbias_offset);
+ reg &= ~(OMAP4_MMC1_PBIASLITE_PWRDNZ | OMAP4_MMC1_PWRDNZ);
+ omap_ctrl_writel(reg, control_pbias_offset);
+ }
+}
+
+static void omap4_hsmmc1_after_set_reg(struct device *dev, int slot,
+int power_on, int vdd)
+{
+ u32 reg;
+
+ /* 100ms delay required for PBIAS configuration */
+ msleep(100);
+
+ if (power_on) {
+ reg = omap_ctrl_readl(control_pbias_offset);
+ reg |= OMAP4_MMC1_PBIASLITE_PWRDNZ;
+ if ((1 << vdd) <= MMC_VDD_165_195) {
+ reg &= ~OMAP4_MMC1_PBIASLITE_VMODE;
+ reg |= (OMAP4_MMC1_PBIASLITE_PWRDNZ |
+ OMAP4_MMC1_PWRDNZ);
+ } else {
+ reg |= (OMAP4_MMC1_PBIASLITE_VMODE |
+ OMAP4_MMC1_PBIASLITE_PWRDNZ |
+ OMAP4_MMC1_PWRDNZ);
+ }
+ omap_ctrl_writel(reg, control_pbias_offset);
+ } else {
+ reg = omap_ctrl_readl(control_pbias_offset);
+reg |= (OMAP4_MMC1_PBIASLITE_PWRDNZ |
+ OMAP4_MMC1_PBIASLITE_VMODE | OMAP4_MMC1_PWRDNZ);
+ omap_ctrl_writel(reg, control_pbias_offset);
+ }
+}
+
static void hsmmc23_before_set_reg(struct device *dev, int slot,
int power_on, int vdd)
{
@@ -140,6 +197,24 @@ static void hsmmc23_before_set_reg(struct device *dev, int
slot,
}
}
+static int mmc_twl_late_init(struct device *dev)
+{
+ int ret = 0;
+ struct platform_device *pdev = container_of(dev,
+ struct platform_device, dev);
+
+ if (cpu_is_omap44xx()) {
+ /* MMC1 Card detect Configuration */
+ if (pdev->id == 0) {
+ ret = omap4_hsmmc1_card_detect_config();
+ if (ret < 0)
+ pr_err("Unable to configure"
+ "Card detect for MMC1\n");
+ }
+ }
+ return ret;
+}
+
static struct omap_mmc_platform_data *hsmmc_data[OMAP34XX_NR_MMC] __initdata;
void __init omap2_hsmmc_init(struct omap2_hsmmc_info *controllers)
@@ -147,13 +222,28 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
struct omap2_hsmmc_info *c;
int nr_hsmmc = ARRAY_SIZE(hsmmc_data);
int i;
+ u32 reg;
- if (cpu_is_omap2430()) {
-
[PATCH v2 2/5] OMAP4-HSMMC: Adding Card detect support
In OMAP4, card detect interrupt is provided by Phoenix and also
card status is provided by MMCCTRL register of Phoenix.
Since OMAP4's card detection doesn't support GPIO,this patch
basically adds a flag which can differentiate whether the
card-detect line is GPIO or NON-GPIO based.
Signed-off-by: Kishore Kadiyala
---
arch/arm/mach-omap2/board-4430sdp.c |1 +
arch/arm/mach-omap2/hsmmc.c |2 ++
arch/arm/mach-omap2/hsmmc.h |1 +
arch/arm/plat-omap/include/plat/mmc.h |2 ++
drivers/mfd/twl6030-irq.c | 27 +++
drivers/mmc/host/omap_hsmmc.c | 18 +-
include/linux/i2c/twl.h |6 ++
7 files changed, 56 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index c4e61d5..41fbffe 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -102,6 +102,7 @@ static struct omap2_hsmmc_info mmc[] = {
* but is a phoenix interrupt
*/
.gpio_cd= TWL6030_IRQ_BASE + MMCDETECT_INTR_OFFSET,
+ .cd_type= true,
.gpio_wp= -EINVAL,
},
{
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 9ad2295..f5ca16c 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -189,6 +190,7 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
mmc->get_context_loss_count = hsmmc_get_context_loss;
mmc->slots[0].switch_pin = c->gpio_cd;
+ mmc->slots[0].nongpio_cd = c->cd_type;
mmc->slots[0].gpio_wp = c->gpio_wp;
mmc->slots[0].remux = c->remux;
diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
index 36f0ba8..3dfc43a 100644
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -17,6 +17,7 @@ struct omap2_hsmmc_info {
boolno_off; /* power_saving and power is not to go off */
boolvcc_aux_disable_is_sleep; /* Regulator off remapped to sleep */
int gpio_cd;/* or -EINVAL */
+ boolcd_type;/* Card detect Type:NON-GPIO=true,GPIO=flase */
int gpio_wp;/* or -EINVAL */
char*name; /* or NULL for default */
struct device *dev; /* returned: pointer to mmc adapter */
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index a1bac07..8458a8b 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
@@ -103,6 +104,7 @@ struct omap_mmc_platform_data {
unsigned vcc_aux_disable_is_sleep:1;
int switch_pin; /* gpio (card detect) */
+ unsigned nongpio_cd:1; /* NON-GPIO=true , GPIO=false */
int gpio_wp;/* gpio (write protect) */
int (*set_bus_mode)(struct device *dev, int slot, int bus_mode);
diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index 10bf228..da3d4ec 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
/*
* TWL6030 (unlike its predecessors, which had two level interrupt handling)
@@ -223,6 +224,32 @@ int twl6030_interrupt_mask(u8 bit_mask, u8 offset)
}
EXPORT_SYMBOL(twl6030_interrupt_mask);
+int twl6030_mmc_card_detect(struct device *dev, int slot)
+{
+ int ret = -ENOSYS;
+ int res = 0;
+ u8 read_reg;
+ struct platform_device *pdev = container_of(dev,
+ struct platform_device, dev);
+
+ switch (pdev->id) {
+ case 0:
+ /*
+* BIT0 of REG_MMC_CTRL
+* 0 - Card not present ,1 - Card present
+*/
+ res = twl_i2c_read_u8(TWL6030_MODULE_ID0,
+ &read_reg, TWL6030_MMCCTRL);
+ if (res >= 0)
+ ret = read_reg & 0x1;
+ break;
+ default:
+ pr_err("Unkown MMC controller %d in %s\n", pdev->id, __func__);
+ }
+ return ret;
+}
+EXPORT_SYMBOL(twl6030_mmc_card_detect);
+
int twl6030_init_irq(int irq_num, unsigned irq_base, unsigned irq_end)
{
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e9caf69..ac903b0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -505,6 +505,18 @@ err_free_sp:
return ret;
}
+static int omap_hsmmc_non_gpio_init(struct omap_mmc_platform_data *pdata)
+{
+ if (pdata->slots[0].switch_pin) {
+ pdata->suspend = omap_hsmmc_suspend_cd
[PATCH v2 1/5] OMAP4-HSMMC: Adding HSMMC support for OMAP4430 Board file
This patch adds MMC1 and MMC2 Controller data for OMAP4430 Board
file.
Signed-off-by: Kishore Kadiyala
---
arch/arm/mach-omap2/Makefile|3 +-
arch/arm/mach-omap2/board-4430sdp.c | 39 --
2 files changed, 34 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ffe600a..65d8d11 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -140,7 +140,8 @@ obj-$(CONFIG_MACH_IGEP0020) += board-igep0020.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o \
hsmmc.o
-obj-$(CONFIG_MACH_OMAP_4430SDP)+= board-4430sdp.o
+obj-$(CONFIG_MACH_OMAP_4430SDP)+= board-4430sdp.o \
+ hsmmc.o
obj-$(CONFIG_MACH_OMAP3517EVM) += board-am3517evm.o
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index f1b9708..c4e61d5 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include "hsmmc.h"
#define ETHERNET_KS8851_IRQ34
#define ETHERNET_KS8851_POWER_ENABLE 48
@@ -93,16 +94,27 @@ static struct omap_musb_board_data musb_board_data = {
.power = 100,
};
-static struct regulator_consumer_supply sdp4430_vmmc_supply[] = {
+static struct omap2_hsmmc_info mmc[] = {
{
- .supply = "vmmc",
+ .mmc= 1,
+ .wires = 8,
+ /* "mmc0_cd" is not a gpio interrupt
+* but is a phoenix interrupt
+*/
+ .gpio_cd= TWL6030_IRQ_BASE + MMCDETECT_INTR_OFFSET,
+ .gpio_wp= -EINVAL,
},
{
- .supply = "vmmc",
- },
- {
- .supply = "vmmc",
+ .mmc= 2,
+ .wires = 8,
+ .gpio_cd= -EINVAL,
+ .gpio_wp= -EINVAL,
+ .nonremovable = true,
},
+ {} /* Terminator */
+};
+
+static struct regulator_consumer_supply sdp4430_vmmc_supply[] = {
{
.supply = "vmmc",
},
@@ -111,6 +123,18 @@ static struct regulator_consumer_supply
sdp4430_vmmc_supply[] = {
},
};
+static int __init sdp4430_mmc_init(void)
+{
+ omap2_hsmmc_init(mmc);
+
+ /* link regulators to MMC adapters ... we "know" the
+* regulators will be set up only *after* we return.
+*/
+ sdp4430_vmmc_supply[0].dev = mmc[0].dev;
+ sdp4430_vmmc_supply[1].dev = mmc[1].dev;
+ return 0;
+}
+
static struct regulator_init_data sdp4430_vaux1 = {
.constraints = {
.min_uV = 100,
@@ -162,7 +186,7 @@ static struct regulator_init_data sdp4430_vmmc = {
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
- .num_consumer_supplies = 5,
+ .num_consumer_supplies = 2,
.consumer_supplies = sdp4430_vmmc_supply,
};
@@ -281,6 +305,7 @@ static void __init omap_4430sdp_init(void)
omap4_i2c_init();
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
omap_serial_init();
+ sdp4430_mmc_init();
/* OMAP4 SDP uses internal transceiver so register nop transceiver */
usb_nop_xceiv_register();
/* FIXME: allow multi-omap to boot until musb is updated for omap4 */
--
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 v2 0/5] Adding MMC Support on OMAP4430 SDP
Adding board and regulator support for MMC1 and MMC2 controllers on OMAP4. V2: - Rebased to Mainline version 2.6.34-rc6 - The Patch series has dependencies on I2c and Regulator support posted earlier [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26256.html [2] http://www.mail-archive.com/linux-...@vger.kernel.org/msg02755.html [3] https://patchwork.kernel.org/patch/94054/ - Tested on both OMAP4430 SDP and OMAP3430 SDP [Also omap_hsmmc.c as Kernel Module] V1: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg26858.html Kishore Kadiyala (5): OMAP4-HSMMC: Adding HSMMC support for OMAP4430 Board file OMAP4-HSMMC: Adding Card detect support OMAP4-HSMMC: Addind MMC-TWL regulator changes OMAP4-HSMMC: Adds Dummy Interface clock's for MMC controllers OMAP4-HSMMC: Enabling MMC support in OMAP4430SDP defconfig arch/arm/configs/omap_4430sdp_defconfig | 19 - arch/arm/mach-omap2/Makefile |3 +- arch/arm/mach-omap2/board-4430sdp.c | 40 -- arch/arm/mach-omap2/clock44xx_data.c |5 + arch/arm/mach-omap2/hsmmc.c | 123 ++--- arch/arm/mach-omap2/hsmmc.h |1 + arch/arm/plat-omap/include/plat/control.h | 17 arch/arm/plat-omap/include/plat/mmc.h |2 + drivers/mfd/twl6030-irq.c | 27 ++ drivers/mmc/host/omap_hsmmc.c | 18 - include/linux/i2c/twl.h | 42 ++ 11 files changed, 276 insertions(+), 21 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7] OMAP2/3: I2C: Errata ID i207: Clear wrong RDR interrupt
Under certain rare conditions, I2C_STAT[13].RDR bit may be set
and the corresponding interrupt fire, even there is no data in
the receive FIFO, or the I2C data transfer is still ongoing.
These spurious RDR events must be ignored by the software.
This patch handles and ignores RDR spurious interrupts.
The below sequence is required in interrupt handler for
handling this errata:
1. If RDR is set to 1, clear RDR
2. Read I2C status register and check for BusBusy bit. If BusBusy
bit is set, skip remaining steps.
3. If BusBusy bit is not set, perform read operation on I2C status
register.
4. If RDR is set, clear the same. Check RDR again and clear if it sets
RDR bit again.
5. Perform I2C Data Read operation N number of times(where N is value
read from the register BUFSTAT-RXSTAT bit fields).
Note:
This errata is not applicable for omap2420 and omap4.
It is applicable for:
1. omap2430
2. omap34xx(including omap3630).
Signed-off-by: Manjunatha GK
Cc: linux-...@vger.kernel.org
Cc: ben-li...@fluff.org
Cc: Kalliguddi, Hema
Cc: Nishanth Menon
Cc: Aaro Koskinen
Cc: Tony Lindgren
---
drivers/i2c/busses/i2c-omap.c | 40
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index ef73483..5f5207e 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -166,6 +166,8 @@ enum {
#define SYSC_IDLEMODE_SMART0x2
#define SYSC_CLOCKACTIVITY_FCLK0x2
+/* Errata definitions */
+#define I2C_OMAP_ERRATA_I207 (1 << 0)
struct omap_i2c_dev {
struct device *dev;
@@ -199,6 +201,7 @@ struct omap_i2c_dev {
u16 bufstate;
u16 syscstate;
u16 westate;
+ u16 errata;
};
const static u8 reg_map[] = {
@@ -498,6 +501,11 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
/* Take the I2C module out of reset: */
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ dev->errata = 0;
+
+ if (cpu_is_omap2430() || cpu_is_omap34xx())
+ dev->errata |= I2C_OMAP_ERRATA_I207;
+
/* Enable interrupts */
dev->iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
@@ -695,6 +703,34 @@ omap_i2c_ack_stat(struct omap_i2c_dev *dev, u16 stat)
omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat);
}
+static inline void i2c_omap_errata_i207(struct omap_i2c_dev *dev, u16 stat)
+{
+ /*
+* I2C Errata(Errata Nos. OMAP2: 1.67, OMAP3: 1.8)
+* Not applicable for OMAP4.
+* Under certain rare conditions, RDR could be set again
+* when the bus is busy, then ignore the interrupt and
+* clear the interrupt.
+*/
+ if (stat & OMAP_I2C_STAT_RDR) {
+ /* Step 1: If RDR is set, clear it */
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
+
+ /* Step 2: */
+ if (!(omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG)
+ & OMAP_I2C_STAT_BB)) {
+
+ /* Step 3: */
+ if (omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG)
+ & OMAP_I2C_STAT_RDR) {
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
+ dev_dbg(dev->dev, "RDR when bus is busy.\n");
+ }
+
+ }
+ }
+}
+
/* rev1 devices are apparently only on some 15xx */
#ifdef CONFIG_ARCH_OMAP15XX
@@ -826,6 +862,10 @@ complete:
}
if (stat & (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
u8 num_bytes = 1;
+
+ if (dev->errata & I2C_OMAP_ERRATA_I207)
+ i2c_omap_errata_i207(dev, stat);
+
if (dev->fifo_size) {
if (stat & OMAP_I2C_STAT_RRDY)
num_bytes = dev->fifo_size;
--
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
[PATCH v2] OMAP3: Registering sgx device and it's platform data
The SGX powervr_device is registered with it's platform specific
data to provide information about setting constraint through
omap_pm_set_min_bus_tput.
Signed-off-by: Preshit Agarwal
Signed-off-by: Manjunatha GK
Cc: Tony Lindgren
Cc: Kevin Hilman
Cc: Mike Turquette
Cc: Hemanth V
---
arch/arm/mach-omap2/devices.c | 26 ++-
arch/arm/mach-omap2/include/mach/omap_sgxdef.h | 11 ++
2 files changed, 35 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-omap2/include/mach/omap_sgxdef.h
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2271b9b..b624f13 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -26,7 +26,7 @@
#include
#include
#include
-
+#include
#include "mux.h"
#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
@@ -786,6 +786,28 @@ static inline void omap_hdq_init(void)
static inline void omap_hdq_init(void) {}
#endif
+struct sgx_platform_data omap_sgx_data = {
+#ifdef CONFIG_PM
+ .set_min_bus_tput = omap_pm_set_min_bus_tput,
+#else
+ .set_min_bus_tput = NULL;
+#endif
+};
+
+static struct platform_device powervr_device = {
+ .name= "pvrsrvkm",
+ .id = -1,
+ .dev= {
+ .platform_data = &omap_sgx_data,
+ }
+};
+
+static void omap_init_sgx(void)
+{
+ (void) platform_device_register(&powervr_device);
+}
+
+
/*-*/
static int __init omap2_init_devices(void)
@@ -800,7 +822,7 @@ static int __init omap2_init_devices(void)
omap_hdq_init();
omap_init_sti();
omap_init_sha1_md5();
-
+ omap_init_sgx();
return 0;
}
arch_initcall(omap2_init_devices);
diff --git a/arch/arm/mach-omap2/include/mach/omap_sgxdef.h
b/arch/arm/mach-omap2/include/mach/omap_sgxdef.h
new file mode 100644
index 000..5d90a6a
--- /dev/null
+++ b/arch/arm/mach-omap2/include/mach/omap_sgxdef.h
@@ -0,0 +1,11 @@
+#ifndef OMAP_SGXDEF_H
+#define OMAP_SGXDEF_H
+
+#include
+
+struct sgx_platform_data {
+ void(*set_min_bus_tput)(struct device *dev, u8 agent_id,
+ unsigned long r);
+};
+
+#endif
--
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 9/9] OMAP:GPIO: Implement GPIO as a platform device
> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Saturday, May 01, 2010 5:34 AM
> To: Varadarajan, Charulatha
> Cc: linux-omap@vger.kernel.org; Nayak, Rajendra; p...@pwsan.com;
> t...@atomide.com
> Subject: Re: [PATCH 9/9] OMAP:GPIO: Implement GPIO as a platform device
>
> Charulatha V writes:
>
> > This patch implements GPIO as a early platform device. Also it
> > implements OMAP2PLUS specific GPIO as HWMOD FW adapted driver.
>
> Should include a summary explanation of why you're converting to an
> early platform device as well.
Okay.
>
> > Inorder to convert GPIO as platform device, modifications are
> > required in clock_data.c files so that device names can be
> > used to obtain clock instead of getting clocks by name/NULL ptr.
>
> ok
>
> > Currently early platform device register does not do device_pm_init.
> > Hence pm_runtime functions are not used to enable the GPIO device
> > since gpio is early platform device.
>
> OK for now, since this isn't using runtime PM, but maybe we need a
> late_initcall() here to do the device_pm_init() + pm_runtime_enable()
>
> This change log needs more description of the intended init sequence.
> Right now it seems that there are multiple init paths. Now that GPIO
> is an early_platform_device, we should be able to at least make
> omap_gpio_init() static and remove its usage from all the board files.
This was the implementation that I initially did in my previous patch
series. The following needs to be considered:
1. omap2_init_devices() might be too late for early_gpio_init() to
be placed in it.
2. omap_init_irq() needs to be completed before calling early_gpio_init().
So, if early_gpio_init() is called from omap2_init_common_hw(), we need to
have omap_init_irq() called before omap2_init_common_hw(). But Tony
objected this approach mentioning that board might not boot up as
omap2_init_common_hw() has to be done asap.
That's why, I had not moved the omap_gpio_init() usage from board files.
>
> Also, the driver and device separation and init is totally mixed
> together and very confusing. The platform_driver is in
Agreed. Please see my comment at the end of this patch in reply to your
other similar comment.
> plat-omap/gpio.c and should be doing the driver init:
> [early_]platform_driver_register() and _probe(). The platform_device
> setup is in mach-omapX/gpio*.c and where the device init should be, in
> this case early_platform_add_devices().
In early_gpio_init, omap_device_build() (device specific) and
early_platform_driver_register_all() (driver specific), _probe() are
done in a sequence. This is because early_gpio_init needs to be called
asap and if we try to split this device specific and driver specific
early_inits, we will end up having two init calls for each early drivers.
I feel that multiple function calls for early_init (one for driver probe and
one for device register) should be avoided as we need to find the right place
to call them.
>
>
> > Signed-off-by: Charulatha V
> > Signed-off-by: Rajendra Nayak
> > ---
> > arch/arm/mach-omap1/Makefile |6 +
> > arch/arm/mach-omap1/clock_data.c |2 +-
> > arch/arm/mach-omap2/Makefile |2 +-
> > arch/arm/mach-omap2/clock2420_data.c | 10 +-
> > arch/arm/mach-omap2/clock2430_data.c | 14 +-
> > arch/arm/mach-omap2/clock3xxx_data.c | 24 +-
> > arch/arm/mach-omap2/clock44xx_data.c | 24 +-
> > arch/arm/plat-omap/gpio.c | 405
> >
> > arch/arm/plat-omap/include/plat/gpio.h | 21 ++
> > 9 files changed, 220 insertions(+), 288 deletions(-)
>
> [...]
>
> > @@ -1621,6 +1501,34 @@ static void __init omap_gpio_show_rev(void)
> > */
> > static struct lock_class_key gpio_lock_class;
> >
> > +static int init_gpio_info(void)
> > +{
> > + gpio_bank_bits = 32;
> > +
> > + if (cpu_is_omap15xx()) {
> > + gpio_bank_count = 2;
> > + gpio_bank_bits = 16;
> > + } else if (cpu_is_omap16xx()) {
> > + gpio_bank_count = 5;
> > + gpio_bank_bits = 16;
> > + } else if (cpu_is_omap7xx())
> > + gpio_bank_count = 7;
> > + else if (cpu_is_omap242x())
> > + gpio_bank_count = 4;
> > + else if (cpu_is_omap243x())
> > + gpio_bank_count = 5;
> > + else if (cpu_is_omap34xx() || cpu_is_omap44xx())
> > + gpio_bank_count = OMAP34XX_NR_GPIOS;
>
> Both the bank count and bank bits could be part of platform_data
> and set in the SoC specific init. This is the GPIO driver part
> and we're trying to make this as SoC independent as possible. Anytime
> you need to add a cpu_is* or #ifdef in this code indicates something
> that should be part of SoC specific init and passed in.
bank count and bank bits are not specific to each device, but SoC specific.
Hence I did not consider passing it as part of platform_data, because this
information would be duplicated across all devices in that SoC.
I
RE: [PATCH 5/9] OMAP:GPIO: Introduce support for OMAP2PLUS chip specific GPIO
> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Saturday, May 01, 2010 4:33 AM
> To: Varadarajan, Charulatha
> Cc: linux-omap@vger.kernel.org; Nayak, Rajendra; p...@pwsan.com;
> t...@atomide.com
> Subject: Re: [PATCH 5/9] OMAP:GPIO: Introduce support for OMAP2PLUS chip
> specific
> GPIO
>
> Charulatha V writes:
>
> > This patch adds support for handling GPIO as a HWMOD adapted
> > platform device for OMAP2PLUS chips.
> >
> > Signed-off-by: Charulatha V
> > ---
> > arch/arm/mach-omap2/gpio.c | 101
> >
> > 1 files changed, 101 insertions(+), 0 deletions(-)
> > create mode 100644 arch/arm/mach-omap2/gpio.c
> >
> > diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
> > new file mode 100644
> > index 000..6424050
> > --- /dev/null
> > +++ b/arch/arm/mach-omap2/gpio.c
> > @@ -0,0 +1,101 @@
> > +/*
> > + * gpio.c - OMAP2PLUS-specific gpio code
> > + *
> > + * Copyright (C) 2010 Texas Instruments, Inc.
> > + *
> > + * Author:
> > + * Charulatha V
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +static int gpio_bank_count;
> > +
> > +struct omap_device_pm_latency omap_gpio_latency[] = {
> > + [0] = {
> > + .deactivate_func = omap_device_idle_hwmods,
> > + .activate_func = omap_device_enable_hwmods,
> > + .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
> > + },
> > +};
> > +
> > +int __init gpio_init(void)
> > +{
> > + int i = 0;
> > + static int is_early_device = true;
> > +
> > + do {
> > + struct omap_device *od;
> > + struct omap_hwmod *oh;
> > + int hw_mod_name_len = 16;
> > + int l;
> > + char oh_name[hw_mod_name_len];
> > + struct omap_gpio_platform_data *pdata;
> > + char *name = "omap-gpio";
> > +
> > + l = snprintf(oh_name, hw_mod_name_len, "gpio%d_hwmod", i + 1);
> > + WARN(l >= hw_mod_name_len,
> > + "String buffer overflow in GPIO device setup\n");
> > +
>
> Rather than iterating over the name, you should have a hwmod_class for
> GPIOs and use omap_hwmod_for_each_by_class() to iterate over all the
> hwmods in the GPIO class.
Ok.
>
> > + oh = omap_hwmod_lookup(oh_name);
> > + if (!oh) {
> > + pr_err("Could not look up %s\n", oh_name);
> > + i++;
> > + continue;
> > + }
> > +
> > + pdata = kzalloc(sizeof(struct omap_gpio_platform_data),
> > + GFP_KERNEL);
> > + if (!pdata) {
> > + pr_err("Memory allocation failed gpio%d\n", i + 1);
> > + return -ENOMEM;
> > + }
> > + pdata->base = oh->_rt_va;
> > + pdata->irq = oh->mpu_irqs[0].irq;
>
> base address and IRQ should not be part of platform_data. platform
> driver should be using platform_get_resource() for both.
Agreed. Will modify.
>
> > + if (cpu_is_omap24xx() || cpu_is_omap34xx())
> > + pdata->method = METHOD_GPIO_24XX;
> > + if (cpu_is_omap44xx())
> > + pdata->method = METHOD_GPIO_44XX;
> > + pdata->virtual_irq_start = IH_GPIO_BASE + 32 * i;
> > + pdata->device_enable = omap_device_enable;
> > + pdata->device_idle = omap_device_idle;
> > + pdata->device_shutdown = omap_device_shutdown;
>
> These aren't valid for GPIO1 which is in WKUP. Maybe we need
> to check if the hwmod is not in wkup_pwrdm before setting these?
I need to check how to implement this.
>
> > + od = omap_device_build(name, i, oh, pdata,
> > + sizeof(*pdata), omap_gpio_latency,
> > + ARRAY_SIZE(omap_gpio_latency),
> > + is_early_device);
> > + WARN(IS_ERR(od), "Cant build omap_device for %s:%s.\n",
> > + name, oh->name);
> > +
> > + i++;
> > + } while (i < gpio_bank_count);
> > + is_early_device = false;
> > +
> > + return 0;
> > +}
> > +arch_initcall(gpio_init);
> > +
> > +int __init omap2_gpio_init(void)
> > +{
> > + if (cpu_is_omap242x())
> > + gpio_bank_count = 4;
> > + else if (cpu_is_omap243x())
> > + gpio_bank_count = 5;
> > + else if (cpu_is_omap34xx() || cpu_is_omap44xx())
> > + gpio_bank_count = OMAP34XX_NR_GPIOS;
>
> The count should be gathered after iterating over the GPIO hwmod class.
> and should not need cpu_is checks.
Sure.
>
> > + if (gpio_init())
> > + return -EINVAL;
> > +
> > + early_platform_driver_register_all("earl
Re: [PATCH 11/11] omap2/3/4: Disable CONFIG_FB_OMAP in omap3_defconfig
On Tue, 2010-05-04 at 16:40 +0200, ext Tony Lindgren wrote: > * Tomi Valkeinen [100504 00:21]: > > Hi, > > > > On Tue, 2010-05-04 at 02:52 +0200, ext Tony Lindgren wrote: > > > * Tony Lindgren [100430 13:47]: > > > > * Tony Lindgren [100430 13:32]: > > > > > Looks like CONFIG_FB_OMAP prevents somehow mounting root on MMC > > > > > at least on zoom3 for multi-omap. Disable CONFIG_FB until the > > > > > omap FB code is fixed. > > > > > > > > This one I'll drop as soon as the problem is sorted out with > > > > CONFIG_FB_OMAP. > > > > > > This one seems to be something under drivers/video/omap, so > > > I'll change CONFIG_FB_OMAP to be a module now. Updated patch > > > below. > > > > > > I'll update omap for-next accordingly, then Tomi can figure > > > it out :) > > > > This sounds... interesting... =) Any more info on what happens? Does it > > also affect new omapfb driver? > > Yeah this is interesting, it seems like the kernel cmdline gets > somehow corrupted for zoom3 with the omap3_defconfig if CONFIG_FB_OMAP=y. > Some options seem to be there, but for example rootwait option is > ignored and the root on MMC never mounts. This is in the current > omap for-next branch. Ok, so the cmdline parsing in omapfb could be broken. I'll check it out. > Hmm, what do you mean with "new omapfb" driver, the stuff you have > queued up? No, I mean the DSS2 version. drivers/video/omap is the old one, written mostly by Imre, and drivers/video/omap2 is the new one, written mostly by me. I guess most boards are still using the old omapfb driver. Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/11] omap2/3/4: Disable CONFIG_FB_OMAP in omap3_defconfig
* Tomi Valkeinen [100504 00:21]: > Hi, > > On Tue, 2010-05-04 at 02:52 +0200, ext Tony Lindgren wrote: > > * Tony Lindgren [100430 13:47]: > > > * Tony Lindgren [100430 13:32]: > > > > Looks like CONFIG_FB_OMAP prevents somehow mounting root on MMC > > > > at least on zoom3 for multi-omap. Disable CONFIG_FB until the > > > > omap FB code is fixed. > > > > > > This one I'll drop as soon as the problem is sorted out with > > > CONFIG_FB_OMAP. > > > > This one seems to be something under drivers/video/omap, so > > I'll change CONFIG_FB_OMAP to be a module now. Updated patch > > below. > > > > I'll update omap for-next accordingly, then Tomi can figure > > it out :) > > This sounds... interesting... =) Any more info on what happens? Does it > also affect new omapfb driver? Yeah this is interesting, it seems like the kernel cmdline gets somehow corrupted for zoom3 with the omap3_defconfig if CONFIG_FB_OMAP=y. Some options seem to be there, but for example rootwait option is ignored and the root on MMC never mounts. This is in the current omap for-next branch. Hmm, what do you mean with "new omapfb" driver, the stuff you have queued up? 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/2] usb: ehci-omap: fix compilation warning
Hi, > -Original Message- > From: Gupta, Ajay Kumar > Sent: Tuesday, May 04, 2010 1:15 PM > To: linux-...@vger.kernel.org > Cc: linux-omap@vger.kernel.org; felipe.ba...@nokia.com; Gupta, Ajay Kumar > Subject: [PATCH 1/2] usb: ehci-omap: fix compilation warning > > Fixes below compilation warning: > drivers/usb/host/ehci-hcd.c:425: > warning: 'ehci_port_power' defined but not used > > Signed-off-by: Ajay Kumar Gupta > --- > drivers/usb/host/ehci-omap.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c > index 40a8583..e55fd58 100644 > --- a/drivers/usb/host/ehci-omap.c > +++ b/drivers/usb/host/ehci-omap.c > @@ -659,6 +659,8 @@ static int ehci_hcd_omap_probe(struct platform_device > *pdev) > goto err_add_hcd; > } > > + ehci_port_power(omap->ehci, 0); There is a typo error, Port power has to be '1'. I am copying the correct patch below. -Ajay - cut here Subject: [PATCH 1/2 v2] usb: ehci-omap: fix compilation warning Fixes below compilation warning: drivers/usb/host/ehci-hcd.c:425: warning: 'ehci_port_power' defined but not used Signed-off-by: Ajay Kumar Gupta --- drivers/usb/host/ehci-omap.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 40a8583..711332e 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -659,6 +659,9 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev) goto err_add_hcd; } + /* root ports should always stay powered */ + ehci_port_power(omap->ehci, 1); + return 0; err_add_hcd: -- 1.6.2.4- end - -- 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 v4 1/2] input: touchscreen: introduce tsc2005 driver
From: Lauri Leukkunen Introduce a driver for the Texas Instruments TSC2005 touchscreen controller (http://focus.ti.com/docs/prod/folders/print/tsc2005.html). The patch is based on a driver by Lauri Leukkunen, with modifications by David Brownell, Phil Carmody, Imre Deak, Hiroshi DOYU, Ari Kauppi, Tony Lindgren, Jarkko Nikula, Eero Nurkkala and Roman Tereshonkov. Signed-off-by: Lauri Leukkunen [aaro.koski...@nokia.com: patch description, rebasing & cleanup] Signed-off-by: Aaro Koskinen Cc: David Brownell Cc: Phil Carmody Cc: Imre Deak Cc: Hiroshi DOYU Cc: Ari Kauppi Cc: Tony Lindgren Cc: Jarkko Nikula Cc: Eero Nurkkala Cc: Roman Tereshonkov --- v4: Refreshed the patches against the current mainline (13bd8e4673d527a9e48f41956b11d391e7c2cfe0). No other changes as no comments were received. The v3 has some major modifications. I have tried to clean up and simplify the driver. All action takes place in thread context, SPI transfers are synchronous, the spinlock is removed, and there are no long sections with interrupts disabled. The driver should be now SMP safe. Also the following review comments are addressed: - Use del_timer_sync() instead of del_timer(). - Use mod_timer() always instead of add_timer(). - Use attribute_group. - Delete filtering and averaging which belong to upper layers. - Delete pen_down sysfs file. The previous version and comments can be seen here: http://marc.info/?t=12573411564&r=1&w=2 drivers/input/touchscreen/Kconfig | 11 + drivers/input/touchscreen/Makefile |1 + drivers/input/touchscreen/tsc2005.c | 678 +++ include/linux/spi/tsc2005.h | 41 +++ 4 files changed, 731 insertions(+), 0 deletions(-) create mode 100644 drivers/input/touchscreen/tsc2005.c create mode 100644 include/linux/spi/tsc2005.h diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig index dfafc76..72c1797 100644 --- a/drivers/input/touchscreen/Kconfig +++ b/drivers/input/touchscreen/Kconfig @@ -548,6 +548,17 @@ config TOUCHSCREEN_TOUCHIT213 To compile this driver as a module, choose M here: the module will be called touchit213. +config TOUCHSCREEN_TSC2005 +tristate "TSC2005 based touchscreens" +depends on SPI_MASTER +help + Say Y here if you have a TSC2005 based touchscreen. + + If unsure, say N. + + To compile this driver as a module, choose M here: the + module will be called tsc2005. + config TOUCHSCREEN_TSC2007 tristate "TSC2007 based touchscreens" depends on I2C diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile index d61a3b4..61fa8b5 100644 --- a/drivers/input/touchscreen/Makefile +++ b/drivers/input/touchscreen/Makefile @@ -33,6 +33,7 @@ obj-$(CONFIG_TOUCHSCREEN_S3C2410) += s3c2410_ts.o obj-$(CONFIG_TOUCHSCREEN_TOUCHIT213) += touchit213.o obj-$(CONFIG_TOUCHSCREEN_TOUCHRIGHT) += touchright.o obj-$(CONFIG_TOUCHSCREEN_TOUCHWIN) += touchwin.o +obj-$(CONFIG_TOUCHSCREEN_TSC2005) += tsc2005.o obj-$(CONFIG_TOUCHSCREEN_TSC2007) += tsc2007.o obj-$(CONFIG_TOUCHSCREEN_UCB1400) += ucb1400_ts.o obj-$(CONFIG_TOUCHSCREEN_WACOM_W8001) += wacom_w8001.o diff --git a/drivers/input/touchscreen/tsc2005.c b/drivers/input/touchscreen/tsc2005.c new file mode 100644 index 000..27ee361 --- /dev/null +++ b/drivers/input/touchscreen/tsc2005.c @@ -0,0 +1,678 @@ +/* + * TSC2005 touchscreen driver + * + * Copyright (C) 2006-2010 Nokia Corporation + * + * Author: Lauri Leukkunen + * based on TSC2301 driver by Klaus K. Pedersen + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + */ + +#include +#include +#include +#include +#include +#include +#include + +/* + * The touchscreen interface operates as follows: + * + * 1) Pen is pressed against the touchscreen. + * 2) TSC2005 performs AD conversion. + * 3) After the conversion is done TSC2005 drives DAV line down. + * 4) GPIO IRQ is received and tsc2005_irq_thread() is scheduled. + * 5) tsc2005_irq_thread() queues up an spi transfer to fetch the x, y, z1, z2 + *values. + * 6) tsc2005_irq_thread() reports coordinates to input layer and sets up + *tsc2005_penup_timer() to be called after TSC2005_PEN
[RESEND PATCH v4 2/2] omap: rx-51: enable tsc2005
Enable TSC2005 touchscreen driver on the RX-51 board.
Signed-off-by: Aaro Koskinen
---
arch/arm/configs/rx51_defconfig |1 +
arch/arm/mach-omap2/board-rx51-peripherals.c | 57 ++
2 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/arch/arm/configs/rx51_defconfig b/arch/arm/configs/rx51_defconfig
index 45135ff..2ebfdb9 100644
--- a/arch/arm/configs/rx51_defconfig
+++ b/arch/arm/configs/rx51_defconfig
@@ -804,6 +804,7 @@ CONFIG_INPUT_TOUCHSCREEN=y
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
# CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set
# CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
+CONFIG_TOUCHSCREEN_TSC2005=m
# CONFIG_TOUCHSCREEN_TSC2007 is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_ATI_REMOTE is not set
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 4377a4c..0fafac4 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -42,18 +43,28 @@
#define RX51_WL1251_POWER_GPIO 87
#define RX51_WL1251_IRQ_GPIO 42
+#define RX51_TSC2005_RESET_GPIO104
+#define RX51_TSC2005_IRQ_GPIO 100
+
/* list all spi devices here */
enum {
RX51_SPI_WL1251,
+ RX51_SPI_TSC2005,
};
static struct wl12xx_platform_data wl1251_pdata;
+static struct tsc2005_platform_data tsc2005_pdata;
static struct omap2_mcspi_device_config wl1251_mcspi_config = {
.turbo_mode = 0,
.single_channel = 1,
};
+static struct omap2_mcspi_device_config tsc2005_mcspi_config = {
+ .turbo_mode = 0,
+ .single_channel = 1,
+};
+
static struct spi_board_info rx51_peripherals_spi_board_info[] __initdata = {
[RX51_SPI_WL1251] = {
.modalias = "wl1251",
@@ -64,6 +75,15 @@ static struct spi_board_info
rx51_peripherals_spi_board_info[] __initdata = {
.controller_data= &wl1251_mcspi_config,
.platform_data = &wl1251_pdata,
},
+ [RX51_SPI_TSC2005] = {
+ .modalias = "tsc2005",
+ .bus_num= 1,
+ .chip_select= 0,
+ .irq= OMAP_GPIO_IRQ(RX51_TSC2005_IRQ_GPIO),
+ .max_speed_hz = 600,
+ .controller_data= &tsc2005_mcspi_config,
+ .platform_data = &tsc2005_pdata,
+ },
};
#if defined(CONFIG_KEYBOARD_GPIO) || defined(CONFIG_KEYBOARD_GPIO_MODULE)
@@ -703,6 +723,42 @@ static inline void board_onenand_init(void)
#endif
+static struct tsc2005_platform_data tsc2005_pdata = {
+ .ts_pressure_max = 2048,
+ .ts_pressure_fudge = 2,
+ .ts_x_max = 4096,
+ .ts_x_fudge= 4,
+ .ts_y_max = 4096,
+ .ts_y_fudge= 7,
+ .ts_x_plate_ohm= 280,
+ .esd_timeout_ms= 8000,
+};
+
+static void rx51_tsc2005_set_reset(bool enable)
+{
+ gpio_set_value(RX51_TSC2005_RESET_GPIO, enable);
+}
+
+static void __init rx51_init_tsc2005(void)
+{
+ int r;
+
+ r = gpio_request(RX51_TSC2005_IRQ_GPIO, "tsc2005 IRQ");
+ if (r >= 0)
+ gpio_direction_input(RX51_TSC2005_IRQ_GPIO);
+ else
+ printk(KERN_ERR "unable to get %s GPIO\n", "tsc2005 IRQ");
+
+ r = gpio_request(RX51_TSC2005_RESET_GPIO, "tsc2005 reset");
+ if (r >= 0) {
+ gpio_direction_output(RX51_TSC2005_RESET_GPIO, 1);
+ tsc2005_pdata.set_reset = rx51_tsc2005_set_reset;
+ } else {
+ printk(KERN_ERR "unable to get %s GPIO\n", "tsc2005 reset");
+ tsc2005_pdata.esd_timeout_ms = 0;
+ }
+}
+
#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91X_MODULE)
static struct omap_smc91x_platform_data board_smc91x_data = {
@@ -787,6 +843,7 @@ void __init rx51_peripherals_init(void)
board_smc91x_init();
rx51_add_gpio_keys();
rx51_init_wl1251();
+ rx51_init_tsc2005();
spi_register_board_info(rx51_peripherals_spi_board_info,
ARRAY_SIZE(rx51_peripherals_spi_board_info));
omap2_hsmmc_init(mmc);
--
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
Re: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
On Tue, May 04, 2010 at 03:23:10PM +0200, ext Hiremath, Vaibhav wrote: > > > -Original Message- > > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > > Sent: Wednesday, April 21, 2010 4:40 PM > > To: Hiremath, Vaibhav > > Cc: linux-omap@vger.kernel.org > > Subject: RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed > > > > On Wed, 2010-04-21 at 12:45 +0200, ext Hiremath, Vaibhav wrote: > > > > -Original Message- > > > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > > > > ow...@vger.kernel.org] On Behalf Of Hiremath, Vaibhav > > > > Sent: Friday, April 16, 2010 4:28 PM > > > > To: Tomi Valkeinen > > > > Cc: linux-omap@vger.kernel.org > > > > Subject: RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed > > > > > > > > > > > > > -Original Message- > > > > > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > > > > > Sent: Friday, April 16, 2010 3:08 PM > > > > > To: Hiremath, Vaibhav > > > > > Cc: linux-omap@vger.kernel.org > > > > > Subject: Re: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed > > > > > > > > > > On Mon, 2010-03-22 at 14:09 +0100, ext hvaib...@ti.com wrote: > > > > > > From: Vaibhav Hiremath > > > > > > > > > > > > In case of 720P with 90/270 degree rotation, the system reports > > > > > > GFX_FIFO_UNDERFLOW error which usually happens if DSS DMA is not > > able to > > > > > fill > > > > > > the FIFO as per requirement. > > > > > > > > > > > > In TRM (section 11.2.6.1.3), where is has been clearly mentioned > > that, > > > > > > > > > > > > "To improve the performance on 90 degree rotation, split the data > > access > > > > > on > > > > > > write side and not read side." > > > > > > > > > > > > That means, read should always happen on 0 degree and write should > > go to > > > > > > respective rotation view. > > > > > > > > > > > > > > > > With this patch my db test app (from > > > > > git://gitorious.org/linux-omap-dss2/omapfb-tests.git) shows a lot of > > > > > tearing when rotation != 0. I tested this on 3430SDP using the LCD. > > > [Hiremath, Vaibhav] Tomi, > > > > > > Yes, just now I tried your db application and I am also seeing tearing > > effect. All other apps (including the one which I used for testing) works > > fine for other rotation angles. > > > > > > Let me debug further before commenting anything on this, I just thought of > > updating you on this. > > > > "db" app uses double buffering for updating the display, with maximum > > update rate. There's also "pan" app, that does a bit similar thing using > > fb offsets. > [Hiremath, Vaibhav] Tomi, > > I found the bug which is causing tearing effect, I tested it here with both, > mine and your applications and for me it is working fine. > > Can you please check at your end? > (Sorry for the attachment) You should really avoid that. I can't quote the patch. What are those CW<->CCW swaps that you do in the patch? Also I think the ioremap stuff is a bit broken since AFAICS it will leave the old angle still mapped when you rotate to another angle. -- Ville Syrjälä -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] omap: gpmc-nand: add ability to keep timings defined by the bootloader
Tony Lindgren wrote: * Mike Rapoport [100503 13:28]: So it comes down to what provides better tolerance, the explicit NAND timings in nanosecs or (rounded) timings in ticks derived from bootloader settings... My experience is that you can get the nanosec timings from the device datasheet(s) and that just should work for any L3 frequency. And what about boards that can have different NAND flash chips assembled? What datasheet should be used to get the nanosecs? Note, that detecting NAND ID in the bootloader and adjusting timings appropriately is not that big deal, and doing it in the kernel seems to me really impractical. My experience is also that trying to do it the other way around won't work because of rounding errors. Trying to produce nanosecond values out of the tick values just is not accurate enough. I'm still not convinced. Similar approach worked for me with several devices attached to sort of GPMC controllers on different SoC. There always was a way to set timings once in the bootloader and then detect the timings in the kernel and update them during cpu-freq transitions... That's why gpmc-onenand.c and usb-tusb6010.c timings are done the way they are, and they're known to work at various L3 frequencies. I'm not really familiar with OneNAND, but looking at gpmc-onenand.c I see hardcoded timings. Moreover, the nanosecs values seem to get adjusted for different L3 frequencies. So, for NAND it would mean that platform would have to supply several timing sets for different L3 freqs? So maybe just not do anything, and print a warning on gpmc L3 changes if the timings are not set? I don't quite understand where exactly this warning should go. I haven't found any treatment of L3 frequency changes in gpmc related code neither in linux-omap nor in linux-omap-pm... Ah, right. There's currently nothing doing that.. That would have to be done based on cpufreq notifiers (or clock notifiers). But we don't have any of that at least in the mainline yet. Hmm I don't even think we currently scale the L3 for cpufreq.. Right now the best way to test would be by booting at different L3 frequencies. Anyways, my point is that setting gpmc_default_timings based on the bootloader after doing the gpmc_cs_get_timings is most likely unsafe for other L3 frequencies. Regards, Tony -- Sincerely yours, Mike. -- 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: DSS2: GFX FIFO UNDERFLOW issue fixed
> -Original Message- > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > Sent: Wednesday, April 21, 2010 4:40 PM > To: Hiremath, Vaibhav > Cc: linux-omap@vger.kernel.org > Subject: RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed > > On Wed, 2010-04-21 at 12:45 +0200, ext Hiremath, Vaibhav wrote: > > > -Original Message- > > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > > > ow...@vger.kernel.org] On Behalf Of Hiremath, Vaibhav > > > Sent: Friday, April 16, 2010 4:28 PM > > > To: Tomi Valkeinen > > > Cc: linux-omap@vger.kernel.org > > > Subject: RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed > > > > > > > > > > -Original Message- > > > > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > > > > Sent: Friday, April 16, 2010 3:08 PM > > > > To: Hiremath, Vaibhav > > > > Cc: linux-omap@vger.kernel.org > > > > Subject: Re: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed > > > > > > > > On Mon, 2010-03-22 at 14:09 +0100, ext hvaib...@ti.com wrote: > > > > > From: Vaibhav Hiremath > > > > > > > > > > In case of 720P with 90/270 degree rotation, the system reports > > > > > GFX_FIFO_UNDERFLOW error which usually happens if DSS DMA is not > able to > > > > fill > > > > > the FIFO as per requirement. > > > > > > > > > > In TRM (section 11.2.6.1.3), where is has been clearly mentioned > that, > > > > > > > > > > "To improve the performance on 90 degree rotation, split the data > access > > > > on > > > > > write side and not read side." > > > > > > > > > > That means, read should always happen on 0 degree and write should > go to > > > > > respective rotation view. > > > > > > > > > > > > > With this patch my db test app (from > > > > git://gitorious.org/linux-omap-dss2/omapfb-tests.git) shows a lot of > > > > tearing when rotation != 0. I tested this on 3430SDP using the LCD. > > [Hiremath, Vaibhav] Tomi, > > > > Yes, just now I tried your db application and I am also seeing tearing > effect. All other apps (including the one which I used for testing) works > fine for other rotation angles. > > > > Let me debug further before commenting anything on this, I just thought of > updating you on this. > > "db" app uses double buffering for updating the display, with maximum > update rate. There's also "pan" app, that does a bit similar thing using > fb offsets. [Hiremath, Vaibhav] Tomi, I found the bug which is causing tearing effect, I tested it here with both, mine and your applications and for me it is working fine. Can you please check at your end? (Sorry for the attachment) Thanks, Vaibhav > > What kind of test apps you have? > > Tomi > 0001-OMAP-DSS2-GFX-FIFO-UNDERFLOW-issue-fixed.patch Description: 0001-OMAP-DSS2-GFX-FIFO-UNDERFLOW-issue-fixed.patch
RE: [PATCH v3] arm: Fix .gitignore for boot/compressed folder
Russell, From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Monday, May 03, 2010 2:59 PM > On Mon, May 03, 2010 at 02:51:25PM -0500, Sergio Aguirre wrote: > > This should complement changes done in: > > > > commit e7db7b4270ed2a606b8c0b5f944a5f92ade0e84c > > Author: Albin Tonnerre > > Date: Fri Jan 8 14:42:43 2010 -0800 > > > > arm: add support for LZO-compressed kernels > > > > It missed to do the respective changes in '.gitignore' file. > > > > Also, add vmlinux to the list, which is generated also during > > the build. > > > > Signed-off-by: Sergio Aguirre > > Acked-by: Uwe Kleine-König > > Ok. Thanks! Regards, Sergio -- 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: [Query][omap iommu] Consulting iommu if a physical region is "mappable" before actually mapping it
Hiroshi, Hari, > -Original Message- > From: Hiroshi DOYU [mailto:hiroshi.d...@nokia.com] > Sent: Tuesday, May 04, 2010 12:59 AM > To: Aguirre, Sergio > Cc: Kanigeri, Hari; linux-omap@vger.kernel.org > Subject: Re: [Query][omap iommu] Consulting iommu if a physical region is > "mappable" before actually mapping it > > From: "ext Aguirre, Sergio" > Subject: RE: [Query][omap iommu] Consulting iommu if a physical region is > "mappable" before actually mapping it > Date: Mon, 3 May 2010 21:23:46 +0200 > > > > > > >> -Original Message- > >> From: Kanigeri, Hari > >> Sent: Monday, May 03, 2010 2:09 PM > >> To: Aguirre, Sergio; Hiroshi DOYU > >> Cc: linux-omap@vger.kernel.org > >> Subject: RE: [Query][omap iommu] Consulting iommu if a physical region > is > >> "mappable" before actually mapping it > >> > >> Sergio, > >> > >> > > >> > Can the iommu driver be "consulted" if a certain area (contiguous or > >> not) > >> > can be mapped or not, before even trying to do it? > >> > > >> > >> -- As long as there are physical pages backing the area it should be > >> mappable right ? > > > > Ok, well.. maybe my question was more about that, if the ISP MMU has > > some kind of limited translation table size, in which it has a > > limited of pages to map to device addresses that the ISP can use. > > > > The need for this is that, in camera, there's a Video4Linux2 IOCTL > > to know if a certain amount of buffers can be handled (and that > > includes if they could be mapped or not), even before actually doing > > the whole allocation/mapping. > > > > If there's no limitation in the translation table size, then I guess > > the only concern is to ensure we have enough free RAM to use. (Which > > I'll like to think that an userspace resource manager will be able > > to figure out for the camera application, which is the one > > allocating the buffers.) > > Right, currently a whole 4GB address space is available, so virtually > no limitation for the translation table size. OK, understood. Sorry if I asked dumb questions, but I'm not an expert on that area. Now I know. :) Thanks a lot for your patience and time! Regards, Sergio > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] omap: mailbox: fix reverse likeliness
On Mon, May 3, 2010 at 9:02 PM, Tony Lindgren wrote:
> * Ohad Ben-Cohen [100502 08:40]:
>> Fix reverse likeliness
>>
>> Signed-off-by: Ohad Ben-Cohen
>> ---
>> If you want, you can also reach me at < ohadb at ti dot com >.
>>
>> arch/arm/plat-omap/mailbox.c | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
>> index 5140efc..5309213 100644
>> --- a/arch/arm/plat-omap/mailbox.c
>> +++ b/arch/arm/plat-omap/mailbox.c
>> @@ -290,7 +290,7 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
>> fail_alloc_txq:
>> free_irq(mbox->irq, mbox);
>> fail_request_irq:
>> - if (unlikely(mbox->ops->shutdown))
>> + if (likely(mbox->ops->shutdown))
>> mbox->ops->shutdown(mbox);
>>
>> return ret;
>> @@ -303,7 +303,7 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
>>
>> free_irq(mbox->irq, mbox);
>>
>> - if (unlikely(mbox->ops->shutdown)) {
>> + if (likely(mbox->ops->shutdown)) {
>> spin_lock(&mboxes_lock);
>> if (mbox_configured > 0)
>> mbox_configured--;
>
> Does this code path need to be optimized? :)
>
> How about just get rid of the (un)likely here?
I like this :)
If we're at it, there are additional cold-path (un)likely macros I
want to target:
>From a921f13dadc02106a2cabb15e3813411d3fcb3a8 Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen
Date: Sat, 17 Apr 2010 01:57:43 +0300
Subject: [PATCH 3/4] omap: mailbox: remove (un)likely macros from cold paths
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/plat-omap/mailbox.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 5140efc..7c60550 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -248,12 +248,12 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
int ret = 0;
struct omap_mbox_queue *mq;
- if (likely(mbox->ops->startup)) {
+ if (mbox->ops->startup) {
spin_lock(&mboxes_lock);
if (!mbox_configured)
ret = mbox->ops->startup(mbox);
- if (unlikely(ret)) {
+ if (ret) {
spin_unlock(&mboxes_lock);
return ret;
}
@@ -263,7 +263,7 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
ret = request_irq(mbox->irq, mbox_interrupt, IRQF_SHARED,
mbox->name, mbox);
- if (unlikely(ret)) {
+ if (ret) {
printk(KERN_ERR
"failed to register mailbox interrupt:%d\n", ret);
goto fail_request_irq;
@@ -290,7 +290,7 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
fail_alloc_txq:
free_irq(mbox->irq, mbox);
fail_request_irq:
- if (unlikely(mbox->ops->shutdown))
+ if (mbox->ops->shutdown)
mbox->ops->shutdown(mbox);
return ret;
@@ -303,7 +303,7 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
free_irq(mbox->irq, mbox);
- if (unlikely(mbox->ops->shutdown)) {
+ if (mbox->ops->shutdown) {
spin_lock(&mboxes_lock);
if (mbox_configured > 0)
mbox_configured--;
--
1.6.3.3
I'll wait a day or two for more comments, and send a v3 series.
Thanks,
Ohad.
>
> 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] OMAP3: PM: fix AM35x musb issue with AUTOIDLE bit in CONTROL_SYSCONFIG
MUSB interface on AM35x stops working when we set AUTOIDLE bit (D0) in CONTROL_SYSCONFIG(0x48002010) register. Signed-off-by: Ajay Kumar Gupta --- arch/arm/mach-omap2/pm34xx.c |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c index eab..cc9d566 100644 --- a/arch/arm/mach-omap2/pm34xx.c +++ b/arch/arm/mach-omap2/pm34xx.c @@ -849,7 +849,12 @@ static void __init prcm_setup_regs(void) CM_AUTOIDLE); } - omap_ctrl_writel(OMAP3430_AUTOIDLE, OMAP2_CONTROL_SYSCONFIG); + /* +* MUSB interface on AM35x stops working when we enable AUTOIDLE, +* so avoid this for AM3517 and AM3505 device. +*/ + if (!cpu_is_omap3517() && !cpu_is_omap3505()) + omap_ctrl_writel(OMAP3430_AUTOIDLE, OMAP2_CONTROL_SYSCONFIG); /* * Set all plls to autoidle. This is needed until autoidle is -- 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
RE: [PATCH] usb: musb: Update FIFO mode_5_cfg to accomodate 4K
> FIFO table fifo_5_cfg was added so that it can be used as a > workaround for OMAP34x/35x errata which limits the FIFO space > uses to be within first 8K or next 8K. > > Updating this table to accomodate an endpoint of 4K so that > the same table can be used for high bandwidth transfers as > used by some USB cameras. > No issues with this patch as is, but it's probably high time we made this fifo table something that the board files can pass down. Is anyone already working on this, or should I give it a shot? - Anand -- 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] usb: musb: Update FIFO mode_5_cfg to accomodate 4K
FIFO table fifo_5_cfg was added so that it can be used as a
workaround for OMAP34x/35x errata which limits the FIFO space
uses to be within first 8K or next 8K.
Updating this table to accomodate an endpoint of 4K so that
the same table can be used for high bandwidth transfers as
used by some USB cameras.
Signed-off-by: Ajay Kumar Gupta
---
drivers/usb/musb/musb_core.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 705cc4a..4e327f5 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1089,10 +1089,10 @@ static struct fifo_cfg __initdata mode_5_cfg[] = {
{ .hw_ep_num = 2, .style = FIFO_RX, .maxpacket = 512, },
{ .hw_ep_num = 3, .style = FIFO_TX, .maxpacket = 512, },
{ .hw_ep_num = 3, .style = FIFO_RX, .maxpacket = 512, },
-{ .hw_ep_num = 4, .style = FIFO_TX, .maxpacket = 512, },
-{ .hw_ep_num = 4, .style = FIFO_RX, .maxpacket = 512, },
-{ .hw_ep_num = 5, .style = FIFO_TX, .maxpacket = 512, },
-{ .hw_ep_num = 5, .style = FIFO_RX, .maxpacket = 512, },
+{ .hw_ep_num = 4, .style = FIFO_TX, .maxpacket = 32, },
+{ .hw_ep_num = 4, .style = FIFO_RX, .maxpacket = 32, },
+{ .hw_ep_num = 5, .style = FIFO_TX, .maxpacket = 32, },
+{ .hw_ep_num = 5, .style = FIFO_RX, .maxpacket = 32, },
{ .hw_ep_num = 6, .style = FIFO_TX, .maxpacket = 32, },
{ .hw_ep_num = 6, .style = FIFO_RX, .maxpacket = 32, },
{ .hw_ep_num = 7, .style = FIFO_TX, .maxpacket = 32, },
@@ -1107,9 +1107,9 @@ static struct fifo_cfg __initdata mode_5_cfg[] = {
{ .hw_ep_num = 11, .style = FIFO_RX, .maxpacket = 32, },
{ .hw_ep_num = 12, .style = FIFO_TX, .maxpacket = 32, },
{ .hw_ep_num = 12, .style = FIFO_RX, .maxpacket = 32, },
-{ .hw_ep_num = 13, .style = FIFO_RXTX, .maxpacket = 512, },
-{ .hw_ep_num = 14, .style = FIFO_RXTX, .maxpacket = 1024, },
-{ .hw_ep_num = 15, .style = FIFO_RXTX, .maxpacket = 1024, },
+{ .hw_ep_num = 13, .style = FIFO_RXTX, .maxpacket = 128, },
+{ .hw_ep_num = 14, .style = FIFO_RXTX, .maxpacket = 256, },
+{ .hw_ep_num = 15, .style = FIFO_RXTX, .maxpacket = 4096, },
};
/*
--
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
Re: [PATCH v5 1/5] omap3: pm: fix for twl4030 script load
Hello Lesly,
On Tue, May 04, 2010 at 09:37:10AM +0200, ext Lesly Arackal Manuel wrote:
> > -Original Message-
> > From: Eduardo Valentin [mailto:eduardo.valen...@nokia.com]
> > Sent: Tuesday, May 04, 2010 11:57 AM
> > To: ext Lesly A M
> > Cc: linux-omap@vger.kernel.org; Lesly A M; Nishanth Menon; David Derrick;
> > Samuel Ortiz
> > Subject: Re: [PATCH v5 1/5] omap3: pm: fix for twl4030 script load
> >
> > Hello Lesly,
> >
> > On Mon, Apr 19, 2010 at 01:43:00PM +0200, ext Lesly A M wrote:
> > > This patch will fix the TRITON sleep/wakeup sequence.
> >
> > OK.
> >
> > >
> > > Since the function to populate the sleep script is getting called always
> > > irrespective of the flag "TWL4030_SLEEP_SCRIPT", other scripts data
> > > is getting over written by the sleep script.
> >
> > Yes, and that is because of missing curls {}.
> >
> > >
> > > Also removing the order checking while loading the scripts,
> > > since the order doesn't matter. Only the values configured
> > > in the register, which is pointing to the starting address
> > > of each sequence should be correct.
> >
> > Are sure about that. Please check commig
> > 75a7456539224c5c5c254130afdb18bd7eb2286f
> > At least from that description, Amit was very convincing that loading
> > order matters.
> >
> > Author: Amit Kucheria
> > Date: Mon Aug 17 17:01:56 2009 +0300
> >
> > mfd: Print warning for twl4030 out-of-order script loading
> >
> > When the sleep script is loaded before the wakeup script, there is a
> > chance that the system might go to sleep before the wakeup script
> > loading is completed. This will lead to a system that does not wakeup
> > and has been observed to cause non-booting boards.
> >
> > >
> > > Signed-off-by: Lesly A M
> > > Cc: Nishanth Menon
> > > Cc: David Derrick
> > > Cc: Samuel Ortiz
> > > ---
> > > drivers/mfd/twl4030-power.c |6 --
> > > 1 files changed, 0 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
> > > index 7efa878..bd98733 100644
> > > --- a/drivers/mfd/twl4030-power.c
> > > +++ b/drivers/mfd/twl4030-power.c
> > > @@ -423,7 +423,6 @@ static int __init load_twl4030_script(struct
> > twl4030_script *tscript,
> > > u8 address)
> > > {
> > > int err;
> > > - static int order;
> > >
> > > /* Make sure the script isn't going beyond last valid address (0x3f)
> > */
> > > if ((address + tscript->size) > END_OF_SCRIPT) {
> > > @@ -444,7 +443,6 @@ static int __init load_twl4030_script(struct
> > twl4030_script *tscript,
> > > err = twl4030_config_wakeup12_sequence(address);
> > > if (err)
> > > goto out;
> > > - order = 1;
> > > }
> > > if (tscript->flags & TWL4030_WAKEUP3_SCRIPT) {
> > > err = twl4030_config_wakeup3_sequence(address);
> > > @@ -452,10 +450,6 @@ static int __init load_twl4030_script(struct
> > twl4030_script *tscript,
> > > goto out;
> > > }
> > > if (tscript->flags & TWL4030_SLEEP_SCRIPT)
> > > - if (order)
> > > - pr_warning("TWL4030: Bad order of scripts (sleep "\
> > > - "script before wakeup) Leads to
> boot"\
> > > - "failure on some boards\n");
> > > err = twl4030_config_sleep_sequence(address);
> >
> >
> > If the problem you are trying to address is the fact that everything goes
> > to
> > sleep address, then just embrace the conditional into brackets.
> >
>
>
> Hi Eduardo,
>
> The load_twl4030_script() is called from twl4030_power_init() which is again
> called from twl_probe(), and this is getting called before
> omap3_idle_init().
>
> So the scripts are loaded before the cpuidle is initialized.
> Then I don't think the system will hit sys_off before loading the scripts.
Yes indeed. At first glance I would expect same thing. But there must be a
reason
for that patch :-). Maybe Amit can comment better on the problem he was
addressing.
I'm ccing him.
>
> Regards,
> Lesly
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 6/8] omap: mailbox: more more stuff to omap2_mbox_init
On Tue, May 4, 2010 at 9:04 AM, Hiroshi DOYU wrote: > From: "ext Kanigeri, Hari" > Subject: RE: [RFC/PATCH 6/8] omap: mailbox: more more stuff to omap2_mbox_init > Date: Mon, 3 May 2010 20:50:39 +0200 >> 2. Compare iommu_get with mailbox_get. iommu_get uses >> driver_find_device to get the iommu structure. I guess we can apply >> the same logic to get mailbox structure. This way we can get rid of >> omap_mbox_register, omap_mbox_unregister, and find_mboxes functions. > > Right. The same logic could be applied. How? In omap2 there are two mailboxes, but the memory is the same. In omap4 there are two mailboxes, but the memory region _and_ irqs are the same. Platform devices cannot share resources... so all the mailboxes are part of a single platform device. -- 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
[no subject]
subscribe linux-omap -- 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
[no subject]
unsubscribe linux-omap ming.c...@authentec.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] AM35x: fix UI card EHCI port and LCD dependency
EHCI port on UI card and LCD share two pins (GPIO 181 and 182) thus
they have to be mutually exclusive.
Signed-off-by: Ajay Kumar Gupta
---
Patch adding config (CONFIG_PANEL_SHARP_LQ043T1DG01) in AM3517 defconfig
is already accepted and available in linux-omap/dss2 branch.
arch/arm/mach-omap2/board-am3517evm.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index c1c4389..837f294 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -119,6 +119,8 @@ static int __init am3517_evm_i2c_init(void)
static int lcd_enabled;
static int dvi_enabled;
+#if defined(CONFIG_PANEL_SHARP_LQ043T1DG01) || \
+ defined(CONFIG_PANEL_SHARP_LQ043T1DG01_MODULE)
static void __init am3517_evm_display_init(void)
{
int r;
@@ -162,6 +164,9 @@ err_2:
err_1:
gpio_free(LCD_PANEL_BKLIGHT_PWR);
}
+#else
+static void __init am3517_evm_display_init(void) {}
+#endif
static int am3517_evm_panel_enable_lcd(struct omap_dss_device *dssdev)
{
@@ -275,7 +280,12 @@ static void __init am3517_evm_init_irq(void)
static const struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
+#if defined(CONFIG_PANEL_SHARP_LQ043T1DG01) || \
+ defined(CONFIG_PANEL_SHARP_LQ043T1DG01_MODULE)
+ .port_mode[1] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+#else
.port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
+#endif
.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
.phy_reset = true,
--
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] usb: ehci-omap: fix compilation warning
Fixes below compilation warning: drivers/usb/host/ehci-hcd.c:425: warning: 'ehci_port_power' defined but not used Signed-off-by: Ajay Kumar Gupta --- drivers/usb/host/ehci-omap.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 40a8583..e55fd58 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -659,6 +659,8 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev) goto err_add_hcd; } + ehci_port_power(omap->ehci, 0); + return 0; err_add_hcd: -- 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] usb: ehci-omap: fix Si version related programming
AM3517 is based on ES3.1 thus ES2.x related programming is invalid
for it so updating ES2.x programming.
Also fixed below checkpatch warning:
WARNING: unnecessary whitespace before a quoted newline
Signed-off-by: Ajay Kumar Gupta
---
drivers/usb/host/ehci-omap.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index e55fd58..d5ff3e2 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -352,8 +352,8 @@ static int omap_start_ehc(struct ehci_hcd_omap *omap,
struct usb_hcd *hcd)
reg &= ~OMAP_UHH_HOSTCONFIG_P3_CONNECT_STATUS;
/* Bypass the TLL module for PHY mode operation */
-if (omap_rev() <= OMAP3430_REV_ES2_1) {
- dev_dbg(omap->dev, "OMAP3 ES version <= ES2.1 \n");
+ if (cpu_is_omap3430() && (omap_rev() <= OMAP3430_REV_ES2_1)) {
+ dev_dbg(omap->dev, "OMAP3 ES version <= ES2.1\n");
if ((omap->port_mode[0] == EHCI_HCD_OMAP_MODE_PHY) ||
(omap->port_mode[1] == EHCI_HCD_OMAP_MODE_PHY) ||
(omap->port_mode[2] == EHCI_HCD_OMAP_MODE_PHY))
--
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
Re: [PATCH] OMAP2/3/4: DMA: reset controller during init
On Mon, May 03, 2010 at 06:58:18PM +0200, ext Tony Lindgren wrote:
> * Mika Westerberg [100503 05:52]:
(...)
> > +/**
> > + * omap_dma_reset() - perform software reset for the DMA controller
> > + */
> > +static void omap_dma_reset(void)
> > +{
> > + u32 v;
> > +
> > + if (cpu_class_is_omap1())
> > + return;
> > +
> > + v = dma_read(OCP_SYSCONFIG);
> > + v |= 0x2; /* software reset */
> > + dma_write(v, OCP_SYSCONFIG);
> > +
> > + /* wait until reset is complete */
> > + while ((dma_read(SYSSTATUS) & 0x1) == 0)
> > + cpu_relax();
>
> This reset part seems to be mach-omap2 specific.
>
> > + /* disable per channel interrupts */
> > + dma_write(0, IRQENABLE_L0);
> > + dma_write(0, IRQENABLE_L1);
> > + dma_write(0, IRQENABLE_L2);
> > + dma_write(0, IRQENABLE_L3);
> > +}
>
> For a minimal fix, how about just disable the interrupt in omap_clear_dma()?
> We are already calling that from omap_init_dma().
If we do it in omap_clear_dma() then omap_dma_global_context_restore() will
return with interrupts masked which probably breaks things.
How about something like following patch?
(checking cpu_class_is_omap2() below in omap_init_dma() is probably redundant
but seems to be consitent with other code).
Thanks,
MW
>From 74389ff1de06e5adb84b978bf1d169c6d802db1b Mon Sep 17 00:00:00 2001
From: Mika Westerberg
Date: Tue, 4 May 2010 09:32:29 +0300
Subject: [PATCH] OMAP2/3/4: DMA: disable channel interrupts in omap_init_dma()
If we are softbooting another kernel using kexec, DMA controller state is not
known when we are performing omap_init_dma(). It is possible that some DMA
channels are already active. For example after kexec we get:
<4>IRQ 0020 for non-allocated DMAchannel 5
<4>IRQ 0020 for non-allocated DMAchannel 5
<4>IRQ 0020 for non-allocated DMAchannel 5
<4>IRQ 0020 for non-allocated DMAchannel 5
<4>IRQ 0020 for non-allocated DMAchannel 5
To prevent any weird things happening, we disable all channel interrupts during
init.
Signed-off-by: Mika Westerberg
---
arch/arm/plat-omap/dma.c | 27 +++
1 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 1d95996..ad42ec3 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -709,6 +709,21 @@ static inline void omap2_enable_irq_lch(int lch)
spin_unlock_irqrestore(&dma_chan_lock, flags);
}
+static inline void omap2_disable_irq_lch(int lch)
+{
+ u32 val;
+ unsigned long flags;
+
+ if (!cpu_class_is_omap2())
+ return;
+
+ spin_lock_irqsave(&dma_chan_lock, flags);
+ val = dma_read(IRQENABLE_L0);
+ val &= ~(1 << lch);
+ dma_write(val, IRQENABLE_L0);
+ spin_unlock_irqrestore(&dma_chan_lock, flags);
+}
+
int omap_request_dma(int dev_id, const char *dev_name,
void (*callback)(int lch, u16 ch_status, void *data),
void *data, int *dma_ch_out)
@@ -807,14 +822,7 @@ void omap_free_dma(int lch)
}
if (cpu_class_is_omap2()) {
- u32 val;
-
- spin_lock_irqsave(&dma_chan_lock, flags);
- /* Disable interrupts */
- val = dma_read(IRQENABLE_L0);
- val &= ~(1 << lch);
- dma_write(val, IRQENABLE_L0);
- spin_unlock_irqrestore(&dma_chan_lock, flags);
+ omap2_disable_irq_lch(lch);
/* Clear the CSR register and IRQ status register */
dma_write(OMAP2_DMA_CSR_CLEAR_MASK, CSR(lch));
@@ -2107,6 +2115,9 @@ static int __init omap_init_dma(void)
for (ch = 0; ch < dma_chan_count; ch++) {
omap_clear_dma(ch);
+ if (cpu_class_is_omap2())
+ omap2_disable_irq_lch(ch);
+
dma_chan[ch].dev_id = -1;
dma_chan[ch].next_lch = -1;
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 1/5] omap3: pm: fix for twl4030 script load
> -Original Message-
> From: Eduardo Valentin [mailto:eduardo.valen...@nokia.com]
> Sent: Tuesday, May 04, 2010 11:57 AM
> To: ext Lesly A M
> Cc: linux-omap@vger.kernel.org; Lesly A M; Nishanth Menon; David Derrick;
> Samuel Ortiz
> Subject: Re: [PATCH v5 1/5] omap3: pm: fix for twl4030 script load
>
> Hello Lesly,
>
> On Mon, Apr 19, 2010 at 01:43:00PM +0200, ext Lesly A M wrote:
> > This patch will fix the TRITON sleep/wakeup sequence.
>
> OK.
>
> >
> > Since the function to populate the sleep script is getting called always
> > irrespective of the flag "TWL4030_SLEEP_SCRIPT", other scripts data
> > is getting over written by the sleep script.
>
> Yes, and that is because of missing curls {}.
>
> >
> > Also removing the order checking while loading the scripts,
> > since the order doesn't matter. Only the values configured
> > in the register, which is pointing to the starting address
> > of each sequence should be correct.
>
> Are sure about that. Please check commig
> 75a7456539224c5c5c254130afdb18bd7eb2286f
> At least from that description, Amit was very convincing that loading
> order matters.
>
> Author: Amit Kucheria
> Date: Mon Aug 17 17:01:56 2009 +0300
>
> mfd: Print warning for twl4030 out-of-order script loading
>
> When the sleep script is loaded before the wakeup script, there is a
> chance that the system might go to sleep before the wakeup script
> loading is completed. This will lead to a system that does not wakeup
> and has been observed to cause non-booting boards.
>
> >
> > Signed-off-by: Lesly A M
> > Cc: Nishanth Menon
> > Cc: David Derrick
> > Cc: Samuel Ortiz
> > ---
> > drivers/mfd/twl4030-power.c |6 --
> > 1 files changed, 0 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
> > index 7efa878..bd98733 100644
> > --- a/drivers/mfd/twl4030-power.c
> > +++ b/drivers/mfd/twl4030-power.c
> > @@ -423,7 +423,6 @@ static int __init load_twl4030_script(struct
> twl4030_script *tscript,
> >u8 address)
> > {
> > int err;
> > - static int order;
> >
> > /* Make sure the script isn't going beyond last valid address (0x3f)
> */
> > if ((address + tscript->size) > END_OF_SCRIPT) {
> > @@ -444,7 +443,6 @@ static int __init load_twl4030_script(struct
> twl4030_script *tscript,
> > err = twl4030_config_wakeup12_sequence(address);
> > if (err)
> > goto out;
> > - order = 1;
> > }
> > if (tscript->flags & TWL4030_WAKEUP3_SCRIPT) {
> > err = twl4030_config_wakeup3_sequence(address);
> > @@ -452,10 +450,6 @@ static int __init load_twl4030_script(struct
> twl4030_script *tscript,
> > goto out;
> > }
> > if (tscript->flags & TWL4030_SLEEP_SCRIPT)
> > - if (order)
> > - pr_warning("TWL4030: Bad order of scripts (sleep "\
> > - "script before wakeup) Leads to
boot"\
> > - "failure on some boards\n");
> > err = twl4030_config_sleep_sequence(address);
>
>
> If the problem you are trying to address is the fact that everything goes
> to
> sleep address, then just embrace the conditional into brackets.
>
Hi Eduardo,
The load_twl4030_script() is called from twl4030_power_init() which is again
called from twl_probe(), and this is getting called before
omap3_idle_init().
So the scripts are loaded before the cpuidle is initialized.
Then I don't think the system will hit sys_off before loading the scripts.
Regards,
Lesly
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/11] omap2/3/4: Disable CONFIG_FB_OMAP in omap3_defconfig
Hi, On Tue, 2010-05-04 at 02:52 +0200, ext Tony Lindgren wrote: > * Tony Lindgren [100430 13:47]: > > * Tony Lindgren [100430 13:32]: > > > Looks like CONFIG_FB_OMAP prevents somehow mounting root on MMC > > > at least on zoom3 for multi-omap. Disable CONFIG_FB until the > > > omap FB code is fixed. > > > > This one I'll drop as soon as the problem is sorted out with > > CONFIG_FB_OMAP. > > This one seems to be something under drivers/video/omap, so > I'll change CONFIG_FB_OMAP to be a module now. Updated patch > below. > > I'll update omap for-next accordingly, then Tomi can figure > it out :) This sounds... interesting... =) Any more info on what happens? Does it also affect new omapfb driver? Tomi -- 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
