'
fi
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: linux-media@vger.kernel.org
---
drivers/media/dvb/bt8xx/dst_ca.c |7 ---
drivers/media/video/cx88/cx88-blackbird.c | 13 +++--
drivers/media/video/dabusb.c
AB-BA deadlock.
Please apply to the respective maintainer trees
if the patches look good.
Arnd Bergmann (12):
staging: autoconvert trivial BKL users to private mutex
isdn: autoconvert trivial BKL users to private mutex
scsi: autoconvert trivial BKL users to private mutex
media: autoconvert
The bt8xx driver only uses the big kernel lock in its dst_ca_ioctl
function and never to serialize against other code, so we can
trivially replace it with a private mutex.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: linux-media@vger.kernel.org
Cc: Mauro Carvalho Chehab mche...@infradead.org
The big kernel lock is gone from almost all code in linux-next, this is
the status of what I think will happen to the remaining users:
drivers/gpu/drm/i810/{i810,i830}_dma.c:
Fixable, but needs someone with the hardware to test. Can probably be
marked CONFIG_BROKEN_ON_SMP if
On Thursday 16 September 2010, Anton Altaparmakov wrote:
On 16 Sep 2010, at 16:04, Jan Kara wrote:
On Thu 16-09-10 16:32:59, Arnd Bergmann wrote:
The big kernel lock is gone from almost all code in linux-next, this is
the status of what I think will happen to the remaining users:
...
fs
On Friday 17 September 2010, Christoph Hellwig wrote:
On Fri, Sep 17, 2010 at 12:45:41PM +0200, Arnd Bergmann wrote:
ncpfs: replace BKL with lock_super
Err, no. lock_super is just as much on it's way out as the BKL. We've
managed to move it down from the VFS into a few remaining
On Friday 17 September 2010, Christoph Hellwig wrote:
Just add a per-sb mutex inside the filesystem. Given that lock_super
isn't used by the VFS anymore that's actually equivalent.
Ok, thanks for the hint. I'll fix that for isofs.
Arnd
--
To unsubscribe from this list: send the line
.
Ok, I queued up this patch now. Thanks!
Arnd
---
Subject: [PATCH] blktrace: remove the big kernel lock
According to Jens, this code does not need the BKL at all,
it is sufficiently serialized by bd_mutex.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Jens Axboe jax...@fusionio.com
Cc
On Saturday 18 September 2010 01:21:41 Petr Vandrovec wrote:
I'll try to come up with something for ncpfs.
Ok, good.
Trivial lock replacement will open deadlock possibility when
someone reads to page which is also mmaped from the same
filesystem (like grep likes to do). BKL with its
The dabusb device driver is sufficiently serialized using
its own mutex, no need for the big kernel lock here
in addition.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Mauro Carvalho Chehab mche...@infradead.org
---
Hi Mauro,
I just realized that the dabusb driver is not actually a v4l
there indefinitely.
On Thursday 16 September 2010, Arnd Bergmann wrote:
The big kernel lock is gone from almost all code in linux-next, this is
the status of what I think will happen to the remaining users:
drivers/gpu/drm/i810/{i810,i830}_dma.c:
Fixable, but needs someone with the hardware
On Monday 18 October 2010 18:19:24 Christoph Hellwig wrote:
Before we get into all these fringe drivers:
- I've not seen any progrss on -get_sb BKL removal for a while
Not sure what you mean. Jan Blunck did the pushdown into get_sb
last year, which is included into linux-next through my
On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
I might be able to find some hardware still lying around here that uses an
i810. Not sure unless I go hunting it. But I get the impression that if
the kernel is a single-CPU kernel there is not any problem anyway? Don't
distros offer a
On Tuesday 19 October 2010, Arnd Bergmann wrote:
On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
I might be able to find some hardware still lying around here that uses an
i810. Not sure unless I go hunting it. But I get the impression that if
the kernel is a single-CPU kernel
to lock_kernel in it.
If you own an Acorp 6A815EPD mainboard with a i815 chipset and
two Pentium-III sockets, and want to run recent kernels on it,
tell me about it.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index b755301
On Wednesday 20 October 2010, Dave Young wrote:
be curious, why can't just fix the lock_kernel logic of i810? Fixing
is too hard?
Find a i810 hardware should be possible, even if the hardware does not
support SMP, can't we test the fix with preemption?
Yes, that should work too. My usual
On Wednesday 10 November 2010, Jimmy Rubin wrote:
This patch adds support for MCDE, Memory-to-display controller
found in the ST-Ericsson ux500 products.
This patch adds the configuration registers found in MCDE.
+
+#define MCDE_VAL2REG(__reg, __fld, __val) \
+ (((__val)
On Wednesday 10 November 2010, Jimmy Rubin wrote:
This patch adds support for MCDE, Memory-to-display controller
found in the ST-Ericsson ux500 products.
Hi Jimmy,
I haven't looked at what this device does, but I've tried to do
a review based on coding style and common practices. I hope this
On Wednesday 10 November 2010, Jimmy Rubin wrote:
This patch adds support for MCDE, Memory-to-display controller
found in the ST-Ericsson ux500 products.
This patch adds pixel processing registers found in MCDE.
Signed-off-by: Jimmy Rubin jimmy.ru...@stericsson.com
Acked-by: Linus Walleij
On Wednesday 10 November 2010, Jimmy Rubin wrote:
+
+ if (ddev-id == PRIMARY_DISPLAY_ID rotate_main) {
+ swap(width, height);
+#ifdef CONFIG_DISPLAY_GENERIC_DSI_PRIMARY_ROTATE_180_DEGREES
+ rotate = FB_ROTATE_CCW;
+#else
+ rotate = FB_ROTATE_CW;
On Wednesday 10 November 2010, Jimmy Rubin wrote:
This patch adds support for the MCDE, Memory-to-display controller,
found in the ST-Ericsson ux500 products.
This patch adds the necessary build files for MCDE and the bus that
all displays are connected to.
Can you explain why you need a
On Wednesday 10 November 2010, Jimmy Rubin wrote:
+
+static struct platform_device mcde_fb_device = {
+ .name = mcde_fb,
+ .id = -1,
+};
Do not introduce new static devices. We are trying to remove them and
they will stop working. Why do you even need a device here if there is
only
On Wednesday 10 November 2010, Jimmy Rubin wrote:
This patch adds support for the MCDE, Memory-to-display controller,
found in the ST-Ericsson ux500 products.
This patch adds a display subsystem framework that can be used
by a frame buffer device driver to control a display and MCDE.
Like
On Sunday 14 November 2010, Hans Verkuil wrote:
This patch series converts 24 v4l drivers to unlocked_ioctl. These are low
hanging fruit but you have to start somewhere :-)
The first patch replaces mutex_lock in the V4L2 core by
mutex_lock_interruptible
for most fops.
The patches all look
On Sunday 14 November 2010 23:48:51 Hans Verkuil wrote:
On Sunday, November 14, 2010 22:53:29 Arnd Bergmann wrote:
On Sunday 14 November 2010, Hans Verkuil wrote:
This patch series converts 24 v4l drivers to unlocked_ioctl. These are low
hanging fruit but you have to start somewhere
On Friday 12 November 2010, Russell King - ARM Linux wrote:
On Fri, Nov 12, 2010 at 04:14:51PM +0100, Arnd Bergmann wrote:
Some people prefer to express all this in C instead of macros:
struct mcde_registers {
enum {
mcde_cr_dsicmd2_en = 0x0001
On Tuesday 16 November 2010, Hans Verkuil wrote:
A pointer to this struct is available in vdev-v4l2_dev. However, not all
drivers implement struct v4l2_device. But on the other hand, most relevant
drivers do. So as a fallback we would still need a static mutex.
Wouldn't that suffer the same
On Tuesday 16 November 2010, Hans Verkuil wrote:
I think there is a misunderstanding. One V4L device (e.g. a TV capture
card, a webcam, etc.) has one v4l2_device struct. But it can have multiple
V4L device nodes (/dev/video0, /dev/radio0, etc.), each represented by a
struct video_device
On Tuesday 16 November 2010, Jimmy RUBIN wrote:
Even static variables like these can cause problems. Ideally all of
these
are referenced through a driver private data structure that is passed
around
with the device. This way you can trivially support multiple devices if
that ever
sent out too early...
On Tuesday 16 November 2010, Arnd Bergmann wrote:
This looks a bit like you actually have multiple interrupt lines
multiplexed
through a private interrupt controller. Have you considered making this
controller
a separate device to multiplex the interrupt
, but didn't bring it up because I considered
it too hacky.
The patch you posted looks good, thanks for bringing up the problem with
my patch and the solution!
Acked-by: Arnd Bergmann a...@arndb.de
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message
. This is a
temporary measure only until we can convert all v4l drivers to use
unlocked_ioctl.
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Acked-by: Arnd Bergmann a...@arndb.de
---
drivers/media/video/v4l2-dev.c| 37
++---
drivers/media/video/v4l2-device.c
On Tuesday 16 November 2010 22:55:32 Hans Verkuil wrote:
Where reasonable use mutex_lock_interruptible instead of mutex_lock.
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Acked-by: Arnd Bergmann a...@arndb.de
--
To unsubscribe from this list: send the line unsubscribe linux-media
because they access
global data, which is unlikely but possible.
Signed-off-by: Arnd Bergmann a...@arndb.de
diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
index 03f7f46..5873d12 100644
--- a/drivers/media/video/v4l2-dev.c
+++ b/drivers/media/video/v4l2-dev.c
On Thursday 25 November 2010, Jimmy RUBIN wrote:
All these header files,
Configuration, pixel processing, formatter, dsi link registers are auto
generated from an xml file.
This actually may or may not be a legal problem, because it means that the
distributed source code is not the
On Thursday 25 November 2010, Marcus LORENTZON wrote:
From: Arnd Bergmann [mailto:a...@arndb.de]
On Wednesday 10 November 2010, Jimmy Rubin wrote:
This patch adds support for the MCDE, Memory-to-display controller,
found in the ST-Ericsson ux500 products.
This patch adds
[dri people: please have a look at the KMS discussion way below]
On Thursday 25 November 2010 19:00:26 Marcus LORENTZON wrote:
-Original Message-
From: Arnd Bergmann [mailto:a...@arndb.de]
Sent: den 25 november 2010 17:48
To: Marcus LORENTZON
Cc: linux-arm-ker
On Tuesday 30 November 2010, Linus Walleij wrote:
2010/11/26 Arnd Bergmann a...@arndb.de:
* When you say that the devices are static, I hope you do not mean
static in the C language sense. We used to allow devices to be
declared as static struct and registered using
On Wednesday 01 December 2010, Russell King - ARM Linux wrote:
Right, so saying to ARM developers that they can't submit code which
adds new static device structures is rather problematical then, and
effectively brings a section of kernel development to a complete
standstill - it means no
On Tuesday 21 December 2010 02:18:06 Thiago Farina wrote:
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c
index e30e8df..55825ec 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@
On Tuesday 21 December 2010 19:34:04 Thiago Farina wrote:
You can probably change this function to look at the return code of
copy_to_user, but then you need to treat the put_user return code
the same, and change the comment.
Right, I will do the same with put_user, but I'm afraid of
On Wednesday 22 December 2010 15:14:49 Andreas Oberritter wrote:
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c
index e30e8df..6f2a022 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++
On Tuesday 16 August 2011, Marek Szyprowski wrote:
On Friday, August 12, 2011 5:01 PM Arnd Bergmann wrote:
How about something like
if (arch_is_coherent() || nommu())
ret = alloc_simple_buffer();
else if (arch_is_v4_v5())
ret = alloc_remap
On Sunday 14 August 2011, Russell King - ARM Linux wrote:
On Fri, Aug 12, 2011 at 02:53:05PM +0200, Arnd Bergmann wrote:
I thought that our discussion ended with the plan to use this only
for ARMv6+ (which has a problem with double mapping) but not on ARMv5
and below (which don't have
On Tuesday 16 August 2011, Russell King - ARM Linux wrote:
On Tue, Aug 16, 2011 at 03:28:48PM +0200, Arnd Bergmann wrote:
Hmm, I don't remember the point about dynamically sizing the pool for
ARMv6K, but that can well be an oversight on my part. I do remember the
part about taking
On Wednesday 17 August 2011, Marek Szyprowski wrote:
Do we really need the dynamic pool for the first version? I would like to
know how much memory can be allocated in GFP_ATOMIC context. What are the
typical sizes of such allocations?
I think this highly depends on the board and on the use
Hi Tomi,
Apparently your patch 8cff88c5d OMAP: DSS2: remove update_mode from omapdss
broke building the omap_vout driver:
/home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c: In function
'omap_vout_probe':
/home/arnd/linux-arm/drivers/media/video/omap/omap_vout.c:2202:15: error:
'struct
MISC_DEVICES.
Signed-off-by: Arnd Bergmann a...@arndb.de
---
arch/arm/mach-davinci/Kconfig |6 --
arch/unicore32/Kconfig|1 -
drivers/misc/Kconfig | 26 --
drivers/mmc/host/Kconfig |1 -
4 files changed, 8 insertions(+), 26 deletions
MFD_SUPPORT is disabled. Turning the MFD submenu
back from menuconfig into a plain menu simplifies the Kconfig syntax
for those kinds of users and avoids the surprise when the menu
suddenly appears because another driver was enabled that selects this
symbol.
Signed-off-by: Arnd Bergmann
On Friday 02 September 2011, Jean Delvare wrote:
Doing this is a good idea, but incidentally I have just spent some time
with the same problem and ended up with a solution that I like better,
which is removing CONFIG_MFD_SUPPORT altogether.
The point is that there is no use enabling
On Monday 05 September 2011, Jean Delvare wrote:
As said before, I'm not sure. Yes, it makes it easier to select misc
device drivers from Kconfig files. But it also makes it impossible to
deselect all misc device drivers at once.
I think that what we really need is the implementation in the
On Sunday 18 September 2011 11:45:16 Randy Dunlap wrote:
We have fallbacks to Andrew and/or GregKH currently, but GregKH is not
consistent or timely with applying drivers/misc/ patches. It deserves
better.
[added him to Cc: list]
I do try to handle patches sent to me for misc/ in
On Thursday 15 September 2011, Grant Likely wrote:
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 21574bd..1836cdf 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -2,10 +2,9 @@
# Multifunction miscellaneous devices
#
-menuconfig MFD_SUPPORT
-
On Monday 19 September 2011, Greg KH wrote:
That sounds good to me, I'll be glad to collect the patches and push
them to Linus for both of those trees (might as well keep them in the
same git tree, no need to separate them, right?) and I'll rely on you
for review and acking them. Much like I
On Thursday 06 October 2011, Marek Szyprowski wrote:
Once again I decided to post an updated version of the Contiguous Memory
Allocator patches.
This version provides mainly a bugfix for a very rare issue that might
have changed migration type of the CMA page blocks resulting in dropping
On Tuesday 11 October 2011, Andrew Morton wrote:
Russell's going to hate me, but...
I do know that he had substantial objections to at least earlier
versions of this, and he is a guy who knows of what he speaks.
So I would want to get a nod from rmk on this work before proceeding.
If
On Saturday 15 October 2011, Andrew Morton wrote:
On Tue, 11 Oct 2011 15:52:04 +0200
Arnd Bergmann a...@arndb.de wrote:
What I would really want to hear from you is your opinion on
the architecture independent stuff. Obviously, ARM is the
most important consumer of the patch set, but I
On Saturday 26 February 2011, Edward Hervey wrote:
Are there any gstreamer/linaro/etc core developers attending the ELC in San
Francisco
in April? I think it might be useful to get together before, during or
after the
conference and see if we can turn this discussion in something
On Friday 04 March 2011, Marek Szyprowski wrote:
From: Andrzej Pietrasiewicz andrze...@samsung.com
This patch performs a complete rewrite of sysmmu driver for Samsung platform:
- the new version introduces an api to construct device private page
tables and enables to use device private
On Friday 11 March 2011, Marek Szyprowski wrote:
We followed the style of iommu API for other mainline ARM platforms (both
OMAP and MSM
also have custom API for their iommu modules). I've briefly checked
include/linux/iommu.h
API and I've noticed that it has been designed mainly for KVM
On Friday 11 March 2011, Marek Szyprowski wrote:
does not support IOMMUs, but that could be changed by wrapping it
using the include/asm-generic/dma-mapping-common.h infrastructure.
ARM dma-mapping framework also requires some additional research for
better DMA
support (there
On Monday 14 March 2011, KyongHo Cho wrote:
I think we can consider another solution for the various requirements.
I think one of the most possible solutions is VCMM.
Or we can enhance include/linux/iommu.h with reference of VCMM.
I think extending or changing the existing interface would be
introduced which gets initialized during
the initialization of each relevant SoC
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
The change looks good, it's definitely a step in the right
direction.
Acked-by: Arnd Bergmann a...@arndb.de
I think you can go even further:
* A straightforward
On Tuesday 15 March 2011 07:00:44 Nori, Sekhar wrote:
* If you need to access sysmod in multiple places, a nicer
way would be to make the virtual address pointer static,
and export the accessor functions for it, rather than
having a global pointer.
Seems like opinion is divided
On Tuesday 22 March 2011, Nori, Sekhar wrote:
.. but forgot to fix this. There is nothing wrong with
using writel, but it doesn't fit into what the subject
of this patch is.
Well, to be more exact, the __raw_writel was actually
wrong here and it should be writel(), but it's certainly
better to
On Monday 18 April 2011, Marek Szyprowski wrote:
From: Andrzej Pietrasiewicz andrze...@samsung.com
This patch performs a complete rewrite of sysmmu driver for Samsung platform:
- simplified the resource management: no more single platform
device with 32 resources is needed, better fits
On Monday 18 April 2011, Marek Szyprowski wrote:
From: Andrzej Pietrasiewicz andrze...@samsung.com
This patch adds new videobuf2 memory allocator dedicated to devices that
supports IOMMU DMA mappings. A device with IOMMU module and a driver
with include/iommu.h compatible interface is
On Tuesday 19 April 2011, Russell King - ARM Linux wrote:
On Tue, Apr 19, 2011 at 11:02:34AM +0200, Marek Szyprowski wrote:
On Monday, April 18, 2011 4:16 PM Arnd Bergmann wrote:
My feeling is that this is not the right abstraction. Why can't you
just implement the regular dma-mapping.h
(adding Joerg to Cc)
On Tuesday 19 April 2011, Marek Szyprowski wrote:
These look wrong for a number of reasons:
* try_module_get(THIS_MODULE) makes no sense at all, the idea of the
try_module_get is to pin down another module that was calling down,
which I suppose is not needed
On Tuesday 19 April 2011, Roedel, Joerg wrote:
On Tue, Apr 19, 2011 at 08:49:50AM -0400, Arnd Bergmann wrote:
Ok, it looks I don't fully get how this iommu.h should be used. It looks
that there can be only one instance of iommu ops registered in the system,
so only one iommu driver can
On Tuesday 19 April 2011, Marek Szyprowski wrote:
1. change the runtime_pm subsystem to allow it to ignore some devices
in an easy way.
2. change the device layout if the sysmmu. If the iommu device is
a child of the device that it is responsible for, I guess you don't
have this
On Tuesday 19 April 2011, Roedel, Joerg wrote:
Getting back to our video codec - it has 2 IOMMU controllers. The codec
hardware is able to address only 256MiB of space. Do you have an idea how
this can be handled with dma-mapping API? The only idea that comes to my
mind is to provide a
On Wednesday 20 April 2011, Marek Szyprowski wrote:
On Tuesday, April 19, 2011 4:30 PM Arnd Bergmann wrote:
Sounds good. I think we should put it into a new drivers/iommu, along
with your specific iommu implementation, and then we can convert the
existing ones over to use that.
I see
On Thursday 21 April 2011, Marek Szyprowski wrote:
On Wednesday, April 20, 2011 6:07 PM Arnd Bergmann wrote:
On Wednesday 20 April 2011, Marek Szyprowski wrote:
The only question is how a device can allocate a buffer that will be most
convenient for IOMMU mapping (i.e. will require least
On Thursday 21 April 2011, Marek Szyprowski wrote:
No, I think that would be much worse, it definitely destroys all kinds of
assumptions that the core code makes about devices. However, I don't think
it's much of a problem to just create two child devices and use them
from the main driver,
On Friday 22 April 2011, Marek Szyprowski wrote:
* Create two codec devices in parallel and bind to both with your
driver, ideally splitting up the resources between the two
devices in a meaningful way.
Video codec has only standard 2 resources - ioregs and irq, so there
is not much
On Thursday 12 May 2011, Josh Wu wrote:
This patch is to enable Atmel Image Sensor Interface (ISI) driver support.
- Using soc-camera framework with videobuf2 dma-contig allocator
- Supporting video streaming of YUV packed format
- Tested on AT91SAM9M10G45-EK with OV2640
Signed-off-by: Josh
On Thursday 26 May 2011, Laurent Pinchart wrote:
On Thursday 26 May 2011 01:50:07 Mauro Carvalho Chehab wrote:
Em 25-05-2011 20:43, Laurent Pinchart escreveu:
Issues arise when devices have floating point registers. And yes, that
happens, I've learnt today about an I2C sensor with
On Thursday 26 May 2011, Sakari Ailus wrote:
I strongly favour GStreamer below OpenMAX rather than V4L2. Naturally the
GStreamer source plugins do use V4L2 where applicable.
Interesting point, yes. Note that this is probably the opposite of
what David had in mind when talking about GStreamer
Wu josh...@atmel.com
Looks good to me now.
Acked-by: Arnd Bergmann a...@arndb.de
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 03 June 2011, Ohad Ben-Cohen wrote:
First stab at iommu consolidation:
Hi Ohad,
Great to see your progress here!
- Migrate OMAP's iommu driver to the generic iommu API. With this in hand,
users can now start using the generic iommu layer instead of calling
omap-specific iommu
On Sunday 05 June 2011, Ohad Ben-Cohen wrote:
As far as I can tell, once we have that in
place, we you can migrate omap3isp from iovmm to dma-mapping and
remove iovmm.
Sounds like a plan.
I'd still prefer us to take small steps here, and not gate the omap
iommu cleanups with Marek's
On Friday 10 June 2011, Marek Szyprowski wrote:
The Contiguous Memory Allocator is a set of functions that lets
one initialise a region of memory which then can be used to perform
allocations of contiguous memory chunks from.
CMA allows for creation of separate contexts. Kernel is allowed to
On Monday 13 June 2011, Marek Szyprowski wrote:
cm_alloc/free are definitely not meant to be called from device drivers.
They should be only considered as a backend for dma-mapping.
'Raw' contiguous memory block doesn't really make sense for the device
drivers. What the drivers require is a
On Tuesday 14 June 2011, Michal Nazarewicz wrote:
On Tue, 14 Jun 2011 15:49:29 +0200, Arnd Bergmann a...@arndb.de wrote:
Please explain the exact requirements that lead you to defining multiple
contexts.
Some devices may have access only to some banks of memory. Some devices
may use
On Tuesday 14 June 2011 18:58:35 Michal Nazarewicz wrote:
On Tue, 14 Jun 2011 18:03:00 +0200, Arnd Bergmann wrote:
For all I know, that is something that is only true for a few very
special Samsung devices,
Maybe. I'm just answering your question. :)
Ah yes, I forgot that separate
On Tuesday 14 June 2011 20:58:25 Zach Pfeffer wrote:
I've seen this split bank allocation in Qualcomm and TI SoCs, with
Samsung, that makes 3 major SoC vendors (I would be surprised if
Nvidia didn't also need to do this) - so I think some configurable
method to control allocations is
On Wednesday 15 June 2011 09:11:39 Marek Szyprowski wrote:
I see your concerns, but I really wonder how to determine the properties
of the global/default cma pool. You definitely don't want to give all
available memory o CMA, because it will have negative impact on kernel
operation (kernel
On Wednesday 15 June 2011, Marek Szyprowski wrote:
If possible I would like to make cma something similar to
declare_dma_coherent()friends, so the board/platform/bus startup code
will just call declare_dma_contiguous() to enable support for cma for
particular devices.
Sounds
On Wednesday 15 June 2011, Michal Nazarewicz wrote:
On Tue, 14 Jun 2011 22:42:24 +0200, Arnd Bergmann a...@arndb.de wrote:
* We still need to solve the same problem in case of IOMMU mappings
at some point, even if today's hardware doesn't have this combination.
It would be good to use
On Tuesday 14 June 2011, Jordan Crouse wrote:
On 06/14/2011 02:42 PM, Arnd Bergmann wrote:
On Tuesday 14 June 2011 20:58:25 Zach Pfeffer wrote:
I've seen this split bank allocation in Qualcomm and TI SoCs, with
Samsung, that makes 3 major SoC vendors (I would be surprised if
Nvidia
On Wednesday 15 June 2011 23:39:58 Larry Bassel wrote:
On 15 Jun 11 10:36, Marek Szyprowski wrote:
On Tuesday, June 14, 2011 10:42 PM Arnd Bergmann wrote:
On Tuesday 14 June 2011 20:58:25 Zach Pfeffer wrote:
I've seen this split bank allocation in Qualcomm and TI SoCs
On Thursday 16 June 2011 02:48:12 Philip Balister wrote:
On 06/15/2011 12:37 AM, Arnd Bergmann wrote:
On Wednesday 15 June 2011 09:11:39 Marek Szyprowski wrote:
I see your concerns, but I really wonder how to determine the properties
of the global/default cma pool. You definitely don't want
On Thursday 16 June 2011 19:01:33 Larry Bassel wrote:
Can you describe how the memory areas differ specifically?
Is there one that is always faster but very small, or are there
just specific circumstances under which some memory is faster than
another?
One is always faster, but very
On Wednesday 15 June 2011, Daniel Vetter wrote:
On Tue, Jun 14, 2011 at 20:30, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 14 June 2011 18:58:35 Michal Nazarewicz wrote:
Ah yes, I forgot that separate regions for different purposes could
decrease fragmentation.
That is indeed a good
On Wednesday 22 June 2011, Hans Verkuil wrote:
How about a Kconfig option that defines the percentage of memory
to set aside for contiguous allocations?
I would actually like to see a cma_size kernel option of some sort. This would
be for the global CMA pool only as I don't think we should
On Wednesday 22 June 2011, Marek Szyprowski wrote:
Sounds really good, but it might be really hard to implemnt, at least for
CMA, because it needs to tweak parameters of memory management internal
structures very early, when buddy allocator has not been activated yet.
Why that? I would expect
On Thursday 23 June 2011 16:47:50 Ralf Baechle wrote:
Fixed by adding an explicit dependency on ISA_DMA_API for all of the
config statment that either result in the direction inclusion of code that
calls the ISA DMA API or selects something which in turn would use the ISA
DMA API.
The sole
On Thursday 23 June 2011 19:22:06 Prarit Bhargava wrote:
This new patchset reworks the existing DMI code into two separate layers. It
is
based off of the feedback I received previously when discussing the SMBIOS
version patch on LKML.
Hi Prarit,
No objections to the patches, but when you
to catch functions returning -ENOIOCTLCMD.
Good catch!
At the recent git history, the return for -ENOIOCTLCMD were modified
by this changeset:
commit b19dd42faf413b4705d4adb38521e82d73fa4249
Author: Arnd Bergmann a...@arndb.de
Date: Sun Jul 4 00:15:10 2010 +0200
bkl: Remove
1 - 100 of 748 matches
Mail list logo
