On Mon, Aug 02, 2010 at 12:32:20PM +0200, Pawel Osciak wrote:
Well, some of them are indeed unused, but it's not an uncommon practice in
kernel and might help future developers.
On the other hand, arch/arm is getting soo big that we need to do
something about this - and one solution is to avoid
On Mon, Aug 02, 2010 at 08:51:06AM -0300, Mauro Carvalho Chehab wrote:
Em 02-08-2010 07:52, Russell King - ARM Linux escreveu:
On Mon, Aug 02, 2010 at 12:32:20PM +0200, Pawel Osciak wrote:
Well, some of them are indeed unused, but it's not an uncommon practice in
kernel and might help
On Mon, Aug 02, 2010 at 02:08:42PM +0200, Pawel Osciak wrote:
Russell King - ARM Linux li...@arm.linux.org.uk wrote:
On Mon, Aug 02, 2010 at 12:32:20PM +0200, Pawel Osciak wrote:
Well, some of them are indeed unused, but it's not an uncommon practice in
kernel and might help future
On Thu, Aug 26, 2010 at 06:51:48PM +0900, FUJITA Tomonori wrote:
On Thu, 26 Aug 2010 11:45:58 +0200 (CEST)
Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
On Thu, 26 Aug 2010, FUJITA Tomonori wrote:
Why can't you revert a commit that causes the regression?
See this reply, and
On Thu, Aug 26, 2010 at 07:00:24PM +0900, FUJITA Tomonori wrote:
On Thu, 26 Aug 2010 11:53:11 +0200
Uwe Kleine-König u.kleine-koe...@pengutronix.de wrote:
We have currently a number of boards broken in the mainline. They must
be
fixed for 2.6.36. I don't think the mentioned API
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,
mcde_cr_dsicmd1_en = 0x0002,
...
} cr;
On Mon, Nov 15, 2010 at 03:25:54PM +0100, Arnd Bergmann wrote:
On Friday 12 November 2010, Russell King - ARM Linux wrote:
It is a bad idea to describe device registers using C structures, and
especially enums.
The only thing C guarantees about structure layout is that the elements
On Tue, Nov 30, 2010 at 04:21:47PM +0100, Arnd Bergmann wrote:
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
On Tue, Nov 30, 2010 at 10:48:34AM -0800, Greg KH wrote:
On Tue, Nov 30, 2010 at 06:40:49PM +, Russell King - ARM Linux wrote:
There's lots of static devices, not only platform devices, in the ARM
tree. It's going to be a hell of a lot of work to fix this all up
properly.
I agree
On Tue, Nov 30, 2010 at 03:05:33PM -0800, Greg KH wrote:
On Tue, Nov 30, 2010 at 10:05:50PM +, Russell King - ARM Linux wrote:
On Tue, Nov 30, 2010 at 10:48:34AM -0800, Greg KH wrote:
On Tue, Nov 30, 2010 at 06:40:49PM +, Russell King - ARM Linux wrote:
There's lots of static
On Wed, Dec 01, 2010 at 01:53:39PM +0100, Peter Stuge wrote:
Russell King - ARM Linux wrote:
I feel it would be better to allow the current situation to continue.
I think this misses the point, and is somewhat redundant; I think
everyone knows that it is easiest to never change anything
On Fri, Dec 10, 2010 at 12:03:07PM +0100, Janusz Krzysztofik wrote:
void __init omap1_camera_init(void *info)
{
struct platform_device *dev = omap1_camera_device;
+ dma_addr_t paddr = omap1_camera_phys_mempool_base;
+ dma_addr_t size = omap1_camera_phys_mempool_size;
On Mon, Dec 13, 2010 at 03:52:20PM +, Catalin Marinas wrote:
On 10 December 2010 17:03, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Dec 10, 2010 at 12:03:07PM +0100, Janusz Krzysztofik wrote:
void __init omap1_camera_init(void *info)
{
struct
On Wed, Dec 15, 2010 at 12:39:20PM +, Catalin Marinas wrote:
On 13 December 2010 16:29, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Dec 13, 2010 at 03:52:20PM +, Catalin Marinas wrote:
On 10 December 2010 17:03, Russell King - ARM Linux
li...@arm.linux.org.uk
On Thu, Dec 23, 2010 at 06:30:57PM +0900, Kyungmin Park wrote:
Hi Andrew,
any comments? what's the next step to merge it for 2.6.38 kernel. we
want to use this feature at mainline kernel.
Has anyone addressed my issue with it that this is wide-open for
abuse by allocating large chunks of
On Thu, Dec 23, 2010 at 11:58:08AM +0100, Marek Szyprowski wrote:
Actually this contiguous memory allocator is a better replacement for
alloc_pages() which is used by dma_alloc_coherent(). It is a generic
framework that is not tied only to ARM architecture.
... which is open to abuse. What
On Thu, Dec 23, 2010 at 02:35:00PM +0100, Tomasz Fujak wrote:
Dear Mr. King,
AFAIK the CMA is the fourth attempt since 2008 taken to solve the
multimedia memory allocation issue on some embedded devices. Most
notably on ARM, that happens to be present in the SoCs we care about
along the
On Thu, Dec 23, 2010 at 02:41:26PM +0100, Michal Nazarewicz wrote:
Russell King - ARM Linux li...@arm.linux.org.uk writes:
Has anyone addressed my issue with it that this is wide-open for
abuse by allocating large chunks of memory, and then remapping
them in some way with different
On Thu, Dec 23, 2010 at 03:04:07PM +0100, Tomasz Fujak wrote:
On 2010-12-23 14:48, Russell King - ARM Linux wrote:
On Thu, Dec 23, 2010 at 02:35:00PM +0100, Tomasz Fujak wrote:
Dear Mr. King,
AFAIK the CMA is the fourth attempt since 2008 taken to solve the
multimedia memory allocation
On Thu, Dec 23, 2010 at 03:08:21PM +0100, Tomasz Fujak wrote:
On 2010-12-23 14:51, Russell King - ARM Linux wrote:
On Thu, Dec 23, 2010 at 02:41:26PM +0100, Michal Nazarewicz wrote:
Russell King - ARM Linux li...@arm.linux.org.uk writes:
Has anyone addressed my issue
On Fri, Dec 24, 2010 at 12:20:32AM +0100, Janusz Krzysztofik wrote:
The patch tries to implement a solution suggested by Russell King,
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/035264.html.
It is expected to solve video buffer allocation issues for at least a
few
On Fri, Dec 24, 2010 at 12:20:32AM +0100, Janusz Krzysztofik wrote:
The patch tries to implement a solution suggested by Russell King,
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/035264.html.
It is expected to solve video buffer allocation issues for at least a
few
On Fri, Dec 24, 2010 at 02:55:25PM +0100, Janusz Krzysztofik wrote:
Friday 24 December 2010 14:02:00 Russell King - ARM Linux wrote:
On Fri, Dec 24, 2010 at 12:20:32AM +0100, Janusz Krzysztofik wrote:
The patch tries to implement a solution suggested by Russell King,
http
On Fri, Aug 12, 2011 at 02:53:05PM +0200, Arnd Bergmann wrote:
On Friday 12 August 2011, Marek Szyprowski wrote:
From: Russell King rmk+ker...@arm.linux.org.uk
Steal memory from the kernel to provide coherent DMA memory to drivers.
This avoids the problem with multiple mappings with
On Tue, Aug 16, 2011 at 03:28:48PM +0200, Arnd Bergmann wrote:
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
On Mon, Sep 05, 2011 at 06:29:53PM +0800, Josh Wu wrote:
+static int initialize_mck(struct atmel_isi *isi,
+ struct isi_platform_data *pdata)
+{
+ int ret;
+ struct clk *pck_parent;
+
+ if (!strlen(pdata-pck_name) || !strlen(pdata-pck_parent_name))
+
On Wed, Aug 03, 2011 at 12:43:50PM -0500, James Bottomley wrote:
I assume from the above that ARM has a hardware page walker?
Correct, and speculative prefetch (which isn't prevented by not having
TLB entries), so you can't keep entries out of the TLB. If it's in
the page tables it can end up
On Fri, Oct 14, 2011 at 04:57:30PM -0700, Andrew Morton wrote:
On Thu, 06 Oct 2011 15:54:46 +0200
Marek Szyprowski m.szyprow...@samsung.com wrote:
+#ifdef phys_to_pfn
+/* nothing to do */
+#elif defined __phys_to_pfn
+# define phys_to_pfn __phys_to_pfn
+#elif defined __va
+# define
On Tue, Nov 01, 2011 at 05:15:52PM -0500, Omar Ramirez Luna wrote:
Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations, reset and sysconfig
handling.
Tidspbridge uses a macro removed with this patch, for now the value
is hardcoded to
On Tue, Jan 04, 2011 at 05:23:37PM +0100, Johan MOSSBERG wrote:
Russell King wrote:
Has anyone addressed my issue with it that this is wide-open for
abuse by allocating large chunks of memory, and then remapping
them in some way with different attributes, thereby violating the
ARM
On Tue, Jan 18, 2011 at 11:32:16PM +0100, Martin Hostettler wrote:
+#include asm/gpio.h
Please use linux/gpio.h in future.
--
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
On Thu, Mar 10, 2011 at 03:14:11PM +0100, Marek Szyprowski wrote:
Hello,
On Tuesday, March 08, 2011 9:14 AM Hans Verkuil wrote:
We had a discussion yesterday regarding ways in which linaro can assist
V4L2 development. One topic was that of sorting out memory providers like
GEM and
On Mon, Mar 14, 2011 at 09:37:51PM +0900, KyongHo Cho wrote:
I have also noticed that dma_map_single/page/sg() can map physical
memory into an arbitrary device address region.
But it is not enough solution for various kinds of IOMMUs.
As Kukjin Kim addressed, we need to support larger page
On Tue, Mar 15, 2011 at 10:45:50AM +0900, InKi Dae wrote:
2011/3/14 Russell King - ARM Linux li...@arm.linux.org.uk:
On Mon, Mar 14, 2011 at 09:37:51PM +0900, KyongHo Cho wrote:
I have also noticed that dma_map_single/page/sg() can map physical
memory into an arbitrary device address region
On Tue, Mar 15, 2011 at 06:34:42PM +0900, daeinki wrote:
Russell King - ARM Linux 쓴 글:
On Tue, Mar 15, 2011 at 10:45:50AM +0900, InKi Dae wrote:
2011/3/14 Russell King - ARM Linux li...@arm.linux.org.uk:
On Mon, Mar 14, 2011 at 09:37:51PM +0900, KyongHo Cho wrote:
I have also noticed
On Sat, Apr 09, 2011 at 03:33:39AM +0200, Janusz Krzysztofik wrote:
Since there were no actual problems reported before, I suppose the old
code, which was passing to remap_pfn_range() a physical page number
calculated from dma_alloc_coherent() privided dma_handle, worked
correctly on all
On Tue, Apr 12, 2011 at 11:06:34PM +0200, Janusz Krzysztofik wrote:
The patch tries to solve this regression by using
virt_to_phys(bus_to_virt(mem-dma_handle)) instead of problematic
virt_to_phys(mem-vaddr).
Who says that DMA handles are bus addresses in the strictest sense?
DMA handles on
On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik wrote:
Taking into account that I'm just trying to fix a regression, and not
invent a new, long term solution: are you able to name an ARM based
board which a) is already supported in 2.6.39, b) is (or can be)
equipped with a
On Wed, Apr 13, 2011 at 10:56:39PM +0200, Janusz Krzysztofik wrote:
Dnia środa 13 kwiecień 2011 o 20:32:31 Russell King - ARM Linux
napisał(a):
On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik wrote:
Taking into account that I'm just trying to fix a regression
On Mon, Apr 18, 2011 at 10:20:49AM +0200, Robert Schwebel wrote:
Uwe,
On Mon, Apr 18, 2011 at 10:14:56AM +0200, Guennadi Liakhovetski wrote:
It's been pushed upstream almost 2 weeks ago:
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/31352
As our autobuilder
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 interfaces for your IOMMU
so that the videobuf code can use
On Thu, May 12, 2011 at 03:42:18PM +0800, Josh Wu wrote:
+err_alloc_isi:
+ clk_disable(pclk);
clk_put() ?
--
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
On Thu, May 12, 2011 at 03:42:18PM +0800, 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
A
On Tue, May 17, 2011 at 11:28:48AM +0200, Javier Martin wrote:
+#include devices.h
+#include ../../../drivers/media/video/omap3isp/isp.h
+#include ../../../drivers/media/video/omap3isp/ispreg.h
This suggests that there's something very wrong with what's going on;
it suggests that you're trying
On Tue, May 17, 2011 at 01:33:52PM +0200, Laurent Pinchart wrote:
Hi Javier,
Thanks for the patch.
Sorry, but this laziness is getting beyond a joke... And the fact that
apparantly no one is picking up on it other than me is also a joke.
+static int mt9p031_power_on(struct mt9p031
On Wed, Jun 08, 2011 at 11:53:49PM +0200, Janusz Krzysztofik wrote:
On Fri 10 Dec 2010 at 22:03:52 Janusz Krzysztofik wrote:
Friday 10 December 2010 18:03:56 Russell King - ARM Linux napisał(a):
On Fri, Dec 10, 2010 at 12:03:07PM +0100, Janusz Krzysztofik wrote:
void __init
On Tue, Jul 05, 2011 at 09:41:48AM +0200, Marek Szyprowski wrote:
The Contiguous Memory Allocator is a set of helper functions for DMA
mapping framework that improves allocations of contiguous memory chunks.
CMA grabs memory on system boot, marks it with CMA_MIGRATE_TYPE and
gives back to
On Tue, Jul 05, 2011 at 01:44:31PM +0200, Arnd Bergmann wrote:
@@ -198,6 +198,12 @@ config MIGRATION
pages as migration can relocate pages to satisfy a huge page
allocation instead of reclaiming.
+config CMA_MIGRATE_TYPE
+ bool
+ help
+ This enables the use
On Tue, Jul 05, 2011 at 02:07:17PM +0200, Arnd Bergmann wrote:
On Tuesday 05 July 2011, Marek Szyprowski wrote:
This is yet another round of Contiguous Memory Allocator patches. I hope
that I've managed to resolve all the items discussed during the Memory
Management summit at Linaro Meeting
On Tue, Jul 05, 2011 at 02:27:44PM +0200, Arnd Bergmann wrote:
It's also a preexisting problem as far as I can tell, and it needs
to be solved in __dma_alloc for both cases, dma_alloc_from_contiguous
and __alloc_system_pages as introduced in patch 7.
Which is now resolved in linux-next, and
On Wed, Jul 06, 2011 at 04:09:29PM +0200, Arnd Bergmann wrote:
Maybe you can simply adapt the default location of the contiguous memory
are like this:
- make CONFIG_CMA depend on CONFIG_HIGHMEM on ARM, at compile time
- if ZONE_HIGHMEM exist during boot, put the CMA area in there
- otherwise,
On Wed, Jul 06, 2011 at 04:56:23PM +0200, Marek Szyprowski wrote:
This will not solve our problems. We need CMA also to create at least one
device private area that for sure will be in low memory (video codec).
You make these statements but you don't say why. Can you please
explain why the
On Wed, Jul 06, 2011 at 04:51:49PM +0200, Arnd Bergmann wrote:
On Wednesday 06 July 2011, Russell King - ARM Linux wrote:
On Wed, Jul 06, 2011 at 04:09:29PM +0200, Arnd Bergmann wrote:
Maybe you can simply adapt the default location of the contiguous memory
are like this:
- make
On Wed, Jul 06, 2011 at 11:05:00AM -0500, Christoph Lameter wrote:
On Wed, 6 Jul 2011, Russell King - ARM Linux wrote:
they typically don't fall into the highmem zone. As the dmabounce
code allocates from the DMA coherent allocator to provide it with
guaranteed DMA-able memory
On Wed, Jul 06, 2011 at 11:19:00AM -0500, Christoph Lameter wrote:
What I described is the basic memory architecture of Linux. I am not that
familiar with ARM and the issue discussed here. Only got involved because
ZONE_DMA was mentioned. The nature of ZONE_DMA is often misunderstood.
The
On Tue, Jul 05, 2011 at 03:58:39PM +0200, Arnd Bergmann wrote:
Ah, sorry I missed that patch on the mailing list, found it now in
your for-next branch.
I've been searching for this email to reply to for the last day or
so...
If I'm reading your ARM: DMA: steal memory for DMA coherent mappings
On Fri, Mar 27, 2009 at 08:33:27AM +0100, Holger Schurig wrote:
Sparse is another tool which can be used while building the
kernel to increase the build time checking, but it can be
quite noisy, so please only look at stuff which pops up for
your specific area.
To get rid of some of the
On Fri, Mar 27, 2009 at 05:18:18PM +0200, Darius Augulis wrote:
You use an FIQ for SoF, and spin_lock_irqsave() to protect. Don't they
only disable IRQs and not FIQs? But it seems your FIQ cannot cause any
trouble, so, it should be fine. Do you really need an FIQ?
This is precisely the
On Tue, May 12, 2009 at 11:31:14AM -0700, Dan Williams wrote:
On Tue, May 12, 2009 at 5:14 AM, Agustin gatoguan...@yahoo.com wrote:
On Tue, 12 May 2009, Guennadi Liakhovetski wrote:
This also fixes the case of a single queued buffer, for example, when
taking a
single frame snapshot
On Sat, May 16, 2009 at 08:22:18PM +0200, Guennadi Liakhovetski wrote:
On Sat, 16 May 2009, Russell King - ARM Linux wrote:
On Tue, May 12, 2009 at 11:31:14AM -0700, Dan Williams wrote:
On Tue, May 12, 2009 at 5:14 AM, Agustin gatoguan...@yahoo.com wrote:
On Tue, 12 May 2009
On Wed, Feb 18, 2009 at 07:09:55AM -0800, Agustin wrote:
Guennadi,
Guennadi Liakhovetski wrote:
diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
index 1f154d0..91e6e4e 100644
--- a/drivers/dma/ipu/ipu_idmac.c
+++ b/drivers/dma/ipu/ipu_idmac.c
@@ -28,6 +28,9 @@
On Fri, Feb 03, 2012 at 09:37:48AM +0100, javier Martin wrote:
I've introduced a couple of printk() to check why this timeout is not
triggered and I've found that the value of jiffies does not increase
between loop iterations (i. e. it's like time didn't advance).
Does anyobody know what
On Fri, Feb 03, 2012 at 10:22:00AM +0100, javier Martin wrote:
Hi Russell,
On 3 February 2012 10:10, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Feb 03, 2012 at 09:37:48AM +0100, javier Martin wrote:
I've introduced a couple of printk() to check why this timeout
On Tue, Feb 21, 2012 at 04:18:02PM -0800, Andrew Morton wrote:
After a while I got it to compile for i386. arm didn't go so well,
partly because arm allmodconfig is presently horked (something to do
with Kconfig not setting PHYS_OFFSET) and partly because arm defconfig
doesn't permit CMA to
On Wed, Apr 17, 2013 at 04:17:18PM +0100, Pawel Moll wrote:
+#if defined(CONFIG_OF)
+static int clcdfb_of_get_tft_parallel_panel(struct clcd_panel *panel,
+ struct display_entity_interface_params *params)
+{
+ int r = params-p.tft_parallel.r_bits;
+ int g =
On Thu, Apr 18, 2013 at 06:33:21PM +0100, Pawel Moll wrote:
This patch adds basic DT bindings for the PL11x CLCD cells
and make their fbdev driver use them, together with the
Common Display Framework.
The DT provides information about the hardware configuration
and limitations (eg. the
On Thu, Jun 13, 2013 at 05:28:08PM +0900, Inki Dae wrote:
This patch adds a buffer synchronization framework based on DMA BUF[1]
and reservation[2] to use dma-buf resource, and based on ww-mutexes[3]
for lock mechanism.
The purpose of this framework is not only to couple cache operations,
On Mon, Jun 17, 2013 at 10:04:45PM +0900, Inki Dae wrote:
It's just to implement a thin sync framework coupling cache operation. This
approach is based on dma-buf for more generic implementation against android
sync driver or KDS.
The described steps may be summarized as:
lock - cache
On Tue, Jun 18, 2013 at 12:03:31AM +0900, Inki Dae wrote:
2013/6/17 Russell King - ARM Linux li...@arm.linux.org.uk
Exactly right. But that is not definitely my point. Could you please see
the below simple example?:
(Presume that CPU and DMA share a buffer and the buffer is mapped with user
On Mon, Jun 17, 2013 at 04:42:37PM +0100, Russell King - ARM Linux wrote:
On Tue, Jun 18, 2013 at 12:03:31AM +0900, Inki Dae wrote:
2013/6/17 Russell King - ARM Linux li...@arm.linux.org.uk
Exactly right. But that is not definitely my point. Could you please see
the below simple example
On Tue, Jun 18, 2013 at 02:19:04AM +0900, Inki Dae wrote:
It seems like that all pages of the scatterlist should be mapped with
DMA every time DMA operation is started (or drm_xxx_set_src_dma_buffer
function call), and the pages should be unmapped from DMA again every
time DMA operation is
On Tue, Jun 18, 2013 at 02:27:40PM +0900, Inki Dae wrote:
So I'd like to ask for other DRM maintainers. How do you think about it? it
seems like that Intel DRM (maintained by Daniel), OMAP DRM (maintained by
Rob) and GEM CMA helper also have same issue Russell pointed out. I think
not only the
On Tue, Jun 18, 2013 at 06:04:44PM +0900, Inki Dae wrote:
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Tuesday, June 18, 2013 5:43 PM
To: Inki Dae
Cc: 'Maarten Lankhorst'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI mailing
list'; 'Rob
On Tue, Jun 18, 2013 at 09:00:16AM +0200, Daniel Vetter wrote:
On Mon, Jun 17, 2013 at 04:42:37PM +0100, Russell King - ARM Linux wrote:
What we need is something along the lines of:
(a) dma_buf_map_attachment() _not_ to map the scatterlist for DMA.
or
(b) drm_gem_prime_import
On Thu, Jun 20, 2013 at 12:10:04AM +0900, Inki Dae wrote:
On the other hand, the below shows how we could enhance the conventional
way with my approach (just example):
CPU - DMA,
ioctl(qbuf command) ioctl(streamon)
|
] On
Behalf Of Russell King - ARM Linux
Sent: Thursday, June 20, 2013 3:29 AM
To: Inki Dae
Cc: linux-fbdev; DRI mailing list; Kyungmin Park; myungjoo.ham; YoungJun
Cho; linux-media@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [RFC PATCH v2] dmabuf-sync
On Fri, Jul 06, 2012 at 02:57:51PM +0200, Javier Martin wrote:
Support the codadx6 that is included in
the i.MX27 SoC.
---
arch/arm/mach-imx/mach-imx27_visstrim_m10.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git
On Fri, Jul 06, 2012 at 02:57:50PM +0200, Javier Martin wrote:
+config VIDEO_CODA
+ tristate ChipsMedia Coda multi-standard codec IP
+ depends on VIDEO_DEV VIDEO_V4L2 SOC_IMX27
+ select VIDEOBUF2_DMA_CONTIG
+ select V4L2_MEM2MEM_DEV
+ default n
Please, no more 'default
This started out as a request to look at the DMA mask situation, and how
to solve the issues which we have on ARM - notably how the DMA mask
should be setup.
However, I started off reviewing how the dma_mask and coherent_dma_mask
was being used, and what I found was rather messy, and in some
On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote:
Hi,
On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote:
Use platform_device_register_full() for those drivers which can, to
avoid messing directly with DMA masks. This can only be done when
the driver does not need
On Fri, Sep 20, 2013 at 07:16:52AM -0500, Tejun Heo wrote:
On Fri, Sep 20, 2013 at 12:11:38AM +0100, Russell King wrote:
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch and
On Fri, Sep 20, 2013 at 02:21:37AM +0100, Ben Hutchings wrote:
On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote:
[...]
-dma_set_coherent_mask() will always be able to set the same or a
-smaller mask as dma_set_mask(). However for the rare case that a
+The coherent coherent mask will
On Fri, Sep 20, 2013 at 07:26:27PM +0200, Heiko Stübner wrote:
Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King:
The DMA API requires drivers to call the appropriate dma_set_mask()
functions before doing any DMA mapping. Add this required call to
the AMBA PL08x driver.
On Mon, Sep 23, 2013 at 03:55:33PM +0530, Vinod Koul wrote:
On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote:
register_platform_device_full() can setup the DMA mask provided the
appropriate member is set in struct platform_device_info. So lets
make that be the case. This
On Mon, Sep 23, 2013 at 02:27:39PM -0400, Alan Stern wrote:
On Thu, 19 Sep 2013, Russell King wrote:
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch and bus code should
On Thu, Sep 26, 2013 at 10:13:56AM +0200, Uwe Kleine-König wrote:
Hi Libin,
On Wed, Sep 25, 2013 at 07:47:19PM -0700, Libin Yang wrote:
In the clk enable and prepare function, we will check the NULL
pointer. So it should be no problem.
I'm not sure what you mean here and unfortunately
On Thu, Sep 26, 2013 at 10:23:08PM +0200, Rafał Miłecki wrote:
2013/9/19 Russell King - ARM Linux li...@arm.linux.org.uk:
This email is only being sent to the mailing lists in question, not to
anyone personally. The list of individuals is far to great to do that.
I'm hoping no mailing
v3.12-rc fails to build with this error:
drivers/media/i2c/ths8200.c:49:2: error: unknown field 'bt' specified in
initializer
drivers/media/i2c/ths8200.c:50:3: error: field name not in record or union
initializer
drivers/media/i2c/ths8200.c:50:3: error: (near initialization for
On Sun, Oct 13, 2013 at 12:36:07PM +0200, Gianluca Gennari wrote:
Il 13/10/2013 12:13, Russell King - ARM Linux ha scritto:
v3.12-rc fails to build with this error:
drivers/media/i2c/ths8200.c:49:2: error: unknown field 'bt' specified in
initializer
drivers/media/i2c/ths8200.c:50:3
On Sun, Oct 13, 2013 at 02:55:49PM +0200, Gianluca Gennari wrote:
Il 13/10/2013 13:16, Russell King - ARM Linux ha scritto:
On Sun, Oct 13, 2013 at 12:36:07PM +0200, Gianluca Gennari wrote:
Il 13/10/2013 12:13, Russell King - ARM Linux ha scritto:
v3.12-rc fails to build with this error
Bad move.
- Forwarded message from Patchwork patchw...@linuxtv.org -
Date: Tue, 15 Oct 2013 15:58:03 -
From: Patchwork patchw...@linuxtv.org
To: rmk+ker...@arm.linux.org.uk
Subject: [linux-media] Patch notification: 1 patch updated
Delivery-date: Tue, 15 Oct 2013 16:58:09 +0100
On Thu, Oct 31, 2013 at 09:46:40AM -0200, Mauro Carvalho Chehab wrote:
Hi Russell,
Em Mon, 30 Sep 2013 13:57:47 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
On 09/19/2013 11:44 PM, Russell King wrote:
Replace the following sequence:
dma_set_mask(dev, mask);
On Wed, Nov 13, 2013 at 11:43:44AM -0700, Troy Kisky wrote:
On 11/13/2013 2:23 AM, Denis Carikli wrote:
+ /* rgb666 */
+ipu_dc_map_clear(priv, IPU_DC_MAP_RGB666);
+ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 2, 17, 0xfc); /* red */
+ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 1,
On Wed, Jan 02, 2013 at 08:10:36AM +0300, Dan Carpenter wrote:
clk_get() returns NULL if CONFIG_HAVE_CLK is disabled.
I told Tony about this but everyone has been gone with end of year
holidays so it hasn't been addressed.
Tony, please fix it so people don't apply these patches until
On Wed, Jan 02, 2013 at 08:29:57AM +0100, Julia Lawall wrote:
There are dereferences to the result of clk_get a few times. I tried the
following semantic patch:
And those are buggy; struct clk is _SUPPOSED_ to be an OPAQUE COOKIE
and no one other than the clk code should be dereferencing it.
On Wed, Jan 02, 2013 at 10:44:32AM +0100, Julia Lawall wrote:
On Wed, 2 Jan 2013, Russell King - ARM Linux wrote:
On Wed, Jan 02, 2013 at 08:10:36AM +0300, Dan Carpenter wrote:
clk_get() returns NULL if CONFIG_HAVE_CLK is disabled.
I told Tony about this but everyone has been gone
On Thu, Jan 03, 2013 at 12:05:20PM +0300, Dan Carpenter wrote:
On Wed, Jan 02, 2013 at 06:31:53PM +1300, Tony Prisk wrote:
Why should a _consumer_ of a clock care? It is _very_ important that
people get this idea - to a consumer, the struct clk is just an opaque
cookie. The fact that it
On Thu, Jan 03, 2013 at 10:14:13AM +0100, Julia Lawall wrote:
On Thu, 3 Jan 2013, Dan Carpenter wrote:
On Wed, Jan 02, 2013 at 06:31:53PM +1300, Tony Prisk wrote:
On Wed, 2013-01-02 at 08:10 +0300, Dan Carpenter wrote:
clk_get() returns NULL if CONFIG_HAVE_CLK is disabled.
I
On Thu, Jan 03, 2013 at 02:10:40PM +0300, Dan Carpenter wrote:
Come on... Don't say we haven't read comment. Obviously, the first
thing we did was read that comment. I've read it many times at this
point and I still think we should add in a bit which says:
So where does it give you in that
On Thu, Jan 03, 2013 at 04:45:54PM +0300, Dan Carpenter wrote:
On Thu, Jan 03, 2013 at 11:21:02AM +, Russell King - ARM Linux wrote:
Maybe you don't realise, but IS_ERR(NULL) is false. Therefore, this falls
into category (2).
No, obviously, I know the difference between IS_ERR
1 - 100 of 403 matches
Mail list logo
