[PATCH 5/6] clk: s5p-fimc: Fix incorrect usage of IS_ERR_OR_NULL
Replace IS_ERR_OR_NULL with IS_ERR on clk_get results.
Signed-off-by: Tony Prisk li...@prisktech.co.nz
CC: Kyungmin Park kyungmin.p...@samsung.com
CC: Tomasz Stanislawski t.stanisl...@samsung.com
CC: linux-media@vger.kernel.org
---
drivers/media/platform/s5p-fimc/fimc-mdevice.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-fimc/fimc-mdevice.c
b/drivers/media/platform/s5p-fimc/fimc-mdevice.c
index 0531ab7..3ac4da2 100644
--- a/drivers/media/platform/s5p-fimc/fimc-mdevice.c
+++ b/drivers/media/platform/s5p-fimc/fimc-mdevice.c
@@ -730,7 +730,7 @@ static int fimc_md_get_clocks(struct fimc_md *fmd)
for (i = 0; i FIMC_MAX_CAMCLKS; i++) {
snprintf(clk_name, sizeof(clk_name), sclk_cam%u, i);
clock = clk_get(NULL, clk_name);
- if (IS_ERR_OR_NULL(clock)) {
+ if (IS_ERR(clock)) {
v4l2_err(fmd-v4l2_dev, Failed to get clock: %s,
clk_name);
return -ENXIO;
--
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 4/6] clk: s5p-tv: Fix incorrect usage of IS_ERR_OR_NULL
Replace IS_ERR_OR_NULL with IS_ERR on clk_get results.
Signed-off-by: Tony Prisk li...@prisktech.co.nz
CC: Kyungmin Park kyungmin.p...@samsung.com
CC: Tomasz Stanislawski t.stanisl...@samsung.com
CC: linux-media@vger.kernel.org
---
drivers/media/platform/s5p-tv/hdmi_drv.c | 10 +-
drivers/media/platform/s5p-tv/mixer_drv.c | 10 +-
drivers/media/platform/s5p-tv/sdo_drv.c | 10 +-
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/media/platform/s5p-tv/hdmi_drv.c
b/drivers/media/platform/s5p-tv/hdmi_drv.c
index 8a9cf43..1c48ca5 100644
--- a/drivers/media/platform/s5p-tv/hdmi_drv.c
+++ b/drivers/media/platform/s5p-tv/hdmi_drv.c
@@ -781,27 +781,27 @@ static int hdmi_resources_init(struct hdmi_device *hdev)
/* get clocks, power */
res-hdmi = clk_get(dev, hdmi);
- if (IS_ERR_OR_NULL(res-hdmi)) {
+ if (IS_ERR(res-hdmi)) {
dev_err(dev, failed to get clock 'hdmi'\n);
goto fail;
}
res-sclk_hdmi = clk_get(dev, sclk_hdmi);
- if (IS_ERR_OR_NULL(res-sclk_hdmi)) {
+ if (IS_ERR(res-sclk_hdmi)) {
dev_err(dev, failed to get clock 'sclk_hdmi'\n);
goto fail;
}
res-sclk_pixel = clk_get(dev, sclk_pixel);
- if (IS_ERR_OR_NULL(res-sclk_pixel)) {
+ if (IS_ERR(res-sclk_pixel)) {
dev_err(dev, failed to get clock 'sclk_pixel'\n);
goto fail;
}
res-sclk_hdmiphy = clk_get(dev, sclk_hdmiphy);
- if (IS_ERR_OR_NULL(res-sclk_hdmiphy)) {
+ if (IS_ERR(res-sclk_hdmiphy)) {
dev_err(dev, failed to get clock 'sclk_hdmiphy'\n);
goto fail;
}
res-hdmiphy = clk_get(dev, hdmiphy);
- if (IS_ERR_OR_NULL(res-hdmiphy)) {
+ if (IS_ERR(res-hdmiphy)) {
dev_err(dev, failed to get clock 'hdmiphy'\n);
goto fail;
}
diff --git a/drivers/media/platform/s5p-tv/mixer_drv.c
b/drivers/media/platform/s5p-tv/mixer_drv.c
index ca0f297..c1b2e0e 100644
--- a/drivers/media/platform/s5p-tv/mixer_drv.c
+++ b/drivers/media/platform/s5p-tv/mixer_drv.c
@@ -240,27 +240,27 @@ static int mxr_acquire_clocks(struct mxr_device *mdev)
struct device *dev = mdev-dev;
res-mixer = clk_get(dev, mixer);
- if (IS_ERR_OR_NULL(res-mixer)) {
+ if (IS_ERR(res-mixer)) {
mxr_err(mdev, failed to get clock 'mixer'\n);
goto fail;
}
res-vp = clk_get(dev, vp);
- if (IS_ERR_OR_NULL(res-vp)) {
+ if (IS_ERR(res-vp)) {
mxr_err(mdev, failed to get clock 'vp'\n);
goto fail;
}
res-sclk_mixer = clk_get(dev, sclk_mixer);
- if (IS_ERR_OR_NULL(res-sclk_mixer)) {
+ if (IS_ERR(res-sclk_mixer)) {
mxr_err(mdev, failed to get clock 'sclk_mixer'\n);
goto fail;
}
res-sclk_hdmi = clk_get(dev, sclk_hdmi);
- if (IS_ERR_OR_NULL(res-sclk_hdmi)) {
+ if (IS_ERR(res-sclk_hdmi)) {
mxr_err(mdev, failed to get clock 'sclk_hdmi'\n);
goto fail;
}
res-sclk_dac = clk_get(dev, sclk_dac);
- if (IS_ERR_OR_NULL(res-sclk_dac)) {
+ if (IS_ERR(res-sclk_dac)) {
mxr_err(mdev, failed to get clock 'sclk_dac'\n);
goto fail;
}
diff --git a/drivers/media/platform/s5p-tv/sdo_drv.c
b/drivers/media/platform/s5p-tv/sdo_drv.c
index ad68bbe..269d246 100644
--- a/drivers/media/platform/s5p-tv/sdo_drv.c
+++ b/drivers/media/platform/s5p-tv/sdo_drv.c
@@ -341,25 +341,25 @@ static int __devinit sdo_probe(struct platform_device
*pdev)
/* acquire clocks */
sdev-sclk_dac = clk_get(dev, sclk_dac);
- if (IS_ERR_OR_NULL(sdev-sclk_dac)) {
+ if (IS_ERR(sdev-sclk_dac)) {
dev_err(dev, failed to get clock 'sclk_dac'\n);
ret = -ENXIO;
goto fail;
}
sdev-dac = clk_get(dev, dac);
- if (IS_ERR_OR_NULL(sdev-dac)) {
+ if (IS_ERR(sdev-dac)) {
dev_err(dev, failed to get clock 'dac'\n);
ret = -ENXIO;
goto fail_sclk_dac;
}
sdev-dacphy = clk_get(dev, dacphy);
- if (IS_ERR_OR_NULL(sdev-dacphy)) {
+ if (IS_ERR(sdev-dacphy)) {
dev_err(dev, failed to get clock 'dacphy'\n);
ret = -ENXIO;
goto fail_dac;
}
sclk_vpll = clk_get(dev, sclk_vpll);
- if (IS_ERR_OR_NULL(sclk_vpll)) {
+ if (IS_ERR(sclk_vpll)) {
dev_err(dev, failed to get clock 'sclk_vpll'\n);
ret = -ENXIO;
goto fail_dacphy;
@@ -367,7 +367,7 @@ static int __devinit sdo_probe(struct platform_device *pdev)
clk_set_parent(sdev-sclk_dac, sclk_vpll);
clk_put(sclk_vpll);
sdev-fout_vpll = clk_get(dev, fout_vpll);
- if
[PATCH 6/6] clk: s5p-g2d: Fix incorrect usage of IS_ERR_OR_NULL
Replace IS_ERR_OR_NULL with IS_ERR on clk_get results.
Signed-off-by: Tony Prisk li...@prisktech.co.nz
CC: Kyungmin Park kyungmin.p...@samsung.com
CC: Tomasz Stanislawski t.stanisl...@samsung.com
CC: linux-media@vger.kernel.org
---
drivers/media/platform/s5p-g2d/g2d.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/s5p-g2d/g2d.c
b/drivers/media/platform/s5p-g2d/g2d.c
index 1bfbc32..dcd5335 100644
--- a/drivers/media/platform/s5p-g2d/g2d.c
+++ b/drivers/media/platform/s5p-g2d/g2d.c
@@ -715,7 +715,7 @@ static int g2d_probe(struct platform_device *pdev)
}
dev-clk = clk_get(pdev-dev, sclk_fimg2d);
- if (IS_ERR_OR_NULL(dev-clk)) {
+ if (IS_ERR(dev-clk)) {
dev_err(pdev-dev, failed to get g2d clock\n);
return -ENXIO;
}
@@ -727,7 +727,7 @@ static int g2d_probe(struct platform_device *pdev)
}
dev-gate = clk_get(pdev-dev, fimg2d);
- if (IS_ERR_OR_NULL(dev-gate)) {
+ if (IS_ERR(dev-gate)) {
dev_err(pdev-dev, failed to get g2d clock gate\n);
ret = -ENXIO;
goto unprep_clk;
--
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
Re: [RFC v2 0/5] Common Display Framework
On Tue, Dec 18, 2012 at 7:21 AM, Rob Clark rob.cl...@linaro.org wrote: The other thing I'd like you guys to do is kill the idea of fbdev and v4l drivers that are shared with the drm codebase, really just implement fbdev and v4l on top of the drm layer, some people might think this is some sort of maintainer thing, but really nothing else makes sense, and having these shared display frameworks just to avoid having using drm/kms drivers seems totally pointless. Fix the drm fbdev emulation if an fbdev interface is needed. But creating a fourth framework because our previous 3 frameworks didn't work out doesn't seem like a situation I want to get behind too much. yeah, let's not have multiple frameworks to do the same thing.. For fbdev, it is pretty clear that it is a dead end. For v4l2 (subdev+mcf), it is perhaps bit more flexible when it comes to random arbitrary hw pipelines than kms. But to take advantage of that, your userspace isn't going to be portable anyways, so you might as well use driver specific properties/ioctls. But I tend to think that is more useful for cameras. And from userspace perspective, kms planes are less painful to use for output than v4l2, so lets stick to drm/kms for output (and not try to add camera/capture support to kms).. k, thx Yeah, I guess having a v4l device also exported by the same driver that exports the drm interface might make sense in some cases. But in many cases I think the video part is just an independent IP block and shuffling data around with dma-buf is all we really need. So yeah, I guess sharing display resources between v4l and drm kms driver should be a last resort option, since coordination (especially if it's supposed to be somewhat dynamic) will be extremely hairy. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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
[PATCHv2] dvb: or51211: apply pr_fmt and use pr_* macros instead of printk
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
drivers/media/dvb-frontends/or51211.c | 94 +++--
1 file changed, 43 insertions(+), 51 deletions(-)
diff --git a/drivers/media/dvb-frontends/or51211.c
b/drivers/media/dvb-frontends/or51211.c
index 1af997e..10cfc05 100644
--- a/drivers/media/dvb-frontends/or51211.c
+++ b/drivers/media/dvb-frontends/or51211.c
@@ -22,6 +22,8 @@
*
*/
+#define pr_fmt(fmt)KBUILD_MODNAME : %s: fmt, __func__
+
/*
* This driver needs external firmware. Please use the command
* kerneldir/Documentation/dvb/get_dvb_firmware or51211 to
@@ -44,9 +46,7 @@
static int debug;
#define dprintk(args...) \
- do { \
- if (debug) printk(KERN_DEBUG or51211: args); \
- } while (0)
+ do { if (debug) pr_debug(args); } while (0)
static u8 run_buf[] = {0x7f,0x01};
static u8 cmd_buf[] = {0x04,0x01,0x50,0x80,0x06}; // ATSC
@@ -80,8 +80,7 @@ static int i2c_writebytes (struct or51211_state* state, u8
reg, const u8 *buf,
msg.buf = (u8 *)buf;
if ((err = i2c_transfer (state-i2c, msg, 1)) != 1) {
- printk(KERN_WARNING or51211: i2c_writebytes error
- (addr %02x, err == %i)\n, reg, err);
+ pr_warn(error (addr %02x, err == %i)\n, reg, err);
return -EREMOTEIO;
}
@@ -98,8 +97,7 @@ static int i2c_readbytes(struct or51211_state *state, u8 reg,
u8 *buf, int len)
msg.buf = buf;
if ((err = i2c_transfer (state-i2c, msg, 1)) != 1) {
- printk(KERN_WARNING or51211: i2c_readbytes error
- (addr %02x, err == %i)\n, reg, err);
+ pr_warn(error (addr %02x, err == %i)\n, reg, err);
return -EREMOTEIO;
}
@@ -118,11 +116,11 @@ static int or51211_load_firmware (struct dvb_frontend* fe,
/* Get eprom data */
tudata[0] = 17;
if (i2c_writebytes(state,0x50,tudata,1)) {
- printk(KERN_WARNING or51211:load_firmware error eprom addr\n);
+ pr_warn(error eprom addr\n);
return -1;
}
if (i2c_readbytes(state,0x50,tudata[145],192)) {
- printk(KERN_WARNING or51211: load_firmware error eprom\n);
+ pr_warn(error eprom\n);
return -1;
}
@@ -136,32 +134,32 @@ static int or51211_load_firmware (struct dvb_frontend* fe,
state-config-reset(fe);
if (i2c_writebytes(state,state-config-demod_address,tudata,585)) {
- printk(KERN_WARNING or51211: load_firmware error 1\n);
+ pr_warn(error 1\n);
return -1;
}
msleep(1);
if (i2c_writebytes(state,state-config-demod_address,
fw-data[393],8125)) {
- printk(KERN_WARNING or51211: load_firmware error 2\n);
+ pr_warn(error 2\n);
return -1;
}
msleep(1);
if (i2c_writebytes(state,state-config-demod_address,run_buf,2)) {
- printk(KERN_WARNING or51211: load_firmware error 3\n);
+ pr_warn(error 3\n);
return -1;
}
/* Wait at least 5 msec */
msleep(10);
if (i2c_writebytes(state,state-config-demod_address,run_buf,2)) {
- printk(KERN_WARNING or51211: load_firmware error 4\n);
+ pr_warn(error 4\n);
return -1;
}
msleep(10);
- printk(or51211: Done.\n);
+ pr_info(Done.\n);
return 0;
};
@@ -173,14 +171,14 @@ static int or51211_setmode(struct dvb_frontend* fe, int
mode)
state-config-setmode(fe, mode);
if (i2c_writebytes(state,state-config-demod_address,run_buf,2)) {
- printk(KERN_WARNING or51211: setmode error 1\n);
+ pr_warn(error 1\n);
return -1;
}
/* Wait at least 5 msec */
msleep(10);
if (i2c_writebytes(state,state-config-demod_address,run_buf,2)) {
- printk(KERN_WARNING or51211: setmode error 2\n);
+ pr_warn(error 2\n);
return -1;
}
@@ -196,7 +194,7 @@ static int or51211_setmode(struct dvb_frontend* fe, int
mode)
* normal +/-150kHz Carrier acquisition range
*/
if (i2c_writebytes(state,state-config-demod_address,cmd_buf,3)) {
- printk(KERN_WARNING or51211: setmode error 3\n);
+ pr_warn(error 3\n);
return -1;
}
@@ -206,14 +204,14 @@ static int or51211_setmode(struct dvb_frontend* fe, int
mode)
rec_buf[3] = 0x00;
msleep(20);
if (i2c_writebytes(state,state-config-demod_address,rec_buf,3)) {
- printk(KERN_WARNING or51211: setmode error 5\n);
+ pr_warn(error 5\n);
}
msleep(3);
if (i2c_readbytes(state,state-config-demod_address,rec_buf[10],2))
Re: Lockup on second streamon with omap3-isp
Le 17/12/2012 10:32, Laurent Pinchart a écrit : Hi Julien, On Friday 14 December 2012 15:18:29 Julien BERAUD wrote: Hi Jean-Philippe, I have had exactly the same problem and the following workaround has caused no regression on our board yet. I can't explain exactly why it works and I think that it is internal to the isp. In function ccdc_set_stream, don't disable the ccdc_subclk when stopping capture: ret = ccdc_disable(ccdc); if (ccdc-output CCDC_OUTPUT_MEMORY) omap3isp_sbl_disable(isp, OMAP3_ISP_SBL_CCDC_WRITE); - omap3isp_subclk_disable(isp, OMAP3_ISP_SUBCLK_CCDC); + //omap3isp_subclk_disable(isp, OMAP3_ISP_SUBCLK_CCDC); I know that it is still a workaround but I hope that maybe it will help someone to understand the real cause of this issue. Do you get CCDC stop timeouts ? They are reported in the kernel log as CCDC stop timeout!. I don't have the appropriate setup currently and I will come back to you as soon as I have it but to my memory, I didn't have stop timeouts systematically but I always had the IRQ's overflow. I also have checked with a scope that the reason was not a crosstalk on the physical lines. Le 13/12/2012 15:14, jean-philippe francois a écrit : Hi, I have news on the IRQ storm on second streamon problem. Reminder : Given a perfectly fine HSYNC / VSYNC / PIXELCLOK configuration, the omap3-isp (at least until 3.4) will go into an interrupt storm when streamon is called for the second time, unless you are able to stop the sensor when not streaming. I have reproduced this on three different board, with three different sensor. On board 1, the problem disappeared by itself (in fact not by itself, see below) and the board is not in my possession anymore. On board 2, I implemented a working s_stream operation in the subdev driver, so the problem was solved because the sensor would effectively stop streaming when told to, keeping the ISP + CCDC happy On board 3, I can't stop the streaming, or I did not figure out how to make it stop yet. I tried to disable the HS_VS_IRQ, but it did not help, so I came back looking at the code of board 1, which was running fine with a 3.4 kernel. And I discovered the problem doesn't happen if I break the pipeline between two consecutive streamon. In other word if I do the following : media-ctl -l '16:0-5:0[1], 5:1-6:0[1]' media-ctl -f '16:0 [SBGGR8 2560x800 (0, 0)/2560x800]' yavta yavta ... - board locks up, soft lockup is fired But if I do this instead : media-ctl -l '16:0-5:0[0], 5:1-6:0[0]' media-ctl -l '16:0-5:0[1], 5:1-6:0[1]' media-ctl -f '16:0 [SBGGR8 2560x800 (0, 0)/2560x800]' yavta media-ctl -l '16:0-5:0[0], 5:1-6:0[0]' media-ctl -l '16:0-5:0[1], 5:1-6:0[1]' media-ctl -f '16:0 [SBGGR8 2560x800 (0, 0)/2560x800]' yavta ... - image are acquired, board doesn't lock up anymore Now this really doesn't make much sense to me. Both sequences should produce the exact same hardware accesses. Could you add a printk in isp_reg_writel (drivers/media/platform/omap3isp/isp.h) and compare the register writes for both sequences ? It would be interesting to go from this workaround to the elimination of the root cause. What can I do / test next to stop this bug from hapenning ? -- 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 v2 0/5] Common Display Framework
On 12/18/2012 06:04 AM, Dave Airlie wrote: Many developers showed interest in the first RFC, and I've had the opportunity to discuss it with most of them. I would like to thank (in no particular order) Tomi Valkeinen for all the time he spend helping me to draft v2, Marcus Lorentzon for his useful input during Linaro Connect Q4 2012, and Linaro for inviting me to Connect and providing a venue to discuss this topic. So this might be a bit off topic but this whole CDF triggered me looking at stuff I generally avoid: I like the effort, right now it seems like x86 and arm display sub systems are quite different in terms of DRM driver (and HW) design. I think this is partly due to little information shared about these different architectures and ideas behind the choices made. I hope some discussion will light up both sides. And an early discussion will hopefully give you less pain when CDF drivers starts to get pushed your way. The biggest problem I'm having currently with the whole ARM graphics and output world is the proliferation of platform drivers for every little thing. The whole ordering of operations with respect to things like suspend/resume or dynamic power management is going to be a real nightmare if there are dependencies between the drivers. How do you enforce ordering of s/r operations between all the various components? Could you give an example? Personally I don't think it is that many. I might not have counted the plat devs in all arm drivers. But the STE one have one per HW IP block in the HW (1 DSS + 3 DSI encoder/formatters). Then of course there are all these panel devices. But I hope that when CDF is finished we will have DSI devices on the DSI bus and DBI devices on the DBI bus. I think most vendors have used platform devices for these since they normally can't be probed in a generic way. But as they are off SoC I feel this is not the best choice. And then many of the panels are I2C devices (control bus) and that I guess is similar to x86 encoders/connectors? Another part of the difference I feel is that in x86 a DRM device is most likely a PCI device, and as such has one huge driver for all IPs on that board. The closest thing we get to that in ARM is probably the DSS (collection of IPs on SoC, like 3D, 2D, display output, encoders). But it doesn't fell right to create a single driver for all these. And as you know often 3D is even from a separate vendor. All these lead up to a slight increase in the number of devices and drivers. Right way, I feel so, but you are welcome to show a better way. The other thing I'd like you guys to do is kill the idea of fbdev and v4l drivers that are shared with the drm codebase, really just implement fbdev and v4l on top of the drm layer, some people might think this is some sort of maintainer thing, but really nothing else makes sense, and having these shared display frameworks just to avoid having using drm/kms drivers seems totally pointless. Fix the drm fbdev emulation if an fbdev interface is needed. But creating a fourth framework because our previous 3 frameworks didn't work out doesn't seem like a situation I want to get behind too much. I have no intention to use CDF outside KMS connector/encoder and I have not heard Laurent talk about this either. Personally I see CDF as helpers to create and reuse connector/encoder drivers between SoCs instead of each SoC do their own panel drivers (which would be about a hundred, times the number of supported SoCs). We probably need to discuss the connector/encoder mappings to CDF/panels. But I think we need to flush out the higher level details like control bus vs. data bus vs. display entities. While I like the generic way of the display entities, I also like the pure bus/device/driver model without too many generalizations. Do you have any support in x86 world that could be compared to mobile phone DSI/DBI/DPI panels? That is, different encoder/lcd-driver chips between the on chip/cpu/SoC CRTC and the external LCD depending on product (mobile/netbook/...) or is it all HDMI/DP/LVDS etc on x86? And if you do, how do you model/setup/share all those in DRM driver? Or it is manageable ( 10) and not up in the hundreds of different encoders/lcd-drivers? /BR /Marcus -- 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 v2 0/5] Common Display Framework
On 12/18/2012 07:21 AM, Rob Clark wrote: On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlieairl...@gmail.com wrote: So this might be a bit off topic but this whole CDF triggered me looking at stuff I generally avoid: The biggest problem I'm having currently with the whole ARM graphics and output world is the proliferation of platform drivers for every little thing. The whole ordering of operations with respect to things like suspend/resume or dynamic power management is going to be a real nightmare if there are dependencies between the drivers. How do you enforce ordering of s/r operations between all the various components? There have been already some ideas proposed to resolve this at the PM subsystem level [1]. And this problem is of course not only specific to platform drivers. The idea of having monolithic drivers, just because we can't get the suspend/resume sequences right otherwise, doesn't really sound appealing. SoC IPs get reused on multiple different SoC series, no only by single manufacturer. Whole graphics/video subsystems are composed from smaller blocks in SoCs, with various number of distinct sub-blocks and same sub-blocks repeated different number of times in a specific SoC revision. Expressing an IP as a platform device seems justified to me, often these platform devices have enough differences to treat them as such. E.g. belong in different power domain/use different clocks. Except there is big issue with the power management... However probably more important is to be able to have driver for a specific IP in a separate module. And this suspend/resume ordering issue is not only about the platform devices. E.g. camera subsystem can be composed of an image sensor sub-device driver, which is most often an I2C client driver, and of multiple SoC processing blocks. The image sensor can have dependencies on the SoC sub-blocks. So even if we created monolithic driver for the SoC part, there are still two pieces to get s/r ordering right - I2C client and SoC drivers. And please don't propose to merge the sensor sub-device driver too. There has been a lot of effort in V4L2 to separate those various functional blocks into sub-devices, so they can be freely reused, without reimplementing same functionality in each driver. BTW, there has been a nice talk about these topics at ELCE [2], particularly slide 22 is interesting. I believe the solution for these issues really needs to be sought in the PM subsystem itself. I tend to think that sub-devices are useful just to have a way to probe hw which may or may not be there, since on ARM we often don't have any alternative.. but beyond that, suspend/resume, and other life-cycle aspects, they should really be treated as all one device. Especially to avoid undefined suspend/resume ordering. [1] https://lkml.org/lkml/2009/9/9/373 [2] http://elinux.org/images/9/90/ELCE2012-Modular-Graphics-on-Embedded-ARM.pdf Thanks, Sylwester -- 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 13/13] drivers/media/tuners/e4000.c: use macros for i2c_msg initialization
Hi Julia, On Thu, 11 Oct 2012 08:45:43 +0200 (CEST), Julia Lawall wrote: I found 6 cases where there are more than 2 messages in the array. I didn't check how many cases where there are two messages but there is something other than one read and one write. Perhaps a reasonable option would be to use I2C_MSG_READ I2C_MSG_WRITE I2C_MSG_READ_OP I2C_MSG_WRITE_OP The last two are for the few cases where more flags are specified. As compared to the original proposal of I2C_MSG_OP, these keep the READ or WRITE idea in the macro name. The additional argument to the OP macros would be or'd with the read or write (nothing to do in this case) flags as appropriate. Mauro proposed INIT_I2C_READ_SUBADDR for the very common case where a message array has one read and one write. I think that putting one I2C_MSG_READ and one I2C_MSG_WRITE in this case is readable enough, and avoids the need to do something special for the cases that don't match the expectations of INIT_I2C_READ_SUBADDR. I propose not to do anything for the moment either for sizes or for message or buffer arrays that contain only one element. Please note that I resigned from my position of i2c subsystem maintainer, so I will not handle this. If you think this is important, you'll have to resubmit and Wolfram will decide what he wants to do about it. -- Jean Delvare -- 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 13/13] drivers/media/tuners/e4000.c: use macros for i2c_msg initialization
On Tue, 18 Dec 2012, Jean Delvare wrote: Hi Julia, On Thu, 11 Oct 2012 08:45:43 +0200 (CEST), Julia Lawall wrote: I found 6 cases where there are more than 2 messages in the array. I didn't check how many cases where there are two messages but there is something other than one read and one write. Perhaps a reasonable option would be to use I2C_MSG_READ I2C_MSG_WRITE I2C_MSG_READ_OP I2C_MSG_WRITE_OP The last two are for the few cases where more flags are specified. As compared to the original proposal of I2C_MSG_OP, these keep the READ or WRITE idea in the macro name. The additional argument to the OP macros would be or'd with the read or write (nothing to do in this case) flags as appropriate. Mauro proposed INIT_I2C_READ_SUBADDR for the very common case where a message array has one read and one write. I think that putting one I2C_MSG_READ and one I2C_MSG_WRITE in this case is readable enough, and avoids the need to do something special for the cases that don't match the expectations of INIT_I2C_READ_SUBADDR. I propose not to do anything for the moment either for sizes or for message or buffer arrays that contain only one element. Please note that I resigned from my position of i2c subsystem maintainer, so I will not handle this. If you think this is important, you'll have to resubmit and Wolfram will decide what he wants to do about it. OK, I had the impression that the conclusion was that the danger was greater than the benefit. If there is interest in it, since I think it does make the code more readable, I can pick it up again. julia -- 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 13/13] drivers/media/tuners/e4000.c: use macros for i2c_msg initialization
Please note that I resigned from my position of i2c subsystem maintainer, so I will not handle this. If you think this is important, you'll have to resubmit and Wolfram will decide what he wants to do about it. OK, I had the impression that the conclusion was that the danger was greater than the benefit. If there is interest in it, since I think it does make the code more readable, I can pick it up again. TBH, there are other things coming which have higher priority, so from my side, currently, there is not much interest right now. Thanks nonetheless, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
[PATCH] media: rc: gpio-ir-recv.c: change platform_data to DT binding
From: Matus Ujhelyi ujhely...@gmail.com
Signed-off-by: Matus Ujhelyi ujhely...@gmail.com
---
drivers/media/rc/gpio-ir-recv.c | 84 ++-
1 file changed, 66 insertions(+), 18 deletions(-)
diff --git a/drivers/media/rc/gpio-ir-recv.c b/drivers/media/rc/gpio-ir-recv.c
index ba1a1eb..cfba079 100644
--- a/drivers/media/rc/gpio-ir-recv.c
+++ b/drivers/media/rc/gpio-ir-recv.c
@@ -58,19 +58,49 @@ err_get_value:
return IRQ_HANDLED;
}
+static const struct of_device_id gpio_ir_of_match[] = {
+ {
+ .compatible = gpio-ir-recv,
+ },
+};
+MODULE_DEVICE_TABLE(of, gpio_ir_of_matchof_match);
+
+static int __devinit gpio_ir_recv_dt_probe (struct gpio_rc_dev *gpio_dev,
+ struct rc_dev *rcdev, struct platform_device *pdev) {
+
+ struct device_node *node = pdev-dev.of_node;
+
+ if (!node) {
+ pr_err(Missing gpio_nr in the DT\n);
+ return -EINVAL;
+ }
+
+ if (of_property_read_u32(node, gpio_nr, gpio_dev-gpio_nr)) {
+ pr_err(Missing gpio_nr in the DT\n);
+ return -EINVAL;
+ }
+
+ if (of_property_read_u64(node, allowed_protos,
rcdev-allowed_protos))
+ rcdev-allowed_protos = RC_BIT_ALL;
+
+ if (of_property_read_bool(node, active_low))
+ gpio_dev-active_low = true;
+ else
+ gpio_dev-active_low = false;
+
+ if (of_property_read_string(node, map_name, rcdev-map_name))
+ rcdev-map_name = NULL;
+
+ return 0;
+}
+
static int __devinit gpio_ir_recv_probe(struct platform_device *pdev)
{
struct gpio_rc_dev *gpio_dev;
struct rc_dev *rcdev;
const struct gpio_ir_recv_platform_data *pdata =
pdev-dev.platform_data;
- int rc;
-
- if (!pdata)
- return -EINVAL;
-
- if (pdata-gpio_nr 0)
- return -EINVAL;
+ int rc = -EINVAL;
gpio_dev = kzalloc(sizeof(struct gpio_rc_dev), GFP_KERNEL);
if (!gpio_dev)
@@ -82,6 +112,28 @@ static int __devinit gpio_ir_recv_probe(struct
platform_device *pdev)
goto err_allocate_device;
}
+ if (!pdata) {
+
+ if (gpio_ir_recv_dt_probe(gpio_dev, rcdev, pdev))
+ goto err_dt_create_of;
+
+ } else {
+
+ if (pdata-allowed_protos)
+ rcdev-allowed_protos = pdata-allowed_protos;
+ else
+ rcdev-allowed_protos = RC_BIT_ALL;
+ rcdev-map_name = pdata-map_name ?: RC_MAP_EMPTY;
+
+ gpio_dev-gpio_nr = pdata-gpio_nr;
+ gpio_dev-active_low = pdata-active_low;
+
+ }
+
+ if (gpio_dev-gpio_nr 0) {
+ goto err_gpio_nr;
+ }
+
rcdev-priv = gpio_dev;
rcdev-driver_type = RC_DRIVER_IR_RAW;
rcdev-input_name = GPIO_IR_DEVICE_NAME;
@@ -92,20 +144,13 @@ static int __devinit gpio_ir_recv_probe(struct
platform_device *pdev)
rcdev-input_id.version = 0x0100;
rcdev-dev.parent = pdev-dev;
rcdev-driver_name = GPIO_IR_DRIVER_NAME;
- if (pdata-allowed_protos)
- rcdev-allowed_protos = pdata-allowed_protos;
- else
- rcdev-allowed_protos = RC_BIT_ALL;
- rcdev-map_name = pdata-map_name ?: RC_MAP_EMPTY;
gpio_dev-rcdev = rcdev;
- gpio_dev-gpio_nr = pdata-gpio_nr;
- gpio_dev-active_low = pdata-active_low;
- rc = gpio_request(pdata-gpio_nr, gpio-ir-recv);
+ rc = gpio_request(gpio_dev-gpio_nr, gpio-ir-recv);
if (rc 0)
goto err_gpio_request;
- rc = gpio_direction_input(pdata-gpio_nr);
+ rc = gpio_direction_input(gpio_dev-gpio_nr);
if (rc 0)
goto err_gpio_direction_input;
@@ -117,7 +162,7 @@ static int __devinit gpio_ir_recv_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, gpio_dev);
- rc = request_any_context_irq(gpio_to_irq(pdata-gpio_nr),
+ rc = request_any_context_irq(gpio_to_irq(gpio_dev-gpio_nr),
gpio_ir_recv_irq,
IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
gpio-ir-recv-irq, gpio_dev);
@@ -131,8 +176,10 @@ err_request_irq:
rc_unregister_device(rcdev);
err_register_rc_device:
err_gpio_direction_input:
- gpio_free(pdata-gpio_nr);
+ gpio_free(gpio_dev-gpio_nr);
err_gpio_request:
+err_dt_create_of:
+err_gpio_nr:
rc_free_device(rcdev);
rcdev = NULL;
err_allocate_device:
@@ -195,6 +242,7 @@ static struct platform_driver gpio_ir_recv_driver = {
#ifdef CONFIG_PM
.pm = gpio_ir_recv_pm_ops,
#endif
+ .of_match_table = of_match_ptr(gpio_ir_of_match),
},
};
module_platform_driver(gpio_ir_recv_driver);
--
1.7.9.5
--
To unsubscribe from this list: send the line
Re: [PATCH v3 2/4] videobuf2-dma-streaming: new videobuf2 memory allocator
Hello, I'm sorry for the delay, I've been terribly busy recently. On 12/11/2012 2:54 PM, Federico Vaga wrote: This allocator is needed because some device (like STA2X11 VIP) cannot work with DMA sg or DMA coherent. Some other device (like the one used by Jonathan when he proposes vb2-dma-nc allocator) can obtain much better performance with DMA streaming than coherent. Ok, please add such explanations at the patch's descriptions, as it is important not only for me, but to others that may need to use it.. OK 2) why vb2-dma-config can't be patched to use dma_map_single (eventually using a different vb2_io_modes bit?); I did not modify vb2-dma-contig because I was thinking that each DMA memory allocator should reflect a DMA API. The basic reason for having more than one VB low-level handling (vb2 was inspired on this concept) is that some DMA APIs are very different than the other ones (see vmalloc x DMA S/G for example). I didn't make a diff between videobuf2-dma-streaming and videobuf2-dma-contig, so I can't tell if it makes sense to merge them or not, but the above argument seems too weak. I was expecting for a technical reason why it wouldn't make sense for merging them. I cannot work on this now. But I think that I can do an integration like the one that I pushed some month ago (a8f3c203e19b702fa5e8e83a9b6fb3c5a6d1cce4). Wind River made that changes to videobuf-contig and I tested, fixed and pushed. 3) what are the usecases for it. Could you please detail it? Without that, one that would be needing to write a driver will have serious doubts about what would be the right driver for its usage. Also, please document it at the driver itself. I don't have a full understand of the board so I don't know exactly why dma_alloc_coherent does not work. I focused my development on previous work by Wind River. I asked to Wind River (which did all the work on this board) for the technical explanation about why coherent doesn't work, but they do not know. That's why I made the new allocator: coherent doesn't work and HW doesn't support SG. Ok, now I see the whole image. I was convinced that this so called streaming allocator is required for performance reasons, not because of the broken platform support for coherent calls. My ultimate goal is to have support for both non-cached (coherent) and cached (non-coherent) buffers in the dma mapping subsystem on top of the common API. Then both types of buffers will be easily supported by dma-contig vb2 allocator. Currently support for streaming-style buffers requires completely different dma mapping calls, although from the device driver point of view the buffers behaves similarly, so implementing them as a separate allocator seems to be the best idea. I can take a look at the dma coherent issues with that board, but I will need some help as I don't have this hardware. I'm not a DMA performance expert. As such, from that comment, it sounded to me that replacing dma-config/dma-sg by dma streaming will always give performance optimizations the hardware allow. me too, I'm not a DMA performance expert. I'm just an user of the DMA API. On my hardware simply it works only with that interface, it is not a performance problem. On a separate but related issue, while doing DMABUF tests with an Exynos4 hardware, using a s5p sensor, sending data to s5p-tv, I noticed a CPU consumption of about 42%, which seems too high. Could it be related to not using the DMA streaming API? This might be related to the excessive cpu cache flushing on dma buf buffers as there were some misunderstanding who is responsible of that (I saw some strange code in drm, but it has been changed a few times). I will add this issue to my todo list. Best regards -- Marek Szyprowski Samsung Poland RD Center -- 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
[PATCHv16 7/7] drm_modes: add of_videomode helpers
Add helper to get drm_display_mode from devicetree.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/gpu/drm/drm_modes.c | 33 +
include/drm/drmP.h |4
2 files changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 184a22d..fd53454 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -35,6 +35,7 @@
#include linux/export.h
#include drm/drmP.h
#include drm/drm_crtc.h
+#include video/of_videomode.h
#include video/videomode.h
/**
@@ -541,6 +542,38 @@ int drm_display_mode_from_videomode(const struct videomode
*vm,
EXPORT_SYMBOL_GPL(drm_display_mode_from_videomode);
#endif
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+/**
+ * of_get_drm_display_mode - get a drm_display_mode from devicetree
+ * @np: device_node with the timing specification
+ * @dmode: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * This function is expensive and should only be used, if only one mode is to
be
+ * read from DT. To get multiple modes start with of_get_display_timings and
+ * work with that instead.
+ */
+int of_get_drm_display_mode(struct device_node *np,
+ struct drm_display_mode *dmode, int index)
+{
+ struct videomode vm;
+ int ret;
+
+ ret = of_get_videomode(np, vm, index);
+ if (ret)
+ return ret;
+
+ drm_display_mode_from_videomode(vm, dmode);
+
+ pr_debug(%s: got %dx%d display mode from %s\n,
+ of_node_full_name(np), vm.hactive, vm.vactive, np-name);
+ drm_mode_debug_printmodeline(dmode);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
+#endif
+
/**
* drm_mode_set_name - set the name on a mode
* @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 5fbb0fe..e26ca59 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -85,6 +85,7 @@ struct module;
struct drm_file;
struct drm_device;
+struct device_node;
struct videomode;
#include drm/drm_os_linux.h
@@ -1458,6 +1459,9 @@ drm_mode_create_from_cmdline_mode(struct drm_device *dev,
extern int drm_display_mode_from_videomode(const struct videomode *vm,
struct drm_display_mode *dmode);
+extern int of_get_drm_display_mode(struct device_node *np,
+ struct drm_display_mode *dmode,
+ int index);
/* Modesetting support */
extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
--
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
[PATCHv16 4/7] fbmon: add videomode helpers
Add a function to convert from the generic videomode to a fb_videomode.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/fbmon.c | 52 +
include/linux/fb.h|4
2 files changed, 56 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index cef6557..17ce135 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,6 +31,7 @@
#include linux/pci.h
#include linux/slab.h
#include video/edid.h
+#include video/videomode.h
#ifdef CONFIG_PPC_OF
#include asm/prom.h
#include asm/pci-bridge.h
@@ -1373,6 +1374,57 @@ int fb_get_mode(int flags, u32 val, struct
fb_var_screeninfo *var, struct fb_inf
kfree(timings);
return err;
}
+
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int fb_videomode_from_videomode(const struct videomode *vm,
+ struct fb_videomode *fbmode)
+{
+ unsigned int htotal, vtotal;
+
+ fbmode-xres = vm-hactive;
+ fbmode-left_margin = vm-hback_porch;
+ fbmode-right_margin = vm-hfront_porch;
+ fbmode-hsync_len = vm-hsync_len;
+
+ fbmode-yres = vm-vactive;
+ fbmode-upper_margin = vm-vback_porch;
+ fbmode-lower_margin = vm-vfront_porch;
+ fbmode-vsync_len = vm-vsync_len;
+
+ /* prevent division by zero in KHZ2PICOS macro */
+ fbmode-pixclock = vm-pixelclock ?
+ KHZ2PICOS(vm-pixelclock / 1000) : 0;
+
+ fbmode-sync = 0;
+ fbmode-vmode = 0;
+ if (vm-dmt_flags VESA_DMT_HSYNC_HIGH)
+ fbmode-sync |= FB_SYNC_HOR_HIGH_ACT;
+ if (vm-dmt_flags VESA_DMT_HSYNC_HIGH)
+ fbmode-sync |= FB_SYNC_VERT_HIGH_ACT;
+ if (vm-data_flags DISPLAY_FLAGS_INTERLACED)
+ fbmode-vmode |= FB_VMODE_INTERLACED;
+ if (vm-data_flags DISPLAY_FLAGS_DOUBLESCAN)
+ fbmode-vmode |= FB_VMODE_DOUBLE;
+ fbmode-flag = 0;
+
+ htotal = vm-hactive + vm-hfront_porch + vm-hback_porch +
+vm-hsync_len;
+ vtotal = vm-vactive + vm-vfront_porch + vm-vback_porch +
+vm-vsync_len;
+ /* prevent division by zero */
+ if (htotal vtotal) {
+ fbmode-refresh = vm-pixelclock / (htotal * vtotal);
+ /* a mode must have htotal and vtotal != 0 or it is invalid */
+ } else {
+ fbmode-refresh = 0;
+ return -EINVAL;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
+#endif
+
#else
int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
{
diff --git a/include/linux/fb.h b/include/linux/fb.h
index c7a9571..100a176 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -19,6 +19,7 @@ struct vm_area_struct;
struct fb_info;
struct device;
struct file;
+struct videomode;
/* Definitions below are used in the parsed monitor specs */
#define FB_DPMS_ACTIVE_OFF 1
@@ -714,6 +715,9 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb);
extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);
+extern int fb_videomode_from_videomode(const struct videomode *vm,
+ struct fb_videomode *fbmode);
+
/* drivers/video/modedb.c */
#define VESA_MODEDB_SIZE 34
extern void fb_var_to_videomode(struct fb_videomode *mode,
--
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
[PATCHv16 5/7] fbmon: add of_videomode helpers
Add helper to get fb_videomode from devicetree.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/fbmon.c | 42 ++
include/linux/fb.h|4
2 files changed, 46 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index 17ce135..94ad0f7 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,6 +31,7 @@
#include linux/pci.h
#include linux/slab.h
#include video/edid.h
+#include video/of_videomode.h
#include video/videomode.h
#ifdef CONFIG_PPC_OF
#include asm/prom.h
@@ -1425,6 +1426,47 @@ int fb_videomode_from_videomode(const struct videomode
*vm,
EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
#endif
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+static inline void dump_fb_videomode(const struct fb_videomode *m)
+{
+ pr_debug(fb_videomode = %ux%u@%uHz (%ukHz) %u %u %u %u %u %u %u %u
%u\n,
+m-xres, m-yres, m-refresh, m-pixclock, m-left_margin,
+m-right_margin, m-upper_margin, m-lower_margin,
+m-hsync_len, m-vsync_len, m-sync, m-vmode, m-flag);
+}
+
+/**
+ * of_get_fb_videomode - get a fb_videomode from devicetree
+ * @np: device_node with the timing specification
+ * @fb: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * DESCRIPTION:
+ * This function is expensive and should only be used, if only one mode is to
be
+ * read from DT. To get multiple modes start with of_get_display_timings ond
+ * work with that instead.
+ */
+int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb,
+ int index)
+{
+ struct videomode vm;
+ int ret;
+
+ ret = of_get_videomode(np, vm, index);
+ if (ret)
+ return ret;
+
+ fb_videomode_from_videomode(vm, fb);
+
+ pr_debug(%s: got %dx%d display mode from %s\n,
+ of_node_full_name(np), vm.hactive, vm.vactive, np-name);
+ dump_fb_videomode(fb);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_fb_videomode);
+#endif
+
#else
int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
{
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 100a176..58b9860 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -20,6 +20,7 @@ struct fb_info;
struct device;
struct file;
struct videomode;
+struct device_node;
/* Definitions below are used in the parsed monitor specs */
#define FB_DPMS_ACTIVE_OFF 1
@@ -715,6 +716,9 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb);
extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);
+extern int of_get_fb_videomode(struct device_node *np,
+ struct fb_videomode *fb,
+ int index);
extern int fb_videomode_from_videomode(const struct videomode *vm,
struct fb_videomode *fbmode);
--
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
[PATCHv16 1/7] viafb: rename display_timing to via_display_timing
The struct display_timing is specific to the via subsystem. The naming leads to
collisions with the new struct display_timing, which is supposed to be a shared
struct between different subsystems.
To clean this up, prepend the existing struct with the subsystem it is specific
to.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/video/via/hw.c |6 +++---
drivers/video/via/hw.h |2 +-
drivers/video/via/lcd.c |2 +-
drivers/video/via/share.h |2 +-
drivers/video/via/via_modesetting.c |8
drivers/video/via/via_modesetting.h |6 +++---
6 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index 898590d..5563c67 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -1467,10 +1467,10 @@ void viafb_set_vclock(u32 clk, int set_iga)
via_write_misc_reg_mask(0x0C, 0x0C); /* select external clock */
}
-struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
+struct via_display_timing var_to_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres)
{
- struct display_timing timing;
+ struct via_display_timing timing;
u16 dx = (var-xres - cxres) / 2, dy = (var-yres - cyres) / 2;
timing.hor_addr = cxres;
@@ -1491,7 +1491,7 @@ struct display_timing var_to_timing(const struct
fb_var_screeninfo *var,
void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres, int iga)
{
- struct display_timing crt_reg = var_to_timing(var,
+ struct via_display_timing crt_reg = var_to_timing(var,
cxres ? cxres : var-xres, cyres ? cyres : var-yres);
if (iga == IGA1)
diff --git a/drivers/video/via/hw.h b/drivers/video/via/hw.h
index 6be243c..c3f2572 100644
--- a/drivers/video/via/hw.h
+++ b/drivers/video/via/hw.h
@@ -637,7 +637,7 @@ extern int viafb_LCD_ON;
extern int viafb_DVI_ON;
extern int viafb_hotplug;
-struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
+struct via_display_timing var_to_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres);
void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres, int iga);
diff --git a/drivers/video/via/lcd.c b/drivers/video/via/lcd.c
index 1650379..022b0df 100644
--- a/drivers/video/via/lcd.c
+++ b/drivers/video/via/lcd.c
@@ -549,7 +549,7 @@ void viafb_lcd_set_mode(const struct fb_var_screeninfo
*var, u16 cxres,
int panel_hres = plvds_setting_info-lcd_panel_hres;
int panel_vres = plvds_setting_info-lcd_panel_vres;
u32 clock;
- struct display_timing timing;
+ struct via_display_timing timing;
struct fb_var_screeninfo panel_var;
const struct fb_videomode *mode_crt_table, *panel_crt_table;
diff --git a/drivers/video/via/share.h b/drivers/video/via/share.h
index 3158dfc..65c65c6 100644
--- a/drivers/video/via/share.h
+++ b/drivers/video/via/share.h
@@ -319,7 +319,7 @@ struct crt_mode_table {
int refresh_rate;
int h_sync_polarity;
int v_sync_polarity;
- struct display_timing crtc;
+ struct via_display_timing crtc;
};
struct io_reg {
diff --git a/drivers/video/via/via_modesetting.c
b/drivers/video/via/via_modesetting.c
index 0e431ae..0b414b0 100644
--- a/drivers/video/via/via_modesetting.c
+++ b/drivers/video/via/via_modesetting.c
@@ -30,9 +30,9 @@
#include debug.h
-void via_set_primary_timing(const struct display_timing *timing)
+void via_set_primary_timing(const struct via_display_timing *timing)
{
- struct display_timing raw;
+ struct via_display_timing raw;
raw.hor_total = timing-hor_total / 8 - 5;
raw.hor_addr = timing-hor_addr / 8 - 1;
@@ -88,9 +88,9 @@ void via_set_primary_timing(const struct display_timing
*timing)
via_write_reg_mask(VIACR, 0x17, 0x80, 0x80);
}
-void via_set_secondary_timing(const struct display_timing *timing)
+void via_set_secondary_timing(const struct via_display_timing *timing)
{
- struct display_timing raw;
+ struct via_display_timing raw;
raw.hor_total = timing-hor_total - 1;
raw.hor_addr = timing-hor_addr - 1;
diff --git a/drivers/video/via/via_modesetting.h
b/drivers/video/via/via_modesetting.h
index 06e09fe..f6a6503 100644
--- a/drivers/video/via/via_modesetting.h
+++ b/drivers/video/via/via_modesetting.h
@@ -33,7 +33,7 @@
#define VIA_PITCH_MAX 0x3FF8
-struct display_timing {
+struct via_display_timing {
u16 hor_total;
u16 hor_addr;
u16 hor_blank_start;
@@ -49,8 +49,8 @@ struct display_timing {
};
-void via_set_primary_timing(const struct display_timing *timing);
-void via_set_secondary_timing(const struct display_timing *timing);
+void via_set_primary_timing(const struct via_display_timing *timing);
+void via_set_secondary_timing(const struct via_display_timing
[PATCHv16 2/7] video: add display_timing and videomode
Add display_timing structure and the according helper functions. This allows
the description of a display via its supported timing parameters.
Also, add helper functions to convert from display timings to a generic
videomode
structure.
The struct display_timing specifies all needed parameters to describe the signal
properties of a display in one mode. This includes
- ranges for signals that may have min-, max- and typical values
- single integers for signals that can be on, off or are ignored
- booleans for signals that are either on or off
As a display may support multiple modes like this, a struct display_timings is
added, that holds all given struct display_timing pointers and declares the
native mode of the display.
Although a display may state that a signal can be in a range, it is driven with
fixed values that indicate a videomode. Therefore graphic drivers don't need all
the information of struct display_timing, but would generate a videomode from
the given set of supported signal timings and work with that.
The video subsystems all define their own structs that describe a mode and work
with that (e.g. fb_videomode or drm_display_mode). To slowly replace all those
various structures and allow code reuse across those subsystems, add struct
videomode as a generic description.
This patch only includes the most basic fields in struct videomode. All missing
fields that are needed to have a really generic video mode description can be
added at a later stage.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/Kconfig |6 ++
drivers/video/Makefile |2 +
drivers/video/display_timing.c | 24
drivers/video/videomode.c | 39 +
include/video/display_timing.h | 124
include/video/videomode.h | 48
6 files changed, 243 insertions(+)
create mode 100644 drivers/video/display_timing.c
create mode 100644 drivers/video/videomode.c
create mode 100644 include/video/display_timing.h
create mode 100644 include/video/videomode.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d08d799..2a23b18 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -33,6 +33,12 @@ config VIDEO_OUTPUT_CONTROL
This framework adds support for low-level control of the video
output switch.
+config DISPLAY_TIMING
+ bool
+
+config VIDEOMODE
+ bool
+
menuconfig FB
tristate Support for frame buffer devices
---help---
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 23e948e..fc30439 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -167,3 +167,5 @@ obj-$(CONFIG_FB_VIRTUAL) += vfb.o
#video output switch sysfs driver
obj-$(CONFIG_VIDEO_OUTPUT_CONTROL) += output.o
+obj-$(CONFIG_DISPLAY_TIMING) += display_timing.o
+obj-$(CONFIG_VIDEOMODE) += videomode.o
diff --git a/drivers/video/display_timing.c b/drivers/video/display_timing.c
new file mode 100644
index 000..5e1822c
--- /dev/null
+++ b/drivers/video/display_timing.c
@@ -0,0 +1,24 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar s.trumt...@pengutronix.de, Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+
+#include linux/export.h
+#include linux/slab.h
+#include video/display_timing.h
+
+void display_timings_release(struct display_timings *disp)
+{
+ if (disp-timings) {
+ unsigned int i;
+
+ for (i = 0; i disp-num_timings; i++)
+ kfree(disp-timings[i]);
+ kfree(disp-timings);
+ }
+ kfree(disp);
+}
+EXPORT_SYMBOL_GPL(display_timings_release);
diff --git a/drivers/video/videomode.c b/drivers/video/videomode.c
new file mode 100644
index 000..21c47a2
--- /dev/null
+++ b/drivers/video/videomode.c
@@ -0,0 +1,39 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar s.trumt...@pengutronix.de, Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+
+#include linux/errno.h
+#include linux/export.h
+#include video/display_timing.h
+#include video/videomode.h
+
+int videomode_from_timing(const struct display_timings *disp,
+ struct videomode *vm, unsigned int index)
+{
+ struct display_timing *dt;
+
+ dt = display_timings_get(disp, index);
+ if (!dt)
+ return -EINVAL;
+
+ vm-pixelclock = display_timing_get_value(dt-pixelclock, TE_TYP);
+ vm-hactive = display_timing_get_value(dt-hactive, TE_TYP);
+ vm-hfront_porch =
[PATCHv16 0/7] of: add display helper
Hi!
Finally, right in time before the end of the world on friday, v16 of the
display helpers.
Changes since v15:
- move include/linux/{videomode,display_timing}.h to include/video
- move include/linux/of_{videomode,display_timing}.h to include/video
- reimplement flags: add VESA flags and data flags
- let pixelclock in struct videomode be unsigned long
- rename of_display_timings_exists to of_display_timings_exist
- revise logging/error messages: replace __func__ with np-full_name
- rename pixelclk-inverted to pixelclk-active
- revise comments in code
Changes since v14:
- fix const struct * warning
(reported by: Leela Krishna Amudala l.kris...@samsung.com)
- return -EINVAL when htotal or vtotal are zero
- remove unreachable code in of_get_display_timings
- include headers in .c files and not implicit in .h
- sort includes alphabetically
- fix lower/uppercase in binding documentation
- rebase onto v3.7-rc7
Changes since v13:
- fix const struct * warning
(reported by: Laurent Pinchart
laurent.pinch...@ideasonboard.com)
- prevent division by zero in fb_videomode_from_videomode
Changes since v12:
- rename struct display_timing to via_display_timing in via subsystem
- fix refreshrate calculation
- fix const struct * warnings
(reported by: Manjunathappa, Prakash prakash...@ti.com)
- some CodingStyle fixes
- rewrite parts of commit messages and display-timings.txt
- let display_timing_get_value get all values instead of just typical
Changes since v11:
- make pointers const where applicable
- add reviewed-by Laurent Pinchart
Changes since v10:
- fix function name (drm_)display_mode_from_videomode
- add acked-by, reviewed-by, tested-by
Changes since v9:
- don't leak memory when previous timings were correct
- CodingStyle fixes
- move blank lines around
Changes since v8:
- fix memory leaks
- change API to be more consistent (foo_from_bar(struct bar, struct
foo))
- include headers were necessary
- misc minor bugfixes
Changes since v7:
- move of_xxx to drivers/video
- remove non-binding documentation from display-timings.txt
- squash display_timings and videomode in one patch
- misc minor fixes
Changes since v6:
- get rid of some empty lines etc.
- move functions to their subsystems
- split of_ from non-of_ functions
- add at least some kerneldoc to some functions
Changes since v5:
- removed all display stuff and just describe timings
Changes since v4:
- refactored functions
Changes since v3:
- print error messages
- free alloced memory
- general cleanup
Changes since v2:
- use hardware-near property-names
- provide a videomode structure
- allow ranges for all properties (min,typ,max)
- functions to get display_mode or fb_videomode
Regards,
Steffen
Steffen Trumtrar (7):
viafb: rename display_timing to via_display_timing
video: add display_timing and videomode
video: add of helper for display timings/videomode
fbmon: add videomode helpers
fbmon: add of_videomode helpers
drm_modes: add videomode helpers
drm_modes: add of_videomode helpers
.../devicetree/bindings/video/display-timing.txt | 109 +
drivers/gpu/drm/drm_modes.c| 70 ++
drivers/video/Kconfig | 21 ++
drivers/video/Makefile |4 +
drivers/video/display_timing.c | 24 ++
drivers/video/fbmon.c | 94
drivers/video/of_display_timing.c | 239
drivers/video/of_videomode.c | 54 +
drivers/video/via/hw.c |6 +-
drivers/video/via/hw.h |2 +-
drivers/video/via/lcd.c|2 +-
drivers/video/via/share.h |2 +-
drivers/video/via/via_modesetting.c|8 +-
drivers/video/via/via_modesetting.h|6 +-
drivers/video/videomode.c | 39
include/drm/drmP.h |9 +
include/linux/fb.h |8 +
include/video/display_timing.h | 124 ++
include/video/of_display_timing.h | 20 ++
include/video/of_videomode.h | 18 ++
include/video/videomode.h | 48
21 files changed, 894 insertions(+), 13 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/display-timing.txt
create mode 100644
[PATCHv16 6/7] drm_modes: add videomode helpers
Add conversion from videomode to drm_display_mode
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/gpu/drm/drm_modes.c | 37 +
include/drm/drmP.h |5 +
2 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 59450f3..184a22d 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -35,6 +35,7 @@
#include linux/export.h
#include drm/drmP.h
#include drm/drm_crtc.h
+#include video/videomode.h
/**
* drm_mode_debug_printmodeline - debug print a mode
@@ -504,6 +505,42 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int
vdisplay, int vrefresh,
}
EXPORT_SYMBOL(drm_gtf_mode);
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int drm_display_mode_from_videomode(const struct videomode *vm,
+ struct drm_display_mode *dmode)
+{
+ dmode-hdisplay = vm-hactive;
+ dmode-hsync_start = dmode-hdisplay + vm-hfront_porch;
+ dmode-hsync_end = dmode-hsync_start + vm-hsync_len;
+ dmode-htotal = dmode-hsync_end + vm-hback_porch;
+
+ dmode-vdisplay = vm-vactive;
+ dmode-vsync_start = dmode-vdisplay + vm-vfront_porch;
+ dmode-vsync_end = dmode-vsync_start + vm-vsync_len;
+ dmode-vtotal = dmode-vsync_end + vm-vback_porch;
+
+ dmode-clock = vm-pixelclock / 1000;
+
+ dmode-flags = 0;
+ if (vm-dmt_flags VESA_DMT_HSYNC_HIGH)
+ dmode-flags |= DRM_MODE_FLAG_PHSYNC;
+ else if (vm-dmt_flags VESA_DMT_HSYNC_LOW)
+ dmode-flags |= DRM_MODE_FLAG_NHSYNC;
+ if (vm-dmt_flags VESA_DMT_VSYNC_HIGH)
+ dmode-flags |= DRM_MODE_FLAG_PVSYNC;
+ else if (vm-dmt_flags VESA_DMT_VSYNC_LOW)
+ dmode-flags |= DRM_MODE_FLAG_NVSYNC;
+ if (vm-data_flags DISPLAY_FLAGS_INTERLACED)
+ dmode-flags |= DRM_MODE_FLAG_INTERLACE;
+ if (vm-data_flags DISPLAY_FLAGS_DOUBLESCAN)
+ dmode-flags |= DRM_MODE_FLAG_DBLSCAN;
+ drm_mode_set_name(dmode);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(drm_display_mode_from_videomode);
+#endif
+
/**
* drm_mode_set_name - set the name on a mode
* @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3fd8280..5fbb0fe 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -85,6 +85,8 @@ struct module;
struct drm_file;
struct drm_device;
+struct videomode;
+
#include drm/drm_os_linux.h
#include drm/drm_hashtab.h
#include drm/drm_mm.h
@@ -1454,6 +1456,9 @@ extern struct drm_display_mode *
drm_mode_create_from_cmdline_mode(struct drm_device *dev,
struct drm_cmdline_mode *cmd);
+extern int drm_display_mode_from_videomode(const struct videomode *vm,
+ struct drm_display_mode *dmode);
+
/* Modesetting support */
extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
extern void drm_vblank_post_modeset(struct drm_device *dev, int crtc);
--
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
[PATCHv16 6/7] drm_modes: add videomode helpers
Add conversion from videomode to drm_display_mode
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/gpu/drm/drm_modes.c | 37 +
include/drm/drmP.h |5 +
2 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 59450f3..184a22d 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -35,6 +35,7 @@
#include linux/export.h
#include drm/drmP.h
#include drm/drm_crtc.h
+#include video/videomode.h
/**
* drm_mode_debug_printmodeline - debug print a mode
@@ -504,6 +505,42 @@ drm_gtf_mode(struct drm_device *dev, int hdisplay, int
vdisplay, int vrefresh,
}
EXPORT_SYMBOL(drm_gtf_mode);
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int drm_display_mode_from_videomode(const struct videomode *vm,
+ struct drm_display_mode *dmode)
+{
+ dmode-hdisplay = vm-hactive;
+ dmode-hsync_start = dmode-hdisplay + vm-hfront_porch;
+ dmode-hsync_end = dmode-hsync_start + vm-hsync_len;
+ dmode-htotal = dmode-hsync_end + vm-hback_porch;
+
+ dmode-vdisplay = vm-vactive;
+ dmode-vsync_start = dmode-vdisplay + vm-vfront_porch;
+ dmode-vsync_end = dmode-vsync_start + vm-vsync_len;
+ dmode-vtotal = dmode-vsync_end + vm-vback_porch;
+
+ dmode-clock = vm-pixelclock / 1000;
+
+ dmode-flags = 0;
+ if (vm-dmt_flags VESA_DMT_HSYNC_HIGH)
+ dmode-flags |= DRM_MODE_FLAG_PHSYNC;
+ else if (vm-dmt_flags VESA_DMT_HSYNC_LOW)
+ dmode-flags |= DRM_MODE_FLAG_NHSYNC;
+ if (vm-dmt_flags VESA_DMT_VSYNC_HIGH)
+ dmode-flags |= DRM_MODE_FLAG_PVSYNC;
+ else if (vm-dmt_flags VESA_DMT_VSYNC_LOW)
+ dmode-flags |= DRM_MODE_FLAG_NVSYNC;
+ if (vm-data_flags DISPLAY_FLAGS_INTERLACED)
+ dmode-flags |= DRM_MODE_FLAG_INTERLACE;
+ if (vm-data_flags DISPLAY_FLAGS_DOUBLESCAN)
+ dmode-flags |= DRM_MODE_FLAG_DBLSCAN;
+ drm_mode_set_name(dmode);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(drm_display_mode_from_videomode);
+#endif
+
/**
* drm_mode_set_name - set the name on a mode
* @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3fd8280..5fbb0fe 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -85,6 +85,8 @@ struct module;
struct drm_file;
struct drm_device;
+struct videomode;
+
#include drm/drm_os_linux.h
#include drm/drm_hashtab.h
#include drm/drm_mm.h
@@ -1454,6 +1456,9 @@ extern struct drm_display_mode *
drm_mode_create_from_cmdline_mode(struct drm_device *dev,
struct drm_cmdline_mode *cmd);
+extern int drm_display_mode_from_videomode(const struct videomode *vm,
+ struct drm_display_mode *dmode);
+
/* Modesetting support */
extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
extern void drm_vblank_post_modeset(struct drm_device *dev, int crtc);
--
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
[PATCHv16 4/7] fbmon: add videomode helpers
Add a function to convert from the generic videomode to a fb_videomode.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/fbmon.c | 52 +
include/linux/fb.h|4
2 files changed, 56 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index cef6557..17ce135 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,6 +31,7 @@
#include linux/pci.h
#include linux/slab.h
#include video/edid.h
+#include video/videomode.h
#ifdef CONFIG_PPC_OF
#include asm/prom.h
#include asm/pci-bridge.h
@@ -1373,6 +1374,57 @@ int fb_get_mode(int flags, u32 val, struct
fb_var_screeninfo *var, struct fb_inf
kfree(timings);
return err;
}
+
+#if IS_ENABLED(CONFIG_VIDEOMODE)
+int fb_videomode_from_videomode(const struct videomode *vm,
+ struct fb_videomode *fbmode)
+{
+ unsigned int htotal, vtotal;
+
+ fbmode-xres = vm-hactive;
+ fbmode-left_margin = vm-hback_porch;
+ fbmode-right_margin = vm-hfront_porch;
+ fbmode-hsync_len = vm-hsync_len;
+
+ fbmode-yres = vm-vactive;
+ fbmode-upper_margin = vm-vback_porch;
+ fbmode-lower_margin = vm-vfront_porch;
+ fbmode-vsync_len = vm-vsync_len;
+
+ /* prevent division by zero in KHZ2PICOS macro */
+ fbmode-pixclock = vm-pixelclock ?
+ KHZ2PICOS(vm-pixelclock / 1000) : 0;
+
+ fbmode-sync = 0;
+ fbmode-vmode = 0;
+ if (vm-dmt_flags VESA_DMT_HSYNC_HIGH)
+ fbmode-sync |= FB_SYNC_HOR_HIGH_ACT;
+ if (vm-dmt_flags VESA_DMT_HSYNC_HIGH)
+ fbmode-sync |= FB_SYNC_VERT_HIGH_ACT;
+ if (vm-data_flags DISPLAY_FLAGS_INTERLACED)
+ fbmode-vmode |= FB_VMODE_INTERLACED;
+ if (vm-data_flags DISPLAY_FLAGS_DOUBLESCAN)
+ fbmode-vmode |= FB_VMODE_DOUBLE;
+ fbmode-flag = 0;
+
+ htotal = vm-hactive + vm-hfront_porch + vm-hback_porch +
+vm-hsync_len;
+ vtotal = vm-vactive + vm-vfront_porch + vm-vback_porch +
+vm-vsync_len;
+ /* prevent division by zero */
+ if (htotal vtotal) {
+ fbmode-refresh = vm-pixelclock / (htotal * vtotal);
+ /* a mode must have htotal and vtotal != 0 or it is invalid */
+ } else {
+ fbmode-refresh = 0;
+ return -EINVAL;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
+#endif
+
#else
int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
{
diff --git a/include/linux/fb.h b/include/linux/fb.h
index c7a9571..100a176 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -19,6 +19,7 @@ struct vm_area_struct;
struct fb_info;
struct device;
struct file;
+struct videomode;
/* Definitions below are used in the parsed monitor specs */
#define FB_DPMS_ACTIVE_OFF 1
@@ -714,6 +715,9 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb);
extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);
+extern int fb_videomode_from_videomode(const struct videomode *vm,
+ struct fb_videomode *fbmode);
+
/* drivers/video/modedb.c */
#define VESA_MODEDB_SIZE 34
extern void fb_var_to_videomode(struct fb_videomode *mode,
--
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
[PATCHv16 3/7] video: add of helper for display timings/videomode
This adds support for reading display timings from DT into a struct display_timings. The of_display_timing implementation supports multiple subnodes. All children are read into an array, that can be queried. If no native mode is specified, the first subnode will be used. For cases where the graphics driver knows there can be only one mode description or where the driver only supports one mode, a helper function of_get_videomode is added, that gets a struct videomode from DT. Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de Signed-off-by: Philipp Zabel p.za...@pengutronix.de Acked-by: Stephen Warren swar...@nvidia.com Reviewed-by: Thierry Reding thierry.red...@avionic-design.de Acked-by: Thierry Reding thierry.red...@avionic-design.de Tested-by: Thierry Reding thierry.red...@avionic-design.de Tested-by: Philipp Zabel p.za...@pengutronix.de Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- .../devicetree/bindings/video/display-timing.txt | 109 + drivers/video/Kconfig | 15 ++ drivers/video/Makefile |2 + drivers/video/of_display_timing.c | 239 drivers/video/of_videomode.c | 54 + include/video/of_display_timing.h | 20 ++ include/video/of_videomode.h | 18 ++ 7 files changed, 457 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/display-timing.txt create mode 100644 drivers/video/of_display_timing.c create mode 100644 drivers/video/of_videomode.c create mode 100644 include/video/of_display_timing.h create mode 100644 include/video/of_videomode.h diff --git a/Documentation/devicetree/bindings/video/display-timing.txt b/Documentation/devicetree/bindings/video/display-timing.txt new file mode 100644 index 000..1500385 --- /dev/null +++ b/Documentation/devicetree/bindings/video/display-timing.txt @@ -0,0 +1,109 @@ +display-timing bindings +=== + +display-timings node + + +required properties: + - none + +optional properties: + - native-mode: The native mode for the display, in case multiple modes are + provided. When omitted, assume the first node is the native. + +timing subnode +-- + +required properties: + - hactive, vactive: display resolution + - hfront-porch, hback-porch, hsync-len: horizontal display timing parameters + in pixels + vfront-porch, vback-porch, vsync-len: vertical display timing parameters in + lines + - clock-frequency: display clock in Hz + +optional properties: + - hsync-active: hsync pulse is active low/high/ignored + - vsync-active: vsync pulse is active low/high/ignored + - de-active: data-enable pulse is active low/high/ignored + - pixelclk-active: with + - active high = drive pixel data on rising edge/ + sample data on falling edge + - active low = drive pixel data on falling edge/ + sample data on rising edge + - ignored = ignored + - interlaced (bool): boolean to enable interlaced mode + - doublescan (bool): boolean to enable doublescan mode + +All the optional properties that are not bool follow the following logic: +1: high active +0: low active +omitted: not used on hardware + +There are different ways of describing the capabilities of a display. The +devicetree representation corresponds to the one commonly found in datasheets +for displays. If a display supports multiple signal timings, the native-mode +can be specified. + +The parameters are defined as: + + +--+-+--+---+ + | |↑| | | + | ||vback_porch | | | + | |↓| | | + +--###--+---+ + | #↑# | | + | #|# | | + | hback #|# hfront | hsync | + | porch #| hactive # porch | len | + |#---+---#|-| + | #|# | | + | #|vactive # | | + | #|# | | + | #↓# | | + +--###--+---+ + | |↑| | | + | ||vfront_porch
[PATCHv16 2/7] video: add display_timing and videomode
Add display_timing structure and the according helper functions. This allows
the description of a display via its supported timing parameters.
Also, add helper functions to convert from display timings to a generic
videomode
structure.
The struct display_timing specifies all needed parameters to describe the signal
properties of a display in one mode. This includes
- ranges for signals that may have min-, max- and typical values
- single integers for signals that can be on, off or are ignored
- booleans for signals that are either on or off
As a display may support multiple modes like this, a struct display_timings is
added, that holds all given struct display_timing pointers and declares the
native mode of the display.
Although a display may state that a signal can be in a range, it is driven with
fixed values that indicate a videomode. Therefore graphic drivers don't need all
the information of struct display_timing, but would generate a videomode from
the given set of supported signal timings and work with that.
The video subsystems all define their own structs that describe a mode and work
with that (e.g. fb_videomode or drm_display_mode). To slowly replace all those
various structures and allow code reuse across those subsystems, add struct
videomode as a generic description.
This patch only includes the most basic fields in struct videomode. All missing
fields that are needed to have a really generic video mode description can be
added at a later stage.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/Kconfig |6 ++
drivers/video/Makefile |2 +
drivers/video/display_timing.c | 24
drivers/video/videomode.c | 39 +
include/video/display_timing.h | 124
include/video/videomode.h | 48
6 files changed, 243 insertions(+)
create mode 100644 drivers/video/display_timing.c
create mode 100644 drivers/video/videomode.c
create mode 100644 include/video/display_timing.h
create mode 100644 include/video/videomode.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d08d799..2a23b18 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -33,6 +33,12 @@ config VIDEO_OUTPUT_CONTROL
This framework adds support for low-level control of the video
output switch.
+config DISPLAY_TIMING
+ bool
+
+config VIDEOMODE
+ bool
+
menuconfig FB
tristate Support for frame buffer devices
---help---
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 23e948e..fc30439 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -167,3 +167,5 @@ obj-$(CONFIG_FB_VIRTUAL) += vfb.o
#video output switch sysfs driver
obj-$(CONFIG_VIDEO_OUTPUT_CONTROL) += output.o
+obj-$(CONFIG_DISPLAY_TIMING) += display_timing.o
+obj-$(CONFIG_VIDEOMODE) += videomode.o
diff --git a/drivers/video/display_timing.c b/drivers/video/display_timing.c
new file mode 100644
index 000..5e1822c
--- /dev/null
+++ b/drivers/video/display_timing.c
@@ -0,0 +1,24 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar s.trumt...@pengutronix.de, Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+
+#include linux/export.h
+#include linux/slab.h
+#include video/display_timing.h
+
+void display_timings_release(struct display_timings *disp)
+{
+ if (disp-timings) {
+ unsigned int i;
+
+ for (i = 0; i disp-num_timings; i++)
+ kfree(disp-timings[i]);
+ kfree(disp-timings);
+ }
+ kfree(disp);
+}
+EXPORT_SYMBOL_GPL(display_timings_release);
diff --git a/drivers/video/videomode.c b/drivers/video/videomode.c
new file mode 100644
index 000..21c47a2
--- /dev/null
+++ b/drivers/video/videomode.c
@@ -0,0 +1,39 @@
+/*
+ * generic display timing functions
+ *
+ * Copyright (c) 2012 Steffen Trumtrar s.trumt...@pengutronix.de, Pengutronix
+ *
+ * This file is released under the GPLv2
+ */
+
+#include linux/errno.h
+#include linux/export.h
+#include video/display_timing.h
+#include video/videomode.h
+
+int videomode_from_timing(const struct display_timings *disp,
+ struct videomode *vm, unsigned int index)
+{
+ struct display_timing *dt;
+
+ dt = display_timings_get(disp, index);
+ if (!dt)
+ return -EINVAL;
+
+ vm-pixelclock = display_timing_get_value(dt-pixelclock, TE_TYP);
+ vm-hactive = display_timing_get_value(dt-hactive, TE_TYP);
+ vm-hfront_porch =
[PATCHv16 7/7] drm_modes: add of_videomode helpers
Add helper to get drm_display_mode from devicetree.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/gpu/drm/drm_modes.c | 33 +
include/drm/drmP.h |4
2 files changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 184a22d..fd53454 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -35,6 +35,7 @@
#include linux/export.h
#include drm/drmP.h
#include drm/drm_crtc.h
+#include video/of_videomode.h
#include video/videomode.h
/**
@@ -541,6 +542,38 @@ int drm_display_mode_from_videomode(const struct videomode
*vm,
EXPORT_SYMBOL_GPL(drm_display_mode_from_videomode);
#endif
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+/**
+ * of_get_drm_display_mode - get a drm_display_mode from devicetree
+ * @np: device_node with the timing specification
+ * @dmode: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * This function is expensive and should only be used, if only one mode is to
be
+ * read from DT. To get multiple modes start with of_get_display_timings and
+ * work with that instead.
+ */
+int of_get_drm_display_mode(struct device_node *np,
+ struct drm_display_mode *dmode, int index)
+{
+ struct videomode vm;
+ int ret;
+
+ ret = of_get_videomode(np, vm, index);
+ if (ret)
+ return ret;
+
+ drm_display_mode_from_videomode(vm, dmode);
+
+ pr_debug(%s: got %dx%d display mode from %s\n,
+ of_node_full_name(np), vm.hactive, vm.vactive, np-name);
+ drm_mode_debug_printmodeline(dmode);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
+#endif
+
/**
* drm_mode_set_name - set the name on a mode
* @mode: name will be set in this mode
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 5fbb0fe..e26ca59 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -85,6 +85,7 @@ struct module;
struct drm_file;
struct drm_device;
+struct device_node;
struct videomode;
#include drm/drm_os_linux.h
@@ -1458,6 +1459,9 @@ drm_mode_create_from_cmdline_mode(struct drm_device *dev,
extern int drm_display_mode_from_videomode(const struct videomode *vm,
struct drm_display_mode *dmode);
+extern int of_get_drm_display_mode(struct device_node *np,
+ struct drm_display_mode *dmode,
+ int index);
/* Modesetting support */
extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
--
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
[PATCHv16 0/7] of: add display helper
Hi!
Finally, right in time before the end of the world on friday, v16 of the
display helpers.
Changes since v15:
- move include/linux/{videomode,display_timing}.h to include/video
- move include/linux/of_{videomode,display_timing}.h to include/video
- reimplement flags: add VESA flags and data flags
- let pixelclock in struct videomode be unsigned long
- rename of_display_timings_exists to of_display_timings_exist
- revise logging/error messages: replace __func__ with np-full_name
- rename pixelclk-inverted to pixelclk-active
- revise comments in code
Changes since v14:
- fix const struct * warning
(reported by: Leela Krishna Amudala l.kris...@samsung.com)
- return -EINVAL when htotal or vtotal are zero
- remove unreachable code in of_get_display_timings
- include headers in .c files and not implicit in .h
- sort includes alphabetically
- fix lower/uppercase in binding documentation
- rebase onto v3.7-rc7
Changes since v13:
- fix const struct * warning
(reported by: Laurent Pinchart
laurent.pinch...@ideasonboard.com)
- prevent division by zero in fb_videomode_from_videomode
Changes since v12:
- rename struct display_timing to via_display_timing in via subsystem
- fix refreshrate calculation
- fix const struct * warnings
(reported by: Manjunathappa, Prakash prakash...@ti.com)
- some CodingStyle fixes
- rewrite parts of commit messages and display-timings.txt
- let display_timing_get_value get all values instead of just typical
Changes since v11:
- make pointers const where applicable
- add reviewed-by Laurent Pinchart
Changes since v10:
- fix function name (drm_)display_mode_from_videomode
- add acked-by, reviewed-by, tested-by
Changes since v9:
- don't leak memory when previous timings were correct
- CodingStyle fixes
- move blank lines around
Changes since v8:
- fix memory leaks
- change API to be more consistent (foo_from_bar(struct bar, struct
foo))
- include headers were necessary
- misc minor bugfixes
Changes since v7:
- move of_xxx to drivers/video
- remove non-binding documentation from display-timings.txt
- squash display_timings and videomode in one patch
- misc minor fixes
Changes since v6:
- get rid of some empty lines etc.
- move functions to their subsystems
- split of_ from non-of_ functions
- add at least some kerneldoc to some functions
Changes since v5:
- removed all display stuff and just describe timings
Changes since v4:
- refactored functions
Changes since v3:
- print error messages
- free alloced memory
- general cleanup
Changes since v2:
- use hardware-near property-names
- provide a videomode structure
- allow ranges for all properties (min,typ,max)
- functions to get display_mode or fb_videomode
Regards,
Steffen
Steffen Trumtrar (7):
viafb: rename display_timing to via_display_timing
video: add display_timing and videomode
video: add of helper for display timings/videomode
fbmon: add videomode helpers
fbmon: add of_videomode helpers
drm_modes: add videomode helpers
drm_modes: add of_videomode helpers
.../devicetree/bindings/video/display-timing.txt | 109 +
drivers/gpu/drm/drm_modes.c| 70 ++
drivers/video/Kconfig | 21 ++
drivers/video/Makefile |4 +
drivers/video/display_timing.c | 24 ++
drivers/video/fbmon.c | 94
drivers/video/of_display_timing.c | 239
drivers/video/of_videomode.c | 54 +
drivers/video/via/hw.c |6 +-
drivers/video/via/hw.h |2 +-
drivers/video/via/lcd.c|2 +-
drivers/video/via/share.h |2 +-
drivers/video/via/via_modesetting.c|8 +-
drivers/video/via/via_modesetting.h|6 +-
drivers/video/videomode.c | 39
include/drm/drmP.h |9 +
include/linux/fb.h |8 +
include/video/display_timing.h | 124 ++
include/video/of_display_timing.h | 20 ++
include/video/of_videomode.h | 18 ++
include/video/videomode.h | 48
21 files changed, 894 insertions(+), 13 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/display-timing.txt
create mode 100644
[PATCHv16 5/7] fbmon: add of_videomode helpers
Add helper to get fb_videomode from devicetree.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
Acked-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Thierry Reding thierry.red...@avionic-design.de
Tested-by: Philipp Zabel p.za...@pengutronix.de
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/video/fbmon.c | 42 ++
include/linux/fb.h|4
2 files changed, 46 insertions(+)
diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
index 17ce135..94ad0f7 100644
--- a/drivers/video/fbmon.c
+++ b/drivers/video/fbmon.c
@@ -31,6 +31,7 @@
#include linux/pci.h
#include linux/slab.h
#include video/edid.h
+#include video/of_videomode.h
#include video/videomode.h
#ifdef CONFIG_PPC_OF
#include asm/prom.h
@@ -1425,6 +1426,47 @@ int fb_videomode_from_videomode(const struct videomode
*vm,
EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
#endif
+#if IS_ENABLED(CONFIG_OF_VIDEOMODE)
+static inline void dump_fb_videomode(const struct fb_videomode *m)
+{
+ pr_debug(fb_videomode = %ux%u@%uHz (%ukHz) %u %u %u %u %u %u %u %u
%u\n,
+m-xres, m-yres, m-refresh, m-pixclock, m-left_margin,
+m-right_margin, m-upper_margin, m-lower_margin,
+m-hsync_len, m-vsync_len, m-sync, m-vmode, m-flag);
+}
+
+/**
+ * of_get_fb_videomode - get a fb_videomode from devicetree
+ * @np: device_node with the timing specification
+ * @fb: will be set to the return value
+ * @index: index into the list of display timings in devicetree
+ *
+ * DESCRIPTION:
+ * This function is expensive and should only be used, if only one mode is to
be
+ * read from DT. To get multiple modes start with of_get_display_timings ond
+ * work with that instead.
+ */
+int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb,
+ int index)
+{
+ struct videomode vm;
+ int ret;
+
+ ret = of_get_videomode(np, vm, index);
+ if (ret)
+ return ret;
+
+ fb_videomode_from_videomode(vm, fb);
+
+ pr_debug(%s: got %dx%d display mode from %s\n,
+ of_node_full_name(np), vm.hactive, vm.vactive, np-name);
+ dump_fb_videomode(fb);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_fb_videomode);
+#endif
+
#else
int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
{
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 100a176..58b9860 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -20,6 +20,7 @@ struct fb_info;
struct device;
struct file;
struct videomode;
+struct device_node;
/* Definitions below are used in the parsed monitor specs */
#define FB_DPMS_ACTIVE_OFF 1
@@ -715,6 +716,9 @@ extern void fb_destroy_modedb(struct fb_videomode *modedb);
extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);
+extern int of_get_fb_videomode(struct device_node *np,
+ struct fb_videomode *fb,
+ int index);
extern int fb_videomode_from_videomode(const struct videomode *vm,
struct fb_videomode *fbmode);
--
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
[PATCHv16 1/7] viafb: rename display_timing to via_display_timing
The struct display_timing is specific to the via subsystem. The naming leads to
collisions with the new struct display_timing, which is supposed to be a shared
struct between different subsystems.
To clean this up, prepend the existing struct with the subsystem it is specific
to.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
drivers/video/via/hw.c |6 +++---
drivers/video/via/hw.h |2 +-
drivers/video/via/lcd.c |2 +-
drivers/video/via/share.h |2 +-
drivers/video/via/via_modesetting.c |8
drivers/video/via/via_modesetting.h |6 +++---
6 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/video/via/hw.c b/drivers/video/via/hw.c
index 898590d..5563c67 100644
--- a/drivers/video/via/hw.c
+++ b/drivers/video/via/hw.c
@@ -1467,10 +1467,10 @@ void viafb_set_vclock(u32 clk, int set_iga)
via_write_misc_reg_mask(0x0C, 0x0C); /* select external clock */
}
-struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
+struct via_display_timing var_to_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres)
{
- struct display_timing timing;
+ struct via_display_timing timing;
u16 dx = (var-xres - cxres) / 2, dy = (var-yres - cyres) / 2;
timing.hor_addr = cxres;
@@ -1491,7 +1491,7 @@ struct display_timing var_to_timing(const struct
fb_var_screeninfo *var,
void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres, int iga)
{
- struct display_timing crt_reg = var_to_timing(var,
+ struct via_display_timing crt_reg = var_to_timing(var,
cxres ? cxres : var-xres, cyres ? cyres : var-yres);
if (iga == IGA1)
diff --git a/drivers/video/via/hw.h b/drivers/video/via/hw.h
index 6be243c..c3f2572 100644
--- a/drivers/video/via/hw.h
+++ b/drivers/video/via/hw.h
@@ -637,7 +637,7 @@ extern int viafb_LCD_ON;
extern int viafb_DVI_ON;
extern int viafb_hotplug;
-struct display_timing var_to_timing(const struct fb_var_screeninfo *var,
+struct via_display_timing var_to_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres);
void viafb_fill_crtc_timing(const struct fb_var_screeninfo *var,
u16 cxres, u16 cyres, int iga);
diff --git a/drivers/video/via/lcd.c b/drivers/video/via/lcd.c
index 1650379..022b0df 100644
--- a/drivers/video/via/lcd.c
+++ b/drivers/video/via/lcd.c
@@ -549,7 +549,7 @@ void viafb_lcd_set_mode(const struct fb_var_screeninfo
*var, u16 cxres,
int panel_hres = plvds_setting_info-lcd_panel_hres;
int panel_vres = plvds_setting_info-lcd_panel_vres;
u32 clock;
- struct display_timing timing;
+ struct via_display_timing timing;
struct fb_var_screeninfo panel_var;
const struct fb_videomode *mode_crt_table, *panel_crt_table;
diff --git a/drivers/video/via/share.h b/drivers/video/via/share.h
index 3158dfc..65c65c6 100644
--- a/drivers/video/via/share.h
+++ b/drivers/video/via/share.h
@@ -319,7 +319,7 @@ struct crt_mode_table {
int refresh_rate;
int h_sync_polarity;
int v_sync_polarity;
- struct display_timing crtc;
+ struct via_display_timing crtc;
};
struct io_reg {
diff --git a/drivers/video/via/via_modesetting.c
b/drivers/video/via/via_modesetting.c
index 0e431ae..0b414b0 100644
--- a/drivers/video/via/via_modesetting.c
+++ b/drivers/video/via/via_modesetting.c
@@ -30,9 +30,9 @@
#include debug.h
-void via_set_primary_timing(const struct display_timing *timing)
+void via_set_primary_timing(const struct via_display_timing *timing)
{
- struct display_timing raw;
+ struct via_display_timing raw;
raw.hor_total = timing-hor_total / 8 - 5;
raw.hor_addr = timing-hor_addr / 8 - 1;
@@ -88,9 +88,9 @@ void via_set_primary_timing(const struct display_timing
*timing)
via_write_reg_mask(VIACR, 0x17, 0x80, 0x80);
}
-void via_set_secondary_timing(const struct display_timing *timing)
+void via_set_secondary_timing(const struct via_display_timing *timing)
{
- struct display_timing raw;
+ struct via_display_timing raw;
raw.hor_total = timing-hor_total - 1;
raw.hor_addr = timing-hor_addr - 1;
diff --git a/drivers/video/via/via_modesetting.h
b/drivers/video/via/via_modesetting.h
index 06e09fe..f6a6503 100644
--- a/drivers/video/via/via_modesetting.h
+++ b/drivers/video/via/via_modesetting.h
@@ -33,7 +33,7 @@
#define VIA_PITCH_MAX 0x3FF8
-struct display_timing {
+struct via_display_timing {
u16 hor_total;
u16 hor_addr;
u16 hor_blank_start;
@@ -49,8 +49,8 @@ struct display_timing {
};
-void via_set_primary_timing(const struct display_timing *timing);
-void via_set_secondary_timing(const struct display_timing *timing);
+void via_set_primary_timing(const struct via_display_timing *timing);
+void via_set_secondary_timing(const struct via_display_timing
Re: [PATCH] [media] Add common binding documentation for video interfaces
On 12/15/2012 02:13 PM, Sylwester Nawrocki wrote: From: Guennadi Liakhovetski g.liakhovet...@gmx.de This patch adds a document describing common OF bindings for video capture, output and video processing devices. It is currently mainly focused on video capture devices, with data interfaces defined in standards like ITU-R BT.656 or MIPI CSI-2. It also documents a method of describing data links between devices. (quickly/briefly) Reviewed-by: Stephen Warren swar...@nvidia.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
[PATCH RESEND 4/6] clk: s5p-tv: Fix incorrect usage of IS_ERR_OR_NULL
Resend to include mailing lists.
Replace IS_ERR_OR_NULL with IS_ERR on clk_get results.
Signed-off-by: Tony Prisk li...@prisktech.co.nz
CC: Kyungmin Park kyungmin.p...@samsung.com
CC: Tomasz Stanislawski t.stanisl...@samsung.com
CC: linux-media@vger.kernel.org
---
drivers/media/platform/s5p-tv/hdmi_drv.c | 10 +-
drivers/media/platform/s5p-tv/mixer_drv.c | 10 +-
drivers/media/platform/s5p-tv/sdo_drv.c | 10 +-
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/media/platform/s5p-tv/hdmi_drv.c
b/drivers/media/platform/s5p-tv/hdmi_drv.c
index 8a9cf43..1c48ca5 100644
--- a/drivers/media/platform/s5p-tv/hdmi_drv.c
+++ b/drivers/media/platform/s5p-tv/hdmi_drv.c
@@ -781,27 +781,27 @@ static int hdmi_resources_init(struct hdmi_device *hdev)
/* get clocks, power */
res-hdmi = clk_get(dev, hdmi);
- if (IS_ERR_OR_NULL(res-hdmi)) {
+ if (IS_ERR(res-hdmi)) {
dev_err(dev, failed to get clock 'hdmi'\n);
goto fail;
}
res-sclk_hdmi = clk_get(dev, sclk_hdmi);
- if (IS_ERR_OR_NULL(res-sclk_hdmi)) {
+ if (IS_ERR(res-sclk_hdmi)) {
dev_err(dev, failed to get clock 'sclk_hdmi'\n);
goto fail;
}
res-sclk_pixel = clk_get(dev, sclk_pixel);
- if (IS_ERR_OR_NULL(res-sclk_pixel)) {
+ if (IS_ERR(res-sclk_pixel)) {
dev_err(dev, failed to get clock 'sclk_pixel'\n);
goto fail;
}
res-sclk_hdmiphy = clk_get(dev, sclk_hdmiphy);
- if (IS_ERR_OR_NULL(res-sclk_hdmiphy)) {
+ if (IS_ERR(res-sclk_hdmiphy)) {
dev_err(dev, failed to get clock 'sclk_hdmiphy'\n);
goto fail;
}
res-hdmiphy = clk_get(dev, hdmiphy);
- if (IS_ERR_OR_NULL(res-hdmiphy)) {
+ if (IS_ERR(res-hdmiphy)) {
dev_err(dev, failed to get clock 'hdmiphy'\n);
goto fail;
}
diff --git a/drivers/media/platform/s5p-tv/mixer_drv.c
b/drivers/media/platform/s5p-tv/mixer_drv.c
index ca0f297..c1b2e0e 100644
--- a/drivers/media/platform/s5p-tv/mixer_drv.c
+++ b/drivers/media/platform/s5p-tv/mixer_drv.c
@@ -240,27 +240,27 @@ static int mxr_acquire_clocks(struct mxr_device *mdev)
struct device *dev = mdev-dev;
res-mixer = clk_get(dev, mixer);
- if (IS_ERR_OR_NULL(res-mixer)) {
+ if (IS_ERR(res-mixer)) {
mxr_err(mdev, failed to get clock 'mixer'\n);
goto fail;
}
res-vp = clk_get(dev, vp);
- if (IS_ERR_OR_NULL(res-vp)) {
+ if (IS_ERR(res-vp)) {
mxr_err(mdev, failed to get clock 'vp'\n);
goto fail;
}
res-sclk_mixer = clk_get(dev, sclk_mixer);
- if (IS_ERR_OR_NULL(res-sclk_mixer)) {
+ if (IS_ERR(res-sclk_mixer)) {
mxr_err(mdev, failed to get clock 'sclk_mixer'\n);
goto fail;
}
res-sclk_hdmi = clk_get(dev, sclk_hdmi);
- if (IS_ERR_OR_NULL(res-sclk_hdmi)) {
+ if (IS_ERR(res-sclk_hdmi)) {
mxr_err(mdev, failed to get clock 'sclk_hdmi'\n);
goto fail;
}
res-sclk_dac = clk_get(dev, sclk_dac);
- if (IS_ERR_OR_NULL(res-sclk_dac)) {
+ if (IS_ERR(res-sclk_dac)) {
mxr_err(mdev, failed to get clock 'sclk_dac'\n);
goto fail;
}
diff --git a/drivers/media/platform/s5p-tv/sdo_drv.c
b/drivers/media/platform/s5p-tv/sdo_drv.c
index ad68bbe..269d246 100644
--- a/drivers/media/platform/s5p-tv/sdo_drv.c
+++ b/drivers/media/platform/s5p-tv/sdo_drv.c
@@ -341,25 +341,25 @@ static int __devinit sdo_probe(struct platform_device
*pdev)
/* acquire clocks */
sdev-sclk_dac = clk_get(dev, sclk_dac);
- if (IS_ERR_OR_NULL(sdev-sclk_dac)) {
+ if (IS_ERR(sdev-sclk_dac)) {
dev_err(dev, failed to get clock 'sclk_dac'\n);
ret = -ENXIO;
goto fail;
}
sdev-dac = clk_get(dev, dac);
- if (IS_ERR_OR_NULL(sdev-dac)) {
+ if (IS_ERR(sdev-dac)) {
dev_err(dev, failed to get clock 'dac'\n);
ret = -ENXIO;
goto fail_sclk_dac;
}
sdev-dacphy = clk_get(dev, dacphy);
- if (IS_ERR_OR_NULL(sdev-dacphy)) {
+ if (IS_ERR(sdev-dacphy)) {
dev_err(dev, failed to get clock 'dacphy'\n);
ret = -ENXIO;
goto fail_dac;
}
sclk_vpll = clk_get(dev, sclk_vpll);
- if (IS_ERR_OR_NULL(sclk_vpll)) {
+ if (IS_ERR(sclk_vpll)) {
dev_err(dev, failed to get clock 'sclk_vpll'\n);
ret = -ENXIO;
goto fail_dacphy;
@@ -367,7 +367,7 @@ static int __devinit sdo_probe(struct platform_device *pdev)
clk_set_parent(sdev-sclk_dac, sclk_vpll);
clk_put(sclk_vpll);
sdev-fout_vpll = clk_get(dev, fout_vpll);
[PATCH RESEND 5/6] clk: s5p-fimc: Fix incorrect usage of IS_ERR_OR_NULL
Resend to include mailing lists.
Replace IS_ERR_OR_NULL with IS_ERR on clk_get results.
Signed-off-by: Tony Prisk li...@prisktech.co.nz
CC: Kyungmin Park kyungmin.p...@samsung.com
CC: Tomasz Stanislawski t.stanisl...@samsung.com
CC: linux-media@vger.kernel.org
---
drivers/media/platform/s5p-fimc/fimc-mdevice.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-fimc/fimc-mdevice.c
b/drivers/media/platform/s5p-fimc/fimc-mdevice.c
index 0531ab7..3ac4da2 100644
--- a/drivers/media/platform/s5p-fimc/fimc-mdevice.c
+++ b/drivers/media/platform/s5p-fimc/fimc-mdevice.c
@@ -730,7 +730,7 @@ static int fimc_md_get_clocks(struct fimc_md *fmd)
for (i = 0; i FIMC_MAX_CAMCLKS; i++) {
snprintf(clk_name, sizeof(clk_name), sclk_cam%u, i);
clock = clk_get(NULL, clk_name);
- if (IS_ERR_OR_NULL(clock)) {
+ if (IS_ERR(clock)) {
v4l2_err(fmd-v4l2_dev, Failed to get clock: %s,
clk_name);
return -ENXIO;
--
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 RESEND 6/6] clk: s5p-g2d: Fix incorrect usage of IS_ERR_OR_NULL
Resend to include mailing lists.
Replace IS_ERR_OR_NULL with IS_ERR on clk_get results.
Signed-off-by: Tony Prisk li...@prisktech.co.nz
CC: Kyungmin Park kyungmin.p...@samsung.com
CC: Tomasz Stanislawski t.stanisl...@samsung.com
CC: linux-media@vger.kernel.org
---
drivers/media/platform/s5p-g2d/g2d.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/s5p-g2d/g2d.c
b/drivers/media/platform/s5p-g2d/g2d.c
index 1bfbc32..dcd5335 100644
--- a/drivers/media/platform/s5p-g2d/g2d.c
+++ b/drivers/media/platform/s5p-g2d/g2d.c
@@ -715,7 +715,7 @@ static int g2d_probe(struct platform_device *pdev)
}
dev-clk = clk_get(pdev-dev, sclk_fimg2d);
- if (IS_ERR_OR_NULL(dev-clk)) {
+ if (IS_ERR(dev-clk)) {
dev_err(pdev-dev, failed to get g2d clock\n);
return -ENXIO;
}
@@ -727,7 +727,7 @@ static int g2d_probe(struct platform_device *pdev)
}
dev-gate = clk_get(pdev-dev, fimg2d);
- if (IS_ERR_OR_NULL(dev-gate)) {
+ if (IS_ERR(dev-gate)) {
dev_err(pdev-dev, failed to get g2d clock gate\n);
ret = -ENXIO;
goto unprep_clk;
--
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
Re: [PATCH V3 10/15] [media] marvell-ccic: split mcam-core into 2 parts for soc_camera support
On Mon, 17 Dec 2012 19:04:26 -0800 Albert Wang twan...@marvell.com wrote: [Albert Wang] So if we add B_DMA_SG and B_VMALLOC support and OLPC XO 1.0 support in soc_camera mode. Then we can just remove the original mode and only support soc_camera mode in marvell-ccic? That is the idea, yes. Unless there is some real value to supporting both modes (that I've not seen), I think it's far better to support just one of them. Trying to support duplicated modes just leads to pain in the long run, in my experience. I can offer to *try* to find time to help with XO 1.0 testing when the time comes. Thanks, jon -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] Add header files and Kbuild plumbing for SI476x MFD core
Em Mon, 8 Oct 2012 11:38:01 -0700
Andrey Smirnov andrey.smir...@convergeddevices.net escreveu:
On 10/08/2012 01:43 AM, Hans Verkuil wrote:
On Sat October 6 2012 03:54:57 Andrey Smirnov wrote:
This patch adds all necessary header files and Kbuild plumbing for the
core driver for Silicon Laboratories Si476x series of AM/FM tuner
chips.
The driver as a whole is implemented as an MFD device and this patch
adds a core portion of it that provides all the necessary
functionality to the two other drivers that represent radio and audio
codec subsystems of the chip.
Signed-off-by: Andrey Smirnov andrey.smir...@convergeddevices.net
---
drivers/mfd/Kconfig | 14 ++
drivers/mfd/Makefile|3 +
include/linux/mfd/si476x-core.h | 529
+++
include/media/si476x.h | 449 +
4 files changed, 995 insertions(+)
create mode 100644 include/linux/mfd/si476x-core.h
create mode 100644 include/media/si476x.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b1a1462..3fab06d 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -895,6 +895,20 @@ config MFD_WL1273_CORE
driver connects the radio-wl1273 V4L2 module and the wl1273
audio codec.
+config MFD_SI476X_CORE
+ tristate Support for Silicon Laboratories 4761/64/68 AM/FM radio.
+ depends on I2C
+ select MFD_CORE
+ default n
+ help
+This is the core driver for the SI476x series of AM/FM radio. This MFD
+driver connects the radio-si476x V4L2 module and the si476x
+audio codec.
+
+To compile this driver as a module, choose M here: the
+module will be called si476x-core.
+
+
config MFD_OMAP_USB_HOST
bool Support OMAP USBHS core driver
depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 79dd22d..942257b 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -132,3 +132,6 @@ obj-$(CONFIG_MFD_RC5T583) += rc5t583.o
rc5t583-irq.o
obj-$(CONFIG_MFD_SEC_CORE)+= sec-core.o sec-irq.o
obj-$(CONFIG_MFD_ANATOP) += anatop-mfd.o
obj-$(CONFIG_MFD_LM3533) += lm3533-core.o lm3533-ctrlbank.o
+
+si476x-core-objs := si476x-cmd.o si476x-prop.o si476x-i2c.o
+obj-$(CONFIG_MFD_SI476X_CORE) += si476x-core.o
diff --git a/include/linux/mfd/si476x-core.h
b/include/linux/mfd/si476x-core.h
new file mode 100644
index 000..eb6f52a
--- /dev/null
+++ b/include/linux/mfd/si476x-core.h
@@ -0,0 +1,529 @@
+/*
+ * include/media/si476x-core.h -- Common definitions for si476x core
+ * device
+ *
+ * Copyright (C) 2012 Innovative Converged Devices(ICD)
+ *
+ * Author: Andrey Smirnov andrey.smir...@convergeddevices.net
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#ifndef SI476X_CORE_H
+#define SI476X_CORE_H
+
+#include linux/kfifo.h
+#include linux/atomic.h
+#include linux/i2c.h
+#include linux/mutex.h
+#include linux/mfd/core.h
+#include linux/videodev2.h
+
+#include media/si476x.h
+
+#ifdef DEBUG
+#define DBG_BUFFER(device, header, buffer, bcount)
\
+ do {\
+ dev_info((device), header); \
+ print_hex_dump_bytes(,\
+ DUMP_PREFIX_OFFSET,\
+ buffer, bcount); \
+ } while (0)
+#else
+#define DBG_BUFFER(device, header, buffer, bcount)
\
+ do {} while (0)
+#endif
+
+enum si476x_freq_suppoted_chips {
typo: suppoted - supported
+ SI476X_CHIP_SI4761 = 1,
+ SI476X_CHIP_SI4762,
+ SI476X_CHIP_SI4763,
+ SI476X_CHIP_SI4764,
+ SI476X_CHIP_SI4768,
+ SI476X_CHIP_SI4769,
+};
+
+enum si476x_mfd_cells {
+ SI476X_RADIO_CELL = 0,
+ SI476X_CODEC_CELL,
+ SI476X_MFD_CELLS,
+};
+
+
+/**
+ * enum si476x_power_state - possible power state of the si476x
+ * device.
+ *
+ * @SI476X_POWER_DOWN: In this state all regulators are turned off
+ * and the reset line is pulled low. The device is completely
+ * inactive.
+ * @SI476X_POWER_UP_FULL: In this state all the power regualtors are
+ * turned on, reset line pulled high, IRQ line is enabled(polling is
+ * active for polling use scenario) and device is turned
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Tue Dec 18 19:00:27 CET 2012 git hash:49cc629df16f2a15917800a8579bd9c25c41b634 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-i686: WARNINGS linux-3.7-i686: ERRORS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-x86_64: WARNINGS linux-3.7-x86_64: ERRORS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification 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: [PATCH V3 10/15] [media] marvell-ccic: split mcam-core into 2 parts for soc_camera support
Hi, Jonathan -Original Message- From: Jonathan Corbet [mailto:cor...@lwn.net] Sent: Wednesday, 19 December, 2012 03:15 To: Albert Wang Cc: g.liakhovet...@gmx.de; linux-media@vger.kernel.org; Libin Yang Subject: Re: [PATCH V3 10/15] [media] marvell-ccic: split mcam-core into 2 parts for soc_camera support On Mon, 17 Dec 2012 19:04:26 -0800 Albert Wang twan...@marvell.com wrote: [Albert Wang] So if we add B_DMA_SG and B_VMALLOC support and OLPC XO 1.0 support in soc_camera mode. Then we can just remove the original mode and only support soc_camera mode in marvell-ccic? That is the idea, yes. Unless there is some real value to supporting both modes (that I've not seen), I think it's far better to support just one of them. Trying to support duplicated modes just leads to pain in the long run, in my experience. [Albert Wang] OK, we will update and submit the remained patches except for the 3 patches related with soc_camera support as the first part. Then we will submit the soc_camera support patches after we rework the patches and add B_DMA_SG and B_VMALLOC support and OLPC XO 1.0 support. I can offer to *try* to find time to help with XO 1.0 testing when the time comes. [Albert Wang] Thank you very much! We were worried about how to get the OLPC XO 1.0 HW. That would be a great help! :) Thanks, jon Thanks Albert Wang 86-21-61092656 -- 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] v3 Add support to Avermedia Twinstar double tuner in af9035
Hi Antti and Jose
I'd like to advise you that I tested this path since it solve issue on
other af9035 devices like avermedia a835 and avermedia a867.
I mean:
mxl5007t_soft_reset: 522: failed!
mxl5007t_tuner_init: error -140 on line 535
mxl5007t_set_params: error -140 on line 666
mxl5007t_soft_reset: 522: failed!
mxl5007t_tuner_init: error -140 on line 535
mxl5007t_set_params: error -140 on line 666
mxl5007t_soft_reset: 522: failed!
mxl5007t_tuner_init: error -140 on line 535
mxl5007t_set_params: error -140 on line 666
mxl5007t_soft_reset: 522: failed!
mxl5007t_tuner_init: error -140 on line 535
mxl5007t_set_params: error -140 on line 666
It seems that no_reset and no_probe configuration parameter added by
jose is needed for mxl5007t initialization.
I suppose that the initialization is already done by the af9035 firmware.
Regards
Eddi De Pieri
On Sun, Sep 23, 2012 at 6:29 PM, Antti Palosaari cr...@iki.fi wrote:
Hello Jose,
Could you try to split and resent?
I will get af9035 + fc0012 dual tuner next week and add support for it. I
wish to use your patch for dual mode, but I as there is that unresolved
MXL5007t dependency I cannot user it currently.
regards
Antti
On 09/15/2012 08:45 PM, Antti Palosaari wrote:
Hello
Could you split that patch to 2?
1) mxl5007t changes
2) af9035/af9033 dual mode
3) af9035/af9033 changes needed for mxl5007t
I cannot say much about tuner changes, but I still wonder are those
really needed as this device is already supported. Is it broken currently?
What happens when no_probe = 0 ?
What happens when no_reset = 0 ?
Soft reset means usually resetting chip state machine. It is something
like start operating command. First program registers then issue soft
reset in order to restart state machine.
regards
Antti
On 08/30/2012 02:02 AM, Jose Alberto Reguero wrote:
This patch add support to the Avermedia Twinstar double tuner in the
af9035
driver. Version 3 of the patch.
Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
Jose Alberto
diff -upr linux/drivers/media/dvb-frontends/af9033.c
linux.new/drivers/media/dvb-frontends/af9033.c
--- linux/drivers/media/dvb-frontends/af9033.c2012-08-14
05:45:22.0 +0200
+++ linux.new/drivers/media/dvb-frontends/af9033.c2012-08-29
16:00:52.020523899 +0200
@@ -326,6 +326,18 @@ static int af9033_init(struct dvb_fronte
goto err;
}
+if (state-cfg.ts_mode == AF9033_TS_MODE_SERIAL) {
+ret = af9033_wr_reg_mask(state, 0x00d91c, 0x01, 0x01);
+if (ret 0)
+goto err;
+ret = af9033_wr_reg_mask(state, 0x00d917, 0x00, 0x01);
+if (ret 0)
+goto err;
+ret = af9033_wr_reg_mask(state, 0x00d916, 0x00, 0x01);
+if (ret 0)
+goto err;
+}
+
state-bandwidth_hz = 0; /* force to program all parameters */
return 0;
diff -upr linux/drivers/media/tuners/mxl5007t.c
linux.new/drivers/media/tuners/mxl5007t.c
--- linux/drivers/media/tuners/mxl5007t.c2012-08-14
05:45:22.0 +0200
+++ linux.new/drivers/media/tuners/mxl5007t.c2012-08-29
13:07:57.299884405 +0200
@@ -374,7 +374,6 @@ static struct reg_pair_t *mxl5007t_calc_
mxl5007t_set_if_freq_bits(state, cfg-if_freq_hz, cfg-invert_if);
mxl5007t_set_xtal_freq_bits(state, cfg-xtal_freq_hz);
-set_reg_bits(state-tab_init, 0x04, 0x01, cfg-loop_thru_enable);
set_reg_bits(state-tab_init, 0x03, 0x08, cfg-clk_out_enable
3);
set_reg_bits(state-tab_init, 0x03, 0x07, cfg-clk_out_amp);
@@ -531,9 +530,11 @@ static int mxl5007t_tuner_init(struct mx
struct reg_pair_t *init_regs;
int ret;
-ret = mxl5007t_soft_reset(state);
-if (mxl_fail(ret))
-goto fail;
+if (!state-config-no_reset) {
+ret = mxl5007t_soft_reset(state);
+if (mxl_fail(ret))
+goto fail;
+}
/* calculate initialization reg array */
init_regs = mxl5007t_calc_init_regs(state, mode);
@@ -887,7 +888,11 @@ struct dvb_frontend *mxl5007t_attach(str
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 1);
-ret = mxl5007t_get_chip_id(state);
+if (!state-config-no_probe)
+ret = mxl5007t_get_chip_id(state);
+
+ret = mxl5007t_write_reg(state, 0x04,
+state-config-loop_thru_enable);
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 0);
diff -upr linux/drivers/media/tuners/mxl5007t.h
linux.new/drivers/media/tuners/mxl5007t.h
--- linux/drivers/media/tuners/mxl5007t.h2012-08-14
05:45:22.0 +0200
+++ linux.new/drivers/media/tuners/mxl5007t.h2012-08-25
19:38:19.990920623 +0200
@@ -73,8 +73,10 @@ struct mxl5007t_config {
enum mxl5007t_xtal_freq xtal_freq_hz;
enum mxl5007t_if_freq if_freq_hz;
unsigned int invert_if:1;
-unsigned int loop_thru_enable:1;
+unsigned int loop_thru_enable:2;
AverMedia Satelllite Hybrid+FM A706
Hello,
I'm trying to add support for AverMedia Satelllite Hybrid+FM A706 card to
saa7134 driver but it does not seem to work :( I did something like this
(also tried .tuner_addr = ADDR_UNSET). It's probably mostly wrong as it's
copied from other cards.
--- a/drivers/media/pci/saa7134/saa7134-cards.c
+++ b/drivers/media/pci/saa7134/saa7134-cards.c
@@ -5773,6 +5773,36 @@ struct saa7134_board saa7134_boards[] = {
.gpio = 0x000,
},
},
+ [SAA7134_BOARD_AVERMEDIA_A706] = {
+ .name = AverMedia AverTV Satellite Hybrid+FM A706,
+ .audio_clock= 0x00187de7,
+ .tuner_type = TUNER_PHILIPS_TDA8290,
+ .radio_type = UNSET,
+ .tuner_addr = 0x63,
+ .radio_addr = ADDR_UNSET,
+ .tuner_config = 2,
+ .gpiomask = 1 21,
+ .mpeg = SAA7134_MPEG_DVB,
+ .inputs = {{
+ .name = name_tv,
+ .vmux = 1,
+ .amux = TV,
+ .tv = 1,
+ }, {
+ .name = name_comp,
+ .vmux = 0,
+ .amux = LINE2,
+ }, {
+ .name = name_svideo,
+ .vmux = 8,
+ .amux = LINE2,
+ } },
+ .radio = {
+ .name = name_radio,
+ .amux = TV,
+ .gpio = 0x020,
+ },
+ },
};
@@ -7020,6 +7050,12 @@ struct pci_device_id saa7134_pci_tbl[] = {
.subdevice= 0x0911,
.driver_data = SAA7134_BOARD_SENSORAY811_911,
}, {
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+ .subvendor= 0x1461, /* Avermedia Technologies Inc */
+ .subdevice= 0x2055, /* AverTV Satellite Hybrid+FM A706 */
+ .driver_data = SAA7134_BOARD_AVERMEDIA_A706,
+ }, {
/* --- boards without eeprom + subsystem ID --- */
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7134,
@@ -7266,6 +7302,7 @@ static int saa7134_tda8290_callback(struct saa7134_dev
*dev,
case SAA7134_BOARD_KWORLD_PCI_SBTVD_FULLSEG:
case SAA7134_BOARD_KWORLD_PC150U:
case SAA7134_BOARD_MAGICPRO_PROHDTV_PRO2:
+ case SAA7134_BOARD_AVERMEDIA_A706:
/* tda8290 + tda18271 */
ret = saa7134_tda8290_18271_callback(dev, command, arg);
break;
diff --git a/drivers/media/pci/saa7134/saa7134-dvb.c
b/drivers/media/pci/saa7134/saa7134-dvb.c
index b209de4..c6f886d 100644
--- a/drivers/media/pci/saa7134/saa7134-dvb.c
+++ b/drivers/media/pci/saa7134/saa7134-dvb.c
@@ -1070,6 +1070,11 @@ static struct mt312_config zl10313_compro_s350_config = {
.demod_address = 0x0e,
};
+static struct mt312_config zl10313_avermedia_a706_config = {
+ .demod_address = 0x0e,
+};
+
+
static struct lgdt3305_config hcw_lgdt3305_config = {
.i2c_addr = 0x0e,
.mpeg_mode = LGDT3305_MPEG_SERIAL,
@@ -1817,6 +1822,19 @@ static int dvb_init(struct saa7134_dev *dev)
prohdtv_pro2_tda18271_config);
}
break;
+ case SAA7134_BOARD_AVERMEDIA_A706:
+ fe0-dvb.frontend = dvb_attach(mt312_attach,
+ zl10313_avermedia_a706_config, dev-i2c_adap);
+ if (fe0-dvb.frontend) {
+ dvb_attach(tda829x_attach, fe0-dvb.frontend,
+ dev-i2c_adap, 0x4b,
+ tda829x_no_probe);
+ if (dvb_attach(zl10039_attach, fe0-dvb.frontend,
+ 0x60, dev-i2c_adap) == NULL)
+ wprintk(%s: No zl10039 found!\n,
+ __func__);
+ }
+ break;
default:
wprintk(Huh? unknown DVB card?\n);
break;
diff --git a/drivers/media/pci/saa7134/saa7134.h
b/drivers/media/pci/saa7134/saa7134.h
index c24b651..6cef84d 100644
--- a/drivers/media/pci/saa7134/saa7134.h
+++ b/drivers/media/pci/saa7134/saa7134.h
@@ -332,6 +332,7 @@ struct saa7134_card_ir {
#define SAA7134_BOARD_SENSORAY811_911 188
#define SAA7134_BOARD_KWORLD_PC150U 189
#define SAA7134_BOARD_ASUSTeK_PS3_100 190
+#define SAA7134_BOARD_AVERMEDIA_A706 191
#define SAA7134_MAXBOARDS 32
#define SAA7134_INPUT_MAX 8
The result is:
[3.843111] saa7130/34: v4l2 driver version 0, 2, 17 loaded
[3.843677] saa7133[0]: found at :02:01.0, rev: 209, irq: 9, latency:
32, mmio: 0xf400
[
Two new DVB-C scan lists for Switzerland
Dear linux-dvb Members I would like to kindly ask you to add the two attached new scan list to your repository. http://linuxtv.org/hg/dvb-apps/file/5e68946b0e0d/util/scan/dvb-c The files will add new entries for two cable networks in Switzerland: - GGA Pratteln - interGGA They are both fully non-encrypted free-to-air networks but also contain some pay-tv transponders. Could you also remove the list below because it's useless: http://linuxtv.org/hg/dvb-apps/file/5e68946b0e0d/util/scan/dvb-c/ch-unknown Thank you very much Patrick Pfyffer ch-GGA-Pratteln Description: Binary data ch-interGGA Description: Binary data
Re: [RFC] Initial scan files troubles and brainstorming
Unfortunatly, I have had zero replies. So why bring it up again? On 2012/11/30 Jakub Kasprzycki provided us with updated polish DVB-T frequencies for his region. This has yet to be merged, almost 3 weeks later. While I know people are busy and merging frequency updates doesn't seem critical, for people who somewhat depend on them, the sooner, the better. Since I didn't expect anybody to actually do the work, just was asking for your thoughts, I've done the work. I've setup a repository and purged all unrelated files. All history should have been preserved. I'll quickly repeat why I think this approach would be quite reasonable. * dvb-apps binary changes don't result in unnecessary releases * frequency updates don't result in unnecessary dvb-app releases * Less strict requirements for commits (code reviews etc) * Possibly easier entry for new submitters * much easier to package (tag it once per month if an update was) * Separate maintainer possible * just seems more logical to have it separated ;) This obviously should find a nice home on linuxtv where it belongs! Here is my personal repository with the work I mentioned done. git://git.schinagl.nl/dvb_frequency_scanfiles.git If an issue is that none of the original maintainers are not looking forward to do the job, I am willing to take maintenance on me for now. Anyway, hopefully this time we can get some form of discussion going :) Oliver On 10/18/12 13:26, Oliver Schinagl wrote: Hello list, I was talking to someone over at tvheadend and was told that the linux-media initial scan files tend to be often very out dated. Also when newer files are submitted, requests to merge them are simply being ignored. Obviously I have zero proof to back those claims. True or not, they have decided to keep a local copy and try to keep that up to date as possible. One of the reasons to take this approach, is because major distro's also do it in this way. 1 This obviously results in a duplication of work and since it's factual data really wasted resources, no central repository of said factual data, but spread and makes it confusing on top of that for users of this data. Now I don't know the proper solution or if it really is a problem. Well it appears to be so I guess ;) Something that comes to mind, is to split off the initial scan files from the dvb-apps package and have a seperate git tree for it, like for example the firmware git tree. I feel this has several advantages over the current setup. One could have /usr/share/dvb/ as a git tree and simply pull to have an up to date tree. Initialscan file 'users (as in developers)' can more easily clone it and do pull requests. Possibly more lenient commit access, e.g. allow a 'trusted' developer of a dvb project to have commit rights, without much risk of breaking any source code. Other things I haven't thought of yet. Since there really isn't a 'stable' release, current trunk can be considered the go to release, unverified changes could live in a branch? Again, if everybody can firmly claim there is no problem and that the initial scanfiles are updated nearly when an actually change takes place, then we should try convince downstream maintainers of course. Anyway, this is just something that was on my mind and wanted some feedback on. Oliver -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/6] Add header files and Kbuild plumbing for SI476x MFD core
On 12-12-18 11:37 AM, Mauro Carvalho Chehab wrote:
Em Mon, 8 Oct 2012 11:38:01 -0700
Andrey Smirnov andrey.smir...@convergeddevices.net escreveu:
On 10/08/2012 01:43 AM, Hans Verkuil wrote:
On Sat October 6 2012 03:54:57 Andrey Smirnov wrote:
This patch adds all necessary header files and Kbuild plumbing for the
core driver for Silicon Laboratories Si476x series of AM/FM tuner
chips.
The driver as a whole is implemented as an MFD device and this patch
adds a core portion of it that provides all the necessary
functionality to the two other drivers that represent radio and audio
codec subsystems of the chip.
Signed-off-by: Andrey Smirnov andrey.smir...@convergeddevices.net
---
drivers/mfd/Kconfig | 14 ++
drivers/mfd/Makefile|3 +
include/linux/mfd/si476x-core.h | 529 +++
include/media/si476x.h | 449 +
4 files changed, 995 insertions(+)
create mode 100644 include/linux/mfd/si476x-core.h
create mode 100644 include/media/si476x.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b1a1462..3fab06d 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -895,6 +895,20 @@ config MFD_WL1273_CORE
driver connects the radio-wl1273 V4L2 module and the wl1273
audio codec.
+config MFD_SI476X_CORE
+ tristate Support for Silicon Laboratories 4761/64/68 AM/FM radio.
+ depends on I2C
+ select MFD_CORE
+ default n
+ help
+ This is the core driver for the SI476x series of AM/FM radio. This MFD
+ driver connects the radio-si476x V4L2 module and the si476x
+ audio codec.
+
+ To compile this driver as a module, choose M here: the
+ module will be called si476x-core.
+
+
config MFD_OMAP_USB_HOST
bool Support OMAP USBHS core driver
depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 79dd22d..942257b 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -132,3 +132,6 @@ obj-$(CONFIG_MFD_RC5T583) += rc5t583.o rc5t583-irq.o
obj-$(CONFIG_MFD_SEC_CORE)+= sec-core.o sec-irq.o
obj-$(CONFIG_MFD_ANATOP) += anatop-mfd.o
obj-$(CONFIG_MFD_LM3533) += lm3533-core.o lm3533-ctrlbank.o
+
+si476x-core-objs := si476x-cmd.o si476x-prop.o si476x-i2c.o
+obj-$(CONFIG_MFD_SI476X_CORE) += si476x-core.o
diff --git a/include/linux/mfd/si476x-core.h b/include/linux/mfd/si476x-core.h
new file mode 100644
index 000..eb6f52a
--- /dev/null
+++ b/include/linux/mfd/si476x-core.h
@@ -0,0 +1,529 @@
+/*
+ * include/media/si476x-core.h -- Common definitions for si476x core
+ * device
+ *
+ * Copyright (C) 2012 Innovative Converged Devices(ICD)
+ *
+ * Author: Andrey Smirnov andrey.smir...@convergeddevices.net
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#ifndef SI476X_CORE_H
+#define SI476X_CORE_H
+
+#include linux/kfifo.h
+#include linux/atomic.h
+#include linux/i2c.h
+#include linux/mutex.h
+#include linux/mfd/core.h
+#include linux/videodev2.h
+
+#include media/si476x.h
+
+#ifdef DEBUG
+#define DBG_BUFFER(device, header, buffer, bcount) \
+ do {\
+ dev_info((device), header); \
+ print_hex_dump_bytes(, \
+DUMP_PREFIX_OFFSET,\
+buffer, bcount); \
+ } while (0)
+#else
+#define DBG_BUFFER(device, header, buffer, bcount) \
+ do {} while (0)
+#endif
+
+enum si476x_freq_suppoted_chips {
typo: suppoted - supported
+ SI476X_CHIP_SI4761 = 1,
+ SI476X_CHIP_SI4762,
+ SI476X_CHIP_SI4763,
+ SI476X_CHIP_SI4764,
+ SI476X_CHIP_SI4768,
+ SI476X_CHIP_SI4769,
+};
+
+enum si476x_mfd_cells {
+ SI476X_RADIO_CELL = 0,
+ SI476X_CODEC_CELL,
+ SI476X_MFD_CELLS,
+};
+
+
+/**
+ * enum si476x_power_state - possible power state of the si476x
+ * device.
+ *
+ * @SI476X_POWER_DOWN: In this state all regulators are turned off
+ * and the reset line is pulled low. The device is completely
+ * inactive.
+ * @SI476X_POWER_UP_FULL: In this state all the power regualtors are
+ * turned on, reset line pulled high, IRQ line is enabled(polling is
+ * active for polling use scenario) and device is turned on with
+ * POWER_UP command. The device is ready to be used.
+ *
