Re: [PATCH v1.1 14/15] omap3isp: Add support for the Device Tree
Hi Sakari,
Thank you for the patch. This looks good to me, except that there's one last
bug I've spotted. Please see below.
On Saturday 21 March 2015 00:05:04 Sakari Ailus wrote:
> Add the ISP device to omap3 DT include file and add support to the driver to
> use it.
>
> Also obtain information on the external entities and the ISP configuration
> related to them through the Device Tree in addition to the platform data.
>
> Signed-off-by: Sakari Ailus
> ---
> since v1:
>
> - Print endpoint name in debug message when parsing an endpoint.
>
> - Rename lane-polarity property as lane-polarities.
>
> - Print endpoint name with the interface if the interface is invalid.
>
> - Remove assignment to two variables at the same time.
>
> - Fix multiple sub-device support in isp_of_parse_nodes().
>
> - Put of_node properly in isp_of_parse_nodes() (requires Philipp Zabel's
> patch "of: Decrement refcount of previous endpoint in
> of_graph_get_next_endpoint".
>
> - Rename return value variable rval as ret to be consistent with the rest of
> the driver.
>
> - Read the register offset from the syscom property's first argument.
>
> drivers/media/platform/omap3isp/isp.c | 218 ++--
> drivers/media/platform/omap3isp/isp.h | 11 ++
> drivers/media/platform/omap3isp/ispcsiphy.c |7 +
> 3 files changed, 224 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c index 992e74c..92a859e 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
[snip]
> +static int isp_of_parse_nodes(struct device *dev,
> + struct v4l2_async_notifier *notifier)
> +{
> + struct device_node *node;
> +
> + notifier->subdevs = devm_kcalloc(
> + dev, ISP_MAX_SUBDEVS, sizeof(*notifier->subdevs), GFP_KERNEL);
> + if (!notifier->subdevs)
> + return -ENOMEM;
> +
> + while ((node = of_graph_get_next_endpoint(dev->of_node, node)) &&
> +notifier->num_subdevs < ISP_MAX_SUBDEVS) {
If the first condition evaluates to true and the second one to false, the loop
will be exited without releasing the reference to the DT node. You could just
switch the two conditions to fix this.
> + struct isp_async_subdev *isd;
> +
> + isd = devm_kzalloc(dev, sizeof(*isd), GFP_KERNEL);
> + if (!isd) {
> + of_node_put(node);
> + return -ENOMEM;
> + }
> +
> + notifier->subdevs[notifier->num_subdevs] = &isd->asd;
> +
> + if (isp_of_parse_node(dev, node, isd)) {
> + of_node_put(node);
> + return -EINVAL;
> + }
> +
> + isd->asd.match.of.node = of_graph_get_remote_port_parent(node);
> + of_node_put(node);
> + if (!isd->asd.match.of.node) {
> + dev_warn(dev, "bad remote port parent\n");
> + return -EINVAL;
> + }
> +
> + isd->asd.match_type = V4L2_ASYNC_MATCH_OF;
> + notifier->num_subdevs++;
> + }
> +
> + return notifier->num_subdevs;
> +}
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media-workshop] [ANN] Media Mini-Summit Draft Agenda for March 26th
Em Mon, 16 Mar 2015 12:25:28 +0100 Hans Verkuil escreveu: > This is the draft agenda for the media mini-summit in San Jose on March 26th. > > Time: 9 AM to 5 PM (approximately) > Room: TBC (Mauro, do you know this?) I'll check on this Monday with LF and wiĺl give you a feedback. > > Attendees: > > Mauro Carvalho Chehab - mche...@osg.samsung.com - Samsung > Laurent Pinchart - laurent.pinch...@ideasonboard.com - Ideas on board > Hans Verkuil - hverk...@xs4all.nl- Cisco > > Mauro, do you have a better overview of who else will attend? This time, we'll be using ELC registration site to track. I'll see how we can get this info with LF as well, but, as people can join it dynamically, the best is to get the list with them on Thursday evening, and double-check during the Summit to track last-minute changes. > > Agenda: > > Times are approximate and will likely change. > > 9:00-9:15 Get everyone installed, laptops hooked up, etc. > 9:15-9:30 Introduction > 9:30-10:30 Media Controller support for DVB (Mauro): > 1) dynamic creation/removal of pipelines > 2) change media_entity_pipeline_start to also define > the final entity > 3) how to setup pipelines that also envolve audio and DRM > 4) how to lock the media controller pipeline between enabling a > pipeline and starting it, in order to avoid race conditions > > See this post for more detailed information: > > https://www.mail-archive.com/linux-media@vger.kernel.org/msg85910.html Actually, there are two threads and two followup emails. The detailed info is at: https://www.mail-archive.com/linux-media@vger.kernel.org/msg85910.html https://www.mail-archive.com/linux-media@vger.kernel.org/msg85979.html https://www.mail-archive.com/linux-media@vger.kernel.org/msg83883.html https://www.mail-archive.com/linux-media@vger.kernel.org/msg83884.html I'll prepare a summary covering everything into a single file to make easier, and I'll prepare some slides with the topic highlights. > 10:30-10:45 Break > 10:45-12:00 Continue discussion > 12:00-13:00 Lunch (Mauro, do you have any idea whether there is a lunch > organized, > or if we are on our own?) I'm almost sure we are on our on for lunch. I'll double check this also with LF. > 13:00-14:40 Continue discussion > 14:40-15:00 Break > 15:00-16:00 Subdev hotplug in the context of both FPGA dynamic > reconfiguration and > project Ara (http://www.projectara.com/) (Laurent). > 16:00-17:00 Update on ongoing projects (Hans): > - proposal for Android Camera v3-type requests (aka > configuration stores) > - work on colorspace improvements > - vivid & v4l2-compliance improvements > - removing duplicate subdev video ops and use pad ops instead > - others? > > Most of the time will be spent on DVB and the MC. Based on past experience > this > likely will take some time to get a concensus. > > Comments are welcome! > > Regards, > > Hans > > ___ > media-workshop mailing list > media-works...@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
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: Mon Mar 23 04:00:14 CET 2015 git branch: test git hash: 3d945be05ac1e806af075e9315bc1b3409adae2b 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: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: OK linux-3.17.8-i686: OK linux-3.18.7-i686: OK linux-3.19-i686: OK linux-4.0-rc1-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB-T Receivers Latency
Hi Pier, On Sun, Mar 22, 2015 at 6:37 PM, pier@libero.it wrote: > Hello, > > I was wondering if anyone had any idea of how much latency a DVB-T receiver > can add, in the path between radiofrequency and the MPEG-TS stream. I have > 100ms of unwanted latency I can't explain in an application I'm developing, so > I was faulting either the tx modulator or the rx demodulator latency for it. > In > my specific case I'm using a 292e as receiver, that seems to have DSP filters > in it, and could very well be the cause of this tenth of a second delay. The receiver itself is unlikely to add any appreciable amount of latency. Those devices typically only have a few kilobytes of onboard SRAM for buffering to the USB host controller, enough to hold a couple of dozen packets. For a stream that is measured in Mbit/second, it's a trivial amount of buffering. If we're talking about latency introduced by the DSP doing demodulation, we would be measuring latency in microseconds, not tens or hundreds of milliseconds. It's much more likely any buffering you are seeing which is introducing latency is in either the driver, the DVB core, or the application itself. I don't know how you are measuring, but if you're actually *watching* the video as a means of measuring latency, then the latency is almost certainly in the MPEG decoder. If you're using instrumentation though that looks at the actual MPEG packets, then it's likely you would have already ruled that out. > I was going to buy a couple more receivers to measure the differences, but I > was wondering if anyone had any analytic input before wasting money that way. I wouldn't bother. All of the USB devices are going to provide comparable behavior. The PCI/PCIe devices if anything are going to have a higher latency because they might have shared memory for the ring buffers, and thus can have a much larger FIFO. There is likely tuning you can do to reduce the latency, but it's all in the kernel and software stack, not the DVB-T receiver hardware itself. If you can describe your methodology for how you are measuring latency in greater detail, I might be able to point you in the right direction. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] [media] mantis: fix error handling
Good, but still a couple nits.
On Sun, Mar 22, 2015 at 06:16:18PM +0100, Silvan Jegen wrote:
> --- a/drivers/media/pci/mantis/mantis_cards.c
> +++ b/drivers/media/pci/mantis/mantis_cards.c
> @@ -170,7 +170,7 @@ static int mantis_pci_probe(struct pci_dev *pdev,
> if (mantis == NULL) {
> printk(KERN_ERR "%s ERROR: Out of memory\n", __func__);
> err = -ENOMEM;
> - goto fail0;
> + return err;
Just:
return -ENOMEM;
> }
>
> mantis->num = devs;
> @@ -183,70 +183,69 @@ static int mantis_pci_probe(struct pci_dev *pdev,
> err = mantis_pci_init(mantis);
> if (err) {
> dprintk(MANTIS_ERROR, 1, "ERROR: Mantis PCI initialization
> failed <%d>", err);
> - goto fail1;
> + goto err_free_mantis;
> }
>
> err = mantis_stream_control(mantis, STREAM_TO_HIF);
> if (err < 0) {
> dprintk(MANTIS_ERROR, 1, "ERROR: Mantis stream control failed
> <%d>", err);
> - goto fail1;
> + goto err_pci_exit;
> }
>
> err = mantis_i2c_init(mantis);
> if (err < 0) {
> dprintk(MANTIS_ERROR, 1, "ERROR: Mantis I2C initialization
> failed <%d>", err);
> - goto fail2;
> + goto err_pci_exit;
> }
>
> err = mantis_get_mac(mantis);
> if (err < 0) {
> dprintk(MANTIS_ERROR, 1, "ERROR: Mantis MAC address read failed
> <%d>", err);
> - goto fail2;
> + goto err_i2c_exit;
> }
>
> err = mantis_dma_init(mantis);
> if (err < 0) {
> dprintk(MANTIS_ERROR, 1, "ERROR: Mantis DMA initialization
> failed <%d>", err);
> - goto fail3;
> + goto err_i2c_exit;
> }
>
> err = mantis_dvb_init(mantis);
> if (err < 0) {
> dprintk(MANTIS_ERROR, 1, "ERROR: Mantis DVB initialization
> failed <%d>", err);
> - goto fail4;
> + goto err_dma_exit;
> }
> +
> err = mantis_uart_init(mantis);
> if (err < 0) {
> dprintk(MANTIS_ERROR, 1, "ERROR: Mantis UART initialization
> failed <%d>", err);
> - goto fail6;
> + goto err_dvb_exit;
> }
>
> devs++;
>
> return err;
return 0;
That was in the original, but let's just clean it up as well.
>
> +err_dvb_exit:
> + dprintk(MANTIS_ERROR, 1, "ERROR: Mantis DVB exit! <%d>", err);
> + mantis_dvb_exit(mantis);
>
> - dprintk(MANTIS_ERROR, 1, "ERROR: Mantis UART exit! <%d>", err);
> - mantis_uart_exit(mantis);
> -
> -fail6:
> -fail4:
> +err_dma_exit:
> dprintk(MANTIS_ERROR, 1, "ERROR: Mantis DMA exit! <%d>", err);
> mantis_dma_exit(mantis);
>
> -fail3:
> +err_i2c_exit:
> dprintk(MANTIS_ERROR, 1, "ERROR: Mantis I2C exit! <%d>", err);
> mantis_i2c_exit(mantis);
>
> -fail2:
> +err_pci_exit:
> dprintk(MANTIS_ERROR, 1, "ERROR: Mantis PCI exit! <%d>", err);
> mantis_pci_exit(mantis);
>
> -fail1:
> +err_free_mantis:
> dprintk(MANTIS_ERROR, 1, "ERROR: Mantis free! <%d>", err);
> kfree(mantis);
Remove all these dprintks in the error handling.
regards,
dan carpenter
--
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
DVB-T Receivers Latency
Hello, I was wondering if anyone had any idea of how much latency a DVB-T receiver can add, in the path between radiofrequency and the MPEG-TS stream. I have 100ms of unwanted latency I can't explain in an application I'm developing, so I was faulting either the tx modulator or the rx demodulator latency for it. In my specific case I'm using a 292e as receiver, that seems to have DSP filters in it, and could very well be the cause of this tenth of a second delay. I was going to buy a couple more receivers to measure the differences, but I was wondering if anyone had any analytic input before wasting money that way. Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 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 70fa7b7..dc468de 100644
--- a/include/media/v4l2-of.h
+++ b/include/media/v4l2-of.h
@@ -54,7 +54,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;
@@ -63,7 +62,6 @@ struct v4l2_of_endpoint {
struct v4l2_of_bus_parallel parallel;
struct v4l2_of_bus_mipi_csi2 mipi_csi2;
} bus;
- struct list_head head;
};
#ifdef CONFIG_OF
--
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 v2 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 b4ed9a9..1c3e398 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -128,8 +128,9 @@ int v4l2_of_parse_endpoint(const struct device_node *node,
struct v4l2_of_endpoint *endpoint)
{
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));
v4l2_of_parse_csi_bus(node, endpoint);
/*
diff --git a/include/media/v4l2-of.h b/include/media/v4l2-of.h
index dc468de..00eec26 100644
--- a/include/media/v4l2-of.h
+++ b/include/media/v4l2-of.h
@@ -57,6 +57,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
[PATCH v2 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 ecae76b..a6c2dab 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 v2 0/4] Add link-frequencies to struct v4l2_of_endpoint
Hi, I've split off the third and obviously somewhat problematic patch in the set, and sent a pull req containing the first two patches and another dependent patch: http://www.spinics.net/lists/linux-media/msg88033.html> The changes intend to address the review comments I gathered the last time. The third patch of set 1 has been split into three, with the major differences being that - the interface functions are now called v4l2_of_alloc_parse_endpoint() and v4l2_of_free_endpoint(), - v4l2_of_alloc_parse_endpoint() will allocate and return struct v4l2_of_endpoint. Correspondingly v4l2_of_free_endpoint() will release it, - the usage pattern of existing users is unchanged, however new drivers are adviced to use the new interface. The old interface could be removed at some point when it no longer has users, however it is not urgent in any way. v1 can be found here: http://www.spinics.net/lists/linux-media/msg87479.html> Comments are very welcome. -- Kind 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 v2 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 1c3e398..e092c72 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
@@ -122,6 +123,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,
@@ -143,3 +148,86 @@ int v4l2_of_parse_endpoint(const struct device_node *node,
return 0;
}
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", endpo
Re: [PATCH 1/1] mn88473: implement lock for all delivery systems
On 03/22/2015 06:02 PM, Benjamin Larsson wrote: Now it works. Next time I really expect you will test your patches somehow before sending. Now I tested 3 different patch versions, find 2 first to be broken and last one working. It took around 2 hours of my time. Patch applied. Antti Yeah, my bad. Next I want to move the driver out of staging. What do I need to fix to make it suitable for the main tree ? There is locking code for both 88472 and 88473. There is a workaround for the I2C errors. The r820t is now able to receive dvb-c at frequencies around 300MHz. So I think all TODO's are taken care of. Is it inly the missing register I/O checks left ? I think technically it is in a condition that it could be moved out from stating. There is surely a lot of things that could be done better or improve, but all the must be fixed things are fixed. regards Antti -- 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: [PATCH v2] [media] mantis: fix error handling
Am 22.03.2015 18:16, schrieb Silvan Jegen:
> Remove dead code, make goto label names more expressive and add a label
> in order to call mantis_dvb_exit if mantis_uart_init fails.
>
> Also make sure that mantis_pci_exit is called if we fail the
> mantis_stream_control call and that we call mantis_i2c_exit if
> mantis_get_mac fails.
>
> Signed-off-by: Silvan Jegen
> ---
> V2 Changes (due to Dan Carpenter's review):
> - Remove dead code, do not activate it
> - Make goto labels more expressive
> - Add a call to mantis_dvb_exit
>
> drivers/media/pci/mantis/mantis_cards.c | 33
> -
> 1 file changed, 16 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/media/pci/mantis/mantis_cards.c
> b/drivers/media/pci/mantis/mantis_cards.c
> index 801fc55..70df61e 100644
> --- a/drivers/media/pci/mantis/mantis_cards.c
> +++ b/drivers/media/pci/mantis/mantis_cards.c
> @@ -170,7 +170,7 @@ static int mantis_pci_probe(struct pci_dev *pdev,
> if (mantis == NULL) {
> printk(KERN_ERR "%s ERROR: Out of memory\n", __func__);
> err = -ENOMEM;
> - goto fail0;
> + return err;
> }
>
> mantis->num = devs;
> @@ -183,70 +183,69 @@ static int mantis_pci_probe(struct pci_dev *pdev,
> err = mantis_pci_init(mantis);
> if (err) {
> dprintk(MANTIS_ERROR, 1, "ERROR: Mantis PCI initialization
> failed <%d>", err);
> - goto fail1;
> + goto err_free_mantis;
> }
>
> err = mantis_stream_control(mantis, STREAM_TO_HIF);
> if (err < 0) {
> dprintk(MANTIS_ERROR, 1, "ERROR: Mantis stream control failed
> <%d>", err);
> - goto fail1;
> + goto err_pci_exit;
> }
>
> err = mantis_i2c_init(mantis);
> if (err < 0) {
> dprintk(MANTIS_ERROR, 1, "ERROR: Mantis I2C initialization
> failed <%d>", err);
> - goto fail2;
> + goto err_pci_exit;
> }
>
> err = mantis_get_mac(mantis);
> if (err < 0) {
> dprintk(MANTIS_ERROR, 1, "ERROR: Mantis MAC address read failed
> <%d>", err);
> - goto fail2;
> + goto err_i2c_exit;
> }
>
> err = mantis_dma_init(mantis);
> if (err < 0) {
> dprintk(MANTIS_ERROR, 1, "ERROR: Mantis DMA initialization
> failed <%d>", err);
> - goto fail3;
> + goto err_i2c_exit;
> }
>
> err = mantis_dvb_init(mantis);
> if (err < 0) {
> dprintk(MANTIS_ERROR, 1, "ERROR: Mantis DVB initialization
> failed <%d>", err);
> - goto fail4;
> + goto err_dma_exit;
> }
> +
> err = mantis_uart_init(mantis);
> if (err < 0) {
> dprintk(MANTIS_ERROR, 1, "ERROR: Mantis UART initialization
> failed <%d>", err);
> - goto fail6;
> + goto err_dvb_exit;
> }
>
> devs++;
>
> return err;
>
Hi Silvan Jegen,
i found the dprintk() a bit confusing, if i understand the code correctly it
will always print on error:
the dprintf found in if (err<0) like :
dprintk(MANTIS_ERROR, 1, "ERROR: Mantis DVB initialization failed <%d>", err);
and then
dprintk(MANTIS_ERROR, 1, "ERROR: Mantis DVB exit! <%d>", err);
maybe this is more a question for the maintainer, but this seems a bit useless.
re,
wh
> +err_dvb_exit:
> + dprintk(MANTIS_ERROR, 1, "ERROR: Mantis DVB exit! <%d>", err);
> + mantis_dvb_exit(mantis);
>
> - dprintk(MANTIS_ERROR, 1, "ERROR: Mantis UART exit! <%d>", err);
> - mantis_uart_exit(mantis);
> -
> -fail6:
> -fail4:
> +err_dma_exit:
> dprintk(MANTIS_ERROR, 1, "ERROR: Mantis DMA exit! <%d>", err);
> mantis_dma_exit(mantis);
>
> -fail3:
> +err_i2c_exit:
> dprintk(MANTIS_ERROR, 1, "ERROR: Mantis I2C exit! <%d>", err);
> mantis_i2c_exit(mantis);
>
> -fail2:
> +err_pci_exit:
> dprintk(MANTIS_ERROR, 1, "ERROR: Mantis PCI exit! <%d>", err);
> mantis_pci_exit(mantis);
>
> -fail1:
> +err_free_mantis:
> dprintk(MANTIS_ERROR, 1, "ERROR: Mantis free! <%d>", err);
> kfree(mantis);
>
> -fail0:
> return err;
> }
>
--
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/1] [media] DocBook media: fix broken EIA hyperlink
This fixes the bibliography hyperlink to "http://www.eia.org"; which now redirects to a page with a "404 Not found" error. The latest update to the document referred to is now available on the Consumer Electronics Association website. Signed-off-by: Michael Opdenacker --- Documentation/DocBook/media/v4l/biblio.xml | 11 +-- Documentation/DocBook/media/v4l/dev-sliced-vbi.xml | 2 +- Documentation/DocBook/media/v4l/vidioc-g-sliced-vbi-cap.xml | 2 +- 3 files changed, 7 insertions(+), 8 deletions(-) diff --git a/Documentation/DocBook/media/v4l/biblio.xml b/Documentation/DocBook/media/v4l/biblio.xml index 7ff01a23c2fe..fdee6b3f3eca 100644 --- a/Documentation/DocBook/media/v4l/biblio.xml +++ b/Documentation/DocBook/media/v4l/biblio.xml @@ -1,14 +1,13 @@ References - - EIA 608-B + + CEA 608-E - Electronic Industries Alliance (http://www.eia.org";>http://www.eia.org) + Consumer Electronics Association (http://www.ce.org";>http://www.ce.org) - EIA 608-B "Recommended Practice for Line 21 Data -Service" + CEA-608-E R-2014 "Line 21 Data Services" diff --git a/Documentation/DocBook/media/v4l/dev-sliced-vbi.xml b/Documentation/DocBook/media/v4l/dev-sliced-vbi.xml index 7a8bf3011ee9..0aec62ed2bf8 100644 --- a/Documentation/DocBook/media/v4l/dev-sliced-vbi.xml +++ b/Documentation/DocBook/media/v4l/dev-sliced-vbi.xml @@ -254,7 +254,7 @@ ETS 300 231, lsb first transmitted. V4L2_SLICED_CAPTION_525 0x1000 - + NTSC line 21, 284 (second field 21) Two bytes in transmission order, including parity bit, lsb first transmitted. diff --git a/Documentation/DocBook/media/v4l/vidioc-g-sliced-vbi-cap.xml b/Documentation/DocBook/media/v4l/vidioc-g-sliced-vbi-cap.xml index bd015d1563ff..d05623c55403 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-sliced-vbi-cap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-sliced-vbi-cap.xml @@ -205,7 +205,7 @@ ETS 300 231, lsb first transmitted. V4L2_SLICED_CAPTION_525 0x1000 - + NTSC line 21, 284 (second field 21) Two bytes in transmission order, including parity bit, lsb first transmitted. -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/1] DocBook media: fix broken EIA hyperlink
Hi, This is a fix for the only broken link in kernel documentation, at least according to the "linkchecker" tool that we are running on the Free Electrons website once a day. As kernel documentation is part of our website (on http://free-electrons.com/kerneldoc/), I get reminded of this broken link once a day! Michael. Michael Opdenacker (1): [media] DocBook media: fix broken EIA hyperlink Documentation/DocBook/media/v4l/biblio.xml | 11 +-- Documentation/DocBook/media/v4l/dev-sliced-vbi.xml | 2 +- Documentation/DocBook/media/v4l/vidioc-g-sliced-vbi-cap.xml | 2 +- 3 files changed, 7 insertions(+), 8 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] [media] mantis: fix error handling
Remove dead code, make goto label names more expressive and add a label
in order to call mantis_dvb_exit if mantis_uart_init fails.
Also make sure that mantis_pci_exit is called if we fail the
mantis_stream_control call and that we call mantis_i2c_exit if
mantis_get_mac fails.
Signed-off-by: Silvan Jegen
---
V2 Changes (due to Dan Carpenter's review):
- Remove dead code, do not activate it
- Make goto labels more expressive
- Add a call to mantis_dvb_exit
drivers/media/pci/mantis/mantis_cards.c | 33 -
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/drivers/media/pci/mantis/mantis_cards.c
b/drivers/media/pci/mantis/mantis_cards.c
index 801fc55..70df61e 100644
--- a/drivers/media/pci/mantis/mantis_cards.c
+++ b/drivers/media/pci/mantis/mantis_cards.c
@@ -170,7 +170,7 @@ static int mantis_pci_probe(struct pci_dev *pdev,
if (mantis == NULL) {
printk(KERN_ERR "%s ERROR: Out of memory\n", __func__);
err = -ENOMEM;
- goto fail0;
+ return err;
}
mantis->num = devs;
@@ -183,70 +183,69 @@ static int mantis_pci_probe(struct pci_dev *pdev,
err = mantis_pci_init(mantis);
if (err) {
dprintk(MANTIS_ERROR, 1, "ERROR: Mantis PCI initialization
failed <%d>", err);
- goto fail1;
+ goto err_free_mantis;
}
err = mantis_stream_control(mantis, STREAM_TO_HIF);
if (err < 0) {
dprintk(MANTIS_ERROR, 1, "ERROR: Mantis stream control failed
<%d>", err);
- goto fail1;
+ goto err_pci_exit;
}
err = mantis_i2c_init(mantis);
if (err < 0) {
dprintk(MANTIS_ERROR, 1, "ERROR: Mantis I2C initialization
failed <%d>", err);
- goto fail2;
+ goto err_pci_exit;
}
err = mantis_get_mac(mantis);
if (err < 0) {
dprintk(MANTIS_ERROR, 1, "ERROR: Mantis MAC address read failed
<%d>", err);
- goto fail2;
+ goto err_i2c_exit;
}
err = mantis_dma_init(mantis);
if (err < 0) {
dprintk(MANTIS_ERROR, 1, "ERROR: Mantis DMA initialization
failed <%d>", err);
- goto fail3;
+ goto err_i2c_exit;
}
err = mantis_dvb_init(mantis);
if (err < 0) {
dprintk(MANTIS_ERROR, 1, "ERROR: Mantis DVB initialization
failed <%d>", err);
- goto fail4;
+ goto err_dma_exit;
}
+
err = mantis_uart_init(mantis);
if (err < 0) {
dprintk(MANTIS_ERROR, 1, "ERROR: Mantis UART initialization
failed <%d>", err);
- goto fail6;
+ goto err_dvb_exit;
}
devs++;
return err;
+err_dvb_exit:
+ dprintk(MANTIS_ERROR, 1, "ERROR: Mantis DVB exit! <%d>", err);
+ mantis_dvb_exit(mantis);
- dprintk(MANTIS_ERROR, 1, "ERROR: Mantis UART exit! <%d>", err);
- mantis_uart_exit(mantis);
-
-fail6:
-fail4:
+err_dma_exit:
dprintk(MANTIS_ERROR, 1, "ERROR: Mantis DMA exit! <%d>", err);
mantis_dma_exit(mantis);
-fail3:
+err_i2c_exit:
dprintk(MANTIS_ERROR, 1, "ERROR: Mantis I2C exit! <%d>", err);
mantis_i2c_exit(mantis);
-fail2:
+err_pci_exit:
dprintk(MANTIS_ERROR, 1, "ERROR: Mantis PCI exit! <%d>", err);
mantis_pci_exit(mantis);
-fail1:
+err_free_mantis:
dprintk(MANTIS_ERROR, 1, "ERROR: Mantis free! <%d>", err);
kfree(mantis);
-fail0:
return err;
}
--
2.3.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] mn88473: implement lock for all delivery systems
Now it works. Next time I really expect you will test your patches somehow before sending. Now I tested 3 different patch versions, find 2 first to be broken and last one working. It took around 2 hours of my time. Patch applied. Antti Yeah, my bad. Next I want to move the driver out of staging. What do I need to fix to make it suitable for the main tree ? There is locking code for both 88472 and 88473. There is a workaround for the I2C errors. The r820t is now able to receive dvb-c at frequencies around 300MHz. So I think all TODO's are taken care of. Is it inly the missing register I/O checks left ? MvH Benjamin Larsson -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Extend struct v4l2_fmtdesc to give more format info
Hi Hans,
On Fri, Mar 20, 2015 at 02:25:57PM +0100, Hans Verkuil wrote:
> This is a proposal to extend the information returned by v4l2_fmtdesc
> (VIDIOC_ENUM_FMT).
>
> Especially in combination with my previous RFC PATCH
> (https://patchwork.linuxtv.org/patch/28877/)
> this is very easy to fill in correctly in the core, and it will help both
> drivers and
> applications.
>
> It is very common that you need to know whether the format is for rgb,
> greyscale or YUV,
> whether a format is only supported with the multiplanar API or not (useful
> for the
> libv4l-mplane plugin to avoid enumerating multiplanar formats), whether there
> is an
> alpha channel, what the chroma subsampling format is and how planar formats
> are organized.
>
>
> struct v4l2_fmtdesc {
> __u32 index; /* Format number */
> __u32 type; /* enum v4l2_buf_type */
> __u32 flags;
> __u8description[32];/* Description string */
> __u32 pixelformat;/* Format fourcc */
> __u8color_encoding; /* Color encoding */
> __u8chroma_subsampling; /* Chroma subsampling */
> __u8planar; /* Planar format organization */
> __u8reserved2;
> __u32 reserved[3];
> };
>
> #define V4L2_FMT_FLAG_COMPRESSED 0x0001
> #define V4L2_FMT_FLAG_EMULATED 0x0002
> #define V4L2_FMT_FLAG_IS_MPLANE 0x0004
> #define V4L2_FMT_FLAG_HAS_ALPHA 0x0008
>
> #define V4L2_FMT_COLOR_ENC_UNKNOWN 0
> #define V4L2_FMT_COLOR_ENC_RGB 1
> #define V4L2_FMT_COLOR_ENC_GREY 2
> #define V4L2_FMT_COLOR_ENC_YCBCR3
>
> #define V4L2_FMT_CHROMA_UNKNOWN 0
> #define V4L2_FMT_CHROMA_4_4_4 1
> #define V4L2_FMT_CHROMA_4_2_2 2
> #define V4L2_FMT_CHROMA_4_2_0 3
> #define V4L2_FMT_CHROMA_4_1_1 4
> #define V4L2_FMT_CHROMA_4_1_0 5
>
> #define V4L2_FMT_PLANAR_UNKNOWN 0
> #define V4L2_FMT_PLANAR_NONE 1 /* not a planar format */
> #define V4L2_FMT_PLANAR_Y_CBCR 2 /* one luma, one packed chroma
> plane */
> #define V4L2_FMT_PLANAR_Y_CB_CR 3 /* one luma and two chroma
> planes */
>
> For compressed formats color_encoding, chroma_subsampling and planar are all
> set to 0.
>
> Using this information helps both drivers and applications to calculate the
> bytesperline values and offsets of each plane for formats like PIX_FMT_YUV420.
>
> I've worked with this in vivid and in qv4l2, and it is a real pain without
> this information. Every driver and app needs to do the same calculations.
>
> It's trivial to add support for this in the v4l2 core.
How much of this is defined by the 4cc code already? Everything?
This is an interesting case. The information would likely be needed by both
applications and drivers but in the kernel API itself it's redundant, isn't
it?
> I am also considering adding a bits_per_pixel field. It is likely useful
> as an internal kernel helper function, but whether it helps applications
> is something I don't really know.
I think this would be nice to have. But like the others, I wonder if the
kernel API is the right place for this.
Do you have concrete examples (excluding the vivi driver) where drivers
would benefit from this in other than a trivial manner? I can imagine the
user space would though.
Just my 5 euro cents.
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1.1 14/15] omap3isp: Add support for the Device Tree
Hi Laurent, On Sat, Mar 21, 2015 at 12:05:04AM +0200, Sakari Ailus wrote: > Add the ISP device to omap3 DT include file and add support to the driver to > use it. > > Also obtain information on the external entities and the ISP configuration > related to them through the Device Tree in addition to the platform data. > > Signed-off-by: Sakari Ailus If you're happy with this version, please add the set to your tree. The patches can be also found in here, on top of your histogram DMA changes: ssh://linuxtv.org/git/sailus/media_tree.git rm696-054-media -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1.1 10/15] omap3isp: Move the syscon register out of the ISP register maps
The syscon register isn't part of the ISP, use it through the syscom driver
regmap instead. The syscom block is considered to be from 343x on ISP
revision 2.0 whereas 15.0 is assumed to have 3630 syscon.
Signed-off-by: Sakari Ailus
Acked-by: Laurent Pinchart
Acked-by: Tony Lindgren
---
since v1:
- Depend on MFD_SYSCON in Kconfig
arch/arm/mach-omap2/devices.c | 10 --
drivers/media/platform/Kconfig |1 +
drivers/media/platform/omap3isp/isp.c | 20
drivers/media/platform/omap3isp/isp.h | 19 +--
drivers/media/platform/omap3isp/ispcsiphy.c | 20 +---
5 files changed, 43 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1afb50d..e945957 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -143,16 +143,6 @@ static struct resource omap3isp_resources[] = {
.flags = IORESOURCE_MEM,
},
{
- .start = OMAP343X_CTRL_BASE + OMAP343X_CONTROL_CSIRXFE,
- .end= OMAP343X_CTRL_BASE + OMAP343X_CONTROL_CSIRXFE
+ 3,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP343X_CTRL_BASE +
OMAP3630_CONTROL_CAMERA_PHY_CTRL,
- .end= OMAP343X_CTRL_BASE +
OMAP3630_CONTROL_CAMERA_PHY_CTRL + 3,
- .flags = IORESOURCE_MEM,
- },
- {
.start = 24 + OMAP_INTC_START,
.flags = IORESOURCE_IRQ,
}
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 2e30be5..272dc8c 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -90,6 +90,7 @@ config VIDEO_OMAP3
select ARM_DMA_USE_IOMMU
select OMAP_IOMMU
select VIDEOBUF2_DMA_CONTIG
+ select MFD_SYSCON
---help---
Driver for an OMAP 3 camera controller.
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index 68d7edfc..83b4368 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -51,6 +51,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -94,8 +95,9 @@ static const struct isp_res_mapping isp_res_maps[] = {
1 << OMAP3_ISP_IOMEM_RESZ |
1 << OMAP3_ISP_IOMEM_SBL |
1 << OMAP3_ISP_IOMEM_CSI2A_REGS1 |
- 1 << OMAP3_ISP_IOMEM_CSIPHY2 |
- 1 << OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE,
+ 1 << OMAP3_ISP_IOMEM_CSIPHY2,
+ .syscon_offset = 0xdc,
+ .phy_type = ISP_PHY_TYPE_3430,
},
{
.isp_rev = ISP_REVISION_15_0,
@@ -112,8 +114,9 @@ static const struct isp_res_mapping isp_res_maps[] = {
1 << OMAP3_ISP_IOMEM_CSI2A_REGS2 |
1 << OMAP3_ISP_IOMEM_CSI2C_REGS1 |
1 << OMAP3_ISP_IOMEM_CSIPHY1 |
- 1 << OMAP3_ISP_IOMEM_CSI2C_REGS2 |
- 1 << OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL,
+ 1 << OMAP3_ISP_IOMEM_CSI2C_REGS2,
+ .syscon_offset = 0x2f0,
+ .phy_type = ISP_PHY_TYPE_3630,
},
};
@@ -2352,6 +2355,15 @@ static int isp_probe(struct platform_device *pdev)
}
}
+ isp->syscon = syscon_regmap_lookup_by_pdevname("syscon.0");
+ if (IS_ERR(isp->syscon)) {
+ ret = PTR_ERR(isp->syscon);
+ goto error_isp;
+ }
+
+ isp->syscon_offset = isp_res_maps[m].syscon_offset;
+ isp->phy_type = isp_res_maps[m].phy_type;
+
/* IOMMU */
ret = isp_attach_iommu(isp);
if (ret < 0) {
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h
index 9535524..03d2129 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -59,8 +59,6 @@ enum isp_mem_resources {
OMAP3_ISP_IOMEM_CSI2C_REGS1,
OMAP3_ISP_IOMEM_CSIPHY1,
OMAP3_ISP_IOMEM_CSI2C_REGS2,
- OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE,
- OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL,
OMAP3_ISP_IOMEM_LAST
};
@@ -93,14 +91,25 @@ enum isp_subclk_resource {
/* ISP2P: OMAP 36xx */
#define ISP_REVISION_15_0 0xF0
+#define ISP_PHY_TYPE_3430 0
+#define ISP_PHY_TYPE_3630 1
+
+struct regmap;
+
/*
* struct isp_res_mapping - Map ISP io resources to ISP revision.
* @isp_rev: ISP_REVISION_x_x
* @map: bitmap for enum isp_mem_resources
+ * @syscon_offset: offset of the syscon register for 343x / 3630
+ * (CONTROL_CSIRXFE / CONTROL_CAMERA_PHY_CTRL, respectively)
+ * from the syscon base address
+ * @phy_
Re: [RFC PATCH] v4l2-ioctl: fill in the description for VIDIOC_ENUM_FMT
On Fri, Mar 20, 2015 at 01:17:19PM +0100, Hans Verkuil wrote: > The descriptions used in drivers for the formats returned with ENUM_FMT > are all over the place. > > So instead allow the core to fill in the description and flags. This > allows drivers to drop the description and flags. > > If the format is not found in the list, and if the description field is > filled in, then just return but call WARN_ONCE to let developers know > that this list needs to be extended. > > Based on an earlier patch from Philipp Zabel: > http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/81411 > > But this patch moves the code into the core and away from drivers. > > Signed-off-by: Hans Verkuil > Cc: Philipp Zabel Nice patch! Acked-by: Sakari Ailus -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v4.1] smiapp OF fixes
Hi Mauro, The three patches contain first two cleanups and finally move the reading of link-frequencies property from the endpoint node where it is actually located. I've left the patch that adds link-frequencies reading to the V4L2 OF code out for it isn't necessary to get it in now. There will most likely be a few more versions of that. Please pull. The following changes since commit 3d945be05ac1e806af075e9315bc1b3409adae2b: [media] mn88473: simplify bandwidth registers setting code (2015-03-03 13:09:12 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git smiapp-of-fix for you to fetch changes up to 88458f8114b33627c23ef5e4b664b412d1db1591: smiapp: Read link-frequencies property from the endpoint node (2015-03-22 13:50:11 +0200) Sakari Ailus (3): smiapp: Use of_property_read_u64_array() to read a 64-bit number array smiapp: Clean up smiapp_get_pdata() smiapp: Read link-frequencies property from the endpoint node drivers/media/i2c/smiapp/smiapp-core.c | 36 +++- 1 file changed, 7 insertions(+), 29 deletions(-) -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 4.1] Astrometa / mn88472 / mn88473
Two fixes for r820t which I reviewed quite carefully and should be OK. mn88472 and mn88473 are staging demodulator drivers. regards Antti The following changes since commit 3d945be05ac1e806af075e9315bc1b3409adae2b: [media] mn88473: simplify bandwidth registers setting code (2015-03-03 13:09:12 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git astrometa for you to fetch changes up to 16c00dacdd0437c5a62b5db4329520bdbe5dd26c: mn88473: implement lock for all delivery systems (2015-03-22 13:25:18 +0200) Antti Palosaari (2): mn88473: define symbol rate limits mn88472: define symbol rate limits Benjamin Larsson (9): r820t: add DVBC profile in sysfreq_sel r820t: change read_gain() code to match register layout rtl28xxu: lower the rc poll time to mitigate i2c transfer errors mn88472: implement lock for all delivery systems mn88472: implement firmware parity check mn88473: implement firmware parity check mn88473: check if firmware is already running before loading it mn88472: check if firmware is already running before loading it mn88473: implement lock for all delivery systems drivers/media/tuners/r820t.c| 15 ++- drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 +- drivers/staging/media/mn88472/mn88472.c | 52 drivers/staging/media/mn88473/mn88473.c | 80 +--- 4 files changed, 140 insertions(+), 9 deletions(-) -- 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: [PATCH 1/1] mn88473: implement lock for all delivery systems
On 03/21/2015 12:18 PM, Benjamin Larsson wrote:
On 03/21/2015 12:25 AM, Antti Palosaari wrote:
On 03/21/2015 01:13 AM, Benjamin Larsson wrote:
On 03/19/2015 03:44 PM, Antti Palosaari wrote:
Bad news. It does lock for DVB-C now, but DVB-T nor DVB-T2 does not
lock.
regards
Antti
I'm getting tired :/. Had the time to test now and the checks is
supposed to be negated.
if (utmp & 0xA0) { -> if (!(utmp & 0xA0))
But as stock dvbv5-scan crashes on ubuntu 14.04 and I can't unload the
mn88473 module I will confirm this when I have an actual working version
of dvbv5-scan and Ubuntu.
You could also use w_scan. Or install latest dvbv5-scan from git - it
works even without install by running from compile directory.
Ok, will try that later.
Anyway, I tried the attached patch and I was able to get a lock after a
reboot from windows with the windows driver initializing the stick. If I
replugged the stick I get no signal and if I try the rtl2832 demod it
reports the same. So I think that my signal is just to weak for the
kernel r820t driver. So it would be nice if you could test this patch
and see if it works.
Now it works. Next time I really expect you will test your patches
somehow before sending. Now I tested 3 different patch versions, find 2
first to be broken and last one working. It took around 2 hours of my time.
Patch applied.
Antti
regards
Antti
MvH
Benjamin Larsson
--
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: [GIT FIXES FOR v3.20] Fix USERPTR buffers for vb2 dma-contig mem type
Ping. On Fri, Feb 13, 2015 at 12:16:11PM +0200, Sakari Ailus wrote: > Hi Mauro, > > This single patch fixes setting the write parameter to 1 for > get_user_pages() on writable buffers. Without this using USERPTR buffers > with the dma-contig mem type will corrupt system memory. > > This is directly applicable to fixes and master branches and should be > pulled into both. > > The following changes since commit 4bad5d2d25099a42e146d7b18d2b98950ed287f5: > > [media] dvb_net: Convert local hex dump to print_hex_dump_debug (2015-02-03 > 18:24:44 -0200) > > are available in the git repository at: > > ssh://linuxtv.org/git/sailus/media_tree.git vb2-fix > > for you to fetch changes up to 5a433fbc3ead7d65143bf039eb77512d0558e2e7: > > vb2: Fix dma_dir setting for dma-contig mem type (2015-02-13 12:14:31 +0200) > > > Sakari Ailus (1): > vb2: Fix dma_dir setting for dma-contig mem type > > drivers/media/v4l2-core/videobuf2-dma-contig.c |3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > -- > Kind regards, > > Sakari Ailus > e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1.1 13/15] v4l: of: Read lane-polarities endpoint property
Hi Sakari,
Thank you for the patch.
On Saturday 21 March 2015 00:08:15 Sakari Ailus wrote:
> Add lane_polarities field to struct v4l2_of_bus_mipi_csi2 and write the
> contents of the lane-polarities property to it. The field tells the polarity
> of the physical lanes starting from the first one. Any unused lanes are
> ignored, i.e. only the polarity of the used lanes is specified.
>
> Also rework reading the "data-lanes" property a little.
>
> Signed-off-by: Sakari Ailus
Acked-by: Laurent Pinchart
> ---
> since v1:
>
> - Rename lane-polarity property as lane-polarities.
>
> drivers/media/v4l2-core/v4l2-of.c | 41 ++
> include/media/v4l2-of.h |3 +++
> 2 files changed, 35 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-of.c
> b/drivers/media/v4l2-core/v4l2-of.c index b4ed9a9..58e401f 100644
> --- a/drivers/media/v4l2-core/v4l2-of.c
> +++ b/drivers/media/v4l2-core/v4l2-of.c
> @@ -19,11 +19,10 @@
>
> #include
>
> -static void v4l2_of_parse_csi_bus(const struct device_node *node,
> - struct v4l2_of_endpoint *endpoint)
> +static int v4l2_of_parse_csi_bus(const struct device_node *node,
> + struct v4l2_of_endpoint *endpoint)
> {
> struct v4l2_of_bus_mipi_csi2 *bus = &endpoint->bus.mipi_csi2;
> - u32 data_lanes[ARRAY_SIZE(bus->data_lanes)];
> struct property *prop;
> bool have_clk_lane = false;
> unsigned int flags = 0;
> @@ -32,16 +31,34 @@ static void v4l2_of_parse_csi_bus(const struct
> device_node *node, prop = of_find_property(node, "data-lanes", NULL);
> if (prop) {
> const __be32 *lane = NULL;
> - int i;
> + unsigned int i;
>
> - for (i = 0; i < ARRAY_SIZE(data_lanes); i++) {
> - lane = of_prop_next_u32(prop, lane, &data_lanes[i]);
> + for (i = 0; i < ARRAY_SIZE(bus->data_lanes); i++) {
> + lane = of_prop_next_u32(prop, lane, &v);
> if (!lane)
> break;
> + bus->data_lanes[i] = v;
> }
> bus->num_data_lanes = i;
> - while (i--)
> - bus->data_lanes[i] = data_lanes[i];
> + }
> +
> + prop = of_find_property(node, "lane-polarities", NULL);
> + if (prop) {
> + const __be32 *polarity = NULL;
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(bus->lane_polarities); i++) {
> + polarity = of_prop_next_u32(prop, polarity, &v);
> + if (!polarity)
> + break;
> + bus->lane_polarities[i] = v;
> + }
> +
> + if (i < 1 + bus->num_data_lanes /* clock + data */) {
> + pr_warn("%s: too few lane-polarities entries (need %u,
> got
%u)\n",
> + node->full_name, 1 + bus->num_data_lanes, i);
> + return -EINVAL;
> + }
> }
>
> if (!of_property_read_u32(node, "clock-lanes", &v)) {
> @@ -56,6 +73,8 @@ static void v4l2_of_parse_csi_bus(const struct device_node
> *node,
>
> bus->flags = flags;
> endpoint->bus_type = V4L2_MBUS_CSI2;
> +
> + return 0;
> }
>
> static void v4l2_of_parse_parallel_bus(const struct device_node *node,
> @@ -127,11 +146,15 @@ static void v4l2_of_parse_parallel_bus(const struct
> device_node *node, int v4l2_of_parse_endpoint(const struct device_node
> *node,
> struct v4l2_of_endpoint *endpoint)
> {
> + int rval;
> +
> of_graph_parse_endpoint(node, &endpoint->base);
> endpoint->bus_type = 0;
> memset(&endpoint->bus, 0, sizeof(endpoint->bus));
>
> - v4l2_of_parse_csi_bus(node, endpoint);
> + rval = v4l2_of_parse_csi_bus(node, endpoint);
> + if (rval)
> + return rval;
> /*
>* Parse the parallel video bus properties only if none
>* of the MIPI CSI-2 specific properties were found.
> diff --git a/include/media/v4l2-of.h b/include/media/v4l2-of.h
> index 70fa7b7..2de42c5 100644
> --- a/include/media/v4l2-of.h
> +++ b/include/media/v4l2-of.h
> @@ -29,12 +29,15 @@ struct device_node;
> * @data_lanes: an array of physical data lane indexes
> * @clock_lane: physical lane index of the clock lane
> * @num_data_lanes: number of data lanes
> + * @lane_polarities: polarity of the lanes. The order is the same of
> + * the physical lanes.
> */
> struct v4l2_of_bus_mipi_csi2 {
> unsigned int flags;
> unsigned char data_lanes[4];
> unsigned char clock_lane;
> unsigned short num_data_lanes;
> + bool lane_polarities[5];
> };
>
> /**
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo
