* [PATCH] drm/radeon/kms: add R4XX mc register access helper.
From: Jerome Glisse @ 2009-09-09 20:24 UTC (permalink / raw)
To: airlied; +Cc: dri-devel, linux-kernel, Jerome Glisse
Atombios will use the mc register access helper and R4XX hw have a
bigger mc range than R3XX so add R4XX specific mc register access
helper.
igned-off-by: Jerome Glisse <jglisse@redhat.com>
---
drivers/gpu/drm/radeon/r420.c | 17 ++++++++++++
drivers/gpu/drm/radeon/r420d.h | 43 ++++++++++++++++++++++++++++++++
drivers/gpu/drm/radeon/radeon.h | 4 +++
drivers/gpu/drm/radeon/radeon_device.c | 4 +++
4 files changed, 68 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpu/drm/radeon/r420d.h
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index 029cee2..551d699 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -29,6 +29,7 @@
#include "drmP.h"
#include "radeon_reg.h"
#include "radeon.h"
+#include "r420d.h"
/* r420,r423,rv410 depends on : */
void r100_pci_gart_disable(struct radeon_device *rdev);
@@ -237,3 +238,19 @@ int r420_debugfs_pipes_info_init(struct radeon_device *rdev)
return 0;
#endif
}
+
+u32 r420_mc_rreg(struct radeon_device *rdev, u32 reg)
+{
+ u32 r;
+
+ WREG32(R_0001F8_MC_IND_INDEX, S_0001F8_MC_IND_ADDR(reg));
+ r = RREG32(R_0001FC_MC_IND_DATA);
+ return r;
+}
+
+void r420_mc_wreg(struct radeon_device *rdev, u32 reg, u32 v)
+{
+ WREG32(R_0001F8_MC_IND_INDEX, S_0001F8_MC_IND_ADDR(reg) |
+ S_0001F8_MC_IND_WR_EN(1));
+ WREG32(R_0001FC_MC_IND_DATA, v);
+}
diff --git a/drivers/gpu/drm/radeon/r420d.h b/drivers/gpu/drm/radeon/r420d.h
new file mode 100644
index 0000000..8b946c1
--- /dev/null
+++ b/drivers/gpu/drm/radeon/r420d.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright 2008 Advanced Micro Devices, Inc.
+ * Copyright 2008 Red Hat Inc.
+ * Copyright 2009 Jerome Glisse.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: Dave Airlie
+ * Alex Deucher
+ * Jerome Glisse
+ */
+#ifndef R420D_H
+#define R420D_H
+
+#define R_0001F8_MC_IND_INDEX 0x0001F8
+#define S_0001F8_MC_IND_ADDR(x) (((x) & 0x7F) << 0)
+#define G_0001F8_MC_IND_ADDR(x) (((x) >> 0) & 0x7F)
+#define C_0001F8_MC_IND_ADDR 0xFFFFFF80
+#define S_0001F8_MC_IND_WR_EN(x) (((x) & 0x1) << 8)
+#define G_0001F8_MC_IND_WR_EN(x) (((x) >> 8) & 0x1)
+#define C_0001F8_MC_IND_WR_EN 0xFFFFFEFF
+#define R_0001FC_MC_IND_DATA 0x0001FC
+#define S_0001FC_MC_IND_DATA(x) (((x) & 0xFFFFFFFF) << 0)
+#define G_0001FC_MC_IND_DATA(x) (((x) >> 0) & 0xFFFFFFFF)
+#define C_0001FC_MC_IND_DATA 0x00000000
+
+#endif
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index fe86b20..868d7c1 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -940,4 +940,8 @@ int r100_pci_gart_set_page(struct radeon_device *rdev, int i, uint64_t addr);
int r100_pci_gart_enable(struct radeon_device *rdev);
void r100_pci_gart_tlb_flush(struct radeon_device *rdev);
+/* r420,r423,rv410 */
+u32 r420_mc_rreg(struct radeon_device *rdev, u32 reg);
+void r420_mc_wreg(struct radeon_device *rdev, u32 reg, u32 v);
+
#endif
diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c
index da8646a..d1e356b 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -266,6 +266,10 @@ void radeon_register_accessor_init(struct radeon_device *rdev)
rdev->pll_rreg = &r100_pll_rreg;
rdev->pll_wreg = &r100_pll_wreg;
}
+ if (rdev->family >= CHIP_R420) {
+ rdev->mc_rreg = &r420_mc_rreg;
+ rdev->mc_wreg = &r420_mc_wreg;
+ }
if (rdev->family >= CHIP_RV515) {
rdev->mc_rreg = &rv515_mc_rreg;
rdev->mc_wreg = &rv515_mc_wreg;
--
1.6.4.1
^ permalink raw reply related
* Re: [PATCH] * mpc8313erdb.dts: Fixed eTSEC interrupt assignment.
From: Kim Phillips @ 2009-09-09 20:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev, Roland Lezuo
In-Reply-To: <F7AA2B23-A019-4E11-993D-AF0F6F1FD50A@kernel.crashing.org>
On Wed, 9 Sep 2009 15:28:01 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Sep 9, 2009, at 1:22 PM, Scott Wood wrote:
>
> > On Fri, Sep 04, 2009 at 12:31:25PM +0200, Roland Lezuo wrote:
> >> The following patch is needed to correctly assign the IRQs for the
> >> gianfar driver on the MPC8313ERDB-revc boards. ERR and TX are swapped
> >> as well as the interrupt lines for the two devices.
> >
> > And it will incorrectly assign them on older revisions of the chip.
> >
> > We really should have a u-boot fixup based on SVR.
definitely.
> I felt like Kim did this.
I never got my hands on a Rev. C board. What's the SVR on it? I think
this is also valid for Rev. B boards, and I don't have one of those
either.
Kim
^ permalink raw reply
* Linux 2.6.27.33
From: Greg KH @ 2009-09-09 20:33 UTC (permalink / raw)
To: linux-kernel, Andrew Morton, torvalds, stable; +Cc: lwn
I'm announcing the release of the 2.6.27.33 kernel. It fixes a build
error with the ocfs2 filesystem. If you do not use ocfs2, there is no
need to upgrade to this version, and 2.6.27.32 is sufficient.
I'll also be replying to this message with a copy of the patch between
2.6.27.32 and 2.6.27.33
The updated 2.6.27.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.27.y.git
and can be browsed at the normal kernel.org git web browser:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.27.y.git;a=summary
thanks,
greg k-h
------------
Makefile | 2 +-
fs/ocfs2/aops.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
Greg Kroah-Hartman (2):
OCFS2: fix build error
Linux 2.6.27.33
^ permalink raw reply
* Re: Linux 2.6.27.33
From: Greg KH @ 2009-09-09 20:34 UTC (permalink / raw)
To: linux-kernel, Andrew Morton, torvalds, stable, lwn
In-Reply-To: <20090909203337.GA31676@kroah.com>
diff --git a/Makefile b/Makefile
index 00dc0ee..1b2c0fb 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 27
-EXTRAVERSION = .32
+EXTRAVERSION = .33
NAME = Trembling Tortoise
# *DOCUMENTATION*
diff --git a/fs/ocfs2/aops.c b/fs/ocfs2/aops.c
index 0f04b70..4039637 100644
--- a/fs/ocfs2/aops.c
+++ b/fs/ocfs2/aops.c
@@ -1234,6 +1234,7 @@ out:
*/
static int ocfs2_write_cluster(struct address_space *mapping,
u32 phys, unsigned int unwritten,
+ unsigned int should_zero,
struct ocfs2_alloc_context *data_ac,
struct ocfs2_alloc_context *meta_ac,
struct ocfs2_write_ctxt *wc, u32 cpos,
^ permalink raw reply related
* Re: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re: Breakage with local APIC routing)
From: Ryan Stone @ 2009-09-09 20:39 UTC (permalink / raw)
To: Juergen Lock
Cc: Mohammed Gamal, freebsd-current, Jan Kiszka, qemu-devel,
Avi Kivity
In-Reply-To: <20090909201556.GA95426@triton8.kn-bremen.de>
[-- Attachment #1: Type: text/plain, Size: 215 bytes --]
Luigi Rizzo recently posted a thread to current (
http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011393.html)
that would explain the new problem on FreeBSD 8. He posted a patch
that
you can try.
[-- Attachment #2: Type: text/html, Size: 313 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] push: make non-fast-forward help message configurable
From: Jeff King @ 2009-09-09 20:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Matthieu Moy, Teemu Likonen, git
In-Reply-To: <7vr5ugszte.fsf@alter.siamese.dyndns.org>
On Wed, Sep 09, 2009 at 12:06:21PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > diff --git a/advice.c b/advice.c
> > new file mode 100644
> > index 0000000..b5216a2
> > --- /dev/null
> > +++ b/advice.c
> > @@ -0,0 +1,25 @@
> > +#include "cache.h"
> > +
> > +int advice_push_nonfastforward = 1;
> > +
> > +static struct {
> > + const char *name;
> > + int *preference;
> > +} advice_config[] = {
> > + { "pushnonfastforward", &advice_push_nonfastforward },
> > +};
>
> Can we have the value inside this struct, instead of having a pointer
> to another variable, and get rid of that variable altogether?
We could, but then callers need some way of indexing into the array.
Which means either:
- a constant offset (like "#define ADVICE_PUSH_NONFASTFORWARD 0"). The
problem with that is you get no compile-time support for making sure
that your index matches the variable you want. I.e., you have:
{ "pushnonfastforward", 1 } /* ADVICE_PUSH_NONFASTFORWARD */
with the position in the array implicitly matching the manually
assigned numbers. We do have precedent in things like diff_colors.
I don't remember if we have ever screwed it up.
- a dynamic offset, like (as you noted):
> If we did so, this part needs to become
>
> if (nonfastforward && check_advice("pushnonfastforward")) {
>
> which would be less efficient, but by definition advices are on the slow
> path, right?
which, as you note, is less efficient. It also turns typo-checking into
a run-time error rather than a compile-time error, which is IMHO a bad
idea. And if you care about such things, it is worse for using something
like ctags to find variable uses.
I went the way I did because it provides compile-time checking, and
because the variable is referred to by name in the table, the matching
is explicit and thus harder to screw up.
One final option would be to get rid of the table altogether. Its
function is to allow you to iterate over all of the variables. Now that
the "advice.all" option has been dropped, the only use is during config
parsing. We could simply unroll that loop to:
if (!strcmp(k, "pushnonfastforward")) {
advice_push_nonfastforward = git_config_bool(var, value);
return 0;
}
if (!strcmp(k, "statushints")) {
advice_status_hints = git_config_bool(var, value);
return 0;
}
as we do in other config parsing.
-Peff
^ permalink raw reply
* Re: [PATCH 3/3] viafb: use read-only mode parsing
From: Andrew Morton @ 2009-09-09 20:39 UTC (permalink / raw)
To: Florian Tobias Schandinat
Cc: linux-fbdev, linux-kernel, JosephChan, ScottFang,
FlorianSchandinat
In-Reply-To: <1252290284-3668-3-git-send-email-FlorianSchandinat@gmx.de>
On Mon, 7 Sep 2009 02:24:44 +0000
Florian Tobias Schandinat <FlorianSchandinat@gmx.de> wrote:
> +static void parse_mode(const char *str, u32 *xres, u32 *yres)
> +{
> + char *ptr;
> +
> + *xres = simple_strtoul(str, &ptr, 10);
> + if (ptr[0] != 'x')
> + goto out_default;
> +
> + *yres = simple_strtoul(&ptr[1], &ptr, 10);
> + if (ptr[0])
> + goto out_default;
> +
> + return;
> +
> +out_default:
> + printk(KERN_WARNING "viafb received invalid mode string: %s\n", str);
> + *xres = 640;
> + *yres = 480;
> +}
One wonders if we could use sscanf here?
The second simple_strtoul() could use strict_strtoul(), but that's not
obviously superior IMO.
^ permalink raw reply
* + viafb-remove-unused-structure-member.patch added to -mm tree
From: akpm @ 2009-09-09 20:40 UTC (permalink / raw)
To: mm-commits
Cc: laforge, FlorianSchandinat, HaraldWelte, JosephChan, ScottFang,
corbet
The patch titled
viafb: remove unused structure member
has been added to the -mm tree. Its filename is
viafb-remove-unused-structure-member.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: viafb: remove unused structure member
From: Harald Welte <laforge@gnumonks.org>
Remove a structure member 'on_slot' in the chip_info structure which is
completely unused.
Signed-off-by: Harald Welte <HaraldWelte@viatech.com>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Scott Fang <ScottFang@viatech.com.cn>
Cc: Joseph Chan <JosephChan@via.com.tw>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/video/via/chip.h | 1 -
1 file changed, 1 deletion(-)
diff -puN drivers/video/via/chip.h~viafb-remove-unused-structure-member drivers/video/via/chip.h
--- a/drivers/video/via/chip.h~viafb-remove-unused-structure-member
+++ a/drivers/video/via/chip.h
@@ -122,7 +122,6 @@ struct lvds_chip_information {
struct chip_information {
int gfx_chip_name;
int gfx_chip_revision;
- int chip_on_slot;
struct tmds_chip_information tmds_chip_info;
struct lvds_chip_information lvds_chip_info;
struct lvds_chip_information lvds_chip_info2;
_
Patches currently in -mm which might be from laforge@gnumonks.org are
pcmcia-fix-read-buffer-overflow.patch
viafb-remove-duplicated-cx700-register-init.patch
viafb-remove-temporary-start-address-setting.patch
viafb-merge-viafb_update_viafb_par-in-viafb_update_fix.patch
viafb-split-viafb_set_start_addr-up.patch
viafb-fix-ioremap_nocache-error-handling.patch
viafb-clean-up-viamodeh.patch
viafb-remove-duplicated-mode-information.patch
viafb-clean-up-duoview.patch
viafb-clean-up-virtual-memory-handling.patch
viafb-remove-unused-video-device-stuff.patch
viafb-remove-lvds-initialization.patch
viafb-another-small-cleanup-of-viafb_par.patch
viafb-improve-viafb_par.patch
viafb-2d-engine-rewrite.patch
viafb-2d-engine-rewrite-v2.patch
viafb-switch-to-seq_file.patch
viafb-cleanup-viafb_cursor.patch
viafb-improve-pitch-handling.patch
viafb-hardware-acceleration-initialization-cleanup.patch
viafb-make-module-parameters-visible-in-sysfs.patch
viafb-remove-unused-structure-member.patch
viafb-use-read-only-mode-parsing.patch
^ permalink raw reply
* + viafb-use-read-only-mode-parsing.patch added to -mm tree
From: akpm @ 2009-09-09 20:40 UTC (permalink / raw)
To: mm-commits; +Cc: FlorianSchandinat, JosephChan, ScottFang, corbet, laforge
The patch titled
viafb: use read-only mode parsing
has been added to the -mm tree. Its filename is
viafb-use-read-only-mode-parsing.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: viafb: use read-only mode parsing
From: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
viafb: use read-only mode parsing
The previous method of mode parsing wrote to the strings resulting in
truncated mode strings in the sysfs.
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Scott Fang <ScottFang@viatech.com.cn>
Cc: Joseph Chan <JosephChan@via.com.tw>
Cc: Harald Welte <laforge@gnumonks.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/video/via/viafbdev.c | 44 ++++++++++++++++++---------------
1 file changed, 25 insertions(+), 19 deletions(-)
diff -puN drivers/video/via/viafbdev.c~viafb-use-read-only-mode-parsing drivers/video/via/viafbdev.c
--- a/drivers/video/via/viafbdev.c~viafb-use-read-only-mode-parsing
+++ a/drivers/video/via/viafbdev.c
@@ -1821,11 +1821,29 @@ static void viafb_remove_proc(struct pro
remove_proc_entry("viafb", NULL);
}
+static void parse_mode(const char *str, u32 *xres, u32 *yres)
+{
+ char *ptr;
+
+ *xres = simple_strtoul(str, &ptr, 10);
+ if (ptr[0] != 'x')
+ goto out_default;
+
+ *yres = simple_strtoul(&ptr[1], &ptr, 10);
+ if (ptr[0])
+ goto out_default;
+
+ return;
+
+out_default:
+ printk(KERN_WARNING "viafb received invalid mode string: %s\n", str);
+ *xres = 640;
+ *yres = 480;
+}
+
static int __devinit via_pci_probe(void)
{
- unsigned long default_xres, default_yres;
- char *tmpc, *tmpm;
- char *tmpc_sec, *tmpm_sec;
+ u32 default_xres, default_yres;
int vmode_index;
u32 viafb_par_length;
@@ -1902,26 +1920,14 @@ static int __devinit via_pci_probe(void)
viafb_second_size * 1024 * 1024;
}
- tmpm = viafb_mode;
- tmpc = strsep(&tmpm, "x");
- strict_strtoul(tmpc, 0, &default_xres);
- strict_strtoul(tmpm, 0, &default_yres);
-
+ parse_mode(viafb_mode, &default_xres, &default_yres);
vmode_index = viafb_get_mode_index(default_xres, default_yres);
DEBUG_MSG(KERN_INFO "0->index=%d\n", vmode_index);
if (viafb_SAMM_ON == 1) {
- if (strcmp(viafb_mode, viafb_mode1)) {
- tmpm_sec = viafb_mode1;
- tmpc_sec = strsep(&tmpm_sec, "x");
- strict_strtoul(tmpc_sec, 0,
- (unsigned long *)&viafb_second_xres);
- strict_strtoul(tmpm_sec, 0,
- (unsigned long *)&viafb_second_yres);
- } else {
- viafb_second_xres = default_xres;
- viafb_second_yres = default_yres;
- }
+ parse_mode(viafb_mode1, &viafb_second_xres,
+ &viafb_second_yres);
+
if (0 == viafb_second_virtual_xres) {
switch (viafb_second_xres) {
case 1400:
_
Patches currently in -mm which might be from FlorianSchandinat@gmx.de are
viafb-remove-duplicated-cx700-register-init.patch
viafb-remove-temporary-start-address-setting.patch
viafb-merge-viafb_update_viafb_par-in-viafb_update_fix.patch
viafb-split-viafb_set_start_addr-up.patch
viafb-fix-ioremap_nocache-error-handling.patch
viafb-clean-up-viamodeh.patch
viafb-remove-duplicated-mode-information.patch
viafb-clean-up-duoview.patch
viafb-clean-up-virtual-memory-handling.patch
viafb-remove-unused-video-device-stuff.patch
viafb-remove-lvds-initialization.patch
viafb-another-small-cleanup-of-viafb_par.patch
viafb-improve-viafb_par.patch
viafb-2d-engine-rewrite.patch
viafb-2d-engine-rewrite-v2.patch
viafb-switch-to-seq_file.patch
viafb-cleanup-viafb_cursor.patch
viafb-improve-pitch-handling.patch
viafb-hardware-acceleration-initialization-cleanup.patch
viafb-make-module-parameters-visible-in-sysfs.patch
viafb-remove-unused-structure-member.patch
viafb-use-read-only-mode-parsing.patch
fb-fix-fb_pan_display-range-check.patch
fb-do-not-ignore-fb_set_par-errors.patch
^ permalink raw reply
* + viafb-make-module-parameters-visible-in-sysfs.patch added to -mm tree
From: akpm @ 2009-09-09 20:40 UTC (permalink / raw)
To: mm-commits
Cc: laforge, FlorianSchandinat, HaraldWelte, JosephChan, ScottFang,
corbet
The patch titled
viafb: make module parameters visible in sysfs
has been added to the -mm tree. Its filename is
viafb-make-module-parameters-visible-in-sysfs.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: viafb: make module parameters visible in sysfs
From: Harald Welte <laforge@gnumonks.org>
Signed-off-by: Harald Welte <HaraldWelte@viatech.com>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Scott Fang <ScottFang@viatech.com.cn>
Cc: Joseph Chan <JosephChan@via.com.tw>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
drivers/video/via/viafbdev.c | 43 ++++++++++++++++-----------------
1 file changed, 22 insertions(+), 21 deletions(-)
diff -puN drivers/video/via/viafbdev.c~viafb-make-module-parameters-visible-in-sysfs drivers/video/via/viafbdev.c
--- a/drivers/video/via/viafbdev.c~viafb-make-module-parameters-visible-in-sysfs
+++ a/drivers/video/via/viafbdev.c
@@ -21,6 +21,7 @@
#include <linux/module.h>
#include <linux/seq_file.h>
+#include <linux/stat.h>
#define _MASTER_FILE
#include "global.h"
@@ -2191,79 +2192,79 @@ module_init(viafb_init);
module_exit(viafb_exit);
#ifdef MODULE
-module_param(viafb_memsize, int, 0);
+module_param(viafb_memsize, int, S_IRUSR);
-module_param(viafb_mode, charp, 0);
+module_param(viafb_mode, charp, S_IRUSR);
MODULE_PARM_DESC(viafb_mode, "Set resolution (default=640x480)");
-module_param(viafb_mode1, charp, 0);
+module_param(viafb_mode1, charp, S_IRUSR);
MODULE_PARM_DESC(viafb_mode1, "Set resolution (default=640x480)");
-module_param(viafb_bpp, int, 0);
+module_param(viafb_bpp, int, S_IRUSR);
MODULE_PARM_DESC(viafb_bpp, "Set color depth (default=32bpp)");
-module_param(viafb_bpp1, int, 0);
+module_param(viafb_bpp1, int, S_IRUSR);
MODULE_PARM_DESC(viafb_bpp1, "Set color depth (default=32bpp)");
-module_param(viafb_refresh, int, 0);
+module_param(viafb_refresh, int, S_IRUSR);
MODULE_PARM_DESC(viafb_refresh,
"Set CRT viafb_refresh rate (default = 60)");
-module_param(viafb_refresh1, int, 0);
+module_param(viafb_refresh1, int, S_IRUSR);
MODULE_PARM_DESC(viafb_refresh1,
"Set CRT refresh rate (default = 60)");
-module_param(viafb_lcd_panel_id, int, 0);
+module_param(viafb_lcd_panel_id, int, S_IRUSR);
MODULE_PARM_DESC(viafb_lcd_panel_id,
"Set Flat Panel type(Default=1024x768)");
-module_param(viafb_lcd_dsp_method, int, 0);
+module_param(viafb_lcd_dsp_method, int, S_IRUSR);
MODULE_PARM_DESC(viafb_lcd_dsp_method,
"Set Flat Panel display scaling method.(Default=Expandsion)");
-module_param(viafb_SAMM_ON, int, 0);
+module_param(viafb_SAMM_ON, int, S_IRUSR);
MODULE_PARM_DESC(viafb_SAMM_ON,
"Turn on/off flag of SAMM(Default=OFF)");
-module_param(viafb_accel, int, 0);
+module_param(viafb_accel, int, S_IRUSR);
MODULE_PARM_DESC(viafb_accel,
"Set 2D Hardware Acceleration: 0 = OFF, 1 = ON (default)");
-module_param(viafb_active_dev, charp, 0);
+module_param(viafb_active_dev, charp, S_IRUSR);
MODULE_PARM_DESC(viafb_active_dev, "Specify active devices.");
-module_param(viafb_display_hardware_layout, int, 0);
+module_param(viafb_display_hardware_layout, int, S_IRUSR);
MODULE_PARM_DESC(viafb_display_hardware_layout,
"Display Hardware Layout (LCD Only, DVI Only...,etc)");
-module_param(viafb_second_size, int, 0);
+module_param(viafb_second_size, int, S_IRUSR);
MODULE_PARM_DESC(viafb_second_size,
"Set secondary device memory size");
-module_param(viafb_dual_fb, int, 0);
+module_param(viafb_dual_fb, int, S_IRUSR);
MODULE_PARM_DESC(viafb_dual_fb,
"Turn on/off flag of dual framebuffer devices.(Default = OFF)");
-module_param(viafb_platform_epia_dvi, int, 0);
+module_param(viafb_platform_epia_dvi, int, S_IRUSR);
MODULE_PARM_DESC(viafb_platform_epia_dvi,
"Turn on/off flag of DVI devices on EPIA board.(Default = OFF)");
-module_param(viafb_device_lcd_dualedge, int, 0);
+module_param(viafb_device_lcd_dualedge, int, S_IRUSR);
MODULE_PARM_DESC(viafb_device_lcd_dualedge,
"Turn on/off flag of dual edge panel.(Default = OFF)");
-module_param(viafb_bus_width, int, 0);
+module_param(viafb_bus_width, int, S_IRUSR);
MODULE_PARM_DESC(viafb_bus_width,
"Set bus width of panel.(Default = 12)");
-module_param(viafb_lcd_mode, int, 0);
+module_param(viafb_lcd_mode, int, S_IRUSR);
MODULE_PARM_DESC(viafb_lcd_mode,
"Set Flat Panel mode(Default=OPENLDI)");
-module_param(viafb_lcd_port, charp, 0);
+module_param(viafb_lcd_port, charp, S_IRUSR);
MODULE_PARM_DESC(viafb_lcd_port, "Specify LCD output port.");
-module_param(viafb_dvi_port, charp, 0);
+module_param(viafb_dvi_port, charp, S_IRUSR);
MODULE_PARM_DESC(viafb_dvi_port, "Specify DVI output port.");
MODULE_LICENSE("GPL");
_
Patches currently in -mm which might be from laforge@gnumonks.org are
pcmcia-fix-read-buffer-overflow.patch
viafb-remove-duplicated-cx700-register-init.patch
viafb-remove-temporary-start-address-setting.patch
viafb-merge-viafb_update_viafb_par-in-viafb_update_fix.patch
viafb-split-viafb_set_start_addr-up.patch
viafb-fix-ioremap_nocache-error-handling.patch
viafb-clean-up-viamodeh.patch
viafb-remove-duplicated-mode-information.patch
viafb-clean-up-duoview.patch
viafb-clean-up-virtual-memory-handling.patch
viafb-remove-unused-video-device-stuff.patch
viafb-remove-lvds-initialization.patch
viafb-another-small-cleanup-of-viafb_par.patch
viafb-improve-viafb_par.patch
viafb-2d-engine-rewrite.patch
viafb-2d-engine-rewrite-v2.patch
viafb-switch-to-seq_file.patch
viafb-cleanup-viafb_cursor.patch
viafb-improve-pitch-handling.patch
viafb-hardware-acceleration-initialization-cleanup.patch
viafb-make-module-parameters-visible-in-sysfs.patch
viafb-remove-unused-structure-member.patch
viafb-use-read-only-mode-parsing.patch
^ permalink raw reply
* Re: FreeBSD timing issues and qemu (was: Re: [Qemu-devel] Re: Breakage with local APIC routing)
From: Luigi Rizzo @ 2009-09-09 20:46 UTC (permalink / raw)
To: Juergen Lock
Cc: Mohammed Gamal, freebsd-current, Jan Kiszka, qemu-devel,
Avi Kivity
In-Reply-To: <20090907205955.GA91866@triton8.kn-bremen.de>
On Mon, Sep 07, 2009 at 10:59:55PM +0200, Juergen Lock wrote:
> [I'm copying freebsd-current@FreeBSD.org because ppl there might know
> more about this...]
>
> qemu on FreeBSD hosts used to be able to run a (FreeBSD at least) guest
> with the same HZ as the host (like, 1000) with (mostly) proper timing
> once, but no longer. :( It seems there are two problems involved:
>
> a) use of apic seems to cause the clock irq rate to be doubled to 2 * HZ
> (can anyone explain why?), i.e. a FreeBSD 7 guest on a FreeBSD 7 host
> only gets proper timing after setting hint.apic.0.disabled=1 via the
> loader. (as can be verified by `vmstat -i' and `time sleep 2' in an
> installed guest or via the fixit->cdrom/dvd shell on a FreeBSD livefs
> or dvd1 iso.)
>
> b) qemu running on FreeBSD 8 hosts (and most likely head) has the
> additional problem of running its timers only at HZ/2 when using
> setitimer(2) (called `-clock unix' in qemu), as seen below. (as also
this problem in 8.x is caused by the bug i described here yesterday:
http://lists.freebsd.org/pipermail/freebsd-current/2009-September/011393.html
In qeumu, the setitimer call (in file vl.c) has a timeout of 1 tick
which maps to callout_reset(..., 1, ...) and because (due to the bug)
8.x processes callouts 1 tick late, this effectively halves the clock rate.
> seen below, timer_settime(2) aka `-clock dynticks' in qemu behaves
> even worse, but that is similarly true on FreeBSD 7 which is why
> I removed the patch that enabled that from our qemu port(s) a few
> days ago.) And the only reason FreeBSD 8 guests are usually less
> affected by these problems is they now reduce their HZ to 100 when
> they detect being run in a VM. (which makes sense for other reasons
> as well, don't get me wrong... but of course doesn't help when the
> host is running with HZ=100 too.)
cheers
luigi
^ permalink raw reply
* [PATCH/RFC] IB/mad: Fix lock-lock-timer deadlock in RMPP code (was: [NEW PATCH] IB/mad: Fix possible lock-lock-timer deadlock)
From: Roland Dreier @ 2009-09-09 20:42 UTC (permalink / raw)
To: Bart Van Assche, Sean Hefty, Hal Rosenstock
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA,
general-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5
In-Reply-To: <e2e108260909081209t36bfef12m24ce000686ed116e-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Holding agent->lock across cancel_delayed_work() (which does
del_timer_sync()) in ib_cancel_rmpp_recvs() leads to lockdep reports of
possible lock-timer deadlocks if a consumer ever does something that
connects agent->lock to a lock taken in IRQ context (cf
http://marc.info/?l=linux-rdma&m=125243699026045).
However, it seems this locking is not necessary here, since the locking
did not prevent the rmpp_list from having an item added immediately
after the lock is dropped -- so there must be sufficient synchronization
protecting the rmpp_list without the locking here. Therefore, we can
fix the lockdep issue by simply deleting the locking.
Hal/Sean, does this look right to you?
---
drivers/infiniband/core/mad_rmpp.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/core/mad_rmpp.c b/drivers/infiniband/core/mad_rmpp.c
index 57a3c6f..865c109 100644
--- a/drivers/infiniband/core/mad_rmpp.c
+++ b/drivers/infiniband/core/mad_rmpp.c
@@ -85,12 +85,10 @@ void ib_cancel_rmpp_recvs(struct ib_mad_agent_private *agent)
struct mad_rmpp_recv *rmpp_recv, *temp_rmpp_recv;
unsigned long flags;
- spin_lock_irqsave(&agent->lock, flags);
list_for_each_entry(rmpp_recv, &agent->rmpp_list, list) {
cancel_delayed_work(&rmpp_recv->timeout_work);
cancel_delayed_work(&rmpp_recv->cleanup_work);
}
- spin_unlock_irqrestore(&agent->lock, flags);
flush_workqueue(agent->qp_info->port_priv->wq);
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 6/6] hugetlb: update hugetlb documentation for mempolicy based management.
From: David Rientjes @ 2009-09-09 20:44 UTC (permalink / raw)
To: Mel Gorman
Cc: Lee Schermerhorn, linux-mm, Andrew Morton, Nishanth Aravamudan,
linux-numa, Adam Litke, Andy Whitcroft, Eric Whitney,
Randy Dunlap
In-Reply-To: <20090909081631.GB24614@csn.ul.ie>
On Wed, 9 Sep 2009, Mel Gorman wrote:
> And to beat a dead horse, it does make sense that an application
> allocating hugepages obey memory policies. It does with dynamic hugepage
> resizing for example. It should have been done years ago and
> unfortunately wasn't but it's not the first time that the behaviour of
> hugepages differed from the core VM.
>
I agree completely, I'm certainly not defending the current implementation
as a sound design and I too would have preferred that it have done the
same as Lee's patchset from the very beginning. The issue I'm raising is
that while we both agree the current behavior is suboptimal and confusing,
it is the long-standing kernel behavior. There are applications out there
that are written to allocate and free hugepages and now changing the pool
from which they can allocate or free to could be problematic.
I'm personally fine with the breakage since I'm aware of this discussion
and can easily fix it in userspace. I'm more concerned about others
leaking hugepages or having their boot scripts break because they are
allocating far fewer hugepages than before. The documentation
(Documentation/vm/hugetlbpage.txt) has always said
/proc/sys/vm/nr_hugepaegs affects hugepages on a system level and now that
it's changed, I think it should be done explicitly with a new flag than
implicitly.
Would you explain why introducing a new mempolicy flag, MPOL_F_HUGEPAGES,
and only using the new behavior when this is set would be inconsistent or
inadvisible? Since this is a new behavior that will differ from the
long-standing default, it seems like it warrants a new mempolicy flag to
avoid all userspace breakage and make hugepage allocation and freeing with
an underlying mempolicy explicit.
This would address your audience that have been (privately) emailing you
while confused about why the hugepages being allocated from a global
tunable wouldn't be confined to their mempolicy.
--
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 2/2] pci-stub: add pci_stub.ids parameter
From: Jesse Barnes @ 2009-09-09 20:45 UTC (permalink / raw)
To: Tejun Heo
Cc: Greg KH, Linux Kernel, Jesse Barnes, linux-pci, Shane Huang,
Chris Wright, Grant Grundler
In-Reply-To: <4A9F61CF.2090209@kernel.org>
On Thu, 03 Sep 2009 15:27:27 +0900
Tejun Heo <tj@kernel.org> wrote:
> Add ids module parameter which allows specifying initial IDs for the
> pci-stub driver. When built into the kernel, pci-stub is linked
> before any real pci drivers and by setting up IDs from initialization
> it can prevent built-in drivers from attaching to specific devices.
>
> While at it, make pci_stub_probe() print out about devices it grabbed
> to weed out "but my controller isn't being probed" bug reports.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> ---
> Unchanged from the first posting.
Applied these two to linux-next, thanks.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH] To avoid the divide by zero error during the first execution, initialize the data type.
From: Troy Kisky @ 2009-09-09 20:47 UTC (permalink / raw)
To: avm; +Cc: davinci-linux-open-source, Arun Mani, alsa-devel@alsa-project.org
In-Reply-To: <1252527563-15074-1-git-send-email-avm@ti.com>
avm@ti.com wrote:
> From: Arun Mani <a0270733@gtcx26221.gt.design.ti.com>
>
> Signed-off-by: Arun Mani <a0270733@gtcx26221.gt.design.ti.com>
> ---
> sound/soc/davinci/davinci-i2s.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c
> index b1ea52f..61b1763 100644
> --- a/sound/soc/davinci/davinci-i2s.c
> +++ b/sound/soc/davinci/davinci-i2s.c
> @@ -104,10 +104,12 @@ enum {
>
> static struct davinci_pcm_dma_params davinci_i2s_pcm_out = {
> .name = "I2S PCM Stereo out",
> + .data_type = 2, //Initialize the data type for playback to avoid divide by zero
You should have ".acnt = 2" also for consistency.
> };
>
> static struct davinci_pcm_dma_params davinci_i2s_pcm_in = {
> .name = "I2S PCM Stereo in",
> + .data_type = 2, //Initialize the data type for playback to avoid divide by zero
> };
>
> struct davinci_mcbsp_dev {
And if the 1st stream is an 8-bit audio stream, will it initialize it incorrectly ???
Of course, we have formats = SNDRV_PCM_FMTBIT_S16_LE, currently so it's not an issue yet...
I don't see how data_type is not being set in davinci_i2s_hw_params
before being used in davinci_pcm_prepare.
Can prepare be called before hw_params ?
There is a "return -EINVAL" in davinci_i2s_hw_params with a
"printk(KERN_WARNING "davinci-i2s: unsupported PCM format\n")" before it.
Do you see this message in your log ?
Thanks
Troy
^ permalink raw reply
* [U-Boot] [PATCH v2] ppc/85xx: Introduce RESET_VECTOR_ADDRESS to handle non-standard link address
From: Wolfgang Denk @ 2009-09-09 20:47 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1252527755-14866-1-git-send-email-galak@kernel.crashing.org>
Dear Kumar Gala,
In message <1252527755-14866-1-git-send-email-galak@kernel.crashing.org> you wrote:
> Some board ports place TEXT_BASE at a location that would cause the
> RESET_VECTOR_ADDRESS not to be at 0xfffffffc when we link. By default
> we assume RESET_VECTOR_ADDRESS will be 0xfffffffc if the board doesn't
> explicitly set it.
thanks.
Just some nitpicking:
> --- a/cpu/mpc85xx/u-boot.lds
> +++ b/cpu/mpc85xx/u-boot.lds
> @@ -20,6 +20,10 @@
> * MA 02111-1307 USA
> */
>
> +#ifndef RESET_VECTOR_ADDRESS
> +#define RESET_VECTOR_ADDRESS (0xfffffffc)
> +#endif
No parens needed here.
Except from that:
Acked-by: Wolfgang Denk <wd@denx.de>
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I go on working for the same reason a hen goes on laying eggs."
- H. L. Mencken
^ permalink raw reply
* Re: [PATCH for -mm] getrusage: fill ru_maxrss value
From: Andrew Morton @ 2009-09-09 20:46 UTC (permalink / raw)
To: KOSAKI Motohiro; +Cc: hugh, jpirko, linux-kernel, oleg, linux-mm, mingo
In-Reply-To: <20090907115430.6C16.A69D9226@jp.fujitsu.com>
On Mon, 7 Sep 2009 11:58:36 +0900 (JST)
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
> > Grr, my fault.
> > I recognize it. sorry.
>
> I've finished my long pending homework ;)
>
> Andrew, can you please replace following patch with getrusage-fill-ru_maxrss-value.patch
> and getrusage-fill-ru_maxrss-value-update.patch?
>
>
>
> ChangeLog
> ===============================
> o Merge getrusage-fill-ru_maxrss-value.patch and getrusage-fill-ru_maxrss-value-update.patch
> o rewrote test programs (older version hit FreeBSD bug and it obfuscate testcase intention, thanks Hugh)
The code changes are unaltered, so I merely updated the changelog.
The changelog had lots of ^------- lines in it. But those are
conventionally the end-of-changelog separator so I rewrote them to
^=======
--
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: Attempt to load 2.6.31-rc8 under Xen 3.4.1 on top of Ubuntu 9.04 Server
From: Boris Derzhavets @ 2009-09-09 20:47 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk; +Cc: xen-devel@lists.xensource.com
In-Reply-To: <20090909202148.GA5577@phenom.dumpdata.com>
[-- Attachment #1.1: Type: text/plain, Size: 1329 bytes --]
Yes , switching default locations doesn't help.
Need to be instructed in more details to perform task.
Boris.
--- On Wed, 9/9/09, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [Xen-devel] Attempt to load 2.6.31-rc8 under Xen 3.4.1 on top of Ubuntu 9.04 Server
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Date: Wednesday, September 9, 2009, 4:21 PM
On Wed, Sep 09, 2009 at 12:43:51PM -0700, Boris Derzhavets wrote:
> Problem with serial console output.
>
> Grub Entry on testing box:-
>
> title Xen 3.5 Serial / Ubuntu 9.04 Jaunty (kernel 2.6.31-rc8)
> kernel /xen-3.5.gz dom0_mem=1024M loglvl=all guest_loglvl=all com1=19200,8n1 console=com1
> module /vmlinuz-2.6.31-rc8 ro root=/dev/sdc2 console=hvc0 earlyprintk=xen
> module /initrd-2.6.31-rc8.img
>
> On connected box in text mode:-
>
> # cat /dev/ttyS0 | tee log
>
> I am getting unreadable output
That might be due to baudrate not being set right. Can you use minicom instead (and obviously
set the right baudrate).
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 1978 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [PATCH for -mm] getrusage: fill ru_maxrss value
From: Andrew Morton @ 2009-09-09 20:46 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: kosaki.motohiro, hugh, jpirko, linux-kernel, oleg, linux-mm,
mingo
In-Reply-To: <20090907115430.6C16.A69D9226@jp.fujitsu.com>
On Mon, 7 Sep 2009 11:58:36 +0900 (JST)
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote:
> > Grr, my fault.
> > I recognize it. sorry.
>
> I've finished my long pending homework ;)
>
> Andrew, can you please replace following patch with getrusage-fill-ru_maxrss-value.patch
> and getrusage-fill-ru_maxrss-value-update.patch?
>
>
>
> ChangeLog
> ===============================
> o Merge getrusage-fill-ru_maxrss-value.patch and getrusage-fill-ru_maxrss-value-update.patch
> o rewrote test programs (older version hit FreeBSD bug and it obfuscate testcase intention, thanks Hugh)
The code changes are unaltered, so I merely updated the changelog.
The changelog had lots of ^------- lines in it. But those are
conventionally the end-of-changelog separator so I rewrote them to
^=======
^ permalink raw reply
* [PATCH] splice.2, tee.2, vmsplice.2: Update return type
From: Mark Hills @ 2009-09-09 20:48 UTC (permalink / raw)
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w; +Cc: linux-man-u79uwXL29TY76Z2rM5mHXA
Return type is ssize_t since glibc-2.7, see /usr/include/bits/fcntl.h
---
man2/splice.2 | 4 ++--
man2/tee.2 | 2 +-
man2/vmsplice.2 | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/man2/splice.2 b/man2/splice.2
index d9c192a..1d4b74f 100644
--- a/man2/splice.2
+++ b/man2/splice.2
@@ -31,8 +31,8 @@ splice \- splice data to/from a pipe
.B #define _GNU_SOURCE
.B #include <fcntl.h>
-.BI "long splice(int " fd_in ", loff_t *" off_in ", int " fd_out ,
-.BI " loff_t *" off_out ", size_t " len \
+.BI "ssize_t splice(int " fd_in ", loff_t *" off_in ", int " fd_out ,
+.BI " loff_t *" off_out ", size_t " len \
", unsigned int " flags );
.fi
.SH DESCRIPTION
diff --git a/man2/tee.2 b/man2/tee.2
index 323bee5..feda6c8 100644
--- a/man2/tee.2
+++ b/man2/tee.2
@@ -31,7 +31,7 @@ tee \- duplicating pipe content
.B #define _GNU_SOURCE
.B #include <fcntl.h>
-.BI "long tee(int " fd_in ", int " fd_out ", size_t " len \
+.BI "ssize_t tee(int " fd_in ", int " fd_out ", size_t " len \
", unsigned int " flags );
.fi
.SH DESCRIPTION
diff --git a/man2/vmsplice.2 b/man2/vmsplice.2
index 2c95893..91b2d04 100644
--- a/man2/vmsplice.2
+++ b/man2/vmsplice.2
@@ -32,8 +32,8 @@ vmsplice \- splice user pages into a pipe
.B #include <fcntl.h>
.B #include <sys/uio.h>
-.BI "long vmsplice(int " fd ", const struct iovec *" iov ,
-.BI " unsigned long " nr_segs ", unsigned int " flags );
+.BI "ssize_t vmsplice(int " fd ", const struct iovec *" iov ,
+.BI " unsigned long " nr_segs ", unsigned int " flags );
.fi
.SH DESCRIPTION
.\" Linus: vmsplice() system call to basically do a "write to
--
1.6.3.2
--
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 related
* [PATCH 0/2] PCI Hotplug: internal interface cleanups
From: Alex Chiang @ 2009-09-09 20:49 UTC (permalink / raw)
To: jbarnes; +Cc: linux-pci, linux-kernel
This is a re-post of an old patch series that wasn't picked up last
time due to being too late in the merge window.
It removes a bunch of copy/paste code in acpiphp by simplifying some
internal interfaces.
Please consider this for .32.
Thanks!
---
Alex Chiang (2):
PCI Hotplug: acpiphp: find bridges the easy way
PCI Hotplug: convert acpi_pci_detect_ejectable() to take an acpi_handle
drivers/pci/hotplug/acpi_pcihp.c | 9 +--
drivers/pci/hotplug/acpiphp_glue.c | 104 +++++++++---------------------------
drivers/pci/hotplug/pciehp_acpi.c | 5 +-
include/linux/pci_hotplug.h | 2 -
4 files changed, 34 insertions(+), 86 deletions(-)
^ permalink raw reply
* [PATCH 1/2] PCI Hotplug: acpiphp: find bridges the easy way
From: Alex Chiang @ 2009-09-09 20:49 UTC (permalink / raw)
To: jbarnes; +Cc: linux-pci, linux-kernel, Bjorn Helgaas
In-Reply-To: <20090909204738.11037.26974.stgit@bob.kio>
Instead of constantly evaluating _ADR and _SEG over and over again,
let's simplify our lives by using:
acpi_pci_find_root() for root bridges
acpi_get_pci_dev() for p2p bridges
This change eliminates some copy 'n paste code and also allows us
to simplify some internal interfaces.
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Alex Chiang <achiang@hp.com>
---
drivers/pci/hotplug/acpiphp_glue.c | 81 +++++++++---------------------------
1 files changed, 21 insertions(+), 60 deletions(-)
diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c
index 2e5f259..e72e0ad 100644
--- a/drivers/pci/hotplug/acpiphp_glue.c
+++ b/drivers/pci/hotplug/acpiphp_glue.c
@@ -277,14 +277,15 @@ register_slot(acpi_handle handle, u32 lvl, void *context, void **rv)
/* see if it's worth looking at this bridge */
-static int detect_ejectable_slots(struct pci_bus *pbus)
+static int detect_ejectable_slots(acpi_handle handle)
{
- int found = acpi_pci_detect_ejectable(pbus);
+ int found;
+ struct pci_bus *pbus;
+
+ pbus = pci_bus_from_handle(handle);
+ found = acpi_pci_detect_ejectable(pbus);
if (!found) {
- acpi_handle bridge_handle = acpi_pci_get_bridge_handle(pbus);
- if (!bridge_handle)
- return 0;
- acpi_walk_namespace(ACPI_TYPE_DEVICE, bridge_handle, (u32)1,
+ acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, (u32)1,
is_pci_dock_device, (void *)&found, NULL);
}
return found;
@@ -415,9 +416,10 @@ static inline void config_p2p_bridge_flags(struct acpiphp_bridge *bridge)
/* allocate and initialize host bridge data structure */
-static void add_host_bridge(acpi_handle *handle, struct pci_bus *pci_bus)
+static void add_host_bridge(acpi_handle *handle)
{
struct acpiphp_bridge *bridge;
+ struct acpi_pci_root *root = acpi_pci_find_root(handle);
bridge = kzalloc(sizeof(struct acpiphp_bridge), GFP_KERNEL);
if (bridge == NULL)
@@ -426,7 +428,7 @@ static void add_host_bridge(acpi_handle *handle, struct pci_bus *pci_bus)
bridge->type = BRIDGE_TYPE_HOST;
bridge->handle = handle;
- bridge->pci_bus = pci_bus;
+ bridge->pci_bus = root->bus;
spin_lock_init(&bridge->res_lock);
@@ -435,7 +437,7 @@ static void add_host_bridge(acpi_handle *handle, struct pci_bus *pci_bus)
/* allocate and initialize PCI-to-PCI bridge data structure */
-static void add_p2p_bridge(acpi_handle *handle, struct pci_dev *pci_dev)
+static void add_p2p_bridge(acpi_handle *handle)
{
struct acpiphp_bridge *bridge;
@@ -449,8 +451,8 @@ static void add_p2p_bridge(acpi_handle *handle, struct pci_dev *pci_dev)
bridge->handle = handle;
config_p2p_bridge_flags(bridge);
- bridge->pci_dev = pci_dev_get(pci_dev);
- bridge->pci_bus = pci_dev->subordinate;
+ bridge->pci_dev = acpi_get_pci_dev(handle);
+ bridge->pci_bus = bridge->pci_dev->subordinate;
if (!bridge->pci_bus) {
err("This is not a PCI-to-PCI bridge!\n");
goto err;
@@ -467,7 +469,7 @@ static void add_p2p_bridge(acpi_handle *handle, struct pci_dev *pci_dev)
init_bridge_misc(bridge);
return;
err:
- pci_dev_put(pci_dev);
+ pci_dev_put(bridge->pci_dev);
kfree(bridge);
return;
}
@@ -478,39 +480,21 @@ static acpi_status
find_p2p_bridge(acpi_handle handle, u32 lvl, void *context, void **rv)
{
acpi_status status;
- acpi_handle dummy_handle;
- unsigned long long tmp;
- int device, function;
struct pci_dev *dev;
- struct pci_bus *pci_bus = context;
-
- status = acpi_get_handle(handle, "_ADR", &dummy_handle);
- if (ACPI_FAILURE(status))
- return AE_OK; /* continue */
-
- status = acpi_evaluate_integer(handle, "_ADR", NULL, &tmp);
- if (ACPI_FAILURE(status)) {
- dbg("%s: _ADR evaluation failure\n", __func__);
- return AE_OK;
- }
-
- device = (tmp >> 16) & 0xffff;
- function = tmp & 0xffff;
-
- dev = pci_get_slot(pci_bus, PCI_DEVFN(device, function));
+ dev = acpi_get_pci_dev(handle);
if (!dev || !dev->subordinate)
goto out;
/* check if this bridge has ejectable slots */
- if ((detect_ejectable_slots(dev->subordinate) > 0)) {
+ if ((detect_ejectable_slots(handle) > 0)) {
dbg("found PCI-to-PCI bridge at PCI %s\n", pci_name(dev));
- add_p2p_bridge(handle, dev);
+ add_p2p_bridge(handle);
}
/* search P2P bridges under this p2p bridge */
status = acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, (u32)1,
- find_p2p_bridge, dev->subordinate, NULL);
+ find_p2p_bridge, NULL, NULL);
if (ACPI_FAILURE(status))
warn("find_p2p_bridge failed (error code = 0x%x)\n", status);
@@ -525,9 +509,7 @@ static int add_bridge(acpi_handle handle)
{
acpi_status status;
unsigned long long tmp;
- int seg, bus;
acpi_handle dummy_handle;
- struct pci_bus *pci_bus;
/* if the bridge doesn't have _STA, we assume it is always there */
status = acpi_get_handle(handle, "_STA", &dummy_handle);
@@ -542,36 +524,15 @@ static int add_bridge(acpi_handle handle)
return 0;
}
- /* get PCI segment number */
- status = acpi_evaluate_integer(handle, "_SEG", NULL, &tmp);
-
- seg = ACPI_SUCCESS(status) ? tmp : 0;
-
- /* get PCI bus number */
- status = acpi_evaluate_integer(handle, "_BBN", NULL, &tmp);
-
- if (ACPI_SUCCESS(status)) {
- bus = tmp;
- } else {
- warn("can't get bus number, assuming 0\n");
- bus = 0;
- }
-
- pci_bus = pci_find_bus(seg, bus);
- if (!pci_bus) {
- err("Can't find bus %04x:%02x\n", seg, bus);
- return 0;
- }
-
/* check if this bridge has ejectable slots */
- if (detect_ejectable_slots(pci_bus) > 0) {
+ if (detect_ejectable_slots(handle) > 0) {
dbg("found PCI host-bus bridge with hot-pluggable slots\n");
- add_host_bridge(handle, pci_bus);
+ add_host_bridge(handle);
}
/* search P2P bridges under this host bridge */
status = acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, (u32)1,
- find_p2p_bridge, pci_bus, NULL);
+ find_p2p_bridge, NULL, NULL);
if (ACPI_FAILURE(status))
warn("find_p2p_bridge failed (error code = 0x%x)\n", status);
^ permalink raw reply related
* [PATCH 2/2] PCI Hotplug: convert acpi_pci_detect_ejectable() to take an acpi_handle
From: Alex Chiang @ 2009-09-09 20:49 UTC (permalink / raw)
To: jbarnes; +Cc: linux-pci, linux-kernel, Kenji Kaneshige
In-Reply-To: <20090909204738.11037.26974.stgit@bob.kio>
acpi_pci_detect_ejectable() goes through effort to convert its
struct pci_bus arg to an acpi_handle, but every time we use this
interface, we already have the handle available.
So let's just use the handle instead of converting back and forth.
Cc: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Alex Chiang <achiang@hp.com>
---
drivers/pci/hotplug/acpi_pcihp.c | 9 +++------
drivers/pci/hotplug/acpiphp_glue.c | 33 +++++++++++----------------------
drivers/pci/hotplug/pciehp_acpi.c | 5 +++--
include/linux/pci_hotplug.h | 2 +-
4 files changed, 18 insertions(+), 31 deletions(-)
diff --git a/drivers/pci/hotplug/acpi_pcihp.c b/drivers/pci/hotplug/acpi_pcihp.c
index eb15958..80af75c 100644
--- a/drivers/pci/hotplug/acpi_pcihp.c
+++ b/drivers/pci/hotplug/acpi_pcihp.c
@@ -500,18 +500,15 @@ check_hotplug(acpi_handle handle, u32 lvl, void *context, void **rv)
/**
* acpi_pci_detect_ejectable - check if the PCI bus has ejectable slots
- * @pbus - PCI bus to scan
+ * @handle - handle of the PCI bus to scan
*
* Returns 1 if the PCI bus has ACPI based ejectable slots, 0 otherwise.
*/
-int acpi_pci_detect_ejectable(struct pci_bus *pbus)
+int acpi_pci_detect_ejectable(acpi_handle handle)
{
- acpi_handle handle;
int found = 0;
- if (!(handle = acpi_pci_get_bridge_handle(pbus)))
- return 0;
- acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, (u32)1,
+ acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, 1,
check_hotplug, (void *)&found, NULL);
return found;
}
diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c
index e72e0ad..680c336 100644
--- a/drivers/pci/hotplug/acpiphp_glue.c
+++ b/drivers/pci/hotplug/acpiphp_glue.c
@@ -62,22 +62,6 @@ static void acpiphp_sanitize_bus(struct pci_bus *bus);
static void acpiphp_set_hpp_values(acpi_handle handle, struct pci_bus *bus);
static void handle_hotplug_event_func(acpi_handle handle, u32 type, void *context);
-static struct pci_bus *pci_bus_from_handle(acpi_handle handle)
-{
- struct pci_bus *pbus;
- struct acpi_pci_root *root;
-
- root = acpi_pci_find_root(handle);
- if (root)
- pbus = root->bus;
- else {
- struct pci_dev *pdev = acpi_get_pci_dev(handle);
- pbus = pdev->subordinate;
- pci_dev_put(pdev);
- }
- return pbus;
-}
-
/* callback routine to check for the existence of a pci dock device */
static acpi_status
is_pci_dock_device(acpi_handle handle, u32 lvl, void *context, void **rv)
@@ -279,11 +263,7 @@ register_slot(acpi_handle handle, u32 lvl, void *context, void **rv)
/* see if it's worth looking at this bridge */
static int detect_ejectable_slots(acpi_handle handle)
{
- int found;
- struct pci_bus *pbus;
-
- pbus = pci_bus_from_handle(handle);
- found = acpi_pci_detect_ejectable(pbus);
+ int found = acpi_pci_detect_ejectable(handle);
if (!found) {
acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, (u32)1,
is_pci_dock_device, (void *)&found, NULL);
@@ -1364,7 +1344,16 @@ static void acpiphp_sanitize_bus(struct pci_bus *bus)
/* Program resources in newly inserted bridge */
static int acpiphp_configure_bridge (acpi_handle handle)
{
- struct pci_bus *bus = pci_bus_from_handle(handle);
+ struct pci_bus *bus;
+
+ if (acpi_is_root_bridge(handle)) {
+ struct acpi_pci_root *root = acpi_pci_find_root(handle);
+ bus = root->bus;
+ } else {
+ struct pci_dev *pdev = acpi_get_pci_dev(handle);
+ bus = pdev->subordinate;
+ pci_dev_put(pdev);
+ }
pci_bus_size_bridges(bus);
pci_bus_assign_resources(bus);
diff --git a/drivers/pci/hotplug/pciehp_acpi.c b/drivers/pci/hotplug/pciehp_acpi.c
index 9604801..0c6aa99 100644
--- a/drivers/pci/hotplug/pciehp_acpi.c
+++ b/drivers/pci/hotplug/pciehp_acpi.c
@@ -47,7 +47,7 @@ int pciehp_acpi_slot_detection_check(struct pci_dev *dev)
{
if (slot_detection_mode != PCIEHP_DETECT_ACPI)
return 0;
- if (acpi_pci_detect_ejectable(dev->subordinate))
+ if (acpi_pci_detect_ejectable(dev->dev.archdata.acpi_handle))
return 0;
return -ENODEV;
}
@@ -94,7 +94,8 @@ static int __init dummy_probe(struct pcie_device *dev)
dup_slot_id++;
}
list_add_tail(&slot->slot_list, &dummy_slots);
- if (!acpi_slot_detected && acpi_pci_detect_ejectable(pbus))
+ if (!acpi_slot_detected &&
+ acpi_pci_detect_ejectable(pbus->self->dev.archdata.acpi_handle))
acpi_slot_detected = 1;
return -ENODEV; /* dummy driver always returns error */
}
diff --git a/include/linux/pci_hotplug.h b/include/linux/pci_hotplug.h
index 1b00cc3..f0c31ae 100644
--- a/include/linux/pci_hotplug.h
+++ b/include/linux/pci_hotplug.h
@@ -231,7 +231,7 @@ extern acpi_status acpi_get_hp_params_from_firmware(struct pci_bus *bus,
struct hotplug_params *hpp);
int acpi_get_hp_hw_control_from_firmware(struct pci_dev *dev, u32 flags);
int acpi_pci_check_ejectable(struct pci_bus *pbus, acpi_handle handle);
-int acpi_pci_detect_ejectable(struct pci_bus *pbus);
+int acpi_pci_detect_ejectable(acpi_handle handle);
#endif
#endif
^ permalink raw reply related
* Re: Epic regression in throughput since v2.6.23
From: Serge Belyshev @ 2009-09-09 20:49 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Con Kolivas, linux-kernel, Peter Zijlstra, Mike Galbraith
In-Reply-To: <20090909155223.GA12065@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> Thanks!
>
> I think we found the reason for that regression - would you mind
> to re-test with latest -tip, e157986 or later?
>
> If that works for you i'll describe our theory.
>
Good job -- seems to work, thanks. Regression is still about 3% though:
http://img3.imageshack.us/img3/5335/epicbfstip.png
^ permalink raw reply
* Re: BFS vs. mainline scheduler benchmarks and measurements
From: Jens Axboe @ 2009-09-09 20:50 UTC (permalink / raw)
To: Nikos Chantziaras
Cc: Ingo Molnar, Mike Galbraith, Peter Zijlstra, Con Kolivas,
linux-kernel
In-Reply-To: <4AA80C1E.2080901@arcor.de>
On Wed, Sep 09 2009, Nikos Chantziaras wrote:
> On 09/09/2009 09:04 PM, Ingo Molnar wrote:
>> [...]
>> * Jens Axboe<jens.axboe@oracle.com> wrote:
>>
>>> On Wed, Sep 09 2009, Jens Axboe wrote:
>>> [...]
>>> BFS210 runs on the laptop (dual core intel core duo). With make -j4
>>> running, I clock the following latt -c8 'sleep 10' latencies:
>>>
>>> -rc9
>>>
>>> Max 17895 usec
>>> Avg 8028 usec
>>> Stdev 5948 usec
>>> Stdev mean 405 usec
>>>
>>> Max 17896 usec
>>> Avg 4951 usec
>>> Stdev 6278 usec
>>> Stdev mean 427 usec
>>>
>>> Max 17885 usec
>>> Avg 5526 usec
>>> Stdev 6819 usec
>>> Stdev mean 464 usec
>>>
>>> -rc9 + mike
>>>
>>> Max 6061 usec
>>> Avg 3797 usec
>>> Stdev 1726 usec
>>> Stdev mean 117 usec
>>>
>>> Max 5122 usec
>>> Avg 3958 usec
>>> Stdev 1697 usec
>>> Stdev mean 115 usec
>>>
>>> Max 6691 usec
>>> Avg 2130 usec
>>> Stdev 2165 usec
>>> Stdev mean 147 usec
>>
>> At least in my tests these latencies were mainly due to a bug in
>> latt.c - i've attached the fixed version.
>>
>> The other reason was wakeup batching. If you do this:
>>
>> echo 0> /proc/sys/kernel/sched_wakeup_granularity_ns
>>
>> ... then you can switch on insta-wakeups on -tip too.
>>
>> With a dual-core box and a make -j4 background job running, on
>> latest -tip i get the following latencies:
>>
>> $ ./latt -c8 sleep 30
>> Entries: 656 (clients=8)
>>
>> Averages:
>> ------------------------------
>> Max 158 usec
>> Avg 12 usec
>> Stdev 10 usec
>
> With your version of latt.c, I get these results with 2.6-tip vs
> 2.6.31-rc9-bfs:
>
>
> (mainline)
> Averages:
> ------------------------------
> Max 50 usec
> Avg 12 usec
> Stdev 3 usec
>
>
> (BFS)
> Averages:
> ------------------------------
> Max 474 usec
> Avg 11 usec
> Stdev 16 usec
>
>
> However, the interactivity problems still remain. Does that mean it's
> not a latency issue?
It probably just means that latt isn't a good measure of the problem.
Which isn't really too much of a surprise.
--
Jens Axboe
^ 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.