Re: [PATCH V3] watchdog: s3c2410_wdt: remove the global variables

2013-07-30 Thread Leela Krishna Amudala 
Hello Wim Van Sebroeck,

Can you please review this patch and take necessary action.

Best Wishes,
Leela Krishna Amudala.


On Wed, Jul 24, 2013 at 1:23 PM, Kukjin Kim kg...@kernel.org wrote:
 Leela Krishna Amudala wrote:

 This patch removes the global variables in the driver file and
 group them into a structure.

 Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com

 (+ Wim Van Sebroeck)

 Looks good to me,

 Acked-by: Kukjin Kim kgene@samsung.com

 Thanks,
 Kukjin

 ---
  Note: This patch is rebased on kgene's for-next branch and tested on
 SMDK5420.

  Changes since V2:
   - Addressed comments given by Tomasz Figa t.f...@samsung.com
 https://patchwork.kernel.org/patch/2831032/
   - Renamed structure name from s3c2410_watchdog to s3c2410_wdt.

  Changes since V1:
   - changed the patch subject.
   - indentation correction in s3c2410_watchdog structure.

  drivers/watchdog/s3c2410_wdt.c |  225 +++
 -
  1 file changed, 131 insertions(+), 94 deletions(-)

 diff --git a/drivers/watchdog/s3c2410_wdt.c
 b/drivers/watchdog/s3c2410_wdt.c
 index 6a22cf5..739dbd3 100644
 --- a/drivers/watchdog/s3c2410_wdt.c
 +++ b/drivers/watchdog/s3c2410_wdt.c
 @@ -84,13 +84,17 @@ MODULE_PARM_DESC(soft_noboot, Watchdog action, set to
 1 to ignore reboots, 
   0 to reboot (default 0));
  MODULE_PARM_DESC(debug, Watchdog debug, set to 1 for debug (default
 0));

 -static struct device*wdt_dev;/* platform device attached to */
 -static struct resource   *wdt_mem;
 -static struct resource   *wdt_irq;
 -static struct clk*wdt_clock;
 -static void __iomem  *wdt_base;
 -static unsigned int   wdt_count;
 -static DEFINE_SPINLOCK(wdt_lock);
 +struct s3c2410_wdt {
 + struct device   *dev;
 + struct clk  *clock;
 + void __iomem*reg_base;
 + unsigned intcount;
 + spinlock_t  lock;
 + unsigned long   wtcon_save;
 + unsigned long   wtdat_save;
 + struct watchdog_device  wdt_device;
 + struct notifier_block   freq_transition;
 +};

  /* watchdog control routines */

 @@ -102,29 +106,43 @@ do {
 \

  /* functions */

 +static inline struct s3c2410_wdt *to_s3c2410_wdt(struct watchdog_device
 *wdd)
 +{
 + return container_of(wdd, struct s3c2410_wdt, wdt_device);
 +}
 +
 +static inline struct s3c2410_wdt *freq_to_wdt(struct notifier_block *nb)
 +{
 + return container_of(nb, struct s3c2410_wdt, freq_transition);
 +}
 +
  static int s3c2410wdt_keepalive(struct watchdog_device *wdd)
  {
 - spin_lock(wdt_lock);
 - writel(wdt_count, wdt_base + S3C2410_WTCNT);
 - spin_unlock(wdt_lock);
 + struct s3c2410_wdt *wdt = to_s3c2410_wdt(wdd);
 +
 + spin_lock(wdt-lock);
 + writel(wdt-count, wdt-reg_base + S3C2410_WTCNT);
 + spin_unlock(wdt-lock);

   return 0;
  }

 -static void __s3c2410wdt_stop(void)
 +static void __s3c2410wdt_stop(struct s3c2410_wdt *wdt)
  {
   unsigned long wtcon;

 - wtcon = readl(wdt_base + S3C2410_WTCON);
 + wtcon = readl(wdt-reg_base + S3C2410_WTCON);
   wtcon = ~(S3C2410_WTCON_ENABLE | S3C2410_WTCON_RSTEN);
 - writel(wtcon, wdt_base + S3C2410_WTCON);
 + writel(wtcon, wdt-reg_base + S3C2410_WTCON);
  }

  static int s3c2410wdt_stop(struct watchdog_device *wdd)
  {
 - spin_lock(wdt_lock);
 - __s3c2410wdt_stop();
 - spin_unlock(wdt_lock);
 + struct s3c2410_wdt *wdt = to_s3c2410_wdt(wdd);
 +
 + spin_lock(wdt-lock);
 + __s3c2410wdt_stop(wdt);
 + spin_unlock(wdt-lock);

   return 0;
  }
 @@ -132,12 +150,13 @@ static int s3c2410wdt_stop(struct watchdog_device
 *wdd)
  static int s3c2410wdt_start(struct watchdog_device *wdd)
  {
   unsigned long wtcon;
 + struct s3c2410_wdt *wdt = to_s3c2410_wdt(wdd);

 - spin_lock(wdt_lock);
 + spin_lock(wdt-lock);

 - __s3c2410wdt_stop();
 + __s3c2410wdt_stop(wdt);

 - wtcon = readl(wdt_base + S3C2410_WTCON);
 + wtcon = readl(wdt-reg_base + S3C2410_WTCON);
   wtcon |= S3C2410_WTCON_ENABLE | S3C2410_WTCON_DIV128;

   if (soft_noboot) {
 @@ -148,25 +167,26 @@ static int s3c2410wdt_start(struct watchdog_device
 *wdd)
   wtcon |= S3C2410_WTCON_RSTEN;
   }

 - DBG(%s: wdt_count=0x%08x, wtcon=%08lx\n,
 - __func__, wdt_count, wtcon);
 + DBG(%s: count=0x%08x, wtcon=%08lx\n,
 + __func__, wdt-count, wtcon);

 - writel(wdt_count, wdt_base + S3C2410_WTDAT);
 - writel(wdt_count, wdt_base + S3C2410_WTCNT);
 - writel(wtcon, wdt_base + S3C2410_WTCON);
 - spin_unlock(wdt_lock);
 + writel(wdt-count, wdt-reg_base + S3C2410_WTDAT);
 + writel(wdt-count, wdt-reg_base + S3C2410_WTCNT);
 + writel(wtcon, wdt-reg_base + S3C2410_WTCON);
 + spin_unlock(wdt-lock);

   return 0;
  }

 -static inline int s3c2410wdt_is_running(void)
 +static inline int s3c2410wdt_is_running(struct s3c2410_wdt *wdt)
  {
 - return

Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control

2013-07-30 Thread Seung-Woo Kim 
Hi Rahul,

On 2013년 07월 30일 12:42, Rahul Sharma wrote:
 
 
 On Tue, Jun 18, 2013 at 5:07 PM, Kishon Vijay Abraham I kis...@ti.com
 mailto:kis...@ti.com wrote:
 
 Hi,
 
 On Tuesday 18 June 2013 03:33 PM, Rahul Sharma wrote:
  Thanks all,
 
  On Fri, Jun 14, 2013 at 11:39 AM, 김승우 sw0312@samsung.com
 mailto:sw0312@samsung.com wrote:
  Hello Kishon,
 
  On 2013년 06월 13일 21:54, Kishon Vijay Abraham I wrote:
  Hi,
 
  On Thursday 13 June 2013 04:51 PM, Inki Dae wrote:
 
 
  -Original Message-
  From: Sylwester Nawrocki [mailto:s.nawro...@samsung.com
 mailto:s.nawro...@samsung.com]
  Sent: Thursday, June 13, 2013 5:56 PM
  To: Rahul Sharma
  Cc: Rahul Sharma; Inki Dae; linux-samsung-soc@vger.kernel.org
 mailto:linux-samsung-soc@vger.kernel.org;
  devicetree-
  disc...@lists.ozlabs.org mailto:disc...@lists.ozlabs.org;
 DRI mailing list; Kukjin Kim; Seung-Woo Kim;
  Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren;
  grant.lik...@linaro.org mailto:grant.lik...@linaro.org
  Subject: Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy
 clock with
  pmu reg control
 
  Hi,
 
  On 06/13/2013 06:26 AM, Rahul Sharma wrote:
  Mr. Dae,
 
  Thanks for your valuable inputs.
 
  I posted it as RFC because, I also have received comments to
 register
  hdmiphy as a clock controller. As we always configure it for
 specific
  frequency, hdmi-phy looks similar to a PLL. But it really doesn't
  belong to that class. Secondly prior to exynos5420, it was a i2c
  device. I am not sure we can register a I2C device as a clock
  controller. I wanted to discuss and explore this option here.
 
  Have you considered using the generic PHY framework for those HDMI
  PHY devices [1] ? I guess we could add a dedicated group of
 ops for
  video PHYs, similarly as is is done with struct
 v4l2_subdev_ops. For
  configuring things like the carrier/pixel clock frequency or
 anything
  what's common across the video PHYs.
 
  Perhaps you could have a look and see if this framework would be
  useful for HDMI and possibly point out anything what might be
 missing ?
 
  I'm not sure it it really solves the issues specific to the Exynos
  HDMI but at least with a generic PHY driver the PHY module
 would be
  separate from the PHY controller, as often same HDMI DPHY can
 be used
  with various types of a HDMI controller. So this would allow
 to not
  duplicate the HDMI PHY drivers in the long-term perspective.
 
  Yeah, at least, it seems that we could use PHY module to
 control PMU
  register, HDMI_PHY_CONTROL. However, PHY module provides only
 init/on/off
  callbacks. As you may know, HDMIPHY needs i2c interfaces to control
  HDMIPHY
  clock. So with PHY module, HDMIPHY driver could enable PMU more
  generically,
  but also has to use existing i2c stuff to control HDMIPHY
 clock. I had a
  quick review to Generic PHY Framework[v6] but I didn't see that
 the PHY
  module could generically support more features such as i2c stuff.
 
  I don't think PHY framework needs to provide i2c interfaces to
 program
  certain configurations. Instead in one of the callbacks
 (init/on/off)
  PHY driver can program whatever it wants using any of the
 interfaces it
  needs. IMO PHY framework should work independent of the interfaces.
 
  In exnoys hdmi case, i2c interface is not the exact issue. In exynos
  hdmi, hdmiphy should send i2c configuration about video clock
  information as the video mode information including resolution,
 bit per
  pixel, refresh rate passed from drm subsystem. So init/on/off
 callbacks
  of phy framework are not enough for exynos hdmiphy and it should
 have a
  callback to set video mode.
 
  Do you have plan to add driver specific extend callback pointers
 to phy
  framework?
 
  Currently, hdmi directly calls phy operations, but Rahul's
 another patch
  set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and
 hdmiphy is
  connected with exynos hdmi own sub driver callback operations.
 
  IMHO, if phy framework can support extend callback feature, then this
  own sub driver callbacks can be replaced with phy framework at
 long term
  view.
 
  Extended callbacks are always welcome. I can also use phy device
  private data to pass on private ops like get_pixelclk and
 set_pixelclk.
 
 I would recommend creating a wrapper to the existing PHY framework
 for HDMI PHY. That way, we can have other HDMI phys added
 easily. We need to figure out all the ops that might be needed by the
 HDMI PHY to be added to the wrapper.
 IMO

Re: [PATCH 1/3] clk: exynos5250: Add G2D gate clock

2013-07-30 Thread Sachin Kamat 
On 30 July 2013 12:18, Mike Turquette mturque...@linaro.org wrote:
 Quoting Sachin Kamat (2013-07-27 06:29:56)
 On 27 July 2013 01:48, Mike Turquette mturque...@linaro.org wrote:
  Quoting Sachin Kamat (2013-07-05 01:42:27)
  Adds gate clock for G2D IP for Exynos5250 SoC.
 
  Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
  Cc: Mike Turquette mturque...@linaro.org
 
  I've taken patch #1 into clk-next.

 Thanks Mike.

 
  ---
  This patch depends on the following patch:
  http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20581
 
  I think I've gotten all three series you sent out, can you confirm?

 I haven't seen any update in your tree [1] since quite some time. The
 last commit I see in clk-next branch is 45e3ec3784 (clk: tegra: fix
 ifdef for tegra_periph_reset_assert inline). I hope I am looking at
 the right tree?

 You are, but I had not pushed to it since the merge window closed. It is
 now updated.


Thanks Mike. I confirm that all the three patch series that you
mentioned are applied in your tree.
Please check the below one too.

http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg20598.html

-- 
With warm regards,
Sachin
--
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 01/15] drivers: phy: add generic PHY framework

2013-07-30 Thread Felipe Balbi 
On Sun, Jul 21, 2013 at 08:46:53AM -0700, Greg KH wrote:
 On Sun, Jul 21, 2013 at 01:12:07PM +0200, Tomasz Figa wrote:
  On Sunday 21 of July 2013 16:37:33 Kishon Vijay Abraham I wrote:
   Hi,
   
   On Sunday 21 July 2013 04:01 PM, Tomasz Figa wrote:
Hi,

On Saturday 20 of July 2013 19:59:10 Greg KH wrote:
On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
On Sat, 20 Jul 2013, Greg KH wrote:
That should be passed using platform data.

Ick, don't pass strings around, pass pointers.  If you have
platform
data you can get to, then put the pointer there, don't use a
name.

I don't think I understood you here :-s We wont have phy pointer
when we create the device for the controller no?(it'll be done in
board file). Probably I'm missing something.

Why will you not have that pointer?  You can't rely on the name
as
the device id will not match up, so you should be able to rely on
the pointer being in the structure that the board sets up, right?

Don't use names, especially as ids can, and will, change, that is
going
to cause big problems.  Use pointers, this is C, we are supposed to
be
doing that :)

Kishon, I think what Greg means is this:  The name you are using
must
be stored somewhere in a data structure constructed by the board
file,
right?  Or at least, associated with some data structure somehow.
Otherwise the platform code wouldn't know which PHY hardware
corresponded to a particular name.

Greg's suggestion is that you store the address of that data
structure
in the platform data instead of storing the name string.  Have the
consumer pass the data structure's address when it calls phy_create,
instead of passing the name.  Then you don't have to worry about two
PHYs accidentally ending up with the same name or any other similar
problems.

Close, but the issue is that whatever returns from phy_create()
should
then be used, no need to call any find functions, as you can just
use
the pointer that phy_create() returns.  Much like all other class api
functions in the kernel work.

I think there is a confusion here about who registers the PHYs.

All platform code does is registering a platform/i2c/whatever device,
which causes a driver (located in drivers/phy/) to be instantiated.
Such drivers call phy_create(), usually in their probe() callbacks,
so platform_code has no way (and should have no way, for the sake of
layering) to get what phy_create() returns.
 
 Why not put pointers in the platform data structure that can hold these
 pointers?  I thought that is why we created those structures in the
 first place.  If not, what are they there for?

heh, IMO we shouldn't pass pointers of any kind through platform_data,
we want to pass data :-)

Allowing to pass pointers through that, is one of the reasons which got
us in such a big mess in ARM land, well it was much easier for a
board-file/driver writer to pass a function pointer then to create a
generic framework :-)

IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex cases
when passing just a name using platform data will not work. I would
second what Stephen said [1] and define a structure doing things in a
DT-like way.

Example;

[platform code]

static const struct phy_lookup my_phy_lookup[] = {

PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1, phy.2),
   
   The only problem here is that if *PLATFORM_DEVID_AUTO* is used while
   creating the device, the ids in the device name would change and
   PHY_LOOKUP wont be useful.
  
  I don't think this is a problem. All the existing lookup methods already 
  use ID to identify devices (see regulators, clkdev, PWMs, i2c, ...). You 
  can simply add a requirement that the ID must be assigned manually, 
  without using PLATFORM_DEVID_AUTO to use PHY lookup.
 
 And I'm saying that this idea, of using a specific name and id, is
 frought with fragility and will break in the future in various ways when
 devices get added to systems, making these strings constantly have to be
 kept up to date with different board configurations.
 
 People, NEVER, hardcode something like an id.  The fact that this
 happens today with the clock code, doesn't make it right, it makes the
 clock code wrong.  Others have already said that this is wrong there as
 well, as systems change and dynamic ids get used more and more.
 
 Let's not repeat the same mistakes of the past just because we refuse to
 learn from them...
 
 So again, the find a phy by a string functions should be removed, the
 device id should be automatically created by the phy core just to make
 things unique in sysfs, and no driver code should _ever_ be reliant on
 the number that is being created, and the pointer

[PATCH 04/35] spi: use dev_get_platdata()

2013-07-30 Thread Jingoo Han 
Use the wrapper function for retrieving the platform data instead of
accessing dev-platform_data directly.

Signed-off-by: Jingoo Han jg1@samsung.com
---
 drivers/spi/spi-altera.c|2 +-
 drivers/spi/spi-ath79.c |2 +-
 drivers/spi/spi-au1550.c|2 +-
 drivers/spi/spi-bcm63xx.c   |2 +-
 drivers/spi/spi-bfin-sport.c|2 +-
 drivers/spi/spi-bfin-v3.c   |2 +-
 drivers/spi/spi-bfin5xx.c   |2 +-
 drivers/spi/spi-coldfire-qspi.c |2 +-
 drivers/spi/spi-davinci.c   |4 ++--
 drivers/spi/spi-ep93xx.c|2 +-
 drivers/spi/spi-fsl-espi.c  |4 ++--
 drivers/spi/spi-fsl-lib.c   |2 +-
 drivers/spi/spi-fsl-spi.c   |   13 +++--
 drivers/spi/spi-gpio.c  |4 ++--
 drivers/spi/spi-mpc512x-psc.c   |2 +-
 drivers/spi/spi-mpc52xx-psc.c   |2 +-
 drivers/spi/spi-nuc900.c|2 +-
 drivers/spi/spi-oc-tiny.c   |2 +-
 drivers/spi/spi-omap-100k.c |2 +-
 drivers/spi/spi-omap2-mcspi.c   |2 +-
 drivers/spi/spi-pl022.c |3 ++-
 drivers/spi/spi-rspi.c  |2 +-
 drivers/spi/spi-s3c24xx.c   |2 +-
 drivers/spi/spi-s3c64xx.c   |4 ++--
 drivers/spi/spi-sh-msiof.c  |2 +-
 drivers/spi/spi-sh-sci.c|2 +-
 drivers/spi/spi-ti-ssp.c|2 +-
 drivers/spi/spi-tle62x0.c   |2 +-
 drivers/spi/spi-xilinx.c|2 +-
 29 files changed, 40 insertions(+), 38 deletions(-)

diff --git a/drivers/spi/spi-altera.c b/drivers/spi/spi-altera.c
index 81b9adb..e53caac 100644
--- a/drivers/spi/spi-altera.c
+++ b/drivers/spi/spi-altera.c
@@ -217,7 +217,7 @@ static irqreturn_t altera_spi_irq(int irq, void *dev)
 
 static int altera_spi_probe(struct platform_device *pdev)
 {
-   struct altera_spi_platform_data *platp = pdev-dev.platform_data;
+   struct altera_spi_platform_data *platp = dev_get_platdata(pdev-dev);
struct altera_spi *hw;
struct spi_master *master;
struct resource *res;
diff --git a/drivers/spi/spi-ath79.c b/drivers/spi/spi-ath79.c
index 0e06407..37bad95 100644
--- a/drivers/spi/spi-ath79.c
+++ b/drivers/spi/spi-ath79.c
@@ -221,7 +221,7 @@ static int ath79_spi_probe(struct platform_device *pdev)
sp = spi_master_get_devdata(master);
platform_set_drvdata(pdev, sp);
 
-   pdata = pdev-dev.platform_data;
+   pdata = dev_get_platdata(pdev-dev);
 
master-bits_per_word_mask = SPI_BPW_RANGE_MASK(1, 32);
master-setup = ath79_spi_setup;
diff --git a/drivers/spi/spi-au1550.c b/drivers/spi/spi-au1550.c
index e196555..1d00d9b3 100644
--- a/drivers/spi/spi-au1550.c
+++ b/drivers/spi/spi-au1550.c
@@ -776,7 +776,7 @@ static int au1550_spi_probe(struct platform_device *pdev)
hw = spi_master_get_devdata(master);
 
hw-master = spi_master_get(master);
-   hw-pdata = pdev-dev.platform_data;
+   hw-pdata = dev_get_platdata(pdev-dev);
hw-dev = pdev-dev;
 
if (hw-pdata == NULL) {
diff --git a/drivers/spi/spi-bcm63xx.c b/drivers/spi/spi-bcm63xx.c
index 4ac028d..b454f1b 100644
--- a/drivers/spi/spi-bcm63xx.c
+++ b/drivers/spi/spi-bcm63xx.c
@@ -335,7 +335,7 @@ static int bcm63xx_spi_probe(struct platform_device *pdev)
 {
struct resource *r;
struct device *dev = pdev-dev;
-   struct bcm63xx_spi_pdata *pdata = pdev-dev.platform_data;
+   struct bcm63xx_spi_pdata *pdata = dev_get_platdata(pdev-dev);
int irq;
struct spi_master *master;
struct clk *clk;
diff --git a/drivers/spi/spi-bfin-sport.c b/drivers/spi/spi-bfin-sport.c
index 07ec597..91921b5 100644
--- a/drivers/spi/spi-bfin-sport.c
+++ b/drivers/spi/spi-bfin-sport.c
@@ -756,7 +756,7 @@ static int bfin_sport_spi_probe(struct platform_device 
*pdev)
struct bfin_sport_spi_master_data *drv_data;
int status;
 
-   platform_info = dev-platform_data;
+   platform_info = dev_get_platdata(dev);
 
/* Allocate master with space for drv_data */
master = spi_alloc_master(dev, sizeof(*master) + 16);
diff --git a/drivers/spi/spi-bfin-v3.c b/drivers/spi/spi-bfin-v3.c
index 603d7e9..85fdc12 100644
--- a/drivers/spi/spi-bfin-v3.c
+++ b/drivers/spi/spi-bfin-v3.c
@@ -773,7 +773,7 @@ static irqreturn_t bfin_spi_rx_dma_isr(int irq, void 
*dev_id)
 static int bfin_spi_probe(struct platform_device *pdev)
 {
struct device *dev = pdev-dev;
-   struct bfin_spi3_master *info = dev-platform_data;
+   struct bfin_spi3_master *info = dev_get_platdata(dev);
struct spi_master *master;
struct bfin_spi_master *drv_data;
struct resource *mem, *res;
diff --git a/drivers/spi/spi-bfin5xx.c b/drivers/spi/spi-bfin5xx.c
index 59a7342..45bdf73 100644
--- a/drivers/spi/spi-bfin5xx.c
+++ b/drivers/spi/spi-bfin5xx.c
@@ -1271,7 +1271,7 @@ static int bfin_spi_probe(struct platform_device *pdev)
struct resource *res;
int status = 0;
 
-   platform_info = dev-platform_data;
+

Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy clock with pmu reg control

2013-07-30 Thread Rahul Sharma 
Thanks Seung-Woo,

On Tue, Jul 30, 2013 at 11:36 AM, Seung-Woo Kim sw0312@samsung.com wrote:
 Hi Rahul,

 On 2013년 07월 30일 12:42, Rahul Sharma wrote:


 On Tue, Jun 18, 2013 at 5:07 PM, Kishon Vijay Abraham I kis...@ti.com
 mailto:kis...@ti.com wrote:

 Hi,

 On Tuesday 18 June 2013 03:33 PM, Rahul Sharma wrote:
  Thanks all,
 
  On Fri, Jun 14, 2013 at 11:39 AM, 김승우 sw0312@samsung.com
 mailto:sw0312@samsung.com wrote:
  Hello Kishon,
 
  On 2013년 06월 13일 21:54, Kishon Vijay Abraham I wrote:
  Hi,
 
  On Thursday 13 June 2013 04:51 PM, Inki Dae wrote:
 
 
  -Original Message-
  From: Sylwester Nawrocki [mailto:s.nawro...@samsung.com
 mailto:s.nawro...@samsung.com]
  Sent: Thursday, June 13, 2013 5:56 PM
  To: Rahul Sharma
  Cc: Rahul Sharma; Inki Dae; linux-samsung-soc@vger.kernel.org
 mailto:linux-samsung-soc@vger.kernel.org;
  devicetree-
  disc...@lists.ozlabs.org mailto:disc...@lists.ozlabs.org;
 DRI mailing list; Kukjin Kim; Seung-Woo Kim;
  Sean Paul; sunil joshi; Kishon Vijay Abraham I; Stephen Warren;
  grant.lik...@linaro.org mailto:grant.lik...@linaro.org
  Subject: Re: [RFC 0/2] exynos5250/hdmi: replace dummy hdmiphy
 clock with
  pmu reg control
 
  Hi,
 
  On 06/13/2013 06:26 AM, Rahul Sharma wrote:
  Mr. Dae,
 
  Thanks for your valuable inputs.
 
  I posted it as RFC because, I also have received comments to
 register
  hdmiphy as a clock controller. As we always configure it for
 specific
  frequency, hdmi-phy looks similar to a PLL. But it really doesn't
  belong to that class. Secondly prior to exynos5420, it was a i2c
  device. I am not sure we can register a I2C device as a clock
  controller. I wanted to discuss and explore this option here.
 
  Have you considered using the generic PHY framework for those HDMI
  PHY devices [1] ? I guess we could add a dedicated group of
 ops for
  video PHYs, similarly as is is done with struct
 v4l2_subdev_ops. For
  configuring things like the carrier/pixel clock frequency or
 anything
  what's common across the video PHYs.
 
  Perhaps you could have a look and see if this framework would be
  useful for HDMI and possibly point out anything what might be
 missing ?
 
  I'm not sure it it really solves the issues specific to the Exynos
  HDMI but at least with a generic PHY driver the PHY module
 would be
  separate from the PHY controller, as often same HDMI DPHY can
 be used
  with various types of a HDMI controller. So this would allow
 to not
  duplicate the HDMI PHY drivers in the long-term perspective.
 
  Yeah, at least, it seems that we could use PHY module to
 control PMU
  register, HDMI_PHY_CONTROL. However, PHY module provides only
 init/on/off
  callbacks. As you may know, HDMIPHY needs i2c interfaces to control
  HDMIPHY
  clock. So with PHY module, HDMIPHY driver could enable PMU more
  generically,
  but also has to use existing i2c stuff to control HDMIPHY
 clock. I had a
  quick review to Generic PHY Framework[v6] but I didn't see that
 the PHY
  module could generically support more features such as i2c stuff.
 
  I don't think PHY framework needs to provide i2c interfaces to
 program
  certain configurations. Instead in one of the callbacks
 (init/on/off)
  PHY driver can program whatever it wants using any of the
 interfaces it
  needs. IMO PHY framework should work independent of the interfaces.
 
  In exnoys hdmi case, i2c interface is not the exact issue. In exynos
  hdmi, hdmiphy should send i2c configuration about video clock
  information as the video mode information including resolution,
 bit per
  pixel, refresh rate passed from drm subsystem. So init/on/off
 callbacks
  of phy framework are not enough for exynos hdmiphy and it should
 have a
  callback to set video mode.
 
  Do you have plan to add driver specific extend callback pointers
 to phy
  framework?
 
  Currently, hdmi directly calls phy operations, but Rahul's
 another patch
  set, mentioned by Inki, divides hdmi and hdmiphy and hdmi and
 hdmiphy is
  connected with exynos hdmi own sub driver callback operations.
 
  IMHO, if phy framework can support extend callback feature, then this
  own sub driver callbacks can be replaced with phy framework at
 long term
  view.
 
  Extended callbacks are always welcome. I can also use phy device
  private data to pass on private ops like get_pixelclk and
 set_pixelclk.

 I would recommend creating a wrapper to the existing PHY framework
 for HDMI PHY. That way, we can have other HDMI phys added
 easily. We need to figure

RE: RE: [PATCH v8 05/12] clk: exynos5250: add gate clock descriptions of System MMU

2013-07-30 Thread Cho KyongHo 
 -Original Message-
 From: Mike Turquette [mailto:mturque...@linaro.org]
 Sent: Tuesday, July 30, 2013 3:47 PM
 To: Cho KyongHo; 'Linux ARM Kernel'; 'Linux IOMMU'; 'Linux Kernel'; 'Linux 
 Samsung SOC'
 Cc: 'Kukjin Kim'; 'Hyunwoong Kim'; 'Prathyush'; 'Grant Grundler'; 'Joerg 
 Roedel'; 'Keyyoung Park';
 'Subash Patel'; 'Sachin Kamat'; 'Thomas Abraham'; 'Antonios Motakis'; 
 kvm...@lists.cs.columbia.edu;
 'Rahul Sharma'
 Subject: Re: RE: [PATCH v8 05/12] clk: exynos5250: add gate clock 
 descriptions of System MMU
 
 Quoting Cho KyongHo (2013-07-27 02:08:11)
   -Original Message-
   From: Mike Turquette [mailto:mturque...@linaro.org]
   Sent: Saturday, July 27, 2013 5:01 AM
  
   Quoting Cho KyongHo (2013-07-26 04:27:54)
This adds gate clocks of all System MMUs and their master IPs
that are not apeared in clk-exynos5250.c
   
Signed-off-by: Cho KyongHo pullip@samsung.com
  
   Change looks good to me. Are you OK if I take it into the clk tree or do
   you want to keep this series together?
 
  I would like you to pick this to your tree and let me know which branch
  contains this patch.
  Then I will remove this from my patch series.
 
 camif_top corresponds to 345 in your patch, but this conflicts the g2d
 clock introduced in patch clk: exynos5250: Add G2D gate clock in the
 clk tree. I've pushed out the latest clk-next branch with this change:
 
 git://git.linaro.org/people/mturquette/linux.git clk-next
 
 Can you rebase your change on top of this and resolve the clock id
 mapping?
 
Oh,
I will rebase this patch on your git in the next patch version.

Thank you.

 Thanks,
 Mike
 
 
  Thank you,
  Cho KyongHo.
  
   Regards,
   Mike
  
---
 .../devicetree/bindings/clock/exynos5250-clock.txt |   28 +-
 drivers/clk/samsung/clk-exynos5250.c   |   57 
---
 2 files changed, 75 insertions(+), 10 deletions(-)
   
diff --git 
a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 781a627..df49694 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -154,7 +154,33 @@ clock which they consume.
   dsim0341
   dp   342
   mixer343
-  hdmi 345
+  hdmi 344
+  camif_top345
+  smmu_fimc_lite0  346
+  smmu_fimc_lite1  347
+  smmu_fimc_lite2  348
+  smmu_tv  349
+  smmu_fimd1   350
+  smmu_2d  351
+  fimc_isp 352
+  fimc_drc 353
+  fimc_fd  354
+  fimc_scc 355
+  fimc_scp 356
+  fimc_mcuctl  357
+  fimc_odc 358
+  fimc_dis 359
+  fimc_3dnr360
+  smmu_fimc_isp361
+  smmu_fimc_drc362
+  smmu_fimc_fd 363
+  smmu_fimc_scc364
+  smmu_fimc_scp365
+  smmu_fimc_mcuctl 366
+  smmu_fimc_odc367
+  smmu_fimc_dis0   368
+  smmu_fimc_dis1   369
+  smmu_fimc_3dnr   370
   
 Example 1: An example of a clock controller node is listed below.
   
diff --git a/drivers/clk/samsung/clk-exynos5250.c 
b/drivers/clk/samsung/clk-exynos5250.c
index 22d7699..e242bde 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -53,12 +53,15 @@
 #define DIV_PERIC3 0x10564
 #define DIV_PERIC4 0x10568
 #define DIV_PERIC5 0x1056c
+#define GATE_IP_ISP0   0x0C800
+#define GATE_IP_ISP1   0x0C800
 #define GATE_IP_GSCL   0x10920
 #define GATE_IP_MFC0x1092c
 #define GATE_IP_GEN0x10934
 #define GATE_IP_FSYS   0x10944
 #define GATE_IP_PERIC  0x10950
 #define GATE_IP_PERIS  0x10960
+#define GATE_IP_ACP0x18800
 #define SRC_CDREX  0x20200
 #define PLL_DIV2_SEL   0x20a24
 #define GATE_IP_DISP1  0x10928
@@ -100,6 +103,14 @@ enum exynos5250_clks {
tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, 
hdmi_cec, mct,
wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi,
   
+   camif_top, smmu_fimc_lite0, smmu_fimc_lite1, smmu_fimc_lite2,
+   smmu_tv, smmu_fimd1, smmu_2d,
+   fimc_isp, fimc_drc, fimc_fd, fimc_scc, fimc_scp, fimc_mcuctl, 
fimc_odc,
+   fimc_dis, fimc_3dnr,
+   smmu_fimc_isp, smmu_fimc_drc, smmu_fimc_fd, smmu_fimc_scc,
+   smmu_fimc_scp, smmu_fimc_mcuctl, smmu_fimc_odc, smmu_fimc_dis0,
+   smmu_fimc_dis1, smmu_fimc_3dnr,
+

[PATCH v2 0/7] Add DT nodes for FIMD and DP controller for Exynos5420 SoC

2013-07-30 Thread Vikas Sajjan 
This patchset adds DT nodes for FIMD and DP controller for Exynos5420
based SMDK.

It moves all common properties of FIMD and DP controller DT node specific to
Exynos5 Socs like 5250 and 5420 to exynos5.dtsi file.

It also adds required PM domain DT nodes for exynos5420.

Is rebased on branch kgene's for-next
https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/log/?h=for-next

The DP PHY DT Node is based on Jingoo Han's inflight patchset at
http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/66435

changes since v1:
- Addressed comments given by Tomasz Figa tomasz.f...@gmail.com
and Ajay kumar ajayn...@gmail.com

Vikas Sajjan (6):
  ARM: dts: Move display-timimg information inside FIMD DT node for
exynos5250
  ARM: dts: Update FIMD DT node for Exynos5 SoCs
  ARM: dts: Add FIMD DT node to exynos5420 DTS files
  ARM: dts: Update DP controller DT Node for Exynos5 based SoCs
  ARM: dts: Add DP controller DT node to exynos5420 SoC
  ARM: dts: Add pin state information for DP HPD support to Exynos5420

Yadwinder Singh Brar (1):
  ARM: dts: Add basic PM domains for EXYNOS5420

 arch/arm/boot/dts/exynos5.dtsi|   21 +++
 arch/arm/boot/dts/exynos5250-arndale.dts  |4 ++-
 arch/arm/boot/dts/exynos5250-smdk5250.dts |   32 +
 arch/arm/boot/dts/exynos5250.dtsi |   28 ++-
 arch/arm/boot/dts/exynos5420-pinctrl.dtsi |7 
 arch/arm/boot/dts/exynos5420-smdk5420.dts |   31 
 arch/arm/boot/dts/exynos5420.dtsi |   55 +
 7 files changed, 145 insertions(+), 33 deletions(-)

-- 
1.7.9.5

--
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/7] ARM: dts: Move display-timimg information inside FIMD DT node for exynos5250

2013-07-30 Thread Vikas Sajjan 
As the display-timing information is parsed by FIMD driver, it makes
sense to move the display-timimg DT node inside FIMD DT node for exynos5250

Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
 arch/arm/boot/dts/exynos5250-smdk5250.dts |   29 -
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 49f18c2..d176dbb 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -262,19 +262,22 @@
pinctrl-0 = dp_hpd;
};
 
-   display-timings {
-   native-mode = timing0;
-   timing0: timing@0 {
-   /* 1280x800 */
-   clock-frequency = 5;
-   hactive = 1280;
-   vactive = 800;
-   hfront-porch = 4;
-   hback-porch = 4;
-   hsync-len = 4;
-   vback-porch = 4;
-   vfront-porch = 4;
-   vsync-len = 4;
+   fimd@1440 {
+   status = okay;
+   display-timings {
+   native-mode = timing0;
+   timing0: timing@0 {
+   /* 1280x800 */
+   clock-frequency = 5;
+   hactive = 1280;
+   vactive = 800;
+   hfront-porch = 4;
+   hback-porch = 4;
+   hsync-len = 4;
+   vback-porch = 4;
+   vfront-porch = 4;
+   vsync-len = 4;
+   };
};
};
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/7] ARM: dts: Add basic PM domains for EXYNOS5420

2013-07-30 Thread Vikas Sajjan 
From: Yadwinder Singh Brar yadi.b...@samsung.com

Add DT nodes for gsc, isp, mfc, disp, mau, g2d and msc PM domains.

Signed-off-by: Yadwinder Singh Brar yadi.b...@samsung.com
---
 arch/arm/boot/dts/exynos5420.dtsi |   35 +++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 8c54c4b..884d8f4 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -90,6 +90,41 @@
};
};
 
+   gsc_pd: power-domain@10044000 {
+   compatible = samsung,exynos4210-pd;
+   reg = 0x10044000 0x20;
+   };
+
+   isp_pd: power-domain@10044020 {
+   compatible = samsung,exynos4210-pd;
+   reg = 0x10044020 0x20;
+   };
+
+   mfc_pd: power-domain@10044060 {
+   compatible = samsung,exynos4210-pd;
+   reg = 0x10044060 0x20;
+   };
+
+   disp_pd: power-domain@100440C0 {
+   compatible = samsung,exynos4210-pd;
+   reg = 0x100440C0 0x20;
+   };
+
+   mau_pd: power-domain@100440E0 {
+   compatible = samsung,exynos4210-pd;
+   reg = 0x100440E0 0x20;
+   };
+
+   g2d_pd: power-domain@10044100 {
+   compatible = samsung,exynos4210-pd;
+   reg = 0x10044100 0x20;
+   };
+
+   msc_pd: power-domain@10044120 {
+   compatible = samsung,exynos4210-pd;
+   reg = 0x10044120 0x20;
+   };
+
pinctrl_0: pinctrl@1340 {
compatible = samsung,exynos5420-pinctrl;
reg = 0x1340 0x1000;
-- 
1.7.9.5

--
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 2/7] ARM: dts: Update FIMD DT node for Exynos5 SoCs

2013-07-30 Thread Vikas Sajjan 
Moves the properties of FIMD DT node which are common across Exynos5 based
SoCs like Exynos5250 and Exxynos5420 to exynos5.dtsi

Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
 arch/arm/boot/dts/exynos5.dtsi   |   10 ++
 arch/arm/boot/dts/exynos5250-arndale.dts |1 +
 arch/arm/boot/dts/exynos5250.dtsi|7 +--
 3 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index f65e124..d464b6c 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -108,4 +108,14 @@
interrupts = 0 42 0;
status = disabled;
};
+
+   fimd@1440 {
+   compatible = samsung,exynos5250-fimd;
+   interrupt-parent = combiner;
+   reg = 0x1440 0x4;
+   interrupt-names = fifo, vsync, lcd_sys;
+   interrupts = 18 4, 18 5, 18 6;
+   status = disabled;
+   };
+
 };
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index 96d528d..76825ef 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -519,6 +519,7 @@
};
 
fimd: fimd@1440 {
+   status = okay;
display-timings {
native-mode = timing0;
timing0: timing@0 {
diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index ef57277..238bdb2 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -630,12 +630,7 @@
};
};
 
-   fimd {
-   compatible = samsung,exynos5250-fimd;
-   interrupt-parent = combiner;
-   reg = 0x1440 0x4;
-   interrupt-names = fifo, vsync, lcd_sys;
-   interrupts = 18 4, 18 5, 18 6;
+   fimd@1440 {
clocks = clock 133, clock 339;
clock-names = sclk_fimd, fimd;
};
-- 
1.7.9.5

--
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 6/7] ARM: dts: Add DP controller DT node to exynos5420 SoC

2013-07-30 Thread Vikas Sajjan 
Adds DP controller DT node to exynos5420 SoC

Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
 arch/arm/boot/dts/exynos5420-smdk5420.dts |   10 ++
 arch/arm/boot/dts/exynos5420.dtsi |   13 +
 2 files changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 0c0249c..80aa3d4 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -31,6 +31,16 @@
};
};
 
+   dp-controller@145b {
+   samsung,color-space = 0;
+   samsung,dynamic-range = 0;
+   samsung,ycbcr-coeff = 0;
+   samsung,color-depth = 1;
+   samsung,link-rate = 0x0a;
+   samsung,lane-count = 4;
+   status = okay;
+   };
+
fimd@1440 {
status = okay;
display-timings {
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 2f98c89..8255db2 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -181,6 +181,19 @@
clock-names = uart, clk_uart_baud0;
};
 
+   dp_phy: video-phy@10040728 {
+   compatible = samsung,exynos5250-dp-video-phy;
+   reg = 0x10040728 4;
+   #phy-cells = 0;
+   };
+
+   dp-controller@145b {
+   clocks = clock 412;
+   clock-names = dp;
+   phys = dp_phy;
+   phy-names = dp;
+   };
+
fimd@1440 {
samsung,power-domain = disp_pd;
clocks = clock 147, clock 421;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 5/7] ARM: dts: Update DP controller DT Node for Exynos5 based SoCs

2013-07-30 Thread Vikas Sajjan 
Moves the properties of DP controller to exynos5.dtsi which are common
across exynos5 SoCs like Exynos5250 and Exynos5420.

The PHY DP Node is based on Jingoo Han's jg1@samsung.com patch at
https://patchwork.linuxtv.org/patch/19189/

Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
 arch/arm/boot/dts/exynos5.dtsi|   11 +++
 arch/arm/boot/dts/exynos5250-arndale.dts  |3 ++-
 arch/arm/boot/dts/exynos5250-smdk5250.dts |3 ++-
 arch/arm/boot/dts/exynos5250.dtsi |   21 +
 4 files changed, 24 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
index d464b6c..213a2d8 100644
--- a/arch/arm/boot/dts/exynos5.dtsi
+++ b/arch/arm/boot/dts/exynos5.dtsi
@@ -118,4 +118,15 @@
status = disabled;
};
 
+   dp-controller@145b {
+   compatible = samsung,exynos5-dp;
+   reg = 0x145b 0x1000;
+   interrupts = 10 3;
+   interrupt-parent = combiner;
+   #address-cells = 1;
+   #size-cells = 0;
+   status = disabled;
+   };
+
+
 };
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index 76825ef..ce74400 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -509,13 +509,14 @@
};
};
 
-   dp-controller {
+   dp-controller@145b {
samsung,color-space = 0;
samsung,dynamic-range = 0;
samsung,ycbcr-coeff = 0;
samsung,color-depth = 1;
samsung,link-rate = 0x0a;
samsung,lane-count = 4;
+   status = okay;
};
 
fimd: fimd@1440 {
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index d176dbb..f9ab99c 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -250,7 +250,7 @@
samsung,vbus-gpio = gpx2 6 0;
};
 
-   dp-controller {
+   dp-controller@145b {
samsung,color-space = 0;
samsung,dynamic-range = 0;
samsung,ycbcr-coeff = 0;
@@ -260,6 +260,7 @@
 
pinctrl-names = default;
pinctrl-0 = dp_hpd;
+   status = okay;
};
 
fimd@1440 {
diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 238bdb2..1c017dc 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -614,20 +614,17 @@
interrupts = 0 94 0;
};
 
-   dp-controller {
-   compatible = samsung,exynos5-dp;
-   reg = 0x145b 0x1000;
-   interrupts = 10 3;
-   interrupt-parent = combiner;
+   dp_phy: video-phy@10040720 {
+   compatible = samsung,exynos5250-dp-video-phy;
+   reg = 0x10040720 4;
+   #phy-cells = 0;
+   };
+
+   dp-controller@145b {
clocks = clock 342;
clock-names = dp;
-   #address-cells = 1;
-   #size-cells = 0;
-
-   dptx-phy {
-   reg = 0x10040720;
-   samsung,enable-mask = 1;
-   };
+   phys = dp_phy;
+   phy-names = dp;
};
 
fimd@1440 {
-- 
1.7.9.5

--
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 4/7] ARM: dts: Add FIMD DT node to exynos5420 DTS files

2013-07-30 Thread Vikas Sajjan 
Adds FIMD DT node to exynos5420 based SMDK. Also adds display-timimg
information node.

Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
 arch/arm/boot/dts/exynos5420-smdk5420.dts |   19 +++
 arch/arm/boot/dts/exynos5420.dtsi |7 +++
 2 files changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 08607df..0c0249c 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -30,4 +30,23 @@
clock-frequency = 2400;
};
};
+
+   fimd@1440 {
+   status = okay;
+   display-timings {
+   native-mode = timing0;
+   timing0: timing@0 {
+   clock-frequency = 5;
+   hactive = 2560;
+   vactive = 1600;
+   hfront-porch = 48;
+   hback-porch = 80;
+   hsync-len = 32;
+   vback-porch = 16;
+   vfront-porch = 8;
+   vsync-len = 6;
+   };
+   };
+   };
+
 };
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 884d8f4..2f98c89 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -180,4 +180,11 @@
clocks = clock 260, clock 131;
clock-names = uart, clk_uart_baud0;
};
+
+   fimd@1440 {
+   samsung,power-domain = disp_pd;
+   clocks = clock 147, clock 421;
+   clock-names = sclk_fimd, fimd;
+   };
+
 };
-- 
1.7.9.5

--
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 7/7] ARM: dts: Add pin state information for DP HPD support to Exynos5420

2013-07-30 Thread Vikas Sajjan 
Add pin state information for DP HPD support that requires pin configuration
support using pinctrl interface.

Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
 arch/arm/boot/dts/exynos5420-pinctrl.dtsi |7 +++
 arch/arm/boot/dts/exynos5420-smdk5420.dts |2 ++
 2 files changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi 
b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
index 5848c42..e695aba 100644
--- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
@@ -59,6 +59,13 @@
interrupt-controller;
#interrupt-cells = 2;
};
+
+   dp_hpd: dp_hpd {
+   samsung,pins = gpx0-7;
+   samsung,pin-function = 3;
+   samsung,pin-pud = 0;
+   samaung,pin-drv = 0;
+   };
};
 
pinctrl@1341 {
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index 80aa3d4..123e523 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -32,6 +32,8 @@
};
 
dp-controller@145b {
+   pinctrl-names = default;
+   pinctrl-0 = dp_hpd;
samsung,color-space = 0;
samsung,dynamic-range = 0;
samsung,ycbcr-coeff = 0;
-- 
1.7.9.5

--
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 v7 00/11] Add generic set_rate clk_ops for PLL35xx and PLL36xx for samsung SoCs

2013-07-30 Thread Vikas Sajjan 
Hi Mike,

On Tue, Jul 23, 2013 at 6:56 AM, Mike Turquette mturque...@linaro.org wrote:
 Quoting Vikas Sajjan (2013-07-21 23:15:27)
 Hi Kukjin / Mike,

 Can you apply this series

 Let me apply this to see if the dependencies are taken care of now. If
 so I'll just take it through the clk tree.


Any updates on this series.
I could NOT see them at
http://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=shortlog;h=refs/heads/clk-next


 Regards,
 Mike


 On Tue, Jul 16, 2013 at 7:10 PM, Yadwinder Singh Brar
 yadi.bra...@gmail.com wrote:
  Hi Kukjin / Mike,
 
  On Tue, Jun 25, 2013 at 7:40 AM, Kukjin Kim kgene@samsung.com wrote:
  Mike Turquette wrote:
 
  Quoting Kukjin Kim (2013-06-24 08:02:39)
   On 06/22/13 01:31, Mike Turquette wrote:
   
Acked-by: Mike Turquettemturque...@linaro.org
   
Or I can take this through the clk tree. Either way is fine.
   
   Mike, please go ahead taking this series into the clk tree for 3.11.
 
  Actually it might be better for you to take it. Patch #5 relies on
  drivers/clk/samsung/clk-exynos5420.c which only exists in the samsung
  tree.  It was introduced by commit 1609027f, clk: exynos5420: register
  clocks using common clock framework.
 
  Yes, you're right. It depends on soc-exynos5420 stuff in samsung tree.
 
  And these patches need to be applied with some fuzz to the clk tree due
  to other changes which are not in my tree and only present in yours.
 
  The best two options are either for you to take this series or it can be
  rebased on top of clk-next, after which I'll apply it.
 
  Let me try to send this series via samsung tree for v3.11 but I'm not 
  sure because it's a little bit late for arm-soc tree.
 
  Thanks for your ack, just note I will send to arm-soc tonight in my time.
 
 
  Can we get this series merge now in any of trees.
  Please let me if its required to rebase it.
 
  Regards,
  Yadwinder
--
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 v4 1/6] clk/exynos5250: Fix HDMI clock number in documentation

2013-07-30 Thread Mike Turquette 
Quoting Rahul Sharma (2013-07-24 22:07:32)
 From: Arun Kumar K arun...@samsung.com
 
 This patch corrects the HDMI clock number given wrongly
 in the documentation.
 
 Signed-off-by: Arun Kumar K arun...@samsung.com
 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com

You can drop this patch as it is fixed in the clk-next branch already by
commit of/documentation: Fix a typo in exynos5250-clock.txt, 07c2ae9c.

Regards,
Mike

 ---
  Documentation/devicetree/bindings/clock/exynos5250-clock.txt |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt 
 b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
 index 781a627..1a05761 100644
 --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
 +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
 @@ -154,7 +154,7 @@ clock which they consume.
dsim0341
dp   342
mixer343
 -  hdmi 345
 +  hdmi 344
  
  Example 1: An example of a clock controller node is listed below.
  
 -- 
 1.7.10.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

Re: [PATCH v4 0/6] clk/exynos5250: add clocks for hdmi subsystem

2013-07-30 Thread Mike Turquette 
Quoting Rahul Sharma (2013-07-24 22:07:31)
 Add clock changes for hdmi subsystem for exynos5250 SoC. These
 include addition of new clocks like mout_hdmi and smmu_tv, associating
 ID to clk_hdmiphy and some essential corrections.
 
 This set is based on kukjin's for-next branch at
 http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git.

I've taken patches 2-4 into the clk-next branch. Patch #1 can be
dropped.

Patches 5  6 need to be rebased onto clk-next as the g2d clock has
reserved mapping 345.  Also I've cc'd Cho KyongHo who is rebasing his
system mmu clock patch[1] onto clk-next. Can the two of your coordinate
your changes to avoid mapping conflicts in the binding? Perhaps Rahul
can carry Cho's patch in his next version when he rebases patches 5  6.

Thanks,
Mike

[1] https://lkml.org/lkml/2013/7/30/51

 
 V4:
 1) Added Arun's patch hdmi clock number correction in this series.
 2) Corrected clock number for smmu_mixer
 
 V3:
 1) Rebase to kgene for-next based on 3.11-rc1.
 2) Added Tushar's patch in the series.
 
 V2:
 1) Dropped clk/exynos5250: Fix HDMI clock number in documentation as
 it already get merged.
 
 Arun Kumar K (1):
   clk/exynos5250: Fix HDMI clock number in documentation
 
 Rahul Sharma (4):
   clk/exynos5250: add mout_hdmi mux clock for hdmi
   clk/exynos5250: add sclk_hdmiphy in the list of special clocks
   clk/exynos5250: add clock for mixer sysmmu
   clk/exynos5250: change parent to aclk200_disp1 for hdmi subsystem
 
 Tushar Behera (1):
   Documentation: exynos5250-clock: Add div_i2s1 and div_i2s2
 
  .../devicetree/bindings/clock/exynos5250-clock.txt |   14 +-
  drivers/clk/samsung/clk-exynos5250.c   |   20 
 ++--
  2 files changed, 27 insertions(+), 7 deletions(-)
 
 -- 
 1.7.10.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

Re: [PATCH 1/3] clk: exynos5250: Add G2D gate clock

2013-07-30 Thread Sachin Kamat 
On 31 July 2013 09:12, Mike Turquette mturque...@linaro.org wrote:
 Quoting Sachin Kamat (2013-07-29 23:55:33)
 On 30 July 2013 12:18, Mike Turquette mturque...@linaro.org wrote:
  Quoting Sachin Kamat (2013-07-27 06:29:56)
  On 27 July 2013 01:48, Mike Turquette mturque...@linaro.org wrote:
   Quoting Sachin Kamat (2013-07-05 01:42:27)
   Adds gate clock for G2D IP for Exynos5250 SoC.
  
   Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
   Cc: Mike Turquette mturque...@linaro.org
  
   I've taken patch #1 into clk-next.
 
  Thanks Mike.
 
  
   ---
   This patch depends on the following patch:
   http://thread.gmane.org/gmane.linux.kernel.samsung-soc/20581
  
   I think I've gotten all three series you sent out, can you confirm?
 
  I haven't seen any update in your tree [1] since quite some time. The
  last commit I see in clk-next branch is 45e3ec3784 (clk: tegra: fix
  ifdef for tegra_periph_reset_assert inline). I hope I am looking at
  the right tree?
 
  You are, but I had not pushed to it since the merge window closed. It is
  now updated.
 

 Thanks Mike. I confirm that all the three patch series that you
 mentioned are applied in your tree.
 Please check the below one too.

 http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg20598.html

 Ok, I picked that one up too.

Thanks Mike.

-- 
With warm regards,
Sachin
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RE: [PATCH Resend 1/1] clk: exynos4: Add clock entries for TMU

2013-07-30 Thread Mike Turquette 
Quoting Kukjin Kim (2013-07-24 05:05:46)
 Sachin Kamat wrote:
  
  Added clock entries for thermal management unit (TMU) for
  Exynos4 SoCs.
  
  Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 
 Acked-by: Kukjin Kim kgene@samsung.com
 
 Mike, I remember you're ok this for v3.12 so if you do not apply this in
 clk-next yet, please go ahead :)

You remember correctly. I've pulled this into clk-next.

Regards,
Mike

 
 Thanks,
 Kukjin
 
  ---
  Resending this (after rebasing) based on the below discussion:
  http://comments.gmane.org/gmane.linux.kernel.samsung-soc/19933
  
  Previous version:
  http://comments.gmane.org/gmane.linux.kernel.samsung-soc/18081
  ---
   .../devicetree/bindings/clock/exynos4-clock.txt|1 +
   drivers/clk/samsung/clk-exynos4.c  |4 +++-
   2 files changed, 4 insertions(+), 1 deletion(-)
  
  diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt
  b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
  index 14d5c2a..c6bf8a6 100644
  --- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt
  +++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
  @@ -236,6 +236,7 @@ Exynos4 SoC and this is specified where applicable.
 spi0_isp_sclk   380 Exynos4x12
 spi1_isp_sclk   381 Exynos4x12
 uart_isp_sclk   382 Exynos4x12
  +  tmu_apbif   383
  
[Mux Clocks]
  
  diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-
  exynos4.c
  index 75635eb..cee297d 100644
  --- a/drivers/clk/samsung/clk-exynos4.c
  +++ b/drivers/clk/samsung/clk-exynos4.c
  @@ -169,7 +169,7 @@ enum exynos4_clks {
gicisp, smmu_isp, smmu_drc, smmu_fd, smmu_lite0, smmu_lite1,
  mcuctl_isp,
mpwm_isp, i2c0_isp, i2c1_isp, mtcadc_isp, pwm_isp, wdt_isp,
  uart_isp,
asyncaxim, smmu_ispcx, spi0_isp, spi1_isp, pwm_isp_sclk,
  spi0_isp_sclk,
  - spi1_isp_sclk, uart_isp_sclk,
  + spi1_isp_sclk, uart_isp_sclk, tmu_apbif,
  
/* mux clocks */
mout_fimc0 = 384, mout_fimc1, mout_fimc2, mout_fimc3, mout_cam0,
  @@ -814,6 +814,7 @@ static struct samsung_gate_clock
 exynos4210_gate_clks[]
  __initdata = {
GATE_A(keyif, keyif, aclk100, E4210_GATE_IP_PERIR, 16, 0, 0,
  keypad),
GATE_DA(sclk_fimd1, exynos4-fb.1, sclk_fimd1, div_fimd1,
E4210_SRC_MASK_LCD1, 0, CLK_SET_RATE_PARENT, 0,
  sclk_fimd),
  + GATE(tmu_apbif, tmu_apbif, aclk100, E4210_GATE_IP_PERIR, 17, 0,
  0),
   };
  
   /* list of gate clocks supported in exynos4x12 soc */
  @@ -915,6 +916,7 @@ static struct samsung_gate_clock
 exynos4x12_gate_clks[]
  __initdata = {
GATE(spi1_isp, spi1_isp, aclk200, E4X12_GATE_ISP1, 13,
CLK_IGNORE_UNUSED, 0),
GATE(g2d, g2d, aclk200, GATE_IP_DMC, 23, 0, 0),
  + GATE(tmu_apbif, tmu_apbif, aclk100, E4X12_GATE_IP_PERIR, 17, 0,
  0),
   };
  
   /*
  --
  1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 Resend 2/3] of/documentation: Update G2D documentation

2013-07-30 Thread Mike Turquette 
Quoting Sachin Kamat (2013-07-08 23:29:15)
 Exynos5250 G2D IP requires only the gate clock. Update the
 binding documentation accordingly.
 
 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 Cc: Inki Dae inki@samsung.com

Taken into clk-next.

Thanks,
Mike

 ---
 Updated the description of clock-names as suggested by Tomasz Figa.
 ---
  .../devicetree/bindings/gpu/samsung-g2d.txt|7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt 
 b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
 index 3f454ff..c4f358d 100644
 --- a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
 +++ b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
 @@ -11,8 +11,11 @@ Required properties:
  
- interrupts : G2D interrupt number to the CPU.
- clocks : from common clock binding: handle to G2D clocks.
 -  - clock-names : from common clock binding: must contain sclk_fimg2d and
 - fimg2d, corresponding to entries in the clocks property.
 +  - clock-names : names of clocks listed in clocks property, in the same
 + order, depending on SoC type:
 + - for S5PV210 and Exynos4 based SoCs: fimg2d and
 +   sclk_fimg2d
 + - for Exynos5250 SoC: fimg2d.
  
  Example:
 g2d@1280 {
 -- 
 1.7.9.5
--
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 v4 0/6] clk/exynos5250: add clocks for hdmi subsystem

2013-07-30 Thread Rahul Sharma 
On Wed, Jul 31, 2013 at 2:38 AM, Mike Turquette mturque...@linaro.org wrote:
 Quoting Rahul Sharma (2013-07-24 22:07:31)
 Add clock changes for hdmi subsystem for exynos5250 SoC. These
 include addition of new clocks like mout_hdmi and smmu_tv, associating
 ID to clk_hdmiphy and some essential corrections.

 This set is based on kukjin's for-next branch at
 http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git.

 I've taken patches 2-4 into the clk-next branch. Patch #1 can be
 dropped.

 Patches 5  6 need to be rebased onto clk-next as the g2d clock has
 reserved mapping 345.  Also I've cc'd Cho KyongHo who is rebasing his
 system mmu clock patch[1] onto clk-next. Can the two of your coordinate
 your changes to avoid mapping conflicts in the binding? Perhaps Rahul
 can carry Cho's patch in his next version when he rebases patches 5  6.

 Thanks,
 Mike


Thanks Mike,

I will rebase and post 5, 6 on top of Cho's patches (based on  clk-next) .

regards,
Rahul Sharma.

 [1] https://lkml.org/lkml/2013/7/30/51


 V4:
 1) Added Arun's patch hdmi clock number correction in this series.
 2) Corrected clock number for smmu_mixer

 V3:
 1) Rebase to kgene for-next based on 3.11-rc1.
 2) Added Tushar's patch in the series.

 V2:
 1) Dropped clk/exynos5250: Fix HDMI clock number in documentation as
 it already get merged.

 Arun Kumar K (1):
   clk/exynos5250: Fix HDMI clock number in documentation

 Rahul Sharma (4):
   clk/exynos5250: add mout_hdmi mux clock for hdmi
   clk/exynos5250: add sclk_hdmiphy in the list of special clocks
   clk/exynos5250: add clock for mixer sysmmu
   clk/exynos5250: change parent to aclk200_disp1 for hdmi subsystem

 Tushar Behera (1):
   Documentation: exynos5250-clock: Add div_i2s1 and div_i2s2

  .../devicetree/bindings/clock/exynos5250-clock.txt |   14 +-
  drivers/clk/samsung/clk-exynos5250.c   |   20 
 ++--
  2 files changed, 27 insertions(+), 7 deletions(-)

 --
 1.7.10.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

RE: [PATCH] ARM: SAMSUNG: fix to support for missing cpu specific map_io

2013-07-30 Thread Kukjin Kim 
Sachin Kamat wrote:
 
 On 30 July 2013 09:57, Kukjin Kim kgene@samsung.com wrote:
 
  Since commit 7ed76e08 (ARM: EXYNOS: Fix low level debug support)
  map_io() is not needed for exynos5440 so need to fix to lookup
  cpu which using map_io(). Without this, kernel boot log complains
  'CPU EXYNOS5440 support not enabled' on exynos5440 and panic().
 
  Signed-off-by: Kukjin Kim kgene@samsung.com
  ---
   arch/arm/plat-samsung/init.c |5 +++--
   1 file changed, 3 insertions(+), 2 deletions(-)
 
  diff --git a/arch/arm/plat-samsung/init.c b/arch/arm/plat-samsung/init.c
  index 3e5c461..50a3ea0 100644
  --- a/arch/arm/plat-samsung/init.c
  +++ b/arch/arm/plat-samsung/init.c
  @@ -55,12 +55,13 @@ void __init s3c_init_cpu(unsigned long idcode,
 
  printk(CPU %s (id 0x%08lx)\n, cpu-name, idcode);
 
  -   if (cpu-map_io == NULL || cpu-init == NULL) {
  +   if (cpu-init == NULL) {
  printk(KERN_ERR CPU %s support not enabled\n,
cpu-name);
  panic(Unsupported Samsung CPU);
 
 While at it you could probably remove the printk and have that message
 printed by panic instead?
 
If required, it should be handled separately, and it is not critical.

- Kukjin

--
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 01/15] drivers: phy: add generic PHY framework

2013-07-30 Thread Kishon Vijay Abraham I 
Hi,

On Tuesday 30 July 2013 12:41 PM, Felipe Balbi wrote:
 On Sun, Jul 21, 2013 at 08:46:53AM -0700, Greg KH wrote:
 On Sun, Jul 21, 2013 at 01:12:07PM +0200, Tomasz Figa wrote:
 On Sunday 21 of July 2013 16:37:33 Kishon Vijay Abraham I wrote:
 Hi,

 On Sunday 21 July 2013 04:01 PM, Tomasz Figa wrote:
 Hi,

 On Saturday 20 of July 2013 19:59:10 Greg KH wrote:
 On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
 On Sat, 20 Jul 2013, Greg KH wrote:
 That should be passed using platform data.

 Ick, don't pass strings around, pass pointers.  If you have
 platform
 data you can get to, then put the pointer there, don't use a
 name.

 I don't think I understood you here :-s We wont have phy pointer
 when we create the device for the controller no?(it'll be done in
 board file). Probably I'm missing something.

 Why will you not have that pointer?  You can't rely on the name
 as
 the device id will not match up, so you should be able to rely on
 the pointer being in the structure that the board sets up, right?

 Don't use names, especially as ids can, and will, change, that is
 going
 to cause big problems.  Use pointers, this is C, we are supposed to
 be
 doing that :)

 Kishon, I think what Greg means is this:  The name you are using
 must
 be stored somewhere in a data structure constructed by the board
 file,
 right?  Or at least, associated with some data structure somehow.
 Otherwise the platform code wouldn't know which PHY hardware
 corresponded to a particular name.

 Greg's suggestion is that you store the address of that data
 structure
 in the platform data instead of storing the name string.  Have the
 consumer pass the data structure's address when it calls phy_create,
 instead of passing the name.  Then you don't have to worry about two
 PHYs accidentally ending up with the same name or any other similar
 problems.

 Close, but the issue is that whatever returns from phy_create()
 should
 then be used, no need to call any find functions, as you can just
 use
 the pointer that phy_create() returns.  Much like all other class api
 functions in the kernel work.

 I think there is a confusion here about who registers the PHYs.

 All platform code does is registering a platform/i2c/whatever device,
 which causes a driver (located in drivers/phy/) to be instantiated.
 Such drivers call phy_create(), usually in their probe() callbacks,
 so platform_code has no way (and should have no way, for the sake of
 layering) to get what phy_create() returns.

 Why not put pointers in the platform data structure that can hold these
 pointers?  I thought that is why we created those structures in the
 first place.  If not, what are they there for?
 
 heh, IMO we shouldn't pass pointers of any kind through platform_data,
 we want to pass data :-)
 
 Allowing to pass pointers through that, is one of the reasons which got
 us in such a big mess in ARM land, well it was much easier for a
 board-file/driver writer to pass a function pointer then to create a
 generic framework :-)
 
 IMHO we need a lookup method for PHYs, just like for clocks,
 regulators, PWMs or even i2c busses because there are complex cases
 when passing just a name using platform data will not work. I would
 second what Stephen said [1] and define a structure doing things in a
 DT-like way.

 Example;

 [platform code]

 static const struct phy_lookup my_phy_lookup[] = {

   PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1, phy.2),

 The only problem here is that if *PLATFORM_DEVID_AUTO* is used while
 creating the device, the ids in the device name would change and
 PHY_LOOKUP wont be useful.

 I don't think this is a problem. All the existing lookup methods already 
 use ID to identify devices (see regulators, clkdev, PWMs, i2c, ...). You 
 can simply add a requirement that the ID must be assigned manually, 
 without using PLATFORM_DEVID_AUTO to use PHY lookup.

 And I'm saying that this idea, of using a specific name and id, is
 frought with fragility and will break in the future in various ways when
 devices get added to systems, making these strings constantly have to be
 kept up to date with different board configurations.

 People, NEVER, hardcode something like an id.  The fact that this
 happens today with the clock code, doesn't make it right, it makes the
 clock code wrong.  Others have already said that this is wrong there as
 well, as systems change and dynamic ids get used more and more.

 Let's not repeat the same mistakes of the past just because we refuse to
 learn from them...

 So again, the find a phy by a string functions should be removed, the
 device id should be automatically created by the phy core just to make
 things unique in sysfs, and no driver code should _ever_ be reliant on
 the number that is being created, and the pointer to the phy structure
 should be used everywhere instead.

 With those types of changes, I will consider merging this subsystem, but
 without them, sorry, I will not.
 
 I'll agree with Greg

RE: [PATCH 3/3] ARM: EXYNOS: Add G2D support to exynos5250

2013-07-30 Thread Kukjin Kim 
Sachin Kamat wrote:
 
 Adds G2D node to exynos5250 DT file.
 
 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 ---
  arch/arm/boot/dts/exynos5250.dtsi |8 
  1 file changed, 8 insertions(+)
 
 diff --git a/arch/arm/boot/dts/exynos5250.dtsi
 b/arch/arm/boot/dts/exynos5250.dtsi
 index ef57277..6f356ce 100644
 --- a/arch/arm/boot/dts/exynos5250.dtsi
 +++ b/arch/arm/boot/dts/exynos5250.dtsi
 @@ -163,6 +163,14 @@
   clock-names = watchdog;
   };
 
 + g2d@1085 {
 + compatible = samsung,exynos5250-g2d;
 + reg = 0x1085 0x1000;
 + interrupts = 0 91 0;
 + clocks = clock 345;
 + clock-names = fimg2d;
 + };
 +
   codec@1100 {
   compatible = samsung,mfc-v6;
   reg = 0x1100 0x1;
 --
 1.7.9.5

Looks ok to me, applied.

Thanks,
Kukjin

--
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