[PATCH] omap3isp: Fix iommu domain use-after-free in isp_probe() error path
isp_save_ctx() is called from omap3isp_put() after iommu_domain_free() in the isp_probe() error path [3.205047] Unable to handle kernel NULL pointer dereference at virtual address 003c [3.213470] pgd = c0004000 [3.216308] [003c] *pgd= [3.220031] Internal error: Oops: 5 [#1] PREEMPT ARM [3.225189] Modules linked in: [3.228363] CPU: 0Not tainted (3.7.10 #3) [3.232971] PC is at omap2_iommu_save_ctx+0x0/0x34 [3.237945] LR is at omap_iommu_save_ctx+0x1c/0x24 [3.242919] pc : []lr : []psr: 6113 ... [3.425109] [] (omap2_iommu_save_ctx+0x0/0x34) from [] (omap_iommu_save_ctx+0x1c/0x24) [3.435150] [] (omap_iommu_save_ctx+0x1c/0x24) from [] (omap3isp_put+0x84/0xfc) [3.444519] [] (omap3isp_put+0x84/0xfc) from [] (isp_probe+0x8d8/0xa60) [3.453186] [] (isp_probe+0x8d8/0xa60) from [] (platform_drv_probe+0x14/0x18) [3.462402] [] (platform_drv_probe+0x14/0x18) from [] (driver_probe_device+0xb0/0x1dc) compare isp_remove(): isp->domain is set to NULL after iommu_domain_free() above crash is observed with 3.7 the issue is fixed in 3.11 (7c0f812a5d65e712618af880dda4a5cc7ed79463), but present in 3.10 longterm Cc: sta...@vger.kernel.org Signed-off-by: Peter Meerwald --- drivers/media/platform/omap3isp/isp.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/platform/omap3isp/isp.c b/drivers/media/platform/omap3isp/isp.c index 1d7dbd5..a73d9d9 100644 --- a/drivers/media/platform/omap3isp/isp.c +++ b/drivers/media/platform/omap3isp/isp.c @@ -2287,6 +2287,7 @@ detach_dev: iommu_detach_device(isp->domain, &pdev->dev); free_domain: iommu_domain_free(isp->domain); + isp->domain = NULL; error_isp: isp_xclk_cleanup(isp); omap3isp_put(isp); -- 1.7.9.5 -- 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
[PATCH] omap3isp: Make isp_register_entities() fail when sensor registration fails
isp_register_entities() ignores registration failure of the sensor,
/dev/video* devices are created nevertheless
if the sensor fails, all entities should not be created
Signed-off-by: Peter Meerwald
---
I'm not too sure about the ENODEV error code
drivers/media/platform/omap3isp/isp.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index 06a0df4..1ef6b5d 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -1903,8 +1903,10 @@ static int isp_register_entities(struct isp_device *isp)
unsigned int i;
sensor = isp_register_subdev_group(isp, subdevs->subdevs);
- if (sensor == NULL)
- continue;
+ if (sensor == NULL) {
+ ret = -ENODEV;
+ goto done;
+ }
sensor->host_priv = subdevs;
--
1.7.9.5
--
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
Re: [PATCHv2 1/3] phy: Add exynos-simple-phy driver
Hi Rahul,
I will prepare we v3 version.
Do you want me to add your patches for exynos5?50 to the patchset?
Regards,
Tomasz Stanislawski
On 04/30/2014 08:37 AM, Rahul Sharma wrote:
> Hi Tomasz,
>
> I have tested your patches for exynos5250 and 5420. Works fine. Are
> you planning to post v3? If you want I can share hand with you for v3.
>
> Regards,
> Rahul Sharma
>
> On 9 April 2014 17:17, Andreas Oberritter wrote:
>> Hello Andrzej,
>>
>> On 09.04.2014 10:37, Andrzej Hajda wrote:
+static int exynos_phy_probe(struct platform_device *pdev)
+{
+const struct of_device_id *of_id = of_match_device(
+of_match_ptr(exynos_phy_of_match), &pdev->dev);
+const u32 *offsets = of_id->data;
+int count;
+struct device *dev = &pdev->dev;
+struct phy **phys;
+struct resource *res;
+void __iomem *regs;
+int i;
+struct phy_provider *phy_provider;
+
+/* count number of phys to create */
+for (count = 0; offsets[count] != ~0; ++count)
+;
>>>
>>> count = ARRAY_SIZE(offsets) - 1;
>>
>> u32 *offsets is not an array.
>>
>> Regards,
>> Andreas
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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
Re: [PATCH] omap3isp: Make isp_register_entities() fail when sensor registration fails
Hi Peter, On Wed, Apr 30, 2014 at 10:14:31AM +0200, Peter Meerwald wrote: > isp_register_entities() ignores registration failure of the sensor, > /dev/video* devices are created nevertheless > > if the sensor fails, all entities should not be created Why? In some cases it'd be nice to be able to use the devices that actually are available. This certainly isn't something that should cause probe to fail IMHO. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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
Re: [PATCHv2 1/3] phy: Add exynos-simple-phy driver
Sure (5250, 5420). I will wait for the same to update DT patches, if any.
Regards,
Rahul Sharma.
On 30 April 2014 14:02, Tomasz Stanislawski wrote:
> Hi Rahul,
> I will prepare we v3 version.
> Do you want me to add your patches for exynos5?50 to the patchset?
> Regards,
> Tomasz Stanislawski
>
> On 04/30/2014 08:37 AM, Rahul Sharma wrote:
>> Hi Tomasz,
>>
>> I have tested your patches for exynos5250 and 5420. Works fine. Are
>> you planning to post v3? If you want I can share hand with you for v3.
>>
>> Regards,
>> Rahul Sharma
>>
>> On 9 April 2014 17:17, Andreas Oberritter wrote:
>>> Hello Andrzej,
>>>
>>> On 09.04.2014 10:37, Andrzej Hajda wrote:
> +static int exynos_phy_probe(struct platform_device *pdev)
> +{
> +const struct of_device_id *of_id = of_match_device(
> +of_match_ptr(exynos_phy_of_match), &pdev->dev);
> +const u32 *offsets = of_id->data;
> +int count;
> +struct device *dev = &pdev->dev;
> +struct phy **phys;
> +struct resource *res;
> +void __iomem *regs;
> +int i;
> +struct phy_provider *phy_provider;
> +
> +/* count number of phys to create */
> +for (count = 0; offsets[count] != ~0; ++count)
> +;
count = ARRAY_SIZE(offsets) - 1;
>>>
>>> u32 *offsets is not an array.
>>>
>>> Regards,
>>> Andreas
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-samsung-soc" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
--
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
Re: [PATCH] omap3isp: Make isp_register_entities() fail when sensor registration fails
Hi, > On Wed, Apr 30, 2014 at 10:14:31AM +0200, Peter Meerwald wrote: > > isp_register_entities() ignores registration failure of the sensor, > > /dev/video* devices are created nevertheless > > > > if the sensor fails, all entities should not be created > Why? In some cases it'd be nice to be able to use the devices that actually > are available. This certainly isn't something that should cause probe to > fail IMHO. I see your point; e.g the ISP resizer could be used without a sensor anyway, I can figure out later-on from the device topology that no sensor is present thanks, p. -- Peter Meerwald +43-664-218 (mobile) -- 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
Re: [PATCH] omap3isp: Make isp_register_entities() fail when sensor registration fails
On Wed, Apr 30, 2014 at 11:04:14AM +0200, Peter Meerwald wrote: > Hi, > > > On Wed, Apr 30, 2014 at 10:14:31AM +0200, Peter Meerwald wrote: > > > isp_register_entities() ignores registration failure of the sensor, > > > /dev/video* devices are created nevertheless > > > > > > if the sensor fails, all entities should not be created > > > Why? In some cases it'd be nice to be able to use the devices that actually > > are available. This certainly isn't something that should cause probe to > > fail IMHO. > > I see your point; e.g the ISP resizer could be used without a sensor True. You might also be just missing the flash controller. Or you could have multiple sensors connected. > anyway, I can figure out later-on from the device topology that no sensor > is present Good. :-) -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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
[patch v3] [media] em28xx-cards: fix indenting in probe()
There was a mix of 4 space and tab indenting here which was confusing.
Signed-off-by: Dan Carpenter
---
v3: Just fix all the surrounding indents as well.
v2: At first I thought the code was buggy and was missing curly braces
but it was just the indenting which was confusing.
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index 50aa5a5..3744766 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -3416,14 +3416,14 @@ static int em28xx_usb_probe(struct usb_interface
*interface,
/* Select USB transfer types to use */
if (has_video) {
- if (!dev->analog_ep_isoc || (try_bulk && dev->analog_ep_bulk))
- dev->analog_xfer_bulk = 1;
- em28xx_info("analog set to %s mode.\n",
- dev->analog_xfer_bulk ? "bulk" : "isoc");
+ if (!dev->analog_ep_isoc || (try_bulk && dev->analog_ep_bulk))
+ dev->analog_xfer_bulk = 1;
+ em28xx_info("analog set to %s mode.\n",
+ dev->analog_xfer_bulk ? "bulk" : "isoc");
}
if (has_dvb) {
- if (!dev->dvb_ep_isoc || (try_bulk && dev->dvb_ep_bulk))
- dev->dvb_xfer_bulk = 1;
+ if (!dev->dvb_ep_isoc || (try_bulk && dev->dvb_ep_bulk))
+ dev->dvb_xfer_bulk = 1;
em28xx_info("dvb set to %s mode.\n",
dev->dvb_xfer_bulk ? "bulk" : "isoc");
--
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
Re: [PATCH v4 02/03] ARM: sunxi: Add driver for sunxi IR controller
Em Wed, 30 Apr 2014 03:58:18 -0700 (PDT)
Александр Берсенев escreveu:
> [PATCH v4 02/03] ARM: sunxi: Add driver for sunxi IR controller
>
> This patch adds driver for sunxi IR controller.
> It is based on Alexsey Shestacov's work based on the original driver
> supplied by Allwinner.
>
> Signed-off-by: Alexander Bersenev
> Signed-off-by: Alexsey Shestacov
>
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index 8fbd377..9427fad 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -343,4 +343,14 @@ config RC_ST
>
> If you're not sure, select N here.
>
> +config IR_SUNXI
> +tristate "SUNXI IR remote control"
> +depends on RC_CORE
> +depends on ARCH_SUNXI
> +---help---
> + Say Y if you want to use sunXi internal IR Controller
> +
> + To compile this driver as a module, choose M here: the module will
> + be called sunxi-ir.
> +
> endif #RC_DEVICES
> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> index f8b54ff..93cdbe9 100644
> --- a/drivers/media/rc/Makefile
> +++ b/drivers/media/rc/Makefile
> @@ -32,4 +32,5 @@ obj-$(CONFIG_IR_GPIO_CIR) += gpio-ir-recv.o
> obj-$(CONFIG_IR_IGUANA) += iguanair.o
> obj-$(CONFIG_IR_TTUSBIR) += ttusbir.o
> obj-$(CONFIG_RC_ST) += st_rc.o
> +obj-$(CONFIG_IR_SUNXI) += sunxi-ir.o
> obj-$(CONFIG_IR_IMG) += img-ir/
> diff --git a/drivers/media/rc/sunxi-ir.c b/drivers/media/rc/sunxi-ir.c
> new file mode 100644
> index 000..f051d94
> --- /dev/null
> +++ b/drivers/media/rc/sunxi-ir.c
> @@ -0,0 +1,303 @@
> +/*
> + * Driver for Allwinner sunXi IR controller
> + *
> + * Copyright (C) 2014 Alexsey Shestacov
> + * Copyright (C) 2014 Alexander Bersenev
> + *
> + * Based on sun5i-ir.c:
> + * Copyright (C) 2007-2012 Daniel Wang
> + * Allwinner Technology Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define SUNXI_IR_DEV "sunxi-ir"
> +
> +/* Registers */
> +/* IR Control */
> +#define SUNXI_IR_CTL_REG 0x00
> +/* Rx Config */
> +#define SUNXI_IR_RXCTL_REG0x10
> +/* Rx Data */
> +#define SUNXI_IR_RXFIFO_REG 0x20
> +/* Rx Interrupt Enable */
> +#define SUNXI_IR_RXINT_REG0x2C
> +/* Rx Interrupt Status */
> +#define SUNXI_IR_RXSTA_REG0x30
> +/* IR Sample Config */
> +#define SUNXI_IR_CIR_REG 0x34
> +
> +/* Bit Definition of IR_RXINTS_REG Register */
> +#define SUNXI_IR_RXINTS_RXOF BIT(0) /* Rx FIFO Overflow */
> +#define SUNXI_IR_RXINTS_RXPE BIT(1) /* Rx Packet End */
> +#define SUNXI_IR_RXINTS_RXDA BIT(4) /* Rx FIFO Data Available */
> +/* Hardware supported fifo size */
> +#define SUNXI_IR_FIFO_SIZE16
> +/* How much messages in fifo triggers IRQ */
> +#define SUNXI_IR_FIFO_TRIG8
> +/* Required frequency for IR0 or IR1 clock in CIR mode */
> +#define SUNXI_IR_BASE_CLK 800
> +/* Frequency after IR internal divider */
> +#define SUNXI_IR_CLK (SUNXI_IR_BASE_CLK / 64)
> +/* Sample period in ns */
> +#define SUNXI_IR_SAMPLE (10ul / SUNXI_IR_CLK)
> +/* Filter threshold in samples */
> +#define SUNXI_IR_RXFILT 1
> +/* Idle Threshold in samples */
> +#define SUNXI_IR_RXIDLE 20
> +/* Time after which device stops sending data in ms */
> +#define SUNXI_IR_TIMEOUT 120
> +
> +struct sunxi_ir {
> + spinlock_t ir_lock;
> + struct rc_dev *rc;
> + void __iomem*base;
> + int irq;
> + struct clk *clk;
> + struct clk *apb_clk;
> + const char *map_name;
> +};
Still badly indented. Maybe your emailer is mangling whitespaces.
The best is to use git send-email to send the patches.
Also, please c/c linux-media ML for the entire patch series, as, in general,
we generally merge all patches via one tree (typically, the tree to where the
real driver will be merged - in this case, the media tree), after getting
the needed acks from DT and arm subarch maintainers (when applicable).
I'll do a better review after the whitespace fixups.
Regards,
Mauro
> +
> +static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
> +{
> + unsigned long status;
> + unsigned char dt;
> + unsigned int cnt, rc;
> + struct sunxi_ir *ir = dev_id;
> + DEFINE_IR_RAW_EVENT(rawir);
> +
> + spin_lock_irq(&ir->ir_lock);
> +
> + status = readl(ir->base + SUNXI_IR_RXSTA_REG);
> +
> + /* clean all pending statuses */
> + writel(status | 0xff, ir->base + SUNXI_IR_RXSTA_REG);
> +
> + if (status & SUNXI_IR_RXINTS_RXDA) {
> + /* How much messages in fifo
Re: [PATCH v2 1/2] v4l: Add resolution change event.
Hi Hans,
On 04/22/14 18:22, Hans Verkuil wrote:
> On 04/21/2014 11:26 AM, Arun Kumar K wrote:
>> From: Pawel Osciak
>>
>> This event indicates that the decoder has reached a point in the stream,
>> at which the resolution changes. The userspace is expected to provide a new
>> set of CAPTURE buffers for the new format before decoding can continue.
>> The event can also be used for more generic events involving resolution
>> or format changes at runtime for all kinds of video devices.
>>
>> Signed-off-by: Pawel Osciak
>> Signed-off-by: Arun Kumar K
>> ---
>> .../DocBook/media/v4l/vidioc-subscribe-event.xml | 16
>> include/uapi/linux/videodev2.h |6 ++
>> 2 files changed, 22 insertions(+)
>>
>> diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
>> b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
>> index 5c70b61..0aec831 100644
>> --- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
>> +++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
>> @@ -155,6 +155,22 @@
>>
>>
>>
>> +V4L2_EVENT_SOURCE_CHANGE
>> +5
>> +
>> + This event is triggered when a resolution or format change
>> + is detected during runtime by the video device. It can be a
>> + runtime resolution change triggered by a video decoder or the
>> + format change happening on an HDMI connector. Application may
>> + need to reinitialize buffers before proceeding further.
>> +
>> + This event has a &v4l2-event-source-change; associated
>> + with it. This has significance only for v4l2 subdevs where the
>> + pad_num field will be updated with
>> + the pad number on which the event is triggered.
>> +
>> +
>> +
>> V4L2_EVENT_PRIVATE_START
>> 0x0800
>> Base event number for driver-private events.
>> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
>> index 6ae7bbe..12e0614 100644
>> --- a/include/uapi/linux/videodev2.h
>> +++ b/include/uapi/linux/videodev2.h
>> @@ -1733,6 +1733,7 @@ struct v4l2_streamparm {
>> #define V4L2_EVENT_EOS 2
>> #define V4L2_EVENT_CTRL 3
>> #define V4L2_EVENT_FRAME_SYNC 4
>> +#define V4L2_EVENT_SOURCE_CHANGE5
>> #define V4L2_EVENT_PRIVATE_START0x0800
>>
>> /* Payload for V4L2_EVENT_VSYNC */
>> @@ -1764,12 +1765,17 @@ struct v4l2_event_frame_sync {
>> __u32 frame_sequence;
>> };
>>
>> +struct v4l2_event_source_change {
>> +__u32 pad_num;
>> +};
>> +
>> struct v4l2_event {
>> __u32 type;
>> union {
>> struct v4l2_event_vsync vsync;
>> struct v4l2_event_ctrl ctrl;
>> struct v4l2_event_frame_syncframe_sync;
>> +struct v4l2_event_source_change source_change;
>> __u8data[64];
>> } u;
>> __u32 pending;
>>
>
> This needs to be done differently. The problem is that you really have
> multiple
> events that you want to subscribe to: one for each pad (or input: see the way
> VIDIOC_G/S_EDID maps pad to an input or output index when used with a video
> node,
> we have to support that for this event as well).
>
> What you want to do is similar to what is done for control events: there you
> can
> subscribe for a specific control and get notified when that control changes.
>
> The way that works in the event code is that the 'id' field in the v4l2_event
> struct contains that control ID, or, in this case, the pad/input/output index.
>
As I am new to v4l2-events itself, I might have some noob questions.
I understood filling pad index into id field. But for video nodes,
the application is supposed to put v4l2_buf_type in the id field?
> In the application you will subscribe to the SOURCE_CHANGE event for a
> specific
> pad/input/output index.
>
> In other words, the pad_num field should be dropped and the id field used
> instead.
>
> Assuming we will also add a 'changes' field (see my reply to the other post
> on that topic), then you should also provide replace and merge ops (see
> v4l2-ctrls.c). That way it is sufficient to use just one element when calling
> v4l2_event_subscribe(): you will never loose information since if multiple
> events arrive before the application can dequeue them, the 'changes'
> information
> will be the ORed value of all those intermediate events.
>
If I understand correctly, the implementation should go somewhat in the
following lines:
+void v4l2_event_src_replace(struct v4l2_event *old, const struct
v4l2_event *new)
+{
+ u32 old_changes = old->u.src_change.changes;
+
+ old->u.src_change = new->u.src_change;
+ old->u.src_change.changes |= old_changes;
+}
[RFC PATCH 1/4] drivers/base: add interface tracker framework
interface_tracker is a generic framework which allows to track appearance
and disappearance of different interfaces provided by kernel/driver code inside
the kernel. Examples of such interfaces: clocks, phys, regulators, drm_panel...
Interface is specified by a pair of object pointer and interface type. Object
type depends on interface type, for example interface type drm_panel determines
that object is a device_node. Object pointer is used to distinguish different
interfaces of the same type and should identify object the interface is bound
to.
Signed-off-by: Andrzej Hajda
---
drivers/base/Makefile | 2 +-
drivers/base/interface_tracker.c | 307 ++
include/linux/interface_tracker.h | 27
3 files changed, 335 insertions(+), 1 deletion(-)
create mode 100644 drivers/base/interface_tracker.c
create mode 100644 include/linux/interface_tracker.h
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 04b314e..5a45c41 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -4,7 +4,7 @@ obj-y := component.o core.o bus.o dd.o
syscore.o \
driver.o class.o platform.o \
cpu.o firmware.o init.o map.o devres.o \
attribute_container.o transport_class.o \
- topology.o container.o
+ topology.o container.o interface_tracker.o
obj-$(CONFIG_DEVTMPFS) += devtmpfs.o
obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
obj-y += power/
diff --git a/drivers/base/interface_tracker.c b/drivers/base/interface_tracker.c
new file mode 100644
index 000..3d36cba
--- /dev/null
+++ b/drivers/base/interface_tracker.c
@@ -0,0 +1,307 @@
+/*
+ * Generic framework for tracking kernel interfaces
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd
+ * Andrzej Hajda
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * interface_tracker is a generic framework which allows to track appearance
+ * and disappearance of different interfaces provided by kernel/driver code
+ * inside the kernel. Examples of such interfaces: clocks, phys, regulators,
+ * drm_panel...
+ * Interface is specified by a pair of object pointer and interface type.
Object
+ * type depends on interface type, for example interface type drm_panel
+ * determines that object is a device_node. Object pointer is used
+ * to distinguish different interfaces of the same type and should identify
+ * object the interface is bound to. For example it could be DT node,
+ * struct device...
+ *
+ * The framework provides two functions for interface providers which should be
+ * called just after interface becomes available or just before interface
+ * removal. Interface consumers can register callback which will be called when
+ * the requested interface changes its state, if during callback registration
+ * the interface is already up, notification will be sent also.
+ *
+ * The framework allows nesting calls, for example it is possible to signal one
+ * interface in tracker callback of another interface. It is done by putting
+ * every request into the queue. If the queue is empty before adding
+ * the request, the queue will be processed after, if there is already another
+ * request in the queue it means the queue is already processed by different
+ * thread so no additional action is required. With this pattern only spinlock
+ * is necessary to protect the queue. However in case of removal of either
+ * callback or interface caller should be sure that his request has been
+ * processed so framework waits until the queue becomes empty, it is done using
+ * completion mechanism.
+ * The framework functions should not be called in atomic context. Callbacks
+ * should be aware that they can be called in any time between registration and
+ * unregistration, so they should use synchronization mechanisms carefully.
+ * Callbacks should also avoid to perform time consuming tasks, the framework
+ * serializes them, so it could stall other callbacks.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+enum interface_tracker_task_id {
+ interface_tracker_task_register,
+ interface_tracker_task_unregister,
+ interface_tracker_task_ifup,
+ interface_tracker_task_ifdown,
+};
+
+struct interface_tracker_task {
+ struct list_head list;
+ enum interface_tracker_task_id task_id;
+
+ const void *object;
+ unsigned long type;
+ union {
+ struct interface_tracker_block *itb;
+ void *data;
+ };
+};
+
+struct interface_tracker_node {
+ struct list_head list;
+ struct list_head itb_head;
+ const void *object;
+ unsigned long type;
+ void *data;
+ bool ifup;
+};
+
+static LIST_HEAD(int
[RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces
Generic framework for tracking internal interfaces == Summary --- interface_tracker is a generic framework which allows to track appearance and disappearance of different interfaces provided by kernel/driver code inside the kernel. Examples of such interfaces: clocks, phys, regulators, drm_panel... Interface is specified by a pair of object pointer and interface type. Object type depends on interface type, for example interface type drm_panel determines that object is a device_node. Object pointer is used to distinguish different interfaces of the same type and should identify object the interface is bound to. For example it could be DT node, struct device,... The framework provides two functions for interface providers which should be called just after interface becomes available or just before interface removal. Interface consumers can register callback which will be called when requested interface changes its state, if during callback registration the interface is already up, notification will be sent also. The framework allows nesting calls, for example it is possible to signal one interface in tracker callback of another interface. It is done by putting every request into the queue. If the queue is empty before adding the request, the queue will be processed after, if there is already another request in the queue it means the queue is already processed by different thread so no additional action is required. With this pattern only spinlock is necessary to protect the queue. However in case of removal of either callback or interface caller should be sure that his request has been processed so framework waits until the queue becomes empty, it is done using completion mechanism. The framework functions should not be called in atomic context. Callbacks should be aware that they can be called in any time between registration and de-registration, so they should use synchronization mechanisms carefully. Callbacks should also avoid to perform time consuming tasks, the framework serializes them, so it could stall other callbacks. Use cases - The interface is very generic, there are many situations it can be useful: 1. Replacement for subsystem specific methods of publishing/unpublishing interfaces. Currently many frameworks allows only querying for presence of given interface. In such cases client can defer probing or implement interface polling, which is usually subobtimal. Additionally subsystems often do not provide methods to signal to the consumers that they are about to be destroyed. 2. Monitoring for different interfaces provided by the same object. An example should explain it better. Lets assume in device tree drm crtc device node have video link to another node, so it knows only that there is something connected to its RGB output. It can be a RGB panel (drm_panel framework), it can be an image enhancer (SoC specific framework) or it can be some signal converter (drm_encoder, drm_bridge, drm_encoder_slave...). Driver have only phandle to another node. Currently it is difficult to handle such situations in a generic way. interface_tracker should make it simple: crtc should monitor all supported interface types that appears at the device_node pointed by the phandle. Potential use cases --- Points mentioned above were the reasons for writing this framework. During development I have realized that this framework can be also useful for other tasks. 3. Replacement for deferred probing - if for some reason driver do not wants to defer but it requires given resources it can use interface_tracker. It should be possible to create an helper which will wait for appearance of all interfaces from a given list, and 'continue' probe only when all resources becomes available. 4. Replacement or helper for subsystem specific solutions: - V4L2 subdev async registration, - component framework. Both frameworks solves a problem of tracking sub-components (un-)registration by master device, it should be possible to do the same with interface_tracker framework. Some additional helpers can be convienent to make the implementation easier. 5. Cure the situation with sysfs 'unbind' property. Currently many drivers are providers of different resources/interfaces: regulators, clocks, phys, V4L2 subdevs, ... They are usually protected from module unloading by getting module reference, but there is no protection from driver unbinding using sysfs method: echo 'device' >/sys/bus/.../drivers/.../unbind. After unbind consumer stays with the pointer to non-existing object, next time it tries to use it system usually crashes. interface_tracker do not add any protection, but it adds a way to signal to the consumer that given resource will disappear. It allows to handle such situations more gently. Potential issues/extensions --- 1. Scalability - the framework serializes all tasks and callbacks. In case there are no many users
[RFC PATCH 3/4] drm/exynos/dpi: add interface tracker support
exynos_dpi uses connector polling for tracking panel presence,
this solution introduces unnecessary 10s delay before panel activation.
Moreover it is unsafe, module unloading or driver unbinding can
cause system crash. interface_tracker support solves both problems.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 58 ++---
1 file changed, 47 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 2b09c7c..4c6682f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -14,6 +14,7 @@
#include
#include
+#include
#include
#include
@@ -21,6 +22,8 @@
#include "exynos_drm_drv.h"
+static void exynos_dpi_dpms(struct exynos_drm_display *display, int mode);
+
struct exynos_dpi {
struct device *dev;
struct device_node *panel_node;
@@ -28,6 +31,7 @@ struct exynos_dpi {
struct drm_panel *panel;
struct drm_connector connector;
struct drm_encoder *encoder;
+ struct interface_tracker_block itb;
struct videomode *vm;
int dpms_mode;
@@ -41,15 +45,9 @@ exynos_dpi_detect(struct drm_connector *connector, bool
force)
struct exynos_dpi *ctx = connector_to_dpi(connector);
/* panels supported only by boot-loader are always connected */
- if (!ctx->panel_node)
+ if (ctx->vm)
return connector_status_connected;
- if (!ctx->panel) {
- ctx->panel = of_drm_find_panel(ctx->panel_node);
- if (ctx->panel)
- drm_panel_attach(ctx->panel, &ctx->connector);
- }
-
if (ctx->panel)
return connector_status_connected;
@@ -114,6 +112,28 @@ static struct drm_connector_helper_funcs
exynos_dpi_connector_helper_funcs = {
.best_encoder = exynos_dpi_best_encoder,
};
+void exynos_dpi_notifier(struct interface_tracker_block *itb,
+const void *object, unsigned long type, bool on,
+void *data)
+{
+ struct exynos_dpi *ctx = container_of(itb, struct exynos_dpi, itb);
+
+ mutex_lock(&ctx->connector.dev->mode_config.mutex);
+ if (on) {
+ ctx->panel = data;
+ drm_panel_attach(ctx->panel, &ctx->connector);
+ } else {
+ struct exynos_drm_display *display;
+
+ display = platform_get_drvdata(to_platform_device(ctx->dev));
+ exynos_dpi_dpms(display, DRM_MODE_DPMS_OFF);
+ drm_panel_detach(ctx->panel);
+ ctx->panel = NULL;
+ }
+ mutex_unlock(&ctx->connector.dev->mode_config.mutex);
+ drm_helper_hpd_irq_event(ctx->connector.dev);
+}
+
static int exynos_dpi_create_connector(struct exynos_drm_display *display,
struct drm_encoder *encoder)
{
@@ -123,10 +143,7 @@ static int exynos_dpi_create_connector(struct
exynos_drm_display *display,
ctx->encoder = encoder;
- if (ctx->panel_node)
- connector->polled = DRM_CONNECTOR_POLL_CONNECT;
- else
- connector->polled = DRM_CONNECTOR_POLL_HPD;
+ connector->polled = DRM_CONNECTOR_POLL_HPD;
ret = drm_connector_init(encoder->dev, connector,
&exynos_dpi_connector_funcs,
@@ -140,9 +157,27 @@ static int exynos_dpi_create_connector(struct
exynos_drm_display *display,
drm_sysfs_connector_add(connector);
drm_mode_connector_attach_encoder(connector, encoder);
+ if (ctx->panel_node) {
+ ctx->itb.callback = exynos_dpi_notifier;
+ interface_tracker_register(ctx->panel_node,
+ INTERFACE_TRACKER_TYPE_DRM_PANEL,
+ &ctx->itb);
+ }
+
return 0;
}
+static void exynos_dpi_display_remove(struct exynos_drm_display *display)
+{
+ struct exynos_dpi *ctx = display->ctx;
+
+ if (ctx->panel_node) {
+ interface_tracker_unregister(ctx->panel_node,
+INTERFACE_TRACKER_TYPE_DRM_PANEL,
+&ctx->itb);
+ }
+}
+
static void exynos_dpi_poweron(struct exynos_dpi *ctx)
{
if (ctx->panel)
@@ -178,6 +213,7 @@ static void exynos_dpi_dpms(struct exynos_drm_display
*display, int mode)
static struct exynos_drm_display_ops exynos_dpi_display_ops = {
.create_connector = exynos_dpi_create_connector,
+ .remove = exynos_dpi_display_remove,
.dpms = exynos_dpi_dpms
};
--
1.8.3.2
--
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
[RFC PATCH 4/4] drm/panel/ld9040: do not power off panel on removal
Panel is powered off already by connector during drm_panel_remove call.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/panel/panel-ld9040.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-ld9040.c
b/drivers/gpu/drm/panel/panel-ld9040.c
index 1f1f837..1def4b0 100644
--- a/drivers/gpu/drm/panel/panel-ld9040.c
+++ b/drivers/gpu/drm/panel/panel-ld9040.c
@@ -348,7 +348,6 @@ static int ld9040_remove(struct spi_device *spi)
{
struct ld9040 *ctx = spi_get_drvdata(spi);
- ld9040_power_off(ctx);
drm_panel_remove(&ctx->panel);
return 0;
--
1.8.3.2
--
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
[RFC PATCH 2/4] drm/panel: add interface tracker support
drm_panel framework allows only query for presence of given panel.
It also does not protect panel module from unloading and does not
provide solution for driver unbinding. interface_tracker
should solve both issues.
Signed-off-by: Andrzej Hajda
---
---
drivers/gpu/drm/drm_panel.c | 5 +
include/linux/interface_tracker.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 2ef988e..72a3c5c 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -22,6 +22,7 @@
*/
#include
+#include
#include
#include
@@ -41,6 +42,8 @@ int drm_panel_add(struct drm_panel *panel)
mutex_lock(&panel_lock);
list_add_tail(&panel->list, &panel_list);
mutex_unlock(&panel_lock);
+ interface_tracker_ifup(panel->dev->of_node,
+ INTERFACE_TRACKER_TYPE_DRM_PANEL, panel);
return 0;
}
@@ -48,6 +51,8 @@ EXPORT_SYMBOL(drm_panel_add);
void drm_panel_remove(struct drm_panel *panel)
{
+ interface_tracker_ifdown(panel->dev->of_node,
+INTERFACE_TRACKER_TYPE_DRM_PANEL, panel);
mutex_lock(&panel_lock);
list_del_init(&panel->list);
mutex_unlock(&panel_lock);
diff --git a/include/linux/interface_tracker.h
b/include/linux/interface_tracker.h
index e1eff00..0a08cba 100644
--- a/include/linux/interface_tracker.h
+++ b/include/linux/interface_tracker.h
@@ -6,6 +6,8 @@
struct list_head;
struct interface_tracker_block;
+#define INTERFACE_TRACKER_TYPE_DRM_PANEL 1
+
typedef void (*interface_tracker_fn_t)(struct interface_tracker_block *itb,
const void *object, unsigned long type,
bool on, void *data);
--
1.8.3.2
--
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
Logitech c920 exposure settings with V4L2
Hello, I am not sure my previous message was posted. So I am reposting with outputs. I am trying to change exposure settings to manual and then to aperture priority. I want to read the exposure absolute value set by the camera when its in auto (aperture priority) mode. However after I switched from manual to auto mode I keep getting the old value set my me in manual mode. This is my output. $ v4l2-ctl --device=/dev/video0 --set-ctrl=exposure_auto=1 $ v4l2-ctl --device=/dev/video0 --set-ctrl=exposure_absolute=2500 $ v4l2-ctl --device=/dev/video0 --get-ctrl=exposure_absolute exposure_absolute: 2500 $ v4l2-ctl --device=/dev/video0 --set-ctrl=exposure_auto=3 $ v4l2-ctl --device=/dev/video0 --get-ctrl=exposure_absolute exposure_absolute: 2500 Can anyone help me with this. Thanks. Asanka -- 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
Re: [PATCH v2 1/2] v4l: Add resolution change event.
On 04/30/2014 12:38 PM, Arun Kumar K wrote:
> Hi Hans,
>
>
> On 04/22/14 18:22, Hans Verkuil wrote:
>> On 04/21/2014 11:26 AM, Arun Kumar K wrote:
>>> From: Pawel Osciak
>>>
>>> This event indicates that the decoder has reached a point in the stream,
>>> at which the resolution changes. The userspace is expected to provide a new
>>> set of CAPTURE buffers for the new format before decoding can continue.
>>> The event can also be used for more generic events involving resolution
>>> or format changes at runtime for all kinds of video devices.
>>>
>>> Signed-off-by: Pawel Osciak
>>> Signed-off-by: Arun Kumar K
>>> ---
>>> .../DocBook/media/v4l/vidioc-subscribe-event.xml | 16
>>> include/uapi/linux/videodev2.h |6 ++
>>> 2 files changed, 22 insertions(+)
>>>
>>> diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
>>> b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
>>> index 5c70b61..0aec831 100644
>>> --- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
>>> +++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
>>> @@ -155,6 +155,22 @@
>>>
>>>
>>>
>>> + V4L2_EVENT_SOURCE_CHANGE
>>> + 5
>>> +
>>> + This event is triggered when a resolution or format change
>>> + is detected during runtime by the video device. It can be a
>>> + runtime resolution change triggered by a video decoder or the
>>> + format change happening on an HDMI connector. Application may
>>> + need to reinitialize buffers before proceeding further.
>>> +
>>> + This event has a &v4l2-event-source-change; associated
>>> + with it. This has significance only for v4l2 subdevs where the
>>> + pad_num field will be updated with
>>> + the pad number on which the event is triggered.
>>> +
>>> +
>>> +
>>> V4L2_EVENT_PRIVATE_START
>>> 0x0800
>>> Base event number for driver-private events.
>>> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
>>> index 6ae7bbe..12e0614 100644
>>> --- a/include/uapi/linux/videodev2.h
>>> +++ b/include/uapi/linux/videodev2.h
>>> @@ -1733,6 +1733,7 @@ struct v4l2_streamparm {
>>> #define V4L2_EVENT_EOS 2
>>> #define V4L2_EVENT_CTRL3
>>> #define V4L2_EVENT_FRAME_SYNC 4
>>> +#define V4L2_EVENT_SOURCE_CHANGE 5
>>> #define V4L2_EVENT_PRIVATE_START 0x0800
>>>
>>> /* Payload for V4L2_EVENT_VSYNC */
>>> @@ -1764,12 +1765,17 @@ struct v4l2_event_frame_sync {
>>> __u32 frame_sequence;
>>> };
>>>
>>> +struct v4l2_event_source_change {
>>> + __u32 pad_num;
>>> +};
>>> +
>>> struct v4l2_event {
>>> __u32 type;
>>> union {
>>> struct v4l2_event_vsync vsync;
>>> struct v4l2_event_ctrl ctrl;
>>> struct v4l2_event_frame_syncframe_sync;
>>> + struct v4l2_event_source_change source_change;
>>> __u8data[64];
>>> } u;
>>> __u32 pending;
>>>
>>
>> This needs to be done differently. The problem is that you really have
>> multiple
>> events that you want to subscribe to: one for each pad (or input: see the way
>> VIDIOC_G/S_EDID maps pad to an input or output index when used with a video
>> node,
>> we have to support that for this event as well).
>>
>> What you want to do is similar to what is done for control events: there you
>> can
>> subscribe for a specific control and get notified when that control changes.
>>
>> The way that works in the event code is that the 'id' field in the v4l2_event
>> struct contains that control ID, or, in this case, the pad/input/output
>> index.
>>
>
> As I am new to v4l2-events itself, I might have some noob questions.
> I understood filling pad index into id field. But for video nodes,
> the application is supposed to put v4l2_buf_type in the id field?
No, a capture video node can have multiple inputs (those are enumerated with
VIDIOC_ENUMINPUTS), and each input can generate a SOURCE_CHANGE event, even if
it
is not the currently active input. Hence the need of setting id to the input
index. v4l2_buf_type makes no sense here.
>
>> In the application you will subscribe to the SOURCE_CHANGE event for a
>> specific
>> pad/input/output index.
>>
>> In other words, the pad_num field should be dropped and the id field used
>> instead.
>>
>> Assuming we will also add a 'changes' field (see my reply to the other post
>> on that topic), then you should also provide replace and merge ops (see
>> v4l2-ctrls.c). That way it is sufficient to use just one element when calling
>> v4l2_event_subscribe(): you will never loose information since if multiple
>> events arrive before the application can dequeue them, the 'changes'
>
[PATCH v5 0/3] ARM: sunxi: Add support for consumer infrared devices
This patch introduces Consumer IR(CIR) support for sunxi boards. This is based on Alexsey Shestacov's work based on the original driver supplied by Allwinner. Signed-off-by: Alexander Bersenev Signed-off-by: Alexsey Shestacov --- Changes since version 1: - Fix timer memory leaks - Fix race condition when driver unloads while interrupt handler is active - Support Cubieboard 2(need testing) Changes since version 2: - More reliable keydown events - Documentation fixes - Rename registers accurding to A20 user manual - Remove some includes, order includes alphabetically - Use BIT macro - Typo fixes Changes since version 3: - Split the patch on smaller parts - More documentation fixes - Add clock-names in DT - Use devm_clk_get function to get the clocks - Removed gpios property from ir's DT - Changed compatible from allwinner,sunxi-ir to allwinner,sun7i-a20-ir in DT - Use spin_lock_irq instead spin_lock_irqsave in interrupt handler - Add myself in the copyright ;) - Coding style and indentation fixes Changes since version 4: - Try to fix indentation errors by sending patches with git send-mail Alexander Bersenev (3): ARM: sunxi: Add documentation for sunxi consumer infrared devices ARM: sunxi: Add driver for sunxi IR controller ARM: sunxi: Add IR controller support in DT on A20 .../devicetree/bindings/media/sunxi-ir.txt | 23 ++ arch/arm/boot/dts/sun7i-a20-cubieboard2.dts| 6 + arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 6 + arch/arm/boot/dts/sun7i-a20.dtsi | 31 +++ drivers/media/rc/Kconfig | 10 + drivers/media/rc/Makefile | 1 + drivers/media/rc/sunxi-ir.c| 303 + 7 files changed, 380 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/sunxi-ir.txt create mode 100644 drivers/media/rc/sunxi-ir.c -- 1.9.2 -- 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
[PATCH v5 2/3] ARM: sunxi: Add driver for sunxi IR controller
This patch adds driver for sunxi IR controller.
It is based on Alexsey Shestacov's work based on the original driver
supplied by Allwinner.
Signed-off-by: Alexander Bersenev
Signed-off-by: Alexsey Shestacov
---
drivers/media/rc/Kconfig| 10 ++
drivers/media/rc/Makefile | 1 +
drivers/media/rc/sunxi-ir.c | 303
3 files changed, 314 insertions(+)
create mode 100644 drivers/media/rc/sunxi-ir.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 8fbd377..9427fad 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -343,4 +343,14 @@ config RC_ST
If you're not sure, select N here.
+config IR_SUNXI
+tristate "SUNXI IR remote control"
+depends on RC_CORE
+depends on ARCH_SUNXI
+---help---
+ Say Y if you want to use sunXi internal IR Controller
+
+ To compile this driver as a module, choose M here: the module will
+ be called sunxi-ir.
+
endif #RC_DEVICES
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index f8b54ff..93cdbe9 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -32,4 +32,5 @@ obj-$(CONFIG_IR_GPIO_CIR) += gpio-ir-recv.o
obj-$(CONFIG_IR_IGUANA) += iguanair.o
obj-$(CONFIG_IR_TTUSBIR) += ttusbir.o
obj-$(CONFIG_RC_ST) += st_rc.o
+obj-$(CONFIG_IR_SUNXI) += sunxi-ir.o
obj-$(CONFIG_IR_IMG) += img-ir/
diff --git a/drivers/media/rc/sunxi-ir.c b/drivers/media/rc/sunxi-ir.c
new file mode 100644
index 000..f051d94
--- /dev/null
+++ b/drivers/media/rc/sunxi-ir.c
@@ -0,0 +1,303 @@
+/*
+ * Driver for Allwinner sunXi IR controller
+ *
+ * Copyright (C) 2014 Alexsey Shestacov
+ * Copyright (C) 2014 Alexander Bersenev
+ *
+ * Based on sun5i-ir.c:
+ * Copyright (C) 2007-2012 Daniel Wang
+ * Allwinner Technology Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define SUNXI_IR_DEV "sunxi-ir"
+
+/* Registers */
+/* IR Control */
+#define SUNXI_IR_CTL_REG 0x00
+/* Rx Config */
+#define SUNXI_IR_RXCTL_REG0x10
+/* Rx Data */
+#define SUNXI_IR_RXFIFO_REG 0x20
+/* Rx Interrupt Enable */
+#define SUNXI_IR_RXINT_REG0x2C
+/* Rx Interrupt Status */
+#define SUNXI_IR_RXSTA_REG0x30
+/* IR Sample Config */
+#define SUNXI_IR_CIR_REG 0x34
+
+/* Bit Definition of IR_RXINTS_REG Register */
+#define SUNXI_IR_RXINTS_RXOF BIT(0) /* Rx FIFO Overflow */
+#define SUNXI_IR_RXINTS_RXPE BIT(1) /* Rx Packet End */
+#define SUNXI_IR_RXINTS_RXDA BIT(4) /* Rx FIFO Data Available */
+/* Hardware supported fifo size */
+#define SUNXI_IR_FIFO_SIZE16
+/* How much messages in fifo triggers IRQ */
+#define SUNXI_IR_FIFO_TRIG8
+/* Required frequency for IR0 or IR1 clock in CIR mode */
+#define SUNXI_IR_BASE_CLK 800
+/* Frequency after IR internal divider */
+#define SUNXI_IR_CLK (SUNXI_IR_BASE_CLK / 64)
+/* Sample period in ns */
+#define SUNXI_IR_SAMPLE (10ul / SUNXI_IR_CLK)
+/* Filter threshold in samples */
+#define SUNXI_IR_RXFILT 1
+/* Idle Threshold in samples */
+#define SUNXI_IR_RXIDLE 20
+/* Time after which device stops sending data in ms */
+#define SUNXI_IR_TIMEOUT 120
+
+struct sunxi_ir {
+ spinlock_t ir_lock;
+ struct rc_dev *rc;
+ void __iomem*base;
+ int irq;
+ struct clk *clk;
+ struct clk *apb_clk;
+ const char *map_name;
+};
+
+static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
+{
+ unsigned long status;
+ unsigned char dt;
+ unsigned int cnt, rc;
+ struct sunxi_ir *ir = dev_id;
+ DEFINE_IR_RAW_EVENT(rawir);
+
+ spin_lock_irq(&ir->ir_lock);
+
+ status = readl(ir->base + SUNXI_IR_RXSTA_REG);
+
+ /* clean all pending statuses */
+ writel(status | 0xff, ir->base + SUNXI_IR_RXSTA_REG);
+
+ if (status & SUNXI_IR_RXINTS_RXDA) {
+ /* How much messages in fifo */
+ rc = (status >> 8) & 0x3f;
+ /* Sanity check */
+ rc = rc > SUNXI_IR_FIFO_SIZE ? SUNXI_IR_FIFO_SIZE : rc;
+ /* if we have data */
+ for (cnt = 0; cnt < rc; cnt++) {
+ /* for each bit in fifo */
+ dt = readb(ir->base + SUNXI_IR_RXFIFO_REG);
+ rawir.pulse = (dt & 0x80) != 0;
+ rawir.duration = (dt & 0x7f) * SUNXI_IR_SAMPLE;
+ ir_raw_event_store_with_
[PATCH v5 3/3] ARM: sunxi: Add IR controller support in DT on A20
This patch adds IR controller in A20 Device-Tree:
- Two IR devices found in A20 user manual
- Pins for two devices
- One IR device physically found on Cubieboard 2
- One IR device physically found on Cubietruck
Signed-off-by: Alexander Bersenev
Signed-off-by: Alexsey Shestacov
---
arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 6 ++
arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 6 ++
arch/arm/boot/dts/sun7i-a20.dtsi| 31 +
3 files changed, 43 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
index feeff64..2564e8c 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
@@ -164,6 +164,12 @@
reg = <1>;
};
};
+
+ ir0: ir@01c21800 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ir0_pins_a>;
+ status = "okay";
+ };
};
leds {
diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
index e288562..e375e89 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -232,6 +232,12 @@
reg = <1>;
};
};
+
+ ir0: ir@01c21800 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ir0_pins_a>;
+ status = "okay";
+ };
};
leds {
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 0ae2b77..bb655a5 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -724,6 +724,19 @@
allwinner,drive = <2>;
allwinner,pull = <0>;
};
+
+ ir0_pins_a: ir0@0 {
+ allwinner,pins = "PB3","PB4";
+ allwinner,function = "ir0";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+ ir1_pins_a: ir1@0 {
+ allwinner,pins = "PB22","PB23";
+ allwinner,function = "ir1";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
};
timer@01c20c00 {
@@ -937,5 +950,23 @@
#interrupt-cells = <3>;
interrupts = <1 9 0xf04>;
};
+
+ ir0: ir@01c21800 {
+ compatible = "allwinner,sun7i-a20-ir";
+ clocks = <&apb0_gates 6>, <&ir0_clk>;
+ clock-names = "apb", "ir";
+ interrupts = <0 5 4>;
+ reg = <0x01c21800 0x40>;
+ status = "disabled";
+ };
+
+ ir1: ir@01c21c00 {
+ compatible = "allwinner,sun7i-a20-ir";
+ clocks = <&apb0_gates 7>, <&ir1_clk>;
+ clock-names = "apb", "ir";
+ interrupts = <0 6 4>;
+ reg = <0x01C21c00 0x40>;
+ status = "disabled";
+ };
};
};
--
1.9.2
--
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
[PATCH v5 1/3] ARM: sunxi: Add documentation for sunxi consumer infrared devices
This patch adds documentation for Device-Tree bindings for sunxi IR
controller.
Signed-off-by: Alexander Bersenev
Signed-off-by: Alexsey Shestacov
---
.../devicetree/bindings/media/sunxi-ir.txt | 23 ++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/sunxi-ir.txt
diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt
b/Documentation/devicetree/bindings/media/sunxi-ir.txt
new file mode 100644
index 000..d502cf4
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
@@ -0,0 +1,23 @@
+Device-Tree bindings for SUNXI IR controller found in sunXi SoC family
+
+Required properties:
+- compatible : should be "allwinner,sun7i-a20-ir";
+- clocks : list of clock specifiers, corresponding to
+ entries in clock-names property;
+- clock-names : should contain "apb0_ir0" and "ir0" entries;
+- interrupts : should contain IR IRQ number;
+- reg : should contain IO map address for IR.
+
+Optional properties:
+- linux,rc-map-name : Remote control map name.
+
+Example:
+
+ir0: ir@01c21800 {
+ compatible = "allwinner,sun7i-a20-ir";
+ clocks = <&apb0_gates 6>, <&ir0_clk>;
+ clock-names = "apb0_ir0", "ir0";
+ interrupts = <0 5 1>;
+ reg = <0x01C21800 0x40>;
+ linux,rc-map-name = "rc-rc6-mce";
+};
--
1.9.2
--
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
Re: [RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces
On Wed, Apr 30, 2014 at 04:02:50PM +0200, Andrzej Hajda wrote: > Generic framework for tracking internal interfaces > == > > Summary > --- > > interface_tracker is a generic framework which allows to track appearance > and disappearance of different interfaces provided by kernel/driver code > inside > the kernel. Examples of such interfaces: clocks, phys, regulators, > drm_panel... > Interface is specified by a pair of object pointer and interface type. Object > type depends on interface type, for example interface type drm_panel > determines > that object is a device_node. Object pointer is used to distinguish different > interfaces of the same type and should identify object the interface is bound > to. > For example it could be DT node, struct device,... > > The framework provides two functions for interface providers which should be > called just after interface becomes available or just before interface > removal. Interface consumers can register callback which will be called > when requested interface changes its state, if during callback registration > the interface is already up, notification will be sent also. > > The framework allows nesting calls, for example it is possible to signal one > interface in tracker callback of another interface. It is done by putting > every request into the queue. If the queue is empty before adding > the request, the queue will be processed after, if there is already another > request in the queue it means the queue is already processed by different > thread so no additional action is required. With this pattern only spinlock > is necessary to protect the queue. However in case of removal of either > callback or interface caller should be sure that his request has been > processed so framework waits until the queue becomes empty, it is done using > completion mechanism. > > The framework functions should not be called in atomic context. Callbacks > should be aware that they can be called in any time between registration and > de-registration, so they should use synchronization mechanisms carefully. > Callbacks should also avoid to perform time consuming tasks, the framework > serializes them, so it could stall other callbacks. > > Use cases > - > > The interface is very generic, there are many situations it can be useful: > > 1. Replacement for subsystem specific methods of publishing/unpublishing > interfaces. Currently many frameworks allows only querying for presence of > given > interface. In such cases client can defer probing or implement interface > polling, which is usually subobtimal. Additionally subsystems often do not > provide methods to signal to the consumers that they are about to be > destroyed. > > 2. Monitoring for different interfaces provided by the same object. An example > should explain it better. Lets assume in device tree drm crtc device node have > video link to another node, so it knows only that there is something connected > to its RGB output. It can be a RGB panel (drm_panel framework), it can be an > image enhancer (SoC specific framework) or it can be some signal converter > (drm_encoder, drm_bridge, drm_encoder_slave...). Driver have only phandle to > another node. Currently it is difficult to handle such situations in a generic > way. interface_tracker should make it simple: crtc should monitor all > supported > interface types that appears at the device_node pointed by the phandle. > > Potential use cases > --- > > Points mentioned above were the reasons for writing this framework. During > development I have realized that this framework can be also useful for other > tasks. > > 3. Replacement for deferred probing - if for some reason driver do not wants > to > defer but it requires given resources it can use interface_tracker. It should > be > possible to create an helper which will wait for appearance of all interfaces > from a given list, and 'continue' probe only when all resources becomes > available. > > 4. Replacement or helper for subsystem specific solutions: > - V4L2 subdev async registration, > - component framework. > Both frameworks solves a problem of tracking sub-components (un-)registration > by master device, it should be possible to do the same with interface_tracker > framework. Some additional helpers can be convienent to make the > implementation > easier. > > 5. Cure the situation with sysfs 'unbind' property. Currently many drivers are > providers of different resources/interfaces: regulators, clocks, phys, > V4L2 subdevs, ... They are usually protected from module unloading by getting > module reference, but there is no protection from driver unbinding using sysfs > method: echo 'device' >/sys/bus/.../drivers/.../unbind. After unbind consumer > stays with the pointer to non-existing object, next time it tries to use it > system usually crashes. interface_tracker do not add any protection, but it > adds > a
[PATCH] media: parport: Fix format string mismatch in bw-qcam.c
Fix format string mismatch in bw-qcam.c
Signed-off-by: Masanari Iida
---
drivers/media/parport/bw-qcam.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/parport/bw-qcam.c b/drivers/media/parport/bw-qcam.c
index 8a0e84c..416507a 100644
--- a/drivers/media/parport/bw-qcam.c
+++ b/drivers/media/parport/bw-qcam.c
@@ -937,7 +937,7 @@ static struct qcam *qcam_init(struct parport *port)
return NULL;
v4l2_dev = &qcam->v4l2_dev;
- snprintf(v4l2_dev->name, sizeof(v4l2_dev->name), "bw-qcam%d", num_cams);
+ snprintf(v4l2_dev->name, sizeof(v4l2_dev->name), "bw-qcam%u", num_cams);
if (v4l2_device_register(port->dev, v4l2_dev) < 0) {
v4l2_err(v4l2_dev, "Could not register v4l2_device\n");
--
2.0.0.rc1
--
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
Re: [PATCH] [media] v4l2-device: fix potential NULL pointer dereference for subdev unregister path
Hi Liu,
Thank you for the patch.
On Wednesday 30 April 2014 12:25:21 Liu Ying wrote:
> The pointer 'sd->v4l2_dev' is likely to be NULL and dereferenced in the
> subdev unregister path. The issue should happen if CONFIG_MEDIA_CONTROLLER
> is defined.
>
> This patch fixes the issue by setting the pointer to be NULL after it will
> not be derefereneced any more in the path.
I'm not sure to understand the problem. Where do you see sd->v4l2_dev being
(potentially) dereferenced after being set to NULL ?
> Cc: Mauro Carvalho Chehab
> Cc: Andrzej Hajda
> Cc: Laurent Pinchart
> Cc: Sakari Ailus
> Cc: Sylwester Nawrocki
> Cc: Hans Verkuil
> Cc: linux-media@vger.kernel.org
> Signed-off-by: Liu Ying
> ---
> drivers/media/v4l2-core/v4l2-device.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-device.c
> b/drivers/media/v4l2-core/v4l2-device.c index 02d1b63..d98d96f 100644
> --- a/drivers/media/v4l2-core/v4l2-device.c
> +++ b/drivers/media/v4l2-core/v4l2-device.c
> @@ -271,7 +271,6 @@ void v4l2_device_unregister_subdev(struct v4l2_subdev
> *sd)
>
> if (sd->internal_ops && sd->internal_ops->unregistered)
> sd->internal_ops->unregistered(sd);
> - sd->v4l2_dev = NULL;
>
> #if defined(CONFIG_MEDIA_CONTROLLER)
> if (v4l2_dev->mdev) {
> @@ -279,6 +278,7 @@ void v4l2_device_unregister_subdev(struct v4l2_subdev
> *sd) media_device_unregister_entity(&sd->entity);
> }
> #endif
> + v4l2_dev = NULL;
> video_unregister_device(sd->devnode);
> module_put(sd->owner);
> }
--
Regards,
Laurent Pinchart
--
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
Re: [PATCH] omap3isp: Fix iommu domain use-after-free in isp_probe() error path
Hi Peter, Thank you for the patch. On Wednesday 30 April 2014 10:13:30 Peter Meerwald wrote: > isp_save_ctx() is called from omap3isp_put() after iommu_domain_free() in > the isp_probe() error path > > [3.205047] Unable to handle kernel NULL pointer dereference at virtual > address 003c [3.213470] pgd = c0004000 > [3.216308] [003c] *pgd= > [3.220031] Internal error: Oops: 5 [#1] PREEMPT ARM > [3.225189] Modules linked in: > [3.228363] CPU: 0Not tainted (3.7.10 #3) > [3.232971] PC is at omap2_iommu_save_ctx+0x0/0x34 > [3.237945] LR is at omap_iommu_save_ctx+0x1c/0x24 > [3.242919] pc : []lr : []psr: 6113 > ... > [3.425109] [] (omap2_iommu_save_ctx+0x0/0x34) from > [] (omap_iommu_save_ctx+0x1c/0x24) > [3.435150] [] (omap_iommu_save_ctx+0x1c/0x24) from > [] (omap3isp_put+0x84/0xfc) > [3.444519] [] (omap3isp_put+0x84/0xfc) from [] > (isp_probe+0x8d8/0xa60) > [3.453186] [] (isp_probe+0x8d8/0xa60) from [] > (platform_drv_probe+0x14/0x18) > [3.462402] [] (platform_drv_probe+0x14/0x18) from [] > (driver_probe_device+0xb0/0x1dc) > > compare isp_remove(): isp->domain is set to NULL after iommu_domain_free() > > above crash is observed with 3.7 > the issue is fixed in 3.11 (7c0f812a5d65e712618af880dda4a5cc7ed79463), > but present in 3.10 longterm Would cherry-picking commit 7c0f812a5d65e712618af880dda4a5cc7ed79463 for the 3.10 stable series make sense instead ? Otherwise, Acked-by: Laurent Pinchart > Cc: sta...@vger.kernel.org > Signed-off-by: Peter Meerwald > --- > drivers/media/platform/omap3isp/isp.c |1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/media/platform/omap3isp/isp.c > b/drivers/media/platform/omap3isp/isp.c index 1d7dbd5..a73d9d9 100644 > --- a/drivers/media/platform/omap3isp/isp.c > +++ b/drivers/media/platform/omap3isp/isp.c > @@ -2287,6 +2287,7 @@ detach_dev: > iommu_detach_device(isp->domain, &pdev->dev); > free_domain: > iommu_domain_free(isp->domain); > + isp->domain = NULL; > error_isp: > isp_xclk_cleanup(isp); > omap3isp_put(isp); -- Regards, Laurent Pinchart -- 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
Re: [RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces
Hi Greg, Thanks for comments. I CC Laurent, I hope it could be interesting for him also. Greg Kroah-Hartman wrote, On 30.04.2014 17:49: On Wed, Apr 30, 2014 at 04:02:50PM +0200, Andrzej Hajda wrote: Generic framework for tracking internal interfaces == Summary --- interface_tracker is a generic framework which allows to track appearance and disappearance of different interfaces provided by kernel/driver code inside the kernel. Examples of such interfaces: clocks, phys, regulators, drm_panel... Interface is specified by a pair of object pointer and interface type. Object type depends on interface type, for example interface type drm_panel determines that object is a device_node. Object pointer is used to distinguish different interfaces of the same type and should identify object the interface is bound to. For example it could be DT node, struct device,... The framework provides two functions for interface providers which should be called just after interface becomes available or just before interface removal. Interface consumers can register callback which will be called when requested interface changes its state, if during callback registration the interface is already up, notification will be sent also. The framework allows nesting calls, for example it is possible to signal one interface in tracker callback of another interface. It is done by putting every request into the queue. If the queue is empty before adding the request, the queue will be processed after, if there is already another request in the queue it means the queue is already processed by different thread so no additional action is required. With this pattern only spinlock is necessary to protect the queue. However in case of removal of either callback or interface caller should be sure that his request has been processed so framework waits until the queue becomes empty, it is done using completion mechanism. The framework functions should not be called in atomic context. Callbacks should be aware that they can be called in any time between registration and de-registration, so they should use synchronization mechanisms carefully. Callbacks should also avoid to perform time consuming tasks, the framework serializes them, so it could stall other callbacks. Use cases - The interface is very generic, there are many situations it can be useful: 1. Replacement for subsystem specific methods of publishing/unpublishing interfaces. Currently many frameworks allows only querying for presence of given interface. In such cases client can defer probing or implement interface polling, which is usually subobtimal. Additionally subsystems often do not provide methods to signal to the consumers that they are about to be destroyed. 2. Monitoring for different interfaces provided by the same object. An example should explain it better. Lets assume in device tree drm crtc device node have video link to another node, so it knows only that there is something connected to its RGB output. It can be a RGB panel (drm_panel framework), it can be an image enhancer (SoC specific framework) or it can be some signal converter (drm_encoder, drm_bridge, drm_encoder_slave...). Driver have only phandle to another node. Currently it is difficult to handle such situations in a generic way. interface_tracker should make it simple: crtc should monitor all supported interface types that appears at the device_node pointed by the phandle. Potential use cases --- Points mentioned above were the reasons for writing this framework. During development I have realized that this framework can be also useful for other tasks. 3. Replacement for deferred probing - if for some reason driver do not wants to defer but it requires given resources it can use interface_tracker. It should be possible to create an helper which will wait for appearance of all interfaces from a given list, and 'continue' probe only when all resources becomes available. 4. Replacement or helper for subsystem specific solutions: - V4L2 subdev async registration, - component framework. Both frameworks solves a problem of tracking sub-components (un-)registration by master device, it should be possible to do the same with interface_tracker framework. Some additional helpers can be convienent to make the implementation easier. 5. Cure the situation with sysfs 'unbind' property. Currently many drivers are providers of different resources/interfaces: regulators, clocks, phys, V4L2 subdevs, ... They are usually protected from module unloading by getting module reference, but there is no protection from driver unbinding using sysfs method: echo 'device' >/sys/bus/.../drivers/.../unbind. After unbind consumer stays with the pointer to non-existing object, next time it tries to use it system usually crashes. interface_tracker do not add any protection, but it adds a way to signal to the consumer that given resource will disappear.
Re: [RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces
On Wed, Apr 30, 2014 at 11:42:09PM +0200, Andrzej Hajda wrote: > The main problem with component framework is that componentization > significantly changes every driver and changes it in a way which is not > compatible with traditional drivers, so devices which are intended to > work with different DRM masters are hard to componentize if some of DRMs > are componentized and some not. Many of the problems which the component helpers are designed to solve are those where you need the drm_device structure (or snd_card, or whatever subsystem specific card/device representation structure) pre-created in order to initialise the components. In the case of DRM, you can't initialise encoders or connectors without their drm_device structure pre-existing - because these components are attached to the drm_device. Your solution to that is to delay those calls, but the DRM subsystem is not designed to cope like that - it's designed such that when the connector or encoder initialisation functions are called, it is assumed that the driver is initialising its state. (I've raised this point before but you've just fobbed it off in the past.) Another issue here is that the order of initialisation matters greatly. Take CRTCs for example. In DRM, the order of attachment of CRTCs defines their identity, changing the order changes their identity, and changes how they are bound to their respective connectors. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- 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
Re: [PATCH v2 01/26] omap3isp: stat: Rename IS_COHERENT_BUF to ISP_STAT_USES_DMAENGINE
Hi Laurent, Thanks for the set! I've been looking forward to see this! :) On Mon, Apr 21, 2014 at 02:28:47PM +0200, Laurent Pinchart wrote: > The macro is meant to test whether the statistics engine uses an > external DMA engine to transfer data or supports DMA directly. As both > cases will be supported by DMA coherent buffers rename the macro to > ISP_STAT_USES_DMAENGINE for improved clarity. Both use DMA, but the ISP just implements its own. How about calling the macro ISP_STAT_USES_SYSTEM_DMA instead? Up to you. -- Regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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
Re: [PATCH v2 01/26] omap3isp: stat: Rename IS_COHERENT_BUF to ISP_STAT_USES_DMAENGINE
Hi Sakari, On Thursday 01 May 2014 01:45:47 Sakari Ailus wrote: > Hi Laurent, > > Thanks for the set! I've been looking forward to see this! :) > > On Mon, Apr 21, 2014 at 02:28:47PM +0200, Laurent Pinchart wrote: > > The macro is meant to test whether the statistics engine uses an > > external DMA engine to transfer data or supports DMA directly. As both > > cases will be supported by DMA coherent buffers rename the macro to > > ISP_STAT_USES_DMAENGINE for improved clarity. > > Both use DMA, but the ISP just implements its own. How about calling the > macro ISP_STAT_USES_SYSTEM_DMA instead? Up to you. DMA engine is the Linux name for the system DMA engine API. It might indeed be slightly generic, but I'm not too sure whether ISP_STAT_USES_SYSTEM_DMA would be more descriptive. I suppose it depends on the background of the reader :-) If you insist I can change it. -- Regards, Laurent Pinchart -- 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
-- Kedves felhasználó, az e-mail;
-- Kedves felhasználó, az e-mail; Túllépte a 23.432 box set Webszolgáltatásról /, és akkor nem lesz gond a küldő és a az e-maileket kapni az újraellenőrzés-ig. Kérjük, frissítse, kattintson a gomb link, és kitölt a információ, amely a fiók igazolására Kérjük, kövesse az alábbi linkre, és másolja illessze be a böngésző címsorába ellenőriz a postaláda. http://updatewewrr.jimdo.com/ Vigyázz! Ha nem lesz csak korlátozott hozzáférést az e-mail fiókot. Ha A frissítés? a fiók három napon belül frissül Fiók értesítési tartósan le kell zárni. Üdvözlettel, a rendszer administratorh -- 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
Re: [linux-sunxi] [PATCH v5 0/3] ARM: sunxi: Add support for consumer infrared devices
Ühel kenal päeval, K, 30.04.2014 kell 21:16, kirjutas Alexander
Bersenev:
> This patch introduces Consumer IR(CIR) support for sunxi boards.
>
> This is based on Alexsey Shestacov's work based on the original driver
> supplied by Allwinner.
>
> Signed-off-by: Alexander Bersenev
> Signed-off-by: Alexsey Shestacov
> ---
> Changes since version 1:
> - Fix timer memory leaks
> - Fix race condition when driver unloads while interrupt handler is active
> - Support Cubieboard 2(need testing)
>
> Changes since version 2:
> - More reliable keydown events
> - Documentation fixes
> - Rename registers accurding to A20 user manual
> - Remove some includes, order includes alphabetically
> - Use BIT macro
> - Typo fixes
>
> Changes since version 3:
> - Split the patch on smaller parts
> - More documentation fixes
> - Add clock-names in DT
> - Use devm_clk_get function to get the clocks
> - Removed gpios property from ir's DT
> - Changed compatible from allwinner,sunxi-ir to allwinner,sun7i-a20-ir in DT
> - Use spin_lock_irq instead spin_lock_irqsave in interrupt handler
> - Add myself in the copyright ;)
> - Coding style and indentation fixes
>
> Changes since version 4:
> - Try to fix indentation errors by sending patches with git send-mail
git am still complains due to mixed tabs-spaces used for indentation
> Alexander Bersenev (3):
> ARM: sunxi: Add documentation for sunxi consumer infrared devices
Applying: ARM: sunxi: Add documentation for sunxi consumer infrared devices
/usr/src/linux/.git/rebase-apply/patch:28: space before tab in indent.
compatible = "allwinner,sun7i-a20-ir";
/usr/src/linux/.git/rebase-apply/patch:29: space before tab in indent.
clocks = <&apb0_gates 6>, <&ir0_clk>;
/usr/src/linux/.git/rebase-apply/patch:30: space before tab in indent.
clock-names = "apb0_ir0", "ir0";
/usr/src/linux/.git/rebase-apply/patch:31: space before tab in indent.
interrupts = <0 5 1>;
/usr/src/linux/.git/rebase-apply/patch:32: space before tab in indent.
reg = <0x01C21800 0x40>;
> ARM: sunxi: Add driver for sunxi IR controller
OK
> ARM: sunxi: Add IR controller support in DT on A20
Applying: ARM: sunxi: Add IR controller support in DT on A20
/usr/src/linux/.git/rebase-apply/patch:70: space before tab in indent.
ir0: ir@01c21800 {
/usr/src/linux/.git/rebase-apply/patch:71: space before tab in indent.
compatible = "allwinner,sun7i-a20-ir";
/usr/src/linux/.git/rebase-apply/patch:79: space before tab in indent.
ir1: ir@01c21c00 {
/usr/src/linux/.git/rebase-apply/patch:80: space before tab in indent.
compatible = "allwinner,sun7i-a20-ir";
--
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
