[PATCH v3 0/2] adv7343 add OF support
From: Lad, Prabhakar prabhakar.cse...@gmail.com This series adds OF support for adv7343 driver. The first patch makes platform data members as a array, so to ease in adding DT support. Lad, Prabhakar (2): media: i2c: adv7343: make the platform data members as array media: i2c: adv7343: add OF support .../devicetree/bindings/media/i2c/adv7343.txt | 48 + arch/arm/mach-davinci/board-da850-evm.c|6 +- drivers/media/i2c/adv7343.c| 74 include/media/adv7343.h| 20 ++ 4 files changed, 113 insertions(+), 35 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/i2c/adv7343.txt -- 1.7.9.5 -- 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/2] media: i2c: adv7343: make the platform data members as array
From: Lad, Prabhakar prabhakar.cse...@gmail.com
This patch makes the platform data members as array wherever
possible, so as this makes easier while collecting the data
in DT case and read the entire array at once.
This patch also makes appropriate changes to board-da850-evm.c
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Cc: Sekhar Nori nsek...@ti.com
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm/mach-davinci/board-da850-evm.c |6 ++
drivers/media/i2c/adv7343.c | 28 ++--
include/media/adv7343.h | 20
3 files changed, 20 insertions(+), 34 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index e6f5b5d..ab6bdbe 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -733,12 +733,10 @@ static struct tvp514x_platform_data tvp5146_pdata = {
static struct adv7343_platform_data adv7343_pdata = {
.mode_config = {
- .dac_3 = 1,
- .dac_2 = 1,
- .dac_1 = 1,
+ .dac = { 1, 1, 1 },
},
.sd_config = {
- .sd_dac_out1 = 1,
+ .sd_dac_out = { 1 },
},
};
diff --git a/drivers/media/i2c/adv7343.c b/drivers/media/i2c/adv7343.c
index 8080c2c..f0238fb 100644
--- a/drivers/media/i2c/adv7343.c
+++ b/drivers/media/i2c/adv7343.c
@@ -227,12 +227,12 @@ static int adv7343_setoutput(struct v4l2_subdev *sd, u32
output_type)
else
val = state-pdata-mode_config.sleep_mode 0 |
state-pdata-mode_config.pll_control 1 |
- state-pdata-mode_config.dac_3 2 |
- state-pdata-mode_config.dac_2 3 |
- state-pdata-mode_config.dac_1 4 |
- state-pdata-mode_config.dac_6 5 |
- state-pdata-mode_config.dac_5 6 |
- state-pdata-mode_config.dac_4 7;
+ state-pdata-mode_config.dac[2] 2 |
+ state-pdata-mode_config.dac[1] 3 |
+ state-pdata-mode_config.dac[0] 4 |
+ state-pdata-mode_config.dac[5] 5 |
+ state-pdata-mode_config.dac[4] 6 |
+ state-pdata-mode_config.dac[3] 7;
err = adv7343_write(sd, ADV7343_POWER_MODE_REG, val);
if (err 0)
@@ -251,15 +251,15 @@ static int adv7343_setoutput(struct v4l2_subdev *sd, u32
output_type)
/* configure SD DAC Output 2 and SD DAC Output 1 bit to zero */
val = state-reg82 (SD_DAC_1_DI SD_DAC_2_DI);
- if (state-pdata state-pdata-sd_config.sd_dac_out1)
- val = val | (state-pdata-sd_config.sd_dac_out1 1);
- else if (state-pdata !state-pdata-sd_config.sd_dac_out1)
- val = val ~(state-pdata-sd_config.sd_dac_out1 1);
+ if (state-pdata state-pdata-sd_config.sd_dac_out[0])
+ val = val | (state-pdata-sd_config.sd_dac_out[0] 1);
+ else if (state-pdata !state-pdata-sd_config.sd_dac_out[0])
+ val = val ~(state-pdata-sd_config.sd_dac_out[0] 1);
- if (state-pdata state-pdata-sd_config.sd_dac_out2)
- val = val | (state-pdata-sd_config.sd_dac_out2 2);
- else if (state-pdata !state-pdata-sd_config.sd_dac_out2)
- val = val ~(state-pdata-sd_config.sd_dac_out2 2);
+ if (state-pdata state-pdata-sd_config.sd_dac_out[1])
+ val = val | (state-pdata-sd_config.sd_dac_out[1] 2);
+ else if (state-pdata !state-pdata-sd_config.sd_dac_out[1])
+ val = val ~(state-pdata-sd_config.sd_dac_out[1] 2);
err = adv7343_write(sd, ADV7343_SD_MODE_REG2, val);
if (err 0)
diff --git a/include/media/adv7343.h b/include/media/adv7343.h
index 944757b..e4142b1 100644
--- a/include/media/adv7343.h
+++ b/include/media/adv7343.h
@@ -28,12 +28,7 @@
* @pll_control: PLL and oversampling control. This control allows internal
* PLL 1 circuit to be powered down and the oversampling to be
* switched off.
- * @dac_1: power on/off DAC 1.
- * @dac_2: power on/off DAC 2.
- * @dac_3: power on/off DAC 3.
- * @dac_4: power on/off DAC 4.
- * @dac_5: power on/off DAC 5.
- * @dac_6: power on/off DAC 6.
+ * @dac: array to configure power on/off DAC's 1..6
*
* Power mode register (Register 0x0), for more info refer REGISTER MAP ACCESS
* section of datasheet[1], table 17 page no 30.
@@ -43,23 +38,16 @@
struct adv7343_power_mode {
bool sleep_mode;
bool pll_control;
- bool dac_1;
- bool dac_2;
- bool dac_3;
- bool dac_4;
- bool dac_5;
- bool dac_6;
+ u32 dac[6];
};
/**
* struct adv7343_sd_config - SD Only Output Configuration.
- * @sd_dac_out1: Configure SD DAC Output 1.
- * @sd_dac_out2: Configure SD DAC Output 2.
+ * @sd_dac_out: array
[PATCH v3 2/2] media: i2c: adv7343: add OF support
From: Lad, Prabhakar prabhakar.cse...@gmail.com
add OF support for the adv7343 driver.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
Changes for v3:
1: Fixed review comments pointed by Sylwester.
Changes for v2:
1: Fixed naming of properties.
.../devicetree/bindings/media/i2c/adv7343.txt | 48
drivers/media/i2c/adv7343.c| 46 ++-
2 files changed, 93 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/adv7343.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7343.txt
b/Documentation/devicetree/bindings/media/i2c/adv7343.txt
new file mode 100644
index 000..5653bc2
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adv7343.txt
@@ -0,0 +1,48 @@
+* Analog Devices adv7343 video encoder
+
+The ADV7343 are high speed, digital-to-analog video encoders in a 64-lead LQFP
+package. Six high speed, 3.3 V, 11-bit video DACs provide support for composite
+(CVBS), S-Video (Y-C), and component (YPrPb/RGB) analog outputs in standard
+definition (SD), enhanced definition (ED), or high definition (HD) video
+formats.
+
+Required Properties :
+- compatible: Must be adi,adv7343
+
+Optional Properties :
+- adi,power-mode-sleep-mode: on enable the current consumption is reduced to
+ micro ampere level. All DACs and the internal PLL
+ circuit are disabled.
+- adi,power-mode-pll-ctrl: PLL and oversampling control. This control allows
+ internal PLL 1 circuit to be powered down and the
+ oversampling to be switched off.
+- ad,adv7343-power-mode-dac: array configuring the power on/off DAC's 1..6,
+ 0 = OFF and 1 = ON, Default value when this
+ property is not specified is 0 0 0 0 0 0.
+- ad,adv7343-sd-config-dac-out: array configure SD DAC Output's 1 and 2, 0 =
OFF
+and 1 = ON, Default value when this property is
+not specified is 0 0.
+
+Example:
+
+i2c0@1c22000 {
+ ...
+ ...
+
+ adv7343@2a {
+ compatible = adi,adv7343;
+ reg = 0x2a;
+
+ port {
+ adv7343_1: endpoint {
+ adi,power-mode-sleep-mode;
+ adi,power-mode-pll-ctrl;
+ /* Use DAC1..3, DAC6 */
+ adi,dac-enable = 1 1 1 0 0 1;
+ /* Use SD DAC output 1 */
+ adi,sd-dac-enable = 1 0;
+ };
+ };
+ };
+ ...
+};
diff --git a/drivers/media/i2c/adv7343.c b/drivers/media/i2c/adv7343.c
index f0238fb..aeb56c5 100644
--- a/drivers/media/i2c/adv7343.c
+++ b/drivers/media/i2c/adv7343.c
@@ -30,6 +30,7 @@
#include media/v4l2-async.h
#include media/v4l2-device.h
#include media/v4l2-ctrls.h
+#include media/v4l2-of.h
#include adv7343_regs.h
@@ -399,6 +400,40 @@ static int adv7343_initialize(struct v4l2_subdev *sd)
return err;
}
+static struct adv7343_platform_data *
+adv7343_get_pdata(struct i2c_client *client)
+{
+ struct adv7343_platform_data *pdata;
+ struct device_node *np;
+
+ if (!IS_ENABLED(CONFIG_OF) || !client-dev.of_node)
+ return client-dev.platform_data;
+
+ np = v4l2_of_get_next_endpoint(client-dev.of_node, NULL);
+ if (!np)
+ return NULL;
+
+ pdata = devm_kzalloc(client-dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ goto done;
+
+ pdata-mode_config.sleep_mode =
+ of_property_read_bool(np, adi,power-mode-sleep-mode);
+
+ pdata-mode_config.pll_control =
+ of_property_read_bool(np, adi,power-mode-pll-ctrl);
+
+ of_property_read_u32_array(np, adi,dac-enable,
+ pdata-mode_config.dac, 6);
+
+ of_property_read_u32_array(np, adi,sd-dac-enable,
+ pdata-sd_config.sd_dac_out, 2);
+
+done:
+ of_node_put(np);
+ return pdata;
+}
+
static int adv7343_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -417,7 +452,7 @@ static int adv7343_probe(struct i2c_client *client,
return -ENOMEM;
/* Copy board specific information here */
- state-pdata = client-dev.platform_data;
+ state-pdata = adv7343_get_pdata(client);
state-reg00= 0x80;
state-reg01= 0x00;
@@ -483,8 +518,17 @@ static const struct i2c_device_id adv7343_id[] = {
MODULE_DEVICE_TABLE(i2c, adv7343_id);
+#if IS_ENABLED(CONFIG_OF)
+static const struct of_device_id adv7343_of_match[] = {
+ {.compatible = adi,adv7343, },
+ { /*
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
[PATCH] dvb-usb: add another product id for Elgato EyeTV SAT
From: Manuel Schönlaub manuel.schoenl...@gmail.com
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 manuel.schoenl...@gmail.com
---
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
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 1/2] [media] coda: Check the return value from clk_prepare_enable()
From: Fabio Estevam fabio.este...@freescale.com 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 fabio.este...@freescale.com --- 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 fabio.este...@freescale.com
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 fabio.este...@freescale.com
---
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
[PATCH v2 1/2] [media] coda: Check the return value from clk_prepare_enable()
From: Fabio Estevam fabio.este...@freescale.com 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 fabio.este...@freescale.com --- 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 2/2] [media] coda: No need to check the return value of platform_get_resource()
From: Fabio Estevam fabio.este...@freescale.com
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 fabio.este...@freescale.com
---
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
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
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 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
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
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
