Few Doubts on adding DT nodes for bridge driver
Hi Sylwester, Guennadi,
I am working on adding DT support for VPIF driver, initially to get
some hands dirty
on working on Capture driver and later will move ahead to add for the display.
I have added asynchronous probing support for the both the bridge and subdevs
which works perfectly like on a charm with passing pdata as usually,
but doing the
same with DT I have few doubts on building the pdata in the bridge driver.
This is a snippet of my subdes in i2c node:-
i2c0: i2c@1c22000 {
status = "okay";
clock-frequency = <10>;
pinctrl-names = "default";
pinctrl-0 = <&i2c0_pins>;
tvp514x@5c {
compatible = "ti,tvp5146";
reg = <0x5c>;
port {
tvp514x_1: endpoint {
remote-endpoint =
<&vpif_capture0_1>;
hsync-active = <1>;
vsync-active = <1>;
pclk-sample = <0>;
};
};
};
tvp514x@5d {
compatible = "ti,tvp5146";
reg = <0x5d>;
port {
tvp514x_2: endpoint {
remote-endpoint =
<&vpif_capture0_0>;
hsync-active = <1>;
vsync-active = <1>;
pclk-sample = <0>;
};
};
};
..
};
Here tvp514x are the subdevs the platform has two of them one at 0x5c and 0x5d,
so I have added two nodes for them.
Following is DT node for the bridge driver:-
vpif_capture@0 {
status = "okay";
port {
vpif_capture0_1: endpoint@1 {
remote = <&tvp514x_1>;
};
vpif_capture0_0: endpoint@0 {
remote = <&tvp514x_2>;
};
};
};
I have added two endpoints for the bridge driver. In the bridge driver
to build the pdata from DT node,I do the following,
np = v4l2_of_get_next_endpoint(pdev->dev.of_node, NULL);
The above will give the first endpoint ie, endpoint@1
>From here is it possible to get the tvp514x_1 endpoint node and the
parent of it?
so that I build the asynchronous subdev list for the bridge driver.
+static struct v4l2_async_subdev tvp1_sd = {
+ .hw = {
+ .bus_type = V4L2_ASYNC_BUS_I2C,
+ .match.i2c = {
+ .adapter_id = 1,
+ .address = 0x5c,
+ },
+ },
+};
For building the asd subdev list in the bridge driver I can get the
address easily,
how do I get the adapter_id ? should this be a property subdev ? And also same
with bustype.
Regards,
--Prabhakar
--
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
OK
OK -- 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
OK
OK -- 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
OK
OK -- 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
OK
OK -- 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
OK
OK -- 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
Yon've won a Prize
Yon've won a Prize MICROSOFT IBERICA SL" YOU 'VE WON. ATTN:MICROSOFT IBERICA SL Your email has won (EUR244,000,00) (TWO HUNDRED AND FOURTY FOUR THOUSAND EURO) Batch number:XL73276498AM Ref number:QR352899526KC This is a millennium scientific computer game in which email addresses were used.It is a promotional program aimed at encouraging internet users,therefore you do not need to buy ticket to enter for it. For further development,clarification and procedure please Contact:Dr Eduardo Sanchez, Email contact:payingroll...@yahoo.com.hk -- 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 01/15] drivers: phy: add generic PHY framework
On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote: > On Sat, 20 Jul 2013, Greg KH wrote: > > > > >>That should be passed using platform data. > > > > > > > >Ick, don't pass strings around, pass pointers. If you have platform > > > >data you can get to, then put the pointer there, don't use a "name". > > > > > > I don't think I understood you here :-s We wont have phy pointer > > > when we create the device for the controller no?(it'll be done in > > > board file). Probably I'm missing something. > > > > Why will you not have that pointer? You can't rely on the "name" as the > > device id will not match up, so you should be able to rely on the > > pointer being in the structure that the board sets up, right? > > > > Don't use names, especially as ids can, and will, change, that is going > > to cause big problems. Use pointers, this is C, we are supposed to be > > doing that :) > > Kishon, I think what Greg means is this: The name you are using must > be stored somewhere in a data structure constructed by the board file, > right? Or at least, associated with some data structure somehow. > Otherwise the platform code wouldn't know which PHY hardware > corresponded to a particular name. > > Greg's suggestion is that you store the address of that data structure > in the platform data instead of storing the name string. Have the > consumer pass the data structure's address when it calls phy_create, > instead of passing the name. Then you don't have to worry about two > PHYs accidentally ending up with the same name or any other similar > problems. Close, but the issue is that whatever returns from phy_create() should then be used, no need to call any "find" functions, as you can just use the pointer that phy_create() returns. Much like all other class api functions in the kernel work. thanks, greg k-h -- 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 01/15] drivers: phy: add generic PHY framework
On Sat, 20 Jul 2013, Greg KH wrote: > > >>That should be passed using platform data. > > > > > >Ick, don't pass strings around, pass pointers. If you have platform > > >data you can get to, then put the pointer there, don't use a "name". > > > > I don't think I understood you here :-s We wont have phy pointer > > when we create the device for the controller no?(it'll be done in > > board file). Probably I'm missing something. > > Why will you not have that pointer? You can't rely on the "name" as the > device id will not match up, so you should be able to rely on the > pointer being in the structure that the board sets up, right? > > Don't use names, especially as ids can, and will, change, that is going > to cause big problems. Use pointers, this is C, we are supposed to be > doing that :) Kishon, I think what Greg means is this: The name you are using must be stored somewhere in a data structure constructed by the board file, right? Or at least, associated with some data structure somehow. Otherwise the platform code wouldn't know which PHY hardware corresponded to a particular name. Greg's suggestion is that you store the address of that data structure in the platform data instead of storing the name string. Have the consumer pass the data structure's address when it calls phy_create, instead of passing the name. Then you don't have to worry about two PHYs accidentally ending up with the same name or any other similar problems. Alan Stern -- 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 01/15] drivers: phy: add generic PHY framework
On Sat, Jul 20, 2013 at 08:49:32AM +0530, Kishon Vijay Abraham I wrote: > Hi, > > On Saturday 20 July 2013 05:20 AM, Greg KH wrote: > >On Fri, Jul 19, 2013 at 12:06:01PM +0530, Kishon Vijay Abraham I wrote: > >>Hi, > >> > >>On Friday 19 July 2013 11:59 AM, Greg KH wrote: > >>>On Fri, Jul 19, 2013 at 11:25:44AM +0530, Kishon Vijay Abraham I wrote: > Hi, > > On Friday 19 July 2013 11:13 AM, Greg KH wrote: > >On Fri, Jul 19, 2013 at 11:07:10AM +0530, Kishon Vijay Abraham I wrote: > >>+ ret = dev_set_name(&phy->dev, "%s.%d", dev_name(dev), id); > > > >Your naming is odd, no "phy" anywhere in it? You rely on the sender > >to > >never send a duplicate name.id pair? Why not create your own ids > >based > >on the number of phys in the system, like almost all other classes > >and > >subsystems do? > > hmm.. some PHY drivers use the id they provide to perform some of > their > internal operation as in [1] (This is used only if a single PHY > provider > implements multiple PHYS). Probably I'll add an option like > PLATFORM_DEVID_AUTO > to give the PHY drivers an option to use auto id. > > [1] -> > http://archive.arm.linux.org.uk/lurker/message/20130628.134308.4a8f7668.ca.html > >>> > >>>No, who cares about the id? No one outside of the phy core ever > >>>should, > >>>because you pass back the only pointer that they really do care about, > >>>if they need to do anything with the device. Use that, and then you > >>>can > >> > >>hmm.. ok. > >> > >>>rip out all of the "search for a phy by a string" logic, as that's not > >> > >>Actually this is needed for non-dt boot case. In the case of dt boot, > >>we use a > >>phandle by which the controller can get a reference to the phy. But in > >>the case > >>of non-dt boot, the controller can get a reference to the phy only by > >>label. > > > >I don't understand. They registered the phy, and got back a pointer to > >it. Why can't they save it in their local structure to use it again > >later if needed? They should never have to "ask" for the device, as the > > One is a *PHY provider* driver which is a driver for some PHY device. > This will > use phy_create to create the phy. > The other is a *PHY consumer* driver which might be any controller driver > (can > be USB/SATA/PCIE). The PHY consumer will use phy_get to get a reference > to the > phy (by *phandle* in the case of dt boot and *label* in the case of > non-dt boot). > >device id might be unknown if there are multiple devices in the system. > > I agree with you on the device id part. That need not be known to the PHY > driver. > >>> > >>>How does a consumer know which "label" to use in a non-dt system if > >>>there are multiple PHYs in the system? > >> > >>That should be passed using platform data. > > > >Ick, don't pass strings around, pass pointers. If you have platform > >data you can get to, then put the pointer there, don't use a "name". > > I don't think I understood you here :-s We wont have phy pointer > when we create the device for the controller no?(it'll be done in > board file). Probably I'm missing something. Why will you not have that pointer? You can't rely on the "name" as the device id will not match up, so you should be able to rely on the pointer being in the structure that the board sets up, right? Don't use names, especially as ids can, and will, change, that is going to cause big problems. Use pointers, this is C, we are supposed to be doing that :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] [media] coda: No need to check the return value of platform_get_resource()
From: Fabio Estevam
When using devm_ioremap_resource(), we do not need to check the return value of
platform_get_resource(), so just remove it.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- None
drivers/media/platform/coda.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index 486db30..f9a4b33 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -2039,11 +2039,6 @@ static int coda_probe(struct platform_device *pdev)
/* Get memory for physical registers */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (res == NULL) {
- dev_err(&pdev->dev, "failed to get memory region resource\n");
- return -ENOENT;
- }
-
dev->regs_base = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(dev->regs_base))
return PTR_ERR(dev->regs_base);
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] [media] coda: Check the return value from clk_prepare_enable()
From: Fabio Estevam clk_prepare_enable() may fail, so let's check its return value and propagate it in the case of error. Signed-off-by: Fabio Estevam --- Changes since v1: - Add missing 'if' drivers/media/platform/coda.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c index df4ada88..486db30 100644 --- a/drivers/media/platform/coda.c +++ b/drivers/media/platform/coda.c @@ -1559,14 +1559,21 @@ static int coda_open(struct file *file) list_add(&ctx->list, &dev->instances); coda_unlock(ctx); - clk_prepare_enable(dev->clk_per); - clk_prepare_enable(dev->clk_ahb); + ret = clk_prepare_enable(dev->clk_per); + if (ret) + goto err; + + ret = clk_prepare_enable(dev->clk_ahb); + if (ret) + goto err_clk_ahb; v4l2_dbg(1, coda_debug, &dev->v4l2_dev, "Created instance %d (%p)\n", ctx->idx, ctx); return 0; +err_clk_ahb: + clk_disable_unprepare(dev->clk_per); err: v4l2_fh_del(&ctx->fh); v4l2_fh_exit(&ctx->fh); -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] [media] coda: Check the return value from clk_prepare_enable()
From: Fabio Estevam clk_prepare_enable() may fail, so let's check its return value and propagate it in the case of error. Signed-off-by: Fabio Estevam --- drivers/media/platform/coda.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c index df4ada88..dd76228 100644 --- a/drivers/media/platform/coda.c +++ b/drivers/media/platform/coda.c @@ -1559,14 +1559,20 @@ static int coda_open(struct file *file) list_add(&ctx->list, &dev->instances); coda_unlock(ctx); - clk_prepare_enable(dev->clk_per); - clk_prepare_enable(dev->clk_ahb); + ret = clk_prepare_enable(dev->clk_per); + if (ret) + goto err; + + ret = clk_prepare_enable(dev->clk_ahb); + goto err_clk_ahb; v4l2_dbg(1, coda_debug, &dev->v4l2_dev, "Created instance %d (%p)\n", ctx->idx, ctx); return 0; +err_clk_ahb: + clk_disable_unprepare(dev->clk_per); err: v4l2_fh_del(&ctx->fh); v4l2_fh_exit(&ctx->fh); -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] [media] coda: No need to check the return value of platform_get_resource()
From: Fabio Estevam
When using devm_ioremap_resource(), we do not need to check the return value of
platform_get_resource(), so just remove it.
Signed-off-by: Fabio Estevam
---
drivers/media/platform/coda.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index dd76228..236385f 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -2038,11 +2038,6 @@ static int coda_probe(struct platform_device *pdev)
/* Get memory for physical registers */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (res == NULL) {
- dev_err(&pdev->dev, "failed to get memory region resource\n");
- return -ENOENT;
- }
-
dev->regs_base = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(dev->regs_base))
return PTR_ERR(dev->regs_base);
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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: Sat Jul 20 19:02:57 CEST 2013 git branch: test git hash: 1c26190a8d492adadac4711fe5762d46204b18b0 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: v0.4.5-rc1 host hardware: x86_64 host os:3.9-7.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.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: OK linux-3.10-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: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: OK linux-3.10-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: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse version: v0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dvb-usb: add another product id for "Elgato EyeTV SAT"
From: Manuel Schönlaub
There is another revision of "Elgato EyeTV SAT" working with this driver
but using a previously unknown product id.
Signed-off-by: Manuel Schönlaub
---
drivers/media/dvb-core/dvb-usb-ids.h |1 +
drivers/media/usb/dvb-usb/az6027.c |7 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff -upNr linux-3.10/drivers/media/dvb-core/dvb-usb-ids.h
linux-3.10-patched/drivers/media/dvb-core/dvb-usb-ids.h
--- linux-3.10/drivers/media/dvb-core/dvb-usb-ids.h 2013-07-01
00:13:29.0 +0200
+++ linux-3.10-patched/drivers/media/dvb-core/dvb-usb-ids.h 2013-07-20
18:01:23.573035824 +0200
@@ -353,6 +353,7 @@
#define USB_PID_ELGATO_EYETV_DTT_2 0x003f
#define USB_PID_ELGATO_EYETV_DTT_Dlx 0x0020
#define USB_PID_ELGATO_EYETV_SAT 0x002a
+#define USB_PID_ELGATO_EYETV_SAT_CI0x0025
#define USB_PID_DVB_T_USB_STICK_HIGH_SPEED_COLD0x5000
#define USB_PID_DVB_T_USB_STICK_HIGH_SPEED_WARM0x5001
#define USB_PID_FRIIO_WHITE0x0001
diff -upNr linux-3.10/drivers/media/usb/dvb-usb/az6027.c
linux-3.10-patched/drivers/media/usb/dvb-usb/az6027.c
--- linux-3.10/drivers/media/usb/dvb-usb/az6027.c 2013-07-01
00:13:29.0 +0200
+++ linux-3.10-patched/drivers/media/usb/dvb-usb/az6027.c 2013-07-20
18:31:47.622924602 +0200
@@ -1088,6 +1088,7 @@ static struct usb_device_id az6027_usb_t
{ USB_DEVICE(USB_VID_TECHNISAT, USB_PID_TECHNISAT_USB2_HDCI_V1) },
{ USB_DEVICE(USB_VID_TECHNISAT, USB_PID_TECHNISAT_USB2_HDCI_V2) },
{ USB_DEVICE(USB_VID_ELGATO, USB_PID_ELGATO_EYETV_SAT) },
+ { USB_DEVICE(USB_VID_ELGATO, USB_PID_ELGATO_EYETV_SAT_CI) },
{ },
};
@@ -1136,7 +1137,7 @@ static struct dvb_usb_device_properties
.i2c_algo = &az6027_i2c_algo,
- .num_device_descs = 6,
+ .num_device_descs = 7,
.devices = {
{
.name = "AZUREWAVE DVB-S/S2 USB2.0 (AZ6027)",
@@ -1162,6 +1163,10 @@ static struct dvb_usb_device_properties
.name = "Elgato EyeTV Sat",
.cold_ids = { &az6027_usb_table[5], NULL },
.warm_ids = { NULL },
+ }, {
+ .name = "Elgato EyeTV Sat",
+ .cold_ids = { &az6027_usb_table[6], NULL },
+ .warm_ids = { NULL },
},
{ NULL },
}
--
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
Is it Possible to get GSE using TBS6925
Hi, I am wondering if it is possible to capture GSE with my TBS6925. I found a patch for TBS6925 linux driver from Christian Prähauser[1] to support multistream in linux. But the Patch is for an old version of the driver. When I tried to apply the patch on liplianin driver (s2-37) I realized that the source code has changed, and already included some of the changes. Since it has been almost a year since the last post in this field I wanted to know if any further investigation has happened on the mater, and if any one was able to capture GSE. In dvbnet homepage[2] I can see there is a gse-testing tool, but no download link! Has anyone used that tool? Does any one have the tool!? Any help would be appreciated. Thank you in advance. Cheers [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg42465.html [2] http://www.cosy.sbg.ac.at/~cpraehaus/dvb-net.shtml -- 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
