date:20131004

Re: [PATCH 1/6] thermal: exynos: fix: Return from exynos_report_trigger() when therm_dev is NULL

2013-10-04 Thread Lukasz Majewski

Hi Eduardo,

Thanks for reply.

 On 24-09-2013 04:08, Lukasz Majewski wrote:
  The commit 4de0bdaa9677d11406c9becb70c60887c957e1f0
  (thermal: exynos: Add support for instance based
  register/unregister) broke check for presence of therm_dev at
  global thermal zone in exynos_report_trigger().
  
  The resulting wrong test prevents thermal_zone_device_update()
  call, which calls handlers for situation when trip points are
  passed. Such behavior prevents thermal driver from proper reaction
  (when TMU interrupt is raised) in a situation when overheating is
  detected at TMU hardware. This patch fixes it.
  
  Signed-off-by: Lukasz Majewski l.majew...@samsung.com
  Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
  Reviewed-by: Tomasz Figa t.f...@samsung.com
  ---
   drivers/thermal/samsung/exynos_thermal_common.c |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
  
  diff --git a/drivers/thermal/samsung/exynos_thermal_common.c
  b/drivers/thermal/samsung/exynos_thermal_common.c index
  f10a6ad..55a912a 100644 ---
  a/drivers/thermal/samsung/exynos_thermal_common.c +++
  b/drivers/thermal/samsung/exynos_thermal_common.c @@ -310,7 +310,7
  @@ void exynos_report_trigger(struct thermal_sensor_conf *conf) }
   
  th_zone = conf-pzone_data;
  -   if (th_zone-therm_dev)
  +   if (!th_zone-therm_dev)
 
 Fine with this fix, as it really looks obvious. But after reading the
 code a bit, I am considering if we can remove the above check at all.

I have just preserved the old behaviour for -rcX fix.

 
 Reading the driver code piece at drivers/thermal/samsung/exynos_tmu.c,
 by checking how exynos_register_thermal gets called, and how error is
 handled, I assume we do not need to check for th_zone-therm_dev.

It looks like we don't need this check (we will not register the
thermal zone if therm dev is not correct).

 
 To me looks like the driver only allows th_zone's exist only with
 valid therm_dev, isn't it? Except for the probe sequence, maybe, at
 run time there is a time window that we have valid th_zone with
 invalid therm_dev. However, reading the probe, still, the irq gets
 initialized only in very end, so the work queue don't get queue till
 then at least.
 
 So, my question before acking is, shall we remove this check
 altogether?

I think that it is up to you to decide how we proceed. 

Shall this patch go into v3.12-rcX since it is obvious (and documents
what and when was broken) or would you require to prepare new patch
with removal of this check?

 
 
  return;
   
  if (th_zone-bind == false) {
  
 
 



-- 
Best regards,

Lukasz Majewski

Samsung RD Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/6] thermal: exynos: Provide separate TMU data for Exynos4412

2013-10-04 Thread Lukasz Majewski

Hi Eduardo,

 Lukasz,
 
 Just minor comments.
 
 On 24-09-2013 04:08, Lukasz Majewski wrote:
  Up till now Exynos5250 and Exynos4412 had the same definitions for
  TMU data. Following commit changes that, by introducing separate
  exynos4412_default_tmu_data structure.
  
  Since Exynos4412 was chronologically first, the corresponding name
  for TMU registers and default data was renamed.
  
  Additionally, new SOC_ARCH_EXYNOS4412 type has been defined.
 
 It is not clear the objective of the patch itself. Was it just to make
 the code more readable or are you fixing something?

I'm fixing thermal on EXYNOS4412 device (trats2). The problem here is
to do it properly, since on the current code EXYNOS4412 and EXYNOS5250
uses the same configuration data.

To fix this problem, I had to split them. Also chronologically the
THERMAL IP first appeared on EXYNOS4412, not EXYNOS5250.

 
  
  Signed-off-by: Lukasz Majewski l.majew...@samsung.com
  Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
  Reviewed-by: Tomasz Figa t.f...@samsung.com
  ---
   drivers/thermal/samsung/exynos_tmu.c  |7 ---
   drivers/thermal/samsung/exynos_tmu.h  |1 +
   drivers/thermal/samsung/exynos_tmu_data.c |   26
  --
  drivers/thermal/samsung/exynos_tmu_data.h |9 - 4 files
  changed, 33 insertions(+), 10 deletions(-)
  
  diff --git a/drivers/thermal/samsung/exynos_tmu.c
  b/drivers/thermal/samsung/exynos_tmu.c index b43afda..a858cc4 100644
  --- a/drivers/thermal/samsung/exynos_tmu.c
  +++ b/drivers/thermal/samsung/exynos_tmu.c
  @@ -488,7 +488,7 @@ static const struct of_device_id
  exynos_tmu_match[] = { },
  {
  .compatible = samsung,exynos4412-tmu,
  -   .data = (void *)EXYNOS5250_TMU_DRV_DATA,
  +   .data = (void *)EXYNOS4412_TMU_DRV_DATA,
  },
  {
  .compatible = samsung,exynos5250-tmu,
  @@ -630,8 +630,9 @@ static int exynos_tmu_probe(struct
  platform_device *pdev) return ret;
   
  if (pdata-type == SOC_ARCH_EXYNOS ||
  -   pdata-type == SOC_ARCH_EXYNOS4210 ||
  -   pdata-type == SOC_ARCH_EXYNOS5440)
  +   pdata-type == SOC_ARCH_EXYNOS4210 ||
  +   pdata-type == SOC_ARCH_EXYNOS4412 ||
  +   pdata-type == SOC_ARCH_EXYNOS5440)
  data-soc = pdata-type;
  else {
  ret = -EINVAL;
  diff --git a/drivers/thermal/samsung/exynos_tmu.h
  b/drivers/thermal/samsung/exynos_tmu.h index b364c9e..db37df0 100644
  --- a/drivers/thermal/samsung/exynos_tmu.h
  +++ b/drivers/thermal/samsung/exynos_tmu.h
  @@ -41,6 +41,7 @@ enum calibration_mode {
   
   enum soc_type {
  SOC_ARCH_EXYNOS4210 = 1,
  +   SOC_ARCH_EXYNOS4412,
  SOC_ARCH_EXYNOS,
  SOC_ARCH_EXYNOS5440,
   };
 
 I believe the above enum needs some documentation. SOC_ARCH_EXYNOS
 seams to be a bit confusing.

This is fixed at patch 4/6 of the series.

 
  diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
  b/drivers/thermal/samsung/exynos_tmu_data.c index 9002499..bd08093
  100644 --- a/drivers/thermal/samsung/exynos_tmu_data.c
  +++ b/drivers/thermal/samsung/exynos_tmu_data.c
  @@ -90,8 +90,8 @@ struct exynos_tmu_init_data const
  exynos4210_default_tmu_data = { };
   #endif
   
  -#if defined(CONFIG_SOC_EXYNOS5250) ||
  defined(CONFIG_SOC_EXYNOS4412) -static const struct
  exynos_tmu_registers exynos5250_tmu_registers = { +#if
  defined(CONFIG_SOC_EXYNOS4412) || defined(CONFIG_SOC_EXYNOS5250)
  +static const struct exynos_tmu_registers exynos4412_tmu_registers
  = { .triminfo_data = EXYNOS_TMU_REG_TRIMINFO, .triminfo_25_shift =
  EXYNOS_TRIMINFO_25_SHIFT, .triminfo_85_shift =
  EXYNOS_TRIMINFO_85_SHIFT, @@ -128,7 +128,7 @@ static const struct
  exynos_tmu_registers exynos5250_tmu_registers = { .emul_time_mask =
  EXYNOS_EMUL_TIME_MASK, };
   
  -#define EXYNOS5250_TMU_DATA \
  +#define EXYNOS4412_TMU_DATA \
  .threshold_falling = 10, \
  .trigger_levels[0] = 85, \
  .trigger_levels[1] = 103, \
  @@ -162,15 +162,29 @@ static const struct exynos_tmu_registers
  exynos5250_tmu_registers = { .temp_level = 103, \
  }, \
  .freq_tab_count = 2, \
  -   .type = SOC_ARCH_EXYNOS, \
  -   .registers = exynos5250_tmu_registers, \
  +   .registers = exynos4412_tmu_registers, \
  .features = (TMU_SUPPORT_EMULATION |
  TMU_SUPPORT_TRIM_RELOAD | \ TMU_SUPPORT_FALLING_TRIP |
  TMU_SUPPORT_READY_STATUS | \ TMU_SUPPORT_EMUL_TIME)
  +#endif
   
  +#if defined(CONFIG_SOC_EXYNOS4412)
  +struct exynos_tmu_init_data const exynos4412_default_tmu_data = {
  +   .tmu_data = {
  +   { EXYNOS4412_TMU_DATA,
  +   .type = SOC_ARCH_EXYNOS4412,
  +   },
  +   },
  +   .tmu_count = 1,
  +};
  +#endif
  +
  +#if defined(CONFIG_SOC_EXYNOS5250)
   struct exynos_tmu_init_data const exynos5250_default_tmu_data = {
  .tmu_data = {
  -   { EXYNOS5250_TMU_DATA },
  +   { EXYNOS4412_TMU_DATA,
  +   .type = SOC_ARCH_EXYNOS,
  +   },

Re: [PATCH 4/6] thermal: exynos: Replace SOC_ARCH_EXYNOS with SOC_ARCH_EXYNOS5250

2013-10-04 Thread Bartlomiej Zolnierkiewicz


Hi,

On Thursday, October 03, 2013 06:08:45 PM Eduardo Valentin wrote:
 On 24-09-2013 04:08, Lukasz Majewski wrote:
  The TMU data definition is now separated to Exynos4412 and Exynos5250.
  
  Now SOC_ARCH_EXYNOS only refers to Exynos5250. Hence the name
  SOC_ARCH_EXYNOS has been changed to SOC_ARCH_EXYNOS5250.
  
 
 How about merging this one with patch 02?

I would prefer that this is not done since patch #2 is a separate logical
change and it should be kept as a minimal preparatory patch for patch #3
(which is an important bugfix) to make potential backporting of fixes into
-stable etc. easier.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics

  Signed-off-by: Lukasz Majewski l.majew...@samsung.com
  ---
   drivers/thermal/samsung/exynos_tmu.c  |4 ++--
   drivers/thermal/samsung/exynos_tmu.h  |2 +-
   drivers/thermal/samsung/exynos_tmu_data.c |2 +-
   3 files changed, 4 insertions(+), 4 deletions(-)
  
  diff --git a/drivers/thermal/samsung/exynos_tmu.c 
  b/drivers/thermal/samsung/exynos_tmu.c
  index 21b89e4..037cd46 100644
  --- a/drivers/thermal/samsung/exynos_tmu.c
  +++ b/drivers/thermal/samsung/exynos_tmu.c
  @@ -632,9 +632,9 @@ static int exynos_tmu_probe(struct platform_device 
  *pdev)
  if (ret)
  return ret;
   
  -   if (pdata-type == SOC_ARCH_EXYNOS ||
  -   pdata-type == SOC_ARCH_EXYNOS4210 ||
  +   if (pdata-type == SOC_ARCH_EXYNOS4210 ||
  pdata-type == SOC_ARCH_EXYNOS4412 ||
  +   pdata-type == SOC_ARCH_EXYNOS5250 ||
  pdata-type == SOC_ARCH_EXYNOS5440)
  data-soc = pdata-type;
  else {
  diff --git a/drivers/thermal/samsung/exynos_tmu.h 
  b/drivers/thermal/samsung/exynos_tmu.h
  index db37df0..b42ece4 100644
  --- a/drivers/thermal/samsung/exynos_tmu.h
  +++ b/drivers/thermal/samsung/exynos_tmu.h
  @@ -42,7 +42,7 @@ enum calibration_mode {
   enum soc_type {
  SOC_ARCH_EXYNOS4210 = 1,
  SOC_ARCH_EXYNOS4412,
  -   SOC_ARCH_EXYNOS,
  +   SOC_ARCH_EXYNOS5250,
  SOC_ARCH_EXYNOS5440,
   };
   
  diff --git a/drivers/thermal/samsung/exynos_tmu_data.c 
  b/drivers/thermal/samsung/exynos_tmu_data.c
  index bd08093..188223f 100644
  --- a/drivers/thermal/samsung/exynos_tmu_data.c
  +++ b/drivers/thermal/samsung/exynos_tmu_data.c
  @@ -183,7 +183,7 @@ struct exynos_tmu_init_data const 
  exynos4412_default_tmu_data = {
   struct exynos_tmu_init_data const exynos5250_default_tmu_data = {
  .tmu_data = {
  { EXYNOS4412_TMU_DATA,
  -   .type = SOC_ARCH_EXYNOS,
  +   .type = SOC_ARCH_EXYNOS5250,
  },
  },
  .tmu_count = 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 3/6] thermal: exynos: Provide initial setting for TMU's test MUX address at Exynos4412

2013-10-04 Thread Lukasz Majewski

Hi Eduardo,

 On 24-09-2013 04:08, Lukasz Majewski wrote:
  The commit d0a0ce3e77c795258d47f9163e92d5031d0c5221 (thermal:
  exynos: Add missing definations and code cleanup) has removed
  setting of test MUX address value at TMU configuration setting.
  
  This field is not present on Exynos4210 and Exynos5 SoCs. However
  on Exynos4412 SoC it is required to set this field after reset
  because without it TMU shows maximal available temperature, which
  causes immediate platform shutdown.
  
  Signed-off-by: Lukasz Majewski l.majew...@samsung.com
  Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
  Reviewed-by: Tomasz Figa t.f...@samsung.com
  ---
   drivers/thermal/samsung/exynos_tmu.c  |3 +++
   drivers/thermal/samsung/exynos_tmu_data.h |4 
   2 files changed, 7 insertions(+)
  
  diff --git a/drivers/thermal/samsung/exynos_tmu.c
  b/drivers/thermal/samsung/exynos_tmu.c index a858cc4..21b89e4 100644
  --- a/drivers/thermal/samsung/exynos_tmu.c
  +++ b/drivers/thermal/samsung/exynos_tmu.c
  @@ -317,6 +317,9 @@ static void exynos_tmu_control(struct
  platform_device *pdev, bool on) 
  con = readl(data-base + reg-tmu_ctrl);
   
  +   if (pdata-type == SOC_ARCH_EXYNOS4412)
  +   con |= (EXYNOS4412_MUX_ADDR_VALUE 
  EXYNOS4412_MUX_ADDR_SHIFT);
 
 Amit has introduced a way to describe features instead of checking
 features per type. It would be interesting to have a reasoning why not
 to use it. 

Problem with Exynos4412 and Exynos4212 is that _only_ those SoCs export
this MUX_ADDR field at TMU_CONTROL register. Also I _must_ setup it
correctly after reset (reset value causes board emergency shutdown).

The Exynos5250 defines it as a reserved.

 Think what if new Exynos TMU versions come, are you guys
 going to steadily increase the above check for type?

As the alternative I can define the TMU_SUPPORT_MUX_ADDR at .features
field for EXYNOS4412_TMU_DATA.

Then I can test for this feature at exynos_tmu_control function.
Proper shift and mask can be defined at struct exynos_tmu_registers.

Eduardo, Amit, will we manage to review/pull those patches with new
approach before -rcX ends?

 
  +
  if (pdata-reference_voltage) {
  con = ~(reg-buf_vref_sel_mask 
  reg-buf_vref_sel_shift); con |= pdata-reference_voltage 
  reg-buf_vref_sel_shift; diff --git
  a/drivers/thermal/samsung/exynos_tmu_data.h
  b/drivers/thermal/samsung/exynos_tmu_data.h index b130b1e..a1ea19d
  100644 --- a/drivers/thermal/samsung/exynos_tmu_data.h +++
  b/drivers/thermal/samsung/exynos_tmu_data.h @@ -95,6 +95,10 @@
   
   #define EXYNOS_MAX_TRIGGER_PER_REG 4
   
  +/* Exynos4412 specific */
  +#define EXYNOS4412_MUX_ADDR_VALUE  6
  +#define EXYNOS4412_MUX_ADDR_SHIFT  20
  +
   /*exynos5440 specific registers*/
   #define EXYNOS5440_TMU_S0_7_TRIM   0x000
   #define EXYNOS5440_TMU_S0_7_CTRL   0x020
  
 
 



-- 
Best regards,

Lukasz Majewski

Samsung RD Institute Poland (SRPOL) | Linux Platform Group
--
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/6] thermal: exynos: Replace SOC_ARCH_EXYNOS with SOC_ARCH_EXYNOS5250

2013-10-04 Thread Lukasz Majewski

Hi Eduardo,

 On 24-09-2013 04:08, Lukasz Majewski wrote:
  The TMU data definition is now separated to Exynos4412 and
  Exynos5250.
  
  Now SOC_ARCH_EXYNOS only refers to Exynos5250. Hence the name
  SOC_ARCH_EXYNOS has been changed to SOC_ARCH_EXYNOS5250.
  
 
 How about merging this one with patch 02?

I wanted to show how the work was logically split - patch 02
extracts Exynos4412 from Exynos5250. Then this patch changes the name.

I will merge those two patches. No problem.

 
  Signed-off-by: Lukasz Majewski l.majew...@samsung.com
  ---
   drivers/thermal/samsung/exynos_tmu.c  |4 ++--
   drivers/thermal/samsung/exynos_tmu.h  |2 +-
   drivers/thermal/samsung/exynos_tmu_data.c |2 +-
   3 files changed, 4 insertions(+), 4 deletions(-)
  
  diff --git a/drivers/thermal/samsung/exynos_tmu.c
  b/drivers/thermal/samsung/exynos_tmu.c index 21b89e4..037cd46 100644
  --- a/drivers/thermal/samsung/exynos_tmu.c
  +++ b/drivers/thermal/samsung/exynos_tmu.c
  @@ -632,9 +632,9 @@ static int exynos_tmu_probe(struct
  platform_device *pdev) if (ret)
  return ret;
   
  -   if (pdata-type == SOC_ARCH_EXYNOS ||
  -   pdata-type == SOC_ARCH_EXYNOS4210 ||
  +   if (pdata-type == SOC_ARCH_EXYNOS4210 ||
  pdata-type == SOC_ARCH_EXYNOS4412 ||
  +   pdata-type == SOC_ARCH_EXYNOS5250 ||
  pdata-type == SOC_ARCH_EXYNOS5440)
  data-soc = pdata-type;
  else {
  diff --git a/drivers/thermal/samsung/exynos_tmu.h
  b/drivers/thermal/samsung/exynos_tmu.h index db37df0..b42ece4 100644
  --- a/drivers/thermal/samsung/exynos_tmu.h
  +++ b/drivers/thermal/samsung/exynos_tmu.h
  @@ -42,7 +42,7 @@ enum calibration_mode {
   enum soc_type {
  SOC_ARCH_EXYNOS4210 = 1,
  SOC_ARCH_EXYNOS4412,
  -   SOC_ARCH_EXYNOS,
  +   SOC_ARCH_EXYNOS5250,
  SOC_ARCH_EXYNOS5440,
   };
   
  diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
  b/drivers/thermal/samsung/exynos_tmu_data.c index bd08093..188223f
  100644 --- a/drivers/thermal/samsung/exynos_tmu_data.c
  +++ b/drivers/thermal/samsung/exynos_tmu_data.c
  @@ -183,7 +183,7 @@ struct exynos_tmu_init_data const
  exynos4412_default_tmu_data = { struct exynos_tmu_init_data const
  exynos5250_default_tmu_data = { .tmu_data = {
  { EXYNOS4412_TMU_DATA,
  -   .type = SOC_ARCH_EXYNOS,
  +   .type = SOC_ARCH_EXYNOS5250,
  },
  },
  .tmu_count = 1,
  
 
 



-- 
Best regards,

Lukasz Majewski

Samsung RD Institute Poland (SRPOL) | Linux Platform Group
--
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/6] thermal: exynos: Replace SOC_ARCH_EXYNOS with SOC_ARCH_EXYNOS5250

2013-10-04 Thread Bartlomiej Zolnierkiewicz

On Friday, October 04, 2013 12:23:30 PM Lukasz Majewski wrote:
 Hi Eduardo,
 
  On 24-09-2013 04:08, Lukasz Majewski wrote:
   The TMU data definition is now separated to Exynos4412 and
   Exynos5250.
   
   Now SOC_ARCH_EXYNOS only refers to Exynos5250. Hence the name
   SOC_ARCH_EXYNOS has been changed to SOC_ARCH_EXYNOS5250.
   
  
  How about merging this one with patch 02?
 
 I wanted to show how the work was logically split - patch 02
 extracts Exynos4412 from Exynos5250. Then this patch changes the name.
 
 I will merge those two patches. No problem.

Oh, well. Looking at the patch #2 again the merge can be done without
sacrificing backportability.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics

  
   Signed-off-by: Lukasz Majewski l.majew...@samsung.com
   ---
drivers/thermal/samsung/exynos_tmu.c  |4 ++--
drivers/thermal/samsung/exynos_tmu.h  |2 +-
drivers/thermal/samsung/exynos_tmu_data.c |2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
   
   diff --git a/drivers/thermal/samsung/exynos_tmu.c
   b/drivers/thermal/samsung/exynos_tmu.c index 21b89e4..037cd46 100644
   --- a/drivers/thermal/samsung/exynos_tmu.c
   +++ b/drivers/thermal/samsung/exynos_tmu.c
   @@ -632,9 +632,9 @@ static int exynos_tmu_probe(struct
   platform_device *pdev) if (ret)
 return ret;

   - if (pdata-type == SOC_ARCH_EXYNOS ||
   - pdata-type == SOC_ARCH_EXYNOS4210 ||
   + if (pdata-type == SOC_ARCH_EXYNOS4210 ||
 pdata-type == SOC_ARCH_EXYNOS4412 ||
   + pdata-type == SOC_ARCH_EXYNOS5250 ||
 pdata-type == SOC_ARCH_EXYNOS5440)
 data-soc = pdata-type;
 else {
   diff --git a/drivers/thermal/samsung/exynos_tmu.h
   b/drivers/thermal/samsung/exynos_tmu.h index db37df0..b42ece4 100644
   --- a/drivers/thermal/samsung/exynos_tmu.h
   +++ b/drivers/thermal/samsung/exynos_tmu.h
   @@ -42,7 +42,7 @@ enum calibration_mode {
enum soc_type {
 SOC_ARCH_EXYNOS4210 = 1,
 SOC_ARCH_EXYNOS4412,
   - SOC_ARCH_EXYNOS,
   + SOC_ARCH_EXYNOS5250,
 SOC_ARCH_EXYNOS5440,
};

   diff --git a/drivers/thermal/samsung/exynos_tmu_data.c
   b/drivers/thermal/samsung/exynos_tmu_data.c index bd08093..188223f
   100644 --- a/drivers/thermal/samsung/exynos_tmu_data.c
   +++ b/drivers/thermal/samsung/exynos_tmu_data.c
   @@ -183,7 +183,7 @@ struct exynos_tmu_init_data const
   exynos4412_default_tmu_data = { struct exynos_tmu_init_data const
   exynos5250_default_tmu_data = { .tmu_data = {
 { EXYNOS4412_TMU_DATA,
   - .type = SOC_ARCH_EXYNOS,
   + .type = SOC_ARCH_EXYNOS5250,
 },
 },
 .tmu_count = 1,

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

[PATCH v4 0/4] Exynos5 Series SCALER Driver

2013-10-04 Thread Shaik Ameer Basha

This patch adds support for SCALER device which is a
new device for scaling, blending, color fill  and color space
conversion on EXYNOS5410/5420 SoCs.

This device supports the following as key features.
input image format
- YCbCr420 2P(UV/VU), 3P
- YCbCr422 1P(YUYV/UYVY/YVYU), 2P(UV,VU), 3P
- YCbCr444 2P(UV,VU), 3P
- RGB565, ARGB1555, ARGB, ARGB, RGBA
- Pre-multiplexed ARGB, L8A8 and L8
output image format
- YCbCr420 2P(UV/VU), 3P
- YCbCr422 1P(YUYV/UYVY/YVYU), 2P(UV,VU), 3P
- YCbCr444 2P(UV,VU), 3P
- RGB565, ARGB1555, ARGB, ARGB, RGBA
- Pre-multiplexed ARGB
input rotation
- 0/90/180/270 degree, X/Y/XY Flip
scale ratio
- 1/4 scale down to 16 scale up
color space conversion
- RGB to YUV / YUV to RGB
Size - Exynos5420
- Input : 16x16 to 8192x8192
- Output:   4x4 to 8192x8192
Size - Exynos5410
- Input/Output: 4x4 to 4096x4096
alpha blending, color fill

Rebased on:
---
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git:master

Changes from v3:
---
Addressed review comments from, Sylwester Nawrocki and Hans Verkuil.
Links to the review comments:
1] https://linuxtv.org/patch/20072/
2] https://linuxtv.org/patch/20073/

Changes from v2:
---
Addressed review comments from, Inki Dae, Hans Verkuil and Sylwester Nawrocki.
Links to the review comments:
1] https://linuxtv.org/patch/19783/
2] https://linuxtv.org/patch/19784/
3] https://linuxtv.org/patch/19785/
4] https://linuxtv.org/patch/19786/
5] https://linuxtv.org/patch/19787/

Changes from v1:
---
1] Split the previous single patch into multiple patches.
2] Added DT binding documentation.
3] Removed the unnecessary header file inclusions.
4] Fix the condition check in mscl_prepare_address for swapping cb/cr addresses.

Shaik Ameer Basha (4):
  [media] exynos-scaler: Add new driver for Exynos5 SCALER
  [media] exynos-scaler: Add core functionality for the SCALER driver
  [media] exynos-scaler: Add m2m functionality for the SCALER driver
  [media] exynos-scaler: Add DT bindings for SCALER driver

 .../devicetree/bindings/media/exynos5-scaler.txt   |   22 +
 drivers/media/platform/Kconfig |8 +
 drivers/media/platform/Makefile|1 +
 drivers/media/platform/exynos-scaler/Makefile  |3 +
 drivers/media/platform/exynos-scaler/scaler-m2m.c  |  786 +
 drivers/media/platform/exynos-scaler/scaler-regs.c |  336 ++
 drivers/media/platform/exynos-scaler/scaler-regs.h |  331 ++
 drivers/media/platform/exynos-scaler/scaler.c  | 1238 
 drivers/media/platform/exynos-scaler/scaler.h  |  375 ++
 9 files changed, 3100 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/exynos5-scaler.txt
 create mode 100644 drivers/media/platform/exynos-scaler/Makefile
 create mode 100644 drivers/media/platform/exynos-scaler/scaler-m2m.c
 create mode 100644 drivers/media/platform/exynos-scaler/scaler-regs.c
 create mode 100644 drivers/media/platform/exynos-scaler/scaler-regs.h
 create mode 100644 drivers/media/platform/exynos-scaler/scaler.c
 create mode 100644 drivers/media/platform/exynos-scaler/scaler.h

-- 
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 v4 4/4] [media] exynos-scaler: Add DT bindings for SCALER driver

2013-10-04 Thread Shaik Ameer Basha

This patch adds the DT binding documentation for the
Exynos5420/5410 based SCALER device driver.

Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
 .../devicetree/bindings/media/exynos5-scaler.txt   |   22 
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/exynos5-scaler.txt

diff --git a/Documentation/devicetree/bindings/media/exynos5-scaler.txt 
b/Documentation/devicetree/bindings/media/exynos5-scaler.txt
new file mode 100644
index 000..f620baf
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/exynos5-scaler.txt
@@ -0,0 +1,22 @@
+* Samsung Exynos5 SCALER device
+
+SCALER is used for scaling, blending, color fill and color space
+conversion on EXYNOS[5420/5410] SoCs.
+
+Required properties:
+- compatible: should be samsung,exynos5420-scaler or
+   samsung,exynos5410-scaler
+- reg: should contain SCALER physical address location and length.
+- interrupts: should contain SCALER interrupt number
+- clocks: should contain the SCALER clock specifier, from the
+   common clock bindings
+- clock-names: should be scaler
+
+Example:
+   scaler_0: scaler@0x1280 {
+   compatible = samsung,exynos5420-scaler;
+   reg = 0x1280 0x1000;
+   interrupts = 0 220 0;
+   clocks = clock 381;
+   clock-names = scaler;
+   };
-- 
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 v4 3/4] [media] exynos-scaler: Add m2m functionality for the SCALER driver

2013-10-04 Thread Shaik Ameer Basha

This patch adds the Makefile and memory to memory (m2m) interface
functionality for the SCALER driver.

Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
 drivers/media/platform/Kconfig|8 +
 drivers/media/platform/Makefile   |1 +
 drivers/media/platform/exynos-scaler/Makefile |3 +
 drivers/media/platform/exynos-scaler/scaler-m2m.c |  786 +
 4 files changed, 798 insertions(+)
 create mode 100644 drivers/media/platform/exynos-scaler/Makefile
 create mode 100644 drivers/media/platform/exynos-scaler/scaler-m2m.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 8068d7b..339d3ba 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -201,6 +201,14 @@ config VIDEO_SAMSUNG_EXYNOS_GSC
help
  This is a v4l2 driver for Samsung EXYNOS5 SoC G-Scaler.
 
+config VIDEO_SAMSUNG_EXYNOS_SCALER
+   tristate Samsung Exynos SCALER driver
+   depends on OF  VIDEO_DEV  VIDEO_V4L2  ARCH_EXYNOS5
+   select VIDEOBUF2_DMA_CONTIG
+   select V4L2_MEM2MEM_DEV
+   help
+ This is a v4l2 driver for Samsung EXYNOS5410/5420 SoC SCALER.
+
 config VIDEO_SH_VEU
tristate SuperH VEU mem2mem video processing driver
depends on VIDEO_DEV  VIDEO_V4L2  GENERIC_HARDIRQS  HAS_DMA
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 4e4da48..14cdad5 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV)+= s5p-tv/
 
 obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D)+= s5p-g2d/
 obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += exynos-gsc/
+obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_SCALER)  += exynos-scaler/
 
 obj-$(CONFIG_BLACKFIN)  += blackfin/
 
diff --git a/drivers/media/platform/exynos-scaler/Makefile 
b/drivers/media/platform/exynos-scaler/Makefile
new file mode 100644
index 000..6c8a25b
--- /dev/null
+++ b/drivers/media/platform/exynos-scaler/Makefile
@@ -0,0 +1,3 @@
+exynos-scaler-objs := scaler.o scaler-m2m.o scaler-regs.o
+
+obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_SCALER)  += exynos-scaler.o
diff --git a/drivers/media/platform/exynos-scaler/scaler-m2m.c 
b/drivers/media/platform/exynos-scaler/scaler-m2m.c
new file mode 100644
index 000..eb3af85
--- /dev/null
+++ b/drivers/media/platform/exynos-scaler/scaler-m2m.c
@@ -0,0 +1,786 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung EXYNOS5 SoC series SCALER driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/module.h
+#include linux/pm_runtime.h
+
+#include media/v4l2-ioctl.h
+
+#include scaler-regs.h
+
+#define SCALER_DEF_PIX_FMT V4L2_PIX_FMT_RGB32
+#define SCALER_DEF_WIDTH   1280
+#define SCALER_DEF_HEIGHT  720
+
+static int scaler_m2m_ctx_stop_req(struct scaler_ctx *ctx)
+{
+   struct scaler_ctx *curr_ctx;
+   struct scaler_dev *scaler = ctx-scaler_dev;
+   int ret;
+
+   curr_ctx = v4l2_m2m_get_curr_priv(scaler-m2m.m2m_dev);
+   if (!scaler_m2m_pending(scaler) || (curr_ctx != ctx))
+   return 0;
+
+   scaler_ctx_state_lock_set(SCALER_CTX_STOP_REQ, ctx);
+   ret = wait_event_timeout(scaler-irq_queue,
+   !scaler_ctx_state_is_set(SCALER_CTX_STOP_REQ, ctx),
+   SCALER_SHUTDOWN_TIMEOUT);
+
+   return ret == 0 ? -ETIMEDOUT : ret;
+}
+
+static int scaler_m2m_start_streaming(struct vb2_queue *q, unsigned int count)
+{
+   struct scaler_ctx *ctx = q-drv_priv;
+   int ret;
+
+   ret = pm_runtime_get_sync(ctx-scaler_dev-pdev-dev);
+
+   return ret  0 ? 0 : ret;
+}
+
+static int scaler_m2m_stop_streaming(struct vb2_queue *q)
+{
+   struct scaler_ctx *ctx = q-drv_priv;
+   int ret;
+
+   ret = scaler_m2m_ctx_stop_req(ctx);
+   if (ret  0)
+   scaler_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
+
+   pm_runtime_put(ctx-scaler_dev-pdev-dev);
+
+   return 0;
+}
+
+void scaler_m2m_job_finish(struct scaler_ctx *ctx, int vb_state)
+{
+   struct vb2_buffer *src_vb, *dst_vb;
+
+   if (!ctx || !ctx-m2m_ctx)
+   return;
+
+   src_vb = v4l2_m2m_src_buf_remove(ctx-m2m_ctx);
+   dst_vb = v4l2_m2m_dst_buf_remove(ctx-m2m_ctx);
+
+   if (src_vb  dst_vb) {
+   v4l2_m2m_buf_done(src_vb, vb_state);
+   v4l2_m2m_buf_done(dst_vb, vb_state);
+
+   v4l2_m2m_job_finish(ctx-scaler_dev-m2m.m2m_dev,
+   ctx-m2m_ctx);
+   }
+}
+
+static void scaler_m2m_job_abort(void *priv)
+{
+   struct scaler_ctx *ctx = priv;
+   int ret;
+
+   ret = scaler_m2m_ctx_stop_req(ctx);
+   if (ret  0)
+

[PATCH v4 1/4] [media] exynos-scaler: Add new driver for Exynos5 SCALER

2013-10-04 Thread Shaik Ameer Basha

This patch adds support for SCALER device which is a new device
for scaling, blending, color fill  and color space conversion
on EXYNOS5410 and EXYNOS5420 SoCs.

This device supports the followings as key feature.
input image format
- YCbCr420 2P(UV/VU), 3P
- YCbCr422 1P(YUYV/UYVY/YVYU), 2P(UV,VU), 3P
- YCbCr444 2P(UV,VU), 3P
- RGB565, ARGB1555, ARGB, ARGB, RGBA
- Pre-multiplexed ARGB, L8A8 and L8
output image format
- YCbCr420 2P(UV/VU), 3P
- YCbCr422 1P(YUYV/UYVY/YVYU), 2P(UV,VU), 3P
- YCbCr444 2P(UV,VU), 3P
- RGB565, ARGB1555, ARGB, ARGB, RGBA
- Pre-multiplexed ARGB
input rotation
- 0/90/180/270 degree, X/Y/XY Flip
scale ratio
- 1/4 scale down to 16 scale up
color space conversion
- RGB to YUV / YUV to RGB
Size - Exynos5420
- Input : 16x16 to 8192x8192
- Output:   4x4 to 8192x8192
Size - Exynos5410
- Input/Output: 4x4 to 4096x4096
alpha blending, color fill

Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
 drivers/media/platform/exynos-scaler/scaler-regs.c |  336 
 drivers/media/platform/exynos-scaler/scaler-regs.h |  331 +++
 2 files changed, 667 insertions(+)
 create mode 100644 drivers/media/platform/exynos-scaler/scaler-regs.c
 create mode 100644 drivers/media/platform/exynos-scaler/scaler-regs.h

diff --git a/drivers/media/platform/exynos-scaler/scaler-regs.c 
b/drivers/media/platform/exynos-scaler/scaler-regs.c
new file mode 100644
index 000..ae4a548
--- /dev/null
+++ b/drivers/media/platform/exynos-scaler/scaler-regs.c
@@ -0,0 +1,336 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung EXYNOS5 SoC series SCALER driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/platform_device.h
+
+#include scaler-regs.h
+
+/* Scaler reset timeout in milliseconds */
+#define SCALER_RESET_TIMEOUT   50
+
+void scaler_hw_set_sw_reset(struct scaler_dev *dev)
+{
+   u32 cfg;
+
+   cfg = scaler_read(dev, SCALER_CFG);
+   cfg |= SCALER_CFG_SOFT_RESET;
+
+   scaler_write(dev, SCALER_CFG, cfg);
+}
+
+int scaler_wait_reset(struct scaler_dev *dev)
+{
+   unsigned long end = jiffies + msecs_to_jiffies(SCALER_RESET_TIMEOUT);
+   u32 cfg, reset_done = 0;
+
+   while (time_before(jiffies, end)) {
+   cfg = scaler_read(dev, SCALER_CFG);
+   if (!(cfg  SCALER_CFG_SOFT_RESET)) {
+   reset_done = 1;
+   break;
+   }
+   usleep_range(10, 20);
+   }
+
+   /*
+* Write any value to read/write register and read it back.
+* If the written and read value matches, then the reset process is
+* succeeded.
+*/
+   while (reset_done) {
+
+   /*
+* TODO: need to define number of tries before returning
+* -EBUSY to the caller
+*/
+
+   scaler_write(dev, SCALER_CFG_SOFT_RESET_CHECK_REG,
+   SCALER_CFG_SOFT_RESET_CHECK_VAL);
+   if (SCALER_CFG_SOFT_RESET_CHECK_VAL ==
+   scaler_read(dev, SCALER_CFG_SOFT_RESET_CHECK_REG))
+   return 0;
+   }
+
+   return -EBUSY;
+}
+
+void scaler_hw_set_irq(struct scaler_dev *dev, int irq_num, bool enable)
+{
+   u32 cfg;
+
+   if ((irq_num  SCALER_INT_FRAME_END) ||
+   (irq_num  SCALER_INT_TIMEOUT))
+   return;
+
+   cfg = scaler_read(dev, SCALER_INT_EN);
+   if (enable)
+   cfg |= (1  irq_num);
+   else
+   cfg = ~(1  irq_num);
+   scaler_write(dev, SCALER_INT_EN, cfg);
+}
+
+void scaler_hw_set_input_addr(struct scaler_dev *dev, struct scaler_addr *addr)
+{
+   scaler_dbg(dev, src_buf: 0x%x, cb: 0x%x, cr: 0x%x,
+   addr-y, addr-cb, addr-cr);
+   scaler_write(dev, SCALER_SRC_Y_BASE, addr-y);
+   scaler_write(dev, SCALER_SRC_CB_BASE, addr-cb);
+   scaler_write(dev, SCALER_SRC_CR_BASE, addr-cr);
+}
+
+void scaler_hw_set_output_addr(struct scaler_dev *dev,
+struct scaler_addr *addr)
+{
+   scaler_dbg(dev, dst_buf: 0x%x, cb: 0x%x, cr: 0x%x,
+   addr-y, addr-cb, addr-cr);
+   scaler_write(dev, SCALER_DST_Y_BASE, addr-y);
+   scaler_write(dev, SCALER_DST_CB_BASE, addr-cb);
+   scaler_write(dev, SCALER_DST_CR_BASE, addr-cr);
+}
+
+void scaler_hw_set_in_size(struct scaler_ctx *ctx)
+{
+   struct scaler_dev *dev = ctx-scaler_dev;
+   struct scaler_frame *frame = ctx-s_frame;
+   u32 cfg;
+
+   /* set input pixel offset */
+

[PATCH v4 2/4] [media] exynos-scaler: Add core functionality for the SCALER driver

2013-10-04 Thread Shaik Ameer Basha

This patch adds the core functionality for the SCALER driver.

Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
 drivers/media/platform/exynos-scaler/scaler.c | 1238 +
 drivers/media/platform/exynos-scaler/scaler.h |  375 
 2 files changed, 1613 insertions(+)
 create mode 100644 drivers/media/platform/exynos-scaler/scaler.c
 create mode 100644 drivers/media/platform/exynos-scaler/scaler.h

diff --git a/drivers/media/platform/exynos-scaler/scaler.c 
b/drivers/media/platform/exynos-scaler/scaler.c
new file mode 100644
index 000..57635f2
--- /dev/null
+++ b/drivers/media/platform/exynos-scaler/scaler.c
@@ -0,0 +1,1238 @@
+/*
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung EXYNOS5 SoC series SCALER driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/interrupt.h
+#include linux/module.h
+#include linux/of_platform.h
+#include linux/pm_runtime.h
+
+#include scaler-regs.h
+
+#define SCALER_CLOCK_GATE_NAME scaler
+
+static const struct scaler_fmt scaler_formats[] = {
+   {
+   .name   = YUV 4:2:0 non-contig. 2p, Y/CbCr,
+   .pixelformat= V4L2_PIX_FMT_NV12M,
+   .depth  = { 8, 4 },
+   .color  = SCALER_YUV420,
+   .color_order= SCALER_CBCR,
+   .num_planes = 2,
+   .num_comp   = 2,
+   .scaler_color   = SCALER_YUV420_2P_Y_UV,
+   .flags  = (SCALER_FMT_SRC | SCALER_FMT_DST),
+
+   }, {
+   .name   = YUV 4:2:0 contig. 2p, Y/CbCr,
+   .pixelformat= V4L2_PIX_FMT_NV12,
+   .depth  = { 12 },
+   .color  = SCALER_YUV420,
+   .color_order= SCALER_CBCR,
+   .num_planes = 1,
+   .num_comp   = 2,
+   .scaler_color   = SCALER_YUV420_2P_Y_UV,
+   .flags  = (SCALER_FMT_SRC | SCALER_FMT_DST),
+   }, {
+   .name   = YUV 4:2:0 n.c. 2p, Y/CbCr tiled,
+   .pixelformat= V4L2_PIX_FMT_NV12MT_16X16,
+   .depth  = { 8, 4 },
+   .color  = SCALER_YUV420,
+   .color_order= SCALER_CBCR,
+   .num_planes = 2,
+   .num_comp   = 2,
+   .scaler_color   = SCALER_YUV420_2P_Y_UV,
+   .flags  = (SCALER_FMT_SRC | SCALER_FMT_TILED),
+   }, {
+   .name   = YUV 4:2:2 contig. 2p, Y/CbCr,
+   .pixelformat= V4L2_PIX_FMT_NV16,
+   .depth  = { 16 },
+   .color  = SCALER_YUV422,
+   .color_order= SCALER_CBCR,
+   .num_planes = 1,
+   .num_comp   = 2,
+   .scaler_color   = SCALER_YUV422_2P_Y_UV,
+   .flags  = (SCALER_FMT_SRC | SCALER_FMT_DST),
+   }, {
+   .name   = YUV 4:4:4 contig. 2p, Y/CbCr,
+   .pixelformat= V4L2_PIX_FMT_NV24,
+   .depth  = { 24 },
+   .color  = SCALER_YUV444,
+   .color_order= SCALER_CBCR,
+   .num_planes = 1,
+   .num_comp   = 2,
+   .scaler_color   = SCALER_YUV444_2P_Y_UV,
+   .flags  = (SCALER_FMT_SRC | SCALER_FMT_DST),
+   }, {
+   .name   = RGB565,
+   .pixelformat= V4L2_PIX_FMT_RGB565X,
+   .depth  = { 16 },
+   .color  = SCALER_RGB,
+   .num_planes = 1,
+   .num_comp   = 1,
+   .scaler_color   = SCALER_RGB565,
+   .flags  = (SCALER_FMT_SRC | SCALER_FMT_DST),
+   }, {
+   .name   = XRGB-1555, 16 bpp,
+   .pixelformat= V4L2_PIX_FMT_RGB555,
+   .depth  = { 16 },
+   .color  = SCALER_RGB,
+   .num_planes = 1,
+   .num_comp   = 1,
+   .scaler_color   = SCALER_ARGB1555,
+   .flags  = (SCALER_FMT_SRC | SCALER_FMT_DST),
+   }, {
+   .name   = XRGB-, 32 bpp,
+   .pixelformat= V4L2_PIX_FMT_RGB32,
+   .depth  = { 32 },
+   .color  = SCALER_RGB,
+   .num_planes = 1,
+   .num_comp   = 1,
+   .scaler_color   = SCALER_ARGB,
+   .flags  = (SCALER_FMT_SRC | SCALER_FMT_DST),
+   }, {
+   .name   = YUV 4:2:2 packed, YCrYCb,
+   .pixelformat= V4L2_PIX_FMT_YVYU,
+   .depth  = { 16

[PATCH] thermal: offer Samsung thermal support only when ARCH_EXYNOS is defined

2013-10-04 Thread Bartlomiej Zolnierkiewicz

Menu for Samsung thermal support is visible on all Samsung
platforms while thermal drivers are currently available only
for EXYNOS SoCs. Fix it by replacing PLAT_SAMSUNG dependency
with ARCH_EXYNOS one.

Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/thermal/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index a709c63..05cf95c 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -198,7 +198,7 @@ source drivers/thermal/ti-soc-thermal/Kconfig
 endmenu
 
 menu Samsung thermal drivers
-depends on PLAT_SAMSUNG
+depends on ARCH_EXYNOS
 source drivers/thermal/samsung/Kconfig
 endmenu
 
-- 
1.8.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] thermal: EXYNOS: always register TMU driver with core thermal framework

2013-10-04 Thread Bartlomiej Zolnierkiewicz

There is little sense in having separate config option for
registering EXYNOS TMU driver with the core thermal framework.
Fix it by integrating EXYNOS_THERMAL_CORE config option with
EXYNOS_THERMAL one.

Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/thermal/samsung/Kconfig | 14 +++---
 drivers/thermal/samsung/Makefile|  2 +-
 drivers/thermal/samsung/exynos_thermal_common.h | 12 
 3 files changed, 4 insertions(+), 24 deletions(-)

diff --git a/drivers/thermal/samsung/Kconfig b/drivers/thermal/samsung/Kconfig
index f760389..04eabee 100644
--- a/drivers/thermal/samsung/Kconfig
+++ b/drivers/thermal/samsung/Kconfig
@@ -5,14 +5,6 @@ config EXYNOS_THERMAL
  If you say yes here you get support for the TMU (Thermal Management
  Unit) driver for SAMSUNG EXYNOS series of SoCs. This driver 
initialises
  the TMU, reports temperature and handles cooling action if defined.
- This driver uses the Exynos core thermal APIs and TMU configuration
- data from the supported SoCs.
-
-config EXYNOS_THERMAL_CORE
-   bool Core thermal framework support for EXYNOS SOCs
-   depends on EXYNOS_THERMAL
-   help
- If you say yes here you get support for EXYNOS TMU
- (Thermal Management Unit) common registration/unregistration
- functions to the core thermal layer and also to use the generic
- CPU cooling APIs.
+ This driver uses the Exynos core thermal APIs, TMU configuration data
+ from the supported SoCs, common registration/unregistration functions
+ to the core thermal layer and also the generic CPU cooling APIs.
diff --git a/drivers/thermal/samsung/Makefile b/drivers/thermal/samsung/Makefile
index c09d830..a829107 100644
--- a/drivers/thermal/samsung/Makefile
+++ b/drivers/thermal/samsung/Makefile
@@ -4,4 +4,4 @@
 obj-$(CONFIG_EXYNOS_THERMAL)   += exynos_thermal.o
 exynos_thermal-y   := exynos_tmu.o
 exynos_thermal-y   += exynos_tmu_data.o
-exynos_thermal-$(CONFIG_EXYNOS_THERMAL_CORE)   += exynos_thermal_common.o
+exynos_thermal-y   += exynos_thermal_common.o
diff --git a/drivers/thermal/samsung/exynos_thermal_common.h 
b/drivers/thermal/samsung/exynos_thermal_common.h
index 3eb2ed9..8681679 100644
--- a/drivers/thermal/samsung/exynos_thermal_common.h
+++ b/drivers/thermal/samsung/exynos_thermal_common.h
@@ -88,20 +88,8 @@ struct thermal_sensor_conf {
struct device *dev;
 };
 
-/*Functions used exynos based thermal sensor driver*/
-#ifdef CONFIG_EXYNOS_THERMAL_CORE
 void exynos_unregister_thermal(struct thermal_sensor_conf *sensor_conf);
 int exynos_register_thermal(struct thermal_sensor_conf *sensor_conf);
 void exynos_report_trigger(struct thermal_sensor_conf *sensor_conf);
-#else
-static inline void
-exynos_unregister_thermal(struct thermal_sensor_conf *sensor_conf) { return; }
 
-static inline int
-exynos_register_thermal(struct thermal_sensor_conf *sensor_conf) { return 0; }
-
-static inline void
-exynos_report_trigger(struct thermal_sensor_conf *sensor_conf) { return; }
-
-#endif /* CONFIG_EXYNOS_THERMAL_CORE */
 #endif /* _EXYNOS_THERMAL_COMMON_H */
-- 
1.8.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

Re: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present

2013-10-04 Thread Sean Paul

On Fri, Oct 4, 2013 at 12:18 AM, Inki Dae inki@samsung.com wrote:
 2013/10/4 Sean Paul seanp...@chromium.org:
 On Thu, Oct 3, 2013 at 10:29 PM, Inki Dae inki@samsung.com wrote:
 2013/10/4 Sean Paul seanp...@chromium.org:
 This patch adds code to look for the ptn3460 in the device tree file on
 exynos initialization. If ptn node is found, the driver will initialize
 the ptn3460 driver and skip creating a DP connector (since the bridge
 driver will register its own connector).

 Signed-off-by: Sean Paul seanp...@chromium.org
 ---

 v2:
 - Changed include from of_i2c.h to i2c.h
 - Changed of_find_by_name to of_find_compatible

  drivers/gpu/drm/exynos/exynos_drm_core.c | 44 
 +++-
  1 file changed, 43 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c 
 b/drivers/gpu/drm/exynos/exynos_drm_core.c
 index 1bef6dc..08ca4f9 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_core.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
 @@ -12,7 +12,9 @@
   * option) any later version.
   */

 +#include linux/i2c.h
  #include drm/drmP.h
 +#include drm/bridge/ptn3460.h
  #include exynos_drm_drv.h
  #include exynos_drm_encoder.h
  #include exynos_drm_connector.h
 @@ -20,6 +22,40 @@

  static LIST_HEAD(exynos_drm_subdrv_list);

 +struct bridge_init {
 +   struct i2c_client *client;
 +   struct device_node *node;
 +};
 +
 +static bool find_bridge(const char *compat, struct bridge_init *bridge)
 +{
 +   bridge-client = NULL;
 +   bridge-node = of_find_compatible_node(NULL, NULL, compat);

 Then, shouldn't the lvds-bridge driver be implemented as i2c driver so
 that such tricky isn't needed? Is there any reason you use such tricky
 codes?


 This is what I was explaining earlier today. If the bridge driver is
 just an i2c driver, it won't get a pointer to drm_device, and can't
 register itself as a drm_bridge or drm_connector. To solve this, you
 need the ptn3460_init callback.


 No, I think you can use sub driver. how about registering to exynos
 drm core that driver using exynos_drm_subdrv_register function after
 probed? Is there something I am missing?


The ptn driver isn't exynos-specific, so I don't think making it an
exynos_drm_subdrv is appropriate.

Sean


 If it's an i2c driver with the ptn3460_init callback, where it parses
 the dt in probe, then you have a race between the ptn probe and the
 ptn init/drm hooks. ie: it's possible drm will initialize and call
 disable/post_disable/pre_enable/enable before things have been probed.

 And also, exynos drm core will call a probe callback of the sub driver
 after _drm is initialized_. Is there something I am missing?

 To solve this, you need to use some global state and/or locking.

 So, to summarize. We can have this of_find_compatible with a init
 callback, or we can have an i2c driver + global state/locking + init
 callback. I chose the former, since it seemed easier.

 If you have a better way to achieve this, I'm definitely interested,
 but I saw this as the lesser of two evils.

 Sean

 I think you need to implement the lvds-bridge driver as i2c driver,
 and then consider how to take care of this. I mean let's find a better
 way how we could take care of the i2c based driver in exynos drm
 framework or driver. In all cases, such tricky codes are not good.

 +   if (!bridge-node)
 +   return false;
 +
 +   bridge-client = of_find_i2c_device_by_node(bridge-node);
 +   if (!bridge-client)
 +   return false;
 +
 +   return true;
 +}
 +
 +/* returns the number of bridges attached */
 +static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
 +   struct drm_encoder *encoder)
 +{
 +   struct bridge_init bridge;
 +   int ret;
 +
 +   if (find_bridge(nxp,ptn3460, bridge)) {
 +   ret = ptn3460_init(dev, encoder, bridge.client, 
 bridge.node);
 +   if (!ret)
 +   return 1;
 +   }
 +   return 0;
 +}
 +
  static int exynos_drm_create_enc_conn(struct drm_device *dev,
 struct exynos_drm_subdrv *subdrv)
  {
 @@ -36,6 +72,13 @@ static int exynos_drm_create_enc_conn(struct drm_device 
 *dev,
 DRM_ERROR(failed to create encoder\n);
 return -EFAULT;
 }
 +   subdrv-encoder = encoder;
 +
 +   if (subdrv-manager-display_ops-type == EXYNOS_DISPLAY_TYPE_LCD) 
 {
 +   ret = exynos_drm_attach_lcd_bridge(dev, encoder);
 +   if (ret)
 +   return 0;
 +   }

 /*
  * create and initialize a connector for this sub driver and
 @@ -48,7 +91,6 @@ static int exynos_drm_create_enc_conn(struct drm_device 
 *dev,
 goto err_destroy_encoder;
 }

 -   subdrv-encoder = encoder;
 subdrv-connector = connector;

 return 0;
 --
 1.8.4

 --
 To unsubscribe from this list: send the line unsubscribe

RE: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present

2013-10-04 Thread Inki Dae

 -Original Message-
 From: Sean Paul [mailto:seanp...@chromium.org]
 Sent: Friday, October 04, 2013 11:17 PM
 To: Inki Dae
 Cc: Kukjin Kim; DRI mailing list; linux-samsung-soc@vger.kernel.org;
 linux-arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org; linux-
 d...@vger.kernel.org; devicet...@vger.kernel.org; Dave Airlie
 Subject: Re: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present

 On Fri, Oct 4, 2013 at 12:18 AM, Inki Dae inki@samsung.com wrote:
  2013/10/4 Sean Paul seanp...@chromium.org:
  On Thu, Oct 3, 2013 at 10:29 PM, Inki Dae inki@samsung.com wrote:
  2013/10/4 Sean Paul seanp...@chromium.org:
  This patch adds code to look for the ptn3460 in the device tree file
 on
  exynos initialization. If ptn node is found, the driver will
 initialize
  the ptn3460 driver and skip creating a DP connector (since the bridge
  driver will register its own connector).

  Signed-off-by: Sean Paul seanp...@chromium.org
  ---

  v2:
  - Changed include from of_i2c.h to i2c.h
  - Changed of_find_by_name to of_find_compatible

   drivers/gpu/drm/exynos/exynos_drm_core.c | 44
 +++-
   1 file changed, 43 insertions(+), 1 deletion(-)

  diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
 b/drivers/gpu/drm/exynos/exynos_drm_core.c
  index 1bef6dc..08ca4f9 100644
  --- a/drivers/gpu/drm/exynos/exynos_drm_core.c
  +++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
  @@ -12,7 +12,9 @@
* option) any later version.
*/

  +#include linux/i2c.h
   #include drm/drmP.h
  +#include drm/bridge/ptn3460.h
   #include exynos_drm_drv.h
   #include exynos_drm_encoder.h
   #include exynos_drm_connector.h
  @@ -20,6 +22,40 @@

   static LIST_HEAD(exynos_drm_subdrv_list);

  +struct bridge_init {
  +   struct i2c_client *client;
  +   struct device_node *node;
  +};
  +
  +static bool find_bridge(const char *compat, struct bridge_init
 *bridge)
  +{
  +   bridge-client = NULL;
  +   bridge-node = of_find_compatible_node(NULL, NULL, compat);

  Then, shouldn't the lvds-bridge driver be implemented as i2c driver so
  that such tricky isn't needed? Is there any reason you use such tricky
  codes?

  This is what I was explaining earlier today. If the bridge driver is
  just an i2c driver, it won't get a pointer to drm_device, and can't
  register itself as a drm_bridge or drm_connector. To solve this, you
  need the ptn3460_init callback.

  No, I think you can use sub driver. how about registering to exynos
  drm core that driver using exynos_drm_subdrv_register function after
  probed? Is there something I am missing?

 The ptn driver isn't exynos-specific, so I don't think making it an
 exynos_drm_subdrv is appropriate.

I _really know_ that the ptn driver isn't exynos-specific. I mean that you
can use exynos_drm_subdrv somehow. ie. you can add a new bridge module
specific to exynos, and this module can register its own sub driver at end
of probe. Why do you try to use such tricky codes?

Thanks,
Inki Dae

 Sean

  If it's an i2c driver with the ptn3460_init callback, where it parses
  the dt in probe, then you have a race between the ptn probe and the
  ptn init/drm hooks. ie: it's possible drm will initialize and call
  disable/post_disable/pre_enable/enable before things have been probed.

  And also, exynos drm core will call a probe callback of the sub driver
  after _drm is initialized_. Is there something I am missing?

  To solve this, you need to use some global state and/or locking.

  So, to summarize. We can have this of_find_compatible with a init
  callback, or we can have an i2c driver + global state/locking + init
  callback. I chose the former, since it seemed easier.

  If you have a better way to achieve this, I'm definitely interested,
  but I saw this as the lesser of two evils.

  Sean

  I think you need to implement the lvds-bridge driver as i2c driver,
  and then consider how to take care of this. I mean let's find a better
  way how we could take care of the i2c based driver in exynos drm
  framework or driver. In all cases, such tricky codes are not good.

  +   if (!bridge-node)
  +   return false;
  +
  +   bridge-client = of_find_i2c_device_by_node(bridge-node);
  +   if (!bridge-client)
  +   return false;
  +
  +   return true;
  +}
  +
  +/* returns the number of bridges attached */
  +static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
  +   struct drm_encoder *encoder)
  +{
  +   struct bridge_init bridge;
  +   int ret;
  +
  +   if (find_bridge(nxp,ptn3460, bridge)) {
  +   ret = ptn3460_init(dev, encoder, bridge.client,
 bridge.node);
  +   if (!ret)
  +   return 1;
  +   }
  +   return 0;
  +}
  +
   static int exynos_drm_create_enc_conn(struct drm_device *dev,
  struct exynos_drm_subdrv
*subdrv)
   {

Re: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present

2013-10-04 Thread Sean Paul

On Fri, Oct 4, 2013 at 11:01 AM, Inki Dae inki@samsung.com wrote:

 -Original Message-
 From: Sean Paul [mailto:seanp...@chromium.org]
 Sent: Friday, October 04, 2013 11:17 PM
 To: Inki Dae
 Cc: Kukjin Kim; DRI mailing list; linux-samsung-soc@vger.kernel.org;
 linux-arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org; linux-
 d...@vger.kernel.org; devicet...@vger.kernel.org; Dave Airlie
 Subject: Re: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present

 On Fri, Oct 4, 2013 at 12:18 AM, Inki Dae inki@samsung.com wrote:
  2013/10/4 Sean Paul seanp...@chromium.org:
  On Thu, Oct 3, 2013 at 10:29 PM, Inki Dae inki@samsung.com wrote:
  2013/10/4 Sean Paul seanp...@chromium.org:
  This patch adds code to look for the ptn3460 in the device tree file
 on
  exynos initialization. If ptn node is found, the driver will
 initialize
  the ptn3460 driver and skip creating a DP connector (since the bridge
  driver will register its own connector).

  Signed-off-by: Sean Paul seanp...@chromium.org
  ---

  v2:
  - Changed include from of_i2c.h to i2c.h
  - Changed of_find_by_name to of_find_compatible

   drivers/gpu/drm/exynos/exynos_drm_core.c | 44
 +++-
   1 file changed, 43 insertions(+), 1 deletion(-)

  diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
 b/drivers/gpu/drm/exynos/exynos_drm_core.c
  index 1bef6dc..08ca4f9 100644
  --- a/drivers/gpu/drm/exynos/exynos_drm_core.c
  +++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
  @@ -12,7 +12,9 @@
* option) any later version.
*/

  +#include linux/i2c.h
   #include drm/drmP.h
  +#include drm/bridge/ptn3460.h
   #include exynos_drm_drv.h
   #include exynos_drm_encoder.h
   #include exynos_drm_connector.h
  @@ -20,6 +22,40 @@

   static LIST_HEAD(exynos_drm_subdrv_list);

  +struct bridge_init {
  +   struct i2c_client *client;
  +   struct device_node *node;
  +};
  +
  +static bool find_bridge(const char *compat, struct bridge_init
 *bridge)
  +{
  +   bridge-client = NULL;
  +   bridge-node = of_find_compatible_node(NULL, NULL, compat);

  Then, shouldn't the lvds-bridge driver be implemented as i2c driver so
  that such tricky isn't needed? Is there any reason you use such tricky
  codes?

  This is what I was explaining earlier today. If the bridge driver is
  just an i2c driver, it won't get a pointer to drm_device, and can't
  register itself as a drm_bridge or drm_connector. To solve this, you
  need the ptn3460_init callback.

  No, I think you can use sub driver. how about registering to exynos
  drm core that driver using exynos_drm_subdrv_register function after
  probed? Is there something I am missing?

 The ptn driver isn't exynos-specific, so I don't think making it an
 exynos_drm_subdrv is appropriate.

 I _really know_ that the ptn driver isn't exynos-specific. I mean that you
 can use exynos_drm_subdrv somehow. ie. you can add a new bridge module
 specific to exynos, and this module can register its own sub driver at end
 of probe. Why do you try to use such tricky codes?

So I create a new exynos_lvds_driver which is an i2c driver. When that
probes, all it does is register that driver as an exynos_drm_subdrv.
Then in the subdrv probe I call into ptn3460_init?

That seems a lot more tricky than just calling ptn3460_init directly...

Sean

 Thanks,
 Inki Dae

 Sean

  If it's an i2c driver with the ptn3460_init callback, where it parses
  the dt in probe, then you have a race between the ptn probe and the
  ptn init/drm hooks. ie: it's possible drm will initialize and call
  disable/post_disable/pre_enable/enable before things have been probed.

  And also, exynos drm core will call a probe callback of the sub driver
  after _drm is initialized_. Is there something I am missing?

  To solve this, you need to use some global state and/or locking.

  So, to summarize. We can have this of_find_compatible with a init
  callback, or we can have an i2c driver + global state/locking + init
  callback. I chose the former, since it seemed easier.

  If you have a better way to achieve this, I'm definitely interested,
  but I saw this as the lesser of two evils.

  Sean

  I think you need to implement the lvds-bridge driver as i2c driver,
  and then consider how to take care of this. I mean let's find a better
  way how we could take care of the i2c based driver in exynos drm
  framework or driver. In all cases, such tricky codes are not good.

  +   if (!bridge-node)
  +   return false;
  +
  +   bridge-client = of_find_i2c_device_by_node(bridge-node);
  +   if (!bridge-client)
  +   return false;
  +
  +   return true;
  +}
  +
  +/* returns the number of bridges attached */
  +static int exynos_drm_attach_lcd_bridge(struct drm_device *dev,
  +   struct drm_encoder *encoder)
  +{
  +   struct bridge_init bridge;
  +   int ret;
  +
  +   if (find_bridge(nxp,ptn3460,

RE: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present

2013-10-04 Thread Inki Dae

 -Original Message-
 From: Sean Paul [mailto:seanp...@chromium.org]
 Sent: Saturday, October 05, 2013 12:05 AM
 To: Inki Dae
 Cc: Kukjin Kim; DRI mailing list; linux-samsung-soc; Linux ARM Kernel;
 Linux Kernel Mailing List; linux-...@vger.kernel.org;
 devicet...@vger.kernel.org; Dave Airlie
 Subject: Re: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present

 On Fri, Oct 4, 2013 at 11:01 AM, Inki Dae inki@samsung.com wrote:

  -Original Message-
  From: Sean Paul [mailto:seanp...@chromium.org]
  Sent: Friday, October 04, 2013 11:17 PM
  To: Inki Dae
  Cc: Kukjin Kim; DRI mailing list; linux-samsung-soc@vger.kernel.org;
  linux-arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org;
 linux-
  d...@vger.kernel.org; devicet...@vger.kernel.org; Dave Airlie
  Subject: Re: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present

  On Fri, Oct 4, 2013 at 12:18 AM, Inki Dae inki@samsung.com wrote:
   2013/10/4 Sean Paul seanp...@chromium.org:
   On Thu, Oct 3, 2013 at 10:29 PM, Inki Dae inki@samsung.com
 wrote:
   2013/10/4 Sean Paul seanp...@chromium.org:
   This patch adds code to look for the ptn3460 in the device tree
 file
  on
   exynos initialization. If ptn node is found, the driver will
  initialize
   the ptn3460 driver and skip creating a DP connector (since the
 bridge
   driver will register its own connector).

   Signed-off-by: Sean Paul seanp...@chromium.org
   ---

   v2:
   - Changed include from of_i2c.h to i2c.h
   - Changed of_find_by_name to of_find_compatible

drivers/gpu/drm/exynos/exynos_drm_core.c | 44
  +++-
1 file changed, 43 insertions(+), 1 deletion(-)

   diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
  b/drivers/gpu/drm/exynos/exynos_drm_core.c
   index 1bef6dc..08ca4f9 100644
   --- a/drivers/gpu/drm/exynos/exynos_drm_core.c
   +++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
   @@ -12,7 +12,9 @@
 * option) any later version.
 */

   +#include linux/i2c.h
#include drm/drmP.h
   +#include drm/bridge/ptn3460.h
#include exynos_drm_drv.h
#include exynos_drm_encoder.h
#include exynos_drm_connector.h
   @@ -20,6 +22,40 @@

static LIST_HEAD(exynos_drm_subdrv_list);

   +struct bridge_init {
   +   struct i2c_client *client;
   +   struct device_node *node;
   +};
   +
   +static bool find_bridge(const char *compat, struct bridge_init
  *bridge)
   +{
   +   bridge-client = NULL;
   +   bridge-node = of_find_compatible_node(NULL, NULL,
compat);

   Then, shouldn't the lvds-bridge driver be implemented as i2c driver
 so
   that such tricky isn't needed? Is there any reason you use such
 tricky
   codes?

   This is what I was explaining earlier today. If the bridge driver is
   just an i2c driver, it won't get a pointer to drm_device, and can't
   register itself as a drm_bridge or drm_connector. To solve this, you
   need the ptn3460_init callback.

   No, I think you can use sub driver. how about registering to exynos
   drm core that driver using exynos_drm_subdrv_register function after
   probed? Is there something I am missing?

  The ptn driver isn't exynos-specific, so I don't think making it an
  exynos_drm_subdrv is appropriate.

  I _really know_ that the ptn driver isn't exynos-specific. I mean that
 you
  can use exynos_drm_subdrv somehow. ie. you can add a new bridge module
  specific to exynos, and this module can register its own sub driver at
 end
  of probe. Why do you try to use such tricky codes?

 So I create a new exynos_lvds_driver which is an i2c driver. When that
 probes, all it does is register that driver as an exynos_drm_subdrv.
 Then in the subdrv probe I call into ptn3460_init?

 That seems a lot more tricky than just calling ptn3460_init directly...

Why more tricky? At least the dt binding will be done in device driver.

Anyway, this also is reasonable to me. It seems that we need a bit different
design for such bridge driver.

Basically, exysnos drm fimd driver has one encoder and one connector, and
these are connected each other, and this connector means lcd panel without
any display bus. So if we want to use display bus, it might need to create a
new encoder and connector for the display bus device. It seems that this way
is more reasonable to me.
ie.  if we want for image data goes from fimd to lcd panel, we can connect a
existing connector and crtc of fimd, and if fimd to display bus, we can
connect the new connector and the crtc of fimd through setcrtc or setplane.

Of course, for this we would need more works and efforts. Such tricky codes
definitely are not good.

Thanks,
Inki Dae

 Sean

  Thanks,
  Inki Dae

  Sean

   If it's an i2c driver with the ptn3460_init callback, where it
 parses
   the dt in probe, then you have a race between the ptn probe and the
   ptn init/drm hooks. ie: it's possible drm will initialize and call

Re: [PATCH 3/6] ARM: EXYNOS: add Exynos Dual Cluster Support

2013-10-04 Thread Nicolas Pitre

On Wed, 2 Oct 2013, Dave Martin wrote:

 On Tue, Oct 01, 2013 at 08:17:04PM +0400, Vyacheslav Tyrtov wrote:
  +static int exynos_power_up(unsigned int cpu, unsigned int cluster)
  +{
  + int ret;
  + local_irq_disable();
 
 Should there be a local_fiq_disable() here also?

No.  In fact this is paired with

  + arch_spin_lock(exynos_lock);

to create the equivalent of a arch_spin_lock_irq().  And the reason is:

/*
 * We can't use regular spinlocks. In the switcher case, it is possible
 * for an outbound CPU to call power_down() after its inbound counterpart
 * is already live using the same logical CPU number which trips lockdep
 * debugging.
 */

Otherwise we simply would have used spin_lock_irq().

No FIQs are supposed to ever race with this code.


Nicolas
--
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] PCI: exynos: missing clk_disable_unprepare() on error in exynos_pcie_probe()

2013-10-04 Thread Bjorn Helgaas

On Sun, Sep 29, 2013 at 10:29:11AM +0800, Wei Yongjun wrote:
 From: Wei Yongjun yongjun_...@trendmicro.com.cn
 
 Add the missing clk_disable_unprepare() before return
 from exynos_pcie_probe() in the error handling case.
 
 Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn

Applied with Jingoo's ack and Sylwester's subject line to
pci/host-exynos.  Thanks!

Bjorn

 ---
  drivers/pci/host/pci-exynos.c | 18 --
  1 file changed, 12 insertions(+), 6 deletions(-)
 
 diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
 index 94e096b..e25598a 100644
 --- a/drivers/pci/host/pci-exynos.c
 +++ b/drivers/pci/host/pci-exynos.c
 @@ -487,18 +487,24 @@ static int __init exynos_pcie_probe(struct 
 platform_device *pdev)
  
   elbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
   exynos_pcie-elbi_base = devm_ioremap_resource(pdev-dev, elbi_base);
 - if (IS_ERR(exynos_pcie-elbi_base))
 - return PTR_ERR(exynos_pcie-elbi_base);
 + if (IS_ERR(exynos_pcie-elbi_base)) {
 + ret = PTR_ERR(exynos_pcie-elbi_base);
 + goto fail_bus_clk;
 + }
  
   phy_base = platform_get_resource(pdev, IORESOURCE_MEM, 1);
   exynos_pcie-phy_base = devm_ioremap_resource(pdev-dev, phy_base);
 - if (IS_ERR(exynos_pcie-phy_base))
 - return PTR_ERR(exynos_pcie-phy_base);
 + if (IS_ERR(exynos_pcie-phy_base)) {
 + ret = PTR_ERR(exynos_pcie-phy_base);
 + goto fail_bus_clk;
 + }
  
   block_base = platform_get_resource(pdev, IORESOURCE_MEM, 2);
   exynos_pcie-block_base = devm_ioremap_resource(pdev-dev, block_base);
 - if (IS_ERR(exynos_pcie-block_base))
 - return PTR_ERR(exynos_pcie-block_base);
 + if (IS_ERR(exynos_pcie-block_base)) {
 + ret = PTR_ERR(exynos_pcie-block_base);
 + goto fail_bus_clk;
 + }
  
   ret = add_pcie_port(pp, pdev);
   if (ret  0)
 
--
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 v3 2/2] arm: dt: Exynos5420: populate cpu node enteries to 8 cpus

2013-10-04 Thread Kukjin Kim

Chander Kashyap wrote:
 
 Hi Kukgin,
 
 On 6 September 2013 00:52, Sylwester Nawrocki
 sylvester.nawro...@gmail.com wrote:
  On 09/05/2013 01:29 PM, Chander Kashyap wrote:
 
  Exynos5420 is octacore SoC from samsung.
 
 
  s/octacore/octa-core ?
  s/samsung/Samsung
 
 
  Hence populate all the cpu node enteries.
 
 
  s/cpu/CPU ?
  s/enteries/entries
 
  Signed-off-by: Chander Kashyapchander.kash...@linaro.org
 
 
  Subjects of the dts patches normally start with ARM: dts:.
 
  I guess this all could be corrected while the patch is being applied
  to the platform maitainter's tree.
 
 Shall i send a version or you will take these.
 
Please re-send :-)

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

RE: RE: [PATCH v2 00/12] clk/exynos convert clock IDs to macros

2013-10-04 Thread Kukjin Kim

Mike Turquette wrote:
 
 Quoting Kukjin Kim (2013-09-30 03:11:41)
  Mike Turquette wrote:
  
   Quoting Sylwester Nawrocki (2013-09-16 07:33:45)
On 09/12/2013 12:50 PM, Kukjin Kim wrote:
 Well...I'm not sure changing to use macro is better or not at this
   moment...
   
I think it is. ;) It's really less error prone to have symbolic
 names
   instead
of the plain numbers. The clock ids are defined in one place and it
 is
   more
clear what a clock is by looking at symbolic name. It's especially
   annoying
to use plain numbers where are are many clock in a single node, like
 10
   or
more. What are you main concerns with this ?
  
   I think having the symbolic names is a win for readability.
  
  Hmm...since Mike who is a maintainer for ccf agrees with Sylwester's
 opinion, so I agree. Actually, I had no strong objection on this but still
 I'm not sure using macro is really better because sometimes the name
 doesn't give readability really I think though.
 
  Mike, can you give me your ack on clk stuff?
 
 Yes, but I was thinking to take this change through the clk tree. The
 new branch based on -rc3 will be published tonight.
 
 Let me know if it causes problems for you for me to take it.
 
Uhm, I think dt changes can make ugly conflicts because of spread dt changing?

- 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 1/6] thermal: exynos: fix: Return from exynos_report_trigger() when therm_dev is NULL

Re: [PATCH 2/6] thermal: exynos: Provide separate TMU data for Exynos4412

Re: [PATCH 4/6] thermal: exynos: Replace SOC_ARCH_EXYNOS with SOC_ARCH_EXYNOS5250

Re: [PATCH 3/6] thermal: exynos: Provide initial setting for TMU's test MUX address at Exynos4412

Re: [PATCH 4/6] thermal: exynos: Replace SOC_ARCH_EXYNOS with SOC_ARCH_EXYNOS5250

Re: [PATCH 4/6] thermal: exynos: Replace SOC_ARCH_EXYNOS with SOC_ARCH_EXYNOS5250

[PATCH v4 0/4] Exynos5 Series SCALER Driver

[PATCH v4 4/4] [media] exynos-scaler: Add DT bindings for SCALER driver

[PATCH v4 3/4] [media] exynos-scaler: Add m2m functionality for the SCALER driver

[PATCH v4 1/4] [media] exynos-scaler: Add new driver for Exynos5 SCALER

[PATCH v4 2/4] [media] exynos-scaler: Add core functionality for the SCALER driver

[PATCH] thermal: offer Samsung thermal support only when ARCH_EXYNOS is defined

[PATCH] thermal: EXYNOS: always register TMU driver with core thermal framework

Re: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present

RE: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present

Re: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present

RE: [PATCH v2 4/5] drm/exynos: Initialize ptn3460 if present

Re: [PATCH 3/6] ARM: EXYNOS: add Exynos Dual Cluster Support

Re: [PATCH] PCI: exynos: missing clk_disable_unprepare() on error in exynos_pcie_probe()

RE: [PATCH v3 2/2] arm: dt: Exynos5420: populate cpu node enteries to 8 cpus

RE: RE: [PATCH v2 00/12] clk/exynos convert clock IDs to macros

21 matches

Site Navigation

Mail list logo

Footer information