* [PATCH 1/1] arm: omap: gpio: define .disable callback for gpio irq chip
From: David Brownell @ 2011-01-07 9:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110105202939.GC8717@n2100.arm.linux.org.uk>
> o lazy-disable state
This is an odd state, and confusion regularly
comes up ... I've never been a fan of having the
imperatively named disable_irq() act like a
disable_irq_at a_random_later_time_ _but_nyet(). If
one must have the latter function, clearer IMO
to name it better and have disable_irq()
do exactly that by the time it returns ... that
is after all what folk expect given its name and conventional interpretation of "disable".
(ergo confusion when that's not what happens)
lazy_disable_irq() would be accurate, butI'm not
sure many folk would choose to use it.
- Dave
^ permalink raw reply
* [PATCH V2] ST SPEAr: PCIE gadget suppport
From: pratyush @ 2011-01-07 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106184840.GA21672@kroah.com>
On 1/7/2011 12:18 AM, Greg KH wrote:
> On Thu, Jan 06, 2011 at 05:29:10PM +0530, Viresh Kumar wrote:
>> From: Pratyush Anand <pratyush.anand@st.com>
>>
>> This is a configurable gadget. can be configured by sysfs interface. Any
>> IP available at PCIE bus can be programmed to be used by host
>> controller.It supoorts both INTX and MSI.
>> By default, gadget is configured for INTX and SYSRAM1 is mapped to BAR0
>> with size 0x1000
>>
>> Changes since V1:
>> - __iomem added for register addresses
>> - kerneldoc comment removed whereever not required.
>> - help node moved from sysfs to documentation/misc-devices
>> - strict_strtoul used instead of sscanf
>>
>> Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
>> Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
>> ---
>> Documentation/misc-devices/spear-pcie-gadget.txt | 125 ++++
>
> New sysfs entries require updates to the Documentation/ABI/ directory
> for them.
>
> Please rework the patch to include these entries.
>
Ok..will send [Patch V3] with these modifications.
But, are these rework needed if I move this interface to configfs
as you have suggested below.
Or is there some different directory where documentation for configfs
node can be mentioned?
>> +read behaviour of nodes:
>> +------------------------------
>> +link :gives ltssm status.
>> +int_type :type of supported interrupt
>> +no_of_msi read :zero if MSI is not enabled by host.A positive value is the
>> + number of MSI vector granted.
>> +vendor_id :returns programmed vendor id (hex)
>> +device_id :returns programmed device id(hex)
>> +bar0_size: :retruns size of bar0 in hex.
>> +bar0_address :returns address of bar0 mapped area in hex.
>> +bar0_rw_offset :returns offset of bar0 for which bar0_data will return value.
>> +bar0_data :returns data at bar0_rw_offset.
>> +
>> +write behaviour of nodes:
>> +------------------------------
>> +link :write UP to enable ltsmm DOWN to disable
>> +int_type :write interrupt type to be configured and (int_type could be
>> + INTA, MSI or NO_INT).select MSI only when you have programmed
>> + no_of_msi node.
>> +no_of_msi :number of MSI vector needed.
>> +inta :write 1 to assert INTA and 0 to de-assert.
>> +send_msi :write MSI vector to be send.
>> +vendor_id :write vendor id(hex) to be programmed.
>> +device_id :write device id(hex) to be programmed.
>> +bar0_size :write size of bar0 in hex. default bar0 size is 1000 (hex)
>> + bytes.
>> +bar0_address :write address of bar0 mapped area in hex. (default mapping of
>> + bar0 is SYSRAM1(E0800000).Aalways program bar size before bar
>> + address. kernel might modify bar size and address to align. So
>> + read back bar size and address after writing to cross check.
>> +bar0_rw_offset :write offset of bar0 for which bar0_data will write value.
>> +bar0_data :write data to be written at bar0_rw_offset.
>
> Should you use configfs for this instead of sysfs? It looks like that
> is what you are looking for here.
>
configfs seems better option. Will do that in V3.
Regards
Pratyush
> thanks,
>
> greg k-h
> .
>
^ permalink raw reply
* [PATCH V2] ST SPEAr: PCIE gadget suppport
From: pratyush @ 2011-01-07 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106121853.016fb990.akpm@linux-foundation.org>
On 1/7/2011 1:48 AM, Andrew Morton wrote:
> On Thu, 6 Jan 2011 17:29:10 +0530
> Viresh Kumar <viresh.kumar@st.com> wrote:
>
>> From: Pratyush Anand <pratyush.anand@st.com>
>>
>> This is a configurable gadget. can be configured by sysfs interface. Any
>> IP available at PCIE bus can be programmed to be used by host
>> controller.It supoorts both INTX and MSI.
>> By default, gadget is configured for INTX and SYSRAM1 is mapped to BAR0
>> with size 0x1000
>>
>> ...
>>
>> --- /dev/null
>> +++ b/Documentation/misc-devices/spear-pcie-gadget.txt
>
> Please recheck this documentation file - it contains a number of simple
> typos.
>
will check that and send PATCH V3.
>>
>> ...
>>
>> + if (strict_strtoul(buf, 0, &config->requested_msi))
>> + return -EINVAL;
>
> It doesn't matter much, but the code really should propagate the
> strict_strtoul() return error code back to the caller, rather than
> overwriting it with -EINVAL.
>
will do that modification in PATCH V3.
Regards
Pratyush
> .
>
^ permalink raw reply
* Memory sharing issue by application on V4L2 based device driver with system mmu.
From: Michel Dänzer @ 2011-01-07 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinsduJkynwwEeM5K9f3D7C6jtBgkAyZ0-_0z2X-@mail.gmail.com>
On Fre, 2011-01-07 at 11:17 +0900, InKi Dae wrote:
> thank you for your comments.
>
> your second comment has no any problem as I said before, user virtual
> addess could be translated in page unit. but the problem, as you said,
> is that when cpu access to the memory in user mode, the memory
> allocated by malloc, page fault occurs so we can't find pfn to user
> virtual address. I missed that. but I think we could resolve this one.
>
> as before, user application allocates memory through malloc function
> and then send it to device driver(using userptr feature). if the pfn
> is null when device driver translated user virtual address in page
> unit then it allocates phsical memory in page unit using some
> interface such as alloc_page() and then mapping them. when pfn is
> null, to check it and allocate physical memory in page unit could be
> processed by videobuf2.
>
> of course, videobuf2 has no any duty considered for system mmu. so
> videobuf2 just provides callback for 3rd party and any platform with
> system mmu such as Samsung SoC C210 implements the function(allocating
> physical memory and mapping it) and registers it to callback of
> videobuf2. by doing so, I think your first comment could be cleared.
FWIW, TTM (drivers/gpu/drm/ttm, include/drm/ttm) is designed and used
for managing memory between CPU/GPU and kernel/userspace access. I
haven't looked at your requirements in detail, but if you haven't looked
at TTM yet, it sounds like it might be worth a look.
--
Earthling Michel D?nzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* [PATCH] omap: wd_timer: Fix crash frm wdt_probe when !CONFIG_RUNTIME_PM
From: Santosh Shilimkar @ 2011-01-07 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1101061120480.31961@utopia.booyaka.com>
> -----Original Message-----
> From: Paul Walmsley [mailto:paul at pwsan.com]
> Sent: Thursday, January 06, 2011 11:56 PM
> To: Santosh Shilimkar
> Cc: linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH] omap: wd_timer: Fix crash frm wdt_probe when
> !CONFIG_RUNTIME_PM
>
> Hi Santosh,
>
> On Wed, 5 Jan 2011, Santosh Shilimkar wrote:
>
> > Commit ff2516fb 'wd_timer: disable on boot via hwmod postsetup
> mechanism'
> > introduced watchdog timer state state management using
> postsetup_state.
> > This was done to allow some board files to support watchdog
> coverage
> > throughout kernel initialization and it work as intended when
> RUNTIME_PM
> > is enabled.
> >
> > With !CONFIG_RUNTIME_PM and no board is specifically requests
> watchdog
> > to remain enabled the omap_wdt_probe crashesh. This is because
> hwmod
> > in absense of runtime PM unable to turn watchdog clocks because
> it's
> > state is set to be disabled. For rest of the device, the state is
> > set as enabled in absense of RUNTIME_PM
> >
> > [ 1.372558] Unhandled fault: imprecise external abort (0x1406)
> at 0xad733eeb
> > [ 1.379913] Internal error: : 1406 [#1] SMP
> > [ 1.384277] last sysfs file:
> > [ 1.387359] Modules linked in:
> > [ 1.390563] CPU: 0 Tainted: G W (2.6.37-rc7-00265-
> g4298a4c-dirty #23)
> > [ 1.398468] PC is at omap_wdt_disable+0x2c/0x3c
> > [ 1.403198] LR is at omap_wdt_probe+0x124/0x1e0
> > [ 1.407928] pc : [<c02f5bf4>] lr : [<c03be10c>] psr:
> 60000013
> > [ 1.407958] sp : df833f00 ip : 00000000 fp : 00000000
> > [ 1.419921] r10: c0ac57ac r9 : df959e00 r8 : 00000000
> > [ 1.425384] r7 : df959e08 r6 : df8000c0 r5 : df95bebc r4 :
> df87dde0
> > [ 1.432189] r3 : fc314000 r2 : 00005555 r1 : fc314034 r0 :
> df87dde0
> >
> > This patch make the default watchdog state to be enabled in case
> of
> > !CONFIG_RUNTIME_PM. This fixes the crash
> >
> > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > Cc: Paul Walmsley <paul@pwsan.com>
> > ---
> > Paul, I am not too sure if it breaks your _shutdown idea of
> watchdog
> > timer.
>
> Maybe. What happens in a case where the bootloader enables the
> watchdog,
> but the booting kernel is compiled with !CONFIG_OMAP_WATCHDOG and
> !CONFIG_PM_RUNTIME? Won't the watchdog reset the MPU unexpectedly
> in that
> case? Or am I missing something...
>
I had a same doubght. But the test I did with and without
"CONFIG_OMAP_WATCHDOG" just at kernel level. The TI bootloader
have MPU watchdog being always disabled.
Will do a test on this scenario by explicitly disabling the
MPU WDT in bootloader.
Regards,
Santosh
^ permalink raw reply
* [PATCH v2 2/5] omap2plus: prm: Trvial build break fix for undefined reference to 'omap2_prm_read_mod_reg'
From: Santosh Shilimkar @ 2011-01-07 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1101061056340.22048@utopia.booyaka.com>
> -----Original Message-----
> From: Paul Walmsley [mailto:paul at pwsan.com]
> Sent: Thursday, January 06, 2011 11:28 PM
> To: Santosh Shilimkar
> Cc: linux-omap at vger.kernel.org; khilman at ti.com; tony at atomide.com;
> linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH v2 2/5] omap2plus: prm: Trvial build break fix
> for undefined reference to 'omap2_prm_read_mod_reg'
>
> Hi Santosh
>
> On Wed, 5 Jan 2011, Santosh Shilimkar wrote:
>
> > omap2plus_defocnfig build breaks when customised with only
> ARCH_OMAP4
> > selected. This is because common files make references to the
> functions
> > which are defined only for omap2xxx and omap3xxx.
>
> ...
>
> >
> > This patch adds stubs for these functions so that build continues
> to work.
> >
> > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > Cc: Paul Walmsley <paul@pwsan.com>
> > ---
> > arch/arm/mach-omap2/prm2xxx_3xxx.h | 63
> +++++++++++++++++++++++++++++++++++-
> > 1 files changed, 62 insertions(+), 1 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.h b/arch/arm/mach-
> omap2/prm2xxx_3xxx.h
> > index 53d44f6..843f329 100644
> > --- a/arch/arm/mach-omap2/prm2xxx_3xxx.h
> > +++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h
> > @@ -228,7 +228,67 @@
> >
> >
> > #ifndef __ASSEMBLER__
> > -
> > +/*
> > + * Stub omap2xxx/omap3xxx functions so that common files
> > + * continue to build when custom builds are used
> > + */
> > +#if defined(CONFIG_ARCH_OMAP4) && !(defined(CONFIG_ARCH_OMAP2) ||
> \
> > + defined(CONFIG_ARCH_OMAP3))
> > +static inline u32 omap2_prm_read_mod_reg(s16 module, u16 idx)
> > +{
> > + WARN_ONCE(1, "prm: omap2xxx/omap3xxx specific function and "
> > + "not suppose to be used on omap4\n");
> > + return 0;
> > +}
>
> I think it would be best to use WARN() on these, rather than
> WARN_ONCE().
> That's because these could be called from different parts of the
> code
> base, and the stack backtrace will help someone figure out all the
> code
> that needs to be fixed.
>
Ok.
> Once you do that, this patch is
>
> Acked-by: Paul Walmsley <paul@pwsan.com>
>
Thanks
^ permalink raw reply
* [PATCH v2 1/5] omap2plus: clockdomain: Trivial fix for build break because of clktrctrl_mask
From: Rajendra Nayak @ 2011-01-07 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87ipy1vqdi.fsf@ti.com>
> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org
[mailto:linux-omap-owner at vger.kernel.org] On Behalf Of Kevin Hilman
> Sent: Thursday, January 06, 2011 11:58 PM
> To: Paul Walmsley
> Cc: Santosh Shilimkar; linux-omap at vger.kernel.org; tony at atomide.com;
linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH v2 1/5] omap2plus: clockdomain: Trivial fix for
build break because of clktrctrl_mask
>
> Paul Walmsley <paul@pwsan.com> writes:
>
> > On Wed, 5 Jan 2011, Kevin Hilman wrote:
> >
> >> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> >>
> >> > struct clockdomain member clktrctrl_mask is available for only for
OMAP2
> >> > and OMAP3 architectures. Technially it is also used only for these
archs
> >> > but this breaks the build with custom OMAP4 configuration.
> >>
> >> I'll queue patches 3-5 for the 2.6.38-rc fixes cycle.
> >>
> >> With Paul's ack, I can queue the others too, or Paul can decide to
take
> >> them via his tree. Paul can decide.
> >
> > I've acked one and requested minor changes on the other, after which
it
> > can be acked by me. You're welcome to take them at that point. Just
a
> > request, maybe you can post a branch with just these patches in them;
that
> > way Rajendra and/or I can rebase his new clockdomain changes on it
until
> > -rc1 comes out.
>
> Sure, will do.
Just another trivial fix.
^ permalink raw reply
* [PATCH] OMAP: powerdomain: remove unused func declaration
From: Rajendra Nayak @ 2011-01-07 8:37 UTC (permalink / raw)
To: linux-arm-kernel
Trivial fix to remove the unused function declaration
from the powerdomain header.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
arch/arm/mach-omap2/powerdomain.h | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index c66431e..0b7a357 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -165,7 +165,6 @@ struct pwrdm_ops {
int (*pwrdm_wait_transition)(struct powerdomain *pwrdm);
};
-void pwrdm_fw_init(void);
void pwrdm_init(struct powerdomain **pwrdm_list, struct pwrdm_ops
*custom_funcs);
struct powerdomain *pwrdm_lookup(const char *name);
--
1.7.0.4
>
> I currently have a 'fixes-for-tony' branch in my tree which has all the
> fixes I've collected for the -rc cycle.
>
> If you prefer something separate with only the prm and clockdomain
> patches from this series, I can do that as well.
>
> Kevin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--001517478c1086211304993d93fe
Content-Type: application/octet-stream;
name="0001-OMAP-powerdomain-remove-unused-func-declaration.patch"
Content-Disposition: attachment;
filename="0001-OMAP-powerdomain-remove-unused-func-declaration.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: 98bf8ae8cb917994_0.1
RnJvbSBiYjQ2Yjc0ZDJiMGFiM2QzNWU3MmI3NjBkYTdlMTIzYTg5MWU2ODEzIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBSYWplbmRyYSBOYXlhayA8cm5heWFrQHRpLmNvbT4KRGF0ZTog
RnJpLCA3IEphbiAyMDExIDE0OjA3OjI1ICswNTMwClN1YmplY3Q6IFtQQVRDSF0gT01BUDogcG93
ZXJkb21haW46IHJlbW92ZSB1bnVzZWQgZnVuYyBkZWNsYXJhdGlvbgoKVHJpdmlhbCBmaXggdG8g
cmVtb3ZlIHRoZSB1bnVzZWQgZnVuY3Rpb24gZGVjbGFyYXRpb24KZnJvbSB0aGUgcG93ZXJkb21h
aW4gaGVhZGVyLgoKU2lnbmVkLW9mZi1ieTogUmFqZW5kcmEgTmF5YWsgPHJuYXlha0B0aS5jb20+
Ci0tLQogYXJjaC9hcm0vbWFjaC1vbWFwMi9wb3dlcmRvbWFpbi5oIHwgICAgMSAtCiAxIGZpbGVz
IGNoYW5nZWQsIDAgaW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9h
cmNoL2FybS9tYWNoLW9tYXAyL3Bvd2VyZG9tYWluLmggYi9hcmNoL2FybS9tYWNoLW9tYXAyL3Bv
d2VyZG9tYWluLmgKaW5kZXggYzY2NDMxZS4uMGI3YTM1NyAxMDA2NDQKLS0tIGEvYXJjaC9hcm0v
bWFjaC1vbWFwMi9wb3dlcmRvbWFpbi5oCisrKyBiL2FyY2gvYXJtL21hY2gtb21hcDIvcG93ZXJk
b21haW4uaApAQCAtMTY1LDcgKzE2NSw2IEBAIHN0cnVjdCBwd3JkbV9vcHMgewogCWludAkoKnB3
cmRtX3dhaXRfdHJhbnNpdGlvbikoc3RydWN0IHBvd2VyZG9tYWluICpwd3JkbSk7CiB9OwogCi12
b2lkIHB3cmRtX2Z3X2luaXQodm9pZCk7CiB2b2lkIHB3cmRtX2luaXQoc3RydWN0IHBvd2VyZG9t
YWluICoqcHdyZG1fbGlzdCwgc3RydWN0IHB3cmRtX29wcyAqY3VzdG9tX2Z1bmNzKTsKIAogc3Ry
dWN0IHBvd2VyZG9tYWluICpwd3JkbV9sb29rdXAoY29uc3QgY2hhciAqbmFtZSk7Ci0tIAoxLjcu
MC40Cgo=
--001517478c1086211304993d93fe--
^ permalink raw reply related
* [PATCH v3 05/10] net/fec: add dual fec support for mx28
From: Shawn Guo @ 2011-01-07 7:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106071047.GW25121@pengutronix.de>
Hi Uwe,
On Thu, Jan 06, 2011 at 08:10:47AM +0100, Uwe Kleine-K?nig wrote:
> Hello Shawn,
>
[...]
> > > > + /*
> > > > + * enet-mac reset will reset mac address registers too,
> > > > + * so need to reconfigure it.
> > > > + */
> > > > + if (fec_is_enetmac) {
> > > > + memcpy(&temp_mac, dev->dev_addr, ETH_ALEN);
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > + writel(cpu_to_be32(temp_mac[0]), fep->hwp + FEC_ADDR_LOW);
> > > > + writel(cpu_to_be32(temp_mac[1]), fep->hwp + FEC_ADDR_HIGH);
> > > where is the value saved to temp_mac[]? For me it looks you write
> > > uninitialized data into the mac registers.
> >
> > memcpy above.
> oops. right. I looked for something like
>
> temp_mac[0] = dev->dev_addr[0] << $shiftfor0 | ...
>
> which AFAIK is what you want here. memcpy is sensible to (at least)
> endian issues. If you ask me factor out the setting of the mac address
> in probe to a function and use that here, too.
>
The memcpy of mac address is being widely used in fec and other
network drivers, and I do not prefer to change something so common
in this patch set.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH v2 3/3] ARM i.MX53 enable sdhc support on EVK board
From: yong.shen at freescale.com @ 2011-01-07 4:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294374334-18920-1-git-send-email-yong.shen@freescale.com>
From: Yong Shen <yong.shen@freescale.com>
1. changes some register address to fit macro definition
2. add platform data and clock for sdhc
Signed-off-by: Yong Shen <yong.shen@freescale.com>
---
arch/arm/mach-mx5/Kconfig | 1 +
arch/arm/mach-mx5/board-mx53_evk.c | 3 +++
arch/arm/mach-mx5/clock-mx51-mx53.c | 2 ++
arch/arm/mach-mx5/devices-imx53.h | 5 +++++
.../plat-mxc/devices/platform-sdhci-esdhc-imx.c | 12 ++++++++++++
arch/arm/plat-mxc/include/mach/mx53.h | 16 ++++++++--------
6 files changed, 31 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
index 632d711..23b0e3f 100644
--- a/arch/arm/mach-mx5/Kconfig
+++ b/arch/arm/mach-mx5/Kconfig
@@ -125,6 +125,7 @@ config MACH_MX53_EVK
select SOC_IMX53
select IMX_HAVE_PLATFORM_IMX_UART
select IMX_HAVE_PLATFORM_IMX_I2C
+ select IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX
help
Include support for MX53 EVK platform. This includes specific
configurations for the board and its peripherals.
diff --git a/arch/arm/mach-mx5/board-mx53_evk.c b/arch/arm/mach-mx5/board-mx53_evk.c
index d0b4570..4043451 100644
--- a/arch/arm/mach-mx5/board-mx53_evk.c
+++ b/arch/arm/mach-mx5/board-mx53_evk.c
@@ -99,6 +99,9 @@ static void __init mx53_evk_board_init(void)
imx53_add_imx_i2c(0, &mx53_evk_i2c_data);
imx53_add_imx_i2c(1, &mx53_evk_i2c_data);
+
+ imx53_add_sdhci_esdhc_imx(0, NULL);
+ imx53_add_sdhci_esdhc_imx(1, NULL);
}
static void __init mx53_evk_timer_init(void)
diff --git a/arch/arm/mach-mx5/clock-mx51-mx53.c b/arch/arm/mach-mx5/clock-mx51-mx53.c
index 0ade3c4..15fa89e 100644
--- a/arch/arm/mach-mx5/clock-mx51-mx53.c
+++ b/arch/arm/mach-mx5/clock-mx51-mx53.c
@@ -1328,6 +1328,8 @@ static struct clk_lookup mx53_lookups[] = {
_REGISTER_CLOCK(NULL, "iim_clk", iim_clk)
_REGISTER_CLOCK("imx-i2c.0", NULL, i2c1_clk)
_REGISTER_CLOCK("imx-i2c.1", NULL, i2c2_clk)
+ _REGISTER_CLOCK("sdhci-esdhc-imx.0", NULL, esdhc1_clk)
+ _REGISTER_CLOCK("sdhci-esdhc-imx.1", NULL, esdhc2_clk)
};
static void clk_tree_init(void)
diff --git a/arch/arm/mach-mx5/devices-imx53.h b/arch/arm/mach-mx5/devices-imx53.h
index ca1232b..f7c89ef 100644
--- a/arch/arm/mach-mx5/devices-imx53.h
+++ b/arch/arm/mach-mx5/devices-imx53.h
@@ -20,3 +20,8 @@ extern const struct imx_imx_uart_1irq_data imx53_imx_uart_data[] __initconst;
extern const struct imx_imx_i2c_data imx53_imx_i2c_data[] __initconst;
#define imx53_add_imx_i2c(id, pdata) \
imx_add_imx_i2c(&imx53_imx_i2c_data[id], pdata)
+
+extern const struct imx_sdhci_esdhc_imx_data
+imx53_sdhci_esdhc_imx_data[] __initconst;
+#define imx53_add_sdhci_esdhc_imx(id, pdata) \
+ imx_add_sdhci_esdhc_imx(&imx53_sdhci_esdhc_imx_data[id], pdata)
diff --git a/arch/arm/plat-mxc/devices/platform-sdhci-esdhc-imx.c b/arch/arm/plat-mxc/devices/platform-sdhci-esdhc-imx.c
index b352564..6b2940b 100644
--- a/arch/arm/plat-mxc/devices/platform-sdhci-esdhc-imx.c
+++ b/arch/arm/plat-mxc/devices/platform-sdhci-esdhc-imx.c
@@ -53,6 +53,18 @@ imx51_sdhci_esdhc_imx_data[] __initconst = {
};
#endif /* ifdef CONFIG_SOC_IMX51 */
+#ifdef CONFIG_SOC_IMX53
+const struct imx_sdhci_esdhc_imx_data
+imx53_sdhci_esdhc_imx_data[] __initconst = {
+#define imx53_sdhci_esdhc_imx_data_entry(_id, _hwid) \
+ imx_sdhci_esdhc_imx_data_entry(MX53, _id, _hwid)
+ imx53_sdhci_esdhc_imx_data_entry(0, 1),
+ imx53_sdhci_esdhc_imx_data_entry(1, 2),
+ imx53_sdhci_esdhc_imx_data_entry(2, 3),
+ imx53_sdhci_esdhc_imx_data_entry(3, 4),
+};
+#endif /* ifdef CONFIG_SOC_IMX53 */
+
struct platform_device *__init imx_add_sdhci_esdhc_imx(
const struct imx_sdhci_esdhc_imx_data *data,
const struct esdhc_platform_data *pdata)
diff --git a/arch/arm/plat-mxc/include/mach/mx53.h b/arch/arm/plat-mxc/include/mach/mx53.h
index a35e0c7..340937f 100644
--- a/arch/arm/plat-mxc/include/mach/mx53.h
+++ b/arch/arm/plat-mxc/include/mach/mx53.h
@@ -53,13 +53,13 @@
#define MX53_SPBA0_BASE_ADDR 0x50000000
#define MX53_SPBA0_SIZE SZ_1M
-#define MX53_MMC_SDHC1_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00004000)
-#define MX53_MMC_SDHC2_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00008000)
+#define MX53_ESDHC1_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00004000)
+#define MX53_ESDHC2_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00008000)
#define MX53_UART3_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x0000C000)
#define MX53_CSPI1_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00010000)
#define MX53_SSI2_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00014000)
-#define MX53_MMC_SDHC3_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00020000)
-#define MX53_MMC_SDHC4_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00024000)
+#define MX53_ESDHC3_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00020000)
+#define MX53_ESDHC4_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00024000)
#define MX53_SPDIF_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00028000)
#define MX53_ASRC_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x0002C000)
#define MX53_ATA_DMA_BASE_ADDR (MX53_SPBA0_BASE_ADDR + 0x00030000)
@@ -229,10 +229,10 @@
* Interrupt numbers
*/
#define MX53_INT_RESV0 0
-#define MX53_INT_MMC_SDHC1 1
-#define MX53_INT_MMC_SDHC2 2
-#define MX53_INT_MMC_SDHC3 3
-#define MX53_INT_MMC_SDHC4 4
+#define MX53_INT_ESDHC1 1
+#define MX53_INT_ESDHC2 2
+#define MX53_INT_ESDHC3 3
+#define MX53_INT_ESDHC4 4
#define MX53_INT_RESV5 5
#define MX53_INT_SDMA 6
#define MX53_INT_IOMUX 7
--
1.7.1
^ permalink raw reply related
* [PATCH v2 2/3] ARM i.MX53 enable i2c on EVK board
From: yong.shen at freescale.com @ 2011-01-07 4:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294374334-18920-1-git-send-email-yong.shen@freescale.com>
From: Yong Shen <yong.shen@freescale.com>
add i2c platform data and clock
Signed-off-by: Yong Shen <yong.shen@freescale.com>
---
arch/arm/mach-mx5/Kconfig | 1 +
arch/arm/mach-mx5/board-mx53_evk.c | 7 +++++++
arch/arm/mach-mx5/clock-mx51-mx53.c | 2 ++
arch/arm/mach-mx5/devices-imx53.h | 5 +++++
arch/arm/plat-mxc/devices/platform-imx-i2c.c | 9 +++++++++
5 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
index 55254b6..632d711 100644
--- a/arch/arm/mach-mx5/Kconfig
+++ b/arch/arm/mach-mx5/Kconfig
@@ -124,6 +124,7 @@ config MACH_MX53_EVK
bool "Support MX53 EVK platforms"
select SOC_IMX53
select IMX_HAVE_PLATFORM_IMX_UART
+ select IMX_HAVE_PLATFORM_IMX_I2C
help
Include support for MX53 EVK platform. This includes specific
configurations for the board and its peripherals.
diff --git a/arch/arm/mach-mx5/board-mx53_evk.c b/arch/arm/mach-mx5/board-mx53_evk.c
index 8a744ae..d0b4570 100644
--- a/arch/arm/mach-mx5/board-mx53_evk.c
+++ b/arch/arm/mach-mx5/board-mx53_evk.c
@@ -65,6 +65,10 @@ static inline void mx53_evk_init_uart(void)
imx53_add_imx_uart(2, &mx53_evk_uart_pdata);
}
+static const struct imxi2c_platform_data mx53_evk_i2c_data __initconst = {
+ .bitrate = 100000,
+};
+
static inline void mx53_evk_fec_reset(void)
{
int ret;
@@ -92,6 +96,9 @@ static void __init mx53_evk_board_init(void)
mx53_evk_init_uart();
mx53_evk_fec_reset();
imx53_add_fec(&mx53_evk_fec_pdata);
+
+ imx53_add_imx_i2c(0, &mx53_evk_i2c_data);
+ imx53_add_imx_i2c(1, &mx53_evk_i2c_data);
}
static void __init mx53_evk_timer_init(void)
diff --git a/arch/arm/mach-mx5/clock-mx51-mx53.c b/arch/arm/mach-mx5/clock-mx51-mx53.c
index b21bc47..0ade3c4 100644
--- a/arch/arm/mach-mx5/clock-mx51-mx53.c
+++ b/arch/arm/mach-mx5/clock-mx51-mx53.c
@@ -1326,6 +1326,8 @@ static struct clk_lookup mx53_lookups[] = {
_REGISTER_CLOCK(NULL, "gpt", gpt_clk)
_REGISTER_CLOCK("fec.0", NULL, fec_clk)
_REGISTER_CLOCK(NULL, "iim_clk", iim_clk)
+ _REGISTER_CLOCK("imx-i2c.0", NULL, i2c1_clk)
+ _REGISTER_CLOCK("imx-i2c.1", NULL, i2c2_clk)
};
static void clk_tree_init(void)
diff --git a/arch/arm/mach-mx5/devices-imx53.h b/arch/arm/mach-mx5/devices-imx53.h
index dbf1989..ca1232b 100644
--- a/arch/arm/mach-mx5/devices-imx53.h
+++ b/arch/arm/mach-mx5/devices-imx53.h
@@ -15,3 +15,8 @@ extern const struct imx_fec_data imx53_fec_data __initconst;
extern const struct imx_imx_uart_1irq_data imx53_imx_uart_data[] __initconst;
#define imx53_add_imx_uart(id, pdata) \
imx_add_imx_uart_1irq(&imx53_imx_uart_data[id], pdata)
+
+
+extern const struct imx_imx_i2c_data imx53_imx_i2c_data[] __initconst;
+#define imx53_add_imx_i2c(id, pdata) \
+ imx_add_imx_i2c(&imx53_imx_i2c_data[id], pdata)
diff --git a/arch/arm/plat-mxc/devices/platform-imx-i2c.c b/arch/arm/plat-mxc/devices/platform-imx-i2c.c
index 72ba880..7ba94e1 100644
--- a/arch/arm/plat-mxc/devices/platform-imx-i2c.c
+++ b/arch/arm/plat-mxc/devices/platform-imx-i2c.c
@@ -78,6 +78,15 @@ const struct imx_imx_i2c_data imx51_imx_i2c_data[] __initconst = {
};
#endif /* ifdef CONFIG_SOC_IMX51 */
+#ifdef CONFIG_SOC_IMX53
+const struct imx_imx_i2c_data imx53_imx_i2c_data[] __initconst = {
+#define imx53_imx_i2c_data_entry(_id, _hwid) \
+ imx_imx_i2c_data_entry(MX53, _id, _hwid, SZ_4K)
+ imx53_imx_i2c_data_entry(0, 1),
+ imx53_imx_i2c_data_entry(1, 2),
+};
+#endif /* ifdef CONFIG_SOC_IMX51 */
+
struct platform_device *__init imx_add_imx_i2c(
const struct imx_imx_i2c_data *data,
const struct imxi2c_platform_data *pdata)
--
1.7.1
^ permalink raw reply related
* [PATCH v2 1/3] ARM i.MX53: enable fec driver on EVK board
From: yong.shen at freescale.com @ 2011-01-07 4:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294374334-18920-1-git-send-email-yong.shen@freescale.com>
From: Yong Shen <yong.shen@freescale.com>
1. Adjust FEC base address name to fit macro definition
2. Add platform data and reset function for FEC
Signed-off-by: Yong Shen <yong.shen@freescale.com>
---
arch/arm/mach-mx5/board-mx53_evk.c | 27 +++++++++++++++++++++++++++
arch/arm/mach-mx5/devices-imx53.h | 4 ++++
arch/arm/plat-mxc/devices/Kconfig | 2 +-
arch/arm/plat-mxc/devices/platform-fec.c | 5 +++++
arch/arm/plat-mxc/include/mach/mx53.h | 2 +-
5 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mx5/board-mx53_evk.c b/arch/arm/mach-mx5/board-mx53_evk.c
index fa97d0d..8a744ae 100644
--- a/arch/arm/mach-mx5/board-mx53_evk.c
+++ b/arch/arm/mach-mx5/board-mx53_evk.c
@@ -21,6 +21,9 @@
#include <linux/init.h>
#include <linux/clk.h>
+#include <linux/fec.h>
+#include <linux/delay.h>
+#include <linux/gpio.h>
#include <mach/common.h>
#include <mach/hardware.h>
#include <asm/mach-types.h>
@@ -29,6 +32,8 @@
#include <mach/imx-uart.h>
#include <mach/iomux-mx53.h>
+#define SMD_FEC_PHY_RST IMX_GPIO_NR(7, 6)
+
#include "crm_regs.h"
#include "devices-imx53.h"
@@ -60,11 +65,33 @@ static inline void mx53_evk_init_uart(void)
imx53_add_imx_uart(2, &mx53_evk_uart_pdata);
}
+static inline void mx53_evk_fec_reset(void)
+{
+ int ret;
+
+ /* reset FEC PHY */
+ ret = gpio_request(SMD_FEC_PHY_RST, "fec-phy-reset");
+ if (ret) {
+ printk(KERN_ERR"failed to get GPIO_FEC_PHY_RESET: %d\n", ret);
+ return;
+ }
+ gpio_direction_output(SMD_FEC_PHY_RST, 0);
+ gpio_set_value(SMD_FEC_PHY_RST, 0);
+ msleep(1);
+ gpio_set_value(SMD_FEC_PHY_RST, 1);
+}
+
+static struct fec_platform_data mx53_evk_fec_pdata = {
+ .phy = PHY_INTERFACE_MODE_RMII,
+};
+
static void __init mx53_evk_board_init(void)
{
mxc_iomux_v3_setup_multiple_pads(mx53_evk_pads,
ARRAY_SIZE(mx53_evk_pads));
mx53_evk_init_uart();
+ mx53_evk_fec_reset();
+ imx53_add_fec(&mx53_evk_fec_pdata);
}
static void __init mx53_evk_timer_init(void)
diff --git a/arch/arm/mach-mx5/devices-imx53.h b/arch/arm/mach-mx5/devices-imx53.h
index 9d0ec25..dbf1989 100644
--- a/arch/arm/mach-mx5/devices-imx53.h
+++ b/arch/arm/mach-mx5/devices-imx53.h
@@ -8,6 +8,10 @@
#include <mach/mx53.h>
#include <mach/devices-common.h>
+extern const struct imx_fec_data imx53_fec_data __initconst;
+#define imx53_add_fec(pdata) \
+ imx_add_fec(&imx53_fec_data, pdata)
+
extern const struct imx_imx_uart_1irq_data imx53_imx_uart_data[] __initconst;
#define imx53_add_imx_uart(id, pdata) \
imx_add_imx_uart_1irq(&imx53_imx_uart_data[id], pdata)
diff --git a/arch/arm/plat-mxc/devices/Kconfig b/arch/arm/plat-mxc/devices/Kconfig
index 2537166..b9ab1d5 100644
--- a/arch/arm/plat-mxc/devices/Kconfig
+++ b/arch/arm/plat-mxc/devices/Kconfig
@@ -1,6 +1,6 @@
config IMX_HAVE_PLATFORM_FEC
bool
- default y if ARCH_MX25 || SOC_IMX27 || SOC_IMX35 || SOC_IMX51
+ default y if ARCH_MX25 || SOC_IMX27 || SOC_IMX35 || SOC_IMX51 || SOC_IMX53
config IMX_HAVE_PLATFORM_FLEXCAN
select HAVE_CAN_FLEXCAN if CAN
diff --git a/arch/arm/plat-mxc/devices/platform-fec.c b/arch/arm/plat-mxc/devices/platform-fec.c
index 269ec78..b50c351 100644
--- a/arch/arm/plat-mxc/devices/platform-fec.c
+++ b/arch/arm/plat-mxc/devices/platform-fec.c
@@ -36,6 +36,11 @@ const struct imx_fec_data imx51_fec_data __initconst =
imx_fec_data_entry_single(MX51);
#endif
+#ifdef CONFIG_SOC_IMX53
+const struct imx_fec_data imx53_fec_data __initconst =
+ imx_fec_data_entry_single(MX53);
+#endif
+
struct platform_device *__init imx_add_fec(
const struct imx_fec_data *data,
const struct fec_platform_data *pdata)
diff --git a/arch/arm/plat-mxc/include/mach/mx53.h b/arch/arm/plat-mxc/include/mach/mx53.h
index 9577cdb..a35e0c7 100644
--- a/arch/arm/plat-mxc/include/mach/mx53.h
+++ b/arch/arm/plat-mxc/include/mach/mx53.h
@@ -136,7 +136,7 @@
#define MX53_MIPI_HSC_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000DC000)
#define MX53_MLB_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000E4000)
#define MX53_SSI3_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000E8000)
-#define MX53_MXC_FEC_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000EC000)
+#define MX53_FEC_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000EC000)
#define MX53_TVE_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000F0000)
#define MX53_VPU_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000F4000)
#define MX53_SAHARA_BASE_ADDR (MX53_AIPS2_BASE_ADDR + 0x000F8000)
--
1.7.1
^ permalink raw reply related
* [PATCH v2 0/3] ARM i.MX53: enable some drivers on EVK board
From: yong.shen at freescale.com @ 2011-01-07 4:25 UTC (permalink / raw)
To: linux-arm-kernel
change log:
patch 1/3 was changed as per Russell's comment, using <linux/gpio.h> rather than <mach/gpio.h>
^ permalink raw reply
* Memory sharing issue by application on V4L2 based device driver with system mmu.
From: daeinki @ 2011-01-07 4:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <003201cbae19$bda3dfc0$38eb9f40$%han@samsung.com>
Hello, Mr. Jonghun.
please, note that user process's pgd and device's pgd with system mmu
are differnent. first, the memory allocated by user malloc should be
mapped to physical memory in page unit because user app also should be
accessed to own memory region. and when mapping the physical memory to
device virtual address, it creates page table entry for 64k or 1M and
then could map physical address to those entries. therefore what you
mention has no problem.
actual issue is not to need demend paging, some issues we don't
understand may exist as side effects.
thank you.
Jonghun Han ? ?:
> Hello,
>
> That's not a translation issue. What I mention is the size of allocation.
> The malloc uses 4KB page allocation and SYS.MMU can handle it.
> But 64KB or 1MB physically contiguous memory is better than 4KB page in the
> point of performance.
>
> Best regards,
>
>> -----Original Message-----
>> From: linux-media-owner at vger.kernel.org [mailto:linux-media-
>> owner at vger.kernel.org] On Behalf Of InKi Dae
>> Sent: Friday, January 07, 2011 11:17 AM
>> To: Jonghun Han
>> Cc: linux-media at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> linux-fbdev;
>> kyungmin.park at samsung.com
>> Subject: Re: Memory sharing issue by application on V4L2 based device
> driver
>> with system mmu.
>>
>> thank you for your comments.
>>
>> your second comment has no any problem as I said before, user virtual
> addess
>> could be translated in page unit. but the problem, as you said, is that
> when cpu
>> access to the memory in user mode, the memory allocated by malloc, page
> fault
>> occurs so we can't find pfn to user virtual address. I missed that. but I
> think we
>> could resolve this one.
>>
>> as before, user application allocates memory through malloc function and
> then
>> send it to device driver(using userptr feature). if the pfn is null when
> device driver
>> translated user virtual address in page unit then it allocates phsical
> memory in
>> page unit using some interface such as alloc_page() and then mapping
> them. when
>> pfn is null, to check it and allocate physical memory in page unit could
> be
>> processed by videobuf2.
>>
>> of course, videobuf2 has no any duty considered for system mmu. so
>> videobuf2 just provides callback for 3rd party and any platform with
> system mmu
>> such as Samsung SoC C210 implements the function(allocating physical
> memory
>> and mapping it) and registers it to callback of videobuf2. by doing so, I
> think your
>> first comment could be cleared.
>>
>> please, feel free to give me your opinion and pointing out.
>>
>> thank you.
>>
>> 2011? 1? 7? ?? 8:57, Jonghun Han <jonghun.han@samsung.com>?? ?:
>>> Hello,
>>>
>>> There are two reasons why malloc isn't suitable for it.
>>>
>>> The first is that malloc doesn't allocate memory when malloc is called.
>>> So driver or vb2 cannot find PFN for it in the VIDIOC_QBUF.
>>>
>>> The second is that malloc uses 4KB page allocation.
>>> SYS.MMU(IO-MMU) can handle scattered memory. But it has a penalty when
>>> TLB miss is occurred.
>>> So as possible as physically contiguous pages are needed for
>>> performance enhancement.
>>>
>>> So new allocator which can clear two main issues is needed.
>>>
>>> Best regards,
>>>
>>>> -----Original Message-----
>>>> From: linux-media-owner at vger.kernel.org [mailto:linux-media-
>>>> owner at vger.kernel.org] On Behalf Of InKi Dae
>>>> Sent: Thursday, January 06, 2011 10:25 PM
>>>> To: linux-media at vger.kernel.org
>>>> Subject: Memory sharing issue by application on V4L2 based device
>>>> driver
>>> with
>>>> system mmu.
>>>>
>>>> Hello, all.
>>>>
>>>> I'd like to discuss memory sharing issue by application on v4l2 based
>>> device driver
>>>> with system mmu and get some advices about that.
>>>>
>>>> Now I am working on Samsung SoC C210 platform and this platform has
>>>> some multimedia devices with system mmu such as fimc, and mfc also we
>>>> have implemented device drivers for them. those drivers are based on
>>>> V4L2
>>> framework
>>>> with videobuf2. for system mmu of each device, we used VCM(Virtual
>>> Contiguous
>>>> Memory) framework.
>>>>
>>>> Simply, VCM framework provides physical memory, device virtual
>>>> memory allocation and memory mapping between them. when device driver
>>>> is
>>> initialized or
>>>> operated by user application, each driver allocates physical memory
>>>> and
>>> device
>>>> virtual memory and then mapping using VCM interface.
>>>>
>>>> refer to below link for more detail.
>>>> http://www.spinics.net/lists/linux-media/msg26548.html
>>>>
>>>> Physical memory access process is as the following.
>>>> DVA PA
>>>> device --------------> system mmu ------------------> physical memory
>>>>
>>>> DVA : device virtual address.
>>>> PA : physical address.
>>>>
>>>> like this, device virtual address should be set to buffer(source or
>>>> destination) register of multimedia device.
>>>>
>>>> the problem is that application want to share own memory with any
>>>> device
>>> driver to
>>>> avoid memory copy. in other words, user-allocated memory could be
>>>> source
>>> or
>>>> destination memory of multimedia device driver.
>>>>
>>>>
>>>> let's see the diagram below.
>>>>
>>>> user application
>>>>
>>>> |
>>>> |
>>>> |
>>>> |
>>>> | 1. UVA(allocated by malloc)
>>>> |
>>>> |
>>>> ?|/ 2. UVA(in page unit)
>>>>
>>>> -----> multimedia device driver -------------------> videobuf2
>>>> |
>>>> | | ^ |
>>>> | | | |
>>>> | | -------------------------------------------
>>>> | | 3. PA(in page unit)
>>>> | |
>>>> | | 4. PA(in page unit)
>>>> 6. DVA | |
>>>> | |
>>>> | |
>>>> | ?|/
>>>> |
>>>> | Virtual Contiguous Memory ---------
>>>> | |
>>>> | | ^ |
>>>> | | | | 5. map PA to DVA
>>>> | | | |
>>>> | | | |
>>>> ------------- -------------------------
>>>>
>>>> PA : physical address.
>>>> UVA : user virtual address.
>>>> DVA : device virtual address.
>>>>
>>>> 1. user application allocates user space memory through malloc
>>>> function
>>> and
>>>> sending it to multimedia device driver based on v4l2 framework
>>>> through
>>> userptr
>>>> feature.
>>>>
>>>> 2, 3. multimedia device driver gets translated physical address from
>>>> videobuf2 framework in page unit.
>>>>
>>>> 4, 5. multimedia device driver gets allocated device virtual address
>>>> and
>>> mapping it
>>>> to physical address and then mapping them through VCM interface.
>>>>
>>>> 6. multimedia device driver sets device virtual address from VCM to
>>> buffer register.
>>>> the diagram above is fully theoretical so I wonder that this way is
>>> reasonable and
>>>> has some problems also what should be considered.
>>>>
>>>> thank you for your interesting.
>>>>
>>>> _______________________________________________
>>>> linux-arm-kernel mailing list
>>>> linux-arm-kernel at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe
>>>> linux-media" in
>>> the body
>>>> of a message to majordomo at vger.kernel.org More majordomo info at
>>>> http://vger.kernel.org/majordomo-info.html
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body
>> of a message to majordomo at vger.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* linux-next: omap2plus_defconfig not building
From: Tony Lindgren @ 2011-01-07 3:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20101223210649.GT7771@atomide.com>
* Tony Lindgren <tony@atomide.com> [101223 13:12]:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [101223 12:30]:
> >
> > It's also queued for 2.6.38, but there is an issue with the latest gcc
> > stuffing a .armv7 directive (or whatever) at the beginning of its
> > output, thereby overriding the -Wa,-march=armv7-a on the command line.
> > I think someone's looking at fixing GCC.
> >
> > This stuff _is_ in linux-next, and has been in linux-next for ages.
>
> Yes, but that's a different patch :) Sorry I should have provided a link
> for the one I'm talking about, it's the patch that changes the options
> for SWP_EMULATE to have "depends on CPU_V7 && !CPU_V6":
>
> http://marc.info/?l=linux-arm-kernel&m=128748874510144&w=2
>
> That's still needed until we have the assembly in a separate .S file,
> or have the GCC options changed.
I'll queue Catalin's patch as I need it for omap2plus_defconfig to
build. Let me if you want to take it and I'll drop it.
Regards,
Tony
^ permalink raw reply
* Memory sharing issue by application on V4L2 based device driver with system mmu.
From: Jonghun Han @ 2011-01-07 3:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinsduJkynwwEeM5K9f3D7C6jtBgkAyZ0-_0z2X-@mail.gmail.com>
Hello,
That's not a translation issue. What I mention is the size of allocation.
The malloc uses 4KB page allocation and SYS.MMU can handle it.
But 64KB or 1MB physically contiguous memory is better than 4KB page in the
point of performance.
Best regards,
> -----Original Message-----
> From: linux-media-owner at vger.kernel.org [mailto:linux-media-
> owner at vger.kernel.org] On Behalf Of InKi Dae
> Sent: Friday, January 07, 2011 11:17 AM
> To: Jonghun Han
> Cc: linux-media at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
linux-fbdev;
> kyungmin.park at samsung.com
> Subject: Re: Memory sharing issue by application on V4L2 based device
driver
> with system mmu.
>
> thank you for your comments.
>
> your second comment has no any problem as I said before, user virtual
addess
> could be translated in page unit. but the problem, as you said, is that
when cpu
> access to the memory in user mode, the memory allocated by malloc, page
fault
> occurs so we can't find pfn to user virtual address. I missed that. but I
think we
> could resolve this one.
>
> as before, user application allocates memory through malloc function and
then
> send it to device driver(using userptr feature). if the pfn is null when
device driver
> translated user virtual address in page unit then it allocates phsical
memory in
> page unit using some interface such as alloc_page() and then mapping
them. when
> pfn is null, to check it and allocate physical memory in page unit could
be
> processed by videobuf2.
>
> of course, videobuf2 has no any duty considered for system mmu. so
> videobuf2 just provides callback for 3rd party and any platform with
system mmu
> such as Samsung SoC C210 implements the function(allocating physical
memory
> and mapping it) and registers it to callback of videobuf2. by doing so, I
think your
> first comment could be cleared.
>
> please, feel free to give me your opinion and pointing out.
>
> thank you.
>
> 2011? 1? 7? ?? 8:57, Jonghun Han <jonghun.han@samsung.com>?? ?:
> >
> > Hello,
> >
> > There are two reasons why malloc isn't suitable for it.
> >
> > The first is that malloc doesn't allocate memory when malloc is called.
> > So driver or vb2 cannot find PFN for it in the VIDIOC_QBUF.
> >
> > The second is that malloc uses 4KB page allocation.
> > SYS.MMU(IO-MMU) can handle scattered memory. But it has a penalty when
> > TLB miss is occurred.
> > So as possible as physically contiguous pages are needed for
> > performance enhancement.
> >
> > So new allocator which can clear two main issues is needed.
> >
> > Best regards,
> >
> >> -----Original Message-----
> >> From: linux-media-owner at vger.kernel.org [mailto:linux-media-
> >> owner at vger.kernel.org] On Behalf Of InKi Dae
> >> Sent: Thursday, January 06, 2011 10:25 PM
> >> To: linux-media at vger.kernel.org
> >> Subject: Memory sharing issue by application on V4L2 based device
> >> driver
> > with
> >> system mmu.
> >>
> >> Hello, all.
> >>
> >> I'd like to discuss memory sharing issue by application on v4l2 based
> > device driver
> >> with system mmu and get some advices about that.
> >>
> >> Now I am working on Samsung SoC C210 platform and this platform has
> >> some multimedia devices with system mmu such as fimc, and mfc also we
> >> have implemented device drivers for them. those drivers are based on
> >> V4L2
> > framework
> >> with videobuf2. for system mmu of each device, we used VCM(Virtual
> > Contiguous
> >> Memory) framework.
> >>
> >> Simply, VCM framework provides physical memory, device virtual
> >> memory allocation and memory mapping between them. when device driver
> >> is
> > initialized or
> >> operated by user application, each driver allocates physical memory
> >> and
> > device
> >> virtual memory and then mapping using VCM interface.
> >>
> >> refer to below link for more detail.
> >> http://www.spinics.net/lists/linux-media/msg26548.html
> >>
> >> Physical memory access process is as the following.
> >> DVA PA
> >> device --------------> system mmu ------------------> physical memory
> >>
> >> DVA : device virtual address.
> >> PA : physical address.
> >>
> >> like this, device virtual address should be set to buffer(source or
> >> destination) register of multimedia device.
> >>
> >> the problem is that application want to share own memory with any
> >> device
> > driver to
> >> avoid memory copy. in other words, user-allocated memory could be
> >> source
> > or
> >> destination memory of multimedia device driver.
> >>
> >>
> >> let's see the diagram below.
> >>
> >> user application
> >>
> >> |
> >> |
> >> |
> >> |
> >> | 1. UVA(allocated by malloc)
> >> |
> >> |
> >> ?|/ 2. UVA(in page unit)
> >>
> >> -----> multimedia device driver -------------------> videobuf2
> >> |
> >> | | ^ |
> >> | | | |
> >> | | -------------------------------------------
> >> | | 3. PA(in page unit)
> >> | |
> >> | | 4. PA(in page unit)
> >> 6. DVA | |
> >> | |
> >> | |
> >> | ?|/
> >> |
> >> | Virtual Contiguous Memory ---------
> >> | |
> >> | | ^ |
> >> | | | | 5. map PA to DVA
> >> | | | |
> >> | | | |
> >> ------------- -------------------------
> >>
> >> PA : physical address.
> >> UVA : user virtual address.
> >> DVA : device virtual address.
> >>
> >> 1. user application allocates user space memory through malloc
> >> function
> > and
> >> sending it to multimedia device driver based on v4l2 framework
> >> through
> > userptr
> >> feature.
> >>
> >> 2, 3. multimedia device driver gets translated physical address from
> >> videobuf2 framework in page unit.
> >>
> >> 4, 5. multimedia device driver gets allocated device virtual address
> >> and
> > mapping it
> >> to physical address and then mapping them through VCM interface.
> >>
> >> 6. multimedia device driver sets device virtual address from VCM to
> > buffer register.
> >>
> >> the diagram above is fully theoretical so I wonder that this way is
> > reasonable and
> >> has some problems also what should be considered.
> >>
> >> thank you for your interesting.
> >>
> >> _______________________________________________
> >> linux-arm-kernel mailing list
> >> linux-arm-kernel at lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe
> >> linux-media" in
> > the body
> >> of a message to majordomo at vger.kernel.org More majordomo info at
> >> http://vger.kernel.org/majordomo-info.html
> >
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body
> of a message to majordomo at vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [GIT PULL] omap changes for v2.6.38
From: Tony Lindgren @ 2011-01-07 2:50 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
Please pull omap changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-for-linus
The interesting changes for this merge window are:
- Start using common code for omap hardware modules (hwmod) for resetting,
enabling, and idling the hardare modules. This allows us to do fine
grained power management using runtime PM in a way where the drivers
stay generic.
- Power management updates to get closer to have DVFS working
- Combine all omap1 defconfigs into one omap1_defconfig
- Various omap4 updates, pin multiplexing updates, clean-up and
board updates
There's a trivial merge conflict in arch/arm/plat-omap/Kconfig
that git mergetool handles automatically.
Regards,
Tony
The following changes since commit 3c0cb7c31c206aaedb967e44b98442bbeb17a6c4:
Merge branch 'devel' of master.kernel.org:/home/rmk/linux-2.6-arm (2011-01-06 16:50:35 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-for-linus
Aaro Koskinen (19):
arm: omap1: add missing includes
arm: omap1: make some functions static
arm: omap1: mbox: make variables static
arm: omap1: mbox: delete unused variable
arm: omap1: board-ams-delta: fix cast
arm: omap2: timer-gp: delete unused variable
arm: mach-omap2: remove NULL board_mux from board files
arm: mach-omap2: n8x0: clean up dummy onenand init
arm: mach-omap2: rx51: clean up dummy onenand init
arm: omap: rename board-rx51-sdram.c to sdram-nokia.c
arm: omap: add sdram-nokia.h
arm: omap: sdram-nokia: prepare for new memory timings
arm: omap: sdram-nokia: use array to list timings
arm: omap: sdram-nokia: improve error handling
arm: omap: sdram-nokia: delete redundant timing data
arm: omap: sdram-nokia: add 97.6/195.2 MHz timing data
arm: omap: add minimal support for RM-680
arm: mach-omap2: hsmmc_reset: fix clk_get() error handling
arm: mach-omap2: Kconfig: fix incorrect option
Adrian Hunter (2):
OMAP2/3: GPMC: put sync_clk value in picoseconds instead of nanoseconds
OMAP2/3: OneNAND: add 104MHz support
Anand Gadiyar (2):
omap: remove dead wdt code in plat-omap/devices.c
omap2430: hwmod: remove stray declaration
Andrei Emeltchenko (2):
OMAP: Serial: Define OMAP uart MDR1 reg and remove magic numbers
omap: Serial: Define register access modes in LCR
Arno Steffen (1):
OMAP3: fix typo in OMAP3_IVA_MASK
Ben Gamari (1):
omap2: Make OMAP2PLUS select OMAP_DM_TIMER
Benoit Cousson (30):
OMAP4: hwmod: add I2C hwmods for OMAP4430
OMAP: mux: Replace printk with pr_xxx macros
OMAP: mux: Add support for control module split in several partitions
OMAP4: mux: Add CBL package data for OMAP4430 ES1
OMAP4: sdp4430: Select CBL package for ES1 and initialize mux
OMAP4: mux: Add CBS package data for OMAP4430 ES2
OMAP4: sdp4430: Select CBS package for ES2
OMAP4: hwmod data: Add GPIO
omap: serial: Change device name: omap-hsuart -> omap_uart
I2C: i2c-omap: Change device name: i2c_omap -> omap_i2c
OMAP4: hwmod data: add system DMA
OMAP4: PRCM: Add SCRM header file
OMAP4: clock data: Add control for pad_clks_ck and slimbus_clk
OMAP3: clock data: Add "wkup_clkdm" in sr1_fck and sr2_fck
OMAP4: hwmod data: Fix hwmod entries order
OMAP4: hwmod data: Add SYSS_HAS_RESET_STATUS flag
OMAP4: hwmod data: Fix missing address in DMM and EMIF_FW
OMAP4: hwmod data: Add IVA and DSP
OMAP4: hwmod & clock data: Fix GPIO opt_clks and ocp_if iclk
OMAP2430: hwmod data: Use common dev_attr for i2c1 and i2c2
OMAP2+: hwmod: Make omap_hwmod_register private and remove omap_hwmod_unregister
OMAP2+: hwmod: Mark functions used only during initialization with __init
OMAP2+: hwmod: Remove omap_hwmod_mutex
OMAP2+: hwmod: Add wakeup support for new OMAP4 IPs
OMAP4: hwmod data: Add SIDLE_SMART_WKUP modes to several IPs
OMAP4: hwmod: Add inital data for smartreflex modules.
OMAP4: hwmod data: Fix missing SIDLE_SMART_WKUP in smartreflexsysc
OMAP4: hwmod data: Move the smartreflex structures
OMAP4: hwmod data: Move the DMA structures
OMAP4: hwmod data: Fix alignment and end of line in structurefields
Bryan Wu (1):
omap: kill all section mismatch warning for omap2plus_defconfig
Charulatha V (1):
OMAP3: clock: Update clock domain name for mcspi fck
Dan Murphy (1):
OMAP: mux: Add __func__ macro to pr_xxx macros
Daniel Morsing (1):
OMAP2: Devkit8000: Use _cansleep GPIO functions for displayreset lines
Eduardo Valentin (1):
OMAP3630: PM: Erratum i583: disable coreoff if < ES1.2
Enric Balletbo i Serra (3):
omap3: IGEP v2: Remove onenand_setup no-op function
omap3: IGEP v2: Remove igep2_config array
omap3: IGEP v2: Improve igep2_flash_init() function
Evgeny Kuznetsov (1):
omap: Ptr "isr_reg" tracked as NULL was dereferenced
Felipe Balbi (3):
arm: omap: combine zoom2 and zoom3 board-files
arm: omap: zoom: substitute gpio number with symbolic name
arm: omap: tusb6010: add name for MUSB IRQ
Felipe Contreras (1):
OMAP: iommu: make iva2 iommu selectable
Fernando Guzman Lugo (1):
OMAP: mailbox: change full flag per mailbox queue instead of global
G, Manjunath Kondaiah (8):
OMAP: DMA: Replace read/write macros with functions
OMAP: DMA: Introduce errata handling feature
OMAP2420: hwmod data: add system DMA
OMAP2430: hwmod data: add system DMA
OMAP3: hwmod data: add system DMA
OMAP1: DMA: Implement in platform device model
OMAP2+: DMA: hwmod: Device registration
OMAP: DMA: Convert DMA library into platform driver
Grazvydas Ignotas (1):
omap: pandora: fix wifi support
Guzman Lugo, Fernando (4):
OMAP: iovmm: no gap checking for fixed address
OMAP: iovmm: add superpages support to fixed da address
OMAP: iovmm: replace __iounmap with iounmap
OMAP: iommu: create new api to set valid da range
Hari Kanigeri (1):
OMAP4: clocks: add dummy clock for mailbox
Hemanth V (2):
omap4: Add platform changes for Ambient Light sensor
omap4: Add platform changes for PWM LED
Janusz Krzysztofik (3):
OMAP1: drop AMS_DELTA_FIQ config option
OMAP1: clock_data: use runtime cpu / machine checks
Keyboard: omap-keypad: use matrix_keypad.h
Jarkko Nikula (7):
omap: McBSP: Fix potential memory leak in omap_mcbsp_remove
omap: rx51: Remove extra tlv320aic3x.h inclusion
omap: rx51: Add supplies and data for codec b part ofTLV320AIC34
omap: rx51: Switch rx51_tpa6130a2_data __initdata to__initdata_or_module
omap: rx51: Cleanup vdds_sdi supply construction
omap: rx51: Add vdda_dac supply for tvout
omap: rx51: Remove tvout code that plays with gpio 40
Jean Pihet (9):
OMAP3: add comments for erratas i540 and i478 workarounds
OMAP2+: disable idle early in the suspend sequence
OMAP3: remove unused code from the ASM sleep code
OMAP2+: use global values for the SRAM PA addresses
OMAP3: remove hardcoded values from the ASM sleep code
OMAP3: re-organize the ASM sleep code
OMAP3: rework of the ASM sleep code execution paths
OMAP3: add comments for low power code errata
OMAP3: ASM sleep code format rework
John Rigby (1):
OMAP4: enable smc instruction in new assembler versions
Jon Hunter (2):
OMAP: clock: fix configuration of J-Type DPLLs to work for OMAP3 and OMAP4
OMAP4: clock data: Add missing fixed divisors
Jonathan Bergsagel (1):
OMAP4: clock data: Add missing fields in iva_hsd_byp_clk_mux_ck
Kanigeri, Hari (3):
OMAP: mailbox: fix checkpatch warnings
OMAP: mailbox: send message in process context
OMAP: mailbox: add notification support for multiple readers
Kevin Hilman (6):
OMAP3: remove OPP interfaces from OMAP PM layer
OMAP2+: omap_hwmod: fix wakeup enable/disable for consistency
OMAP2+: powerdomain: add API to get context loss count
OMAP: PM: implement context loss count APIs
OMAP: PM noop: implement context loss count for non-omap_devices
OMAP2: PM: fix compile error when !CONFIG_SUSPEND
Laurent Pinchart (2):
omap3: igepv2: Don't call gpio_set_value right aftergpio_direction_output
omap3: igepv2: LED gpio-led:green:d1 is active low
Mans Rullgard (1):
omap4: l2x0: enable instruction and data prefetching
Marc Zyngier (1):
Fix IGEPv2 second MMC channel power supply
Marek Belisko (2):
omap1: htc_herald: Fix compilation warning
omap1: pm_bus: Fix compilation warning
Nishanth Menon (5):
omap: opp: add OMAP3 OPP table data and common init
omap4: opp: add OPP table data
OMAP3: pm: introduce errata handling
OMAP3630: PM: Erratum i608: disable RTA
OMAP3: PM: make omap3_cpuidle_update_states independent of enable_off_mode
Ohad Ben-Cohen (1):
omap: boards w/ wl12xx should select REGULATOR_FIXED_VOLTAGE
Omar Ramirez Luna (2):
OMAP: mailbox: remove unreachable return
OMAP: mailbox: fix detection for previously supported chips
Paul Walmsley (35):
OMAP2xxx: hwmod: add I2C hwmods for OMAP2420, 2430
OMAP: I2C: split device registration and convert OMAP2+ to omap_device
OMAP1: I2C: fix device initialization
OMAP2+: io: split omap2_init_common_hw()
OMAP2+: hwmod: allow custom pre-shutdown functions
OMAP2+: hwmod: add postsetup state
OMAP2+: hwmod: add support for per-class custom device reset functions
OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock
OMAP2+: hwmod: fix a warning, add some docs, remove unused fields
OMAP2+: wd_timer: separate watchdog disable code from the rest of mach-omap2/devices.c
OMAP2+: wd_timer: disable on boot via hwmod postsetup mechanism
OMAP2+: powerdomains: move powerdomain static data to .c files
OMAP2+: clockdomains: move clockdomain static data to .c files
OMAP3: control/PRCM: add omap3_ctrl_write_boot_mode()
OMAP3: control/PRCM: move CONTROL_PADCONF_SYS_NIRQ save/restore to SCM code
OMAP4: PRCM: reorganize existing OMAP4 PRCM header files
OMAP4: PRCM: rename _MOD macros to _INST
OMAP2/3: PRCM: split OMAP2/3-specific PRCM code into OMAP2/3-specific files
OMAP3: PRM/CM: separate CM context save/restore; remove PRM context save/restore
OMAP4: PRCM: add OMAP4-specific accessor/mutator functions
OMAP4: PRCM: move global reset function for OMAP4 to an OMAP4-specific file
OMAP2/3: PRM/CM: prefix OMAP2 PRM/CM functions with "omap2_"
OMAP4: powerdomains: add PRCM partition data; use OMAP4 PRM functions
OMAP2+: clockdomains: split the clkdm hwsup enable/disable function
OMAP4: CM instances: add clockdomain register offsets
OMAP4: clockdomains: add OMAP4 PRCM data and OMAP4 support
OMAP2/3: clockdomain: remove unneeded .clkstctrl_reg, remove some direct CM register accesses
OMAP2+: clockdomain: move header file from plat-omap to mach-omap2
OMAP2+: powerdomain: move header file from plat-omap to mach-omap2
OMAP3: control/PM: move padconf save code to mach-omap2/control.c
OMAP2xxx clock: fix dss2_fck recalc to use clksel
OMAP3: clock: clarify usage of struct clksel_rate.flags and struct omap_clk.cpu
OMAP3: clock: fix incorrect rate display when switching MPU rate@boot
OMAP2/3: SRAM: add comment about crashes during a TLB miss
MAINTAINERS: OMAP: hwmod: update hwmod code, data maintainership
Peter 'p2' De Schrijver (2):
OMAP3: PM: Erratum i581 support: dll kick strategy
OMAP3630: PM: Disable L2 cache while invalidating L2 cache
Raghuveer Murthy (2):
OMAP4: Pandaboard: Add omap_reserve functionality
OMAP4: Pandaboard: Fix MMC card detect gpio line
Rajendra Nayak (14):
OMAP3: hwmod: add I2C hwmods for OMAP3430
OMAP: I2C: Convert i2c driver to use PM runtime api's
OMAP2+: hwmod: Update the sysc_cache in case module context is lost
OMAP: powerdomain: Move static allocations from powerdomains.h to a .c file
OMAP: powerdomain: Infrastructure to put arch specific code
OMAP: powerdomain: Arch specific funcs for state control
OMAP: powerdomain: Arch specific funcs for logic control
OMAP: powerdomain: Arch specific funcs for mem control
OMAP4: clock data: Add SCRM auxiliary clock nodes
OMAP4: clock data: Export control to enable/disable CORE/PER M3 clocks
OMAP2+: hwmod: Disable clocks when hwmod enable fails
OMAP4: PM: Use the low-power state change feature on OMAP4
OMAP4: PM: Do not assume clkdm supports hw transitions
OMAP4: powerdomain: l4per pwrdm does not support OFF
Richard Woodruff (1):
OMAP3: PM: Update clean_l2 to use v7_flush_dcache_all
Santosh Shilimkar (7):
ARM: l2x0: Add aux control register bitfields
omap4: l2x0: Construct the AUXCTRL value using defines
omap4: l2x0: Set share override bit
omap4: l2x0: Enable early BRESP bit
OMAP4: powerdomain: Add pwrdm_clear_all_prev_pwrst
OMAP4: powerdomain: Remove L3INIT_PD OFF state
OMAP4: clock data: Keep L3INSTR clock domain modulemode under HW control
Shubhrajyoti D (1):
omap: McBSP: Make the free variable update more readable
Srikar (1):
Added video data to support tvout on rx51
Srinath (2):
omap: AM3517/05: Add craneboard support
arm: omap: craneboard: Add USB EHCI support
Thara Gopinath (15):
OMAP: pm.c correct the initcall for an early init.
OMAP4: clock data: Add missing DPLL x2 clock nodes
OMAP3: PM: Adding voltage driver support.
OMAP: Introduce voltage domain information in the hwmod structures
OMAP3: PM: Adding smartreflex driver support.
OMAP3: PM: Adding smartreflex device file.
OMAP3: PM: Adding smartreflex hwmod data
OMAP3: PM: Adding smartreflex class3 driver
OMAP3: PM: Register TWL4030 pmic info with the voltage driver.
OMAP3: PM: Adding debug support to Voltage and Smartreflex drivers
OMAP3: PM: Program correct init voltages for VDD1 and VDD2
OMAP4: Register voltage PMIC parameters with the voltage layer
OMAP4: Adding voltage driver support
OMAP4: PM: Program correct init voltages for scalable VDDs
OMAP4: Smartreflex framework extensions
Thomas Weber (1):
OMAP3: Devkit8000: Add DEBUG_LL support
Tony Lindgren (33):
Merge branches 'devel-cleanup', 'devel-serial' and 'devel-board' into omap-for-linus
Merge branch 'pm-hwmod-i2c' of ssh://master.kernel.org/.../khilman/linux-omap-pm into omap-for-linus
Merge branch 'ctrl-wip/mux-omap4-v4' of git://gitorious.org/omap-pm/linux into omap-for-linus
omap: Fix undefined reference to omap2_i2c_mux_pins
omap: Don't select mux by default for each board
omap: Fix gpio_request calls to happen as arch_initcall
OMAP: GPIO: Make omap_gpio_show_rev bank specific
omap1: Fix gpio mpuio bank to work for multi-omap for 7xx/15xx/16xx
Merge branch 'devel-cleanup' into omap-for-linus
omap1: Use asm_irq_flags for entry-macro.S
omap2+: Initialize omap_irq_base for entry-macro.S from platform code
Merge branch 'devel-omap-irq' into omap-for-linus
omap: Split omap_read/write functions for omap1 and omap2+
omap1: Add initcall checks for omap1 and booted board
omap1: Add omap1_defconfig
omap1: Delete old defconfigs
Merge branch 'devel-gpio' into omap-for-linus
omap: Fix setting omap_irq_base for 2430
Merge branch 'devel-board' into omap-for-linus
Merge branch 'for_2.6.38' of git://gitorious.org/iommu_mailbox/iommu_mailbox into devel-iommu-mailbox
omap1: Fix innovator FPGA init for multi-omap
Merge branches 'devel-iommu-mailbox' and 'devel-l2x0' into omap-for-linus
Merge branch 'devel-dma' into omap-for-linus
Merge branch 'pm-next' of ssh://master.kernel.org/.../khilman/linux-omap-pm into omap-for-linus
Merge branch 'pm-opp' of ssh://master.kernel.org/.../khilman/linux-omap-pm into omap-for-linus
Merge branches 'devel-gpmc' and 'devel-misc' into omap-for-linus
Merge branch 'integration-2.6.38-for-tony' of git://git.pwsan.com/linux-2.6 into omap-for-linus
Merge branch 'pm-sr' of ssh://master.kernel.org/.../khilman/linux-omap-pm into omap-for-linus
omap2+: Add omap_mux_get_by_name
omap2+: Add support for hwmod specific muxing of devices
omap2+: Allow hwmod state changes to mux pads based on the state changes
omap2+: Add struct omap_board_data and use it for platform level serial init
omap2+: Initialize serial port for dynamic remuxing for n8x0
Varadarajan, Charulatha (9):
OMAP: GPIO: prepare for platform driver
OMAP15xx: GPIO: Introduce support for GPIO init
OMAP16xx: GPIO: Introduce support for GPIO init
OMAP7xx: GPIO: Introduce support for GPIO init
OMAP2420: hwmod data: Add GPIO
OMAP2430: hwmod data: Add GPIO
OMAP3: hwmod data: Add GPIO
OMAP2+: GPIO: device registration
OMAP: GPIO: Implement GPIO as a platform device
Vishwanath BS (1):
OMAP3: SDRC: Add comments on Errata i520 for Global SW reset
sricharan (1):
OMAP4: pandaboard: Select CBL & CBS package and initialize mux
Documentation/arm/OMAP/omap_pm | 25 +
MAINTAINERS | 14 +
arch/arm/configs/ams_delta_defconfig | 121 --
arch/arm/configs/htcherald_defconfig | 73 -
arch/arm/configs/n770_defconfig | 138 --
arch/arm/configs/omap1_defconfig | 286 ++++
arch/arm/configs/omap_generic_1510_defconfig | 84 -
arch/arm/configs/omap_generic_1610_defconfig | 87 -
arch/arm/configs/omap_generic_1710_defconfig | 75 -
arch/arm/configs/omap_h2_1610_defconfig | 109 --
arch/arm/configs/omap_innovator_1510_defconfig | 102 --
arch/arm/configs/omap_innovator_1610_defconfig | 58 -
arch/arm/configs/omap_osk_5912_defconfig | 87 -
arch/arm/configs/omap_perseus2_730_defconfig | 65 -
arch/arm/configs/palmte_defconfig | 48 -
arch/arm/configs/palmtt_defconfig | 56 -
arch/arm/configs/palmz71_defconfig | 53 -
arch/arm/configs/sx1_defconfig | 110 --
arch/arm/include/asm/hardware/cache-l2x0.h | 12 +-
arch/arm/include/asm/io.h | 13 +-
arch/arm/mach-davinci/include/mach/io.h | 4 +-
arch/arm/mach-iop13xx/include/mach/io.h | 4 +-
arch/arm/mach-iop32x/include/mach/io.h | 4 +-
arch/arm/mach-iop33x/include/mach/io.h | 4 +-
arch/arm/mach-ixp23xx/include/mach/io.h | 4 +-
arch/arm/mach-ixp4xx/include/mach/io.h | 4 +-
arch/arm/mach-kirkwood/include/mach/io.h | 4 +-
arch/arm/mach-omap1/Kconfig | 11 +-
arch/arm/mach-omap1/Makefile | 12 +-
arch/arm/mach-omap1/board-ams-delta.c | 137 +-
arch/arm/mach-omap1/board-fsample.c | 89 +-
arch/arm/mach-omap1/board-h2.c | 79 +-
arch/arm/mach-omap1/board-h3.c | 97 +-
arch/arm/mach-omap1/board-htcherald.c | 102 +-
arch/arm/mach-omap1/board-innovator.c | 32 +-
arch/arm/mach-omap1/board-nokia770.c | 30 +-
arch/arm/mach-omap1/board-osk.c | 27 +-
arch/arm/mach-omap1/board-palmte.c | 29 +-
arch/arm/mach-omap1/board-palmtt.c | 28 +-
arch/arm/mach-omap1/board-palmz71.c | 31 +-
arch/arm/mach-omap1/board-perseus2.c | 91 +-
arch/arm/mach-omap1/board-sx1.c | 58 +-
arch/arm/mach-omap1/board-voiceblue.c | 7 +-
arch/arm/mach-omap1/clock_data.c | 27 +-
arch/arm/mach-omap1/devices.c | 4 +
arch/arm/mach-omap1/dma.c | 390 +++++
arch/arm/mach-omap1/flash.c | 1 +
arch/arm/mach-omap1/fpga.c | 10 +-
arch/arm/mach-omap1/gpio15xx.c | 99 ++
arch/arm/mach-omap1/gpio16xx.c | 200 +++
arch/arm/mach-omap1/gpio7xx.c | 262 ++++
arch/arm/mach-omap1/include/mach/entry-macro.S | 27 +-
arch/arm/mach-omap1/io.c | 39 +
arch/arm/mach-omap1/irq.c | 5 +
arch/arm/mach-omap1/lcd_dma.c | 3 +
arch/arm/mach-omap1/leds.c | 3 +
arch/arm/mach-omap1/mailbox.c | 5 +-
arch/arm/mach-omap1/mcbsp.c | 5 +-
arch/arm/mach-omap1/mux.c | 2 +-
arch/arm/mach-omap1/pm.c | 3 +
arch/arm/mach-omap1/pm_bus.c | 4 +-
arch/arm/mach-omap1/serial.c | 11 +-
arch/arm/mach-omap1/time.c | 1 +
arch/arm/mach-omap2/Kconfig | 34 +-
arch/arm/mach-omap2/Makefile | 83 +-
arch/arm/mach-omap2/board-2430sdp.c | 8 +-
arch/arm/mach-omap2/board-3430sdp.c | 6 +-
arch/arm/mach-omap2/board-3630sdp.c | 8 +-
arch/arm/mach-omap2/board-4430sdp.c | 45 +-
arch/arm/mach-omap2/board-am3517crane.c | 116 ++
arch/arm/mach-omap2/board-am3517evm.c | 7 +-
arch/arm/mach-omap2/board-apollon.c | 10 +-
arch/arm/mach-omap2/board-cm-t35.c | 15 +-
arch/arm/mach-omap2/board-cm-t3517.c | 4 +-
arch/arm/mach-omap2/board-devkit8000.c | 14 +-
arch/arm/mach-omap2/board-generic.c | 3 +-
arch/arm/mach-omap2/board-h4.c | 71 +-
arch/arm/mach-omap2/board-igep0020.c | 124 +-
arch/arm/mach-omap2/board-igep0030.c | 7 +-
arch/arm/mach-omap2/board-ldp.c | 8 +-
arch/arm/mach-omap2/board-n8x0.c | 70 +-
arch/arm/mach-omap2/board-omap3beagle.c | 8 +-
arch/arm/mach-omap2/board-omap3evm.c | 6 +-
arch/arm/mach-omap2/board-omap3logic.c | 6 +-
arch/arm/mach-omap2/board-omap3pandora.c | 10 +-
arch/arm/mach-omap2/board-omap3stalker.c | 6 +-
arch/arm/mach-omap2/board-omap3touchbook.c | 8 +-
arch/arm/mach-omap2/board-omap4panda.c | 22 +-
arch/arm/mach-omap2/board-overo.c | 8 +-
arch/arm/mach-omap2/board-rm680.c | 187 +++
arch/arm/mach-omap2/board-rx51-peripherals.c | 77 +-
arch/arm/mach-omap2/board-rx51-video.c | 9 +-
arch/arm/mach-omap2/board-rx51.c | 10 +-
arch/arm/mach-omap2/board-zoom-peripherals.c | 2 +-
.../arm/mach-omap2/{board-zoom3.c => board-zoom.c} | 102 +-
arch/arm/mach-omap2/board-zoom2.c | 117 --
arch/arm/mach-omap2/clkt2xxx_apll.c | 12 +-
arch/arm/mach-omap2/clkt2xxx_dpllcore.c | 10 +-
arch/arm/mach-omap2/clkt2xxx_osc.c | 2 +-
arch/arm/mach-omap2/clkt2xxx_sys.c | 2 +-
arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 14 +-
arch/arm/mach-omap2/clkt_dpll.c | 1 -
arch/arm/mach-omap2/clock.c | 6 +-
arch/arm/mach-omap2/clock.h | 1 -
arch/arm/mach-omap2/clock2420_data.c | 14 +-
arch/arm/mach-omap2/clock2430.c | 2 +-
arch/arm/mach-omap2/clock2430_data.c | 14 +-
arch/arm/mach-omap2/clock34xx.c | 2 +-
arch/arm/mach-omap2/clock3517.c | 2 +-
arch/arm/mach-omap2/clock3xxx.c | 6 +-
arch/arm/mach-omap2/clock3xxx_data.c | 230 ++--
arch/arm/mach-omap2/clock44xx_data.c | 690 ++++++---
arch/arm/mach-omap2/clockdomain.c | 220 ++--
.../include/plat => mach-omap2}/clockdomain.h | 40 +-
...clockdomains.h => clockdomains2xxx_3xxx_data.c} | 109 +--
...{clockdomains44xx.h => clockdomains44xx_data.c} | 169 ++-
arch/arm/mach-omap2/cm-regbits-24xx.h | 11 +-
arch/arm/mach-omap2/cm-regbits-34xx.h | 13 +-
arch/arm/mach-omap2/cm-regbits-44xx.h | 3 -
arch/arm/mach-omap2/cm.c | 68 -
arch/arm/mach-omap2/cm.h | 137 +--
arch/arm/mach-omap2/cm1_44xx.h | 261 ++++
arch/arm/mach-omap2/cm2_44xx.h | 508 ++++++
arch/arm/mach-omap2/cm2xxx_3xxx.c | 471 ++++++
arch/arm/mach-omap2/cm2xxx_3xxx.h | 147 ++
arch/arm/mach-omap2/cm44xx.c | 52 +
arch/arm/mach-omap2/cm44xx.h | 668 +--------
arch/arm/mach-omap2/cm4xxx.c | 62 -
arch/arm/mach-omap2/cminst44xx.c | 214 +++
arch/arm/mach-omap2/cminst44xx.h | 31 +
arch/arm/mach-omap2/control.c | 133 ++-
arch/arm/mach-omap2/control.h | 42 +-
arch/arm/mach-omap2/cpuidle34xx.c | 40 +-
arch/arm/mach-omap2/devices.c | 108 +-
arch/arm/mach-omap2/dma.c | 297 ++++
arch/arm/mach-omap2/dpll3xxx.c | 57 +-
arch/arm/mach-omap2/dsp.c | 23 +-
arch/arm/mach-omap2/gpio.c | 104 ++
arch/arm/mach-omap2/gpmc-nand.c | 2 +-
arch/arm/mach-omap2/gpmc-onenand.c | 19 +-
arch/arm/mach-omap2/gpmc.c | 12 +-
arch/arm/mach-omap2/include/mach/entry-macro.S | 44 +-
arch/arm/mach-omap2/io.c | 141 ++-
arch/arm/mach-omap2/irq.c | 5 +-
arch/arm/mach-omap2/mailbox.c | 19 +-
arch/arm/mach-omap2/mux.c | 525 +++++--
arch/arm/mach-omap2/mux.h | 154 ++-
arch/arm/mach-omap2/mux2420.c | 10 +-
arch/arm/mach-omap2/mux2430.c | 10 +-
arch/arm/mach-omap2/mux34xx.c | 9 +-
arch/arm/mach-omap2/mux44xx.c | 1625 +++++++++++++++++++
arch/arm/mach-omap2/mux44xx.h | 298 ++++
arch/arm/mach-omap2/omap-iommu.c | 10 +-
arch/arm/mach-omap2/omap4-common.c | 30 +-
arch/arm/mach-omap2/omap_hwmod.c | 483 ++++---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 465 ++++++-
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 519 ++++++-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 870 +++++++++++-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 1644 +++++++++++++++++---
arch/arm/mach-omap2/omap_opp_data.h | 72 +
arch/arm/mach-omap2/omap_twl.c | 277 ++++
arch/arm/mach-omap2/opp.c | 93 ++
arch/arm/mach-omap2/opp3xxx_data.c | 107 ++
arch/arm/mach-omap2/opp4xxx_data.c | 57 +
arch/arm/mach-omap2/pm-debug.c | 21 +-
arch/arm/mach-omap2/pm.c | 144 ++-
arch/arm/mach-omap2/pm.h | 59 +-
arch/arm/mach-omap2/pm24xx.c | 224 ++--
arch/arm/mach-omap2/pm34xx.c | 236 ++--
arch/arm/mach-omap2/pm44xx.c | 18 +-
arch/arm/mach-omap2/powerdomain-common.c | 110 ++
arch/arm/mach-omap2/powerdomain.c | 441 ++----
arch/arm/mach-omap2/powerdomain.h | 233 +++
arch/arm/mach-omap2/powerdomain2xxx_3xxx.c | 242 +++
arch/arm/mach-omap2/powerdomain44xx.c | 225 +++
arch/arm/mach-omap2/powerdomains.h | 153 --
arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c | 79 +
arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.h | 22 +
...{powerdomains24xx.h => powerdomains2xxx_data.c} | 48 +-
...{powerdomains34xx.h => powerdomains3xxx_data.c} | 56 +-
...{powerdomains44xx.h => powerdomains44xx_data.c} | 92 +-
arch/arm/mach-omap2/prcm-common.h | 85 +-
arch/arm/mach-omap2/prcm.c | 556 +------
arch/arm/mach-omap2/prcm44xx.h | 42 +
arch/arm/mach-omap2/prcm_mpu44xx.c | 45 +
arch/arm/mach-omap2/prcm_mpu44xx.h | 104 ++
arch/arm/mach-omap2/prm-regbits-24xx.h | 2 +-
arch/arm/mach-omap2/prm-regbits-34xx.h | 11 +-
arch/arm/mach-omap2/prm-regbits-44xx.h | 2 -
arch/arm/mach-omap2/prm.h | 369 +-----
arch/arm/mach-omap2/prm2xxx_3xxx.c | 64 +-
arch/arm/mach-omap2/prm2xxx_3xxx.h | 367 +++++
arch/arm/mach-omap2/prm44xx.c | 81 +-
arch/arm/mach-omap2/prm44xx.h | 766 +++++-----
arch/arm/mach-omap2/prminst44xx.c | 66 +
arch/arm/mach-omap2/prminst44xx.h | 25 +
arch/arm/mach-omap2/scrm44xx.h | 175 +++
.../{board-rx51-sdram.c => sdram-nokia.c} | 102 +-
arch/arm/mach-omap2/sdram-nokia.h | 12 +
arch/arm/mach-omap2/sdrc.c | 2 -
arch/arm/mach-omap2/sdrc.h | 1 -
arch/arm/mach-omap2/sdrc2xxx.c | 6 +-
arch/arm/mach-omap2/serial.c | 69 +-
arch/arm/mach-omap2/sleep34xx.S | 836 ++++++-----
arch/arm/mach-omap2/smartreflex-class3.c | 59 +
arch/arm/mach-omap2/smartreflex.c | 1029 ++++++++++++
arch/arm/mach-omap2/sr_device.c | 146 ++
arch/arm/mach-omap2/sram242x.S | 10 +-
arch/arm/mach-omap2/sram243x.S | 10 +-
arch/arm/mach-omap2/sram34xx.S | 8 +-
arch/arm/mach-omap2/timer-gp.c | 3 +-
arch/arm/mach-omap2/usb-tusb6010.c | 5 +-
arch/arm/mach-omap2/voltage.c | 1571 +++++++++++++++++++
arch/arm/mach-omap2/wd_timer.c | 54 +
arch/arm/mach-omap2/wd_timer.h | 17 +
arch/arm/mach-orion5x/include/mach/io.h | 4 +-
arch/arm/mach-tegra/include/mach/io.h | 4 +-
arch/arm/plat-omap/Kconfig | 35 +
arch/arm/plat-omap/devices.c | 40 -
arch/arm/plat-omap/dma.c | 695 ++++-----
arch/arm/plat-omap/gpio.c | 670 +++------
arch/arm/plat-omap/i2c.c | 128 +-
arch/arm/plat-omap/include/plat/clkdev_omap.h | 20 +-
arch/arm/plat-omap/include/plat/clock.h | 16 +-
arch/arm/plat-omap/include/plat/common.h | 2 +
arch/arm/plat-omap/include/plat/dma.h | 232 ++--
arch/arm/plat-omap/include/plat/fpga.h | 4 -
arch/arm/plat-omap/include/plat/gpio.h | 48 +-
arch/arm/plat-omap/include/plat/gpmc.h | 9 +-
arch/arm/plat-omap/include/plat/i2c.h | 13 +
arch/arm/plat-omap/include/plat/io.h | 9 +-
arch/arm/plat-omap/include/plat/iommu.h | 5 +
arch/arm/plat-omap/include/plat/irqs.h | 2 +-
arch/arm/plat-omap/include/plat/keypad.h | 35 +-
arch/arm/plat-omap/include/plat/l4_3xxx.h | 24 +
arch/arm/plat-omap/include/plat/mailbox.h | 8 +-
arch/arm/plat-omap/include/plat/omap-pm.h | 39 +-
arch/arm/plat-omap/include/plat/omap-serial.h | 14 +-
arch/arm/plat-omap/include/plat/omap_device.h | 1 +
arch/arm/plat-omap/include/plat/omap_hwmod.h | 73 +-
arch/arm/plat-omap/include/plat/powerdomain.h | 167 --
arch/arm/plat-omap/include/plat/prcm.h | 20 +-
arch/arm/plat-omap/include/plat/serial.h | 5 +-
arch/arm/plat-omap/include/plat/smartreflex.h | 245 +++
arch/arm/plat-omap/include/plat/sram.h | 11 +
arch/arm/plat-omap/include/plat/uncompress.h | 3 +
arch/arm/plat-omap/include/plat/voltage.h | 146 ++
arch/arm/plat-omap/io.c | 58 -
arch/arm/plat-omap/iommu.c | 24 +
arch/arm/plat-omap/iovmm.c | 81 +-
arch/arm/plat-omap/mailbox.c | 130 +-
arch/arm/plat-omap/mcbsp.c | 26 +-
arch/arm/plat-omap/omap-pm-noop.c | 78 +-
arch/arm/plat-omap/omap_device.c | 28 +
arch/arm/plat-omap/sram.c | 14 +-
drivers/i2c/busses/i2c-omap.c | 73 +-
drivers/input/keyboard/omap-keypad.c | 41 +-
drivers/input/serio/Kconfig | 1 -
drivers/mtd/onenand/omap2.c | 3 +
drivers/serial/8250.c | 26 +-
drivers/serial/omap-serial.c | 40 +-
drivers/staging/tidspbridge/core/_tiomap.h | 15 +-
include/linux/i2c-omap.h | 5 +
include/linux/input/matrix_keypad.h | 2 +-
include/linux/serial_reg.h | 19 +
265 files changed, 21079 insertions(+), 8727 deletions(-)
delete mode 100644 arch/arm/configs/ams_delta_defconfig
delete mode 100644 arch/arm/configs/htcherald_defconfig
delete mode 100644 arch/arm/configs/n770_defconfig
create mode 100644 arch/arm/configs/omap1_defconfig
delete mode 100644 arch/arm/configs/omap_generic_1510_defconfig
delete mode 100644 arch/arm/configs/omap_generic_1610_defconfig
delete mode 100644 arch/arm/configs/omap_generic_1710_defconfig
delete mode 100644 arch/arm/configs/omap_h2_1610_defconfig
delete mode 100644 arch/arm/configs/omap_innovator_1510_defconfig
delete mode 100644 arch/arm/configs/omap_innovator_1610_defconfig
delete mode 100644 arch/arm/configs/omap_osk_5912_defconfig
delete mode 100644 arch/arm/configs/omap_perseus2_730_defconfig
delete mode 100644 arch/arm/configs/palmte_defconfig
delete mode 100644 arch/arm/configs/palmtt_defconfig
delete mode 100644 arch/arm/configs/palmz71_defconfig
delete mode 100644 arch/arm/configs/sx1_defconfig
create mode 100644 arch/arm/mach-omap1/dma.c
create mode 100644 arch/arm/mach-omap1/gpio15xx.c
create mode 100644 arch/arm/mach-omap1/gpio16xx.c
create mode 100644 arch/arm/mach-omap1/gpio7xx.c
create mode 100644 arch/arm/mach-omap2/board-am3517crane.c
create mode 100644 arch/arm/mach-omap2/board-rm680.c
rename arch/arm/mach-omap2/{board-zoom3.c => board-zoom.c} (74%)
delete mode 100644 arch/arm/mach-omap2/board-zoom2.c
rename arch/arm/{plat-omap/include/plat => mach-omap2}/clockdomain.h (82%)
rename arch/arm/mach-omap2/{clockdomains.h => clockdomains2xxx_3xxx_data.c} (87%)
rename arch/arm/mach-omap2/{clockdomains44xx.h => clockdomains44xx_data.c} (58%)
delete mode 100644 arch/arm/mach-omap2/cm.c
create mode 100644 arch/arm/mach-omap2/cm1_44xx.h
create mode 100644 arch/arm/mach-omap2/cm2_44xx.h
create mode 100644 arch/arm/mach-omap2/cm2xxx_3xxx.c
create mode 100644 arch/arm/mach-omap2/cm2xxx_3xxx.h
create mode 100644 arch/arm/mach-omap2/cm44xx.c
delete mode 100644 arch/arm/mach-omap2/cm4xxx.c
create mode 100644 arch/arm/mach-omap2/cminst44xx.c
create mode 100644 arch/arm/mach-omap2/cminst44xx.h
create mode 100644 arch/arm/mach-omap2/dma.c
create mode 100644 arch/arm/mach-omap2/gpio.c
create mode 100644 arch/arm/mach-omap2/mux44xx.c
create mode 100644 arch/arm/mach-omap2/mux44xx.h
create mode 100644 arch/arm/mach-omap2/omap_opp_data.h
create mode 100644 arch/arm/mach-omap2/omap_twl.c
create mode 100644 arch/arm/mach-omap2/opp.c
create mode 100644 arch/arm/mach-omap2/opp3xxx_data.c
create mode 100644 arch/arm/mach-omap2/opp4xxx_data.c
create mode 100644 arch/arm/mach-omap2/powerdomain-common.c
create mode 100644 arch/arm/mach-omap2/powerdomain.h
create mode 100644 arch/arm/mach-omap2/powerdomain2xxx_3xxx.c
create mode 100644 arch/arm/mach-omap2/powerdomain44xx.c
delete mode 100644 arch/arm/mach-omap2/powerdomains.h
create mode 100644 arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c
create mode 100644 arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.h
rename arch/arm/mach-omap2/{powerdomains24xx.h => powerdomains2xxx_data.c} (76%)
rename arch/arm/mach-omap2/{powerdomains34xx.h => powerdomains3xxx_data.c} (86%)
rename arch/arm/mach-omap2/{powerdomains44xx.h => powerdomains44xx_data.c} (79%)
create mode 100644 arch/arm/mach-omap2/prcm44xx.h
create mode 100644 arch/arm/mach-omap2/prcm_mpu44xx.c
create mode 100644 arch/arm/mach-omap2/prcm_mpu44xx.h
create mode 100644 arch/arm/mach-omap2/prm2xxx_3xxx.h
create mode 100644 arch/arm/mach-omap2/prminst44xx.c
create mode 100644 arch/arm/mach-omap2/prminst44xx.h
create mode 100644 arch/arm/mach-omap2/scrm44xx.h
rename arch/arm/mach-omap2/{board-rx51-sdram.c => sdram-nokia.c} (66%)
create mode 100644 arch/arm/mach-omap2/sdram-nokia.h
create mode 100644 arch/arm/mach-omap2/smartreflex-class3.c
create mode 100644 arch/arm/mach-omap2/smartreflex.c
create mode 100644 arch/arm/mach-omap2/sr_device.c
create mode 100644 arch/arm/mach-omap2/voltage.c
create mode 100644 arch/arm/mach-omap2/wd_timer.c
create mode 100644 arch/arm/mach-omap2/wd_timer.h
create mode 100644 arch/arm/plat-omap/include/plat/l4_3xxx.h
delete mode 100644 arch/arm/plat-omap/include/plat/powerdomain.h
create mode 100644 arch/arm/plat-omap/include/plat/smartreflex.h
create mode 100644 arch/arm/plat-omap/include/plat/voltage.h
^ permalink raw reply
* [PATCH V3 42/63] ST SPEAr: replace readl, writel with __raw_readl, __raw_writel in uncompress.h
From: stanley.miao @ 2011-01-07 2:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <73a77c388f8d151ce5bc70000832fbb518babe3b.1292833229.git.viresh.kumar@st.com>
Viresh Kumar wrote:
> readl also calls outer cache maintainance operations
I use readl here on spear13xx. It works fine.
This is the definition of readl, could you tell me which code calls
outer cache maintainance ?
#define readl(c) ({ __u32 __v = le32_to_cpu((__force __le32) \
__raw_readl(__mem_pci(c))); __v; })
> which are not available
> during Linux uncompression. This patch replaces readl, writel with __raw_readl
> and __raw_writel.
>
I tried to make spear13xx working under big endian. The _raw_readl here
brought me a big trouble.
Stanley.
> Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
> ---
> arch/arm/plat-spear/include/plat/uncompress.h | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/plat-spear/include/plat/uncompress.h b/arch/arm/plat-spear/include/plat/uncompress.h
> index 99ba678..963aa5b 100644
> --- a/arch/arm/plat-spear/include/plat/uncompress.h
> +++ b/arch/arm/plat-spear/include/plat/uncompress.h
> @@ -24,10 +24,10 @@ static inline void putc(int c)
> {
> void __iomem *base = (void __iomem *)SPEAR_DBG_UART_BASE;
>
> - while (readl(base + UART01x_FR) & UART01x_FR_TXFF)
> + while (__raw_readl(base + UART01x_FR) & UART01x_FR_TXFF)
> barrier();
>
> - writel(c, base + UART01x_DR);
> + __raw_writel(c, base + UART01x_DR);
> }
>
> static inline void flush(void)
>
^ permalink raw reply
* Memory sharing issue by application on V4L2 based device driver with system mmu.
From: InKi Dae @ 2011-01-07 2:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <002201cbadfd$6d59e490$480dadb0$%han@samsung.com>
thank you for your comments.
your second comment has no any problem as I said before, user virtual
addess could be translated in page unit. but the problem, as you said,
is that when cpu access to the memory in user mode, the memory
allocated by malloc, page fault occurs so we can't find pfn to user
virtual address. I missed that. but I think we could resolve this one.
as before, user application allocates memory through malloc function
and then send it to device driver(using userptr feature). if the pfn
is null when device driver translated user virtual address in page
unit then it allocates phsical memory in page unit using some
interface such as alloc_page() and then mapping them. when pfn is
null, to check it and allocate physical memory in page unit could be
processed by videobuf2.
of course, videobuf2 has no any duty considered for system mmu. so
videobuf2 just provides callback for 3rd party and any platform with
system mmu such as Samsung SoC C210 implements the function(allocating
physical memory and mapping it) and registers it to callback of
videobuf2. by doing so, I think your first comment could be cleared.
please, feel free to give me your opinion and pointing out.
thank you.
2011? 1? 7? ?? 8:57, Jonghun Han <jonghun.han@samsung.com>?? ?:
>
> Hello,
>
> There are two reasons why malloc isn't suitable for it.
>
> The first is that malloc doesn't allocate memory when malloc is called.
> So driver or vb2 cannot find PFN for it in the VIDIOC_QBUF.
>
> The second is that malloc uses 4KB page allocation.
> SYS.MMU(IO-MMU) can handle scattered memory. But it has a penalty when TLB
> miss is occurred.
> So as possible as physically contiguous pages are needed for performance
> enhancement.
>
> So new allocator which can clear two main issues is needed.
>
> Best regards,
>
>> -----Original Message-----
>> From: linux-media-owner at vger.kernel.org [mailto:linux-media-
>> owner at vger.kernel.org] On Behalf Of InKi Dae
>> Sent: Thursday, January 06, 2011 10:25 PM
>> To: linux-media at vger.kernel.org
>> Subject: Memory sharing issue by application on V4L2 based device driver
> with
>> system mmu.
>>
>> Hello, all.
>>
>> I'd like to discuss memory sharing issue by application on v4l2 based
> device driver
>> with system mmu and get some advices about that.
>>
>> Now I am working on Samsung SoC C210 platform and this platform has some
>> multimedia devices with system mmu such as fimc, and mfc also we have
>> implemented device drivers for them. those drivers are based on V4L2
> framework
>> with videobuf2. for system mmu of each device, we used VCM(Virtual
> Contiguous
>> Memory) framework.
>>
>> Simply, VCM framework provides physical memory, device virtual memory
>> allocation and memory mapping between them. when device driver is
> initialized or
>> operated by user application, each driver allocates physical memory and
> device
>> virtual memory and then mapping using VCM interface.
>>
>> refer to below link for more detail.
>> http://www.spinics.net/lists/linux-media/msg26548.html
>>
>> Physical memory access process is as the following.
>> DVA PA
>> device --------------> system mmu ------------------> physical memory
>>
>> DVA : device virtual address.
>> PA : physical address.
>>
>> like this, device virtual address should be set to buffer(source or
>> destination) register of multimedia device.
>>
>> the problem is that application want to share own memory with any device
> driver to
>> avoid memory copy. in other words, user-allocated memory could be source
> or
>> destination memory of multimedia device driver.
>>
>>
>> let's see the diagram below.
>>
>> user application
>>
>> |
>> |
>> |
>> |
>> | 1. UVA(allocated by malloc)
>> |
>> |
>> ?|/ 2. UVA(in page unit)
>>
>> -----> multimedia device driver -------------------> videobuf2
>> |
>> | | ^ |
>> | | | |
>> | | -------------------------------------------
>> | | 3. PA(in page unit)
>> | |
>> | | 4. PA(in page unit)
>> 6. DVA | |
>> | |
>> | |
>> | ?|/
>> |
>> | Virtual Contiguous Memory ---------
>> | |
>> | | ^ |
>> | | | | 5. map PA to DVA
>> | | | |
>> | | | |
>> ------------- -------------------------
>>
>> PA : physical address.
>> UVA : user virtual address.
>> DVA : device virtual address.
>>
>> 1. user application allocates user space memory through malloc function
> and
>> sending it to multimedia device driver based on v4l2 framework through
> userptr
>> feature.
>>
>> 2, 3. multimedia device driver gets translated physical address from
>> videobuf2 framework in page unit.
>>
>> 4, 5. multimedia device driver gets allocated device virtual address and
> mapping it
>> to physical address and then mapping them through VCM interface.
>>
>> 6. multimedia device driver sets device virtual address from VCM to
> buffer register.
>>
>> the diagram above is fully theoretical so I wonder that this way is
> reasonable and
>> has some problems also what should be considered.
>>
>> thank you for your interesting.
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body
>> of a message to majordomo at vger.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* [PATCH] rfc v3: ARM: mach-shmobile: mackerel: Add zboot support
From: Simon Horman @ 2011-01-07 2:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110107013725.GB22477@linux-sh.org>
On Fri, Jan 07, 2011 at 10:37:25AM +0900, Paul Mundt wrote:
> On Thu, Dec 09, 2010 at 09:47:15AM +0900, Simon Horman wrote:
> > When CONFIG_ZBOOT_ROM is selected, the resulting zImage file will be small
> > boot loader and may be burned to rom or flash.
> >
> > Compile tested only.
> >
> > This patch assumes that head-mackerel.txt will be the same as head-ap4evb.txt.
> > I am waiting for verification of this.
> >
> > This patch depends on
> > * ARM: 6515/1: Add zboot support for SuperH Mobile ARM
> > (merged into the devel branch of Russel King's linux-2.6-arm tree)
> > * ARM: 6514/1: mach-shmobile: Add zboot support for SuperH Mobile ARM
> > (merged into the devel branch of Russel King's linux-2.6-arm tree)
> > * MACH_MACKEREL (3211) being present in arch/arm/tools/mach-types
> >
> Ok, I've applied this one now that the dependencies are out of the way.
>
> I plan to send my rmobile updates to Linus today, at which point you
> should be able to submit the outstanding MMCIF patch to Russell's patch
> tracker.
Thanks
^ permalink raw reply
* [PATCH 00/03] ARM: mach-shmobile: Initial SMP support
From: Paul Mundt @ 2011-01-07 1:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20101214095703.GG14606@linux-sh.org>
On Tue, Dec 14, 2010 at 06:57:03PM +0900, Paul Mundt wrote:
> On Tue, Dec 14, 2010 at 04:56:47PM +0900, Magnus Damm wrote:
> > ARM: mach-shmobile: Initial SMP support
> >
> > [PATCH 01/03] ARM: mach-shmobile: SMP base support
> > [PATCH 02/03] ARM: mach-shmobile: Enable SMP support
> > [PATCH 03/03] ARM: mach-shmobile: sh73a0 SMP support
> >
> > These patches add SMP framework support for R-Mobile and
> > SH-Mobile processors, together with hardware specific SMP
> > support for the sh73a0 processor.
> >
> > Survives onlining and offlining of secondary processor cores
> > through sysfs. Should compile and boot regardless of
> > CONFIG_SMP, CONFIG_HOTPLUG_CPU and CONFIG_LOCAL_TIMERS.
> >
> > I suggest that patch 1 and 3 are taken through sh-2.6 and
> > patch 2 goes through the RMK patch tracker.
> >
> > Signed-off-by: Magnus Damm <damm@opensource.se>
>
> Applied to rmobile/smp, thanks.
>
> There are integration issues with regards to the GIC changes that I'll
> have to take care of during the merge window regardless, so resolving the
> CONFIG_SMP thing at that point should be pretty straightforward. My plan
> is to wait until after Russell merges, merge your stuff on top of that,
> and then send the updated bits to Linus in one shot.
>
> In order to avoid clashes with -next for now however I won't be merging
> the topic branch in to my -latest branch. Given that the number of boards
> in the wild for this at the moment are in the single digits, I'm not too
> worried about the amount of time these changes spend in -next so long as
> no regressions are introduced for the other boards.
I've now merged the rmobile/smp branch in to rmobile-latest, which
resolves the minor clashes with Russell's merge as well as the
entry-macro rework.
^ permalink raw reply
* [PATCH] rfc v3: ARM: mach-shmobile: mackerel: Add zboot support
From: Paul Mundt @ 2011-01-07 1:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1291855635-30882-1-git-send-email-horms@verge.net.au>
On Thu, Dec 09, 2010 at 09:47:15AM +0900, Simon Horman wrote:
> When CONFIG_ZBOOT_ROM is selected, the resulting zImage file will be small
> boot loader and may be burned to rom or flash.
>
> Compile tested only.
>
> This patch assumes that head-mackerel.txt will be the same as head-ap4evb.txt.
> I am waiting for verification of this.
>
> This patch depends on
> * ARM: 6515/1: Add zboot support for SuperH Mobile ARM
> (merged into the devel branch of Russel King's linux-2.6-arm tree)
> * ARM: 6514/1: mach-shmobile: Add zboot support for SuperH Mobile ARM
> (merged into the devel branch of Russel King's linux-2.6-arm tree)
> * MACH_MACKEREL (3211) being present in arch/arm/tools/mach-types
>
Ok, I've applied this one now that the dependencies are out of the way.
I plan to send my rmobile updates to Linus today, at which point you
should be able to submit the outstanding MMCIF patch to Russell's patch
tracker.
^ permalink raw reply
* [PATCH 0/2] Common struct clk implementation, v10
From: Ben Dooks @ 2011-01-07 1:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294199462.347935.472473715866.0.gpush@pororo>
On 05/01/11 03:51, Jeremy Kerr wrote:
> Hi all,
>
> These patches are an attempt to allow platforms to share clock code. At
> present, the definitions of 'struct clk' are local to platform code,
> which makes allocating and initialising cross-platform clock sources
> difficult, and makes it impossible to compile a single image containing
> support for two ARM platforms with different struct clks.
no, it doesn't actually. you could do run-time link and select
the right arch support.
^ permalink raw reply
* mxc: i2c register mapped twice?
From: Ben Dooks @ 2011-01-07 1:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106122611.GA31718@shlinux1.ap.freescale.net>
On 06/01/11 12:26, Richard Zhao wrote:
> Hi Sascha,
>
> I just realized i2c registers are mapped twice. It's first static mapped at
> mx5x_io_desc and second mapped in driver.
> Drivers always feel happy to receive physical address in resource, and ioremap
> it itself. We might static map too many register regions in machine level?
> I'm sure it's not just i2c.
either cleanup the mapping, or add a custom ioremap() to return this
region for the drivers.
^ permalink raw reply
* [PATCH 1/2] Add a common struct clk
From: Russell King - ARM Linux @ 2011-01-07 0:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201101070810.21398.jeremy.kerr@canonical.com>
On Fri, Jan 07, 2011 at 08:10:20AM +0800, Jeremy Kerr wrote:
> Hi Richard,
>
> > > > +struct clk {
> > > > + const struct clk_ops *ops;
> > > > + unsigned int enable_count;
> > > > + int flags;
> > > > + union {
> > > > + struct mutex mutex;
> > > > + spinlock_t spinlock;
> > > > + } lock;
> > > > +};
> > >
> > > Here you have a "polymorphic" lock, where the clock instance knows
> > > which type it is supposed to be. I got flak from David Miller and
> > >
> > > others trying to do the same thing with the mdio_bus:
> > > http://kerneltrap.org/mailarchive/linux-netdev/2010/7/6/6280618
> > >
> > > The criticism, applied to your case, is that the clk_enable() caller
> > > cannot know whether it is safe to make the call or not. I was told,
> > > "there has got to be a better way."
> >
> > Note that this is not "new". Currently there is no convention available
> > if clk_enable sleeps or not. See e.g.
> > http://thread.gmane.org/gmane.linux.ports.arm.kernel/100744
>
> As Uwe says, the common clock does not change these semantics; I would prefer
> to keep the driver API changes at a minimum with these patches.
>
> But yes, it would be a good idea to:
>
> * introduce clk_enable_atomic, which requires clk->flags & CLK_ATOMIC
>
> * add might_sleep to clk_enable(), encouraging clk uses in atomic contexts
> to switch to clk_enable_atomic.
>
> We'd still be able to handle CLK_ATOMIC clocks in clk_enable(), so the
> enforcement only needs to be one-way.
I think the atomic stuff should be the norm through and through - otherwise
we're going to end up with problems in drivers where they use the _atomic()
stuff, but the clocks behind are coded to sleep.
I hate the GPIO APIs for doing this _cansleep crap as the decision of
whether to use the _cansleep or normal APIs normally can't be made at
the time when the API is used, but sometime later. Many people just use
the non-_cansleep versions irrespective of the context they're in -
which is unnecessarily restrictive - consider what happens if you then
have that driver use a GPIO on an I2C peripheral...
By inventing two interfaces, you're asking for the same thing to happen
with clocks.
^ 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