* Re: [PATCH 4/5] drm/i915: refactor ring error state capture to use arrays
From: Chris Wilson @ 2011-10-30 19:32 UTC (permalink / raw)
To: intel-gfx; +Cc: Daniel Vetter
In-Reply-To: <1320001932-1846-4-git-send-email-daniel.vetter@ffwll.ch>
On Sun, 30 Oct 2011 20:12:11 +0100, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> The code already got unwindy and we want to dump more per-ring
> registers.
So this patch is to cook the spaghetti then? Not sure if unwindy
conjures the right imagery, I still think you mean unwieldly. ;)
> Only functional change is that we now also capture the video
> ring registers on ilk.
>
> v2: fixup a refactor fumble spotted by Chris Wilson.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply
* [meta-gnome] evince: initial add 2.32.0
From: Andreas Müller @ 2011-10-30 19:33 UTC (permalink / raw)
To: openembedded-devel
* recipe based on oe-classic: evince_2.30.0.bb
commit 5dba154457691d2096f2b1a7ef24bdc6f1b51859
* run tested on overo
* TODO further doctype support
configure option -> current configure result
------------------------------------------------
--enable-ps -> PostScript Backend.: no
--enable-djvu -> DJVU Backend.......: no
--enable-impress -> Impress Backend....: no
Signed-off-by: Andreas Müller <schnitzeltony@gmx.de>
---
meta-gnome/recipes-gnome/evince/evince_2.32.0.bb | 39 ++++++++++++++++++++++
1 files changed, 39 insertions(+), 0 deletions(-)
create mode 100644 meta-gnome/recipes-gnome/evince/evince_2.32.0.bb
diff --git a/meta-gnome/recipes-gnome/evince/evince_2.32.0.bb b/meta-gnome/recipes-gnome/evince/evince_2.32.0.bb
new file mode 100644
index 0000000..899d416
--- /dev/null
+++ b/meta-gnome/recipes-gnome/evince/evince_2.32.0.bb
@@ -0,0 +1,39 @@
+DESCRIPTION = "Evince is a document viewer for document formats like pdf, ps, djvu."
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=96f2f8d5ee576a2163977938ea36fa7b"
+SECTION = "x11/office"
+DEPENDS = "gnome-icon-theme gnome-doc-utils-native libgnome-keyring nautilus tiff libxt ghostscript poppler libxml2 gtk+ gconf libglade"
+
+inherit gnome pkgconfig gtk-icon-cache
+
+SRC_URI[archive.md5sum] = "ebc3ce6df8dcbf29cb9492f8dd031319"
+SRC_URI[archive.sha256sum] = "2a4c91ae38f8b5028cebb91b9da9ddc50ea8ae3f3d429df89ba351da2d787ff7"
+
+EXTRA_OECONF = " --enable-thumbnailer \
+ --enable-nautilus \
+ --disable-scrollkeeper \
+ --enable-pixbuf \
+ "
+
+do_install_append() {
+ install -d install -d ${D}${datadir}/pixmaps
+ install -m 0755 ${S}/data/icons/48x48/apps/evince.png ${D}${datadir}/pixmaps/
+}
+
+RDEPENDS_${PN} += "glib-2.0-utils"
+
+PACKAGES =+ "${PN}-nautilus-extension"
+FILES_${PN} += "${datadir}/dbus-1"
+FILES_${PN}-dbg += "${libdir}/*/*/.debug \
+ ${libdir}/*/*/*/.debug"
+FILES_${PN}-dev += "${libdir}/nautilus/extensions-2.0/*.la"
+FILES_${PN}-staticdev += "${libdir}/nautilus/extensions-2.0/*.a"
+FILES_${PN}-nautilus-extension = "${libdir}/nautilus/*/*so"
+
+pkg_postinst_${PN} () {
+if [ -n "$D" ]; then
+ exit 1
+fi
+
+glib-compile-schemas ${datadir}/glib-2.0/schemas
+}
--
1.7.4.4
^ permalink raw reply related
* [GIT PULL] i.MX5 devicetree support
From: Arnd Bergmann @ 2011-10-30 19:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111025091032.GT23421@pengutronix.de>
On Tuesday 25 October 2011, Sascha Hauer wrote:
> Please pull the following. It contains devicetree support for i.MX5
> based systems. You can use the following to resolve the merge conflicts
> against your for-next branch:
>
> git://git.pengutronix.de/git/imx/linux-2.6.git imx-dt-merge
My merge looked slightly different, but equivalent. Having the merge commit
as you did was indeed very useful.
Thanks!
Arnd
^ permalink raw reply
* [GIT PULL] assorted i.MX fixes
From: Arnd Bergmann @ 2011-10-30 19:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111025092344.GU23421@pengutronix.de>
On Tuesday 25 October 2011, Sascha Hauer wrote:
> Please pull the following assorted i.MX fixes. Should have send this
> earlier, I promise to do this next time.
>
> Sascha
>
> The following changes since commit fcb8ce5cfe30ca9ca5c9a79cdfe26d1993e65e0c:
>
> Linux 3.1-rc3 (2011-08-22 11:42:53 -0700)
>
> are available in the git repository at:
> git://git.pengutronix.de/git/imx/linux-2.6.git imx-fixes-for-arnd
Pulled, thanks!
Is it intentional that only one of these commits is tagged stable?
The desciptions seem to suggest that they should all apply to 3.1 or possibly earlier
as well.
Arnd
^ permalink raw reply
* [U-Boot] JOB VACANCY IN MARRIOTT HOTEL
From: JOB VACANCY IN MARRIOTT HOTEL @ 2011-10-30 19:50 UTC (permalink / raw)
To: u-boot
An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://lists.denx.de/pipermail/u-boot/attachments/20111031/77b61338/attachment.txt
^ permalink raw reply
* [PATCH v3] usb: ehci: report Data Buffer Error in debug mode
From: Vikram Pandita @ 2011-10-30 19:55 UTC (permalink / raw)
To: stern; +Cc: linux-usb, linux-omap, Vikram Pandita
From: Vikram Pandita <vikram.pandita@ti.com>
Data Buffer Error as per spec section 4.15.1.1.2
results when there is Underrun or Overrun condition.
This error is considered non-fatal and never gets reported.
Its a very good indication on things going wrong at system level,
like running memory at much slower speed.
This is a good error to flag allowing system level corrections.
An issue was found with OMAP4460 board where DDR had to be run
at full speed and this logging helped.
Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
Reviewed-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
---
v1: original patch
v2: fix review comments from Alan Stern
* use usb_endpoint_num, usb_endpoint_dir_in
v3: More comments from Alan Stern
* indent, use qh
drivers/usb/host/ehci-q.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
index 4e4066c..f136f7f1 100644
--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -373,6 +373,17 @@ qh_completions (struct ehci_hcd *ehci, struct ehci_qh *qh)
retry_xacterr:
if ((token & QTD_STS_ACTIVE) == 0) {
+ /* Report Data Buffer Error: non-fatal but useful */
+ if (token & QTD_STS_DBE)
+ ehci_dbg(ehci,
+ "detected DataBufferErr for urb %p ep%d%s len %d, qtd %p [qh %p]\n",
+ urb,
+ usb_endpoint_num(&urb->ep->desc),
+ usb_endpoint_dir_in(&urb->ep->desc) ? "in" : "out",
+ urb->transfer_buffer_length,
+ qtd,
+ qh);
+
/* on STALL, error, and short reads this urb must
* complete and all its qtds must be recycled.
*/
--
1.7.5.4
^ permalink raw reply related
* [GIT PULL] at91 device tree basics
From: Arnd Bergmann @ 2011-10-30 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EA69BC9.8040402@atmel.com>
On Tuesday 25 October 2011, Nicolas Ferre wrote:
> The following changes since commit c3b92c8787367a8bb53d57d9789b558f1295cc96:
>
> Linux 3.1 (2011-10-24 09:10:05 +0200)
>
> are available in the git repository at:
> git://github.com/at91linux/linux-at91.git for-arnd/at91-dt
>
> They cover the basic device tree work done during the last moths around both
> at91sam9g45 and at91sam9g20 based board. They have been review by Grant and
> Rob. More device tree related stuff is comming ;-)
Hi Nicolas,
I've pulled it into the next/dt branch, it looks all good but please try to
send stuff like this before the merge window next time, ideally much before
the merge window.
Arnd
^ permalink raw reply
* [U-Boot] [PATCH 04/39] GCC4.6: Squash warning in cmd_date.c
From: Mike Frysinger @ 2011-10-30 19:59 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319242654-15534-5-git-send-email-marek.vasut@gmail.com>
On Friday 21 October 2011 20:16:59 Marek Vasut wrote:
> +static inline unsigned int I2C_GET_BUS(void)
> __attribute__((always_inline));
> +static inline unsigned int I2C_GET_BUS(void)
> +{
there's no need to have these prototypes double up. if you really truly need
the "always inline" markings, then use:
static __always_inline unsigned int I2C_GET_BUS(void)
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111030/2acb673a/attachment.pgp
^ permalink raw reply
* Re: [GIT PULL] at91 device tree basics
From: Arnd Bergmann @ 2011-10-30 19:57 UTC (permalink / raw)
To: Nicolas Ferre
Cc: Jean-Christophe PLAGNIOL-VILLARD, Linux Kernel list,
'linux-arm-kernel@lists.infradead.org', Rob Herring,
Grant Likely
In-Reply-To: <4EA69BC9.8040402@atmel.com>
On Tuesday 25 October 2011, Nicolas Ferre wrote:
> The following changes since commit c3b92c8787367a8bb53d57d9789b558f1295cc96:
>
> Linux 3.1 (2011-10-24 09:10:05 +0200)
>
> are available in the git repository at:
> git://github.com/at91linux/linux-at91.git for-arnd/at91-dt
>
> They cover the basic device tree work done during the last moths around both
> at91sam9g45 and at91sam9g20 based board. They have been review by Grant and
> Rob. More device tree related stuff is comming ;-)
Hi Nicolas,
I've pulled it into the next/dt branch, it looks all good but please try to
send stuff like this before the merge window next time, ideally much before
the merge window.
Arnd
^ permalink raw reply
* HT (Hyper Threading) aware process scheduling doesn't work as it should
From: Artem S. Tashkinov @ 2011-10-30 19:57 UTC (permalink / raw)
To: linux-kernel
Hello,
It's known that if you want to reach maximum performance on HT enabled Intel CPUs you
should distribute the load evenly between physical cores, and when you have loaded all
of them you should then load the remaining virtual cores.
For example, if you have 4 physical cores and 8 virtual CPUs then if you have just four
tasks consuming 100% of CPU time you should load four CPU pairs:
VCPUs: {1,2} - one task running
VCPUs: {3,4} - one task running
VCPUs: {5,6} - one task running
VCPUs: {7,8} - one task running
It's absolutely detrimental to performance to bind two tasks to e.g. two physical cores
{1,2} {3,4} and then the remaining two tasks to e.g. the third core 5,6:
VCPUs: {1,2} - one task running
VCPUs: {3,4} - one task running
VCPUs: {5,6} - *two* task runnings
VCPUs: {7,8} - no tasks running
I've found out that even on Linux 3.0.8 the process scheduler doesn't correctly distributes
the load amongst virtual CPUs. E.g. on a 4-core system (8 total virtual CPUs) the process
scheduler often run some instances of four different tasks on the same physical CPU.
Maybe I shouldn't trust top/htop output on this matter but the same test carried out on
Microsoft XP OS shows that it indeed distributes the load correctly, running tasks on different
physical cores whenever possible.
Any thoughts? comments? I think this is quite a serious problem.
Best wishes,
Artem
^ permalink raw reply
* Re: [RESEND PATCH 11/14] staging/media/as102: fix compile warning about unused function
From: Sylwester Nawrocki @ 2011-10-30 20:04 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Piotr Chmura, devel, Devin Heitmueller, Patrick Dickey, Greg KH,
Stefan Richter, LMML
In-Reply-To: <20111018220352.3179feb1@darkstar>
On 10/18/2011 10:03 PM, Piotr Chmura wrote:
> Patch taken from http://kernellabs.com/hg/~dheitmueller/v4l-dvb-as102-2/
>
> Original source and comment:
> # HG changeset patch
> # User Devin Heitmueller<dheitmueller@kernellabs.com>
> # Date 1267319685 18000
> # Node ID 84b93826c0a19efa114a6808165f91390cb86daa
> # Parent 22ef1bdca69a2781abf397c53a0f7f6125f5359a
> as102: fix compile warning about unused function
>
> From: Devin Heitmueller<dheitmueller@kernellabs.com>
>
> The function in question is only used on old kernels, so we had the call to
> the function #ifdef'd, but the definition of the function was stil being
> included.
>
> Priority: normal
>
> Signed-off-by: Devin Heitmueller<dheitmueller@kernellabs.com>
> Signed-off-by: Piotr Chmura<chmooreck@poczta.onet.pl>
>
> diff --git linux/drivers/staging/media/as102/as102_fe.c linuxb/drivers/staging/media/as102/as102_fe.c
> --- linux/drivers/staging/media/as102/as102_fe.c
> +++ linuxb/drivers/staging/media/as102/as102_fe.c
> @@ -32,6 +32,7 @@
> static void as102_fe_copy_tune_parameters(struct as10x_tune_args *dst,
> struct dvb_frontend_parameters *src);
>
> +#if (LINUX_VERSION_CODE< KERNEL_VERSION(2, 6, 19))
I was wondering, could such a conditional compilation be simply skipped when
we are merging the driver into exactly known kernel version ?
For backports there are separate patches at media_build.git and I can't see
such an approach used in any driver upstream.
--
Regards,
Sylwester
^ permalink raw reply
* Re: [PATCH] drm/radeon/kms: remove useless radeon_ddc_dump()
From: Alex Deucher @ 2011-10-30 20:05 UTC (permalink / raw)
To: Thomas Reim; +Cc: Alex Deucher, dri-devel
In-Reply-To: <1319892930.14718.19.camel@Mark-Aurel.gas.de>
On Sat, Oct 29, 2011 at 8:55 AM, Thomas Reim <reimth@googlemail.com> wrote:
> Dear Alex,
>
> but we use DDC probing e. g. to identify connectors with improperly
> terminated i2c bus. Instead of flooding logs and terminals with EDID dumps,
> we decided some months ago to use this function during module loading to
> inform the user once (and only once!), which connector has a monitor
> connected with valid EDID and which connector has not.
There's nothing in that function that actually prevents the printing
of bad EDIDs. All it does is call drm_get_edid() and report whether
it found an EDID or not. radeon_dvi_detect() already takes into
account the requires_extended_probe flag. The connectors are probed by
the fb code for the console as well so it just adds to the module load
time. If we want to print what connectors are connected, it should be
done from the fb code so we only have to do it once.
>
> Graphic solutions in general have several connectors integrated, and it's
> sometimes really difficult to identify, which one of the does not work as
> expected, based on the logs. From above log we see, that a monitor is
> connected to DVI connector, nothing is connected to the VGA connector, and
> we have a problem with the HDMI connector. Without this fuinction, nothing
> helpful from radeon module would be in the logs.
We should print the connector name in the generic drm error code then
if we want to print this info at boot time.
>
> Maybe we can keep this function, but call it only for connectors, for which
> it works, i. e. not for DP, eDP and DP bridge connectors.
That's just as bad. Users won't understand why only certain
connectors are probed.
>
> Best regards
>
> Thomas Reim
>
> Am Dienstag, den 25.10.2011, 19:24 -0400 schrieb alexdeucher@gmail.com:
>
> From: Alex Deucher <alexander.deucher@amd.com>
>
> The function didn't work with DP, eDP, or DP bridge
> connectors and thus confused users as it lead them to
> believe nothing was connected or the EDID was invalid
> when in fact is was, just on the aux bus rather an i2c.
>
> It should also speed up module loading as it avoids a
> bunch of extra DDC probing.
>
> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
> ---
> drivers/gpu/drm/radeon/radeon_display.c | 33
> -------------------------------
> 1 files changed, 0 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 6adb3e5..4998736 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -33,8 +33,6 @@
> #include "drm_crtc_helper.h"
> #include "drm_edid.h"
>
> -static int radeon_ddc_dump(struct drm_connector *connector);
> -
> static void avivo_crtc_load_lut(struct drm_crtc *crtc)
> {
> struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
> @@ -669,7 +667,6 @@ static void radeon_print_display_setup(struct drm_device
> *dev)
> static bool radeon_setup_enc_conn(struct drm_device *dev)
> {
> struct radeon_device *rdev = dev->dev_private;
> - struct drm_connector *drm_connector;
> bool ret = false;
>
> if (rdev->bios) {
> @@ -689,8 +686,6 @@ static bool radeon_setup_enc_conn(struct drm_device
> *dev)
> if (ret) {
> radeon_setup_encoder_clones(dev);
> radeon_print_display_setup(dev);
> - list_for_each_entry(drm_connector, &dev->mode_config.connector_list,
> head)
> - radeon_ddc_dump(drm_connector);
> }
>
> return ret;
> @@ -743,34 +738,6 @@ int radeon_ddc_get_modes(struct radeon_connector
> *radeon_connector)
> return 0;
> }
>
> -static int radeon_ddc_dump(struct drm_connector *connector)
> -{
> - struct edid *edid;
> - struct radeon_connector *radeon_connector =
> to_radeon_connector(connector);
> - int ret = 0;
> -
> - /* on hw with routers, select right port */
> - if (radeon_connector->router.ddc_valid)
> - radeon_router_select_ddc_port(radeon_connector);
> -
> - if (!radeon_connector->ddc_bus)
> - return -1;
> - edid = drm_get_edid(connector, &radeon_connector->ddc_bus->adapter);
> - /* Log EDID retrieval status here. In particular with regard to
> - * connectors with requires_extended_probe flag set, that will prevent
> - * function radeon_dvi_detect() to fetch EDID on this connector,
> - * as long as there is no valid EDID header found */
> - if (edid) {
> - DRM_INFO("Radeon display connector %s: Found valid EDID",
> - drm_get_connector_name(connector));
> - kfree(edid);
> - } else {
> - DRM_INFO("Radeon display connector %s: No monitor connected or invalid
> EDID",
> - drm_get_connector_name(connector));
> - }
> - return ret;
> -}
> -
> /* avivo */
> static void avivo_get_fb_div(struct radeon_pll *pll,
> u32 target_clock,
>
>
^ permalink raw reply
* [GIT PULL] hwspinlock changes for 3.2
From: Ohad Ben-Cohen @ 2011-10-30 20:06 UTC (permalink / raw)
To: Linus Torvalds
Cc: Mathieu Poirier, Arnd Bergmann, Gutierrez, Juan, Stephen Rothwell,
Tony Lindgren, Greg KH, Linus Walleij, linux-kernel, linux-omap,
linux-arm
Hi Linus,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git for-linus
To receive hwspinlock updates for 3.2.
The only noticeable change is a new hwspinlock driver for
ST-Ericsson's u8500 platform by Mathieu; the rest of the changes are
either cleanups or trivial fixes (one of the fixes also trivially
changes a mach-omap2 file, and is Acked by Tony).
All of the patches have been tested in linux-next and currently there
are no merge conflicts, though I expect one to happen with the arm-sco
tree, as reported (and fixed) by Stephen earlier this month (see
http://www.spinics.net/lists/linux-next/msg16931.html).
I've flagged one of the fixes as stable material (the one from Juan).
Normally I would only send you stable-worthy patches during the rc
cycle and not wait until the merge window, but since the hwspinlock
tree and its upstream path have only materialized quite late in the
cycle (see https://lkml.org/lkml/2011/9/21/249), I've decided this
time to wait for the merge window.
Hope it's ok; please tell me if there are any issues.
Thanks,
Ohad.
The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb:
Linux 3.1-rc6 (2011-09-12 14:02:02 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git for-linus
Juan Gutierrez (1):
hwspinlock/core: use a mutex to protect the radix tree
Mathieu J. Poirier (1):
hwspinlock/u8500: add hwspinlock driver
Ohad Ben-Cohen (8):
hwspinlock/core: simplify Kconfig
hwspinlock/core: simplify 'owner' handling
hwspinlock/omap: simplify allocation scheme
hwspinlock/core/omap: fix id issues on multiple hwspinlock devices
hwspinlock/core: remove stubs for register/unregister
hwspinlock/core: register a bank of hwspinlocks in a single API call
hwspinlock/omap: omap_hwspinlock_remove should be __devexit
hwspinlock: add MAINTAINERS entries
Documentation/hwspinlock.txt | 74 +++++++-----
MAINTAINERS | 14 ++
arch/arm/mach-omap2/hwspinlock.c | 8 +-
drivers/hwspinlock/Kconfig | 27 +++--
drivers/hwspinlock/Makefile | 1 +
drivers/hwspinlock/hwspinlock_core.c | 204 +++++++++++++++++++-----------
drivers/hwspinlock/hwspinlock_internal.h | 40 ++++--
drivers/hwspinlock/omap_hwspinlock.c | 127 +++++++------------
drivers/hwspinlock/u8500_hsem.c | 198 +++++++++++++++++++++++++++++
include/linux/hwspinlock.h | 46 +++++--
10 files changed, 514 insertions(+), 225 deletions(-)
create mode 100644 drivers/hwspinlock/u8500_hsem.c
^ permalink raw reply
* [GIT PULL] hwspinlock changes for 3.2
From: Ohad Ben-Cohen @ 2011-10-30 20:06 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git for-linus
To receive hwspinlock updates for 3.2.
The only noticeable change is a new hwspinlock driver for
ST-Ericsson's u8500 platform by Mathieu; the rest of the changes are
either cleanups or trivial fixes (one of the fixes also trivially
changes a mach-omap2 file, and is Acked by Tony).
All of the patches have been tested in linux-next and currently there
are no merge conflicts, though I expect one to happen with the arm-sco
tree, as reported (and fixed) by Stephen earlier this month (see
http://www.spinics.net/lists/linux-next/msg16931.html).
I've flagged one of the fixes as stable material (the one from Juan).
Normally I would only send you stable-worthy patches during the rc
cycle and not wait until the merge window, but since the hwspinlock
tree and its upstream path have only materialized quite late in the
cycle (see https://lkml.org/lkml/2011/9/21/249), I've decided this
time to wait for the merge window.
Hope it's ok; please tell me if there are any issues.
Thanks,
Ohad.
The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb:
Linux 3.1-rc6 (2011-09-12 14:02:02 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git for-linus
Juan Gutierrez (1):
hwspinlock/core: use a mutex to protect the radix tree
Mathieu J. Poirier (1):
hwspinlock/u8500: add hwspinlock driver
Ohad Ben-Cohen (8):
hwspinlock/core: simplify Kconfig
hwspinlock/core: simplify 'owner' handling
hwspinlock/omap: simplify allocation scheme
hwspinlock/core/omap: fix id issues on multiple hwspinlock devices
hwspinlock/core: remove stubs for register/unregister
hwspinlock/core: register a bank of hwspinlocks in a single API call
hwspinlock/omap: omap_hwspinlock_remove should be __devexit
hwspinlock: add MAINTAINERS entries
Documentation/hwspinlock.txt | 74 +++++++-----
MAINTAINERS | 14 ++
arch/arm/mach-omap2/hwspinlock.c | 8 +-
drivers/hwspinlock/Kconfig | 27 +++--
drivers/hwspinlock/Makefile | 1 +
drivers/hwspinlock/hwspinlock_core.c | 204 +++++++++++++++++++-----------
drivers/hwspinlock/hwspinlock_internal.h | 40 ++++--
drivers/hwspinlock/omap_hwspinlock.c | 127 +++++++------------
drivers/hwspinlock/u8500_hsem.c | 198 +++++++++++++++++++++++++++++
include/linux/hwspinlock.h | 46 +++++--
10 files changed, 514 insertions(+), 225 deletions(-)
create mode 100644 drivers/hwspinlock/u8500_hsem.c
^ permalink raw reply
* [GIT PULL] hwspinlock changes for 3.2
From: Ohad Ben-Cohen @ 2011-10-30 20:06 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, Tony Lindgren, Arnd Bergmann, Greg KH, linux-omap,
Gutierrez, Juan, Mathieu Poirier, Linus Walleij, linux-arm,
Stephen Rothwell
Hi Linus,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git for-linus
To receive hwspinlock updates for 3.2.
The only noticeable change is a new hwspinlock driver for
ST-Ericsson's u8500 platform by Mathieu; the rest of the changes are
either cleanups or trivial fixes (one of the fixes also trivially
changes a mach-omap2 file, and is Acked by Tony).
All of the patches have been tested in linux-next and currently there
are no merge conflicts, though I expect one to happen with the arm-sco
tree, as reported (and fixed) by Stephen earlier this month (see
http://www.spinics.net/lists/linux-next/msg16931.html).
I've flagged one of the fixes as stable material (the one from Juan).
Normally I would only send you stable-worthy patches during the rc
cycle and not wait until the merge window, but since the hwspinlock
tree and its upstream path have only materialized quite late in the
cycle (see https://lkml.org/lkml/2011/9/21/249), I've decided this
time to wait for the merge window.
Hope it's ok; please tell me if there are any issues.
Thanks,
Ohad.
The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb:
Linux 3.1-rc6 (2011-09-12 14:02:02 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git for-linus
Juan Gutierrez (1):
hwspinlock/core: use a mutex to protect the radix tree
Mathieu J. Poirier (1):
hwspinlock/u8500: add hwspinlock driver
Ohad Ben-Cohen (8):
hwspinlock/core: simplify Kconfig
hwspinlock/core: simplify 'owner' handling
hwspinlock/omap: simplify allocation scheme
hwspinlock/core/omap: fix id issues on multiple hwspinlock devices
hwspinlock/core: remove stubs for register/unregister
hwspinlock/core: register a bank of hwspinlocks in a single API call
hwspinlock/omap: omap_hwspinlock_remove should be __devexit
hwspinlock: add MAINTAINERS entries
Documentation/hwspinlock.txt | 74 +++++++-----
MAINTAINERS | 14 ++
arch/arm/mach-omap2/hwspinlock.c | 8 +-
drivers/hwspinlock/Kconfig | 27 +++--
drivers/hwspinlock/Makefile | 1 +
drivers/hwspinlock/hwspinlock_core.c | 204 +++++++++++++++++++-----------
drivers/hwspinlock/hwspinlock_internal.h | 40 ++++--
drivers/hwspinlock/omap_hwspinlock.c | 127 +++++++------------
drivers/hwspinlock/u8500_hsem.c | 198 +++++++++++++++++++++++++++++
include/linux/hwspinlock.h | 46 +++++--
10 files changed, 514 insertions(+), 225 deletions(-)
create mode 100644 drivers/hwspinlock/u8500_hsem.c
^ permalink raw reply
* RE: [GIT PULL] mm: frontswap (for 3.2 window)
From: Dave Hansen @ 2011-10-30 20:06 UTC (permalink / raw)
To: Dan Magenheimer
Cc: John Stoffel, Johannes Weiner, Pekka Enberg, Cyclonus J,
Sasha Levin, Christoph Hellwig, David Rientjes, Linus Torvalds,
linux-mm, LKML, Andrew Morton, Konrad Wilk, Jeremy Fitzhardinge,
Seth Jennings, ngupta, Chris Mason, JBeulich, Jonathan Corbet
In-Reply-To: <3ac142d4-a4ca-4a24-bf0b-69a90bd1d1a0@default>
On Sun, 2011-10-30 at 12:18 -0700, Dan Magenheimer wrote:
> > since they're the ones who will have to understand this stuff and know
> > how to maintain it. And keeping this maintainable is a key goal.
>
> Absolutely agree. Count the number of frontswap lines that affect
> the current VM core code and note also how they are very clearly
> identified. It really is a very VERY small impact to the core VM
> code (e.g. in the files swapfile.c and page_io.c).
Granted, the impact on the core VM in lines of code is small. But, I
think the behavioral impact is potentially huge since tmem's hooks add
non-trivial amounts of framework underneath the VM in core paths. In
zcache's case, this means a bunch of allocations and an entirely new
allocator memory allocator being used in the swap paths.
We're certainly still shaking bugs out of the interactions there like
with zcache_direct_reclaim_lock. Granted, that's not a
tmem/frontswap/cleancache bug, but it does speak to the difficulty and
subtlety of writing one of those frameworks underneath the tmem API.
-- Dave
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* RE: [GIT PULL] mm: frontswap (for 3.2 window)
From: Dave Hansen @ 2011-10-30 20:06 UTC (permalink / raw)
To: Dan Magenheimer
Cc: John Stoffel, Johannes Weiner, Pekka Enberg, Cyclonus J,
Sasha Levin, Christoph Hellwig, David Rientjes, Linus Torvalds,
linux-mm, LKML, Andrew Morton, Konrad Wilk, Jeremy Fitzhardinge,
Seth Jennings, ngupta, Chris Mason, JBeulich, Jonathan Corbet
In-Reply-To: <3ac142d4-a4ca-4a24-bf0b-69a90bd1d1a0@default>
On Sun, 2011-10-30 at 12:18 -0700, Dan Magenheimer wrote:
> > since they're the ones who will have to understand this stuff and know
> > how to maintain it. And keeping this maintainable is a key goal.
>
> Absolutely agree. Count the number of frontswap lines that affect
> the current VM core code and note also how they are very clearly
> identified. It really is a very VERY small impact to the core VM
> code (e.g. in the files swapfile.c and page_io.c).
Granted, the impact on the core VM in lines of code is small. But, I
think the behavioral impact is potentially huge since tmem's hooks add
non-trivial amounts of framework underneath the VM in core paths. In
zcache's case, this means a bunch of allocations and an entirely new
allocator memory allocator being used in the swap paths.
We're certainly still shaking bugs out of the interactions there like
with zcache_direct_reclaim_lock. Granted, that's not a
tmem/frontswap/cleancache bug, but it does speak to the difficulty and
subtlety of writing one of those frameworks underneath the tmem API.
-- Dave
^ permalink raw reply
* open802.11s on android
From: Nico Gerwien @ 2011-10-30 20:10 UTC (permalink / raw)
To: linux-wireless
Hi,
i didn't work with open802.11s yet. So i would like to know if it is
compilable on android systems?
Or is there already a precompiled package for android?
Greetings
Nicole
^ permalink raw reply
* Re: Detecting if you are running in a container
From: H. Peter Anvin @ 2011-10-30 20:11 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Ted Ts'o, Kyle Moffett, J. Bruce Fields, Matt Helsley,
Lennart Poettering, Kay Sievers, linux-kernel, harald, david,
greg, Linux Containers, Serge E. Hallyn, Daniel Lezcano,
Paul Menage
In-Reply-To: <m1ipnpl1c9.fsf@fess.ebiederm.org>
On 10/16/2011 02:42 AM, Eric W. Biederman wrote:
>>
>> Something based on UUIDs, perhaps?
>>
>> UUIDs are kind of exactly this, after all... a single namespace designed
>> to be large and random enough to be globally unique without a central
>> registration authority.
>
> mount --bind /proc/self/ns/net /var/run/netns/<name>
>
> When we want to refer to the namespace in syscalls we pass a file
> descriptor we received from opening the namespace reference object.
>
> That moves the entire naming problem into the file namespace.
>
That doesn't solve what I think of as the *real* problem.
The real problem is just another instance of what I sometimes refer to
as the "alien metadata problem": the alien metadata problem (which crops
up in *all kinds* of contexts, including containers, namespaces, virtual
machines, building distribution disk images, and backups) is the fact
that you would like to be able to store, manipulate and preserve, on
disk and in a mounted filesystem, a set of metadata which may not be the
"currently active" metadata.
There are two forms of "solutions" to this: one where the filesystem
still only contains one set of metadata, but it is not currently active,
and one where the filesystem contains multiple sets of metadata for the
same files at the same time, any one of which can be active (and
different ones may be active for different namespaces.)
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* open802.11s on android
From: Nico Gerwien @ 2011-10-30 20:11 UTC (permalink / raw)
To: linux-wireless
Hi,
i didn't work with open802.11s yet. So i would like to know if it is
compilable on android systems?
Or is there already a precompiled package for android?
Greetings
Nicole
^ permalink raw reply
* [U-Boot] [PATCH] drivers/rtc/ds1337.c: fix GCC 4.6 build warnings
From: Marek Vasut @ 2011-10-30 20:12 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20111030131120.5BDA611F9E5D@gemini.denx.de>
> Dear Marek Vasut,
>
> In message <201110300039.59309.marek.vasut@gmail.com> you wrote:
> > > -#undef DEBUG_RTC
> > > -
> > > -#ifdef DEBUG_RTC
> > > -#define DEBUGR(fmt,args...) printf(fmt ,##args)
> > > -#else
> > > -#define DEBUGR(fmt,args...)
> > > -#endif
> > > -/*--------------------------------------------------------------------
> > > -*/ -
> >
> > This undermines the ability of fine-grained debuging output, right? Now
> > you can only debug whole uboot or nothing ... correct me if I'm wrong
> > please.
>
> The normal way to enable debugging on file scope is to compile only
> the respective files with DEBUG defined.
>
>
> Best regards,
>
> Wolfgang Denk
Roger that !!
^ permalink raw reply
* [U-Boot] [PATCH 1/2] post/post.c: CodingStyle cleanup
From: Marek Vasut @ 2011-10-30 20:12 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20111030131005.D051111F9E5D@gemini.denx.de>
> Dear Marek Vasut,
>
> In message <201110300038.14360.marek.vasut@gmail.com> you wrote:
> > > Signed-off-by: Wolfgang Denk <wd@denx.de>
> > > ---
> > >
> > > post/post.c | 59
> > >
> > > +++++++++++++++++++++++++++-------------------------------- 1 files
> > > changed, 27 insertions(+), 32 deletions(-)
> >
> > [...]
> >
> > > if (test->cmd) {
> > >
> > > - addr = (ulong) (test->cmd) + gd->reloc_off;
> > > + addr = (ulong)(test->cmd) + gd->reloc_off;
> > >
> > > test->cmd = (char *)addr;
> > >
> > > }
> > >
> > > if (test->desc) {
> > >
> > > - addr = (ulong) (test->desc) + gd->reloc_off;
> > > + addr = (ulong)(test->desc) + gd->reloc_off;
> > >
> > > test->desc = (char *)addr;
> > >
> > > }
> > >
> > > if (test->test) {
> > >
> > > - addr = (ulong) (test->test) + gd->reloc_off;
> > > + addr = (ulong)(test->test) + gd->reloc_off;
> > >
> > > test->test = (int (*)(int flags)) addr;
> > >
> > > }
> > >
> > > if (test->init_f) {
> > >
> > > - addr = (ulong) (test->init_f) + gd->reloc_off;
> > > + addr = (ulong)(test->init_f) + gd->reloc_off;
> > >
> > > test->init_f = (int (*)(void)) addr;
> > >
> > > }
> > >
> > > if (test->reloc) {
> > >
> > > - addr = (ulong) (test->reloc) + gd->reloc_off;
> > > + addr = (ulong)(test->reloc) + gd->reloc_off;
> >
> > The cast here doesn't seem right maybe ? :-(
>
> Why not?
>
> BTW: this is only a CodingStyle cleanup without any changes of the
> logic.
>
> Best regards,
>
> Wolfgang Denk
Ok! Add my:
Acked-by: Marek Vasut <marek.vasut@gmail.com>
^ permalink raw reply
* [U-Boot] [PATCH 0/8] Add tftpput command for uploading files over network
From: Mike Frysinger @ 2011-10-30 20:13 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EA27CFE.2010303@aribaud.net>
On Saturday 22 October 2011 04:21:18 Albert ARIBAUD wrote:
> Many U-Boot environments use 'tftp' as a shorthand to tftpboot. Did you
> verify that this is not broken by the introduction of 'tftpput'?
those boards are broken. we can't sanely maintain support for people relying
on autocompleted commands.
ignoring that, no one includes config_cmd_all.h, and no one enables this
command. if people do, and they don't test things, then that's even more
their problem.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111030/52922e6f/attachment.pgp
^ permalink raw reply
* Re: [Xenomai-help] xenomai on em2440
From: Łukasz Sacha @ 2011-10-30 20:13 UTC (permalink / raw)
To: xenomai
In-Reply-To: <CAAeYjM=PCjeZ3UhXnGW87+EhPVezi+DrNdwmOUY_hZNmTuC55w@domain.hid>
As I'm reading about xenomai and mini2440 I can see it's gonna be hard
to use xenami 2.6 on my board. This is because I need to have a kernel
that works on my board and such kernels are provided by
friendlyarm.net (git://repo.or.cz/linux-2.6/mini2440.git ). The latest
patched kernel is 2.6.32-rc8 and this one is not supported by xenomai.
I found a kernel 2.6.35-9 patch made by one of the friendlyarm users
but it includes all in one - xenoami 2.5.6 and mini2440 modyfications
(http://www.friendlyarm.net/forum/topic/3299#15471). I think I should
go with this one.
If you can get me a better solution please let me know.
--
Łukasz Dragilla Sacha
On Sun, Oct 30, 2011 at 10:41, Łukasz Sacha <dragilla@domain.hid> wrote:
>> A skin is an API on top of the "thin kernel (ADEOS + Xenomai Nucleus) "
>> which is offered to Real-Time tasks.
>> There is FAQ for that question
>> http://www.xenomai.org/index.php/FAQs#What_is_a_Xenomai_skin.3F
>> which part of this answer does you not understand?
>
> For a beginner there are too many terms that mix in my head, adeos,
> rtos... I'm starting to see the big picture now.
>
>>> My guess is it's the way "real time tasks" part looks like/acts like.
>>> Am I right?
>>> However there is another diagram shown in the Chameleon RTOS pdf -
>>> this does not include the user space.
>>> What is the user space?
>> Which diagram ? on which page of the document?
>
> Page 5. But now when I know that xenomai is more like a nano kernel
> approach than thin kernel approach it all makes sense.
>
>>> Can xenomai have multiple skins at the same time?
>> Yes Xenomai may have mulitple skins
>> (see slide 5 of http://www.xenomai.org/images/c/c6/Xenomai-OSMB-2007-01.pdf)
>> but I don't know if a single application may use different skins at
>> the same time.
>> I never tried myself so I let other answer that one.
>> Why would you want to have/use multiple skin?
>
> I don't. I just wanted to understand how it all works.
>
> I guess for now it is enough questions. I mean I still have plenty but
> I guess now I can start finding answers by myself. Thank you.
>
> regards,
> --
> Luke
>
^ permalink raw reply
* [U-Boot] [PATCH] ARM: re-introduce the MACH_TYPE_XXXXXX for EB_CPUX9K2 board
From: Marek Vasut @ 2011-10-30 20:14 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20111030131230.14FBB11F9E5D@gemini.denx.de>
> Dear Marek Vasut,
>
> In message <201110300047.46696.marek.vasut@gmail.com> you wrote:
> > > /*--------------------------------------------------------------------
> > > ----
> > >
> > > --*/ +#ifndef MACH_TYPE_EB_CPUX9K2
> > > +#define MACH_TYPE_EB_CPUX9K2 1977
> > > +#endif
> > > +/*--------------------------------------------------------------------
> > > ---- --*/ #define CONFIG_SYS_TEXT_BASE 0x00000000
> > >
> > > #define CONFIG_SYS_LOAD_ADDR 0x21000000 /* default load
address */
> >
> > You don't need the ifndef. Cheers
>
> But it doesn;t hurt either. I consider it defensive programming, just
> in case the #defined gets re-added to machtypes.h.
>
> Best regards,
>
> Wolfgang Denk
Sure, but if the machine ID is re-added, we will get a warning in here without
the ifdefs. With the ifdefs, the machine ID might be different here and in the
mach-types file and it might slide unnoticed.
^ 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.