* [PATCH v3] mmc: mxs-mmc: add mmc host driver for i.MX23/28
From: Arnd Bergmann @ 2011-02-22 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110222103349.GA2755@pengutronix.de>
On Tuesday 22 February 2011, Wolfram Sang wrote:
> # mount -t vfat /dev/mmcblk0p1 /mnt
> # dd if=/mnt/test.dat of=/tmp/a bs=1024
> # umount /mnt
> # ./dd --version
> dd (coreutils) 8.5
In general, you should try to rule out file system, garbage collection,
partitioning and cache effects.
With coreutils dd, a good command is
dd if=/dev/zero of=/dev/mmcblk0 bs=64K count=64 seek=256 oflag=direct
* Always write multiples of 4 MB to avoid garbage collection
* smaller block sizes may be faster, so writing 64 times 64K may
be better than writing 4 MB once, depending on the card
* don't write to the FAT area, so start writing at 16 MB into the
device.
* use direct I/O to bypass the page cache.
* read from /dev/zero instead of a disk file to avoid measuring the
wrong thing
Arnd
^ permalink raw reply
* [PATCH v2 01/13] mfd: pruss mfd driver.
From: Wolfgang Grandegger @ 2011-02-22 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <C73EA0C998A34C709A8130A50A1C443F@subhasishg>
On 02/22/2011 01:49 PM, Subhasish Ghosh wrote:
> I am not sure if I understood you correctly, but the current sizeof the
> structure da8xx_prusscore_regs is 0x500.
>
> Here is a link to the PRUSS memory map:
> http://processors.wiki.ti.com/index.php/PRUSS_Memory_Map
>
> The offset 0x00007000 is the PRU0 reg offset and 0x00007800 is the PRU1
> reg offset.
> We cannot have a register file larger than this, but lot of space is
> left out, possibly for future development.
What do you mean with "larger than this"? You ioremap the whole space
and unsued space could be filled with padding bytes:
struct pruss_regs {
u8 ram0[0x0200];
u8 res0[0x1e00];
u8 ram1[0x0200];
u8 res1[0x1e00];
struct pruss_intc_regs intc;
struct pruss_core_regs core[2];
};
Then:
pruss_dev->regs = ioremap(pruss_dev->res->start,
resource_size(pruss_dev->res));
__raw_writel(DA8XX_PRUCORE_CONTROL_RESETVAL,
&pruss_dev->regs.core[pruss_num].control);
That's simple, transparent and save without magic offset handling.
Wolfgang.
^ permalink raw reply
* [PATCH v2 13/13] tty: pruss SUART driver
From: Arnd Bergmann @ 2011-02-22 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DADE3366197E4479A57F3B967A881C33@subhasishg>
On Tuesday 22 February 2011, Subhasish Ghosh wrote:
> @@ -122,13 +122,10 @@ static void omapl_pru_tx_chars(struct omapl_pru_suart
> *soft_uart, u32 uart_no)
> if (!(suart_get_duplex(soft_uart, uart_no) & ePRU_SUART_HALF_TX))
> return;
>
> - if (down_trylock(&soft_uart->port_sem[uart_no]))
> - return;
> -
> if (uart_circ_empty(xmit) ||
> uart_tx_stopped(&soft_uart->port[uart_no])) {
> pruss_suart_stop_tx(&soft_uart->port[uart_no]);
> - up(&soft_uart->port_sem[uart_no]);
> + soft_uart->tx_empty[uart_no] = true;
> return;
> }
>
> @@ -259,7 +256,6 @@ static irqreturn_t pruss_suart_interrupt(s32 irq, void
> *dev_id)
> pru_intr_clr_isrstatus(dev, uart_num, PRU_TX_INTR);
> pru_softuart_clr_tx_status(dev, &soft_uart->suart_hdl
> [port->line]);
> - up(&soft_uart->port_sem[port->line]);
> omapl_pru_tx_chars(soft_uart, port->line);
> }
> } while (txrx_flag & (PRU_RX_INTR | PRU_TX_INTR));
> @@ -294,7 +290,10 @@ static void pruss_suart_start_tx(struct uart_port
> *port)
>
> suart_intr_setmask(dev, soft_uart->suart_hdl[port->line].uart_num,
> PRU_TX_INTR, CHN_TXRX_IE_MASK_CMPLT);
> - omapl_pru_tx_chars(soft_uart, port->line);
> + if (soft_uart->tx_empty[port->line] == true) {
> + soft_uart->tx_empty[port->line] = false;
> + omapl_pru_tx_chars(soft_uart, port->line);
> + }
> }
This looks racy, and I think you at least need to take the spinlock in
pruss_suart_start_tx(), but I don't fully understand the intention of the
code.
I guess you could also use a bitmask for tx_empty and use test_and_clear_bit()
on that to guarantee atomicity.
Arnd
^ permalink raw reply
* [PATCH v3] mmc: mxs-mmc: add mmc host driver for i.MX23/28
From: Wolfram Sang @ 2011-02-22 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102221715.07480.arnd@arndb.de>
On Tue, Feb 22, 2011 at 05:15:07PM +0100, Arnd Bergmann wrote:
> On Tuesday 22 February 2011, Wolfram Sang wrote:
> > # mount -t vfat /dev/mmcblk0p1 /mnt
> > # dd if=/mnt/test.dat of=/tmp/a bs=1024
> > # umount /mnt
> > # ./dd --version
> > dd (coreutils) 8.5
>
> In general, you should try to rule out file system, garbage collection,
> partitioning and cache effects.
Yes, right, I am aware of that (well, most of it ;)). I simplified my
testcase here, because I was sure by previous tests it was only
dependent on the frequency requested by the card. Remember, I wasn't
after maximum values but chasing a difference in read performance of two
magnitudes.
Thanks,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110222/e97edfa7/attachment.sig>
^ permalink raw reply
* MMC quirks relating to performance/lifetime.
From: Arnd Bergmann @ 2011-02-22 16:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTin0BVMgpjmeg682F7zcJJajRumLYcsgNriBwX2v@mail.gmail.com>
On Tuesday 22 February 2011, Andrei Warkentin wrote:
> On Sun, Feb 20, 2011 at 9:03 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > From your flashbench -a run, I would guess that it uses
> > 8 MB allocation units, although the data is not 100% conclusive
> > there.
> >
>
> Because the 8MB aligned write time is significantly faster, right?
I mean because a read spanning an 8 MB boundary is noticably
slower than one spanning a 4 MB boundary (diff 242?s instead of 187?s),
while everything below the numbers for the 4 and 2 MB boundaries
are quite similar.
> I am attaching some graphs. The 16k sandisk shows the slow and fast
> page parallel lines, as does the 8k toshiba (but we knew it for the
> toshiba case), but the boundaries are strange for the sandisk case,
> and there an interesting 2mb variation in the toshiba 8k graph. What
> is the correct way to interpret graphs with other block sizes?
Not sure if it's correct, but my interpretation of your output
is this:
In the Toshiba graph, you see parallel lines that show measurements
30?s apart, e.g. 1.06ms and 1.09 ms in the first one. I assume what
you see here are fast and slow pages, respectively. It's a bit hard
to tell in the resolution you have, and it would make sense to zoom
into the picture to see if they are alternating or just random.
The three groups of double lines are probably just some jitter
from the timing of the interrupt controller. If you run with a larger
--count= value, these should become less visible.
The sandisk plot shows some sector ranges taht are slower than others,
I'd assume that those are the ones that have been recently written.
The 16KB page plot has parallel lines (again, I'd have to see a
finer resolution plot to see if they are alternating), which the
32KB page plot does not have. I see this as an indication that the
pages are indeed 16KB, and in the 32KB plot the results are just
averaged out.
Arnd
^ permalink raw reply
* MMC quirks relating to performance/lifetime.
From: Arnd Bergmann @ 2011-02-22 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTikZh10-2_BLqq0DOm67xZCAEsW9FaRw=+sh+GTY@mail.gmail.com>
On Tuesday 22 February 2011, Andrei Warkentin wrote:
> On Sun, Feb 20, 2011 at 9:23 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > The description of the test case is probably suboptimal. What this does
> > is 32 KB accesses, with 32 KB alignment in the pre and post case, but 16 KB
> > alignment in the "on" case. The idea here is that it should never do
> > any access with less than "--blocksize" aligment.
> >
>
> Now I feel slightly confused :(.
>
> -b 16384 implies blocksize = 16384, maxalign is 8mb due to count 32,
>
> ret = time_rw_interval(dev, count, pre, blocksize,
> align - blocksize, maxalign,
> do_write); //
> <----------------- read 16k@align - 16k with 8mb intervals?
> returnif(ret);
>
> ret = time_rw_interval(dev, count, on, blocksize,
> align - blocksize / 2, maxalign,
> do_write); //
> <----------------- read 16k@align - 8k with 8mb intervals?
> returnif(ret);
>
> ret = time_rw_interval(dev, count, post, blocksize,
> align, maxalign, do_write); //
> <-------- read 16k@align with 8mb intervals?
> returnif(ret);
>
> I hope I'm not missing something obvious...
No, you are absolutely right. I think I changed this once and no longer
remembered what the final version did.
Arnd
^ permalink raw reply
* MMC quirks relating to performance/lifetime.
From: Arnd Bergmann @ 2011-02-22 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTi=ZOUrNoT1W1n3d+9KTMewKZ3kxo71AQsas9OpD@mail.gmail.com>
On Tuesday 22 February 2011, Andrei Warkentin wrote:
> On Sun, Feb 20, 2011 at 8:39 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > E.g. the I/O scheduler can also make sure that we always submit all
> > blocks from the start of one erase unit (e.g. 4 MB) to the end, but
> > not try to merge requests across erase unit boundaries. It can
> > also try to group the requests in aligned power-of-two sized chunks
> > rather than merging as many sectors as possible up to the maximum
> > request size, ignoring the alignment.
>
> I agree. These are common things that affect any kind of flash
> storage, and it belongs in the I/O scheduler as simple tuneables. I'll
> see if I can figure my way around that...
>
> What belongs in mmc card driver are tunable workarounds for MMC/SD
> brokeness. For example - needing to use 8K-spitted reliable writes to
> ensure that a 64KB access doesn't wind up in the 4MB buffer B (as to
> improve lifespan of the card.) But you want a waterline above which
> you don't do this anymore, otherwise the overall performance will go
> to 0 - i.e. there is a need to balance between performance and
> reliability, so the range of access size for which the workaround
> works needs to be runtime controlled, as it's potentially different.
> Another example (this one is apparently affecting Sandisk) - do
> special stuff for block erase, since the card violates spec in that
> regard (touch ext_csd instead of argument, I believe). A different
> example might be turning on reliable writes for WRITE_META (or all)
> blocks for a certain partition (but I just made that up... ).
Yes, makes sense.
> You could put the entire MMC block policy interface through an API
> usable by system integrators - i.e. you would really only care for
> tuning the MMC parameters if you're creating a device around an emmc.
>
> Idea (1). One idea is to keep the "policies" from my previous mail.
> Policies are registered through platform-specific code. The policies
> could be then matched for enabling against a specific block device by
> manfid/date/etc at the time of mmc_block_alloc... For removable media
> no one would fiddle with the tunable parameters anyway, unless there
> was some global database of cards and workarounds and a daemon or some
> such to take care of that... Probably don't want to add such baggage
> to the kernel.
>
> Idea (2). There is probably no need to overcomplicate. Just add a
> platform callback (something like int
> (*mmc_platform_block_workaround)(struct request *, struct
> mmc_blk_request *)). This will be usable as-is for R/W accesses, and
> the discard code will need to be slightly modified.
>
> Do you think there is any need for runtime tuning of the MMC
> workarounds (disregarding ones that really belong in the I/O
> scheduler)? Should the workarounds be simply platform callbacks, or
> should they be something heftier ("policies")?
The platform hook seems the wrong place, because you might use
the same chip in multiple platforms, and a single platform might
have a large number of different boards, all of which require
separate workarounds.
A per-card quirk table does not seem so bad, we have that in
other subsystems as well. I wouldn't necessarily make it
a list of possible quirks, but rather a __devinit function that
is called for a new card on insertion, in order to tweak various
parameters.
Arnd
^ permalink raw reply
* [PATCH 4/4] ARM: tegra: Move pinmux init call
From: Stephen Warren @ 2011-02-22 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimcadeAHWuFApw_H+AEs+hgURxCRO2X92M9cehG@mail.gmail.com>
Colin Cross wrote at Monday, February 21, 2011 8:22 PM:
>
> On Sat, Feb 19, 2011 at 7:38 PM, Stephen Warren <swarren@nvidia.com>
> wrote:
> > In order for the clock initialization to pick up the results of the
> > pinmux initialization (which will initialize various parameters of
> > clocks cdev1, cdev2), the pinmux initialization must happen first.
> > Move the pinmux init to achieve this.
>...
> > ?{
> > + ? ? ? harmony_pinmux_init();
> > +
> > ? ? ? ?tegra_common_init();
> >
> > ? ? ? ?tegra_clk_init_from_table(harmony_clk_init_table);
> >
> > - ? ? ? harmony_pinmux_init();
> > -
>
> This isn't going to work any more. In order for the timer to get a
> reference to its clock, clocks have to be up before the system timer
> is initialized, so Russell added an init_early hook for clock
> initialization. init_machine happens much later, so the per-board
> pinmux init will always happen after clock init.
OK. Drop this patch then.
IIRC, this patch was mostly about making the state (e.g. debugfs files) match
between the pinmux and clock drivers. At least initially I'll ignore this now
that I know what's going on with the audio clocks, and just make audio work
with the appropriate pinmux settings as you suggest.
Maybe that approach will obviate the need for my patch that adds set_parent
for cdev[12], if it's done by pinmux settings instead. I'll check and see.
We can think about the underlying synchronization issue between clock/pinmux
later I think.
--
nvpublic
^ permalink raw reply
* [PATCH 2/5] ARM: omap: update GPIO chained IRQ handler to use EOI in parent chip
From: Tony Lindgren @ 2011-02-22 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298302096-21275-3-git-send-email-will.deacon@arm.com>
* Will Deacon <will.deacon@arm.com> [110221 07:28]:
> On OMAP4, gpio_irq_handler can be chained to a physical interrupt using
> the GIC as the primary IRQ chip. Now that the GIC uses the fasteoi flow
> model, the chained handler must invoke ->irq_eoi once handling is
> complete.
>
> This patch adds a conditional call to ->irq_eoi in the GPIO IRQ handler
> for OMAP platforms. For OMAP implementations using other primary
> interrupt controllers, the ->irq_ack call remains and is also made
> conditional on the support offered by the controller.
>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Colin Cross <ccross@google.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH 2/2] DM9000B: Fix PHY power for network down/up
From: David Miller @ 2011-02-22 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D62D323.7010403@henry.nestler.mail.gmail.com>
From: Henry Nestler <henry.nestler@gmail.com>
Date: Mon, 21 Feb 2011 22:03:31 +0100
> On 21.02.2011 12:14, Sergei Shtylyov wrote:
>> On 21-02-2011 0:45, Henry Nestler wrote:
>>
>>> DM9000 revision B needs 1 ms delay after PHY power on (see spec), and PHY
>>> power must on in register
>>
>> Couldn't parse that.
>
> This can read in manual DM900B-12-DS-F02 from September 2 2010, Page 14:
> "If this Register 1FH bit 0 is updated from '1' to '0', the all
> Registers can not be accessed within 1ms."
>
> The example driver code waits 2 ms.
>
>>> diff --git a/drivers/net/dm9000.c b/drivers/net/dm9000.c
>>> index 2d4c4fc..5925569 100644
>>> --- a/drivers/net/dm9000.c
>>> +++ b/drivers/net/dm9000.c
>> [...]
>>> @@ -1194,6 +1191,10 @@ dm9000_open(struct net_device *dev)
>>> if (request_irq(dev->irq, dm9000_interrupt, irqflags, dev->name, dev))
>>> return -EAGAIN;
>>>
>>> + /* GPIO0 on pre-activate PHY, Reg 1F is not set by reset */
>>> + iow(db, DM9000_GPR, 0); /* REG_1F bit0 activate phyxcer */
>>> + udelay(1000); /* delay needs by DM9000B */
>>
>> Why not mdelay(1)?
>
> Because udelay is the base of mdelay.
> See include/linux/delay.h:31
>
> #define mdelay(n) ... udelay((n)*1000)
He is telling you to use mdelay(1) because it's clearer. Please do
so.
^ permalink raw reply
* [patch-v2.6.39 6/7] OMAP4430: hwmod data: Adding USBOTG
From: Paul Walmsley @ 2011-02-22 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D62ECCC.3040208@ti.com>
On Mon, 21 Feb 2011, Cousson, Benoit wrote:
> Meanwhile, the following will just prevent the fmwk to reset and idle the
> timer during hwmod_init.
>
> Regards,
> Benoit
Looks okay to me for the time being.
Acked-by: Paul Walmsley <paul@pwsan.com>
>
>
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -3989,6 +3989,7 @@ static struct omap_hwmod_ocp_if
> *omap44xx_timer1_slaves[] = {
> static struct omap_hwmod omap44xx_timer1_hwmod = {
> .name = "timer1",
> .class = &omap44xx_timer_1ms_hwmod_class,
> + .flags = HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
> .mpu_irqs = omap44xx_timer1_irqs,
> .mpu_irqs_cnt = ARRAY_SIZE(omap44xx_timer1_irqs),
> .main_clk = "timer1_fck",
>
- Paul
^ permalink raw reply
* [PATCH 2/5] ARM: omap: update GPIO chained IRQ handler to use EOI in parent chip
From: Will Deacon @ 2011-02-22 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bb6bff8b082a50e6b739b22bad6ab6ec@mail.gmail.com>
Hi Santosh,
> > > On OMAP4, gpio_irq_handler can be chained to a physical interrupt
> > > using
> > > the GIC as the primary IRQ chip. Now that the GIC uses the fasteoi
> > > flow
> > > model, the chained handler must invoke ->irq_eoi once handling is
> > > complete.
> > >
> > > This patch adds a conditional call to ->irq_eoi in the GPIO IRQ
> > > handler
> > > for OMAP platforms. For OMAP implementations using other primary
> > > interrupt controllers, the ->irq_ack call remains and is also made
> > > conditional on the support offered by the controller.
> > >
> > > Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > > Cc: Colin Cross <ccross@google.com>
> > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > > ---
> > Thanks Will for changes. They look fine.
> > Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> >
> > I will test your series tomorrow on OMAP with some
> > GPIO interrupts.
> >
> Tested your series on OMAP4 SDP, where GPIO is used for
> ethernet interrupts. They seems to work as expected.
> For omap changes,
> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
That's good news, thanks! One down, three to go...
Will
^ permalink raw reply
* [PATCH v3 2/2] ARM: mxs: add dma device
From: Uwe Kleine-König @ 2011-02-22 18:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110222122733.GD19871@S2100-06.ap.freescale.net>
Hi Shawn,
On Tue, Feb 22, 2011 at 08:27:34PM +0800, Shawn Guo wrote:
> > > diff --git a/arch/arm/mach-mxs/devices/platform-dma.c b/arch/arm/mach-mxs/devices/platform-dma.c
> > > new file mode 100644
> > > index 0000000..ee3220e
> > > --- /dev/null
> > > +++ b/arch/arm/mach-mxs/devices/platform-dma.c
> > I'd prefer to have that called platform-mxs-dma.c to match the driver
> > name. (At least that's what you use for the data structs.)
> >
> If you put this comment a little bit earlier on platform-auart.c which
> is the first example that saves the "mxs" from driver name, I would
> have platform-mxs-dma.c and platform-mxs-mmc.c from the start.
I already noticed I missed auart and planned to follow up with a patch.
Sorry if this resulted in an extra iteration for you.
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH 2/5] ARM: omap: update GPIO chained IRQ handler to use EOI in parent chip
From: Will Deacon @ 2011-02-22 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110222181805.GM15225@atomide.com>
> * Will Deacon <will.deacon@arm.com> [110221 07:28]:
> > On OMAP4, gpio_irq_handler can be chained to a physical interrupt using
> > the GIC as the primary IRQ chip. Now that the GIC uses the fasteoi flow
> > model, the chained handler must invoke ->irq_eoi once handling is
> > complete.
> >
> > This patch adds a conditional call to ->irq_eoi in the GPIO IRQ handler
> > for OMAP platforms. For OMAP implementations using other primary
> > interrupt controllers, the ->irq_ack call remains and is also made
> > conditional on the support offered by the controller.
> >
> > Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > Cc: Colin Cross <ccross@google.com>
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
>
> Acked-by: Tony Lindgren <tony@atomide.com>
Thanks Tony, I'll add your ack.
Will
^ permalink raw reply
* [PATCH v3 3/6] ARM: mxs: dynamically allocate mmc device
From: Uwe Kleine-König @ 2011-02-22 18:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110222123940.GF19871@S2100-06.ap.freescale.net>
Hello Shawn,
On Tue, Feb 22, 2011 at 08:39:41PM +0800, Shawn Guo wrote:
> On Tue, Feb 22, 2011 at 09:31:13AM +0100, Uwe Kleine-K?nig wrote:
> > On Mon, Feb 21, 2011 at 06:42:56PM +0800, Shawn Guo wrote:
> > > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> > > ---
> > > arch/arm/mach-mxs/clock-mx23.c | 16 +++++
> > > arch/arm/mach-mxs/clock-mx28.c | 18 +++++
> > > arch/arm/mach-mxs/devices-mx23.h | 4 +
> > > arch/arm/mach-mxs/devices-mx28.h | 4 +
> > > arch/arm/mach-mxs/devices/Kconfig | 3 +
> > > arch/arm/mach-mxs/devices/Makefile | 1 +
> > > arch/arm/mach-mxs/devices/platform-mmc.c | 77 +++++++++++++++++++++++
> > > arch/arm/mach-mxs/include/mach/devices-common.h | 13 ++++
> > > 8 files changed, 136 insertions(+), 0 deletions(-)
> > > create mode 100644 arch/arm/mach-mxs/devices/platform-mmc.c
> > >
> > > diff --git a/arch/arm/mach-mxs/clock-mx23.c b/arch/arm/mach-mxs/clock-mx23.c
> > > index c19b69a..a1ed5f4 100644
> > > --- a/arch/arm/mach-mxs/clock-mx23.c
> > > +++ b/arch/arm/mach-mxs/clock-mx23.c
> > > @@ -445,6 +445,7 @@ static struct clk_lookup lookups[] = {
> > > _REGISTER_CLOCK("rtc", NULL, rtc_clk)
> > > _REGISTER_CLOCK("mxs-dma-apbh", NULL, hbus_clk)
> > > _REGISTER_CLOCK("mxs-dma-apbx", NULL, xbus_clk)
> > > + _REGISTER_CLOCK("mxs-mmc.0", NULL, ssp_clk)
> > > _REGISTER_CLOCK(NULL, "usb", usb_clk)
> > > _REGISTER_CLOCK(NULL, "audio", audio_clk)
> > > _REGISTER_CLOCK(NULL, "pwm", pwm_clk)
> > > @@ -515,6 +516,15 @@ static int clk_misc_init(void)
> > > __raw_writel(BM_CLKCTRL_CPU_INTERRUPT_WAIT,
> > > CLKCTRL_BASE_ADDR + HW_CLKCTRL_CPU_SET);
> > >
> > > + /*
> > > + * 480 MHz seems too high to be ssp clock source directly,
> > > + * so set frac to get a 288 MHz ref_io.
> > > + */
> > > + reg = __raw_readl(CLKCTRL_BASE_ADDR + HW_CLKCTRL_FRAC);
> > > + reg &= ~BM_CLKCTRL_FRAC_IOFRAC;
> > > + reg |= 30 << BP_CLKCTRL_FRAC_IOFRAC;
> > > + __raw_writel(reg, CLKCTRL_BASE_ADDR + HW_CLKCTRL_FRAC);
> > > +
> > > return 0;
> > > }
> > >
> > > @@ -522,6 +532,12 @@ int __init mx23_clocks_init(void)
> > > {
> > > clk_misc_init();
> > >
> > > + /*
> > > + * source ssp clock from ref_io than ref_xtal,
> > > + * as ref_xtal only provides 24 MHz as maximum.
> > > + */
> > > + clk_set_parent(&ssp_clk, &ref_io_clk);
> > > +
> > > clk_enable(&cpu_clk);
> > > clk_enable(&hbus_clk);
> > > clk_enable(&xbus_clk);
> > > diff --git a/arch/arm/mach-mxs/clock-mx28.c b/arch/arm/mach-mxs/clock-mx28.c
> > > index 9f4ee36..aeb7b2c 100644
> > > --- a/arch/arm/mach-mxs/clock-mx28.c
> > > +++ b/arch/arm/mach-mxs/clock-mx28.c
> > > @@ -619,6 +619,8 @@ static struct clk_lookup lookups[] = {
> > > _REGISTER_CLOCK("pll2", NULL, pll2_clk)
> > > _REGISTER_CLOCK("mxs-dma-apbh", NULL, hbus_clk)
> > > _REGISTER_CLOCK("mxs-dma-apbx", NULL, xbus_clk)
> > > + _REGISTER_CLOCK("mxs-mmc.0", NULL, ssp0_clk)
> > > + _REGISTER_CLOCK("mxs-mmc.1", NULL, ssp1_clk)
> > > _REGISTER_CLOCK("flexcan.0", NULL, can0_clk)
> > > _REGISTER_CLOCK("flexcan.1", NULL, can1_clk)
> > > _REGISTER_CLOCK(NULL, "usb0", usb0_clk)
> > > @@ -730,6 +732,15 @@ static int clk_misc_init(void)
> > > reg |= BM_CLKCTRL_ENET_CLK_OUT_EN;
> > > __raw_writel(reg, CLKCTRL_BASE_ADDR + HW_CLKCTRL_ENET);
> > >
> > > + /*
> > > + * 480 MHz seems too high to be ssp clock source directly,
> > > + * so set frac0 to get a 288 MHz ref_io0.
> > > + */
> > > + reg = __raw_readl(CLKCTRL_BASE_ADDR + HW_CLKCTRL_FRAC0);
> > > + reg &= ~BM_CLKCTRL_FRAC0_IO0FRAC;
> > > + reg |= 30 << BP_CLKCTRL_FRAC0_IO0FRAC;
> > > + __raw_writel(reg, CLKCTRL_BASE_ADDR + HW_CLKCTRL_FRAC0);
> > > +
> > > return 0;
> > > }
> > >
> > > @@ -737,6 +748,13 @@ int __init mx28_clocks_init(void)
> > > {
> > > clk_misc_init();
> > >
> > > + /*
> > > + * source ssp clock from ref_io0 than ref_xtal,
> > > + * as ref_xtal only provides 24 MHz as maximum.
> > > + */
> > > + clk_set_parent(&ssp0_clk, &ref_io0_clk);
> > > + clk_set_parent(&ssp1_clk, &ref_io0_clk);
> > > +
> > > clk_enable(&cpu_clk);
> > > clk_enable(&hbus_clk);
> > > clk_enable(&xbus_clk);
> > > diff --git a/arch/arm/mach-mxs/devices-mx23.h b/arch/arm/mach-mxs/devices-mx23.h
> > > index 1256788..4419390 100644
> > > --- a/arch/arm/mach-mxs/devices-mx23.h
> > > +++ b/arch/arm/mach-mxs/devices-mx23.h
> > > @@ -14,3 +14,7 @@
> > > extern const struct amba_device mx23_duart_device __initconst;
> > > #define mx23_add_duart() \
> > > mxs_add_duart(&mx23_duart_device)
> > > +
> > > +extern const struct mxs_mmc_data mx23_mmc_data[] __initconst;
> > > +#define mx23_add_mmc(id, pdata) \
> > > + mxs_add_mmc(&mx23_mmc_data[id], pdata)
> > mxs_mmc please (not sure about mxs_mxs_mmc_data, but it would be
> > consistent). At least mx23_add_mxs_mmc and mxs_add_mxs_mmc.
> >
> > > diff --git a/arch/arm/mach-mxs/devices-mx28.h b/arch/arm/mach-mxs/devices-mx28.h
> > > index 3b18304..540639d 100644
> > > --- a/arch/arm/mach-mxs/devices-mx28.h
> > > +++ b/arch/arm/mach-mxs/devices-mx28.h
> > > @@ -32,3 +32,7 @@ extern const struct mxs_flexcan_data mx28_flexcan_data[] __initconst;
> > > mxs_add_flexcan(&mx28_flexcan_data[id], pdata)
> > > #define mx28_add_flexcan0(pdata) mx28_add_flexcan(0, pdata)
> > > #define mx28_add_flexcan1(pdata) mx28_add_flexcan(1, pdata)
> > > +
> > > +extern const struct mxs_mmc_data mx28_mmc_data[] __initconst;
> > > +#define mx28_add_mmc(id, pdata) \
> > > + mxs_add_mmc(&mx28_mmc_data[id], pdata)
> > This conflicts with my series, but it's trivial enough to let Sascha
> > handle that.
> >
> > > diff --git a/arch/arm/mach-mxs/devices/Kconfig b/arch/arm/mach-mxs/devices/Kconfig
> > > index 6c65b67..49307f8 100644
> > > --- a/arch/arm/mach-mxs/devices/Kconfig
> > > +++ b/arch/arm/mach-mxs/devices/Kconfig
> > > @@ -11,3 +11,6 @@ config MXS_HAVE_PLATFORM_FEC
> > > config MXS_HAVE_PLATFORM_FLEXCAN
> > > select HAVE_CAN_FLEXCAN if CAN
> > > bool
> > > +
> > > +config MXS_HAVE_PLATFORM_MMC
> > > + bool
> > ditto MXS_HAVE_PLATFORM_MXS_MMC
> >
> > > diff --git a/arch/arm/mach-mxs/devices/Makefile b/arch/arm/mach-mxs/devices/Makefile
> > > index ca7acc4..c0dacfd 100644
> > > --- a/arch/arm/mach-mxs/devices/Makefile
> > > +++ b/arch/arm/mach-mxs/devices/Makefile
> > > @@ -3,3 +3,4 @@ obj-$(CONFIG_MXS_HAVE_PLATFORM_AUART) += platform-auart.o
> > > obj-y += platform-dma.o
> > > obj-$(CONFIG_MXS_HAVE_PLATFORM_FEC) += platform-fec.o
> > > obj-$(CONFIG_MXS_HAVE_PLATFORM_FLEXCAN) += platform-flexcan.o
> > > +obj-$(CONFIG_MXS_HAVE_PLATFORM_MMC) += platform-mmc.o
> > > diff --git a/arch/arm/mach-mxs/devices/platform-mmc.c b/arch/arm/mach-mxs/devices/platform-mmc.c
> > > new file mode 100644
> > > index 0000000..868def1
> > > --- /dev/null
> > > +++ b/arch/arm/mach-mxs/devices/platform-mmc.c
> > > @@ -0,0 +1,77 @@
> > > +/*
> > > + * Copyright (C) 2010 Pengutronix
> > > + * Uwe Kleine-Koenig <u.kleine-koenig@pengutronix.de>
> > > + *
> > > + * Copyright 2011 Freescale Semiconductor, Inc. All Rights Reserved.
> > > + *
> > > + * 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.
> > > + */
> > > +
> > > +#include <linux/compiler.h>
> > > +#include <linux/err.h>
> > > +#include <linux/init.h>
> > > +
> > > +#include <mach/mx23.h>
> > > +#include <mach/mx28.h>
> > > +#include <mach/devices-common.h>
> > > +
> > > +#define mxs_mmc_data_entry_single(soc, _id, hwid) \
> > > + { \
> > > + .id = _id, \
> > > + .iobase = soc ## _SSP ## hwid ## _BASE_ADDR, \
> > > + .dma = soc ## _DMA_SSP ## hwid, \
> > > + .irq_err = soc ## _INT_SSP ## hwid ## _ERROR, \
> > > + .irq_dma = soc ## _INT_SSP ## hwid ## _DMA, \
> > > + }
> > > +
> > > +#define mxs_mmc_data_entry(soc, _id, hwid) \
> > > + [_id] = mxs_mmc_data_entry_single(soc, _id, hwid)
> > > +
> > > +
> > > +#ifdef CONFIG_SOC_IMX23
> > > +const struct mxs_mmc_data mx23_mmc_data[] __initconst = {
> > > +#define mx23_mmc_data_entry(_id, hwid) \
> > > + mxs_mmc_data_entry(MX23, _id, hwid)
> > > + mx23_mmc_data_entry(0, 1),
> > > + mx23_mmc_data_entry(1, 2),
> > > +};
> > hmm, maybe let mxs-mmc.1 use MX23_SSP1_BASE_ADDR?
> > BTW, Sascha pointed out that
> >
> > mxs_mmc_data_entry(MX23, 0, 1),
> > mxs_mmc_data_entry(MX23, 1, 2),
> >
> > is easier than
> >
> > #define mx23_mmc_data_entry(_id, hwid) \
> > mxs_mmc_data_entry(MX23, _id, hwid)
> > mx23_mmc_data_entry(0, 1),
> > mx23_mmc_data_entry(1, 2),
> >
> This approach was used in mx23 auart device code which Sascha has
> merged.
Yeah, I don't care that much. Do as you prefer. Sascha told me to
rework the existing code in a free minute to the two-line variant.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] ARM: ptrace: fix register indexing in GETHBPREGS request
From: Will Deacon @ 2011-02-22 18:40 UTC (permalink / raw)
To: linux-arm-kernel
The GETHBPREGS ptrace request incorrectly maps its index argument onto
the thread's saved debug state when the index != 0. This has not yet
been seen from userspace because GDB (the only user of this request)
only reads from register 0.
This patch fixes the indexing.
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/kernel/ptrace.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kernel/ptrace.c b/arch/arm/kernel/ptrace.c
index eace844..2bf27f3 100644
--- a/arch/arm/kernel/ptrace.c
+++ b/arch/arm/kernel/ptrace.c
@@ -615,10 +615,10 @@ static int ptrace_gethbpregs(struct task_struct *tsk, long num,
while (!(arch_ctrl.len & 0x1))
arch_ctrl.len >>= 1;
- if (idx & 0x1)
- reg = encode_ctrl_reg(arch_ctrl);
- else
+ if (num & 0x1)
reg = bp->attr.bp_addr;
+ else
+ reg = encode_ctrl_reg(arch_ctrl);
}
put:
--
1.7.0.4
^ permalink raw reply related
* [PATCH 3/5] ARM: tegra: update GPIO chained IRQ handler to use EOI in parent chip
From: Colin Cross @ 2011-02-22 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298302096-21275-4-git-send-email-will.deacon@arm.com>
On Mon, Feb 21, 2011 at 7:28 AM, Will Deacon <will.deacon@arm.com> wrote:
> The chained GPIO IRQ handler on Tegra calls ->irq_ack on the parent
> chip prior to handling the interrupt.
>
> This patch updates the code to use ->irq_eoi now that the GIC has moved
> to using the fasteoi flow model.
>
> Cc: Colin Cross <ccross@google.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> ?arch/arm/mach-tegra/gpio.c | ? 17 +----------------
> ?1 files changed, 1 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/mach-tegra/gpio.c b/arch/arm/mach-tegra/gpio.c
> index ad80488..5019b01 100644
> --- a/arch/arm/mach-tegra/gpio.c
> +++ b/arch/arm/mach-tegra/gpio.c
> @@ -219,9 +219,6 @@ static void tegra_gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
> ? ? ? ?struct tegra_gpio_bank *bank;
> ? ? ? ?int port;
> ? ? ? ?int pin;
> - ? ? ? int unmasked = 0;
> -
> - ? ? ? desc->irq_data.chip->irq_ack(&desc->irq_data);
>
> ? ? ? ?bank = get_irq_data(irq);
>
> @@ -233,23 +230,11 @@ static void tegra_gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
>
> ? ? ? ? ? ? ? ?for_each_set_bit(pin, &sta, 8) {
> ? ? ? ? ? ? ? ? ? ? ? ?__raw_writel(1 << pin, GPIO_INT_CLR(gpio));
> -
> - ? ? ? ? ? ? ? ? ? ? ? /* if gpio is edge triggered, clear condition
> - ? ? ? ? ? ? ? ? ? ? ? ?* before executing the hander so that we don't
> - ? ? ? ? ? ? ? ? ? ? ? ?* miss edges
> - ? ? ? ? ? ? ? ? ? ? ? ?*/
> - ? ? ? ? ? ? ? ? ? ? ? if (lvl & (0x100 << pin)) {
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? unmasked = 1;
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? desc->irq_data.chip->irq_unmask(&desc->irq_data);
> - ? ? ? ? ? ? ? ? ? ? ? }
> -
> ? ? ? ? ? ? ? ? ? ? ? ?generic_handle_irq(gpio_to_irq(gpio + pin));
> ? ? ? ? ? ? ? ?}
> ? ? ? ?}
>
> - ? ? ? if (!unmasked)
> - ? ? ? ? ? ? ? desc->irq_data.chip->irq_unmask(&desc->irq_data);
> -
> + ? ? ? desc->irq_data.chip->irq_eoi(&desc->irq_data);
> ?}
>
> ?#ifdef CONFIG_PM
> --
> 1.7.0.4
>
>
>
Acked-by: Colin Cross <ccross@android.com>
Works with chained gpio handlers on Tegra, although the patch is
filled with = escaping.
^ permalink raw reply
* [PATCH 0/3] OMAP2+ hwmod fixes
From: Paul Walmsley @ 2011-02-22 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e6550ef1ea27499e3bc093e264c54d0f@mail.gmail.com>
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...
- Paul
^ permalink raw reply
* [PATCH 1/6] ARM: tegra: add tegra_gpio_table and tegra_gpio_config
From: Erik Gilling @ 2011-02-22 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298354117-19097-2-git-send-email-olof@lixom.net>
Can you split the boardfile changes into their own patch? Also see
the below whitespace only change. Other than that, looks good.
On Mon, Feb 21, 2011 at 9:55 PM, Olof Johansson <olof@lixom.net> wrote:
snip
> diff --git a/arch/arm/mach-tegra/gpio.c b/arch/arm/mach-tegra/gpio.c
> index 132dcd6..ffc146d 100644
> --- a/arch/arm/mach-tegra/gpio.c
> +++ b/arch/arm/mach-tegra/gpio.c
> @@ -378,9 +378,22 @@ static int __init tegra_gpio_init(void)
>
> ? ? ? ?return 0;
> ?}
> -
> ?postcore_initcall(tegra_gpio_init);
whitespace only change
>
> +void __init tegra_gpio_config(struct tegra_gpio_table *table, int num)
> +{
> + ? ? ? int i;
> +
> + ? ? ? for (i = 0; i < num; i++) {
> + ? ? ? ? ? ? ? int gpio = table[i].gpio;
> +
> + ? ? ? ? ? ? ? if (table[i].enable)
> + ? ? ? ? ? ? ? ? ? ? ? tegra_gpio_enable(gpio);
> + ? ? ? ? ? ? ? else
> + ? ? ? ? ? ? ? ? ? ? ? tegra_gpio_disable(gpio);
> + ? ? ? }
> +}
> +
> ?#ifdef CONFIG_DEBUG_FS
>
> ?#include <linux/debugfs.h>
> diff --git a/arch/arm/mach-tegra/include/mach/gpio.h b/arch/arm/mach-tegra/include/mach/gpio.h
> index e31f486..2369fba 100644
> --- a/arch/arm/mach-tegra/include/mach/gpio.h
> +++ b/arch/arm/mach-tegra/include/mach/gpio.h
> @@ -20,6 +20,7 @@
> ?#ifndef __MACH_TEGRA_GPIO_H
> ?#define __MACH_TEGRA_GPIO_H
>
> +#include <linux/init.h>
> ?#include <mach/irqs.h>
>
> ?#define TEGRA_NR_GPIOS ? ? ? ? INT_GPIO_NR
> @@ -47,6 +48,12 @@ static inline int irq_to_gpio(unsigned int irq)
> ? ? ? ?return -EINVAL;
> ?}
>
> +struct tegra_gpio_table {
> + ? ? ? int ? ? gpio; ? /* GPIO number */
> + ? ? ? bool ? ?enable; /* Enable for GPIO at init? */
> +};
> +
> +void __init tegra_gpio_config(struct tegra_gpio_table *table, int num);
> ?void tegra_gpio_enable(int gpio);
> ?void tegra_gpio_disable(int gpio);
>
> --
> 1.7.0.4
>
>
^ permalink raw reply
* [PATCH 3/5] ARM: tegra: update GPIO chained IRQ handler to use EOI in parent chip
From: Will Deacon @ 2011-02-22 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimYvHOzv2w_oxOB5HJfMhp8Kg_A0-Y7Mj41M-HX@mail.gmail.com>
Hi Colin,
> On Mon, Feb 21, 2011 at 7:28 AM, Will Deacon <will.deacon@arm.com> wrote:
> > The chained GPIO IRQ handler on Tegra calls ->irq_ack on the parent
> > chip prior to handling the interrupt.
> >
> > This patch updates the code to use ->irq_eoi now that the GIC has moved
> > to using the fasteoi flow model.
> >
> > Cc: Colin Cross <ccross@google.com>
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > ---
> > arch/arm/mach-tegra/gpio.c | 17 +----------------
> > 1 files changed, 1 insertions(+), 16 deletions(-)
[...]
> Acked-by: Colin Cross <ccross@android.com>
Thanks Colin.
> Works with chained gpio handlers on Tegra, although the patch is
> filled with = escaping.
Hmm, I've seen this problem before. See Russell's explanation here:
http://lists.arm.linux.org.uk/lurker/message/20101201.172105.938cf2c5.en.html
I don't believe it's a problem my end, but if it starts happening
regularly I'll investigate further.
Cheers,
Will
^ permalink raw reply
* [PATCH 4/5] arm: mach-mx3: pcm043: add write-protect and card-detect for SD1
From: Fabio Estevam @ 2011-02-22 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298379500-27590-5-git-send-email-w.sang@pengutronix.de>
Hi Wolfram,
On Tue, Feb 22, 2011 at 9:58 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
...
> ?#define AC97_GPIO_TXFS (1 * 32 + 31)
> ?#define AC97_GPIO_TXD ?(1 * 32 + 28)
> ?#define AC97_GPIO_RESET ? ? ? ?(1 * 32 + 0)
>
> +#define SD1_GPIO_WP ? ?(1 * 32 + 23)
> +#define SD1_GPIO_CD ? ?(1 * 32 + 24)
You could also do:
+#define SD1_GPIO_WP IMX_GPIO_NR(2, 23)
+#define SD1_GPIO_CD IMX_GPIO_NR(2, 24)
Regards,
Fabio Estevam
^ permalink raw reply
* [PATCH 1/6] ARM: tegra: add tegra_gpio_table and tegra_gpio_config
From: Olof Johansson @ 2011-02-22 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTik9_t0mq07mysO2CcK4ppKAmuPAujownfeWEGL5@mail.gmail.com>
Hi
On Tue, Feb 22, 2011 at 11:18 AM, Erik Gilling <konkers@android.com> wrote:
> Can you split the boardfile changes into their own patch? ?Also see
> the below whitespace only change. ?Other than that, looks good.
Ok, done (will push separately, no need to repost just with the split though).
Thanks.
>> ?}
>> -
>> ?postcore_initcall(tegra_gpio_init);
>
> whitespace only change
D'oh, sloppy of me. Fixed.
-Olof
^ permalink raw reply
* [PATCH 0/7] Second batch of Tegra clock updates for 2.6.39
From: Colin Cross @ 2011-02-22 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298342392-21236-1-git-send-email-ccross@android.com>
I pushed everything except the last patch that disables bootloader
clocks to for-next. I'll repost the last change with Olof's comments
addressed.
On Mon, Feb 21, 2011 at 6:39 PM, Colin Cross <ccross@android.com> wrote:
> This patch series contains two small patches out of the previous
> series that needed fixes, as well as some new ones to disable
> unused clocks during boot and related bug fixes.
>
> Patch 4 converts the Harmony and Trimslice boards to use the new
> init_early machine handler. ?Any boards that go in after this
> patch will need to be updated to match, and this patch will need
> to be updated if any boards go in before this patch.
>
> Tested-bys on Harmony and Trimslice would be appreciated.
>
>
^ permalink raw reply
* [PATCH 3/6] ARM: tegra: remove stale nvidia atag handler
From: Colin Cross @ 2011-02-22 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298354117-19097-4-git-send-email-olof@lixom.net>
On Mon, Feb 21, 2011 at 9:55 PM, Olof Johansson <olof@lixom.net> wrote:
> Remove dead atag handling code for nvidia-specific tags.
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
> ---
> ?arch/arm/mach-tegra/board-harmony.c | ? 25 -------------------------
> ?1 files changed, 0 insertions(+), 25 deletions(-)
>
> diff --git a/arch/arm/mach-tegra/board-harmony.c b/arch/arm/mach-tegra/board-harmony.c
> index b9dbdb1..f6ad58b 100644
> --- a/arch/arm/mach-tegra/board-harmony.c
> +++ b/arch/arm/mach-tegra/board-harmony.c
> @@ -35,31 +35,6 @@
> ?#include "board-harmony.h"
> ?#include "clock.h"
>
> -/* NVidia bootloader tags */
> -#define ATAG_NVIDIA ? ? ? ? ? ?0x41000801
> -
> -#define ATAG_NVIDIA_RM ? ? ? ? ? ? ? ? 0x1
> -#define ATAG_NVIDIA_DISPLAY ? ? ? ? ? ?0x2
> -#define ATAG_NVIDIA_FRAMEBUFFER ? ? ? ? ? ? ? ?0x3
> -#define ATAG_NVIDIA_CHIPSHMOO ? ? ? ? ?0x4
> -#define ATAG_NVIDIA_CHIPSHMOOPHYS ? ? ?0x5
> -#define ATAG_NVIDIA_PRESERVED_MEM_0 ? ?0x10000
> -#define ATAG_NVIDIA_PRESERVED_MEM_N ? ?2
> -#define ATAG_NVIDIA_FORCE_32 ? ? ? ? ? 0x7fffffff
> -
> -struct tag_tegra {
> - ? ? ? __u32 bootarg_key;
> - ? ? ? __u32 bootarg_len;
> - ? ? ? char bootarg[1];
> -};
> -
> -static int __init parse_tag_nvidia(const struct tag *tag)
> -{
> -
> - ? ? ? return 0;
> -}
> -__tagtable(ATAG_NVIDIA, parse_tag_nvidia);
> -
> ?static struct plat_serial8250_port debug_uart_platform_data[] = {
> ? ? ? ?{
> ? ? ? ? ? ? ? ?.membase ? ? ? ?= IO_ADDRESS(TEGRA_UARTD_BASE),
> --
> 1.7.0.4
>
>
Acked-by: Colin Cross <ccross@android.com>
Our version of the kernel will never use these atags, so it's better
to warn that they are being ignored and get the bootloaders updated.
^ permalink raw reply
* [PATCH 4/6] ARM: tegra: harmony: register sdhci devices
From: Colin Cross @ 2011-02-22 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298354117-19097-5-git-send-email-olof@lixom.net>
On Mon, Feb 21, 2011 at 9:55 PM, Olof Johansson <olof@lixom.net> wrote:
> Add the 3 sdhci devices that are available on Harmony as
> platform devices. Two go to slots (one 4-lane, one 8-lane),
> and one goes to onboard wifi.
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
> ---
> ?arch/arm/mach-tegra/board-harmony.c | ? 30 ++++++++++++++++++++++++++++++
> ?1 files changed, 30 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-tegra/board-harmony.c b/arch/arm/mach-tegra/board-harmony.c
> index f6ad58b..7010774 100644
> --- a/arch/arm/mach-tegra/board-harmony.c
> +++ b/arch/arm/mach-tegra/board-harmony.c
> @@ -30,10 +30,13 @@
>
> ?#include <mach/iomap.h>
> ?#include <mach/irqs.h>
> +#include <mach/sdhci.h>
>
> ?#include "board.h"
> ?#include "board-harmony.h"
> ?#include "clock.h"
> +#include "devices.h"
> +#include "gpio-names.h"
>
> ?static struct plat_serial8250_port debug_uart_platform_data[] = {
> ? ? ? ?{
> @@ -59,6 +62,9 @@ static struct platform_device debug_uart = {
>
> ?static struct platform_device *harmony_devices[] __initdata = {
> ? ? ? ?&debug_uart,
> + ? ? ? &tegra_sdhci_device1,
> + ? ? ? &tegra_sdhci_device2,
> + ? ? ? &tegra_sdhci_device4,
> ?};
>
> ?static void __init tegra_harmony_fixup(struct machine_desc *desc,
> @@ -77,6 +83,26 @@ static __initdata struct tegra_clk_init_table harmony_clk_init_table[] = {
> ? ? ? ?{ NULL, ? ? ? ? NULL, ? ? ? ? ? 0, ? ? ? ? ? ? ?0},
> ?};
>
> +
> +static struct tegra_sdhci_platform_data sdhci_pdata1 = {
> + ? ? ? .cd_gpio ? ? ? ?= -1,
> + ? ? ? .wp_gpio ? ? ? ?= -1,
> + ? ? ? .power_gpio ? ? = -1,
> +};
> +
> +static struct tegra_sdhci_platform_data sdhci_pdata2 = {
> + ? ? ? .cd_gpio ? ? ? ?= TEGRA_GPIO_PI5,
> + ? ? ? .wp_gpio ? ? ? ?= TEGRA_GPIO_PH1,
> + ? ? ? .power_gpio ? ? = TEGRA_GPIO_PT3,
> +};
> +
> +static struct tegra_sdhci_platform_data sdhci_pdata4 = {
> + ? ? ? .cd_gpio ? ? ? ?= TEGRA_GPIO_PH2,
> + ? ? ? .wp_gpio ? ? ? ?= TEGRA_GPIO_PH3,
> + ? ? ? .power_gpio ? ? = TEGRA_GPIO_PI6,
> + ? ? ? .is_8bit ? ? ? ?= 1,
> +};
> +
> ?static void __init tegra_harmony_init(void)
> ?{
> ? ? ? ?tegra_common_init();
> @@ -85,6 +111,10 @@ static void __init tegra_harmony_init(void)
>
> ? ? ? ?harmony_pinmux_init();
>
> + ? ? ? tegra_sdhci_device1.dev.platform_data = &sdhci_pdata1;
> + ? ? ? tegra_sdhci_device2.dev.platform_data = &sdhci_pdata2;
> + ? ? ? tegra_sdhci_device4.dev.platform_data = &sdhci_pdata4;
> +
> ? ? ? ?platform_add_devices(harmony_devices, ARRAY_SIZE(harmony_devices));
> ?}
>
> --
> 1.7.0.4
>
>
Acked-by: Colin Cross <ccross@android.com>
^ 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