* [RFC/NOT FOR MERGING 1/5] arm: omap: fix up _od_suspend_noirq and _od_resume_noirq
From: Kevin Hilman @ 2012-10-18 20:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018193440.GA8609@arwen.pp.htv.fi>
Felipe Balbi <balbi@ti.com> writes:
[...]
> ps: I'll continue reading the code and further test my series to see
> if I can understand what you say here.
OK. And please get it working in cases where drivers are using I2C in
their suspend/resume (and even late/early) paths, and also where device
runtime PM is disabled from userspace. All of that works with today's
code and will not work with your proposed code.
Kevin
^ permalink raw reply
* [PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
From: Mauro Carvalho Chehab @ 2012-10-18 20:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018202842.11834.14375.stgit@muffinssi.local>
Tony,
Em Thu, 18 Oct 2012 13:28:42 -0700
Tony Lindgren <tony@atomide.com> escreveu:
> Looks like the iommu framework does not have generic functions
> exported for all the needs yet. The hardware specific functions
> are defined in files like intel-iommu.h and amd-iommu.h. Follow
> the same standard for omap-iommu.h.
>
> This is needed because we are removing plat and mach includes
> for ARM common zImage support. Further work should continue
> in the iommu framework context as only pure platform data will
> be communicated from arch/arm/*omap*/* code to the iommu
> framework.
>
> Cc: Joerg Roedel <joerg.roedel@amd.com>
> Cc: Ohad Ben-Cohen <ohad@wizery.com>
> Cc: Ido Yariv <ido@wizery.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
> Cc: Omar Ramirez Luna <omar.luna@linaro.org>
> Cc: linux-media at vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/mach-omap2/iommu2.c | 1
> arch/arm/plat-omap/include/plat/iommu.h | 10 +--
> arch/arm/plat-omap/include/plat/iovmm.h | 89 ----------------------------
> drivers/iommu/omap-iommu-debug.c | 2 -
> drivers/iommu/omap-iommu.c | 1
> drivers/iommu/omap-iovmm.c | 46 ++++++++++++++
> drivers/media/platform/omap3isp/isp.c | 1
> drivers/media/platform/omap3isp/isp.h | 2 -
> drivers/media/platform/omap3isp/ispccdc.c | 1
> drivers/media/platform/omap3isp/ispstat.c | 1
> drivers/media/platform/omap3isp/ispvideo.c | 2 -
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It is better if you send this entire series through the ARM tree, keeping
this hole series altogether (and avoiding the risk of breaking bisectability
if it goes through separate trees). So, you can add my ack for those header
moves for drivers/media/platform/*.
Regards,
Mauro
--
Cheers,
Mauro
^ permalink raw reply
* [PATCHv1] arm:socfpga: Enable SMP for socfpga
From: Rob Herring @ 2012-10-18 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADhT+wcJmwRMeNugWdgY+aU4EGE-y48R6OePTq==TjZajuxfeA@mail.gmail.com>
On 10/17/2012 10:34 PM, Dinh Nguyen wrote:
> Hi Rob,
>
> On Wed, Oct 17, 2012 at 2:07 PM, Rob Herring <robherring2@gmail.com> wrote:
>>
>> On 10/17/2012 02:18 PM, dinguyen at altera.com wrote:
>>> From: Dinh Nguyen <dinguyen@altera.com>
>>>
>>> Enable SMP for the SOCFPGA platform.
>>>
>>> Signed-off-by: Pavel Machek <pavel@denx.de>
>>> Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
>>> ---
>>> arch/arm/boot/dts/socfpga.dtsi | 10 ++
>>> arch/arm/configs/socfpga_defconfig | 9 +-
>>
>> Does the multi_v7_defconfig not work for you?
>
> It does. Are you planning to remove the defconfigs the platforms that
> are part of
> multi_v7_defconfig soon? socfpga_defconfig is broken with SMP enabled because
> it needs +# CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA is not set.
I don't plan to remove them. I'll leave it up to the platform
maintainers as the new multi_v7 config is not exactly the same selections.
That's strange that you care about the errata setting. I think it should
work either way. We do need to scrub the errata list and enable all the
ones which have no runtime impact and are conditioned on the core
revision. I'm not sure what we'll do with the ones that could have a
negative impact on performance of rev's without an errata.
Rob
^ permalink raw reply
* Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
From: Vaibhav Hiremath @ 2012-10-18 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018184443.GD2350@netboy.at.omicron.at>
On 10/19/2012 12:14 AM, Richard Cochran wrote:
> On Thu, Oct 18, 2012 at 03:46:15AM +0000, Paul Walmsley wrote:
>>
>> Probably the driver was submitted before any SoC integration support was
>> available. Grepping for 'cpsw' under arch/ turns up only AM33xx. AM335x
>> didn't have device enumeration support in the mainline kernel until 3.7,
>> via commit a2cfc509bc4eeef9f5c4607b1203f17f22ea2a36 ("ARM: OMAP3+: hwmod:
>> Add AM33XX HWMOD data"). So I don't see how it could have worked with
>> mainline.
>
> ...
>
>> But it seems that the CPSW has never worked in the mainline kernel. So
>> this particular patch is not fixing a regression. Therefore we shouldn't
>> send it upstream during the -rc time period. Instead we'll schedule it to
>> be sent a few weeks later, during the 3.8 merge window.
>
> Let's think about this some more:
>
> The driver's commit is from March and is included in v3.4-rc1.
>
> You say it will be working in 3.8, after 3.7 comes out, in about
> December.
>
> So how long does it take between merging code and actually getting it
> working?
>
> Sorry to harp on this so much, but I try out my patches with the tip
> of the appropriate tree before sending them, or when I cannot, at
> least I put into the log "compile tested only" or something like that.
>
Another important point is, this driver is also required and used for
Davinci family of devices (arch/mach/mach-davinci/).
Thanks,
Vaibhav
> Thanks,
> Richard
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
From: Vaibhav Hiremath @ 2012-10-18 20:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121017181354.GA2412@netboy.at.omicron.at>
On 10/17/2012 11:43 PM, Richard Cochran wrote:
> Paul,
>
> Would you please take this bugfix for 3.7-rc2? The suggestion to mail
> you came from Toni Lindgren. The context where it came from is here:
>
> http://lists.arm.linux.org.uk/lurker/message/20121015.191630.bdae3c50.en.html
>
> Thanks,
> Richard
>
> ----- Forwarded message from Richard Cochran <richardcochran@gmail.com> -----
>
> Date: Mon, 15 Oct 2012 21:16:32 +0200
> From: Richard Cochran <richardcochran@gmail.com>
> To: netdev at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org, Arnd Bergmann <arnd@arndb.de>,
> David Miller <davem@davemloft.net>,
> Russell King <linux@arm.linux.org.uk>,
> Mugunthan V N <mugunthanvnm@ti.com>
> Subject: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
> X-Mailer: git-send-email 1.7.2.5
>
> From: Mugunthan V N <mugunthanvnm@ti.com>
>
> This patch adds minimal hwmod support for davinci mdio driver. This patch
> requires rework on parent child relation between cpsw and davinci mdio
> hwmod data to support runtime PM.
>
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> ---
> arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 34 ++++++++++++++++++++++++++-
> 1 files changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> index 59d5c1c..f96bbc0 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
> @@ -650,8 +650,7 @@ static struct omap_hwmod_class_sysconfig am33xx_cpgmac_sysc = {
> .rev_offs = 0x0,
> .sysc_offs = 0x8,
> .syss_offs = 0x4,
> - .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE |
> - SYSS_HAS_RESET_STATUS),
> + .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
> .idlemodes = (SIDLE_FORCE | SIDLE_NO | MSTANDBY_FORCE |
> MSTANDBY_NO),
> .sysc_fields = &omap_hwmod_sysc_type3,
> @@ -682,6 +681,8 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = {
> .modulemode = MODULEMODE_SWCTRL,
> },
> },
> + .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
> + HWMOD_INIT_NO_RESET | HWMOD_INIT_NO_IDLE),
Hey Richard,
I feel you have picked up this patch in premature state, I didn't like
this NO_RESET and NO_IDLE flag to be set for MDIO.
Couple of reasons,
1. These flags were added for validation, so I expect cpsw driver
should work without these flags set. I tested it mounting NFS as rootFS
and it works for me.
2. There is HW bug as far as idle (in turn ocp reset) is concerned, and
needs special handling for this. I already have patch for this, which I
will submit it to the list.
http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=a28da2ac98f173f97dbbb46be1ce0a3879f21a11
Note: Sorry for long commit description, it was screwed up by someone
while git push.
I have pushed the tested branch to (linux-omap/master + CPSW patches) -
https://github.com/hvaibhav/am335x-linux/tree/am335x-upstream-staging
Thanks,
Vaibhav
> };
>
> /*
> @@ -2510,6 +2511,34 @@ static struct omap_hwmod_addr_space am33xx_elm_addr_space[] = {
> { }
> };
>
> +/* mdio class */
> +static struct omap_hwmod_class am33xx_mdio_hwmod_class = {
> + .name = "davinci_mdio",
> +};
> +
> +struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
> + {
> + .pa_start = 0x4A101000,
> + .pa_end = 0x4A101000 + SZ_256 - 1,
> + .flags = ADDR_MAP_ON_INIT,
> + },
> + { }
> +};
> +
> +static struct omap_hwmod am33xx_mdio_hwmod = {
> + .name = "davinci_mdio",
> + .class = &am33xx_mdio_hwmod_class,
> + .clkdm_name = "cpsw_125mhz_clkdm",
> + .main_clk = "cpsw_125mhz_gclk",
> +};
> +
> +struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
> + .master = &am33xx_cpgmac0_hwmod,
> + .slave = &am33xx_mdio_hwmod,
> + .addr = am33xx_mdio_addr_space,
> + .user = OCP_USER_MPU,
> +};
> +
> static struct omap_hwmod_ocp_if am33xx_l4_ls__elm = {
> .master = &am33xx_l4_ls_hwmod,
> .slave = &am33xx_elm_hwmod,
> @@ -3371,6 +3400,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
> &am33xx_l3_main__tptc2,
> &am33xx_l3_s__usbss,
> &am33xx_l4_hs__cpgmac0,
> + &am33xx_cpgmac0__mdio,
> NULL,
> };
>
>
^ permalink raw reply
* [RFC/NOT FOR MERGING 1/5] arm: omap: fix up _od_suspend_noirq and _od_resume_noirq
From: Kevin Hilman @ 2012-10-18 20:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018193440.GA8609@arwen.pp.htv.fi>
Felipe Balbi <balbi@ti.com> writes:
[...]
> if the device implements none of the suspend methods, then you
> shouldn't suspend it at all, because you'd be masking a bug in the
> driver, IMHO.
OK, let's start over here, because here's the fundamental difference. I
don't think missing suspend methods means a bug in the driver at all.
For a moment, let's ignore the limitations/restrictions that exist today
betwen system PM and runtime PM and assume runtime PM can be used
anytime, including anywhere in the suspend/resume path.
In that ideal world, many drivers would not need system suspend methods
at all. They would just runtime PM to enable/disable themselves based
on driver/device activity.
Stated differently, since the driver is using runtime PM, when system
suspend happens, the device is already idle, and runtime suspended, so
there is nothing for the system PM methods to do. Therefore, no system
PM callbacks are needed. No bug in driver.
(yes, this is oversimplified to illustrate the goal/point. Some drivers
may want to have a ->suspend callback to wait/stop any current
processing, but that is just so runtime PM can kick in.)
This is the "runtime PM centric" view of things that we have been
driving towards with OMAP drivers (we've been doing this with aggressive
clock gating even before runtime PM framework.)
In other words, if drivers are written with this "runtime PM centric"
view, there should be almost nothing to do in the suspend method, except
quiesce the hardware so runtime PM kicks in.
This runtime PM centric view is the mindset/philosophy behind the PM
domain implementation, and driver PM adaptations that we've been doing
for some time.
In converting/reviewing/testing *many* drivers that have been PM adapted
(for system PM and runtime PM), most folks do not get this right.
Therfore, if driver writers can concentrate on runtime PM, and just use
system PM as a "quiesce HW, let runtime PM take over" method, that is
where I want to go.
Kevin
^ permalink raw reply
* [PATCH 3/4] ARM: OMAP2+: Move iommu/iovmm headers to platform_data
From: Tony Lindgren @ 2012-10-18 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018162512.GD30550@atomide.com>
* Tony Lindgren <tony@atomide.com> [121018 09:27]:
> * Laurent Pinchart <laurent.pinchart@ideasonboard.com> [121018 06:45]:
> > Hi,
> >
> > On Monday 15 October 2012 17:36:40 Tony Lindgren wrote:
> > > From: Ido Yariv <ido@wizery.com>
> > >
> > > Move iommu/iovmm headers from plat/ to platform_data/ as part of the
> > > single zImage work.
> >
> > Is that really where those headers belong ? iommu-omap.h contains far more
> > than platform data, and iovmm-omap.h contains no platform data at all.
>
> Hmm I though that was already fixed by Ido but looks like there are
> non-platform data things still remaining there.
>
> Looking at arch/arm/mach-omap2/iommu2.c it seems that it should moved to
> drivers/iommu/omap-iommu2.c and that way most of the header can be local
> in drivers/iommu/omap-iommu.h. I'll do some patches for that and repost.
I ended up solving the iovmm-omap.h issue by adding include/linux/omap-iommu.h
like intel and amd have.
Reposted the series as "[PATCH v3 0/6] omap iommu changes to remove plat includes".
Regards,
Tony
^ permalink raw reply
* [PATCH 6/6] ARM: OMAP2+: Move iommu/iovmm headers to platform_data
From: Tony Lindgren @ 2012-10-18 20:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018202707.11834.1438.stgit@muffinssi.local>
Move iommu/iovmm headers from plat/ to platform_data/ as part of the
single zImage work.
Partially based on an earlier version by Ido Yariv <ido@wizery.com>.
Cc: Joerg Roedel <joerg.roedel@amd.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Ido Yariv <ido@wizery.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Omar Ramirez Luna <omar.luna@linaro.org>
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/devices.c | 2 +-
arch/arm/mach-omap2/omap-iommu.c | 2 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 2 +-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2 +-
drivers/iommu/omap-iommu-debug.c | 3 +--
drivers/iommu/omap-iommu.c | 2 +-
drivers/iommu/omap-iommu2.c | 2 +-
drivers/iommu/omap-iovmm.c | 3 +--
drivers/media/platform/omap3isp/ispvideo.c | 1 -
include/linux/platform_data/iommu-omap.h | 0
10 files changed, 8 insertions(+), 11 deletions(-)
rename arch/arm/plat-omap/include/plat/iommu.h => include/linux/platform_data/iommu-omap.h (100%)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c8c2117..6cd0c2a 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -126,7 +126,7 @@ static struct platform_device omap2cam_device = {
#if defined(CONFIG_IOMMU_API)
-#include <plat/iommu.h>
+#include <linux/platform_data/iommu-omap.h>
static struct resource omap3isp_resources[] = {
{
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index df298d4..a6a4ff8 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -13,7 +13,7 @@
#include <linux/module.h>
#include <linux/platform_device.h>
-#include <plat/iommu.h>
+#include <linux/platform_data/iommu-omap.h>
#include "soc.h"
#include "common.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index f67b7ee..621bc71 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -26,8 +26,8 @@
#include <plat/mmc.h>
#include <linux/platform_data/asoc-ti-mcbsp.h>
#include <linux/platform_data/spi-omap2-mcspi.h>
+#include <linux/platform_data/iommu-omap.h>
#include <plat/dmtimer.h>
-#include <plat/iommu.h>
#include "am35xx.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 652d028..5850b3e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -27,10 +27,10 @@
#include <plat/dma.h>
#include <linux/platform_data/spi-omap2-mcspi.h>
#include <linux/platform_data/asoc-ti-mcbsp.h>
+#include <linux/platform_data/iommu-omap.h>
#include <plat/mmc.h>
#include <plat/dmtimer.h>
#include <plat/common.h>
-#include <plat/iommu.h>
#include "omap_hwmod_common_data.h"
#include "cm1_44xx.h"
diff --git a/drivers/iommu/omap-iommu-debug.c b/drivers/iommu/omap-iommu-debug.c
index d0427bd..d97fbe4 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -19,8 +19,7 @@
#include <linux/platform_device.h>
#include <linux/debugfs.h>
#include <linux/omap-iommu.h>
-
-#include <plat/iommu.h>
+#include <linux/platform_data/iommu-omap.h>
#include "omap-iopgtable.h"
#include "omap-iommu.h"
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index df84087..badc17c 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -26,7 +26,7 @@
#include <asm/cacheflush.h>
-#include <plat/iommu.h>
+#include <linux/platform_data/iommu-omap.h>
#include "omap-iopgtable.h"
#include "omap-iommu.h"
diff --git a/drivers/iommu/omap-iommu2.c b/drivers/iommu/omap-iommu2.c
index 4d8d91d..3642cf2 100644
--- a/drivers/iommu/omap-iommu2.c
+++ b/drivers/iommu/omap-iommu2.c
@@ -19,8 +19,8 @@
#include <linux/stringify.h>
#include <linux/io.h>
#include <linux/omap-iommu.h>
+#include <linux/platform_data/iommu-omap.h>
-#include <plat/iommu.h>
#include "omap-iommu.h"
/*
diff --git a/drivers/iommu/omap-iovmm.c b/drivers/iommu/omap-iovmm.c
index 3e3b242..46d87569 100644
--- a/drivers/iommu/omap-iovmm.c
+++ b/drivers/iommu/omap-iovmm.c
@@ -18,12 +18,11 @@
#include <linux/scatterlist.h>
#include <linux/iommu.h>
#include <linux/omap-iommu.h>
+#include <linux/platform_data/iommu-omap.h>
#include <asm/cacheflush.h>
#include <asm/mach/map.h>
-#include <plat/iommu.h>
-
#include "omap-iopgtable.h"
#include "omap-iommu.h"
diff --git a/drivers/media/platform/omap3isp/ispvideo.c b/drivers/media/platform/omap3isp/ispvideo.c
index 2853bef..3bfa245 100644
--- a/drivers/media/platform/omap3isp/ispvideo.c
+++ b/drivers/media/platform/omap3isp/ispvideo.c
@@ -35,7 +35,6 @@
#include <linux/omap-iommu.h>
#include <media/v4l2-dev.h>
#include <media/v4l2-ioctl.h>
-#include <plat/iommu.h>
#include <plat/omap-pm.h>
#include "ispvideo.h"
diff --git a/arch/arm/plat-omap/include/plat/iommu.h b/include/linux/platform_data/iommu-omap.h
similarity index 100%
rename from arch/arm/plat-omap/include/plat/iommu.h
rename to include/linux/platform_data/iommu-omap.h
^ permalink raw reply related
* [PATCH 5/6] ARM: OMAP2+: Make some definitions local
From: Tony Lindgren @ 2012-10-18 20:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018202707.11834.1438.stgit@muffinssi.local>
From: Ido Yariv <ido@wizery.com>
Move some of the definitions in omap-iommu.h that can be made local to
either drivers/iommu.
Cc: Joerg Roedel <joerg.roedel@amd.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Omar Ramirez Luna <omar.luna@linaro.org>
Signed-off-by: Ido Yariv <ido@wizery.com>
[tony at atomide.com: updated for header changes in the series]
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
drivers/iommu/omap-iommu.c | 15 +++++++++++++++
drivers/iommu/omap-iommu.h | 33 +++------------------------------
drivers/iommu/omap-iommu2.c | 6 ++++++
3 files changed, 24 insertions(+), 30 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 4db86e1..df84087 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -54,6 +54,21 @@ struct omap_iommu_domain {
spinlock_t lock;
};
+#define MMU_LOCK_BASE_SHIFT 10
+#define MMU_LOCK_BASE_MASK (0x1f << MMU_LOCK_BASE_SHIFT)
+#define MMU_LOCK_BASE(x) \
+ ((x & MMU_LOCK_BASE_MASK) >> MMU_LOCK_BASE_SHIFT)
+
+#define MMU_LOCK_VICT_SHIFT 4
+#define MMU_LOCK_VICT_MASK (0x1f << MMU_LOCK_VICT_SHIFT)
+#define MMU_LOCK_VICT(x) \
+ ((x & MMU_LOCK_VICT_MASK) >> MMU_LOCK_VICT_SHIFT)
+
+struct iotlb_lock {
+ short base;
+ short vict;
+};
+
/* accommodate the difference between omap1 and omap2/3 */
static const struct iommu_functions *arch_iommu;
diff --git a/drivers/iommu/omap-iommu.h b/drivers/iommu/omap-iommu.h
index 8c3378d..2b5f3c0 100644
--- a/drivers/iommu/omap-iommu.h
+++ b/drivers/iommu/omap-iommu.h
@@ -72,11 +72,6 @@ struct cr_regs {
};
};
-struct iotlb_lock {
- short base;
- short vict;
-};
-
/* architecture specific functions */
struct iommu_functions {
unsigned long version;
@@ -117,13 +112,6 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct device *dev)
}
#endif
-/* 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)
-
/*
* MMU Register offsets
*/
@@ -151,16 +139,6 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct device *dev)
/*
* MMU Register bit definitions
*/
-#define MMU_LOCK_BASE_SHIFT 10
-#define MMU_LOCK_BASE_MASK (0x1f << MMU_LOCK_BASE_SHIFT)
-#define MMU_LOCK_BASE(x) \
- ((x & MMU_LOCK_BASE_MASK) >> MMU_LOCK_BASE_SHIFT)
-
-#define MMU_LOCK_VICT_SHIFT 4
-#define MMU_LOCK_VICT_MASK (0x1f << MMU_LOCK_VICT_SHIFT)
-#define MMU_LOCK_VICT(x) \
- ((x & MMU_LOCK_VICT_MASK) >> MMU_LOCK_VICT_SHIFT)
-
#define MMU_CAM_VATAG_SHIFT 12
#define MMU_CAM_VATAG_MASK \
((~0UL >> MMU_CAM_VATAG_SHIFT) << MMU_CAM_VATAG_SHIFT)
@@ -222,20 +200,15 @@ extern void omap_iotlb_cr_to_e(struct cr_regs *cr, struct iotlb_entry *e);
extern int
omap_iopgtable_store_entry(struct omap_iommu *obj, struct iotlb_entry *e);
-extern int omap_iommu_set_isr(const char *name,
- int (*isr)(struct omap_iommu *obj, u32 da, u32 iommu_errs,
- void *priv),
- void *isr_priv);
-
extern void omap_iommu_save_ctx(struct device *dev);
extern void omap_iommu_restore_ctx(struct device *dev);
-extern int omap_install_iommu_arch(const struct iommu_functions *ops);
-extern void omap_uninstall_iommu_arch(const struct iommu_functions *ops);
-
extern int omap_foreach_iommu_device(void *data,
int (*fn)(struct device *, void *));
+extern int omap_install_iommu_arch(const struct iommu_functions *ops);
+extern void omap_uninstall_iommu_arch(const struct iommu_functions *ops);
+
extern ssize_t
omap_iommu_dump_ctx(struct omap_iommu *obj, char *buf, ssize_t len);
extern size_t
diff --git a/drivers/iommu/omap-iommu2.c b/drivers/iommu/omap-iommu2.c
index 066e6b2..4d8d91d 100644
--- a/drivers/iommu/omap-iommu2.c
+++ b/drivers/iommu/omap-iommu2.c
@@ -68,6 +68,12 @@
((pgsz) == MMU_CAM_PGSZ_64K) ? 0xffff0000 : \
((pgsz) == MMU_CAM_PGSZ_4K) ? 0xfffff000 : 0)
+/* 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)
static void __iommu_set_twl(struct omap_iommu *obj, bool on)
{
^ permalink raw reply related
* [PATCH 4/6] ARM: OMAP2+: Move iommu2 to drivers/iommu/omap-iommu2.c
From: Tony Lindgren @ 2012-10-18 20:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018202707.11834.1438.stgit@muffinssi.local>
This file should not be in arch/arm. Move it to drivers/iommu
to allow making most of the header local to drivers/iommu.
This is needed as we are removing plat and mach includes
from drivers for ARM common zImage support.
Cc: Joerg Roedel <joerg.roedel@amd.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Ido Yariv <ido@wizery.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Omar Ramirez Luna <omar.luna@linaro.org>
Cc: linux-media at vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/Makefile | 2
arch/arm/plat-omap/include/plat/iommu.h | 272 ++-----------------------------
drivers/iommu/Makefile | 1
drivers/iommu/omap-iommu-debug.c | 1
drivers/iommu/omap-iommu.c | 19 ++
drivers/iommu/omap-iommu.h | 255 +++++++++++++++++++++++++++++
drivers/iommu/omap-iommu2.c | 2
drivers/iommu/omap-iopgtable.h | 22 ---
drivers/iommu/omap-iovmm.c | 1
9 files changed, 293 insertions(+), 282 deletions(-)
create mode 100644 drivers/iommu/omap-iommu.h
rename arch/arm/mach-omap2/iommu2.c => drivers/iommu/omap-iommu2.c (99%)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fe40d9e..d6721a7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -184,8 +184,6 @@ obj-$(CONFIG_HW_PERF_EVENTS) += pmu.o
obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox_mach.o
mailbox_mach-objs := mailbox.o
-obj-$(CONFIG_OMAP_IOMMU) += iommu2.o
-
iommu-$(CONFIG_OMAP_IOMMU) := omap-iommu.o
obj-y += $(iommu-m) $(iommu-y)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h b/arch/arm/plat-omap/include/plat/iommu.h
index a4b71b1..c677b9f 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -10,103 +10,21 @@
* published by the Free Software Foundation.
*/
-#ifndef __MACH_IOMMU_H
-#define __MACH_IOMMU_H
-
-#include <linux/io.h>
-
-#if defined(CONFIG_ARCH_OMAP1)
-#error "iommu for this processor not implemented yet"
-#endif
-
-struct iotlb_entry {
- u32 da;
- u32 pa;
- u32 pgsz, prsvd, valid;
- union {
- u16 ap;
- struct {
- u32 endian, elsz, mixed;
- };
- };
-};
-
-struct omap_iommu {
- const char *name;
- struct module *owner;
- struct clk *clk;
- void __iomem *regbase;
- struct device *dev;
- void *isr_priv;
- struct iommu_domain *domain;
-
- unsigned int refcount;
- spinlock_t iommu_lock; /* global for this whole object */
-
- /*
- * We don't change iopgd for a situation like pgd for a task,
- * but share it globally for each iommu.
- */
- u32 *iopgd;
- spinlock_t page_table_lock; /* protect iopgd */
-
- int nr_tlb_entries;
-
- struct list_head mmap;
- struct mutex mmap_lock; /* protect mmap */
-
- void *ctx; /* iommu context: registres saved area */
- u32 da_start;
- u32 da_end;
-};
-
-struct cr_regs {
- union {
- struct {
- u16 cam_l;
- u16 cam_h;
- };
- u32 cam;
- };
- union {
- struct {
- u16 ram_l;
- u16 ram_h;
- };
- u32 ram;
- };
-};
-
-struct iotlb_lock {
- short base;
- short vict;
-};
-
-/* architecture specific functions */
-struct iommu_functions {
- unsigned long version;
-
- int (*enable)(struct omap_iommu *obj);
- void (*disable)(struct omap_iommu *obj);
- void (*set_twl)(struct omap_iommu *obj, bool on);
- u32 (*fault_isr)(struct omap_iommu *obj, u32 *ra);
-
- void (*tlb_read_cr)(struct omap_iommu *obj, struct cr_regs *cr);
- void (*tlb_load_cr)(struct omap_iommu *obj, struct cr_regs *cr);
-
- struct cr_regs *(*alloc_cr)(struct omap_iommu *obj,
- struct iotlb_entry *e);
- int (*cr_valid)(struct cr_regs *cr);
- u32 (*cr_to_virt)(struct cr_regs *cr);
- void (*cr_to_e)(struct cr_regs *cr, struct iotlb_entry *e);
- ssize_t (*dump_cr)(struct omap_iommu *obj, struct cr_regs *cr,
- char *buf);
-
- u32 (*get_pte_attr)(struct iotlb_entry *e);
+#define MMU_REG_SIZE 256
- void (*save_ctx)(struct omap_iommu *obj);
- void (*restore_ctx)(struct omap_iommu *obj);
- ssize_t (*dump_ctx)(struct omap_iommu *obj, char *buf, ssize_t len);
+/**
+ * struct iommu_arch_data - omap iommu private data
+ * @name: name of the iommu device
+ * @iommu_dev: handle of the iommu device
+ *
+ * This is an omap iommu private data object, which binds an iommu user
+ * to its iommu device. This object should be placed at the iommu user's
+ * dev_archdata so generic IOMMU API can be used without having to
+ * utilize omap-specific plumbing anymore.
+ */
+struct omap_iommu_arch_data {
+ const char *name;
+ struct omap_iommu *iommu_dev;
};
/**
@@ -129,165 +47,3 @@ struct iommu_platform_data {
u32 da_start;
u32 da_end;
};
-
-/**
- * struct iommu_arch_data - omap iommu private data
- * @name: name of the iommu device
- * @iommu_dev: handle of the iommu device
- *
- * This is an omap iommu private data object, which binds an iommu user
- * to its iommu device. This object should be placed at the iommu user's
- * dev_archdata so generic IOMMU API can be used without having to
- * utilize omap-specific plumbing anymore.
- */
-struct omap_iommu_arch_data {
- const char *name;
- struct omap_iommu *iommu_dev;
-};
-
-#ifdef CONFIG_IOMMU_API
-/**
- * dev_to_omap_iommu() - retrieves an omap iommu object from a user device
- * @dev: iommu client device
- */
-static inline struct omap_iommu *dev_to_omap_iommu(struct device *dev)
-{
- struct omap_iommu_arch_data *arch_data = dev->archdata.iommu;
-
- return arch_data->iommu_dev;
-}
-#endif
-
-/* 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)
-
-/*
- * MMU Register offsets
- */
-#define MMU_REVISION 0x00
-#define MMU_SYSCONFIG 0x10
-#define MMU_SYSSTATUS 0x14
-#define MMU_IRQSTATUS 0x18
-#define MMU_IRQENABLE 0x1c
-#define MMU_WALKING_ST 0x40
-#define MMU_CNTL 0x44
-#define MMU_FAULT_AD 0x48
-#define MMU_TTB 0x4c
-#define MMU_LOCK 0x50
-#define MMU_LD_TLB 0x54
-#define MMU_CAM 0x58
-#define MMU_RAM 0x5c
-#define MMU_GFLUSH 0x60
-#define MMU_FLUSH_ENTRY 0x64
-#define MMU_READ_CAM 0x68
-#define MMU_READ_RAM 0x6c
-#define MMU_EMU_FAULT_AD 0x70
-
-#define MMU_REG_SIZE 256
-
-/*
- * MMU Register bit definitions
- */
-#define MMU_LOCK_BASE_SHIFT 10
-#define MMU_LOCK_BASE_MASK (0x1f << MMU_LOCK_BASE_SHIFT)
-#define MMU_LOCK_BASE(x) \
- ((x & MMU_LOCK_BASE_MASK) >> MMU_LOCK_BASE_SHIFT)
-
-#define MMU_LOCK_VICT_SHIFT 4
-#define MMU_LOCK_VICT_MASK (0x1f << MMU_LOCK_VICT_SHIFT)
-#define MMU_LOCK_VICT(x) \
- ((x & MMU_LOCK_VICT_MASK) >> MMU_LOCK_VICT_SHIFT)
-
-#define MMU_CAM_VATAG_SHIFT 12
-#define MMU_CAM_VATAG_MASK \
- ((~0UL >> MMU_CAM_VATAG_SHIFT) << MMU_CAM_VATAG_SHIFT)
-#define MMU_CAM_P (1 << 3)
-#define MMU_CAM_V (1 << 2)
-#define MMU_CAM_PGSZ_MASK 3
-#define MMU_CAM_PGSZ_1M (0 << 0)
-#define MMU_CAM_PGSZ_64K (1 << 0)
-#define MMU_CAM_PGSZ_4K (2 << 0)
-#define MMU_CAM_PGSZ_16M (3 << 0)
-
-#define MMU_RAM_PADDR_SHIFT 12
-#define MMU_RAM_PADDR_MASK \
- ((~0UL >> MMU_RAM_PADDR_SHIFT) << MMU_RAM_PADDR_SHIFT)
-
-#define MMU_RAM_ENDIAN_MASK (1 << MMU_RAM_ENDIAN_SHIFT)
-#define MMU_RAM_ELSZ_MASK (3 << MMU_RAM_ELSZ_SHIFT)
-
-#define MMU_RAM_ELSZ_16 (1 << MMU_RAM_ELSZ_SHIFT)
-#define MMU_RAM_ELSZ_32 (2 << MMU_RAM_ELSZ_SHIFT)
-#define MMU_RAM_ELSZ_NONE (3 << MMU_RAM_ELSZ_SHIFT)
-#define MMU_RAM_MIXED_SHIFT 6
-#define MMU_RAM_MIXED_MASK (1 << MMU_RAM_MIXED_SHIFT)
-#define MMU_RAM_MIXED MMU_RAM_MIXED_MASK
-
-/*
- * utilities for super page(16MB, 1MB, 64KB and 4KB)
- */
-
-#define iopgsz_max(bytes) \
- (((bytes) >= SZ_16M) ? SZ_16M : \
- ((bytes) >= SZ_1M) ? SZ_1M : \
- ((bytes) >= SZ_64K) ? SZ_64K : \
- ((bytes) >= SZ_4K) ? SZ_4K : 0)
-
-#define bytes_to_iopgsz(bytes) \
- (((bytes) == SZ_16M) ? MMU_CAM_PGSZ_16M : \
- ((bytes) == SZ_1M) ? MMU_CAM_PGSZ_1M : \
- ((bytes) == SZ_64K) ? MMU_CAM_PGSZ_64K : \
- ((bytes) == SZ_4K) ? MMU_CAM_PGSZ_4K : -1)
-
-#define iopgsz_to_bytes(iopgsz) \
- (((iopgsz) == MMU_CAM_PGSZ_16M) ? SZ_16M : \
- ((iopgsz) == MMU_CAM_PGSZ_1M) ? SZ_1M : \
- ((iopgsz) == MMU_CAM_PGSZ_64K) ? SZ_64K : \
- ((iopgsz) == MMU_CAM_PGSZ_4K) ? SZ_4K : 0)
-
-#define iopgsz_ok(bytes) (bytes_to_iopgsz(bytes) >= 0)
-
-/*
- * global functions
- */
-extern u32 omap_iommu_arch_version(void);
-
-extern void omap_iotlb_cr_to_e(struct cr_regs *cr, struct iotlb_entry *e);
-
-extern int
-omap_iopgtable_store_entry(struct omap_iommu *obj, struct iotlb_entry *e);
-
-extern int omap_iommu_set_isr(const char *name,
- int (*isr)(struct omap_iommu *obj, u32 da, u32 iommu_errs,
- void *priv),
- void *isr_priv);
-
-extern int omap_install_iommu_arch(const struct iommu_functions *ops);
-extern void omap_uninstall_iommu_arch(const struct iommu_functions *ops);
-
-extern int omap_foreach_iommu_device(void *data,
- int (*fn)(struct device *, void *));
-
-extern ssize_t
-omap_iommu_dump_ctx(struct omap_iommu *obj, char *buf, ssize_t len);
-extern size_t
-omap_dump_tlb_entries(struct omap_iommu *obj, char *buf, ssize_t len);
-
-/*
- * register accessors
- */
-static inline u32 iommu_read_reg(struct omap_iommu *obj, size_t offs)
-{
- return __raw_readl(obj->regbase + offs);
-}
-
-static inline void iommu_write_reg(struct omap_iommu *obj, u32 val, size_t offs)
-{
- __raw_writel(val, obj->regbase + offs);
-}
-
-#endif /* __MACH_IOMMU_H */
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 14a4d5f..f66b816 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_DMAR_TABLE) += dmar.o
obj-$(CONFIG_INTEL_IOMMU) += iova.o intel-iommu.o
obj-$(CONFIG_IRQ_REMAP) += intel_irq_remapping.o irq_remapping.o
obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
+obj-$(CONFIG_OMAP_IOMMU) += omap-iommu2.o
obj-$(CONFIG_OMAP_IOVMM) += omap-iovmm.o
obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o
obj-$(CONFIG_TEGRA_IOMMU_GART) += tegra-gart.o
diff --git a/drivers/iommu/omap-iommu-debug.c b/drivers/iommu/omap-iommu-debug.c
index cf4a0b5..d0427bd 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -23,6 +23,7 @@
#include <plat/iommu.h>
#include "omap-iopgtable.h"
+#include "omap-iommu.h"
#define MAXCOLUMN 100 /* for short messages */
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index eadcfde..4db86e1 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -22,12 +22,14 @@
#include <linux/omap-iommu.h>
#include <linux/mutex.h>
#include <linux/spinlock.h>
+#include <linux/io.h>
#include <asm/cacheflush.h>
#include <plat/iommu.h>
#include "omap-iopgtable.h"
+#include "omap-iommu.h"
#define for_each_iotlb_cr(obj, n, __i, cr) \
for (__i = 0; \
@@ -1016,6 +1018,23 @@ static void iopte_cachep_ctor(void *iopte)
clean_dcache_area(iopte, IOPTE_TABLE_SIZE);
}
+static u32 iotlb_init_entry(struct iotlb_entry *e, u32 da, u32 pa,
+ u32 flags)
+{
+ memset(e, 0, sizeof(*e));
+
+ e->da = da;
+ e->pa = pa;
+ e->valid = 1;
+ /* FIXME: add OMAP1 support */
+ e->pgsz = flags & MMU_CAM_PGSZ_MASK;
+ e->endian = flags & MMU_RAM_ENDIAN_MASK;
+ e->elsz = flags & MMU_RAM_ELSZ_MASK;
+ e->mixed = flags & MMU_RAM_MIXED_MASK;
+
+ return iopgsz_to_bytes(e->pgsz);
+}
+
static int omap_iommu_map(struct iommu_domain *domain, unsigned long da,
phys_addr_t pa, size_t bytes, int prot)
{
diff --git a/drivers/iommu/omap-iommu.h b/drivers/iommu/omap-iommu.h
new file mode 100644
index 0000000..8c3378d
--- /dev/null
+++ b/drivers/iommu/omap-iommu.h
@@ -0,0 +1,255 @@
+/*
+ * omap iommu: main structures
+ *
+ * Copyright (C) 2008-2009 Nokia Corporation
+ *
+ * Written by Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#if defined(CONFIG_ARCH_OMAP1)
+#error "iommu for this processor not implemented yet"
+#endif
+
+struct iotlb_entry {
+ u32 da;
+ u32 pa;
+ u32 pgsz, prsvd, valid;
+ union {
+ u16 ap;
+ struct {
+ u32 endian, elsz, mixed;
+ };
+ };
+};
+
+struct omap_iommu {
+ const char *name;
+ struct module *owner;
+ struct clk *clk;
+ void __iomem *regbase;
+ struct device *dev;
+ void *isr_priv;
+ struct iommu_domain *domain;
+
+ unsigned int refcount;
+ spinlock_t iommu_lock; /* global for this whole object */
+
+ /*
+ * We don't change iopgd for a situation like pgd for a task,
+ * but share it globally for each iommu.
+ */
+ u32 *iopgd;
+ spinlock_t page_table_lock; /* protect iopgd */
+
+ int nr_tlb_entries;
+
+ struct list_head mmap;
+ struct mutex mmap_lock; /* protect mmap */
+
+ void *ctx; /* iommu context: registres saved area */
+ u32 da_start;
+ u32 da_end;
+};
+
+struct cr_regs {
+ union {
+ struct {
+ u16 cam_l;
+ u16 cam_h;
+ };
+ u32 cam;
+ };
+ union {
+ struct {
+ u16 ram_l;
+ u16 ram_h;
+ };
+ u32 ram;
+ };
+};
+
+struct iotlb_lock {
+ short base;
+ short vict;
+};
+
+/* architecture specific functions */
+struct iommu_functions {
+ unsigned long version;
+
+ int (*enable)(struct omap_iommu *obj);
+ void (*disable)(struct omap_iommu *obj);
+ void (*set_twl)(struct omap_iommu *obj, bool on);
+ u32 (*fault_isr)(struct omap_iommu *obj, u32 *ra);
+
+ void (*tlb_read_cr)(struct omap_iommu *obj, struct cr_regs *cr);
+ void (*tlb_load_cr)(struct omap_iommu *obj, struct cr_regs *cr);
+
+ struct cr_regs *(*alloc_cr)(struct omap_iommu *obj,
+ struct iotlb_entry *e);
+ int (*cr_valid)(struct cr_regs *cr);
+ u32 (*cr_to_virt)(struct cr_regs *cr);
+ void (*cr_to_e)(struct cr_regs *cr, struct iotlb_entry *e);
+ ssize_t (*dump_cr)(struct omap_iommu *obj, struct cr_regs *cr,
+ char *buf);
+
+ u32 (*get_pte_attr)(struct iotlb_entry *e);
+
+ void (*save_ctx)(struct omap_iommu *obj);
+ void (*restore_ctx)(struct omap_iommu *obj);
+ ssize_t (*dump_ctx)(struct omap_iommu *obj, char *buf, ssize_t len);
+};
+
+#ifdef CONFIG_IOMMU_API
+/**
+ * dev_to_omap_iommu() - retrieves an omap iommu object from a user device
+ * @dev: iommu client device
+ */
+static inline struct omap_iommu *dev_to_omap_iommu(struct device *dev)
+{
+ struct omap_iommu_arch_data *arch_data = dev->archdata.iommu;
+
+ return arch_data->iommu_dev;
+}
+#endif
+
+/* 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)
+
+/*
+ * MMU Register offsets
+ */
+#define MMU_REVISION 0x00
+#define MMU_SYSCONFIG 0x10
+#define MMU_SYSSTATUS 0x14
+#define MMU_IRQSTATUS 0x18
+#define MMU_IRQENABLE 0x1c
+#define MMU_WALKING_ST 0x40
+#define MMU_CNTL 0x44
+#define MMU_FAULT_AD 0x48
+#define MMU_TTB 0x4c
+#define MMU_LOCK 0x50
+#define MMU_LD_TLB 0x54
+#define MMU_CAM 0x58
+#define MMU_RAM 0x5c
+#define MMU_GFLUSH 0x60
+#define MMU_FLUSH_ENTRY 0x64
+#define MMU_READ_CAM 0x68
+#define MMU_READ_RAM 0x6c
+#define MMU_EMU_FAULT_AD 0x70
+
+#define MMU_REG_SIZE 256
+
+/*
+ * MMU Register bit definitions
+ */
+#define MMU_LOCK_BASE_SHIFT 10
+#define MMU_LOCK_BASE_MASK (0x1f << MMU_LOCK_BASE_SHIFT)
+#define MMU_LOCK_BASE(x) \
+ ((x & MMU_LOCK_BASE_MASK) >> MMU_LOCK_BASE_SHIFT)
+
+#define MMU_LOCK_VICT_SHIFT 4
+#define MMU_LOCK_VICT_MASK (0x1f << MMU_LOCK_VICT_SHIFT)
+#define MMU_LOCK_VICT(x) \
+ ((x & MMU_LOCK_VICT_MASK) >> MMU_LOCK_VICT_SHIFT)
+
+#define MMU_CAM_VATAG_SHIFT 12
+#define MMU_CAM_VATAG_MASK \
+ ((~0UL >> MMU_CAM_VATAG_SHIFT) << MMU_CAM_VATAG_SHIFT)
+#define MMU_CAM_P (1 << 3)
+#define MMU_CAM_V (1 << 2)
+#define MMU_CAM_PGSZ_MASK 3
+#define MMU_CAM_PGSZ_1M (0 << 0)
+#define MMU_CAM_PGSZ_64K (1 << 0)
+#define MMU_CAM_PGSZ_4K (2 << 0)
+#define MMU_CAM_PGSZ_16M (3 << 0)
+
+#define MMU_RAM_PADDR_SHIFT 12
+#define MMU_RAM_PADDR_MASK \
+ ((~0UL >> MMU_RAM_PADDR_SHIFT) << MMU_RAM_PADDR_SHIFT)
+
+#define MMU_RAM_ENDIAN_MASK (1 << MMU_RAM_ENDIAN_SHIFT)
+#define MMU_RAM_ENDIAN_BIG (1 << MMU_RAM_ENDIAN_SHIFT)
+
+#define MMU_RAM_ELSZ_MASK (3 << MMU_RAM_ELSZ_SHIFT)
+#define MMU_RAM_ELSZ_8 (0 << MMU_RAM_ELSZ_SHIFT)
+#define MMU_RAM_ELSZ_16 (1 << MMU_RAM_ELSZ_SHIFT)
+#define MMU_RAM_ELSZ_32 (2 << MMU_RAM_ELSZ_SHIFT)
+#define MMU_RAM_ELSZ_NONE (3 << MMU_RAM_ELSZ_SHIFT)
+#define MMU_RAM_MIXED_SHIFT 6
+#define MMU_RAM_MIXED_MASK (1 << MMU_RAM_MIXED_SHIFT)
+#define MMU_RAM_MIXED MMU_RAM_MIXED_MASK
+
+/*
+ * utilities for super page(16MB, 1MB, 64KB and 4KB)
+ */
+
+#define iopgsz_max(bytes) \
+ (((bytes) >= SZ_16M) ? SZ_16M : \
+ ((bytes) >= SZ_1M) ? SZ_1M : \
+ ((bytes) >= SZ_64K) ? SZ_64K : \
+ ((bytes) >= SZ_4K) ? SZ_4K : 0)
+
+#define bytes_to_iopgsz(bytes) \
+ (((bytes) == SZ_16M) ? MMU_CAM_PGSZ_16M : \
+ ((bytes) == SZ_1M) ? MMU_CAM_PGSZ_1M : \
+ ((bytes) == SZ_64K) ? MMU_CAM_PGSZ_64K : \
+ ((bytes) == SZ_4K) ? MMU_CAM_PGSZ_4K : -1)
+
+#define iopgsz_to_bytes(iopgsz) \
+ (((iopgsz) == MMU_CAM_PGSZ_16M) ? SZ_16M : \
+ ((iopgsz) == MMU_CAM_PGSZ_1M) ? SZ_1M : \
+ ((iopgsz) == MMU_CAM_PGSZ_64K) ? SZ_64K : \
+ ((iopgsz) == MMU_CAM_PGSZ_4K) ? SZ_4K : 0)
+
+#define iopgsz_ok(bytes) (bytes_to_iopgsz(bytes) >= 0)
+
+/*
+ * global functions
+ */
+extern u32 omap_iommu_arch_version(void);
+
+extern void omap_iotlb_cr_to_e(struct cr_regs *cr, struct iotlb_entry *e);
+
+extern int
+omap_iopgtable_store_entry(struct omap_iommu *obj, struct iotlb_entry *e);
+
+extern int omap_iommu_set_isr(const char *name,
+ int (*isr)(struct omap_iommu *obj, u32 da, u32 iommu_errs,
+ void *priv),
+ void *isr_priv);
+
+extern void omap_iommu_save_ctx(struct device *dev);
+extern void omap_iommu_restore_ctx(struct device *dev);
+
+extern int omap_install_iommu_arch(const struct iommu_functions *ops);
+extern void omap_uninstall_iommu_arch(const struct iommu_functions *ops);
+
+extern int omap_foreach_iommu_device(void *data,
+ int (*fn)(struct device *, void *));
+
+extern ssize_t
+omap_iommu_dump_ctx(struct omap_iommu *obj, char *buf, ssize_t len);
+extern size_t
+omap_dump_tlb_entries(struct omap_iommu *obj, char *buf, ssize_t len);
+
+/*
+ * register accessors
+ */
+static inline u32 iommu_read_reg(struct omap_iommu *obj, size_t offs)
+{
+ return __raw_readl(obj->regbase + offs);
+}
+
+static inline void iommu_write_reg(struct omap_iommu *obj, u32 val, size_t offs)
+{
+ __raw_writel(val, obj->regbase + offs);
+}
diff --git a/arch/arm/mach-omap2/iommu2.c b/drivers/iommu/omap-iommu2.c
similarity index 99%
rename from arch/arm/mach-omap2/iommu2.c
rename to drivers/iommu/omap-iommu2.c
index 77cbf2f..066e6b2 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/drivers/iommu/omap-iommu2.c
@@ -17,9 +17,11 @@
#include <linux/module.h>
#include <linux/slab.h>
#include <linux/stringify.h>
+#include <linux/io.h>
#include <linux/omap-iommu.h>
#include <plat/iommu.h>
+#include "omap-iommu.h"
/*
* omap2 architecture specific register bit definitions
diff --git a/drivers/iommu/omap-iopgtable.h b/drivers/iommu/omap-iopgtable.h
index 66a8139..cd4ae9e 100644
--- a/drivers/iommu/omap-iopgtable.h
+++ b/drivers/iommu/omap-iopgtable.h
@@ -10,9 +10,6 @@
* published by the Free Software Foundation.
*/
-#ifndef __PLAT_OMAP_IOMMU_H
-#define __PLAT_OMAP_IOMMU_H
-
/*
* "L2 table" address mask and size definitions.
*/
@@ -97,24 +94,5 @@ static inline phys_addr_t omap_iommu_translate(u32 d, u32 va, u32 mask)
#define iopte_index(da) (((da) >> IOPTE_SHIFT) & (PTRS_PER_IOPTE - 1))
#define iopte_offset(iopgd, da) (iopgd_page_vaddr(iopgd) + iopte_index(da))
-static inline u32 iotlb_init_entry(struct iotlb_entry *e, u32 da, u32 pa,
- u32 flags)
-{
- memset(e, 0, sizeof(*e));
-
- e->da = da;
- e->pa = pa;
- e->valid = 1;
- /* FIXME: add OMAP1 support */
- e->pgsz = flags & MMU_CAM_PGSZ_MASK;
- e->endian = flags & MMU_RAM_ENDIAN_MASK;
- e->elsz = flags & MMU_RAM_ELSZ_MASK;
- e->mixed = flags & MMU_RAM_MIXED_MASK;
-
- return iopgsz_to_bytes(e->pgsz);
-}
-
#define to_iommu(dev) \
(struct omap_iommu *)platform_get_drvdata(to_platform_device(dev))
-
-#endif /* __PLAT_OMAP_IOMMU_H */
diff --git a/drivers/iommu/omap-iovmm.c b/drivers/iommu/omap-iovmm.c
index 9852101..3e3b242 100644
--- a/drivers/iommu/omap-iovmm.c
+++ b/drivers/iommu/omap-iovmm.c
@@ -25,6 +25,7 @@
#include <plat/iommu.h>
#include "omap-iopgtable.h"
+#include "omap-iommu.h"
/*
* IOVMF_FLAGS: attribute for iommu virtual memory area(iovma)
^ permalink raw reply related
* [PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
From: Tony Lindgren @ 2012-10-18 20:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018202707.11834.1438.stgit@muffinssi.local>
Looks like the iommu framework does not have generic functions
exported for all the needs yet. The hardware specific functions
are defined in files like intel-iommu.h and amd-iommu.h. Follow
the same standard for omap-iommu.h.
This is needed because we are removing plat and mach includes
for ARM common zImage support. Further work should continue
in the iommu framework context as only pure platform data will
be communicated from arch/arm/*omap*/* code to the iommu
framework.
Cc: Joerg Roedel <joerg.roedel@amd.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Ido Yariv <ido@wizery.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Omar Ramirez Luna <omar.luna@linaro.org>
Cc: linux-media at vger.kernel.org
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/mach-omap2/iommu2.c | 1
arch/arm/plat-omap/include/plat/iommu.h | 10 +--
arch/arm/plat-omap/include/plat/iovmm.h | 89 ----------------------------
drivers/iommu/omap-iommu-debug.c | 2 -
drivers/iommu/omap-iommu.c | 1
drivers/iommu/omap-iovmm.c | 46 ++++++++++++++
drivers/media/platform/omap3isp/isp.c | 1
drivers/media/platform/omap3isp/isp.h | 2 -
drivers/media/platform/omap3isp/ispccdc.c | 1
drivers/media/platform/omap3isp/ispstat.c | 1
drivers/media/platform/omap3isp/ispvideo.c | 2 -
include/linux/omap-iommu.h | 47 +++++++++++++++
12 files changed, 101 insertions(+), 102 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/iovmm.h
create mode 100644 include/linux/omap-iommu.h
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index eefc379..77cbf2f 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -17,6 +17,7 @@
#include <linux/module.h>
#include <linux/slab.h>
#include <linux/stringify.h>
+#include <linux/omap-iommu.h>
#include <plat/iommu.h>
diff --git a/arch/arm/plat-omap/include/plat/iommu.h b/arch/arm/plat-omap/include/plat/iommu.h
index 7e8c7b6..a4b71b1 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -216,13 +216,10 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct device *dev)
#define MMU_RAM_PADDR_SHIFT 12
#define MMU_RAM_PADDR_MASK \
((~0UL >> MMU_RAM_PADDR_SHIFT) << MMU_RAM_PADDR_SHIFT)
-#define MMU_RAM_ENDIAN_SHIFT 9
+
#define MMU_RAM_ENDIAN_MASK (1 << MMU_RAM_ENDIAN_SHIFT)
-#define MMU_RAM_ENDIAN_BIG (1 << MMU_RAM_ENDIAN_SHIFT)
-#define MMU_RAM_ENDIAN_LITTLE (0 << MMU_RAM_ENDIAN_SHIFT)
-#define MMU_RAM_ELSZ_SHIFT 7
#define MMU_RAM_ELSZ_MASK (3 << MMU_RAM_ELSZ_SHIFT)
-#define MMU_RAM_ELSZ_8 (0 << MMU_RAM_ELSZ_SHIFT)
+
#define MMU_RAM_ELSZ_16 (1 << MMU_RAM_ELSZ_SHIFT)
#define MMU_RAM_ELSZ_32 (2 << MMU_RAM_ELSZ_SHIFT)
#define MMU_RAM_ELSZ_NONE (3 << MMU_RAM_ELSZ_SHIFT)
@@ -269,9 +266,6 @@ extern int omap_iommu_set_isr(const char *name,
void *priv),
void *isr_priv);
-extern void omap_iommu_save_ctx(struct device *dev);
-extern void omap_iommu_restore_ctx(struct device *dev);
-
extern int omap_install_iommu_arch(const struct iommu_functions *ops);
extern void omap_uninstall_iommu_arch(const struct iommu_functions *ops);
diff --git a/arch/arm/plat-omap/include/plat/iovmm.h b/arch/arm/plat-omap/include/plat/iovmm.h
deleted file mode 100644
index 498e57c..0000000
--- a/arch/arm/plat-omap/include/plat/iovmm.h
+++ /dev/null
@@ -1,89 +0,0 @@
-/*
- * omap iommu: simple virtual address space management
- *
- * Copyright (C) 2008-2009 Nokia Corporation
- *
- * Written by Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#ifndef __IOMMU_MMAP_H
-#define __IOMMU_MMAP_H
-
-#include <linux/iommu.h>
-
-struct iovm_struct {
- struct omap_iommu *iommu; /* iommu object which this belongs to */
- u32 da_start; /* area definition */
- u32 da_end;
- u32 flags; /* IOVMF_: see below */
- struct list_head list; /* linked in ascending order */
- const struct sg_table *sgt; /* keep 'page' <-> 'da' mapping */
- void *va; /* mpu side mapped address */
-};
-
-/*
- * IOVMF_FLAGS: attribute for iommu virtual memory area(iovma)
- *
- * lower 16 bit is used for h/w and upper 16 bit is for s/w.
- */
-#define IOVMF_SW_SHIFT 16
-
-/*
- * iovma: h/w flags derived from cam and ram attribute
- */
-#define IOVMF_CAM_MASK (~((1 << 10) - 1))
-#define IOVMF_RAM_MASK (~IOVMF_CAM_MASK)
-
-#define IOVMF_PGSZ_MASK (3 << 0)
-#define IOVMF_PGSZ_1M MMU_CAM_PGSZ_1M
-#define IOVMF_PGSZ_64K MMU_CAM_PGSZ_64K
-#define IOVMF_PGSZ_4K MMU_CAM_PGSZ_4K
-#define IOVMF_PGSZ_16M MMU_CAM_PGSZ_16M
-
-#define IOVMF_ENDIAN_MASK (1 << 9)
-#define IOVMF_ENDIAN_BIG MMU_RAM_ENDIAN_BIG
-#define IOVMF_ENDIAN_LITTLE MMU_RAM_ENDIAN_LITTLE
-
-#define IOVMF_ELSZ_MASK (3 << 7)
-#define IOVMF_ELSZ_8 MMU_RAM_ELSZ_8
-#define IOVMF_ELSZ_16 MMU_RAM_ELSZ_16
-#define IOVMF_ELSZ_32 MMU_RAM_ELSZ_32
-#define IOVMF_ELSZ_NONE MMU_RAM_ELSZ_NONE
-
-#define IOVMF_MIXED_MASK (1 << 6)
-#define IOVMF_MIXED MMU_RAM_MIXED
-
-/*
- * iovma: s/w flags, used for mapping and umapping internally.
- */
-#define IOVMF_MMIO (1 << IOVMF_SW_SHIFT)
-#define IOVMF_ALLOC (2 << IOVMF_SW_SHIFT)
-#define IOVMF_ALLOC_MASK (3 << IOVMF_SW_SHIFT)
-
-/* "superpages" is supported just with physically linear pages */
-#define IOVMF_DISCONT (1 << (2 + IOVMF_SW_SHIFT))
-#define IOVMF_LINEAR (2 << (2 + IOVMF_SW_SHIFT))
-#define IOVMF_LINEAR_MASK (3 << (2 + IOVMF_SW_SHIFT))
-
-#define IOVMF_DA_FIXED (1 << (4 + IOVMF_SW_SHIFT))
-
-
-extern struct iovm_struct *omap_find_iovm_area(struct device *dev, u32 da);
-extern u32
-omap_iommu_vmap(struct iommu_domain *domain, struct device *dev, u32 da,
- const struct sg_table *sgt, u32 flags);
-extern struct sg_table *omap_iommu_vunmap(struct iommu_domain *domain,
- struct device *dev, u32 da);
-extern u32
-omap_iommu_vmalloc(struct iommu_domain *domain, struct device *dev,
- u32 da, size_t bytes, u32 flags);
-extern void
-omap_iommu_vfree(struct iommu_domain *domain, struct device *dev,
- const u32 da);
-extern void *omap_da_to_va(struct device *dev, u32 da);
-
-#endif /* __IOMMU_MMAP_H */
diff --git a/drivers/iommu/omap-iommu-debug.c b/drivers/iommu/omap-iommu-debug.c
index 0cac372..cf4a0b5 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -18,9 +18,9 @@
#include <linux/uaccess.h>
#include <linux/platform_device.h>
#include <linux/debugfs.h>
+#include <linux/omap-iommu.h>
#include <plat/iommu.h>
-#include <plat/iovmm.h>
#include "omap-iopgtable.h"
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index f2bbfb0..eadcfde 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -19,6 +19,7 @@
#include <linux/clk.h>
#include <linux/platform_device.h>
#include <linux/iommu.h>
+#include <linux/omap-iommu.h>
#include <linux/mutex.h>
#include <linux/spinlock.h>
diff --git a/drivers/iommu/omap-iovmm.c b/drivers/iommu/omap-iovmm.c
index b332392..9852101 100644
--- a/drivers/iommu/omap-iovmm.c
+++ b/drivers/iommu/omap-iovmm.c
@@ -17,15 +17,59 @@
#include <linux/device.h>
#include <linux/scatterlist.h>
#include <linux/iommu.h>
+#include <linux/omap-iommu.h>
#include <asm/cacheflush.h>
#include <asm/mach/map.h>
#include <plat/iommu.h>
-#include <plat/iovmm.h>
#include "omap-iopgtable.h"
+/*
+ * IOVMF_FLAGS: attribute for iommu virtual memory area(iovma)
+ *
+ * lower 16 bit is used for h/w and upper 16 bit is for s/w.
+ */
+#define IOVMF_SW_SHIFT 16
+
+/*
+ * iovma: h/w flags derived from cam and ram attribute
+ */
+#define IOVMF_CAM_MASK (~((1 << 10) - 1))
+#define IOVMF_RAM_MASK (~IOVMF_CAM_MASK)
+
+#define IOVMF_PGSZ_MASK (3 << 0)
+#define IOVMF_PGSZ_1M MMU_CAM_PGSZ_1M
+#define IOVMF_PGSZ_64K MMU_CAM_PGSZ_64K
+#define IOVMF_PGSZ_4K MMU_CAM_PGSZ_4K
+#define IOVMF_PGSZ_16M MMU_CAM_PGSZ_16M
+
+#define IOVMF_ENDIAN_MASK (1 << 9)
+#define IOVMF_ENDIAN_BIG MMU_RAM_ENDIAN_BIG
+
+#define IOVMF_ELSZ_MASK (3 << 7)
+#define IOVMF_ELSZ_16 MMU_RAM_ELSZ_16
+#define IOVMF_ELSZ_32 MMU_RAM_ELSZ_32
+#define IOVMF_ELSZ_NONE MMU_RAM_ELSZ_NONE
+
+#define IOVMF_MIXED_MASK (1 << 6)
+#define IOVMF_MIXED MMU_RAM_MIXED
+
+/*
+ * iovma: s/w flags, used for mapping and umapping internally.
+ */
+#define IOVMF_MMIO (1 << IOVMF_SW_SHIFT)
+#define IOVMF_ALLOC (2 << IOVMF_SW_SHIFT)
+#define IOVMF_ALLOC_MASK (3 << IOVMF_SW_SHIFT)
+
+/* "superpages" is supported just with physically linear pages */
+#define IOVMF_DISCONT (1 << (2 + IOVMF_SW_SHIFT))
+#define IOVMF_LINEAR (2 << (2 + IOVMF_SW_SHIFT))
+#define IOVMF_LINEAR_MASK (3 << (2 + IOVMF_SW_SHIFT))
+
+#define IOVMF_DA_FIXED (1 << (4 + IOVMF_SW_SHIFT))
+
static struct kmem_cache *iovm_area_cachep;
/* return the offset of the first scatterlist entry in a sg table */
diff --git a/drivers/media/platform/omap3isp/isp.c b/drivers/media/platform/omap3isp/isp.c
index 99640d8..d72bd38 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -66,6 +66,7 @@
#include <linux/slab.h>
#include <linux/sched.h>
#include <linux/vmalloc.h>
+#include <linux/omap-iommu.h>
#include <media/v4l2-common.h>
#include <media/v4l2-device.h>
diff --git a/drivers/media/platform/omap3isp/isp.h b/drivers/media/platform/omap3isp/isp.h
index 8be7487..50be8c2 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -34,8 +34,6 @@
#include <linux/platform_device.h>
#include <linux/wait.h>
#include <linux/iommu.h>
-#include <plat/iommu.h>
-#include <plat/iovmm.h>
#include "ispstat.h"
#include "ispccdc.h"
diff --git a/drivers/media/platform/omap3isp/ispccdc.c b/drivers/media/platform/omap3isp/ispccdc.c
index 60181ab..b2d4976 100644
--- a/drivers/media/platform/omap3isp/ispccdc.c
+++ b/drivers/media/platform/omap3isp/ispccdc.c
@@ -32,6 +32,7 @@
#include <linux/mm.h>
#include <linux/sched.h>
#include <linux/slab.h>
+#include <linux/omap-iommu.h>
#include <media/v4l2-event.h>
#include "isp.h"
diff --git a/drivers/media/platform/omap3isp/ispstat.c b/drivers/media/platform/omap3isp/ispstat.c
index d7ac76b..e135774 100644
--- a/drivers/media/platform/omap3isp/ispstat.c
+++ b/drivers/media/platform/omap3isp/ispstat.c
@@ -28,6 +28,7 @@
#include <linux/dma-mapping.h>
#include <linux/slab.h>
#include <linux/uaccess.h>
+#include <linux/omap-iommu.h>
#include "isp.h"
diff --git a/drivers/media/platform/omap3isp/ispvideo.c b/drivers/media/platform/omap3isp/ispvideo.c
index a0b737fe..2853bef 100644
--- a/drivers/media/platform/omap3isp/ispvideo.c
+++ b/drivers/media/platform/omap3isp/ispvideo.c
@@ -32,10 +32,10 @@
#include <linux/sched.h>
#include <linux/slab.h>
#include <linux/vmalloc.h>
+#include <linux/omap-iommu.h>
#include <media/v4l2-dev.h>
#include <media/v4l2-ioctl.h>
#include <plat/iommu.h>
-#include <plat/iovmm.h>
#include <plat/omap-pm.h>
#include "ispvideo.h"
diff --git a/include/linux/omap-iommu.h b/include/linux/omap-iommu.h
new file mode 100644
index 0000000..bd12665
--- /dev/null
+++ b/include/linux/omap-iommu.h
@@ -0,0 +1,47 @@
+/*
+ * omap iommu: simple virtual address space management
+ *
+ * Copyright (C) 2008-2009 Nokia Corporation
+ *
+ * Written by Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+struct iovm_struct {
+ struct omap_iommu *iommu; /* iommu object which this belongs to */
+ u32 da_start; /* area definition */
+ u32 da_end;
+ u32 flags; /* IOVMF_: see below */
+ struct list_head list; /* linked in ascending order */
+ const struct sg_table *sgt; /* keep 'page' <-> 'da' mapping */
+ void *va; /* mpu side mapped address */
+};
+
+#define MMU_RAM_ENDIAN_SHIFT 9
+#define MMU_RAM_ENDIAN_LITTLE (0 << MMU_RAM_ENDIAN_SHIFT)
+#define MMU_RAM_ELSZ_8 (0 << MMU_RAM_ELSZ_SHIFT)
+#define IOVMF_ENDIAN_LITTLE MMU_RAM_ENDIAN_LITTLE
+#define MMU_RAM_ELSZ_SHIFT 7
+#define IOVMF_ELSZ_8 MMU_RAM_ELSZ_8
+
+struct iommu_domain;
+
+extern struct iovm_struct *omap_find_iovm_area(struct device *dev, u32 da);
+extern u32
+omap_iommu_vmap(struct iommu_domain *domain, struct device *dev, u32 da,
+ const struct sg_table *sgt, u32 flags);
+extern struct sg_table *omap_iommu_vunmap(struct iommu_domain *domain,
+ struct device *dev, u32 da);
+extern u32
+omap_iommu_vmalloc(struct iommu_domain *domain, struct device *dev,
+ u32 da, size_t bytes, u32 flags);
+extern void
+omap_iommu_vfree(struct iommu_domain *domain, struct device *dev,
+ const u32 da);
+extern void *omap_da_to_va(struct device *dev, u32 da);
+
+extern void omap_iommu_save_ctx(struct device *dev);
+extern void omap_iommu_restore_ctx(struct device *dev);
^ permalink raw reply related
* [PATCH 2/6] ARM: OMAP2+: Move iopgtable header to drivers/iommu/
From: Tony Lindgren @ 2012-10-18 20:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018202707.11834.1438.stgit@muffinssi.local>
From: Ido Yariv <ido@wizery.com>
The iopgtable header file is only used by the iommu & iovmm drivers, so
move it to drivers/iommu/, as part of the single zImage effort.
Cc: Joerg Roedel <joerg.roedel@amd.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Omar Ramirez Luna <omar.luna@linaro.org>
Signed-off-by: Ido Yariv <ido@wizery.com>
[tony at atomide.com: updated to be earlier in the series]
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
drivers/iommu/omap-iommu-debug.c | 2 +-
drivers/iommu/omap-iommu.c | 2 +-
drivers/iommu/omap-iopgtable.h | 0
drivers/iommu/omap-iovmm.c | 2 +-
4 files changed, 3 insertions(+), 3 deletions(-)
rename arch/arm/plat-omap/include/plat/iopgtable.h => drivers/iommu/omap-iopgtable.h (100%)
diff --git a/drivers/iommu/omap-iommu-debug.c b/drivers/iommu/omap-iommu-debug.c
index f55fc5d..0cac372 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -22,7 +22,7 @@
#include <plat/iommu.h>
#include <plat/iovmm.h>
-#include <plat/iopgtable.h>
+#include "omap-iopgtable.h"
#define MAXCOLUMN 100 /* for short messages */
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index d0b1234..f2bbfb0 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -26,7 +26,7 @@
#include <plat/iommu.h>
-#include <plat/iopgtable.h>
+#include "omap-iopgtable.h"
#define for_each_iotlb_cr(obj, n, __i, cr) \
for (__i = 0; \
diff --git a/arch/arm/plat-omap/include/plat/iopgtable.h b/drivers/iommu/omap-iopgtable.h
similarity index 100%
rename from arch/arm/plat-omap/include/plat/iopgtable.h
rename to drivers/iommu/omap-iopgtable.h
diff --git a/drivers/iommu/omap-iovmm.c b/drivers/iommu/omap-iovmm.c
index 2e10c3e..b332392 100644
--- a/drivers/iommu/omap-iovmm.c
+++ b/drivers/iommu/omap-iovmm.c
@@ -24,7 +24,7 @@
#include <plat/iommu.h>
#include <plat/iovmm.h>
-#include <plat/iopgtable.h>
+#include "omap-iopgtable.h"
static struct kmem_cache *iovm_area_cachep;
^ permalink raw reply related
* [PATCH 1/6] ARM: OMAP: Merge iommu2.h into iommu.h
From: Tony Lindgren @ 2012-10-18 20:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018202707.11834.1438.stgit@muffinssi.local>
From: Ido Yariv <ido@wizery.com>
Since iommu is not supported on OMAP1 and will not likely to ever be
supported, merge plat/iommu2.h into iommu.h so only one file would have
to move to platform_data/ as part of the single zImage effort.
Cc: Joerg Roedel <joerg.roedel@amd.com>
Cc: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Omar Ramirez Luna <omar.luna@linaro.org>
Signed-off-by: Ido Yariv <ido@wizery.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/plat-omap/include/plat/iommu.h | 88 ++++++++++++++++++++++++++--
arch/arm/plat-omap/include/plat/iommu2.h | 96 ------------------------------
2 files changed, 83 insertions(+), 101 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/iommu2.h
diff --git a/arch/arm/plat-omap/include/plat/iommu.h b/arch/arm/plat-omap/include/plat/iommu.h
index 68b5f03..7e8c7b6 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -13,6 +13,12 @@
#ifndef __MACH_IOMMU_H
#define __MACH_IOMMU_H
+#include <linux/io.h>
+
+#if defined(CONFIG_ARCH_OMAP1)
+#error "iommu for this processor not implemented yet"
+#endif
+
struct iotlb_entry {
u32 da;
u32 pa;
@@ -159,11 +165,70 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct device *dev)
#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
-#include <plat/iommu2.h>
-#endif
+/*
+ * MMU Register offsets
+ */
+#define MMU_REVISION 0x00
+#define MMU_SYSCONFIG 0x10
+#define MMU_SYSSTATUS 0x14
+#define MMU_IRQSTATUS 0x18
+#define MMU_IRQENABLE 0x1c
+#define MMU_WALKING_ST 0x40
+#define MMU_CNTL 0x44
+#define MMU_FAULT_AD 0x48
+#define MMU_TTB 0x4c
+#define MMU_LOCK 0x50
+#define MMU_LD_TLB 0x54
+#define MMU_CAM 0x58
+#define MMU_RAM 0x5c
+#define MMU_GFLUSH 0x60
+#define MMU_FLUSH_ENTRY 0x64
+#define MMU_READ_CAM 0x68
+#define MMU_READ_RAM 0x6c
+#define MMU_EMU_FAULT_AD 0x70
+
+#define MMU_REG_SIZE 256
+
+/*
+ * MMU Register bit definitions
+ */
+#define MMU_LOCK_BASE_SHIFT 10
+#define MMU_LOCK_BASE_MASK (0x1f << MMU_LOCK_BASE_SHIFT)
+#define MMU_LOCK_BASE(x) \
+ ((x & MMU_LOCK_BASE_MASK) >> MMU_LOCK_BASE_SHIFT)
+
+#define MMU_LOCK_VICT_SHIFT 4
+#define MMU_LOCK_VICT_MASK (0x1f << MMU_LOCK_VICT_SHIFT)
+#define MMU_LOCK_VICT(x) \
+ ((x & MMU_LOCK_VICT_MASK) >> MMU_LOCK_VICT_SHIFT)
+
+#define MMU_CAM_VATAG_SHIFT 12
+#define MMU_CAM_VATAG_MASK \
+ ((~0UL >> MMU_CAM_VATAG_SHIFT) << MMU_CAM_VATAG_SHIFT)
+#define MMU_CAM_P (1 << 3)
+#define MMU_CAM_V (1 << 2)
+#define MMU_CAM_PGSZ_MASK 3
+#define MMU_CAM_PGSZ_1M (0 << 0)
+#define MMU_CAM_PGSZ_64K (1 << 0)
+#define MMU_CAM_PGSZ_4K (2 << 0)
+#define MMU_CAM_PGSZ_16M (3 << 0)
+
+#define MMU_RAM_PADDR_SHIFT 12
+#define MMU_RAM_PADDR_MASK \
+ ((~0UL >> MMU_RAM_PADDR_SHIFT) << MMU_RAM_PADDR_SHIFT)
+#define MMU_RAM_ENDIAN_SHIFT 9
+#define MMU_RAM_ENDIAN_MASK (1 << MMU_RAM_ENDIAN_SHIFT)
+#define MMU_RAM_ENDIAN_BIG (1 << MMU_RAM_ENDIAN_SHIFT)
+#define MMU_RAM_ENDIAN_LITTLE (0 << MMU_RAM_ENDIAN_SHIFT)
+#define MMU_RAM_ELSZ_SHIFT 7
+#define MMU_RAM_ELSZ_MASK (3 << MMU_RAM_ELSZ_SHIFT)
+#define MMU_RAM_ELSZ_8 (0 << MMU_RAM_ELSZ_SHIFT)
+#define MMU_RAM_ELSZ_16 (1 << MMU_RAM_ELSZ_SHIFT)
+#define MMU_RAM_ELSZ_32 (2 << MMU_RAM_ELSZ_SHIFT)
+#define MMU_RAM_ELSZ_NONE (3 << MMU_RAM_ELSZ_SHIFT)
+#define MMU_RAM_MIXED_SHIFT 6
+#define MMU_RAM_MIXED_MASK (1 << MMU_RAM_MIXED_SHIFT)
+#define MMU_RAM_MIXED MMU_RAM_MIXED_MASK
/*
* utilities for super page(16MB, 1MB, 64KB and 4KB)
@@ -218,4 +283,17 @@ omap_iommu_dump_ctx(struct omap_iommu *obj, char *buf, ssize_t len);
extern size_t
omap_dump_tlb_entries(struct omap_iommu *obj, char *buf, ssize_t len);
+/*
+ * register accessors
+ */
+static inline u32 iommu_read_reg(struct omap_iommu *obj, size_t offs)
+{
+ return __raw_readl(obj->regbase + offs);
+}
+
+static inline void iommu_write_reg(struct omap_iommu *obj, u32 val, size_t offs)
+{
+ __raw_writel(val, obj->regbase + offs);
+}
+
#endif /* __MACH_IOMMU_H */
diff --git a/arch/arm/plat-omap/include/plat/iommu2.h b/arch/arm/plat-omap/include/plat/iommu2.h
deleted file mode 100644
index d4116b5..0000000
--- a/arch/arm/plat-omap/include/plat/iommu2.h
+++ /dev/null
@@ -1,96 +0,0 @@
-/*
- * omap iommu: omap2 architecture specific definitions
- *
- * Copyright (C) 2008-2009 Nokia Corporation
- *
- * Written by Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#ifndef __MACH_IOMMU2_H
-#define __MACH_IOMMU2_H
-
-#include <linux/io.h>
-
-/*
- * MMU Register offsets
- */
-#define MMU_REVISION 0x00
-#define MMU_SYSCONFIG 0x10
-#define MMU_SYSSTATUS 0x14
-#define MMU_IRQSTATUS 0x18
-#define MMU_IRQENABLE 0x1c
-#define MMU_WALKING_ST 0x40
-#define MMU_CNTL 0x44
-#define MMU_FAULT_AD 0x48
-#define MMU_TTB 0x4c
-#define MMU_LOCK 0x50
-#define MMU_LD_TLB 0x54
-#define MMU_CAM 0x58
-#define MMU_RAM 0x5c
-#define MMU_GFLUSH 0x60
-#define MMU_FLUSH_ENTRY 0x64
-#define MMU_READ_CAM 0x68
-#define MMU_READ_RAM 0x6c
-#define MMU_EMU_FAULT_AD 0x70
-
-#define MMU_REG_SIZE 256
-
-/*
- * MMU Register bit definitions
- */
-#define MMU_LOCK_BASE_SHIFT 10
-#define MMU_LOCK_BASE_MASK (0x1f << MMU_LOCK_BASE_SHIFT)
-#define MMU_LOCK_BASE(x) \
- ((x & MMU_LOCK_BASE_MASK) >> MMU_LOCK_BASE_SHIFT)
-
-#define MMU_LOCK_VICT_SHIFT 4
-#define MMU_LOCK_VICT_MASK (0x1f << MMU_LOCK_VICT_SHIFT)
-#define MMU_LOCK_VICT(x) \
- ((x & MMU_LOCK_VICT_MASK) >> MMU_LOCK_VICT_SHIFT)
-
-#define MMU_CAM_VATAG_SHIFT 12
-#define MMU_CAM_VATAG_MASK \
- ((~0UL >> MMU_CAM_VATAG_SHIFT) << MMU_CAM_VATAG_SHIFT)
-#define MMU_CAM_P (1 << 3)
-#define MMU_CAM_V (1 << 2)
-#define MMU_CAM_PGSZ_MASK 3
-#define MMU_CAM_PGSZ_1M (0 << 0)
-#define MMU_CAM_PGSZ_64K (1 << 0)
-#define MMU_CAM_PGSZ_4K (2 << 0)
-#define MMU_CAM_PGSZ_16M (3 << 0)
-
-#define MMU_RAM_PADDR_SHIFT 12
-#define MMU_RAM_PADDR_MASK \
- ((~0UL >> MMU_RAM_PADDR_SHIFT) << MMU_RAM_PADDR_SHIFT)
-#define MMU_RAM_ENDIAN_SHIFT 9
-#define MMU_RAM_ENDIAN_MASK (1 << MMU_RAM_ENDIAN_SHIFT)
-#define MMU_RAM_ENDIAN_BIG (1 << MMU_RAM_ENDIAN_SHIFT)
-#define MMU_RAM_ENDIAN_LITTLE (0 << MMU_RAM_ENDIAN_SHIFT)
-#define MMU_RAM_ELSZ_SHIFT 7
-#define MMU_RAM_ELSZ_MASK (3 << MMU_RAM_ELSZ_SHIFT)
-#define MMU_RAM_ELSZ_8 (0 << MMU_RAM_ELSZ_SHIFT)
-#define MMU_RAM_ELSZ_16 (1 << MMU_RAM_ELSZ_SHIFT)
-#define MMU_RAM_ELSZ_32 (2 << MMU_RAM_ELSZ_SHIFT)
-#define MMU_RAM_ELSZ_NONE (3 << MMU_RAM_ELSZ_SHIFT)
-#define MMU_RAM_MIXED_SHIFT 6
-#define MMU_RAM_MIXED_MASK (1 << MMU_RAM_MIXED_SHIFT)
-#define MMU_RAM_MIXED MMU_RAM_MIXED_MASK
-
-/*
- * register accessors
- */
-static inline u32 iommu_read_reg(struct omap_iommu *obj, size_t offs)
-{
- return __raw_readl(obj->regbase + offs);
-}
-
-static inline void iommu_write_reg(struct omap_iommu *obj, u32 val, size_t offs)
-{
- __raw_writel(val, obj->regbase + offs);
-}
-
-#endif /* __MACH_IOMMU2_H */
^ permalink raw reply related
* [PATCH v3 0/6] omap iommu changes to remove plat includes
From: Tony Lindgren @ 2012-10-18 20:28 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Here's this one again fixed with the issues Laurent noticed.
Regards,
Tony
---
Ido Yariv (3):
ARM: OMAP: Merge iommu2.h into iommu.h
ARM: OMAP2+: Move iopgtable header to drivers/iommu/
ARM: OMAP2+: Make some definitions local
Tony Lindgren (3):
ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
ARM: OMAP2+: Move iommu2 to drivers/iommu/omap-iommu2.c
ARM: OMAP2+: Move iommu/iovmm headers to platform_data
arch/arm/mach-omap2/Makefile | 2
arch/arm/mach-omap2/devices.c | 2
arch/arm/mach-omap2/omap-iommu.c | 2
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 2
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2
arch/arm/plat-omap/include/plat/iommu2.h | 96 -------------------
arch/arm/plat-omap/include/plat/iovmm.h | 89 ------------------
drivers/iommu/Makefile | 1
drivers/iommu/omap-iommu-debug.c | 8 +-
drivers/iommu/omap-iommu.c | 39 ++++++++
drivers/iommu/omap-iommu.h | 133 ++++++++++++++-------------
drivers/iommu/omap-iommu2.c | 11 ++
drivers/iommu/omap-iopgtable.h | 22 ----
drivers/iommu/omap-iovmm.c | 50 ++++++++++
drivers/media/platform/omap3isp/isp.c | 1
drivers/media/platform/omap3isp/isp.h | 2
drivers/media/platform/omap3isp/ispccdc.c | 1
drivers/media/platform/omap3isp/ispstat.c | 1
drivers/media/platform/omap3isp/ispvideo.c | 3 -
include/linux/omap-iommu.h | 47 ++++++++++
include/linux/platform_data/iommu-omap.h | 49 ++++++++++
21 files changed, 273 insertions(+), 290 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/iommu2.h
delete mode 100644 arch/arm/plat-omap/include/plat/iovmm.h
rename arch/arm/plat-omap/include/plat/iommu.h => drivers/iommu/omap-iommu.h (69%)
rename arch/arm/mach-omap2/iommu2.c => drivers/iommu/omap-iommu2.c (96%)
rename arch/arm/plat-omap/include/plat/iopgtable.h => drivers/iommu/omap-iopgtable.h (85%)
create mode 100644 include/linux/omap-iommu.h
create mode 100644 include/linux/platform_data/iommu-omap.h
--
Signature
^ permalink raw reply
* [PATCH] ARM: tegra: cpuidle: replace LP3 with ARM_CPUIDLE_WFI_STATE
From: Stephen Warren @ 2012-10-18 20:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349691856-30590-1-git-send-email-josephl@nvidia.com>
On 10/08/2012 04:24 AM, Joseph Lo wrote:
> The Tegra CPU idle LP3 state is doing ARM WFI only. So it's same with
> the common ARM_CPUIDLE_WFI_STATE. Using it to replace LP3 now.
Applied to Tegra's for-3.8/cpuidle branch (I created that branch in
anticipation of there being a bunch of other cpuidle work for 3.8).
^ permalink raw reply
* Доска бесплатных объявлений с Каталогом Организаций
From: trueboard.ru @ 2012-10-18 19:42 UTC (permalink / raw)
To: linux-arm-kernel
?????????? ???? ?????????? ????????? ?? ????? ????? ?????????? ? ? ???????? ??????????? trueboard.ru, ??? ??????? ??? ????? ??? ????? ??????????? ????????????? ???????????????? ???? ?????? ??? ?????? ? ???? ?????????????? ???????? ? ????? ????? ?????????? ? ????????? ?????????? ? ??? ?? ???????? ??????????? .
????? ???? ???? ? ??? ???? ????, ?????????? ?? ??? ??? ???????? (?? ?????? "??????") ? ?? ???????? VIP ?????????? ?????????!
www.trueboard.ru
^ permalink raw reply
* [RFC/NOT FOR MERGING 1/5] arm: omap: fix up _od_suspend_noirq and _od_resume_noirq
From: Felipe Balbi @ 2012-10-18 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87vce77hba.fsf@deeprootsystems.com>
Hi,
On Thu, Oct 18, 2012 at 11:42:33AM -0700, Kevin Hilman wrote:
> >> Again, this is required because system suspend disables runtime PM
> >> transitions at a certain point, if the device is used after that point,
> >> there is *no other way* for the driver to properly manage the idle
> >> transition (or, if there is, please explain it to me.)
> >
> > Can you please let me know of any situation where e.g. I2C/SPI would be
> > needed after all its children are suspended ?
>
> There lots of I2C users who are not children of the I2C bus device. Any
> users of regulators on the I2C-connected PMIC for example (MMC comes to
> mind, and is not a child of the I2C bus.). Also, enable/disable of GPIO
> IRQ lines on I2C GPIO expanders. The devices using those GPIO IRQs are
> not children of the I2C bus.
MMC isn't a child of I2C, indeed, but the regulator is a child of TWL
which is a child of the I2C bus.
> Stated differently, I2C devices themselves (PMIC, GPIO expanders, etc.)
> are children of the I2C bus device. But *users* of those devices will
> be other drivers who have no parent/child relationship with the I2C bus
> device in the driver model.
correct, but MMC is not suspended as late as suspend_noirq() is it ?
Looks like only I2C can fall into this category because of exactly
regulators and I/O expanders. So wouldn't implementing
omap_i2c_suspend_noirq() and omap_i2c_resume_noirq() solve the same
problem ?
> >> > so you shouldn't forcefully resume the device.
> >>
> >> Note it's only forcefully resumed *if* it was forcefully suspended by
> >> suspend_noirq.
> >
> > likewise, you shouldn't forcefully runtime suspend a device. The device
> > driver needs to be required to provide suspend/resume functions if it
> > cares.
>
> I don't think you've fully understood the problem being solved here.
>
> This is for devices who designed for use throughout the suspend process
> (IOW, *after* their suspend callbacks have been called.)
is there no way for a device to tell PM core that it doesn't want to be
suspended during ->suspend_early or ->suspend but only on
->suspend_noirq ? Isn't the fact that we don't implement ->suspend_early
and ->suspend enough to keep the device running ? I think that will be
the case with the patch which adds the extra check on
_od_suspend_noirq(), no ?
And before you reply, if the device implements none of the suspend
methods, then you shouldn't suspend it at all, because you'd be masking
a bug in the driver, IMHO.
> >> But even then, with your proposed changes, I don't think the device will
> >> be properly idled (including the omap_device_idle) in these important cases:
> >>
> >> 1) I2C is used by some other device *after* its ->suspend method has
> >> been called.
> >
> > how can that happen ? I2C's ->suspend method will only be called after
> > all its children are suspended.
>
> Unfortunately, drivers which use I2C are not all children of the I2C bus
> device in the driver model (see above.)
>
> This gets to a much bigger problem with the linux driver model today.
> There are *many* power relationships/dependencies between devices that
> are not modeled by driver model device hierarchy.
Ok. Now I see a good point :-) You're correct, thanks
> >> It doesn't matter if the driver has noirq methods. If it is not yet
> >> runtime suspended, it is forceably runtime suspended. The generic
> >
> > if it's not yet runtime suspended, you need to call the driver's
> > ->suspend_* method (depending on the suspend phase you are right now),
>
> You're confusing system suspend and runtime suspend, and forgetting that
> we might want to use runtime PM *during* system suspend/resume.
Maybe I wasn't clear enough. What I meant to say was that if the device
isn't runtime_suspended by the time you should be calling its
->suspend_noirq method, then calling the device's runtime_suspend()
method looks very weird to me.
It really seems, to me, that implementing suspend_noirq() on e.g. I2C
controller driver should do the trick provided you call
->suspend_noirq() instead of ->runtime_suspend(). I mean, if we do exact
the same thing on runtime_suspend() and suspend_noirq() (namely disable
IRQs, save context, etc), then it should make no difference which method
you call, right ?
> Again, the reason a device may not yet runtime suspended is because it
> was in use during suspend, and runtime PM has been disabled by the PM
> core during system PM. If the PM core did not disable runtime PM, the
> drivers runtime PM methods would be called, and we would not need to
> implement this in the PM domain layer.
fair enough, but what I still don't get is why you need to call exactly
->runtime_suspend. What's the problem with calling ->suspend_noirq() ?
Again, look at the last patch. Note that I do the same thing on both
->suspend (should be ->suspend_noirq()) and ->runtime_suspend(), with a
slight difference:
on ->suspend(_noirq) if the device is already runtime_suspended, I just
return 0, otherwise I follow the same procedure and (due to the other
patches) omap_device_idle() will be called the same way. The device will
be suspended, but (let's assume) PM runtime doesn't know about it. No
problem, during resume you will call omap_device_resume() and later call
pm_generic_resume(_noirq) which will call omap_i2c_resume(_noirq) which
will:
reenable_irqs();
restore_context();
pm_runtime_disable(dev);
pm_runtime_set_active(dev); /* we have already resumed the device */
pm_runtime_enable(dev);
return 0;
> >> noirq calls are just there in case the driver has noirq callbacks.
> >
> > I get that, but why would you suspend a device which doesn't want to be
> > suspended in suspend_noirq(), but using its runtime_suspend method ?
>
> What do you mean "doesn't want to be suspended"? If a device doesn't
by "doesn't want to be suspended" I mean that it hasn't implemented a
noirq method.
> want to be suspended, it needs to return an error from one of its
> suspend methods. Barring that, the system *will* suspend, and in order
> to hit low power states, we have to properly idle each device.
>
> The underlying assumption is that by the time the noirq phase runs, the
> device should already be runtime suspended. If it is not, then one of
> the following ha happened:
>
> - device was used during suspend, but after runtime PM was disabled by
> the PM core (during system suspend)
>
> - runtime PM disabled from userspace
>
> In both cases, *somebody* has to properly idle the device and "finish"
yes, and that somebody is omap_device_idle() right ? Now my question
remains: why is it so important to call device's ->runtime_suspend
method. Why couldn't you call device's ->suspend_noirq method instead ?
> the runtime suspend late in the suspend phase. As recommended by
> Rafael, we handle this at the PM domain level.
>
> > If I2C dies on a suspend/resume transition, it's a bug in the I2C
> > driver, no ?
>
> Sure, but this has nothing to do with I2C dying.
Imagine that instead of calling ->runtime_suspend we were to call
->suspend_noirq, but the device doesn't implement that. What would
happen ? no context save, no context restore, I2C dead.
ps: I'll continue reading the code and further test my series to see
if I can understand what you say here.
cheers
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121018/7af66528/attachment.sig>
^ permalink raw reply
* [PATCH] [media] s5p-tv: don't include linux/version.h in mixer_video.c
From: Jesper Juhl @ 2012-10-18 19:28 UTC (permalink / raw)
To: linux-arm-kernel
The header is not needed, so remove it.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
drivers/media/platform/s5p-tv/mixer_video.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/media/platform/s5p-tv/mixer_video.c b/drivers/media/platform/s5p-tv/mixer_video.c
index 0c1cd89..9b52f3a 100644
--- a/drivers/media/platform/s5p-tv/mixer_video.c
+++ b/drivers/media/platform/s5p-tv/mixer_video.c
@@ -19,7 +19,6 @@
#include <linux/videodev2.h>
#include <linux/mm.h>
#include <linux/module.h>
-#include <linux/version.h>
#include <linux/timer.h>
#include <media/videobuf2-dma-contig.h>
--
1.7.1
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
From: Paul Walmsley @ 2012-10-18 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018184443.GD2350@netboy.at.omicron.at>
On Thu, 18 Oct 2012, Richard Cochran wrote:
> You say it will be working in 3.8, after 3.7 comes out, in about
> December.
I wrote that we'll schedule the SoC integration patch for sending upstream
for 3.8. This does not necessarily mean that our upstreams will take it,
or that it will result in a working CPSW.
> Sorry to harp on this so much, but I try out my patches with the tip of
> the appropriate tree before sending them, or when I cannot, at least I
> put into the log "compile tested only" or something like that.
Great!
- Paul
^ permalink raw reply
* [PATCH 1/5] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
From: Jon Hunter @ 2012-10-18 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB43DBA@DBDE01.ent.ti.com>
On 10/18/2012 01:39 PM, Hiremath, Vaibhav wrote:
> On Fri, Oct 19, 2012 at 00:00:31, Hunter, Jon wrote:
>>
>> On 10/18/2012 01:04 PM, Hiremath, Vaibhav wrote:
>>> On Thu, Oct 18, 2012 at 22:12:07, Hunter, Jon wrote:
>>
>> ...
>>
>>>> Yes, but do you also see the bug that is hiding in gpmc_mem_init()?
>>>>
>>>> My point is to highlight this and not hide it, so that we can fix it
>>>> now. Otherwise if we wait until we enable the gpmc driver with DT and
>>>> this could hinder the DT migration later.
>>>>
>>>
>>> As I already mentioned in my previous response, your patch is required
>>> irrespective of this patch. I would consider your patch as a cleanup patch.
>>>
>>>
>>> Both the patches are independent, your patch is handling the error path
>>> properly, whereas, my patch makes sure that you don't unnecessarily probe
>>> GPMC if you are booting from DT and GPMC node is not present, as described
>>> above.
>>
>> Your patch hides a bug. That's my point. How do you expect am335x ever
>> to support gpmc devices if this bug is not addressed?
>>
>
> Jon,
> May be my commit description was mis-leading to you.
> I am not commenting anything on your bug-fix, but do not agree that it is
> anything to do with hiding a bug.
So we can agree is disagree on that ;-)
> I only agree with you on one point, if someone wants to change the board-
> file to use GPMC with DT boot mode, then he will not be able to use it.
>
>> So I think that you are over-simplifying it when you say that my patch
>> is just a clean-up patch. I agree that it is adding appropriate error
>> handling, but it also highlights the presence of a bug by allowing the
>> probe to fail.
>>
>> Anyway, I don't care to debate this any further,
>
> Me neither...
>
>> we just need to fix
>> gpmc_mem_init().
>>
>
> Agreed, and that's what your patch rightly doing it.
No. My patch does not fix the _actual_ bug, it is still there. Why do
you think that the probe is still failing for am335x? Without fixing it
am335x will never be able to support gpmc. So gpmc_mem_init() still
needs to be fixed.
Jon
^ permalink raw reply
* Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
From: Richard Cochran @ 2012-10-18 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210180313360.6893@utopia.booyaka.com>
On Thu, Oct 18, 2012 at 03:46:15AM +0000, Paul Walmsley wrote:
>
> Probably the driver was submitted before any SoC integration support was
> available. Grepping for 'cpsw' under arch/ turns up only AM33xx. AM335x
> didn't have device enumeration support in the mainline kernel until 3.7,
> via commit a2cfc509bc4eeef9f5c4607b1203f17f22ea2a36 ("ARM: OMAP3+: hwmod:
> Add AM33XX HWMOD data"). So I don't see how it could have worked with
> mainline.
...
> But it seems that the CPSW has never worked in the mainline kernel. So
> this particular patch is not fixing a regression. Therefore we shouldn't
> send it upstream during the -rc time period. Instead we'll schedule it to
> be sent a few weeks later, during the 3.8 merge window.
Let's think about this some more:
The driver's commit is from March and is included in v3.4-rc1.
You say it will be working in 3.8, after 3.7 comes out, in about
December.
So how long does it take between merging code and actually getting it
working?
Sorry to harp on this so much, but I try out my patches with the tip
of the appropriate tree before sending them, or when I cannot, at
least I put into the log "compile tested only" or something like that.
Thanks,
Richard
^ permalink raw reply
* Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
From: Paul Walmsley @ 2012-10-18 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018182732.GC2350@netboy.at.omicron.at>
On Thu, 18 Oct 2012, Richard Cochran wrote:
> I *do* mind if y'all go merging all kinds of code that has never been
> tested. Those who submit and their reviewers should ensure that the
> code is actually working. Before buying hardware or starting projects,
> I often check what is in mainline. I expect that mainline has been at
> least minimally tested.
>
> Maybe that is just me, or maybe people working on the ARM tree have
> different expectations.
Any complaints or assumptions you might have in that regard should be
directed towards the netdev folks, since they're the ones who merged this
driver.
- Paul
^ permalink raw reply
* [RFC/NOT FOR MERGING 1/5] arm: omap: fix up _od_suspend_noirq and _od_resume_noirq
From: Kevin Hilman @ 2012-10-18 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121018175027.GA7917@arwen.pp.htv.fi>
Felipe Balbi <balbi@ti.com> writes:
> Hi,
>
> On Thu, Oct 18, 2012 at 10:42:37AM -0700, Kevin Hilman wrote:
>> Felipe Balbi <balbi@ti.com> writes:
>>
>> > Hi,
>> >
>> > On Thu, Oct 18, 2012 at 09:34:15AM -0700, Kevin Hilman wrote:
>> >> Felipe Balbi <balbi@ti.com> writes:
>> >>
>> >> > current implementation doesn't take care about
>> >> > drivers which don't provide *_noirq methods
>> >>
>> >> The generic ops handle this. See below.
>> >>
>> >> > and we could fall into a situation where we would suspend/resume
>> >> > devices even though they haven't asked for it.
>> >>
>> >> The following explanation doesn't explain this, so I dont' follow
>> >> the "even though they haven't asked for it" part.
>> >>
>> >> > One such case happened with the I2C driver which
>> >> > was getting suspended during suspend_noirq() just
>> >> > to be resume right after by any other device doing
>> >> > an I2C transfer on its suspend method.
>> >>
>> >> In order to be I2C to be runtime resumed after its noirq method has been
>> >> called, that means the other device is doing an I2C xfer in its noirq
>> >> method. That is a bug.
>> >>
>> >> > Signed-off-by: Felipe Balbi <balbi@ti.com>
>> >> > ---
>> >> > arch/arm/plat-omap/omap_device.c | 8 ++++++++
>> >> > 1 file changed, 8 insertions(+)
>> >> >
>> >> > diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
>> >> > index 7a7d1f2..935f416 100644
>> >> > --- a/arch/arm/plat-omap/omap_device.c
>> >> > +++ b/arch/arm/plat-omap/omap_device.c
>> >> > @@ -804,8 +804,12 @@ static int _od_suspend_noirq(struct device *dev)
>> >> > {
>> >> > struct platform_device *pdev = to_platform_device(dev);
>> >> > struct omap_device *od = to_omap_device(pdev);
>> >> > + const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
>> >> > int ret;
>> >> >
>> >> > + if (!pm || !pm->suspend_noirq)
>> >> > + return 0;
>> >> > +
>> >>
>> >> you just re implemented pm_generic_suspend_noirq() (c.f. drivers/base/power/generic_ops.c)
>> >>
>> >> > /* Don't attempt late suspend on a driver that is not bound */
>> >> > if (od->_driver_status != BUS_NOTIFY_BOUND_DRIVER)
>> >> > return 0;
>> >> > @@ -827,6 +831,10 @@ static int _od_resume_noirq(struct device *dev)
>> >> > {
>> >> > struct platform_device *pdev = to_platform_device(dev);
>> >> > struct omap_device *od = to_omap_device(pdev);
>> >> > + const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
>> >> > +
>> >> > + if (!pm || !pm->resume_noirq)
>> >> > + return 0;
>> >>
>> >> and this is basically pm_generic_resume_noirq()
>> >
>> > not true, there is a slight different. Note that you only call
>> > pm_generic_resume_noirq() after calling pm_runtime_resume()ing the
>> > device:
>>
>> >> static int _od_resume_noirq(struct device *dev)
>> >> {
>> >> struct platform_device *pdev = to_platform_device(dev);
>> >> struct omap_device *od = to_omap_device(pdev);
>> >>
>> >> if ((od->flags & OMAP_DEVICE_SUSPENDED) &&
>> >> !pm_runtime_status_suspended(dev)) {
>> >> od->flags &= ~OMAP_DEVICE_SUSPENDED;
>> >> if (!(od->flags & OMAP_DEVICE_NO_IDLE_ON_SUSPEND))
>> >> omap_device_enable(pdev);
>> >> pm_generic_runtime_resume(dev);
>> >
>> > right here. IMHO this is a bug, if the define doesn't implement
>> > resume_noirq, it's telling you that it has nothing to do at that time,
>>
>> This is where the misunderstanding is. I suggest you have a look
>> at commit c03f007a8bf0e092caeb6856a5c8a850df10b974 where this feature
>> was added, but I'll try to summarize:
>>
>> The goal is simply this:
>>
>> If, by the time .suspend_noirq has run, the driver is not already
>> runtime suspended, then forcefully runtime suspend it.
>>
>> That's it.
>
> Yes, I got the intention, but to me it looks wrong.
>
>> Again, this is required because system suspend disables runtime PM
>> transitions at a certain point, if the device is used after that point,
>> there is *no other way* for the driver to properly manage the idle
>> transition (or, if there is, please explain it to me.)
>
> Can you please let me know of any situation where e.g. I2C/SPI would be
> needed after all its children are suspended ?
There lots of I2C users who are not children of the I2C bus device. Any
users of regulators on the I2C-connected PMIC for example (MMC comes to
mind, and is not a child of the I2C bus.). Also, enable/disable of GPIO
IRQ lines on I2C GPIO expanders. The devices using those GPIO IRQs are
not children of the I2C bus.
Stated differently, I2C devices themselves (PMIC, GPIO expanders, etc.)
are children of the I2C bus device. But *users* of those devices will
be other drivers who have no parent/child relationship with the I2C bus
device in the driver model.
>> > so you shouldn't forcefully resume the device.
>>
>> Note it's only forcefully resumed *if* it was forcefully suspended by
>> suspend_noirq.
>
> likewise, you shouldn't forcefully runtime suspend a device. The device
> driver needs to be required to provide suspend/resume functions if it
> cares.
I don't think you've fully understood the problem being solved here.
This is for devices who designed for use throughout the suspend process
(IOW, *after* their suspend callbacks have been called.)
>> > If the device dies, then it means that it needs to implement
>> > resume_noirq. What you have here, is a "workaround" for badly written
>> > device drivers IMHO.
>>
>> That's one way of looking at it. The other way of looking at it is that
>> by handling this at the PM domain level, the drivers can be much simpler,
>> and thus less likely to get wrong.
>
> You're still bypassing what the PM framework wants us to do, no ? What
> if Rafael decides to drastically change the way system and runtime PM is
> done and it ends up breaking what we have on OMAP ? If we stick to the
> standard, the it's less likely to brea.
What I have done on OMAP was done in direct collaboration with the PM
core mantainers, and designed specifically for limitations in the PM
core. If those assumptions change, I will have to change. I have no
problems dealing with that if/when the time comes.
>> But even then, with your proposed changes, I don't think the device will
>> be properly idled (including the omap_device_idle) in these important cases:
>>
>> 1) I2C is used by some other device *after* its ->suspend method has
>> been called.
>
> how can that happen ? I2C's ->suspend method will only be called after
> all its children are suspended.
Unfortunately, drivers which use I2C are not all children of the I2C bus
device in the driver model (see above.)
This gets to a much bigger problem with the linux driver model today.
There are *many* power relationships/dependencies between devices that
are not modeled by driver model device hierarchy.
>> 2) I2C runtime PM is disabled from userspace
>> (echo off > /sys/devices/.../power/control)
>
> that should not make a difference if you omap_device_idle() is written
> as it should. Maybe what you need is a refactor to provide
> omap_device_idle() and omap_device_runtime_idle(), the latter taking
> care of the case where runtime pm can be disabled from userspace while
> the former idling whenever it's called.
No thanks.
>> but I'll take this up in the I2C driver patch itself.
>
> sure :-)
>
>> > Note also, that you could runtime resume devices which don't implement
>> > resume_noirq().
>>
>> Again, this is by design.
>
> a very weird design IMHO. Either that or I'm really missing something
> here.
I agree it's wierd. Unfortunately, it's necessary.
>> It doesn't matter if the driver has noirq methods. If it is not yet
>> runtime suspended, it is forceably runtime suspended. The generic
>
> if it's not yet runtime suspended, you need to call the driver's
> ->suspend_* method (depending on the suspend phase you are right now),
You're confusing system suspend and runtime suspend, and forgetting that
we might want to use runtime PM *during* system suspend/resume.
Again, the reason a device may not yet runtime suspended is because it
was in use during suspend, and runtime PM has been disabled by the PM
core during system PM. If the PM core did not disable runtime PM, the
drivers runtime PM methods would be called, and we would not need to
implement this in the PM domain layer.
> but "reusing" the runtime_suspend method sounds to me like another
> "special OMAP requirement".
There's nothing special about OMAP here. Any devices that want to use
runtime PM *throughout* the suspend path has this requirment, and the
implementation used in our PM domain layer was implemented based on the
recommendation of Rafael.
>> noirq calls are just there in case the driver has noirq callbacks.
>
> I get that, but why would you suspend a device which doesn't want to be
> suspended in suspend_noirq(), but using its runtime_suspend method ?
What do you mean "doesn't want to be suspended"? If a device doesn't
want to be suspended, it needs to return an error from one of its
suspend methods. Barring that, the system *will* suspend, and in order
to hit low power states, we have to properly idle each device.
The underlying assumption is that by the time the noirq phase runs, the
device should already be runtime suspended. If it is not, then one of
the following ha happened:
- device was used during suspend, but after runtime PM was disabled by
the PM core (during system suspend)
- runtime PM disabled from userspace
In both cases, *somebody* has to properly idle the device and "finish"
the runtime suspend late in the suspend phase. As recommended by
Rafael, we handle this at the PM domain level.
> If I2C dies on a suspend/resume transition, it's a bug in the I2C
> driver, no ?
Sure, but this has nothing to do with I2C dying.
Kevin
^ permalink raw reply
* [GIT PULL] first set of ux500 for ARM SoC for v3.8
From: Linus Walleij @ 2012-10-18 18:39 UTC (permalink / raw)
To: linux-arm-kernel
Hi ARM SoC folks,
here are two small commits for v3.8 that I'd like to make sure
land in ARM SoC before I begin with all the other stuff.
Please pull them in!
Yours,
Linus Walleij
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
ux500-core
for you to fetch changes up to 4040d10a3d44023703f81083bb90a3eb45a39eee:
ARM: ux500: add DB serial number to entropy pool (2012-10-15 13:53:55 +0200)
----------------------------------------------------------------
A first set of Ux500 core patches for v3.8:
- Support the HREF520 board
- Add the device serial number to the entropy pool
----------------------------------------------------------------
Linus Walleij (2):
ARM: ux500: support the HREFP520 board variant
ARM: ux500: add DB serial number to entropy pool
arch/arm/mach-ux500/board-mop500.c | 13 +++++++++++--
arch/arm/mach-ux500/cpu-db8500.c | 5 ++++-
2 files changed, 15 insertions(+), 3 deletions(-)
^ permalink raw reply
* 3.7-rc-1 Release Causing application failure for compilation
From: Baruch Siach @ 2012-10-18 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+V-a8uj4wSz60Ov8S3MpSrUe-D5+OcpVsFjURzSEcE6VdvGGQ@mail.gmail.com>
Hello Prabhakar Lad,
On Thu, Oct 18, 2012 at 09:49:34PM +0530, Prabhakar Lad wrote:
> I have updated to 3.7-rc1 kernel version with latest head with
> commit-id 43c422eda99b894f18d1cca17bcd2401efaf7bd0
> but when I try to cross compile the Application I am getting following errors.
>
> /home/plad/ti/linus/linus/include/linux/types.h:14:26: error:
> conflicting types for 'fd_set'
> /home/plad/CodeSourcery/Sourcery_G++_Lite/bin/../arm-none-linux-gnueabi/libc/usr/include/sys/select.h:78:5:
> note: previous declaration of 'fd_set' was here
> /home/plad/ti/linus/linus/include/linux/types.h:15:25: error:
[snip]
> I use the codesourcery toolchain for cross compiling the applications
> for ARM. The same compiler is used to build the uImage for ARM, but
> when I try building the apps I see this issue. Can any help me out in
> fixing this.
It seems that you are including kernel headers directly in your userspace
code. Don't do that. Types defined in kernel headers conflict with types
defined in your toolchain's kernel headers. Instead, just use the headers that
are part of your toolchain, which in turn include kernel headers that your
toolchain was built with.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ 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