[PATCH v4 11/16] drm: bridge: analogix/dp: add platform device type support
On 06.09.2015 13:07, Yakir Yang wrote:
> Hi Krzysztof,
>
> å¨ 09/04/2015 08:36 AM, Krzysztof Kozlowski åé:
>> On 01.09.2015 15:07, Yakir Yang wrote:
>>
>> Empty commit message. Please explain here why you want to add platform
>> device type support.
>>
>> Actually the title is confusing. You are not adding support for platform
>> device types but rather adding a field containing type of device.
>>
>>
>>> Signed-off-by: Yakir Yang
>>> ---
>>> Changes in v4: None
>>> Changes in v3: None
>>> Changes in v2:
>>> - Add GNU license v2 declared and samsung copyright
>>>
>>> drivers/gpu/drm/exynos/exynos_dp.c | 1 +
>>> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 1 +
>>> include/drm/bridge/analogix_dp.h| 16
>>> 3 files changed, 18 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_dp.c
>>> b/drivers/gpu/drm/exynos/exynos_dp.c
>>> index 6060d2c..40ef727 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_dp.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_dp.c
>>> @@ -224,6 +224,7 @@ static int exynos_dp_bind(struct device *dev,
>>> struct device *master, void *data)
>>> dp->dev = dev;
>>> dp->drm_dev = drm_dev;
>>> +dp->plat_data.dev_type = EXYNOS_DP;
>>> dp->plat_data.power_on = exynos_dp_poweron;
>>> dp->plat_data.power_off = exynos_dp_poweroff;
>>> dp->plat_data.get_modes = exynos_dp_get_modes;
>>> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> index efea045..4934271 100644
>>> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>>> @@ -293,6 +293,7 @@ static int rockchip_dp_bind(struct device *dev,
>>> struct device *master,
>>> return ret;
>>> }
>>> +dp->plat_data.dev_type = RK3288_DP;
>>> dp->plat_data.attach = NULL;
>>> dp->plat_data.get_modes = NULL;
>>> dp->plat_data.power_on = rockchip_dp_poweron;
>>> diff --git a/include/drm/bridge/analogix_dp.h
>>> b/include/drm/bridge/analogix_dp.h
>>> index 8b4ffad..7209a64 100644
>>> --- a/include/drm/bridge/analogix_dp.h
>>> +++ b/include/drm/bridge/analogix_dp.h
>>> @@ -1,9 +1,25 @@
>>> +/*
>>> + * Analogix Core DP (Display Port) interface driver.
>>> + *
>>> + * Copyright (C) 2012 Samsung Electronics Co., Ltd.
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>>> modify it
>>> + * under the terms of the GNU General Public License as published by
>>> the
>>> + * Free Software Foundation; either version 2 of the License, or (at
>>> your
>>> + * option) any later version.
>>> + */
>> Two questions:
>> 1. Why this change is here? I would rather expect it at patch 3/16 when
>> you created this file... That is the usual time for adding copyrights.
>
> Yep, I should move this to 03/16.
>
>> 2. Does this file contains previous Samsung work?
>
> Hmm... I think this haven't contains the previous Samsung works,
> but I have the cover the head message from analogix_dp_core driver
> (include the copyright, but without ant author).
If it does not contain Samsung's work then don't mention its copyrights.
Best regards,
Krzysztof
>
> Thanks
> - Yakir
>
>> Best regards,
>> Krzysztof
>>
>>> #ifndef _ANALOGIX_DP_H_
>>> #define _ANALOGIX_DP_H_
>>> #include
>>> +enum analogix_dp_devtype {
>>> +EXYNOS_DP,
>>> +RK3288_DP,
>>> +};
>>> +
>>> struct analogix_dp_plat_data {
>>> +enum analogix_dp_devtype dev_type;
>>> struct drm_panel *panel;
>>> int (*power_on)(struct analogix_dp_plat_data *);
>>>
>>
>>
>>
>
>
>
[PATCH libdrm 1/2] automake: set --enable-valgrind during make distcheck
Signed-off-by: Emil Velikov --- Makefile.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index a7a0cca..ca41508 100644 --- a/Makefile.am +++ b/Makefile.am @@ -37,7 +37,8 @@ AM_DISTCHECK_CONFIGURE_FLAGS = \ --enable-tegra-experimental-api \ --enable-install-test-programs \ --enable-cairo-tests \ - --enable-manpages + --enable-manpages \ + --enable-valgrind pkgconfigdir = @pkgconfigdir@ pkgconfig_DATA = libdrm.pc -- 2.5.0
[PATCH libdrm 2/2] xf86drmMode: smoke-test the atomic API
As going through the modetest patches for atomic support I've noticed
that if we pass NULL for the drmModeAtomicReqPtr argument we'll crash.
So let's handle things appropriately if the user forgot to check the
return value of drmModeAtomicAlloc and drmModeAtomicDuplicate or made a
typo somewhere along the way.
Cc: Ville Syrjälä
Cc: Rob Clark
Cc: Daniel Stone
Signed-off-by: Emil Velikov
---
xf86drmMode.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/xf86drmMode.c b/xf86drmMode.c
index 23800dd..ab6b519 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -1189,6 +1189,9 @@ drmModeAtomicReqPtr
drmModeAtomicDuplicate(drmModeAtomicReqPtr old)
{
drmModeAtomicReqPtr new;
+ if (!old)
+ return NULL;
+
new = drmMalloc(sizeof *new);
if (!new)
return NULL;
@@ -1213,6 +1216,9 @@ drmModeAtomicReqPtr
drmModeAtomicDuplicate(drmModeAtomicReqPtr old)
int drmModeAtomicMerge(drmModeAtomicReqPtr base, drmModeAtomicReqPtr augment)
{
+ if (!base)
+ return -EINVAL;
+
if (!augment || augment->cursor == 0)
return 0;
@@ -1239,12 +1245,15 @@ int drmModeAtomicMerge(drmModeAtomicReqPtr base,
drmModeAtomicReqPtr augment)
int drmModeAtomicGetCursor(drmModeAtomicReqPtr req)
{
+ if (!req)
+ return -EINVAL;
return req->cursor;
}
void drmModeAtomicSetCursor(drmModeAtomicReqPtr req, int cursor)
{
- req->cursor = cursor;
+ if (req)
+ req->cursor = cursor;
}
int drmModeAtomicAddProperty(drmModeAtomicReqPtr req,
@@ -1252,6 +1261,9 @@ int drmModeAtomicAddProperty(drmModeAtomicReqPtr req,
uint32_t property_id,
uint64_t value)
{
+ if (!req)
+ return -EINVAL;
+
if (req->cursor >= req->size_items) {
drmModeAtomicReqItemPtr new;
@@ -1309,6 +1321,9 @@ int drmModeAtomicCommit(int fd, drmModeAtomicReqPtr req,
uint32_t flags,
int obj_idx = -1;
int ret = -1;
+ if (!req)
+ return -EINVAL;
+
if (req->cursor == 0)
return 0;
--
2.5.0
[PATCH libdrm] xf86drm: remove makedev() hack/workaround
On 7 August 2015 at 17:39, Emil Velikov wrote: > Back when this was introduced commit 569da5a42eb(Merged glxmisc-3-0-0) > sys/sysmacros.h was used instead of the respecive headers (as per the > manual). > > We've been handling it correctly for a little while now - in Linux, BSD > and Solaris. Thus we can drop this workaround. > > Signed-off-by: Emil Velikov > --- > xf86drm.c | 8 > 1 file changed, 8 deletions(-) > > diff --git a/xf86drm.c b/xf86drm.c > index 5e02969..7e41537 100644 > --- a/xf86drm.c > +++ b/xf86drm.c > @@ -94,14 +94,6 @@ > #define DRM_MAJOR 226 /* Linux */ > #endif > > -/* > - * This definition needs to be changed on some systems if dev_t is a > structure. > - * If there is a header file we can get it from, there would be best. > - */ > -#ifndef makedev > -#define makedev(x,y)((dev_t)(((x) << 8) | (y))) > -#endif > - > #define DRM_MSG_VERBOSITY 3 > > #define memclear(s) memset(&s, 0, sizeof(s)) > -- > 2.5.0 > Humble ping anyone ? -Emil
[PATCH libdrm] tests: Add -lm to LDADD for dristat
From: Michel Dänzer Fixes build failure due to unresolved log2. Signed-off-by: Michel Dänzer --- tests/Makefile.am | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/Makefile.am b/tests/Makefile.am index 9a2d932..a511d28 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -33,6 +33,8 @@ check_PROGRAMS = \ dristat \ drmstat +dristat_LDADD = -lm + if HAVE_NOUVEAU SUBDIRS += nouveau endif -- 2.5.0
[PATCH v2 0/5] drm/i2c: adv7511: ADV7533 support
ADV7533 is a DSI to HDMI encoder chip. It's like ADV7511, but with an additional DSI RX block that takes in DSI video mode output. This series adds support for ADV7533. Unlike ADV7511 that's modelled as a drm i2c slave encoder, ADV7533 is a drm_bridge object. The bridge ops further create a HDMI type connector device for the chip's output. Changes in v2: - The last patch in the series has changed completely. Instead of using the dummy mipi dsi device usage, we now have two separate drivers for i2c and dsi components of the chip. This was discussed in depth (without a final conclusion) here: https://lkml.org/lkml/2015/6/30/42 With this approach, we wouldn't need to create dummy dsi devices, but we'd have two DT nodes for two different parts of the same chip - Use of_device_get_match_data() to simplify things. The older series (using dummy mipi dsi devices) is here: http://lists.freedesktop.org/archives/dri-devel/2015-July/087088.html Can we please decide on one of these approaches? Archit Taneja (4): drm/i2c: adv7511: Fix mutex deadlock when interrupts are disabled drm/i2c: adv7511: Refactor encoder slave functions drm/i2c: adv7511: Add drm_bridge/connector for ADV7533 drm/i2c: adv7511: Add dsi driver for adv7533 Lars-Peter Clausen (1): drm/i2c: adv7511: Initial support for adv7533 drivers/gpu/drm/i2c/adv7511.c | 480 ++ 1 file changed, 434 insertions(+), 46 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
[PATCH v2 1/5] drm/i2c: adv7511: Fix mutex deadlock when interrupts are disabled
When the adv7511 i2c client doesn't have an interrupt line, we observe a
deadlock on caused by trying to lock drm device's mode_config.mutex twice
in the same context.
Here is the sequence that causes it:
ioctl DRM_IOCTL_MODE_GETCONNECTOR from userspace
drm_mode_getconnector (acquires mode_config mutex)
connector->fill_modes()
drm_helper_probe_single_connector_modes
connector_funcs->get_modes
adv7511_encoder_get_modes
adv7511_get_edid_block
adv7511_irq_process
drm_helper_hpd_irq_event (acquires mode_config mutex again)
In adv7511_irq_process, don't call drm_helper_hpd_irq_event when not
called from interrupt context. It doesn't serve any purpose there anyway.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/i2c/adv7511.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
index 2aaa3c8..cf5bb29 100644
--- a/drivers/gpu/drm/i2c/adv7511.c
+++ b/drivers/gpu/drm/i2c/adv7511.c
@@ -422,7 +422,7 @@ static bool adv7511_hpd(struct adv7511 *adv7511)
return false;
}
-static int adv7511_irq_process(struct adv7511 *adv7511)
+static int adv7511_irq_process(struct adv7511 *adv7511, bool process_hpd)
{
unsigned int irq0, irq1;
int ret;
@@ -438,7 +438,7 @@ static int adv7511_irq_process(struct adv7511 *adv7511)
regmap_write(adv7511->regmap, ADV7511_REG_INT(0), irq0);
regmap_write(adv7511->regmap, ADV7511_REG_INT(1), irq1);
- if (irq0 & ADV7511_INT0_HDP && adv7511->encoder)
+ if (process_hpd && irq0 & ADV7511_INT0_HDP && adv7511->encoder)
drm_helper_hpd_irq_event(adv7511->encoder->dev);
if (irq0 & ADV7511_INT0_EDID_READY || irq1 & ADV7511_INT1_DDC_ERROR) {
@@ -456,7 +456,7 @@ static irqreturn_t adv7511_irq_handler(int irq, void *devid)
struct adv7511 *adv7511 = devid;
int ret;
- ret = adv7511_irq_process(adv7511);
+ ret = adv7511_irq_process(adv7511, true);
return ret < 0 ? IRQ_NONE : IRQ_HANDLED;
}
@@ -473,7 +473,7 @@ static int adv7511_wait_for_edid(struct adv7511 *adv7511,
int timeout)
adv7511->edid_read, msecs_to_jiffies(timeout));
} else {
for (; timeout > 0; timeout -= 25) {
- ret = adv7511_irq_process(adv7511);
+ ret = adv7511_irq_process(adv7511, false);
if (ret < 0)
break;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[PATCH v2 2/5] drm/i2c: adv7511: Initial support for adv7533
From: Lars-Peter Clausen
ADV7533 is a DSI to HDMI encoder chip. It is a derivative of ADV7511,
with additional blocks to translate input DSI data to parallel RGB
data. Besides the ADV7511 i2c register map, it has additional registers
that require to be configured to activate the DSI blocks.
Use DT compatible strings to populate the adv7533 type enum. Add minimal
register configurations belonging to the DSI/CEC register map.
Signed-off-by: Lars-Peter Clausen
---
drivers/gpu/drm/i2c/adv7511.c | 141 --
1 file changed, 122 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
index cf5bb29..cf5961d5 100644
--- a/drivers/gpu/drm/i2c/adv7511.c
+++ b/drivers/gpu/drm/i2c/adv7511.c
@@ -20,12 +20,18 @@
#include "adv7511.h"
+enum adv7511_type {
+ ADV7511,
+ ADV7533,
+};
+
struct adv7511 {
struct i2c_client *i2c_main;
struct i2c_client *i2c_edid;
+ struct i2c_client *i2c_cec;
struct regmap *regmap;
- struct regmap *packet_memory_regmap;
+ struct regmap *regmap_cec;
enum drm_connector_status status;
bool powered;
@@ -46,6 +52,8 @@ struct adv7511 {
struct edid *edid;
struct gpio_desc *gpio_pd;
+
+ enum adv7511_type type;
};
static struct adv7511 *encoder_to_adv7511(struct drm_encoder *encoder)
@@ -66,6 +74,23 @@ static const struct reg_default adv7511_fixed_registers[] = {
{ 0x55, 0x02 },
};
+/* ADI recommended values for proper operation. */
+static const struct reg_default adv7533_fixed_registers[] = {
+ { 0x16, 0x20 },
+ { 0x9a, 0xe0 },
+ { 0xba, 0x70 },
+ { 0xde, 0x82 },
+ { 0xe4, 0x40 },
+ { 0xe5, 0x80 },
+};
+
+static const struct reg_default adv7533_cec_fixed_registers[] = {
+ { 0x15, 0xd0 },
+ { 0x17, 0xd0 },
+ { 0x24, 0x20 },
+ { 0x57, 0x11 },
+};
+
/*
-
* Register access
*/
@@ -158,6 +183,15 @@ static const struct regmap_config adv7511_regmap_config = {
.volatile_reg = adv7511_register_volatile,
};
+static const struct regmap_config adv7533_cec_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = 0xff,
+ .cache_type = REGCACHE_RBTREE,
+};
+
+
/*
-
* Hardware configuration
*/
@@ -358,6 +392,25 @@ static void adv7511_set_link_config(struct adv7511
*adv7511,
adv7511->rgb = config->input_colorspace == HDMI_COLORSPACE_RGB;
}
+static void adv7511_dsi_receiver_dpms(struct adv7511 *adv7511)
+{
+ if (adv7511->type != ADV7533)
+ return;
+
+ if (adv7511->powered) {
+ /* set number of dsi lanes (hardcoded to 4 for now) */
+ regmap_write(adv7511->regmap_cec, 0x1c, 0x4 << 4);
+ /* disable internal timing generator */
+ regmap_write(adv7511->regmap_cec, 0x27, 0x0b);
+ /* enable hdmi */
+ regmap_write(adv7511->regmap_cec, 0x03, 0x89);
+ /* disable test mode */
+ regmap_write(adv7511->regmap_cec, 0x55, 0x00);
+ } else {
+ regmap_write(adv7511->regmap_cec, 0x03, 0x0b);
+ }
+}
+
static void adv7511_power_on(struct adv7511 *adv7511)
{
adv7511->current_edid_segment = -1;
@@ -387,6 +440,8 @@ static void adv7511_power_on(struct adv7511 *adv7511)
regcache_sync(adv7511->regmap);
adv7511->powered = true;
+
+ adv7511_dsi_receiver_dpms(adv7511);
}
static void adv7511_power_off(struct adv7511 *adv7511)
@@ -398,6 +453,8 @@ static void adv7511_power_off(struct adv7511 *adv7511)
regcache_mark_dirty(adv7511->regmap);
adv7511->powered = false;
+
+ adv7511_dsi_receiver_dpms(adv7511);
}
/*
-
@@ -567,6 +624,9 @@ static int adv7511_get_modes(struct drm_encoder *encoder,
/* Reading the EDID only works if the device is powered */
if (!adv7511->powered) {
+ regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER2,
+ ADV7511_REG_POWER2_HDP_SRC_MASK,
+ ADV7511_REG_POWER2_HDP_SRC_NONE);
regmap_write(adv7511->regmap, ADV7511_REG_INT(0),
ADV7511_INT0_EDID_READY);
regmap_write(adv7511->regmap, ADV7511_REG_INT(1),
@@ -770,8 +830,6 @@ static int adv7511_parse_dt(struct device_node *np,
const char *str;
int ret;
- memset(config, 0, sizeof(*config));
-
of_property_read_u32(np, "adi,input-depth", &config->input_color_depth);
if (config->input_color_depth != 8 && config->input_color_depth != 10 &&
config->input_color_depth != 12)
@@ -871,9 +929,18 @@ static int adv7511_pr
[PATCH v2 3/5] drm/i2c: adv7511: Refactor encoder slave functions
ADV7511 is represented as an i2c drm slave encoder device. ADV7533, on
the other hand, is going be a normal i2c client device creating bridge
and connector entities.
Move the code in encoder slave functions to generate helpers that are
agnostic to the drm object type. These helpers will later also be used
by bridge and connecter helper functions.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/i2c/adv7511.c | 80 ++-
1 file changed, 57 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
index cf5961d5..e35ad37 100644
--- a/drivers/gpu/drm/i2c/adv7511.c
+++ b/drivers/gpu/drm/i2c/adv7511.c
@@ -612,13 +612,11 @@ static int adv7511_get_edid_block(void *data, u8 *buf,
unsigned int block,
}
/*
-
- * Encoder operations
+ * ADV75xx helpers
*/
-
-static int adv7511_get_modes(struct drm_encoder *encoder,
-struct drm_connector *connector)
+static int adv7511_get_modes(struct adv7511 *adv7511,
+ struct drm_connector *connector)
{
- struct adv7511 *adv7511 = encoder_to_adv7511(encoder);
struct edid *edid;
unsigned int count;
@@ -656,21 +654,10 @@ static int adv7511_get_modes(struct drm_encoder *encoder,
return count;
}
-static void adv7511_encoder_dpms(struct drm_encoder *encoder, int mode)
-{
- struct adv7511 *adv7511 = encoder_to_adv7511(encoder);
-
- if (mode == DRM_MODE_DPMS_ON)
- adv7511_power_on(adv7511);
- else
- adv7511_power_off(adv7511);
-}
-
static enum drm_connector_status
-adv7511_encoder_detect(struct drm_encoder *encoder,
+adv7511_detect(struct adv7511 *adv7511,
struct drm_connector *connector)
{
- struct adv7511 *adv7511 = encoder_to_adv7511(encoder);
enum drm_connector_status status;
unsigned int val;
bool hpd;
@@ -694,7 +681,7 @@ adv7511_encoder_detect(struct drm_encoder *encoder,
if (status == connector_status_connected && hpd && adv7511->powered) {
regcache_mark_dirty(adv7511->regmap);
adv7511_power_on(adv7511);
- adv7511_get_modes(encoder, connector);
+ adv7511_get_modes(adv7511, connector);
if (adv7511->status == connector_status_connected)
status = connector_status_disconnected;
} else {
@@ -708,8 +695,8 @@ adv7511_encoder_detect(struct drm_encoder *encoder,
return status;
}
-static int adv7511_encoder_mode_valid(struct drm_encoder *encoder,
- struct drm_display_mode *mode)
+static int adv7511_mode_valid(struct adv7511 *adv7511,
+const struct drm_display_mode *mode)
{
if (mode->clock > 165000)
return MODE_CLOCK_HIGH;
@@ -717,11 +704,10 @@ static int adv7511_encoder_mode_valid(struct drm_encoder
*encoder,
return MODE_OK;
}
-static void adv7511_encoder_mode_set(struct drm_encoder *encoder,
+static void adv7511_mode_set(struct adv7511 *adv7511,
struct drm_display_mode *mode,
struct drm_display_mode *adj_mode)
{
- struct adv7511 *adv7511 = encoder_to_adv7511(encoder);
unsigned int low_refresh_rate;
unsigned int hsync_polarity = 0;
unsigned int vsync_polarity = 0;
@@ -812,12 +798,60 @@ static void adv7511_encoder_mode_set(struct drm_encoder
*encoder,
adv7511->f_tmds = mode->clock;
}
+/*
-
+ * Encoder operations
+ */
+
+static int adv7511_encoder_get_modes(struct drm_encoder *encoder,
+struct drm_connector *connector)
+{
+ struct adv7511 *adv7511 = encoder_to_adv7511(encoder);
+
+ return adv7511_get_modes(adv7511, connector);
+}
+
+static void adv7511_encoder_dpms(struct drm_encoder *encoder, int mode)
+{
+ struct adv7511 *adv7511 = encoder_to_adv7511(encoder);
+
+ if (mode == DRM_MODE_DPMS_ON)
+ adv7511_power_on(adv7511);
+ else
+ adv7511_power_off(adv7511);
+}
+
+static enum drm_connector_status
+adv7511_encoder_detect(struct drm_encoder *encoder,
+ struct drm_connector *connector)
+{
+ struct adv7511 *adv7511 = encoder_to_adv7511(encoder);
+
+ return adv7511_detect(adv7511, connector);
+}
+
+static int adv7511_encoder_mode_valid(struct drm_encoder *encoder,
+ struct drm_display_mode *mode)
+{
+ struct adv7511 *adv7511 = encoder_to_adv7511(encoder);
+
+ return adv7511_mode_valid(adv7511, mode);
+}
+
+static void adv7511_encoder_mode_set(struct drm_encoder *encoder,
+struct drm_display_mode *mode,
+
[PATCH v2 4/5] drm/i2c: adv7511: Add drm_bridge/connector for ADV7533
Create bridge and connector helper functions. These internally refer to
the ADV75xx helper functions.
The driver registers a drm_bridge object during probe. The bridge, in
turn registers a HDMI connector when a user attaches the bridge.
Therefore, when the device type is ADV7533, we create bridge and
connector entities, and when it's ADV7511, we create a slave encoder as
before.
Since the i2c driver is still wrapped around by the drm_i2c_slave_encoder
struct. We make sure the encoder_init op returns an error when the device
type is ADV7533.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/i2c/adv7511.c | 155 ++
1 file changed, 155 insertions(+)
diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
index e35ad37..b6c80e3 100644
--- a/drivers/gpu/drm/i2c/adv7511.c
+++ b/drivers/gpu/drm/i2c/adv7511.c
@@ -17,6 +17,8 @@
#include
#include
#include
+#include
+#include
#include "adv7511.h"
@@ -44,6 +46,9 @@ struct adv7511 {
wait_queue_head_t wq;
struct drm_encoder *encoder;
+ struct drm_connector connector;
+ struct drm_bridge bridge;
+
bool embedded_sync;
enum adv7511_sync_polarity vsync_polarity;
enum adv7511_sync_polarity hsync_polarity;
@@ -855,6 +860,139 @@ static struct drm_encoder_slave_funcs
adv7511_encoder_funcs = {
};
/*
-
+ * Bridge and connector functions
+ */
+
+static struct adv7511 *connector_to_adv7511(struct drm_connector *connector)
+{
+ return container_of(connector, struct adv7511, connector);
+}
+
+/* Connector helper functions */
+static int adv7533_connector_get_modes(struct drm_connector *connector)
+{
+ struct adv7511 *adv = connector_to_adv7511(connector);
+
+ return adv7511_get_modes(adv, connector);
+}
+
+static struct drm_encoder *
+adv7533_connector_best_encoder(struct drm_connector *connector)
+{
+ struct adv7511 *adv = connector_to_adv7511(connector);
+
+ return adv->bridge.encoder;
+}
+
+static enum drm_mode_status
+adv7533_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
+{
+ struct adv7511 *adv = connector_to_adv7511(connector);
+
+ return adv7511_mode_valid(adv, mode);
+}
+
+static struct drm_connector_helper_funcs adv7533_connector_helper_funcs = {
+ .get_modes = adv7533_connector_get_modes,
+ .best_encoder = adv7533_connector_best_encoder,
+ .mode_valid = adv7533_connector_mode_valid,
+};
+
+static enum drm_connector_status
+adv7533_connector_detect(struct drm_connector *connector, bool force)
+{
+ struct adv7511 *adv = connector_to_adv7511(connector);
+
+ return adv7511_detect(adv, connector);
+}
+
+static struct drm_connector_funcs adv7533_connector_funcs = {
+ .dpms = drm_helper_connector_dpms,
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .detect = adv7533_connector_detect,
+ .destroy = drm_connector_cleanup,
+ .reset = drm_atomic_helper_connector_reset,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+/* Bridge funcs */
+static struct adv7511 *bridge_to_adv7511(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct adv7511, bridge);
+}
+
+static void adv7533_bridge_pre_enable(struct drm_bridge *bridge)
+{
+ struct adv7511 *adv = bridge_to_adv7511(bridge);
+
+ adv7511_power_on(adv);
+}
+
+static void adv7533_bridge_post_disable(struct drm_bridge *bridge)
+{
+ struct adv7511 *adv = bridge_to_adv7511(bridge);
+
+ adv7511_power_off(adv);
+}
+
+static void adv7533_bridge_enable(struct drm_bridge *bridge)
+{
+}
+
+static void adv7533_bridge_disable(struct drm_bridge *bridge)
+{
+}
+
+static void adv7533_bridge_mode_set(struct drm_bridge *bridge,
+struct drm_display_mode *mode,
+struct drm_display_mode *adj_mode)
+{
+ struct adv7511 *adv = bridge_to_adv7511(bridge);
+
+ adv7511_mode_set(adv, mode, adj_mode);
+}
+
+static int adv7533_bridge_attach(struct drm_bridge *bridge)
+{
+ struct adv7511 *adv = bridge_to_adv7511(bridge);
+ int ret;
+
+ adv->encoder = bridge->encoder;
+
+ if (!bridge->encoder) {
+ DRM_ERROR("Parent encoder object not found");
+ return -ENODEV;
+ }
+
+ adv->connector.polled = DRM_CONNECTOR_POLL_HPD;
+ ret = drm_connector_init(bridge->dev, &adv->connector,
+ &adv7533_connector_funcs, DRM_MODE_CONNECTOR_HDMIA);
+ if (ret) {
+ DRM_ERROR("Failed to initialize connector with drm\n");
+ return ret;
+ }
+ drm_connector_helper_add(&adv->connector,
+ &adv7533_connector_hel
[PATCH v2 5/5] drm/i2c: adv7511: Add dsi driver for adv7533
Add a separate mipi_dsi_driver for adv7533. In the case of this chip,
both the i2c and dsi drivers will operate together.
Both the drivers are expected to use the same per-device driver
data struct. The i2c driver takes the responsibility of allocating
the struct, and the dsi device gets a pointer to it by getting the
corresponding i2c client device's data.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/i2c/adv7511.c | 98 ++-
1 file changed, 97 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
index b6c80e3..8325913 100644
--- a/drivers/gpu/drm/i2c/adv7511.c
+++ b/drivers/gpu/drm/i2c/adv7511.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include "adv7511.h"
@@ -58,6 +59,9 @@ struct adv7511 {
struct gpio_desc *gpio_pd;
+ struct mipi_dsi_device *dsi;
+ int num_dsi_lanes;
+
enum adv7511_type type;
};
@@ -403,8 +407,10 @@ static void adv7511_dsi_receiver_dpms(struct adv7511
*adv7511)
return;
if (adv7511->powered) {
+ struct mipi_dsi_device *dsi = adv7511->dsi;
+
/* set number of dsi lanes (hardcoded to 4 for now) */
- regmap_write(adv7511->regmap_cec, 0x1c, 0x4 << 4);
+ regmap_write(adv7511->regmap_cec, 0x1c, dsi->lanes << 4);
/* disable internal timing generator */
regmap_write(adv7511->regmap_cec, 0x27, 0x0b);
/* enable hdmi */
@@ -1289,8 +1295,97 @@ static struct drm_i2c_encoder_driver adv7511_driver = {
.encoder_init = adv7511_encoder_init,
};
+/* Driver for the DSI component within the chip */
+static int adv7533_parse_dt(struct device_node *np, struct adv7511 *adv7511)
+{
+ u32 num_lanes;
+
+ of_property_read_u32(np, "adi,dsi-lanes", &num_lanes);
+
+ if (num_lanes < 1 || num_lanes > 4)
+ return -EINVAL;
+
+ adv7511->num_dsi_lanes = num_lanes;
+
+ /* TODO: Check if these need to be parsed by DT or not */
+ adv7511->rgb = true;
+ adv7511->embedded_sync = false;
+
+ return 0;
+}
+
+static int adv7533_probe(struct mipi_dsi_device *dsi)
+{
+ struct device *dev = &dsi->dev;
+ struct adv7511 *adv7511;
+ struct device_node *np = dsi->dev.of_node;
+ struct device_node *i2c_node;
+ struct i2c_client *i2c;
+ int ret;
+
+ i2c_node = of_parse_phandle(np, "i2c-control", 0);
+ if (!i2c_node)
+ return -ENODEV;
+
+ i2c = of_find_i2c_device_by_node(i2c_node);
+ if (!i2c)
+ return -EPROBE_DEFER;
+
+ adv7511 = i2c_get_clientdata(i2c);
+ if (!adv7511)
+ return -ENODEV;
+
+ /* this sets up link with the i2c driver */
+ adv7511->dsi = dsi;
+
+ mipi_dsi_set_drvdata(dsi, adv7511);
+
+ ret = adv7533_parse_dt(np, adv7511);
+ if (ret)
+ return ret;
+
+ dsi->lanes = adv7511->num_dsi_lanes;
+ dsi->format = MIPI_DSI_FMT_RGB888;
+ dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE
+ | MIPI_DSI_MODE_EOT_PACKET | MIPI_DSI_MODE_VIDEO_HSE;
+
+ return mipi_dsi_attach(dsi);
+}
+
+static int adv7533_remove(struct mipi_dsi_device *dsi)
+{
+ mipi_dsi_detach(dsi);
+
+ return 0;
+}
+
+static const struct of_device_id adv7533_of_match[] = {
+ { .compatible = "adi,adv7533-dsi" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, adv7533_of_match);
+
+static struct mipi_dsi_driver adv7533_driver = {
+ .probe = adv7533_probe,
+ .remove = adv7533_remove,
+ .driver = {
+ .name = "adv7533",
+ .of_match_table = adv7533_of_match,
+ },
+};
+
static int __init adv7511_init(void)
{
+ int ret;
+
+ /*
+* not bailing out here because adv7511 variant won't
+* need a DSI driver
+*/
+ ret = mipi_dsi_driver_register(&adv7533_driver);
+ if (ret)
+ DRM_DEBUG("mipi driver register failed %d\n", ret);
+
return drm_i2c_encoder_register(THIS_MODULE, &adv7511_driver);
}
module_init(adv7511_init);
@@ -1298,6 +1393,7 @@ module_init(adv7511_init);
static void __exit adv7511_exit(void)
{
drm_i2c_encoder_unregister(&adv7511_driver);
+ mipi_dsi_driver_unregister(&adv7533_driver);
}
module_exit(adv7511_exit);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
[RFC 0/2] drm/dsi: DSI for devices with different control bus
Thierry,
On 08/21/2015 11:39 AM, Archit Taneja wrote:
>
>
> On 08/20/2015 05:18 PM, Thierry Reding wrote:
>> On Thu, Aug 20, 2015 at 09:46:14AM +0530, Archit Taneja wrote:
>>> Hi Thierry, Lucas,
>>>
>>>
>>> On 08/19/2015 08:32 PM, Thierry Reding wrote:
On Wed, Aug 19, 2015 at 04:52:24PM +0200, Lucas Stach wrote:
> Am Mittwoch, den 19.08.2015, 16:34 +0200 schrieb Thierry Reding:
>> On Wed, Aug 19, 2015 at 04:17:08PM +0200, Lucas Stach wrote:
>>> Hi Thierry, Archit,
>>>
> [...]
Perhaps a better way would be to invert this relationship.
According to
your proposal we'd have to have DT like this:
i2c at ... {
...
dsi-device at ... {
...
dsi-bus = <&dsi>;
...
};
...
};
dsi at ... {
...
};
Inversing the relationship would become something like this:
i2c at ... {
...
};
dsi at ... {
...
peripheral at ... {
...
i2c-bus = <&i2c>;
...
};
...
};
Both of those aren't fundamentally different, and they both have
the
disavantage of lacking ways to transport configuration data that
the
other bus needs to instantiate the dummy device (such as the reg
property for example, denoting the I2C slave address or the DSI
VC).
So how about we create two devices in the device tree and fuse
them at
the driver level:
i2c at ... {
...
i2cdsi: dsi-device at ... {
...
};
...
};
dsi at ... {
...
peripheral at ... {
...
control = <&i2cdsi>;
...
};
...
};
This way we'll get both an I2C device and a DSI device that we
can fully
describe using the standard device tree bindings. At driver time
we can
get the I2C device from the phandle in the control property of
the DSI
device and use it to execute I2C transactions.
>>> I don't really like to see that you are inventing yet-another-way to
>>> handle devices connected to multiple buses.
>>>
>>> Devicetree is structured along the control buses, even if the
>>> devices
>>> are connected to multiple buses, in the DT they are always
>>> children of
>>> the bus that is used to control their registers from the CPUs
>>> perspective. So a DSI encoder that is controlled through i2c is
>>> clearly
>>> a child of the i2c master controller and only of that one.
>>
>> I think that's a flawed interpretation of what's going on here. The
>> device in fact has two interfaces: one is I2C, the other is DSI.
>> In my
>> opinion that's reason enough to represent it as two logical devices.
>>
> Does it really have 2 control interfaces that are used at the same
> time?
> Or is the DSI connection a passive data bus if the register control
> happens through i2c?
The interfaces may not be used at the same time, and the DSI interface
may even be crippled, but the device is still addressable from the DSI
host controller, if for nothing else than for routing the video stream.
>>> If you need to model connections between devices that are not
>>> reflected
>>> through the control bus hierarchy you should really consider
>>> using the
>>> standardized of-graph bindings.
>>> (Documentation/devicetree/bindings/graph.txt)
>>
>> The problem is that the original proposal would instantiate a dummy
>> device, so it wouldn't be represented in DT at all. So unless you
>> do add
>> two logical devices to DT (one for each bus interface), you don't
>> have
>> anything to glue together with an OF graph.
>>
> I see that the having dummy device is the least desirable solution.
> But
> if there is only one control bus to the device I think it should be
> one
> device sitting beneath the control bus.
>
> You can then use of-graph to model the data path between the DSI
> encoder
> and device.
But you will be needing a device below the DSI host controller to
represent that endpoint of the connection. The DSI host controller
itself is in no way connected to the I2C adapter. You would have to
>
[PATCH] drm/mgag200: fix memory leak
If drm_fb_helper_alloc_fbi() fails then we were directly returning
without freeing sysram. Also if drm_fb_helper_alloc_fbi() succeeds but
mgag200_framebuffer_init() fails then we were not releasing sysram and
we were not releasing fbi helper also.
Signed-off-by: Sudip Mukherjee
---
drivers/gpu/drm/mgag200/mgag200_fb.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c
b/drivers/gpu/drm/mgag200/mgag200_fb.c
index 87de15e..5fe476a 100644
--- a/drivers/gpu/drm/mgag200/mgag200_fb.c
+++ b/drivers/gpu/drm/mgag200/mgag200_fb.c
@@ -189,14 +189,16 @@ static int mgag200fb_create(struct drm_fb_helper *helper,
return -ENOMEM;
info = drm_fb_helper_alloc_fbi(helper);
- if (IS_ERR(info))
- return PTR_ERR(info);
+ if (IS_ERR(info)) {
+ ret = PTR_ERR(info);
+ goto err_alloc_fbi;
+ }
info->par = mfbdev;
ret = mgag200_framebuffer_init(dev, &mfbdev->mfb, &mode_cmd, gobj);
if (ret)
- return ret;
+ goto err_framebuffer_init;
mfbdev->sysram = sysram;
mfbdev->size = size;
@@ -226,6 +228,13 @@ static int mgag200fb_create(struct drm_fb_helper *helper,
DRM_DEBUG_KMS("allocated %dx%d\n",
fb->width, fb->height);
return 0;
+
+err_framebuffer_init:
+ drm_fb_helper_release_fbi(helper);
+
+err_alloc_fbi:
+ vfree(sysram);
+ return ret;
}
static int mga_fbdev_destroy(struct drm_device *dev,
--
1.9.1
[PATCH v4 09/22] drm: Probe panels on demand
When looking up a panel through its OF node, probe it if it hasn't
already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: Tomeu Vizoso
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/drm_panel.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 2ef988e037b7..ad79a7b9c74d 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -23,6 +23,7 @@
#include
#include
+#include
#include
#include
@@ -80,6 +81,8 @@ struct drm_panel *of_drm_find_panel(struct device_node *np)
{
struct drm_panel *panel;
+ of_device_probe(np);
+
mutex_lock(&panel_lock);
list_for_each_entry(panel, &panel_list, list) {
--
2.4.3
[PATCH v4 10/22] drm/tegra: Probe dpaux devices on demand
When looking up a dpaux device through its OF node, probe it if it
hasn't already.
The goal is to reduce deferred probes to a minimum, as it makes it very
cumbersome to find out why a device failed to probe, and can introduce
very big delays in when a critical device is probed.
Signed-off-by: Tomeu Vizoso
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/tegra/dpaux.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
index 224a7dc8e4ed..96a2eec7e020 100644
--- a/drivers/gpu/drm/tegra/dpaux.c
+++ b/drivers/gpu/drm/tegra/dpaux.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -439,6 +440,8 @@ struct tegra_dpaux *tegra_dpaux_find_by_of_node(struct
device_node *np)
{
struct tegra_dpaux *dpaux;
+ of_device_probe(np);
+
mutex_lock(&dpaux_lock);
list_for_each_entry(dpaux, &dpaux_list, list)
--
2.4.3
[PATCH libdrm 2/2] xf86drmMode: smoke-test the atomic API
On Mon, Sep 07, 2015 at 10:53:06AM +0100, Emil Velikov wrote:
> As going through the modetest patches for atomic support I've noticed
> that if we pass NULL for the drmModeAtomicReqPtr argument we'll crash.
>
> So let's handle things appropriately if the user forgot to check the
> return value of drmModeAtomicAlloc and drmModeAtomicDuplicate or made a
> typo somewhere along the way.
I'm not sure hand-holding the user to such an extent is actually useful.
OTOH I guess one NULL check per function call isn't all that expensive
either.
>
> Cc: Ville Syrjälä
> Cc: Rob Clark
> Cc: Daniel Stone
> Signed-off-by: Emil Velikov
> ---
> xf86drmMode.c | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/xf86drmMode.c b/xf86drmMode.c
> index 23800dd..ab6b519 100644
> --- a/xf86drmMode.c
> +++ b/xf86drmMode.c
> @@ -1189,6 +1189,9 @@ drmModeAtomicReqPtr
> drmModeAtomicDuplicate(drmModeAtomicReqPtr old)
> {
> drmModeAtomicReqPtr new;
>
> + if (!old)
> + return NULL;
> +
> new = drmMalloc(sizeof *new);
> if (!new)
> return NULL;
> @@ -1213,6 +1216,9 @@ drmModeAtomicReqPtr
> drmModeAtomicDuplicate(drmModeAtomicReqPtr old)
>
> int drmModeAtomicMerge(drmModeAtomicReqPtr base, drmModeAtomicReqPtr augment)
> {
> + if (!base)
> + return -EINVAL;
> +
> if (!augment || augment->cursor == 0)
> return 0;
>
> @@ -1239,12 +1245,15 @@ int drmModeAtomicMerge(drmModeAtomicReqPtr base,
> drmModeAtomicReqPtr augment)
>
> int drmModeAtomicGetCursor(drmModeAtomicReqPtr req)
> {
> + if (!req)
> + return -EINVAL;
> return req->cursor;
> }
>
> void drmModeAtomicSetCursor(drmModeAtomicReqPtr req, int cursor)
> {
> - req->cursor = cursor;
> + if (req)
> + req->cursor = cursor;
> }
>
> int drmModeAtomicAddProperty(drmModeAtomicReqPtr req,
> @@ -1252,6 +1261,9 @@ int drmModeAtomicAddProperty(drmModeAtomicReqPtr req,
>uint32_t property_id,
>uint64_t value)
> {
> + if (!req)
> + return -EINVAL;
> +
> if (req->cursor >= req->size_items) {
> drmModeAtomicReqItemPtr new;
>
> @@ -1309,6 +1321,9 @@ int drmModeAtomicCommit(int fd, drmModeAtomicReqPtr
> req, uint32_t flags,
> int obj_idx = -1;
> int ret = -1;
>
> + if (!req)
> + return -EINVAL;
> +
> if (req->cursor == 0)
> return 0;
>
> --
> 2.5.0
--
Ville Syrjälä
Intel OTC
[PATCH] virtio-gpu: fix compilation warnings
On Mi, 2015-09-02 at 12:30 +0300, Mike Rapoport wrote: > Update snprintf format in virtgpu_fence.c and virtgpu_debugfs.c to fix the > following compilation warnings: > > C [M] drivers/gpu/drm/virtio/virtgpu_fence.o > drivers/gpu/drm/virtio/virtgpu_fence.c: In function > âvirtio_timeline_value_strâ : > drivers/gpu/drm/virtio/virtgpu_fence.c:64:2: warning: format â%luâ > expects argument of type âlong unsigned intâ, but argument 4 has type > âlong long intâ [-Wformat=] > snprintf(str, size, "%lu", atomic64_read(&fence->drv->last_seq)); > ^ > CC [M] drivers/gpu/drm/virtio/virtgpu_debugfs.o > drivers/gpu/drm/virtio/virtgpu_debugfs.c: In function > âvirtio_gpu_debugfs_irq_infoâ: > drivers/gpu/drm/virtio/virtgpu_debugfs.c:39:6: warning: format â%ldâ > expects argument of type âlong intâ, but argument 3 has type âlong long > intâ [-Wformat=] > vgdev->fence_drv.sync_seq); Doesn't fly. I assume this removes the warnings for 32bit builds, but with the patch applied I get warnings on 64bit builds ... cheers, Gerd
[PATCH 1/3] drm: Make some modes const when iterating through them
From: Ville Syrjälä
valid_inferred_mode() don't change the modes over which it iterates,
so make the iterator const.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 05bb731..9afb1fc 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2044,7 +2044,7 @@ mode_in_range(const struct drm_display_mode *mode, struct
edid *edid,
static bool valid_inferred_mode(const struct drm_connector *connector,
const struct drm_display_mode *mode)
{
- struct drm_display_mode *m;
+ const struct drm_display_mode *m;
bool ok = false;
list_for_each_entry(m, &connector->probed_modes, head) {
--
2.4.6
[PATCH 2/3] drm: Remove the 'mode' argument from drm_select_eld()
From: Ville Syrjälä
drm_select_eld() doesn't look at the passed in mode, so don't pass it
in.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 4 +---
drivers/gpu/drm/i915/intel_audio.c | 2 +-
include/drm/drm_edid.h | 3 +--
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9afb1fc..e32218f 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3396,7 +3396,6 @@ EXPORT_SYMBOL(drm_av_sync_delay);
/**
* drm_select_eld - select one ELD from multiple HDMI/DP sinks
* @encoder: the encoder just changed display mode
- * @mode: the adjusted display mode
*
* It's possible for one encoder to be associated with multiple HDMI/DP sinks.
* The policy is now hard coded to simply use the first HDMI/DP sink's ELD.
@@ -3404,8 +3403,7 @@ EXPORT_SYMBOL(drm_av_sync_delay);
* Return: The connector associated with the first HDMI/DP sink that has ELD
* attached to it.
*/
-struct drm_connector *drm_select_eld(struct drm_encoder *encoder,
-struct drm_display_mode *mode)
+struct drm_connector *drm_select_eld(struct drm_encoder *encoder)
{
struct drm_connector *connector;
struct drm_device *dev = encoder->dev;
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index 89c1a8ce..f73de0b 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -404,7 +404,7 @@ void intel_audio_codec_enable(struct intel_encoder
*intel_encoder)
struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
enum port port = intel_dig_port->port;
- connector = drm_select_eld(encoder, mode);
+ connector = drm_select_eld(encoder);
if (!connector)
return;
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 53c53c4..31528d9 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -327,8 +327,7 @@ int drm_edid_to_sad(struct edid *edid, struct cea_sad
**sads);
int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb);
int drm_av_sync_delay(struct drm_connector *connector,
struct drm_display_mode *mode);
-struct drm_connector *drm_select_eld(struct drm_encoder *encoder,
-struct drm_display_mode *mode);
+struct drm_connector *drm_select_eld(struct drm_encoder *encoder);
int drm_load_edid_firmware(struct drm_connector *connector);
int
--
2.4.6
[PATCH 3/3] drm: Make drm_av_sync_delay() 'mode' argument const
From: Ville Syrjälä
drm_av_sync_delay() doesn't change the passed in mode, so make it const.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 2 +-
include/drm/drm_edid.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e32218f..d895556 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3361,7 +3361,7 @@ EXPORT_SYMBOL(drm_edid_to_speaker_allocation);
* the sink doesn't support audio or video.
*/
int drm_av_sync_delay(struct drm_connector *connector,
- struct drm_display_mode *mode)
+ const struct drm_display_mode *mode)
{
int i = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
int a, v;
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 31528d9..2af9769 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -326,7 +326,7 @@ void drm_edid_to_eld(struct drm_connector *connector,
struct edid *edid);
int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb);
int drm_av_sync_delay(struct drm_connector *connector,
- struct drm_display_mode *mode);
+ const struct drm_display_mode *mode);
struct drm_connector *drm_select_eld(struct drm_encoder *encoder);
int drm_load_edid_firmware(struct drm_connector *connector);
--
2.4.6
[git pull] drm for 4.3
On Fri, Sep 04, 2015 at 11:40:53PM +0100, Dave Airlie wrote: > > Hi Linus, > > This is the main pull request for the drm for 4.3. Nouveau is probably the > biggest > amount of changes in here, since it missed 4.2. Highlights below, along with > the usual > bunch of fixes. There are a few minor conflicts with your tree but nothing > you can't handle. All stuff outside drm should have applicable acks. > > Highlights: > > ... > i915: > Skylake support enabled by default > legacy modesetting using atomic infrastructure > Skylake fixes > GEN9 workarounds Since this merge, I'm seeing this twice during boot.. [ cut here ] WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/i915/intel_display.c:1377 assert_planes_disabled+0xdf/0x140() plane A assertion failure, should be disabled but not CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.2.0-think+ #9 Workqueue: events_unbound async_run_entry_fn 0561 88050392b6f8 8d7dccce 88050392b740 88050392b730 8d079ee2 880500a6 8805008e99c8 88050392b790 Call Trace: [] dump_stack+0x4e/0x79 [] warn_slowpath_common+0x82/0xc0 [] warn_slowpath_fmt+0x4c/0x50 [] assert_planes_disabled+0xdf/0x140 [] intel_disable_pipe+0x4b/0x2c0 [] haswell_crtc_disable+0x8a/0x2e0 [] intel_atomic_commit+0xff/0x1320 [] ? drm_atomic_check_only+0x21e/0x550 [] drm_atomic_commit+0x37/0x60 [] drm_atomic_helper_set_config+0x1c5/0x430 [] drm_mode_set_config_internal+0x65/0x110 [] restore_fbdev_mode+0xbe/0xe0 [] drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70 [] drm_fb_helper_set_par+0x2d/0x50 [] intel_fbdev_set_par+0x1a/0x60 [] fbcon_init+0x545/0x5d0 [] visual_init+0xca/0x130 [] do_bind_con_driver+0x1c5/0x3b0 [] do_take_over_console+0x149/0x1a0 [] do_fbcon_takeover+0x57/0xb0 [] fbcon_event_notify+0x66c/0x760 [] notifier_call_chain+0x3e/0xb0 [] __blocking_notifier_call_chain+0x4d/0x70 [] blocking_notifier_call_chain+0x16/0x20 [] fb_notifier_call_chain+0x1b/0x20 [] register_framebuffer+0x1e7/0x300 [] drm_fb_helper_initial_config+0x252/0x3e0 [] intel_fbdev_initial_config+0x1b/0x20 [] async_run_entry_fn+0x4a/0x140 [] process_one_work+0x1fd/0x670 [] ? process_one_work+0x16c/0x670 [] worker_thread+0x4e/0x450 [] ? process_one_work+0x670/0x670 [] kthread+0x101/0x120 [] ? kthread_create_on_node+0x250/0x250 [] ret_from_fork+0x3f/0x70 [] ? kthread_create_on_node+0x250/0x250 ---[ end trace 54cab2e0c772d5d9 ]--- 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3 Processor Integrated Graphics Controller (rev 06)
[PATCH 0/6] scripts/kernel-doc: Kernel-doc improvements
The following series contains: * kernel-doc: markdown support and improvements. * Fixing kernel-doc highlights. * Improve doc support for functions and structs with same name. * misc small fixes for drm docbook. Signed-off-by: Danilo Cesar Lemes de Paula Cc: Daniel Vetter Cc: Jonathan Corbet Cc: Andrew Morton Cc: Johannes Berg Cc: linux-kernel at vger.kernel.org Cc: linux-doc at vger.kernel.org Cc: intel-gfx Cc: dri-devel Danilo Cesar Lemes de Paula (6): scripts/kernel-doc: Replacing highlights hash by an array scripts/kernel-doc: Adding infrastructure for markdown support drm/doc: Convert to markdown drm/doc: Fixing xml documentation warning scripts/kernel-doc: Improve Markdown results scripts/kernel-doc: Processing -nofunc for functions only Documentation/DocBook/Makefile | 25 +++-- Documentation/DocBook/drm.tmpl | 86 --- drivers/gpu/drm/drm_modes.c| 12 +-- drivers/gpu/drm/drm_modeset_lock.c | 14 ++- drivers/gpu/drm/drm_prime.c| 16 ++- drivers/gpu/drm/i915/i915_reg.h| 48 - include/drm/drm_modeset_lock.h | 10 +- include/drm/drm_vma_manager.h | 10 +- scripts/docproc.c | 54 +++--- scripts/kernel-doc | 216 ++--- 10 files changed, 264 insertions(+), 227 deletions(-) -- 2.4.3
[PATCH 1/6] scripts/kernel-doc: Replacing highlights hash by an array
The "highlight" code is very sensible to the order of the hash keys, but the order of the keys cannot be predicted. It generates faulty DocBook entries like: - @device_for_each_child Sorting the result is not enough some times (as it's deterministic but we can't control it). We should use an array for that job, so we can guarantee that the order of the regex execution on dohighlight is correct. Signed-off-by: Danilo Cesar Lemes de Paula Cc: Randy Dunlap Cc: Daniel Vetter Cc: Laurent Pinchart Cc: Jonathan Corbet Cc: Herbert Xu Cc: Stephan Mueller Cc: Michal Marek Cc: linux-kernel at vger.kernel.org Cc: linux-doc at vger.kernel.org Cc: intel-gfx Cc: dri-devel --- scripts/kernel-doc | 104 ++--- 1 file changed, 60 insertions(+), 44 deletions(-) diff --git a/scripts/kernel-doc b/scripts/kernel-doc index 9a08fb5..0affe4f 100755 --- a/scripts/kernel-doc +++ b/scripts/kernel-doc @@ -206,59 +206,73 @@ my $type_env = '(\$\w+)'; # One for each output format # these work fairly well -my %highlights_html = ( $type_constant, "\$1", - $type_func, "\$1", - $type_struct_xml, "\$1", - $type_env, "\$1", - $type_param, "\$1" ); +my @highlights_html = ( + [$type_constant, "\$1"], + [$type_func, "\$1"], + [$type_struct_xml, "\$1"], + [$type_env, "\$1"], + [$type_param, "\$1"] + ); my $local_lt = "lt:"; my $local_gt = "gt:"; my $blankline_html = $local_lt . "p" . $local_gt; # was "" # html version 5 -my %highlights_html5 = ( $type_constant, "\$1", - $type_func, "\$1", - $type_struct_xml, "\$1", - $type_env, "\$1", - $type_param, "\$1" ); +my @highlights_html5 = ( +[$type_constant, "\$1"], +[$type_func, "\$1"], +[$type_struct_xml, "\$1"], +[$type_env, "\$1"], +[$type_param, "\$1]"] + ); my $blankline_html5 = $local_lt . "br /" . $local_gt; # XML, docbook format -my %highlights_xml = ( "([^=])\\\"([^\\\"<]+)\\\"", "\$1\$2", - $type_constant, "\$1", - $type_func, "\$1", - $type_struct_xml, "\$1", - $type_env, "\$1", - $type_param, "\$1" ); +my @highlights_xml = ( + ["([^=])\\\"([^\\\"<]+)\\\"", "\$1\$2"], + [$type_constant, "\$1"], + [$type_struct_xml, "\$1"], + [$type_param, "\$1"], + [$type_func, "\$1"], + [$type_env, "\$1"] +); my $blankline_xml = $local_lt . "/para" . $local_gt . $local_lt . "para" . $local_gt . "\n"; # gnome, docbook format -my %highlights_gnome = ( $type_constant, "\$1", -$type_func, "\$1", -$type_struct, "\$1", -$type_env, "\$1", -$type_param, "\$1" ); +my @highlights_gnome = ( +[$type_constant, "\$1"], +[$type_func, "\$1"], +[$type_struct, "\$1"], +[$type_env, "\$1"], +[$type_param, "\$1" ] + ); my $blankline_gnome = "\n"; # these are pretty rough -my %highlights_man = ( $type_constant, "\$1", - $type_func, "fB\$1fP", - $type_struct, "fI\$1fP", - $type_param, "fI\$1fP" ); +my @highlights_man = ( + [$type_constant, "\$1"], + [$type_func, "fB\$1fP"], + [$type_struct, "fI\$1fP"], + [$type_param, "fI\$1fP"] +); my $blankline_man = ""; # text-mode -my %highlights_text = ( $type_constant, "\$1", - $type_func, "\$1", - $type_struct, "\$1", - $type_param, "\$1" ); +my @highlights_text = ( + [$type_constant, "\$1"], + [$type_func, "\$1"], + [$type_struct, "\$1"], + [$type_param, "\$1"] + ); my $blankline_text = ""; # list mode -my %highlights_list = ( $type_constant, "\$1", - $type_func, "\$1", - $type_struct, "\$1", - $type_param, "\$1" ); +my @highlights_list = ( + [$type_constant, "\$1"], + [$type_func, "\$1"], + [$type_struct, "\$1"], + [$typ
[PATCH 2/6] scripts/kernel-doc: Adding infrastructure for markdown support
Markdown support is given by calling an external tool, pandoc, for all
highlighted text on kernel-doc.
Pandoc converts Markdown text to proper Docbook tags, which will be
later translated to pdf, html or other targets.
This adds the capability of adding human-readle text highlight (bold,
underline, etc), bullet and numbered lists, simple tables, fixed-width
text (including asciiart), requiring minimal changes to current
documentation.
At this moment, pandoc is totally optional. Docbooks ready for markdown
should be added to the MARKDOWNREADY variable inside the Makefile. In
case the developer doesn't have pandoc installed, Make will throw a
warning and the documentation build will continue, generating
simple Documentation without the features brought by pandoc.
Signed-off-by: Danilo Cesar Lemes de Paula
Cc: Randy Dunlap
Cc: Daniel Vetter
Cc: Laurent Pinchart
Cc: Jonathan Corbet
Cc: Herbert Xu
Cc: Stephan Mueller
Cc: Michal Marek
Cc: linux-kernel at vger.kernel.org
Cc: linux-doc at vger.kernel.org
Cc: intel-gfx
Cc: dri-devel
---
Documentation/DocBook/Makefile | 25 +++-
scripts/docproc.c | 54 --
scripts/kernel-doc | 66 --
3 files changed, 119 insertions(+), 26 deletions(-)
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 93eff64..c1ff834 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -17,6 +17,8 @@ DOCBOOKS := z8530book.xml device-drivers.xml \
tracepoint.xml drm.xml media_api.xml w1.xml \
writing_musb_glue_layer.xml crypto-API.xml iio.xml
+MARKDOWNREADY :=
+
include Documentation/DocBook/media/Makefile
###
@@ -81,18 +83,23 @@ XMLTOFLAGS += --skip-validation
# The following rules are used to generate the .xml documentation
# required to generate the final targets. (ps, pdf, html).
quiet_cmd_docproc = DOCPROC $@
- cmd_docproc = SRCTREE=$(srctree)/ $(DOCPROC) doc $< >$@
+ cmd_docproc = SRCTREE=$(srctree)/ $(DOCPROC) doc $<
define rule_docproc
- set -e; \
-$(if $($(quiet)cmd_$(1)),echo ' $($(quiet)cmd_$(1))';)\
-$(cmd_$(1)); \
-( \
- echo 'cmd_$@ := $(cmd_$(1))';\
- echo $@: `SRCTREE=$(srctree) $(DOCPROC) depend $<`; \
+ set -e;
\
+ USEMARKDOWN="";
\
+ FILE=`basename $@`;
\
+ [[ "$(MARKDOWNREADY)" =~ "$${FILE}" ]] && USEMARKDOWN="-use-markdown";
\
+$(if $($(quiet)cmd_$(1)),echo ' $($(quiet)cmd_$(1))';)
\
+$(cmd_$(1)) $$USEMARKDOWN >$@;
\
+(
\
+ echo 'cmd_$@ := $(cmd_$(1))';
\
+ echo $@: `SRCTREE=$(srctree) $(DOCPROC) depend $<`;
\
) > $(dir $@).$(notdir $@).cmd
endef
%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) $(KERNELDOCXMLREF) FORCE
+ @(which pandoc > /dev/null 2>&1) || \
+ (echo "*** To get propper documentation you need to install pandoc
***";)
$(call if_changed_rule,docproc)
# Tell kbuild to always build the programs
@@ -103,6 +110,10 @@ notfoundtemplate = echo "*** You have to install
docbook-utils or xmlto ***"; \
db2xtemplate = db2TYPE -o $(dir $@) $<
xmltotemplate = xmlto TYPE $(XMLTOFLAGS) -o $(dir $@) $<
+ifneq ($(shell which pandoc >/dev/null 2>&1 && echo found),found)
+ MARKDOWNREADY := "";
+endif
+
# determine which methods are available
ifeq ($(shell which db2ps >/dev/null 2>&1 && echo found),found)
use-db2x = db2x
diff --git a/scripts/docproc.c b/scripts/docproc.c
index e267e621..7c6b225 100644
--- a/scripts/docproc.c
+++ b/scripts/docproc.c
@@ -73,12 +73,15 @@ FILELINE * docsection;
#define NOFUNCTION"-nofunction"
#define NODOCSECTIONS "-no-doc-sections"
#define SHOWNOTFOUND "-show-not-found"
+#define USEMARKDOWN "-use-markdown"
static char *srctree, *kernsrctree;
static char **all_list = NULL;
static int all_list_len = 0;
+static int use_markdown = 0;
+
static void consume_symbol(const char *sym)
{
int i;
@@ -95,10 +98,11 @@ static void consume_symbol(const char *sym)
static void usage (void)
{
- fprintf(stderr, "Usage: docproc {doc|depend} file\n");
+ fprintf(stderr, "Usage: docproc {doc|depend} [-use-markdown] file\n");
fprintf(stderr, "Input is read from file.tmpl. Output is sent to
stdout\n");
fprintf(stderr, "doc: frontend when generating kernel documentatio
[PATCH 3/6] drm/doc: Convert to markdown
DRM Docbook is now Markdown ready. This means its doc is able to use markdown text on it. * Documentation/DocBook/drm.tmpl: Contains a table duplicated from drivers/gpu/drm/i915/i915_reg.h. This is not needed anymore * drivers/gpu/drm/drm_modeset_lock.c: had a code example that used to look pretty bad on html. Fixed by using proper code markup. * drivers/gpu/drm/drm_prime.c: Remove spaces between lines to make a proper markup list. * drivers/gpu/drm/i915/i915_reg.h: Altought pandoc supports tables, it doesn't support table cell spanning. But we can use fixed-width for those special cases. * include/drm/drm_vma_manager.h: Another code example that should be proper indented with four spaces. Signed-off-by: Danilo Cesar Lemes de Paula Cc: Randy Dunlap Cc: Daniel Vetter Cc: Laurent Pinchart Cc: Jonathan Corbet Cc: Herbert Xu Cc: Stephan Mueller Cc: Michal Marek Cc: linux-kernel at vger.kernel.org Cc: linux-doc at vger.kernel.org Cc: intel-gfx Cc: dri-devel --- Documentation/DocBook/Makefile | 2 +- Documentation/DocBook/drm.tmpl | 86 -- drivers/gpu/drm/drm_modes.c| 12 +++--- drivers/gpu/drm/drm_modeset_lock.c | 14 +++ drivers/gpu/drm/drm_prime.c| 16 +++ drivers/gpu/drm/i915/i915_reg.h| 48 ++--- include/drm/drm_vma_manager.h | 10 ++--- 7 files changed, 48 insertions(+), 140 deletions(-) diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index c1ff834..75b7d9b 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -17,7 +17,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \ tracepoint.xml drm.xml media_api.xml w1.xml \ writing_musb_glue_layer.xml crypto-API.xml iio.xml -MARKDOWNREADY := +MARKDOWNREADY := drm.xml include Documentation/DocBook/media/Makefile diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 9ddf8c6..4111902 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -4076,92 +4076,6 @@ int num_ioctls; DPIO !Pdrivers/gpu/drm/i915/i915_reg.h DPIO - - Dual channel PHY (VLV/CHV/BXT) - - - - - - - - - - - - - - - - - - CH0 - CH1 - - - - - CMN/PLL/REF - CMN/PLL/REF - - - PCS01 - PCS23 - PCS01 - PCS23 - - - TX0 - TX1 - TX2 - TX3 - TX0 - TX1 - TX2 - TX3 - - - DDI0 - DDI1 - - - - - - Single channel PHY (CHV/BXT) - - - - - - - - - - - CH0 - - - - - CMN/PLL/REF - - - PCS01 - PCS23 - - - TX0 - TX1 - TX2 - TX3 - - - DDI2 - - - - diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index cd74a09..9480464 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -553,10 +553,10 @@ EXPORT_SYMBOL(drm_gtf_mode_complex); * drivers/video/fbmon.c * * Standard GTF parameters: - * M = 600 - * C = 40 - * K = 128 - * J = 20 + * M = 600 + * C = 40 + * K = 128 + * J = 20 * * Returns: * The modeline based on the GTF algorithm stored in a drm_display_mode object. @@ -1212,7 +1212,7 @@ EXPORT_SYMBOL(drm_mode_connector_list_update); * This uses the same parameters as the fb modedb.c, except for an extra * force-enable, force-enable-digital and force-disable bit at the end: * - * x[M][R][-][@][i][m][eDd] + * x[M][R][-][@][i][m][eDd] * * The intermediate drm_cmdline_mode structure is required to store additional * options from the command line modline like the force-enable/disable flag. @@ -1491,4 +1491,4 @@ int drm_mode_convert_umode(struct drm_display_mode *out, out: return ret; -} \ No newline at end of file +} diff --git a/drivers/gpu/drm/drm_modeset_lock.c b/drivers/gpu/drm/drm_modeset_lock.c index fba321c..9abee87 100644 --- a/drivers/gpu/drm/drm_modeset_lock.c +++ b/drivers/gpu/drm/drm_modeset_lock.c @@ -40,17 +40,15 @@ * The basic usage pattern is to: * * drm_modeset_acquire_init(&ctx) - * retry: + *
[PATCH 4/6] drm/doc: Fixing xml documentation warning
"/**" should be used for kernel-doc documentation only.
It causes a warning with the new "in struct body" format.
Signed-off-by: Danilo Cesar Lemes de Paula
Cc: Randy Dunlap
Cc: Daniel Vetter
Cc: Laurent Pinchart
Cc: Jonathan Corbet
Cc: Herbert Xu
Cc: Stephan Mueller
Cc: Michal Marek
Cc: linux-kernel at vger.kernel.org
Cc: linux-doc at vger.kernel.org
Cc: intel-gfx
Cc: dri-devel
Cc: Graham Whaley
---
include/drm/drm_modeset_lock.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/drm/drm_modeset_lock.h b/include/drm/drm_modeset_lock.h
index 5dd18bf..94938d8 100644
--- a/include/drm/drm_modeset_lock.h
+++ b/include/drm/drm_modeset_lock.h
@@ -43,19 +43,19 @@ struct drm_modeset_acquire_ctx {
struct ww_acquire_ctx ww_ctx;
- /**
+ /*
* Contended lock: if a lock is contended you should only call
* drm_modeset_backoff() which drops locks and slow-locks the
* contended lock.
*/
struct drm_modeset_lock *contended;
- /**
+ /*
* list of held locks (drm_modeset_lock)
*/
struct list_head locked;
- /**
+ /*
* Trylock mode, use only for panic handlers!
*/
bool trylock_only;
@@ -70,12 +70,12 @@ struct drm_modeset_acquire_ctx {
* Used for locking CRTCs and other modeset resources.
*/
struct drm_modeset_lock {
- /**
+ /*
* modeset lock
*/
struct ww_mutex mutex;
- /**
+ /*
* Resources that are locked as part of an atomic update are added
* to a list (so we know what to unlock at the end).
*/
--
2.4.3
[PATCH 5/6] scripts/kernel-doc: Improve Markdown results
Using pandoc as the Markdown engine cause some minor side effects as
pandoc includes main tags for almost everything.
Original Markdown support approach removes those main tags, but it caused
some inconsistencies when that tag is not the main one, like:
..
...
As kernel-doc was already including a tag, it causes the presence
of double tags (), which is not supported by DocBook
spec.
Html target gets away with it, so it causes no harm, although other
targets might not be so lucky (pdf as example).
We're now delegating the inclusion of the main tag to pandoc
only, as it knows when it's necessary or not.
That behavior causes a corner case, the only situation where we're
certainly that is not needed, which is the content.
For those cases, we're using a $output_markdown_nopara = 1 control var.
Signed-off-by: Danilo Cesar Lemes de Paula
Cc: Randy Dunlap
Cc: Daniel Vetter
Cc: Laurent Pinchart
Cc: Jonathan Corbet
Cc: Herbert Xu
Cc: Stephan Mueller
Cc: Michal Marek
Cc: linux-kernel at vger.kernel.org
Cc: linux-doc at vger.kernel.org
Cc: intel-gfx
Cc: dri-devel
Cc: Graham Whaley
---
scripts/kernel-doc | 48 ++--
1 file changed, 34 insertions(+), 14 deletions(-)
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 5fe572a..d6129e7 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -288,6 +288,7 @@ my $use_markdown = 0;
my $verbose = 0;
my $output_mode = "man";
my $output_preformatted = 0;
+my $output_markdown_nopara = 0;
my $no_doc_sections = 0;
my @highlights = @highlights_man;
my $blankline = $blankline_man;
@@ -538,8 +539,11 @@ sub markdown_to_docbook {
close(CHLD_OUT);
close(CHLD_ERR);
- # pandoc insists in adding Main , we should remove them.
- $content =~ s:\A\s*\s*\n(.*)\n\Z$:$1:egsm;
+ if ($output_markdown_nopara) {
+ # pandoc insists in adding Main , sometimes we
+ # want to remove them.
+ $content =~ s:\A\s*\s*\n(.*)\n\Z$:$1:egsm;
+ }
return $content;
}
@@ -614,7 +618,7 @@ sub output_highlight {
$line =~ s/^\s*//;
}
if ($line eq ""){
- if (! $output_preformatted) {
+ if (! $output_preformatted && ! $use_markdown) {
print $lineprefix, local_unescape($blankline);
}
} else {
@@ -1035,7 +1039,7 @@ sub output_section_xml(%) {
# programlisting is already included by pandoc
print "\n" unless $use_markdown;
$output_preformatted = 1;
- } else {
+ } elsif (! $use_markdown) {
print "\n";
}
output_highlight($args{'sections'}{$section});
@@ -1043,7 +1047,7 @@ sub output_section_xml(%) {
if ($section =~ m/EXAMPLE/i) {
print "\n" unless $use_markdown;
print "\n";
- } else {
+ } elsif (! $use_markdown) {
print "\n";
}
print "\n";
@@ -1075,7 +1079,9 @@ sub output_function_xml(%) {
print " " . $args{'function'} . "\n";
print " \n";
print " ";
+$output_markdown_nopara = 1;
output_highlight ($args{'purpose'});
+$output_markdown_nopara = 0;
print " \n";
print "\n";
@@ -1113,10 +1119,12 @@ sub output_function_xml(%) {
$parameter_name =~ s/\[.*//;
print " \n
$parameter\n";
- print " \n\n";
+ print " \n";
+ print "\n" unless $use_markdown;
$lineprefix=" ";
output_highlight($args{'parameterdescs'}{$parameter_name});
- print "\n \n \n";
+ print "\n" unless $use_markdown;
+ print " \n \n";
}
print " \n";
} else {
@@ -1152,7 +1160,9 @@ sub output_struct_xml(%) {
print " " . $args{'type'} . " " . $args{'struct'} .
"\n";
print " \n";
print " ";
+$output_markdown_nopara = 1;
output_highlight ($args{'purpose'});
+$output_markdown_nopara = 0;
print " \n";
print "\n";
@@ -1205,9 +1215,11 @@ sub output_struct_xml(%) {
($args{'parameterdescs'}{$parameter_name} ne $undescribed) || next;
print "";
print " $parameter\n";
- print " \n";
+ print " \n";
+ print " \n" unless $use_markdown;
output_highlight($args{'parameterdescs'}{$parameter_name});
- print " \n";
+ print " \n" unless $use_markdown;
+ print " \n";
print "\n";
}
print " \n";
@@ -1246,7 +1258,9 @@ sub output_enum_xml(%) {
print " enum " . $args{'enum'} . "\n";
print " \n";
print " ";
+$output_markdown_nopara = 1;
output_highlight ($args{'purpose'});
+$output_markdown_nopara = 0;
print " \n";
print "\n";
@@ -1276,9 +1290,11 @@ sub output_enum_xml(%) {
print "";
print " $parameter\n";
- print " \n";
+ print " \n";
+ print "
[PATCH 6/6] scripts/kernel-doc: Processing -nofunc for functions only
Docproc process EXPORT_SYMBOL(f1) macro and uses -nofunc f1 to
avoid duplicated documentation in the next call.
It works for most of the cases, but there are some specific situations
where a struct has the same name of an already-exported function.
Current kernel-doc behavior ignores those structs and do not add them
to the final documentation. This patch fixes it.
This is non-usual and the only case I've found is the drm_modeset_lock
(function and struct) defined in drm_modeset_lock.h and
drm_modeset_lock.c. Considering this, it should only affect the DRM
documentation by including struct drm_modeset_lock to the final Docbook.
Signed-off-by: Danilo Cesar Lemes de Paula
Cc: Daniel Vetter
Cc: Jonathan Corbet
Cc: Andrew Morton
Cc: Johannes Berg
Cc: linux-kernel at vger.kernel.org
Cc: linux-doc at vger.kernel.org
Cc: intel-gfx
Cc: dri-devel
---
scripts/kernel-doc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index d6129e7..a01b20ea 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -1836,7 +1836,7 @@ sub output_declaration {
my $func = "output_${functype}_$output_mode";
if (($function_only==0) ||
( $function_only == 1 && defined($function_table{$name})) ||
- ( $function_only == 2 && !defined($function_table{$name})))
+ ( $function_only == 2 && !($functype eq "function" &&
defined($function_table{$name}
{
&$func(@_);
$section_counter++;
--
2.4.3
[PATCH] scripts/kernel-doc: Improve Markdown results
On 09/04/2015 05:39 PM, Jonathan Corbet wrote: > On Fri, 4 Sep 2015 14:53:34 -0300 > Danilo Cesar Lemes de Paula wrote: > >> In the last few days I sent three features: >> Markdown support (patch series 1) >> Cross-reference hyperlink support (patch series 1) >> in-struct-body documentation (series 2) >> >> I assume you want a new patch series for the series 1, containing the >> feature itself and the fixes that I sent later, correct? > > The cross-reference patch was merged, so there's no need to send that > again. Anything else that isn't in mainline now should be resent as a > new series. I did send a new set, named "[PATCH 0/6] scripts/kernel-doc: Kernel-doc improvements" I did include all the patches I didn't find in mainline. Is it enough? Thanks, Danilo
[Bug 91896] AMDGPU Fiji: only getting 1080i on DP
https://bugs.freedesktop.org/show_bug.cgi?id=91896 Ernst Sjöstrand changed: What|Removed |Added Component|Driver/AMDgpu |DRM/AMDgpu Version|git |DRI git Assignee|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop ||.org Product|xorg|DRI QA Contact|xorg-team at lists.x.org | -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150907/3f4fc3fc/attachment.html>
[PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed
On Sun, Sep 06, 2015 at 11:59:08AM +0800, Yakir Yang wrote: > Hi Thierry, > > å¨ 09/03/2015 05:04 PM, Thierry Reding åé: > >On Thu, Sep 03, 2015 at 12:27:47PM +0800, Yakir Yang wrote: > >>Hi Rob, > >> > >>å¨ 09/03/2015 04:17 AM, Rob Herring åé: > >>>On Tue, Sep 1, 2015 at 1:14 AM, Yakir Yang wrote: > >>>>Some edp screen do not have hpd signal, so we can't just return > >>>>failed when hpd plug in detect failed. > >>>This is a property of the panel (or connector perhaps), so this > >>>property should be located there. At least, it is a common issue and > >>>not specific to this chip. We could have an HDMI connector and failed > >>>to hook up HPD for example. A connector node is also where hpd-gpios > >>>should be located instead (and are already defined by > >>>../bindings/video/hdmi-connector.txt). Perhaps we need a eDP connector > >>>binding, too. > >>Yep, I agree with your front point, it is a property of panel, not specific > >>to eDP controller, so this code should handle in connector logic. > > From your description it sounds more like this is in fact a property of > >the panel. Or maybe I should say "quirk". If the panel doesn't generate > >the HPD signal, then that should be a property of the panel, not the > >connector. The eDP specification mandates that connectors have a HPD > >signal, though it allows the "HPD conductor in the connector cable" to > >be omitted if not used by the source. I'd consider the cable to belong > >to the panel rather than the connector, so absence of HPD, either > >because the cable doesn't have the conductor or because the panel does > >not generate the signal, should be a quirk of the panel. > > > >That said you could have a panel that supports HPD connected via a cable > >that doesn't transmit it, so this would be a per-board variant and hence > >should be a device tree property rather than hard-coded in some panel > >driver. > > > >Conversely, if the panel isn't capable of generating an HPD signal, then > >I don't think it would be appropriate to make it a DT property. It would > >be better to hard-code it in the driver, lest someone forget to set the > >property in DT and get stuck with a device that isn't operational. > > Oh, you're right, if it's a cable quirk, then DT property would be okay, if > it > is a problem of panel, then maybe hard-code in driver would be better. > > After look up for the document of panel "innolux,n116bge", I haven't see > any description of hot plug signal, and even not found in PIN ASSIGNMENT. > So I believe it's a panel problem, that's to say it should handle in panel > driver. The datasheet that I have for that panel lists HPD as pin 17. Also I used to have a setup with that panel and I distinctly remember hotplug working just fine. Perhaps this is an issue with a specific variant of the panel? Or perhaps this is indeed a problem with the cable that's connecting the panel to the board. It could be one of those cases where they left out the HPD conductor to save money. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150907/b3e2ffa1/attachment-0001.sig>
[PATCH v4 03/16] drm: bridge: analogix/dp: split exynos dp driver to bridge dir
Hi Krzysztof,
å¨ 09/07/2015 08:22 AM, Krzysztof Kozlowski åé:
> On 06.09.2015 16:49, Yakir Yang wrote:
>> Hi Krzysztof,
>>
>> å¨ 09/04/2015 08:41 AM, Krzysztof Kozlowski åé:
>>> On 03.09.2015 14:30, Yakir Yang wrote:
Hi Krzysztof,
å¨ 09/03/2015 08:58 AM, Krzysztof Kozlowski åé:
> On 01.09.2015 14:49, Yakir Yang wrote:
>> Split the dp core driver from exynos directory to bridge
>> directory, and rename the core driver to analogix_dp_*,
>> leave the platform code to analogix_dp-exynos.
>>
>> Signed-off-by: Yakir Yang
>> ---
>> Changes in v4:
>> - Take Rob suggest, update "analogix,hpd-gpios" to "hpd-gpios" DT
>> propery.
>> - Take Jingoo suggest, rename "analogix_dp-exynos.c" file name to
>> "exynos_dp.c"
>> - Take Archit suggest, create a separate folder for analogix code in
>> bridge/
>>
>> Changes in v3:
>> - Take Thierry Reding suggest, move exynos's video_timing code
>> to analogix_dp-exynos platform driver, add get_modes method
>> to struct analogix_dp_plat_data.
>> - Take Heiko suggest, rename some "samsung*" dts propery to
>> "analogix*".
>>
>> Changes in v2:
>> - Take Jingoo Han suggest, remove new copyright
>> - Fix compiled failed dut to analogix_dp_device misspell
>> [.]
>>
>> -static int exynos_dp_bridge_attach(struct drm_bridge *bridge)
>> +static int analogix_dp_bridge_attach(struct drm_bridge *bridge)
>> {
>> -struct exynos_dp_device *dp = bridge->driver_private;
>> -struct drm_encoder *encoder = &dp->encoder;
>> +struct analogix_dp_device *dp = bridge->driver_private;
>> +struct drm_encoder *encoder = dp->encoder;
>> struct drm_connector *connector = &dp->connector;
>> int ret;
>> -/* Pre-empt DP connector creation if there's a bridge */
>> -if (dp->ptn_bridge) {
>> -ret = exynos_drm_attach_lcd_bridge(dp, encoder);
>> -if (!ret)
>> -return 0;
>> +if (!bridge->encoder) {
>> +DRM_ERROR("Parent encoder object not found");
>> +return -ENODEV;
>> }
>> +encoder->bridge = bridge;
>> +
>> connector->polled = DRM_CONNECTOR_POLL_HPD;
>> ret = drm_connector_init(dp->drm_dev, connector,
>> - &exynos_dp_connector_funcs,
>> + &analogix_dp_connector_funcs,
>> DRM_MODE_CONNECTOR_eDP);
>> if (ret) {
>> DRM_ERROR("Failed to initialize connector with drm\n");
>> return ret;
>> }
>> -drm_connector_helper_add(connector,
>> &exynos_dp_connector_helper_funcs);
>> +drm_connector_helper_add(connector,
>> + &analogix_dp_connector_helper_funcs);
>> drm_connector_register(connector);
>> drm_mode_connector_attach_encoder(connector, encoder);
>> -if (dp->panel)
>> -ret = drm_panel_attach(dp->panel, &dp->connector);
>> +if (dp->plat_data && dp->plat_data->panel) {
>> +ret = drm_panel_attach(dp->plat_data->panel, &dp->connector);
>> +if (ret) {
>> +DRM_ERROR("Failed to attach panel\n");
>> +return ret;
>> +}
>> +}
>> +
>> +/*
>> + * This should be the end of attach function, caused
>> + * we should ensure dp bridge could attach first.
>> + */
>> + if (dp->plat_data && dp->plat_data->attach) {
>> + ret = dp->plat_data->attach(dp->plat_data, bridge);
>> + if (ret) {
>> + DRM_ERROR("Failed at platform attch func\n");
> Two new error paths appeared here and above. Don't you have to
> cleanup something? I don't know, just wondering...
Hmm... I think both panel & platform_attch need ERROR remind when
it failed. But if it still need clean, I though it should clean the
platform attch
error,
this is not relate to DRM directly, just analogix driver logic, so
code would like,
-if (dp->panel)
-ret = drm_panel_attach(dp->panel, &dp->connector);
+if (dp->plat_data && dp->plat_data->panel) {
+ret = drm_panel_attach(dp->plat_data->panel, &dp->connector);
+if (ret) {
+DRM_ERROR("Failed to attach panel\n");
+return ret;
+}
+}
+/*
+ * This should be the end of attach function, caused
+ * we should ensure dp bridge could attach first.
+ */
+ if (dp->plat_data && dp->plat_data->attach) {
+ ret = dp->plat_data->attach(dp->plat_data, bridge);
return ret;
>>> I am lost... the code looks the same. What did you change?
>> I just remove the DRM_ERROR after dp->plat_data->attach(),
>
[PATCH v4 03/16] drm: bridge: analogix/dp: split exynos dp driver to bridge dir
On Fri, Sep 04, 2015 at 11:29:30PM +0200, Heiko Stuebner wrote:
> Am Freitag, 4. September 2015, 16:06:02 schrieb Rob Herring:
> > On Tue, Sep 1, 2015 at 3:46 PM, Heiko Stuebner wrote:
> > > Am Dienstag, 1. September 2015, 13:49:58 schrieb Yakir Yang:
> > >> Split the dp core driver from exynos directory to bridge
> > >> directory, and rename the core driver to analogix_dp_*,
> > >> leave the platform code to analogix_dp-exynos.
> > >>
> > >> Signed-off-by: Yakir Yang
> > >
> > > [...]
> > >
> > >> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
> > >> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c similarity index 50%
> > >> rename from drivers/gpu/drm/exynos/exynos_dp_core.c
> > >> rename to drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > >> index bed0252..7d62f22 100644
> > >> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> > >> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > >
> > > [...]
> > >
> > >> connector->polled = DRM_CONNECTOR_POLL_HPD;
> > >>
> > >> ret = drm_connector_init(dp->drm_dev, connector,
> > >>
> > >> - &exynos_dp_connector_funcs,
> > >> + &analogix_dp_connector_funcs,
> > >>
> > >>DRM_MODE_CONNECTOR_eDP);
> > >>
> > >> if (ret) {
> > >>
> > >> DRM_ERROR("Failed to initialize connector with drm\n");
> > >> return ret;
> > >>
> > >> }
> > >>
> > >> - drm_connector_helper_add(connector,
> > >> &exynos_dp_connector_helper_funcs); +
> > >> drm_connector_helper_add(connector,
> > >> + &analogix_dp_connector_helper_funcs);
> > >>
> > >> drm_connector_register(connector);
> > >
> > > this should only run on exynos, as we're doing all our connector
> > > registration in the core driver after all components are bound, so I
> > > guess something like>
> > > the following is needed:
> > >if (dp->plat_data && dp->plat_data->dev_type == EXYNOS_DP)
> > >
> > >drm_connector_register(connector);
> >
> > Yuck!
> >
> > Surely there is a better way. From what I've seen of DRM, I have no
> > doubt this is needed, but really a better solution is needed. Surely
> > there can be a more generic way for the driver to determine if it
> > should handle the connector or not. This seems like a common problem
> > including one I have seen. What I'm working on has onchip DSI encoder
> > -> ADV7533 -> HDMI. The DSI encoder can also have a direct attached
> > panel. So I have to check for a bridge in the encoder driver and only
> > register the connector for the panel if a bridge is not attached.
>
> I'm also only a part-time drm meddler, so things may be inaccurate.
>
> This conditional is not meant to prevent the registration of the dp
> connector,
> only delay it for non-exynos drms. The connector registration does publish it
> to userspace, so like i.MX we're doing that for all connectors at the same
> time after all components are bound - to also make x11 happy. Exynos on the
> other hand seems to register its connectors individually and I'm not sure if
> they would be willing to change that.
>
> see d3007dabeff4 ("drm/rockchip: register all connectors after bind") or
> simply rockchip_drm_drv.c line 178.
>
> and e355e7dd607b ("imx-drm: delay publishing sysfs connector entries")
There really shouldn't be a reason for both drivers to behave
differently in this case. Gustavo has done a lot of work on cleaning up
the Exynos driver lately, so perhaps you should sync up with him to see
if this is something that he can integrate with his changes.
If you can't reach an agreement and Exynos must keep the exact behaviour
as it has now, then perhaps a better option would be to have the
Analogix core driver not register the connector but rather leave that up
to users of the helpers. Then you don't have to clutter the core driver
with this type of platform-specific data.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150907/096f8638/attachment-0001.sig>
[PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed
On Sun, Sep 06, 2015 at 04:20:39PM +0800, Yakir Yang wrote: > Hi Rob, > > å¨ 09/05/2015 05:46 AM, Rob Herring åé: > >On Wed, Sep 2, 2015 at 11:27 PM, Yakir Yang wrote: > >>Hi Rob, > >> > >>å¨ 09/03/2015 04:17 AM, Rob Herring åé: > >>>On Tue, Sep 1, 2015 at 1:14 AM, Yakir Yang wrote: > >>>>Some edp screen do not have hpd signal, so we can't just return > >>>>failed when hpd plug in detect failed. > >>>This is a property of the panel (or connector perhaps), so this > >>>property should be located there. At least, it is a common issue and > >>>not specific to this chip. We could have an HDMI connector and failed > >>>to hook up HPD for example. A connector node is also where hpd-gpios > >>>should be located instead (and are already defined by > >>>../bindings/video/hdmi-connector.txt). Perhaps we need a eDP connector > >>>binding, too. > >> > >>Yep, I agree with your front point, it is a property of panel, not specific > >>to eDP controller, so this code should handle in connector logic. > >> > >>But another question, if we just leave this property to connector, > >>then we would need to parse this property in analogix_dp-rockchip.c, > >>and then make an hook in analogix_dp_core.c driver. This is not nice, > >>and if there are some coming platform which alse want to use analogix_dp > >>code and meet this "no-hpd" situation, then they would need duplicate > >>to parse this property and fill the hook in analogix_dp_core.c driver. > >>So it's little bit conflict :-) > >Ideally, you would be able to just retrieve this quirk from the > >connector or panel. Getting this property from your node vs. the port > >you are attached to should not be much harder. Either the connector > >struct can have this info or there can be a DT function that can walk > >the graph and get it. Just don't open code the graph traversal in your > >driver. > > > >>Beside I can not understand your example very well. Do you mean > >>that there are some HDMI monitor which also do not have HPD > >>signal (just like some eDP panel do not have hpd too), and then > >>the "hpd-gpios" ? Hmm... I don't know how the "hpd-gpios" want > >>to help in this case, would you mind show some sample code :-D > >I don't know that there is h/w, but it is always possible HPD is not > >hooked up or hooked up incorrectly some how. > > > >If there is no HPD support, then hpd-gpios is not going to help you. > > > >I think there are 3 cases to handle: > >- HPD handled by bridge chip - The bridge driver knows it has this > >capability. No DT properties are needed and no HPD properties on the > >connector node imply the bridge chip should handle HPD functions. > >- HPD handled by GPIO line (or some other block) - Indicated by > >hpd-gpios present > >- No or broken HPD - Indicated by "hpd-force" property. > > Oh, I think the first/second case isn't suitable in this case, my panel > "cnm,n116bgeea2" haven't included HPD signal. Note that if your panel doesn't signal HPD you're supposed to poll the sink to make sure you catch loss of link integrity. I've always found it odd that people would want to save a couple of bucks on the HPD signal conductor when that means that you will consume more power because you need to periodically poll the link for integrity. > >>>Are there any eDP panels which don't have EDID and need panel details in > >>>DT? > >> > >>Oh, I think you want to collect some info that belong to panel > >>property but no indicate in panel EDID message, so those can > >>be collect in eDP connector binding, is it right ? > >Yes, and as Thierry pointed out we may need to know the exact panel even. > > Yeah, just like I reply to Thierry, this is a panel quirk. And he suggest we > should > handle this in panel driver, but I have no idea how to handle this in common > panel > driver. :) Like I said in another subthread, this panel does have an HPD line in a variant that I've used in the past. So if your variant doesn't have the HPD line, we're dealing with quirks within the same family of panels. That would make this some sort of quirk, and I'm not sure if there is a standard way for defining quirks in DT. Rob, do you know of any precedent for this? I suppose we could always add a variant-specific compatible string that would allow this quirk to be encoded in the driver, though I'm not sure if the model string in datasheets has enough detail to tell them apart. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150907/c2a060c9/attachment-0001.sig>
[PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed
On Fri, Sep 04, 2015 at 11:20:03AM +0100, Russell King - ARM Linux wrote: > On Thu, Sep 03, 2015 at 11:04:40AM +0200, Thierry Reding wrote: > > Conversely, if the panel isn't capable of generating an HPD signal, then > > I don't think it would be appropriate to make it a DT property. It would > > be better to hard-code it in the driver, lest someone forget to set the > > property in DT and get stuck with a device that isn't operational. > > There is another way to deal with this: DRM supports the idea of connector > forcing - where you can force the connector to think that it's connected > or disconnected. Yes, this could work well for RGB/LVDS or DSI connectors perhaps. For eDP there is added complexity because the HPD interrupt function is also used to signal loss of link integrity. That is, after receiving an HPD interrupt you are supposed to retrain the link (or at least check the link status to see if the interrupt cause is loss of integrity). While the eDP specification makes HPD optional, it also says that if HPD isn't available, then the source must use polling to monitor link integrity instead. DRM does provide a mechanism for that as well. You can set the connector's ->polled field to DRM_CONNECTOR_POLL_CONNECT | DRM_CONNECTOR_POLL_DISCONNECT and have the core actively poll for the connector status (i.e. call ->detect() every 100 ms). I think use of polling would be more appropriate in case of eDP. > One of the problems is that not many ARM DRM drivers implement it - maybe > it should be a requirement for code to be accepted? :) I suspect that many drivers may roll their own. In fact I'm guilty of that myself. On Tegra we have a default implementation for outputs which will default to the state of an HPD GPIO where available and fall back to "always connected" for outputs that have a panel connected. Outputs that have a separate mechanism to signal hotplug detection (such as DP) simply use a custom ->detect() implementation. The overhead of rolling one's own is almost zero and connector forcing has the disadvantage of being available via sysfs and debugfs, so the default set by drivers could be overwritten by users at runtime with no easy way back. Given the above I'm not sure enforcing connector forcing would be beneficial. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150907/30abe69e/attachment-0001.sig>
[PATCH] gpu: host1x: Fix MLOCK's debug info
28.06.2015 22:27, Dmitry Osipenko пиÑеÑ:
> MLOCK's debug info, spewed on CDMA timeout, contains meaningless MLOCK
> owner channel ID because HOST1X_SYNC_MLOCK_OWNER_CHID_F() returns shifted
> value, while unshifted should be used. Fix it by changing '_F' to '_V'.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/host1x/hw/debug_hw.c | 2 +-
> drivers/gpu/host1x/hw/hw_host1x01_sync.h | 8
> drivers/gpu/host1x/hw/hw_host1x02_sync.h | 8
> drivers/gpu/host1x/hw/hw_host1x04_sync.h | 8
> 4 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/host1x/hw/debug_hw.c
> b/drivers/gpu/host1x/hw/debug_hw.c
> index 791de93..cc3f182 100644
> --- a/drivers/gpu/host1x/hw/debug_hw.c
> +++ b/drivers/gpu/host1x/hw/debug_hw.c
> @@ -298,7 +298,7 @@ static void host1x_debug_show_mlocks(struct host1x *host,
> struct output *o)
> host1x_sync_readl(host, HOST1X_SYNC_MLOCK_OWNER(i));
> if (HOST1X_SYNC_MLOCK_OWNER_CH_OWNS_V(owner))
> host1x_debug_output(o, "%d: locked by channel %d\n",
> - i, HOST1X_SYNC_MLOCK_OWNER_CHID_F(owner));
> + i, HOST1X_SYNC_MLOCK_OWNER_CHID_V(owner));
> else if (HOST1X_SYNC_MLOCK_OWNER_CPU_OWNS_V(owner))
> host1x_debug_output(o, "%d: locked by cpu\n", i);
> else
> diff --git a/drivers/gpu/host1x/hw/hw_host1x01_sync.h
> b/drivers/gpu/host1x/hw/hw_host1x01_sync.h
> index ac704e5..31238c2 100644
> --- a/drivers/gpu/host1x/hw/hw_host1x01_sync.h
> +++ b/drivers/gpu/host1x/hw/hw_host1x01_sync.h
> @@ -131,12 +131,12 @@ static inline u32 host1x_sync_mlock_owner_r(unsigned
> int id)
> }
> #define HOST1X_SYNC_MLOCK_OWNER(id) \
> host1x_sync_mlock_owner_r(id)
> -static inline u32 host1x_sync_mlock_owner_chid_f(u32 v)
> +static inline u32 host1x_sync_mlock_owner_chid_v(u32 v)
> {
> - return (v & 0xf) << 8;
> + return (v >> 8) & 0xf;
> }
> -#define HOST1X_SYNC_MLOCK_OWNER_CHID_F(v) \
> - host1x_sync_mlock_owner_chid_f(v)
> +#define HOST1X_SYNC_MLOCK_OWNER_CHID_V(v) \
> + host1x_sync_mlock_owner_chid_v(v)
> static inline u32 host1x_sync_mlock_owner_cpu_owns_v(u32 r)
> {
> return (r >> 1) & 0x1;
> diff --git a/drivers/gpu/host1x/hw/hw_host1x02_sync.h
> b/drivers/gpu/host1x/hw/hw_host1x02_sync.h
> index 4495401..540c7b6 100644
> --- a/drivers/gpu/host1x/hw/hw_host1x02_sync.h
> +++ b/drivers/gpu/host1x/hw/hw_host1x02_sync.h
> @@ -131,12 +131,12 @@ static inline u32 host1x_sync_mlock_owner_r(unsigned
> int id)
> }
> #define HOST1X_SYNC_MLOCK_OWNER(id) \
> host1x_sync_mlock_owner_r(id)
> -static inline u32 host1x_sync_mlock_owner_chid_f(u32 v)
> +static inline u32 host1x_sync_mlock_owner_chid_v(u32 v)
> {
> - return (v & 0xf) << 8;
> + return (v >> 8) & 0xf;
> }
> -#define HOST1X_SYNC_MLOCK_OWNER_CHID_F(v) \
> - host1x_sync_mlock_owner_chid_f(v)
> +#define HOST1X_SYNC_MLOCK_OWNER_CHID_V(v) \
> + host1x_sync_mlock_owner_chid_v(v)
> static inline u32 host1x_sync_mlock_owner_cpu_owns_v(u32 r)
> {
> return (r >> 1) & 0x1;
> diff --git a/drivers/gpu/host1x/hw/hw_host1x04_sync.h
> b/drivers/gpu/host1x/hw/hw_host1x04_sync.h
> index ef2275b..3d6c8ec 100644
> --- a/drivers/gpu/host1x/hw/hw_host1x04_sync.h
> +++ b/drivers/gpu/host1x/hw/hw_host1x04_sync.h
> @@ -131,12 +131,12 @@ static inline u32 host1x_sync_mlock_owner_r(unsigned
> int id)
> }
> #define HOST1X_SYNC_MLOCK_OWNER(id) \
> host1x_sync_mlock_owner_r(id)
> -static inline u32 host1x_sync_mlock_owner_chid_f(u32 v)
> +static inline u32 host1x_sync_mlock_owner_chid_v(u32 v)
> {
> - return (v & 0xf) << 8;
> + return (v >> 8) & 0xf;
> }
> -#define HOST1X_SYNC_MLOCK_OWNER_CHID_F(v) \
> - host1x_sync_mlock_owner_chid_f(v)
> +#define HOST1X_SYNC_MLOCK_OWNER_CHID_V(v) \
> + host1x_sync_mlock_owner_chid_v(v)
> static inline u32 host1x_sync_mlock_owner_cpu_owns_v(u32 r)
> {
> return (r >> 1) & 0x1;
>
Ping Thierry
--
Dmitry
[PATCHv9 10/15] v4l2-subdev: add HDMI CEC ops
From: Hans Verkuil
Add CEC callbacks to the v4l2_subdev_video_ops. These are the low-level CEC
ops that subdevs that support CEC have to implement.
Signed-off-by: Hans Verkuil
[k.debski at samsung.com: Merged changes from CEC Updates commit by Hans
Verkuil]
Signed-off-by: Kamil Debski
---
include/media/v4l2-subdev.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index b273cf9..3adddc7 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -42,6 +42,10 @@
#defineV4L2_DEVICE_NOTIFY_EVENT_IOW('v', 2, struct
v4l2_event)
+#define V4L2_SUBDEV_CEC_TX_DONE_IOW('v', 3, u32)
+#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 +55,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 {
@@ -421,6 +426,11 @@ struct v4l2_subdev_video_ops {
const struct v4l2_mbus_config *cfg);
int (*s_rx_buffer)(struct v4l2_subdev *sd, void *buf,
unsigned int *size);
+ void (*cec_ready)(struct v4l2_subdev *sd);
+ unsigned (*cec_available_log_addrs)(struct v4l2_subdev *sd);
+ int (*cec_enable)(struct v4l2_subdev *sd, bool enable);
+ int (*cec_log_addr)(struct v4l2_subdev *sd, u8 logical_addr);
+ int (*cec_transmit)(struct v4l2_subdev *sd, u32 timeout_ms, struct
cec_msg *msg);
};
/**
--
2.1.4
[PATCHv9 15/15] cobalt: add cec support
From: Hans Verkuil
Add CEC support to the cobalt driver.
Signed-off-by: Hans Verkuil
---
drivers/media/pci/cobalt/Kconfig | 1 +
drivers/media/pci/cobalt/cobalt-driver.c | 51 --
drivers/media/pci/cobalt/cobalt-driver.h | 2 +
drivers/media/pci/cobalt/cobalt-irq.c| 3 +
drivers/media/pci/cobalt/cobalt-v4l2.c | 113 +--
5 files changed, 159 insertions(+), 11 deletions(-)
diff --git a/drivers/media/pci/cobalt/Kconfig b/drivers/media/pci/cobalt/Kconfig
index 1f88ccc..46483ee 100644
--- a/drivers/media/pci/cobalt/Kconfig
+++ b/drivers/media/pci/cobalt/Kconfig
@@ -4,6 +4,7 @@ config VIDEO_COBALT
depends on PCI_MSI && MTD_COMPLEX_MAPPINGS
depends on GPIOLIB || COMPILE_TEST
depends on SND
+ select CEC
select I2C_ALGOBIT
select VIDEO_ADV7604
select VIDEO_ADV7511
diff --git a/drivers/media/pci/cobalt/cobalt-driver.c
b/drivers/media/pci/cobalt/cobalt-driver.c
index 8fed61e..ed53781 100644
--- a/drivers/media/pci/cobalt/cobalt-driver.c
+++ b/drivers/media/pci/cobalt/cobalt-driver.c
@@ -76,6 +76,7 @@ static u8 edid[256] = {
0x0A, 0x0A, 0x0A, 0x0A, 0x00, 0x00, 0x00, 0x10,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x68,
+
0x02, 0x03, 0x1a, 0xc0, 0x48, 0xa2, 0x10, 0x04,
0x02, 0x01, 0x21, 0x14, 0x13, 0x23, 0x09, 0x07,
0x07, 0x65, 0x03, 0x0c, 0x00, 0x10, 0x00, 0xe2,
@@ -149,17 +150,58 @@ static void cobalt_notify(struct v4l2_subdev *sd,
struct cobalt *cobalt = to_cobalt(sd->v4l2_dev);
unsigned sd_nr = cobalt_get_sd_nr(sd);
struct cobalt_stream *s = &cobalt->streams[sd_nr];
- bool hotplug = arg ? *((int *)arg) : false;
- if (s->is_output)
+ switch (notification) {
+ case V4L2_SUBDEV_CEC_TX_DONE:
+ cec_transmit_done(s->cec_adap, (unsigned long)arg);
+ return;
+ case V4L2_SUBDEV_CEC_RX_MSG:
+ cec_received_msg(s->cec_adap, arg);
+ return;
+ case V4L2_SUBDEV_CEC_CONN_INPUTS:
+ cec_connected_inputs(s->cec_adap, *(u16 *)arg);
+ return;
+ default:
+ break;
+ }
+
+ if (s->is_output) {
+ switch (notification) {
+ case ADV7511_EDID_DETECT: {
+ struct adv7511_edid_detect *ed = arg;
+
+ s->cec_adap->phys_addr = ed->phys_addr;
+ if (!ed->present) {
+ cec_enable(s->cec_adap, false);
+ break;
+ }
+ cec_enable(s->cec_adap, true);
+ break;
+ }
+ case ADV7511_MONITOR_DETECT: {
+ struct adv7511_monitor_detect *md = arg;
+
+ if (!md->present) {
+ cec_enable(s->cec_adap, false);
+ break;
+ }
+ break;
+ }
+ }
return;
+ }
switch (notification) {
- case ADV76XX_HOTPLUG:
+ case ADV76XX_HOTPLUG: {
+ bool hotplug = arg ? *((int *)arg) : false;
+
cobalt_s_bit_sysctrl(cobalt,
COBALT_SYS_CTRL_HPD_TO_CONNECTOR_BIT(sd_nr), hotplug);
+ if (s->cec_adap)
+ cec_connected_inputs(s->cec_adap, hotplug);
cobalt_dbg(1, "Set hotplug for adv %d to %d\n", sd_nr, hotplug);
break;
+ }
case V4L2_DEVICE_NOTIFY_EVENT:
cobalt_dbg(1, "Format changed for adv %d\n", sd_nr);
v4l2_event_queue(&s->vdev, arg);
@@ -627,8 +669,9 @@ static int cobalt_subdevs_hsma_init(struct cobalt *cobalt)
s->sd = v4l2_i2c_new_subdev_board(&cobalt->v4l2_dev,
s->i2c_adap, &adv7842_info, NULL);
if (s->sd) {
- int err = v4l2_subdev_call(s->sd, pad, set_edid, &cobalt_edid);
+ int err;
+ err = v4l2_subdev_call(s->sd, pad, set_edid, &cobalt_edid);
if (err)
return err;
err = v4l2_subdev_call(s->sd, pad, set_fmt, NULL,
diff --git a/drivers/media/pci/cobalt/cobalt-driver.h
b/drivers/media/pci/cobalt/cobalt-driver.h
index c206df9..55a8c0d 100644
--- a/drivers/media/pci/cobalt/cobalt-driver.h
+++ b/drivers/media/pci/cobalt/cobalt-driver.h
@@ -31,6 +31,7 @@
#include
#include
+#include
#include
#include
#include
@@ -221,6 +222,7 @@ struct cobalt_stream {
struct list_head bufs;
struct i2c_adapter *i2c_adap;
struct v4l2_subdev *sd;
+ struct cec_adapter *cec_adap;
struct mutex lock;
spinlock_t irqlock;
struct v4l2_dv_timings timings;
diff --git a/drivers/media/pci/cobalt/cobalt-irq.c
b/drivers/media/p
[PATCHv9 13/15] cec: adv7511: add cec support.
From: Hans Verkuil
Add CEC support to the adv7511 driver.
Signed-off-by: Hans Verkuil
[k.debski at samsung.com: Merged changes from CEC Updates commit by Hans
Verkuil]
Signed-off-by: Kamil Debski
Signed-off-by: Hans Verkuil
---
drivers/media/i2c/adv7511.c | 359 +++-
include/media/adv7511.h | 6 +-
2 files changed, 353 insertions(+), 12 deletions(-)
diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
index e4900df..645d4ba 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;
@@ -225,7 +235,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;
@@ -240,6 +250,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);
@@ -413,16 +451,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);
@@ -433,10 +483,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->val & 0xff);
break;
+ case 1:
+ if (state->i2c_cec) {
+ adv7511_cec_write(sd, reg->reg & 0xff, reg->val & 0xff);
+ break;
+ }
+ /* fall through */
default:
v4l2_info(sd, "Register %03llx not supported\n", reg->reg);
adv7511_inv_register(sd);
@@ -524,6 +582,7 @@ static int adv7511_log_status(struct v4l2_subdev *sd)
{
struct adv7511_state *state = get_adv7511_state(sd);
s
[PATCHv9 14/15] 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 +++
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 | 37 +++
.../media/platform/s5p-cec/exynos_hdmi_cecctrl.c | 208 +++
drivers/media/platform/s5p-cec/regs-cec.h | 96 +++
drivers/media/platform/s5p-cec/s5p_cec.c | 284 +
drivers/media/platform/s5p-cec/s5p_cec.h | 76 ++
9 files changed, 747 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 at 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/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index dc75694..58346e6 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -117,6 +117,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 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 efa0295..957af5f 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -27,6 +27,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 +1,2 @@
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec.o
+s5p-cec-y += s5p_cec.o exynos_hdmi_cecctrl.o
diff --git a/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
b/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
new file mode 100644
index 000..d008695
--- /dev/null
+++ b/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
@@ -0,0 +1,37 @@
+/* drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
+ *
+ * Copyright (c) 2010, 2014 Samsung Electronics
+ * http://www.samsung.com/
+ *
+ * Header file for interface of Samsung Exynos hdmi cec hardware
+ *
+ * This program is free software;
[PATCHv9 08/15] cec.txt: add CEC framework documentation
Document the new HDMI CEC framework.
Signed-off-by: Hans Verkuil
[k.debski at samsung.com: add DocBook documentation by Hans Verkuil, with
Signed-off-by: Kamil Debski
Signed-off-by: Hans Verkuil
---
Documentation/cec.txt | 166 ++
1 file changed, 166 insertions(+)
create mode 100644 Documentation/cec.txt
diff --git a/Documentation/cec.txt b/Documentation/cec.txt
new file mode 100644
index 000..b298249
--- /dev/null
+++ b/Documentation/cec.txt
@@ -0,0 +1,166 @@
+CEC Kernel Support
+==
+
+The CEC framework provides a unified kernel interface for use with HDMI CEC
+hardware. It is designed to handle a multiple variants of hardware. Adding to
+the flexibility of the framework it enables to set which parts of the CEC
+protocol processing is handled by the hardware, by the driver and by the
+userspace application.
+
+
+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 protocol enables control of compatible devices with a single remote.
+Synchronous power on/standby, instant playback with changing the content source
+on the TV.
+
+The Kernel Interface
+
+
+CEC Adapter
+---
+
+#define CEC_LOG_ADDR_INVALID 0xff
+
+/* The maximum number of logical addresses one device can be assigned to.
+ * The CEC 2.0 spec allows for only 2 logical addresses at the moment. The
+ * Analog Devices CEC hardware supports 3. So let's go wild and go for 4. */
+#define CEC_MAX_LOG_ADDRS 4
+
+/* The "Primary Device Type" */
+#define CEC_OP_PRIM_DEVTYPE_TV 0
+#define CEC_OP_PRIM_DEVTYPE_RECORD 1
+#define CEC_OP_PRIM_DEVTYPE_TUNER 3
+#define CEC_OP_PRIM_DEVTYPE_PLAYBACK 4
+#define CEC_OP_PRIM_DEVTYPE_AUDIOSYSTEM5
+#define CEC_OP_PRIM_DEVTYPE_SWITCH 6
+#define CEC_OP_PRIM_DEVTYPE_VIDEOPROC 7
+
+/* The "All Device Types" flags (CEC 2.0) */
+#define CEC_OP_ALL_DEVTYPE_TV (1 << 7)
+#define CEC_OP_ALL_DEVTYPE_RECORD (1 << 6)
+#define CEC_OP_ALL_DEVTYPE_TUNER (1 << 5)
+#define CEC_OP_ALL_DEVTYPE_PLAYBACK(1 << 4)
+#define CEC_OP_ALL_DEVTYPE_AUDIOSYSTEM (1 << 3)
+#define CEC_OP_ALL_DEVTYPE_SWITCH (1 << 2)
+/* And if you wondering what happened to VIDEOPROC devices: those should
+ * be mapped to a SWITCH. */
+
+/* The logical address types that the CEC device wants to claim */
+#define CEC_LOG_ADDR_TYPE_TV 0
+#define CEC_LOG_ADDR_TYPE_RECORD 1
+#define CEC_LOG_ADDR_TYPE_TUNER2
+#define CEC_LOG_ADDR_TYPE_PLAYBACK 3
+#define CEC_LOG_ADDR_TYPE_AUDIOSYSTEM 4
+#define CEC_LOG_ADDR_TYPE_SPECIFIC 5
+#define CEC_LOG_ADDR_TYPE_UNREGISTERED 6
+/* Switches should use UNREGISTERED.
+ * Video processors should use SPECIFIC. */
+
+/* The CEC version */
+#define CEC_OP_CEC_VERSION_1_3A4
+#define CEC_OP_CEC_VERSION_1_4 5
+#define CEC_OP_CEC_VERSION_2_0 6
+
+struct cec_adapter {
+ /* internal fields removed */
+
+ u16 phys_addr;
+ u32 capabilities;
+ u8 version;
+ u8 num_log_addrs;
+ u8 prim_device[CEC_MAX_LOG_ADDRS];
+ u8 log_addr_type[CEC_MAX_LOG_ADDRS];
+ u8 log_addr[CEC_MAX_LOG_ADDRS];
+
+ int (*adap_enable)(struct cec_adapter *adap, bool enable);
+ int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr);
+ int (*adap_transmit)(struct cec_adapter *adap, struct cec_msg *msg);
+ void (*adap_transmit_timed_out)(struct cec_adapter *adap);
+
+ void (*claimed_log_addr)(struct cec_adapter *adap, u8 idx);
+ int (*received)(struct cec_adapter *adap, struct cec_msg *msg);
+};
+
+int cec_create_adapter(struct cec_adapter *adap, u32 caps);
+void cec_delete_adapter(struct cec_adapter *adap);
+int cec_transmit_msg(struct cec_adapter *adap, struct cec_data *data, bool
block);
+
+/* Called by the adapter */
+void cec_transmit_done(struct cec_adapter *adap, u32 status);
+void cec_received_msg(struct cec_adapter *adap, struct cec_msg *msg);
+
+int cec_receive_msg(struct cec_adapter *adap, struct cec_msg *msg, bool block);
+int cec_claim_log_addrs(struct cec_adapter *adap, struct cec_log_addrs
*log_addrs, bool block);
+
+The device type defines are defined by the CEC standard.
+
+The cec_adapter structure represents the adapter. It has a number of
+operations that have to be implemented in the driver: adap_enable() enables
+or disables the physical adapter, adap_log_addr() tells the driver which
+logical address should be configured. This may be called multiple times
+to configure multiple logical addresses. Calling adap_ena
[PATCHv9 12/15] cec: adv7842: add cec support
From: Hans Verkuil
Add CEC support to the adv7842 driver.
Signed-off-by: Hans Verkuil
---
drivers/media/i2c/adv7842.c | 267 +---
1 file changed, 250 insertions(+), 17 deletions(-)
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index b7269b8..b9f3e46 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,11 @@ 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;
+
+ bool cec_ready;
+ u8 cec_addr[ADV7842_MAX_ADDRS];
+ u8 cec_valid_addrs;
+ bool cec_enabled_adap;
};
/* Unsupported timings. This device cannot support 720p30. */
@@ -418,9 +426,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 +704,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 +723,15 @@ 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;
+ if (state->cec_ready) {
+ 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);
@@ -983,20 +1010,17 @@ static int adv7842_s_register(struct v4l2_subdev *sd,
static int adv7842_s_detect_tx_5v_ctrl(struct v4l2_subdev *sd)
{
struct adv7842_state *state = to_state(sd);
- int prev = v4l2_ctrl_g_ctrl(state->detect_tx_5v_ctrl);
- u8 reg_io_6f = io_read(sd, 0x6f);
- int val = 0;
+ u16 cable_det = adv7842_read_cable_det(sd);
+ u16 connected_inputs;
- if (reg_io_6f & 0x02)
- val |= 1; /* port A */
- if (reg_io_6f & 0x01)
- val |= 2; /* port B */
+ v4l2_dbg(1, debug, sd, "%s: 0x%x\n", __func__, cable_det);
- v4l2_dbg(1, debug, sd, "%s: 0x%x -> 0x%x\n", __func__, prev, val);
+ connected_inputs = state->hdmi_edid.present & cable_det;
+ if (state->cec_ready)
+ v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_CONN_INPUTS,
+ &connected_inputs);
- if (val != prev)
- return v4l2_ctrl_s_ctrl(state->detect_tx_5v_ctrl, val);
- return 0;
+ return v4l2_ctrl_s_ctrl(state->detect_tx_5v_ctrl, cable_det);
}
static int find_and_set_predefined_video_timings(struct v4l2_subdev *sd,
@@ -2157,6 +2181,194 @@ static void adv7842_irq_enable(struct v4l2_subdev *sd,
bool enable)
}
}
+static void adv7842_cec_tx_raw_status(struct v4l2_subdev *sd, u8 tx_raw_status)
+{
+ 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__);
+ v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE,
+ (void *)CEC_TX_STATUS_ARB_LOST);
+ return;
+ }
+ if (tx_raw_status & 0x04) {
+ v4l2_dbg(1, debug, sd, "%s: tx raw: retry failed\n", __func__);
+ v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE,
+ (void *)CEC_TX_STATUS_RETRY_TIMEOUT);
+ return;
[PATCHv9 06/15] 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-core.h | 1 +
include/media/rc-map.h| 5 +-
5 files changed, 181 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 t
[PATCHv9 09/15] DocBook/media: add CEC documentation
From: Hans Verkuil Add DocBook documentation for the CEC API. Signed-off-by: Hans Verkuil [k.debski at samsung.com: add documentation for passthrough mode] [k.debski at samsung.com: minor fixes and change of reserved field sizes] Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- Documentation/DocBook/media/Makefile | 2 + Documentation/DocBook/media/v4l/biblio.xml | 10 + Documentation/DocBook/media/v4l/cec-api.xml| 76 + 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 | 161 +++ .../DocBook/media/v4l/cec-ioc-adap-g-log-addrs.xml | 306 + .../DocBook/media/v4l/cec-ioc-adap-g-phys-addr.xml | 78 ++ .../DocBook/media/v4l/cec-ioc-adap-g-state.xml | 87 ++ .../DocBook/media/v4l/cec-ioc-adap-g-vendor-id.xml | 70 + Documentation/DocBook/media/v4l/cec-ioc-claim.xml | 71 + .../DocBook/media/v4l/cec-ioc-dqevent.xml | 208 ++ .../DocBook/media/v4l/cec-ioc-g-monitor.xml| 86 ++ .../DocBook/media/v4l/cec-ioc-g-passthrough.xml| 81 ++ .../DocBook/media/v4l/cec-ioc-receive.xml | 185 + Documentation/DocBook/media_api.tmpl | 8 +- 18 files changed, 1742 insertions(+), 2 deletions(-) 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-claim.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-dqevent.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-monitor.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-g-passthrough.xml create mode 100644 Documentation/DocBook/media/v4l/cec-ioc-receive.xml diff --git a/Documentation/DocBook/media/Makefile b/Documentation/DocBook/media/Makefile index 08527e7..b97fb71 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 fdee6b3..bed940b 100644 --- a/Documentation/DocBook/media/v4l/biblio.xml +++ b/Documentation/DocBook/media/v4l/biblio.xml @@ -324,6 +324,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-Definition Multimedia Interface + Specification Version 2.0 + + DP diff --git a/Documentation/DocBook/media/v4l/cec-api.xml b/Documentation/DocBook/media/v4l/cec-api.xml new file mode 100644 index 000..0e68f75 --- /dev/null +++ b/Documentation/DocBook/media/v4l/cec-api.xml @@ -0,0 +1,76 @@ + + + + Hans
[PATCHv9 07/15] cec: add HDMI CEC framework
From: Hans Verkuil
The added HDMI CEC framework provides a generic kernel interface for
HDMI CEC devices.
Signed-off-by: Hans Verkuil
[k.debski at samsung.com: Merged CEC Updates commit by Hans Verkuil]
[k.debski at samsung.com: Merged Update author commit by Hans Verkuil]
[k.debski at samsung.com: change kthread handling when setting logical
address]
[k.debski at samsung.com: code cleanup and fixes]
[k.debski at samsung.com: add missing CEC commands to match spec]
[k.debski at samsung.com: add RC framework support]
[k.debski at samsung.com: move and edit documentation]
[k.debski at samsung.com: add vendor id reporting]
[k.debski at samsung.com: add possibility to clear assigned logical
addresses]
[k.debski at samsung.com: documentation fixes, clenaup and expansion]
[k.debski at samsung.com: reorder of API structs and add reserved fields]
[k.debski at samsung.com: fix handling of events and fix 32/64bit timespec
problem]
[k.debski at samsung.com: add cec.h to include/uapi/linux/Kbuild]
[k.debski at samsung.com: add sequence number handling]
[k.debski at samsung.com: add passthrough mode]
[k.debski at samsung.com: fix CEC defines, add missing CEC 2.0 commands]
minor additions]
Signed-off-by: Kamil Debski
Signed-off-by: Hans Verkuil
---
MAINTAINERS| 12 +
drivers/media/Kconfig |6 +
drivers/media/Makefile |2 +
drivers/media/cec.c| 1921
include/media/cec.h| 175
include/uapi/linux/Kbuild |2 +
include/uapi/linux/cec-funcs.h | 1771
include/uapi/linux/cec.h | 781
8 files changed, 4670 insertions(+)
create mode 100644 drivers/media/cec.c
create mode 100644 include/media/cec.h
create mode 100644 include/uapi/linux/cec-funcs.h
create mode 100644 include/uapi/linux/cec.h
diff --git a/MAINTAINERS b/MAINTAINERS
index e0946a0..2904a66 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2553,6 +2553,18 @@ F: drivers/net/ieee802154/cc2520.c
F: include/linux/spi/cc2520.h
F: Documentation/devicetree/bindings/net/ieee802154/cc2520.txt
+CEC DRIVER
+M: Hans Verkuil
+L: linux-media at vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+W: http://linuxtv.org
+S: Supported
+F: drivers/media/cec.c
+F: drivers/media/rc/keymaps/rc-cec.c
+F: include/media/cec.h
+F: include/uapi/linux/cec.h
+F: include/uapi/linux/cec-funcs.h
+
CELL BROADBAND ENGINE ARCHITECTURE
M: Arnd Bergmann
L: linuxppc-dev at lists.ozlabs.org
diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 3ef3d6c..48e44f5 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -15,6 +15,12 @@ if MEDIA_SUPPORT
comment "Multimedia core support"
+config CEC
+ tristate "CEC API (EXPERIMENTAL)"
+ select RC_CORE
+ ---help---
+ Enable the CEC API.
+
#
# Multimedia support - automatically enable V4L2 and DVB core
#
diff --git a/drivers/media/Makefile b/drivers/media/Makefile
index e608bbc..db66014 100644
--- a/drivers/media/Makefile
+++ b/drivers/media/Makefile
@@ -2,6 +2,8 @@
# Makefile for the kernel multimedia device drivers.
#
+obj-$(CONFIG_CEC) += cec.o
+
media-objs := media-device.o media-devnode.o media-entity.o
#
diff --git a/drivers/media/cec.c b/drivers/media/cec.c
new file mode 100644
index 000..7084d2c
--- /dev/null
+++ b/drivers/media/cec.c
@@ -0,0 +1,1921 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define CEC_NUM_DEVICES256
+#define CEC_NAME "cec"
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "debug level (0-2)");
+
+#define dprintk(lvl, fmt, arg...) \
+ do {\
+ if (lvl <= debug) \
+ pr_info("cec-%s: " fmt, adap->name, ## arg);\
+ } while (0)
+
+static dev_t cec_dev_t;
+
+/* Active devices */
+static DEFINE_MUTEX(cec_devnode_lock);
+static DECLARE_BITMAP(cec_devnode_nums, CEC_NUM_DEVICES);
+
+/* dev to cec_devnode */
+#define to_cec_devnode(cd) container_of(cd, struct cec_devnode, dev)
+
+static inline struct cec_devnode *cec_devnode_data(struct file *filp)
+{
+ struct cec_fh *fh = filp->private_data;
+
+ return &fh->adap->devnode;
+}
+
+static bool cec_pa_are_adjacent(const struct cec_adapter *adap, u16 pa1, u16
pa2)
+{
+ u16 mask = 0xf000;
+ int i;
+
+ if (pa1 == CEC_PHYS_ADDR_INVALID || pa2 == CEC_PHYS_ADDR_INVALID)
+ return false;
+ for (i = 0; i < 3; i++) {
+ if ((pa1 & mask) != (pa2 & mask))
+ break;
+ mask = (mask >> 4) | 0xf000;
+ }
+ if ((pa1 & ~mask) || (pa2 & ~mask))
+ ret
[PATCHv9 03/15] dts: exynos4412-odroid*: enable the HDMI CEC device
From: Kamil Debski
Add a dts node entry and enable the HDMI CEC device present in the Exynos4
family of SoCs.
Signed-off-by: Kamil Debski
Signed-off-by: Hans Verkuil
Acked-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4210-universal_c210.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index d4f2b11..06df693 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -515,6 +515,10 @@
enable-active-high;
};
+ cec at 100B {
+ status = "okay";
+ };
+
hdmi_ddc: i2c-ddc {
compatible = "i2c-gpio";
gpios = <&gpe4 2 0 &gpe4 3 0>;
--
2.1.4
[PATCHv9 04/15] input.h: add BUS_CEC type
From: Hans Verkuil
Inputs can come in over the HDMI CEC bus, so add a new type for this.
Signed-off-by: Hans Verkuil
Acked-by: Dmitry Torokhov
---
include/uapi/linux/input.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index 731417c..a32bff1 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -972,6 +972,7 @@ struct input_keymap_entry {
#define BUS_GSC0x1A
#define BUS_ATARI 0x1B
#define BUS_SPI0x1C
+#define BUS_CEC0x1D
/*
* MT_TOOL types
--
2.1.4
[PATCHv9 05/15] 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.h | 28
1 file changed, 28 insertions(+)
diff --git a/include/uapi/linux/input.h b/include/uapi/linux/input.h
index a32bff1..5e7019a 100644
--- a/include/uapi/linux/input.h
+++ b/include/uapi/linux/input.h
@@ -752,6 +752,34 @@ struct input_keymap_entry {
#define KEY_KBDINPUTASSIST_ACCEPT 0x264
#define KEY_KBDINPUTASSIST_CANCEL 0x265
+#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.1.4
[PATCHv9 00/15] HDMI CEC framework
Hi all, The ninth version of this patchset addresses comments I received from Russell King. As far as I am concerned this version is code complete (but I said that before) and the only thing missing is that the cec.txt documentation is out-of-sync with the current implementation. So there will be a v10 fixing that. 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 Best regards, Hans Changes since v8 - Addressed the comments Russell King made about how the cec character devices should be allocated/freed. - Updated the DocBook documentation. Changes since v7 - I thought that the core thread could handle out-of-order messages, but that turned out to be wrong. After careful analysis I realized that I had to rewrite this part in cec.c in order to make it work. - Added new CEC-specific keys to input.h and use them in the CEC rc keymap. Replaced KEY_PLAY/PAUSE/STOP with KEY_PLAYCD/PAUSECD/STOPCD to clarify that these are media operations and not the Pause key on the keyboard. - Added CEC_PHYS_ADDR_INVALID (0x) - Added monitor support to monitor CEC traffic - Replaced CAP_TRANSMIT and CAP_RECEIVE by a single CAP_IO. - Replaced CAP_CDC by CAP_CDC_HPD since this only applies to the HPD part of the CDC messages. - Add CAP_IS_SOURCE. - Add ninputs field to cec_caps to export the number of inputs of the device. - Drop CEC_LOG_ADDRS_FL_HANDLE_MSGS and the flags field (see next change for more info). - Add CEC_CLAIM and CEC_RELEASE to explicitly start/stop processing CEC messages. This also implies ownership of the CEC interface, so other filehandles can only receive but not transmit. - Reworked event handling: report adapter state changes, input changes and if the message receive queue is full. - cec-funcs.h: added CDC HEC support. - Renamed G/S_ADAP ioctls to ADAP_G/S: this made it clearer which ioctls deal with the adapter configuration and which deal with CEC messages/events. - Clarified which CEC messages are passed on to userspace and which aren't. Specifically if CAP_ARC is set, then all ARC messages are handled by the kernel. If CAP_CDC_HPD is set, then all CDC hotplug messages are handled by the kernel. Otherwise these messages are passed on to userspace. Changes since v6 - added cec-funcs.h to provide wrapper functions that fill in the cec_msg struct. This header is needed both by the kernel and by applications. - fix a missing rc_unregister_device call. - added CEC support for the adv7842 and cobalt drivers. - added CEC operand defines. Rename CEC message defines to CEC_MSG_ and operand defines now use CEC_OP_. - the CEC_VERSION defines are dropped since we now have the CEC_OP_VERSION defines. - ditto: CEC_PRIM_DEVTYPE_ is now CEC_OP_PRIM_DEVTYPE. - ditto: CEC_FL_ALL_DEVTYPE_ is now CEC_OP_ALL_DEVTYPE. - cec-ioc-g-adap-log-addrs.xml: document cec_versions field. - cec-ioc-g-caps.xml: drop vendor_id and version fields. - add MAINTAINERS entry. - add CDC support (not yet fully functional). - add a second debug level for message debugging. - fix a nasty kernel Oops in cec_transmit_msg while waiting for transmit completion (adap->tx_queue[idx].func wasn't set to NULL). - add support for CEC_MSG_REPORT_FEATURES (CEC 2.0 only). - correctly abort unsupported messages. - add support for the device power status feature. - add support for the audio return channel (preliminary). - add support for the CDC hotplug message (preliminary). - added osd_name to struct cec_log_addrs. - reported physical addresses are stored internally. - fix enabling/disabling the CEC adapter (internal fields weren't cleared correctly). - zero reserved fields. - return an error if you try to receive/transmit and the adapter isn't configured. - when creating the adapter provide the owner module and the parent device. - add a CEC_VENDOR_ID_NONE define to signal if no vendor ID was set. - add new capabilities: RC (remote control), ARC (audio return channel) and CDC (Capability Discovery and Control). - applications that want to handle messages for a logical address need to set the CEC_LOG_ADDRS_FL_HANDLE_MSGS flag. Otherwise the CEC core will be the one handling all messages. - Each logical address has its own all_device_types value. So this should be an array, not a single value. - I'm sure I've forgotten some changes... Changes since v5 - drop struct cec_timeval in favour of a __u64 that keeps the timestamp in ns - remove userspace documentation from Documentation/cec.txt as userspace API is described in the DocBook - add missing documentation for the passthrough mode to the DocBook - add information about the number of events that can be queued - fix misspelling of reply - fix behaviour of posting an event in cec_received_msg, such that the behaviour is consistent with the documentation Change
[PATCHv9 01/15] 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 at 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 at 0386 {
--
2.1.4
[PATCHv9 02/15] 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 b0d52b1..0d5319e 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -719,6 +719,18 @@
status = "disabled";
};
+ hdmicec: cec at 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 at 12C1 {
compatible = "samsung,exynos4210-mixer";
interrupts = <0 91 0>;
--
2.1.4
[Intel-gfx] [PATCH] libdrm: Add framebuffer modifiers uapi
On 08/03/2015 10:48 AM, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Sync up with new kernel features as per commits:
>
> e3eb3250d84ef97b766312345774367b6a310db8
> 93b81f5102a7cd270a305c2741b17c8d44bb0629
> b5ff6e1637b683d5996ae11ac29afe406c0bee90
> 8c4f83fb1e8bf317e894f62d17a63c32b7a6b75e
> 570655b09b065d2fff1b8ab9bdb8308f4c5a05a3
Ping anyone?
Can we review and merge this uapi catchup or some existing process will
scoop it up at some point? It hasn't happened so far...
Regards,
Tvrtko
> Signed-off-by: Tvrtko Ursulin
> Cc: dri-devel at lists.freedesktop.org
> Cc: Rob Clark
> Cc: Daniel Vetter
> ---
> include/drm/drm.h| 1 +
> include/drm/drm_fourcc.h | 93
>
> include/drm/drm_mode.h | 11 +-
> 3 files changed, 104 insertions(+), 1 deletion(-)
>
> diff --git a/include/drm/drm.h b/include/drm/drm.h
> index 167b7b81b0d0..a950b580cd11 100644
> --- a/include/drm/drm.h
> +++ b/include/drm/drm.h
> @@ -816,6 +816,7 @@ struct drm_event_vblank {
> #define DRM_CAP_PRIME 0x5
> #define DRM_CAP_TIMESTAMP_MONOTONIC 0x6
> #define DRM_CAP_ASYNC_PAGE_FLIP 0x7
> +#define DRM_CAP_ADDFB2_MODIFIERS 0x10
>
> #define DRM_PRIME_CAP_IMPORT 0x1
> #define DRM_PRIME_CAP_EXPORT 0x2
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index 85facb0a17cf..63a80ca5ba39 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -127,4 +127,97 @@
> #define DRM_FORMAT_YUV444 fourcc_code('Y', 'U', '2', '4') /*
> non-subsampled Cb (1) and Cr (2) planes */
> #define DRM_FORMAT_YVU444 fourcc_code('Y', 'V', '2', '4') /*
> non-subsampled Cr (1) and Cb (2) planes */
>
> +
> +/*
> + * Format Modifiers:
> + *
> + * Format modifiers describe, typically, a re-ordering or modification
> + * of the data in a plane of an FB. This can be used to express tiled/
> + * swizzled formats, or compression, or a combination of the two.
> + *
> + * The upper 8 bits of the format modifier are a vendor-id as assigned
> + * below. The lower 56 bits are assigned as vendor sees fit.
> + */
> +
> +/* Vendor Ids: */
> +#define DRM_FORMAT_MOD_NONE 0
> +#define DRM_FORMAT_MOD_VENDOR_INTEL 0x01
> +#define DRM_FORMAT_MOD_VENDOR_AMD 0x02
> +#define DRM_FORMAT_MOD_VENDOR_NV 0x03
> +#define DRM_FORMAT_MOD_VENDOR_SAMSUNG 0x04
> +#define DRM_FORMAT_MOD_VENDOR_QCOM0x05
> +/* add more to the end as needed */
> +
> +#define fourcc_mod_code(vendor, val) \
> + u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val &
> 0x00ffULL))
> +
> +/*
> + * Format Modifier tokens:
> + *
> + * When adding a new token please document the layout with a code comment,
> + * similar to the fourcc codes above. drm_fourcc.h is considered the
> + * authoritative source for all of these.
> + */
> +
> +/* Intel framebuffer modifiers */
> +
> +/*
> + * Intel X-tiling layout
> + *
> + * This is a tiled layout using 4Kb tiles (except on gen2 where the tiles
> 2Kb)
> + * in row-major layout. Within the tile bytes are laid out row-major, with
> + * a platform-dependent stride. On top of that the memory can apply
> + * platform-depending swizzling of some higher address bits into bit6.
> + *
> + * This format is highly platforms specific and not useful for cross-driver
> + * sharing. It exists since on a given platform it does uniquely identify the
> + * layout in a simple way for i915-specific userspace.
> + */
> +#define I915_FORMAT_MOD_X_TILED fourcc_mod_code(INTEL, 1)
> +
> +/*
> + * Intel Y-tiling layout
> + *
> + * This is a tiled layout using 4Kb tiles (except on gen2 where the tiles
> 2Kb)
> + * in row-major layout. Within the tile bytes are laid out in OWORD (16
> bytes)
> + * chunks column-major, with a platform-dependent height. On top of that the
> + * memory can apply platform-depending swizzling of some higher address bits
> + * into bit6.
> + *
> + * This format is highly platforms specific and not useful for cross-driver
> + * sharing. It exists since on a given platform it does uniquely identify the
> + * layout in a simple way for i915-specific userspace.
> + */
> +#define I915_FORMAT_MOD_Y_TILED fourcc_mod_code(INTEL, 2)
> +
> +/*
> + * Intel Yf-tiling layout
> + *
> + * This is a tiled layout using 4Kb tiles in row-major layout.
> + * Within the tile pixels are laid out in 16 256 byte units / sub-tiles which
> + * are arranged in four groups (two wide, two high) with column-major layout.
> + * Each group therefore consits out of four 256 byte units, which are also
> laid
> + * out as 2x2 column-major.
> + * 256 byte units are made out of four 64 byte blocks of pixels, producing
> + * either a square block or a 2:1 unit.
> + * 64 byte blocks of pixels contain four pixel rows of 16 bytes, where the
> width
> + * in pixel depends on the pixel depth.
> + */
> +#define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
> +
> +/*
> + * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macrobl
similar files amd vs radeon
I executed a clone detection tool* on drivers source code and I found that there are similar files between drivers/gpu/drm/amd/ and drivers/gpu/drm/radeon, but also inside each of theses folders. Some examples: drivers/gpu/drm/amd/amdgpu/dce_v11_0.c,drivers/gpu/drm/amd/amdgpu/dce_v10_0.c drivers/gpu/drm/amd/amdgpu/ci_dpm.c,drivers/gpu/drm/radeon/ci_dpm.c drivers/gpu/drm/radeon/kv_dpm.c,drivers/gpu/drm/amd/amdgpu/kv_dpm.c I use meld for seeing the differences and similarities. More results from the tool at: http://pastebin.com/iX3fhifG (The number on the first field is the number of probable cloned lines of code). Should these files be consolidated? And if so how? Thank you, Peter * https://github.com/petersenna/ccfinderx-core -- Peter
[PATCH v4 0/22] On-demand device probing
On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso wrote: > Hello, > > I have a problem with the panel on my Tegra Chromebook taking longer > than expected to be ready during boot (Stéphane Marchesin reported what > is basically the same issue in [0]), and have looked into ordered > probing as a better way of solving this than moving nodes around in the > DT or playing with initcall levels and linking order. > > While reading the thread [1] that Alexander Holler started with his > series to make probing order deterministic, it occurred to me that it > should be possible to achieve the same by probing devices as they are > referenced by other devices. > > This basically reuses the information that is already implicit in the > probe() implementations, saving us from refactoring existing drivers or > adding information to DTBs. > > During review of v1 of this series Linus Walleij suggested that it > should be the device driver core to make sure that dependencies are > ready before probing a device. I gave this idea a try [2] but Mark Brown > pointed out to the logic duplication between the resource acquisition > and dependency discovery code paths (though I think it's fairly minor). > > To address that code duplication I experimented with Arnd's devm_probe > [3] concept of having drivers declare their dependencies instead of > acquiring them during probe, and while it worked [4], I don't think we > end up winning anything when compared to just probing devices on-demand > from resource getters. > > One remaining objection is to the "sprinkling" of calls to > of_device_probe() in the resource getters of each subsystem, but I think > it's the right thing to do given that the storage of resources is > currently subsystem-specific. > > We could avoid the above by moving resource storage into the core, but I > don't think there's a compelling case for that. > > I have tested this on boards with Tegra, iMX.6, Exynos, Rockchip and > OMAP SoCs, and these patches were enough to eliminate all the deferred > probes (except one in PandaBoard because omap_dma_system doesn't have a > firmware node as of yet). > > Have submitted a branch [5] with only these patches on top of thursday's > linux-next to kernelci.org and I don't see any issues that could be > caused by them. For some reason it currently has more passes than the > version of -next it's based on! > > With this series I get the kernel to output to the panel in 0.5s, > instead of 2.8s. > > Regards, > > Tomeu > > [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html > > [1] https://lkml.org/lkml/2014/5/12/452 > > [2] https://lkml.org/lkml/2015/6/17/305 > > [3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689 > > [4] https://lkml.org/lkml/2015/7/21/441a > > [5] > https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=on-demand-probes-v6 > > [6] > http://kernelci.org/boot/all/job/collabora/kernel/v4.2-11902-g25d80c927f8b/ > > [7] http://kernelci.org/boot/all/job/next/kernel/next-20150903/ > > Changes in v4: > - Added bus.pre_probe callback so the probes of Primecell devices can be > deferred if their device IDs cannot be yet read because of the clock > driver not having probed when they are registered. Maybe this goes > overboard and the matching information should be in the DT if there is > one. Seems overboard to me or at least a separate problem. Most clocks have to be setup before the driver model simply because timers depend on clocks usually. Rob
[PATCH v4 03/16] drm: bridge: analogix/dp: split exynos dp driver to bridge dir
On 06.09.2015 16:49, Yakir Yang wrote:
> Hi Krzysztof,
>
> å¨ 09/04/2015 08:41 AM, Krzysztof Kozlowski åé:
>> On 03.09.2015 14:30, Yakir Yang wrote:
>>> Hi Krzysztof,
>>>
>>> å¨ 09/03/2015 08:58 AM, Krzysztof Kozlowski åé:
On 01.09.2015 14:49, Yakir Yang wrote:
> Split the dp core driver from exynos directory to bridge
> directory, and rename the core driver to analogix_dp_*,
> leave the platform code to analogix_dp-exynos.
>
> Signed-off-by: Yakir Yang
> ---
> Changes in v4:
> - Take Rob suggest, update "analogix,hpd-gpios" to "hpd-gpios" DT
> propery.
> - Take Jingoo suggest, rename "analogix_dp-exynos.c" file name to
> "exynos_dp.c"
> - Take Archit suggest, create a separate folder for analogix code in
> bridge/
>
> Changes in v3:
> - Take Thierry Reding suggest, move exynos's video_timing code
> to analogix_dp-exynos platform driver, add get_modes method
> to struct analogix_dp_plat_data.
> - Take Heiko suggest, rename some "samsung*" dts propery to
> "analogix*".
>
> Changes in v2:
> - Take Jingoo Han suggest, remove new copyright
> - Fix compiled failed dut to analogix_dp_device misspell
>
> [.]
>
> -static int exynos_dp_bridge_attach(struct drm_bridge *bridge)
> +static int analogix_dp_bridge_attach(struct drm_bridge *bridge)
>{
> -struct exynos_dp_device *dp = bridge->driver_private;
> -struct drm_encoder *encoder = &dp->encoder;
> +struct analogix_dp_device *dp = bridge->driver_private;
> +struct drm_encoder *encoder = dp->encoder;
>struct drm_connector *connector = &dp->connector;
>int ret;
>-/* Pre-empt DP connector creation if there's a bridge */
> -if (dp->ptn_bridge) {
> -ret = exynos_drm_attach_lcd_bridge(dp, encoder);
> -if (!ret)
> -return 0;
> +if (!bridge->encoder) {
> +DRM_ERROR("Parent encoder object not found");
> +return -ENODEV;
>}
>+encoder->bridge = bridge;
> +
>connector->polled = DRM_CONNECTOR_POLL_HPD;
> ret = drm_connector_init(dp->drm_dev, connector,
> - &exynos_dp_connector_funcs,
> + &analogix_dp_connector_funcs,
> DRM_MODE_CONNECTOR_eDP);
>if (ret) {
>DRM_ERROR("Failed to initialize connector with drm\n");
>return ret;
>}
>-drm_connector_helper_add(connector,
> &exynos_dp_connector_helper_funcs);
> +drm_connector_helper_add(connector,
> + &analogix_dp_connector_helper_funcs);
>drm_connector_register(connector);
>drm_mode_connector_attach_encoder(connector, encoder);
>-if (dp->panel)
> -ret = drm_panel_attach(dp->panel, &dp->connector);
> +if (dp->plat_data && dp->plat_data->panel) {
> +ret = drm_panel_attach(dp->plat_data->panel, &dp->connector);
> +if (ret) {
> +DRM_ERROR("Failed to attach panel\n");
> +return ret;
> +}
> +}
> +
> +/*
> + * This should be the end of attach function, caused
> + * we should ensure dp bridge could attach first.
> + */
> + if (dp->plat_data && dp->plat_data->attach) {
> + ret = dp->plat_data->attach(dp->plat_data, bridge);
> + if (ret) {
> + DRM_ERROR("Failed at platform attch func\n");
Two new error paths appeared here and above. Don't you have to
cleanup something? I don't know, just wondering...
>>> Hmm... I think both panel & platform_attch need ERROR remind when
>>> it failed. But if it still need clean, I though it should clean the
>>> platform attch
>>> error,
>>> this is not relate to DRM directly, just analogix driver logic, so
>>> code would like,
>>>
>>> -if (dp->panel)
>>> -ret = drm_panel_attach(dp->panel, &dp->connector);
>>> +if (dp->plat_data && dp->plat_data->panel) {
>>> +ret = drm_panel_attach(dp->plat_data->panel, &dp->connector);
>>> +if (ret) {
>>> +DRM_ERROR("Failed to attach panel\n");
>>> +return ret;
>>> +}
>>> +}
>>>
>>> +/*
>>> + * This should be the end of attach function, caused
>>> + * we should ensure dp bridge could attach first.
>>> + */
>>> + if (dp->plat_data && dp->plat_data->attach) {
>>> + ret = dp->plat_data->attach(dp->plat_data, bridge);
>>>
>>>return ret;
>> I am lost... the code looks the same. What did you change?
>
> I just remove the DRM_ERROR after dp->plat_data->attach(),
> maybe I should paste the change that rebase on this patch,
> here are they,
>
> /*
> * This should be the end of attach function, caused
> * we should ensure dp bridge could attach f
[PATCH v4 11/16] drm: bridge: analogix/dp: add platform device type support
Hi Krzysztof,
å¨ 09/07/2015 07:55 AM, Krzysztof Kozlowski åé:
> On 06.09.2015 13:07, Yakir Yang wrote:
>> Hi Krzysztof,
>>
>> å¨ 09/04/2015 08:36 AM, Krzysztof Kozlowski åé:
>>> On 01.09.2015 15:07, Yakir Yang wrote:
>>>
>>> Empty commit message. Please explain here why you want to add platform
>>> device type support.
>>>
>>> Actually the title is confusing. You are not adding support for platform
>>> device types but rather adding a field containing type of device.
>>>
>>>
Signed-off-by: Yakir Yang
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- Add GNU license v2 declared and samsung copyright
drivers/gpu/drm/exynos/exynos_dp.c | 1 +
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 1 +
include/drm/bridge/analogix_dp.h| 16
3 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c
b/drivers/gpu/drm/exynos/exynos_dp.c
index 6060d2c..40ef727 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -224,6 +224,7 @@ static int exynos_dp_bind(struct device *dev,
struct device *master, void *data)
dp->dev = dev;
dp->drm_dev = drm_dev;
+dp->plat_data.dev_type = EXYNOS_DP;
dp->plat_data.power_on = exynos_dp_poweron;
dp->plat_data.power_off = exynos_dp_poweroff;
dp->plat_data.get_modes = exynos_dp_get_modes;
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index efea045..4934271 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -293,6 +293,7 @@ static int rockchip_dp_bind(struct device *dev,
struct device *master,
return ret;
}
+dp->plat_data.dev_type = RK3288_DP;
dp->plat_data.attach = NULL;
dp->plat_data.get_modes = NULL;
dp->plat_data.power_on = rockchip_dp_poweron;
diff --git a/include/drm/bridge/analogix_dp.h
b/include/drm/bridge/analogix_dp.h
index 8b4ffad..7209a64 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -1,9 +1,25 @@
+/*
+ * Analogix Core DP (Display Port) interface driver.
+ *
+ * Copyright (C) 2012 Samsung Electronics Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or
modify it
+ * under the terms of the GNU General Public License as published by
the
+ * Free Software Foundation; either version 2 of the License, or (at
your
+ * option) any later version.
+ */
>>> Two questions:
>>> 1. Why this change is here? I would rather expect it at patch 3/16 when
>>> you created this file... That is the usual time for adding copyrights.
>> Yep, I should move this to 03/16.
>>
>>> 2. Does this file contains previous Samsung work?
>> Hmm... I think this haven't contains the previous Samsung works,
>> but I have the cover the head message from analogix_dp_core driver
>> (include the copyright, but without ant author).
> If it does not contain Samsung's work then don't mention its copyrights.
Okay,
- Yakir
>
> Best regards,
> Krzysztof
>
>> Thanks
>> - Yakir
>>
>>> Best regards,
>>> Krzysztof
>>>
#ifndef _ANALOGIX_DP_H_
#define _ANALOGIX_DP_H_
#include
+enum analogix_dp_devtype {
+EXYNOS_DP,
+RK3288_DP,
+};
+
struct analogix_dp_plat_data {
+enum analogix_dp_devtype dev_type;
struct drm_panel *panel;
int (*power_on)(struct analogix_dp_plat_data *);
>>>
>>>
>>
>>
>
>
>
[PATCH v4 0/22] On-demand device probing
Hello, I have a problem with the panel on my Tegra Chromebook taking longer than expected to be ready during boot (Stéphane Marchesin reported what is basically the same issue in [0]), and have looked into ordered probing as a better way of solving this than moving nodes around in the DT or playing with initcall levels and linking order. While reading the thread [1] that Alexander Holler started with his series to make probing order deterministic, it occurred to me that it should be possible to achieve the same by probing devices as they are referenced by other devices. This basically reuses the information that is already implicit in the probe() implementations, saving us from refactoring existing drivers or adding information to DTBs. During review of v1 of this series Linus Walleij suggested that it should be the device driver core to make sure that dependencies are ready before probing a device. I gave this idea a try [2] but Mark Brown pointed out to the logic duplication between the resource acquisition and dependency discovery code paths (though I think it's fairly minor). To address that code duplication I experimented with Arnd's devm_probe [3] concept of having drivers declare their dependencies instead of acquiring them during probe, and while it worked [4], I don't think we end up winning anything when compared to just probing devices on-demand from resource getters. One remaining objection is to the "sprinkling" of calls to of_device_probe() in the resource getters of each subsystem, but I think it's the right thing to do given that the storage of resources is currently subsystem-specific. We could avoid the above by moving resource storage into the core, but I don't think there's a compelling case for that. I have tested this on boards with Tegra, iMX.6, Exynos, Rockchip and OMAP SoCs, and these patches were enough to eliminate all the deferred probes (except one in PandaBoard because omap_dma_system doesn't have a firmware node as of yet). Have submitted a branch [5] with only these patches on top of thursday's linux-next to kernelci.org and I don't see any issues that could be caused by them. For some reason it currently has more passes than the version of -next it's based on! With this series I get the kernel to output to the panel in 0.5s, instead of 2.8s. Regards, Tomeu [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html [1] https://lkml.org/lkml/2014/5/12/452 [2] https://lkml.org/lkml/2015/6/17/305 [3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689 [4] https://lkml.org/lkml/2015/7/21/441a [5] https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=on-demand-probes-v6 [6] http://kernelci.org/boot/all/job/collabora/kernel/v4.2-11902-g25d80c927f8b/ [7] http://kernelci.org/boot/all/job/next/kernel/next-20150903/ Changes in v4: - Added bus.pre_probe callback so the probes of Primecell devices can be deferred if their device IDs cannot be yet read because of the clock driver not having probed when they are registered. Maybe this goes overboard and the matching information should be in the DT if there is one. - Rename of_platform_probe to of_device_probe - Use device_node.device instead of device_node.platform_dev - Take a reference to the regulator's device to prevent dangling pointers - Add Kconfig DELAY_DEVICE_PROBES to allow disabling delayed probing in machines with initcalls that depend on devices probing at a given time. - Start processing deferred probes in device_initcall_sync - Also defer probes of AMBA devices registered from the DT as they can also request resources. Changes in v3: - Set and use device_node.platform_dev instead of reversing the logic to find the platform device that encloses a device node. - Drop the fwnode API to probe firmware nodes and add OF-only API for now. I think this same scheme could be used for machines with ACPI, but I haven't been able to find one that had to defer its probes because of the device probe order. - Avoid unlocking the regulator device's mutex if we don't have a device Changes in v2: - Acquire regulator device lock before returning from regulator_dev_lookup() Tomeu Vizoso (22): driver core: Add pre_probe callback to bus_type ARM: amba: Move reading of periphid to pre_probe() of/platform: Point to struct device from device node of: add function to allow probing a device from a OF node gpio: Probe GPIO drivers on demand gpio: Probe pinctrl devices on demand regulator: core: Reduce critical area in _regulator_get regulator: core: Probe regulators on demand drm: Probe panels on demand drm/tegra: Probe dpaux devices on demand i2c: core: Probe i2c adapters and devices on demand pwm: Probe PWM chip devices on demand backlight: Probe backlight devices on demand usb: phy: Probe phy devices on demand clk: Probe clk providers on demand pinctrl: Probe pinctrl devices on demand phy: core: Probe phy providers on demand dma: of: Pr
[PATCHv9 11/15] cec: adv7604: add cec support.
From: Hans Verkuil
Add CEC support to the adv7604 driver.
Signed-off-by: Hans Verkuil
[k.debski at samsung.com: Merged changes from CEC Updates commit by Hans
Verkuil]
[k.debski at samsung.com: add missing methods cec/io_write_and_or]
[k.debski at samsung.com: change adv7604 to adv76xx in added functions]
[hansverk at cisco.com: use _clr_set instead of _and_or]
---
drivers/media/i2c/adv7604.c | 254 +++-
1 file changed, 250 insertions(+), 4 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 5631ec0..c8142c2 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,11 @@ struct adv76xx_state {
u16 spa_port_a[2];
struct v4l2_fract aspect_ratio;
u32 rgb_quantization_range;
+ bool cec_ready;
+ 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;
@@ -430,7 +438,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);
}
@@ -463,6 +472,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);
@@ -550,8 +565,15 @@ 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;
+ if (state->cec_ready) {
+ 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));
@@ -891,9 +913,14 @@ 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;
+
+ if (state->cec_ready)
+ v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_CONN_INPUTS,
+ &connected_inputs);
- return v4l2_ctrl_s_ctrl(state->detect_tx_5v_ctrl,
- info->read_cable_det(sd));
+ return v4l2_ctrl_s_ctrl(state->detect_tx_5v_ctrl, cable_det);
}
static int find_and_set_predefined_video_timings(struct v4l2_subdev *sd,
@@ -1914,6 +1941,198 @@ 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)
+{
+ 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__);
+ v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE,
+ (void *)CEC_TX_STATUS_ARB_LOST);
+ return;
+ }
+ if (tx_raw_status & 0x04) {
+ v4l2_dbg(1, debug, sd, "%s: tx raw: retry failed\n", __func__);
+ v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE,
+ (void *)CEC_TX_STATUS_RETRY_TIMEOUT);
+ return;
+ }
+ if (tx_raw_status & 0x01) {
+ v4l2_dbg(1, debug, sd, "%s: tx raw: ready ok\n", __func__);
+ v4l2_subdev_notify(sd, V4L2_SUBDEV_CEC_TX_DONE,
+ (void *)CEC_TX_STATUS_OK);
+ return;
+ }
+}
+
+static void adv76xx_cec_isr(struct v4l2_subdev *sd, bool *handled)
+{
+ u8 cec_irq;
+
+ /* cec controller */
+ cec_irq = i
