[PATCH v3] thermal: consistently use int for temperatures

[Sascha Hauer]

The thermal code uses int, long and unsigned long for temperatures
in different places.

Using an unsigned type limits the thermal framework to positive
temperatures without need. Also several drivers currently will report
temperatures near UINT_MAX for temperatures below 0°C. This will probably
immediately shut the machine down due to overtemperature if started below
0°C.

'long' is 64bit on several architectures. This is not needed since INT_MAX °mC
is above the melting point of all known materials.

Consistently use a plain 'int' for temperatures throughout the thermal code and
the drivers. This only changes the places in the drivers where the temperature
is passed around as pointer, when drivers internally use another type this is
not changed.

Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Acked-by: Geert Uytterhoeven geert+rene...@glider.be
Reviewed-by: Jean Delvare jdelv...@suse.de
Reviewed-by: Lukasz Majewski l.majew...@samsung.com
Reviewed-by: Darren Hart dvh...@linux.intel.com
Reviewed-by: Heiko Stuebner he...@sntech.de
Reviewed-by: Peter Feuerer pe...@piie.net
Cc: Punit Agrawal punit.agra...@arm.com
Cc: Zhang Rui rui.zh...@intel.com
Cc: Eduardo Valentin edubez...@gmail.com
Cc: linux...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Jean Delvare jdelv...@suse.de
Cc: Peter Feuerer pe...@piie.net
Cc: Heiko Stuebner he...@sntech.de
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Thierry Reding thierry.red...@gmail.com
Cc: linux-a...@vger.kernel.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-o...@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: Guenter Roeck li...@roeck-us.net
Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Maxime Ripard maxime.rip...@free-electrons.com
Cc: Darren Hart dvh...@infradead.org
Cc: lm-sens...@lm-sensors.org
Signed-off-by: Zhang Rui rui.zh...@intel.com
---

changes since v2:
- Add missing conversion for charger-manager driver
changes since v1: 
- Add missing pieces for power_allocator driver

 drivers/acpi/thermal.c | 12 +-
 drivers/hwmon/lm75.c   |  2 +-
 drivers/hwmon/ntc_thermistor.c |  2 +-
 drivers/hwmon/tmp102.c |  2 +-
 drivers/input/touchscreen/sun4i-ts.c   |  8 +++
 drivers/platform/x86/acerhdf.c |  9 
 drivers/platform/x86/intel_mid_thermal.c   |  9 
 drivers/power/charger-manager.c|  2 +-
 drivers/power/power_supply_core.c  |  2 +-
 drivers/thermal/armada_thermal.c   |  2 +-
 drivers/thermal/db8500_thermal.c   |  7 +++---
 drivers/thermal/dove_thermal.c |  2 +-
 drivers/thermal/fair_share.c   |  2 +-
 drivers/thermal/gov_bang_bang.c|  5 ++--
 drivers/thermal/hisi_thermal.c |  4 ++--
 drivers/thermal/imx_thermal.c  | 27 +++---
 drivers/thermal/int340x_thermal/int3400_thermal.c  |  2 +-
 .../thermal/int340x_thermal/int340x_thermal_zone.c | 10 
 .../thermal/int340x_thermal/int340x_thermal_zone.h |  8 +++
 .../int340x_thermal/processor_thermal_device.c |  4 ++--
 drivers/thermal/intel_quark_dts_thermal.c  | 13 +--
 drivers/thermal/intel_soc_dts_iosf.c   |  8 +++
 drivers/thermal/kirkwood_thermal.c |  2 +-
 drivers/thermal/of-thermal.c   | 14 +--
 drivers/thermal/power_allocator.c  | 16 ++---
 drivers/thermal/qcom-spmi-temp-alarm.c |  2 +-
 drivers/thermal/rcar_thermal.c |  7 +++---
 drivers/thermal/rockchip_thermal.c | 10 
 drivers/thermal/samsung/exynos_tmu.c   | 23 +-
 drivers/thermal/spear_thermal.c|  2 +-
 drivers/thermal/st/st_thermal.c|  5 ++--
 drivers/thermal/step_wise.c|  4 ++--
 drivers/thermal/tegra_soctherm.c   |  4 ++--
 drivers/thermal/thermal_core.c | 26 ++---
 drivers/thermal/thermal_hwmon.c| 10 
 drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 10 
 drivers/thermal/x86_pkg_temp_thermal.c | 10 
 include/linux/thermal.h| 26 +
 include/trace/events/thermal_power_allocator.h |  6 ++---
 39 files changed, 152 insertions(+), 167 deletions(-)

diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index 6d4e44e..e66ad25 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -529,8 +529,7 @@ static void acpi_thermal_check(void *data)
 
 /* sys I/F for generic thermal sysfs support */
 
-static int thermal_get_temp(struct thermal_zone_device *thermal,
-

Re: [PATCH v2] thermal: consistently use int for temperatures

[Sascha Hauer]

On Thu, Jul 23, 2015 at 02:07:59PM +0200, Pavel Machek wrote:
 On Tue 2015-07-21 09:21:32, Sascha Hauer wrote:
  The thermal code uses int, long and unsigned long for temperatures
  in different places.
  
  Using an unsigned type limits the thermal framework to positive
  temperatures without need. Also several drivers currently will report
  temperatures near UINT_MAX for temperatures below 0°C. This will probably
  immediately shut the machine down due to overtemperature if started below
  0°C.
  
  'long' is 64bit on several architectures. This is not needed since INT_MAX 
  °mC
  is above the melting point of all known materials.
 
 Can we do something like
 
 typedef millicelsius_t int;
 
 ...to document the units?

I am not very fond of typedefs and I am not sure this adds any value. I
could change it when more people ask for it, but I just sent the new
version without this.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
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

[GIT PULL] Non-critical fixes for v4.3

[Krzysztof Kozlowski]

Dear Kukjin,

Previously you did not picked up the fix for cpufreq memory leak.
I am sending it again with respective acks from LKML. Also another
minor improvement in the set.

Best regards,
Krzysztof


The following changes since commit 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93:

  Merge tag 'ext4_for_linus_stable' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2015-07-05 16:24:54 
-0700)

are available in the git repository at:


  https://github.com/krzk/linux.git tags/samsung-fixes-non-critical-v4.3-2

for you to fetch changes up to 434213f727c12fab8657c8db3d23da4b0463365d:

  video: fbdev: s3c-fb: Constify platform_device_id (2015-07-24 15:17:32 +0900)


Improvements for Exynos boards:
1. Fix memory leak in cpufreq error path.
2. Constify platform_device_id in video/fbdev/s3c-fb.


Krzysztof Kozlowski (1):
  video: fbdev: s3c-fb: Constify platform_device_id

Shailendra Verma (1):
  cpufreq: exynos: Fix for memory leak in case SOC name does not match

 drivers/cpufreq/exynos-cpufreq.c | 6 --
 drivers/video/fbdev/s3c-fb.c | 2 +-
 2 files changed, 5 insertions(+), 3 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux-next, Exynos Octa boot fail, bisected to: drm/exynos: remove drm_iommu_attach_device_if_possible

[Inki Dae]

On 2015년 07월 22일 19:08, Inki Dae wrote:
 On 2015년 07월 22일 17:42, Joonyoung Shim wrote:
 On 07/22/2015 05:22 PM, Inki Dae wrote:
 On 2015년 07월 22일 17:12, Joonyoung Shim wrote:
 On 07/22/2015 01:55 PM, Inki Dae wrote:
 On 2015년 07월 22일 11:02, Joonyoung Shim wrote:
 On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote:
 Hi,

 Today's linux-next (next-20150721) encounters boot failures on Exynos
 Octa (Exynos5422) based boards. The boards hangs. I bisected it to:

 d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
 commit d80167b85024982c5f18d0481a5c248100360118
 Author: Joonyoung Shim jy0922.s...@samsung.com
 Date:   Thu Jul 2 21:49:39 2015 +0900

 drm/exynos: remove drm_iommu_attach_device_if_possible

 Already drm_iommu_attach_device checks whether support iommu 
 internally.
 It should clear channels always regardless iommu support. We didn't 
 know
 because we can detect the problem when iommu is enabled, so we don't
 have to use drm_iommu_attach_device_if_possible and then we can 
 remove
 drm_iommu_attach_device_if_possible and clear_channels function 
 pointer.

 Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
 Tested-by: Marek Szyprowski m.szyprow...@samsung.com
 Signed-off-by: Inki Dae inki@samsung.com

 :04 04 83379efbf4960f58d680371628ec04387935bd53
 da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers


 Config: exynos
 Boot log from Odroid XU3-Lite attached.

 Any hints or ideas?

 The point that hangs is when accesses fimd register in
 fimd_clear_channels function, so i doubt clock setting for fimd.

 It's gone something that hangs after i enable gating for ACLK_200_DISP1
 clock.

 If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it
 support. Any ideas?

 I think bootloader should have enabled ACLK_200_DISP1 clock and also
 device driver should enable all relevant clocks before the device
 accesses its own registers.

 Best way would be that the clock is enabled by common clock framework
 but it seems there is no anything that the clock framework can do it. So
 I think what we have to do is to add the clock support to device tree.

 It's not easy problem to me. Should we add which clock? I think we
 cannot control ACLK_200_DISP1 or CLKDIV2_DISP1_BLK directly by below
 hierarchy, right? Then we should control gate clocks, but we have not
 controlled any gate clocks using BTS_ prefix.

 The clock hierarchy from Exynos5422 user manual,
 ACLK_200_DISP1 -- CLKDIV2_DISP1_BLK -- HDMI LINK
HDMI PHY
MIC1
DSIM1
DPTX LINK
MDNIE1
SYSMMU_MIXER
SYSMMU_FIMD1_M0
SYSMMU_FIMD1_M1
BTS_TVM0
BTS_TVM1
BTS_FIMD1_M0
BTS_FIMD1_M1

 Other way, IMHO, fimd driver doesn't have to enable ACLK_200_DISP1 clock,
 just it should be controlled by connector drivers, e.g. dsi, dp because
 fimd only cannot operate, so dsi or dp must need (Actually i'm not sure
 about this, just i thought that Exynos5 SoCs don't have any gpios for
 dpi, so they cannot use dpi, right?).

 It needs to probe connector driver like dsi or dp earlier than fimd and
 fimd_bind function should return error if connector driver like dsi or
 dp was not probed. This is also not easy to me.

 In this case, if one of above gate clocks is enabled, the ACLK_200_DISP1
 should be enabled. So I guess the problem would be due to below line of
 clk-exynos5420.c,

 GATE(CLK_FIMD1, fimd1, aclk300_disp1, GATE_IP_DISP1, 0, 0, 0),

 Can you check it again after modifying it like below?,
 GATE(CLK_FIMD1, fimd1, aclk200_disp1, GATE_IP_DISP1, 0, 0, 0),

 No, parent clock of fimd1 gate clock is ACLK_300_DISP1.
 
 Yes, I checked just it through exynos5420 and exynos5422 document. I
 just guessed. So do you mean that aclk200_disp1 affects FIMD controller
 even though aclk200_disp1 isn't a parent clock of FIMD? If so, it's very
 strange.

Root problem was because it had tried to access FIMD registers before
crtc and connector driver binding is completed.

ACLK200_DISP1 will be enabled by connector driver - MIPI-DSI - of FIMD
like above clock hierarchy commented by Joonyoung.

So all we have to do would be,
1. to put off clearing channel and attaching iommu just after the
binding completion between crtc and connector drivers - in case of
Exynos drm driver, the binding is done before modeset operation.

Or 2. to enable FIMD relevant clock gates, BTS_FIMD1_M0/1 in FIMD driver.

In case of number 1, we would need to add a new interface which can
notify that crtc drivers enable their iommu units just after the binding
completion.

In 

Re: [GIT PULL] ARM: defconfig: Improvements for 4.3

[Krzysztof Kozlowski]

2015-07-17 15:51 GMT+09:00 Krzysztof Kozlowski k.kozlow...@samsung.com:
 Dear Kukjin,

 Few defconfig related changes.

 Description along with a tag.
 You can find them also on the lists with my reviewed-by.

 Best regards,
 Krzysztof

Any comments on this pull request?

Best regards,
Krzysztof




 The following changes since commit 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93:

   Merge tag 'ext4_for_linus_stable' of 
 git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2015-07-05 16:24:54 
 -0700)

 are available in the git repository at:


   https://github.com/krzk/linux.git tags/samsung-defconfig-4.3

 for you to fetch changes up to 5efedc7617df7add295702f21f11dd7e7a67b76e:

   ARM: multi_v7_defconfig: Enable max77802 regulator (2015-07-16 15:57:31 
 +0900)

 
 Defconfig changes around Exynos based boards:
 1. Enable sound on Odroid XU3 on exynos defconfig.
 2. Enable NTC thermistors for Chromebooks on exynos and multi_v7.
 3. Enable main PMIC regulator for Chromebooks on multi_v7.
 4. Clean up in multi_v7 - remove old (non-existing) configs.

 
 Anand Moon (1):
   ARM: exynos_defconfig: Enable CONFIG_SND_SOC_ODROIDX2 for Odroid-XU3

 Javier Martinez Canillas (4):
   ARM: multi_v7_defconfig: Remove old Samsung USB PHY configs
   ARM: multi_v7_defconfig: Enable NTC Thermistors support
   ARM: exynos_defconfig: Enable NTC Thermistors support
   ARM: multi_v7_defconfig: Enable max77802 regulator

  arch/arm/configs/exynos_defconfig   | 3 +++
  arch/arm/configs/multi_v7_defconfig | 5 +++--
  2 files changed, 6 insertions(+), 2 deletions(-)
 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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 v6 0/3] cpufreq: Use cpufreq-dt driver for Exynos3250

[Krzysztof Kozlowski]

On 24.07.2015 12:40, Kukjin Kim wrote:
 On 07/24/15 09:30, Michael Turquette wrote:
 Quoting Kukjin Kim (2015-07-07 07:43:31)
 Bartlomiej Zolnierkiewicz wrote:
 
 [...]
 
 Chanwoo Choi (3):
   clk: samsung: exynos3250: Add cpu clock configuration data and 
 instaniate cpu clock
   ARM: dts: Add CPU OPP and regulator supply property for Exynos3250
   ARM: exynos: Add exynos3250 compatible to use generic cpufreq driver

  arch/arm/boot/dts/exynos3250-monk.dts   |  4 
  arch/arm/boot/dts/exynos3250-rinato.dts |  4 
  arch/arm/boot/dts/exynos3250.dtsi   | 15 +++
  arch/arm/mach-exynos/exynos.c   |  1 +
  drivers/clk/samsung/clk-exynos3250.c| 32 
 ++--
  include/dt-bindings/clock/exynos3250.h  |  1 +
  6 files changed, 55 insertions(+), 2 deletions(-)

 Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com

 Thank you for working on this.

 +1 Thanks.

 Mike and Sylwester, if you're OK on this series, I'd like to pick up in 
 Samsung
 tree together. And if you want, I could provide topic branch for clk tree.

 Kukjin,

 A topic branch would be great.

 Sure, BTW it means you did 'ack' on this clk change? If not, please let
 em know ;-) I'll let you know once the topic branch is ready.

Dear Kukjin,

Will you handle this patchset and dependants (ARM: dts: Add CPU cooling
binding for Exynos3250-based Rinato/Monk board) for v4.3?

Best regards,
Krzysztof

--
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 08/11] MTD: m25p80: Add option to limit SPI transfer size.

[Marek Vasut]

On Thursday, July 23, 2015 at 07:03:47 PM, Michal Suchanek wrote:

Hi!

[...]

  It's probably slower to set up DMA for 2-byte commands but it might
  work nonetheless.
  
  It is, the overhead will be considerable. It might help the stability
  though. I'm really looking forward to the results!
  
  Hello,
  
  this does not quite work.
  
  My test with spidev:
  
  # ./spinor /dev/spidev1.0
  Sending 9f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  Received 00 ff c8 60 16 c8 60 16 c8 60 16 c8 60 16 c8 60
  Sending 90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  Received 00 ff ff ff ff c8 15 c8 15 c8 15 c8 15 c8 15 c8
  Sending 9f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  Received 00 ff c8 60 16 c8 60 16 c8 60 16 c8 60 16 c8 60
  
  I receive correct ID but spi-nor complains it does not know ID 00 c8 60.
  IIRC garbage should be sent only at the time command is transferred so
  only one byte of garbage should be received. Also the garbage tends to
  be the last state of the data output - all 0 or all 1.
  So it seems using DMA for all transfers including 1-byte commands
  results in (some?) received data getting an extra 00 prefix.
  
  
  I also managed to lock up the controller completely since there is
  some error passing the SPI speed somewhere :(
  
  [ 1352.977530] spidev spi1.0: setup mode 0, 8 bits/w, 8000 Hz max --
  0 [ 1352.977540] spidev spi1.0: spi mode 0
  [ 1352.977576] spidev spi1.0: setup mode 0, 8 bits/w, 8000 Hz max --
  0 [ 1352.977582] spidev spi1.0: msb first
  [ 1352.977614] spidev spi1.0: setup mode 0, 8 bits/w, 8000 Hz max --
  0 [ 1352.977620] spidev spi1.0: 0 bits per word
  [ 1352.977652] spidev spi1.0: setup mode 0, 8 bits/w, 2690588672 Hz max
  -- 0 [ 1352.977726] spi_master spi1: s3c64xx_spi_config: clk_from_cmu 1
  src_clk sclk_spi1 mode bpw 8
  [ 1352.977753] spi_master spi1: spi1.0 s3c64xx_spi_transfer_one: xfer
  bpw 8 speed -1604378624
  [ 1352.977760] spi_master spi1: s3c64xx_spi_config: clk_from_cmu 1
  src_clk sclk_spi1 mode bpw 8
  [ 1352.977781] spi_master spi1: spi1.0 s3c64xx_spi_transfer_one: using
  dma [ 1352.977797] dma-pl330 121b.pdma: setting up request on thread
  1
 
 Hmm, on a second thought it probably works as expected more or less.
 
 The nonsensical value was passed from application and there is no
 guard against that.
 
 Since I don't do PIO the controller remains locked up indefinitely.

I have to admit, I don't quite understand the above. I also don't quite know
what your spidev test does. Can you possibly just bind a regular SPI NOR driver 
and run mtdtests to see if it is stable ?
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] Non-critical fixes for v4.3

[Bartlomiej Zolnierkiewicz]

Hi,

On Friday, July 24, 2015 03:34:55 PM Krzysztof Kozlowski wrote:
 Dear Kukjin,
 
 Previously you did not picked up the fix for cpufreq memory leak.
 I am sending it again with respective acks from LKML. Also another
 minor improvement in the set.
 
 Best regards,
 Krzysztof
 
 
 The following changes since commit 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93:
 
   Merge tag 'ext4_for_linus_stable' of 
 git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2015-07-05 16:24:54 
 -0700)
 
 are available in the git repository at:
 
 
   https://github.com/krzk/linux.git tags/samsung-fixes-non-critical-v4.3-2
 
 for you to fetch changes up to 434213f727c12fab8657c8db3d23da4b0463365d:
 
   video: fbdev: s3c-fb: Constify platform_device_id (2015-07-24 15:17:32 
 +0900)
 
 
 Improvements for Exynos boards:
 1. Fix memory leak in cpufreq error path.
 2. Constify platform_device_id in video/fbdev/s3c-fb.
 
 
 Krzysztof Kozlowski (1):
   video: fbdev: s3c-fb: Constify platform_device_id
 
 Shailendra Verma (1):
   cpufreq: exynos: Fix for memory leak in case SOC name does not match

I would suggest merging this fix in v4.2 not v4.3:

- it is obvious and touches only error paths

- (hopefully) in v4.3 the exynos-cpufreq driver will be completely
  replaced by using cpufreq-dt for Exynos platforms (thus there will be
  no benefits of having this fix in v4.3 but there will be potential
  risk of merge conflicts due to exynos-cpufreq driver removal)

  drivers/cpufreq/exynos-cpufreq.c | 6 --
  drivers/video/fbdev/s3c-fb.c | 2 +-
  2 files changed, 5 insertions(+), 3 deletions(-)

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

--
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 08/11] MTD: m25p80: Add option to limit SPI transfer size.

[Michal Suchanek]

On 24 July 2015 at 10:34, Marek Vasut ma...@denx.de wrote:
 On Thursday, July 23, 2015 at 07:03:47 PM, Michal Suchanek wrote:

 Hi!

 [...]

  It's probably slower to set up DMA for 2-byte commands but it might
  work nonetheless.
 
  It is, the overhead will be considerable. It might help the stability
  though. I'm really looking forward to the results!
 
  Hello,
 
  this does not quite work.
 
  My test with spidev:
 
  # ./spinor /dev/spidev1.0
  Sending 9f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  Received 00 ff c8 60 16 c8 60 16 c8 60 16 c8 60 16 c8 60
  Sending 90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  Received 00 ff ff ff ff c8 15 c8 15 c8 15 c8 15 c8 15 c8
  Sending 9f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  Received 00 ff c8 60 16 c8 60 16 c8 60 16 c8 60 16 c8 60
 
  I receive correct ID but spi-nor complains it does not know ID 00 c8 60.
  IIRC garbage should be sent only at the time command is transferred so
  only one byte of garbage should be received. Also the garbage tends to
  be the last state of the data output - all 0 or all 1.
  So it seems using DMA for all transfers including 1-byte commands
  results in (some?) received data getting an extra 00 prefix.
 
 
  I also managed to lock up the controller completely since there is
  some error passing the SPI speed somewhere :(
 
  [ 1352.977530] spidev spi1.0: setup mode 0, 8 bits/w, 8000 Hz max --
  0 [ 1352.977540] spidev spi1.0: spi mode 0
  [ 1352.977576] spidev spi1.0: setup mode 0, 8 bits/w, 8000 Hz max --
  0 [ 1352.977582] spidev spi1.0: msb first
  [ 1352.977614] spidev spi1.0: setup mode 0, 8 bits/w, 8000 Hz max --
  0 [ 1352.977620] spidev spi1.0: 0 bits per word
  [ 1352.977652] spidev spi1.0: setup mode 0, 8 bits/w, 2690588672 Hz max
  -- 0 [ 1352.977726] spi_master spi1: s3c64xx_spi_config: clk_from_cmu 1
  src_clk sclk_spi1 mode bpw 8
  [ 1352.977753] spi_master spi1: spi1.0 s3c64xx_spi_transfer_one: xfer
  bpw 8 speed -1604378624
  [ 1352.977760] spi_master spi1: s3c64xx_spi_config: clk_from_cmu 1
  src_clk sclk_spi1 mode bpw 8
  [ 1352.977781] spi_master spi1: spi1.0 s3c64xx_spi_transfer_one: using
  dma [ 1352.977797] dma-pl330 121b.pdma: setting up request on thread
  1

 Hmm, on a second thought it probably works as expected more or less.

 The nonsensical value was passed from application and there is no
 guard against that.

 Since I don't do PIO the controller remains locked up indefinitely.

 I have to admit, I don't quite understand the above. I also don't quite know
 what your spidev test does.

It does a full duplex transfer sending what is printed and printing
what is received.

 Can you possibly just bind a regular SPI NOR driver
 and run mtdtests to see if it is stable ?

I can if I use PIO for short transfers. Using DMA for all transfers
results in the received data prefixed with 00 so the NOR flash
identification fails. Admittedly I have no idea what the flash memory
actually contains so if all DMA reads were always prefixed with 00 I
could not tell. I vaguely recall reading the whole content and parsing
the

I can probably make the minimum length for DMA configurable so I can
fall back to PIO when the controler locks up. It seems setting up a
PIO transfer makes it work again.

Thanks

Michal
--
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] clk: s2mps11: Use kcalloc instead of kzalloc for array allocation

[Stephen Boyd]

On 07/22, Vaibhav Hiremath wrote:
 This patch cleans up the driver for,
 
   - Use devm_kcalloc varient instead of devm_kzalloc for array
 allocation.
   - clk_prepare/unprepare, remove ret variable as it is not required
   - use __exit for cleanup function
 
 As I am referring this driver as a reference for my 88pm800 clk driver,
 applying same changes here as well.
 
 Signed-off-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
 ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 v6 0/3] cpufreq: Use cpufreq-dt driver for Exynos3250

[Michael Turquette]

Quoting Kukjin Kim (2015-07-23 21:08:27)
 On 07/24/15 12:40, Kukjin Kim wrote:
  On 07/24/15 09:30, Michael Turquette wrote:
  Quoting Kukjin Kim (2015-07-07 07:43:31)
  Bartlomiej Zolnierkiewicz wrote:
  
  [...]
  
  Chanwoo Choi (3):
clk: samsung: exynos3250: Add cpu clock configuration data and 
  instaniate cpu clock
ARM: dts: Add CPU OPP and regulator supply property for Exynos3250
ARM: exynos: Add exynos3250 compatible to use generic cpufreq driver
 
   arch/arm/boot/dts/exynos3250-monk.dts   |  4 
   arch/arm/boot/dts/exynos3250-rinato.dts |  4 
   arch/arm/boot/dts/exynos3250.dtsi   | 15 +++
   arch/arm/mach-exynos/exynos.c   |  1 +
   drivers/clk/samsung/clk-exynos3250.c| 32 
  ++--
   include/dt-bindings/clock/exynos3250.h  |  1 +
   6 files changed, 55 insertions(+), 2 deletions(-)
 
  Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
 
  Thank you for working on this.
 
  +1 Thanks.
 
  Mike and Sylwester, if you're OK on this series, I'd like to pick up in 
  Samsung
  tree together. And if you want, I could provide topic branch for clk tree.
 
  Kukjin,
 
  A topic branch would be great.
 
  Sure, BTW it means you did 'ack' on this clk change? If not, please let
  em know ;-) I'll let you know once the topic branch is ready.
  
 Mike,
 
 Done, the topic branch 'v4.3-topic/clk-samsung' in samsung tree is for
 your clk tree.

Thanks!

Mike

 
 Thanks,
 Kukjin
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
--
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] thermal: consistently use int for temperatures

[Guenter Roeck]

On 07/24/2015 03:11 PM, Pavel Machek wrote:

On Fri 2015-07-24 06:59:26, Guenter Roeck wrote:

On 07/23/2015 11:29 PM, Sascha Hauer wrote:

On Thu, Jul 23, 2015 at 02:07:59PM +0200, Pavel Machek wrote:

On Tue 2015-07-21 09:21:32, Sascha Hauer wrote:

The thermal code uses int, long and unsigned long for temperatures
in different places.

Using an unsigned type limits the thermal framework to positive
temperatures without need. Also several drivers currently will report
temperatures near UINT_MAX for temperatures below 0°C. This will probably
immediately shut the machine down due to overtemperature if started below
0°C.

'long' is 64bit on several architectures. This is not needed since INT_MAX °mC
is above the melting point of all known materials.


Can we do something like

typedef millicelsius_t int;

...to document the units?


I am not very fond of typedefs and I am not sure this adds any value. I
could change it when more people ask for it, but I just sent the new
version without this.



I thought we are supposed to not introduce new typedefs anyway.


You are not supposed to typedef struct, but typedef for millicelsius_t
would be ok. And it is your only chance if you want people to pay
attention. If you make it int, someone will pass it to long or
something else..


Seems to me that would be just lazyness. The same person might use 'long'
even if millicelsius_t is defined. A typedef doesn't preclude people
from ignoring it.

Guenter

--
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] thermal: consistently use int for temperatures

[Guenter Roeck]

On 07/23/2015 11:29 PM, Sascha Hauer wrote:

On Thu, Jul 23, 2015 at 02:07:59PM +0200, Pavel Machek wrote:

On Tue 2015-07-21 09:21:32, Sascha Hauer wrote:

The thermal code uses int, long and unsigned long for temperatures
in different places.

Using an unsigned type limits the thermal framework to positive
temperatures without need. Also several drivers currently will report
temperatures near UINT_MAX for temperatures below 0°C. This will probably
immediately shut the machine down due to overtemperature if started below
0°C.

'long' is 64bit on several architectures. This is not needed since INT_MAX °mC
is above the melting point of all known materials.


Can we do something like

typedef millicelsius_t int;

...to document the units?


I am not very fond of typedefs and I am not sure this adds any value. I
could change it when more people ask for it, but I just sent the new
version without this.



I thought we are supposed to not introduce new typedefs anyway.

Guenter


--
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] thermal: consistently use int for temperatures

[Pavel Machek]

On Fri 2015-07-24 06:59:26, Guenter Roeck wrote:
 On 07/23/2015 11:29 PM, Sascha Hauer wrote:
 On Thu, Jul 23, 2015 at 02:07:59PM +0200, Pavel Machek wrote:
 On Tue 2015-07-21 09:21:32, Sascha Hauer wrote:
 The thermal code uses int, long and unsigned long for temperatures
 in different places.
 
 Using an unsigned type limits the thermal framework to positive
 temperatures without need. Also several drivers currently will report
 temperatures near UINT_MAX for temperatures below 0°C. This will probably
 immediately shut the machine down due to overtemperature if started below
 0°C.
 
 'long' is 64bit on several architectures. This is not needed since INT_MAX 
 °mC
 is above the melting point of all known materials.
 
 Can we do something like
 
 typedef millicelsius_t int;
 
 ...to document the units?
 
 I am not very fond of typedefs and I am not sure this adds any value. I
 could change it when more people ask for it, but I just sent the new
 version without this.
 
 
 I thought we are supposed to not introduce new typedefs anyway.

You are not supposed to typedef struct, but typedef for millicelsius_t
would be ok. And it is your only chance if you want people to pay
attention. If you make it int, someone will pass it to long or
something else..
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 2/9] ARM: multi_v7_defconfig: Enable max77802 regulator, rtc and clock drivers

[Kukjin Kim]

Olof Johansson wrote:
 
 Hi,
 
Hi,

 On Fri, Jul 17, 2015 at 11:47 AM, Javier Martinez Canillas
 jav...@dowhile0.org wrote:
  Hello Olof,
 
  On Fri, Jul 17, 2015 at 6:49 PM, Olof Johansson o...@lixom.net wrote:
  On Thu, Jul 16, 2015 at 09:42:47AM +0900, Krzysztof Kozlowski wrote:
  On 16.07.2015 00:38, Javier Martinez Canillas wrote:
   Hello,
  
   On Thu, May 14, 2015 at 5:40 PM, Javier Martinez Canillas
   javier.marti...@collabora.co.uk wrote:
   The Maxim max77802 Power Management IC is used on many Exynos machines.
   Besides a bunch of regulators, this chip has a Real-Time-Clock (RTC)
   and 2-channel 32kHz clock outputs.
  
   Enable the kernel config options to have the drivers for these devices
   built as a module.
  
   Signed-off-by: Javier Martinez Canillas 
   javier.marti...@collabora.co.uk
   ---
arch/arm/configs/multi_v7_defconfig | 3 +++
1 file changed, 3 insertions(+)
  
   diff --git a/arch/arm/configs/multi_v7_defconfig 
   b/arch/arm/configs/multi_v7_defconfig
   index 2349584b6e08..080120fe5580 100644
   --- a/arch/arm/configs/multi_v7_defconfig
   +++ b/arch/arm/configs/multi_v7_defconfig
   @@ -373,6 +373,7 @@ CONFIG_POWER_RESET_SYSCON=y
CONFIG_REGULATOR_MAX8907=y
CONFIG_REGULATOR_MAX8973=y
CONFIG_REGULATOR_MAX77686=y
   +CONFIG_REGULATOR_MAX77802=m
  
   I noticed that the version that landed in 4.2-rc1 as commit
   f3caa529c6f5 (ARM: multi_v7_defconfig: Enable max77802 regulator, rtc
   and clock drivers) doesn't include this symbol. I guess it was caused
   by a wrong resolved conflict? I'll post a patch to enable the
   regulator again.
 
  As you can see in mentioned mainline commit Kukjin removed it manually:
  [kg...@kernel.org: removing useless REGULATOR_MAX77802 config]
 
  I wonder why?
 
  Seems odd. exynos_defconfig still enables it.
 
It has been removed when I did 'make savedefconfig' at that time maybe because
of dependency with other configs...

  Yeah since it is needed for at least the Exynos5420 Peach Pit and
  Exynos5800 Peach Pi Chromebooks that use this PMIC.
 
  Javier or Krzysztof, please send an incremental fix to enable and I'll pick
  it up as a fix.
 
 
  I already posted an incremental patch [0] and Krzysztof is pushing it
  through Kukjin for 4.3 [1].
 
Yes. I'll send it out to arm-soc in this weekend.

  I guess that's OK and there is no need to add it as a fix for the 4.2
  -rc cycle since this is not really a regression. I mean, the max77802
  regulator driver was never enabled for multi_v7_defconfig before.
 
 Yeah, I came across those emails a little further down. :-) It's all
 good, we'll see it come in later.
 
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

[PATCH 2/3] ARM: SAMSUNG: make local dev-backlight in mach-s3c64xx

[Kukjin Kim]

This patch moves dev-backlight from plat-samsung into mach-s3c64xx
because it is used for only s3c64xx no other platforms.

Signed-off-by: Kukjin Kim kgene@samsung.com
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
---
 arch/arm/mach-s3c64xx/Kconfig   | 6 ++
 arch/arm/mach-s3c64xx/Makefile  | 2 ++
 arch/arm/{plat-samsung = mach-s3c64xx}/dev-backlight.c | 3 +--
 arch/arm/plat-samsung/Kconfig   | 6 --
 arch/arm/plat-samsung/Makefile  | 2 --
 5 files changed, 9 insertions(+), 10 deletions(-)
 rename arch/arm/{plat-samsung = mach-s3c64xx}/dev-backlight.c (98%)

diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index eff95e9..28c7097 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -34,6 +34,12 @@ config S3C64XX_DEV_ONENAND1
help
  Compile in platform device definition for OneNAND1 controller
 
+config SAMSUNG_DEV_BACKLIGHT
+   bool
+   depends on SAMSUNG_DEV_PWM
+   help
+ Compile in platform device definition LCD backlight with PWM Timer
+
 # platform specific device setup
 
 config S3C64XX_SETUP_I2C0
diff --git a/arch/arm/mach-s3c64xx/Makefile b/arch/arm/mach-s3c64xx/Makefile
index 17f4b07..bb233f3 100644
--- a/arch/arm/mach-s3c64xx/Makefile
+++ b/arch/arm/mach-s3c64xx/Makefile
@@ -40,6 +40,8 @@ obj-$(CONFIG_S3C64XX_SETUP_SDHCI_GPIO)+= 
setup-sdhci-gpio.o
 obj-$(CONFIG_S3C64XX_SETUP_SPI)+= setup-spi.o
 obj-$(CONFIG_S3C64XX_SETUP_USB_PHY) += setup-usb-phy.o
 
+obj-$(CONFIG_SAMSUNG_DEV_BACKLIGHT)+= dev-backlight.o
+
 # Machine support
 
 obj-$(CONFIG_MACH_ANW6410) += mach-anw6410.o
diff --git a/arch/arm/plat-samsung/dev-backlight.c 
b/arch/arm/mach-s3c64xx/dev-backlight.c
similarity index 98%
rename from arch/arm/plat-samsung/dev-backlight.c
rename to arch/arm/mach-s3c64xx/dev-backlight.c
index 2157c5b..62f4648 100644
--- a/arch/arm/plat-samsung/dev-backlight.c
+++ b/arch/arm/mach-s3c64xx/dev-backlight.c
@@ -1,5 +1,4 @@
-/* linux/arch/arm/plat-samsung/dev-backlight.c
- *
+/*
  * Copyright (c) 2011 Samsung Electronics Co., Ltd.
  *  http://www.samsung.com
  *
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index f115c81..0e1874c 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -217,12 +217,6 @@ config SAMSUNG_DEV_PWM
help
  Compile in platform device definition for PWM Timer
 
-config SAMSUNG_DEV_BACKLIGHT
-   bool
-   depends on SAMSUNG_DEV_PWM
-   help
- Compile in platform device definition LCD backlight with PWM Timer
-
 config S3C24XX_PWM
bool PWM device support
select PWM
diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
index c48a2cc..624f5db 100644
--- a/arch/arm/plat-samsung/Makefile
+++ b/arch/arm/plat-samsung/Makefile
@@ -22,8 +22,6 @@ obj-$(CONFIG_SAMSUNG_ATAGS)   += devs.o
 obj-$(CONFIG_SAMSUNG_ATAGS)+= dev-uart.o
 obj-$(CONFIG_S5P_DEV_MFC)  += s5p-dev-mfc.o
 
-obj-$(CONFIG_SAMSUNG_DEV_BACKLIGHT)+= dev-backlight.o
-
 # PM support
 
 obj-$(CONFIG_PM_SLEEP) += pm-common.o
-- 
2.0.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

[[PATCH 1/3] ARM: SAMSUNG: make local setup-camif in mach-s3c24xx

[Kukjin Kim]

This patch moves setup-camif from plat-samsung into mach-s3c24xx
because it can be used only for s3c24xx no other platforms.

Signed-off-by: Kukjin Kim kgene@samsung.com
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
---
 arch/arm/mach-s3c24xx/Kconfig | 5 +
 arch/arm/mach-s3c24xx/Makefile| 1 +
 arch/arm/{plat-samsung = mach-s3c24xx}/setup-camif.c | 0
 arch/arm/plat-samsung/Kconfig | 6 --
 arch/arm/plat-samsung/Makefile| 2 --
 5 files changed, 6 insertions(+), 8 deletions(-)
 rename arch/arm/{plat-samsung = mach-s3c24xx}/setup-camif.c (100%)

diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 23bec3a..ef68ecb 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -124,6 +124,11 @@ config S3C24XX_PLL
  This also means that the PLL tables for the selected CPU(s) will
  be built which may increase the size of the kernel image.
 
+config S3C_SETUP_CAMIF
+   bool
+   help
+ Compile in common setup code for S3C CAMIF devices
+
 # cpu frequency items common between s3c2410 and s3c2440/s3c2442
 
 config S3C2410_IOTIMING
diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
index 05920c8..8ac2f58 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -99,3 +99,4 @@ obj-$(CONFIG_S3C2416_SETUP_SDHCI_GPIO)+= 
setup-sdhci-gpio.o
 obj-$(CONFIG_S3C2443_SETUP_SPI)+= setup-spi.o
 obj-$(CONFIG_ARCH_S3C24XX) += setup-i2c.o
 obj-$(CONFIG_S3C24XX_SETUP_TS) += setup-ts.o
+obj-$(CONFIG_S3C_SETUP_CAMIF)  += setup-camif.o
diff --git a/arch/arm/plat-samsung/setup-camif.c 
b/arch/arm/mach-s3c24xx/setup-camif.c
similarity index 100%
rename from arch/arm/plat-samsung/setup-camif.c
rename to arch/arm/mach-s3c24xx/setup-camif.c
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index cb8e3d6..f115c81 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -231,18 +231,12 @@ config S3C24XX_PWM
  Support for exporting the PWM timer blocks via the pwm device
  system
 
-config S3C_SETUP_CAMIF
-   bool
-   help
- Compile in common setup code for S3C CAMIF devices
-
 config SAMSUNG_PM_GPIO
bool
default y if GPIO_SAMSUNG  PM
help
  Include legacy GPIO power management code for platforms not using
  pinctrl-samsung driver.
-
 endif
 
 config S5P_DEV_MFC
diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
index 1a29ab1..c48a2cc 100644
--- a/arch/arm/plat-samsung/Makefile
+++ b/arch/arm/plat-samsung/Makefile
@@ -24,8 +24,6 @@ obj-$(CONFIG_S5P_DEV_MFC) += s5p-dev-mfc.o
 
 obj-$(CONFIG_SAMSUNG_DEV_BACKLIGHT)+= dev-backlight.o
 
-obj-$(CONFIG_S3C_SETUP_CAMIF)  += setup-camif.o
-
 # PM support
 
 obj-$(CONFIG_PM_SLEEP) += pm-common.o
-- 
2.0.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

[PATCH 3/3] ARM: SAMSUNG: make local s5p-dev-mfc in mach-exynos

[Kukjin Kim]

This patch moves s5p-dev-mfc from plat-samsung into mach-exynos
because it is used for only exynos no other platforms.

Signed-off-by: Kukjin Kim kgene@samsung.com
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
---
 arch/arm/mach-exynos/Kconfig | 5 +
 arch/arm/mach-exynos/Makefile| 2 ++
 arch/arm/{plat-samsung = mach-exynos}/s5p-dev-mfc.c | 0
 arch/arm/plat-samsung/Kconfig| 5 -
 arch/arm/plat-samsung/Makefile   | 1 -
 5 files changed, 7 insertions(+), 6 deletions(-)
 rename arch/arm/{plat-samsung = mach-exynos}/s5p-dev-mfc.c (100%)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 81064cd..4c4858c 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -30,6 +30,11 @@ menuconfig ARCH_EXYNOS
 
 if ARCH_EXYNOS
 
+config S5P_DEV_MFC
+   bool
+   help
+ Compile in setup memory (init) code for MFC
+
 config ARCH_EXYNOS3
bool SAMSUNG EXYNOS3
select ARM_CPU_SUSPEND if PM
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index bcefb54..2f30676 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -23,3 +23,5 @@ AFLAGS_sleep.o
:=-Wa,-march=armv7-a$(plus_sec)
 
 obj-$(CONFIG_EXYNOS5420_MCPM)  += mcpm-exynos.o
 CFLAGS_mcpm-exynos.o   += -march=armv7-a
+
+obj-$(CONFIG_S5P_DEV_MFC)  += s5p-dev-mfc.o
diff --git a/arch/arm/plat-samsung/s5p-dev-mfc.c 
b/arch/arm/mach-exynos/s5p-dev-mfc.c
similarity index 100%
rename from arch/arm/plat-samsung/s5p-dev-mfc.c
rename to arch/arm/mach-exynos/s5p-dev-mfc.c
diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig
index 0e1874c..57729b9 100644
--- a/arch/arm/plat-samsung/Kconfig
+++ b/arch/arm/plat-samsung/Kconfig
@@ -233,11 +233,6 @@ config SAMSUNG_PM_GPIO
  pinctrl-samsung driver.
 endif
 
-config S5P_DEV_MFC
-   bool
-   help
- Compile in setup memory (init) code for MFC
-
 comment Power management
 
 config SAMSUNG_PM_DEBUG
diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile
index 624f5db..8c91176 100644
--- a/arch/arm/plat-samsung/Makefile
+++ b/arch/arm/plat-samsung/Makefile
@@ -20,7 +20,6 @@ obj-$(CONFIG_SAMSUNG_ATAGS)   += platformdata.o
 
 obj-$(CONFIG_SAMSUNG_ATAGS)+= devs.o
 obj-$(CONFIG_SAMSUNG_ATAGS)+= dev-uart.o
-obj-$(CONFIG_S5P_DEV_MFC)  += s5p-dev-mfc.o
 
 # PM support
 
-- 
2.0.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: [GIT PULL] Non-critical fixes for v4.3

[Kukjin Kim]

Krzysztof Kozlowski wrote:
 
 2015-07-24 20:04 GMT+09:00 Bartlomiej Zolnierkiewicz 
 b.zolnier...@samsung.com:
 
  Hi,
 
  On Friday, July 24, 2015 03:34:55 PM Krzysztof Kozlowski wrote:
  Dear Kukjin,
 
  Previously you did not picked up the fix for cpufreq memory leak.
  I am sending it again with respective acks from LKML. Also another
  minor improvement in the set.
 
  Best regards,
  Krzysztof
 
 
  The following changes since commit 
  1c4c7159ed2468f3ac4ce5a7f08d79663d381a93:
 
Merge tag 'ext4_for_linus_stable' of 
  git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
 (2015-07-05 16:24:54 -0700)
 
  are available in the git repository at:
 
 
https://github.com/krzk/linux.git tags/samsung-fixes-non-critical-v4.3-2
 
  for you to fetch changes up to 434213f727c12fab8657c8db3d23da4b0463365d:
 
video: fbdev: s3c-fb: Constify platform_device_id (2015-07-24 15:17:32 
  +0900)
 
  
  Improvements for Exynos boards:
  1. Fix memory leak in cpufreq error path.
  2. Constify platform_device_id in video/fbdev/s3c-fb.
 
  
  Krzysztof Kozlowski (1):
video: fbdev: s3c-fb: Constify platform_device_id
 
  Shailendra Verma (1):
cpufreq: exynos: Fix for memory leak in case SOC name does not match
 
  I would suggest merging this fix in v4.2 not v4.3:
 
  - it is obvious and touches only error paths
 
 Indeed, good point, thanks for pointing this. Although these are not
 regressions for issues introduced in current release but they are are
 non-intrusive.
 
 Kukjin, do you agree? Can you pull them for second round of v4.2 fixes (not 
 4.3)
 
Agreed. OK.

  - (hopefully) in v4.3 the exynos-cpufreq driver will be completely
replaced by using cpufreq-dt for Exynos platforms (thus there will be
no benefits of having this fix in v4.3 but there will be potential
risk of merge conflicts due to exynos-cpufreq driver removal)
 
 
 We'll see... The Exynos 4x12 requires OPP patches. Are these ready for 4.3?
 
I think, if any conflicts based on fixes during -rc, can be handled by
maintainer.

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: [GIT PULL] ARM: defconfig: Improvements for 4.3

[Kukjin Kim]

Krzysztof Kozlowski
 
 2015-07-17 15:51 GMT+09:00 Krzysztof Kozlowski k.kozlow...@samsung.com:
  Dear Kukjin,
 
  Few defconfig related changes.
 
  Description along with a tag.
  You can find them also on the lists with my reviewed-by.
 
  Best regards,
  Krzysztof
 
 Any comments on this pull request?
 
Will pick them up, thanks.

 Best regards,
 Krzysztof
 
 
 
 
  The following changes since commit 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93:
 
Merge tag 'ext4_for_linus_stable' of 
  git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
 (2015-07-05 16:24:54 -0700)

Please don't make a branch based on some random commit, just use 'rc' as a
basis. Note that usually '-rc1' is used if there is no reason to use another
'rc' because of dependency.

- Kukjin

 
  are available in the git repository at:
 
 
https://github.com/krzk/linux.git tags/samsung-defconfig-4.3
 
  for you to fetch changes up to 5efedc7617df7add295702f21f11dd7e7a67b76e:
 
ARM: multi_v7_defconfig: Enable max77802 regulator (2015-07-16 15:57:31 
  +0900)
 
  
  Defconfig changes around Exynos based boards:
  1. Enable sound on Odroid XU3 on exynos defconfig.
  2. Enable NTC thermistors for Chromebooks on exynos and multi_v7.
  3. Enable main PMIC regulator for Chromebooks on multi_v7.
  4. Clean up in multi_v7 - remove old (non-existing) configs.
 
  
  Anand Moon (1):
ARM: exynos_defconfig: Enable CONFIG_SND_SOC_ODROIDX2 for Odroid-XU3
 
  Javier Martinez Canillas (4):
ARM: multi_v7_defconfig: Remove old Samsung USB PHY configs
ARM: multi_v7_defconfig: Enable NTC Thermistors support
ARM: exynos_defconfig: Enable NTC Thermistors support
ARM: multi_v7_defconfig: Enable max77802 regulator
 
   arch/arm/configs/exynos_defconfig   | 3 +++
   arch/arm/configs/multi_v7_defconfig | 5 +++--
   2 files changed, 6 insertions(+), 2 deletions(-)
  --

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

RE: [PATCH v6 0/3] cpufreq: Use cpufreq-dt driver for Exynos3250

[Kukjin Kim]

Krzysztof Kozlowski wrote:
 
 On 24.07.2015 12:40, Kukjin Kim wrote:
  On 07/24/15 09:30, Michael Turquette wrote:
  Quoting Kukjin Kim (2015-07-07 07:43:31)
  Bartlomiej Zolnierkiewicz wrote:
 
  [...]
 
  Chanwoo Choi (3):
clk: samsung: exynos3250: Add cpu clock configuration data and 
  instaniate cpu clock
ARM: dts: Add CPU OPP and regulator supply property for Exynos3250
ARM: exynos: Add exynos3250 compatible to use generic cpufreq driver
 
   arch/arm/boot/dts/exynos3250-monk.dts   |  4 
   arch/arm/boot/dts/exynos3250-rinato.dts |  4 
   arch/arm/boot/dts/exynos3250.dtsi   | 15 +++
   arch/arm/mach-exynos/exynos.c   |  1 +
   drivers/clk/samsung/clk-exynos3250.c| 32 
  ++--
   include/dt-bindings/clock/exynos3250.h  |  1 +
   6 files changed, 55 insertions(+), 2 deletions(-)
 
  Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
 
  Thank you for working on this.
 
  +1 Thanks.
 
  Mike and Sylwester, if you're OK on this series, I'd like to pick up in 
  Samsung
  tree together. And if you want, I could provide topic branch for clk tree.
 
  Kukjin,
 
  A topic branch would be great.
 
  Sure, BTW it means you did 'ack' on this clk change? If not, please let
  em know ;-) I'll let you know once the topic branch is ready.
 
 Dear Kukjin,
 
 Will you handle this patchset and dependants (ARM: dts: Add CPU cooling
 binding for Exynos3250-based Rinato/Monk board) for v4.3?
 
You mean Chanwoo's patch. Yes, I'll. Thanks for your gentle reminder.

- 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: [GIT PULL] Non-critical fixes for v4.3

[Krzysztof Kozlowski]

2015-07-24 20:04 GMT+09:00 Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com:

 Hi,

 On Friday, July 24, 2015 03:34:55 PM Krzysztof Kozlowski wrote:
 Dear Kukjin,

 Previously you did not picked up the fix for cpufreq memory leak.
 I am sending it again with respective acks from LKML. Also another
 minor improvement in the set.

 Best regards,
 Krzysztof


 The following changes since commit 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93:

   Merge tag 'ext4_for_linus_stable' of 
 git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2015-07-05 
 16:24:54 -0700)

 are available in the git repository at:


   https://github.com/krzk/linux.git tags/samsung-fixes-non-critical-v4.3-2

 for you to fetch changes up to 434213f727c12fab8657c8db3d23da4b0463365d:

   video: fbdev: s3c-fb: Constify platform_device_id (2015-07-24 15:17:32 
 +0900)

 
 Improvements for Exynos boards:
 1. Fix memory leak in cpufreq error path.
 2. Constify platform_device_id in video/fbdev/s3c-fb.

 
 Krzysztof Kozlowski (1):
   video: fbdev: s3c-fb: Constify platform_device_id

 Shailendra Verma (1):
   cpufreq: exynos: Fix for memory leak in case SOC name does not match

 I would suggest merging this fix in v4.2 not v4.3:

 - it is obvious and touches only error paths

Indeed, good point, thanks for pointing this. Although these are not
regressions for issues introduced in current release but they are are
non-intrusive.

Kukjin, do you agree? Can you pull them for second round of v4.2 fixes (not 4.3)


 - (hopefully) in v4.3 the exynos-cpufreq driver will be completely
   replaced by using cpufreq-dt for Exynos platforms (thus there will be
   no benefits of having this fix in v4.3 but there will be potential
   risk of merge conflicts due to exynos-cpufreq driver removal)


We'll see... The Exynos 4x12 requires OPP patches. Are these ready for 4.3?

Best regards,
Krzysztof
--
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