TENS stimulator/TENS massager
Dear Client, Good day ! Woody here,the manufacturer for TENS / EMS stimulator in Guangzhou China. Can offer good quanlity products in short time. Have any interesting please talk with me for the details. Best regards. Woody
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Tue Apr 7 04:00:18 CEST 2015 git branch: test git hash: a5562f65b1371a0988b707c10c44fcc2bba56990 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-44-g40791b9 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.19.0-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: ERRORS linux-git-powerpc64: OK linux-git-sh: ERRORS linux-git-x86_64: OK linux-2.6.32.27-i686: ERRORS linux-2.6.33.7-i686: ERRORS linux-2.6.34.7-i686: ERRORS linux-2.6.35.9-i686: ERRORS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: ERRORS linux-3.6.11-i686: ERRORS linux-3.7.4-i686: ERRORS linux-3.8-i686: ERRORS linux-3.9.2-i686: ERRORS linux-3.10.1-i686: ERRORS linux-3.11.1-i686: ERRORS linux-3.12.23-i686: ERRORS linux-3.13.11-i686: ERRORS linux-3.14.9-i686: ERRORS linux-3.15.2-i686: ERRORS linux-3.16.7-i686: ERRORS linux-3.17.8-i686: ERRORS linux-3.18.7-i686: ERRORS linux-3.19-i686: ERRORS linux-4.0-rc1-i686: ERRORS linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: ERRORS linux-2.6.34.7-x86_64: ERRORS linux-2.6.35.9-x86_64: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: ERRORS linux-3.6.11-x86_64: ERRORS linux-3.7.4-x86_64: ERRORS linux-3.8-x86_64: ERRORS linux-3.9.2-x86_64: ERRORS linux-3.10.1-x86_64: ERRORS linux-3.11.1-x86_64: ERRORS linux-3.12.23-x86_64: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.9-x86_64: ERRORS linux-3.15.2-x86_64: ERRORS linux-3.16.7-x86_64: ERRORS linux-3.17.8-x86_64: ERRORS linux-3.18.7-x86_64: ERRORS linux-3.19-x86_64: OK linux-4.0-rc1-x86_64: OK apps: OK spec-git: OK ABI WARNING: change for arm-at91 ABI WARNING: change for arm-davinci ABI WARNING: change for arm-exynos ABI WARNING: change for arm-mx ABI WARNING: change for arm-omap ABI WARNING: change for arm-omap1 ABI WARNING: change for arm-pxa ABI WARNING: change for blackfin ABI WARNING: change for i686 ABI WARNING: change for m32r ABI WARNING: change for mips ABI WARNING: change for powerpc64 ABI WARNING: change for sh ABI WARNING: change for x86_64 sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Question about switch() of soc_mbus_config_compatible()
Hi Mauro, Guennadi
I would like to ask you about switch() of
linux/drivers/media/platform/soc_camera/soc_mediabus.c ::
soc_mbus_config_compatible
unsigned int soc_mbus_config_compatible(const struct v4l2_mbus_config *cfg,
unsigned int flags)
{
...
switch (cfg->type) {
case V4L2_MBUS_PARALLEL:
hsync = common_flags & (V4L2_MBUS_HSYNC_ACTIVE_HIGH |
V4L2_MBUS_HSYNC_ACTIVE_LOW);
vsync = common_flags & (V4L2_MBUS_VSYNC_ACTIVE_HIGH |
=> V4L2_MBUS_VSYNC_ACTIVE_LOW);
case V4L2_MBUS_BT656:
pclk = common_flags & (V4L2_MBUS_PCLK_SAMPLE_RISING |
V4L2_MBUS_PCLK_SAMPLE_FALLING);
data = common_flags & (V4L2_MBUS_DATA_ACTIVE_HIGH |
V4L2_MBUS_DATA_ACTIVE_LOW);
mode = common_flags & (V4L2_MBUS_MASTER | V4L2_MBUS_SLAVE);
return (!hsync || !vsync || !pclk || !data || !mode) ?
0 : common_flags;
...
}
Here, there is no break, no return, no /* FALL THROUGH */
It is very confusable, but what is this intention ?
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/4] v4l: of: Remove the head field in struct v4l2_of_endpoint
The field is unused. Remove it.
Signed-off-by: Sakari Ailus
---
include/media/v4l2-of.h |2 --
1 file changed, 2 deletions(-)
diff --git a/include/media/v4l2-of.h b/include/media/v4l2-of.h
index f831c9c..f66b92c 100644
--- a/include/media/v4l2-of.h
+++ b/include/media/v4l2-of.h
@@ -57,7 +57,6 @@ struct v4l2_of_bus_parallel {
* @base: struct of_endpoint containing port, id, and local of_node
* @bus_type: bus type
* @bus: bus configuration data structure
- * @head: list head for this structure
*/
struct v4l2_of_endpoint {
struct of_endpoint base;
@@ -66,7 +65,6 @@ struct v4l2_of_endpoint {
struct v4l2_of_bus_parallel parallel;
struct v4l2_of_bus_mipi_csi2 mipi_csi2;
} bus;
- struct list_head head;
};
/**
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/4] Add link-frequencies to struct v4l2_of_endpoint
Hi folks, This set changes the interface which is used to parse the properties of the endpoint for media devices. changes since v2: - Rebased on current media-tree v2 can be found here: http://www.spinics.net/lists/linux-media/msg88058.html -- Regards, Sakari -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/4] v4l: of: Parse variable length properties --- link-frequencies
The link-frequencies property is a variable length array of link frequencies
in an endpoint. The array is needed by an increasing number of drivers, so
it makes sense to add it to struct v4l2_of_endpoint.
However, the length of the array is variable and the size of struct
v4l2_of_endpoint is fixed since it is allocated by the caller. The options
here are
1. to define a fixed maximum limit of link frequencies that has to be the
global maximum of all boards. This is seen as problematic since the maximum
could be largish, and everyone hitting the problem would need to submit a
patch to fix it, or
2. parse the property in every driver. This doesn't sound appealing as two
of the three implementations submitted to linux-media were wrong, and one of
them was even merged before this was noticed, or
3. change the interface so that allocating and releasing memory according to
the size of the array is possible. This is what the patch does.
v4l2_of_alloc_parse_endpoint() is just like v4l2_of_parse_endpoint(), but it
will allocate the memory resources needed to store struct v4l2_of_endpoint
and the additional arrays pointed to by this struct. A corresponding release
function v4l2_of_free_endpoint() is provided to release the memory allocated
by v4l2_of_alloc_parse_endpoint().
In addition to this, the link-frequencies property is parsed as well, and
the result is stored to struct v4l2_of_endpoint field link_frequencies.
Signed-off-by: Sakari Ailus
---
drivers/media/v4l2-core/v4l2-of.c | 88 +
include/media/v4l2-of.h | 17 +++
2 files changed, 105 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c
index 3ac6348..9810cc6 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -141,6 +142,10 @@ static void v4l2_of_parse_parallel_bus(const struct
device_node *node,
* V4L2_MBUS_CSI2_CONTINUOUS_CLOCK flag.
* The caller should hold a reference to @node.
*
+ * NOTE: This function does not parse properties the size of which is
+ * variable without a low fixed limit. Please use
+ * v4l2_of_alloc_parse_endpoint() in new drivers instead.
+ *
* Return: 0.
*/
int v4l2_of_parse_endpoint(const struct device_node *node,
@@ -167,6 +172,89 @@ int v4l2_of_parse_endpoint(const struct device_node *node,
}
EXPORT_SYMBOL(v4l2_of_parse_endpoint);
+/*
+ * v4l2_of_free_endpoint() - release resources acquired by
+ * v4l2_of_alloc_parse_endpoint()
+ * @endpoint - the endpoint the resources of which are to be released
+ *
+ * It is safe to call this function with NULL argument or on and
+ * endpoint the parsing of which failed.
+ */
+void v4l2_of_free_endpoint(struct v4l2_of_endpoint *endpoint)
+{
+ if (IS_ERR_OR_NULL(endpoint))
+ return;
+
+ kfree(endpoint->link_frequencies);
+ kfree(endpoint);
+}
+EXPORT_SYMBOL(v4l2_of_free_endpoint);
+
+/**
+ * v4l2_of_alloc_parse_endpoint() - parse all endpoint node properties
+ * @node: pointer to endpoint device_node
+ *
+ * All properties are optional. If none are found, we don't set any flags.
+ * This means the port has a static configuration and no properties have
+ * to be specified explicitly.
+ * If any properties that identify the bus as parallel are found and
+ * slave-mode isn't set, we set V4L2_MBUS_MASTER. Similarly, if we recognise
+ * the bus as serial CSI-2 and clock-noncontinuous isn't set, we set the
+ * V4L2_MBUS_CSI2_CONTINUOUS_CLOCK flag.
+ * The caller should hold a reference to @node.
+ *
+ * v4l2_of_alloc_parse_endpoint() has two important differences to
+ * v4l2_of_parse_endpoint():
+ *
+ * 1. It also parses variable size data and
+ *
+ * 2. The memory resources it has acquired to store the variable size
+ *data must be released using v4l2_of_free_endpoint() when no longer
+ *needed.
+ *
+ * Return: Pointer to v4l2_of_endpoint if successful, on error a
+ * negative error code.
+ */
+struct v4l2_of_endpoint *v4l2_of_alloc_parse_endpoint(
+ const struct device_node *node)
+{
+ struct v4l2_of_endpoint *endpoint;
+ int len;
+ int rval;
+
+ endpoint = kzalloc(sizeof(*endpoint), GFP_KERNEL);
+ if (!endpoint)
+ return ERR_PTR(-ENOMEM);
+
+ rval = v4l2_of_parse_endpoint(node, endpoint);
+ if (rval < 0)
+ goto out_err;
+
+ if (of_get_property(node, "link-frequencies", &len)) {
+ endpoint->link_frequencies = kmalloc(len, GFP_KERNEL);
+ if (!endpoint->link_frequencies) {
+ rval = -ENOMEM;
+ goto out_err;
+ }
+
+ endpoint->nr_of_link_frequencies =
+ len / sizeof(*endpoint->link_frequencies);
+
+ rval = of_property_read_u64_array(
+ node, "link-frequencies", endpoint->link_frequenci
[PATCH v3 4/4] smiapp: Use v4l2_of_alloc_parse_endpoint()
Instead of parsing the link-frequencies property in the driver, let
v4l2_of_alloc_parse_endpoint() do it.
Signed-off-by: Sakari Ailus
---
drivers/media/i2c/smiapp/smiapp-core.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c
index 557f25d..4a2e8d3 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2975,9 +2975,9 @@ static int smiapp_resume(struct device *dev)
static struct smiapp_platform_data *smiapp_get_pdata(struct device *dev)
{
struct smiapp_platform_data *pdata;
- struct v4l2_of_endpoint bus_cfg;
+ struct v4l2_of_endpoint *bus_cfg;
struct device_node *ep;
- uint32_t asize;
+ int i;
int rval;
if (!dev->of_node)
@@ -2987,13 +2987,17 @@ static struct smiapp_platform_data
*smiapp_get_pdata(struct device *dev)
if (!ep)
return NULL;
+ bus_cfg = v4l2_of_alloc_parse_endpoint(ep);
+ if (IS_ERR(bus_cfg)) {
+ rval = PTR_ERR(bus_cfg);
+ goto out_err;
+ }
+
pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
goto out_err;
- v4l2_of_parse_endpoint(ep, &bus_cfg);
-
- switch (bus_cfg.bus_type) {
+ switch (bus_cfg->bus_type) {
case V4L2_MBUS_CSI2:
pdata->csi_signalling_mode = SMIAPP_CSI_SIGNALLING_MODE_CSI2;
break;
@@ -3002,7 +3006,7 @@ static struct smiapp_platform_data
*smiapp_get_pdata(struct device *dev)
goto out_err;
}
- pdata->lanes = bus_cfg.bus.mipi_csi2.num_data_lanes;
+ pdata->lanes = bus_cfg->bus.mipi_csi2.num_data_lanes;
dev_dbg(dev, "lanes %u\n", pdata->lanes);
/* xshutdown GPIO is optional */
@@ -3022,34 +3026,30 @@ static struct smiapp_platform_data
*smiapp_get_pdata(struct device *dev)
dev_dbg(dev, "reset %d, nvm %d, clk %d, csi %d\n", pdata->xshutdown,
pdata->nvm_size, pdata->ext_clk, pdata->csi_signalling_mode);
- rval = of_get_property(ep, "link-frequencies", &asize) ? 0 : -ENOENT;
- if (rval) {
- dev_warn(dev, "can't get link-frequencies array size\n");
+ if (!bus_cfg->nr_of_link_frequencies) {
+ dev_warn(dev, "no link frequencies defined\n");
goto out_err;
}
- pdata->op_sys_clock = devm_kzalloc(dev, asize, GFP_KERNEL);
+ pdata->op_sys_clock = devm_kcalloc(
+ dev, bus_cfg->nr_of_link_frequencies + 1 /* guardian */,
+ sizeof(*pdata->op_sys_clock), GFP_KERNEL);
if (!pdata->op_sys_clock) {
rval = -ENOMEM;
goto out_err;
}
- asize /= sizeof(*pdata->op_sys_clock);
- rval = of_property_read_u64_array(
- ep, "link-frequencies", pdata->op_sys_clock, asize);
- if (rval) {
- dev_warn(dev, "can't get link-frequencies\n");
- goto out_err;
+ for (i = 0; i < bus_cfg->nr_of_link_frequencies; i++) {
+ pdata->op_sys_clock[i] = bus_cfg->link_frequencies[i];
+ dev_dbg(dev, "freq %d: %lld\n", i, pdata->op_sys_clock[i]);
}
- for (; asize > 0; asize--)
- dev_dbg(dev, "freq %d: %lld\n", asize - 1,
- pdata->op_sys_clock[asize - 1]);
-
+ v4l2_of_free_endpoint(bus_cfg);
of_node_put(ep);
return pdata;
out_err:
+ v4l2_of_free_endpoint(bus_cfg);
of_node_put(ep);
return NULL;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/4] v4l: of: Instead of zeroing bus_type and bus field separately, unify this
Clean the entire struct starting from bus_type. As more fields are added, no
changes will be needed in the function to reset their value explicitly.
Signed-off-by: Sakari Ailus
---
drivers/media/v4l2-core/v4l2-of.c |5 +++--
include/media/v4l2-of.h |1 +
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c
index 83143d3..3ac6348 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -149,8 +149,9 @@ int v4l2_of_parse_endpoint(const struct device_node *node,
int rval;
of_graph_parse_endpoint(node, &endpoint->base);
- endpoint->bus_type = 0;
- memset(&endpoint->bus, 0, sizeof(endpoint->bus));
+ /* Zero fields from bus_type to until the end */
+ memset(&endpoint->bus_type, 0, sizeof(*endpoint) -
+ offsetof(typeof(*endpoint), bus_type));
rval = v4l2_of_parse_csi_bus(node, endpoint);
if (rval)
diff --git a/include/media/v4l2-of.h b/include/media/v4l2-of.h
index f66b92c..5bbdfbf 100644
--- a/include/media/v4l2-of.h
+++ b/include/media/v4l2-of.h
@@ -60,6 +60,7 @@ struct v4l2_of_bus_parallel {
*/
struct v4l2_of_endpoint {
struct of_endpoint base;
+ /* Fields below this line will be cleaned by v4l2_of_parse_endpoint() */
enum v4l2_mbus_type bus_type;
union {
struct v4l2_of_bus_parallel parallel;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/14] clkdev: add clkdev_create() helper
On 04/03/15 10:12, Russell King wrote: > @@ -316,6 +329,29 @@ clkdev_alloc(struct clk *clk, const char *con_id, const > char *dev_fmt, ...) > } > EXPORT_SYMBOL(clkdev_alloc); > > +/** > + * clkdev_create - allocate and add a clkdev lookup structure > + * @clk: struct clk to associate with all clk_lookups > + * @con_id: connection ID string on device > + * @dev_fmt: format string describing device name > + * > + * Returns a clk_lookup structure, which can be later unregistered and > + * freed. Please add that this returns NULL on failure. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/14] clkdev: use clk_hw internally
On 04/03/15 10:12, Russell King wrote:
> Signed-off-by: Russell King
Some commit text would be nice for us 5 years from now when we wonder
why this patch was applied.
I suspect the commit text would go like this:
clk_add_alias() calls clk_get() followed by clk_put() but in between
those two calls it saves away the struct clk pointer to a clk_lookup
structure. This leaves the 'clk' member of the clk_lookup pointing at
freed memory on configurations where CONFIG_COMMON_CLK=y. This is a
problem because clk_get_sys() will eventually try to dereference the
freed pointer by calling __clk_get_hw() on it. Fix this by saving away
the struct clk_hw pointer instead of the struct clk pointer so that when
we try to create a per-user struct clk in clk_get_sys() we don't
dereference a junk pointer.
Now the question is does any of this matter for the 4.0 release. From
what I can tell, the answer is no.
$ git grep 'clk_add_alias' v4.0-rc6
v4.0-rc6:arch/arm/mach-davinci/da850.c: clk_add_alias("async",
da850_cpufreq_device.name,
v4.0-rc6:arch/arm/mach-omap1/board-nokia770.c: clk_add_alias("hwa_sys_ck",
NULL, "bclk", NULL);
v4.0-rc6:arch/arm/mach-pxa/eseries.c: clk_add_alias("CLK_CK48M",
e740_t7l66xb_device.name,
v4.0-rc6:arch/arm/mach-pxa/eseries.c: clk_add_alias("CLK_CK3P6MI",
e750_tc6393xb_device.name,
v4.0-rc6:arch/arm/mach-pxa/eseries.c: clk_add_alias("CLK_CK3P6MI",
e800_tc6393xb_device.name,
v4.0-rc6:arch/arm/mach-pxa/lubbock.c: clk_add_alias("SA_CLK", NULL,
"GPIO11_CLK", NULL);
v4.0-rc6:arch/arm/mach-pxa/tosa.c: clk_add_alias("CLK_CK3P6MI",
tc6393xb_device.name, "GPIO11_CLK", NULL);
v4.0-rc6:arch/mips/alchemy/common/clock.c:
clk_add_alias(t->alias, NULL, t->base, NULL);
v4.0-rc6:arch/mips/ath79/clock.c: clk_add_alias("wdt", NULL, "ahb", NULL);
v4.0-rc6:arch/mips/ath79/clock.c: clk_add_alias("uart", NULL, "ahb",
NULL);
v4.0-rc6:arch/mips/ath79/clock.c: clk_add_alias("wdt", NULL, "ahb", NULL);
v4.0-rc6:arch/mips/ath79/clock.c: clk_add_alias("uart", NULL, "ahb",
NULL);
v4.0-rc6:arch/mips/ath79/clock.c: clk_add_alias("wdt", NULL, "ahb", NULL);
v4.0-rc6:arch/mips/ath79/clock.c: clk_add_alias("uart", NULL, "ahb",
NULL);
v4.0-rc6:arch/mips/ath79/clock.c: clk_add_alias("wdt", NULL, "ahb", NULL);
v4.0-rc6:arch/mips/ath79/clock.c: clk_add_alias("uart", NULL, "ref",
NULL);
v4.0-rc6:arch/mips/ath79/clock.c: clk_add_alias("wdt", NULL, "ref", NULL);
v4.0-rc6:arch/mips/ath79/clock.c: clk_add_alias("uart", NULL, "ref",
NULL);
v4.0-rc6:arch/mips/ath79/clock.c: clk_add_alias("wdt", NULL, "ref", NULL);
v4.0-rc6:arch/mips/ath79/clock.c: clk_add_alias("uart", NULL, "ref",
NULL);
v4.0-rc6:arch/sh/kernel/cpu/clock-cpg.c:clk_add_alias("fck",
"sh-tmu-sh3.0", "peripheral_clk", NULL);
v4.0-rc6:arch/sh/kernel/cpu/clock-cpg.c:clk_add_alias("fck",
"sh-tmu.0", "peripheral_clk", NULL);
v4.0-rc6:arch/sh/kernel/cpu/clock-cpg.c:clk_add_alias("fck",
"sh-tmu.1", "peripheral_clk", NULL);
v4.0-rc6:arch/sh/kernel/cpu/clock-cpg.c:clk_add_alias("fck",
"sh-tmu.2", "peripheral_clk", NULL);
v4.0-rc6:arch/sh/kernel/cpu/clock-cpg.c:clk_add_alias("fck", "sh-mtu2",
"peripheral_clk", NULL);
v4.0-rc6:arch/sh/kernel/cpu/clock-cpg.c:clk_add_alias("fck",
"sh-cmt-16.0", "peripheral_clk", NULL);
v4.0-rc6:arch/sh/kernel/cpu/clock-cpg.c:clk_add_alias("fck",
"sh-cmt-32.0", "peripheral_clk", NULL);
v4.0-rc6:arch/sh/kernel/cpu/clock-cpg.c:clk_add_alias("sci_ick", NULL,
"peripheral_clk", NULL);
All of these architectures and platforms have CONFIG_COMMON_CLK=n, so
there doesn't seem to be any regression that these patches are fixing.
That isn't to say the patches are bad, just that they aren't urgent for
the upcoming release.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/14] clkdev: get rid of redundant clk_add_alias() prototype in linux/clk.h
On 04/04/15 05:43, Robert Jarzmik wrote: > Russell King writes: > >> clk_add_alias() is provided by clkdev, and is not part of the clk API. >> Howver, it is prototyped in two locations: linux/clkdev.h and >> linux/clk.h. This is a mess. Get rid of the redundant and unnecessary >> version in linux/clk.h. >> >> Signed-off-by: Russell King > Tested-by: Robert Jarzmik > > Actually, this serie fixes a regression I've seen in linux-next, and which was > triggering the Oops in [1] on lubbock. With your serie, the kernel boots fine. > > Is this with the lubbock_defconfig? Is it a regression in 4.0-rc series or is it due to some pending -next patches interacting with the per-user clock patches? It looks like the latter because __clk_get_hw() should be inlined on lubbock_defconfig where CONFIG_COMMON_CLK=n. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DVBSky S952 and PCTV 290e DVB-T2 Together
I wasn't sure if this was the right place for this query, but I just wondered if anyone could help. I'm trying to use both a dual tuner DVB-S2 DVBSky S952 card and a PCTV 290e DVB-T2 card on one machine running Ubuntu 14.04. I heard that the DVBSky card is now supported in the main media_build drivers, so when I did a fresh install of my computer a few days ago, I tried this. The DVBSky card was recognised but TVHeadend was unable to tune in any channels, reporting problems with setting DiSEqC and LNB voltage. This has led me back to using DVBSky's own release of V4L media_build drivers from their site - http://www.dvbsky.net/Support_linux.html - media_build-bst-14-141106. However, with the DVBSky drivers, I cannot use my PCTV 290e DVB-T2 USB stick (it works fine under the regular media_build). I get the following messages on dmesg: [2.074294] em28xx: disagrees about version of symbol v4l2_i2c_new_subdev_board [2.074296] em28xx: Unknown symbol v4l2_i2c_new_subdev_board (err -22) [2.074351] em28xx: disagrees about version of symbol tveeprom_hauppauge_analog [2.074352] em28xx: Unknown symbol tveeprom_hauppauge_analog (err -22) The device does not show in DVB devices. Does anybody know what this error is and how to fix it? I don't mind using either regular drivers or the DVBSky ones as long as I can get both my devices working. Many thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: using TSOP receiver without lircd
On Mon, Apr 06, 2015 at 06:01:52PM +0200, Sergio Serrano wrote: >Hi members! > >In the hope that someone can help me, I has come to this mailing list after >contacting David Hardeman (thank you!). >He has already given me some clues. This is my scenario. > >I'm using a OMAP2 processor and capturing TSOP34836 (remote RC5 compatible) >signals through GPIO+interrupt. I have created the /dev/lirc0 device , here >comes my question: If possible I don't want to deal with LIRC and irrecord >stuff. Is it possible? What will be the first steps? Your next step would be a kernel driver that receives the GPIO interrupts and feeds them into rc-core as "edge" events. drivers/media/rc/gpio-ir-recv.c is probably what you want as a starting point (though you'll need to find a way to feed it the right parameters...) Regards, David -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 4.1] ts2022 tuner makefile fix
The following changes since commit a5562f65b1371a0988b707c10c44fcc2bba56990: [media] v4l: xilinx: Add Test Pattern Generator driver (2015-04-03 01:04:18 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git ts2022_makefile_fix for you to fetch changes up to 52a5e5181425959030acb8c13bd0b1fe10db5bfb: m88ts2022: remove from Makefile (2015-04-06 19:22:11 +0300) Hans Verkuil (1): m88ts2022: remove from Makefile drivers/media/tuners/Makefile | 1 - 1 file changed, 1 deletion(-) -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: using TSOP receiver without lircd
Hi members! In the hope that someone can help me, I has come to this mailing list after contacting David Hardeman (thank you!). He has already given me some clues. This is my scenario. I'm using a OMAP2 processor and capturing TSOP34836 (remote RC5 compatible) signals through GPIO+interrupt. I have created the /dev/lirc0 device , here comes my question: If possible I don't want to deal with LIRC and irrecord stuff. Is it possible? What will be the first steps? Kind regards, Sergio -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] break kconfig dependency loop
Em Mon, 06 Apr 2015 11:50:21 +0200 Paul Bolle escreveu: > On Wed, 2015-04-01 at 16:47 +0300, Jani Nikula wrote: > > I think part of the problem is that "select" is often used not as > > documented [1] but rather as "show my config in menuconfig for > > convenience even if my dependency is not met, and select the dependency > > even though I know it can screw up the dependency chain". > > Perhaps people use select because it offers, given the problem they > face, a reasonable way to make the kconfig tools generate a > sensible .config. It helps them to spend less time fiddling with Kconfig > files. And they expect that it helps others to configure their build > more easily, as it might save those others some work. At least on media, the main usage of select is to handle complex hardware where lots of drivers are needed in order to have support for all boards supported by a given board. On a practical example, let's take a look at em28xx driver. This is a bridge driver for media boards. It supports ~100 different boards. Each board may have different tuners, different analog TV demods, different digital TV demods, eeproms attached into one of its I2C buses. As this is an USB stick, the normal user will never know what are the other components of the board without some hard work (by opening the USB stick by seeking for the information at the Internet until he discovers all the components). Even after knowing the hardware components, he has to figure out what drivers implement support for each component. So, for the normal user, we offer a way for the user to select all possible combinations via MEDIA_SUBDRV_AUTOSELECT. This way, he'll know for sure that all boards supported by em28xx will be available. For those that would embedded em28xx on some hardware (like a TV PVR box), he can disable such option and manually select the specific components his hardware uses. For obvious reasons, we recommend distros to always enable MEDIA_SUBDRV_AUTOSELECT. So, yes, select saves a lot of work to configure the build what they want on an easy and sane way. That's said, while it would be possible to convert select into depends on, the result would be really ugly, and very hard to be maintained, as I2C drivers that don't actually depend on the bridge drivers would need a fake depends on list: config DVB_MB86A20S tristate "Fujitsu mb86a20s" # real dependency chain depends on DVB_CORE && I2C # fake dependency chain depends on (!MEDIA_SUBDRV_AUTOSELECT || CONFIG_VIDEO_CX23885_DVB || CONFIG_VIDEO_CX231XX_DVB || CONFIG_VIDEO_EM28xx_DVB) I got here an easy example of an ISDB-T driver, with is not used on many boards. There are other I2C drivers that are used by almost all media drivers, with would result on a very complex fake dependency chain. The worse thing with such ugly fake dependency chain is that people adding a new driver (or support for a new board) would need to remember to dig into drivers that weren't touched, adding new stuff on their Kconfig. > > In the big picture, it feels like menuconfig needs a way to display > > items whose dependencies are not met, and a way to recursively enable > > said items and all their dependencies when told. I believe so. > How could that work its way through (multiple levels of) things like: > depends on FOO || (BAZ && BAR) At least for our typical use case, the dependency chain should not have things like the above, as we use this mainly for I2C drivers, and the bridge drivers also depend on I2C. I would say that, if Kconfig adds a recursive select implementation, such implementation should: - stop recursion if the depends condition was met; - if the depends condition is unmet and has two or more possible options to satisfy (like on your above example), it should prompt the user about what option it would want. If it can't do it (for example, for a "silent" type of config, where it shouldn't be expected any userspace interaction), it should print a warning and not enable the driver. Granted, this is easier said than done. We have this problem mapped for a long time, but none was brave enough (or had enough time) to actually try to implement something like that. So, what we generally do, as a workaround, is to try to simplify the Kconfig stuff to avoid complex use cases. We do that by adding fake dependencies to drivers that might require another driver for some board to work. For example, several USB media drivers now depends on I2C_MUX just because a few of the possible drivers it may need should select I2C_MUX. Btw, I2C_MUX is an optional feature of the I2C core. There's no way for a normal user to know if a driver would need such feature or not, as it basically depends on how the device was internally wired and if the Kernel driver would use it (older drivers have their own solution without using the I2C_MUX new way). There are a few other such options at the I2C sub-system. All of them depends on I2C onl
[PATCH 2/4] ir-keytable: replace more sysfs if-else code with loops
Document the sysfs1 interface in protocol_map[] and replace some
more if-else code with loops.
Signed-off-by: David Härdeman
---
utils/keytable/keytable.c | 124 -
1 file changed, 55 insertions(+), 69 deletions(-)
diff --git a/utils/keytable/keytable.c b/utils/keytable/keytable.c
index 2ca693f..949eed9 100644
--- a/utils/keytable/keytable.c
+++ b/utils/keytable/keytable.c
@@ -109,36 +109,37 @@ enum sysfs_protocols {
struct protocol_map_entry {
const char *name;
+ const char *sysfs1_name;
enum sysfs_protocols sysfs_protocol;
};
const struct protocol_map_entry protocol_map[] = {
- { "unknown",SYSFS_UNKNOWN },
- { "other", SYSFS_OTHER },
- { "lirc", SYSFS_LIRC },
- { "rc-5", SYSFS_RC5 },
- { "rc5",SYSFS_RC5 },
- { "rc-5x", SYSFS_INVALID },
- { "rc5x", SYSFS_INVALID },
- { "jvc",SYSFS_JVC },
- { "sony", SYSFS_SONY },
- { "sony12", SYSFS_INVALID },
- { "sony15", SYSFS_INVALID },
- { "sony20", SYSFS_INVALID },
- { "nec",SYSFS_NEC },
- { "sanyo", SYSFS_SANYO },
- { "mce-kbd",SYSFS_MCE_KBD },
- { "mce_kbd",SYSFS_MCE_KBD },
- { "rc-6", SYSFS_RC6 },
- { "rc6",SYSFS_RC6 },
- { "rc-6-0", SYSFS_INVALID },
- { "rc-6-6a-20", SYSFS_INVALID },
- { "rc-6-6a-24", SYSFS_INVALID },
- { "rc-6-6a-32", SYSFS_INVALID },
- { "rc-6-mce", SYSFS_INVALID },
- { "sharp", SYSFS_SHARP },
- { "xmp",SYSFS_XMP },
- { NULL, SYSFS_INVALID },
+ { "unknown",NULL, SYSFS_UNKNOWN },
+ { "other", NULL, SYSFS_OTHER },
+ { "lirc", NULL, SYSFS_LIRC },
+ { "rc-5", "/rc5_decoder", SYSFS_RC5 },
+ { "rc5",NULL, SYSFS_RC5 },
+ { "rc-5x", NULL, SYSFS_INVALID },
+ { "rc5x", NULL, SYSFS_INVALID },
+ { "jvc","/jvc_decoder", SYSFS_JVC },
+ { "sony", "/sony_decoder",SYSFS_SONY },
+ { "sony12", NULL, SYSFS_INVALID },
+ { "sony15", NULL, SYSFS_INVALID },
+ { "sony20", NULL, SYSFS_INVALID },
+ { "nec","/nec_decoder", SYSFS_NEC },
+ { "sanyo", NULL, SYSFS_SANYO },
+ { "mce-kbd",NULL, SYSFS_MCE_KBD },
+ { "mce_kbd",NULL, SYSFS_MCE_KBD },
+ { "rc-6", "/rc6_decoder", SYSFS_RC6 },
+ { "rc6",NULL, SYSFS_RC6 },
+ { "rc-6-0", NULL, SYSFS_INVALID },
+ { "rc-6-6a-20", NULL, SYSFS_INVALID },
+ { "rc-6-6a-24", NULL, SYSFS_INVALID },
+ { "rc-6-6a-32", NULL, SYSFS_INVALID },
+ { "rc-6-mce", NULL, SYSFS_INVALID },
+ { "sharp", NULL, SYSFS_SHARP },
+ { "xmp","/xmp_decoder", SYSFS_XMP },
+ { NULL, NULL, SYSFS_INVALID },
};
static enum sysfs_protocols parse_sysfs_protocol(const char *name, bool
all_allowed)
@@ -886,7 +887,7 @@ static int v1_get_sw_enabled_protocol(char *dirname)
}
static int v1_set_sw_enabled_protocol(struct rc_device *rc_dev,
- char *dirname, int enabled)
+ const char *dirname, int enabled)
{
FILE *fp;
char name[512];
@@ -1084,30 +1085,20 @@ static int get_attribs(struct rc_device *rc_dev, char
*sysfs_name)
} else if (strstr(cur->name, "/supported_protocols")) {
rc_dev->version = VERSION_1;
rc_dev->supported = v1_get_hw_protocols(cur->name);
- } else if (strstr(cur->name, "/nec_decoder")) {
- rc_dev->supported |= SYSFS_NEC;
- if (v1_get_sw_enabled_protocol(cur->name))
- rc_dev->current |= SYSFS_NEC;
- } else if (strstr(cur->name, "/rc5_decoder")) {
- rc_dev->supported |= SYSFS_RC5;
- if (v1_get_sw_enabled_protocol(cur->name))
- rc_dev->current |= SYSFS_RC5;
- } else if (strstr(cur->name, "/rc6_decoder")) {
- rc_dev->supported |= SYSFS_RC6;
- if (v1_get_sw_enabled_protocol(cur->name))
- rc_dev->current |= SYSFS_RC6;
- } else if (strstr(cur->name, "/jvc_decoder")) {
- rc_dev->supported |= SYSFS_JVC;
- if (v1_get_sw_enabled_protocol(cur->name))
- rc_dev->cu
[PATCH 4/4] ir-keytable: allow protocol for scancode-keycode mappings
Introduce a list of "kernel" ir protocols (e.g. "sony12" instead of "sony")
and extend the set-key command to ir-keytable to allow for a mapping of the
form "protocol:scancode=keycode" in addition to the old "scancode=keycode"
format. The code automatically falls back to the old behaviour if the
kernel doesn't support the new approach with protocols.
The read command is also updated to show the protocol information if the
kernel supports it.
Signed-off-by: David Härdeman
---
utils/keytable/keytable.c | 288 -
1 file changed, 202 insertions(+), 86 deletions(-)
diff --git a/utils/keytable/keytable.c b/utils/keytable/keytable.c
index 63eea2e..fd50095 100644
--- a/utils/keytable/keytable.c
+++ b/utils/keytable/keytable.c
@@ -55,13 +55,22 @@ struct input_keymap_entry_v2 {
#define EVIOCSKEYCODE_V2 _IOW('E', 0x04, struct input_keymap_entry_v2)
#endif
-struct keytable_entry {
- u_int32_t scancode;
- u_int32_t keycode;
- struct keytable_entry *next;
+struct rc_scancode {
+ u_int16_t protocol;
+ u_int16_t reserved[3];
+ u_int64_t scancode;
};
-struct keytable_entry *keytable = NULL;
+struct rc_keymap_entry {
+ u_int8_t flags;
+ u_int8_t len;
+ u_int16_t index;
+ u_int32_t keycode;
+ union {
+ struct rc_scancode rc;
+ u_int8_t raw[32];
+ };
+};
struct uevents {
char*key;
@@ -109,41 +118,76 @@ enum sysfs_protocols {
SYSFS_INVALID = 0,
};
+enum kernel_protocol {
+ KERN_UNKNOWN= 0,/* Protocol not known */
+ KERN_OTHER = 1,/* Protocol known but proprietary */
+ KERN_LIRC = 2,/* Pass raw IR to lirc userspace */
+ KERN_RC5= 3,/* Philips RC5 protocol */
+ KERN_RC5X = 4,/* Philips RC5x protocol */
+ KERN_RC5_SZ = 5,/* StreamZap variant of RC5 */
+ KERN_JVC= 6,/* JVC protocol */
+ KERN_SONY12 = 7,/* Sony 12 bit protocol */
+ KERN_SONY15 = 8,/* Sony 15 bit protocol */
+ KERN_SONY20 = 9,/* Sony 20 bit protocol */
+ KERN_NEC= 10, /* NEC protocol */
+ KERN_SANYO = 11, /* Sanyo protocol */
+ KERN_MCE_KBD= 12, /* RC6-ish MCE keyboard/mouse */
+ KERN_RC6_0 = 13, /* Philips RC6-0-16 protocol */
+ KERN_RC6_6A_20 = 14, /* Philips RC6-6A-20 protocol */
+ KERN_RC6_6A_24 = 15, /* Philips RC6-6A-24 protocol */
+ KERN_RC6_6A_32 = 16, /* Philips RC6-6A-32 protocol */
+ KERN_RC6_MCE= 17, /* MCE (Philips RC6-6A-32 subtype)
protocol */
+ KERN_SHARP = 18, /* Sharp protocol */
+ KERN_XMP= 19, /* XMP protocol */
+ KERN_INVALID= 31, /* internal, no real protocol number */
+};
+
struct protocol_map_entry {
const char *name;
const char *sysfs1_name;
enum sysfs_protocols sysfs_protocol;
+ enum kernel_protocol kernel_protocol;
};
const struct protocol_map_entry protocol_map[] = {
- { "unknown",NULL, SYSFS_UNKNOWN },
- { "other", NULL, SYSFS_OTHER },
- { "lirc", NULL, SYSFS_LIRC },
- { "rc-5", "/rc5_decoder", SYSFS_RC5 },
- { "rc5",NULL, SYSFS_RC5 },
- { "rc-5x", NULL, SYSFS_INVALID },
- { "rc5x", NULL, SYSFS_INVALID },
- { "jvc","/jvc_decoder", SYSFS_JVC },
- { "sony", "/sony_decoder",SYSFS_SONY },
- { "sony12", NULL, SYSFS_INVALID },
- { "sony15", NULL, SYSFS_INVALID },
- { "sony20", NULL, SYSFS_INVALID },
- { "nec","/nec_decoder", SYSFS_NEC },
- { "sanyo", NULL, SYSFS_SANYO },
- { "mce-kbd",NULL, SYSFS_MCE_KBD },
- { "mce_kbd",NULL, SYSFS_MCE_KBD },
- { "rc-6", "/rc6_decoder", SYSFS_RC6 },
- { "rc6",NULL, SYSFS_RC6 },
- { "rc-6-0", NULL, SYSFS_INVALID },
- { "rc-6-6a-20", NULL, SYSFS_INVALID },
- { "rc-6-6a-24", NULL, SYSFS_INVALID },
- { "rc-6-6a-32", NULL, SYSFS_INVALID },
- { "rc-6-mce", NULL, SYSFS_INVALID },
- { "sharp", NULL, SYSFS_SHARP },
- { "xmp","/xmp_decoder", SYSFS_XMP },
- { NULL, NULL, SYSFS_INVALID },
+ { "unknown",NULL, SYSFS_UNKNOWN, KERN_UNKNOWN},
+ { "other", NULL, SYSFS_OTHER,KERN_OTHER },
+ { "lirc", NULL,
[PATCH 3/4] ir-keytable: cleanup keytable code
Cleanup the keytable code by giving the struct members more explicit
names (scancode instead of codes[0], keycode instead of codes[1]).
Also, replace a linked list implementation using a quirky empty list
member as the head of the list rather than the classical pointer.
Signed-off-by: David Härdeman
---
utils/keytable/keytable.c | 100 ++---
1 file changed, 57 insertions(+), 43 deletions(-)
diff --git a/utils/keytable/keytable.c b/utils/keytable/keytable.c
index 949eed9..63eea2e 100644
--- a/utils/keytable/keytable.c
+++ b/utils/keytable/keytable.c
@@ -55,12 +55,14 @@ struct input_keymap_entry_v2 {
#define EVIOCSKEYCODE_V2 _IOW('E', 0x04, struct input_keymap_entry_v2)
#endif
-struct keytable {
- u_int32_t codes[2];
- struct input_keymap_entry_v2 keymap;
- struct keytable *next;
+struct keytable_entry {
+ u_int32_t scancode;
+ u_int32_t keycode;
+ struct keytable_entry *next;
};
+struct keytable_entry *keytable = NULL;
+
struct uevents {
char*key;
char*value;
@@ -237,12 +239,6 @@ static int delay = 0;
static int period = 0;
static enum sysfs_protocols ch_proto = 0;
-struct keytable keys = {
- .codes = {0, 0},
- .next = NULL
-};
-
-
struct cfgfile cfg = {
NULL, NULL, NULL, NULL
};
@@ -268,13 +264,12 @@ struct rc_device {
enum sysfs_protocols supported, current; /* Current and supported IR
protocols */
};
-struct keytable *nextkey = &keys;
-
static error_t parse_keyfile(char *fname, char **table)
{
FILE *fin;
int value, line = 0;
char *scancode, *keycode, s[2048];
+ struct keytable_entry *ke;
*table = NULL;
@@ -356,14 +351,16 @@ static error_t parse_keyfile(char *fname, char **table)
perror(_("value"));
}
- nextkey->codes[0] = (unsigned) strtoul(scancode, NULL, 0);
- nextkey->codes[1] = (unsigned) value;
- nextkey->next = calloc(1, sizeof(*nextkey));
- if (!nextkey->next) {
+ ke = calloc(1, sizeof(*ke));
+ if (!ke) {
perror("parse_keyfile");
return ENOMEM;
}
- nextkey = nextkey->next;
+
+ ke->scancode= strtoul(scancode, NULL, 0);
+ ke->keycode = value;
+ ke->next= keytable;
+ keytable= ke;
}
fclose(fin);
@@ -497,33 +494,46 @@ static error_t parse_opt(int k, char *arg, struct
argp_state *state)
case 'k':
p = strtok(arg, ":=");
do {
+ struct keytable_entry *ke;
+
if (!p)
goto err_inval;
- nextkey->codes[0] = strtoul(p, NULL, 0);
- if (errno)
+
+ ke = calloc(1, sizeof(*ke));
+ if (!ke) {
+ perror(_("No memory!\n"));
+ return ENOMEM;
+ }
+
+ ke->scancode = strtoul(p, NULL, 0);
+ if (errno) {
+ free(ke);
goto err_inval;
+ }
p = strtok(NULL, ",;");
- if (!p)
+ if (!p) {
+ free(ke);
goto err_inval;
+ }
+
key = parse_code(p);
if (key == -1) {
key = strtol(p, NULL, 0);
- if (errno)
+ if (errno) {
+ free(ke);
goto err_inval;
+ }
}
- nextkey->codes[1] = key;
+
+ ke->keycode = key;
if (debug)
fprintf(stderr, _("scancode 0x%04x=%u\n"),
- nextkey->codes[0], nextkey->codes[1]);
+ ke->scancode, ke->keycode);
- nextkey->next = calloc(1, sizeof(keys));
- if (!nextkey->next) {
- perror(_("No memory!\n"));
- return ENOMEM;
- }
- nextkey = nextkey->next;
+ ke->next = keytable;
+ keytable = ke;
p = strtok(NULL, ":=");
} while (p);
@@ -1189,26 +1199,30 @@ static void clear_table(int fd)
static int add_keys(int fd)
{
int write_cnt = 0;
+ struct keytable_entry *ke;
+
[PATCH 1/4] ir-keytable: clarify the meaning of ir protocols
Clarify that ir protocols refer to the ones used by sysfs (e.g. "sony", not
"sony12" or "sony15") and replace a bunch of if-else protocol comparison
code with loops instead.
Signed-off-by: David Härdeman
---
utils/keytable/keytable.c | 408 +
1 file changed, 152 insertions(+), 256 deletions(-)
diff --git a/utils/keytable/keytable.c b/utils/keytable/keytable.c
index dcbfd83..2ca693f 100644
--- a/utils/keytable/keytable.c
+++ b/utils/keytable/keytable.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include "parse.h"
@@ -89,21 +90,88 @@ enum sysfs_ver {
VERSION_2, /* has node protocols */
};
-enum ir_protocols {
- RC_5= 1 << 0,
- RC_6= 1 << 1,
- NEC = 1 << 2,
- JVC = 1 << 3,
- SONY= 1 << 4,
- LIRC= 1 << 5,
- SANYO = 1 << 6,
- RC_5_SZ = 1 << 7,
- SHARP = 1 << 8,
- MCE_KBD = 1 << 9,
- XMP = 1 << 10,
- OTHER = 1 << 31,
+enum sysfs_protocols {
+ SYSFS_UNKNOWN = (1 << 0),
+ SYSFS_OTHER = (1 << 1),
+ SYSFS_LIRC = (1 << 2),
+ SYSFS_RC5 = (1 << 3),
+ SYSFS_RC5_SZ= (1 << 4),
+ SYSFS_JVC = (1 << 5),
+ SYSFS_SONY = (1 << 6),
+ SYSFS_NEC = (1 << 7),
+ SYSFS_SANYO = (1 << 8),
+ SYSFS_MCE_KBD = (1 << 9),
+ SYSFS_RC6 = (1 << 10),
+ SYSFS_SHARP = (1 << 11),
+ SYSFS_XMP = (1 << 12),
+ SYSFS_INVALID = 0,
};
+struct protocol_map_entry {
+ const char *name;
+ enum sysfs_protocols sysfs_protocol;
+};
+
+const struct protocol_map_entry protocol_map[] = {
+ { "unknown",SYSFS_UNKNOWN },
+ { "other", SYSFS_OTHER },
+ { "lirc", SYSFS_LIRC },
+ { "rc-5", SYSFS_RC5 },
+ { "rc5",SYSFS_RC5 },
+ { "rc-5x", SYSFS_INVALID },
+ { "rc5x", SYSFS_INVALID },
+ { "jvc",SYSFS_JVC },
+ { "sony", SYSFS_SONY },
+ { "sony12", SYSFS_INVALID },
+ { "sony15", SYSFS_INVALID },
+ { "sony20", SYSFS_INVALID },
+ { "nec",SYSFS_NEC },
+ { "sanyo", SYSFS_SANYO },
+ { "mce-kbd",SYSFS_MCE_KBD },
+ { "mce_kbd",SYSFS_MCE_KBD },
+ { "rc-6", SYSFS_RC6 },
+ { "rc6",SYSFS_RC6 },
+ { "rc-6-0", SYSFS_INVALID },
+ { "rc-6-6a-20", SYSFS_INVALID },
+ { "rc-6-6a-24", SYSFS_INVALID },
+ { "rc-6-6a-32", SYSFS_INVALID },
+ { "rc-6-mce", SYSFS_INVALID },
+ { "sharp", SYSFS_SHARP },
+ { "xmp",SYSFS_XMP },
+ { NULL, SYSFS_INVALID },
+};
+
+static enum sysfs_protocols parse_sysfs_protocol(const char *name, bool
all_allowed)
+{
+ const struct protocol_map_entry *pme;
+
+ if (!name)
+ return SYSFS_INVALID;
+
+ if (all_allowed && !strcasecmp(name, "all"))
+ return ~0;
+
+ for (pme = protocol_map; pme->name; pme++) {
+ if (!strcasecmp(name, pme->name))
+ return pme->sysfs_protocol;
+ }
+
+ return SYSFS_INVALID;
+}
+
+static void write_sysfs_protocols(enum sysfs_protocols protocols, FILE *fp,
const char *fmt)
+{
+ const struct protocol_map_entry *pme;
+
+ for (pme = protocol_map; pme->name; pme++) {
+ if (!(protocols & pme->sysfs_protocol))
+ continue;
+
+ fprintf(fp, fmt, pme->name);
+ protocols &= ~pme->sysfs_protocol;
+ }
+}
+
static int parse_code(char *string)
{
struct parse_event *p;
@@ -166,7 +234,7 @@ static int debug = 0;
static int test = 0;
static int delay = 0;
static int period = 0;
-static enum ir_protocols ch_proto = 0;
+static enum sysfs_protocols ch_proto = 0;
struct keytable keys = {
.codes = {0, 0},
@@ -196,7 +264,7 @@ struct rc_device {
enum sysfs_ver version; /* sysfs version */
enum rc_type type; /* Software (raw) or hardware decoder */
- enum ir_protocols supported, current; /* Current and supported IR
protocols */
+ enum sysfs_protocols supported, current; /* Current and supported IR
protocols */
};
struct keytable *nextkey = &keys;
@@ -237,37 +305,20 @@ static error_t parse_keyfile(char *fname, char **table)
strcpy(*table, p);
} else if (!strcmp(p, "type")) {
p = strtok(NULL, " ,\n");
- do {
- if (!p)
-
[PATCH 0/4] Add protocol support to ir-keytable
The following series adds support to ir-keytable for explicitly setting the protocol of scancode<->keycode mappings (requires a patched kernel). The first three patches are cleanups and refactoring which are probably worthwhile to apply in any case. The fourth patch adds the actual support (backward compatible) for set-key and reading the keytable. Separate patches would be necessary to also support reading keytable files with protocol information. --- David Härdeman (4): ir-keytable: clarify the meaning of ir protocols ir-keytable: replace more sysfs if-else code with loops ir-keytable: cleanup keytable code ir-keytable: allow protocol for scancode-keycode mappings utils/keytable/keytable.c | 716 +++-- 1 file changed, 364 insertions(+), 352 deletions(-) -- David Härdeman -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] NEC scancodes and protocols in keymaps - v2
The following two patches should show more clearly what I mean by adding protocols to the keytables (and letting userspace add keytable entries with explicit protocol information). Consider it a basis for discussion. Each patch has a separate description, please refer to those for more information. v2: fix some bugs found while implementing support in ir-keytables. --- David Härdeman (2): rc-core: use the full 32 bits for NEC scancodes rc-core: don't throw away protocol information drivers/media/rc/ati_remote.c|1 drivers/media/rc/imon.c |7 + drivers/media/rc/ir-nec-decoder.c| 26 --- drivers/media/rc/rc-main.c | 234 -- drivers/media/usb/dvb-usb-v2/af9015.c| 22 +-- drivers/media/usb/dvb-usb-v2/af9035.c| 25 +-- drivers/media/usb/dvb-usb-v2/az6007.c| 16 +- drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 20 +-- drivers/media/usb/dvb-usb/dib0700_core.c | 24 +-- drivers/media/usb/em28xx/em28xx-input.c | 37 + include/media/rc-core.h | 26 +++ include/media/rc-map.h | 23 ++- 12 files changed, 266 insertions(+), 195 deletions(-) -- David Härdeman -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] rc-core: use the full 32 bits for NEC scancodes
Using the full 32 bits for all kinds of NEC scancodes simplifies rc-core
and the nec decoder without any loss of functionality. At the same time
it ensures that scancodes for NEC16/NEC24/NEC32 do not overlap and
removes any ambiguity.
For example, before this patch, consider these two NEC messages:
NEC16 message to address 0x05, command 0x03
NEC24 message to address 0x0005, command 0x03
They'll both have scancode 0x0503, and there's no way to tell which
message was received.
In order to maintain backwards compatibility, some heuristics are added
in rc-main.c to convert scancodes to NEC32 as necessary when userspace
adds entries to the keytable using the regular input ioctls.
No conversion will be made for the newer "rc_keymap_entry" based ioctls
(see the next patch).
Signed-off-by: David Härdeman
---
drivers/media/rc/ir-nec-decoder.c| 26 ++
drivers/media/rc/rc-main.c | 54 +-
drivers/media/usb/dvb-usb-v2/af9015.c| 22 ++--
drivers/media/usb/dvb-usb-v2/af9035.c| 25 +++---
drivers/media/usb/dvb-usb-v2/az6007.c| 16 ++---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 20 +++
drivers/media/usb/dvb-usb/dib0700_core.c | 24 +++--
drivers/media/usb/em28xx/em28xx-input.c | 37 +
include/media/rc-map.h | 16 +++--
9 files changed, 102 insertions(+), 138 deletions(-)
diff --git a/drivers/media/rc/ir-nec-decoder.c
b/drivers/media/rc/ir-nec-decoder.c
index 7b81fec..16907c1 100644
--- a/drivers/media/rc/ir-nec-decoder.c
+++ b/drivers/media/rc/ir-nec-decoder.c
@@ -50,7 +50,6 @@ static int ir_nec_decode(struct rc_dev *dev, struct
ir_raw_event ev)
struct nec_dec *data = &dev->raw->nec;
u32 scancode;
u8 address, not_address, command, not_command;
- bool send_32bits = false;
if (!(dev->enabled_protocols & RC_BIT_NEC))
return 0;
@@ -163,28 +162,9 @@ static int ir_nec_decode(struct rc_dev *dev, struct
ir_raw_event ev)
command = bitrev8((data->bits >> 8) & 0xff);
not_command = bitrev8((data->bits >> 0) & 0xff);
- if ((command ^ not_command) != 0xff) {
- IR_dprintk(1, "NEC checksum error: received 0x%08x\n",
- data->bits);
- send_32bits = true;
- }
-
- if (send_32bits) {
- /* NEC transport, but modified protocol, used by at
-* least Apple and TiVo remotes */
- scancode = data->bits;
- IR_dprintk(1, "NEC (modified) scancode 0x%08x\n",
scancode);
- } else if ((address ^ not_address) != 0xff) {
- /* Extended NEC */
- scancode = address << 16 |
- not_address << 8 |
- command;
- IR_dprintk(1, "NEC (Ext) scancode 0x%06x\n", scancode);
- } else {
- /* Normal NEC */
- scancode = address << 8 | command;
- IR_dprintk(1, "NEC scancode 0x%04x\n", scancode);
- }
+ scancode = RC_SCANCODE_NEC32(address << 24 | not_address << 16 |
+command << 8 | not_command);
+ IR_dprintk(1, "NEC scancode 0x%08x\n", scancode);
if (data->is_nec_x)
data->necx_repeat = true;
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index d068c4e..3379379 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -317,6 +317,49 @@ static unsigned int ir_establish_scancode(struct rc_dev
*dev,
}
/**
+ * guess_protocol() - heuristics to guess the protocol for a scancode
+ * @rdev: the struct rc_dev device descriptor
+ * @return:the guessed RC_TYPE_* protocol
+ *
+ * Internal routine to guess the current IR protocol for legacy ioctls.
+ */
+static inline enum rc_type guess_protocol(struct rc_dev *rdev)
+{
+ struct rc_map *rc_map = &rdev->rc_map;
+
+ if (hweight64(rdev->enabled_protocols) == 1)
+ return rc_bitmap_to_type(rdev->enabled_protocols);
+ else if (hweight64(rdev->allowed_protocols) == 1)
+ return rc_bitmap_to_type(rdev->allowed_protocols);
+ else
+ return rc_map->rc_type;
+}
+
+/**
+ * to_nec32() - helper function to try to convert misc NEC scancodes to NEC32
+ * @orig: original scancode
+ * @return:NEC32 scancode
+ *
+ * This helper routine is used to provide backwards compatibility.
+ */
+static u64 to_nec32(u64 orig)
+{
+ u8 b3 = (u8)(orig >> 16);
+ u8 b2 = (u8)(orig >> 8);
+ u8 b1 = (u8)(orig >> 0);
+
+ if (orig <= 0x)
+ /* Plain old NEC */
+ retur
[PATCH 2/2] rc-core: don't throw away protocol information
It is currently impossible to distinguish between scancodes which have
been generated using different protocols (and scancodes can, and will,
overlap).
For example:
RC5 message to address 0x00, command 0x03 has scancode 0x0503
JVC message to address 0x00, command 0x03 has scancode 0x0503
It is only possible to distinguish (and parse) scancodes by known the
scancode *and* the protocol.
Setting and getting keycodes in the input subsystem used to be done via
the EVIOC[GS]KEYCODE ioctl and "unsigned int[2]" (one int for scancode
and one for the keycode).
The interface has now been extended to use the EVIOC[GS]KEYCODE_V2 ioctl
which uses the following struct:
struct input_keymap_entry {
__u8 flags;
__u8 len;
__u16 index;
__u32 keycode;
__u8 scancode[32];
};
(scancode can of course be even bigger, thanks to the len member).
This patch changes how the "input_keymap_entry" struct is interpreted
by rc-core by casting it to "rc_keymap_entry":
struct rc_scancode {
__u16 protocol;
__u16 reserved[3];
__u64 scancode;
}
struct rc_keymap_entry {
__u8 flags;
__u8 len;
__u16 index;
__u32 keycode;
union {
struct rc_scancode rc;
__u8 raw[32];
};
};
The u64 scancode member is large enough for all current protocols and it
would be possible to extend it in the future should it be necessary for
some exotic protocol.
The main advantage with this change is that the protocol is made explicit,
which means that we're not throwing away data (the protocol type).
This also means that struct rc_map no longer hardcodes the protocol, meaning
that keytables with mixed entries are possible.
Heuristics are also added to hopefully do the right thing with older
ioctls in order to preserve backwards compatibility.
Signed-off-by: David Härdeman
---
drivers/media/rc/ati_remote.c |1
drivers/media/rc/imon.c |7 +
drivers/media/rc/rc-main.c| 196 +
include/media/rc-core.h | 26 +
include/media/rc-map.h|7 +
5 files changed, 172 insertions(+), 65 deletions(-)
diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c
index a356318..a1df608 100644
--- a/drivers/media/rc/ati_remote.c
+++ b/drivers/media/rc/ati_remote.c
@@ -544,6 +544,7 @@ static void ati_remote_input_report(struct urb *urb)
* set, assume this is a scrollwheel up/down event.
*/
wheel_keycode = rc_g_keycode_from_table(ati_remote->rdev,
+ RC_TYPE_OTHER,
scancode & 0x78);
if (wheel_keycode == KEY_RESERVED) {
diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
index 65f80b8..ec4414a 100644
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -1263,14 +1263,15 @@ static u32 imon_remote_key_lookup(struct imon_context
*ictx, u32 scancode)
bool is_release_code = false;
/* Look for the initial press of a button */
- keycode = rc_g_keycode_from_table(ictx->rdev, scancode);
+ keycode = rc_g_keycode_from_table(ictx->rdev, ictx->rc_type, scancode);
ictx->rc_toggle = 0x0;
ictx->rc_scancode = scancode;
/* Look for the release of a button */
if (keycode == KEY_RESERVED) {
release = scancode & ~0x4000;
- keycode = rc_g_keycode_from_table(ictx->rdev, release);
+ keycode = rc_g_keycode_from_table(ictx->rdev, ictx->rc_type,
+ release);
if (keycode != KEY_RESERVED)
is_release_code = true;
}
@@ -1299,7 +1300,7 @@ static u32 imon_mce_key_lookup(struct imon_context *ictx,
u32 scancode)
scancode = scancode | MCE_KEY_MASK | MCE_TOGGLE_BIT;
ictx->rc_scancode = scancode;
- keycode = rc_g_keycode_from_table(ictx->rdev, scancode);
+ keycode = rc_g_keycode_from_table(ictx->rdev, ictx->rc_type, scancode);
/* not used in mce mode, but make sure we know its false */
ictx->release_code = false;
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 3379379..52b792d 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -103,7 +103,7 @@ EXPORT_SYMBOL_GPL(rc_map_unregister);
static struct rc_map_table empty[] = {
- { 0x2a, KEY_COFFEE },
+ { RC_TYPE_OTHER, 0x2a, KEY_COFFEE },
};
static struct rc_map_list empty_map = {
@@ -119,7 +119,6 @@ static struct rc_map_list empty_map = {
* ir_create_table() - initializes a scancode table
* @rc_map:the rc_map to initialize
* @name: name to assign to the table
- * @rc_type: ir type to assign to the new table
* @size: initial size of the table
* @return:zero on success or a neg
Re: [PATCH v2 1/4] break kconfig dependency loop
On Wed, 2015-04-01 at 16:47 +0300, Jani Nikula wrote: > I think part of the problem is that "select" is often used not as > documented [1] but rather as "show my config in menuconfig for > convenience even if my dependency is not met, and select the dependency > even though I know it can screw up the dependency chain". Perhaps people use select because it offers, given the problem they face, a reasonable way to make the kconfig tools generate a sensible .config. It helps them to spend less time fiddling with Kconfig files. And they expect that it helps others to configure their build more easily, as it might save those others some work. > In the big picture, it feels like menuconfig needs a way to display > items whose dependencies are not met, and a way to recursively enable > said items and all their dependencies when told. How could that work its way through (multiple levels of) things like: depends on FOO || (BAZ && BAR) > This would reduce the > resistance to sticking with "select" when clearly "depends" is what's > meant. I had drafted a rather verbose response to this. But I think I'm not really sure what you're saying here, probably because "select" and "depends on" are rather different. How would you know that the actual intention was to use "depends on"? Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Please let me know if you need to print color box, display box and labels
Hi, this is David Wu from Shanghai, China. Please let me know if you need color box, display box, corrugated box, label, hang tag etc. I will send you the website. Best regards, David Wu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
