Re: [PATCH 1/5] [media] media-device: get rid of the spinlock
Hello Mauro, On Wed, Mar 16, 2016 at 9:04 AM, Mauro Carvalho Chehab wrote: > Right now, the lock schema for media_device struct is messy, > since sometimes, it is protected via a spin lock, while, for > media graph traversal, it is protected by a mutex. > > Solve this conflict by always using a mutex. > > As a side effect, this prevents a bug where the media notifiers > were called at atomic context. > > Signed-off-by: Mauro Carvalho Chehab > --- I agree with the patch. Reviewed-by: Javier Martinez Canillas Best regards, Javier -- 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] media: rename media unregister function
Shuah Khan wrote: > On 03/18/2016 08:12 AM, Javier Martinez Canillas wrote: >> Hello Shuah, >> >> On 03/18/2016 11:01 AM, Shuah Khan wrote: >>> On 03/18/2016 07:05 AM, Mauro Carvalho Chehab wrote: Now that media_device_unregister() also does a cleanup, rename it to media_device_unregister_cleanup(). Signed-off-by: Mauro Carvalho Chehab >>> >>> I think adding cleanup is redundant. media_device_unregister() >>> would imply that there has to be some cleanup releasing resources. >>> I wouldn't make this change. >>> >> >> Problem is that there is a media_device_init() and media_device_register(), >> so having both unregister and cleanup in this function will make very clear >> that a single function is the counter part of the previous two operations. >> > > Yes. I realized that this change is motivated by the fact that there is > the media_device_init() and we had the counterpart media_device_cleanup() > as an exported function. I still think there is no need to make the change > to add _cleanup() at the end of media_device_unregister(). It can be handled > in API documentation that it does both. I think that's a bad idea. People will only read the documentation when something doesn't work. In this case it's easy to miss that. -- Sakari Ailus sakari.ai...@linux.intel.com -- 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
[PATCHv13 13/17] cec: adv7842: add cec support
Add CEC support to the adv7842 driver.
Signed-off-by: Hans Verkuil
---
drivers/media/i2c/Kconfig | 2 +-
drivers/media/i2c/adv7842.c | 331 +++-
2 files changed, 270 insertions(+), 63 deletions(-)
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 3d01ffc..11ca81c 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -220,7 +220,7 @@ config VIDEO_ADV7604
config VIDEO_ADV7842
tristate "Analog Devices ADV7842 decoder"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && MEDIA_CEC
select HDMI
---help---
Support for the Analog Devices ADV7842 video decoder.
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index 7ccb85d..d12abe0 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -79,6 +80,8 @@ MODULE_LICENSE("GPL");
#define ADV7842_OP_SWAP_CB_CR (1 << 0)
+#define ADV7842_MAX_ADDRS (3)
+
/*
**
*
@@ -142,6 +145,10 @@ struct adv7842_state {
struct v4l2_ctrl *free_run_color_ctrl_manual;
struct v4l2_ctrl *free_run_color_ctrl;
struct v4l2_ctrl *rgb_quantization_range_ctrl;
+
+ u8 cec_addr[ADV7842_MAX_ADDRS];
+ u8 cec_valid_addrs;
+ bool cec_enabled_adap;
};
/* Unsupported timings. This device cannot support 720p30. */
@@ -418,9 +425,9 @@ static inline int cec_write(struct v4l2_subdev *sd, u8 reg,
u8 val)
return adv_smbus_write_byte_data(state->i2c_cec, reg, val);
}
-static inline int cec_write_and_or(struct v4l2_subdev *sd, u8 reg, u8 mask, u8
val)
+static inline int cec_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask,
u8 val)
{
- return cec_write(sd, reg, (cec_read(sd, reg) & mask) | val);
+ return cec_write(sd, reg, (cec_read(sd, reg) & ~mask) | val);
}
static inline int infoframe_read(struct v4l2_subdev *sd, u8 reg)
@@ -696,6 +703,18 @@ adv7842_get_dv_timings_cap(struct v4l2_subdev *sd)
/* --- */
+static u16 adv7842_read_cable_det(struct v4l2_subdev *sd)
+{
+ u8 reg = io_read(sd, 0x6f);
+ u16 val = 0;
+
+ if (reg & 0x02)
+ val |= 1; /* port A */
+ if (reg & 0x01)
+ val |= 2; /* port B */
+ return val;
+}
+
static void adv7842_delayed_work_enable_hotplug(struct work_struct *work)
{
struct delayed_work *dwork = to_delayed_work(work);
@@ -703,8 +722,13 @@ static void adv7842_delayed_work_enable_hotplug(struct
work_struct *work)
struct adv7842_state, delayed_work_enable_hotplug);
struct v4l2_subdev *sd = &state->sd;
int present = state->hdmi_edid.present;
+ u16 connected_inputs;
u8 mask = 0;
+ connected_inputs = present & adv7842_read_cable_det(sd);
+ v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_CONN_INPUTS,
+ &connected_inputs);
+
v4l2_dbg(2, debug, sd, "%s: enable hotplug on ports: 0x%x\n",
__func__, present);
@@ -762,50 +786,17 @@ static int edid_write_vga_segment(struct v4l2_subdev *sd)
return 0;
}
-static int edid_spa_location(const u8 *edid)
-{
- u8 d;
-
- /*
-* TODO, improve and update for other CEA extensions
-* currently only for 1 segment (256 bytes),
-* i.e. 1 extension block and CEA revision 3.
-*/
- if ((edid[0x7e] != 1) ||
- (edid[0x80] != 0x02) ||
- (edid[0x81] != 0x03)) {
- return -EINVAL;
- }
- /*
-* search Vendor Specific Data Block (tag 3)
-*/
- d = edid[0x82] & 0x7f;
- if (d > 4) {
- int i = 0x84;
- int end = 0x80 + d;
- do {
- u8 tag = edid[i]>>5;
- u8 len = edid[i] & 0x1f;
-
- if ((tag == 3) && (len >= 5))
- return i + 4;
- i += len + 1;
- } while (i < end);
- }
- return -EINVAL;
-}
-
static int edid_write_hdmi_segment(struct v4l2_subdev *sd, u8 port)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct adv7842_state *state = to_state(sd);
- const u8 *val = state->hdmi_edid.edid;
- int spa_loc = edid_spa_location(val);
+ const u8 *edid = state->hdmi_edid.edid;
+ int spa_loc;
int err = 0;
int i;
- v4l2_dbg(2, debug, sd, "%s: write EDID on port %c (spa at 0x%x)\n",
- __func__, (port == ADV7842_EDID_PORT_A) ? 'A' : 'B',
spa_loc);
+ v4l2_dbg(2, debug, sd, "%s: write EDID on port %c\n",
+
[PATCH 2/2] media/dvb-core: forward media_create_pad_links() return value
Signed-off-by: Max Kellermann
---
drivers/media/dvb-core/dvbdev.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c
index c756d4b..96de2fa 100644
--- a/drivers/media/dvb-core/dvbdev.c
+++ b/drivers/media/dvb-core/dvbdev.c
@@ -677,13 +677,13 @@ int dvb_create_media_graph(struct dvb_adapter *adap,
demux, 0, MEDIA_LNK_FL_ENABLED,
false);
if (ret)
- return -ENOMEM;
+ return ret;
}
if (demux && ca) {
ret = media_create_pad_link(demux, 1, ca,
0, MEDIA_LNK_FL_ENABLED);
if (ret)
- return -ENOMEM;
+ return ret;
}
/* Create demux links for each ringbuffer/pad */
--
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
[RFCv1 PATCH 2/2] tc358840: add CEC support
From: Hans Verkuil
Signed-off-by: Hans Verkuil
---
drivers/media/i2c/Kconfig | 2 +-
drivers/media/i2c/tc358840.c | 212 +--
drivers/media/i2c/tc358840_regs.h | 301 --
3 files changed, 396 insertions(+), 119 deletions(-)
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 1fd6057..3243218 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -309,7 +309,7 @@ config VIDEO_TC358743
config VIDEO_TC358840
tristate "Toshiba TC358840 decoder"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && MEDIA_CEC
select HDMI
---help---
Support for the Toshiba TC358840 HDMI to MIPI CSI-2 bridge.
diff --git a/drivers/media/i2c/tc358840.c b/drivers/media/i2c/tc358840.c
index 5ce7155..3d5ff98 100644
--- a/drivers/media/i2c/tc358840.c
+++ b/drivers/media/i2c/tc358840.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include
#include "tc358840_regs.h"
@@ -74,6 +75,7 @@ struct tc358840_state {
struct media_pad pad[2];
struct v4l2_ctrl_handler hdl;
struct i2c_client *i2c_client;
+ struct cec_adapter *cec_adap;
bool enabled;
/* controls */
@@ -694,6 +696,7 @@ static void tc358840_set_ref_clk(struct v4l2_subdev *sd)
u32 sys_freq;
u32 lock_ref_freq;
+ u32 cec_freq;
u32 nco;
u16 csc;
@@ -723,6 +726,15 @@ static void tc358840_set_ref_clk(struct v4l2_subdev *sd)
csc = pdata->refclk_hz / 1;
i2c_wr8(sd, SCLK_CSC0, csc & 0xFF);
i2c_wr8(sd, SCLK_CSC1, (csc >> 8) & 0xFF);
+
+ /*
+* Trial and error suggests that the default register value
+* of 656 is for a 42 MHz reference clock. Use that to derive
+* a new value based on the actual reference clock.
+*/
+ cec_freq = (656 * sys_freq) / 4200;
+ i2c_wr16(sd, CECHCLK, cec_freq);
+ i2c_wr16(sd, CECLCLK, cec_freq);
}
static void tc358840_set_csi_mbus_config(struct v4l2_subdev *sd)
@@ -1051,6 +1063,99 @@ static void tc358840_initial_setup(struct v4l2_subdev
*sd)
i2c_wr8_and_or(sd, VI_MODE, ~MASK_RGB_DVI, 0);
}
+/* --- CEC --- */
+
+static int tc358840_cec_adap_enable(struct cec_adapter *adap, bool enable)
+{
+ struct tc358840_state *state = adap->priv;
+ struct v4l2_subdev *sd = &state->sd;
+
+ i2c_wr32(sd, CECIMSK, enable ? MASK_CECTIM | MASK_CECRIM : 0);
+ i2c_wr32(sd, CECICLR, MASK_CECTICLR | MASK_CECRICLR);
+ i2c_wr32(sd, CECEN, enable);
+ if (enable)
+ i2c_wr32(sd, CECREN, MASK_CECREN);
+ return 0;
+}
+
+static int tc358840_cec_adap_monitor_all_enable(struct cec_adapter *adap,
+ bool enable)
+{
+ struct tc358840_state *state = adap->priv;
+ struct v4l2_subdev *sd = &state->sd;
+ u32 reg;
+
+ reg = i2c_rd32(sd, CECRCTL1);
+ if (enable)
+ reg |= MASK_CECOTH;
+ else
+ reg &= ~MASK_CECOTH;
+ i2c_wr32(sd, CECRCTL1, reg);
+ return 0;
+}
+
+static int tc358840_cec_adap_log_addr(struct cec_adapter *adap, u8 log_addr)
+{
+ struct tc358840_state *state = adap->priv;
+ struct v4l2_subdev *sd = &state->sd;
+ unsigned la = 0;
+
+ if (log_addr != CEC_LOG_ADDR_INVALID) {
+ la = i2c_rd32(sd, CECADD);
+ la |= 1 << log_addr;
+ }
+ i2c_wr32(sd, CECADD, la);
+ return 0;
+}
+
+static int tc358840_cec_adap_transmit(struct cec_adapter *adap, u8 attempts,
+ u32 signal_free_time, struct cec_msg *msg)
+{
+ struct tc358840_state *state = adap->priv;
+ struct v4l2_subdev *sd = &state->sd;
+ unsigned i;
+
+ i2c_wr32(sd, CECTCTL,
+(cec_msg_is_broadcast(msg) ? MASK_CECBRD : 0) |
+(signal_free_time - 1));
+ for (i = 0; i < msg->len; i++)
+ i2c_wr32(sd, CECTBUF1 + i * 4,
+msg->msg[i] | ((i == msg->len - 1) ? MASK_CECTEOM :
0));
+ i2c_wr32(sd, CECTEN, MASK_CECTEN);
+ return 0;
+}
+
+static int tc358840_received(struct cec_adapter *adap, struct cec_msg *msg)
+{
+ struct cec_msg reply;
+ u16 pa;
+
+ cec_msg_init(&reply, adap->log_addr[0], cec_msg_initiator(msg));
+
+ switch (msg->msg[1]) {
+ case CEC_MSG_SET_STREAM_PATH:
+ if (!adap->is_source)
+ return -ENOMSG;
+ cec_ops_set_stream_path(msg, &pa);
+ if (pa != adap->phys_addr)
+ return -ENOMSG;
+ cec_msg_active_source(&reply, adap->phys_addr);
+ cec_transmit_msg(adap, &reply, false);
+ break;
+ default:
+ return -ENOMSG;
+ }
+ return 0;
+}
+
+sta
Re: [PATCH 4/5] [media] media-device: use kref for media_device instance
Em Thu, 17 Mar 2016 13:50:53 +0200
Sakari Ailus escreveu:
> Hi Mauro,
>
> On Wed, Mar 16, 2016 at 09:04:05AM -0300, Mauro Carvalho Chehab wrote:
> > Now that the media_device can be used by multiple drivers,
> > via devres, we need to be sure that it will be dropped only
> > when all drivers stop using it.
>
> Not long ago we split media device initialisation and registration into two.
> The intent with that was to prevent users from seeing the media device until
> all the initialisation is finished. I suppose that with dynamic updates, or
> media device being shared with two drivers, it might be difficult to achieve
> that. At least the method has to be different.
>
> media_device_init() and media_device_cleanup() were a pair where the latter
> undid the first.
Yes, this patch breaks the balance of _init()/_cleanup(), but this is for
a greater good. It is very hard to remove the devnode and cleanup the
media_device struct when multiple drivers can use it. The best way to
warrant that we'll be doing that is via kref.
> This patchs remove the requirement of calling cleanup
> explitly, breaking that model. It's perhaps not a big problem, there is
> likely no single driver which would initialise the media controller device
> once but would register and unregister it multiple times. I still wonder if
> we really lost something important if we removed media_device_init() and
> media_device_cleanup() altogether and merged the functionality in
> media_device_{,un}register().
>
> Cc Javier who wrote the patch.
That patch was written to avoid a race trouble of having the media
devnode to initialize too early. Merging them back would cause troubles.
Maybe what we could do, instead, is to rename media_device_init()
to media_device_register(), and call the function that creates the
devnode as media_device_create_devnode().
What do you think?
>
> commit 9832e155f1ed3030fdfaa19e72c06472dc2ecb1d
> Author: Javier Martinez Canillas
> Date: Fri Dec 11 20:57:08 2015 -0200
>
> [media] media-device: split media initialization and registration
>
> For system-wide media device, I think we'd need to introduce a new concept,
> graph, that would define an interconnected set of entities. This would
> mainly be needed for callbacks, e.g. the power on / off sequences of the
> entities could be specific to V4L as discussed earlier. With this approach
> hacks wouldn't be needed to be made in the first place to support two drivers
> sharing a media device.
>
> What was the original reason you needed to share the media device btw.?
>
> >
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> > drivers/media/media-device.c | 48
> > +++-
> > include/media/media-device.h | 3 +++
> > 2 files changed, 37 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> > index c32fa15cc76e..38e6c319fe6e 100644
> > --- a/drivers/media/media-device.c
> > +++ b/drivers/media/media-device.c
> > @@ -721,6 +721,15 @@ int __must_check __media_device_register(struct
> > media_device *mdev,
> > {
> > int ret;
> >
> > + /* Check if mdev was ever registered at all */
> > + mutex_lock(&mdev->graph_mutex);
> > + if (media_devnode_is_registered(&mdev->devnode)) {
> > + kref_get(&mdev->kref);
> > + mutex_unlock(&mdev->graph_mutex);
> > + return 0;
> > + }
> > + kref_init(&mdev->kref);
> > +
> > /* Register the device node. */
> > mdev->devnode.fops = &media_device_fops;
> > mdev->devnode.parent = mdev->dev;
> > @@ -730,8 +739,10 @@ int __must_check __media_device_register(struct
> > media_device *mdev,
> > mdev->topology_version = 0;
> >
> > ret = media_devnode_register(&mdev->devnode, owner);
> > - if (ret < 0)
> > + if (ret < 0) {
> > + media_devnode_unregister(&mdev->devnode);
> > return ret;
> > + }
> >
> > ret = device_create_file(&mdev->devnode.dev, &dev_attr_model);
> > if (ret < 0) {
> > @@ -739,6 +750,7 @@ int __must_check __media_device_register(struct
> > media_device *mdev,
> > return ret;
> > }
> >
> > + mutex_unlock(&mdev->graph_mutex);
> > dev_dbg(mdev->dev, "Media device registered\n");
> >
> > return 0;
> > @@ -773,23 +785,15 @@ void media_device_unregister_entity_notify(struct
> > media_device *mdev,
> > }
> > EXPORT_SYMBOL_GPL(media_device_unregister_entity_notify);
> >
> > -void media_device_unregister(struct media_device *mdev)
> > +static void do_media_device_unregister(struct kref *kref)
> > {
> > + struct media_device *mdev;
> > struct media_entity *entity;
> > struct media_entity *next;
> > struct media_interface *intf, *tmp_intf;
> > struct media_entity_notify *notify, *nextp;
> >
> > - if (mdev == NULL)
> > - return;
> > -
> > - mutex_lock(&mdev->graph_mutex);
> > -
> > - /* Check if mdev was ever registered at all */
> > - if (!media
[PATCH] libdvbv5: Fix dvb-format-convert segfault
Fixes dvb-format-convert crashing when encountering an
unrecognised polarization value.
Signed-off-by: Edward Sheldrake
---
lib/libdvbv5/dvb-file.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/libdvbv5/dvb-file.c b/lib/libdvbv5/dvb-file.c
index 3fda65f..fc2bebc 100644
--- a/lib/libdvbv5/dvb-file.c
+++ b/lib/libdvbv5/dvb-file.c
@@ -648,8 +648,8 @@ static int fill_entry(struct dvb_entry *entry, char *key,
char *value)
else if (!strcasecmp(key, "AUDIO_PID"))
is_audio = 1;
else if (!strcasecmp(key, "POLARIZATION")) {
- for (j = 0; ARRAY_SIZE(dvb_sat_pol_name); j++)
- if (!strcasecmp(value, dvb_sat_pol_name[j]))
+ for (j = 0; j < ARRAY_SIZE(dvb_sat_pol_name); j++)
+ if (dvb_sat_pol_name[j] && !strcasecmp(value,
dvb_sat_pol_name[j]))
break;
if (j == ARRAY_SIZE(dvb_sat_pol_name))
return -2;
--
2.5.0
--
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
[PATCHv13 02/17] dts: exynos4: add node for the HDMI CEC device
From: Kamil Debski
This patch adds HDMI CEC node specific to the Exynos4210/4x12 SoC series.
Signed-off-by: Kamil Debski
Signed-off-by: Hans Verkuil
Acked-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 045785c..8913408 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -751,6 +751,18 @@
status = "disabled";
};
+ hdmicec: cec@100B {
+ compatible = "samsung,s5p-cec";
+ reg = <0x100B 0x200>;
+ interrupts = <0 114 0>;
+ clocks = <&clock CLK_HDMI_CEC>;
+ clock-names = "hdmicec";
+ samsung,syscon-phandle = <&pmu_system_controller>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_cec>;
+ status = "disabled";
+ };
+
mixer: mixer@12C1 {
compatible = "samsung,exynos4210-mixer";
interrupts = <0 91 0>;
--
2.7.0
--
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
[PATCHv13 09/17] cec.txt: add CEC framework documentation
From: Hans Verkuil Document the new HDMI CEC framework. Signed-off-by: Hans Verkuil [k.deb...@samsung.com: add DocBook documentation by Hans Verkuil, with Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- Documentation/cec.txt | 391 ++ 1 file changed, 391 insertions(+) create mode 100644 Documentation/cec.txt diff --git a/Documentation/cec.txt b/Documentation/cec.txt new file mode 100644 index 000..71b508a --- /dev/null +++ b/Documentation/cec.txt @@ -0,0 +1,391 @@ +CEC Kernel Support +== + +The CEC framework provides a unified kernel interface for use with HDMI CEC +hardware. It is designed to handle a multiple types of hardware (receivers, +transmitters, USB dongles). The framework also gives the option to decide +what to do in the kernel driver and what should be handled by userspace +applications. In addition it integrates the remote control passthrough +feature into the kernel's remote control framework. + + +The CEC Protocol + + +The CEC protocol enables consumer electronic devices to communicate with each +other through the HDMI connection. The protocol uses logical addresses in the +communication. The logical address is strictly connected with the functionality +provided by the device. The TV acting as the communication hub is always +assigned address 0. The physical address is determined by the physical +connection between devices. + +The CEC framework described here is up to date with the CEC 2.0 specification. +It is documented in the HDMI 1.4 specification with the new 2.0 bits documented +in the HDMI 2.0 specification. But for most of the features the freely available +HDMI 1.3a specification is sufficient: + +http://www.microprocessor.org/HDMISpecification13a.pdf + + +The Kernel Interface + + +CEC Adapter +--- + +The struct cec_adapter represents the CEC adapter hardware. It is created by +calling cec_create_adapter() and deleted by calling cec_delete_adapter(): + +struct cec_adapter *cec_create_adapter(const struct cec_adap_ops *ops, + void *priv, const char *name, u32 caps, + u8 ninputs, struct device *parent); +void cec_delete_adapter(struct cec_adapter *adap); + +To create an adapter you need to pass the following information: + +ops: adapter operations which are called by the CEC framework and that you +have to implement. + +priv: will be stored in adap->priv and can be used by the adapter ops. + +name: the name of the CEC adapter. Note: this name will be copied. + +caps: capabilities of the CEC adapter. These capabilities determine the + capabilities of the hardware and which parts are to be handled + by userspace and which parts are handled by kernelspace. The + capabilities are returned by CEC_ADAP_G_CAPS. + +ninputs: the number of HDMI inputs of the device. This may be 0. This + is returned by CEC_ADAP_G_CAPS. + +parent: the parent device. + + +After creating the adapter the driver can modify the following fields +in struct cec_adapter: + + u8 available_log_addrs; + +This determines the number of simultaneous logical addresses the hardware +can program. Often this is 1, which is also the default. + + u8 pwr_state; + +The CEC_MSG_GIVE_DEVICE_POWER_STATUS power state. By default this is +CEC_OP_POWER_STATUS_ON (0). The driver can change this to signal power +state transitions. + + u16 phys_addr; + +By default this is 0x, but drivers can change this using the cec_set_phys_addr +function. The phys_addr field must be set before the CEC adapter is enabled (see +the adap_enable op below). While the CEC adapter remains enabled it cannot be +changed. Drivers never set this if CEC_CAP_PHYS_ADDR is set. + + u32 vendor_id; + +By default this is CEC_VENDOR_ID_NONE (0x). It should not be changed +once the adapter is configured. Drivers never set this if CEC_CAP_VENDOR_ID +is set. + + u8 cec_version; + +The CEC version that the framework should support. By default this is the +latest version, but it can be changed to an older version, causing attempts +to use later extensions to fail. Obviously this should be set before the +CEC adapter is enabled. + +To register the /dev/cecX device node and the remote control device (if +CEC_CAP_RC is set) you call: + +int cec_register_adapter(struct cec_adapter *adap); + +To unregister the devices call: + +void cec_unregister_adapter(struct cec_adapter *adap); + +Note: if cec_register_adapter() fails, then call cec_delete_adapter() to +clean up. But if cec_register_adapter() succeeded, then only call +cec_unregister_adapter() to clean up, never cec_delete_adapter(). The +unregister function will delete the adapter automatically once the last user +of that /dev/cecX device has closed its file handle. + + +Implementing the Low-Level CEC Adapter +-- + +The following low-level adapter operations have to be i
[PATCH 2/2] [media] media-device: make topology_version u64
The uAPI defines it with 64 bits. Let's change the Kernel
implementation too.
Signed-off-by: Mauro Carvalho Chehab
---
include/media/media-device.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/media/media-device.h b/include/media/media-device.h
index 9166bff8068e..4a475604d992 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -358,7 +358,7 @@ struct media_device {
u32 hw_revision;
u32 driver_version;
- u32 topology_version;
+ u64 topology_version;
u32 id;
struct ida entity_internal_idx;
--
2.5.0
--
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: [PATCHv13 01/17] dts: exynos4*: add HDMI CEC pin definition to pinctrl
On 03/19/2016 03:50 AM, Krzysztof Kozlowski wrote: > On Fri, Mar 18, 2016 at 03:07:00PM +0100, Hans Verkuil wrote: >> From: Kamil Debski >> >> Add pinctrl nodes for the HDMI CEC device to the Exynos4210 and >> Exynos4x12 SoCs. These are required by the HDMI CEC device. >> >> Signed-off-by: Kamil Debski >> Signed-off-by: Hans Verkuil >> Acked-by: Krzysztof Kozlowski >> --- >> arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 7 +++ >> arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 7 +++ >> 2 files changed, 14 insertions(+) > > Hi Hans, > > I see you have been carrying these three patches for a long time. > Initially I thought that there are some dependencies... but maybe there > are not? > > Can I take these Exynos DTS patches to samsung-soc? That would be very nice! BTW, it would be nice if someone from Samsung could try to improve the s5p CEC driver from this patch series. The problem is that it expects userspace to tell it the physical address, which is read from the EDID. But the HDMI driver in the kernel already knows this, so requiring userspace to handle this is not nice. Basically the CEC driver needs to know when a new EDID has been read and when the hotplug detect goes low (EDID has been lost). If someone who actually knows the HDMI code could provide me with a patch, then I can fix the CEC driver. I have an odroid to test with, so I can check the code. Regards, Hans -- 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
[PATCHv13 10/17] DocBook/media: add CEC documentation
Add DocBook documentation for the CEC API. Signed-off-by: Hans Verkuil [k.deb...@samsung.com: add documentation for passthrough mode] [k.deb...@samsung.com: minor fixes and change of reserved field sizes] Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- Documentation/DocBook/device-drivers.tmpl | 3 + Documentation/DocBook/media/Makefile | 2 + Documentation/DocBook/media/v4l/biblio.xml | 10 + Documentation/DocBook/media/v4l/cec-api.xml| 75 + Documentation/DocBook/media/v4l/cec-func-close.xml | 59 Documentation/DocBook/media/v4l/cec-func-ioctl.xml | 73 + Documentation/DocBook/media/v4l/cec-func-open.xml | 94 +++ Documentation/DocBook/media/v4l/cec-func-poll.xml | 89 ++ .../DocBook/media/v4l/cec-ioc-adap-g-caps.xml | 174 .../DocBook/media/v4l/cec-ioc-adap-g-log-addrs.xml | 306 + .../DocBook/media/v4l/cec-ioc-adap-g-phys-addr.xml | 81 ++ .../DocBook/media/v4l/cec-ioc-adap-g-state.xml | 88 ++ .../DocBook/media/v4l/cec-ioc-adap-g-vendor-id.xml | 71 + .../DocBook/media/v4l/cec-ioc-adap-log-status.xml | 51 .../DocBook/media/v4l/cec-ioc-dqevent.xml | 280 +++ Documentation/DocBook/media/v4l/cec-ioc-g-mode.xml | 286 +++ .../DocBook/media/v4l/cec-ioc-receive.xml | 261 ++ Documentation/DocBook/media_api.tmpl | 6 +- 18 files changed, 2008 insertions(+), 1 deletion(-) create mode 100644 Documentation/DocBook/media/v4l/cec-api.xml create mode 100644 Documentation/DocBook/media/v4l/cec-func-close.xml create mode 100644 Documentation/DocBook/media/v4l/cec-func-ioctl.xml create mode 100644 Documentation/DocBook/media/v4l/cec-func-open.xml create mode 100644 Documentation/DocBook/media/v4l/cec-func-poll.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-adap-g-caps.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-adap-g-log-addrs.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-adap-g-phys-addr.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-adap-g-state.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-adap-g-vendor-id.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-adap-log-status.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-dqevent.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-mode.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-receive.xml diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index cc303a2..9db705d 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -269,6 +269,9 @@ X!Isound/sound_firmware.c !Iinclude/media/media-devnode.h !Iinclude/media/media-entity.h + Consumer Electronics Control devices +!Iinclude/media/cec.h + diff --git a/Documentation/DocBook/media/Makefile b/Documentation/DocBook/media/Makefile index 2840ff4..497b57e 100644 --- a/Documentation/DocBook/media/Makefile +++ b/Documentation/DocBook/media/Makefile @@ -64,6 +64,7 @@ IOCTLS = \ $(shell perl -ne 'print "$$1 " if /\#define\s+([A-Z][^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/net.h) \ $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/video.h) \ $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/media.h) \ + $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/cec.h) \ $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/v4l2-subdev.h) \ DEFINES = \ @@ -100,6 +101,7 @@ STRUCTS = \ $(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/ && !/_old/)' $(srctree)/include/uapi/linux/dvb/net.h) \ $(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' $(srctree)/include/uapi/linux/dvb/video.h) \ $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/media.h) \ + $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/cec.h) \ $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/v4l2-subdev.h) \ $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/v4l2-mediabus.h) diff --git a/Documentation/DocBook/media/v4l/biblio.xml b/Documentation/DocBook/media/v4l/biblio.xml index 9beb30f..87f1d24 100644 --- a/Documentation/DocBook/media/v4l/biblio.xml +++ b/Documentation/DocBook/media/v4l/biblio.xml @@ -342,6 +342,16 @@ in the frequency range from 87,5 to 108,0 MHz Specification Version 1.4a + + HDMI2 + + HDMI Licensing LLC +(http://www.hdmi.org";>http://www.hdmi.org) + + High-Defi
Re: [PATCH] media: fix media_device_unregister() to destroy media device device resource
On 03/18/2016 03:52 AM, Mauro Carvalho Chehab wrote:
> Em Thu, 17 Mar 2016 16:46:36 -0600
> Shuah Khan escreveu:
>
>> When all drivers except usb-core driver is unbound, destroy the media device
>> resource. Other wise, media device resource will persist in a defunct state.
>> This leads to use-after-free and bad access errors during a subsequent bind.
>> Fix it to destroy the media device resource when last reference is released
>> in media_device_unregister().
>>
>> Signed-off-by: Shuah Khan
>> ---
>> drivers/media/media-device.c | 28 ++--
>> 1 file changed, 22 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
>> index 070421e..7312612 100644
>> --- a/drivers/media/media-device.c
>> +++ b/drivers/media/media-device.c
>> @@ -822,22 +822,38 @@ printk("%s: mdev=%p\n", __func__, mdev);
>> dev_dbg(mdev->dev, "Media device unregistered\n");
>> }
>>
>> +static void media_device_release_devres(struct device *dev, void *res)
>> +{
>> +}
>> +
>> +static void media_device_destroy_devres(struct device *dev)
>> +{
>> +int ret;
>> +
>> +ret = devres_destroy(dev, media_device_release_devres, NULL, NULL);
>> +pr_debug("%s: devres_destroy() returned %d\n", __func__, ret);
>> +}
>> +
>> void media_device_unregister(struct media_device *mdev)
>> {
>> +int ret;
>> +struct device *dev;
>> printk("%s: mdev=%p\n", __func__, mdev);
>> if (mdev == NULL)
>> return;
>>
>> -mutex_lock(&mdev->graph_mutex);
>> -kref_put(&mdev->kref, do_media_device_unregister);
>> -mutex_unlock(&mdev->graph_mutex);
>> +ret = kref_put_mutex(&mdev->kref, do_media_device_unregister,
>> + &mdev->graph_mutex);
>> +if (ret) {
>> +/* do_media_device_unregister() has run */
>> +dev = mdev->dev;
>> +mutex_unlock(&mdev->graph_mutex);
>
>
>> +media_device_destroy_devres(dev);
>
> This doesn't seem right: what happens on drivers that don't use
> devres to allocate struct media_device?
>
That is okay. devres_destroy() won't find the resource. The way it works
is it will try to find the resource with the match routine and data and
that step will fail it will return -ENOENT. At that point nothing more
is done.
ret = devres_destroy(dev, media_device_release_devres, NULL, NULL);
pr_debug("%s: devres_destroy() returned %d\n", __func__, ret);
devres_destroy() combines the devres_find() and remove. So we are good
here.
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
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
我的照片在:
你的老朋友邀你来Q群:343257759
Re: [PATCH] [media] media: rename media unregister function
Em Fri, 18 Mar 2016 16:20:19 +0200 Sakari Ailus escreveu: > Shuah Khan wrote: > > On 03/18/2016 08:12 AM, Javier Martinez Canillas wrote: > >> Hello Shuah, > >> > >> On 03/18/2016 11:01 AM, Shuah Khan wrote: > >>> On 03/18/2016 07:05 AM, Mauro Carvalho Chehab wrote: > Now that media_device_unregister() also does a cleanup, rename it > to media_device_unregister_cleanup(). > > Signed-off-by: Mauro Carvalho Chehab > >>> > >>> I think adding cleanup is redundant. media_device_unregister() > >>> would imply that there has to be some cleanup releasing resources. > >>> I wouldn't make this change. > >>> > >> > >> Problem is that there is a media_device_init() and media_device_register(), > >> so having both unregister and cleanup in this function will make very clear > >> that a single function is the counter part of the previous two operations. > >> > > > > Yes. I realized that this change is motivated by the fact that there is > > the media_device_init() and we had the counterpart media_device_cleanup() > > as an exported function. I still think there is no need to make the change > > to add _cleanup() at the end of media_device_unregister(). It can be handled > > in API documentation that it does both. > > I think that's a bad idea. People will only read the documentation when > something doesn't work. In this case it's easy to miss that. After thinking about that, I guess the best is to use kref only if the media_device_*devres functions are used. With this, we don't need to touch at media_device_cleanup(). Just the patch to the ML: https://patchwork.linuxtv.org/patch/33533/ It was tested with HVR-950Q. Regards, Mauro -- 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 4/5] [media] media-device: use kref for media_device instance
Em Wed, 16 Mar 2016 08:05:15 -0600
Shuah Khan escreveu:
> On 03/16/2016 06:04 AM, Mauro Carvalho Chehab wrote:
> > Now that the media_device can be used by multiple drivers,
> > via devres, we need to be sure that it will be dropped only
> > when all drivers stop using it.
> >
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> > drivers/media/media-device.c | 48
> > +++-
> > include/media/media-device.h | 3 +++
> > 2 files changed, 37 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> > index c32fa15cc76e..38e6c319fe6e 100644
> > --- a/drivers/media/media-device.c
> > +++ b/drivers/media/media-device.c
> > @@ -721,6 +721,15 @@ int __must_check __media_device_register(struct
> > media_device *mdev,
> > {
> > int ret;
> >
> > + /* Check if mdev was ever registered at all */
> > + mutex_lock(&mdev->graph_mutex);
> > + if (media_devnode_is_registered(&mdev->devnode)) {
> > + kref_get(&mdev->kref);
> > + mutex_unlock(&mdev->graph_mutex);
> > + return 0;
> > + }
> > + kref_init(&mdev->kref);
> > +
> > /* Register the device node. */
> > mdev->devnode.fops = &media_device_fops;
> > mdev->devnode.parent = mdev->dev;
> > @@ -730,8 +739,10 @@ int __must_check __media_device_register(struct
> > media_device *mdev,
> > mdev->topology_version = 0;
> >
> > ret = media_devnode_register(&mdev->devnode, owner);
> > - if (ret < 0)
> > + if (ret < 0) {
> > + media_devnode_unregister(&mdev->devnode);
> > return ret;
> > + }
> >
> > ret = device_create_file(&mdev->devnode.dev, &dev_attr_model);
> > if (ret < 0) {
> > @@ -739,6 +750,7 @@ int __must_check __media_device_register(struct
> > media_device *mdev,
> > return ret;
> > }
> >
> > + mutex_unlock(&mdev->graph_mutex);
> > dev_dbg(mdev->dev, "Media device registered\n");
> >
> > return 0;
> > @@ -773,23 +785,15 @@ void media_device_unregister_entity_notify(struct
> > media_device *mdev,
> > }
> > EXPORT_SYMBOL_GPL(media_device_unregister_entity_notify);
> >
> > -void media_device_unregister(struct media_device *mdev)
> > +static void struct kref *kref)
> > {
> > + struct media_device *mdev;
> > struct media_entity *entity;
> > struct media_entity *next;
> > struct media_interface *intf, *tmp_intf;
> > struct media_entity_notify *notify, *nextp;
> >
> > - if (mdev == NULL)
> > - return;
> > -
> > - mutex_lock(&mdev->graph_mutex);
> > -
> > - /* Check if mdev was ever registered at all */
> > - if (!media_devnode_is_registered(&mdev->devnode)) {
> > - mutex_unlock(&mdev->graph_mutex);
> > - return;
> > - }
> > + mdev = container_of(kref, struct media_device, kref);
> >
> > /* Remove all entities from the media device */
> > list_for_each_entry_safe(entity, next, &mdev->entities, graph_obj.list)
> > @@ -807,13 +811,26 @@ void media_device_unregister(struct media_device
> > *mdev)
> > kfree(intf);
> > }
> >
> > - mutex_unlock(&mdev->graph_mutex);
> > + /* Check if mdev devnode was registered */
> > + if (!media_devnode_is_registered(&mdev->devnode))
> > + return;
> >
> > device_remove_file(&mdev->devnode.dev, &dev_attr_model);
> > media_devnode_unregister(&mdev->devnode);
>
> Patch looks good.
>
> Reviewed-by: Shuah Khan
>
> Please see a few comments below that aren't related to this patch.
>
> The above is unprotected and could be done twice when two drivers
> call media_device_unregister(). I think we still mark the media
> device unregistered in media_devnode_unregister(). We have to
> protect these two steps still.
>
> I attempted to do this with a unregister in progress flag which
> gets set at the beginning in media_device_unregister(). That
> does ensure media_device_unregister() runs only once. If that
> approach isn't desirable, we have to find another way.
Do you mean do_media_device_unregister()? This is protected, as
this function is only called via media_device_unregister(),
with the mutex hold. I opted to take the mutex there, as
it makes the return code simpler.
>
> -- Shuah
> >
> > dev_dbg(mdev->dev, "Media device unregistered\n");
> > }
> > +
> > +void media_device_unregister(struct media_device *mdev)
> > +{
> > + if (mdev == NULL)
> > + return;
> > +
> > + mutex_lock(&mdev->graph_mutex);
> > + kref_put(&mdev->kref, do_media_device_unregister);
> > + mutex_unlock(&mdev->graph_mutex);
> > +
> > +}
> > EXPORT_SYMBOL_GPL(media_device_unregister);
> >
> > static void media_device_release_devres(struct device *dev, void *res)
> > @@ -825,13 +842,16 @@ struct media_device *media_device_get_devres(struct
> > device *dev)
> > struct media_device *mdev;
> >
> > mdev = devres_find(dev, media_device_release_devres, NULL, NULL);
> > - if (mdev)
> > +
Re: [PATCH] media: rc: remove unneeded mutex in rc_register_device
On 16.03.2016 20:53, Heiner Kallweit wrote:
> Access to dev->initialized is atomic, therefore we don't have to
> protect it with a mutex.
Mutexes are used to split the code to mutually exclusive execution blocks,
so not arguing about the apparently correct change itself I want to
emphasize that the given explanation of the change in the commit message is
wrong. Atomic access does not cancel a specific care about execution
ordering.
Indirectly it applies to ("rc-core: allow calling rc_open with device not
initialized"), where "initialized" bool property was changed to atomic_t
type --- this (sub-)change is just useless.
Please grasp the topic and reword the commit message.
> Signed-off-by: Heiner Kallweit
> ---
> drivers/media/rc/rc-main.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
> index 4e9bbe7..68541b1 100644
> --- a/drivers/media/rc/rc-main.c
> +++ b/drivers/media/rc/rc-main.c
> @@ -1492,9 +1492,7 @@ int rc_register_device(struct rc_dev *dev)
> }
>
> /* Allow the RC sysfs nodes to be accessible */
> - mutex_lock(&dev->lock);
> atomic_set(&dev->initialized, 1);
> - mutex_unlock(&dev->lock);
>
> IR_dprintk(1, "Registered rc%u (driver: %s, remote: %s, mode %s)\n",
> dev->minor,
>
--
With best wishes,
Vladimir
--
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] Add tw5864 driver
On Mon, Mar 14, 2016 at 03:55:14AM +0200, Andrey Utkin wrote: > From: Andrey Utkin > > Support for boards based on Techwell TW5864 chip which provides > multichannel video & audio grabbing and encoding (H.264, MJPEG, > ADPCM G.726). > > Signed-off-by: Andrey Utkin > Tested-by: Andrey Utkin > --- > MAINTAINERS |7 + > drivers/staging/media/Kconfig|2 + > drivers/staging/media/Makefile |1 + > drivers/staging/media/tw5864/Kconfig | 11 + > drivers/staging/media/tw5864/Makefile|3 + > drivers/staging/media/tw5864/tw5864-bs.h | 154 ++ > drivers/staging/media/tw5864/tw5864-config.c | 359 + > drivers/staging/media/tw5864/tw5864-core.c | 453 ++ > drivers/staging/media/tw5864/tw5864-h264.c | 183 +++ > drivers/staging/media/tw5864/tw5864-reg.h| 2200 > ++ > drivers/staging/media/tw5864/tw5864-tables.h | 237 +++ > drivers/staging/media/tw5864/tw5864-video.c | 1364 > drivers/staging/media/tw5864/tw5864.h| 280 > include/linux/pci_ids.h |1 + > 14 files changed, 5255 insertions(+) > create mode 100644 drivers/staging/media/tw5864/Kconfig > create mode 100644 drivers/staging/media/tw5864/Makefile > create mode 100644 drivers/staging/media/tw5864/tw5864-bs.h > create mode 100644 drivers/staging/media/tw5864/tw5864-config.c > create mode 100644 drivers/staging/media/tw5864/tw5864-core.c > create mode 100644 drivers/staging/media/tw5864/tw5864-h264.c > create mode 100644 drivers/staging/media/tw5864/tw5864-reg.h > create mode 100644 drivers/staging/media/tw5864/tw5864-tables.h > create mode 100644 drivers/staging/media/tw5864/tw5864-video.c > create mode 100644 drivers/staging/media/tw5864/tw5864.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index 409509d..7bb1fa9 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -11195,6 +11195,13 @@ T: git git://linuxtv.org/media_tree.git > S: Odd fixes > F: drivers/media/usb/tm6000/ > > +TW5864 VIDEO4LINUX DRIVER > +M: Bluecherry Maintainers I wonder if this the right thing to do. Generally speaking a maintainer is a person and not a corporate. > +M: Andrey Utkin > +L: linux-media@vger.kernel.org > +S: Supported > +F: drivers/staging/media/tw5864/ > + > --- /dev/null > +++ b/drivers/staging/media/tw5864/tw5864-bs.h > @@ -0,0 +1,154 @@ > +/* > + * TW5864 driver - Exp-Golomb code functions > + * > + * Copyright (C) 2015 Bluecherry, LLC > + * Author: Andrey Utkin You don't need to state your name here. It is written in git log. -- 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] media: rename media unregister function
Hello Mauro, On 03/18/2016 10:05 AM, Mauro Carvalho Chehab wrote: > Now that media_device_unregister() also does a cleanup, rename it > to media_device_unregister_cleanup(). > I believe there should be a Suggested-by Sakari Ailus tag here. > Signed-off-by: Mauro Carvalho Chehab The patch looks good and I agree that makes things more clear. Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- 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] sound/usb: Fix memory leak in media_snd_stream_delete() during unbind
Adding Takashi Iwai
On 03/16/2016 08:58 PM, Shuah Khan wrote:
> media_snd_stream_delete() fails to release resources during unbind. This
> leads to use-after-free in media_gobj_create() on a subsequent bind.
>
> [ 1445.086410] BUG: KASAN: use-after-free in media_gobj_create+0x3a1/0x470
> [media] at addr 8801ead49998
>
> [ 1445.086771] Call Trace:
> [ 1445.086779] [] dump_stack+0x67/0x94
> [ 1445.086785] [] print_trailer+0xf9/0x150
> [ 1445.086790] [] object_err+0x34/0x40
> [ 1445.086796] [] kasan_report_error+0x221/0x530
> [ 1445.086803] [] __asan_report_store8_noabort+0x43/0x50
> [ 1445.086813] [] ? media_gobj_create+0x3a1/0x470 [media]
> [ 1445.086822] [] media_gobj_create+0x3a1/0x470 [media]
> [ 1445.086831] [] media_device_register_entity+0x259/0x6f0
> [media]
> [ 1445.086841] [] ?
> media_device_unregister_entity_notify+0x100/0x100 [media]
> [ 1445.086846] [] ? ___slab_alloc+0x172/0x500
> [ 1445.086854] [] ? mark_held_locks+0xc8/0x120
> [ 1445.086859] [] ? __slab_alloc+0x50/0x70
> [ 1445.086878] [] ? media_snd_mixer_init+0x16c/0x500
> [snd_usb_audio]
> [ 1445.086884] [] ? kasan_unpoison_shadow+0x36/0x50
> [ 1445.086890] [] ? kasan_unpoison_shadow+0x36/0x50
> [ 1445.086895] [] ? kasan_kmalloc+0x5e/0x70
>
> Signed-off-by: Shuah Khan
> ---
> sound/usb/media.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/usb/media.c b/sound/usb/media.c
> index 44a5de9..0d03773 100644
> --- a/sound/usb/media.c
> +++ b/sound/usb/media.c
> @@ -135,7 +135,7 @@ void media_snd_stream_delete(struct snd_usb_substream
> *subs)
> if (mctl && mctl->media_dev) {
> struct media_device *mdev;
>
> - mdev = subs->stream->chip->media_dev;
> + mdev = mctl->media_dev;
> if (mdev && media_devnode_is_registered(&mdev->devnode)) {
> media_devnode_remove(mctl->intf_devnode);
> media_device_unregister_entity(&mctl->media_entity);
>
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
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: fix media_device_unregister() to destroy media device device resource
Em Thu, 17 Mar 2016 16:46:36 -0600
Shuah Khan escreveu:
> When all drivers except usb-core driver is unbound, destroy the media device
> resource. Other wise, media device resource will persist in a defunct state.
> This leads to use-after-free and bad access errors during a subsequent bind.
> Fix it to destroy the media device resource when last reference is released
> in media_device_unregister().
>
> Signed-off-by: Shuah Khan
> ---
> drivers/media/media-device.c | 28 ++--
> 1 file changed, 22 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index 070421e..7312612 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -822,22 +822,38 @@ printk("%s: mdev=%p\n", __func__, mdev);
> dev_dbg(mdev->dev, "Media device unregistered\n");
> }
>
> +static void media_device_release_devres(struct device *dev, void *res)
> +{
> +}
> +
> +static void media_device_destroy_devres(struct device *dev)
> +{
> + int ret;
> +
> + ret = devres_destroy(dev, media_device_release_devres, NULL, NULL);
> + pr_debug("%s: devres_destroy() returned %d\n", __func__, ret);
> +}
> +
> void media_device_unregister(struct media_device *mdev)
> {
> + int ret;
> + struct device *dev;
> printk("%s: mdev=%p\n", __func__, mdev);
> if (mdev == NULL)
> return;
>
> - mutex_lock(&mdev->graph_mutex);
> - kref_put(&mdev->kref, do_media_device_unregister);
> - mutex_unlock(&mdev->graph_mutex);
> + ret = kref_put_mutex(&mdev->kref, do_media_device_unregister,
> + &mdev->graph_mutex);
> + if (ret) {
> + /* do_media_device_unregister() has run */
> + dev = mdev->dev;
> + mutex_unlock(&mdev->graph_mutex);
> + media_device_destroy_devres(dev);
This doesn't seem right: what happens on drivers that don't use
devres to allocate struct media_device?
> + }
>
> }
> EXPORT_SYMBOL_GPL(media_device_unregister);
>
> -static void media_device_release_devres(struct device *dev, void *res)
> -{
> -}
>
> struct media_device *media_device_get_devres(struct device *dev)
> {
--
Thanks,
Mauro
--
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
[PATCHv13 17/17] vivid: add CEC emulation
The vivid driver has been extended to provide CEC adapters for the HDMI input and HDMI outputs in order to test CEC applications. This CEC emulation is faithful to the CEC timings (i.e., it all at a snail's pace). Signed-off-by: Hans Verkuil --- Documentation/video4linux/vivid.txt | 36 ++- drivers/media/platform/vivid/Kconfig | 1 + drivers/media/platform/vivid/vivid-core.c| 361 ++- drivers/media/platform/vivid/vivid-core.h| 27 ++ drivers/media/platform/vivid/vivid-kthread-cap.c | 11 + drivers/media/platform/vivid/vivid-vid-cap.c | 31 ++ drivers/media/platform/vivid/vivid-vid-common.c | 7 + 7 files changed, 460 insertions(+), 14 deletions(-) diff --git a/Documentation/video4linux/vivid.txt b/Documentation/video4linux/vivid.txt index e35d376..0d89715 100644 --- a/Documentation/video4linux/vivid.txt +++ b/Documentation/video4linux/vivid.txt @@ -74,7 +74,8 @@ Section 11: Cropping, Composing, Scaling Section 12: Formats Section 13: Capture Overlay Section 14: Output Overlay -Section 15: Some Future Improvements +Section 15: CEC (Consumer Electronics Control) +Section 16: Some Future Improvements Section 1: Configuring the driver @@ -364,7 +365,11 @@ For HDMI inputs it is possible to set the EDID. By default a simple EDID is provided. You can only set the EDID for HDMI inputs. Internally, however, the EDID is shared between all HDMI inputs. -No interpretation is done of the EDID data. +No interpretation is done of the EDID data with the exception of the +physical address. See the CEC section for more details. + +There is a maximum of 15 HDMI inputs (if there are more, then they will be +reduced to 15) since that's the limitation of the EDID physical address. Section 3: Video Output @@ -409,6 +414,9 @@ standard, and for all others a 1:1 pixel aspect ratio is returned. An HDMI output has a valid EDID which can be obtained through VIDIOC_G_EDID. +There is a maximum of 15 HDMI outputs (if there are more, then they will be +reduced to 15) since that's the limitation of the EDID physical address. See +also the CEC section for more details. Section 4: VBI Capture -- @@ -1108,7 +1116,26 @@ capabilities will slow down the video loop considerably as a lot of checks have to be done per pixel. -Section 15: Some Future Improvements +Section 15: CEC (Consumer Electronics Control) +-- + +If there are HDMI inputs then a CEC adapter will be created that has +the same number of input ports. This is the equivalent of e.g. a TV that +has that number of inputs. Each HDMI output will also create a +CEC adapter that is hooked up to the corresponding input port, or (if there +are more outputs than inputs) is not hooked up at all. In other words, +this is the equivalent of hooking up each output device to an input port of +the TV. Any remaining output devices remain unconnected. + +The EDID that each output reads reports a unique CEC physical address that is +based on the physical address of the EDID of the input. So if the EDID of the +receiver has physical address A.B.0.0, then each output will see an EDID +containing physical address A.B.C.0 where C is 1 to the number of inputs. If +there are more outputs than inputs then the remaining outputs have a CEC adapter +that is disabled and reports an invalid physical address. + + +Section 16: Some Future Improvements Just as a reminder and in no particular order: @@ -1121,8 +1148,6 @@ Just as a reminder and in no particular order: - Fix sequence/field numbering when looping of video with alternate fields - Add support for V4L2_CID_BG_COLOR for video outputs - Add ARGB888 overlay support: better testing of the alpha channel -- Add custom DV timings support -- Add support for V4L2_DV_FL_REDUCED_FPS - Improve pixel aspect support in the tpg code by passing a real v4l2_fract - Use per-queue locks and/or per-device locks to improve throughput - Add support to loop from a specific output to a specific input across @@ -1133,3 +1158,4 @@ Just as a reminder and in no particular order: - Make a thread for the RDS generation, that would help in particular for the "Controls" RDS Rx I/O Mode as the read-only RDS controls could be updated in real-time. +- Changing the EDID should cause hotplug detect emulation to happen. diff --git a/drivers/media/platform/vivid/Kconfig b/drivers/media/platform/vivid/Kconfig index 0885e93..8645bb6 100644 --- a/drivers/media/platform/vivid/Kconfig +++ b/drivers/media/platform/vivid/Kconfig @@ -6,6 +6,7 @@ config VIDEO_VIVID select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT + select MEDIA_CEC select VIDEOBUF2_VMALLOC default n ---help--- diff --git a/drivers/media/platform/vivid/vivid-core.c b/drivers/media/platform/vivid/vivid-core.c index ec125bec..777807d 100
[PATCH] sound/usb: Fix memory leak in media_snd_stream_delete() during unbind
media_snd_stream_delete() fails to release resources during unbind. This
leads to use-after-free in media_gobj_create() on a subsequent bind.
[ 1445.086410] BUG: KASAN: use-after-free in media_gobj_create+0x3a1/0x470
[media] at addr 8801ead49998
[ 1445.086771] Call Trace:
[ 1445.086779] [] dump_stack+0x67/0x94
[ 1445.086785] [] print_trailer+0xf9/0x150
[ 1445.086790] [] object_err+0x34/0x40
[ 1445.086796] [] kasan_report_error+0x221/0x530
[ 1445.086803] [] __asan_report_store8_noabort+0x43/0x50
[ 1445.086813] [] ? media_gobj_create+0x3a1/0x470 [media]
[ 1445.086822] [] media_gobj_create+0x3a1/0x470 [media]
[ 1445.086831] [] media_device_register_entity+0x259/0x6f0
[media]
[ 1445.086841] [] ?
media_device_unregister_entity_notify+0x100/0x100 [media]
[ 1445.086846] [] ? ___slab_alloc+0x172/0x500
[ 1445.086854] [] ? mark_held_locks+0xc8/0x120
[ 1445.086859] [] ? __slab_alloc+0x50/0x70
[ 1445.086878] [] ? media_snd_mixer_init+0x16c/0x500
[snd_usb_audio]
[ 1445.086884] [] ? kasan_unpoison_shadow+0x36/0x50
[ 1445.086890] [] ? kasan_unpoison_shadow+0x36/0x50
[ 1445.086895] [] ? kasan_kmalloc+0x5e/0x70
Signed-off-by: Shuah Khan
---
sound/usb/media.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/usb/media.c b/sound/usb/media.c
index 44a5de9..0d03773 100644
--- a/sound/usb/media.c
+++ b/sound/usb/media.c
@@ -135,7 +135,7 @@ void media_snd_stream_delete(struct snd_usb_substream *subs)
if (mctl && mctl->media_dev) {
struct media_device *mdev;
- mdev = subs->stream->chip->media_dev;
+ mdev = mctl->media_dev;
if (mdev && media_devnode_is_registered(&mdev->devnode)) {
media_devnode_remove(mctl->intf_devnode);
media_device_unregister_entity(&mctl->media_entity);
--
2.5.0
--
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 1/5] [media] media-device: get rid of the spinlock
Em Wed, 16 Mar 2016 09:53:12 -0300 Javier Martinez Canillas escreveu: > Hello Mauro, > > On Wed, Mar 16, 2016 at 9:04 AM, Mauro Carvalho Chehab > wrote: > > Right now, the lock schema for media_device struct is messy, > > since sometimes, it is protected via a spin lock, while, for > > media graph traversal, it is protected by a mutex. > > > > Solve this conflict by always using a mutex. > > > > As a side effect, this prevents a bug where the media notifiers > > were called at atomic context. > > > > Signed-off-by: Mauro Carvalho Chehab Btw, I'm running a stress test here, doing bind/unbind on au0828, while calling mc_nextgen_test: Running one instance of this loop: $ i=0; while :; do i=$((i+1)); echo "loop $i"; sudo su -c "echo 1-3.1.2:1.0 > /sys/bus/usb/drivers/au0828/bind"; sudo su -c "echo 1-3.1.2:1.0 > /sys/bus/usb/drivers/au0828/unbind"; done and 3 instances of this loop: $ while :; do clear; mc_nextgen_test; done My test machine has 4 CPUs, so this should be enough to check if the mutexes at ioctl and at the register/unregister functions are ok. Right now, the loop ran 160 times. Not a single trouble. Ok, it is not doing any graph traversal ops, but the code seems to be pretty much reliable with mutexes. I'll keep it running for more time to be sure, but it seems that the current media core works fine for dynamic entity/interface/link addition/removal. Regards, Mauro > > --- > > I agree with the patch. > > Reviewed-by: Javier Martinez Canillas > > Best regards, > Javier > -- > 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 -- Thanks, Mauro -- 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] dma-buf, drm, ion: Propagate error code from dma_buf_start_cpu_access()
On Fri, Mar 18, 2016 at 08:02:39PM +, Chris Wilson wrote:
> Drivers, especially i915.ko, can fail during the initial migration of a
> dma-buf for CPU access. However, the error code from the driver was not
> being propagated back to ioctl and so userspace was blissfully ignorant
> of the failure. Rendering corruption ensues.
>
> Whilst fixing the ioctl to return the error code from
> dma_buf_start_cpu_access(), also do the same for
> dma_buf_end_cpu_access(). For most drivers, dma_buf_end_cpu_access()
> cannot fail. i915.ko however, as most drivers would, wants to avoid being
> uninterruptible (as would be required to guarrantee no failure when
> flushing the buffer to the device). As userspace already has to handle
> errors from the SYNC_IOCTL, take advantage of this to be able to restart
> the syscall across signals.
>
> This fixes a coherency issue for i915.ko as well as reducing the
> uninterruptible hold upon its BKL, the struct_mutex.
>
> Fixes commit c11e391da2a8fe973c3c2398452000bed505851e
> Author: Daniel Vetter
> Date: Thu Feb 11 20:04:51 2016 -0200
>
> dma-buf: Add ioctls to allow userspace to flush
>
> Testcase: igt/gem_concurrent_blit/*dmabuf*interruptible
> Testcase: igt/prime_mmap_coherency/ioctl-errors
> Signed-off-by: Chris Wilson
> Cc: Tiago Vignatti
> Cc: Stéphane Marchesin
> Cc: David Herrmann
> Cc: Sumit Semwal
> Cc: Daniel Vetter
> CC: linux-media@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: intel-...@lists.freedesktop.org
> Cc: de...@driverdev.osuosl.org
Applied to drm-misc, I'll send a pull to Dave the next few days if no one
screams.
-Daniel
> ---
> drivers/dma-buf/dma-buf.c | 17 +++--
> drivers/gpu/drm/i915/i915_gem_dmabuf.c| 15 +--
> drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 5 +++--
> drivers/gpu/drm/udl/udl_fb.c | 4 ++--
> drivers/staging/android/ion/ion.c | 6 --
> include/linux/dma-buf.h | 6 +++---
> 6 files changed, 28 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 9810d1df0691..774a60f4309a 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -259,6 +259,7 @@ static long dma_buf_ioctl(struct file *file,
> struct dma_buf *dmabuf;
> struct dma_buf_sync sync;
> enum dma_data_direction direction;
> + int ret;
>
> dmabuf = file->private_data;
>
> @@ -285,11 +286,11 @@ static long dma_buf_ioctl(struct file *file,
> }
>
> if (sync.flags & DMA_BUF_SYNC_END)
> - dma_buf_end_cpu_access(dmabuf, direction);
> + ret = dma_buf_end_cpu_access(dmabuf, direction);
> else
> - dma_buf_begin_cpu_access(dmabuf, direction);
> + ret = dma_buf_begin_cpu_access(dmabuf, direction);
>
> - return 0;
> + return ret;
> default:
> return -ENOTTY;
> }
> @@ -613,13 +614,17 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
> *
> * This call must always succeed.
> */
> -void dma_buf_end_cpu_access(struct dma_buf *dmabuf,
> - enum dma_data_direction direction)
> +int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
> +enum dma_data_direction direction)
> {
> + int ret = 0;
> +
> WARN_ON(!dmabuf);
>
> if (dmabuf->ops->end_cpu_access)
> - dmabuf->ops->end_cpu_access(dmabuf, direction);
> + ret = dmabuf->ops->end_cpu_access(dmabuf, direction);
> +
> + return ret;
> }
> EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> index 1f3eef6fb345..0506016e18e0 100644
> --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> @@ -228,25 +228,20 @@ static int i915_gem_begin_cpu_access(struct dma_buf
> *dma_buf, enum dma_data_dire
> return ret;
> }
>
> -static void i915_gem_end_cpu_access(struct dma_buf *dma_buf, enum
> dma_data_direction direction)
> +static int i915_gem_end_cpu_access(struct dma_buf *dma_buf, enum
> dma_data_direction direction)
> {
> struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> struct drm_device *dev = obj->base.dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - bool was_interruptible;
> int ret;
>
> - mutex_lock(&dev->struct_mutex);
> - was_interruptible = dev_priv->mm.interruptible;
> - dev_priv->mm.interruptible = false;
> + ret = i915_mutex_lock_interruptible(dev);
> + if (ret)
> + return ret;
>
> ret = i915_gem_object_set_to_gtt_domain(obj, false);
> -
> - dev_priv->mm.interruptible = was_interruptible;
> mutex_unlock(&dev->struct_mutex);
>
> - if (unlikely(ret))
> - DRM_E
Re: [PATCH] sound/usb: fix to release stream resources from media_snd_device_delete()
Em Fri, 18 Mar 2016 23:57:08 -0300
Mauro Carvalho Chehab escreveu:
> Em Fri, 18 Mar 2016 20:50:31 -0600
> Shuah Khan escreveu:
>
> > Fix to release stream resources from media_snd_device_delete() before
> > media device is unregistered. Without this change, stream resource free
> > is attempted after the media device is unregistered which would result
> > in use-after-free errors.
> >
> > Signed-off-by: Shuah Khan
> > ---
> >
> > - Ran bind/unbind loop (1000 iteration) test on snd-usb-audio
> > while running mc_nextgen_test loop (1000 iterations) in parallel.
> > - Ran bind/unbind and rmmod/modprobe tests on both drivers. Also
> > generated graphs when after bind/unbind, rmmod/modprobe. Graphs
> > look good.
> > - Note: Please apply the following patch to fix memory leak:
> > sound/usb: Fix memory leak in media_snd_stream_delete() during unbind
> > https://lkml.org/lkml/2016/3/16/1050
> >
> > sound/usb/media.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/sound/usb/media.c b/sound/usb/media.c
> > index de4a815..e35af88 100644
> > --- a/sound/usb/media.c
> > +++ b/sound/usb/media.c
> > @@ -301,6 +301,13 @@ int media_snd_device_create(struct snd_usb_audio *chip,
> > void media_snd_device_delete(struct snd_usb_audio *chip)
> > {
> > struct media_device *mdev = chip->media_dev;
> > + struct snd_usb_stream *stream;
> > +
> > + /* release resources */
> > + list_for_each_entry(stream, &chip->pcm_list, list) {
> > + media_snd_stream_delete(&stream->substream[0]);
> > + media_snd_stream_delete(&stream->substream[1]);
>
> I'll look on it better tomorrow, but it sounds weird to hardcode
> substream[0] and [1] here... are you sure that this is valid for
> *all* devices supported by snd-usb-audio?
After looking at pcm.c and finding this:
static void snd_usb_audio_stream_free(struct snd_usb_stream *stream)
{
free_substream(&stream->substream[0]);
free_substream(&stream->substream[1]);
list_del(&stream->list);
kfree(stream);
}
It seems that assuming that substream is always an array with size 2
is right.
I'll do some tests with it today with your patch.
Regards,
Mauro
>
> Regards,
> Mauro
>
> > + }
> >
> > media_snd_mixer_delete(chip);
> >
>
>
--
Thanks,
Mauro
--
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
cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Thu Mar 17 04:00:24 CET 2016 git branch: test git hash: da470473c9cf9c4ebb40d046b306c76427b6df94 gcc version:i686-linux-gcc (GCC) 5.3.0 sparse version: v0.5.0-51-ga53cea2 smatch version: v0.5.0-3228-g5cf65ab host hardware: x86_64 host os:4.4.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: OK linux-3.17.8-i686: OK linux-3.18.7-i686: OK linux-3.19-i686: OK linux-4.0-i686: OK linux-4.1.1-i686: OK linux-4.2-i686: OK linux-4.3-i686: OK linux-4.4-i686: OK linux-4.5-i686: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-x86_64: OK linux-4.1.1-x86_64: OK linux-4.2-x86_64: OK linux-4.3-x86_64: OK linux-4.4-x86_64: OK linux-4.5-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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
[PATCH v2] media: rc: remove unneeded mutex in rc_register_device
Access to dev->initialized is atomic and dev->initialized isn't accessed in any other code protected by this mutex. Therefore we don't need to get the mutex here. Signed-off-by: Heiner Kallweit --- v2: - corrected commit message --- drivers/media/rc/rc-main.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c index 4e9bbe7..68541b1 100644 --- a/drivers/media/rc/rc-main.c +++ b/drivers/media/rc/rc-main.c @@ -1492,9 +1492,7 @@ int rc_register_device(struct rc_dev *dev) } /* Allow the RC sysfs nodes to be accessible */ - mutex_lock(&dev->lock); atomic_set(&dev->initialized, 1); - mutex_unlock(&dev->lock); IR_dprintk(1, "Registered rc%u (driver: %s, remote: %s, mode %s)\n", dev->minor, -- 2.7.3 -- 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 7/7] mtd: nand: sunxi: update DT bindings
On Tue, Mar 08, 2016 at 12:15:15PM +0100, Boris Brezillon wrote: > Document dmas and dma-names properties. > > Signed-off-by: Boris Brezillon > --- > Documentation/devicetree/bindings/mtd/sunxi-nand.txt | 4 > 1 file changed, 4 insertions(+) Acked-by: Rob Herring -- 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 4/5] [media] media-device: use kref for media_device instance
Hi Mauro,
On Wed, Mar 16, 2016 at 09:04:05AM -0300, Mauro Carvalho Chehab wrote:
> Now that the media_device can be used by multiple drivers,
> via devres, we need to be sure that it will be dropped only
> when all drivers stop using it.
Not long ago we split media device initialisation and registration into two.
The intent with that was to prevent users from seeing the media device until
all the initialisation is finished. I suppose that with dynamic updates, or
media device being shared with two drivers, it might be difficult to achieve
that. At least the method has to be different.
media_device_init() and media_device_cleanup() were a pair where the latter
undid the first. This patchs remove the requirement of calling cleanup
explitly, breaking that model. It's perhaps not a big problem, there is
likely no single driver which would initialise the media controller device
once but would register and unregister it multiple times. I still wonder if
we really lost something important if we removed media_device_init() and
media_device_cleanup() altogether and merged the functionality in
media_device_{,un}register().
Cc Javier who wrote the patch.
commit 9832e155f1ed3030fdfaa19e72c06472dc2ecb1d
Author: Javier Martinez Canillas
Date: Fri Dec 11 20:57:08 2015 -0200
[media] media-device: split media initialization and registration
For system-wide media device, I think we'd need to introduce a new concept,
graph, that would define an interconnected set of entities. This would
mainly be needed for callbacks, e.g. the power on / off sequences of the
entities could be specific to V4L as discussed earlier. With this approach
hacks wouldn't be needed to be made in the first place to support two drivers
sharing a media device.
What was the original reason you needed to share the media device btw.?
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/media/media-device.c | 48
> +++-
> include/media/media-device.h | 3 +++
> 2 files changed, 37 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index c32fa15cc76e..38e6c319fe6e 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -721,6 +721,15 @@ int __must_check __media_device_register(struct
> media_device *mdev,
> {
> int ret;
>
> + /* Check if mdev was ever registered at all */
> + mutex_lock(&mdev->graph_mutex);
> + if (media_devnode_is_registered(&mdev->devnode)) {
> + kref_get(&mdev->kref);
> + mutex_unlock(&mdev->graph_mutex);
> + return 0;
> + }
> + kref_init(&mdev->kref);
> +
> /* Register the device node. */
> mdev->devnode.fops = &media_device_fops;
> mdev->devnode.parent = mdev->dev;
> @@ -730,8 +739,10 @@ int __must_check __media_device_register(struct
> media_device *mdev,
> mdev->topology_version = 0;
>
> ret = media_devnode_register(&mdev->devnode, owner);
> - if (ret < 0)
> + if (ret < 0) {
> + media_devnode_unregister(&mdev->devnode);
> return ret;
> + }
>
> ret = device_create_file(&mdev->devnode.dev, &dev_attr_model);
> if (ret < 0) {
> @@ -739,6 +750,7 @@ int __must_check __media_device_register(struct
> media_device *mdev,
> return ret;
> }
>
> + mutex_unlock(&mdev->graph_mutex);
> dev_dbg(mdev->dev, "Media device registered\n");
>
> return 0;
> @@ -773,23 +785,15 @@ void media_device_unregister_entity_notify(struct
> media_device *mdev,
> }
> EXPORT_SYMBOL_GPL(media_device_unregister_entity_notify);
>
> -void media_device_unregister(struct media_device *mdev)
> +static void do_media_device_unregister(struct kref *kref)
> {
> + struct media_device *mdev;
> struct media_entity *entity;
> struct media_entity *next;
> struct media_interface *intf, *tmp_intf;
> struct media_entity_notify *notify, *nextp;
>
> - if (mdev == NULL)
> - return;
> -
> - mutex_lock(&mdev->graph_mutex);
> -
> - /* Check if mdev was ever registered at all */
> - if (!media_devnode_is_registered(&mdev->devnode)) {
> - mutex_unlock(&mdev->graph_mutex);
> - return;
> - }
> + mdev = container_of(kref, struct media_device, kref);
>
> /* Remove all entities from the media device */
> list_for_each_entry_safe(entity, next, &mdev->entities, graph_obj.list)
> @@ -807,13 +811,26 @@ void media_device_unregister(struct media_device *mdev)
> kfree(intf);
> }
>
> - mutex_unlock(&mdev->graph_mutex);
> + /* Check if mdev devnode was registered */
> + if (!media_devnode_is_registered(&mdev->devnode))
> + return;
>
> device_remove_file(&mdev->devnode.dev, &dev_attr_model);
> media_devnode_unregister(&mdev->devnode);
>
> dev_dbg(mdev->dev, "Media device unregistered\n");
> }
>
[PATCH 2/2] mceusb: add support for SMK eHome receiver
Add USB ID of SMK RXX6000 series IR receiver. Often branded as
Lenovo receiver.
Signed-off-by: Olli Salonen
---
drivers/media/rc/mceusb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index 09ca9f6..5cf2e74 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -303,6 +303,9 @@ static struct usb_device_id mceusb_dev_table[] = {
/* SMK/I-O Data GV-MC7/RCKIT Receiver */
{ USB_DEVICE(VENDOR_SMK, 0x0353),
.driver_info = MCE_GEN2_NO_TX },
+ /* SMK RXX6000 Infrared Receiver */
+ { USB_DEVICE(VENDOR_SMK, 0x0357),
+ .driver_info = MCE_GEN2_NO_TX },
/* Tatung eHome Infrared Transceiver */
{ USB_DEVICE(VENDOR_TATUNG, 0x9150) },
/* Shuttle eHome Infrared Transceiver */
--
1.9.1
--
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 1/2] media/dvb-core: fix inverted check
Breakage caused by commit f50d51661a
Signed-off-by: Max Kellermann
---
drivers/media/dvb-core/dvbdev.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c
index 560450a..c756d4b 100644
--- a/drivers/media/dvb-core/dvbdev.c
+++ b/drivers/media/dvb-core/dvbdev.c
@@ -682,7 +682,7 @@ int dvb_create_media_graph(struct dvb_adapter *adap,
if (demux && ca) {
ret = media_create_pad_link(demux, 1, ca,
0, MEDIA_LNK_FL_ENABLED);
- if (!ret)
+ if (ret)
return -ENOMEM;
}
--
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: [PATCHv13 05/17] HID: add HDMI CEC specific keycodes
Hi Dmitry, Can you Ack this? I don't expect this to change anymore. Your comments have been incorporated (added the "Diagonal movement keys" comment). Thanks! Hans On 03/18/2016 03:07 PM, Hans Verkuil wrote: > From: Kamil Debski > > Add HDMI CEC specific keycodes to the keycodes definition. > > Signed-off-by: Kamil Debski > Signed-off-by: Hans Verkuil > --- > include/uapi/linux/input-event-codes.h | 30 ++ > 1 file changed, 30 insertions(+) > > diff --git a/include/uapi/linux/input-event-codes.h > b/include/uapi/linux/input-event-codes.h > index 87cf351..02b7b3a 100644 > --- a/include/uapi/linux/input-event-codes.h > +++ b/include/uapi/linux/input-event-codes.h > @@ -611,6 +611,36 @@ > #define KEY_KBDINPUTASSIST_ACCEPT0x264 > #define KEY_KBDINPUTASSIST_CANCEL0x265 > > +/* Diagonal movement keys */ > +#define KEY_RIGHT_UP 0x266 > +#define KEY_RIGHT_DOWN 0x267 > +#define KEY_LEFT_UP 0x268 > +#define KEY_LEFT_DOWN0x269 > + > +#define KEY_ROOT_MENU0x26a /* Show Device's Root > Menu */ > +#define KEY_MEDIA_TOP_MENU 0x26b /* Show Top Menu of the Media > (e.g. DVD) */ > +#define KEY_NUMERIC_11 0x26c > +#define KEY_NUMERIC_12 0x26d > +/* > + * Toggle Audio Description: refers to an audio service that helps blind and > + * visually impaired consumers understand the action in a program. Note: in > + * some countries this is referred to as "Video Description". > + */ > +#define KEY_AUDIO_DESC 0x26e > +#define KEY_3D_MODE 0x26f > +#define KEY_NEXT_FAVORITE0x270 > +#define KEY_STOP_RECORD 0x271 > +#define KEY_PAUSE_RECORD 0x272 > +#define KEY_VOD 0x273 /* Video on Demand */ > +#define KEY_UNMUTE 0x274 > +#define KEY_FASTREVERSE 0x275 > +#define KEY_SLOWREVERSE 0x276 > +/* > + * Control a data application associated with the currently viewed channel, > + * e.g. teletext or data broadcast application (MHEG, MHP, HbbTV, etc.) > + */ > +#define KEY_DATA 0x275 > + > #define BTN_TRIGGER_HAPPY0x2c0 > #define BTN_TRIGGER_HAPPY1 0x2c0 > #define BTN_TRIGGER_HAPPY2 0x2c1 > -- 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: [v4l-utils PATCH 1/1] libv4l2subdev: Allow extra spaces between format strings
Hi Sakari, Thank you for the patch. On Friday 11 March 2016 22:43:18 Sakari Ailus wrote: > It's possible to pass more than one format string (and entity) to > v4l2_subdev_parse_setup_formats(), yet v4l2_subdev_parse_pad_format() does > not parse the string until the next non-space character. > v4l2_subdev_parse_setup_formats() expects to find a comma right after that > leading spaces before the comma to produce an error. > > Seek until no spaces are seen. > > Signed-off-by: Sakari Ailus Acked-by: Laurent Pinchart > --- > utils/media-ctl/libv4l2subdev.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/utils/media-ctl/libv4l2subdev.c > b/utils/media-ctl/libv4l2subdev.c index 1f5fca4..3dcf943 100644 > --- a/utils/media-ctl/libv4l2subdev.c > +++ b/utils/media-ctl/libv4l2subdev.c > @@ -723,6 +723,7 @@ int v4l2_subdev_parse_setup_formats(struct media_device > *media, const char *p) if (ret < 0) > return ret; > > + for (; isspace(*end); end++); > p = end + 1; > } while (*end == ','); -- 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
[PATCHv13 01/17] dts: exynos4*: add HDMI CEC pin definition to pinctrl
From: Kamil Debski
Add pinctrl nodes for the HDMI CEC device to the Exynos4210 and
Exynos4x12 SoCs. These are required by the HDMI CEC device.
Signed-off-by: Kamil Debski
Signed-off-by: Hans Verkuil
Acked-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 7 +++
arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 7 +++
2 files changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
index a7c2128..9331c62 100644
--- a/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4210-pinctrl.dtsi
@@ -820,6 +820,13 @@
samsung,pin-pud = <1>;
samsung,pin-drv = <0>;
};
+
+ hdmi_cec: hdmi-cec {
+ samsung,pins = "gpx3-6";
+ samsung,pin-function = <3>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
};
pinctrl@0386 {
diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
index bac25c6..856b292 100644
--- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
@@ -885,6 +885,13 @@
samsung,pin-pud = <0>;
samsung,pin-drv = <0>;
};
+
+ hdmi_cec: hdmi-cec {
+ samsung,pins = "gpx3-6";
+ samsung,pin-function = <3>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <0>;
+ };
};
pinctrl_2: pinctrl@0386 {
--
2.7.0
--
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 4/5] [media] media-device: use kref for media_device instance
Hello Mauro,
Patch looks almost good to me, I just have a question below:
On Wed, Mar 16, 2016 at 9:04 AM, Mauro Carvalho Chehab
wrote:
> Now that the media_device can be used by multiple drivers,
> via devres, we need to be sure that it will be dropped only
> when all drivers stop using it.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/media/media-device.c | 48
> +++-
> include/media/media-device.h | 3 +++
> 2 files changed, 37 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index c32fa15cc76e..38e6c319fe6e 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -721,6 +721,15 @@ int __must_check __media_device_register(struct
> media_device *mdev,
> {
> int ret;
>
> + /* Check if mdev was ever registered at all */
> + mutex_lock(&mdev->graph_mutex);
> + if (media_devnode_is_registered(&mdev->devnode)) {
> + kref_get(&mdev->kref);
> + mutex_unlock(&mdev->graph_mutex);
> + return 0;
> + }
> + kref_init(&mdev->kref);
> +
> /* Register the device node. */
> mdev->devnode.fops = &media_device_fops;
> mdev->devnode.parent = mdev->dev;
> @@ -730,8 +739,10 @@ int __must_check __media_device_register(struct
> media_device *mdev,
> mdev->topology_version = 0;
>
> ret = media_devnode_register(&mdev->devnode, owner);
> - if (ret < 0)
> + if (ret < 0) {
> + media_devnode_unregister(&mdev->devnode);
Why are you adding this? If media_devnode_register() failed then the
device node won't be registered so is not correct to call
media_devnode_unregister(). Or maybe I'm missing something.
Reviewed-by: Javier Martinez Canillas
Best regards,
Javier
--
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 RESEND] media: dvb_ringbuffer: Add memory barriers
Implement memory barriers according to Documentation/circular-buffers.txt:
- use smp_store_release() to update ringbuffer read/write pointers
- use smp_load_acquire() to load write pointer on reader side
- use ACCESS_ONCE() to load read pointer on writer side
This fixes data stream corruptions observed e.g. on an ARM Cortex-A9
quad core system with different types (PCI, USB) of DVB tuners.
Signed-off-by: Soeren Moch
Cc: sta...@vger.kernel.org # 3.14+
---
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Since smp_store_release() and smp_load_acquire() were introduced in linux-3.14,
a 3.14+ stable tag was added. Is it desired to apply a similar patch to older
stable kernels?
---
drivers/media/dvb-core/dvb_ringbuffer.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/media/dvb-core/dvb_ringbuffer.c
b/drivers/media/dvb-core/dvb_ringbuffer.c
index 1100e98..58b5968 100644
--- a/drivers/media/dvb-core/dvb_ringbuffer.c
+++ b/drivers/media/dvb-core/dvb_ringbuffer.c
@@ -55,7 +55,7 @@ void dvb_ringbuffer_init(struct dvb_ringbuffer *rbuf, void
*data, size_t len)
int dvb_ringbuffer_empty(struct dvb_ringbuffer *rbuf)
{
- return (rbuf->pread==rbuf->pwrite);
+ return (rbuf->pread == smp_load_acquire(&rbuf->pwrite));
}
@@ -64,7 +64,7 @@ ssize_t dvb_ringbuffer_free(struct dvb_ringbuffer *rbuf)
{
ssize_t free;
- free = rbuf->pread - rbuf->pwrite;
+ free = ACCESS_ONCE(rbuf->pread) - rbuf->pwrite;
if (free <= 0)
free += rbuf->size;
return free-1;
@@ -76,7 +76,7 @@ ssize_t dvb_ringbuffer_avail(struct dvb_ringbuffer *rbuf)
{
ssize_t avail;
- avail = rbuf->pwrite - rbuf->pread;
+ avail = smp_load_acquire(&rbuf->pwrite) - rbuf->pread;
if (avail < 0)
avail += rbuf->size;
return avail;
@@ -86,14 +86,15 @@ ssize_t dvb_ringbuffer_avail(struct dvb_ringbuffer *rbuf)
void dvb_ringbuffer_flush(struct dvb_ringbuffer *rbuf)
{
- rbuf->pread = rbuf->pwrite;
+ smp_store_release(&rbuf->pread, smp_load_acquire(&rbuf->pwrite));
rbuf->error = 0;
}
EXPORT_SYMBOL(dvb_ringbuffer_flush);
void dvb_ringbuffer_reset(struct dvb_ringbuffer *rbuf)
{
- rbuf->pread = rbuf->pwrite = 0;
+ smp_store_release(&rbuf->pread, 0);
+ smp_store_release(&rbuf->pwrite, 0);
rbuf->error = 0;
}
@@ -119,12 +120,12 @@ ssize_t dvb_ringbuffer_read_user(struct dvb_ringbuffer
*rbuf, u8 __user *buf, si
return -EFAULT;
buf += split;
todo -= split;
- rbuf->pread = 0;
+ smp_store_release(&rbuf->pread, 0);
}
if (copy_to_user(buf, rbuf->data+rbuf->pread, todo))
return -EFAULT;
- rbuf->pread = (rbuf->pread + todo) % rbuf->size;
+ smp_store_release(&rbuf->pread, (rbuf->pread + todo) % rbuf->size);
return len;
}
@@ -139,11 +140,11 @@ void dvb_ringbuffer_read(struct dvb_ringbuffer *rbuf, u8
*buf, size_t len)
memcpy(buf, rbuf->data+rbuf->pread, split);
buf += split;
todo -= split;
- rbuf->pread = 0;
+ smp_store_release(&rbuf->pread, 0);
}
memcpy(buf, rbuf->data+rbuf->pread, todo);
- rbuf->pread = (rbuf->pread + todo) % rbuf->size;
+ smp_store_release(&rbuf->pread, (rbuf->pread + todo) % rbuf->size);
}
@@ -158,10 +159,10 @@ ssize_t dvb_ringbuffer_write(struct dvb_ringbuffer *rbuf,
const u8 *buf, size_t
memcpy(rbuf->data+rbuf->pwrite, buf, split);
buf += split;
todo -= split;
- rbuf->pwrite = 0;
+ smp_store_release(&rbuf->pwrite, 0);
}
memcpy(rbuf->data+rbuf->pwrite, buf, todo);
- rbuf->pwrite = (rbuf->pwrite + todo) % rbuf->size;
+ smp_store_release(&rbuf->pwrite, (rbuf->pwrite + todo) % rbuf->size);
return len;
}
@@ -181,12 +182,12 @@ ssize_t dvb_ringbuffer_write_user(struct dvb_ringbuffer
*rbuf,
return len - todo;
buf += split;
todo -= split;
- rbuf->pwrite = 0;
+ smp_store_release(&rbuf->pwrite, 0);
}
status = copy_from_user(rbuf->data+rbuf->pwrite, buf, todo);
if (status)
return len - todo;
- rbuf->pwrite = (rbuf->pwrite + todo) % rbuf->size;
+ smp_store_release(&rbuf->pwrite, (rbuf->pwrite + todo) % rbuf->size);
return len;
}
-- 1.9.1
--
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: RE
Please confirm receipt of my previous mail..When can i call you -- 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: rc: reduce size of struct ir_raw_event
Am 17.03.2016 um 11:53 schrieb Sean Young: > On Thu, Mar 17, 2016 at 07:40:59AM +0100, Heiner Kallweit wrote: >> Am 16.03.2016 um 23:28 schrieb Sean Young: >>> On Wed, Mar 16, 2016 at 10:18:38PM +0100, Heiner Kallweit wrote: + u8 pulse:1; + u8 reset:1; + u8 timeout:1; + u8 carrier_report:1; >>> >>> Why are you changing the type of the bitfields? >>> >> I did this to make sure that the compiler uses one byte for >> the bit field. When testing gcc also used just one byte when >> keeping the original "unsigned" type for the bit field members. >> Therefore it wouldn't be strictly neeeded. >> >> But I'm not sure whether it's guaranteed that the compiler packs a >> bit field to the smallest possible data type and we can rely on it. >> AFAIK C99 is a little more specific about this implementation detail of >> bit fields but C89/C90 is used for kernel compilation. > > It might be worth reading about structure packing rules rather than > guessing. > Whenever it became interesting when reading the statement was: unspecified / implementation-dependent. But at least C90 clearly states that only signed / unsigned int are acceptable for bit fields. Therefore leave the bit field as it is. I will provide a v2. Heiner > > Sean > -- 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] media: rc: remove unneeded mutex in rc_register_device
Access to dev->initialized is atomic, therefore we don't have to protect it with a mutex. Signed-off-by: Heiner Kallweit --- drivers/media/rc/rc-main.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c index 4e9bbe7..68541b1 100644 --- a/drivers/media/rc/rc-main.c +++ b/drivers/media/rc/rc-main.c @@ -1492,9 +1492,7 @@ int rc_register_device(struct rc_dev *dev) } /* Allow the RC sysfs nodes to be accessible */ - mutex_lock(&dev->lock); atomic_set(&dev->initialized, 1); - mutex_unlock(&dev->lock); IR_dprintk(1, "Registered rc%u (driver: %s, remote: %s, mode %s)\n", dev->minor, -- 2.7.3 -- 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 1/2] sound/usb/media: use core routine to initialize media_device
The media core has now a routine to initialize media_device
for USB devices. Use it, instead of doing its own logic,
as it warrants that all USB drivers will behave the same. It
also warrants that the device will get the same data, no matter
if it was initialized initially via snd-usb-audio or via
some other driver, like au0828.
Signed-off-by: Mauro Carvalho Chehab
---
sound/usb/media.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/sound/usb/media.c b/sound/usb/media.c
index 93a50d01490c..44a5de91f748 100644
--- a/sound/usb/media.c
+++ b/sound/usb/media.c
@@ -263,19 +263,11 @@ int media_snd_device_create(struct snd_usb_audio *chip,
mdev = media_device_get_devres(&usbdev->dev);
if (!mdev)
return -ENOMEM;
- if (!mdev->dev) {
- /* register media device */
- mdev->dev = &usbdev->dev;
- if (usbdev->product)
- strlcpy(mdev->model, usbdev->product,
- sizeof(mdev->model));
- if (usbdev->serial)
- strlcpy(mdev->serial, usbdev->serial,
- sizeof(mdev->serial));
- strcpy(mdev->bus_info, usbdev->devpath);
- mdev->hw_revision = le16_to_cpu(usbdev->descriptor.bcdDevice);
- media_device_init(mdev);
- }
+
+ /* Initialize media device */
+ if (!mdev->dev)
+ media_device_usb_init(mdev, usbdev, NULL);
+
if (!media_devnode_is_registered(&mdev->devnode)) {
ret = media_device_register(mdev);
if (ret) {
--
2.5.0
--
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] sound/usb: fix to release stream resources from media_snd_device_delete()
Em Fri, 18 Mar 2016 20:50:31 -0600 Shuah Khan escreveu: > Fix to release stream resources from media_snd_device_delete() before > media device is unregistered. Without this change, stream resource free > is attempted after the media device is unregistered which would result > in use-after-free errors. > > Signed-off-by: Shuah Khan > --- > > - Ran bind/unbind loop (1000 iteration) test on snd-usb-audio > while running mc_nextgen_test loop (1000 iterations) in parallel. > - Ran bind/unbind and rmmod/modprobe tests on both drivers. Also > generated graphs when after bind/unbind, rmmod/modprobe. Graphs > look good. > - Note: Please apply the following patch to fix memory leak: > sound/usb: Fix memory leak in media_snd_stream_delete() during unbind > https://lkml.org/lkml/2016/3/16/1050 Yeah, a way better! For normal bind/unbind, it seems to be working fine. Also for driver's rmmod, so: Tested-by: Mauro Carvalho Chehab PS.: === There are still some troubles if we run an infinite loop binding/unbinding au0828 and another one binding/unbinding snd-usb-audio, like this one: [ 91.556188] [ cut here ] [ 91.556500] WARNING: CPU: 1 PID: 2920 at drivers/media/media-entity.c:392 __media_entity_pipeline_start+0x271/0xce0 [media]() [ 91.556626] Modules linked in: ir_lirc_codec lirc_dev au8522_dig xc5000 tuner au8522_decoder au8522_common au0828 videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core tveeprom dvb_core rc_core v4l2_common videodev snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device media cpufreq_powersave cpufreq_conservative cpufreq_userspace cpufreq_stats parport_pc ppdev lp parport snd_hda_codec_hdmi intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel iTCO_wdt kvm iTCO_vendor_support irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel sha256_ssse3 sha256_generic hmac drbg snd_hda_codec_realtek i915 snd_hda_codec_generic aesni_intel aes_x86_64 btusb lrw btrtl gf128mul snd_hda_intel glue_helper ablk_helper btbcm btintel cryptd psmouse snd_hda_codec bluetooth [ 91.556693] snd_hwdep i2c_algo_bit sg snd_hda_core serio_raw pcspkr evdev drm_kms_helper snd_pcm rfkill drm snd_timer mei_me snd i2c_i801 soundcore lpc_ich mei mfd_core battery video dw_dmac i2c_designware_platform dw_dmac_core i2c_designware_core acpi_pad button tpm_tis tpm ext4 crc16 mbcache jbd2 dm_mod sd_mod hid_generic usbhid ahci libahci libata e1000e xhci_pci ptp scsi_mod ehci_pci ehci_hcd pps_core xhci_hcd fan thermal sdhci_acpi sdhci mmc_core i2c_hid hid [ 91.556748] CPU: 1 PID: 2920 Comm: v4l_id Tainted: G D W 4.5.0+ #62 [ 91.556751] Hardware name: /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722 08/12/2015 [ 91.556754] a0e247a0 8803a3d17b08 819447c1 [ 91.556759] 88009bbe17c0 8803a3d17b48 8114fd16 a0e20651 [ 91.556763] 8803a47c9c58 8803a477d2c8 8803a5ac96f8 dc00 [ 91.556768] Call Trace: [ 91.556774] [] dump_stack+0x85/0xc4 [ 91.556778] [] warn_slowpath_common+0xc6/0x120 [ 91.556783] [] ? __media_entity_pipeline_start+0x271/0xce0 [media] [ 91.556786] [] warn_slowpath_null+0x1a/0x20 [ 91.556790] [] __media_entity_pipeline_start+0x271/0xce0 [media] [ 91.556794] [] ? __schedule+0x78a/0x2570 [ 91.556797] [] ? memset+0x28/0x30 [ 91.556802] [] ? media_entity_pipeline_stop+0x60/0x60 [media] [ 91.556806] [] ? trace_hardirqs_on+0xd/0x10 [ 91.556810] [] ? au0828_enable_source+0x55/0x9f0 [au0828] [ 91.556813] [] ? mutex_trylock+0x400/0x400 [ 91.556818] [] ? au0828_v4l2_close+0xb3/0x590 [au0828] [ 91.556822] [] au0828_enable_source+0x3f4/0x9f0 [au0828] [ 91.556824] [] ? mutex_trylock+0x400/0x400 [ 91.556834] [] v4l_enable_media_source+0x66/0x90 [videodev] [ 91.556839] [] au0828_v4l2_close+0x25a/0x590 [au0828] [ 91.556846] [] v4l2_release+0xf0/0x210 [videodev] [ 91.556849] [] __fput+0x20f/0x6d0 [ 91.556853] [] fput+0xe/0x10 [ 91.556856] [] task_work_run+0x137/0x200 [ 91.556859] [] exit_to_usermode_loop+0x154/0x180 [ 91.556863] [] ? trace_hardirqs_on_caller+0x16/0x590 [ 91.556866] [] syscall_return_slowpath+0x186/0x1c0 [ 91.556869] [] entry_SYSCALL_64_fastpath+0xbf/0xc1 [ 91.556872] ---[ end trace 3e95e11ff0b9efad ]--- I suspect that something is not properly protected by the graph mutex at either ALSA or au0828 driver. I also got a GPF: [ 95.398931] au0828: Start Pipeline: Xceive XC5000->au0828a vbi Error -16 [ 95.398936] au0828: Deactivate link Error 0 [ 95.398943] tuner 6-0061: Putting tuner to sleep [ 95.398960] kasan: CONFIG_KASAN_INLINE enabled [ 95.398962] kasan: GPF could be caused by NULL-ptr deref or user memory access [ 95.398967] general protection fault: [#2] SMP KASAN [ 95.399020] Modules linked in: ir_lirc_codec lirc_dev au8522_dig xc5000 tuner au8522_decoder au8522_common au0828 vide
[PATCHv13 00/17] HDMI CEC framework
Hi all, The thirteenth version of this patchset addresses problems I found when using this patch series in real situations. This also made me realize that this is not quite ready yet to be merged, although it is getting close. See the changelog below. The cec-ctl and cec-compliance utilities used to test the CEC framework can be found here: http://git.linuxtv.org/cgit.cgi/hverkuil/v4l-utils.git/log/?h=cec Note that I started the first steps towards a proper CEC compliance test where I can put a CEC adapter in follower mode (where it replies to messages emulating a device) and/or initiator mode where the device sends messages to remote CEC adapters, testing those. Early days yet, but very useful in designing the new CEC_G/S_MODE ioctls to replace the old CLAIM/RELEASE, G/S_MONITOR and G_PASSTHROUGH ioctls. The new ioctls made much more sense and are a good fit with CEC protocol. The TODO items on my list are: - think more carefully about the relationship between setting the physical address, enabling/disabling the adapter and setting logical addresses. I.e. setting physical address f.f.f.f should automatically switch the CEC adapter to the Unregistered logical address. You would also like the adapter to automatically re-register its logical addresses when needed. - The ARC and CDC HPD support will probably have to be left out from the final version: I think I will have to test with this with actual hardware in order to check if what is happening now is actually correct. I'm not confident of that right now. - More documentation tweaks The low-level kernel API towards the actual CEC adapter drivers is pretty stable. I now have support for s5p, adv7604, adv7842, adv7511, tc358840 (new upcoming driver, not yet in the kernel but posted today) and one other that I can't yet tell about :-) I've also played with the omap4 CEC adapter for a pandaboard, but that isn't working yet. Best regards, Hans Changes since v12 = - Added driver and name fields to the cec_caps struct. Without this it was very difficult to tell CEC adapters apart in a human readable manner. - Renamed CEC_CAP_IO to CEC_CAP_TRANSMIT, which better describes this capability. - Added the CEC_ADAP_LOG_STATUS to log the current status of the CEC adapter. Very useful when debugging. - Added comments to the cec.c source. - Added a timeout when waiting for a transmit to finish. Without the timeout the state machine could lock up when dealing with broken CEC adapter drivers or just unlucky situations. - Commenting the code also found a number of bugs which have been fixed. - Trying to poll yourself is now handled by the framework since different hardware would give different results. The framework will just NACK it. - Disabling the CEC adapter doesn't clear the physical address anymore. This turned out to be quite painful for applications. - Merged the CLAIM/RELEASE, G/S_MONITOR and G_PASSTHROUGH ioctls into two G/S_MODE ioctls. This allows you to tell the driver which initiator and follower modes you want, and greatly simplifies how these modes are handled. Changes since v11 = - Add a new CEC_EVENT_PHYS_ADDR_CHANGED to report when the physical address of the CEC adapter changes. Since the physical address is obtained from the EDID the application has to be informed when the kernel (or userspace for that matter) sets that. - Add a new internal cec_set_phys_addr() function to change the physical address and post the event. - Modified the retry-transmit mechanism: the framework will do the retry if the low-level driver returns a TX_STATUS error, but does not set the CEC_TX_STATUS_MAX_RETRIES status bit. In that case the framework assumes that there is no hardware retry and it will retry itself. This used to be through the 'retries' pointer argument (set to 0 if there is no retry support) but that doesn't work for hardware that does retry for some error conditions but not for others. - Added the missing CEC_TX_STATUS_LOW_DRIVE bit and low_drive_cnt error counter. I missed that potential CEC bus error condition. - By passing a NULL pointer to cec_claim_log_addrs() drivers can clear the logical addresses. - When a source loses the HPD the source has to clear the logical addresses and update its physical address. Implement this in the cobalt driver. - Improve tx_status handling in the various low-level drivers. Changes since v10 = - Split the msg.status field into tx_status and rx_status. - Add counters for various CEC protocol errors that can occur during transmit. - Add tx_status bits for the ARB_LOST and NACK status and add a generic CEC_TX_STATUS_ERROR bit. - Add retry support to the CEC framework for hardware that does not have retry support. - Improve event handling: on open() generate events that report the initial CEC adapter status and the number of connected inputs. Also ensure that you never loose important ev
Re: [PATCH] sound/usb: fix to release stream resources from media_snd_device_delete()
On 03/19/2016 04:39 AM, Mauro Carvalho Chehab wrote:
> Em Fri, 18 Mar 2016 23:57:08 -0300
> Mauro Carvalho Chehab escreveu:
>
>> Em Fri, 18 Mar 2016 20:50:31 -0600
>> Shuah Khan escreveu:
>>
>>> Fix to release stream resources from media_snd_device_delete() before
>>> media device is unregistered. Without this change, stream resource free
>>> is attempted after the media device is unregistered which would result
>>> in use-after-free errors.
>>>
>>> Signed-off-by: Shuah Khan
>>> ---
>>>
>>> - Ran bind/unbind loop (1000 iteration) test on snd-usb-audio
>>> while running mc_nextgen_test loop (1000 iterations) in parallel.
>>> - Ran bind/unbind and rmmod/modprobe tests on both drivers. Also
>>> generated graphs when after bind/unbind, rmmod/modprobe. Graphs
>>> look good.
>>> - Note: Please apply the following patch to fix memory leak:
>>> sound/usb: Fix memory leak in media_snd_stream_delete() during unbind
>>> https://lkml.org/lkml/2016/3/16/1050
>>>
>>> sound/usb/media.c | 7 +++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/sound/usb/media.c b/sound/usb/media.c
>>> index de4a815..e35af88 100644
>>> --- a/sound/usb/media.c
>>> +++ b/sound/usb/media.c
>>> @@ -301,6 +301,13 @@ int media_snd_device_create(struct snd_usb_audio *chip,
>>> void media_snd_device_delete(struct snd_usb_audio *chip)
>>> {
>>> struct media_device *mdev = chip->media_dev;
>>> + struct snd_usb_stream *stream;
>>> +
>>> + /* release resources */
>>> + list_for_each_entry(stream, &chip->pcm_list, list) {
>>> + media_snd_stream_delete(&stream->substream[0]);
>>> + media_snd_stream_delete(&stream->substream[1]);
>>
>> I'll look on it better tomorrow, but it sounds weird to hardcode
>> substream[0] and [1] here... are you sure that this is valid for
>> *all* devices supported by snd-usb-audio?
>
> After looking at pcm.c and finding this:
>
> static void snd_usb_audio_stream_free(struct snd_usb_stream *stream)
> {
> free_substream(&stream->substream[0]);
> free_substream(&stream->substream[1]);
> list_del(&stream->list);
> kfree(stream);
> }
>
> It seems that assuming that substream is always an array with size 2
> is right.
>
> I'll do some tests with it today with your patch.
>
Right. snd-usb-audio uses this in several places like the one above you found.
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
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] sound/usb: fix to release stream resources from media_snd_device_delete()
On 03/19/2016 06:10 AM, Mauro Carvalho Chehab wrote: > Em Fri, 18 Mar 2016 20:50:31 -0600 > Shuah Khan escreveu: > >> Fix to release stream resources from media_snd_device_delete() before >> media device is unregistered. Without this change, stream resource free >> is attempted after the media device is unregistered which would result >> in use-after-free errors. >> >> Signed-off-by: Shuah Khan >> --- >> >> - Ran bind/unbind loop (1000 iteration) test on snd-usb-audio >> while running mc_nextgen_test loop (1000 iterations) in parallel. >> - Ran bind/unbind and rmmod/modprobe tests on both drivers. Also >> generated graphs when after bind/unbind, rmmod/modprobe. Graphs >> look good. >> - Note: Please apply the following patch to fix memory leak: >> sound/usb: Fix memory leak in media_snd_stream_delete() during unbind >> https://lkml.org/lkml/2016/3/16/1050 > > Yeah, a way better! > > For normal bind/unbind, it seems to be working fine. Also > for driver's rmmod, so: > > Tested-by: Mauro Carvalho Chehab > > PS.: > === > > There are still some troubles if we run an infinite loop > binding/unbinding au0828 and another one binding/unbinding > snd-usb-audio, like this one: Yes. I noticed this one when I was running a loop of 1000 on au0828. I couldn't reproduce this when I tested this patch. P.S: au08282 loops takes longer btw since au0828 initialization is lot more complex. We have to look at this one. > > > [ 91.556188] [ cut here ] > [ 91.556500] WARNING: CPU: 1 PID: 2920 at drivers/media/media-entity.c:392 > __media_entity_pipeline_start+0x271/0xce0 [media]() > [ 91.556626] Modules linked in: ir_lirc_codec lirc_dev au8522_dig xc5000 > tuner au8522_decoder au8522_common au0828 videobuf2_vmalloc videobuf2_memops > videobuf2_v4l2 videobuf2_core tveeprom dvb_core rc_core v4l2_common videodev > snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device media > cpufreq_powersave cpufreq_conservative cpufreq_userspace cpufreq_stats > parport_pc ppdev lp parport snd_hda_codec_hdmi intel_rapl > x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel iTCO_wdt kvm > iTCO_vendor_support irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel > ghash_clmulni_intel sha256_ssse3 sha256_generic hmac drbg > snd_hda_codec_realtek i915 snd_hda_codec_generic aesni_intel aes_x86_64 btusb > lrw btrtl gf128mul snd_hda_intel glue_helper ablk_helper btbcm btintel cryptd > psmouse snd_hda_codec bluetooth > [ 91.556693] snd_hwdep i2c_algo_bit sg snd_hda_core serio_raw pcspkr evdev > drm_kms_helper snd_pcm rfkill drm snd_timer mei_me snd i2c_i801 soundcore > lpc_ich mei mfd_core battery video dw_dmac i2c_designware_platform > dw_dmac_core i2c_designware_core acpi_pad button tpm_tis tpm ext4 crc16 > mbcache jbd2 dm_mod sd_mod hid_generic usbhid ahci libahci libata e1000e > xhci_pci ptp scsi_mod ehci_pci ehci_hcd pps_core xhci_hcd fan thermal > sdhci_acpi sdhci mmc_core i2c_hid hid > [ 91.556748] CPU: 1 PID: 2920 Comm: v4l_id Tainted: G D W 4.5.0+ > #62 > [ 91.556751] Hardware name: /NUC5i7RYB, BIOS > RYBDWi35.86A.0350.2015.0812.1722 08/12/2015 > [ 91.556754] a0e247a0 8803a3d17b08 819447c1 > > [ 91.556759] 88009bbe17c0 8803a3d17b48 8114fd16 > a0e20651 > [ 91.556763] 8803a47c9c58 8803a477d2c8 8803a5ac96f8 > dc00 > [ 91.556768] Call Trace: > [ 91.556774] [] dump_stack+0x85/0xc4 > [ 91.556778] [] warn_slowpath_common+0xc6/0x120 > [ 91.556783] [] ? > __media_entity_pipeline_start+0x271/0xce0 [media] > [ 91.556786] [] warn_slowpath_null+0x1a/0x20 > [ 91.556790] [] > __media_entity_pipeline_start+0x271/0xce0 [media] > [ 91.556794] [] ? __schedule+0x78a/0x2570 > [ 91.556797] [] ? memset+0x28/0x30 > [ 91.556802] [] ? media_entity_pipeline_stop+0x60/0x60 > [media] > [ 91.556806] [] ? trace_hardirqs_on+0xd/0x10 > [ 91.556810] [] ? au0828_enable_source+0x55/0x9f0 > [au0828] > [ 91.556813] [] ? mutex_trylock+0x400/0x400 > [ 91.556818] [] ? au0828_v4l2_close+0xb3/0x590 [au0828] > [ 91.556822] [] au0828_enable_source+0x3f4/0x9f0 [au0828] > [ 91.556824] [] ? mutex_trylock+0x400/0x400 > [ 91.556834] [] v4l_enable_media_source+0x66/0x90 > [videodev] > [ 91.556839] [] au0828_v4l2_close+0x25a/0x590 [au0828] > [ 91.556846] [] v4l2_release+0xf0/0x210 [videodev] > [ 91.556849] [] __fput+0x20f/0x6d0 > [ 91.556853] [] fput+0xe/0x10 > [ 91.556856] [] task_work_run+0x137/0x200 > [ 91.556859] [] exit_to_usermode_loop+0x154/0x180 > [ 91.556863] [] ? trace_hardirqs_on_caller+0x16/0x590 > [ 91.556866] [] syscall_return_slowpath+0x186/0x1c0 > [ 91.556869] [] entry_SYSCALL_64_fastpath+0xbf/0xc1 > [ 91.556872] ---[ end trace 3e95e11ff0b9efad ]--- > > I suspect that something is not properly protected by the graph mutex at > either ALSA or au0828 driver. > > I also got a GPF: > > [ 95
[PATCHv13 06/17] rc: Add HDMI CEC protocol handling
From: Kamil Debski
Add handling of remote control events coming from the HDMI CEC bus.
This patch includes a new keymap that maps values found in the CEC
messages to the keys pressed and released. Also, a new protocol has
been added to the core.
Signed-off-by: Kamil Debski
Signed-off-by: Hans Verkuil
---
drivers/media/rc/keymaps/Makefile | 1 +
drivers/media/rc/keymaps/rc-cec.c | 174 ++
drivers/media/rc/rc-main.c| 1 +
include/media/rc-map.h| 5 +-
4 files changed, 180 insertions(+), 1 deletion(-)
create mode 100644 drivers/media/rc/keymaps/rc-cec.c
diff --git a/drivers/media/rc/keymaps/Makefile
b/drivers/media/rc/keymaps/Makefile
index fbbd3bb..9cffcc6 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-behold.o \
rc-behold-columbus.o \
rc-budget-ci-old.o \
+ rc-cec.o \
rc-cinergy-1400.o \
rc-cinergy.o \
rc-delock-61959.o \
diff --git a/drivers/media/rc/keymaps/rc-cec.c
b/drivers/media/rc/keymaps/rc-cec.c
new file mode 100644
index 000..193cdca
--- /dev/null
+++ b/drivers/media/rc/keymaps/rc-cec.c
@@ -0,0 +1,174 @@
+/* Keytable for the CEC remote control
+ *
+ * Copyright (c) 2015 by Kamil Debski
+ *
+ * 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.
+ */
+
+#include
+#include
+
+/* CEC Spec "High-Definition Multimedia Interface Specification" can be
obtained
+ * here: http://xtreamerdev.googlecode.com/files/CEC_Specs.pdf
+ * The list of control codes is listed in Table 27: User Control Codes p. 95 */
+
+static struct rc_map_table cec[] = {
+ { 0x00, KEY_OK },
+ { 0x01, KEY_UP },
+ { 0x02, KEY_DOWN },
+ { 0x03, KEY_LEFT },
+ { 0x04, KEY_RIGHT },
+ { 0x05, KEY_RIGHT_UP },
+ { 0x06, KEY_RIGHT_DOWN },
+ { 0x07, KEY_LEFT_UP },
+ { 0x08, KEY_LEFT_DOWN },
+ { 0x09, KEY_ROOT_MENU }, /* CEC Spec: Device Root Menu - see Note 2 */
+ /* Note 2: This is the initial display that a device shows. It is
+* device-dependent and can be, for example, a contents menu, setup
+* menu, favorite menu or other menu. The actual menu displayed
+* may also depend on the device's current state. */
+ { 0x0a, KEY_SETUP },
+ { 0x0b, KEY_MENU }, /* CEC Spec: Contents Menu */
+ { 0x0c, KEY_FAVORITES }, /* CEC Spec: Favorite Menu */
+ { 0x0d, KEY_EXIT },
+ /* 0x0e-0x0f: Reserved */
+ { 0x10, KEY_MEDIA_TOP_MENU },
+ { 0x11, KEY_CONTEXT_MENU },
+ /* 0x12-0x1c: Reserved */
+ { 0x1d, KEY_DIGITS }, /* CEC Spec: select/toggle a Number Entry Mode */
+ { 0x1e, KEY_NUMERIC_11 },
+ { 0x1f, KEY_NUMERIC_12 },
+ /* 0x20-0x29: Keys 0 to 9 */
+ { 0x20, KEY_NUMERIC_0 },
+ { 0x21, KEY_NUMERIC_1 },
+ { 0x22, KEY_NUMERIC_2 },
+ { 0x23, KEY_NUMERIC_3 },
+ { 0x24, KEY_NUMERIC_4 },
+ { 0x25, KEY_NUMERIC_5 },
+ { 0x26, KEY_NUMERIC_6 },
+ { 0x27, KEY_NUMERIC_7 },
+ { 0x28, KEY_NUMERIC_8 },
+ { 0x29, KEY_NUMERIC_9 },
+ { 0x2a, KEY_DOT },
+ { 0x2b, KEY_ENTER },
+ { 0x2c, KEY_CLEAR },
+ /* 0x2d-0x2e: Reserved */
+ { 0x2f, KEY_NEXT_FAVORITE }, /* CEC Spec: Next Favorite */
+ { 0x30, KEY_CHANNELUP },
+ { 0x31, KEY_CHANNELDOWN },
+ { 0x32, KEY_PREVIOUS }, /* CEC Spec: Previous Channel */
+ { 0x33, KEY_SOUND }, /* CEC Spec: Sound Select */
+ { 0x34, KEY_VIDEO }, /* 0x34: CEC Spec: Input Select */
+ { 0x35, KEY_INFO }, /* CEC Spec: Display Information */
+ { 0x36, KEY_HELP },
+ { 0x37, KEY_PAGEUP },
+ { 0x38, KEY_PAGEDOWN },
+ /* 0x39-0x3f: Reserved */
+ { 0x40, KEY_POWER },
+ { 0x41, KEY_VOLUMEUP },
+ { 0x42, KEY_VOLUMEDOWN },
+ { 0x43, KEY_MUTE },
+ { 0x44, KEY_PLAYCD },
+ { 0x45, KEY_STOPCD },
+ { 0x46, KEY_PAUSECD },
+ { 0x47, KEY_RECORD },
+ { 0x48, KEY_REWIND },
+ { 0x49, KEY_FASTFORWARD },
+ { 0x4a, KEY_EJECTCD }, /* CEC Spec: Eject */
+ { 0x4b, KEY_FORWARD },
+ { 0x4c, KEY_BACK },
+ { 0x4d, KEY_STOP_RECORD }, /* CEC Spec: Stop-Record */
+ { 0x4e, KEY_PAUSE_RECORD }, /* CEC Spec: Pause-Record */
+ /* 0x4f: Reserved */
+ { 0x50, KEY_ANGLE },
+ { 0x51, KEY_TV2 },
+ { 0x52, KEY_VOD }, /* CEC Spec: Video on Demand */
+ { 0x53, KEY_EPG },
+ { 0x54, KEY_TIME }, /* CEC Spec: Timer */
+ { 0x55, KEY_CONFIG },
+ /* The following codes are hard to implement at this moment, as they
+
[PATCHv13 05/17] HID: add HDMI CEC specific keycodes
From: Kamil Debski Add HDMI CEC specific keycodes to the keycodes definition. Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- include/uapi/linux/input-event-codes.h | 30 ++ 1 file changed, 30 insertions(+) diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h index 87cf351..02b7b3a 100644 --- a/include/uapi/linux/input-event-codes.h +++ b/include/uapi/linux/input-event-codes.h @@ -611,6 +611,36 @@ #define KEY_KBDINPUTASSIST_ACCEPT 0x264 #define KEY_KBDINPUTASSIST_CANCEL 0x265 +/* Diagonal movement keys */ +#define KEY_RIGHT_UP 0x266 +#define KEY_RIGHT_DOWN 0x267 +#define KEY_LEFT_UP0x268 +#define KEY_LEFT_DOWN 0x269 + +#define KEY_ROOT_MENU 0x26a /* Show Device's Root Menu */ +#define KEY_MEDIA_TOP_MENU 0x26b /* Show Top Menu of the Media (e.g. DVD) */ +#define KEY_NUMERIC_11 0x26c +#define KEY_NUMERIC_12 0x26d +/* + * Toggle Audio Description: refers to an audio service that helps blind and + * visually impaired consumers understand the action in a program. Note: in + * some countries this is referred to as "Video Description". + */ +#define KEY_AUDIO_DESC 0x26e +#define KEY_3D_MODE0x26f +#define KEY_NEXT_FAVORITE 0x270 +#define KEY_STOP_RECORD0x271 +#define KEY_PAUSE_RECORD 0x272 +#define KEY_VOD0x273 /* Video on Demand */ +#define KEY_UNMUTE 0x274 +#define KEY_FASTREVERSE0x275 +#define KEY_SLOWREVERSE0x276 +/* + * Control a data application associated with the currently viewed channel, + * e.g. teletext or data broadcast application (MHEG, MHP, HbbTV, etc.) + */ +#define KEY_DATA 0x275 + #define BTN_TRIGGER_HAPPY 0x2c0 #define BTN_TRIGGER_HAPPY1 0x2c0 #define BTN_TRIGGER_HAPPY2 0x2c1 -- 2.7.0 -- 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 5/5] [media] media-device: make media_device_cleanup() static
Hello Mauro,
On Wed, Mar 16, 2016 at 11:36 AM, Mauro Carvalho Chehab
wrote:
> Em Wed, 16 Mar 2016 11:03:38 -0300
> Javier Martinez Canillas escreveu:
>
>> Hello Mauro,
>>
>> The patch looks mostly good to me, I just have a question below:
>>
>> On Wed, Mar 16, 2016 at 9:04 AM, Mauro Carvalho Chehab
>> wrote:
>>
>> [snip]
>>
>> >
>> > -void media_device_cleanup(struct media_device *mdev)
>> > +static void media_device_cleanup(struct media_device *mdev)
>> > {
>> > ida_destroy(&mdev->entity_internal_idx);
>> > mdev->entity_internal_idx_max = 0;
>> > media_entity_graph_walk_cleanup(&mdev->pm_count_walk);
>> > - mutex_destroy(&mdev->graph_mutex);
>>
>> Any reason why this is removed? mutex_init() is still called in
>> media_device_init() so I believe the destroy should be kept here.
>
> This code is now called only at do_media_device_unregister, with
> is protected by the mutex. If we keep the mutex_destroy there,
> the mutex will be destroyed in lock state, causing an error if
> mutex debug is enabled.
>
> Btw, the standard implementation for the mutex is:
> include/linux/mutex.h:static inline void mutex_destroy(struct mutex
> *lock) {}
>
> Only when mutex debug is enabled, it becomes something else:
> include/linux/mutex-debug.h:extern void mutex_destroy(struct mutex
> *lock);
>
> With produces a warning if the mutex_destroy() is called with the
> mutex is hold. This can never happen with the current implementation, as
> the logic is:
> mutex_lock(&mdev->graph_mutex);
> kref_put(&mdev->kref, do_media_device_unregister);
> mutex_unlock(&mdev->graph_mutex);
>
> We could eventually move the mutex lock to
> do_media_device_unregister() and then add there the mutex_destroy()
>
I see, thanks a lot for your explanation.
> Regards,
> Mauro
>
Best regards,
Javier
--
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 2/5] [media] media-device: Fix a comment
The comment is for the wrong function. Fix it. Signed-off-by: Mauro Carvalho Chehab --- include/media/media-device.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/media/media-device.h b/include/media/media-device.h index 0c2de97181f3..ca3871b853ba 100644 --- a/include/media/media-device.h +++ b/include/media/media-device.h @@ -490,7 +490,7 @@ int __must_check __media_device_register(struct media_device *mdev, #define media_device_register(mdev) __media_device_register(mdev, THIS_MODULE) /** - * __media_device_unregister() - Unegisters a media device element + *_media_device_unregister() - Unegisters a media device element * * @mdev: pointer to struct &media_device * -- 2.5.0 -- 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 1/3] [media] v4l2-mc.h: Add a S-Video C input PAD to demod enum
On 03/18/2016 04:45 PM, Hans Verkuil wrote:
> On 03/09/2016 08:09 PM, Javier Martinez Canillas wrote:
>> The enum demod_pad_index list the PADs that an analog TV demod has but
>> in some decoders the S-Video Y (luminance) and C (chrominance) signals
>> are carried by different connectors. So a single DEMOD_PAD_IF_INPUT is
>> not enough and an additional PAD is needed in the case of S-Video for
>> the additional C signal.
>>
>> Add a DEMOD_PAD_C_INPUT that can be used for this case and the existing
>> DEMOD_PAD_IF_INPUT can be used for either Composite or the Y signal.
>>
>> Suggested-by: Mauro Carvalho Chehab
>> Signed-off-by: Javier Martinez Canillas
>>
>> ---
>> Hello,
>>
>> This change was suggested by Mauro in [0] although is still not clear
>> if this is the way forward since changing PAD indexes can break the
>> uAPI depending on how the PADs are looked up. Another alternative is
>> to have a PAD type as Mauro mentioned on the same email but since the
>> series are RFC, I'm making this change as an example and hopping that
>> the patches can help with the discussion.
>>
>> [0]: http://www.spinics.net/lists/linux-media/msg98042.html
>>
>> Best regards,
>> Javier
>>
>> include/media/v4l2-mc.h | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/media/v4l2-mc.h b/include/media/v4l2-mc.h
>> index 98a938aabdfb..47c00c288a06 100644
>> --- a/include/media/v4l2-mc.h
>> +++ b/include/media/v4l2-mc.h
>> @@ -94,7 +94,8 @@ enum if_aud_dec_pad_index {
>> * @DEMOD_NUM_PADS: Maximum number of output pads.
>> */
>> enum demod_pad_index {
>> -DEMOD_PAD_IF_INPUT,
>> +DEMOD_PAD_IF_INPUT, /* S-Video Y input or Composite */
>> +DEMOD_PAD_C_INPUT, /* S-Video C input or Composite */
>> DEMOD_PAD_VID_OUT,
>> DEMOD_PAD_VBI_OUT,
>> DEMOD_PAD_AUDIO_OUT,
>>
>
> These pad index enums are butt ugly and won't scale in the long run. An entity
> should have just as many pads as it needs and no more.
>
> If you want to have an heuristic so you can find which pad carries e.g.
> composite video, then it is better to ask the subdev for that.
>
> E.g.: err = v4l2_subdev_call(sd, pad, g_signal_pad, V4L2_PAD_Y_SIG_INPUT,
> &pad)
>
> The subdev driver knows which pad has which signal, so this does not rely on
> hardcoding all combinations of possible pad types and you can still
> heuristically
> build a media graph for legacy drivers.
>
> What we do now is reminiscent of the bad old days when the input numbers (as
> returned by ENUMINPUT) where mapped to the i2c routing (basically pads). I
> worked
> hard to get rid of that hardcoded relationship and I don't like to see it
> coming
> back.
>
> Actually, I am not sure if a new subdev op will work at all. This information
> really belongs to the device tree or card info. Just as it is done today with
> the audio and video s_routing op. The op basically sets up the routing (i.e.
> pads). We didn't have pads (or an MC) when I made that op, but the purpose
> is the same.
>
> Although I guess that a g_signal_pad might be enough in many cases. I don't
> know what is the best solution, to be honest. All I know is that the current
> approach will end in tears.
>
> Hmm, looking at saa7134-cards you have lists of inputs. You could add a
> pad_type
> field there and use the g_signal_pad to obtain the corresponding pad of the
> subdev entity. You'd have pad types TV, COMPOSITE[1-N], SVIDEO[1-N], etc.
>
> Note that input 1 could map to pad type COMPOSITE3 since that all depends on
> how the board is wired up.
>
> But at least this approach doesn't force subdevs to have more pads than they
> need.
Actually, there is really no need for these 'pad types'. Why not just put the
actual pads in the card info? You know that anyway since you have to configure
the routing. So just stick it in the board info structs.
Why this rush to get all this in? Can we at least disable the media device
creation for these usb and pci devices until we are sure we got all the details
right? As long as we don't register the media device these pads aren't used and
we can still make changes.
Let's be honest: nobody is waiting for media devices for these chipsets. We want
it because we want to be consistent and it is great for prototyping, but other
than us no one cares.
This stuff is really hard to get right, and I feel these things are exposed too
soon. And once it is part of the public API it is very hard to revert.
Regards,
Hans
--
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] media: rename media unregister function
On 03/18/2016 07:05 AM, Mauro Carvalho Chehab wrote: > Now that media_device_unregister() also does a cleanup, rename it > to media_device_unregister_cleanup(). > > Signed-off-by: Mauro Carvalho Chehab I think adding cleanup is redundant. media_device_unregister() would imply that there has to be some cleanup releasing resources. I wouldn't make this change. thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- 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
[PATCHv13 16/17] cec: s5p-cec: Add s5p-cec driver
From: Kamil Debski
Add CEC interface driver present in the Samsung Exynos range of
SoCs.
The following files were based on work by SangPil Moon:
- exynos_hdmi_cec.h
- exynos_hdmi_cecctl.c
Signed-off-by: Kamil Debski
Signed-off-by: Hans Verkuil
---
.../devicetree/bindings/media/s5p-cec.txt | 31 +++
MAINTAINERS| 7 +
drivers/media/platform/Kconfig | 12 +
drivers/media/platform/Makefile| 1 +
drivers/media/platform/s5p-cec/Makefile| 2 +
drivers/media/platform/s5p-cec/exynos_hdmi_cec.h | 38 +++
.../media/platform/s5p-cec/exynos_hdmi_cecctrl.c | 210 +++
drivers/media/platform/s5p-cec/regs-cec.h | 96 +++
drivers/media/platform/s5p-cec/s5p_cec.c | 295 +
drivers/media/platform/s5p-cec/s5p_cec.h | 76 ++
10 files changed, 768 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/s5p-cec.txt
create mode 100644 drivers/media/platform/s5p-cec/Makefile
create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
create mode 100644 drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
create mode 100644 drivers/media/platform/s5p-cec/regs-cec.h
create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.c
create mode 100644 drivers/media/platform/s5p-cec/s5p_cec.h
diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt
b/Documentation/devicetree/bindings/media/s5p-cec.txt
new file mode 100644
index 000..925ab4d
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/s5p-cec.txt
@@ -0,0 +1,31 @@
+* Samsung HDMI CEC driver
+
+The HDMI CEC module is present is Samsung SoCs and its purpose is to
+handle communication between HDMI connected devices over the CEC bus.
+
+Required properties:
+ - compatible : value should be following
+ "samsung,s5p-cec"
+
+ - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+
+ - interrupts : HDMI CEC interrupt number to the CPU.
+ - clocks : from common clock binding: handle to HDMI CEC clock.
+ - clock-names : from common clock binding: must contain "hdmicec",
+ corresponding to entry in the clocks property.
+ - samsung,syscon-phandle - phandle to the PMU system controller
+
+Example:
+
+hdmicec: cec@100B {
+ compatible = "samsung,s5p-cec";
+ reg = <0x100B 0x200>;
+ interrupts = <0 114 0>;
+ clocks = <&clock CLK_HDMI_CEC>;
+ clock-names = "hdmicec";
+ samsung,syscon-phandle = <&pmu_system_controller>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_cec>;
+ status = "okay";
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 9b10806..1eb422b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1543,6 +1543,13 @@ L: linux-media@vger.kernel.org
S: Maintained
F: drivers/media/platform/s5p-tv/
+ARM/SAMSUNG S5P SERIES HDMI CEC SUBSYSTEM SUPPORT
+M: Kyungmin Park
+L: linux-arm-ker...@lists.infradead.org
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/media/platform/s5p-cec/
+
ARM/SAMSUNG S5P SERIES JPEG CODEC SUPPORT
M: Andrzej Pietrasiewicz
M: Jacek Anaszewski
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 201f5c2..8a5597e 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -108,6 +108,18 @@ config VIDEO_S3C_CAMIF
source "drivers/media/platform/soc_camera/Kconfig"
source "drivers/media/platform/exynos4-is/Kconfig"
source "drivers/media/platform/s5p-tv/Kconfig"
+
+config VIDEO_SAMSUNG_S5P_CEC
+ tristate "Samsung S5P CEC driver"
+ depends on VIDEO_DEV && VIDEO_V4L2 && (PLAT_S5P || ARCH_EXYNOS ||
COMPILE_TEST)
+ select MEDIA_CEC
+ default n
+ ---help---
+ This is a driver for Samsung S5P HDMI CEC interface. It uses the
+ generic CEC framework interface.
+ CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
source "drivers/media/platform/am437x/Kconfig"
source "drivers/media/platform/xilinx/Kconfig"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index bbb7bd1..f598c80 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE) +=
m2m-deinterlace.o
obj-$(CONFIG_VIDEO_S3C_CAMIF) += s3c-camif/
obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS4_IS) += exynos4-is/
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV) += s5p-tv/
diff --git a/drivers/media/platform/s5p-cec/Makefile
b/drivers/media/platform/s5p-cec/Makefile
new file mode 100644
index 000..0e2cf45
--- /dev/null
+++ b/drivers/media/platform/s5p-cec/Makefile
@@ -0,0
Re: [PATCH] media: rc: reduce size of struct ir_raw_event
On Thu, Mar 17, 2016 at 07:40:59AM +0100, Heiner Kallweit wrote: > Am 16.03.2016 um 23:28 schrieb Sean Young: > > On Wed, Mar 16, 2016 at 10:18:38PM +0100, Heiner Kallweit wrote: > >> + u8 pulse:1; > >> + u8 reset:1; > >> + u8 timeout:1; > >> + u8 carrier_report:1; > > > > Why are you changing the type of the bitfields? > > > I did this to make sure that the compiler uses one byte for > the bit field. When testing gcc also used just one byte when > keeping the original "unsigned" type for the bit field members. > Therefore it wouldn't be strictly neeeded. > > But I'm not sure whether it's guaranteed that the compiler packs a > bit field to the smallest possible data type and we can rely on it. > AFAIK C99 is a little more specific about this implementation detail of > bit fields but C89/C90 is used for kernel compilation. It might be worth reading about structure packing rules rather than guessing. Sean -- 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] [media] media: rename media unregister function
Now that media_device_unregister() also does a cleanup, rename it
to media_device_unregister_cleanup().
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/common/siano/smsdvb-main.c | 2 +-
drivers/media/media-device.c | 4 ++--
drivers/media/pci/saa7134/saa7134-core.c | 2 +-
drivers/media/platform/exynos4-is/media-dev.c| 4 ++--
drivers/media/platform/omap3isp/isp.c| 2 +-
drivers/media/platform/s3c-camif/camif-core.c| 4 ++--
drivers/media/platform/vsp1/vsp1_drv.c | 2 +-
drivers/media/platform/xilinx/xilinx-vipp.c | 4 ++--
drivers/media/usb/au0828/au0828-core.c | 2 +-
drivers/media/usb/cx231xx/cx231xx-cards.c| 2 +-
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 2 +-
drivers/media/usb/dvb-usb/dvb-usb-dvb.c | 2 +-
drivers/media/usb/em28xx/em28xx-cards.c | 2 +-
drivers/media/usb/siano/smsusb.c | 4 ++--
drivers/media/usb/uvc/uvc_driver.c | 2 +-
drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c | 4 ++--
drivers/staging/media/omap4iss/iss.c | 2 +-
include/media/media-device.h | 6 +++---
include/media/media-entity.h | 2 +-
sound/usb/media.c| 2 +-
20 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/drivers/media/common/siano/smsdvb-main.c
b/drivers/media/common/siano/smsdvb-main.c
index 711c389c05e3..26184f84f41b 100644
--- a/drivers/media/common/siano/smsdvb-main.c
+++ b/drivers/media/common/siano/smsdvb-main.c
@@ -616,7 +616,7 @@ static void smsdvb_media_device_unregister(struct
smsdvb_client_t *client)
if (!coredev->media_dev)
return;
- media_device_unregister(coredev->media_dev);
+ media_device_unregister_cleanup(coredev->media_dev);
kfree(coredev->media_dev);
coredev->media_dev = NULL;
#endif
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 070421e4d32e..9076439abc5f 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -822,7 +822,7 @@ printk("%s: mdev=%p\n", __func__, mdev);
dev_dbg(mdev->dev, "Media device unregistered\n");
}
-void media_device_unregister(struct media_device *mdev)
+void media_device_unregister_cleanup(struct media_device *mdev)
{
printk("%s: mdev=%p\n", __func__, mdev);
if (mdev == NULL)
@@ -833,7 +833,7 @@ printk("%s: mdev=%p\n", __func__, mdev);
mutex_unlock(&mdev->graph_mutex);
}
-EXPORT_SYMBOL_GPL(media_device_unregister);
+EXPORT_SYMBOL_GPL(media_device_unregister_cleanup);
static void media_device_release_devres(struct device *dev, void *res)
{
diff --git a/drivers/media/pci/saa7134/saa7134-core.c
b/drivers/media/pci/saa7134/saa7134-core.c
index 213dc71f09eb..5f08cb22fb1a 100644
--- a/drivers/media/pci/saa7134/saa7134-core.c
+++ b/drivers/media/pci/saa7134/saa7134-core.c
@@ -812,7 +812,7 @@ static void saa7134_unregister_media_device(struct
saa7134_dev *dev)
#ifdef CONFIG_MEDIA_CONTROLLER
if (!dev->media_dev)
return;
- media_device_unregister(dev->media_dev);
+ media_device_unregister_cleanup(dev->media_dev);
kfree(dev->media_dev);
dev->media_dev = NULL;
#endif
diff --git a/drivers/media/platform/exynos4-is/media-dev.c
b/drivers/media/platform/exynos4-is/media-dev.c
index 8c106fda7b84..e968523e0b5c 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -1501,7 +1501,7 @@ err_clk:
err_m_ent:
fimc_md_unregister_entities(fmd);
err_md:
- media_device_unregister(&fmd->media_dev);
+ media_device_unregister_cleanup(&fmd->media_dev);
v4l2_device_unregister(&fmd->v4l2_dev);
return ret;
}
@@ -1520,7 +1520,7 @@ static int fimc_md_remove(struct platform_device *pdev)
device_remove_file(&pdev->dev, &dev_attr_subdev_conf_mode);
fimc_md_unregister_entities(fmd);
fimc_md_pipelines_free(fmd);
- media_device_unregister(&fmd->media_dev);
+ media_device_unregister_cleanup(&fmd->media_dev);
fimc_md_put_clocks(fmd);
return 0;
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index cd67edcad8d3..b8fe65fb06cb 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -1597,7 +1597,7 @@ static void isp_unregister_entities(struct isp_device
*isp)
omap3isp_stat_unregister_entities(&isp->isp_hist);
v4l2_device_unregister(&isp->v4l2_dev);
- media_device_unregister(&isp->media_dev);
+ media_device_unregister_cleanup(&isp->media_dev);
}
static int isp_link_entity(
diff --git a/drivers/media/platform/s3c-camif/camif-core.c
b/drivers/media/platform/s3c-camif/camif-core.c
index 0159f98da435..303a84d7f4ec 100644
---
[PATCHv13 14/17] cec: adv7511: add cec support.
Add CEC support to the adv7511 driver.
Signed-off-by: Hans Verkuil
[k.deb...@samsung.com: Merged changes from CEC Updates commit by Hans Verkuil]
Signed-off-by: Kamil Debski
Signed-off-by: Hans Verkuil
---
drivers/media/i2c/Kconfig | 2 +-
drivers/media/i2c/adv7511.c | 356 +++-
include/media/i2c/adv7511.h | 6 +-
3 files changed, 350 insertions(+), 14 deletions(-)
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 11ca81c..98edc74 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -445,7 +445,7 @@ config VIDEO_ADV7393
config VIDEO_ADV7511
tristate "Analog Devices ADV7511 encoder"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && MEDIA_CEC
select HDMI
---help---
Support for the Analog Devices ADV7511 video encoder.
diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
index bd822f0..cee768b 100644
--- a/drivers/media/i2c/adv7511.c
+++ b/drivers/media/i2c/adv7511.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
static int debug;
module_param(debug, int, 0644);
@@ -59,6 +60,8 @@ MODULE_LICENSE("GPL v2");
#define ADV7511_MIN_PIXELCLOCK 2000
#define ADV7511_MAX_PIXELCLOCK 22500
+#define ADV7511_MAX_ADDRS (3)
+
/*
**
*
@@ -90,12 +93,19 @@ struct adv7511_state {
struct v4l2_ctrl_handler hdl;
int chip_revision;
u8 i2c_edid_addr;
- u8 i2c_cec_addr;
u8 i2c_pktmem_addr;
+ u8 i2c_cec_addr;
+
+ struct i2c_client *i2c_cec;
+ u8 cec_addr[ADV7511_MAX_ADDRS];
+ u8 cec_valid_addrs;
+ bool cec_enabled_adap;
+
/* Is the adv7511 powered on? */
bool power_on;
/* Did we receive hotplug and rx-sense signals? */
bool have_monitor;
+ bool enabled_irq;
/* timings from s_dv_timings */
struct v4l2_dv_timings dv_timings;
u32 fmt_code;
@@ -227,7 +237,7 @@ static int adv_smbus_read_i2c_block_data(struct i2c_client
*client,
return ret;
}
-static inline void adv7511_edid_rd(struct v4l2_subdev *sd, u16 len, u8 *buf)
+static void adv7511_edid_rd(struct v4l2_subdev *sd, uint16_t len, uint8_t *buf)
{
struct adv7511_state *state = get_adv7511_state(sd);
int i;
@@ -242,6 +252,34 @@ static inline void adv7511_edid_rd(struct v4l2_subdev *sd,
u16 len, u8 *buf)
v4l2_err(sd, "%s: i2c read error\n", __func__);
}
+static inline int adv7511_cec_read(struct v4l2_subdev *sd, u8 reg)
+{
+ struct adv7511_state *state = get_adv7511_state(sd);
+
+ return i2c_smbus_read_byte_data(state->i2c_cec, reg);
+}
+
+static int adv7511_cec_write(struct v4l2_subdev *sd, u8 reg, u8 val)
+{
+ struct adv7511_state *state = get_adv7511_state(sd);
+ int ret;
+ int i;
+
+ for (i = 0; i < 3; i++) {
+ ret = i2c_smbus_write_byte_data(state->i2c_cec, reg, val);
+ if (ret == 0)
+ return 0;
+ }
+ v4l2_err(sd, "%s: I2C Write Problem\n", __func__);
+ return ret;
+}
+
+static inline int adv7511_cec_write_and_or(struct v4l2_subdev *sd, u8 reg, u8
mask,
+ u8 val)
+{
+ return adv7511_cec_write(sd, reg, (adv7511_cec_read(sd, reg) & mask) |
val);
+}
+
static int adv7511_pktmem_rd(struct v4l2_subdev *sd, u8 reg)
{
struct adv7511_state *state = get_adv7511_state(sd);
@@ -425,16 +463,28 @@ static const struct v4l2_ctrl_ops adv7511_ctrl_ops = {
#ifdef CONFIG_VIDEO_ADV_DEBUG
static void adv7511_inv_register(struct v4l2_subdev *sd)
{
+ struct adv7511_state *state = get_adv7511_state(sd);
+
v4l2_info(sd, "0x000-0x0ff: Main Map\n");
+ if (state->i2c_cec)
+ v4l2_info(sd, "0x100-0x1ff: CEC Map\n");
}
static int adv7511_g_register(struct v4l2_subdev *sd, struct v4l2_dbg_register
*reg)
{
+ struct adv7511_state *state = get_adv7511_state(sd);
+
reg->size = 1;
switch (reg->reg >> 8) {
case 0:
reg->val = adv7511_rd(sd, reg->reg & 0xff);
break;
+ case 1:
+ if (state->i2c_cec) {
+ reg->val = adv7511_cec_read(sd, reg->reg & 0xff);
+ break;
+ }
+ /* fall through */
default:
v4l2_info(sd, "Register %03llx not supported\n", reg->reg);
adv7511_inv_register(sd);
@@ -445,10 +495,18 @@ static int adv7511_g_register(struct v4l2_subdev *sd,
struct v4l2_dbg_register *
static int adv7511_s_register(struct v4l2_subdev *sd, const struct
v4l2_dbg_register *reg)
{
+ struct adv7511_state *state = get_adv7511_state(sd);
+
switch (reg->reg >> 8) {
case 0:
adv7511_wr(sd, reg->reg & 0xff, reg->va
[PATCH] media: rc: reduce size of struct ir_raw_event
struct ir_raw_event currently has a size of 12 bytes on most (all?)
architectures. This can be reduced to 8 bytes whilst maintaining
full backwards compatibility.
This saves 2KB in size of struct ir_raw_event_ctrl (as element
kfifo is reduced by 512 * 4 bytes) and it allows to copy the
full struct ir_raw_event with a single 64 bit operation.
Successfully tested with the Nuvoton driver and successfully
compile-tested with the ene_ir driver (as it uses the carrier /
duty_cycle elements).
Signed-off-by: Heiner Kallweit
---
include/media/rc-core.h | 26 --
1 file changed, 8 insertions(+), 18 deletions(-)
diff --git a/include/media/rc-core.h b/include/media/rc-core.h
index 0f77b3d..b8f27c9 100644
--- a/include/media/rc-core.h
+++ b/include/media/rc-core.h
@@ -214,27 +214,17 @@ enum raw_event_type {
struct ir_raw_event {
union {
- u32 duration;
-
- struct {
- u32 carrier;
- u8 duty_cycle;
- };
+ u32 duration;
+ u32 carrier;
};
-
- unsignedpulse:1;
- unsignedreset:1;
- unsignedtimeout:1;
- unsignedcarrier_report:1;
+ u8 duty_cycle;
+ u8 pulse:1;
+ u8 reset:1;
+ u8 timeout:1;
+ u8 carrier_report:1;
};
-#define DEFINE_IR_RAW_EVENT(event) \
- struct ir_raw_event event = { \
- { .duration = 0 } , \
- .pulse = 0, \
- .reset = 0, \
- .timeout = 0, \
- .carrier_report = 0 }
+#define DEFINE_IR_RAW_EVENT(event) struct ir_raw_event event = {}
static inline void init_ir_raw_event(struct ir_raw_event *ev)
{
--
2.7.3
--
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] dma-buf,drm,ion: Propagate error code from dma_buf_start_cpu_access()
Drivers, especially i915.ko, can fail during the initial migration of a
dma-buf for CPU access. However, the error code from the driver was not
being propagated back to ioctl and so userspace was blissfully ignorant
of the failure. Rendering corruption ensues.
Whilst fixing the ioctl to return the error code from
dma_buf_start_cpu_access(), also do the same for
dma_buf_end_cpu_access(). For most drivers, dma_buf_end_cpu_access()
cannot fail. i915.ko however, as most drivers would, wants to avoid being
uninterruptible (as would be required to guarrantee no failure when
flushing the buffer to the device). As userspace already has to handle
errors from the SYNC_IOCTL, take advantage of this to be able to restart
the syscall across signals.
This fixes a coherency issue for i915.ko as well as reducing the
uninterruptible hold upon its BKL, the struct_mutex.
Fixes commit c11e391da2a8fe973c3c2398452000bed505851e
Author: Daniel Vetter
Date: Thu Feb 11 20:04:51 2016 -0200
dma-buf: Add ioctls to allow userspace to flush
Testcase: igt/gem_concurrent_blit/*dmabuf*interruptible
Testcase: igt/prime_mmap_coherency/ioctl-errors
Signed-off-by: Chris Wilson
Cc: Tiago Vignatti
Cc: Stéphane Marchesin
Cc: David Herrmann
Cc: Sumit Semwal
Cc: Daniel Vetter
CC: linux-media@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc: intel-...@lists.freedesktop.org
Cc: de...@driverdev.osuosl.org
---
drivers/dma-buf/dma-buf.c | 17 +++--
drivers/gpu/drm/i915/i915_gem_dmabuf.c| 15 +--
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 5 +++--
drivers/gpu/drm/udl/udl_fb.c | 4 ++--
drivers/staging/android/ion/ion.c | 6 --
include/linux/dma-buf.h | 6 +++---
6 files changed, 28 insertions(+), 25 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 9810d1df0691..774a60f4309a 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -259,6 +259,7 @@ static long dma_buf_ioctl(struct file *file,
struct dma_buf *dmabuf;
struct dma_buf_sync sync;
enum dma_data_direction direction;
+ int ret;
dmabuf = file->private_data;
@@ -285,11 +286,11 @@ static long dma_buf_ioctl(struct file *file,
}
if (sync.flags & DMA_BUF_SYNC_END)
- dma_buf_end_cpu_access(dmabuf, direction);
+ ret = dma_buf_end_cpu_access(dmabuf, direction);
else
- dma_buf_begin_cpu_access(dmabuf, direction);
+ ret = dma_buf_begin_cpu_access(dmabuf, direction);
- return 0;
+ return ret;
default:
return -ENOTTY;
}
@@ -613,13 +614,17 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
*
* This call must always succeed.
*/
-void dma_buf_end_cpu_access(struct dma_buf *dmabuf,
- enum dma_data_direction direction)
+int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
+ enum dma_data_direction direction)
{
+ int ret = 0;
+
WARN_ON(!dmabuf);
if (dmabuf->ops->end_cpu_access)
- dmabuf->ops->end_cpu_access(dmabuf, direction);
+ ret = dmabuf->ops->end_cpu_access(dmabuf, direction);
+
+ return ret;
}
EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 1f3eef6fb345..0506016e18e0 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -228,25 +228,20 @@ static int i915_gem_begin_cpu_access(struct dma_buf
*dma_buf, enum dma_data_dire
return ret;
}
-static void i915_gem_end_cpu_access(struct dma_buf *dma_buf, enum
dma_data_direction direction)
+static int i915_gem_end_cpu_access(struct dma_buf *dma_buf, enum
dma_data_direction direction)
{
struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
struct drm_device *dev = obj->base.dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
- bool was_interruptible;
int ret;
- mutex_lock(&dev->struct_mutex);
- was_interruptible = dev_priv->mm.interruptible;
- dev_priv->mm.interruptible = false;
+ ret = i915_mutex_lock_interruptible(dev);
+ if (ret)
+ return ret;
ret = i915_gem_object_set_to_gtt_domain(obj, false);
-
- dev_priv->mm.interruptible = was_interruptible;
mutex_unlock(&dev->struct_mutex);
- if (unlikely(ret))
- DRM_ERROR("unable to flush buffer following CPU access;
rendering may be corrupt\n");
+ return ret;
}
static const struct dma_buf_ops i915_dmabuf_ops = {
diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
index 3cf8aab23a39..af267c35d813 100644
--- a/drivers/gpu/drm/omap
Re: [alsa-devel] [PATCH] sound/usb: Fix memory leak in media_snd_stream_delete() during unbind
On Thu, 17 Mar 2016 03:58:06 +0100,
Shuah Khan wrote:
>
> media_snd_stream_delete() fails to release resources during unbind. This
> leads to use-after-free in media_gobj_create() on a subsequent bind.
>
> [ 1445.086410] BUG: KASAN: use-after-free in media_gobj_create+0x3a1/0x470
> [media] at addr 8801ead49998
>
> [ 1445.086771] Call Trace:
> [ 1445.086779] [] dump_stack+0x67/0x94
> [ 1445.086785] [] print_trailer+0xf9/0x150
> [ 1445.086790] [] object_err+0x34/0x40
> [ 1445.086796] [] kasan_report_error+0x221/0x530
> [ 1445.086803] [] __asan_report_store8_noabort+0x43/0x50
> [ 1445.086813] [] ? media_gobj_create+0x3a1/0x470 [media]
> [ 1445.086822] [] media_gobj_create+0x3a1/0x470 [media]
> [ 1445.086831] [] media_device_register_entity+0x259/0x6f0
> [media]
> [ 1445.086841] [] ?
> media_device_unregister_entity_notify+0x100/0x100 [media]
> [ 1445.086846] [] ? ___slab_alloc+0x172/0x500
> [ 1445.086854] [] ? mark_held_locks+0xc8/0x120
> [ 1445.086859] [] ? __slab_alloc+0x50/0x70
> [ 1445.086878] [] ? media_snd_mixer_init+0x16c/0x500
> [snd_usb_audio]
> [ 1445.086884] [] ? kasan_unpoison_shadow+0x36/0x50
> [ 1445.086890] [] ? kasan_unpoison_shadow+0x36/0x50
> [ 1445.086895] [] ? kasan_kmalloc+0x5e/0x70
>
> Signed-off-by: Shuah Khan
Mauro, please take it through your tree.
Acked-by: Takashi Iwai
thanks,
Takashi
> ---
> sound/usb/media.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/usb/media.c b/sound/usb/media.c
> index 44a5de9..0d03773 100644
> --- a/sound/usb/media.c
> +++ b/sound/usb/media.c
> @@ -135,7 +135,7 @@ void media_snd_stream_delete(struct snd_usb_substream
> *subs)
> if (mctl && mctl->media_dev) {
> struct media_device *mdev;
>
> - mdev = subs->stream->chip->media_dev;
> + mdev = mctl->media_dev;
> if (mdev && media_devnode_is_registered(&mdev->devnode)) {
> media_devnode_remove(mctl->intf_devnode);
> media_device_unregister_entity(&mctl->media_entity);
> --
> 2.5.0
>
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
--
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 2/5] [media] media-device: Fix a comment
Hello Mauro, On Wed, Mar 16, 2016 at 9:04 AM, Mauro Carvalho Chehab wrote: > The comment is for the wrong function. Fix it. > > Signed-off-by: Mauro Carvalho Chehab > --- > include/media/media-device.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/media/media-device.h b/include/media/media-device.h > index 0c2de97181f3..ca3871b853ba 100644 > --- a/include/media/media-device.h > +++ b/include/media/media-device.h > @@ -490,7 +490,7 @@ int __must_check __media_device_register(struct > media_device *mdev, > #define media_device_register(mdev) __media_device_register(mdev, > THIS_MODULE) > > /** > - * __media_device_unregister() - Unegisters a media device element > + *_media_device_unregister() - Unegisters a media device element > * s/_media_device_unregister()/media_device_unregister() and while being there, you can also fix the "Unegisters" typo. After those changes: Reviewed-by: Javier Martinez Canillas Best regards, Javier -- 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
[RFCv1 PATCH 1/2] tc358840: add Toshiba HDMI-to-CSI bridge driver
From: Hans Verkuil
First draft version.
This driver was created by Armin Weiss and cleaned up, rebased and 4k
support finalized by Hans Verkuil.
Signed-off-by: Armin Weiss
Signed-off-by: Hans Verkuil
---
.../devicetree/bindings/media/i2c/tc358840.txt | 50 +
MAINTAINERS|7 +
drivers/media/i2c/Kconfig | 10 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/tc358840.c | 2341
drivers/media/i2c/tc358840_regs.h | 726 ++
include/media/i2c/tc358840.h | 89 +
7 files changed, 3224 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/tc358840.txt
create mode 100644 drivers/media/i2c/tc358840.c
create mode 100644 drivers/media/i2c/tc358840_regs.h
create mode 100644 include/media/i2c/tc358840.h
diff --git a/Documentation/devicetree/bindings/media/i2c/tc358840.txt
b/Documentation/devicetree/bindings/media/i2c/tc358840.txt
new file mode 100644
index 000..b2a2544
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tc358840.txt
@@ -0,0 +1,50 @@
+* Toshiba TC358840 HDMI-RX to MIPI CSI2-TX Bridge
+
+The Toshiba TC358840 HDMI-RX to MIPI CSI2-TX (H2C) is a bridge that converts
+a HDMI stream to MIPI CSI-2 TX. It is programmable through I2C.
+
+Required Properties:
+
+- compatible: value should be "toshiba,tc358840"
+- clocks, clock-names: should contain a phandle link to the reference clock
+ source, the clock input is named "refclk".
+
+Optional Properties:
+
+- reset-gpios: gpio phandle GPIO connected to the reset pin
+- interrupts, interrupt-parent: GPIO connected to the interrupt pin
+- data-lanes: should be <1 2 3 4> for four-lane operation,
+ or <1 2> for two-lane operation
+- clock-lanes: should be <0>
+- clock-noncontinuous: Presence of this boolean property decides whether the
+ MIPI CSI-2 clock is continuous or non-continuous.
+- link-frequencies: List of allowed link frequencies in Hz. Each frequency is
+ expressed as a 64-bit big-endian integer. The frequency
+ is half of the bps per lane due to DDR transmission.
+- csi_port: which CSI ports can be used: 1 = TX0, 2 = TX1, 3 = TX0 + TX1.
+
+For further information on the MIPI CSI-2 endpoint node properties, see
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ tc358840@0f {
+ compatible = "toshiba,tc358840";
+ reg = <0x0f>;
+ clocks = <&hdmi_osc>;
+ clock-names = "refclk";
+ reset-gpios = <&gpio6 9 GPIO_ACTIVE_LOW>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
+ csi_port = <3>;
+
+ port {
+ tc358840_out: endpoint {
+ remote-endpoint = <&mipi_csi2_in>;
+ data-lanes = <1 2 3 4>;
+ clock-lanes = <0>;
+ clock-noncontinuous;
+ link-frequencies = /bits/ 64 <29700>;
+ };
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 1df5b8e..ac63d7d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11053,6 +11053,13 @@ S: Maintained
F: drivers/media/i2c/tc358743*
F: include/media/i2c/tc358743.h
+TOSHIBA TC358840 DRIVER
+M: Hans Verkuil
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/media/i2c/tc358840*
+F: include/media/i2c/tc358840.h
+
TMIO MMC DRIVER
M: Ian Molton
L: linux-...@vger.kernel.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 98edc74..1fd6057 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -307,6 +307,16 @@ config VIDEO_TC358743
To compile this driver as a module, choose M here: the
module will be called tc358743.
+config VIDEO_TC358840
+ tristate "Toshiba TC358840 decoder"
+ depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ select HDMI
+ ---help---
+ Support for the Toshiba TC358840 HDMI to MIPI CSI-2 bridge.
+
+ To compile this driver as a module, choose M here: the
+ module will be called tc358840.
+
config VIDEO_TVP514X
tristate "Texas Instruments TVP514x video decoder"
depends on VIDEO_V4L2 && I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 94f2c99..384e8a3 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -80,3 +80,4 @@ obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
obj-$(CONFIG_VIDEO_ML86V7667) += ml86v7667.o
obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
obj-$(CONFIG_VIDEO_TC358743) += tc358743.o
+obj-$(CONFIG_VIDEO_TC358840) += tc358840.o
diff --git a/drivers/media/i2
Re: [PATCH 4/5] [media] media-device: use kref for media_device instance
Hi Mauro, On Wed, Mar 16, 2016 at 09:04:05AM -0300, Mauro Carvalho Chehab wrote: > Now that the media_device can be used by multiple drivers, > via devres, we need to be sure that it will be dropped only > when all drivers stop using it. > > Signed-off-by: Mauro Carvalho Chehab For patches 2 (assuming fixes according to Javier's comment), 4 and 5, and "[media] media: rename media unregister function": Acked-by: Sakari Ailus -- 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] fence: add missing descriptions for fence
Commit b55b54b5db33 ("staging/android: remove struct sync_pt")
added the members child_list and active_list to the fence struct, but
didn't add descriptions for these. Adding the descriptions.
Signed-off-by: Luis de Bethencourt
---
Hi,
Noticed this missing descriptions when running make htmldocs.
Got the following warnings:
.//include/linux/fence.h:84: warning: No description found for parameter
'child_list'
.//include/linux/fence.h:84: warning: No description found for parameter
'active_list'
Thanks :)
Luis
include/linux/fence.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/fence.h b/include/linux/fence.h
index 2b17698..2056e9f 100644
--- a/include/linux/fence.h
+++ b/include/linux/fence.h
@@ -49,6 +49,8 @@ struct fence_cb;
* @timestamp: Timestamp when the fence was signaled.
* @status: Optional, only valid if < 0, must be set before calling
* fence_signal, indicates that the fence has completed with an error.
+ * @child_list: list of children fences
+ * @active_list: list of active fences
*
* the flags member must be manipulated and read using the appropriate
* atomic ops (bit_*), so taking the spinlock will not be needed most
--
2.5.1
--
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] media: fix media_device_unregister() to destroy media device device resource
When all drivers except usb-core driver is unbound, destroy the media device
resource. Other wise, media device resource will persist in a defunct state.
This leads to use-after-free and bad access errors during a subsequent bind.
Fix it to destroy the media device resource when last reference is released
in media_device_unregister().
Signed-off-by: Shuah Khan
---
drivers/media/media-device.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 070421e..7312612 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -822,22 +822,38 @@ printk("%s: mdev=%p\n", __func__, mdev);
dev_dbg(mdev->dev, "Media device unregistered\n");
}
+static void media_device_release_devres(struct device *dev, void *res)
+{
+}
+
+static void media_device_destroy_devres(struct device *dev)
+{
+ int ret;
+
+ ret = devres_destroy(dev, media_device_release_devres, NULL, NULL);
+ pr_debug("%s: devres_destroy() returned %d\n", __func__, ret);
+}
+
void media_device_unregister(struct media_device *mdev)
{
+ int ret;
+ struct device *dev;
printk("%s: mdev=%p\n", __func__, mdev);
if (mdev == NULL)
return;
- mutex_lock(&mdev->graph_mutex);
- kref_put(&mdev->kref, do_media_device_unregister);
- mutex_unlock(&mdev->graph_mutex);
+ ret = kref_put_mutex(&mdev->kref, do_media_device_unregister,
+&mdev->graph_mutex);
+ if (ret) {
+ /* do_media_device_unregister() has run */
+ dev = mdev->dev;
+ mutex_unlock(&mdev->graph_mutex);
+ media_device_destroy_devres(dev);
+ }
}
EXPORT_SYMBOL_GPL(media_device_unregister);
-static void media_device_release_devres(struct device *dev, void *res)
-{
-}
struct media_device *media_device_get_devres(struct device *dev)
{
--
2.5.0
--
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 v3 06/22] media: Media Controller enable/disable source handler API
Hi Shuah,
I see that the patches have been merged to media-tree.git master and
subsequently a pull request has been sent to Linus including them, but the
remaining issues still need to be fixed. Some matters should be discussed
further on the list.
On Mon, Mar 14, 2016 at 09:22:12AM -0600, Shuah Khan wrote:
> On 03/13/2016 02:11 PM, Sakari Ailus wrote:
> > Hi Shuah,
> >
> > On Thu, Mar 10, 2016 at 07:29:59AM -0700, Shuah Khan wrote:
> >> On 03/10/2016 12:35 AM, Sakari Ailus wrote:
> >>> Hi Shuah,
> >>>
> >>> On Thu, Feb 11, 2016 at 04:41:22PM -0700, Shuah Khan wrote:
> Add new fields to struct media_device to add enable_source, and
> disable_source handlers, and source_priv to stash driver private
> data that is used to run these handlers. The enable_source handler
> finds source entity for the passed in entity and checks if it is
> available. When link is found, it activates it. Disable source
> handler deactivates the link.
>
> Bridge driver is expected to implement and set these handlers.
>
> Signed-off-by: Shuah Khan
> ---
> include/media/media-device.h | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/include/media/media-device.h b/include/media/media-device.h
> index 075a482..1a04644 100644
> --- a/include/media/media-device.h
> +++ b/include/media/media-device.h
> @@ -302,6 +302,11 @@ struct media_entity_notify {
> * @entity_notify: List of registered entity_notify callbacks
> * @lock: Entities list lock
> * @graph_mutex: Entities graph operation lock
> + *
> + * @source_priv: Driver Private data for enable/disable source handlers
> + * @enable_source: Enable Source Handler function pointer
> + * @disable_source: Disable Source Handler function pointer
> + *
> * @link_notify: Link state change notification callback
> *
> * This structure represents an abstract high-level media device. It
> allows easy
> @@ -313,6 +318,26 @@ struct media_entity_notify {
> *
> * @model is a descriptive model name exported through sysfs. It
> doesn't have to
> * be unique.
> + *
> + * @enable_source is a handler to find source entity for the
> + * sink entity and activate the link between them if source
> + * entity is free. Drivers should call this handler before
> + * accessing the source.
> + *
> + * @disable_source is a handler to find source entity for the
> + * sink entity and deactivate the link between them. Drivers
> + * should call this handler to release the source.
> + *
> >>>
> >>> Is there a particular reason you're not simply (de)activating the link,
> >>> but
> >>> instead add a new callback?
> >>
> >> These two handlers are separate for a couple of reasons:
> >>
> >> 1. Explicit and symmetric API is easier to use and maintain.
> >>Similar what we do in other cases, register/unregister
> >>get/put etc.
> >
> > Link state is set explicitly (enabled or disabled). This is certainly not a
> > reason to create a redundant API for link setup.
> >
> >> 2. This is more important. Disable handler makes sure the
> >>owner is releasing the resource. Otherwise, when some
> >>other application does enable, the owner could loose
> >>the resource, if enable and disable are the same.
> >>
> >>e.g: Video app is holding the resource, DVB app does
> >>enable. Disable handler makes sure Video/owner is the one
> >>that is asking to do the release.
> >
> > Based on the later patches in this set, the enable_source() callback of the
> > au0828 driver performs three things:
> >
> > - Find the source entity,
> > - Enable the link from some au0828 entity to the source and
> > - Start the pipeline that begins from the I/O device node. The pipe object
> > is embedded in struct video_device.
> >
> > disable_source() undoes this in reverse order.
> >
> > That's in the au0828 driver and rightly so.
> >
> > Then it gets murkier. enable_source() and disable_source() callbacks
> > (through a few turns) will get called from v4l2-ioctl.c functions
> > v4l_querycap, v4l_s_fmt, v4l_s_frequency, v4l_s_std and v4l_querystd. This
> > is also performed in VB2 core vb2_core_streamon() function.
> >
> > I certainly have no objections when it comes to blocking other processes
> > from setting the format when a process holding a file handle to a device has
> > e.g. set the format. The implementation is another matter.
> >
> > What particularly does concern me in this patchset is:
> >
> > - struct media_pipe is intended to be allocated by drivers embedded in
> > another struct holding information the driver needs related to the
> > pipeline. Moving this struct to struct video_device prevents this, which
> > translates to v4l_enable_media_source() and v4l_disable_media_source()
> > functions the patch
Re: STK1160 - no video
Well, I just tried, and failed to reproduce those kernel log messages. There is a comment in one of the source file about "spammy" messages that show up if there is mismatch between the actual and expected video standards. I don't think I had them mismatched before, but maybe I did. Or maybe after all my mucking around I had managed to get the adapter in a weird state. So, for now, that patch seems to be all that is needed. Kevin On Fri, Mar 18, 2016 at 7:11 PM, Ezequiel Garcia wrote: > Hey Kevin, > > On 4 March 2016 at 00:11, Kevin Fitch wrote: >> Here is a quick patch that gives me actual video. That being said I >> see some curious stuff being logged while video is streaming: >> > > Patch looks more or less good, but that kernel log is not good. > > It indicates that the USB packet is not entirely sane, and so the incoming > data is not what the driver is expecting. > > Have you been able to make any progress with it? > -- > Ezequiel García, VanguardiaSur > www.vanguardiasur.com.ar -- 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] media: rename media unregister function
Hello Shuah, On 03/18/2016 11:01 AM, Shuah Khan wrote: > On 03/18/2016 07:05 AM, Mauro Carvalho Chehab wrote: >> Now that media_device_unregister() also does a cleanup, rename it >> to media_device_unregister_cleanup(). >> >> Signed-off-by: Mauro Carvalho Chehab > > I think adding cleanup is redundant. media_device_unregister() > would imply that there has to be some cleanup releasing resources. > I wouldn't make this change. > Problem is that there is a media_device_init() and media_device_register(), so having both unregister and cleanup in this function will make very clear that a single function is the counter part of the previous two operations. > thanks, > -- Shuah > Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- 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] pctv452e: correct parameters for TechnoTrend TT S2-3600
2008-02-25 Andre Weidemann added support for TT S2-3600 and noted
that he still gets image distortions every now and then.
It seems to be common knowledge in many projects that changing
the USB parameters seems to help. OpenELEC has included this patch
for a few years, for example. Nobody bothered to report the issue
upstream though, it seems.
References:
https://github.com/OpenELEC/OpenELEC.tv/issues/1957
http://www.vdr-portal.de/board60-linux/board14-betriebssystem/board96-yavdr/p1033458-darstellungsproblem-bei-2-tt-3600-usb/#post1033458
(in German)
I'd suggest we include the patch below. Any objections?
Signed-off-by: Olli Salonen
---
drivers/media/usb/dvb-usb/pctv452e.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/dvb-usb/pctv452e.c
b/drivers/media/usb/dvb-usb/pctv452e.c
index ec397c4..c05de1b 100644
--- a/drivers/media/usb/dvb-usb/pctv452e.c
+++ b/drivers/media/usb/dvb-usb/pctv452e.c
@@ -995,11 +995,11 @@ static struct dvb_usb_device_properties
tt_connect_s2_3600_properties = {
/* parameter for the MPEG2-data transfer */
.stream = {
.type = USB_ISOC,
- .count = 7,
+ .count = 4,
.endpoint = 0x02,
.u = {
.isoc = {
- .framesperurb = 4,
+ .framesperurb = 64,
.framesize = 940,
.interval = 1
}
--
1.9.1
--
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
[RFCv1 PATCH 0/2] Driver for the Toshiba tc358840 HDMI-to-CSI2 bridge
From: Hans Verkuil This is an initial version for the Toshiba tc358840 HDMI-to-CSI2 bridge. The original code was contributed by Armin Weiss and I have cleaned it up, rebased it to our media tree, finalized the 4k support and added CEC support (this is a separate patch and sits on top of the CEC v13 patch series which will be posted soon). My git tree containing the CEC v13 patches + these tc358840 patches is here: http://git.linuxtv.org/hverkuil/media_tree.git/log/?h=tc358840 This will be rebased every so often! You're warned :-) There are various things that need cleaning up before this is ready for mainlining: - The device tree properties are messy and need to be cleaned up and properly documented. - There are a lot of FIXMEs that have to be checked (especially writes to registers where it is not clear if that should be done or not). - The isr has a bunch of mdelay calls: I need to verify which of these (if any) is really necessary and basically figure out what is going on there. Note for Armin: the EDID isn't set in this driver. It is userspace (or possibly the V4L2 driver) that has to set it. This is not something that this driver can decide. The v4l2-ctl utility can set predefined EDIDs using --set-edid. That said, it needs to be updated so it can set EDIDs suitable for 4k formats. I'll work on that. Regards, Hans Hans Verkuil (2): tc358840: add Toshiba HDMI-to-CSI bridge driver tc358840: add CEC support .../devicetree/bindings/media/i2c/tc358840.txt | 50 + MAINTAINERS|7 + drivers/media/i2c/Kconfig | 10 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/tc358840.c | 2529 drivers/media/i2c/tc358840_regs.h | 815 +++ include/media/i2c/tc358840.h | 89 + 7 files changed, 3501 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/tc358840.txt create mode 100644 drivers/media/i2c/tc358840.c create mode 100644 drivers/media/i2c/tc358840_regs.h create mode 100644 include/media/i2c/tc358840.h -- 2.7.0 -- 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 RFC 0/2] pxa_camera transition to v4l2 standalone device
Hi Hans and Guennadi, As Hans is converting sh_mobile_ceu_camera.c, let's see how close our ports are to see if there are things we could either reuse of change. The port is assuming : - the formation translation is transferred into soc_mediabus, so that it can be reused across all v4l2 devices - pxa_camera is ported This sets a ground of discussion for soc_camera adherence removal from pxa_camera. I'd like to have a comment from Hans if this is what he has in mind, and Guennadi if he agrees to transfer the soc xlate stuff to soc_mediabus. Cheers. -- Robert Robert Jarzmik (2): media: platform: transfer format translations to soc_mediabus media: platform: pxa_camera: make a standalone v4l2 device drivers/media/platform/soc_camera/pxa_camera.c | 715 +-- drivers/media/platform/soc_camera/soc_camera.c | 7 +- drivers/media/platform/soc_camera/soc_mediabus.c | 65 +++ include/linux/platform_data/media/camera-pxa.h | 2 + include/media/drv-intf/soc_mediabus.h| 22 + include/media/soc_camera.h | 15 - 6 files changed, 495 insertions(+), 331 deletions(-) -- 2.1.4 -- 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 RFC 1/2] media: platform: transfer format translations to soc_mediabus
Transfer the formats translations to soc_mediabus. Even is soc_camera
was to be deprecated, soc_mediabus will survive, and should describe all
that happens on the bus connecting the image processing unit of the SoC
and the sensor.
The translation engine provides an easy way to compute the formats
available in the v4l2 device, given any sensors format capabilities
bound with known image processing transformations.
Signed-off-by: Robert Jarzmik
---
drivers/media/platform/soc_camera/soc_camera.c | 7 +--
drivers/media/platform/soc_camera/soc_mediabus.c | 65
include/media/drv-intf/soc_mediabus.h| 22
include/media/soc_camera.h | 15 --
4 files changed, 88 insertions(+), 21 deletions(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index 46c7186f7867..039524a20056 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -204,12 +204,7 @@ static void soc_camera_clock_stop(struct soc_camera_host
*ici)
const struct soc_camera_format_xlate *soc_camera_xlate_by_fourcc(
struct soc_camera_device *icd, unsigned int fourcc)
{
- unsigned int i;
-
- for (i = 0; i < icd->num_user_formats; i++)
- if (icd->user_formats[i].host_fmt->fourcc == fourcc)
- return icd->user_formats + i;
- return NULL;
+ return soc_mbus_xlate_by_fourcc(icd->user_formats, fourcc);
}
EXPORT_SYMBOL(soc_camera_xlate_by_fourcc);
diff --git a/drivers/media/platform/soc_camera/soc_mediabus.c
b/drivers/media/platform/soc_camera/soc_mediabus.c
index e3e665e1c503..95c13055f50f 100644
--- a/drivers/media/platform/soc_camera/soc_mediabus.c
+++ b/drivers/media/platform/soc_camera/soc_mediabus.c
@@ -10,6 +10,7 @@
#include
#include
+#include
#include
#include
@@ -512,6 +513,70 @@ unsigned int soc_mbus_config_compatible(const struct
v4l2_mbus_config *cfg,
}
EXPORT_SYMBOL(soc_mbus_config_compatible);
+struct soc_camera_format_xlate *soc_mbus_build_fmts_xlate(
+ struct v4l2_device *v4l2_dev, struct v4l2_subdev *subdev,
+ int (*get_formats)(struct v4l2_device *, unsigned int,
+ struct soc_camera_format_xlate *xlate))
+{
+ unsigned int i, fmts = 0, raw_fmts = 0;
+ int ret;
+ struct v4l2_subdev_mbus_code_enum code = {
+ .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+ };
+ struct soc_camera_format_xlate *user_formats;
+
+ while (!v4l2_subdev_call(subdev, pad, enum_mbus_code, NULL, &code)) {
+ raw_fmts++;
+ code.index++;
+ }
+
+ /*
+* First pass - only count formats this host-sensor
+* configuration can provide
+*/
+ for (i = 0; i < raw_fmts; i++) {
+ ret = get_formats(v4l2_dev, i, NULL);
+ if (ret < 0)
+ return ERR_PTR(ret);
+ fmts += ret;
+ }
+
+ if (!fmts)
+ return ERR_PTR(-ENXIO);
+
+ user_formats = kcalloc(fmts + 1, sizeof(*user_formats), GFP_KERNEL);
+ if (!user_formats)
+ return ERR_PTR(-ENOMEM);
+
+ /* Second pass - actually fill data formats */
+ fmts = 0;
+ for (i = 0; i < raw_fmts; i++) {
+ ret = get_formats(v4l2_dev, i, user_formats + fmts);
+ if (ret < 0)
+ goto egfmt;
+ fmts += ret;
+ }
+ user_formats[fmts].code = 0;
+
+ return user_formats;
+egfmt:
+ kfree(user_formats);
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL(soc_mbus_build_fmts_xlate);
+
+const struct soc_camera_format_xlate *soc_mbus_xlate_by_fourcc(
+ struct soc_camera_format_xlate *user_formats, unsigned int fourcc)
+{
+ unsigned int i;
+
+ for (i = 0; user_formats[i].code; i++)
+ if (user_formats[i].host_fmt->fourcc == fourcc)
+ return user_formats + i;
+ return NULL;
+}
+EXPORT_SYMBOL(soc_mbus_xlate_by_fourcc);
+
static int __init soc_mbus_init(void)
{
return 0;
diff --git a/include/media/drv-intf/soc_mediabus.h
b/include/media/drv-intf/soc_mediabus.h
index 2ff773785fb6..08af52f6338c 100644
--- a/include/media/drv-intf/soc_mediabus.h
+++ b/include/media/drv-intf/soc_mediabus.h
@@ -95,6 +95,21 @@ struct soc_mbus_lookup {
struct soc_mbus_pixelfmtfmt;
};
+/**
+ * struct soc_camera_format_xlate - match between host and sensor formats
+ * @code: code of a sensor provided format
+ * @host_fmt: host format after host translation from code
+ *
+ * Host and sensor translation structure. Used in table of host and sensor
+ * formats matchings in soc_camera_device. A host can override the generic list
+ * generation by implementing get_formats(), and use it for format checks and
+ * format setup.
+ */
+struct soc_camera_format_xlate {
+ u32 code;
+ c
[PATCH RFC 2/2] media: platform: pxa_camera: make a standalone v4l2 device
This patch removes the soc_camera API dependency from pxa_camera.
In the current status :
- all previously captures are working the same on pxa270
- the s_crop() call was removed, judged not working
(see what happens soc_camera_s_crop() when get_crop() == NULL)
- if the pixel clock is provided by then sensor, ie. not MCLK, the dual
stage change is not handled yet.
(see all the comments left)
Signed-off-by: Robert Jarzmik
---
drivers/media/platform/soc_camera/pxa_camera.c | 715 ++---
include/linux/platform_data/media/camera-pxa.h | 2 +
2 files changed, 407 insertions(+), 310 deletions(-)
diff --git a/drivers/media/platform/soc_camera/pxa_camera.c
b/drivers/media/platform/soc_camera/pxa_camera.c
index 141a5ba603a8..3670ae798e31 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -3,6 +3,7 @@
*
* Copyright (C) 2006, Sascha Hauer, Pengutronix
* Copyright (C) 2008, Guennadi Liakhovetski
+ * Copyright (C) 2016, Robert Jarzmik
*
* 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
@@ -14,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -22,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -32,13 +35,16 @@
#include
#include
+#include
+#include
#include
-#include
-#include
-#include
-#include
+#include
+#include
#include
+#include
+#include
+
#include
#include
@@ -168,6 +174,9 @@
CICR0_PERRM | CICR0_QDM | CICR0_CDM | CICR0_SOFM | \
CICR0_EOFM | CICR0_FOM)
+#define sensor_call(cam, o, f, args...) \
+ v4l2_subdev_call(cam->sensor, o, f, ##args)
+
/*
* Structures
*/
@@ -195,7 +204,14 @@ struct pxa_buffer {
};
struct pxa_camera_dev {
- struct soc_camera_host soc_host;
+ struct v4l2_device v4l2_dev;
+ struct video_device vdev;
+ struct v4l2_async_notifier notifier;
+ struct vb2_queuevb2_vq;
+ struct v4l2_subdev *sensor;
+ struct soc_camera_format_xlate *user_formats;
+ const struct soc_camera_format_xlate *current_fmt;
+ struct v4l2_pix_format current_pix;
/*
* PXA27x is only supposed to handle one camera on its Quick Capture
* interface. If anyone ever builds hardware to enable more than
@@ -215,11 +231,13 @@ struct pxa_camera_dev {
unsigned long ciclk;
unsigned long mclk;
u32 mclk_divisor;
+ struct v4l2_clk *mclk_clk;
u16 width_flags;/* max 10 bits */
struct list_headcapture;
spinlock_t lock;
+ struct mutexmlock;
struct pxa_buffer *active;
struct tasklet_struct task_eof;
@@ -249,7 +267,12 @@ static struct pxa_buffer *vb2_to_pxa_buffer(struct
vb2_buffer *vb)
static struct device *pcdev_to_dev(struct pxa_camera_dev *pcdev)
{
- return pcdev->soc_host.v4l2_dev.dev;
+ return pcdev->v4l2_dev.dev;
+}
+
+static struct pxa_camera_dev *v4l2_dev_to_pcdev(struct v4l2_device *v4l2_dev)
+{
+ return container_of(v4l2_dev, struct pxa_camera_dev, v4l2_dev);
}
static void pxa_camera_dma_irq(struct pxa_camera_dev *pcdev,
@@ -638,13 +661,12 @@ static int pxa_vb2_prepare(struct vb2_buffer *vb)
{
struct pxa_camera_dev *pcdev = vb2_get_drv_priv(vb->vb2_queue);
struct pxa_buffer *buf = vb2_to_pxa_buffer(vb);
- struct soc_camera_device *icd = soc_camera_from_vb2q(vb->vb2_queue);
int i, ret = 0;
switch (pcdev->channels) {
case 1:
case 3:
- vb2_set_plane_payload(vb, 0, icd->sizeimage);
+ vb2_set_plane_payload(vb, 0, pcdev->current_pix.sizeimage);
break;
default:
return -EINVAL;
@@ -654,7 +676,7 @@ static int pxa_vb2_prepare(struct vb2_buffer *vb)
"%s (vb=%p) nb_channels=%d size=%lu\n",
__func__, vb, pcdev->channels, vb2_get_plane_payload(vb, 0));
- WARN_ON(!icd->current_fmt);
+ WARN_ON(!pcdev->current_fmt);
#ifdef DEBUG
/*
@@ -691,16 +713,15 @@ static int pxa_vb2_init(struct vb2_buffer *vb)
{
struct pxa_camera_dev *pcdev = vb2_get_drv_priv(vb->vb2_queue);
struct pxa_buffer *buf = vb2_to_pxa_buffer(vb);
- struct soc_camera_device *icd = soc_camera_from_vb2q(vb->vb2_queue);
dev_dbg(pcdev_to_dev(pcdev),
"%s(nb_channels=%d size=%u)\n",
-__func__, pcdev->channels, icd->sizeimage);
+__func__, pcdev->channels, pcdev->current_pix.sizeimage);
switch (pcdev->channels) {
case 1:
case 3:
- vb2_set_plane_payload(vb, 0, icd->sizeimage);
+ vb2_set_pl
Re: [PATCH 6/7] mtd: nand: sunxi: add support for DMA assisted operations
On Tue, 8 Mar 2016 12:15:14 +0100
Boris Brezillon wrote:
> The sunxi NAND controller is able to pipeline ECC operations only when
> operated in DMA mode, which improves a lot NAND throughput while keeping
> CPU usage low.
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/mtd/nand/sunxi_nand.c | 301
> +-
> 1 file changed, 297 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
> index 07c3af7..7ba285e 100644
> --- a/drivers/mtd/nand/sunxi_nand.c
> +++ b/drivers/mtd/nand/sunxi_nand.c
[...]
> +static int sunxi_nfc_hw_ecc_write_page_dma(struct mtd_info *mtd,
> +struct nand_chip *chip,
> +const u8 *buf,
> +int oob_required,
> +int page)
> +{
> + struct nand_chip *nand = mtd_to_nand(mtd);
> + struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
> + struct nand_ecc_ctrl *ecc = &nand->ecc;
> + struct sg_table sgt;
> + int ret, i;
> +
> + ret = sunxi_nfc_wait_cmd_fifo_empty(nfc);
> + if (ret)
> + return ret;
> +
> + ret = sunxi_nfc_dma_op_prepare(mtd, buf, ecc->size, ecc->steps,
> +DMA_TO_DEVICE, &sgt);
> + if (ret)
> + goto pio_fallback;
> +
> + for (i = 0; i < ecc->steps; i++) {
> + const u8 *oob = nand->oob_poi + (i * (ecc->bytes + 4));
> +
> + sunxi_nfc_hw_ecc_set_prot_oob_bytes(mtd, oob, i, !i, page);
> + }
> +
> + sunxi_nfc_hw_ecc_enable(mtd);
> + sunxi_nfc_randomizer_config(mtd, page, false);
> + sunxi_nfc_randomizer_enable(mtd);
> +
> + writel((NAND_CMD_RNDIN << 8) | NAND_CMD_PAGEPROG,
> +nfc->regs + NFC_REG_RCMD_SET);
> +
> + dma_async_issue_pending(nfc->dmac);
> +
> + writel(NFC_PAGE_OP | NFC_DATA_SWAP_METHOD |
> +NFC_DATA_TRANS | NFC_ACCESS_DIR,
> +nfc->regs + NFC_REG_CMD);
> +
> + ret = sunxi_nfc_wait_events(nfc, NFC_CMD_INT_FLAG, true, 0);
> + if (ret)
> + dmaengine_terminate_all(nfc->dmac);
> +
> + sunxi_nfc_randomizer_disable(mtd);
> + sunxi_nfc_hw_ecc_disable(mtd);
> +
> + sunxi_nfc_dma_op_cleanup(mtd, DMA_FROM_DEVICE, &sgt);
Should be DMA_TO_DEVICE here ^
> +
> + if (ret)
> + return ret;
> +
> + if (oob_required || (chip->options & NAND_NEED_SCRAMBLING))
> + /* TODO: use DMA to transfer extra OOB bytes ? */
> + sunxi_nfc_hw_ecc_write_extra_oob(mtd, chip->oob_poi,
> + NULL, page);
> +
> + return 0;
> +
> +pio_fallback:
> + return sunxi_nfc_hw_ecc_write_page(mtd, chip, buf, oob_required, page);
> +}
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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 1/5] [media] media-device: get rid of the spinlock
Right now, the lock schema for media_device struct is messy,
since sometimes, it is protected via a spin lock, while, for
media graph traversal, it is protected by a mutex.
Solve this conflict by always using a mutex.
As a side effect, this prevents a bug where the media notifiers
were called at atomic context.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/media-device.c | 32 ++--
drivers/media/media-entity.c | 16
include/media/media-device.h | 6 +-
3 files changed, 23 insertions(+), 31 deletions(-)
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 6e43c95629ea..c32fa15cc76e 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -90,17 +90,17 @@ static struct media_entity *find_entity(struct media_device
*mdev, u32 id)
id &= ~MEDIA_ENT_ID_FLAG_NEXT;
- spin_lock(&mdev->lock);
+ mutex_lock(&mdev->graph_mutex);
media_device_for_each_entity(entity, mdev) {
if (((media_entity_id(entity) == id) && !next) ||
((media_entity_id(entity) > id) && next)) {
- spin_unlock(&mdev->lock);
+ mutex_unlock(&mdev->graph_mutex);
return entity;
}
}
- spin_unlock(&mdev->lock);
+ mutex_unlock(&mdev->graph_mutex);
return NULL;
}
@@ -590,12 +590,12 @@ int __must_check media_device_register_entity(struct
media_device *mdev,
if (!ida_pre_get(&mdev->entity_internal_idx, GFP_KERNEL))
return -ENOMEM;
- spin_lock(&mdev->lock);
+ mutex_lock(&mdev->graph_mutex);
ret = ida_get_new_above(&mdev->entity_internal_idx, 1,
&entity->internal_idx);
if (ret < 0) {
- spin_unlock(&mdev->lock);
+ mutex_unlock(&mdev->graph_mutex);
return ret;
}
@@ -615,9 +615,6 @@ int __must_check media_device_register_entity(struct
media_device *mdev,
(notify)->notify(entity, notify->notify_data);
}
- spin_unlock(&mdev->lock);
-
- mutex_lock(&mdev->graph_mutex);
if (mdev->entity_internal_idx_max
>= mdev->pm_count_walk.ent_enum.idx_max) {
struct media_entity_graph new = { .top = 0 };
@@ -680,9 +677,9 @@ void media_device_unregister_entity(struct media_entity
*entity)
if (mdev == NULL)
return;
- spin_lock(&mdev->lock);
+ mutex_lock(&mdev->graph_mutex);
__media_device_unregister_entity(entity);
- spin_unlock(&mdev->lock);
+ mutex_unlock(&mdev->graph_mutex);
}
EXPORT_SYMBOL_GPL(media_device_unregister_entity);
@@ -703,7 +700,6 @@ void media_device_init(struct media_device *mdev)
INIT_LIST_HEAD(&mdev->pads);
INIT_LIST_HEAD(&mdev->links);
INIT_LIST_HEAD(&mdev->entity_notify);
- spin_lock_init(&mdev->lock);
mutex_init(&mdev->graph_mutex);
ida_init(&mdev->entity_internal_idx);
@@ -752,9 +748,9 @@ EXPORT_SYMBOL_GPL(__media_device_register);
int __must_check media_device_register_entity_notify(struct media_device *mdev,
struct media_entity_notify *nptr)
{
- spin_lock(&mdev->lock);
+ mutex_lock(&mdev->graph_mutex);
list_add_tail(&nptr->list, &mdev->entity_notify);
- spin_unlock(&mdev->lock);
+ mutex_unlock(&mdev->graph_mutex);
return 0;
}
EXPORT_SYMBOL_GPL(media_device_register_entity_notify);
@@ -771,9 +767,9 @@ static void __media_device_unregister_entity_notify(struct
media_device *mdev,
void media_device_unregister_entity_notify(struct media_device *mdev,
struct media_entity_notify *nptr)
{
- spin_lock(&mdev->lock);
+ mutex_lock(&mdev->graph_mutex);
__media_device_unregister_entity_notify(mdev, nptr);
- spin_unlock(&mdev->lock);
+ mutex_unlock(&mdev->graph_mutex);
}
EXPORT_SYMBOL_GPL(media_device_unregister_entity_notify);
@@ -787,11 +783,11 @@ void media_device_unregister(struct media_device *mdev)
if (mdev == NULL)
return;
- spin_lock(&mdev->lock);
+ mutex_lock(&mdev->graph_mutex);
/* Check if mdev was ever registered at all */
if (!media_devnode_is_registered(&mdev->devnode)) {
- spin_unlock(&mdev->lock);
+ mutex_unlock(&mdev->graph_mutex);
return;
}
@@ -811,7 +807,7 @@ void media_device_unregister(struct media_device *mdev)
kfree(intf);
}
- spin_unlock(&mdev->lock);
+ mutex_unlock(&mdev->graph_mutex);
device_remove_file(&mdev->devnode.dev, &dev_attr_model);
media_devnode_unregister(&mdev->devnode);
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index e95070b3a3d4..c53c1d5589a0 100644
--- a/drivers/
Re: [PATCH 3/5] [media] au0828: Unregister notifiers
Hello Mauro, Patch looks good to me, I just have a minor comment: On Wed, Mar 16, 2016 at 9:04 AM, Mauro Carvalho Chehab wrote: > If au0828 gets removed, we need to remove the notifiers. > > Signed-off-by: Mauro Carvalho Chehab > --- > drivers/media/usb/au0828/au0828-core.c | 34 > -- > 1 file changed, 24 insertions(+), 10 deletions(-) > > diff --git a/drivers/media/usb/au0828/au0828-core.c > b/drivers/media/usb/au0828/au0828-core.c > index 2fcd17d9b1a6..06da73f1ff22 100644 > --- a/drivers/media/usb/au0828/au0828-core.c > +++ b/drivers/media/usb/au0828/au0828-core.c > @@ -131,21 +131,35 @@ static int recv_control_msg(struct au0828_dev *dev, u16 > request, u32 value, > return status; > } > > +#ifdef CONFIG_MEDIA_CONTROLLER > +static void au0828_media_graph_notify(struct media_entity *new, > + void *notify_data); > +#endif > + I would rather move the au0828_media_graph_notify() function definition before au0828_unregister_media_device() instead of adding this function forward declaration. Specially since requires ifdef guards which makes it even harder to read. Reviewed-by: Javier Martinez Canillas Best regards, Javier -- 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] Remove space before end of line in Astra-28.2E file
Fixes dvb-format-convert parsing the polarization value. Signed-off-by: Edward Sheldrake --- dvb-s/Astra-28.2E | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dvb-s/Astra-28.2E b/dvb-s/Astra-28.2E index ea06c56..5c3e515 100644 --- a/dvb-s/Astra-28.2E +++ b/dvb-s/Astra-28.2E @@ -572,7 +572,7 @@ [CHANNEL] DELIVERY_SYSTEM = DVBS FREQUENCY = 11170750 - POLARIZATION = HORIZONTAL + POLARIZATION = HORIZONTAL SYMBOL_RATE = 2200 INNER_FEC = 5/6 MODULATION = QPSK -- 2.5.0 -- 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 3/5] [media] au0828: Unregister notifiers
If au0828 gets removed, we need to remove the notifiers.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/usb/au0828/au0828-core.c | 34 --
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/drivers/media/usb/au0828/au0828-core.c
b/drivers/media/usb/au0828/au0828-core.c
index 2fcd17d9b1a6..06da73f1ff22 100644
--- a/drivers/media/usb/au0828/au0828-core.c
+++ b/drivers/media/usb/au0828/au0828-core.c
@@ -131,21 +131,35 @@ static int recv_control_msg(struct au0828_dev *dev, u16
request, u32 value,
return status;
}
+#ifdef CONFIG_MEDIA_CONTROLLER
+static void au0828_media_graph_notify(struct media_entity *new,
+ void *notify_data);
+#endif
+
static void au0828_unregister_media_device(struct au0828_dev *dev)
{
-
#ifdef CONFIG_MEDIA_CONTROLLER
- if (dev->media_dev &&
- media_devnode_is_registered(&dev->media_dev->devnode)) {
- /* clear enable_source, disable_source */
- dev->media_dev->source_priv = NULL;
- dev->media_dev->enable_source = NULL;
- dev->media_dev->disable_source = NULL;
+ struct media_device *mdev = dev->media_dev;
+ struct media_entity_notify *notify, *nextp;
- media_device_unregister(dev->media_dev);
- media_device_cleanup(dev->media_dev);
- dev->media_dev = NULL;
+ if (!mdev || !media_devnode_is_registered(&mdev->devnode))
+ return;
+
+ /* Remove au0828 entity_notify callbacks */
+ list_for_each_entry_safe(notify, nextp, &mdev->entity_notify, list) {
+ if (notify->notify != au0828_media_graph_notify)
+ continue;
+ media_device_unregister_entity_notify(mdev, notify);
}
+
+ /* clear enable_source, disable_source */
+ dev->media_dev->source_priv = NULL;
+ dev->media_dev->enable_source = NULL;
+ dev->media_dev->disable_source = NULL;
+
+ media_device_unregister(dev->media_dev);
+ media_device_cleanup(dev->media_dev);
+ dev->media_dev = NULL;
#endif
}
--
2.5.0
--
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: STK1160 - no video
Hey Kevin, On 4 March 2016 at 00:11, Kevin Fitch wrote: > Here is a quick patch that gives me actual video. That being said I > see some curious stuff being logged while video is streaming: > Patch looks more or less good, but that kernel log is not good. It indicates that the USB packet is not entirely sane, and so the incoming data is not what the driver is expecting. Have you been able to make any progress with it? -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar -- 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
cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Fri Mar 18 04:00:21 CET 2016 git branch: test git hash: da470473c9cf9c4ebb40d046b306c76427b6df94 gcc version:i686-linux-gcc (GCC) 5.3.0 sparse version: v0.5.0-51-ga53cea2 smatch version: v0.5.0-3228-g5cf65ab host hardware: x86_64 host os:4.4.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: OK linux-3.17.8-i686: OK linux-3.18.7-i686: OK linux-3.19-i686: OK linux-4.0-i686: OK linux-4.1.1-i686: OK linux-4.2-i686: OK linux-4.3-i686: OK linux-4.4-i686: OK linux-4.5-i686: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-x86_64: OK linux-4.1.1-x86_64: OK linux-4.2-x86_64: OK linux-4.3-x86_64: OK linux-4.4-x86_64: OK linux-4.5-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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] fence: add missing descriptions for fence
Hello Luis,
On Sat, Mar 19, 2016 at 4:50 PM, Luis de Bethencourt
wrote:
> Commit b55b54b5db33 ("staging/android: remove struct sync_pt")
> added the members child_list and active_list to the fence struct, but
> didn't add descriptions for these. Adding the descriptions.
>
Patches whose commit message mentions a specific commit that
introduced and issue, usually also have a "Fixes:" tag before the
S-o-B. For example this patch should have:
Fixes: b55b54b5db33 ("staging/android: remove struct sync_pt")
> Signed-off-by: Luis de Bethencourt
> ---
> Hi,
>
> Noticed this missing descriptions when running make htmldocs.
>
> Got the following warnings:
> .//include/linux/fence.h:84: warning: No description found for parameter
> 'child_list'
> .//include/linux/fence.h:84: warning: No description found for parameter
> 'active_list'
>
> Thanks :)
> Luis
>
Patch looks good to me.
Reviewed-by: Javier Martinez Canillas
Best regards,
Javier
--
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] fence: add missing descriptions for fence
On 19/03/16 23:55, Javier Martinez Canillas wrote:
> Hello Luis,
>
> On Sat, Mar 19, 2016 at 4:50 PM, Luis de Bethencourt
> wrote:
>> Commit b55b54b5db33 ("staging/android: remove struct sync_pt")
>> added the members child_list and active_list to the fence struct, but
>> didn't add descriptions for these. Adding the descriptions.
>>
>
> Patches whose commit message mentions a specific commit that
> introduced and issue, usually also have a "Fixes:" tag before the
> S-o-B. For example this patch should have:
>
> Fixes: b55b54b5db33 ("staging/android: remove struct sync_pt")
>> Signed-off-by: Luis de Bethencourt
>> ---
>> Hi,
>>
>> Noticed this missing descriptions when running make htmldocs.
>>
>> Got the following warnings:
>> .//include/linux/fence.h:84: warning: No description found for parameter
>> 'child_list'
>> .//include/linux/fence.h:84: warning: No description found for parameter
>> 'active_list'
>>
>> Thanks :)
>> Luis
>>
>
> Patch looks good to me.
>
> Reviewed-by: Javier Martinez Canillas
>
> Best regards,
> Javier
>
Hi Javier,
I didn't knew that, but thanks for saying so I can learn and use it in the
future.
I used the 'Commit b55b54b5db33 ("staging/android: remove struct sync_pt")'
format because that is what checkpatch recommended. But after re-reading
Documentation/SubmittingPatches it all makes sense and the process is clear
in my head.
Thanks!
Luis
--
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 5/5] [media] media-device: make media_device_cleanup() static
When multiple drivers are sharing the media_device struct,
one driver cannot know the right moment to cleanup the
media_device struct, because it can happen only when the
struct is not used by the other drivers.
So, let's call media_device_cleanup() internally, and
ensure that media_device_unregister() will do the right thing,
if the media device is not fully initialized.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/common/siano/smsdvb-main.c | 1 -
drivers/media/media-device.c | 13 ++---
drivers/media/pci/saa7134/saa7134-core.c | 1 -
drivers/media/platform/exynos4-is/media-dev.c | 3 +--
drivers/media/platform/omap3isp/isp.c | 1 -
drivers/media/platform/s3c-camif/camif-core.c | 2 --
drivers/media/platform/vsp1/vsp1_drv.c| 1 -
drivers/media/platform/xilinx/xilinx-vipp.c | 3 +--
drivers/media/usb/au0828/au0828-core.c| 1 -
drivers/media/usb/cx231xx/cx231xx-cards.c | 1 -
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 1 -
drivers/media/usb/dvb-usb/dvb-usb-dvb.c | 1 -
drivers/media/usb/em28xx/em28xx-cards.c | 1 -
drivers/media/usb/siano/smsusb.c | 2 +-
drivers/media/usb/uvc/uvc_driver.c| 4 +---
include/media/media-device.h | 10 --
16 files changed, 10 insertions(+), 36 deletions(-)
diff --git a/drivers/media/common/siano/smsdvb-main.c
b/drivers/media/common/siano/smsdvb-main.c
index 9148e14c9d07..711c389c05e3 100644
--- a/drivers/media/common/siano/smsdvb-main.c
+++ b/drivers/media/common/siano/smsdvb-main.c
@@ -617,7 +617,6 @@ static void smsdvb_media_device_unregister(struct
smsdvb_client_t *client)
if (!coredev->media_dev)
return;
media_device_unregister(coredev->media_dev);
- media_device_cleanup(coredev->media_dev);
kfree(coredev->media_dev);
coredev->media_dev = NULL;
#endif
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 38e6c319fe6e..0c7371eeda84 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -707,14 +707,12 @@ void media_device_init(struct media_device *mdev)
}
EXPORT_SYMBOL_GPL(media_device_init);
-void media_device_cleanup(struct media_device *mdev)
+static void media_device_cleanup(struct media_device *mdev)
{
ida_destroy(&mdev->entity_internal_idx);
mdev->entity_internal_idx_max = 0;
media_entity_graph_walk_cleanup(&mdev->pm_count_walk);
- mutex_destroy(&mdev->graph_mutex);
}
-EXPORT_SYMBOL_GPL(media_device_cleanup);
int __must_check __media_device_register(struct media_device *mdev,
struct module *owner)
@@ -812,11 +810,12 @@ static void do_media_device_unregister(struct kref *kref)
}
/* Check if mdev devnode was registered */
- if (!media_devnode_is_registered(&mdev->devnode))
- return;
+ if (media_devnode_is_registered(&mdev->devnode)) {
+ device_remove_file(&mdev->devnode.dev, &dev_attr_model);
+ media_devnode_unregister(&mdev->devnode);
+ }
- device_remove_file(&mdev->devnode.dev, &dev_attr_model);
- media_devnode_unregister(&mdev->devnode);
+ media_device_cleanup(mdev);
dev_dbg(mdev->dev, "Media device unregistered\n");
}
diff --git a/drivers/media/pci/saa7134/saa7134-core.c
b/drivers/media/pci/saa7134/saa7134-core.c
index c0e1780ec831..213dc71f09eb 100644
--- a/drivers/media/pci/saa7134/saa7134-core.c
+++ b/drivers/media/pci/saa7134/saa7134-core.c
@@ -813,7 +813,6 @@ static void saa7134_unregister_media_device(struct
saa7134_dev *dev)
if (!dev->media_dev)
return;
media_device_unregister(dev->media_dev);
- media_device_cleanup(dev->media_dev);
kfree(dev->media_dev);
dev->media_dev = NULL;
#endif
diff --git a/drivers/media/platform/exynos4-is/media-dev.c
b/drivers/media/platform/exynos4-is/media-dev.c
index feb521f28e14..8c106fda7b84 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -1501,7 +1501,7 @@ err_clk:
err_m_ent:
fimc_md_unregister_entities(fmd);
err_md:
- media_device_cleanup(&fmd->media_dev);
+ media_device_unregister(&fmd->media_dev);
v4l2_device_unregister(&fmd->v4l2_dev);
return ret;
}
@@ -1521,7 +1521,6 @@ static int fimc_md_remove(struct platform_device *pdev)
fimc_md_unregister_entities(fmd);
fimc_md_pipelines_free(fmd);
media_device_unregister(&fmd->media_dev);
- media_device_cleanup(&fmd->media_dev);
fimc_md_put_clocks(fmd);
return 0;
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index 5d54e2c6c16b..cd67edcad8d3 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -1598,7 +1598,6 @@ static void isp_unregister_
Re: STK1160 - no video
On 18 March 2016 at 23:29, Kevin Fitch wrote: > Well, I just tried, and failed to reproduce those kernel log messages. > There is a comment in one of the source file about "spammy" messages > that show up if there is mismatch between the actual and expected > video standards. I don't think I had them mismatched before, but maybe > I did. Or maybe after all my mucking around I had managed to get the > adapter in a weird state. So, for now, that patch seems to be all that > is needed. > OK, sounds fair. Want me to polish that patch and send it with your authorship, or will you send it? -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar -- 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] media-device: Don't call notify callbacks holding a spinlock
Em Thu, 17 Mar 2016 13:38:56 +0200
Laurent Pinchart escreveu:
> Hi Mauro,
>
> On Monday 14 March 2016 16:16:29 Mauro Carvalho Chehab wrote:
> > The notify routines may sleep. So, they can't be called in spinlock
> > context. Also, they may want to call other media routines that might
> > be spinning the spinlock, like creating a link.
> >
> > This fixes the following bug:
> >
> > [ 1839.510587] BUG: sleeping function called from invalid context at
> > mm/slub.c:1289 [ 1839.510881] in_atomic(): 1, irqs_disabled(): 0, pid:
> > 3479, name: modprobe [ 1839.511157] 4 locks held by modprobe/3479:
> > [ 1839.511415] #0: (&dev->mutex){..}, at: []
> > __driver_attach+0xa3/0x160 [ 1839.512381] #1: (&dev->mutex){..}, at:
> > [] __driver_attach+0xb1/0x160 [ 1839.512388] #2:
> > (register_mutex#5){+.+.+.}, at: []
> > usb_audio_probe+0x257/0x1c90 [snd_usb_audio] [ 1839.512401] #3:
> > (&(&mdev->lock)->rlock){+.+.+.}, at: []
> > media_device_register_entity+0x1cb/0x700 [media] [ 1839.512412] CPU: 2 PID:
> > 3479 Comm: modprobe Not tainted 4.5.0-rc3+ #49 [ 1839.512415] Hardware
> > name: /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722
> > 08/12/2015 [ 1839.512417] 8803b3f6f288
> > 81933901 8803c4bae000 [ 1839.512422] 8803c4bae5c8
> > 8803b3f6f2b0 811c6af5 8803c4bae000 [ 1839.512427]
> > 8285d7f6 0509 8803b3f6f2f0 811c6ce5 [
> > 1839.512432] Call Trace:
> > [ 1839.512436] [] dump_stack+0x85/0xc4
> > [ 1839.512440] [] ___might_sleep+0x245/0x3a0
> > [ 1839.512443] [] __might_sleep+0x95/0x1a0
> > [ 1839.512446] [] kmem_cache_alloc_trace+0x20e/0x300
> > [ 1839.512451] [] ? media_add_link+0x4d/0x140 [media]
> > [ 1839.512455] [] media_add_link+0x4d/0x140 [media]
> > [ 1839.512459] [] media_create_pad_link+0xa1/0x600
> > [media] [ 1839.512463] []
> > au0828_media_graph_notify+0x173/0x360 [au0828] [ 1839.512467]
> > [] ? media_gobj_create+0x1ba/0x480 [media] [ 1839.512471]
> > [] media_device_register_entity+0x3ab/0x700 [media]
> >
> > Tested with an HVR-950Q, under the following testcases:
> >
> > 1) load au0828 driver first, and then snd-usb-audio;
> > 2) load snd-usb-audio driver first, and then au0828;
> > 3) loading both drivers, and then connecting the device.
> >
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> > drivers/media/i2c/tvp5150.c | 39
> > drivers/media/media-device.c | 5 +++--
> > drivers/media/v4l2-core/v4l2-common.c | 8 +++
> > include/media/v4l2-subdev.h | 4
> > 4 files changed, 40 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
> > index ff18444e19e4..14004fd7d0fb 100644
> > --- a/drivers/media/i2c/tvp5150.c
> > +++ b/drivers/media/i2c/tvp5150.c
> > @@ -1208,6 +1208,28 @@ static int tvp5150_registered_async(struct
> > v4l2_subdev *sd) return 0;
> > }
> >
> > +static int __maybe_unused tvp5150_pad_init(struct v4l2_subdev *sd)
> > +{
> > + struct tvp5150 *core = to_tvp5150(sd);
> > + int res;
> > +
> > +#if defined(CONFIG_MEDIA_CONTROLLER)
> > + core->pads[DEMOD_PAD_IF_INPUT].flags = MEDIA_PAD_FL_SINK;
> > + core->pads[DEMOD_PAD_VID_OUT].flags = MEDIA_PAD_FL_SOURCE;
> > + core->pads[DEMOD_PAD_VBI_OUT].flags = MEDIA_PAD_FL_SOURCE;
> > +
> > + sd->entity.function = MEDIA_ENT_F_ATV_DECODER;
> > +
> > + res = media_entity_pads_init(&sd->entity, DEMOD_NUM_PADS, core->pads);
> > + if (res < 0)
> > + return res;
> > +
> > + sd->entity.ops = &tvp5150_sd_media_ops;
> > +#endif
> > + return 0;
> > +}
> > +
> > +
> > /* ---
> > */
> >
> > static const struct v4l2_ctrl_ops tvp5150_ctrl_ops = {
> > @@ -1246,6 +1268,9 @@ static const struct v4l2_subdev_vbi_ops
> > tvp5150_vbi_ops = { };
> >
> > static const struct v4l2_subdev_pad_ops tvp5150_pad_ops = {
> > +#ifdef CONFIG_MEDIA_CONTROLLER
> > + .pad_init = tvp5150_pad_init,
> > +#endif
> > .enum_mbus_code = tvp5150_enum_mbus_code,
> > .enum_frame_size = tvp5150_enum_frame_size,
> > .set_fmt = tvp5150_fill_fmt,
> > @@ -1475,20 +1500,6 @@ static int tvp5150_probe(struct i2c_client *c,
> > v4l2_i2c_subdev_init(sd, c, &tvp5150_ops);
> > sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> >
> > -#if defined(CONFIG_MEDIA_CONTROLLER)
> > - core->pads[DEMOD_PAD_IF_INPUT].flags = MEDIA_PAD_FL_SINK;
> > - core->pads[DEMOD_PAD_VID_OUT].flags = MEDIA_PAD_FL_SOURCE;
> > - core->pads[DEMOD_PAD_VBI_OUT].flags = MEDIA_PAD_FL_SOURCE;
> > -
> > - sd->entity.function = MEDIA_ENT_F_ATV_DECODER;
> > -
> > - res = media_entity_pads_init(&sd->entity, DEMOD_NUM_PADS, core->pads);
> > - if (res < 0)
> > - return res;
> > -
> > - sd->entity.ops = &tvp5150_sd_media_ops;
> > -#endif
> > -
> > res = tvp5150_detect_version(core);
> > if (res < 0)
> > return res;
Re: [PATCH 1/5] [media] media-device: get rid of the spinlock
Hi Mauro, On Wed, Mar 16, 2016 at 09:04:02AM -0300, Mauro Carvalho Chehab wrote: > Right now, the lock schema for media_device struct is messy, > since sometimes, it is protected via a spin lock, while, for > media graph traversal, it is protected by a mutex. > > Solve this conflict by always using a mutex. > > As a side effect, this prevents a bug where the media notifiers > were called at atomic context. > > Signed-off-by: Mauro Carvalho Chehab The scope of mdev->lock isn't much, really. I think this is fine, no need to create another mutex. Acked-by: Sakari Ailus -- 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] media: rc: reduce size of struct ir_raw_event
On Wed, Mar 16, 2016 at 10:18:38PM +0100, Heiner Kallweit wrote:
> struct ir_raw_event currently has a size of 12 bytes on most (all?)
> architectures. This can be reduced to 8 bytes whilst maintaining
> full backwards compatibility.
> This saves 2KB in size of struct ir_raw_event_ctrl (as element
> kfifo is reduced by 512 * 4 bytes) and it allows to copy the
> full struct ir_raw_event with a single 64 bit operation.
>
> Successfully tested with the Nuvoton driver and successfully
> compile-tested with the ene_ir driver (as it uses the carrier /
> duty_cycle elements).
>
> Signed-off-by: Heiner Kallweit
> ---
> include/media/rc-core.h | 26 --
> 1 file changed, 8 insertions(+), 18 deletions(-)
>
> diff --git a/include/media/rc-core.h b/include/media/rc-core.h
> index 0f77b3d..b8f27c9 100644
> --- a/include/media/rc-core.h
> +++ b/include/media/rc-core.h
> @@ -214,27 +214,17 @@ enum raw_event_type {
>
> struct ir_raw_event {
> union {
> - u32 duration;
> -
> - struct {
> - u32 carrier;
> - u8 duty_cycle;
> - };
> + u32 duration;
> + u32 carrier;
> };
> -
> - unsignedpulse:1;
> - unsignedreset:1;
> - unsignedtimeout:1;
> - unsignedcarrier_report:1;
> + u8 duty_cycle;
Moving duty_cycle does indeed reduce the structure size from 12 to 8.
> + u8 pulse:1;
> + u8 reset:1;
> + u8 timeout:1;
> + u8 carrier_report:1;
Why are you changing the type of the bitfields?
> };
>
> -#define DEFINE_IR_RAW_EVENT(event) \
> - struct ir_raw_event event = { \
> - { .duration = 0 } , \
> - .pulse = 0, \
> - .reset = 0, \
> - .timeout = 0, \
> - .carrier_report = 0 }
> +#define DEFINE_IR_RAW_EVENT(event) struct ir_raw_event event = {}
Seems fine. I've always kinda wondered why this macro is needed.
Sean
--
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 1/3] [media] v4l2-mc.h: Add a S-Video C input PAD to demod enum
On 03/09/2016 08:09 PM, Javier Martinez Canillas wrote:
> The enum demod_pad_index list the PADs that an analog TV demod has but
> in some decoders the S-Video Y (luminance) and C (chrominance) signals
> are carried by different connectors. So a single DEMOD_PAD_IF_INPUT is
> not enough and an additional PAD is needed in the case of S-Video for
> the additional C signal.
>
> Add a DEMOD_PAD_C_INPUT that can be used for this case and the existing
> DEMOD_PAD_IF_INPUT can be used for either Composite or the Y signal.
>
> Suggested-by: Mauro Carvalho Chehab
> Signed-off-by: Javier Martinez Canillas
>
> ---
> Hello,
>
> This change was suggested by Mauro in [0] although is still not clear
> if this is the way forward since changing PAD indexes can break the
> uAPI depending on how the PADs are looked up. Another alternative is
> to have a PAD type as Mauro mentioned on the same email but since the
> series are RFC, I'm making this change as an example and hopping that
> the patches can help with the discussion.
>
> [0]: http://www.spinics.net/lists/linux-media/msg98042.html
>
> Best regards,
> Javier
>
> include/media/v4l2-mc.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/media/v4l2-mc.h b/include/media/v4l2-mc.h
> index 98a938aabdfb..47c00c288a06 100644
> --- a/include/media/v4l2-mc.h
> +++ b/include/media/v4l2-mc.h
> @@ -94,7 +94,8 @@ enum if_aud_dec_pad_index {
> * @DEMOD_NUM_PADS: Maximum number of output pads.
> */
> enum demod_pad_index {
> - DEMOD_PAD_IF_INPUT,
> + DEMOD_PAD_IF_INPUT, /* S-Video Y input or Composite */
> + DEMOD_PAD_C_INPUT, /* S-Video C input or Composite */
> DEMOD_PAD_VID_OUT,
> DEMOD_PAD_VBI_OUT,
> DEMOD_PAD_AUDIO_OUT,
>
These pad index enums are butt ugly and won't scale in the long run. An entity
should have just as many pads as it needs and no more.
If you want to have an heuristic so you can find which pad carries e.g.
composite video, then it is better to ask the subdev for that.
E.g.: err = v4l2_subdev_call(sd, pad, g_signal_pad, V4L2_PAD_Y_SIG_INPUT, &pad)
The subdev driver knows which pad has which signal, so this does not rely on
hardcoding all combinations of possible pad types and you can still
heuristically
build a media graph for legacy drivers.
What we do now is reminiscent of the bad old days when the input numbers (as
returned by ENUMINPUT) where mapped to the i2c routing (basically pads). I
worked
hard to get rid of that hardcoded relationship and I don't like to see it coming
back.
Actually, I am not sure if a new subdev op will work at all. This information
really belongs to the device tree or card info. Just as it is done today with
the audio and video s_routing op. The op basically sets up the routing (i.e.
pads). We didn't have pads (or an MC) when I made that op, but the purpose
is the same.
Although I guess that a g_signal_pad might be enough in many cases. I don't
know what is the best solution, to be honest. All I know is that the current
approach will end in tears.
Hmm, looking at saa7134-cards you have lists of inputs. You could add a pad_type
field there and use the g_signal_pad to obtain the corresponding pad of the
subdev entity. You'd have pad types TV, COMPOSITE[1-N], SVIDEO[1-N], etc.
Note that input 1 could map to pad type COMPOSITE3 since that all depends on
how the board is wired up.
But at least this approach doesn't force subdevs to have more pads than they
need.
Regards,
Hans
--
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 4/5] [media] media-device: use kref for media_device instance
Now that the media_device can be used by multiple drivers,
via devres, we need to be sure that it will be dropped only
when all drivers stop using it.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/media-device.c | 48 +++-
include/media/media-device.h | 3 +++
2 files changed, 37 insertions(+), 14 deletions(-)
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index c32fa15cc76e..38e6c319fe6e 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -721,6 +721,15 @@ int __must_check __media_device_register(struct
media_device *mdev,
{
int ret;
+ /* Check if mdev was ever registered at all */
+ mutex_lock(&mdev->graph_mutex);
+ if (media_devnode_is_registered(&mdev->devnode)) {
+ kref_get(&mdev->kref);
+ mutex_unlock(&mdev->graph_mutex);
+ return 0;
+ }
+ kref_init(&mdev->kref);
+
/* Register the device node. */
mdev->devnode.fops = &media_device_fops;
mdev->devnode.parent = mdev->dev;
@@ -730,8 +739,10 @@ int __must_check __media_device_register(struct
media_device *mdev,
mdev->topology_version = 0;
ret = media_devnode_register(&mdev->devnode, owner);
- if (ret < 0)
+ if (ret < 0) {
+ media_devnode_unregister(&mdev->devnode);
return ret;
+ }
ret = device_create_file(&mdev->devnode.dev, &dev_attr_model);
if (ret < 0) {
@@ -739,6 +750,7 @@ int __must_check __media_device_register(struct
media_device *mdev,
return ret;
}
+ mutex_unlock(&mdev->graph_mutex);
dev_dbg(mdev->dev, "Media device registered\n");
return 0;
@@ -773,23 +785,15 @@ void media_device_unregister_entity_notify(struct
media_device *mdev,
}
EXPORT_SYMBOL_GPL(media_device_unregister_entity_notify);
-void media_device_unregister(struct media_device *mdev)
+static void do_media_device_unregister(struct kref *kref)
{
+ struct media_device *mdev;
struct media_entity *entity;
struct media_entity *next;
struct media_interface *intf, *tmp_intf;
struct media_entity_notify *notify, *nextp;
- if (mdev == NULL)
- return;
-
- mutex_lock(&mdev->graph_mutex);
-
- /* Check if mdev was ever registered at all */
- if (!media_devnode_is_registered(&mdev->devnode)) {
- mutex_unlock(&mdev->graph_mutex);
- return;
- }
+ mdev = container_of(kref, struct media_device, kref);
/* Remove all entities from the media device */
list_for_each_entry_safe(entity, next, &mdev->entities, graph_obj.list)
@@ -807,13 +811,26 @@ void media_device_unregister(struct media_device *mdev)
kfree(intf);
}
- mutex_unlock(&mdev->graph_mutex);
+ /* Check if mdev devnode was registered */
+ if (!media_devnode_is_registered(&mdev->devnode))
+ return;
device_remove_file(&mdev->devnode.dev, &dev_attr_model);
media_devnode_unregister(&mdev->devnode);
dev_dbg(mdev->dev, "Media device unregistered\n");
}
+
+void media_device_unregister(struct media_device *mdev)
+{
+ if (mdev == NULL)
+ return;
+
+ mutex_lock(&mdev->graph_mutex);
+ kref_put(&mdev->kref, do_media_device_unregister);
+ mutex_unlock(&mdev->graph_mutex);
+
+}
EXPORT_SYMBOL_GPL(media_device_unregister);
static void media_device_release_devres(struct device *dev, void *res)
@@ -825,13 +842,16 @@ struct media_device *media_device_get_devres(struct
device *dev)
struct media_device *mdev;
mdev = devres_find(dev, media_device_release_devres, NULL, NULL);
- if (mdev)
+ if (mdev) {
+ kref_get(&mdev->kref);
return mdev;
+ }
mdev = devres_alloc(media_device_release_devres,
sizeof(struct media_device), GFP_KERNEL);
if (!mdev)
return NULL;
+
return devres_get(dev, mdev, NULL, NULL);
}
EXPORT_SYMBOL_GPL(media_device_get_devres);
diff --git a/include/media/media-device.h b/include/media/media-device.h
index ca3871b853ba..73c16e6e6b6b 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -23,6 +23,7 @@
#ifndef _MEDIA_DEVICE_H
#define _MEDIA_DEVICE_H
+#include
#include
#include
@@ -283,6 +284,7 @@ struct media_entity_notify {
* struct media_device - Media device
* @dev: Parent device
* @devnode: Media device node
+ * @kref: Object refcount
* @driver_name: Optional device driver name. If not set, calls to
* %MEDIA_IOC_DEVICE_INFO will return dev->driver->name.
* This is needed for USB drivers for example, as otherwise
@@ -347,6 +349,7 @@ struct media_device {
/* dev->driver_data points to this struct. */
struc
Re: [PATCH] [media] media-device: Don't call notify callbacks holding a spinlock
Hi Mauro,
On Monday 14 March 2016 16:16:29 Mauro Carvalho Chehab wrote:
> The notify routines may sleep. So, they can't be called in spinlock
> context. Also, they may want to call other media routines that might
> be spinning the spinlock, like creating a link.
>
> This fixes the following bug:
>
> [ 1839.510587] BUG: sleeping function called from invalid context at
> mm/slub.c:1289 [ 1839.510881] in_atomic(): 1, irqs_disabled(): 0, pid:
> 3479, name: modprobe [ 1839.511157] 4 locks held by modprobe/3479:
> [ 1839.511415] #0: (&dev->mutex){..}, at: []
> __driver_attach+0xa3/0x160 [ 1839.512381] #1: (&dev->mutex){..}, at:
> [] __driver_attach+0xb1/0x160 [ 1839.512388] #2:
> (register_mutex#5){+.+.+.}, at: []
> usb_audio_probe+0x257/0x1c90 [snd_usb_audio] [ 1839.512401] #3:
> (&(&mdev->lock)->rlock){+.+.+.}, at: []
> media_device_register_entity+0x1cb/0x700 [media] [ 1839.512412] CPU: 2 PID:
> 3479 Comm: modprobe Not tainted 4.5.0-rc3+ #49 [ 1839.512415] Hardware
> name: /NUC5i7RYB, BIOS RYBDWi35.86A.0350.2015.0812.1722
> 08/12/2015 [ 1839.512417] 8803b3f6f288
> 81933901 8803c4bae000 [ 1839.512422] 8803c4bae5c8
> 8803b3f6f2b0 811c6af5 8803c4bae000 [ 1839.512427]
> 8285d7f6 0509 8803b3f6f2f0 811c6ce5 [
> 1839.512432] Call Trace:
> [ 1839.512436] [] dump_stack+0x85/0xc4
> [ 1839.512440] [] ___might_sleep+0x245/0x3a0
> [ 1839.512443] [] __might_sleep+0x95/0x1a0
> [ 1839.512446] [] kmem_cache_alloc_trace+0x20e/0x300
> [ 1839.512451] [] ? media_add_link+0x4d/0x140 [media]
> [ 1839.512455] [] media_add_link+0x4d/0x140 [media]
> [ 1839.512459] [] media_create_pad_link+0xa1/0x600
> [media] [ 1839.512463] []
> au0828_media_graph_notify+0x173/0x360 [au0828] [ 1839.512467]
> [] ? media_gobj_create+0x1ba/0x480 [media] [ 1839.512471]
> [] media_device_register_entity+0x3ab/0x700 [media]
>
> Tested with an HVR-950Q, under the following testcases:
>
> 1) load au0828 driver first, and then snd-usb-audio;
> 2) load snd-usb-audio driver first, and then au0828;
> 3) loading both drivers, and then connecting the device.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/media/i2c/tvp5150.c | 39
> drivers/media/media-device.c | 5 +++--
> drivers/media/v4l2-core/v4l2-common.c | 8 +++
> include/media/v4l2-subdev.h | 4
> 4 files changed, 40 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
> index ff18444e19e4..14004fd7d0fb 100644
> --- a/drivers/media/i2c/tvp5150.c
> +++ b/drivers/media/i2c/tvp5150.c
> @@ -1208,6 +1208,28 @@ static int tvp5150_registered_async(struct
> v4l2_subdev *sd) return 0;
> }
>
> +static int __maybe_unused tvp5150_pad_init(struct v4l2_subdev *sd)
> +{
> + struct tvp5150 *core = to_tvp5150(sd);
> + int res;
> +
> +#if defined(CONFIG_MEDIA_CONTROLLER)
> + core->pads[DEMOD_PAD_IF_INPUT].flags = MEDIA_PAD_FL_SINK;
> + core->pads[DEMOD_PAD_VID_OUT].flags = MEDIA_PAD_FL_SOURCE;
> + core->pads[DEMOD_PAD_VBI_OUT].flags = MEDIA_PAD_FL_SOURCE;
> +
> + sd->entity.function = MEDIA_ENT_F_ATV_DECODER;
> +
> + res = media_entity_pads_init(&sd->entity, DEMOD_NUM_PADS, core->pads);
> + if (res < 0)
> + return res;
> +
> + sd->entity.ops = &tvp5150_sd_media_ops;
> +#endif
> + return 0;
> +}
> +
> +
> /* ---
> */
>
> static const struct v4l2_ctrl_ops tvp5150_ctrl_ops = {
> @@ -1246,6 +1268,9 @@ static const struct v4l2_subdev_vbi_ops
> tvp5150_vbi_ops = { };
>
> static const struct v4l2_subdev_pad_ops tvp5150_pad_ops = {
> +#ifdef CONFIG_MEDIA_CONTROLLER
> + .pad_init = tvp5150_pad_init,
> +#endif
> .enum_mbus_code = tvp5150_enum_mbus_code,
> .enum_frame_size = tvp5150_enum_frame_size,
> .set_fmt = tvp5150_fill_fmt,
> @@ -1475,20 +1500,6 @@ static int tvp5150_probe(struct i2c_client *c,
> v4l2_i2c_subdev_init(sd, c, &tvp5150_ops);
> sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
>
> -#if defined(CONFIG_MEDIA_CONTROLLER)
> - core->pads[DEMOD_PAD_IF_INPUT].flags = MEDIA_PAD_FL_SINK;
> - core->pads[DEMOD_PAD_VID_OUT].flags = MEDIA_PAD_FL_SOURCE;
> - core->pads[DEMOD_PAD_VBI_OUT].flags = MEDIA_PAD_FL_SOURCE;
> -
> - sd->entity.function = MEDIA_ENT_F_ATV_DECODER;
> -
> - res = media_entity_pads_init(&sd->entity, DEMOD_NUM_PADS, core->pads);
> - if (res < 0)
> - return res;
> -
> - sd->entity.ops = &tvp5150_sd_media_ops;
> -#endif
> -
> res = tvp5150_detect_version(core);
> if (res < 0)
> return res;
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index 6ba6e8f982fc..fc3c199e5500 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -587,14 +587,15 @@ int __must_check media_devi
[PATCH 1/2] mceusb: add support for Adaptec eHome receiver
New USB ID for Adaptec eHome receiver in some HP laptops.
Signed-off-by: Olli Salonen
---
drivers/media/rc/mceusb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index 35155ae..09ca9f6 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -188,6 +188,7 @@
#define VENDOR_TWISTEDMELON0x2596
#define VENDOR_HAUPPAUGE 0x2040
#define VENDOR_PCTV0x2013
+#define VENDOR_ADAPTEC 0x03f3
enum mceusb_model_type {
MCE_GEN2 = 0, /* Most boards */
@@ -405,6 +406,8 @@ static struct usb_device_id mceusb_dev_table[] = {
.driver_info = HAUPPAUGE_CX_HYBRID_TV },
{ USB_DEVICE(VENDOR_PCTV, 0x025e),
.driver_info = HAUPPAUGE_CX_HYBRID_TV },
+ /* Adaptec / HP eHome Receiver */
+ { USB_DEVICE(VENDOR_ADAPTEC, 0x0094) },
/* Terminating entry */
{ }
--
1.9.1
--
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: add GFP flag to media_*() that could get called in atomic context
Em Wed, 16 Mar 2016 10:28:35 +0200
Sakari Ailus escreveu:
> Hi Mauro,
>
> On Tue, Mar 15, 2016 at 12:55:35PM -0300, Mauro Carvalho Chehab wrote:
> > Em Mon, 14 Mar 2016 14:09:09 +0200
> > Sakari Ailus escreveu:
> >
> > > Hi Mauro,
> > >
...
> > > Notify callbacks, perhaps not, but the list is still protected by the
> > > spinlock. It perhaps is not likely that another process would change it
> > > but
> > > I don't think we can rely on that.
> >
> > I can see only 2 risks protected by the lock:
> >
> > 1) mdev gets freed while an entity is being created. This is a problem
> >with the current memory protection schema we're using. I guess the
> >only way to fix it is to use kref for
> > mdev/entities/interfaces/links/pads.
> >This change doesn't make it better or worse.
> >Also, I don't think we have such risk with the current devices.
> >
> > 2) a notifier may be inserted or removed by another driver, while the
> >loop is running.
> >
> > To avoid (2), I see 3 alternatives:
> >
> > a) keep the loop as proposed on this patch. As the list is navigated using
> > list_for_each_entry_safe(), I guess[1] it should be safe to remove/add
> > new notify callbacks there while the loop is running by some other process.
> >
>
> list_for_each_entry_safe() does not protect against concurrent access, only
> against adding and removing list entries by the same user. List access
> serialisation is still needed, whether you use _safe() functions or not.
>
> >
> > [1] It *is* safe if the change were done inside the loop - but I'm not
> > 100% sure that it is safe if some other CPU touches the notify list.
>
> Indeed.
>
> >
> > b) Unlock/relock the spinlock every time:
> >
> > /* previous code that locks mdev->lock spinlock */
> >
> > /* invoke entity_notify callbacks */
> > list_for_each_entry_safe(notify, next, &mdev->entity_notify, list) {
> > spin_unlock(&mdev->lock);
> > (notify)->notify(entity, notify->notify_data);
> > spin_lock(&mdev->lock);
> > }
> >
> > spin_unlock(&mdev->lock);
> >
> > c) use a separate lock for the notify list -this seems to be an overkill.
> >
> > d) Protect it with the graph traversal mutex. That sounds the worse idea,
> >IMHO, as we'll be abusing the lock.
>
> I'd simply replace the spinlock with a mutex here. As we want to get rid of
> the graph mutex anyway in the long run, let's not mix the two as they're
> well separated now. As long as the mutex users do not sleep (i.e. the
> notify() callback) the mutex is about as fast to use as the spinlock.
It could work. I added such patch on an experimental branch, where
I'm addressing a few troubles with au0828 unbind logic:
https://git.linuxtv.org/mchehab/experimental.git/log/?h=au0828-unbind-fixes
The patch itself is at:
https://git.linuxtv.org/mchehab/experimental.git/commit/?h=au0828-unbind-fixes&id=dba4d41bdfa6bb8dc51cb0f692102919b2b7c8b4
At least for au0828, it seems to work fine.
Regards,
Mauro
--
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/3] [media] tvp515p: Proposal for MC input connector support
Hello, On 03/09/2016 04:09 PM, Javier Martinez Canillas wrote: > > I was waiting for the MC input connector support discussion to settle before > attempting to propose another patch series for the tvp5150 video decoder but > IIUC you are going to continue the discussion at ELC so I'm posting a series > that I believe is aligned with the latest conversations. > > This is of course a RFC and not meant to be merged but just to start looking > how the DT binding using OF graph for connectors could look like and to see > an implementation that uses a PAD (and thus link) per electrical signal (the > 1:1 model mentioned by Laurent). > Any comments about this series? Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- 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
cron job: media_tree daily build: ABI WARNING
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sun Mar 20 04:00:26 CET 2016 git branch: test git hash: b39950960d2b890c21465c69c7c0e4ff6253c6b5 gcc version:i686-linux-gcc (GCC) 5.3.0 sparse version: v0.5.0-56-g7647c77 smatch version: Warning: /share/smatch/smatch_data/ is not accessible. Use --no-data or --data to suppress this message. v0.5.0-3353-gcae47da host hardware: x86_64 host os:4.4.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: OK linux-3.17.8-i686: OK linux-3.18.7-i686: OK linux-3.19-i686: OK linux-4.0-i686: OK linux-4.1.1-i686: OK linux-4.2-i686: OK linux-4.3-i686: OK linux-4.4-i686: OK linux-4.5-i686: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-x86_64: OK linux-4.1.1-x86_64: OK linux-4.2-x86_64: OK linux-4.3-x86_64: OK linux-4.4-x86_64: OK linux-4.5-x86_64: OK apps: OK spec-git: OK ABI WARNING: change for arm-at91 ABI WARNING: change for arm-davinci ABI WARNING: change for arm-exynos ABI WARNING: change for arm-mx ABI WARNING: change for arm-omap ABI WARNING: change for arm-omap1 ABI WARNING: change for arm-pxa ABI WARNING: change for blackfin-bf561 ABI WARNING: change for i686 ABI WARNING: change for m32r ABI WARNING: change for mips ABI WARNING: change for powerpc64 ABI WARNING: change for sh ABI WARNING: change for x86_64 sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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
更多关于我的信息在
你的老朋友邀你来Q群:343257759
[PATCHv13 11/17] v4l2-subdev: add HDMI CEC ops
Add CEC callbacks to the new v4l2_subdev_cec_ops struct. These are the
low-level CEC ops that subdevs that support CEC have to implement.
Signed-off-by: Hans Verkuil
[k.deb...@samsung.com: Merged changes from CEC Updates commit by Hans Verkuil]
Signed-off-by: Kamil Debski
---
include/media/v4l2-subdev.h | 22 ++
1 file changed, 22 insertions(+)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 11e2dfe..78edf25 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -42,6 +42,18 @@
#defineV4L2_DEVICE_NOTIFY_EVENT_IOW('v', 2, struct
v4l2_event)
+struct v4l2_subdev_cec_tx_done {
+ u8 status;
+ u8 arb_lost_cnt;
+ u8 nack_cnt;
+ u8 low_drive_cnt;
+ u8 error_cnt;
+};
+
+#define V4L2_SUBDEV_CEC_TX_DONE_IOW('v', 3, struct
v4l2_subdev_cec_tx_done)
+#define V4L2_SUBDEV_CEC_RX_MSG _IOW('v', 4, struct cec_msg)
+#define V4L2_SUBDEV_CEC_CONN_INPUTS_IOW('v', 5, u16)
+
struct v4l2_device;
struct v4l2_ctrl_handler;
struct v4l2_event;
@@ -51,6 +63,7 @@ struct v4l2_subdev;
struct v4l2_subdev_fh;
struct tuner_setup;
struct v4l2_mbus_frame_desc;
+struct cec_msg;
/* decode_vbi_line */
struct v4l2_decode_vbi_line {
@@ -645,6 +658,14 @@ struct v4l2_subdev_pad_ops {
struct v4l2_mbus_frame_desc *fd);
};
+struct v4l2_subdev_cec_ops {
+ unsigned (*adap_available_log_addrs)(struct v4l2_subdev *sd);
+ int (*adap_enable)(struct v4l2_subdev *sd, bool enable);
+ int (*adap_log_addr)(struct v4l2_subdev *sd, u8 logical_addr);
+ int (*adap_transmit)(struct v4l2_subdev *sd, u8 attempts,
+u32 signal_free_time, struct cec_msg *msg);
+};
+
struct v4l2_subdev_ops {
const struct v4l2_subdev_core_ops *core;
const struct v4l2_subdev_tuner_ops *tuner;
@@ -654,6 +675,7 @@ struct v4l2_subdev_ops {
const struct v4l2_subdev_ir_ops *ir;
const struct v4l2_subdev_sensor_ops *sensor;
const struct v4l2_subdev_pad_ops*pad;
+ const struct v4l2_subdev_cec_ops*cec;
};
/*
--
2.7.0
--
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
[PATCHv13 03/17] dts: exynos4412-odroid*: enable the HDMI CEC device
From: Marek Szyprowski
Add a dts node entry and enable the HDMI CEC device present in the Exynos4
family of SoCs.
Signed-off-by: Marek Szyprowski
Signed-off-by: Hans Verkuil
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 395c3ca..c9b1425 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -500,3 +500,7 @@
&watchdog {
status = "okay";
};
+
+&hdmicec {
+ status = "okay";
+};
--
2.7.0
--
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
[PATCHv13 12/17] cec: adv7604: add cec support.
Add CEC support to the adv7604 driver.
Signed-off-by: Hans Verkuil
[k.deb...@samsung.com: Merged changes from CEC Updates commit by Hans Verkuil]
[k.deb...@samsung.com: add missing methods cec/io_write_and_or]
[k.deb...@samsung.com: change adv7604 to adv76xx in added functions]
[hansv...@cisco.com: use _clr_set instead of _and_or]
---
drivers/media/i2c/Kconfig | 2 +-
drivers/media/i2c/adv7604.c | 294 ++--
2 files changed, 259 insertions(+), 37 deletions(-)
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 993dc50..3d01ffc 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -206,7 +206,7 @@ config VIDEO_ADV7183
config VIDEO_ADV7604
tristate "Analog Devices ADV7604 decoder"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && MEDIA_CEC
depends on GPIOLIB || COMPILE_TEST
select HDMI
---help---
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 41a1bfc..2fc954a 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -40,6 +40,7 @@
#include
#include
+#include
#include
#include
#include
@@ -80,6 +81,8 @@ MODULE_LICENSE("GPL");
#define ADV76XX_OP_SWAP_CB_CR (1 << 0)
+#define ADV76XX_MAX_ADDRS (3)
+
enum adv76xx_type {
ADV7604,
ADV7611,
@@ -184,6 +187,10 @@ struct adv76xx_state {
u16 spa_port_a[2];
struct v4l2_fract aspect_ratio;
u32 rgb_quantization_range;
+ u8 cec_addr[ADV76XX_MAX_ADDRS];
+ u8 cec_valid_addrs;
+ bool cec_enabled_adap;
+
struct workqueue_struct *work_queues;
struct delayed_work delayed_work_enable_hotplug;
bool restart_stdi_once;
@@ -381,7 +388,8 @@ static inline int io_write(struct v4l2_subdev *sd, u8 reg,
u8 val)
return regmap_write(state->regmap[ADV76XX_PAGE_IO], reg, val);
}
-static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask, u8
val)
+static inline int io_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask,
+ u8 val)
{
return io_write(sd, reg, (io_read(sd, reg) & ~mask) | val);
}
@@ -414,6 +422,12 @@ static inline int cec_write(struct v4l2_subdev *sd, u8
reg, u8 val)
return regmap_write(state->regmap[ADV76XX_PAGE_CEC], reg, val);
}
+static inline int cec_write_clr_set(struct v4l2_subdev *sd, u8 reg, u8 mask,
+ u8 val)
+{
+ return cec_write(sd, reg, (cec_read(sd, reg) & ~mask) | val);
+}
+
static inline int infoframe_read(struct v4l2_subdev *sd, u8 reg)
{
struct adv76xx_state *state = to_state(sd);
@@ -501,8 +515,13 @@ static inline int edid_write_block(struct v4l2_subdev *sd,
static void adv76xx_set_hpd(struct adv76xx_state *state, unsigned int hpd)
{
+ u16 connected_inputs;
unsigned int i;
+ connected_inputs = hpd & state->info->read_cable_det(&state->sd);
+ v4l2_subdev_notify(&state->sd, V4L2_SUBDEV_CEC_CONN_INPUTS,
+ &connected_inputs);
+
for (i = 0; i < state->info->num_dv_ports; ++i)
gpiod_set_value_cansleep(state->hpd_gpio[i], hpd & BIT(i));
@@ -872,9 +891,12 @@ static int adv76xx_s_detect_tx_5v_ctrl(struct v4l2_subdev
*sd)
{
struct adv76xx_state *state = to_state(sd);
const struct adv76xx_chip_info *info = state->info;
+ u16 cable_det = info->read_cable_det(sd);
+ u16 connected_inputs = state->edid.present & cable_det;
- return v4l2_ctrl_s_ctrl(state->detect_tx_5v_ctrl,
- info->read_cable_det(sd));
+ v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_CONN_INPUTS,
+ &connected_inputs);
+ return v4l2_ctrl_s_ctrl(state->detect_tx_5v_ctrl, cable_det);
}
static int find_and_set_predefined_video_timings(struct v4l2_subdev *sd,
@@ -1900,6 +1922,200 @@ static int adv76xx_set_format(struct v4l2_subdev *sd,
return 0;
}
+static void adv76xx_cec_tx_raw_status(struct v4l2_subdev *sd, u8 tx_raw_status)
+{
+ struct v4l2_subdev_cec_tx_done tx_done = {};
+
+ if ((cec_read(sd, 0x11) & 0x01) == 0) {
+ v4l2_dbg(1, debug, sd, "%s: tx raw: tx disabled\n", __func__);
+ return;
+ }
+
+ if (tx_raw_status & 0x02) {
+ v4l2_dbg(1, debug, sd, "%s: tx raw: arbitration lost\n",
+__func__);
+ tx_done.status = CEC_TX_STATUS_ARB_LOST;
+ tx_done.arb_lost_cnt = 1;
+ v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE, &tx_done);
+ return;
+ }
+ if (tx_raw_status & 0x04) {
+ v4l2_dbg(1, debug, sd, "%s: tx raw: retry failed\n", __func__);
+ /*
+* We set this status bit since this hardware performs
+* retransmis
