* [PATCH v2] ARM: Tegra: Make tegra_dma_init a postcore_initcall
From: Olof Johansson @ 2011-02-23 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298482889-21841-1-git-send-email-swarren@nvidia.com>
On Wed, Feb 23, 2011 at 9:41 AM, Stephen Warren <swarren@nvidia.com> wrote:
> The following commit makes the Tegra APB DMA engine fail to initialize
> correctly: 0cf6230af909a86f81907455eca2a5c9b8f68fe6
> ARM: tegra: Move tegra_common_init to tegra_init_early
>
> The reason is that tegra_init_early_ calls tegra_dma_init which calls
> request_threaded_irq, which fails since the IRQ hasn't yet been marked
> valid; that only happens in tegra_init_irq, which gets called after
> tegra_init_early.
>
> This used to work OK, since tegra_init_early was tegra_common_init, which
> got called after tegra_init_irq, basically from the beginning of
> tegra_harmony_init.
>
> Solve this by converting tegra_dma_init to a postcore_initcall. This makes
> it execute late enough that IRQs are marked valid, and avoids having to
> add it back to every machine's init function.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Olof Johansson <olof@lixom.net>
^ permalink raw reply
* [PATCH v2] i2c: tegra: Add i2c support
From: Colin Cross @ 2011-02-23 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110223002059.GV15795@trinity.fluff.org>
On Tue, Feb 22, 2011 at 4:20 PM, Ben Dooks <ben-i2c@fluff.org> wrote:
> On Sun, Feb 20, 2011 at 05:14:21PM -0800, Colin Cross wrote:
>> Adds I2C bus driver for nVidia Tegra SoCs. ?Tegra includes 4 I2C
>> controllers, one of which is inside the Dynamic Voltage Controller
>> and has a slightly different register map.
>>
>> Signed-off-by: Colin Cross <ccross@android.com>
>
> Would have been helpful to start a new thread, missed this the first time
> around.
>
>> + ? ? i2c_dev = kzalloc(sizeof(struct tegra_i2c_dev), GFP_KERNEL);
>> + ? ? if (!i2c_dev) {
>
> no error print here.
>
>> + ? ? ? ? ? ? ret = -ENOMEM;
>> + ? ? ? ? ? ? goto err_i2c_clk_put;
>> + ? ? }
>
>> + ? ? if (pdev->id == 3)
>> + ? ? ? ? ? ? i2c_dev->is_dvc = 1;
>> + ? ? init_completion(&i2c_dev->msg_complete);
>
> you might want to think about having a seperate platform bus name for
> this case, and switching the is_dvc field on that. It'll make life much
> easier if someone decides that what the next tegra i2c needs is 5 i2c
> controllers.
>
> I'll consider putting this (as is) into the -next tree, but would like
> to see the issues with readsl/writesl sorted out and any other review
> comments sorted.
>
Thanks for merging it. Can I merge your i2c-tegra tree into the tegra
for-next tree to allow some board changes that depend on the header to
go on top?
^ permalink raw reply
* [PATCH v3 2/2] OMAP: IOMMU: add support to callback during fault handling
From: David Cohen @ 2011-02-23 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=s-p3OQfzor27sf-qqqNxipSrOAEQtPQEGaO=L@mail.gmail.com>
On Wed, Feb 23, 2011 at 3:39 PM, Guzman Lugo, Fernando
<fernando.lugo@ti.com> wrote:
> On Wed, Feb 23, 2011 at 3:45 AM, David Cohen <dacohen@gmail.com> wrote:
>> On Wed, Feb 23, 2011 at 3:17 AM, Guzman Lugo, Fernando
>> <fernando.lugo@ti.com> wrote:
>>> On Wed, Feb 16, 2011 at 1:35 PM, David Cohen <dacohen@gmail.com> wrote:
>>>> Add support to register an isr for IOMMU fault situations and adapt it
>>>> to allow such (*isr)() to be used as fault callback. Drivers using IOMMU
>>>> module might want to be informed when errors happen in order to debug it
>>>> or react.
>>>>
>>>> Signed-off-by: David Cohen <dacohen@gmail.com>
>>>> ---
>>>> ?arch/arm/mach-omap2/iommu2.c ? ? ? ? ? ?| ? 17 +++++++++-
>>>> ?arch/arm/plat-omap/include/plat/iommu.h | ? 14 ++++++++-
>>>> ?arch/arm/plat-omap/iommu.c ? ? ? ? ? ? ?| ? 52 ++++++++++++++++++++++---------
>>>> ?3 files changed, 65 insertions(+), 18 deletions(-)
>>>>
>>> ....
>>>
>>>> @@ -917,6 +912,33 @@ void iommu_put(struct iommu *obj)
>>>> ?}
>>>> ?EXPORT_SYMBOL_GPL(iommu_put);
>>>>
>>>> +int iommu_set_isr(const char *name,
>>>> + ? ? ? ? ? ? ? ? int (*isr)(struct iommu *obj, u32 da, u32 iommu_errs,
>>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ?void *priv),
>>>> + ? ? ? ? ? ? ? ? void *isr_priv)
>>>> +{
>>>> + ? ? ? struct device *dev;
>>>> + ? ? ? struct iommu *obj;
>>>> +
>>>
>>> if the driver support multiple user for the same iommu why can only
>>> one callback be registered? should it support register multiple
>>> callback function (one per user)?
>>
>> Can you define a scenario for that?
>> On OMAP3 ISP the multiple users are the multiple ISP submodule, but I
>> don't think it's necessary all submodule to have a specific callback.
>> ISP core layer should handle.
>
> Hi,
>
> In OMAP4 the cortex M3 is a double core processor and as each core is
> running they own version of the RTOS we threat them independently. So
> our driver which controls the remote processor sees two processor but
> both use the same iommu hw. When a iommu fault happens, at this
> moment, it is consider as a faltal error and it is no managed to
> recover and continue, instead a restart of the processor is needed, if
> the fault happens in core0 we need to reset core1 too and vice versa.
> if the iommu would support several user callbacks, we can register the
> callback which resets core0 and also the callback which resets core1
> and treat them as totally independent processors. Also we have an
> error event notifier driver, which is only in charge of notifying
> error events to userspace, so we would have multiple callbacks we
> could do this
I understood your point. In this case, I may not disagree about having
more than one callback per obj, although it doesn't seem a nice
scenario.
We can have a list of callbacks and call the entire list when a fault
happens. But it's necessary to pay attention it will happen in atomic
context and users should not abuse and register many callbacks. The
callback should *NOT* print useless messages and must verify the error
code to not execute useless steps.
In this context, callback and ISR cannot share a same pointer anymore.
>
> iommu <---- register fault callback for error notify driver
>
> instead of
>
> iommu <--- register fault callback for remote processor driver
> <----register fault event for error notify driver.
>
> with that, we remove one dependency of the errornotify driver.
I don't know very well the errornotify driver, but to bypass it seems
be a good approach for me.
>
> Moreover, the iommu code support serveral users of the same hw iommu,
> and it does not make sense for me, that you can register only one
> callback, or if other user register its callback the previous one will
> be overwritten.
It's quite complex and dangerous this situation, as one driver can
crash another one. But I don't think drivers have much choice.
Hiroshi, do you have any different opinion for this subject? I can
send a v4 version for this patch giving support for multiple callbacks
per obj.
Br,
David
>
> Regards,
> Fernando.
>
>>
>> Br,
>>
>> David
>>
>>>
>>> Regards,
>>> Fernando.
>>>
>>
>
^ permalink raw reply
* [PATCH 1/5] ARM: smp: Select local timers vs dummytimersupportruntime
From: Russell King - ARM Linux @ 2011-02-23 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b9ea630b656efc370b6c5da78dedd41d@mail.gmail.com>
On Thu, Feb 24, 2011 at 12:41:38AM +0530, Santosh Shilimkar wrote:
> > -----Original Message-----
> > From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> > Sent: Thursday, February 24, 2011 12:33 AM
> > To: Santosh Shilimkar
> > Cc: linux-omap at vger.kernel.org; Kevin Hilman; linux-arm-
> > kernel at lists.infradead.org; tony at atomide.com; David Brown; Daniel
> > Walker; Bryan Huntsman; Kukjin Kim; Paul Mundt; Magnus Damm; Colin
> > Cross; Erik Gilling; Srinidhi Kasagar; Linus Walleij
> > Subject: Re: [PATCH 1/5] ARM: smp: Select local timers vs
> > dummytimersupportruntime
> >
> > On Wed, Feb 23, 2011 at 11:28:11PM +0530, Santosh Shilimkar wrote:
> > > Patch 6759/1 and patch 6760/1 in patch system
> >
> > Was there any difference between 6760 and 6753 ?
> Nope.
> I just rebased them together and pushed
Well, both patches are identical, so I'll stick with 6753/1 which I've
already merged.
Thanks
^ permalink raw reply
* [PATCH 1/5] ARM: smp: Select local timers vsdummytimersupportruntime
From: Santosh Shilimkar @ 2011-02-23 20:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110223195533.GC16041@n2100.arm.linux.org.uk>
> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Thursday, February 24, 2011 1:26 AM
> To: Santosh Shilimkar
> Cc: linux-omap at vger.kernel.org; Kevin Hilman; linux-arm-
> kernel at lists.infradead.org; tony at atomide.com; David Brown; Daniel
> Walker; Bryan Huntsman; Kukjin Kim; Paul Mundt; Magnus Damm; Colin
> Cross; Erik Gilling; Srinidhi Kasagar; Linus Walleij
> Subject: Re: [PATCH 1/5] ARM: smp: Select local timers
> vsdummytimersupportruntime
>
> On Thu, Feb 24, 2011 at 12:41:38AM +0530, Santosh Shilimkar wrote:
> > > -----Original Message-----
> > > From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> > > Sent: Thursday, February 24, 2011 12:33 AM
> > > To: Santosh Shilimkar
> > > Cc: linux-omap at vger.kernel.org; Kevin Hilman; linux-arm-
> > > kernel at lists.infradead.org; tony at atomide.com; David Brown;
> Daniel
> > > Walker; Bryan Huntsman; Kukjin Kim; Paul Mundt; Magnus Damm;
> Colin
> > > Cross; Erik Gilling; Srinidhi Kasagar; Linus Walleij
> > > Subject: Re: [PATCH 1/5] ARM: smp: Select local timers vs
> > > dummytimersupportruntime
> > >
> > > On Wed, Feb 23, 2011 at 11:28:11PM +0530, Santosh Shilimkar
> wrote:
> > > > Patch 6759/1 and patch 6760/1 in patch system
> > >
> > > Was there any difference between 6760 and 6753 ?
> > Nope.
> > I just rebased them together and pushed
>
> Well, both patches are identical, so I'll stick with 6753/1 which
> I've already merged.
>
Thanks.
I got discarded messege for 6753, so I submitted it.
As you noticed, they are same.
^ permalink raw reply
* [PATCH v2] ARM: Tegra: DMA: Fail safe if initialization fails
From: Stephen Warren @ 2011-02-23 20:06 UTC (permalink / raw)
To: linux-arm-kernel
tegra_dma_init currently simply bails out early if any initialization fails.
This skips various data-structure initialization. In turn, this means that
tegra_dma_allocate_channel can still hand out channels. In this case, when
tegra_dma_free_channel is called, which calls tegra_dma_cancel, the walking
on ch->list will OOPS since the list's next/prev pointers may still be
NULL.
To solve this, add an explicit "initialized" flag, only set this once _init
has fully completed successfully, and have _allocate_channel refuse to hand
out channels if this is not set.
While at it, simplify _init:
* Remove redundant memsets
* Use bitmap_fill to mark all channels as in-use up-front, and remove
some now-redundant bitmap initialization loops.
* Only mark a channel as free once all channel-related initialization has
completed.
Finally, the successful exit path from _init always has ret==0, so just
hard-code that return. The error path still returns ret.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
v2:
* Added explicit initialized flag. I chose not to re-use the shared-channel
bitmap entry for this purpose, since that bit needs to be marked in-use
so that the non-shared-channel path doesn't hand out that channel.
* Removed redundant memsets
* Use bitmap_fill instead of a loop
* Hard-code success return value
arch/arm/mach-tegra/dma.c | 23 ++++++++++-------------
1 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-tegra/dma.c b/arch/arm/mach-tegra/dma.c
index bd4f62a..01db832 100644
--- a/arch/arm/mach-tegra/dma.c
+++ b/arch/arm/mach-tegra/dma.c
@@ -127,8 +127,8 @@ struct tegra_dma_channel {
#define NV_DMA_MAX_CHANNELS 32
+static int initialized;
static DEFINE_MUTEX(tegra_dma_lock);
-
static DECLARE_BITMAP(channel_usage, NV_DMA_MAX_CHANNELS);
static struct tegra_dma_channel dma_channels[NV_DMA_MAX_CHANNELS];
@@ -352,6 +352,9 @@ struct tegra_dma_channel *tegra_dma_allocate_channel(int mode)
int channel;
struct tegra_dma_channel *ch = NULL;
+ if (!initialized)
+ return NULL;
+
mutex_lock(&tegra_dma_lock);
/* first channel is the shared channel */
@@ -678,6 +681,8 @@ int __init tegra_dma_init(void)
void __iomem *addr;
struct clk *c;
+ bitmap_fill(channel_usage, NV_DMA_MAX_CHANNELS);
+
c = clk_get_sys("tegra-dma", NULL);
if (IS_ERR(c)) {
pr_err("Unable to get clock for APB DMA\n");
@@ -696,18 +701,9 @@ int __init tegra_dma_init(void)
writel(0xFFFFFFFFul >> (31 - TEGRA_SYSTEM_DMA_CH_MAX),
addr + APB_DMA_IRQ_MASK_SET);
- memset(channel_usage, 0, sizeof(channel_usage));
- memset(dma_channels, 0, sizeof(dma_channels));
-
- /* Reserve all the channels we are not supposed to touch */
- for (i = 0; i < TEGRA_SYSTEM_DMA_CH_MIN; i++)
- __set_bit(i, channel_usage);
-
for (i = TEGRA_SYSTEM_DMA_CH_MIN; i <= TEGRA_SYSTEM_DMA_CH_MAX; i++) {
struct tegra_dma_channel *ch = &dma_channels[i];
- __clear_bit(i, channel_usage);
-
ch->id = i;
snprintf(ch->name, TEGRA_DMA_NAME_SIZE, "dma_channel_%d", i);
@@ -726,14 +722,15 @@ int __init tegra_dma_init(void)
goto fail;
}
ch->irq = irq;
+
+ __clear_bit(i, channel_usage);
}
/* mark the shared channel allocated */
__set_bit(TEGRA_SYSTEM_DMA_CH_MIN, channel_usage);
- for (i = TEGRA_SYSTEM_DMA_CH_MAX+1; i < NV_DMA_MAX_CHANNELS; i++)
- __set_bit(i, channel_usage);
+ initialized = 1;
- return ret;
+ return 0;
fail:
writel(0, addr + APB_DMA_GEN);
for (i = TEGRA_SYSTEM_DMA_CH_MIN; i <= TEGRA_SYSTEM_DMA_CH_MAX; i++) {
--
1.7.1
^ permalink raw reply related
* [PATCH v3 2/2] OMAP: IOMMU: add support to callback during fault handling
From: Sakari Ailus @ 2011-02-23 20:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=s-p3OQfzor27sf-qqqNxipSrOAEQtPQEGaO=L@mail.gmail.com>
Guzman Lugo, Fernando wrote:
> Hi,
Hi Fernando,
> In OMAP4 the cortex M3 is a double core processor and as each core is
> running they own version of the RTOS we threat them independently. So
> our driver which controls the remote processor sees two processor but
> both use the same iommu hw. When a iommu fault happens, at this
> moment, it is consider as a faltal error and it is no managed to
> recover and continue, instead a restart of the processor is needed, if
> the fault happens in core0 we need to reset core1 too and vice versa.
> if the iommu would support several user callbacks, we can register the
> callback which resets core0 and also the callback which resets core1
> and treat them as totally independent processors. Also we have an
> error event notifier driver, which is only in charge of notifying
> error events to userspace, so we would have multiple callbacks we
> could do this
The original purpose of the patch, as far as I understand, is to allow
getting useful information for debugging purposes should an iommu fault
happen.
Also, I'm not sure it's necessarily a good idea to just go and reset
the M3 cores in case an iommu fault happens --- this is very probably a
grave bug in the software running on those M3s. It should be fixed
instead of just hiding it. There will be consequences to host side as
well, won't there?
> iommu <---- register fault callback for error notify driver
>
> instead of
>
> iommu <--- register fault callback for remote processor driver
> <----register fault event for error notify driver.
>
> with that, we remove one dependency of the errornotify driver.
I suppose this is not in mainline?
Regards,
--
Sakari Ailus
sakari.ailus at maxwell.research.nokia.com
^ permalink raw reply
* [PATCH v3 2/2] OMAP: IOMMU: add support to callback during fault handling
From: David Cohen @ 2011-02-23 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D656961.7080105@maxwell.research.nokia.com>
On Wed, Feb 23, 2011 at 10:09 PM, Sakari Ailus
<sakari.ailus@maxwell.research.nokia.com> wrote:
> Guzman Lugo, Fernando wrote:
>> Hi,
>
> Hi Fernando,
>
>> In OMAP4 the cortex M3 is a double core processor and as each core is
>> running they own version of the RTOS we threat them independently. So
>> our driver which controls the remote processor sees two processor but
>> both use the same iommu hw. When a iommu fault happens, at this
>> moment, it is consider as a faltal error and it is no managed to
>> recover and continue, instead a restart of the processor is needed, if
>> the fault happens in core0 we need to reset core1 too and vice versa.
>> if the iommu would support several user callbacks, we can register the
>> callback which resets core0 and also the callback which resets core1
>> and treat them as totally independent processors. Also we have an
>> error event notifier driver, which is only in charge of notifying
>> error events to userspace, so we would have multiple callbacks we
>> could do this
>
> The original purpose of the patch, as far as I understand, is to allow
> getting useful information for debugging purposes should an iommu fault
> happen.
>
> Also, I'm not sure it's necessarily a good idea to just go and reset
> the M3 cores in case an iommu fault happens --- this is very probably a
> grave bug in the software running on those M3s. It should be fixed
> instead of just hiding it. There will be consequences to host side as
> well, won't there?
That's really a good point. callbacks in this situation are mostly to
debug purpose. Drivers shouldn't rely on that to work properly.
David
>
>> iommu <---- register fault callback for error notify driver
>>
>> instead of
>>
>> iommu <--- register fault callback for remote processor driver
>> <----register fault event for error notify driver.
>>
>> with that, we remove one dependency of the errornotify driver.
>
> I suppose this is not in mainline?
>
> Regards,
>
> --
> Sakari Ailus
> sakari.ailus at maxwell.research.nokia.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 1/2] PRUSS UIO driver support
From: Thomas Gleixner @ 2011-02-23 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298469161-7644-2-git-send-email-pratheesh@ti.com>
On Wed, 23 Feb 2011, Pratheesh Gangadhar wrote:
Is it actually too much of an hassle to cc the people who spent their
time to review previous versions of your patch ?
> +struct clk *pruss_clk;
> +struct uio_info *info;
> +void *ddr_virt_addr = NULL, *prussio_virt_addr = NULL;
Grrr. We do not initialize with NULL.
> +dma_addr_t ddr_phy_addr;
Also all of these want to be static.
> +static irqreturn_t pruss_handler(int irq, struct uio_info *dev_info)
> +{
> + void __iomem *base = dev_info->mem[0].internal_addr;
> + void __iomem *intren_reg = base + PINTC_HIER;
> + void __iomem *intrstat_reg = base + PINTC_HIPIR + ((irq - 1) << 2);
> + int intren_regval = ioread32(intren_reg), intr_mask = (1 << (irq - 1));
> +
> + /* Is interrupt enabled and active ? */
> + if (!(intren_regval & intr_mask)
> + && (ioread32(intrstat_reg) & PINTC_HIPIR_NO_PEND_MASK))
> + return IRQ_NONE;
You could avoid all these ugly line breaks by chosing sensible short
names for variables and defines.
> + /* Disable interrupt */
> + iowrite32((intren_regval & ~intr_mask), intren_reg);
> + return IRQ_HANDLED;
> +}
> +
> +static void pruss_cleanup(struct platform_device *dev, struct uio_info *info)
> +{
> + int count;
> + struct uio_info *p;
Nit: I prefer the longer declarations above the shorter ones. It's
easier to parse, but that's really my personal preference.
struct uio_info *p;
int count;
Compare and contrast it and decide yourself.
> +
> + for (count = 0, p = info; count < MAX_PRUSS_EVTOUT_INSTANCE;
> + count++, p++) {
Aside of making that constant shorter, you could assign info to p in
the variable declaration already. So avoid that line break.
> + uio_unregister_device(p);
> + kfree(p->name);
> + }
> + iounmap(prussio_virt_addr);
> + dma_free_coherent(&dev->dev, info[0].mem[2].size,
> + info[0].mem[2].internal_addr, info[0].mem[2].addr);
You sure, that iounmap and dma_free_coherent are too happy about being
called with NULL pointers?
> +
> + kfree(info);
> + clk_put(pruss_clk);
> +}
> +
> +static int __devinit pruss_probe(struct platform_device *dev)
> +{
> + int ret = -ENODEV, count = 0;
> + struct resource *regs_prussio, *regs_l3ram, *regs_ddr;
> + struct uio_info *p;
> +
> + info = kzalloc(sizeof(struct uio_info) * MAX_PRUSS_EVTOUT_INSTANCE,
> + GFP_KERNEL);
> + if (!info)
> + return -ENOMEM;
> +
> + /* Power on PRU in case its not done as part of boot-loader */
> + pruss_clk = clk_get(&dev->dev, "pruss");
> + if (IS_ERR(pruss_clk)) {
> + dev_err(&dev->dev, "Failed to get clock\n");
> + ret = PTR_ERR(pruss_clk);
> + return ret;
Memory leak.
> + } else {
> + clk_enable(pruss_clk);
> + }
> +
> + regs_prussio = platform_get_resource(dev, IORESOURCE_MEM, 0);
> + if (!regs_prussio) {
> + dev_err(&dev->dev, "No PRUSS I/O resource specified\n");
> + goto out_free;
> + }
> +
> + regs_l3ram = platform_get_resource(dev, IORESOURCE_MEM, 1);
> + if (!regs_l3ram) {
> + dev_err(&dev->dev, "No L3 RAM resource specified\n");
> + goto out_free;
> + }
> +
> + regs_ddr = platform_get_resource(dev, IORESOURCE_MEM, 2);
> + if (!regs_ddr) {
> + dev_err(&dev->dev, "No External RAM resource specified\n");
> + goto out_free;
> + }
> +
> + if (!regs_prussio->start || !regs_l3ram->start) {
> + dev_err(&dev->dev, "Invalid memory resource\n");
> + goto out_free;
> + }
> +
> + ddr_virt_addr =
> + dma_alloc_coherent(&dev->dev, regs_ddr->end - regs_ddr->start + 1,
> + &ddr_phy_addr, GFP_KERNEL | GFP_DMA);
> + if (!ddr_virt_addr) {
> + dev_err(&dev->dev, "Could not allocate external memory\n");
> + goto out_free;
> + }
> +
> + prussio_virt_addr =
> + ioremap(regs_prussio->start,
> + regs_prussio->end - regs_prussio->start + 1);
Either make those variable names shorter or do:
len = regs_prussio->end - regs_prussio->start + 1;
prussio_virt_addr = ioremap(regs_prussio->start, len);
Those multi line breaks are irritating and not necessary at all.
They result from mindlessly converting code following an unfortunately
popular codingstyle which is only readable on extra wide screen
monitors. I really wonder when people start to understand that the
human eye can only parse up to a certain line width easily. There is a
reason why newspapers are printed in columns.
Please be a bit more careful about this. Just mechanically converting
existing horrible code to 80 chars does not make it more readable and
less horrible than not converting it at all.
> + if (prussio_virt_addr) {
> + dev_err(&dev->dev, "Can't remap PRUSS I/O address range\n");
> + goto out_free;
> + }
> +
> + for (count = 0, p = info; count < MAX_PRUSS_EVTOUT_INSTANCE;
> + count++, p++) {
See above.
for (cnt = 0, p = info; cnt < MAX_PRUSS_EVT; cnt++, p++) {
is better readable and contains exactly the same amount of
information.
Thanks,
tglx
^ permalink raw reply
* [PATCH 4/5] ARM: Tegra: Create defines for GPIO names
From: Stephen Warren @ 2011-02-23 20:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinPssv8Wpy0Qe5GAHqN=9dicSLZ8sUmq+JeW2_q@mail.gmail.com>
Colin Cross wrote at Wednesday, February 23, 2011 12:09 PM:
> On Wed, Feb 23, 2011 at 10:58 AM, Stephen Warren <swarren@nvidia.com> wrote:
> > This ensures they're kept in sync between platform_data definitions and
> > the GPIO table initialization.
>
> Can you name these for what they are used for (if they have a single use)?
> i.e. TEGRA_GPIO_EMMC_CD instead of TEGRA_GPIO_SD2_CD
Are you looking for correlation with the schematics, or something else;
my interpretation is that the names in the patch already appear to describe
what the signals are used for.
In particular, in your example, you wrote "EMMC" rather than "SD2". I'm not
sure where the name "EMMC" comes from, nor why there's no number in the name
"EMMC".
For reference, the schematics for these two boards use the following signal
names:
Harmony:
SDIO2_CD, SDIO2_WP, EN_VDDIO_SD
HSMMC_CD, HSMMC_WP, EN_VDDIO_SDMMC
Seaboard:
SDIO32_CD, SDIO3_WP, EN_VDDIO_SD
Would those be OK?
Thanks.
--
nvpublic
^ permalink raw reply
* [PATCH 4/5] ARM: Tegra: Create defines for GPIO names
From: Colin Cross @ 2011-02-23 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF03112A5D59@HQMAIL01.nvidia.com>
On Wed, Feb 23, 2011 at 12:35 PM, Stephen Warren <swarren@nvidia.com> wrote:
> Colin Cross wrote at Wednesday, February 23, 2011 12:09 PM:
>> On Wed, Feb 23, 2011 at 10:58 AM, Stephen Warren <swarren@nvidia.com> wrote:
>> > This ensures they're kept in sync between platform_data definitions and
>> > the GPIO table initialization.
>>
>> Can you name these for what they are used for (if they have a single use)?
>> i.e. TEGRA_GPIO_EMMC_CD instead of TEGRA_GPIO_SD2_CD
>
> Are you looking for correlation with the schematics, or something else;
> my interpretation is that the names in the patch already appear to describe
> what the signals are used for.
>
> In particular, in your example, you wrote "EMMC" rather than "SD2". I'm not
> sure where the name "EMMC" comes from, nor why there's no number in the name
> "EMMC".
>
> For reference, the schematics for these two boards use the following signal
> names:
>
> Harmony:
> SDIO2_CD, SDIO2_WP, EN_VDDIO_SD
> HSMMC_CD, HSMMC_WP, EN_VDDIO_SDMMC
>
> Seaboard:
> SDIO32_CD, SDIO3_WP, EN_VDDIO_SD
>
> Would those be OK?
I meant use the name of the device they are connected to (if there is
one). By EMMC I meant the embedded MMC storage device. The gpio is
not notable because it is used by the SDIO driver for port 2, it is
notable because it is connected to the EMMC chip or the wifi chip or a
card slot.
^ permalink raw reply
* [PATCH 4/5] ARM: Tegra: Create defines for GPIO names
From: Stephen Warren @ 2011-02-23 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimgB3CZmiVXR9MYTEOXk9uSok12vcVaTTx1tn2M@mail.gmail.com>
Colin Cross wrote at Wednesday, February 23, 2011 1:39 PM:
>
> On Wed, Feb 23, 2011 at 12:35 PM, Stephen Warren <swarren@nvidia.com> wrote:
> > Colin Cross wrote at Wednesday, February 23, 2011 12:09 PM:
> >> On Wed, Feb 23, 2011 at 10:58 AM, Stephen Warren <swarren@nvidia.com> wrote:
> >> > This ensures they're kept in sync between platform_data definitions and
> >> > the GPIO table initialization.
> >>
> >> Can you name these for what they are used for (if they have a single use)?
> >> i.e. TEGRA_GPIO_EMMC_CD instead of TEGRA_GPIO_SD2_CD
> >
> > Are you looking for correlation with the schematics, or something else;
>...
>
> I meant use the name of the device they are connected to (if there is
> one). By EMMC I meant the embedded MMC storage device. The gpio is
> not notable because it is used by the SDIO driver for port 2, it is
> notable because it is connected to the EMMC chip or the wifi chip or a
> card slot.
The GPIOs currently in the code are for SD slots/connectors; we don't have
any GPIO definitions for any internal MMC memory, or WiFi chips.
I guess the numbering could be changed; 2 vs. 4 don't very obviously map to
the slots on the board for the user, yet the only thing better I can think
of would be the connector numbers on the silkscreen?
--
nvpublic
^ permalink raw reply
* [PATCH v3 1/2] PRUSS UIO driver support
From: Sergei Shtylyov @ 2011-02-23 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1102232057260.2701@localhost6.localdomain6>
Hello.
On 23-02-2011 23:25, Thomas Gleixner wrote:
>> + prussio_virt_addr =
>> + ioremap(regs_prussio->start,
>> + regs_prussio->end - regs_prussio->start + 1);
> Either make those variable names shorter or do:
> len = regs_prussio->end - regs_prussio->start + 1;
Or even:
len = resource_size(regs_prussio);
> prussio_virt_addr = ioremap(regs_prussio->start, len);
WBR, Sergei
^ permalink raw reply
* [PATCH 4/6] ARM: tegra: harmony: register sdhci devices
From: Grant Likely @ 2011-02-23 20:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=mjR6dnxcTxYzTvJK4DgEW7mO+p4TUeu6kq6fn@mail.gmail.com>
On Tue, Feb 22, 2011 at 07:44:58AM -0800, Olof Johansson wrote:
> On Mon, Feb 21, 2011 at 10:59 PM, Mike Rapoport <mike@compulab.co.il> wrote:
> > Hi Olof,
> > Sorry for jumping late, haven't thought about the proposal below yesterday.
> > I'm not objecting to applying the patch as is, we can refactor the code
> > afterwards as well.
>
> Thanks for the input. And yeah, I'd say we can refactor later when we
> see how things will fit well with flat devicetrees. More below.
>
>
> >> ?static void __init tegra_harmony_init(void)
> >> ?{
> >> ? ? ? tegra_common_init();
> >> @@ -85,6 +111,10 @@ static void __init tegra_harmony_init(void)
> >>
> >> ? ? ? harmony_pinmux_init();
> >>
> >> + ? ? tegra_sdhci_device1.dev.platform_data = &sdhci_pdata1;
> >> + ? ? tegra_sdhci_device2.dev.platform_data = &sdhci_pdata2;
> >> + ? ? tegra_sdhci_device4.dev.platform_data = &sdhci_pdata4;
> >> +
> >
> > I think that instead of copying explicit initialization of the platform_data
> > member from board to board we can do something similar to what PXA does. The
> > board file would have to call something like
> > tegra_set_device_X_info(struct tegra_device_X_platform_data *data);
> > and then static registration of platform devices in the board files can be dropped.
> >
> > For instance, the devices.c would have
> >
> > void __init tegra_register_device(struct platform_device *dev, void *data)
> > {
> > ? ? ? ?int ret;
> >
> > ? ? ? ?dev->dev.platform_data = data;
> >
> > ? ? ? ?ret = platform_device_register(dev);
> > ? ? ? ?if (ret)
> > ? ? ? ? ? ? ? ?dev_err(&dev->dev, "unable to register device: %d\n", ret);
> > }
> >
> > void __init tegra_set_sdhci1_info(struct tegra_sdhci_platform_data *info)
> > {
> > ? ? ? ?tegra_register_device(&tegra_sdhci_device1, info);
> > }
> >
> > and the board files would just call tegra_set_sdhci1_info to pass the platform
> > data for the tegra_sdhci_device1 and register the device.
> >
> > This way we could reduce amount of copy/paste between the board files. Besides,
> > if/when tegra will be using device trees, handling of the device registration in
> > common place would make the transition easier.
>
> I don't see how that reduces the amount of copy and paste
> (significantly), since you still need the platform_data defined per
> board so you'll need to add the calls there. Maybe a generic
> "set_platform_data" hook instead of doing the pointer assignment
> open-coded would be an improvement though.
Option 3 is to use a bus notifier to attach additional platform data
when the device gets registered. That is turning out to be the
cleanest solution when it comes to getting additional pdata to a
device that is pulled out of the dt, and this sounds like a similar
situation.
>
> I'm personally not a fan of the style where data is described as code,
> i.e. where there would be a tegra_set_<dev>_info function for every
> possible device out there. If anything that adds to the amount of
> copy-and-paste (per device), when it could just be handled with one
> common function being passed the appropriate data (i.e. like
> tegra_register_device).
+1
>
> Anyway, I'm not looking to argue over it. :) I think we'll see when
> the FDT pieces start to take shape what kind of model will work well,
> and there's no reason to do premature refactoring.
>
>
> -Olof
^ permalink raw reply
* [PATCH v3 1/2] PRUSS UIO driver support
From: Thomas Gleixner @ 2011-02-23 20:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6572ED.9020805@mvista.com>
On Wed, 23 Feb 2011, Sergei Shtylyov wrote:
> Hello.
>
> On 23-02-2011 23:25, Thomas Gleixner wrote:
>
> > > + prussio_virt_addr =
> > > + ioremap(regs_prussio->start,
> > > + regs_prussio->end - regs_prussio->start + 1);
>
> > Either make those variable names shorter or do:
>
> > len = regs_prussio->end - regs_prussio->start + 1;
>
> Or even:
>
> len = resource_size(regs_prussio);
>
> > prussio_virt_addr = ioremap(regs_prussio->start, len);
Good point. Forgot about that one :)
Thanks,
tglx
^ permalink raw reply
* [PATCH v3 2/2] OMAP: IOMMU: add support to callback during fault handling
From: Sakari Ailus @ 2011-02-23 20:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=+rzHDB_hGzGtZKNZB02z4v65GAD-87zVpOdni@mail.gmail.com>
David Cohen wrote:
> On Wed, Feb 23, 2011 at 3:39 PM, Guzman Lugo, Fernando
> <fernando.lugo@ti.com> wrote:
>> On Wed, Feb 23, 2011 at 3:45 AM, David Cohen <dacohen@gmail.com> wrote:
>>> On Wed, Feb 23, 2011 at 3:17 AM, Guzman Lugo, Fernando
>>> <fernando.lugo@ti.com> wrote:
>>>> On Wed, Feb 16, 2011 at 1:35 PM, David Cohen <dacohen@gmail.com> wrote:
>>>>> Add support to register an isr for IOMMU fault situations and adapt it
>>>>> to allow such (*isr)() to be used as fault callback. Drivers using IOMMU
>>>>> module might want to be informed when errors happen in order to debug it
>>>>> or react.
>>>>>
>>>>> Signed-off-by: David Cohen <dacohen@gmail.com>
>>>>> ---
>>>>> arch/arm/mach-omap2/iommu2.c | 17 +++++++++-
>>>>> arch/arm/plat-omap/include/plat/iommu.h | 14 ++++++++-
>>>>> arch/arm/plat-omap/iommu.c | 52 ++++++++++++++++++++++---------
>>>>> 3 files changed, 65 insertions(+), 18 deletions(-)
>>>>>
>>>> ....
>>>>
>>>>> @@ -917,6 +912,33 @@ void iommu_put(struct iommu *obj)
>>>>> }
>>>>> EXPORT_SYMBOL_GPL(iommu_put);
>>>>>
>>>>> +int iommu_set_isr(const char *name,
>>>>> + int (*isr)(struct iommu *obj, u32 da, u32 iommu_errs,
>>>>> + void *priv),
>>>>> + void *isr_priv)
>>>>> +{
>>>>> + struct device *dev;
>>>>> + struct iommu *obj;
>>>>> +
>>>>
>>>> if the driver support multiple user for the same iommu why can only
>>>> one callback be registered? should it support register multiple
>>>> callback function (one per user)?
>>>
>>> Can you define a scenario for that?
>>> On OMAP3 ISP the multiple users are the multiple ISP submodule, but I
>>> don't think it's necessary all submodule to have a specific callback.
>>> ISP core layer should handle.
>>
>> Hi,
>>
>> In OMAP4 the cortex M3 is a double core processor and as each core is
>> running they own version of the RTOS we threat them independently. So
>> our driver which controls the remote processor sees two processor but
>> both use the same iommu hw. When a iommu fault happens, at this
>> moment, it is consider as a faltal error and it is no managed to
>> recover and continue, instead a restart of the processor is needed, if
>> the fault happens in core0 we need to reset core1 too and vice versa.
>> if the iommu would support several user callbacks, we can register the
>> callback which resets core0 and also the callback which resets core1
>> and treat them as totally independent processors. Also we have an
>> error event notifier driver, which is only in charge of notifying
>> error events to userspace, so we would have multiple callbacks we
>> could do this
>
> I understood your point. In this case, I may not disagree about having
> more than one callback per obj, although it doesn't seem a nice
> scenario.
> We can have a list of callbacks and call the entire list when a fault
> happens. But it's necessary to pay attention it will happen in atomic
> context and users should not abuse and register many callbacks. The
> callback should *NOT* print useless messages and must verify the error
> code to not execute useless steps.
> In this context, callback and ISR cannot share a same pointer anymore.
I think this is outside of the scope of the patch but...
To efficiently debug iommu faults (with a driver using iommu page
walking), besides the actual fault address the list of existing mappings
and the information which driver created them and for which purpose is
useful.
The list of mappings is already available in the iommu structure. It'd
be nice if there was a function a driver could call to print them.
I can only think of ugly ways to implement the other.
Just my 5 cents (as we have no 2 cent coins here).
Regards,
--
Sakari Ailus
sakari.ailus at maxwell.research.nokia.com
^ permalink raw reply
* [PATCH 4/5] ARM: Tegra: Create defines for GPIO names
From: Colin Cross @ 2011-02-23 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF03112A5D63@HQMAIL01.nvidia.com>
On Wed, Feb 23, 2011 at 12:49 PM, Stephen Warren <swarren@nvidia.com> wrote:
> Colin Cross wrote at Wednesday, February 23, 2011 1:39 PM:
>>
>> On Wed, Feb 23, 2011 at 12:35 PM, Stephen Warren <swarren@nvidia.com> wrote:
>> > Colin Cross wrote at Wednesday, February 23, 2011 12:09 PM:
>> >> On Wed, Feb 23, 2011 at 10:58 AM, Stephen Warren <swarren@nvidia.com> wrote:
>> >> > This ensures they're kept in sync between platform_data definitions and
>> >> > the GPIO table initialization.
>> >>
>> >> Can you name these for what they are used for (if they have a single use)?
>> >> i.e. TEGRA_GPIO_EMMC_CD instead of TEGRA_GPIO_SD2_CD
>> >
>> > Are you looking for correlation with the schematics, or something else;
>>...
>>
>> I meant use the name of the device they are connected to (if there is
>> one). ?By EMMC I meant the embedded MMC storage device. ?The gpio is
>> not notable because it is used by the SDIO driver for port 2, it is
>> notable because it is connected to the EMMC chip or the wifi chip or a
>> card slot.
>
> The GPIOs currently in the code are for SD slots/connectors; we don't have
> any GPIO definitions for any internal MMC memory, or WiFi chips.
>
> I guess the numbering could be changed; 2 vs. 4 don't very obviously map to
> the slots on the board for the user, yet the only thing better I can think
> of would be the connector numbers on the silkscreen?
If they are just general-purpose slots, the existing naming is fine.
Acked-by: Colin Cross <ccross@android.com>
^ permalink raw reply
* [PATCH v2] ARM: Tegra: DMA: Fail safe if initialization fails
From: Colin Cross @ 2011-02-23 21:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298491602-20072-1-git-send-email-swarren@nvidia.com>
On Wed, Feb 23, 2011 at 12:06 PM, Stephen Warren <swarren@nvidia.com> wrote:
> tegra_dma_init currently simply bails out early if any initialization fails.
> This skips various data-structure initialization. In turn, this means that
> tegra_dma_allocate_channel can still hand out channels. In this case, when
> tegra_dma_free_channel is called, which calls tegra_dma_cancel, the walking
> on ch->list will OOPS since the list's next/prev pointers may still be
> NULL.
>
> To solve this, add an explicit "initialized" flag, only set this once _init
> has fully completed successfully, and have _allocate_channel refuse to hand
> out channels if this is not set.
>
> While at it, simplify _init:
> * Remove redundant memsets
> * Use bitmap_fill to mark all channels as in-use up-front, and remove
> ?some now-redundant bitmap initialization loops.
> * Only mark a channel as free once all channel-related initialization has
> ?completed.
>
> Finally, the successful exit path from _init always has ret==0, so just
> hard-code that return. The error path still returns ret.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
> v2:
> * Added explicit initialized flag. I chose not to re-use the shared-channel
> ?bitmap entry for this purpose, since that bit needs to be marked in-use
> ?so that the non-shared-channel path doesn't hand out that channel.
> * Removed redundant memsets
> * Use bitmap_fill instead of a loop
> * Hard-code success return value
>
> ?arch/arm/mach-tegra/dma.c | ? 23 ++++++++++-------------
> ?1 files changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/mach-tegra/dma.c b/arch/arm/mach-tegra/dma.c
> index bd4f62a..01db832 100644
> --- a/arch/arm/mach-tegra/dma.c
> +++ b/arch/arm/mach-tegra/dma.c
> @@ -127,8 +127,8 @@ struct tegra_dma_channel {
>
> ?#define ?NV_DMA_MAX_CHANNELS ?32
>
> +static int initialized;
Use a bool, and call it something like tegra_dma_initialized to
prevent warnings if someone else forgets a static on a variable called
initialized.
> ?static DEFINE_MUTEX(tegra_dma_lock);
> -
Unnecessary whitespace change
> ?static DECLARE_BITMAP(channel_usage, NV_DMA_MAX_CHANNELS);
> ?static struct tegra_dma_channel dma_channels[NV_DMA_MAX_CHANNELS];
>
> @@ -352,6 +352,9 @@ struct tegra_dma_channel *tegra_dma_allocate_channel(int mode)
> ? ? ? ?int channel;
> ? ? ? ?struct tegra_dma_channel *ch = NULL;
>
> + ? ? ? if (!initialized)
Maybe if (WARN_ON(!initialized))?
> + ? ? ? ? ? ? ? return NULL;
> +
> ? ? ? ?mutex_lock(&tegra_dma_lock);
>
> ? ? ? ?/* first channel is the shared channel */
> @@ -678,6 +681,8 @@ int __init tegra_dma_init(void)
> ? ? ? ?void __iomem *addr;
> ? ? ? ?struct clk *c;
>
> + ? ? ? bitmap_fill(channel_usage, NV_DMA_MAX_CHANNELS);
> +
> ? ? ? ?c = clk_get_sys("tegra-dma", NULL);
> ? ? ? ?if (IS_ERR(c)) {
> ? ? ? ? ? ? ? ?pr_err("Unable to get clock for APB DMA\n");
> @@ -696,18 +701,9 @@ int __init tegra_dma_init(void)
> ? ? ? ?writel(0xFFFFFFFFul >> (31 - TEGRA_SYSTEM_DMA_CH_MAX),
> ? ? ? ? ? ? ? addr + APB_DMA_IRQ_MASK_SET);
>
> - ? ? ? memset(channel_usage, 0, sizeof(channel_usage));
> - ? ? ? memset(dma_channels, 0, sizeof(dma_channels));
> -
> - ? ? ? /* Reserve all the channels we are not supposed to touch */
> - ? ? ? for (i = 0; i < TEGRA_SYSTEM_DMA_CH_MIN; i++)
> - ? ? ? ? ? ? ? __set_bit(i, channel_usage);
> -
> ? ? ? ?for (i = TEGRA_SYSTEM_DMA_CH_MIN; i <= TEGRA_SYSTEM_DMA_CH_MAX; i++) {
> ? ? ? ? ? ? ? ?struct tegra_dma_channel *ch = &dma_channels[i];
>
> - ? ? ? ? ? ? ? __clear_bit(i, channel_usage);
> -
> ? ? ? ? ? ? ? ?ch->id = i;
> ? ? ? ? ? ? ? ?snprintf(ch->name, TEGRA_DMA_NAME_SIZE, "dma_channel_%d", i);
>
> @@ -726,14 +722,15 @@ int __init tegra_dma_init(void)
> ? ? ? ? ? ? ? ? ? ? ? ?goto fail;
> ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ? ? ?ch->irq = irq;
> +
> + ? ? ? ? ? ? ? __clear_bit(i, channel_usage);
> ? ? ? ?}
> ? ? ? ?/* mark the shared channel allocated */
> ? ? ? ?__set_bit(TEGRA_SYSTEM_DMA_CH_MIN, channel_usage);
>
> - ? ? ? for (i = TEGRA_SYSTEM_DMA_CH_MAX+1; i < NV_DMA_MAX_CHANNELS; i++)
> - ? ? ? ? ? ? ? __set_bit(i, channel_usage);
> + ? ? ? initialized = 1;
intialized = true
>
> - ? ? ? return ret;
> + ? ? ? return 0;
> ?fail:
> ? ? ? ?writel(0, addr + APB_DMA_GEN);
> ? ? ? ?for (i = TEGRA_SYSTEM_DMA_CH_MIN; i <= TEGRA_SYSTEM_DMA_CH_MAX; i++) {
> --
> 1.7.1
>
>
^ permalink raw reply
* [PATCH 1/5] ARM: Tegra: Add devices.c entries for audio
From: Colin Cross @ 2011-02-23 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298487532-5000-2-git-send-email-swarren@nvidia.com>
On Wed, Feb 23, 2011 at 10:58 AM, Stephen Warren <swarren@nvidia.com> wrote:
> For I2S, DAS, PCM devices
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
> NOTE: This patch will not apply until Olof's recently posted
> boards-for-next branch is merged.
>
> ?arch/arm/mach-tegra/devices.c ? ? ? ? ? ?| ? 70 ++++++++++++++++++++++++++++++
> ?arch/arm/mach-tegra/devices.h ? ? ? ? ? ?| ? ?4 ++
> ?arch/arm/mach-tegra/include/mach/iomap.h | ? ?3 +
> ?3 files changed, 77 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-tegra/devices.c b/arch/arm/mach-tegra/devices.c
> index 682e6d3..1528f9d 100644
> --- a/arch/arm/mach-tegra/devices.c
> +++ b/arch/arm/mach-tegra/devices.c
> @@ -503,3 +503,73 @@ struct platform_device tegra_uarte_device = {
> ? ? ? ? ? ? ? ?.coherent_dma_mask ? ? ?= DMA_BIT_MASK(32),
> ? ? ? ?},
> ?};
> +
> +static struct resource i2s_resource1[] = {
> + ? ? ? [0] = {
> + ? ? ? ? ? ? ? .start ?= INT_I2S1,
> + ? ? ? ? ? ? ? .end ? ?= INT_I2S1,
> + ? ? ? ? ? ? ? .flags ?= IORESOURCE_IRQ
> + ? ? ? },
> + ? ? ? [1] = {
> + ? ? ? ? ? ? ? .start ?= TEGRA_DMA_REQ_SEL_I2S_1,
> + ? ? ? ? ? ? ? .end ? ?= TEGRA_DMA_REQ_SEL_I2S_1,
> + ? ? ? ? ? ? ? .flags ?= IORESOURCE_DMA
> + ? ? ? },
> + ? ? ? [2] = {
> + ? ? ? ? ? ? ? .start ?= TEGRA_I2S1_BASE,
> + ? ? ? ? ? ? ? .end ? ?= TEGRA_I2S1_BASE + TEGRA_I2S1_SIZE - 1,
> + ? ? ? ? ? ? ? .flags ?= IORESOURCE_MEM
> + ? ? ? }
> +};
> +
> +static struct resource i2s_resource2[] = {
> + ? ? ? [0] = {
> + ? ? ? ? ? ? ? .start ?= INT_I2S2,
> + ? ? ? ? ? ? ? .end ? ?= INT_I2S2,
> + ? ? ? ? ? ? ? .flags ?= IORESOURCE_IRQ
> + ? ? ? },
> + ? ? ? [1] = {
> + ? ? ? ? ? ? ? .start ?= TEGRA_DMA_REQ_SEL_I2S2_1,
> + ? ? ? ? ? ? ? .end ? ?= TEGRA_DMA_REQ_SEL_I2S2_1,
> + ? ? ? ? ? ? ? .flags ?= IORESOURCE_DMA
> + ? ? ? },
> + ? ? ? [2] = {
> + ? ? ? ? ? ? ? .start ?= TEGRA_I2S2_BASE,
> + ? ? ? ? ? ? ? .end ? ?= TEGRA_I2S2_BASE + TEGRA_I2S2_SIZE - 1,
> + ? ? ? ? ? ? ? .flags ?= IORESOURCE_MEM
> + ? ? ? }
> +};
> +
> +struct platform_device tegra_i2s_device1 = {
> + ? ? ? .name ? ? ? ? ? = "tegra-i2s",
> + ? ? ? .id ? ? ? ? ? ? = 0,
> + ? ? ? .resource ? ? ? = i2s_resource1,
> + ? ? ? .num_resources ?= ARRAY_SIZE(i2s_resource1),
> +};
> +
> +struct platform_device tegra_i2s_device2 = {
> + ? ? ? .name ? ? ? ? ? = "tegra-i2s",
> + ? ? ? .id ? ? ? ? ? ? = 1,
> + ? ? ? .resource ? ? ? = i2s_resource2,
> + ? ? ? .num_resources ?= ARRAY_SIZE(i2s_resource2),
> +};
> +
> +static struct resource tegra_das_resources[] = {
> + ? ? ? [0] = {
> + ? ? ? ? ? ? ? .start = TEGRA_APB_MISC_DAS_BASE,
> + ? ? ? ? ? ? ? .end = TEGRA_APB_MISC_DAS_BASE + TEGRA_APB_MISC_DAS_SIZE - 1,
> + ? ? ? ? ? ? ? .flags = IORESOURCE_MEM,
> + ? ? ? },
> +};
> +
> +struct platform_device tegra_das_device = {
> + ? ? ? .name ? ? ? ? ? = "tegra-das",
> + ? ? ? .id ? ? ? ? ? ? = -1,
> + ? ? ? .num_resources ?= ARRAY_SIZE(tegra_das_resources),
> + ? ? ? .resource ? ? ? = tegra_das_resources,
> +};
> +
> +struct platform_device tegra_pcm_device = {
> + ? ? ? .name = "tegra-pcm-audio",
> + ? ? ? .id = -1,
> +};
> diff --git a/arch/arm/mach-tegra/devices.h b/arch/arm/mach-tegra/devices.h
> index 888810c..4a7dc0a 100644
> --- a/arch/arm/mach-tegra/devices.h
> +++ b/arch/arm/mach-tegra/devices.h
> @@ -42,5 +42,9 @@ extern struct platform_device tegra_uartc_device;
> ?extern struct platform_device tegra_uartd_device;
> ?extern struct platform_device tegra_uarte_device;
> ?extern struct platform_device tegra_pmu_device;
> +extern struct platform_device tegra_i2s_device1;
> +extern struct platform_device tegra_i2s_device2;
> +extern struct platform_device tegra_das_device;
> +extern struct platform_device tegra_pcm_device;
>
> ?#endif
> diff --git a/arch/arm/mach-tegra/include/mach/iomap.h b/arch/arm/mach-tegra/include/mach/iomap.h
> index 691cdab..19dec3a 100644
> --- a/arch/arm/mach-tegra/include/mach/iomap.h
> +++ b/arch/arm/mach-tegra/include/mach/iomap.h
> @@ -122,6 +122,9 @@
> ?#define TEGRA_APB_MISC_BASE ? ? ? ? ? ?0x70000000
> ?#define TEGRA_APB_MISC_SIZE ? ? ? ? ? ?SZ_4K
>
> +#define TEGRA_APB_MISC_DAS_BASE ? ? ? ? ? ? ? ?0x70000c00
> +#define TEGRA_APB_MISC_DAS_SIZE ? ? ? ? ? ? ? ?SZ_128
> +
> ?#define TEGRA_AC97_BASE ? ? ? ? ? ? ? ? ? ? ? ?0x70002000
> ?#define TEGRA_AC97_SIZE ? ? ? ? ? ? ? ? ? ? ? ?SZ_512
Acked-by: Colin Cross <ccross@android.com>
^ permalink raw reply
* [PATCH 2/5] ARM: Tegra: Rename I2S clocks to match driver name
From: Colin Cross @ 2011-02-23 21:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298487532-5000-3-git-send-email-swarren@nvidia.com>
On Wed, Feb 23, 2011 at 10:58 AM, Stephen Warren <swarren@nvidia.com> wrote:
> The driver is tegra-i2s not just i2s. Rename the clocks to match, so that
> clk_get_sys can look up by driver name.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
> NOTE: This patch should apply right now.
>
> ?arch/arm/mach-tegra/tegra2_clocks.c | ? ?4 ++--
> ?1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-tegra/tegra2_clocks.c b/arch/arm/mach-tegra/tegra2_clocks.c
> index 3015a2c..ee3f9d7 100644
> --- a/arch/arm/mach-tegra/tegra2_clocks.c
> +++ b/arch/arm/mach-tegra/tegra2_clocks.c
> @@ -2128,8 +2128,8 @@ struct clk tegra_list_clks[] = {
> ? ? ? ?PERIPH_CLK("apbdma", ? ?"tegra-dma", ? ? ? ? ? ?NULL, ? 34, ? ? 0, ? ? ?108000000, mux_pclk, ? ? ? ? ? ? ? ? ? ?0),
> ? ? ? ?PERIPH_CLK("rtc", ? ? ? "rtc-tegra", ? ? ? ? ? ?NULL, ? 4, ? ? ?0, ? ? ?32768, ? ? mux_clk_32k, ? ? ? ? ? ? ? ? PERIPH_NO_RESET),
> ? ? ? ?PERIPH_CLK("timer", ? ? "timer", ? ? ? ? ? ? ? ?NULL, ? 5, ? ? ?0, ? ? ?26000000, ?mux_clk_m, ? ? ? ? ? ? ? ? ? 0),
> - ? ? ? PERIPH_CLK("i2s1", ? ? ?"i2s.0", ? ? ? ? ? ? ? ?NULL, ? 11, ? ? 0x100, ?26000000, ?mux_pllaout0_audio2x_pllp_clkm, ? ? ?MUX | DIV_U71),
> - ? ? ? PERIPH_CLK("i2s2", ? ? ?"i2s.1", ? ? ? ? ? ? ? ?NULL, ? 18, ? ? 0x104, ?26000000, ?mux_pllaout0_audio2x_pllp_clkm, ? ? ?MUX | DIV_U71),
> + ? ? ? PERIPH_CLK("i2s1", ? ? ?"tegra-i2s.0", ? ? ? ? ?NULL, ? 11, ? ? 0x100, ?26000000, ?mux_pllaout0_audio2x_pllp_clkm, ? ? ?MUX | DIV_U71),
> + ? ? ? PERIPH_CLK("i2s2", ? ? ?"tegra-i2s.1", ? ? ? ? ?NULL, ? 18, ? ? 0x104, ?26000000, ?mux_pllaout0_audio2x_pllp_clkm, ? ? ?MUX | DIV_U71),
> ? ? ? ?PERIPH_CLK("spdif_out", "spdif_out", ? ? ? ? ? ?NULL, ? 10, ? ? 0x108, ?100000000, mux_pllaout0_audio2x_pllp_clkm, ? ? ?MUX | DIV_U71),
> ? ? ? ?PERIPH_CLK("spdif_in", ?"spdif_in", ? ? ? ? ? ? NULL, ? 10, ? ? 0x10c, ?100000000, mux_pllp_pllc_pllm, ? ? ? ? ?MUX | DIV_U71),
> ? ? ? ?PERIPH_CLK("pwm", ? ? ? "pwm", ? ? ? ? ? ? ? ? ?NULL, ? 17, ? ? 0x110, ?432000000, mux_pllp_pllc_audio_clkm_clk32, ? ? ?MUX | DIV_U71),
> --
> 1.7.1
>
>
Ack, I'll put it in for-next
^ permalink raw reply
* [PATCH 3/5] ARM: Tegra: Rename clk_dev1/2 to cdev1/2
From: Colin Cross @ 2011-02-23 21:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298487532-5000-4-git-send-email-swarren@nvidia.com>
On Wed, Feb 23, 2011 at 10:58 AM, Stephen Warren <swarren@nvidia.com> wrote:
> The ASoC machine driver was written assuming my previous patch to add
> complete support for these clocks, which named them cdev1/2. Rename
> the clocks to match that, to avoid churn in the ASoC driver.
>
> This rename also makes the clocks more consistent with other Tegra
> clocks irrespective of any of that.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
> NOTE: This patch should apply right now.
>
> ?arch/arm/mach-tegra/tegra2_clocks.c | ? 12 ++++++------
> ?1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-tegra/tegra2_clocks.c b/arch/arm/mach-tegra/tegra2_clocks.c
> index ee3f9d7..6d7c4ee 100644
> --- a/arch/arm/mach-tegra/tegra2_clocks.c
> +++ b/arch/arm/mach-tegra/tegra2_clocks.c
> @@ -1823,8 +1823,8 @@ static struct clk tegra_clk_d = {
> ?};
>
> ?/* dap_mclk1, belongs to the cdev1 pingroup. */
> -static struct clk tegra_dev1_clk = {
> - ? ? ? .name ? ? ?= "clk_dev1",
> +static struct clk tegra_clk_cdev1 = {
> + ? ? ? .name ? ? ?= "cdev1",
> ? ? ? ?.ops ? ? ? = &tegra_cdev_clk_ops,
> ? ? ? ?.rate ? ? ?= 26000000,
> ? ? ? ?.max_rate ?= 26000000,
> @@ -1834,8 +1834,8 @@ static struct clk tegra_dev1_clk = {
> ?};
>
> ?/* dap_mclk2, belongs to the cdev2 pingroup. */
> -static struct clk tegra_dev2_clk = {
> - ? ? ? .name ? ? ?= "clk_dev2",
> +static struct clk tegra_clk_cdev2 = {
> + ? ? ? .name ? ? ?= "cdev2",
> ? ? ? ?.ops ? ? ? = &tegra_cdev_clk_ops,
> ? ? ? ?.rate ? ? ?= 26000000,
> ? ? ? ?.max_rate ?= 26000000,
> @@ -2276,8 +2276,8 @@ struct clk *tegra_ptr_clks[] = {
> ? ? ? ?&tegra_clk_hclk,
> ? ? ? ?&tegra_clk_pclk,
> ? ? ? ?&tegra_clk_d,
> - ? ? ? &tegra_dev1_clk,
> - ? ? ? &tegra_dev2_clk,
> + ? ? ? &tegra_clk_cdev1,
> + ? ? ? &tegra_clk_cdev2,
> ? ? ? ?&tegra_clk_virtual_cpu,
> ? ? ? ?&tegra_clk_blink,
> ? ? ? ?&tegra_clk_cop,
> --
> 1.7.1
>
>
Ack, I'll put it in for-next
^ permalink raw reply
* [PATCH 5/5] ARM: Tegra: Enable Harmony audio support
From: Colin Cross @ 2011-02-23 21:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298487532-5000-6-git-send-email-swarren@nvidia.com>
On Wed, Feb 23, 2011 at 10:58 AM, Stephen Warren <swarren@nvidia.com> wrote:
> * Set up platform data required by I2C, and ASoC machine & codec drivers.
> * Enable required GPIO pins as GPIOs.
> * Initialize audio-related clocks.
> * Correctly configure pinmux for audio-related GPIOs.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> ---
> NOTE: This patch will not apply until Olof's recently posted
> boards-for-next branch is merged.
>
> NOTE: This patch will not apply until the following two commits are
> present in Tegra for-next:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git
> 7cfe56172ac14d2031f1896ecb629033f71caafa
> ASoC: wm8903: Expose GPIOs through gpiolib
> Mark said he'd be OK with this being cherry-picked into the Tegra tree.
>
> git://git.fluff.org/bjdooks/linux.git
> db811ca0f48578f9940f49f284ac81e336b264ad
> i2c: tegra: Add i2c support
> Ben hasn't been asked whether a cherry-pick is OK. We could ask, or simply
> wait for the merge window to be open, Linus' tree to pick this change up,
> Tegra for-next to be rebased on Linus' tree, and then apply the patch below.
>
> Note: I manually tested cherry-picking both those changes into Tegra for-next,
> merging Olof's branch, and applying this patch series. The build succeeded,
> and Harmony booted to a shell prompt.
>
> ?arch/arm/mach-tegra/board-harmony-pinmux.c | ? 16 +++++---
> ?arch/arm/mach-tegra/board-harmony.c ? ? ? ?| ? 58 ++++++++++++++++++++++++++++
> ?arch/arm/mach-tegra/board-harmony.h ? ? ? ?| ? ?7 +++
> ?3 files changed, 75 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-tegra/board-harmony-pinmux.c b/arch/arm/mach-tegra/board-harmony-pinmux.c
> index 3ada474..4d63e2e 100644
> --- a/arch/arm/mach-tegra/board-harmony-pinmux.c
> +++ b/arch/arm/mach-tegra/board-harmony-pinmux.c
> @@ -27,11 +27,11 @@ static struct tegra_pingroup_config harmony_pinmux[] = {
> ? ? ? ?{TEGRA_PINGROUP_ATC, ? TEGRA_MUX_NAND, ? ? ? ? ?TEGRA_PUPD_NORMAL, ? ?TEGRA_TRI_NORMAL},
> ? ? ? ?{TEGRA_PINGROUP_ATD, ? TEGRA_MUX_GMI, ? ? ? ? ? TEGRA_PUPD_NORMAL, ? ?TEGRA_TRI_NORMAL},
> ? ? ? ?{TEGRA_PINGROUP_ATE, ? TEGRA_MUX_GMI, ? ? ? ? ? TEGRA_PUPD_NORMAL, ? ?TEGRA_TRI_NORMAL},
> - ? ? ? {TEGRA_PINGROUP_CDEV1, TEGRA_MUX_OSC, ? ? ? ? ? TEGRA_PUPD_PULL_DOWN, TEGRA_TRI_TRISTATE},
> + ? ? ? {TEGRA_PINGROUP_CDEV1, TEGRA_MUX_PLLA_OUT, ? ? ?TEGRA_PUPD_NORMAL, ? ?TEGRA_TRI_NORMAL},
> ? ? ? ?{TEGRA_PINGROUP_CDEV2, TEGRA_MUX_PLLP_OUT4, ? ? TEGRA_PUPD_PULL_DOWN, TEGRA_TRI_TRISTATE},
> ? ? ? ?{TEGRA_PINGROUP_CRTP, ?TEGRA_MUX_CRT, ? ? ? ? ? TEGRA_PUPD_NORMAL, ? ?TEGRA_TRI_TRISTATE},
> ? ? ? ?{TEGRA_PINGROUP_CSUS, ?TEGRA_MUX_VI_SENSOR_CLK, TEGRA_PUPD_PULL_DOWN, TEGRA_TRI_TRISTATE},
> - ? ? ? {TEGRA_PINGROUP_DAP1, ?TEGRA_MUX_DAP1, ? ? ? ? ?TEGRA_PUPD_NORMAL, ? ?TEGRA_TRI_TRISTATE},
> + ? ? ? {TEGRA_PINGROUP_DAP1, ?TEGRA_MUX_DAP1, ? ? ? ? ?TEGRA_PUPD_NORMAL, ? ?TEGRA_TRI_NORMAL},
> ? ? ? ?{TEGRA_PINGROUP_DAP2, ?TEGRA_MUX_DAP2, ? ? ? ? ?TEGRA_PUPD_NORMAL, ? ?TEGRA_TRI_TRISTATE},
> ? ? ? ?{TEGRA_PINGROUP_DAP3, ?TEGRA_MUX_DAP3, ? ? ? ? ?TEGRA_PUPD_NORMAL, ? ?TEGRA_TRI_TRISTATE},
> ? ? ? ?{TEGRA_PINGROUP_DAP4, ?TEGRA_MUX_DAP4, ? ? ? ? ?TEGRA_PUPD_NORMAL, ? ?TEGRA_TRI_TRISTATE},
> @@ -114,13 +114,13 @@ static struct tegra_pingroup_config harmony_pinmux[] = {
> ? ? ? ?{TEGRA_PINGROUP_SLXK, ?TEGRA_MUX_PCIE, ? ? ? ? ?TEGRA_PUPD_NORMAL, ? ?TEGRA_TRI_TRISTATE},
> ? ? ? ?{TEGRA_PINGROUP_SPDI, ?TEGRA_MUX_RSVD2, ? ? ? ? TEGRA_PUPD_NORMAL, ? ?TEGRA_TRI_TRISTATE},
> ? ? ? ?{TEGRA_PINGROUP_SPDO, ?TEGRA_MUX_RSVD2, ? ? ? ? TEGRA_PUPD_NORMAL, ? ?TEGRA_TRI_TRISTATE},
> - ? ? ? {TEGRA_PINGROUP_SPIA, ?TEGRA_MUX_GMI, ? ? ? ? ? TEGRA_PUPD_PULL_DOWN, TEGRA_TRI_TRISTATE},
> - ? ? ? {TEGRA_PINGROUP_SPIB, ?TEGRA_MUX_GMI, ? ? ? ? ? TEGRA_PUPD_PULL_DOWN, TEGRA_TRI_TRISTATE},
> - ? ? ? {TEGRA_PINGROUP_SPIC, ?TEGRA_MUX_GMI, ? ? ? ? ? TEGRA_PUPD_PULL_UP, ? TEGRA_TRI_NORMAL},
> + ? ? ? {TEGRA_PINGROUP_SPIA, ?TEGRA_MUX_GMI, ? ? ? ? ? TEGRA_PUPD_NORMAL, ? ?TEGRA_TRI_NORMAL},
> + ? ? ? {TEGRA_PINGROUP_SPIB, ?TEGRA_MUX_GMI, ? ? ? ? ? TEGRA_PUPD_NORMAL, ? ?TEGRA_TRI_NORMAL},
> + ? ? ? {TEGRA_PINGROUP_SPIC, ?TEGRA_MUX_GMI, ? ? ? ? ? TEGRA_PUPD_PULL_UP, ? TEGRA_TRI_TRISTATE},
> ? ? ? ?{TEGRA_PINGROUP_SPID, ?TEGRA_MUX_SPI1, ? ? ? ? ?TEGRA_PUPD_PULL_DOWN, TEGRA_TRI_TRISTATE},
> ? ? ? ?{TEGRA_PINGROUP_SPIE, ?TEGRA_MUX_SPI1, ? ? ? ? ?TEGRA_PUPD_PULL_UP, ? TEGRA_TRI_TRISTATE},
> ? ? ? ?{TEGRA_PINGROUP_SPIF, ?TEGRA_MUX_SPI1, ? ? ? ? ?TEGRA_PUPD_PULL_DOWN, TEGRA_TRI_TRISTATE},
> - ? ? ? {TEGRA_PINGROUP_SPIG, ?TEGRA_MUX_SPI2_ALT, ? ? ?TEGRA_PUPD_PULL_UP, ? TEGRA_TRI_TRISTATE},
> + ? ? ? {TEGRA_PINGROUP_SPIG, ?TEGRA_MUX_SPI2_ALT, ? ? ?TEGRA_PUPD_NORMAL, ? ?TEGRA_TRI_TRISTATE},
> ? ? ? ?{TEGRA_PINGROUP_SPIH, ?TEGRA_MUX_SPI2_ALT, ? ? ?TEGRA_PUPD_PULL_UP, ? TEGRA_TRI_TRISTATE},
> ? ? ? ?{TEGRA_PINGROUP_UAA, ? TEGRA_MUX_ULPI, ? ? ? ? ?TEGRA_PUPD_PULL_UP, ? TEGRA_TRI_TRISTATE},
> ? ? ? ?{TEGRA_PINGROUP_UAB, ? TEGRA_MUX_ULPI, ? ? ? ? ?TEGRA_PUPD_PULL_UP, ? TEGRA_TRI_TRISTATE},
> @@ -147,6 +147,10 @@ static struct tegra_gpio_table gpio_table[] = {
> ? ? ? ?{ .gpio = TEGRA_GPIO_SD4_CD, ? ? ? ? ? ?.enable = true ?},
> ? ? ? ?{ .gpio = TEGRA_GPIO_SD4_WP, ? ? ? ? ? ?.enable = true ?},
> ? ? ? ?{ .gpio = TEGRA_GPIO_SD4_POWER, ? ? ? ? .enable = true ?},
> + ? ? ? { .gpio = TEGRA_GPIO_CDC_IRQ, ? ? ? ? ? .enable = true ?},
> + ? ? ? { .gpio = TEGRA_GPIO_HP_DET, ? ? ? ? ? ?.enable = true ?},
> + ? ? ? { .gpio = TEGRA_GPIO_INT_MIC_EN, ? ? ? ?.enable = true ?},
> + ? ? ? { .gpio = TEGRA_GPIO_EXT_MIC_EN, ? ? ? ?.enable = true ?},
> ?};
>
> ?void harmony_pinmux_init(void)
> diff --git a/arch/arm/mach-tegra/board-harmony.c b/arch/arm/mach-tegra/board-harmony.c
> index 2c4a234..afa4b5e 100644
> --- a/arch/arm/mach-tegra/board-harmony.c
> +++ b/arch/arm/mach-tegra/board-harmony.c
> @@ -2,6 +2,7 @@
> ?* arch/arm/mach-tegra/board-harmony.c
> ?*
> ?* Copyright (C) 2010 Google, Inc.
> + * Copyright (C) 2011 NVIDIA, Inc.
> ?*
> ?* This software is licensed under the terms of the GNU General Public
> ?* License version 2, as published by the Free Software Foundation, and
> @@ -21,13 +22,19 @@
> ?#include <linux/clk.h>
> ?#include <linux/dma-mapping.h>
> ?#include <linux/pda_power.h>
> +#include <linux/i2c.h>
> +#include <linux/i2c-tegra.h>
> ?#include <linux/io.h>
>
> +#include <sound/wm8903.h>
> +
> ?#include <asm/mach-types.h>
> ?#include <asm/mach/arch.h>
> ?#include <asm/mach/time.h>
> ?#include <asm/setup.h>
>
> +#include <mach/gpio.h>
> +#include <mach/harmony_audio.h>
> ?#include <mach/iomap.h>
> ?#include <mach/irqs.h>
> ?#include <mach/sdhci.h>
> @@ -60,11 +67,31 @@ static struct platform_device debug_uart = {
> ? ? ? ?},
> ?};
>
> +static struct harmony_audio_platform_data harmony_audio_pdata = {
> + ? ? ? .gpio_spkr_en ? ? ? ? ? = TEGRA_GPIO_SPKR_EN,
> + ? ? ? .gpio_hp_det ? ? ? ? ? ?= TEGRA_GPIO_HP_DET,
> + ? ? ? .gpio_int_mic_en ? ? ? ?= TEGRA_GPIO_INT_MIC_EN,
> + ? ? ? .gpio_ext_mic_en ? ? ? ?= TEGRA_GPIO_EXT_MIC_EN,
> +};
> +
> +static struct platform_device harmony_audio_device = {
> + ? ? ? .name ? = "tegra-snd-harmony",
> + ? ? ? .id ? ? = 0,
> + ? ? ? .dev ? ?= {
> + ? ? ? ? ? ? ? .platform_data ?= &harmony_audio_pdata,
> + ? ? ? },
> +};
> +
> ?static struct platform_device *harmony_devices[] __initdata = {
> ? ? ? ?&debug_uart,
> ? ? ? ?&tegra_sdhci_device1,
> ? ? ? ?&tegra_sdhci_device2,
> ? ? ? ?&tegra_sdhci_device4,
> + ? ? ? &tegra_i2c_device1,
> + ? ? ? &tegra_i2s_device1,
> + ? ? ? &tegra_das_device,
> + ? ? ? &tegra_pcm_device,
> + ? ? ? &harmony_audio_device,
> ?};
>
> ?static void __init tegra_harmony_fixup(struct machine_desc *desc,
> @@ -80,6 +107,10 @@ static void __init tegra_harmony_fixup(struct machine_desc *desc,
> ?static __initdata struct tegra_clk_init_table harmony_clk_init_table[] = {
> ? ? ? ?/* name ? ? ? ? parent ? ? ? ? ?rate ? ? ? ? ? ?enabled */
> ? ? ? ?{ "uartd", ? ? ?"pll_p", ? ? ? ?216000000, ? ? ?true },
> + ? ? ? { "pll_a", ? ? ?"pll_p_out1", ? 56448000, ? ? ? true },
> + ? ? ? { "pll_a_out0", "pll_a", ? ? ? ?11289600, ? ? ? true },
> + ? ? ? { "cdev1", ? ? ?NULL, ? ? ? ? ? 0, ? ? ? ? ? ? ?true },
> + ? ? ? { "i2s1", ? ? ? "pll_a_out0", ? 11289600, ? ? ? false},
> ? ? ? ?{ NULL, ? ? ? ? NULL, ? ? ? ? ? 0, ? ? ? ? ? ? ?0},
> ?};
>
> @@ -103,6 +134,30 @@ static struct tegra_sdhci_platform_data sdhci_pdata4 = {
> ? ? ? ?.is_8bit ? ? ? ?= 1,
> ?};
>
> +static struct tegra_i2c_platform_data i2c_pdata1 = {
> + ? ? ? .bus_clk_rate = 400000,
> +};
> +
> +static struct wm8903_platform_data harmony_wm8903_pdata = {
> + ? ? ? .irq_active_low = 0,
> + ? ? ? .micdet_cfg = 0,
> + ? ? ? .micdet_delay = 100,
> + ? ? ? .gpio_base = GPIO_WM8903(0),
> + ? ? ? .gpio_cfg = {
> + ? ? ? ? ? ? ? WM8903_GPIO_NO_CONFIG,
> + ? ? ? ? ? ? ? WM8903_GPIO_NO_CONFIG,
> + ? ? ? ? ? ? ? 0,
> + ? ? ? ? ? ? ? WM8903_GPIO_NO_CONFIG,
> + ? ? ? ? ? ? ? WM8903_GPIO_NO_CONFIG,
> + ? ? ? },
> +};
> +
> +static struct i2c_board_info __initdata wm8903_board_info = {
> + ? ? ? I2C_BOARD_INFO("wm8903", 0x1a),
> + ? ? ? .platform_data = &harmony_wm8903_pdata,
> + ? ? ? .irq = TEGRA_GPIO_TO_IRQ(TEGRA_GPIO_CDC_IRQ),
> +};
> +
> ?static void __init tegra_harmony_init(void)
> ?{
> ? ? ? ?tegra_clk_init_from_table(harmony_clk_init_table);
> @@ -112,8 +167,11 @@ static void __init tegra_harmony_init(void)
> ? ? ? ?tegra_sdhci_device1.dev.platform_data = &sdhci_pdata1;
> ? ? ? ?tegra_sdhci_device2.dev.platform_data = &sdhci_pdata2;
> ? ? ? ?tegra_sdhci_device4.dev.platform_data = &sdhci_pdata4;
> + ? ? ? tegra_i2c_device1.dev.platform_data = &i2c_pdata1;
>
> ? ? ? ?platform_add_devices(harmony_devices, ARRAY_SIZE(harmony_devices));
> +
> + ? ? ? i2c_register_board_info(0, &wm8903_board_info, 1);
> ?}
>
> ?MACHINE_START(HARMONY, "harmony")
> diff --git a/arch/arm/mach-tegra/board-harmony.h b/arch/arm/mach-tegra/board-harmony.h
> index 4fe33b8..fbf2304 100644
> --- a/arch/arm/mach-tegra/board-harmony.h
> +++ b/arch/arm/mach-tegra/board-harmony.h
> @@ -17,12 +17,19 @@
> ?#ifndef _MACH_TEGRA_BOARD_HARMONY_H
> ?#define _MACH_TEGRA_BOARD_HARMONY_H
>
> +#define GPIO_WM8903(_x_) ? ? ? ? ? ? ? (TEGRA_NR_GPIOS + (_x_))
Can you name this HARMONY_GPIO_WM8903?
> +
> ?#define TEGRA_GPIO_SD2_CD ? ? ? ? ? ? ?TEGRA_GPIO_PI5
> ?#define TEGRA_GPIO_SD2_WP ? ? ? ? ? ? ?TEGRA_GPIO_PH1
> ?#define TEGRA_GPIO_SD2_POWER ? ? ? ? ? TEGRA_GPIO_PT3
> ?#define TEGRA_GPIO_SD4_CD ? ? ? ? ? ? ?TEGRA_GPIO_PH2
> ?#define TEGRA_GPIO_SD4_WP ? ? ? ? ? ? ?TEGRA_GPIO_PH3
> ?#define TEGRA_GPIO_SD4_POWER ? ? ? ? ? TEGRA_GPIO_PI6
> +#define TEGRA_GPIO_CDC_IRQ ? ? ? ? ? ? TEGRA_GPIO_PX3
> +#define TEGRA_GPIO_SPKR_EN ? ? ? ? ? ? GPIO_WM8903(2)
> +#define TEGRA_GPIO_HP_DET ? ? ? ? ? ? ?TEGRA_GPIO_PW2
> +#define TEGRA_GPIO_INT_MIC_EN ? ? ? ? ?TEGRA_GPIO_PX0
> +#define TEGRA_GPIO_EXT_MIC_EN ? ? ? ? ?TEGRA_GPIO_PX1
>
> ?void harmony_pinmux_init(void);
>
> --
> 1.7.1
>
>
^ permalink raw reply
* [PATCH 5/5] ARM: Tegra: Enable Harmony audio support
From: Olof Johansson @ 2011-02-23 21:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298487532-5000-6-git-send-email-swarren@nvidia.com>
Stephen,
Since this depends on i2c, and registers one of the adapters to do it,
we should just get the adapters registered separately (all of them)
before this. I was holding off that part of board code since the i2c
driver went up that maintainer path instead, but if Colin pulls it
into tegra for-next, then I'll go ahead with those peices as well.
I'll pick up the board-side patches from this series (1, 4, 5), and
Colin will take the core patches (2, 3).
On Wed, Feb 23, 2011 at 10:58 AM, Stephen Warren <swarren@nvidia.com> wrote:
> +static struct wm8903_platform_data harmony_wm8903_pdata = {
> + ? ? ? .irq_active_low = 0,
> + ? ? ? .micdet_cfg = 0,
> + ? ? ? .micdet_delay = 100,
> + ? ? ? .gpio_base = GPIO_WM8903(0),
> + ? ? ? .gpio_cfg = {
> + ? ? ? ? ? ? ? WM8903_GPIO_NO_CONFIG,
> + ? ? ? ? ? ? ? WM8903_GPIO_NO_CONFIG,
> + ? ? ? ? ? ? ? 0,
> + ? ? ? ? ? ? ? WM8903_GPIO_NO_CONFIG,
> + ? ? ? ? ? ? ? WM8903_GPIO_NO_CONFIG,
> + ? ? ? },
> +};
[...]
> diff --git a/arch/arm/mach-tegra/board-harmony.h b/arch/arm/mach-tegra/board-harmony.h
> index 4fe33b8..fbf2304 100644
> --- a/arch/arm/mach-tegra/board-harmony.h
> +++ b/arch/arm/mach-tegra/board-harmony.h
> @@ -17,12 +17,19 @@
> ?#ifndef _MACH_TEGRA_BOARD_HARMONY_H
> ?#define _MACH_TEGRA_BOARD_HARMONY_H
>
> +#define GPIO_WM8903(_x_) ? ? ? ? ? ? ? (TEGRA_NR_GPIOS + (_x_))
The above assumes that wm8903 is the GPIO controller that gets
allocated the numbers right after native tegra gpio. That might not be
the case on all boards, since the TPS PMIC has some as well, I
believe.
Does it need a hardcoded GPIO base, or can it use the dynamic one
(i.e. use -1 here)? I don't even see any reference to gpio_base in the
driver...
-Olof
^ permalink raw reply
* [PATCH v3 2/2] OMAP: IOMMU: add support to callback during fault handling
From: Guzman Lugo, Fernando @ 2011-02-23 21:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=+rzHDB_hGzGtZKNZB02z4v65GAD-87zVpOdni@mail.gmail.com>
On Wed, Feb 23, 2011 at 1:54 PM, David Cohen <dacohen@gmail.com> wrote:
> On Wed, Feb 23, 2011 at 3:39 PM, Guzman Lugo, Fernando
> <fernando.lugo@ti.com> wrote:
>> On Wed, Feb 23, 2011 at 3:45 AM, David Cohen <dacohen@gmail.com> wrote:
>>> On Wed, Feb 23, 2011 at 3:17 AM, Guzman Lugo, Fernando
>>> <fernando.lugo@ti.com> wrote:
>>>> On Wed, Feb 16, 2011 at 1:35 PM, David Cohen <dacohen@gmail.com> wrote:
>>>>> Add support to register an isr for IOMMU fault situations and adapt it
>>>>> to allow such (*isr)() to be used as fault callback. Drivers using IOMMU
>>>>> module might want to be informed when errors happen in order to debug it
>>>>> or react.
>>>>>
>>>>> Signed-off-by: David Cohen <dacohen@gmail.com>
>>>>> ---
>>>>> ?arch/arm/mach-omap2/iommu2.c ? ? ? ? ? ?| ? 17 +++++++++-
>>>>> ?arch/arm/plat-omap/include/plat/iommu.h | ? 14 ++++++++-
>>>>> ?arch/arm/plat-omap/iommu.c ? ? ? ? ? ? ?| ? 52 ++++++++++++++++++++++---------
>>>>> ?3 files changed, 65 insertions(+), 18 deletions(-)
>>>>>
>>>> ....
>>>>
>>>>> @@ -917,6 +912,33 @@ void iommu_put(struct iommu *obj)
>>>>> ?}
>>>>> ?EXPORT_SYMBOL_GPL(iommu_put);
>>>>>
>>>>> +int iommu_set_isr(const char *name,
>>>>> + ? ? ? ? ? ? ? ? int (*isr)(struct iommu *obj, u32 da, u32 iommu_errs,
>>>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ?void *priv),
>>>>> + ? ? ? ? ? ? ? ? void *isr_priv)
>>>>> +{
>>>>> + ? ? ? struct device *dev;
>>>>> + ? ? ? struct iommu *obj;
>>>>> +
>>>>
>>>> if the driver support multiple user for the same iommu why can only
>>>> one callback be registered? should it support register multiple
>>>> callback function (one per user)?
>>>
>>> Can you define a scenario for that?
>>> On OMAP3 ISP the multiple users are the multiple ISP submodule, but I
>>> don't think it's necessary all submodule to have a specific callback.
>>> ISP core layer should handle.
>>
>> Hi,
>>
>> In OMAP4 the cortex M3 is a double core processor and as each core is
>> running they own version of the RTOS we threat them independently. So
>> our driver which controls the remote processor sees two processor but
>> both use the same iommu hw. When a iommu fault happens, at this
>> moment, it is consider as a faltal error and it is no managed to
>> recover and continue, instead a restart of the processor is needed, if
>> the fault happens in core0 we need to reset core1 too and vice versa.
>> if the iommu would support several user callbacks, we can register the
>> callback which resets core0 and also the callback which resets core1
>> and treat them as totally independent processors. Also we have an
>> error event notifier driver, which is only in charge of notifying
>> error events to userspace, so we would have multiple callbacks we
>> could do this
>
> I understood your point. In this case, I may not disagree about having
> more than one callback per obj, although it doesn't seem a nice
> scenario.
> We can have a list of callbacks and call the entire list when a fault
check kernel/notifier.c module and how it is manage in mailbox, so you
can implement something similar.
> happens. But it's necessary to pay attention it will happen in atomic
> context and users should not abuse and register many callbacks. The
> callback should *NOT* print useless messages and must verify the error
> code to not execute useless steps.
Sure, users needs to consider the callback as a ISR and if they need
to do something heavy then schedule a task to do that.
> In this context, callback and ISR cannot share a same pointer anymore.
>
>>
>> iommu <---- register fault callback for error notify driver
>>
>> instead of
>>
>> iommu <--- register fault callback for remote processor driver
>> <----register fault event for error notify driver.
>>
>> with that, we remove one dependency of the errornotify driver.
>
> I don't know very well the errornotify driver, but to bypass it seems
> be a good approach for me.
that driver is not upstream yet, the intention is to have a driver
which can handle many errors, at this moments it is not handle the
errors, but notifying them to userspace. it is thought to be a generic
error handler with the posibility of notify many errors, among them
the iommu fault, so if the error handler driver will notify iommy
fault errors it makes more sense to register with iommu module instead
of doing with other driver which uses iommu module, and that can be
done having multiple callbacks.
>
>>
>> Moreover, the iommu code support serveral users of the same hw iommu,
>> and it does not make sense for me, that you can register only one
>> callback, or if other user register its callback the previous one will
>> be overwritten.
>
> It's quite complex and dangerous this situation, as one driver can
> crash another one.
Yes that can happen, and if you don't have multiple callbacks the
other driver wont even notice it crashed and will try to work
normally. That is not good.
> But I don't think drivers have much choice.
>
> Hiroshi, do you have any different opinion for this subject? I can
> send a v4 version for this patch giving support for multiple callbacks
> per obj.
>
> Br,
>
> David
>
>>
>> Regards,
>> Fernando.
>>
>>>
>>> Br,
>>>
>>> David
>>>
>>>>
>>>> Regards,
>>>> Fernando.
>>>>
>>>
>>
>
^ permalink raw reply
* [alsa-devel] [PATCH 1/3] pxa: Enable pxa-pcm-audio on pxa210/pxa25x platform
From: Liam Girdwood @ 2011-02-23 21:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298417351-24727-1-git-send-email-dbaryshkov@gmail.com>
On Wed, 2011-02-23 at 02:29 +0300, Dmitry Eremin-Solenikov wrote:
> pxa25x platforms were left out of major ASoC Update patch.
> Since f0fba2ad1b a registration of pxa-pcm-audio device is required for
> ASoC to function on pxa platforms. Register one also for pxa210/pxa25x.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> Cc: Eric Miao <eric.y.miao@gmail.com>
> ---
> arch/arm/mach-pxa/pxa25x.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/pxa25x.c b/arch/arm/mach-pxa/pxa25x.c
> index fbc5b77..b166b1d 100644
> --- a/arch/arm/mach-pxa/pxa25x.c
> +++ b/arch/arm/mach-pxa/pxa25x.c
> @@ -347,6 +347,7 @@ static struct platform_device *pxa25x_devices[] __initdata = {
> &pxa25x_device_assp,
> &pxa25x_device_pwm0,
> &pxa25x_device_pwm1,
> + &pxa_device_asoc_platform,
> };
>
> static struct sys_device pxa25x_sysdev[] = {
All
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
^ 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