* Re: [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
From: David Cohen @ 2011-02-15 14:36 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: tony, linux-omap, Hiroshi.DOYU, linux-arm-kernel, Sergei Shtylyov
In-Reply-To: <20110215142923.GC11199@n2100.arm.linux.org.uk>
On Tue, Feb 15, 2011 at 4:29 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Feb 15, 2011 at 04:38:32PM +0300, Sergei Shtylyov wrote:
>>> diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
>>> index 14ee686..4244a07 100644
>>> --- a/arch/arm/mach-omap2/iommu2.c
>>> +++ b/arch/arm/mach-omap2/iommu2.c
>>> @@ -163,13 +163,13 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra)
>>> da = iommu_read_reg(obj, MMU_FAULT_AD);
>>> *ra = da;
>>>
>>> - dev_err(obj->dev, "%s:\tda:%08x ", __func__, da);
>>> + dev_dbg(obj->dev, "%s:\tda:%08x ", __func__, da);
>>
>> Note that dev_dbg() will only print something if either DEBUG or
>> CONFIG_DYNAMIC_DEBUG are defined...
>>
>>>
>>> for (i = 0; i< ARRAY_SIZE(err_msg); i++) {
>>> if (stat & (1<< i))
>>> - printk("%s ", err_msg[i]);
>>> + printk(KERN_DEBUG "%s ", err_msg[i]);
>>
>> ... unlike printk(KERN_DEBUG...). You probably want to use pr_debug() instead.
>
> No - this isn't starting a new line. pr_cont() here.
But pr_cont() would be wrong in case of DEBUG isn't set, isn't it?
>
>>> }
>>> - printk("\n");
>>> + printk(KERN_DEBUG "\n");
>>
>> Here too... Although wait, it should be KERN_CONT instead! Debug
>> levels are only attributed to the whole lines.
>
> And pr_cont() here too. If you care about using KERN_CONT which is
> just a static marker to allow automated printk level checking easier.
The same situation here.
But this patch was dropped in the next version.
Br,
David
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
From: Jarkko Nikula @ 2011-02-15 14:30 UTC (permalink / raw)
To: David Cohen
Cc: tony, linux-omap, Hiroshi.DOYU, linux-arm-kernel, Sergei Shtylyov
In-Reply-To: <AANLkTim3+PFgJUU_-YqOt1M5NkSyHo6wUwF_XwC9MWSP@mail.gmail.com>
On Tue, 15 Feb 2011 16:08:32 +0200
David Cohen <dacohen@gmail.com> wrote:
> > So it's sure that a developer won't need these error dumps when
> > receiving an error report? I.e. IOMMU upper level errors give enough
> > information to start doing own debugging?
>
> Yes, developers do need this information.
> But it's a bit useless tell only we've got an iommu fault, due to many
> places might be causing it. My purpose is to let the debug
> responsibility to IOMMU users. They have access to the iovmm layer as
> well and can provide a much more useful information.
> e.g. OMAP3 ISP has many submodules using IOMMU. With a fault callback,
> it can dump all the iovm areas and the faulty 'da' too. It might
> indicate which submodule was responsible for the issue.
>
> Of course we can just let this debug messages the way they are and
> print this redundant information. But IMO it's not necessary.
>
Sounds fair enough and if I understood correctly this is not something
what end user will hit but more like another developer. In that case
the debug messages are the right thing.
--
Jarkko
^ permalink raw reply
* Re: [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
From: Russell King - ARM Linux @ 2011-02-15 14:29 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: tony, David Cohen, linux-omap, Hiroshi.DOYU, linux-arm-kernel
In-Reply-To: <4D5A81D8.2080800@ru.mvista.com>
On Tue, Feb 15, 2011 at 04:38:32PM +0300, Sergei Shtylyov wrote:
>> diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
>> index 14ee686..4244a07 100644
>> --- a/arch/arm/mach-omap2/iommu2.c
>> +++ b/arch/arm/mach-omap2/iommu2.c
>> @@ -163,13 +163,13 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra)
>> da = iommu_read_reg(obj, MMU_FAULT_AD);
>> *ra = da;
>>
>> - dev_err(obj->dev, "%s:\tda:%08x ", __func__, da);
>> + dev_dbg(obj->dev, "%s:\tda:%08x ", __func__, da);
>
> Note that dev_dbg() will only print something if either DEBUG or
> CONFIG_DYNAMIC_DEBUG are defined...
>
>>
>> for (i = 0; i< ARRAY_SIZE(err_msg); i++) {
>> if (stat & (1<< i))
>> - printk("%s ", err_msg[i]);
>> + printk(KERN_DEBUG "%s ", err_msg[i]);
>
> ... unlike printk(KERN_DEBUG...). You probably want to use pr_debug() instead.
No - this isn't starting a new line. pr_cont() here.
>> }
>> - printk("\n");
>> + printk(KERN_DEBUG "\n");
>
> Here too... Although wait, it should be KERN_CONT instead! Debug
> levels are only attributed to the whole lines.
And pr_cont() here too. If you care about using KERN_CONT which is
just a static marker to allow automated printk level checking easier.
^ permalink raw reply
* Re: [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
From: David Cohen @ 2011-02-15 14:21 UTC (permalink / raw)
To: Jarkko Nikula
Cc: tony, linux-omap, Hiroshi.DOYU, linux-arm-kernel, Sergei Shtylyov
In-Reply-To: <AANLkTim3+PFgJUU_-YqOt1M5NkSyHo6wUwF_XwC9MWSP@mail.gmail.com>
On Tue, Feb 15, 2011 at 4:08 PM, David Cohen <dacohen@gmail.com> wrote:
> On Tue, Feb 15, 2011 at 3:59 PM, Jarkko Nikula <jhnikula@gmail.com> wrote:
>> On Tue, 15 Feb 2011 15:44:27 +0200
>> David Cohen <dacohen@gmail.com> wrote:
>>
>>> >> @@ -163,13 +163,13 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj,
>>> >> u32 *ra)
>>> >> da = iommu_read_reg(obj, MMU_FAULT_AD);
>>> >> *ra = da;
>>> >>
>>> >> - dev_err(obj->dev, "%s:\tda:%08x ", __func__, da);
>>> >> + dev_dbg(obj->dev, "%s:\tda:%08x ", __func__, da);
>>> >
>>> > Note that dev_dbg() will only print something if either DEBUG or
>>> > CONFIG_DYNAMIC_DEBUG are defined...
>>>
>>> That's my plan.
>>>
>> So it's sure that a developer won't need these error dumps when
>> receiving an error report? I.e. IOMMU upper level errors give enough
>> information to start doing own debugging?
>
> Yes, developers do need this information.
> But it's a bit useless tell only we've got an iommu fault, due to many
> places might be causing it. My purpose is to let the debug
> responsibility to IOMMU users. They have access to the iovmm layer as
> well and can provide a much more useful information.
> e.g. OMAP3 ISP has many submodules using IOMMU. With a fault callback,
> it can dump all the iovm areas and the faulty 'da' too. It might
> indicate which submodule was responsible for the issue.
>
> Of course we can just let this debug messages the way they are and
> print this redundant information. But IMO it's not necessary.
Indeed, we can leave this discussion for future. My main purpose now
is the fault callback. I'll drop this patch 1/2 for now.
Regards,
David
>
> Regards,
>
> David
>
>>
>> Just my 2 cents.
>>
>> --
>> Jarkko
>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
From: David Cohen @ 2011-02-15 14:08 UTC (permalink / raw)
To: Jarkko Nikula
Cc: Sergei Shtylyov, tony, linux-omap, Hiroshi.DOYU, linux-arm-kernel
In-Reply-To: <20110215155948.32b564d5.jhnikula@gmail.com>
On Tue, Feb 15, 2011 at 3:59 PM, Jarkko Nikula <jhnikula@gmail.com> wrote:
> On Tue, 15 Feb 2011 15:44:27 +0200
> David Cohen <dacohen@gmail.com> wrote:
>
>> >> @@ -163,13 +163,13 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj,
>> >> u32 *ra)
>> >> da = iommu_read_reg(obj, MMU_FAULT_AD);
>> >> *ra = da;
>> >>
>> >> - dev_err(obj->dev, "%s:\tda:%08x ", __func__, da);
>> >> + dev_dbg(obj->dev, "%s:\tda:%08x ", __func__, da);
>> >
>> > Note that dev_dbg() will only print something if either DEBUG or
>> > CONFIG_DYNAMIC_DEBUG are defined...
>>
>> That's my plan.
>>
> So it's sure that a developer won't need these error dumps when
> receiving an error report? I.e. IOMMU upper level errors give enough
> information to start doing own debugging?
Yes, developers do need this information.
But it's a bit useless tell only we've got an iommu fault, due to many
places might be causing it. My purpose is to let the debug
responsibility to IOMMU users. They have access to the iovmm layer as
well and can provide a much more useful information.
e.g. OMAP3 ISP has many submodules using IOMMU. With a fault callback,
it can dump all the iovm areas and the faulty 'da' too. It might
indicate which submodule was responsible for the issue.
Of course we can just let this debug messages the way they are and
print this redundant information. But IMO it's not necessary.
Regards,
David
>
> Just my 2 cents.
>
> --
> Jarkko
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
From: David Cohen @ 2011-02-15 14:01 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Hiroshi.DOYU, tony, linux-omap, linux-arm-kernel
In-Reply-To: <4D5A85F4.5060103@ru.mvista.com>
On Tue, Feb 15, 2011 at 3:56 PM, Sergei Shtylyov <sshtylyov@mvista.com> wrote:
> On 15-02-2011 16:44, David Cohen wrote:
>
>>>> IOMMU upper layer is already printing error message. OMAP2+ specific
>>>> layer may print error message only for debug purpose.
>
>>>> Signed-off-by: David Cohen<dacohen@gmail.com>
>>>> ---
>>>> arch/arm/mach-omap2/iommu2.c | 6 +++---
>>>> 1 files changed, 3 insertions(+), 3 deletions(-)
>
>>>> diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
>>>> index 14ee686..4244a07 100644
>>>> --- a/arch/arm/mach-omap2/iommu2.c
>>>> +++ b/arch/arm/mach-omap2/iommu2.c
>>>> @@ -163,13 +163,13 @@ static u32 omap2_iommu_fault_isr(struct iommu
>>>> *obj,
>>>> u32 *ra)
>>>> da = iommu_read_reg(obj, MMU_FAULT_AD);
>>>> *ra = da;
>>>>
>>>> - dev_err(obj->dev, "%s:\tda:%08x ", __func__, da);
>>>> + dev_dbg(obj->dev, "%s:\tda:%08x ", __func__, da);
>
>>> Note that dev_dbg() will only print something if either DEBUG or
>>> CONFIG_DYNAMIC_DEBUG are defined...
>
>> That's my plan.
>
>>>> for (i = 0; i < ARRAY_SIZE(err_msg); i++) {
>>>> if (stat& (1<< i))
>>>> - printk("%s ", err_msg[i]);
>>>> + printk(KERN_DEBUG "%s ", err_msg[i]);
>
>>> ... unlike printk(KERN_DEBUG...). You probably want to use pr_debug()
>>> instead.
>
>>>> }
>>>> - printk("\n");
>>>> + printk(KERN_DEBUG "\n");
>
>>> Here too... Although wait, it should be KERN_CONT instead! Debug levels
>>> are only attributed to the whole lines.
>
>> But your observation is correct. I'll resend it with KERN_CONT instead.
>
> This won't play out correctly anyway. If DEBUG is not #define'd, the
> beginning of line won't be printed but the continuations will. You just
> can't do it correctly with dev_dbg(), unless you break the single line into
> several ones.
Yes, I got this situation. I'm coming with a proper solution on next version.
Br,
David
>
>> Regards,
>
>> David
>
> WBR, Sergei
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
From: Jarkko Nikula @ 2011-02-15 13:59 UTC (permalink / raw)
To: David Cohen
Cc: Sergei Shtylyov, tony, linux-omap, Hiroshi.DOYU, linux-arm-kernel
In-Reply-To: <AANLkTinQX59iyX1La=99Urgh5_JF0iZacBDqQz1VQfhi@mail.gmail.com>
On Tue, 15 Feb 2011 15:44:27 +0200
David Cohen <dacohen@gmail.com> wrote:
> >> @@ -163,13 +163,13 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj,
> >> u32 *ra)
> >> da = iommu_read_reg(obj, MMU_FAULT_AD);
> >> *ra = da;
> >>
> >> - dev_err(obj->dev, "%s:\tda:%08x ", __func__, da);
> >> + dev_dbg(obj->dev, "%s:\tda:%08x ", __func__, da);
> >
> > Note that dev_dbg() will only print something if either DEBUG or
> > CONFIG_DYNAMIC_DEBUG are defined...
>
> That's my plan.
>
So it's sure that a developer won't need these error dumps when
receiving an error report? I.e. IOMMU upper level errors give enough
information to start doing own debugging?
Just my 2 cents.
--
Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
From: Sergei Shtylyov @ 2011-02-15 13:56 UTC (permalink / raw)
To: David Cohen
Cc: Sergei Shtylyov, Hiroshi.DOYU, tony, linux-omap, linux-arm-kernel
In-Reply-To: <AANLkTinQX59iyX1La=99Urgh5_JF0iZacBDqQz1VQfhi@mail.gmail.com>
On 15-02-2011 16:44, David Cohen wrote:
>>> IOMMU upper layer is already printing error message. OMAP2+ specific
>>> layer may print error message only for debug purpose.
>>> Signed-off-by: David Cohen<dacohen@gmail.com>
>>> ---
>>> arch/arm/mach-omap2/iommu2.c | 6 +++---
>>> 1 files changed, 3 insertions(+), 3 deletions(-)
>>> diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
>>> index 14ee686..4244a07 100644
>>> --- a/arch/arm/mach-omap2/iommu2.c
>>> +++ b/arch/arm/mach-omap2/iommu2.c
>>> @@ -163,13 +163,13 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj,
>>> u32 *ra)
>>> da = iommu_read_reg(obj, MMU_FAULT_AD);
>>> *ra = da;
>>>
>>> - dev_err(obj->dev, "%s:\tda:%08x ", __func__, da);
>>> + dev_dbg(obj->dev, "%s:\tda:%08x ", __func__, da);
>> Note that dev_dbg() will only print something if either DEBUG or
>> CONFIG_DYNAMIC_DEBUG are defined...
> That's my plan.
>>> for (i = 0; i < ARRAY_SIZE(err_msg); i++) {
>>> if (stat& (1<< i))
>>> - printk("%s ", err_msg[i]);
>>> + printk(KERN_DEBUG "%s ", err_msg[i]);
>> ... unlike printk(KERN_DEBUG...). You probably want to use pr_debug()
>> instead.
>>> }
>>> - printk("\n");
>>> + printk(KERN_DEBUG "\n");
>> Here too... Although wait, it should be KERN_CONT instead! Debug levels
>> are only attributed to the whole lines.
> But your observation is correct. I'll resend it with KERN_CONT instead.
This won't play out correctly anyway. If DEBUG is not #define'd, the
beginning of line won't be printed but the continuations will. You just can't
do it correctly with dev_dbg(), unless you break the single line into several
ones.
> Regards,
> David
WBR, Sergei
^ permalink raw reply
* Re: Downtime and Update - Please read
From: OMAP Admin @ 2011-02-15 13:54 UTC (permalink / raw)
To: pandaboard-/JYPxA39Uh5TLH3MbocFFw,
omapdiscuss-/JYPxA39Uh5TLH3MbocFFw,
omapzoom-/JYPxA39Uh5TLH3MbocFFw,
omapandroid-discussion-GQPhjZDXxwGtG0bUXCXiUA,
beagleboard-/JYPxA39Uh5TLH3MbocFFw,
linux-omap-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <AANLkTim=8GLw+PKfU9Qdu5wWGsX=88wD97mDMcPB6wpJ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2411 bytes --]
An update about the downtime:
We have removed captcha for edits on OMAPPedia wiki.
The new logins are still restricted and only Admin can create new login
accounts.
We plan to remove this restriction after two weeks.
If you are getting file download message while accessing
http://pandaboard.org or http://omappedia.org then do one of the followings:
1. Clear cache of your browser and try, if the problem persists then
2. Alternatively you can access both the web-sites as:
Wiki -> http://omapedia.org (there is one less 'p' in the name),
or as http://omappedia.com
PandaBoard -> http://www.pandaboard.org
Please send an email to omapadm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org if you have any questions concerns
or see any issues.
Thank you,
OMAP Admin Team
On Mon, Feb 14, 2011 at 4:13 PM, OMAP Admin <omapadm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> All,
>
> We have successfully stopped the spammers and cleaned up the lot of
> spam-user-id as well as spam-content.
>
> We plan to take the system down for 2 hrs tomorrow Tue Feb 15, 2011 at
> 14:00 pm GMT
> (which would be 19:30 IST, or 08:00 CDT).
>
> The downtime affects pandaboard.org, omiio.org and omappedia.org.
> Please refrain from using any of these web-sites during the downtime.
>
> During the downtime we plan to do some maintenance activities along with
> removing captcha on edits from omappedia.org.
> Currently only Admin can create new accounts on omappedia.org. We intent
> to keep that mechanism on for couple of more weeks. You can always send an
> email to omapadm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org if you need new accounts created.
>
> If you have any questions or concerns please email them to:
> omapadm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
>
> Thank you,
>
> Regards,
>
> OMAP Admin Team
>
>
> On Thu, Feb 3, 2011 at 5:27 PM, OMAP Admin <omapadm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> All,
>>
>> We are being hit by spammers on our wiki.
>> Last week we enabled captcha on new user registration.
>> That did not stop the spammers.
>> Today we saw spammers deleting content from our main page.
>>
>> To prevent and discourage spammers we have enabled captcha on all edits.
>> Apologize for the inconvenience it may cause to you.
>>
>> If you have any questions please feel free to email omapadm-Re5JQEeQqe9fmgfxC/sS/w@public.gmane.org
>>
>>
>> OMAP Admin Team
>>
>
>
[-- Attachment #2: Type: text/html, Size: 3847 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] OMAP: PM: implement devices wakeup latency constraints APIs
From: Jean Pihet @ 2011-02-15 13:52 UTC (permalink / raw)
To: Vishwanath Sripathy
Cc: Kevin Hilman, paul, Vibhore Vardhan, Santosh Shilimkar,
Rajendra Nayak, linux-omap, Jean Pihet-XID
In-Reply-To: <b34afc47bcc37fa68315718cdbcd19e1@mail.gmail.com>
Hi Vishwa,
On Tue, Feb 15, 2011 at 10:35 AM, Vishwanath Sripathy
<vishwanath.bs@ti.com> wrote:
>> -----Original Message-----
>> From: jean.pihet@newoldbits.com [mailto:jean.pihet@newoldbits.com]
>> Sent: Friday, February 11, 2011 12:53 AM
>> To: khilman@ti.com; paul@pwsan.com; Vibhore Vardhan; Santosh
>> Shilimkar; Vishwanath BS; rnayak@ti.com
>> Cc: linux-omap@vger.kernel.org; Jean Pihet; Vibhore Vardhan
>> Subject: [PATCH 2/2] OMAP: PM: implement devices wakeup latency
>> constraints APIs
>>
>> From: Jean Pihet <j-pihet@ti.com>
>>
>> Implement OMAP PM layer omap_pm_set_max_dev_wakeup_lat API by
>> creating similar APIs at the omap_device and omap_hwmod levels. The
>> omap_hwmod level call is the layer with access to the powerdomain
>> core, so it is the place where the powerdomain is queried to set and
>> release the constraints.
>>
>> NOTE: only works for devices which have been converted to use
>> omap_device/omap_hwmod.
>>
>> Longer term, we could possibly remove this API from the OMAP PM layer,
>> and instead directly use the omap_device level API.
>>
>> Based on Vibhore's original patch , adapted to omap_device and
>> omap_hwmod frameworks.
>>
>> Signed-off-by: Jean Pihet <j-pihet@ti.com>
>> Cc: Vibhore Vardhan <vvardhan@ti.com>
>> ---
>> arch/arm/mach-omap2/omap_hwmod.c | 62 +++++++++-
>> arch/arm/mach-omap2/powerdomain.c | 176
>> ++++++++++++++++++++++++-
>> arch/arm/mach-omap2/powerdomain.h | 31 +++++
>> arch/arm/mach-omap2/powerdomains3xxx_data.c | 60
>> +++++++++
>> arch/arm/plat-omap/include/plat/omap_device.h | 2 +
>> arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 +
>> arch/arm/plat-omap/omap-pm-constraints.c | 101 ++++++---------
>> arch/arm/plat-omap/omap_device.c | 28 ++++
>> 8 files changed, 399 insertions(+), 63 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-
>> omap2/omap_hwmod.c
>> index e282e35..0dc096f 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod.c
>> @@ -142,6 +142,7 @@
>> #include "powerdomain.h"
>> #include <plat/clock.h>
>> #include <plat/omap_hwmod.h>
>> +#include <plat/omap_device.h>
>> #include <plat/prcm.h>
>>
>> #include "cm2xxx_3xxx.h"
>> @@ -2198,10 +2199,69 @@ ohsps_unlock:
>> }
>>
>> /**
>> + * omap_hwmod_set_max_dev_wakeup_lat - set a device wake-up
>> constraint
>> + * @oh: struct omap_hwmod *
>> + * @req_oh: struct omap_hwmod *
> Need to explain what this parameters mean.
Ok, will add a description here. Basically oh corresponds to the
device (and so the power domain) to set a constraint on and req_oh is
the constraint requester. oh is used to determine which power domain
to set a constraint on, req_oh is used to record the requester for
later update or removal of a constraint.
>> + * @t: wakeup latency constraint (us). -1 removes the existing
>> constraint
>> + *
>> + * Query the powerdomain of @oh to set/release the wake-up
>> constraint
>> + *
>> + * Returns -EINVAL if @oh or @req_oh have no power domain, or the
>> return
>> + * code from the pwrdm function
>> (pwrdm_wakeuplat_set/release_constraint)
>> + * of the powerdomain assocated with @oh.
>> + */
>> +int omap_hwmod_set_max_dev_wakeup_lat(struct omap_hwmod
>> *req_oh,
>> + struct omap_hwmod *oh, long t)
>> +{
>> + struct device *req_dev;
>> + struct platform_device *pdev;
>> + struct powerdomain *pwrdm;
>> + int ret = 0;
>> +
>> + pwrdm = omap_hwmod_get_pwrdm(oh);
>> +
>> + /* Catch devices with undefined powerdomains */
>> + if (!pwrdm) {
>> + pr_err("omap_hwmod: Error: could not find parent "
>> + "powerdomain for %s\n", oh->name);
>> + return -EINVAL;
>> + }
>> +
>> + pdev = &(req_oh->od->pdev);
>> + if (pdev == NULL) {
>> + pr_err("omap_hwmod: Error: pdev not found for oh %s\n",
>> + oh->name);
>> + return -EINVAL;
>> + }
>> +
>> + req_dev = &(pdev->dev);
>> + if (req_dev == NULL) {
>> + pr_err("omap_hwmod: Error: device not found for oh
>> %s\n",
>> + oh->name);
>> + return -EINVAL;
>> + }
> If I understand correctly, req_dev is used for keeping track of different
> requests. If so, why can't you directly pass req_dev as an input param
> instead of deriving it from pdev.
The layering in the API is as follows: caller -> omap-pm ->
omap_device -> omap_hwmod -> powerdomain. The parameters types are
passed accordingly.
Note: I will rename pdev to req_pdev to make it clear that the
parameter relates to the requester.
>> +
>> + /* Call set/release_constraint for the given pwrdm */
>> + if (t == -1) {
>> + pr_debug("omap_hwmod: remove max device latency
>> constraint: "
>> + "oh %s, pwrdm %s, req by oh %s\n",
>> + oh->name, pwrdm->name, req_oh->name);
>> + ret = pwrdm_wakeuplat_release_constraint(pwrdm,
>> req_dev);
>> + } else {
>> + pr_debug("omap_hwmod: add max device latency
>> constraint: "
>> + "oh %s, t = %ld usec, pwrdm %s, req by oh
>> %s\n",
>> + oh->name, t, pwrdm->name, req_oh->name);
>> + ret = pwrdm_wakeuplat_set_constraint(pwrdm, req_dev,
>> t);
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +/**
>> * omap_hwmod_get_context_loss_count - get lost context count
>> * @oh: struct omap_hwmod *
>> *
>> - * Query the powerdomain of of @oh to get the context loss
>> + * Query the powerdomain of @oh to get the context loss
>> * count for this device.
>> *
>> * Returns the context loss count of the powerdomain assocated with
>> @oh
>> diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-
>> omap2/powerdomain.c
>> index eaed0df..3ed3bea 100644
>> --- a/arch/arm/mach-omap2/powerdomain.c
>> +++ b/arch/arm/mach-omap2/powerdomain.c
>> @@ -19,16 +19,19 @@
>> #include <linux/list.h>
>> #include <linux/errno.h>
>> #include <linux/string.h>
>> +#include <linux/slab.h>
>> +
>> +#include <plat/cpu.h>
>> +#include <plat/prcm.h>
>> +
>> #include "cm2xxx_3xxx.h"
>> #include "prcm44xx.h"
>> #include "cm44xx.h"
>> #include "prm2xxx_3xxx.h"
>> #include "prm44xx.h"
>>
>> -#include <plat/cpu.h>
>> #include "powerdomain.h"
>> #include "clockdomain.h"
>> -#include <plat/prcm.h>
>>
>> #include "pm.h"
>>
>> @@ -103,6 +106,13 @@ static int _pwrdm_register(struct powerdomain
>> *pwrdm)
>> pwrdm->state = pwrdm_read_pwrst(pwrdm);
>> pwrdm->state_counter[pwrdm->state] = 1;
>>
>> + /* Initialize priority ordered list for wakeup latency constraint
> */
>> + spin_lock_init(&pwrdm->wakeuplat_lock);
>> + plist_head_init(&pwrdm->wakeuplat_dev_list, &pwrdm-
>> >wakeuplat_lock);
>> +
>> + /* res_mutex protects res_list add and del ops */
>> + mutex_init(&pwrdm->wakeuplat_mutex);
>> +
>> pr_debug("powerdomain: registered %s\n", pwrdm->name);
>>
>> return 0;
>> @@ -176,6 +186,62 @@ static int _pwrdm_post_transition_cb(struct
>> powerdomain *pwrdm, void *unused)
>> return 0;
>> }
>>
>> +/**
>> + * pwrdm_wakeuplat_update_pwrst - Update power domain power
>> state if needed
>> + * @pwrdm: struct powerdomain * to which requesting device belongs
>> to
>> + *
>> + * Finds minimum latency value from all entries in the list and
>> + * the power domain power state needing the constraint. Programs
>> + * new state if it is different from current power state.
>> + */
>> +static void pwrdm_wakeuplat_update_pwrst(struct powerdomain
>> *pwrdm)
>> +{
>> + struct plist_node *node;
>> + int new_state;
>> + unsigned long min_latency = -1;
>> +
>> + if (!plist_head_empty(&pwrdm->wakeuplat_dev_list)) {
>> + node = plist_last(&pwrdm->wakeuplat_dev_list);
> Wouldn't plist_last return the node with highest latency? I think you are
> looking for lowest latency.
Yes indeed. We need the strongest constraint, so the lowest allowed
wake-up latency value.
>> + min_latency = node->prio;
>> + }
>> +
>> + /* Find power state with wakeup latency < minimum constraint.
>> */
>> + for (new_state = 0x0; new_state < PWRDM_MAX_PWRSTS;
>> new_state++) {
>> + if (min_latency == -1 ||
>> + pwrdm->wakeup_lat[new_state] <= min_latency)
>> + break;
>> + }
>> +
>> + switch (new_state) {
>> + case PWRDM_FUNC_PWRST_OFF:
>> + new_state = PWRDM_POWER_OFF;
>> + break;
>> + case PWRDM_FUNC_PWRST_OSWR:
>> + pwrdm_set_logic_retst(pwrdm, PWRDM_POWER_OFF);
>> + case PWRDM_FUNC_PWRST_CSWR:
>> + new_state = PWRDM_POWER_RET;
>> + break;
>> + case PWRDM_FUNC_PWRST_ON:
>> + new_state = PWRDM_POWER_ON;
>> + break;
>> + default:
>> + pr_warn("powerdomain: requested latency constraint not "
>> + "supported %s set to ON state\n", pwrdm->name);
>> + new_state = PWRDM_POWER_ON;
>> + break;
>> + }
>> +
>> + if (pwrdm_read_pwrst(pwrdm) != new_state) {
>> + if (cpu_is_omap34xx())
> Why this cpu check here?
Only 34xx has support for the latency constraints. The other platforms
have the wakeup latency values set as '0', which means that OFF mode
will always be chosen as preferred state. Is it allowed to set the
pwrdm_state in this case?
>> + omap_set_pwrdm_state(pwrdm, new_state);
>> + }
>> +
>> + pr_debug("powerdomain: %s pwrst: curr= %d, prev= %d next=
>> %d "
>> + "wkuplat_min= %lu, set_state= %d\n", pwrdm->name,
>> + pwrdm_read_pwrst(pwrdm),
>> pwrdm_read_prev_pwrst(pwrdm),
>> + pwrdm_read_next_pwrst(pwrdm), min_latency,
>> new_state);
>> +}
>> +
>> /* Public functions */
>>
>> /**
>> @@ -911,6 +977,112 @@ int pwrdm_post_transition(void)
>> }
>>
>> /**
>> + * pwrdm_wakeuplat_set_constraint - Set powerdomain wakeup
>> latency constraint
>> + * @pwrdm: struct powerdomain * to which requesting device belongs
>> to
>> + * @dev: struct device * of requesting device
>> + * @t: wakeup latency constraint in microseconds
>> + *
>> + * Adds new entry to powerdomain's wakeup latency constraint list.
>> + * If the requesting device already exists in the list, old value is
>> + * overwritten. Checks whether current power state is still adequate.
>> + * Returns -EINVAL if the powerdomain or device pointer is NULL,
>> + * or -ENOMEM if kmalloc fails, or returns 0 upon success.
>> + */
>> +int pwrdm_wakeuplat_set_constraint(struct powerdomain *pwrdm,
>> + struct device *req_dev, unsigned long
> t)
>> +{
>> + struct wakeuplat_dev_list *user;
>> + int found = 0, ret = 0;
>> +
>> + if (!pwrdm || !req_dev) {
>> + WARN(1, "powerdomain: %s: invalid parameter(s)",
>> __func__);
>> + return -EINVAL;
>> + }
>> +
>> + mutex_lock(&pwrdm->wakeuplat_mutex);
>> +
>> + plist_for_each_entry(user, &pwrdm->wakeuplat_dev_list, node) {
>> + if (user->dev == req_dev) {
>> + found = 1;
>> + break;
>> + }
>> + }
>> +
>> + /* Add new entry to the list or update existing request */
>> + if (found && user->constraint_us == t) {
>> + goto exit_set;
>> + } else if (!found) {
>> + user = kzalloc(sizeof(struct wakeuplat_dev_list),
>> GFP_KERNEL);
>> + if (!user) {
>> + pr_err("powerdomain: FATAL ERROR: kzalloc
>> failed\n");
>> + ret = -ENOMEM;
>> + goto exit_set;
>> + }
>> + user->dev = req_dev;
>> + } else {
>> + plist_del(&user->node, &pwrdm->wakeuplat_dev_list);
>> + }
>> +
>> + plist_node_init(&user->node, t);
>> + plist_add(&user->node, &pwrdm->wakeuplat_dev_list);
>> + user->node.prio = user->constraint_us = t;
>> +
>> + pwrdm_wakeuplat_update_pwrst(pwrdm);
>> +
>> +exit_set:
>> + mutex_unlock(&pwrdm->wakeuplat_mutex);
>> +
>> + return ret;
>> +}
>> +
>> +/**
>> + * pwrdm_wakeuplat_release_constraint - Release powerdomain
>> wkuplat constraint
>> + * @pwrdm: struct powerdomain * to which requesting device belongs
>> to
>> + * @req_dev: struct device * of requesting device
>> + *
>> + * Removes device's entry from powerdomain's wakeup latency
>> constraint list.
>> + * Checks whether current power state is still adequate.
>> + * Returns -EINVAL if the powerdomain or device pointer is NULL or
>> + * no such entry exists in the list, or returns 0 upon success.
>> + */
>> +int pwrdm_wakeuplat_release_constraint(struct powerdomain *pwrdm,
>> + struct device *req_dev)
>> +{
>> + struct wakeuplat_dev_list *user;
>> + int found = 0, ret = 0;
>> +
>> + if (!pwrdm || !req_dev) {
>> + WARN(1, "powerdomain: %s: invalid parameter(s)",
>> __func__);
>> + return -EINVAL;
>> + }
>> +
>> + mutex_lock(&pwrdm->wakeuplat_mutex);
>> +
>> + plist_for_each_entry(user, &pwrdm->wakeuplat_dev_list, node) {
>> + if (user->dev == req_dev) {
>> + found = 1;
>> + break;
>> + }
>> + }
>> +
>> + if (!found) {
>> + pr_err("OMAP PM: Error: no prior constraint to
> release\n");
>> + ret = -EINVAL;
>> + goto exit_rls;
>> + }
>> +
>> + plist_del(&user->node, &pwrdm->wakeuplat_dev_list);
>> + kfree(user);
>> +
>> + pwrdm_wakeuplat_update_pwrst(pwrdm);
>> +
>> +exit_rls:
>> + mutex_unlock(&pwrdm->wakeuplat_mutex);
>> +
>> + return ret;
>> +}
>> +
>> +/**
>> * pwrdm_get_context_loss_count - get powerdomain's context loss
>> count
>> * @pwrdm: struct powerdomain * to wait for
>> *
>> diff --git a/arch/arm/mach-omap2/powerdomain.h b/arch/arm/mach-
>> omap2/powerdomain.h
>> index c66431e..d4189d8 100644
>> --- a/arch/arm/mach-omap2/powerdomain.h
>> +++ b/arch/arm/mach-omap2/powerdomain.h
>> @@ -19,6 +19,9 @@
>>
>> #include <linux/types.h>
>> #include <linux/list.h>
>> +#include <linux/plist.h>
>> +#include <linux/mutex.h>
>> +#include <linux/spinlock.h>
>>
>> #include <linux/atomic.h>
>>
>> @@ -46,6 +49,15 @@
>>
>> #define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | (1 <<
>> PWRDM_POWER_ON))
>>
>> +/* Powerdomain functional power states */
>> +#define PWRDM_FUNC_PWRST_OFF 0x0
>> +#define PWRDM_FUNC_PWRST_OSWR 0x1
>> +#define PWRDM_FUNC_PWRST_CSWR 0x2
>> +#define PWRDM_FUNC_PWRST_ON 0x3
>> +
>> +#define PWRDM_MAX_FUNC_PWRSTS 4
>> +
>> +#define UNSUP_STATE -1
>>
>> /* Powerdomain flags */
>> #define PWRDM_HAS_HDWR_SAR (1 << 0) /* hardware save-and-
>> restore support */
>> @@ -96,6 +108,10 @@ struct powerdomain;
>> * @state_counter:
>> * @timer:
>> * @state_timer:
>> + * @wakeup_lat: Wakeup latencies for possible powerdomain power
>> states
Will add a comment about the ordering (latency values must be sorted
in decremental order).
>> + * @wakeuplat_lock: spinlock for plist
>> + * @wakeuplat_dev_list: plist_head linking all devices placing
>> constraint
>> + * @wakeuplat_mutex: mutex to protect per powerdomain list ops
>> *
>> * @prcm_partition possible values are defined in mach-
>> omap2/prcm44xx.h.
>> */
>> @@ -121,6 +137,16 @@ struct powerdomain {
>> s64 timer;
>> s64 state_timer[PWRDM_MAX_PWRSTS];
>> #endif
>> + const u32 wakeup_lat[PWRDM_MAX_FUNC_PWRSTS];
>> + spinlock_t wakeuplat_lock;
>> + struct plist_head wakeuplat_dev_list;
>> + struct mutex wakeuplat_mutex;
>> +};
>> +
>> +struct wakeuplat_dev_list {
>> + struct device *dev;
>> + unsigned long constraint_us;
>> + struct plist_node node;
>> };
>>
>> /**
>> @@ -211,6 +237,11 @@ int pwrdm_clkdm_state_switch(struct
>> clockdomain *clkdm);
>> int pwrdm_pre_transition(void);
>> int pwrdm_post_transition(void);
>> int pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm);
>> +
>> +int pwrdm_wakeuplat_set_constraint(struct powerdomain *pwrdm,
>> + struct device *dev, unsigned long t);
>> +int pwrdm_wakeuplat_release_constraint(struct powerdomain *pwrdm,
>> + struct device *dev);
>> u32 pwrdm_get_context_loss_count(struct powerdomain *pwrdm);
>>
>> extern void omap2xxx_powerdomains_init(void);
>> diff --git a/arch/arm/mach-omap2/powerdomains3xxx_data.c
>> b/arch/arm/mach-omap2/powerdomains3xxx_data.c
>> index e1bec56..4f7e44d 100644
>> --- a/arch/arm/mach-omap2/powerdomains3xxx_data.c
>> +++ b/arch/arm/mach-omap2/powerdomains3xxx_data.c
>> @@ -52,6 +52,12 @@ static struct powerdomain iva2_pwrdm = {
>> [2] = PWRSTS_OFF_ON,
>> [3] = PWRDM_POWER_ON,
>> },
>> + .wakeup_lat = {
>> + [PWRDM_FUNC_PWRST_OFF] = 1100,
>> + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
>> + [PWRDM_FUNC_PWRST_CSWR] = 350,
>> + [PWRDM_FUNC_PWRST_ON] = 0,
>> + },
>> };
>>
>> static struct powerdomain mpu_3xxx_pwrdm = {
>> @@ -68,6 +74,12 @@ static struct powerdomain mpu_3xxx_pwrdm = {
>> .pwrsts_mem_on = {
>> [0] = PWRSTS_OFF_ON,
>> },
>> + .wakeup_lat = {
>> + [PWRDM_FUNC_PWRST_OFF] = 95,
>> + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
>> + [PWRDM_FUNC_PWRST_CSWR] = 45,
>> + [PWRDM_FUNC_PWRST_ON] = 0,
>> + },
>> };
>>
>> /*
>> @@ -98,6 +110,12 @@ static struct powerdomain
>> core_3xxx_pre_es3_1_pwrdm = {
>> [0] = PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */
>> [1] = PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */
>> },
>> + .wakeup_lat = {
>> + [PWRDM_FUNC_PWRST_OFF] = 100,
>> + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
>> + [PWRDM_FUNC_PWRST_CSWR] = 60,
>> + [PWRDM_FUNC_PWRST_ON] = 0,
>> + },
>> };
>>
>> static struct powerdomain core_3xxx_es3_1_pwrdm = {
>> @@ -121,6 +139,12 @@ static struct powerdomain
>> core_3xxx_es3_1_pwrdm = {
>> [0] = PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */
>> [1] = PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */
>> },
>> + .wakeup_lat = {
>> + [PWRDM_FUNC_PWRST_OFF] = 100,
>> + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
>> + [PWRDM_FUNC_PWRST_CSWR] = 60,
>> + [PWRDM_FUNC_PWRST_ON] = 0,
>> + },
>> };
>>
>> static struct powerdomain dss_pwrdm = {
>> @@ -136,6 +160,12 @@ static struct powerdomain dss_pwrdm = {
>> .pwrsts_mem_on = {
>> [0] = PWRDM_POWER_ON, /* MEMONSTATE */
>> },
>> + .wakeup_lat = {
>> + [PWRDM_FUNC_PWRST_OFF] = 70,
>> + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
>> + [PWRDM_FUNC_PWRST_CSWR] = 20,
>> + [PWRDM_FUNC_PWRST_ON] = 0,
>> + },
>> };
>>
>> /*
>> @@ -157,6 +187,12 @@ static struct powerdomain sgx_pwrdm = {
>> .pwrsts_mem_on = {
>> [0] = PWRDM_POWER_ON, /* MEMONSTATE */
>> },
>> + .wakeup_lat = {
>> + [PWRDM_FUNC_PWRST_OFF] = 1000,
>> + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
>> + [PWRDM_FUNC_PWRST_CSWR] = UNSUP_STATE,
>> + [PWRDM_FUNC_PWRST_ON] = 0,
>> + },
>> };
>>
>> static struct powerdomain cam_pwrdm = {
>> @@ -172,6 +208,12 @@ static struct powerdomain cam_pwrdm = {
>> .pwrsts_mem_on = {
>> [0] = PWRDM_POWER_ON, /* MEMONSTATE */
>> },
>> + .wakeup_lat = {
>> + [PWRDM_FUNC_PWRST_OFF] = 850,
>> + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
>> + [PWRDM_FUNC_PWRST_CSWR] = 35,
>> + [PWRDM_FUNC_PWRST_ON] = 0,
>> + },
>> };
>>
>> static struct powerdomain per_pwrdm = {
>> @@ -187,6 +229,12 @@ static struct powerdomain per_pwrdm = {
>> .pwrsts_mem_on = {
>> [0] = PWRDM_POWER_ON, /* MEMONSTATE */
>> },
>> + .wakeup_lat = {
>> + [PWRDM_FUNC_PWRST_OFF] = 200,
>> + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
>> + [PWRDM_FUNC_PWRST_CSWR] = 110,
>> + [PWRDM_FUNC_PWRST_ON] = 0,
>> + },
>> };
>>
>> static struct powerdomain emu_pwrdm = {
>> @@ -201,6 +249,12 @@ static struct powerdomain neon_pwrdm = {
>> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
>> .pwrsts = PWRSTS_OFF_RET_ON,
>> .pwrsts_logic_ret = PWRDM_POWER_RET,
>> + .wakeup_lat = {
>> + [PWRDM_FUNC_PWRST_OFF] = 200,
>> + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
>> + [PWRDM_FUNC_PWRST_CSWR] = 35,
>> + [PWRDM_FUNC_PWRST_ON] = 0,
>> + },
>> };
>>
>> static struct powerdomain usbhost_pwrdm = {
>> @@ -223,6 +277,12 @@ static struct powerdomain usbhost_pwrdm = {
>> .pwrsts_mem_on = {
>> [0] = PWRDM_POWER_ON, /* MEMONSTATE */
>> },
>> + .wakeup_lat = {
>> + [PWRDM_FUNC_PWRST_OFF] = 800,
>> + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE,
>> + [PWRDM_FUNC_PWRST_CSWR] = 150,
>> + [PWRDM_FUNC_PWRST_ON] = 0,
>> + },
>> };
>>
>> static struct powerdomain dpll1_pwrdm = {
>> diff --git a/arch/arm/plat-omap/include/plat/omap_device.h
>> b/arch/arm/plat-omap/include/plat/omap_device.h
>> index e4c349f..5da6b47 100644
>> --- a/arch/arm/plat-omap/include/plat/omap_device.h
>> +++ b/arch/arm/plat-omap/include/plat/omap_device.h
>> @@ -107,6 +107,8 @@ void __iomem *omap_device_get_rt_va(struct
>> omap_device *od);
>> int omap_device_align_pm_lat(struct platform_device *pdev,
>> u32 new_wakeup_lat_limit);
>> struct powerdomain *omap_device_get_pwrdm(struct omap_device
>> *od);
>> +int omap_device_set_max_dev_wakeup_lat(struct platform_device
>> *req_pdev,
>> + struct platform_device *pdev, long
> t);
>> u32 omap_device_get_context_loss_count(struct platform_device
>> *pdev);
>>
>> /* Other */
>> diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
>> b/arch/arm/plat-omap/include/plat/omap_hwmod.h
>> index 1eee85a..0fbb974 100644
>> --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
>> +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
>> @@ -587,6 +587,8 @@ int omap_hwmod_for_each_by_class(const char
>> *classname,
>> void *user);
>>
>> int omap_hwmod_set_postsetup_state(struct omap_hwmod *oh, u8
>> state);
>> +int omap_hwmod_set_max_dev_wakeup_lat(struct omap_hwmod
>> *req_oh,
>> + struct omap_hwmod *oh, long t);
>> u32 omap_hwmod_get_context_loss_count(struct omap_hwmod *oh);
>>
>> /*
>> diff --git a/arch/arm/plat-omap/omap-pm-constraints.c b/arch/arm/plat-
>> omap/omap-pm-constraints.c
>> index c8b4e4c..7ae855f 100644
>> --- a/arch/arm/plat-omap/omap-pm-constraints.c
>> +++ b/arch/arm/plat-omap/omap-pm-constraints.c
>> @@ -24,6 +24,7 @@
>> /* Interface documentation is in mach/omap-pm.h */
>> #include <plat/omap-pm.h>
>> #include <plat/omap_device.h>
>> +#include <plat/common.h>
>>
>> static bool off_mode_enabled;
>> static u32 dummy_context_loss_counter;
>> @@ -32,34 +33,6 @@ static u32 dummy_context_loss_counter;
>> * Device-driver-originated constraints (via board-*.c files)
>> */
>>
>> -int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t)
>> -{
>> - if (!dev || t < -1) {
>> - WARN(1, "OMAP PM: %s: invalid parameter(s)",
>> __func__);
>> - return -EINVAL;
>> - };
>> -
>> - if (t == -1)
>> - pr_debug("OMAP PM: remove max MPU wakeup latency
>> constraint: "
>> - "dev %s\n", dev_name(dev));
>> - else
>> - pr_debug("OMAP PM: add max MPU wakeup latency
>> constraint: "
>> - "dev %s, t = %ld usec\n", dev_name(dev), t);
>> -
>> - /*
>> - * For current Linux, this needs to map the MPU to a
>> - * powerdomain, then go through the list of current max lat
>> - * constraints on the MPU and find the smallest. If
>> - * the latency constraint has changed, the code should
>> - * recompute the state to enter for the next powerdomain
>> - * state.
>> - *
>> - * TI CDP code can call constraint_set here.
>> - */
>> -
>> - return 0;
>> -}
>> -
>> int omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id,
>> unsigned long r)
>> {
>> if (!dev || (agent_id != OCP_INITIATOR_AGENT &&
>> @@ -87,62 +60,70 @@ int omap_pm_set_min_bus_tput(struct device
>> *dev, u8 agent_id, unsigned long r)
>> return 0;
>> }
>>
>> +/*
>> + * omap_pm_set_max_dev_wakeup_lat - set/release devices wake-up
>> latency
>> + * constraints
>> + */
>> int omap_pm_set_max_dev_wakeup_lat(struct device *req_dev, struct
>> device *dev,
>> long t)
>> {
>> + struct platform_device *pdev, *req_pdev;
>> + int ret = 0;
>> +
>> if (!req_dev || !dev || t < -1) {
>> WARN(1, "OMAP PM: %s: invalid parameter(s)",
>> __func__);
>> return -EINVAL;
>> + }
>> +
>> + /* Look for the platform devices */
>> + pdev = container_of(dev, struct platform_device, dev);
>
> You could perhaps use macro to_platform_device instead of using
> container_of.
Yes that is better.
>
>> + req_pdev = container_of(req_dev, struct platform_device, dev);
Same here.
>> +
>> + /* Try to catch non platform devices. */
>> + if ((pdev->name == NULL) || (req_pdev->name == NULL)) {
>> + pr_err("OMAP-PM set_wakeup_lat: Error: platform devices
>> "
>> + "not valid\n");
>> + return -EINVAL;
>> + } else {
>> + /* Call the omap_device API */
>> + ret = omap_device_set_max_dev_wakeup_lat(req_pdev,
>> pdev, t);
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +int omap_pm_set_max_mpu_wakeup_lat(struct device *req_dev, long
>> t)
>> +{
>> + if (!req_dev || t < -1) {
>> + WARN(1, "OMAP PM: %s: invalid parameter(s)",
>> __func__);
>> + return -EINVAL;
>> };
>>
>> if (t == -1)
>> - pr_debug("OMAP PM: remove max device latency
>> constraint: "
>> - "dev %s\n", dev_name(dev));
>> + pr_debug("OMAP PM: remove max MPU wakeup latency
>> constraint: "
>> + "dev %s\n", dev_name(req_dev));
>> else
>> - pr_debug("OMAP PM: add max device latency constraint: "
>> - "dev %s, t = %ld usec\n", dev_name(dev), t);
>> + pr_debug("OMAP PM: add max MPU wakeup latency
>> constraint: "
>> + "dev %s, t = %ld usec\n", dev_name(req_dev), t);
>>
>> - /*
>> - * For current Linux, this needs to map the device to a
>> - * powerdomain, then go through the list of current max lat
>> - * constraints on that powerdomain and find the smallest. If
>> - * the latency constraint has changed, the code should
>> - * recompute the state to enter for the next powerdomain
>> - * state. Conceivably, this code should also determine
>> - * whether to actually disable the device clocks or not,
>> - * depending on how long it takes to re-enable the clocks.
>> - *
>> - * TI CDP code can call constraint_set here.
>> - */
>> + omap_pm_set_max_dev_wakeup_lat(req_dev,
>> omap2_get_mpuss_device(), t);
>>
>> return 0;
>> }
>>
>> -int omap_pm_set_max_sdma_lat(struct device *dev, long t)
>> +int omap_pm_set_max_sdma_lat(struct device *req_dev, long t)
>> {
>> - if (!dev || t < -1) {
>> + if (!req_dev || t < -1) {
>> WARN(1, "OMAP PM: %s: invalid parameter(s)",
>> __func__);
>> return -EINVAL;
>> };
>>
>> if (t == -1)
>> pr_debug("OMAP PM: remove max DMA latency constraint:
>> "
>> - "dev %s\n", dev_name(dev));
>> + "dev %s\n", dev_name(req_dev));
>> else
>> pr_debug("OMAP PM: add max DMA latency constraint: "
>> - "dev %s, t = %ld usec\n", dev_name(dev), t);
>> -
>> - /*
>> - * For current Linux PM QOS params, this code should scan the
>> - * list of maximum CPU and DMA latencies and select the
>> - * smallest, then set cpu_dma_latency pm_qos_param
>> - * accordingly.
>> - *
>> - * For future Linux PM QOS params, with separate CPU and DMA
>> - * latency params, this code should just set the dma_latency
>> param.
>> - *
>> - * TI CDP code can call constraint_set here.
>> - */
>> + "dev %s, t = %ld usec\n", dev_name(req_dev), t);
>>
>> return 0;
>> }
>> diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-
>> omap/omap_device.c
>> index 57adb27..1fe93d3 100644
>> --- a/arch/arm/plat-omap/omap_device.c
>> +++ b/arch/arm/plat-omap/omap_device.c
>> @@ -280,6 +280,34 @@ static void _add_optional_clock_alias(struct
>> omap_device *od,
>> /* Public functions for use by core code */
>>
>> /**
>> + * omap_device_set_max_dev_wakeup_lat - set/release a device
>> constraint
>> + * @od: struct omap_device *
>> + * @req_od: struct omap_device *
>> + *
>> + * Using the primary hwmod, set/release a device constraint for the
>> pdev
>> + * device, requested by the req_pdev device.
>> + *
>> + * If any hwmods exist for the omap_device assoiated with @pdev and
>> @req_pdev,
>> + * set/release the constraint for the corresponding hwmods, otherwise
>> return
>> + * -EINVAL.
>> + */
>> +int omap_device_set_max_dev_wakeup_lat(struct platform_device
>> *req_pdev,
>> + struct platform_device *pdev, long
> t)
>> +{
>> + struct omap_device *od, *req_od;
>> + u32 ret = -EINVAL;
>> +
>> + od = _find_by_pdev(pdev);
>> + req_od = _find_by_pdev(req_pdev);
>> +
>> + if ((od->hwmods_cnt) && (req_od->hwmods_cnt))
>> + ret = omap_hwmod_set_max_dev_wakeup_lat(req_od-
>> >hwmods[0],
>> + od->hwmods[0], t);
>> +
>> + return ret;
>> +}
>> +
>> +/**
>> * omap_device_get_context_loss_count - get lost context count
>> * @od: struct omap_device *
>> *
> Vishwa
>> --
>> 1.7.2.3
>
Thanks for the review, I will resubmit the patch asap.
Regards,
Jean
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 4/8] ARM: etm: Allow range selection
From: Alexander Shishkin @ 2011-02-15 13:50 UTC (permalink / raw)
To: Arve Hjønnevåg
Cc: Russell King, Greg Kroah-Hartman, linux-kernel, Jason Wessel,
linux-omap, linux-arm-kernel
In-Reply-To: <1297750276-12475-4-git-send-email-arve@android.com>
On Mon, Feb 14, 2011 at 10:11:12PM -0800, Arve Hjønnevåg wrote:
> Trace kernel text segment by default as before, allow tracing of other
> ranges by writing a range to /sys/devices/etm/trace_range, or to trace
> everything by writing 0 0.
Since you're adding this, I think it might make sense to add a 3rd optional
ctx id field, so that userspace tracing is also possible, especially when
on-chip ETB sizes increase to something more sensible than what they are
these days.
Thanks!
>
> Signed-off-by: Arve Hjønnevåg <arve@android.com>
> ---
> arch/arm/kernel/etm.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++---
> 1 files changed, 46 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/kernel/etm.c b/arch/arm/kernel/etm.c
> index bc7d8f2..8a1c422 100644
> --- a/arch/arm/kernel/etm.c
> +++ b/arch/arm/kernel/etm.c
> @@ -40,12 +40,17 @@ struct tracectx {
> unsigned long flags;
> int ncmppairs;
> int etm_portsz;
> + unsigned long range_start;
> + unsigned long range_end;
> struct device *dev;
> struct clk *emu_clk;
> struct mutex mutex;
> };
>
> -static struct tracectx tracer;
> +static struct tracectx tracer = {
> + .range_start = (unsigned long)_stext,
> + .range_end = (unsigned long)_etext,
> +};
>
> static inline bool trace_isrunning(struct tracectx *t)
> {
> @@ -115,8 +120,12 @@ static int trace_start(struct tracectx *t)
> return -EFAULT;
> }
>
> - etm_setup_address_range(t, 1, (unsigned long)_stext,
> - (unsigned long)_etext, 0, 0);
> + if (t->range_start || t->range_end)
> + etm_setup_address_range(t, 1,
> + t->range_start, t->range_end, 0, 0);
> + else
> + etm_writel(t, ETMTE_INCLEXCL, ETMR_TRACEENCTRL);
> +
> etm_writel(t, 0, ETMR_TRACEENCTRL2);
> etm_writel(t, 0, ETMR_TRACESSCTRL);
> etm_writel(t, 0x6f, ETMR_TRACEENEVT);
> @@ -525,6 +534,35 @@ static ssize_t trace_mode_store(struct kobject *kobj,
> static struct kobj_attribute trace_mode_attr =
> __ATTR(trace_mode, 0644, trace_mode_show, trace_mode_store);
>
> +static ssize_t trace_range_show(struct kobject *kobj,
> + struct kobj_attribute *attr,
> + char *buf)
> +{
> + return sprintf(buf, "%08lx %08lx\n",
> + tracer.range_start, tracer.range_end);
> +}
> +
> +static ssize_t trace_range_store(struct kobject *kobj,
> + struct kobj_attribute *attr,
> + const char *buf, size_t n)
> +{
> + unsigned long range_start, range_end;
> +
> + if (sscanf(buf, "%lx %lx", &range_start, &range_end) != 2)
> + return -EINVAL;
> +
> + mutex_lock(&tracer.mutex);
> + tracer.range_start = range_start;
> + tracer.range_end = range_end;
> + mutex_unlock(&tracer.mutex);
> +
> + return n;
> +}
> +
> +
> +static struct kobj_attribute trace_range_attr =
> + __ATTR(trace_range, 0644, trace_range_show, trace_range_store);
> +
> static int __init etm_probe(struct amba_device *dev, struct amba_id *id)
> {
> struct tracectx *t = &tracer;
> @@ -576,6 +614,10 @@ static int __init etm_probe(struct amba_device *dev, struct amba_id *id)
> if (ret)
> dev_dbg(&dev->dev, "Failed to create trace_mode in sysfs\n");
>
> + ret = sysfs_create_file(&dev->dev.kobj, &trace_range_attr.attr);
> + if (ret)
> + dev_dbg(&dev->dev, "Failed to create trace_range in sysfs\n");
> +
> dev_dbg(t->dev, "ETM AMBA driver initialized.\n");
>
> out:
> @@ -605,6 +647,7 @@ static int etm_remove(struct amba_device *dev)
> sysfs_remove_file(&dev->dev.kobj, &trace_running_attr.attr);
> sysfs_remove_file(&dev->dev.kobj, &trace_info_attr.attr);
> sysfs_remove_file(&dev->dev.kobj, &trace_mode_attr.attr);
> + sysfs_remove_file(&dev->dev.kobj, &trace_range_attr.attr);
>
> return 0;
> }
> --
> 1.7.3.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
From: David Cohen @ 2011-02-15 13:44 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: Hiroshi.DOYU, tony, linux-omap, linux-arm-kernel
In-Reply-To: <4D5A81D8.2080800@ru.mvista.com>
On Tue, Feb 15, 2011 at 3:38 PM, Sergei Shtylyov <sshtylyov@mvista.com> wrote:
> Hello.
Hi,
>
> On 15-02-2011 16:20, David Cohen wrote:
>
>> IOMMU upper layer is already printing error message. OMAP2+ specific
>> layer may print error message only for debug purpose.
>
>> Signed-off-by: David Cohen<dacohen@gmail.com>
>> ---
>> arch/arm/mach-omap2/iommu2.c | 6 +++---
>> 1 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
>> index 14ee686..4244a07 100644
>> --- a/arch/arm/mach-omap2/iommu2.c
>> +++ b/arch/arm/mach-omap2/iommu2.c
>> @@ -163,13 +163,13 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj,
>> u32 *ra)
>> da = iommu_read_reg(obj, MMU_FAULT_AD);
>> *ra = da;
>>
>> - dev_err(obj->dev, "%s:\tda:%08x ", __func__, da);
>> + dev_dbg(obj->dev, "%s:\tda:%08x ", __func__, da);
>
> Note that dev_dbg() will only print something if either DEBUG or
> CONFIG_DYNAMIC_DEBUG are defined...
That's my plan.
>
>>
>> for (i = 0; i< ARRAY_SIZE(err_msg); i++) {
>> if (stat & (1<< i))
>> - printk("%s ", err_msg[i]);
>> + printk(KERN_DEBUG "%s ", err_msg[i]);
>
> ... unlike printk(KERN_DEBUG...). You probably want to use pr_debug()
> instead.
>
>> }
>> - printk("\n");
>> + printk(KERN_DEBUG "\n");
>
> Here too... Although wait, it should be KERN_CONT instead! Debug levels
> are only attributed to the whole lines.
But your observation is correct. I'll resend it with KERN_CONT instead.
Regards,
David
>
> WBR, Sergei
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
From: Sergei Shtylyov @ 2011-02-15 13:38 UTC (permalink / raw)
To: David Cohen; +Cc: Hiroshi.DOYU, tony, linux-omap, linux-arm-kernel
In-Reply-To: <1297776033-8579-2-git-send-email-dacohen@gmail.com>
Hello.
On 15-02-2011 16:20, David Cohen wrote:
> IOMMU upper layer is already printing error message. OMAP2+ specific
> layer may print error message only for debug purpose.
> Signed-off-by: David Cohen<dacohen@gmail.com>
> ---
> arch/arm/mach-omap2/iommu2.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
> index 14ee686..4244a07 100644
> --- a/arch/arm/mach-omap2/iommu2.c
> +++ b/arch/arm/mach-omap2/iommu2.c
> @@ -163,13 +163,13 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra)
> da = iommu_read_reg(obj, MMU_FAULT_AD);
> *ra = da;
>
> - dev_err(obj->dev, "%s:\tda:%08x ", __func__, da);
> + dev_dbg(obj->dev, "%s:\tda:%08x ", __func__, da);
Note that dev_dbg() will only print something if either DEBUG or
CONFIG_DYNAMIC_DEBUG are defined...
>
> for (i = 0; i< ARRAY_SIZE(err_msg); i++) {
> if (stat & (1<< i))
> - printk("%s ", err_msg[i]);
> + printk(KERN_DEBUG "%s ", err_msg[i]);
... unlike printk(KERN_DEBUG...). You probably want to use pr_debug() instead.
> }
> - printk("\n");
> + printk(KERN_DEBUG "\n");
Here too... Although wait, it should be KERN_CONT instead! Debug levels
are only attributed to the whole lines.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 0/2] IOMMU fault callback support
From: David Cohen @ 2011-02-15 13:32 UTC (permalink / raw)
To: Hiroshi.DOYU; +Cc: linux-omap, linux-arm-kernel, tony
In-Reply-To: <1297776033-8579-1-git-send-email-dacohen@gmail.com>
A missing prefix in the cover letter's subject. It's: OMAP: IOMMU:
Br,
David
On Tue, Feb 15, 2011 at 3:20 PM, David Cohen <dacohen@gmail.com> wrote:
> Hi,
>
> This patch set adds fault callback support to allow IOMMU users to debug or
> react when a fault happens.
> IOMMU faults might be very difficult to reproduce and then to figure out
> the source of the problem. Currently IOMMU driver prints not so useful
> debug message and does not notice user about such issue.
> With a fault callback, IOMMU user may debug much more useful information
> and/or react to go back to a valid state.
>
> Br,
>
> David
> ---
>
> David Cohen (2):
> OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
> OMAP: IOMMU: add support to callback during fault handling
>
> arch/arm/mach-omap2/iommu2.c | 27 ++++++++++++++++----
> arch/arm/plat-omap/include/plat/iommu.h | 15 ++++++++++-
> arch/arm/plat-omap/iommu.c | 41 ++++++++++++++++++++++++++++---
> 3 files changed, 72 insertions(+), 11 deletions(-)
>
> --
> 1.7.2.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 2/2] OMAP: IOMMU: add support to callback during fault handling
From: David Cohen @ 2011-02-15 13:20 UTC (permalink / raw)
To: Hiroshi.DOYU; +Cc: linux-omap, linux-arm-kernel, tony
In-Reply-To: <1297776033-8579-1-git-send-email-dacohen@gmail.com>
Add support to register a callback for IOMMU fault situations. Drivers using
IOMMU module might want to be informed when such errors happen in order to
debug it or react.
Signed-off-by: David Cohen <dacohen@gmail.com>
---
arch/arm/mach-omap2/iommu2.c | 21 +++++++++++++--
arch/arm/plat-omap/include/plat/iommu.h | 15 ++++++++++-
arch/arm/plat-omap/iommu.c | 41 ++++++++++++++++++++++++++++---
3 files changed, 69 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 4244a07..559a066 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -143,10 +143,10 @@ static void omap2_iommu_set_twl(struct iommu *obj, bool on)
__iommu_set_twl(obj, false);
}
-static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra)
+static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra, u32 *iommu_errs)
{
int i;
- u32 stat, da;
+ u32 stat, da, errs;
const char *err_msg[] = {
"tlb miss",
"translation fault",
@@ -157,8 +157,10 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra)
stat = iommu_read_reg(obj, MMU_IRQSTATUS);
stat &= MMU_IRQ_MASK;
- if (!stat)
+ if (!stat) {
+ *iommu_errs = 0;
return 0;
+ }
da = iommu_read_reg(obj, MMU_FAULT_AD);
*ra = da;
@@ -171,6 +173,19 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra)
}
printk(KERN_DEBUG "\n");
+ errs = 0;
+ if (stat & MMU_IRQ_TLBMISS)
+ errs |= OMAP_IOMMU_ERR_TLB_MISS;
+ if (stat & MMU_IRQ_TRANSLATIONFAULT)
+ errs |= OMAP_IOMMU_ERR_TRANS_FAULT;
+ if (stat & MMU_IRQ_EMUMISS)
+ errs |= OMAP_IOMMU_ERR_EMU_MISS;
+ if (stat & MMU_IRQ_TABLEWALKFAULT)
+ errs |= OMAP_IOMMU_ERR_TBLWALK_FAULT;
+ if (stat & MMU_IRQ_MULTIHITFAULT)
+ errs |= OMAP_IOMMU_ERR_MULTIHIT_FAULT;
+ *iommu_errs = errs;
+
iommu_write_reg(obj, stat, MMU_IRQSTATUS);
return stat;
diff --git a/arch/arm/plat-omap/include/plat/iommu.h b/arch/arm/plat-omap/include/plat/iommu.h
index 19cbb5e..5a2475f 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -31,6 +31,7 @@ struct iommu {
struct clk *clk;
void __iomem *regbase;
struct device *dev;
+ void *fault_cb_priv;
unsigned int refcount;
struct mutex iommu_lock; /* global for this whole object */
@@ -48,6 +49,7 @@ struct iommu {
struct mutex mmap_lock; /* protect mmap */
int (*isr)(struct iommu *obj);
+ void (*fault_cb)(struct iommu *obj, u32 da, u32 iommu_errs, void *priv);
void *ctx; /* iommu context: registres saved area */
u32 da_start;
@@ -83,7 +85,7 @@ struct iommu_functions {
int (*enable)(struct iommu *obj);
void (*disable)(struct iommu *obj);
void (*set_twl)(struct iommu *obj, bool on);
- u32 (*fault_isr)(struct iommu *obj, u32 *ra);
+ u32 (*fault_isr)(struct iommu *obj, u32 *ra, u32 *iommu_errs);
void (*tlb_read_cr)(struct iommu *obj, struct cr_regs *cr);
void (*tlb_load_cr)(struct iommu *obj, struct cr_regs *cr);
@@ -109,6 +111,13 @@ struct iommu_platform_data {
u32 da_end;
};
+/* IOMMU errors */
+#define OMAP_IOMMU_ERR_TLB_MISS (1 << 0)
+#define OMAP_IOMMU_ERR_TRANS_FAULT (1 << 1)
+#define OMAP_IOMMU_ERR_EMU_MISS (1 << 2)
+#define OMAP_IOMMU_ERR_TBLWALK_FAULT (1 << 3)
+#define OMAP_IOMMU_ERR_MULTIHIT_FAULT (1 << 4)
+
#if defined(CONFIG_ARCH_OMAP1)
#error "iommu for this processor not implemented yet"
#else
@@ -161,6 +170,10 @@ extern size_t iopgtable_clear_entry(struct iommu *obj, u32 iova);
extern int iommu_set_da_range(struct iommu *obj, u32 start, u32 end);
extern struct iommu *iommu_get(const char *name);
extern void iommu_put(struct iommu *obj);
+extern int iommu_set_fault_callback(const char *name,
+ void (*fault_cb)(struct iommu *obj, u32 da,
+ u32 errs, void *priv),
+ void *fault_cb_priv);
extern void iommu_save_ctx(struct iommu *obj);
extern void iommu_restore_ctx(struct iommu *obj);
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index b1107c0..7f780ee 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -163,9 +163,9 @@ static u32 get_iopte_attr(struct iotlb_entry *e)
return arch_iommu->get_pte_attr(e);
}
-static u32 iommu_report_fault(struct iommu *obj, u32 *da)
+static u32 iommu_report_fault(struct iommu *obj, u32 *da, u32 *iommu_errs)
{
- return arch_iommu->fault_isr(obj, da);
+ return arch_iommu->fault_isr(obj, da, iommu_errs);
}
static void iotlb_lock_get(struct iommu *obj, struct iotlb_lock *l)
@@ -780,7 +780,7 @@ static void iopgtable_clear_entry_all(struct iommu *obj)
*/
static irqreturn_t iommu_fault_handler(int irq, void *data)
{
- u32 stat, da;
+ u32 stat, da, errs;
u32 *iopgd, *iopte;
int err = -EIO;
struct iommu *obj = data;
@@ -796,13 +796,19 @@ static irqreturn_t iommu_fault_handler(int irq, void *data)
return IRQ_HANDLED;
clk_enable(obj->clk);
- stat = iommu_report_fault(obj, &da);
+ stat = iommu_report_fault(obj, &da, &errs);
clk_disable(obj->clk);
if (!stat)
return IRQ_HANDLED;
iommu_disable(obj);
+ if (obj->fault_cb) {
+ obj->fault_cb(obj, da, errs, obj->fault_cb_priv);
+ /* No need to print error message as callback is called */
+ return IRQ_NONE;
+ }
+
iopgd = iopgd_offset(obj, da);
if (!iopgd_is_table(*iopgd)) {
@@ -917,6 +923,33 @@ void iommu_put(struct iommu *obj)
}
EXPORT_SYMBOL_GPL(iommu_put);
+int iommu_set_fault_callback(const char *name,
+ void (*fault_cb)(struct iommu *obj, u32 da,
+ u32 iommu_errs, void *priv),
+ void *fault_cb_priv)
+{
+ struct device *dev;
+ struct iommu *obj;
+
+ dev = driver_find_device(&omap_iommu_driver.driver, NULL, (void *)name,
+ device_match_by_alias);
+ if (!dev)
+ return -ENODEV;
+
+ obj = to_iommu(dev);
+ mutex_lock(&obj->iommu_lock);
+ if (obj->refcount != 0) {
+ mutex_unlock(&obj->iommu_lock);
+ return -EBUSY;
+ }
+ obj->fault_cb = fault_cb;
+ obj->fault_cb_priv = fault_cb_priv;
+ mutex_unlock(&obj->iommu_lock);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(iommu_set_fault_callback);
+
/*
* OMAP Device MMU(IOMMU) detection
*/
--
1.7.2.3
^ permalink raw reply related
* [PATCH 1/2] OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
From: David Cohen @ 2011-02-15 13:20 UTC (permalink / raw)
To: Hiroshi.DOYU; +Cc: linux-omap, linux-arm-kernel, tony
In-Reply-To: <1297776033-8579-1-git-send-email-dacohen@gmail.com>
IOMMU upper layer is already printing error message. OMAP2+ specific
layer may print error message only for debug purpose.
Signed-off-by: David Cohen <dacohen@gmail.com>
---
arch/arm/mach-omap2/iommu2.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 14ee686..4244a07 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -163,13 +163,13 @@ static u32 omap2_iommu_fault_isr(struct iommu *obj, u32 *ra)
da = iommu_read_reg(obj, MMU_FAULT_AD);
*ra = da;
- dev_err(obj->dev, "%s:\tda:%08x ", __func__, da);
+ dev_dbg(obj->dev, "%s:\tda:%08x ", __func__, da);
for (i = 0; i < ARRAY_SIZE(err_msg); i++) {
if (stat & (1 << i))
- printk("%s ", err_msg[i]);
+ printk(KERN_DEBUG "%s ", err_msg[i]);
}
- printk("\n");
+ printk(KERN_DEBUG "\n");
iommu_write_reg(obj, stat, MMU_IRQSTATUS);
--
1.7.2.3
^ permalink raw reply related
* [PATCH 0/2] IOMMU fault callback support
From: David Cohen @ 2011-02-15 13:20 UTC (permalink / raw)
To: Hiroshi.DOYU; +Cc: linux-omap, linux-arm-kernel, tony
Hi,
This patch set adds fault callback support to allow IOMMU users to debug or
react when a fault happens.
IOMMU faults might be very difficult to reproduce and then to figure out
the source of the problem. Currently IOMMU driver prints not so useful
debug message and does not notice user about such issue.
With a fault callback, IOMMU user may debug much more useful information
and/or react to go back to a valid state.
Br,
David
---
David Cohen (2):
OMAP2+: IOMMU: change OMAP2+ error message to dev_dbg()
OMAP: IOMMU: add support to callback during fault handling
arch/arm/mach-omap2/iommu2.c | 27 ++++++++++++++++----
arch/arm/plat-omap/include/plat/iommu.h | 15 ++++++++++-
arch/arm/plat-omap/iommu.c | 41 ++++++++++++++++++++++++++++---
3 files changed, 72 insertions(+), 11 deletions(-)
--
1.7.2.3
^ permalink raw reply
* Re: [PATCH v2] OMAP: IOMMU: add missing function declaration
From: Hiroshi DOYU @ 2011-02-15 13:09 UTC (permalink / raw)
To: dacohen, tony; +Cc: linux-omap, linux-arm-kernel
In-Reply-To: <1297769473-24052-1-git-send-email-dacohen@gmail.com>
From: David Cohen <dacohen@gmail.com>
Subject: [PATCH v2] OMAP: IOMMU: add missing function declaration
Date: Tue, 15 Feb 2011 13:31:13 +0200
> Declaration of exported function 'iopgtable_lookup_entry' is missing from
> header file. Currently we have a sparse warning as it's not being used
> externally. Adding its declaration to avoid such warning and allow its usage
> in future.
>
> Signed-off-by: David Cohen <dacohen@gmail.com>
> ---
> arch/arm/plat-omap/include/plat/iommu.h | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
Thanks. Tony, Please put this into your queue.
^ permalink raw reply
* Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
From: Linus Walleij @ 2011-02-15 12:58 UTC (permalink / raw)
To: Eduardo Valentin
Cc: LKML, linux-arm-kernel, Linux-OMAP, Russell King, Andrew Morton,
ext Tony Lindgren, ext Kevin Hilman, Peter De-Schrijver,
santosh.shilimkar, Ambresh, felipe.balbi, Jouni Hogander,
Paul Mundt, Lee Jones, maxime.coquelin-nonst, Jonas Åberg
In-Reply-To: <1273587331-24604-1-git-send-email-eduardo.valentin@nokia.com>
2010/5/11 Eduardo Valentin <eduardo.valentin@nokia.com>:
> Here is the version 5 of the change to export OMAP data to userspace
> (name, revision, id code, production id and die id).
>
> Basically, this version is still attempting to create a new file under /proc.
> It is the /proc/socinfo, which should be used to export bits which are SoC specific
> (not CPU related, nor machine related).
>
> So, differences between previous version are:
> - merged patch 02/04 with 03/04 to avoid compilation breakages.
> - simplified the seq_file usage by using the single_open and single_release functions
> - exported a function to register a seq_operation .show callback
> - adapted the changes accordingly
>
> As usual, comments are welcome.
Eduardo, what has happened to this patchset?
Now we need something similar for arch/arm/mach-ux500 and I was sort of
hoping that this infrastructure would be in place already... wrong I was.
Do you want help in picking it up and try to polish it up?
Yours,
Linus Walleij
^ permalink raw reply
* Re: OMAP: DSS2: Common IRQ handler for all OMAPs
From: Cousson, Benoit @ 2011-02-15 12:56 UTC (permalink / raw)
To: Taneja, Archit
Cc: Semwal, Sumit, Balbi, Felipe, linux-omap@vger.kernel.org,
Valkeinen, Tomi
In-Reply-To: <4D5A74F2.1060100@ti.com>
On 2/15/2011 1:43 PM, Taneja, Archit wrote:
> Hi,
>
> <snip>
>
>>>>>
>>>>> Is it okay to have the same irq entry for 2 different hwmods?
>>>>> This requirement comes from OMAP3 where dispc and dsi have a common irq
>>>>> line, where as on OMAP4 dispc and dsi have separate irq lines.
>>>>
>>>> Well, no. I explained that in one of my comment about hwmod modification.
>>>> The hwmod data are reflecting the exact HW capabilities.
>>>> So, if there is a change in the HW, the hwmod will be different.
>>>> It is up to the driver to adapt to this change.
>>> I guess what Archit wanted to say is, for hw IPs DISPC and DSI, on
>>> OMAP3, have a common IRQ line, so could both their hwmod databases
>>> have the same IRQ added for them? This would us call, for a common IRQ
>>> line shared w/ DISPC and DSI, like
>>> mentioned in Tomi's sample code above.
>>
>> OK, thanks for the clarification, actually I missed a little bit the
>> point :-(
>>
>> So in fact the 2 modules share that same IRQ today, and you just want to
>> populate both hwmod with the same input.
>> If this is a real OR between the two IRQ lines, meaning the dispc cannot
>> mask the dsi IRQ or the opposite, then having the same IRQ number in the
>> two different hwmods is a correct representation of the HW.
>
> There is a real OR between the 2 irq lines in OMAP3, as there is no
> DSS_IRQENABLE, but there is a DSS_IRQSTATUS.
>
> You can mask one of DISPC or DSI by zeroing all the bits in
> DISPC_IRQENABLE or DSI_IRQENABLE respectively. But there is no higher
> level register to mask them.
That's perfect then, and it deserves the duplication of this irq number
for both hwmods.
Regards,
Benoit
^ permalink raw reply
* [PATCH 6/6] arm: omap2: clksel: fix compile warning
From: Felipe Balbi @ 2011-02-15 12:49 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Linux OMAP Mailing List, Felipe Balbi
In-Reply-To: <1297774156-23312-1-git-send-email-balbi@ti.com>
Fix the following compile warning:
arch/arm/mach-omap2/clkt_clksel.c: In function '_get_div_and_fieldval':
arch/arm/mach-omap2/clkt_clksel.c:100:35: warning: 'max_clkr' may be
used uninitialized in this function
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
arch/arm/mach-omap2/clkt_clksel.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt_clksel.c b/arch/arm/mach-omap2/clkt_clksel.c
index a781cd6..e25364d 100644
--- a/arch/arm/mach-omap2/clkt_clksel.c
+++ b/arch/arm/mach-omap2/clkt_clksel.c
@@ -97,7 +97,7 @@ static u8 _get_div_and_fieldval(struct clk *src_clk, struct clk *clk,
u32 *field_val)
{
const struct clksel *clks;
- const struct clksel_rate *clkr, *max_clkr;
+ const struct clksel_rate *clkr, *max_clkr = NULL;
u8 max_div = 0;
clks = _get_clksel_by_parent(clk, src_clk);
--
1.7.4.rc2
^ permalink raw reply related
* [PATCH 5/6] arm: omap2: irq: fix compile warning:
From: Felipe Balbi @ 2011-02-15 12:49 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Linux OMAP Mailing List, Felipe Balbi
In-Reply-To: <1297774156-23312-1-git-send-email-balbi@ti.com>
Fix the following compile warning:
arch/arm/mach-omap2/irq.c:64:31: warning: 'intc_context' defined but not
used
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
arch/arm/mach-omap2/irq.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 23049c4..d151aac 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -61,8 +61,6 @@ struct omap3_intc_regs {
u32 mir[INTCPS_NR_MIR_REGS];
};
-static struct omap3_intc_regs intc_context[ARRAY_SIZE(irq_banks)];
-
/* INTC bank register get/set */
static void intc_bank_write_reg(u32 val, struct omap_irq_bank *bank, u16 reg)
@@ -229,6 +227,8 @@ void __init omap_init_irq(void)
}
#ifdef CONFIG_ARCH_OMAP3
+static struct omap3_intc_regs intc_context[ARRAY_SIZE(irq_banks)];
+
void omap_intc_save_context(void)
{
int ind = 0, i = 0;
--
1.7.4.rc2
^ permalink raw reply related
* [PATCH 4/6] arm: omap1: fix a bunch of section mismatches
From: Felipe Balbi @ 2011-02-15 12:49 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Linux OMAP Mailing List, Felipe Balbi
In-Reply-To: <1297774156-23312-1-git-send-email-balbi@ti.com>
Fix the following section mismatches:
WARNING: arch/arm/mach-omap1/built-in.o(.data+0x491c): Section mismatch
in reference from the variable fsample_config to the (unknown reference)
.init.data:(unknown)
The variable fsample_config references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the
variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
WARNING: arch/arm/mach-omap1/built-in.o(.data+0x8f0c): Section mismatch
in reference from the variable ams_delta_config to the (unknown
reference) .init.data:(unknown)
The variable ams_delta_config references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the
variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
WARNING: arch/arm/mach-omap1/built-in.o(.data+0x93ac): Section mismatch
in reference from the variable ams_delta_camera_device to the (unknown
reference) .init.data:(unknown)
The variable ams_delta_camera_device references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the
variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
WARNING: vmlinux.o(.data+0x5e94): Section mismatch in reference from the
variable fsample_config to the (unknown reference) .init.data:(unknown)
The variable fsample_config references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the
variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
WARNING: vmlinux.o(.data+0xa484): Section mismatch in reference from the
variable ams_delta_config to the (unknown reference)
.init.data:(unknown)
The variable ams_delta_config references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the
variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
WARNING: vmlinux.o(.data+0xa924): Section mismatch in reference from the
variable ams_delta_camera_device to the (unknown reference)
.init.data:(unknown)
The variable ams_delta_camera_device references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the
variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
arch/arm/mach-omap1/board-ams-delta.c | 14 +++++++-------
arch/arm/mach-omap1/board-fsample.c | 2 +-
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c b/arch/arm/mach-omap1/board-ams-delta.c
index 22cc8c8..2f446a2 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -165,7 +165,7 @@ static struct map_desc ams_delta_io_desc[] __initdata = {
}
};
-static struct omap_lcd_config ams_delta_lcd_config __initdata = {
+static struct omap_lcd_config ams_delta_lcd_config = {
.ctrl_name = "internal",
};
@@ -208,14 +208,14 @@ static const struct matrix_keymap_data ams_delta_keymap_data = {
.keymap_size = ARRAY_SIZE(ams_delta_keymap),
};
-static struct omap_kp_platform_data ams_delta_kp_data = {
+static struct omap_kp_platform_data ams_delta_kp_data __initdata = {
.rows = 8,
.cols = 8,
.keymap_data = &ams_delta_keymap_data,
.delay = 9,
};
-static struct platform_device ams_delta_kp_device = {
+static struct platform_device ams_delta_kp_device __initdata = {
.name = "omap-keypad",
.id = -1,
.dev = {
@@ -225,12 +225,12 @@ static struct platform_device ams_delta_kp_device = {
.resource = ams_delta_kp_resources,
};
-static struct platform_device ams_delta_lcd_device = {
+static struct platform_device ams_delta_lcd_device __initdata = {
.name = "lcd_ams_delta",
.id = -1,
};
-static struct platform_device ams_delta_led_device = {
+static struct platform_device ams_delta_led_device __initdata = {
.name = "ams-delta-led",
.id = -1
};
@@ -259,7 +259,7 @@ static int ams_delta_camera_power(struct device *dev, int power)
#define ams_delta_camera_power NULL
#endif
-static struct soc_camera_link __initdata ams_delta_iclink = {
+static struct soc_camera_link ams_delta_iclink __initdata = {
.bus_id = 0, /* OMAP1 SoC camera bus */
.i2c_adapter_id = 1,
.board_info = &ams_delta_camera_board_info[0],
@@ -267,7 +267,7 @@ static struct soc_camera_link __initdata ams_delta_iclink = {
.power = ams_delta_camera_power,
};
-static struct platform_device ams_delta_camera_device = {
+static struct platform_device ams_delta_camera_device __initdata = {
.name = "soc-camera-pdrv",
.id = 0,
.dev = {
diff --git a/arch/arm/mach-omap1/board-fsample.c b/arch/arm/mach-omap1/board-fsample.c
index 0efb9db..27fb1be 100644
--- a/arch/arm/mach-omap1/board-fsample.c
+++ b/arch/arm/mach-omap1/board-fsample.c
@@ -287,7 +287,7 @@ static struct platform_device *devices[] __initdata = {
&lcd_device,
};
-static struct omap_lcd_config fsample_lcd_config __initdata = {
+static struct omap_lcd_config fsample_lcd_config = {
.ctrl_name = "internal",
};
--
1.7.4.rc2
^ permalink raw reply related
* [PATCH 3/6] arm: omap1: fix compile warnings
From: Felipe Balbi @ 2011-02-15 12:49 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Linux OMAP Mailing List, Felipe Balbi
In-Reply-To: <1297774156-23312-1-git-send-email-balbi@ti.com>
Fix the following compile warnings:
arch/arm/mach-omap1/board-innovator.c:165:3: warning: initialization
makes integer from pointer without a cast
arch/arm/mach-omap1/board-perseus2.c:305:3: warning: initialization
makes integer from pointer without a cast
arch/arm/mach-omap1/board-fsample.c:338:3: warning: initialization makes
integer from pointer without a cast
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
arch/arm/plat-omap/include/plat/fpga.h | 92 ++++++++++++++++----------------
1 files changed, 46 insertions(+), 46 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/fpga.h b/arch/arm/plat-omap/include/plat/fpga.h
index ae39bcb..bd3c632 100644
--- a/arch/arm/plat-omap/include/plat/fpga.h
+++ b/arch/arm/plat-omap/include/plat/fpga.h
@@ -30,18 +30,18 @@ extern void omap1510_fpga_init_irq(void);
* ---------------------------------------------------------------------------
*/
/* maps in the FPGA registers and the ETHR registers */
-#define H2P2_DBG_FPGA_BASE IOMEM(0xE8000000) /* VA */
+#define H2P2_DBG_FPGA_BASE 0xE8000000 /* VA */
#define H2P2_DBG_FPGA_SIZE SZ_4K /* SIZE */
#define H2P2_DBG_FPGA_START 0x04000000 /* PA */
#define H2P2_DBG_FPGA_ETHR_START (H2P2_DBG_FPGA_START + 0x300)
-#define H2P2_DBG_FPGA_FPGA_REV (H2P2_DBG_FPGA_BASE + 0x10) /* FPGA Revision */
-#define H2P2_DBG_FPGA_BOARD_REV (H2P2_DBG_FPGA_BASE + 0x12) /* Board Revision */
-#define H2P2_DBG_FPGA_GPIO (H2P2_DBG_FPGA_BASE + 0x14) /* GPIO outputs */
-#define H2P2_DBG_FPGA_LEDS (H2P2_DBG_FPGA_BASE + 0x16) /* LEDs outputs */
-#define H2P2_DBG_FPGA_MISC_INPUTS (H2P2_DBG_FPGA_BASE + 0x18) /* Misc inputs */
-#define H2P2_DBG_FPGA_LAN_STATUS (H2P2_DBG_FPGA_BASE + 0x1A) /* LAN Status line */
-#define H2P2_DBG_FPGA_LAN_RESET (H2P2_DBG_FPGA_BASE + 0x1C) /* LAN Reset line */
+#define H2P2_DBG_FPGA_FPGA_REV IOMEM(H2P2_DBG_FPGA_BASE + 0x10) /* FPGA Revision */
+#define H2P2_DBG_FPGA_BOARD_REV IOMEM(H2P2_DBG_FPGA_BASE + 0x12) /* Board Revision */
+#define H2P2_DBG_FPGA_GPIO IOMEM(H2P2_DBG_FPGA_BASE + 0x14) /* GPIO outputs */
+#define H2P2_DBG_FPGA_LEDS IOMEM(H2P2_DBG_FPGA_BASE + 0x16) /* LEDs outputs */
+#define H2P2_DBG_FPGA_MISC_INPUTS IOMEM(H2P2_DBG_FPGA_BASE + 0x18) /* Misc inputs */
+#define H2P2_DBG_FPGA_LAN_STATUS IOMEM(H2P2_DBG_FPGA_BASE + 0x1A) /* LAN Status line */
+#define H2P2_DBG_FPGA_LAN_RESET IOMEM(H2P2_DBG_FPGA_BASE + 0x1C) /* LAN Reset line */
/* NOTE: most boards don't have a static mapping for the FPGA ... */
struct h2p2_dbg_fpga {
@@ -81,55 +81,55 @@ struct h2p2_dbg_fpga {
* OMAP-1510 FPGA
* ---------------------------------------------------------------------------
*/
-#define OMAP1510_FPGA_BASE IOMEM(0xE8000000) /* VA */
+#define OMAP1510_FPGA_BASE 0xE8000000 /* VA */
#define OMAP1510_FPGA_SIZE SZ_4K
#define OMAP1510_FPGA_START 0x08000000 /* PA */
/* Revision */
-#define OMAP1510_FPGA_REV_LOW (OMAP1510_FPGA_BASE + 0x0)
-#define OMAP1510_FPGA_REV_HIGH (OMAP1510_FPGA_BASE + 0x1)
+#define OMAP1510_FPGA_REV_LOW IOMEM(OMAP1510_FPGA_BASE + 0x0)
+#define OMAP1510_FPGA_REV_HIGH IOMEM(OMAP1510_FPGA_BASE + 0x1)
-#define OMAP1510_FPGA_LCD_PANEL_CONTROL (OMAP1510_FPGA_BASE + 0x2)
-#define OMAP1510_FPGA_LED_DIGIT (OMAP1510_FPGA_BASE + 0x3)
-#define INNOVATOR_FPGA_HID_SPI (OMAP1510_FPGA_BASE + 0x4)
-#define OMAP1510_FPGA_POWER (OMAP1510_FPGA_BASE + 0x5)
+#define OMAP1510_FPGA_LCD_PANEL_CONTROL IOMEM(OMAP1510_FPGA_BASE + 0x2)
+#define OMAP1510_FPGA_LED_DIGIT IOMEM(OMAP1510_FPGA_BASE + 0x3)
+#define INNOVATOR_FPGA_HID_SPI IOMEM(OMAP1510_FPGA_BASE + 0x4)
+#define OMAP1510_FPGA_POWER IOMEM(OMAP1510_FPGA_BASE + 0x5)
/* Interrupt status */
-#define OMAP1510_FPGA_ISR_LO (OMAP1510_FPGA_BASE + 0x6)
-#define OMAP1510_FPGA_ISR_HI (OMAP1510_FPGA_BASE + 0x7)
+#define OMAP1510_FPGA_ISR_LO IOMEM(OMAP1510_FPGA_BASE + 0x6)
+#define OMAP1510_FPGA_ISR_HI IOMEM(OMAP1510_FPGA_BASE + 0x7)
/* Interrupt mask */
-#define OMAP1510_FPGA_IMR_LO (OMAP1510_FPGA_BASE + 0x8)
-#define OMAP1510_FPGA_IMR_HI (OMAP1510_FPGA_BASE + 0x9)
+#define OMAP1510_FPGA_IMR_LO IOMEM(OMAP1510_FPGA_BASE + 0x8)
+#define OMAP1510_FPGA_IMR_HI IOMEM(OMAP1510_FPGA_BASE + 0x9)
/* Reset registers */
-#define OMAP1510_FPGA_HOST_RESET (OMAP1510_FPGA_BASE + 0xa)
-#define OMAP1510_FPGA_RST (OMAP1510_FPGA_BASE + 0xb)
-
-#define OMAP1510_FPGA_AUDIO (OMAP1510_FPGA_BASE + 0xc)
-#define OMAP1510_FPGA_DIP (OMAP1510_FPGA_BASE + 0xe)
-#define OMAP1510_FPGA_FPGA_IO (OMAP1510_FPGA_BASE + 0xf)
-#define OMAP1510_FPGA_UART1 (OMAP1510_FPGA_BASE + 0x14)
-#define OMAP1510_FPGA_UART2 (OMAP1510_FPGA_BASE + 0x15)
-#define OMAP1510_FPGA_OMAP1510_STATUS (OMAP1510_FPGA_BASE + 0x16)
-#define OMAP1510_FPGA_BOARD_REV (OMAP1510_FPGA_BASE + 0x18)
-#define OMAP1510P1_PPT_DATA (OMAP1510_FPGA_BASE + 0x100)
-#define OMAP1510P1_PPT_STATUS (OMAP1510_FPGA_BASE + 0x101)
-#define OMAP1510P1_PPT_CONTROL (OMAP1510_FPGA_BASE + 0x102)
-
-#define OMAP1510_FPGA_TOUCHSCREEN (OMAP1510_FPGA_BASE + 0x204)
-
-#define INNOVATOR_FPGA_INFO (OMAP1510_FPGA_BASE + 0x205)
-#define INNOVATOR_FPGA_LCD_BRIGHT_LO (OMAP1510_FPGA_BASE + 0x206)
-#define INNOVATOR_FPGA_LCD_BRIGHT_HI (OMAP1510_FPGA_BASE + 0x207)
-#define INNOVATOR_FPGA_LED_GRN_LO (OMAP1510_FPGA_BASE + 0x208)
-#define INNOVATOR_FPGA_LED_GRN_HI (OMAP1510_FPGA_BASE + 0x209)
-#define INNOVATOR_FPGA_LED_RED_LO (OMAP1510_FPGA_BASE + 0x20a)
-#define INNOVATOR_FPGA_LED_RED_HI (OMAP1510_FPGA_BASE + 0x20b)
-#define INNOVATOR_FPGA_CAM_USB_CONTROL (OMAP1510_FPGA_BASE + 0x20c)
-#define INNOVATOR_FPGA_EXP_CONTROL (OMAP1510_FPGA_BASE + 0x20d)
-#define INNOVATOR_FPGA_ISR2 (OMAP1510_FPGA_BASE + 0x20e)
-#define INNOVATOR_FPGA_IMR2 (OMAP1510_FPGA_BASE + 0x210)
+#define OMAP1510_FPGA_HOST_RESET IOMEM(OMAP1510_FPGA_BASE + 0xa)
+#define OMAP1510_FPGA_RST IOMEM(OMAP1510_FPGA_BASE + 0xb)
+
+#define OMAP1510_FPGA_AUDIO IOMEM(OMAP1510_FPGA_BASE + 0xc)
+#define OMAP1510_FPGA_DIP IOMEM(OMAP1510_FPGA_BASE + 0xe)
+#define OMAP1510_FPGA_FPGA_IO IOMEM(OMAP1510_FPGA_BASE + 0xf)
+#define OMAP1510_FPGA_UART1 IOMEM(OMAP1510_FPGA_BASE + 0x14)
+#define OMAP1510_FPGA_UART2 IOMEM(OMAP1510_FPGA_BASE + 0x15)
+#define OMAP1510_FPGA_OMAP1510_STATUS IOMEM(OMAP1510_FPGA_BASE + 0x16)
+#define OMAP1510_FPGA_BOARD_REV IOMEM(OMAP1510_FPGA_BASE + 0x18)
+#define OMAP1510P1_PPT_DATA IOMEM(OMAP1510_FPGA_BASE + 0x100)
+#define OMAP1510P1_PPT_STATUS IOMEM(OMAP1510_FPGA_BASE + 0x101)
+#define OMAP1510P1_PPT_CONTROL IOMEM(OMAP1510_FPGA_BASE + 0x102)
+
+#define OMAP1510_FPGA_TOUCHSCREEN IOMEM(OMAP1510_FPGA_BASE + 0x204)
+
+#define INNOVATOR_FPGA_INFO IOMEM(OMAP1510_FPGA_BASE + 0x205)
+#define INNOVATOR_FPGA_LCD_BRIGHT_LO IOMEM(OMAP1510_FPGA_BASE + 0x206)
+#define INNOVATOR_FPGA_LCD_BRIGHT_HI IOMEM(OMAP1510_FPGA_BASE + 0x207)
+#define INNOVATOR_FPGA_LED_GRN_LO IOMEM(OMAP1510_FPGA_BASE + 0x208)
+#define INNOVATOR_FPGA_LED_GRN_HI IOMEM(OMAP1510_FPGA_BASE + 0x209)
+#define INNOVATOR_FPGA_LED_RED_LO IOMEM(OMAP1510_FPGA_BASE + 0x20a)
+#define INNOVATOR_FPGA_LED_RED_HI IOMEM(OMAP1510_FPGA_BASE + 0x20b)
+#define INNOVATOR_FPGA_CAM_USB_CONTROL IOMEM(OMAP1510_FPGA_BASE + 0x20c)
+#define INNOVATOR_FPGA_EXP_CONTROL IOMEM(OMAP1510_FPGA_BASE + 0x20d)
+#define INNOVATOR_FPGA_ISR2 IOMEM(OMAP1510_FPGA_BASE + 0x20e)
+#define INNOVATOR_FPGA_IMR2 IOMEM(OMAP1510_FPGA_BASE + 0x210)
#define OMAP1510_FPGA_ETHR_START (OMAP1510_FPGA_START + 0x300)
--
1.7.4.rc2
^ permalink raw reply related
* [PATCH 2/6] arm: omap1: fix compile warning
From: Felipe Balbi @ 2011-02-15 12:49 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Linux OMAP Mailing List, Felipe Balbi
In-Reply-To: <1297774156-23312-1-git-send-email-balbi@ti.com>
Fix the following compile warning:
arch/arm/mach-omap1/board-palmte.c:233:13: warning:
'palmte_headphones_detect' defined but not used
Signed-off-by: Felipe Balbi <balbi@ti.com>
---
arch/arm/mach-omap1/board-palmte.c | 13 -------------
1 files changed, 0 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap1/board-palmte.c b/arch/arm/mach-omap1/board-palmte.c
index fb51ce6..c9d38f4 100644
--- a/arch/arm/mach-omap1/board-palmte.c
+++ b/arch/arm/mach-omap1/board-palmte.c
@@ -230,19 +230,6 @@ static struct spi_board_info palmte_spi_info[] __initdata = {
},
};
-static void palmte_headphones_detect(void *data, int state)
-{
- if (state) {
- /* Headphones connected, disable speaker */
- gpio_set_value(PALMTE_SPEAKER_GPIO, 0);
- printk(KERN_INFO "PM: speaker off\n");
- } else {
- /* Headphones unplugged, re-enable speaker */
- gpio_set_value(PALMTE_SPEAKER_GPIO, 1);
- printk(KERN_INFO "PM: speaker on\n");
- }
-}
-
static void __init palmte_misc_gpio_setup(void)
{
/* Set TSC2102 PINTDAV pin as input (used by TSC2102 driver) */
--
1.7.4.rc2
^ permalink raw reply related
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