* [PATCH] Fix hang on reboot with Tegra2
From: Simon Glass @ 2011-02-17 16:13 UTC (permalink / raw)
To: linux-arm-kernel
This seems to be a regression in 2.6.37.
We cannot use writel() here since the resulting wmb() calls l2x0_cache_sync()
which uses a spinlock and L1 cache may be off at this point.
Change-Id: Ia23b317dee919055ff4abba1484735ea3165fd99
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-February/041909.html
Signed-off-by: Simon Glass <sjg@chromium.org>
---
arch/arm/mach-tegra/include/mach/system.h | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-tegra/include/mach/system.h b/arch/arm/mach-tegra/include/mach/system.h
index 84d5d46..f1c0a79 100644
--- a/arch/arm/mach-tegra/include/mach/system.h
+++ b/arch/arm/mach-tegra/include/mach/system.h
@@ -33,7 +33,9 @@ static inline void arch_reset(char mode, const char *cmd)
void __iomem *reset = IO_ADDRESS(TEGRA_CLK_RESET_BASE + 0x04);
u32 reg = readl(reset);
reg |= 0x04;
- writel(reg, reset);
+
+ /* use writel_related to avoid spinlock since L1 cache may be off */
+ writel_relaxed(reg, reset);
}
#endif
--
1.7.3.1
^ permalink raw reply related
* [PATCH] omap2plus: smartreflex: remove sr debug directory in omap_sr_remove()
From: sawant at ti.com @ 2011-02-17 15:57 UTC (permalink / raw)
To: linux-arm-kernel
From: Anand S Sawant <sawant@ti.com>
omap_sr_probe() creates the smartreflex debug directory and its
underlying nvalue debug directory. These directories are removed in
omap_sr_remove().
Basic smartreflex functionality tested on OMAP3630 Zoom3 & OMAP4430 SDP
Signed-off-by: Anand S Sawant <sawant@ti.com>
---
Rebased on the latest Kevin's pm branch
(commit id: b6fb54bc4bfc396a9b982d76c1c954c974290a1a)
arch/arm/mach-omap2/smartreflex.c | 23 +++++++++++++----------
1 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
index a1f532e..dc19f17 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -54,6 +54,7 @@ struct omap_sr {
struct list_head node;
struct omap_sr_nvalue_table *nvalue_table;
struct voltagedomain *voltdm;
+ struct dentry *dbg_dir;
};
/* sr_list contains all the instances of smartreflex module */
@@ -822,7 +823,7 @@ static int __init omap_sr_probe(struct platform_device *pdev)
struct omap_sr *sr_info = kzalloc(sizeof(struct omap_sr), GFP_KERNEL);
struct omap_sr_data *pdata = pdev->dev.platform_data;
struct resource *mem, *irq;
- struct dentry *vdd_dbg_dir, *dbg_dir, *nvalue_dir;
+ struct dentry *vdd_dbg_dir, *nvalue_dir;
struct omap_volt_data *volt_data;
int i, ret = 0;
@@ -895,23 +896,23 @@ static int __init omap_sr_probe(struct platform_device *pdev)
if (!vdd_dbg_dir)
return -EINVAL;
- dbg_dir = debugfs_create_dir("smartreflex", vdd_dbg_dir);
- if (IS_ERR(dbg_dir)) {
+ sr_info->dbg_dir = debugfs_create_dir("smartreflex", vdd_dbg_dir);
+ if (IS_ERR(sr_info->dbg_dir)) {
dev_err(&pdev->dev, "%s: Unable to create debugfs directory\n",
__func__);
- return PTR_ERR(dbg_dir);
+ return PTR_ERR(sr_info->dbg_dir);
}
- (void) debugfs_create_file("autocomp", S_IRUGO | S_IWUSR, dbg_dir,
- (void *)sr_info, &pm_sr_fops);
- (void) debugfs_create_x32("errweight", S_IRUGO, dbg_dir,
+ (void) debugfs_create_file("autocomp", S_IRUGO | S_IWUSR,
+ sr_info->dbg_dir, (void *)sr_info, &pm_sr_fops);
+ (void) debugfs_create_x32("errweight", S_IRUGO, sr_info->dbg_dir,
&sr_info->err_weight);
- (void) debugfs_create_x32("errmaxlimit", S_IRUGO, dbg_dir,
+ (void) debugfs_create_x32("errmaxlimit", S_IRUGO, sr_info->dbg_dir,
&sr_info->err_maxlimit);
- (void) debugfs_create_x32("errminlimit", S_IRUGO, dbg_dir,
+ (void) debugfs_create_x32("errminlimit", S_IRUGO, sr_info->dbg_dir,
&sr_info->err_minlimit);
- nvalue_dir = debugfs_create_dir("nvalue", dbg_dir);
+ nvalue_dir = debugfs_create_dir("nvalue", sr_info->dbg_dir);
if (IS_ERR(nvalue_dir)) {
dev_err(&pdev->dev, "%s: Unable to create debugfs directory"
"for n-values\n", __func__);
@@ -975,6 +976,8 @@ static int __devexit omap_sr_remove(struct platform_device *pdev)
if (sr_info->autocomp_active)
sr_stop_vddautocomp(sr_info);
+ if (sr_info->dbg_dir)
+ debugfs_remove_recursive(sr_info->dbg_dir);
list_del(&sr_info->node);
iounmap(sr_info->base);
--
1.7.0.4
^ permalink raw reply related
* [patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG
From: Cousson, Benoit @ 2011-02-17 15:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110217152648.GO22356@legolas.emea.dhcp.ti.com>
On 2/17/2011 4:26 PM, Balbi, Felipe wrote:
> On Thu, Feb 17, 2011 at 04:21:47PM +0100, Cousson, Benoit wrote:
>> On 2/17/2011 4:18 PM, Balbi, Felipe wrote:
>>> On Thu, Feb 17, 2011 at 05:15:27PM +0200, Felipe Balbi wrote:
>>>> On Thu, Feb 17, 2011 at 02:43:21PM +0100, Cousson, Benoit wrote:
>>>>> Hi Felipe and Hema,
>>>>>
>>>>> Sorry for this late review, but I have a couple of comments on this one.
>>>>>
>>>>> Since I was planning to send usb hwmod data file to Tony directly
>>>>> like I did for the other drivers, I can handle the update myself if
>>>>> you want.
>>>>
>>>> I'll change this particular patch to yours.
>>>
>>> doesn't apply:
>>>
>>> $ patch -p1< ~/benoit.diff
>>> patching file arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>>> Hunk #1 succeeded at 55 with fuzz 1 (offset -7 lines).
>>> patch: **** malformed patch at line 42: omap44xx_l4_cfg__l3_main_2 = {
>>>
>>> could you base this off of v2.6.38-rc5 ?
>>
>> This is what I was about to say.
>> You have a dependency with the for_2.6.39/omap4_hwmod_data branch
>> in git://gitorious.org/omap-pm/linux.git.
>
> I cannot have such a dependency and if you create that I can't send a
> pull request to Tony otherwise we will have conflicts later. Either you
> clear up that dependency or Tony will have to manually apply the patches
> I have queued. It's only 7 of them anyway, so maybe not a big deal.
I will try to rebase that one on v2.6.38-rc5 and see if it will generate
any issue during the merge with the omap4_hwmod_data series. Generally
issues appears if the data are located at the same place in the file.
Since the usb is between uart and wd_timer, that might work.
Benoit
^ permalink raw reply
* [PATCH]drivers:dma:coh901318.c Change initate to initiate.
From: Jiri Kosina @ 2011-02-17 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=F29x=iFUGd3PkHhLtA5E_oA5R7fOyUvQJXW0J@mail.gmail.com>
On Mon, 31 Jan 2011, Linus Walleij wrote:
> > Not sure if this is a typo or not. if it is then feel free to take this.
> >
> > Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
>
> Why not,
> Acked-by: Linus Walleij <linus.walleij@stericsson.com>
Applied.
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply
* MMC quirks relating to performance/lifetime.
From: Arnd Bergmann @ 2011-02-17 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimoqCtWMmBJ40v+1UjR0U2Sdh9pp+2fwYpi3fUx@mail.gmail.com>
On Thursday 17 February 2011, Andrei Warkentin wrote:
> Ext4.
Ok, I see. I haven't really done this kind of tests before, but my
feeling is that ext3/ext4 may be much worse than the alternatives
at the moment. It would certainly be worthwhile to do tests using
nilfs2 and btrfs, whose default behaviour matches the requirements
of your eMMC flash much better, and see how they perform with and
without your patch.
> I agree, which is why all of this is controlled now through sysfs, and
> there are no more hard-coded checks for manfid, mmc versus sd or any
> other magic. There is a page_size_secs attribute, through which you
> can notify of the page size for the device.
How about making that just page_size in bytes? sectors don't always
mean 512 bytes, so this would be both shorter and less anbiguous.
> The workaround for small
> writes crossing the page boundary (and winding up in Buffer B, instead
> of A) is turned on by setting split_tlow and split_thigh, which
> provided a threshold range in sectors over which the the writes will
> be split/aligned. The second workaround for splitting larger requests
> and writing them with reliable write (to avoid getting coalesced and
> winding up in Buffer B again) is controlled through split_relw_tlow
> and split_relw_thigh. Do you think there is a better way? Or is this
> good enough?
I think I'd try to reduce the number of sysfs files needed for this.
What are the values you would typically set here?
My feeling is that separating unaligned page writes from full pages
or multiples of pages could always be benefitial for all cards, or at
least harmless, but that will require more measurements.
Whether to do the reliable write or not could be a simple flag
if the numbers are the same.
> So, as I mentioned before, T had done some tests given data provided
> by M, and then T verified that this fix was good. I need to do my own
> tests on the patch after I rewrite it. Is iozone the best tool I can
> use? So far I have a MMC logging facility through connector that I use
> to collect stats (useful for seeing how fs traffic translates to
> actual mmc commands...once I clean it up I'll push here for RFC). What
> about the tool you're writing? Any way I can use it?
It's now available in a an early almost-usable version at
git://git.linaro.org/people/arnd/flashbench.git
I don't have a test for the second buffer yet, but it would be
good to know some of the other characteristics of your eMMC drive.
Please try some of these commands:
flashbench -a /dev/mmcblk0 --blocksize=1024
flashbench --open-au --open-au-nr=1 /dev/mmcblk0 --blocksize=512
flashbench --open-au --open-au-nr=1 /dev/mmcblk0 --blocksize=512 --random
flashbench --open-au --open-au-nr=2 /dev/mmcblk0 --blocksize=512
flashbench --open-au --open-au-nr=2 /dev/mmcblk0 --blocksize=512 --random
flashbench --open-au --open-au-nr=3 /dev/mmcblk0 --blocksize=512
flashbench --open-au --open-au-nr=3 /dev/mmcblk0 --blocksize=512 --random
Note that the --open-au test will overwrite your data. You can do it on a
partition you don't use, but it needs to be aligned to 4 MB.
Arnd
^ permalink raw reply
* [patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG
From: Felipe Balbi @ 2011-02-17 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D5D3D0B.8090106@ti.com>
On Thu, Feb 17, 2011 at 04:21:47PM +0100, Cousson, Benoit wrote:
> On 2/17/2011 4:18 PM, Balbi, Felipe wrote:
> >On Thu, Feb 17, 2011 at 05:15:27PM +0200, Felipe Balbi wrote:
> >>On Thu, Feb 17, 2011 at 02:43:21PM +0100, Cousson, Benoit wrote:
> >>>Hi Felipe and Hema,
> >>>
> >>>Sorry for this late review, but I have a couple of comments on this one.
> >>>
> >>>Since I was planning to send usb hwmod data file to Tony directly
> >>>like I did for the other drivers, I can handle the update myself if
> >>>you want.
> >>
> >>I'll change this particular patch to yours.
> >
> >doesn't apply:
> >
> >$ patch -p1< ~/benoit.diff
> >patching file arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> >Hunk #1 succeeded at 55 with fuzz 1 (offset -7 lines).
> >patch: **** malformed patch at line 42: omap44xx_l4_cfg__l3_main_2 = {
> >
> >could you base this off of v2.6.38-rc5 ?
>
> This is what I was about to say.
> You have a dependency with the for_2.6.39/omap4_hwmod_data branch
> in git://gitorious.org/omap-pm/linux.git.
I cannot have such a dependency and if you create that I can't send a
pull request to Tony otherwise we will have conflicts later. Either you
clear up that dependency or Tony will have to manually apply the patches
I have queued. It's only 7 of them anyway, so maybe not a big deal.
Tony, what do you prefer ? Do we clear out the dependency, or you queue
all the patches I have manually ??
A simple way to clear this out would be with a git rebase -i v2.6.38-rc5
and moving the MUSB HWMOD to be the first one in the series, then it
should apply cleanly on my tree.
--
balbi
^ permalink raw reply
* [PATCH] i.MX23/28 framebuffer driver
From: Clark, Rob @ 2011-02-17 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTim3iUNHsaCf7387H-X+XW0YDQsQVa1FwDvo0KvH@mail.gmail.com>
Hmm, I was thinking more on the xf86 side of things.. ie. to provide
default implementations of xf86CrtcFuncsRec and xf86OutputFuncsRec
functions..
BR,
-R
On Wed, Feb 16, 2011 at 7:24 PM, Jammy Zhou <jammy.zhou@linaro.org> wrote:
>
> There is already one KMS abstraction layer (libkms.so) in libdrm, maybe it can serve as what we needed.
>
> Regards,
> Jammy
>
> On Thu, Feb 17, 2011 at 9:08 AM, Clark, Rob <rob@ti.com> wrote:
>>
>> I'm still in the learning-as-I-go phase here, so definitely not ready
>> to propose a solution, but it does seem to me like there is room for
>> some sort of kms-helper library here to handle more of the boilerplate
>> xf86-video-* stuff.. ?I guess I'll have a better picture once I have a
>> chance to add support for the various multi-monitor configurations.
>> But certainly would be interested if anyone already has some ideas.
>>
>> BR,
>> -R
>>
>> On Wed, Feb 16, 2011 at 8:42 AM, Jesse Barker <jesse.barker@linaro.org> wrote:
>> > Speaking for the Linaro graphics working group, I think it's great.? And, I
>> > think you're right, that if enough of the KMS support in xf86-video-* is
>> > similar enough (I was only aware of intel and nouveau supporting it properly
>> > at current), pulling it out into a common layer would make it easier to
>> > support in new drivers (including fbdev).
>> >
>> > cheers,
>> > Jesse
>> >
>> > On Wed, Feb 16, 2011 at 4:22 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> >>
>> >> On Tuesday 15 February 2011, Clark, Rob wrote:
>> >> > I'd been experimenting a bit on the side w/ the DRM driver framework (
>> >> >
>> >> > http://gitorious.com/~robclark/pandaboard/robclarks-kernel-omap4/commits/omap_gpu
>> >> > ), but had to add a good chunk of mostly boilerplate code to our xorg
>> >> > driver in order just to test it. ?Maybe some generic support for KMS
>> >> > in xf86-video-fbdev would have made this easier to develop the kernel
>> >> > part without in parallel having to implement the userspace part. ?I'm
>> >> > not sure if this is the sort of thing the linaro-wg has in mind?
>> >>
>> >> I'm not sure what the the linaro multimedia wg thinks of this, but the
>> >> kernel code you linked looks like it's doing exactly the right thing.
>> >>
>> >> ? ? ? ?Arnd
>> >>
>> >> _______________________________________________
>> >> linaro-dev mailing list
>> >> linaro-dev at lists.linaro.org
>> >> http://lists.linaro.org/mailman/listinfo/linaro-dev
>> >
>> >
>>
>> _______________________________________________
>> linaro-dev mailing list
>> linaro-dev at lists.linaro.org
>> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
^ permalink raw reply
* platform/i2c busses: pm runtime and system sleep
From: Rabin Vincent @ 2011-02-17 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201012170109.43137.rjw@sisk.pl>
On Fri, Dec 17, 2010 at 05:39, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Thursday, December 16, 2010, Rabin Vincent wrote:
>> There seem to be some differences between the generic ops and the i2c
>> and platform busses' implementations of the interaction between runtime
>> PM and system sleep:
>>
>> ? (1) The platform bus does not implement the
>> ? ? ? don't-call-pm->suspend()-if pm_runtime_suspended()-returns-true
>> ? ? ? functionality implemented by the generic ops and i2c.
>>
>> ? (2) Both I2C and platform do not set the device as active when a
>> ? ? ? pm->resume callback exists and it succeeds.
...
>> Are these divergences from the generic ops to be considered as bugs?
>
> I think so. ?I'm not sure about (1), because someone may already depend on
> that behavior, but (2) looks like a bug to me.
Revisiting these points again. (2) has since been corrected for i2c,
but platform does not do (1) and (2).
I've submitted a patch today to convert the AMBA bus to support pm-ops,
and it was convenient to just use the GENERIC_SUBSYS_PM_OPS. But some
ARM SoCs have a combination of AMBA and platform devices for the on-chip
devices so having different behaviour between the interaction of
runtime-pm and system suspend callbacks does not seem like an ideal
situation, and would only serve to confuse driver writers. So, should I
just not use GENERIC_SUBSYS_PM_OPS in the AMBA bus but instead open-code
the rountines to make it work like platform?
This will solve the platform vs AMBA bus, but shouldn't we really be
aiming for consistent behaviour between these and the other busses such
as I2C and SPI, which are also usually commonly used on the same
platforms and are using GENERIC_PM_OPS?
Should we be auditing all platform drivers and then switch platform to
the GENERIC_PM_OPS?
Or should the two points (1) and (2) be not handled in the bus at all
and be left to individual drivers (in which case we should audit i2c and
spi and change GENERIC_PM_OPS)?
^ permalink raw reply
* [PATCHv3] mx31: add support for the bugbase 1.3 from buglabs
From: Denis 'GNUtoo' Carikli @ 2011-02-17 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110213211855.GC13279@pengutronix.de>
> And I wonder there is no copyright statement by you in
> arch/arm/mach-mx3/mach-bug.c, maybe because you consider your changes
> too minor to be relevant? (INAL and I don't know who to value your
> contribution.)
Here is the thread:
http://thread.gmane.org/gmane.linux.ports.arm.msm/122
What should I do? can I add my own name too?
Denis.
^ permalink raw reply
* [patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG
From: Cousson, Benoit @ 2011-02-17 15:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110217151804.GM22356@legolas.emea.dhcp.ti.com>
On 2/17/2011 4:18 PM, Balbi, Felipe wrote:
> On Thu, Feb 17, 2011 at 05:15:27PM +0200, Felipe Balbi wrote:
>> On Thu, Feb 17, 2011 at 02:43:21PM +0100, Cousson, Benoit wrote:
>>> Hi Felipe and Hema,
>>>
>>> Sorry for this late review, but I have a couple of comments on this one.
>>>
>>> Since I was planning to send usb hwmod data file to Tony directly
>>> like I did for the other drivers, I can handle the update myself if
>>> you want.
>>
>> I'll change this particular patch to yours.
>
> doesn't apply:
>
> $ patch -p1< ~/benoit.diff
> patching file arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> Hunk #1 succeeded at 55 with fuzz 1 (offset -7 lines).
> patch: **** malformed patch at line 42: omap44xx_l4_cfg__l3_main_2 = {
>
> could you base this off of v2.6.38-rc5 ?
This is what I was about to say.
You have a dependency with the for_2.6.39/omap4_hwmod_data branch
in git://gitorious.org/omap-pm/linux.git.
Benoit
^ permalink raw reply
* [PATCH 4/8] OMAP4: hwmod data: Add DSS, DISPC, DSI1&2, RFBI, HDMI and VENC
From: Semwal, Sumit @ 2011-02-17 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimPxP2dN-xgKhTwFwo-iPcgJ9gRSYAFF3=TLap1@mail.gmail.com>
On Thu, Feb 17, 2011 at 8:32 PM, Semwal, Sumit <sumit.semwal@ti.com> wrote:
> Hi Benoit,
>
> One minor comment;
>
> On Thu, Feb 17, 2011 at 3:54 PM, Benoit Cousson <b-cousson@ti.com> wrote:
>> Add dss, dispc, dsi1, dsi2, hdmi, rfbi and venc hwmods.
>> In OMAP4 there are severals IPs that can be reached by differents
>> interconnect paths depending of the access initiator (MPU vs. SDMA).
>> In the case of the DSS, both L3 direct path and L4 CFG path can be
>> used to access all the DSS IPs. The two ocp_ip already exists to support
>> the two address spaces.
>>
>> ? ? ?+------------+-- L3_MAIN --+ MPU
>> ?IP ?| ? ? ? ? ? ?|
>> ? ? ?+-- L4_CFG --+
>>
>> L3 main address range is specified first, since it is used by default.
>> dss is also considered as an IP as dispc, rfbi, and named as dss_core.
>>
>> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
>> Signed-off-by: Mayuresh Janorkar <mayur@ti.com>
>> Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com>
>> Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
>> [b-cousson at ti.com: Re-organize structures to match file
>> convention and remove irq entry from dss_hwmod]
>> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
>> @@ -1,7 +1,7 @@
>> ?/*
>> ?* Hardware modules present on the OMAP44xx chips
>> ?*
>> - * Copyright (C) 2009-2010 Texas Instruments, Inc.
>> + * Copyright (C) 2009-2011 Texas Instruments, Inc.
>> ?* Copyright (C) 2009-2010 Nokia Corporation
>> ?*
>> ?* Paul Walmsley
>> @@ -43,6 +43,7 @@
>> ?static struct omap_hwmod omap44xx_dma_system_hwmod;
>> ?static struct omap_hwmod omap44xx_dmm_hwmod;
>> ?static struct omap_hwmod omap44xx_dsp_hwmod;
>> +static struct omap_hwmod omap44xx_dss_hwmod;
> I guess we agreed to name this dss_core - any specific reason to change it?
Oh well, blame it on weary eyes - I do see that you've named the
device correctly as 'dss_core', so please ignore this comment!
Best regards,
~Sumit.
>
> Best regards,
> ~Sumit.
> <snip>
>
^ permalink raw reply
* [PATCH V3 3/4] ARM: Xilinx: base header files and assembly macros
From: Arnd Bergmann @ 2011-02-17 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110217151223.GJ24627@n2100.arm.linux.org.uk>
On Thursday 17 February 2011, Russell King - ARM Linux wrote:
> > Actually, for correctness you should use the regular readl/writel, not
> > the __raw_ versions, which can result in reordered or partial accesses
> > on the bus.
>
> Not in the decompressor. readl/writel are unsupported there - the
> decompressor doesn't have the L2 cache support code and so the barriers
> necessary for readl/writel cause link errors.
Ah right, of course. Sorry for the confusion.
Arnd
^ permalink raw reply
* [patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG
From: Felipe Balbi @ 2011-02-17 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110217151527.GL22356@legolas.emea.dhcp.ti.com>
On Thu, Feb 17, 2011 at 05:15:27PM +0200, Felipe Balbi wrote:
> On Thu, Feb 17, 2011 at 02:43:21PM +0100, Cousson, Benoit wrote:
> > Hi Felipe and Hema,
> >
> > Sorry for this late review, but I have a couple of comments on this one.
> >
> > Since I was planning to send usb hwmod data file to Tony directly
> > like I did for the other drivers, I can handle the update myself if
> > you want.
>
> I'll change this particular patch to yours.
doesn't apply:
$ patch -p1 < ~/benoit.diff
patching file arch/arm/mach-omap2/omap_hwmod_44xx_data.c
Hunk #1 succeeded at 55 with fuzz 1 (offset -7 lines).
patch: **** malformed patch@line 42: omap44xx_l4_cfg__l3_main_2 = {
could you base this off of v2.6.38-rc5 ?
--
balbi
^ permalink raw reply
* [RFC 2/5] ARM: P2V: avoid initializers and assembly using PHYS_OFFSET
From: Eric Miao @ 2011-02-17 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1PaDOv-00023d-Gi@rmk-PC.arm.linux.org.uk>
On Wed, Jan 5, 2011 at 4:22 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> As PHYS_OFFSET will be becoming a variable, we can't have it used in
> initializers nor assembly code. ?Replace those in generic code with
> a run-time initialization. ?Replace those in platform code using the
> individual platform specific PLAT_PHYS_OFFSET.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Eric Miao <eric.y.miao@gmail.com>
^ permalink raw reply
* [RFC 1/5] ARM: P2V: separate PHYS_OFFSET from platform definitions
From: Eric Miao @ 2011-02-17 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1PaDOb-00023Z-CR@rmk-PC.arm.linux.org.uk>
On Wed, Jan 5, 2011 at 4:22 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> This uncouple PHYS_OFFSET from the platform definitions, thereby
> facilitating run-time computation of the physical memory offset.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Acked-by: Eric Miao <eric.y.miao@gmail.com>
^ permalink raw reply
* [patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG
From: Felipe Balbi @ 2011-02-17 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D5D25F9.8030907@ti.com>
On Thu, Feb 17, 2011 at 02:43:21PM +0100, Cousson, Benoit wrote:
> Hi Felipe and Hema,
>
> Sorry for this late review, but I have a couple of comments on this one.
>
> Since I was planning to send usb hwmod data file to Tony directly
> like I did for the other drivers, I can handle the update myself if
> you want.
I'll change this particular patch to yours.
--
balbi
^ permalink raw reply
* [PATCH V3 3/4] ARM: Xilinx: base header files and assembly macros
From: Russell King - ARM Linux @ 2011-02-17 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102171541.12261.arnd@arndb.de>
On Thu, Feb 17, 2011 at 03:41:11PM +0100, Arnd Bergmann wrote:
> On Thursday 17 February 2011, John Linn wrote:
> > > > +
> > > > +#define UART_FIFO_WRITE(base, value) \
> > > > + (*(volatile unsigned int *)((base) + UART_FIFO_OFFSET) =
> > (value))
> > > > +
> > > > +#define UART_STATUS(base) \
> > > > + (*(volatile unsigned int *)((base) + UART_SR_OFFSET))
> > >
> > > You could probably make these static inline functions in the header
> > and
> > > use __raw_{readl,writel}() to make this a little cleaner.
> > >
> >
> > I had considered that, but it wasn't clear to me at the time what the
> > compressor could use or not.
> >
> > I'll give it a try as I agree that's cleaner.
>
> Actually, for correctness you should use the regular readl/writel, not
> the __raw_ versions, which can result in reordered or partial accesses
> on the bus.
Not in the decompressor. readl/writel are unsupported there - the
decompressor doesn't have the L2 cache support code and so the barriers
necessary for readl/writel cause link errors.
^ permalink raw reply
* [PATCH v2 1/3] dmaengine: mxs-dma: add dma support for i.MX23/28
From: Russell King - ARM Linux @ 2011-02-17 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102171538.31061.arnd@arndb.de>
On Thu, Feb 17, 2011 at 03:38:30PM +0100, Arnd Bergmann wrote:
> On Monday 14 February 2011, Shawn Guo wrote:
> > +static void mxs_dma_tasklet(unsigned long data)
> > +{
> > + struct mxs_dma_chan *mxs_chan = (struct mxs_dma_chan *) data;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&mxs_chan->lock, flags);
> > +
> > + if (mxs_chan->desc.callback)
> > + mxs_chan->desc.callback(mxs_chan->desc.callback_param);
> > +
> > + if (mxs_chan->status == DMA_SUCCESS)
> > + mxs_chan->last_completed = mxs_chan->desc.cookie;
> > +
> > + spin_unlock_irqrestore(&mxs_chan->lock, flags);
> > +}
>
> Here is a different problem. The entire tasklet has interrupts
> disabled and holds the spinlock that the interrupt handler does
> not hold.
>
> This actually makes the tasklet a stricter context than the
> actual interrupt handler, defeating the purpose of tasklets
> (i.e. that you can run code without disabling interrupts).
>
> I don't know what the rules for dmaengine callbacks are regarding
> the context in which they are called, but it seems you should
> either get rid of the spin_lock_irqsave here or do everything
> from the interrupt handler.
dmaengine callbacks should be made from tasklet context with no locks
held.
The generally accepted way to do this is:
dma_async_tx_callback callback;
void *callback_param;
spin_lock_irqsave(&mxs_chan->lock, flags);
callback = mxs_chan->desc.callback;
callback_param = mxs_chan->desc.callback_param;
if (mxs_chan->status == DMA_SUCCESS)
mxs_chan->last_completed = mxs_chan->desc.cookie;
spin_unlock_irqrestore(&mxs_chan->lock, flags);
if (callback)
callback(callback_param);
which also avoids the locking issue when the callback starts the next
MMC request.
^ permalink raw reply
* [PATCH 4/8] OMAP4: hwmod data: Add DSS, DISPC, DSI1&2, RFBI, HDMI and VENC
From: Semwal, Sumit @ 2011-02-17 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297938289-8678-5-git-send-email-b-cousson@ti.com>
Hi Benoit,
One minor comment;
On Thu, Feb 17, 2011 at 3:54 PM, Benoit Cousson <b-cousson@ti.com> wrote:
> Add dss, dispc, dsi1, dsi2, hdmi, rfbi and venc hwmods.
> In OMAP4 there are severals IPs that can be reached by differents
> interconnect paths depending of the access initiator (MPU vs. SDMA).
> In the case of the DSS, both L3 direct path and L4 CFG path can be
> used to access all the DSS IPs. The two ocp_ip already exists to support
> the two address spaces.
>
> ? ? ?+------------+-- L3_MAIN --+ MPU
> ?IP ?| ? ? ? ? ? ?|
> ? ? ?+-- L4_CFG --+
>
> L3 main address range is specified first, since it is used by default.
> dss is also considered as an IP as dispc, rfbi, and named as dss_core.
>
> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
> Signed-off-by: Mayuresh Janorkar <mayur@ti.com>
> Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com>
> Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
> [b-cousson at ti.com: Re-organize structures to match file
> convention and remove irq entry from dss_hwmod]
> ---
> ?arch/arm/mach-omap2/omap_hwmod_44xx_data.c | ?612 +++++++++++++++++++++++++++-
> ?1 files changed, 604 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index 37b3024..aafe60d 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -1,7 +1,7 @@
> ?/*
> ?* Hardware modules present on the OMAP44xx chips
> ?*
> - * Copyright (C) 2009-2010 Texas Instruments, Inc.
> + * Copyright (C) 2009-2011 Texas Instruments, Inc.
> ?* Copyright (C) 2009-2010 Nokia Corporation
> ?*
> ?* Paul Walmsley
> @@ -43,6 +43,7 @@
> ?static struct omap_hwmod omap44xx_dma_system_hwmod;
> ?static struct omap_hwmod omap44xx_dmm_hwmod;
> ?static struct omap_hwmod omap44xx_dsp_hwmod;
> +static struct omap_hwmod omap44xx_dss_hwmod;
I guess we agreed to name this dss_core - any specific reason to change it?
Best regards,
~Sumit.
<snip>
^ permalink raw reply
* [PATCH V3 3/4] ARM: Xilinx: base header files and assembly macros
From: Arnd Bergmann @ 2011-02-17 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <71326bcb-7836-4820-84c1-f3d8257e9f92@VA3EHSMHS020.ehs.local>
On Thursday 17 February 2011, John Linn wrote:
> > > +
> > > +#define UART_FIFO_WRITE(base, value) \
> > > + (*(volatile unsigned int *)((base) + UART_FIFO_OFFSET) =
> (value))
> > > +
> > > +#define UART_STATUS(base) \
> > > + (*(volatile unsigned int *)((base) + UART_SR_OFFSET))
> >
> > You could probably make these static inline functions in the header
> and
> > use __raw_{readl,writel}() to make this a little cleaner.
> >
>
> I had considered that, but it wasn't clear to me at the time what the
> compressor could use or not.
>
> I'll give it a try as I agree that's cleaner.
Actually, for correctness you should use the regular readl/writel, not
the __raw_ versions, which can result in reordered or partial accesses
on the bus.
Arnd
^ permalink raw reply
* [PATCH] mach-ux500: basic HREFv60 support v2
From: Linus Walleij @ 2011-02-17 14:40 UTC (permalink / raw)
To: linux-arm-kernel
From: Linus Walleij <linus.walleij@linaro.org>
The HREFv60 variant of the MOP500 family of boards remove the
external GPIO expander and route these pins back to some of the
readily available internal GPIO pins instead.
Based on a patch by Bibek Basu <bibek.basu@stericsson.com> for
an internal kernel version.
Cc: Bibek Basu <bibek.basu@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Re-spin when I realized that I was adding the GPIO pins for
HREFv60 in an init function connected to the Toshiba GPIO
expander just removed from the board. Fix it up the right way
instead, hopefully.
---
arch/arm/mach-ux500/board-mop500-sdi.c | 42 +++++++++++++++++++-----
arch/arm/mach-ux500/board-mop500-stuib.c | 12 ++++++-
arch/arm/mach-ux500/board-mop500.c | 23 ++++++++++++--
arch/arm/mach-ux500/board-mop500.h | 14 ++++++++-
arch/arm/mach-ux500/include/mach/uncompress.h | 6 +++-
5 files changed, 81 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-ux500/board-mop500-sdi.c b/arch/arm/mach-ux500/board-mop500-sdi.c
index 68c8375..bf0b024 100644
--- a/arch/arm/mach-ux500/board-mop500-sdi.c
+++ b/arch/arm/mach-ux500/board-mop500-sdi.c
@@ -12,6 +12,7 @@
#include <linux/mmc/host.h>
#include <linux/platform_device.h>
+#include <asm/mach-types.h>
#include <plat/ste_dma40.h>
#include <mach/devices.h>
#include <mach/hardware.h>
@@ -68,7 +69,6 @@ static struct mmci_platform_data mop500_sdi0_data = {
.ocr_mask = MMC_VDD_29_30,
.f_max = 100000000,
.capabilities = MMC_CAP_4_BIT_DATA,
- .gpio_cd = GPIO_SDMMC_CD,
.gpio_wp = -1,
#ifdef CONFIG_STE_DMA40
.dma_filter = stedma40_filter,
@@ -77,23 +77,40 @@ static struct mmci_platform_data mop500_sdi0_data = {
#endif
};
-void mop500_sdi_tc35892_init(void)
+/* GPIO pins used by the sdi0 level shifter */
+static int sdi0_en = -1;
+static int sdi0_vsel = -1;
+
+static void sdi0_configure(void)
{
int ret;
- ret = gpio_request(GPIO_SDMMC_EN, "SDMMC_EN");
+ ret = gpio_request(sdi0_en, "level shifter enable");
if (!ret)
- ret = gpio_request(GPIO_SDMMC_1V8_3V_SEL,
- "GPIO_SDMMC_1V8_3V_SEL");
- if (ret)
+ ret = gpio_request(sdi0_vsel,
+ "level shifter 1v8-3v select");
+
+ if (ret) {
+ pr_warning("unable to config sdi0 gpios for level shifter.\n");
return;
+ }
- gpio_direction_output(GPIO_SDMMC_1V8_3V_SEL, 0);
- gpio_direction_output(GPIO_SDMMC_EN, 1);
+ /* Select the default 2.9V and enable level shifter */
+ gpio_direction_output(sdi0_vsel, 0);
+ gpio_direction_output(sdi0_en, 1);
+ /* Add the device */
db8500_add_sdi0(&mop500_sdi0_data);
}
+void mop500_sdi_tc35892_init(void)
+{
+ mop500_sdi0_data.gpio_cd = GPIO_SDMMC_CD;
+ sdi0_en = GPIO_SDMMC_EN;
+ sdi0_vsel = GPIO_SDMMC_1V8_3V_SEL;
+ sdi0_configure();
+}
+
/*
* SDI 2 (POP eMMC, not on DB8500ed)
*/
@@ -179,8 +196,15 @@ void __init mop500_sdi_init(void)
/* On-board eMMC */
db8500_add_sdi4(&mop500_sdi4_data);
+ if (machine_is_hrefv60()) {
+ mop500_sdi0_data.gpio_cd = HREFV60_SDMMC_CD_GPIO;
+ sdi0_en = HREFV60_SDMMC_EN_GPIO;
+ sdi0_vsel = HREFV60_SDMMC_1V8_3V_GPIO;
+ sdi0_configure();
+ }
/*
- * sdi0 will finally be added when the TC35892 initializes and calls
+ * On boards with the TC35892 GPIO expander, sdi0 will finally
+ * be added when the TC35892 initializes and calls
* mop500_sdi_tc35892_init() above.
*/
}
diff --git a/arch/arm/mach-ux500/board-mop500-stuib.c b/arch/arm/mach-ux500/board-mop500-stuib.c
index 8b6323e..8c97977 100644
--- a/arch/arm/mach-ux500/board-mop500-stuib.c
+++ b/arch/arm/mach-ux500/board-mop500-stuib.c
@@ -12,6 +12,7 @@
#include <linux/interrupt.h>
#include <linux/i2c.h>
#include <linux/input/matrix_keypad.h>
+#include <asm/mach-types.h>
#include "board-mop500.h"
@@ -154,7 +155,6 @@ static struct bu21013_platform_device tsc_plat_device = {
.cs_dis = bu21013_gpio_board_exit,
.irq_read_val = bu21013_read_pin_val,
.irq = NOMADIK_GPIO_TO_IRQ(TOUCH_GPIO_PIN),
- .cs_pin = GPIO_BU21013_CS,
.touch_x_max = TOUCH_XMAX,
.touch_y_max = TOUCH_YMAX,
.ext_clk = false,
@@ -167,7 +167,6 @@ static struct bu21013_platform_device tsc_plat2_device = {
.cs_dis = bu21013_gpio_board_exit,
.irq_read_val = bu21013_read_pin_val,
.irq = NOMADIK_GPIO_TO_IRQ(TOUCH_GPIO_PIN),
- .cs_pin = GPIO_BU21013_CS,
.touch_x_max = TOUCH_XMAX,
.touch_y_max = TOUCH_YMAX,
.ext_clk = false,
@@ -189,6 +188,15 @@ static struct i2c_board_info __initdata u8500_i2c3_devices_stuib[] = {
void __init mop500_stuib_init(void)
{
+ if (machine_is_hrefv60()) {
+ tsc_plat_device.cs_pin = HREFV60_TOUCH_RST_GPIO;
+ tsc_plat2_device.cs_pin = HREFV60_TOUCH_RST_GPIO;
+ } else {
+ tsc_plat_device.cs_pin = GPIO_BU21013_CS;
+ tsc_plat2_device.cs_pin = GPIO_BU21013_CS;
+
+ }
+
mop500_uib_i2c_add(0, mop500_i2c0_devices_stuib,
ARRAY_SIZE(mop500_i2c0_devices_stuib));
diff --git a/arch/arm/mach-ux500/board-mop500.c b/arch/arm/mach-ux500/board-mop500.c
index 72448e1..8790d98 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -202,7 +202,6 @@ static struct gpio_keys_button mop500_gpio_keys[] = {
.desc = "SFH7741 Proximity Sensor",
.type = EV_SW,
.code = SW_FRONT_PROXIMITY,
- .gpio = GPIO_PROX_SENSOR,
.active_low = 0,
.can_disable = 1,
}
@@ -379,8 +378,18 @@ static void __init mop500_uart_init(void)
db8500_add_uart2(&uart2_plat);
}
-static void __init u8500_init_machine(void)
+static void __init mop500_init_machine(void)
{
+ /*
+ * The HREFv60 board removed a GPIO expander and routed
+ * all these GPIO pins to the internal GPIO controller
+ * instead.
+ */
+ if (machine_is_hrefv60())
+ mop500_gpio_keys[0].gpio = HREFV60_PROX_SENSE_GPIO;
+ else
+ mop500_gpio_keys[0].gpio = GPIO_PROX_SENSOR;
+
u8500_init_devices();
mop500_pins_init();
@@ -407,5 +416,13 @@ MACHINE_START(U8500, "ST-Ericsson MOP500 platform")
.init_irq = ux500_init_irq,
/* we re-use nomadik timer here */
.timer = &ux500_timer,
- .init_machine = u8500_init_machine,
+ .init_machine = mop500_init_machine,
+MACHINE_END
+
+MACHINE_START(HREFV60, "ST-Ericsson U8500 Platform HREFv60+")
+ .boot_params = 0x100,
+ .map_io = u8500_map_io,
+ .init_irq = ux500_init_irq,
+ .timer = &ux500_timer,
+ .init_machine = mop500_init_machine,
MACHINE_END
diff --git a/arch/arm/mach-ux500/board-mop500.h b/arch/arm/mach-ux500/board-mop500.h
index 48abca7..56722f4 100644
--- a/arch/arm/mach-ux500/board-mop500.h
+++ b/arch/arm/mach-ux500/board-mop500.h
@@ -7,9 +7,21 @@
#ifndef __BOARD_MOP500_H
#define __BOARD_MOP500_H
-#define MOP500_EGPIO(x) (NOMADIK_NR_GPIO + (x))
+/* HREFv60-specific GPIO assignments, this board has no GPIO expander */
+#define HREFV60_TOUCH_RST_GPIO 143
+#define HREFV60_PROX_SENSE_GPIO 217
+#define HREFV60_HAL_SW_GPIO 145
+#define HREFV60_SDMMC_EN_GPIO 169
+#define HREFV60_SDMMC_1V8_3V_GPIO 5
+#define HREFV60_SDMMC_CD_GPIO 95
+#define HREFV60_ACCEL_INT1_GPIO 82
+#define HREFV60_ACCEL_INT2_GPIO 83
+#define HREFV60_MAGNET_DRDY_GPIO 32
+#define HREFV60_DISP1_RST_GPIO 65
+#define HREFV60_DISP2_RST_GPIO 66
/* GPIOs on the TC35892 expander */
+#define MOP500_EGPIO(x) (NOMADIK_NR_GPIO + (x))
#define GPIO_SDMMC_CD MOP500_EGPIO(3)
#define GPIO_PROX_SENSOR MOP500_EGPIO(7)
#define GPIO_BU21013_CS MOP500_EGPIO(13)
diff --git a/arch/arm/mach-ux500/include/mach/uncompress.h b/arch/arm/mach-ux500/include/mach/uncompress.h
index 9a6614c..ab0fe14 100644
--- a/arch/arm/mach-ux500/include/mach/uncompress.h
+++ b/arch/arm/mach-ux500/include/mach/uncompress.h
@@ -50,7 +50,11 @@ static void flush(void)
static inline void arch_decomp_setup(void)
{
- if (machine_is_u8500())
+ /* Check in run time if we run on an U8500 or U5500 */
+ if (machine_is_u8500() ||
+ machine_is_svp8500v1() ||
+ machine_is_svp8500v2() ||
+ machine_is_hrefv60())
ux500_uart_base = U8500_UART2_BASE;
else if (machine_is_u5500())
ux500_uart_base = U5500_UART0_BASE;
--
1.7.3.2
^ permalink raw reply related
* [PATCH v2 1/3] dmaengine: mxs-dma: add dma support for i.MX23/28
From: Arnd Bergmann @ 2011-02-17 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297650228-12762-2-git-send-email-shawn.guo@freescale.com>
On Monday 14 February 2011, Shawn Guo wrote:
> This patch adds dma support for Freescale MXS-based SoC i.MX23/28,
> including apbh-dma and apbx-dma.
>
> * apbh-dma and apbx-dma are supported in the driver as two instances,
> and have to be filtered by dma clients via device id. It becomes
> the convention that apbh-dma always gets registered prior to
> apbx-dma.
>
> * apbh-dma is different between mx23 and mx28, hardware version
> register is used to handle the differences.
>
> * mxs-dma supports pio function besides data transfer. The driver
> uses dma_data_direction DMA_NONE to identify the pio mode, and
> steals sgl and sg_len to get pio words and numbers from clients.
>
> * mxs dmaengine has some very specific features, like sense function
> and the special NAND support (nand_lock, nand_wait4ready). These
> are too specific to implemented in generic dmaengine driver.
>
> * The driver refers to imx-sdma and only a single descriptor is
> statically assigned to each channel.
Hi Shawn,
I took a look at this after our discussion about the MMC driver locking
problem. My feeling is that you still need to get a better understanding
of the locking interfaces in Linux.
> +struct mxs_dma_ccw {
> + u32 next;
> + u16 bits;
> + u16 xfer_bytes;
> +#define MAX_XFER_BYTES 0xff00
> + dma_addr_t bufaddr;
> +#define MXS_PIO_WORDS 16
> + u32 pio_words[MXS_PIO_WORDS];
> +};
Unrelated, but should bufaddr really be dma_addr_t? If this is a hardware
structure, you should make it u32, because dma_addr_t may be either 32 or
64 bit in the future, as we get to multiplatform kernels.
> +struct mxs_dma_chan {
> + struct mxs_dma_engine *mxs_dma;
> + struct dma_chan chan;
> + struct dma_async_tx_descriptor desc;
> + struct tasklet_struct tasklet;
> + spinlock_t lock;
> + int chan_irq;
> + struct mxs_dma_ccw *ccw;
> + dma_addr_t ccw_phys;
> + dma_cookie_t last_completed;
> + enum dma_status status;
> + unsigned int flags;
> +#define MXS_DMA_SG_LOOP (1 << 0)
> +};
> +
> +struct mxs_dma_engine {
> + int dev_id;
> + unsigned int version;
> + void __iomem *base;
> + struct clk *clk;
> + struct dma_device dma_device;
> + struct device_dma_parameters dma_parms;
> +#define MXS_DMA_CHANNELS 16
> + struct mxs_dma_chan mxs_chans[MXS_DMA_CHANNELS];
> +};
So you have locking per channel, but there is no lock in the dma engine
structure locking the global fields. This is probably fine.
> +static void mxs_dma_reset_chan(struct mxs_dma_chan *mxs_chan)
> +{
> + struct mxs_dma_engine *mxs_dma = mxs_chan->mxs_dma;
> + int chan_id = mxs_chan->chan.chan_id;
> +
> + if (dma_is_apbh() && apbh_is_old())
> + __mxs_setl(1 << (chan_id + BP_APBH_CTRL0_RESET_CHANNEL),
> + mxs_dma->base + HW_APBHX_CTRL0);
> + else
> + __mxs_setl(1 << (chan_id + BP_APBHX_CHANNEL_CTRL_RESET_CHANNEL),
> + mxs_dma->base + HW_APBHX_CHANNEL_CTRL);
> +}
> +
> +static void mxs_dma_enable_chan(struct mxs_dma_chan *mxs_chan)
> +{
> + struct mxs_dma_engine *mxs_dma = mxs_chan->mxs_dma;
> + int chan_id = mxs_chan->chan.chan_id;
> +
> + /* set cmd_addr up */
> + __raw_writel(mxs_chan->ccw_phys,
> + mxs_dma->base + HW_APBHX_CHn_NXTCMDAR(chan_id));
> +
> + /* enable apbh channel clock */
> + if (dma_is_apbh()) {
> + if (apbh_is_old())
> + __mxs_clrl(1 << (chan_id + BP_APBH_CTRL0_CLKGATE_CHANNEL),
> + mxs_dma->base + HW_APBHX_CTRL0);
> + else
> + __mxs_clrl(1 << chan_id, mxs_dma->base + HW_APBHX_CTRL0);
> + }
> +
> + /* write 1 to SEMA to kick off the channel */
> + __raw_writel(1, mxs_dma->base + HW_APBHX_CHn_SEMA(chan_id));
> +}
Just like the MMC driver, you also use __raw_writel(). If you have to do
that, please encapsulate the access into a wrapper function that adds
all the necessary serialization and add a comment explaining why you
cannot use writel()/writel_relaxed().
Or just use writel().
> +static void mxs_dma_disable_chan(struct mxs_dma_chan *mxs_chan)
> +{
> + struct mxs_dma_engine *mxs_dma = mxs_chan->mxs_dma;
> + int chan_id = mxs_chan->chan.chan_id;
> +
> + /* disable apbh channel clock */
> + if (dma_is_apbh()) {
> + if (apbh_is_old())
> + __mxs_setl(1 << (chan_id + BP_APBH_CTRL0_CLKGATE_CHANNEL),
> + mxs_dma->base + HW_APBHX_CTRL0);
> + else
> + __mxs_setl(1 << chan_id, mxs_dma->base + HW_APBHX_CTRL0);
> + }
> +
> + mxs_chan->status = DMA_SUCCESS;
> +}
> +
> +static void mxs_dma_pause_chan(struct mxs_dma_chan *mxs_chan)
> +{
> + struct mxs_dma_engine *mxs_dma = mxs_chan->mxs_dma;
> + int chan_id = mxs_chan->chan.chan_id;
> +
> + /* freeze the channel */
> + if (dma_is_apbh() && apbh_is_old())
> + __mxs_setl(1 << chan_id, mxs_dma->base + HW_APBHX_CTRL0);
> + else
> + __mxs_setl(1 << chan_id, mxs_dma->base + HW_APBHX_CHANNEL_CTRL);
> +
> + mxs_chan->status = DMA_PAUSED;
> +}
> +
> +static void mxs_dma_resume_chan(struct mxs_dma_chan *mxs_chan)
> +{
> + struct mxs_dma_engine *mxs_dma = mxs_chan->mxs_dma;
> + int chan_id = mxs_chan->chan.chan_id;
> +
> + /* unfreeze the channel */
> + if (dma_is_apbh() && apbh_is_old())
> + __mxs_clrl(1 << chan_id, mxs_dma->base + HW_APBHX_CTRL0);
> + else
> + __mxs_clrl(1 << chan_id, mxs_dma->base + HW_APBHX_CHANNEL_CTRL);
> +
> + mxs_chan->status = DMA_IN_PROGRESS;
> +}
Should these take the spinlock? What if they are called simultaneously on
multiple CPUs, or while the interrupt handler is running on another CPU?
Without a lock, another thread might see an incorrect value of mxs_chan->status.
> +static dma_cookie_t mxs_dma_assign_cookie(struct mxs_dma_chan *mxs_chan)
> +{
> + dma_cookie_t cookie = mxs_chan->chan.cookie;
> +
> + if (++cookie < 0)
> + cookie = 1;
> +
> + mxs_chan->chan.cookie = cookie;
> + mxs_chan->desc.cookie = cookie;
> +
> + return cookie;
> +}
> +
> +static struct mxs_dma_chan *to_mxs_dma_chan(struct dma_chan *chan)
> +{
> + return container_of(chan, struct mxs_dma_chan, chan);
> +}
> +
> +static dma_cookie_t mxs_dma_tx_submit(struct dma_async_tx_descriptor *tx)
> +{
> + struct mxs_dma_chan *mxs_chan = to_mxs_dma_chan(tx->chan);
> + dma_cookie_t cookie;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&mxs_chan->lock, flags);
> +
> + cookie = mxs_dma_assign_cookie(mxs_chan);
> +
> + mxs_dma_enable_chan(mxs_chan);
> +
> + spin_unlock_irqrestore(&mxs_chan->lock, flags);
> +
> + return cookie;
> +}
Just like the MMC driver, you use spin_lock_irqsave() in the functions that
are called by other drivers, but then don't actually lock in the interrupt
handler. This is clearly wrong, as I explained before:
The interrupt handler may already be running on another CPU, so it
is not at all serialized with this code.
> +static void mxs_dma_tasklet(unsigned long data)
> +{
> + struct mxs_dma_chan *mxs_chan = (struct mxs_dma_chan *) data;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&mxs_chan->lock, flags);
> +
> + if (mxs_chan->desc.callback)
> + mxs_chan->desc.callback(mxs_chan->desc.callback_param);
> +
> + if (mxs_chan->status == DMA_SUCCESS)
> + mxs_chan->last_completed = mxs_chan->desc.cookie;
> +
> + spin_unlock_irqrestore(&mxs_chan->lock, flags);
> +}
Here is a different problem. The entire tasklet has interrupts
disabled and holds the spinlock that the interrupt handler does
not hold.
This actually makes the tasklet a stricter context than the
actual interrupt handler, defeating the purpose of tasklets
(i.e. that you can run code without disabling interrupts).
I don't know what the rules for dmaengine callbacks are regarding
the context in which they are called, but it seems you should
either get rid of the spin_lock_irqsave here or do everything
from the interrupt handler.
That leaves the last_completed variable. This apparently
needs to be protected using a spinlock, because
it can be read from other tasks calling mxs_dma_tx_status,
which in turn does not take the lock, so that is broken, too.
Arnd
^ permalink raw reply
* [PATCH V3 3/4] ARM: Xilinx: base header files and assembly macros
From: John Linn @ 2011-02-17 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110217100126.GD22961@pulham.picochip.com>
> -----Original Message-----
> From: Jamie Iles [mailto:jamie at jamieiles.com]
> Sent: Thursday, February 17, 2011 3:01 AM
> To: John Linn
> Cc: linux-arm-kernel at lists.infradead.org;
linux-kernel at vger.kernel.org; linux at arm.linux.org.uk;
> catalin.marinas at arm.com; glikely at secretlab.ca; arnd at arndb.de
> Subject: Re: [PATCH V3 3/4] ARM: Xilinx: base header files and
assembly macros
>
> Hi John,
>
> A few more nitpicks, but looking good now!
>
> Jamie
>
> On Wed, Feb 16, 2011 at 09:11:55AM -0700, John Linn wrote:
> > These are the minimum needed to build the kernel for the new
platform.
> >
> > Signed-off-by: John Linn <john.linn@xilinx.com>
> > ---
> >
> > V3 Changes
> >
> > Updates based on Russell Kings' comments
> > Changed headers to update the license info and remove
> > the address
> >
> > Updated the constant to use UL in vmalloc.h
> >
> > V2 Changes
> >
> > Updates based on Russell King's comments
> > moved to using entry-macro-gic.S
> > moved stuff from hardware.h to xilinx_soc.h
> > added IOMEM() in io.h to help with typing
> > Minor updates to IO_SPACE_LIMIT and __io()
> > Updated addresses to be clear with seperate virtual
> > and physical addresses
> >
> > arch/arm/mach-xilinx/include/mach/clkdev.h | 33
++++++++++++++++
> > arch/arm/mach-xilinx/include/mach/debug-macro.S | 36
+++++++++++++++++
> > arch/arm/mach-xilinx/include/mach/entry-macro.S | 30
++++++++++++++
> > arch/arm/mach-xilinx/include/mach/hardware.h | 18 +++++++++
> > arch/arm/mach-xilinx/include/mach/io.h | 33
++++++++++++++++
> > arch/arm/mach-xilinx/include/mach/irqs.h | 29
++++++++++++++
> > arch/arm/mach-xilinx/include/mach/memory.h | 23 +++++++++++
> > arch/arm/mach-xilinx/include/mach/system.h | 28
+++++++++++++
> > arch/arm/mach-xilinx/include/mach/timex.h | 24 ++++++++++++
> > arch/arm/mach-xilinx/include/mach/uart.h | 31
+++++++++++++++
> > arch/arm/mach-xilinx/include/mach/uncompress.h | 47
+++++++++++++++++++++++
> > arch/arm/mach-xilinx/include/mach/vmalloc.h | 20 ++++++++++
> > arch/arm/mach-xilinx/include/mach/xilinx_soc.h | 46
++++++++++++++++++++++
> > 13 files changed, 398 insertions(+), 0 deletions(-)
> > create mode 100644 arch/arm/mach-xilinx/include/mach/clkdev.h
> > create mode 100644 arch/arm/mach-xilinx/include/mach/debug-macro.S
> > create mode 100644 arch/arm/mach-xilinx/include/mach/entry-macro.S
> > create mode 100644 arch/arm/mach-xilinx/include/mach/hardware.h
> > create mode 100644 arch/arm/mach-xilinx/include/mach/io.h
> > create mode 100644 arch/arm/mach-xilinx/include/mach/irqs.h
> > create mode 100644 arch/arm/mach-xilinx/include/mach/memory.h
> > create mode 100644 arch/arm/mach-xilinx/include/mach/system.h
> > create mode 100644 arch/arm/mach-xilinx/include/mach/timex.h
> > create mode 100644 arch/arm/mach-xilinx/include/mach/uart.h
> > create mode 100644 arch/arm/mach-xilinx/include/mach/uncompress.h
> > create mode 100644 arch/arm/mach-xilinx/include/mach/vmalloc.h
> > create mode 100644 arch/arm/mach-xilinx/include/mach/xilinx_soc.h
> >
> > diff --git a/arch/arm/mach-xilinx/include/mach/clkdev.h
b/arch/arm/mach-xilinx/include/mach/clkdev.h
> > new file mode 100644
> > index 0000000..5dd1453
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/clkdev.h
> > @@ -0,0 +1,33 @@
> > +/*
> > + * arch/arm/mach-xilinx/include/mach/clkdev.h
> > + *
> > + * Copyright (C) 2011 Xilinx, Inc.
> > + *
> > + * This software is licensed under the terms of the GNU General
Public
> > + * License version 2, as published by the Free Software Foundation,
and
> > + * may be copied, distributed, and modified under those terms.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + *
> > + */
> > +
> > +#ifndef __MACH_CLKDEV_H__
> > +#define __MACH_CLKDEV_H__
> > +
> > +struct clk {
> > + unsigned long rate;
> > +};
> > +
> > +static inline int __clk_get(struct clk *clk)
> > +{
> > + return 1;
> > +}
> > +
> > +static inline void __clk_put(struct clk *clk)
> > +{
> > +}
> > +
> > +#endif
> > diff --git a/arch/arm/mach-xilinx/include/mach/debug-macro.S
b/arch/arm/mach-
> xilinx/include/mach/debug-macro.S
> > new file mode 100644
> > index 0000000..30d3d3d
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/debug-macro.S
> > @@ -0,0 +1,36 @@
> > +/* arch/arm/mach-xilinx/include/mach/debug-macro.S
> > + *
> > + * Debugging macro include header
> > + *
> > + * Copyright (C) 2011 Xilinx
> > + *
> > + * This software is licensed under the terms of the GNU General
Public
> > + * License version 2, as published by the Free Software Foundation,
and
> > + * may be copied, distributed, and modified under those terms.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include <mach/xilinx_soc.h>
> > +#include <mach/uart.h>
> > +
> > + .macro addruart, rp, rv
> > + ldr \rp, =LL_UART_PADDR @ physical
> > + ldr \rv, =LL_UART_VADDR @ virtual
> > + .endm
> > +
> > + .macro senduart,rd,rx
> > + str \rd, [\rx, #UART_FIFO_OFFSET] @ TXDATA
> > + .endm
> > +
> > + .macro waituart,rd,rx
> > + .endm
> > +
> > + .macro busyuart,rd,rx
> > +1002: ldr \rd, [\rx, #UART_SR_OFFSET] @ get
status register
> > + tst \rd, #UART_SR_TXFULL @
> > + bne 1002b @ wait if FIFO is full
> > + .endm
> > diff --git a/arch/arm/mach-xilinx/include/mach/entry-macro.S
b/arch/arm/mach-
> xilinx/include/mach/entry-macro.S
> > new file mode 100644
> > index 0000000..11a2866
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/entry-macro.S
> > @@ -0,0 +1,30 @@
> > +/*
> > + * arch/arm/mach-xilinx/include/mach/entry-macro.S
> > + *
> > + * Low-level IRQ helper macros
> > + *
> > + * Copyright (C) 2011 Xilinx
> > + *
> > + * based on arch/plat-mxc/include/mach/entry-macro.S
> > + *
> > + * Copyright (C) 2007 Lennert Buytenhek <buytenh@wantstofly.org>
> > + * Copyright 2004-2007 Freescale Semiconductor, Inc. All Rights
Reserved.
> > + *
> > + * This software is licensed under the terms of the GNU General
Public
> > + * License version 2, as published by the Free Software Foundation,
and
> > + * may be copied, distributed, and modified under those terms.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include <mach/hardware.h>
> > +#include <asm/hardware/entry-macro-gic.S>
> > +
> > + .macro disable_fiq
> > + .endm
> > +
> > + .macro arch_ret_to_user, tmp1, tmp2
> > + .endm
> > diff --git a/arch/arm/mach-xilinx/include/mach/hardware.h
b/arch/arm/mach-
> xilinx/include/mach/hardware.h
> > new file mode 100644
> > index 0000000..f9685c4
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/hardware.h
> > @@ -0,0 +1,18 @@
> > +/* arch/arm/mach-xilinx/include/mach/hardware.h
> > + *
> > + * Copyright (C) 2011 Xilinx
> > + *
> > + * This software is licensed under the terms of the GNU General
Public
> > + * License version 2, as published by the Free Software Foundation,
and
> > + * may be copied, distributed, and modified under those terms.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#ifndef __MACH_HARDWARE_H__
> > +#define __MACH_HARDWARE_H__
> > +
> > +#endif
> > diff --git a/arch/arm/mach-xilinx/include/mach/io.h
b/arch/arm/mach-xilinx/include/mach/io.h
> > new file mode 100644
> > index 0000000..ef69e65
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/io.h
> > @@ -0,0 +1,33 @@
> > +/* arch/arm/mach-xilinx/include/mach/io.h
> > + *
> > + * Copyright (C) 2011 Xilinx
> > + *
> > + * This software is licensed under the terms of the GNU General
Public
> > + * License version 2, as published by the Free Software Foundation,
and
> > + * may be copied, distributed, and modified under those terms.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#ifndef __MACH_IO_H__
> > +#define __MACH_IO_H__
> > +
> > +/* Allow IO space to be anywhere in the memory */
> > +
> > +#define IO_SPACE_LIMIT 0xffff
> > +
> > +/* IO address mapping macros, nothing special at this time but
required */
> > +
> > +#ifdef __ASSEMBLER__
> > +#define IOMEM(x) (x)
> > +#else
> > +#define IOMEM(x) ((void __force __iomem *)(x))
> > +#endif
> > +
> > +#define __io(a) __typesafe_io(a)
> > +#define __mem_pci(a) (a)
> > +
> > +#endif
> > diff --git a/arch/arm/mach-xilinx/include/mach/irqs.h
b/arch/arm/mach-xilinx/include/mach/irqs.h
> > new file mode 100644
> > index 0000000..47a8162
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/irqs.h
> > @@ -0,0 +1,29 @@
> > +/* arch/arm/mach-xilinx/include/mach/irqs.h
> > + *
> > + * Copyright (C) 2011 Xilinx
> > + *
> > + * This software is licensed under the terms of the GNU General
Public
> > + * License version 2, as published by the Free Software Foundation,
and
> > + * may be copied, distributed, and modified under those terms.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#ifndef __MACH_IRQS_H
> > +#define __MACH_IRQS_H
> > +
> > +#define ARCH_NR_GPIOS 118
> > +#define NR_IRQS (128 + ARCH_NR_GPIOS)
> > +
> > +/*
> > + * GIC Interrupts
> > + */
> > +
> > +#define IRQ_GIC_SPI_START 32
> > +#define IRQ_TIMERCOUNTER0 42
> > +#define IRQ_UART0 59
> > +
> > +#endif
> > diff --git a/arch/arm/mach-xilinx/include/mach/memory.h
b/arch/arm/mach-xilinx/include/mach/memory.h
> > new file mode 100644
> > index 0000000..c200486
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/memory.h
> > @@ -0,0 +1,23 @@
> > +/* arch/arm/mach-xilinx/include/mach/memory.h
> > + *
> > + * Copyright (C) 2011 Xilinx
> > + *
> > + * This software is licensed under the terms of the GNU General
Public
> > + * License version 2, as published by the Free Software Foundation,
and
> > + * may be copied, distributed, and modified under those terms.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#ifndef __MACH_MEMORY_H__
> > +#define __MACH_MEMORY_H__
> > +
> > +#include <mach/hardware.h>
> > +
> > +#define PHYS_OFFSET 0x0
>
> This should be PLAT_PHYS_OFFSET and could do with being surrounded
with
> UL() e.g.
>
> #define PLAT_PHYS_OFFSET UL(0x00000000)
I think Russell mentioned it was changing in the future but I didn't
know when to do it.
Easy enough.
>
> > +#define MEM_SIZE SZ_256M
> > +
> > +#endif
> > diff --git a/arch/arm/mach-xilinx/include/mach/system.h
b/arch/arm/mach-xilinx/include/mach/system.h
> > new file mode 100644
> > index 0000000..e8514a0
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/system.h
> > @@ -0,0 +1,28 @@
> > +/* arch/arm/mach-xilinx/include/mach/system.h
> > + *
> > + * Copyright (C) 2011 Xilinx
> > + *
> > + * This software is licensed under the terms of the GNU General
Public
> > + * License version 2, as published by the Free Software Foundation,
and
> > + * may be copied, distributed, and modified under those terms.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#ifndef __MACH_SYSTEM_H__
> > +#define __MACH_SYSTEM_H__
> > +
> > +static inline void arch_idle(void)
> > +{
> > + cpu_do_idle();
> > +}
> > +
> > +static inline void arch_reset(char mode, const char *cmd)
> > +{
> > + /* Add architecture specific reset processing here */
>
> I think you can add cpu_reset(0) in here to try a soft reset by
jumping
> to the reset vector. This should give you some reset functionality.
>
Will look at that. I think it requires a lot more than that for our
platform to clean up.
> > +}
> > +
> > +#endif
> > diff --git a/arch/arm/mach-xilinx/include/mach/timex.h
b/arch/arm/mach-xilinx/include/mach/timex.h
> > new file mode 100644
> > index 0000000..6765e15
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/timex.h
> > @@ -0,0 +1,24 @@
> > +/* arch/arm/mach-xilinx/include/mach/timex.h
> > + *
> > + * Copyright (C) 2011 Xilinx
> > + *
> > + * This software is licensed under the terms of the GNU General
Public
> > + * License version 2, as published by the Free Software Foundation,
and
> > + * may be copied, distributed, and modified under those terms.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#ifndef __MACH_TIMEX_H__
> > +#define __MACH_TIMEX_H__
> > +
> > +#include <mach/hardware.h>
>
> I don't think you need mach/hardware.h included in here.
>
Looks like that's true. I should have caught that.
> > +
> > +#define PERIPHERAL_CLOCK_RATE 2500000
> > +
> > +#define CLOCK_TICK_RATE (PERIPHERAL_CLOCK_RATE / 32)
> > +
> > +#endif
> > diff --git a/arch/arm/mach-xilinx/include/mach/uart.h
b/arch/arm/mach-xilinx/include/mach/uart.h
> > new file mode 100644
> > index 0000000..20a10d7
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/uart.h
> > @@ -0,0 +1,31 @@
> > +/* arch/arm/mach-xilinx/include/mach/uart.h
> > + *
> > + * Copyright (C) 2011 Xilinx
> > + *
> > + * This software is licensed under the terms of the GNU General
Public
> > + * License version 2, as published by the Free Software Foundation,
and
> > + * may be copied, distributed, and modified under those terms.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#ifndef __MACH_UART_H__
> > +#define __MACH_UART_H__
> > +
> > +#define UART_CR_OFFSET 0x00 /* Control Register [8:0] */
> > +#define UART_SR_OFFSET 0x2C /* Channel Status [11:0] */
> > +#define UART_FIFO_OFFSET 0x30 /* FIFO [15:0] or [7:0] */
> > +
> > +#define UART_SR_TXFULL 0x00000010 /* TX FIFO full
*/
> > +#define UART_SR_TXEMPTY 0x00000008 /* TX FIFO empty
*/
> > +
> > +#define UART_FIFO_WRITE(base, value) \
> > + (*(volatile unsigned int *)((base) + UART_FIFO_OFFSET) =
(value))
> > +
> > +#define UART_STATUS(base) \
> > + (*(volatile unsigned int *)((base) + UART_SR_OFFSET))
>
> You could probably make these static inline functions in the header
and
> use __raw_{readl,writel}() to make this a little cleaner.
>
I had considered that, but it wasn't clear to me at the time what the
compressor could use or not.
I'll give it a try as I agree that's cleaner.
> > +
> > +#endif
> > diff --git a/arch/arm/mach-xilinx/include/mach/uncompress.h
b/arch/arm/mach-
> xilinx/include/mach/uncompress.h
> > new file mode 100644
> > index 0000000..b7a5110
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/uncompress.h
> > @@ -0,0 +1,47 @@
> > +/* arch/arm/mach-xilinx/include/mach/uncompress.h
> > + *
> > + * Copyright (C) 2011 Xilinx
> > + *
> > + * This software is licensed under the terms of the GNU General
Public
> > + * License version 2, as published by the Free Software Foundation,
and
> > + * may be copied, distributed, and modified under those terms.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#ifndef __MACH_UNCOMPRESS_H__
> > +#define __MACH_UNCOMPRESS_H__
> > +
> > +#include <mach/xilinx_soc.h>
> > +#include <mach/uart.h>
> > +
> > +void arch_decomp_setup(void)
> > +{
> > +}
> > +
> > +static inline void flush(void)
> > +{
> > + /*
> > + * Wait while the FIFO is not empty
> > + */
> > + while (!(UART_STATUS(LL_UART_PADDR) & UART_SR_TXEMPTY))
> > + ;
> > +}
> > +
> > +#define arch_decomp_wdog()
> > +
> > +static void putc(char ch)
> > +{
> > + /*
> > + * Wait for room in the FIFO, then write the char into the FIFO
> > + */
> > + while (UART_STATUS(LL_UART_PADDR) & UART_SR_TXFULL)
> > + ;
>
> It might be worth adding a barrier() call to these loops to be
explicit
> about the volatility.
OK
I appreciate all your help and time to review, both you and Russell. I'm
learning a lot and it's much
cleaner too.
I hope there's an ack in the near future :)
Thanks
John
>
> > +
> > + UART_FIFO_WRITE(LL_UART_PADDR, ch);
> > +}
> > +
> > +#endif
> > diff --git a/arch/arm/mach-xilinx/include/mach/vmalloc.h
b/arch/arm/mach-
> xilinx/include/mach/vmalloc.h
> > new file mode 100644
> > index 0000000..aba20a3
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/vmalloc.h
> > @@ -0,0 +1,20 @@
> > +/* arch/arm/mach-xilinx/include/mach/vmalloc.h
> > + *
> > + * Copyright (C) 2011 Xilinx
> > + *
> > + * This software is licensed under the terms of the GNU General
Public
> > + * License version 2, as published by the Free Software Foundation,
and
> > + * may be copied, distributed, and modified under those terms.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#ifndef __MACH_VMALLOC_H__
> > +#define __MACH_VMALLOC_H__
> > +
> > +#define VMALLOC_END 0xE0000000UL
> > +
> > +#endif
> > diff --git a/arch/arm/mach-xilinx/include/mach/xilinx_soc.h
b/arch/arm/mach-
> xilinx/include/mach/xilinx_soc.h
> > new file mode 100644
> > index 0000000..d01cde1
> > --- /dev/null
> > +++ b/arch/arm/mach-xilinx/include/mach/xilinx_soc.h
> > @@ -0,0 +1,46 @@
> > +/* arch/arm/mach-xilinx/include/mach/xilinx_soc.h
> > + *
> > + * Copyright (C) 2011 Xilinx
> > + *
> > + * This software is licensed under the terms of the GNU General
Public
> > + * License version 2, as published by the Free Software Foundation,
and
> > + * may be copied, distributed, and modified under those terms.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#ifndef __MACH_XILINX_SOC_H__
> > +#define __MACH_XILINX_SOC_H__
> > +
> > +/* For now, all mappings are flat (physical = virtual)
> > + */
> > +#define UART0_PHYS 0xE0000000
> > +#define UART0_VIRT UART0_PHYS
> > +
> > +#define TTC0_PHYS 0xF8001000
> > +#define TTC0_VIRT TTC0_PHYS
> > +
> > +#define PL310_L2CC_PHYS 0xF8F02000
> > +#define PL310_L2CC_VIRT PL310_L2CC_PHYS
> > +
> > +#define SCU_PERIPH_PHYS 0xF8F00000
> > +#define SCU_PERIPH_VIRT SCU_PERIPH_PHYS
> > +
> > +/* The following are intended for the devices that are mapped early
*/
> > +
> > +#define TTC0_BASE IOMEM(TTC0_VIRT)
> > +#define SCU_PERIPH_BASE IOMEM(SCU_PERIPH_VIRT)
> > +#define SCU_GIC_CPU_BASE (SCU_PERIPH_BASE + 0x100)
> > +#define SCU_GIC_DIST_BASE (SCU_PERIPH_BASE + 0x1000)
> > +#define PL310_L2CC_BASE IOMEM(PL310_L2CC_VIRT)
> > +
> > +/*
> > + * Mandatory for CONFIG_LL_DEBUG, UART is mapped virtual = physical
> > + */
> > +#define LL_UART_PADDR UART0_PHYS
> > +#define LL_UART_VADDR UART0_VIRT
> > +
> > +#endif
> > --
> > 1.6.2.1
> >
> >
> >
> > This email and any attachments are intended for the sole use of the
named recipient(s) and
> contain(s) confidential information that may be proprietary,
privileged or copyrighted under
> applicable law. If you are not the intended recipient, do not read,
copy, or forward this email
> message or any attachments. Delete this email message and any
attachments immediately.
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe
linux-kernel" in
> > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply
* [patch v2 5/5] mx51: add support for efika smartbook
From: Arnaud Patard (Rtp) @ 2011-02-17 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110217143127.307109680@rtp-net.org>
An embedded and charset-unspecified text was scrubbed...
Name: efikasb.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110217/cc9d1656/attachment.ksh>
^ permalink raw reply
* [patch v2 4/5] efika: enable cpufreq
From: Arnaud Patard (Rtp) @ 2011-02-17 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110217143127.307109680@rtp-net.org>
An embedded and charset-unspecified text was scrubbed...
Name: efikamx_tst_cpufreq.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110217/5a45edbe/attachment.ksh>
^ 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