[PATCH 0/3] FB: Add window positioning support

2011-09-20 Thread Ajay Kumar
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


[PATCH 1/3] include: fb: Add definiton for window positioning structure

2011-09-20 Thread Ajay Kumar
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 ajaykumar...@samsung.com
Signed-off-by: Banajit Goswami banaji...@samsung.com
Suggested-by: Marek Szyprowski m.szyprow...@samsung.com
---
 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 2/3] ARM: SAMSUNG: Embed window positioning data structure in s3c-fb plat data

2011-09-20 Thread Ajay Kumar
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 ajaykumar...@samsung.com
Signed-off-by: Banajit Goswami banaji...@samsung.com
Suggested-by: Marek Szyprowski m.szyprow...@samsung.com
---
 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 3/3] video: s3c-fb: Modify s3c-fb driver to support window positioning

2011-09-20 Thread Ajay Kumar
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 ajaykumar...@samsung.com
Signed-off-by: Banajit Goswami banaji...@samsung.com
Suggested-by: Marek Szyprowski m.szyprow...@samsung.com
---
 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] mmc: card: modify mmc_getgeo function

2011-09-20 Thread Girish K S
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 girish.shivananja...@linaro.org
---
 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


Re: [PATCH 1/3] include: fb: Add definiton for window positioning structure

2011-09-20 Thread Tomi Valkeinen
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 ajaykumar...@samsung.com
 Signed-off-by: Banajit Goswami banaji...@samsung.com
 Suggested-by: Marek Szyprowski m.szyprow...@samsung.com
 ---
  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


Re: [PATCH 1/3] include: fb: Add definiton for window positioning structure

2011-09-20 Thread Baruch Siach
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

2011-09-20 Thread Ajay kumar
Hi Tomi,

On Tue, Sep 20, 2011 at 4:40 PM, Tomi Valkeinen tomi.valkei...@ti.com 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 ajaykumar...@samsung.com
 Signed-off-by: Banajit Goswami banaji...@samsung.com
 Suggested-by: Marek Szyprowski m.szyprow...@samsung.com
 ---
  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

2011-09-20 Thread Ajay kumar
Hi Baruch,

On Tue, Sep 20, 2011 at 4:54 PM, Baruch Siach bar...@tkos.co.il 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

2011-09-20 Thread Tomi Valkeinen
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 tomi.valkei...@ti.com 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 ajaykumar...@samsung.com
  Signed-off-by: Banajit Goswami banaji...@samsung.com
  Suggested-by: Marek Szyprowski m.szyprow...@samsung.com
  ---
   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

2011-09-20 Thread Florian Tobias Schandinat
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 tomi.valkei...@ti.com 
 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 ajaykumar...@samsung.com
 Signed-off-by: Banajit Goswami banaji...@samsung.com
 Suggested-by: Marek Szyprowski m.szyprow...@samsung.com
 ---
  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 old code will still use x/yres as part of video timings, making
 things confusing.

As I see it xres/yres (together with xoffset/yoffset) is 

Re: [PATCH 1/3] include: fb: Add definiton for window positioning structure

2011-09-20 Thread Baruch Siach
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 bar...@tkos.co.il 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

2011-09-20 Thread Tomi Valkeinen
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: [GIT PULL] Samsung cleanup for v3.2

2011-09-20 Thread Arnd Bergmann
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 kgene@samsung.com */
 -  .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: [GIT PULL] Samsung boards for v3.2

2011-09-20 Thread Arnd Bergmann
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: [PATCH 4/7] gpio/samsung: Remove useless old Samsung related GPIO drivers

2011-09-20 Thread Grant Likely
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 ben-li...@fluff.org
 Cc: Grant Likely grant.lik...@secretlab.ca
 Signed-off-by: Kukjin Kim kgene@samsung.com

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: [PATCH 1/7 (RE-SEND)] gpio/s3c24xx: move gpio driver into drivers/gpio/

2011-09-20 Thread Grant Likely
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 100644 arch/arm/plat-s3c24xx/include/plat/map.h
  delete mode 100644 

RE: [PATCH 5/7] gpio/samsung: Added gpio-samsung.c to support Samsung GPIOs

2011-09-20 Thread Kukjin Kim
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 ben-li...@fluff.org
  Cc: Grant Likely grant.lik...@secretlab.ca
  Signed-off-by: Kukjin Kim kgene@samsung.com
  ---
   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 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 5/7] gpio/samsung: Added gpio-samsung.c to support Samsung GPIOs

2011-09-20 Thread Grant Likely
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 ben-li...@fluff.org
 Cc: Grant Likely grant.lik...@secretlab.ca
 Signed-off-by: Kukjin Kim kgene@samsung.com
 ---
  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 1/7 (RE-SEND)] gpio/s3c24xx: move gpio driver into drivers/gpio/

2011-09-20 Thread Kukjin Kim
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 kgene@samsung.com, 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/gpio/gpio-samsung.c| 2686
  
   53 files changed, 3072 insertions(+), 3534 deletions(-)
   delete mode 

RE: [GIT PULL] Samsung boards for v3.2

2011-09-20 Thread Kukjin Kim
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 tushar.beh...@linaro.org
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 nicolas.pi...@linaro.org
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
Signed-off-by: Kukjin Kim kgene@samsung.com

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 jh...@insignal.co.kr */
-   .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 kgene@samsung.com */
-   .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 kgene@samsung.com */
-   .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 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: [GIT PULL] Samsung cleanup for v3.2

2011-09-20 Thread Kukjin Kim
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 kgene@samsung.com */
  -  .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 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


[PATCH] serial: samsung: move handling of fclk/n clock to platform code

2011-09-20 Thread Thomas Abraham
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 ben-li...@fluff.org
Cc: Vasily Khoruzhick anars...@gmail.com
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
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 linux/mutex.h
 #include linux/clk.h
 #include linux/io.h
+#include linux/serial_core.h
 
 #include mach/hardware.h
 #include linux/atomic.h
@@ -43,6 +44,7 @@
 
 #include plat/clock.h
 #include plat/cpu.h
+#include plat/regs-serial.h
 
 /* 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 

[PATCH V2 0/3] Add TVOUT support for SMDKV310

2011-09-20 Thread Hatim Ali
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 V2 1/3] ARM: EXYNOS4: Add TVOUT support for SMDKV310

2011-09-20 Thread Hatim Ali
Add support for TVOUT on SMDKV310 board.

Signed-off-by: Hatim Ali hatim...@samsung.com
---
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


[RESEND PATCH 2/3] ARM: EXYNOS4: Update consistent DMA size to 8MB

2011-09-20 Thread Hatim Ali
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 hatim...@samsung.com
---
 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


[RESEND PATCH 3/3] s5p-tv: Add PM_RUNTIME dependency

2011-09-20 Thread Hatim Ali
The TVOUT driver requires PM_RUNTIME support for proper clock
enabling.

Signed-off-by: Hatim Ali hatim...@samsung.com
---
 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