On Thursday 26 January 2012, Marek Szyprowski wrote:
> Welcome everyone!
>
> Yes, that's true. This is yet another release of the Contiguous Memory
> Allocator patches. This version mainly includes code cleanups requested
> by Mel Gorman and a few minor bug fixes.
Hi Marek,
Thanks for keeping up
kernel mapping and in an
uncached mapping for DMA: We know that the code we are using in mainline
is broken on ARMv6 and later and that CMA fixes that problem.
I'm not the right person to judge the memory management code changes,
others need to comment on that. Aside from that:
Acked-by: Arnd Ber
On Wednesday 22 February 2012, Russell King - ARM Linux wrote:
> 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 setti
On Friday 25 May 2012, Linus Torvalds wrote:
> Please do something like
>
>gpg --keyserver pgp.mit.edu --send-keys 7126925D
>
> to actually make your public key public.
>
> Of course, if it isn't public, I assume it hasn't actually been signed
> by anybody, which makes it largely useless. Bu
On Friday 02 December 2011, Sumit Semwal wrote:
> This is the first step in defining a dma buffer sharing mechanism.
This looks very nice, but there are a few things I don't understand yet
and a bunch of trivial comments I have about things I spotted.
Do you have prototype exporter and consumer d
On Monday 05 December 2011 19:55:44 Daniel Vetter wrote:
> > The only way to solve this that I can think of right now is to
> > mandate that the mappings are all coherent (i.e. noncachable
> > on noncoherent architectures like ARM). If you do that, you no
> > longer need the sync_sg_for_* calls.
>
On Monday 05 December 2011 21:58:39 Daniel Vetter wrote:
> On Mon, Dec 05, 2011 at 08:29:49PM +0100, Arnd Bergmann wrote:
> > ...
>
> Thanks a lot for this excellent overview. I think at least for the first
> version of dmabuf we should drop the sync_* interfaces and simply
On Monday 05 December 2011 14:46:47 Rob Clark wrote:
> On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann wrote:
> > On Friday 02 December 2011, Sumit Semwal wrote:
> >> This is the first step in defining a dma buffer sharing mechanism.
> >
> > This looks very nice, but
On Monday 05 December 2011, Rob Clark wrote:
> > On the topic of a coherency model for dmabuf, I think we need to look at
> > dma_buf_attachment_map/unmap (and also the mmap variants cpu_start and
> > cpu_finish or whatever they might get called) as barriers:
> >
> > So after a dma_buf_map, all pre
On Wednesday 07 December 2011, Semwal, Sumit wrote:
> >
> > Do you have a use case for making the interface compile-time disabled?
> > I had assumed that any code using it would make no sense if it's not
> > available so you don't actually need this.
>
> Ok. Though if we keep the interface compile-
On Wednesday 07 December 2011, Semwal, Sumit wrote:
> Right; that would be ideal, but we may not be able to ask each user to
> do so - especially when the sharing part might be interspersed in
> existing buffer handling code. So for now, I would like to keep it as
> it-is.
Ok, fair enough. It cert
On Wednesday 07 December 2011, Semwal, Sumit wrote:
> Thanks for the excellent discussion - it indeed is very good learning
> for the relatively-inexperienced me :)
>
> So, for the purpose of dma-buf framework, could I summarize the
> following and rework accordingly?:
> 1. remove mmap() dma_buf_o
On Thursday 08 December 2011, Daniel Vetter wrote:
> > c) only allowing streaming mappings, even if those are non-coherent
> > (requiring strict serialization between CPU (in-kernel) and dma users of
> > the buffer)
>
> I think only allowing streaming access makes the most sense:
> - I don't see m
On Monday 12 December 2011, Mel Gorman wrote:
> The bloat exists either way. I don't believe the linker strips it out so
> overall it would make more sense to depend on compaction to keep the
> vmstat counters for debugging reasons if nothing else. It's not
> something I feel very strongly about th
On Saturday 10 December 2011, Daniel Vetter wrote:
> If userspace (through some driver calls)
> tries to do stupid things, it'll just get garbage. See
> Message-ID:
>
> for my reasons why it think this is the right way to go forward. So in
> essence I'm really interested in the reasons why you wa
On Monday 12 December 2011, Robert Morell wrote:
> >
> > Doing a buffer sharing with something that is not GPL is not fun, as, if any
> > issue rises there, it would be impossible to discover if the problem is
> > either
> > at the closed-source driver or at the open source one. At the time I was
On Tuesday 20 December 2011, Sakari Ailus wrote:
> (I'm jumping into the discussion in the middle, and might miss something
> that has already been talked about. I still hope what I'm about to say is
> relevant. :-))
It certainly is relevant.
> In subsystems such as V4L2 where drivers deal with s
On Monday 19 December 2011, Semwal, Sumit wrote:
> I didn't see a consensus on whether dma_buf should enforce some form
> of serialization within the API - so atleast for v1 of dma-buf, I
> propose to 'not' impose a restriction, and we can tackle it (add new
> ops or enforce as design?) whenever we
On Tuesday 20 December 2011, Daniel Vetter wrote:
> > I'm thinking for a first version, we can get enough mileage out of it by
> > saying:
> > 1) only exporter can mmap to userspace
> > 2) only importers that do not need CPU access to buffer..
Ok, that sounds possible. The alternative to this wou
t exported for OMAP1, so we have to move the
definition out of the OMAP2 specific section.
Signed-off-by: Arnd Bergmann
Cc: Mauro Carvalho Chehab
Cc: Timo Kokkonen
Cc: Tony Lindgren
Cc: Laurent Pinchart
Cc: Greg Kroah-Hartman
Cc: linux-media@vger.kernel.org
---
arch/arm/plat-omap/dmti
directly
to the arm-soc tree with an Ack or do a round-trip through
the platform maintainer tree. I think Tony already has some of
the OMAP1 fixes, so we should try not to duplicate them.
Arnd
Arnd Bergmann (9):
clk: vt8500: Fix "fix device clock divisor calculations"
Revert parts
On Thursday 14 March 2013, Fabio Porcedda wrote:
> This patch converts the drivers to use the
> module_platform_driver_probe() macro which makes the code smaller and
> a bit simpler.
>
> Signed-off-by: Fabio Porcedda
> Cc: Greg Kroah-Hartman
> Cc: Arnd Bergmann
This driver can be enabled on OMAP1 at the moment, which breaks
allyesconfig for that platform. Let's mark it OMAP2PLUS-only
in Kconfig, since that is the only thing it builds on.
Signed-off-by: Arnd Bergmann
Cc: Mauro Carvalho Chehab
Cc: Timo Kokkonen
Cc: Tony Lindgren
Cc: Laurent Pin
On Friday 15 March 2013, Fabio Porcedda wrote:
> >> * Regarding the use of module_platform_driver_probe, I'm a little worried
> >> about
> >> the interactions with deferred probing. I don't think there are any
> >> regressions,
> >> but we should probably make people aware that one cannot ret
On Friday 15 March 2013, H Hartley Sweeten wrote:
> Arnd,
>
> Ill look at converting the ep93xx pwm driver to the PWM subsystem. The only
> issue is
> the current driver exposes a sysfs interface that I think is not available in
> that subsystem.
You can probably keep providing that interface i
On Monday 18 March 2013, Fabio Porcedda wrote:
> Since by using platform_driver_probe() the function
> ep93xx_pwm_probe() is freed after initialization,
> is better to use module_platform_drive_probe().
> IMHO i don't see any good reason to use module_platform_driver() for
> this driver.
As I com
On Monday 18 March 2013, Fabio Porcedda wrote:
>
> On Mon, Mar 18, 2013 at 11:58 AM, Arnd Bergmann wrote:
> > On Monday 18 March 2013, Fabio Porcedda wrote:
> >> Since by using platform_driver_probe() the function
> >> ep93xx_pwm_probe() is freed after initial
On Tuesday 19 March 2013, Geert Uytterhoeven wrote:
> Hmm, so we may have drivers that (now) work perfectly fine with
> module_platform_driver_probe()/platform_driver_probe(), but will start
> failing suddenly in the future?
They will fail if someone changes the initialization order. That would
al
On Tuesday 19 March 2013, Fabio Porcedda wrote:
> On Tue, Mar 19, 2013 at 5:48 PM, Arnd Bergmann wrote:
> > On Tuesday 19 March 2013, Geert Uytterhoeven wrote:
> >> Hmm, so we may have drivers that (now) work perfectly fine with
> >> module_platform_driver_probe()/p
On Wednesday 20 March 2013, Fabio Porcedda wrote:
> I think we can check inside the deferred_probe_work_func()
> if the dev->probe function pointer is equal to platform_drv_probe_fail().
I think it's too late by then, because that would only warn if we try to probe
it again, but when platform_dri
On Wednesday 20 March 2013, Fabio Porcedda wrote:
>
> On Wed, Mar 20, 2013 at 11:20 AM, Arnd Bergmann wrote:
> > On Wednesday 20 March 2013, Fabio Porcedda wrote:
> >> I think we can check inside the deferred_probe_work_func()
> >> if the dev->p
On Tuesday 02 April 2013, Guennadi Liakhovetski wrote:
> Currently modular V4L2 build with enabled OF is broken dur to the
> of_get_next_parent() function being unavailable to modules. Export it to
> fix the build.
>
> Cc: Sylwester Nawrocki
> Signed-off-by: Guennadi Liakhovetski
Looks good to
subsystem maintainers: feel free to directly apply the patches
for your subsystem, there should be no dependencies between any of them,
aside from the last patch requiring all of the earlier ones to be applied
first. Getting an Ack is also fine so we can put the patches into arm-soc.
Arnd
Arnd
In multiplatform configurations, we cannot include headers
provided by only the exynos platform. Fortunately a number
of drivers that include those headers do not actually need
them, so we can just remove the inclusions.
Signed-off-by: Arnd Bergmann
Cc: linux-media@vger.kernel.org
Cc: Mauro
On Thursday 11 April 2013, Sylwester Nawrocki wrote:
> On 04/11/2013 02:13 AM, Mauro Carvalho Chehab wrote:
> > Em Thu, 11 Apr 2013 02:04:53 +0200
> > Arnd Bergmann escreveu:
> >
> >> In multiplatform configurations, we cannot include headers
> >&g
be':
> :(.text+0x1107d4): undefined reference to `of_get_named_gen_pool'
> :(.text+0x1108b8): undefined reference to `gen_pool_alloc'
> :(.text+0x1108d0): undefined reference to `gen_pool_virt_to_phys'
> :(.text+0x110918): undefined reference to `dev_get_gen_pool&
On Saturday 27 April 2013, Fabio Estevam wrote:
> I fixed this issue in a different way:
> https://patchwork.kernel.org/patch/2432841/
>
> And Shawn has already queued it.
Ok, that's probably better.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the bo
carefully.
I'm definitely happy for any patches to go into maintainer
trees right away. Obviously the final patch cannot go in
until everything else gets merged first and I suspect there
will be a series of patches for maintainerless drivers that
will go along with it.
Arnd
Ar
sleep_on and its variants are broken and going away soon. This changes
the omap vout driver to use interruptible_sleep_on_timeout instead,
which fixes potential race where the dma is complete before we
schedule.
Signed-off-by: Arnd Bergmann
Cc: Mauro Carvalho Chehab
Cc: linux-media
order to do this, we have to slightly adapt the
meaning of the ar->start_capture field to distinguish between not having
started a frame and having completed it.
Signed-off-by: Arnd Bergmann
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
---
drivers/media/platform/arv.c | 4 ++--
1 f
interruptible_sleep_on is racy and going away. This replaces
one use in the radio-cadet driver with an open-coded
wait loop that lets us check the condition under the mutex
but sleep without it.
Signed-off-by: Arnd Bergmann
Cc: Hans Verkuil
Cc: Mauro Carvalho Chehab
Cc: linux-media
There is no reason to use sleep_on_timeout here, and we want to get
rid of that interface. Use the simpler msleep_interruptible instead.
Signed-off-by: Arnd Bergmann
Cc: Hans Verkuil
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
---
drivers/media/usb/usbvision/usbvision.h | 4
commit 340a30c514 "s2255drv: upgrade to videobuf2" changed the API
used by the s2255 driver, but did not modify the Kconfig statement,
which can lead to build errors when no other driver already uses
VIDEOBUF2_VMALLOC. This patch does the necessary Kconfig change.
Signed-off-by: Arn
On Thursday 06 March 2014, Sylwester Nawrocki wrote:
> This patch adds the V4L2 asynchronous subdev registration and
> device tree support. Common clock API is used to control the
> sensor master clock from within the subdev.
>
> Signed-off-by: Andrzej Hajda
> Signed-off-by: Sylwester Nawrocki
>
The LIRC support for sa1100 appears to have never worked
because it relies on header files that have never been
present in git history. Actually trying to build the
driver on an ARM sa1100 kernel fails, so let's just remove
the broken support.
Signed-off-by: Arnd Bergmann
Cc: Jarod Wilso
If the USB code is a loadable module, this driver cannot
be built-in. This adds an explicit dependency on CONFIG_USB
so that Kconfig can force sn9c102 to be a module in this case.
Signed-off-by: Arnd Bergmann
Cc: Luca Risolia
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
Cc: linux
Hi Greg,
Here are a couple of simple fixes from my backlog of ARM
randconfig bugs. Nothing urgent, they can probably all go
into next for 3.17 after the merge window, but see for
yourself.
Arnd
Arnd Bergmann (5):
staging: lirc: remove sa1100 support
staging/iio
the
driver incorrectly calls a platform-internal interface
for omap4_ctrl_pad_readl/omap4_ctrl_pad_writel.
To work around that, we can export those symbols, but
that isn't really the correct solution, as we should not
have dependencies on platform code this way.
Signed-off-by: Arnd Bergmann
---
This
On Wednesday 11 June 2014 09:42:04 Nishanth Menon wrote:
> On 06/11/2014 09:35 AM, Arnd Bergmann wrote:
> > The OMAP4 camera support depends on I2C and VIDEO_V4L2, both
> > of which can be loadable modules. This causes build failures
> > if we want the camera driver to be bu
On Thursday 12 June 2014 16:12:17 Laurent Pinchart wrote:
> > From 3a965f4fd5a6b3ef4a66aa4e7c916cfd34fd5706 Mon Sep 17 00:00:00 2001
> > From: Arnd Bergmann
> > Date: Tue, 21 Jan 2014 09:32:43 +0100
> > Subject: [PATCH] [media] staging: tighten omap4iss dependencies
&
On Thursday 12 June 2014 07:25:15 Greg KH wrote:
> On Thu, Jun 12, 2014 at 04:15:32PM +0200, Arnd Bergmann wrote:
> > On Thursday 12 June 2014 16:12:17 Laurent Pinchart wrote:
> > > > From 3a965f4fd5a6b3ef4a66aa4e7c916cfd34fd5706 Mon Sep 17 00:00:00 2001
> > > >
On Thursday 18 December 2014 11:37:13 Chunyan Zhang wrote:
> This patch changes the 32-bit time type (timeval) to the 64-bit one
> (ktime_t), since 32-bit time types will break in the year 2038.
>
> I use ktime_t instead of all uses of timeval in imon.c
>
> This patch also changes do_gettimeofday
The vb2_dma_sg_memops pointer is only valid if VIDEOBUF2_DMA_SG is
set, so we should select that to avoid this build error:
drivers/built-in.o: In function `mcam_v4l_open':
:(.text+0x388d00): undefined reference to `vb2_dma_sg_memops'
Signed-off-by: Arnd Bergmann
Cc: Jonat
`smscore_unregister_device'
:(.text+0x156140): undefined reference to `smscore_start_device'
Signed-off-by: Arnd Bergmann
---
drivers/media/mmc/siano/Kconfig | 2 ++
drivers/media/usb/siano/Kconfig | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/media/mmc/siano/Kconfig b/drive
aration of function 'v4l2_subdev_get_try_format'
[-Werror=implicit-function-declaration]
return v4l2_subdev_get_try_format(fh, pad);
^
Signed-off-by: Arnd Bergmann
Cc: Greg Kroah-Hartman
---
drivers/staging/media/davinci_vpfe/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --g
usb/gspca/xirlink_cit.c:2935: undefined reference to `input_event'
drivers/built-in.o:/git/arm-soc/include/linux/input.h:414: more undefined
references to `input_event' follow
This adds an explicit dependency.
Signed-off-by: Arnd Bergmann
Cc: Hans de Goede
---
drivers/media/usb
here are all trivial, mostly adding missing dependencies.
Please apply.
Arnd Bergmann (7):
[media] timberdale: do not select TIMB_DMA
[media] radio/aimslab: use mdelay instead of udelay
[media] staging/davinci/vpfe/dm365: add missing dependencies
[media] siano: fix Kconfig depende
Large udelay values are not allowed on the ARM architecture
and result in a build error like
ERROR: "__bad_udelay" [drivers/media/radio/radio-aimslab.ko] undefined!
This changes the aimslab radio driver to use an equivalent mdelay
statement.
Signed-off-by: Arnd Bergmann
Cc: Ha
e code around.
Alternatively it could be removed entirely.
Signed-off-by: Arnd Bergmann
Cc: Jonathan Corbet
---
drivers/media/platform/marvell-ccic/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/marvell-ccic/Kconfig
b/drivers/media/platform/m
ving the inappropriate 'select'
statement and replacing it with a direct dependency on the
drivers that provide the services this needs.
Signed-off-by: Arnd Bergmann
Fixes: 7155043c2d027 ("[media] enable COMPILE_TEST for media drivers")
---
drivers/media/platform/Kconfig |
7;
This marks the driver as 'BROKEN' but keeps the code around.
Alternatively it could be removed entirely.
Signed-off-by: Arnd Bergmann
Acked-by: Jonathan Corbet
Cc: Libin Yang
Fixes: 05fed81625bf75 ("[media] marvell-ccic: add MIPI support for marvell-ccic
driver")
> This driv
n function `vb2_ioctl_querybuf':
:(.text+0x115530): undefined reference to `video_devdata'
To solve this, we need to add a dependency on VIDEO_V4L2,
which enforces that the davinci drivers themselves can only
be loadable modules if V4L2 is not built-in, and they do
not cause the videobuf2 code to
2c_get_adapter(pdata->hdmiphy_bus);
^
This patch changes the Kconfig description to include I2C
as a dependency for this driver, so it cannot be configured
incorrectly.
Signed-off-by: Arnd Bergmann
diff --git a/drivers/media/platform/s5p-tv/Kconfig
b/drivers/media/platform/s5p-tv/Kco
On Tuesday 03 February 2015 09:04:03 Rob Clark wrote:
> On Tue, Feb 3, 2015 at 2:48 AM, Daniel Vetter wrote:
> > On Mon, Feb 02, 2015 at 03:30:21PM -0500, Rob Clark wrote:
> >> On Mon, Feb 2, 2015 at 11:54 AM, Daniel Vetter wrote:
> >> >> My initial thought is for dma-buf to not try to prevent so
On Tuesday 03 February 2015 14:41:09 Russell King - ARM Linux wrote:
> On Tue, Feb 03, 2015 at 03:17:27PM +0100, Arnd Bergmann wrote:
> > On Tuesday 03 February 2015 09:04:03 Rob Clark wrote:
> > > Since I'm stuck w/ an iommu, instead of built in mmu, my plan was to
> &
On Tuesday 03 February 2015 15:22:05 Russell King - ARM Linux wrote:
> On Tue, Feb 03, 2015 at 03:52:48PM +0100, Arnd Bergmann wrote:
> > On Tuesday 03 February 2015 14:41:09 Russell King - ARM Linux wrote:
> > > I'd go as far as saying that the "DMA API on top of IOMM
On Tuesday 03 February 2015 15:54:04 Russell King - ARM Linux wrote:
> On Tue, Feb 03, 2015 at 04:31:13PM +0100, Arnd Bergmann wrote:
> > The dma_map_* interfaces assign the virtual addresses internally,
> > using typically either a global address space for all devices, or one
&g
On Tuesday 03 February 2015 11:22:01 Rob Clark wrote:
> On Tue, Feb 3, 2015 at 11:12 AM, Arnd Bergmann wrote:
> > I agree for the case you are describing here. From what I understood
> > from Rob was that he is looking at something more like:
> >
> > Fig 3
> > CPU
On Tuesday 03 February 2015 21:04:35 Daniel Vetter wrote:
> - On many soc people love to reuse iommus with the same or similar
> interface all over the place. The solution thus far adopted on arm
> platforms is to write an iommu driver for those and then implement the
> dma-api on top of thi
On Tuesday 03 February 2015 12:35:34 Rob Clark wrote:
>
> I can't think of cases outside of GPU's.. if it were more common I'd
> be in favor of teaching dma api about multiple contexts, but right now
> I think that would just amount to forcing a lot of churn on everyone
> else for the benefit of
de restructured in a way to turn around the dependency, but either
way would require much larger changes here.
Signed-off-by: Arnd Bergmann
Fixes: 7b34be71db53 ("[media] use IS_ENABLED() macro")
See-also: c5dec9fb248e ("V4L/DVB (4751): Fix DBV_FE_CUSTOMISE for card drivers
comp
On Thursday 19 February 2015 13:11:07 Michal Marek wrote:
> On 2015-02-18 18:12, Arnd Bergmann wrote:
> > In the media drivers, the v4l2 core knows about all submodules
> > and calls into them from a common function. However this cannot
> > work if the modules that get called
On Thursday 19 February 2015 16:06:18 Michal Marek wrote:
> > We have similar problems in other areas
> > of the kernel. In theory, we could enforce the VIDEO_TUNER driver to
> > be modular here by adding lots of dependencies to it:
> >
> > config VIDEO_TUNER
> > tristate
> > depends o
ko] undefined!
ERROR: "skb_push" [drivers/media/radio/wl128x/fm_drv.ko] undefined!
ERROR: "skb_pull" [drivers/media/radio/wl128x/fm_drv.ko] undefined!
Making the driver dependency explicit solves randconfig
build problems and makes it more obvious to the reader.
Signed-off-by: Ar
turn, this broke ARM allyesconfig builds. Replacing the
omap4_ctrl_pad_writel call with WARN_ON(1) won't make the
situation any worse than it already is, but fixes the build
problem.
Signed-off-by: Arnd Bergmann
Fixes: efde234674d9 ("ARM: OMAP4+: control: remove support for legacy pad
read/wr
ency, this adds the 'select BITREVERSE' that
all other similar drivers have.
Signed-off-by: Arnd Bergmann
diff --git a/drivers/media/tuners/Kconfig b/drivers/media/tuners/Kconfig
index 983510d282f6..db4caf2b4669 100644
--- a/drivers/media/tuners/Kconfig
+++ b/drivers/media/tuners/Kcon
ell. The commit that introduced
the warning was marked for 3.18+ backports, so this should
probably be backported too.
Signed-off-by: Arnd Bergmann
Fixes: 0e661006370b7 ("[media] vb2: fix 'UNBALANCED' warnings when calling
vb2_thread_stop()")
Cc: # for v3.18 and
nged in
the original cleanup, and found them to be correct in either
version, so I do not touch that part.
As this is a rather obscure bug, there is no need for backports.
Signed-off-by: Arnd Bergmann
Fixes: 028c70ff42783 ("[media] dvb-usb/dvb-usb-v2: use IS_ENABLED")
---
dri
ion]
The dependency already exists for exynos-fimc-lite and s5p-fimc,
but is missing for exynos4-fimc.
Signed-off-by: Arnd Bergmann
diff --git a/drivers/media/platform/exynos4-is/Kconfig
b/drivers/media/platform/exynos4-is/Kconfig
index b7b2e472240a..40423c6c5324 100644
--- a/drivers/media/platfor
1400bd1 ("[media] omap3isp: Move to videobuf2")
Signed-off-by: Arnd Bergmann
Hi Laurent,
Could you have a look at this? It's possible I'm missing something
important here, but this is what I currently need to get randconfig
builds to use the omap3isp driver.
diff --
On Tuesday 22 July 2014 13:42:00 Sylwester Nawrocki wrote:
> On 14/07/14 11:56, Mark Rutland wrote:
> >> diff --git a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
> >> b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
> >> > index 937b755..3142745 100644
> >> > --- a
On Tuesday 22 July 2014 16:18:25 Sylwester Nawrocki wrote:
>
> All right, then I would rephrase it to:
>
> - clock-names : should contain:
>- "jpeg" for the common gate clock,
>- "sclk" for the special clock (only for Exynos3250).
> - clocks: shou
On Tuesday 09 September 2014 12:09:36 Mauro Carvalho Chehab wrote:
> -exynos4.c
> > > index e51c078360f5..01eeacf28843 100644
> > > --- a/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
> > > +++ b/drivers/media/platform/s5p-jpeg/jpeg-hw-exynos4.c
> > > @@ -23,7 +23,9 @@ void exynos4_jpeg_sw_rese
er is not needed at all,
because module_put has the same check.
Signed-off-by: Arnd Bergmann
diff --git a/drivers/media/pci/pt3/pt3.c b/drivers/media/pci/pt3/pt3.c
index 90f86ce7a001..39305f07dc2e 100644
--- a/drivers/media/pci/pt3/pt3.c
+++ b/drivers/media/pci/pt3/pt3.c
@@ -429,14 +429,10 @@ static in
>From 6699184d4b791e8a10380d3b75be837607d3 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann
Date: Mon, 29 Sep 2014 17:33:25 +0200
Subject: [PATCH] [media] vivid: add CONFIG_FB dependency
The vivid test driver creates a framebuffer, which fails if the the framebuffer
layer is not enab
On Monday 06 October 2014 11:10:26 Paul Bolle wrote:
> config VIDEO_SAMSUNG_S5P_TV
> bool "Samsung TV driver for S5P platform"
> depends on PM_RUNTIME
> - depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
> + depends on ARCH_EXYNOS || COMPILE_TEST
> default n
>
On Wednesday 21 January 2009, Jaswinder Singh Rajput wrote:
> > diff -r 29c5787efcda linux/include/linux/videodev.h
> > --- a/linux/include/linux/videodev.hThu Jan 15 09:07:03 2009 -0800
> > +++ b/linux/include/linux/videodev.hWed Jan 21 00:51:45 2009 -0800
> > @@ -15,7 +15,8 @@
> > #incl
many libc variants.
This introduces a that can be safely included
by any other header file.
Signed-off-by: Arnd Bergmann
--- /dev/null
+++ b/include/linux/strict_types.h
@@ -0,0 +1,31 @@
+#ifndef __LINUX_STRICT_TYPES_H
+#define __LINUX_STRICT_TYPES_H
+
+#include
+/*
+ * Below are truly Linux-spec
On Wednesday 04 February 2009, H. Peter Anvin wrote:
>
> Actually, if anything we should move the *non* __KERNEL_STRICT_NAMES out
> of into something else, or completely deep-six them. I
> don't know of any libc which wants these anymore, and I think they're
> just residual libc5 cruft.
>
> How
A number of standard posix types are used in exported headers, which
is not allowed if __STRICT_KERNEL_NAMES is defined. Change them all
to use the safe __kernel variant so that we can make __STRICT_KERNEL_NAMES
the default.
Signed-off-by: Arnd Bergmann
---
On Thursday 05 February 2009, H
On Thursday 05 February 2009, Arnd Bergmann wrote:
> @@ -9,6 +9,7 @@
> #endif
> #include
>
> +#error this doesn't compile
> struct elf_siginfo
> {
> int si_signo; /* signal number */
This hunk obviously was not meant to be
701 - 791 of 791 matches
Mail list logo
