* [PATCH 6/6] ARM: nmk: update GPIO chained IRQ handler to use EOI in parent chip
From: Will Deacon @ 2011-03-02 15:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1103012133530.2701@localhost6.localdomain6>
Hi Thomas,
> Can you please take the time and explain me the difference of the
> following:
>
> irqchip1.c
>
> struct irq_chip1;
>
> handle_primary_irq(int irq, struct irq_desc *desc)
> {
> chip->irq_ack();
> desc->demux();
> }
>
> init()
> {
> irq_set_chip(PRIMARY_IRQ, &irq_chip1);
> irq_set_primary_handler(PRIMARY_IRQ, handle_primary_irq);
> }
I think with this approach you get the exact opposite problem; that
is the primary irq_chip doesn't know which IRQs are going to be
demuxed so it cannot know at init time which IRQs need their primary
handler set. Is the idea that you set_primary_handler for all IRQs,
stash that in the descriptor somewhere and then replace handle_irq
with the primary handler when a demux handler is registered?
I guess I'm missing something here,
Cheers,
Will
^ permalink raw reply
* [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
From: Jamie Iles @ 2011-03-02 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimdAMLk4scWECNjUmtxKNzd5bBK8VNcLjs8JjBH@mail.gmail.com>
On Wed, Mar 02, 2011 at 03:42:33PM +0100, Linus Walleij wrote:
> 2011/3/2 Jamie Iles <jamie@jamieiles.com>:
>
> >> > /sys/devices/system/soc/
> >> > /sys/devices/system/soc/unique_id<- Unified way to export an ID for all machs
> >>
> >> Arbitrary number of bits? Some will have a 64-bit ID, some will have 32-bit
> >> etc.
> >>
> >> Should we say it's a hex string of 64 bits?
> >
> > Could we provide hooks for the platform that takes the buffer and length
> > and let the platform do the snprintf()? ?Our devices have a 128-bit
> > serial number and I'm sure there must be others.
>
> Isn't it better to just make it 64-bit so that apps can always parse it,
> and then you can have your high-res numbers under mach?
>
> If there is no solid ABI for this there is no point to make it
> generic under /soc/unique_id at all.
I guess I'd argue that a arbitrary length hex string could be considered
as a solid ABI but you're right that it's probably more important to get
something out there and I'm probably being too picky, so apologies!
Jamie
^ permalink raw reply
* [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
From: Linus Walleij @ 2011-03-02 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110302113823.GB2728@pulham.picochip.com>
2011/3/2 Jamie Iles <jamie@jamieiles.com>:
>> > /sys/devices/system/soc/
>> > /sys/devices/system/soc/unique_id<- Unified way to export an ID for all machs
>>
>> Arbitrary number of bits? Some will have a 64-bit ID, some will have 32-bit
>> etc.
>>
>> Should we say it's a hex string of 64 bits?
>
> Could we provide hooks for the platform that takes the buffer and length
> and let the platform do the snprintf()? ?Our devices have a 128-bit
> serial number and I'm sure there must be others.
Isn't it better to just make it 64-bit so that apps can always parse it,
and then you can have your high-res numbers under mach?
If there is no solid ABI for this there is no point to make it
generic under /soc/unique_id at all.
/soc/name is another useful thing to have I think.
Apart from this we are now en route to the same color of
bikeshed discussion this patchset saw earlier, Maxime please
just implement something that works for you/us so others
can patch in whatever they need on top later.
Yours,
Linus Walleij
^ permalink raw reply
* [patch v2 2/3] arm: pmu: allow platform specifc irq enable/disable handling
From: Ming Lei @ 2011-03-02 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <-3190832915456449126@unknownmsgid>
Hi Will,
2011/3/2 Will Deacon <will.deacon@arm.com>:
> Looks good to me. Unfortunately, I don't have an OMAP4 to test this
> on (contributions welcome :) so I've just eyeballed the code:
>
> Reviewed-by: Will Deacon <will.deacon@arm.com>
>
> You'll need to wait for the ux500 stuff to be merged before you can
> get this upstream (Linus W is handling the pull request afaik).
Thanks for your review, the ux500 stuff has been merged into -next
tree already, so this one may be into -next too.
thanks,
--
Lei Ming
^ permalink raw reply
* [PATCH] ARM: mx3/mx35_3ds: Use MX35 USB OTG Erratum
From: Fabio Estevam @ 2011-03-02 14:26 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
arch/arm/mach-mx3/mach-mx35_3ds.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mx3/mach-mx35_3ds.c b/arch/arm/mach-mx3/mach-mx35_3ds.c
index 5f35d5c..f2cec07 100644
--- a/arch/arm/mach-mx3/mach-mx35_3ds.c
+++ b/arch/arm/mach-mx3/mach-mx35_3ds.c
@@ -132,6 +132,11 @@ static int mx35_3ds_otg_init(struct platform_device *pdev)
static const struct fsl_usb2_platform_data usb_otg_pdata __initconst = {
.operating_mode = FSL_USB2_DR_DEVICE,
.phy_mode = FSL_USB2_PHY_UTMI_WIDE,
+ .workaround = FLS_USB2_WORKAROUND_ENGCM09152,
+/*
+ * ENGCM09152 also requires a hardware change.
+ * Please check the MX35 Chip Errata document for details.
+ */
};
static struct mxc_usbh_platform_data otg_pdata __initdata = {
--
1.6.0.4
^ permalink raw reply related
* [PATCH] ARM: mxs/mx28evk: add flexcan devices
From: Sascha Hauer @ 2011-03-02 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110302125525.GD21601@S2100-06.ap.freescale.net>
On Wed, Mar 02, 2011 at 08:55:25PM +0800, Shawn Guo wrote:
> On Wed, Mar 02, 2011 at 07:45:50PM +0800, Shawn Guo wrote:
> > On Wed, Mar 02, 2011 at 12:11:48PM +0100, Sascha Hauer wrote:
> > > Hi Shawn,
> > >
> > Hi Sascha,
> >
> > > On Wed, Mar 02, 2011 at 06:54:44PM +0800, Shawn Guo wrote:
> > > > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> > > > ---
> > > > arch/arm/mach-mxs/Kconfig | 1 +
> > > > arch/arm/mach-mxs/mach-mx28evk.c | 37 +++++++++++++++++++++++++++++++++++++
> > > > 2 files changed, 38 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/arch/arm/mach-mxs/Kconfig b/arch/arm/mach-mxs/Kconfig
> > > > index 55bf075..9a1f2cb 100644
> > > > --- a/arch/arm/mach-mxs/Kconfig
> > > > +++ b/arch/arm/mach-mxs/Kconfig
> > > > @@ -31,6 +31,7 @@ config MACH_MX28EVK
> > > > select MXS_HAVE_AMBA_DUART
> > > > select MXS_HAVE_PLATFORM_AUART
> > > > select MXS_HAVE_PLATFORM_FEC
> > > > + select MXS_HAVE_PLATFORM_FLEXCAN
> > > > select MXS_OCOTP
> > > > default y
> > > > help
> > > > diff --git a/arch/arm/mach-mxs/mach-mx28evk.c b/arch/arm/mach-mxs/mach-mx28evk.c
> > > > index 1f0b708..3cefb73 100644
> > > > --- a/arch/arm/mach-mxs/mach-mx28evk.c
> > > > +++ b/arch/arm/mach-mxs/mach-mx28evk.c
> > > > @@ -28,6 +28,7 @@
> > > > #include "devices-mx28.h"
> > > > #include "gpio.h"
> > > >
> > > > +#define MX28EVK_FLEXCAN_SWITCH MXS_GPIO_NR(2, 13)
> > > > #define MX28EVK_FEC_PHY_POWER MXS_GPIO_NR(2, 15)
> > > > #define MX28EVK_FEC_PHY_RESET MXS_GPIO_NR(4, 13)
> > > >
> > > > @@ -95,6 +96,15 @@ static const iomux_cfg_t mx28evk_pads[] __initconst = {
> > > > /* phy reset line */
> > > > MX28_PAD_ENET0_RX_CLK__GPIO_4_13 |
> > > > (MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
> > > > +
> > > > + /* flexcan0 */
> > > > + MX28_PAD_GPMI_RDY2__CAN0_TX,
> > > > + MX28_PAD_GPMI_RDY3__CAN0_RX,
> > > > + /* flexcan1 */
> > > > + MX28_PAD_GPMI_CE2N__CAN1_TX,
> > > > + MX28_PAD_GPMI_CE3N__CAN1_RX,
> > > > + /* transceiver power control */
> > > > + MX28_PAD_SSP1_CMD__GPIO_2_13,
> > > > };
> > > >
> > > > /* fec */
> > > > @@ -178,8 +188,28 @@ error:
> > > > return -ETIMEDOUT;
> > > > }
> > > >
> > > > +/* flexcan */
> > > > +static void mx28evk_flexcan_switch(int enable)
> > > > +{
> > > > + static int count;
> > > > +
> > > > + if (enable) {
> > > > + if (!count++)
> > > > + gpio_set_value(MX28EVK_FLEXCAN_SWITCH, 1);
> > > > + } else {
> > > > + if (!--count)
> > > > + gpio_set_value(MX28EVK_FLEXCAN_SWITCH, 0);
> > > > + }
> > > > +}
> > >
> > > Why this count variable? It shouldn't hurt to call gpio_set_value
> > > multiple times.
> > >
> Something like this?
>
> /*
> * On mx28evk board, two flexcan transceivers are controlled
> * by one power switch gpio.
> */
> #define FLEXCAN0_SWITCH_ON (1 << 0)
> #define FLEXCAN1_SWITCH_ON (1 << 1)
>
> static int flexcan_switch_on;
>
> static void mx28evk_flexcan0_switch(int enable)
> {
> if (enable) {
> flexcan_switch_on |= FLEXCAN0_SWITCH_ON;
> gpio_set_value(MX28EVK_FLEXCAN_SWITCH, 1);
> } else {
> flexcan_switch_on &= ~FLEXCAN0_SWITCH_ON;
> if (!flexcan_switch_on)
> gpio_set_value(MX28EVK_FLEXCAN_SWITCH, 0);
> }
> }
>
> static void mx28evk_flexcan1_switch(int enable)
> {
> if (enable) {
> flexcan_switch_on |= FLEXCAN1_SWITCH_ON;
> gpio_set_value(MX28EVK_FLEXCAN_SWITCH, 1);
> } else {
> flexcan_switch_on &= ~FLEXCAN1_SWITCH_ON;
> if (!flexcan_switch_on)
> gpio_set_value(MX28EVK_FLEXCAN_SWITCH, 0);
> }
> }
>
> static const struct flexcan_platform_data
> mx28evk_flexcan_pdata[] __initconst = {
> {
> .transceiver_switch = mx28evk_flexcan0_switch,
> }, {
> .transceiver_switch = mx28evk_flexcan1_switch,
> }
> };
More like this, which is slightly easier to read, but the effect is the
same.
static int flexcan0_en, flexcan0_en;
/*
* MX28EVK_FLEXCAN_SWITCH is shared between both can controllers
*/
static void mx28evk_flexcan_switch(void)
{
if (flexcan0_en || flexcan1_en)
gpio_set_value(MX28EVK_FLEXCAN_SWITCH, 1);
else
gpio_set_value(MX28EVK_FLEXCAN_SWITCH, 0);
}
static void mx28evk_flexcan0_switch(int enable)
{
flexcan0_en = enable;
mx28evk_flexcan_switch();
}
static void mx28evk_flexcan1_switch(int enable)
{
flexcan1_en = enable;
mx28evk_flexcan_switch();
}
static const struct flexcan_platform_data
mx28evk_flexcan_pdata[] __initconst = {
{
.transceiver_switch = mx28evk_flexcan0_switch,
}, {
.transceiver_switch = mx28evk_flexcan1_switch,
}
};
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v2 15/18] omap3+: sr: disable spamming interrupts
From: Sergei Shtylyov @ 2011-03-02 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299063331-27968-16-git-send-email-nm@ti.com>
Hello.
On 02-03-2011 13:55, Nishanth Menon wrote:
> At times with bad SR configurations especially during silicon bringups,
> we could get continuous spurious interrupts which end up hanging the
> platform in the form of an ISR call for status bits that are
> automatically enabled by the h/w without any s/w clearing option.
> If we detect scenarios where isr was called without the corresponding
> notification bit being set, instead of hanging up the system,
> we will disable interrupt after noting the event in the system log
> to try and keep system sanity and allow developer to debug and fix
> the condition.
> Signed-off-by: Nishanth Menon<nm@ti.com>
> ---
> arch/arm/mach-omap2/smartreflex.c | 12 ++++++++++--
> 1 files changed, 10 insertions(+), 2 deletions(-)
> diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
> index 49a04ea..d62da3d 100644
> --- a/arch/arm/mach-omap2/smartreflex.c
> +++ b/arch/arm/mach-omap2/smartreflex.c
> @@ -209,8 +209,16 @@ static irqreturn_t sr_interrupt(int irq, void *data)
> value = irqstat_to_notifier_v2(status);
> }
>
> - if (sr_class->notify)
> - sr_class->notify(sr_info->voltdm, value);
> + /* Attempt some resemblence of recovery! */
Resemblance?
WBR, Sergei
^ permalink raw reply
* [PATCH v2 10/18] omap3+: sr: call handler with interrupt disabled
From: Sergei Shtylyov @ 2011-03-02 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299063331-27968-11-git-send-email-nm@ti.com>
Hello.
On 02-03-2011 13:55, Nishanth Menon wrote:
> Request the handler irq such that there is no nesting for calls.
> the notifiers are not expected to be nested, further the interrupt
> events for status change should be handled prior to the next event
> else there is a risk of loosing events.
> Signed-off-by: Nishanth Menon<nm@ti.com>
> ---
> arch/arm/mach-omap2/smartreflex.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
> diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c
> index 99e4c4f..a4e9f2d 100644
> --- a/arch/arm/mach-omap2/smartreflex.c
> +++ b/arch/arm/mach-omap2/smartreflex.c
> @@ -278,7 +278,7 @@ static int sr_late_init(struct omap_sr *sr_info)
> goto error;
> }
> ret = request_irq(sr_info->irq, sr_interrupt,
> - 0, name, (void *)sr_info);
> + IRQF_DISABLED, name, (void *)sr_info);
Isn't this flag a nop now?
WBR, Sergei
^ permalink raw reply
* [PATCH v8 1/1] PRUSS UIO driver support
From: Thomas Gleixner @ 2011-03-02 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299065886-30099-2-git-send-email-pratheesh@ti.com>
On Wed, 2 Mar 2011, Pratheesh Gangadhar wrote:
> This patch implements PRUSS (Programmable Real-time Unit Sub System)
> UIO driver which exports SOC resources associated with PRUSS like
> I/O, memories and IRQs to user space. PRUSS is dual 32-bit RISC
> processors which is efficient in performing embedded tasks that
> require manipulation of packed memory mapped data structures and
> handling system events that have tight real time constraints. This
> driver is currently supported on Texas Instruments DA850, AM18xx and
> OMAP-L138 devices.
> For example, PRUSS runs firmware for real-time critical industrial
> communication data link layer and communicates with application stack
> running in user space via shared memory and IRQs.
>
> Signed-off-by: Pratheesh Gangadhar <pratheesh@ti.com>
> Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
No further objections.
Thanks for your patience,
tglx
^ permalink raw reply
* [PATCH v8 1/1] PRUSS UIO driver support
From: Arnd Bergmann @ 2011-03-02 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299065886-30099-2-git-send-email-pratheesh@ti.com>
On Wednesday 02 March 2011, Pratheesh Gangadhar wrote:
> +
> +static struct clk *pruss_clk;
> +static struct uio_info *info;
> +static dma_addr_t sram_paddr, ddr_paddr;
> +static void *prussio_vaddr, *sram_vaddr, *ddr_vaddr;
> +
To my initial comment about these being single-instance
variables, you said you'd change that, which has not happened
yet.
Also, I now noticed that the types are wrong, you are
missing __iomem annotations for MMIO ranges. Please make
sure that the code builds fine with sparse and "make C=1",
which will tell you about these problems.
Arnd
^ permalink raw reply
* [PATCH] ARM: mxs/mx28evk: add flexcan devices
From: Shawn Guo @ 2011-03-02 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110302131425.GD22310@pengutronix.de>
On Wed, Mar 02, 2011 at 02:14:25PM +0100, Uwe Kleine-K?nig wrote:
> Hello,
>
> On Wed, Mar 02, 2011 at 06:54:44PM +0800, Shawn Guo wrote:
> > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> > ---
> > arch/arm/mach-mxs/Kconfig | 1 +
> > arch/arm/mach-mxs/mach-mx28evk.c | 37 +++++++++++++++++++++++++++++++++++++
> > 2 files changed, 38 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-mxs/Kconfig b/arch/arm/mach-mxs/Kconfig
> > index 55bf075..9a1f2cb 100644
> > --- a/arch/arm/mach-mxs/Kconfig
> > +++ b/arch/arm/mach-mxs/Kconfig
> > @@ -31,6 +31,7 @@ config MACH_MX28EVK
> > select MXS_HAVE_AMBA_DUART
> > select MXS_HAVE_PLATFORM_AUART
> > select MXS_HAVE_PLATFORM_FEC
> > + select MXS_HAVE_PLATFORM_FLEXCAN
> > select MXS_OCOTP
> > default y
> > help
> > diff --git a/arch/arm/mach-mxs/mach-mx28evk.c b/arch/arm/mach-mxs/mach-mx28evk.c
> > index 1f0b708..3cefb73 100644
> > --- a/arch/arm/mach-mxs/mach-mx28evk.c
> > +++ b/arch/arm/mach-mxs/mach-mx28evk.c
> > @@ -28,6 +28,7 @@
> > #include "devices-mx28.h"
> > #include "gpio.h"
> >
> > +#define MX28EVK_FLEXCAN_SWITCH MXS_GPIO_NR(2, 13)
> > #define MX28EVK_FEC_PHY_POWER MXS_GPIO_NR(2, 15)
> > #define MX28EVK_FEC_PHY_RESET MXS_GPIO_NR(4, 13)
> >
> > @@ -95,6 +96,15 @@ static const iomux_cfg_t mx28evk_pads[] __initconst = {
> > /* phy reset line */
> > MX28_PAD_ENET0_RX_CLK__GPIO_4_13 |
> > (MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
> > +
> > + /* flexcan0 */
> > + MX28_PAD_GPMI_RDY2__CAN0_TX,
> > + MX28_PAD_GPMI_RDY3__CAN0_RX,
> > + /* flexcan1 */
> > + MX28_PAD_GPMI_CE2N__CAN1_TX,
> > + MX28_PAD_GPMI_CE3N__CAN1_RX,
> > + /* transceiver power control */
> > + MX28_PAD_SSP1_CMD__GPIO_2_13,
> > };
> >
> > /* fec */
> > @@ -178,8 +188,28 @@ error:
> > return -ETIMEDOUT;
> > }
> >
> > +/* flexcan */
> > +static void mx28evk_flexcan_switch(int enable)
> > +{
> > + static int count;
> > +
> > + if (enable) {
> > + if (!count++)
> > + gpio_set_value(MX28EVK_FLEXCAN_SWITCH, 1);
> > + } else {
> > + if (!--count)
> > + gpio_set_value(MX28EVK_FLEXCAN_SWITCH, 0);
> > + }
> > +}
> > +
> > +static const struct flexcan_platform_data mx28evk_flexcan_pdata __initconst = {
> > + .transceiver_switch = mx28evk_flexcan_switch,
> > +};
> > +
> > static void __init mx28evk_init(void)
> > {
> > + int ret;
> > +
> > mxs_iomux_setup_multiple_pads(mx28evk_pads, ARRAY_SIZE(mx28evk_pads));
> >
> > mx28_add_duart();
> > @@ -192,6 +222,13 @@ static void __init mx28evk_init(void)
> > mx28evk_fec_reset();
> > mx28_add_fec(0, &mx28_fec_pdata[0]);
> > mx28_add_fec(1, &mx28_fec_pdata[1]);
> > +
> > + ret = gpio_request_one(MX28EVK_FLEXCAN_SWITCH, GPIOF_DIR_OUT,
> > + "flexcan-switch");
> > + if (ret)
> > + pr_warn("failed to request gpio flexcan-switch: %d\n", ret);
> > + mx28_add_flexcan(0, &mx28evk_flexcan_pdata);
> > + mx28_add_flexcan(1, &mx28evk_flexcan_pdata);
> You must not add the flexcan devices if gpio_request failed. Otherwise
> you use the gpio anyhow.
>
Ah, yes.
--
Regards,
Shawn
^ permalink raw reply
* [PATCH] ARM: mxs/mx28evk: add flexcan devices
From: Uwe Kleine-König @ 2011-03-02 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299063284-21795-1-git-send-email-shawn.guo@freescale.com>
Hello,
On Wed, Mar 02, 2011 at 06:54:44PM +0800, Shawn Guo wrote:
> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> ---
> arch/arm/mach-mxs/Kconfig | 1 +
> arch/arm/mach-mxs/mach-mx28evk.c | 37 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 38 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-mxs/Kconfig b/arch/arm/mach-mxs/Kconfig
> index 55bf075..9a1f2cb 100644
> --- a/arch/arm/mach-mxs/Kconfig
> +++ b/arch/arm/mach-mxs/Kconfig
> @@ -31,6 +31,7 @@ config MACH_MX28EVK
> select MXS_HAVE_AMBA_DUART
> select MXS_HAVE_PLATFORM_AUART
> select MXS_HAVE_PLATFORM_FEC
> + select MXS_HAVE_PLATFORM_FLEXCAN
> select MXS_OCOTP
> default y
> help
> diff --git a/arch/arm/mach-mxs/mach-mx28evk.c b/arch/arm/mach-mxs/mach-mx28evk.c
> index 1f0b708..3cefb73 100644
> --- a/arch/arm/mach-mxs/mach-mx28evk.c
> +++ b/arch/arm/mach-mxs/mach-mx28evk.c
> @@ -28,6 +28,7 @@
> #include "devices-mx28.h"
> #include "gpio.h"
>
> +#define MX28EVK_FLEXCAN_SWITCH MXS_GPIO_NR(2, 13)
> #define MX28EVK_FEC_PHY_POWER MXS_GPIO_NR(2, 15)
> #define MX28EVK_FEC_PHY_RESET MXS_GPIO_NR(4, 13)
>
> @@ -95,6 +96,15 @@ static const iomux_cfg_t mx28evk_pads[] __initconst = {
> /* phy reset line */
> MX28_PAD_ENET0_RX_CLK__GPIO_4_13 |
> (MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
> +
> + /* flexcan0 */
> + MX28_PAD_GPMI_RDY2__CAN0_TX,
> + MX28_PAD_GPMI_RDY3__CAN0_RX,
> + /* flexcan1 */
> + MX28_PAD_GPMI_CE2N__CAN1_TX,
> + MX28_PAD_GPMI_CE3N__CAN1_RX,
> + /* transceiver power control */
> + MX28_PAD_SSP1_CMD__GPIO_2_13,
> };
>
> /* fec */
> @@ -178,8 +188,28 @@ error:
> return -ETIMEDOUT;
> }
>
> +/* flexcan */
> +static void mx28evk_flexcan_switch(int enable)
> +{
> + static int count;
> +
> + if (enable) {
> + if (!count++)
> + gpio_set_value(MX28EVK_FLEXCAN_SWITCH, 1);
> + } else {
> + if (!--count)
> + gpio_set_value(MX28EVK_FLEXCAN_SWITCH, 0);
> + }
> +}
> +
> +static const struct flexcan_platform_data mx28evk_flexcan_pdata __initconst = {
> + .transceiver_switch = mx28evk_flexcan_switch,
> +};
> +
> static void __init mx28evk_init(void)
> {
> + int ret;
> +
> mxs_iomux_setup_multiple_pads(mx28evk_pads, ARRAY_SIZE(mx28evk_pads));
>
> mx28_add_duart();
> @@ -192,6 +222,13 @@ static void __init mx28evk_init(void)
> mx28evk_fec_reset();
> mx28_add_fec(0, &mx28_fec_pdata[0]);
> mx28_add_fec(1, &mx28_fec_pdata[1]);
> +
> + ret = gpio_request_one(MX28EVK_FLEXCAN_SWITCH, GPIOF_DIR_OUT,
> + "flexcan-switch");
> + if (ret)
> + pr_warn("failed to request gpio flexcan-switch: %d\n", ret);
> + mx28_add_flexcan(0, &mx28evk_flexcan_pdata);
> + mx28_add_flexcan(1, &mx28evk_flexcan_pdata);
You must not add the flexcan devices if gpio_request failed. Otherwise
you use the gpio anyhow.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] ARM: mxs/mx28evk: add flexcan devices
From: Shawn Guo @ 2011-03-02 12:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110302114549.GC21601@S2100-06.ap.freescale.net>
On Wed, Mar 02, 2011 at 07:45:50PM +0800, Shawn Guo wrote:
> On Wed, Mar 02, 2011 at 12:11:48PM +0100, Sascha Hauer wrote:
> > Hi Shawn,
> >
> Hi Sascha,
>
> > On Wed, Mar 02, 2011 at 06:54:44PM +0800, Shawn Guo wrote:
> > > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> > > ---
> > > arch/arm/mach-mxs/Kconfig | 1 +
> > > arch/arm/mach-mxs/mach-mx28evk.c | 37 +++++++++++++++++++++++++++++++++++++
> > > 2 files changed, 38 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-mxs/Kconfig b/arch/arm/mach-mxs/Kconfig
> > > index 55bf075..9a1f2cb 100644
> > > --- a/arch/arm/mach-mxs/Kconfig
> > > +++ b/arch/arm/mach-mxs/Kconfig
> > > @@ -31,6 +31,7 @@ config MACH_MX28EVK
> > > select MXS_HAVE_AMBA_DUART
> > > select MXS_HAVE_PLATFORM_AUART
> > > select MXS_HAVE_PLATFORM_FEC
> > > + select MXS_HAVE_PLATFORM_FLEXCAN
> > > select MXS_OCOTP
> > > default y
> > > help
> > > diff --git a/arch/arm/mach-mxs/mach-mx28evk.c b/arch/arm/mach-mxs/mach-mx28evk.c
> > > index 1f0b708..3cefb73 100644
> > > --- a/arch/arm/mach-mxs/mach-mx28evk.c
> > > +++ b/arch/arm/mach-mxs/mach-mx28evk.c
> > > @@ -28,6 +28,7 @@
> > > #include "devices-mx28.h"
> > > #include "gpio.h"
> > >
> > > +#define MX28EVK_FLEXCAN_SWITCH MXS_GPIO_NR(2, 13)
> > > #define MX28EVK_FEC_PHY_POWER MXS_GPIO_NR(2, 15)
> > > #define MX28EVK_FEC_PHY_RESET MXS_GPIO_NR(4, 13)
> > >
> > > @@ -95,6 +96,15 @@ static const iomux_cfg_t mx28evk_pads[] __initconst = {
> > > /* phy reset line */
> > > MX28_PAD_ENET0_RX_CLK__GPIO_4_13 |
> > > (MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
> > > +
> > > + /* flexcan0 */
> > > + MX28_PAD_GPMI_RDY2__CAN0_TX,
> > > + MX28_PAD_GPMI_RDY3__CAN0_RX,
> > > + /* flexcan1 */
> > > + MX28_PAD_GPMI_CE2N__CAN1_TX,
> > > + MX28_PAD_GPMI_CE3N__CAN1_RX,
> > > + /* transceiver power control */
> > > + MX28_PAD_SSP1_CMD__GPIO_2_13,
> > > };
> > >
> > > /* fec */
> > > @@ -178,8 +188,28 @@ error:
> > > return -ETIMEDOUT;
> > > }
> > >
> > > +/* flexcan */
> > > +static void mx28evk_flexcan_switch(int enable)
> > > +{
> > > + static int count;
> > > +
> > > + if (enable) {
> > > + if (!count++)
> > > + gpio_set_value(MX28EVK_FLEXCAN_SWITCH, 1);
> > > + } else {
> > > + if (!--count)
> > > + gpio_set_value(MX28EVK_FLEXCAN_SWITCH, 0);
> > > + }
> > > +}
> >
> > Why this count variable? It shouldn't hurt to call gpio_set_value
> > multiple times.
> >
Something like this?
/*
* On mx28evk board, two flexcan transceivers are controlled
* by one power switch gpio.
*/
#define FLEXCAN0_SWITCH_ON (1 << 0)
#define FLEXCAN1_SWITCH_ON (1 << 1)
static int flexcan_switch_on;
static void mx28evk_flexcan0_switch(int enable)
{
if (enable) {
flexcan_switch_on |= FLEXCAN0_SWITCH_ON;
gpio_set_value(MX28EVK_FLEXCAN_SWITCH, 1);
} else {
flexcan_switch_on &= ~FLEXCAN0_SWITCH_ON;
if (!flexcan_switch_on)
gpio_set_value(MX28EVK_FLEXCAN_SWITCH, 0);
}
}
static void mx28evk_flexcan1_switch(int enable)
{
if (enable) {
flexcan_switch_on |= FLEXCAN1_SWITCH_ON;
gpio_set_value(MX28EVK_FLEXCAN_SWITCH, 1);
} else {
flexcan_switch_on &= ~FLEXCAN1_SWITCH_ON;
if (!flexcan_switch_on)
gpio_set_value(MX28EVK_FLEXCAN_SWITCH, 0);
}
}
static const struct flexcan_platform_data
mx28evk_flexcan_pdata[] __initconst = {
{
.transceiver_switch = mx28evk_flexcan0_switch,
}, {
.transceiver_switch = mx28evk_flexcan1_switch,
}
};
--
Regards,
Shawn
^ permalink raw reply
* [PATCH] omap:iommu-added cache flushing operation for L2 cache
From: Santosh Shilimkar @ 2011-03-02 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299008793-27428-1-git-send-email-fernando.lugo@ti.com>
Hello,
> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> owner at vger.kernel.org] On Behalf Of Fernando Guzman Lugo
> Sent: Wednesday, March 02, 2011 1:17 AM
> To: hiroshi.doyu at nokia.com
> Cc: tony at atomide.com; linux at arm.linux.org.uk; linux-
> omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org; Ramesh Gupta; Hari Kanigeri
> Subject: [PATCH] omap:iommu-added cache flushing operation for L2
> cache
>
> From: Ramesh Gupta <grgupta@ti.com>
>
> Signed-off-by: Ramesh Gupta <grgupta@ti.com>
> Signed-off-by: Hari Kanigeri <h-kanigeri2@ti.com>
> ---
> arch/arm/plat-omap/iommu.c | 22 ++++++++--------------
> 1 files changed, 8 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
> index e3eb038..aeb2c33 100644
> --- a/arch/arm/plat-omap/iommu.c
> +++ b/arch/arm/plat-omap/iommu.c
> @@ -471,22 +471,15 @@ EXPORT_SYMBOL_GPL(foreach_iommu_device);
> */
> static void flush_iopgd_range(u32 *first, u32 *last)
> {
> - /* FIXME: L2 cache should be taken care of if it exists */
> - do {
> - asm("mcr p15, 0, %0, c7, c10, 1 @ flush_pgd"
> - : : "r" (first));
> - first += L1_CACHE_BYTES / sizeof(*first);
> - } while (first <= last);
> + dmac_flush_range(first, last);
There is note just above this API.
/*
* These are private to the dma-mapping API. Do not use directly.
* Their sole purpose is to ensure that data held in the cache
* is visible to DMA, or data written by DMA to system memory is
* visible to the CPU.
*/
#define dmac_map_area cpu_cache.dma_map_area
#define dmac_unmap_area cpu_cache.dma_unmap_area
#define dmac_flush_range cpu_cache.dma_flush_range
> + outer_flush_range(virt_to_phys(first), virt_to_phys(last));
> }
>
^ permalink raw reply
* [patch v2 3/3] arm: omap4: support pmu
From: Santosh Shilimkar @ 2011-03-02 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299063420-22203-4-git-send-email-tom.leiming@gmail.com>
Tom,
> -----Original Message-----
> From: linux-arm-kernel-bounces at lists.infradead.org [mailto:linux-
> arm-kernel-bounces at lists.infradead.org] On Behalf Of
> tom.leiming at gmail.com
> Sent: Wednesday, March 02, 2011 4:27 PM
> To: linux at arm.linux.org.uk
> Cc: Woodruff Richard; Tony Lindgren; Ming Lei; will.deacon at arm.com;
> linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: [patch v2 3/3] arm: omap4: support pmu
>
> 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
> about "Oprofile on Pandaboard / Omap4" on
> 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>
> ---
Few comments.
> arch/arm/mach-omap2/dbg44xx.h | 18 +++++++++
> arch/arm/mach-omap2/devices.c | 83
> +++++++++++++++++++++++++++++++++++++++-
> 2 files changed, 98 insertions(+), 3 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
You don't need this file. Move this base addresses to
arch/arm/plat-omap/include/plat/omap44xx.h
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-
> omap2/devices.c
> index d216976..bae02d5 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -22,6 +22,7 @@
> #include <asm/mach-types.h>
> #include <asm/mach/map.h>
> #include <asm/pmu.h>
> +#include <asm/cti.h>
>
> #include <plat/tc.h>
> #include <plat/board.h>
> @@ -35,6 +36,7 @@
>
> #include "mux.h"
> #include "control.h"
> +#include "dbg44xx.h"
>
> #if defined(CONFIG_VIDEO_OMAP2) ||
> defined(CONFIG_VIDEO_OMAP2_MODULE)
>
> @@ -322,20 +324,95 @@ 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,
> };
>
> +static struct arm_pmu_platdata omap4_pmu_data;
> +static struct cti omap4_cti[2];
> +
> +static void omap4_enable_cti(int irq)
> +{
> + if (irq == OMAP44XX_IRQ_CTI0)
> + cti_enable(&omap4_cti[0]);
> + else if (irq == OMAP44XX_IRQ_CTI1)
> + cti_enable(&omap4_cti[1]);
> +}
> +
> +static void omap4_disable_cti(int irq)
> +{
> + if (irq == OMAP44XX_IRQ_CTI0)
> + cti_disable(&omap4_cti[0]);
> + else if (irq == OMAP44XX_IRQ_CTI1)
> + cti_disable(&omap4_cti[1]);
> +}
> +
> +static irqreturn_t omap4_pmu_handler(int irq, void *dev,
> irq_handler_t handler)
> +{
> + if (irq == OMAP44XX_IRQ_CTI0)
> + cti_irq_ack(&omap4_cti[0]);
> + else if (irq == OMAP44XX_IRQ_CTI1)
> + cti_irq_ack(&omap4_cti[1]);
> +
> + return handler(irq, dev);
> +}
> +
> +static void omap4_configure_pmu_irq(void)
> +{
> + void *base0;
> + void *base1;
s/ void *base/ void __iomem *base
> +
> + base0 = ioremap(OMAP44XX_CTI0_BASE, 4096);
s/4096/SZ_4K
> + base1 = ioremap(OMAP44XX_CTI1_BASE, 4096);
> + if (!base0 && !base1) {
> + pr_err("ioremap for omap4 CTI failed\n");
s/omap4/OMAP4
> + return;
> + }
> +
> + /*configure CTI0 for pmu irq routing*/
> + cti_init(&omap4_cti[0], base0, OMAP44XX_IRQ_CTI0, 6);
> + cti_unlock(&omap4_cti[0]);
> + cti_map_trigger(&omap4_cti[0], 1, 6, 2);
> +
> + /*configure CTI1 for pmu irq routing*/
> + cti_init(&omap4_cti[1], base1, OMAP44XX_IRQ_CTI1, 6);
> + cti_unlock(&omap4_cti[1]);
> + cti_map_trigger(&omap4_cti[1], 1, 6, 2);
> +
> + omap4_pmu_data.handle_irq = omap4_pmu_handler;
> + omap4_pmu_data.enable_irq = omap4_enable_cti;
> + omap4_pmu_data.disable_irq = omap4_disable_cti;
> +}
> +
> static void omap_init_pmu(void)
> {
> - if (cpu_is_omap24xx())
> + if (cpu_is_omap24xx()) {
> omap_pmu_device.resource = &omap2_pmu_resource;
> - else if (cpu_is_omap34xx())
> + } 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;
> + omap_pmu_device.dev.platform_data = &omap4_pmu_data;
> + omap4_configure_pmu_irq();
> + } else {
> return;
> + }
>
> platform_device_register(&omap_pmu_device);
> }
> --
> 1.7.3
>
>
> _______________________________________________
> 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] OMAP:iommu - pgd and pte entries weren't getting flushed out
From: David Cohen @ 2011-03-02 12:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299008793-27428-2-git-send-email-fernando.lugo@ti.com>
Hi,
On Tue, Mar 1, 2011 at 9:46 PM, Fernando Guzman Lugo
<fernando.lugo@ti.com> wrote:
> From: Hari Kanigeri <h-kanigeri2@ti.com>
>
> pgd and pte entries weren't getting flushed out leading to MMU faults.
May I ask you to add to the patch body description why it's wrong and
why your solution is necessary?
Br,
David
>
> Signed-off-by: Hari Kanigeri <h-kanigeri2@ti.com>
> ---
> ?arch/arm/plat-omap/iommu.c | ? 12 ++++++------
> ?1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
> index aeb2c33..e9473ff 100644
> --- a/arch/arm/plat-omap/iommu.c
> +++ b/arch/arm/plat-omap/iommu.c
> @@ -508,7 +508,7 @@ static u32 *iopte_alloc(struct iommu *obj, u32 *iopgd, u32 da)
> ? ? ? ? ? ? ? ? ? ? ? ?return ERR_PTR(-ENOMEM);
>
> ? ? ? ? ? ? ? ?*iopgd = virt_to_phys(iopte) | IOPGD_TABLE;
> - ? ? ? ? ? ? ? flush_iopgd_range(iopgd, iopgd);
> + ? ? ? ? ? ? ? flush_iopgd_range(iopgd, iopgd + 1);
>
> ? ? ? ? ? ? ? ?dev_vdbg(obj->dev, "%s: a new pte:%p\n", __func__, iopte);
> ? ? ? ?} else {
> @@ -537,7 +537,7 @@ static int iopgd_alloc_section(struct iommu *obj, u32 da, u32 pa, u32 prot)
> ? ? ? ?}
>
> ? ? ? ?*iopgd = (pa & IOSECTION_MASK) | prot | IOPGD_SECTION;
> - ? ? ? flush_iopgd_range(iopgd, iopgd);
> + ? ? ? flush_iopgd_range(iopgd, iopgd + 1);
> ? ? ? ?return 0;
> ?}
>
> @@ -554,7 +554,7 @@ static int iopgd_alloc_super(struct iommu *obj, u32 da, u32 pa, u32 prot)
>
> ? ? ? ?for (i = 0; i < 16; i++)
> ? ? ? ? ? ? ? ?*(iopgd + i) = (pa & IOSUPER_MASK) | prot | IOPGD_SUPER;
> - ? ? ? flush_iopgd_range(iopgd, iopgd + 15);
> + ? ? ? flush_iopgd_range(iopgd, iopgd + 16);
> ? ? ? ?return 0;
> ?}
>
> @@ -567,7 +567,7 @@ static int iopte_alloc_page(struct iommu *obj, u32 da, u32 pa, u32 prot)
> ? ? ? ? ? ? ? ?return PTR_ERR(iopte);
>
> ? ? ? ?*iopte = (pa & IOPAGE_MASK) | prot | IOPTE_SMALL;
> - ? ? ? flush_iopte_range(iopte, iopte);
> + ? ? ? flush_iopte_range(iopte, iopte + 1);
>
> ? ? ? ?dev_vdbg(obj->dev, "%s: da:%08x pa:%08x pte:%p *pte:%08x\n",
> ? ? ? ? ? ? ? ? __func__, da, pa, iopte, *iopte);
> @@ -592,7 +592,7 @@ static int iopte_alloc_large(struct iommu *obj, u32 da, u32 pa, u32 prot)
>
> ? ? ? ?for (i = 0; i < 16; i++)
> ? ? ? ? ? ? ? ?*(iopte + i) = (pa & IOLARGE_MASK) | prot | IOPTE_LARGE;
> - ? ? ? flush_iopte_range(iopte, iopte + 15);
> + ? ? ? flush_iopte_range(iopte, iopte + 16);
> ? ? ? ?return 0;
> ?}
>
> @@ -763,7 +763,7 @@ void iopgtable_clear_entry_all(struct iommu *obj)
> ? ? ? ? ? ? ? ? ? ? ? ?iopte_free(iopte_offset(iopgd, 0));
>
> ? ? ? ? ? ? ? ?*iopgd = 0;
> - ? ? ? ? ? ? ? flush_iopgd_range(iopgd, iopgd);
> + ? ? ? ? ? ? ? flush_iopgd_range(iopgd, iopgd + 1);
> ? ? ? ?}
>
> ? ? ? ?flush_iotlb_all(obj);
> --
> 1.7.0.4
>
> --
> 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
* [PATCH 3/3] ARM: tegra: trimslice: initialize PCI-e only when running on TrimSlice
From: Mike Rapoport @ 2011-03-02 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1299068166.git.mike@compulab.co.il>
Currently tegra_pcie_init is effectively called as subsys_initcall. With
multiplatform kernel this may cause hangs on boards that don't intend to
support Tegra2 PCI-e. Ensure that TrimSlice board code initializes PCI-e
only when actually running on the TrimSlice.
Signed-off-by: Mike Rapoport <mike@compulab.co.il>
---
arch/arm/mach-tegra/board-trimslice.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-tegra/board-trimslice.c b/arch/arm/mach-tegra/board-trimslice.c
index 0f3081a..7be7d4a 100644
--- a/arch/arm/mach-tegra/board-trimslice.c
+++ b/arch/arm/mach-tegra/board-trimslice.c
@@ -79,6 +79,9 @@ static __initdata struct tegra_clk_init_table trimslice_clk_init_table[] = {
static int __init tegra_trimslice_pci_init(void)
{
+ if (!machine_is_trimslice())
+ return 0;
+
return tegra_pcie_init(true, true);
}
subsys_initcall(tegra_trimslice_pci_init);
--
1.7.3.1
^ permalink raw reply related
* [PATCH 2/3] ARM: tegra: add PCI Express power gating
From: Mike Rapoport @ 2011-03-02 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1299068166.git.mike@compulab.co.il>
Signed-off-by: Mike Rapoport <mike@compulab.co.il>
---
arch/arm/mach-tegra/pcie.c | 22 ++++++++++++++++++++--
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-tegra/pcie.c b/arch/arm/mach-tegra/pcie.c
index 6de5ef4..2941212 100644
--- a/arch/arm/mach-tegra/pcie.c
+++ b/arch/arm/mach-tegra/pcie.c
@@ -39,6 +39,7 @@
#include <mach/pinmux.h>
#include <mach/iomap.h>
#include <mach/clk.h>
+#include <mach/powergate.h>
/* register definitions */
#define AFI_OFFSET 0x3800
@@ -688,13 +689,30 @@ static void tegra_pcie_power_off(void)
tegra_periph_reset_assert(tegra_pcie.afi_clk);
tegra_periph_reset_assert(tegra_pcie.pex_clk);
+ tegra_powergate_power_off(TEGRA_POWERGATE_PCIE);
tegra_pcie_xclk_clamp(true);
}
-static int tegra_pcie_power_on(void)
+static int tegra_pcie_power_regate(void)
{
+ int err;
+
+ tegra_pcie_power_off();
+
tegra_pcie_xclk_clamp(true);
+
tegra_periph_reset_assert(tegra_pcie.pcie_xclk);
+ tegra_periph_reset_assert(tegra_pcie.afi_clk);
+
+ err = tegra_powergate_sequence_power_up(TEGRA_POWERGATE_PCIE,
+ tegra_pcie.pex_clk);
+ if (err) {
+ pr_err("PCIE: powerup sequence failed: %d\n", err);
+ return err;
+ }
+
+ tegra_periph_reset_deassert(tegra_pcie.afi_clk);
+
tegra_pcie_xclk_clamp(false);
clk_enable(tegra_pcie.afi_clk);
@@ -759,7 +777,7 @@ static int __init tegra_pcie_get_resources(void)
return err;
}
- err = tegra_pcie_power_on();
+ err = tegra_pcie_power_regate();
if (err) {
pr_err("PCIE: failed to power up: %d\n", err);
goto err_pwr_on;
--
1.7.3.1
^ permalink raw reply related
* [PATCH 1/3] ARM: tegra: PCIE minor code refactoring
From: Mike Rapoport @ 2011-03-02 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1299068166.git.mike@compulab.co.il>
Move tegra_pcie_power_off before tegra_pcie_power_on for clean addition
of PCIE power gating
Signed-off-by: Mike Rapoport <mike@compulab.co.il>
---
arch/arm/mach-tegra/pcie.c | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-tegra/pcie.c b/arch/arm/mach-tegra/pcie.c
index 53f5fa3..6de5ef4 100644
--- a/arch/arm/mach-tegra/pcie.c
+++ b/arch/arm/mach-tegra/pcie.c
@@ -682,6 +682,15 @@ static void tegra_pcie_xclk_clamp(bool clamp)
pmc_writel(reg, PMC_SCRATCH42);
}
+static void tegra_pcie_power_off(void)
+{
+ tegra_periph_reset_assert(tegra_pcie.pcie_xclk);
+ tegra_periph_reset_assert(tegra_pcie.afi_clk);
+ tegra_periph_reset_assert(tegra_pcie.pex_clk);
+
+ tegra_pcie_xclk_clamp(true);
+}
+
static int tegra_pcie_power_on(void)
{
tegra_pcie_xclk_clamp(true);
@@ -693,15 +702,6 @@ static int tegra_pcie_power_on(void)
return clk_enable(tegra_pcie.pll_e);
}
-static void tegra_pcie_power_off(void)
-{
- tegra_periph_reset_assert(tegra_pcie.pcie_xclk);
- tegra_periph_reset_assert(tegra_pcie.afi_clk);
- tegra_periph_reset_assert(tegra_pcie.pex_clk);
-
- tegra_pcie_xclk_clamp(true);
-}
-
static int tegra_pcie_clocks_get(void)
{
int err;
--
1.7.3.1
^ permalink raw reply related
* [PATCH 0/3] ARM: tegra: PCI-e improvements
From: Mike Rapoport @ 2011-03-02 12:34 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
This patches add PCI-e powergating support and fix for TrimSlice PCI-e initialization in the mutliplatform kernels.
The patches are also available at git repository
git://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux-tegra.git trimslice/upstream
The following changes since commit ccac05152e7c6a8103b9e7a801bc995180a800fc:
ARM: Tegra: DMA: Fail safe if initialization fails (2011-02-23 14:06:03 -0800)
Mike Rapoport (3):
ARM: tegra: PCIE minor code refactoring
ARM: tegra: add PCI Express power gating
ARM: tegra: trimslice: initialize PCI-e only when running on
TrimSlice
arch/arm/mach-tegra/board-trimslice.c | 3 ++
arch/arm/mach-tegra/pcie.c | 38 ++++++++++++++++++++++++--------
2 files changed, 31 insertions(+), 10 deletions(-)
--
1.7.3.1
^ permalink raw reply
* [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
From: Maxime Coquelin @ 2011-03-02 12:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110302113823.GB2728@pulham.picochip.com>
On 03/02/2011 12:38 PM, Jamie Iles wrote:
> On Wed, Mar 02, 2011 at 11:36:38AM +0100, Linus Walleij wrote:
>> On Wed, Mar 2, 2011 at 9:23 AM, Maxime Coquelin
>> <maxime.coquelin-nonst@stericsson.com> wrote:
>>
>>> I think we should have a tree like this :
>>>
>>> /sys/devices/system/soc/
>>> /sys/devices/system/soc/unique_id<- Unified way to export an ID for all machs
>> Arbitrary number of bits? Some will have a 64-bit ID, some will have 32-bit
>> etc.
>>
>> Should we say it's a hex string of 64 bits?
> Could we provide hooks for the platform that takes the buffer and length
> and let the platform do the snprintf()? Our devices have a 128-bit
> serial number and I'm sure there must be others.
This is one possibility, another one is to let the platform specify how
it exports this serial, as you proposed bellow.
>>> /sys/devices/system/soc/mach/
>>> /sys/devices/system/soc/mach/name<- Name of the mach
>>> /sys/devices/system/soc/mach/foo_id
>>> /sys/devices/system/soc/mach/bar_id<- Vendors may have several/different IDs
>>> to export (IDCODE for OMAP, Production ID...)
> Do we need a way to allow platforms to specify additional attributes to
> co into the socinfo? For our devices we can boot in different modes and
> how we boot determines how the firmware is upgraded. In the case above
> the platform could specify that it needs foo_id and bar_id and the
> callbacks to fill them in.
Yes it was what I thought with the foo and bar IDs exports.
Maxime
^ permalink raw reply
* [patch v2 2/3] arm: pmu: allow platform specifc irq enable/disable handling
From: Will Deacon @ 2011-03-02 12:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299063420-22203-3-git-send-email-tom.leiming@gmail.com>
Hello,
> -----Original Message-----
> From: tom.leiming at gmail.com [mailto:tom.leiming at gmail.com]
> Sent: 02 March 2011 10:57
> To: linux at arm.linux.org.uk
> Cc: linux-arm-kernel at lists.infradead.org; Will Deacon; Ming Lei
> Subject: [patch v2 2/3] arm: pmu: allow platform specifc irq enable/disable handling
>
> From: Ming Lei <tom.leiming@gmail.com>
>
> This patch introduces .enable_irq and .disable_irq into
> struct arm_pmu_platdata, so platform specific irq enablement
> can be handled after request_irq, and platform specific irq
> disablement can be handled before free_irq.
>
> This patch is for support of pmu irq routed from CTI on omap4.
>
> Signed-off-by: Ming Lei <tom.leiming@gmail.com>
> ---
> arch/arm/include/asm/pmu.h | 15 ++++++++++++---
> arch/arm/kernel/perf_event.c | 15 ++++++++++++---
> 2 files changed, 24 insertions(+), 6 deletions(-)
[...]
Looks good to me. Unfortunately, I don't have an OMAP4 to test this
on (contributions welcome :) so I've just eyeballed the code:
Reviewed-by: Will Deacon <will.deacon@arm.com>
You'll need to wait for the ux500 stuff to be merged before you can
get this upstream (Linus W is handling the pull request afaik).
Will
^ permalink raw reply
* [PATCH] ARM: mxs/mx28evk: add flexcan devices
From: Sascha Hauer @ 2011-03-02 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110302114549.GC21601@S2100-06.ap.freescale.net>
On Wed, Mar 02, 2011 at 07:45:50PM +0800, Shawn Guo wrote:
> On Wed, Mar 02, 2011 at 12:11:48PM +0100, Sascha Hauer wrote:
> > Hi Shawn,
> >
> Hi Sascha,
>
> > On Wed, Mar 02, 2011 at 06:54:44PM +0800, Shawn Guo wrote:
> > > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> > > ---
> > > arch/arm/mach-mxs/Kconfig | 1 +
> > > arch/arm/mach-mxs/mach-mx28evk.c | 37 +++++++++++++++++++++++++++++++++++++
> > > 2 files changed, 38 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-mxs/Kconfig b/arch/arm/mach-mxs/Kconfig
> > > index 55bf075..9a1f2cb 100644
> > > --- a/arch/arm/mach-mxs/Kconfig
> > > +++ b/arch/arm/mach-mxs/Kconfig
> > > @@ -31,6 +31,7 @@ config MACH_MX28EVK
> > > select MXS_HAVE_AMBA_DUART
> > > select MXS_HAVE_PLATFORM_AUART
> > > select MXS_HAVE_PLATFORM_FEC
> > > + select MXS_HAVE_PLATFORM_FLEXCAN
> > > select MXS_OCOTP
> > > default y
> > > help
> > > diff --git a/arch/arm/mach-mxs/mach-mx28evk.c b/arch/arm/mach-mxs/mach-mx28evk.c
> > > index 1f0b708..3cefb73 100644
> > > --- a/arch/arm/mach-mxs/mach-mx28evk.c
> > > +++ b/arch/arm/mach-mxs/mach-mx28evk.c
> > > @@ -28,6 +28,7 @@
> > > #include "devices-mx28.h"
> > > #include "gpio.h"
> > >
> > > +#define MX28EVK_FLEXCAN_SWITCH MXS_GPIO_NR(2, 13)
> > > #define MX28EVK_FEC_PHY_POWER MXS_GPIO_NR(2, 15)
> > > #define MX28EVK_FEC_PHY_RESET MXS_GPIO_NR(4, 13)
> > >
> > > @@ -95,6 +96,15 @@ static const iomux_cfg_t mx28evk_pads[] __initconst = {
> > > /* phy reset line */
> > > MX28_PAD_ENET0_RX_CLK__GPIO_4_13 |
> > > (MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
> > > +
> > > + /* flexcan0 */
> > > + MX28_PAD_GPMI_RDY2__CAN0_TX,
> > > + MX28_PAD_GPMI_RDY3__CAN0_RX,
> > > + /* flexcan1 */
> > > + MX28_PAD_GPMI_CE2N__CAN1_TX,
> > > + MX28_PAD_GPMI_CE3N__CAN1_RX,
> > > + /* transceiver power control */
> > > + MX28_PAD_SSP1_CMD__GPIO_2_13,
> > > };
> > >
> > > /* fec */
> > > @@ -178,8 +188,28 @@ error:
> > > return -ETIMEDOUT;
> > > }
> > >
> > > +/* flexcan */
> > > +static void mx28evk_flexcan_switch(int enable)
> > > +{
> > > + static int count;
> > > +
> > > + if (enable) {
> > > + if (!count++)
> > > + gpio_set_value(MX28EVK_FLEXCAN_SWITCH, 1);
> > > + } else {
> > > + if (!--count)
> > > + gpio_set_value(MX28EVK_FLEXCAN_SWITCH, 0);
> > > + }
> > > +}
> >
> > Why this count variable? It shouldn't hurt to call gpio_set_value
> > multiple times.
> >
> This gpio controls the power of both flexcan0 and flexcan1
> transceivers, and we do not want one power-off really shut the power
> down if the other is still on.
Ok, I see. You should add a comment making this clear. Or maybe even
better, add a switch function for each controller and do the actual
switching based on "both off" instead of a counter. This even will
work when the flexcan driver has unbalanced switch calls.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH] omap:iommu-added cache flushing operation for L2 cache
From: David Cohen @ 2011-03-02 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1299008793-27428-1-git-send-email-fernando.lugo@ti.com>
Hi,
On Tue, Mar 1, 2011 at 9:46 PM, Fernando Guzman Lugo
<fernando.lugo@ti.com> wrote:
> From: Ramesh Gupta <grgupta@ti.com>
No patch body description at all?
Can we get at least something here?
Regards,
David
>
> Signed-off-by: Ramesh Gupta <grgupta@ti.com>
> Signed-off-by: Hari Kanigeri <h-kanigeri2@ti.com>
> ---
> ?arch/arm/plat-omap/iommu.c | ? 22 ++++++++--------------
> ?1 files changed, 8 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
> index e3eb038..aeb2c33 100644
> --- a/arch/arm/plat-omap/iommu.c
> +++ b/arch/arm/plat-omap/iommu.c
> @@ -471,22 +471,15 @@ EXPORT_SYMBOL_GPL(foreach_iommu_device);
> ?*/
> ?static void flush_iopgd_range(u32 *first, u32 *last)
> ?{
> - ? ? ? /* FIXME: L2 cache should be taken care of if it exists */
> - ? ? ? do {
> - ? ? ? ? ? ? ? asm("mcr ? ? ? ?p15, 0, %0, c7, c10, 1 @ flush_pgd"
> - ? ? ? ? ? ? ? ? ? : : "r" (first));
> - ? ? ? ? ? ? ? first += L1_CACHE_BYTES / sizeof(*first);
> - ? ? ? } while (first <= last);
> + ? ? ? dmac_flush_range(first, last);
> + ? ? ? outer_flush_range(virt_to_phys(first), virt_to_phys(last));
> ?}
>
> +
> ?static void flush_iopte_range(u32 *first, u32 *last)
> ?{
> - ? ? ? /* FIXME: L2 cache should be taken care of if it exists */
> - ? ? ? do {
> - ? ? ? ? ? ? ? asm("mcr ? ? ? ?p15, 0, %0, c7, c10, 1 @ flush_pte"
> - ? ? ? ? ? ? ? ? ? : : "r" (first));
> - ? ? ? ? ? ? ? first += L1_CACHE_BYTES / sizeof(*first);
> - ? ? ? } while (first <= last);
> + ? ? ? dmac_flush_range(first, last);
> + ? ? ? outer_flush_range(virt_to_phys(first), virt_to_phys(last));
> ?}
>
> ?static void iopte_free(u32 *iopte)
> @@ -750,7 +743,7 @@ size_t iopgtable_clear_entry(struct iommu *obj, u32 da)
> ?}
> ?EXPORT_SYMBOL_GPL(iopgtable_clear_entry);
>
> -static void iopgtable_clear_entry_all(struct iommu *obj)
> +void iopgtable_clear_entry_all(struct iommu *obj)
> ?{
> ? ? ? ?int i;
>
> @@ -777,7 +770,7 @@ static void iopgtable_clear_entry_all(struct iommu *obj)
>
> ? ? ? ?spin_unlock(&obj->page_table_lock);
> ?}
> -
> +EXPORT_SYMBOL_GPL(iopgtable_clear_entry_all);
> ?/*
> ?* ? ? Device IOMMU generic operations
> ?*/
> @@ -1068,6 +1061,7 @@ static void iopte_cachep_ctor(void *iopte)
> ? ? ? ?clean_dcache_area(iopte, IOPTE_TABLE_SIZE);
> ?}
>
> +
> ?static int __init omap_iommu_init(void)
> ?{
> ? ? ? ?struct kmem_cache *p;
> --
> 1.7.0.4
>
> --
> 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
* [PATCH] ARM: mxs/mx28evk: add flexcan devices
From: Shawn Guo @ 2011-03-02 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110302111148.GV29521@pengutronix.de>
On Wed, Mar 02, 2011 at 12:11:48PM +0100, Sascha Hauer wrote:
> Hi Shawn,
>
Hi Sascha,
> On Wed, Mar 02, 2011 at 06:54:44PM +0800, Shawn Guo wrote:
> > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> > ---
> > arch/arm/mach-mxs/Kconfig | 1 +
> > arch/arm/mach-mxs/mach-mx28evk.c | 37 +++++++++++++++++++++++++++++++++++++
> > 2 files changed, 38 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-mxs/Kconfig b/arch/arm/mach-mxs/Kconfig
> > index 55bf075..9a1f2cb 100644
> > --- a/arch/arm/mach-mxs/Kconfig
> > +++ b/arch/arm/mach-mxs/Kconfig
> > @@ -31,6 +31,7 @@ config MACH_MX28EVK
> > select MXS_HAVE_AMBA_DUART
> > select MXS_HAVE_PLATFORM_AUART
> > select MXS_HAVE_PLATFORM_FEC
> > + select MXS_HAVE_PLATFORM_FLEXCAN
> > select MXS_OCOTP
> > default y
> > help
> > diff --git a/arch/arm/mach-mxs/mach-mx28evk.c b/arch/arm/mach-mxs/mach-mx28evk.c
> > index 1f0b708..3cefb73 100644
> > --- a/arch/arm/mach-mxs/mach-mx28evk.c
> > +++ b/arch/arm/mach-mxs/mach-mx28evk.c
> > @@ -28,6 +28,7 @@
> > #include "devices-mx28.h"
> > #include "gpio.h"
> >
> > +#define MX28EVK_FLEXCAN_SWITCH MXS_GPIO_NR(2, 13)
> > #define MX28EVK_FEC_PHY_POWER MXS_GPIO_NR(2, 15)
> > #define MX28EVK_FEC_PHY_RESET MXS_GPIO_NR(4, 13)
> >
> > @@ -95,6 +96,15 @@ static const iomux_cfg_t mx28evk_pads[] __initconst = {
> > /* phy reset line */
> > MX28_PAD_ENET0_RX_CLK__GPIO_4_13 |
> > (MXS_PAD_4MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
> > +
> > + /* flexcan0 */
> > + MX28_PAD_GPMI_RDY2__CAN0_TX,
> > + MX28_PAD_GPMI_RDY3__CAN0_RX,
> > + /* flexcan1 */
> > + MX28_PAD_GPMI_CE2N__CAN1_TX,
> > + MX28_PAD_GPMI_CE3N__CAN1_RX,
> > + /* transceiver power control */
> > + MX28_PAD_SSP1_CMD__GPIO_2_13,
> > };
> >
> > /* fec */
> > @@ -178,8 +188,28 @@ error:
> > return -ETIMEDOUT;
> > }
> >
> > +/* flexcan */
> > +static void mx28evk_flexcan_switch(int enable)
> > +{
> > + static int count;
> > +
> > + if (enable) {
> > + if (!count++)
> > + gpio_set_value(MX28EVK_FLEXCAN_SWITCH, 1);
> > + } else {
> > + if (!--count)
> > + gpio_set_value(MX28EVK_FLEXCAN_SWITCH, 0);
> > + }
> > +}
>
> Why this count variable? It shouldn't hurt to call gpio_set_value
> multiple times.
>
This gpio controls the power of both flexcan0 and flexcan1
transceivers, and we do not want one power-off really shut the power
down if the other is still on.
--
Regards,
Shawn
^ 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