Re: [PATCH 17/18] omap: rx51: Add supplies for the tlv320aic3x codec driver
On Thu, May 06, 2010 at 08:57:16AM +0200, Valentin Eduardo (Nokia-D/Helsinki)
wrote:
> Hello Jarkko,
>
> Just minor comments on this one, sorry for being late for that.
>
> On Wed, May 05, 2010 at 09:33:23PM +0200, ext Tony Lindgren wrote:
> > From: Jarkko Nikula
> >
> > Upcoming change to tlv320aic3x codec driver require four supplies.
> > Implement this by connecting analogic supplies to TWL4030 VMMC2 and digital
> > supplies to TWL4030 VIO.
> >
> > Signed-off-by: Jarkko Nikula
> > Cc: Eduardo Valentin
> > Signed-off-by: Tony Lindgren
> > ---
> > arch/arm/mach-omap2/board-rx51-peripherals.c | 60
> > +++---
> > 1 files changed, 53 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
> > b/arch/arm/mach-omap2/board-rx51-peripherals.c
> > index 3addfe6..8179d55 100644
> > --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
> > +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
> > @@ -277,7 +277,7 @@ static struct regulator_consumer_supply
> > rx51_vmmc1_supply = {
> > .dev_name = "mmci-omap-hs.0",
> > };
> >
> > -static struct regulator_consumer_supply rx51_vmmc2_supply = {
> > +static struct regulator_consumer_supply rx51_vaux3_supply = {
> > .supply = "vmmc",
> > .dev_name = "mmci-omap-hs.1",
> > };
> > @@ -287,6 +287,35 @@ static struct regulator_consumer_supply
> > rx51_vsim_supply = {
> > .dev_name = "mmci-omap-hs.1",
> > };
> >
> > +static struct regulator_consumer_supply rx51_vmmc2_supplies[] = {
> > + /* tlv320aic3x analog supplies */
> > + {
> > + .supply = "AVDD",
> > + .dev_name = "2-0018",
> > + },
> > + {
> > + .supply = "DRVDD",
> > + .dev_name = "2-0018",
> > + },
> > + /* Keep vmmc as last item. It is not iterated for newer boards */
> > + {
> > + .supply = "vmmc",
> > + .dev_name = "mmci-omap-hs.1",
> > + },
> > +};
> > +
> > +static struct regulator_consumer_supply rx51_vio_supplies[] = {
> > + /* tlv320aic3x digital supplies */
> > + {
> > + .supply = "IOVDD",
> > + .dev_name = "2-0018"
> > + },
> > + {
> > + .supply = "DVDD",
> > + .dev_name = "2-0018"
> > + },
> > +};
>
>
> This isn't mandatory, but I find the code more readable if you use the
> REGULATOR_SUPPLY macro,
> which kinda suitable for cases like yours, where you are passing the pair
> supply&dev_name.
> > +
> > static struct regulator_init_data rx51_vaux1 = {
> > .constraints = {
> > .name = "V28",
> > @@ -338,7 +367,7 @@ static struct regulator_init_data rx51_vaux3_mmc = {
> > | REGULATOR_CHANGE_STATUS,
> > },
> > .num_consumer_supplies = 1,
> > - .consumer_supplies = &rx51_vmmc2_supply,
> > + .consumer_supplies = &rx51_vaux3_supply,
> > };
> >
> > static struct regulator_init_data rx51_vaux4 = {
> > @@ -380,8 +409,8 @@ static struct regulator_init_data rx51_vmmc2 = {
> > | REGULATOR_CHANGE_MODE
> > | REGULATOR_CHANGE_STATUS,
> > },
> > - .num_consumer_supplies = 1,
> > - .consumer_supplies = &rx51_vmmc2_supply,
> > + .num_consumer_supplies = ARRAY_SIZE(rx51_vmmc2_supplies),
> > + .consumer_supplies = rx51_vmmc2_supplies,
> > };
> >
> > static struct regulator_init_data rx51_vsim = {
> > @@ -411,6 +440,20 @@ static struct regulator_init_data rx51_vdac = {
> > },
> > };
> >
> > +static struct regulator_init_data rx51_vio = {
> > + .constraints = {
> > + .min_uV = 180,
> > + .max_uV = 180,
> > + .valid_modes_mask = REGULATOR_MODE_NORMAL
> > + | REGULATOR_MODE_STANDBY,
> > + .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
>
> I'm not sure if we would ever change voltage level in VIO in rx51 case.
> It could enter sleep mode. But even there it wouldn't change voltage level.
> Except, of cource, during off mode transition. But then, the regfw wouldn't
> care.
Actually, one correction here, even during off mode transition I believe we
need to
keep it, otherwise some wake up source would be screwed.
>
>
> > + | REGULATOR_CHANGE_MODE
> > + | REGULATOR_CHANGE_STATUS,
> > + },
> > + .num_consumer_supplies = ARRAY_SIZE(rx51_vio_supplies),
> > + .consumer_supplies = rx51_vio_supplies,
> > +};
> > +
> > static int rx51_twlgpio_setup(struct device *dev, unsigned gpio, unsigned
> > n)
> > {
> > /* FIXME this gpio setup is just a placeholder for now */
> > @@ -618,6 +661,7 @@ static struct twl4030_platform_data rx51_twldata
> > __initdata = {
> > .vmmc1 = &rx51_vmmc1,
> > .vsim = &r
Re: [PATCH 17/18] omap: rx51: Add supplies for the tlv320aic3x codec driver
Hello Jarkko,
Just minor comments on this one, sorry for being late for that.
On Wed, May 05, 2010 at 09:33:23PM +0200, ext Tony Lindgren wrote:
> From: Jarkko Nikula
>
> Upcoming change to tlv320aic3x codec driver require four supplies.
> Implement this by connecting analogic supplies to TWL4030 VMMC2 and digital
> supplies to TWL4030 VIO.
>
> Signed-off-by: Jarkko Nikula
> Cc: Eduardo Valentin
> Signed-off-by: Tony Lindgren
> ---
> arch/arm/mach-omap2/board-rx51-peripherals.c | 60
> +++---
> 1 files changed, 53 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
> b/arch/arm/mach-omap2/board-rx51-peripherals.c
> index 3addfe6..8179d55 100644
> --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
> +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
> @@ -277,7 +277,7 @@ static struct regulator_consumer_supply rx51_vmmc1_supply
> = {
> .dev_name = "mmci-omap-hs.0",
> };
>
> -static struct regulator_consumer_supply rx51_vmmc2_supply = {
> +static struct regulator_consumer_supply rx51_vaux3_supply = {
> .supply = "vmmc",
> .dev_name = "mmci-omap-hs.1",
> };
> @@ -287,6 +287,35 @@ static struct regulator_consumer_supply rx51_vsim_supply
> = {
> .dev_name = "mmci-omap-hs.1",
> };
>
> +static struct regulator_consumer_supply rx51_vmmc2_supplies[] = {
> + /* tlv320aic3x analog supplies */
> + {
> + .supply = "AVDD",
> + .dev_name = "2-0018",
> + },
> + {
> + .supply = "DRVDD",
> + .dev_name = "2-0018",
> + },
> + /* Keep vmmc as last item. It is not iterated for newer boards */
> + {
> + .supply = "vmmc",
> + .dev_name = "mmci-omap-hs.1",
> + },
> +};
> +
> +static struct regulator_consumer_supply rx51_vio_supplies[] = {
> + /* tlv320aic3x digital supplies */
> + {
> + .supply = "IOVDD",
> + .dev_name = "2-0018"
> + },
> + {
> + .supply = "DVDD",
> + .dev_name = "2-0018"
> + },
> +};
This isn't mandatory, but I find the code more readable if you use the
REGULATOR_SUPPLY macro,
which kinda suitable for cases like yours, where you are passing the pair
supply&dev_name.
> +
> static struct regulator_init_data rx51_vaux1 = {
> .constraints = {
> .name = "V28",
> @@ -338,7 +367,7 @@ static struct regulator_init_data rx51_vaux3_mmc = {
> | REGULATOR_CHANGE_STATUS,
> },
> .num_consumer_supplies = 1,
> - .consumer_supplies = &rx51_vmmc2_supply,
> + .consumer_supplies = &rx51_vaux3_supply,
> };
>
> static struct regulator_init_data rx51_vaux4 = {
> @@ -380,8 +409,8 @@ static struct regulator_init_data rx51_vmmc2 = {
> | REGULATOR_CHANGE_MODE
> | REGULATOR_CHANGE_STATUS,
> },
> - .num_consumer_supplies = 1,
> - .consumer_supplies = &rx51_vmmc2_supply,
> + .num_consumer_supplies = ARRAY_SIZE(rx51_vmmc2_supplies),
> + .consumer_supplies = rx51_vmmc2_supplies,
> };
>
> static struct regulator_init_data rx51_vsim = {
> @@ -411,6 +440,20 @@ static struct regulator_init_data rx51_vdac = {
> },
> };
>
> +static struct regulator_init_data rx51_vio = {
> + .constraints = {
> + .min_uV = 180,
> + .max_uV = 180,
> + .valid_modes_mask = REGULATOR_MODE_NORMAL
> + | REGULATOR_MODE_STANDBY,
> + .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
I'm not sure if we would ever change voltage level in VIO in rx51 case.
It could enter sleep mode. But even there it wouldn't change voltage level.
Except, of cource, during off mode transition. But then, the regfw wouldn't
care.
> + | REGULATOR_CHANGE_MODE
> + | REGULATOR_CHANGE_STATUS,
> + },
> + .num_consumer_supplies = ARRAY_SIZE(rx51_vio_supplies),
> + .consumer_supplies = rx51_vio_supplies,
> +};
> +
> static int rx51_twlgpio_setup(struct device *dev, unsigned gpio, unsigned n)
> {
> /* FIXME this gpio setup is just a placeholder for now */
> @@ -618,6 +661,7 @@ static struct twl4030_platform_data rx51_twldata
> __initdata = {
> .vmmc1 = &rx51_vmmc1,
> .vsim = &rx51_vsim,
> .vdac = &rx51_vdac,
> + .vio= &rx51_vio,
> };
>
> static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_1[]
> = {
> @@ -638,12 +682,14 @@ static struct i2c_board_info __initdata
> rx51_peripherals_i2c_board_info_2[] = {
> static int __init rx51_i2c_init(void)
> {
> if ((system_rev >= SYS
RE: [PATCH]omap: mux.c warning removal
Hi Kevin Thanks for review comments! The updated patch is below. From: Keshava Munegowda This patch removes the below warning arch/arm/mach-omap2/mux.c:52: warning: 'mux_phys' defined but not used The definition of variable mux_phys should be enclosed in the macro CONFIG_ARCH_OMAP3 Signed-off-by: Keshava Munegowda Index: linux-2.6/arch/arm/mach-omap2/mux.c === --- linux-2.6.orig/arch/arm/mach-omap2/mux.c2010-05-05 23:59:19.0 +0530 +++ linux-2.6/arch/arm/mach-omap2/mux.c 2010-05-06 00:00:07.0 +0530 @@ -49,7 +49,7 @@ struct list_headnode; }; -static unsigned long mux_phys; + static void __iomem *mux_base; u16 omap_mux_read(u16 reg) @@ -373,6 +373,7 @@ #ifdef CONFIG_ARCH_OMAP3 static LIST_HEAD(muxmodes); static DEFINE_MUTEX(muxmode_mutex); +static unsigned long mux_phys; #ifdef CONFIG_OMAP_MUX > -Original Message- > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > Sent: Thursday, May 06, 2010 2:52 AM > To: Munegowda, Keshava > Cc: linux-omap@vger.kernel.org; t...@atomide.com > Subject: Re: [PATCH]omap: mux.c warning removal > > "Munegowda, Keshava" writes: > > > From: Keshava Munegowda > > > > This patch removes the below warning > > arch/arm/mach-omap2/mux.c:52: warning: 'mux_phys' defined but not used > > The definition of variable mux_phys should be enclosed in the macro > > CONFIG_ARCH_OMAP3 > > > > Signed-off-by: Keshava Munegowda > > Index: linux-2.6/arch/arm/mach-omap2/mux.c > > === > > --- linux-2.6.orig/arch/arm/mach-omap2/mux.c2010-05-05 > > 05:28:47.0 +0530 > > +++ linux-2.6/arch/arm/mach-omap2/mux.c 2010-05-05 05:29:02.0 > > +0530 > > @@ -49,7 +49,9 @@ > > struct list_headnode; > > }; > > > > +#ifdef CONFIG_ARCH_OMAP3 > > static unsigned long mux_phys; > > +#endif > > Rather than add another #ifdef, just move this inside the existing > #ifdef farther down in the file. > > Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP3: wait on IDLEST after enabling USBTLL fclk
We need to wait on the IDLEST bit after the clocks are enabled
before attempting to access any register.
Currently, the USBTLL i-clock ops uses the clkops_omap2_dflt_wait,
while the USBTLL f-clock ops uses clkops_omap2_dflt. If the
i-clock is enabled first, the clkops_omap2_dflt_wait is
short-circuited as the companion f-clock is not enabled.
This can cause a data abort if the IDLEST has not transitioned,
and we try to access a USBTLL register.
Since the USBTLL i-clock and f-clock could be enabled in any order,
this is a bug. Fix it by changing the clkops for the f-clock.
Signed-off-by: Anand Gadiyar
---
arch/arm/mach-omap2/clock3xxx_data.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-omap-2.6/arch/arm/mach-omap2/clock3xxx_data.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/clock3xxx_data.c
+++ linux-omap-2.6/arch/arm/mach-omap2/clock3xxx_data.c
@@ -1484,7 +1484,7 @@ static struct clk ts_fck = {
static struct clk usbtll_fck = {
.name = "usbtll_fck",
- .ops= &clkops_omap2_dflt,
+ .ops= &clkops_omap2_dflt_wait,
.parent = &dpll5_m2_ck,
.enable_reg = OMAP_CM_REGADDR(CORE_MOD, OMAP3430ES2_CM_FCLKEN3),
.enable_bit = OMAP3430ES2_EN_USBTLL_SHIFT,
--
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 v3 0/4] omap: mailbox: cleanup & simplify
From: ext Ohad Ben-Cohen Subject: [PATCH v3 0/4] omap: mailbox: cleanup & simplify Date: Wed, 5 May 2010 17:33:05 +0200 > This series includes comments from Hiroshi and Tony (thanks!). > > Changes since v2: > - add mbox_kfifo_size module parameter sanity checks > - remove (un)likely macros from cold mailbox paths Acked-by: Hiroshi DOYU > > Thanks, > Ohad. > > --- > If you want, you can also reach me at < ohadb at ti dot com >. > > Ohad Ben-Cohen (4): > omap: mailbox: convert rwlocks to spinlock > omap: mailbox cleanup: split MODULE_AUTHOR line > omap: mailbox: remove (un)likely macros from cold paths > omap: mailbox: convert block api to kfifo > > arch/arm/mach-omap2/mailbox.c |3 +- > arch/arm/plat-omap/Kconfig|9 ++ > arch/arm/plat-omap/include/plat/mailbox.h |4 +- > arch/arm/plat-omap/mailbox.c | 155 > ++--- > 4 files changed, 87 insertions(+), 84 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] omap: mailbox: fix reverse likeliness
Hi Tony,
From: ext Tony Lindgren
Subject: Re: [PATCH v2 3/4] omap: mailbox: fix reverse likeliness
Date: Wed, 5 May 2010 17:21:35 +0200
> * Ohad Ben-Cohen [100504 04:42]:
>> 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:
>
> Looks good to me.
>
> Hiroshi, care to ack/nak all the mailbox and iommu patches you want
> me to merge? Or if you have them in some git branch against mainline
> -rc6 that would be cool too.
Feel free to add my ACK on them. Looks ok to me too.
If there's more patches coming, I can consider to collect patches and
to provide git branches for mailbox and iommu for next merge.
--
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 v1 2/3] OMAP4: Ethernet: KS8851 Board Support
Manjunath,
> > > > > > > +
> > > > > > > +static void omap_ethernet_init(void)
> > > > > > > +{
> > > > > > > + gpio_request(ETHERNET_KS8851_POWER_ENABLE, "ethernet");
> > > > > > > + gpio_direction_output(ETHERNET_KS8851_POWER_ENABLE, 1);
> > > > > > > + gpio_request(ETHERNET_KS8851_QUART, "quart");
> > > > > > > + gpio_direction_output(ETHERNET_KS8851_QUART, 1);
> > > > > > > + gpio_request(ETHERNET_KS8851_IRQ, "ks8851");
> > > > > >
> > > > > > Any reason for not checking return value of gpio_request()?
> > > > > >
[snip]
> Minor changes:
> if (gpio_request(x))
> return status;
> if (gpio_request(y))
> goto err1;
> if (gpio_request(z))
> goto err2;
> ...
> return 0;
>
> err2:
> free(y);
>
> err1:
> free(x);
> return status;
How about this patch?
Note. I am thinking in spi_register_board_info registration:
1. to be done if ethernet fails, other spi dev can be added in future
2. not to be done if ethernet fails, no other dev in spi bus 1 for now
What is the best approach? Is it to keep #2?
---
#define ETH_KS8851_IRQ 34
#define ETH_KS8851_POWER_ON 48
#define ETH_KS8851_QUART138
static struct spi_board_info sdp4430_spi_board_info[] __initdata = {
{
.modalias = "ks8851",
.bus_num= 1,
.chip_select= 0,
.max_speed_hz = 2400,
.irq= ETH_KS8851_IRQ,
},
};
static int omap_ethernet_init(void)
{
int status;
status = gpio_request(ETH_KS8851_POWER_ON, "eth_power");
if (status < 0) {
pr_warning("Cannot request GPIO %d\n", ETH_KS8851_POWER_ON);
return status;
}
status = gpio_request(ETH_KS8851_QUART, "quart");
if (status < 0) {
pr_warning("Cannot request GPIO %d\n", ETH_KS8851_QUART);
goto err1;
}
status = gpio_request(ETH_KS8851_IRQ, "eth_irq");
if (status < 0) {
pr_warning("Cannot request GPIO %d\n", ETH_KS8851_IRQ);
goto err2;
}
gpio_direction_output(ETH_KS8851_POWER_ON, 1);
gpio_direction_output(ETH_KS8851_QUART, 1);
gpio_direction_input(ETH_KS8851_IRQ);
return status;
err2:
gpio_free(ETH_KS8851_QUART);
err1:
gpio_free(ETH_KS8851_POWER_ON);
return status;
}
[...]
/* FIXME: allow multi-omap to boot until musb is updated for omap4 */
if (!cpu_is_omap44xx())
usb_musb_init(&musb_board_data);
status = omap_ethernet_init();
if (status)
pr_warning("Ethernet initialization failed: %d\n", status);
else
sdp4430_spi_board_info[0].irq = gpio_to_irq(ETH_KS8851_IRQ);
spi_register_board_info(sdp4430_spi_board_info,
ARRAY_SIZE(sdp4430_spi_board_info));
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: Possible bug in onenand_base ?
Hi,
Can you add this statement at below the code?
printk("%s[%d] page %d, %d, %d\n", __func__, __LINE__, page, (int)
onenand_addr(this, block), ((int) addr >> this->page_shift) &
this->page_mask);
In my test environment, it displays the correct page number.
(addr - onenand_addr(this, block) >> this->page_shift is same as
'(addr >> this->page_shift) & this->page_mask'.
Thank you,
Kyungmin Park
On Fri, Apr 30, 2010 at 7:05 PM, 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/
>
--
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 v1 2/3] OMAP4: Ethernet: KS8851 Board Support
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org
> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of G,
> Manjunath Kondaiah
> Sent: Thursday, May 06, 2010 8:45 AM
> To: Arce, Abraham; Tony Lindgren
> Cc: linux-omap@vger.kernel.org;
> spi-devel-gene...@lists.sourceforge.net
> Subject: RE: [PATCH v1 2/3] OMAP4: Ethernet: KS8851 Board Support
>
>
>
> > -Original Message-
> > From: Arce, Abraham
> > Sent: Thursday, May 06, 2010 6:18 AM
> > To: Tony Lindgren
> > Cc: G, Manjunath Kondaiah; linux-omap@vger.kernel.org;
> > spi-devel-gene...@lists.sourceforge.net
> > Subject: RE: [PATCH v1 2/3] OMAP4: Ethernet: KS8851 Board Support
> >
> > > > > > +
> > > > > > +static void omap_ethernet_init(void)
> > > > > > +{
> > > > > > + gpio_request(ETHERNET_KS8851_POWER_ENABLE, "ethernet");
> > > > > > + gpio_direction_output(ETHERNET_KS8851_POWER_ENABLE, 1);
> > > > > > + gpio_request(ETHERNET_KS8851_QUART, "quart");
> > > > > > + gpio_direction_output(ETHERNET_KS8851_QUART, 1);
> > > > > > + gpio_request(ETHERNET_KS8851_IRQ, "ks8851");
> > > > >
> > > > > Any reason for not checking return value of gpio_request()?
> > > > >
> > > >
> > > > Thought initially about them as dedicated lines for
> > ethernet avoiding
> > > > both reasons to check for a gpio's request:
> > > >
> > > > 1. invalid gpio
> > > > 2. already claimed gpio
> > >
> > > You still need to check for the result.
> > >
> >
> > Is the below approach ok? Using goto would make it better?
> >
> > int status;
> >
> > status = gpio_request(ETHERNET_KS8851_POWER_ENABLE,
> > "ethernet");
> > if (status < 0)
>
> You need to have warning message about this failure.
>
> > return status;
> >
> > gpio_request(ETHERNET_KS8851_QUART, "quart");
> > if (status < 0) {
>
> -Ditto-
>
> > gpio_free(ETHERNET_KS8851_POWER_ENABLE);
> > return status;
>
> Return to where? This function seems to be void, change signature
> of this API.
>
> > }
> >
> > gpio_request(ETHERNET_KS8851_IRQ, "ks8851");
> > if (status < 0) {
>
> Bug! Checking previous status.
>
> > gpio_free(ETHERNET_KS8851_POWER_ENABLE);
> > gpio_free(ETHERNET_KS8851_QUART);
> > return status;
> > }
> >
> > gpio_direction_output(ETHERNET_KS8851_POWER_ENABLE, 1);
> > gpio_direction_output(ETHERNET_KS8851_QUART, 1);
> > gpio_direction_input(ETHERNET_KS8851_IRQ);
>
> Goto will be better approach compared to above logic.
>
> if(gpio_request(x)
> goto err1;
>
> if(gpio_request(y)
> goto err2;
>
> if(gpio_request(z)
> goto err3;
> ...
> return 0;
>
> err3:
> free(x);
> err2:
> free(y);
> err1:
> free(z);
>
> return status;
Minor changes:
if (gpio_request(x))
return status;
if (gpio_request(y))
goto err1;
if (gpio_request(z))
goto err2;
...
return 0;
err2:
free(y);
err1:
free(x);
return status;
-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
RE: [PATCH v1 2/3] OMAP4: Ethernet: KS8851 Board Support
> -Original Message-
> From: Arce, Abraham
> Sent: Thursday, May 06, 2010 6:18 AM
> To: Tony Lindgren
> Cc: G, Manjunath Kondaiah; linux-omap@vger.kernel.org;
> spi-devel-gene...@lists.sourceforge.net
> Subject: RE: [PATCH v1 2/3] OMAP4: Ethernet: KS8851 Board Support
>
> > > > > +
> > > > > +static void omap_ethernet_init(void)
> > > > > +{
> > > > > + gpio_request(ETHERNET_KS8851_POWER_ENABLE, "ethernet");
> > > > > + gpio_direction_output(ETHERNET_KS8851_POWER_ENABLE, 1);
> > > > > + gpio_request(ETHERNET_KS8851_QUART, "quart");
> > > > > + gpio_direction_output(ETHERNET_KS8851_QUART, 1);
> > > > > + gpio_request(ETHERNET_KS8851_IRQ, "ks8851");
> > > >
> > > > Any reason for not checking return value of gpio_request()?
> > > >
> > >
> > > Thought initially about them as dedicated lines for
> ethernet avoiding
> > > both reasons to check for a gpio's request:
> > >
> > > 1. invalid gpio
> > > 2. already claimed gpio
> >
> > You still need to check for the result.
> >
>
> Is the below approach ok? Using goto would make it better?
>
> int status;
>
> status = gpio_request(ETHERNET_KS8851_POWER_ENABLE,
> "ethernet");
> if (status < 0)
You need to have warning message about this failure.
> return status;
>
> gpio_request(ETHERNET_KS8851_QUART, "quart");
> if (status < 0) {
-Ditto-
> gpio_free(ETHERNET_KS8851_POWER_ENABLE);
> return status;
Return to where? This function seems to be void, change signature
of this API.
> }
>
> gpio_request(ETHERNET_KS8851_IRQ, "ks8851");
> if (status < 0) {
Bug! Checking previous status.
> gpio_free(ETHERNET_KS8851_POWER_ENABLE);
> gpio_free(ETHERNET_KS8851_QUART);
> return status;
> }
>
> gpio_direction_output(ETHERNET_KS8851_POWER_ENABLE, 1);
> gpio_direction_output(ETHERNET_KS8851_QUART, 1);
> gpio_direction_input(ETHERNET_KS8851_IRQ);
Goto will be better approach compared to above logic.
if(gpio_request(x)
goto err1;
if(gpio_request(y)
goto err2;
if(gpio_request(z)
goto err3;
...
return 0;
err3:
free(x);
err2:
free(y);
err1:
free(z);
return status;
-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
RE: [RFC] [PATCH 1/3] OMAP4: Keyboard Controller Support
Thanks Kevin,
> > Keyboard controller for OMAP4 with built-in scanning algorithm.
> > The following implementations are used:
> >
> > - matrix_keypac.c logic
> > - hwmod framework
> > - threaded irq
> >
> > Signed-off-by: Syed Rafiuddin
> > Signed-off-by: Abraham Arce
>
> Some general comments...
>
> What's missing here is a separation of the driver and the device.
> What you need is for arch code to register a platfrom_device (using
> hwmod + omap_device). Then this driver will use the standard
> platform_device resource calls to get its base address, IRQs, etc. and
> any platform_data.
>
> IOW, as Felipe mentioned, the driver should not be doing the hwmod +
> omap_device init and registration.
As metioned to Felipe, my approach is
sdp4430_keypad_init() {
...
omap_hwmod_lookup(oh_name);
...
kzalloc(sizeof(struct matrix_keypad_platform_data), GFP_KERNEL);
...
omap_device_build(name, id, oh, pdata,
...
}
and then called within
omap_4430sdp_init()
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: [PATCH] Add support for OMAP3Stalker boards
Thanks for replaying, I did have a long wait.
A question about board version. Is it good to do a hardware check to find
out hardware version?
Like function static void __init omap3_evm_get_revision(void) in
board-omap3evm.c
Best regards,
Jason
> -Original Message-
> From: Tony Lindgren [mailto:t...@atomide.com]
> Sent: 2010年5月5日 7:00
> To: Jason
> Cc: linux-omap@vger.kernel.org
> Subject: 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,
> >
RE: [PATCH] Disable the non working eMMC on Zoom2/3
> -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Wednesday, May 05, 2010 1:27 PM > To: Madhusudhan > Cc: 'Nishanth Menon'; 'Ghorai, Sukumar'; linux-omap@vger.kernel.org; > linux-...@vger.kernel.org > Subject: Re: [PATCH] Disable the non working eMMC on Zoom2/3 > > * Madhusudhan [100430 09:52]: > > > > > > > > > > > > > > > Hmm, finally got around looking into this again. Looks like the > mmc > > > > > > is now working on my zoom3 with the current Linus' tree at > commit > > > > > > 7c6bd2010fced38444c9fd658f4c6ce61bd185bf. So I guess something > that > > > > > > we had in omap-fixes fixed this. Or maybe some fix for > drivers/mmc? > > > > > > > > > > > > This is with the debug_ll patch applied: > > > > > > > > > > > > https://patchwork.kernel.org/patch/87532/ > > > > > > > > > > For the microSD card, turns out the card I used was flakey. So > > > > > that should explain some of the problems. I'm almost certain > > > > > I tried with two different cards earlier though. In any case, > > > > > let's assume the problem is only the eMMC. > > > > > > > > > Sorry, I did not get a complete picture. Your earlier email said > that > > > with > > > > Linus tree eMMC on your Zoom3 is working. Is that correct? > > > > > > Nope, now the microSD is working, eMMC is not working. > > > > > > > IMHO, an omap level fix can not solve the problem with eMMC because > as I > > > can > > > > see from the log you provided above that a 16G device is detected as > 1G. > > > > This is certainly due to the issue I mentioned earlier. > > > > > > OK > > > > This means that some production boards still have this issue with eMMC. > So > > my patch disables the support for MMC2 on zoom boards. Would you > consider > > that? > > But is it also broken on zoom2? > Yes. > And what about this "Simulate multi mmc card as one big" patch? > Did not get you, what patch are you referring to? Regards, Madhu > 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 v2 2/2] ARM: McBSP: 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 6696eb6..9a0e788 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 v2 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. Changes from v1: - Changed to correct IRQ lines. - Check if rx_irq is defined, instead of checking if cpu is omap4 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 v2 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..c293370 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 = OMAP44XX_IRQ_MCBSP1,
.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 = OMAP44XX_IRQ_MCBSP2,
.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 = OMAP44XX_IRQ_MCBSP3,
.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 = OMAP44XX_IRQ_MCBSP4,
.ops= &omap2_mcbsp_ops,
},
};
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index e1d0440..6696eb6 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 (mcbsp->rx_irq) {
+ 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 (mcbsp->rx_irq)
+ 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
RE: [PATCH 1/2] ARM: McBSP: Fix request for irq in OMAP4
Jarkko Nikula wrote:
> On Wed, 5 May 2010 08:32:13 +0530
> "G, Manjunath Kondaiah" wrote:
>
>>> - 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/
>>
> Threaded irq conversion would be better to handle as a separate patch
> as it does different thing than this patch.
I will redo this patch without threaded irq for now, and will do the
conversion in a later patch then.--
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 v1 2/3] OMAP4: Ethernet: KS8851 Board Support
> > > > +
> > > > +static void omap_ethernet_init(void)
> > > > +{
> > > > + gpio_request(ETHERNET_KS8851_POWER_ENABLE, "ethernet");
> > > > + gpio_direction_output(ETHERNET_KS8851_POWER_ENABLE, 1);
> > > > + gpio_request(ETHERNET_KS8851_QUART, "quart");
> > > > + gpio_direction_output(ETHERNET_KS8851_QUART, 1);
> > > > + gpio_request(ETHERNET_KS8851_IRQ, "ks8851");
> > >
> > > Any reason for not checking return value of gpio_request()?
> > >
> >
> > Thought initially about them as dedicated lines for ethernet avoiding
> > both reasons to check for a gpio's request:
> >
> > 1. invalid gpio
> > 2. already claimed gpio
>
> You still need to check for the result.
>
Is the below approach ok? Using goto would make it better?
int status;
status = gpio_request(ETHERNET_KS8851_POWER_ENABLE, "ethernet");
if (status < 0)
return status;
gpio_request(ETHERNET_KS8851_QUART, "quart");
if (status < 0) {
gpio_free(ETHERNET_KS8851_POWER_ENABLE);
return status;
}
gpio_request(ETHERNET_KS8851_IRQ, "ks8851");
if (status < 0) {
gpio_free(ETHERNET_KS8851_POWER_ENABLE);
gpio_free(ETHERNET_KS8851_QUART);
return status;
}
gpio_direction_output(ETHERNET_KS8851_POWER_ENABLE, 1);
gpio_direction_output(ETHERNET_KS8851_QUART, 1);
gpio_direction_input(ETHERNET_KS8851_IRQ);
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: [PM][PATCH v3 2/4] OMAP3: Serial: Errata i202: fix for MDR1 access
Kattungal, Deepak had written, on 05/05/2010 07:19 PM, the following:
Hi Kevin,
My Comments as below.
Regards
Deepak
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Wednesday, May 05, 2010 6:55 PM
To: Menon, Nishanth
Cc: linux-omap; Kattungal, Deepak; Raja, Govindraj; Tero Kristo
Subject: Re: [PM][PATCH v3 2/4] OMAP3: Serial: Errata i202: fix for MDR1 access
Nishanth Menon writes:
From: Deepak K
Original patch:
http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=42d4a342c009bd9727c100abc8a4bc3063c22f0c
Errata i202 (OMAP3430 - 1.12, OMAP3630 - 1.6):
This workaround is currently done for all OMAPs.
Presumably, this errata will eventually be fixed. So, as with other
errata fixes, we need some sort of SoC-rev based flag and the errata
workaround done based on that flag.
Deepak : This would be a good fix, thanks for the suggestion.
to confuse ;): I kinda disagree and agree on this..
Disagree:
The code in question is under CONFIG_ARCH_OMAP3 for context save and
restore -> yes, this errata is valid for for all OMAP3s SOCs currently.
OMAP4 and CONFIG_PM is not there yet in pm branch I suppose. at least in
the OMAP4 errata does not seem to have uart erratas any that I see of,
but given that the doc is pretty prelim, I will wait for final edition..
Agree: the patch mashes up errata code along with normal logic, making
it a bit difficult to read thru..
ideally, I would like to introduce:
struct omap_uart_state {
u16 errata;
}
set it and handle it accordingly.. 2cents: would have preferred to see
serial_override also do something similar though..
Also, shouldn't there be a fix for this in the 8250 and omap-serial
drivers too?
Deepak : The 8250 is not using the MDR Register. This would be needed only by
the omap-serial.
> The 8250 being a general driver we may not require the access to MDR1
register. Hence the fix not
> required for 8250.
hmm.. surprised MDR reg is settings b/w ir and uart settings which
should be ideally in serial.c(at the current location) and very omap
specific 8250 wont hit it, but wondering how omap-serial hits it.. gotta
dig at it sometime later..
any suggestions which path to take folks?
Kevin
UART module MDR1 register access can cause a dummy underrun
condition which could result in a freeze in the case of IrDA
communication or if used as UART, corrupted data.
Workaround is as follows for everytime MDR1 register is changed:
* setup all required UART registers
* setup MDR1.MODE_SELECT bit field
* Wait 5 L4 clk cycles + 5 UART functional clock cycles
* Clear the Tx and RX fifo using FCR register
Note: The following step is not done as I am assuming it is not
needed due to reconfiguration being done and there is no halted
operation perse.
* Read if required, the RESUME register to resume halted operation
Cc: Govindraj R
Cc: Kevin Hilman
Cc: Tero Kristo
Signed-off-by: Deepak K
Signed-off-by: Nishanth Menon
---
Changes from V2:
* Use macros instead of hardcoded values
Ref:
V2: http://marc.info/?t=127084514600010&r=1&w=2&n=2
v1: http://marc.info/?t=12707493315&r=1&w=2
arch/arm/mach-omap2/serial.c | 41 ++---
1 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index a7c45b5..6d13183 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -185,6 +185,42 @@ static inline void __init omap_uart_reset(struct
omap_uart_state *uart)
#if defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP3)
+/*
+ * Work Around for Errata i202 (3430 - 1.12, 3630 - 1.6)
+ * The access to uart register after MDR1 Access
+ * causes UART to corrupt data.
+ *
+ * Need a delay =
+ * 5 L4 clock cycles + 5 UART functional clock cycle (@48MHz = ~0.2uS)
+ * give 10 times as much
+ */
+static void omap_uart_mdr1_errataset(struct omap_uart_state *uart, u8 mdr1_val,
+ u8 fcr_val)
+{
+ struct plat_serial8250_port *p = uart->p;
+ u8 timeout = 255;
+
+ serial_write_reg(p, UART_OMAP_MDR1, mdr1_val);
+ udelay(2);
+ serial_write_reg(p, UART_FCR, fcr_val | UART_FCR_CLEAR_XMIT |
+ UART_FCR_CLEAR_RCVR);
+ /*
+* Wait for FIFO to empty: when empty, RX_FIFO_E bit is 0 and
+* TX_FIFO_E bit is 1.
+*/
+ while (UART_LSR_THRE != (serial_read_reg(p, UART_LSR) &
+ (UART_LSR_THRE | UART_LSR_DR))) {
+ timeout--;
+ if (!timeout) {
+ /* Should *never* happen. we warn and carry on */
+ dev_crit(&uart->pdev.dev, "Errata i202: timedout %x\n",
+ serial_read_reg(p, UART_LSR));
+ break;
+ }
+ udelay(1);
+ }
+}
+
static void omap_uart_save_context(struct omap_uart_state *uart)
{
u16 lcr = 0;
@@ -222,7 +258,7 @@ static
RE: [PM][PATCH v3 2/4] OMAP3: Serial: Errata i202: fix for MDR1 access
Hi Kevin,
My Comments as below.
Regards
Deepak
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Wednesday, May 05, 2010 6:55 PM
To: Menon, Nishanth
Cc: linux-omap; Kattungal, Deepak; Raja, Govindraj; Tero Kristo
Subject: Re: [PM][PATCH v3 2/4] OMAP3: Serial: Errata i202: fix for MDR1 access
Nishanth Menon writes:
> From: Deepak K
>
> Original patch:
> http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=42d4a342c009bd9727c100abc8a4bc3063c22f0c
>
> Errata i202 (OMAP3430 - 1.12, OMAP3630 - 1.6):
This workaround is currently done for all OMAPs.
Presumably, this errata will eventually be fixed. So, as with other
errata fixes, we need some sort of SoC-rev based flag and the errata
workaround done based on that flag.
Deepak : This would be a good fix, thanks for the suggestion.
Also, shouldn't there be a fix for this in the 8250 and omap-serial
drivers too?
Deepak : The 8250 is not using the MDR Register. This would be needed only by
the omap-serial. The 8250 being a general driver we may not require the access
to MDR1 register. Hence the fix not required for 8250.
Kevin
> UART module MDR1 register access can cause a dummy underrun
> condition which could result in a freeze in the case of IrDA
> communication or if used as UART, corrupted data.
>
> Workaround is as follows for everytime MDR1 register is changed:
> * setup all required UART registers
> * setup MDR1.MODE_SELECT bit field
> * Wait 5 L4 clk cycles + 5 UART functional clock cycles
> * Clear the Tx and RX fifo using FCR register
>
> Note: The following step is not done as I am assuming it is not
> needed due to reconfiguration being done and there is no halted
> operation perse.
> * Read if required, the RESUME register to resume halted operation
>
> Cc: Govindraj R
> Cc: Kevin Hilman
> Cc: Tero Kristo
>
> Signed-off-by: Deepak K
> Signed-off-by: Nishanth Menon
> ---
> Changes from V2:
> * Use macros instead of hardcoded values
>
> Ref:
> V2: http://marc.info/?t=127084514600010&r=1&w=2&n=2
> v1: http://marc.info/?t=12707493315&r=1&w=2
>
> arch/arm/mach-omap2/serial.c | 41 ++---
> 1 files changed, 38 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index a7c45b5..6d13183 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -185,6 +185,42 @@ static inline void __init omap_uart_reset(struct
> omap_uart_state *uart)
>
> #if defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP3)
>
> +/*
> + * Work Around for Errata i202 (3430 - 1.12, 3630 - 1.6)
> + * The access to uart register after MDR1 Access
> + * causes UART to corrupt data.
> + *
> + * Need a delay =
> + * 5 L4 clock cycles + 5 UART functional clock cycle (@48MHz = ~0.2uS)
> + * give 10 times as much
> + */
> +static void omap_uart_mdr1_errataset(struct omap_uart_state *uart, u8
> mdr1_val,
> + u8 fcr_val)
> +{
> + struct plat_serial8250_port *p = uart->p;
> + u8 timeout = 255;
> +
> + serial_write_reg(p, UART_OMAP_MDR1, mdr1_val);
> + udelay(2);
> + serial_write_reg(p, UART_FCR, fcr_val | UART_FCR_CLEAR_XMIT |
> + UART_FCR_CLEAR_RCVR);
> + /*
> + * Wait for FIFO to empty: when empty, RX_FIFO_E bit is 0 and
> + * TX_FIFO_E bit is 1.
> + */
> + while (UART_LSR_THRE != (serial_read_reg(p, UART_LSR) &
> + (UART_LSR_THRE | UART_LSR_DR))) {
> + timeout--;
> + if (!timeout) {
> + /* Should *never* happen. we warn and carry on */
> + dev_crit(&uart->pdev.dev, "Errata i202: timedout %x\n",
> + serial_read_reg(p, UART_LSR));
> + break;
> + }
> + udelay(1);
> + }
> +}
> +
> static void omap_uart_save_context(struct omap_uart_state *uart)
> {
> u16 lcr = 0;
> @@ -222,7 +258,7 @@ static void omap_uart_restore_context(struct
> omap_uart_state *uart)
>
> uart->context_valid = 0;
>
> - serial_write_reg(p, UART_OMAP_MDR1, 0x7);
> + omap_uart_mdr1_errataset(uart, 0x07, 0xA0);
> serial_write_reg(p, UART_LCR, 0xBF); /* Config B mode */
> efr = serial_read_reg(p, UART_EFR);
> serial_write_reg(p, UART_EFR, UART_EFR_ECB);
> @@ -235,14 +271,13 @@ static void omap_uart_restore_context(struct
> omap_uart_state *uart)
> serial_write_reg(p, UART_IER, uart->ier);
> serial_write_reg(p, UART_LCR, 0x80);
> serial_write_reg(p, UART_MCR, uart->mcr);
> - serial_write_reg(p, UART_FCR, 0xA1);
> serial_write_reg(p, UART_LCR, 0xBF); /* Config B mode */
> serial_write_reg(p, UART_EFR, efr);
> serial_write_reg(p, UART_LCR, UART_LCR_WLEN8);
> serial_write_reg(p, UART_OMAP_SCR, uart->scr);
> serial_write_reg(p, UART_OMAP_WER, uart->wer);
> serial_write_reg(p, UART_OMAP_SYSC, uart->sysc);
> -
Re: [PATCH] rwsem generic spinlock: use IRQ save/restore spinlocks
Kevin Hilman writes: > rwsems can be used with IRQs disabled, particularily in early boot > before IRQs are enabled. Currently the spin_unlock_irq() usage in the > slow-path will unconditionally enable interrupts and cause problems > early in boot where interrupts are not yet initialized or enabled. > > This patch uses save/restore versions of IRQ spinlocks in the slowpath > to ensure interrupts are not unintentionally enabled in the case where > the rwsem is used with IRQs disabled. > > Idea for this fix suggested by H. Peter Anvin. > > Tested on TI OMAP3-based platform (ARM Cortex-A8) > > Signed-off-by: Kevin Hilman > Cc: Rabin Vincent > Cc: H. Peter Anvin > LKML-Reference: > Reviewed-by: WANG Cong For the benefit of the l-o archives... This patch was merged into mainline in .34-rc6 and fixes potential deadlocks on boot, seen especially when using the SLUB allocator. 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: [PM][PATCH 4/4] OMAP3: Serial: kill dev_attr_sleep_timeout sparse warn
Nishanth Menon writes:
> Remove the following sparse warnings by declaring attr as static:
> arch/arm/mach-omap2/serial.c:627:1: warning: symbol 'dev_attr_sleep_timeout'
> was not declared. Should it be static?
>
> Cc: Govindraj R
> Cc: Kevin Hilman
> Cc: Tero Kristo
>
> Signed-off-by: Nishanth Menon
Thanks, adding to pm-next, queing for 2.6.35.
Kevin
> ---
> arch/arm/mach-omap2/serial.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index c7b2326..cea0a9e 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -624,7 +624,8 @@ static ssize_t sleep_timeout_store(struct device *dev,
> return n;
> }
>
> -DEVICE_ATTR(sleep_timeout, 0644, sleep_timeout_show, sleep_timeout_store);
> +static DEVICE_ATTR(sleep_timeout, 0644, sleep_timeout_show,
> + sleep_timeout_store);
> #define DEV_CREATE_FILE(dev, attr) WARN_ON(device_create_file(dev, attr))
> #else
> static inline void omap_uart_idle_init(struct omap_uart_state *uart) {}
> --
> 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: [PM][PATCH v3 2/4] OMAP3: Serial: Errata i202: fix for MDR1 access
Nishanth Menon writes:
> From: Deepak K
>
> Original patch:
> http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=42d4a342c009bd9727c100abc8a4bc3063c22f0c
>
> Errata i202 (OMAP3430 - 1.12, OMAP3630 - 1.6):
This workaround is currently done for all OMAPs.
Presumably, this errata will eventually be fixed. So, as with other
errata fixes, we need some sort of SoC-rev based flag and the errata
workaround done based on that flag.
Also, shouldn't there be a fix for this in the 8250 and omap-serial
drivers too?
Kevin
> UART module MDR1 register access can cause a dummy underrun
> condition which could result in a freeze in the case of IrDA
> communication or if used as UART, corrupted data.
>
> Workaround is as follows for everytime MDR1 register is changed:
> * setup all required UART registers
> * setup MDR1.MODE_SELECT bit field
> * Wait 5 L4 clk cycles + 5 UART functional clock cycles
> * Clear the Tx and RX fifo using FCR register
>
> Note: The following step is not done as I am assuming it is not
> needed due to reconfiguration being done and there is no halted
> operation perse.
> * Read if required, the RESUME register to resume halted operation
>
> Cc: Govindraj R
> Cc: Kevin Hilman
> Cc: Tero Kristo
>
> Signed-off-by: Deepak K
> Signed-off-by: Nishanth Menon
> ---
> Changes from V2:
> * Use macros instead of hardcoded values
>
> Ref:
> V2: http://marc.info/?t=127084514600010&r=1&w=2&n=2
> v1: http://marc.info/?t=12707493315&r=1&w=2
>
> arch/arm/mach-omap2/serial.c | 41 ++---
> 1 files changed, 38 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index a7c45b5..6d13183 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -185,6 +185,42 @@ static inline void __init omap_uart_reset(struct
> omap_uart_state *uart)
>
> #if defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP3)
>
> +/*
> + * Work Around for Errata i202 (3430 - 1.12, 3630 - 1.6)
> + * The access to uart register after MDR1 Access
> + * causes UART to corrupt data.
> + *
> + * Need a delay =
> + * 5 L4 clock cycles + 5 UART functional clock cycle (@48MHz = ~0.2uS)
> + * give 10 times as much
> + */
> +static void omap_uart_mdr1_errataset(struct omap_uart_state *uart, u8
> mdr1_val,
> + u8 fcr_val)
> +{
> + struct plat_serial8250_port *p = uart->p;
> + u8 timeout = 255;
> +
> + serial_write_reg(p, UART_OMAP_MDR1, mdr1_val);
> + udelay(2);
> + serial_write_reg(p, UART_FCR, fcr_val | UART_FCR_CLEAR_XMIT |
> + UART_FCR_CLEAR_RCVR);
> + /*
> + * Wait for FIFO to empty: when empty, RX_FIFO_E bit is 0 and
> + * TX_FIFO_E bit is 1.
> + */
> + while (UART_LSR_THRE != (serial_read_reg(p, UART_LSR) &
> + (UART_LSR_THRE | UART_LSR_DR))) {
> + timeout--;
> + if (!timeout) {
> + /* Should *never* happen. we warn and carry on */
> + dev_crit(&uart->pdev.dev, "Errata i202: timedout %x\n",
> + serial_read_reg(p, UART_LSR));
> + break;
> + }
> + udelay(1);
> + }
> +}
> +
> static void omap_uart_save_context(struct omap_uart_state *uart)
> {
> u16 lcr = 0;
> @@ -222,7 +258,7 @@ static void omap_uart_restore_context(struct
> omap_uart_state *uart)
>
> uart->context_valid = 0;
>
> - serial_write_reg(p, UART_OMAP_MDR1, 0x7);
> + omap_uart_mdr1_errataset(uart, 0x07, 0xA0);
> serial_write_reg(p, UART_LCR, 0xBF); /* Config B mode */
> efr = serial_read_reg(p, UART_EFR);
> serial_write_reg(p, UART_EFR, UART_EFR_ECB);
> @@ -235,14 +271,13 @@ static void omap_uart_restore_context(struct
> omap_uart_state *uart)
> serial_write_reg(p, UART_IER, uart->ier);
> serial_write_reg(p, UART_LCR, 0x80);
> serial_write_reg(p, UART_MCR, uart->mcr);
> - serial_write_reg(p, UART_FCR, 0xA1);
> serial_write_reg(p, UART_LCR, 0xBF); /* Config B mode */
> serial_write_reg(p, UART_EFR, efr);
> serial_write_reg(p, UART_LCR, UART_LCR_WLEN8);
> serial_write_reg(p, UART_OMAP_SCR, uart->scr);
> serial_write_reg(p, UART_OMAP_WER, uart->wer);
> serial_write_reg(p, UART_OMAP_SYSC, uart->sysc);
> - serial_write_reg(p, UART_OMAP_MDR1, 0x00); /* UART 16x mode */
> + omap_uart_mdr1_errataset(uart, 0x00, 0xA1);
> }
> #else
> static inline void omap_uart_save_context(struct omap_uart_state *uart) {}
> --
> 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: [PM][PATCH 1/4] OMAP3: Serial: Add context save and restore for mcr
Nishanth Menon writes:
> From: Govindraj R
>
> Ref:
> http://git.omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=c74952c3077e4b19e649b5b48c785c01f73ab9d4
>
> Adds context save/restore for mcr register as state of mcr register
> is lost after core off.
>
> Cc: Kevin Hilman
> Cc: Tero Kristo
>
> Signed-off-by: Govindraj R
> Signed-off-by: Nishanth Menon
OK, adding to pm-next, and queing (hopefully) for 2.6.35.
Kevin
> ---
> Note: Original Patch was done for android kernel, was ported and sanity
> tested to l-o pm. A quick check did not reveal any mcr access in
> arch/arm/mach-omap2/serial.c though drivers/serial/8250.c seems to
> hit on it a lot, hence posting.
>
> arch/arm/mach-omap2/serial.c |6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index b731556..86d3b47 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -78,6 +78,7 @@ struct omap_uart_state {
> u16 sysc;
> u16 scr;
> u16 wer;
> + u16 mcr;
> #endif
> };
>
> @@ -201,6 +202,9 @@ static void omap_uart_save_context(struct omap_uart_state
> *uart)
> uart->sysc = serial_read_reg(p, UART_OMAP_SYSC);
> uart->scr = serial_read_reg(p, UART_OMAP_SCR);
> uart->wer = serial_read_reg(p, UART_OMAP_WER);
> + serial_write_reg(p, UART_LCR, 0x80);
> + uart->mcr = serial_read_reg(p, UART_MCR);
> + serial_write_reg(p, UART_LCR, lcr);
>
> uart->context_valid = 1;
> }
> @@ -229,6 +233,8 @@ static void omap_uart_restore_context(struct
> omap_uart_state *uart)
> serial_write_reg(p, UART_DLM, uart->dlh);
> serial_write_reg(p, UART_LCR, 0x0); /* Operational mode */
> serial_write_reg(p, UART_IER, uart->ier);
> + serial_write_reg(p, UART_LCR, 0x80);
> + serial_write_reg(p, UART_MCR, uart->mcr);
> serial_write_reg(p, UART_FCR, 0xA1);
> serial_write_reg(p, UART_LCR, 0xBF); /* Config B mode */
> serial_write_reg(p, UART_EFR, efr);
> --
> 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: [RFC] [PATCH 1/3] OMAP4: Keyboard Controller Support
Felipe,
Thanks for your comments...
[..]
> >+#include
> >+#include
>
> should the platform_driver know about hwmod and omap_device ? Paul ?
> Kevin ?
Working on these changes...
>
> >+struct omap_keypad {
> >+
>
> unnecessary blank line.
Removed
>
> >+ struct platform_device *pdev;
>
> generaly we save the struct device *.
>
> >+ struct omap_hwmod *oh;
> >+ const struct matrix_keypad_platform_data *pdata;
>
> you should not save the platform_data here. Generaly you should only use
> that to initialize fields on your structure. Remember that a
> platform_data will be declared as __initdata.
Removed
>
> >+/* Interrupt thread primary handler, called in hard interrupt context */
> >+
> >+static irqreturn_t omap_keypad_interrupt(int irq, void *dev_id)
> >+{
> >+ struct omap_keypad *keypad_data = dev_id;
> >+
> >+ /* disable interrupts */
> >+ __raw_writel(OMAP4_DEF_IRQDISABLE, keypad_data->base +
> >+ OMAP4_KBD_IRQENABLE);
> >+
> >+ /* wake up handler thread */
> >+ return IRQ_WAKE_THREAD;
> >+
> >+}
> >+
> >+/* Interrupt thread handler thread */
> >+
> >+static irqreturn_t omap_keypad_threaded(int irq, void *dev_id)
> >+{
> >+ struct omap_keypad *keypad_data = dev_id;
> >+ struct input_dev *input = keypad_data->input;
> >+ unsigned char key_state[8];
> >+ int col, row, code;
> >+ u32 *new_state = (u32 *) key_state;
> >+
> >+ *new_state = __raw_readl(keypad_data->base +
> >+ OMAP4_KBD_FULLCODE31_0);
> >+ *(new_state + 1) = __raw_readl(keypad_data->base +
> >+ OMAP4_KBD_FULLCODE63_32);
> >+
> >+ for (col = 0; col < keypad_data->cols; col++) {
> >+ for (row = 0; row < keypad_data->rows; row++) {
> >+ code = MATRIX_SCAN_CODE(row, col,
> >+ keypad_data->row_shift);
> >+ if (code < 0) {
> >+ printk(KERN_INFO "Spurious key %d-%d\n",
> >+ col, row);
>
> use dev_dbg()
Added
>
> >+ continue;
> >+ }
> >+ input_report_key(input, keypad_data->keycodes[code],
> >+ key_state[col] & (1 << row));
>
> missing input_sync()
Added
>
> >+static int __devinit omap_keypad_probe(struct platform_device *pdev)
> >+{
>
> [..]
>
> >+ length = snprintf(oh_name, hw_mod_name_len, "keyboard");
> >+ WARN(length >= hw_mod_name_len,
> >+ "String buffer overflow in keyboard device setup\n");
>
> you're using snprintf() this WARN() shouldn't happen even, remove it.
Code now in board file, removed
>
> >+
> >+ oh = omap_hwmod_lookup(oh_name);
> >+ if (!oh)
> >+ pr_err("Could not look up %s\n", oh_name);
>
> I think omap_hwmod and omap_device shouldn't be here, but at least use
> dev_err();
Moving to board file...
>
> >+
> >+ pdata = kzalloc(sizeof(struct matrix_keypad_platform_data),
> >+ GFP_KERNEL);
>
> this should come from platform code.
Working on these changes...
I'll have a function in 4430sdp board file that will setup hwmod and omap
device called
sdp4430_keypad_init() {
...
omap_hwmod_lookup(oh_name);
kzalloc(sizeof(struct matrix_keypad_platform_data), GFP_KERNEL);
omap_device_build(name, id, oh, pdata,
...
}
and then called within
omap_4430sdp_init()
>
> >+
> >+ od = omap_device_build(name, id, oh, pdata,
> >+ sizeof(struct matrix_keypad_platform_data),
> >+ omap_keyboard_latency,
> >+ ARRAY_SIZE(omap_keyboard_latency), 1);
> >+ WARN(IS_ERR(od), "Could not build omap_device for %s %s\n",
> >+ name, oh_name);
>
> this too.
Moving to board file...
>
> >+ status = input_register_device(keypad_data->input);
> >+ if (status < 0) {
> >+ dev_err(&pdev->dev, "failed to register input device\n");
> >+ goto failed_free_device;
> >+ }
> >+
> >+ omap_keypad_config(keypad_data);
>
> registering and configuring should be done before requesting the irq.
Changed
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: [PATCH 9/9] OMAP:GPIO: Implement GPIO as a platform device
* Kevin Hilman [100505 13:54]: > "Varadarajan, Charulatha" writes: > > >> -Original Message- > >> From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > > > > 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. > > OK... for now. I'd still like to see GPIO init consolidated as there's > no (good) reason why every board file has to init GPIOs when it's common > for all SoCs, but this doesn't necessarily have to be done in your series. > Although, if you do it for OMAP1 (as proposed below) you should do similar > for OMAP2+. Let's try to use just arch/subsys_initcall for starting the GPIO. AFAIK we don't need it earlier than that. See also my comments to the patch 5/9. 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 5/9] OMAP:GPIO: Introduce support for OMAP2PLUS chip specific GPIO
* Charulatha V [100422 08:50]:
> This patch adds support for handling GPIO as a HWMOD adapted
> platform device for OMAP2PLUS chips.
> +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");
> +
> + 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;
> + 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;
> +
> + 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);
You can get rid of most of the cpu_is_omap in gpio_init if you pass
the method as a parameter to gpio_init(int method). We should only need
to use cpu_is_omap exactly once for every 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;
> +
> + if (gpio_init())
> + return -EINVAL;
> +
> + early_platform_driver_register_all("earlygpio");
> + early_platform_driver_probe("earlygpio", gpio_bank_count, 0);
> + return 0;
> +}
Then please replace this init with something like:
#ifdef CONFIG_ARCH_OMAP2
int __init omap242x_gpio_init(void)
{
if (!cpu_is_omap2420())
return -EINVAL;
gpio_bank_count = 4;
return gpio_init(METHOD_GPIO_24XX);
}
subsys_initcall(omap242x_gpio_init);
int __init omap243x_gpio_init(void)
{
if (!cpu_is_omap2430())
return -EINVAL;
gpio_bank_count = 5;
return gpio_init(METHOD_GPIO_24XX);
}
subsys_initcall(omap243x_gpio_init);
#endif
#ifdef CONFIG_ARCH_OMAP3
int __init omap34xx_gpio_init(void)
{
if (!cpu_is_omap34xx())
return -EINVAL;
gpio_bank_count = OMAP34X_NR_GPIOS;
return gpio_init(METHOD_GPIO_34XX);
}
subsys_initcall(omap34xx_gpio_init);
#endif
...
This way it will be more future proof when new omaps get added
and the if else stuff disappears. Also then you'll have an omap
specific function to initialize the gpio stuff.
Note that then early_platform_driver_register_all and
early_platform_driver_probe can be moved to gpio_init.
With multi-omap build the subsys_initcall runs for all of the
selected platforms, but returns early except for the machine
we're running on. All the code is optimized out for omap
specific product kernels.
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 V2] OMAP: GPIO: Fix OMAP4 GPIO reg access issues
Charulatha V writes: > Access to some of the OMAP4 GPIO registers are not properly handled. > This patch fixes it. > > This patch is tested on 3430SDP and 4430SDP boards > > Signed-off-by: Charulatha V > cc: Kevin Hilman Acked-by: Kevin Hilman All this #ifdeffery will be gone with the in-progress hwmod conversion, but this fix should go in in the meantime. 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: [PATCHv3 18/22] OMAP3: PM: Optional reset of voltage during Smartreflex disable.
"Gopinath, Thara" writes: >>>-Original Message- >>>From: Kevin Hilman [mailto:khil...@deeprootsystems.com] >>>Sent: Wednesday, April 28, 2010 12:45 AM >>>To: Gopinath, Thara >>>Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Cousson, Benoit; Sripathy, >>>Vishwanath; Sawant, Anand >>>Subject: Re: [PATCHv3 18/22] OMAP3: PM: Optional reset of voltage during >>>Smartreflex disable. >>> >>>Thara Gopinath writes: >>> Currently whenever smartreflex is disabled the voltage for the particular VDD is reset to the non-smartreflex compensated level. This step is unnecessary during dvfs because anyways in the next couple of steps before re-enabling smartreflex , the voltage level is changed. This patch adds the flexibility in the smartreflex framework for the user to specify whether or not a voltage reset is required after disabling of smartrefelx. The smartreflex driver just passes on this info to the smartreflex class driver, which ultimately takes the decision to reset the voltage or not. Signed-off-by: Thara Gopinath >>> >>>I don't think this option should be a decision made for each call to >>>omap_smartreflex_[en|dis]able(). Rather it should be an init time >>>option. > > Why do you say this? Anytime we do a disable of smartreflex auto >compensation from user space we need a reset of the voltage is >required. During dvfs during smartreflex disable a reset of the >voltage is not required. And in both these scenarios it is the same >class API that gets called. So the only way for the API to know >whether to reset the voltage or not is through this parameter. Also >IMHO keeping it parameter based allows more flexibility in the >framework for voltage reset. OK, I see now. I was looking at this patch in isolation and didn't notice the usage of it in the next DVFS patch where the ->disable is done without reset. Also, since this new flag is a bool, change it from int to bool. Or better yet add a new function. One thing I'm not a fan of for readability sake is the use of bool flags. It makes me have to go look at the function to see what the flag is used for. I'd rather just see a new function added. Something like omap_smartreflex_disable_noreset() would make the code a bit more readable. Thanks, Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]omap: mux.c warning removal
"Munegowda, Keshava" writes: > From: Keshava Munegowda > > This patch removes the below warning > arch/arm/mach-omap2/mux.c:52: warning: 'mux_phys' defined but not used > The definition of variable mux_phys should be enclosed in the macro > CONFIG_ARCH_OMAP3 > > Signed-off-by: Keshava Munegowda > Index: linux-2.6/arch/arm/mach-omap2/mux.c > === > --- linux-2.6.orig/arch/arm/mach-omap2/mux.c 2010-05-05 05:28:47.0 > +0530 > +++ linux-2.6/arch/arm/mach-omap2/mux.c 2010-05-05 05:29:02.0 > +0530 > @@ -49,7 +49,9 @@ > struct list_headnode; > }; > > +#ifdef CONFIG_ARCH_OMAP3 > static unsigned long mux_phys; > +#endif Rather than add another #ifdef, just move this inside the existing #ifdef farther down in the file. 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: ARCH_OMAP34XX usage in gpio PM code
Ranjith Lohithakshan writes:
> Kevin,
>
> Most of the ARCH_OMAP34XX usage has been converted to ARCH_OMAP3,
> however there is still a piece of code in gpio on PM branch that refers
> ARCH_OMAP34XX
>
> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
> index 7b2178c..0c84aae 100644
> --- a/arch/arm/plat-omap/gpio.c
> +++ b/arch/arm/plat-omap/gpio.c
> @@ -2095,7 +2095,7 @@ static int omap_gpio_suspend(struct sys_device
> *dev, pm_me
> __raw_writel(bank->suspend_wakeup, wake_set);
> spin_unlock_irqrestore(&bank->lock, flags);
>
> -#ifdef CONFIG_ARCH_OMAP34XX
> +#ifdef CONFIG_ARCH_OMAP3
> if (bank->method == METHOD_GPIO_24XX) {
> int j;
> for (j = 0; j < 32; j++) {
>
> Shouldn't we be making this change? Let me know and I will include it in
> the ads7846 wakeup series.
You're right. Good catch.
Please submit this fix as a separate patch and I will add it to the
pm-gpio branch.
Thanks,
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: McBSP: Fix request for irq in OMAP4
Jorge Eduardo Candelaria writes:
> 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/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) {
Instead of cpu_is* here, just use 'if (mcbsp->rx_irq)' which will
be more portable in other cases of no RX IRQ.
> + 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())
here too
> + free_irq(mcbsp->rx_irq, (void *)mcbsp);
> free_irq(mcbsp->tx_irq, (void *)mcbsp);
> }
>
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 3/3] omap: rx51: Add supplies for the tlv320aic3x codec driver
* Jarkko Nikula [100505 11:35]: > On Wed, 5 May 2010 08:15:39 -0700 > Tony Lindgren wrote: > > > * Mark Brown [100505 07:20]: > > > Seems sensible to merge this along with the CODEC driver patch it > > > depends on if everyone else is happy (assuming no merge issues)? > > > > Sounds good to me. I'll take the other ones, if there are merge issues > > then we can move some of the other patches into your tree too. > > > > Acked-by: Tony Lindgren > > I would rather keep the board-rx51-peripherals.c in linux-omap sync > than get the N900 audio working as soon as possible :-) > > None of these patches are build or boot critical so I can wait & repost > the last one when the codec patches hit into mainline. > > Only harm from some missing board-rx51-peripherals.c patch is that > codec either doesn't probe or is kept in reset but system boots up > fine. And trees are clean too! OK, fine with me. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] omap platform data and board updates for 2.6.35 merge window
* Koen Kooi [100505 13:16]: > Tony, > > Any chance of https://patchwork.kernel.org/patch/94049/ going in as well? > Tomi has acked it already. That one looks good to me, but I thought Tomi is going to queue all the DSS board-*.c patches somewhere. 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 9/9] OMAP:GPIO: Implement GPIO as a platform device
"Varadarajan, Charulatha" writes:
>> -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.
OK... for now. I'd still like to see GPIO init consolidated as there's
no (good) reason why every board file has to init GPIOs when it's common
for all SoCs, but this doesn't necessarily have to be done in your series.
Although, if you do it for OMAP1 (as proposed below) you should do similar
for OMAP2+.
>>
>> 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.
But your driver probe is already in a separate init path (via
arch_initcall) from your device init path omap_gpio_init().
My problem is that there is a 2nd driver init path:
board file -> [driver]omap_gpio_init() -> [device] _gpio_init()
The fact that it goes through the driver is what I don't like.
>>
>>
>> > 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())
>
Re: [PATCH 00/18] omap platform data and board updates for 2.6.35 merge window
Tony, Any chance of https://patchwork.kernel.org/patch/94049/ going in as well? Tomi has acked it already. regards, Koen Op 5 mei 2010, om 21:32 heeft Tony Lindgren het volgende geschreven: > Hi all, > > Here are some omap patches for review. This series is pretty much > all platform data and board init updates for omap1/2/3. > > The omap4 patches are still coming, but seem to need a bit more work. > > Regards, > > Tony > > --- > > Ajay Kumar Gupta (1): > AM35x: fix UI card EHCI port and LCD dependency > > Janusz Krzysztofik (1): > omap1: amsdelta: defconfig updates > > Jarkko Nikula (3): > omap: rx51: Change the TWL4030 VMMC2 voltage constraints andsupply name > omap: rx51: Add i2c2 board_info with tlv320aic3x > omap: rx51: Add supplies for the tlv320aic3x codec driver > > Sriram (6): > can:ti_hecc: board specific hookup on AM3517EVM > can:ti_hecc: Enable CAN support on AM3517 > AM35xx EMAC : define submodule offsets > AM35xx : Platform specific hookup for EMAC module > OMAP3 : clock data: Update name string for EMAC clocks > AM3517 defconfig update : enable EMAC support > > Steve Sakoman (1): > omap: Overo: Add support for second ethernet port > > Thomas Weber (2): > omap: Devkit8000: Add mux initialization > omap: Devkit8000: Update default configuration > > Vaibhav Hiremath (1): > OMAP2/3: Add V4L2 DSS driver support in device.c > > Viral Mehta (3): > omap2: Add I2C bus 1 initialisation for 2430sdp > omap2: Add OHCI USB platform init for 2430 SDP > omap2: select ARCH_OMAP_OTG for OMAP2430 SDP > > > arch/arm/configs/am3517_evm_defconfig| 92 ++- > arch/arm/configs/ams_delta_defconfig |9 + > arch/arm/configs/devkit8000_defconfig| 157 +++--- > arch/arm/mach-omap2/Kconfig |1 > arch/arm/mach-omap2/board-2430sdp.c | 21 +++ > arch/arm/mach-omap2/board-am3517evm.c| 146 > arch/arm/mach-omap2/board-devkit8000.c | 155 ++ > arch/arm/mach-omap2/board-overo.c| 14 ++ > arch/arm/mach-omap2/board-rx51-peripherals.c | 77 +++-- > arch/arm/mach-omap2/clock3xxx_data.c |4 - > arch/arm/mach-omap2/devices.c| 28 + > arch/arm/mach-omap2/include/mach/am35xx.h| 20 +++ > 12 files changed, 632 insertions(+), 92 deletions(-) > > -- > Signature > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/18] OMAP3 : clock data: Update name string for EMAC clocks
* Russell King - ARM Linux [100505 12:41]:
> On Wed, May 05, 2010 at 12:33:09PM -0700, Tony Lindgren wrote:
> > The emac driver uses generic name for the module and phy
> > clocks. Updated the omap3xxx_clks table to match the names
> > used by the Davinci emac driver.
>
> Patch doesn't match description.
Sriramakrishnan, can you please update the patch for better
description?
> IMHO "ick" and "fck" are generic names, whereas "emac_clk" and
> "phy_clk" are specific names.
>
> > - CLK("davinci_emac", "ick", &emac_ick, CK_AM35XX),
> > - CLK("davinci_emac", "fck", &emac_fck, CK_AM35XX),
> > + CLK("davinci_emac", "emac_clk", &emac_ick, CK_AM35XX),
> > + CLK("davinci_emac", "phy_clk", &emac_fck, CK_AM35XX),
Yeah as Paul pointed out too, there should be a follow-up patch
to fix there clock names in drivers/net/davinci_emac.c, mach-davinci/dm646x.c,
mach-davinci/da850.c, and mach-omap2/clock3xxx_data.c.
That should also be mentioned in the patch description.
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 12/18] OMAP3 : clock data: Update name string for EMAC clocks
On Wed, May 05, 2010 at 12:33:09PM -0700, Tony Lindgren wrote:
> The emac driver uses generic name for the module and phy
> clocks. Updated the omap3xxx_clks table to match the names
> used by the Davinci emac driver.
Patch doesn't match description. IMHO "ick" and "fck" are generic names,
whereas "emac_clk" and "phy_clk" are specific names.
> - CLK("davinci_emac", "ick", &emac_ick, CK_AM35XX),
> - CLK("davinci_emac", "fck", &emac_fck, CK_AM35XX),
> + CLK("davinci_emac", "emac_clk", &emac_ick, CK_AM35XX),
> + CLK("davinci_emac", "phy_clk", &emac_fck, CK_AM35XX),
--
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 04/18] omap2: Add OHCI USB platform init for 2430 SDP
From: Viral Mehta
Add platform init code for OHCI USB on OMAP2430 SDP
Signed-off-by: Viral Mehta
[t...@atomide.com: Updated subject to mention the board name]
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-2430sdp.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 85f5f33..a11a575 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -207,6 +207,15 @@ static struct omap_musb_board_data musb_board_data = {
.mode = MUSB_OTG,
.power = 100,
};
+static struct omap_usb_config sdp2430_usb_config __initdata = {
+ .otg= 1,
+#ifdef CONFIG_USB_GADGET_OMAP
+ .hmc_mode = 0x0,
+#elif defined(CONFIG_USB_OHCI_HCD) || defined(CONFIG_USB_OHCI_HCD_MODULE)
+ .hmc_mode = 0x1,
+#endif
+ .pins[0]= 3,
+};
static void __init omap_2430sdp_init(void)
{
@@ -217,6 +226,7 @@ static void __init omap_2430sdp_init(void)
platform_add_devices(sdp2430_devices, ARRAY_SIZE(sdp2430_devices));
omap_serial_init();
omap2_hsmmc_init(mmc);
+ omap_usb_init(&sdp2430_usb_config);
usb_musb_init(&musb_board_data);
board_smc91x_init();
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/18] omap1: amsdelta: defconfig updates
From: Janusz Krzysztofik The patch provides the following ams_delta_defconfig updates: - explicitly select preemptable RCU, - replace outdated CONFIG_LBD and CONFIG_LSF options with CONFIG_LBDAF, - activate support for LCD contrast setting (new in 2.6.34), - turn off verbose bug reporting for smaller kernel. Created and tested against linux-2.6.34-rc3. Signed-off-by: Janusz Krzysztofik Signed-off-by: Tony Lindgren --- arch/arm/configs/ams_delta_defconfig |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/arm/configs/ams_delta_defconfig b/arch/arm/configs/ams_delta_defconfig index ecf45fb..6d8a0c8 100644 --- a/arch/arm/configs/ams_delta_defconfig +++ b/arch/arm/configs/ams_delta_defconfig @@ -47,6 +47,7 @@ CONFIG_SYSVIPC_SYSCTL=y # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set +CONFIG_TREE_PREEMPT_RCU=y # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_SYSFS_DEPRECATED=y @@ -95,9 +96,8 @@ CONFIG_KMOD=y # Block layer # CONFIG_BLOCK=y -# CONFIG_LBD is not set +# CONFIG_LBDAF is not set # CONFIG_BLK_DEV_IO_TRACE is not set -# CONFIG_LSF is not set # # IO Schedulers @@ -836,7 +836,8 @@ CONFIG_DAB=y # # Graphics support # -# CONFIG_BACKLIGHT_LCD_SUPPORT is not set +CONFIG_BACKLIGHT_LCD_SUPPORT=y +CONFIG_LCD_CLASS_DEVICE=y # # Display device support @@ -1284,7 +1285,7 @@ CONFIG_DEBUG_PREEMPT=y # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set # CONFIG_DEBUG_KOBJECT is not set -CONFIG_DEBUG_BUGVERBOSE=y +# CONFIG_DEBUG_BUGVERBOSE is not set # CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_LIST is not set -- 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 18/18] AM35x: fix UI card EHCI port and LCD dependency
From: Ajay Kumar Gupta
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
Signed-off-by: Tony Lindgren
---
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 02e2097..19b9e41 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -216,6 +216,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;
@@ -259,6 +261,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)
{
@@ -372,7 +377,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,
--
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 17/18] omap: rx51: Add supplies for the tlv320aic3x codec driver
From: Jarkko Nikula
Upcoming change to tlv320aic3x codec driver require four supplies.
Implement this by connecting analogic supplies to TWL4030 VMMC2 and digital
supplies to TWL4030 VIO.
Signed-off-by: Jarkko Nikula
Cc: Eduardo Valentin
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 60 +++---
1 files changed, 53 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 3addfe6..8179d55 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -277,7 +277,7 @@ static struct regulator_consumer_supply rx51_vmmc1_supply =
{
.dev_name = "mmci-omap-hs.0",
};
-static struct regulator_consumer_supply rx51_vmmc2_supply = {
+static struct regulator_consumer_supply rx51_vaux3_supply = {
.supply = "vmmc",
.dev_name = "mmci-omap-hs.1",
};
@@ -287,6 +287,35 @@ static struct regulator_consumer_supply rx51_vsim_supply =
{
.dev_name = "mmci-omap-hs.1",
};
+static struct regulator_consumer_supply rx51_vmmc2_supplies[] = {
+ /* tlv320aic3x analog supplies */
+ {
+ .supply = "AVDD",
+ .dev_name = "2-0018",
+ },
+ {
+ .supply = "DRVDD",
+ .dev_name = "2-0018",
+ },
+ /* Keep vmmc as last item. It is not iterated for newer boards */
+ {
+ .supply = "vmmc",
+ .dev_name = "mmci-omap-hs.1",
+ },
+};
+
+static struct regulator_consumer_supply rx51_vio_supplies[] = {
+ /* tlv320aic3x digital supplies */
+ {
+ .supply = "IOVDD",
+ .dev_name = "2-0018"
+ },
+ {
+ .supply = "DVDD",
+ .dev_name = "2-0018"
+ },
+};
+
static struct regulator_init_data rx51_vaux1 = {
.constraints = {
.name = "V28",
@@ -338,7 +367,7 @@ static struct regulator_init_data rx51_vaux3_mmc = {
| REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = 1,
- .consumer_supplies = &rx51_vmmc2_supply,
+ .consumer_supplies = &rx51_vaux3_supply,
};
static struct regulator_init_data rx51_vaux4 = {
@@ -380,8 +409,8 @@ static struct regulator_init_data rx51_vmmc2 = {
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
- .num_consumer_supplies = 1,
- .consumer_supplies = &rx51_vmmc2_supply,
+ .num_consumer_supplies = ARRAY_SIZE(rx51_vmmc2_supplies),
+ .consumer_supplies = rx51_vmmc2_supplies,
};
static struct regulator_init_data rx51_vsim = {
@@ -411,6 +440,20 @@ static struct regulator_init_data rx51_vdac = {
},
};
+static struct regulator_init_data rx51_vio = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(rx51_vio_supplies),
+ .consumer_supplies = rx51_vio_supplies,
+};
+
static int rx51_twlgpio_setup(struct device *dev, unsigned gpio, unsigned n)
{
/* FIXME this gpio setup is just a placeholder for now */
@@ -618,6 +661,7 @@ static struct twl4030_platform_data rx51_twldata __initdata
= {
.vmmc1 = &rx51_vmmc1,
.vsim = &rx51_vsim,
.vdac = &rx51_vdac,
+ .vio= &rx51_vio,
};
static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_1[] = {
@@ -638,12 +682,14 @@ static struct i2c_board_info __initdata
rx51_peripherals_i2c_board_info_2[] = {
static int __init rx51_i2c_init(void)
{
if ((system_rev >= SYSTEM_REV_S_USES_VAUX3 && system_rev < 0x100) ||
- system_rev >= SYSTEM_REV_B_USES_VAUX3)
+ system_rev >= SYSTEM_REV_B_USES_VAUX3) {
rx51_twldata.vaux3 = &rx51_vaux3_mmc;
- else {
+ /* Only older boards use VMMC2 for internal MMC */
+ rx51_vmmc2.num_consumer_supplies--;
+ } else {
rx51_twldata.vaux3 = &rx51_vaux3_cam;
- rx51_twldata.vmmc2 = &rx51_vmmc2;
}
+ rx51_twldata.vmmc2 = &rx51_vmmc2;
omap_register_i2c_bus(1, 2200, rx51_peripherals_i2c_board_info_1,
ARRAY_SIZE(rx51_peripherals_i2c_board_info_1));
omap_register_i2c_bus(2, 10
[PATCH 16/18] omap: rx51: Add i2c2 board_info with tlv320aic3x
From: Jarkko Nikula
This makes possible to probe the audio codec and add another i2c2
components in the future.
Fix also indentation for the first omap_register_i2c_bus.
Signed-off-by: Jarkko Nikula
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index b803f47..3addfe6 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -629,6 +629,12 @@ static struct i2c_board_info __initdata
rx51_peripherals_i2c_board_info_1[] = {
},
};
+static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[] = {
+ {
+ I2C_BOARD_INFO("tlv320aic3x", 0x18),
+ },
+};
+
static int __init rx51_i2c_init(void)
{
if ((system_rev >= SYSTEM_REV_S_USES_VAUX3 && system_rev < 0x100) ||
@@ -639,8 +645,9 @@ static int __init rx51_i2c_init(void)
rx51_twldata.vmmc2 = &rx51_vmmc2;
}
omap_register_i2c_bus(1, 2200, rx51_peripherals_i2c_board_info_1,
- ARRAY_SIZE(rx51_peripherals_i2c_board_info_1));
- omap_register_i2c_bus(2, 100, NULL, 0);
+ ARRAY_SIZE(rx51_peripherals_i2c_board_info_1));
+ omap_register_i2c_bus(2, 100, rx51_peripherals_i2c_board_info_2,
+ ARRAY_SIZE(rx51_peripherals_i2c_board_info_2));
omap_register_i2c_bus(3, 400, NULL, 0);
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/18] omap: rx51: Change the TWL4030 VMMC2 voltage constraints andsupply name
From: Jarkko Nikula
I believe the VMMC2 constraints must be the same than with VAUX3. Older
boards are using TWL4030 VMMC2 supply for internal MMC whereas newer are
using VAUX3 that has more limited constraints defined in this same file.
More over, the VMMC2 supply is used also for analog audio domain and the
miminum analog voltage of the TLV320AIC34 codec is 2.7 V.
To combine these two facts, the patch changes supply name to V28_A as the
newer boards register VMMC2_30 for VAUX3 and uses the same constraints than
VAUX3 since those constraints are ok for the TLV320AIC34.
Signed-off-by: Jarkko Nikula
Cc: Adrian Hunter
Cc: Eduardo Valentin
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-rx51-peripherals.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 4377a4c..b803f47 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -370,9 +370,9 @@ static struct regulator_init_data rx51_vmmc1 = {
static struct regulator_init_data rx51_vmmc2 = {
.constraints = {
- .name = "VMMC2_30",
- .min_uV = 185,
- .max_uV = 315,
+ .name = "V28_A",
+ .min_uV = 280,
+ .max_uV = 300,
.apply_uV = true,
.valid_modes_mask = REGULATOR_MODE_NORMAL
| REGULATOR_MODE_STANDBY,
--
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 14/18] omap: Overo: Add support for second ethernet port
From: Steve Sakoman
Some Overo add-on boards include a second ethernet port. This patch
adds support for that second port.
Signed-off-by: Steve Sakoman
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-overo.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 8848c7c..79ac414 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -63,6 +63,8 @@
#define OVERO_SMSC911X_CS 5
#define OVERO_SMSC911X_GPIO176
+#define OVERO_SMSC911X2_CS 4
+#define OVERO_SMSC911X2_GPIO 65
#if defined(CONFIG_TOUCHSCREEN_ADS7846) || \
defined(CONFIG_TOUCHSCREEN_ADS7846_MODULE)
@@ -137,6 +139,16 @@ static struct resource overo_smsc911x_resources[] = {
},
};
+static struct resource overo_smsc911x2_resources[] = {
+ {
+ .name = "smsc911x2-memory",
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL,
+ },
+};
+
static struct smsc911x_platform_config overo_smsc911x_config = {
.irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
.irq_type = SMSC911X_IRQ_TYPE_OPEN_DRAIN,
@@ -146,7 +158,7 @@ static struct smsc911x_platform_config
overo_smsc911x_config = {
static struct platform_device overo_smsc911x_device = {
.name = "smsc911x",
- .id = -1,
+ .id = 0,
.num_resources = ARRAY_SIZE(overo_smsc911x_resources),
.resource = overo_smsc911x_resources,
.dev= {
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/18] AM3517 defconfig update : enable EMAC support
From: Sriram Update the default configuration for AM3517EVM to enable support for EMAC peripheral. Signed-off-by: Sriramakrishnan Signed-off-by: Tony Lindgren --- arch/arm/configs/am3517_evm_defconfig | 70 + 1 files changed, 69 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/am3517_evm_defconfig b/arch/arm/configs/am3517_evm_defconfig index c151d6e..232f8ee 100644 --- a/arch/arm/configs/am3517_evm_defconfig +++ b/arch/arm/configs/am3517_evm_defconfig @@ -531,7 +531,75 @@ CONFIG_SCSI_LOWLEVEL=y # CONFIG_SCSI_OSD_INITIATOR is not set # CONFIG_ATA is not set # CONFIG_MD is not set -# CONFIG_NETDEVICES is not set +CONFIG_NETDEVICES=y +# CONFIG_DUMMY is not set +# CONFIG_BONDING is not set +# CONFIG_MACVLAN is not set +# CONFIG_EQUALIZER is not set +# CONFIG_TUN is not set +# CONFIG_VETH is not set +CONFIG_PHYLIB=y + +# +# MII PHY device drivers +# +# CONFIG_MARVELL_PHY is not set +# CONFIG_DAVICOM_PHY is not set +# CONFIG_QSEMI_PHY is not set +# CONFIG_LXT_PHY is not set +# CONFIG_CICADA_PHY is not set +# CONFIG_VITESSE_PHY is not set +# CONFIG_SMSC_PHY is not set +# CONFIG_BROADCOM_PHY is not set +# CONFIG_ICPLUS_PHY is not set +# CONFIG_REALTEK_PHY is not set +# CONFIG_NATIONAL_PHY is not set +# CONFIG_STE10XP is not set +# CONFIG_LSI_ET1011C_PHY is not set +# CONFIG_FIXED_PHY is not set +# CONFIG_MDIO_BITBANG is not set +CONFIG_NET_ETHERNET=y +# CONFIG_MII is not set +# CONFIG_AX88796 is not set +# CONFIG_SMC91X is not set +CONFIG_TI_DAVINCI_EMAC=y +# CONFIG_DM9000 is not set +# CONFIG_ETHOC is not set +# CONFIG_SMC911X is not set +# CONFIG_SMSC911X is not set +# CONFIG_DNET is not set +# CONFIG_IBM_NEW_EMAC_ZMII is not set +# CONFIG_IBM_NEW_EMAC_RGMII is not set +# CONFIG_IBM_NEW_EMAC_TAH is not set +# CONFIG_IBM_NEW_EMAC_EMAC4 is not set +# CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set +# CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set +# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set +# CONFIG_B44 is not set +# CONFIG_KS8842 is not set +# CONFIG_KS8851_MLL is not set +# CONFIG_NETDEV_1000 is not set +# CONFIG_NETDEV_1 is not set +# CONFIG_WLAN is not set + +# +# Enable WiMAX (Networking options) to see the WiMAX drivers +# + +# +# USB Network Adapters +# +# CONFIG_USB_CATC is not set +# CONFIG_USB_KAWETH is not set +# CONFIG_USB_PEGASUS is not set +# CONFIG_USB_RTL8150 is not set +# CONFIG_USB_USBNET is not set +# CONFIG_WAN is not set +# CONFIG_PPP is not set +# CONFIG_SLIP is not set +# CONFIG_NETCONSOLE is not set +# CONFIG_NETPOLL is not set +# CONFIG_NET_POLL_CONTROLLER is not set # CONFIG_ISDN is not set # CONFIG_PHONE is not set -- 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 12/18] OMAP3 : clock data: Update name string for EMAC clocks
From: Sriram
The emac driver uses generic name for the module and phy
clocks. Updated the omap3xxx_clks table to match the names
used by the Davinci emac driver.
Signed-off-by: Sriramakrishnan
Acked-by: Paul Walmsley
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/clock3xxx_data.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index 9cba556..6905eb7 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3472,8 +3472,8 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, "ipss_ick", &ipss_ick, CK_AM35XX),
CLK(NULL, "rmii_ck", &rmii_ck, CK_AM35XX),
CLK(NULL, "pclk_ck", &pclk_ck, CK_AM35XX),
- CLK("davinci_emac", "ick", &emac_ick, CK_AM35XX),
- CLK("davinci_emac", "fck", &emac_fck, CK_AM35XX),
+ CLK("davinci_emac", "emac_clk", &emac_ick, CK_AM35XX),
+ CLK("davinci_emac", "phy_clk", &emac_fck, CK_AM35XX),
CLK("vpfe-capture", "master", &vpfe_ick, CK_AM35XX),
CLK("vpfe-capture", "slave",&vpfe_fck, CK_AM35XX),
CLK("musb_hdrc","ick", &hsotgusb_ick_am35xx,
CK_AM35XX),
--
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 11/18] AM35xx : Platform specific hookup for EMAC module
From: Sriram
Modified AM35xx EVM init sequence to handle EMAC
initialization.
Signed-off-by: Sriramakrishnan
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-am3517evm.c | 98 +
1 files changed, 98 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 6ca0075..02e2097 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -31,11 +32,106 @@
#include
#include
+#include
#include
#include
#include "mux.h"
+#define AM35XX_EVM_PHY_MASK(0xF)
+#define AM35XX_EVM_MDIO_FREQUENCY (100)
+
+static struct emac_platform_data am3517_evm_emac_pdata = {
+ .phy_mask = AM35XX_EVM_PHY_MASK,
+ .mdio_max_freq = AM35XX_EVM_MDIO_FREQUENCY,
+ .rmii_en= 1,
+};
+
+static struct resource am3517_emac_resources[] = {
+ {
+ .start = AM35XX_IPSS_EMAC_BASE,
+ .end= AM35XX_IPSS_EMAC_BASE + 0x3,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_35XX_EMAC_C0_RXTHRESH_IRQ,
+ .end= INT_35XX_EMAC_C0_RXTHRESH_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = INT_35XX_EMAC_C0_RX_PULSE_IRQ,
+ .end= INT_35XX_EMAC_C0_RX_PULSE_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = INT_35XX_EMAC_C0_TX_PULSE_IRQ,
+ .end= INT_35XX_EMAC_C0_TX_PULSE_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = INT_35XX_EMAC_C0_MISC_PULSE_IRQ,
+ .end= INT_35XX_EMAC_C0_MISC_PULSE_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device am3517_emac_device = {
+ .name = "davinci_emac",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(am3517_emac_resources),
+ .resource = am3517_emac_resources,
+};
+
+static void am3517_enable_ethernet_int(void)
+{
+ u32 regval;
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = (regval | AM35XX_CPGMAC_C0_RX_PULSE_CLR |
+ AM35XX_CPGMAC_C0_TX_PULSE_CLR |
+ AM35XX_CPGMAC_C0_MISC_PULSE_CLR |
+ AM35XX_CPGMAC_C0_RX_THRESH_CLR);
+ omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+static void am3517_disable_ethernet_int(void)
+{
+ u32 regval;
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = (regval | AM35XX_CPGMAC_C0_RX_PULSE_CLR |
+ AM35XX_CPGMAC_C0_TX_PULSE_CLR);
+ omap_ctrl_writel(regval, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ regval = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+void am3517_evm_ethernet_init(struct emac_platform_data *pdata)
+{
+ unsigned int regval;
+
+ pdata->ctrl_reg_offset = AM35XX_EMAC_CNTRL_OFFSET;
+ pdata->ctrl_mod_reg_offset = AM35XX_EMAC_CNTRL_MOD_OFFSET;
+ pdata->ctrl_ram_offset = AM35XX_EMAC_CNTRL_RAM_OFFSET;
+ pdata->mdio_reg_offset = AM35XX_EMAC_MDIO_OFFSET;
+ pdata->ctrl_ram_size= AM35XX_EMAC_CNTRL_RAM_SIZE;
+ pdata->version = EMAC_VERSION_2;
+ pdata->hw_ram_addr = AM35XX_EMAC_HW_RAM_ADDR;
+ pdata->interrupt_enable = am3517_enable_ethernet_int;
+ pdata->interrupt_disable= am3517_disable_ethernet_int;
+ am3517_emac_device.dev.platform_data= pdata;
+ platform_device_register(&am3517_emac_device);
+
+ regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
+ regval = regval & (~(AM35XX_CPGMACSS_SW_RST));
+ omap_ctrl_writel(regval, AM35XX_CONTROL_IP_SW_RESET);
+ regval = omap_ctrl_readl(AM35XX_CONTROL_IP_SW_RESET);
+
+ return ;
+}
+
+
+
#define LCD_PANEL_PWR 176
#define LCD_PANEL_BKLIGHT_PWR 182
#define LCD_PANEL_PWM 181
@@ -351,6 +447,8 @@ static void __init am3517_evm_init(void)
i2c_register_board_info(1, am3517evm_i2c_boardinfo,
ARRAY_SIZE(am3517evm_i2c_boardinfo));
+ /*Ethernet*/
+ am3517_evm_ethernet_init(&am3517_evm_emac_pdata);
}
static void __init am3517_evm_map_io(void)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/18] AM35xx EMAC : define submodule offsets
From: Sriram Define offsets for EMAC sub modules. Signed-off-by: Sriramakrishnan Signed-off-by: Tony Lindgren --- arch/arm/mach-omap2/include/mach/am35xx.h | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/am35xx.h b/arch/arm/mach-omap2/include/mach/am35xx.h index 0636263..f1e13d1 100644 --- a/arch/arm/mach-omap2/include/mach/am35xx.h +++ b/arch/arm/mach-omap2/include/mach/am35xx.h @@ -32,4 +32,13 @@ #define AM35XX_HECC_INT_LINE (0x0) #define AM35XX_HECC_VERSION(0x1) -#endif /* __ASM_ARCH_AM35XX_H */ +#define AM35XX_EMAC_CNTRL_OFFSET (0x1) +#define AM35XX_EMAC_CNTRL_MOD_OFFSET (0x0) +#define AM35XX_EMAC_CNTRL_RAM_OFFSET (0x2) +#define AM35XX_EMAC_MDIO_OFFSET(0x3) +#define AM35XX_EMAC_CNTRL_RAM_SIZE (0x2000) +#define AM35XX_EMAC_RAM_ADDR (AM3517_EMAC_BASE + \ + AM3517_EMAC_CNTRL_RAM_OFFSET) +#define AM35XX_EMAC_HW_RAM_ADDR(0x01E2) + +#endif /* __ASM_ARCH_AM35XX_H */ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/18] can:ti_hecc: Enable CAN support on AM3517
From: Sriram Modify the default kernel configuration on AM3517 to enable CAN. Signed-off-by: Sriramakrishnan Signed-off-by: Tony Lindgren --- arch/arm/configs/am3517_evm_defconfig | 22 ++ 1 files changed, 18 insertions(+), 4 deletions(-) diff --git a/arch/arm/configs/am3517_evm_defconfig b/arch/arm/configs/am3517_evm_defconfig index 66a10b5..c151d6e 100644 --- a/arch/arm/configs/am3517_evm_defconfig +++ b/arch/arm/configs/am3517_evm_defconfig @@ -422,15 +422,29 @@ CONFIG_DEFAULT_TCP_CONG="cubic" # # CONFIG_NET_PKTGEN is not set # CONFIG_HAMRADIO is not set -# CONFIG_CAN is not set +CONFIG_CAN=y +CONFIG_CAN_RAW=y +CONFIG_CAN_BCM=y + +# +# CAN Device Drivers +# +CONFIG_CAN_VCAN=y +CONFIG_CAN_DEV=y +CONFIG_CAN_CALC_BITTIMING=y +CONFIG_CAN_TI_HECC=y +# CONFIG_CAN_SJA1000 is not set + +# +# CAN USB interfaces +# +# CONFIG_CAN_EMS_USB is not set +CONFIG_CAN_DEBUG_DEVICES=y # CONFIG_IRDA is not set # CONFIG_BT is not set # CONFIG_AF_RXRPC is not set CONFIG_WIRELESS=y # CONFIG_CFG80211 is not set -CONFIG_CFG80211_DEFAULT_PS_VALUE=0 -# CONFIG_WIRELESS_OLD_REGULATORY is not set -# CONFIG_WIRELESS_EXT is not set # CONFIG_LIB80211 is not set # -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/18] omap: Devkit8000: Update default configuration
From: Thomas Weber This patch updates the new default configuration for the Devkit8000. Signed-off-by: Thomas Weber Signed-off-by: Tony Lindgren --- arch/arm/configs/devkit8000_defconfig | 157 +++-- 1 files changed, 91 insertions(+), 66 deletions(-) diff --git a/arch/arm/configs/devkit8000_defconfig b/arch/arm/configs/devkit8000_defconfig index 61a817e..c7a6820 100644 --- a/arch/arm/configs/devkit8000_defconfig +++ b/arch/arm/configs/devkit8000_defconfig @@ -1,13 +1,14 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.33-rc6 -# Thu Feb 4 15:42:56 2010 +# Linux kernel version: 2.6.34-rc2 +# Wed Mar 24 13:27:25 2010 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_GENERIC_GPIO=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_HAVE_PROC_CPU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y @@ -19,7 +20,9 @@ CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_ARCH_HAS_CPUFREQ=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_NEED_DMA_MAP_STATE=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y +CONFIG_ARM_L1_CACHE_SHIFT_6=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_CONSTRUCTORS=y @@ -60,11 +63,6 @@ CONFIG_RCU_FANOUT=32 CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 -CONFIG_GROUP_SCHED=y -CONFIG_FAIR_GROUP_SCHED=y -# CONFIG_RT_GROUP_SCHED is not set -CONFIG_USER_SCHED=y -# CONFIG_CGROUP_SCHED is not set # CONFIG_CGROUPS is not set # CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set @@ -96,10 +94,14 @@ CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y +CONFIG_HAVE_PERF_EVENTS=y +CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # +# CONFIG_PERF_EVENTS is not set +# CONFIG_PERF_COUNTERS is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_COMPAT_BRK=y CONFIG_SLAB=y @@ -170,7 +172,7 @@ CONFIG_INLINE_WRITE_UNLOCK=y CONFIG_INLINE_WRITE_UNLOCK_IRQ=y # CONFIG_INLINE_WRITE_UNLOCK_IRQRESTORE is not set # CONFIG_MUTEX_SPIN_ON_OWNER is not set -# CONFIG_FREEZER is not set +CONFIG_FREEZER=y # # System Type @@ -181,6 +183,7 @@ CONFIG_MMU=y # CONFIG_ARCH_REALVIEW is not set # CONFIG_ARCH_VERSATILE is not set # CONFIG_ARCH_AT91 is not set +# CONFIG_ARCH_BCMRING is not set # CONFIG_ARCH_CLPS711X is not set # CONFIG_ARCH_GEMINI is not set # CONFIG_ARCH_EBSA110 is not set @@ -190,7 +193,6 @@ CONFIG_MMU=y # CONFIG_ARCH_STMP3XXX is not set # CONFIG_ARCH_NETX is not set # CONFIG_ARCH_H720X is not set -# CONFIG_ARCH_NOMADIK is not set # CONFIG_ARCH_IOP13XX is not set # CONFIG_ARCH_IOP32X is not set # CONFIG_ARCH_IOP33X is not set @@ -207,21 +209,26 @@ CONFIG_MMU=y # CONFIG_ARCH_KS8695 is not set # CONFIG_ARCH_NS9XXX is not set # CONFIG_ARCH_W90X900 is not set +# CONFIG_ARCH_NUC93X is not set # CONFIG_ARCH_PNX4008 is not set # CONFIG_ARCH_PXA is not set # CONFIG_ARCH_MSM is not set +# CONFIG_ARCH_SHMOBILE is not set # CONFIG_ARCH_RPC is not set # CONFIG_ARCH_SA1100 is not set # CONFIG_ARCH_S3C2410 is not set # CONFIG_ARCH_S3C64XX is not set +# CONFIG_ARCH_S5P6440 is not set +# CONFIG_ARCH_S5P6442 is not set # CONFIG_ARCH_S5PC1XX is not set +# CONFIG_ARCH_S5PV210 is not set # CONFIG_ARCH_SHARK is not set # CONFIG_ARCH_LH7A40X is not set # CONFIG_ARCH_U300 is not set +# CONFIG_ARCH_U8500 is not set +# CONFIG_ARCH_NOMADIK is not set # CONFIG_ARCH_DAVINCI is not set CONFIG_ARCH_OMAP=y -# CONFIG_ARCH_BCMRING is not set -# CONFIG_ARCH_U8500 is not set # # TI OMAP Implementations @@ -237,16 +244,20 @@ CONFIG_ARCH_OMAP3=y # OMAP Feature Selections # # CONFIG_OMAP_RESET_CLOCKS is not set -# CONFIG_OMAP_MUX is not set +CONFIG_OMAP_MUX=y +# CONFIG_OMAP_MUX_DEBUG is not set +CONFIG_OMAP_MUX_WARNINGS=y CONFIG_OMAP_MCBSP=y # CONFIG_OMAP_MBOX_FWK is not set # CONFIG_OMAP_MPU_TIMER is not set CONFIG_OMAP_32K_TIMER=y +# CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE is not set CONFIG_OMAP_32K_TIMER_HZ=128 CONFIG_OMAP_DM_TIMER=y # CONFIG_OMAP_PM_NONE is not set CONFIG_OMAP_PM_NOOP=y CONFIG_ARCH_OMAP3430=y +CONFIG_OMAP_PACKAGE_CUS=y # # OMAP Board Type @@ -295,6 +306,7 @@ CONFIG_ARM_THUMB=y # CONFIG_CPU_BPREDICT_DISABLE is not set CONFIG_HAS_TLS_REG=y CONFIG_ARM_L1_CACHE_SHIFT=6 +CONFIG_CPU_HAS_PMU=y # CONFIG_ARM_ERRATA_430973 is not set # CONFIG_ARM_ERRATA_458693 is not set # CONFIG_ARM_ERRATA_460075 is not set @@ -387,7 +399,14 @@ CONFIG_HAVE_AOUT=y # # Power management options # -# CONFIG_PM is not set +CONFIG_PM=y +# CONFIG_PM_DEBUG is not set +CONFIG_PM_SLEEP=y +CONFIG_SUSPEND=y +CONFIG_SUSPEND_FREEZER=y +# CONFIG_APM_EMULATION is not set +# CONFIG_PM_RUNTIME is not set +CONFIG_PM_OPS=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_NET=y @@ -395,7 +414,6 @@ CONFIG_NET=y # Networking options # CONFIG_PACKET=y -# CONFIG_PACKET_MMAP is not set CONFIG_UNIX=y CONFIG_XFRM=y # CONFIG_XFRM_USER is not set @@ -666,6 +684,7 @@ CONFIG
[PATCH 08/18] can:ti_hecc: board specific hookup on AM3517EVM
From: Sriram
Add board specific hookup for TI HECC driver on
AM3517 EVM
Signed-off-by: Sriramakrishnan
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-am3517evm.c | 38 +
arch/arm/mach-omap2/include/mach/am35xx.h |9 +++
2 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index c1c4389..6ca0075 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -292,6 +293,42 @@ static struct omap_board_mux board_mux[] __initdata = {
#define board_mux NULL
#endif
+
+static struct resource am3517_hecc_resources[] = {
+ {
+ .start = AM35XX_IPSS_HECC_BASE,
+ .end= AM35XX_IPSS_HECC_BASE + 0x3FFF,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = INT_35XX_HECC0_IRQ,
+ .end= INT_35XX_HECC0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device am3517_hecc_device = {
+ .name = "ti_hecc",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(am3517_hecc_resources),
+ .resource = am3517_hecc_resources,
+};
+
+static struct ti_hecc_platform_data am3517_evm_hecc_pdata = {
+ .scc_hecc_offset= AM35XX_HECC_SCC_HECC_OFFSET,
+ .scc_ram_offset = AM35XX_HECC_SCC_RAM_OFFSET,
+ .hecc_ram_offset= AM35XX_HECC_RAM_OFFSET,
+ .mbx_offset = AM35XX_HECC_MBOX_OFFSET,
+ .int_line = AM35XX_HECC_INT_LINE,
+ .version= AM35XX_HECC_VERSION,
+};
+
+static void am3517_evm_hecc_init(struct ti_hecc_platform_data *pdata)
+{
+ am3517_hecc_device.dev.platform_data = pdata;
+ platform_device_register(&am3517_hecc_device);
+}
+
static void __init am3517_evm_init(void)
{
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
@@ -305,6 +342,7 @@ static void __init am3517_evm_init(void)
/* Configure GPIO for EHCI port */
omap_mux_init_gpio(57, OMAP_PIN_OUTPUT);
usb_ehci_init(&ehci_pdata);
+ am3517_evm_hecc_init(&am3517_evm_hecc_pdata);
/* DSS */
am3517_evm_display_init();
diff --git a/arch/arm/mach-omap2/include/mach/am35xx.h
b/arch/arm/mach-omap2/include/mach/am35xx.h
index a705f94..0636263 100644
--- a/arch/arm/mach-omap2/include/mach/am35xx.h
+++ b/arch/arm/mach-omap2/include/mach/am35xx.h
@@ -23,4 +23,13 @@
#define AM35XX_IPSS_HECC_BASE 0x5C05
#define AM35XX_IPSS_VPFE_BASE 0x5C06
+
+/* HECC module specifc offset definitions */
+#define AM35XX_HECC_SCC_HECC_OFFSET(0x0)
+#define AM35XX_HECC_SCC_RAM_OFFSET (0x3000)
+#define AM35XX_HECC_RAM_OFFSET (0x3000)
+#define AM35XX_HECC_MBOX_OFFSET(0x2000)
+#define AM35XX_HECC_INT_LINE (0x0)
+#define AM35XX_HECC_VERSION(0x1)
+
#endif /* __ASM_ARCH_AM35XX_H */
--
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 06/18] omap: Devkit8000: Add mux initialization
From: Thomas Weber
Initialize multiplexed pins with correct mode.
Signed-off-by: Thomas Weber
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-devkit8000.c | 155
1 files changed, 155 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 47e3af2..77022b5 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -633,8 +633,163 @@ static const struct ehci_hcd_omap_platform_data
ehci_pdata __initconst = {
.reset_gpio_port[2] = -EINVAL
};
+static struct omap_board_mux board_mux[] __initdata = {
+ /* nCS and IRQ for Devkit8000 ethernet */
+ OMAP3_MUX(GPMC_NCS6, OMAP_MUX_MODE0),
+ OMAP3_MUX(ETK_D11, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+
+ /* McSPI 2*/
+ OMAP3_MUX(MCSPI2_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCSPI2_SIMO, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(MCSPI2_SOMI, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCSPI2_CS0, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(MCSPI2_CS1, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+
+ /* PENDOWN GPIO */
+ OMAP3_MUX(ETK_D13, OMAP_MUX_MODE4 | OMAP_PIN_INPUT),
+
+ /* mUSB */
+ OMAP3_MUX(HSUSB0_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_STP, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(HSUSB0_DIR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_NXT, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA4, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA5, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA6, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(HSUSB0_DATA7, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+
+ /* USB 1 */
+ OMAP3_MUX(ETK_CTL, OMAP_MUX_MODE3 | OMAP_PIN_INPUT),
+ OMAP3_MUX(ETK_CLK, OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(ETK_D8, OMAP_MUX_MODE3 | OMAP_PIN_INPUT),
+ OMAP3_MUX(ETK_D9, OMAP_MUX_MODE3 | OMAP_PIN_INPUT),
+ OMAP3_MUX(ETK_D0, OMAP_MUX_MODE3 | OMAP_PIN_INPUT),
+ OMAP3_MUX(ETK_D1, OMAP_MUX_MODE3 | OMAP_PIN_INPUT),
+ OMAP3_MUX(ETK_D2, OMAP_MUX_MODE3 | OMAP_PIN_INPUT),
+ OMAP3_MUX(ETK_D3, OMAP_MUX_MODE3 | OMAP_PIN_INPUT),
+ OMAP3_MUX(ETK_D4, OMAP_MUX_MODE3 | OMAP_PIN_INPUT),
+ OMAP3_MUX(ETK_D5, OMAP_MUX_MODE3 | OMAP_PIN_INPUT),
+ OMAP3_MUX(ETK_D6, OMAP_MUX_MODE3 | OMAP_PIN_INPUT),
+ OMAP3_MUX(ETK_D7, OMAP_MUX_MODE3 | OMAP_PIN_INPUT),
+
+ /* MMC 1 */
+ OMAP3_MUX(SDMMC1_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(SDMMC1_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(SDMMC1_DAT0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(SDMMC1_DAT1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(SDMMC1_DAT2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(SDMMC1_DAT3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(SDMMC1_DAT4, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(SDMMC1_DAT5, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(SDMMC1_DAT6, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(SDMMC1_DAT7, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+
+ /* McBSP 2 */
+ OMAP3_MUX(MCBSP2_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP2_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP2_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP2_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+
+ /* I2C 1 */
+ OMAP3_MUX(I2C1_SCL, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(I2C1_SDA, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+
+ /* I2C 2 */
+ OMAP3_MUX(I2C2_SCL, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(I2C2_SDA, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+
+ /* I2C 3 */
+ OMAP3_MUX(I2C3_SCL, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(I2C3_SDA, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+
+ /* I2C 4 */
+ OMAP3_MUX(I2C4_SCL, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(I2C4_SDA, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+
+ /* serial ports */
+ OMAP3_MUX(MCBSP3_CLKX, OMAP_MUX_MODE1 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(MCBSP3_FSX, OMAP_MUX_MODE1 | OMAP_PIN_INPUT),
+ OMAP3_MUX(UART1_TX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(UART1_RX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+
+ /* DSS */
+ OMAP3_MUX(DSS_PCLK, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_HSYNC, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_VSYNC, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_ACBIAS, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(DSS_DATA0, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ O
[PATCH 03/18] omap2: Add I2C bus 1 initialisation for 2430sdp
From: Viral Mehta
Initialize isp1301 FS USB transceiver and
add I2C bus1 initialization code for OMAP2430 SDP
Signed-off-by: Viral Mehta
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/board-2430sdp.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 01d113f..85f5f33 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -174,9 +174,18 @@ static struct i2c_board_info __initdata
sdp2430_i2c_boardinfo[] = {
},
};
+static struct i2c_board_info __initdata sdp2430_i2c1_boardinfo[] = {
+ {
+ I2C_BOARD_INFO("isp1301_omap", 0x2D),
+ .flags = I2C_CLIENT_WAKE,
+ .irq = OMAP_GPIO_IRQ(78),
+ },
+};
+
static int __init omap2430_i2c_init(void)
{
- omap_register_i2c_bus(1, 400, NULL, 0);
+ omap_register_i2c_bus(1, 100, sdp2430_i2c1_boardinfo,
+ ARRAY_SIZE(sdp2430_i2c1_boardinfo));
omap_register_i2c_bus(2, 2600, sdp2430_i2c_boardinfo,
ARRAY_SIZE(sdp2430_i2c_boardinfo));
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/18] omap2: select ARCH_OMAP_OTG for OMAP2430 SDP
From: Viral Mehta Configuration for OMAP2430 should select ARCH_OMAP_OTG just like it is done for OMAP2420 Signed-off-by: Viral Mehta Signed-off-by: Tony Lindgren --- arch/arm/mach-omap2/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 2455dcc..99abac2 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -10,6 +10,7 @@ config ARCH_OMAP2420 config ARCH_OMAP2430 bool "OMAP2430 support" depends on ARCH_OMAP2 + select ARCH_OMAP_OTG config ARCH_OMAP3430 bool "OMAP3430 support" -- 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 01/18] OMAP2/3: Add V4L2 DSS driver support in device.c
From: Vaibhav Hiremath
Signed-off-by: Vaibhav Hiremath
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/devices.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2271b9b..10f3a3c 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -786,6 +786,33 @@ static inline void omap_hdq_init(void)
static inline void omap_hdq_init(void) {}
#endif
+/*---*/
+
+#if defined(CONFIG_VIDEO_OMAP2_VOUT) || \
+ defined(CONFIG_VIDEO_OMAP2_VOUT_MODULE)
+#if defined(CONFIG_FB_OMAP2) || defined(CONFIG_FB_OMAP2_MODULE)
+static struct resource omap_vout_resource[3 - CONFIG_FB_OMAP2_NUM_FBS] = {
+};
+#else
+static struct resource omap_vout_resource[2] = {
+};
+#endif
+
+static struct platform_device omap_vout_device = {
+ .name = "omap_vout",
+ .num_resources = ARRAY_SIZE(omap_vout_resource),
+ .resource = &omap_vout_resource[0],
+ .id = -1,
+};
+static void omap_init_vout(void)
+{
+ if (platform_device_register(&omap_vout_device) < 0)
+ printk(KERN_ERR "Unable to register OMAP-VOUT device\n");
+}
+#else
+static inline void omap_init_vout(void) {}
+#endif
+
/*-*/
static int __init omap2_init_devices(void)
@@ -800,6 +827,7 @@ static int __init omap2_init_devices(void)
omap_hdq_init();
omap_init_sti();
omap_init_sha1_md5();
+ omap_init_vout();
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/18] omap platform data and board updates for 2.6.35 merge window
Hi all, Here are some omap patches for review. This series is pretty much all platform data and board init updates for omap1/2/3. The omap4 patches are still coming, but seem to need a bit more work. Regards, Tony --- Ajay Kumar Gupta (1): AM35x: fix UI card EHCI port and LCD dependency Janusz Krzysztofik (1): omap1: amsdelta: defconfig updates Jarkko Nikula (3): omap: rx51: Change the TWL4030 VMMC2 voltage constraints andsupply name omap: rx51: Add i2c2 board_info with tlv320aic3x omap: rx51: Add supplies for the tlv320aic3x codec driver Sriram (6): can:ti_hecc: board specific hookup on AM3517EVM can:ti_hecc: Enable CAN support on AM3517 AM35xx EMAC : define submodule offsets AM35xx : Platform specific hookup for EMAC module OMAP3 : clock data: Update name string for EMAC clocks AM3517 defconfig update : enable EMAC support Steve Sakoman (1): omap: Overo: Add support for second ethernet port Thomas Weber (2): omap: Devkit8000: Add mux initialization omap: Devkit8000: Update default configuration Vaibhav Hiremath (1): OMAP2/3: Add V4L2 DSS driver support in device.c Viral Mehta (3): omap2: Add I2C bus 1 initialisation for 2430sdp omap2: Add OHCI USB platform init for 2430 SDP omap2: select ARCH_OMAP_OTG for OMAP2430 SDP arch/arm/configs/am3517_evm_defconfig| 92 ++- arch/arm/configs/ams_delta_defconfig |9 + arch/arm/configs/devkit8000_defconfig| 157 +++--- arch/arm/mach-omap2/Kconfig |1 arch/arm/mach-omap2/board-2430sdp.c | 21 +++ arch/arm/mach-omap2/board-am3517evm.c| 146 arch/arm/mach-omap2/board-devkit8000.c | 155 ++ arch/arm/mach-omap2/board-overo.c| 14 ++ arch/arm/mach-omap2/board-rx51-peripherals.c | 77 +++-- arch/arm/mach-omap2/clock3xxx_data.c |4 - arch/arm/mach-omap2/devices.c| 28 + arch/arm/mach-omap2/include/mach/am35xx.h| 20 +++ 12 files changed, 632 insertions(+), 92 deletions(-) -- Signature -- 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] AM35x: fix UI card EHCI port and LCD dependency
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): 869c0f68ff64620334e044c56aa3dedd42eb6ccc PatchWorks http://patchwork.kernel.org/patch/96688/ 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=869c0f68ff64620334e044c56aa3dedd42eb6ccc -- 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: [CBUS PATCH 1/1] CBUS: Fix broken compilation
hi again, On Wed, May 05, 2010 at 05:05:29PM +0200, Chinea Carlos (Nokia-D/Helsinki) wrote: Include explicitly slab.h in: drivers/cbus/cbus.c drivers/cbus/retu-headset.c drivers/cbus/retu-user.c drivers/cbus/retu-wdt.c drivers/cbus/tahvo-user.c Compile tested with n8x0_defconfig Signed-off-by: Carlos Chinea I see now the problem. --- drivers/cbus/cbus.c |1 + drivers/cbus/retu-headset.c |1 + drivers/cbus/retu-user.c|1 + drivers/cbus/retu-wdt.c |1 + drivers/cbus/tahvo-user.c |1 + 5 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/cbus/cbus.c b/drivers/cbus/cbus.c index 00c3c32..2c74d6e 100644 --- a/drivers/cbus/cbus.c +++ b/drivers/cbus/cbus.c @@ -30,6 +30,7 @@ #include #include #include +#include this is already included in line 32 of that file. diff --git a/drivers/cbus/retu-headset.c b/drivers/cbus/retu-headset.c index e798bc2..645679c 100644 --- a/drivers/cbus/retu-headset.c +++ b/drivers/cbus/retu-headset.c @@ -25,6 +25,7 @@ #include #include #include +#include already on line 25, right above #include diff --git a/drivers/cbus/retu-user.c b/drivers/cbus/retu-user.c index 0f35dc5..7bc97d4 100644 --- a/drivers/cbus/retu-user.c +++ b/drivers/cbus/retu-user.c @@ -33,6 +33,7 @@ #include #include #include +#include already on line 26 diff --git a/drivers/cbus/retu-wdt.c b/drivers/cbus/retu-wdt.c index 35932dd..fda8b35 100644 --- a/drivers/cbus/retu-wdt.c +++ b/drivers/cbus/retu-wdt.c @@ -35,6 +35,7 @@ #include #include #include +#include already on line 25 diff --git a/drivers/cbus/tahvo-user.c b/drivers/cbus/tahvo-user.c index c0e8daf..b28b015 100644 --- a/drivers/cbus/tahvo-user.c +++ b/drivers/cbus/tahvo-user.c @@ -33,6 +33,7 @@ #include #include #include +#include already on line 26. NAK to this patch. -- balbi DefectiveByDesign.org -- 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] select ARCH_OMAP_OTG for OMAP2430 SDP
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): 66fe139ec4ee8d548d504753d720cd18594616c4 PatchWorks http://patchwork.kernel.org/patch/93050/ 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=66fe139ec4ee8d548d504753d720cd18594616c4 -- 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] Add OHCI USB platform init
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): 397794b0aa2844dd98a2c527cb7a23ae059f2b24 PatchWorks http://patchwork.kernel.org/patch/93049/ 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=397794b0aa2844dd98a2c527cb7a23ae059f2b24 -- 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/3] omap: rx51: Add supplies for the tlv320aic3x codec
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): 138eb2e88b5021b0a1ff23111e7a788323316f59 PatchWorks http://patchwork.kernel.org/patch/96507/ 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=138eb2e88b5021b0a1ff23111e7a788323316f59 -- 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/3] omap: rx51: Add i2c2 board_info with tlv320aic3x
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): 4f39e921e97d2856f69f3e0ab2c0853007da06c7 PatchWorks http://patchwork.kernel.org/patch/96506/ 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=4f39e921e97d2856f69f3e0ab2c0853007da06c7 -- 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 1/3] omap: rx51: Change the TWL4030 VMMC2 voltage
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): 597e16fc7c7867087548f10413643350371e4b77 PatchWorks http://patchwork.kernel.org/patch/96505/ 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=597e16fc7c7867087548f10413643350371e4b77 -- 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 4/4 v2] ks8851: read/write MAC address on companion eeprom through debugfs
A more elegant alternative to ethtool for updating the ks8851
MAC address stored on its companion eeprom.
Using this debugfs interface does not require any knowledge on the
ks8851 companion eeprom organization to update the MAC address.
Example to write 01:23:45:67:89:AB MAC address to the companion
eeprom (assuming debugfs is mounted in /sys/kernel/debug):
$ echo "01:23:45:67:89:AB" > /sys/kernel/debug/ks8851/mac_eeprom
Signed-off-by: Sebastien Jan
---
drivers/net/ks8851.c | 216 ++
1 files changed, 216 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ks8851.c b/drivers/net/ks8851.c
index 8e38c36..1b62ec5 100644
--- a/drivers/net/ks8851.c
+++ b/drivers/net/ks8851.c
@@ -22,6 +22,11 @@
#include
+#ifdef CONFIG_DEBUG_FS
+#include
+#include
+#endif
+
#include "ks8851.h"
/**
@@ -1550,6 +1555,214 @@ static int ks8851_read_selftest(struct ks8851_net *ks)
return 0;
}
+#ifdef CONFIG_DEBUG_FS
+static struct dentry *ks8851_dir;
+
+static int ks8851_mac_eeprom_open(struct inode *inode, struct file *file)
+{
+ file->private_data = inode->i_private;
+ return 0;
+}
+
+static int ks8851_mac_eeprom_release(struct inode *inode, struct file *file)
+{
+ return 0;
+}
+
+static loff_t ks8851_mac_eeprom_seek(struct file *file, loff_t off, int whence)
+{
+ return 0;
+}
+
+/**
+ * ks8851_mac_eeprom_read - Read a MAC address in ks8851 companion EEPROM
+ *
+ * Warning: The READ feature is not supported on ks8851 revision 0.
+ */
+static ssize_t ks8851_mac_eeprom_read(struct file *filep, char __user *buff,
+ size_t count, loff_t *offp)
+{
+ ssize_t ret;
+ struct net_device *dev = filep->private_data;
+ char str[50];
+ unsigned int data;
+ unsigned char mac_addr[6];
+
+ if (*offp > 0) {
+ ret = 0;
+ goto ks8851_cnt_rd_bk;
+ }
+
+ data = ks8851_eeprom_read(dev, 1);
+ mac_addr[5] = data & 0xFF;
+ mac_addr[4] = (data >> 8) & 0xFF;
+ data = ks8851_eeprom_read(dev, 2);
+ mac_addr[3] = data & 0xFF;
+ mac_addr[2] = (data >> 8) & 0xFF;
+ data = ks8851_eeprom_read(dev, 3);
+ mac_addr[1] = data & 0xFF;
+ mac_addr[0] = (data >> 8) & 0xFF;
+
+ sprintf(str, "%02x:%02x:%02x:%02x:%02x:%02x\n", mac_addr[0],
+ mac_addr[1], mac_addr[2], mac_addr[3], mac_addr[4],
+ mac_addr[5]);
+
+ ret = strlen(str);
+
+ if (copy_to_user((void __user *)buff, str, ret)) {
+ dev_err(&dev->dev, "ks8851 - copy_to_user failed\n");
+ ret = 0;
+ } else {
+ *offp = ret;
+ }
+
+ks8851_cnt_rd_bk:
+ return ret;
+}
+
+/*
+ * Split the buffer `buf' into ':'-separated words.
+ * Return the number of words or <0 on error.
+ */
+#define isdelimiter(c) ((c) == ':')
+static int ks8851_debug_tokenize(char *buf, char *words[], int maxwords)
+{
+ int nwords = 0;
+
+ while (*buf) {
+ char *end;
+
+ /* Skip leading whitespace */
+ while (*buf && isspace(*buf))
+ buf++;
+ if (!*buf)
+ break; /* oh, it was trailing whitespace */
+
+ /* Run `end' over a word */
+ for (end = buf ; *end && !isdelimiter(*end) ; end++)
+ ;
+ /* `buf' is the start of the word, `end' is one past the end */
+
+ if (nwords == maxwords)
+ return -EINVAL; /* ran out of words[] before bytes */
+ if (*end)
+ *end++ = '\0'; /* terminate the word */
+ words[nwords++] = buf;
+ buf = end;
+ }
+ return nwords;
+}
+
+/**
+ * ks8851_mac_eeprom_write - Write a MAC address in ks8851 companion EEPROM
+ *
+ */
+static ssize_t ks8851_mac_eeprom_write(struct file *filep,
+ const char __user *buff, size_t count, loff_t *offp)
+{
+ struct net_device *dev = filep->private_data;
+ ssize_t ret;
+#define MAXWORDS 6
+ int nwords, i;
+ char *words[MAXWORDS];
+ char tmpbuf[256];
+ unsigned long mac_addr[6];
+
+ if (count == 0)
+ return 0;
+ if (count > sizeof(tmpbuf)-1)
+ return -E2BIG;
+ if (copy_from_user(tmpbuf, buff, count))
+ return -EFAULT;
+ tmpbuf[count] = '\0';
+ dev_dbg(&dev->dev, "%s: read %d bytes from userspace\n",
+ __func__, (int)count);
+
+ nwords = ks8851_debug_tokenize(tmpbuf, words, MAXWORDS);
+ if (nwords != 6) {
+ dev_warn(&dev->dev,
+ "ks8851 MAC address write to EEPROM requires a MAC address " \
+ "like 01:23:45:67:89:AB\n");
+ return -EINVAL;
+ }
+
+
[PATCH 0/4 v2] ks8851: support for read/write MAC address from eeprom
Provides the ability to update the ks8851 companion eeprom content (including the MAC address) through ethtool or debugfs (for MAC address only). Differences with v1: - added the support of eeprom access through ethtool - different patches split Patch set tested on OMAP4-based test board. Build tested on net-2.6 head. Applies on current net-2.6 head. Sebastien Jan (4): ks8851: Add caching of CCR register ks8851: Low level functions for read/write to companion eeprom ks8851: companion eeprom access through ethtool ks8851: read/write MAC address on companion eeprom through debugfs drivers/net/ks8851.c | 570 ++ drivers/net/ks8851.h | 14 ++- 2 files changed, 583 insertions(+), 1 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4 v2] ks8851: companion eeprom access through ethtool
Accessing ks8851 companion eeprom permits modifying the ks8851 stored
MAC address.
Example how to change the MAC address using ethtool, to set the
01:23:45:67:89:AB MAC address:
$ echo "0:AB8976452301" | xxd -r > mac.bin
$ sudo ethtool -E eth0 magic 0x8870 offset 2 < mac.bin
Signed-off-by: Sebastien Jan
---
drivers/net/ks8851.c | 114 ++
1 files changed, 114 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ks8851.c b/drivers/net/ks8851.c
index 787f9df..8e38c36 100644
--- a/drivers/net/ks8851.c
+++ b/drivers/net/ks8851.c
@@ -1318,6 +1318,117 @@ static int ks8851_nway_reset(struct net_device *dev)
return mii_nway_restart(&ks->mii);
}
+static int ks8851_get_eeprom_len(struct net_device *dev)
+{
+ struct ks8851_net *ks = netdev_priv(dev);
+ return ks->eeprom_size;
+}
+
+static int ks8851_get_eeprom(struct net_device *dev,
+ struct ethtool_eeprom *eeprom, u8 *bytes)
+{
+ struct ks8851_net *ks = netdev_priv(dev);
+ u16 *eeprom_buff;
+ int first_word;
+ int last_word;
+ int ret_val = 0;
+ u16 i;
+
+ if (eeprom->len == 0)
+ return -EINVAL;
+
+ if (eeprom->len > ks->eeprom_size)
+ return -EINVAL;
+
+ eeprom->magic = ks8851_rdreg16(ks, KS_CIDER);
+
+ first_word = eeprom->offset >> 1;
+ last_word = (eeprom->offset + eeprom->len - 1) >> 1;
+
+ eeprom_buff = kmalloc(sizeof(u16) *
+ (last_word - first_word + 1), GFP_KERNEL);
+ if (!eeprom_buff)
+ return -ENOMEM;
+
+ for (i = 0; i < last_word - first_word + 1; i++)
+ eeprom_buff[i] = ks8851_eeprom_read(dev, first_word + 1);
+
+ /* Device's eeprom is little-endian, word addressable */
+ for (i = 0; i < last_word - first_word + 1; i++)
+ le16_to_cpus(&eeprom_buff[i]);
+
+ memcpy(bytes, (u8 *)eeprom_buff + (eeprom->offset & 1), eeprom->len);
+ kfree(eeprom_buff);
+
+ return ret_val;
+}
+
+static int ks8851_set_eeprom(struct net_device *dev,
+ struct ethtool_eeprom *eeprom, u8 *bytes)
+{
+ struct ks8851_net *ks = netdev_priv(dev);
+ u16 *eeprom_buff;
+ void *ptr;
+ int max_len;
+ int first_word;
+ int last_word;
+ int ret_val = 0;
+ u16 i;
+
+ if (eeprom->len == 0)
+ return -EOPNOTSUPP;
+
+ if (eeprom->len > ks->eeprom_size)
+ return -EINVAL;
+
+ if (eeprom->magic != ks8851_rdreg16(ks, KS_CIDER))
+ return -EFAULT;
+
+ first_word = eeprom->offset >> 1;
+ last_word = (eeprom->offset + eeprom->len - 1) >> 1;
+ max_len = (last_word - first_word + 1) * 2;
+ eeprom_buff = kmalloc(max_len, GFP_KERNEL);
+ if (!eeprom_buff)
+ return -ENOMEM;
+
+ ptr = (void *)eeprom_buff;
+
+ if (eeprom->offset & 1) {
+ /* need read/modify/write of first changed EEPROM word */
+ /* only the second byte of the word is being modified */
+ eeprom_buff[0] = ks8851_eeprom_read(dev, first_word);
+ ptr++;
+ }
+ if ((eeprom->offset + eeprom->len) & 1)
+ /* need read/modify/write of last changed EEPROM word */
+ /* only the first byte of the word is being modified */
+ eeprom_buff[last_word - first_word] =
+ ks8851_eeprom_read(dev, last_word);
+
+
+ /* Device's eeprom is little-endian, word addressable */
+ le16_to_cpus(&eeprom_buff[0]);
+ le16_to_cpus(&eeprom_buff[last_word - first_word]);
+
+ memcpy(ptr, bytes, eeprom->len);
+
+ for (i = 0; i < last_word - first_word + 1; i++)
+ eeprom_buff[i] = cpu_to_le16(eeprom_buff[i]);
+
+ ks8851_eeprom_write(dev, EEPROM_OP_EWEN, 0, 0);
+
+ for (i = 0; i < last_word - first_word + 1; i++) {
+ ks8851_eeprom_write(dev, EEPROM_OP_WRITE, first_word + i,
+ eeprom_buff[i]);
+ mdelay(EEPROM_WRITE_TIME);
+ }
+
+ ks8851_eeprom_write(dev, EEPROM_OP_EWDS, 0, 0);
+
+ kfree(eeprom_buff);
+ return ret_val;
+}
+
static const struct ethtool_ops ks8851_ethtool_ops = {
.get_drvinfo= ks8851_get_drvinfo,
.get_msglevel = ks8851_get_msglevel,
@@ -1326,6 +1437,9 @@ static const struct ethtool_ops ks8851_ethtool_ops = {
.set_settings = ks8851_set_settings,
.get_link = ks8851_get_link,
.nway_reset = ks8851_nway_reset,
+ .get_eeprom_len = ks8851_get_eeprom_len,
+ .get_eeprom = ks8851_get_eeprom,
+ .set_eeprom = ks8851_set_eeprom,
};
/* MII interface controls */
--
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 majo
[PATCH 2/4 v2] ks8851: Low level functions for read/write to companion eeprom
Low-level functions provide 16bits words read and write capability
to ks8851 companion eeprom.
Signed-off-by: Sebastien Jan
---
drivers/net/ks8851.c | 228 ++
drivers/net/ks8851.h | 14 +++-
2 files changed, 241 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ks8851.c b/drivers/net/ks8851.c
index a84e500..787f9df 100644
--- a/drivers/net/ks8851.c
+++ b/drivers/net/ks8851.c
@@ -1044,6 +1044,234 @@ static const struct net_device_ops ks8851_netdev_ops = {
.ndo_validate_addr = eth_validate_addr,
};
+/* Companion eeprom access */
+
+enum { /* EEPROM programming states */
+ EEPROM_CONTROL,
+ EEPROM_ADDRESS,
+ EEPROM_DATA,
+ EEPROM_COMPLETE
+};
+
+/**
+ * ks8851_eeprom_read - read a 16bits word in ks8851 companion EEPROM
+ * @dev: The network device the PHY is on.
+ * @addr: EEPROM address to read
+ *
+ * eeprom_size: used to define the data coding length. Can be changed
+ * through debug-fs.
+ *
+ * Programs a read on the EEPROM using ks8851 EEPROM SW access feature.
+ * Warning: The READ feature is not supported on ks8851 revision 0.
+ *
+ * Rough programming model:
+ * - on period start: set clock high and read value on bus
+ * - on period / 2: set clock low and program value on bus
+ * - start on period / 2
+ */
+unsigned int ks8851_eeprom_read(struct net_device *dev, unsigned int addr)
+{
+ struct ks8851_net *ks = netdev_priv(dev);
+ int eepcr;
+ int ctrl = EEPROM_OP_READ;
+ int state = EEPROM_CONTROL;
+ int bit_count = EEPROM_OP_LEN - 1;
+ unsigned int data = 0;
+ int dummy;
+ unsigned int addr_len;
+
+ addr_len = (ks->eeprom_size == 128) ? 6 : 8;
+
+ /* start transaction: chip select high, authorize write */
+ mutex_lock(&ks->lock);
+ eepcr = EEPCR_EESA | EEPCR_EESRWA;
+ ks8851_wrreg16(ks, KS_EEPCR, eepcr);
+ eepcr |= EEPCR_EECS;
+ ks8851_wrreg16(ks, KS_EEPCR, eepcr);
+ mutex_unlock(&ks->lock);
+
+ while (state != EEPROM_COMPLETE) {
+ /* falling clock period starts... */
+ /* set EED_IO pin for control and address */
+ eepcr &= ~EEPCR_EEDO;
+ switch (state) {
+ case EEPROM_CONTROL:
+ eepcr |= ((ctrl >> bit_count) & 1) << 2;
+ if (bit_count-- <= 0) {
+ bit_count = addr_len - 1;
+ state = EEPROM_ADDRESS;
+ }
+ break;
+ case EEPROM_ADDRESS:
+ eepcr |= ((addr >> bit_count) & 1) << 2;
+ bit_count--;
+ break;
+ case EEPROM_DATA:
+ /* Change to receive mode */
+ eepcr &= ~EEPCR_EESRWA;
+ break;
+ }
+
+ /* lower clock */
+ eepcr &= ~EEPCR_EESCK;
+
+ mutex_lock(&ks->lock);
+ ks8851_wrreg16(ks, KS_EEPCR, eepcr);
+ mutex_unlock(&ks->lock);
+
+ /* waitread period / 2 */
+ udelay(EEPROM_SK_PERIOD / 2);
+
+ /* rising clock period starts... */
+
+ /* raise clock */
+ mutex_lock(&ks->lock);
+ eepcr |= EEPCR_EESCK;
+ ks8851_wrreg16(ks, KS_EEPCR, eepcr);
+ mutex_unlock(&ks->lock);
+
+ /* Manage read */
+ switch (state) {
+ case EEPROM_ADDRESS:
+ if (bit_count < 0) {
+ bit_count = EEPROM_DATA_LEN - 1;
+ state = EEPROM_DATA;
+ }
+ break;
+ case EEPROM_DATA:
+ mutex_lock(&ks->lock);
+ dummy = ks8851_rdreg16(ks, KS_EEPCR);
+ mutex_unlock(&ks->lock);
+ data |= ((dummy >> EEPCR_EESB_OFFSET) & 1) << bit_count;
+ if (bit_count-- <= 0)
+ state = EEPROM_COMPLETE;
+ break;
+ }
+
+ /* wait period / 2 */
+ udelay(EEPROM_SK_PERIOD / 2);
+ }
+
+ /* close transaction */
+ mutex_lock(&ks->lock);
+ eepcr &= ~EEPCR_EECS;
+ ks8851_wrreg16(ks, KS_EEPCR, eepcr);
+ eepcr = 0;
+ ks8851_wrreg16(ks, KS_EEPCR, eepcr);
+ mutex_unlock(&ks->lock);
+
+ return data;
+}
+
+/**
+ * ks8851_eeprom_write - write a 16bits word in ks8851 companion EEPROM
+ * @dev: The network device the PHY is on.
+ * @op: operand (can be WRITE, EWEN, EWDS)
+ * @addr: EEPROM address to write
+ * @data: data to write
+ *
+ * eeprom_size: used to define the data coding length. Can be changed
+ * through debug-fs.
+ *
+ * Programs a write on the EEPROM using ks8851 EEPROM SW access f
[PATCH 1/4 v2] ks8851: Add caching of CCR register
CCR register contains information on companion eeprom availability.
Signed-off-by: Sebastien Jan
---
drivers/net/ks8851.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ks8851.c b/drivers/net/ks8851.c
index 9e9f9b3..a84e500 100644
--- a/drivers/net/ks8851.c
+++ b/drivers/net/ks8851.c
@@ -76,7 +76,9 @@ union ks8851_tx_hdr {
* @msg_enable: The message flags controlling driver output (see ethtool).
* @fid: Incrementing frame id tag.
* @rc_ier: Cached copy of KS_IER.
+ * @rc_ccr: Cached copy of KS_CCR.
* @rc_rxqcr: Cached copy of KS_RXQCR.
+ * @eeprom_size: Companion eeprom size in Bytes, 0 if no eeprom
*
* The @lock ensures that the chip is protected when certain operations are
* in progress. When the read or write packet transfer is in progress, most
@@ -107,6 +109,8 @@ struct ks8851_net {
u16 rc_ier;
u16 rc_rxqcr;
+ u16 rc_ccr;
+ u16 eeprom_size;
struct mii_if_info mii;
struct ks8851_rxctrlrxctrl;
@@ -1279,6 +1283,14 @@ static int __devinit ks8851_probe(struct spi_device *spi)
goto err_id;
}
+ /* cache the contents of the CCR register for EEPROM, etc. */
+ ks->rc_ccr = ks8851_rdreg16(ks, KS_CCR);
+
+ if (ks->rc_ccr & CCR_EEPROM)
+ ks->eeprom_size = 128;
+ else
+ ks->eeprom_size = 0;
+
ks8851_read_selftest(ks);
ks8851_init_mac(ks);
--
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] omap: gpio: Fix compilation warnings
This patch fixes following compilation warnings:
In function 'omap2_gpio_resume_after_retention':
2096: warning: 'l' may be used uninitialized in this function
In function 'omap2_gpio_prepare_for_retention':
2039: warning: 'l2' may be used uninitialized in this function
2039: warning: 'l1' may be used uninitialized in this function
Which got introduced in commit ID:
commit 3f1686a9bfe74979c6ad538c78039730f665f77e
Author: Tony Lindgren
Date: Mon Feb 15 09:27:25 2010 -0800
omap: Fix gpio.c for multi-omap for omap4
By making the first value assignation conditional in runtime, and
making the compiler think they could be used uninitialized.
Signed-off-by: Sergio Aguirre
---
arch/arm/plat-omap/gpio.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 45a225d..f0d5c2f 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -2036,7 +2036,7 @@ void omap2_gpio_prepare_for_retention(void)
* IRQs will be generated. See OMAP2420 Errata item 1.101. */
for (i = 0; i < gpio_bank_count; i++) {
struct gpio_bank *bank = &gpio_bank[i];
- u32 l1, l2;
+ u32 l1 = 0, l2 = 0;
if (!(bank->enabled_non_wakeup_gpios))
continue;
@@ -2093,7 +2093,7 @@ void omap2_gpio_resume_after_retention(void)
return;
for (i = 0; i < gpio_bank_count; i++) {
struct gpio_bank *bank = &gpio_bank[i];
- u32 l, gen, gen0, gen1;
+ u32 l = 0, gen, gen0, gen1;
if (!(bank->enabled_non_wakeup_gpios))
continue;
--
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 3/3] omap: rx51: Add supplies for the tlv320aic3x codec driver
On Wed, 5 May 2010 08:15:39 -0700 Tony Lindgren wrote: > * Mark Brown [100505 07:20]: > > Seems sensible to merge this along with the CODEC driver patch it > > depends on if everyone else is happy (assuming no merge issues)? > > Sounds good to me. I'll take the other ones, if there are merge issues > then we can move some of the other patches into your tree too. > > Acked-by: Tony Lindgren I would rather keep the board-rx51-peripherals.c in linux-omap sync than get the N900 audio working as soon as possible :-) None of these patches are build or boot critical so I can wait & repost the last one when the codec patches hit into mainline. Only harm from some missing board-rx51-peripherals.c patch is that codec either doesn't probe or is kept in reset but system boots up fine. And trees are clean too! -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 0/2] omap-sham: OMAP SHA1/MD5 driver
* Herbert Xu [100502 20:07]: > On Wed, Apr 28, 2010 at 05:18:05PM +0300, Dmitry Kasatkin wrote: > > Changes to v4: > > - concurrent requests support via queue > > - hmac > > - shash support removed > > > > Dmitry Kasatkin (2): > > crypto: updates omap sham device related platform code > > crypto: omap-sham - omap sha1 & md5 driver > > Both patches applied. Thanks for all your hard work Dmitry! Just noticed that the first patch should be updated: CONFIG_ARCH_OMAP2 instead of CONFIG_ARCH_OMAP24XX CONFIG_ARCH_OMAP3 instead of CONFIG_ARCH_OMAP34XX BTW, chances are that this part will conflict with other omap patches. But if that happens, we can move it to the omap for-next. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCHv2 1/4] gpiolib: introduce set_debounce method
On Tue, May 04, 2010 at 03:40:30PM -0700, Tony Lindgren wrote: > * 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. will do it tomorrow, but it would be good to hear from Dave before. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [CBUS PATCH 1/1] CBUS: Fix broken compilation
On Wed, May 05, 2010 at 06:05:29PM +0300, Carlos Chinea wrote: > Include explicitly slab.h in: > drivers/cbus/cbus.c > drivers/cbus/retu-headset.c > drivers/cbus/retu-user.c > drivers/cbus/retu-wdt.c > drivers/cbus/tahvo-user.c > > Compile tested with n8x0_defconfig > > Signed-off-by: Carlos Chinea do you need to update your tree ? tony applied a patch from me already, or did I miss something else ? I'm sure I compile with n770_defconf and n8x0_defconfig. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: Update FIFO mode_5_cfg to accomodate 4K
On Tue, May 04, 2010 at 02:40:58PM +0530, Gadiyar, Anand wrote: > > 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? I had sent a version of that to linux-...@vger, will dig it and resend. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] usb: ehci-omap: fix Si version related programming
On Tue, May 04, 2010 at 01:15:23PM +0530, Ajay Kumar Gupta wrote:
> @@ -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");
this shouldn't be here. please pass down a flag through platform_data
for such checks.
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Disable the non working eMMC on Zoom2/3
* Madhusudhan [100430 09:52]: > > > > > > > > > > > Hmm, finally got around looking into this again. Looks like the mmc > > > > > is now working on my zoom3 with the current Linus' tree at commit > > > > > 7c6bd2010fced38444c9fd658f4c6ce61bd185bf. So I guess something that > > > > > we had in omap-fixes fixed this. Or maybe some fix for drivers/mmc? > > > > > > > > > > This is with the debug_ll patch applied: > > > > > > > > > > https://patchwork.kernel.org/patch/87532/ > > > > > > > > For the microSD card, turns out the card I used was flakey. So > > > > that should explain some of the problems. I'm almost certain > > > > I tried with two different cards earlier though. In any case, > > > > let's assume the problem is only the eMMC. > > > > > > > Sorry, I did not get a complete picture. Your earlier email said that > > with > > > Linus tree eMMC on your Zoom3 is working. Is that correct? > > > > Nope, now the microSD is working, eMMC is not working. > > > > > IMHO, an omap level fix can not solve the problem with eMMC because as I > > can > > > see from the log you provided above that a 16G device is detected as 1G. > > > This is certainly due to the issue I mentioned earlier. > > > > OK > > This means that some production boards still have this issue with eMMC. So > my patch disables the support for MMC2 on zoom boards. Would you consider > that? But is it also broken on zoom2? And what about this "Simulate multi mmc card as one big" 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: Old DSS code broken as module (was "RE: [PATCH 11/11] omap2/3/4: Disable CONFIG_FB_OMAP in omap3_defconfig")
From: Tony Lindgren [mailto:t...@atomide.com] Sent: Wednesday, May 05, 2010 12:44 PM > * Aguirre, Sergio [100505 10:27]: > > Tony, > > > > > -Original Message- > > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > > > ow...@vger.kernel.org] On Behalf Of Tony Lindgren > > > Sent: Friday, April 30, 2010 3:34 PM > > > To: linux-arm-ker...@lists.infradead.org > > > Cc: linux-omap@vger.kernel.org > > > Subject: [PATCH 11/11] omap2/3/4: Disable CONFIG_FB_OMAP in > > > omap3_defconfig > > > > > > 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 allows booting omap3_defconfig on various omaps. Tested on > > > 2420-n8x0, 3430-n900, 3630-zoom3 and 4430-blaze. Note that n8x0 > > > still has issues with starting user space because of TLS and > > > VFP. > > > > (Looping Tomi) > > > > Unfortunately, your patch is uncovering an issue with old DSS code to > > compile it as module, which I think is caused by this: > > > > A single omapfb.ko is attempted to be created in drivers/video/omap/ > folder, > > but the included source files (DSS code + lcd drivers), results in > multiple > > module_init entries added in a single module, and therefore giving > errors of > > duplicate init_module entries between omapfb_main.c and the lcd_*.c > files. > > > > So, either you disable old DSS driver completely, or you have it as > > built-in. > > OK thanks for pointing that out. I'll disable it so we have a > booting omap3_defconfig (with the modules compiling). In my local tree, I just have created this simple change, which could be reverted IF old DSS is intended to be used as a module in the future. I don't know how acceptable is to have it officially applied though. Regards, Sergio > > Regards, > > Tony 0001-omapfb-Remove-tristate-option-in-Kconfig.patch Description: 0001-omapfb-Remove-tristate-option-in-Kconfig.patch
Re: [PATCH] OMAP3: PM: fix AM35x musb issue with AUTOIDLE bit in CONTROL_SYSCONFIG
Ajay Kumar Gupta writes: > MUSB interface on AM35x stops working when we set AUTOIDLE bit (D0) in > CONTROL_SYSCONFIG(0x48002010) register. why? stops working in what way? I think you need to investigate more into why this is happening. This suggest to me that something in the MUSB device/driver init is not quite right for these boards. Kevin > 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: Old DSS code broken as module (was "RE: [PATCH 11/11] omap2/3/4: Disable CONFIG_FB_OMAP in omap3_defconfig")
* Aguirre, Sergio [100505 10:27]: > Tony, > > > -Original Message- > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > > ow...@vger.kernel.org] On Behalf Of Tony Lindgren > > Sent: Friday, April 30, 2010 3:34 PM > > To: linux-arm-ker...@lists.infradead.org > > Cc: linux-omap@vger.kernel.org > > Subject: [PATCH 11/11] omap2/3/4: Disable CONFIG_FB_OMAP in > > omap3_defconfig > > > > 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 allows booting omap3_defconfig on various omaps. Tested on > > 2420-n8x0, 3430-n900, 3630-zoom3 and 4430-blaze. Note that n8x0 > > still has issues with starting user space because of TLS and > > VFP. > > (Looping Tomi) > > Unfortunately, your patch is uncovering an issue with old DSS code to > compile it as module, which I think is caused by this: > > A single omapfb.ko is attempted to be created in drivers/video/omap/ folder, > but the included source files (DSS code + lcd drivers), results in multiple > module_init entries added in a single module, and therefore giving errors of > duplicate init_module entries between omapfb_main.c and the lcd_*.c files. > > So, either you disable old DSS driver completely, or you have it as > built-in. OK thanks for pointing that out. I'll disable it so we have a booting omap3_defconfig (with the modules compiling). 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
Old DSS code broken as module (was "RE: [PATCH 11/11] omap2/3/4: Disable CONFIG_FB_OMAP in omap3_defconfig")
Tony, > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Tony Lindgren > Sent: Friday, April 30, 2010 3:34 PM > To: linux-arm-ker...@lists.infradead.org > Cc: linux-omap@vger.kernel.org > Subject: [PATCH 11/11] omap2/3/4: Disable CONFIG_FB_OMAP in > omap3_defconfig > > 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 allows booting omap3_defconfig on various omaps. Tested on > 2420-n8x0, 3430-n900, 3630-zoom3 and 4430-blaze. Note that n8x0 > still has issues with starting user space because of TLS and > VFP. (Looping Tomi) Unfortunately, your patch is uncovering an issue with old DSS code to compile it as module, which I think is caused by this: A single omapfb.ko is attempted to be created in drivers/video/omap/ folder, but the included source files (DSS code + lcd drivers), results in multiple module_init entries added in a single module, and therefore giving errors of duplicate init_module entries between omapfb_main.c and the lcd_*.c files. So, either you disable old DSS driver completely, or you have it as built-in. 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 v8 2/2] omap hsmmc: adaptation of sdma descriptor autoloading feature
> >> + if (cpu_is_omap44xx() || cpu_is_omap3630()) {
> > Can we avoid above by passing this part of platform data??
> > devices.c
>
> I am not clear about the method. The board files export the
> omap_mmc_platform_data.
> Does it imply that all board files have to change and export
> the capability so that it can be queried ?
>
I dont see why this capability needs to be passed from the platform data.
As this feature is dependant on omap it is okay to have a cpu check in the
driver as the patch is doing it.
> >> + host->dma_ctrl_buf = dma_alloc_coherent(NULL,
> >> + DMA_CTRL_BUF_SIZE,
> >> + &host->dma_ctrl_buf_phy,
> >> + 0);
> >> + if (host->dma_ctrl_buf != NULL)
> >> + host->dma_caps |= DMA_TYPE_SDMA_DLOAD;
> >> + }
> >> +
> >> /* Since we do only SG emulation, we can have as many segs
> >> * as we want. */
> > Not your patch but above commenting style isn't right
> OK
--
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 1/3] OMAP4: SPI: Fix Driver Kconfig
* Arce, Abraham [100505 00:05]: > 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..f950b63 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 OMAP" > + depends on ARCH_OMAP2PLUS > help > - SPI master controller for OMAP24xx/OMAP34xx Multichannel SPI > + SPI master controller for OMAP24XX and later Multichannel SPI > (McSPI) modules. > > config SPI_OMAP_100K Planning on merging this via omap tree so we get the omap4 Ethernet working. That is after the related patch has been updated to check the result from gpio_request. Anybody from the spi list care to ack this? 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 v1 2/3] OMAP4: Ethernet: KS8851 Board Support
* Arce, Abraham [100505 01:06]:
> Manjunath,
>
> > > +
> > > +static void omap_ethernet_init(void)
> > > +{
> > > + gpio_request(ETHERNET_KS8851_POWER_ENABLE, "ethernet");
> > > + gpio_direction_output(ETHERNET_KS8851_POWER_ENABLE, 1);
> > > + gpio_request(ETHERNET_KS8851_QUART, "quart");
> > > + gpio_direction_output(ETHERNET_KS8851_QUART, 1);
> > > + gpio_request(ETHERNET_KS8851_IRQ, "ks8851");
> >
> > Any reason for not checking return value of gpio_request()?
> >
>
> Thought initially about them as dedicated lines for ethernet avoiding
> both reasons to check for a gpio's request:
>
> 1. invalid gpio
> 2. already claimed gpio
You still need to check for the result.
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 v8 1/2] sDMA: descriptor autoloading feature
On Wed, May 5, 2010 at 5:31 PM, Shilimkar, Santosh
wrote:
>
>
>> -Original Message-
>> From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of
>> Venkatraman S
>> Sent: Wednesday, May 05, 2010 5:20 PM
>> To: Shilimkar, Santosh
>> Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
>> linux-arm-ker...@lists.infradead.org;
>> Chikkature Rajashekar, Madhusudhan; Adrian Hunter; Tony Lindgren
>> Subject: Re: [PATCH v8 1/2] sDMA: descriptor autoloading feature
>>
>> [Long sections have been trimmed to the context of the discussion]
>> On Wed, May 5, 2010 at 3:02 PM, Shilimkar, Santosh
>> wrote:
>> >> -Original Message-
>> >> +static int dma_sglist_set_phy_params(struct omap_dma_sglist_node *sghead,
>> >> + dma_addr_t phyaddr, int nelem)
>> >> +{
>> >> + struct omap_dma_sglist_node *sgcurr, *sgprev;
>> >> + dma_addr_t elem_paddr = phyaddr;
>> >> +
>> >> + for (sgprev = sghead;
>> >> + sgprev < sghead + nelem;
>> >> + sgprev++) {
>> >> +
>> >> + sgcurr = sgprev + 1;
>> >> + sgprev->next = sgcurr;
>> >> + elem_paddr += (int)sizeof(*sgcurr);
>> >> + sgprev->next_desc_add_ptr = elem_paddr;
>> >> +
>> >> + switch (sgcurr->desc_type) {
>> >> + case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE1:
>> >> + omap_dma_list_set_ntype(sgprev, 1);
>> >> + break;
>> >> +
>> >> + case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE2a:
>> >> + /* intentional no break */
>> >> + case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE2b:
>> >> + omap_dma_list_set_ntype(sgprev, 2);
>> >> + break;
>> >> +
>> >> + case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE3a:
>> >> + /* intentional no break */
>> >> + case OMAP_DMA_SGLIST_DESCRIPTOR_TYPE3b:
>> >> + omap_dma_list_set_ntype(sgprev, 3);
>> >> + break;
>> >> +
>> >> + default:
>> >> + return -EINVAL;
>> >> +
>> >> + }
>> > Are we supporting all the descriptor types. I think only type2a is
>> > supported. In that case please add FIXME, or WARN message here.
>>
>> From DMA perspective, all are supported - no restrictions. Only I have
>> not figured
>> out how to use type 2b and type 3b descriptors. It's not the fault of
>> DMA driver or
>> specification :-) It's actually upto the client to select the right type.
> OK. Then the question which I wanted to ask.
> For TX, 2b should have been better choice than 2a isn't it?
Not much of a difference (as the space allocation is common), but I
couldn't get 2b working correctly.
Will try that once I get some clarification from hardware team.
>>
>> >> +
>> >> + lcfg->sghead = sgparams;
>> >> + lcfg->num_elem = nelem;
>> >> + lcfg->sgheadphy = padd;
>> >> + lcfg->pausenode = -1;
>> >> +
>> >> +
>> >> + if (NULL == chparams)
>> > Minute point really. Better readability "ch_params"
>> OK
>>
>> >> + dma_write(l, CDP(lch));
>> >> + dma_write((lcfg->sgheadphy), CNDP(lch));
>> >> + /**
>> >> + * Barrier needed as writes to the
>> >> + * descriptor memory needs to be flushed
>> >> + * before it's used by DMA controller
>> >> + */
>> > Little bit of re-wording if you can.
>> > Also you don't wanted the double **
>> > /*
>> > * Memory barrier is needed because data may still be
>> > * in the write buffer. The barrier drains write buffers and
>> > * ensures that DMA sees correct descriptors
>> > */
>> OK
>>
>> >> + wmb();
>> >> + omap_start_dma(lch);
>> >> +
>> >> + /* Maintain the pause state in descriptor */
>> >> + omap_set_dma_sglist_pausebit(lcfg, lcfg->pausenode, 0);
>> >> + omap_set_dma_sglist_pausebit(lcfg, pauseafter, 1);
>> >> +
>> >> + /**
>> >> + * Barrier needed as writes to the
>> >> + * descriptor memory needs to be flushed
>> >> + * before it's used by DMA controller
>> >> + */
>> > Description change if possible
>> OK
>>
>> >> + wmb();
>> >> +
>> >> + /* Errata i557 - pausebit should be cleared in no standby mode */
>> > This should have been
>>
>> I couldn't understand this comment.
> This should have been a separate patch since it's an errata.
OK.
>>
>> >> + sys_cf = dma_read(OCP_SYSCONFIG);
>> >> + l = sys_cf;
>> >> + /* Middle mode reg set no Standby */
>> >> + l &= ~(BIT(12) | BIT(13));
>> >> + dma_write(l, OCP_SYSCONFIG);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor autoloading feature
[Long sections have been trimmed to the context of discussion]
Shilimkar, Santosh wrote:
>
>> -Original Message-
>> From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of
>> Venkatraman S
>> Sent: Thursday, April 29, 2010 11:05 PM
>> To: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
>> linux-arm-ker...@lists.arm.linux.org.uk
>> Cc: Chikkature Rajashekar, Madhusudhan; Adrian Hunter; Kadiyala, Kishore;
>> Shilimkar, Santosh; Tony
>> Lindgren
>> Subject: [PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor
>> autoloading feature
>>
>> From 1c63dd42fc6c563c931168779ce73401332faa52 Mon Sep 17 00:00:00 2001
>> From: Venkatraman S
>> Date: Thu, 29 Apr 2010 22:43:31 +0530
>> Subject: [PATCH 2/2] omap hsmmc: adaptation of sdma descriptor
>> autoloading feature
>>
>> Start to use the sDMA descriptor autoloading feature.
>> For large datablocks, the MMC driver has to repeatedly setup,
>> program and teardown the dma channel for each element of the
>> sglist received in omap_hsmmc_request.
>>
>> By using descriptor autoloading, transfers from / to each element of
>> the sglist is pre programmed into a linked list. The sDMA driver
>> completes the entire transaction and provides a single interrupt.
>>
>> Due to this, number of dma interrupts for a typical 100MB transfer on the
>> MMC is
>> reduced from 25000 to about 400 (approximate). Transfer speeds are
>> improved by ~5%.
>> (Though it varies on the size of read / write & improves on huge transfers)
>>
>> Descriptor autoloading is available only in 3630 and 4430 (as of now).
>> Hence normal DMA mode is also retained.
>>
>> Signed-off-by: Venkatraman S
>> CC: Adrian Hunter
>> CC: Madhusudhan C
>> CC: Shilimkar Santosh
>> CC: Tony Lindgren
>> ---
>> Changes since previous version
>> * Rebased to Adrian Hunter's interrupt syncronisation patch
>> https://patchwork.kernel.org/patch/94670/
>> * Rename ICR name definition
>> drivers/mmc/host/omap_hsmmc.c | 148
>> ++--
>> 1 files changed, 125 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
>> index 65093d4..095fd94 100644
>> --- a/drivers/mmc/host/omap_hsmmc.c
>> +++ b/drivers/mmc/host/omap_hsmmc.c
>> @@ -102,6 +102,8 @@
>> #define SRD (1 << 26)
>> #define SOFTRESET (1 << 1)
>> #define RESETDONE (1 << 0)
>> +/* End of superblock indicator for sglist transfers */
>> +#define DMA_ICR_SGLIST_END 0x4D00
>>
>> /*
>> * FIXME: Most likely all the data using these _DEVID defines should come
>> @@ -118,6 +120,12 @@
>> #define OMAP_MMC_MASTER_CLOCK 9600
>> #define DRIVER_NAME "mmci-omap-hs"
>>
>> +#define DMA_TYPE_NODMA 0
> " DMA_TYPE_NODMA" doesn't make sense
>> +#define DMA_TYPE_SDMA 1
>> +#define DMA_TYPE_SDMA_DLOAD 2
>
> How about ??
> #define TRANSFER_NODMA 0
> #define TRANSFER_SDMA_NORMAL 1
> #define TRANSFER_SDMA_DESCRIPTOR 2
> I think ADMA is also in pipeline, so it can become then
> #define TRANSFER_ADMA_DESCRIPTOR 3
Yes I was planning to use 3 for ADMA, but the names don't
make a big difference.
>> +
>> +#define DMA_CTRL_BUF_SIZE (PAGE_SIZE * 3)
>> +
>> /* Timeouts for entering power saving states on inactivity, msec */
>> #define OMAP_MMC_DISABLED_TIMEOUT 100
>> #define OMAP_MMC_SLEEP_TIMEOUT 1000
>> @@ -170,7 +178,11 @@ struct omap_hsmmc_host {
>> u32 bytesleft;
>> int suspended;
>> int irq;
>> - int use_dma, dma_ch;
>> + int dma_caps;
>> + int dma_in_use;
> This flag isn't necessary. What you are doing is
> just renaming it. Can't you avoid that ??
> Inudertand the intent behind "dma_in_use " instead
> of "use_dma", but you can surely avoid this change.
Actually there is a shift in the meaning of these variables
so I believe the change is necessary.
With my changes, the type of DMA to use (SDMA, SDMA_DESC_LOAD)
[and in the future NODMA, ADMA] can vary on a per transfer basis.
Previously use_dma was a static capability variable of whether DMA
was available. That has been move to dma_caps. The dma_in_use,
as the name more intuitively suggests, keeps track of the type of transfer
used in the current transaction.
>> {
>> unsigned int irq_mask;
>>
>> - if (host->use_dma)
>> + if (host->dma_in_use)
> This will go with no flag change.
Explanation as above
>> irq_mask = INT_EN_MASK & ~(BRR_ENABLE | BWR_ENABLE);
>> else
>> irq_mask = INT_EN_MASK;
>> @@ -813,7 +825,7 @@ omap_hsmmc_start_command(struct omap_hsmmc_host
>> *host, struct mmc_command *cmd,
>> cmdreg &= ~(DDIR);
>> }
>>
>> - if (host->use_dma)
>> + if (host->dma_in_use)
> ditto
>> cmdreg |= DMA_EN;
>>
>>
[PATCH v3 4/4] omap: mailbox: convert block api to kfifo
The underlying buffering implementation of mailbox
is converted from block API to kfifo due to the simplicity
and speed of kfifo.
The default size of the kfifo buffer is set to 256 bytes.
This value is configurable at compile time (via
CONFIG_OMAP_MBOX_KFIFO_SIZE), and can be changed at
runtime (via the mbox_kfifo_size module parameter).
Signed-off-by: Ohad Ben-Cohen
Signed-off-by: Hari Kanigeri
---
If you want, you can also reach me at < ohadb at ti dot com >.
arch/arm/plat-omap/Kconfig|9 +++
arch/arm/plat-omap/include/plat/mailbox.h |4 +-
arch/arm/plat-omap/mailbox.c | 112 +---
3 files changed, 63 insertions(+), 62 deletions(-)
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 6da796e..f4b0029 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -106,6 +106,15 @@ config OMAP_MBOX_FWK
Say Y here if you want to use OMAP Mailbox framework support for
DSP, IVA1.0 and IVA2 in OMAP1/2/3.
+config OMAP_MBOX_KFIFO_SIZE
+ int "Mailbox kfifo default buffer size (bytes)"
+ depends on OMAP_MBOX_FWK
+ default 256
+ help
+ Specify the default size of mailbox's kfifo buffers (bytes).
+ This can also be changed at runtime (via the mbox_kfifo_size
+ module parameter).
+
config OMAP_IOMMU
tristate
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h
b/arch/arm/plat-omap/include/plat/mailbox.h
index 729166b..0c3c4a5 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -5,8 +5,8 @@
#include
#include
-#include
#include
+#include
typedef u32 mbox_msg_t;
struct omap_mbox;
@@ -42,7 +42,7 @@ struct omap_mbox_ops {
struct omap_mbox_queue {
spinlock_t lock;
- struct request_queue*queue;
+ struct kfifofifo;
struct work_struct work;
struct tasklet_struct tasklet;
int (*callback)(void *);
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 7c60550..908d9d2 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -21,11 +21,14 @@
*
*/
+#include
#include
#include
#include
#include
#include
+#include
+#include
#include
@@ -35,6 +38,10 @@ static DEFINE_SPINLOCK(mboxes_lock);
static int mbox_configured;
+static unsigned int mbox_kfifo_size = CONFIG_OMAP_MBOX_KFIFO_SIZE;
+module_param(mbox_kfifo_size, uint, S_IRUGO);
+MODULE_PARM_DESC(mbox_kfifo_size, "Size of omap's mailbox kfifo (bytes)");
+
/* Mailbox FIFO handle functions */
static inline mbox_msg_t mbox_fifo_read(struct omap_mbox *mbox)
{
@@ -67,7 +74,7 @@ static inline int is_mbox_irq(struct omap_mbox *mbox,
omap_mbox_irq_t irq)
/*
* message sender
*/
-static int __mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg)
+static int __mbox_poll_for_space(struct omap_mbox *mbox)
{
int ret = 0, i = 1000;
@@ -78,49 +85,50 @@ static int __mbox_msg_send(struct omap_mbox *mbox,
mbox_msg_t msg)
return -1;
udelay(1);
}
- mbox_fifo_write(mbox, msg);
return ret;
}
-
int omap_mbox_msg_send(struct omap_mbox *mbox, mbox_msg_t msg)
{
+ struct omap_mbox_queue *mq = mbox->txq;
+ int ret = 0, len;
- struct request *rq;
- struct request_queue *q = mbox->txq->queue;
+ spin_lock(&mq->lock);
- rq = blk_get_request(q, WRITE, GFP_ATOMIC);
- if (unlikely(!rq))
- return -ENOMEM;
+ if (kfifo_avail(&mq->fifo) < sizeof(msg)) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ len = kfifo_in(&mq->fifo, (unsigned char *)&msg, sizeof(msg));
+ WARN_ON(len != sizeof(msg));
- blk_insert_request(q, rq, 0, (void *) msg);
tasklet_schedule(&mbox->txq->tasklet);
- return 0;
+out:
+ spin_unlock(&mq->lock);
+ return ret;
}
EXPORT_SYMBOL(omap_mbox_msg_send);
static void mbox_tx_tasklet(unsigned long tx_data)
{
- int ret;
- struct request *rq;
struct omap_mbox *mbox = (struct omap_mbox *)tx_data;
- struct request_queue *q = mbox->txq->queue;
-
- while (1) {
-
- rq = blk_fetch_request(q);
-
- if (!rq)
- break;
+ struct omap_mbox_queue *mq = mbox->txq;
+ mbox_msg_t msg;
+ int ret;
- ret = __mbox_msg_send(mbox, (mbox_msg_t)rq->special);
- if (ret) {
+ while (kfifo_len(&mq->fifo)) {
+ if (__mbox_poll_for_space(mbox)) {
omap_mbox_enable_irq(mbox, IRQ_TX);
- blk_requeue_request(q, rq);
- return;
+ break;
}
- blk_end_request_all(rq, 0);
+
+ ret = kfifo_out(&mq->fifo, (unsigned char *)&msg,
+
[PATCH v3 3/4] omap: mailbox: remove (un)likely macros from cold paths
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 | 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
--
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 v3 2/4] omap: mailbox cleanup: split MODULE_AUTHOR line
use multiple MODULE_AUTHOR lines for multiple authors
Signed-off-by: Ohad Ben-Cohen
---
If you want, you can also reach me at < ohadb at ti dot com >.
arch/arm/mach-omap2/mailbox.c |3 ++-
arch/arm/plat-omap/mailbox.c |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 318f363..763272c 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -486,5 +486,6 @@ module_exit(omap2_mbox_exit);
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("omap mailbox: omap2/3/4 architecture specific functions");
-MODULE_AUTHOR("Hiroshi DOYU , Paul Mundt");
+MODULE_AUTHOR("Hiroshi DOYU ");
+MODULE_AUTHOR("Paul Mundt");
MODULE_ALIAS("platform:"DRV_NAME);
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index af3a6ac..5140efc 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -419,4 +419,5 @@ module_exit(omap_mbox_exit);
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("omap mailbox: interrupt driven messaging");
-MODULE_AUTHOR("Toshihiro Kobayashi and Hiroshi DOYU");
+MODULE_AUTHOR("Toshihiro Kobayashi");
+MODULE_AUTHOR("Hiroshi DOYU");
--
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 v3 1/4] omap: mailbox: convert rwlocks to spinlock
rwlocks are slower and have potential starvation issues
therefore spinlocks are generally preferred.
see also: http://lwn.net/Articles/364583/
Signed-off-by: Ohad Ben-Cohen
Signed-off-by: Kanigeri Hari
---
If you want, you can also reach me at < ohadb at ti dot com >.
arch/arm/plat-omap/mailbox.c | 30 +++---
1 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 08a2df7..af3a6ac 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -31,7 +31,7 @@
static struct workqueue_struct *mboxd;
static struct omap_mbox *mboxes;
-static DEFINE_RWLOCK(mboxes_lock);
+static DEFINE_SPINLOCK(mboxes_lock);
static int mbox_configured;
@@ -249,16 +249,16 @@ static int omap_mbox_startup(struct omap_mbox *mbox)
struct omap_mbox_queue *mq;
if (likely(mbox->ops->startup)) {
- write_lock(&mboxes_lock);
+ spin_lock(&mboxes_lock);
if (!mbox_configured)
ret = mbox->ops->startup(mbox);
if (unlikely(ret)) {
- write_unlock(&mboxes_lock);
+ spin_unlock(&mboxes_lock);
return ret;
}
mbox_configured++;
- write_unlock(&mboxes_lock);
+ spin_unlock(&mboxes_lock);
}
ret = request_irq(mbox->irq, mbox_interrupt, IRQF_SHARED,
@@ -304,12 +304,12 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
free_irq(mbox->irq, mbox);
if (unlikely(mbox->ops->shutdown)) {
- write_lock(&mboxes_lock);
+ spin_lock(&mboxes_lock);
if (mbox_configured > 0)
mbox_configured--;
if (!mbox_configured)
mbox->ops->shutdown(mbox);
- write_unlock(&mboxes_lock);
+ spin_unlock(&mboxes_lock);
}
}
@@ -330,14 +330,14 @@ struct omap_mbox *omap_mbox_get(const char *name)
struct omap_mbox *mbox;
int ret;
- read_lock(&mboxes_lock);
+ spin_lock(&mboxes_lock);
mbox = *(find_mboxes(name));
if (mbox == NULL) {
- read_unlock(&mboxes_lock);
+ spin_unlock(&mboxes_lock);
return ERR_PTR(-ENOENT);
}
- read_unlock(&mboxes_lock);
+ spin_unlock(&mboxes_lock);
ret = omap_mbox_startup(mbox);
if (ret)
@@ -363,15 +363,15 @@ int omap_mbox_register(struct device *parent, struct
omap_mbox *mbox)
if (mbox->next)
return -EBUSY;
- write_lock(&mboxes_lock);
+ spin_lock(&mboxes_lock);
tmp = find_mboxes(mbox->name);
if (*tmp) {
ret = -EBUSY;
- write_unlock(&mboxes_lock);
+ spin_unlock(&mboxes_lock);
goto err_find;
}
*tmp = mbox;
- write_unlock(&mboxes_lock);
+ spin_unlock(&mboxes_lock);
return 0;
@@ -384,18 +384,18 @@ int omap_mbox_unregister(struct omap_mbox *mbox)
{
struct omap_mbox **tmp;
- write_lock(&mboxes_lock);
+ spin_lock(&mboxes_lock);
tmp = &mboxes;
while (*tmp) {
if (mbox == *tmp) {
*tmp = mbox->next;
mbox->next = NULL;
- write_unlock(&mboxes_lock);
+ spin_unlock(&mboxes_lock);
return 0;
}
tmp = &(*tmp)->next;
}
- write_unlock(&mboxes_lock);
+ spin_unlock(&mboxes_lock);
return -EINVAL;
}
--
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 v3 0/4] omap: mailbox: cleanup & simplify
This series includes comments from Hiroshi and Tony (thanks!). Changes since v2: - add mbox_kfifo_size module parameter sanity checks - remove (un)likely macros from cold mailbox paths Thanks, Ohad. --- If you want, you can also reach me at < ohadb at ti dot com >. Ohad Ben-Cohen (4): omap: mailbox: convert rwlocks to spinlock omap: mailbox cleanup: split MODULE_AUTHOR line omap: mailbox: remove (un)likely macros from cold paths omap: mailbox: convert block api to kfifo arch/arm/mach-omap2/mailbox.c |3 +- arch/arm/plat-omap/Kconfig|9 ++ arch/arm/plat-omap/include/plat/mailbox.h |4 +- arch/arm/plat-omap/mailbox.c | 155 ++--- 4 files changed, 87 insertions(+), 84 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] omap: mailbox: fix reverse likeliness
On Wed, May 5, 2010 at 6:21 PM, Tony Lindgren wrote:
> * Ohad Ben-Cohen [100504 04:42]:
>> 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:
>
> Looks good to me.
>
> Hiroshi, care to ack/nak all the mailbox and iommu patches you want
> me to merge? Or if you have them in some git branch against mainline
> -rc6 that would be cool too.
I'll post a v3 with all recent updated in a few minutes. I hope it helps.
Thanks,
Ohad.
>
> We need to get the ones we want to merge into linux-arm-kernel for
> review soon, I don't think they been posted there yet.
>
> Regards,
>
> Tony
>
>
>
>> 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
>
--
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
* Ohad Ben-Cohen [100504 04:42]:
> 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:
Looks good to me.
Hiroshi, care to ack/nak all the mailbox and iommu patches you want
me to merge? Or if you have them in some git branch against mainline
-rc6 that would be cool too.
We need to get the ones we want to merge into linux-arm-kernel for
review soon, I don't think they been posted there yet.
Regards,
Tony
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] omap: rx51: Add supplies for the tlv320aic3x codec driver
On Wed, May 05, 2010 at 08:15:39AM -0700, Tony Lindgren wrote: > Sounds good to me. I'll take the other ones, if there are merge issues > then we can move some of the other patches into your tree too. > Acked-by: Tony Lindgren OK, please resubmit to ASoC (Liam will be picking this one up since it's OMAP-specific). -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] omap: rx51: Add supplies for the tlv320aic3x codec driver
* Mark Brown [100505 07:20]: > On Wed, May 05, 2010 at 05:20:11PM +0300, Jarkko Nikula wrote: > > > I have one patch more to this set but it cannot be applied before this > > tlv320aic3x patch hits into mainline: > > > http://mailman.alsa-project.org/pipermail/alsa-devel/2010-May/027408.html > > Seems sensible to merge this along with the CODEC driver patch it > depends on if everyone else is happy (assuming no merge issues)? Sounds good to me. I'll take the other ones, if there are merge issues then we can move some of the other patches into your tree too. 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: Upcoming merge window and omap NAND patches
* Mike Rapoport [100505 05:51]: > Ghorai, > > Ghorai, Sukumar wrote: > >Tony, > >I understand your comment/input. And I will work on it. Great, good to hear. > >All existing omap3 boards are using same old fashion. So let me see how many > >board I can test before post the patch. I will update this next week. > > I'd be glad to test the patches on CM-T35 if you'd like to. For this merge window how about just getting rid of OMAP34XX_GPMC_VIRT in the board-*.c files and move that to gpmc-nand.c? This may allow adding more board-*.c NAND files without having to patch all of them later on again. However, if there are more changes needed to all the board-*.c files for the NAND platform data, then let's just fix the existing ones first before adding new ones. After that, looks like most of the work is to move some of the GPMC functions from omap2.c to gpmc.c. Or should they rather be in gpmc-nand.c if they are only used with NAND connected to GPMC? 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
[CBUS PATCH 1/1] CBUS: Fix broken compilation
Include explicitly slab.h in: drivers/cbus/cbus.c drivers/cbus/retu-headset.c drivers/cbus/retu-user.c drivers/cbus/retu-wdt.c drivers/cbus/tahvo-user.c Compile tested with n8x0_defconfig Signed-off-by: Carlos Chinea --- drivers/cbus/cbus.c |1 + drivers/cbus/retu-headset.c |1 + drivers/cbus/retu-user.c|1 + drivers/cbus/retu-wdt.c |1 + drivers/cbus/tahvo-user.c |1 + 5 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/cbus/cbus.c b/drivers/cbus/cbus.c index 00c3c32..2c74d6e 100644 --- a/drivers/cbus/cbus.c +++ b/drivers/cbus/cbus.c @@ -30,6 +30,7 @@ #include #include #include +#include #include #include diff --git a/drivers/cbus/retu-headset.c b/drivers/cbus/retu-headset.c index e798bc2..645679c 100644 --- a/drivers/cbus/retu-headset.c +++ b/drivers/cbus/retu-headset.c @@ -25,6 +25,7 @@ #include #include #include +#include #include "retu.h" diff --git a/drivers/cbus/retu-user.c b/drivers/cbus/retu-user.c index 0f35dc5..7bc97d4 100644 --- a/drivers/cbus/retu-user.c +++ b/drivers/cbus/retu-user.c @@ -33,6 +33,7 @@ #include #include #include +#include #include diff --git a/drivers/cbus/retu-wdt.c b/drivers/cbus/retu-wdt.c index 35932dd..fda8b35 100644 --- a/drivers/cbus/retu-wdt.c +++ b/drivers/cbus/retu-wdt.c @@ -35,6 +35,7 @@ #include #include #include +#include #include diff --git a/drivers/cbus/tahvo-user.c b/drivers/cbus/tahvo-user.c index c0e8daf..b28b015 100644 --- a/drivers/cbus/tahvo-user.c +++ b/drivers/cbus/tahvo-user.c @@ -33,6 +33,7 @@ #include #include #include +#include #include -- 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: [RFC] Initial attempt to make ARM use LMB
On Thu, Mar 25, 2010 at 11:32:48PM +, Russell King - ARM Linux wrote: > LMB... logical memory blocks. > > LM is a different method of managing memory regions during the early > boot period when the usual kernel memory allocators are not up and > running. LMB has been in the kernel for quite some time, and is > already being used by Microblaze, PPC, SH and Sparc. Maybe soon x86 > as well. > > The motivation for this is that there appears to be plans to kill off > the other method - bootmem. (see discussions on the linux-arch ml.) I've now queued the first three patches in this series for the next merge window, which is basically the preparation for moving to LMB. Essentially, that's: - removing useless includes of linux/bootmem.h - sorting the meminfo array prior to sanity_check_meminfo() - moving the mapping of lowmem into mmu.c and making create_mapping() static None of these changes should affect any currently merged platforms, and wouldn't be affected by Ben's LMB updates either. -- 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 v3 08/21] OMAP: DSS2: Taal: Improve taal_power_on() error handling
From: Jani Nikula
Check return values and bail out on errors.
Signed-off-by: Jani Nikula
---
drivers/video/omap2/displays/panel-taal.c | 30 ++--
1 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index d0701e2..a093eda 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -696,16 +696,32 @@ static int taal_power_on(struct omap_dss_device *dssdev)
if (id2 == 0x00 || id2 == 0xff || id2 == 0x81)
td->cabc_broken = true;
- taal_dcs_write_1(DCS_BRIGHTNESS, 0xff);
- taal_dcs_write_1(DCS_CTRL_DISPLAY, (1<<2) | (1<<5)); /* BL | BCTRL */
+ r = taal_dcs_write_1(DCS_BRIGHTNESS, 0xff);
+ if (r)
+ goto err;
- taal_dcs_write_1(DCS_PIXEL_FORMAT, 0x7); /* 24bit/pixel */
+ r = taal_dcs_write_1(DCS_CTRL_DISPLAY,
+ (1<<2) | (1<<5)); /* BL | BCTRL */
+ if (r)
+ goto err;
- taal_set_addr_mode(td->rotate, td->mirror);
- if (!td->cabc_broken)
- taal_dcs_write_1(DCS_WRITE_CABC, td->cabc_mode);
+ r = taal_dcs_write_1(DCS_PIXEL_FORMAT, 0x7); /* 24bit/pixel */
+ if (r)
+ goto err;
- taal_dcs_write_0(DCS_DISPLAY_ON);
+ r = taal_set_addr_mode(td->rotate, td->mirror);
+ if (r)
+ goto err;
+
+ if (!td->cabc_broken) {
+ r = taal_dcs_write_1(DCS_WRITE_CABC, td->cabc_mode);
+ if (r)
+ goto err;
+ }
+
+ r = taal_dcs_write_0(DCS_DISPLAY_ON);
+ if (r)
+ goto err;
r = _taal_enable_te(dssdev, td->te_enabled);
if (r)
--
1.6.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 10/21] OMAP: DSS2: Taal: Change DSI bus locking to avoid deadlock in ESD work
From: Jani Nikula
Move dsi_bus_lock/unlock() out of taal_power_on/off() to avoid deadlock
in taal_esd_work().
Signed-off-by: Jani Nikula
---
drivers/video/omap2/displays/panel-taal.c | 29 +++--
1 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index 214d3cf..af159c1 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -672,8 +672,6 @@ static int taal_power_on(struct omap_dss_device *dssdev)
/* it seems we have to wait a bit until taal is ready */
msleep(5);
- dsi_bus_lock();
-
r = omapdss_dsi_display_enable(dssdev);
if (r) {
dev_err(&dssdev->dev, "failed to enable DSI\n");
@@ -744,8 +742,6 @@ static int taal_power_on(struct omap_dss_device *dssdev)
omapdss_dsi_vc_enable_hs(TCH, true);
- dsi_bus_unlock();
-
return 0;
err:
dev_err(&dssdev->dev, "error while enabling panel, issuing HW reset\n");
@@ -754,8 +750,6 @@ err:
omapdss_dsi_display_disable(dssdev);
err0:
- dsi_bus_unlock();
-
return r;
}
@@ -764,8 +758,6 @@ static void taal_power_off(struct omap_dss_device *dssdev)
struct taal_data *td = dev_get_drvdata(&dssdev->dev);
int r;
- dsi_bus_lock();
-
cancel_delayed_work(&td->esd_work);
r = taal_dcs_write_0(DCS_DISPLAY_OFF);
@@ -784,8 +776,6 @@ static void taal_power_off(struct omap_dss_device *dssdev)
omapdss_dsi_display_disable(dssdev);
td->enabled = 0;
-
- dsi_bus_unlock();
}
static int taal_enable(struct omap_dss_device *dssdev)
@@ -802,7 +792,12 @@ static int taal_enable(struct omap_dss_device *dssdev)
goto err;
}
+ dsi_bus_lock();
+
r = taal_power_on(dssdev);
+
+ dsi_bus_unlock();
+
if (r)
goto err;
@@ -825,9 +820,13 @@ static void taal_disable(struct omap_dss_device *dssdev)
mutex_lock(&td->lock);
+ dsi_bus_lock();
+
if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE)
taal_power_off(dssdev);
+ dsi_bus_unlock();
+
dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
mutex_unlock(&td->lock);
@@ -847,7 +846,12 @@ static int taal_suspend(struct omap_dss_device *dssdev)
goto err;
}
+ dsi_bus_lock();
+
taal_power_off(dssdev);
+
+ dsi_bus_unlock();
+
dssdev->state = OMAP_DSS_DISPLAY_SUSPENDED;
mutex_unlock(&td->lock);
@@ -872,7 +876,12 @@ static int taal_resume(struct omap_dss_device *dssdev)
goto err;
}
+ dsi_bus_lock();
+
r = taal_power_on(dssdev);
+
+ dsi_bus_unlock();
+
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
mutex_unlock(&td->lock);
--
1.6.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
