RE: [PATCH v8 00/16] To use DMA generic APIs for Samsung DMA
On Mon, 2011-09-19 at 19:23 +0900, Kukjin Kim wrote: > Vinod Koul wrote: > > > > On Wed, 2011-09-14 at 17:03 +0530, Jassi Brar wrote: > > > On 14 September 2011 16:47, Vinod Koul wrote: > > > > > > >> The changelog for [PATCH v8 04/16] is misleading - we don't need any > > > >> modification for the reason mentioned in changelog. But the > > > >> modification > > > >> has positive side-effect of preventing callbacks during terminate_all > > > >> which > > > >> is no way understood from the changelog. So I would like to changelog > > > >> corrected. > > > > I thought change log was correct in depicting what patch does and Boojin > > > > had replied I will check again... > > > > > > I didn't reply because I ran out of ways to explain the same thing in > > > different words. > > I checked again the patch, change log and your comments. > > I agree with current change log, and also your observation is right but > > that is just a side effect, which IMO should be best left to developer > > to choose or not, in this case she ignored it > > > > So no changes to this and I a ready to merge it to my next in a day or > > two... > > > So as a note, pulled git://git.infradead.org/users/vkoul/slave-dma.git > samsung_dma for other regarding dma patches in arch/arm/ samsung stuff. > > If any problems, please let me know. > I am pushing them to next now.. -- ~Vinod -- 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] include: fb: Add definiton for window positioning structure
On Tue, 2011-09-20 at 20:08 +0300, Baruch Siach wrote:
> Hi Ajay,
>
> On Tue, Sep 20, 2011 at 08:56:57PM +0530, Ajay kumar wrote:
> > Hi Baruch,
> > On Tue, Sep 20, 2011 at 4:54 PM, Baruch Siach wrote:
> > > Hi Ajay,
> > >
> > > On Tue, Sep 20, 2011 at 11:30:39AM -0400, Ajay Kumar wrote:
> > >> This patch adds a data structure definiton to hold framebuffer
> > >> windows/planes.
> > >> An ioctl number is also added to provide user access
> > >> to change window position dynamically.
> > >
> > > [snip]
> > >
> > >> +/* Window overlaying */
> > >> +struct fb_overlay_win_pos {
> > >> + __u32 win_pos_x;/* x-offset from LCD(0,0) where window
> > >> starts */
> > >> + __u32 win_pos_y;/* y-offset from LCD(0,0) where window
> > >> starts */
> > >> +};
> > >
> > > Why not allow negative offsets where the left or upper part of the
> > > framebuffer
> > > is hidden?
> >
> > Thanks for pointing it out. Are there drivers which place the overlay
> > windows such that some part of the window is hidden from being
> > displayed on the screen?
>
> I don't know. However, since this is new userspace ABI which should stay
> compatible forever, we should make sure to do it right. Using __s32 instead
> of
> __u32 won't limit us in the future.
OMAP HW doesn't allow "funny" things like overlay being outside the
visible area, i.e. negative position or size larger than the display.
And my guess is that hardware rarely allow things like that, as it would
just complicate the hardware without any gain.
Out-of-display-overlays can of course be emulated by the software. But
I'm not sure if it's good to add the complexity in the driver layer, as
it could as well be handled in the userspace.
Then again, a signed value would be future safer ("just in case"), and
if the driver can just reject values it doesn't want to support, there's
no real harm there either.
Tomi
--
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: [RESEND PATCH 2/3] ARM: EXYNOS4: Update consistent DMA size to 8MB
Hi, As I know, CONSISTENT_DMA_SIZE is removed, please use the updated APIs. Thank you, Kyungmin Park On Wed, Sep 21, 2011 at 2:44 PM, Hatim Ali wrote: > Change the consistent DMA allocation to 8MB to support the > TVOUT driver. > > NOTE: Once CMA support is merged into mainline, we will use it for memory > allocation. > > Signed-off-by: Hatim Ali > --- > arch/arm/mach-exynos4/include/mach/memory.h | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-exynos4/include/mach/memory.h > b/arch/arm/mach-exynos4/include/mach/memory.h > index 374ef2c..7549742 100644 > --- a/arch/arm/mach-exynos4/include/mach/memory.h > +++ b/arch/arm/mach-exynos4/include/mach/memory.h > @@ -15,6 +15,8 @@ > > #define PLAT_PHYS_OFFSET UL(0x4000) > > +#define CONSISTENT_DMA_SIZE SZ_8M > + > /* Maximum of 256MiB in one bank */ > #define MAX_PHYSMEM_BITS 32 > #define SECTION_SIZE_BITS 28 > -- > 1.7.2.3 > > -- > 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
[RESEND PATCH 3/3] s5p-tv: Add PM_RUNTIME dependency
The TVOUT driver requires PM_RUNTIME support for proper clock enabling. Signed-off-by: Hatim Ali --- drivers/media/video/s5p-tv/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/s5p-tv/Kconfig b/drivers/media/video/s5p-tv/Kconfig index 9c37dee..f2a0977 100644 --- a/drivers/media/video/s5p-tv/Kconfig +++ b/drivers/media/video/s5p-tv/Kconfig @@ -8,7 +8,7 @@ config VIDEO_SAMSUNG_S5P_TV bool "Samsung TV driver for S5P platform (experimental)" - depends on PLAT_S5P + depends on PLAT_S5P && PM_RUNTIME depends on EXPERIMENTAL default n ---help--- -- 1.7.2.3 -- 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
[RESEND PATCH 2/3] ARM: EXYNOS4: Update consistent DMA size to 8MB
Change the consistent DMA allocation to 8MB to support the TVOUT driver. NOTE: Once CMA support is merged into mainline, we will use it for memory allocation. Signed-off-by: Hatim Ali --- arch/arm/mach-exynos4/include/mach/memory.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-exynos4/include/mach/memory.h b/arch/arm/mach-exynos4/include/mach/memory.h index 374ef2c..7549742 100644 --- a/arch/arm/mach-exynos4/include/mach/memory.h +++ b/arch/arm/mach-exynos4/include/mach/memory.h @@ -15,6 +15,8 @@ #define PLAT_PHYS_OFFSET UL(0x4000) +#define CONSISTENT_DMA_SIZESZ_8M + /* Maximum of 256MiB in one bank */ #define MAX_PHYSMEM_BITS 32 #define SECTION_SIZE_BITS 28 -- 1.7.2.3 -- 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/3] ARM: EXYNOS4: Add TVOUT support for SMDKV310
Add support for TVOUT on SMDKV310 board.
Signed-off-by: Hatim Ali
---
Changes since V1:
Incorporated changes as suggested by Tomasz Stanislawski
- Added GPIO settings for hot-plug detection.
- Added setting hdmi and mixer's parent for TV power domain.
arch/arm/mach-exynos4/Kconfig |2 ++
arch/arm/mach-exynos4/mach-smdkv310.c | 25 +
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index 3b594fe..0bf0fe04 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -131,6 +131,7 @@ config MACH_SMDKV310
select S3C_DEV_RTC
select S3C_DEV_WDT
select S3C_DEV_I2C1
+ select S5P_DEV_I2C_HDMIPHY
select S5P_DEV_MFC
select S3C_DEV_HSMMC
select S3C_DEV_HSMMC1
@@ -140,6 +141,7 @@ config MACH_SMDKV310
select EXYNOS4_DEV_AHCI
select SAMSUNG_DEV_KEYPAD
select EXYNOS4_DEV_PD
+ select S5P_DEV_TV
select SAMSUNG_DEV_PWM
select EXYNOS4_DEV_SYSMMU
select EXYNOS4_SETUP_FIMD0
diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c
b/arch/arm/mach-exynos4/mach-smdkv310.c
index 7ce4d8b..50de270 100644
--- a/arch/arm/mach-exynos4/mach-smdkv310.c
+++ b/arch/arm/mach-exynos4/mach-smdkv310.c
@@ -239,6 +239,7 @@ static struct platform_device *smdkv310_devices[]
__initdata = {
&s3c_device_hsmmc2,
&s3c_device_hsmmc3,
&s3c_device_i2c1,
+ &s5p_device_i2c_hdmiphy,
&s3c_device_rtc,
&s3c_device_wdt,
&exynos4_device_ac97,
@@ -262,6 +263,8 @@ static struct platform_device *smdkv310_devices[]
__initdata = {
&smdkv310_lcd_lte480wv,
&smdkv310_smsc911x,
&exynos4_device_ahci,
+ &s5p_device_hdmi,
+ &s5p_device_mixer,
};
static void __init smdkv310_smsc911x_init(void)
@@ -298,6 +301,25 @@ static struct platform_pwm_backlight_data smdkv310_bl_data
= {
.pwm_period_ns = 1000,
};
+static void s5p_tv_setup(void)
+{
+ int ret;
+
+ /* direct HPD to HDMI chip */
+ ret = gpio_request(EXYNOS4_GPX3(7), "hpd-plug");
+
+ if (!ret) {
+ gpio_direction_input(EXYNOS4_GPX3(7));
+ s3c_gpio_cfgpin_range(EXYNOS4_GPX3(7),
+ 1, S3C_GPIO_SFN(3));
+ } else
+ pr_err("Failed to request gpio for hpd: %d\n", ret);
+
+ /* setup dependencies between TV devices */
+ s5p_device_hdmi.dev.parent = &exynos4_device_pd[PD_TV].dev;
+ s5p_device_mixer.dev.parent = &exynos4_device_pd[PD_TV].dev;
+}
+
static void __init smdkv310_map_io(void)
{
s5p_init_io(NULL, 0, S5P_VA_CHIPID);
@@ -327,6 +349,9 @@ static void __init smdkv310_machine_init(void)
samsung_bl_set(&smdkv310_bl_gpio_info, &smdkv310_bl_data);
s5p_fimd0_set_platdata(&smdkv310_lcd0_pdata);
+ s5p_tv_setup();
+ s5p_i2c_hdmiphy_set_platdata(NULL);
+
platform_add_devices(smdkv310_devices, ARRAY_SIZE(smdkv310_devices));
s5p_device_mfc.dev.parent = &exynos4_device_pd[PD_MFC].dev;
}
--
1.7.2.3
--
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/3] Add TVOUT support for SMDKV310
This is v2 of the TVOUT patch set for SMDKV310. v1 is available at below link. (http://www.spinics.net/lists/arm-kernel/msg138054.html) Patch 1 has been modified according to the comments received from Tomasz Stanislawski. Patches 2 and 3 are RESENDs. Hatim Ali (3): ARM: EXYNOS4: Add TVOUT support for SMDKV310 ARM: EXYNOS4: Update consistent DMA size to 8MB s5p-tv: Add PM_RUNTIME dependency arch/arm/mach-exynos4/Kconfig |2 ++ arch/arm/mach-exynos4/include/mach/memory.h |2 ++ arch/arm/mach-exynos4/mach-smdkv310.c | 25 + drivers/media/video/s5p-tv/Kconfig |2 +- 4 files changed, 30 insertions(+), 1 deletions(-) -- 1.7.2.3 -- 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] serial: samsung: move handling of fclk/n clock to platform code
s3c2440 uses fclk/n (fclk divided by n) clock as one of the possible clocks used
to generate the baud rate clock. The divider 'n' in this case can be logically
represented outside of the uart controller.
This patch creates a new clock by name "fclk_n" for s3c2440 based platforms to
represent the fclk/n clock in the platform code. This clock provides a get_rate
callback that checks the UCON0/1/2 registers to determine the clock rate. The
samsung uart driver would receive the "fclk_n" clock name as one of the possible
baud rate clock options and the driver need not determine clock rate of fclk/n.
Cc: Ben Dooks
Cc: Vasily Khoruzhick
Signed-off-by: Thomas Abraham
---
In order to add clkdev based clock lookup (moving away from passing clock names
in platform data) for the Samsung UART driver, some portions of this driver
have to be first simplified. In this patch, the complicated handling on fclk/n
clock is removed which would further result in removing of the struct
s3c24xx_uart_clksrc itself and consolidation of the clock handling for
various SoC's supported by the Samsung UART driver.
The addition of clkdev based clock lookup is required to fully add device tree
support for the Samsung driver (no platform data when using device tree based
discovery means no list of clock names for baud rate clock).
This patch has been tested on smdk2440 board and following two patches
applied on top of linux 3.1-rc6.
[PATCH] serial: samsung: Add unified interrupt handler for s3c64xx and later
SoC's
[PATCH] ARM: SAMSUNG: Remove uart irq handling from plaform code
arch/arm/mach-s3c2440/clock.c | 37 +++
arch/arm/mach-s3c2440/mach-rx1950.c |4 +-
arch/arm/mach-s3c2440/mach-rx3715.c |4 +-
drivers/tty/serial/s3c2440.c| 33 ++
drivers/tty/serial/samsung.c| 21 ---
5 files changed, 44 insertions(+), 55 deletions(-)
diff --git a/arch/arm/mach-s3c2440/clock.c b/arch/arm/mach-s3c2440/clock.c
index f9e6bda..8a6cf6a 100644
--- a/arch/arm/mach-s3c2440/clock.c
+++ b/arch/arm/mach-s3c2440/clock.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
@@ -43,6 +44,7 @@
#include
#include
+#include
/* S3C2440 extended clock support */
@@ -108,6 +110,40 @@ static struct clk s3c2440_clk_ac97 = {
.ctrlbit= S3C2440_CLKCON_CAMERA,
};
+static unsigned long s3c2440_fclk_n_getrate(struct clk *clk)
+{
+ unsigned long ucon0, ucon1, ucon2, divisor;
+
+ /* the fun of calculating the uart divisors on the s3c2440 */
+ ucon0 = __raw_readl(S3C24XX_VA_UART0 + S3C2410_UCON);
+ ucon1 = __raw_readl(S3C24XX_VA_UART1 + S3C2410_UCON);
+ ucon2 = __raw_readl(S3C24XX_VA_UART2 + S3C2410_UCON);
+
+ ucon0 &= S3C2440_UCON0_DIVMASK;
+ ucon1 &= S3C2440_UCON1_DIVMASK;
+ ucon2 &= S3C2440_UCON2_DIVMASK;
+
+ if (ucon0 != 0)
+ divisor = (ucon0 >> S3C2440_UCON_DIVSHIFT) + 6;
+ else if (ucon1 != 0)
+ divisor = (ucon1 >> S3C2440_UCON_DIVSHIFT) + 21;
+ else if (ucon2 != 0)
+ divisor = (ucon2 >> S3C2440_UCON_DIVSHIFT) + 36;
+ else
+ /* manual calims 44, seems to be 9 */
+ divisor = 9;
+
+ return clk_get_rate(clk->parent) / divisor;
+}
+
+static struct clk s3c2440_clk_fclk_n = {
+ .name = "fclk_n",
+ .parent = &clk_f,
+ .ops= &(struct clk_ops) {
+ .get_rate = s3c2440_fclk_n_getrate,
+ },
+};
+
static int s3c2440_clk_add(struct sys_device *sysdev)
{
struct clk *clock_upll;
@@ -126,6 +162,7 @@ static int s3c2440_clk_add(struct sys_device *sysdev)
s3c2440_clk_cam.parent = clock_h;
s3c2440_clk_ac97.parent = clock_p;
s3c2440_clk_cam_upll.parent = clock_upll;
+ s3c24xx_register_clock(&s3c2440_clk_fclk_n);
s3c24xx_register_clock(&s3c2440_clk_ac97);
s3c24xx_register_clock(&s3c2440_clk_cam);
diff --git a/arch/arm/mach-s3c2440/mach-rx1950.c
b/arch/arm/mach-s3c2440/mach-rx1950.c
index 27ea950..9528b37 100644
--- a/arch/arm/mach-s3c2440/mach-rx1950.c
+++ b/arch/arm/mach-s3c2440/mach-rx1950.c
@@ -69,8 +69,8 @@ static struct map_desc rx1950_iodesc[] __initdata = {
static struct s3c24xx_uart_clksrc rx1950_serial_clocks[] = {
[0] = {
- .name = "fclk",
- .divisor = 0x0a,
+ .name = "fclk_n",
+ .divisor = 1,
.min_baud = 0,
.max_baud = 0,
},
diff --git a/arch/arm/mach-s3c2440/mach-rx3715.c
b/arch/arm/mach-s3c2440/mach-rx3715.c
index 1472b1a..a88247e 100644
--- a/arch/arm/mach-s3c2440/mach-rx3715.c
+++ b/arch/arm/mach-s3c2440/mach-rx3715.c
@@ -70,8 +70,8 @@ static struct map_desc rx3715_iodesc[] __initdata = {
static struct s3c24xx_uart_clksrc rx3715_serial_clocks[] = {
[0] = {
- .name = "fclk",
-
RE: [GIT PULL] Samsung cleanup for v3.2
Arnd Bergmann wrote: > > On Monday 19 September 2011, Kukjin Kim wrote: > > This is Samsung cleanup for v3.2. > > > > Please pull from: > > git://github.com/kgene/linux-samsung.git next-samsung-cleanup > > Pulled into arm-soc/next/cleanup. > Thanks :) > > If any problems, please let me know. > > One tiny conflict with Nico's cross-platform series: > Yes, I know. I have received same information from Stephen when he merged. > + > + MACHINE_START(SMDKC210, "SMDKC210") > + /* Maintainer: Kukjin Kim */ > - .boot_params= S5P_PA_SDRAM + 0x100, > ++ .atag_offset= 0x100, > + .init_irq = exynos4_init_irq, > + .map_io = smdkv310_map_io, > + .init_machine = smdkv310_machine_init, > + .timer = &exynos4_timer, > + MACHINE_END > > I'll handle this in the upstream submission. > OK, thanks. Best regards, Kgene. -- Kukjin Kim , 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: [GIT PULL] Samsung boards for v3.2
Arnd Bergmann wrote: > > On Monday 19 September 2011, Kukjin Kim wrote: > > Please pull from: > > git://github.com/kgene/linux-samsung.git next-samsung-board > > > > As you see, the next-samsung-board includes new board, SMDK4212. Of course > > to support new SoC, EXYNOS4212 is required for it but current > > arch/arm/mach-exynos4 (ARCH_EXYNOS4) can support it so I merged it into > > next-samsung-board not next-samsung-soc and to support handling of cupid > and > > rev. in Samsung stuff for it. As I remember, you said -soc branch of arm-soc > > is for adding new architecture like arch/arm/mach-. > > > > As a note, this includes samsung-fixes-2 which has been already pulled in > > your tree too. > > Looks good. I had to apply the same atag_offset change to the new board > file that was done in all other branches as well. > Yes, as a note, so I have applied following for it in my -next. It's ok to me either your handling or following. commit 61338e607202a7cf9d5f63e69eb538782643ff90 Author: Tushar Behera Date: Mon Sep 19 20:09:01 2011 +0900 ARM: EXYNOS4: convert boot_params to atag_offset Based on "ARM: introduce atag_offset to replace boot_params" by Nicolas Pitre (2bb9839e312ed55a6d5824ffa6077ce3d7d63b1e). Since boot_params variable is deleted from machine_desc, the variable is modified in the newer board files. CC: Nicolas Pitre Signed-off-by: Tushar Behera Signed-off-by: Kukjin Kim diff --git a/arch/arm/mach-exynos4/mach-origen.c b/arch/arm/mach-exynos4/mach-origen.c index c8121fc..421294b 100644 --- a/arch/arm/mach-exynos4/mach-origen.c +++ b/arch/arm/mach-exynos4/mach-origen.c @@ -209,7 +209,7 @@ static void __init origen_machine_init(void) MACHINE_START(ORIGEN, "ORIGEN") /* Maintainer: JeongHyeon Kim */ - .boot_params= S5P_PA_SDRAM + 0x100, + .atag_offset= 0x100, .init_irq = exynos4_init_irq, .map_io = origen_map_io, .init_machine = origen_machine_init, diff --git a/arch/arm/mach-exynos4/mach-smdk4212.c b/arch/arm/mach-exynos4/mach-smdk4212.c index 3479a93..8c41ae1 100644 --- a/arch/arm/mach-exynos4/mach-smdk4212.c +++ b/arch/arm/mach-exynos4/mach-smdk4212.c @@ -284,7 +284,7 @@ static void __init smdk4212_machine_init(void) MACHINE_START(SMDK4212, "SMDK4212") /* Maintainer: Kukjin Kim */ - .boot_params= S5P_PA_SDRAM + 0x100, + .atag_offset= 0x100, .init_irq = exynos4_init_irq, .map_io = smdk4212_map_io, .init_machine = smdk4212_machine_init, diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-exynos4/mach-smdkv310.c index 57cf632..7ce4d8b 100644 --- a/arch/arm/mach-exynos4/mach-smdkv310.c +++ b/arch/arm/mach-exynos4/mach-smdkv310.c @@ -344,7 +344,7 @@ MACHINE_END MACHINE_START(SMDKC210, "SMDKC210") /* Maintainer: Kukjin Kim */ - .boot_params= S5P_PA_SDRAM + 0x100, + .atag_offset= 0x100, .init_irq = exynos4_init_irq, .map_io = smdkv310_map_io, .init_machine = smdkv310_machine_init, > Pulled into next/board. Thanks! > Thanks :) Best regards, Kgene. -- Kukjin Kim , 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 1/7 (RE-SEND)] gpio/s3c24xx: move gpio driver into drivers/gpio/
Grant Likely wrote: > > On Mon, Sep 19, 2011 at 08:13:12PM +0900, Kukjin Kim wrote: > > Kukjin Kim wrote: > > > > > > > (snip)... > > > > Hi Grant, > > > > I didn't get any comments on this series, gpio-samsung patches for > > consolidation of Samsung gpiolib. Please let me know whether this is ok to > > you or not. And I think, if you're ok, this should be sent to upstream via > > both gpio tree and arm(samsung) tree to avoid conflicts... > > > > As a note, following is its status... > > > > Kukjin Kim (9): > > ARM: SAMSUNG: Move map header file into plat-samsung > > gpio/s3c24xx: move gpio driver into drivers/gpio/ > > gpio/s3c64xx: move gpio driver into drivers/gpio/ > > gpio/s5p64x0: move gpio driver into drivers/gpio/ > > gpio/samsung: Remove useless old Samsung related GPIO drivers > > gpio/samsung: Added gpio-samsung.c to support Samsung GPIOs > > ARM: SAMSUNG: Update the name of regarding Samsung GPIO > > ARM: SAMSUNG: Remove useless Samsung GPIO related CONFIGs > > Merge branch 'next/topic-plat-samsung-1' into next/topic-gpio-samsung > > Actually, even though I said I would pick it up, you've already got it > in a tree, so you can go ahead and merge it with my ack. I don't see > any major risk of conflicts for the next merge window, so there is no > need to merge it in the gpio tree also. > Hi Grant, OK, I will do it after adding your ack. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. > > > > > arch/arm/Kconfig |3 - > > arch/arm/mach-exynos4/include/mach/pm-core.h |2 +- > > arch/arm/mach-s3c2410/Kconfig |7 - > > arch/arm/mach-s3c2410/Makefile |1 - > > arch/arm/mach-s3c2410/include/mach/gpio-fns.h | 99 +- > > arch/arm/mach-s3c2410/include/mach/gpio-track.h|6 +- > > arch/arm/mach-s3c2410/include/mach/map.h | 52 +- > > arch/arm/mach-s3c2410/include/mach/pm-core.h |2 +- > > arch/arm/mach-s3c2410/s3c2410.c|4 +- > > arch/arm/mach-s3c2412/Kconfig |1 - > > arch/arm/mach-s3c2412/Makefile |1 - > > arch/arm/mach-s3c2412/gpio.c |2 +- > > arch/arm/mach-s3c2416/Kconfig |1 - > > arch/arm/mach-s3c2416/s3c2416.c|4 +- > > arch/arm/mach-s3c2440/Kconfig |4 - > > arch/arm/mach-s3c2440/s3c2440.c|4 +- > > arch/arm/mach-s3c2440/s3c2442.c|4 +- > > arch/arm/mach-s3c2443/Kconfig |1 - > > arch/arm/mach-s3c2443/s3c2443.c|4 +- > > arch/arm/mach-s3c64xx/Makefile |1 - > > arch/arm/mach-s3c64xx/gpiolib.c| 290 --- > > arch/arm/mach-s3c64xx/include/mach/map.h |9 +- > > arch/arm/mach-s3c64xx/include/mach/pm-core.h |2 +- > > arch/arm/mach-s5p64x0/Makefile |2 +- > > arch/arm/mach-s5p64x0/gpiolib.c| 511 > > arch/arm/mach-s5pv210/include/mach/pm-core.h |2 +- > > arch/arm/plat-s3c24xx/Kconfig |1 - > > arch/arm/plat-s3c24xx/Makefile |2 - > > arch/arm/plat-s3c24xx/gpio.c | 96 - > > arch/arm/plat-s3c24xx/gpiolib.c| 229 -- > > arch/arm/plat-s3c24xx/include/plat/map.h | 100 - > > arch/arm/plat-s5p/Kconfig |3 - > > arch/arm/plat-s5p/irq-gpioint.c| 10 +- > > arch/arm/plat-samsung/Kconfig | 27 - > > arch/arm/plat-samsung/Makefile |2 - > > arch/arm/plat-samsung/gpio-config.c| 431 > > arch/arm/plat-samsung/gpio.c | 167 -- > > .../plat-samsung/include/plat/gpio-cfg-helpers.h | 172 +- > > arch/arm/plat-samsung/include/plat/gpio-cfg.h | 34 +- > > arch/arm/plat-samsung/include/plat/gpio-core.h | 97 +- > > arch/arm/plat-samsung/include/plat/gpio-fns.h | 98 + > > arch/arm/plat-samsung/include/plat/map-s3c.h | 84 + > > .../include/plat/map-s5p.h |6 +- > > arch/arm/plat-samsung/include/plat/pm.h| 10 +- > > arch/arm/plat-samsung/pm-gpio.c| 72 +- > > arch/arm/plat-samsung/pm.c |6 +- > > drivers/gpio/Kconfig | 16 - > > drivers/gpio/Makefile |7 +- > > drivers/gpio/gpio-exynos4.c| 385 --- > > drivers/gpio/gpio-plat-samsung.c | 205 -- > > drivers/gpio/gpio-s5pc100.c| 354 --- > > drivers/gpio/gpio-s5pv210.c| 287 --- > > drivers/gpi
Re: [PATCH 5/7] gpio/samsung: Added gpio-samsung.c to support Samsung GPIOs
On Tue, Aug 30, 2011 at 09:27:27PM +0900, Kukjin Kim wrote: > This patch adds support for Samsung GPIOs with one gpio driver. > Actually there are drivers/gpio-s3c24xx.c, gpio-s3c64xx.c, > gpio-s5p64x0.c, gpio-s5pc100.c, gpio-s5pv210.c, gpio-exynos4.c, > gpio-plat-samsung.c, plat-samsung/gpio-config.c and gpio.c to > support each Samsung SoCs before. > Basically, the gpio-samsung.c has been made by their merging > and removing duplicated definitions. > > Note: gpio-samsung.c includes some SoC dependent codes and it > will be replaced next time. > > Cc: Ben Dooks > Cc: Grant Likely > Signed-off-by: Kukjin Kim > --- > drivers/gpio/Makefile |1 + > drivers/gpio/gpio-samsung.c | 2686 > +++ > 2 files changed, 2687 insertions(+), 0 deletions(-) > create mode 100644 drivers/gpio/gpio-samsung.c It's a big driver file, but I'll go ahead and pick this up without too much review because at least it is all in the same place now. I'll expect further cleanup in future patches. g. -- 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 5/7] gpio/samsung: Added gpio-samsung.c to support Samsung GPIOs
Grant Likely wrote: > > On Tue, Aug 30, 2011 at 09:27:27PM +0900, Kukjin Kim wrote: > > This patch adds support for Samsung GPIOs with one gpio driver. > > Actually there are drivers/gpio-s3c24xx.c, gpio-s3c64xx.c, > > gpio-s5p64x0.c, gpio-s5pc100.c, gpio-s5pv210.c, gpio-exynos4.c, > > gpio-plat-samsung.c, plat-samsung/gpio-config.c and gpio.c to > > support each Samsung SoCs before. > > Basically, the gpio-samsung.c has been made by their merging > > and removing duplicated definitions. > > > > Note: gpio-samsung.c includes some SoC dependent codes and it > > will be replaced next time. > > > > Cc: Ben Dooks > > Cc: Grant Likely > > Signed-off-by: Kukjin Kim > > --- > > drivers/gpio/Makefile |1 + > > drivers/gpio/gpio-samsung.c | 2686 > +++ > > 2 files changed, 2687 insertions(+), 0 deletions(-) > > create mode 100644 drivers/gpio/gpio-samsung.c > > It's a big driver file, but I'll go ahead and pick this up without too > much review because at least it is all in the same place now. I'll > expect further cleanup in future patches. > Yes, as you said, I agree this is needed some cleanup. I and my team will do it next time. Thanks. Best regards, Kgene. -- Kukjin Kim , 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 4/7] gpio/samsung: Remove useless old Samsung related GPIO drivers
Grant Likely wrote: > > On Tue, Aug 30, 2011 at 09:27:26PM +0900, Kukjin Kim wrote: > > Since gpio-samsung.c can replace old Samsung GPIO drivers, > > this patch removes them. > > > > Cc: Ben Dooks > > Cc: Grant Likely > > Signed-off-by: Kukjin Kim > > Removing this code before adding the new code means it is not > bisectable. I'll squash the two patches together when I pick them > up.. > OK, no problem and would be better to me if you could create some topic branch for this series. I'd like to merge it to avoid conflicts with Samsung stuff. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. > > > --- > > arch/arm/plat-samsung/Makefile |2 - > > arch/arm/plat-samsung/gpio-config.c | 431 - > > arch/arm/plat-samsung/gpio.c| 167 > > drivers/gpio/Kconfig| 28 -- > > drivers/gpio/Makefile |9 - > > drivers/gpio/gpio-exynos4.c | 385 -- > > drivers/gpio/gpio-plat-samsung.c| 205 -- > > drivers/gpio/gpio-s3c24xx.c | 283 --- > > drivers/gpio/gpio-s3c64xx.c | 289 > > drivers/gpio/gpio-s5p64x0.c | 510 --- > > drivers/gpio/gpio-s5pc100.c | 354 > > drivers/gpio/gpio-s5pv210.c | 287 > > 12 files changed, 0 insertions(+), 2950 deletions(-) > > delete mode 100644 arch/arm/plat-samsung/gpio-config.c > > delete mode 100644 arch/arm/plat-samsung/gpio.c > > delete mode 100644 drivers/gpio/gpio-exynos4.c > > delete mode 100644 drivers/gpio/gpio-plat-samsung.c > > delete mode 100644 drivers/gpio/gpio-s3c24xx.c > > delete mode 100644 drivers/gpio/gpio-s3c64xx.c > > delete mode 100644 drivers/gpio/gpio-s5p64x0.c > > delete mode 100644 drivers/gpio/gpio-s5pc100.c > > delete mode 100644 drivers/gpio/gpio-s5pv210.c > > -- 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/7 (RE-SEND)] gpio/s3c24xx: move gpio driver into drivers/gpio/
On Mon, Sep 19, 2011 at 08:13:12PM +0900, Kukjin Kim wrote: > Kukjin Kim wrote: > > > > (snip)... > > Hi Grant, > > I didn't get any comments on this series, gpio-samsung patches for > consolidation of Samsung gpiolib. Please let me know whether this is ok to > you or not. And I think, if you're ok, this should be sent to upstream via > both gpio tree and arm(samsung) tree to avoid conflicts... > > As a note, following is its status... > > Kukjin Kim (9): > ARM: SAMSUNG: Move map header file into plat-samsung > gpio/s3c24xx: move gpio driver into drivers/gpio/ > gpio/s3c64xx: move gpio driver into drivers/gpio/ > gpio/s5p64x0: move gpio driver into drivers/gpio/ > gpio/samsung: Remove useless old Samsung related GPIO drivers > gpio/samsung: Added gpio-samsung.c to support Samsung GPIOs > ARM: SAMSUNG: Update the name of regarding Samsung GPIO > ARM: SAMSUNG: Remove useless Samsung GPIO related CONFIGs > Merge branch 'next/topic-plat-samsung-1' into next/topic-gpio-samsung Actually, even though I said I would pick it up, you've already got it in a tree, so you can go ahead and merge it with my ack. I don't see any major risk of conflicts for the next merge window, so there is no need to merge it in the gpio tree also. g. > > arch/arm/Kconfig |3 - > arch/arm/mach-exynos4/include/mach/pm-core.h |2 +- > arch/arm/mach-s3c2410/Kconfig |7 - > arch/arm/mach-s3c2410/Makefile |1 - > arch/arm/mach-s3c2410/include/mach/gpio-fns.h | 99 +- > arch/arm/mach-s3c2410/include/mach/gpio-track.h|6 +- > arch/arm/mach-s3c2410/include/mach/map.h | 52 +- > arch/arm/mach-s3c2410/include/mach/pm-core.h |2 +- > arch/arm/mach-s3c2410/s3c2410.c|4 +- > arch/arm/mach-s3c2412/Kconfig |1 - > arch/arm/mach-s3c2412/Makefile |1 - > arch/arm/mach-s3c2412/gpio.c |2 +- > arch/arm/mach-s3c2416/Kconfig |1 - > arch/arm/mach-s3c2416/s3c2416.c|4 +- > arch/arm/mach-s3c2440/Kconfig |4 - > arch/arm/mach-s3c2440/s3c2440.c|4 +- > arch/arm/mach-s3c2440/s3c2442.c|4 +- > arch/arm/mach-s3c2443/Kconfig |1 - > arch/arm/mach-s3c2443/s3c2443.c|4 +- > arch/arm/mach-s3c64xx/Makefile |1 - > arch/arm/mach-s3c64xx/gpiolib.c| 290 --- > arch/arm/mach-s3c64xx/include/mach/map.h |9 +- > arch/arm/mach-s3c64xx/include/mach/pm-core.h |2 +- > arch/arm/mach-s5p64x0/Makefile |2 +- > arch/arm/mach-s5p64x0/gpiolib.c| 511 > arch/arm/mach-s5pv210/include/mach/pm-core.h |2 +- > arch/arm/plat-s3c24xx/Kconfig |1 - > arch/arm/plat-s3c24xx/Makefile |2 - > arch/arm/plat-s3c24xx/gpio.c | 96 - > arch/arm/plat-s3c24xx/gpiolib.c| 229 -- > arch/arm/plat-s3c24xx/include/plat/map.h | 100 - > arch/arm/plat-s5p/Kconfig |3 - > arch/arm/plat-s5p/irq-gpioint.c| 10 +- > arch/arm/plat-samsung/Kconfig | 27 - > arch/arm/plat-samsung/Makefile |2 - > arch/arm/plat-samsung/gpio-config.c| 431 > arch/arm/plat-samsung/gpio.c | 167 -- > .../plat-samsung/include/plat/gpio-cfg-helpers.h | 172 +- > arch/arm/plat-samsung/include/plat/gpio-cfg.h | 34 +- > arch/arm/plat-samsung/include/plat/gpio-core.h | 97 +- > arch/arm/plat-samsung/include/plat/gpio-fns.h | 98 + > arch/arm/plat-samsung/include/plat/map-s3c.h | 84 + > .../include/plat/map-s5p.h |6 +- > arch/arm/plat-samsung/include/plat/pm.h| 10 +- > arch/arm/plat-samsung/pm-gpio.c| 72 +- > arch/arm/plat-samsung/pm.c |6 +- > drivers/gpio/Kconfig | 16 - > drivers/gpio/Makefile |7 +- > drivers/gpio/gpio-exynos4.c| 385 --- > drivers/gpio/gpio-plat-samsung.c | 205 -- > drivers/gpio/gpio-s5pc100.c| 354 --- > drivers/gpio/gpio-s5pv210.c| 287 --- > drivers/gpio/gpio-samsung.c| 2686 > > 53 files changed, 3072 insertions(+), 3534 deletions(-) > delete mode 100644 arch/arm/mach-s3c64xx/gpiolib.c > delete mode 100644 arch/arm/mach-s5p64x0/gpiolib.c > delete mode 100644 arch/arm/plat-s3c24xx/gpio.c > delete mode 100644 arch/arm/plat-s3c24xx/gpiolib.c > delete mode 10064
Re: [PATCH 4/7] gpio/samsung: Remove useless old Samsung related GPIO drivers
On Tue, Aug 30, 2011 at 09:27:26PM +0900, Kukjin Kim wrote: > Since gpio-samsung.c can replace old Samsung GPIO drivers, > this patch removes them. > > Cc: Ben Dooks > Cc: Grant Likely > Signed-off-by: Kukjin Kim Removing this code before adding the new code means it is not bisectable. I'll squash the two patches together when I pick them up.. g. > --- > arch/arm/plat-samsung/Makefile |2 - > arch/arm/plat-samsung/gpio-config.c | 431 - > arch/arm/plat-samsung/gpio.c| 167 > drivers/gpio/Kconfig| 28 -- > drivers/gpio/Makefile |9 - > drivers/gpio/gpio-exynos4.c | 385 -- > drivers/gpio/gpio-plat-samsung.c| 205 -- > drivers/gpio/gpio-s3c24xx.c | 283 --- > drivers/gpio/gpio-s3c64xx.c | 289 > drivers/gpio/gpio-s5p64x0.c | 510 > --- > drivers/gpio/gpio-s5pc100.c | 354 > drivers/gpio/gpio-s5pv210.c | 287 > 12 files changed, 0 insertions(+), 2950 deletions(-) > delete mode 100644 arch/arm/plat-samsung/gpio-config.c > delete mode 100644 arch/arm/plat-samsung/gpio.c > delete mode 100644 drivers/gpio/gpio-exynos4.c > delete mode 100644 drivers/gpio/gpio-plat-samsung.c > delete mode 100644 drivers/gpio/gpio-s3c24xx.c > delete mode 100644 drivers/gpio/gpio-s3c64xx.c > delete mode 100644 drivers/gpio/gpio-s5p64x0.c > delete mode 100644 drivers/gpio/gpio-s5pc100.c > delete mode 100644 drivers/gpio/gpio-s5pv210.c > -- 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: [GIT PULL] Samsung boards for v3.2
On Monday 19 September 2011, Kukjin Kim wrote: > Please pull from: > git://github.com/kgene/linux-samsung.git next-samsung-board > > As you see, the next-samsung-board includes new board, SMDK4212. Of course > to support new SoC, EXYNOS4212 is required for it but current > arch/arm/mach-exynos4 (ARCH_EXYNOS4) can support it so I merged it into > next-samsung-board not next-samsung-soc and to support handling of cupid and > rev. in Samsung stuff for it. As I remember, you said -soc branch of arm-soc > is for adding new architecture like arch/arm/mach-. > > As a note, this includes samsung-fixes-2 which has been already pulled in > your tree too. Looks good. I had to apply the same atag_offset change to the new board file that was done in all other branches as well. Pulled into next/board. Thanks! Arnd -- 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: [GIT PULL] Samsung cleanup for v3.2
On Monday 19 September 2011, Kukjin Kim wrote: > This is Samsung cleanup for v3.2. > > Please pull from: > git://github.com/kgene/linux-samsung.git next-samsung-cleanup Pulled into arm-soc/next/cleanup. > If any problems, please let me know. One tiny conflict with Nico's cross-platform series: + + MACHINE_START(SMDKC210, "SMDKC210") + /* Maintainer: Kukjin Kim */ - .boot_params= S5P_PA_SDRAM + 0x100, ++ .atag_offset= 0x100, + .init_irq = exynos4_init_irq, + .map_io = smdkv310_map_io, + .init_machine = smdkv310_machine_init, + .timer = &exynos4_timer, + MACHINE_END I'll handle this in the upstream submission. Thanks, Arnd -- 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] include: fb: Add definiton for window positioning structure
On Tue, 2011-09-20 at 16:55 +, Florian Tobias Schandinat wrote: > Did you have a look at the (existing) API [1] Laurent proposed for discovering > the internal connections between the framebuffers (or with any other devices)? I know the basics of media controller, but I haven't really looked at the code. > If you agree that it'd be a good idea to use it I feel that we should make the > windowing API more compatible with it. So basically what we want to have as a I can't say if MC should be used for fb or not, but I think something similar should be used if we want to get overlays etc. supported. But even with MC (or something else) there, I'm not quite sure how they fit into the fb model. I think the core problem here is that in a more complex setup (at least as I see it for OMAP) the fb should be just a framebuffer in memory, without any direct relation to hardware. The hardware part (an overlay, or whichever is the corresponding element) will then use the framebuffer as the pixel source. However, the current fb model combines those two things into one. If we manage to separate them, and add MC or similar, I think it'll work. > window is one or more sunk pads so the pad-index should be also part of the > interface. I'm still confused with how OMAP works when it does not have a > "root" Do you mean how the hardware works, or how I've designed omapfb driver? > window/framebuffer. Normally I feel that the window position should be a > property of the parent window as this is what the position is relative too. > But > if the parent is no framebuffer, should we also include the entity into the > interface to allow configuring things that are nor even framebuffers? Right, I think you're pondering the core problem here =). On OMAP we have the display (the whole area shown on the panel/tv), which has video timings and things like that. But no pixel data as such (a configurable background color is there, though). And then we have the overlays, which are somewhere on the display, and the overlays get pixel data from memory (framebuffers). So in a way we have a contentless root window, but presenting that with an fb device doesn't feel right. And the fb device would logically be fb0, and if it couldn't show any content it couldn't be used as default framebuffer. > Also I think we need a z-index in case overlays overlap (might happen or?) and > enforcing that all z-indexes are different for the same entity. Yes, free z-order is supported in OMAP4. Previous OMAPs had fixed z-order, although in certain configuration (enable/disable alpha blending) the fixed z-order does change... > As I see it xres/yres (together with xoffset/yoffset) is always the visible > part > of the framebuffer. Typically that's also part of the timings as they define > what is visible. With the introduction of overlays (and maybe even for some > hardware anyway) it is no longer always true to have any timings at all. So on > all framebuffer that do not have physical timings the timing interpretation is > useless anyway (I'm thinking about adding a FB_CAP_NOTIMING) and what remains > is > the interpretation of xres/yres as visible screen region. For a system where there's always a root window for every output, plus variable size overlays, FB_CAP_NOTIMING makes sense. But it would still leave the problem if there's no root window. How to change timings on a system like OMAP? Tomi -- 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] include: fb: Add definiton for window positioning structure
Hi Ajay,
On Tue, Sep 20, 2011 at 08:56:57PM +0530, Ajay kumar wrote:
> Hi Baruch,
> On Tue, Sep 20, 2011 at 4:54 PM, Baruch Siach wrote:
> > Hi Ajay,
> >
> > On Tue, Sep 20, 2011 at 11:30:39AM -0400, Ajay Kumar wrote:
> >> This patch adds a data structure definiton to hold framebuffer
> >> windows/planes.
> >> An ioctl number is also added to provide user access
> >> to change window position dynamically.
> >
> > [snip]
> >
> >> +/* Window overlaying */
> >> +struct fb_overlay_win_pos {
> >> + __u32 win_pos_x; /* x-offset from LCD(0,0) where window
> >> starts */
> >> + __u32 win_pos_y; /* y-offset from LCD(0,0) where window
> >> starts */
> >> +};
> >
> > Why not allow negative offsets where the left or upper part of the
> > framebuffer
> > is hidden?
>
> Thanks for pointing it out. Are there drivers which place the overlay
> windows such that some part of the window is hidden from being
> displayed on the screen?
I don't know. However, since this is new userspace ABI which should stay
compatible forever, we should make sure to do it right. Using __s32 instead of
__u32 won't limit us in the future.
baruch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
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] include: fb: Add definiton for window positioning structure
On 09/20/2011 03:39 PM, Tomi Valkeinen wrote:
> On Tue, 2011-09-20 at 20:16 +0530, Ajay kumar wrote:
>> Hi Tomi,
>>
>> On Tue, Sep 20, 2011 at 4:40 PM, Tomi Valkeinen
>> wrote:
>>> On Tue, 2011-09-20 at 11:30 -0400, Ajay Kumar wrote:
This patch adds a data structure definiton to hold framebuffer
windows/planes.
An ioctl number is also added to provide user access
to change window position dynamically.
Ajay, do you need this urgently or can we delay this one merge window? I don't
think that a week or so is enough to get a consistent API that gets everything
right. So if you have a pressing need to have it within the 3.2 kernel I'd
prefer to do it only for your driver now and adjust it when we get the thing
done, probably in 3.3.
Signed-off-by: Ajay Kumar
Signed-off-by: Banajit Goswami
Suggested-by: Marek Szyprowski
---
include/linux/fb.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 1d6836c..2141941 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -39,6 +39,7 @@
#define FBIOPUT_MODEINFO0x4617
#define FBIOGET_DISPINFO0x4618
#define FBIO_WAITFORVSYNC_IOW('F', 0x20, __u32)
+#define FBIOPOS_OVERLAY_WIN _IOW('F', 0x21, struct fb_overlay_win_pos)
#define FB_TYPE_PACKED_PIXELS0 /* Packed Pixels
*/
#define FB_TYPE_PLANES 1 /* Non interleaved
planes */
@@ -366,6 +367,12 @@ struct fb_image {
struct fb_cmap cmap;/* color map info */
};
+/* Window overlaying */
+struct fb_overlay_win_pos {
+ __u32 win_pos_x;/* x-offset from LCD(0,0) where window
starts */
+ __u32 win_pos_y;/* y-offset from LCD(0,0) where window
starts */
+};
>>>
>>> Shouldn't this also include the window size (in case scaling is
>>> supported)?
>>
>> The "xres" and "yres" fields in fb_var_screeninfo are being used to
>> represent the size of the window (visible resolution). So we have,
>>
>> win_pos_x: x-offset from LCD(0,0) where window starts.
>> win_pos_y: y-offset from LCD(0,0) where window starts.
>> (win_pos_x + xres) : x-offset from LCD(0,0) where window ends.
>> (win_pos_y + yres) : y-offset from LCD(0,0) where window ends.
>
> Sure, but the xres and yres tell the _input_ resolution, i.e. how many
> pixels are read from the memory. What is missing is the _output_
> resolution, which is the size of the window. These are not necessarily
> the same, if the system supports scaling.
I agree, scaling is an issue that should get solved on the way. So adding
u32 width, height;
with an initial/special value of 0 which means just take what the source
width/height is.
>>> This also won't work for setups where the same framebuffer is used by
>>> multiple overlays. For example, this is the case on OMAP when the same
>>> content is cloned to, say, LCD and TV, each of which is showing an
>>> overlay.
>>
>> These x and y position are used to configure the display controller
>> (for LCD only) and not to alter the data in physical buffer
>> (framebuffer). Could you elaborate the above use case you have
>> mentioned and how adding the x and y offsets would not meet that
>> requirement.
>
> Nothing wrong with adding x/y offsets, but the problem is in configuring
> the two overlays. If the framebuffer data is used by two overlays, each
> overlay should be configured separately. And your ioctl does not have
> any way to define which overlay is being affected.
Did you have a look at the (existing) API [1] Laurent proposed for discovering
the internal connections between the framebuffers (or with any other devices)?
If you agree that it'd be a good idea to use it I feel that we should make the
windowing API more compatible with it. So basically what we want to have as a
window is one or more sunk pads so the pad-index should be also part of the
interface. I'm still confused with how OMAP works when it does not have a "root"
window/framebuffer. Normally I feel that the window position should be a
property of the parent window as this is what the position is relative too. But
if the parent is no framebuffer, should we also include the entity into the
interface to allow configuring things that are nor even framebuffers?
Also I think we need a z-index in case overlays overlap (might happen or?) and
enforcing that all z-indexes are different for the same entity.
> Of course, if we specify that a single framebuffer will ever go only to
> one output, the problem disappears.
>
> However, even if we specify so, this will make the fbdev a bit weird:
> what is x/yres after this patch? In the current fbdev x/yres is the size
> of the output, and x/yres are part of video timings. After this patch
> this is no longer the case: x/yres will be the size of the overlay. But
> the o
Re: [PATCH 1/3] include: fb: Add definiton for window positioning structure
On Tue, 2011-09-20 at 20:16 +0530, Ajay kumar wrote:
> Hi Tomi,
>
> On Tue, Sep 20, 2011 at 4:40 PM, Tomi Valkeinen wrote:
> > On Tue, 2011-09-20 at 11:30 -0400, Ajay Kumar wrote:
> >> This patch adds a data structure definiton to hold framebuffer
> >> windows/planes.
> >> An ioctl number is also added to provide user access
> >> to change window position dynamically.
> >>
> >> Signed-off-by: Ajay Kumar
> >> Signed-off-by: Banajit Goswami
> >> Suggested-by: Marek Szyprowski
> >> ---
> >> include/linux/fb.h |7 +++
> >> 1 files changed, 7 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/include/linux/fb.h b/include/linux/fb.h
> >> index 1d6836c..2141941 100644
> >> --- a/include/linux/fb.h
> >> +++ b/include/linux/fb.h
> >> @@ -39,6 +39,7 @@
> >> #define FBIOPUT_MODEINFO0x4617
> >> #define FBIOGET_DISPINFO0x4618
> >> #define FBIO_WAITFORVSYNC_IOW('F', 0x20, __u32)
> >> +#define FBIOPOS_OVERLAY_WIN _IOW('F', 0x21, struct fb_overlay_win_pos)
> >>
> >> #define FB_TYPE_PACKED_PIXELS0 /* Packed Pixels
> >>*/
> >> #define FB_TYPE_PLANES 1 /* Non interleaved
> >> planes */
> >> @@ -366,6 +367,12 @@ struct fb_image {
> >> struct fb_cmap cmap;/* color map info */
> >> };
> >>
> >> +/* Window overlaying */
> >> +struct fb_overlay_win_pos {
> >> + __u32 win_pos_x;/* x-offset from LCD(0,0) where window
> >> starts */
> >> + __u32 win_pos_y;/* y-offset from LCD(0,0) where window
> >> starts */
> >> +};
> >
> > Shouldn't this also include the window size (in case scaling is
> > supported)?
>
> The "xres" and "yres" fields in fb_var_screeninfo are being used to
> represent the size of the window (visible resolution). So we have,
>
> win_pos_x: x-offset from LCD(0,0) where window starts.
> win_pos_y: y-offset from LCD(0,0) where window starts.
> (win_pos_x + xres) : x-offset from LCD(0,0) where window ends.
> (win_pos_y + yres) : y-offset from LCD(0,0) where window ends.
Sure, but the xres and yres tell the _input_ resolution, i.e. how many
pixels are read from the memory. What is missing is the _output_
resolution, which is the size of the window. These are not necessarily
the same, if the system supports scaling.
> > This also won't work for setups where the same framebuffer is used by
> > multiple overlays. For example, this is the case on OMAP when the same
> > content is cloned to, say, LCD and TV, each of which is showing an
> > overlay.
>
> These x and y position are used to configure the display controller
> (for LCD only) and not to alter the data in physical buffer
> (framebuffer). Could you elaborate the above use case you have
> mentioned and how adding the x and y offsets would not meet that
> requirement.
Nothing wrong with adding x/y offsets, but the problem is in configuring
the two overlays. If the framebuffer data is used by two overlays, each
overlay should be configured separately. And your ioctl does not have
any way to define which overlay is being affected.
Of course, if we specify that a single framebuffer will ever go only to
one output, the problem disappears.
However, even if we specify so, this will make the fbdev a bit weird:
what is x/yres after this patch? In the current fbdev x/yres is the size
of the output, and x/yres are part of video timings. After this patch
this is no longer the case: x/yres will be the size of the overlay. But
the old code will still use x/yres as part of video timings, making
things confusing.
And generally I can't really make my mind about adding these more
complex features. On one hand it would be very nice to have fbdev
supporting overlays and whatnot, but on the other hand, I can't figure
out how to add them properly.
Tomi
--
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] include: fb: Add definiton for window positioning structure
Hi Baruch,
On Tue, Sep 20, 2011 at 4:54 PM, Baruch Siach wrote:
> Hi Ajay,
>
> On Tue, Sep 20, 2011 at 11:30:39AM -0400, Ajay Kumar wrote:
>> This patch adds a data structure definiton to hold framebuffer
>> windows/planes.
>> An ioctl number is also added to provide user access
>> to change window position dynamically.
>
> [snip]
>
>> +/* Window overlaying */
>> +struct fb_overlay_win_pos {
>> + __u32 win_pos_x; /* x-offset from LCD(0,0) where window starts
>> */
>> + __u32 win_pos_y; /* y-offset from LCD(0,0) where window starts
>> */
>> +};
>
> Why not allow negative offsets where the left or upper part of the framebuffer
> is hidden?
Thanks for pointing it out. Are there drivers which place the overlay
windows such that some part of the window is hidden from being
displayed on the screen?
> baruch
>
> --
> ~. .~ Tk Open Systems
> =}ooO--U--Ooo{=
> - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
> --
> 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
>
Ajay
--
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] include: fb: Add definiton for window positioning structure
Hi Tomi,
On Tue, Sep 20, 2011 at 4:40 PM, Tomi Valkeinen wrote:
> On Tue, 2011-09-20 at 11:30 -0400, Ajay Kumar wrote:
>> This patch adds a data structure definiton to hold framebuffer
>> windows/planes.
>> An ioctl number is also added to provide user access
>> to change window position dynamically.
>>
>> Signed-off-by: Ajay Kumar
>> Signed-off-by: Banajit Goswami
>> Suggested-by: Marek Szyprowski
>> ---
>> include/linux/fb.h | 7 +++
>> 1 files changed, 7 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/fb.h b/include/linux/fb.h
>> index 1d6836c..2141941 100644
>> --- a/include/linux/fb.h
>> +++ b/include/linux/fb.h
>> @@ -39,6 +39,7 @@
>> #define FBIOPUT_MODEINFO 0x4617
>> #define FBIOGET_DISPINFO 0x4618
>> #define FBIO_WAITFORVSYNC _IOW('F', 0x20, __u32)
>> +#define FBIOPOS_OVERLAY_WIN _IOW('F', 0x21, struct fb_overlay_win_pos)
>>
>> #define FB_TYPE_PACKED_PIXELS 0 /* Packed Pixels
>> */
>> #define FB_TYPE_PLANES 1 /* Non interleaved
>> planes */
>> @@ -366,6 +367,12 @@ struct fb_image {
>> struct fb_cmap cmap; /* color map info */
>> };
>>
>> +/* Window overlaying */
>> +struct fb_overlay_win_pos {
>> + __u32 win_pos_x; /* x-offset from LCD(0,0) where window starts
>> */
>> + __u32 win_pos_y; /* y-offset from LCD(0,0) where window starts
>> */
>> +};
>
> Shouldn't this also include the window size (in case scaling is
> supported)?
The "xres" and "yres" fields in fb_var_screeninfo are being used to
represent the size of the window (visible resolution). So we have,
win_pos_x: x-offset from LCD(0,0) where window starts.
win_pos_y: y-offset from LCD(0,0) where window starts.
(win_pos_x + xres) : x-offset from LCD(0,0) where window ends.
(win_pos_y + yres) : y-offset from LCD(0,0) where window ends.
> This also won't work for setups where the same framebuffer is used by
> multiple overlays. For example, this is the case on OMAP when the same
> content is cloned to, say, LCD and TV, each of which is showing an
> overlay.
These x and y position are used to configure the display controller
(for LCD only) and not to alter the data in physical buffer
(framebuffer). Could you elaborate the above use case you have
mentioned and how adding the x and y offsets would not meet that
requirement.
> Tomi
>
Ajay
--
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] include: fb: Add definiton for window positioning structure
Hi Ajay,
On Tue, Sep 20, 2011 at 11:30:39AM -0400, Ajay Kumar wrote:
> This patch adds a data structure definiton to hold framebuffer windows/planes.
> An ioctl number is also added to provide user access
> to change window position dynamically.
[snip]
> +/* Window overlaying */
> +struct fb_overlay_win_pos {
> + __u32 win_pos_x;/* x-offset from LCD(0,0) where window starts */
> + __u32 win_pos_y;/* y-offset from LCD(0,0) where window starts */
> +};
Why not allow negative offsets where the left or upper part of the framebuffer
is hidden?
baruch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
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] include: fb: Add definiton for window positioning structure
On Tue, 2011-09-20 at 11:30 -0400, Ajay Kumar wrote:
> This patch adds a data structure definiton to hold framebuffer windows/planes.
> An ioctl number is also added to provide user access
> to change window position dynamically.
>
> Signed-off-by: Ajay Kumar
> Signed-off-by: Banajit Goswami
> Suggested-by: Marek Szyprowski
> ---
> include/linux/fb.h |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 1d6836c..2141941 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -39,6 +39,7 @@
> #define FBIOPUT_MODEINFO0x4617
> #define FBIOGET_DISPINFO0x4618
> #define FBIO_WAITFORVSYNC_IOW('F', 0x20, __u32)
> +#define FBIOPOS_OVERLAY_WIN _IOW('F', 0x21, struct fb_overlay_win_pos)
>
> #define FB_TYPE_PACKED_PIXELS0 /* Packed Pixels
> */
> #define FB_TYPE_PLANES 1 /* Non interleaved
> planes */
> @@ -366,6 +367,12 @@ struct fb_image {
> struct fb_cmap cmap;/* color map info */
> };
>
> +/* Window overlaying */
> +struct fb_overlay_win_pos {
> + __u32 win_pos_x;/* x-offset from LCD(0,0) where window starts */
> + __u32 win_pos_y;/* y-offset from LCD(0,0) where window starts */
> +};
Shouldn't this also include the window size (in case scaling is
supported)?
This also won't work for setups where the same framebuffer is used by
multiple overlays. For example, this is the case on OMAP when the same
content is cloned to, say, LCD and TV, each of which is showing an
overlay.
Tomi
--
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] mmc: card: modify mmc_getgeo function
In the earlier code the cylinder, sector and head are assigned
independently. Current patch generates the cylinder number
with the values of sector and head.
This patch only makes they cylinder value to be dependent on
the sector and head.
Signed-off-by: Girish K S
---
drivers/mmc/card/block.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 1ff5486..bebb13b 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -226,9 +226,10 @@ static int mmc_blk_release(struct gendisk *disk, fmode_t
mode)
static int
mmc_blk_getgeo(struct block_device *bdev, struct hd_geometry *geo)
{
- geo->cylinders = get_capacity(bdev->bd_disk) / (4 * 16);
geo->heads = 4;
geo->sectors = 16;
+ geo->cylinders = get_capacity(bdev->bd_disk) /
+ (geo->heads * geo->sectors);
return 0;
}
--
1.7.1
--
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 3/3] video: s3c-fb: Modify s3c-fb driver to support window positioning
Positions the framebuffer window during driver initialization,
using the platform data.It also adds an ioctl definition
to change window position dynamically.
Signed-off-by: Ajay Kumar
Signed-off-by: Banajit Goswami
Suggested-by: Marek Szyprowski
---
drivers/video/s3c-fb.c | 37 -
1 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
index 0fda252..b087a12 100644
--- a/drivers/video/s3c-fb.c
+++ b/drivers/video/s3c-fb.c
@@ -441,6 +441,7 @@ static int s3c_fb_set_par(struct fb_info *info)
{
struct fb_var_screeninfo *var = &info->var;
struct s3c_fb_win *win = info->par;
+ struct fb_overlay_win_pos *winpos = &win->windata->winpos;
struct s3c_fb *sfb = win->parent;
void __iomem *regs = sfb->regs;
void __iomem *buf = regs;
@@ -539,12 +540,13 @@ static int s3c_fb_set_par(struct fb_info *info)
/* write 'OSD' registers to control position of framebuffer */
- data = VIDOSDxA_TOPLEFT_X(0) | VIDOSDxA_TOPLEFT_Y(0);
+ data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
+ VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
writel(data, regs + VIDOSD_A(win_no, sfb->variant));
- data = VIDOSDxB_BOTRIGHT_X(s3c_fb_align_word(var->bits_per_pixel,
-var->xres - 1)) |
- VIDOSDxB_BOTRIGHT_Y(var->yres - 1);
+ data = VIDOSDxB_BOTRIGHT_X((s3c_fb_align_word(var->bits_per_pixel,
+ (winpos->win_pos_x + var->xres - 1 |
+ VIDOSDxB_BOTRIGHT_Y((winpos->win_pos_y + var->yres - 1));
writel(data, regs + VIDOSD_B(win_no, sfb->variant));
@@ -998,9 +1000,11 @@ static int s3c_fb_ioctl(struct fb_info *info, unsigned
int cmd,
unsigned long arg)
{
struct s3c_fb_win *win = info->par;
+ struct fb_overlay_win_pos *winpos = &win->windata->winpos;
struct s3c_fb *sfb = win->parent;
- int ret;
+ int ret = 0;
u32 crtc;
+ u32 data;
switch (cmd) {
case FBIO_WAITFORVSYNC:
@@ -1011,6 +1015,29 @@ static int s3c_fb_ioctl(struct fb_info *info, unsigned
int cmd,
ret = s3c_fb_wait_for_vsync(sfb, crtc);
break;
+ case FBIOPOS_OVERLAY_WIN:
+ if (copy_from_user(winpos, (u32 __user *)arg,
+ sizeof(struct fb_overlay_win_pos))) {
+ ret = -EFAULT;
+ break;
+ }
+
+ shadow_protect_win(win, 1);
+
+ /* write 'OSD' registers to set position of the window */
+ data = VIDOSDxA_TOPLEFT_X(winpos->win_pos_x) |
+ VIDOSDxA_TOPLEFT_Y(winpos->win_pos_y);
+ writel(data, sfb->regs + VIDOSD_A(win->index, sfb->variant));
+
+ data = VIDOSDxB_BOTRIGHT_X(
+ s3c_fb_align_word(info->var.bits_per_pixel,
+ (winpos->win_pos_x + info->var.xres - 1)));
+ data |= VIDOSDxB_BOTRIGHT_Y(winpos->win_pos_y +
+ info->var.yres - 1);
+ writel(data, sfb->regs + VIDOSD_B(win->index, sfb->variant));
+
+ shadow_protect_win(win, 0);
+ break;
default:
ret = -ENOTTY;
}
--
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 2/3] ARM: SAMSUNG: Embed window positioning data structure in s3c-fb plat data
This patch adds a new field in s3c_fb_pd_win structure,
thereby allowing the user to place window at the desired position.
Signed-off-by: Ajay Kumar
Signed-off-by: Banajit Goswami
Suggested-by: Marek Szyprowski
---
arch/arm/plat-samsung/include/plat/fb.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/fb.h
b/arch/arm/plat-samsung/include/plat/fb.h
index 0fedf47..920decd 100644
--- a/arch/arm/plat-samsung/include/plat/fb.h
+++ b/arch/arm/plat-samsung/include/plat/fb.h
@@ -27,6 +27,7 @@
* @win_mode: The display parameters to initialise (not for window 0)
* @virtual_x: The virtual X size.
* @virtual_y: The virtual Y size.
+ * @winpos: Position of overlayed window w.r.t the LCD screen.
*/
struct s3c_fb_pd_win {
struct fb_videomode win_mode;
@@ -35,6 +36,8 @@ struct s3c_fb_pd_win {
unsigned short max_bpp;
unsigned short virtual_x;
unsigned short virtual_y;
+
+ struct fb_overlay_win_pos winpos;
};
/**
--
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 1/3] include: fb: Add definiton for window positioning structure
This patch adds a data structure definiton to hold framebuffer windows/planes.
An ioctl number is also added to provide user access
to change window position dynamically.
Signed-off-by: Ajay Kumar
Signed-off-by: Banajit Goswami
Suggested-by: Marek Szyprowski
---
include/linux/fb.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 1d6836c..2141941 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -39,6 +39,7 @@
#define FBIOPUT_MODEINFO0x4617
#define FBIOGET_DISPINFO0x4618
#define FBIO_WAITFORVSYNC _IOW('F', 0x20, __u32)
+#define FBIOPOS_OVERLAY_WIN_IOW('F', 0x21, struct fb_overlay_win_pos)
#define FB_TYPE_PACKED_PIXELS 0 /* Packed Pixels*/
#define FB_TYPE_PLANES 1 /* Non interleaved planes */
@@ -366,6 +367,12 @@ struct fb_image {
struct fb_cmap cmap;/* color map info */
};
+/* Window overlaying */
+struct fb_overlay_win_pos {
+ __u32 win_pos_x;/* x-offset from LCD(0,0) where window starts */
+ __u32 win_pos_y;/* y-offset from LCD(0,0) where window starts */
+};
+
/*
* hardware cursor control
*/
--
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 0/3] FB: Add window positioning support
This patchset adds support for positioning the overlay windows on the LCD. These patches are based on the discussion about adding features to fbdev at: http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg06292.html To Florian: include: fb: Add definiton for window positioning structure video: s3c-fb: Modify s3c-fb driver to support window positioning To Kukjin, ARM: SAMSUNG: Embed window positioning data structure in s3c-fb plat data arch/arm/plat-samsung/include/plat/fb.h |3 ++ drivers/video/s3c-fb.c | 37 ++ include/linux/fb.h |7 ++ 3 files changed, 42 insertions(+), 5 deletions(-) -- 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
