RE: [PATCH 1/3] Move FIMD register headers to include/video/
Hello, On Tuesday, July 31, 2012 2:48 AM Jingoo Han wrote: On Monday, July 30, 2012 8:16 PM, Leela Krishna Amudala wrote: Hello Jingoo Han, On Mon, Jul 30, 2012 at 2:23 PM, Jingoo Han jg1@samsung.com wrote: On Monday, July 30, 2012 5:45 PM, Leela Krishna Amudala wrote: Moved the contents of regs-fb-v4.h and regs-fb.h from arch side to include/video/samsung_fimd.h Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 --- arch/arm/plat-samsung/include/plat/regs-fb.h| 403 - include/video/samsung_fimd.h| 533 +++ 3 files changed, 533 insertions(+), 562 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h create mode 100644 include/video/samsung_fimd.h +*/ + +/*FIMD V8 REG OFFSET */ +#define FIMD_V8_VIDTCON0 (0x20010) +#define FIMD_V8_VIDTCON1 (0x20014) +#define FIMD_V8_VIDTCON2 (0x20018) +#define FIMD_V8_VIDTCON3 (0x2001C) +#define FIMD_V8_VIDCON1 (0x20004) How about using soc_is_exynos5250()? +#define VIDTCON0 (soc_is_exynos5250() ? \ + (0x20010) : (0x10)) In this case, the FIMD driver does not need to change. Also, one binary is available. Please don't mix two methods of runtime detection. FIMD driver (s3c-fb) already has runtime hw detection based on platform device id. Adding such detection for exynos5 to DRM FIMD driver should not be a big issue too. Best regards -- Marek Szyprowski Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Move FIMD register headers to include/video/
Hi, On Tuesday 31 of July 2012 at 09:47:57, Jingoo Han wrote: On Monday, July 30, 2012 8:16 PM, Leela Krishna Amudala wrote: Hello Jingoo Han, On Mon, Jul 30, 2012 at 2:23 PM, Jingoo Han jg1@samsung.com wrote: On Monday, July 30, 2012 5:45 PM, Leela Krishna Amudala wrote: Moved the contents of regs-fb-v4.h and regs-fb.h from arch side to include/video/samsung_fimd.h Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 --- arch/arm/plat-samsung/include/plat/regs-fb.h| 403 - include/video/samsung_fimd.h| 533 +++ 3 files changed, 533 insertions(+), 562 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h create mode 100644 include/video/samsung_fimd.h +*/ + +/*FIMD V8 REG OFFSET */ +#define FIMD_V8_VIDTCON0 (0x20010) +#define FIMD_V8_VIDTCON1 (0x20014) +#define FIMD_V8_VIDTCON2 (0x20018) +#define FIMD_V8_VIDTCON3 (0x2001C) +#define FIMD_V8_VIDCON1 (0x20004) How about using soc_is_exynos5250()? +#define VIDTCON0 (soc_is_exynos5250() ? \ + (0x20010) : (0x10)) In this case, the FIMD driver does not need to change. Also, one binary is available. This would look good indeed, but there are some drawbacks: - it would not scale nicely for future SoCs using the new FIMD - it would add the overhead of checking SoC ID for every access to affected registers (at least 1 load, 1 AND, 1 compare, 1 move and 1 conditional OR, so 5 instructions in total, possibly even more, as opposed to a single load from a variant struct). I would stay with the way used in s3c-fb driver, using variant structs describing FIMD revisions. Best regards, Tomasz Figa Best regards, Jingoo Han CC'ed Marek. To Leela Krishna Amudala, Don't add these definitions for FIMD_V8_xxx registers, which arenot related to current regs-fb-v4.h and regs-fb.h. Just move and merge regs-fb-v4.h and regs-fb.h to one header file, not add new definitions. If you want to add these definitions, please make new patch for this. Will do it in the suggested way, Also, #define FIMD_V8_xxx is ugly. I think that there is better way. Please, find other way. I used FIMD_V8_xxx instead of EXYNOS5_FIMD_*, because in future, there is a possibility that version 8 FIMD can be used in other application processors also. Thanks for reviewing the patch. Best Wishes, Leela Krishna. -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-fbdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation
Hi Guennadi, On Tuesday 31 July 2012 13:14:13 Guennadi Liakhovetski wrote: On Tue, 31 Jul 2012, Laurent Pinchart wrote: On Tuesday 31 July 2012 11:56:44 Guennadi Liakhovetski wrote: On Thu, 26 Jul 2012, Laurent Pinchart wrote: On Wednesday 18 July 2012 11:18:33 Sylwester Nawrocki wrote: On 07/16/2012 11:42 AM, Guennadi Liakhovetski wrote: On Fri, 25 May 2012, Sylwester Nawrocki wrote: The driver initializes all board related properties except the s_power() callback to board code. The platforms that require this callback are not supported by this driver yet for CONFIG_OF=y. Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Bartlomiej Zolnierkiewiczb.zolnier...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- .../bindings/camera/samsung-s5k6aafx.txt | 57 + drivers/media/video/s5k6aa.c | 129 ++-- 2 files changed, 146 insertions(+), 40 deletions(-) create mode 100644 Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt diff --git a/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt new file mode 100644 index 000..6685a9c --- /dev/null +++ b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt @@ -0,0 +1,57 @@ +Samsung S5K6AAFX camera sensor +-- + +Required properties: + +- compatible : samsung,s5k6aafx; +- reg : base address of the device on I2C bus; You said you ended up putting your sensors outside of I2C busses, is this one of changes, that are present in your git-tree but not in this series? No, I must have been not clear enough on that. Our idea was to keep I2C slave device nodes as an I2C controller's child nodes, according to the current convention. The 'sensor' nodes (the 'camera''s children) would only contain a phandle to a respective I2C slave node. This implies that we cannot access I2C bus in I2C client's device probe() callback. An actual H/W access could begin only from within and after invocation of v4l2_subdev .registered callback.. That's how I've envisioned the DT bindings for sensors as well, this sounds good. The real challenge will be to get hold of the subdev to register it without race conditions. Hrm... That's how early pre-subdev versions of soc-camera used to work, that's where all the device_video_probe() functions come from. But then we switched to dynamic i2c device registration. Do we want to switch all drivers back now?... Couldn't we temporarily use references from subdevs to hosts until the clock API is available? I don't think that requires a reference from subdevs to hosts in the DT. The subdev will need the host to be probed before a clock can be available so you won't be able to access the hardware in the probe() function in the generic case. You will need to wait until the registered() subdev operation is called, at which point the host can be accessed through the v4l2_device. Sure, I understand, but that's exactly what we wanted to avoid - succeeding client's i2c .probe() without even touching the hardware. But should we allow host probe() to succeed if the sensor isn't present ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation
On Tue, 31 Jul 2012, Laurent Pinchart wrote: Hi Guennadi, On Tuesday 31 July 2012 13:14:13 Guennadi Liakhovetski wrote: On Tue, 31 Jul 2012, Laurent Pinchart wrote: On Tuesday 31 July 2012 11:56:44 Guennadi Liakhovetski wrote: On Thu, 26 Jul 2012, Laurent Pinchart wrote: On Wednesday 18 July 2012 11:18:33 Sylwester Nawrocki wrote: On 07/16/2012 11:42 AM, Guennadi Liakhovetski wrote: On Fri, 25 May 2012, Sylwester Nawrocki wrote: The driver initializes all board related properties except the s_power() callback to board code. The platforms that require this callback are not supported by this driver yet for CONFIG_OF=y. Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Bartlomiej Zolnierkiewiczb.zolnier...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- .../bindings/camera/samsung-s5k6aafx.txt | 57 + drivers/media/video/s5k6aa.c | 129 ++-- 2 files changed, 146 insertions(+), 40 deletions(-) create mode 100644 Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt diff --git a/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt new file mode 100644 index 000..6685a9c --- /dev/null +++ b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt @@ -0,0 +1,57 @@ +Samsung S5K6AAFX camera sensor +-- + +Required properties: + +- compatible : samsung,s5k6aafx; +- reg : base address of the device on I2C bus; You said you ended up putting your sensors outside of I2C busses, is this one of changes, that are present in your git-tree but not in this series? No, I must have been not clear enough on that. Our idea was to keep I2C slave device nodes as an I2C controller's child nodes, according to the current convention. The 'sensor' nodes (the 'camera''s children) would only contain a phandle to a respective I2C slave node. This implies that we cannot access I2C bus in I2C client's device probe() callback. An actual H/W access could begin only from within and after invocation of v4l2_subdev .registered callback.. That's how I've envisioned the DT bindings for sensors as well, this sounds good. The real challenge will be to get hold of the subdev to register it without race conditions. Hrm... That's how early pre-subdev versions of soc-camera used to work, that's where all the device_video_probe() functions come from. But then we switched to dynamic i2c device registration. Do we want to switch all drivers back now?... Couldn't we temporarily use references from subdevs to hosts until the clock API is available? I don't think that requires a reference from subdevs to hosts in the DT. The subdev will need the host to be probed before a clock can be available so you won't be able to access the hardware in the probe() function in the generic case. You will need to wait until the registered() subdev operation is called, at which point the host can be accessed through the v4l2_device. Sure, I understand, but that's exactly what we wanted to avoid - succeeding client's i2c .probe() without even touching the hardware. But should we allow host probe() to succeed if the sensor isn't present ? I think we should, yes. The host hardware is there and functional - whether or not all or some of the clients are failing. Theoretically clients can also be hot-plugged. Whether and how many video device nodes we create, that's a different question. 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-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation
Hi Guennadi, On Tuesday 31 July 2012 13:29:55 Guennadi Liakhovetski wrote: On Tue, 31 Jul 2012, Laurent Pinchart wrote: On Tuesday 31 July 2012 13:14:13 Guennadi Liakhovetski wrote: On Tue, 31 Jul 2012, Laurent Pinchart wrote: On Tuesday 31 July 2012 11:56:44 Guennadi Liakhovetski wrote: On Thu, 26 Jul 2012, Laurent Pinchart wrote: On Wednesday 18 July 2012 11:18:33 Sylwester Nawrocki wrote: On 07/16/2012 11:42 AM, Guennadi Liakhovetski wrote: On Fri, 25 May 2012, Sylwester Nawrocki wrote: The driver initializes all board related properties except the s_power() callback to board code. The platforms that require this callback are not supported by this driver yet for CONFIG_OF=y. Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Bartlomiej Zolnierkiewiczb.zolnier...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- .../bindings/camera/samsung-s5k6aafx.txt | 57 + drivers/media/video/s5k6aa.c | 129 ++-- 2 files changed, 146 insertions(+), 40 deletions(-) create mode 100644 Documentation/devicetree/bindings/camera/samsung-s5k6aafx.t xt diff --git a/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.t xt b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.t xt new file mode 100644 index 000..6685a9c --- /dev/null +++ b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.t xt @@ -0,0 +1,57 @@ +Samsung S5K6AAFX camera sensor +-- + +Required properties: + +- compatible : samsung,s5k6aafx; +- reg : base address of the device on I2C bus; You said you ended up putting your sensors outside of I2C busses, is this one of changes, that are present in your git- tree but not in this series? No, I must have been not clear enough on that. Our idea was to keep I2C slave device nodes as an I2C controller's child nodes, according to the current convention. The 'sensor' nodes (the 'camera''s children) would only contain a phandle to a respective I2C slave node. This implies that we cannot access I2C bus in I2C client's device probe() callback. An actual H/W access could begin only from within and after invocation of v4l2_subdev .registered callback.. That's how I've envisioned the DT bindings for sensors as well, this sounds good. The real challenge will be to get hold of the subdev to register it without race conditions. Hrm... That's how early pre-subdev versions of soc-camera used to work, that's where all the device_video_probe() functions come from. But then we switched to dynamic i2c device registration. Do we want to switch all drivers back now?... Couldn't we temporarily use references from subdevs to hosts until the clock API is available? I don't think that requires a reference from subdevs to hosts in the DT. The subdev will need the host to be probed before a clock can be available so you won't be able to access the hardware in the probe() function in the generic case. You will need to wait until the registered() subdev operation is called, at which point the host can be accessed through the v4l2_device. Sure, I understand, but that's exactly what we wanted to avoid - succeeding client's i2c .probe() without even touching the hardware. But should we allow host probe() to succeed if the sensor isn't present ? I think we should, yes. The host hardware is there and functional - whether or not all or some of the clients are failing. Theoretically clients can also be hot-plugged. Whether and how many video device nodes we create, that's a different question. I think I can agree with you on this (although I could change my mind if this architecture turns out to result in unsolvable technical issues). That will involve a lot of work though. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 0/5] arm: samsung: Move FIMD headers to include/video/
This patchset moves the contents of regs-fb-v4.h and regs-fb.h from arch side to include/video/samsung_fimd.h This patchset is created and rebased against master branch of torvalds tree. Tested on smdk5250 board, build tested for other boards. Changes from version 1: - Split the patches as per Sylwester comments - Changed FIMD_V8_xxx macro to EXYNOS5_xxx Leela Krishna Amudala (5): include/video: Add samsung FIMD register header include/video: Add Exynos5 specific FIMD register offsets arm: samsung: Include the modified FIMD header file driver: Include the modified FIMD header file arm: samsung: delete frame buffer header files from platform arch/arm/mach-exynos/mach-nuri.c |2 +- arch/arm/mach-exynos/mach-origen.c |2 +- arch/arm/mach-exynos/mach-smdk4x12.c |2 +- arch/arm/mach-exynos/mach-smdkv310.c |2 +- arch/arm/mach-exynos/mach-universal_c210.c |2 +- arch/arm/mach-exynos/setup-fimd0.c |2 +- arch/arm/mach-s3c24xx/mach-smdk2416.c |2 +- arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- arch/arm/mach-s3c64xx/mach-hmt.c |2 +- arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- arch/arm/mach-s3c64xx/mach-ncp.c |2 +- arch/arm/mach-s3c64xx/mach-real6410.c |2 +- arch/arm/mach-s3c64xx/mach-smartq5.c |2 +- arch/arm/mach-s3c64xx/mach-smartq7.c |2 +- arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6440.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6450.c |2 +- arch/arm/mach-s5pc100/mach-smdkc100.c |2 +- arch/arm/mach-s5pv210/mach-aquila.c|2 +- arch/arm/mach-s5pv210/mach-goni.c |2 +- arch/arm/mach-s5pv210/mach-smdkv210.c |2 +- arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +- drivers/video/s3c-fb.c |2 +- .../plat/regs-fb.h = include/video/samsung_fimd.h | 152 +-- 26 files changed, 165 insertions(+), 194 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h rename arch/arm/plat-samsung/include/plat/regs-fb.h = include/video/samsung_fimd.h (74%) -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 1/5] include/video: Add samsung FIMD register header
This patch copies the contents from regs-fb-v4.h and regs-fb.h to include/video/samsung_fimd.h Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- include/video/samsung_fimd.h | 526 ++ 1 files changed, 526 insertions(+), 0 deletions(-) create mode 100644 include/video/samsung_fimd.h diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h new file mode 100644 index 000..e979f42 --- /dev/null +++ b/include/video/samsung_fimd.h @@ -0,0 +1,526 @@ +/* include/video/samsung_fimd.h + * + * Copyright 2008 Openmoko, Inc. + * Copyright 2008 Simtec Electronics + * http://armlinux.simtec.co.uk/ + * Ben Dooks b...@simtec.co.uk + * + * S3C Platform - new-style fimd and framebuffer register definitions + * + * This is the register set for the fimd and new style framebuffer interface + * found from the S3C2443 onwards into the S3C2416, S3C2450 and the + * S3C64XX series such as the S3C6400 and S3C6410. + * + * The file does not contain the cpu specific items which are based on + * whichever architecture is selected, it only contains the core of the + * register set. See mach/regs-fb.h to get the specifics. + * + * 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. +*/ + +/* VIDCON0 */ + +#define VIDCON0(0x00) +#define VIDCON0_INTERLACE (1 29) +#define VIDCON0_VIDOUT_MASK(0x3 26) +#define VIDCON0_VIDOUT_SHIFT (26) +#define VIDCON0_VIDOUT_RGB (0x0 26) +#define VIDCON0_VIDOUT_TV (0x1 26) +#define VIDCON0_VIDOUT_I80_LDI0(0x2 26) +#define VIDCON0_VIDOUT_I80_LDI1(0x3 26) + +#define VIDCON0_L1_DATA_MASK (0x7 23) +#define VIDCON0_L1_DATA_SHIFT (23) +#define VIDCON0_L1_DATA_16BPP (0x0 23) +#define VIDCON0_L1_DATA_18BPP16(0x1 23) +#define VIDCON0_L1_DATA_18BPP9 (0x2 23) +#define VIDCON0_L1_DATA_24BPP (0x3 23) +#define VIDCON0_L1_DATA_18BPP (0x4 23) +#define VIDCON0_L1_DATA_16BPP8 (0x5 23) + +#define VIDCON0_L0_DATA_MASK (0x7 20) +#define VIDCON0_L0_DATA_SHIFT (20) +#define VIDCON0_L0_DATA_16BPP (0x0 20) +#define VIDCON0_L0_DATA_18BPP16(0x1 20) +#define VIDCON0_L0_DATA_18BPP9 (0x2 20) +#define VIDCON0_L0_DATA_24BPP (0x3 20) +#define VIDCON0_L0_DATA_18BPP (0x4 20) +#define VIDCON0_L0_DATA_16BPP8 (0x5 20) + +#define VIDCON0_PNRMODE_MASK (0x3 17) +#define VIDCON0_PNRMODE_SHIFT (17) +#define VIDCON0_PNRMODE_RGB(0x0 17) +#define VIDCON0_PNRMODE_BGR(0x1 17) +#define VIDCON0_PNRMODE_SERIAL_RGB (0x2 17) +#define VIDCON0_PNRMODE_SERIAL_BGR (0x3 17) + +#define VIDCON0_CLKVALUP (1 16) +#define VIDCON0_CLKVAL_F_MASK (0xff 6) +#define VIDCON0_CLKVAL_F_SHIFT (6) +#define VIDCON0_CLKVAL_F_LIMIT (0xff) +#define VIDCON0_CLKVAL_F(_x) ((_x) 6) +#define VIDCON0_VLCKFREE (1 5) +#define VIDCON0_CLKDIR (1 4) + +#define VIDCON0_CLKSEL_MASK(0x3 2) +#define VIDCON0_CLKSEL_SHIFT (2) +#define VIDCON0_CLKSEL_HCLK(0x0 2) +#define VIDCON0_CLKSEL_LCD (0x1 2) +#define VIDCON0_CLKSEL_27M (0x3 2) + +#define VIDCON0_ENVID (1 1) +#define VIDCON0_ENVID_F(1 0) + +#define VIDCON1(0x04) +#define VIDCON1_LINECNT_MASK (0x7ff 16) +#define VIDCON1_LINECNT_SHIFT (16) +#define VIDCON1_LINECNT_GET(_v)(((_v) 16) 0x7ff) +#define VIDCON1_VSTATUS_MASK (0x3 13) +#define VIDCON1_VSTATUS_SHIFT (13) +#define VIDCON1_VSTATUS_VSYNC (0x0 13) +#define VIDCON1_VSTATUS_BACKPORCH (0x1 13) +#define VIDCON1_VSTATUS_ACTIVE (0x2 13) +#define VIDCON1_VSTATUS_FRONTPORCH (0x0 13) +#define VIDCON1_VCLK_MASK (0x3 9) +#define VIDCON1_VCLK_HOLD (0x0 9) +#define VIDCON1_VCLK_RUN (0x1 9) + +#define VIDCON1_INV_VCLK (1 7) +#define VIDCON1_INV_HSYNC (1 6) +#define VIDCON1_INV_VSYNC (1 5) +#define VIDCON1_INV_VDEN (1 4) + +/* VIDCON2 */ + +#define VIDCON2
[PATCH V2 2/5] include/video: Add Exynos5 specific FIMD register offsets
Exynos5 has VIDTCON and VIDCON registers at different offsets from the previous SOCs. Hence, adding the macros. Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- include/video/samsung_fimd.h |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h index e979f42..820f190 100644 --- a/include/video/samsung_fimd.h +++ b/include/video/samsung_fimd.h @@ -524,3 +524,10 @@ * 1110-none- -none- -none- -none--none- * -none- -none- -none- -none--none- */ + +/*EXYNOS5 FIMD REG OFFSET */ +#define EXYNOS5_VIDTCON0 (0x20010) +#define EXYNOS5_VIDTCON1 (0x20014) +#define EXYNOS5_VIDTCON2 (0x20018) +#define EXYNOS5_VIDTCON3 (0x2001C) +#define EXYNOS5_VIDCON1(0x20004) -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 3/5] arm: samsung: Include the modified FIMD header file
The fimd register headers have been moved to include/video/ hence, modifying the machine files accordingly. Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- arch/arm/mach-exynos/mach-nuri.c |2 +- arch/arm/mach-exynos/mach-origen.c |2 +- arch/arm/mach-exynos/mach-smdk4x12.c |2 +- arch/arm/mach-exynos/mach-smdkv310.c |2 +- arch/arm/mach-exynos/mach-universal_c210.c |2 +- arch/arm/mach-exynos/setup-fimd0.c |2 +- arch/arm/mach-s3c24xx/mach-smdk2416.c |2 +- arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- arch/arm/mach-s3c64xx/mach-hmt.c |2 +- arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- arch/arm/mach-s3c64xx/mach-ncp.c |2 +- arch/arm/mach-s3c64xx/mach-real6410.c |2 +- arch/arm/mach-s3c64xx/mach-smartq5.c |2 +- arch/arm/mach-s3c64xx/mach-smartq7.c |2 +- arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6440.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6450.c |2 +- arch/arm/mach-s5pc100/mach-smdkc100.c |2 +- arch/arm/mach-s5pv210/mach-aquila.c|2 +- arch/arm/mach-s5pv210/mach-goni.c |2 +- arch/arm/mach-s5pv210/mach-smdkv210.c |2 +- 22 files changed, 22 insertions(+), 22 deletions(-) diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c index f98a83a..573a0c4 100644 --- a/arch/arm/mach-exynos/mach-nuri.c +++ b/arch/arm/mach-exynos/mach-nuri.c @@ -39,7 +39,7 @@ #include asm/mach-types.h #include plat/adc.h -#include plat/regs-fb-v4.h +#include video/samsung_fimd.h #include plat/regs-serial.h #include plat/cpu.h #include plat/devs.h diff --git a/arch/arm/mach-exynos/mach-origen.c b/arch/arm/mach-exynos/mach-origen.c index 5a12dc2..c69707e 100644 --- a/arch/arm/mach-exynos/mach-origen.c +++ b/arch/arm/mach-exynos/mach-origen.c @@ -31,7 +31,7 @@ #include video/platform_lcd.h #include plat/regs-serial.h -#include plat/regs-fb-v4.h +#include video/samsung_fimd.h #include plat/cpu.h #include plat/devs.h #include plat/sdhci.h diff --git a/arch/arm/mach-exynos/mach-smdk4x12.c b/arch/arm/mach-exynos/mach-smdk4x12.c index b26beb1..8a8acff 100644 --- a/arch/arm/mach-exynos/mach-smdk4x12.c +++ b/arch/arm/mach-exynos/mach-smdk4x12.c @@ -35,7 +35,7 @@ #include plat/iic.h #include plat/keypad.h #include plat/mfc.h -#include plat/regs-fb.h +#include video/samsung_fimd.h #include plat/regs-serial.h #include plat/sdhci.h diff --git a/arch/arm/mach-exynos/mach-smdkv310.c b/arch/arm/mach-exynos/mach-smdkv310.c index 3cfa688..c2df6e8 100644 --- a/arch/arm/mach-exynos/mach-smdkv310.c +++ b/arch/arm/mach-exynos/mach-smdkv310.c @@ -28,7 +28,7 @@ #include video/platform_lcd.h #include plat/regs-serial.h #include plat/regs-srom.h -#include plat/regs-fb-v4.h +#include video/samsung_fimd.h #include plat/cpu.h #include plat/devs.h #include plat/fb.h diff --git a/arch/arm/mach-exynos/mach-universal_c210.c b/arch/arm/mach-exynos/mach-universal_c210.c index 4d1f40d..e6fb471 100644 --- a/arch/arm/mach-exynos/mach-universal_c210.c +++ b/arch/arm/mach-exynos/mach-universal_c210.c @@ -39,7 +39,7 @@ #include plat/fb.h #include plat/mfc.h #include plat/sdhci.h -#include plat/regs-fb-v4.h +#include video/samsung_fimd.h #include plat/fimc-core.h #include plat/s5p-time.h #include plat/camport.h diff --git a/arch/arm/mach-exynos/setup-fimd0.c b/arch/arm/mach-exynos/setup-fimd0.c index 07a6dbe..53c4c51 100644 --- a/arch/arm/mach-exynos/setup-fimd0.c +++ b/arch/arm/mach-exynos/setup-fimd0.c @@ -14,7 +14,7 @@ #include linux/gpio.h #include plat/gpio-cfg.h -#include plat/regs-fb-v4.h +#include video/samsung_fimd.h #include mach/map.h diff --git a/arch/arm/mach-s3c24xx/mach-smdk2416.c b/arch/arm/mach-s3c24xx/mach-smdk2416.c index c3100a0..c8d5f51 100644 --- a/arch/arm/mach-s3c24xx/mach-smdk2416.c +++ b/arch/arm/mach-s3c24xx/mach-smdk2416.c @@ -52,7 +52,7 @@ #include plat/udc.h #include linux/platform_data/s3c-hsudc.h -#include plat/regs-fb-v4.h +#include video/samsung_fimd.h #include plat/fb.h #include plat/common-smdk.h diff --git a/arch/arm/mach-s3c64xx/mach-anw6410.c b/arch/arm/mach-s3c64xx/mach-anw6410.c index ffa29dd..27e3087 100644 --- a/arch/arm/mach-s3c64xx/mach-anw6410.c +++ b/arch/arm/mach-s3c64xx/mach-anw6410.c @@ -44,7 +44,7 @@ #include plat/regs-serial.h #include plat/iic.h #include plat/fb.h -#include plat/regs-fb-v4.h +#include video/samsung_fimd.h #include plat/clock.h #include plat/devs.h diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c b/arch/arm/mach-s3c64xx/mach-crag6410.c index 09cd812..66e8c69 100644 --- a/arch/arm/mach-s3c64xx/mach-crag6410.c +++ b/arch/arm/mach-s3c64xx/mach-crag6410.c @@ -57,7 +57,7 @@ #include mach/regs-gpio-memport.h #include plat/regs-serial.h -#include plat/regs-fb-v4.h +#include video/samsung_fimd.h
[PATCH V2 4/5] driver: Include the modified FIMD header file
The fimd register headers have been moved to include/video/ hence, modifying the driver files accordingly. Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +- drivers/video/s3c-fb.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 29fdbfe..8da90f9 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c @@ -20,7 +20,7 @@ #include linux/pm_runtime.h #include drm/exynos_drm.h -#include plat/regs-fb-v4.h +#include video/samsung_fimd.h #include exynos_drm_drv.h #include exynos_drm_fbdev.h diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c index 69bf9d0..1226fdd 100644 --- a/drivers/video/s3c-fb.c +++ b/drivers/video/s3c-fb.c @@ -26,7 +26,7 @@ #include linux/pm_runtime.h #include mach/map.h -#include plat/regs-fb-v4.h +#include video/samsung_fimd.h #include plat/fb.h /* This driver will export a number of framebuffer interfaces depending -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 5/5] arm: samsung: delete frame buffer header files from platform
The FIMD register headers are moved to include/video/ hence, deleting these files from platform side Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 - arch/arm/plat-samsung/include/plat/regs-fb.h| 403 --- 2 files changed, 0 insertions(+), 562 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h diff --git a/arch/arm/plat-samsung/include/plat/regs-fb-v4.h b/arch/arm/plat-samsung/include/plat/regs-fb-v4.h deleted file mode 100644 index 4c3647f..000 --- a/arch/arm/plat-samsung/include/plat/regs-fb-v4.h +++ /dev/null @@ -1,159 +0,0 @@ -/* arch/arm/plat-samsung/include/plat/regs-fb-v4.h - * - * Copyright 2008 Openmoko, Inc. - * Copyright 2008 Simtec Electronics - * http://armlinux.simtec.co.uk/ - * Ben Dooks b...@simtec.co.uk - * - * S3C64XX - new-style framebuffer register definitions - * - * This is the register set for the new style framebuffer interface - * found from the S3C2443 onwards and specifically the S3C64XX series - * S3C6400 and S3C6410. - * - * The file contains the cpu specific items which change between whichever - * architecture is selected. See plat/regs-fb.h for the core definitions - * that are the same. - * - * 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 the core definitions here, in case we really do need to - * override them at a later date. -*/ - -#include plat/regs-fb.h - -#define S3C_FB_MAX_WIN (5) /* number of hardware windows available. */ -#define VIDCON1_FSTATUS_EVEN (1 15) - -/* Video timing controls */ -#define VIDTCON0 (0x10) -#define VIDTCON1 (0x14) -#define VIDTCON2 (0x18) - -/* Window position controls */ - -#define WINCON(_win) (0x20 + ((_win) * 4)) - -/* OSD1 and OSD4 do not have register D */ - -#define VIDOSD_BASE(0x40) - -#define VIDINTCON0 (0x130) - -/* WINCONx */ - -#define WINCONx_CSCWIDTH_MASK (0x3 26) -#define WINCONx_CSCWIDTH_SHIFT (26) -#define WINCONx_CSCWIDTH_WIDE (0x0 26) -#define WINCONx_CSCWIDTH_NARROW(0x3 26) - -#define WINCONx_ENLOCAL(1 22) -#define WINCONx_BUFSTATUS (1 21) -#define WINCONx_BUFSEL (1 20) -#define WINCONx_BUFAUTOEN (1 19) -#define WINCONx_YCbCr (1 13) - -#define WINCON1_LOCALSEL_CAMIF (1 23) - -#define WINCON2_LOCALSEL_CAMIF (1 23) -#define WINCON2_BLD_PIX(1 6) - -#define WINCON2_ALPHA_SEL (1 1) -#define WINCON2_BPPMODE_MASK (0xf 2) -#define WINCON2_BPPMODE_SHIFT (2) -#define WINCON2_BPPMODE_1BPP (0x0 2) -#define WINCON2_BPPMODE_2BPP (0x1 2) -#define WINCON2_BPPMODE_4BPP (0x2 2) -#define WINCON2_BPPMODE_8BPP_1232 (0x4 2) -#define WINCON2_BPPMODE_16BPP_565 (0x5 2) -#define WINCON2_BPPMODE_16BPP_A1555(0x6 2) -#define WINCON2_BPPMODE_16BPP_I1555(0x7 2) -#define WINCON2_BPPMODE_18BPP_666 (0x8 2) -#define WINCON2_BPPMODE_18BPP_A1665(0x9 2) -#define WINCON2_BPPMODE_19BPP_A1666(0xa 2) -#define WINCON2_BPPMODE_24BPP_888 (0xb 2) -#define WINCON2_BPPMODE_24BPP_A1887(0xc 2) -#define WINCON2_BPPMODE_25BPP_A1888(0xd 2) -#define WINCON2_BPPMODE_28BPP_A4888(0xd 2) - -#define WINCON3_BLD_PIX(1 6) - -#define WINCON3_ALPHA_SEL (1 1) -#define WINCON3_BPPMODE_MASK (0xf 2) -#define WINCON3_BPPMODE_SHIFT (2) -#define WINCON3_BPPMODE_1BPP (0x0 2) -#define WINCON3_BPPMODE_2BPP (0x1 2) -#define WINCON3_BPPMODE_4BPP (0x2 2) -#define WINCON3_BPPMODE_16BPP_565 (0x5 2) -#define WINCON3_BPPMODE_16BPP_A1555(0x6 2) -#define WINCON3_BPPMODE_16BPP_I1555(0x7 2) -#define WINCON3_BPPMODE_18BPP_666 (0x8 2) -#define WINCON3_BPPMODE_18BPP_A1665(0x9 2) -#define WINCON3_BPPMODE_19BPP_A1666(0xa 2) -#define WINCON3_BPPMODE_24BPP_888 (0xb 2) -#define WINCON3_BPPMODE_24BPP_A1887(0xc 2) -#define WINCON3_BPPMODE_25BPP_A1888(0xd 2) -#define WINCON3_BPPMODE_28BPP_A4888(0xd 2) - -#define VIDINTCON0_FIFIOSEL_WINDOW2(0x10 5) -#define
Re: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation
On Tue, 31 Jul 2012, Laurent Pinchart wrote: Hi Guennadi, On Tuesday 31 July 2012 13:29:55 Guennadi Liakhovetski wrote: On Tue, 31 Jul 2012, Laurent Pinchart wrote: On Tuesday 31 July 2012 13:14:13 Guennadi Liakhovetski wrote: On Tue, 31 Jul 2012, Laurent Pinchart wrote: On Tuesday 31 July 2012 11:56:44 Guennadi Liakhovetski wrote: On Thu, 26 Jul 2012, Laurent Pinchart wrote: On Wednesday 18 July 2012 11:18:33 Sylwester Nawrocki wrote: On 07/16/2012 11:42 AM, Guennadi Liakhovetski wrote: On Fri, 25 May 2012, Sylwester Nawrocki wrote: The driver initializes all board related properties except the s_power() callback to board code. The platforms that require this callback are not supported by this driver yet for CONFIG_OF=y. Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Bartlomiej Zolnierkiewiczb.zolnier...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- .../bindings/camera/samsung-s5k6aafx.txt | 57 + drivers/media/video/s5k6aa.c | 129 ++-- 2 files changed, 146 insertions(+), 40 deletions(-) create mode 100644 Documentation/devicetree/bindings/camera/samsung-s5k6aafx.t xt diff --git a/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.t xt b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.t xt new file mode 100644 index 000..6685a9c --- /dev/null +++ b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.t xt @@ -0,0 +1,57 @@ +Samsung S5K6AAFX camera sensor +-- + +Required properties: + +- compatible : samsung,s5k6aafx; +- reg : base address of the device on I2C bus; You said you ended up putting your sensors outside of I2C busses, is this one of changes, that are present in your git- tree but not in this series? No, I must have been not clear enough on that. Our idea was to keep I2C slave device nodes as an I2C controller's child nodes, according to the current convention. The 'sensor' nodes (the 'camera''s children) would only contain a phandle to a respective I2C slave node. This implies that we cannot access I2C bus in I2C client's device probe() callback. An actual H/W access could begin only from within and after invocation of v4l2_subdev .registered callback.. That's how I've envisioned the DT bindings for sensors as well, this sounds good. The real challenge will be to get hold of the subdev to register it without race conditions. Hrm... That's how early pre-subdev versions of soc-camera used to work, that's where all the device_video_probe() functions come from. But then we switched to dynamic i2c device registration. Do we want to switch all drivers back now?... Couldn't we temporarily use references from subdevs to hosts until the clock API is available? I don't think that requires a reference from subdevs to hosts in the DT. The subdev will need the host to be probed before a clock can be available so you won't be able to access the hardware in the probe() function in the generic case. You will need to wait until the registered() subdev operation is called, at which point the host can be accessed through the v4l2_device. Sure, I understand, but that's exactly what we wanted to avoid - succeeding client's i2c .probe() without even touching the hardware. But should we allow host probe() to succeed if the sensor isn't present ? I think we should, yes. The host hardware is there and functional - whether or not all or some of the clients are failing. Theoretically clients can also be hot-plugged. Whether and how many video device nodes we create, that's a different question. I think I can agree with you on this (although I could change my mind if this architecture turns out to result in unsolvable technical issues). That will involve a lot of work though. There's however at least one more gotcha that occurs to me with this approach: if clients fail to probe, how do we find out about that and turn clocks back off? One improvement to turning clocks on immediately in host's probe() is to only do it in a BUS_NOTIFY_BIND_DRIVER notifier. But how do we find out, that probing failed? No notifier is called in this case. We could use a time-out, but that's ugly. I think, we could ever request a new notifier for this case. We could also require client
Re: [RFC/PATCH 02/13] media: s5p-csis: Add device tree support
On 07/31/2012 01:05 PM, Laurent Pinchart wrote: What about CSI receivers that can reroute the lanes internally ? We would need to specify lane indices for each lane then, maybe with something like clock-lane =0; data-lanes =2 3 1; Sounds good to me. And the clock-lane could be made optional, as not all devices would need it. However, as far as I can see, there is currently no generic API for handling this kind of data structure. E.g. number of cells for the interrupts property is specified with an additional #interrupt-cells property. It would have been much easier to handle something like: data-lanes = 2, 3, 1; i.e. an array of the lane indexes. I'm fine with that. ...on a second thought: shouldn't this be handled by pinctrl? Or is it some CSI-2 module internal lane switching, not the global SoC pin function configuration? On the hardware I came across, it's handled by the CSI2 receiver, not the SoC pinmux feature. Same here. Is there any hardware known to mux those MIPI-CSI D-PHY high speed differential signals with general purpose IO pins ? Or are there mostly dedicated pins used ? However, if there are cases the lane configuration is done solely at CSI2 receiver level, there seems little point in involving the pinctrl API. -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation
On 07/31/2012 02:26 PM, Guennadi Liakhovetski wrote: But should we allow host probe() to succeed if the sensor isn't present ? I think we should, yes. The host hardware is there and functional - whether or not all or some of the clients are failing. Theoretically clients can also be hot-plugged. Whether and how many video device nodes we create, that's a different question. I think I can agree with you on this (although I could change my mind if this architecture turns out to result in unsolvable technical issues). That will involve a lot of work though. There's however at least one more gotcha that occurs to me with this approach: if clients fail to probe, how do we find out about that and turn clocks back off? One improvement to turning clocks on immediately in Hmm, wouldn't it be the client that turns a clock on/off when needed ? I'd like to preserve this functionality, so client drivers can have full control on the power up/down sequences. While we are trying to improve the current situation... host's probe() is to only do it in a BUS_NOTIFY_BIND_DRIVER notifier. But how do we find out, that probing failed? No notifier is called in this case. We could use a time-out, but that's ugly. I think, we could ever request a new notifier for this case. We could also require client drivers to call a V4L2 function in this case, but that's not very pretty either. -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/5] include/video: Add Exynos5 specific FIMD register offsets
Hello. On 31-07-2012 16:23, Leela Krishna Amudala wrote: Exynos5 has VIDTCON and VIDCON registers at different offsets from the previous SOCs. Hence, adding the macros. Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- include/video/samsung_fimd.h |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h index e979f42..820f190 100644 --- a/include/video/samsung_fimd.h +++ b/include/video/samsung_fimd.h @@ -524,3 +524,10 @@ * 1110 -none- -none- -none- -none--none- * -none- -none- -none- -none--none- */ + +/*EXYNOS5 FIMD REG OFFSET */ +#define EXYNOS5_VIDTCON0 (0x20010) +#define EXYNOS5_VIDTCON1 (0x20014) +#define EXYNOS5_VIDTCON2 (0x20018) +#define EXYNOS5_VIDTCON3 (0x2001C) +#define EXYNOS5_VIDCON1(0x20004) Parens not needed around simple literals. WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation
On Tue, 31 Jul 2012, Sylwester Nawrocki wrote: On 07/31/2012 02:26 PM, Guennadi Liakhovetski wrote: But should we allow host probe() to succeed if the sensor isn't present ? I think we should, yes. The host hardware is there and functional - whether or not all or some of the clients are failing. Theoretically clients can also be hot-plugged. Whether and how many video device nodes we create, that's a different question. I think I can agree with you on this (although I could change my mind if this architecture turns out to result in unsolvable technical issues). That will involve a lot of work though. There's however at least one more gotcha that occurs to me with this approach: if clients fail to probe, how do we find out about that and turn clocks back off? One improvement to turning clocks on immediately in Hmm, wouldn't it be the client that turns a clock on/off when needed ? I'd like to preserve this functionality, so client drivers can have full control on the power up/down sequences. While we are trying to improve the current situation... Eventually, when the clock API is available - yes, the client would just call clk_enable() / clk_disable(). But for now isn't it host's job to do that? Or you want to add new API for that? Thanks Guennadi host's probe() is to only do it in a BUS_NOTIFY_BIND_DRIVER notifier. But how do we find out, that probing failed? No notifier is called in this case. We could use a time-out, but that's ugly. I think, we could ever request a new notifier for this case. We could also require client drivers to call a V4L2 function in this case, but that's not very pretty either. --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/5] include/video: Add Exynos5 specific FIMD register offsets
Hi, On 07/31/2012 02:51 PM, Sergei Shtylyov wrote: +/*EXYNOS5 FIMD REG OFFSET */ How about changing it to, e.g. /* EXYNOS5 specific register offset definitions */ (but just in case you happen to resend this patch series) +#define EXYNOS5_VIDTCON0(0x20010) +#define EXYNOS5_VIDTCON1(0x20014) +#define EXYNOS5_VIDTCON2(0x20018) +#define EXYNOS5_VIDTCON3(0x2001C) +#define EXYNOS5_VIDCON1(0x20004) Parens not needed around simple literals. Yes, I agree it looks insane. But, I think we could allow this for consistency with the remaining definitions. -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation
On 07/31/2012 02:59 PM, Guennadi Liakhovetski wrote: On Tue, 31 Jul 2012, Sylwester Nawrocki wrote: On 07/31/2012 02:26 PM, Guennadi Liakhovetski wrote: But should we allow host probe() to succeed if the sensor isn't present ? I think we should, yes. The host hardware is there and functional - whether or not all or some of the clients are failing. Theoretically clients can also be hot-plugged. Whether and how many video device nodes we create, that's a different question. I think I can agree with you on this (although I could change my mind if this architecture turns out to result in unsolvable technical issues). That will involve a lot of work though. There's however at least one more gotcha that occurs to me with this approach: if clients fail to probe, how do we find out about that and turn clocks back off? One improvement to turning clocks on immediately in Hmm, wouldn't it be the client that turns a clock on/off when needed ? I'd like to preserve this functionality, so client drivers can have full control on the power up/down sequences. While we are trying to improve the current situation... Eventually, when the clock API is available - yes, the client would just call clk_enable() / clk_disable(). But for now isn't it host's job to do that? Or you want to add new API for that? Indeed, looking at existing drivers, the clocks' handling is now mostly done in the host drivers. Only the omap3isp appears to do the right thing, i.e. delegating control over the clock to client drivers, but it does it with platform_data callbacks. We've already discussed adding a new API for that, http://www.mail-archive.com/linux-media@vger.kernel.org/msg35359.html However using common clock API and binding a clock to client device (either DT based or not) sounds like a best approach to me. Waiting for the common clock API to be generally available maybe we could add some clock ops at the v4l2_device ? Just a humble suggestion, I'm not sure whether it is really good and needed or not. -- Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V2 2/5] include/video: Add Exynos5 specific FIMD register offsets
Leela Krishna Amudala wrote: Exynos5 has VIDTCON and VIDCON registers at different offsets from the previous SOCs. Hence, adding the macros. Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- include/video/samsung_fimd.h |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h index e979f42..820f190 100644 --- a/include/video/samsung_fimd.h +++ b/include/video/samsung_fimd.h @@ -524,3 +524,10 @@ * 1110 -none- -none- -none- -none--none- * -none- -none- -none- -none--none- */ + +/*EXYNOS5 FIMD REG OFFSET */ +#define EXYNOS5_VIDTCON0 (0x20010) +#define EXYNOS5_VIDTCON1 (0x20014) +#define EXYNOS5_VIDTCON2 (0x20018) +#define EXYNOS5_VIDTCON3 (0x2001C) +#define EXYNOS5_VIDCON1 (0x20004) -- 1.7.0.4 All of EXYNOS5 SoCs including upcoming SoCs _really_ have same address like above? I don't think so. You need to consider its flexibility or some compatibility when definitions are added. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V2 3/5] arm: samsung: Include the modified FIMD header file
Leela Krishna Amudala wrote: The fimd register headers have been moved to include/video/ hence, modifying the machine files accordingly. Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- arch/arm/mach-exynos/mach-nuri.c |2 +- arch/arm/mach-exynos/mach-origen.c |2 +- arch/arm/mach-exynos/mach-smdk4x12.c |2 +- arch/arm/mach-exynos/mach-smdkv310.c |2 +- arch/arm/mach-exynos/mach-universal_c210.c |2 +- arch/arm/mach-exynos/setup-fimd0.c |2 +- arch/arm/mach-s3c24xx/mach-smdk2416.c |2 +- arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- arch/arm/mach-s3c64xx/mach-hmt.c |2 +- arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- arch/arm/mach-s3c64xx/mach-ncp.c |2 +- arch/arm/mach-s3c64xx/mach-real6410.c |2 +- arch/arm/mach-s3c64xx/mach-smartq5.c |2 +- arch/arm/mach-s3c64xx/mach-smartq7.c |2 +- arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6440.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6450.c |2 +- arch/arm/mach-s5pc100/mach-smdkc100.c |2 +- arch/arm/mach-s5pv210/mach-aquila.c|2 +- arch/arm/mach-s5pv210/mach-goni.c |2 +- arch/arm/mach-s5pv210/mach-smdkv210.c |2 +- 22 files changed, 22 insertions(+), 22 deletions(-) diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach- nuri.c index f98a83a..573a0c4 100644 --- a/arch/arm/mach-exynos/mach-nuri.c +++ b/arch/arm/mach-exynos/mach-nuri.c @@ -39,7 +39,7 @@ #include asm/mach-types.h #include plat/adc.h -#include plat/regs-fb-v4.h +#include video/samsung_fimd.h #include plat/regs-serial.h #include plat/cpu.h #include plat/devs.h NO! Don't just replace it. Please put the inclusions with the same kind like following. diff --git a/arch/arm/mach-exynos/mach-nuri.c b/arch/arm/mach-exynos/mach-nuri.c index ea785fc..90d8daa 100644 --- a/arch/arm/mach-exynos/mach-nuri.c +++ b/arch/arm/mach-exynos/mach-nuri.c @@ -29,6 +29,7 @@ #include drm/exynos_drm.h #include video/platform_lcd.h +#include video/samsung_fimd.h #include media/m5mols.h #include media/s5k6aa.h #include media/s5p_fimc.h @@ -39,7 +40,6 @@ #include asm/mach-types.h #include plat/adc.h -#include plat/regs-fb-v4.h #include plat/regs-serial.h #include plat/cpu.h #include plat/devs.h Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V2 4/5] driver: Include the modified FIMD header file
Leela Krishna Amudala wrote: The fimd register headers have been moved to include/video/ hence, modifying the driver files accordingly. Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +- drivers/video/s3c-fb.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) [...] --- a/drivers/video/s3c-fb.c +++ b/drivers/video/s3c-fb.c @@ -26,7 +26,7 @@ #include linux/pm_runtime.h #include mach/map.h -#include plat/regs-fb-v4.h +#include video/samsung_fimd.h #include plat/fb.h See my previous comments. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V2 0/5] arm: samsung: Move FIMD headers to include/video/
Leela Krishna Amudala wrote: This patchset moves the contents of regs-fb-v4.h and regs-fb.h from arch side to include/video/samsung_fimd.h This patchset is created and rebased against master branch of torvalds tree. Tested on smdk5250 board, build tested for other boards. (Cc'ed Florian Tobias Schandinat) Yeah, since it's merge window, this series could be created against on mainline. And IMO, would be helpful to us if this series could be sent to upstream via samsung tree after reviewing, because this touches too many files in samsung tree and just adds include/video/samsung_fimd.h. But I'm not sure the added inclusion will be used in other file of drivers/video. If so, I can provide some topic branch can be merged into Florian's tree. Florian, how about? Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. Changes from version 1: - Split the patches as per Sylwester comments - Changed FIMD_V8_xxx macro to EXYNOS5_xxx Leela Krishna Amudala (5): include/video: Add samsung FIMD register header include/video: Add Exynos5 specific FIMD register offsets arm: samsung: Include the modified FIMD header file driver: Include the modified FIMD header file arm: samsung: delete frame buffer header files from platform arch/arm/mach-exynos/mach-nuri.c |2 +- arch/arm/mach-exynos/mach-origen.c |2 +- arch/arm/mach-exynos/mach-smdk4x12.c |2 +- arch/arm/mach-exynos/mach-smdkv310.c |2 +- arch/arm/mach-exynos/mach-universal_c210.c |2 +- arch/arm/mach-exynos/setup-fimd0.c |2 +- arch/arm/mach-s3c24xx/mach-smdk2416.c |2 +- arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- arch/arm/mach-s3c64xx/mach-hmt.c |2 +- arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- arch/arm/mach-s3c64xx/mach-ncp.c |2 +- arch/arm/mach-s3c64xx/mach-real6410.c |2 +- arch/arm/mach-s3c64xx/mach-smartq5.c |2 +- arch/arm/mach-s3c64xx/mach-smartq7.c |2 +- arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6440.c |2 +- arch/arm/mach-s5p64x0/mach-smdk6450.c |2 +- arch/arm/mach-s5pc100/mach-smdkc100.c |2 +- arch/arm/mach-s5pv210/mach-aquila.c|2 +- arch/arm/mach-s5pv210/mach-goni.c |2 +- arch/arm/mach-s5pv210/mach-smdkv210.c |2 +- arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +- drivers/video/s3c-fb.c |2 +- .../plat/regs-fb.h = include/video/samsung_fimd.h | 152 +-- 26 files changed, 165 insertions(+), 194 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h rename arch/arm/plat-samsung/include/plat/regs-fb.h = include/video/samsung_fimd.h (74%) -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8 v2] ARM: EXYNOS5: Add machine data for USB 2.0
On 07/29/2012 10:11 PM, Arnd Bergmann wrote: On Saturday 28 July 2012, Vivek Gautam wrote: Can you pleae explain why this is done in the changelog? We try hard to do such mappings from the device driver instead, so I'm surprised that this is necessary fo rthe USB phy. We are doing the mapping for device address in the driver, but this memory mapping for USB PHY registers that need to be programmed by the software is done here. This is similar to what we see for exynos4 also. Is it something that i can still change? Please suggest. Yes, I think the USB PHY handling for all exynos chips should be changed from an ad-hoc method to a more formal device driver. As I commented in another patch of this series, I think the main problem is that treat the USB PHY as a property of the platform, which it really isn't. We have a bunch of other USB PHY drivers for other platforms that are inside of the drivers/usb hierarchy. For all I know, there is no formal USB PHY driver API yet, and it seems that it would be a good idea to introduce one now, but for now, just move the code to drivers/usb/phy/ and make it one file per different kind of PHY. Totally agree. I think that two PHY drivers need for usb2.0 PHY and usb3.0 PHY in drivers/usb/phy directory. First, let's make usb2.0 PHY driver for samsung SoCs from phy control codes of arch/arm, then add to support usb2.0 PHY for exynos5 and make usb3.0 PHY driver for exynos. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Re: [PATCH] ARM: EXYNOS: Add I2S SFR base addresses
PADMAVATHI VENNA wrote:
Padma, don't post with html styled :(
And you need to check the regarding addresses as per Sachin commented.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--- Original Message ---
Sender : Sachin Kamatsachin.ka...@linaro.org
Date : Jul 26, 2012 13:41 (GMT+09:00)
Title : Re: [PATCH] ARM: EXYNOS: Add I2S SFR base addresses
On 25 July 2012 17:35, Padmavathi Venna wrote:
The base address of I2S 0 controller is similar in exynos4 and exynos5
platforms. So this patch defines a common macro for the I2S controller
0 base address in both the platforms and use the same macro.
This patch also defines the I2S controller 1,2 base addresses in exynos5
and correct the I2S controller 1 base address in exynos4
Signed-off-by: Padmavathi Venna
---
arch/arm/mach-exynos/dev-audio.c|2 +-
arch/arm/mach-exynos/include/mach/map.h |6 --
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/dev-audio.c
b/arch/arm/mach-exynos/dev-audio.c
index b33a5b6..5dbc9a2 100644
--- a/arch/arm/mach-exynos/dev-audio.c
+++ b/arch/arm/mach-exynos/dev-audio.c
@@ -62,7 +62,7 @@ static struct s3c_audio_pdata i2sv5_pdata = {
};
static struct resource exynos4_i2s0_resource[] = {
- [0] = DEFINE_RES_MEM(EXYNOS4_PA_I2S0, SZ_256),
+ [0] = DEFINE_RES_MEM(EXYNOS_PA_I2S0, SZ_256),
[1] = DEFINE_RES_DMA(DMACH_I2S0_TX),
[2] = DEFINE_RES_DMA(DMACH_I2S0_RX),
[3] = DEFINE_RES_DMA(DMACH_I2S0S_TX),
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index c72b675..5cf7d91 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -39,9 +39,11 @@
#define EXYNOS4_PA_G2D 0x1280
-#define EXYNOS4_PA_I2S00x0383
-#define EXYNOS4_PA_I2S10xE310
+#define EXYNOS_PA_I2S0 0x0383
+#define EXYNOS4_PA_I2S10xE210
#define EXYNOS4_PA_I2S20xE2A0
As per the TRM, these addresses (I2S1 and I2S2) are 0x1396 and
0x1397 respectively on Exynos4412 SoC.
Please verify.
I didn't verify Exynos4412 before. I will send a new patch for this.
+#define EXYNOS5_PA_I2S10x12D6
+#define EXYNOS5_PA_I2S20x12D7
#define EXYNOS4_PA_PCM00x0384
#define EXYNOS4_PA_PCM10x1398
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe
linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ASoC: Samsung: Update Kconfig for Exynos5250 and Exynos4412
Padmavathi Venna wrote: Update Kconfig file to support the Exynos5250 and Exynos4412 Signed-off-by: Sangsu Park sangsu4u.p...@samsung.com Signed-off-by: Sangbeom Kim sbki...@samsung.com Signed-off-by: Padmavathi Venna padm...@samsung.com --- sound/soc/samsung/Kconfig |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig index fe3995c..d54e400 100644 --- a/sound/soc/samsung/Kconfig +++ b/sound/soc/samsung/Kconfig @@ -1,6 +1,6 @@ config SND_SOC_SAMSUNG tristate ASoC support for Samsung - depends on ARCH_S3C24XX || ARCH_S3C64XX || ARCH_S5PC100 || ARCH_S5PV210 || ARCH_S5P64X0 || ARCH_EXYNOS4 + depends on PLAT_SAMSUNG select S3C64XX_DMA if ARCH_S3C64XX select S3C2410_DMA if ARCH_S3C24XX help @@ -63,7 +63,7 @@ config SND_SOC_SAMSUNG_SMDK_WM8580 config SND_SOC_SAMSUNG_SMDK_WM8994 tristate SoC I2S Audio support for WM8994 on SMDK - depends on SND_SOC_SAMSUNG (MACH_SMDKV310 || MACH_SMDKC210 || MACH_SMDK4212) + depends on SND_SOC_SAMSUNG (MACH_SMDKV310 || MACH_SMDKC210 || MACH_SMDK4212 || MACH_SMDK4412 || SOC_EXYNOS5250) Well, do you think _really_ all board which has a EXYNOS5250 SoC is needed this config? I don't think so? [...] Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 5/5] arm: samsung: delete frame buffer header files from platform
Hello Kgene, On Wed, Aug 1, 2012 at 7:34 AM, Kukjin Kim kgene@samsung.com wrote: Leela Krishna Amudala wrote: The FIMD register headers are moved to include/video/ hence, deleting these files from platform side Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com --- arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 - arch/arm/plat-samsung/include/plat/regs-fb.h| 403 --- 2 files changed, 0 insertions(+), 562 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h No. This should be squashed into first patch on this series. See below. arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 .../plat/regs-fb.h = include/video/samsung_fimd.h | 145 -- 2 files changed, 134 insertions(+), 170 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h rename arch/arm/plat-samsung/include/plat/regs-fb.h = include/video/samsung_fimd.h (74%) If I squash it with the first patch and if somebody set that as a head commit, it will break the build. Hence, splitted it up from the first patch. Thank you Sylwester for suggesting this split up change. Regards, Leela Krishna Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-fbdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
