Re: iram pool not available for MX27
On Monday, September 30, 2013 05:14 PM, Chris Ruehl wrote: On Monday, September 30, 2013 05:08 PM, Chris Ruehl wrote: Hi Philipp, On Monday, September 30, 2013 04:30 PM, Philipp Zabel wrote: Hi Chris, Am Montag, den 30.09.2013, 13:40 +0800 schrieb Chris Ruehl: Hi Phillipp, hope things doing OK. I recently update to the 3.12-rc kernel and hit this problem below. [ 3.377790] coda coda-imx27.0: iram pool not available [ 3.383363] coda: probe of coda-imx27.0 failed with error -12 I read your comments of the patch-set using platform data rather then hard coded addresses to get the ocram from a SoC. I checked the imx27.dtsi for the iram (coda: coda@..) definition and compare with the former hard coded address and size it matches. My .config also has the CONFIG_OF set. Any Idea what's go wrong? do you have the mmio-sram driver enabled (CONFIG_SRAM=y)? regards Philipp No, I didn't, and I found out that my device is not yet ported to use Device Tree Support for the moment I will quick add the CONFIG_SRAM and see what happen, but on the long term I move my code (clone of mach-mx27ads.c) to DTS which makes absolute sense when I see how nice that code works. Thanks for the reply! Chris CONFIG_SRAM not solve my problem, I must port the code to Device Tree Support and call the of_ functions to make the iram config available. thank you. Chris -- 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 Hi, almost done but the coda works now with my board :-) and more questions coming up but 1st: [4.626900] udevd[717]: starting version 175 [7.190348] coda 10023000.coda: Initialized CodaDx6. [7.195486] coda 10023000.coda: Firmware version: 2.2.5 [7.313178] coda 10023000.coda: codec registered as /dev/video0 [ 13.999803] EXT4-fs (mmcblk0p1): re-mounted. Opts: (null) :-) ))) Chris -- 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: imx27.dtsi usbotg/usbh2 oops in fsl_usb2_mph_dr_of_probe
On Monday, October 28, 2013 08:42 PM, Chris Ruehl wrote:
On Monday, October 28, 2013 08:25 PM, Fabio Estevam wrote:
On Mon, Oct 28, 2013 at 10:17 AM, Chris Ruehl
chris.ru...@gtsys.com.hk wrote:
Hi,
when tried to activate the USB-OTG or USBH2 with the FDT the system
oops
You should have posted this to the linux-usb list instead :-)
config: (imx27.dtsi)
usbotg: usb@10024000 {
compatible = fsl-usb2-dr;
You should use compatible =fsl,imx27-usb so that it uses the
chipidea usb driver.
I didn't get USB detected with
compatible =fsl,imx27-usb
nothing happen.
The ChipIdea was not selected in the .config and this is why nothing
come out.
(only if someone read the thread and wondering why)
--
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
--
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 3/7] video: exynos_mipi_dsim: Use the generic PHY driver
Hi Tomasz, On Tue, OCT 28, 2013 21:24, Tomasz Figa wrote: Hi Donghwa, On Monday 28 of October 2013 15:12:08 Donghwa Lee wrote: On Fri, OCT 25, 2013 06:57, Sylwester Nawrocki wrote: On 10/24/2013 05:57 PM, Kishon Vijay Abraham I wrote: On Thursday 24 October 2013 09:12 PM, Sachin Kamat wrote: On 24 October 2013 20:00, Olof Johanssono...@lixom.net wrote: On Wed, Oct 16, 2013 at 9:28 AM, Kishon Vijay Abraham Ikis...@ti.com wrote: diff --git a/drivers/video/exynos/exynos_mipi_dsi.c b/drivers/video/exynos/exynos_mipi_dsi.c index 32e5406..00b3a52 100644 --- a/drivers/video/exynos/exynos_mipi_dsi.c +++ b/drivers/video/exynos/exynos_mipi_dsi.c @@ -156,8 +157,7 @@ static int exynos_mipi_dsi_blank_mode(struct mipi_dsim_device *dsim, int power) exynos_mipi_regulator_enable(dsim); /* enable MIPI-DSI PHY. */ - if (dsim-pd-phy_enable) - dsim-pd-phy_enable(pdev, true); + phy_power_on(dsim-phy); clk_enable(dsim-clock); This introduces the below with exynos_defconfig: ../../drivers/video/exynos/exynos_mipi_dsi.c: In function 'exynos_mipi_dsi_blank_mode': ../../drivers/video/exynos/exynos_mipi_dsi.c:144:26: warning: unused variable 'pdev' [-Wunused-variable] struct platform_device *pdev = to_platform_device(dsim-dev); Sorry about missing that, I only noticed this warning recently and didn't get around to submit a patch. I have already submitted a patch to fix this [1] Thanks a lot guys for fixing this. [1] http://marc.info/?l=linux-fbdevm=138233359617936w=2 Sorry, missed that :-( This MIPI DSIM driver is affectively a dead code in the mainline now, once Exynos become a dt-only platform. I guess it can be deleted for 3.14, once S5P gets converted to the device tree. The new driver using CDF is basically a complete rewrite. Or device tree support should be added to that driver, but I believe it doesn't make sense without CDF. MIPI DSIM driver is not a dead code. There is a steady trickle of patches. It's kind of late, but, I will update it as DT based drivers as soon as possible. And Why do you think that DT support of existing MIPI DSIM is something less than great? First of all, the exynos_mipi_dsim driver has currently no users in mainline kernel, so it is essentially dead code. In addition, on a platform that is the primary candidate for using it, which is Exynos, there is no way to use it, due to no DT support. As I mentioned above, patches are submitted sometimes and I will update this driver as soon as possible to support DT. As for the driver itself, it is not really a great example of good code. It contains a hacks, like calling msleep() without any clear reason and also many coding style issues. I'd prefer to replace it with the new exynos-dsi driver rewritten completely in SRPOL, when CDF is finished. Yes, I know this drivers had been changed about only minor issues and it is not really good code style. And CDF is more good and light. But discussion for CDF is still remaining a kind of requests. If it is merged into linux kernel and many users use it, existing MIPI DSI drivers will be replaced with the new drivers naturally, isn't it? Until that, I and quite a few users will update and code re-factory for this drivers to be more better. BR, Donghwa Lee Best regards, Tomasz -- 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] videobuf2: Add missing lock held on vb2_fop_relase
Hello
Anybody has a comment here? If not I will post a patch with the
modifications propossed by Sylwester.
Thanks!
On Sat, Oct 19, 2013 at 10:08 PM, Ricardo Ribalda Delgado
ricardo.riba...@gmail.com wrote:
Hello Sylwester
On Sat, Oct 19, 2013 at 8:27 PM, Sylwester Nawrocki
sylvester.nawro...@gmail.com wrote:
On 10/19/2013 06:07 PM, Ricardo Ribalda wrote:
[...]
---
drivers/media/platform/exynos4-is/fimc-capture.c | 2 +-
drivers/media/platform/exynos4-is/fimc-lite.c| 2 +-
drivers/media/usb/em28xx/em28xx-video.c | 2 +-
drivers/media/v4l2-core/videobuf2-core.c | 18 +-
include/media/videobuf2-core.h | 2 ++
5 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/fimc-capture.c
b/drivers/media/platform/exynos4-is/fimc-capture.c
index fb27ff7..c38d247c 100644
--- a/drivers/media/platform/exynos4-is/fimc-capture.c
+++ b/drivers/media/platform/exynos4-is/fimc-capture.c
@@ -549,7 +549,7 @@ static int fimc_capture_release(struct file *file)
vc-streaming = false;
}
- ret = vb2_fop_release(file);
+ ret = __vb2_fop_release(file, true);
if (close) {
clear_bit(ST_CAPT_BUSY,fimc-state);
diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c
b/drivers/media/platform/exynos4-is/fimc-lite.c
index e5798f7..021d804 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite.c
+++ b/drivers/media/platform/exynos4-is/fimc-lite.c
@@ -546,7 +546,7 @@ static int fimc_lite_release(struct file *file)
mutex_unlock(entity-parent-graph_mutex);
}
- vb2_fop_release(file);
+ __vb2_fop_release(file, true);
pm_runtime_put(fimc-pdev-dev);
clear_bit(ST_FLITE_SUSPENDED,fimc-state);
diff --git a/drivers/media/usb/em28xx/em28xx-video.c
b/drivers/media/usb/em28xx/em28xx-video.c
index 9d10334..6a5c147 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -1664,7 +1664,7 @@ static int em28xx_v4l2_close(struct file *filp)
em28xx_videodbg(users=%d\n, dev-users);
mutex_lock(dev-lock);
- vb2_fop_release(filp);
+ __vb2_fop_release(filp, false);
I believe no modifications are needed for this driver.
if (dev-users == 1) {
/* the device is already disconnect,
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 594c75e..ce309a8 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2619,16 +2619,32 @@ int vb2_fop_mmap(struct file *file, struct
vm_area_struct *vma)
}
EXPORT_SYMBOL_GPL(vb2_fop_mmap);
-int vb2_fop_release(struct file *file)
+int __vb2_fop_release(struct file *file, bool lock_is_held)
{
struct video_device *vdev = video_devdata(file);
+ struct mutex *lock;
if (file-private_data == vdev-queue-owner) {
+ if (lock_is_held)
+ lock = NULL;
+ else
+ lock = vdev-queue-lock ?
+ vdev-queue-lock : vdev-lock;
+ if (lock)
+ mutex_lock(lock);
vb2_queue_release(vdev-queue);
vdev-queue-owner = NULL;
+ if (lock)
+ mutex_unlock(lock);
}
return v4l2_fh_release(file);
}
+EXPORT_SYMBOL_GPL(__vb2_fop_release);
+
+int vb2_fop_release(struct file *file)
+{
+ return __vb2_fop_release(file, false);
+}
EXPORT_SYMBOL_GPL(vb2_fop_release);
It might be better to make it something like:
The rationale behind my patch (and probably not properly commented) is
that the vb2_fop_release must be used ONLY as a file operantion
handler.
If the user makes its own function for relase the __vb2_fop_release
function must be used and the infrastructure must be notified about
the status of he lock (he is on his own).
I believe my approach is simpler because It has only two functions
(instead of 3) and the user understand the difference of the two
functions just by looking at the arguments. In the future we could
even check statically that vb2_fop_release is not called inside a
driver.
Anyway, this is just a detail :), the most important part is that the
oops is fixed, and that all the drivers that worked keep working.
Lets wait for more comments and then lets post a new patch (with two
functions and better documentation, or three functions).
Thank you very much for you comments!!!
static int _vb2_fop_release(struct file *file, bool locked)
{
struct video_device *vdev = video_devdata(file);
struct mutex *lock;
if (file-private_data == vdev-queue-owner) {
lock = vdev-queue-lock ?
vdev-queue-lock : vdev-lock;
Re: [GIT PULL FOR 3.13] Exynos5 SoC FIMC-IS imaging subsystem driver
Em Tue, 29 Oct 2013 01:06:30 +0100 Sylwester Nawrocki sylvester.nawro...@gmail.com escreveu: Hi Mauro, On 10/28/2013 11:11 PM, Mauro Carvalho Chehab wrote: The following changes since commit 8ca5d2d8e58df7235b77ed435e63c484e123fede: [media] uvcvideo: Fix data type for pan/tilt control (2013-10-17 06:55:29 -0300) are available in the git repository at: git://linuxtv.org/snawrocki/samsung.git for-v3.13-2 for you to fetch changes up to 6eb89d71b27e6731755ab5722f3cdc0f6e8273f2: V4L: Add s5k4e5 sensor driver (2013-10-18 21:36:42 +0200) Arun Kumar K (12): exynos5-fimc-is: Add Exynos5 FIMC-IS device tree bindings documentation As agreed during KS, the subsystem maintainers should wait for a documentation review on DT by the DT maintainers, at least for a while. So, I'd like to see either their reviews on this patch: https://patchwork.linuxtv.org/patch/20439/ Or their ack for us to apply it. I agree with you on that. Just please note the first version of this patch has been posted *5 months* ago https://patchwork.linuxtv.org/patch/18684 Stephen has reviewed subsequent version about 3 months ago: https://patchwork.linuxtv.org/patch/19521 Then we got no more comments from DT maintainers, I have reviewed this patch multiple times on the mailing lists: https://patchwork.linuxtv.org/patch/19715 https://patchwork.linuxtv.org/patch/19749 And explicitly asked for an Ack: https://patchwork.linuxtv.org/patch/19832 Then those 2 versions passed silently: https://patchwork.linuxtv.org/patch/20055 https://patchwork.linuxtv.org/patch/20225 And...huh...we got another review, I didn't notice it until now: https://patchwork.linuxtv.org/patch/20439 Thanks Mark. Arun, care to address those review comments and send us an updated binding documentation patch ? Hence I think we have waited for a while. ;) exynos5-fimc-is: Add driver core files exynos5-fimc-is: Add common driver header files exynos5-fimc-is: Add register definition and context header exynos5-fimc-is: Add isp subdev exynos5-fimc-is: Add scaler subdev exynos5-fimc-is: Add sensor interface exynos5-fimc-is: Add the hardware pipeline control exynos5-fimc-is: Add the hardware interface module exynos5-is: Add Kconfig and Makefile V4L: Add DT binding doc for s5k4e5 image sensor Same applies to this patch: https://patchwork.linuxtv.org/patch/20448/ This one also have been on the mailing list for quite some time and it uses already standard bindings, so I assumed it is OK to merge it. https://patchwork.linuxtv.org/project/linux-media/list/?state=*q=s5k4e5 But if there must be an Ack then we shall wait, it will probably won't make a big difference now, if this patch is postponed by 3 more months. Yeah, it seems that we've waited for a long time to get an ack there. So, let's do this: Please send a new version with Mark's comments. Also, please split Doc changes from the code changes on the new series. I'll wait for a couple days for DT people to review it. If we don't have any reply, I'll review and apply it for Kernel 3.13, if I don't see anything really weird on it. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ov3640 driver tested with media-ctl and yavta
Tom Bassai_Dai at gmx.net writes: Hello, I tried to use the ov3640 camera driver from Laurent Pinchart with the media-ctl and the yavta tools. I configured the pipeline as sensor - ccdc -memory. First I got problems with the CCDC module. it always said that the ccdc won't become idle!, but it didn't restart by itself. So for testing I removed the waiting function which waits for the ccdc to become idle and tried again. Now I received some data from the buffers but the image is just black. Any idea what my problem could be? Best Regards, Tom Hello, I still have the problem that I don't receive any image data when the waiting function is commented in. I just get the ccdc won't become idle output. when this function is commented out and the polarities within the board-overo.c file are correct. I get some image data on which I can see the right structure but wrong colors. Does anyone have an idea what the problem could be when the color is incorrect? http://imageshack.us/photo/my-images/707/wkjf.png/ Regrads, Tom -- 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] rtl2830: add parent for I2C adapter
Wolfram,
Phil email address was not valid anymore, so could you Wolfram, as a I2C
subsystem maintainer, look and comment that. The fact is that my driver
has a 3.12 regression and I want to know where it is coming from to make
decision what to do!
regards
Antti
On 21.10.2013 23:20, Antti Palosaari wrote:
Hello Phil and Wolfram,
I found one of my drivers was crashing when DTV USB stick was plugged.
Patch in that mail patch fixes the problem.
I quickly looked possible I2C patches causing the problem and saw that
one as most suspicions:
commit 3923172b3d700486c1ca24df9c4c5405a83e2309
i2c: reduce parent checking to a NOOP in non-I2C_MUX case
My config has no CONFIG_I2C_MUX set currently, but I am not sure how it
has been earlier.
Any idea?
regards
Antti
On 21.10.2013 23:12, Antti Palosaari wrote:
i2c i2c-6: adapter [RTL2830 tuner I2C adapter] registered
BUG: unable to handle kernel NULL pointer dereference at 0220
IP: [a0002900] i2c_register_adapter+0x130/0x390 [i2c_core]
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/rtl2830.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/dvb-frontends/rtl2830.c
b/drivers/media/dvb-frontends/rtl2830.c
index 362d26d..68ee70b 100644
--- a/drivers/media/dvb-frontends/rtl2830.c
+++ b/drivers/media/dvb-frontends/rtl2830.c
@@ -700,6 +700,7 @@ struct dvb_frontend *rtl2830_attach(const struct
rtl2830_config *cfg,
sizeof(priv-tuner_i2c_adapter.name));
priv-tuner_i2c_adapter.algo = rtl2830_tuner_i2c_algo;
priv-tuner_i2c_adapter.algo_data = NULL;
+priv-tuner_i2c_adapter.dev.parent = i2c-dev;
i2c_set_adapdata(priv-tuner_i2c_adapter, priv);
if (i2c_add_adapter(priv-tuner_i2c_adapter) 0) {
dev_err(i2c-dev,
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v3] [RFC] v4l2: Support for multiple selections
Hi Tomasz, (Please also see the notes from the Media summit Hans posted.) Tomasz Stanislawski wrote: Hi Ricardo, I am the designer of selection API. I hope I can help you a little. I think that there are two issues mixed in 'Mulitple selections' topic. Firstly, you described that you program a piece of hardware that is capable of selecting 8 areas for scanning. Now you are looking for userspace API to support such a feature. The feature of posting multiple rectangle was proposed in this RFC. Secondly, You introduced struct v4l2_ext_rect which is a future-proof version of v4l2_rect. I think that both issues should be solved in two separate patchsets. Ad 1. The selection of multiple scanning areas is a very driver-specific feature, isn't it? I think that you do not need to introduce any abstract interface. What would be other applications of the proposed interface? Do you know other drivers that may need it? Sakari mentioned introduction of private targets for selections. I like this idea. Just define: #define V4L2_SEL_TGT_PRIVATE 0x8000 I think a private target would definitely make sense if this was functionality that was present on a single sensor or two --- that's what I actually proposed for this originally. But as far as I understand, it is more common but just not present on sensors used in mobile devices. So standardising this makes sense. All targets that are = V4L2_SEL_TGT_PRIVATE are driver-specific. Generic applications must not use them. Non-generic application must check out the driver of video node before using selections from private set. If some target becomes more useful and accepted by more then one driver then it can be moved to generic API. The good thing about private target is that enums from different drivers can collide so the target space is not going to be trashed. But how to deal with multiple rectangles? I have an auxiliary question. Do you have to set all rectangles at once? can you set up them one by one? Anyway, first try to define something like this: #define V4L2_SEL_TGT_XXX_SCANOUT0 V4L2_SEL_TGT_PRIVATE #define V4L2_SEL_TGT_XXX_SCANOUT0_DEFAULT (V4L2_SEL_TGT_XXX_SCANOUT0 + 1) #define V4L2_SEL_TGT_XXX_SCANOUT0_BOUNDS (V4L2_SEL_TGT_XXX_SCANOUT0 + 2) #define V4L2_SEL_TGT_XXX_SCANOUT0 (V4L2_SEL_TGT_PRIVATE + 16) ... -- OR-- parametrized macros similar to one below: #define V4L2_SEL_TGT_XXX_SCANOUT(n) (V4L2_SEL_TGT_PRIVATE + 16 * (n)) The application could setup all scanout areas one-by-one. By default V4L2_SEL_TGT_XXX_SCANOUT0 would be equal to the whole array. The height of all consecutive area would be 0. This means disabling them effectively. The change of V4L2_SEL_TGT_XXX_SCANOUT0 would influence all consequtive rectangle by shifting them down or resetting them to height 0. Notice that as long as targets are driver specific you are free do define interaction between the targets. I hope that proposed solution is satisfactory. BTW. I think that the HW trick you described is not cropping. By cropping you select which part of sensor area is going to be processed into compose rectangle in a buffer. So technicaly you still insert the whole sensor area into the buffer. Only part of the buffer is actually updated. So there is no cropping (cropping area is equal to the whole array). Notice, that every 'cropping' area goes to different part of a buffer. So you would need also muliple targets for composing (!!!) and very long chapter in V4L2 doc describing interactions between muliple-rectangle crops and compositions. Good luck !!! :). Multiple crop rectangles shouldn't make that more difficult than it was since for the next step the image size is still a rectangle (it is just composed of several smaller ones). Drivers supporting this will suffer, though, but others shouldn't need to care. The documentation must thus also be changed to say that the crop rectangles must together form a rectangle if multiple rectangle support is added. I reckon Ricardo is looking forward to using this on V4L2 interface, but I think support should also be added to the V4L2 sub-device interface. Currently it is a hell to understand and define interaction between single crop, and compose and unfamous VIDIOC_S_FMT and m2m madness. I strongly recommend to use private selections. It will be much simpler to define, implement, and modify if needed. BTW2. I think that the mulitple scanout areas can be modelled using media device API. Sakari may know how to do this. The media device plays no part in subsystem specific matters such as formats. This is relevant in the scope of V4L2 only, IMHO. -- Kind regards, Sakari Ailus sakari.ai...@iki.fi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 07/19] v4l: sh_vou: Enable the driver on all ARM platforms
Renesas ARM platforms are transitioning from single-platform to multi-platform kernels using the new ARCH_SHMOBILE_MULTI. Make the driver available on all ARM platforms to enable it on both ARCH_SHMOBILE and ARCH_SHMOBILE_MULTI, and increase build testing coverage with COMPILE_TEST. Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de Cc: Mauro Carvalho Chehab m.che...@samsung.com Cc: linux-media@vger.kernel.org Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com --- drivers/media/platform/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index c7caf94..399ef1c 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -36,7 +36,7 @@ source drivers/media/platform/blackfin/Kconfig config VIDEO_SH_VOU tristate SuperH VOU video output driver depends on MEDIA_CAMERA_SUPPORT - depends on VIDEO_DEV ARCH_SHMOBILE I2C + depends on VIDEO_DEV (ARM || COMPILE_TEST) I2C select VIDEOBUF_DMA_CONTIG help Support for the Video Output Unit (VOU) on SuperH SoCs. -- 1.8.1.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 v7 1/5] omap3isp: Modify clocks registration to avoid circular references
Hi Laurent,
(adding Mauro and LMML at Cc)
On 10/29/2013 11:28 PM, Laurent Pinchart wrote:
Hi Sylwester,
Thank you for the patch.
On Tuesday 29 October 2013 20:51:04 Sylwester Nawrocki wrote:
The clock core code is going to be modified so clk_get() takes
reference on the clock provider module. Until the potential circular
reference issue is properly addressed, we pass NULL as as the first
argument to clk_register(), in order to disallow sub-devices taking
a reference on the ISP module back trough clk_get(). This should
prevent locking the modules in memory.
Cc: Laurent Pinchartlaurent.pinch...@ideasonboard.com
Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
Acked-by: Laurent Pinchartlaurent.pinch...@ideasonboard.com
Do you plan to push this to mainline as part of this patch series ? I don't
have pending patches for the omap3isp that would conflict with this patch, so
that would be fine with me.
Thanks, yes I thought this patch might be merged together through the clk
tree, if Mike is willing to take it and we get yours and Mauro's Ack on it.
---
This patch has been compile tested only.
---
drivers/media/platform/omap3isp/isp.c | 22 --
drivers/media/platform/omap3isp/isp.h |1 +
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c index df3a0ec..286027a 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -290,9 +290,11 @@ static int isp_xclk_init(struct isp_device *isp)
struct clk_init_data init;
unsigned int i;
+ for (i = 0; i ARRAY_SIZE(isp-xclks); ++i)
+ isp-xclks[i].clk = ERR_PTR(-EINVAL);
+
for (i = 0; i ARRAY_SIZE(isp-xclks); ++i) {
struct isp_xclk *xclk =isp-xclks[i];
- struct clk *clk;
xclk-isp = isp;
xclk-id = i == 0 ? ISP_XCLK_A : ISP_XCLK_B;
@@ -305,10 +307,15 @@ static int isp_xclk_init(struct isp_device *isp)
init.num_parents = 1;
xclk-hw.init =init;
-
- clk = devm_clk_register(isp-dev,xclk-hw);
- if (IS_ERR(clk))
- return PTR_ERR(clk);
+ /*
+* The first argument is NULL in order to avoid circular
+* reference, as this driver takes reference on the
+* sensor subdevice modules and the sensors would take
+* reference on this module through clk_get().
+*/
+ xclk-clk = clk_register(NULL,xclk-hw);
+ if (IS_ERR(xclk-clk))
+ return PTR_ERR(xclk-clk);
if (pdata-xclks[i].con_id == NULL
pdata-xclks[i].dev_id == NULL)
@@ -320,7 +327,7 @@ static int isp_xclk_init(struct isp_device *isp)
xclk-lookup-con_id = pdata-xclks[i].con_id;
xclk-lookup-dev_id = pdata-xclks[i].dev_id;
- xclk-lookup-clk = clk;
+ xclk-lookup-clk = xclk-clk;
clkdev_add(xclk-lookup);
}
@@ -335,6 +342,9 @@ static void isp_xclk_cleanup(struct isp_device *isp)
for (i = 0; i ARRAY_SIZE(isp-xclks); ++i) {
struct isp_xclk *xclk =isp-xclks[i];
+ if (!IS_ERR(xclk-clk))
+ clk_unregister(xclk-clk);
+
if (xclk-lookup)
clkdev_drop(xclk-lookup);
}
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h index cd3eff4..1498f2b 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -135,6 +135,7 @@ struct isp_xclk {
struct isp_device *isp;
struct clk_hw hw;
struct clk_lookup *lookup;
+ struct clk *clk;
enum isp_xclk_id id;
spinlock_t lock;/* Protects enabled and divider */
--
Regards,
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: [GIT PULL FOR 3.13] Exynos5 SoC FIMC-IS imaging subsystem driver
On 10/29/2013 01:54 PM, Mauro Carvalho Chehab wrote: [...] Yeah, it seems that we've waited for a long time to get an ack there. So, let's do this: Please send a new version with Mark's comments. Also, please split Doc changes from the code changes on the new series. I'll wait for a couple days for DT people to review it. If we don't have any reply, I'll review and apply it for Kernel 3.13, if I don't see anything really weird on it. Ok, I will make sure all DT binding documentation is in separate patches, actually only one patch needs to be reworked. Since Mark already reviewed the FIMC-IS and the S5K4E5 image sensor DT binding patches the only one which may need further review is this one: https://patchwork.linuxtv.org/patch/20237 Arun, could you send us the updated series ? Unfortunately I might not be able to find time to address those comments myself until Friday. -- 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 3/7] video: exynos_mipi_dsim: Use the generic PHY driver
On 10/29/2013 09:38 AM, Donghwa Lee wrote: On Tue, OCT 28, 2013 21:24, Tomasz Figa wrote: On Monday 28 of October 2013 15:12:08 Donghwa Lee wrote: [...] First of all, the exynos_mipi_dsim driver has currently no users in mainline kernel, so it is essentially dead code. In addition, on a platform that is the primary candidate for using it, which is Exynos, there is no way to use it, due to no DT support. As I mentioned above, patches are submitted sometimes and I will update this driver as soon as possible to support DT. As for the driver itself, it is not really a great example of good code. It contains a hacks, like calling msleep() without any clear reason and also many coding style issues. I'd prefer to replace it with the new exynos-dsi driver rewritten completely in SRPOL, when CDF is finished. Yes, I know this drivers had been changed about only minor issues and it is not really good code style. And CDF is more good and light. But discussion for CDF is still remaining a kind of requests. If it is merged into linux kernel and many users use it, existing MIPI DSI drivers will be replaced with the new drivers naturally, isn't it? Not necessarily. Our goal should be to have fairly stable DT binding at the SoC side so all available panels can possibly be used with any SoC without problems. Then please refrain for a while from pushing entirely vendor specific DT bindings upstream. Let's focus instead on an as much as possible common framework and the DT bindings. Whether the CDF will be part of DRM or not the DT bindings are supposed to be generic, so they work with whatever driver architecture. I guess you could try to come up with an unstable DT binding for the MIPI DSIM and display panels it is used with, but at this stage it seems just a waste of time. If there were no SoC specific panel drivers in the kernel there would be now much less trouble with DT support. -- 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
[PATCH -next] [media] v4l: ti-vpe: use module_platform_driver to simplify the code
From: Wei Yongjun yongjun_...@trendmicro.com.cn
module_platform_driver() makes the code simpler by eliminating
boilerplate code.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/media/platform/ti-vpe/vpe.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index 4e58069..89658a3 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -2081,18 +2081,7 @@ static struct platform_driver vpe_pdrv = {
},
};
-static void __exit vpe_exit(void)
-{
- platform_driver_unregister(vpe_pdrv);
-}
-
-static int __init vpe_init(void)
-{
- return platform_driver_register(vpe_pdrv);
-}
-
-module_init(vpe_init);
-module_exit(vpe_exit);
+module_platform_driver(vpe_pdrv);
MODULE_DESCRIPTION(TI VPE driver);
MODULE_AUTHOR(Dale Farnsworth, d...@farnsworth.org);
--
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 -next] [media] v4l: ti-vpe: fix error return code in vpe_probe()
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/media/platform/ti-vpe/vpe.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index 4e58069..0dbfd52 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -2007,8 +2007,10 @@ static int vpe_probe(struct platform_device *pdev)
vpe_top_vpdma_reset(dev);
dev-vpdma = vpdma_create(pdev);
- if (IS_ERR(dev-vpdma))
+ if (IS_ERR(dev-vpdma)) {
+ ret = PTR_ERR(dev-vpdma);
goto runtime_put;
+ }
vfd = dev-vfd;
*vfd = vpe_videodev;
--
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 -next] [media] v4l: ti-vpe: fix return value check in vpe_probe()
From: Wei Yongjun yongjun_...@trendmicro.com.cn
In case of error, the function devm_kzalloc() and devm_ioremap()
returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return
value check should be replaced with NULL test.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/media/platform/ti-vpe/vpe.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index 4e58069..90cf369 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -1942,8 +1942,8 @@ static int vpe_probe(struct platform_device *pdev)
int ret, irq, func;
dev = devm_kzalloc(pdev-dev, sizeof(*dev), GFP_KERNEL);
- if (IS_ERR(dev))
- return PTR_ERR(dev);
+ if (!dev)
+ return -ENOMEM;
spin_lock_init(dev-lock);
@@ -1962,8 +1962,8 @@ static int vpe_probe(struct platform_device *pdev)
* registers based on the sub block base addresses
*/
dev-base = devm_ioremap(pdev-dev, res-start, SZ_32K);
- if (IS_ERR(dev-base)) {
- ret = PTR_ERR(dev-base);
+ if (!dev-base) {
+ ret = -ENOMEM;
goto v4l2_dev_unreg;
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Oct 30 04:00:36 CET 2013 git branch: for-v3.13c git hash: 3adeac2c34cc28e05d0ec52f38f009dcce278555 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.11-4.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-rc1-i686: OK linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-rc1-x86_64: OK apps: WARNINGS spec-git: OK sparse version: 0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] rtl28xxu: add 15f4:0131 Astrometa DVB-T2
Components are RTL2832P + R828D + MN88472.
Currently support only DVB-T as there is no driver for MN88472 demod.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index 8c600b7..ecca036 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1427,6 +1427,9 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
rtl2832u_props, Leadtek WinFast DTV Dongle mini, NULL) },
{ DVB_USB_DEVICE(USB_VID_GTEK, USB_PID_CPYTO_REDI_PC50A,
rtl2832u_props, Crypto ReDi PC 50 A, NULL) },
+
+ { DVB_USB_DEVICE(USB_VID_HANFTEK, 0x0131,
+ rtl2832u_props, Astrometa DVB-T2, NULL) },
{ }
};
MODULE_DEVICE_TABLE(usb, rtl28xxu_id_table);
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] r820t: add support for R828D
Small changes in order to support tuner version R828D @ 16 MHz clock.
There was 'vco_fine_tune' check, which seems to adjust synthesizer
output divider (mixer dix / LO div / Rout) by one. R828D seems to
return vco_fine_tune=1 every time and that condition causes tuning
fail as output divider was increased by one.
Resolve problem by skipping whole condition in case of R828D tuner.
Just to mention, other tuner, R820T, seems to return 2 here.
Synthesizer maximum frequency check was hard coded to check synthesizer N
and thus worked correctly only for clock frequencies around 30 MHz.
As whole test is quite useless in any case, I removed it totally.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/tuners/r820t.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/media/tuners/r820t.c b/drivers/media/tuners/r820t.c
index 1c23666..d9ee43f 100644
--- a/drivers/media/tuners/r820t.c
+++ b/drivers/media/tuners/r820t.c
@@ -612,10 +612,19 @@ static int r820t_set_pll(struct r820t_priv *priv, enum
v4l2_tuner_type type,
vco_fine_tune = (data[4] 0x30) 4;
- if (vco_fine_tune VCO_POWER_REF)
- div_num = div_num - 1;
- else if (vco_fine_tune VCO_POWER_REF)
- div_num = div_num + 1;
+ tuner_dbg(mix_div=%d div_num=%d vco_fine_tune=%d\n,
+ mix_div, div_num, vco_fine_tune);
+
+ /*
+* XXX: R828D/16MHz seems to have always vco_fine_tune=1.
+* Due to that, this calculation goes wrong.
+*/
+ if (priv-cfg-rafael_chip != CHIP_R828D) {
+ if (vco_fine_tune VCO_POWER_REF)
+ div_num = div_num - 1;
+ else if (vco_fine_tune VCO_POWER_REF)
+ div_num = div_num + 1;
+ }
rc = r820t_write_reg_mask(priv, 0x10, div_num 5, 0xe0);
if (rc 0)
@@ -637,11 +646,6 @@ static int r820t_set_pll(struct r820t_priv *priv, enum
v4l2_tuner_type type,
vco_fra = pll_ref * 129 / 128;
}
- if (nint 63) {
- tuner_info(No valid PLL values for %u kHz!\n, freq);
- return -EINVAL;
- }
-
ni = (nint - 13) / 4;
si = nint - 4 * ni - 13;
--
1.8.3.1
--
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 3/4] rtl28xxu: add RTL2832P + R828D support
RTL2832P is version of RTL2832U with extra TS interface.
As for now, we support only integrated RTL2832 demod.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 39 +
drivers/media/usb/dvb-usb-v2/rtl28xxu.h | 1 +
2 files changed, 40 insertions(+)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index c0cd084..8c600b7 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -377,6 +377,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
struct rtl28xxu_req req_e4000 = {0x02c8, CMD_I2C_RD, 1, buf};
struct rtl28xxu_req req_tda18272 = {0x00c0, CMD_I2C_RD, 2, buf};
struct rtl28xxu_req req_r820t = {0x0034, CMD_I2C_RD, 1, buf};
+ struct rtl28xxu_req req_r828d = {0x0074, CMD_I2C_RD, 1, buf};
dev_dbg(d-udev-dev, %s:\n, __func__);
@@ -489,6 +490,15 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
goto found;
}
+ /* check R828D ID register; reg=00 val=69 */
+ ret = rtl28xxu_ctrl_msg(d, req_r828d);
+ if (ret == 0 buf[0] == 0x69) {
+ priv-tuner = TUNER_RTL2832_R828D;
+ priv-tuner_name = R828D;
+ goto found;
+ }
+
+
found:
dev_dbg(d-udev-dev, %s: tuner=%s\n, __func__, priv-tuner_name);
@@ -745,6 +755,7 @@ static int rtl2832u_frontend_attach(struct dvb_usb_adapter
*adap)
rtl2832_config = rtl28xxu_rtl2832_e4000_config;
break;
case TUNER_RTL2832_R820T:
+ case TUNER_RTL2832_R828D:
rtl2832_config = rtl28xxu_rtl2832_r820t_config;
break;
default:
@@ -866,6 +877,13 @@ static const struct r820t_config rtl2832u_r820t_config = {
.rafael_chip = CHIP_R820T,
};
+static const struct r820t_config rtl2832u_r828d_config = {
+ .i2c_addr = 0x3a,
+ .xtal = 1600,
+ .max_i2c_msg_len = 2,
+ .rafael_chip = CHIP_R828D,
+};
+
static int rtl2832u_tuner_attach(struct dvb_usb_adapter *adap)
{
int ret;
@@ -923,6 +941,27 @@ static int rtl2832u_tuner_attach(struct dvb_usb_adapter
*adap)
adap-fe[0]-ops.read_signal_strength =
adap-fe[0]-ops.tuner_ops.get_rf_strength;
break;
+ case TUNER_RTL2832_R828D:
+ /* power off mn88472 demod on GPIO0 */
+ ret = rtl28xx_wr_reg_mask(d, SYS_GPIO_OUT_VAL, 0x00, 0x01);
+ if (ret)
+ goto err;
+
+ ret = rtl28xx_wr_reg_mask(d, SYS_GPIO_DIR, 0x00, 0x01);
+ if (ret)
+ goto err;
+
+ ret = rtl28xx_wr_reg_mask(d, SYS_GPIO_OUT_EN, 0x01, 0x01);
+ if (ret)
+ goto err;
+
+ fe = dvb_attach(r820t_attach, adap-fe[0], d-i2c_adap,
+ rtl2832u_r828d_config);
+
+ /* Use tuner to get the signal strength */
+ adap-fe[0]-ops.read_signal_strength =
+ adap-fe[0]-ops.tuner_ops.get_rf_strength;
+ break;
default:
fe = NULL;
dev_err(d-udev-dev, %s: unknown tuner=%d\n, KBUILD_MODNAME,
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.h
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.h
index 729b354..2142bcb 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.h
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.h
@@ -83,6 +83,7 @@ enum rtl28xxu_tuner {
TUNER_RTL2832_TDA18272,
TUNER_RTL2832_FC0013,
TUNER_RTL2832_R820T,
+ TUNER_RTL2832_R828D,
};
struct rtl28xxu_req {
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] rtl2832: add new tuner R828D
Use R820T config for R828D too as those are about same tuner.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/rtl2832.c | 1 +
drivers/media/dvb-frontends/rtl2832.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/media/dvb-frontends/rtl2832.c
b/drivers/media/dvb-frontends/rtl2832.c
index facb848..a95dfe0 100644
--- a/drivers/media/dvb-frontends/rtl2832.c
+++ b/drivers/media/dvb-frontends/rtl2832.c
@@ -489,6 +489,7 @@ static int rtl2832_init(struct dvb_frontend *fe)
init = rtl2832_tuner_init_e4000;
break;
case RTL2832_TUNER_R820T:
+ case RTL2832_TUNER_R828D:
len = ARRAY_SIZE(rtl2832_tuner_init_r820t);
init = rtl2832_tuner_init_r820t;
break;
diff --git a/drivers/media/dvb-frontends/rtl2832.h
b/drivers/media/dvb-frontends/rtl2832.h
index 91b2dcf..2cfbb6a 100644
--- a/drivers/media/dvb-frontends/rtl2832.h
+++ b/drivers/media/dvb-frontends/rtl2832.h
@@ -53,6 +53,7 @@ struct rtl2832_config {
#define RTL2832_TUNER_E4000 0x27
#define RTL2832_TUNER_FC00130x29
#define RTL2832_TUNER_R820T0x2a
+#define RTL2832_TUNER_R828D0x2b
u8 tuner;
};
--
1.8.3.1
--
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
