* Re: [Qemu-devel] [PULL 00/19] Block patches
From: Anthony Liguori @ 2011-10-24 16:19 UTC (permalink / raw)
To: Kevin Wolf; +Cc: qemu-devel
In-Reply-To: <1319217556-28273-1-git-send-email-kwolf@redhat.com>
On 10/21/2011 12:18 PM, Kevin Wolf wrote:
> The following changes since commit c2e2343e1faae7bbc77574c12a25881b1b696808:
>
> hw/arm_gic.c: Fix save/load of irq_target array (2011-10-21 17:19:56 +0200)
>
> are available in the git repository at:
> git://repo.or.cz/qemu/kevin.git for-anthony
Pulled. Thanks.
Regards,
Anthony Liguori
>
> Alex Jia (1):
> fix memory leak in aio_write_f
>
> Kevin Wolf (5):
> xen_disk: Always set feature-barrier = 1
> fdc: Fix floppy port I/O
> qemu-img: Don't allow preallocation and compression at the same time
> qcow2: Fix bdrv_write_compressed error handling
> pc: Fix floppy drives with if=none
>
> Paolo Bonzini (12):
> sheepdog: add coroutine_fn markers
> add socket_set_block
> block: rename bdrv_co_rw_bh
> block: unify flush implementations
> block: add bdrv_co_discard and bdrv_aio_discard support
> vmdk: fix return values of vmdk_parent_open
> vmdk: clean up open
> block: add a CoMutex to synchronous read drivers
> block: take lock around bdrv_read implementations
> block: take lock around bdrv_write implementations
> block: change flush to co_flush
> block: change discard to co_discard
>
> Stefan Hajnoczi (1):
> block: drop redundant bdrv_flush implementation
>
> block.c | 258 ++++++++++++++++++++++++++++++-------------------
> block.h | 5 +
> block/blkdebug.c | 6 -
> block/blkverify.c | 9 --
> block/bochs.c | 15 +++-
> block/cloop.c | 15 +++-
> block/cow.c | 34 ++++++-
> block/dmg.c | 15 +++-
> block/nbd.c | 28 +++++-
> block/parallels.c | 15 +++-
> block/qcow.c | 17 +---
> block/qcow2-cluster.c | 6 +-
> block/qcow2.c | 72 ++++++--------
> block/qed.c | 6 -
> block/raw-posix.c | 23 +----
> block/raw-win32.c | 4 +-
> block/raw.c | 23 ++---
> block/rbd.c | 4 +-
> block/sheepdog.c | 14 ++--
> block/vdi.c | 6 +-
> block/vmdk.c | 82 ++++++++++------
> block/vpc.c | 34 ++++++-
> block/vvfat.c | 28 +++++-
> block_int.h | 9 +-
> hw/fdc.c | 14 +++
> hw/fdc.h | 9 ++-
> hw/pc.c | 25 +++--
> hw/pc.h | 3 +-
> hw/pc_piix.c | 5 +-
> hw/xen_disk.c | 5 +-
> oslib-posix.c | 7 ++
> oslib-win32.c | 6 +
> qemu-img.c | 11 ++
> qemu-io.c | 1 +
> qemu_socket.h | 1 +
> trace-events | 1 +
> 36 files changed, 524 insertions(+), 292 deletions(-)
>
>
^ permalink raw reply
* Re: ceph on non-btrfs file systems
From: Christian Brunner @ 2011-10-24 16:22 UTC (permalink / raw)
To: Sage Weil; +Cc: ceph-devel
In-Reply-To: <Pine.LNX.4.64.1110231739380.25255@cobra.newdream.net>
Thanks for explaining this. I don't have any objections against btrfs
as a osd filesystem. Even the fact that there is no btrfs-fsck doesn't
scare me, since I can use the ceph replication to recover a lost
btrfs-filesystem. The only problem I have is, that btrfs is not stable
on our side and I wonder what you are doing to make it work. (Maybe
it's related to the load pattern of using ceph as a backend store for
qemu).
Here is a list of the btrfs problems I'm having:
- When I run ceph with the default configuration (btrfs snaps enabled)
I can see a rapid increase in Disk-I/O after a few hours of uptime.
Btrfs-cleaner is using more and more time in
btrfs_clean_old_snapshots().
- When I run ceph with btrfs snaps disabled, the situation is getting
slightly better. I can run an OSD for about 3 days without problems,
but then again the load increases. This time, I can see that the
ceph-osd (blkdev_issue_flush) and btrfs-endio-wri are doing more work
than usual.
Another thing is that I'm seeing a WARNING: at fs/btrfs/inode.c:2114
from time to time. Maybe it's related to the performance issues, but
seems to be able to verify this.
It's really sad to see, that ceph performance and stability is
suffering that much from the underlying filesystems and that this
hasn't changed over the last months.
Kind regards,
Christian
2011/10/24 Sage Weil <sage@newdream.net>:
> Although running on ext4, xfs, or whatever other non-btrfs you want mostly
> works, there are a few important remaining issues:
>
> 1- ext4 limits total xattrs for 4KB. This can cause problems in some
> cases, as Ceph uses xattrs extensively. Most of the time we don't hit
> this. We do hit the limit with radosgw pretty easily, though, and may
> also hit it in exceptional cases where the OSD cluster is very unhealthy.
>
> There is a large xattr patch for ext4 from the Lustre folks that has been
> floating around for (I think) years. Maybe as interest grows in running
> Ceph on ext4 this can move upstream.
>
> Previously we were being forgiving about large setxattr failures on ext3,
> but we found that was leading to corruption in certain cases (because we
> couldn't set our internal metadata), so the next release will assert/crash
> in that case (fail-stop instead of fail-maybe-eventually-corrupt).
>
> XFS does not have an xattr size limit and thus does have this problem.
>
> 2- The other problem is with OSD journal replay of non-idempotent
> transactions. On non-btrfs backends, the Ceph OSDs use a write-ahead
> journal. After restart, the OSD does not know exactly which transactions
> in the journal may have already been committed to disk, and may reapply a
> transaction again during replay. For most operations (write, delete,
> truncate) this is fine.
>
> Some operations, though, are non-idempotent. The simplest example is
> CLONE, which copies (efficiently, on btrfs) data from one object to
> another. If the source object is modified, the osd restarts, and then
> the clone is replayed, the target will get incorrect (newer) data. For
> example,
>
> 1- clone A -> B
> 2- modify A
> <osd crash, replay from 1>
>
> B will get new instead of old contents.
>
> (This doesn't happen on btrfs because the snapshots allow us to replay
> from a known consistent point in time.)
>
> For things like clone, skipping the operation of the target exists almost
> works, except for cases like
>
> 1- clone A -> B
> 2- modify A
> ...
> 3- delete B
> <osd crash, replay from 1>
>
> (Although in that example who cares if B had bad data; it was removed
> anyway.) The larger problem, though, is that that doesn't always work;
> CLONERANGE copies a range of a file from A to B, where B may already
> exist.
>
> In practice, the higher level interfaces don't make full use of the
> low-level interface, so it's possible some solution exists that careful
> avoids the problem with a partial solution in the lower layer. This makes
> me nervous, though, as it is easy to break.
>
> Another possibility:
>
> - on non-btrfs, we set a xattr on every modified object with the
> op_seq, the unique sequence number for the transaction.
> - for any (potentially) non-idempotent operation, we fsync() before
> continuing to the next transaction, to ensure that xattr hits disk.
> - on replay, we skip a transaction if the xattr indicates we already
> performed this transaction.
>
> Because every 'transaction' only modifies on a single object (file),
> this ought to work. It'll make things like clone slow, but let's face it:
> they're already slow on non-btrfs file systems because they actually copy
> the data (instead of duplicating the extent refs in btrfs). And it should
> make the full ObjectStore iterface safe, without upper layers having to
> worry about the kinds and orders of transactions they perform.
>
> Other ideas?
>
> This issue is tracked at http://tracker.newdream.net/issues/213.
>
> sage
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/1] gst-plugins-good: correctly handle gconf schema
From: Richard Purdie @ 2011-10-24 16:18 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <64effb846c8f9b1e6fe57a7e213d24d046439b99.1319135920.git.josh@linux.intel.com>
On Thu, 2011-10-20 at 11:40 -0700, Joshua Lock wrote:
> Add the shipped gconf schema to the gconfelements package and inherit the gconf
> class so that schema processing is handled via post* scripts.
>
> Signed-off-by: Joshua Lock <josh@linux.intel.com>
> ---
> .../gstreamer/gst-plugins-good_0.10.30.bb | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
Merged to master, thanks.
Richard
^ permalink raw reply
* Re: Linux USB HID should ignore values outside Logical Minimum/Maximum range
From: Chris Friesen @ 2011-10-24 16:24 UTC (permalink / raw)
To: Denilson Figueiredo de Sá
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jiri Kosina,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <op.v3q34la3dsdv5o@localhost>
On 10/22/2011 05:42 AM, Denilson Figueiredo de Sá wrote:
> It may even happen to send an out-of-range value for one axis, but a
> valid value for another axis. The code should be prepared for that
> (ignore one, but keep the other).
In this case what should be used for the "invalid" axis value? The
previous value?
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.friesen-b7o/lNNmKxtBDgjK7y7TUQ@public.gmane.org
www.genband.com
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Xenomai-help] address spaces of real-time task and standard linux process
From: Thomas Lockhart @ 2011-10-24 16:25 UTC (permalink / raw)
To: haitaozhumail-disc@domain.hid; +Cc: xenomai@xenomai.org
In-Reply-To: <1319401552.9644.YahooMailNeo@domain.hid>
On 10/23/2011 01:25 PM, haitaozhumail-disc@domain.hid wrote:
> Hi All,
>
> Do a standard Linux process and a real-time task (spawned by the
> standard Linux process with rt_task_create and rt_task_start ) share the
> same address space? More specifically, I have a C++ program like this:
...
> Can the function demo() correctly access the object created in main()?
> What if pA is a smart pointer defined in Boost library?
Yes, yes, and yes (though I didn't look at the actual code, the address
space is shared).
For things like smart pointers, just make sure that someone is keeping a
reference to the object so the reference count does not go to zero.
hth
- Tom
^ permalink raw reply
* Re: Linux USB HID should ignore values outside Logical Minimum/Maximum range
From: Chris Friesen @ 2011-10-24 16:24 UTC (permalink / raw)
To: Denilson Figueiredo de Sá
Cc: linux-kernel, Jiri Kosina, linux-input, linux-usb
In-Reply-To: <op.v3q34la3dsdv5o@localhost>
On 10/22/2011 05:42 AM, Denilson Figueiredo de Sá wrote:
> It may even happen to send an out-of-range value for one axis, but a
> valid value for another axis. The code should be prepared for that
> (ignore one, but keep the other).
In this case what should be used for the "invalid" axis value? The
previous value?
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com
^ permalink raw reply
* Re: Converting from Raid 5 to 6
From: Mathias Burén @ 2011-10-24 16:27 UTC (permalink / raw)
To: Michael Busby; +Cc: linux-raid
In-Reply-To: <CAFsPQ__G3j3CbMDJyYO7BaJrxnPi=MAZFiRfgbruzMhiCVQYag@mail.gmail.com>
On 24 October 2011 17:03, Michael Busby <michael.a.busby@gmail.com> wrote:
> should the speed be very slow when doing this progress, its a lot
> slower than a normal grow
>
> reshape = 1.2% (25006080/1953513984) finish=12481.8min speed=2574K/sec
>
> On 24 October 2011 15:11, Mathias Burén <mathias.buren@gmail.com> wrote:
>> On 24 October 2011 14:11, Michael Busby <michael.a.busby@gmail.com> wrote:
>>> At the moment i have a raid5 setup with 5 disks, i am looking to add a
>>> 6th disk and change from raid 5 to raid 6
>>>
>>> having looked at Neil's site i have found the following command, and
>>> just want to double check this is still the recommend way of
>>> converting
>>>
>>> mdadm --grow /dev/md0 --level=6 --raid-disks=6 --backup-file=/home/md.backup
>>>
>>> also would i need to add the extra disk before or after the command?
>>>
>>> cheers
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>> Hi,
>>
>> I grew my 6 disk RAID5 to a 7 disk RAID6. First, add the drive. Then
>> partition it as required. Then add the drive to the array (I think
>> it'll become a spare?). Then you can grow it.
>>
>> Make sure you're using the latest mdadm tools available.
>>
>> Regards,
>> Mathias
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
(please reply to the bottom of the email)
What CPU are you using? What are the min/max kbps settings on the md
device? What does top (or htop) show you?
/M
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [U-Boot] [PATCH] [BUG] arm, lib: fix compile breakage
From: Albert ARIBAUD @ 2011-10-24 16:28 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319434952-10971-1-git-send-email-hs@denx.de>
Hi Heiko,
Le 24/10/2011 07:42, Heiko Schocher a ?crit :
> since commit dc8bbea0170eb2aca428ea221c91fc2e5e11f199 building
> arch/arm/lib/board.c breaks if CONFIG_CMD_NET is defined.
> Fix this.
>
> Signed-off-by: Heiko Schocher<hs@denx.de>
> Cc: Albert ARIBAUD<albert.u.boot@aribaud.net>
> Cc: Simon Glass<sjg@chromium.org>
> ---
> arch/arm/lib/board.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
> index ad02dbd..c1a3f2c 100644
> --- a/arch/arm/lib/board.c
> +++ b/arch/arm/lib/board.c
> @@ -440,6 +440,9 @@ void board_init_r(gd_t *id, ulong dest_addr)
> #if !defined(CONFIG_SYS_NO_FLASH)
> ulong flash_size;
> #endif
> +#if defined(CONFIG_CMD_NET)
> + char *s;
> +#endif
>
> gd = id;
>
Applied to u-boot-arm/master, thanks.
Amicalement,
--
Albert.
^ permalink raw reply
* Re: [PATCH 1/2] LSM: Do not apply mmap_min_addr check to PROT_NONE mappings
From: Roland McGrath @ 2011-10-24 16:28 UTC (permalink / raw)
To: Eric Paris
Cc: Linus Torvalds, Andrew Morton, James Morris, Stephen Smalley,
selinux, John Johansen, linux-security-module, linux-kernel
In-Reply-To: <1319468868.3280.9.camel@localhost>
> I feel like, and it's just a very vague feeling, that the PROT bits
> didn't matter to the kernel. It would still happily execute stuff on
> page 0 even without PROT_EXEC at some point in the past. I'm probably
> totally off base, and I could test it, but I sort of feel like I
> remember something like that....
Saying that PROT_EXEC might not be enforced is quite a different thing than
saying "PROT bits don't matter". It's certainly the case that in some past
kernel versions, some hardware (older x86 chips), some configurations (x86
non-PAE), and some modes (READ_IMPLIES_EXEC personality stuff), what you
can read, you can execute. I sincerely doubt it's ever been the case that
anything mapped as PROT_NONE could be accessed in any manner.
Thanks,
Roland
^ permalink raw reply
* [GIT PULL] 9p changes fro merge window
From: Eric Van Hensbergen @ 2011-10-24 16:28 UTC (permalink / raw)
To: Linus Torvalds, V9FS Developers, linux-kernel
The following changes since commit c3b92c8787367a8bb53d57d9789b558f1295cc96:
Linux 3.1 (2011-10-24 09:10:05 +0200)
are available in the git repository at:
git://github.com/ericvh/linux.git for-next
Aneesh Kumar K.V (4):
fs/9p: Update zero-copy implementation in 9p
fs/9p: inode file operation is properly initialized init_special_inode
fs/9p: Cleanup option parsing in 9p
net/9p: Convert net/9p protocol dumps to tracepoints
Dan Carpenter (2):
9p: move dereference after NULL check
fs/9p: change an int to unsigned int
Nicolae Mogoreanu (1):
9p: fix 9p.txt to advertise msize instead of maxdata
Documentation/filesystems/9p.txt | 2 +-
fs/9p/v9fs.c | 33 ++-
fs/9p/vfs_dir.c | 14 +-
fs/9p/vfs_inode.c | 2 -
include/net/9p/9p.h | 14 +-
include/net/9p/client.h | 8 +-
include/net/9p/transport.h | 10 +-
include/trace/events/9p.h | 176 ++++++++++++++
net/9p/client.c | 469 +++++++++++++++++++++++++++-----------
net/9p/protocol.c | 99 +-------
net/9p/protocol.h | 4 +-
net/9p/trans_common.c | 53 ++---
net/9p/trans_common.h | 21 +--
net/9p/trans_virtio.c | 319 +++++++++++++++-----------
14 files changed, 772 insertions(+), 452 deletions(-)
create mode 100644 include/trace/events/9p.h
^ permalink raw reply
* Re: Converting from Raid 5 to 6
From: Michael Busby @ 2011-10-24 16:34 UTC (permalink / raw)
To: Mathias Burén; +Cc: linux-raid
In-Reply-To: <CADNH=7GEL2SabyRM_FYJHyGEJ5eibobwzmH=iKzibF-Tkt25kw@mail.gmail.com>
On 24 October 2011 17:27, Mathias Burén <mathias.buren@gmail.com> wrote:
> On 24 October 2011 17:03, Michael Busby <michael.a.busby@gmail.com> wrote:
>> should the speed be very slow when doing this progress, its a lot
>> slower than a normal grow
>>
>> reshape = 1.2% (25006080/1953513984) finish=12481.8min speed=2574K/sec
>>
>> On 24 October 2011 15:11, Mathias Burén <mathias.buren@gmail.com> wrote:
>>> On 24 October 2011 14:11, Michael Busby <michael.a.busby@gmail.com> wrote:
>>>> At the moment i have a raid5 setup with 5 disks, i am looking to add a
>>>> 6th disk and change from raid 5 to raid 6
>>>>
>>>> having looked at Neil's site i have found the following command, and
>>>> just want to double check this is still the recommend way of
>>>> converting
>>>>
>>>> mdadm --grow /dev/md0 --level=6 --raid-disks=6 --backup-file=/home/md.backup
>>>>
>>>> also would i need to add the extra disk before or after the command?
>>>>
>>>> cheers
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>> Hi,
>>>
>>> I grew my 6 disk RAID5 to a 7 disk RAID6. First, add the drive. Then
>>> partition it as required. Then add the drive to the array (I think
>>> it'll become a spare?). Then you can grow it.
>>>
>>> Make sure you're using the latest mdadm tools available.
>>>
>>> Regards,
>>> Mathias
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> (please reply to the bottom of the email)
>
> What CPU are you using? What are the min/max kbps settings on the md
> device? What does top (or htop) show you?
>
> /M
>
Its a AMD 1.3ghz, in a HP microserver
max = 2000000
min = 200000
top - 17:33:49 up 4 days, 18:57, 2 users, load average: 1.19, 1.32, 1.34
Tasks: 102 total, 1 running, 101 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.3%us, 4.8%sy, 0.0%ni, 61.6%id, 32.9%wa, 0.0%hi, 0.3%si, 0.0%st
Mem: 2958840k total, 2519944k used, 438896k free, 140868k buffers
Swap: 3143676k total, 376112k used, 2767564k free, 1122084k cached
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 7/9] ib_srpt: Convert srp_max_rdma_size into per port configfs attribute
From: Bart Van Assche @ 2011-10-24 16:34 UTC (permalink / raw)
To: Nicholas A. Bellinger; +Cc: linux-rdma, Roland Dreier, Christoph Hellwig
In-Reply-To: <1319434422-15354-8-git-send-email-nab-IzHhD5pYlfBP7FQvKIMDCQ@public.gmane.org>
On Mon, Oct 24, 2011 at 7:33 AM, Nicholas A. Bellinger
<nab-IzHhD5pYlfBP7FQvKIMDCQ@public.gmane.org> wrote:
> This patch converts the srp_max_rdma_size module parameter into a per
> endpoint configfs attribute. This includes adding the necessary bits
> for show + store attributes w/ min/max bounds checking, and updating
> srpt_get_ioc() to accept a struct srpt_port parameter.
>
> [ ... ]
>
> -static void srpt_get_ioc(struct srpt_device *sdev, u32 slot,
> +static void srpt_get_ioc(struct srpt_port *sport, u32 slot,
> struct ib_dm_mad *mad)
The SRP spec says that there should be only one value for
iocp->rdma_size per I/O controller. This patch breaks that rule. I'm
not sure it's a good idea to introduce such behavior changes.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [U-Boot] [PATCH 1/2] rtc: Make mc13783-rtc driver generic
From: Fabio Estevam @ 2011-10-24 16:37 UTC (permalink / raw)
To: u-boot
Rename mc13783-rtc so that it can be used for both MC13783 and MC13892 PMICs.
efikamx board, for example, does use a MC13892 PMIC, but the RTC selection is currently made as:
#define CONFIG_RTC_MC13783
,which is not very obvious.
Let the MC13783 and MC13892 RTC be selected by:
#define CONFIG_RTC_MC13XXX
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
README | 2 +-
drivers/rtc/Makefile | 2 +-
include/configs/efikamx.h | 2 +-
include/configs/imx31_litekit.h | 2 +-
include/configs/mx31ads.h | 2 +-
include/configs/mx31pdk.h | 2 +-
include/configs/qong.h | 2 +-
include/configs/vision2.h | 2 +-
8 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/README b/README
index eb9ade9..1e20452 100644
--- a/README
+++ b/README
@@ -841,7 +841,7 @@ The following options need to be configured:
CONFIG_RTC_MPC8xx - use internal RTC of MPC8xx
CONFIG_RTC_PCF8563 - use Philips PCF8563 RTC
- CONFIG_RTC_MC13783 - use MC13783 RTC
+ CONFIG_RTC_MC13XXX - use MC13783 or MC13892 RTC
CONFIG_RTC_MC146818 - use MC146818 RTC
CONFIG_RTC_DS1307 - use Maxim, Inc. DS1307 RTC
CONFIG_RTC_DS1337 - use Maxim, Inc. DS1337 RTC
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index df440c6..a16f590 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -50,7 +50,7 @@ COBJS-$(CONFIG_RTC_M41T62) += m41t62.o
COBJS-$(CONFIG_RTC_M41T94) += m41t94.o
COBJS-$(CONFIG_RTC_M48T35A) += m48t35ax.o
COBJS-$(CONFIG_RTC_MAX6900) += max6900.o
-COBJS-$(CONFIG_RTC_MC13783) += mc13783-rtc.o
+COBJS-$(CONFIG_RTC_MC13XXX) += mc13xxx-rtc.o
COBJS-$(CONFIG_RTC_MC146818) += mc146818.o
COBJS-$(CONFIG_MCFRTC) += mcfrtc.o
COBJS-$(CONFIG_RTC_MK48T59) += mk48t59.o
diff --git a/include/configs/efikamx.h b/include/configs/efikamx.h
index 7e4b424..68bede9 100644
--- a/include/configs/efikamx.h
+++ b/include/configs/efikamx.h
@@ -132,7 +132,7 @@
#define CONFIG_FSL_PMIC_CLK 25000000
#define CONFIG_FSL_PMIC_MODE (SPI_MODE_0 | SPI_CS_HIGH)
#define CONFIG_FSL_PMIC_BITLEN 32
-#define CONFIG_RTC_MC13783
+#define CONFIG_RTC_MC13XXX
#endif
/*
diff --git a/include/configs/imx31_litekit.h b/include/configs/imx31_litekit.h
index 89e71c0..1455ea2 100644
--- a/include/configs/imx31_litekit.h
+++ b/include/configs/imx31_litekit.h
@@ -81,7 +81,7 @@
#define CONFIG_FSL_PMIC_CLK 1000000
#define CONFIG_FSL_PMIC_MODE (SPI_MODE_0 | SPI_CS_HIGH)
#define CONFIG_FSL_PMIC_BITLEN 32
-#define CONFIG_RTC_MC13783
+#define CONFIG_RTC_MC13XXX
/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
diff --git a/include/configs/mx31ads.h b/include/configs/mx31ads.h
index c9d80ef..7e011ae 100644
--- a/include/configs/mx31ads.h
+++ b/include/configs/mx31ads.h
@@ -78,7 +78,7 @@
#define CONFIG_FSL_PMIC_CLK 1000000
#define CONFIG_FSL_PMIC_MODE (SPI_MODE_0 | SPI_CS_HIGH)
#define CONFIG_FSL_PMIC_BITLEN 32
-#define CONFIG_RTC_MC13783
+#define CONFIG_RTC_MC13XXX
/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
diff --git a/include/configs/mx31pdk.h b/include/configs/mx31pdk.h
index b72f30b..9d64827 100644
--- a/include/configs/mx31pdk.h
+++ b/include/configs/mx31pdk.h
@@ -79,7 +79,7 @@
#define CONFIG_FSL_PMIC_CLK 1000000
#define CONFIG_FSL_PMIC_MODE (SPI_MODE_0 | SPI_CS_HIGH)
#define CONFIG_FSL_PMIC_BITLEN 32
-#define CONFIG_RTC_MC13783
+#define CONFIG_RTC_MC13XXX
/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
diff --git a/include/configs/qong.h b/include/configs/qong.h
index 4820914..4409186 100644
--- a/include/configs/qong.h
+++ b/include/configs/qong.h
@@ -58,7 +58,7 @@
#define CONFIG_MXC_SPI
#define CONFIG_DEFAULT_SPI_BUS 1
#define CONFIG_DEFAULT_SPI_MODE (SPI_MODE_0 | SPI_CS_HIGH)
-#define CONFIG_RTC_MC13783
+#define CONFIG_RTC_MC13XXX
#define CONFIG_PMIC
#define CONFIG_PMIC_SPI
diff --git a/include/configs/vision2.h b/include/configs/vision2.h
index a2a9f3f..5a4cd66 100644
--- a/include/configs/vision2.h
+++ b/include/configs/vision2.h
@@ -95,7 +95,7 @@
#define CONFIG_FSL_PMIC_CLK 2500000
#define CONFIG_FSL_PMIC_MODE SPI_MODE_0
#define CONFIG_FSL_PMIC_BITLEN 32
-#define CONFIG_RTC_MC13783
+#define CONFIG_RTC_MC13XXX
/*
* MMC Configs
--
1.6.0.4
^ permalink raw reply related
* [U-Boot] [PATCH 2/2] mx51evk: Add RTC support
From: Fabio Estevam @ 2011-10-24 16:37 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319474257-11851-1-git-send-email-fabio.estevam@freescale.com>
MX51EVK has a MC13892 PMIC. Add RTC support.
Tested via 'date' command that reads the PMIC RTC registers:
MX51EVK U-Boot > date
Date: 1970-01-01 (Thursday) Time: 0:40:35
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
include/configs/mx51evk.h | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h
index 2c449b8..67b5f0b 100644
--- a/include/configs/mx51evk.h
+++ b/include/configs/mx51evk.h
@@ -79,6 +79,7 @@
#define CONFIG_FSL_PMIC_CLK 2500000
#define CONFIG_FSL_PMIC_MODE (SPI_MODE_0 | SPI_CS_HIGH)
#define CONFIG_FSL_PMIC_BITLEN 32
+#define CONFIG_RTC_MC13XXX
/*
* MMC Configs
@@ -124,6 +125,8 @@
#undef CONFIG_CMD_IMLS
+#define CONFIG_CMD_DATE
+
#define CONFIG_BOOTDELAY 3
#define CONFIG_ETHPRIME "FEC0"
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH v0] fast-import: Add drop command
From: Vitor Antunes @ 2011-10-24 16:37 UTC (permalink / raw)
To: Dmitry Ivankov, Jonathan Nieder; +Cc: git, Sverre Rabbelier, David Barr
In-Reply-To: <CAOpHH-WSyD23GKtZ2nLiSsJfLU-+7ibyGhGccyvtAhKQ-jffBw@mail.gmail.com>
Hi,
This thread did not receive any updates for a long time.
Could someone provide some feedback?
Is this feasible? Does it make sense to add this command? If not, why?
Thanks,
Vitor
On Tue, Sep 27, 2011 at 9:57 AM, Vitor Antunes <vitor.hda@gmail.com> wrote:
> On Sat, Sep 24, 2011 at 10:19 PM, Dmitry Ivankov <divanorama@gmail.com> wrote:
>> On Sun, Sep 25, 2011 at 1:37 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>>> Thanks. I must have missed the earlier discussion. What are the
>>> semantics of this command and its intended purpose?
>> My guess is that if fast-import is used to manage a set of "remote"
>> branches, it should be able to delete branches. Then, it should
>> be allowed to do non-fastforward updates too (--force). Why can't
>> it just ignore branches deletion (considering --force)?
>
> I started by using --force, but I did not want to completely disable
> these checks. The idea of the drop command is to add support to the
> exceptions that require non-fastforward updates.
>
>> Random thoughts:
>> 1. once 'drop' is executed, fast-import can't tell if the branch was
>> actually deleted. And moreover any attempt to read this branch
>> head becomes illegal (either it's missing in .git or fast-import is
>> instructed to use a dropped branch).
>> 2. 'reset' command is a bit like proposed 'drop' but it never deletes
>> a branch ref. Consider following imports:
>> 1) import branch topic
>> 2) reset topic
>> 3) import branch topic2 starting at topic (incorrect import)
>> If 1-3) is done in one fast-import process, the error is reported.
>> If 3) is done separately, it succeeds but the result is strange:
>> topic2 isn't started from scratch but from old "erased" topic.
>> So, maybe, reset should be fixed to erase branches on --force.
>
> I think you are not considering the possibility that checkpoints could
> have been done along the way. I use them frequently to be able to
> analyse branches with diff-tree. As soon as a checkpoint is done,
> update-branches will issue an error (commit A is not part of branch A').
>
>> One more scenario is:
>> 1) import topic
>> 2) reset topic
>> 3) import topic
>> If 1-3) go together - no error
>> If 3) goes separate - no error, but non-fastforward update.
>> Much more harmless, but still may look strange.
>
> Not exactly true if there is a checkpoint done after step 1.
>
> My scenario is:
>
> 1) import topic
> 2) checkpoint
> 3) diff-tree and processing
> 4) exit if processing returns ok
> 5) reset topic to another HEAD
> 6) goto 1)
^ permalink raw reply
* Re: [PATCH 1/1] hob: fix backtrace when dismissing open dialog
From: Richard Purdie @ 2011-10-24 16:32 UTC (permalink / raw)
To: Joshua Lock; +Cc: bitbake-devel
In-Reply-To: <db59297aa1861614ffaea4295b9b054baa8a12b9.1318353511.git.josh@linux.intel.com>
On Tue, 2011-10-11 at 10:20 -0700, Joshua Lock wrote:
> Clearly a logic/indentation error - we should only try and load the recipe
> should the file-chooser return OK.
>
> Fixes [YOCTO #1668]
>
> Signed-off-by: Joshua Lock <josh@linux.intel.com>
> ---
> lib/bb/ui/hob.py | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
Merged to master, thanks.
Richard
^ permalink raw reply
* Re: Linux USB HID should ignore values outside Logical Minimum/Maximum range
From: Denilson Figueiredo de Sá @ 2011-10-24 16:39 UTC (permalink / raw)
To: Chris Friesen; +Cc: linux-kernel, Jiri Kosina, linux-input, linux-usb
In-Reply-To: <4EA5913D.7090004@genband.com>
On Mon, Oct 24, 2011 at 14:24, Chris Friesen <chris.friesen@genband.com> wrote:
> On 10/22/2011 05:42 AM, Denilson Figueiredo de Sá wrote:
>
>> It may even happen to send an out-of-range value for one axis, but a
>> valid value for another axis. The code should be prepared for that
>> (ignore one, but keep the other).
>
> In this case what should be used for the "invalid" axis value? The previous
> value?
If that's an absolute pointing device, can we supply only one axis? I
mean, can we do this: "move the pointer to this X position, but leave
the Y position where it currently is". (note that the pointer might
have moved since last input from this device, due to other devices
also being present)
If that's not possible, then I'm not sure about what should be the
correct behavior. Should we ignore both axes if one of them is
invalid? Should we use the last good value from the other axis? (note
that relative pointing devices like proper mice shouldn't have this
issue, as we can just use zero for invalid values, which means "no
movement")
I haven't tested that on Windows (yet), so I don't know how it
behaves. If I test it, I'll post my results here.
I know, this is a corner case difficult to decide about.
By the way, my report was about absolute pointing devices, but I
haven't tested how Linux USB HID behaves for other kinds of devices
(keyboards, gamepads, anything else).
--
Denilson Figueiredo de Sá
Rio de Janeiro - Brasil
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Linux USB HID should ignore values outside Logical Minimum/Maximum range
From: Denilson Figueiredo de Sá @ 2011-10-24 16:39 UTC (permalink / raw)
To: Chris Friesen; +Cc: linux-kernel, Jiri Kosina, linux-input, linux-usb
In-Reply-To: <4EA5913D.7090004@genband.com>
On Mon, Oct 24, 2011 at 14:24, Chris Friesen <chris.friesen@genband.com> wrote:
> On 10/22/2011 05:42 AM, Denilson Figueiredo de Sá wrote:
>
>> It may even happen to send an out-of-range value for one axis, but a
>> valid value for another axis. The code should be prepared for that
>> (ignore one, but keep the other).
>
> In this case what should be used for the "invalid" axis value? The previous
> value?
If that's an absolute pointing device, can we supply only one axis? I
mean, can we do this: "move the pointer to this X position, but leave
the Y position where it currently is". (note that the pointer might
have moved since last input from this device, due to other devices
also being present)
If that's not possible, then I'm not sure about what should be the
correct behavior. Should we ignore both axes if one of them is
invalid? Should we use the last good value from the other axis? (note
that relative pointing devices like proper mice shouldn't have this
issue, as we can just use zero for invalid values, which means "no
movement")
I haven't tested that on Windows (yet), so I don't know how it
behaves. If I test it, I'll post my results here.
I know, this is a corner case difficult to decide about.
By the way, my report was about absolute pointing devices, but I
haven't tested how Linux USB HID behaves for other kinds of devices
(keyboards, gamepads, anything else).
--
Denilson Figueiredo de Sá
Rio de Janeiro - Brasil
^ permalink raw reply
* Re: A question on IOCTL interface for MMC
From: Chris Ball @ 2011-10-24 16:39 UTC (permalink / raw)
To: Shashidhar Hiremath; +Cc: Arnd Bergmann, J Freyensee, John Calixto, linux-mmc
In-Reply-To: <CANYdXnoS31GLnbFcwj76SUoyVhcti8Q-4_5fmyRy3DUJGbSRjg@mail.gmail.com>
Hi,
On Mon, Oct 24 2011, Shashidhar Hiremath wrote:
> As explained in previous mail, the IOCTL is actually an inteface to
> block layer and it is only expecting read/write commands to be sent
> through the interface.The prrof of it can be seen in write_flag
> present in the IOCTL structure which indicates the either the command
> can be read or a write command.
Please just try it, using an arbitrary write_flag.
Thanks,
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* [Buildroot] [RFC] Slides "Using Buildroot for real projects"
From: Yann E. MORIN @ 2011-10-24 16:42 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20111024173250.7e598d6f@skate>
Thomas, All,
On Monday 24 October 2011 17:32:50 Thomas Petazzoni wrote:
> Le Sun, 23 Oct 2011 14:37:55 +0200,
> Baruch Siach <baruch@tkos.co.il> a ?crit :
>
> > 1. Slide 23: missing -e in the 'echo' command
> >
> > $ echo "/dev/mtdblock7\t\t/applog\tjffs2\tdefaults\t\t0\t0"
> > /dev/mtdblock7\t\t/applog\tjffs2\tdefaults\t\t0\t0
> >
> > $ echo -e "/dev/mtdblock7\t\t/applog\tjffs2\tdefaults\t\t0\t0"
> > /dev/mtdblock7 /applog jffs2 defaults 0 0
>
> -e is not needed with sh:
The problem is that /bin/sh might be whatever. With a POSIX-conformant
/bin/sh (eg. dash), this is true. With bash, it is not. Alas, many
systems still have bash as /bin/sh.
$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 May 17 23:53 /bin/sh -> bash
$ echo "bli\nbla"
bli\nbla
$ /bin/bash
$ echo "bli\nbla"
bli\nbla
$ exit
$ /bin/dash
$ echo "bli\nbla"
bli
bla
The answer it to use printf [0].
I now use printf as much as I can. printf is in POSIX and does not suffer
from all the discrepancies there are in the many echo implementations.
> $ echo "bla\nbli"
> bla
> bli
> $ echo -e "bla\nbli"
> -e bla
> bli
[0] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/printf.html
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply
* Re: [PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write
From: Marek Olšák @ 2011-10-24 16:42 UTC (permalink / raw)
To: Thomas Hellstrom; +Cc: dri-devel
In-Reply-To: <4E9034E7.8070701@shipmail.org>
On Sat, Oct 8, 2011 at 1:32 PM, Thomas Hellstrom <thomas@shipmail.org> wrote:
> On 10/08/2011 01:27 PM, Ville Syrjälä wrote:
>>
>> On Sat, Oct 08, 2011 at 01:10:13PM +0200, Thomas Hellstrom wrote:
>>
>>>
>>> On 10/08/2011 12:26 PM, Ville Syrjälä wrote:
>>>
>>>>
>>>> On Fri, Oct 07, 2011 at 10:58:13AM +0200, Thomas Hellstrom wrote:
>>>>
>>>>
>>>>>
>>>>> Oh, and one more style comment below:
>>>>>
>>>>> On 08/07/2011 10:39 PM, Marek Olšák wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> +enum ttm_buffer_usage {
>>>>>> + TTM_USAGE_READ = 1,
>>>>>> + TTM_USAGE_WRITE = 2,
>>>>>> + TTM_USAGE_READWRITE = TTM_USAGE_READ | TTM_USAGE_WRITE
>>>>>> +};
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Please don't use enums for bit operations.
>>>>>
>>>>>
>>>>
>>>> Now I'm curious. Why not?
>>>>
>>>>
>>>>
>>>
>>> Because it's inconsistent with how flags are defined in the rest of the
>>> TTM module.
>>>
>>
>> Ah OK. I was wondering if there's some subtle technical issue involved.
>> I've recently gotten to the habit of using enums for pretty much all
>> constants. Just easier on the eye IMHO, and avoids cpp output from
>> looking like number soup.
>>
>>
>
> Yes, there are a number of advantages, including symbolic debugger output.
> If we had flag enums that enumerated 1, 2, 4, 8 etc. I'd feel motivated to
> move
> all TTM definitions over.
I don't think that how it is enumerated matters in any way. What I
like about enums, besides what has already been mentioned, is that it
adds a self-documentation in the code. Compare:
void ttm_set_bo_flags(unsigned flags);
And:
void ttm_set_bo_flags(enum ttm_bo_flags flags);
The latter is way easier to understand for somebody who doesn't know
the code and wants to implement his first patch. With the latter, it's
clear at first glance what are the valid values for "flags", because
you can just search for "enum ttm_bo_flags".
I will change the enum to defines for the sake of following your code
style convention, but it's an unreasonable convention to say the
least.
Marek
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [U-Boot] [PATCH v2 1/2] rtc: Make mc13783-rtc driver generic
From: Fabio Estevam @ 2011-10-24 16:44 UTC (permalink / raw)
To: u-boot
Rename mc13783-rtc so that it can be used for both MC13783 and MC13892 PMICs.
efikamx board, for example, does use a MC13892 PMIC, but the RTC selection is currently made as:
#define CONFIG_RTC_MC13783
,which is not very obvious.
Let the MC13783 and MC13892 RTC be selected by:
#define CONFIG_RTC_MC13XXX
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
Changes since v1:
- Properly handle the file rename via git.
README | 2 +-
drivers/rtc/Makefile | 2 +-
drivers/rtc/{mc13783-rtc.c => mc13xxx-rtc.c} | 0
include/configs/efikamx.h | 2 +-
include/configs/imx31_litekit.h | 2 +-
include/configs/mx31ads.h | 2 +-
include/configs/mx31pdk.h | 2 +-
include/configs/qong.h | 2 +-
include/configs/vision2.h | 2 +-
9 files changed, 8 insertions(+), 8 deletions(-)
rename drivers/rtc/{mc13783-rtc.c => mc13xxx-rtc.c} (100%)
diff --git a/README b/README
index eb9ade9..1e20452 100644
--- a/README
+++ b/README
@@ -841,7 +841,7 @@ The following options need to be configured:
CONFIG_RTC_MPC8xx - use internal RTC of MPC8xx
CONFIG_RTC_PCF8563 - use Philips PCF8563 RTC
- CONFIG_RTC_MC13783 - use MC13783 RTC
+ CONFIG_RTC_MC13XXX - use MC13783 or MC13892 RTC
CONFIG_RTC_MC146818 - use MC146818 RTC
CONFIG_RTC_DS1307 - use Maxim, Inc. DS1307 RTC
CONFIG_RTC_DS1337 - use Maxim, Inc. DS1337 RTC
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index df440c6..a16f590 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -50,7 +50,7 @@ COBJS-$(CONFIG_RTC_M41T62) += m41t62.o
COBJS-$(CONFIG_RTC_M41T94) += m41t94.o
COBJS-$(CONFIG_RTC_M48T35A) += m48t35ax.o
COBJS-$(CONFIG_RTC_MAX6900) += max6900.o
-COBJS-$(CONFIG_RTC_MC13783) += mc13783-rtc.o
+COBJS-$(CONFIG_RTC_MC13XXX) += mc13xxx-rtc.o
COBJS-$(CONFIG_RTC_MC146818) += mc146818.o
COBJS-$(CONFIG_MCFRTC) += mcfrtc.o
COBJS-$(CONFIG_RTC_MK48T59) += mk48t59.o
diff --git a/drivers/rtc/mc13783-rtc.c b/drivers/rtc/mc13xxx-rtc.c
similarity index 100%
rename from drivers/rtc/mc13783-rtc.c
rename to drivers/rtc/mc13xxx-rtc.c
diff --git a/include/configs/efikamx.h b/include/configs/efikamx.h
index 7e4b424..68bede9 100644
--- a/include/configs/efikamx.h
+++ b/include/configs/efikamx.h
@@ -132,7 +132,7 @@
#define CONFIG_FSL_PMIC_CLK 25000000
#define CONFIG_FSL_PMIC_MODE (SPI_MODE_0 | SPI_CS_HIGH)
#define CONFIG_FSL_PMIC_BITLEN 32
-#define CONFIG_RTC_MC13783
+#define CONFIG_RTC_MC13XXX
#endif
/*
diff --git a/include/configs/imx31_litekit.h b/include/configs/imx31_litekit.h
index 89e71c0..1455ea2 100644
--- a/include/configs/imx31_litekit.h
+++ b/include/configs/imx31_litekit.h
@@ -81,7 +81,7 @@
#define CONFIG_FSL_PMIC_CLK 1000000
#define CONFIG_FSL_PMIC_MODE (SPI_MODE_0 | SPI_CS_HIGH)
#define CONFIG_FSL_PMIC_BITLEN 32
-#define CONFIG_RTC_MC13783
+#define CONFIG_RTC_MC13XXX
/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
diff --git a/include/configs/mx31ads.h b/include/configs/mx31ads.h
index c9d80ef..7e011ae 100644
--- a/include/configs/mx31ads.h
+++ b/include/configs/mx31ads.h
@@ -78,7 +78,7 @@
#define CONFIG_FSL_PMIC_CLK 1000000
#define CONFIG_FSL_PMIC_MODE (SPI_MODE_0 | SPI_CS_HIGH)
#define CONFIG_FSL_PMIC_BITLEN 32
-#define CONFIG_RTC_MC13783
+#define CONFIG_RTC_MC13XXX
/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
diff --git a/include/configs/mx31pdk.h b/include/configs/mx31pdk.h
index b72f30b..9d64827 100644
--- a/include/configs/mx31pdk.h
+++ b/include/configs/mx31pdk.h
@@ -79,7 +79,7 @@
#define CONFIG_FSL_PMIC_CLK 1000000
#define CONFIG_FSL_PMIC_MODE (SPI_MODE_0 | SPI_CS_HIGH)
#define CONFIG_FSL_PMIC_BITLEN 32
-#define CONFIG_RTC_MC13783
+#define CONFIG_RTC_MC13XXX
/* allow to overwrite serial and ethaddr */
#define CONFIG_ENV_OVERWRITE
diff --git a/include/configs/qong.h b/include/configs/qong.h
index 4820914..4409186 100644
--- a/include/configs/qong.h
+++ b/include/configs/qong.h
@@ -58,7 +58,7 @@
#define CONFIG_MXC_SPI
#define CONFIG_DEFAULT_SPI_BUS 1
#define CONFIG_DEFAULT_SPI_MODE (SPI_MODE_0 | SPI_CS_HIGH)
-#define CONFIG_RTC_MC13783
+#define CONFIG_RTC_MC13XXX
#define CONFIG_PMIC
#define CONFIG_PMIC_SPI
diff --git a/include/configs/vision2.h b/include/configs/vision2.h
index a2a9f3f..5a4cd66 100644
--- a/include/configs/vision2.h
+++ b/include/configs/vision2.h
@@ -95,7 +95,7 @@
#define CONFIG_FSL_PMIC_CLK 2500000
#define CONFIG_FSL_PMIC_MODE SPI_MODE_0
#define CONFIG_FSL_PMIC_BITLEN 32
-#define CONFIG_RTC_MC13783
+#define CONFIG_RTC_MC13XXX
/*
* MMC Configs
--
1.6.0.4
^ permalink raw reply related
* [U-Boot] [PATCH v2 2/2] mx51evk: Add RTC support
From: Fabio Estevam @ 2011-10-24 16:44 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319474656-12172-1-git-send-email-fabio.estevam@freescale.com>
MX51EVK has a MC13892 PMIC. Add RTC support.
Tested via 'date' command that reads the PMIC RTC registers:
MX51EVK U-Boot > date
Date: 1970-01-01 (Thursday) Time: 0:40:35
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
Changes since v1:
- No changes
include/configs/mx51evk.h | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h
index 2c449b8..67b5f0b 100644
--- a/include/configs/mx51evk.h
+++ b/include/configs/mx51evk.h
@@ -79,6 +79,7 @@
#define CONFIG_FSL_PMIC_CLK 2500000
#define CONFIG_FSL_PMIC_MODE (SPI_MODE_0 | SPI_CS_HIGH)
#define CONFIG_FSL_PMIC_BITLEN 32
+#define CONFIG_RTC_MC13XXX
/*
* MMC Configs
@@ -124,6 +125,8 @@
#undef CONFIG_CMD_IMLS
+#define CONFIG_CMD_DATE
+
#define CONFIG_BOOTDELAY 3
#define CONFIG_ETHPRIME "FEC0"
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH 0/2] Improve usability of checksums
From: Richard Purdie @ 2011-10-24 16:38 UTC (permalink / raw)
To: Joshua Lock; +Cc: bitbake-devel
In-Reply-To: <cover.1318352470.git.josh@linux.intel.com>
On Tue, 2011-10-11 at 10:07 -0700, Joshua Lock wrote:
> I'd heard some complaints around the usability of checksums and, having done
> some recipe work recently, must agree with them.
> This series ams to make using checksums less intrusive by:
>
> a) Removing the requirement that if one type of checksum is defined the other
> must be too.
> b) Reporting all sum mismatches at once
> c) Enabling sums to be defined as a parameter of a SRC_URI
>
> Regards,
> Joshua
>
> The following changes since commit dca46cc2e1c75b6add2c4801e2994a4812745f5b:
>
> fetch2: Export additional variables to the fetchers (2011-10-05 14:23:16 +0100)
>
> are available in the git repository at:
> git://github.com/incandescant/bitbake checksum
> https://github.com/incandescant/bitbake/tree/checksum
>
> Joshua Lock (2):
> fetch2: improve usability of checksums
> fetch2: enable checksum definition as SRC_URI parameter
Merged to master (or will be when I can actually push the changes).
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH-v2] ib_srpt: Initial SRP Target merge for v3.2-rc1
From: Bart Van Assche @ 2011-10-24 16:45 UTC (permalink / raw)
To: Nicholas A. Bellinger
Cc: linux-rdma, Roland Dreier, Christoph Hellwig, Vu Pham,
David Dillow
In-Reply-To: <1319435841-19046-1-git-send-email-nab-IzHhD5pYlfBP7FQvKIMDCQ@public.gmane.org>
On Mon, Oct 24, 2011 at 7:57 AM, Nicholas A. Bellinger
<nab-IzHhD5pYlfBP7FQvKIMDCQ@public.gmane.org> wrote:
> This v2 patch adds the kernel module ib_srpt SCSI RDMA Protocol (SRP) target
> implementation conforming to the SRP r16a specification for the mainline
> drivers/target infrastructure.
>
> This driver was originally developed by Vu Pham and has been optimized by
> Bart Van Assche and merged into upstream LIO based on his srpt-lio-4.1 branch.
> This patch is made against the current pending target-core changes for
> v3.2-rc1, the full tree is available here:
Maybe you remember that the reason why I developed this patch was to
be able to run performance measurements ? The following changes are
necessary to convert this patch into a robust kernel driver:
- Handle the case where the last WQE event arrives before the
corresponding queue pair is reset (r3870 in the SCST SVN repo).
- Handle IB completion timeouts. Although the InfiniBand Architecture
Manual specifies that a HCA must generate an error completion for each
pending work item when a queue pair reset is issued, an important
class of HCAs doesn't do this (that includes the HCA in your test
setup). In the SCST version of this driver such timeouts are handled
by the function srpt_pending_cmd_timeout().
Both issues mentioned above can lead to sessions not being cleaned up
properly and hence all future logins from the initiator associated
with that session to be blocked.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is 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.