Message ID | 20110418225538.155F.B41FCDD0@s9.dion.ne.jp (mailing list archive) |
---|---|
State | Not Applicable |
Headers | show |
Hello Akira On Mon, 18 Apr 2011, Akira Tsukamoto wrote: > Hello Guennadi, > > > > Sorry for the sudden email but may I have your advice on soc_camera? > > > You can have a look at another driver > > for a Sharp camera sensor: > > > > drivers/media/video/rj54n1cb0c.c > > > > and at its platform glue in arch/sh/boards/mach-kfr2r09/setup.c, there you > > find > > > > struct platform_device kfr2r09_camera > > > > which links to > > > > struct soc_camera_link rj54n1_link > > > > The ARM cpu is made by Renesas. > > > > Then, perhaps, something similar to > > > > arch/arm/mach-shmobile/board-ap4evb.c > > Thank you for your suggestion, I was able to bind my driver > with soc_camera(I believe...). > > I attached my draft driver files at the end of this email > for any suggestions. Thanks for attaching your sources. > In the beginning, I would like to explain the fundamental > information. > > 1) 2 megapixel camera module is connected to > the ARM board, Renesas ag5evm, through I2C. > arch/arm/mach-shmobile/board-ag5evm.c > 2) The camera module is connected to CEU on the ag5evm. > 3) I followed your instruction to bind the camera > sensor driver to soc_camera as attached and > builds and boots fine. > 4) I have not received the data sheet from the vender > for the camera yet ;) > 5) But I have the prototype board on my hand. > 6) I can not implement the details of the driver without > the data sheet but would like to start implement the > outline, so I could save my time while I am waiting > for the data sheet. > > Also, > I would like to know, if I need to bind to > sh_mobile_ceu_camera.c > too, and how, because the camera is connected to CEU. Yes, you do. Look at the board-ap4evb and board-mackerel files at everything, containing the "ceu" string in it. The former configures a serially connected camera sensor over the MIPI CSI-2 bus, the latter over the parallel interface. I haven't reviewed your sources in detail, just two comments, regarding something, that caught my eye: > (I never knew the word CEU until I started to work with > this project...) > > Thank you and best regards, > > Akira [snip] > --- linux_kernel_bsp/arch/arm/mach-shmobile/board-ag5evm.c 2011-03-22 12:30:14.000000000 +0900 > +++ linux_kernel/arch/arm/mach-shmobile/board-ag5evm.c 2011-04-18 14:39:20.000000000 +0900 > @@ -59,6 +59,7 @@ > > #include <sound/sh_fsi.h> > #include <video/sh_mobile_lcdc.h> > +#include <media/soc_camera.h> > > static struct r8a66597_platdata usb_host_data = { > .on_chip = 1, > @@ -317,11 +318,38 @@ static struct platform_device fsi_device > }, > }; > > +static struct i2c_board_info rj65na20_info = { > + I2C_BOARD_INFO("rj65na20", 0x40), > +}; > + > +struct soc_camera_link rj65na20_link = { > + .bus_id = 0, > + .board_info = &rj65na20_info, > + .i2c_adapter_id = 0, > + .module_name = "rj65na20", > +}; > + > +static struct platform_device rj65na20_camera = { > + .name = "soc-camera-pdrv-2M", This name has to match with what's advertised in drivers/media/video/soc_camera.c, namely "soc-camera-pdrv" > + .id = 0, > + .dev = { > + .platform_data = &rj65na20_link, > + }, > +}; > + > static struct i2c_board_info i2c0_devices[] = { > { > I2C_BOARD_INFO("ag5evm_ts", 0x20), > .irq = pint2irq(12), /* PINTC3 */ > }, > + /* 2M camera */ > + { > + I2C_BOARD_INFO("rj65na20", 0x40), > + }, No, you do not have to include this here, the sensor must not be registered automatically during the board initialisation. Thanks Guennadi > }; > > static struct i2c_board_info i2c1_devices[] = { > @@ -548,6 +576,8 @@ static struct platform_device *ag5evm_de > > &usb_mass_storage_device, > &android_usb_device, > + > + &rj65na20_camera, > }; > > static struct map_desc ag5evm_io_desc[] __initdata = { > @@ -748,6 +778,7 @@ static void __init ag5evm_init(void) > struct clk *sub_clk = clk_get(NULL, "sub_clk"); > struct clk *extal2_clk = clk_get(NULL, "extal2"); > struct clk *fsia_clk = clk_get(NULL, "fsia_clk"); > + struct clk *vck1_clk = clk_get(NULL, "vck1_clk"); > clk_set_parent(sub_clk, extal2_clk); > > __raw_writel(__raw_readl(SUBCKCR) & ~(1<<9), SUBCKCR); > @@ -853,6 +884,43 @@ static void __init ag5evm_init(void) > __raw_writel(0x2a8b9111, DSI1PHYCR); > clk_enable(clk_get(NULL, "dsi-tx")); > > + /* 2M camera */ > + gpio_request(GPIO_PORT44, NULL); > + gpio_direction_output(GPIO_PORT44, 0); > + udelay(10); > + gpio_set_value(GPIO_PORT44, 1); > + > /* Unreset LCD Panel */ > gpio_request(GPIO_PORT217, NULL); > gpio_direction_output(GPIO_PORT217, 0); > > -- > Akira Tsukamoto > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Guennadi, > > Also, > > I would like to know, if I need to bind to > > sh_mobile_ceu_camera.c > > too, and how, because the camera is connected to CEU. > > Yes, you do. Look at the board-ap4evb and board-mackerel files at > everything, containing the "ceu" string in it. The former configures a > serially connected camera sensor over the MIPI CSI-2 bus, the latter over > the parallel interface. Thank you, I will definitely look into those files about ceu. > > +static struct platform_device rj65na20_camera = { > > + .name = "soc-camera-pdrv-2M", > > This name has to match with what's advertised in > drivers/media/video/soc_camera.c, namely "soc-camera-pdrv" I will fix it. > > static struct i2c_board_info i2c0_devices[] = { > > { > > I2C_BOARD_INFO("ag5evm_ts", 0x20), > > .irq = pint2irq(12), /* PINTC3 */ > > }, > > + /* 2M camera */ > > + { > > + I2C_BOARD_INFO("rj65na20", 0x40), > > + }, > > No, you do not have to include this here, the sensor must not be registered > automatically during the board initialisation. Thank you for your review. It is already midnight in Tokyo, so I will try it first in the morning tomorrow. With kind regards, FYI: > the ARM board, Renesas, through I2C. > arch/arm/mach-shmobile/board-ag5evm.c This file is temporal situation just for me to start with. Akira
Hello Guennadi, > > > static struct i2c_board_info i2c0_devices[] = { > > > { > > > I2C_BOARD_INFO("ag5evm_ts", 0x20), > > > .irq = pint2irq(12), /* PINTC3 */ > > > }, > > > + /* 2M camera */ > > > + { > > > + I2C_BOARD_INFO("rj65na20", 0x40), > > > + }, > > > > No, you do not have to include this here, the sensor must not be registered > > automatically during the board initialisation. I have one more question before sleeping :) The camera module needs to be initialized by writing values to the registers. Do I need to write init function at the following? static const struct v4l2_subdev_core_ops rj65na20_core_ops = { .reset = rj65na20_reset, [snip] } With kind regards, Akira
On Tue, 19 Apr 2011, Akira Tsukamoto wrote: > Hello Guennadi, > > > > > static struct i2c_board_info i2c0_devices[] = { > > > > { > > > > I2C_BOARD_INFO("ag5evm_ts", 0x20), > > > > .irq = pint2irq(12), /* PINTC3 */ > > > > }, > > > > + /* 2M camera */ > > > > + { > > > > + I2C_BOARD_INFO("rj65na20", 0x40), > > > > + }, > > > > > > No, you do not have to include this here, the sensor must not be registered > > > automatically during the board initialisation. > > I have one more question before sleeping :) > > The camera module needs to be initialized by writing values to the registers. > Do I need to write init function at the following? > > static const struct v4l2_subdev_core_ops rj65na20_core_ops = { > .reset = rj65na20_reset, > [snip] > } AFAICS neither soc_camera.c, nor sh_mobile_ceu_camera.c call the .reset subdevice core method, so, no, at the moment implementing it wouldn't produce any result. Either you have to choose one of the methods, that are currently called, or you have to add a call to .reset() as required. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> On Tue, 19 Apr 2011, Akira Tsukamoto wrote: > >> Hello Guennadi, >> >> > > > static struct i2c_board_info i2c0_devices[] = { >> > > > { >> > > > I2C_BOARD_INFO("ag5evm_ts", 0x20), >> > > > .irq = pint2irq(12), /* PINTC3 */ >> > > > }, >> > > > + /* 2M camera */ >> > > > + { >> > > > + I2C_BOARD_INFO("rj65na20", 0x40), >> > > > + }, >> > > >> > > No, you do not have to include this here, the sensor must not be >> registered >> > > automatically during the board initialisation. >> >> I have one more question before sleeping :) >> >> The camera module needs to be initialized by writing values to the >> registers. >> Do I need to write init function at the following? >> >> static const struct v4l2_subdev_core_ops rj65na20_core_ops = { >> .reset = rj65na20_reset, >> [snip] >> } > > AFAICS neither soc_camera.c, nor sh_mobile_ceu_camera.c call the .reset > subdevice core method, so, no, at the moment implementing it wouldn't > produce any result. Either you have to choose one of the methods, that are > currently called, or you have to add a call to .reset() as required. I don't really like the use of reset for this. The reset op is a pretty poorly defined op. There is a registration op as well these days that might be better suited for this (see struct v4l2_subdev_internal_ops). Regards, Hans > > Thanks > Guennadi > --- > Guennadi Liakhovetski, Ph.D. > Freelance Open-Source Software Developer > http://www.open-technology.de/ > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Hans, > >> The camera module needs to be initialized by writing values to the > >> registers. > >> Do I need to write init function at the following? > >> > >> static const struct v4l2_subdev_core_ops rj65na20_core_ops = { > >> .reset = rj65na20_reset, > >> [snip] > >> } > > > > AFAICS neither soc_camera.c, nor sh_mobile_ceu_camera.c call the .reset > > subdevice core method, so, no, at the moment implementing it wouldn't > > produce any result. Either you have to choose one of the methods, that are > > currently called, or you have to add a call to .reset() as required. > > I don't really like the use of reset for this. The reset op is a pretty > poorly defined op. There is a registration op as well these days that > might be better suited for this (see struct v4l2_subdev_internal_ops). May I ask to guide me how to implement: struct v4l2_subdev_internal_ops { int (*registered)(struct v4l2_subdev *sd); void (*unregistered)(struct v4l2_subdev *sd); }; for the initializing camera module by writing values to the register? With kind regards, Akira
--- linux_kernel_bsp/arch/arm/mach-shmobile/board-ag5evm.c 2011-03-22 12:30:14.000000000 +0900 +++ linux_kernel/arch/arm/mach-shmobile/board-ag5evm.c 2011-04-18 14:39:20.000000000 +0900 @@ -59,6 +59,7 @@ #include <sound/sh_fsi.h> #include <video/sh_mobile_lcdc.h> +#include <media/soc_camera.h> static struct r8a66597_platdata usb_host_data = { .on_chip = 1, @@ -317,11 +318,38 @@ static struct platform_device fsi_device }, }; +static struct i2c_board_info rj65na20_info = { + I2C_BOARD_INFO("rj65na20", 0x40), +}; + +struct soc_camera_link rj65na20_link = { + .bus_id = 0, + .board_info = &rj65na20_info, + .i2c_adapter_id = 0, + .module_name = "rj65na20", +}; + +static struct platform_device rj65na20_camera = { + .name = "soc-camera-pdrv-2M", + .id = 0, + .dev = { + .platform_data = &rj65na20_link, + }, +}; + static struct i2c_board_info i2c0_devices[] = { { I2C_BOARD_INFO("ag5evm_ts", 0x20), .irq = pint2irq(12), /* PINTC3 */ }, + /* 2M camera */ + { + I2C_BOARD_INFO("rj65na20", 0x40), + }, }; static struct i2c_board_info i2c1_devices[] = { @@ -548,6 +576,8 @@ static struct platform_device *ag5evm_de &usb_mass_storage_device, &android_usb_device,