* Re: [RFC v2 0/2] vmevent: A bit reworked pressure attribute + docs + man page
From: Minchan Kim @ 2012-10-25 8:53 UTC (permalink / raw)
To: Pekka Enberg
Cc: Anton Vorontsov, Mel Gorman, Leonid Moiseichuk, KOSAKI Motohiro,
Bartlomiej Zolnierkiewicz, John Stultz,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
patches-QSEj5FYQhm4dnm+yROfE0A,
kernel-team-z5hGa2qSFaRBDgjK7y7TUQ,
linux-man-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAOJsxLGsjTe13WjY_Q=BLBELwQXOjuwo7PiEKwONHUfR4mQmig-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Pekka,
On Thu, Oct 25, 2012 at 09:44:52AM +0300, Pekka Enberg wrote:
> On Thu, Oct 25, 2012 at 9:40 AM, Minchan Kim <minchan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > Your description doesn't include why we need new vmevent_fd(2).
> > Of course, it's very flexible and potential to add new VM knob easily but
> > the thing we is about to use now is only VMEVENT_ATTR_PRESSURE.
> > Is there any other use cases for swap or free? or potential user?
> > Adding vmevent_fd without them is rather overkill.
>
> What ABI would you use instead?
I thought /dev/some_knob like mem_notify and epoll is enough but please keep in mind
that I'm not against vmevent_fd strongly. My point is that description should include
explain about why other candidate is not good or why vmevent_fd is better.
(But at least, I don't like vmevent timer polling still and I hope we use it
as last resort once we can find another)
>
> On Thu, Oct 25, 2012 at 9:40 AM, Minchan Kim <minchan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > I don't object but we need rationale for adding new system call which should
> > be maintained forever once we add it.
>
> Agreed.
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo-Bw31MaZKKs0EbZ0PF+XxCw@public.gmane.org For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org"> email-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org </a>
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-man" 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: Who is the 'git' vendor?
From: Andreas Ericsson @ 2012-10-25 8:52 UTC (permalink / raw)
To: PROHASKA, Thor
Cc: 'git@vger.kernel.org',
'Thor Home (thorlp@hotkey.net.au)'
In-Reply-To: <8F7A9DADB4F4064EB938B0D3EBB63FDC208A5A34@PBNEMBMSX4120.int.Corp.sun>
On 10/25/2012 08:43 AM, PROHASKA, Thor wrote:
> Hi,
>
> The organisation I am currently working for uses 'git'.
>
> In order to manage all the software used in the organisation we have
> been compiling a list of software that includes the software Vendor's
> name.
>
> My colleague has listed the vendor of git as being the 'Software
> Freedom Conservancy'. Can you please advise me if this is correct? If
> not, who should the vendor be identified as?
>
Most likely, you'll want to put "git@vger.kernel.org" as vendor for git,
as the whole vendor concept doesn't really fly with FOSS. There's noone
to go to if it breaks your systems, and unless you purchase a support
contract from somewhere there's noone to turn to except the (excellent)
git community in case you have issues with it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: [PATCH] pch_gbe: don't come up if we can't allocate buffers
From: Veaceslav Falico @ 2012-10-25 8:51 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, davem, richardcochran, tshimizu818, andy.cress,
erwan.velu
In-Reply-To: <1351154458.6537.146.camel@edumazet-glaptop>
On Thu, Oct 25, 2012 at 10:40:58AM +0200, Eric Dumazet wrote:
>On Thu, 2012-10-25 at 09:10 +0200, Veaceslav Falico wrote:
>> Currently, even if pch_gbe_alloc_tx/rx_buffers (even partially) fail, we
>> bring the interface up. It mihgt confuse the user (if he requested specific
>> amount of buffers) and can lead to different bugs.
>>
>> Add error handling to these functions and clean after them in case of
>> failure. It also resolves a possible NULL pointer dereference in
>> pch_gbe_alloc_tx_buffers(), in case of netdev_alloc_skb() failure. It's ok
>> to (paritally) fail for pch_gbe_alloc_rx_buffers() in some situation, so
>> don't clean inside and rather handle skb freeing outside of the function.
>>
>> This patch also adds tx_alloc_buff_failed ethtool counter.
>
>This should not be needed :
>
>> -static void pch_gbe_alloc_tx_buffers(struct pch_gbe_adapter *adapter,
>> +static int pch_gbe_alloc_tx_buffers(struct pch_gbe_adapter *adapter,
>> struct pch_gbe_tx_ring *tx_ring)
>> {
>> struct pch_gbe_buffer *buffer_info;
>> @@ -1506,6 +1521,7 @@ static void pch_gbe_alloc_tx_buffers(struct pch_gbe_adapter *adapter,
>> unsigned int i;
>> unsigned int bufsz;
>> struct pch_gbe_tx_desc *tx_desc;
>> + int err;
>>
>> bufsz =
>> adapter->hw.mac.max_frame_size + PCH_GBE_DMA_ALIGN + NET_IP_ALIGN;
>> @@ -1513,12 +1529,26 @@ static void pch_gbe_alloc_tx_buffers(struct pch_gbe_adapter *adapter,
>> for (i = 0; i < tx_ring->count; i++) {
>> buffer_info = &tx_ring->buffer_info[i];
>> skb = netdev_alloc_skb(adapter->netdev, bufsz);
>> + if (unlikely(!skb)) {
>> + adapter->stats.tx_alloc_buff_failed++;
>> + err = -ENOMEM;
>> + goto freeall;
>> + }
>
>Hmmm
>
>These skbs should be allocated using GFP_KERNEL, to lower risk of OOM,
>using a mere alloc_skb(bufsz, GFP_KERNEL)
>
>Only skbs for rx 'need' netdev_alloc_skb() to add a NET_SKB_PAD
>headroom.
>
> skb = alloc_skb(bufsz, GFP_KERNEL);
> if (!skb)
> goto fail;
> skb_reserve(skb, NET_IP_ALIGN);
>
>And BTW, we dont really need skbs here, only a bounce buffer so that we
>can copy frames on it... (kmalloc() instead of alloc_skb())
>
>> skb_reserve(skb, PCH_GBE_DMA_ALIGN);
>
>PCH_GBE_DMA_ALIGN is zero ...
>
>> buffer_info->skb = skb;
>> tx_desc = PCH_GBE_TX_DESC(*tx_ring, i);
>> tx_desc->gbec_status = (DSC_INIT16);
>> }
>> - return;
>> + return 0;
>> +
>> +freeall:
>> + for (i--; i >= 0; i--) {
>> + dev_kfree_skb_any(buffer_info->skb);
>> + buffer_info->skb = NULL;
>> + tx_desc = PCH_GBE_TX_DESC(*tx_ring, i);
>> + tx_desc->gbec_status = 0;
>> + }
>> + return err;
>> }
>>
>
>
>Also I would call pch_gbe_alloc_tx_buffers() _after_
>pch_gbe_alloc_rx_buffers() (Since rx allocations probably are using
>GFP_ATOMIC allocations)
Agree with all, will update the patch.
Thank you very much for the review!
^ permalink raw reply
* Re: [PATCH] drm/i915: be less verbose about inability to provide vendor backlight
From: Chris Wilson @ 2012-10-25 8:51 UTC (permalink / raw)
To: intel-gfx; +Cc: jani.nikula
In-Reply-To: <1351151859-24853-1-git-send-email-jani.nikula@intel.com>
On Thu, 25 Oct 2012 10:57:38 +0300, Jani Nikula <jani.nikula@intel.com> wrote:
> commit 28dcc2d60cb570d9f549c329b2f51400553412a1
> Author: Jani Nikula <jani.nikula@intel.com>
> Date: Mon Sep 3 16:25:12 2012 +0300
>
> drm/i915: do not expose a dysfunctional backlight interface to userspace
>
> prevents backlight interface creation if the BIOS has not set the backlight
> PWM CTL registers that contain the max PWM value. It's apparently normal on
> those machines, so demote the message about it to debug level.
>
> Reported-by: Orion Poplawski <orion@cora.nwra.com>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56330
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We may want to create an explicit bug/task to track the missing
initialisation as a reminder as well.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply
* [PATCH] mm: rmap: fix build warning
From: Bob Liu @ 2012-10-25 8:50 UTC (permalink / raw)
To: akpm; +Cc: fengguang.wu, yuanhan.liu, sfr, linux-next, linux-mm, Bob Liu
mm/rmap.c: In function 'try_to_unmap_cluster':
mm/rmap.c:1361:9: warning: unused variable 'pud' [-Wunused-variable]
mm/rmap.c:1360:9: warning: unused variable 'pgd' [-Wunused-variable]
I forgot to del these variable in my commit:
0981230ec3206f98dcc58febfef9fd35b540d25a mm: introduce mm_find_pmd()
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Bob Liu <lliubbo@gmail.com>
---
mm/rmap.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/mm/rmap.c b/mm/rmap.c
index 6c686c2..98b100e 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1360,8 +1360,6 @@ static int try_to_unmap_cluster(unsigned long cursor, unsigned int *mapcount,
struct vm_area_struct *vma, struct page *check_page)
{
struct mm_struct *mm = vma->vm_mm;
- pgd_t *pgd;
- pud_t *pud;
pmd_t *pmd;
pte_t *pte;
pte_t pteval;
--
1.7.9.5
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH] mm: rmap: fix build warning
From: Bob Liu @ 2012-10-25 8:50 UTC (permalink / raw)
To: akpm; +Cc: fengguang.wu, yuanhan.liu, sfr, linux-next, linux-mm, Bob Liu
mm/rmap.c: In function 'try_to_unmap_cluster':
mm/rmap.c:1361:9: warning: unused variable 'pud' [-Wunused-variable]
mm/rmap.c:1360:9: warning: unused variable 'pgd' [-Wunused-variable]
I forgot to del these variable in my commit:
0981230ec3206f98dcc58febfef9fd35b540d25a mm: introduce mm_find_pmd()
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Bob Liu <lliubbo@gmail.com>
---
mm/rmap.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/mm/rmap.c b/mm/rmap.c
index 6c686c2..98b100e 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1360,8 +1360,6 @@ static int try_to_unmap_cluster(unsigned long cursor, unsigned int *mapcount,
struct vm_area_struct *vma, struct page *check_page)
{
struct mm_struct *mm = vma->vm_mm;
- pgd_t *pgd;
- pud_t *pud;
pmd_t *pmd;
pte_t *pte;
pte_t pteval;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] net phy: poll for a link
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-25 8:49 UTC (permalink / raw)
To: Eric Bénard; +Cc: barebox
In-Reply-To: <20121024215649.25964bc6@eb-e6520>
On 21:56 Wed 24 Oct , Eric Bénard wrote:
> Hi,
>
> Le Wed, 24 Oct 2012 20:33:59 +0200,
> Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> a écrit :
>
> > On 20:06 Wed 24 Oct , Sascha Hauer wrote:
> > > Since we have phylib we have no instance which polls for a link. This
> > > means that network boot often bails out after a powercycle or phy reset.
> > > This changes the link status behaviour to:
> > >
> > > - Always check for a link if the last link test was unsuccesful
> > > - If the last check was succesful, check for a link when the last
> > > check is longer than 5 seconds ago
> > > - Try to get a link for 5 seconds.
> > 5 seconds is too long
> >
> > and check the link is wrong you need to check the autoneg
> > the link may be down because no cable
> >
> and the autoneg can have been successful before the cable was
> removed : how to you handle this cas ?
the advertise tell you something change
so you need to restart the autoneg
Best Regards,
J.
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* [PATCH 2/2] Btrfs-progs: Introduce another form of btrfs subvolume set-default command
From: Chen Yang @ 2012-10-25 8:49 UTC (permalink / raw)
To: linux-btrfs; +Cc: Chen Yang
This patch introduces another form of btrfs subvolume set-default command.
In command "btrfs subvolume set-default", we used subvolume <id> and <path>
to set the default subvolume of a filesystem.
By the new form, we can use subvolume path to set the default subvolume.
The new form:
subvolume set-default [-p] [-f] <path>
For example:
If <path> is a subvolume, no option needed.
#btrfs subvolume set-default /mnt/subvol
If <path> is not a subvolume, -p option makes btrfs enter interactive mode
# btrfs subvolume set-default -p /mnt/subvol/dir
'/mnt/subvol/dir' is not a subvolume, use parent tree instead? (y or n)y
If interactive is not expected, -f option makes btrfs skip it and 'yes' will be choose
# btrfs subvolume set-default -p -f /mnt/subvol/dir
Signed-off-by: Cheng Yang <chenyang.fnst@cn.fujitsu.com>
---
Makefile | 2 +-
cmds-subvolume.c | 107 +++++++++++++++++++++++++++++++++++++++++++++++-------
man/btrfs.8.in | 17 +++++++++
yesno.c | 56 ++++++++++++++++++++++++++++
yesno.h | 24 ++++++++++++
5 files changed, 191 insertions(+), 15 deletions(-)
create mode 100644 yesno.c
create mode 100644 yesno.h
diff --git a/Makefile b/Makefile
index 4894903..433dc32 100644
--- a/Makefile
+++ b/Makefile
@@ -4,7 +4,7 @@ CFLAGS = -g -O1
objects = ctree.o disk-io.o radix-tree.o extent-tree.o print-tree.o \
root-tree.o dir-item.o file-item.o inode-item.o \
inode-map.o crc32c.o rbtree.o extent-cache.o extent_io.o \
- volumes.o utils.o btrfs-list.o btrfslabel.o repair.o \
+ volumes.o utils.o btrfs-list.o btrfslabel.o repair.o yesno.o\
send-stream.o send-utils.o qgroup.o
cmds_objects = cmds-subvolume.o cmds-filesystem.o cmds-device.o cmds-scrub.o \
cmds-inspect.o cmds-balance.o cmds-send.o cmds-receive.o \
diff --git a/cmds-subvolume.c b/cmds-subvolume.c
index ac39f7b..e35fdd4 100644
--- a/cmds-subvolume.c
+++ b/cmds-subvolume.c
@@ -32,6 +32,7 @@
#include "ctree.h"
#include "commands.h"
#include "btrfs-list.h"
+#include "yesno.h"
static const char * const subvolume_cmd_group_usage[] = {
"btrfs subvolume <command> <args>",
@@ -620,22 +621,81 @@ static int cmd_subvol_get_default(int argc, char **argv)
static const char * const cmd_subvol_set_default_usage[] = {
"btrfs subvolume set-default <subvolid> <path>",
+ "btrfs subvolume set-default [-p] [-f] <path>",
"Set the default subvolume of a filesystem",
+ "-p If <path> is not a subvolume, it will enter",
+ " interactive mode, then you can choose to set",
+ " the parent tree of the <path> as default or not.",
+ "-f This option must be used with -p. The interactive",
+ " mode will be skipped and 'yes' will be set.",
NULL
};
static int cmd_subvol_set_default(int argc, char **argv)
{
- int ret=0, fd, e;
- u64 objectid;
+ int ret = 0, fd = -1, e;
+ int parent = 0, force = 0;
+ u64 objectid = -1;
char *path;
- char *subvolid;
+ char *subvolid, *inv;
- if (check_argc_exact(argc, 3))
- usage(cmd_subvol_set_default_usage);
+ optind = 1;
+ while (1) {
+ int c = getopt(argc, argv, "pf");
+ if (c < 0)
+ break;
+
+ switch (c) {
+ case 'p':
+ parent = 1;
+ break;
+ case 'f':
+ force = 1;
+ break;
+ default:
+ usage_lines(cmd_subvol_set_default_usage, 1);
+ }
+ }
+
+ if (check_argc_min(argc - optind, 1) ||
+ check_argc_max(argc - optind, 3))
+ usage_lines(cmd_subvol_set_default_usage, 1);
+
+ if (force && !parent)
+ usage_lines(cmd_subvol_set_default_usage, 1);
- subvolid = argv[1];
- path = argv[2];
+ if (argc - optind == 2) {
+ subvolid = argv[optind];
+ path = argv[optind + 1];
+
+ objectid = (unsigned long long)strtoll(subvolid, &inv, 0);
+ if (errno == ERANGE || subvolid == inv) {
+ fprintf(stderr,
+ "ERROR: invalid tree id (%s)\n", subvolid);
+ return 30;
+ }
+ } else {
+ path = argv[optind];
+
+ ret = test_issubvolume(path);
+ if (ret < 0) {
+ fprintf(stderr,
+ "ERROR: error accessing '%s'\n", path);
+ return 12;
+ }
+ if (!ret) {
+ fprintf(stderr,
+ "'%s' is not a subvolume, use parent tree instead",
+ path);
+ if (force)
+ fprintf(stderr, "!\n");
+ else {
+ fprintf(stderr, "? (y or n)");
+ if (!yesno())
+ return 13;
+ }
+ }
+ }
fd = open_file_or_dir(path);
if (fd < 0) {
@@ -643,16 +703,35 @@ static int cmd_subvol_set_default(int argc, char **argv)
return 12;
}
- objectid = (unsigned long long)strtoll(subvolid, NULL, 0);
- if (errno == ERANGE) {
- fprintf(stderr, "ERROR: invalid tree id (%s)\n",subvolid);
- return 30;
+ /*
+ * When objectid is -1, it means that
+ * subvolume id is not specified by user.
+ * We will set default subvolume by <path>.
+ */
+ if (objectid == -1) {
+ struct btrfs_ioctl_ino_lookup_args args;
+
+ memset(&args, 0, sizeof(args));
+ args.treeid = 0;
+ args.objectid = BTRFS_FIRST_FREE_OBJECTID;
+
+ ret = ioctl(fd, BTRFS_IOC_INO_LOOKUP, &args);
+ if (ret) {
+ fprintf(stderr,
+ "ERROR: can't perform the search - %s\n",
+ strerror(errno));
+ return ret;
+ }
+
+ objectid = args.treeid;
}
+
ret = ioctl(fd, BTRFS_IOC_DEFAULT_SUBVOL, &objectid);
e = errno;
close(fd);
- if( ret < 0 ){
- fprintf(stderr, "ERROR: unable to set a new default subvolume - %s\n",
+ if (ret < 0) {
+ fprintf(stderr,
+ "ERROR: unable to set a new default subvolume - %s\n",
strerror(e));
return 30;
}
@@ -708,7 +787,7 @@ const struct cmd_group subvolume_cmd_group = {
{ "get-default", cmd_subvol_get_default,
cmd_subvol_get_default_usage, NULL, 0 },
{ "set-default", cmd_subvol_set_default,
- cmd_subvol_set_default_usage, NULL, 0 },
+ cmd_subvol_set_default_usage, NULL, 0 , 1 },
{ "find-new", cmd_find_new, cmd_find_new_usage, NULL, 0 },
{ 0, 0, 0, 0, 0 }
}
diff --git a/man/btrfs.8.in b/man/btrfs.8.in
index 9222580..0a52688 100644
--- a/man/btrfs.8.in
+++ b/man/btrfs.8.in
@@ -15,6 +15,8 @@ btrfs \- control a btrfs filesystem
.PP
\fBbtrfs\fP \fBsubvolume set-default\fP\fI <id> <path>\fP
.PP
+\fBbtrfs\fP \fBsubvolume set-default\fP\fI [-p] [-f] <subvolume>\fP
+.PP
\fBbtrfs\fP \fBsubvolume get-default\fP\fI <path>\fP
.PP
\fBbtrfs\fP \fBfilesystem defragment\fP -c[zlib|lzo] [-l \fIlen\fR] \
@@ -155,6 +157,21 @@ Set the subvolume of the filesystem \fI<path>\fR which is mounted as
is returned by the \fBsubvolume list\fR command.
.TP
+\fBsubvolume set-default\fR\fI [-p] [-f] <path>\fR
+Set the subvolume of the filesystem as default. The subvolume is identified
+by \fI<path>\fR. By default(no option is given), it should be a path to
+subvolume, or btrfs returns an error.
+
+\fB-p\fR If \fB-p\fR is given, and \fI<path>\fR is a subvolume, btrfs is the
+same as default. And if <path> is not a subvolume, btrfs enters
+interactive mode, then you can choose to set the parent tree of \fI<path>\fR
+as default or not.
+
+\fB-f\fR \fB-f\fR must be used with \fB-p\fR, and the interactive mode
+will be skipped and 'yes' will be chosen. Given \fB-f\fR option without
+\fB-p\fR, btrfs returns an error.
+.TP
+
\fBsubvolume get-default\fR\fI <path>\fR
Get the default subvolume of the filesystem \fI<path>\fR. The output format
is similar to \fBsubvolume list\fR command.
diff --git a/yesno.c b/yesno.c
new file mode 100644
index 0000000..ef0c0db
--- /dev/null
+++ b/yesno.c
@@ -0,0 +1,56 @@
+/* yesno.c -- read a yes/no response from stdin
+
+ Copyright (C) 1990, 1998, 2001, 2003-2012 Free Software Foundation, Inc.
+
+ This program is free software: you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+#include "yesno.h"
+
+#include <stdlib.h>
+#include <stdio.h>
+
+/* Return true if we read an affirmative line from standard input.
+
+ Since this function uses stdin, it is suggested that the caller not
+ use STDIN_FILENO directly, and also that the line
+ atexit(close_stdin) be added to main(). */
+
+bool yesno(void)
+{
+ bool yes;
+
+#if ENABLE_NLS
+ char *response = NULL;
+ size_t response_size = 0;
+ ssize_t response_len = getline(&response, &response_size, stdin);
+
+ if (response_len <= 0)
+ yes = false;
+ else{
+ response[response_len - 1] = '\0';
+ yes = (0 < rpmatch(response));
+ }
+
+ free(response);
+#else
+ /* Test against "^[yY]", hardcoded to avoid requiring getline,
+ regex, and rpmatch. */
+ int c = getchar();
+ yes = (c == 'y' || c == 'Y');
+ while (c != '\n' && c != EOF)
+ c = getchar();
+#endif
+
+ return yes;
+}
diff --git a/yesno.h b/yesno.h
new file mode 100644
index 0000000..6f5c43f
--- /dev/null
+++ b/yesno.h
@@ -0,0 +1,24 @@
+/* declare yesno
+ Copyright (C) 2004, 2009-2012 Free Software Foundation, Inc.
+
+ This program is free software: you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+#ifndef YESNO_H_
+# define YESNO_H_
+
+# include <stdbool.h>
+
+bool yesno(void);
+
+#endif
--
1.7.7.6
^ permalink raw reply related
* [PATCH 1/2] Btrfs-progs: Improve the command help system of btrfs
From: Chen Yang @ 2012-10-25 8:49 UTC (permalink / raw)
To: linux-btrfs; +Cc: Chen Yang
Btrfs's command help system allow you to show only one line short usage.
But in some case we need to use two or more lines to show
the short usage of a complicated command.
This patch add a filed 'lines' in cmd_struct, which is the number of the
extra short usage lines you want to append.
For example you have N lines short usage; you should set the field 'lines'
to N-1.
Signed-off-by: Cheng Yang <chenyang.fnst@cn.fujitsu.com>
---
commands.h | 4 ++++
help.c | 31 ++++++++++++++++++++++---------
2 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/commands.h b/commands.h
index bb6d2dd..f535dc2 100644
--- a/commands.h
+++ b/commands.h
@@ -48,6 +48,9 @@ struct cmd_struct {
/* if true don't list this token in help listings */
int hidden;
+
+ /* number of the extra short usage lines */
+ int lines;
};
struct cmd_group {
@@ -70,6 +73,7 @@ int handle_command_group(const struct cmd_group *grp, int argc,
/* help.c */
extern const char * const generic_cmd_help_usage[];
+void usage_lines(const char * const *usagestr, int lines);
void usage(const char * const *usagestr);
void usage_command(const struct cmd_struct *cmd, int full, int err);
void usage_command_group(const struct cmd_group *grp, int all, int err);
diff --git a/help.c b/help.c
index 6d04293..5679933 100644
--- a/help.c
+++ b/help.c
@@ -28,15 +28,21 @@ extern char argv0_buf[ARGV0_BUF_SIZE];
#define USAGE_LISTING 8U
static int do_usage_one_command(const char * const *usagestr,
- unsigned int flags, FILE *outf)
+ unsigned int flags, FILE *outf, int lines)
{
- int pad = 4;
+ int pad = 4, i = 0;
if (!usagestr || !*usagestr)
return -1;
fprintf(outf, "%s%s\n", (flags & USAGE_LISTING) ? " " : "usage: ",
*usagestr++);
+ for (i = 0; i < lines; i++) {
+ fprintf(outf, "%s%s\n",
+ (flags & USAGE_LISTING) ? " " : " ",
+ usagestr[i]);
+ }
+ usagestr += lines;
/* a short one-line description (mandatory) */
if ((flags & USAGE_SHORT) == 0)
@@ -79,7 +85,7 @@ static int do_usage_one_command(const char * const *usagestr,
static int usage_command_internal(const char * const *usagestr,
const char *token, int full, int lst,
- FILE *outf)
+ FILE *outf, int lines)
{
unsigned int flags = USAGE_SHORT;
int ret;
@@ -89,7 +95,7 @@ static int usage_command_internal(const char * const *usagestr,
if (lst)
flags |= USAGE_LISTING;
- ret = do_usage_one_command(usagestr, flags, outf);
+ ret = do_usage_one_command(usagestr, flags, outf, lines);
switch (ret) {
case -1:
fprintf(outf, "No usage for '%s'\n", token);
@@ -103,24 +109,31 @@ static int usage_command_internal(const char * const *usagestr,
}
static void usage_command_usagestr(const char * const *usagestr,
- const char *token, int full, int err)
+ const char *token, int full, int err, int lines)
{
FILE *outf = err ? stderr : stdout;
int ret;
- ret = usage_command_internal(usagestr, token, full, 0, outf);
+ ret = usage_command_internal(usagestr, token, full, 0, outf, lines);
if (!ret)
fputc('\n', outf);
}
void usage_command(const struct cmd_struct *cmd, int full, int err)
{
- usage_command_usagestr(cmd->usagestr, cmd->token, full, err);
+ usage_command_usagestr(
+ cmd->usagestr, cmd->token, full, err, cmd->lines);
}
void usage(const char * const *usagestr)
{
- usage_command_usagestr(usagestr, NULL, 1, 1);
+ usage_lines(usagestr, 0);
+ exit(129);
+}
+
+void usage_lines(const char * const *usagestr, int lines)
+{
+ usage_command_usagestr(usagestr, NULL, 1, 1, lines);
exit(129);
}
@@ -144,7 +157,7 @@ static void usage_command_group_internal(const struct cmd_group *grp, int full,
}
usage_command_internal(cmd->usagestr, cmd->token, full,
- 1, outf);
+ 1, outf, cmd->lines);
continue;
}
--
1.7.7.6
^ permalink raw reply related
* [Qemu-devel] [PATCH 2/2] hw/xtensa_sim: get rid of intermediate xtensa_sim_init
From: Max Filippov @ 2012-10-25 8:47 UTC (permalink / raw)
To: qemu-devel
Cc: Blue Swirl, Peter Maydell, Max Filippov, Markus Armbruster,
Eduardo Habkost
In-Reply-To: <1351154852-29217-1-git-send-email-jcmvbkbc@gmail.com>
Remove xtensa_sim_init that only explodes machine init args, rename
sim_init to xtensa_sim_init.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
---
hw/xtensa_sim.c | 27 ++++++++-------------------
1 files changed, 8 insertions(+), 19 deletions(-)
diff --git a/hw/xtensa_sim.c b/hw/xtensa_sim.c
index 2e846d8..0d633e4 100644
--- a/hw/xtensa_sim.c
+++ b/hw/xtensa_sim.c
@@ -44,16 +44,20 @@ static void sim_reset(void *opaque)
cpu_reset(CPU(cpu));
}
-static void sim_init(ram_addr_t ram_size,
- const char *boot_device,
- const char *kernel_filename, const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
+static void xtensa_sim_init(QEMUMachineInitArgs *args)
{
XtensaCPU *cpu = NULL;
CPUXtensaState *env = NULL;
MemoryRegion *ram, *rom;
+ ram_addr_t ram_size = args->ram_size;
+ const char *cpu_model = args->cpu_model;
+ const char *kernel_filename = args->kernel_filename;
int n;
+ if (!cpu_model) {
+ cpu_model = XTENSA_DEFAULT_CPU_MODEL;
+ }
+
for (n = 0; n < smp_cpus; n++) {
cpu = cpu_xtensa_init(cpu_model);
if (cpu == NULL) {
@@ -96,21 +100,6 @@ static void sim_init(ram_addr_t ram_size,
}
}
-static void xtensa_sim_init(QEMUMachineInitArgs *args)
-{
- ram_addr_t ram_size = args->ram_size;
- const char *cpu_model = args->cpu_model;
- const char *kernel_filename = args->kernel_filename;
- const char *kernel_cmdline = args->kernel_cmdline;
- const char *initrd_filename = args->initrd_filename;
- const char *boot_device = args->boot_device;
- if (!cpu_model) {
- cpu_model = XTENSA_DEFAULT_CPU_MODEL;
- }
- sim_init(ram_size, boot_device, kernel_filename, kernel_cmdline,
- initrd_filename, cpu_model);
-}
-
static QEMUMachine xtensa_sim_machine = {
.name = "sim",
.desc = "sim machine (" XTENSA_DEFAULT_CPU_MODEL ")",
--
1.7.7.6
^ permalink raw reply related
* [Qemu-devel] [PATCH 0/2] xtensa boards: don't prematurely explode QEMUMachineInitArgs
From: Max Filippov @ 2012-10-25 8:47 UTC (permalink / raw)
To: qemu-devel
Cc: Blue Swirl, Peter Maydell, Max Filippov, Markus Armbruster,
Eduardo Habkost
Max Filippov (2):
hw/xtensa_lx60: don't prematurely explode QEMUMachineInitArgs
hw/xtensa_sim: get rid of intermediate xtensa_sim_init
hw/xtensa_lx60.c | 25 ++++++-------------------
hw/xtensa_sim.c | 27 ++++++++-------------------
2 files changed, 14 insertions(+), 38 deletions(-)
--
1.7.7.6
^ permalink raw reply
* [Qemu-devel] [PATCH 1/2] hw/xtensa_lx60: don't prematurely explode QEMUMachineInitArgs
From: Max Filippov @ 2012-10-25 8:47 UTC (permalink / raw)
To: qemu-devel
Cc: Blue Swirl, Peter Maydell, Max Filippov, Markus Armbruster,
Eduardo Habkost
In-Reply-To: <1351154852-29217-1-git-send-email-jcmvbkbc@gmail.com>
Don't explode QEMUMachineInitArgs before passing it to lx_init.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
---
hw/xtensa_lx60.c | 25 ++++++-------------------
1 files changed, 6 insertions(+), 19 deletions(-)
diff --git a/hw/xtensa_lx60.c b/hw/xtensa_lx60.c
index 5dd2e08..b4d3b8e 100644
--- a/hw/xtensa_lx60.c
+++ b/hw/xtensa_lx60.c
@@ -156,9 +156,7 @@ static void lx60_reset(void *opaque)
}
static void lx_init(const LxBoardDesc *board,
- ram_addr_t ram_size, const char *boot_device,
- const char *kernel_filename, const char *kernel_cmdline,
- const char *initrd_filename, const char *cpu_model)
+ ram_addr_t ram_size, QEMUMachineInitArgs *args)
{
#ifdef TARGET_WORDS_BIGENDIAN
int be = 1;
@@ -171,6 +169,9 @@ static void lx_init(const LxBoardDesc *board,
MemoryRegion *ram, *rom, *system_io;
DriveInfo *dinfo;
pflash_t *flash = NULL;
+ const char *cpu_model = args->cpu_model;
+ const char *kernel_filename = args->kernel_filename;
+ const char *kernel_cmdline = args->kernel_cmdline;
int n;
if (!cpu_model) {
@@ -272,37 +273,23 @@ static void lx_init(const LxBoardDesc *board,
static void xtensa_lx60_init(QEMUMachineInitArgs *args)
{
ram_addr_t ram_size = args->ram_size;
- const char *cpu_model = args->cpu_model;
- const char *kernel_filename = args->kernel_filename;
- const char *kernel_cmdline = args->kernel_cmdline;
- const char *initrd_filename = args->initrd_filename;
- const char *boot_device = args->boot_device;
static const LxBoardDesc lx60_board = {
.flash_size = 0x400000,
.flash_sector_size = 0x10000,
.sram_size = 0x20000,
};
- lx_init(&lx60_board, ram_size, boot_device,
- kernel_filename, kernel_cmdline,
- initrd_filename, cpu_model);
+ lx_init(&lx60_board, ram_size, args);
}
static void xtensa_lx200_init(QEMUMachineInitArgs *args)
{
ram_addr_t ram_size = args->ram_size;
- const char *cpu_model = args->cpu_model;
- const char *kernel_filename = args->kernel_filename;
- const char *kernel_cmdline = args->kernel_cmdline;
- const char *initrd_filename = args->initrd_filename;
- const char *boot_device = args->boot_device;
static const LxBoardDesc lx200_board = {
.flash_size = 0x1000000,
.flash_sector_size = 0x20000,
.sram_size = 0x2000000,
};
- lx_init(&lx200_board, ram_size, boot_device,
- kernel_filename, kernel_cmdline,
- initrd_filename, cpu_model);
+ lx_init(&lx200_board, ram_size, args);
}
static QEMUMachine xtensa_lx60_machine = {
--
1.7.7.6
^ permalink raw reply related
* Re: [RFC v2 0/2] vmevent: A bit reworked pressure attribute + docs + man page
From: Minchan Kim @ 2012-10-25 8:53 UTC (permalink / raw)
To: Pekka Enberg
Cc: Anton Vorontsov, Mel Gorman, Leonid Moiseichuk, KOSAKI Motohiro,
Bartlomiej Zolnierkiewicz, John Stultz, linux-mm, linux-kernel,
linaro-kernel, patches, kernel-team, linux-man
In-Reply-To: <CAOJsxLGsjTe13WjY_Q=BLBELwQXOjuwo7PiEKwONHUfR4mQmig@mail.gmail.com>
Hi Pekka,
On Thu, Oct 25, 2012 at 09:44:52AM +0300, Pekka Enberg wrote:
> On Thu, Oct 25, 2012 at 9:40 AM, Minchan Kim <minchan@kernel.org> wrote:
> > Your description doesn't include why we need new vmevent_fd(2).
> > Of course, it's very flexible and potential to add new VM knob easily but
> > the thing we is about to use now is only VMEVENT_ATTR_PRESSURE.
> > Is there any other use cases for swap or free? or potential user?
> > Adding vmevent_fd without them is rather overkill.
>
> What ABI would you use instead?
I thought /dev/some_knob like mem_notify and epoll is enough but please keep in mind
that I'm not against vmevent_fd strongly. My point is that description should include
explain about why other candidate is not good or why vmevent_fd is better.
(But at least, I don't like vmevent timer polling still and I hope we use it
as last resort once we can find another)
>
> On Thu, Oct 25, 2012 at 9:40 AM, Minchan Kim <minchan@kernel.org> wrote:
> > I don't object but we need rationale for adding new system call which should
> > be maintained forever once we add it.
>
> Agreed.
>
> --
> 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/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
--
Kind regards,
Minchan Kim
^ permalink raw reply
* Re: [RFC v2 0/2] vmevent: A bit reworked pressure attribute + docs + man page
From: Minchan Kim @ 2012-10-25 8:53 UTC (permalink / raw)
To: Pekka Enberg
Cc: Anton Vorontsov, Mel Gorman, Leonid Moiseichuk, KOSAKI Motohiro,
Bartlomiej Zolnierkiewicz, John Stultz, linux-mm, linux-kernel,
linaro-kernel, patches, kernel-team, linux-man
In-Reply-To: <CAOJsxLGsjTe13WjY_Q=BLBELwQXOjuwo7PiEKwONHUfR4mQmig@mail.gmail.com>
Hi Pekka,
On Thu, Oct 25, 2012 at 09:44:52AM +0300, Pekka Enberg wrote:
> On Thu, Oct 25, 2012 at 9:40 AM, Minchan Kim <minchan@kernel.org> wrote:
> > Your description doesn't include why we need new vmevent_fd(2).
> > Of course, it's very flexible and potential to add new VM knob easily but
> > the thing we is about to use now is only VMEVENT_ATTR_PRESSURE.
> > Is there any other use cases for swap or free? or potential user?
> > Adding vmevent_fd without them is rather overkill.
>
> What ABI would you use instead?
I thought /dev/some_knob like mem_notify and epoll is enough but please keep in mind
that I'm not against vmevent_fd strongly. My point is that description should include
explain about why other candidate is not good or why vmevent_fd is better.
(But at least, I don't like vmevent timer polling still and I hope we use it
as last resort once we can find another)
>
> On Thu, Oct 25, 2012 at 9:40 AM, Minchan Kim <minchan@kernel.org> wrote:
> > I don't object but we need rationale for adding new system call which should
> > be maintained forever once we add it.
>
> Agreed.
>
> --
> 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/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
--
Kind regards,
Minchan Kim
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
From: Chris Wilson @ 2012-10-25 8:47 UTC (permalink / raw)
To: Daniel Vetter, Justin P. Mattock
Cc: dri-devel@lists.freedesktop.org, Linux Kernel Mailing List
In-Reply-To: <CAKMK7uFMaf=ohEKyWKNsd-mSQkW__0BUww_iYLNFo347mEYAMg@mail.gmail.com>
On Thu, 25 Oct 2012 10:16:08 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Thu, Oct 25, 2012 at 7:22 AM, Justin P. Mattock
> <justinmattock@gmail.com> wrote:
> >
> > here is a link to the file..: intel_error_decode
> > http://www.filefactory.com/file/22bypyjhs4mx
>
> I haven't figured out how to access this thing. Can you please file a
> bug report on bugs.freedesktop.org and attach it there?
No worries, it is another ILK hang similar to the ones reported earlier
- it just seems the ring stops advancing. Hopefully it is a missing w/a
from http://cgit.freedesktop.org/~danvet/drm/log/?h=ilk-wa-pile
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply
* Re: iMac (PM61) quieter fan?
From: Benjamin Herrenschmidt @ 2012-10-25 8:46 UTC (permalink / raw)
To: Jeremy Elgin; +Cc: linuxppc-dev
In-Reply-To: <26F74A8F-8BCD-4E97-99F4-8DF14C2568D6@jeremyelgin.me>
On Thu, 2012-10-25 at 16:13 +1300, Jeremy Elgin wrote:
> I'm running Ubuntu 12.04 on my iMac G4 1GHz (PowerMac6,1) and I've
> been looking for any installable option to quiet the fan, nothing I've
> found mentions PowerMac6,1 and the modules installed don't even
> mention different PM models, just therm_windtunnel.ko &
> windfarm_core.ko - this first module won't load (No such device) and
> the second isn't used by anything (yet), do I need to install a .deb
> package that'll talk to this module?
>
> I know this is not really about development but it's specific to PPC,
> ok? :-)
I don't know much about the fan control on the iMac G4. You can try
sending me a dump of /proc/device-tree (a tarball), it might tell us
more about what's in there.
> Oh, I also have a Dual 2.0 GHz G5 (PowerMac7,3) that I'm keen to get
> Ubuntu running on as a headless server and it'll need fan controls
> too. What I mean to say is, I'm keen to help out with these two pieces
> of hardware should you need testers for them specifically.
This should be fully supported already.
Cheers,
Ben.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [media-workshop] Tentative Agenda for the November workshop
From: Sylwester Nawrocki @ 2012-10-25 8:43 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: Hans Verkuil, media-workshop, linux-media
In-Reply-To: <1372729.rmYJ0LutvU@avalon>
Hi Laurent,
On 10/25/2012 12:42 AM, Laurent Pinchart wrote:
>>>> Sylwester, would Samsung be able to prepare for a brainstorming session
>>>> on Monday or Tuesday? Both Laurent and myself have presentations on
>>>> Wednesday, so that's not the best day for such a session.
>>
>> Kamil has presentation on Tuesday so there would be only Monday left.
>>
>>>> Do you think we should do a half-day or a full day session on this?
>>>
>>> Half a day should be more than enough to start with. The topic is quite
>>> complex, and we'll need to sleep over it, several times. A full day would
>>> just result in brain overheat. I was thinking more in the line of
>>> starting our thought process, so maybe twice an hour or two hours would
>>> be good. That would allow us to attend the ELCE talks as well :-)
>>> (there's definitely a couple of them that I would like to listen to).
>>
>> I agree, I wouldn't like to loose whole day of the conference for that
>> as well. One, two hours for the starters could be sufficient. So we can
>> possibly agree on some initial idea and could get back to it later.
>> I don't think I have already material for a full day session.
>
> One hour, possibly twice, would have my preference. That shouldn't be too
> difficult to organize. When will you and Kamil arrive ?
Sounds good to me. We'll arrive on Sunday afternoon, and staying until
next Sunday.
--
Regards,
Sylwester
^ permalink raw reply
* Re: t9401 fails with OS X sed
From: Jeff King @ 2012-10-25 8:41 UTC (permalink / raw)
To: Geert Bosch; +Cc: Brian Gernhardt, Git List
In-Reply-To: <F721B376-F4E6-4274-9A6E-BD1CFCBDA39F@adacore.com>
On Thu, Oct 25, 2012 at 01:04:11AM -0400, Geert Bosch wrote:
> On Oct 24, 2012, at 23:54, Brian Gernhardt <brian@gernhardtsoftware.com> wrote:
>
> > It works if I change \s to [[:space:]], but I don't know how portable that is.
>
> As \s is shorthand for the POSIX character class [:space:], I'd say the latter
> should be more portable: anything accepting the shorthand should also accept
> the full character class. If not, you probably only care about horizontal tab
> and space, for which you could just use a simple regular expression. Just a
> literal space and tab character between square brackets is probably going to be
> most portable, though not most readable.
I agree that the POSIX character class would be more portable than "\s",
but we do not have any existing uses of them, and I would worry a little
about older systems like Solaris. If we can simply use a literal space
and tab, that seems like the safest.
Brian, can you work up a patch?
-Peff
^ permalink raw reply
* Re: [PATCH V2 5/6] Thermal: Add ST-Ericsson DB8500 thermal dirver.
From: Viresh Kumar @ 2012-10-25 8:41 UTC (permalink / raw)
To: Hongbo Zhang, Amit Kucheria
Cc: linaro-dev, linux-kernel, linux-pm, STEricsson_nomadik_linux,
kernel, linaro-kernel, hongbo.zhang, patches
In-Reply-To: <CAJLyvQxEAeP__drUAAz6D_UeeDRvdqKdmim3xAO7sXP8cCM8=g@mail.gmail.com>
On 25 October 2012 13:56, Hongbo Zhang <hongbo.zhang@linaro.org> wrote:
While replying to mails, don't remove lines like above. They help
identifying who
wrote what.
> [...]
>>> +/* Callback to get temperature changing trend */
>>> +static int db8500_sys_get_trend(struct thermal_zone_device *thermal,
For example, you can't tell who wrote this line...
>>> +static int __devinit db8500_thermal_probe(struct platform_device *pdev)
>>> +{
>>> + struct db8500_thermal_zone *pzone = NULL;
>>> + struct db8500_thsens_platform_data *ptrips = NULL;
>>> + int low_irq, high_irq, ret = 0;
>>> + unsigned long dft_low, dft_high;
>>> +
>>> + pzone = devm_kzalloc(&pdev->dev, sizeof(*pzone), GFP_KERNEL);
>>> + if (!pzone)
>>> + return -ENOMEM;
>>> +
>>> + ptrips = db8500_thermal_parse_dt(pdev);
>>
>> This is what u have in this routine at the very first line:
>>
>> if (!np) {
>> dev_err(&pdev->dev, "Missing device tree data\n");
>>
>> So, you will end up printing this line for every non-DT case. Not good.
>> What u can do is, give preference to normal pdata here.
> I moved this if(!np) into parse_dt function, no problem again.
> (in fact have already done this, but it is missed in this sending)
Sorry couldn't get your point. :(
Can you share diff of latest code in the same mail thread?
>>> + ret = devm_request_threaded_irq(&pdev->dev, low_irq, NULL,
>>
>> why threaded irq?
> In fact PRCMU firmware is polling the thermal sensor, and if it meets
> threshold, the PRCMU will write this event into share memory (shared
> between PRCMU and ARM) and trigger an interrupt to ARM.
>
> There may be other events passed via share memory, so it is better to
> handle this kind of irq as fast as possible(it is always the policy),
> and threaded irq satisfies this case better then the traditional one.
Its been long that i prepared for an interview, but i believe purpose
of threaded
irq is something else.
There can be two use cases of request_irq()
- We don't want to sleep from interrupt handler, because we don't need to sleep
for reading hardware's register. And so handler must be called from interrupt
context. We use normal request_irq() here. This is the fastest one.
- We have to sleep from some part of interrupt handler, because we don't have
peripherals register on AMBA bus. But we have it on SPI or I2C bus,
where read/
write to SPI/I2C can potentially sleep. So, we want handler to execute from
process context and so use request_threaded_irq(), i.e. handler will
be called
from a thread. This will surely be slow.
Now in threaded irq case, we can give two handlers, one that must be called
from interrupt context and other that must be called from process context.
Both will be called one by one.
Sorry if i am wrong in my theory :(
@Amit: Am i correct??
Now, the same question again. Are you sure you want threaded irq here.
>>> + prcmu_low_irq_handler, IRQF_NO_SUSPEND | IRQF_ONESHOT,
>>> + "dbx500_temp_low", pzone);
^ permalink raw reply
* Re: [PATCH] pch_gbe: don't come up if we can't allocate buffers
From: Eric Dumazet @ 2012-10-25 8:40 UTC (permalink / raw)
To: Veaceslav Falico
Cc: netdev, davem, richardcochran, tshimizu818, andy.cress,
erwan.velu
In-Reply-To: <1351149005-13698-1-git-send-email-vfalico@redhat.com>
On Thu, 2012-10-25 at 09:10 +0200, Veaceslav Falico wrote:
> Currently, even if pch_gbe_alloc_tx/rx_buffers (even partially) fail, we
> bring the interface up. It mihgt confuse the user (if he requested specific
> amount of buffers) and can lead to different bugs.
>
> Add error handling to these functions and clean after them in case of
> failure. It also resolves a possible NULL pointer dereference in
> pch_gbe_alloc_tx_buffers(), in case of netdev_alloc_skb() failure. It's ok
> to (paritally) fail for pch_gbe_alloc_rx_buffers() in some situation, so
> don't clean inside and rather handle skb freeing outside of the function.
>
> This patch also adds tx_alloc_buff_failed ethtool counter.
This should not be needed :
> -static void pch_gbe_alloc_tx_buffers(struct pch_gbe_adapter *adapter,
> +static int pch_gbe_alloc_tx_buffers(struct pch_gbe_adapter *adapter,
> struct pch_gbe_tx_ring *tx_ring)
> {
> struct pch_gbe_buffer *buffer_info;
> @@ -1506,6 +1521,7 @@ static void pch_gbe_alloc_tx_buffers(struct pch_gbe_adapter *adapter,
> unsigned int i;
> unsigned int bufsz;
> struct pch_gbe_tx_desc *tx_desc;
> + int err;
>
> bufsz =
> adapter->hw.mac.max_frame_size + PCH_GBE_DMA_ALIGN + NET_IP_ALIGN;
> @@ -1513,12 +1529,26 @@ static void pch_gbe_alloc_tx_buffers(struct pch_gbe_adapter *adapter,
> for (i = 0; i < tx_ring->count; i++) {
> buffer_info = &tx_ring->buffer_info[i];
> skb = netdev_alloc_skb(adapter->netdev, bufsz);
> + if (unlikely(!skb)) {
> + adapter->stats.tx_alloc_buff_failed++;
> + err = -ENOMEM;
> + goto freeall;
> + }
Hmmm
These skbs should be allocated using GFP_KERNEL, to lower risk of OOM,
using a mere alloc_skb(bufsz, GFP_KERNEL)
Only skbs for rx 'need' netdev_alloc_skb() to add a NET_SKB_PAD
headroom.
skb = alloc_skb(bufsz, GFP_KERNEL);
if (!skb)
goto fail;
skb_reserve(skb, NET_IP_ALIGN);
And BTW, we dont really need skbs here, only a bounce buffer so that we
can copy frames on it... (kmalloc() instead of alloc_skb())
> skb_reserve(skb, PCH_GBE_DMA_ALIGN);
PCH_GBE_DMA_ALIGN is zero ...
> buffer_info->skb = skb;
> tx_desc = PCH_GBE_TX_DESC(*tx_ring, i);
> tx_desc->gbec_status = (DSC_INIT16);
> }
> - return;
> + return 0;
> +
> +freeall:
> + for (i--; i >= 0; i--) {
> + dev_kfree_skb_any(buffer_info->skb);
> + buffer_info->skb = NULL;
> + tx_desc = PCH_GBE_TX_DESC(*tx_ring, i);
> + tx_desc->gbec_status = 0;
> + }
> + return err;
> }
>
Also I would call pch_gbe_alloc_tx_buffers() _after_
pch_gbe_alloc_rx_buffers() (Since rx allocations probably are using
GFP_ATOMIC allocations)
^ permalink raw reply
* [PATCH] ext4: do not try to write superblock on journal-less readonly remount
From: Michael Tokarev @ 2012-10-25 8:39 UTC (permalink / raw)
To: linux-ext4; +Cc: sandeen, Michael Tokarev
When a journal-less ext4 filesystem is mounted on a read-only block
device (blockdev --setro will do), each remount (for other, unrelated,
flags, like suid=>nosuid etc) results in a series of scary messages
from kernel telling about I/O errors on the device.
This is becauese of the following code ext4_remount():
if (sbi->s_journal == NULL)
ext4_commit_super(sb, 1);
at the end of remount procedure, which forces writing (flushing) of
a superblock regardless whenever it is dirty or not, if the filesystem
is readonly or not, and whenever the device itself is readonly or not.
The proposed fix tests whenever both old mount flags and new mount
flags does not include MS_READONLY, and only in this case calls
ext4_commit_super().
Maybe it is sufficient to check for MS_READONLY just in old mount
options (old_sb_flags). Note this is journal-less mode, so, for
example, we weren't have journal replay operation, so if old flags
include MS_REASONLY, we shuold have no dirty blocks at all, and
there's no reason to call ext4_commit_super().
But only in case both old and new flags include MS_READONLY we're
certain we will not write anything - if new flag does not include
this bit, we will write sooner or later anyway, so preventing just
one commit_super() at the _beginning_ of mount is not really necessary.
This change probably applicable to -stable, -- not because it fixes
a serious bug, but because the messages printed by the kernel are
rather scary for an average user. On the other hand, actual usage
of ext4 in nojournal mode on a read-only medium is very rare.
Thanks to Eric Sandeen for help in diagnosing this issue.
Signed-off-By: Michael Tokarev <mjt@tls.msk.ru>
---
fs/ext4/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 3e0851e..2e896fd 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -4687,7 +4687,7 @@ static int ext4_remount(struct super_block *sb, int *flags, char *data)
}
ext4_setup_system_zone(sb);
- if (sbi->s_journal == NULL)
+ if (sbi->s_journal == NULL && !(sb->s_flags & old_sb_flags & MS_RDONLY))
ext4_commit_super(sb, 1);
unlock_super(sb);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
From: Laurent Pinchart @ 2012-10-25 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025002056.2082.45221.stgit@muffinssi.local>
Hi Tony,
Thanks for the patch.
On Wednesday 24 October 2012 17:20:56 Tony Lindgren wrote:
> Looks like the iommu framework does not have generic functions
> exported for all the needs yet. The hardware specific functions
> are defined in files like intel-iommu.h and amd-iommu.h. Follow
> the same standard for omap-iommu.h.
>
> This is needed because we are removing plat and mach includes
> for ARM common zImage support. Further work should continue
> in the iommu framework context as only pure platform data will
> be communicated from arch/arm/*omap*/* code to the iommu
> framework.
>
> Cc: Joerg Roedel <joerg.roedel@amd.com>
> Cc: Ohad Ben-Cohen <ohad@wizery.com>
> Cc: Ido Yariv <ido@wizery.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Omar Ramirez Luna <omar.luna@linaro.org>
> Cc: linux-media at vger.kernel.org
> Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/mach-omap2/iommu2.c | 1
> arch/arm/plat-omap/include/plat/iommu.h | 10 +--
> arch/arm/plat-omap/include/plat/iovmm.h | 89
> ---------------------------- drivers/iommu/omap-iommu-debug.c |
> 2 -
> drivers/iommu/omap-iommu.c | 1
> drivers/iommu/omap-iovmm.c | 46 ++++++++++++++
> drivers/media/platform/omap3isp/isp.c | 1
> drivers/media/platform/omap3isp/isp.h | 4 -
> drivers/media/platform/omap3isp/ispccdc.c | 1
> drivers/media/platform/omap3isp/ispstat.c | 1
> drivers/media/platform/omap3isp/ispvideo.c | 2 -
> include/linux/omap-iommu.h | 52 ++++++++++++++++
> 12 files changed, 107 insertions(+), 103 deletions(-)
> delete mode 100644 arch/arm/plat-omap/include/plat/iovmm.h
> create mode 100644 include/linux/omap-iommu.h
>
> diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
> index eefc379..e8116cf 100644
> --- a/arch/arm/mach-omap2/iommu2.c
> +++ b/arch/arm/mach-omap2/iommu2.c
> @@ -15,6 +15,7 @@
> #include <linux/device.h>
> #include <linux/jiffies.h>
> #include <linux/module.h>
> +#include <linux/omap-iommu.h>
> #include <linux/slab.h>
> #include <linux/stringify.h>
>
> diff --git a/arch/arm/plat-omap/include/plat/iommu.h
> b/arch/arm/plat-omap/include/plat/iommu.h index 7e8c7b6..a4b71b1 100644
> --- a/arch/arm/plat-omap/include/plat/iommu.h
> +++ b/arch/arm/plat-omap/include/plat/iommu.h
> @@ -216,13 +216,10 @@ static inline struct omap_iommu
> *dev_to_omap_iommu(struct device *dev) #define MMU_RAM_PADDR_SHIFT 12
> #define MMU_RAM_PADDR_MASK \
> ((~0UL >> MMU_RAM_PADDR_SHIFT) << MMU_RAM_PADDR_SHIFT)
> -#define MMU_RAM_ENDIAN_SHIFT 9
> +
> #define MMU_RAM_ENDIAN_MASK (1 << MMU_RAM_ENDIAN_SHIFT)
> -#define MMU_RAM_ENDIAN_BIG (1 << MMU_RAM_ENDIAN_SHIFT)
> -#define MMU_RAM_ENDIAN_LITTLE (0 << MMU_RAM_ENDIAN_SHIFT)
> -#define MMU_RAM_ELSZ_SHIFT 7
> #define MMU_RAM_ELSZ_MASK (3 << MMU_RAM_ELSZ_SHIFT)
> -#define MMU_RAM_ELSZ_8 (0 << MMU_RAM_ELSZ_SHIFT)
> +
> #define MMU_RAM_ELSZ_16 (1 << MMU_RAM_ELSZ_SHIFT)
> #define MMU_RAM_ELSZ_32 (2 << MMU_RAM_ELSZ_SHIFT)
> #define MMU_RAM_ELSZ_NONE (3 << MMU_RAM_ELSZ_SHIFT)
> @@ -269,9 +266,6 @@ extern int omap_iommu_set_isr(const char *name,
> void *priv),
> void *isr_priv);
>
> -extern void omap_iommu_save_ctx(struct device *dev);
> -extern void omap_iommu_restore_ctx(struct device *dev);
> -
> extern int omap_install_iommu_arch(const struct iommu_functions *ops);
> extern void omap_uninstall_iommu_arch(const struct iommu_functions *ops);
>
> diff --git a/arch/arm/plat-omap/include/plat/iovmm.h
> b/arch/arm/plat-omap/include/plat/iovmm.h deleted file mode 100644
> index 498e57c..0000000
> --- a/arch/arm/plat-omap/include/plat/iovmm.h
> +++ /dev/null
> @@ -1,89 +0,0 @@
> -/*
> - * omap iommu: simple virtual address space management
> - *
> - * Copyright (C) 2008-2009 Nokia Corporation
> - *
> - * Written by Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> - */
> -
> -#ifndef __IOMMU_MMAP_H
> -#define __IOMMU_MMAP_H
> -
> -#include <linux/iommu.h>
> -
> -struct iovm_struct {
> - struct omap_iommu *iommu; /* iommu object which this belongs to */
> - u32 da_start; /* area definition */
> - u32 da_end;
> - u32 flags; /* IOVMF_: see below */
> - struct list_head list; /* linked in ascending order */
> - const struct sg_table *sgt; /* keep 'page' <-> 'da' mapping */
> - void *va; /* mpu side mapped address */
> -};
> -
> -/*
> - * IOVMF_FLAGS: attribute for iommu virtual memory area(iovma)
> - *
> - * lower 16 bit is used for h/w and upper 16 bit is for s/w.
> - */
> -#define IOVMF_SW_SHIFT 16
> -
> -/*
> - * iovma: h/w flags derived from cam and ram attribute
> - */
> -#define IOVMF_CAM_MASK (~((1 << 10) - 1))
> -#define IOVMF_RAM_MASK (~IOVMF_CAM_MASK)
> -
> -#define IOVMF_PGSZ_MASK (3 << 0)
> -#define IOVMF_PGSZ_1M MMU_CAM_PGSZ_1M
> -#define IOVMF_PGSZ_64K MMU_CAM_PGSZ_64K
> -#define IOVMF_PGSZ_4K MMU_CAM_PGSZ_4K
> -#define IOVMF_PGSZ_16M MMU_CAM_PGSZ_16M
> -
> -#define IOVMF_ENDIAN_MASK (1 << 9)
> -#define IOVMF_ENDIAN_BIG MMU_RAM_ENDIAN_BIG
> -#define IOVMF_ENDIAN_LITTLE MMU_RAM_ENDIAN_LITTLE
> -
> -#define IOVMF_ELSZ_MASK (3 << 7)
> -#define IOVMF_ELSZ_8 MMU_RAM_ELSZ_8
> -#define IOVMF_ELSZ_16 MMU_RAM_ELSZ_16
> -#define IOVMF_ELSZ_32 MMU_RAM_ELSZ_32
> -#define IOVMF_ELSZ_NONE MMU_RAM_ELSZ_NONE
> -
> -#define IOVMF_MIXED_MASK (1 << 6)
> -#define IOVMF_MIXED MMU_RAM_MIXED
> -
> -/*
> - * iovma: s/w flags, used for mapping and umapping internally.
> - */
> -#define IOVMF_MMIO (1 << IOVMF_SW_SHIFT)
> -#define IOVMF_ALLOC (2 << IOVMF_SW_SHIFT)
> -#define IOVMF_ALLOC_MASK (3 << IOVMF_SW_SHIFT)
> -
> -/* "superpages" is supported just with physically linear pages */
> -#define IOVMF_DISCONT (1 << (2 + IOVMF_SW_SHIFT))
> -#define IOVMF_LINEAR (2 << (2 + IOVMF_SW_SHIFT))
> -#define IOVMF_LINEAR_MASK (3 << (2 + IOVMF_SW_SHIFT))
> -
> -#define IOVMF_DA_FIXED (1 << (4 + IOVMF_SW_SHIFT))
> -
> -
> -extern struct iovm_struct *omap_find_iovm_area(struct device *dev, u32 da);
> -extern u32
> -omap_iommu_vmap(struct iommu_domain *domain, struct device *dev, u32 da,
> - const struct sg_table *sgt, u32 flags);
> -extern struct sg_table *omap_iommu_vunmap(struct iommu_domain *domain,
> - struct device *dev, u32 da);
> -extern u32
> -omap_iommu_vmalloc(struct iommu_domain *domain, struct device *dev,
> - u32 da, size_t bytes, u32 flags);
> -extern void
> -omap_iommu_vfree(struct iommu_domain *domain, struct device *dev,
> - const u32 da);
> -extern void *omap_da_to_va(struct device *dev, u32 da);
> -
> -#endif /* __IOMMU_MMAP_H */
> diff --git a/drivers/iommu/omap-iommu-debug.c
> b/drivers/iommu/omap-iommu-debug.c index 0cac372..cf4a0b5 100644
> --- a/drivers/iommu/omap-iommu-debug.c
> +++ b/drivers/iommu/omap-iommu-debug.c
> @@ -18,9 +18,9 @@
> #include <linux/uaccess.h>
> #include <linux/platform_device.h>
> #include <linux/debugfs.h>
> +#include <linux/omap-iommu.h>
>
> #include <plat/iommu.h>
> -#include <plat/iovmm.h>
>
> #include "omap-iopgtable.h"
>
> diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
> index f2bbfb0..eadcfde 100644
> --- a/drivers/iommu/omap-iommu.c
> +++ b/drivers/iommu/omap-iommu.c
> @@ -19,6 +19,7 @@
> #include <linux/clk.h>
> #include <linux/platform_device.h>
> #include <linux/iommu.h>
> +#include <linux/omap-iommu.h>
> #include <linux/mutex.h>
> #include <linux/spinlock.h>
>
> diff --git a/drivers/iommu/omap-iovmm.c b/drivers/iommu/omap-iovmm.c
> index b332392..9852101 100644
> --- a/drivers/iommu/omap-iovmm.c
> +++ b/drivers/iommu/omap-iovmm.c
> @@ -17,15 +17,59 @@
> #include <linux/device.h>
> #include <linux/scatterlist.h>
> #include <linux/iommu.h>
> +#include <linux/omap-iommu.h>
>
> #include <asm/cacheflush.h>
> #include <asm/mach/map.h>
>
> #include <plat/iommu.h>
> -#include <plat/iovmm.h>
>
> #include "omap-iopgtable.h"
>
> +/*
> + * IOVMF_FLAGS: attribute for iommu virtual memory area(iovma)
> + *
> + * lower 16 bit is used for h/w and upper 16 bit is for s/w.
> + */
> +#define IOVMF_SW_SHIFT 16
> +
> +/*
> + * iovma: h/w flags derived from cam and ram attribute
> + */
> +#define IOVMF_CAM_MASK (~((1 << 10) - 1))
> +#define IOVMF_RAM_MASK (~IOVMF_CAM_MASK)
> +
> +#define IOVMF_PGSZ_MASK (3 << 0)
> +#define IOVMF_PGSZ_1M MMU_CAM_PGSZ_1M
> +#define IOVMF_PGSZ_64K MMU_CAM_PGSZ_64K
> +#define IOVMF_PGSZ_4K MMU_CAM_PGSZ_4K
> +#define IOVMF_PGSZ_16M MMU_CAM_PGSZ_16M
> +
> +#define IOVMF_ENDIAN_MASK (1 << 9)
> +#define IOVMF_ENDIAN_BIG MMU_RAM_ENDIAN_BIG
> +
> +#define IOVMF_ELSZ_MASK (3 << 7)
> +#define IOVMF_ELSZ_16 MMU_RAM_ELSZ_16
> +#define IOVMF_ELSZ_32 MMU_RAM_ELSZ_32
> +#define IOVMF_ELSZ_NONE MMU_RAM_ELSZ_NONE
> +
> +#define IOVMF_MIXED_MASK (1 << 6)
> +#define IOVMF_MIXED MMU_RAM_MIXED
> +
> +/*
> + * iovma: s/w flags, used for mapping and umapping internally.
> + */
> +#define IOVMF_MMIO (1 << IOVMF_SW_SHIFT)
> +#define IOVMF_ALLOC (2 << IOVMF_SW_SHIFT)
> +#define IOVMF_ALLOC_MASK (3 << IOVMF_SW_SHIFT)
> +
> +/* "superpages" is supported just with physically linear pages */
> +#define IOVMF_DISCONT (1 << (2 + IOVMF_SW_SHIFT))
> +#define IOVMF_LINEAR (2 << (2 + IOVMF_SW_SHIFT))
> +#define IOVMF_LINEAR_MASK (3 << (2 + IOVMF_SW_SHIFT))
> +
> +#define IOVMF_DA_FIXED (1 << (4 + IOVMF_SW_SHIFT))
> +
> static struct kmem_cache *iovm_area_cachep;
>
> /* return the offset of the first scatterlist entry in a sg table */
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c index 99640d8..7f182f0 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -61,6 +61,7 @@
> #include <linux/i2c.h>
> #include <linux/interrupt.h>
> #include <linux/module.h>
> +#include <linux/omap-iommu.h>
> #include <linux/platform_device.h>
> #include <linux/regulator/consumer.h>
> #include <linux/slab.h>
> diff --git a/drivers/media/platform/omap3isp/isp.h
> b/drivers/media/platform/omap3isp/isp.h index 8be7487..8d68669 100644
> --- a/drivers/media/platform/omap3isp/isp.h
> +++ b/drivers/media/platform/omap3isp/isp.h
> @@ -31,11 +31,9 @@
> #include <media/v4l2-device.h>
> #include <linux/device.h>
> #include <linux/io.h>
> +#include <linux/iommu.h>
> #include <linux/platform_device.h>
> #include <linux/wait.h>
> -#include <linux/iommu.h>
> -#include <plat/iommu.h>
> -#include <plat/iovmm.h>
>
> #include "ispstat.h"
> #include "ispccdc.h"
> diff --git a/drivers/media/platform/omap3isp/ispccdc.c
> b/drivers/media/platform/omap3isp/ispccdc.c index 60181ab..6ae1ffb2 100644
> --- a/drivers/media/platform/omap3isp/ispccdc.c
> +++ b/drivers/media/platform/omap3isp/ispccdc.c
> @@ -30,6 +30,7 @@
> #include <linux/device.h>
> #include <linux/dma-mapping.h>
> #include <linux/mm.h>
> +#include <linux/omap-iommu.h>
> #include <linux/sched.h>
> #include <linux/slab.h>
> #include <media/v4l2-event.h>
> diff --git a/drivers/media/platform/omap3isp/ispstat.c
> b/drivers/media/platform/omap3isp/ispstat.c index d7ac76b..35c3823 100644
> --- a/drivers/media/platform/omap3isp/ispstat.c
> +++ b/drivers/media/platform/omap3isp/ispstat.c
> @@ -26,6 +26,7 @@
> */
>
> #include <linux/dma-mapping.h>
> +#include <linux/omap-iommu.h>
> #include <linux/slab.h>
> #include <linux/uaccess.h>
>
> diff --git a/drivers/media/platform/omap3isp/ispvideo.c
> b/drivers/media/platform/omap3isp/ispvideo.c index a0b737fe..a4b8290 100644
> --- a/drivers/media/platform/omap3isp/ispvideo.c
> +++ b/drivers/media/platform/omap3isp/ispvideo.c
> @@ -27,6 +27,7 @@
> #include <linux/clk.h>
> #include <linux/mm.h>
> #include <linux/module.h>
> +#include <linux/omap-iommu.h>
> #include <linux/pagemap.h>
> #include <linux/scatterlist.h>
> #include <linux/sched.h>
> @@ -35,7 +36,6 @@
> #include <media/v4l2-dev.h>
> #include <media/v4l2-ioctl.h>
> #include <plat/iommu.h>
> -#include <plat/iovmm.h>
> #include <plat/omap-pm.h>
>
> #include "ispvideo.h"
> diff --git a/include/linux/omap-iommu.h b/include/linux/omap-iommu.h
> new file mode 100644
> index 0000000..cac78de
> --- /dev/null
> +++ b/include/linux/omap-iommu.h
> @@ -0,0 +1,52 @@
> +/*
> + * omap iommu: simple virtual address space management
> + *
> + * Copyright (C) 2008-2009 Nokia Corporation
> + *
> + * Written by Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef _INTEL_IOMMU_H_
> +#define _INTEL_IOMMU_H_
> +
> +struct iovm_struct {
> + struct omap_iommu *iommu; /* iommu object which this belongs to */
> + u32 da_start; /* area definition */
> + u32 da_end;
> + u32 flags; /* IOVMF_: see below */
> + struct list_head list; /* linked in ascending order */
> + const struct sg_table *sgt; /* keep 'page' <-> 'da' mapping */
> + void *va; /* mpu side mapped address */
> +};
> +
> +#define MMU_RAM_ENDIAN_SHIFT 9
> +#define MMU_RAM_ENDIAN_LITTLE (0 << MMU_RAM_ENDIAN_SHIFT)
> +#define MMU_RAM_ELSZ_8 (0 << MMU_RAM_ELSZ_SHIFT)
> +#define IOVMF_ENDIAN_LITTLE MMU_RAM_ENDIAN_LITTLE
> +#define MMU_RAM_ELSZ_SHIFT 7
> +#define IOVMF_ELSZ_8 MMU_RAM_ELSZ_8
> +
> +struct iommu_domain;
> +
> +extern struct iovm_struct *omap_find_iovm_area(struct device *dev, u32 da);
> +extern u32
> +omap_iommu_vmap(struct iommu_domain *domain, struct device *dev, u32 da,
> + const struct sg_table *sgt, u32 flags);
> +extern struct sg_table *omap_iommu_vunmap(struct iommu_domain *domain,
> + struct device *dev, u32 da);
> +extern u32
> +omap_iommu_vmalloc(struct iommu_domain *domain, struct device *dev,
> + u32 da, size_t bytes, u32 flags);
> +extern void
> +omap_iommu_vfree(struct iommu_domain *domain, struct device *dev,
> + const u32 da);
> +extern void *omap_da_to_va(struct device *dev, u32 da);
> +
> +extern void omap_iommu_save_ctx(struct device *dev);
> +extern void omap_iommu_restore_ctx(struct device *dev);
> +
> +#endif
I still think you should split this in two files, omap-iommu.h and omap-
iovmm.h. The later would just be arch/arm/plat-omap/include/plat/iovmm.h moved
to include/linux.h.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFC 1/2] vmevent: Implement pressure attribute
From: Minchan Kim @ 2012-10-25 8:38 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Pekka Enberg, Mel Gorman, Leonid Moiseichuk, KOSAKI Motohiro,
Bartlomiej Zolnierkiewicz, John Stultz, linux-mm, linux-kernel,
linaro-kernel, patches, kernel-team, linux-man
In-Reply-To: <20121025022321.GA8892@lizard>
On Wed, Oct 24, 2012 at 07:23:21PM -0700, Anton Vorontsov wrote:
> Hello Pekka,
>
> Thanks for taking a look into this!
>
> On Wed, Oct 24, 2012 at 12:03:10PM +0300, Pekka Enberg wrote:
> > On Mon, 22 Oct 2012, Anton Vorontsov wrote:
> > > This patch introduces VMEVENT_ATTR_PRESSURE, the attribute reports Linux
> > > virtual memory management pressure. There are three discrete levels:
> > >
> > > VMEVENT_PRESSURE_LOW: Notifies that the system is reclaiming memory for
> > > new allocations. Monitoring reclaiming activity might be useful for
> > > maintaining overall system's cache level.
> > >
> > > VMEVENT_PRESSURE_MED: The system is experiencing medium memory pressure,
> > > there is some mild swapping activity. Upon this event applications may
> > > decide to free any resources that can be easily reconstructed or re-read
> > > from a disk.
> >
> > Nit:
> >
> > s/VMEVENT_PRESSURE_MED/VMEVENT_PRESSUDE_MEDIUM/
>
> Sure thing, will change.
>
> > Other than that, I'm OK with this. Mel and others, what are your thoughts
> > on this?
> >
> > Anton, have you tested this with real world scenarios?
>
> Yup, I was mostly testing it on a desktop. I.e. in a KVM instance I was
> running a full fedora17 desktop w/ a lot of apps opened. The pressure
> index was pretty good in the sense that it was indeed reflecting the
> sluggishness in the system during swap activity. It's not ideal, i.e. the
> index might drop slightly for some time, but we usually interested in
> "above some value" threshold, so it should be fine.
>
> The _LOW level is defined very strictly, and cannot be tuned anyhow. So
> it's very solid, and that's what we mostly use for Android.
>
> The _OOM level is also defined quite strict, so from the API point of
> view, it's also solid, and should not be a problem.
The one of the concern when I see the code is that whether we should consider
high order page allocation. Now OOM killer doesn't kill anyone when VM
suffer from higher order allocation because it doesn't help getting physical
contiguos memory in normal case. Same rule could be applied.
>
> Although the problem with _OOM is delivering the event in time (i.e. we
> must be quick in predicting it, before OOMK triggers). Today the patch has
Absolutely. It was a biggest challenge.
> a shortcut for _OOM level: we send _OOM notification when reclaimer's
> priority is below empirically found value '3' (we might make it tunable
> via sysctl too, but that would expose another mm detail -- although sysctl
> sounds not that bad as exposing something in the C API; we have plenty of
> mm knobs in /proc/sys/vm/ already).
Hmm, I'm not sure depending on such magic value is good idea but I have no idea
so I will shut up :(
>
> The real tunable is _MED level, and this should be tuned based on the
> desired system's behaviour that I described in more detail in this long
> post: http://lkml.org/lkml/2012/10/7/29.
>
> Based on my observations, I wouldn't say that we have plenty of room to
> tune the value, though. Usual swapping activity causes index to rise to
> say to 30%, and when the system can't keep up, it raises to 50..90 (but we
> still have plenty of swap space, so the system is far away from OOM,
> although it is thrashing. Ideally I'd prefer to not have any sysctl, but I
> believe _MED level is really based on user's definition of "medium".
>
> > How does it stack up against Android's low memory killer, for example?
>
> The LMK driver is effectively using what we call _LOW pressure
> notifications here, so by definition it is enough to build a full
> replacement for the in-kernel LMK using just the _LOW level. But in the
> future, we might want to use _MED as well, e.g. kill unneeded services
> based not on the cache level, but based on the pressure.
Good idea.
Thanks for keeping trying this, Anton!
>
> Thanks,
> Anton.
>
> --
> 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/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
--
Kind regards,
Minchan Kim
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
From: Laurent Pinchart @ 2012-10-25 8:39 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-arm-kernel, Ohad Ben-Cohen, Mauro Carvalho Chehab,
Joerg Roedel, Omar Ramirez Luna, linux-omap, Ido Yariv,
linux-media
In-Reply-To: <20121025002056.2082.45221.stgit@muffinssi.local>
Hi Tony,
Thanks for the patch.
On Wednesday 24 October 2012 17:20:56 Tony Lindgren wrote:
> Looks like the iommu framework does not have generic functions
> exported for all the needs yet. The hardware specific functions
> are defined in files like intel-iommu.h and amd-iommu.h. Follow
> the same standard for omap-iommu.h.
>
> This is needed because we are removing plat and mach includes
> for ARM common zImage support. Further work should continue
> in the iommu framework context as only pure platform data will
> be communicated from arch/arm/*omap*/* code to the iommu
> framework.
>
> Cc: Joerg Roedel <joerg.roedel@amd.com>
> Cc: Ohad Ben-Cohen <ohad@wizery.com>
> Cc: Ido Yariv <ido@wizery.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Omar Ramirez Luna <omar.luna@linaro.org>
> Cc: linux-media@vger.kernel.org
> Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/mach-omap2/iommu2.c | 1
> arch/arm/plat-omap/include/plat/iommu.h | 10 +--
> arch/arm/plat-omap/include/plat/iovmm.h | 89
> ---------------------------- drivers/iommu/omap-iommu-debug.c |
> 2 -
> drivers/iommu/omap-iommu.c | 1
> drivers/iommu/omap-iovmm.c | 46 ++++++++++++++
> drivers/media/platform/omap3isp/isp.c | 1
> drivers/media/platform/omap3isp/isp.h | 4 -
> drivers/media/platform/omap3isp/ispccdc.c | 1
> drivers/media/platform/omap3isp/ispstat.c | 1
> drivers/media/platform/omap3isp/ispvideo.c | 2 -
> include/linux/omap-iommu.h | 52 ++++++++++++++++
> 12 files changed, 107 insertions(+), 103 deletions(-)
> delete mode 100644 arch/arm/plat-omap/include/plat/iovmm.h
> create mode 100644 include/linux/omap-iommu.h
>
> diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
> index eefc379..e8116cf 100644
> --- a/arch/arm/mach-omap2/iommu2.c
> +++ b/arch/arm/mach-omap2/iommu2.c
> @@ -15,6 +15,7 @@
> #include <linux/device.h>
> #include <linux/jiffies.h>
> #include <linux/module.h>
> +#include <linux/omap-iommu.h>
> #include <linux/slab.h>
> #include <linux/stringify.h>
>
> diff --git a/arch/arm/plat-omap/include/plat/iommu.h
> b/arch/arm/plat-omap/include/plat/iommu.h index 7e8c7b6..a4b71b1 100644
> --- a/arch/arm/plat-omap/include/plat/iommu.h
> +++ b/arch/arm/plat-omap/include/plat/iommu.h
> @@ -216,13 +216,10 @@ static inline struct omap_iommu
> *dev_to_omap_iommu(struct device *dev) #define MMU_RAM_PADDR_SHIFT 12
> #define MMU_RAM_PADDR_MASK \
> ((~0UL >> MMU_RAM_PADDR_SHIFT) << MMU_RAM_PADDR_SHIFT)
> -#define MMU_RAM_ENDIAN_SHIFT 9
> +
> #define MMU_RAM_ENDIAN_MASK (1 << MMU_RAM_ENDIAN_SHIFT)
> -#define MMU_RAM_ENDIAN_BIG (1 << MMU_RAM_ENDIAN_SHIFT)
> -#define MMU_RAM_ENDIAN_LITTLE (0 << MMU_RAM_ENDIAN_SHIFT)
> -#define MMU_RAM_ELSZ_SHIFT 7
> #define MMU_RAM_ELSZ_MASK (3 << MMU_RAM_ELSZ_SHIFT)
> -#define MMU_RAM_ELSZ_8 (0 << MMU_RAM_ELSZ_SHIFT)
> +
> #define MMU_RAM_ELSZ_16 (1 << MMU_RAM_ELSZ_SHIFT)
> #define MMU_RAM_ELSZ_32 (2 << MMU_RAM_ELSZ_SHIFT)
> #define MMU_RAM_ELSZ_NONE (3 << MMU_RAM_ELSZ_SHIFT)
> @@ -269,9 +266,6 @@ extern int omap_iommu_set_isr(const char *name,
> void *priv),
> void *isr_priv);
>
> -extern void omap_iommu_save_ctx(struct device *dev);
> -extern void omap_iommu_restore_ctx(struct device *dev);
> -
> extern int omap_install_iommu_arch(const struct iommu_functions *ops);
> extern void omap_uninstall_iommu_arch(const struct iommu_functions *ops);
>
> diff --git a/arch/arm/plat-omap/include/plat/iovmm.h
> b/arch/arm/plat-omap/include/plat/iovmm.h deleted file mode 100644
> index 498e57c..0000000
> --- a/arch/arm/plat-omap/include/plat/iovmm.h
> +++ /dev/null
> @@ -1,89 +0,0 @@
> -/*
> - * omap iommu: simple virtual address space management
> - *
> - * Copyright (C) 2008-2009 Nokia Corporation
> - *
> - * Written by Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> - */
> -
> -#ifndef __IOMMU_MMAP_H
> -#define __IOMMU_MMAP_H
> -
> -#include <linux/iommu.h>
> -
> -struct iovm_struct {
> - struct omap_iommu *iommu; /* iommu object which this belongs to */
> - u32 da_start; /* area definition */
> - u32 da_end;
> - u32 flags; /* IOVMF_: see below */
> - struct list_head list; /* linked in ascending order */
> - const struct sg_table *sgt; /* keep 'page' <-> 'da' mapping */
> - void *va; /* mpu side mapped address */
> -};
> -
> -/*
> - * IOVMF_FLAGS: attribute for iommu virtual memory area(iovma)
> - *
> - * lower 16 bit is used for h/w and upper 16 bit is for s/w.
> - */
> -#define IOVMF_SW_SHIFT 16
> -
> -/*
> - * iovma: h/w flags derived from cam and ram attribute
> - */
> -#define IOVMF_CAM_MASK (~((1 << 10) - 1))
> -#define IOVMF_RAM_MASK (~IOVMF_CAM_MASK)
> -
> -#define IOVMF_PGSZ_MASK (3 << 0)
> -#define IOVMF_PGSZ_1M MMU_CAM_PGSZ_1M
> -#define IOVMF_PGSZ_64K MMU_CAM_PGSZ_64K
> -#define IOVMF_PGSZ_4K MMU_CAM_PGSZ_4K
> -#define IOVMF_PGSZ_16M MMU_CAM_PGSZ_16M
> -
> -#define IOVMF_ENDIAN_MASK (1 << 9)
> -#define IOVMF_ENDIAN_BIG MMU_RAM_ENDIAN_BIG
> -#define IOVMF_ENDIAN_LITTLE MMU_RAM_ENDIAN_LITTLE
> -
> -#define IOVMF_ELSZ_MASK (3 << 7)
> -#define IOVMF_ELSZ_8 MMU_RAM_ELSZ_8
> -#define IOVMF_ELSZ_16 MMU_RAM_ELSZ_16
> -#define IOVMF_ELSZ_32 MMU_RAM_ELSZ_32
> -#define IOVMF_ELSZ_NONE MMU_RAM_ELSZ_NONE
> -
> -#define IOVMF_MIXED_MASK (1 << 6)
> -#define IOVMF_MIXED MMU_RAM_MIXED
> -
> -/*
> - * iovma: s/w flags, used for mapping and umapping internally.
> - */
> -#define IOVMF_MMIO (1 << IOVMF_SW_SHIFT)
> -#define IOVMF_ALLOC (2 << IOVMF_SW_SHIFT)
> -#define IOVMF_ALLOC_MASK (3 << IOVMF_SW_SHIFT)
> -
> -/* "superpages" is supported just with physically linear pages */
> -#define IOVMF_DISCONT (1 << (2 + IOVMF_SW_SHIFT))
> -#define IOVMF_LINEAR (2 << (2 + IOVMF_SW_SHIFT))
> -#define IOVMF_LINEAR_MASK (3 << (2 + IOVMF_SW_SHIFT))
> -
> -#define IOVMF_DA_FIXED (1 << (4 + IOVMF_SW_SHIFT))
> -
> -
> -extern struct iovm_struct *omap_find_iovm_area(struct device *dev, u32 da);
> -extern u32
> -omap_iommu_vmap(struct iommu_domain *domain, struct device *dev, u32 da,
> - const struct sg_table *sgt, u32 flags);
> -extern struct sg_table *omap_iommu_vunmap(struct iommu_domain *domain,
> - struct device *dev, u32 da);
> -extern u32
> -omap_iommu_vmalloc(struct iommu_domain *domain, struct device *dev,
> - u32 da, size_t bytes, u32 flags);
> -extern void
> -omap_iommu_vfree(struct iommu_domain *domain, struct device *dev,
> - const u32 da);
> -extern void *omap_da_to_va(struct device *dev, u32 da);
> -
> -#endif /* __IOMMU_MMAP_H */
> diff --git a/drivers/iommu/omap-iommu-debug.c
> b/drivers/iommu/omap-iommu-debug.c index 0cac372..cf4a0b5 100644
> --- a/drivers/iommu/omap-iommu-debug.c
> +++ b/drivers/iommu/omap-iommu-debug.c
> @@ -18,9 +18,9 @@
> #include <linux/uaccess.h>
> #include <linux/platform_device.h>
> #include <linux/debugfs.h>
> +#include <linux/omap-iommu.h>
>
> #include <plat/iommu.h>
> -#include <plat/iovmm.h>
>
> #include "omap-iopgtable.h"
>
> diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
> index f2bbfb0..eadcfde 100644
> --- a/drivers/iommu/omap-iommu.c
> +++ b/drivers/iommu/omap-iommu.c
> @@ -19,6 +19,7 @@
> #include <linux/clk.h>
> #include <linux/platform_device.h>
> #include <linux/iommu.h>
> +#include <linux/omap-iommu.h>
> #include <linux/mutex.h>
> #include <linux/spinlock.h>
>
> diff --git a/drivers/iommu/omap-iovmm.c b/drivers/iommu/omap-iovmm.c
> index b332392..9852101 100644
> --- a/drivers/iommu/omap-iovmm.c
> +++ b/drivers/iommu/omap-iovmm.c
> @@ -17,15 +17,59 @@
> #include <linux/device.h>
> #include <linux/scatterlist.h>
> #include <linux/iommu.h>
> +#include <linux/omap-iommu.h>
>
> #include <asm/cacheflush.h>
> #include <asm/mach/map.h>
>
> #include <plat/iommu.h>
> -#include <plat/iovmm.h>
>
> #include "omap-iopgtable.h"
>
> +/*
> + * IOVMF_FLAGS: attribute for iommu virtual memory area(iovma)
> + *
> + * lower 16 bit is used for h/w and upper 16 bit is for s/w.
> + */
> +#define IOVMF_SW_SHIFT 16
> +
> +/*
> + * iovma: h/w flags derived from cam and ram attribute
> + */
> +#define IOVMF_CAM_MASK (~((1 << 10) - 1))
> +#define IOVMF_RAM_MASK (~IOVMF_CAM_MASK)
> +
> +#define IOVMF_PGSZ_MASK (3 << 0)
> +#define IOVMF_PGSZ_1M MMU_CAM_PGSZ_1M
> +#define IOVMF_PGSZ_64K MMU_CAM_PGSZ_64K
> +#define IOVMF_PGSZ_4K MMU_CAM_PGSZ_4K
> +#define IOVMF_PGSZ_16M MMU_CAM_PGSZ_16M
> +
> +#define IOVMF_ENDIAN_MASK (1 << 9)
> +#define IOVMF_ENDIAN_BIG MMU_RAM_ENDIAN_BIG
> +
> +#define IOVMF_ELSZ_MASK (3 << 7)
> +#define IOVMF_ELSZ_16 MMU_RAM_ELSZ_16
> +#define IOVMF_ELSZ_32 MMU_RAM_ELSZ_32
> +#define IOVMF_ELSZ_NONE MMU_RAM_ELSZ_NONE
> +
> +#define IOVMF_MIXED_MASK (1 << 6)
> +#define IOVMF_MIXED MMU_RAM_MIXED
> +
> +/*
> + * iovma: s/w flags, used for mapping and umapping internally.
> + */
> +#define IOVMF_MMIO (1 << IOVMF_SW_SHIFT)
> +#define IOVMF_ALLOC (2 << IOVMF_SW_SHIFT)
> +#define IOVMF_ALLOC_MASK (3 << IOVMF_SW_SHIFT)
> +
> +/* "superpages" is supported just with physically linear pages */
> +#define IOVMF_DISCONT (1 << (2 + IOVMF_SW_SHIFT))
> +#define IOVMF_LINEAR (2 << (2 + IOVMF_SW_SHIFT))
> +#define IOVMF_LINEAR_MASK (3 << (2 + IOVMF_SW_SHIFT))
> +
> +#define IOVMF_DA_FIXED (1 << (4 + IOVMF_SW_SHIFT))
> +
> static struct kmem_cache *iovm_area_cachep;
>
> /* return the offset of the first scatterlist entry in a sg table */
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c index 99640d8..7f182f0 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -61,6 +61,7 @@
> #include <linux/i2c.h>
> #include <linux/interrupt.h>
> #include <linux/module.h>
> +#include <linux/omap-iommu.h>
> #include <linux/platform_device.h>
> #include <linux/regulator/consumer.h>
> #include <linux/slab.h>
> diff --git a/drivers/media/platform/omap3isp/isp.h
> b/drivers/media/platform/omap3isp/isp.h index 8be7487..8d68669 100644
> --- a/drivers/media/platform/omap3isp/isp.h
> +++ b/drivers/media/platform/omap3isp/isp.h
> @@ -31,11 +31,9 @@
> #include <media/v4l2-device.h>
> #include <linux/device.h>
> #include <linux/io.h>
> +#include <linux/iommu.h>
> #include <linux/platform_device.h>
> #include <linux/wait.h>
> -#include <linux/iommu.h>
> -#include <plat/iommu.h>
> -#include <plat/iovmm.h>
>
> #include "ispstat.h"
> #include "ispccdc.h"
> diff --git a/drivers/media/platform/omap3isp/ispccdc.c
> b/drivers/media/platform/omap3isp/ispccdc.c index 60181ab..6ae1ffb2 100644
> --- a/drivers/media/platform/omap3isp/ispccdc.c
> +++ b/drivers/media/platform/omap3isp/ispccdc.c
> @@ -30,6 +30,7 @@
> #include <linux/device.h>
> #include <linux/dma-mapping.h>
> #include <linux/mm.h>
> +#include <linux/omap-iommu.h>
> #include <linux/sched.h>
> #include <linux/slab.h>
> #include <media/v4l2-event.h>
> diff --git a/drivers/media/platform/omap3isp/ispstat.c
> b/drivers/media/platform/omap3isp/ispstat.c index d7ac76b..35c3823 100644
> --- a/drivers/media/platform/omap3isp/ispstat.c
> +++ b/drivers/media/platform/omap3isp/ispstat.c
> @@ -26,6 +26,7 @@
> */
>
> #include <linux/dma-mapping.h>
> +#include <linux/omap-iommu.h>
> #include <linux/slab.h>
> #include <linux/uaccess.h>
>
> diff --git a/drivers/media/platform/omap3isp/ispvideo.c
> b/drivers/media/platform/omap3isp/ispvideo.c index a0b737fe..a4b8290 100644
> --- a/drivers/media/platform/omap3isp/ispvideo.c
> +++ b/drivers/media/platform/omap3isp/ispvideo.c
> @@ -27,6 +27,7 @@
> #include <linux/clk.h>
> #include <linux/mm.h>
> #include <linux/module.h>
> +#include <linux/omap-iommu.h>
> #include <linux/pagemap.h>
> #include <linux/scatterlist.h>
> #include <linux/sched.h>
> @@ -35,7 +36,6 @@
> #include <media/v4l2-dev.h>
> #include <media/v4l2-ioctl.h>
> #include <plat/iommu.h>
> -#include <plat/iovmm.h>
> #include <plat/omap-pm.h>
>
> #include "ispvideo.h"
> diff --git a/include/linux/omap-iommu.h b/include/linux/omap-iommu.h
> new file mode 100644
> index 0000000..cac78de
> --- /dev/null
> +++ b/include/linux/omap-iommu.h
> @@ -0,0 +1,52 @@
> +/*
> + * omap iommu: simple virtual address space management
> + *
> + * Copyright (C) 2008-2009 Nokia Corporation
> + *
> + * Written by Hiroshi DOYU <Hiroshi.DOYU@nokia.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef _INTEL_IOMMU_H_
> +#define _INTEL_IOMMU_H_
> +
> +struct iovm_struct {
> + struct omap_iommu *iommu; /* iommu object which this belongs to */
> + u32 da_start; /* area definition */
> + u32 da_end;
> + u32 flags; /* IOVMF_: see below */
> + struct list_head list; /* linked in ascending order */
> + const struct sg_table *sgt; /* keep 'page' <-> 'da' mapping */
> + void *va; /* mpu side mapped address */
> +};
> +
> +#define MMU_RAM_ENDIAN_SHIFT 9
> +#define MMU_RAM_ENDIAN_LITTLE (0 << MMU_RAM_ENDIAN_SHIFT)
> +#define MMU_RAM_ELSZ_8 (0 << MMU_RAM_ELSZ_SHIFT)
> +#define IOVMF_ENDIAN_LITTLE MMU_RAM_ENDIAN_LITTLE
> +#define MMU_RAM_ELSZ_SHIFT 7
> +#define IOVMF_ELSZ_8 MMU_RAM_ELSZ_8
> +
> +struct iommu_domain;
> +
> +extern struct iovm_struct *omap_find_iovm_area(struct device *dev, u32 da);
> +extern u32
> +omap_iommu_vmap(struct iommu_domain *domain, struct device *dev, u32 da,
> + const struct sg_table *sgt, u32 flags);
> +extern struct sg_table *omap_iommu_vunmap(struct iommu_domain *domain,
> + struct device *dev, u32 da);
> +extern u32
> +omap_iommu_vmalloc(struct iommu_domain *domain, struct device *dev,
> + u32 da, size_t bytes, u32 flags);
> +extern void
> +omap_iommu_vfree(struct iommu_domain *domain, struct device *dev,
> + const u32 da);
> +extern void *omap_da_to_va(struct device *dev, u32 da);
> +
> +extern void omap_iommu_save_ctx(struct device *dev);
> +extern void omap_iommu_restore_ctx(struct device *dev);
> +
> +#endif
I still think you should split this in two files, omap-iommu.h and omap-
iovmm.h. The later would just be arch/arm/plat-omap/include/plat/iovmm.h moved
to include/linux.h.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: RE: [PATCH] extcon : callback function to read cable property
From: MyungJoo Ham @ 2012-10-25 8:37 UTC (permalink / raw)
To: Tc, Jenny, 최찬우
Cc: linux-kernel@vger.kernel.org, anish kumar
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=euc-kr, Size: 4108 bytes --]
>
> > Subject: Re: [PATCH] extcon : callback function to read cable property
> >
> > On 10/19/2012 12:13 PM, Tc, Jenny wrote:
> > The rold of extcon inform only attached/detached state of extcon consumer
> > driver from extcon provider driver. After extcon consumer driver detect the
> > state of cable through extcon, extcon consumer driver or framework should
> > get the additional information of cable from other device driver except of
> > extcon.
> >
> > Also, extcon manage various cables (e.g., USB, TA, MHL, JIG-USB-ON, JIG-
> > USB-OFF, Dock) What are common properties among many cables expect
> > attached or detached state?
> >
>
> For charger cable the current each cable can provide will be common.
> But may not be relevant for other cables.
>
> I understand your point on extcon role. But my concern is, when the consumer
> driver gets a notification on cable state change, how does the consumer query the
> cable properties in a generic way. Do you have any suggestions for this?
>
> A use case can be as below
>
> When a USB host cable (SDP) connected to the platform, without USB enumeration
> it can support only up to 100mA(USB2.)/150mA(USB 3.0) (As per USB charging spec).
> Once the enumeration is done this can be 500mA/950mA. If the consumer charger driver
> need to configure the charger chip, it need to know the charger cable capabilities.
> For example a platform PLAT1 may have charger driver CHRGR1 and OTG driver OTG1.
> But platform PLAT2 may have CHGR1 but different OTG driver OTG2. How
> CHGR1 driver can detect the cable properties without having any platform layer
> hooks? The platform layer hooks (using platform data)will work only if the consumer is
> a platform driver. What if it's a framework which will have the same flow in all platforms?
In general,
an extcon user (extcon notifee) knows who's the extcon notifier; the user
is supposed to know the name of the notifier.
Thus, the extcon user should be able to get the appropriate object; i.e.,
a regulator struct in this case. Then, according to the USB state,
the current limit of the USB can be changed by the notifier; which
may notify (regulator subsystem has one) the extcon user to react
(change current limit of charger?)
Anyway, in your case of PLAT2, doesn't CHGR1 has (or is) a regulator
controlling the charger current and if the OTG2 regulator affects
the behavior of CHGR1, (the current of OTG2-reg goes to CHGR1-reg)
the consumer-supplier chain should be setup (if the BSP is ideal).
OR
If it is impossible to have any objects of OTG2 (looks strange, but..),
you may have two cables, USB (data) and Fast-charger.04 (add +400mA to USB),
where Fast-charger.04 is enabled when USB2 enumeration is done with 5.
However, the following callback might be considered if there are cases where
an extcon user has information of extcon_name and cable_name while the user
CANNOT get any information on which device or object is related with the
specific cable; in struct extcon, with optional user initializing data section:
+ struct device **cable_device;
OR
+ char **cable_device_name;
With any relevant changes in the status with cable_device,
we may notify any notifier-block that are interested in the specific
cable. Then, the notifier-block (for register_interest) is going to
handle extcon-state changes and cable_device notifications.
Currently, the user's nb is for cable attach/detach events with
true/false value in the place of 32bit value (val). However,
if we add the third possible value for that parameter
(0: cable detached, 1: cable attached, 2: cable status changed;
go find out what's going on), it is still compatible.
I considered using a void pointer instead of cable_device, too.
However, that would spoil the subsystem too much; we'll be creating
a total chaos: "USB-A driver uses struct regulator", "USB-B driver
uses struct device", "USB-C driver uses true/false", and so on.
Cheers,
MyungJoo
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥
^ 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.