cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sat Sep 28 04:00:34 CEST 2013 git branch: test git hash: ffee921033e64edf8579a3b21c7f15d1a6c3ef71 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.10.1 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.10.1-i686: OK linux-3.1.10-i686: OK linux-3.11.1-i686: OK linux-3.12-rc1-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-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.10.1-x86_64: OK linux-3.1.10-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-rc1-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 apps: WARNINGS spec-git: OK ABI WARNING: change for arm-at91 ABI WARNING: change for arm-davinci ABI WARNING: change for arm-exynos ABI WARNING: change for arm-mx ABI WARNING: change for arm-omap ABI WARNING: change for arm-omap1 ABI WARNING: change for arm-pxa ABI WARNING: change for blackfin ABI WARNING: change for i686 ABI WARNING: change for m32r ABI WARNING: change for mips ABI WARNING: change for powerpc64 ABI WARNING: change for sh ABI WARNING: change for x86_64 sparse version: 0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [stable] Re: Dependency bug in the uvcvideo Kconfig
On Thu, Sep 19, 2013 at 04:00:53PM -0700, Randy Dunlap wrote: > On 09/19/13 13:17, Randy Dunlap wrote: > > On 09/18/13 20:44, Jeff P. Zacher wrote: > >> > >> > >> You are correct that this problem shown in the forum was in 3.5.4. > >> However, I am > >> having wither the same or similar problem in 3.10.7. > >> Here is the broken config file, saved as .config-bad > >> > > > > The failing kernel config file is attached. > > For Linux 3.10.x: > > > This is already fixed in mainline but patches need to be backported. > Specifically these 2 commits (in this order): > > > commit a0f9354b1a319cb29c331bfd2e5a15d7f9b87fa4 > Author: Randy Dunlap > Date: Wed May 8 17:28:13 2013 -0300 > > [media] media/usb: fix kconfig dependencies > > and > > commit 5077ac3b8108007f4a2b4589f2d373cf55453206 > Author: Mauro Carvalho Chehab > Date: Wed May 22 11:25:52 2013 -0300 > > Properly handle tristate dependencies on USB/PCI menus > Applied, thanks. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media-workshop] V2: Agenda for the Edinburgh mini-summit
On Sat, Sep 28, 2013 at 01:07:34AM +0300, Sakari Ailus wrote: > > > I would be happy to add another brainstorming day, but since Hugues won't > > > be > > > available on the 21st we can only do limited codec discussions, so we > > > would > > > need other topics as well. Proposals are welcome. Oops. I missed this. I'll arrive to Edinburgh on the afternoon 22nd so 21st is out of question for me. :I -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media-workshop] V2: Agenda for the Edinburgh mini-summit
Hi Hans and Laurent, On Wed, Sep 25, 2013 at 12:39:11PM +0200, Laurent Pinchart wrote: > Hi Hans, > > On Tuesday 24 September 2013 13:24:25 Hans Verkuil wrote: > > On Tue 24 September 2013 12:59:44 Laurent Pinchart wrote: > > > On Tuesday 10 September 2013 11:34:32 Hans Verkuil wrote: > > > > I have collected all the ideas up to now in a V2 of the agenda. > > > > > > > > The items are grouped by the person(s) that suggested them. As done in > > > > the past those who suggested a topic and who will attend the mini-summit > > > > are expected to prepare for it, perhaps making a (very) small > > > > presentation if necessary. > > > > > > [snip] > > > > > > > As it stands I don't think it will be possible to handle it all in one > > > > day. In particular the codec problem as mentioned by Oliver et al needs > > > > a lot of time. Should we set aside a separate day for just this? October > > > > 21 or 22 would work for me. I would really like to get some feedback on > > > > this. If we decide to go for a second day for this topic, then I can see > > > > if I can get a room. It looks like there is a lot of interest in getting > > > > this sorted, so brainstorming for a day might be quite useful. > > > > > > I believe a second day would indeed be very useful. As the ARM kernel > > > summit will take place on the 22nd and 23rd, I would vote for > > > brainstorming on the 21st. > > > > I'm working on the agenda and I think we have enough time to go through > > all the items in one day. It would be great if you can be present for either > > the morning or afternoon for the mini-summit. I have about 4 hours worth of > > topics for which your input would be much appreciated. > > The ARM KS agenda hasn't been published yet, so I can't tell when I'll be > available. I've CC'ed you on an e-mail to Olof regarding this. > > > I would be happy to add another brainstorming day, but since Hugues won't be > > available on the 21st we can only do limited codec discussions, so we would > > need other topics as well. Proposals are welcome. Sounds like a good idea to me. I haven't been in the meetings for a while but in the past the tendency has often been that there's more to discuss that what there's time for. > Brainstorming a property-based API is one topic that would benefit from > longer > discussions. I'm also always free to discuss CDF and how it would be related What an excellent idea! :) > with V4L2 in the future :-) -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] omap3isp : fix image corruption after underrun when using resizer
Hi Jean-Philippe, On Thu, Sep 26, 2013 at 03:52:37PM +0200, jean-philippe francois wrote: > Hi Laurent, > > I was able to reliably get corrupted image when placing the pipeline in > underrun > condition. The pipeline looks like this : > YUYV sensor -> CCDC -> Resizer -> V4L output > > It seems that triggering 'frame sync event' before last line leads to > possible corrupted images > when using the resizer. I think this was rather understood to be somewhat unoptimal way to trigger the interrupt at the end of the frame. > With current code, ISP resizer is always configured in oneshot, and > must be restarted after > each frame. However, has stated by a comment in ispresizer.c, > restarting the resizer while > a frame is sent to the ccdc leads to corrupted images. > > The current resizer code takes care of this restart in two places : > > - in normal situation, when the 'resizer done' IRQ is triggered, a > buffer is available > and the resizer is restarted in the resizer_isr_buffer function > > - in underrun situation, no buffer is available when the resizer done > irq triggers. After a buffer > has eventually been queued, the resizer is restarted on the following > frame sync. > > However, the frame sync event is not generated by the hardware frame sync, > but by the VD0 interrupt of the CCDC. But VD0 event is triggered a > bit early, since it is > configured to trigger after height - 1 lines. It is therefore possible > to restart the resizer while a frame's > last line is being sent. I guess one should then wait for the CCDC to become idle as well. Currently this is not being done --- i.e. ccdc_sbl_wait_idle() should then be called first. > The following patch configures VD0 to trigger after the last line, and > solves the image > corruption issue. However, the previous value does not look like an > off by one error. > What are the reasons to configure VD0 before the last line ? What are > the possible issues > triggered by a change like this ? The VD counter is incremented by the hsync singal. Depending on the polarity, the value of the VD counter at the beginning of last line is either height - 2 or height - 1, and this should be reflected in the configuration as well. Which one do you have? -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 01/13] [media] exynos5-is: Adding media device driver for exynos5
Hi Arun, Shaik, This patch looks good to me, I have added it to my tree for 3.13, with slightly edited patch's description. I will be sending a pull request to the media tree not earlier than in two weeks, thus there is still some time, should anyone have any further comments/change requests. Before applying rest of the series we need an ACK for the patch 02/13 from a DT binding maintainer. Thank you for your hard work on this. 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: Need help with AverMedia306 driver on linux system.
Good news, and thank you for the feedback Must be because I am in Paris/FRANCE, they went all TNT (dvb) I thaught they left a channel or two in the hertzerian analog but not :( or my reception is really bad ... And you have the right cables if it's in it's original laptop !! :) Thnx again for your help !! > Le 27 septembre 2013 à 13:20, Nguyễn Minh Hoàng a >écrit : > > > Yes, you are so smart, buddy. I know you are not developer of these card >driver. But you got the way to make this card worked well. So i wrote to you. >I am not successful with your 306 patches because i use other revision of >linuxtv driver, i tried modprobe option with card=39 too and as you say, it >works as analog - no dvb. This card is hybridge, not single analog or dvb. If >you get the way, help me with your way :) thank you. > > Sent from my iPhone > > > On Sep 27, 2013, at 6:06 PM, remi wrote: > > > > Oh, I am not the person who wrote the driver ... :( > > > > > > I merly cloned the HC81r, gave it the proper PCI ID, and the correct >firmware , > > > > I also have no DVB either, > > > > Unless I get time to learn V4L API, or the mainter of the "xc2028" finds >more > > infos too ... > > > > we are prety much at this stage, some analog, but no dvb ... > > > > at my knowlodge . > > > > > > Best regards > > > > Rémi > > > > > > > > > >> Le 27 septembre 2013 à 12:46, Nguyễn Minh Hoàng >a écrit : > >> > >> > >> Thank you for your relying. I know that your patch is not same my >revision, i can't apply it. I think i should find and add your patches >manually, but there are so much code to do. I am on phone now. I will send you >some more detail when i am back to my computer. Pls help me. > >> Ps: i used "option=39" before, my system got it as video and vbi device, >not dvb device. Maybe i need some patches in this case as your suggestion >today. > >> Thank you again! > >> > >> Sent from my iPhone > >> > >> > On Sep 27, 2013, at 3:24 PM, remi wrote: > >> > > >> > :) > >> > > >> > Also, > >> > > >> > > >> > by the time I redo the patch, > >> > > >> > > >> > You must have seen how i have reached this point, > >> > > >> > I have actually started by insering the module with card=39 as an >option, > >> > > >> > > >> > So you can for now, add theses line to > >> > > >> > gpunk@gpunk-Aspire-8930:~$cat /etc/modprobe.d/video-tv.conf > >> > > >> > > >> > options tuner-xc2028 firmware_name=xc3028-v27.fw > >> > options cx23885 card=39 > >> > > >> > > >> > I called my file this way ... it's arbitrary, please check the man >modprobe of > >> > your ditribution/kernel . > >> > > >> > > >> > Best regards > >> > > >> > Rémi > >> > > >> > > >> > > >> >> Le 21 septembre 2013 à 19:43, "ad...@tydaikho.com" > a écrit : > >> >> > >> >> > >> >> Hi Remi! > >> >> I got my card but i have not finish to install driver. I follow your >patch on linuxtv.org but i am not successful. it makes some mistake: "malform" >and "hunk" errors. > >> >> === > >> >> root@ty-debian:/usr/local/src/linuxtv# patch -p1 < ./cx23885.patch > >> >> can't find file to patch at input line 3 > >> >> Perhaps you used the wrong -p or --strip option? > >> >> The text leading up to this was: > >> >> -- > >> >> |--- drivers/media/pci/cx23885/cx23885.h 2013-03-25 >05:45:50.0 +0100 > >> >> |+++ drivers/media/pci/cx23885/cx23885.h 2013-08-21 >13:55:20.010625134 +0200 > >> >> -- > >> >> File to patch: ./drivers/media/pci/cx23885/cx23885.h > > >> >> patching file ./drivers/media/pci/cx23885/cx23885.h > >> >> patch: malformed patch at line 4: #define >CX23885_BOARD_PROF_800037 > >> >> == > >> >> root@ty-debian:/usr/local/src/linuxtv# patch -p1 < >./cx23885-video.patch > >> >> can't find file to patch at input line 4 > >> >> Perhaps you used the wrong -p or --strip option? > >> >> The text leading up to this was: > >> >> -- > >> >> |--- drivers/media/pci/cx23885/cx23885-video.c 2013-08-02 >05:45:59.0 +0200 > >> >> |+++ drivers/media/pci/cx23885/cx23885-video.c2013-08-21 >13:55:20.017625046 > >> >> |+0200 > >> >> -- > >> >> File to patch: ./drivers/media/pci/cx23885/cx23885-video.c > >> >> patching file ./drivers/media/pci/cx23885/cx23885-video.c > >> >> Hunk #1 FAILED at 511. > >> >> Hunk #2 FAILED at 1888. > >> >> 2 out of 2 hunks FAILED -- saving rejects to file >./drivers/media/pci/cx23885/cx23885-video.c.rej > >> >> > >> >> root@ty-debian:/usr/local/src/linuxtv# patch -p1 < >./cx23885-cards.patch > >> >> can't find file to patch at input line 4 > >> >> Perhaps you used the wrong -p or --strip option? > >> >> The text leading up to this was: > >> >
[PATCH/RFC v3 3/3] add pipe link for display entity
---
arch/arm/boot/dts/rtsm_ve-motherboard.dtsi | 46
arch/arm/boot/dts/rtsm_ve-v2p-ca15x1-ca7x1.dts |4 +++
2 files changed, 50 insertions(+)
diff --git a/arch/arm/boot/dts/rtsm_ve-motherboard.dtsi
b/arch/arm/boot/dts/rtsm_ve-motherboard.dtsi
index 6d12566..b4e032a 100644
--- a/arch/arm/boot/dts/rtsm_ve-motherboard.dtsi
+++ b/arch/arm/boot/dts/rtsm_ve-motherboard.dtsi
@@ -166,6 +166,17 @@
mode = "VGA";
use_dma = <0>;
framebuffer = <0x1800 0x0018>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ clcd_out: endpoint {
+ };
+ };
+ };
};
};
@@ -214,6 +225,41 @@
muxfpga@0 {
compatible = "arm,vexpress-muxfpga";
arm,vexpress-sysreg,func = <7 0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ muxfpga_in: endpoint {
+ remote-endpoint = <&clcd_out>;
+ };
+ };
+ port@1 {
+ reg = <1>;
+ muxfpga_out: endpoint {
+ remote-endpoint = <&con_vga_in>;
+ };
+ };
+
+ };
+ };
+
+ con-vga {
+ compatible = "con-vga";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ con_vga_in: endpoint {
+ remote-endpoint =
<&muxfpga_out>;
+ };
+ };
+ };
};
shutdown@0 {
diff --git a/arch/arm/boot/dts/rtsm_ve-v2p-ca15x1-ca7x1.dts
b/arch/arm/boot/dts/rtsm_ve-v2p-ca15x1-ca7x1.dts
index c59f4b5..45a07c5 100644
--- a/arch/arm/boot/dts/rtsm_ve-v2p-ca15x1-ca7x1.dts
+++ b/arch/arm/boot/dts/rtsm_ve-v2p-ca15x1-ca7x1.dts
@@ -230,4 +230,8 @@
};
};
+&clcd_out {
+ remote-endpoint = <&muxfpga_in>;
+};
+
/include/ "clcd-panels.dtsi"
--
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/CDF RFC v3 0/3] Migrate CDFv3 into pl111 drm/kms driver
Hi all, This series patches base on Tom's "Initial drm/kms driver for pl111"[1] with linaro release 13.07 and migrate the CDFv3 for evaluation. please notes that I set VGA as default output and tested on RTSM only. [1] http://lwn.net/Articles/561344/ Cheers, Show Liu Show Liu (3): Add display entities and pipe link for pl111 Add display entity and set VGA output(site MB) as default add pipe link for display entity arch/arm/boot/dts/rtsm_ve-motherboard.dtsi | 46 +++ arch/arm/boot/dts/rtsm_ve-v2p-ca15x1-ca7x1.dts |4 + drivers/gpu/drm/pl111/pl111_drm.h | 23 +- drivers/gpu/drm/pl111/pl111_drm_device.c | 374 ++-- drivers/video/vexpress-dvi.c | 94 +- 5 files changed, 503 insertions(+), 38 deletions(-) -- 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/RFC v3 2/3] Add display entity and set VGA output(site MB) as default
---
drivers/video/vexpress-dvi.c | 94 +-
1 file changed, 83 insertions(+), 11 deletions(-)
diff --git a/drivers/video/vexpress-dvi.c b/drivers/video/vexpress-dvi.c
index cbcb443..ca0e5bd 100644
--- a/drivers/video/vexpress-dvi.c
+++ b/drivers/video/vexpress-dvi.c
@@ -18,6 +18,12 @@
#include
#include
+#include
+#include
+
+struct _mux_fpga {
+struct display_entity entity;
+};
static struct vexpress_config_func *vexpress_dvimode_func;
@@ -146,6 +152,52 @@ static int vexpress_dvi_fb_event_notify(struct
notifier_block *self,
return NOTIFY_OK;
}
+static int mux_fpga_set_state(struct display_entity *entity,
+enum
display_entity_state state)
+{
+ struct media_pad *source;
+ source = media_entity_remote_pad(&entity->entity.pads[0]);
+ if (source == NULL)
+ return -EPIPE;
+
+ switch (state) {
+ case DISPLAY_ENTITY_STATE_OFF:
+ case DISPLAY_ENTITY_STATE_STANDBY:
+
display_entity_set_stream(to_display_entity(source->entity),
+
source->index,
+
DISPLAY_ENTITY_STREAM_STOPPED);
+ break;
+
+ case DISPLAY_ENTITY_STATE_ON:
+
display_entity_set_stream(to_display_entity(source->entity),
+
source->index,
+
DISPLAY_ENTITY_STREAM_CONTINUOUS);
+ break;
+ }
+
+ return 0;
+}
+
+static int mux_fpga_get_params(struct display_entity *entity, unsigned int
port,
+ struct
display_entity_interface_params *params)
+{
+ memset(params, 0, sizeof(*params));
+
+ /* default using VGA interface type */
+ params->type = DISPLAY_ENTITY_INTERFACE_VGA;
+
+ return 0;
+}
+
+static const struct display_entity_control_ops mux_fpga_control_ops = {
+ .set_state = mux_fpga_set_state,
+ .get_params = mux_fpga_get_params,
+};
+
+static const struct display_entity_ops mux_fpga_ops = {
+ .ctrl = &mux_fpga_control_ops,
+};
+
static struct notifier_block vexpress_dvi_fb_notifier = {
.notifier_call = vexpress_dvi_fb_event_notify,
};
@@ -170,7 +222,9 @@ static int vexpress_dvi_probe(struct platform_device *pdev)
enum vexpress_dvi_func func;
const struct of_device_id *match =
of_match_device(vexpress_dvi_of_match, &pdev->dev);
- u32 site;
+ struct _mux_fpga*mux_fpga = NULL;
+
+ int ret = 0;
if (match)
func = (enum vexpress_dvi_func)match->data;
@@ -182,18 +236,36 @@ static int vexpress_dvi_probe(struct platform_device
*pdev)
vexpress_muxfpga_func =
vexpress_config_func_get_by_dev(&pdev->dev);
device_create_file(&pdev->dev, &dev_attr_fb);
- /* hard-coded for test DRM on RTSM
- Set default site = 0
- */
- if (vexpress_dvi_fb < 0){
- /*default site = 0*/
- site = 0;
- vexpress_config_write(vexpress_muxfpga_func, 0, site);
- vexpress_dvi_fb = site;
- }
+
+ /*
+* default using VEXPRESS_SITE_MB
+*/
+ pr_info("Set Site MB as Default\n");
+ vexpress_config_write(vexpress_muxfpga_func, 0,
VEXPRESS_SITE_MB);
+ vexpress_dvi_fb = VEXPRESS_SITE_MB;
+
+ /* initialize display entity */
+ mux_fpga = devm_kzalloc(&pdev->dev, sizeof(*mux_fpga),
GFP_KERNEL);
+ if (mux_fpga == NULL)
+ return -ENOMEM;
+
+ mux_fpga->entity.dev = &pdev->dev;
+ mux_fpga->entity.ops = &mux_fpga_ops;
+ strlcpy(mux_fpga->entity.name, dev_name(&pdev->dev),
sizeof(mux_fpga->entity.name));
+
+ ret = display_entity_init(&mux_fpga->entity, 1, 1);
+ if (ret < 0)
+ return ret;
+
+ ret = display_entity_add(&mux_fpga->entity);
+ if (ret < 0)
+ return ret;
+
+ platform_set_drvdata(pdev, mux_fpga);
break;
case FUNC_DVIMODE:
vexpress_dvimode_func =
+
vexpress_config_fun
[PATCH/RFC v3 1/3] Add display entities and pipe link for pl111
---
drivers/gpu/drm/pl111/pl111_drm.h| 23 +-
drivers/gpu/drm/pl111/pl111_drm_device.c | 374 --
2 files changed, 370 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/pl111/pl111_drm.h
b/drivers/gpu/drm/pl111/pl111_drm.h
index faf88cb..f81f79e 100644
--- a/drivers/gpu/drm/pl111/pl111_drm.h
+++ b/drivers/gpu/drm/pl111/pl111_drm.h
@@ -19,6 +19,9 @@
#ifndef _PL111_DRM_H_
#define _PL111_DRM_H_
+#include
+#include
+
/* Defines for drm_mode_create_dumb flags settings */
#define PL111_BO_SCANOUT 0x0001 /* scanout compatible buffer requested */
@@ -149,13 +152,17 @@ struct pl111_drm_crtc {
struct drm_framebuffer *fb);
};
+struct pl111_drm_encoder {
+ struct drm_encoder encoder;
+ unsigned int port;
+};
+
struct pl111_drm_connector {
struct drm_connector connector;
+ struct pl111_drm_encoder *encoder;
+ struct media_pad *pad;
};
-struct pl111_drm_encoder {
- struct drm_encoder encoder;
-};
struct pl111_drm_dev_private {
struct pl111_drm_crtc *pl111_crtc;
@@ -186,6 +193,16 @@ struct pl111_drm_dev_private {
/* Cache for flip resources used to avoid kmalloc on each page flip */
struct kmem_cache *page_flip_slab;
+
+ struct drm_device *ddev;
+
+ /*
+*Display entities and notifier
+*/
+ struct media_device mdev;
+ struct display_entity entity;
+ struct display_entity_notifier notifier;
+
};
enum pl111_cursor_size {
diff --git a/drivers/gpu/drm/pl111/pl111_drm_device.c
b/drivers/gpu/drm/pl111/pl111_drm_device.c
index cf22ead..838506f 100644
--- a/drivers/gpu/drm/pl111/pl111_drm_device.c
+++ b/drivers/gpu/drm/pl111/pl111_drm_device.c
@@ -35,6 +35,25 @@
struct pl111_drm_dev_private priv;
+/*
-
+ * Display Entities
+ */
+static int pl111_entity_set_stream(struct display_entity *ent,
+ unsigned int port,
+ enum display_entity_stream_state state)
+{
+ pr_info("DRM %s\n", __func__);
+ return 0;
+}
+
+static const struct display_entity_video_ops pl111_entity_video_ops = {
+ .set_stream = pl111_entity_set_stream,
+};
+
+static const struct display_entity_ops pl111_entity_ops = {
+ .video = &pl111_entity_video_ops,
+};
+
#ifdef CONFIG_DMA_SHARED_BUFFER_USES_KDS
static void initial_kds_obtained(void *cb1, void *cb2)
{
@@ -94,13 +113,217 @@ struct drm_mode_config_funcs mode_config_funcs = {
.fb_create = pl111_fb_create,
};
+struct pl111_drm_encoder *
+pl111_pad_encoder_create(struct pl111_drm_dev_private *priv,
+unsigned int port,
+struct media_pad *pad)
+{
+ struct pl111_drm_encoder *pl111_encoder;
+ struct device *dev = &priv->amba_dev->dev;
+ unsigned int encoder_type;
+ int ret;
+
+ pl111_encoder = devm_kzalloc(dev, sizeof(*pl111_encoder), GFP_KERNEL);
+ if (pl111_encoder == NULL)
+ return ERR_PTR(-ENOMEM);
+
+ pl111_encoder->port = port;
+
+ /* Find the encoder type. */
+ if (pad) {
+ struct display_entity *entity = to_display_entity(pad->entity);
+ struct display_entity_interface_params params;
+
+ ret = display_entity_get_params(entity, pad->index, ¶ms);
+ if (ret < 0) {
+ pr_err("DRM %s: failed to retrieve display entity %s
parameters\n",
+ __func__,
+ entity->name);
+ return ERR_PTR(ret);
+ }
+
+ switch (params.type) {
+ case DISPLAY_ENTITY_INTERFACE_LVDS:
+ encoder_type = DRM_MODE_ENCODER_DAC;
+ break;
+ case DISPLAY_ENTITY_INTERFACE_VGA:
+ encoder_type = DRM_MODE_ENCODER_DAC;
+ break;
+ case DISPLAY_ENTITY_INTERFACE_DPI:
+ case DISPLAY_ENTITY_INTERFACE_DBI:
+ default:
+ encoder_type = DRM_MODE_ENCODER_NONE;
+ break;
+ }
+
+ } else {
+ /* No external encoder, use the internal encoder type. */
+ pr_err("DRM %s: No external encoder, use the internal encoder
type.\n",
+ __func__);
+ encoder_type = DRM_MODE_ENCODER_DAC;
+ }
+
+ pl111_encoder = pl111_encoder_create(priv->ddev, 1);
+
+ return pl111_encoder;
+}
+
+struct pl111_drm_connector *
+pl111_pad_connector_create(struct pl111_drm_dev_private *priv,
+ struct pl111_drm_encoder *pl111_encoder,
+ struct media_pad *pad)
Re: [PATCH RFC] media: rc: OF: Add Generic bindings for remote-control
Em Fri, 27 Sep 2013 14:26:12 +0100
Srinivas KANDAGATLA escreveu:
> On 27/09/13 12:34, Mark Rutland wrote:
>
> >> > +- rx-mode: Can be "infrared" or "uhf". rx-mode should be
> >> > present iff
> >> > + the rx pins are wired up.
> > I'm unsure on this. What if the device has multiple receivers that can
> > be independently configured? What if it supports something other than
> > "infrared" or "uhf"? What if a device can only be wired up as
> > "infrared"?
> >
> > I'm not sure how generic these are, though we should certainly encourage
> > bindings that can be described this way to be described in the same way.
> >
> >> > +- tx-mode: Can be "infrared" or "uhf". tx-mode should be
> >> > present iff
> >> > + the tx pins are wired up.
> > I have similar concerns here to those for the rx-mode property.
> >
> Initially rx-mode and tx-mode sounded like more generic properties
> that's the reason I ended up in this route. But after this discussion it
> looks like its not really generic enough to cater all the use cases.
>
> It make sense for me to perfix "st," for these properties in the st-rc
> driver rather than considering them as generic properties.
Well, for sure the direction (TX, RX, both) is a generic property.
I'd say that the level 1 protocol (IR, UHF, Bluetooth, ...) is also a
generic property. Most remotes are IR, but there are some that are
bluetooth, and your hardware is using UHF.
Btw, we're even thinking on mapping HDMI-CEC remote controller RX/TX via
the RC subsystem. So, another L1 protocol would be "hdmi-cec".
Yet, it seems unlikely that the very same remote controller IP would use
a different protocol for RX and TX, while sharing the same registers.
So, for example, a hardware with "hdmi-cec" and "infrared" will actually
have two remote controller devices. Eventually, the "infrared" being
just RX, while "hdmi-cec" being bi-directional.
So, IMHO, this could be mapped as "l1_protocol" ("infrared", "uhf", ...)
and another one "direction" ("rx", "tx", "bi-directional").
>
> > I think what we actually need to document is the process of creating a
> > binding in such a way as to encourage uniformity. Something like the
> > following steps:
> I agree, It will help.. :-)
> >
> > 1. Look to see if a binding already exists. If so, use it.
> >
> > 2. Is there a binding for a compatible device? If so, use/extend it.
> >
> > 3. Is there a binding for a similar (but incompatible) device? Use it as
> >a template, possibly factor out portions into a class binding if
> >those portions are truly general.
> >
> > 4. Is there a binding for the class of device? If so, build around that,
> >possibly extending it.
> >
> > 5. If there's nothing relevant, create a binding aiming for as much
> >commonality as possible with other devices of that class that may
> >have bindings later.
>
> Thanks for this little guide...
>
> --srini
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] media: rc: OF: Add Generic bindings for remote-control
Em Fri, 27 Sep 2013 12:34:58 +0100 Mark Rutland escreveu: > On Fri, Sep 27, 2013 at 10:33:11AM +0100, Srinivas KANDAGATLA wrote: > > From: Srinivas Kandagatla > > > > This patch attempts to collate generic bindings which can be used by > > the remote control hardwares. Currently the list is not long as there > > are only 2 drivers which are device tree'd. > > > > Mainly this patch tries to document few bindings used by ST IRB driver > > which can be generic as well. This document also add fews common > > bindings used by most of the drivers like, interrupts, regs, clocks and > > pinctrls. > > > > This document can also be holding place to describe generic bindings > > used in remote controls devices. > > > > Signed-off-by: Srinivas Kandagatla > > --- > > Hi All, > > Following Stephen Warren's suggestions at > > https://lkml.org/lkml/2013/9/24/452 > > this patch is an attempt to document such generic bindings in a common > > document. > > > > This document currently collates all the generic bindings used with > > remote-controls and act as holding place to describe generic bindings for > > remote controls. > > > > Comments? > > > > Thanks, > > srini > > > > .../devicetree/bindings/media/remote-control.txt | 31 > > > > 1 files changed, 31 insertions(+), 0 deletions(-) > > create mode 100644 > > Documentation/devicetree/bindings/media/remote-control.txt > > > > diff --git a/Documentation/devicetree/bindings/media/remote-control.txt > > b/Documentation/devicetree/bindings/media/remote-control.txt > > new file mode 100644 > > index 000..901ea56 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/media/remote-control.txt > > @@ -0,0 +1,31 @@ > > +Generic device tree bindings for remote control. > > + > > +properties: > > + - compatible: Can contain any remote control driver compatible string. > > + example: "st-comms-irb, "gpio-ir-receiver". > > This is more generic than remote control, could this not just be left > for the specific binding to describe? > > > + - reg: Base physical address of the controller and length of memory > > + mapped region. > > What if it's on a bus that isn't memory mapped (e.g. i2c, SPI)? > > > + - interrupts: Interrupt-specifier for the sole interrupt generated by > > + the device. The interrupt specifier format depends on the > > + interrupt controller parent. Iff the device supports interrupts. > > What if it has multiple interrupts, and has interrupts-names? > > It might be better to only describe the properties that relate > specifically to remote controls, rather than listing all of the generic > properties that device tree bidnings may have. That would match the > style of the clock bindings. > > > + - rx-mode: Can be "infrared" or "uhf". rx-mode should be present iff > > + the rx pins are wired up. > > I'm unsure on this. What if the device has multiple receivers that can > be independently configured? Well, if a given remote controller hardware has more than one independent receiver (or transmitter), each one should have its own devnode. Likely, two entries at DT. > What if it supports something other than > "infrared" or "uhf"? What if a device can only be wired up as > "infrared"? I would say that a hardware that has both infrared and uhf has actually two different devices. So, it should be mapped as two separate devnodes. > I'm not sure how generic these are, though we should certainly encourage > bindings that can be described this way to be described in the same way. > > > + - tx-mode: Can be "infrared" or "uhf". tx-mode should be present iff > > + the tx pins are wired up. > > I have similar concerns here to those for the rx-mode property. > > > + > > +Optional properties: > > + - linux,rc-map-name: Linux specific remote control map name. Refer to > > + include/media/rc-map.h for full list of maps. > > We shouldn't refer to Linux specifics (i.e. headers) in general in > bindings. While it's possible to relax that a bit for linux,* > properties, I'd prefer to explicitly list elements in the binding. That > prevents the ABI from changing under our feet by someone altering what > looks like a completely internal header file. Well, the remote controller keymaps at include/media/rc-map.h is just a bunch of string names, defined as macro to avoid duplicating those names everywhere, to avoid typos and to help some userspace parsing logic to get all in just one single place. I don't see why the same names couldn't be used on any other OS using DT. The logic behind include/media/rc-map.h, is that those names are used by: 1) kernelspace: in order to locate a keytable with the same name, that would be loaded when the device is initialized; 2) userspace: to seek for a keytable with that name, allowing to dynamically load the keymap table on userspace, instead of hardwiring them on Kernelspace (or replacing the kernel's one by an user-customized one). So, I woul
Re: [PATCH RFC] media: rc: OF: Add Generic bindings for remote-control
On 27/09/13 12:34, Mark Rutland wrote: >> > + - rx-mode: Can be "infrared" or "uhf". rx-mode should be present iff >> > +the rx pins are wired up. > I'm unsure on this. What if the device has multiple receivers that can > be independently configured? What if it supports something other than > "infrared" or "uhf"? What if a device can only be wired up as > "infrared"? > > I'm not sure how generic these are, though we should certainly encourage > bindings that can be described this way to be described in the same way. > >> > + - tx-mode: Can be "infrared" or "uhf". tx-mode should be present iff >> > +the tx pins are wired up. > I have similar concerns here to those for the rx-mode property. > Initially rx-mode and tx-mode sounded like more generic properties that's the reason I ended up in this route. But after this discussion it looks like its not really generic enough to cater all the use cases. It make sense for me to perfix "st," for these properties in the st-rc driver rather than considering them as generic properties. > I think what we actually need to document is the process of creating a > binding in such a way as to encourage uniformity. Something like the > following steps: I agree, It will help.. :-) > > 1. Look to see if a binding already exists. If so, use it. > > 2. Is there a binding for a compatible device? If so, use/extend it. > > 3. Is there a binding for a similar (but incompatible) device? Use it as >a template, possibly factor out portions into a class binding if >those portions are truly general. > > 4. Is there a binding for the class of device? If so, build around that, >possibly extending it. > > 5. If there's nothing relevant, create a binding aiming for as much >commonality as possible with other devices of that class that may >have bindings later. Thanks for this little guide... --srini -- 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: Capture driver implementation issue/questions
On Thu, 2013-09-26 at 14:57 +, Rick Ball wrote: > Hi All, > > I'm working on a video capture driver (my first) for a custom board, > and I have a few questions about handling 'overflow' conditions (when > the application doesn't get back in time to de-queue every frame). I > know that one way to avoid this is to allocate additional frame > buffers, but I'm thinking about conditions where even this doesn't > provide enough of a FIFO. It looks to me (from studying the videobuf2 > code), that if the buffers all fill up (they all end up on the 'done' > list), and then the application 'comes back' and starts de-queuing > buffers, it will get the OLDEST one first, and then, the newer buffers > will be returned, in the order they were originally captured. For some > (most?) applications, this is probably what is best, as frames only > get dropped when they have to, i.e., when the FIFO overflows, and the > app sees the maximum number of frames. But what about applications > that always want to see the 'newest' buffer, even if some frames are > dropped? > > What I would like to do is write my driver such that if a new frame is > captured before the app has de-queued an earlier frame, the older > capture buffer would be removed from the done list and re-queued to > the h/w (it's already still on the queued list, I think). The done > list would then always contain only 1 frame, and it would be the > newest frame captured (and the capture hardware would never run out of > capture buffers to use). I think this would be OK as far as the API is > concerned - the app shouldn't expect that the buffers will necessarily > be returned in the order they were queued, right? Hi Rick, > So here are the questions: > > 1. Does this make sense, or am I wanting to do something that isn't > reasonable (or do I not understand the framework)? In my opinion, if a driver has to drop data, it should prefer to drop the oldest data. Although for TV program video/audio, it doesn't really matter. Both the ivtv driver and cx18 driver, under certain circumstances, recover internal buffers that userspace has delayed too long in reading. ivtv_queue_move(), for example, has a "steal" argument to sometimes steals from the end of internal queues. cx18_stream_rotate_idx_mdls() steals from the head of its particular buffer queue. Both of these drivers use their own internal queueing mechanism though, so they don't help with understanding videobuf. I do not think having a queue with only 1 frame in it makes sense. I'm not quite sure what you're aiming to do with that. You might end up inadventantly forcing synchronization of userspace to the driver (via a spinlock or mutex), which could be a problem with live playback. If userspace can't keep up reading buffers, you should try and examine your system and figure out why. > 2. Is there any way to do this within the current videobuf2 framework? > 3. If not, do you have any suggestions on changes to make this > possible? I'm thinking that we would need a new function that would be > called (probably from an ISR, just before calling vb2_buffer_done on > the new buffer) An ISR? From an interrupt generated by what exactly? This doesn't sound like a good idea to me. Buffer manipulations shouldn't be handled from an hard IRQ (atomic) context anyway. Do this in the work handler, threaded irq handler, or kthread, that normally handles buffer handoffs to and from the hardware. The only time you need to steal buffers is when the hardware dma engine is starved of buffers (for incoming data) or you have no buffers for feeding thw hardware (to send data out). > that would remove the older buffer from the done queue, re-increment > the 'queued_count', and call the 'buf_queue' function provided by the > driver to re-queue the older buffer to the h/w. Am I missing anything? I don't know much about videobuf[2], so I can't help with that. Regards, Andy > Thanks, > > Rick -- 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 RFC] media: rc: OF: Add Generic bindings for remote-control
On Fri, Sep 27, 2013 at 10:33:11AM +0100, Srinivas KANDAGATLA wrote: > From: Srinivas Kandagatla > > This patch attempts to collate generic bindings which can be used by > the remote control hardwares. Currently the list is not long as there > are only 2 drivers which are device tree'd. > > Mainly this patch tries to document few bindings used by ST IRB driver > which can be generic as well. This document also add fews common > bindings used by most of the drivers like, interrupts, regs, clocks and > pinctrls. > > This document can also be holding place to describe generic bindings > used in remote controls devices. > > Signed-off-by: Srinivas Kandagatla > --- > Hi All, > Following Stephen Warren's suggestions at https://lkml.org/lkml/2013/9/24/452 > this patch is an attempt to document such generic bindings in a common > document. > > This document currently collates all the generic bindings used with > remote-controls and act as holding place to describe generic bindings for > remote controls. > > Comments? > > Thanks, > srini > > .../devicetree/bindings/media/remote-control.txt | 31 > > 1 files changed, 31 insertions(+), 0 deletions(-) > create mode 100644 Documentation/devicetree/bindings/media/remote-control.txt > > diff --git a/Documentation/devicetree/bindings/media/remote-control.txt > b/Documentation/devicetree/bindings/media/remote-control.txt > new file mode 100644 > index 000..901ea56 > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/remote-control.txt > @@ -0,0 +1,31 @@ > +Generic device tree bindings for remote control. > + > +properties: > + - compatible: Can contain any remote control driver compatible string. > + example: "st-comms-irb, "gpio-ir-receiver". This is more generic than remote control, could this not just be left for the specific binding to describe? > + - reg: Base physical address of the controller and length of memory > + mapped region. What if it's on a bus that isn't memory mapped (e.g. i2c, SPI)? > + - interrupts: Interrupt-specifier for the sole interrupt generated by > + the device. The interrupt specifier format depends on the > + interrupt controller parent. Iff the device supports interrupts. What if it has multiple interrupts, and has interrupts-names? It might be better to only describe the properties that relate specifically to remote controls, rather than listing all of the generic properties that device tree bidnings may have. That would match the style of the clock bindings. > + - rx-mode: Can be "infrared" or "uhf". rx-mode should be present iff > + the rx pins are wired up. I'm unsure on this. What if the device has multiple receivers that can be independently configured? What if it supports something other than "infrared" or "uhf"? What if a device can only be wired up as "infrared"? I'm not sure how generic these are, though we should certainly encourage bindings that can be described this way to be described in the same way. > + - tx-mode: Can be "infrared" or "uhf". tx-mode should be present iff > + the tx pins are wired up. I have similar concerns here to those for the rx-mode property. > + > +Optional properties: > + - linux,rc-map-name: Linux specific remote control map name. Refer to > + include/media/rc-map.h for full list of maps. We shouldn't refer to Linux specifics (i.e. headers) in general in bindings. While it's possible to relax that a bit for linux,* properties, I'd prefer to explicitly list elements in the binding. That prevents the ABI from changing under our feet by someone altering what looks like a completely internal header file. > + - pinctrl-names, pinctrl-0: The pincontrol settings to configure muxing > + properly for the device pins. > + - clocks : phandle with clock-specifier pair for the device specified > + in compatible. While devices may have these, they're also more general than remote control devices. I'm not sure that they need to be listed here when they need to be described fully in any binding that needs them anyway, especially as this gives an impression that they are valid for bindings that don't need them. I think what we actually need to document is the process of creating a binding in such a way as to encourage uniformity. Something like the following steps: 1. Look to see if a binding already exists. If so, use it. 2. Is there a binding for a compatible device? If so, use/extend it. 3. Is there a binding for a similar (but incompatible) device? Use it as a template, possibly factor out portions into a class binding if those portions are truly general. 4. Is there a binding for the class of device? If so, build around that, possibly extending it. 5. If there's nothing relevant, create a binding aiming for as much commonality as possible with other devices of that class that may have bindings later. Cheers, Mark. > + > +example: > + > +
Re: Need help with AverMedia306 driver on linux system.
Oh, I am not the person who wrote the driver ... :( I merly cloned the HC81r, gave it the proper PCI ID, and the correct firmware , I also have no DVB either, Unless I get time to learn V4L API, or the mainter of the "xc2028" finds more infos too ... we are prety much at this stage, some analog, but no dvb ... at my knowlodge . Best regards Rémi > Le 27 septembre 2013 à 12:46, Nguyễn Minh Hoàng a >écrit : > > > Thank you for your relying. I know that your patch is not same my revision, i >can't apply it. I think i should find and add your patches manually, but there >are so much code to do. I am on phone now. I will send you some more detail >when i am back to my computer. Pls help me. > Ps: i used "option=39" before, my system got it as video and vbi device, not >dvb device. Maybe i need some patches in this case as your suggestion today. > Thank you again! > > Sent from my iPhone > > > On Sep 27, 2013, at 3:24 PM, remi wrote: > > > > :) > > > > Also, > > > > > > by the time I redo the patch, > > > > > > You must have seen how i have reached this point, > > > > I have actually started by insering the module with card=39 as an option, > > > > > > So you can for now, add theses line to > > > > gpunk@gpunk-Aspire-8930:~$cat /etc/modprobe.d/video-tv.conf > > > > > > options tuner-xc2028 firmware_name=xc3028-v27.fw > > options cx23885 card=39 > > > > > > I called my file this way ... it's arbitrary, please check the man modprobe >of > > your ditribution/kernel . > > > > > > Best regards > > > > Rémi > > > > > > > >> Le 21 septembre 2013 à 19:43, "ad...@tydaikho.com" > a écrit : > >> > >> > >> Hi Remi! > >> I got my card but i have not finish to install driver. I follow your >patch on linuxtv.org but i am not successful. it makes some mistake: "malform" >and "hunk" errors. > >> === > >> root@ty-debian:/usr/local/src/linuxtv# patch -p1 < ./cx23885.patch > >> can't find file to patch at input line 3 > >> Perhaps you used the wrong -p or --strip option? > >> The text leading up to this was: > >> -- > >> |--- drivers/media/pci/cx23885/cx23885.h 2013-03-25 05:45:50.0 >+0100 > >> |+++ drivers/media/pci/cx23885/cx23885.h 2013-08-21 >13:55:20.010625134 +0200 > >> -- > >> File to patch: ./drivers/media/pci/cx23885/cx23885.h > > >> patching file ./drivers/media/pci/cx23885/cx23885.h > >> patch: malformed patch at line 4: #define CX23885_BOARD_PROF_8000 > 37 > >> == > >> root@ty-debian:/usr/local/src/linuxtv# patch -p1 < ./cx23885-video.patch > >> can't find file to patch at input line 4 > >> Perhaps you used the wrong -p or --strip option? > >> The text leading up to this was: > >> -- > >> |--- drivers/media/pci/cx23885/cx23885-video.c 2013-08-02 >05:45:59.0 +0200 > >> |+++ drivers/media/pci/cx23885/cx23885-video.c2013-08-21 >13:55:20.017625046 > >> |+0200 > >> -- > >> File to patch: ./drivers/media/pci/cx23885/cx23885-video.c > >> patching file ./drivers/media/pci/cx23885/cx23885-video.c > >> Hunk #1 FAILED at 511. > >> Hunk #2 FAILED at 1888. > >> 2 out of 2 hunks FAILED -- saving rejects to file >./drivers/media/pci/cx23885/cx23885-video.c.rej > >> > >> root@ty-debian:/usr/local/src/linuxtv# patch -p1 < ./cx23885-cards.patch > >> can't find file to patch at input line 4 > >> Perhaps you used the wrong -p or --strip option? > >> The text leading up to this was: > >> -- > >> |--- drivers/media/pci/cx23885/cx23885-cards.c 2012-12-28 >00:04:05.0 +0100 > >> |+++ drivers/media/pci/cx23885/cx23885-cards.c2013-08-21 >14:15:54.173195979 > >> |+0200 > >> -- > >> File to patch: ./drivers/media/pci/cx23885/cx23885-cards.c > >> patching file ./drivers/media/pci/cx23885/cx23885-cards.c > >> Hunk #1 FAILED at 604. > >> Hunk #2 FAILED at 841. > >> Hunk #3 FAILED at 1069. > >> Hunk #4 FAILED at 1394. > >> Hunk #5 FAILED at 1623. > >> Hunk #6 FAILED at 1758. > >> 6 out of 6 hunks FAILED -- saving rejects to file >./drivers/media/pci/cx23885/cx23885-cards.c.rej > >> === > >> > >> If you don't mind, i need your support to get my card works well. Thank >you very much! > >> > >> > >> -- > >> Yahoo: minhhoang1004 + Google: minhhoang1004 + Skype: minhhoang1004 + >MSN: tydaikho > >> -- > >> > >> (http://tydaikho.com) VS (http://vnluser.net) -- 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 v9 01/13] [media] exynos5-is: Adding media device driver for exynos5
From: Shaik Ameer Basha
This patch adds support for media device for EXYNOS5 SoCs.
The current media device supports the following ips to connect
through the media controller framework.
* MIPI-CSIS
Support interconnection(subdev interface) between devices
* FIMC-LITE
Support capture interface from device(Sensor, MIPI-CSIS) to memory
Support interconnection(subdev interface) between devices
* FIMC-IS
Camera post-processing IP having multiple sub-nodes.
G-Scaler will be added later to the current media device.
The media device creates two kinds of pipelines for connecting
the above mentioned IPs.
The pipeline0 is uses Sensor, MIPI-CSIS and FIMC-LITE which captures
image data and dumps to memory.
Pipeline1 uses FIMC-IS components for doing post-processing
operations on the captured image and give scaled YUV output.
Pipeline0
++ +---+ +---+ ++
| Sensor | --> | MIPI-CSIS | --> | FIMC-LITE | --> | Memory |
++ +---+ +---+ ++
Pipeline1
++ ++ +---+ +---+
| Memory | --> | ISP | --> |SCC| --> |SCP|
++ ++ +---+ +---+
Signed-off-by: Shaik Ameer Basha
Signed-off-by: Arun Kumar K
---
.../bindings/media/exynos5250-camera.txt | 126 ++
drivers/media/platform/exynos5-is/exynos5-mdev.c | 1211
drivers/media/platform/exynos5-is/exynos5-mdev.h | 126 ++
3 files changed, 1463 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/exynos5250-camera.txt
create mode 100644 drivers/media/platform/exynos5-is/exynos5-mdev.c
create mode 100644 drivers/media/platform/exynos5-is/exynos5-mdev.h
diff --git a/Documentation/devicetree/bindings/media/exynos5250-camera.txt
b/Documentation/devicetree/bindings/media/exynos5250-camera.txt
new file mode 100644
index 000..09420ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/exynos5250-camera.txt
@@ -0,0 +1,126 @@
+Samsung EXYNOS5 SoC Camera Subsystem
+
+
+The Exynos5 SoC Camera subsystem comprises of multiple sub-devices
+represented by separate device tree nodes. Currently this includes: FIMC-LITE,
+MIPI CSIS and FIMC-IS.
+
+The sub-device nodes are referenced using phandles in the common 'camera' node
+which also includes common properties of the whole subsystem not really
+specific to any single sub-device, like common camera port pins or the common
+camera bus clocks.
+
+Common 'camera' node
+
+
+Required properties:
+
+- compatible : must be "samsung,exynos5250-fimc"
+- clocks : list of clock specifiers, corresponding to entries in
+ the clock-names property
+- clock-names : must contain "sclk_bayer" entry
+- samsung,csis : list of phandles to the mipi-csis device nodes
+- samsung,fimc-lite: list of phandles to the fimc-lite device nodes
+- samsung,fimc-is : phandle to the fimc-is device node
+
+The pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt must be used
+to define a required pinctrl state named "default".
+
+'parallel-ports' node
+-
+
+This node should contain child 'port' nodes specifying active parallel video
+input ports. It includes camera A, camera B and RGB bay inputs.
+'reg' property in the port nodes specifies the input type:
+ 1 - parallel camport A
+ 2 - parallel camport B
+ 5 - RGB camera bay
+
+3, 4 are for MIPI CSI-2 bus and are already described in samsung-mipi-csis.txt
+
+Image sensor nodes
+--
+
+The sensor device nodes should be added to their control bus controller (e.g.
+I2C0) nodes and linked to a port node in the csis or the parallel-ports node,
+using the common video interfaces bindings, defined in video-interfaces.txt.
+
+Example:
+
+ aliases {
+ fimc-lite0 = &fimc_lite_0
+ };
+
+ /* Parallel bus IF sensor */
+ i2c_0: i2c@1386 {
+ s5k6aa: sensor@3c {
+ compatible = "samsung,s5k6aafx";
+ reg = <0x3c>;
+ vddio-supply = <...>;
+
+ clock-frequency = <2400>;
+ clocks = <...>;
+ clock-names = "mclk";
+
+ port {
+ s5k6aa_ep: endpoint {
+ remote-endpoint = <&fimc0_ep>;
+ bus-width = <8>;
+ hsync-active = <0>;
+ vsync-active = <1>;
+ pclk-sample = <1>;
+ };
+ };
+ };
+ };
+
+ /* MIPI CSI-2 bus IF sensor */
+ s5c73m3: sensor@1a {
+ compatible = "samsung,s5c73m3";
+
[PATCH v9 00/13] Exynos5 IS driver
The patch series add support for Exynos5 camera subsystem. It re-uses mipi-csis and fimc-lite from exynos4-is and adds a new media device and fimc-is device drivers for exynos5. Changes from v8 --- - Moved i2c-isp device nodes into the fimc-is node as suggested by Sylwester - Addressed comments given by Sylwester and Philipp Zabel Changes from v7 --- - Addressed few DT related review comments from Sylwester http://www.mail-archive.com/linux-media@vger.kernel.org/msg66403.html - Few fixes added after some regression testing Changes from v6 --- - Addressed DT binding doc review comments from Sylwester http://www.mail-archive.com/linux-media@vger.kernel.org/msg65771.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg65772.html Changes from v5 --- - Addressed review comments from Sylwester http://www.mail-archive.com/linux-media@vger.kernel.org/msg65578.html http://www.mail-archive.com/linux-media@vger.kernel.org/msg65605.html Changes from v4 --- - Addressed all review comments from Sylwester - Added separate PMU node as suggested by Stephen Warren - Added phandle based discovery of subdevs instead of node name Changes from v3 --- - Dropped the RFC tag - Addressed all review comments from Sylwester and Sachin - Removed clock provider for media dev - Added s5k4e5 sensor devicetree binding doc Changes from v2 --- - Added exynos5 media device driver from Shaik to this series - Added ISP pipeline support in media device driver - Based on Sylwester's latest exynos4-is development - Asynchronos registration of sensor subdevs - Made independent IS-sensor support - Add s5k4e5 sensor driver - Addressed review comments from Sylwester, Hans, Andrzej, Sachin Changes from v1 --- - Addressed all review comments from Sylwester - Made sensor subdevs as independent i2c devices - Lots of cleanup - Debugfs support added - Removed PMU global register access Arun Kumar K (12): [media] exynos5-fimc-is: Add Exynos5 FIMC-IS device tree bindings documentation [media] exynos5-fimc-is: Add driver core files [media] exynos5-fimc-is: Add common driver header files [media] exynos5-fimc-is: Add register definition and context header [media] exynos5-fimc-is: Add isp subdev [media] exynos5-fimc-is: Add scaler subdev [media] exynos5-fimc-is: Add sensor interface [media] exynos5-fimc-is: Add the hardware pipeline control [media] exynos5-fimc-is: Add the hardware interface module [media] exynos5-is: Add Kconfig and Makefile V4L: s5k6a3: Change sensor min/max resolutions V4L: Add driver for s5k4e5 image sensor Shaik Ameer Basha (1): [media] exynos5-is: Adding media device driver for exynos5 .../devicetree/bindings/media/exynos5-fimc-is.txt | 84 + .../bindings/media/exynos5250-camera.txt | 126 ++ .../devicetree/bindings/media/i2c/s5k4e5.txt | 45 + drivers/media/i2c/Kconfig |8 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/s5k4e5.c | 347 drivers/media/i2c/s5k6a3.c | 10 +- drivers/media/platform/Kconfig |1 + drivers/media/platform/Makefile|1 + drivers/media/platform/exynos5-is/Kconfig | 20 + drivers/media/platform/exynos5-is/Makefile |7 + drivers/media/platform/exynos5-is/exynos5-mdev.c | 1211 ++ drivers/media/platform/exynos5-is/exynos5-mdev.h | 126 ++ drivers/media/platform/exynos5-is/fimc-is-cmd.h| 187 +++ drivers/media/platform/exynos5-is/fimc-is-core.c | 410 + drivers/media/platform/exynos5-is/fimc-is-core.h | 132 ++ drivers/media/platform/exynos5-is/fimc-is-err.h| 257 +++ .../media/platform/exynos5-is/fimc-is-interface.c | 810 ++ .../media/platform/exynos5-is/fimc-is-interface.h | 124 ++ drivers/media/platform/exynos5-is/fimc-is-isp.c| 534 ++ drivers/media/platform/exynos5-is/fimc-is-isp.h| 90 ++ .../media/platform/exynos5-is/fimc-is-metadata.h | 767 + drivers/media/platform/exynos5-is/fimc-is-param.h | 1159 + .../media/platform/exynos5-is/fimc-is-pipeline.c | 1708 .../media/platform/exynos5-is/fimc-is-pipeline.h | 129 ++ drivers/media/platform/exynos5-is/fimc-is-regs.h | 105 ++ drivers/media/platform/exynos5-is/fimc-is-scaler.c | 476 ++ drivers/media/platform/exynos5-is/fimc-is-scaler.h | 106 ++ drivers/media/platform/exynos5-is/fimc-is-sensor.c | 45 + drivers/media/platform/exynos5-is/fimc-is-sensor.h | 65 + drivers/media/platform/exynos5-is/fimc-is.h| 160 ++ 31 files changed, 9247 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/exynos5-fimc-is.txt create mode 100644 Documentation/devicetree/bindings/media/exynos5250-camera.txt create mode 100644 Documentation/devicetree/bindi
[PATCH v9 07/13] [media] exynos5-fimc-is: Add scaler subdev
FIMC-IS has two hardware scalers named as scaler-codec and
scaler-preview. This patch adds the common code handling the
video nodes and subdevs of both the scalers.
Signed-off-by: Arun Kumar K
Signed-off-by: Kilyeon Im
Reviewed-by: Sylwester Nawrocki
---
drivers/media/platform/exynos5-is/fimc-is-scaler.c | 476
drivers/media/platform/exynos5-is/fimc-is-scaler.h | 106 +
2 files changed, 582 insertions(+)
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-scaler.c
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-scaler.h
diff --git a/drivers/media/platform/exynos5-is/fimc-is-scaler.c
b/drivers/media/platform/exynos5-is/fimc-is-scaler.c
new file mode 100644
index 000..029eb8b
--- /dev/null
+++ b/drivers/media/platform/exynos5-is/fimc-is-scaler.c
@@ -0,0 +1,476 @@
+/*
+ * Samsung EXYNOS5250 FIMC-IS (Imaging Subsystem) driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Arun Kumar K
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+
+#include "fimc-is.h"
+
+#define IS_SCALER_DRV_NAME "fimc-is-scaler"
+
+static const struct fimc_is_fmt formats[] = {
+ {
+ .name = "YUV 4:2:0 3p MultiPlanar",
+ .fourcc = V4L2_PIX_FMT_YUV420M,
+ .depth = {8, 2, 2},
+ .num_planes = 3,
+ },
+ {
+ .name = "YUV 4:2:0 2p MultiPlanar",
+ .fourcc = V4L2_PIX_FMT_NV12M,
+ .depth = {8, 4},
+ .num_planes = 2,
+ },
+ {
+ .name = "YUV 4:2:2 1p MultiPlanar",
+ .fourcc = V4L2_PIX_FMT_NV16,
+ .depth = {16},
+ .num_planes = 1,
+ },
+};
+#define NUM_FORMATS ARRAY_SIZE(formats)
+
+static const struct fimc_is_fmt *find_format(struct v4l2_format *f)
+{
+ unsigned int i;
+
+ for (i = 0; i < NUM_FORMATS; i++) {
+ if (formats[i].fourcc == f->fmt.pix_mp.pixelformat)
+ return &formats[i];
+ }
+ return NULL;
+}
+
+static int scaler_video_capture_start_streaming(struct vb2_queue *vq,
+ unsigned int count)
+{
+ struct fimc_is_scaler *ctx = vb2_get_drv_priv(vq);
+ int ret;
+
+ ret = fimc_is_pipeline_scaler_start(ctx->pipeline,
+ ctx->scaler_id,
+ vq->num_buffers,
+ ctx->fmt->num_planes);
+ if (ret) {
+ v4l2_err(&ctx->subdev, "Scaler start failed.\n");
+ return -EINVAL;
+ }
+
+ set_bit(STATE_RUNNING, &ctx->capture_state);
+ return 0;
+}
+
+static int scaler_video_capture_stop_streaming(struct vb2_queue *vq)
+{
+ struct fimc_is_scaler *ctx = vb2_get_drv_priv(vq);
+ struct fimc_is_buf *buf;
+ int ret;
+
+ ret = fimc_is_pipeline_scaler_stop(ctx->pipeline, ctx->scaler_id);
+ if (ret)
+ v4l2_info(&ctx->subdev, "Scaler already stopped.\n");
+
+ /* Release un-used buffers */
+ while (!list_empty(&ctx->wait_queue)) {
+ buf = fimc_is_scaler_wait_queue_get(ctx);
+ vb2_buffer_done(&buf->vb, VB2_BUF_STATE_ERROR);
+ }
+ while (!list_empty(&ctx->run_queue)) {
+ buf = fimc_is_scaler_run_queue_get(ctx);
+ vb2_buffer_done(&buf->vb, VB2_BUF_STATE_ERROR);
+ }
+
+ clear_bit(STATE_RUNNING, &ctx->capture_state);
+ return 0;
+}
+
+static int scaler_video_capture_queue_setup(struct vb2_queue *vq,
+ const struct v4l2_format *pfmt,
+ unsigned int *num_buffers, unsigned int *num_planes,
+ unsigned int sizes[], void *allocators[])
+{
+ struct fimc_is_scaler *ctx = vb2_get_drv_priv(vq);
+ const struct fimc_is_fmt *fmt = ctx->fmt;
+ unsigned int wh;
+ int i;
+
+ if (!fmt)
+ return -EINVAL;
+
+ *num_planes = fmt->num_planes;
+ wh = ctx->width * ctx->height;
+
+ for (i = 0; i < *num_planes; i++) {
+ allocators[i] = ctx->alloc_ctx;
+ sizes[i] = (wh * fmt->depth[i]) / 8;
+ }
+ return 0;
+}
+
+static int scaler_video_capture_buffer_init(struct vb2_buffer *vb)
+{
+ struct vb2_queue *vq = vb->vb2_queue;
+ struct fimc_is_scaler *ctx = vb2_get_drv_priv(vq);
+ struct fimc_is_buf *buf = container_of(vb, struct fimc_is_buf, vb);
+ const struct fimc_is_fmt *fmt;
+ int i;
+
+ fmt = ctx->fmt;
+ for (i = 0; i < fmt->num_planes; i++)
+ buf->paddr[i] = vb2_dma_contig_plane_dma_addr(vb, i);
+
+ return 0;
+}
+
+static int scaler_video_capture_buffer_prepare(struct vb2_buffer
[PATCH v9 11/13] [media] exynos5-is: Add Kconfig and Makefile
Adds Kconfig and Makefile for exynos5-is driver files. Signed-off-by: Shaik Ameer Basha Signed-off-by: Arun Kumar K Reviewed-by: Sylwester Nawrocki --- drivers/media/platform/Kconfig |1 + drivers/media/platform/Makefile|1 + drivers/media/platform/exynos5-is/Kconfig | 20 drivers/media/platform/exynos5-is/Makefile |7 +++ 4 files changed, 29 insertions(+) create mode 100644 drivers/media/platform/exynos5-is/Kconfig create mode 100644 drivers/media/platform/exynos5-is/Makefile diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 08de865..4b0475e 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -123,6 +123,7 @@ config VIDEO_S3C_CAMIF source "drivers/media/platform/soc_camera/Kconfig" source "drivers/media/platform/exynos4-is/Kconfig" +source "drivers/media/platform/exynos5-is/Kconfig" source "drivers/media/platform/s5p-tv/Kconfig" endif # V4L_PLATFORM_DRIVERS diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index eee28dd..40bf09f 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -37,6 +37,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV)+= s5p-tv/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D)+= s5p-g2d/ obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += exynos-gsc/ +obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS5_CAMERA) += exynos5-is/ obj-$(CONFIG_BLACKFIN) += blackfin/ diff --git a/drivers/media/platform/exynos5-is/Kconfig b/drivers/media/platform/exynos5-is/Kconfig new file mode 100644 index 000..b67d11a --- /dev/null +++ b/drivers/media/platform/exynos5-is/Kconfig @@ -0,0 +1,20 @@ +config VIDEO_SAMSUNG_EXYNOS5_CAMERA + bool "Samsung Exynos5 SoC Camera Media Device driver" + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && PM_RUNTIME + depends on VIDEO_SAMSUNG_EXYNOS4_IS + help + This is a V4L2 media device driver for Exynos5 SoC series + camera subsystem. + +if VIDEO_SAMSUNG_EXYNOS5_CAMERA + +config VIDEO_SAMSUNG_EXYNOS5_FIMC_IS + tristate "Samsung Exynos5 SoC FIMC-IS driver" + depends on I2C && OF + depends on VIDEO_EXYNOS4_FIMC_IS + select VIDEOBUF2_DMA_CONTIG + help + This is a V4L2 driver for Samsung Exynos5 SoC series Imaging + Subsystem known as FIMC-IS. + +endif #VIDEO_SAMSUNG_EXYNOS5_MDEV diff --git a/drivers/media/platform/exynos5-is/Makefile b/drivers/media/platform/exynos5-is/Makefile new file mode 100644 index 000..6cdb037 --- /dev/null +++ b/drivers/media/platform/exynos5-is/Makefile @@ -0,0 +1,7 @@ +ccflags-y += -Idrivers/media/platform/exynos4-is +exynos5-fimc-is-objs := fimc-is-core.o fimc-is-isp.o fimc-is-scaler.o +exynos5-fimc-is-objs += fimc-is-pipeline.o fimc-is-interface.o fimc-is-sensor.o +exynos-mdevice-objs := exynos5-mdev.o + +obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS5_FIMC_IS) += exynos5-fimc-is.o +obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS5_CAMERA) += exynos-mdevice.o -- 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 v9 05/13] [media] exynos5-fimc-is: Add register definition and context header
This patch adds the register definition file for the fimc-is driver and also the header file containing the main context for the driver. Signed-off-by: Arun Kumar K Signed-off-by: Kilyeon Im Reviewed-by: Sylwester Nawrocki --- drivers/media/platform/exynos5-is/fimc-is-regs.h | 105 ++ drivers/media/platform/exynos5-is/fimc-is.h | 160 ++ 2 files changed, 265 insertions(+) create mode 100644 drivers/media/platform/exynos5-is/fimc-is-regs.h create mode 100644 drivers/media/platform/exynos5-is/fimc-is.h diff --git a/drivers/media/platform/exynos5-is/fimc-is-regs.h b/drivers/media/platform/exynos5-is/fimc-is-regs.h new file mode 100644 index 000..06aa466 --- /dev/null +++ b/drivers/media/platform/exynos5-is/fimc-is-regs.h @@ -0,0 +1,105 @@ +/* + * Samsung Exynos5 SoC series FIMC-IS driver + * + * Copyright (c) 2013 Samsung Electronics Co., Ltd + * Arun Kumar K + * Kil-yeon Lim + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef FIMC_IS_REGS_H +#define FIMC_IS_REGS_H + +/* WDT_ISP register */ +#define WDT0x0017 +/* MCUCTL register */ +#define MCUCTL 0x0018 +/* MCU Controller Register */ +#define MCUCTLR(MCUCTL+0x00) +#define MCUCTLR_AXI_ISPX_AWCACHE(x)((x) << 16) +#define MCUCTLR_AXI_ISPX_ARCACHE(x)((x) << 12) +#define MCUCTLR_MSWRST (1 << 0) +/* Boot Base OFfset Address Register */ +#define BBOAR (MCUCTL+0x04) +#define BBOAR_BBOA(x) ((x) << 0) + +/* Interrupt Generation Register 0 from Host CPU to VIC */ +#define INTGR0 (MCUCTL+0x08) +#define INTGR0_INTGC(n)(1 << ((n) + 16)) +#define INTGR0_INTGD(n)(1 << (n)) + +/* Interrupt Clear Register 0 from Host CPU to VIC */ +#define INTCR0 (MCUCTL+0x0c) +#define INTCR0_INTCC(n)(1 << ((n) + 16)) +#define INTCR0_INTCD(n)(1 << (n)) + +/* Interrupt Mask Register 0 from Host CPU to VIC */ +#define INTMR0 (MCUCTL+0x10) +#define INTMR0_INTMC(n)(1 << ((n) + 16)) +#define INTMR0_INTMD(n)(1 << (n)) + +/* Interrupt Status Register 0 from Host CPU to VIC */ +#define INTSR0 (MCUCTL+0x14) +#define INTSR0_GET_INTSD(n, x) (((x) >> (n)) & 0x1) +#define INTSR0_GET_INTSC(n, x) (((x) >> ((n) + 16)) & 0x1) + +/* Interrupt Mask Status Register 0 from Host CPU to VIC */ +#define INTMSR0(MCUCTL+0x18) +#define INTMSR0_GET_INTMSD(n, x) (((x) >> (n)) & 0x1) +#define INTMSR0_GET_INTMSC(n, x) (((x) >> ((n) + 16)) & 0x1) + +/* Interrupt Generation Register 1 from ISP CPU to Host IC */ +#define INTGR1 (MCUCTL+0x1c) +#define INTGR1_INTGC(n)(1 << (n)) + +/* Interrupt Clear Register 1 from ISP CPU to Host IC */ +#define INTCR1 (MCUCTL+0x20) +#define INTCR1_INTCC(n)(1 << (n)) + +/* Interrupt Mask Register 1 from ISP CPU to Host IC */ +#define INTMR1 (MCUCTL+0x24) +#define INTMR1_INTMC(n)(1 << (n)) + +/* Interrupt Status Register 1 from ISP CPU to Host IC */ +#define INTSR1 (MCUCTL+0x28) +/* Interrupt Mask Status Register 1 from ISP CPU to Host IC */ +#define INTMSR1(MCUCTL+0x2c) +/* Interrupt Clear Register 2 from ISP BLK's interrupts to Host IC */ +#define INTCR2 (MCUCTL+0x30) +#define INTCR2_INTCC(n)(1 << (n)) + +/* Interrupt Mask Register 2 from ISP BLK's interrupts to Host IC */ +#define INTMR2 (MCUCTL+0x34) +#define INTMR2_INTMCIS(n) (1 << (n)) + +/* Interrupt Status Register 2 from ISP BLK's interrupts to Host IC */ +#define INTSR2 (MCUCTL+0x38) +/* Interrupt Mask Status Register 2 from ISP BLK's interrupts to Host IC */ +#define INTMSR2(MCUCTL+0x3c) +/* General Purpose Output Control Register (0~17) */ +#define GPOCTLR(MCUCTL+0x40) +#define GPOCTLR_GPOG(n, x) ((x) << (n)) + +/* General Purpose Pad Output Enable Register (0~17) */ +#define GPOENCTLR (MCUCTL+0x44) +#define GPOENCTLR_GPOEN0(n, x) ((x) << (n)) + +/* General Purpose Input Control Register (0~17) */ +#define GPICTLR(MCUCTL+0x48) + +/* IS Shared Registers between ISP CPU and HOST CPU */ +#define ISSR(n)(MCUCTL + 0x80 + (n)) + +/* PMU for FIMC-IS*/ +#define PMUREG_CMU_RESET_ISP_SYS_PWR_REG 0x1584 +#define PMUREG_ISP_ARM_CONFIGURA
[PATCH v9 12/13] V4L: s5k6a3: Change sensor min/max resolutions
s5k6a3 sensor has actual pixel resolution of 1408x1402 against the active resolution 1392x1392. The real resolution is needed when raw sensor SRGB data is dumped to memory by fimc-lite. Signed-off-by: Arun Kumar K Reviewed-by: Sylwester Nawrocki --- drivers/media/i2c/s5k6a3.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/media/i2c/s5k6a3.c b/drivers/media/i2c/s5k6a3.c index ccbb4fc..e70e217 100644 --- a/drivers/media/i2c/s5k6a3.c +++ b/drivers/media/i2c/s5k6a3.c @@ -25,10 +25,12 @@ #include #include -#define S5K6A3_SENSOR_MAX_WIDTH1392 -#define S5K6A3_SENSOR_MAX_HEIGHT 1392 -#define S5K6A3_SENSOR_MIN_WIDTH32 -#define S5K6A3_SENSOR_MIN_HEIGHT 32 +#define S5K6A3_SENSOR_MAX_WIDTH1408 +#define S5K6A3_SENSOR_MAX_HEIGHT 1402 +#define S5K6A3_SENSOR_ACTIVE_WIDTH 1392 +#define S5K6A3_SENSOR_ACTIVE_HEIGHT1392 +#define S5K6A3_SENSOR_MIN_WIDTH(32 + 16) +#define S5K6A3_SENSOR_MIN_HEIGHT (32 + 10) #define S5K6A3_DEF_PIX_WIDTH 1296 #define S5K6A3_DEF_PIX_HEIGHT 732 -- 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 v9 08/13] [media] exynos5-fimc-is: Add sensor interface
Some sensors to be used with fimc-is are exclusively controlled
by the fimc-is firmware. This minimal sensor driver provides
the required info for the firmware to configure the sensors
sitting on I2C bus.
Signed-off-by: Arun Kumar K
Reviewed-by: Sylwester Nawrocki
---
drivers/media/platform/exynos5-is/fimc-is-sensor.c | 45 ++
drivers/media/platform/exynos5-is/fimc-is-sensor.h | 65
2 files changed, 110 insertions(+)
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-sensor.c
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-sensor.h
diff --git a/drivers/media/platform/exynos5-is/fimc-is-sensor.c
b/drivers/media/platform/exynos5-is/fimc-is-sensor.c
new file mode 100644
index 000..475f1c3
--- /dev/null
+++ b/drivers/media/platform/exynos5-is/fimc-is-sensor.c
@@ -0,0 +1,45 @@
+/*
+ * Samsung EXYNOS5250 FIMC-IS (Imaging Subsystem) driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Arun Kumar K
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "fimc-is-sensor.h"
+
+static const struct sensor_drv_data s5k6a3_drvdata = {
+ .id = FIMC_IS_SENSOR_ID_S5K6A3,
+ .open_timeout = S5K6A3_OPEN_TIMEOUT,
+ .setfile_name = "exynos5_s5k6a3_setfile.bin",
+};
+
+static const struct sensor_drv_data s5k4e5_drvdata = {
+ .id = FIMC_IS_SENSOR_ID_S5K4E5,
+ .open_timeout = S5K4E5_OPEN_TIMEOUT,
+ .setfile_name = "exynos5_s5k4e5_setfile.bin",
+};
+
+static const struct of_device_id fimc_is_sensor_of_ids[] = {
+ {
+ .compatible = "samsung,s5k6a3",
+ .data = &s5k6a3_drvdata,
+ },
+ {
+ .compatible = "samsung,s5k4e5",
+ .data = &s5k4e5_drvdata,
+ },
+ { }
+};
+
+const struct sensor_drv_data *exynos5_is_sensor_get_drvdata(
+ struct device_node *node)
+{
+ const struct of_device_id *of_id;
+
+ of_id = of_match_node(fimc_is_sensor_of_ids, node);
+ return of_id ? of_id->data : NULL;
+}
diff --git a/drivers/media/platform/exynos5-is/fimc-is-sensor.h
b/drivers/media/platform/exynos5-is/fimc-is-sensor.h
new file mode 100644
index 000..0ba5733
--- /dev/null
+++ b/drivers/media/platform/exynos5-is/fimc-is-sensor.h
@@ -0,0 +1,65 @@
+/*
+ * Samsung EXYNOS4x12 FIMC-IS (Imaging Subsystem) driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Arun Kumar K
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef FIMC_IS_SENSOR_H_
+#define FIMC_IS_SENSOR_H_
+
+#include
+#include
+
+#define S5K6A3_OPEN_TIMEOUT2000 /* ms */
+#define S5K6A3_SENSOR_WIDTH1392
+#define S5K6A3_SENSOR_HEIGHT 1392
+
+#define S5K4E5_OPEN_TIMEOUT2000 /* ms */
+#define S5K4E5_SENSOR_WIDTH2560
+#define S5K4E5_SENSOR_HEIGHT 1920
+
+#define SENSOR_WIDTH_PADDING 16
+#define SENSOR_HEIGHT_PADDING 10
+
+enum fimc_is_sensor_id {
+ FIMC_IS_SENSOR_ID_S5K3H2 = 1,
+ FIMC_IS_SENSOR_ID_S5K6A3,
+ FIMC_IS_SENSOR_ID_S5K4E5,
+ FIMC_IS_SENSOR_ID_S5K3H7,
+ FIMC_IS_SENSOR_ID_CUSTOM,
+ FIMC_IS_SENSOR_ID_END
+};
+
+struct sensor_drv_data {
+ enum fimc_is_sensor_id id;
+ /* sensor open timeout in ms */
+ unsigned short open_timeout;
+ char *setfile_name;
+};
+
+/**
+ * struct fimc_is_sensor - fimc-is sensor data structure
+ * @drvdata: a pointer to the sensor's parameters data structure
+ * @i2c_bus: ISP I2C bus index (0...1)
+ * @width: sensor active width
+ * @height: sensor active height
+ * @pixel_width: sensor effective pixel width (width + padding)
+ * @pixel_height: sensor effective pixel height (height + padding)
+ */
+struct fimc_is_sensor {
+ const struct sensor_drv_data *drvdata;
+ unsigned int i2c_bus;
+ unsigned int width;
+ unsigned int height;
+ unsigned int pixel_width;
+ unsigned int pixel_height;
+};
+
+const struct sensor_drv_data *exynos5_is_sensor_get_drvdata(
+ struct device_node *node);
+
+#endif /* FIMC_IS_SENSOR_H_ */
--
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 v9 13/13] V4L: Add driver for s5k4e5 image sensor
This patch adds subdev driver for Samsung S5K4E5 raw image sensor.
Like s5k6a3, it is also another fimc-is firmware controlled
sensor. This minimal sensor driver doesn't do any I2C communications
as its done by ISP firmware. It can be updated if needed to a
regular sensor driver by adding the I2C communication.
Signed-off-by: Arun Kumar K
Reviewed-by: Sylwester Nawrocki
---
.../devicetree/bindings/media/i2c/s5k4e5.txt | 45 +++
drivers/media/i2c/Kconfig |8 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/s5k4e5.c | 347
4 files changed, 401 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/s5k4e5.txt
create mode 100644 drivers/media/i2c/s5k4e5.c
diff --git a/Documentation/devicetree/bindings/media/i2c/s5k4e5.txt
b/Documentation/devicetree/bindings/media/i2c/s5k4e5.txt
new file mode 100644
index 000..0fca087
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/s5k4e5.txt
@@ -0,0 +1,45 @@
+* Samsung S5K4E5 Raw Image Sensor
+
+S5K4E5 is a raw image sensor with maximum resolution of 2560x1920
+pixels. Data transfer is carried out via MIPI CSI-2 port and controls
+via I2C bus.
+
+Required Properties:
+- compatible : must be "samsung,s5k4e5"
+- reg : I2C device address
+- reset-gpios : specifier of a GPIO connected to the RESET pin
+- clocks : should contain the sensor's EXTCLK clock specifier, from
+ the common clock bindings
+- clock-names : should contain "extclk" entry
+- svdda-supply : core voltage supply
+- svddio-supply: I/O voltage supply
+
+Optional Properties:
+- clock-frequency : the frequency at which the "extclk" clock should be
+ configured to operate, in Hz; if this property is not
+ specified default 24 MHz value will be used
+
+The device node should be added to respective control bus controller
+(e.g. I2C0) nodes and linked to the csis port node, using the common
+video interfaces bindings, defined in video-interfaces.txt.
+
+Example:
+
+ i2c-isp@1313 {
+ s5k4e5@20 {
+ compatible = "samsung,s5k4e5";
+ reg = <0x20>;
+ reset-gpios = <&gpx1 2 1>;
+ clock-frequency = <2400>;
+ clocks = <&clock 129>;
+ clock-names = "extclk"
+ svdda-supply = <...>;
+ svddio-supply = <...>;
+ port {
+ is_s5k4e5_ep: endpoint {
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&csis0_ep>;
+ };
+ };
+ };
+ };
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index f7e9147..271028b 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -572,6 +572,14 @@ config VIDEO_S5K6A3
This is a V4L2 sensor-level driver for Samsung S5K6A3 raw
camera sensor.
+config VIDEO_S5K4E5
+ tristate "Samsung S5K4E5 sensor support"
+ depends on MEDIA_CAMERA_SUPPORT
+ depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF
+ ---help---
+ This is a V4L2 sensor-level driver for Samsung S5K4E5 raw
+ camera sensor.
+
config VIDEO_S5K4ECGX
tristate "Samsung S5K4ECGX sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index cf3cf03..0aeed8e 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o
obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o
obj-$(CONFIG_VIDEO_S5K6A3) += s5k6a3.o
+obj-$(CONFIG_VIDEO_S5K4E5) += s5k4e5.o
obj-$(CONFIG_VIDEO_S5K4ECGX) += s5k4ecgx.o
obj-$(CONFIG_VIDEO_S5C73M3)+= s5c73m3/
obj-$(CONFIG_VIDEO_ADP1653)+= adp1653.o
diff --git a/drivers/media/i2c/s5k4e5.c b/drivers/media/i2c/s5k4e5.c
new file mode 100644
index 000..639062b
--- /dev/null
+++ b/drivers/media/i2c/s5k4e5.c
@@ -0,0 +1,347 @@
+/*
+ * Samsung S5K4E5 image sensor driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Arun Kumar K
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define S5K4E5_SENSOR_MAX_WIDTH2576
+#define S5K4E5_SENSOR_MAX_HEIGHT 1930
+
+#define S5K4E5_SENSOR_ACTIVE_WIDTH 2560
+#define S5K4E5_SENSOR
[PATCH v9 06/13] [media] exynos5-fimc-is: Add isp subdev
fimc-is driver takes video data input from the ISP video node
which is added in this patch. This node accepts Bayer input
buffers which is given from the IS sensors.
Signed-off-by: Arun Kumar K
Signed-off-by: Kilyeon Im
Reviewed-by: Sylwester Nawrocki
---
drivers/media/platform/exynos5-is/fimc-is-isp.c | 534 +++
drivers/media/platform/exynos5-is/fimc-is-isp.h | 90
2 files changed, 624 insertions(+)
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-isp.c
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-isp.h
diff --git a/drivers/media/platform/exynos5-is/fimc-is-isp.c
b/drivers/media/platform/exynos5-is/fimc-is-isp.c
new file mode 100644
index 000..7bd603f
--- /dev/null
+++ b/drivers/media/platform/exynos5-is/fimc-is-isp.c
@@ -0,0 +1,534 @@
+/*
+ * Samsung EXYNOS5250 FIMC-IS (Imaging Subsystem) driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Arun Kumar K
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+
+#include "fimc-is.h"
+
+#define ISP_DRV_NAME "fimc-is-isp"
+
+static const struct fimc_is_fmt formats[] = {
+ {
+ .name = "Bayer GR-BG 8bits",
+ .fourcc = V4L2_PIX_FMT_SGRBG8,
+ .depth = { 8 },
+ .num_planes = 1,
+ },
+ {
+ .name = "Bayer GR-BG 10bits",
+ .fourcc = V4L2_PIX_FMT_SGRBG10,
+ .depth = { 16 },
+ .num_planes = 1,
+ },
+ {
+ .name = "Bayer GR-BG 12bits",
+ .fourcc = V4L2_PIX_FMT_SGRBG12,
+ .depth = { 16 },
+ .num_planes = 1,
+ },
+};
+#define NUM_FORMATS ARRAY_SIZE(formats)
+
+static const struct fimc_is_fmt *find_format(struct v4l2_format *f)
+{
+ unsigned int i;
+
+ for (i = 0; i < NUM_FORMATS; i++)
+ if (formats[i].fourcc == f->fmt.pix_mp.pixelformat)
+ return &formats[i];
+ return NULL;
+}
+
+static int isp_video_output_start_streaming(struct vb2_queue *vq,
+ unsigned int count)
+{
+ struct fimc_is_isp *isp = vb2_get_drv_priv(vq);
+
+ set_bit(STATE_RUNNING, &isp->output_state);
+ return 0;
+}
+
+static int isp_video_output_stop_streaming(struct vb2_queue *vq)
+{
+ struct fimc_is_isp *isp = vb2_get_drv_priv(vq);
+ struct fimc_is_buf *buf;
+
+ /* Release unused buffers */
+ while (!list_empty(&isp->wait_queue)) {
+ buf = fimc_is_isp_wait_queue_get(isp);
+ vb2_buffer_done(&buf->vb, VB2_BUF_STATE_ERROR);
+ }
+ while (!list_empty(&isp->run_queue)) {
+ buf = fimc_is_isp_run_queue_get(isp);
+ vb2_buffer_done(&buf->vb, VB2_BUF_STATE_ERROR);
+ }
+
+ clear_bit(STATE_RUNNING, &isp->output_state);
+ return 0;
+}
+
+static int isp_video_output_queue_setup(struct vb2_queue *vq,
+ const struct v4l2_format *pfmt,
+ unsigned int *num_buffers, unsigned int *num_planes,
+ unsigned int sizes[], void *allocators[])
+{
+ struct fimc_is_isp *isp = vb2_get_drv_priv(vq);
+ const struct fimc_is_fmt *fmt = isp->fmt;
+ unsigned int wh, i;
+
+ if (!fmt)
+ return -EINVAL;
+
+ *num_planes = fmt->num_planes;
+ wh = isp->width * isp->height;
+
+ for (i = 0; i < *num_planes; i++) {
+ allocators[i] = isp->alloc_ctx;
+ sizes[i] = (wh * fmt->depth[i]) / 8;
+ }
+ return 0;
+}
+
+static int isp_video_output_buffer_init(struct vb2_buffer *vb)
+{
+ struct fimc_is_buf *buf = container_of(vb, struct fimc_is_buf, vb);
+
+ buf->paddr[0] = vb2_dma_contig_plane_dma_addr(vb, 0);
+ return 0;
+}
+
+static int isp_video_output_buffer_prepare(struct vb2_buffer *vb)
+{
+ struct vb2_queue *vq = vb->vb2_queue;
+ struct fimc_is_isp *isp = vb2_get_drv_priv(vq);
+ unsigned long size;
+
+ size = (isp->width * isp->height * isp->fmt->depth[0]) / 8;
+ if (vb2_plane_size(vb, 0) < size) {
+ v4l2_err(&isp->subdev, "User buffer too small (%ld < %ld)\n",
+vb2_plane_size(vb, 0), size);
+ return -EINVAL;
+ }
+ vb2_set_plane_payload(vb, 0, size);
+
+ return 0;
+}
+
+static void isp_video_output_buffer_queue(struct vb2_buffer *vb)
+{
+ struct vb2_queue *vq = vb->vb2_queue;
+ struct fimc_is_isp *isp = vb2_get_drv_priv(vq);
+ struct fimc_is_buf *buf = container_of(vb, struct fimc_is_buf, vb);
+
+ fimc_is_pipeline_buf_lock(isp->pipeline);
+ fimc_is_isp_wait_queue_add(isp, buf);
+ fimc_is_pi
[PATCH v9 10/13] [media] exynos5-fimc-is: Add the hardware interface module
The hardware interface module finally sends the commands to the
FIMC-IS firmware and runs the interrupt handler for getting the
responses.
Signed-off-by: Arun Kumar K
Signed-off-by: Kilyeon Im
Reviewed-by: Sylwester Nawrocki
---
.../media/platform/exynos5-is/fimc-is-interface.c | 810
.../media/platform/exynos5-is/fimc-is-interface.h | 124 +++
2 files changed, 934 insertions(+)
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-interface.c
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-interface.h
diff --git a/drivers/media/platform/exynos5-is/fimc-is-interface.c
b/drivers/media/platform/exynos5-is/fimc-is-interface.c
new file mode 100644
index 000..c5da6ff
--- /dev/null
+++ b/drivers/media/platform/exynos5-is/fimc-is-interface.c
@@ -0,0 +1,810 @@
+/*
+ * Samsung EXYNOS5 FIMC-IS (Imaging Subsystem) driver
+*
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Kil-yeon Lim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include "fimc-is.h"
+#include "fimc-is-cmd.h"
+#include "fimc-is-regs.h"
+
+#define init_request_barrier(itf) mutex_init(&itf->request_barrier)
+#define enter_request_barrier(itf) mutex_lock(&itf->request_barrier)
+#define exit_request_barrier(itf) mutex_unlock(&itf->request_barrier)
+
+static inline void itf_get_cmd(struct fimc_is_interface *itf,
+ struct fimc_is_msg *msg, unsigned int index)
+{
+ struct is_common_reg __iomem *com_regs = itf->com_regs;
+
+ memset(msg, 0, sizeof(*msg));
+
+ switch (index) {
+ case INTR_GENERAL:
+ msg->command = com_regs->ihcmd;
+ msg->instance = com_regs->ihc_sensorid;
+ memcpy(msg->param, com_regs->ihc_param,
+ 4 * sizeof(msg->param[0]));
+ break;
+ case INTR_SCC_FDONE:
+ msg->command = IHC_FRAME_DONE;
+ msg->instance = com_regs->scc_sensor_id;
+ memcpy(msg->param, com_regs->scc_param,
+ 3 * sizeof(msg->param[0]));
+ break;
+ case INTR_SCP_FDONE:
+ msg->command = IHC_FRAME_DONE;
+ msg->instance = com_regs->scp_sensor_id;
+ memcpy(msg->param, com_regs->scp_param,
+ 3 * sizeof(msg->param[0]));
+ break;
+ case INTR_META_DONE:
+ msg->command = IHC_FRAME_DONE;
+ msg->instance = com_regs->meta_sensor_id;
+ msg->param[0] = com_regs->meta_param1;
+ break;
+ case INTR_SHOT_DONE:
+ msg->command = IHC_FRAME_DONE;
+ msg->instance = com_regs->shot_sensor_id;
+ memcpy(msg->param, com_regs->shot_param,
+ 2 * sizeof(msg->param[0]));
+ break;
+ default:
+ dev_err(itf->dev, "%s Unknown command\n", __func__);
+ break;
+ }
+}
+
+static inline unsigned int itf_get_intr(struct fimc_is_interface *itf)
+{
+ unsigned int status;
+ struct is_common_reg __iomem *com_regs = itf->com_regs;
+
+ status = readl(itf->regs + INTMSR1) | com_regs->ihcmd_iflag |
+ com_regs->scc_iflag |
+ com_regs->scp_iflag |
+ com_regs->meta_iflag |
+ com_regs->shot_iflag;
+
+ return status;
+}
+
+static void itf_set_state(struct fimc_is_interface *itf,
+ unsigned long state)
+{
+ unsigned long flags;
+ spin_lock_irqsave(&itf->slock_state, flags);
+ __set_bit(state, &itf->state);
+ spin_unlock_irqrestore(&itf->slock_state, flags);
+}
+
+static void itf_clr_state(struct fimc_is_interface *itf,
+ unsigned long state)
+{
+ unsigned long flags;
+ spin_lock_irqsave(&itf->slock_state, flags);
+ __clear_bit(state, &itf->state);
+ spin_unlock_irqrestore(&itf->slock_state, flags);
+}
+
+static int itf_get_state(struct fimc_is_interface *itf,
+ unsigned long state)
+{
+ int ret = 0;
+ unsigned long flags;
+
+ spin_lock_irqsave(&itf->slock_state, flags);
+ ret = test_bit(state, &itf->state);
+ spin_unlock_irqrestore(&itf->slock_state, flags);
+ return ret;
+}
+
+static void itf_init_wakeup(struct fimc_is_interface *itf)
+{
+ itf_set_state(itf, IS_IF_STATE_INIT);
+ wake_up(&itf->irq_queue);
+}
+
+void itf_busy_wakeup(struct fimc_is_interface *itf)
+{
+ itf_clr_state(itf, IS_IF_STATE_BUSY);
+ wake_up(&itf->irq_queue);
+}
+
+static int itf_wait_hw_ready(struct fimc_is_interface *itf)
+{
+ int t;
+ for (t = TRY_RECV_AWARE_COUNT; t >= 0; t--) {
+ unsigned int cfg = readl(itf->regs + INTMSR0);
+ if (INTMSR0_GET_INTMSD(0, cfg) == 0)
+
[PATCH v9 09/13] [media] exynos5-fimc-is: Add the hardware pipeline control
This patch adds the crucial hardware pipeline control for the
fimc-is driver. All the subdev nodes will call this pipeline
interfaces to reach the hardware. Responsibilities of this module
involves configuring and maintaining the hardware pipeline involving
multiple sub-ips like ISP, DRC, Scalers, ODC, 3DNR, FD etc.
Signed-off-by: Arun Kumar K
Signed-off-by: Kilyeon Im
Reviewed-by: Sylwester Nawrocki
---
.../media/platform/exynos5-is/fimc-is-pipeline.c | 1708
.../media/platform/exynos5-is/fimc-is-pipeline.h | 129 ++
2 files changed, 1837 insertions(+)
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-pipeline.c
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-pipeline.h
diff --git a/drivers/media/platform/exynos5-is/fimc-is-pipeline.c
b/drivers/media/platform/exynos5-is/fimc-is-pipeline.c
new file mode 100644
index 000..a73d952
--- /dev/null
+++ b/drivers/media/platform/exynos5-is/fimc-is-pipeline.c
@@ -0,0 +1,1708 @@
+/*
+ * Samsung EXYNOS5 FIMC-IS (Imaging Subsystem) driver
+*
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Arun Kumar K
+ * Kil-yeon Lim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "fimc-is.h"
+#include "fimc-is-pipeline.h"
+#include "fimc-is-metadata.h"
+#include "fimc-is-regs.h"
+#include "fimc-is-cmd.h"
+#include
+#include
+
+/* Default setting values */
+#define DEFAULT_PREVIEW_STILL_WIDTH1280
+#define DEFAULT_PREVIEW_STILL_HEIGHT 720
+#define DEFAULT_CAPTURE_VIDEO_WIDTH1920
+#define DEFAULT_CAPTURE_VIDEO_HEIGHT 1080
+#define DEFAULT_CAPTURE_STILL_WIDTH2560
+#define DEFAULT_CAPTURE_STILL_HEIGHT 1920
+#define DEFAULT_CAPTURE_STILL_CROP_WIDTH 2560
+#define DEFAULT_CAPTURE_STILL_CROP_HEIGHT 1440
+#define DEFAULT_PREVIEW_VIDEO_WIDTH640
+#define DEFAULT_PREVIEW_VIDEO_HEIGHT 480
+
+/* Init params for pipeline devices */
+static const struct sensor_param init_sensor_param = {
+ .frame_rate = {
+ .frame_rate = 30,
+ },
+};
+
+static const struct isp_param init_isp_param = {
+ .control = {
+ .cmd = CONTROL_COMMAND_START,
+ .bypass = CONTROL_BYPASS_DISABLE,
+ },
+ .otf_input = {
+ .cmd = OTF_INPUT_COMMAND_DISABLE,
+ .width = DEFAULT_CAPTURE_STILL_WIDTH,
+ .height = DEFAULT_CAPTURE_STILL_HEIGHT,
+ .format = OTF_INPUT_FORMAT_BAYER,
+ .bitwidth = OTF_INPUT_BIT_WIDTH_10BIT,
+ .order = OTF_INPUT_ORDER_BAYER_GR_BG,
+ .frametime_max = 3,
+ },
+ .dma1_input = {
+ .cmd = DMA_INPUT_COMMAND_DISABLE,
+ },
+ .dma2_input = {
+ .cmd = DMA_INPUT_COMMAND_DISABLE,
+ },
+ .aa = {
+ .cmd = ISP_AA_COMMAND_START,
+ },
+ .flash = {
+ .cmd = ISP_FLASH_COMMAND_DISABLE,
+ .redeye = ISP_FLASH_REDEYE_DISABLE,
+ },
+ .awb = {
+ .cmd = ISP_AWB_COMMAND_AUTO,
+ },
+ .effect = {
+ .cmd = ISP_IMAGE_EFFECT_DISABLE,
+ },
+ .iso = {
+ .cmd = ISP_ISO_COMMAND_AUTO,
+ },
+ .adjust = {
+ .cmd = ISP_ADJUST_COMMAND_AUTO,
+ },
+ .metering = {
+ .cmd = ISP_METERING_COMMAND_CENTER,
+ .win_width = DEFAULT_CAPTURE_STILL_WIDTH,
+ .win_height = DEFAULT_CAPTURE_STILL_HEIGHT,
+ },
+ .afc = {
+ .cmd = ISP_AFC_COMMAND_AUTO,
+ },
+ .otf_output = {
+ .cmd = OTF_OUTPUT_COMMAND_ENABLE,
+ .width = DEFAULT_CAPTURE_STILL_WIDTH,
+ .height = DEFAULT_CAPTURE_STILL_HEIGHT,
+ .format = OTF_OUTPUT_FORMAT_YUV444,
+ .bitwidth = OTF_OUTPUT_BIT_WIDTH_12BIT,
+ .order = OTF_OUTPUT_ORDER_BAYER_GR_BG,
+ },
+ .dma1_output = {
+ .cmd = DMA_OUTPUT_COMMAND_DISABLE,
+ .width = DEFAULT_CAPTURE_STILL_WIDTH,
+ .height = DEFAULT_CAPTURE_STILL_HEIGHT,
+ .format = DMA_INPUT_FORMAT_YUV444,
+ .bitwidth = DMA_INPUT_BIT_WIDTH_8BIT,
+ .plane = 1,
+ .order = DMA_INPUT_ORDER_YCBCR,
+ },
+ .dma2_output = {
+ .cmd = DMA_OUTPUT_COMMAND_DISABLE,
+ .width = DEFAULT_CAPTURE_STILL_WIDTH,
+ .height = DEFAULT_CAPTURE_STILL_HEIGHT,
+ .format = DMA_OUTPUT_FORMAT_BAYER,
+ .bitwidth = DMA_OUTPUT_BIT_WIDTH_12BIT,
+ .plane = 1,
+ .order = DMA_OUTPUT_ORDER_GB_BG,
+ .dma_out_mask = 0x,
+ },
+};
+
+static const struct drc_param init_drc_param = {
+ .control
[PATCH v9 03/13] [media] exynos5-fimc-is: Add driver core files
This driver is for the FIMC-IS IP available in Samsung Exynos5
SoC onwards. This patch adds the core files for the new driver.
Signed-off-by: Arun Kumar K
Signed-off-by: Kilyeon Im
Reviewed-by: Sylwester Nawrocki
---
drivers/media/platform/exynos5-is/fimc-is-core.c | 410 ++
drivers/media/platform/exynos5-is/fimc-is-core.h | 132 +++
2 files changed, 542 insertions(+)
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-core.c
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-core.h
diff --git a/drivers/media/platform/exynos5-is/fimc-is-core.c
b/drivers/media/platform/exynos5-is/fimc-is-core.c
new file mode 100644
index 000..2b116d0
--- /dev/null
+++ b/drivers/media/platform/exynos5-is/fimc-is-core.c
@@ -0,0 +1,410 @@
+/*
+ * Samsung EXYNOS5 FIMC-IS (Imaging Subsystem) driver
+*
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Arun Kumar K
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "fimc-is.h"
+#include "fimc-is-i2c.h"
+
+#define CLK_MCU_ISP_DIV0_FREQ (200 * 100)
+#define CLK_MCU_ISP_DIV1_FREQ (100 * 100)
+#define CLK_ISP_DIV0_FREQ (134 * 100)
+#define CLK_ISP_DIV1_FREQ (68 * 100)
+#define CLK_ISP_DIVMPWM_FREQ (34 * 100)
+
+static const char * const fimc_is_clock_name[] = {
+ [IS_CLK_ISP]= "isp",
+ [IS_CLK_MCU_ISP]= "mcu_isp",
+ [IS_CLK_ISP_DIV0] = "isp_div0",
+ [IS_CLK_ISP_DIV1] = "isp_div1",
+ [IS_CLK_ISP_DIVMPWM]= "isp_divmpwm",
+ [IS_CLK_MCU_ISP_DIV0] = "mcu_isp_div0",
+ [IS_CLK_MCU_ISP_DIV1] = "mcu_isp_div1",
+};
+
+static void fimc_is_put_clocks(struct fimc_is *is)
+{
+ int i;
+
+ for (i = 0; i < IS_CLK_MAX_NUM; i++) {
+ if (IS_ERR(is->clock[i]))
+ continue;
+ clk_unprepare(is->clock[i]);
+ clk_put(is->clock[i]);
+ is->clock[i] = ERR_PTR(-EINVAL);
+ }
+}
+
+static int fimc_is_get_clocks(struct fimc_is *is)
+{
+ struct device *dev = &is->pdev->dev;
+ int i, ret;
+
+ for (i = 0; i < IS_CLK_MAX_NUM; i++) {
+ is->clock[i] = clk_get(dev, fimc_is_clock_name[i]);
+ if (IS_ERR(is->clock[i]))
+ goto err;
+ ret = clk_prepare(is->clock[i]);
+ if (ret < 0) {
+ clk_put(is->clock[i]);
+ is->clock[i] = ERR_PTR(-EINVAL);
+ goto err;
+ }
+ }
+ return 0;
+err:
+ fimc_is_put_clocks(is);
+ pr_err("Failed to get clock: %s\n", fimc_is_clock_name[i]);
+ return -ENXIO;
+}
+
+static int fimc_is_configure_clocks(struct fimc_is *is)
+{
+ int i, ret;
+
+ for (i = 0; i < IS_CLK_MAX_NUM; i++)
+ is->clock[i] = ERR_PTR(-EINVAL);
+
+ ret = fimc_is_get_clocks(is);
+ if (ret)
+ return ret;
+
+ /* Set rates */
+ ret = clk_set_rate(is->clock[IS_CLK_MCU_ISP_DIV0],
+ CLK_MCU_ISP_DIV0_FREQ);
+ if (ret)
+ return ret;
+ ret = clk_set_rate(is->clock[IS_CLK_MCU_ISP_DIV1],
+ CLK_MCU_ISP_DIV1_FREQ);
+ if (ret)
+ return ret;
+ ret = clk_set_rate(is->clock[IS_CLK_ISP_DIV0], CLK_ISP_DIV0_FREQ);
+ if (ret)
+ return ret;
+ ret = clk_set_rate(is->clock[IS_CLK_ISP_DIV1], CLK_ISP_DIV1_FREQ);
+ if (ret)
+ return ret;
+ ret = clk_set_rate(is->clock[IS_CLK_ISP_DIVMPWM],
+ CLK_ISP_DIVMPWM_FREQ);
+ return ret;
+}
+
+static void fimc_is_pipelines_destroy(struct fimc_is *is)
+{
+ int i;
+
+ for (i = 0; i < is->drvdata->num_instances; i++)
+ fimc_is_pipeline_destroy(&is->pipeline[i]);
+}
+
+static int fimc_is_parse_sensor_config(struct fimc_is *is, unsigned int index,
+ struct device_node *node)
+{
+ struct fimc_is_sensor *sensor = &is->sensor[index];
+ u32 tmp = 0;
+ int ret;
+
+ sensor->drvdata = exynos5_is_sensor_get_drvdata(node);
+ if (!sensor->drvdata) {
+ dev_err(&is->pdev->dev, "no driver data found for: %s\n",
+node->full_name);
+ return -EINVAL;
+ }
+
+ node = v4l2_of_get_next_endpoint(node, NULL);
+ if (!node)
+ return -EN
[PATCH v9 02/13] [media] exynos5-fimc-is: Add Exynos5 FIMC-IS device tree bindings documentation
The patch adds the DT binding documentation for Samsung
Exynos5 SoC series imaging subsystem (FIMC-IS).
Signed-off-by: Arun Kumar K
Reviewed-by: Sylwester Nawrocki
---
.../devicetree/bindings/media/exynos5-fimc-is.txt | 84
1 file changed, 84 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/exynos5-fimc-is.txt
diff --git a/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt
b/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt
new file mode 100644
index 000..0525417
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt
@@ -0,0 +1,84 @@
+Samsung EXYNOS5 SoC series Imaging Subsystem (FIMC-IS)
+--
+
+The camera subsystem on Samsung Exynos5 SoC has some changes relative
+to previous SoC versions. Exynos5 has almost similar MIPI-CSIS and
+FIMC-LITE IPs but has a much improved version of FIMC-IS which can
+handle sensor controls and camera post-processing operations. The
+Exynos5 FIMC-IS has a dedicated ARM Cortex A5 processor, many
+post-processing blocks (ISP, DRC, FD, ODC, DIS, 3DNR) and two
+dedicated scalers (SCC and SCP).
+
+fimc-is node
+
+
+Required properties:
+
+- compatible: must be "samsung,exynos5250-fimc-is"
+- reg : physical base address and size of the memory mapped
+ registers
+- interrupt-parent : parent interrupt controller
+- interrupts: fimc-is interrupt to the parent interrupt controller
+- clocks: list of clock specifiers, corresponding to entries in
+ clock-names property
+- clock-names : must contain "isp", "mcu_isp", "isp_div0", "isp_div1",
+ "isp_divmpwm", "mcu_isp_div0", "mcu_isp_div1" entries,
+ matching entries in the clocks property
+- samsung,pmu : phandle to the Power Management Unit (PMU) node
+
+i2c-isp (ISP I2C bus controller) nodes
+--
+The i2c-isp node is defined as the child node of fimc-is.
+
+Required properties:
+
+- compatible : should be "samsung,exynos4212-i2c-isp" for Exynos4212,
+ Exynos4412 and Exynos5250 SoCs
+- reg : physical base address and length of the registers set
+- clocks : must contain gate clock specifier for this controller
+- clock-names : must contain "i2c_isp" entry
+
+For the i2c-isp node, it is required to specify a pinctrl state named
"default",
+according to the pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt.
+
+Device tree nodes of the image sensors controlled directly by the FIMC-IS
+firmware must be child nodes of their corresponding ISP I2C bus controller
node.
+The data link of these image sensors must be specified using the common video
+interfaces bindings, defined in video-interfaces.txt.
+
+Example:
+
+ fimc_is: fimc-is@1300 {
+ compatible = "samsung,exynos5250-fimc-is";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ reg = <0x1300 0x20>;
+ interrupt-parent = <&combiner>;
+ interrupts = <19 1>;
+ clocks = <&clock 346>, <&clock 347>, <&clock 512>,
+ <&clock 513>, <&clock 514>, <&clock 515>,
+ <&clock 516>;
+ clock-names = "isp", "mcu_isp", "isp_div0", "isp_div1",
+ "isp_divmpwm", "mcu_isp_div0",
+ "mcu_isp_div1";
+ samsung,pmu = <&pmu>;
+
+ i2c0_isp: i2c-isp@1313 {
+ compatible = "samsung,exynos4212-i2c-isp";
+ reg = <0x1313 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clock 352>;
+ clock-names = "i2c_isp";
+ };
+
+ i2c1_isp: i2c-isp@1314 {
+ compatible = "samsung,exynos4212-i2c-isp";
+ reg = <0x1314 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clock 353>;
+ clock-names = "i2c_isp";
+ };
+ };
--
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 v5] media: st-rc: Add ST remote control driver
Thanks Prabhakar,
>> +config RC_ST
>> + tristate "ST remote control receiver"
>> + depends on ARCH_STI && RC_CORE
>> + help
>> +Say Y here if you want support for ST remote control driver
>> +which allows both IR and UHF RX.
>> +The driver passes raw pluse and space information to the LIRC
>> decoder.
>> +
> s/pluse/pulse
>
Yep.. Will fix it..
[...]
>> +
>> +/* Registers */
>> +#define IRB_SAMPLE_RATE_COMM 0x64/* sample freq divisor*/
>> +#define IRB_CLOCK_SEL 0x70/* clock select */
>> +#define IRB_CLOCK_SEL_STATUS 0x74/* clock status */
>> +/* IRB IR/UHF receiver registers */
>> +#define IRB_RX_ON 0x40 /* pulse time capture */
>> +#define IRB_RX_SYS 0X44 /* sym period capture */
>> +#define IRB_RX_INT_EN 0x48 /* IRQ enable (R/W) */
>> +#define IRB_RX_INT_STATUS 0x4C /* IRQ status (R/W) */
>> +#define IRB_RX_EN 0x50 /* Receive enablei*/
> s/enablei/enable
>
>> +#define IRB_MAX_SYM_PERIOD 0x54 /* max sym value */
>> +#define IRB_RX_INT_CLEAR0x58 /* overrun status */
>> +#define IRB_RX_STATUS 0x6C /* receive status */
>> +#define IRB_RX_NOISE_SUPPR 0x5C /* noise suppression */
>> +#define IRB_RX_POLARITY_INV 0x68 /* polarity inverter */
>> +
> generally smaller case hex letters are preferred
I will change this.
[...]
>> +
>> +static int st_rc_probe(struct platform_device *pdev)
>> +{
>> + int ret = -EINVAL;
>> + struct rc_dev *rdev;
>> + struct device *dev = &pdev->dev;
>> + struct resource *res;
>> + struct st_rc_device *rc_dev;
>> + struct device_node *np = pdev->dev.of_node;
>> + const char *rx_mode;
>> +
>> + rc_dev = devm_kzalloc(dev, sizeof(struct st_rc_device), GFP_KERNEL);
>> +
>> + if (!rc_dev)
>> + return -ENOMEM;
>> +
>> + rdev = rc_allocate_device();
>> +
>> + if (!rdev)
>> + return -ENOMEM;
>> +
>> + if (np && !of_property_read_string(np, "rx-mode", &rx_mode)) {
>> +
>> + if (!strcmp(rx_mode, "uhf")) {
>> + rc_dev->rxuhfmode = true;
>> + } else if (!strcmp(rx_mode, "infrared")) {
>> + rc_dev->rxuhfmode = false;
>> + } else {
>> + dev_err(dev, "Unsupported rx mode [%s]\n", rx_mode);
>> + goto err;
>> + }
>> +
>> + } else {
>> + goto err;
>> + }
>> +
>> + rc_dev->sys_clock = devm_clk_get(dev, NULL);
>> + if (IS_ERR(rc_dev->sys_clock)) {
>> + dev_err(dev, "System clock not found\n");
>> + ret = PTR_ERR(rc_dev->sys_clock);
>> + goto err;
>> + }
>> +
>> + rc_dev->irq = platform_get_irq(pdev, 0);
>> + if (rc_dev->irq < 0) {
>> + ret = rc_dev->irq;
>> + goto clkerr;
>> + }
>> +
>> + ret = -ENODEV;
> Not required
yes, its redundant here.
>
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + if (!res)
>> + goto clkerr;
>> +
> This check is not required.
Ok, I see your point.
>
>> + rc_dev->base = devm_ioremap_resource(dev, res);
>> + if (IS_ERR(rc_dev->base))
>> + goto clkerr;
>> +
> In case of error assin ret to PTR_ERR(rc_dev->base)
Yes It makes sense .. I will assign it to ret.
Also found that there is a typo here.
It should be a goto err instead of goto clkerr.
Will fix that as well in next spin.
>
>> + if (rc_dev->rxuhfmode)
>> + rc_dev->rx_base = rc_dev->base + 0x40;
>> + else
>> + rc_dev->rx_base = rc_dev->base;
>> +
>> + rc_dev->dev = dev;
>> + platform_set_drvdata(pdev, rc_dev);
>> + st_rc_hardware_init(rc_dev);
>> +
>> + rdev->driver_type = RC_DRIVER_IR_RAW;
>> + rdev->allowed_protos = RC_BIT_ALL;
>> + /* rx sampling rate is 10Mhz */
>> + rdev->rx_resolution = 100;
>> + rdev->timeout = US_TO_NS(MAX_SYMB_TIME);
>> + rdev->priv = rc_dev;
>> + rdev->open = st_rc_open;
>> + rdev->close = st_rc_close;
>> + rdev->driver_name = IR_ST_NAME;
>> + rdev->map_name = RC_MAP_LIRC;
>> + rdev->input_name = "ST Remote Control Receiver";
>> +
>> + /* enable wake via this device */
>> + device_set_wakeup_capable(dev, true);
>> + device_set_wakeup_enable(dev, true);
>> +
>> + ret = rc_register_device(rdev);
>> + if (ret < 0)
>> + goto clkerr;
>> +
>> + rc_dev->rdev = rdev;
>> + if (devm_request_irq(dev, rc_dev->irq, st_rc_rx_interrupt,
>> + IRQF_NO_SUSPEND, IR_ST_NAME, rc_dev) < 0) {
>> + dev_err(dev, "IRQ %d register failed\n", rc_dev->irq);
>> + ret = -EINVAL;
>> + goto rcerr;
>> + }
>> +
>> + /**
>> +
[PATCH RFC] media: rc: OF: Add Generic bindings for remote-control
From: Srinivas Kandagatla
This patch attempts to collate generic bindings which can be used by
the remote control hardwares. Currently the list is not long as there
are only 2 drivers which are device tree'd.
Mainly this patch tries to document few bindings used by ST IRB driver
which can be generic as well. This document also add fews common
bindings used by most of the drivers like, interrupts, regs, clocks and
pinctrls.
This document can also be holding place to describe generic bindings
used in remote controls devices.
Signed-off-by: Srinivas Kandagatla
---
Hi All,
Following Stephen Warren's suggestions at https://lkml.org/lkml/2013/9/24/452
this patch is an attempt to document such generic bindings in a common
document.
This document currently collates all the generic bindings used with
remote-controls and act as holding place to describe generic bindings for
remote controls.
Comments?
Thanks,
srini
.../devicetree/bindings/media/remote-control.txt | 31
1 files changed, 31 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/remote-control.txt
diff --git a/Documentation/devicetree/bindings/media/remote-control.txt
b/Documentation/devicetree/bindings/media/remote-control.txt
new file mode 100644
index 000..901ea56
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/remote-control.txt
@@ -0,0 +1,31 @@
+Generic device tree bindings for remote control.
+
+properties:
+ - compatible: Can contain any remote control driver compatible string.
+ example: "st-comms-irb, "gpio-ir-receiver".
+ - reg: Base physical address of the controller and length of memory
+ mapped region.
+ - interrupts: Interrupt-specifier for the sole interrupt generated by
+ the device. The interrupt specifier format depends on the
+ interrupt controller parent. Iff the device supports interrupts.
+ - rx-mode: Can be "infrared" or "uhf". rx-mode should be present iff
+ the rx pins are wired up.
+ - tx-mode: Can be "infrared" or "uhf". tx-mode should be present iff
+ the tx pins are wired up.
+
+Optional properties:
+ - linux,rc-map-name: Linux specific remote control map name. Refer to
+ include/media/rc-map.h for full list of maps.
+ - pinctrl-names, pinctrl-0: The pincontrol settings to configure muxing
+ properly for the device pins.
+ - clocks : phandle with clock-specifier pair for the device specified
+ in compatible.
+
+example:
+
+ rc: rc@fe518000 {
+ compatible = "st,comms-irb";
+ reg = <0xfe518000 0x234>;
+ interrupts = <0 203 0>;
+ rx-mode = "infrared";
+ };
--
1.7.6.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 v5] media: st-rc: Add ST remote control driver
Hi Srinivas,
Thanks for the patch. Several nits below.
On Fri, Sep 27, 2013 at 2:32 PM, Srinivas KANDAGATLA
wrote:
> From: Srinivas Kandagatla
>
> This patch adds support to ST RC driver, which is basically a IR/UHF
> receiver and transmitter. This IP (IRB) is common across all the ST
> parts for settop box platforms. IRB is embedded in ST COMMS IP block.
> It supports both Rx & Tx functionality.
>
> This driver adds only Rx functionality via LIRC codec.
>
> Signed-off-by: Srinivas Kandagatla
> Acked-by: Sean Young
> ---
> Hi Chehab,
>
> This is a very simple rc driver for IRB controller found in STi SOCs.
> This driver is a raw driver which feeds data to lirc codec for the user lircd
> to decode the keys.
>
> This patch is based on v3.12-rc1.
>
> Changes since v4:
> - updated dt bindings doc with suggestions from Stephen W.
>
> Changes since v3:
> - updated dt bindings doc with suggestions from Mark R.
>
> Changes since v2:
> - Updated Kconfig dependencies as suggested by Sean and Chehab.
> - Fixed a logical check spoted by Sean.
>
> Changes since v1:
> - Device tree bindings cleaned up as suggested by Mark and Pawel
> - use ir_raw_event_reset under overflow conditions as suggested by
> Sean.
> - call ir_raw_event_handle in interrupt handler as suggested by Sean.
> - correct allowed_protos flag with RC_BIT_ types as suggested by Sean.
> - timeout and rx resolution added as suggested by Sean.
>
> Thankyou all for reviewing and commenting.
>
> Thanks,
> srini
> Documentation/devicetree/bindings/media/st-rc.txt | 27 ++
> drivers/media/rc/Kconfig | 10 +
> drivers/media/rc/Makefile |1 +
> drivers/media/rc/st_rc.c | 396
> +
> 4 files changed, 434 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/media/st-rc.txt
> create mode 100644 drivers/media/rc/st_rc.c
>
> diff --git a/Documentation/devicetree/bindings/media/st-rc.txt
> b/Documentation/devicetree/bindings/media/st-rc.txt
> new file mode 100644
> index 000..797ef39
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/st-rc.txt
> @@ -0,0 +1,27 @@
> +Device-Tree bindings for ST IRB IP
> +
> +Required properties:
> + - compatible: Should contain "st,comms-irb".
> + - reg: Base physical address of the controller and length of memory
> + mapped region.
> + - interrupts: interrupt-specifier for the sole interrupt generated by
> + the device. The interrupt specifier format depends on the interrupt
> + controller parent.
> + - rx-mode: can be "infrared" or "uhf". rx-mode should be present iff
> + the rx pins are wired up.
> + - tx-mode: should be "infrared". tx-mode should be present iff the tx
> + pins are wired up.
> +
> +Optional properties:
> + - pinctrl-names, pinctrl-0: the pincontrol settings to configure
> muxing
> + properly for IRB pins.
> + - clocks : phandle with clock-specifier pair for IRB block.
> +
> +Example node:
> +
> + rc: rc@fe518000 {
> + compatible = "st,comms-irb";
> + reg = <0xfe518000 0x234>;
> + interrupts = <0 203 0>;
> + rx-mode = "infrared";
> + };
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index 11e84bc..557afc5 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -322,4 +322,14 @@ config IR_GPIO_CIR
>To compile this driver as a module, choose M here: the module will
>be called gpio-ir-recv.
>
> +config RC_ST
> + tristate "ST remote control receiver"
> + depends on ARCH_STI && RC_CORE
> + help
> +Say Y here if you want support for ST remote control driver
> +which allows both IR and UHF RX.
> +The driver passes raw pluse and space information to the LIRC
> decoder.
> +
s/pluse/pulse
> +If you're not sure, select N here.
> +
> endif #RC_DEVICES
> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> index 56bacf0..f4eb32c 100644
> --- a/drivers/media/rc/Makefile
> +++ b/drivers/media/rc/Makefile
> @@ -30,3 +30,4 @@ obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o
> obj-$(CONFIG_IR_GPIO_CIR) += gpio-ir-recv.o
> obj-$(CONFIG_IR_IGUANA) += iguanair.o
> obj-$(CONFIG_IR_TTUSBIR) += ttusbir.o
> +obj-$(CONFIG_RC_ST) += st_rc.o
> diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
> new file mode 100644
> index 000..e2dad9c
> --- /dev/null
> +++ b/drivers/media/rc/st_rc.c
> @@ -0,0 +1,396 @@
> +/*
> + * Copyright (C) 2013 STMicroelectronics Limited
> + * Author: Srinivas Kandagatla
> + *
> + * 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 Foundatio
[PATCH v5] media: st-rc: Add ST remote control driver
From: Srinivas Kandagatla
This patch adds support to ST RC driver, which is basically a IR/UHF
receiver and transmitter. This IP (IRB) is common across all the ST
parts for settop box platforms. IRB is embedded in ST COMMS IP block.
It supports both Rx & Tx functionality.
This driver adds only Rx functionality via LIRC codec.
Signed-off-by: Srinivas Kandagatla
Acked-by: Sean Young
---
Hi Chehab,
This is a very simple rc driver for IRB controller found in STi SOCs.
This driver is a raw driver which feeds data to lirc codec for the user lircd
to decode the keys.
This patch is based on v3.12-rc1.
Changes since v4:
- updated dt bindings doc with suggestions from Stephen W.
Changes since v3:
- updated dt bindings doc with suggestions from Mark R.
Changes since v2:
- Updated Kconfig dependencies as suggested by Sean and Chehab.
- Fixed a logical check spoted by Sean.
Changes since v1:
- Device tree bindings cleaned up as suggested by Mark and Pawel
- use ir_raw_event_reset under overflow conditions as suggested by Sean.
- call ir_raw_event_handle in interrupt handler as suggested by Sean.
- correct allowed_protos flag with RC_BIT_ types as suggested by Sean.
- timeout and rx resolution added as suggested by Sean.
Thankyou all for reviewing and commenting.
Thanks,
srini
Documentation/devicetree/bindings/media/st-rc.txt | 27 ++
drivers/media/rc/Kconfig | 10 +
drivers/media/rc/Makefile |1 +
drivers/media/rc/st_rc.c | 396 +
4 files changed, 434 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/st-rc.txt
create mode 100644 drivers/media/rc/st_rc.c
diff --git a/Documentation/devicetree/bindings/media/st-rc.txt
b/Documentation/devicetree/bindings/media/st-rc.txt
new file mode 100644
index 000..797ef39
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/st-rc.txt
@@ -0,0 +1,27 @@
+Device-Tree bindings for ST IRB IP
+
+Required properties:
+ - compatible: Should contain "st,comms-irb".
+ - reg: Base physical address of the controller and length of memory
+ mapped region.
+ - interrupts: interrupt-specifier for the sole interrupt generated by
+ the device. The interrupt specifier format depends on the interrupt
+ controller parent.
+ - rx-mode: can be "infrared" or "uhf". rx-mode should be present iff
+ the rx pins are wired up.
+ - tx-mode: should be "infrared". tx-mode should be present iff the tx
+ pins are wired up.
+
+Optional properties:
+ - pinctrl-names, pinctrl-0: the pincontrol settings to configure muxing
+ properly for IRB pins.
+ - clocks : phandle with clock-specifier pair for IRB block.
+
+Example node:
+
+ rc: rc@fe518000 {
+ compatible = "st,comms-irb";
+ reg = <0xfe518000 0x234>;
+ interrupts = <0 203 0>;
+ rx-mode = "infrared";
+ };
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 11e84bc..557afc5 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -322,4 +322,14 @@ config IR_GPIO_CIR
To compile this driver as a module, choose M here: the module will
be called gpio-ir-recv.
+config RC_ST
+ tristate "ST remote control receiver"
+ depends on ARCH_STI && RC_CORE
+ help
+Say Y here if you want support for ST remote control driver
+which allows both IR and UHF RX.
+The driver passes raw pluse and space information to the LIRC decoder.
+
+If you're not sure, select N here.
+
endif #RC_DEVICES
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 56bacf0..f4eb32c 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o
obj-$(CONFIG_IR_GPIO_CIR) += gpio-ir-recv.o
obj-$(CONFIG_IR_IGUANA) += iguanair.o
obj-$(CONFIG_IR_TTUSBIR) += ttusbir.o
+obj-$(CONFIG_RC_ST) += st_rc.o
diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
new file mode 100644
index 000..e2dad9c
--- /dev/null
+++ b/drivers/media/rc/st_rc.c
@@ -0,0 +1,396 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics Limited
+ * Author: Srinivas Kandagatla
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct st_rc_device {
+ struct device *dev;
+ int irq;
+ int irq_wake;
+ struct clk *
Re: [PATCH 00/51] DMA mask changes
On Thu, Sep 26, 2013 at 10:23:08PM +0200, Rafał Miłecki wrote: > 2013/9/19 Russell King - ARM Linux : > > This email is only being sent to the mailing lists in question, not to > > anyone personally. The list of individuals is far to great to do that. > > I'm hoping no mailing lists reject the patches based on the number of > > recipients. > > Huh, I think it was enough to send only 3 patches to the b43-dev@. Like: > [PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks > [PATCH 14/51] DMA-API: net: b43: (...) > [PATCH 15/51] DMA-API: net: b43legacy: (...) > ;) > > I believe Joe has some nice script for doing it that way. When fixing > some coding style / formatting, he sends only related patches to the > given ML. If I did that, then the mailing lists would not get the first patch, because almost none of the lists would be referred to by patch 1. Moreover, people complain when they don't have access to the full patch series - they assume patches are missing for some reason, and they ask for the rest of the series. -- 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: Need help with AverMedia306 driver on linux system.
:) Also, by the time I redo the patch, You must have seen how i have reached this point, I have actually started by insering the module with card=39 as an option, So you can for now, add theses line to gpunk@gpunk-Aspire-8930:~$cat /etc/modprobe.d/video-tv.conf options tuner-xc2028 firmware_name=xc3028-v27.fw options cx23885 card=39 I called my file this way ... it's arbitrary, please check the man modprobe of your ditribution/kernel . Best regards Rémi > Le 21 septembre 2013 à 19:43, "ad...@tydaikho.com" >a écrit : > > > Hi Remi! > I got my card but i have not finish to install driver. I follow your patch on >linuxtv.org but i am not successful. it makes some mistake: "malform" and >"hunk" errors. > === > root@ty-debian:/usr/local/src/linuxtv# patch -p1 < ./cx23885.patch > can't find file to patch at input line 3 > Perhaps you used the wrong -p or --strip option? > The text leading up to this was: > -- > |--- drivers/media/pci/cx23885/cx23885.h 2013-03-25 05:45:50.0 +0100 > |+++ drivers/media/pci/cx23885/cx23885.h 2013-08-21 13:55:20.010625134 >+0200 > -- > File to patch: ./drivers/media/pci/cx23885/cx23885.h > > patching file ./drivers/media/pci/cx23885/cx23885.h > patch: malformed patch at line 4: #define CX23885_BOARD_PROF_8000 > 37 > == > root@ty-debian:/usr/local/src/linuxtv# patch -p1 < ./cx23885-video.patch > can't find file to patch at input line 4 > Perhaps you used the wrong -p or --strip option? > The text leading up to this was: > -- > |--- drivers/media/pci/cx23885/cx23885-video.c 2013-08-02 >05:45:59.0 +0200 > |+++ drivers/media/pci/cx23885/cx23885-video.c2013-08-21 >13:55:20.017625046 > |+0200 > -- > File to patch: ./drivers/media/pci/cx23885/cx23885-video.c > patching file ./drivers/media/pci/cx23885/cx23885-video.c > Hunk #1 FAILED at 511. > Hunk #2 FAILED at 1888. > 2 out of 2 hunks FAILED -- saving rejects to file >./drivers/media/pci/cx23885/cx23885-video.c.rej > > root@ty-debian:/usr/local/src/linuxtv# patch -p1 < ./cx23885-cards.patch > can't find file to patch at input line 4 > Perhaps you used the wrong -p or --strip option? > The text leading up to this was: > -- > |--- drivers/media/pci/cx23885/cx23885-cards.c 2012-12-28 >00:04:05.0 +0100 > |+++ drivers/media/pci/cx23885/cx23885-cards.c2013-08-21 >14:15:54.173195979 > |+0200 > -- > File to patch: ./drivers/media/pci/cx23885/cx23885-cards.c > patching file ./drivers/media/pci/cx23885/cx23885-cards.c > Hunk #1 FAILED at 604. > Hunk #2 FAILED at 841. > Hunk #3 FAILED at 1069. > Hunk #4 FAILED at 1394. > Hunk #5 FAILED at 1623. > Hunk #6 FAILED at 1758. > 6 out of 6 hunks FAILED -- saving rejects to file >./drivers/media/pci/cx23885/cx23885-cards.c.rej > === > > If you don't mind, i need your support to get my card works well. Thank you >very much! > > > -- > Yahoo: minhhoang1004 + Google: minhhoang1004 + Skype: minhhoang1004 + MSN: >tydaikho > -- > > (http://tydaikho.com) VS (http://vnluser.net) -- 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
