* Re: [patch 3/5] mm: try to distribute dirty pages fairly across zones
From: Wu Fengguang @ 2011-10-31 11:33 UTC (permalink / raw)
To: Johannes Weiner
Cc: Michal Hocko, Andrew Morton, Mel Gorman, Christoph Hellwig,
Dave Chinner, Jan Kara, Rik van Riel, Minchan Kim, Chris Mason,
Theodore Ts'o, Andreas Dilger, Li, Shaohua, xfs@oss.sgi.com,
linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20111028201829.GA20607@localhost>
> //regression
> 3) much increased cpu %user and %system for btrfs
Sorry I find out that the CPU time regressions for btrfs are caused by
some additional trace events enabled on btrfs (for debugging an
unrelated btrfs hang bug) which results in 7 times more trace event
lines:
2701238 /export/writeback/thresh=1000M/btrfs-1dd-4k-8p-2941M-1000M:10-3.1.0-rc9-ioless-full-nfs-wq5-next-20111014+
19054054 /export/writeback/thresh=1000M/btrfs-1dd-4k-8p-2941M-1000M:10-3.1.0-rc9-ioless-full-per-zone-dirty-next-20111014+
So no real regressions.
Besides, the patchset also performs good on random writes:
3.1.0-rc9-ioless-full-nfs-wq5-next-20111014+ 3.1.0-rc9-ioless-full-per-zone-dirty-next-20111014+
------------------------ ------------------------
1.65 -5.1% 1.57 MMAP-RANDWRITE-4K/btrfs-fio_fat_mmap_randwrite_4k-4k-8p-4096M-20:10-X
18.65 -6.4% 17.46 MMAP-RANDWRITE-4K/ext3-fio_fat_mmap_randwrite_4k-4k-8p-4096M-20:10-X
2.09 +1.2% 2.12 MMAP-RANDWRITE-4K/ext4-fio_fat_mmap_randwrite_4k-4k-8p-4096M-20:10-X
2.49 -0.3% 2.48 MMAP-RANDWRITE-4K/xfs-fio_fat_mmap_randwrite_4k-4k-8p-4096M-20:10-X
51.35 +0.0% 51.36 MMAP-RANDWRITE-64K/btrfs-fio_fat_mmap_randwrite_64k-64k-8p-4096M-20:10-X
45.20 +0.5% 45.43 MMAP-RANDWRITE-64K/ext3-fio_fat_mmap_randwrite_64k-64k-8p-4096M-20:10-X
44.77 +0.7% 45.10 MMAP-RANDWRITE-64K/ext4-fio_fat_mmap_randwrite_64k-64k-8p-4096M-20:10-X
45.11 +2.5% 46.23 MMAP-RANDWRITE-64K/xfs-fio_fat_mmap_randwrite_64k-64k-8p-4096M-20:10-X
211.31 +0.2% 211.74 TOTAL write_bw
And writes to USB key:
3.1.0-rc9-ioless-full-nfs-wq5-next-20111014+ 3.1.0-rc9-ioless-full-per-zone-dirty-next-20111014+
------------------------ ------------------------
5.94 +0.8% 5.99 UKEY-thresh=1G/btrfs-1dd-4k-8p-4096M-1024M:10-X
2.64 -0.8% 2.62 UKEY-thresh=1G/ext3-10dd-4k-8p-4096M-1024M:10-X
5.10 +0.3% 5.12 UKEY-thresh=1G/ext3-1dd-4k-8p-4096M-1024M:10-X
3.26 -0.8% 3.24 UKEY-thresh=1G/ext3-2dd-4k-8p-4096M-1024M:10-X
5.63 -0.5% 5.60 UKEY-thresh=1G/ext4-10dd-4k-8p-4096M-1024M:10-X
6.04 -0.1% 6.04 UKEY-thresh=1G/ext4-1dd-4k-8p-4096M-1024M:10-X
5.90 -0.2% 5.88 UKEY-thresh=1G/ext4-2dd-4k-8p-4096M-1024M:10-X
2.45 +22.6% 3.00 UKEY-thresh=1G/xfs-10dd-4k-8p-4096M-1024M:10-X
6.18 -0.4% 6.16 UKEY-thresh=1G/xfs-1dd-4k-8p-4096M-1024M:10-X
4.81 +0.0% 4.81 UKEY-thresh=1G/xfs-2dd-4k-8p-4096M-1024M:10-X
47.94 +1.1% 48.45 TOTAL write_bw
In summary, I see no problem at all in these trivial writeback tests.
Tested-by: Wu Fengguang <fengguang.wu@intel.com>
Thanks,
Fengguang
^ permalink raw reply
* Re: [patch 3/5] mm: try to distribute dirty pages fairly across zones
From: Wu Fengguang @ 2011-10-31 11:33 UTC (permalink / raw)
To: Johannes Weiner
Cc: Christoph Hellwig, Rik van Riel, Jan Kara,
linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org,
xfs@oss.sgi.com, Michal Hocko, linux-mm@kvack.org, Andreas Dilger,
Mel Gorman, Li, Shaohua, linux-fsdevel@vger.kernel.org,
Theodore Ts'o, Andrew Morton, linux-ext4@vger.kernel.org,
Chris Mason, Minchan Kim
In-Reply-To: <20111028201829.GA20607@localhost>
> //regression
> 3) much increased cpu %user and %system for btrfs
Sorry I find out that the CPU time regressions for btrfs are caused by
some additional trace events enabled on btrfs (for debugging an
unrelated btrfs hang bug) which results in 7 times more trace event
lines:
2701238 /export/writeback/thresh=1000M/btrfs-1dd-4k-8p-2941M-1000M:10-3.1.0-rc9-ioless-full-nfs-wq5-next-20111014+
19054054 /export/writeback/thresh=1000M/btrfs-1dd-4k-8p-2941M-1000M:10-3.1.0-rc9-ioless-full-per-zone-dirty-next-20111014+
So no real regressions.
Besides, the patchset also performs good on random writes:
3.1.0-rc9-ioless-full-nfs-wq5-next-20111014+ 3.1.0-rc9-ioless-full-per-zone-dirty-next-20111014+
------------------------ ------------------------
1.65 -5.1% 1.57 MMAP-RANDWRITE-4K/btrfs-fio_fat_mmap_randwrite_4k-4k-8p-4096M-20:10-X
18.65 -6.4% 17.46 MMAP-RANDWRITE-4K/ext3-fio_fat_mmap_randwrite_4k-4k-8p-4096M-20:10-X
2.09 +1.2% 2.12 MMAP-RANDWRITE-4K/ext4-fio_fat_mmap_randwrite_4k-4k-8p-4096M-20:10-X
2.49 -0.3% 2.48 MMAP-RANDWRITE-4K/xfs-fio_fat_mmap_randwrite_4k-4k-8p-4096M-20:10-X
51.35 +0.0% 51.36 MMAP-RANDWRITE-64K/btrfs-fio_fat_mmap_randwrite_64k-64k-8p-4096M-20:10-X
45.20 +0.5% 45.43 MMAP-RANDWRITE-64K/ext3-fio_fat_mmap_randwrite_64k-64k-8p-4096M-20:10-X
44.77 +0.7% 45.10 MMAP-RANDWRITE-64K/ext4-fio_fat_mmap_randwrite_64k-64k-8p-4096M-20:10-X
45.11 +2.5% 46.23 MMAP-RANDWRITE-64K/xfs-fio_fat_mmap_randwrite_64k-64k-8p-4096M-20:10-X
211.31 +0.2% 211.74 TOTAL write_bw
And writes to USB key:
3.1.0-rc9-ioless-full-nfs-wq5-next-20111014+ 3.1.0-rc9-ioless-full-per-zone-dirty-next-20111014+
------------------------ ------------------------
5.94 +0.8% 5.99 UKEY-thresh=1G/btrfs-1dd-4k-8p-4096M-1024M:10-X
2.64 -0.8% 2.62 UKEY-thresh=1G/ext3-10dd-4k-8p-4096M-1024M:10-X
5.10 +0.3% 5.12 UKEY-thresh=1G/ext3-1dd-4k-8p-4096M-1024M:10-X
3.26 -0.8% 3.24 UKEY-thresh=1G/ext3-2dd-4k-8p-4096M-1024M:10-X
5.63 -0.5% 5.60 UKEY-thresh=1G/ext4-10dd-4k-8p-4096M-1024M:10-X
6.04 -0.1% 6.04 UKEY-thresh=1G/ext4-1dd-4k-8p-4096M-1024M:10-X
5.90 -0.2% 5.88 UKEY-thresh=1G/ext4-2dd-4k-8p-4096M-1024M:10-X
2.45 +22.6% 3.00 UKEY-thresh=1G/xfs-10dd-4k-8p-4096M-1024M:10-X
6.18 -0.4% 6.16 UKEY-thresh=1G/xfs-1dd-4k-8p-4096M-1024M:10-X
4.81 +0.0% 4.81 UKEY-thresh=1G/xfs-2dd-4k-8p-4096M-1024M:10-X
47.94 +1.1% 48.45 TOTAL write_bw
In summary, I see no problem at all in these trivial writeback tests.
Tested-by: Wu Fengguang <fengguang.wu@intel.com>
Thanks,
Fengguang
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* [U-Boot] [BREAKAGE] gplugd board / armada100_fec
From: Marek Vasut @ 2011-10-31 11:33 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1451501677.280874.1320040341365.JavaMail.root@ahm.einfochips.com>
> ----- "Marek Vasut" <marek.vasut@gmail.com> wrote:
> > Dear Ajay Bhargav,
> >
> > I compiled the "gplugd" board and I got the following warnings, please
> > fix.
> >
> > Configuring for gplugd board...
> > armada100_fec.c: In function 'armdfec_init':
> > armada100_fec.c:483:2: warning: dereferencing type-punned pointer will
> > break
> > strict-aliasing rules
> > armada100_fec.c:484:2: warning: dereferencing type-punned pointer will
> > break
> > strict-aliasing rules
> > armada100_fec.c: In function 'armdfec_recv':
> > armada100_fec.c:670:2: warning: dereferencing type-punned pointer will
> > break
> > strict-aliasing rules
> > gplugd.c: In function 'board_init':
> > gplugd.c:95:27: error: 'MACH_TYPE_SHEEVAD' undeclared (first use in
> > this
> > function)
> > gplugd.c:95:27: note: each undeclared identifier is reported only once
> > for each
> > function it appears in
> >
> > Cheers
>
> Hi Marek,
>
> May I know what version of gcc are you using?
ELDK4.2 and ELDK5.0
so gcc4.2 and 4.6, but I include you a testcase (edit path to armada100_fec.h).
gcc -m32 -Wall -fstrict-aliasing -o test2 test2.c ; ./test2
>
> I will fix the MACH_TYPE_SHEEVAD as suggested by Albert.
>
> Regards,
> Ajay Bhargav
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test2.c
Type: text/x-csrc
Size: 504 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111031/76e373d7/attachment.c
^ permalink raw reply
* Re: [patch 3/5] mm: try to distribute dirty pages fairly across zones
From: Wu Fengguang @ 2011-10-31 11:33 UTC (permalink / raw)
To: Johannes Weiner
Cc: Michal Hocko, Andrew Morton, Mel Gorman, Christoph Hellwig,
Dave Chinner, Jan Kara, Rik van Riel, Minchan Kim, Chris Mason,
Theodore Ts'o, Andreas Dilger, Li, Shaohua, xfs@oss.sgi.com,
linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20111028201829.GA20607@localhost>
> //regression
> 3) much increased cpu %user and %system for btrfs
Sorry I find out that the CPU time regressions for btrfs are caused by
some additional trace events enabled on btrfs (for debugging an
unrelated btrfs hang bug) which results in 7 times more trace event
lines:
2701238 /export/writeback/thresh=1000M/btrfs-1dd-4k-8p-2941M-1000M:10-3.1.0-rc9-ioless-full-nfs-wq5-next-20111014+
19054054 /export/writeback/thresh=1000M/btrfs-1dd-4k-8p-2941M-1000M:10-3.1.0-rc9-ioless-full-per-zone-dirty-next-20111014+
So no real regressions.
Besides, the patchset also performs good on random writes:
3.1.0-rc9-ioless-full-nfs-wq5-next-20111014+ 3.1.0-rc9-ioless-full-per-zone-dirty-next-20111014+
------------------------ ------------------------
1.65 -5.1% 1.57 MMAP-RANDWRITE-4K/btrfs-fio_fat_mmap_randwrite_4k-4k-8p-4096M-20:10-X
18.65 -6.4% 17.46 MMAP-RANDWRITE-4K/ext3-fio_fat_mmap_randwrite_4k-4k-8p-4096M-20:10-X
2.09 +1.2% 2.12 MMAP-RANDWRITE-4K/ext4-fio_fat_mmap_randwrite_4k-4k-8p-4096M-20:10-X
2.49 -0.3% 2.48 MMAP-RANDWRITE-4K/xfs-fio_fat_mmap_randwrite_4k-4k-8p-4096M-20:10-X
51.35 +0.0% 51.36 MMAP-RANDWRITE-64K/btrfs-fio_fat_mmap_randwrite_64k-64k-8p-4096M-20:10-X
45.20 +0.5% 45.43 MMAP-RANDWRITE-64K/ext3-fio_fat_mmap_randwrite_64k-64k-8p-4096M-20:10-X
44.77 +0.7% 45.10 MMAP-RANDWRITE-64K/ext4-fio_fat_mmap_randwrite_64k-64k-8p-4096M-20:10-X
45.11 +2.5% 46.23 MMAP-RANDWRITE-64K/xfs-fio_fat_mmap_randwrite_64k-64k-8p-4096M-20:10-X
211.31 +0.2% 211.74 TOTAL write_bw
And writes to USB key:
3.1.0-rc9-ioless-full-nfs-wq5-next-20111014+ 3.1.0-rc9-ioless-full-per-zone-dirty-next-20111014+
------------------------ ------------------------
5.94 +0.8% 5.99 UKEY-thresh=1G/btrfs-1dd-4k-8p-4096M-1024M:10-X
2.64 -0.8% 2.62 UKEY-thresh=1G/ext3-10dd-4k-8p-4096M-1024M:10-X
5.10 +0.3% 5.12 UKEY-thresh=1G/ext3-1dd-4k-8p-4096M-1024M:10-X
3.26 -0.8% 3.24 UKEY-thresh=1G/ext3-2dd-4k-8p-4096M-1024M:10-X
5.63 -0.5% 5.60 UKEY-thresh=1G/ext4-10dd-4k-8p-4096M-1024M:10-X
6.04 -0.1% 6.04 UKEY-thresh=1G/ext4-1dd-4k-8p-4096M-1024M:10-X
5.90 -0.2% 5.88 UKEY-thresh=1G/ext4-2dd-4k-8p-4096M-1024M:10-X
2.45 +22.6% 3.00 UKEY-thresh=1G/xfs-10dd-4k-8p-4096M-1024M:10-X
6.18 -0.4% 6.16 UKEY-thresh=1G/xfs-1dd-4k-8p-4096M-1024M:10-X
4.81 +0.0% 4.81 UKEY-thresh=1G/xfs-2dd-4k-8p-4096M-1024M:10-X
47.94 +1.1% 48.45 TOTAL write_bw
In summary, I see no problem at all in these trivial writeback tests.
Tested-by: Wu Fengguang <fengguang.wu@intel.com>
Thanks,
Fengguang
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH] ip= server-id should be server-IP
From: Anton Blanchard @ 2011-10-31 11:30 UTC (permalink / raw)
To: initramfs-u79uwXL29TY76Z2rM5mHXA
From looking at the code it seems like server-id should really
be named server-IP.
---
Index: dracut/dracut.kernel.7.xml
===================================================================
--- dracut.orig/dracut.kernel.7.xml 2011-10-31 21:12:55.371535209 +1100
+++ dracut/dracut.kernel.7.xml 2011-10-31 21:13:32.100192208 +1100
@@ -445,7 +445,7 @@ with a valid DHCP root-path.</para>
</varlistentry>
<varlistentry>
<term><envar>ip=</envar><replaceable><client-IP></replaceable>:
- <replaceable><server-id></replaceable>
+ <replaceable><server-IP></replaceable>
:<replaceable><gateway-IP></replaceable>:<replaceable><netmask></replaceable>:<replaceable><client_hostname></replaceable>:<replaceable><interface></replaceable>:<replaceable>{none|off}</replaceable></term>
<listitem>
<para>explicit network configuration. If you want do define a IPv6 address, put it in brackets (e.g. [2001:DB8::1]).
Index: dracut/modules.d/40network/parse-ip-opts.sh
===================================================================
--- dracut.orig/modules.d/40network/parse-ip-opts.sh 2011-10-31 21:12:59.875615777 +1100
+++ dracut/modules.d/40network/parse-ip-opts.sh 2011-10-31 21:13:38.132300111 +1100
@@ -7,7 +7,7 @@
#
# ip=<interface>:[dhcp|on|any]
#
-# ip=<client-IP-number>:<server-id>:<gateway-IP-number>:<netmask>:<client-hostname>:<interface>:[dhcp|on|any|none|off]
+# ip=<client-IP-number>:<server-IP-number>:<gateway-IP-number>:<netmask>:<client-hostname>:<interface>:[dhcp|on|any|none|off]
#
# When supplying more than only ip= line, <interface> is mandatory and
# bootdev= must contain the name of the primary interface to use for
^ permalink raw reply
* [PATCH] server-id in ip= is not optional
From: Anton Blanchard @ 2011-10-31 11:29 UTC (permalink / raw)
To: initramfs-u79uwXL29TY76Z2rM5mHXA
The documentation suggests that server-id is an optional argument
but ip_to_var fails if it is not specified. Fix the documentation.
---
diff --git a/dracut.kernel.7.xml b/dracut.kernel.7.xml
index 7cd7b81..990797e 100644
--- a/dracut.kernel.7.xml
+++ b/dracut.kernel.7.xml
@@ -444,9 +444,9 @@ with a valid DHCP root-path.</para>
</listitem>
</varlistentry>
<varlistentry>
- <term><envar>ip=</envar><replaceable><client-IP></replaceable>:<optional>
+ <term><envar>ip=</envar><replaceable><client-IP></replaceable>:
<replaceable><server-id></replaceable>
- </optional>:<replaceable><gateway-IP></replaceable>:<replaceable><netmask></replaceable>:<replaceable><client_hostname></replaceable>:<replaceable><interface></replaceable>:<replaceable>{none|off}</replaceable></term>
+ :<replaceable><gateway-IP></replaceable>:<replaceable><netmask></replaceable>:<replaceable><client_hostname></replaceable>:<replaceable><interface></replaceable>:<replaceable>{none|off}</replaceable></term>
<listitem>
<para>explicit network configuration. If you want do define a IPv6 address, put it in brackets (e.g. [2001:DB8::1]).
This parameter can be specified multiple times.</para>
^ permalink raw reply related
* [U-Boot] [PATCH] ehci-mxc: remove incorrect comment
From: Stefano Babic @ 2011-10-31 11:29 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4E9C714B.50003@grandegger.com>
On 10/17/2011 08:17 PM, Wolfgang Grandegger wrote:
> The USB port to be used is determined by CONFIG_MXC_USB_PORT.
> So, it appears that the comment is not correct. Remove it.
>
> Signed-off-by: Wolfgang Grandegger <wg@denx.de>
> ---
> drivers/usb/host/ehci-mxc.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
Applied to u-boot-imx, thanks.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* [U-Boot] [BREAKAGE] gplugd board / armada100_fec
From: Ajay Bhargav @ 2011-10-31 11:29 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201110311233.25610.marek.vasut@gmail.com>
----- "Marek Vasut" <marek.vasut@gmail.com> wrote:
> > ----- "Marek Vasut" <marek.vasut@gmail.com> wrote:
> > > Dear Ajay Bhargav,
> > >
> > > I compiled the "gplugd" board and I got the following warnings,
> please
> > > fix.
> > >
> > > Configuring for gplugd board...
> > > armada100_fec.c: In function 'armdfec_init':
> > > armada100_fec.c:483:2: warning: dereferencing type-punned pointer
> will
> > > break
> > > strict-aliasing rules
> > > armada100_fec.c:484:2: warning: dereferencing type-punned pointer
> will
> > > break
> > > strict-aliasing rules
> > > armada100_fec.c: In function 'armdfec_recv':
> > > armada100_fec.c:670:2: warning: dereferencing type-punned pointer
> will
> > > break
> > > strict-aliasing rules
> > > gplugd.c: In function 'board_init':
> > > gplugd.c:95:27: error: 'MACH_TYPE_SHEEVAD' undeclared (first use
> in
> > > this
> > > function)
> > > gplugd.c:95:27: note: each undeclared identifier is reported only
> once
> > > for each
> > > function it appears in
> > >
> > > Cheers
> >
> > Hi Marek,
> >
> > May I know what version of gcc are you using?
>
> ELDK4.2 and ELDK5.0
>
> so gcc4.2 and 4.6, but I include you a testcase (edit path to
> armada100_fec.h).
>
> gcc -m32 -Wall -fstrict-aliasing -o test2 test2.c ; ./test2
>
> >
> > I will fix the MACH_TYPE_SHEEVAD as suggested by Albert.
> >
> > Regards,
> > Ajay Bhargav
>
Can you please check the patch I have just sent? I have cc it to you too.
Regards,
Ajay Bhargav
^ permalink raw reply
* [PATCH] Handle upper case MAC addresses in ifname option
From: Anton Blanchard @ 2011-10-31 11:28 UTC (permalink / raw)
To: initramfs-u79uwXL29TY76Z2rM5mHXA
While the documentation states that ifname MAC addresses must be
lower case, we silently accept upper case ones and fail later on
when udev doesn't rename the device.
Instead of adding sanity checking on the MAC address just convert
it to lower case and remove the requirement completely.
---
Index: dracut/modules.d/40network/parse-ifname.sh
===================================================================
--- dracut.orig/modules.d/40network/parse-ifname.sh 2011-10-31 21:35:17.107601600 +1100
+++ dracut/modules.d/40network/parse-ifname.sh 2011-10-31 21:35:18.199621240 +1100
@@ -25,7 +25,8 @@ parse_ifname_opts() {
case $# in
7)
ifname_if=$1
- ifname_mac=$2:$3:$4:$5:$6:$7
+ # udev requires MAC addresses to be lower case
+ ifname_mac=`echo $2:$3:$4:$5:$6:$7 | tr '[:upper:]' '[:lower:]'`
;;
*)
die "Invalid arguments for ifname="
Index: dracut/dracut.kernel.7.xml
===================================================================
--- dracut.orig/dracut.kernel.7.xml 2011-10-31 21:58:49.353246994 +1100
+++ dracut/dracut.kernel.7.xml 2011-10-31 22:05:47.840887387 +1100
@@ -456,7 +456,6 @@ This parameter can be specified multiple
<term><envar>ifname=</envar><replaceable><interface></replaceable>:<replaceable><MAC></replaceable></term>
<listitem>
<para>Assign network device name <interface> (ie eth0) to the NIC with MAC <MAC>.
-Note letters in the MAC-address must be lowercase!
<remark>Note: If you use this option you <emphasis remap="B">must</emphasis> specify an ifname= argument for all interfaces used in ip= or fcoe= arguments.</remark>
This parameter can be specified multiple times.</para>
</listitem>
^ permalink raw reply
* [PULL] au8522/s4h1409/s4h1411: Calculate signal strength shown as percentage from SNR up to 35dB
From: Michael Krufky @ 2011-10-31 11:28 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: linux-media
In-Reply-To: <CAOcJUbxTLAtQFa3s5FMUKp2MgX6FCmheN930xWp2xYTD8oApzw@mail.gmail.com>
(resent with missing [PULL] tag in subject line)
Mauro,
Please pull from my atscdemod branch at
git://linuxtv.org/mkrufky/tuners . These changesets bring au8522,
s5h1409, and s5h1411 up to speed with the other ATSC demodulator
drivers to all report signal strength in a single conforming way. We
all agreed on this at the LPC over two years ago, and these patches
have been sitting in my hg tree since then, I've just completely
forgotten to issue this pull request. LGDT3305 and LGDT330X drivers
already report signal strength this way. Userspace developers have
been patiently waiting for this merge - I apologize to them for
sitting on it for so long. Please merge this :-)
The following changes since commit a63366b935456dd0984f237642f6d4001dcf8017:
[media] mxl111sf: update demod_ops.info.name to "MaxLinear MxL111SF
DVB-T demodulator" (2011-10-24 03:20:09 +0200)
are available in the git repository at:
git://linuxtv.org/mkrufky/tuners atscdemod
Michael Krufky (3):
au8522: Calculate signal strength shown as percentage from SNR up to 35dB
s5h1409: Calculate signal strength shown as percentage from SNR up to 35dB
s5h1411: Calculate signal strength shown as percentage from SNR up to 35dB
drivers/media/dvb/frontends/au8522_dig.c | 31 +++++++++++++++++++++++++++++-
drivers/media/dvb/frontends/s5h1409.c | 31 +++++++++++++++++++++++++++++-
drivers/media/dvb/frontends/s5h1411.c | 31 +++++++++++++++++++++++++++++-
3 files changed, 90 insertions(+), 3 deletions(-)
Best regards,
Michael Krufky
^ permalink raw reply
* [U-Boot] [PATCH] Update s3c24x0 timer implementation
From: Mark Norman @ 2011-10-31 11:27 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201110241558.36834.marek.vasut@gmail.com>
Hi Marek Vasut,
>>
>> 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.
>
Thanks for your feedback. I have submitted an updated patch using git
send-email. I think I got the formatting right this time. :)
>>
>> 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?
I have declared some bitfields to remove the magic numbers.
>
>> +
>> + ? ? /* 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?
I haven't addressed this in my latest patch as it would be quite a
large change that I though might be worthy of its own patch (there are
several related functions get_FCLK, get_HCLK, etc. which could be
updated at the same time).
>> 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 ...
>
The latest patch no longer creates new variables in the global_data
struct and instead reuses some of the existing ones.
Any more feedback would be welcomed.
Cheers
Mark Norman
^ permalink raw reply
* Re: Problems with 'xl create winxp' (hvm) on xen 4.1.2 (also affects GPLPV)
From: Ian Campbell @ 2011-10-31 11:26 UTC (permalink / raw)
To: jim burns; +Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com
In-Reply-To: <1320058232.23193.59.camel@zakaz.uk.xensource.com>
On Mon, 2011-10-31 at 10:50 +0000, Ian Campbell wrote:
> On Sat, 2011-10-29 at 06:57 +0100, jim burns wrote:
> > Setup:
> >
> > Fedora 15, w/f16's 3.1.0 (also tried 2.6.40 & 3.0.0)
> > xen 4.1.2 (newly upgraded from 4.1.1, from rawhide)
> >
> > Since the release notes for 4.1.2 said, in part:
> >
> > Fixes/features include:
> > * New XL toolstack
> >
> > I decided to test some problems I saw using xl to start a winxp hvm domu under
> > xen 4.1.1, and found that they were still there, and I came up with a somewhat
> > more serious one as well. I'm sure that others can point out more serious
> > problems, but these are the ones that affect me. In all cases, 'xm create'
> > does not have these problems. Domu config at the end of the post.
> >
> > New to 4.1.2:
> >
> > 1) Starting winxp with xl does not create a vif interface - only a tap one.
> > More exactly, the vif is created, but does not get an ipv6 address - it shows
> > up in 'ifconfig -a', or 'ifconfig vifn.0' - and does not get added to the
> > bridge. If you are using James' GPLPV drivers, you end up with no network
> > connectivity, as they use vif, not tap. I'd be surprised if other pvhvm
> > solutions don't see this also.
>
> I see this with the tip of xen-4.1-testing too but not with
> xen-unstable. I'll see if I can figure out which backport is missing...
23047:4ca13a170482 "libxl: provide full path to vif hotplug script
script" seems like a very plausible candidate, I bet
"script=/etc/xen/scripts/vif-bridge" would function as a workaround.
> [...]
> > 2) If your vif= line in your config specifies a bridge, such as
> > 'bridge=virbr0', the '-net tap' option to qemu-dm remains as 'bridge=xenbr0',
> > as if it was hard coded. Again, this is an hvm problem. 'xl create'-ing a pv
> > domu correctly puts the vif on the requested bridge. (If memory serves, under
> > xen 4.1.1, when the vif for an hvm domain was being put on a bridge, I believe
> > it was on the bridge requested, so the problem is just with tap.)
>
> Similarly I can reproduce this too but only on 4.1.
Actually this one is broken in unstable too.
The handling of leading and trailing whitespace in the vif option seems
to be completely b0rked in xl and e.g. "bridge = virbr1" ends up as key
"bridge " and key " virbr1". That entire parser (actually, both of them
-- there's a whole nother one in main_networkattach!) is a mess.
There's probably a bandaid which can be applied but really the whole
thing need ripping out and making sensible.
As a workaround in the meantime you can probably avoid whitespace around
the "=" and "," in the vif line.
Ian.
^ permalink raw reply
* au8522/s4h1409/s4h1411: Calculate signal strength shown as percentage from SNR up to 35dB
From: Michael Krufky @ 2011-10-31 11:25 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: linux-media
Mauro,
Please pull from my atscdemod branch at
git://linuxtv.org/mkrufky/tuners . These changesets bring au8522,
s5h1409, and s5h1411 up to speed with the other ATSC demodulator
drivers to all report signal strength in a single conforming way. We
all agreed on this at the LPC over two years ago, and these patches
have been sitting in my hg tree since then, I've just completely
forgotten to issue this pull request. LGDT3305 and LGDT330X drivers
already report signal strength this way. Userspace developers have
been patiently waiting for this merge - I apologize to them for
sitting on it for so long. Please merge this :-)
The following changes since commit a63366b935456dd0984f237642f6d4001dcf8017:
[media] mxl111sf: update demod_ops.info.name to "MaxLinear MxL111SF
DVB-T demodulator" (2011-10-24 03:20:09 +0200)
are available in the git repository at:
git://linuxtv.org/mkrufky/tuners atscdemod
Michael Krufky (3):
au8522: Calculate signal strength shown as percentage from SNR up to 35dB
s5h1409: Calculate signal strength shown as percentage from SNR up to 35dB
s5h1411: Calculate signal strength shown as percentage from SNR up to 35dB
drivers/media/dvb/frontends/au8522_dig.c | 31 +++++++++++++++++++++++++++++-
drivers/media/dvb/frontends/s5h1409.c | 31 +++++++++++++++++++++++++++++-
drivers/media/dvb/frontends/s5h1411.c | 31 +++++++++++++++++++++++++++++-
3 files changed, 90 insertions(+), 3 deletions(-)
Best regards,
Michael Krufky
^ permalink raw reply
* Re: powerpc 476, Little-endian, pte fault
From: Benjamin Herrenschmidt @ 2011-10-31 11:23 UTC (permalink / raw)
To: Michael Neuling; +Cc: Santosh Kumar, linuxppc-dev, Ian Munsie, linux-kernel
In-Reply-To: <20440.1320054588@neuling.org>
On Mon, 2011-10-31 at 20:49 +1100, Michael Neuling wrote:
> > I have built a cross compiler for ppc440 in little endian mode and
> > using it to build the kernel.
> >
> > Yes i am running Linux in Little-Endian. This is the first user space
> > process. I wrote the below program and running it as init from
> > /sbin/init. I have also set the permissions with chmod +s.
> >
> > main()
> > {
> >
> > while(1){
> > printf("hello world");
> > sleep(1);
> > }
> > }
>
> Does libc even support little endian on PPC?
Ian did a port a while back for uClibc, is that at least partially based
on it ?
> > I have attached the patch.
>
> This is a pretty huge patch:
>
> 115 files changed, 44479 insertions(+), 7398 deletions(-)
>
> It seems to include a new platform as well as a bunch of unrelated junk.
>
> I suggest you need to break this down into something more digestible.
> Like remove all the junk in the patch. Then add the support for the new
> platform (invader? platform). Then start looking at little endian.
> Unless you do this, it's unlikely anyone here is going to be able to
> help.
>
> When you get to the little endian work, you might want to take a look at
> this patch series from Ian Munsie:
>
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-October/086165.html
Right, the new patch should be if possible based on Ian's series or at
least a cleaned / rebased variant of it. Then split in bits so we can
review it properly.
Cheers,
Ben.
> Mikey
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: powerpc 476, Little-endian, pte fault
From: Benjamin Herrenschmidt @ 2011-10-31 11:23 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, Ian Munsie, Santosh Kumar, linux-kernel
In-Reply-To: <20440.1320054588@neuling.org>
On Mon, 2011-10-31 at 20:49 +1100, Michael Neuling wrote:
> > I have built a cross compiler for ppc440 in little endian mode and
> > using it to build the kernel.
> >
> > Yes i am running Linux in Little-Endian. This is the first user space
> > process. I wrote the below program and running it as init from
> > /sbin/init. I have also set the permissions with chmod +s.
> >
> > main()
> > {
> >
> > while(1){
> > printf("hello world");
> > sleep(1);
> > }
> > }
>
> Does libc even support little endian on PPC?
Ian did a port a while back for uClibc, is that at least partially based
on it ?
> > I have attached the patch.
>
> This is a pretty huge patch:
>
> 115 files changed, 44479 insertions(+), 7398 deletions(-)
>
> It seems to include a new platform as well as a bunch of unrelated junk.
>
> I suggest you need to break this down into something more digestible.
> Like remove all the junk in the patch. Then add the support for the new
> platform (invader? platform). Then start looking at little endian.
> Unless you do this, it's unlikely anyone here is going to be able to
> help.
>
> When you get to the little endian work, you might want to take a look at
> this patch series from Ian Munsie:
>
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-October/086165.html
Right, the new patch should be if possible based on Ian's series or at
least a cleaned / rebased variant of it. Then split in bits so we can
review it properly.
Cheers,
Ben.
> Mikey
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: kernel panic
From: Thomas Renninger @ 2011-10-31 12:24 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: nick bray, linux-kernel, linux-acpi, lenb, Zhao Yakui, Zhang Rui
In-Reply-To: <201110280413.51751.trenn@suse.de>
On Friday 28 October 2011 04:13:50 Thomas Renninger wrote:
...
> Ah, maybe an older acpidump got used and the _CST method of the
> object is in a not exported, dynamically loaded SSDT.
> This is very likely.
>
> Please use a very recent acpidump:
> Hm, Len's ftp directory on kernel.org where latest acpidump was
> located is gone?
I've put a (hopefully) recent acpidump source here:
ftp.suse.com/pub/people/trenn/acpidump
Should get available in an hour or so.
I expect you see:
"Dynamic OEM Table Load"
message(s) in dmesg and the SSDT which includes the ACPI parts which are
causing this is loaded at runtime. Older acpidump versions were not able
to extract these, the one I put on my ftp account should be able to.
Can you run it and put the output somewhere (related Ubuntu bug?) and
provide a pointer to it, please.
Hm, you could create a bug here:
http://acpica.org/bugzilla
It looks like ACPI code in the _CST function is triggering an ACPICA
interpreter memory bug when it tries to evaluate the func (guessing...).
Thomas
^ permalink raw reply
* [Bug 42280] NVc0 generation card (0x0c1000a1) not working
From: bugzilla-daemon-CC+yJ3UmIYqDUpFQwHEjaQ @ 2011-10-31 11:23 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <bug-42280-8800-V0hAGp6uBxMKqLRl/0Ahz6D7qz1kEfGD2LY78lusg7I@public.gmane.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=42280
--- Comment #10 from Bruno Antunes <sardaukar.siet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2011-10-31 04:23:32 PDT ---
I'm using the 3.1 kernel from last Wednesday... it only works with
"nouveau.noaccel=0"
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: [patch] Staging: iio/dac/ad5064.c: signedness bug in ad5064_read_raw()
From: Jonathan Cameron @ 2011-10-31 11:22 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Dan Carpenter, Greg Kroah-Hartman, linux-iio, devel,
kernel-janitors
In-Reply-To: <4EAD2A97.8090103@metafoo.de>
On 10/30/11 10:44, Lars-Peter Clausen wrote:
> On 10/29/2011 09:20 AM, Dan Carpenter wrote:
>> regulator_get_voltage() returns an int so "scale_uv" should be an
>> int. Making it unsigned here breaks the error handling.
>>
>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> uhm, yes...
>
> Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
>
> Thanks.
>
>>
>> diff --git a/drivers/staging/iio/dac/ad5064.c b/drivers/staging/iio/dac/ad5064.c
>> index 24279f2..3b14526 100644
>> --- a/drivers/staging/iio/dac/ad5064.c
>> +++ b/drivers/staging/iio/dac/ad5064.c
>> @@ -280,8 +280,8 @@ static int ad5064_read_raw(struct iio_dev *indio_dev,
>> long m)
>> {
>> struct ad5064_state *st = iio_priv(indio_dev);
>> - unsigned long scale_uv;
>> unsigned int vref;
>> + int scale_uv;
>>
>> switch (m) {
>> case 0:
>
>
^ permalink raw reply
* Re: [patch] Staging: iio/dac/ad5360.c: signedness bug in ad5360_read_raw()
From: Jonathan Cameron @ 2011-10-31 11:22 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Dan Carpenter, Greg Kroah-Hartman, Michael Hennerich, linux-iio,
devel, kernel-janitors
In-Reply-To: <4EAD2AB4.1010009@metafoo.de>
On 10/30/11 10:45, Lars-Peter Clausen wrote:
> On 10/29/2011 09:21 AM, Dan Carpenter wrote:
>> ad5360_get_channel_vref() returns an int and scale_uv should be the
>> same. Making it unsigned here breaks the error handling.
>>
>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>>
>
> Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jonathan Cameron <jic23cam.ac.uk>
>
> Thanks.
>
>> diff --git a/drivers/staging/iio/dac/ad5360.c b/drivers/staging/iio/dac/ad5360.c
>> index 72d0f3f..cfeea72 100644
>> --- a/drivers/staging/iio/dac/ad5360.c
>> +++ b/drivers/staging/iio/dac/ad5360.c
>> @@ -371,8 +371,8 @@ static int ad5360_read_raw(struct iio_dev *indio_dev,
>> long m)
>> {
>> struct ad5360_state *st = iio_priv(indio_dev);
>> - unsigned long scale_uv;
>> unsigned int ofs_index;
>> + int scale_uv;
>> int ret;
>>
>> switch (m) {
>
>
^ permalink raw reply
* [U-Boot] [PATCH 2/2] ARM: remove superfluous setting of arch_number in board specific code.
From: David Müller @ 2011-10-31 11:22 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320060127-12300-1-git-send-email-d.mueller@elsoft.ch>
Signed-off-by: David Mueller <d.mueller@elsoft.ch>
---
board/mpl/vcma9/vcma9.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/board/mpl/vcma9/vcma9.c b/board/mpl/vcma9/vcma9.c
index e63625b..9f259c2 100644
--- a/board/mpl/vcma9/vcma9.c
+++ b/board/mpl/vcma9/vcma9.c
@@ -72,9 +72,6 @@ int board_early_init_f(void)
int board_init(void)
{
- /* arch number of VCMA9-Board */
- gd->bd->bi_arch_number = MACH_TYPE_MPL_VCMA9;
-
/* adress of boot parameters */
gd->bd->bi_boot_params = 0x30000100;
--
1.7.4.4
^ permalink raw reply related
* [U-Boot] [PATCH] qong: enable support for compressed images
From: Stefano Babic @ 2011-10-31 11:22 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319572096-1228-1-git-send-email-wd@denx.de>
On 10/25/2011 09:48 PM, Wolfgang Denk wrote:
> - enable support for unzip command
> - enable support for compressed bitmap images
>
> We also have to increase the malloc() arena a bit for this.
>
> Signed-off-by: Wolfgang Denk <wd@denx.de>
> Cc: Stefano Babic <sbabic@denx.de>
> ---
Applied to u-boot-imx, thanks.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* [U-Boot] [PATCH 1/2] ARM: re-add MACH_TYPE_XXXXXX for VCMA9 board and add CONFIG_MACH_TYPE
From: David Müller @ 2011-10-31 11:22 UTC (permalink / raw)
To: u-boot
Signed-off-by: David Mueller <d.mueller@elsoft.ch>
---
include/configs/VCMA9.h | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/include/configs/VCMA9.h b/include/configs/VCMA9.h
index 8b8113d..a370c15 100644
--- a/include/configs/VCMA9.h
+++ b/include/configs/VCMA9.h
@@ -29,6 +29,9 @@
#ifndef __CONFIG_H
#define __CONFIG_H
+
+#define MACH_TYPE_MPL_VCMA9 227
+
/*
* High Level Configuration Options
* (easy to change)
@@ -37,6 +40,7 @@
#define CONFIG_S3C24X0 /* in a SAMSUNG S3C24x0-type SoC */
#define CONFIG_S3C2410 /* specifically a SAMSUNG S3C2410 SoC */
#define CONFIG_VCMA9 /* on a MPL VCMA9 Board */
+#define CONFIG_MACH_TYPE MACH_TYPE_MPL_VCMA9 /* Machine type */
#define CONFIG_SYS_TEXT_BASE 0x0
--
1.7.4.4
^ permalink raw reply related
* Re: [meta-efl][meta-oe 06/12] liblinebreak: import from openembedded classic
From: Koen Kooi @ 2011-10-31 10:51 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <ff2c3e6a8645c6120d4770be1592e7644ab72ad2.1319884094.git.Martin.Jansa@gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Op 29-10-11 12:29, Martin Jansa schreef:
> From: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
>
> The License was verified and LIC_FILES_CHKSUM was added
>
> Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> Signed-off-by:
> Martin Jansa <Martin.Jansa@gmail.com> ---
> .../liblinebreak/liblinebreak_1.2.bb | 13 +++++++++++++ 1
> files changed, 13 insertions(+), 0 deletions(-) create mode 100644
> meta-oe/recipes-support/liblinebreak/liblinebreak_1.2.bb
>
> diff --git a/meta-oe/recipes-support/liblinebreak/liblinebreak_1.2.bb
> b/meta-oe/recipes-support/liblinebreak/liblinebreak_1.2.bb new file mode
> 100644 index 0000000..03c4352 --- /dev/null +++
> b/meta-oe/recipes-support/liblinebreak/liblinebreak_1.2.bb @@ -0,0 +1,13
> @@ +DESCRIPTION = "Liblinebreak is an implementation of the line breaking
> algorithm as described in Unicode 5.1.0 Standard Annex 14, Revision 22"
> +HOMEPAGE = "http://vimgadgets.sourceforge.net/liblinebreak/" +SECTION =
> "libs" +PRIORITY = "optional"
PRIORITY doesn't exist anymore, please remove it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org
iD8DBQFOrn2sMkyGM64RGpERAu9iAJ91VSMJHuLUIhyyyzYN1tBf+oJXoACghkzx
3dNmEJ54T5jOC5xz5zxIaUw=
=3L7G
-----END PGP SIGNATURE-----
^ permalink raw reply
* [U-Boot] [PATCH]: davinci: Replace CONFIG_PRELOADER with CONFIG_SPL_BUILD in board/davinci/common/misc.c
From: Heiko Schocher @ 2011-10-31 11:20 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20111031104437.GA20232@Hardy>
Hello Sughosh Ganu,
Sughosh Ganu wrote:
> On Mon Sep 19, 2011 at 01:00:25PM +0530, Sughosh Ganu wrote:
>> On Tue Sep 13, 2011 at 06:12:08PM +0530, Sughosh Ganu wrote:
>>> Make the conditional compilation in misc.c based on
>>> CONFIG_SPL_BUILD, replacing CONFIG_PRELOADER which was removed as part
>>> of commit 401bb30b6d.
>>>
>>> Making this change, we no longer need to compile memsize.c for
>>> hawkboard's nand_spl.
>>>
>>> Signed-off-by: Sughosh Ganu <urwithsughosh@gmail.com>
>>> ---
>>>
>>> Tested the changes on hawkboard.
>>> Build tested on davinci boards with a 'MAKEALL -v davinci'
>>>
>>>
>>> board/davinci/common/misc.c | 2 +-
>>> nand_spl/board/davinci/da8xxevm/Makefile | 6 ------
>>> 2 files changed, 1 insertions(+), 7 deletions(-)
>> Will this not go through ti next branch. I don't see this patch
>> included in the u-boot-ti/next pull request by Sandeep.
>
> Sandeep, can this be included in the ti tree. This has been pending
> for some time now. Thanks.
@Sandeep: if you apply this patch, can you please remove my patch
http://patchwork.ozlabs.org/patch/106983/
pending since 2011-07-27 from patchworks?
Thanks!
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [PATCH v2 3/3] staging:iio:dac: Add AD5421 driver
From: Jonathan Cameron @ 2011-10-31 11:28 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Michael Hennerich, linux-iio, device-drivers-devel, drivers
In-Reply-To: <1319705074-3082-3-git-send-email-lars@metafoo.de>
On 10/27/11 09:44, Lars-Peter Clausen wrote:
> This patch adds support for the Analog Devices AD5421 Loop-Powered, 4mA to 20mA
> DAC.
>
> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Acked-by: Jonathan Cameron <jic23@cam.ac.uk>
Feel free to send on to Greg as you've nailed everything I cared about.
I do wonder if we might be better with an explicit 'no_read' flag in the
chan_spec for channels like this. That way we could assign more meaningful
channel numbers? Afterall, sooner of later we are going to have something
with two temperature sensors that only generate events.
What do you think?
>
> ---
> Changes since v1:
> * Added lock to protect fault_mask
> * Use channel index -1 for the temperature channel
> * Explicitly initialize current_range in case of absent platform data
> * Minor code style cleanups
> ---
> drivers/staging/iio/dac/Kconfig | 10 +
> drivers/staging/iio/dac/Makefile | 1 +
> drivers/staging/iio/dac/ad5421.c | 555 ++++++++++++++++++++++++++++++++++++++
> drivers/staging/iio/dac/ad5421.h | 32 +++
> 4 files changed, 598 insertions(+), 0 deletions(-)
> create mode 100644 drivers/staging/iio/dac/ad5421.c
> create mode 100644 drivers/staging/iio/dac/ad5421.h
>
> diff --git a/drivers/staging/iio/dac/Kconfig b/drivers/staging/iio/dac/Kconfig
> index fac8549..0e8983a 100644
> --- a/drivers/staging/iio/dac/Kconfig
> +++ b/drivers/staging/iio/dac/Kconfig
> @@ -24,6 +24,16 @@ config AD5360
> To compile this driver as module choose M here: the module will be called
> ad5360.
>
> +config AD5421
> + tristate "Analog Devices AD5421 DAC driver"
> + depends on SPI
> + help
> + Say yes here to build support for Analog Devices AD5421 loop-powered
> + digital-to-analog convertors (DAC).
> +
> + To compile this driver as module choose M here: the module will be called
> + ad5421.
> +
> config AD5624R_SPI
> tristate "Analog Devices AD5624/44/64R DAC spi driver"
> depends on SPI
> diff --git a/drivers/staging/iio/dac/Makefile b/drivers/staging/iio/dac/Makefile
> index 07b6f5e..e75b0c8 100644
> --- a/drivers/staging/iio/dac/Makefile
> +++ b/drivers/staging/iio/dac/Makefile
> @@ -3,6 +3,7 @@
> #
>
> obj-$(CONFIG_AD5360) += ad5360.o
> +obj-$(CONFIG_AD5421) += ad5421.o
> obj-$(CONFIG_AD5624R_SPI) += ad5624r_spi.o
> obj-$(CONFIG_AD5064) += ad5064.o
> obj-$(CONFIG_AD5504) += ad5504.o
> diff --git a/drivers/staging/iio/dac/ad5421.c b/drivers/staging/iio/dac/ad5421.c
> new file mode 100644
> index 0000000..71ee868
> --- /dev/null
> +++ b/drivers/staging/iio/dac/ad5421.c
> @@ -0,0 +1,555 @@
> +/*
> + * AD5421 Digital to analog converters driver
> + *
> + * Copyright 2011 Analog Devices Inc.
> + *
> + * Licensed under the GPL-2.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/module.h>
> +#include <linux/interrupt.h>
> +#include <linux/kernel.h>
> +#include <linux/spi/spi.h>
> +#include <linux/slab.h>
> +#include <linux/sysfs.h>
> +
> +#include "../iio.h"
> +#include "../sysfs.h"
> +#include "../events.h"
> +#include "dac.h"
> +#include "ad5421.h"
> +
> +
> +#define AD5421_REG_DAC_DATA 0x1
> +#define AD5421_REG_CTRL 0x2
> +#define AD5421_REG_OFFSET 0x3
> +#define AD5421_REG_GAIN 0x4
> +/* load dac and fault shared the same register number. Writing to it will cause
> + * a dac load command, reading from it will return the fault status register */
> +#define AD5421_REG_LOAD_DAC 0x5
> +#define AD5421_REG_FAULT 0x5
> +#define AD5421_REG_FORCE_ALARM_CURRENT 0x6
> +#define AD5421_REG_RESET 0x7
> +#define AD5421_REG_START_CONVERSION 0x8
> +#define AD5421_REG_NOOP 0x9
> +
> +#define AD5421_CTRL_WATCHDOG_DISABLE BIT(12)
> +#define AD5421_CTRL_AUTO_FAULT_READBACK BIT(11)
> +#define AD5421_CTRL_MIN_CURRENT BIT(9)
> +#define AD5421_CTRL_ADC_SOURCE_TEMP BIT(8)
> +#define AD5421_CTRL_ADC_ENABLE BIT(7)
> +#define AD5421_CTRL_PWR_DOWN_INT_VREF BIT(6)
> +
> +#define AD5421_FAULT_SPI BIT(15)
> +#define AD5421_FAULT_PEC BIT(14)
> +#define AD5421_FAULT_OVER_CURRENT BIT(13)
> +#define AD5421_FAULT_UNDER_CURRENT BIT(12)
> +#define AD5421_FAULT_TEMP_OVER_140 BIT(11)
> +#define AD5421_FAULT_TEMP_OVER_100 BIT(10)
> +#define AD5421_FAULT_UNDER_VOLTAGE_6V BIT(9)
> +#define AD5421_FAULT_UNDER_VOLTAGE_12V BIT(8)
> +
> +/* These bits will cause the fault pin to go high */
> +#define AD5421_FAULT_TRIGGER_IRQ \
> + (AD5421_FAULT_SPI | AD5421_FAULT_PEC | AD5421_FAULT_OVER_CURRENT | \
> + AD5421_FAULT_UNDER_CURRENT | AD5421_FAULT_TEMP_OVER_140)
> +
> +/**
> + * struct ad5421_state - driver instance specific data
> + * @spi: spi_device
> + * @ctrl: control register cache
> + * @current_range: current range which the device is configured for
> + * @data: spi transfer buffers
> + * @fault_mask: software masking of events
> + */
> +struct ad5421_state {
> + struct spi_device *spi;
> + unsigned int ctrl;
> + enum ad5421_current_range current_range;
> + unsigned int fault_mask;
> +
> + /*
> + * DMA (thus cache coherency maintenance) requires the
> + * transfer buffers to live in their own cache lines.
> + */
> + union {
> + u32 d32;
> + u8 d8[4];
> + } data[2] ____cacheline_aligned;
> +};
> +
> +static const struct iio_chan_spec ad5421_channels[] = {
> + {
> + .type = IIO_CURRENT,
> + .indexed = 1,
> + .output = 1,
> + .channel = 0,
> + .info_mask = IIO_CHAN_INFO_SCALE_SHARED_BIT |
> + IIO_CHAN_INFO_OFFSET_SHARED_BIT |
> + IIO_CHAN_INFO_CALIBSCALE_SEPARATE_BIT |
> + IIO_CHAN_INFO_CALIBBIAS_SEPARATE_BIT,
> + .scan_type = IIO_ST('u', 16, 16, 0),
> + .event_mask = IIO_EV_BIT(IIO_EV_TYPE_THRESH, IIO_EV_DIR_RISING) |
> + IIO_EV_BIT(IIO_EV_TYPE_THRESH, IIO_EV_DIR_FALLING),
> + },
> + {
> + .type = IIO_TEMP,
> + .channel = -1,
> + .event_mask = IIO_EV_BIT(IIO_EV_TYPE_THRESH, IIO_EV_DIR_RISING),
> + },
> +};
> +
> +static int ad5421_write_unlocked(struct iio_dev *indio_dev,
> + unsigned int reg, unsigned int val)
> +{
> + struct ad5421_state *st = iio_priv(indio_dev);
> +
> + st->data[0].d32 = cpu_to_be32((reg << 16) | val);
> +
> + return spi_write(st->spi, &st->data[0].d8[1], 3);
> +}
> +
> +static int ad5421_write(struct iio_dev *indio_dev, unsigned int reg,
> + unsigned int val)
> +{
> + int ret;
> +
> + mutex_lock(&indio_dev->mlock);
> + ret = ad5421_write_unlocked(indio_dev, reg, val);
> + mutex_unlock(&indio_dev->mlock);
> +
> + return ret;
> +}
> +
> +static int ad5421_read(struct iio_dev *indio_dev, unsigned int reg)
> +{
> + struct ad5421_state *st = iio_priv(indio_dev);
> + struct spi_message m;
> + int ret;
> + struct spi_transfer t[] = {
> + {
> + .tx_buf = &st->data[0].d8[1],
> + .len = 3,
> + .cs_change = 1,
> + }, {
> + .rx_buf = &st->data[1].d8[1],
> + .len = 3,
> + },
> + };
> +
> + spi_message_init(&m);
> + spi_message_add_tail(&t[0], &m);
> + spi_message_add_tail(&t[1], &m);
> +
> + mutex_lock(&indio_dev->mlock);
> +
> + st->data[0].d32 = cpu_to_be32((1 << 23) | (reg << 16));
> +
> + ret = spi_sync(st->spi, &m);
> + if (ret >= 0)
> + ret = be32_to_cpu(st->data[1].d32) & 0xffff;
> +
> + mutex_unlock(&indio_dev->mlock);
> +
> + return ret;
> +}
> +
> +static int ad5421_update_ctrl(struct iio_dev *indio_dev, unsigned int set,
> + unsigned int clr)
> +{
> + struct ad5421_state *st = iio_priv(indio_dev);
> + unsigned int ret;
> +
> + mutex_lock(&indio_dev->mlock);
> +
> + st->ctrl &= ~clr;
> + st->ctrl |= set;
> +
> + ret = ad5421_write_unlocked(indio_dev, AD5421_REG_CTRL, st->ctrl);
> +
> + mutex_unlock(&indio_dev->mlock);
> +
> + return ret;
> +}
> +
> +static irqreturn_t ad5421_fault_handler(int irq, void *data)
> +{
> + struct iio_dev *indio_dev = data;
> + struct ad5421_state *st = iio_priv(indio_dev);
> + unsigned int fault;
> + unsigned int old_fault = 0;
> + unsigned int events;
> +
> + fault = ad5421_read(indio_dev, AD5421_REG_FAULT);
> + if (!fault)
> + return IRQ_NONE;
> +
> + /* If we had a fault, this might mean that the DAC has lost its state
> + * and has been reset. Make sure that the control register actually
> + * contains what we expect it to contain. Otherwise the watchdog might
> + * be enabled and we get watchdog timeout faults, which will render the
> + * DAC unusable. */
> + ad5421_update_ctrl(indio_dev, 0, 0);
> +
> +
> + /* The fault pin stays high as long as a fault condition is present and
> + * it is not possible to mask fault conditions. For certain fault
> + * conditions for example like over-temperature it takes some time
> + * until the fault condition disappears. If we would exit the interrupt
> + * handler immediately after handling the event it would be entered
> + * again instantly. Thus we fall back to polling in case we detect that
> + * a interrupt condition is still present.
> + */
> + do {
> + /* 0xffff is a invalid value for the register and will only be
> + * read if there has been a communication error */
> + if (fault == 0xffff)
> + fault = 0;
> +
> + /* we are only interested in new events */
> + events = (old_fault ^ fault) & fault;
> + events &= st->fault_mask;
> +
> + if (events & AD5421_FAULT_OVER_CURRENT) {
> + iio_push_event(indio_dev,
> + IIO_UNMOD_EVENT_CODE(IIO_CURRENT,
> + 0,
> + IIO_EV_TYPE_THRESH,
> + IIO_EV_DIR_RISING),
> + iio_get_time_ns());
> + }
> +
> + if (events & AD5421_FAULT_UNDER_CURRENT) {
> + iio_push_event(indio_dev,
> + IIO_UNMOD_EVENT_CODE(IIO_CURRENT,
> + 0,
> + IIO_EV_TYPE_THRESH,
> + IIO_EV_DIR_FALLING),
> + iio_get_time_ns());
> + }
> +
> + if (events & AD5421_FAULT_TEMP_OVER_140) {
> + iio_push_event(indio_dev,
> + IIO_UNMOD_EVENT_CODE(IIO_TEMP,
> + 0,
> + IIO_EV_TYPE_MAG,
> + IIO_EV_DIR_RISING),
> + iio_get_time_ns());
> + }
> +
> + old_fault = fault;
> + fault = ad5421_read(indio_dev, AD5421_REG_FAULT);
> +
> + /* still active? go to sleep for some time */
> + if (fault & AD5421_FAULT_TRIGGER_IRQ)
> + msleep(1000);
> +
> + } while (fault & AD5421_FAULT_TRIGGER_IRQ);
> +
> +
> + return IRQ_HANDLED;
> +}
> +
> +static void ad5421_get_current_min_max(struct ad5421_state *st,
> + unsigned int *min, unsigned int *max)
> +{
> + /* The current range is configured using external pins, which are
> + * usually hard-wired and not run-time switchable. */
> + switch (st->current_range) {
> + case AD5421_CURRENT_RANGE_4mA_20mA:
> + *min = 4000;
> + *max = 20000;
> + break;
> + case AD5421_CURRENT_RANGE_3mA8_21mA:
> + *min = 3800;
> + *max = 21000;
> + break;
> + case AD5421_CURRENT_RANGE_3mA2_24mA:
> + *min = 3200;
> + *max = 24000;
> + break;
> + default:
> + *min = 0;
> + *max = 1;
> + break;
> + }
> +}
> +
> +static inline unsigned int ad5421_get_offset(struct ad5421_state *st)
> +{
> + unsigned int min, max;
> +
> + ad5421_get_current_min_max(st, &min, &max);
> + return (min * (1 << 16)) / (max - min);
> +}
> +
> +static inline unsigned int ad5421_get_scale(struct ad5421_state *st)
> +{
> + unsigned int min, max;
> +
> + ad5421_get_current_min_max(st, &min, &max);
> + return ((max - min) * 1000) / (1 << 16);
> +}
> +
> +static int ad5421_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int *val, int *val2, long m)
> +{
> + struct ad5421_state *st = iio_priv(indio_dev);
> + int ret;
> +
> + if (chan->type != IIO_CURRENT)
> + return -EINVAL;
> +
> + switch (m) {
> + case 0:
> + ret = ad5421_read(indio_dev, AD5421_REG_DAC_DATA);
> + if (ret < 0)
> + return ret;
> + *val = ret;
> + return IIO_VAL_INT;
> + case IIO_CHAN_INFO_SCALE:
> + *val = 0;
> + *val2 = ad5421_get_scale(st);
> + return IIO_VAL_INT_PLUS_MICRO;
> + case IIO_CHAN_INFO_OFFSET:
> + *val = ad5421_get_offset(st);
> + return IIO_VAL_INT;
> + case IIO_CHAN_INFO_CALIBBIAS:
> + ret = ad5421_read(indio_dev, AD5421_REG_OFFSET);
> + if (ret < 0)
> + return ret;
> + *val = ret - 32768;
> + return IIO_VAL_INT;
> + case IIO_CHAN_INFO_CALIBSCALE:
> + ret = ad5421_read(indio_dev, AD5421_REG_GAIN);
> + if (ret < 0)
> + return ret;
> + *val = ret;
> + return IIO_VAL_INT;
> + }
> +
> + return -EINVAL;
> +}
> +
> +static int ad5421_write_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int val, int val2, long mask)
> +{
> + const unsigned int max_val = 1 << 16;
> +
> + switch (mask) {
> + case 0:
> + if (val >= max_val || val < 0)
> + return -EINVAL;
> +
> + return ad5421_write(indio_dev, AD5421_REG_DAC_DATA, val);
> + case IIO_CHAN_INFO_CALIBBIAS:
> + val += 32768;
> + if (val >= max_val || val < 0)
> + return -EINVAL;
> +
> + return ad5421_write(indio_dev, AD5421_REG_OFFSET, val);
> + case IIO_CHAN_INFO_CALIBSCALE:
> + if (val >= max_val || val < 0)
> + return -EINVAL;
> +
> + return ad5421_write(indio_dev, AD5421_REG_GAIN, val);
> + default:
> + break;
> + }
> +
> + return -EINVAL;
> +}
> +
> +static int ad5421_write_event_config(struct iio_dev *indio_dev,
> + u64 event_code, int state)
> +{
> + struct ad5421_state *st = iio_priv(indio_dev);
> + unsigned int mask;
> +
> + switch (IIO_EVENT_CODE_EXTRACT_CHAN_TYPE(event_code)) {
> + case IIO_CURRENT:
> + if (IIO_EVENT_CODE_EXTRACT_DIR(event_code) ==
> + IIO_EV_DIR_RISING)
> + mask = AD5421_FAULT_OVER_CURRENT;
> + else
> + mask = AD5421_FAULT_UNDER_CURRENT;
> + break;
> + case IIO_TEMP:
> + mask = AD5421_FAULT_TEMP_OVER_140;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + mutex_lock(&indio_dev->mlock);
> + if (state)
> + st->fault_mask |= mask;
> + else
> + st->fault_mask &= ~mask;
> + mutex_unlock(&indio_dev->mlock);
> +
> + return 0;
> +}
> +
> +static int ad5421_read_event_config(struct iio_dev *indio_dev,
> + u64 event_code)
> +{
> + struct ad5421_state *st = iio_priv(indio_dev);
> + unsigned int mask;
> +
> + switch (IIO_EVENT_CODE_EXTRACT_CHAN_TYPE(event_code)) {
> + case IIO_CURRENT:
> + if (IIO_EVENT_CODE_EXTRACT_DIR(event_code) ==
> + IIO_EV_DIR_RISING)
> + mask = AD5421_FAULT_OVER_CURRENT;
> + else
> + mask = AD5421_FAULT_UNDER_CURRENT;
> + break;
> + case IIO_TEMP:
> + mask = AD5421_FAULT_TEMP_OVER_140;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return (bool)(st->fault_mask & mask);
> +}
> +
> +static int ad5421_read_event_value(struct iio_dev *indio_dev, u64 event_code,
> + int *val)
> +{
> + int ret;
> +
> + switch (IIO_EVENT_CODE_EXTRACT_CHAN_TYPE(event_code)) {
> + case IIO_CURRENT:
> + ret = ad5421_read(indio_dev, AD5421_REG_DAC_DATA);
> + if (ret < 0)
> + return ret;
> + *val = ret;
> + break;
> + case IIO_TEMP:
> + *val = 140000;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static const struct iio_info ad5421_info = {
> + .read_raw = ad5421_read_raw,
> + .write_raw = ad5421_write_raw,
> + .read_event_config = ad5421_read_event_config,
> + .write_event_config = ad5421_write_event_config,
> + .read_event_value = ad5421_read_event_value,
> + .driver_module = THIS_MODULE,
> +};
> +
> +static int __devinit ad5421_probe(struct spi_device *spi)
> +{
> + struct ad5421_platform_data *pdata = dev_get_platdata(&spi->dev);
> + struct iio_dev *indio_dev;
> + struct ad5421_state *st;
> + int ret;
> +
> + indio_dev = iio_allocate_device(sizeof(*st));
> + if (indio_dev == NULL) {
> + dev_err(&spi->dev, "Failed to allocate iio device\n");
> + return -ENOMEM;
> + }
> +
> + st = iio_priv(indio_dev);
> + spi_set_drvdata(spi, indio_dev);
> +
> + st->spi = spi;
> +
> + indio_dev->dev.parent = &spi->dev;
> + indio_dev->name = "ad5421";
> + indio_dev->info = &ad5421_info;
> + indio_dev->modes = INDIO_DIRECT_MODE;
> + indio_dev->channels = ad5421_channels;
> + indio_dev->num_channels = ARRAY_SIZE(ad5421_channels);
> +
> + st->ctrl = AD5421_CTRL_WATCHDOG_DISABLE |
> + AD5421_CTRL_AUTO_FAULT_READBACK;
> +
> + if (pdata) {
> + st->current_range = pdata->current_range;
> + if (pdata->external_vref)
> + st->ctrl |= AD5421_CTRL_PWR_DOWN_INT_VREF;
> + } else {
> + st->current_range = AD5421_CURRENT_RANGE_4mA_20mA;
> + }
> +
> + /* write initial ctrl register value */
> + ad5421_update_ctrl(indio_dev, 0, 0);
> +
> + if (spi->irq) {
> + ret = request_threaded_irq(spi->irq,
> + NULL,
> + ad5421_fault_handler,
> + IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> + "ad5421 fault",
> + indio_dev);
> + if (ret)
> + goto error_free;
> + }
> +
> + ret = iio_device_register(indio_dev);
> + if (ret) {
> + dev_err(&spi->dev, "Failed to register iio device: %d\n", ret);
> + goto error_free_irq;
> + }
> +
> + return 0;
> +
> +error_free_irq:
> + if (spi->irq)
> + free_irq(spi->irq, indio_dev);
> +error_free:
> + iio_free_device(indio_dev);
> +
> + return ret;
> +}
> +
> +static int __devexit ad5421_remove(struct spi_device *spi)
> +{
> + struct iio_dev *indio_dev = spi_get_drvdata(spi);
> +
> + iio_device_unregister(indio_dev);
> + if (spi->irq)
> + free_irq(spi->irq, indio_dev);
> + iio_free_device(indio_dev);
> +
> + return 0;
> +}
> +
> +static struct spi_driver ad5421_driver = {
> + .driver = {
> + .name = "ad5421",
> + .owner = THIS_MODULE,
> + },
> + .probe = ad5421_probe,
> + .remove = __devexit_p(ad5421_remove),
> +};
> +
> +static __init int ad5421_init(void)
> +{
> + return spi_register_driver(&ad5421_driver);
> +}
> +module_init(ad5421_init);
> +
> +static __exit void ad5421_exit(void)
> +{
> + spi_unregister_driver(&ad5421_driver);
> +}
> +module_exit(ad5421_exit);
> +
> +MODULE_AUTHOR("Lars-Peter Clausen <lars@metafoo.de>");
> +MODULE_DESCRIPTION("Analog Devices AD5421 DAC");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("spi:ad5421");
> diff --git a/drivers/staging/iio/dac/ad5421.h b/drivers/staging/iio/dac/ad5421.h
> new file mode 100644
> index 0000000..cd2bb84
> --- /dev/null
> +++ b/drivers/staging/iio/dac/ad5421.h
> @@ -0,0 +1,32 @@
> +#ifndef __IIO_DAC_AD5421_H__
> +#define __IIO_DAC_AD5421_H__
> +
> +/*
> + * TODO: This file needs to go into include/linux/iio
> + */
> +
> +/**
> + * enum ad5421_current_range - Current range the AD5421 is configured for.
> + * @AD5421_CURRENT_RANGE_4mA_20mA: 4 mA to 20 mA (RANGE1,0 pins = 00)
> + * @AD5421_CURRENT_RANGE_3mA8_21mA: 3.8 mA to 21 mA (RANGE1,0 pins = x1)
> + * @AD5421_CURRENT_RANGE_3mA2_24mA: 3.2 mA to 24 mA (RANGE1,0 pins = 10)
> + */
> +
> +enum ad5421_current_range {
> + AD5421_CURRENT_RANGE_4mA_20mA,
> + AD5421_CURRENT_RANGE_3mA8_21mA,
> + AD5421_CURRENT_RANGE_3mA2_24mA,
> +};
> +
> +/**
> + * struct ad5421_platform_data - AD5421 DAC driver platform data
> + * @external_vref: whether an external reference voltage is used or not
> + * @current_range: Current range the AD5421 is configured for
> + */
> +
> +struct ad5421_platform_data {
> + bool external_vref;
> + enum ad5421_current_range current_range;
> +};
> +
> +#endif
^ 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.