* [PATCH v6 2/3] OMAP: DSS2: OMAPFB: make VRFB depends on OMAP2,3
From: Guruswamy Senthilvadivu @ 2010-10-08 6:56 UTC (permalink / raw)
To: tomi.valkeinen, hvaibhav, linux-omap, linux-fbdev; +Cc: Senthilvadivu Guruswamy
In-Reply-To: <1286520273-4892-2-git-send-email-svadivu@ti.com>
From: Senthilvadivu Guruswamy <svadivu@ti.com>
config VRFB should depend on ARCH_OMAP2 or ARCH_OMAP3.
Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com>
---
drivers/video/omap2/omapfb/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/omapfb/Kconfig b/drivers/video/omap2/omapfb/Kconfig
index 43496d6..65149b2 100644
--- a/drivers/video/omap2/omapfb/Kconfig
+++ b/drivers/video/omap2/omapfb/Kconfig
@@ -3,7 +3,7 @@ menuconfig FB_OMAP2
depends on FB && OMAP2_DSS
select OMAP2_VRAM
- select OMAP2_VRFB
+ select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
--
1.6.3.3
^ permalink raw reply related
* [PATCH v6 3/3] OMAP: DSS2: OMAPFB: Allow usage of def_vrfb only for omap2,3
From: Guruswamy Senthilvadivu @ 2010-10-08 6:56 UTC (permalink / raw)
To: tomi.valkeinen, hvaibhav, linux-omap, linux-fbdev; +Cc: Senthilvadivu Guruswamy
In-Reply-To: <1286520273-4892-3-git-send-email-svadivu@ti.com>
From: Senthilvadivu Guruswamy <svadivu@ti.com>
VRFB is supported only on OMAP2 and OMAP3 platforms. If VRFB rotation is
not supported by the hardware and the user requests VRFB rotation,
print a warning and ignore the request from the user.
Signed-off-by: Senthilvadivu Guruswamy <svadivu@ti.com>
---
drivers/video/omap2/omapfb/omapfb-main.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index bddfca6..fcd9038 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2198,6 +2198,16 @@ static int omapfb_probe(struct platform_device *pdev)
goto err0;
}
+ /* TODO : Replace cpu check with omap_has_vrfb once HAS_FEATURE
+ * available for OMAP2 and OMAP3
+ */
+ if (def_vrfb && !cpu_is_omap24xx() && !cpu_is_omap34xx()) {
+ def_vrfb = 0;
+ dev_warn(&pdev->dev, "VRFB is not supported in this hardware,"
+ "ignoring the module parameter vrfb=y\n");
+ }
+
+
mutex_init(&fbdev->mtx);
fbdev->dev = &pdev->dev;
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 2/2] sched: use the old min_vruntime when normalizing on dequeue
From: Mike Galbraith @ 2010-10-08 6:57 UTC (permalink / raw)
To: Dima Zavin
Cc: linux-kernel, Peter Zijlstra, Ingo Molnar,
Arve Hjønnevåg
In-Reply-To: <AANLkTimR3pmxNF5TLTyEHZjPTrQeLrTB+HLsj-X6jPRx@mail.gmail.com>
On Thu, 2010-10-07 at 14:00 -0700, Dima Zavin wrote:
> Mike,
>
> Thanks for the Ack for patch 1/2, could you take a look at this one too?
Ok, did that. I'd do it like below instead.
> Should I re-upload the series as v2 or you can pick the latest from
> patch 1 and take this one?
Peter's the merge point, I just help break stuff ;-)
I tested the below with pinned/unpinned mixes of sleepers and hogs, and
saw no ill effects. My thought on the logic is embedded in the comment.
From: Dima Zavin <dima@android.com>
Subject: [PATCH 2/2] sched: use the old min_vruntime when normalizing on dequeue
Date: Tue, 28 Sep 2010 23:46:14 -0700
After pulling the thread off the run-queue during a cgroup change,
the cfs_rq.min_vruntime gets recalculated. The dequeued thread's vruntime
then gets normalized to this new value. This can then lead to the thread
getting an unfair boost in the new group if the vruntime of the next
task in the old run-queue was way further ahead.
Cc: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Dima Zavin <dima@android.com>
---
kernel/sched_fair.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
Index: linux-2.6/kernel/sched_fair.c
===================================================================
--- linux-2.6.orig/kernel/sched_fair.c
+++ linux-2.6/kernel/sched_fair.c
@@ -826,15 +826,17 @@ dequeue_entity(struct cfs_rq *cfs_rq, st
if (se != cfs_rq->curr)
__dequeue_entity(cfs_rq, se);
account_entity_dequeue(cfs_rq, se);
- update_min_vruntime(cfs_rq);
/*
- * Normalize the entity after updating the min_vruntime because the
- * update can refer to the ->curr item and we need to reflect this
- * movement in our normalized position.
+ * Normalize vruntime prior to updating min_vruntime. Any motion
+ * referring to ->curr will have been captured by update_curr() above.
+ * We don't want to preserve what lag might become as a result of
+ * this dequeue, we want to preserve what lag is at dequeue time.
*/
if (!(flags & DEQUEUE_SLEEP))
se->vruntime -= cfs_rq->min_vruntime;
+
+ update_min_vruntime(cfs_rq);
}
/*
^ permalink raw reply
* Re: Newbie Question About Dev-Interface Method
From: Jean Delvare @ 2010-10-08 6:57 UTC (permalink / raw)
To: Rory Filer; +Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <8F90F944E50427428C60E12A34A309D2308DA559B4-3qf8vkpM5jTbmvMHnzRVpW3Pdy6AhKVLXbPIYa3/oNjDOqzlkpFKJg@public.gmane.org>
Hi Rory,
On Thu, 7 Oct 2010 14:37:57 -0700, Rory Filer wrote:
> I'm working on a proof-of-concept device which contains several chips connected to the same adapter (/dev/ic2-0) on the I2C bus. Some of these have kernel-space drivers (e.g. GPIO Expander) and some don't. For the ones that don't I've opted to use the method described in the kernel Documentation/i2c/dev-interface document. This works great and does all I need for now. This is the general procedure I'm following as outlined in kernel - Documentation/i2c/dev-interface.
>
> - open /dev/i2c-N
> - Set the chip's address by calling ioctl(file, I2C_SLAVE, address)
> - interact with the chip using read/write or smb calls, etc.
> - close the file when done
>
> I'm assuming that a kernel space chip driver like our gpio expander (pca953x.c) also uses the same adapter driver as my user-space application since that expander chip is on the same bus.
Let's clarify right away: i2c-dev (which handles /dev/i2c-* nodes) is
NOT an adapter driver. It is a bridge driver between user-space and
your adapter driver. Your adapter driver is most likely one living in
drivers/i2c/busses, and depends on the actual hardware you run on.
> My question is, what happens if a kernel driver is using the bus at the same time my user-mode application is?
It will work fine.
> Even if the user space app. may not be running when the chip driver runs, the adapter has an address written into it via the ioctl() call, I noted above.
Incorrect. The address isn't written to the adapter, it is a setting
local to i2c-dev and even specific to the file handle you got when
opening a /dev/i2c-* node. Each subsequent read, write or smbus call in
your user-space driver automatically includes the slave address, which
is only valid for the read, write or smbus call in question.
> Can unpredictable results occur in this scenario?
No.
> I think I could protect against it by writing a thread to serialize accesses to the I2C bus, but that only works if my entire application is running inside one process. I'm hoping someone on the list might be able to advise.
The i2c-core module already serializes all accesses to every given i2c
adapter through i2c_transfer() and i2c_smbus_xfer().
--
Jean Delvare
http://khali.linux-fr.org/wishlist.html
^ permalink raw reply
* make oldconfig warnings [was: mmotm 2010-10-07-14-08 uploaded]
From: Jiri Slaby @ 2010-10-08 6:58 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: linux-kernel, mm-commits, linux-kbuild
In-Reply-To: <37921.1286489353@localhost>
Ccing linux-kbuild
On 10/08/2010 12:09 AM, Valdis.Kletnieks@vt.edu wrote:
> On Thu, 07 Oct 2010 14:08:45 PDT, akpm@linux-foundation.org said:
>> The mm-of-the-moment snapshot 2010-10-07-14-08 has been uploaded to
>>
>> http://userweb.kernel.org/~akpm/mmotm/
>
> 'make oldconfig' splatted this at the very end:
>
> NCP file system support (to mount NetWare volumes) (NCP_FS) [N/m/y/?] n
> Coda file system support (advanced network fs) (CODA_FS) [N/m/y/?] n
> Andrew File System support (AFS) (EXPERIMENTAL) (AFS_FS) [N/m/y/?] n
> warning: (IEEE1394_PCILYNX && (PCI || BROKEN) && PCI && IEEE1394 && I2C || SFC && NETDEVICES && NETDEV_10000 && PCI && INET || I2C_VIA && I2C && PCI && EXPERIMENTAL || I2C_HYDRA && I2C && PCI && PPC_CHRP && EXPERIMENTAL || I2C_GPIO && I2C && GENERIC_GPIO || I2C_IXP2000 && I2C && ARCH_IXP2000 || I2C_SIMTEC && I2C || I2C_VERSATILE && I2C && (ARCH_VERSATILE || ARCH_REALVIEW || ARCH_VEXPRESS) || I2C_PARPORT && I2C && PARPORT || I2C_PARPORT_LIGHT && I2C || I2C_ACORN && I2C && ARCH_ACORN || SCx200_I2C && I2C && SCx200_GPIO || VIDEO_BT848 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_DEV && PCI && I2C && VIDEO_V4L2 && INPUT && VIDEO_IR || VIDEO_CX88 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && VIDEO_DEV && PCI && I2C && INPUT && VIDEO_IR || VIDEO_CX23885 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && DVB_CORE && VIDEO_DEV && PCI && I2C && INPUT && IR_CORE || VIDEO_AU0828 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && I2C && INPUT && DVB_CORE && USB &&
V!
> IDEO_V4L2 || VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR || VIDEO_CX18 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && DVB_CORE && PCI && I2C && EXPERIMENTAL && INPUT && VIDEO_IR || VIDEO_SAA7164 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && DVB_CORE && PCI && I2C || DVB_PLUTO2 && MEDIA_SUPPORT && DVB_CAPTURE_DRIVERS && DVB_CORE && PCI && I2C || DRM && HAS_IOMEM && (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU || FB_DDC && HAS_IOMEM && FB || FB_VIA && HAS_IOMEM && FB && PCI && X86 || VIDEO_CX25821 && STAGING && !STAGING_EXCLUDE_BUILD && DVB_CORE && VIDEO_DEV && PCI && I2C && INPUT && BKL) selects I2C_ALGOBIT which has unmet direct dependencies (I2C && !I2C_HELPER_AUTO)
> warning: (NETFILTER_XT_MATCH_REALM && NET && INET && NETFILTER && NETFILTER_XTABLES && NETFILTER_ADVANCED || NET_CLS_ROUTE4 && NET && NET_SCHED) selects NET_CLS_ROUTE which has unmet direct dependencies (NET && NET_SCHED)
I have ton of them after doing oldconfig on my allmodconfig setup too:
warning: (IEEE1394_PCILYNX && (PCI || BROKEN) && PCI && IEEE1394 && I2C
|| SFC && NETDEVICES && NETDEV_10000 && PCI && INET || I2C_VIA && I2C &&
PCI && EXPERIMENTAL || I2C_HYDRA && I2C && PCI && PPC_CHRP &&
EXPERIMENTAL || I2C_GPIO && I2C && GENERIC_GPIO || I2C_IXP2000 && I2C &&
ARCH_IXP2000 || I2C_SIMTEC && I2C || I2C_VERSATILE && I2C &&
(ARCH_VERSATILE || ARCH_REALVIEW || ARCH_VEXPRESS) || I2C_PARPORT && I2C
&& PARPORT || I2C_PARPORT_LIGHT && I2C || I2C_ACORN && I2C && ARCH_ACORN
|| SCx200_I2C && I2C && SCx200_GPIO || VIDEO_BT848 && MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && VIDEO_DEV && PCI && I2C && VIDEO_V4L2 && INPUT
&& VIDEO_IR || VIDEO_CX88 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_V4L2 && VIDEO_DEV && PCI && I2C && INPUT && VIDEO_IR ||
VIDEO_CX23885 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 &&
DVB_CORE && VIDEO_DEV && PCI && I2C && INPUT && IR_CORE || VIDEO_AU0828
&& MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && I2C && INPUT && DVB_CORE &&
USB && VIDEO_V4L2 || VIDEO_IVTV && MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR
|| VIDEO_CX18 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 &&
DVB_CORE && PCI && I2C && EXPERIMENTAL && INPUT && VIDEO_IR ||
VIDEO_SAA7164 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 &&
DVB_CORE && PCI && I2C || DVB_PLUTO2 && MEDIA_SUPPORT &&
DVB_CAPTURE_DRIVERS && DVB_CORE && PCI && I2C || DRM && HAS_IOMEM &&
(AGP || AGP=n) && !EMULATED_CMPXCHG && MMU || FB_DDC && HAS_IOMEM && FB
|| FB_VIA && HAS_IOMEM && FB && PCI && X86 || VIDEO_CX25821 && STAGING
&& !STAGING_EXCLUDE_BUILD && DVB_CORE && VIDEO_DEV && PCI && I2C &&
INPUT && BKL) selects I2C_ALGOBIT which has unmet direct dependencies
(I2C && !I2C_HELPER_AUTO)
warning: (I2C_PCA_PLATFORM && I2C || I2C_PCA_ISA && I2C && ISA) selects
I2C_ALGOPCA which has unmet direct dependencies (I2C && !I2C_HELPER_AUTO)
warning: (VIDEO_BT848 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_DEV && PCI && I2C && VIDEO_V4L2 && INPUT && VIDEO_IR &&
VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_TVAUDIO which has unmet direct
dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
!VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_BT848 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_DEV && PCI && I2C && VIDEO_V4L2 && INPUT && VIDEO_IR &&
VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_TDA7432 which has unmet direct
dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
!VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_MXB && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && PCI &&
VIDEO_V4L2 && I2C && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_TDA9840
which has unmet direct dependencies (MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && !VIDEO_HELPER_CHIPS_AUTO && I2C)
warning: (VIDEO_MXB && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && PCI &&
VIDEO_V4L2 && I2C && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_TEA6415C
which has unmet direct dependencies (MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && !VIDEO_HELPER_CHIPS_AUTO && I2C)
warning: (VIDEO_MXB && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && PCI &&
VIDEO_V4L2 && I2C && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_TEA6420
which has unmet direct dependencies (MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && !VIDEO_HELPER_CHIPS_AUTO && I2C)
warning: (VIDEO_BT848 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_DEV && PCI && I2C && VIDEO_V4L2 && INPUT && VIDEO_IR &&
VIDEO_HELPER_CHIPS_AUTO || VIDEO_IVTV && MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR
|| VIDEO_PVRUSB2 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
V4L_USB_DRIVERS && USB && VIDEO_V4L2 && I2C && VIDEO_MEDIA ||
VIDEO_EM28XX && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 &&
V4L_USB_DRIVERS && USB && VIDEO_DEV && I2C && INPUT && VIDEO_IR &&
VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_MSP3400 which has unmet direct
dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
!VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_CX18 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_V4L2 && DVB_CORE && PCI && I2C && EXPERIMENTAL && INPUT &&
VIDEO_IR) selects VIDEO_CS5345 which has unmet direct dependencies
(MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO &&
VIDEO_V4L2 && I2C)
warning: (VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR || VIDEO_PVRUSB2 &&
MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && V4L_USB_DRIVERS && USB &&
VIDEO_V4L2 && I2C && VIDEO_MEDIA) selects VIDEO_CS53L32A which has unmet
direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
!VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR) selects VIDEO_M52790
which has unmet direct dependencies (MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_CX88 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_V4L2 && VIDEO_DEV && PCI && I2C && INPUT && VIDEO_IR &&
VIDEO_HELPER_CHIPS_AUTO || VIDEO_IVTV && MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR
|| VIDEO_PVRUSB2 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
V4L_USB_DRIVERS && USB && VIDEO_V4L2 && I2C && VIDEO_MEDIA) selects
VIDEO_WM8775 which has unmet direct dependencies (MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR) selects VIDEO_WM8739
which has unmet direct dependencies (MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR) selects VIDEO_VP27SMPX
which has unmet direct dependencies (MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_BT848 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_DEV && PCI && I2C && VIDEO_V4L2 && INPUT && VIDEO_IR &&
VIDEO_HELPER_CHIPS_AUTO || VIDEO_SAA7134 && MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && VIDEO_DEV && PCI && I2C && INPUT
&& VIDEO_IR && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_SAA6588 which has
unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
!VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_ZORAN_LML33 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_V4L2 && VIDEO_ZORAN_ZR36060 && VIDEO_HELPER_CHIPS_AUTO) selects
VIDEO_BT819 which has unmet direct dependencies (MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_ZORAN_LML33 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_V4L2 && VIDEO_ZORAN_ZR36060 && VIDEO_HELPER_CHIPS_AUTO ||
VIDEO_ZORAN_AVS6EYES && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_V4L2 && VIDEO_ZORAN_ZR36060 && EXPERIMENTAL &&
VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_BT856 which has unmet direct
dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
!VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_ZORAN_AVS6EYES && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS
&& VIDEO_V4L2 && VIDEO_ZORAN_ZR36060 && EXPERIMENTAL &&
VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_BT866 which has unmet direct
dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
!VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_ZORAN_AVS6EYES && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS
&& VIDEO_V4L2 && VIDEO_ZORAN_ZR36060 && EXPERIMENTAL &&
VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_KS0127 which has unmet direct
dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
!VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_CAFE_CCIC && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
PCI && I2C && VIDEO_V4L2) selects VIDEO_OV7670 which has unmet direct
dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
!VIDEO_HELPER_CHIPS_AUTO && I2C && VIDEO_V4L2)
warning: (VIDEO_EM28XX && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_V4L2 && V4L_USB_DRIVERS && USB && VIDEO_DEV && I2C && INPUT &&
VIDEO_IR && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_MT9V011 which has
unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
!VIDEO_HELPER_CHIPS_AUTO && I2C && VIDEO_V4L2)
warning: (VIDEO_ZORAN_DC10 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_V4L2 && VIDEO_ZORAN_ZR36060 && VIDEO_HELPER_CHIPS_AUTO) selects
VIDEO_SAA7110 which has unmet direct dependencies (MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_ZORAN_BUZ && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_V4L2 && VIDEO_ZORAN_ZR36060 && VIDEO_HELPER_CHIPS_AUTO ||
VIDEO_ZORAN_LML33R10 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_V4L2 && VIDEO_ZORAN_ZR36060 && VIDEO_HELPER_CHIPS_AUTO ||
VIDEO_MXB && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && PCI && VIDEO_V4L2
&& I2C && VIDEO_HELPER_CHIPS_AUTO || VIDEO_IVTV && MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR
|| VIDEO_PVRUSB2 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
V4L_USB_DRIVERS && USB && VIDEO_V4L2 && I2C && VIDEO_MEDIA ||
VIDEO_EM28XX && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 &&
V4L_USB_DRIVERS && USB && VIDEO_DEV && I2C && INPUT && VIDEO_IR &&
VIDEO_HELPER_CHIPS_AUTO || VIDEO_USBVISION && MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && V4L_USB_DRIVERS && USB && I2C && VIDEO_V4L2 &&
VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_SAA711X which has unmet direct
dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
!VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR) selects VIDEO_SAA717X
which has unmet direct dependencies (MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_EM28XX && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_V4L2 && V4L_USB_DRIVERS && USB && VIDEO_DEV && I2C && INPUT &&
VIDEO_IR && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_TVP5150 which has
unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
!VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_ZORAN_DC30 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_V4L2 && VIDEO_ZORAN && VIDEO_HELPER_CHIPS_AUTO) selects
VIDEO_VPX3220 which has unmet direct dependencies (MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_CX23885 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_V4L2 && DVB_CORE && VIDEO_DEV && PCI && I2C && INPUT && IR_CORE ||
VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 &&
PCI && I2C && INPUT && VIDEO_IR || VIDEO_PVRUSB2 && MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && V4L_USB_DRIVERS && USB && VIDEO_V4L2 && I2C &&
VIDEO_MEDIA || VIDEO_CX231XX && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS
&& VIDEO_V4L2 && V4L_USB_DRIVERS && USB && VIDEO_DEV && I2C && INPUT &&
VIDEO_IR || VIDEO_CX25821 && STAGING && !STAGING_EXCLUDE_BUILD &&
DVB_CORE && VIDEO_DEV && PCI && I2C && INPUT && BKL) selects
VIDEO_CX25840 which has unmet direct dependencies (MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_CX88_BLACKBIRD && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS
&& VIDEO_V4L2 && VIDEO_CX88 || VIDEO_CX23885 && MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && DVB_CORE && VIDEO_DEV && PCI &&
I2C && INPUT && IR_CORE || VIDEO_IVTV && MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR
|| VIDEO_CX18 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 &&
DVB_CORE && PCI && I2C && EXPERIMENTAL && INPUT && VIDEO_IR ||
VIDEO_PVRUSB2 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
V4L_USB_DRIVERS && USB && VIDEO_V4L2 && I2C && VIDEO_MEDIA ||
VIDEO_CX25821 && STAGING && !STAGING_EXCLUDE_BUILD && DVB_CORE &&
VIDEO_DEV && PCI && I2C && INPUT && BKL) selects VIDEO_CX2341X which has
unmet direct dependencies (MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
!VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && VIDEO_V4L2_COMMON)
warning: (VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR) selects VIDEO_SAA7127
which has unmet direct dependencies (MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_ZORAN_BUZ && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_V4L2 && VIDEO_ZORAN_ZR36060 && VIDEO_HELPER_CHIPS_AUTO) selects
VIDEO_SAA7185 which has unmet direct dependencies (MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_ZORAN_LML33R10 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS
&& VIDEO_V4L2 && VIDEO_ZORAN_ZR36060 && VIDEO_HELPER_CHIPS_AUTO) selects
VIDEO_ADV7170 which has unmet direct dependencies (MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_ZORAN_DC30 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_V4L2 && VIDEO_ZORAN && VIDEO_HELPER_CHIPS_AUTO || VIDEO_ZORAN_DC10
&& MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 &&
VIDEO_ZORAN_ZR36060 && VIDEO_HELPER_CHIPS_AUTO) selects VIDEO_ADV7175
which has unmet direct dependencies (MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR) selects VIDEO_UPD64031A
which has unmet direct dependencies (MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
warning: (VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS &&
VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR) selects VIDEO_UPD64083
which has unmet direct dependencies (MEDIA_SUPPORT &&
VIDEO_CAPTURE_DRIVERS && !VIDEO_HELPER_CHIPS_AUTO && VIDEO_V4L2 && I2C)
> Haven't had a chance to research it yet.
Neither me had.
regards,
--
js
^ permalink raw reply
* Re: fatal: BUG: dashless options don't support arguments
From: Johannes Sixt @ 2010-10-08 6:59 UTC (permalink / raw)
To: Brian Zitzow; +Cc: git
In-Reply-To: <AANLkTikqB-EvE6uxgBmutssJoiH2RiPjSxtjbo++Jj-X@mail.gmail.com>
Am 10/8/2010 2:06, schrieb Brian Zitzow:
> Hello,
> I was asked to report this bug error... Environment: OS 10.4.11 PowerPC:
>
> Ki:$ git branch
> * branch1
> master
> Ki:$ git checkout master
> fatal: BUG: dashless options don't support arguments
> Ki:$ git --version
> git version 1.7.3.GIT
Maybe related to this one:
http://thread.gmane.org/gmane.linux.kernel/973211/focus=973865
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/5] defaultenv: introduce CONFIG_DEFAULT_ENVIRONMENT_GENERIC to enable it
From: Sascha Hauer @ 2010-10-08 6:59 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD; +Cc: barebox
In-Reply-To: <1286469458-11362-1-git-send-email-plagnioj@jcrosoft.com>
On Thu, Oct 07, 2010 at 06:37:34PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> this will we usefull to enable functionnality if used
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> ---
> arch/arm/configs/neso_defconfig | 3 ++-
> arch/arm/configs/pca100_defconfig | 3 ++-
> arch/arm/configs/pcm037_defconfig | 3 ++-
> arch/arm/configs/pcm038_defconfig | 3 ++-
> arch/arm/configs/pcm043_defconfig | 3 ++-
> common/Kconfig | 7 +++++++
> common/Makefile | 4 ++++
> 7 files changed, 21 insertions(+), 5 deletions(-)
>
>
> +config DEFAULT_ENVIRONMENT_GENERIC
> + bool
> + depends on DEFAULT_ENVIRONMENT
> + prompt "Default environment generic"
> + help
> + Generic barebox default env
How about a bit more verbosity:
prompt "Add generic default environment"
help
With this option barebox will use the generic default
environment found under defaultenv/ in the src tree.
The Directory given with DEFAULT_ENVIRONMENT_PATH
will be added to the default environment. This should
at least contain a /env/config file.
> +
> config DEFAULT_ENVIRONMENT_PATH
> string
> depends on DEFAULT_ENVIRONMENT
> diff --git a/common/Makefile b/common/Makefile
> index e56dbc2..b42ab7a 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -26,6 +26,10 @@ ifdef CONFIG_DEFAULT_ENVIRONMENT
> $(obj)/startup.o: include/generated/barebox_default_env.h
> $(obj)/env.o: include/generated/barebox_default_env.h
>
> +ifeq ($(CONFIG_DEFAULT_ENVIRONMENT_GENERIC),y)
> +CONFIG_DEFAULT_ENVIRONMENT_PATH += defaultenv
> +endif
This reverses the order the different environment directories are
parsed. Now the files from defaultenv will overwrite the ones
from DEFAULT_ENVIRONMENT_PATH. I made it intentionally the other
way round.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* [PULL] soc-camera: welcome a new host: OMAP1 and a couple of new sensor drivers
From: Guennadi Liakhovetski @ 2010-10-08 7:00 UTC (permalink / raw)
To: Linux Media Mailing List; +Cc: Mauro Carvalho Chehab, Laurent Pinchart
Hi Mauro
So, as promised, here goes part 2 of 2.6.37 patches for soc-camera and
related. There's also going to be one issue with this one to take care of:
the last patch will conflict with Laurent's pad-level ops patches, which
also move mediabus pixel codes around. But since Laurent's patches are
still at the RFC stage, AFAICS, they'll have to be extended slightly:)
The following changes since commit 81d64d12e11a3cca995e6c752e4bd2898959ed0a:
V4L/DVB: cx231xx: remove some unused functions (2010-10-07 21:05:52 -0300)
are available in the git repository at:
git://linuxtv.org/gliakhovetski/v4l-dvb.git for-2.6.37
Guennadi Liakhovetski (3):
V4L: add IMX074 sensor chip ID
V4L: add an IMX074 sensor soc-camera / v4l2-subdev driver
V4L: sh_mobile_ceu_camera: use default .get_parm() and .set_parm() operations
Janusz Krzysztofik (3):
SoC Camera: add driver for OMAP1 camera interface
SoC Camera: add driver for OV6650 sensor
SoC Camera: add support for g_parm / s_parm operations
Michael Grzeschik (1):
mt9m111: changed MIN_DARK_COLS to MT9M131 spec count
Sascha Hauer (1):
v4l2-mediabus: Add pixelcodes for BGR565 formats
drivers/media/video/Kconfig | 20 +
drivers/media/video/Makefile | 3 +
drivers/media/video/imx074.c | 508 +++++++++
drivers/media/video/mt9m111.c | 2 +-
drivers/media/video/omap1_camera.c | 1702 ++++++++++++++++++++++++++++
drivers/media/video/ov6650.c | 1225 ++++++++++++++++++++
drivers/media/video/sh_mobile_ceu_camera.c | 18 -
drivers/media/video/soc_camera.c | 18 +
include/media/omap1_camera.h | 35 +
include/media/v4l2-chip-ident.h | 4 +
include/media/v4l2-mediabus.h | 2 +
11 files changed, 3518 insertions(+), 19 deletions(-)
create mode 100644 drivers/media/video/imx074.c
create mode 100644 drivers/media/video/omap1_camera.c
create mode 100644 drivers/media/video/ov6650.c
create mode 100644 include/media/omap1_camera.h
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH 02/18] fs: Convert nr_inodes and nr_unused to per-cpu counters
From: Christoph Hellwig @ 2010-10-08 7:01 UTC (permalink / raw)
To: Dave Chinner; +Cc: linux-fsdevel, linux-kernel
In-Reply-To: <1286515292-15882-3-git-send-email-david@fromorbit.com>
On Fri, Oct 08, 2010 at 04:21:16PM +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
>
> The number of inodes allocated does not need to be tied to the
> addition or removal of an inode to/from a list. If we are not tied
> to a list lock, we could update the counters when inodes are
> initialised or destroyed, but to do that we need to convert the
> counters to be per-cpu (i.e. independent of a lock). This means that
> we have the freedom to change the list/locking implementation
> without needing to care about the counters.
>
> Based on a patch originally from Eric Dumazet.
>
> Signed-off-by: Dave Chinner <dchinner@redhat.com>
Looks good except for a spurious whitespace change in inode_init_early.
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Pour votre securité faites confiance au numero 1 Europeen
From: SD Telesurveillance par Plein Temps @ 2010-10-08 7:01 UTC (permalink / raw)
To: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
^ permalink raw reply
* Re: [Xenomai-help] kernel oopses when killing realtime task
From: Pavel Machek @ 2010-10-08 7:01 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai
In-Reply-To: <4CADBDC2.8080600@domain.hid>
Hi!
> > I have... quite an interesting setup here.
> >
> > SMP machine, with special PCI card; that card has GPIOs and serial
> > ports. Unfortunately, there's only one interrupt, shared between
> > serials and GPIO pins, and serials are way too complex to be handled
> > by realtime layer.
> >
> > So I ended up with
> >
> > // we also have an interrupt handler:
> > ret = rtdm_irq_request(&my_context->irq_handle,
> > gpio_rt_config.irq, demo_interrupt,
> > RTDM_IRQTYPE_SHARED,
> > context->device->proc_name, my_context);
> >
> > and
> >
> > static int demo_interrupt(rtdm_irq_t *irq_context)
> > {
> > struct demodrv_context *ctx;
> > int dev_id;
> > int ret = RTDM_IRQ_HANDLED; // usual return value
> > unsigned pending, output;
> >
> > ctx = rtdm_irq_get_arg(irq_context, struct demodrv_context);
> > dev_id = ctx->dev_id;
> >
> > if (!ctx->ready) {
> > printk(KERN_CRIT "Unexpected interrupt\n");
> > return XN_ISR_PROPAGATE;
>
> Who sets ready and when? Looks racy.
Debugging aid; yes, this one is racy.
> > rtdm_lock_put(&ctx->lock);
> >
> > /* We need to propagate the interrupt, so that PMC-6L serials
> > work. Result is that interrupt latencies can't be
> > guaranteed when serials are in use. */
> >
> > return RTDM_IRQ_HANDLED;
> > }
> >
> > Unregistration is:
> > my_context->ready = 0;
> > rtdm_irq_disable(&my_context->irq_handle);
>
> Where is rtdm_irq_free? Again, this ready flag looks racy.
Aha, sorry, I quoted wrong snippet. rtdm_irq_free() follows
immediately, like this:
int demo_close_rt(struct rtdm_dev_context *context,
rtdm_user_info_t *user_info)
{
struct demodrv_context *my_context;
rtdm_lockctx_t lock_ctx;
// get the context
my_context = (struct demodrv_context *)context->dev_private;
// if we need to do some stuff with preemption disabled:
rtdm_lock_get_irqsave(&my_context->lock, lock_ctx);
my_context->ready = 0;
rtdm_irq_disable(&my_context->irq_handle);
// free irq in RTDM
rtdm_irq_free(&my_context->irq_handle);
// destroy our interrupt signal/event
rtdm_event_destroy(&my_context->irq_event);
// other stuff here
rtdm_lock_put_irqrestore(&my_context->lock, lock_ctx);
return 0;
}
Now... I'm aware that lock_get/put around irq_free should be
unneccessary, as should be irq_disable and my ->ready flag. Those were
my attempts to work around the problem. I'll attach the full source at
the end.
> > Unfortunately, when the userspace app is ran and killed repeatedly (so
> > that interrupt is registered/unregistered all the time), I get
> > oopses in __ipipe_dispatch_wired() -- it seems to call into the NULL
> > pointer.
> >
> > I decided that "wired" interrupt when the source is shared between
> > Linux and Xenomai, is wrong thing, so I disable "wired" interrupts
> > altogether, but that only moved oops to __virq_end.
>
> This is wrong. The only way to get a determistically shared IRQs across
> domains is via the wired path, either using the pattern Gilles cited or,
> in a slight variation, signaling down via a separate rtdm_nrtsig.
For now, I'm trying to get it not to oops; deterministic latencies are
the next topic :-(.
The hardware is little unusual that it generates interrupts at 1kHz,
whether realtime driver is loaded or not.
Pavel
/**********************************************************/
/* HARD REAL TIME RTDM Driver Skeleton V1.1 */
/* */
/* Based on code of Jan Kiszka - thanks Jan! */
/* (C) 2006 Jan Kiszka, www.captain.at */
/* (C) 2010 Pavel Machek, sysgo */
/* License: GPL */
/**********************************************************/
/* Note: Interrupt is shared between serial lines and GPIOs. That
means that interrupt latencies can't be guaranteed when serials are
in use.
*/
#include <linux/mman.h>
#include <rtdm/rtdm_driver.h>
#include "pmc6l-rt.h"
char dummy_buffer[BUFSIZE];
int events;
// our driver context struct: used for storing various information
struct demodrv_context {
rtdm_irq_t irq_handle;
rtdm_lock_t lock;
int dev_id;
u64 last_timestamp;
rtdm_event_t irq_event;
volatile unsigned long irq_event_lock;
volatile int irq_events;
int64_t timeout;
void *buf;
int ready;
};
#define GPIO_CONF_LOW 0xb0
#define GPIO_CONF_HIGH 0xb2
#define GPIO_STATUS_IN 0xb4
#define GPIO_STATUS_OUT 0xb6
#define GPIO_IRQ_ID 0x2a
#define iowrite(bits, val, adr) iowrite##bits(cpu_to_be##bits(val), adr)
#define ioread(bits, adr) be##bits##_to_cpu(ioread##bits(adr))
#define pgwrite(dat, adr) iowrite(16, (dat), gpio_rt_config.mmio+(adr))
#define pgread(adr) ioread(16, gpio_rt_config.mmio+(adr))
/**********************************************************/
/* INTERRUPT HANDLING */
/**********************************************************/
/*
* Demo interrupt code; when GPIO #2 is changed, GPIO #4 is toggled.
*/
static int demo_interrupt(rtdm_irq_t *irq_context)
{
struct demodrv_context *ctx;
int dev_id;
int ret = RTDM_IRQ_HANDLED; // usual return value
unsigned pending, output;
ctx = rtdm_irq_get_arg(irq_context, struct demodrv_context);
dev_id = ctx->dev_id;
if (!ctx->ready) {
printk(KERN_CRIT "Unexpected interrupt\n");
return XN_ISR_PROPAGATE;
}
#if 0
rtdm_lock_get(&ctx->lock);
pending = pgread(GPIO_IRQ_ID);
pgwrite(0, GPIO_IRQ_ID);
output = pgread(GPIO_STATUS_OUT);
output ^= (1<<3);
pgwrite(output, GPIO_STATUS_OUT);
// do stuff
if (events > 1000) {
rtdm_event_signal(&ctx->irq_event);
events = 0;
}
events++;
rtdm_lock_put(&ctx->lock);
// those return values were dropped from the RTDM
// ret = RTDM_IRQ_ENABLE | RTDM_IRQ_PROPAGATE;
/* We need to propagate the interrupt, so that PMC-6L serials
work. Result is that interrupt latencies can't be
guaranteed when serials are in use. */
// return XN_ISR_PROPAGATE;
return RTDM_IRQ_HANDLED;
#else
pending = pgread(GPIO_IRQ_ID);
pgwrite(0, GPIO_IRQ_ID);
output = pgread(GPIO_STATUS_OUT);
output = output & (~(1<<3));
if (pgread(GPIO_STATUS_IN) & (1<<1))
output |= (1<<3);
pgwrite(output, GPIO_STATUS_OUT);
// those return values were dropped from the RTDM
// ret = RTDM_IRQ_ENABLE | RTDM_IRQ_PROPAGATE;
/* We need to propagate the interrupt, so that PMC-6L serials
work. Result is that interrupt latencies can't be
guaranteed when serials are in use. */
// return XN_ISR_PROPAGATE;
return RTDM_IRQ_HANDLED;
#endif
}
/**********************************************************/
/* DRIVER OPEN */
/**********************************************************/
int demo_open_rt(struct rtdm_dev_context *context,
rtdm_user_info_t *user_info,
int oflags)
{
struct demodrv_context *my_context;
int dev_id = context->device->device_id;
int ret;
// get the context for our driver - used to store driver info
my_context = (struct demodrv_context *)context->dev_private;
// we also have an interrupt handler:
ret = rtdm_irq_request(&my_context->irq_handle, gpio_rt_config.irq, demo_interrupt,
RTDM_IRQTYPE_SHARED, context->device->proc_name, my_context);
if (ret < 0)
return ret;
/* IPC initialisation - cannot fail with used parameters */
rtdm_lock_init(&my_context->lock);
rtdm_event_init(&my_context->irq_event, 0);
my_context->dev_id = dev_id;
my_context->irq_events = 0;
my_context->irq_event_lock = 0;
my_context->ready = 1;
my_context->timeout = 0; // wait INFINITE
// enable interrupt in RTDM
rtdm_irq_enable(&my_context->irq_handle);
return 0;
}
/**********************************************************/
/* DRIVER CLOSE */
/**********************************************************/
int demo_close_rt(struct rtdm_dev_context *context,
rtdm_user_info_t *user_info)
{
struct demodrv_context *my_context;
rtdm_lockctx_t lock_ctx;
// get the context
my_context = (struct demodrv_context *)context->dev_private;
// if we need to do some stuff with preemption disabled:
rtdm_lock_get_irqsave(&my_context->lock, lock_ctx);
my_context->ready = 0;
rtdm_irq_disable(&my_context->irq_handle);
// free irq in RTDM
rtdm_irq_free(&my_context->irq_handle);
// destroy our interrupt signal/event
rtdm_event_destroy(&my_context->irq_event);
// other stuff here
rtdm_lock_put_irqrestore(&my_context->lock, lock_ctx);
return 0;
}
/**********************************************************/
/* DRIVER READ */
/**********************************************************/
int demo_read_rt(struct rtdm_dev_context *context,
rtdm_user_info_t *user_info, void *buf, size_t nbyte)
{
struct demodrv_context *ctx;
int dev_id;
char *out_pos = (char *)buf;
rtdm_toseq_t timeout_seq;
int ret;
// zero bytes requested ? return!
if (nbyte == 0)
return 0;
// check if R/W actions to user-space are allowed
if (user_info && !rtdm_rw_user_ok(user_info, buf, nbyte))
return -EFAULT;
ctx = (struct demodrv_context *)context->dev_private;
dev_id = ctx->dev_id;
// wait: if ctx->timeout = 0, it will block infintely until
// rtdm_event_signal(&ctx->irq_event); is called from our
// interrupt routine
ret = rtdm_event_timedwait(&ctx->irq_event, ctx->timeout, &timeout_seq);
// now write the requested stuff to user-space
if (rtdm_copy_to_user(user_info, out_pos,
dummy_buffer, BUFSIZE) != 0) {
ret = -EFAULT;
} else {
ret = BUFSIZE;
}
return ret;
}
/**********************************************************/
/* DRIVER OPERATIONS */
/**********************************************************/
static struct rtdm_device demo_device = {
struct_version: RTDM_DEVICE_STRUCT_VER,
device_flags: RTDM_NAMED_DEVICE,
context_size: sizeof(struct demodrv_context),
device_name: DEV_FILE,
/* open and close functions are not real-time safe due kmalloc
and kfree. If you do not use kmalloc and kfree, and you made
sure that there is no syscall in the open/close handler, you
can declare the open_rt and close_rt handler.
*/
open_rt: NULL,
open_nrt: demo_open_rt,
ops: {
close_rt: NULL,
close_nrt: demo_close_rt,
ioctl_rt: NULL,
ioctl_nrt: NULL,
read_rt: demo_read_rt,
read_nrt: NULL,
write_rt: NULL,
write_nrt: NULL,
recvmsg_rt: NULL,
recvmsg_nrt: NULL,
sendmsg_rt: NULL,
sendmsg_nrt: NULL,
},
device_class: RTDM_CLASS_EXPERIMENTAL,
device_sub_class: 222,
driver_name: DRV_NAME,
peripheral_name: DEV_FILE_NAME,
provider_name: "-",
proc_name: demo_device.device_name,
};
/**********************************************************/
/* INIT DRIVER */
/**********************************************************/
int init_module(void)
{
pmc_gpio_rt_config();
printk("realtime driver at irq %d mmio %x\n",
gpio_rt_config.irq, gpio_rt_config.mmio);
return rtdm_dev_register(&demo_device);
}
/**********************************************************/
/* CLEANUP DRIVER */
/**********************************************************/
void cleanup_module(void)
{
rtdm_dev_unregister(&demo_device, 1000);
}
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("RTDM Real Time Driver Example");
--- user app ----
/**********************************************************/
/* HARD REAL TIME RTDM Driver User-Space Application */
/* */
/* Based on code of Jan Kiszka - thanks Jan! */
/* (C) 2006 Jan Kiszka, www.captain.at */
/* (C) 2010 Pavel Machek, sysgo */
/* License: GPL */
/**********************************************************/
#include <stdio.h>
#include <signal.h>
#include <unistd.h>
#include <sys/mman.h>
#include <native/task.h>
#include <native/timer.h>
#include <rtdm/rtdm.h>
#include "pmc6l-rt.h"
unsigned int my_state = 0;
int timer_started = 0;
int my_fd = -1;
int shutdownnow = 0;
RT_TASK my_task;
// --s-ms-us-ns
RTIME my_task_period_ns = 1000000000llu;
/**********************************************************/
/* CLOSE RT DRIVER */
/**********************************************************/
static int close_file( int fd, unsigned char *name) {
int ret,i=0;
do {
i++;
ret = rt_dev_close(fd);
switch(-ret){
case EBADF: printf("%s -> invalid fd or context\n",name);
break;
case EAGAIN: printf("%s -> EAGAIN (%d times)\n",name,i);
rt_task_sleep(50000); // wait 50us
break;
case 0: printf("%s -> closed\n",name);
break;
default: printf("%s -> ???\n",name);
break;
}
} while (ret == -EAGAIN && i < 10);
return ret;
}
/**********************************************************/
/* CLEANING UP */
/**********************************************************/
void cleanup_all(void) {
if (my_state & STATE_FILE_OPENED) {
close_file( my_fd, DEV_FILE " (user)");
my_state &= ~STATE_FILE_OPENED;
}
if (my_state & STATE_TASK_CREATED) {
printf("delete my_task\n");
rt_task_delete(&my_task);
my_state &= ~STATE_TASK_CREATED;
}
if (timer_started) {
printf("stop timer\n");
rt_timer_stop();
}
}
void catch_signal(int sig) {
shutdownnow = 1;
cleanup_all();
printf("exit\n");
return;
}
/**********************************************************/
/* REAL TIME TASK */
/**********************************************************/
void my_task_proc(void *arg) {
int ret;
ssize_t sz = sizeof(RTIME);
ssize_t written = 0;
ssize_t read = 0;
int counter = 0;
int readbackcounter;
unsigned char buf[17] = "CAPTAIN WAS HERE\0";
unsigned char buf2[17] = "XXXXXXXXXXXXXXXX\0";
/* no periodic task, due blocking read from the RT driver (see below too)
ret = rt_task_set_periodic(NULL, TM_NOW, rt_timer_ns2ticks(my_task_period_ns));
if (ret) {
printf("error while set periodic, code %d\n",ret);
goto exit_my_task;
}
*/
while (1) {
sprintf(buf, "CAPTAIN %d", counter);
counter++;
if (counter > 100) counter = 0;
/* switch to primary mode */
ret = rt_task_set_mode(0, T_PRIMARY, NULL);
if (ret) {
printf("error while rt_task_set_mode, code %d\n",ret);
goto exit_my_task;
}
sz = sizeof(buf2);
read = rt_dev_read(my_fd, &buf2, sizeof(buf2));
if (read == sz ) {
printf("READ: read=%s\n",buf2);
} else {
if (read < 0 ) {
printf("error while rt_dev_read, code %d\n",read);
} else {
printf("only %d / %d byte received \n",read,sz);
}
}
// read blocks, so check if user hit CTRL-C meanwhile
// otherwise we segfault when mmap'ing
if (shutdownnow == 1) break;
}
exit_my_task:
if (my_state & STATE_FILE_OPENED) {
if (!close_file( my_fd, DEV_FILE " (write)")) {
my_state &= ~STATE_FILE_OPENED;
}
}
printf("exit\n");
}
/**********************************************************/
/* MAIN: mainly RT task initialization */
/**********************************************************/
int main(int argc, char* argv[]) {
int ret = 0;
signal(SIGTERM, catch_signal);
signal(SIGINT, catch_signal);
printf("PRESS CTRL-C to EXIT\n");
/* no memory-swapping for this programm */
mlockall(MCL_CURRENT | MCL_FUTURE);
/* start timer */
ret = rt_timer_start(TM_ONESHOT);
switch (ret) {
case 0: printf("timer started\n");
timer_started = 1;
break;
case -EBUSY: printf("timer is running\n");
timer_started = 0;
break;
case -ENOSYS: printf("can't start timer\n");
return ret;
}
/* open DEV_FILE */
my_fd = rt_dev_open( DEV_FILE, 0);
if (my_fd < 0) {
printf("can't open %s\n", DEV_FILE);
goto error;
}
my_state |= STATE_FILE_OPENED;
printf("%s opened\n", DEV_FILE);
/* create my_task */
ret = rt_task_create(&my_task,"my_task",0,50,0);
if (ret) {
printf("failed to create my_task, code %d\n",ret);
goto error;
}
my_state |= STATE_TASK_CREATED;
printf("my_task created\n");
/* start my_task */
printf("starting my_task\n");
ret = rt_task_start(&my_task,&my_task_proc,NULL);
if (ret) {
printf("failed to start my_task, code %d\n",ret);
goto error;
}
pause();
return 0;
error:
cleanup_all();
return ret;
}
^ permalink raw reply
* Re: [PATCH 03/18] fs: keep inode with backing-dev
From: Christoph Hellwig @ 2010-10-08 7:01 UTC (permalink / raw)
To: Dave Chinner; +Cc: linux-fsdevel, linux-kernel
In-Reply-To: <1286515292-15882-4-git-send-email-david@fromorbit.com>
On Fri, Oct 08, 2010 at 04:21:17PM +1100, Dave Chinner wrote:
> From: Nick Piggin <npiggin@suse.de>
>
> Having inode on writeback lists of a different bdi than
> inode->i_mapping->backing_dev_info makes it very difficult to do
> per-bdi locking of the writeback lists. Add functions to move these
> inodes over when the mapping backing dev is changed.
>
> Also, rename i_mapping.backing_dev_info to i_mapping.a_bdi while we're
> here. Succinct is nice, and it catches conversion errors.
NAK. This is fixed by my patch to always use s_bdi for writeback
purposed that hit Linus' tree two days ago.
^ permalink raw reply
* Re: .* entries in official release source tarballs
From: Jan Beulich @ 2010-10-08 7:02 UTC (permalink / raw)
To: Ian Jackson; +Cc: xen-devel@lists.xensource.com
In-Reply-To: <19629.63891.993200.856801@mariner.uk.xensource.com>
>>> On 07.10.10 at 18:47, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("[Xen-devel] .* entries in official release source
> tarballs"):
>> Since these are - afaict - meaningless outside of mercurial, would it be
>> possible to drop them when creating the tarballs?
>
> It would be possible but I don't think it's a good idea. The more
> steps are involved in creating the official release tarballs, the more
> likely it is that something will go wrong.
>
> Are these files causing some kind of problem for you ?
No, not a problem really - they're just confusing/meaningless there
(just like I thing .*ignore files scattered around source trees don't
belong in release tarballs).
Jan
^ permalink raw reply
* [PATCH 1/2] MMCI: add some register defines for ST Micro variants
From: Linus Walleij @ 2010-10-08 7:02 UTC (permalink / raw)
To: linux-arm-kernel
This adds a few registers to the MMCI/PL180 derivates that
is used for some odd control stuff like SDIO.
Signed-off-by: Marcin Mielczarczyk <marcin.mielczarczyk@tieto.com>
Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
---
drivers/mmc/host/mmci.h | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index acac081..690f2c6 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -54,10 +54,16 @@
#define MCI_DPSM_MODE (1 << 2)
#define MCI_DPSM_DMAENABLE (1 << 3)
#define MCI_DPSM_BLOCKSIZE (1 << 4)
-#define MCI_DPSM_RWSTART (1 << 8)
-#define MCI_DPSM_RWSTOP (1 << 9)
-#define MCI_DPSM_RWMOD (1 << 10)
-#define MCI_DPSM_SDIOEN (1 << 11)
+/* Control register extensions in the ST Micro U300 and Ux500 versions */
+#define MCI_ST_DPSM_RWSTART (1 << 8)
+#define MCI_ST_DPSM_RWSTOP (1 << 9)
+#define MCI_ST_DPSM_RWMOD (1 << 10)
+#define MCI_ST_DPSM_SDIOEN (1 << 11)
+/* Control register exeensions in the ST Micro Ux500 versions */
+#define MCI_ST_DPSM_DMAREQCTL (1 << 12)
+#define MCI_ST_DPSM_DBOOTMODEEN (1 << 13)
+#define MCI_ST_DPSM_BUSYMODE (1 << 14)
+#define MCI_ST_DPSM_DDRMODE (1 << 15)
#define MMCIDATACNT 0x030
#define MMCISTATUS 0x034
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] mmc: MMC 4.4 DDR support
From: Adrian Hunter @ 2010-10-08 7:02 UTC (permalink / raw)
To: Philip Rakity; +Cc: linux-mmc@vger.kernel.org
In-Reply-To: <DFA7B5FE-718A-484B-BA1D-D1B44E3A5A32@marvell.com>
On 01/10/10 06:01, ext Philip Rakity wrote:
>
> I was wondering if we could remove one of the CAPS for DDR voltage (MMC_CAP_1_8V_DDR and MMC_CAP_1_2V_DDR). Both 1.2 and 1.8v are defined in the JEDEC Standard No. 84-A441.
>
> The sd 3.0 host controller only defines the option for 1.8v. I cannot see a way to set 1.2v.
>
> If this makes sense I can prepare a patch.--
If the host controller does not support 1.2V DDR then it should definitely
not set MMC_CAP_1_2V_DDR. That is precisely what the caps are for.
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 2/2] MMCI: add SDIO support for ST Variants
From: Linus Walleij @ 2010-10-08 7:02 UTC (permalink / raw)
To: linux-arm-kernel
This adds some minor variant data and trickery to enable SDIO
on the ST Micro variants of MMCI/PL180.
Signed-off-by: Marcin Mielczarczyk <marcin.mielczarczyk@tieto.com>
Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
---
drivers/mmc/host/mmci.c | 36 +++++++++++++++++++++++++++++++++++-
1 files changed, 35 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 09bcce7..cd9414b 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -19,6 +19,7 @@
#include <linux/highmem.h>
#include <linux/log2.h>
#include <linux/mmc/host.h>
+#include <linux/mmc/card.h>
#include <linux/amba/bus.h>
#include <linux/clk.h>
#include <linux/scatterlist.h>
@@ -54,6 +55,7 @@ struct variant_data {
unsigned int fifosize;
unsigned int fifohalfsize;
bool singleirq;
+ bool sdio;
};
static struct variant_data variant_arm = {
@@ -67,6 +69,7 @@ static struct variant_data variant_u300 = {
.fifohalfsize = 8 * 4,
.clkreg_enable = 1 << 13, /* HWFCEN */
.datalength_bits = 16,
+ .sdio = true,
};
static struct variant_data variant_ux500 = {
@@ -76,6 +79,7 @@ static struct variant_data variant_ux500 = {
.clkreg_enable = 1 << 14, /* HWFCEN */
.datalength_bits = 24,
.singleirq = true,
+ .sdio = true,
};
/*
@@ -217,6 +221,11 @@ static void mmci_start_data(struct mmci_host *host, struct mmc_data *data)
irqmask = MCI_TXFIFOHALFEMPTYMASK;
}
+ /* The ST Micro variants has a special bit to enable SDIO */
+ if (variant->sdio && host->mmc->card)
+ if (mmc_card_sdio(host->mmc->card))
+ datactrl |= MCI_ST_DPSM_SDIOEN;
+
writel(datactrl, base + MMCIDATACTRL);
writel(readl(base + MMCIMASK0) & ~MCI_DATAENDMASK, base + MMCIMASK0);
mmci_set_mask1(host, irqmask);
@@ -415,7 +424,32 @@ static int mmci_pio_write(struct mmci_host *host, char *buffer, unsigned int rem
variant->fifosize : variant->fifohalfsize;
count = min(remain, maxcnt);
- writesl(base + MMCIFIFO, ptr, count >> 2);
+ /*
+ * The ST Micro variant for SDIO transfer sizes
+ * less then 8 bytes should have clock H/W flow
+ * control disabled.
+ */
+ if (variant->sdio &&
+ mmc_card_sdio(host->mmc->card)) {
+ if (count < 8)
+ writel(readl(host->base + MMCICLOCK) &
+ ~variant->clkreg_enable,
+ host->base + MMCICLOCK);
+ else
+ writel(readl(host->base + MMCICLOCK) |
+ variant->clkreg_enable,
+ host->base + MMCICLOCK);
+ }
+
+ /*
+ * SDIO especially may want to send something that is
+ * not divisible by 4 (as opposed to card sectors
+ * etc), and the FIFO only accept full 32-bit writes.
+ * So compensate by adding +3 on the count, a single
+ * byte become a 32bit write, 7 bytes will be two
+ * 32bit writes etc.
+ */
+ writesl(base + MMCIFIFO, ptr, (count + 3) >> 2);
ptr += count;
remain -= count;
--
1.6.3.3
^ permalink raw reply related
* [patch] gdth: integer overflow in ioctl
From: Dan Carpenter @ 2010-10-08 7:03 UTC (permalink / raw)
To: Achim Leubner
Cc: James E.J. Bottomley, linux-scsi, linux-kernel, kernel-janitors
gdth_ioctl_alloc() takes the size variable as an int.
copy_from_user() takes the size variable as an unsigned long.
gen.data_len and gen.sense_len are unsigned longs.
On x86_64 longs are 64 bit and ints are 32 bit.
We could pass in a very large number and the allocation would truncate
the size to 32 bits and allocate a small buffer. Then when we do the
copy_from_user(), it would result in a memory corruption.
CC: stable@kernel.org
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index b860d65..4cf7ffa 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -4175,6 +4175,14 @@ static int ioc_general(void __user *arg, char *cmnd)
ha = gdth_find_ha(gen.ionode);
if (!ha)
return -EFAULT;
+
+ if (gen.data_len > INT_MAX)
+ return -EINVAL;
+ if (gen.sense_len > INT_MAX)
+ return -EINVAL;
+ if (gen.data_len + gen.sense_len > INT_MAX)
+ return -EINVAL;
+
if (gen.data_len + gen.sense_len != 0) {
if (!(buf = gdth_ioctl_alloc(ha, gen.data_len + gen.sense_len,
FALSE, &paddr)))
^ permalink raw reply related
* [patch] gdth: integer overflow in ioctl
From: Dan Carpenter @ 2010-10-08 7:03 UTC (permalink / raw)
To: Achim Leubner
Cc: James E.J. Bottomley, linux-scsi, linux-kernel, kernel-janitors
gdth_ioctl_alloc() takes the size variable as an int.
copy_from_user() takes the size variable as an unsigned long.
gen.data_len and gen.sense_len are unsigned longs.
On x86_64 longs are 64 bit and ints are 32 bit.
We could pass in a very large number and the allocation would truncate
the size to 32 bits and allocate a small buffer. Then when we do the
copy_from_user(), it would result in a memory corruption.
CC: stable@kernel.org
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index b860d65..4cf7ffa 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -4175,6 +4175,14 @@ static int ioc_general(void __user *arg, char *cmnd)
ha = gdth_find_ha(gen.ionode);
if (!ha)
return -EFAULT;
+
+ if (gen.data_len > INT_MAX)
+ return -EINVAL;
+ if (gen.sense_len > INT_MAX)
+ return -EINVAL;
+ if (gen.data_len + gen.sense_len > INT_MAX)
+ return -EINVAL;
+
if (gen.data_len + gen.sense_len != 0) {
if (!(buf = gdth_ioctl_alloc(ha, gen.data_len + gen.sense_len,
FALSE, &paddr)))
^ permalink raw reply related
* Re: [lm-sensors] [PATCH] coretemp: fix reading of microcode revision
From: Jan Beulich @ 2010-10-08 7:05 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <4CADB0A1020000780001B335@vpn.id2.novell.com>
>>> On 07.10.10 at 20:46, Fenghua Yu <fenghua.yu@intel.com> wrote:
> On Thu, Oct 07, 2010 at 02:36:01AM -0700, Jan Beulich wrote:
>> @@ -327,8 +336,13 @@ static int __devinit coretemp_probe(stru
>>
>> if ((c->x86_model = 0xe) && (c->x86_mask < 0xc)) {
>> /* check for microcode update */
>> - rdmsr_on_cpu(data->id, MSR_IA32_UCODE_REV, &eax, &edx);
>> - if (edx < 0x39) {
>> + err = smp_call_function_single(data->id, get_ucode_rev_on_cpu,
>> + &edx, 1);
>> + if (err)
>> + dev_warn(&pdev->dev,
>> + "Cannot determine microcode revision "
>> + "of the CPU!\n");
>
> When err, need to call dev_err and go to exit_free. This error handling
> should
> be same as edx < 0x39 case.
Hmm, not sure - I'd prefer to consider the machine usable in this
(theoretical only anyway) case.
Jan
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* Re: [PATCH] fast-import: Allow filemodify to set the root
From: Jonathan Nieder @ 2010-10-08 7:05 UTC (permalink / raw)
To: Johannes Sixt
Cc: Sverre Rabbelier, David Barr, Git Mailing List,
Ramkumar Ramachandra
In-Reply-To: <4CAEBF2E.8020206@viscovery.net>
Johannes Sixt wrote:
> Am 10/7/2010 22:28, schrieb Jonathan Nieder:
>> | For a command (like filter-branch --subdirectory-filter) that wants
>> | to commit a lot of trees that already exist in the object db, writing
>> | undeltified objects as loose files only to repack them later can
>> | involve a significant amount[*] of overhead.
>
> 1. But when an object already exists in the db, it won't be written again,
> will it?
In David's application, the trees already exist, but the commits are new.
> 2. Even though fast-import puts all (new) objects into a pack file, the
> pack is heavily sub-optimal, and you should repack -f anyway. So what's
> the point? Only to avoid a loose object?
To avoid thousands of loose objects.
> (I'm not saying that the patch is unwanted, but only that the
> justification is still not sufficiently complete.)
No problem - these questions are useful. If the result is learning
that something else is responsible for the speedup David observed in
his script, that would not be a bad outcome after all.
I suppose supporting M 040000 <tree> "" and C <path> "" could still
be a good idea in that case anyway, for the convenience of front-end
authors.
Jonathan
who still hasn't reviewed the patch (sorry)
^ permalink raw reply
* Re: [PATCH 04/18] fs: Implement lazy LRU updates for inodes.
From: Christoph Hellwig @ 2010-10-08 7:08 UTC (permalink / raw)
To: Dave Chinner; +Cc: linux-fsdevel, linux-kernel
In-Reply-To: <1286515292-15882-5-git-send-email-david@fromorbit.com>
Looks good,
Reviewed-by: Christoph Hellwig <hch@lst.de>
A few nipicks on the comments or lack thereof below:
> @@ -489,8 +484,15 @@ static void prune_icache(int nr_to_scan)
>
> inode = list_entry(inode_unused.prev, struct inode, i_list);
>
> - if (inode->i_state || atomic_read(&inode->i_count)) {
> + if (atomic_read(&inode->i_count) ||
> + (inode->i_state & ~I_REFERENCED)) {
> + list_del_init(&inode->i_list);
> + percpu_counter_dec(&nr_inodes_unused);
> + continue;
> + }
> + if (inode->i_state & I_REFERENCED) {
> list_move(&inode->i_list, &inode_unused);
> + inode->i_state &= ~I_REFERENCED;
> continue;
I think this code could use some comments explaining the lazy LRU
scheme.
> - if (inode != list_entry(inode_unused.next,
> - struct inode, i_list))
> - continue; /* wrong inode or list_empty */
> - if (!can_unuse(inode))
> + /*
> + * if we can't reclaim this inod immediately, give it
> + * another pass through the free list so we don't spin
> + * on it.
s/inod/inode/
> +
> + /*
> + * We avoid moving dirty inodes back onto the LRU now because I_FREEING
> + * is set and hence writeback_single_inode() won't move the inode
> + * around.
> + */
> + if (!list_empty(&inode->i_list)) {
> + list_del_init(&inode->i_list);
> + percpu_counter_dec(&nr_inodes_unused);
> + }
> +
The comment is a bit misleading. We do not only avoid moving it to the
LRU, but actively delete the inode from the LRU here. I don't think the
I_FREEING check isn't the only reason - the LRU code traditionally
couldn't deal with unlinked inodes at all, although the switch to
->evict_inode probably has fixed that.
^ permalink raw reply
* Re: [PATCH 00/08] ARM: Dynamic IRQ demux support
From: Eric Miao @ 2010-10-08 7:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimAjypE8jTEymyO-0FucXrT8voQ7jVxiZxHF==d@mail.gmail.com>
On Thu, Oct 7, 2010 at 2:39 PM, Magnus Damm <magnus.damm@gmail.com> wrote:
> Hi Eric,
>
> On Wed, Oct 6, 2010 at 10:06 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>> On Wed, Oct 6, 2010 at 3:17 PM, Magnus Damm <magnus.damm@gmail.com> wrote:
>>> ARM: Dynamic IRQ demux support
>
>> Just FYI, I had a patch months ago for this:
>>
>> http://www.spinics.net/linux/lists/arm-kernel/msg92836.html
>>
>> Do you think that's a simpler way to go?
>
> Thanks for the pointer. I wasn't aware of your patch, but the fact
> that both of us came up with similar solutions to the same problem
> clearly shows that there is a need for this feature.
>
> Your patch is much less intrusive compared to what i came up with. I
> like the simplicity. I guess it is natural that the simplicity comes
> with a bit of overhead. I'm thinking of the extra branches and
> whatever potential cache misses coming from the code and callback
> being located in different cache lines compared to the rest of the
> code in __irq_svc and __irq_usr.
>
> My patches keeps the handlers in the same cache lines as before, but
> this comes with the cost of more serious rearrangement of the code.
> Also, my alignment_trap patch may decrease performance, not sure how
> to deal with that in a good way.
Yeah, I was thinking of the performance degradation at that time as well.
What worried me most is actually the long jump. However, we do have
a long jump to asm_do_IRQ anyway.
And the optimizations like get_irqnr_preamble and get_irqnr_and_base
can be carried out in C code as well, or if that's tricky enough, inline
assembly code can also help.
>
> I don't mind so much which patch that gets merged, but I'm a little
> bit concerned about code duplication. My patch moves macros into a
> header file that each demux instance can make use of to minimize the
> amount of duplicated code. I'm not sure how you are planning on
> implementing each demux instance. If possible I'd like to see the
> irq_handler macro in a header file somewhere so we don't have to
> duplicate that code.
Machines will have to specify their IRQ demux handler, which could be
same among a group of machines which share common demux code, and
thus duplication can be avoided.
>
> On top of that I'd also like to break out the GIC demux code and put
> it in a central location, but that's a separate issue.
I think we can make a common function call for all the IRQ demux handler
for GIC then.
>
> Any thoughts? Shall I try to move the irq_handler macro to some header file?
>
Your patch is excellent, I don't mind either which gets in. What I'm a
bit concerned is the effort to keep up with the mostly optimized code.
I was thinking of a bit (not that much significant I guess) performance loss
when multiple IRQ demux handler is required for the sake of simplicity
and less intrusiveness, while still able to use the original optimized path
when that's not required (i.e. turning CONFIG_.... off).
Thoughts?
> Thanks,
>
> / magnus
>
^ permalink raw reply
* [PATCH 00/08] ARM: Dynamic IRQ demux support
From: Eric Miao @ 2010-10-08 7:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimAjypE8jTEymyO-0FucXrT8voQ7jVxiZxHF==d@mail.gmail.com>
On Thu, Oct 7, 2010 at 2:39 PM, Magnus Damm <magnus.damm@gmail.com> wrote:
> Hi Eric,
>
> On Wed, Oct 6, 2010 at 10:06 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>> On Wed, Oct 6, 2010 at 3:17 PM, Magnus Damm <magnus.damm@gmail.com> wrote:
>>> ARM: Dynamic IRQ demux support
>
>> Just FYI, I had a patch months ago for this:
>>
>> http://www.spinics.net/linux/lists/arm-kernel/msg92836.html
>>
>> Do you think that's a simpler way to go?
>
> Thanks for the pointer. I wasn't aware of your patch, but the fact
> that both of us came up with similar solutions to the same problem
> clearly shows that there is a need for this feature.
>
> Your patch is much less intrusive compared to what i came up with. I
> like the simplicity. I guess it is natural that the simplicity comes
> with a bit of overhead. I'm thinking of the extra branches and
> whatever potential cache misses coming from the code and callback
> being located in different cache lines compared to the rest of the
> code in __irq_svc and __irq_usr.
>
> My patches keeps the handlers in the same cache lines as before, but
> this comes with the cost of more serious rearrangement of the code.
> Also, my alignment_trap patch may decrease performance, not sure how
> to deal with that in a good way.
Yeah, I was thinking of the performance degradation at that time as well.
What worried me most is actually the long jump. However, we do have
a long jump to asm_do_IRQ anyway.
And the optimizations like get_irqnr_preamble and get_irqnr_and_base
can be carried out in C code as well, or if that's tricky enough, inline
assembly code can also help.
>
> I don't mind so much which patch that gets merged, but I'm a little
> bit concerned about code duplication. My patch moves macros into a
> header file that each demux instance can make use of to minimize the
> amount of duplicated code. I'm not sure how you are planning on
> implementing each demux instance. If possible I'd like to see the
> irq_handler macro in a header file somewhere so we don't have to
> duplicate that code.
Machines will have to specify their IRQ demux handler, which could be
same among a group of machines which share common demux code, and
thus duplication can be avoided.
>
> On top of that I'd also like to break out the GIC demux code and put
> it in a central location, but that's a separate issue.
I think we can make a common function call for all the IRQ demux handler
for GIC then.
>
> Any thoughts? Shall I try to move the irq_handler macro to some header file?
>
Your patch is excellent, I don't mind either which gets in. What I'm a
bit concerned is the effort to keep up with the mostly optimized code.
I was thinking of a bit (not that much significant I guess) performance loss
when multiple IRQ demux handler is required for the sake of simplicity
and less intrusiveness, while still able to use the original optimized path
when that's not required (i.e. turning CONFIG_.... off).
Thoughts?
> Thanks,
>
> / magnus
>
^ permalink raw reply
* RE: [PATCH v1 13/16] OMAP3: hwmod DSS: VENC Move init,exit to driver
From: Guruswamy, Senthilvadivu @ 2010-10-08 7:09 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: khilman@deeprootsystems.com, tomi.valkeinen@nokia.com,
paul@pwsan.com, Hiremath, Vaibhav, linux-omap@vger.kernel.org
In-Reply-To: <20101007215733.5ab1c091@surf>
> -----Original Message-----
> From: Thomas Petazzoni [mailto:thomas.petazzoni@free-electrons.com]
> Sent: Friday, October 08, 2010 1:28 AM
> To: Guruswamy, Senthilvadivu
> Cc: khilman@deeprootsystems.com; tomi.valkeinen@nokia.com; paul@pwsan.com;
> Hiremath, Vaibhav; linux-omap@vger.kernel.org
> Subject: Re: [PATCH v1 13/16] OMAP3: hwmod DSS: VENC Move init,exit to
> driver
>
> Hello Senthil,
>
> On Wed, 6 Oct 2010 16:44:56 +0530
> Guruswamy Senthilvadivu <svadivu@ti.com> wrote:
>
> > diff --git a/drivers/video/omap2/dss/venc.c
> b/drivers/video/omap2/dss/venc.c
> > index ec17b28..3a121cb 100644
> > --- a/drivers/video/omap2/dss/venc.c
> > +++ b/drivers/video/omap2/dss/venc.c
> > @@ -87,26 +87,6 @@
> > #define VENC_OUTPUT_TEST 0xC8
> > #define VENC_DAC_B__DAC_C 0xC8
> >
> > -/* VENC HW IP initialisation */
> > -static int omap_venchw_probe(struct platform_device *pdev)
> > -{
> > - return 0;
> > -}
> > -
> > -static int omap_venchw_remove(struct platform_device *pdev)
> > -{
> > - return 0;
> > -}
> > -
> > -static struct platform_driver omap_venchw_driver = {
> > - .probe = omap_venchw_probe,
> > - .remove = omap_venchw_remove,
> > - .driver = {
> > - .name = "dss_venc",
> > - .owner = THIS_MODULE,
> > - },
> > -};
>
> Would be better in patch 7/16 to put this stuff at the correct place
> (bottom of the file) so it does not need to be moved here.
>
[Senthil] Taken. Will do the movement in the first patch itself.
> > +/* VENC HW IP initialisation */
> > +static int omap_venchw_probe(struct platform_device *pdev)
> > +{
> > + int r;
> > + venc.pdev = pdev;
> > +
> > + r = venc_init(pdev);
> > + if (r) {
> > + DSSERR("Failed to initialize venc\n");
> > + goto err_venc;
> > + }
> > +
> > +err_venc:
> > + return r;
> > +}
> > +
> > +static int omap_venchw_remove(struct platform_device *pdev)
> > +{
> > + venc_exit();
> > + return 0;
> > +}
>
> Same comment as before: include the code of venc_init() and venc_exit()
> directly in the ->probe() and ->remove() hooks respectively.
>
> > +struct regulator *dss_get_vdda_dac(void)
> > +{
> > + struct regulator *reg;
> > +
> > + if (venc.vdda_dac_reg != NULL)
> > + return venc.vdda_dac_reg;
> > +
> > + reg = regulator_get(&venc.pdev->dev, "vdda_dac");
> > + if (!IS_ERR(reg))
> > + venc.vdda_dac_reg = reg;
> >
> > + return reg;
> > +}
>
> As far as I can see, this function is now only used in venc_init(),
> which is in the same file, so the function should be static, and the
> prototype removed from drivers/video/omap2/dss/core.h.
>
> I'm also a bit skeptical about what this function does. It is called
> this way in venc_init():
>
> venc.vdda_dac_reg = dss_get_vdda_dac();
>
> so it is dss_get_vdda_dac() responsability to set venc.vdda_dac_reg, or
> is it the caller responsability ?
>
> Moreover, the logic in dss_get_vdda_dac() that tests whether
> venc.vdda_dac_reg is already initialized seems to indicate that this
> function could be called several times. However, I only see it called
> from venc_init(), which as far as I understand is called only once.
>
[Senthil] when code was in core.c there were chances of it getting called more than once. Now it is called only once as you see, so it could be made static.
> Isn't it possible to simplify this by removing the dss_get_vdda_dac()
> function and just doing:
>
> venc.vdda_dac_reg = regulator_get(&venc.pdev->dev, "vdda_dac");
>
> in the venc_init() function (which should become the ->probe() method).
>
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
^ permalink raw reply
* [Bug 30693] [R600c KWin 4.5.2] Blur does not work with RV670 (it works with RV710)
From: bugzilla-daemon @ 2010-10-08 7:10 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-30693-502@http.bugs.freedesktop.org/>
https://bugs.freedesktop.org/show_bug.cgi?id=30693
--- Comment #3 from darkbasic <darkbasic4@gmail.com> 2010-10-08 00:10:45 PDT ---
As I said latest snapshot, so mesa 7.10-devel.
The screenshot shows what I see instead of the blur effect: the window becomes
dark gray.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
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.