* RE: [PATCH 3/5][v2] fsl-rio: Add two ports and rapidio message units support
From: Bounine, Alexandre @ 2011-10-24 13:51 UTC (permalink / raw)
To: Liu Gang-B34182, Kumar Gala, linuxppc-dev, Zang Roy-R61911
Cc: Andrew Morton, linux-kernel
In-Reply-To: <9A1C2A9ACC704641BC472A1588CE164712E48E@039-SN1MPN1-005.039d.mgd.msft.net>
On Sat, Oct 22, 2011 at 1:15 AM, Liu Gang-B34182 <B34182@freescale.com>
wrote:
>
> From: Bounine, Alexandre [mailto:Alexandre.Bounine@idt.com]
> Sent: Thursday, October 20, 2011 3:54 AM
> To: Kumar Gala; linuxppc-dev@ozlabs.org
> Cc: Andrew Morton; Liu Gang-B34182; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH 3/5][v2] fsl-rio: Add two ports and rapidio
message
> units support
>
> On Thu, Oct 13, 2011 at 10:09 AM, Kumar Gala wrote:
> >
> > From: Liu Gang <Gang.Liu@freescale.com>
> >
> > Usually, freescale rapidio endpoint can support one 1X or two 4X LP-
> > Serial link interfaces, and rapidio message transactions can be
> > implemented
> by
> > two
>
> Is the number of 1x ports described correctly?
> Can we have two 1x ports as well?
> [Liu Gang-B34182] Yes you are right. endpoint can also have two 1x
> ports. I'll correct it.
>
> > message units. This patch adds the support of two rapidio ports and
> > initializes message unit 0 and message unit 1. And these ports and
> > message
> ... skip ...
> > +
> > + /* Probe the master port phy type */
> > + ccsr = in_be32(priv->regs_win + RIO_CCSR + i*0x20);
> > + port->phy_type = (ccsr & 1) ? RIO_PHY_SERIAL :
> > RIO_PHY_PARALLEL;
> > + dev_info(&dev->dev, "RapidIO PHY type: %s\n",
> > + (port->phy_type == RIO_PHY_PARALLEL) ?
> > + "parallel" :
> > + ((port->phy_type == RIO_PHY_SERIAL) ?
> "serial"
> > :
> > + "unknown"));
> > + /* Checking the port training status */
> > + if (in_be32((priv->regs_win + RIO_ESCSR + i*0x20)) & 1)
> {
> > + dev_err(&dev->dev, "Port %d is not ready. "
> > + "Try to restart connection...\n", i);
> > + switch (port->phy_type) {
> > + case RIO_PHY_SERIAL:
> > + /* Disable ports */
> > + out_be32(priv->regs_win
> > + + RIO_CCSR + i*0x20, 0);
> > + /* Set 1x lane */
> > + setbits32(priv->regs_win
> > + + RIO_CCSR + i*0x20,
> 0x02000000);
> > + /* Enable ports */
> > + setbits32(priv->regs_win
> > + + RIO_CCSR + i*0x20,
> 0x00600000);
> > + break;
> > + case RIO_PHY_PARALLEL:
> > + /* Disable ports */
> > + out_be32(priv->regs_win
> > + + RIO_CCSR + i*0x20,
> 0x22000000);
> > + /* Enable ports */
> > + out_be32(priv->regs_win
> > + + RIO_CCSR + i*0x20,
> 0x44000000);
> > + break;
> > + }
>
> Probably this may be a good moment to drop the support for parallel
> link.
> Especially after you renamed controller to "srio" in the device tree.
> [Liu Gang-B34182] I'm also considering if we should drop the parallel
> link support and doorbell outbound ATMU configuration.
> I found some older powerpc chips support parallel link, like mpc8540
> and so on. But DTS files of these chips do not support
> Rapidio nodes. For example we can't find rapidio node in
> arch/powerpc/boot/dts/mpc8540ads.dts file. So can we conclude that
> these chips with parallel rapidio link do not need the support for
> rapidio module and the code for parallel link can be removed?
We are not aware about any use of tsi500 P-RIO switches.
I would consider parallel implementation as an early stage
of RapidIO development which may be safely dropped.
I will keep P-RIO related definitions only because they are part of
the spec. I consider removing tsi500 switch driver as well.
>
> > + msleep(100);
... skip ...
>
> >
> > @@ -340,35 +327,45 @@ fsl_rio_dbell_handler(int irq, void
> > *dev_instance)
> > " sid %2.2x tid %2.2x info %4.4x\n",
> > DBELL_SID(dmsg), DBELL_TID(dmsg),
> DBELL_INF(dmsg));
> >
> > - list_for_each_entry(dbell, &port->dbells, node) {
> > - if ((dbell->res->start <= DBELL_INF(dmsg)) &&
> > - (dbell->res->end >= DBELL_INF(dmsg))) {
> > - found = 1;
> > - break;
> > + for (i = 0; i < MAX_PORT_NUM; i++) {
> > + if (fsl_dbell->mport[i]) {
> > + list_for_each_entry(dbell,
> > + &fsl_dbell->mport[i]->dbells,
> node) {
> > + if ((dbell->res->start
> > + <= DBELL_INF(dmsg))
> > + && (dbell->res->end
> > + >= DBELL_INF(dmsg))) {
> > + found = 1;
> > + break;
> > + }
> > + }
> > + if (found && dbell->dinb) {
> > + dbell->dinb(fsl_dbell->mport[i],
> > + dbell->dev_id,
> DBELL_SID(dmsg),
> > + DBELL_TID(dmsg),
> > + DBELL_INF(dmsg));
> > + break;
> > + }
> > }
> > }
>
> Do we need to check for matching DBELL_TID and mport destID here and
> scan only doorbell list attached to the right port? Otherwise this may
> call service routine associated with doorbell on a wrong port.
> [Liu Gang-B34182] Do you mean to match DBELL_TID and mport DevID?
Yes.
> Usually this is a reliable method, but for the rapidio module of
> powerpc, will encounter some problem. We set the port's DevID by
> the register "Base Device ID CSR" defined in Rapidio Specification.
The
> rapidio module of powerpc can support two ports but have only one the
> Base Device ID CSR. So these two ports will have the same
> DevID. Although there are two registers "Alternate Device ID CSR" to
> separate deviceIDs for each port, they are specific registers of the
> freescale rapidio and can't be accessed by getting the extended
feature
> space block offset. For this doobell issue, in order to call a right
> service routine, perhaps we should ensure that different ports in
> different "res->start and res->end" configurations.
This gives us an issue that has to be solved at some point.
Splitting doorbell resources may be a way in this case but should be
considered in context of RIO network with different endpoints and
therefore
it will be some device-specific quirk.
Probably the best approach in this case is to keep doorbell handler as
it is now (for purpose of this patchset) and address doorbell resource
assignment during enumeration/discovery. At least this has to be well
commented.
>
> > - if (found) {
> > - dbell->dinb(port, dbell->dev_id,
> > - DBELL_SID(dmsg),
> > - DBELL_TID(dmsg),
> DBELL_INF(dmsg));
> > - } else {
> > +
> > + if (!found) {
> > pr_debug
> > ("RIO: spurious doorbell,"
> > " sid %2.2x tid %2.2x info %4.4x\n",
> > DBELL_SID(dmsg), DBELL_TID(dmsg),
> > DBELL_INF(dmsg));
> > }
> > - setbits32(&rmu->msg_regs->dmr, DOORBELL_DMR_DI);
> > - out_be32(&rmu->msg_regs->dsr, DOORBELL_DSR_DIQI);
> > + setbits32(&fsl_dbell->dbell_regs->dmr, DOORBELL_DMR_DI);
> > + out_be32(&fsl_dbell->dbell_regs->dsr,
> DOORBELL_DSR_DIQI);
> > }
> >
> > out:
> > return IRQ_HANDLED;
> > }
> >
... skip ...
Regards,
Alex.
^ permalink raw reply
* Re: [PATCH 1/2] Bluetooth: Return proper error codes on rfcomm tty init
From: Anderson Briglia @ 2011-10-24 13:57 UTC (permalink / raw)
To: David Herrmann; +Cc: linux-bluetooth, padovan
In-Reply-To: <1319463058-29311-1-git-send-email-dh.herrmann@googlemail.com>
Hi David,
On Mon, Oct 24, 2011 at 3:30 PM, David Herrmann
<dh.herrmann@googlemail.com> wrote:
> Forward error codes from tty core to the rfcomm_init caller instead of using
> generic -1 errors.
>
> Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
> ---
> net/bluetooth/rfcomm/tty.c | 9 ++++++---
> 1 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/net/bluetooth/rfcomm/tty.c b/net/bluetooth/rfcomm/tty.c
> index c258796..2b753a3 100644
> --- a/net/bluetooth/rfcomm/tty.c
> +++ b/net/bluetooth/rfcomm/tty.c
> @@ -1155,9 +1155,11 @@ static const struct tty_operations rfcomm_ops = {
>
> int __init rfcomm_init_ttys(void)
> {
> + int error;
> +
> rfcomm_tty_driver = alloc_tty_driver(RFCOMM_TTY_PORTS);
> if (!rfcomm_tty_driver)
> - return -1;
> + return -ENOMEM;
>
> rfcomm_tty_driver->owner = THIS_MODULE;
> rfcomm_tty_driver->driver_name = "rfcomm";
> @@ -1172,10 +1174,11 @@ int __init rfcomm_init_ttys(void)
> rfcomm_tty_driver->init_termios.c_lflag &= ~ICANON;
> tty_set_operations(rfcomm_tty_driver, &rfcomm_ops);
>
> - if (tty_register_driver(rfcomm_tty_driver)) {
> + error = tty_register_driver(rfcomm_tty_driver);
> + if (error) {
> BT_ERR("Can't register RFCOMM TTY driver");
> put_tty_driver(rfcomm_tty_driver);
> - return -1;
> + return error;
Since you are defining a new variable (error), how about use it on
other error paths and add a "goto out" and have just one return path?
Regards,
Anderson Briglia
> }
>
> BT_INFO("RFCOMM TTY layer initialized");
> --
> 1.7.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
INdT - Instituto Nokia de tecnologia
+55 92 2126 1122
+55 92 8423 3183
^ permalink raw reply
* Perf support for OMAP4
From: Ming Lei @ 2011-10-24 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024133230.GA4449@mudshark.cambridge.arm.com>
On Mon, Oct 24, 2011 at 9:32 PM, Will Deacon <will.deacon@arm.com> wrote:
> Hello,
>
> On Thu, Sep 29, 2011 at 08:20:53AM +0100, Ming Lei wrote:
>> On Wed, Sep 28, 2011 at 11:54 PM, Will Deacon <will.deacon@arm.com> wrote:
>> > Hi Tom,
>> >
>> > I can't see your OMAP4 Perf/PMU patches from here:
>> >
>> > http://lists.infradead.org/pipermail/linux-arm-kernel/2011-March/045283.html
>> >
>> > in mainline or next.
>> >
>> > Are you still pushing these or did you get blocked awaiting feedback?
>>
>> OK, I will rebase the patch against -next tree and resend it later.
>
> Ping? I'd really like to get this tested and queued for 3.3 as it's
> currently blocking hardware perf-events on Pandaboard.
Sorry for the delay, I will send out the patch set later today.
thanks,
--
Ming Lei
^ permalink raw reply
* Re: [PATCH] bnx2x: Adding FW 7.0.29.0
From: Dmitry Kravkov @ 2011-10-24 13:57 UTC (permalink / raw)
To: dwmw2@infradead.org
Cc: ben@decadent.org.uk, netdev@vger.kernel.org, Eilon Greenstein
In-Reply-To: <1318867968.5817.1.camel@lb-tlvb-dmitry>
On Mon, 2011-10-17 at 09:12 -0700, Dmitry Kravkov wrote:
> On Mon, 2011-10-17 at 07:00 -0700, Dmitry Kravkov wrote:
> > Includes fixes for the following issues:
> > 1. (iSCSI) Arrival of un-solicited ASYNC message causes
> > firmware to abort the connection with RST.
> > 2. (FCoE) There is a probability that truncated FCoE packet on
> > RX path won't get detected which might lead to FW assert.
> > 3. (iSCSI) Arrival of target-initiated NOP-IN during intense
> > ISCSI traffic might lead to FW assert.
> > 4. (iSCSI) Chip hangs when in case of retransmission not aligned
> > to 4-bytes from the beginning of iSCSI PDU.
> > 5. (FCoE) Arrival of packets beyond task IO size can lead to crash.
> >
David, do you have estimation to handle the request? We have pending
patch for net-next. Thanks.
^ permalink raw reply
* Re: Xen two tree at kernel.org
From: Stephen Rothwell @ 2011-10-24 13:57 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: linux-kernel
In-Reply-To: <20111024130930.GB19142@phenom.dumpdata.com>
[-- Attachment #1: Type: text/plain, Size: 392 bytes --]
Hi Konrad,
On Mon, 24 Oct 2011 09:09:30 -0400 Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>
> Could you move the #xen-two link to point at
>
> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git #linux-next
>
> please?
I have switched to that now.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [U-Boot] [PATCH] Update s3c24x0 timer implementation
From: Marek Vasut @ 2011-10-24 13:58 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAJtrzLNz3TBBRHoNtHkuGci4YJZ9PLrJfvGaR_XdVbrdcprxbQ@mail.gmail.com>
> Dear Wolfgang Denk,
>
> Thank you for your response.
>
> >> Since the .rel.text section is required by the relocation code, I
> >> assume that .bss global variables cannot be used until after
> >> relocation?
> >
> > Why do you have to make such assumptions? That's documented
> > behaviour. Didn't you RTFM?
>
> I thought I had done a thorough search previously but after receiving
> your response I managed to find some of the details outlined in the
> README file.
>
> I have attached an updated patch below which hopefully addresses the
> other issues you highlighted.
Hehe, you should RTFM ;-) http://www.denx.de/wiki/U-Boot/Patches
Generally, use git send-email to send the patch.
>
> Kind Regards,
>
> Mark Norman
>
>
>
> The s3c24x0 timer has been updated to use the global_data struct.
> Restructured code based on other timer.c files.
> Updated comments and several parameters.
>
> Signed-off-by: Mark Norman <mpnorman@gmail.com>
> ---
> arch/arm/cpu/arm920t/s3c24x0/timer.c | 155
> +++++++++++++-------------------- arch/arm/include/asm/global_data.h |
> 4 +
> 2 files changed, 65 insertions(+), 94 deletions(-)
>
> diff --git a/arch/arm/cpu/arm920t/s3c24x0/timer.c
> b/arch/arm/cpu/arm920t/s3c24x0/timer.c
> index 9571870..5695c62 100644
> --- a/arch/arm/cpu/arm920t/s3c24x0/timer.c
> +++ b/arch/arm/cpu/arm920t/s3c24x0/timer.c
> @@ -35,142 +35,109 @@
> #include <asm/io.h>
> #include <asm/arch/s3c24x0_cpu.h>
>
> -int timer_load_val = 0;
> -static ulong timer_clk;
> +DECLARE_GLOBAL_DATA_PTR;
>
> -/* macro to read the 16 bit timer */
> -static inline ulong READ_TIMER(void)
> +/* Read the 16 bit timer */
> +static inline ulong read_timer(void)
> {
> struct s3c24x0_timers *timers = s3c24x0_get_base_timers();
>
> return readl(&timers->tcnto4) & 0xffff;
> }
>
> -static ulong timestamp;
> -static ulong lastdec;
> -
> int timer_init(void)
> {
> + /*
> + * PWM Timer 4 is used because it has no output.
> + * Prescaler is hard fixed at 250, divider at 2.
> + * This generates a Timer clock frequency of 100kHz (@PCLK=50MHz) and
> + * therefore 10us timer ticks.
> + */
> + const ulong prescaler = 250;
> struct s3c24x0_timers *timers = s3c24x0_get_base_timers();
> ulong tmr;
>
> - /* use PWM Timer 4 because it has no output */
> - /* prescaler for Timer 4 is 16 */
> - writel(0x0f00, &timers->tcfg0);
> - if (timer_load_val == 0) {
> - /*
> - * for 10 ms clock period @ PCLK with 4 bit divider = 1/2
> - * (default) and prescaler = 16. Should be 10390
> - * @33.25MHz and 15625 @ 50 MHz
> - */
> - timer_load_val = get_PCLK() / (2 * 16 * 100);
> - timer_clk = get_PCLK() / (2 * 16);
> - }
> - /* load value for 10 ms timeout */
> - lastdec = timer_load_val;
> - writel(timer_load_val, &timers->tcntb4);
> - /* auto load, manual update of timer 4 */
> + /* Set prescaler for Timer 4 */
> + writel((prescaler-1) << 8, &timers->tcfg0);
Can we get rid of the magic numbers please?
> +
> + /* Calculate timer freq, approx 100kHz @ PCLK=50MHz. */
> + gd->timer_rate_hz = get_PCLK() / (2 * prescaler);
Can get_PCLK() be renamed to be lower-case only?
> +
> + /* Set timer for 0.5s timeout (50000 ticks @ 10us ticks). */
> + gd->timer_reset_value = 50000;
> + writel(gd->timer_reset_value, &timers->tcntb4);
> + gd->lastdec = gd->timer_reset_value;
> +
> + /* Load the initial timer 4 count value using the manual update bit. */
> tmr = (readl(&timers->tcon) & ~0x0700000) | 0x0600000;
Magic values :-(
> writel(tmr, &timers->tcon);
> - /* auto load, start timer 4 */
> +
> + /* Configure timer 4 for auto reload and start it. */
> tmr = (tmr & ~0x0700000) | 0x0500000;
> writel(tmr, &timers->tcon);
> - timestamp = 0;
> +
> + gd->timestamp = 0;
>
> return (0);
return 0;
if you're cleaning this crap up, do it all at once ;-)
> }
>
> /*
> - * timer without interrupts
> + * Get the number of ticks (in CONFIG_SYS_HZ resolution)
> */
> -ulong get_timer(ulong base)
> +unsigned long long get_ticks(void)
> {
> - return get_timer_masked() - base;
> + return get_timer(0);
> }
>
> -void __udelay (unsigned long usec)
> +unsigned long get_timer_raw(void)
> {
> - ulong tmo;
> - ulong start = get_ticks();
> + ulong now = read_timer();
>
> - tmo = usec / 1000;
> - tmo *= (timer_load_val * 100);
> - tmo /= 1000;
> + if (gd->lastdec >= now) {
> + /* normal mode */
> + gd->timestamp += gd->lastdec - now;
> + } else {
> + /* we have an overflow ... */
> + gd->timestamp += gd->lastdec + gd->timer_reset_value - now;
> + }
> + gd->lastdec = now;
>
> - while ((ulong) (get_ticks() - start) < tmo)
> - /*NOP*/;
> + return gd->timestamp;
> }
>
> -ulong get_timer_masked(void)
> +/*
> + * This function is derived from PowerPC code (timebase clock frequency).
> + * On ARM it returns the number of timer ticks per second.
> + */
> +ulong get_tbclk(void)
> {
> - ulong tmr = get_ticks();
> -
> - return tmr / (timer_clk / CONFIG_SYS_HZ);
> + return CONFIG_SYS_HZ;
> }
>
> -void udelay_masked(unsigned long usec)
> +ulong get_timer_masked(void)
> {
> - ulong tmo;
> - ulong endtime;
> - signed long diff;
> -
> - if (usec >= 1000) {
> - tmo = usec / 1000;
> - tmo *= (timer_load_val * 100);
> - tmo /= 1000;
> - } else {
> - tmo = usec * (timer_load_val * 100);
> - tmo /= (1000 * 1000);
> - }
> + unsigned long tmr = get_timer_raw();
>
> - endtime = get_ticks() + tmo;
> + return (tmr * CONFIG_SYS_HZ) / gd->timer_rate_hz;
> +}
>
> - do {
> - ulong now = get_ticks();
> - diff = endtime - now;
> - } while (diff >= 0);
> +ulong get_timer(ulong base)
> +{
> + return get_timer_masked() - base;
> }
>
> -/*
> - * This function is derived from PowerPC code (read timebase as long
> long). - * On ARM it just returns the timer value.
> - */
> -unsigned long long get_ticks(void)
> +void __udelay(unsigned long usec)
> {
> - ulong now = READ_TIMER();
> + unsigned long tmp;
> + unsigned long tmo;
>
> - if (lastdec >= now) {
> - /* normal mode */
> - timestamp += lastdec - now;
> - } else {
> - /* we have an overflow ... */
> - timestamp += lastdec + timer_load_val - now;
> - }
> - lastdec = now;
> + /* convert usec to ticks. */
> + tmo = ((gd->timer_rate_hz / 1000) * usec) / 1000;
>
> - return timestamp;
> -}
> + tmp = get_timer_raw() + tmo; /* get current timestamp */
>
> -/*
> - * This function is derived from PowerPC code (timebase clock frequency).
> - * On ARM it returns the number of timer ticks per second.
> - */
> -ulong get_tbclk(void)
> -{
> - ulong tbclk;
> -
> -#if defined(CONFIG_SMDK2400)
> - tbclk = timer_load_val * 100;
> -#elif defined(CONFIG_SBC2410X) || \
> - defined(CONFIG_SMDK2410) || \
> - defined(CONFIG_S3C2440) || \
> - defined(CONFIG_VCMA9)
> - tbclk = CONFIG_SYS_HZ;
> -#else
> -# error "tbclk not configured"
> -#endif
> -
> - return tbclk;
> + while (get_timer_raw() < tmp) /* loop till event */
> + /*NOP*/;
> }
>
> /*
> diff --git a/arch/arm/include/asm/global_data.h
> b/arch/arm/include/asm/global_data.h
> index fac98d5..b836915 100644
> --- a/arch/arm/include/asm/global_data.h
> +++ b/arch/arm/include/asm/global_data.h
> @@ -67,6 +67,10 @@ typedef struct global_data {
> #ifdef CONFIG_IXP425
> unsigned long timestamp;
> #endif
> +#ifdef CONFIG_S3C24X0
> + unsigned long lastdec;
> + unsigned long timestamp;
> +#endif
I wonder about this change ...
> unsigned long relocaddr; /* Start address of U-Boot in RAM */
> phys_size_t ram_size; /* RAM size */
> unsigned long mon_len; /* monitor len */
Cheers
^ permalink raw reply
* [Buildroot] Call For Participation: buildroot + crosstool-NG Developpers' Day
From: Mike Frysinger @ 2011-10-24 13:59 UTC (permalink / raw)
To: buildroot
In-Reply-To: <201108151803.02636.yann.morin.1998@anciens.enib.fr>
i'm leaving sat morn, but i'd like to meet up with you guys at some
point if only to say "hi" :)
-mike
^ permalink raw reply
* RE: how stable are snapshots at the block level?
From: Edward Ned Harvey @ 2011-10-24 13:59 UTC (permalink / raw)
To: 'Mathijs Kwik'; +Cc: linux-btrfs
In-Reply-To: <CAKvOHKCjxxKTahivOuRBPBB89JBrTwndQ6cCEuFaPbJr8PYtpA@mail.gmail.com>
> From: Mathijs Kwik [mailto:mathijs@bluescreen303.nl]
> Sent: Sunday, October 23, 2011 11:20 AM
>
> > Also if you're rsyncing the block level device, you're running underneath
> btrfs and losing any checksumming benefit that btrfs was giving you, so
> you're possibly introducing risk for silent data corruption. (Or more
> accurately, failing to allow btrfs to detect/correct it.)
>
> Not sure... I'm sure that's the case for in-use subvolumes, but
> shouldn't snapshots (and their metadata/checksums) just be safe?
Nope. The whole point of checksumming is like this: All devices are imperfect. They have built-in error detection and correction. Whenever an error occurs (which is often) the drive tries to silently correct it (reread) without telling the OS. But the checksumming in hardware is rather weak. Sometimes you'll get corrupt data that passes the hardware test and reaches the OS without any clue that it's wrong. I find that a typical small business fileserver (10 sata disks) hits these approx once a year.
Filesystem checksumming is much stronger (lower probability to silently allow an error). Like randomly selecting a single molecule twice consecutively amongst all the molecules in the solar system. Like much less likely to occur than the end of the human race, etc. So when the silent errors occur, filesystem checksumming definitely detects it, and if possible, corrects it.
If you are reading the raw device underneath btrfs, you are not getting the benefit of the filesystem checksumming. If you encounter an undetected read/write error, it will silently pass. Your data will be corrupted, you'll never know about it until you see the side-effects (whatever they may be).
While people with computers have accepted this level of unreliability for years (fat32, ntfs, ext3/4, etc) people are now beginning to recognize the importance on a greater scale. Once corrupted, always corrupted. People want to keep their data indefinitely.
> Thanks for your advice,
> Like I said, for me, right now, sticking to tried-and-tested
> file-based rsync is just ok. But I hope to get some insights into
> other possibilities. btrfs send sounds cool, but I sure hope this is
> not the only solution, as I described a few scenarios where
> block-level copies have advantages.
There is never a situation where block level copies have any advantage over something like btrfs send. Except perhaps forensics or espionage. But in terms of fast efficient reliable backups, btrfs send has every advantage and no disadvantage compared to block level copy.
There are many situations where btrfs send has an advantage over both block level and file level copies. It instantly knows all the relevant disk blocks to send, it preserves every property, it's agnostic about filesystem size or layout on either sending or receiving end, you have the option to create different configurations on each side, including compression etc. And so on.
^ permalink raw reply
* [U-Boot] [PATCH] image: Allow images to indicate they're loadable at any address
From: Stephen Warren @ 2011-10-24 13:59 UTC (permalink / raw)
To: u-boot
The legacy uImage format includes an absolute load and entry-
point address. When presented with a uImage in memory that
isn't loaded at the address in the image's load address,
U-Boot will relocate the image to its address in the header.
Some payloads can actually be loaded and used at any arbitrary
address. An example is an ARM Linux kernel zImage file. This
is useful when sharing a single zImage across multiple boards
with different memory layouts, or U-Boot builds with different
${load_addr} since sharing a single absolute load address may
not be possible.
With this config option enabled, an image header may contain a
load address of -1/0xffffffff. This indicates the image can
operate at any load address, and U-Boot will avoid automtically
copying it anywhere. In this case, the entry-point field is
specified relative to the start of the image payload.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
Wolfgang,
This is an much simpler and less invasive alternative to my previous
IH_TYPE_KERNEL_REL patch. If it's OK, you can ignore that patch.
u-boot.bin sizes for Tegra Seaboard without/with this config option on:
text data bss dec hex filename
165858 3565 217016 386439 5e587 ./u-boot
with:
text data bss dec hex filename
165950 3565 217012 386527 5e5df ./u-boot
README | 23 +++++++++++++++++++++++
common/cmd_bootm.c | 4 ++++
common/image.c | 27 +++++++++++++++++++++++++++
include/image.h | 4 ++++
4 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/README b/README
index eb9ade9..480cfe3 100644
--- a/README
+++ b/README
@@ -3177,6 +3177,29 @@ Low Level (hardware related) configuration options:
be used if available. These functions may be faster under some
conditions but may increase the binary size.
+Image-related options:
+---------------------------------------------------
+
+- CONFIG_SYS_RELOCATABLE_IMAGES
+
+ The legacy uImage format includes an absolute load and entry-
+ point address. When presented with a uImage in memory that
+ isn't loaded at the address in the image's load address,
+ U-Boot will relocate the image to its address in the header.
+
+ Some payloads can actually be loaded and used at any arbitrary
+ address. An example is an ARM Linux kernel zImage file. This
+ is useful when sharing a single zImage across multiple boards
+ with different memory layouts, or U-Boot builds with different
+ ${load_addr} since sharing a single absolute load address may
+ not be possible.
+
+ With this config option enabled, an image header may contain a
+ load address of -1/0xffffffff. This indicates the image can
+ operate at any load address, and U-Boot will avoid automtically
+ copying it anywhere. In this case, the entry-point field is
+ specified relative to the start of the image payload.
+
Building the Software:
======================
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index bb9b698..de08bbc 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -730,6 +730,10 @@ static image_header_t *image_get_kernel (ulong img_addr, int verify)
return NULL;
}
+#ifdef CONFIG_SYS_RELOCATABLE_IMAGES
+ image_fixup_load_entry(hdr);
+#endif
+
show_boot_progress (3);
image_print_contents (hdr);
diff --git a/common/image.c b/common/image.c
index 32ad4da..a746c6f 100644
--- a/common/image.c
+++ b/common/image.c
@@ -342,6 +342,25 @@ void image_print_contents (const void *ptr)
}
}
+#ifdef CONFIG_SYS_RELOCATABLE_IMAGES
+void image_fixup_load_entry(image_header_t *hdr)
+{
+ ulong load;
+ ulong hsize;
+ ulong ep;
+
+ load = image_get_load(hdr);
+ if (load != -1)
+ return;
+
+ load = (ulong)hdr;
+ hsize = image_get_header_size();
+ ep = load + hsize + image_get_ep(hdr);
+
+ image_set_load(hdr, load);
+ image_set_ep(hdr, ep);
+}
+#endif
#ifndef USE_HOSTCC
/**
@@ -379,6 +398,10 @@ static const image_header_t *image_get_ramdisk (ulong rd_addr, uint8_t arch,
return NULL;
}
+#ifdef CONFIG_SYS_RELOCATABLE_IMAGES
+ image_fixup_load_entry((image_header_t *)rd_hdr);
+#endif
+
show_boot_progress (10);
image_print_contents (rd_hdr);
@@ -1116,6 +1139,10 @@ static const image_header_t *image_get_fdt (ulong fdt_addr)
}
puts ("OK\n");
+#ifdef CONFIG_SYS_RELOCATABLE_IMAGES
+ image_fixup_load_entry((image_header_t *)fdt_hdr);
+#endif
+
if (!image_check_type (fdt_hdr, IH_TYPE_FLATDT)) {
fdt_error ("uImage is not a fdt");
return NULL;
diff --git a/include/image.h b/include/image.h
index b7caaa6..c680f1f 100644
--- a/include/image.h
+++ b/include/image.h
@@ -332,6 +332,10 @@ int genimg_get_format (void *img_addr);
int genimg_has_config (bootm_headers_t *images);
ulong genimg_get_image (ulong img_addr);
+#ifdef CONFIG_SYS_RELOCATABLE_IMAGES
+void image_fixup_load_entry(image_header_t *hdr);
+#endif
+
int boot_get_ramdisk (int argc, char * const argv[], bootm_headers_t *images,
uint8_t arch, ulong *rd_start, ulong *rd_end);
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Grant Likely @ 2011-10-24 13:59 UTC (permalink / raw)
To: Shawn Guo
Cc: Rajendra Nayak, patches, tony, devicetree-discuss, Mark Brown,
linux-kernel, linux-omap, lrg, linux-arm-kernel
In-Reply-To: <20111024134025.GE1755@S2100-06.ap.freescale.net>
On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
> On Mon, Oct 24, 2011 at 03:06:37PM +0200, Mark Brown wrote:
> > On Mon, Oct 24, 2011 at 09:04:31PM +0800, Shawn Guo wrote:
> >
> > > If we can attach the device_node of 'regulators' node to dev->of_node
> > > when calling regulator_register(regulator_desc, dev, ...) from
> > > regulator driver, the regulator core will be able to find all nodes under
> > > 'regulators' using for_each_child_of_node(dev->of_node, child).
> >
> > Please provide concrete examples of the bindings you're talking about,
> > the really important thing here is how sane the bindings look and I've
> > really got no idea what any of what you're talking about will look like
> > or if they make sense.
> >
> The only thing different from what I attached last time is the
> compatible string added to 'regulators' node.
>
> ecspi@70010000 { /* ECSPI1 */
> fsl,spi-num-chipselects = <2>;
> cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */
> <&gpio3 25 0>; /* GPIO4_25 */
> status = "okay";
>
> pmic: mc13892@0 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "fsl,mc13892";
> spi-max-frequency = <6000000>;
> reg = <0>;
> mc13xxx-irq-gpios = <&gpio0 8 0>; /* GPIO1_8 */
>
> regulators {
> compatible = "fsl,mc13892-regulator";
>
> sw1reg: mc13892_sw1 {
> regulator-min-uV = <600000>;
> regulator-max-uV = <1375000>;
> regulator-change-voltage;
> regulator-boot-on;
> regulator-always-on;
> };
>
> sw2reg: mc13892_sw2 {
> regulator-min-uV = <900000>;
> regulator-max-uV = <1850000>;
> regulator-change-voltage;
> regulator-boot-on;
> regulator-always-on;
> };
>
> ......
> };
>
> leds {
> ......
> };
>
> buttons {
> ......
> };
> };
>
> flash: at45db321d@1 {
> ......
> };
> };
>
> > > hesitate to hack this into mfd_add_devices(), so I would like to add
> > > compatible string "fsl,mc13892-regulators" to node 'regulators' and
> > > find the node using of_find_compatible_node(dev->parent, NULL,
> > > "fsl,mc13892-regulators").
> >
> > It's not immediately obvious to me that having a binding for the
> > regulators separately makes sense, it's not a usefully distinct device.
> >
> Fair point. Actually, I also hate to have the finding of node
> 'regulators' plugged into regulator driver. What about following
> change to address Grant's concern on global device tree search?
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index 8fe132d..29dcf90 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
>
> /* find device_node and attach it */
> - rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
> + rdev->dev.of_node = of_find_node_by_name(dev->parent->of_node,
> + regulator_desc->name);
of_find_node_by_name() doesn't work that way. The first argument is a
starting point, but it doesn't restrict the search to children of a
node.
for_each_child_of_node() is what you want to use when iterating over
the children which unfortunately changes the structure of this
function.
g.
^ permalink raw reply
* [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Grant Likely @ 2011-10-24 13:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024134025.GE1755@S2100-06.ap.freescale.net>
On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
> On Mon, Oct 24, 2011 at 03:06:37PM +0200, Mark Brown wrote:
> > On Mon, Oct 24, 2011 at 09:04:31PM +0800, Shawn Guo wrote:
> >
> > > If we can attach the device_node of 'regulators' node to dev->of_node
> > > when calling regulator_register(regulator_desc, dev, ...) from
> > > regulator driver, the regulator core will be able to find all nodes under
> > > 'regulators' using for_each_child_of_node(dev->of_node, child).
> >
> > Please provide concrete examples of the bindings you're talking about,
> > the really important thing here is how sane the bindings look and I've
> > really got no idea what any of what you're talking about will look like
> > or if they make sense.
> >
> The only thing different from what I attached last time is the
> compatible string added to 'regulators' node.
>
> ecspi at 70010000 { /* ECSPI1 */
> fsl,spi-num-chipselects = <2>;
> cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */
> <&gpio3 25 0>; /* GPIO4_25 */
> status = "okay";
>
> pmic: mc13892 at 0 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "fsl,mc13892";
> spi-max-frequency = <6000000>;
> reg = <0>;
> mc13xxx-irq-gpios = <&gpio0 8 0>; /* GPIO1_8 */
>
> regulators {
> compatible = "fsl,mc13892-regulator";
>
> sw1reg: mc13892_sw1 {
> regulator-min-uV = <600000>;
> regulator-max-uV = <1375000>;
> regulator-change-voltage;
> regulator-boot-on;
> regulator-always-on;
> };
>
> sw2reg: mc13892_sw2 {
> regulator-min-uV = <900000>;
> regulator-max-uV = <1850000>;
> regulator-change-voltage;
> regulator-boot-on;
> regulator-always-on;
> };
>
> ......
> };
>
> leds {
> ......
> };
>
> buttons {
> ......
> };
> };
>
> flash: at45db321d at 1 {
> ......
> };
> };
>
> > > hesitate to hack this into mfd_add_devices(), so I would like to add
> > > compatible string "fsl,mc13892-regulators" to node 'regulators' and
> > > find the node using of_find_compatible_node(dev->parent, NULL,
> > > "fsl,mc13892-regulators").
> >
> > It's not immediately obvious to me that having a binding for the
> > regulators separately makes sense, it's not a usefully distinct device.
> >
> Fair point. Actually, I also hate to have the finding of node
> 'regulators' plugged into regulator driver. What about following
> change to address Grant's concern on global device tree search?
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index 8fe132d..29dcf90 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
>
> /* find device_node and attach it */
> - rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
> + rdev->dev.of_node = of_find_node_by_name(dev->parent->of_node,
> + regulator_desc->name);
of_find_node_by_name() doesn't work that way. The first argument is a
starting point, but it doesn't restrict the search to children of a
node.
for_each_child_of_node() is what you want to use when iterating over
the children which unfortunately changes the structure of this
function.
g.
^ permalink raw reply
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Grant Likely @ 2011-10-24 13:59 UTC (permalink / raw)
To: Shawn Guo
Cc: Mark Brown, Rajendra Nayak, patches, tony, devicetree-discuss,
linux-kernel, linux-omap, lrg, linux-arm-kernel
In-Reply-To: <20111024134025.GE1755@S2100-06.ap.freescale.net>
On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
> On Mon, Oct 24, 2011 at 03:06:37PM +0200, Mark Brown wrote:
> > On Mon, Oct 24, 2011 at 09:04:31PM +0800, Shawn Guo wrote:
> >
> > > If we can attach the device_node of 'regulators' node to dev->of_node
> > > when calling regulator_register(regulator_desc, dev, ...) from
> > > regulator driver, the regulator core will be able to find all nodes under
> > > 'regulators' using for_each_child_of_node(dev->of_node, child).
> >
> > Please provide concrete examples of the bindings you're talking about,
> > the really important thing here is how sane the bindings look and I've
> > really got no idea what any of what you're talking about will look like
> > or if they make sense.
> >
> The only thing different from what I attached last time is the
> compatible string added to 'regulators' node.
>
> ecspi@70010000 { /* ECSPI1 */
> fsl,spi-num-chipselects = <2>;
> cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */
> <&gpio3 25 0>; /* GPIO4_25 */
> status = "okay";
>
> pmic: mc13892@0 {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "fsl,mc13892";
> spi-max-frequency = <6000000>;
> reg = <0>;
> mc13xxx-irq-gpios = <&gpio0 8 0>; /* GPIO1_8 */
>
> regulators {
> compatible = "fsl,mc13892-regulator";
>
> sw1reg: mc13892_sw1 {
> regulator-min-uV = <600000>;
> regulator-max-uV = <1375000>;
> regulator-change-voltage;
> regulator-boot-on;
> regulator-always-on;
> };
>
> sw2reg: mc13892_sw2 {
> regulator-min-uV = <900000>;
> regulator-max-uV = <1850000>;
> regulator-change-voltage;
> regulator-boot-on;
> regulator-always-on;
> };
>
> ......
> };
>
> leds {
> ......
> };
>
> buttons {
> ......
> };
> };
>
> flash: at45db321d@1 {
> ......
> };
> };
>
> > > hesitate to hack this into mfd_add_devices(), so I would like to add
> > > compatible string "fsl,mc13892-regulators" to node 'regulators' and
> > > find the node using of_find_compatible_node(dev->parent, NULL,
> > > "fsl,mc13892-regulators").
> >
> > It's not immediately obvious to me that having a binding for the
> > regulators separately makes sense, it's not a usefully distinct device.
> >
> Fair point. Actually, I also hate to have the finding of node
> 'regulators' plugged into regulator driver. What about following
> change to address Grant's concern on global device tree search?
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index 8fe132d..29dcf90 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
>
> /* find device_node and attach it */
> - rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
> + rdev->dev.of_node = of_find_node_by_name(dev->parent->of_node,
> + regulator_desc->name);
of_find_node_by_name() doesn't work that way. The first argument is a
starting point, but it doesn't restrict the search to children of a
node.
for_each_child_of_node() is what you want to use when iterating over
the children which unfortunately changes the structure of this
function.
g.
^ permalink raw reply
* Re: [PATCH] module,bug: Add TAINT_OOT_MODULE flag for modules not built in-tree
From: Dave Jones @ 2011-10-24 13:58 UTC (permalink / raw)
To: Ben Hutchings; +Cc: LKML, Greg KH, Debian kernel maintainers, Rusty Russell
In-Reply-To: <1319461948.31243.31.camel@deadeye>
On Mon, Oct 24, 2011 at 03:12:28PM +0200, Ben Hutchings wrote:
> Use of the GPL or a compatible licence doesn't necessarily make the code
> any good. We already consider staging modules to be suspect, and this
> should also be true for out-of-tree modules which may receive very
> little review.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> ---
> Debian has been carrying this for the last few kernel versions. The
> recent thread '[RFC] virtualbox tainting.' and discussions at KS suggest
> that this might be more generally useful.
Looks good to me.
Reviewed-by: Dave Jones <davej@redhat.com>
^ permalink raw reply
* [xen-unstable bisection] complete test-i386-i386-pair
From: xen.org @ 2011-10-24 14:00 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson, keir, stefano.stabellini
branch xen-unstable
xen branch xen-unstable
job test-i386-i386-pair
test leak-check/check/src_host
Tree: linux git://github.com/jsgf/linux-xen.git
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
*** Found and reproduced problem changeset ***
Bug is in tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Bug introduced: 1c8789852eaf
Bug not present: 8269826353d8
changeset: 23990:1c8789852eaf
user: Jan Beulich <jbeulich@suse.com>
date: Fri Oct 21 09:44:47 2011 +0200
x86/hpet: allocate CPU masks dynamically
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
For bisection revision-tuple graph see:
http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-i386-i386-pair.leak-check--check--src_host.html
Revision IDs in each graph node refer, respectively, to the Trees above.
----------------------------------------
Searching for failure / basis pass:
9471 fail [dst_host=field-cricket,src_host=bush-cricket] / 9355 ok.
Failure / basis pass flights: 9471 / 9355
Tree: linux git://github.com/jsgf/linux-xen.git
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 a7ccbc79fc17
Basis pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 6c583d35d76d
Generating revisions with ./adhoc-revtuple-generator git://github.com/jsgf/linux-xen.git#6bec8b4a4c14095d0b7ce424db9d583c3decae6c-6bec8b4a4c14095d0b7ce424db9d583c3decae6c git://hg.uk.xensource.com/HG/qemu-xen-unstable.git#25378e0a76b282127e9ab8933a4defbc91db3862-25378e0a76b282127e9ab8933a4defbc91db3862 http://xenbits.xen.org/staging/xen-unstable.hg#6c583d35d76d-a7ccbc79fc17
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 74 nodes in revision graph
Searching for test results:
9355 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 6c583d35d76d
9363 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 a7ccbc79fc17
9390 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 6c583d35d76d
9391 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 a7ccbc79fc17
9392 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 253073b522f8
9471 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 a7ccbc79fc17
9472 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 53528bab2eb4
9554 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 8269826353d8
9587 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 1c8789852eaf
9588 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 8269826353d8
9589 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 1c8789852eaf
9590 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 8269826353d8
9591 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 1c8789852eaf
Searching for interesting versions
Result found: flight 9355 (pass), for basis pass
Result found: flight 9363 (fail), for basis failure
Repro found: flight 9390 (pass), for basis pass
Repro found: flight 9391 (fail), for basis failure
0 revisions at 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 8269826353d8
No revisions left to test, checking graph state.
Result found: flight 9554 (pass), for last pass
Result found: flight 9587 (fail), for first failure
Repro found: flight 9588 (pass), for last pass
Repro found: flight 9589 (fail), for first failure
Repro found: flight 9590 (pass), for last pass
Repro found: flight 9591 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Bug introduced: 1c8789852eaf
Bug not present: 8269826353d8
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
changeset: 23990:1c8789852eaf
user: Jan Beulich <jbeulich@suse.com>
date: Fri Oct 21 09:44:47 2011 +0200
x86/hpet: allocate CPU masks dynamically
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-i386-i386-pair.leak-check--check--src_host.{dot,ps,png,html}.
----------------------------------------
9591: trouble: broken
flight 9591 xen-unstable real-bisect [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/9591/
jobs:
test-i386-i386-pair broken
------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
^ permalink raw reply
* dec behavior question
From: Kumar Gala @ 2011-10-24 14:01 UTC (permalink / raw)
To: David Gibson; +Cc: devicetree-discuss
If I have something like:
---------------------------------------
spi.dtsi:
&spi0 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc8536-espi";
reg = <0x7000 0x1000>;
interrupts = <59 0x2 0 0>;
};
---------------------------------------
foo.dts:
spi0: spi@f00bar {
compatible = "FOOBAR";
};
/include/ "spi.dtsi"
---------------------------------------
What do you expect the resulting dtb to look like w/regards to the compatible node?
- k
^ permalink raw reply
* Re: [PATCH 03/11] powerpc/85xx: Rework PCI nodes on P1020RDB
From: Kumar Gala @ 2011-10-24 14:02 UTC (permalink / raw)
To: Tabi Timur-B04825; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <CAOZdJXUy5qDhbEAih2kx91fmgyxqd7u9T6AV4fDvp4AMMRA+4w@mail.gmail.com>
On Oct 23, 2011, at 9:37 AM, Tabi Timur-B04825 wrote:
> On Sat, Oct 22, 2011 at 4:20 PM, Kumar Gala =
<galak@kernel.crashing.org> wrote:
>> * Move SoC specific details like irq mapping to SoC dtsi
>> * Update interrupt property to cover both error interrupt and PCIe
>> runtime interrupts
>=20
> Are we going to be doing this for all our device trees? If so, then I
> think we need to document what properties the board dts should be
> defining when it includes a node from a dtsi. Something like this:
Yes, I intend we do this as much as possible.
> dtsi:
> pcie@0 {
> /* dts should define 'reg' and 'ranges' */
> reg =3D <0 0 0 0 0>;
> #interrupt-cells =3D <1>;
>=20
> I suppose it's obvious that 'reg' and 'ranges' should be defined, so
> this isn't the best example. But we should document if any other
> properties should be defined.
>=20
> For example, the SSI nodes contain a bunch of SOC- and board-specific
> properties.
I would have hoped the bindings had made it clear already what was board =
info vs what was SoC.
If not, they should be clarify that in the binding specs.
- k=
^ permalink raw reply
* [xen-unstable bisection] complete test-i386-i386-pair
From: xen.org @ 2011-10-24 14:02 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson, keir, stefano.stabellini
branch xen-unstable
xen branch xen-unstable
job test-i386-i386-pair
test leak-check/check/dst_host
Tree: linux git://github.com/jsgf/linux-xen.git
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
*** Found and reproduced problem changeset ***
Bug is in tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Bug introduced: 1c8789852eaf
Bug not present: 8269826353d8
changeset: 23990:1c8789852eaf
user: Jan Beulich <jbeulich@suse.com>
date: Fri Oct 21 09:44:47 2011 +0200
x86/hpet: allocate CPU masks dynamically
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
For bisection revision-tuple graph see:
http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-i386-i386-pair.leak-check--check--dst_host.html
Revision IDs in each graph node refer, respectively, to the Trees above.
----------------------------------------
Searching for failure / basis pass:
9471 fail [dst_host=field-cricket,src_host=bush-cricket] / 9355 ok.
Failure / basis pass flights: 9471 / 9355
Tree: linux git://github.com/jsgf/linux-xen.git
Tree: qemu git://hg.uk.xensource.com/HG/qemu-xen-unstable.git
Tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Latest 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 a7ccbc79fc17
Basis pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 6c583d35d76d
Generating revisions with ./adhoc-revtuple-generator git://github.com/jsgf/linux-xen.git#6bec8b4a4c14095d0b7ce424db9d583c3decae6c-6bec8b4a4c14095d0b7ce424db9d583c3decae6c git://hg.uk.xensource.com/HG/qemu-xen-unstable.git#25378e0a76b282127e9ab8933a4defbc91db3862-25378e0a76b282127e9ab8933a4defbc91db3862 http://xenbits.xen.org/staging/xen-unstable.hg#6c583d35d76d-a7ccbc79fc17
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
Loaded 74 nodes in revision graph
Searching for test results:
9355 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 6c583d35d76d
9363 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 a7ccbc79fc17
9390 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 6c583d35d76d
9391 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 a7ccbc79fc17
9392 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 253073b522f8
9471 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 a7ccbc79fc17
9472 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 53528bab2eb4
9554 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 8269826353d8
9587 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 1c8789852eaf
9588 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 8269826353d8
9589 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 1c8789852eaf
9590 pass 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 8269826353d8
9591 fail 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 1c8789852eaf
Searching for interesting versions
Result found: flight 9355 (pass), for basis pass
Result found: flight 9363 (fail), for basis failure
Repro found: flight 9390 (pass), for basis pass
Repro found: flight 9391 (fail), for basis failure
0 revisions at 6bec8b4a4c14095d0b7ce424db9d583c3decae6c 25378e0a76b282127e9ab8933a4defbc91db3862 8269826353d8
No revisions left to test, checking graph state.
Result found: flight 9554 (pass), for last pass
Result found: flight 9587 (fail), for first failure
Repro found: flight 9588 (pass), for last pass
Repro found: flight 9589 (fail), for first failure
Repro found: flight 9590 (pass), for last pass
Repro found: flight 9591 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: xen http://xenbits.xen.org/staging/xen-unstable.hg
Bug introduced: 1c8789852eaf
Bug not present: 8269826353d8
pulling from ssh://xen@xenbits.xen.org/HG/staging/xen-unstable.hg
searching for changes
no changes found
changeset: 23990:1c8789852eaf
user: Jan Beulich <jbeulich@suse.com>
date: Fri Oct 21 09:44:47 2011 +0200
x86/hpet: allocate CPU masks dynamically
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Revision graph left in /home/xc_osstest/results/bisect.xen-unstable.test-i386-i386-pair.leak-check--check--dst_host.{dot,ps,png,html}.
No revision to test.
^ permalink raw reply
* Re: [PATCH V2 01/10] configure: Introduce --enable-xen-pci-passthrough.
From: Anthony PERARD @ 2011-10-24 14:02 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Xen Devel, QEMU-devel
In-Reply-To: <alpine.DEB.2.00.1110201135540.3519@kaball-desktop>
On Thu, Oct 20, 2011 at 11:57, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
>
>> diff --git a/Makefile.target b/Makefile.target
>> index 417f23e..c518103 100644
>> --- a/Makefile.target
>> +++ b/Makefile.target
>> @@ -208,6 +208,8 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
>>
>> obj-i386-$(CONFIG_XEN) += xen_platform.o
>>
>> +# Xen PCI Passthrough
>> +
>
> why?
To reserve a space for futur addition. So on the next patch, I'll just
add the object to compile and not this comment.
And why not ?
--
Anthony PERARD
^ permalink raw reply
* Re: [PATCH v2 BlueZ] Add new command and event for LTK storage support
From: Johan Hedberg @ 2011-10-24 14:03 UTC (permalink / raw)
To: Vinicius Costa Gomes; +Cc: linux-bluetooth
In-Reply-To: <1319463212-13307-1-git-send-email-vinicius.gomes@openbossa.org>
Hi Vinicius,
On Mon, Oct 24, 2011, Vinicius Costa Gomes wrote:
> This documents the new command and event that are to be added to
> the Management API to add support for persistent pairing of LE
> devices.
> ---
>
> Changes:
> - New command code, because new commands were added;
> - Removed the Debug Keys parameter;
>
>
> doc/mgmt-api.txt | 32 ++++++++++++++++++++++++++++++++
> 1 files changed, 32 insertions(+), 0 deletions(-)
Applied, except that the event needed to be 0x0018 instead of 17 because
of the new Passkey Request event.
Johan
^ permalink raw reply
* Re: [Qemu-devel] [PATCH V2 01/10] configure: Introduce --enable-xen-pci-passthrough.
From: Anthony PERARD @ 2011-10-24 14:02 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: Xen Devel, QEMU-devel
In-Reply-To: <alpine.DEB.2.00.1110201135540.3519@kaball-desktop>
On Thu, Oct 20, 2011 at 11:57, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
>
>> diff --git a/Makefile.target b/Makefile.target
>> index 417f23e..c518103 100644
>> --- a/Makefile.target
>> +++ b/Makefile.target
>> @@ -208,6 +208,8 @@ obj-$(CONFIG_NO_XEN) += xen-stub.o
>>
>> obj-i386-$(CONFIG_XEN) += xen_platform.o
>>
>> +# Xen PCI Passthrough
>> +
>
> why?
To reserve a space for futur addition. So on the next patch, I'll just
add the object to compile and not this comment.
And why not ?
--
Anthony PERARD
^ permalink raw reply
* Re: [RFC PATCH 2/2] tools/perf: Make group_fd static and move its place in __perf_evsel__open()
From: Arnaldo Carvalho de Melo @ 2011-10-24 14:03 UTC (permalink / raw)
To: Deng-Cheng Zhu; +Cc: linux-kernel, Peter Zijlstra, Paul Mackerras, Ingo Molnar
In-Reply-To: <1319453820-12992-3-git-send-email-dczhu@mips.com>
Em Mon, Oct 24, 2011 at 06:57:00PM +0800, Deng-Cheng Zhu escreveu:
> __perf_evsel__open() is called per event, it does not work for all the
> grouped events at one time. So, currently group_fd will alway be -1 for
> the events in a group. This patch fixes it.
>
> Signed-off-by: Deng-Cheng Zhu <dczhu@mips.com>
> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
> ---
> tools/perf/util/evsel.c | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> index e389815..7bd0d9d 100644
> --- a/tools/perf/util/evsel.c
> +++ b/tools/perf/util/evsel.c
> @@ -219,9 +219,8 @@ static int __perf_evsel__open(struct perf_evsel *evsel, struct cpu_map *cpus,
> }
>
> for (cpu = 0; cpu < cpus->nr; cpu++) {
> - int group_fd = -1;
> -
> for (thread = 0; thread < threads->nr; thread++) {
> + static int group_fd = -1;
>
> if (!evsel->cgrp)
> pid = threads->map[thread];
Lets not do it that way, using statics for this is humm, ugly, IMHO.
Just pass an integer pointer that is a member of perf_evlist, I'll work
on a patch now.
Thanks for reporting the bug tho!
- Arnaldo
^ permalink raw reply
* Re: [PATCH 1/2] Bluetooth: Return proper error codes on rfcomm tty init
From: David Herrmann @ 2011-10-24 14:03 UTC (permalink / raw)
To: Anderson Briglia; +Cc: linux-bluetooth, padovan
In-Reply-To: <CALJ2SBJ3qgHV91sS-PXkrS6w7kaxMnHFM0Z-eM2KGUedCZy0nA@mail.gmail.com>
On Mon, Oct 24, 2011 at 3:57 PM, Anderson Briglia
<anderson.briglia@openbossa.org> wrote:
> Hi David,
>
> On Mon, Oct 24, 2011 at 3:30 PM, David Herrmann
> <dh.herrmann@googlemail.com> wrote:
>> Forward error codes from tty core to the rfcomm_init caller instead of using
>> generic -1 errors.
>>
>> Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
>> ---
>> net/bluetooth/rfcomm/tty.c | 9 ++++++---
>> 1 files changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/net/bluetooth/rfcomm/tty.c b/net/bluetooth/rfcomm/tty.c
>> index c258796..2b753a3 100644
>> --- a/net/bluetooth/rfcomm/tty.c
>> +++ b/net/bluetooth/rfcomm/tty.c
>> @@ -1155,9 +1155,11 @@ static const struct tty_operations rfcomm_ops = {
>>
>> int __init rfcomm_init_ttys(void)
>> {
>> + int error;
>> +
>> rfcomm_tty_driver = alloc_tty_driver(RFCOMM_TTY_PORTS);
>> if (!rfcomm_tty_driver)
>> - return -1;
>> + return -ENOMEM;
>>
>> rfcomm_tty_driver->owner = THIS_MODULE;
>> rfcomm_tty_driver->driver_name = "rfcomm";
>> @@ -1172,10 +1174,11 @@ int __init rfcomm_init_ttys(void)
>> rfcomm_tty_driver->init_termios.c_lflag &= ~ICANON;
>> tty_set_operations(rfcomm_tty_driver, &rfcomm_ops);
>>
>> - if (tty_register_driver(rfcomm_tty_driver)) {
>> + error = tty_register_driver(rfcomm_tty_driver);
>> + if (error) {
>> BT_ERR("Can't register RFCOMM TTY driver");
>> put_tty_driver(rfcomm_tty_driver);
>> - return -1;
>> + return error;
>
> Since you are defining a new variable (error), how about use it on
> other error paths and add a "goto out" and have just one return path?
Isn't it quite common style to have the first error path return
directly? And then the other error paths use goto. However, there is
only one additional error path left so I don't see any way to make
this look nicer.
With more than 2 error paths I agree, a goto would be more readable,
but I cannot see this making this function look nicer. Anyway, if you
guys want, I can resend with goto's.
> Regards,
>
> Anderson Briglia
Regards
David
^ permalink raw reply
* Re: [PATCH] gpiolib: Ensure struct gpio is always defined
From: Grant Likely @ 2011-10-24 14:04 UTC (permalink / raw)
To: Mark Brown; +Cc: Grant Likely, linux-kernel, patches
In-Reply-To: <1319462650-23696-1-git-send-email-broonie@opensource.wolfsonmicro.com>
On Mon, Oct 24, 2011 at 03:24:10PM +0200, Mark Brown wrote:
> Currently struct gpio is only defined when using gpiolib which makes the
> stub gpio_request_array() much less useful in drivers than is ideal as
> they can't work with struct gpio. Since there are no other definitions
> in kernel instead make the define always available no matter if gpiolib
> is selectable or selected, ensuring that drivers can always use the
> type.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
>
> flob
Applied, thanks.
What does "flob" mean?
g.
> ---
> include/asm-generic/gpio.h | 12 ------------
> include/linux/gpio.h | 22 ++++++++++++----------
> 2 files changed, 12 insertions(+), 22 deletions(-)
>
> diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
> index d494001..d0b6423 100644
> --- a/include/asm-generic/gpio.h
> +++ b/include/asm-generic/gpio.h
> @@ -170,18 +170,6 @@ extern int __gpio_cansleep(unsigned gpio);
>
> extern int __gpio_to_irq(unsigned gpio);
>
> -/**
> - * struct gpio - a structure describing a GPIO with configuration
> - * @gpio: the GPIO number
> - * @flags: GPIO configuration as specified by GPIOF_*
> - * @label: a literal description string of this GPIO
> - */
> -struct gpio {
> - unsigned gpio;
> - unsigned long flags;
> - const char *label;
> -};
> -
> extern int gpio_request_one(unsigned gpio, unsigned long flags, const char *label);
> extern int gpio_request_array(const struct gpio *array, size_t num);
> extern void gpio_free_array(const struct gpio *array, size_t num);
> diff --git a/include/linux/gpio.h b/include/linux/gpio.h
> index 17b5a0d..38ac48b 100644
> --- a/include/linux/gpio.h
> +++ b/include/linux/gpio.h
> @@ -14,6 +14,18 @@
> #define GPIOF_OUT_INIT_LOW (GPIOF_DIR_OUT | GPIOF_INIT_LOW)
> #define GPIOF_OUT_INIT_HIGH (GPIOF_DIR_OUT | GPIOF_INIT_HIGH)
>
> +/**
> + * struct gpio - a structure describing a GPIO with configuration
> + * @gpio: the GPIO number
> + * @flags: GPIO configuration as specified by GPIOF_*
> + * @label: a literal description string of this GPIO
> + */
> +struct gpio {
> + unsigned gpio;
> + unsigned long flags;
> + const char *label;
> +};
> +
> #ifdef CONFIG_GENERIC_GPIO
> #include <asm/gpio.h>
>
> @@ -24,18 +36,8 @@
> #include <linux/errno.h>
>
> struct device;
> -struct gpio;
> struct gpio_chip;
>
> -/*
> - * Some platforms don't support the GPIO programming interface.
> - *
> - * In case some driver uses it anyway (it should normally have
> - * depended on GENERIC_GPIO), these routines help the compiler
> - * optimize out much GPIO-related code ... or trigger a runtime
> - * warning when something is wrongly called.
> - */
> -
> static inline bool gpio_is_valid(int number)
> {
> return false;
> --
> 1.7.6.3
>
^ permalink raw reply
* [PATCH V3 1/2] ARM: at91: dt: at91sam9g45 family and board device tree files
From: Nicolas Ferre @ 2011-10-24 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E9F8226.4030503@gmail.com>
Create a new device tree source file for Atmel at91sam9g45 SoC family.
The Evaluation Kit at91sam9m10g45ek includes it.
This first basic support will be populated as drivers and boards will be
converted to device tree.
Contains serial, dma and interrupt controllers.
The generic board file still takes advantage of platform data for early serial
init. As we need a storage media and the NAND flash driver is not converted to
DT yet, we keep old initialization for it.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
V3:
- additional clock lookup for device tree handling
- devices disabled in dtsi file so that only useful devices are
enabled in dts files
V2: foundation for AT91SAM generic support
- device tree focused board file
- inclusion of USART DT support
- early USART and NAND still using platform data
arch/arm/boot/dts/at91sam9g45.dtsi | 106 +++++++++++++++++++++++++++
arch/arm/boot/dts/at91sam9m10g45ek.dts | 35 +++++++++
arch/arm/mach-at91/Kconfig | 11 +++
arch/arm/mach-at91/Makefile | 3 +
arch/arm/mach-at91/Makefile.boot | 2 +
arch/arm/mach-at91/at91sam9g45.c | 6 ++
arch/arm/mach-at91/board-dt.c | 122 ++++++++++++++++++++++++++++++++
7 files changed, 285 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/at91sam9g45.dtsi
create mode 100644 arch/arm/boot/dts/at91sam9m10g45ek.dts
create mode 100644 arch/arm/mach-at91/board-dt.c
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
new file mode 100644
index 0000000..db6a452
--- /dev/null
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -0,0 +1,106 @@
+/*
+ * at91sam9g45.dtsi - Device Tree Include file for AT91SAM9G45 family SoC
+ * applies to AT91SAM9G45, AT91SAM9M10,
+ * AT91SAM9G46, AT91SAM9M11 SoC
+ *
+ * Copyright (C) 2011 Atmel,
+ * 2011 Nicolas Ferre <nicolas.ferre@atmel.com>
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+ model = "Atmel AT91SAM9G45 family SoC";
+ compatible = "atmel,at91sam9g45";
+ interrupt-parent = <&aic>;
+
+ aliases {
+ serial0 = &dbgu;
+ serial1 = &usart0;
+ serial2 = &usart1;
+ serial3 = &usart2;
+ serial4 = &usart3;
+ };
+ cpus {
+ cpu at 0 {
+ compatible = "arm,arm926ejs";
+ };
+ };
+
+ memory at 70000000 {
+ reg = <0x70000000 0x10000000>;
+ };
+
+ ahb {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ apb {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ aic: interrupt-controller at fffff000 {
+ #interrupt-cells = <1>;
+ compatible = "atmel,at91rm9200-aic";
+ interrupt-controller;
+ interrupt-parent;
+ reg = <0xfffff000 0x200>;
+ };
+
+ dma: dma-controller at ffffec00 {
+ compatible = "atmel,at91sam9g45-dma";
+ reg = <0xffffec00 0x200>;
+ interrupts = <21>;
+ };
+
+ dbgu: serial at ffffee00 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0xffffee00 0x200>;
+ interrupts = <1>;
+ status = "disabled";
+ };
+
+ usart0: serial at fff8c000 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0xfff8c000 0x200>;
+ interrupts = <7>;
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ status = "disabled";
+ };
+
+ usart1: serial at fff90000 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0xfff90000 0x200>;
+ interrupts = <8>;
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ status = "disabled";
+ };
+
+ usart2: serial at fff94000 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0xfff94000 0x200>;
+ interrupts = <9>;
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ status = "disabled";
+ };
+
+ usart3: serial at fff98000 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0xfff98000 0x200>;
+ interrupts = <10>;
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ status = "disabled";
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/at91sam9m10g45ek.dts b/arch/arm/boot/dts/at91sam9m10g45ek.dts
new file mode 100644
index 0000000..85b34f5
--- /dev/null
+++ b/arch/arm/boot/dts/at91sam9m10g45ek.dts
@@ -0,0 +1,35 @@
+/*
+ * at91sam9m10g45ek.dts - Device Tree file for AT91SAM9M10G45-EK board
+ *
+ * Copyright (C) 2011 Atmel,
+ * 2011 Nicolas Ferre <nicolas.ferre@atmel.com>
+ *
+ * Licensed under GPLv2 or later.
+ */
+/dts-v1/;
+/include/ "at91sam9g45.dtsi"
+
+/ {
+ model = "Atmel AT91SAM9M10G45-EK";
+ compatible = "atmel,at91sam9m10g45ek", "atmel,at91sam9g45", "atmel,at91sam9";
+
+ chosen {
+ bootargs = "mem=64M console=ttyS0,115200 mtdparts=atmel_nand:4M(bootstrap/uboot/kernel)ro,60M(rootfs),-(data) root=/dev/mtdblock1 rw rootfstype=jffs2";
+ };
+
+ memory at 70000000 {
+ reg = <0x70000000 0x4000000>;
+ };
+
+ ahb {
+ apb {
+ dbgu: serial at ffffee00 {
+ status = "okay";
+ };
+
+ usart1: serial at fff90000 {
+ status = "okay";
+ };
+ };
+ };
+};
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index 2248467..4b59d96 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -442,6 +442,17 @@ endif
# ----------------------------------------------------------
+comment "Generic Board Type"
+
+config MACH_AT91SAM_DT
+ bool "Atmel AT91SAM Evaluation Kits with device-tree support"
+ select USE_OF
+ help
+ Select this if you want to experiment device-tree with
+ an Atmel Evaluation Kit.
+
+# ----------------------------------------------------------
+
comment "AT91 Board Options"
config MTD_AT91_DATAFLASH_CARD
diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
index bf57e8b..3ff245e 100644
--- a/arch/arm/mach-at91/Makefile
+++ b/arch/arm/mach-at91/Makefile
@@ -74,6 +74,9 @@ obj-$(CONFIG_MACH_SNAPPER_9260) += board-snapper9260.o
# AT91SAM9G45 board-specific support
obj-$(CONFIG_MACH_AT91SAM9M10G45EK) += board-sam9m10g45ek.o
+# AT91SAM board with device-tree
+obj-$(CONFIG_MACH_AT91SAM_DT) += board-dt.o
+
# AT91CAP9 board-specific support
obj-$(CONFIG_MACH_AT91CAP9ADK) += board-cap9adk.o
diff --git a/arch/arm/mach-at91/Makefile.boot b/arch/arm/mach-at91/Makefile.boot
index 3462b81..d278863 100644
--- a/arch/arm/mach-at91/Makefile.boot
+++ b/arch/arm/mach-at91/Makefile.boot
@@ -16,3 +16,5 @@ else
params_phys-y := 0x20000100
initrd_phys-y := 0x20410000
endif
+
+dtb-$(CONFIG_MACH_AT91SAM_DT) += at91sam9m10g45ek.dtb
diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c
index e04c5fb..8baf5a1 100644
--- a/arch/arm/mach-at91/at91sam9g45.c
+++ b/arch/arm/mach-at91/at91sam9g45.c
@@ -215,6 +215,12 @@ static struct clk_lookup periph_clocks_lookups[] = {
CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.1", &tcb0_clk),
CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk),
CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk),
+ /* more usart lookup table for DT entries */
+ CLKDEV_CON_DEV_ID("usart", "ffffee00.serial", &mck),
+ CLKDEV_CON_DEV_ID("usart", "fff8c000.serial", &usart0_clk),
+ CLKDEV_CON_DEV_ID("usart", "fff90000.serial", &usart1_clk),
+ CLKDEV_CON_DEV_ID("usart", "fff94000.serial", &usart2_clk),
+ CLKDEV_CON_DEV_ID("usart", "fff98000.serial", &usart3_clk),
};
static struct clk_lookup usart_clocks_lookups[] = {
diff --git a/arch/arm/mach-at91/board-dt.c b/arch/arm/mach-at91/board-dt.c
new file mode 100644
index 0000000..77fe466
--- /dev/null
+++ b/arch/arm/mach-at91/board-dt.c
@@ -0,0 +1,122 @@
+/*
+ * Setup code for AT91SAM Evaluation Kits with Device Tree support
+ *
+ * Covers: * AT91SAM9G45-EKES board
+ * * AT91SAM9M10-EKES board
+ * * AT91SAM9M10G45-EK board
+ *
+ * Copyright (C) 2011 Atmel,
+ * 2011 Nicolas Ferre <nicolas.ferre@atmel.com>
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/gpio.h>
+#include <linux/irqdomain.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+
+#include <mach/hardware.h>
+#include <mach/board.h>
+#include <mach/system_rev.h>
+#include <mach/at91sam9_smc.h>
+
+#include <asm/setup.h>
+#include <asm/irq.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <asm/mach/irq.h>
+
+#include "sam9_smc.h"
+#include "generic.h"
+
+
+static void __init ek_init_early(void)
+{
+ /* Initialize processor: 12.000 MHz crystal */
+ at91_initialize(12000000);
+
+ /* DGBU on ttyS0. (Rx & Tx only) */
+ at91_register_uart(0, 0, 0);
+
+ /* set serial console to ttyS0 (ie, DBGU) */
+ at91_set_serial_console(0);
+}
+
+/* det_pin is not connected */
+static struct atmel_nand_data __initdata ek_nand_data = {
+ .ale = 21,
+ .cle = 22,
+ .rdy_pin = AT91_PIN_PC8,
+ .enable_pin = AT91_PIN_PC14,
+};
+
+static struct sam9_smc_config __initdata ek_nand_smc_config = {
+ .ncs_read_setup = 0,
+ .nrd_setup = 2,
+ .ncs_write_setup = 0,
+ .nwe_setup = 2,
+
+ .ncs_read_pulse = 4,
+ .nrd_pulse = 4,
+ .ncs_write_pulse = 4,
+ .nwe_pulse = 4,
+
+ .read_cycle = 7,
+ .write_cycle = 7,
+
+ .mode = AT91_SMC_READMODE | AT91_SMC_WRITEMODE | AT91_SMC_EXNWMODE_DISABLE,
+ .tdf_cycles = 3,
+};
+
+static void __init ek_add_device_nand(void)
+{
+ ek_nand_data.bus_width_16 = board_have_nand_16bit();
+ /* setup bus-width (8 or 16) */
+ if (ek_nand_data.bus_width_16)
+ ek_nand_smc_config.mode |= AT91_SMC_DBW_16;
+ else
+ ek_nand_smc_config.mode |= AT91_SMC_DBW_8;
+
+ /* configure chip-select 3 (NAND) */
+ sam9_smc_configure(3, &ek_nand_smc_config);
+
+ at91_add_device_nand(&ek_nand_data);
+}
+
+static const struct of_device_id aic_of_match[] __initconst = {
+ { .compatible = "atmel,at91rm9200-aic", },
+ {},
+};
+
+static void __init at91_dt_init_irq(void)
+{
+ irq_domain_generate_simple(aic_of_match, 0xfffff000, 0);
+ at91_init_irq_default();
+}
+
+static void __init at91_dt_device_init(void)
+{
+ of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+
+ /* NAND */
+ ek_add_device_nand();
+}
+
+static const char *at91_dt_board_compat[] __initdata = {
+ "atmel,at91sam9m10g45ek",
+ NULL
+};
+
+DT_MACHINE_START(at91sam9m10g45ek_dt, "Atmel AT91SAM (Device Tree)")
+ /* Maintainer: Atmel */
+ .timer = &at91sam926x_timer,
+ .map_io = at91_map_io,
+ .init_early = ek_init_early,
+ .init_irq = at91_dt_init_irq,
+ .init_machine = at91_dt_device_init,
+ .dt_compat = at91_dt_board_compat,
+MACHINE_END
--
1.7.5.4
^ permalink raw reply related
* [PATCH V3 1/2] ARM: at91: dt: at91sam9g45 family and board device tree files
From: Nicolas Ferre @ 2011-10-24 14:05 UTC (permalink / raw)
To: robherring2-Re5JQEeQqe8AvxtiuMwx3w,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <4E9F8226.4030503-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Create a new device tree source file for Atmel at91sam9g45 SoC family.
The Evaluation Kit at91sam9m10g45ek includes it.
This first basic support will be populated as drivers and boards will be
converted to device tree.
Contains serial, dma and interrupt controllers.
The generic board file still takes advantage of platform data for early serial
init. As we need a storage media and the NAND flash driver is not converted to
DT yet, we keep old initialization for it.
Signed-off-by: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
---
V3:
- additional clock lookup for device tree handling
- devices disabled in dtsi file so that only useful devices are
enabled in dts files
V2: foundation for AT91SAM generic support
- device tree focused board file
- inclusion of USART DT support
- early USART and NAND still using platform data
arch/arm/boot/dts/at91sam9g45.dtsi | 106 +++++++++++++++++++++++++++
arch/arm/boot/dts/at91sam9m10g45ek.dts | 35 +++++++++
arch/arm/mach-at91/Kconfig | 11 +++
arch/arm/mach-at91/Makefile | 3 +
arch/arm/mach-at91/Makefile.boot | 2 +
arch/arm/mach-at91/at91sam9g45.c | 6 ++
arch/arm/mach-at91/board-dt.c | 122 ++++++++++++++++++++++++++++++++
7 files changed, 285 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/at91sam9g45.dtsi
create mode 100644 arch/arm/boot/dts/at91sam9m10g45ek.dts
create mode 100644 arch/arm/mach-at91/board-dt.c
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
new file mode 100644
index 0000000..db6a452
--- /dev/null
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -0,0 +1,106 @@
+/*
+ * at91sam9g45.dtsi - Device Tree Include file for AT91SAM9G45 family SoC
+ * applies to AT91SAM9G45, AT91SAM9M10,
+ * AT91SAM9G46, AT91SAM9M11 SoC
+ *
+ * Copyright (C) 2011 Atmel,
+ * 2011 Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+ model = "Atmel AT91SAM9G45 family SoC";
+ compatible = "atmel,at91sam9g45";
+ interrupt-parent = <&aic>;
+
+ aliases {
+ serial0 = &dbgu;
+ serial1 = &usart0;
+ serial2 = &usart1;
+ serial3 = &usart2;
+ serial4 = &usart3;
+ };
+ cpus {
+ cpu@0 {
+ compatible = "arm,arm926ejs";
+ };
+ };
+
+ memory@70000000 {
+ reg = <0x70000000 0x10000000>;
+ };
+
+ ahb {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ apb {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ aic: interrupt-controller@fffff000 {
+ #interrupt-cells = <1>;
+ compatible = "atmel,at91rm9200-aic";
+ interrupt-controller;
+ interrupt-parent;
+ reg = <0xfffff000 0x200>;
+ };
+
+ dma: dma-controller@ffffec00 {
+ compatible = "atmel,at91sam9g45-dma";
+ reg = <0xffffec00 0x200>;
+ interrupts = <21>;
+ };
+
+ dbgu: serial@ffffee00 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0xffffee00 0x200>;
+ interrupts = <1>;
+ status = "disabled";
+ };
+
+ usart0: serial@fff8c000 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0xfff8c000 0x200>;
+ interrupts = <7>;
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ status = "disabled";
+ };
+
+ usart1: serial@fff90000 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0xfff90000 0x200>;
+ interrupts = <8>;
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ status = "disabled";
+ };
+
+ usart2: serial@fff94000 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0xfff94000 0x200>;
+ interrupts = <9>;
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ status = "disabled";
+ };
+
+ usart3: serial@fff98000 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0xfff98000 0x200>;
+ interrupts = <10>;
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ status = "disabled";
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/at91sam9m10g45ek.dts b/arch/arm/boot/dts/at91sam9m10g45ek.dts
new file mode 100644
index 0000000..85b34f5
--- /dev/null
+++ b/arch/arm/boot/dts/at91sam9m10g45ek.dts
@@ -0,0 +1,35 @@
+/*
+ * at91sam9m10g45ek.dts - Device Tree file for AT91SAM9M10G45-EK board
+ *
+ * Copyright (C) 2011 Atmel,
+ * 2011 Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
+ *
+ * Licensed under GPLv2 or later.
+ */
+/dts-v1/;
+/include/ "at91sam9g45.dtsi"
+
+/ {
+ model = "Atmel AT91SAM9M10G45-EK";
+ compatible = "atmel,at91sam9m10g45ek", "atmel,at91sam9g45", "atmel,at91sam9";
+
+ chosen {
+ bootargs = "mem=64M console=ttyS0,115200 mtdparts=atmel_nand:4M(bootstrap/uboot/kernel)ro,60M(rootfs),-(data) root=/dev/mtdblock1 rw rootfstype=jffs2";
+ };
+
+ memory@70000000 {
+ reg = <0x70000000 0x4000000>;
+ };
+
+ ahb {
+ apb {
+ dbgu: serial@ffffee00 {
+ status = "okay";
+ };
+
+ usart1: serial@fff90000 {
+ status = "okay";
+ };
+ };
+ };
+};
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index 2248467..4b59d96 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -442,6 +442,17 @@ endif
# ----------------------------------------------------------
+comment "Generic Board Type"
+
+config MACH_AT91SAM_DT
+ bool "Atmel AT91SAM Evaluation Kits with device-tree support"
+ select USE_OF
+ help
+ Select this if you want to experiment device-tree with
+ an Atmel Evaluation Kit.
+
+# ----------------------------------------------------------
+
comment "AT91 Board Options"
config MTD_AT91_DATAFLASH_CARD
diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
index bf57e8b..3ff245e 100644
--- a/arch/arm/mach-at91/Makefile
+++ b/arch/arm/mach-at91/Makefile
@@ -74,6 +74,9 @@ obj-$(CONFIG_MACH_SNAPPER_9260) += board-snapper9260.o
# AT91SAM9G45 board-specific support
obj-$(CONFIG_MACH_AT91SAM9M10G45EK) += board-sam9m10g45ek.o
+# AT91SAM board with device-tree
+obj-$(CONFIG_MACH_AT91SAM_DT) += board-dt.o
+
# AT91CAP9 board-specific support
obj-$(CONFIG_MACH_AT91CAP9ADK) += board-cap9adk.o
diff --git a/arch/arm/mach-at91/Makefile.boot b/arch/arm/mach-at91/Makefile.boot
index 3462b81..d278863 100644
--- a/arch/arm/mach-at91/Makefile.boot
+++ b/arch/arm/mach-at91/Makefile.boot
@@ -16,3 +16,5 @@ else
params_phys-y := 0x20000100
initrd_phys-y := 0x20410000
endif
+
+dtb-$(CONFIG_MACH_AT91SAM_DT) += at91sam9m10g45ek.dtb
diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c
index e04c5fb..8baf5a1 100644
--- a/arch/arm/mach-at91/at91sam9g45.c
+++ b/arch/arm/mach-at91/at91sam9g45.c
@@ -215,6 +215,12 @@ static struct clk_lookup periph_clocks_lookups[] = {
CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.1", &tcb0_clk),
CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk),
CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk),
+ /* more usart lookup table for DT entries */
+ CLKDEV_CON_DEV_ID("usart", "ffffee00.serial", &mck),
+ CLKDEV_CON_DEV_ID("usart", "fff8c000.serial", &usart0_clk),
+ CLKDEV_CON_DEV_ID("usart", "fff90000.serial", &usart1_clk),
+ CLKDEV_CON_DEV_ID("usart", "fff94000.serial", &usart2_clk),
+ CLKDEV_CON_DEV_ID("usart", "fff98000.serial", &usart3_clk),
};
static struct clk_lookup usart_clocks_lookups[] = {
diff --git a/arch/arm/mach-at91/board-dt.c b/arch/arm/mach-at91/board-dt.c
new file mode 100644
index 0000000..77fe466
--- /dev/null
+++ b/arch/arm/mach-at91/board-dt.c
@@ -0,0 +1,122 @@
+/*
+ * Setup code for AT91SAM Evaluation Kits with Device Tree support
+ *
+ * Covers: * AT91SAM9G45-EKES board
+ * * AT91SAM9M10-EKES board
+ * * AT91SAM9M10G45-EK board
+ *
+ * Copyright (C) 2011 Atmel,
+ * 2011 Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/gpio.h>
+#include <linux/irqdomain.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+
+#include <mach/hardware.h>
+#include <mach/board.h>
+#include <mach/system_rev.h>
+#include <mach/at91sam9_smc.h>
+
+#include <asm/setup.h>
+#include <asm/irq.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <asm/mach/irq.h>
+
+#include "sam9_smc.h"
+#include "generic.h"
+
+
+static void __init ek_init_early(void)
+{
+ /* Initialize processor: 12.000 MHz crystal */
+ at91_initialize(12000000);
+
+ /* DGBU on ttyS0. (Rx & Tx only) */
+ at91_register_uart(0, 0, 0);
+
+ /* set serial console to ttyS0 (ie, DBGU) */
+ at91_set_serial_console(0);
+}
+
+/* det_pin is not connected */
+static struct atmel_nand_data __initdata ek_nand_data = {
+ .ale = 21,
+ .cle = 22,
+ .rdy_pin = AT91_PIN_PC8,
+ .enable_pin = AT91_PIN_PC14,
+};
+
+static struct sam9_smc_config __initdata ek_nand_smc_config = {
+ .ncs_read_setup = 0,
+ .nrd_setup = 2,
+ .ncs_write_setup = 0,
+ .nwe_setup = 2,
+
+ .ncs_read_pulse = 4,
+ .nrd_pulse = 4,
+ .ncs_write_pulse = 4,
+ .nwe_pulse = 4,
+
+ .read_cycle = 7,
+ .write_cycle = 7,
+
+ .mode = AT91_SMC_READMODE | AT91_SMC_WRITEMODE | AT91_SMC_EXNWMODE_DISABLE,
+ .tdf_cycles = 3,
+};
+
+static void __init ek_add_device_nand(void)
+{
+ ek_nand_data.bus_width_16 = board_have_nand_16bit();
+ /* setup bus-width (8 or 16) */
+ if (ek_nand_data.bus_width_16)
+ ek_nand_smc_config.mode |= AT91_SMC_DBW_16;
+ else
+ ek_nand_smc_config.mode |= AT91_SMC_DBW_8;
+
+ /* configure chip-select 3 (NAND) */
+ sam9_smc_configure(3, &ek_nand_smc_config);
+
+ at91_add_device_nand(&ek_nand_data);
+}
+
+static const struct of_device_id aic_of_match[] __initconst = {
+ { .compatible = "atmel,at91rm9200-aic", },
+ {},
+};
+
+static void __init at91_dt_init_irq(void)
+{
+ irq_domain_generate_simple(aic_of_match, 0xfffff000, 0);
+ at91_init_irq_default();
+}
+
+static void __init at91_dt_device_init(void)
+{
+ of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+
+ /* NAND */
+ ek_add_device_nand();
+}
+
+static const char *at91_dt_board_compat[] __initdata = {
+ "atmel,at91sam9m10g45ek",
+ NULL
+};
+
+DT_MACHINE_START(at91sam9m10g45ek_dt, "Atmel AT91SAM (Device Tree)")
+ /* Maintainer: Atmel */
+ .timer = &at91sam926x_timer,
+ .map_io = at91_map_io,
+ .init_early = ek_init_early,
+ .init_irq = at91_dt_init_irq,
+ .init_machine = at91_dt_device_init,
+ .dt_compat = at91_dt_board_compat,
+MACHINE_END
--
1.7.5.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.