* [PATCH 0/7] Add support for Freescale's mc34708 to mc13xxx driver
From: Fabio Estevam @ 2012-10-04 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5AVP1L-6A7cmV-kQEfG1C+vczFKT=sQbFtLJDaGau0kRg@mail.gmail.com>
Hi Samuel,
On Wed, Sep 5, 2012 at 11:22 AM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Samuel,
>
> On Thu, Jul 12, 2012 at 8:02 PM, Marc Reilly <marc@cpdesign.com.au> wrote:
>> Hi Uwe,
>>
>>> This series was tested on a Phytec pcm038 (mc13783 on spi) using
>>> traditional boot (i.e. not dt) and on a i.MX53 based machine (mc34708 on
>>> i2c) using dt boot.
>>>
>>> Philippe's patches are already in next, they are just included here for
>>> those who want to test the patches. The 'mfd/mc13xxx: drop modifying
>>> driver's id_table in probe' was already sent out yesterday and is
>>> included here because the last patch depends on it.
>>>
>>
>> For all patches (that don't already have it):
>> Acked-by: Marc Reilly <marc@cpdesign.com.au>
>
> Can this series be applied?
Any comments on this series, please?
I want to add mc34708 support to mx53qsb and need this series to be applied.
^ permalink raw reply
* [PATCH v3 3/6] ARM: davinci: da850: changed SRAM allocator to shared ram.
From: Matt Porter @ 2012-10-04 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506D79A3.4020506@ti.com>
On Thu, Oct 04, 2012 at 05:27:23PM +0530, Sekhar Nori wrote:
> Matt,
>
> On 10/3/2012 8:25 PM, Matt Porter wrote:
> > From: Subhasish Ghosh <subhasish@mistralsolutions.com>
> >
> > This patch modifies the sram allocator to allocate memory
> > from the DA8XX shared RAM.
> >
> > Signed-off-by: Subhasish Ghosh <subhasish@mistralsolutions.com>
> > [rebased onto consolidated SRAM patches]
> > Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
> > [rebased to mainline as consolidated SRAM patches were dropped]
> > Signed-off-by: Matt Porter <mporter@ti.com>
>
> Were you able to test PM with this change or you need my help?
I'll try it out now and if I have problems I may need to enlist your
help here. :)
-Matt
^ permalink raw reply
* [PATCH v3 0/6] uio_pruss cleanup and platform support
From: Sekhar Nori @ 2012-10-04 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121004124253.GC11149@beef>
On 10/4/2012 6:12 PM, Matt Porter wrote:
> On Thu, Oct 04, 2012 at 11:11:45AM +0200, Philipp Zabel wrote:
>> Hi Matt,
>>
>> On 10/3/12, Matt Porter <mporter@ti.com> wrote:
>>> This series enables uio_pruss on DA850 and removes use of the
>>> private SRAM API by the driver. The driver previously was not
>>> enabled by any platform and the private SRAM API was accessing
>>> an invalid SRAM bank.
>>
>> have you seen my SRAM patch series at https://lkml.org/lkml/2012/9/7/281
>> "Add device tree support for on-chip SRAM" ?
>
> Yes.
>
>> I think the generic SRAM/genalloc driver (https://lkml.org/lkml/2012/9/7/282)
>> could be useful to map the L3RAM on Davinci.
>> With the gen_pool lookup patch (https://lkml.org/lkml/2012/9/7/284) the
>> uio_pruss driver could then use the gen_pool_find_by_phys() (or
>> of_get_named_gen_pool() for initialization from device tree) to
>> retrieve the struct gen_pool*.
>>
>> This way you could avoid handing it over via platform data and you could
>> get rid of arch/arm/mach-davinci/{sram.c,include/mach/sram.h} completely.
>
> I did miss the gen_pool_find_by_phys() call in that series. That does
> look useful. I actually mentioned your series in an earlier posting
> since I like it, but since the initialization of the driver was inherently
> tied to DT it's not usable for DaVinci that's just starting to convert
> to DT and needs !DT support as well.
>
> I do see it moving to your driver exclusively, but I wanted to make this
> series focused on only getting rid of the private SRAM API using the
> existing pdata framework that's already there. I think once
> gen_pool_find_by_phys() goes upstream we can switch to that and get the
> address from a resource in the !DT case. I guess we should see if Sekhar
> would like to see this happen in two steps or just have us depend on
> the gen_pool_find_by_phys() patch now.
I prefer going with this series now and switching to the SRAM driver
once it is available mainline.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v3 2/6] ARM: davinci: da850-dm646x: remove the SRAM_VIRT iotable entry
From: Matt Porter @ 2012-10-04 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506D78BE.1000607@ti.com>
On Thu, Oct 04, 2012 at 05:23:34PM +0530, Sekhar Nori wrote:
> On 10/3/2012 8:25 PM, Matt Porter wrote:
> > From: Ben Gardiner <bengardiner@nanometrics.ca>
> >
> > The sram regions defined for da850-dm646x in their iotable entries are also
> > defined in their davinci_soc_info's.
> >
> > Remove this duplicate information which is now uneccessary since sram
> > init will ioremap the regions defined by their davinci_soc_info's.
> >
> > Since this removal completely removes all uses of SRAM_VIRT, also remove
> > the SRAM_VIRT definition.
> >
> > Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
> > Tested-by: Matt Porter <mporter@ti.com>
>
> What testing was done with this patch? Can you please add that
> information to the commit text as well.
I have only tested on AM180x with uio_pruss and davinci-pcm (series
for that posted a short while ago). In the uio_pruss case, I run the
sample applications from the userspace PRU package that test
communication with the shared SRAM, DDR, and internal PRU SRAM. For
davinci-pcm, my series enables shared SRAM ping-pong buffering which is
working comparably to pcm capture/playback without ping-pong buffering
enabled on AM180x.
I have not tested PM at all...yet.
I'll add this detail to the commit.
-Matt
^ permalink raw reply
* [PATCH v3 1/6] ARM: davinci: sram: ioremap the davinci_soc_info specified sram regions
From: Matt Porter @ 2012-10-04 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506D7799.2090307@ti.com>
On Thu, Oct 04, 2012 at 05:18:41PM +0530, Sekhar Nori wrote:
> On 10/3/2012 8:25 PM, Matt Porter wrote:
> > From: Ben Gardiner <bengardiner@nanometrics.ca>
> >
> > The current davinci init sets up SRAM in iotables. There has been an observed
> > failure to boot a da850 with 128K specified in the iotable.
> >
> > Make the davinci sram allocator -- now based on RMK's consolidated SRAM
> > support -- do an ioremap of the region specified by the entries in
>
> The part about being based on RMK's consolidated SRAM support should be
> dropped.
Ok, cruft from trying to preserve Ben's original patch comments. Will
remove.
> > davinci_soc_info before registering with gen_pool_add_virt().
> >
> > This commit breaks runtime of davinci boards since the regions that
> > the sram init is now trying to ioremap have been iomapped by their
> > iotable entries. The iotable entries will be removed in the patches
> > to come.
>
> I would prefer merging 2/6 into this for this reason.
Ok, makes sense. This again comes from me trying to just use the
original patches. I'll squash these together for v4.
>
> >
> > Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
> > [rebased to mainline as the consolidated SRAM support was dropped]
> > Signed-off-by: Matt Porter <mporter@ti.com>
> > ---
> > arch/arm/mach-davinci/sram.c | 17 ++++++++++++++---
> > 1 file changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
> > index db0f778..0e8ca4f 100644
> > --- a/arch/arm/mach-davinci/sram.c
> > +++ b/arch/arm/mach-davinci/sram.c
> > @@ -10,6 +10,7 @@
> > */
> > #include <linux/module.h>
> > #include <linux/init.h>
> > +#include <linux/io.h>
> > #include <linux/genalloc.h>
> >
> > #include <mach/common.h>
> > @@ -32,7 +33,7 @@ void *sram_alloc(size_t len, dma_addr_t *dma)
> > return NULL;
> >
> > if (dma)
> > - *dma = dma_base + (vaddr - SRAM_VIRT);
> > + *dma = gen_pool_virt_to_phys(sram_pool, vaddr);
> > return (void *)vaddr;
> >
> > }
> > @@ -53,8 +54,10 @@ EXPORT_SYMBOL(sram_free);
> > */
> > static int __init sram_init(void)
> > {
> > + phys_addr_t phys = davinci_soc_info.sram_dma;
> > unsigned len = davinci_soc_info.sram_len;
> > int status = 0;
> > + void *addr;
> >
> > if (len) {
> > len = min_t(unsigned, len, SRAM_SIZE);
> > @@ -62,8 +65,16 @@ static int __init sram_init(void)
> > if (!sram_pool)
> > status = -ENOMEM;
> > }
> > - if (sram_pool)
> > - status = gen_pool_add(sram_pool, SRAM_VIRT, len, -1);
> > +
> > + if (sram_pool) {
> > + addr = ioremap(phys, len);
> > + if (!addr)
> > + return -ENOMEM;
> > + if((status = gen_pool_add_virt(sram_pool, (unsigned)addr,
> > + phys, len, -1)))
>
> Nit: prefer to set status outside of if().
Ok. Will change.
>
> Looks good otherwise. Thanks for reviving this.
No problem, I'm just glad we seem to have a workable solution now.
Also, if you could check the conversation with Phillip about
gen_pool_find_by_phys(), I wonder what you think about depending on that
now, or waiting to convert to it when it goes upstream.
I'm torn as I see all the pdata going away anyway when Davinci is fully
converted to DT, and then also any use of find_by_phys() would go away
in favor of using the of helpers with his driver.
-Matt
^ permalink raw reply
* [PATCH] ARM: ux500: 8500: register LCD VSI pinctrl table
From: Linus Walleij @ 2012-10-04 12:46 UTC (permalink / raw)
To: linux-arm-kernel
From: Patrice Chotard <patrice.chotard@stericsson.com>
This fixes up the pins used by the VSI interface to the HDMI
AV8100 encoder.
Signed-off-by: Patrice Chotard <patrice.chotard@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/mach-ux500/board-mop500-pins.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-ux500/board-mop500-pins.c b/arch/arm/mach-ux500/board-mop500-pins.c
index a267c6d..8ab8688 100644
--- a/arch/arm/mach-ux500/board-mop500-pins.c
+++ b/arch/arm/mach-ux500/board-mop500-pins.c
@@ -162,7 +162,10 @@ static struct pinctrl_map __initdata mop500_family_pinmap[] = {
DB8500_MUX("lcd_d8_d11_a_1", "lcd", "mcde-tvout"),
DB8500_MUX("lcdaclk_b_1", "lcda", "mcde-tvout"),
/* Mux in LCD VSI1 and pull it up for MCDE HDMI output */
- DB8500_MUX("lcdvsi1_a_1", "lcd", "av8100-hdmi"),
+ DB8500_MUX("lcdvsi1_a_1", "lcd", "0-0070"),
+ DB8500_PIN("GPIO69_E2", in_pu, "0-0070"),
+ /* LCD VSI1 sleep state */
+ DB8500_PIN_SLEEP("GPIO69_E2", slpm_in_wkup_pdis, "0-0070"),
/* Mux in i2c0 block, default state */
DB8500_MUX("i2c0_a_1", "i2c0", "nmk-i2c.0"),
/* i2c0 sleep state */
--
1.7.11.3
^ permalink raw reply related
* [PATCH] serial: i.MX: evaluate linux,stdout-path property
From: Rob Herring @ 2012-10-04 12:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349347191-7406-1-git-send-email-s.hauer@pengutronix.de>
On 10/04/2012 05:39 AM, Sascha Hauer wrote:
> devicetrees may have the linux,stdout-path property to specify the
> console. This patch adds support to the i.MX serial driver for this.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
>
> I was originally looking for a more generic way to handle this, but
> since a struct console has no device associated to it, it's not
> possible to match a console with a device in a generic way. So we
Could we add a device ptr to struct console?
> just call add_preferred_console from the driver and let it go down
> to a string matching in the console code.
> If anyone has a better idea how to handle this, please let me know.
> Otherwise I'm happy to see this patch applied aswell.
>
> Thanks
> Sascha
>
> drivers/tty/serial/imx.c | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index e309e8b..b52c4a7 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -1397,6 +1397,32 @@ static int serial_imx_resume(struct platform_device *dev)
>
> #ifdef CONFIG_OF
> /*
> + * Check if this device matches the linux,stdout-path property
> + * in the chosen node. return true if yes, false otherwise
> + */
> +static int serial_imx_is_stdoutpath(struct platform_device *pdev)
Couldn't this function be generic? Just move
IS_ENABLED(CONFIG_SERIAL_IMX_CONSOLE) outside this function. Arguably,
the presence of the property or not could replace the config option all
together.
And use a struct device so this can work with devices other than
platform devices (i.e. amba).
Rob
> +{
> + struct device_node *dn;
> + const char *name;
> +
> + if (!IS_ENABLED(CONFIG_SERIAL_IMX_CONSOLE))
> + return 0;
> +
> + name = of_get_property(of_chosen, "linux,stdout-path", NULL);
> + if (name == NULL)
> + return 0;
> +
> + dn = of_find_node_by_path(name);
> + if (!dn)
> + return 0;
> +
> + if (dn == pdev->dev.of_node)
> + return 1;
> +
> + return 0;
> +}
> +
> +/*
> * This function returns 1 iff pdev isn't a device instatiated by dt, 0 iff it
> * could successfully get all information from dt or a negative errno.
> */
> @@ -1427,6 +1453,9 @@ static int serial_imx_probe_dt(struct imx_port *sport,
>
> sport->devdata = of_id->data;
>
> + if (serial_imx_is_stdoutpath(pdev))
> + add_preferred_console(imx_reg.cons->name, sport->port.line, 0);
> +
> return 0;
> }
> #else
>
^ permalink raw reply
* [PATCH v3 0/6] uio_pruss cleanup and platform support
From: Matt Porter @ 2012-10-04 12:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121004091145.GA3317@pengutronix.de>
On Thu, Oct 04, 2012 at 11:11:45AM +0200, Philipp Zabel wrote:
> Hi Matt,
>
> On 10/3/12, Matt Porter <mporter@ti.com> wrote:
> > This series enables uio_pruss on DA850 and removes use of the
> > private SRAM API by the driver. The driver previously was not
> > enabled by any platform and the private SRAM API was accessing
> > an invalid SRAM bank.
>
> have you seen my SRAM patch series at https://lkml.org/lkml/2012/9/7/281
> "Add device tree support for on-chip SRAM" ?
Yes.
> I think the generic SRAM/genalloc driver (https://lkml.org/lkml/2012/9/7/282)
> could be useful to map the L3RAM on Davinci.
> With the gen_pool lookup patch (https://lkml.org/lkml/2012/9/7/284) the
> uio_pruss driver could then use the gen_pool_find_by_phys() (or
> of_get_named_gen_pool() for initialization from device tree) to
> retrieve the struct gen_pool*.
>
> This way you could avoid handing it over via platform data and you could
> get rid of arch/arm/mach-davinci/{sram.c,include/mach/sram.h} completely.
I did miss the gen_pool_find_by_phys() call in that series. That does
look useful. I actually mentioned your series in an earlier posting
since I like it, but since the initialization of the driver was inherently
tied to DT it's not usable for DaVinci that's just starting to convert
to DT and needs !DT support as well.
I do see it moving to your driver exclusively, but I wanted to make this
series focused on only getting rid of the private SRAM API using the
existing pdata framework that's already there. I think once
gen_pool_find_by_phys() goes upstream we can switch to that and get the
address from a resource in the !DT case. I guess we should see if Sekhar
would like to see this happen in two steps or just have us depend on
the gen_pool_find_by_phys() patch now.
BTW, I was going to post a patch for your driver to allow
configurability of the allocation order, but have been busy with other
things. We'll eventually need that when switching to it as the
hardcoded page size order isn't going to work for all cases.
-Matt
^ permalink raw reply
* [PATCH 03/12] mmc: dw_mmc: fix building exynos driver as a module
From: Seungwon Jeon @ 2012-10-04 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFbHwiRGnhEf-3XJJJPrHwmQRj_YE2kCZaGURHDQcu=cj0zSHw@mail.gmail.com>
Monday, October 01, 2012, Will Newton <will.newton@gmail.com> wrote:
> On Fri, Sep 28, 2012 at 10:36 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > The MODULE_DEVICE_TABLE() entry in the dw_mmc_exynos driver
> > points to the wrong symbol which results in a link error
> > when building as a loadable module.
> >
> > Further, we get a warning about the driver_data being
> > marked constant, which requires annotating a few pointers
> > as const.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Chris Ball <cjb@laptop.org>
> > Cc: Thomas Abraham <thomas.abraham@linaro.org>
> > Cc: Will Newton <will.newton@imgtec.com>
> > Cc: Jaehoon Chung <jh80.chung@samsung.com>
> > Cc: Seungwon Jeon <tgih.jun@samsung.com>
> > Cc: Kyungmin Park <kyungmin.park@samsung.com>
> > Cc: linux-mmc at vger.kernel.org
> > ---
> > drivers/mmc/host/dw_mmc-exynos.c | 4 ++--
> > drivers/mmc/host/dw_mmc-pltfm.c | 2 +-
> > drivers/mmc/host/dw_mmc-pltfm.h | 2 +-
> > drivers/mmc/host/dw_mmc.c | 2 +-
> > include/linux/mmc/dw_mmc.h | 2 +-
> > 5 files changed, 6 insertions(+), 6 deletions(-)
>
> This looks ok to me, but I'll let one of the Exynos guys ack those
> specific changes as I don't have the hardware.
>
> There's already a patch for the dev_info warning in dw_mmc.c frm
> Seungwon Jeon, and it seems to me like a separate change but I don't
> really mind how it gets merged.
Looks good to me.
I don't mind it about including 'dev_info warning'.
Acked-by: Seungwon Jeon<tgih.jun@samsung.com>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3 5/6] ARM: davinci: Add support for PRUSS on DA850
From: Sekhar Nori @ 2012-10-04 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349276133-26408-6-git-send-email-mporter@ti.com>
On 10/3/2012 8:25 PM, Matt Porter wrote:
> Adds PRUSS clock, registers the L3RAM pool, and registers the
> platform device for uio_pruss on DA850.
>
> Signed-off-by: Matt Porter <mporter@ti.com>
I am interested in knowing how this patch was tested.
> ---
> arch/arm/mach-davinci/board-da850-evm.c | 12 +++++
> arch/arm/mach-davinci/da850.c | 7 +++
> arch/arm/mach-davinci/devices-da8xx.c | 66 ++++++++++++++++++++++++++++
> arch/arm/mach-davinci/include/mach/da8xx.h | 2 +
> 4 files changed, 87 insertions(+)
>
> diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
> index 1295e61..acc6e84 100644
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> @@ -29,6 +29,7 @@
> #include <linux/regulator/machine.h>
> #include <linux/regulator/tps6507x.h>
> #include <linux/input/tps6507x-ts.h>
> +#include <linux/platform_data/uio_pruss.h>
> #include <linux/spi/spi.h>
> #include <linux/spi/flash.h>
> #include <linux/delay.h>
> @@ -42,6 +43,7 @@
> #include <mach/da8xx.h>
> #include <linux/platform_data/mtd-davinci.h>
> #include <mach/mux.h>
> +#include <mach/sram.h>
> #include <linux/platform_data/mtd-davinci-aemif.h>
> #include <linux/platform_data/spi-davinci.h>
I know you did not introduce the mess, but can you include a patch to
fix the mixture of mach/ and linux/ includes here? mach/ includes should
follow the linux/ includes.
>
> @@ -1253,6 +1255,10 @@ static __init int da850_wl12xx_init(void)
>
> #endif /* CONFIG_DA850_WL12XX */
>
> +struct uio_pruss_pdata da8xx_pruss_uio_pdata = {
> + .pintc_base = 0x4000,
> +};
> +
> #define DA850EVM_SATA_REFCLKPN_RATE (100 * 1000 * 1000)
>
> static __init void da850_evm_init(void)
> @@ -1339,6 +1345,12 @@ static __init void da850_evm_init(void)
> pr_warning("da850_evm_init: lcdcntl mux setup failed: %d\n",
> ret);
>
> + da8xx_pruss_uio_pdata.l3ram_pool = sram_get_gen_pool();
I wonder if this platform data should still be called l3ram pool. L3RAM
is OMAP terminology. May be just call it sram_pool? Also this patch
should follow 6/6 to prevent build breakage.
> + ret = da8xx_register_pruss_uio(&da8xx_pruss_uio_pdata);
> + if (ret)
> + pr_warning("pruss_uio initialization failed: %d\n",
> + ret);
> +
> /* Handle board specific muxing for LCD here */
> ret = davinci_cfg_reg_list(da850_evm_lcdc_pins);
> if (ret)
> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index d8d69de..7c01d31 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
Can you separate out board and SoC changes into different patches?
> @@ -212,6 +212,12 @@ static struct clk tptc2_clk = {
> .flags = ALWAYS_ENABLED,
> };
>
> +static struct clk pruss_clk = {
> + .name = "pruss",
> + .parent = &pll0_sysclk2,
> + .lpsc = DA8XX_LPSC0_PRUSS,
> +};
> +
> static struct clk uart0_clk = {
> .name = "uart0",
> .parent = &pll0_sysclk2,
> @@ -378,6 +384,7 @@ static struct clk_lookup da850_clks[] = {
> CLK(NULL, "tptc1", &tptc1_clk),
> CLK(NULL, "tpcc1", &tpcc1_clk),
> CLK(NULL, "tptc2", &tptc2_clk),
> + CLK(NULL, "pruss", &pruss_clk),
This is actually incorrect since we should use device name rather than
con_id for matching the clock. If there is just one clock that the
driver needs, connection id should be NULL. Looking at the driver now,
the clk_get() call seems to pass a valid device pointer. So, I wonder
how you are able to look up the clock even with a NULL device name.
> CLK(NULL, "uart0", &uart0_clk),
> CLK(NULL, "uart1", &uart1_clk),
> CLK(NULL, "uart2", &uart2_clk),
> diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
> index bd2f72b..7c2e0d2 100644
> --- a/arch/arm/mach-davinci/devices-da8xx.c
> +++ b/arch/arm/mach-davinci/devices-da8xx.c
> @@ -518,6 +518,72 @@ void __init da8xx_register_mcasp(int id, struct snd_platform_data *pdata)
> }
> }
>
> +#define DA8XX_PRUSS_MEM_BASE 0x01C30000
In this file all base addresses are added at the top of the file. The
defines are sorted in ascending order of address. If that's broken, its
all my fault, but please don't add to the breakage when adding this entry :)
> +
> +static struct resource da8xx_pruss_resources[] = {
> + {
> + .start = DA8XX_PRUSS_MEM_BASE,
> + .end = DA8XX_PRUSS_MEM_BASE + 0xFFFF,
> + .flags = IORESOURCE_MEM,
> + },
> + {
> + .start = IRQ_DA8XX_EVTOUT0,
> + .end = IRQ_DA8XX_EVTOUT0,
> + .flags = IORESOURCE_IRQ,
> + },
> + {
> + .start = IRQ_DA8XX_EVTOUT1,
> + .end = IRQ_DA8XX_EVTOUT1,
> + .flags = IORESOURCE_IRQ,
> + },
> + {
> + .start = IRQ_DA8XX_EVTOUT2,
> + .end = IRQ_DA8XX_EVTOUT2,
> + .flags = IORESOURCE_IRQ,
> + },
> + {
> + .start = IRQ_DA8XX_EVTOUT3,
> + .end = IRQ_DA8XX_EVTOUT3,
> + .flags = IORESOURCE_IRQ,
> + },
> + {
> + .start = IRQ_DA8XX_EVTOUT4,
> + .end = IRQ_DA8XX_EVTOUT4,
> + .flags = IORESOURCE_IRQ,
> + },
> + {
> + .start = IRQ_DA8XX_EVTOUT5,
> + .end = IRQ_DA8XX_EVTOUT5,
> + .flags = IORESOURCE_IRQ,
> + },
> + {
> + .start = IRQ_DA8XX_EVTOUT6,
> + .end = IRQ_DA8XX_EVTOUT6,
> + .flags = IORESOURCE_IRQ,
> + },
> + {
> + .start = IRQ_DA8XX_EVTOUT7,
> + .end = IRQ_DA8XX_EVTOUT7,
> + .flags = IORESOURCE_IRQ,
> + },
> +};
> +
> +static struct platform_device da8xx_pruss_uio_dev = {
> + .name = "pruss_uio",
> + .id = -1,
> + .num_resources = ARRAY_SIZE(da8xx_pruss_resources),
> + .resource = da8xx_pruss_resources,
> + .dev = {
> + .coherent_dma_mask = 0xffffffff,
DMA_BIT_MASK(32)?
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 3/4] ARM: OMAP2: gpmc: Add support for BCH ECC scheme
From: Ivan Djelic @ 2012-10-04 12:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <518397C60809E147AF5323E0420B992E3E9B4902@DBDE01.ent.ti.com>
On Thu, Oct 04, 2012 at 09:03:42AM +0100, Philip, Avinash wrote:
(...)
> > > +int gpmc_calculate_ecc_bch(int cs, const u_char *dat, u_char *ecc)
> > > +{
> > > + int i, eccbchtsel;
> > > + u32 nsectors, reg, bch_val1, bch_val2, bch_val3, bch_val4;
> > > +
> > > + if (gpmc_ecc_used != cs)
> > > + return -EINVAL;
> > > +
> > > + /* read number of sectors for ecc to be calculated */
> > > + nsectors = ((gpmc_read_reg(GPMC_ECC_CONFIG) >> 4) & 0x7) + 1;
> > > + /*
> > > + * find BCH scheme used
> > > + * 0 -> BCH4
> > > + * 1 -> BCH8
> > > + */
> > > + eccbchtsel = ((gpmc_read_reg(GPMC_ECC_CONFIG) >> 12) & 0x3);
> > > +
> > > + /* update ecc bytes for entire page */
> > > + for (i = 0; i < nsectors; i++) {
> > > +
> > > + reg = GPMC_ECC_BCH_RESULT_0 + 16 * i;
> > > +
> > > + /* Read hw-computed remainder */
> > > + bch_val1 = gpmc_read_reg(reg + 0);
> > > + bch_val2 = gpmc_read_reg(reg + 4);
> > > + if (eccbchtsel) {
> > > + bch_val3 = gpmc_read_reg(reg + 8);
> > > + bch_val4 = gpmc_read_reg(reg + 12);
> > > + }
> > > +
> > > + if (eccbchtsel) {
> > > + /* BCH8 ecc scheme */
> > > + *ecc++ = (bch_val4 & 0xFF);
> > > + *ecc++ = ((bch_val3 >> 24) & 0xFF);
> > > + *ecc++ = ((bch_val3 >> 16) & 0xFF);
> > > + *ecc++ = ((bch_val3 >> 8) & 0xFF);
> > > + *ecc++ = (bch_val3 & 0xFF);
> > > + *ecc++ = ((bch_val2 >> 24) & 0xFF);
> > > + *ecc++ = ((bch_val2 >> 16) & 0xFF);
> > > + *ecc++ = ((bch_val2 >> 8) & 0xFF);
> > > + *ecc++ = (bch_val2 & 0xFF);
> > > + *ecc++ = ((bch_val1 >> 24) & 0xFF);
> > > + *ecc++ = ((bch_val1 >> 16) & 0xFF);
> > > + *ecc++ = ((bch_val1 >> 8) & 0xFF);
> > > + *ecc++ = (bch_val1 & 0xFF);
> > > + /* 14th byte of ecc not used */
> > > + *ecc++ = 0;
> > > + } else {
> > > + /* BCH4 ecc scheme */
> > > + *ecc++ = ((bch_val2 >> 12) & 0xFF);
> > > + *ecc++ = ((bch_val2 >> 4) & 0xFF);
> > > + *ecc++ = (((bch_val2 & 0xF) << 4) |
> > > + ((bch_val1 >> 28) & 0xF));
> > > + *ecc++ = ((bch_val1 >> 20) & 0xFF);
> > > + *ecc++ = ((bch_val1 >> 12) & 0xFF);
> > > + *ecc++ = ((bch_val1 >> 4) & 0xFF);
> > > + *ecc++ = ((bch_val1 & 0xF) << 4);
> > > + }
> > > + }
> > > +
> > > + gpmc_ecc_used = -EINVAL;
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL_GPL(gpmc_calculate_ecc_bch);
> >
> > Here you introduce a function very similar to gpmc_calculate_ecc_bch4 and
> > gpmc_calculate_ecc_bch8, but without the added benefit (IMHO) of the constant
> > polynomial that allows to get an ecc sequence of 0xFFs for a buffer filled with
> > 0xFFs. Why ?
>
> I don't exactly understand what we benefitted/achieve. In my observation,
> this API does spare area also written with 0xFF if data area is 0xFFs.
> So the area looks like erased page again.
Precisely. It means you can read the page with ECC enabled without having to check if
the page has been programmed; it also enables bitflip correction on erased pages.
> > If using the ELM prevents you from reusing gpmc_calculate_ecc_bch[48], could you explain in which way ?
>
> When using gpmc_calculate_ecc_bch[48], calculated ecc values modified.
> The read sequence we following is
> Read 512 byte -> read ECC bytes from spare area
> Now the calculated ECC will be zero if no error is reported. In case of error, a syndrome
> Polynomial is reported. In either case modifying will corrupt the data.
It is still possible to retrieve your original error syndrome, even using the technique transforming ECC on erased pages into 0xFFs.
But I guess you're not interested if you need RBL compatibility.
BR,
--
Ivan
^ permalink raw reply
* [PATCH 1/3] mfd: dbx500: Export prmcu_request_ape_opp_100_voltage
From: Ulf Hansson @ 2012-10-04 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348497799-32143-2-git-send-email-ulf.hansson@stericsson.com>
Hi Sam and Linus,
Do you see any issues with this patch? Can we advise Mike to merge it
though his clock tree?
Kind regards
Ulf Hansson
On 24 September 2012 16:43, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
> From: Ulf Hansson <ulf.hansson@linaro.org>
>
> This function needs to be exported to let clients be able to
> request the ape opp 100 voltage.
>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> ---
> drivers/mfd/db8500-prcmu.c | 4 ++--
> include/linux/mfd/db8500-prcmu.h | 4 ++--
> include/linux/mfd/dbx500-prcmu.h | 10 ++++++++++
> 3 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mfd/db8500-prcmu.c b/drivers/mfd/db8500-prcmu.c
> index e7f9539..0b8e0a0 100644
> --- a/drivers/mfd/db8500-prcmu.c
> +++ b/drivers/mfd/db8500-prcmu.c
> @@ -1167,12 +1167,12 @@ int db8500_prcmu_get_ape_opp(void)
> }
>
> /**
> - * prcmu_request_ape_opp_100_voltage - Request APE OPP 100% voltage
> + * db8500_prcmu_request_ape_opp_100_voltage - Request APE OPP 100% voltage
> * @enable: true to request the higher voltage, false to drop a request.
> *
> * Calls to this function to enable and disable requests must be balanced.
> */
> -int prcmu_request_ape_opp_100_voltage(bool enable)
> +int db8500_prcmu_request_ape_opp_100_voltage(bool enable)
> {
> int r = 0;
> u8 header;
> diff --git a/include/linux/mfd/db8500-prcmu.h b/include/linux/mfd/db8500-prcmu.h
> index b82f6ee..6ee4247 100644
> --- a/include/linux/mfd/db8500-prcmu.h
> +++ b/include/linux/mfd/db8500-prcmu.h
> @@ -515,7 +515,6 @@ enum romcode_read prcmu_get_rc_p2a(void);
> enum ap_pwrst prcmu_get_xp70_current_state(void);
> bool prcmu_has_arm_maxopp(void);
> struct prcmu_fw_version *prcmu_get_fw_version(void);
> -int prcmu_request_ape_opp_100_voltage(bool enable);
> int prcmu_release_usb_wakeup_state(void);
> void prcmu_configure_auto_pm(struct prcmu_auto_pm_config *sleep,
> struct prcmu_auto_pm_config *idle);
> @@ -564,6 +563,7 @@ int db8500_prcmu_set_arm_opp(u8 opp);
> int db8500_prcmu_get_arm_opp(void);
> int db8500_prcmu_set_ape_opp(u8 opp);
> int db8500_prcmu_get_ape_opp(void);
> +int db8500_prcmu_request_ape_opp_100_voltage(bool enable);
> int db8500_prcmu_set_ddr_opp(u8 opp);
> int db8500_prcmu_get_ddr_opp(void);
>
> @@ -610,7 +610,7 @@ static inline int db8500_prcmu_get_ape_opp(void)
> return APE_100_OPP;
> }
>
> -static inline int prcmu_request_ape_opp_100_voltage(bool enable)
> +static inline int db8500_prcmu_request_ape_opp_100_voltage(bool enable)
> {
> return 0;
> }
> diff --git a/include/linux/mfd/dbx500-prcmu.h b/include/linux/mfd/dbx500-prcmu.h
> index c410d99..c202d6c 100644
> --- a/include/linux/mfd/dbx500-prcmu.h
> +++ b/include/linux/mfd/dbx500-prcmu.h
> @@ -336,6 +336,11 @@ static inline int prcmu_get_ape_opp(void)
> return db8500_prcmu_get_ape_opp();
> }
>
> +static inline int prcmu_request_ape_opp_100_voltage(bool enable)
> +{
> + return db8500_prcmu_request_ape_opp_100_voltage(enable);
> +}
> +
> static inline void prcmu_system_reset(u16 reset_code)
> {
> return db8500_prcmu_system_reset(reset_code);
> @@ -507,6 +512,11 @@ static inline int prcmu_get_ape_opp(void)
> return APE_100_OPP;
> }
>
> +static inline int prcmu_request_ape_opp_100_voltage(bool enable)
> +{
> + return 0;
> +}
> +
> static inline int prcmu_set_arm_opp(u8 opp)
> {
> return 0;
> --
> 1.7.10
>
^ permalink raw reply
* [PATCH 9/9] ARM/dts: omap5-evm: pinmux configuration for audio
From: Peter Ujfalusi @ 2012-10-04 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349351848-12972-1-git-send-email-peter.ujfalusi@ti.com>
u-boot stopped configuring 'non essential' pins recently. The kernel needs
to configure the mux for audio needs.
Since the pinmux for these IPs are static let pinctrl to handle the mux
configuration for.
Configuring the mux for: twl6040 (audpwron), McPDM, DMIC, McBSP1 and McBSP2.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/omap5-evm.dts | 54 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 825e607..c663eba 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -27,6 +27,60 @@
};
+&omap5_pmx_core {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &twl6040_pins
+ &mcpdm_pins
+ &dmic_pins
+ &mcbsp1_pins
+ &mcbsp2_pins
+ >;
+
+ twl6040_pins: pinmux_twl6040_pins {
+ pinctrl-single,pins = <
+ 0x18a 0x6 /* perslimbus2_clock.gpio5_145 OUTPUT | MODE6 */
+ >;
+ };
+
+ mcpdm_pins: pinmux_mcpdm_pins {
+ pinctrl-single,pins = <
+ 0x142 0x108 /* abe_clks.abe_clks INPUT PULLDOWN | MODE0 */
+ 0x15c 0x108 /* abemcpdm_ul_data.abemcpdm_ul_data INPUT PULLDOWN | MODE0 */
+ 0x15e 0x108 /* abemcpdm_dl_data.abemcpdm_dl_data INPUT PULLDOWN | MODE0 */
+ 0x160 0x118 /* abemcpdm_frame.abemcpdm_frame INPUT PULLUP | MODE0 */
+ 0x162 0x108 /* abemcpdm_lb_clk.abemcpdm_lb_clk INPUT PULLDOWN | MODE0 */
+ >;
+ };
+
+ dmic_pins: pinmux_dmic_pins {
+ pinctrl-single,pins = <
+ 0x144 0x100 /* abedmic_din1.abedmic_din1 INPUT | MODE0 */
+ 0x146 0x100 /* abedmic_din2.abedmic_din2 INPUT | MODE0 */
+ 0x148 0x100 /* abedmic_din3.abedmic_din3 INPUT | MODE0 */
+ 0x14a 0 /* abedmic_clk1.abedmic_clk1 OUTPUT | MODE0 */
+ >;
+ };
+
+ mcbsp1_pins: pinmux_mcbsp1_pins {
+ pinctrl-single,pins = <
+ 0x14c 0x101 /* abedmic_clk2.abemcbsp1_fsx INPUT | MODE1 */
+ 0x14e 0x9 /* abedmic_clk3.abemcbsp1_dx OUTPUT PULLDOWN | MODE1 */
+ 0x150 0x101 /* abeslimbus1_clock.abemcbsp1_clkx INPUT | MODE0 */
+ 0x152 0x109 /* abeslimbus1_data.abemcbsp1_dr INPUT PULLDOWN | MODE1 */
+ >;
+ };
+
+ mcbsp2_pins: pinmux_mcbsp2_pins {
+ pinctrl-single,pins = <
+ 0x154 0x108 /* abemcbsp2_dr.abemcbsp2_dr INPUT PULLDOWN | MODE0 */
+ 0x156 0x8 /* abemcbsp2_dx.abemcbsp2_dx OUTPUT PULLDOWN | MODE0 */
+ 0x158 0x100 /* abemcbsp2_fsx.abemcbsp2_fsx INPUT | MODE0 */
+ 0x15a 0x100 /* abemcbsp2_clkx.abemcbsp2_clkx INPUT | MODE0 */
+ >;
+ };
+};
+
&mmc1 {
vmmc-supply = <&vmmcsd_fixed>;
bus-width = <4>;
--
1.7.12
^ permalink raw reply related
* [PATCH 8/9] ARM/dts: Add pinctrl driver entries for omap5
From: Peter Ujfalusi @ 2012-10-04 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349351848-12972-1-git-send-email-peter.ujfalusi@ti.com>
These all use the generic pinctrl-single driver for the padconf registers.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/omap5.dtsi | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 9ac75b3..00ee987 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -65,6 +65,23 @@
ranges;
ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
+ omap5_pmx_core: pinmux at 4a002840 {
+ compatible = "ti,omap4-padconf", "pinctrl-single";
+ reg = <0x4a002840 0x01b6>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-single,register-width = <16>;
+ pinctrl-single,function-mask = <0x7fff>;
+ };
+ omap5_pmx_wkup: pinmux at 4ae0c840 {
+ compatible = "ti,omap4-padconf", "pinctrl-single";
+ reg = <0x4ae0c840 0x0038>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-single,register-width = <16>;
+ pinctrl-single,function-mask = <0x7fff>;
+ };
+
gic: interrupt-controller at 48211000 {
compatible = "arm,cortex-a15-gic";
interrupt-controller;
--
1.7.12
^ permalink raw reply related
* [PATCH 7/9] ARM/dts: omap4-panda: pinmux configuration for audio
From: Peter Ujfalusi @ 2012-10-04 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349351848-12972-1-git-send-email-peter.ujfalusi@ti.com>
u-boot stopped configuring 'non essential' pins recently. The kernel needs
to configure the mux for audio needs.
Since the pinmux for these IPs are static let pinctrl to handle the mux
configuration for.
Configuring the mux for: twl6040 (audpwron, irq), McPDM and McBSP1.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/omap4-panda.dts | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
index 771cefd..e8f927c 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -59,6 +59,41 @@
};
};
+&omap4_pmx_core {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &twl6040_pins
+ &mcpdm_pins
+ &mcbsp1_pins
+ >;
+
+ twl6040_pins: pinmux_twl6040_pins {
+ pinctrl-single,pins = <
+ 0xe0 0x3 /* hdq_sio.gpio_127 OUTPUT | MODE3 */
+ 0x160 0x100 /* sys_nirq2.sys_nirq2 INPUT | MODE0 */
+ >;
+ };
+
+ mcpdm_pins: pinmux_mcpdm_pins {
+ pinctrl-single,pins = <
+ 0xc6 0x108 /* abe_pdm_ul_data.abe_pdm_ul_data INPUT PULLDOWN | MODE0 */
+ 0xc8 0x108 /* abe_pdm_dl_data.abe_pdm_dl_data INPUT PULLDOWN | MODE0 */
+ 0xca 0x118 /* abe_pdm_frame.abe_pdm_frame INPUT PULLUP | MODE0 */
+ 0xcc 0x108 /* abe_pdm_lb_clk.abe_pdm_lb_clk INPUT PULLDOWN | MODE0 */
+ 0xce 0x108 /* abe_clks.abe_clks INPUT PULLDOWN | MODE0 */
+ >;
+ };
+
+ mcbsp1_pins: pinmux_mcbsp1_pins {
+ pinctrl-single,pins = <
+ 0xbe 0x100 /* abe_mcbsp1_clkx.abe_mcbsp1_clkx INPUT | MODE0 */
+ 0xc0 0x108 /* abe_mcbsp1_dr.abe_mcbsp1_dr INPUT PULLDOWN | MODE0 */
+ 0xc2 0x8 /* abe_mcbsp1_dx.abe_mcbsp1_dx OUTPUT PULLDOWN | MODE0 */
+ 0xc4 0x100 /* abe_mcbsp1_fsx.abe_mcbsp1_fsx INPUT | MODE0 */
+ >;
+ };
+};
+
&i2c1 {
clock-frequency = <400000>;
--
1.7.12
^ permalink raw reply related
* [PATCH 6/9] ARM/dts: omap4-sdp: pinmux configuration for audio
From: Peter Ujfalusi @ 2012-10-04 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349351848-12972-1-git-send-email-peter.ujfalusi@ti.com>
u-boot stopped configuring 'non essential' pins recently. The kernel needs
to configure the mux for audio needs.
Since the pinmux for these IPs are static let pinctrl to handle the mux
configuration for.
Configuring the mux for: twl6040 (audpwron, irq), McPDM, DMIC, McBSP1 and
McBSP2.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/omap4-sdp.dts | 53 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 53 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index cf09875..5b7e04f 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -117,6 +117,15 @@
};
&omap4_pmx_core {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &twl6040_pins
+ &mcpdm_pins
+ &dmic_pins
+ &mcbsp1_pins
+ &mcbsp2_pins
+ >;
+
uart2_pins: pinmux_uart2_pins {
pinctrl-single,pins = <
0xd8 0x118 /* uart2_cts.uart2_cts INPUT_PULLUP | MODE0 */
@@ -141,6 +150,50 @@
0x11e 0 /* uart4_tx.uart4_tx OUTPUT | MODE0 */
>;
};
+
+ twl6040_pins: pinmux_twl6040_pins {
+ pinctrl-single,pins = <
+ 0xe0 0x3 /* hdq_sio.gpio_127 OUTPUT | MODE3 */
+ 0x160 0x100 /* sys_nirq2.sys_nirq2 INPUT | MODE0 */
+ >;
+ };
+
+ mcpdm_pins: pinmux_mcpdm_pins {
+ pinctrl-single,pins = <
+ 0xc6 0x108 /* abe_pdm_ul_data.abe_pdm_ul_data INPUT PULLDOWN | MODE0 */
+ 0xc8 0x108 /* abe_pdm_dl_data.abe_pdm_dl_data INPUT PULLDOWN | MODE0 */
+ 0xca 0x118 /* abe_pdm_frame.abe_pdm_frame INPUT PULLUP | MODE0 */
+ 0xcc 0x108 /* abe_pdm_lb_clk.abe_pdm_lb_clk INPUT PULLDOWN | MODE0 */
+ 0xce 0x108 /* abe_clks.abe_clks INPUT PULLDOWN | MODE0 */
+ >;
+ };
+
+ dmic_pins: pinmux_dmic_pins {
+ pinctrl-single,pins = <
+ 0xd0 0 /* abe_dmic_clk1.abe_dmic_clk1 OUTPUT | MODE0 */
+ 0xd2 0x100 /* abe_dmic_din1.abe_dmic_din1 INPUT | MODE0 */
+ 0xd4 0x100 /* abe_dmic_din2.abe_dmic_din2 INPUT | MODE0 */
+ 0xd6 0x100 /* abe_dmic_din3.abe_dmic_din3 INPUT | MODE0 */
+ >;
+ };
+
+ mcbsp1_pins: pinmux_mcbsp1_pins {
+ pinctrl-single,pins = <
+ 0xbe 0x100 /* abe_mcbsp1_clkx.abe_mcbsp1_clkx INPUT | MODE0 */
+ 0xc0 0x108 /* abe_mcbsp1_dr.abe_mcbsp1_dr INPUT PULLDOWN | MODE0 */
+ 0xc2 0x8 /* abe_mcbsp1_dx.abe_mcbsp1_dx OUTPUT PULLDOWN | MODE0 */
+ 0xc4 0x100 /* abe_mcbsp1_fsx.abe_mcbsp1_fsx INPUT | MODE0 */
+ >;
+ };
+
+ mcbsp2_pins: pinmux_mcbsp2_pins {
+ pinctrl-single,pins = <
+ 0xb6 0x100 /* abe_mcbsp2_clkx.abe_mcbsp2_clkx INPUT | MODE0 */
+ 0xb8 0x108 /* abe_mcbsp2_dr.abe_mcbsp2_dr INPUT PULLDOWN | MODE0 */
+ 0xba 0x8 /* abe_mcbsp2_dx.abe_mcbsp2_dx OUTPUT PULLDOWN | MODE0 */
+ 0xbc 0x100 /* abe_mcbsp2_fsx.abe_mcbsp2_fsx INPUT | MODE0 */
+ >;
+ };
};
&i2c1 {
--
1.7.12
^ permalink raw reply related
* [PATCH 5/9] ARM/dts: omap5-evm: Disable unused McBSP3
From: Peter Ujfalusi @ 2012-10-04 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349351848-12972-1-git-send-email-peter.ujfalusi@ti.com>
McBSP3 is not usable on OMAP4 SDP/Blaze (the pins used for McPDM).
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/omap5-evm.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 9c41a3f..825e607 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -82,3 +82,7 @@
0x020700d9>; /* SEARCH */
linux,input-no-autorepeat;
};
+
+&mcbsp3 {
+ status = "disabled";
+};
--
1.7.12
^ permalink raw reply related
* [PATCH v3 3/6] ARM: davinci: da850: changed SRAM allocator to shared ram.
From: Sekhar Nori @ 2012-10-04 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349276133-26408-4-git-send-email-mporter@ti.com>
Matt,
On 10/3/2012 8:25 PM, Matt Porter wrote:
> From: Subhasish Ghosh <subhasish@mistralsolutions.com>
>
> This patch modifies the sram allocator to allocate memory
> from the DA8XX shared RAM.
>
> Signed-off-by: Subhasish Ghosh <subhasish@mistralsolutions.com>
> [rebased onto consolidated SRAM patches]
> Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
> [rebased to mainline as consolidated SRAM patches were dropped]
> Signed-off-by: Matt Porter <mporter@ti.com>
Were you able to test PM with this change or you need my help?
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 4/9] ARM/dts: omap4-sdp: Disable unused McBSP3
From: Peter Ujfalusi @ 2012-10-04 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349351848-12972-1-git-send-email-peter.ujfalusi@ti.com>
McBSP3 is not usable on OMAP4 SDP/Blaze (the pins used for McPDM).
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/omap4-sdp.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 94a23b3..cf09875 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -349,3 +349,7 @@
pinctrl-names = "default";
pinctrl-0 = <&uart4_pins>;
};
+
+&mcbsp3 {
+ status = "disabled";
+};
--
1.7.12
^ permalink raw reply related
* [PATCH 3/9] ARM/dts: omap4-panda: Disable unused audio IPs
From: Peter Ujfalusi @ 2012-10-04 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349351848-12972-1-git-send-email-peter.ujfalusi@ti.com>
McBSP2, McBSP3 and DMIC is not usable on PandaBoard (not connected, no
external pins provided for them).
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/boot/dts/omap4-panda.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda.dts b/arch/arm/boot/dts/omap4-panda.dts
index 20b966e..771cefd 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -137,3 +137,15 @@
cs1-used;
device-handle = <&elpida_ECB240ABACN>;
};
+
+&mcbsp2 {
+ status = "disabled";
+};
+
+&mcbsp3 {
+ status = "disabled";
+};
+
+&dmic {
+ status = "disabled";
+};
--
1.7.12
^ permalink raw reply related
* [PATCH 2/9] ARM: OMAP: board-omap4panda: Pin mux configuration for audio needs
From: Peter Ujfalusi @ 2012-10-04 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349351848-12972-1-git-send-email-peter.ujfalusi@ti.com>
u-boot stopped configuring 'non essential' pins recently. These pins are
essential for audio and need to be done to have working audio on the board.
Pin Mux configuration for: twl6040 audpwron gpio, McPDM, and McBSP1.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/mach-omap2/board-omap4panda.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index 57d217a..51d08fc 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -380,6 +380,21 @@ static struct omap_board_mux board_mux[] __initdata = {
/* NIRQ2 for twl6040 */
OMAP4_MUX(SYS_NIRQ2, OMAP_MUX_MODE0 |
OMAP_PIN_INPUT_PULLUP | OMAP_PIN_OFF_WAKEUPENABLE),
+ /* GPIO_127 for twl6040 */
+ OMAP4_MUX(HDQ_SIO, OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT),
+ /* McPDM */
+ OMAP4_MUX(ABE_PDM_UL_DATA, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
+ OMAP4_MUX(ABE_PDM_DL_DATA, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
+ OMAP4_MUX(ABE_PDM_FRAME, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP4_MUX(ABE_PDM_LB_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
+ OMAP4_MUX(ABE_CLKS, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
+ /* McBSP1 */
+ OMAP4_MUX(ABE_MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP4_MUX(ABE_MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
+ OMAP4_MUX(ABE_MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT |
+ OMAP_PULL_ENA),
+ OMAP4_MUX(ABE_MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
--
1.7.12
^ permalink raw reply related
* [PATCH 1/9] ARM: OMAP: board-4430-sdp: Pin mux configuration for audio needs
From: Peter Ujfalusi @ 2012-10-04 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349351848-12972-1-git-send-email-peter.ujfalusi@ti.com>
u-boot stopped configuring 'non essential' pins recently. These pins are
essential for audio and need to be done to have working audio on the board.
Pin Mux configuration for: twl6040 audpwron gpio, McPDM, DMIC, McBSP1 and
McBSP2.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
arch/arm/mach-omap2/board-4430sdp.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 09644af..41a9b01 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -753,6 +753,32 @@ static struct omap_board_mux board_mux[] __initdata = {
/* NIRQ2 for twl6040 */
OMAP4_MUX(SYS_NIRQ2, OMAP_MUX_MODE0 |
OMAP_PIN_INPUT_PULLUP | OMAP_PIN_OFF_WAKEUPENABLE),
+ /* GPIO_127 for twl6040 */
+ OMAP4_MUX(HDQ_SIO, OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT),
+ /* McPDM */
+ OMAP4_MUX(ABE_PDM_UL_DATA, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
+ OMAP4_MUX(ABE_PDM_DL_DATA, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
+ OMAP4_MUX(ABE_PDM_FRAME, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP4_MUX(ABE_PDM_LB_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
+ OMAP4_MUX(ABE_CLKS, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
+ /* DMIC */
+ OMAP4_MUX(ABE_DMIC_CLK1, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP4_MUX(ABE_DMIC_DIN1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP4_MUX(ABE_DMIC_DIN2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP4_MUX(ABE_DMIC_DIN3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ /* McBSP1 */
+ OMAP4_MUX(ABE_MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP4_MUX(ABE_MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
+ OMAP4_MUX(ABE_MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT |
+ OMAP_PULL_ENA),
+ OMAP4_MUX(ABE_MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ /* McBSP2 */
+ OMAP4_MUX(ABE_MCBSP2_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP4_MUX(ABE_MCBSP2_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
+ OMAP4_MUX(ABE_MCBSP2_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT |
+ OMAP_PULL_ENA),
+ OMAP4_MUX(ABE_MCBSP2_FSX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
--
1.7.12
^ permalink raw reply related
* [PATCH 0/9] ARM: dts/OMAP: Pinmux audio configuration for OMAP4+
From: Peter Ujfalusi @ 2012-10-04 11:57 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
u-boot recently stopped configuring 'non essential' pin mux. This change leaves
the audio essential pins in non configured state which prevents the use of audio.
The following series makes sure that the needed pins are configured correctly by
the kernel on OMAP4 and OMAP5.
Tony: can this series queued for 3.7?
Regards,
Peter
---
Peter Ujfalusi (9):
ARM: OMAP: board-4430-sdp: Pin mux configuration for audio needs
ARM: OMAP: board-omap4panda: Pin mux configuration for audio needs
ARM/dts: omap4-panda: Disable unused audio IPs
ARM/dts: omap4-sdp: Disable unused McBSP3
ARM/dts: omap5-evm: Disable unused McBSP3
ARM/dts: omap4-sdp: pinmux configuration for audio
ARM/dts: omap4-panda: pinmux configuration for audio
ARM/dts: Add pinctrl driver entries for omap5
ARM/dts: omap5-evm: pinmux configuration for audio
arch/arm/boot/dts/omap4-panda.dts | 47 +++++++++++++++++++++++++++
arch/arm/boot/dts/omap4-sdp.dts | 57 +++++++++++++++++++++++++++++++++
arch/arm/boot/dts/omap5-evm.dts | 58 ++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/omap5.dtsi | 17 ++++++++++
arch/arm/mach-omap2/board-4430sdp.c | 26 +++++++++++++++
arch/arm/mach-omap2/board-omap4panda.c | 15 +++++++++
6 files changed, 220 insertions(+)
--
1.7.12
^ permalink raw reply
* [PATCH v3 2/6] ARM: davinci: da850-dm646x: remove the SRAM_VIRT iotable entry
From: Sekhar Nori @ 2012-10-04 11:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349276133-26408-3-git-send-email-mporter@ti.com>
On 10/3/2012 8:25 PM, Matt Porter wrote:
> From: Ben Gardiner <bengardiner@nanometrics.ca>
>
> The sram regions defined for da850-dm646x in their iotable entries are also
> defined in their davinci_soc_info's.
>
> Remove this duplicate information which is now uneccessary since sram
> init will ioremap the regions defined by their davinci_soc_info's.
>
> Since this removal completely removes all uses of SRAM_VIRT, also remove
> the SRAM_VIRT definition.
>
> Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
> Tested-by: Matt Porter <mporter@ti.com>
What testing was done with this patch? Can you please add that
information to the commit text as well.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v3 1/6] ARM: davinci: sram: ioremap the davinci_soc_info specified sram regions
From: Sekhar Nori @ 2012-10-04 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349276133-26408-2-git-send-email-mporter@ti.com>
On 10/3/2012 8:25 PM, Matt Porter wrote:
> From: Ben Gardiner <bengardiner@nanometrics.ca>
>
> The current davinci init sets up SRAM in iotables. There has been an observed
> failure to boot a da850 with 128K specified in the iotable.
>
> Make the davinci sram allocator -- now based on RMK's consolidated SRAM
> support -- do an ioremap of the region specified by the entries in
The part about being based on RMK's consolidated SRAM support should be
dropped.
> davinci_soc_info before registering with gen_pool_add_virt().
>
> This commit breaks runtime of davinci boards since the regions that
> the sram init is now trying to ioremap have been iomapped by their
> iotable entries. The iotable entries will be removed in the patches
> to come.
I would prefer merging 2/6 into this for this reason.
>
> Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
> [rebased to mainline as the consolidated SRAM support was dropped]
> Signed-off-by: Matt Porter <mporter@ti.com>
> ---
> arch/arm/mach-davinci/sram.c | 17 ++++++++++++++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/sram.c b/arch/arm/mach-davinci/sram.c
> index db0f778..0e8ca4f 100644
> --- a/arch/arm/mach-davinci/sram.c
> +++ b/arch/arm/mach-davinci/sram.c
> @@ -10,6 +10,7 @@
> */
> #include <linux/module.h>
> #include <linux/init.h>
> +#include <linux/io.h>
> #include <linux/genalloc.h>
>
> #include <mach/common.h>
> @@ -32,7 +33,7 @@ void *sram_alloc(size_t len, dma_addr_t *dma)
> return NULL;
>
> if (dma)
> - *dma = dma_base + (vaddr - SRAM_VIRT);
> + *dma = gen_pool_virt_to_phys(sram_pool, vaddr);
> return (void *)vaddr;
>
> }
> @@ -53,8 +54,10 @@ EXPORT_SYMBOL(sram_free);
> */
> static int __init sram_init(void)
> {
> + phys_addr_t phys = davinci_soc_info.sram_dma;
> unsigned len = davinci_soc_info.sram_len;
> int status = 0;
> + void *addr;
>
> if (len) {
> len = min_t(unsigned, len, SRAM_SIZE);
> @@ -62,8 +65,16 @@ static int __init sram_init(void)
> if (!sram_pool)
> status = -ENOMEM;
> }
> - if (sram_pool)
> - status = gen_pool_add(sram_pool, SRAM_VIRT, len, -1);
> +
> + if (sram_pool) {
> + addr = ioremap(phys, len);
> + if (!addr)
> + return -ENOMEM;
> + if((status = gen_pool_add_virt(sram_pool, (unsigned)addr,
> + phys, len, -1)))
Nit: prefer to set status outside of if().
Looks good otherwise. Thanks for reviving this.
Thanks,
Sekhar
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox