* [PATCH] i2c: at91: fix SMBus quick command
From: ludovic.desroches at atmel.com @ 2012-11-09 17:23 UTC (permalink / raw)
To: linux-arm-kernel
From: Ludovic Desroches <ludovic.desroches@atmel.com>
SMBus command was not performed. This patch fixes this issue. The timeout log
priority has been decreased to not make console dirty uselessly.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
---
Hi Wolfram,
It would be great if this patch could be included into 3.7. The driver was
claiming that it supports SMBus quick command but it was not true. Moreover,
with some IP versions, it could cause data corruption.
I tested it with i2cdetect as you suggested. EEPROMs were detected but not
other devices (lm75 and ds1337). I have exactly the same behavior by using
i2c-gpio driver so I think there is no major issue on a driver point of view.
Thanks.
Regards.
Ludovic
drivers/i2c/busses/i2c-at91.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index aa59a25..a6670eb 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -39,6 +39,7 @@
#define AT91_TWI_STOP 0x0002 /* Send a Stop Condition */
#define AT91_TWI_MSEN 0x0004 /* Master Transfer Enable */
#define AT91_TWI_SVDIS 0x0020 /* Slave Transfer Disable */
+#define AT91_TWI_QUICK 0x0040 /* SMBus quick command */
#define AT91_TWI_SWRST 0x0080 /* Software Reset */
#define AT91_TWI_MMR 0x0004 /* Master Mode Register */
@@ -212,7 +213,10 @@ static int at91_do_twi_transfer(struct at91_twi_dev *dev)
INIT_COMPLETION(dev->cmd_complete);
dev->transfer_status = 0;
- if (dev->msg->flags & I2C_M_RD) {
+
+ if (!dev->buf_len) {
+ at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_QUICK);
+ } else if (dev->msg->flags & I2C_M_RD) {
unsigned start_flags = AT91_TWI_START;
if (at91_twi_read(dev, AT91_TWI_SR) & AT91_TWI_RXRDY) {
@@ -235,7 +239,7 @@ static int at91_do_twi_transfer(struct at91_twi_dev *dev)
ret = wait_for_completion_interruptible_timeout(&dev->cmd_complete,
dev->adapter.timeout);
if (ret == 0) {
- dev_err(dev->dev, "controller timed out\n");
+ dev_dbg(dev->dev, "controller timed out\n");
at91_init_twi_bus(dev);
return -ETIMEDOUT;
}
--
1.7.11.3
^ permalink raw reply related
* [PATCH v3 7/7] crypto: omap_sham: Remove usage of private DMA API
From: Mark A. Greer @ 2012-11-09 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALLzPKY9fRSwgSTw-t9-wRbCHVbKPA=m+RsTWW4=CaxtDCczcQ@mail.gmail.com>
On Fri, Nov 09, 2012 at 06:28:16PM +0200, Kasatkin, Dmitry wrote:
> On Wed, Nov 7, 2012 at 4:57 AM, Mark A. Greer <mgreer@animalcreek.com> wrote:
> > From: "Mark A. Greer" <mgreer@animalcreek.com>
> >
> > Remove usage of the private OMAP DMA API.
> > The dmaengine API will be used instead.
> >
> > CC: Russell King <rmk+kernel@arm.linux.org.uk>
> > CC: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
> > Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
> > ---
> > drivers/crypto/omap-sham.c | 117 ---------------------------------------------
> > 1 file changed, 117 deletions(-)
> >
> > diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
> > index b57277c..ebb5255 100644
> > --- a/drivers/crypto/omap-sham.c
> > +++ b/drivers/crypto/omap-sham.c
> > @@ -807,18 +762,6 @@ static int omap_sham_handle_queue(struct omap_sham_dev *dd,
> > if (err)
> > goto err1;
> >
> > -#ifdef OMAP_SHAM_DMA_PRIVATE
> > - omap_set_dma_dest_params(dd->dma_lch, 0,
> > - OMAP_DMA_AMODE_CONSTANT,
> > - dd->phys_base + SHA_REG_DIN(0), 0, 16);
> > -
> > - omap_set_dma_dest_burst_mode(dd->dma_lch,
> > - OMAP_DMA_DATA_BURST_16);
> > -
> > - omap_set_dma_src_burst_mode(dd->dma_lch,
> > - OMAP_DMA_DATA_BURST_4);
>
> Burst mode significantly improves performance.
> How do you configure burst mode with new API?
This is (or should be) taken care of by the dmaengine infrastructure.
I've noted that there's an issue and there is a discussion about it
here:
http://www.spinics.net/lists/linux-omap/msg79855.html
We probably need to extend the dmaengine API to allow API-users to
request specific tweaks/optimizations/whatever but that's MHO.
Mark
--
^ permalink raw reply
* [PATCH v2] pinctrl/nomadik: make independent of prcmu driver
From: Stephen Warren @ 2012-11-09 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352456915-28738-1-git-send-email-linus.walleij@stericsson.com>
On 11/09/2012 03:28 AM, Linus Walleij wrote:
> From: Jonas Aaberg <jonas.aberg@stericsson.com>
>
> Currently there are some unnecessary criss-cross
> dependencies between the PRCMU driver in MFD and a lot of
> other drivers, mainly because other drivers need to poke
> around in the PRCM register range.
>
> In cases like this there are actually just a few select
> registers that the pinctrl driver need to read/modify/write,
> and it turns out that no other driver is actually using
> these registers, so there are no concurrency issues
> whatsoever.
>
> So: don't let the location of the register range complicate
> things, just poke into these registers directly and skip
> a layer of indirection.
>
> Take this opportunity to add kerneldoc to the pinctrl
> state container.
> diff --git a/drivers/pinctrl/pinctrl-nomadik.c b/drivers/pinctrl/pinctrl-nomadik.c
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (res) {
> + npct->prcm_base = devm_ioremap(&pdev->dev, res->start,
> + resource_size(res));
> + if (!npct->prcm_base) {
> + dev_err(&pdev->dev,
> + "failed to ioremap PRCM registers\n");
> + return -ENOMEM;
> + }
> + } else {
> + dev_info(&pdev->dev,
> + "No PRCM base, assume no ALT-Cx control is available\n");
> + }
Where is "assume no ALT-Cx control is available" implemented; I don't
see anything that uses npct->prcm_base to conditionally enable/block any
features. Is it just assumed that the DT won't contain any entries that
trigger writes to the PRCM registers? That seems fragile; it could cause
a "user"-triggered kernel crash.
Aside from that, this seems fine. Much smaller than V1:-)
^ permalink raw reply
* [RFC 3/6] sched: pack small tasks
From: Morten Rasmussen @ 2012-11-09 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349595838-31274-4-git-send-email-vincent.guittot@linaro.org>
Hi Vincent,
I have experienced suboptimal buddy selection on a dual cluster setup
(ARM TC2) if SD_SHARE_POWERLINE is enabled at MC level and disabled at
CPU level. This seems to be the correct flag settings for a system with
only cluster level power gating.
To me it looks like update_packing_domain() is not doing the right
thing. See inline comments below.
On Sun, Oct 07, 2012 at 08:43:55AM +0100, Vincent Guittot wrote:
> During sched_domain creation, we define a pack buddy CPU if available.
>
> On a system that share the powerline at all level, the buddy is set to -1
>
> On a dual clusters / dual cores system which can powergate each core and
> cluster independantly, the buddy configuration will be :
> | CPU0 | CPU1 | CPU2 | CPU3 |
> -----------------------------------
> buddy | CPU0 | CPU0 | CPU0 | CPU2 |
>
> Small tasks tend to slip out of the periodic load balance.
> The best place to choose to migrate them is at their wake up.
>
> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> ---
> kernel/sched/core.c | 1 +
> kernel/sched/fair.c | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++
> kernel/sched/sched.h | 1 +
> 3 files changed, 111 insertions(+)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index dab7908..70cadbe 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -6131,6 +6131,7 @@ cpu_attach_domain(struct sched_domain *sd, struct root_domain *rd, int cpu)
> rcu_assign_pointer(rq->sd, sd);
> destroy_sched_domains(tmp, cpu);
>
> + update_packing_domain(cpu);
> update_top_cache_domain(cpu);
> }
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 4f4a4f6..8c9d3ed 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -157,6 +157,63 @@ void sched_init_granularity(void)
> update_sysctl();
> }
>
> +
> +/*
> + * Save the id of the optimal CPU that should be used to pack small tasks
> + * The value -1 is used when no buddy has been found
> + */
> +DEFINE_PER_CPU(int, sd_pack_buddy);
> +
> +/* Look for the best buddy CPU that can be used to pack small tasks
> + * We make the assumption that it doesn't wort to pack on CPU that share the
> + * same powerline. We looks for the 1st sched_domain without the
> + * SD_SHARE_POWERLINE flag. Then We look for the sched_group witht the lowest
> + * power per core based on the assumption that their power efficiency is
> + * better */
> +void update_packing_domain(int cpu)
> +{
> + struct sched_domain *sd;
> + int id = -1;
> +
> + sd = highest_flag_domain(cpu, SD_SHARE_POWERLINE);
> + if (!sd)
> + sd = rcu_dereference_check_sched_domain(cpu_rq(cpu)->sd);
> + else
> + sd = sd->parent;
sd is the highest level where SD_SHARE_POWERLINE is enabled so the sched
groups of the parent level would represent the power domains. If get it
right, we want to pack inside the cluster first and only let first cpu
of the cluster do packing on another cluster. So all cpus - except the
first one - in the current sched domain should find its buddy within the
domain and only the first one should go to the parent sched domain to
find its buddy.
I propose the following fix:
- sd = sd->parent;
+ if (cpumask_first(sched_domain_span(sd)) == cpu
+ || !sd->parent)
+ sd = sd->parent;
> +
> + while (sd) {
> + struct sched_group *sg = sd->groups;
> + struct sched_group *pack = sg;
> + struct sched_group *tmp = sg->next;
> +
> + /* 1st CPU of the sched domain is a good candidate */
> + if (id == -1)
> + id = cpumask_first(sched_domain_span(sd));
There is no guarantee that id is in the sched group pointed to by
sd->groups, which is implicitly assumed later in the search loop. We
need to find the sched group that contains id and point sg to that
instead. I haven't found an elegant way to find that group, but the fix
below should at least give the right result.
+ /* Find sched group of candidate */
+ tmp = sd->groups;
+ do {
+ if (cpumask_test_cpu(id, sched_group_cpus(tmp)))
+ {
+ sg = tmp;
+ break;
+ }
+ } while (tmp = tmp->next, tmp != sd->groups);
+
+ pack = sg;
+ tmp = sg->next;
Regards,
Morten
> +
> + /* loop the sched groups to find the best one */
> + while (tmp != sg) {
> + if (tmp->sgp->power * sg->group_weight <
> + sg->sgp->power * tmp->group_weight)
> + pack = tmp;
> + tmp = tmp->next;
> + }
> +
> + /* we have found a better group */
> + if (pack != sg)
> + id = cpumask_first(sched_group_cpus(pack));
> +
> + /* Look for another CPU than itself */
> + if ((id != cpu)
> + || ((sd->parent) && !(sd->parent->flags && SD_LOAD_BALANCE)))
> + break;
> +
> + sd = sd->parent;
> + }
> +
> + pr_info(KERN_INFO "CPU%d packing on CPU%d\n", cpu, id);
> + per_cpu(sd_pack_buddy, cpu) = id;
> +}
> +
> #if BITS_PER_LONG == 32
> # define WMULT_CONST (~0UL)
> #else
> @@ -3073,6 +3130,55 @@ static int select_idle_sibling(struct task_struct *p, int target)
> return target;
> }
>
> +static inline bool is_buddy_busy(int cpu)
> +{
> + struct rq *rq = cpu_rq(cpu);
> +
> + /*
> + * A busy buddy is a CPU with a high load or a small load with a lot of
> + * running tasks.
> + */
> + return ((rq->avg.usage_avg_sum << rq->nr_running) >
> + rq->avg.runnable_avg_period);
> +}
> +
> +static inline bool is_light_task(struct task_struct *p)
> +{
> + /* A light task runs less than 25% in average */
> + return ((p->se.avg.usage_avg_sum << 2) < p->se.avg.runnable_avg_period);
> +}
> +
> +static int check_pack_buddy(int cpu, struct task_struct *p)
> +{
> + int buddy = per_cpu(sd_pack_buddy, cpu);
> +
> + /* No pack buddy for this CPU */
> + if (buddy == -1)
> + return false;
> +
> + /*
> + * If a task is waiting for running on the CPU which is its own buddy,
> + * let the default behavior to look for a better CPU if available
> + * The threshold has been set to 37.5%
> + */
> + if ((buddy == cpu)
> + && ((p->se.avg.usage_avg_sum << 3) < (p->se.avg.runnable_avg_sum * 5)))
> + return false;
> +
> + /* buddy is not an allowed CPU */
> + if (!cpumask_test_cpu(buddy, tsk_cpus_allowed(p)))
> + return false;
> +
> + /*
> + * If the task is a small one and the buddy is not overloaded,
> + * we use buddy cpu
> + */
> + if (!is_light_task(p) || is_buddy_busy(buddy))
> + return false;
> +
> + return true;
> +}
> +
> /*
> * sched_balance_self: balance the current task (running on cpu) in domains
> * that have the 'flag' flag set. In practice, this is SD_BALANCE_FORK and
> @@ -3098,6 +3204,9 @@ select_task_rq_fair(struct task_struct *p, int sd_flag, int wake_flags)
> if (p->nr_cpus_allowed == 1)
> return prev_cpu;
>
> + if (check_pack_buddy(cpu, p))
> + return per_cpu(sd_pack_buddy, cpu);
> +
> if (sd_flag & SD_BALANCE_WAKE) {
> if (cpumask_test_cpu(cpu, tsk_cpus_allowed(p)))
> want_affine = 1;
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index a95d5c1..086d8bf 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -875,6 +875,7 @@ static inline void idle_balance(int cpu, struct rq *rq)
>
> extern void sysrq_sched_debug_show(void);
> extern void sched_init_granularity(void);
> +extern void update_packing_domain(int cpu);
> extern void update_max_interval(void);
> extern void update_group_power(struct sched_domain *sd, int cpu);
> extern int update_runtime(struct notifier_block *nfb, unsigned long action, void *hcpu);
> --
> 1.7.9.5
>
>
> _______________________________________________
> linaro-dev mailing list
> linaro-dev at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
^ permalink raw reply
* [PATCH v3 1/7] ARM: OMAP2xxx: hwmod: Convert SHAM crypto device data to hwmod
From: Paul Walmsley @ 2012-11-09 17:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121109170703.GA13898@animalcreek.com>
On Fri, 9 Nov 2012, Mark A. Greer wrote:
> On Fri, Nov 09, 2012 at 06:10:20PM +0200, Kasatkin, Dmitry wrote:
>
> > Why not using macros as it was before?
> >
> > OMAP24XX_SEC_SHA1MD5_BASE
>
> I am following the precedent set in the existing code of that file
> which uses the actual address instead of a macro (except for uart).
>
> I have no preference but I believe that is how Paul prefers it.
>
> Paul?
My upstream prefers the raw addresses, I believe, under the rationale that
it allows the macro definitions to be removed from arch/arm/mach-omap2.
This reduces the total number of lines of code in that directory - and
this is currently an overriding concern of my upstreams.
So, yes the address format in your patch is fine.
- Paul
^ permalink raw reply
* [PATCH v3 1/7] ARM: OMAP2xxx: hwmod: Convert SHAM crypto device data to hwmod
From: Mark A. Greer @ 2012-11-09 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALLzPKY7TCFe0yvpwJFNf8U2=h4k1Jcb8g9Q0UpGM8qv2FcSwg@mail.gmail.com>
On Fri, Nov 09, 2012 at 06:10:20PM +0200, Kasatkin, Dmitry wrote:
> Hello,
Thanks for your comments, Dmitry.
> On Wed, Nov 7, 2012 at 4:57 AM, Mark A. Greer <mgreer@animalcreek.com> wrote:
> > From: "Mark A. Greer" <mgreer@animalcreek.com>
> >
> > Convert the device data for the OMAP2 SHAM crypto IP from
> > explicit platform_data to hwmod.
> >
> > CC: Paul Walmsley <paul@pwsan.com>
> > Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
> > ---
> > diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> > index cba60e0..f18fa50 100644
> > --- a/arch/arm/mach-omap2/devices.c
> > +++ b/arch/arm/mach-omap2/devices.c
> > @@ -501,16 +485,24 @@ static struct platform_device sham_device = {
> > static void omap_init_sham(void)
> > {
> > if (cpu_is_omap24xx()) {
> > - sham_device.resource = omap2_sham_resources;
> > - sham_device.num_resources = omap2_sham_resources_sz;
> > + struct omap_hwmod *oh;
> > + struct platform_device *pdev;
> > +
> > + oh = omap_hwmod_lookup("sham");
> > + if (!oh)
> > + return;
> > +
> > + pdev = omap_device_build("omap-sham", -1, oh, NULL, 0, NULL,
> > + 0, 0);
> > + WARN(IS_ERR(pdev), "Can't build omap_device for omap-sham\n");
> > } else if (cpu_is_omap34xx()) {
> > sham_device.resource = omap3_sham_resources;
> > sham_device.num_resources = omap3_sham_resources_sz;
> > + platform_device_register(&sham_device);
>
> Why changes are only for OMAP2?
> OMAP3 is also the same class.
This patch is specifically for omap2.
A following patch does the same for omap3.
> > diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c b/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
> > index 1a1287d..bb314c5 100644
> > --- a/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
> > @@ -138,6 +138,15 @@ static struct omap_hwmod_addr_space omap2_rng_addr_space[] = {
> > { }
> > };
> >
> > +struct omap_hwmod_addr_space omap2xxx_sham_addrs[] = {
> > + {
> > + .pa_start = 0x480a4000,
> > + .pa_end = 0x480a4000 + 0x64 - 1,
> > + .flags = ADDR_TYPE_RT
> > + },
> > + { }
> > +};
>
> Why not using macros as it was before?
>
> OMAP24XX_SEC_SHA1MD5_BASE
I am following the precedent set in the existing code of that file
which uses the actual address instead of a macro (except for uart).
I have no preference but I believe that is how Paul prefers it.
Paul?
^ permalink raw reply
* [PATCH] atmel_serial oops when peripheral clock misconfigured
From: Douglas Gilbert @ 2012-11-09 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In lk 3.7.0-rc4 when a peripheral clock is not found for
a serial port the atmel_serial driver brings down the
kernel with an oops during boot-up. This impacts the
Atmel AT91 family of MCUs.
For example, arch/arm/mach-at91/at91sam9x5.c does not
specify properly the peripheral clocks for the UTXD0/URXD0
and UTXD1/URXD1 serial ports. Selecting either of those
ports in a dts file will crash the kernel. at91sam9x5.c needs
to be fixed but stopping atmel_serial crashing the kernel is
more urgent.
Patch attached for your consideration.
Signed-of-by: Douglas Gilbert <dgilbert@interlog.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: atmel_serial_clk_oops.patch
Type: text/x-patch
Size: 2246 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121109/d24da5e3/attachment.bin>
^ permalink raw reply
* pxa27x_keypad status
From: Robert Jarzmik @ 2012-11-09 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+E=qVc37ZB-mfbJxFVWCVsOC_4Rx7bjzMMkouiTNhhEqATnsw@mail.gmail.com>
Vasily Khoruzhick <anarsoul@gmail.com> writes:
> On Mon, Nov 5, 2012 at 9:45 PM, Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> Hi Robert,
>
> 3.7-rc2 works for me except suspend/resume issue (does not work after resume)
> I've just reverted 6ce34a5fb4955fac1eebe080e1c2784bc8710449 as
> temporary workaround.
OK, checked on another of my devices. You're right, it does work.
Conclusion: one device with broken keypad hardware :(
Cheers.
--
Robert
^ permalink raw reply
* [PATCH 1/1] regulator: gpio-regulator: fix crash when no states property in dt
From: Mark Brown @ 2012-11-09 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352450076-22682-1-git-send-email-Frank.Li@freescale.com>
On Fri, Nov 09, 2012 at 04:34:36PM +0800, Frank Li wrote:
> /* Fetch states. */
> prop = of_find_property(np, "states", NULL);
> - proplen = prop->length / sizeof(int);
> + proplen = prop ? prop->length / sizeof(int) : 0;
Aren't states mandatory for this driver, in which case shouldn't the
probe fail here?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121109/32576d25/attachment.sig>
^ permalink raw reply
* [GIT PULL v2] ARM: OMAP: second set of PRCM cleanups for 3.8
From: Paul Walmsley @ 2012-11-09 16:56 UTC (permalink / raw)
To: linux-arm-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Tony,
The following changes since commit 7fc54fd3084457c7f11b9e2e1e3fcd19a3badc33:
Merge branch 'omap-for-v3.8/cleanup-headers' into omap-for-v3.8/cleanup-prcm (2012-10-26 13:32:22 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-cleanup-b2-for-3.8
for you to fetch changes up to b99db36cdf37decb1b5575c5f293d170cbbc53d6:
ARM: OMAP2+: PRCM: remove obsolete prcm.[ch] (2012-11-08 15:09:26 -0700)
- ----------------------------------------------------------------
Second set of OMAP PRCM cleanups for 3.8.
These patches remove the use of omap_prcm_get_reset_sources() from the
OMAP watchdog driver, and remove mach-omap2/prcm.c and
plat-omap/include/plat/prcm.h.
Basic test logs for this branch on top of Tony's cleanup-prcm branch
at commit 7fc54fd3084457c7f11b9e2e1e3fcd19a3badc33 are here:
http://www.pwsan.com/omap/testlogs/prcm_cleanup_b_3.8/20121108151646/
However, cleanup-prcm at 7fc54fd3 does not include some fixes
that are needed for a successful test. With several reverts,
fixes, and workarounds applied, the following test logs were
obtained:
http://www.pwsan.com/omap/testlogs/TEST_prcm_cleanup_b_3.8/20121108151930/
which indicate that the series tests cleanly.
This second pull request updates one of the patches which broke
with rmk's allnoconfigs, and also updates the tag description to
indicate that 7fc54fd3 is building cleanly here.
- ----------------------------------------------------------------
vmlinux object size
(delta in bytes from test_cleanup-prcm_7fc54fd_v3.7-rc (7fc54fd3084457c7f11b9e2e1e3fcd19a3badc33)):
text data bss total kernel
-104 -72 0 -176 am33xx_only
+120 -64 0 +56 n800_multi_omap2xxx
+336 -32 0 +304 n800_only_a
+88 -24 0 +64 omap1_defconfig
0 0 0 0 omap1_defconfig_1510innovator_only
+132 -8 0 +124 omap1_defconfig_5912osk_only
+788 -232 0 +556 omap2plus_defconfig
+336 -32 0 +304 omap2plus_defconfig_2430sdp_only
+788 -240 0 +548 omap2plus_defconfig_cpupm
+844 -224 0 +620 omap2plus_defconfig_no_pm
+336 -144 0 +192 omap2plus_defconfig_omap2_4_only
+4528 -112 0 +4416 omap2plus_defconfig_omap3_4_only
+1524 -248 +3472 +4748 rmk_omap3430_ldp_allnoconfig
+312 -48 0 +264 rmk_omap3430_ldp_oldconfig
+1524 -248 +3472 +4748 rmk_omap4430_sdp_allnoconfig
+208 -48 0 +160 rmk_omap4430_sdp_oldconfig
Paul Walmsley (17):
ARM: OMAP1: CGRM: fix omap1_get_reset_sources() return type
ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer
watchdog: OMAP: use standard GETBOOTSTATUS interface; use platform_data fn ptr
ARM: OMAP2+: PRCM: remove omap_prcm_get_reset_sources()
ARM: OMAP2+: common: remove mach-omap2/common.c globals and map_common_io code
ARM: OMAP2/3: PRM: add SoC reset functions (using the CORE DPLL method)
ARM: OMAP2xxx: clock: remove global 'dclk' variable
ARM: OMAP2xxx: clock: move virt_prcm_set code into clkt2xxx_virt_prcm_set.c
ARM: OMAP2+: PRCM: create SoC-specific chip restart functions
ARM: OMAP2+: board files: use SoC-specific system restart functions
ARM: OMAP2xxx: APLL/CM: convert to use omap2_cm_wait_module_ready()
ARM: OMAP2+: CM/clock: convert _omap2_module_wait_ready() to use SoC-independent CM functions
ARM: OMAP2+: PRCM: remove omap2_cm_wait_idlest()
ARM: OMAP2+: PRCM: split and relocate the PRM/CM globals setup
ARM: OMAP2+: PRCM: consolidate PRCM-related timeout macros
ARM: OMAP2+: hwmod: call to _omap4_disable_module() should use the SoC-specific call
ARM: OMAP2+: PRCM: remove obsolete prcm.[ch]
arch/arm/mach-omap1/common.h | 2 +-
arch/arm/mach-omap1/devices.c | 21 ++-
arch/arm/mach-omap1/reset.c | 9 +-
arch/arm/mach-omap2/Makefile | 7 +-
arch/arm/mach-omap2/am33xx.h | 1 +
arch/arm/mach-omap2/board-2430sdp.c | 2 +-
arch/arm/mach-omap2/board-3430sdp.c | 2 +-
arch/arm/mach-omap2/board-3630sdp.c | 2 +-
arch/arm/mach-omap2/board-4430sdp.c | 2 +-
arch/arm/mach-omap2/board-am3517crane.c | 2 +-
arch/arm/mach-omap2/board-am3517evm.c | 2 +-
arch/arm/mach-omap2/board-apollon.c | 2 +-
arch/arm/mach-omap2/board-cm-t35.c | 18 +--
arch/arm/mach-omap2/board-cm-t3517.c | 2 +-
arch/arm/mach-omap2/board-devkit8000.c | 2 +-
arch/arm/mach-omap2/board-generic.c | 10 +-
arch/arm/mach-omap2/board-h4.c | 2 +-
arch/arm/mach-omap2/board-igep0020.c | 4 +-
arch/arm/mach-omap2/board-ldp.c | 2 +-
arch/arm/mach-omap2/board-n8x0.c | 6 +-
arch/arm/mach-omap2/board-omap3beagle.c | 2 +-
arch/arm/mach-omap2/board-omap3evm.c | 2 +-
arch/arm/mach-omap2/board-omap3logic.c | 4 +-
arch/arm/mach-omap2/board-omap3pandora.c | 2 +-
arch/arm/mach-omap2/board-omap3stalker.c | 2 +-
arch/arm/mach-omap2/board-omap3touchbook.c | 2 +-
arch/arm/mach-omap2/board-omap4panda.c | 2 +-
arch/arm/mach-omap2/board-overo.c | 2 +-
arch/arm/mach-omap2/board-rm680.c | 4 +-
arch/arm/mach-omap2/board-rx51.c | 2 +-
arch/arm/mach-omap2/board-ti8168evm.c | 4 +-
arch/arm/mach-omap2/board-zoom.c | 4 +-
arch/arm/mach-omap2/clkt2xxx_apll.c | 57 ++------
arch/arm/mach-omap2/clkt2xxx_dpllcore.c | 36 ++++-
arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 70 ++++++++--
arch/arm/mach-omap2/clkt_iclk.c | 1 -
arch/arm/mach-omap2/clock.c | 57 +++++++-
arch/arm/mach-omap2/clock.h | 28 ----
arch/arm/mach-omap2/clock2420_data.c | 26 +---
arch/arm/mach-omap2/clock2430_data.c | 26 +---
arch/arm/mach-omap2/clock2xxx.c | 16 ---
arch/arm/mach-omap2/clock2xxx.h | 9 +-
arch/arm/mach-omap2/cm-regbits-24xx.h | 2 +
arch/arm/mach-omap2/cm.h | 20 ++-
arch/arm/mach-omap2/cm2xxx.c | 128 ++++++++++++++++-
arch/arm/mach-omap2/cm2xxx.h | 4 +
arch/arm/mach-omap2/cm2xxx_3xxx.h | 8 +-
arch/arm/mach-omap2/cm3xxx.c | 66 +++++++++
arch/arm/mach-omap2/cm3xxx.h | 5 +
arch/arm/mach-omap2/cm_common.c | 70 +++++++++-
arch/arm/mach-omap2/cminst44xx.h | 2 +
arch/arm/mach-omap2/common.c | 183 -------------------------
arch/arm/mach-omap2/common.h | 133 +++++-------------
arch/arm/mach-omap2/control.c | 10 +-
arch/arm/mach-omap2/control.h | 2 +
arch/arm/mach-omap2/cpuidle34xx.c | 1 -
arch/arm/mach-omap2/devices.c | 26 ----
arch/arm/mach-omap2/display.c | 2 +-
arch/arm/mach-omap2/hdq1w.c | 4 +-
arch/arm/mach-omap2/i2c.c | 6 +-
arch/arm/mach-omap2/id.c | 7 +-
arch/arm/mach-omap2/io.c | 86 ++++++++++--
arch/arm/mach-omap2/mcbsp.c | 2 +-
arch/arm/mach-omap2/msdi.c | 4 +-
arch/arm/mach-omap2/omap2-restart.c | 65 +++++++++
arch/arm/mach-omap2/omap3-restart.c | 36 +++++
arch/arm/mach-omap2/omap4-common.c | 19 +++
arch/arm/mach-omap2/omap_hwmod.c | 8 +-
arch/arm/mach-omap2/pm34xx.c | 1 -
arch/arm/mach-omap2/powerdomain.c | 2 -
arch/arm/mach-omap2/prcm-common.h | 22 ---
arch/arm/mach-omap2/prcm.c | 189 --------------------------
arch/arm/mach-omap2/prcm_mpu44xx.c | 17 +++
arch/arm/mach-omap2/prcm_mpu44xx.h | 9 +-
arch/arm/mach-omap2/prm.h | 24 +++-
arch/arm/mach-omap2/prm2xxx.c | 15 +-
arch/arm/mach-omap2/prm2xxx.h | 2 +
arch/arm/mach-omap2/prm2xxx_3xxx.h | 7 -
arch/arm/mach-omap2/prm3xxx.c | 16 ++-
arch/arm/mach-omap2/prm3xxx.h | 2 +
arch/arm/mach-omap2/prm44xx.c | 1 -
arch/arm/mach-omap2/prm_common.c | 16 ++-
arch/arm/mach-omap2/prminst44xx.h | 2 +
arch/arm/mach-omap2/sdrc.c | 8 +-
arch/arm/mach-omap2/sdrc.h | 2 +
arch/arm/mach-omap2/ti81xx.h | 9 ++
arch/arm/mach-omap2/wd_timer.c | 40 +++++-
arch/arm/plat-omap/include/plat/prcm.h | 37 -----
drivers/watchdog/omap_wdt.c | 26 ++--
include/linux/platform_data/omap-wd-timer.h | 38 ++++++
90 files changed, 991 insertions(+), 851 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap2-restart.c
create mode 100644 arch/arm/mach-omap2/omap3-restart.c
delete mode 100644 arch/arm/mach-omap2/prcm.c
delete mode 100644 arch/arm/plat-omap/include/plat/prcm.h
create mode 100644 include/linux/platform_data/omap-wd-timer.h
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBAgAGBQJQnTVXAAoJEMePsQ0LvSpLRJQP+QGaUAh8fr6WCF29unEVZN/8
U/WTNoJnH2WyCjo8dw/xrhFvMfrFFo4aX5HMC9uHlPdkfK5qWFN47+Rw7DYeJsqT
OchzlfG3ECmg1L1SeUviI+9MdQ37QSQd5+Fb7oT8oYsZbndQ2cD1tV9X/Wa5xNUw
ka3yTmR60zu8LGII8lscuk9/FgyP6anSH6nZLoUilTxO1Ux8ae4kQt0vUFRSg2Yn
HKXLJMoL1hedZxVcfMGHZJ/Q1YwiGGsk8myyRtdeTihXPB2VM7Jsf+2zI3yYQpZV
LH1mrtiHQP3OC396zg5ELMuj+VO1vZi0Nw/Khdk3haPC73XFWAHyTX2tfXeTcoS4
ffeHvzQGkj/SVBs8i58nnegJQaBzuFY7koiW4arZd9J7h4al4Y4mXk0nThYidTDU
5TdjHJXa1bHPq4YKPz4l0QMkWDkyVNYtE5xHY0xl7yGcZkp/JCPixEwGE+c+SZMt
EqyonivsXecek8N4wlLmWw6kyjvuA9MxkZUClLSWkSx5KCoF1S1Cha5eyWIA1c6k
zovfEmiT3qw4yVaBOi7sI4ijrD0XKFbtErfsrKXn8uJFiMVZ9GX8Dn1FpyjOTvuE
MiV4yOxgVSv8sSn8gUE3V1MmHEOjGuGtPS41I7wpVeRaKolaKEYuMiDIJWxJ+LUu
Ur0wUp6HUXX6uVrmQfZI
=sFm/
-----END PGP SIGNATURE-----
^ permalink raw reply
* [RFC 3/6] sched: pack small tasks
From: Morten Rasmussen @ 2012-11-09 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5093A63B.2070700@ti.com>
On Fri, Nov 02, 2012 at 10:53:47AM +0000, Santosh Shilimkar wrote:
> On Monday 29 October 2012 06:42 PM, Vincent Guittot wrote:
> > On 24 October 2012 17:20, Santosh Shilimkar <santosh.shilimkar@ti.com> wrote:
> >> Vincent,
> >>
> >> Few comments/questions.
> >>
> >>
> >> On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
> >>>
> >>> During sched_domain creation, we define a pack buddy CPU if available.
> >>>
> >>> On a system that share the powerline at all level, the buddy is set to -1
> >>>
> >>> On a dual clusters / dual cores system which can powergate each core and
> >>> cluster independantly, the buddy configuration will be :
> >>> | CPU0 | CPU1 | CPU2 | CPU3 |
> >>> -----------------------------------
> >>> buddy | CPU0 | CPU0 | CPU0 | CPU2 |
> >>
> >> ^
> >> Is that a typo ? Should it be CPU2 instead of
> >> CPU0 ?
> >
> > No it's not a typo.
> > The system packs at each scheduling level. It starts to pack in
> > cluster because each core can power gate independently so CPU1 tries
> > to pack its tasks in CPU0 and CPU3 in CPU2. Then, it packs at CPU
> > level so CPU2 tries to pack in the cluster of CPU0 and CPU0 packs in
> > itself
> >
> I get it. Though in above example a task may migrate from say
> CPU3->CPU2->CPU0 as part of packing. I was just thinking whether
> moving such task from say CPU3 to CPU0 might be best instead.
To me it seems suboptimal to pack the task twice, but the alternative is
not good either. If you try to move the task directly to CPU0 you may
miss packing opportunities if CPU0 is already busy, while CPU2 might
have enough capacity to take it. It would probably be better to check
the business of CPU0 and then back off and try CPU2 if CP0 is busy. This
would require a buddy list for each CPU rather just a single buddy and
thus might become expensive.
>
> >>
> >>> Small tasks tend to slip out of the periodic load balance.
> >>> The best place to choose to migrate them is at their wake up.
> >>>
> >> I have tried this series since I was looking at some of these packing
> >> bits. On Mobile workloads like OSIdle with Screen ON, MP3, gallary,
> >> I did see some additional filtering of threads with this series
> >> but its not making much difference in power. More on this below.
> >
> > Can I ask you which configuration you have used ? how many cores and
> > cluster ? Can they be power gated independently ?
> >
> I have been trying with couple of setups. Dual Core ARM machine and
> Quad core X86 box with single package thought most of the mobile
> workload analysis I was doing on ARM machine. On both setups
> CPUs can be gated independently.
>
> >>
> >>
> >>> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
> >>> ---
> >>> kernel/sched/core.c | 1 +
> >>> kernel/sched/fair.c | 109
> >>> ++++++++++++++++++++++++++++++++++++++++++++++++++
> >>> kernel/sched/sched.h | 1 +
> >>> 3 files changed, 111 insertions(+)
> >>>
> >>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> >>> index dab7908..70cadbe 100644
> >>> --- a/kernel/sched/core.c
> >>> +++ b/kernel/sched/core.c
> >>> @@ -6131,6 +6131,7 @@ cpu_attach_domain(struct sched_domain *sd, struct
> >>> root_domain *rd, int cpu)
> >>> rcu_assign_pointer(rq->sd, sd);
> >>> destroy_sched_domains(tmp, cpu);
> >>>
> >>> + update_packing_domain(cpu);
> >>> update_top_cache_domain(cpu);
> >>> }
> >>>
> >>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> >>> index 4f4a4f6..8c9d3ed 100644
> >>> --- a/kernel/sched/fair.c
> >>> +++ b/kernel/sched/fair.c
> >>> @@ -157,6 +157,63 @@ void sched_init_granularity(void)
> >>> update_sysctl();
> >>> }
> >>>
> >>> +
> >>> +/*
> >>> + * Save the id of the optimal CPU that should be used to pack small tasks
> >>> + * The value -1 is used when no buddy has been found
> >>> + */
> >>> +DEFINE_PER_CPU(int, sd_pack_buddy);
> >>> +
> >>> +/* Look for the best buddy CPU that can be used to pack small tasks
> >>> + * We make the assumption that it doesn't wort to pack on CPU that share
> >>> the
> >>
> >> s/wort/worth
> >
> > yes
> >
> >>
> >>> + * same powerline. We looks for the 1st sched_domain without the
> >>> + * SD_SHARE_POWERLINE flag. Then We look for the sched_group witht the
> >>> lowest
> >>> + * power per core based on the assumption that their power efficiency is
> >>> + * better */
> >>
> >> Commenting style..
> >> /*
> >> *
> >> */
> >>
> >
> > yes
> >
> >> Can you please expand the why the assumption is right ?
> >> "it doesn't wort to pack on CPU that share the same powerline"
> >
> > By "share the same power-line", I mean that the CPUs can't power off
> > independently. So if some CPUs can't power off independently, it's
> > worth to try to use most of them to race to idle.
> >
> In that case I suggest we use different word here. Power line can be
> treated as voltage line, power domain.
> May be SD_SHARE_CPU_POWERDOMAIN ?
>
How about just SD_SHARE_POWERDOMAIN ?
> >>
> >> Think about a scenario where you have quad core, ducal cluster system
> >>
> >> |Cluster1| |cluster 2|
> >> | CPU0 | CPU1 | CPU2 | CPU3 | | CPU0 | CPU1 | CPU2 | CPU3 |
> >>
> >>
> >> Both clusters run from same voltage rail and have same PLL
> >> clocking them. But the cluster have their own power domain
> >> and all CPU's can power gate them-self to low power states.
> >> Clusters also have their own level2 caches.
> >>
> >> In this case, you will still save power if you try to pack
> >> load on one cluster. No ?
> >
> > yes, I need to update the description of SD_SHARE_POWERLINE because
> > I'm afraid I was not clear enough. SD_SHARE_POWERLINE includes the
> > power gating capacity of each core. For your example above, the
> > SD_SHARE_POWERLINE shoud be cleared at both MC and CPU level.
> >
> Thanks for clarification.
>
> >>
> >>
> >>> +void update_packing_domain(int cpu)
> >>> +{
> >>> + struct sched_domain *sd;
> >>> + int id = -1;
> >>> +
> >>> + sd = highest_flag_domain(cpu, SD_SHARE_POWERLINE);
> >>> + if (!sd)
> >>> + sd = rcu_dereference_check_sched_domain(cpu_rq(cpu)->sd);
> >>> + else
> >>> + sd = sd->parent;
> >>> +
> >>> + while (sd) {
> >>> + struct sched_group *sg = sd->groups;
> >>> + struct sched_group *pack = sg;
> >>> + struct sched_group *tmp = sg->next;
> >>> +
> >>> + /* 1st CPU of the sched domain is a good candidate */
> >>> + if (id == -1)
> >>> + id = cpumask_first(sched_domain_span(sd));
> >>> +
> >>> + /* loop the sched groups to find the best one */
> >>> + while (tmp != sg) {
> >>> + if (tmp->sgp->power * sg->group_weight <
> >>> + sg->sgp->power *
> >>> tmp->group_weight)
> >>> + pack = tmp;
> >>> + tmp = tmp->next;
> >>> + }
> >>> +
> >>> + /* we have found a better group */
> >>> + if (pack != sg)
> >>> + id = cpumask_first(sched_group_cpus(pack));
> >>> +
> >>> + /* Look for another CPU than itself */
> >>> + if ((id != cpu)
> >>> + || ((sd->parent) && !(sd->parent->flags &&
> >>> SD_LOAD_BALANCE)))
> >>
> >> Is the condition "!(sd->parent->flags && SD_LOAD_BALANCE)" for
> >> big.LITTLE kind of system where SD_LOAD_BALANCE may not be used ?
> >
> > No, packing small tasks is part of the load balance so if the
> > LOAD_BALANCE flag is cleared, we will not try to pack which is a kind
> > of load balance. There is no link with big.LITTLE
> >
> Now it make sense to me.
>
> >>
> >>
> >>> + break;
> >>> +
> >>> + sd = sd->parent;
> >>> + }
> >>> +
> >>> + pr_info(KERN_INFO "CPU%d packing on CPU%d\n", cpu, id);
> >>> + per_cpu(sd_pack_buddy, cpu) = id;
> >>> +}
> >>> +
> >>> #if BITS_PER_LONG == 32
> >>> # define WMULT_CONST (~0UL)
> >>> #else
> >>> @@ -3073,6 +3130,55 @@ static int select_idle_sibling(struct task_struct
> >>> *p, int target)
> >>> return target;
> >>> }
> >>>
> >>> +static inline bool is_buddy_busy(int cpu)
> >>> +{
> >>> + struct rq *rq = cpu_rq(cpu);
> >>> +
> >>> + /*
> >>> + * A busy buddy is a CPU with a high load or a small load with a
> >>> lot of
> >>> + * running tasks.
> >>> + */
> >>> + return ((rq->avg.usage_avg_sum << rq->nr_running) >
> >>> + rq->avg.runnable_avg_period);
> >>
> >> I agree busy CPU is the one with high load, but many small threads may
> >> not make CPU fully busy, right ? Should we just stick to the load
> >> parameter alone here ?
> >
> > IMO, the busy state of a CPU isn't only the load but also how many
> > threads are waiting for running on it. This formula tries to take into
> > account both inputs. If you have dozen of small tasks on a CPU, the
> > latency can be large even if the tasks are small.
> >
> Sure. Your point is to avoid throttling and probably use race for
> idle.
>
> >>
> >>
> >>> +}
> >>> +
> >>> +static inline bool is_light_task(struct task_struct *p)
> >>> +{
> >>> + /* A light task runs less than 25% in average */
> >>> + return ((p->se.avg.usage_avg_sum << 2) <
> >>> p->se.avg.runnable_avg_period);
> >>> +}
> >>
> >> Since the whole packing logic relies on the light threads only, the
> >> overall effectiveness is not significant. Infact with multiple tries on
> >> Dual core system, I didn't see any major improvement in power. I think
> >> we need to be more aggressive here. From the cover letter, I noticed
> >> that, you were concerned about any performance drop due to packing and
> >> may be that is the reason you chose the conservative threshold. But the
> >> fact is, if we want to save meaningful power, there will be slight
> >> performance drop which is expected.
> >
> > I think that everybody agrees that packing small tasks will save power
> > whereas it seems to be not so obvious for heavy task. But I may have
> > set the threshold a bit too low
> >
> I agree on packing saves power part for sure.
>
I'm not fully convinced that packing always saves power. For systems
with multiple cpu clusters where each cluster is a power domain and the
cpus have no individual power saving states it would probably be more
power efficient to spread the tasks and hope for more opportunities for
hitting cluster shutdown. If all tasks are packed on one cpu it will
keep the whole cluster up, while the remaining cpus are idling without
possibility for entering efficient power states.
Regards,
Morten
> > Up to which load, you would like to pack on 1 core of your dual core system ?
> > Can you provide more details of your load ? Have you got a trace that
> > you can share ?
> >
> More than how much load to pack, I was more looking from the power
> savings delta we can achieve by doing it. Some of the usecases like
> osidle, mp3, gallary are already very low power and that might be
> the reason I didn't notice major mA delta. Though the perf
> traces did show some filtering even at 25 % load. i tried upto
> 50 % threshold to see the effectiveness and there was more
> improvement and hence the suggestion about aggressiveness.
>
> May be you can try some of these use-cases on your setup instead of
> synthetic workload and see the results.
>
> Regards
> Santosh
>
>
>
>
> _______________________________________________
> linaro-dev mailing list
> linaro-dev at lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
^ permalink raw reply
* [PATCH 1/6] spi: imx: specify spi base for device tree probe
From: Mark Brown @ 2012-11-09 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352469625-32024-2-git-send-email-s.trumtrar@pengutronix.de>
On Fri, Nov 09, 2012 at 03:00:20PM +0100, Steffen Trumtrar wrote:
> * This breaks compatibility with user space applications between non-DT and DT.
> * On platforms that are in between DT and non-DT, it breaks registration of
> devices via spi_board_info.
> Use the same method as 7e6086d9e54a159a6257c02bb7fc5805c614aad2 does for gpios:
> Use alias to identify the spi port, and then specify the base via the port id.
> If alias is not defined in DT, allocate the base dynamically.
This sounds like a fix userspace and/or complete your DT conversion
problem...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121109/deb6a538/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: OMAP2+: Prevent redefinition errors for soc.h
From: Jon Hunter @ 2012-11-09 16:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121109162259.GO6801@atomide.com>
On 11/09/2012 10:22 AM, Tony Lindgren wrote:
> * Jon Hunter <jon-hunter@ti.com> [121109 08:21]:
>> If the header soc.h is included more than once in a source (for example
>> once directly by the source file and once indirectly by another header
>> file), then the compiler will generate redefintion errors for the macros
>> in soc.h. Prevent this by only allowing the content in soc.h to be
>> included once.
>>
>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
>> ---
>>
>> Please note that I ran into this problem when rebasing my dmtimer fixes
>> series [1] on Tony's Linux-OMAP master branch. I am including plat/cpu.h
>> in dmtimer.h and I found several other files including dmtimer.h are also
>> including soc.h and so generate a lot of errors.
>>
>> [1] http://marc.info/?l=linux-omap&m=135231490218361&w=2
>
> As these headers are private to mach-omap2, I'd rather not allow including
> them more than once so we can eventually clean up the includes further.
>
> We should include the headers directly where used, except for the
> legacy board-*.c files that will be going away anyways.
>
> Including the files directly should fix this easily, if not let me
> know.
The alternative fix is to ensure anyone including dmtimer.h also
includes soc.h. However, I did not know if we should have such a
dependency. If you are ok with that then that is what I will do for now.
It is not a massive change.
Cheers
Jon
^ permalink raw reply
* [PATCH v3 7/7] crypto: omap_sham: Remove usage of private DMA API
From: Kasatkin, Dmitry @ 2012-11-09 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352257033-32495-8-git-send-email-mgreer@animalcreek.com>
On Wed, Nov 7, 2012 at 4:57 AM, Mark A. Greer <mgreer@animalcreek.com> wrote:
> From: "Mark A. Greer" <mgreer@animalcreek.com>
>
> Remove usage of the private OMAP DMA API.
> The dmaengine API will be used instead.
>
> CC: Russell King <rmk+kernel@arm.linux.org.uk>
> CC: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
> ---
> drivers/crypto/omap-sham.c | 117 ---------------------------------------------
> 1 file changed, 117 deletions(-)
>
> diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
> index b57277c..ebb5255 100644
> --- a/drivers/crypto/omap-sham.c
> +++ b/drivers/crypto/omap-sham.c
> @@ -13,8 +13,6 @@
> * Some ideas are from old omap-sha1-md5.c driver.
> */
>
> -#define OMAP_SHAM_DMA_PRIVATE
> -
> #define pr_fmt(fmt) "%s: " fmt, __func__
>
> #include <linux/err.h>
> @@ -29,10 +27,8 @@
> #include <linux/platform_device.h>
> #include <linux/scatterlist.h>
> #include <linux/dma-mapping.h>
> -#ifndef OMAP_SHAM_DMA_PRIVATE
> #include <linux/dmaengine.h>
> #include <linux/omap-dma.h>
> -#endif
> #include <linux/pm_runtime.h>
> #include <linux/delay.h>
> #include <linux/crypto.h>
> @@ -43,12 +39,6 @@
> #include <crypto/hash.h>
> #include <crypto/internal/hash.h>
>
> -#ifdef OMAP_SHAM_DMA_PRIVATE
> -#include <plat/cpu.h>
> -#include <plat/dma.h>
> -#include <mach/irqs.h>
> -#endif
> -
> #define SHA_REG_DIGEST(x) (0x00 + ((x) * 0x04))
> #define SHA_REG_DIN(x) (0x1C + ((x) * 0x04))
>
> @@ -120,9 +110,7 @@ struct omap_sham_reqctx {
>
> /* walk state */
> struct scatterlist *sg;
> -#ifndef OMAP_SHAM_DMA_PRIVATE
> struct scatterlist sgl;
> -#endif
> unsigned int offset; /* offset in current sg */
> unsigned int total; /* total request */
>
> @@ -156,12 +144,7 @@ struct omap_sham_dev {
> int irq;
> spinlock_t lock;
> int err;
> -#ifdef OMAP_SHAM_DMA_PRIVATE
> - int dma;
> - int dma_lch;
> -#else
> struct dma_chan *dma_lch;
> -#endif
> struct tasklet_struct done_task;
>
> unsigned long flags;
> @@ -331,7 +314,6 @@ static int omap_sham_xmit_cpu(struct omap_sham_dev *dd, const u8 *buf,
> return -EINPROGRESS;
> }
>
> -#ifndef OMAP_SHAM_DMA_PRIVATE
> static void omap_sham_dma_callback(void *param)
> {
> struct omap_sham_dev *dd = param;
> @@ -339,34 +321,18 @@ static void omap_sham_dma_callback(void *param)
> set_bit(FLAGS_DMA_READY, &dd->flags);
> tasklet_schedule(&dd->done_task);
> }
> -#endif
>
> static int omap_sham_xmit_dma(struct omap_sham_dev *dd, dma_addr_t dma_addr,
> size_t length, int final, int is_sg)
> {
> struct omap_sham_reqctx *ctx = ahash_request_ctx(dd->req);
> -#ifdef OMAP_SHAM_DMA_PRIVATE
> - int len32;
> -#else
> struct dma_async_tx_descriptor *tx;
> struct dma_slave_config cfg;
> int ret;
> -#endif
>
> dev_dbg(dd->dev, "xmit_dma: digcnt: %d, length: %d, final: %d\n",
> ctx->digcnt, length, final);
>
> -#ifdef OMAP_SHAM_DMA_PRIVATE
> - len32 = DIV_ROUND_UP(length, sizeof(u32));
> -
> - omap_set_dma_transfer_params(dd->dma_lch, OMAP_DMA_DATA_TYPE_S32, len32,
> - 1, OMAP_DMA_SYNC_PACKET, dd->dma,
> - OMAP_DMA_DST_SYNC_PREFETCH);
> -
> - omap_set_dma_src_params(dd->dma_lch, 0, OMAP_DMA_AMODE_POST_INC,
> - dma_addr, 0, 0);
> -
> -#else
> memset(&cfg, 0, sizeof(cfg));
>
> cfg.dst_addr = dd->phys_base + SHA_REG_DIN(0);
> @@ -406,7 +372,6 @@ static int omap_sham_xmit_dma(struct omap_sham_dev *dd, dma_addr_t dma_addr,
>
> tx->callback = omap_sham_dma_callback;
> tx->callback_param = dd;
> -#endif
>
> omap_sham_write_ctrl(dd, length, final, 1);
>
> @@ -417,12 +382,8 @@ static int omap_sham_xmit_dma(struct omap_sham_dev *dd, dma_addr_t dma_addr,
>
> set_bit(FLAGS_DMA_ACTIVE, &dd->flags);
>
> -#ifdef OMAP_SHAM_DMA_PRIVATE
> - omap_start_dma(dd->dma_lch);
> -#else
> dmaengine_submit(tx);
> dma_async_issue_pending(dd->dma_lch);
> -#endif
>
> return -EINPROGRESS;
> }
> @@ -528,7 +489,6 @@ static int omap_sham_update_dma_start(struct omap_sham_dev *dd)
> if (ctx->bufcnt || ctx->offset)
> return omap_sham_update_dma_slow(dd);
>
> -#ifndef OMAP_SHAM_DMA_PRIVATE
> /*
> * Don't use the sg interface when the transfer size is less
> * than the number of elements in a DMA frame. Otherwise,
> @@ -537,7 +497,6 @@ static int omap_sham_update_dma_start(struct omap_sham_dev *dd)
> */
> if (ctx->total < (DST_MAXBURST * sizeof(u32)))
> return omap_sham_update_dma_slow(dd);
> -#endif
>
> dev_dbg(dd->dev, "fast: digcnt: %d, bufcnt: %u, total: %u\n",
> ctx->digcnt, ctx->bufcnt, ctx->total);
> @@ -599,11 +558,7 @@ static int omap_sham_update_dma_stop(struct omap_sham_dev *dd)
> {
> struct omap_sham_reqctx *ctx = ahash_request_ctx(dd->req);
>
> -#ifdef OMAP_SHAM_DMA_PRIVATE
> - omap_stop_dma(dd->dma_lch);
> -#else
> dmaengine_terminate_all(dd->dma_lch);
> -#endif
>
> if (ctx->flags & BIT(FLAGS_SG)) {
> dma_unmap_sg(dd->dev, ctx->sg, 1, DMA_TO_DEVICE);
> @@ -807,18 +762,6 @@ static int omap_sham_handle_queue(struct omap_sham_dev *dd,
> if (err)
> goto err1;
>
> -#ifdef OMAP_SHAM_DMA_PRIVATE
> - omap_set_dma_dest_params(dd->dma_lch, 0,
> - OMAP_DMA_AMODE_CONSTANT,
> - dd->phys_base + SHA_REG_DIN(0), 0, 16);
> -
> - omap_set_dma_dest_burst_mode(dd->dma_lch,
> - OMAP_DMA_DATA_BURST_16);
> -
> - omap_set_dma_src_burst_mode(dd->dma_lch,
> - OMAP_DMA_DATA_BURST_4);
Burst mode significantly improves performance.
How do you configure burst mode with new API?
- Dmitry
> -#endif
> -
> if (ctx->digcnt)
> /* request has changed - restore hash */
> omap_sham_copy_hash(req, 0);
> @@ -1209,55 +1152,13 @@ static irqreturn_t omap_sham_irq(int irq, void *dev_id)
> return IRQ_HANDLED;
> }
>
> -#ifdef OMAP_SHAM_DMA_PRIVATE
> -static void omap_sham_dma_callback(int lch, u16 ch_status, void *data)
> -{
> - struct omap_sham_dev *dd = data;
> -
> - if (ch_status != OMAP_DMA_BLOCK_IRQ) {
> - pr_err("omap-sham DMA error status: 0x%hx\n", ch_status);
> - dd->err = -EIO;
> - clear_bit(FLAGS_INIT, &dd->flags);/* request to re-initialize */
> - }
> -
> - set_bit(FLAGS_DMA_READY, &dd->flags);
> - tasklet_schedule(&dd->done_task);
> -}
> -
> -static int omap_sham_dma_init(struct omap_sham_dev *dd)
> -{
> - int err;
> -
> - dd->dma_lch = -1;
> -
> - err = omap_request_dma(dd->dma, dev_name(dd->dev),
> - omap_sham_dma_callback, dd, &dd->dma_lch);
> - if (err) {
> - dev_err(dd->dev, "Unable to request DMA channel\n");
> - return err;
> - }
> -
> - return 0;
> -}
> -
> -static void omap_sham_dma_cleanup(struct omap_sham_dev *dd)
> -{
> - if (dd->dma_lch >= 0) {
> - omap_free_dma(dd->dma_lch);
> - dd->dma_lch = -1;
> - }
> -}
> -#endif
> -
> static int __devinit omap_sham_probe(struct platform_device *pdev)
> {
> struct omap_sham_dev *dd;
> struct device *dev = &pdev->dev;
> struct resource *res;
> -#ifndef OMAP_SHAM_DMA_PRIVATE
> dma_cap_mask_t mask;
> unsigned dma_chan;
> -#endif
> int err, i, j;
>
> dd = kzalloc(sizeof(struct omap_sham_dev), GFP_KERNEL);
> @@ -1292,11 +1193,7 @@ static int __devinit omap_sham_probe(struct platform_device *pdev)
> err = -ENODEV;
> goto res_err;
> }
> -#ifdef OMAP_SHAM_DMA_PRIVATE
> - dd->dma = res->start;
> -#else
> dma_chan = res->start;
> -#endif
>
> /* Get the IRQ */
> dd->irq = platform_get_irq(pdev, 0);
> @@ -1313,11 +1210,6 @@ static int __devinit omap_sham_probe(struct platform_device *pdev)
> goto res_err;
> }
>
> -#ifdef OMAP_SHAM_DMA_PRIVATE
> - err = omap_sham_dma_init(dd);
> - if (err)
> - goto dma_err;
> -#else
> dma_cap_zero(mask);
> dma_cap_set(DMA_SLAVE, mask);
>
> @@ -1328,7 +1220,6 @@ static int __devinit omap_sham_probe(struct platform_device *pdev)
> err = -ENXIO;
> goto dma_err;
> }
> -#endif
>
> dd->io_base = ioremap(dd->phys_base, SZ_4K);
> if (!dd->io_base) {
> @@ -1364,11 +1255,7 @@ err_algs:
> iounmap(dd->io_base);
> pm_runtime_disable(dev);
> io_err:
> -#ifdef OMAP_SHAM_DMA_PRIVATE
> - omap_sham_dma_cleanup(dd);
> -#else
> dma_release_channel(dd->dma_lch);
> -#endif
> dma_err:
> if (dd->irq >= 0)
> free_irq(dd->irq, dd);
> @@ -1397,11 +1284,7 @@ static int __devexit omap_sham_remove(struct platform_device *pdev)
> tasklet_kill(&dd->done_task);
> iounmap(dd->io_base);
> pm_runtime_disable(&pdev->dev);
> -#ifdef OMAP_SHAM_DMA_PRIVATE
> - omap_sham_dma_cleanup(dd);
> -#else
> dma_release_channel(dd->dma_lch);
> -#endif
> if (dd->irq >= 0)
> free_irq(dd->irq, dd);
> kfree(dd);
> --
> 1.7.12
>
^ permalink raw reply
* [PATCH] ARM: OMAP2+: Prevent redefinition errors for soc.h
From: Tony Lindgren @ 2012-11-09 16:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352477961-7634-1-git-send-email-jon-hunter@ti.com>
* Jon Hunter <jon-hunter@ti.com> [121109 08:21]:
> If the header soc.h is included more than once in a source (for example
> once directly by the source file and once indirectly by another header
> file), then the compiler will generate redefintion errors for the macros
> in soc.h. Prevent this by only allowing the content in soc.h to be
> included once.
>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> ---
>
> Please note that I ran into this problem when rebasing my dmtimer fixes
> series [1] on Tony's Linux-OMAP master branch. I am including plat/cpu.h
> in dmtimer.h and I found several other files including dmtimer.h are also
> including soc.h and so generate a lot of errors.
>
> [1] http://marc.info/?l=linux-omap&m=135231490218361&w=2
As these headers are private to mach-omap2, I'd rather not allow including
them more than once so we can eventually clean up the includes further.
We should include the headers directly where used, except for the
legacy board-*.c files that will be going away anyways.
Including the files directly should fix this easily, if not let me
know.
Regards,
Tony
> arch/arm/mach-omap2/soc.h | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
> index 0700964..6b270a0 100644
> --- a/arch/arm/mach-omap2/soc.h
> +++ b/arch/arm/mach-omap2/soc.h
> @@ -25,6 +25,9 @@
> *
> */
>
> +#ifndef __ARCH_ARM_MACH_OMAP2_SOC_H
> +#define __ARCH_ARM_MACH_OMAP2_SOC_H
> +
> #include "omap24xx.h"
> #include "omap34xx.h"
> #include "omap44xx.h"
> @@ -471,3 +474,4 @@ OMAP4_HAS_FEATURE(mpu_1_5ghz, MPU_1_5GHZ)
>
> #endif /* __ASSEMBLY__ */
>
> +#endif /* __ARCH_ARM_MACH_OMAP2_SOC_H */
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH] ARM: OMAP2+: Prevent redefinition errors for soc.h
From: Jon Hunter @ 2012-11-09 16:19 UTC (permalink / raw)
To: linux-arm-kernel
If the header soc.h is included more than once in a source (for example
once directly by the source file and once indirectly by another header
file), then the compiler will generate redefintion errors for the macros
in soc.h. Prevent this by only allowing the content in soc.h to be
included once.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
Please note that I ran into this problem when rebasing my dmtimer fixes
series [1] on Tony's Linux-OMAP master branch. I am including plat/cpu.h
in dmtimer.h and I found several other files including dmtimer.h are also
including soc.h and so generate a lot of errors.
[1] http://marc.info/?l=linux-omap&m=135231490218361&w=2
arch/arm/mach-omap2/soc.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index 0700964..6b270a0 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -25,6 +25,9 @@
*
*/
+#ifndef __ARCH_ARM_MACH_OMAP2_SOC_H
+#define __ARCH_ARM_MACH_OMAP2_SOC_H
+
#include "omap24xx.h"
#include "omap34xx.h"
#include "omap44xx.h"
@@ -471,3 +474,4 @@ OMAP4_HAS_FEATURE(mpu_1_5ghz, MPU_1_5GHZ)
#endif /* __ASSEMBLY__ */
+#endif /* __ARCH_ARM_MACH_OMAP2_SOC_H */
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 3/7] ARM: OMAP3xxx: hwmod: Convert SHAM crypto device data to hwmod
From: Kasatkin, Dmitry @ 2012-11-09 16:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352257033-32495-4-git-send-email-mgreer@animalcreek.com>
On Wed, Nov 7, 2012 at 4:57 AM, Mark A. Greer <mgreer@animalcreek.com> wrote:
> From: "Mark A. Greer" <mgreer@animalcreek.com>
>
> Convert the device data for the OMAP3 SHAM2 (SHA1/MD5) crypto IP
> from explicit platform_data to hwmod.
>
> CC: Paul Walmsley <paul@pwsan.com>
> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
> ---
> arch/arm/mach-omap2/clock3xxx_data.c | 1 +
> arch/arm/mach-omap2/devices.c | 42 ++-------------------
> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 60 ++++++++++++++++++++++++++++++
> 3 files changed, 64 insertions(+), 39 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c
> index 1f42c9d..6f14d9b 100644
> --- a/arch/arm/mach-omap2/clock3xxx_data.c
> +++ b/arch/arm/mach-omap2/clock3xxx_data.c
> @@ -3342,6 +3342,7 @@ static struct omap_clk omap3xxx_clks[] = {
> CLK(NULL, "icr_ick", &icr_ick, CK_34XX | CK_36XX),
> CLK("omap-aes", "ick", &aes2_ick, CK_34XX | CK_36XX),
> CLK("omap-sham", "ick", &sha12_ick, CK_34XX | CK_36XX),
> + CLK(NULL, "sha12_ick", &sha12_ick, CK_34XX | CK_36XX),
> CLK(NULL, "des2_ick", &des2_ick, CK_34XX | CK_36XX),
> CLK("omap_hsmmc.1", "ick", &mmchs2_ick, CK_3XXX),
> CLK("omap_hsmmc.0", "ick", &mmchs1_ick, CK_3XXX),
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index f18fa50..f38ac9d 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -36,6 +36,7 @@
> #include "devices.h"
> #include "cm2xxx_3xxx.h"
> #include "cm-regbits-24xx.h"
> +#include "cm-regbits-34xx.h"
>
> #define L3_MODULES_MAX_LEN 12
> #define L3_MODULES 3
> @@ -453,38 +454,9 @@ static void omap_init_rng(void)
> WARN(IS_ERR(pdev), "Can't build omap_device for omap_rng\n");
> }
>
> -#if defined(CONFIG_CRYPTO_DEV_OMAP_SHAM) || defined(CONFIG_CRYPTO_DEV_OMAP_SHAM_MODULE)
> -
> -#ifdef CONFIG_ARCH_OMAP3
> -static struct resource omap3_sham_resources[] = {
> - {
> - .start = OMAP34XX_SEC_SHA1MD5_BASE,
> - .end = OMAP34XX_SEC_SHA1MD5_BASE + 0x64,
> - .flags = IORESOURCE_MEM,
> - },
> - {
> - .start = 49 + OMAP_INTC_START,
> - .flags = IORESOURCE_IRQ,
> - },
> - {
> - .start = OMAP34XX_DMA_SHA1MD5_RX,
> - .flags = IORESOURCE_DMA,
> - }
> -};
Ok... it is also for OMAP3..
> -static int omap3_sham_resources_sz = ARRAY_SIZE(omap3_sham_resources);
> -#else
> -#define omap3_sham_resources NULL
> -#define omap3_sham_resources_sz 0
> -#endif
> -
> -static struct platform_device sham_device = {
> - .name = "omap-sham",
> - .id = -1,
> -};
> -
> -static void omap_init_sham(void)
> +static void __init omap_init_sham(void)
> {
> - if (cpu_is_omap24xx()) {
> + if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
> struct omap_hwmod *oh;
> struct platform_device *pdev;
>
> @@ -495,18 +467,10 @@ static void omap_init_sham(void)
> pdev = omap_device_build("omap-sham", -1, oh, NULL, 0, NULL,
> 0, 0);
> WARN(IS_ERR(pdev), "Can't build omap_device for omap-sham\n");
> - } else if (cpu_is_omap34xx()) {
> - sham_device.resource = omap3_sham_resources;
> - sham_device.num_resources = omap3_sham_resources_sz;
> - platform_device_register(&sham_device);
> } else {
> pr_err("%s: platform not supported\n", __func__);
> - return;
> }
> }
> -#else
> -static inline void omap_init_sham(void) { }
> -#endif
>
> #if defined(CONFIG_CRYPTO_DEV_OMAP_AES) || defined(CONFIG_CRYPTO_DEV_OMAP_AES_MODULE)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> index f67b7ee..785a0c5 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
> @@ -3543,6 +3543,65 @@ static struct omap_hwmod_ocp_if omap3xxx_l3_main__gpmc = {
> .user = OCP_USER_MPU | OCP_USER_SDMA,
> };
>
> +/* l4_core -> SHAM2 (SHA1/MD5) (similar to omap24xx) */
> +static struct omap_hwmod_class_sysconfig omap3_sham_sysc = {
> + .rev_offs = 0x5c,
> + .sysc_offs = 0x60,
> + .syss_offs = 0x64,
> + .sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE |
> + SYSS_HAS_RESET_STATUS),
> + .sysc_fields = &omap_hwmod_sysc_type1,
> +};
> +
> +static struct omap_hwmod_class omap3xxx_sham_class = {
> + .name = "sham",
> + .sysc = &omap3_sham_sysc,
> +};
> +
> +struct omap_hwmod_irq_info omap3_sham_mpu_irqs[] = {
> + { .irq = 49 + OMAP_INTC_START, },
> + { .irq = -1 }
> +};
> +
> +struct omap_hwmod_dma_info omap3_sham_sdma_reqs[] = {
> + { .name = "rx", .dma_req = OMAP34XX_DMA_SHA1MD5_RX, },
> + { .dma_req = -1 }
> +};
> +
> +struct omap_hwmod omap3xxx_sham_hwmod = {
> + .name = "sham",
> + .mpu_irqs = omap3_sham_mpu_irqs,
> + .sdma_reqs = omap3_sham_sdma_reqs,
> + .main_clk = "sha12_ick",
> + .prcm = {
> + .omap2 = {
> + .module_offs = CORE_MOD,
> + .prcm_reg_id = 1,
> + .module_bit = OMAP3430_EN_SHA12_SHIFT,
> + .idlest_reg_id = 1,
> + .idlest_idle_bit = OMAP3430_ST_SHA12_SHIFT,
> + },
> + },
> + .class = &omap3xxx_sham_class,
> +};
> +
> +static struct omap_hwmod_addr_space omap3xxx_sham_addrs[] = {
> + {
> + .pa_start = 0x480c3000,
> + .pa_end = 0x480c3000 + 0x64 - 1,
> + .flags = ADDR_TYPE_RT
> + },
> + { }
> +};
> +
> +static struct omap_hwmod_ocp_if omap3xxx_l4_core__sham = {
> + .master = &omap3xxx_l4_core_hwmod,
> + .slave = &omap3xxx_sham_hwmod,
> + .clk = "sha12_ick",
> + .addr = omap3xxx_sham_addrs,
> + .user = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> static struct omap_hwmod_ocp_if *omap3xxx_hwmod_ocp_ifs[] __initdata = {
> &omap3xxx_l3_main__l4_core,
> &omap3xxx_l3_main__l4_per,
> @@ -3596,6 +3655,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_hwmod_ocp_ifs[] __initdata = {
> /* GP-only hwmod links */
> static struct omap_hwmod_ocp_if *omap3xxx_gp_hwmod_ocp_ifs[] __initdata = {
> &omap3xxx_l4_sec__timer12,
> + &omap3xxx_l4_core__sham,
> NULL
> };
>
> --
> 1.7.12
>
^ permalink raw reply
* [PATCH v3 1/7] ARM: OMAP2xxx: hwmod: Convert SHAM crypto device data to hwmod
From: Kasatkin, Dmitry @ 2012-11-09 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352257033-32495-2-git-send-email-mgreer@animalcreek.com>
Hello,
On Wed, Nov 7, 2012 at 4:57 AM, Mark A. Greer <mgreer@animalcreek.com> wrote:
> From: "Mark A. Greer" <mgreer@animalcreek.com>
>
> Convert the device data for the OMAP2 SHAM crypto IP from
> explicit platform_data to hwmod.
>
> CC: Paul Walmsley <paul@pwsan.com>
> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
> ---
> arch/arm/mach-omap2/clock2430_data.c | 1 +
> arch/arm/mach-omap2/devices.c | 34 ++++++++------------
> arch/arm/mach-omap2/omap_hwmod_2420_data.c | 1 +
> arch/arm/mach-omap2/omap_hwmod_2430_data.c | 1 +
> .../mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 18 +++++++++++
> arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 37 ++++++++++++++++++++++
> arch/arm/mach-omap2/omap_hwmod_common_data.h | 2 ++
> 7 files changed, 73 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/clock2430_data.c b/arch/arm/mach-omap2/clock2430_data.c
> index 22404fe..4d52ec6 100644
> --- a/arch/arm/mach-omap2/clock2430_data.c
> +++ b/arch/arm/mach-omap2/clock2430_data.c
> @@ -1993,6 +1993,7 @@ static struct omap_clk omap2430_clks[] = {
> CLK(NULL, "sdrc_ick", &sdrc_ick, CK_243X),
> CLK(NULL, "des_ick", &des_ick, CK_243X),
> CLK("omap-sham", "ick", &sha_ick, CK_243X),
> + CLK(NULL, "sha_ick", &sha_ick, CK_242X),
> CLK("omap_rng", "ick", &rng_ick, CK_243X),
> CLK(NULL, "rng_ick", &rng_ick, CK_243X),
> CLK("omap-aes", "ick", &aes_ick, CK_243X),
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index cba60e0..f18fa50 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -34,6 +34,8 @@
> #include "mux.h"
> #include "control.h"
> #include "devices.h"
> +#include "cm2xxx_3xxx.h"
> +#include "cm-regbits-24xx.h"
>
> #define L3_MODULES_MAX_LEN 12
> #define L3_MODULES 3
> @@ -453,24 +455,6 @@ static void omap_init_rng(void)
>
> #if defined(CONFIG_CRYPTO_DEV_OMAP_SHAM) || defined(CONFIG_CRYPTO_DEV_OMAP_SHAM_MODULE)
>
> -#ifdef CONFIG_ARCH_OMAP2
> -static struct resource omap2_sham_resources[] = {
> - {
> - .start = OMAP24XX_SEC_SHA1MD5_BASE,
> - .end = OMAP24XX_SEC_SHA1MD5_BASE + 0x64,
> - .flags = IORESOURCE_MEM,
> - },
> - {
> - .start = 51 + OMAP_INTC_START,
> - .flags = IORESOURCE_IRQ,
> - }
> -};
> -static int omap2_sham_resources_sz = ARRAY_SIZE(omap2_sham_resources);
> -#else
> -#define omap2_sham_resources NULL
> -#define omap2_sham_resources_sz 0
> -#endif
> -
> #ifdef CONFIG_ARCH_OMAP3
> static struct resource omap3_sham_resources[] = {
> {
> @@ -501,16 +485,24 @@ static struct platform_device sham_device = {
> static void omap_init_sham(void)
> {
> if (cpu_is_omap24xx()) {
> - sham_device.resource = omap2_sham_resources;
> - sham_device.num_resources = omap2_sham_resources_sz;
> + struct omap_hwmod *oh;
> + struct platform_device *pdev;
> +
> + oh = omap_hwmod_lookup("sham");
> + if (!oh)
> + return;
> +
> + pdev = omap_device_build("omap-sham", -1, oh, NULL, 0, NULL,
> + 0, 0);
> + WARN(IS_ERR(pdev), "Can't build omap_device for omap-sham\n");
> } else if (cpu_is_omap34xx()) {
> sham_device.resource = omap3_sham_resources;
> sham_device.num_resources = omap3_sham_resources_sz;
> + platform_device_register(&sham_device);
Why changes are only for OMAP2?
OMAP3 is also the same class.
> } else {
> pr_err("%s: platform not supported\n", __func__);
> return;
> }
> - platform_device_register(&sham_device);
> }
> #else
> static inline void omap_init_sham(void) { }
> diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> index b5db600..b102a53 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
> @@ -603,6 +603,7 @@ static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[] __initdata = {
> &omap2420_l4_core__mcbsp2,
> &omap2420_l4_core__msdi1,
> &omap2xxx_l4_core__rng,
> + &omap2xxx_l4_core__sham,
> &omap2420_l4_core__hdq1w,
> &omap2420_l4_wkup__counter_32k,
> &omap2420_l3__gpmc,
> diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> index c455e41..b1ce7b0 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
> @@ -963,6 +963,7 @@ static struct omap_hwmod_ocp_if *omap2430_hwmod_ocp_ifs[] __initdata = {
> &omap2430_l4_core__mcbsp5,
> &omap2430_l4_core__hdq1w,
> &omap2xxx_l4_core__rng,
> + &omap2xxx_l4_core__sham,
> &omap2430_l4_wkup__counter_32k,
> &omap2430_l3__gpmc,
> NULL,
> diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c b/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
> index 1a1287d..bb314c5 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_interconnect_data.c
> @@ -138,6 +138,15 @@ static struct omap_hwmod_addr_space omap2_rng_addr_space[] = {
> { }
> };
>
> +struct omap_hwmod_addr_space omap2xxx_sham_addrs[] = {
> + {
> + .pa_start = 0x480a4000,
> + .pa_end = 0x480a4000 + 0x64 - 1,
> + .flags = ADDR_TYPE_RT
> + },
> + { }
> +};
Why not using macros as it was before?
OMAP24XX_SEC_SHA1MD5_BASE
> +
> /*
> * Common interconnect data
> */
> @@ -389,3 +398,12 @@ struct omap_hwmod_ocp_if omap2xxx_l4_core__rng = {
> .addr = omap2_rng_addr_space,
> .user = OCP_USER_MPU | OCP_USER_SDMA,
> };
> +
> +/* l4 core -> sham interface */
> +struct omap_hwmod_ocp_if omap2xxx_l4_core__sham = {
> + .master = &omap2xxx_l4_core_hwmod,
> + .slave = &omap2xxx_sham_hwmod,
> + .clk = "sha_ick",
> + .addr = omap2xxx_sham_addrs,
> + .user = OCP_USER_MPU,
> +};
> diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
> index bd9220e..a041670 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
> @@ -851,3 +851,40 @@ struct omap_hwmod omap2xxx_rng_hwmod = {
> .flags = HWMOD_INIT_NO_RESET,
> .class = &omap2_rng_hwmod_class,
> };
> +
> +/* SHAM */
> +
> +static struct omap_hwmod_class_sysconfig omap2_sham_sysc = {
> + .rev_offs = 0x5c,
> + .sysc_offs = 0x60,
> + .syss_offs = 0x64,
> + .sysc_flags = (SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE |
> + SYSS_HAS_RESET_STATUS),
> + .sysc_fields = &omap_hwmod_sysc_type1,
> +};
> +
> +static struct omap_hwmod_class omap2xxx_sham_class = {
> + .name = "sham",
> + .sysc = &omap2_sham_sysc,
> +};
> +
> +struct omap_hwmod_irq_info omap2_sham_mpu_irqs[] = {
> + { .irq = 51 + OMAP_INTC_START, },
> + { .irq = -1 }
> +};
> +
> +struct omap_hwmod omap2xxx_sham_hwmod = {
> + .name = "sham",
> + .mpu_irqs = omap2_sham_mpu_irqs,
> + .main_clk = "l4_ck",
> + .prcm = {
> + .omap2 = {
> + .module_offs = CORE_MOD,
> + .prcm_reg_id = 4,
> + .module_bit = OMAP24XX_EN_SHA_SHIFT,
> + .idlest_reg_id = 4,
> + .idlest_idle_bit = OMAP24XX_ST_SHA_SHIFT,
> + },
> + },
> + .class = &omap2xxx_sham_class,
> +};
> diff --git a/arch/arm/mach-omap2/omap_hwmod_common_data.h b/arch/arm/mach-omap2/omap_hwmod_common_data.h
> index 2bc8f17..74a7b7a 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_common_data.h
> +++ b/arch/arm/mach-omap2/omap_hwmod_common_data.h
> @@ -78,6 +78,7 @@ extern struct omap_hwmod omap2xxx_mcspi2_hwmod;
> extern struct omap_hwmod omap2xxx_counter_32k_hwmod;
> extern struct omap_hwmod omap2xxx_gpmc_hwmod;
> extern struct omap_hwmod omap2xxx_rng_hwmod;
> +extern struct omap_hwmod omap2xxx_sham_hwmod;
>
> /* Common interface data across OMAP2xxx */
> extern struct omap_hwmod_ocp_if omap2xxx_l3_main__l4_core;
> @@ -105,6 +106,7 @@ extern struct omap_hwmod_ocp_if omap2xxx_l4_core__dss_dispc;
> extern struct omap_hwmod_ocp_if omap2xxx_l4_core__dss_rfbi;
> extern struct omap_hwmod_ocp_if omap2xxx_l4_core__dss_venc;
> extern struct omap_hwmod_ocp_if omap2xxx_l4_core__rng;
> +extern struct omap_hwmod_ocp_if omap2xxx_l4_core__sham;
>
> /* Common IP block data */
> extern struct omap_hwmod_dma_info omap2_uart1_sdma_reqs[];
> --
> 1.7.12
>
^ permalink raw reply
* [PATCH 6/6] ASoC: fsl: add imx-wm8974 machine driver
From: Mark Brown @ 2012-11-09 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352469625-32024-7-git-send-email-s.trumtrar@pengutronix.de>
On Fri, Nov 09, 2012 at 03:00:25PM +0100, Steffen Trumtrar wrote:
> +static int imx_wm8974_dai_init(struct snd_soc_pcm_runtime *rtd)
> +{
> + struct imx_wm8974_data *data = container_of(rtd->card,
> + struct imx_wm8974_data, card);
> + struct device *dev = rtd->card->dev;
> + int ret;
> +
> + /* the pll stability peaks at N=8 and around 90MHz.
> + * This values are best reached with a 12.288MHz or
> + * 11.289MHz clock. As the first is closer to N=8 in
> + * more situations, chose 12.288MHz as the target clock
> + * (ref: datasheet section "Master Clock and Phase Locked Loop")*/
> + ret = snd_soc_dai_set_pll(rtd->codec_dai, 0, 0, data->clk_frequency,
> + 12288000);
This seems far from ideal - it's starting the PLL at system boot and
just leaving it running. This will be power inefficient when the system
is not playing audio as the PLL will be consuming power but not used for
anything. You could also do the same thing with the MCLK.
Note also that a 12.288MHz clock is only suitable for 8kHz based sample
rates, for CD audio 44.1kHz based rates like most media files 11.2896MHz
should be chosen. The driver may want to switch dynamically at runtime
to support the widest possible range of rates.
> + data->codec_clk = clk_get(&codec_pdev->dev, NULL);
> + if (IS_ERR(data->codec_clk)) {
devm_clk_get() - this'd free the clock that's leaked on removal.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121109/7de65984/attachment.sig>
^ permalink raw reply
* [PATCH] dma: add new DMA control commands
From: Artem Bityutskiy @ 2012-11-09 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507FBDF1.5050602@freescale.com>
On Thu, 2012-10-18 at 16:29 +0800, Huang Shijie wrote:
> ? 2012?10?18? 16:16, Marek Vasut ??:
> > So we can't stream data from the chip? About time to adjust the MTD framework to
> > allow that. Maybe implement a command queue?
> >
>
> to Artem & David:
> is this possible to stream the data out with a command queue?
Well, I think there was no HW which supported reading multiple pages
with DMA before, are your sure yours support this? Usually reading a
NAND page consists of 2 phases - loading the NAND array contents to a
controller buffer, and then copying that to RAM. And the second part is
something people sometimes do with DMA, AFAIU.
If your HW supports this, sure the MTD framework can be re-worked. Or
you may write your own 'mtd->_read()' / 'mtd->_write()' implementation.
--
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121109/12358221/attachment.sig>
^ permalink raw reply
* [GIT PULL] New ASID allocator for 3.8
From: Will Deacon @ 2012-11-09 15:09 UTC (permalink / raw)
To: linux-arm-kernel
Hi Russell,
This has been in -next for a while now and we've been playing with it
internally for even longer than that. It hasn't received as much review
as I would have liked but I'm confident in my understanding of the code.
Cheers,
Will
The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89:
Linux 3.7-rc4 (2012-11-04 11:07:39 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git asid-allocation
Will Deacon (3):
ARM: mm: remove IPI broadcasting on ASID rollover
ARM: mm: avoid taking ASID spinlock on fastpath
ARM: mm: use bitmap operations when allocating new ASIDs
arch/arm/include/asm/mmu.h | 11 +--
arch/arm/include/asm/mmu_context.h | 82 +--------------
arch/arm/mm/context.c | 207 +++++++++++++++++++-----------------
3 files changed, 115 insertions(+), 185 deletions(-)
^ permalink raw reply
* [GIT PULL] prot-none fixes for 3.8
From: Will Deacon @ 2012-11-09 15:08 UTC (permalink / raw)
To: linux-arm-kernel
Hi Russell,
This patch series fixes the treatment of PROT_NONE pages for 2-level and
3-level page tables so that the kernel cannot be used to access these
pages on behalf of userspace when !CPU_USE_DOMAINS.
Thanks,
Will
The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89:
Linux 3.7-rc4 (2012-11-04 11:07:39 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git for-rmk/prot-none
Will Deacon (4):
ARM: mm: use pteval_t to represent page protection values
ARM: mm: don't use the access flag permissions mechanism for classic MMU
ARM: mm: introduce L_PTE_VALID for page table entries
ARM: mm: introduce present, faulting entries for PAGE_NONE
arch/arm/include/asm/pgtable-2level.h | 2 ++
arch/arm/include/asm/pgtable-3level.h | 4 +++-
arch/arm/include/asm/pgtable.h | 10 ++++------
arch/arm/mm/mmu.c | 2 +-
arch/arm/mm/proc-macros.S | 4 ++++
arch/arm/mm/proc-v7-2level.S | 10 +++++++---
arch/arm/mm/proc-v7-3level.S | 5 ++++-
7 files changed, 25 insertions(+), 12 deletions(-)
^ permalink raw reply
* [GIT PULL] hw-breakpoint updates for 3.8
From: Will Deacon @ 2012-11-09 15:06 UTC (permalink / raw)
To: linux-arm-kernel
Hi Russell,
This series of patches reworks much of the debug register reset sequence
for ARM debug architecture 7.1 in light of some comments from Stephen
Boyd.
Thanks,
Will
The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89:
Linux 3.7-rc4 (2012-11-04 11:07:39 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git hw-breakpoint
Dietmar Eggemann (1):
ARM: hw_breakpoint: use CRn as argument for debug reg accessor macros
Will Deacon (7):
ARM: hw_breakpoint: only clear OS lock when implemented on v7
ARM: hw_breakpoint: fix monitor mode detection with v7.1
ARM: hw_breakpoint: fix ordering of debug register reset sequence
ARM: hw_breakpoint: don't try to clear v6 debug registers during boot
ARM: hw_breakpoint: make boot quieter without CPUID feature registers
ARM: hw_breakpoint: check if monitor mode is enabled during validation
ARM: hw_breakpoint: kill WARN_ONCE usage
arch/arm/include/asm/hw_breakpoint.h | 8 +-
arch/arm/kernel/hw_breakpoint.c | 154 +++++++++++++++++++---------------
2 files changed, 89 insertions(+), 73 deletions(-)
^ permalink raw reply
* [GIT PULL] perf updates for 3.8
From: Will Deacon @ 2012-11-09 15:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi Russell,
This patch series is largely a continuation of the ongoing perf work
to support multi-cluster, but there are also a couple of other random
patches for OMAP (Acked by Tony) and future-proofing for KVM from Marc.
Cheers,
Will
The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89:
Linux 3.7-rc4 (2012-11-04 11:07:39 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/updates
Jon Hunter (1):
ARM: PMU: fix runtime PM enable
Marc Zyngier (1):
ARM: perf: add guest vs host discrimination
Mark Rutland (1):
ARM: perf: register cpu_notifier at driver init
Sudeep KarkadaNagesha (3):
ARM: perf: allocate CPU PMU dynamically at probe time
ARM: perf: consistently use struct perf_event in arm_pmu functions
ARM: perf: check ARMv7 counter validity on a per-pmu basis
Will Deacon (2):
ARM: perf: return NOTIFY_DONE from cpu notifier when no available PMU
ARM: perf: consistently use arm_pmu->name for PMU name
arch/arm/include/asm/perf_event.h | 5 +
arch/arm/include/asm/pmu.h | 28 ++---
arch/arm/kernel/perf_event.c | 85 ++++++++----
arch/arm/kernel/perf_event_cpu.c | 74 +++++++----
arch/arm/kernel/perf_event_v6.c | 126 +++++++++---------
arch/arm/kernel/perf_event_v7.c | 246 ++++++++++++++++------------------
arch/arm/kernel/perf_event_xscale.c | 157 ++++++++++++-----------
arch/arm/mach-omap2/pmu.c | 2 -
8 files changed, 385 insertions(+), 338 deletions(-)
^ permalink raw reply
* [PATCH v2 1/5] ARM: kernel: smp_setup_processor_id() updates
From: Lorenzo Pieralisi @ 2012-11-09 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121109144446.GC17405@mudshark.cambridge.arm.com>
On Fri, Nov 09, 2012 at 02:44:46PM +0000, Will Deacon wrote:
> On Fri, Nov 09, 2012 at 02:34:10PM +0000, Lorenzo Pieralisi wrote:
> > This patch applies some basic changes to the smp_setup_processor_id()
> > ARM implementation to make the code that builds cpu_logical_map more
> > uniform across the kernel.
> >
> > The function now prints the full extent of the boot CPU MPIDR[23:0] and
> > initializes the cpu_logical_map for CPUs up to nr_cpu_ids.
> >
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > ---
> > arch/arm/kernel/setup.c | 7 ++++---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > index da1d1aa..ede7c84 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -426,13 +426,14 @@ int __cpu_logical_map[NR_CPUS];
> > void __init smp_setup_processor_id(void)
> > {
> > int i;
> > - u32 cpu = is_smp() ? read_cpuid_mpidr() & 0xff : 0;
> > + u32 mpidr = read_cpuid_mpidr() & 0xffffff;
>
> We need that is_smp() check, otherwise we'll go and do a funky CP15
> operation on CPU's that might not be too happy about it.
You are right, sorry my apologies.
I will have to check it even when parsing the DT then.
Lorenzo
^ 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