* [PATCH 2/3] arm: pmu: support pmu irq routed from CTI
From: Ming Lei @ 2011-03-01 15:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <-294597288559385401@unknownmsgid>
Hi,
2011/3/1 Will Deacon <will.deacon@arm.com>:
> Hello,
>
>> Subject: [PATCH 2/3] arm: pmu: support pmu irq routed from CTI
>>
>> From: Ming Lei <tom.leiming@gmail.com>
>>
>> This patch introduces pmu_platform_data struct to
>> support pmu irq routed from CTI, such as implemented
>> on OMAP4.
>>
>> Generally speaking, clearing cti irq should be done in
>> irq handler, also enabling cti module after calling
>> request_irq and disabling cti module before calling
>> free_irq.
>>
>> Signed-off-by: Ming Lei <tom.leiming@gmail.com>
>> ---
>> ?arch/arm/include/asm/pmu.h ? | ? 12 ++++++++++
>> ?arch/arm/kernel/perf_event.c | ? 51 ++++++++++++++++++++++++++++++++++++-----
>> ?2 files changed, 56 insertions(+), 7 deletions(-)
>
> This will conflict with the the ux500 PMU workaround:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2011-February/041145.html
Thanks for your pointing out it.
I will send out -v1 of these patches against the latest -next tree.
thanks,
--
Lei Ming
^ permalink raw reply
* [RFC] device.h: add device_set_platdata routine
From: Greg KH @ 2011-03-01 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110301075953.GR22310@pengutronix.de>
On Tue, Mar 01, 2011 at 08:59:53AM +0100, Uwe Kleine-K?nig wrote:
> [added gregkh and lkml to Cc:]
>
> Hi Viresh,
>
> On Tue, Mar 01, 2011 at 10:03:20AM +0530, Viresh Kumar wrote:
> > device.h supports device_get_platdata but doesn't support device_set_platdata.
> > This routine is required by platforms in which device structure is declared
> > in a machine specific file and platform data comes from board specific file.
> >
> > This will be used by SPEAr patches sent in separate patch series.
> >
> > Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
> > ---
> > include/linux/device.h | 5 +++++
> > 1 files changed, 5 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/linux/device.h b/include/linux/device.h
> > index 1bf5cf0..6ce0f20 100644
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -576,6 +576,11 @@ static inline void *dev_get_platdata(const struct device *dev)
> > return dev->platform_data;
> > }
> >
> > +static inline void dev_set_platdata(struct device *dev, void *platdata)
> > +{
> > + dev->platform_data = platdata;
> > +}
> > +
> Note that dev->platform_data was designed to hold dynamically allocated
> memory, at least it's kfreed in platform_device_release. And note there
> is platform_device_add_data that kmemdups its argument into
> pdev->dev.platform_data.
>
> Compared to your dev_set_platdata platform_device_add_data only works
> for platform_devices, don't know if it's worth to change that.
>
> And regarding platform_device_add_data I wonder if it wouldn't be more
> consistent to set platform_data = NULL if (!data)? Greg?
Maybe, care to send a patch?
thanks,
greg k-h
^ permalink raw reply
* [PATCH] audio:am3517evm support for AIC23
From: Abhilash K V @ 2011-03-01 15:43 UTC (permalink / raw)
To: linux-arm-kernel
This patch aims to fix the registration of the AIC23-based audio
module on the AM3517-EVM, with the following two changes:
1. The i2c_board_info entry supporting aic23 codec was added into
the i2c2 bus.
2. The i2c client device name (".2-001a" in this case, including
the separator period) was appended to the codec_name member of
am3517evm_dai to resolve the names mismatch happening in
soc_bind_dai_link().
Signed-off-by: Abhilash K V <abhilash.kv@ti.com>
---
arch/arm/mach-omap2/board-am3517evm.c | 3 +++
sound/soc/omap/am3517evm.c | 2 +-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c
index ad71cbf..8da8d20 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -358,6 +358,9 @@ static struct pca953x_platform_data am3517evm_gpio_expander_info_0 = {
};
static struct i2c_board_info __initdata am3517evm_i2c2_boardinfo[] = {
{
+ I2C_BOARD_INFO("tlv320aic23", 0x1A),
+ },
+ {
I2C_BOARD_INFO("tca6416", 0x21),
.platform_data = &am3517evm_gpio_expander_info_0,
},
diff --git a/sound/soc/omap/am3517evm.c b/sound/soc/omap/am3517evm.c
index 979dd50..ddbd2a1 100644
--- a/sound/soc/omap/am3517evm.c
+++ b/sound/soc/omap/am3517evm.c
@@ -139,7 +139,7 @@ static struct snd_soc_dai_link am3517evm_dai = {
.cpu_dai_name ="omap-mcbsp-dai.0",
.codec_dai_name = "tlv320aic23-hifi",
.platform_name = "omap-pcm-audio",
- .codec_name = "tlv320aic23-codec",
+ .codec_name = "tlv320aic23-codec.2-001a",
.init = am3517evm_aic23_init,
.ops = &am3517evm_ops,
};
--
1.6.2.4
^ permalink raw reply related
* [RFC PATCH] ARM: Use generic BUG() handler
From: Simon Glass @ 2011-03-01 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110301100306.GA18007@n2100.arm.linux.org.uk>
On Tue, Mar 1, 2011 at 2:03 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Mar 01, 2011 at 10:12:40AM +0100, Mikael Pettersson wrote:
>> Russell King - ARM Linux writes:
>> ?> On Tue, Mar 01, 2011 at 08:49:49AM +0000, Russell King - ARM Linux wrote:
>> ?> > On Mon, Feb 28, 2011 at 04:27:43PM -0800, Simon Glass wrote:
>> ?> > > + ? ? ?asm volatile("1:\t.word %c3\n" ? ? ? ? ? ? ? ? ? ? ? ? ?\
>> ?> > > + ? ? ? ? ? ? ? ? ? ".pushsection __bug_table,\"a\"\n" ? ? ? ? \
>> ?> > > + ? ? ? ? ? ? ? ? ? "2:\t.word 1b, %c0\n" ? ? ? ? ? ? ? ? ? ? ?\
>> ?> > > + ? ? ? ? ? ? ? ? ? "\t.hword %c1, 0\n" ? ? ? ? ? ? ? ? ? ? ? ?\
>> ?> > > + ? ? ? ? ? ? ? ? ? "\t.org 2b+%c2\n" ? ? ? ? ? ? ? ? ? ? ? ? ?\
>> ?> >
>> ?> > %c doesn't work on lots of versions of gcc, which is why we can't use
>> ?> > the generic bug support. ?There's no way to reliably generate constants
>> ?> > without many compiler versions spitting out a '#' before them.
>> ?>
>> ?> gcc 4.3.2:
>> ?>
>> ?> asm(".word %c0" : : "i" (0));
>> ?>
>> ?> produces:
>> ?>
>> ?> ? ? ? ? .word #0
>> ?>
>> ?> which gas chokes on:
>> ?>
>> ?> /tmp/cc2hGOHd.s:12: Error: bad expression
>> ?> /tmp/cc2hGOHd.s:12: Error: junk at end of line, first unrecognized character is `0'
>> ?>
>> ?> So what this means is that it's impossible to generate constants in
>> ?> assembly with GCC targetting ARM without having them prefixed by '#',
>> ?> which in turn makes it impossible to use the generic BUG support.
>> ?>
>> ?> I reported this bug to gcc folk many years ago. ?I've no idea which
>> ?> version it has been fixed in or if it's even been fixed.
>>
>> What's the gcc bugzilla bug number?
>
> No idea off hand - I'll have to search for that.
>
It seems I am lucky with the gcc I am using. I would have thought this
would be a pretty fundamental feature, but yes I did notice that %c
wasn't used anywhere.
Would this kernel feature be acceptable as a selectable config option
on ARM then?
Thanks,
Simon
^ permalink raw reply
* [PATCH 0/3] OMAP2+ hwmod fixes
From: Cousson, Benoit @ 2011-03-01 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <19850e063c924a8a30c69ac02621a659@mail.gmail.com>
Hi Paul,
On 2/23/2011 11:05 AM, Nayak, Rajendra wrote:
> Hi Paul,
>
>> From: Paul Walmsley [mailto:paul at pwsan.com]
>> Sent: Wednesday, February 23, 2011 12:40 AM
>>
>> Hi Rajendra
>>
>> On Tue, 22 Feb 2011, Rajendra Nayak wrote:
>>
>>> The original behavior of the iterators, to terminate upon
>>> encountering an error, seems fine to me. The only problem
>>> I faced was that they fail silently and go undetected, unless
>>> their user catches the return value and WARN's, which I found
>>> was not the case with most users, mainly those of
>>> omap_hwmod_for_each_by_class.
>>> I was thinking of keeping the behaviour of these iterators
>>> same for now and add WARN's in these iterators itself upon
>>> an error, so its seen even if the user fails to catch it.
>>
>> What's your opinion on adding the pr_err() or WARN() into the code that
>> the iterator calls for each hwmod? That code should know why something
>> fails, so it should be able to provide a more detailed error message.
> Of
>> course, it is not as general a solution...
>
> I agree, if the callback functions are written with proper errors
> or WARN's, they are the right place where most of the details'
> exist. So maybe we don't need these in the iterator's after all.
So to conclude, I will drop the #3 and just push #1 and #2.
#1 is fine with addition of the WARN.
#2 does return an error but does not print anything, but since each call
(_init_main_clk, _init_interface_clks, _init_opt_clks) does report
some pr_warn in case of error, this is fine.
Regards,
Benoit
^ permalink raw reply
* [patch v1 0/3] arm: support pmu irq routed from CTI
From: tom.leiming at gmail.com @ 2011-03-01 16:58 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This patches support pmu irq routed from CTI, such as implemented
on OMAP4:
- introduce some CTI helpers and registers' definition
- introduce platform_data to pmu driver, so perf irq handler
can handle irq correctly if it is routed from CTI
- configure CTI on OMAP4 so that perf can work on OMAP4
The patches have been tested Ok on Pandaboard, and 'perf' does work
after applying them.
v1:
- rebase the patch set against 2.6.38-rc6-next-20110301, fix
conflicts, which is pointed out by Will Deacon
arch/arm/include/asm/cti.h | 177 +++++++++++++++++++++++++++++++++++++++++
arch/arm/include/asm/pmu.h | 12 +++
arch/arm/kernel/perf_event.c | 57 ++++++++++----
arch/arm/mach-omap2/dbg44xx.h | 18 ++++
arch/arm/mach-omap2/devices.c | 55 +++++++++++++-
thanks,
--
Lei Ming
^ permalink raw reply
* [patch v1 1/3] arm: introduce cross trigger interface helpers
From: tom.leiming at gmail.com @ 2011-03-01 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298998711-8165-1-git-send-email-tom.leiming@gmail.com>
From: Ming Lei <tom.leiming@gmail.com>
OMAP4 uses cross trigger interface(CTI) to route
performance monitor irq to GIC, so introduce cti
helpers to make access for cti easily.
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
---
arch/arm/include/asm/cti.h | 177 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 177 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/cti.h
diff --git a/arch/arm/include/asm/cti.h b/arch/arm/include/asm/cti.h
new file mode 100644
index 0000000..c9addd3
--- /dev/null
+++ b/arch/arm/include/asm/cti.h
@@ -0,0 +1,177 @@
+/*
+ * arch/arm/include/asm/cti.h
+ */
+#ifndef __ASMARM_CTI_H
+#define __ASMARM_CTI_H
+
+#include <asm/io.h>
+
+/*The registers' definition is from section 3.2 of
+ * Embedded Cross Trigger Revision: r0p0
+ **/
+#define CTICONTROL 0x000
+#define CTISTATUS 0x004
+#define CTILOCK 0x008
+#define CTIPROTECTION 0x00C
+#define CTIINTACK 0x010
+#define CTIAPPSET 0x014
+#define CTIAPPCLEAR 0x018
+#define CTIAPPPULSE 0x01c
+#define CTIINEN 0x020
+#define CTIOUTEN 0x0A0
+#define CTITRIGINSTATUS 0x130
+#define CTITRIGOUTSTATUS 0x134
+#define CTICHINSTATUS 0x138
+#define CTICHOUTSTATUS 0x13c
+#define CTIPERIPHID0 0xFE0
+#define CTIPERIPHID1 0xFE4
+#define CTIPERIPHID2 0xFE8
+#define CTIPERIPHID3 0xFEC
+#define CTIPCELLID0 0xFF0
+#define CTIPCELLID1 0xFF4
+#define CTIPCELLID2 0xFF8
+#define CTIPCELLID3 0xFFC
+
+/*The two below are from section 3.6.4 of
+ * CoreSight v1.0 Architecture Specification
+ **/
+#define LOCKACCESS 0xFB0
+#define LOCKSTATUS 0xFB4
+
+/**
+ * struct cti - cross trigger interface struct
+ * @base: mapped virtual address for the cti base
+ * @irq: irq number for the cti
+ * @trig_out_for_irq: triger out number which will cause
+ * the @irq happen
+ *
+ * cti struct used to operate cti registers.
+ */
+struct cti {
+ void *base;
+ int irq;
+ int trig_out_for_irq;
+};
+
+/**
+ * cti_init - initialize the cti instance
+ * @cti: cti instance
+ * @base: mapped virtual address for the cti base
+ * @irq: irq number for the cti
+ * @trig_out: triger out number which will cause
+ * the @irq happen
+ *
+ * called by machine code to pass the board dependent
+ * @base, @irq and @trig_out to cti.
+ */
+static inline void cti_init(struct cti *cti,
+ void *base, int irq, int trig_out)
+{
+ cti->base = base;
+ cti->irq = irq;
+ cti->trig_out_for_irq = trig_out;
+}
+
+/**
+ * cti_map_trigger - use the @chan to map @trig_in to @trig_out
+ * @cti: cti instance
+ * @trig_in: trigger in number
+ * @trig_out: trigger out number
+ * @channel: channel number
+ *
+ * This function maps one trigger in of @trig_in to one trigger
+ * out of @trig_out using the channel @chan.
+ */
+static inline void cti_map_trigger(struct cti *cti,
+ int trig_in, int trig_out, int chan)
+{
+ void *base = cti->base;
+ unsigned long val;
+
+ val = __raw_readl(base + CTIINEN + trig_in * 4);
+ val |= 1 << chan;
+ __raw_writel(val, base + CTIINEN + trig_in * 4);
+
+ val = __raw_readl(base + CTIOUTEN + trig_out * 4);
+ val |= 1 << chan;
+ __raw_writel(val, base + CTIOUTEN + trig_out * 4);
+}
+
+/**
+ * cti_enable - enable the cti module
+ * @cti: cti instance
+ *
+ * enable the cti module
+ */
+static inline void cti_enable(struct cti *cti)
+{
+ __raw_writel(0x1, cti->base);
+}
+
+/**
+ * cti_disable - disable the cti module
+ * @cti: cti instance
+ *
+ * enable the cti module
+ */
+static inline void cti_disable(struct cti *cti)
+{
+ __raw_writel(0, cti->base);
+}
+
+/**
+ * cti_irq_ack - clear the cti irq
+ * @cti: cti instance
+ *
+ * clear the cti irq
+ */
+static inline void cti_irq_ack(struct cti *cti)
+{
+ void *base = cti->base;
+ unsigned long val;
+
+ val = __raw_readl(base + CTIINTACK);
+ val |= 1 << cti->trig_out_for_irq;
+ __raw_writel(val, base + CTIINTACK);
+}
+
+/**
+ * cti_unlock - unlock cti module
+ * @cti: cti instance
+ *
+ * unlock the cti module, or else any writes to the cti
+ * module is not allowed.
+ */
+static inline void cti_unlock(struct cti *cti)
+{
+ void *base = cti->base;
+ unsigned long val;
+
+ val = __raw_readl(base + LOCKSTATUS);
+
+ if (val & 1) {
+ val = 0xC5ACCE55;
+ __raw_writel(val, base + LOCKACCESS);
+ }
+}
+
+/**
+ * cti_unlock - lock cti module
+ * @cti: cti instance
+ *
+ * lock the cti module, so any writes to the cti
+ * module will be not allowed.
+ */
+static inline void cti_lock(struct cti *cti)
+{
+ void *base = cti->base;
+ unsigned long val;
+
+ val = __raw_readl(base + LOCKSTATUS);
+
+ if (!(val & 1)) {
+ val = ~0xC5ACCE55;
+ __raw_writel(val, base + LOCKACCESS);
+ }
+}
+#endif
--
1.7.3
^ permalink raw reply related
* [patch v1 2/3] arm: pmu: support pmu irq routed from CTI
From: tom.leiming at gmail.com @ 2011-03-01 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298998711-8165-1-git-send-email-tom.leiming@gmail.com>
From: Ming Lei <tom.leiming@gmail.com>
This patch introduces pmu_platform_data struct to
support pmu irq routed from CTI, such as implemented
on OMAP4.
Generally speaking, clearing cti irq should be done in
irq handler, also enabling cti module after calling
request_irq and disabling cti module before calling
free_irq.
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
---
arch/arm/include/asm/pmu.h | 12 +++++++++
arch/arm/kernel/perf_event.c | 57 ++++++++++++++++++++++++++++++-----------
2 files changed, 53 insertions(+), 16 deletions(-)
diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
index 7544ce6..6162aaf 100644
--- a/arch/arm/include/asm/pmu.h
+++ b/arch/arm/include/asm/pmu.h
@@ -13,20 +13,32 @@
#define __ARM_PMU_H__
#include <linux/interrupt.h>
+#include <asm/cti.h>
enum arm_pmu_type {
ARM_PMU_DEVICE_CPU = 0,
ARM_NUM_PMU_DEVICES,
};
+#define MAX_CTI_NUM 4
/*
* struct arm_pmu_platdata - ARM PMU platform data
*
+ * @use_cti_irq: pmu irq is routed from cti
+ * @cti_cnt: cti counts used for pmu irq routing
+ * @cti: cti instances used to help access cti registers
* @handle_irq: an optional handler which will be called from the interrupt and
* passed the address of the low level handler, and can be used to implement
* any platform specific handling before or after calling it.
+ *
+ * If pmu irq is routed from CTI, @use_cti_irq, @cti_cnt and
+ * @cti must be initialized and passed to pmu driver.
*/
struct arm_pmu_platdata {
+ int use_cti_irq;
+ int cti_cnt;
+ struct cti cti[MAX_CTI_NUM];
+
irqreturn_t (*handle_irq)(int irq, void *dev,
irq_handler_t pmu_handler);
};
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index 22e194eb..9027a8f 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -377,18 +377,39 @@ validate_group(struct perf_event *event)
return 0;
}
-static irqreturn_t armpmu_platform_irq(int irq, void *dev)
+static inline int cti_irq(struct arm_pmu_platdata *data)
{
- struct arm_pmu_platdata *plat = dev_get_platdata(&pmu_device->dev);
+ return data && data->use_cti_irq;
+}
+
+static inline struct cti *irq_to_cti(struct arm_pmu_platdata *data,
+ int irq)
+{
+ int idx;
- return plat->handle_irq(irq, dev, armpmu->handle_irq);
+ for(idx = 0; idx < data->cti_cnt; idx++)
+ if (data->cti[idx].irq == irq)
+ return &data->cti[idx];
+ return NULL;
+}
+
+static inline irqreturn_t armpmu_handle_irq(int irq_num, void *dev)
+{
+ struct arm_pmu_platdata *plat = dev;
+
+ if (cti_irq(plat))
+ cti_irq_ack(irq_to_cti(plat, irq_num));
+
+ if (plat && plat->handle_irq)
+ return plat->handle_irq(irq_num, dev, armpmu->handle_irq);
+ else
+ return armpmu->handle_irq(irq_num, NULL);
}
static int
armpmu_reserve_hardware(void)
{
struct arm_pmu_platdata *plat;
- irq_handler_t handle_irq;
int i, err = -ENODEV, irq;
pmu_device = reserve_pmu(ARM_PMU_DEVICE_CPU);
@@ -399,11 +420,7 @@ armpmu_reserve_hardware(void)
init_pmu(ARM_PMU_DEVICE_CPU);
- plat = dev_get_platdata(&pmu_device->dev);
- if (plat && plat->handle_irq)
- handle_irq = armpmu_platform_irq;
- else
- handle_irq = armpmu->handle_irq;
+ plat = platform_get_drvdata(pmu_device);
if (pmu_device->num_resources < 1) {
pr_err("no irqs for PMUs defined\n");
@@ -415,21 +432,25 @@ armpmu_reserve_hardware(void)
if (irq < 0)
continue;
- err = request_irq(irq, handle_irq,
+ err = request_irq(irq, armpmu_handle_irq,
IRQF_DISABLED | IRQF_NOBALANCING,
- "armpmu", NULL);
+ "armpmu", plat);
if (err) {
pr_warning("unable to request IRQ%d for ARM perf "
"counters\n", irq);
break;
- }
+ } else if (cti_irq(plat))
+ cti_enable(irq_to_cti(plat, irq));
}
if (err) {
for (i = i - 1; i >= 0; --i) {
irq = platform_get_irq(pmu_device, i);
- if (irq >= 0)
- free_irq(irq, NULL);
+ if (irq >= 0) {
+ if (cti_irq(plat))
+ cti_disable(irq_to_cti(plat, irq));
+ free_irq(irq, plat);
+ }
}
release_pmu(pmu_device);
pmu_device = NULL;
@@ -442,11 +463,15 @@ static void
armpmu_release_hardware(void)
{
int i, irq;
+ struct arm_pmu_platdata *plat = platform_get_drvdata(pmu_device);
for (i = pmu_device->num_resources - 1; i >= 0; --i) {
irq = platform_get_irq(pmu_device, i);
- if (irq >= 0)
- free_irq(irq, NULL);
+ if (irq >= 0) {
+ if (cti_irq(plat))
+ cti_disable(irq_to_cti(plat, irq));
+ free_irq(irq, plat);
+ }
}
armpmu->stop();
--
1.7.3
^ permalink raw reply related
* [patch v1 3/3] arm: omap4: support pmu
From: tom.leiming at gmail.com @ 2011-03-01 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298998711-8165-1-git-send-email-tom.leiming@gmail.com>
From: Ming Lei <tom.leiming@gmail.com>
This patch supports pmu irq routed from CTI, so
make pmu/perf working on OMAP4.
The idea is from Woodruff Richard in the disscussion
"Oprofile on Pandaboard / Omap4" of pandaboard at googlegroups.com.
Cc: Woodruff Richard <r-woodruff2@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: linux-omap at vger.kernel.org
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
---
arch/arm/mach-omap2/dbg44xx.h | 18 +++++++++++++
arch/arm/mach-omap2/devices.c | 55 ++++++++++++++++++++++++++++++++++++++++-
2 files changed, 72 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/dbg44xx.h
diff --git a/arch/arm/mach-omap2/dbg44xx.h b/arch/arm/mach-omap2/dbg44xx.h
new file mode 100644
index 0000000..e447ad5
--- /dev/null
+++ b/arch/arm/mach-omap2/dbg44xx.h
@@ -0,0 +1,18 @@
+/*
+ * OMAP44xx on-chip debug support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * XXX This file needs to be updated to align on one of "OMAP4", "OMAP44XX",
+ * or "OMAP4430".
+ */
+
+#ifndef __ARCH_ARM_MACH_OMAP2_DBG44XX_H
+#define __ARCH_ARM_MACH_OMAP2_DBG44XX_H
+
+#define OMAP44XX_CTI0_BASE 0x54148000
+#define OMAP44XX_CTI1_BASE 0x54149000
+
+#endif
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index d216976..0420a58 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -35,6 +35,7 @@
#include "mux.h"
#include "control.h"
+#include "dbg44xx.h"
#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
@@ -322,19 +323,71 @@ static struct resource omap3_pmu_resource = {
.flags = IORESOURCE_IRQ,
};
+static struct resource omap4_pmu_resource[] = {
+ {
+ .start = OMAP44XX_IRQ_CTI0,
+ .end = OMAP44XX_IRQ_CTI0,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = OMAP44XX_IRQ_CTI1,
+ .end = OMAP44XX_IRQ_CTI1,
+ .flags = IORESOURCE_IRQ,
+ }
+};
+
static struct platform_device omap_pmu_device = {
.name = "arm-pmu",
.id = ARM_PMU_DEVICE_CPU,
.num_resources = 1,
};
+struct arm_pmu_platdata omap4_pmu_data;
+
+static void omap4_configure_pmu_irq(void)
+{
+ void *base0;
+ void *base1;
+
+ base0 = ioremap(OMAP44XX_CTI0_BASE, 4096);
+ base1 = ioremap(OMAP44XX_CTI1_BASE, 4096);
+ if (!base0 && !base1) {
+ pr_err("ioremap for omap4 CTI failed\n");
+ return;
+ }
+
+ /*configure CTI0 for pmu irq routing*/
+ cti_init(&omap4_pmu_data.cti[0], base0,
+ OMAP44XX_IRQ_CTI0, 6);
+ cti_unlock(&omap4_pmu_data.cti[0]);
+ cti_map_trigger(&omap4_pmu_data.cti[0],
+ 1, 6, 2);
+
+ /*configure CTI1 for pmu irq routing*/
+ cti_init(&omap4_pmu_data.cti[1], base1,
+ OMAP44XX_IRQ_CTI1, 6);
+ cti_unlock(&omap4_pmu_data.cti[1]);
+ cti_map_trigger(&omap4_pmu_data.cti[1],
+ 1, 6, 3);
+
+ omap4_pmu_data.cti_cnt = 2;
+ omap4_pmu_data.use_cti_irq = 1;
+ omap4_pmu_data.handle_irq = NULL;
+}
+
static void omap_init_pmu(void)
{
if (cpu_is_omap24xx())
omap_pmu_device.resource = &omap2_pmu_resource;
else if (cpu_is_omap34xx())
omap_pmu_device.resource = &omap3_pmu_resource;
- else
+ else if (cpu_is_omap44xx()) {
+ omap_pmu_device.resource = omap4_pmu_resource;
+ omap_pmu_device.num_resources = 2;
+ platform_set_drvdata(&omap_pmu_device, &omap4_pmu_data);
+
+ omap4_configure_pmu_irq();
+ } else
return;
platform_device_register(&omap_pmu_device);
--
1.7.3
^ permalink raw reply related
* resend hsudc patches for s3c24xx?
From: Heiko Stübner @ 2011-03-01 17:07 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
some time around october 2010 Sangbeom Kim posted patches from Thomas Abraham
to support the hs-udc of the s3c24xx-platform. But these patches were not
added to the kernel.
We are currently working on s3c2416 based devices which would profit from this
drivers and not having to keep them locally.
We ported the patches to a 2.6.38-rc state which can be found on [1] and also
attached. Especially the driver itself [2] needed a bit of rework and I'm not
sure if the gadget_chips id is simply incremented for new drivers.
As the merge-window for 2.6.39 approaches, could you have another look at them
and merge eventually them into the linux-samsung tree?
Thanks
Heiko
[1] http://gitorious.org/oyo-hack/kernel/commits/s3c-hsudc
[2] http://gitorious.org/oyo-
hack/kernel/commit/c063317869d11c3b8f906061319f8a075de06b5c
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ARM-S3C2416-Add-USB-Phy-register-definitions.patch
Type: text/x-patch
Size: 2146 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110301/11ab6ee5/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-ARM-S3C24XX-Add-plaform-device-definition-for-USB-Hi.patch
Type: text/x-patch
Size: 4593 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110301/11ab6ee5/attachment-0005.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-ARM-S3C2416-Add-support-for-USB-2.0-High-Speed-gadge.patch
Type: text/x-patch
Size: 2728 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110301/11ab6ee5/attachment-0006.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-USB-Gadget-Add-Samsung-S3C24XX-USB-High-Speed-contro.patch
Type: text/x-patch
Size: 40485 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110301/11ab6ee5/attachment-0007.bin>
^ permalink raw reply
* [patch v1 3/3] arm: omap4: support pmu
From: Felipe Balbi @ 2011-03-01 17:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298998711-8165-4-git-send-email-tom.leiming@gmail.com>
On Wed, Mar 02, 2011 at 12:58:31AM +0800, tom.leiming at gmail.com wrote:
> From: Ming Lei <tom.leiming@gmail.com>
>
> This patch supports pmu irq routed from CTI, so
> make pmu/perf working on OMAP4.
>
> The idea is from Woodruff Richard in the disscussion
> "Oprofile on Pandaboard / Omap4" of pandaboard at googlegroups.com.
>
> Cc: Woodruff Richard <r-woodruff2@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: linux-omap at vger.kernel.org
> Signed-off-by: Ming Lei <tom.leiming@gmail.com>
> ---
> arch/arm/mach-omap2/dbg44xx.h | 18 +++++++++++++
> arch/arm/mach-omap2/devices.c | 55 ++++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 72 insertions(+), 1 deletions(-)
> create mode 100644 arch/arm/mach-omap2/dbg44xx.h
>
> diff --git a/arch/arm/mach-omap2/dbg44xx.h b/arch/arm/mach-omap2/dbg44xx.h
> new file mode 100644
> index 0000000..e447ad5
> --- /dev/null
> +++ b/arch/arm/mach-omap2/dbg44xx.h
> @@ -0,0 +1,18 @@
> +/*
> + * OMAP44xx on-chip debug support
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * XXX This file needs to be updated to align on one of "OMAP4", "OMAP44XX",
> + * or "OMAP4430".
> + */
> +
> +#ifndef __ARCH_ARM_MACH_OMAP2_DBG44XX_H
> +#define __ARCH_ARM_MACH_OMAP2_DBG44XX_H
> +
> +#define OMAP44XX_CTI0_BASE 0x54148000
> +#define OMAP44XX_CTI1_BASE 0x54149000
> +
> +#endif
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index d216976..0420a58 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -35,6 +35,7 @@
>
> #include "mux.h"
> #include "control.h"
> +#include "dbg44xx.h"
>
> #if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
>
> @@ -322,19 +323,71 @@ static struct resource omap3_pmu_resource = {
> .flags = IORESOURCE_IRQ,
> };
>
> +static struct resource omap4_pmu_resource[] = {
> + {
> + .start = OMAP44XX_IRQ_CTI0,
> + .end = OMAP44XX_IRQ_CTI0,
> + .flags = IORESOURCE_IRQ,
> + },
> + {
> + .start = OMAP44XX_IRQ_CTI1,
> + .end = OMAP44XX_IRQ_CTI1,
> + .flags = IORESOURCE_IRQ,
> + }
> +};
indentation is wrong.
> static void omap_init_pmu(void)
> {
> if (cpu_is_omap24xx())
> omap_pmu_device.resource = &omap2_pmu_resource;
> else if (cpu_is_omap34xx())
> omap_pmu_device.resource = &omap3_pmu_resource;
missing add braces to these two.
--
balbi
^ permalink raw reply
* [PATCH] ARM: vexpress ct-ca9x4: only set twd_base if local timers are being used
From: Sergei Shtylyov @ 2011-03-01 17:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1288891845-12630-1-git-send-email-will.deacon@arm.com>
Hello.
Will Deacon wrote:
> In commit bde28b84, I made the assumption that CONFIG_SMP is always set
Linus asks to also specify the commit summary in parens.
> for the quad-core ct-ca9x4 platform. As it turns out, people who aren't
> using the SMP goodness are confronted with a build failure.
> This patch fixes this issue by ensure that twd_base is only set if
> local timers are being used (and therefore SMP support is configured).
> Reported-by: Nicolas Pitre <nicolas.pitre@linaro.org>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
WBR, Sergei
^ permalink raw reply
* [PATCH] ARM: vexpress ct-ca9x4: only set twd_base if local timers are being used
From: Will Deacon @ 2011-03-01 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6D2B98.4090501@ru.mvista.com>
> Will Deacon wrote:
>
> > In commit bde28b84, I made the assumption that CONFIG_SMP is always set
>
> Linus asks to also specify the commit summary in parens.
Well he merged it for v2.6.37 so I guess it's not the end of the world.
Will
^ permalink raw reply
* [GIT PULL] omap fixes for v2.6.38-rc6
From: Aaro Koskinen @ 2011-03-01 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110228194151.GJ20560@atomide.com>
Hi,
On Mon, 28 Feb 2011, Tony Lindgren wrote:
> Please pull omap fixes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes-for-linus
>
> This contains one more timer regression fix, a DPLL rate fix,
> and a mailbox NULL pointer fix that would be good to get
> in for 2.6.38. The series also removes world-writable flag for
> some debugfs entries.
>
> Other than I believe that's it for omap fixes for v2.6.38.
I wonder what happened to this patch:
http://marc.info/?l=linux-omap&m=129772313519005&w=2
A.
^ permalink raw reply
* [RFC PATCH] ARM: Use generic BUG() handler
From: Dave Martin @ 2011-03-01 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298939263-16421-1-git-send-email-sjg@chromium.org>
On Tue, Mar 1, 2011 at 12:27 AM, Simon Glass <sjg@chromium.org> wrote:
> I am looking for comments please on this patch.
>
> ARM uses its own BUG() handler which makes its output slightly different
> from other archtectures.
>
> One of the problems is that the ARM implementation doesn't report the function
> with the BUG() in it, but always reports the PC being in __bug(). The generic
> implementation doesn't have this problem.
>
> Currently we get something like:
>
> kernel BUG at fs/proc/breakme.c:35!
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> ...
> PC is at __bug+0x20/0x2c
>
> With this patch it displays:
>
> kernel BUG at fs/proc/breakme.c:35!
> Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP
> ...
> PC is at write_breakme+0xd0/0x1b4
>
> This implementation uses an undefined instruction to implement BUG, and sets up
> a bug table containing the relevant information.
>
> Also backtraces were reported slightly differently - so I have added a newline
> after the backtrace message, a space before the address, and ensured that the
> message appears even when CONFIG_ARM_UNWIND is defined. These are aimed at
> consistency between architectures, and may or may not be acceptable for ARM.
> In any case they may be best as a separate patch.
>
> Change-Id: I515db9a04e98084e6bbb21c4a1d13579568a0904
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
> ?arch/arm/Kconfig ? ? ? ? ? ? ?| ? ?4 ++++
> ?arch/arm/include/asm/bug.h ? ?| ? 40 +++++++++++++++++++++++++++++++++++++++-
> ?arch/arm/kernel/traps.c ? ? ? | ? 21 +++++++++++++++++++--
> ?arch/arm/kernel/unwind.c ? ? ?| ? ?1 +
> ?arch/arm/kernel/vmlinux.lds.S | ? 15 +++++++++++++--
> ?5 files changed, 76 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 26d45e5..d4fb0fb 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -191,6 +191,10 @@ config VECTORS_BASE
> ? ? ? ?help
> ? ? ? ? ?The base address of exception vectors.
>
> +config GENERIC_BUG
> + ? ? ? def_bool y
> + ? ? ? depends on BUG
> +
> ?source "init/Kconfig"
>
> ?source "kernel/Kconfig.freezer"
> diff --git a/arch/arm/include/asm/bug.h b/arch/arm/include/asm/bug.h
> index 4d88425..bbbebe4 100644
> --- a/arch/arm/include/asm/bug.h
> +++ b/arch/arm/include/asm/bug.h
> @@ -3,6 +3,40 @@
>
>
> ?#ifdef CONFIG_BUG
> +
> +#ifdef CONFIG_GENERIC_BUG
> +
> +
> +/* A suitable undefined instruction to use for ARM bug handling */
> +#define BUG_INSTR_ARM 0xec000000
This will need a suitable separate definition for
CONFIG_THUMB2_KERNEL, where the instruction encodings are different.
It may also be a good idea to include the whole directive, e.g.
#define BUG_INSTR_ARM ".word 0xec000000"
...since for Thumb you probably want to use .hword/.short (or
inst.n/inst.w if we consider that everyone has new enough tools)
instead of .long in that case.
> +
> +
> +#ifdef CONFIG_DEBUG_BUGVERBOSE
> +#define BUG() ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> +do { ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> + ? ? ? asm volatile("1:\t.word %c3\n" ? ? ? ? ? ? ? ? ? ? ? ? ?\
> + ? ? ? ? ? ? ? ? ? ?".pushsection __bug_table,\"a\"\n" ? ? ? ? \
> + ? ? ? ? ? ? ? ? ? ?"2:\t.word 1b, %c0\n" ? ? ? ? ? ? ? ? ? ? ?\
> + ? ? ? ? ? ? ? ? ? ?"\t.hword %c1, 0\n" ? ? ? ? ? ? ? ? ? ? ? ?\
> + ? ? ? ? ? ? ? ? ? ?"\t.org 2b+%c2\n" ? ? ? ? ? ? ? ? ? ? ? ? ?\
> + ? ? ? ? ? ? ? ? ? ?".popsection" ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> + ? ? ? ? ? ? ? ? ? ?: ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> + ? ? ? ? ? ? ? ? ? ?: "i" (__FILE__), "i" (__LINE__), ? ? ? ? ?\
> + ? ? ? ? ? ? ? ? ? ?"i" (sizeof(struct bug_entry)), ? ? ? ? ? ?\
> + ? ? ? ? ? ? ? ? ? ?"i" (BUG_INSTR_ARM)); ? ? ? ? ? ? ? ? ? ? ?\
> + ? ? ? unreachable(); ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> +} while (0)
> +
> +#else
> +#define BUG() ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> +do { ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \
> + ? ? ? asm volatile("ud2"); ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> + ? ? ? unreachable(); ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\
> +} while (0)
> +#endif
> +
> +#else ?/* not CONFIG_GENERIC_BUG */
> +
> ?#ifdef CONFIG_DEBUG_BUGVERBOSE
> ?extern void __bug(const char *file, int line) __attribute__((noreturn));
>
> @@ -16,8 +50,12 @@ extern void __bug(const char *file, int line) __attribute__((noreturn));
>
> ?#endif
>
> +#endif ?/* CONFIG_GENERIC_BUG */
> +
> ?#define HAVE_ARCH_BUG
> -#endif
> +
> +#endif /* CONFIG_BUG */
> +
>
> ?#include <asm-generic/bug.h>
>
> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> index ee57640..d5e5df9 100644
> --- a/arch/arm/kernel/traps.c
> +++ b/arch/arm/kernel/traps.c
> @@ -21,6 +21,7 @@
> ?#include <linux/kdebug.h>
> ?#include <linux/module.h>
> ?#include <linux/kexec.h>
> +#include <linux/bug.h>
> ?#include <linux/delay.h>
> ?#include <linux/init.h>
>
> @@ -55,7 +56,8 @@ static void dump_mem(const char *, const char *, unsigned long, unsigned long);
> ?void dump_backtrace_entry(unsigned long where, unsigned long from, unsigned long frame)
> ?{
> ?#ifdef CONFIG_KALLSYMS
> - ? ? ? printk("[<%08lx>] (%pS) from [<%08lx>] (%pS)\n", where, (void *)where, from, (void *)from);
> + ? ? ? printk(" [<%08lx>] (%pS) from [<%08lx>] (%pS)\n", where, (void *)where,
> + ? ? ? ? ? ? ?from, (void *)from);
> ?#else
> ? ? ? ?printk("Function entered at [<%08lx>] from [<%08lx>]\n", where, from);
> ?#endif
> @@ -171,7 +173,7 @@ static void dump_backtrace(struct pt_regs *regs, struct task_struct *tsk)
> ? ? ? ?unsigned int fp, mode;
> ? ? ? ?int ok = 1;
>
> - ? ? ? printk("Backtrace: ");
> + ? ? ? printk("Backtrace:\n");
>
> ? ? ? ?if (!tsk)
> ? ? ? ? ? ? ? ?tsk = current;
> @@ -271,6 +273,8 @@ void die(const char *str, struct pt_regs *regs, int err)
> ? ? ? ?spin_lock_irq(&die_lock);
> ? ? ? ?console_verbose();
> ? ? ? ?bust_spinlocks(1);
> + ? ? ? if (!user_mode(regs))
> + ? ? ? ? ? ? ? report_bug(regs->ARM_pc, regs);
> ? ? ? ?ret = __die(str, err, thread, regs);
>
> ? ? ? ?if (regs && kexec_should_crash(thread->task))
> @@ -302,6 +306,19 @@ void arm_notify_die(const char *str, struct pt_regs *regs,
> ? ? ? ?}
> ?}
>
> +int is_valid_bugaddr(unsigned long pc)
> +{
> + ? ? ? unsigned bkpt;
> +
> + ? ? ? if (pc < PAGE_OFFSET)
> + ? ? ? ? ? ? ? return 0;
> + ? ? ? if (probe_kernel_address((unsigned *)pc, bkpt))
> + ? ? ? ? ? ? ? return 0;
> +
> + ? ? ? return bkpt == BUG_INSTR_ARM;
> +}
> +
> +
> ?static LIST_HEAD(undef_hook);
> ?static DEFINE_SPINLOCK(undef_lock);
>
> diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
> index d2cb0b3..3f065bd 100644
> --- a/arch/arm/kernel/unwind.c
> +++ b/arch/arm/kernel/unwind.c
> @@ -355,6 +355,7 @@ void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk)
> ? ? ? ?register unsigned long current_sp asm ("sp");
>
> ? ? ? ?pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
> + ? ? ? printk("Backtrace:\n");
>
> ? ? ? ?if (!tsk)
> ? ? ? ? ? ? ? ?tsk = current;
> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> index 86b66f3..591ab50 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -72,6 +72,18 @@ SECTIONS
>
> ? ? ? ?PERCPU(PAGE_SIZE)
>
> + ? ? ? /*
> + ? ? ? ?* .exit.text is discarded at runtime, not link time, to deal with
> + ? ? ? ?* ?references from bug_table
> + ? ? ? ?*/
> + ? ? ? .exit.text : AT(ADDR(.exit.text)) {
> + ? ? ? ? ? ? ? EXIT_TEXT
> + ? ? ? }
> +
> + ? ? ? .exit.data : AT(ADDR(.exit.data)) {
> + ? ? ? ? ? ? ? EXIT_DATA
> + ? ? ? }
> +
> ?#ifndef CONFIG_XIP_KERNEL
> ? ? ? ?. = ALIGN(PAGE_SIZE);
> ? ? ? ?__init_end = .;
> @@ -246,7 +258,6 @@ SECTIONS
> ? ? ? ? ? ? ? ?__tcm_end = .;
> ? ? ? ?}
> ?#endif
> -
> ? ? ? ?BSS_SECTION(0, 0, 0)
> ? ? ? ?_end = .;
>
> @@ -254,7 +265,7 @@ SECTIONS
> ? ? ? ?.comment 0 : { *(.comment) }
>
> ? ? ? ?/* Default discards */
> - ? ? ? DISCARDS
> + ? ? ? /*DISCARDS*/
>
> ?#ifndef CONFIG_SMP_ON_UP
> ? ? ? ?/DISCARD/ : {
> --
> 1.7.3.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH] ARM: vexpress ct-ca9x4: only set twd_base if local timers are being used
From: Sergei Shtylyov @ 2011-03-01 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <000801cbd836$828d8f20$87a8ad60$@deacon@arm.com>
Hello.
Will Deacon wrote:
>>> In commit bde28b84, I made the assumption that CONFIG_SMP is always set
>> Linus asks to also specify the commit summary in parens.
> Well he merged it for v2.6.37 so I guess it's not the end of the world.
Heh, didn't realize I was replying to such an old email. :-)
> Will
WBR, Sergei
^ permalink raw reply
* [PATCH v6 1/1] PRUSS UIO driver support
From: Hans J. Koch @ 2011-03-01 18:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB593024BF3601C@dbde02.ent.ti.com>
On Tue, Mar 01, 2011 at 10:15:27AM +0530, TK, Pratheesh Gangadhar wrote:
> Hi,
>
> > -----Original Message-----
> > From: Hans J. Koch [mailto:hjk at hansjkoch.de]
> > Sent: Tuesday, March 01, 2011 2:57 AM
> > To: TK, Pratheesh Gangadhar
> > Cc: linux-kernel at vger.kernel.org; hjk at hansjkoch.de; gregkh at suse.de;
> > tglx at linutronix.de; sshtylyov at mvista.com; arnd at arndb.de; Chatterjee, Amit;
> > davinci-linux-open-source at linux.davincidsp.com; linux-arm-
> > kernel at lists.infradead.org
> > Subject: Re: [PATCH v6 1/1] PRUSS UIO driver support
> >
> > On Tue, Mar 01, 2011 at 02:31:35AM +0530, Pratheesh Gangadhar wrote:
> > > +
> > > + /* Register PRUSS IRQ lines */
> > > + p->irq = IRQ_DA8XX_EVTOUT0 + cnt;
> > > + p->handler = pruss_handler;
> > > +
> > > + ret = uio_register_device(&dev->dev, p);
> > > +
> > > + if (ret < 0)
> > > + goto out_free;
> > > + }
> > > +
> > > + spin_lock_init(&lock);
> >
> > That's too late. uio_register_device() enables the irq, and your spin_lock
> > is not ready at that time.
>
> This is ok in this context as "modprobe uio_pruss" is pre-requisite for
> running PRUSS firmware and without firmware running PRUSS won't
> generate interrupts. Actually PRUSS INTC is not setup till we start
> user application.
What if the user application is stopped, UIO driver module unloaded
and loaded again?
Anyway, please don't use that kind of argumentation. The next newbie
developer might copy your work as a basis for his new driver, and there
it probably won't work.
Simply put the spin_lock_init before the loop.
Thanks,
Hans
^ permalink raw reply
* [PATCH] audio:am3517evm support for AIC23
From: Jarkko Nikula @ 2011-03-01 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298994218-30610-1-git-send-email-abhilash.kv@ti.com>
Hi
On Tue, 1 Mar 2011 21:13:38 +0530
Abhilash K V <abhilash.kv@ti.com> wrote:
> This patch aims to fix the registration of the AIC23-based audio
> module on the AM3517-EVM, with the following two changes:
>
> 1. The i2c_board_info entry supporting aic23 codec was added into
> the i2c2 bus.
> 2. The i2c client device name (".2-001a" in this case, including
> the separator period) was appended to the codec_name member of
> am3517evm_dai to resolve the names mismatch happening in
> soc_bind_dai_link().
>
> Signed-off-by: Abhilash K V <abhilash.kv@ti.com>
> ---
> arch/arm/mach-omap2/board-am3517evm.c | 3 +++
> sound/soc/omap/am3517evm.c | 2 +-
> 2 files changed, 4 insertions(+), 1 deletions(-)
>
First, your patch does the correct things.
I investigated a bit and it looks like the sound/soc/omap/am3517evm.c
never worked in mainline since the patch below adding codec to
board-am3517evm.c wasn't applied by reason or another.
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg18470.html
This means that you should split this patch into two and they can be
sent as independent patches. am3517evm.c change via alsa-devel
and board-am3517evm.c via linux-omap & linux-arm-kernel. Some comments
below.
> diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-omap2/board-am3517evm.c
> index ad71cbf..8da8d20 100644
> --- a/arch/arm/mach-omap2/board-am3517evm.c
> +++ b/arch/arm/mach-omap2/board-am3517evm.c
> @@ -358,6 +358,9 @@ static struct pca953x_platform_data am3517evm_gpio_expander_info_0 = {
> };
> static struct i2c_board_info __initdata am3517evm_i2c2_boardinfo[] = {
> {
> + I2C_BOARD_INFO("tlv320aic23", 0x1A),
> + },
> + {
This is ok and don't need anything else as the rest pieces from
original missing patch are added by another patches.
> --- a/sound/soc/omap/am3517evm.c
> +++ b/sound/soc/omap/am3517evm.c
> @@ -139,7 +139,7 @@ static struct snd_soc_dai_link am3517evm_dai = {
> .cpu_dai_name ="omap-mcbsp-dai.0",
> .codec_dai_name = "tlv320aic23-hifi",
> .platform_name = "omap-pcm-audio",
> - .codec_name = "tlv320aic23-codec",
> + .codec_name = "tlv320aic23-codec.2-001a",
> .init = am3517evm_aic23_init,
> .ops = &am3517evm_ops,
> };
Subject for this part could be something like
"ASoC: AM3517: Update codec name after multi-component update".
Remember to cc ASoC maintainers Mark Brown and Liam Girdwood.
You could add my acks to splitted patches.
Acked-by: Jarkko Nikula <jhnikula@gmail.com>
^ permalink raw reply
* [PATCH] ARM: enable CONFIG_KTIME_SCALAR
From: Rob Herring @ 2011-03-01 18:38 UTC (permalink / raw)
To: linux-arm-kernel
From: Rob Herring <rob.herring@calxeda.com>
Use straight 64-bit values as 64-bit operations are fairly efficient on ARM.
Comparing the asm output with and without KTIME_SCALAR, using 64-bit math
generates clearly better code.
Comparing kernel/hrtimer.c .text size, it goes from 0x1414 to 0x119c with
this change.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
arch/arm/Kconfig | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 166efa2..0efbea4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -63,6 +63,10 @@ config GENERIC_CLOCKEVENTS_BROADCAST
depends on GENERIC_CLOCKEVENTS
default y if SMP
+config KTIME_SCALAR
+ bool
+ default y
+
config HAVE_TCM
bool
select GENERIC_ALLOCATOR
--
1.7.1
^ permalink raw reply related
* Fwd: [RFC] MMC: error handling improvements
From: Murali Krishna Palnati @ 2011-03-01 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimpJUoc64py_jCrvsrXscawsR2c7JBtr1e0U+e8@mail.gmail.com>
> ---------- Forwarded message ----------
> From: Linus Walleij <linus.walleij@linaro.org>
> Date: Tue, Feb 22, 2011 at 2:19 AM
> Subject: Re: [RFC] MMC: error handling improvements
> To: Brian Swetland <swetland@google.com>, David Brown
> <davidb@codeaurora.org
>>
> Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>, Chris Ball <
> cjb at laptop.org>, linux-mmc at vger.kernel.org,
> linux-arm-kernel at lists.infradead.org
>
>
> Out of sheer curiosity, Qualcomm/CodeAurora guys:
>
> if you dump out the registers at offset 0xfe0-0xfff on the
> SDCC, does it contain a valid PrimeCell ID? Anyone who
> can make a hexdump of it?
>
> It is possible to hardcode an AMBA ID to use this driver
> even if this area is just 0x0000... but I'm just curious
> about how different silicon vendors treat these registers,
> e.g. if they contain something sensible.
>
Linus,
These Prime cell ID registers are removed in the newer versions of the MSM
SDCC controller and are replaced with a different register that indicates
the controller version number. So, using these prime cell ID registers may
not be an option for us. Nevertheless, as you pointed out we can hard code
the AMBA ID in the platform device data and use that in the mmci driver to
handle stuff specific to this controller similar to what is done for ST
variant in mmci driver.
Though the bulk of the MSM SDCC controller is designed around PL180, there
are still some modifications to include flow control, SDIO support, Data
Mover interface (DMA engine on Qualcomm MSMs) etc. Support/ability to talk
to the Data Mover is one of the main differences when compared to original
PL180 prime cell.
Our main concern in moving to mmci is support for DMA that needs to be
added to this driver. I believe PL180 controller does have the ability to
talk to DMA engines, but i dont see any relevant support for that in mmci
driver, unless i grossly missed something.
Regards
P Murali Krishna
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
^ permalink raw reply
* MMC quirks relating to performance/lifetime.
From: Jens Axboe @ 2011-03-01 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102251321.09232.arnd@arndb.de>
On 2011-02-25 07:21, Arnd Bergmann wrote:
> On Friday 25 February 2011, Andrei Warkentin wrote:
>> Yup. I understand :-). That's the strategy I'm going to follow. For
>> page_size-alignment/splitting I'm looking at the block layer now. Is
>> that the right approach or should I still submit a (cleaned up) patch
>> to mmc/card/block.c for that performance improvement.
>
> I guess it should live in block/cfq-iosched in the long run, but I don't
> know how easy it is to implement it there for test purposes.
I don't think I saw the original patch(es) for this?
--
Jens Axboe
^ permalink raw reply
* [PATCH 1/2] ARM imx53: add pwm devices support
From: Uwe Kleine-König @ 2011-03-01 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimCxkN1HKvhoMS7kHBngYxk6jNbz5qTssH4Fz-B@mail.gmail.com>
Hi Fabio,
On Tue, Mar 01, 2011 at 10:47:23AM -0300, Fabio Estevam wrote:
> On Tue, Mar 1, 2011 at 6:38 AM, Jason Chen <b02280@freescale.com> wrote:
> ...
> > - ? ? ? if (cpu_is_mx27() || cpu_is_mx3() || cpu_is_mx25() || cpu_is_mx51()) {
> > + ? ? ? if (cpu_is_mx27() || cpu_is_mx3() || cpu_is_mx25() || cpu_is_mx51() ||
> > + ? ? ? ? ? ? ? cpu_is_mx53()) {
>
> Wouldn?t "if (!cpu_is_mx1() && !cpu_is_mx21())" work here and make
> the if statement simpler?
Yes, but less future proof. (Assume the next generation SoC is
different ...)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* MMC quirks relating to performance/lifetime.
From: Arnd Bergmann @ 2011-03-01 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6D3F71.4040605@kernel.dk>
On Tuesday 01 March 2011 19:48:17 Jens Axboe wrote:
>
> On 2011-02-25 07:21, Arnd Bergmann wrote:
> > On Friday 25 February 2011, Andrei Warkentin wrote:
> >> Yup. I understand :-). That's the strategy I'm going to follow. For
> >> page_size-alignment/splitting I'm looking at the block layer now. Is
> >> that the right approach or should I still submit a (cleaned up) patch
> >> to mmc/card/block.c for that performance improvement.
> >
> > I guess it should live in block/cfq-iosched in the long run, but I don't
> > know how easy it is to implement it there for test purposes.
>
> I don't think I saw the original patch(es) for this?
Nobody has posted one yet, only discussions. Andrei made a patch for the
MMC block driver to split requests in some cases, but I think the
concept has changed enough that it's probably not useful to look at
that patch.
I think what needs to be done here is to split requests in these cases:
* Small requests should be split on flash page boundaries, where a page
is typically 8 to 32 KB. Sending one hardware request that spans two
partial pages can be slower than sending two requests with the same
data, but on page boundaries.
* If a hardware transfer is limited to a few sectors, these should be
aligned to page boundaries. E.g. assuming a 16 sector page and 32 sector
maximum transfers, a request that spans from sector 7 to 62 should be
split into three transfers: 7-15, 16-47 and 48-62, not 7-38 and 39-62.
This reduces the number of page read-modify-write cycles that the drive
does.
* No request should ever span multiple erase blocks. Most flash drives today
have 4MB erase blocks (sometimes 1, 2 or 8), and the I/O scheduler should
treat the erase block boundary like a seek on a hard drive. The I/O
scheduler should try to send all sector writes of an erase block in sequence,
but after that it can chose any other erase block to write to next.
I think if we get this logic, we can deal well with all cheap flash drives.
The two parameters we need are the page size and the erase block size,
which the kernel can sometimes guess, but should also be tunable in
sysfs for devices that don't tell us or lie to the kernel about them.
I'm not sure if we want to do this for all nonrotational media, or
add another flag to enable these optimizations. On proper SSDs that have
an intelligent controller and enough RAM, they probably would not help
all that much, or even make it slightly slower due to a higher number
of separate write requests.
Arnd
^ permalink raw reply
* MMC quirks relating to performance/lifetime.
From: Jens Axboe @ 2011-03-01 19:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201103012011.51855.arnd@arndb.de>
On 2011-03-01 14:11, Arnd Bergmann wrote:
> On Tuesday 01 March 2011 19:48:17 Jens Axboe wrote:
>>
>> On 2011-02-25 07:21, Arnd Bergmann wrote:
>>> On Friday 25 February 2011, Andrei Warkentin wrote:
>>>> Yup. I understand :-). That's the strategy I'm going to follow. For
>>>> page_size-alignment/splitting I'm looking at the block layer now. Is
>>>> that the right approach or should I still submit a (cleaned up) patch
>>>> to mmc/card/block.c for that performance improvement.
>>>
>>> I guess it should live in block/cfq-iosched in the long run, but I don't
>>> know how easy it is to implement it there for test purposes.
>>
>> I don't think I saw the original patch(es) for this?
>
> Nobody has posted one yet, only discussions. Andrei made a patch for the
> MMC block driver to split requests in some cases, but I think the
> concept has changed enough that it's probably not useful to look at
> that patch.
>
> I think what needs to be done here is to split requests in these cases:
>
> * Small requests should be split on flash page boundaries, where a page
> is typically 8 to 32 KB. Sending one hardware request that spans two
> partial pages can be slower than sending two requests with the same
> data, but on page boundaries.
>
> * If a hardware transfer is limited to a few sectors, these should be
> aligned to page boundaries. E.g. assuming a 16 sector page and 32 sector
> maximum transfers, a request that spans from sector 7 to 62 should be
> split into three transfers: 7-15, 16-47 and 48-62, not 7-38 and 39-62.
> This reduces the number of page read-modify-write cycles that the drive
> does.
>
> * No request should ever span multiple erase blocks. Most flash drives today
> have 4MB erase blocks (sometimes 1, 2 or 8), and the I/O scheduler should
> treat the erase block boundary like a seek on a hard drive. The I/O
> scheduler should try to send all sector writes of an erase block in sequence,
> but after that it can chose any other erase block to write to next.
>
> I think if we get this logic, we can deal well with all cheap flash drives.
> The two parameters we need are the page size and the erase block size,
> which the kernel can sometimes guess, but should also be tunable in
> sysfs for devices that don't tell us or lie to the kernel about them.
>
> I'm not sure if we want to do this for all nonrotational media, or
> add another flag to enable these optimizations. On proper SSDs that have
> an intelligent controller and enough RAM, they probably would not help
> all that much, or even make it slightly slower due to a higher number
> of separate write requests.
Thanks for the recap. One way to handle this would be to have a dm
target that ensures that requests are never built up to violate any of
the above items. Doing splitting is a little silly, when you can prevent
it from happening in the first place.
Alternatively, a queue ->merge_bvec_fn() with a settings table could
provide the same.
As this is of limited scope, I would prefer having this done via a
plugin of some sort (like a dm target).
--
Jens Axboe
^ permalink raw reply
* [PATCH 6/7] OMAP: Serial: Allow UART parameters to be configured from board file
From: Sricharan R @ 2011-03-01 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298903958-6496-7-git-send-email-govindraj.raja@ti.com>
Hi,
>diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
>index 755f4aa..530e9e3 100644
>--- a/arch/arm/mach-omap2/serial.c
>+++ b/arch/arm/mach-omap2/serial.c
>@@ -44,6 +44,15 @@
>
> static int omap_uart_con_id __initdata = -1;
>
>+static struct omap_uart_port_info omap_serial_default_info[] = {
>+ {
>+ .dma_enabled = 0,
>+ .dma_rx_buf_size = DEFAULT_RXDMA_BUFSIZE,
>+ .dma_rx_timeout = DEFAULT_RXDMA_TIMEOUT,
>+ .idle_timeout = DEFAULT_IDLE_TIMEOUT,
>+ },
>+};
>+
> static int uart_idle_hwmod(struct omap_device *od)
> {
> omap_hwmod_idle(od->hwmods[0]);
>@@ -66,6 +75,54 @@ static struct omap_device_pm_latency
omap_uart_latency[]
>= {
> },
> };
>
>+#ifdef CONFIG_OMAP_MUX
>+static struct omap_device_pad default_serial0_pads[] __initdata = {
>+ {
>+ .name = "uart1_rx.uart1_rx",
>+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
>+ .enable = OMAP_MUX_MODE0,
>+ },
>+};
>+
>+static struct omap_device_pad default_serial1_pads[] __initdata = {
>+ {
>+ .name = "uart2_rx.uart2_rx",
>+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
>+ .enable = OMAP_MUX_MODE0,
>+ },
>+};
>+
>+static struct omap_device_pad default_serial2_pads[] __initdata = {
>+ {
>+ .name = "uart3_rx_irrx.uart3_rx_irrx",
>+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
>+ .enable = OMAP_MUX_MODE0,
>+ },
>+};
>+
>+static struct omap_device_pad default_omap36xx_serial3_pads[] __initdata
=
>{
>+ {
>+ .name = "gpmc_wait3.uart4_rx",
>+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
>+ .enable = OMAP_MUX_MODE2,
>+ },
>+};
>+
>+static struct omap_device_pad default_omap4_serial3_pads[] __initdata =
{
>+ {
>+ .name = "uart4_rx.uart4_rx",
>+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
>+ .enable = OMAP_MUX_MODE0,
>+ },
>+};
Here only the UART RX pins are muxed, so what about the cts, rts, tx pins?
Is it consistent that across all socs that only UART3 would have UART/IRDA
functions capability so that serial2 pads can always be called "rx_irxx"
?.
Thanks,
sricharan
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>the body of a message to majordomo at vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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