On Mon, Jan 19, 2009 at 12:23:03PM +0200, Tomi Valkeinen wrote:
> Hi,
>
> Running with latest linux-omap kernel on OMAP3 SDP board, I have problem
> with iounmap(). It looks like iounmap() does not properly free large
> areas. Below is a test which fails for me in 6-7 loops.
>
> OMAP spesific ior
On Mon, Jan 19, 2009 at 02:27:34PM +0200, Tomi Valkeinen wrote:
> On Mon, 2009-01-19 at 11:01 +, ext Russell King - ARM Linux wrote:
> > On Mon, Jan 19, 2009 at 12:23:03PM +0200, Tomi Valkeinen wrote:
> > > Hi,
> > >
> > > Running with latest linux-om
On Mon, Jan 19, 2009 at 07:34:47AM -0600, Woodruff, Richard wrote:
> > Running with latest linux-omap kernel on OMAP3 SDP board, I have problem
> > with iounmap(). It looks like iounmap() does not properly free large
> > areas. Below is a test which fails for me in 6-7 loops.
> >
> > OMAP spesific
On Mon, Jan 19, 2009 at 07:48:09AM -0600, Woodruff, Richard wrote:
>
> > On Mon, Jan 19, 2009 at 07:34:47AM -0600, Woodruff, Richard wrote:
> > > > Running with latest linux-omap kernel on OMAP3 SDP board, I have problem
> > > > with iounmap(). It looks like iounmap() does not properly free large
On Mon, Jan 19, 2009 at 08:06:27AM -0700, Matt Gerassimoff wrote:
> This issue is the reason I have subscribed to the mailing list. I have
> discovered the problem and had a quick patch to solve it.
It's not a solution, it's a work-around. You're not seeing the problem
anymore because you've c
On Mon, Jan 19, 2009 at 08:39:39AM -0700, Matt Gerassimoff wrote:
> >>But without that code, everything works 100%. I'm not sure what all the
> >>remap_area_sections()
> >>code does, but the cleanup definitely does not work, as the kernel OOPS
> >>will testify.
> >>There may be a better solution,
On Mon, Jan 19, 2009 at 03:58:57PM +, Russell King - ARM Linux wrote:
> On Mon, Jan 19, 2009 at 08:39:39AM -0700, Matt Gerassimoff wrote:
> > >>But without that code, everything works 100%. I'm not sure what all the
> > >>remap_area_sections()
> > >&g
On Tue, Jan 13, 2009 at 12:30:02PM +0200, Tony Lindgren wrote:
> * Russell King - ARM Linux [090112 18:47]:
> > On Mon, Jan 12, 2009 at 08:24:42AM +0200, Tony Lindgren wrote:
> > > * Russell King - ARM Linux [090111 12:15]:
> > > > On Sat, Jan 10, 2009 at 11:05:
On Mon, Jan 19, 2009 at 10:07:13AM -0700, Matt Gerassimoff wrote:
> On Mon, 19 Jan 2009 09:13:58 -0700, Russell King - ARM Linux
> wrote:
>
> >diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
> >index 18373f7..9f88dd3 100644
> >--- a/arch/arm/mm/ior
On Mon, Jan 19, 2009 at 11:44:07AM +0200, Hiroshi DOYU wrote:
> Hi David,
>
> From: "ext David Brownell"
> Subject: Re: [PATCH 1/6] omap iommu: tlb and pagetable primitives
> Date: Sat, 17 Jan 2009 12:48:45 -0800
>
> > On Saturday 17 January 2009, Russell King
On Mon, Jan 19, 2009 at 12:36:12PM +0200, Hiroshi DOYU wrote:
> Hi Russell, Thank you for your review.
>
> From: "ext Russell King - ARM Linux"
> Subject: Re: [PATCH 07/10] omap mailbox: add save_/restore_ctx() for PM
> Date: Sat, 17 Jan 2009 17:20:37 +
>
>
At the moment:
ldp_smc911x_resources[0].start = cs_mem_base + 0x0;
ldp_smc911x_resources[0].end = cs_mem_base + 0xf;
However, the SMC911x driver wants to claim 256 bytes from this region.
Indeed, its register set definitions appears to indicate that its needs
more than 16 bytes
On Tue, Jan 20, 2009 at 02:36:43PM +0800, stanley.miao wrote:
> On Mon, 2009-01-19 at 22:37 +0000, Russell King - ARM Linux wrote:
> > At the moment:
> >
> > ldp_smc911x_resources[0].start = cs_mem_base + 0x0;
> > ldp_smc911x_resources[0
On Mon, Jan 19, 2009 at 03:49:40PM +0200, Tomi Valkeinen wrote:
> The original problem remains, it looks to me that iounmap() doesn't free
> the memory, and thus ioremap will fail after couple of loops.
>
> I get the following error on console:
>
> vmap allocation for size 16781312 failed: use vm
A question about OMAP1 mcbsp clocks. From what I understand from the
OMAP5912 clock architecture documentation, mcbsp1 and mcbsp3 have two
clocks:
1. interface clock switchable between DSPPER_CK and DSPXOR_CK.
2. a function clock which could be DSPXOR_CK (mcbsp3), and
CK_DPLL1OUT or MCBS1_CLKS
On Fri, Jan 23, 2009 at 11:18:37AM -0600, Hunter, Jon wrote:
>...
> So for McBSP1/3 you definitely need to have the MPUI clock enabled.
Thanks - that certainly explains why some of these things are happening
which is most useful. However, the approach I've taken is to keep things
in a similar met
On Thu, Jan 22, 2009 at 05:17:28PM -0800, Tony Lindgren wrote:
> Basically we currently cannot use virtual clocks because of this
> and the fact that the parent of the virtual clock may not be known
> as pointed out by Paul Walmsley.
One other thing I'd like to confirm is how the kernel treats the
All,
In a bid to clean up the clk API implementations, and more importantly
ensure that implementations are using the clk API correctly, I've
converted OMAP over to the generic clock lookup (clkdev) implementation.
In doing so, I've shaken out a number of OMAP quirks and OMAP1 specific
clock code
On Sat, Jan 24, 2009 at 10:41:26AM -0600, Woodruff, Richard wrote:
>
> > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux
>
> > Reviews and comments obviously welcome, testing more preferred. Prob
On Sat, Jan 24, 2009 at 09:04:08AM -0800, Tony Lindgren wrote:
> Russell, can you please post your omap-clks[12] patches here too for review
> so people can look at them? It's ok to post a large series of patches to
> this list.
TBH, I haven't worked out how to get git to sanely do that yet, and
I
On Sat, Jan 24, 2009 at 10:32:29AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux [090124 09:38]:
> > I had given up all hope of ever seeing the omap-clks1 branch in mainline.
> > Really. Until I saw a comment from you about apparantly wanting to see it
> > upstre
Now that the usb_port_suspend() build error is fixed in 2.6.29-rc1-git6,
n770_defconfig and omap_apollon_2420_defconfig now suffers from:
drivers/built-in.o: In function `ohci_omap_init':
hid-quirks.c:(.text+0x6c620): undefined reference to `otg_get_transceiver'
drivers/built-in.o: In function `om
On Tue, Jan 27, 2009 at 11:29:35PM +0200, Hiroshi DOYU wrote:
> I attached the update one.
Thanks. I want to hold off on taking these just a little bit longer.
> +static const struct iommu_platform_data omap3_iommu_pdata[] __initconst = {
> + {
> + .name = "isp",
> +
On Sat, Jan 24, 2009 at 11:01:36AM -0800, Tony Lindgren wrote:
> I'll keep the clks-testing branch updated so we all can test it easily,
> and then we'll just flip linux-omap to use that branch for the clocks
> once everything is merged.
Note that I'm going to rebase the two omap-clks branches to
On Fri, Jan 16, 2009 at 10:27:27AM +0200, Hiroshi DOYU wrote:
> @@ -17,6 +17,8 @@
> #include
> #include
>
> +#define DRV_NAME "omap1-mailbox"
I don't see any need for this define - it just adds an additional level of
indirection when trying to find out the name of the driver. It's only
used
On Wed, Jan 28, 2009 at 07:59:02AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux [090128 02:17]:
> > On Sat, Jan 24, 2009 at 11:01:36AM -0800, Tony Lindgren wrote:
> > > I'll keep the clks-testing branch updated so we all can test it easily,
> > > and th
On Wed, Jan 28, 2009 at 05:29:51PM +0200, Hiroshi DOYU wrote:
> diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
> index 44e9101..af32db0 100644
> --- a/arch/arm/mach-omap2/mailbox.c
> +++ b/arch/arm/mach-omap2/mailbox.c
> @@ -14,7 +14,9 @@
> #include
> #include
> #in
On Wed, Jan 28, 2009 at 10:23:05AM -0800, Tony Lindgren wrote:
> From: Juha Yrjola
>
> At least on OMAP, sched_clock() requires the I/O maps to be initialized.
> Spinlock debugging invokes sched_clock() very early.
NAK. This doesn't and can't work on every platform out there. The
only viable f
On Wed, Jan 28, 2009 at 10:32:09AM -0800, Tony Lindgren wrote:
> From: 김규원
>
> By Ingo Molnar, interrupts are not masked by default.
> (refer to 76d2160147f43f982dfe881404cfde9fd0a9da21)
>
> But if interrupts are not masked, the processor can wake up while in
> Suspend-to-RAM state by an externa
On Wed, Jan 28, 2009 at 10:29:35AM -0800, Tony Lindgren wrote:
> It accidentally broke while changing the name for the driver
> to not to conflict with the other mmc driver.
>
> Signed-off-by: Tony Lindgren
> ---
> arch/arm/plat-omap/devices.c |8 +++-
> 1 files changed, 7 insertions(+),
No other comments on 3,4,5,7 and 9.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jan 28, 2009 at 10:24:22AM -0800, Tony Lindgren wrote:
> From: Stanley.Miao
>
> A spin_lock deadlock will occur when omap_mcbsp_request() is invoked.
>
> omap_mcbsp_request()
> \- clk_enable(mcbsp->clk) [takes and holds clockfw_lock]
> \- omap2_clk_enable()
>\- _omap2
On Wed, Jan 28, 2009 at 09:21:22PM +0200, Hiroshi DOYU wrote:
> It seems that I misunderstood your comment in the following mail.
>
> http://lkml.indiana.edu/hypermail/linux/kernel/0901.2/00610.html
Ah, that comment was more about that specific include in that specific
file - I couldn't see anyth
On Wed, Jan 28, 2009 at 01:22:22PM -0700, Paul Walmsley wrote:
> Per rmk's preferences, some patches have been 'compressed.' That is, some
> fix patches have been rolled into a single patch with the original. To
> ease cross-referencing with the linux-omap git tree, original commit IDs
> have b
Since it's been posted to lists, comments are going to be made...
On Tue, Jan 27, 2009 at 07:12:47PM -0700, Paul Walmsley wrote:
> + /*
> + * According to the 12-5 CDP code from TI, "Limitation 2.5"
> + * on 3430ES1 prevents us from changing DPLL multipliers or dividers
> + * on
On Wed, Jan 28, 2009 at 10:10:56PM +, Russell King - ARM Linux wrote:
> Since it's been posted to lists, comments are going to be made...
>
> On Tue, Jan 27, 2009 at 07:12:47PM -0700, Paul Walmsley wrote:
> > + /*
> > +* According to the 12-5 CDP cod
On Tue, Jan 27, 2009 at 07:13:16PM -0700, Paul Walmsley wrote:
> diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
> index c4b80a4..55c5d67 100644
> --- a/arch/arm/mach-omap2/clock.c
> +++ b/arch/arm/mach-omap2/clock.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
On Thu, Jan 29, 2009 at 12:05:13AM -0700, Paul Walmsley wrote:
> Hello Russell,
>
> On Wed, 28 Jan 2009, Russell King - ARM Linux wrote:
>
> > On Wed, Jan 28, 2009 at 01:22:22PM -0700, Paul Walmsley wrote:
> > > Per rmk's preferences, some patches have been '
On Thu, Jan 29, 2009 at 08:11:17AM +, Russell King - ARM Linux wrote:
> On Thu, Jan 29, 2009 at 12:05:13AM -0700, Paul Walmsley wrote:
> > Hello Russell,
> >
> > On Wed, 28 Jan 2009, Russell King - ARM Linux wrote:
> >
> > > On Wed, Jan 28, 2009 at 0
On Wed, Jan 28, 2009 at 12:08:26PM -0700, Paul Walmsley wrote:
> static int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned long rate)
> {
> u16 freqsel;
> struct dpll_data *dd;
> + int ret;
So 'ret' is a new variable...
>
> if (!clk || !rate)
> retur
On Wed, Jan 28, 2009 at 12:08:29PM -0700, Paul Walmsley wrote:
> The DPLL's rate changes when it enters or leaves bypass, so the DPLL's
> rate and the rates of all dependent clocks need to be recalculated
> when this happens.
>
> Also, fix test for bypass to test against the appropriate bypass clo
On Wed, Jan 28, 2009 at 12:08:32PM -0700, Paul Walmsley wrote:
> When a non-CORE DPLL is enabled via omap3_noncore_dpll_enable(), use
> the user's desired rate in clk->rate to determine whether to put the
> DPLL into bypass or lock mode, rather than reading the DPLL's current
> idle state from its
On Wed, Jan 28, 2009 at 12:08:35PM -0700, Paul Walmsley wrote:
> diff --git a/arch/arm/mach-omap2/clock34xx.c b/arch/arm/mach-omap2/clock34xx.c
> index 424eed6..c943043 100644
> --- a/arch/arm/mach-omap2/clock34xx.c
> +++ b/arch/arm/mach-omap2/clock34xx.c
> @@ -270,7 +270,6 @@ static int _omap3_non
On Wed, Jan 28, 2009 at 12:18:16PM -0700, Paul Walmsley wrote:
> From: Mans Rullgard
>
> This makes clk_get_parent() work on OMAP2/3.
This is clearly something that the generic code should be doing.
It's not something specific to OMAP2/3. Please move it to
arch/arm/plat-omap/clock.c
--
To unsub
On Wed, Jan 28, 2009 at 12:08:26PM -0700, Paul Walmsley wrote:
> This patch causes a DPLL to enter bypass when it is instructed to set
> its rate to that of its bypass clock. Previously this was only possible
> after setting the DPLL rate, then disabling and re-enabling it.
The more I think about
On Tue, Jan 27, 2009 at 07:12:47PM -0700, Paul Walmsley wrote:
> +/* Non-CORE DPLL rate set code */
> +
> +/*
> + * omap3_noncore_dpll_program - set non-core DPLL M,N values directly
> + * @clk: struct clk * of DPLL to set
> + * @m: DPLL multiplier to set
> + * @n: DPLL divider to set
> + * @freqse
On Wed, Jan 28, 2009 at 12:18:48PM -0700, Paul Walmsley wrote:
> From: Tony Lindgren
>
> This fixes booting, and is a step toward fixing things properly:
>
> - Make enable_reg u32 instead of u16
No, you're passing this to __raw_read/write, so it needs to be
void __iomem *, not u32. If there's
On Wed, Jan 28, 2009 at 12:27:59PM -0700, Paul Walmsley wrote:
> The price paid is additional runtime memory consumption - 8 bytes per
> clock and 16 bytes per child clock - roughly 4.5KiB on OMAP3.
For OMAP3, that's 222 struct clks of which 182 are children, and indeed
222 * 8 + 182 * 16 gives ab
On Thu, Jan 29, 2009 at 08:25:58AM -0800, Tony Lindgren wrote:
> To me it does not matter which way the stuff gets merged. We just need
> to get it all merged.
>
> If you guys can't get it merged and sorted out then it will all fall
> down on me. And then I have to use tools no smaller than a sled
On Thu, Jan 29, 2009 at 08:53:35AM -0800, Tony Lindgren wrote:
> * Tony Lindgren [090129 08:42]:
> > * Russell King - ARM Linux [090129 08:35]:
> > > On Thu, Jan 29, 2009 at 08:25:58AM -0800, Tony Lindgren wrote:
> > > > To me it does not matter which way the s
On Wed, Jan 28, 2009 at 12:27:51PM -0700, Paul Walmsley wrote:
> Previously the individual clock recalculation functions handled their
> own rate recalculation. This can be handled in the clk_set_rate(),
> clk_set_parent(), and recalculate_root_clocks() functions in
> plat-omap/clock.c. Removes d
On Wed, Jan 28, 2009 at 12:27:59PM -0700, Paul Walmsley wrote:
> +static int omap_clk_for_each_child(struct clk *clk, unsigned long
> parent_rate,
> +u8 rate_storage, int (*cb)(struct clk *, unsigned long, u8))
> +{
> + struct clk_child *child;
> + int ret;
> +
> + list
On Thu, Jan 29, 2009 at 03:14:01PM +, Russell King - ARM Linux wrote:
> On Wed, Jan 28, 2009 at 12:27:59PM -0700, Paul Walmsley wrote:
> > The price paid is additional runtime memory consumption - 8 bytes per
> > clock and 16 bytes per child clock - roughly 4.5KiB on OMAP3.
On Thu, Jan 29, 2009 at 10:57:24PM -0700, Paul Walmsley wrote:
> On Thu, 29 Jan 2009, Russell King - ARM Linux wrote:
> > Final point... this is only called from the function below, which also
> > checks that clk and clk->dpll_data are both non-NULL. So these checks
> > ar
On Fri, Jan 30, 2009 at 01:42:52AM -0700, Paul Walmsley wrote:
> I haven't looked closely at your above three patches for this, but plan to
> do so later today.
>
> Regarding provenance, the patches that I sent you were developed
> independently, for clock notifier support. Ultimately, I have n
On Wed, Jan 28, 2009 at 12:35:28PM -0700, Paul Walmsley wrote:
> Rearrange the parent clock enable status check code so it actually makes
> sense. No functional change.
I don't think there's anything gained from introducing the additional
'parent_ret' variable.
--
To unsubscribe from this list: s
On Fri, Jan 30, 2009 at 08:23:49AM -0600, Woodruff, Richard wrote:
>
> > There's one bug that your version highlights in mine - the virtual mpu
> > clock in omap1 touches the DPLL and repropagates that rate. I've
> > removed that repropagation, so that needs fixing.
> >
> > However, this raises a
On Wed, Jan 28, 2009 at 12:35:33PM -0700, Paul Walmsley wrote:
> The McBSP driver uses virtual clocks to handle enabling and disabling
> its hardware clocks. These virtual clocks have no associated
> clockdomain. After commit 60b8b431e47d8c5b8c02a2e4fa9af388aae20790,
> this prevents the McBSP cloc
On Tue, Jan 27, 2009 at 07:44:08PM -0700, Paul Walmsley wrote:
> diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
> index 55c5d67..7aa09f5 100644
> --- a/arch/arm/mach-omap2/clock.c
> +++ b/arch/arm/mach-omap2/clock.c
> @@ -77,17 +77,17 @@ void omap2_init_clk_clkdm(struct clk
On Tue, Jan 27, 2009 at 07:44:11PM -0700, Paul Walmsley wrote:
> struct clockdomain contains a struct powerdomain *pwrdm and const char
> *pwrdm_name. The pwrdm_name is only used at initialization to look up
> the appropriate pwrdm pointer. Combining these into a union saves
> about 100 bytes on
On Wed, Jan 28, 2009 at 12:35:15PM -0700, Paul Walmsley wrote:
> Every OMAP2/3 clock must now have an assigned clockdomain, so we can
> remove the checks from clk_enable()/clk_disable(). Instead, verify
> that the clockdomain is present only at clock init time via the
> arch_clock clk_register() h
On Tue, Jan 27, 2009 at 07:44:15PM -0700, Paul Walmsley wrote:
> Add clockdomains for the CM and PRM. These replace "wkup_clkdm", a
> placeholder clockdomain which does not exist on the hardware. Add a
> clockdomain for virtual OPP clocks, "virt_opp_clkdm". Mark all clocks
> in the clock tree wi
On Tue, Jan 27, 2009 at 07:44:18PM -0700, Paul Walmsley wrote:
> Each DPLL exists in its own powerdomain (cf 34xx TRM figure 4-18) and
> clockdomain; so, create powerdomain and clockdomain structures for them.
> Mark each DPLL clock as belonging to their respective DPLL clockdomain.
> cf. 34xx TRM
On Tue, Jan 27, 2009 at 07:44:21PM -0700, Paul Walmsley wrote:
> Add clockdomains for all remaining clocks without them, and warn in
> clk_register() if any are missing a clockdomain. On OMAP2, call
> omap2_init_clk_clkdm() immediately after clk_register(), just as OMAP3
> does. Remove omap2_init
On Thu, Jan 29, 2009 at 02:15:44AM -0700, Paul Walmsley wrote:
> Hi Richard,
>
> On Thu, 29 Jan 2009, Paul Walmsley wrote:
>
> > > TLLSAR is not functional till ES3.1 (and beyound). Is it possible to
> > > flag it this way?
> >
> > Yes, it's easy in this case. Thanks for the note. I will sen
On Thu, Jan 29, 2009 at 11:29:31PM -0700, Paul Walmsley wrote:
> On Thu, 29 Jan 2009, Russell King - ARM Linux wrote:
>
> > On Wed, Jan 28, 2009 at 12:18:16PM -0700, Paul Walmsley wrote:
> > > From: Mans Rullgard
> > >
> > > This makes clk_get_parent() wo
On Sat, Jan 31, 2009 at 03:07:06PM +, Måns Rullgård wrote:
> Russell King - ARM Linux writes:
> > Great, thanks. However, I'd forgotten that one of my patches completely
> > removes clk_get_parent() since it's unused by any code in OMAP at present.
> >
&g
On Sat, Jan 31, 2009 at 03:39:07PM +, Måns Rullgård wrote:
> Russell King - ARM Linux writes:
>
> > On Sat, Jan 31, 2009 at 03:07:06PM +, Måns Rullgård wrote:
> >> Russell King - ARM Linux writes:
> >> > Great, thanks. However, I'd forgo
Tony,
Thye LDP platform network interface still doesn't seem to work. There
seems to be several reasons for this:
1. wrong resource size in arch/arm/mach-omap2/board-ldp.c
2. missing OMAPx4xx configuration from drivers/net/smc911x.h
3. missing SMC9211 chip IDs from drivers/net/smc911x.c
The pat
On Mon, Feb 02, 2009 at 01:45:30PM -0800, David Miller wrote:
> From: Russell King - ARM Linux
> Date: Mon, 2 Feb 2009 21:39:53 +
>
> > The patch to fix these issues would seem to be relatively small (12
> > lines in the smc911x and one line change in board-ldp.c) - i
On Mon, Feb 02, 2009 at 03:57:45PM -0800, Tony Lindgren wrote:
> * David Miller [090202 13:45]:
> > From: Russell King - ARM Linux
> > Date: Mon, 2 Feb 2009 21:39:53 +
> >
> > > The patch to fix these issues would seem to be relatively small (12
> >
On Tue, Feb 03, 2009 at 05:01:26PM +0800, stanley.miao wrote:
> Woodruff, Richard wrote:
> >>>Here should be 0x100. Fixing this won't cause problems with smsc911x
> >>>patches.
> >>>
> >>Yes it will - if it gets fixed in the -rc series for the smc911x driver
> >>your patches will conflict.
>
On Mon, Feb 02, 2009 at 12:13:02AM -0700, Paul Walmsley wrote:
> Based on a comparison of E 08 with the three omap-clks1 commits you
> mentioned above, here are some differences that would merit further
> attention. Some of these you've mentioned in subsequent E-mails.
>
> If you use your patch
On Tue, Feb 03, 2009 at 11:02:31AM +, steve.glendinn...@smsc.com wrote:
> Russell King - ARM Linux wrote on 03/02/2009
> 08:10:42:
> > On Mon, Feb 02, 2009 at 03:57:45PM -0800, Tony Lindgren wrote:
> > > * David Miller [090202 13:45]:
> > > > Well, the SM
On Tue, Feb 03, 2009 at 02:20:44AM -0700, Paul Walmsley wrote:
> Hello Russell,
>
> On Sat, 31 Jan 2009, Russell King - ARM Linux wrote:
>
> > On Tue, Jan 27, 2009 at 07:44:11PM -0700, Paul Walmsley wrote:
> > > struct clockdomain contains a struct powerd
On Fri, Feb 06, 2009 at 02:19:34PM -0700, Paul Walmsley wrote:
> [p...@pwsan.com: This patch has been updated to use offsets for OMAP1
> clock enable registers, to resolve all current sparse warnings with the
> clock code, and to convert most magic constants into symbolic macros.
Wish you hadn
On Wed, Jan 28, 2009 at 12:27:56PM -0700, Paul Walmsley wrote:
> For upcoming notifier support, modify the rate recalculation code to
> take parent rate and rate storage parameters. The goal here is to
> allow the clock code to determine what the clock's rate would be after
> a parent change or a
On Wed, Jan 28, 2009 at 12:27:56PM -0700, Paul Walmsley wrote:
> For upcoming notifier support, modify the rate recalculation code to
> take parent rate and rate storage parameters. The goal here is to
> allow the clock code to determine what the clock's rate would be after
> a parent change or a
On Thu, Jan 29, 2009 at 10:47:40PM -0700, Paul Walmsley wrote:
> Hello Russell,
>
> this E-mail responds to your comments on patches C 04 through C 08.
> My understanding is that you'd like me to:
>
> 1. Compress patches C 04 through C 09;
What I would like to see is a clear set of patches (or
On Thu, Jan 29, 2009 at 10:06:08PM +, Russell King - ARM Linux wrote:
> @@ -780,7 +780,7 @@ int omap2_clk_set_parent(struct clk *clk, struct clk
> *new_parent)
> if (clk->usecount > 0)
> _omap2_clk_enable(clk);
>
> - clk->parent = new_paren
It would be nice to get the last OMAP defconfig in mainline working.
It's broken since 2.6.29-rc2-git3 due to this persistent problem:
drivers/built-in.o: In function `omap_udc_probe':
omap.c:(.init.text+0x30cc): undefined reference to `otg_get_transceiver'
omap.c:(.init.text+0x38a4): undefined re
On Mon, Feb 02, 2009 at 10:29:09PM +, Russell King - ARM Linux wrote:
> On Mon, Feb 02, 2009 at 01:45:30PM -0800, David Miller wrote:
> > From: Russell King - ARM Linux
> > Date: Mon, 2 Feb 2009 21:39:53 +
> >
> > > The patch to fix these issues would s
On Tue, Feb 10, 2009 at 11:48:55AM +, Russell King - ARM Linux wrote:
> On Mon, Feb 02, 2009 at 10:29:09PM +0000, Russell King - ARM Linux wrote:
> > On Mon, Feb 02, 2009 at 01:45:30PM -0800, David Miller wrote:
> > > From: Russell King - ARM Linux
> > > Date: Mon
On Tue, Feb 10, 2009 at 01:02:02PM -0800, Tony Lindgren wrote:
> Yeah, the smsc updates for omap might take a while longer to get going.
> So here's my ack for this smc911x patch:
>
> Acked-by: Tony Lindgren
Thanks.
> For the smsc changes, I don't have an LDP to test with. But I'll try
> to get
On Wed, Aug 06, 2008 at 07:21:14AM -0500, Woodruff, Richard wrote:
> Most of the weak memory attributes in newer ARMs are not exploited
> today in tree. I'll guess this was more a correctness and capability
> judgment from Russell.
Not entirely true. We do as much as is safe to do - which is bas
On Thu, Aug 07, 2008 at 01:56:40PM -0500, Woodruff, Richard wrote:
> > From: Russell King - ARM Linux [mailto:[EMAIL PROTECTED]
> > > Most of the weak memory attributes in newer ARMs are not exploited
> > > today in tree. I'll guess this was more a correctness and c
On Thu, Aug 07, 2008 at 03:38:55PM -0500, Woodruff, Richard wrote:
>
> > From: Russell King - ARM Linux [mailto:[EMAIL PROTECTED]
> > > Is DEVICE really safe for things other than FIFOs with out the use of
> > > barriers?
> >
> > As far as I'm aware,
On Thu, Aug 07, 2008 at 10:20:33PM +0100, Russell King - ARM Linux wrote:
> In the case of arch/arm/mach-omap2/irq.c, reading the INTC_REVISION
> reg after masking should be a sufficient solution.
And here's a patch to do exactly that.
diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm
On Thu, Aug 07, 2008 at 06:07:50PM -0500, Woodruff, Richard wrote:
> If I write a series of control register commands to device A, then
> write a go operation to device B, I would hope all of A's writes
> had completed before B gets the go. SO gives you this. DEVICE may
> not with out barriers.
On Fri, Aug 08, 2008 at 12:44:49PM +0100, Catalin Marinas wrote:
> There are already CPUs with weaker memory ordering model than ARM (e.g.
> Alpha) and they are supported by Linux. Of course, there may be problems
> with drivers since most of them are developed in x86.
There are, and they are _con
On Mon, Aug 11, 2008 at 02:03:10PM -0600, Paul Walmsley wrote:
> Commit 2ccdd1e77da52ad494e9af46bf272d816830cb28 doesn't add
> v7wbi_possible_flags and v7wbi_always_flags to possible_tlb_flags and
> always_tlb_flags. This causes the L2 cache flush in clean_pmd_entry()
> (intended for Feroceon o
On Wed, Jul 16, 2008 at 06:19:05PM +0300, Tony Lindgren wrote:
> This patch series contains power domain and clock domain specific patches
> for omap posted to linux-arm-kernel list during 2.6.25-rc5.
>
> I'm reposting the series to a wider audience as Russell King suspected that
> other archs may
On Tue, Aug 19, 2008 at 11:39:51AM +0300, Tony Lindgren wrote:
> * Russell King - ARM Linux <[EMAIL PROTECTED]> [080818 19:34]:
> > On Wed, Jul 16, 2008 at 06:19:05PM +0300, Tony Lindgren wrote:
> > > This patch series contains power domain and clock domain specific patch
On Fri, Jun 06, 2008 at 06:47:42PM -0700, Tony Lindgren wrote:
> This patch adds common function to enable/disable omap2/3 uart
> clocks. Enabled uarts are passed by bootloader in atags and clocks for
> these enabled uarts are touched.
In some ways, this patch is a good thing, in others it's outra
On Fri, Jun 06, 2008 at 07:12:28PM -0700, Tony Lindgren wrote:
> Some register offsets are different for 242x and 243x. This
> will allow compiling sleep code for both chips into the same
> kernel.
>
> Note that some PM patches are still missing. The PM patches will
> be added later on once the ba
On Fri, Jun 06, 2008 at 07:12:30PM -0700, Tony Lindgren wrote:
> static void omap2_clk_wait_ready(struct clk *clk)
> {
> - void __iomem *reg, *other_reg, *st_reg;
> - u32 bit;
> -
> - /*
> - * REVISIT: This code is pretty ugly. It would be nice to generalize
> - * it and pu
On Fri, Jun 06, 2008 at 07:12:33PM -0700, Tony Lindgren wrote:
> From: Paul Walmsley <[EMAIL PROTECTED]>
>
> Add clkdm_get_pwrdm() to the clockdomain code. It will return a
> pointer to the powerdomain struct that the clockdomain is contained
> within. Used by the PM code.
>
> Signed-off-by: Pa
On Fri, Jun 06, 2008 at 07:12:40PM -0700, Tony Lindgren wrote:
> @@ -208,10 +365,12 @@ static int __init omap2_init_devices(void)
> /* please keep these calls, and their implementations above,
>* in alphabetical order so they're easier to sort through.
>*/
> - omap_init_i2
On Fri, Jun 06, 2008 at 06:47:41PM -0700, Tony Lindgren wrote:
> This patch series contains various omap2 patchs from linux-omap tree.
> Big chunk of the patches still improve the clock code. Also more
> clean-up to allow compiling omap2 and omap3 support into the same
> kernel. The patch also adds
On Wed, Aug 20, 2008 at 10:42:44AM +0300, Tony Lindgren wrote:
> Will remove these. I have some mach/io.h clean up patches coming up for
> the next merge window that should take care of this.
If you can sort out about 10 patches and post them to the list, wait
for them to be reviewed and merged be
201 - 300 of 2180 matches
Mail list logo
