Re: [PATCH 2/4] usb: host: xhci-plat: Add support to get PHYs
Hi,
On Tue, Jun 10, 2014 at 1:52 AM, Julius Werner jwer...@chromium.org wrote:
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 9ffecd5..453d89e 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1582,6 +1582,9 @@ struct xhci_hcd {
u32 port_status_u0;
/* Compliance Mode Timer Triggered every 2 seconds */
#define COMP_MODE_RCVRY_MSECS 2000
+ /* phys for the controller */
+ struct phy *phy2_gen;
+ struct phy *phy3_gen;
};
I don't think adding new variables here and restricting most of this
logic to xhci-plat.c (in the next patch) is the best way to do it.
There's no conceptual reason why other host controllers (e.g. xhci-pci
or even EHCI) could not have a similar need to tune their PHY after
reset. PHYs are universal to all host controllers.
There is already a 'phy' member in struct usb_hcd which I think is
mostly unused right now. I think it would be much less
confusing/redundant to reuse that member for this purpose (you could
still set it up from xhci_plat_probe(), and then call it from
hcd_bus_resume() or something like that). Since XHCI host controllers
already conveniently have two struct usb_hcd (one for 2.0 and one for
3.0), you can cleanly store references to your two PHYs in there.
Ok, i will look into the suggested approach, and raise flag in case i
have doubts.
--
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
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] ARM: dts: Add cros_ec to exynos5420-peach-pit and exynos5800-peach-pi
On 06/24/2014 02:19 AM, Doug Anderson wrote:
This adds cros_ec to exynos5420-peach-pit and exynos5800-peach-pi,
including:
* The keyboard
* The i2c tunnel
* The tps65090 under the i2c tunnel
* The battery under the i2c tunnel
To add extra motivation, it should be noted that tps65090 is one of
the things needed to get display-related FETs turned on for pit and
pi.
Note that this relies on a few outstanding changes:
* Needs (spi: s3c64xx: fix broken cs_gpios usage in the driver) and
(spi: s3c64xx: for DT platofrms always get the chipselect info from
DT node) to work properly and match the documented bindings. See
https://patchwork.kernel.org/patch/4346701/ and
https://patchwork.kernel.org/patch/4346711/
Signed-off-by: Doug Anderson diand...@chromium.org
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Along with the dependency patches on next-20140623, tested keyboard on
Peach-Pi board.
Tested-by: Tushar Behera tusha...@samsung.com
Some comments below.
---
Changes in v2:
- Now just one patch since mfd patch landed.
- Rebased to ToT linux-next
arch/arm/boot/dts/exynos5420-peach-pit.dts | 145
+
arch/arm/boot/dts/exynos5800-peach-pi.dts | 145
+
2 files changed, 290 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 7649982..581f385 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
+ regulators {
+ dcdc1 {
+ ti,enable-ext-control;
+ };
+ dcdc2 {
+ ti,enable-ext-control;
+ };
+ dcdc3 {
+ ti,enable-ext-control;
+ };
+ fet1 {
tps65090_fet1: fet1 { ?
+ regulator-name = vcd_led;
+ };
+ tps65090_fet2: fet2 {
I would suggest we add similar labels to fet1, fet3, fet4, fet5 and fet6
also. That way it would be easy to reference them in subsequent DT nodes.
Same comment for Peach-Pi dts file too.
--
Tushar Behera
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 09/10] drm/bridge: Add ps8622/ps8625 bridge driver
Hi Javier,
Thanks for the review.
On Mon, Jun 23, 2014 at 12:05 PM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
Hello Ajay,
On Wed, Jun 11, 2014 at 8:27 PM, Ajay Kumar ajaykumar...@samsung.com wrote:
From: Vincent Palatin vpala...@chromium.org
This patch adds drm_bridge driver for parade DisplayPort
to LVDS bridge chip.
Signed-off-by: Vincent Palatin vpala...@chromium.org
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Sean Paul seanp...@chromium.org
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
.../devicetree/bindings/drm/bridge/ps8622.txt | 21 +
drivers/gpu/drm/bridge/Kconfig |8 +
drivers/gpu/drm/bridge/Makefile|1 +
drivers/gpu/drm/bridge/ps8622.c| 475
include/drm/bridge/ps8622.h| 41 ++
5 files changed, 546 insertions(+)
create mode 100644 Documentation/devicetree/bindings/drm/bridge/ps8622.txt
create mode 100644 drivers/gpu/drm/bridge/ps8622.c
create mode 100644 include/drm/bridge/ps8622.h
diff --git a/Documentation/devicetree/bindings/drm/bridge/ps8622.txt
b/Documentation/devicetree/bindings/drm/bridge/ps8622.txt
new file mode 100644
index 000..1afbd9c
--- /dev/null
+++ b/Documentation/devicetree/bindings/drm/bridge/ps8622.txt
@@ -0,0 +1,21 @@
+ps8622-bridge bindings
+
+Required properties:
+ - compatible: parade,ps8622
+ - reg: first i2c address of the bridge
+ - sleep-gpio: OF device-tree gpio specification
+ - reset-gpio: OF device-tree gpio specification
+
+Optional properties:
+ - lane-count: number of DP lanes to use
+ - use-external-pwm: backlight will be controlled by an external PWM
+
+Example:
+ ps8622-bridge@48 {
+ compatible = parade,ps8622;
+ reg = 0x48;
+ sleep-gpio = gpc3 6 1 0 0;
+ reset-gpio = gpc3 1 1 0 0;
+ display-timings = lcd_display_timings;
+ lane-count = 1
+ };
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index e3fb487..7b843c8 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -10,3 +10,11 @@ config DRM_PANEL_BINDER
select DRM_KMS_HELPER
select DRM_PANEL
---help---
+
+config DRM_PS8622
+ tristate Parade eDP/LVDS bridge
+ depends on DRM
+ select DRM_KMS_HELPER
+ select BACKLIGHT_LCD_SUPPORT
+ select BACKLIGHT_CLASS_DEVICE
+ ---help---
diff --git a/drivers/gpu/drm/bridge/Makefile
b/drivers/gpu/drm/bridge/Makefile
index ba8b5b8..b494d4b 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -2,3 +2,4 @@ ccflags-y := -Iinclude/drm
obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
obj-$(CONFIG_DRM_PANEL_BINDER) += panel_binder.o
+obj-$(CONFIG_DRM_PS8622) += ps8622.o
diff --git a/drivers/gpu/drm/bridge/ps8622.c
b/drivers/gpu/drm/bridge/ps8622.c
new file mode 100644
index 000..387d332
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -0,0 +1,475 @@
+/*
+ * Parade PS8622 eDP/LVDS bridge driver
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/backlight.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/fb.h
+#include linux/gpio.h
+#include linux/i2c.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/pm.h
+#include linux/regulator/consumer.h
+
+#include drmP.h
+#include drm_crtc.h
+#include drm_crtc_helper.h
+
+struct ps8622_bridge {
+ struct drm_bridge *bridge;
+ struct drm_encoder *encoder;
+ struct i2c_client *client;
+ struct regulator *v12;
+ struct backlight_device *bl;
+ struct mutex enable_mutex;
+
+ int gpio_slp_n;
+ int gpio_rst_n;
+
+ u8 max_lane_count;
+ u8 lane_count;
+
+ bool enabled;
+};
+
+struct ps8622_device_data {
+ u8 max_lane_count;
+};
+
+static const struct ps8622_device_data ps8622_data = {
+ .max_lane_count = 1,
+};
+
+static const struct ps8622_device_data ps8625_data = {
+ .max_lane_count = 2,
+};
+
+/* Brightness scale on the Parade chip */
+#define PS8622_MAX_BRIGHTNESS 0xff
+
+/* Timings taken from the version 1.7 datasheet for the PS8622/PS8625 */
+#define PS8622_POWER_RISE_T1_MIN_US 10
Re: [PATCH V4 04/10] drm/panel: Add driver for lvds/edp based panels
Hi Javier,
Thanks for the review.
On Mon, Jun 23, 2014 at 11:30 AM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
Hello Ajay,
Not an extensive review since I'm not familiar with the graphics stack
but a few things I noticed are commented below.
On Wed, Jun 11, 2014 at 8:27 PM, Ajay Kumar ajaykumar...@samsung.com wrote:
This patch adds a simple driver to handle all the LCD and LED
powerup/down routines needed to support eDP/LVDS panels.
The LCD and LED units are usually powered up via regulators,
and almost on all boards, we will have a BACKLIGHT_EN pin to
enable/ disable the backlight.
Sometimes, we can have LCD_EN switches as well.
The routines in this driver can be used to control
panel power sequence on such boards.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
.../devicetree/bindings/panel/panel-lvds.txt | 50
drivers/gpu/drm/panel/Kconfig | 10 +
drivers/gpu/drm/panel/Makefile |1 +
drivers/gpu/drm/panel/panel-lvds.c | 262
4 files changed, 323 insertions(+)
create mode 100644 Documentation/devicetree/bindings/panel/panel-lvds.txt
create mode 100644 drivers/gpu/drm/panel/panel-lvds.c
diff --git a/Documentation/devicetree/bindings/panel/panel-lvds.txt
b/Documentation/devicetree/bindings/panel/panel-lvds.txt
new file mode 100644
index 000..7cb6084
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/panel-lvds.txt
@@ -0,0 +1,50 @@
+panel interface for eDP/lvds panels
+
+Required properties:
+ - compatible: panel-lvds
+
+Optional properties:
+ -lcd-en-gpio:
+ panel LCD poweron GPIO.
+ Indicates which GPIO needs to be powered up as output
+ to powerup/enable the switch to the LCD panel.
+ -led-en-gpio:
+ panel LED enable GPIO.
+ Indicates which GPIO needs to be powered up as output
+ to enable the backlight.
+ -panel-prepare-delay:
+ delay value in ms required for panel_prepare process
+ Delay in ms needed for the panel LCD unit to
+ powerup completely.
+ ex: delay needed till eDP panel throws HPD.
+ delay needed so that we cans tart reading edid.
+ -panel-enable-delay:
+ delay value in ms required for panel_enable process
+ Delay in ms needed for the panel backlight/LED unit
+ to powerup, and delay needed between video_enable and
+ backlight_enable.
+ -panel-disable-delay:
+ delay value in ms required for panel_disable process
+ Delay in ms needed for the panel backlight/LED unit
+ powerdown, and delay needed between backlight_disable
+ and video_disable.
+ -panel-unprepare-delay:
+ delay value in ms required for panel_post_disable process
+ Delay in ms needed for the panel LCD unit to
+ to powerdown completely, and the minimum delay needed
+ before powering it on again.
+ -panel-width-mm: physical panel width [mm]
+ -panel-height-mm: physical panel height [mm]
+
+Example:
+
+ panel-lvds {
+ compatible = panel-lvds;
+ led-en-gpio = gpx3 0 1;
+ panel-prepare-delay = 40;
+ panel-enable-delay = 20;
+ panel-disable-delay = 20;
+ panel-unprepare-delay = 30;
+ panel-width-mm = 256;
+ panel-height-mm = 144;
+ };
Recently it's considered a good practice to have the DT binding
documentation in a separate patch.
Ok, will remember this.
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 4ec874d..8fe7ee5 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -30,4 +30,14 @@ config DRM_PANEL_S6E8AA0
select DRM_MIPI_DSI
select VIDEOMODE_HELPERS
+config DRM_PANEL_EDP_LVDS
+ tristate support for eDP/LVDS panels
+ depends on OF DRM_PANEL
+ select VIDEOMODE_HELPERS
+ help
+ DRM panel driver for direct eDP panels or LVDS connected
+ via DP bridges, that need at most a regulator for LCD unit,
+ a regulator for LED unit and/or enable GPIOs for LCD or LED units.
+ Delay values can also be specified to support powerup and
+ powerdown process.
endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 8b92921..eaafa01 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -1,3 +1,4 @@
Re: [PATCH V4 04/10] drm/panel: Add driver for lvds/edp based panels
Hi Gmeiner, On Mon, Jun 23, 2014 at 12:55 PM, Christian Gmeiner christian.gmei...@gmail.com wrote: Hi 2014-06-11 20:27 GMT+02:00 Ajay Kumar ajaykumar...@samsung.com: This patch adds a simple driver to handle all the LCD and LED powerup/down routines needed to support eDP/LVDS panels. The LCD and LED units are usually powered up via regulators, and almost on all boards, we will have a BACKLIGHT_EN pin to enable/ disable the backlight. Sometimes, we can have LCD_EN switches as well. The routines in this driver can be used to control panel power sequence on such boards. Signed-off-by: Ajay Kumar ajaykumar...@samsung.com Signed-off-by: Rahul Sharma rahul.sha...@samsung.com --- .../devicetree/bindings/panel/panel-lvds.txt | 50 drivers/gpu/drm/panel/Kconfig | 10 + drivers/gpu/drm/panel/Makefile |1 + drivers/gpu/drm/panel/panel-lvds.c | 262 4 files changed, 323 insertions(+) create mode 100644 Documentation/devicetree/bindings/panel/panel-lvds.txt create mode 100644 drivers/gpu/drm/panel/panel-lvds.c diff --git a/Documentation/devicetree/bindings/panel/panel-lvds.txt b/Documentation/devicetree/bindings/panel/panel-lvds.txt new file mode 100644 index 000..7cb6084 --- /dev/null +++ b/Documentation/devicetree/bindings/panel/panel-lvds.txt @@ -0,0 +1,50 @@ +panel interface for eDP/lvds panels + +Required properties: + - compatible: panel-lvds + +Optional properties: + -lcd-en-gpio: + panel LCD poweron GPIO. + Indicates which GPIO needs to be powered up as output + to powerup/enable the switch to the LCD panel. + -led-en-gpio: + panel LED enable GPIO. + Indicates which GPIO needs to be powered up as output + to enable the backlight. + -panel-prepare-delay: + delay value in ms required for panel_prepare process + Delay in ms needed for the panel LCD unit to + powerup completely. + ex: delay needed till eDP panel throws HPD. + delay needed so that we cans tart reading edid. + -panel-enable-delay: + delay value in ms required for panel_enable process + Delay in ms needed for the panel backlight/LED unit + to powerup, and delay needed between video_enable and + backlight_enable. + -panel-disable-delay: + delay value in ms required for panel_disable process + Delay in ms needed for the panel backlight/LED unit + powerdown, and delay needed between backlight_disable + and video_disable. + -panel-unprepare-delay: + delay value in ms required for panel_post_disable process + Delay in ms needed for the panel LCD unit to + to powerdown completely, and the minimum delay needed + before powering it on again. + -panel-width-mm: physical panel width [mm] + -panel-height-mm: physical panel height [mm] + For what are these two properties are needed? Actually, these are needed to caluculate DPI(dots/pixels per inch). That information will be used by the corresponding userspace to deliver proper size fonts. You can refer other panel drivers, even they too are using it! Regards, Ajay If I find some time I will give this patch a try as I need something like this for an imx6d based device. That would be great, Thanks. Ajay -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: exynos: activate the CCI on boot CPU/cluster with the MCPM loopback
On 06/24/2014 09:41 AM, Nicolas Pitre wrote:
The Chromebook firmware doesn't enable the CCI for the boot cpu, and
arguably it shouldn't have to either. Let's have the kernel handle the
CCI on its own for the boot CPU the same way it does it for secondary CPUs
by using the MCPM loopback.
Signed-off-by: Nicolas Pitre n...@linaro.org
---
Tested on top of next-20140623. Verified that all 8 cores are coming up
on Exynos5800 based Peach-pi board.
Tested-by: Tushar Behera tusha...@samsung.com
arch/arm/mach-exynos/mcpm-exynos.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
b/arch/arm/mach-exynos/mcpm-exynos.c
index 0498d0b887..0c839f94ec 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -290,6 +290,19 @@ static void __naked exynos_pm_power_up_setup(unsigned
int affinity_level)
b cci_enable_port_for_self);
}
+static void __init exynos_cache_off(void)
+{
+ if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A15) {
+ /* disable L2 prefetching on the Cortex-A15 */
+ asm volatile(
+ mcrp15, 1, %0, c15, c0, 3\n\t
+ isb\n\t
+ dsb
+ : : r (0x400));
+ }
+ exynos_v7_exit_coherency_flush(all);
+}
+
static const struct of_device_id exynos_dt_mcpm_match[] = {
{ .compatible = samsung,exynos5420 },
{ .compatible = samsung,exynos5800 },
@@ -333,6 +346,8 @@ static int __init exynos_mcpm_init(void)
ret = mcpm_platform_register(exynos_power_ops);
if (!ret)
ret = mcpm_sync_init(exynos_pm_power_up_setup);
+ if (!ret)
+ ret = mcpm_loopback(exynos_cache_off); /* turn on the CCI */
if (ret) {
iounmap(ns_sram_base_addr);
return ret;
--
Tushar Behera
--
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 0/2] Sound support for Exynos4412 Odroid X2, U3 board
On Mon, Jun 23, 2014 at 5:32 PM, Sylwester Nawrocki s.nawro...@samsung.com wrote: I could reproduce such behaviour on the U3 board, but only with u-boot which sets the MPLL clock frequency (fout_mpll) to 880 MHz, rather than 800 MHz, which was the case in my original environment. All fout_mpll child clocks have then different frequency values in both cases. It's a bit strange though, because frequencies of all the audio subsystem clocks seem to be same anyway: I'm using the standard uboot from hardkernel. # cat /sys/kernel/debug/clk/clk_summary This command makes the kernel totally hang, weird. # speaker-test -c 2 -t wav -l 2 -p 1024 This plays back fine. Could it be a problem with the samsung-i2s driver, not correctly flushing at the right times? Or do you think the problem is more likely to be clock-related? Thanks Daniel -- 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 0/2] Sound support for Exynos4412 Odroid X2, U3 board
Hello, On 2014-06-24 10:35, Daniel Drake wrote: On Mon, Jun 23, 2014 at 5:32 PM, Sylwester Nawrocki s.nawro...@samsung.com wrote: I could reproduce such behaviour on the U3 board, but only with u-boot which sets the MPLL clock frequency (fout_mpll) to 880 MHz, rather than 800 MHz, which was the case in my original environment. All fout_mpll child clocks have then different frequency values in both cases. It's a bit strange though, because frequencies of all the audio subsystem clocks seem to be same anyway: I'm using the standard uboot from hardkernel. # cat /sys/kernel/debug/clk/clk_summary This command makes the kernel totally hang, weird. This is known issue with clocks vs. ISP power domain. We should really fix this in exynos4 clock driver. # speaker-test -c 2 -t wav -l 2 -p 1024 This plays back fine. Could it be a problem with the samsung-i2s driver, not correctly flushing at the right times? Or do you think the problem is more likely to be clock-related? Hard to say right now, but at least we need to test a bit more our solutions with different initial clocks configuration. Best regards -- Marek Szyprowski, PhD Samsung RD Institute Poland -- 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] devicetree: Add generic IOMMU device tree bindings
On Sat, Jun 21, 2014 at 12:16:25AM +0100, Olav Haugan wrote:
On 5/30/2014 12:06 PM, Arnd Bergmann wrote:
On Friday 30 May 2014 08:16:05 Rob Herring wrote:
Presumably the ID would be the streamID on ARM's SMMU. How would a
master with 8 streamIDs be described? This is what Calxeda midway has
for SATA and I would expect that to be somewhat common. Either you
need some ID masking or you'll have lots of duplication when you have
windows.
I don't understand the problem. If you have stream IDs 0 through 7,
you would have
master@a {
...
iommus = smmu 0;
};
master@b {
...
iommus = smmu 1;
};
...
master@12 {
...
iommus = smmu 7;
};
and you don't need a window at all. Why would you need a mask of
some sort?
We have multiple-master SMMUs and each master emits a variable number of
StreamIDs. However, we have to apply a mask (the ARM SMMU spec allows
for this) to the StreamIDs due to limited number of StreamID 2 Context
Bank entries in the SMMU. If my understanding is correct we would
represent this in the DT like this:
iommu {
#address-cells = 2;
#size-cells = 0;
};
master@a {
...
iommus = iommu StreamID0 MASK0,
iommu StreamID1 MASK1,
iommu StreamID2 MASK2;
};
Stupid question, but why not simply describe the masked IDs? What use does
the `raw' ID have to Linux?
Will
--
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
sdhci_s3c_consider_clock scheduling while atomic - clk_round_rate
sdhci_s3c_set_clock is called from sdhci_do_set_ios with interrupts disabled, and this calls into sdhci_s3c_consider_clock(). The patch mmc: sdhci-s3c: Cache bus clock rates addressed some scheduling while atomic in this function, but there are more issues here, seen while testing 3.16-rc2 on exynos4412: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:103 in_atomic(): 1, irqs_disabled(): 128, pid: 75, name: mmcqd/0 Preemption disabled at:[ (null)] (null) CPU: 0 PID: 75 Comm: mmcqd/0 Not tainted 3.16.0-rc2-00028-ge9fe7eb-dirty #77 [c0016140] (unwind_backtrace) from [c0011e14] (show_stack+0x10/0x14) [c0011e14] (show_stack) from [c05ce8a8] (dump_stack+0x84/0xc4) [c05ce8a8] (dump_stack) from [c05d2de0] (mutex_lock+0x1c/0x3c) [c05d2de0] (mutex_lock) from [c046214c] (clk_prepare_lock+0x6c/0xf4) [c046214c] (clk_prepare_lock) from [c04625ac] (clk_round_rate+0x10/0x2c) [c04625ac] (clk_round_rate) from [c0447628] (sdhci_s3c_set_clock+0x4c/0x1e8) [c0447628] (sdhci_s3c_set_clock) from [c0447818] (sdhci_cmu_set_clock+0x54/0x140) [c0447818] (sdhci_cmu_set_clock) from [c0443a38] (sdhci_do_set_ios+0x138/0x58c) [c0443a38] (sdhci_do_set_ios) from [c0443864] (sdhci_set_ios+0x28/0x34) clk_round_rate cannot be called here because it takes a mutex. sdhci_s3c_set_clock() also calls into clk_prepare_enable() which looks like it could trigger this problem too. Daniel -- 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: [RFC 4/4] ARM: dts: exynos5250: Add Spring device tree
Hello Doug,
On 06/24/2014 06:05 AM, Doug Anderson wrote:
Andreas,
On Mon, Jun 23, 2014 at 3:46 PM, Andreas Färber afaer...@suse.de wrote:
Hi Doug,
Am 23.06.2014 21:47, schrieb Doug Anderson:
Thanks for posting! A first pass on this is below...
Thanks a lot for your quick review! My first big .dts patch, and no
datasheets for the hardware at hand as a user.
A first pass of replies to my defense. ;)
On Sun, Jun 22, 2014 at 6:21 PM, Andreas Färber afaer...@suse.de wrote:
[...]
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
new file mode 100644
index 000..e857d44
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -0,0 +1,556 @@
+/*
+ * Google Spring board device tree source
+ *
+ * Copyright (c) 2013 Google, Inc
+ * Copyright (c) 2014 SUSE LINUX Products GmbH
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include exynos5250.dtsi
+#include exynos5250-cros-common.dtsi
It is possible we may want to backpedal on the use of
exynos5250-cros-common.dtsi. I know that Olof (now CCed) said he
wasn't a fan of how it turned out.
The original idea was that it should include the arbitrary set of
things that are common between a chunk of Chrome OS boards. As more
boards were introduced things would need to migrate from the common
file to the board files.
At the moment the current conventional wisdom is that some duplication
is better than the confusing movement of everything back and forth.
See exynos5420-peach-pit and exynos5800-peach-pi in ToT linux-next.
Another option is to identify DTS fragments that are common across boards and
create .dtsi files for these specific chunks instead of trying to group all set
of common things on a single .dtsi file.
For example, a quite common design for OMAP2+ based boards is to use a SMSC LAN
chip connected to OMAP's General-Purpose Memory Controller (GPMC). So the
following files were created to reduce DTS duplication:
arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi
arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi
Now that I think about it, is the same that what you did for
arm/boot/dts/cros-ec-keyboard.dtsi.
Maybe splitting exynos5250-cros-common.dtsi in a set of .dtsi files will make it
more flexible/reusable?
+/ {
+ model = Google Spring;
+ compatible = google,spring, samsung,exynos5250,
samsung,exynos5;
+
+ pinctrl@1140 {
The new best way to do things is to put this down at the bottom. See
exynos5420-peach-pit as an example:
pinctrl_0 {
...
}
Note that I believe it was decided that top-level references like that
should be sorted alphabetically.
Thanks for the hint. (My chosen sort order here was by address.)
If you wanted to apply that run to exynos5250-snow I don't think it
would be a terrible idea.
I can of course apply changes to Snow, but I cannot test them myself.
If you want to send up a patch like that I'm happy to give it a once
over and also to test it. ...but don't feel obligated
+ s5m8767_dvs: s5m8767-dvs {
+ samsung,pins = gpd1-0, gpd1-1, gpd1-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+
+ s5m8767_ds: s5m8767-ds {
+ samsung,pins = gpx2-3, gpx2-4, gpx2-5;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+
+ tps65090_irq: tps65090-irq {
+ samsung,pins = gpx2-6;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ s5m8767_irq: s5m8767-irq {
+ samsung,pins = gpx3-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ hdmi_hpd_irq: hdmi-hpd-irq {
+ samsung,pins = gpx3-7;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+ };
+
+ pinctrl@1340 {
+ hsic_reset: hsic-reset {
+ samsung,pins = gpe1-0;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
I'm pretty sure that the HSIC reset needed some funky code to make it
work and I'm not sure what the status of that is upstream
Yeah, you mentioned something along those
Re: [PATCH v2 02/10] mfd: cros_ec: Allow static din/dout buffers with cros_ec_register()
On Wed, 18 Jun 2014, Doug Anderson wrote:
From: Bill Richardson wfric...@chromium.org
The lower-level driver may want to provide its own buffers. If so,
there's no need to allocate new ones. This already happens to work
just fine (since we check for size of 0 and use devm allocation), but
it's good to document it.
[dianders: Resolved conflicts; documented that no code changes needed
on mainline]
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
Reviewed-by: Simon Glass s...@chromium.org
---
Changes in v2: None
include/linux/mfd/cros_ec.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Lee Jones lee.jo...@linaro.org
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index 7e9fe6e..2ee3190 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -68,8 +68,8 @@ struct cros_ec_msg {
* We use this alignment to keep ARM and x86 happy. Probably word
* alignment would be OK, there might be a small performance advantage
* to using dword.
- * @din_size: size of din buffer
- * @dout_size: size of dout buffer
+ * @din_size: size of din buffer to allocate (zero to use static din)
+ * @dout_size: size of dout buffer to allocate (zero to use static dout)
* @command_send: send a command
* @command_recv: receive a command
* @ec_name: name of EC device (e.g. 'chromeos-ec')
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 08/10] mfd: cros_ec: Check result code from EC messages
On Wed, 18 Jun 2014, Doug Anderson wrote:
From: Bill Richardson wfric...@chromium.org
Just because the host was able to talk to the EC doesn't mean that the EC
was happy with what it was told. Errors in communincation are not the same
as error messages from the EC itself.
This change lets the EC report its errors separately.
[dianders: Added common function to cros_ec.c]
Signed-off-by: Bill Richardson wfric...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v2:
- Added common function to cros_ec.c
- Changed to dev_dbg() as per http://crosreview.com/66726
drivers/mfd/cros_ec.c | 18 ++
drivers/mfd/cros_ec_i2c.c | 8 +++-
drivers/mfd/cros_ec_spi.c | 19 ++-
include/linux/mfd/cros_ec.h | 12
4 files changed, 39 insertions(+), 18 deletions(-)
Acked-by: Lee Jones lee.jo...@linaro.org
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 4851ed2..83e30c6 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -44,6 +44,24 @@ int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
}
EXPORT_SYMBOL(cros_ec_prepare_tx);
+int cros_ec_check_result(struct cros_ec_device *ec_dev,
+ struct cros_ec_command *msg)
+{
+ switch (msg-result) {
+ case EC_RES_SUCCESS:
+ return 0;
+ case EC_RES_IN_PROGRESS:
+ dev_dbg(ec_dev-dev, command 0x%02x in progress\n,
+ msg-command);
+ return -EAGAIN;
+ default:
+ dev_dbg(ec_dev-dev, command 0x%02x returned %d\n,
+ msg-command, msg-result);
+ return 0;
+ }
+}
+EXPORT_SYMBOL(cros_ec_check_result);
+
static irqreturn_t ec_irq_thread(int irq, void *data)
{
struct cros_ec_device *ec_dev = data;
diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
index 5bb32f5..189e7d1 100644
--- a/drivers/mfd/cros_ec_i2c.c
+++ b/drivers/mfd/cros_ec_i2c.c
@@ -92,12 +92,10 @@ static int cros_ec_cmd_xfer_i2c(struct cros_ec_device
*ec_dev,
}
/* check response error code */
- if (i2c_msg[1].buf[0]) {
- dev_warn(ec_dev-dev, command 0x%02x returned an error %d\n,
- msg-command, i2c_msg[1].buf[0]);
- ret = -EINVAL;
+ msg-result = i2c_msg[1].buf[0];
+ ret = cros_ec_check_result(ec_dev, msg);
+ if (ret)
goto done;
- }
/* copy response packet payload and compute checksum */
sum = in_buf[0] + in_buf[1];
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index 09ca789..c975087 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -289,21 +289,14 @@ static int cros_ec_cmd_xfer_spi(struct cros_ec_device
*ec_dev,
goto exit;
}
- /* check response error code */
ptr = ec_dev-din;
- if (ptr[0]) {
- if (ptr[0] == EC_RES_IN_PROGRESS) {
- dev_dbg(ec_dev-dev, command 0x%02x in progress\n,
- ec_msg-command);
- ret = -EAGAIN;
- goto exit;
- }
- dev_warn(ec_dev-dev, command 0x%02x returned an error %d\n,
- ec_msg-command, ptr[0]);
- debug_packet(ec_dev-dev, in_err, ptr, len);
- ret = -EINVAL;
+
+ /* check response error code */
+ ec_msg-result = ptr[0];
+ ret = cros_ec_check_result(ec_dev, ec_msg);
+ if (ret)
goto exit;
- }
+
len = ptr[1];
sum = ptr[0] + ptr[1];
if (len ec_msg-insize) {
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index 60c0880..1f79f16 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -143,6 +143,18 @@ int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
struct cros_ec_command *msg);
/**
+ * cros_ec_check_result - Check ec_msg-result
+ *
+ * This is used by ChromeOS EC drivers to check the ec_msg-result for
+ * errors and to warn about them.
+ *
+ * @ec_dev: EC device
+ * @msg: Message to check
+ */
+int cros_ec_check_result(struct cros_ec_device *ec_dev,
+ struct cros_ec_command *msg);
+
+/**
* cros_ec_remove - Remove a ChromeOS EC
*
* Call this to deregister a ChromeOS EC, then clean up any private data.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 10/10] mfd: cros_ec: move EC interrupt to cros_ec_keyb
On Wed, 18 Jun 2014, Doug Anderson wrote:
From: Andrew Bresticker abres...@chromium.org
If we receive EC interrupts after the cros_ec driver has probed, but
before the cros_ec_keyb driver has probed, the cros_ec IRQ handler
will not run the cros_ec_keyb notifier and the EC will leave the IRQ
line asserted. The cros_ec IRQ handler then returns IRQ_HANDLED and
the resulting flood of interrupts causes the machine to hang.
Since the EC interrupt is currently only used for the keyboard, move
the setup and handling of the EC interrupt to the cros_ec_keyb driver.
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v2:
- IRQs should be optional = move EC interrupt to keyboard.
drivers/input/keyboard/cros_ec_keyb.c | 58
---
drivers/mfd/cros_ec.c | 35 +
include/linux/mfd/cros_ec.h | 2 --
3 files changed, 34 insertions(+), 61 deletions(-)
For the MFD changes:
Acked-by: Lee Jones lee.jo...@linaro.org
diff --git a/drivers/input/keyboard/cros_ec_keyb.c
b/drivers/input/keyboard/cros_ec_keyb.c
index b8341ab..791781a 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -24,8 +24,8 @@
#include linux/module.h
#include linux/i2c.h
#include linux/input.h
+#include linux/interrupt.h
#include linux/kernel.h
-#include linux/notifier.h
#include linux/platform_device.h
#include linux/slab.h
#include linux/input/matrix_keypad.h
@@ -42,7 +42,6 @@
* @dev: Device pointer
* @idev: Input device
* @ec: Top level ChromeOS device to use to talk to EC
- * @event_notifier: interrupt event notifier for transport devices
*/
struct cros_ec_keyb {
unsigned int rows;
@@ -55,7 +54,6 @@ struct cros_ec_keyb {
struct device *dev;
struct input_dev *idev;
struct cros_ec_device *ec;
- struct notifier_block notifier;
};
@@ -173,22 +171,6 @@ static void cros_ec_keyb_process(struct cros_ec_keyb
*ckdev,
input_sync(ckdev-idev);
}
-static int cros_ec_keyb_open(struct input_dev *dev)
-{
- struct cros_ec_keyb *ckdev = input_get_drvdata(dev);
-
- return blocking_notifier_chain_register(ckdev-ec-event_notifier,
- ckdev-notifier);
-}
-
-static void cros_ec_keyb_close(struct input_dev *dev)
-{
- struct cros_ec_keyb *ckdev = input_get_drvdata(dev);
-
- blocking_notifier_chain_unregister(ckdev-ec-event_notifier,
-ckdev-notifier);
-}
-
static int cros_ec_keyb_get_state(struct cros_ec_keyb *ckdev, uint8_t
*kb_state)
{
struct cros_ec_command msg = {
@@ -203,19 +185,41 @@ static int cros_ec_keyb_get_state(struct cros_ec_keyb
*ckdev, uint8_t *kb_state)
return ckdev-ec-cmd_xfer(ckdev-ec, msg);
}
-static int cros_ec_keyb_work(struct notifier_block *nb,
- unsigned long state, void *_notify)
+static irqreturn_t cros_ec_keyb_irq(int irq, void *data)
{
+ struct cros_ec_keyb *ckdev = data;
+ struct cros_ec_device *ec = ckdev-ec;
int ret;
- struct cros_ec_keyb *ckdev = container_of(nb, struct cros_ec_keyb,
- notifier);
uint8_t kb_state[ckdev-cols];
+ if (device_may_wakeup(ec-dev))
+ pm_wakeup_event(ec-dev, 0);
+
ret = cros_ec_keyb_get_state(ckdev, kb_state);
if (ret = 0)
cros_ec_keyb_process(ckdev, kb_state, ret);
+ else
+ dev_err(ec-dev, failed to get keyboard state: %d\n, ret);
- return NOTIFY_DONE;
+ return IRQ_HANDLED;
+}
+
+static int cros_ec_keyb_open(struct input_dev *dev)
+{
+ struct cros_ec_keyb *ckdev = input_get_drvdata(dev);
+ struct cros_ec_device *ec = ckdev-ec;
+
+ return request_threaded_irq(ec-irq, NULL, cros_ec_keyb_irq,
+ IRQF_TRIGGER_LOW | IRQF_ONESHOT,
+ cros_ec_keyb, ckdev);
+}
+
+static void cros_ec_keyb_close(struct input_dev *dev)
+{
+ struct cros_ec_keyb *ckdev = input_get_drvdata(dev);
+ struct cros_ec_device *ec = ckdev-ec;
+
+ free_irq(ec-irq, ckdev);
}
static int cros_ec_keyb_probe(struct platform_device *pdev)
@@ -246,8 +250,12 @@ static int cros_ec_keyb_probe(struct platform_device
*pdev)
if (!idev)
return -ENOMEM;
+ if (!ec-irq) {
+ dev_err(dev, no EC IRQ specified\n);
+ return -EINVAL;
+ }
+
ckdev-ec = ec;
- ckdev-notifier.notifier_call = cros_ec_keyb_work;
ckdev-dev = dev;
dev_set_drvdata(pdev-dev, ckdev);
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 83e30c6..4873f9c 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -62,18 +62,6 @@ int
Re: [PATCH v3 0/4] ASoc: samsung: update s3c24xx to dmaengine and common clk framework
On Mon, Jun 23, 2014 at 11:24:03PM +0300, Vasily Khoruzhick wrote:
This series updates s3c24{xx,12}-i2s driver to use newer DMA and CLK APIs.
Applied all, thanks.
signature.asc
Description: Digital signature
RE: [PATCH RFC] mfd: syscon: Decouple syscon interface from syscon devices
Hi, On Wednesday, June 18 2014, Lee Jones wrote: On Tue, 17 Jun 2014, Tomasz Figa wrote: On 17.06.2014 17:42, Arnd Bergmann wrote: On Tuesday 17 June 2014 17:32:44 Tomasz Figa wrote: Currently a syscon entity can be only registered directly through a platform device that binds to a dedicated driver. However in certain use cases it is desirable to make a device used with another driver a syscon interface provider. For example, certain SoCs (e.g. Exynos) contain system controller blocks which perform various functions such as power domain control, CPU power management, low power mode control, but in addition contain certain IP integration glue, such as various signal masks, coprocessor power control, etc. In such case, there is a need to have a dedicated driver for such system controller but also share registers with other drivers. The latter is where the syscon interface is helpful. This patch decouples syscon object from syscon driver, so that it can be registered from any driver in addition to the original syscon platform driver. +1 for this approach. Michal, Pankay, Does it also suit your needs? Sorry for late reply. I tested this patch after changing exynos PMU to be a syscon provider and it's working well. So if we can address Arnd's comments, this patch will be helpful in making exynos PMU a complete platform driver. Thanks, Pankaj Dubey Signed-off-by: Tomasz Figa t.f...@samsung.com Hi Tomasz, This seems like a reasonable way of solving the problem, but I think there is an even better one that we have about in the past: if we promote syscon from a platform driver into a a drivers/base/ helper that is independent of the platform device matching, we can use call syscon_regmap_lookup_* for any device node, whether it's already bound to a driver or not, which do what you need. It would also make it easier to call the syscon code before the platform_device infrastructure gets initialized, which is something a number of people have asked for, e.g. for using regmap to do SMP bringup or for clock registration. Basically, unless I'm missing your point, this is what my patch does, except that I don't move it to drivers/base/ and the registration function I added require a pointer to struct device. Indeed, decoupling it further from the driver model, by adding of_syscon_register() should be useful for early users. If agreed by Arnd, I think this work can be completed as a subsequent patch. Should I move this to drivers/base/, even though from current location it can be used outside the platform driver anyway? If I'm being honest with myself, I'd say that Syscon wasn't really an MFD driver. I'm happy to keep it in there any continue maintaining it, but wouldn't block a move either. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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: MMC error on Exynos4210 board
On 23 juni 2014 06:30:08 CEST, Sachin Kamat spk.li...@gmail.com wrote: Hi Tim, On Sat, Jun 21, 2014 at 2:31 AM, Tim Kryger tim.kry...@gmail.com wrote: On Thu, Jun 19, 2014 at 8:33 PM, Sachin Kamat spk.li...@gmail.com wrote: On Thu, Jun 19, 2014 at 6:11 PM, Jaehoon Chung jh80.ch...@samsung.com wrote: On 06/19/2014 07:40 PM, Sachin Kamat wrote: On Thu, Jun 19, 2014 at 2:40 PM, Tim Kryger tim.kry...@gmail.com wrote: On Thu, Jun 19, 2014 at 1:49 AM, Sachin Kamat spk.li...@gmail.com wrote: On Thu, Jun 19, 2014 at 2:12 PM, Tim Kryger tim.kry...@gmail.com wrote: On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat spk.li...@gmail.com wrote: On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat spk.li...@gmail.com wrote: I see the below error on Exynos4210 based Origen board with linux-next (20140618). Reverting the below commit works fine. Commit: 8d02e775a6 mmc: sdhci: Use mmc core regulator infrastucture -- [2.068992] sdhci: Secure Digital Host Controller Interface driver [2.075059] sdhci: Copyright(c) Pierre Ossman [2.079762] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1251[0]' [2.088021] s3c-sdhci 1251.sdhci: clock source 2: mmc_busclk.2 (5000 Hz) [2.095322] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1251[0]' [2.103794] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1251[0]' [2.112478] s3c-sdhci 1251.sdhci: No vqmmc regulator found [2.118117] mmc0: Hardware doesn't report any support voltages. [2.124004] s3c-sdhci 1251.sdhci: sdhci_add_host() failed [2.130080] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1253[0]' [2.138352] s3c-sdhci 1253.sdhci: clock source 2: mmc_busclk.2 (1667 Hz) [2.145661] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1253[0]' [2.154139] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1253[0]' [2.162834] s3c-sdhci 1253.sdhci: No vqmmc regulator found [2.168464] mmc0: Hardware doesn't report any support voltages. [2.174349] s3c-sdhci 1253.sdhci: sdhci_add_host() failed [2.336148] Waiting for root device /dev/mmcblk0p1... FYI, the board has a 2.8V fixed regulator supply connected to the MMC. You may refer to arch/arm/boot/dts/exynos4210-origen.dts for more details. A 2.8v regulator results in mmc-ocr_avail being set to MMC_VDD_27_28 | MMC_VDD_28_29. The SDHCI capabilities register only indicates support of three voltage levels - 1.8v: SDHCI_CAN_VDD_180 = MMC_VDD_165_195 - 3.0v: SDHCI_CAN_VDD_300 = MMC_VDD_29_30 | MMC_VDD_30_31 - 3.3v: SDHCI_CAN_VDD_330 = MMC_VDD_32_33 | MMC_VDD_33_34 Right. sdhci capabilities only indicated them. But I think SoC can be support the specific VDD range. Even if all capability bits of the host controller were set, there still wouldn't be any overlap. Thus you see a Hardware doesn't report any support voltages message. Previously, this issue was being swept under the rug by cec2e21 mmc: sdhci: Use regulator min/max voltage range according to spec. That change hacked up the voltage range checks such that with your 2.8v fixed regulator, the driver would believe the host could support MMC_VDD_29_30 | MMC_VDD_30_31 | MMC_VDD_32_33 | MMC_VDD_33_34. The driver would start down the path of commanding 3.3v-3.4v (the highest voltage range believed to be supported). At the last second, the driver would see the regulator was fixed and blindly skip over the set voltage operation, saving it from failure. Since my patch eliminates the bogus voltage range checks, your board is now getting caught playing too loose with the SDHCI regulator voltages. Furthermore, the fixed regulator special-case logic that helped hide your issue should also be considered for removal given that fixed regulators now behave properly thanks to c00dc35 regulator: core: Allow regulator_set_voltage for fixed regulators. Thanks for the detailed explanation. What do you propose to get this fixed It would be nice if the driver could be extended to handle the peculiarities of your board in a deliberate manner but limiting the common sdhci driver to supporting only the three voltages from the spec also seems sensible. Until such time that the driver gets fixed to handle 2.8V fixed supply your current patch leaves several of Exynos boards broken for now. the all of exynos used the fixed-regulator(2.8v) should be broken. (Maybe exynos4 series??) Probably. I haven't verified for the other boards. Hence would be good to handle this case in the driver itself. The current external VDD regulator support in the SDHCI driver feels a bit tacked on. External regulators could reasonably support other voltage ranges, like MMC_VDD_27_28 | MMC_VDD_28_29, but those never appear in the final ocr_avail for the host. The driver only looks for the intersection of
[PATCH] drm/exynos: Support DP CLKCON register in FIMD driver
Add the missing setting for DP CLKCON register.
This register is present on Exynos5 based FIMD controllers,
and needs to be used if we are using DP.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |5 +
include/video/samsung_fimd.h |4
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 33161ad..5d3045d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -72,6 +72,7 @@ struct fimd_driver_data {
unsigned int has_shadowcon:1;
unsigned int has_clksel:1;
unsigned int has_limited_fmt:1;
+ unsigned int has_dp_clkcon:1;
};
static struct fimd_driver_data s3c64xx_fimd_driver_data = {
@@ -88,6 +89,7 @@ static struct fimd_driver_data exynos4_fimd_driver_data = {
static struct fimd_driver_data exynos5_fimd_driver_data = {
.timing_base = 0x2,
.has_shadowcon = 1,
+ .has_dp_clkcon = 1,
};
struct fimd_win_data {
@@ -331,6 +333,9 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
if (clkdiv 1)
val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
+ if (ctx-driver_data-has_dp_clkcon)
+ writel(DP_CLK_ENABLE, ctx-regs + DP_CLKCON);
+
writel(val, ctx-regs + VIDCON0);
}
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index b039320..d8f4b0b 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -435,6 +435,10 @@
#define BLENDCON_NEW_8BIT_ALPHA_VALUE (1 0)
#define BLENDCON_NEW_4BIT_ALPHA_VALUE (0 0)
+/* Video clock enable for DP */
+#define DP_CLKCON 0x27C
+#define DP_CLK_ENABLE 0x2
+
/* Notes on per-window bpp settings
*
* Value Win0 Win1 Win2 Win3 Win 4
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5 v2] drm/exynos: allow mulitple layer updates per vsync for mixer
Am 24.06.2014 07:21, schrieb Inki Dae:
On 2014년 06월 23일 14:32, Rahul Sharma wrote:
Allowing only one layer update per vsync can cause issues
while there are update available for both layers. There is
a good amount of possibility to loose updates if we allow
single update per vsync.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_mixer.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index d359501..6773b03 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -511,13 +511,8 @@ static void vp_video_buffer(struct mixer_context *ctx,
int win)
static void mixer_layer_update(struct mixer_context *ctx)
{
struct mixer_resources *res = ctx-mixer_res;
-u32 val;
-
-val = mixer_reg_read(res, MXR_CFG);
-/* allow one update per vsync only */
-if (!(val MXR_CFG_LAYER_UPDATE_COUNT_MASK))
-mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
+mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
Rahul, it looks good to me and ok as is. But above codes don't consider
Exynos4 series. In case of Exynos4xxx SoC,
MXR_CFG_LAYER_UPDATE_COUNT_MASK and MXR_CFG_LAYER_UPDATE of MIXER_CFG
register are reserved fields. So can you work that patch to be
considered for Exynos4xxx SoC? That patch would be additional one.
Anyway, will apply it as is, and I will wait for the additional patch.
If it's not too late, could you fix up multiple in the subject? :)
Cheers,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
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/4] ARM: dts: refactor Odroid DTS file and add support for Odroid X2 and U2/U3
Hello, On 2014-06-19 14:43, Daniel Drake wrote: On Tue, Jun 17, 2014 at 10:25 AM, Marek Szyprowski m.szyprow...@samsung.com wrote: This patch moves some parts of exynos4412-odroidx.dts to common exynos4412-odroid-common.dtsi file and adds support for Odroid X2 and U2/U3 boards. X2 is same as X, but it has faster SoC module (1.7GHz instead of 1.4GHz), while U2/U3 differs from X2 by different way of routing signals to host USB hub. It also lacks some hw modules not yet supported by those dts files (i.e. LCD touch panel). Thanks for this! It is working on ODROID-U2: at least eMMC/SD, LED, serial. Just 2 minor questions from reviewing: Odroid-X DTS used to have serial ports at 1382 and 1383, this patch removes them, but leaves 2. Right. I've forgot the UART port change. Now I've checked it again and schematics reveals that Odroid X/X2 and U2/U3 has UART1 available on UART connector. On the other hand U2/U3 have UART0 RX/TX lines on GPIO connector, while X/X2 has UART3 lines on the LCD/GPIO connector. I can understand the idea of removing entries for ports that are not available on the board, but I've never seen an ODROID with 2 serial ports - should we bring this down to just the 1 enabled serial port that is accessible? That would be best solution, but this way the tty driver name will change from ttySAC1 to ttySAC0 for UART1 port. Until uart driver gets fixed, I would keep all 4 uart defined on X/X2 and define only uart 0 and 1 on U2/U3. I will fix this in the next version of Odroid patches. Odroid-X DTS used to enable EHCI port 2, but with this refactoring, no longer does. Intentional? This was a bug in the initial patch adding usb support. X and X2 uses only HSCI0 port (ehci port 1). Thanks for your review! Best regards -- Marek Szyprowski, PhD Samsung RD Institute Poland -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] hwmon: ntc_thermistor: prepose vendor prefix change
As Murata is the manufacturer of the NTC (Negative Temperature coefficient) based Thermistors. ntc_thermistor driver extensively used the prefix ntc. But, vendor-prefix should be murata instead of ntc. This patchset 1. Updates the vendor-prefix, DT bindings and Documentation, where ever necessary. 2. Adds thermistor nodes to Exynos5420 and Exynos5800 based boards. Patches: 1/4. devicetree: bindings: Document murata vendor prefix Adds the vendor prefix murata to vendor-prefixes.txt. 2/4. hwmon: ntc_thermistor: Use the manufacturer name properly Updates the driver, Kconfig, device tree bindings and Documentation with the Manufacturer/vendor information. 3/4. ARM: DTS: use new compatible string as per the documentation Updates the device node in Exynos4412 based Trats2 board with the new device tree bindings. 4/4. ARM: DTS: Add NTC thermistor nodes as child nodes to ADC Adds Thermistor nodes to Exynos5420 and Exynos5800 based boards. This patchset Naveen Krishna Chatradhi (4): devicetree: bindings: Document murata vendor prefix hwmon: ntc_thermistor: Use the manufacturer name properly ARM: DTS: Add NTC thermistor nodes as child nodes to ADC ARM: DTS: use new compatible string as per the documentation .../devicetree/bindings/arm/samsung/exynos-adc.txt |2 +- .../devicetree/bindings/hwmon/ntc_thermistor.txt | 12 .../devicetree/bindings/vendor-prefixes.txt|1 + Documentation/hwmon/ntc_thermistor |8 ++--- arch/arm/boot/dts/exynos4412-trats2.dts|4 +-- arch/arm/boot/dts/exynos5420-peach-pit.dts | 32 drivers/hwmon/Kconfig |5 +-- drivers/hwmon/ntc_thermistor.c | 12 8 files changed, 55 insertions(+), 21 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] devicetree: bindings: Document murata vendor prefix
Add Murata Manufacturing Co., Ltd. to the list of device tree vendor prefixes. Murata manufactures NTC (Negative Temperature Coefficient) based Thermistors for small scale applications like Mobiles and PDAs. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Cc: Guenter Roeck li...@roeck-us.net --- This changes is needed for the following reasons 1. The vendor prefix ntc is not defined in vendor-prefixes.txt Thus, giving an error when checked with scripts/checkpatch.pl 2. Murata Manufacturing Co., Ltd. Is the vendor for the NTC (Negative Temperature Coefficient) based thermistors. Hence, murata is the right vendor-prefix, Not ntc. 3. NTC is a technology used, But the prefix ntc is wrongly and heavily used in the driver and the documentation. .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 4d7f375..a39b7d7 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -84,6 +84,7 @@ moxa Moxa mplMPL AG mundoreaderMundo Reader S.L. mxicy Macronix International Co., Ltd. +murata Murata Manufacturing Co., Ltd. national National Semiconductor neonodeNeonode Inc. netgearNETGEAR -- 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 3/4] ARM: DTS: use new compatible string as per the documentation
As Murata is the Manufactures the NTC thermistors. The vendor
name in the compatibility is preposed to change to murata, ncpXXX
This patch uses the new compatibility string in exynos4412 based
Trats2 board.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Chanwoo Choi cw00.c...@samsung.com
---
1. Updates the thermistor node in Exynos4412 based Trats2 dts
using the new DT bindings for NTC thermistors updated with vendor-prefix
arch/arm/boot/dts/exynos4412-trats2.dts |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 11967f4..d35755a 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -771,7 +771,7 @@
};
thermistor-ap@0 {
- compatible = ntc,ncp15wb473;
+ compatible = murata,ncp15wb473;
pullup-uv = 180; /* VCC_1.8V_AP */
pullup-ohm = 10; /* 100K */
pulldown-ohm = 10; /* 100K */
@@ -779,7 +779,7 @@
};
thermistor-battery@1 {
- compatible = ntc,ncp15wb473;
+ compatible = murata,ncp15wb473;
pullup-uv = 180; /* VCC_1.8V_AP */
pullup-ohm = 10; /* 100K */
pulldown-ohm = 10; /* 100K */
--
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 2/4] hwmon: ntc_thermistor: Use the manufacturer name properly
Murata Manufacturing Co., Ltd is the vendor for
NTC (Negative Temperature coefficient) based Thermistors.
But, the driver extensively uses NTC as the vendor name.
This patch corrects the vendor name also updates the
compatibility strings according to the vendor-prefix.txt
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Guenter Roeck li...@roeck-us.net
---
This changes is needed for the following reasons
1. The vendor prefix ntc is not defined in vendor-prefixes.txt
Thus, giving an error when checked with scripts/checkpatch.pl
2. Murata Manufacturing Co., Ltd. Is the vendor for the
NTC (Negative Temperature Coefficient) based thermistors.
Hence, murata is the right vendor-prefix, Not ntc.
3. NTC is a technology used, But the prefix ntc is wrongly
and heavily used in the driver and the documentation.
.../devicetree/bindings/arm/samsung/exynos-adc.txt |2 +-
.../devicetree/bindings/hwmon/ntc_thermistor.txt | 12 ++--
Documentation/hwmon/ntc_thermistor |8
drivers/hwmon/Kconfig |5 +++--
drivers/hwmon/ntc_thermistor.c | 12 ++--
5 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index 5d49f2b..832fe8c 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -48,7 +48,7 @@ adc@12D1 {
/* NTC thermistor is a hwmon device */
ncp15wb473@0 {
- compatible = ntc,ncp15wb473;
+ compatible = murata,ncp15wb473;
pullup-uv = 180;
pullup-ohm = 47000;
pulldown-ohm = 0;
diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
index c6f6667..4e9f344 100644
--- a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
+++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
@@ -3,11 +3,11 @@ NTC Thermistor hwmon sensors
Requires node properties:
- compatible value : one of
- ntc,ncp15wb473
- ntc,ncp18wb473
- ntc,ncp21wb473
- ntc,ncp03wb473
- ntc,ncp15wl333
+ murata,ncp15wb473
+ murata,ncp18wb473
+ murata,ncp21wb473
+ murata,ncp03wb473
+ murata,ncp15wl333
- pullup-uv Pull up voltage in micro volts
- pullup-ohm Pull up resistor value in ohms
- pulldown-ohm Pull down resistor value in ohms
@@ -21,7 +21,7 @@ Read more about iio bindings at
Example:
ncp15wb473@0 {
- compatible = ntc,ncp15wb473;
+ compatible = murata,ncp15wb473;
pullup-uv = 180;
pullup-ohm = 47000;
pulldown-ohm = 0;
diff --git a/Documentation/hwmon/ntc_thermistor
b/Documentation/hwmon/ntc_thermistor
index 3bfda94..057b770 100644
--- a/Documentation/hwmon/ntc_thermistor
+++ b/Documentation/hwmon/ntc_thermistor
@@ -1,7 +1,7 @@
Kernel driver ntc_thermistor
=
-Supported thermistors:
+Supported thermistors from Murata:
* Murata NTC Thermistors NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473,
NCP15WL333
Prefixes: 'ncp15wb473', 'ncp18wb473', 'ncp21wb473', 'ncp03wb473',
'ncp15wl333'
Datasheet: Publicly available at Murata
@@ -15,9 +15,9 @@ Authors:
Description
---
-The NTC thermistor is a simple thermistor that requires users to provide the
-resistance and lookup the corresponding compensation table to get the
-temperature input.
+The NTC (Negative Temperature Coefficient) thermistor is a simple thermistor
+that requires users to provide the resistance and lookup the corresponding
+compensation table to get the temperature input.
The NTC driver provides lookup tables with a linear approximation function
and four circuit models with an option not to use any of the four models.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 08531a1..154851b 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1052,7 +1052,7 @@ config SENSORS_PC87427
will be called pc87427.
config SENSORS_NTC_THERMISTOR
- tristate NTC thermistor support
+ tristate NTC based thermistor support from Murata
depends on !OF || IIO=n || IIO
help
This driver supports NTC thermistors sensor reading and its
@@ -1060,7 +1060,8 @@ config SENSORS_NTC_THERMISTOR
send notifications about the temperature.
Currently, this driver supports
- NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473, and NCP15WL333.
+ NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473, and NCP15WL333
+ from Murata.
This driver can also be built as a module. If so, the module
will be called ntc-thermistor.
diff --git a/drivers/hwmon/ntc_thermistor.c
[PATCH 4/4] ARM: DTS: Add NTC thermistor nodes as child nodes to ADC
Exynos5420 based Peach PIT and Exynos5800 based PI boards have
4 NTC thermistors to measure temperatures at various points on the
board.
IIO based ADC becomes the parent and NTC thermistors are the childs,
via the HWMON interface.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Doug Anderson diand...@chromium.org
---
This patch needs
1. MAX77802 PMIC device tree nodes (for ldo9)
https://www.mail-archive.com/devicetree@vger.kernel.org/msg31430.html
2. Uses the DT documentation for NTC thermistors updated with vendor-prefix
arch/arm/boot/dts/exynos5420-peach-pit.dts | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index b96a66a..852a220 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -751,4 +751,36 @@
timeout-sec = 32;
};
+adc {
+ vdd-supply = ldo9_reg;
+ ncp15wb473@3 {
+ compatible = murata,ncp15wb473;
+ pullup-uv = 180;
+ pullup-ohm = 47000;
+ pulldown-ohm = 0;
+ io-channels = adc 3;
+ };
+ ncp15wb473@4 {
+ compatible = murata,ncp15wb473;
+ pullup-uv = 180;
+ pullup-ohm = 47000;
+ pulldown-ohm = 0;
+ io-channels = adc 4;
+ };
+ ncp15wb473@5 {
+ compatible = murata,ncp15wb473;
+ pullup-uv = 180;
+ pullup-ohm = 47000;
+ pulldown-ohm = 0;
+ io-channels = adc 5;
+ };
+ ncp15wb473@6 {
+ compatible = murata,ncp15wb473;
+ pullup-uv = 180;
+ pullup-ohm = 47000;
+ pulldown-ohm = 0;
+ io-channels = adc 6;
+ };
+};
+
#include cros-ec-keyboard.dtsi
--
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] phy: phy-samsung-usb2: Change phy power on/power off sequence
The Exynos4412 USB 2.0 PHY hardware differs from the description provided
in the documentation. Some register bits have different function. This
patch fixes the defines of register bits and changes the way how phys are
powered on and off.
Signed-off-by: Kamil Debski k.deb...@samsung.com
---
drivers/phy/phy-exynos4x12-usb2.c | 112 +
drivers/phy/phy-samsung-usb2.h|3 +-
2 files changed, 77 insertions(+), 38 deletions(-)
diff --git a/drivers/phy/phy-exynos4x12-usb2.c
b/drivers/phy/phy-exynos4x12-usb2.c
index d92a7cc..59d8dd3 100644
--- a/drivers/phy/phy-exynos4x12-usb2.c
+++ b/drivers/phy/phy-exynos4x12-usb2.c
@@ -86,13 +86,23 @@
#define EXYNOS_4x12_URSTCON_OTG_HLINK BIT(1)
#define EXYNOS_4x12_URSTCON_OTG_PHYLINKBIT(2)
#define EXYNOS_4x12_URSTCON_HOST_PHY BIT(3)
+/* The following bit defines are presented in the
+ * order taken from the Exynos4412 reference manual.
+ *
+ * During experiments with the hardware and debugging
+ * it was determined that the hardware behaves contrary
+ * to the manual.
+ *
+ * The following bit values were chaned accordingly to the
+ * results of real hardware experiments.
+ */
#define EXYNOS_4x12_URSTCON_PHY1 BIT(4)
-#define EXYNOS_4x12_URSTCON_HSIC0 BIT(5)
-#define EXYNOS_4x12_URSTCON_HSIC1 BIT(6)
+#define EXYNOS_4x12_URSTCON_HSIC0 BIT(6)
+#define EXYNOS_4x12_URSTCON_HSIC1 BIT(5)
#define EXYNOS_4x12_URSTCON_HOST_LINK_ALL BIT(7)
-#define EXYNOS_4x12_URSTCON_HOST_LINK_P0 BIT(8)
+#define EXYNOS_4x12_URSTCON_HOST_LINK_P0 BIT(10)
#define EXYNOS_4x12_URSTCON_HOST_LINK_P1 BIT(9)
-#define EXYNOS_4x12_URSTCON_HOST_LINK_P2 BIT(10)
+#define EXYNOS_4x12_URSTCON_HOST_LINK_P2 BIT(8)
/* Isolation, configured in the power management unit */
#define EXYNOS_4x12_USB_ISOL_OFFSET0x704
@@ -188,6 +198,7 @@ static void exynos4x12_setup_clk(struct
samsung_usb2_phy_instance *inst)
clk = readl(drv-reg_phy + EXYNOS_4x12_UPHYCLK);
clk = ~EXYNOS_4x12_UPHYCLK_PHYFSEL_MASK;
clk |= drv-ref_reg_val EXYNOS_4x12_UPHYCLK_PHYFSEL_OFFSET;
+ clk |= EXYNOS_4x12_UPHYCLK_PHY1_COMMON_ON;
writel(clk, drv-reg_phy + EXYNOS_4x12_UPHYCLK);
}
@@ -198,27 +209,22 @@ static void exynos4x12_phy_pwr(struct
samsung_usb2_phy_instance *inst, bool on)
u32 phypwr = 0;
u32 rst;
u32 pwr;
- u32 mode = 0;
- u32 switch_mode = 0;
switch (inst-cfg-id) {
case EXYNOS4x12_DEVICE:
phypwr =EXYNOS_4x12_UPHYPWR_PHY0;
rstbits = EXYNOS_4x12_URSTCON_PHY0;
- mode = EXYNOS_4x12_MODE_SWITCH_DEVICE;
- switch_mode = 1;
break;
case EXYNOS4x12_HOST:
phypwr =EXYNOS_4x12_UPHYPWR_PHY1;
- rstbits = EXYNOS_4x12_URSTCON_HOST_PHY;
- mode = EXYNOS_4x12_MODE_SWITCH_HOST;
- switch_mode = 1;
+ rstbits = EXYNOS_4x12_URSTCON_HOST_PHY |
+ EXYNOS_4x12_URSTCON_PHY1 |
+ EXYNOS_4x12_URSTCON_HOST_LINK_P0;
break;
case EXYNOS4x12_HSIC0:
phypwr =EXYNOS_4x12_UPHYPWR_HSIC0;
- rstbits = EXYNOS_4x12_URSTCON_HSIC1 |
- EXYNOS_4x12_URSTCON_HOST_LINK_P0 |
- EXYNOS_4x12_URSTCON_HOST_PHY;
+ rstbits = EXYNOS_4x12_URSTCON_HSIC0 |
+ EXYNOS_4x12_URSTCON_HOST_LINK_P1 ;
break;
case EXYNOS4x12_HSIC1:
phypwr =EXYNOS_4x12_UPHYPWR_HSIC1;
@@ -228,11 +234,6 @@ static void exynos4x12_phy_pwr(struct
samsung_usb2_phy_instance *inst, bool on)
};
if (on) {
- if (switch_mode)
- regmap_update_bits(drv-reg_sys,
- EXYNOS_4x12_MODE_SWITCH_OFFSET,
- EXYNOS_4x12_MODE_SWITCH_MASK, mode);
-
pwr = readl(drv-reg_phy + EXYNOS_4x12_UPHYPWR);
pwr = ~phypwr;
writel(pwr, drv-reg_phy + EXYNOS_4x12_UPHYPWR);
@@ -253,41 +254,78 @@ static void exynos4x12_phy_pwr(struct
samsung_usb2_phy_instance *inst, bool on)
}
}
-static int exynos4x12_power_on(struct samsung_usb2_phy_instance *inst)
+static void exynos4x12_power_on_internal(struct samsung_usb2_phy_instance
*inst)
{
- struct samsung_usb2_phy_driver *drv = inst-drv;
+ if (inst-int_cnt++ 0)
+ return;
- inst-enabled = 1;
exynos4x12_setup_clk(inst);
- exynos4x12_phy_pwr(inst, 1);
exynos4x12_isol(inst, 0);
+ exynos4x12_phy_pwr(inst, 1);
+}
+
+static int exynos4x12_power_on(struct samsung_usb2_phy_instance *inst)
+{
+ struct
Re: [PATCH] drm/exynos: Support DP CLKCON register in FIMD driver
Hi Ajay,
On 06/24/2014 01:09 PM, Ajay Kumar wrote:
Add the missing setting for DP CLKCON register.
This register is present on Exynos5 based FIMD controllers,
and needs to be used if we are using DP.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |5 +
include/video/samsung_fimd.h |4
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 33161ad..5d3045d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -72,6 +72,7 @@ struct fimd_driver_data {
unsigned int has_shadowcon:1;
unsigned int has_clksel:1;
unsigned int has_limited_fmt:1;
+ unsigned int has_dp_clkcon:1;
};
static struct fimd_driver_data s3c64xx_fimd_driver_data = {
@@ -88,6 +89,7 @@ static struct fimd_driver_data exynos4_fimd_driver_data = {
static struct fimd_driver_data exynos5_fimd_driver_data = {
.timing_base = 0x2,
.has_shadowcon = 1,
+ .has_dp_clkcon = 1,
};
struct fimd_win_data {
@@ -331,6 +333,9 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
if (clkdiv 1)
val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
+ if (ctx-driver_data-has_dp_clkcon)
+ writel(DP_CLK_ENABLE, ctx-regs + DP_CLKCON);
+
This code always enables the clock on exynos5. As I understand it should
be enabled only if DP is used.
Regards
Andrzej
writel(val, ctx-regs + VIDCON0);
}
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index b039320..d8f4b0b 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -435,6 +435,10 @@
#define BLENDCON_NEW_8BIT_ALPHA_VALUE(1 0)
#define BLENDCON_NEW_4BIT_ALPHA_VALUE(0 0)
+/* Video clock enable for DP */
+#define DP_CLKCON0x27C
+#define DP_CLK_ENABLE0x2
+
/* Notes on per-window bpp settings
*
* Value Win0 Win1 Win2 Win3 Win 4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/exynos: Support DP CLKCON register in FIMD driver
On Tue, Jun 24, 2014 at 9:01 AM, Andrzej Hajda a.ha...@samsung.com wrote:
Hi Ajay,
On 06/24/2014 01:09 PM, Ajay Kumar wrote:
Add the missing setting for DP CLKCON register.
This register is present on Exynos5 based FIMD controllers,
and needs to be used if we are using DP.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |5 +
include/video/samsung_fimd.h |4
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 33161ad..5d3045d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -72,6 +72,7 @@ struct fimd_driver_data {
unsigned int has_shadowcon:1;
unsigned int has_clksel:1;
unsigned int has_limited_fmt:1;
+ unsigned int has_dp_clkcon:1;
};
static struct fimd_driver_data s3c64xx_fimd_driver_data = {
@@ -88,6 +89,7 @@ static struct fimd_driver_data exynos4_fimd_driver_data = {
static struct fimd_driver_data exynos5_fimd_driver_data = {
.timing_base = 0x2,
.has_shadowcon = 1,
+ .has_dp_clkcon = 1,
};
struct fimd_win_data {
@@ -331,6 +333,9 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
if (clkdiv 1)
val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
+ if (ctx-driver_data-has_dp_clkcon)
+ writel(DP_CLK_ENABLE, ctx-regs + DP_CLKCON);
+
This code always enables the clock on exynos5. As I understand it should
be enabled only if DP is used.
Right!
But, when I searched for the display interface,
only exynos4 based boards use MIPI/DPI, and all exynos5 based boards use DP.
So, I thought adding this in driver_data for exynos5 should be fine.
Inki/Andrej - Shall I add it as an optional DT property?
Ajay
writel(val, ctx-regs + VIDCON0);
}
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index b039320..d8f4b0b 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -435,6 +435,10 @@
#define BLENDCON_NEW_8BIT_ALPHA_VALUE(1 0)
#define BLENDCON_NEW_4BIT_ALPHA_VALUE(0 0)
+/* Video clock enable for DP */
+#define DP_CLKCON0x27C
+#define DP_CLK_ENABLE0x2
+
/* Notes on per-window bpp settings
*
* Value Win0 Win1 Win2 Win3 Win 4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] devicetree: bindings: Document murata vendor prefix
On Tue, Jun 24, 2014 at 01:19:13PM +0100, Naveen Krishna Chatradhi wrote: Add Murata Manufacturing Co., Ltd. to the list of device tree vendor prefixes. Murata manufactures NTC (Negative Temperature Coefficient) based Thermistors for small scale applications like Mobiles and PDAs. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Cc: Guenter Roeck li...@roeck-us.net --- This changes is needed for the following reasons 1. The vendor prefix ntc is not defined in vendor-prefixes.txt Thus, giving an error when checked with scripts/checkpatch.pl 2. Murata Manufacturing Co., Ltd. Is the vendor for the NTC (Negative Temperature Coefficient) based thermistors. Hence, murata is the right vendor-prefix, Not ntc. 3. NTC is a technology used, But the prefix ntc is wrongly and heavily used in the driver and the documentation. .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 4d7f375..a39b7d7 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -84,6 +84,7 @@ moxaMoxa mpl MPL AG mundoreader Mundo Reader S.L. mxicyMacronix International Co., Ltd. +murata Murata Manufacturing Co., Ltd. Nit: please keep this list in alphabetical order. Otherwise, this looks fine to me. With the order fixed: Acked-by: Mark Rutland mark.rutl...@arm.com Mark. national National Semiconductor neonode Neonode Inc. netgear NETGEAR -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe devicetree 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 2/4] hwmon: ntc_thermistor: Use the manufacturer name properly
On Tue, Jun 24, 2014 at 01:19:14PM +0100, Naveen Krishna Chatradhi wrote:
Murata Manufacturing Co., Ltd is the vendor for
NTC (Negative Temperature coefficient) based Thermistors.
But, the driver extensively uses NTC as the vendor name.
This patch corrects the vendor name also updates the
compatibility strings according to the vendor-prefix.txt
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Guenter Roeck li...@roeck-us.net
---
This changes is needed for the following reasons
1. The vendor prefix ntc is not defined in vendor-prefixes.txt
Thus, giving an error when checked with scripts/checkpatch.pl
2. Murata Manufacturing Co., Ltd. Is the vendor for the
NTC (Negative Temperature Coefficient) based thermistors.
Hence, murata is the right vendor-prefix, Not ntc.
3. NTC is a technology used, But the prefix ntc is wrongly
and heavily used in the driver and the documentation.
.../devicetree/bindings/arm/samsung/exynos-adc.txt |2 +-
.../devicetree/bindings/hwmon/ntc_thermistor.txt | 12 ++--
Documentation/hwmon/ntc_thermistor |8
drivers/hwmon/Kconfig |5 +++--
drivers/hwmon/ntc_thermistor.c | 12 ++--
5 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index 5d49f2b..832fe8c 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -48,7 +48,7 @@ adc@12D1 {
/* NTC thermistor is a hwmon device */
ncp15wb473@0 {
- compatible = ntc,ncp15wb473;
+ compatible = murata,ncp15wb473;
pullup-uv = 180;
pullup-ohm = 47000;
pulldown-ohm = 0;
diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
index c6f6667..4e9f344 100644
--- a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
+++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
@@ -3,11 +3,11 @@ NTC Thermistor hwmon sensors
Requires node properties:
- compatible value : one of
- ntc,ncp15wb473
- ntc,ncp18wb473
- ntc,ncp21wb473
- ntc,ncp03wb473
- ntc,ncp15wl333
+ murata,ncp15wb473
+ murata,ncp18wb473
+ murata,ncp21wb473
+ murata,ncp03wb473
+ murata,ncp15wl333
So we're outright changing these rather than deprecating the existing
forms?
In general we've pushed back on changes like this, and requested that
the old strings are kept in both documentation and code as deprecated
forms.
Can you guarantee that changing this is not going to stop someone's
board worknig properly? I suspect not.
Mark.
- pullup-uvPull up voltage in micro volts
- pullup-ohm Pull up resistor value in ohms
- pulldown-ohm Pull down resistor value in ohms
@@ -21,7 +21,7 @@ Read more about iio bindings at
Example:
ncp15wb473@0 {
- compatible = ntc,ncp15wb473;
+ compatible = murata,ncp15wb473;
pullup-uv = 180;
pullup-ohm = 47000;
pulldown-ohm = 0;
diff --git a/Documentation/hwmon/ntc_thermistor
b/Documentation/hwmon/ntc_thermistor
index 3bfda94..057b770 100644
--- a/Documentation/hwmon/ntc_thermistor
+++ b/Documentation/hwmon/ntc_thermistor
@@ -1,7 +1,7 @@
Kernel driver ntc_thermistor
=
-Supported thermistors:
+Supported thermistors from Murata:
* Murata NTC Thermistors NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473,
NCP15WL333
Prefixes: 'ncp15wb473', 'ncp18wb473', 'ncp21wb473', 'ncp03wb473',
'ncp15wl333'
Datasheet: Publicly available at Murata
@@ -15,9 +15,9 @@ Authors:
Description
---
-The NTC thermistor is a simple thermistor that requires users to provide the
-resistance and lookup the corresponding compensation table to get the
-temperature input.
+The NTC (Negative Temperature Coefficient) thermistor is a simple thermistor
+that requires users to provide the resistance and lookup the corresponding
+compensation table to get the temperature input.
The NTC driver provides lookup tables with a linear approximation function
and four circuit models with an option not to use any of the four models.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 08531a1..154851b 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1052,7 +1052,7 @@ config SENSORS_PC87427
will be called pc87427.
config SENSORS_NTC_THERMISTOR
- tristate NTC thermistor support
+ tristate NTC based thermistor support from Murata
depends on !OF || IIO=n || IIO
help
This driver supports NTC thermistors sensor reading and its
@@
Re: [PATCH 3/4] ARM: DTS: use new compatible string as per the documentation
On Tue, Jun 24, 2014 at 01:19:15PM +0100, Naveen Krishna Chatradhi wrote:
As Murata is the Manufactures the NTC thermistors. The vendor
name in the compatibility is preposed to change to murata, ncpXXX
This patch uses the new compatibility string in exynos4412 based
Trats2 board.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Chanwoo Choi cw00.c...@samsung.com
---
1. Updates the thermistor node in Exynos4412 based Trats2 dts
using the new DT bindings for NTC thermistors updated with vendor-prefix
arch/arm/boot/dts/exynos4412-trats2.dts |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 11967f4..d35755a 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -771,7 +771,7 @@
};
thermistor-ap@0 {
- compatible = ntc,ncp15wb473;
+ compatible = murata,ncp15wb473;
So the previous patch woul have broken this board?
Mark.
pullup-uv = 180; /* VCC_1.8V_AP */
pullup-ohm = 10; /* 100K */
pulldown-ohm = 10; /* 100K */
@@ -779,7 +779,7 @@
};
thermistor-battery@1 {
- compatible = ntc,ncp15wb473;
+ compatible = murata,ncp15wb473;
pullup-uv = 180; /* VCC_1.8V_AP */
pullup-ohm = 10; /* 100K */
pulldown-ohm = 10; /* 100K */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe devicetree 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 1/4] devicetree: bindings: Document murata vendor prefix
Hello Mark, On 24 June 2014 19:00, Mark Rutland mark.rutl...@arm.com wrote: On Tue, Jun 24, 2014 at 01:19:13PM +0100, Naveen Krishna Chatradhi wrote: Add Murata Manufacturing Co., Ltd. to the list of device tree vendor prefixes. Murata manufactures NTC (Negative Temperature Coefficient) based Thermistors for small scale applications like Mobiles and PDAs. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Cc: Guenter Roeck li...@roeck-us.net --- This changes is needed for the following reasons 1. The vendor prefix ntc is not defined in vendor-prefixes.txt Thus, giving an error when checked with scripts/checkpatch.pl 2. Murata Manufacturing Co., Ltd. Is the vendor for the NTC (Negative Temperature Coefficient) based thermistors. Hence, murata is the right vendor-prefix, Not ntc. 3. NTC is a technology used, But the prefix ntc is wrongly and heavily used in the driver and the documentation. .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 4d7f375..a39b7d7 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -84,6 +84,7 @@ moxaMoxa mpl MPL AG mundoreader Mundo Reader S.L. mxicyMacronix International Co., Ltd. +murata Murata Manufacturing Co., Ltd. Nit: please keep this list in alphabetical order. Sure, Will rearrange and re-spin. Otherwise, this looks fine to me. With the order fixed: Acked-by: Mark Rutland mark.rutl...@arm.com Thanks Mark. national National Semiconductor neonode Neonode Inc. netgear NETGEAR -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Shine bright, (: Nav :) -- 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/4] hwmon: ntc_thermistor: Use the manufacturer name properly
Hello Mark,
On 24 June 2014 19:02, Mark Rutland mark.rutl...@arm.com wrote:
On Tue, Jun 24, 2014 at 01:19:14PM +0100, Naveen Krishna Chatradhi wrote:
Murata Manufacturing Co., Ltd is the vendor for
NTC (Negative Temperature coefficient) based Thermistors.
But, the driver extensively uses NTC as the vendor name.
This patch corrects the vendor name also updates the
compatibility strings according to the vendor-prefix.txt
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Guenter Roeck li...@roeck-us.net
---
This changes is needed for the following reasons
1. The vendor prefix ntc is not defined in vendor-prefixes.txt
Thus, giving an error when checked with scripts/checkpatch.pl
2. Murata Manufacturing Co., Ltd. Is the vendor for the
NTC (Negative Temperature Coefficient) based thermistors.
Hence, murata is the right vendor-prefix, Not ntc.
3. NTC is a technology used, But the prefix ntc is wrongly
and heavily used in the driver and the documentation.
.../devicetree/bindings/arm/samsung/exynos-adc.txt |2 +-
.../devicetree/bindings/hwmon/ntc_thermistor.txt | 12 ++--
Documentation/hwmon/ntc_thermistor |8
drivers/hwmon/Kconfig |5 +++--
drivers/hwmon/ntc_thermistor.c | 12 ++--
5 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
index 5d49f2b..832fe8c 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -48,7 +48,7 @@ adc@12D1 {
/* NTC thermistor is a hwmon device */
ncp15wb473@0 {
- compatible = ntc,ncp15wb473;
+ compatible = murata,ncp15wb473;
pullup-uv = 180;
pullup-ohm = 47000;
pulldown-ohm = 0;
diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
index c6f6667..4e9f344 100644
--- a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
+++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
@@ -3,11 +3,11 @@ NTC Thermistor hwmon sensors
Requires node properties:
- compatible value : one of
- ntc,ncp15wb473
- ntc,ncp18wb473
- ntc,ncp21wb473
- ntc,ncp03wb473
- ntc,ncp15wl333
+ murata,ncp15wb473
+ murata,ncp18wb473
+ murata,ncp21wb473
+ murata,ncp03wb473
+ murata,ncp15wl333
So we're outright changing these rather than deprecating the existing
forms?
In general we've pushed back on changes like this, and requested that
the old strings are kept in both documentation and code as deprecated
forms.
Should have kept the old bindings as deprecated.
Can you guarantee that changing this is not going to stop someone's
board worknig properly? I suspect not.
As a result of this change, Exynos4412-Trats2 board is broken.
Will re-spin with the deprecated binding.
Mark.
- pullup-uvPull up voltage in micro volts
- pullup-ohm Pull up resistor value in ohms
- pulldown-ohm Pull down resistor value in ohms
@@ -21,7 +21,7 @@ Read more about iio bindings at
Example:
ncp15wb473@0 {
- compatible = ntc,ncp15wb473;
+ compatible = murata,ncp15wb473;
pullup-uv = 180;
pullup-ohm = 47000;
pulldown-ohm = 0;
diff --git a/Documentation/hwmon/ntc_thermistor
b/Documentation/hwmon/ntc_thermistor
index 3bfda94..057b770 100644
--- a/Documentation/hwmon/ntc_thermistor
+++ b/Documentation/hwmon/ntc_thermistor
@@ -1,7 +1,7 @@
Kernel driver ntc_thermistor
=
-Supported thermistors:
+Supported thermistors from Murata:
* Murata NTC Thermistors NCP15WB473, NCP18WB473, NCP21WB473, NCP03WB473,
NCP15WL333
Prefixes: 'ncp15wb473', 'ncp18wb473', 'ncp21wb473', 'ncp03wb473',
'ncp15wl333'
Datasheet: Publicly available at Murata
@@ -15,9 +15,9 @@ Authors:
Description
---
-The NTC thermistor is a simple thermistor that requires users to provide the
-resistance and lookup the corresponding compensation table to get the
-temperature input.
+The NTC (Negative Temperature Coefficient) thermistor is a simple thermistor
+that requires users to provide the resistance and lookup the corresponding
+compensation table to get the temperature input.
The NTC driver provides lookup tables with a linear approximation function
and four circuit models with an option not to use any of the four models.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 08531a1..154851b 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1052,7 +1052,7 @@ config SENSORS_PC87427
will be called pc87427.
config
Re: [PATCH 3/4] ARM: DTS: use new compatible string as per the documentation
Hello Mark,
On 24 June 2014 19:03, Mark Rutland mark.rutl...@arm.com wrote:
On Tue, Jun 24, 2014 at 01:19:15PM +0100, Naveen Krishna Chatradhi wrote:
As Murata is the Manufactures the NTC thermistors. The vendor
name in the compatibility is preposed to change to murata, ncpXXX
This patch uses the new compatibility string in exynos4412 based
Trats2 board.
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Chanwoo Choi cw00.c...@samsung.com
---
1. Updates the thermistor node in Exynos4412 based Trats2 dts
using the new DT bindings for NTC thermistors updated with vendor-prefix
arch/arm/boot/dts/exynos4412-trats2.dts |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 11967f4..d35755a 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -771,7 +771,7 @@
};
thermistor-ap@0 {
- compatible = ntc,ncp15wb473;
+ compatible = murata,ncp15wb473;
So the previous patch woul have broken this board?
Will keep the deprecated binding. But, still change here.
As, this is the only board currently using the NTC thermistors.
Mark.
pullup-uv = 180; /* VCC_1.8V_AP */
pullup-ohm = 10; /* 100K */
pulldown-ohm = 10; /* 100K */
@@ -779,7 +779,7 @@
};
thermistor-battery@1 {
- compatible = ntc,ncp15wb473;
+ compatible = murata,ncp15wb473;
pullup-uv = 180; /* VCC_1.8V_AP */
pullup-ohm = 10; /* 100K */
pulldown-ohm = 10; /* 100K */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Shine bright,
(: Nav :)
--
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: MMC error on Exynos4210 board
Sure thing. I'll try to get it sent out later today. -Tim On Tue, Jun 24, 2014 at 4:11 AM, Ulf Hansson ulf.hans...@linaro.org wrote: On 23 juni 2014 06:30:08 CEST, Sachin Kamat spk.li...@gmail.com wrote: Hi Tim, On Sat, Jun 21, 2014 at 2:31 AM, Tim Kryger tim.kry...@gmail.com wrote: On Thu, Jun 19, 2014 at 8:33 PM, Sachin Kamat spk.li...@gmail.com wrote: On Thu, Jun 19, 2014 at 6:11 PM, Jaehoon Chung jh80.ch...@samsung.com wrote: On 06/19/2014 07:40 PM, Sachin Kamat wrote: On Thu, Jun 19, 2014 at 2:40 PM, Tim Kryger tim.kry...@gmail.com wrote: On Thu, Jun 19, 2014 at 1:49 AM, Sachin Kamat spk.li...@gmail.com wrote: On Thu, Jun 19, 2014 at 2:12 PM, Tim Kryger tim.kry...@gmail.com wrote: On Wed, Jun 18, 2014 at 8:54 PM, Sachin Kamat spk.li...@gmail.com wrote: On Wed, Jun 18, 2014 at 4:33 AM, Sachin Kamat spk.li...@gmail.com wrote: I see the below error on Exynos4210 based Origen board with linux-next (20140618). Reverting the below commit works fine. Commit: 8d02e775a6 mmc: sdhci: Use mmc core regulator infrastucture -- [2.068992] sdhci: Secure Digital Host Controller Interface driver [2.075059] sdhci: Copyright(c) Pierre Ossman [2.079762] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1251[0]' [2.088021] s3c-sdhci 1251.sdhci: clock source 2: mmc_busclk.2 (5000 Hz) [2.095322] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1251[0]' [2.103794] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1251[0]' [2.112478] s3c-sdhci 1251.sdhci: No vqmmc regulator found [2.118117] mmc0: Hardware doesn't report any support voltages. [2.124004] s3c-sdhci 1251.sdhci: sdhci_add_host() failed [2.130080] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1253[0]' [2.138352] s3c-sdhci 1253.sdhci: clock source 2: mmc_busclk.2 (1667 Hz) [2.145661] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1253[0]' [2.154139] of_get_named_gpiod_flags: can't parse gpios property of node '/sdhci@1253[0]' [2.162834] s3c-sdhci 1253.sdhci: No vqmmc regulator found [2.168464] mmc0: Hardware doesn't report any support voltages. [2.174349] s3c-sdhci 1253.sdhci: sdhci_add_host() failed [2.336148] Waiting for root device /dev/mmcblk0p1... FYI, the board has a 2.8V fixed regulator supply connected to the MMC. You may refer to arch/arm/boot/dts/exynos4210-origen.dts for more details. A 2.8v regulator results in mmc-ocr_avail being set to MMC_VDD_27_28 | MMC_VDD_28_29. The SDHCI capabilities register only indicates support of three voltage levels - 1.8v: SDHCI_CAN_VDD_180 = MMC_VDD_165_195 - 3.0v: SDHCI_CAN_VDD_300 = MMC_VDD_29_30 | MMC_VDD_30_31 - 3.3v: SDHCI_CAN_VDD_330 = MMC_VDD_32_33 | MMC_VDD_33_34 Right. sdhci capabilities only indicated them. But I think SoC can be support the specific VDD range. Even if all capability bits of the host controller were set, there still wouldn't be any overlap. Thus you see a Hardware doesn't report any support voltages message. Previously, this issue was being swept under the rug by cec2e21 mmc: sdhci: Use regulator min/max voltage range according to spec. That change hacked up the voltage range checks such that with your 2.8v fixed regulator, the driver would believe the host could support MMC_VDD_29_30 | MMC_VDD_30_31 | MMC_VDD_32_33 | MMC_VDD_33_34. The driver would start down the path of commanding 3.3v-3.4v (the highest voltage range believed to be supported). At the last second, the driver would see the regulator was fixed and blindly skip over the set voltage operation, saving it from failure. Since my patch eliminates the bogus voltage range checks, your board is now getting caught playing too loose with the SDHCI regulator voltages. Furthermore, the fixed regulator special-case logic that helped hide your issue should also be considered for removal given that fixed regulators now behave properly thanks to c00dc35 regulator: core: Allow regulator_set_voltage for fixed regulators. Thanks for the detailed explanation. What do you propose to get this fixed It would be nice if the driver could be extended to handle the peculiarities of your board in a deliberate manner but limiting the common sdhci driver to supporting only the three voltages from the spec also seems sensible. Until such time that the driver gets fixed to handle 2.8V fixed supply your current patch leaves several of Exynos boards broken for now. the all of exynos used the fixed-regulator(2.8v) should be broken. (Maybe exynos4 series??) Probably. I haven't verified for the other boards. Hence would be good to handle this case in the driver itself. The current external VDD regulator support in the SDHCI driver feels a bit tacked on. External regulators could reasonably support other voltage ranges, like
[PATCH 0/6] Various Samsung fixes for v3.16-rc3
This series inteds to fix various issues spotted while testing v3.16-rc2. The patches should be reasonably independent from each other and so could be picked to respective trees. See descriptions of individual patches for more information. Tested on Exynos4412-based Trats2 and Exynos4210-based Trats boards. AFAIK there is no need to backport those fixes to stable. Tomasz Figa (6): mmc: sdhci-s3c: Fix local I/O clock gating ARM: EXYNOS: Fix core ID used by platsmp and hotplug code clk: samsung: exynos4: Remove SRC_MASK_ISP gates ARM: SAMSUNG: Restore Samsung PM Debug functionality ARM: EXYNOS: Fix suspend/resume sequencies ARM: EXYNOS: Register cpuidle device only on Exynos4210 and 5250 arch/arm/mach-exynos/exynos.c | 6 ++ arch/arm/mach-exynos/hotplug.c| 10 ++ arch/arm/mach-exynos/platsmp.c| 34 +++--- arch/arm/mach-exynos/pm.c | 20 arch/arm/plat-samsung/Kconfig | 8 +++- arch/arm/plat-samsung/pm-debug.c | 1 + drivers/clk/samsung/clk-exynos4.c | 16 drivers/mmc/host/sdhci-s3c.c | 17 ++--- 8 files changed, 53 insertions(+), 59 deletions(-) -- 1.9.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 4/6] ARM: SAMSUNG: Restore Samsung PM Debug functionality
Due to recently merged patches and previous merge conflicts, the Samsung PM Debug functionality no longer can be enabled. This patch fixes incorrect dependency of SAMSUNG_PM_DEBUG on an integer symbol and adds missing header inclusion. Signed-off-by: Tomasz Figa t.f...@samsung.com --- arch/arm/plat-samsung/Kconfig| 8 +++- arch/arm/plat-samsung/pm-debug.c | 1 + 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/arch/arm/plat-samsung/Kconfig b/arch/arm/plat-samsung/Kconfig index 301b892..483c959 100644 --- a/arch/arm/plat-samsung/Kconfig +++ b/arch/arm/plat-samsung/Kconfig @@ -412,9 +412,14 @@ config S5P_DEV_MFC comment Power management +config HAVE_SAMSUNG_PM_DEBUG + bool + help + Allow compilation of Samsung PM debugging code. + config SAMSUNG_PM_DEBUG bool S3C2410 PM Suspend debug - depends on PM DEBUG_KERNEL DEBUG_S3C_UART + depends on PM DEBUG_KERNEL HAVE_SAMSUNG_PM_DEBUG help Say Y here if you want verbose debugging from the PM Suspend and Resume code. See file:Documentation/arm/Samsung-S3C24XX/Suspend.txt @@ -484,6 +489,7 @@ config S5P_SLEEP config DEBUG_S3C_UART depends on PLAT_SAMSUNG + select HAVE_SAMSUNG_PM_DEBUG int default 0 if DEBUG_S3C_UART0 default 1 if DEBUG_S3C_UART1 diff --git a/arch/arm/plat-samsung/pm-debug.c b/arch/arm/plat-samsung/pm-debug.c index 8f19f66..3960960 100644 --- a/arch/arm/plat-samsung/pm-debug.c +++ b/arch/arm/plat-samsung/pm-debug.c @@ -14,6 +14,7 @@ */ #include linux/serial_core.h +#include linux/serial_s3c.h #include linux/io.h #include asm/mach/map.h -- 1.9.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 1/6] mmc: sdhci-s3c: Fix local I/O clock gating
For internal card detection mechanism it is required that the local I/O
clock is always running. However while current implementation accounts
for this, it does so incorrectly leading to race conditions and warnings
about unbalanced clock disables.
This patch fixes it by inverting the logic, which now increases local
I/O clock enable count when internal card detect is used, instead of
decreasing it otherwise.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Chris Ball ch...@printf.net
Cc: Ulf Hansson ulf.hans...@linaro.org
Cc: linux-...@vger.kernel.org
---
drivers/mmc/host/sdhci-s3c.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index fa5954a..1795e1f 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -487,8 +487,13 @@ static int sdhci_s3c_probe(struct platform_device *pdev)
goto err_pdata_io_clk;
}
- /* enable the local io clock and keep it running for the moment. */
- clk_prepare_enable(sc-clk_io);
+ /*
+* Keep local I/O clock enabled for internal card detect pin
+* or runtime PM is disabled.
+*/
+ if (pdata-cd_type == S3C_SDHCI_CD_INTERNAL
+ || !IS_ENABLED(CONFIG_PM_RUNTIME))
+ clk_prepare_enable(sc-clk_io);
for (clks = 0, ptr = 0; ptr MAX_BUS_CLK; ptr++) {
char name[14];
@@ -611,15 +616,13 @@ static int sdhci_s3c_probe(struct platform_device *pdev)
goto err_req_regs;
}
-#ifdef CONFIG_PM_RUNTIME
- if (pdata-cd_type != S3C_SDHCI_CD_INTERNAL)
- clk_disable_unprepare(sc-clk_io);
-#endif
return 0;
err_req_regs:
err_no_busclks:
- clk_disable_unprepare(sc-clk_io);
+ if (pdata-cd_type == S3C_SDHCI_CD_INTERNAL
+ || !IS_ENABLED(CONFIG_PM_RUNTIME))
+ clk_disable_unprepare(sc-clk_io);
err_pdata_io_clk:
sdhci_free_host(host);
--
1.9.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 6/6] ARM: EXYNOS: Register cpuidle device only on Exynos4210 and 5250
Currently, the Exynos cpuidle driver works correctly only on Exynos4210
and 5250. Trying to use it with just one CPU online on any other Exynos
SoC will lead to system failure, due to unsupported AFTR mode on other
SoCs. This patch fixes the problem by registering the driver only on
supported SoCs and letting others simply use default WFI mode until
support for them is added.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/mach-exynos/exynos.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index f38cf7c..176bbf5 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -173,10 +173,8 @@ static struct platform_device exynos_cpuidle = {
void __init exynos_cpuidle_init(void)
{
- if (soc_is_exynos5440())
- return;
-
- platform_device_register(exynos_cpuidle);
+ if (soc_is_exynos4210() || soc_is_exynos5250())
+ platform_device_register(exynos_cpuidle);
}
void __init exynos_cpufreq_init(void)
--
1.9.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 5/6] ARM: EXYNOS: Fix suspend/resume sequencies
Due to recent consolidation of Exynos suspend and cpuidle code, some
parts of suspend and resume sequences are executed two times, once from
exynos_pm_syscore_ops and then from exynos_cpu_pm_notifier() and thus it
breaks suspend, at least on Exynos4-based boards.
This patch fixes the issue by removing exynos_pm_syscore_ops completely
and making the code rely only on CPU PM notifier.
Tested on Exynos4210-based Trats board.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/mach-exynos/pm.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 87c0d34..98d4926 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -364,11 +364,6 @@ early_wakeup:
return;
}
-static struct syscore_ops exynos_pm_syscore_ops = {
- .suspend= exynos_pm_suspend,
- .resume = exynos_pm_resume,
-};
-
/*
* Suspend Ops
*/
@@ -438,19 +433,13 @@ static int exynos_cpu_pm_notifier(struct notifier_block
*self,
switch (cmd) {
case CPU_PM_ENTER:
- if (cpu == 0) {
- exynos_pm_central_suspend();
- exynos_cpu_save_register();
- }
+ if (cpu == 0)
+ exynos_pm_suspend();
break;
case CPU_PM_EXIT:
- if (cpu == 0) {
- if (!soc_is_exynos5250())
- scu_enable(S5P_VA_SCU);
- exynos_cpu_restore_register();
- exynos_pm_central_resume();
- }
+ if (cpu == 0)
+ exynos_pm_resume();
break;
}
@@ -475,6 +464,5 @@ void __init exynos_pm_init(void)
tmp |= ((0xFF 8) | (0x1F 1));
__raw_writel(tmp, S5P_WAKEUP_MASK);
- register_syscore_ops(exynos_pm_syscore_ops);
suspend_set_ops(exynos_suspend_ops);
}
--
1.9.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 3/6] clk: samsung: exynos4: Remove SRC_MASK_ISP gates
ISP special clocks have dedicated gating registers and so MUX SRC_MASK
register should not be used. This patch fixes the problem of
Exynos4x12-based boards freezing on system suspend, because those
mux outputs need not to be masked while suspending.
Signed-off-by: Tomasz Figa t.f...@samsung.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/samsung/clk-exynos4.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index 4f150c9..7f4a473 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -925,21 +925,13 @@ static struct samsung_gate_clock exynos4x12_gate_clks[]
__initdata = {
GATE(CLK_RTC, rtc, aclk100, E4X12_GATE_IP_PERIR, 15,
0, 0),
GATE(CLK_KEYIF, keyif, aclk100, E4X12_GATE_IP_PERIR, 16, 0, 0),
- GATE(CLK_SCLK_PWM_ISP, sclk_pwm_isp, div_pwm_isp,
- E4X12_SRC_MASK_ISP, 0, CLK_SET_RATE_PARENT, 0),
- GATE(CLK_SCLK_SPI0_ISP, sclk_spi0_isp, div_spi0_isp_pre,
- E4X12_SRC_MASK_ISP, 4, CLK_SET_RATE_PARENT, 0),
- GATE(CLK_SCLK_SPI1_ISP, sclk_spi1_isp, div_spi1_isp_pre,
- E4X12_SRC_MASK_ISP, 8, CLK_SET_RATE_PARENT, 0),
- GATE(CLK_SCLK_UART_ISP, sclk_uart_isp, div_uart_isp,
- E4X12_SRC_MASK_ISP, 12, CLK_SET_RATE_PARENT, 0),
- GATE(CLK_PWM_ISP_SCLK, pwm_isp_sclk, sclk_pwm_isp,
+ GATE(CLK_PWM_ISP_SCLK, pwm_isp_sclk, div_pwm_isp,
E4X12_GATE_IP_ISP, 0, 0, 0),
- GATE(CLK_SPI0_ISP_SCLK, spi0_isp_sclk, sclk_spi0_isp,
+ GATE(CLK_SPI0_ISP_SCLK, spi0_isp_sclk, div_spi0_isp_pre,
E4X12_GATE_IP_ISP, 1, 0, 0),
- GATE(CLK_SPI1_ISP_SCLK, spi1_isp_sclk, sclk_spi1_isp,
+ GATE(CLK_SPI1_ISP_SCLK, spi1_isp_sclk, div_spi1_isp_pre,
E4X12_GATE_IP_ISP, 2, 0, 0),
- GATE(CLK_UART_ISP_SCLK, uart_isp_sclk, sclk_uart_isp,
+ GATE(CLK_UART_ISP_SCLK, uart_isp_sclk, div_uart_isp,
E4X12_GATE_IP_ISP, 3, 0, 0),
GATE(CLK_WDT, watchdog, aclk100, E4X12_GATE_IP_PERIR, 14, 0, 0),
GATE(CLK_PCM0, pcm0, aclk100, E4X12_GATE_IP_MAUDIO, 2,
--
1.9.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 2/6] ARM: EXYNOS: Fix core ID used by platsmp and hotplug code
When CPU topology is specified in device tree, cpu_logical_map() does
not return core ID anymore, but rather full MPIDR value. This breaks
existing calculation of PMU register offsets on Exynos SoCs.
This patch fixes the problem by adjusting the code to use only core ID
bits of the value returned by cpu_logical_map() to allow CPU topology to
be specified in device tree on Exynos SoCs.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/mach-exynos/hotplug.c | 10 ++
arch/arm/mach-exynos/platsmp.c | 34 +++---
2 files changed, 25 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-exynos/hotplug.c b/arch/arm/mach-exynos/hotplug.c
index 69fa483..5644dac 100644
--- a/arch/arm/mach-exynos/hotplug.c
+++ b/arch/arm/mach-exynos/hotplug.c
@@ -40,11 +40,13 @@ static inline void cpu_leave_lowpower(void)
static inline void platform_do_lowpower(unsigned int cpu, int *spurious)
{
+ u32 mpidr = cpu_logical_map(cpu);
+ u32 core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+
for (;;) {
- /* make cpu1 to be turned off at next WFI command */
- if (cpu == 1)
- exynos_cpu_power_down(cpu);
+ /* Turn the CPU off on next WFI instruction. */
+ exynos_cpu_power_down(core_id);
/*
* here's the WFI
@@ -54,7 +56,7 @@ static inline void platform_do_lowpower(unsigned int cpu, int
*spurious)
:
: memory, cc);
- if (pen_release == cpu_logical_map(cpu)) {
+ if (pen_release == core_id) {
/*
* OK, proper wakeup, we're done
*/
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 1c8d31e..50b9aad 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -90,7 +90,8 @@ static void exynos_secondary_init(unsigned int cpu)
static int exynos_boot_secondary(unsigned int cpu, struct task_struct *idle)
{
unsigned long timeout;
- unsigned long phys_cpu = cpu_logical_map(cpu);
+ u32 mpidr = cpu_logical_map(cpu);
+ u32 core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
int ret = -ENOSYS;
/*
@@ -104,17 +105,18 @@ static int exynos_boot_secondary(unsigned int cpu, struct
task_struct *idle)
* the holding pen - release it, then wait for it to flag
* that it has been released by resetting pen_release.
*
-* Note that pen_release is the hardware CPU ID, whereas
+* Note that pen_release is the hardware CPU core ID, whereas
* cpu is Linux's internal ID.
*/
- write_pen_release(phys_cpu);
+ write_pen_release(core_id);
- if (!exynos_cpu_power_state(cpu)) {
- exynos_cpu_power_up(cpu);
+ if (!exynos_cpu_power_state(core_id)) {
+ exynos_cpu_power_up(core_id);
timeout = 10;
/* wait max 10 ms until cpu1 is on */
- while (exynos_cpu_power_state(cpu) != S5P_CORE_LOCAL_PWR_EN) {
+ while (exynos_cpu_power_state(core_id)
+ != S5P_CORE_LOCAL_PWR_EN) {
if (timeout-- == 0)
break;
@@ -145,20 +147,20 @@ static int exynos_boot_secondary(unsigned int cpu, struct
task_struct *idle)
* Try to set boot address using firmware first
* and fall back to boot register if it fails.
*/
- ret = call_firmware_op(set_cpu_boot_addr, phys_cpu, boot_addr);
+ ret = call_firmware_op(set_cpu_boot_addr, core_id, boot_addr);
if (ret ret != -ENOSYS)
goto fail;
if (ret == -ENOSYS) {
- void __iomem *boot_reg = cpu_boot_reg(phys_cpu);
+ void __iomem *boot_reg = cpu_boot_reg(core_id);
if (IS_ERR(boot_reg)) {
ret = PTR_ERR(boot_reg);
goto fail;
}
- __raw_writel(boot_addr, cpu_boot_reg(phys_cpu));
+ __raw_writel(boot_addr, cpu_boot_reg(core_id));
}
- call_firmware_op(cpu_boot, phys_cpu);
+ call_firmware_op(cpu_boot, core_id);
arch_send_wakeup_ipi_mask(cpumask_of(cpu));
@@ -227,22 +229,24 @@ static void __init exynos_smp_prepare_cpus(unsigned int
max_cpus)
* boot register if it fails.
*/
for (i = 1; i max_cpus; ++i) {
- unsigned long phys_cpu;
unsigned long boot_addr;
+ u32 mpidr;
+ u32 core_id;
int ret;
- phys_cpu = cpu_logical_map(i);
+ mpidr = cpu_logical_map(i);
+ core_id = MPIDR_AFFINITY_LEVEL(mpidr,
Re: [PATCH] drm/exynos: Support DP CLKCON register in FIMD driver
On 06/24/2014 03:14 PM, Ajay kumar wrote:
On Tue, Jun 24, 2014 at 9:01 AM, Andrzej Hajda a.ha...@samsung.com wrote:
Hi Ajay,
On 06/24/2014 01:09 PM, Ajay Kumar wrote:
Add the missing setting for DP CLKCON register.
This register is present on Exynos5 based FIMD controllers,
and needs to be used if we are using DP.
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |5 +
include/video/samsung_fimd.h |4
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 33161ad..5d3045d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -72,6 +72,7 @@ struct fimd_driver_data {
unsigned int has_shadowcon:1;
unsigned int has_clksel:1;
unsigned int has_limited_fmt:1;
+ unsigned int has_dp_clkcon:1;
};
static struct fimd_driver_data s3c64xx_fimd_driver_data = {
@@ -88,6 +89,7 @@ static struct fimd_driver_data exynos4_fimd_driver_data =
{
static struct fimd_driver_data exynos5_fimd_driver_data = {
.timing_base = 0x2,
.has_shadowcon = 1,
+ .has_dp_clkcon = 1,
};
struct fimd_win_data {
@@ -331,6 +333,9 @@ static void fimd_commit(struct exynos_drm_manager *mgr)
if (clkdiv 1)
val |= VIDCON0_CLKVAL_F(clkdiv - 1) | VIDCON0_CLKDIR;
+ if (ctx-driver_data-has_dp_clkcon)
+ writel(DP_CLK_ENABLE, ctx-regs + DP_CLKCON);
+
This code always enables the clock on exynos5. As I understand it should
be enabled only if DP is used.
Right!
But, when I searched for the display interface,
only exynos4 based boards use MIPI/DPI, and all exynos5 based boards use DP.
So, I thought adding this in driver_data for exynos5 should be fine.
Arndale and Arndale-Octa have MIPI/DSI interface with MIPI/LVDS bridge.
Inki/Andrej - Shall I add it as an optional DT property?
No, property is redundant. The simplest solution could be to use
CONFIG_DRM_EXYNOS_DP
macro but it is quite ugly.
I guess extending little bit exynos_drm framework to allow detection of
DP in fimd would be better.
Regards
Andrzej
Ajay
writel(val, ctx-regs + VIDCON0);
}
diff --git a/include/video/samsung_fimd.h b/include/video/samsung_fimd.h
index b039320..d8f4b0b 100644
--- a/include/video/samsung_fimd.h
+++ b/include/video/samsung_fimd.h
@@ -435,6 +435,10 @@
#define BLENDCON_NEW_8BIT_ALPHA_VALUE(1 0)
#define BLENDCON_NEW_4BIT_ALPHA_VALUE(0 0)
+/* Video clock enable for DP */
+#define DP_CLKCON0x27C
+#define DP_CLK_ENABLE0x2
+
/* Notes on per-window bpp settings
*
* Value Win0 Win1 Win2 Win3 Win 4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5 v2] drm/exynos: allow mulitple layer updates per vsync for mixer
2014-06-24 20:38 GMT+09:00 Andreas Färber afaer...@suse.de:
Am 24.06.2014 07:21, schrieb Inki Dae:
On 2014년 06월 23일 14:32, Rahul Sharma wrote:
Allowing only one layer update per vsync can cause issues
while there are update available for both layers. There is
a good amount of possibility to loose updates if we allow
single update per vsync.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/gpu/drm/exynos/exynos_mixer.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index d359501..6773b03 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -511,13 +511,8 @@ static void vp_video_buffer(struct mixer_context *ctx,
int win)
static void mixer_layer_update(struct mixer_context *ctx)
{
struct mixer_resources *res = ctx-mixer_res;
-u32 val;
-
-val = mixer_reg_read(res, MXR_CFG);
-/* allow one update per vsync only */
-if (!(val MXR_CFG_LAYER_UPDATE_COUNT_MASK))
-mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
+mixer_reg_writemask(res, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
Rahul, it looks good to me and ok as is. But above codes don't consider
Exynos4 series. In case of Exynos4xxx SoC,
MXR_CFG_LAYER_UPDATE_COUNT_MASK and MXR_CFG_LAYER_UPDATE of MIXER_CFG
register are reserved fields. So can you work that patch to be
considered for Exynos4xxx SoC? That patch would be additional one.
Anyway, will apply it as is, and I will wait for the additional patch.
If it's not too late, could you fix up multiple in the subject? :)
Corrected. :)
Thanks,
Inki Dae
Cheers,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
--
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: [RFC 4/4] ARM: dts: exynos5250: Add Spring device tree
Re-sending ... the text-only encoding was not properly turned on on
the previous one and irritated the mailing lists.
On Mon, Jun 23, 2014 at 9:05 PM, Doug Anderson diand...@chromium.org wrote:
Andreas,
On Mon, Jun 23, 2014 at 3:46 PM, Andreas Färber afaer...@suse.de wrote:
Hi Doug,
Am 23.06.2014 21:47, schrieb Doug Anderson:
Thanks for posting! A first pass on this is below...
Thanks a lot for your quick review! My first big .dts patch, and no
datasheets for the hardware at hand as a user.
A first pass of replies to my defense. ;)
On Sun, Jun 22, 2014 at 6:21 PM, Andreas Färber afaer...@suse.de wrote:
[...]
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
b/arch/arm/boot/dts/exynos5250-spring.dts
new file mode 100644
index 000..e857d44
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -0,0 +1,556 @@
+/*
+ * Google Spring board device tree source
+ *
+ * Copyright (c) 2013 Google, Inc
+ * Copyright (c) 2014 SUSE LINUX Products GmbH
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include exynos5250.dtsi
+#include exynos5250-cros-common.dtsi
It is possible we may want to backpedal on the use of
exynos5250-cros-common.dtsi. I know that Olof (now CCed) said he
wasn't a fan of how it turned out.
The original idea was that it should include the arbitrary set of
things that are common between a chunk of Chrome OS boards. As more
boards were introduced things would need to migrate from the common
file to the board files.
At the moment the current conventional wisdom is that some duplication
is better than the confusing movement of everything back and forth.
See exynos5420-peach-pit and exynos5800-peach-pi in ToT linux-next.
+/ {
+ model = Google Spring;
+ compatible = google,spring, samsung,exynos5250,
samsung,exynos5;
+
+ pinctrl@1140 {
The new best way to do things is to put this down at the bottom. See
exynos5420-peach-pit as an example:
pinctrl_0 {
...
}
Note that I believe it was decided that top-level references like that
should be sorted alphabetically.
Thanks for the hint. (My chosen sort order here was by address.)
If you wanted to apply that run to exynos5250-snow I don't think it
would be a terrible idea.
I can of course apply changes to Snow, but I cannot test them myself.
If you want to send up a patch like that I'm happy to give it a once
over and also to test it. ...but don't feel obligated
+ s5m8767_dvs: s5m8767-dvs {
+ samsung,pins = gpd1-0, gpd1-1, gpd1-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+
+ s5m8767_ds: s5m8767-ds {
+ samsung,pins = gpx2-3, gpx2-4, gpx2-5;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+
+ tps65090_irq: tps65090-irq {
+ samsung,pins = gpx2-6;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ s5m8767_irq: s5m8767-irq {
+ samsung,pins = gpx3-2;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ hdmi_hpd_irq: hdmi-hpd-irq {
+ samsung,pins = gpx3-7;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+ };
+
+ pinctrl@1340 {
+ hsic_reset: hsic-reset {
+ samsung,pins = gpe1-0;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
I'm pretty sure that the HSIC reset needed some funky code to make it
work and I'm not sure what the status of that is upstream
Yeah, you mentioned something along those lines. However it's the
equivalent of the usb3-vbus-en in -snow.dts. Rename or drop?
It's clearly not equivalent, usb3-vbus-en just turns on/off the load
switch for VBUS
while the HSIC chip (USB3503) is an external PHY (and hub) for the
USB2 port, the reset of the PHY side of the HSIC needs to be done
within the proper timing window compared to the SoC HSIC controller to
get a working link.
As the current kernel has a binding for the SMSC
Re: [PATCH] phy: phy-samsung-usb2: Change phy power on/power off sequence
On Tue, Jun 24, 2014 at 1:54 PM, Kamil Debski k.deb...@samsung.com wrote: The Exynos4412 USB 2.0 PHY hardware differs from the description provided in the documentation. Some register bits have different function. This patch fixes the defines of register bits and changes the way how phys are powered on and off. I guess this replaces the patch titled drivers: phy: exynos4x12-phy: fix HSIC1 power on/off sequence Tested on ODROID-U2. Seems to be working as well as the previous patch: - Internal SMSC hub works on boot and after reboot, tested with USB mouse - Internal SMSC ethernet device works on boot, but disappears upon reboot. (same as previous patch, also reproduced by Marek) Thanks, Daniel -- 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: [RFC 4/4] ARM: dts: exynos5250: Add Spring device tree
Javier, On Tue, Jun 24, 2014 at 3:06 AM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: Hello Doug, On 06/24/2014 06:05 AM, Doug Anderson wrote: Another option is to identify DTS fragments that are common across boards and create .dtsi files for these specific chunks instead of trying to group all set of common things on a single .dtsi file. For example, a quite common design for OMAP2+ based boards is to use a SMSC LAN chip connected to OMAP's General-Purpose Memory Controller (GPMC). So the following files were created to reduce DTS duplication: arch/arm/boot/dts/omap-gpmc-smsc911x.dtsi arch/arm/boot/dts/omap-gpmc-smsc9221.dtsi Now that I think about it, is the same that what you did for arm/boot/dts/cros-ec-keyboard.dtsi. Maybe splitting exynos5250-cros-common.dtsi in a set of .dtsi files will make it more flexible/reusable? Yes, I think the config fragments can be cleaner but I think we have to be judicious about using them. There are definitely tradeoffs involved. The keyboard was such an excessively large thing and totally duplicated, so moving it out made sense. Other bits are less obvious (to me) because there are so many interactions / combinations and you end up with a bit of spaghetti in terms of which labels are used by and provided by each fragment. I guess possibly you could codify that better... A few thoughts looking at exynos5420-peach-pit: * backlight: seems (?) too board specific * samsung,exynos5420-oscclk: could totally be a fragment, but very small. * power key: could be a fragment for all boards that happen to use gpx1-2 for this * sound: could be a fragment for all devices using google,snow-audio-max98090, possibly. Personally I think that status = [enabled | disabled] only makes sense for IP blocks that are part of the SoC but may or may not be used by a board (e.g: i2c and spi buses, sdhci and usb host controllers, etc). DTS should be a description of the hardware so I agree that having a disabled node for a device that is not present in the board is not right. Right. We'll take a look again in v2 when cros-common isn't used. I think this could go in steps: 1. Don't use cros-common for spring 2. Don't use cros-common for snow (fold stuff in) 3. Introduce some fragments. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] ARM: EXYNOS: Fix suspend/resume sequencies
Hi Tomasz,
On Tue, Jun 24, 2014 at 7:27 PM, Tomasz Figa t.f...@samsung.com wrote:
Due to recent consolidation of Exynos suspend and cpuidle code, some
parts of suspend and resume sequences are executed two times, once from
exynos_pm_syscore_ops and then from exynos_cpu_pm_notifier() and thus it
breaks suspend, at least on Exynos4-based boards.
This patch fixes the issue by removing exynos_pm_syscore_ops completely
and making the code rely only on CPU PM notifier.
Tested on Exynos4210-based Trats board.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/mach-exynos/pm.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
A patch from me has recently gone in which converts the soc_is checks
for A9 specific registers to the A9 part number. This patch will
probably have to be rebased atop it.
Regards,
Abhilash
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 87c0d34..98d4926 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -364,11 +364,6 @@ early_wakeup:
return;
}
-static struct syscore_ops exynos_pm_syscore_ops = {
- .suspend= exynos_pm_suspend,
- .resume = exynos_pm_resume,
-};
-
/*
* Suspend Ops
*/
@@ -438,19 +433,13 @@ static int exynos_cpu_pm_notifier(struct notifier_block
*self,
switch (cmd) {
case CPU_PM_ENTER:
- if (cpu == 0) {
- exynos_pm_central_suspend();
- exynos_cpu_save_register();
- }
+ if (cpu == 0)
+ exynos_pm_suspend();
break;
case CPU_PM_EXIT:
- if (cpu == 0) {
- if (!soc_is_exynos5250())
- scu_enable(S5P_VA_SCU);
- exynos_cpu_restore_register();
- exynos_pm_central_resume();
- }
+ if (cpu == 0)
+ exynos_pm_resume();
break;
}
@@ -475,6 +464,5 @@ void __init exynos_pm_init(void)
tmp |= ((0xFF 8) | (0x1F 1));
__raw_writel(tmp, S5P_WAKEUP_MASK);
- register_syscore_ops(exynos_pm_syscore_ops);
suspend_set_ops(exynos_suspend_ops);
}
--
1.9.3
--
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] phy: phy-samsung-usb2: Change phy power on/power off sequence
Hi Daniel, From: Daniel Drake [mailto:dr...@endlessm.com] Sent: Tuesday, June 24, 2014 5:09 PM On Tue, Jun 24, 2014 at 1:54 PM, Kamil Debski k.deb...@samsung.com wrote: The Exynos4412 USB 2.0 PHY hardware differs from the description provided in the documentation. Some register bits have different function. This patch fixes the defines of register bits and changes the way how phys are powered on and off. I guess this replaces the patch titled drivers: phy: exynos4x12-phy: fix HSIC1 power on/off sequence Yes, indeed it replaces this patch. I did some more research on how the hardware actually behaves. Tested on ODROID-U2. Seems to be working as well as the previous patch: Thank you very much for testing. - Internal SMSC hub works on boot and after reboot, tested with USB mouse - Internal SMSC ethernet device works on boot, but disappears upon reboot. (same as previous patch, also reproduced by Marek) By reboot I guess that you mean typing reboot or by using SysRq magic and not power cycling? If so, I had experienced the same symptoms. I guess that the Ethernet chip is not reset properly and fails to enumerate without power cycling (it's nRESET pin is connected to P3V3). I found that removing regulator-always-on from buck8_reg: BUCK8 in the dts file fixes this problem. Best wishes, -- Kamil Debski Samsung RD Institute Poland -- 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 0/3] MCPM: clarify boot CPU situation wrt CCI
Nicolas Pitre nicolas.pi...@linaro.org writes: For the background story, please see: http://news.gmane.org/group/gmane.linux.kernel.samsung-soc/thread=32807 I sat on those patches for a while but they are the best I could think of in terms of implementation. To ease merging I suggest I collect all the ACK's and Tested-by's and submit them all at once to RMK's patch system. Reviewed-by: Kevin Hilman khil...@linaro.org Tested-by: Kevin Hilman khil...@linaro.org I tested this series on Exynos5 Peach Pi (a.k.a. 13 ARM Chromebook 2) and verified all 8 cores are booting up. Kevin P.S. FYI for anyone else wanting to try this on peach-pi, I still need a couple other out of tree clock related patches in order to boot fully. Until the final versions are merged, I'm using these: - Doug's aclk66 clock removal for earlyprintk support http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/262225.html - Leave mau_epll enabled http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/262259.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
[PATCH v2 3/4] clk: samsung: Add driver to control CLKOUT line on Exynos SoCs
This patch introduces a driver that handles configuration of CLKOUT pin
of Exynos SoCs that can be used to output certain clocks from inside of
the SoC to a dedicated output pin.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
.../devicetree/bindings/arm/samsung/pmu.txt| 30
drivers/clk/samsung/Makefile | 1 +
drivers/clk/samsung/clk-exynos-clkout.c| 153 +
3 files changed, 184 insertions(+)
create mode 100644 drivers/clk/samsung/clk-exynos-clkout.c
diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
index 2a4ab04..f9865e7 100644
--- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
@@ -12,8 +12,38 @@ Properties:
- reg : offset and length of the register set.
+ - #clock-cells : must be 1, since PMU requires once cell as clock specifier.
+ The single specifier cell is used as index to list of clocks
+ provided by PMU, which is currently:
+ 0 : SoC clock output (CLKOUT pin)
+
+ - clock-names : list of clock names for particular CLKOUT mux inputs in
+ following format:
+ clkoutN, where N is a decimal number corresponding to
+ CLKOUT mux control bits value for given input, e.g.
+ clkout0, clkout7, clkout15.
+
+ - clocks : list of phandles and specifiers to all input clocks listed in
+ clock-names property.
+
Example :
pmu_system_controller: system-controller@1004 {
compatible = samsung,exynos5250-pmu, syscon;
reg = 0x1004 0x5000;
+ #clock-cells = 1;
+ clock-names = clkout0, clkout1, clkout2, clkout3,
+ clkout4, clkout8, clkout9;
+ clocks = clock CLK_OUT_DMC, clock CLK_OUT_TOP,
+ clock CLK_OUT_LEFTBUS, clock CLK_OUT_RIGHTBUS,
+ clock CLK_OUT_CPU, clock CLK_XXTI,
+ clock CLK_XUSBXTI;
+};
+
+Example of clock consumer :
+
+usb3503: usb3503@08 {
+ /* ... */
+ clock-names = refclk;
+ clocks = pmu_system_controller 0;
+ /* ... */
};
diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile
index 69e8177..2949a55 100644
--- a/drivers/clk/samsung/Makefile
+++ b/drivers/clk/samsung/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_SOC_EXYNOS5410) += clk-exynos5410.o
obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o
obj-$(CONFIG_SOC_EXYNOS5440) += clk-exynos5440.o
obj-$(CONFIG_ARCH_EXYNOS) += clk-exynos-audss.o
+obj-$(CONFIG_ARCH_EXYNOS) += clk-exynos-clkout.o
obj-$(CONFIG_S3C2410_COMMON_CLK)+= clk-s3c2410.o
obj-$(CONFIG_S3C2410_COMMON_DCLK)+= clk-s3c2410-dclk.o
obj-$(CONFIG_S3C2412_COMMON_CLK)+= clk-s3c2412.o
diff --git a/drivers/clk/samsung/clk-exynos-clkout.c
b/drivers/clk/samsung/clk-exynos-clkout.c
new file mode 100644
index 000..3a7cb25
--- /dev/null
+++ b/drivers/clk/samsung/clk-exynos-clkout.c
@@ -0,0 +1,153 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Tomasz Figa t.f...@samsung.com
+ *
+ * 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.
+ *
+ * Clock driver for Exynos clock output
+ */
+
+#include linux/clk.h
+#include linux/clkdev.h
+#include linux/clk-provider.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/syscore_ops.h
+
+#define EXYNOS_CLKOUT_NR_CLKS 1
+#define EXYNOS_CLKOUT_PARENTS 32
+
+#define EXYNOS_PMU_DEBUG_REG 0xa00
+#define EXYNOS_CLKOUT_DISABLE_SHIFT0
+#define EXYNOS_CLKOUT_MUX_SHIFT8
+#define EXYNOS4_CLKOUT_MUX_MASK0xf
+#define EXYNOS5_CLKOUT_MUX_MASK0x1f
+
+struct exynos_clkout {
+ struct clk_gate gate;
+ struct clk_mux mux;
+ spinlock_t slock;
+ struct clk_onecell_data data;
+ struct clk *clk_table[EXYNOS_CLKOUT_NR_CLKS];
+ void __iomem *reg;
+ u32 pmu_debug_save;
+};
+
+static struct exynos_clkout *clkout;
+
+static int exynos_clkout_suspend(void)
+{
+ clkout-pmu_debug_save = readl(clkout-reg + EXYNOS_PMU_DEBUG_REG);
+
+ return 0;
+}
+
+static void exynos_clkout_resume(void)
+{
+ writel(clkout-pmu_debug_save, clkout-reg + EXYNOS_PMU_DEBUG_REG);
+}
+
+static struct syscore_ops exynos_clkout_syscore_ops = {
+ .suspend = exynos_clkout_suspend,
+ .resume = exynos_clkout_resume,
+};
+
+static void __init exynos_clkout_init(struct device_node *node, u32 mux_mask)
+{
+ const char *parent_names[EXYNOS_CLKOUT_PARENTS];
+ struct clk *parents[EXYNOS_CLKOUT_PARENTS];
+ int parent_count;
+ int ret;
+ int i;
+
+ clkout = kzalloc(sizeof(*clkout), GFP_KERNEL);
+ if (!clkout)
+ return;
+
+
[PATCH v2 4/4] ARM: dts: exynos: Update PMU node with CLKOUT related data
This patch extends nodes of PMU system controller on Exynos4210, 4x12,
5250 and 5420 SoCs with newly defined properties used by Exynos CLKOUT
driver.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
arch/arm/boot/dts/exynos4210.dtsi | 10 ++
arch/arm/boot/dts/exynos4x12.dtsi | 7 +++
arch/arm/boot/dts/exynos5250.dtsi | 3 +++
arch/arm/boot/dts/exynos5420.dtsi | 3 +++
4 files changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index ee3001f..97ea7a9 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -31,6 +31,16 @@
pinctrl2 = pinctrl_2;
};
+ pmu_system_controller: system-controller@1002 {
+ clock-names = clkout0, clkout1, clkout2, clkout3,
+ clkout4, clkout8, clkout9;
+ clocks = clock CLK_OUT_DMC, clock CLK_OUT_TOP,
+ clock CLK_OUT_LEFTBUS, clock CLK_OUT_RIGHTBUS,
+ clock CLK_OUT_CPU, clock CLK_XXTI,
+ clock CLK_XUSBXTI;
+ #clock-cells = 1;
+ };
+
sysram@0202 {
compatible = mmio-sram;
reg = 0x0202 0x2;
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index c5a943d..de1f9c7 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -139,6 +139,13 @@
pmu_system_controller: system-controller@1002 {
compatible = samsung,exynos4212-pmu, syscon;
+ clock-names = clkout0, clkout1, clkout2, clkout3,
+ clkout4, clkout8, clkout9;
+ clocks = clock CLK_OUT_DMC, clock CLK_OUT_TOP,
+ clock CLK_OUT_LEFTBUS, clock CLK_OUT_RIGHTBUS,
+ clock CLK_OUT_CPU, clock CLK_XXTI,
+ clock CLK_XUSBXTI;
+ #clock-cells = 1;
};
g2d@1080 {
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi
index 834fb5a..492e1ef 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -191,6 +191,9 @@
pmu_system_controller: system-controller@1004 {
compatible = samsung,exynos5250-pmu, syscon;
reg = 0x1004 0x5000;
+ clock-names = clkout16;
+ clocks = clock CLK_FIN_PLL;
+ #clock-cells = 1;
};
sysreg_system_controller: syscon@1005 {
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index e385322..481beec 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -724,6 +724,9 @@
pmu_system_controller: system-controller@1004 {
compatible = samsung,exynos5420-pmu, syscon;
reg = 0x1004 0x5000;
+ clock-names = clkout16;
+ clocks = clock CLK_FIN_PLL;
+ #clock-cells = 1;
};
sysreg_system_controller: syscon@1005 {
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] clk: samsung: exynos4: Add CLKOUT clock hierarchy
This patch adds definitions of clocks that are used to drive clock
output signals of particular CMU sub-blocks that are then fed to PMU and
handled by Exynos CLKOUT driver added in further patch.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
drivers/clk/samsung/clk-exynos4.c | 116 ++--
include/dt-bindings/clock/exynos4.h | 5 ++
2 files changed, 117 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index f95ae6c..7d1fb99 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -25,10 +25,12 @@
#define DIV_LEFTBUS0x4500
#define GATE_IP_LEFTBUS0x4800
#define E4X12_GATE_IP_IMAGE0x4930
+#define CLKOUT_CMU_LEFTBUS 0x4a00
#define SRC_RIGHTBUS 0x8200
#define DIV_RIGHTBUS 0x8500
#define GATE_IP_RIGHTBUS 0x8800
#define E4X12_GATE_IP_PERIR0x8960
+#define CLKOUT_CMU_RIGHTBUS0x8a00
#define EPLL_LOCK 0xc010
#define VPLL_LOCK 0xc020
#define EPLL_CON0 0xc110
@@ -98,6 +100,7 @@
#define GATE_IP_PERIL 0xc950
#define E4210_GATE_IP_PERIR0xc960
#define GATE_BLOCK 0xc970
+#define CLKOUT_CMU_TOP 0xca00
#define E4X12_MPLL_LOCK0x10008
#define E4X12_MPLL_CON00x10108
#define SRC_DMC0x10200
@@ -105,6 +108,7 @@
#define DIV_DMC0 0x10500
#define DIV_DMC1 0x10504
#define GATE_IP_DMC0x10900
+#define CLKOUT_CMU_DMC 0x10a00
#define APLL_LOCK 0x14000
#define E4210_MPLL_LOCK0x14008
#define APLL_CON0 0x14100
@@ -114,6 +118,7 @@
#define DIV_CPU1 0x14504
#define GATE_SCLK_CPU 0x14800
#define GATE_IP_CPU0x14900
+#define CLKOUT_CMU_CPU 0x14a00
#define E4X12_DIV_ISP0 0x18300
#define E4X12_DIV_ISP1 0x18304
#define E4X12_GATE_ISP00x18800
@@ -242,6 +247,11 @@ static unsigned long exynos4_clk_regs[] __initdata = {
DIV_CPU1,
GATE_SCLK_CPU,
GATE_IP_CPU,
+ CLKOUT_CMU_LEFTBUS,
+ CLKOUT_CMU_RIGHTBUS,
+ CLKOUT_CMU_TOP,
+ CLKOUT_CMU_DMC,
+ CLKOUT_CMU_CPU,
};
static const struct samsung_clk_reg_dump src_mask_suspend[] = {
@@ -400,6 +410,23 @@ PNAME(mout_dac_p4210) = { sclk_vpll,
sclk_hdmiphy, };
PNAME(mout_pwi_p4210) = { xxti, xusbxti, sclk_hdmi24m, sclk_usbphy0,
sclk_usbphy1, sclk_hdmiphy, none,
sclk_epll, sclk_vpll };
+PNAME(clkout_left_p4210) = { sclk_mpll_div_2, sclk_apll_div_2,
+ div_gdl, div_gpl };
+PNAME(clkout_right_p4210) = { sclk_mpll_div_2, sclk_apll_div_2,
+ div_gdr, div_gpr };
+PNAME(clkout_top_p4210) = { fout_epll, fout_vpll, sclk_hdmi24m,
+ sclk_usbphy0, sclk_usbphy1, sclk_hdmiphy,
+ cdclk0, cdclk1, cdclk2, spdif_extclk,
+ aclk160, aclk133, aclk200, aclk100,
+ sclk_mfc, sclk_g3d, sclk_g2d,
+ cam_a_pclk, cam_b_pclk, s_rxbyteclkhs0_2l,
+ s_rxbyteclkhs0_4l };
+PNAME(clkout_dmc_p4210) = { div_dmcd, div_dmcp, div_acp_pclk, div_dmc,
+ div_dphy, none, div_pwi };
+PNAME(clkout_cpu_p4210) = { fout_apll_div_2, none, fout_mpll_div_2,
+ none, arm_clk_div_2, div_corem0,
+ div_corem1, div_corem0, div_atb,
+ div_periph, div_pclk_dbg, div_hpm };
/* Exynos 4x12-specific parent groups */
PNAME(mout_mpll_user_p4x12) = { fin_pll, sclk_mpll, };
@@ -426,6 +453,29 @@ PNAME(mout_user_aclk266_gps_p4x12) = {fin_pll,
div_aclk266_gps, };
PNAME(mout_pwi_p4x12) = { xxti, xusbxti, sclk_hdmi24m, sclk_usbphy0,
none, sclk_hdmiphy, sclk_mpll,
sclk_epll, sclk_vpll };
+PNAME(clkout_left_p4x12) = { sclk_mpll_user_l_div_2, sclk_apll_div_2,
+ div_gdl, div_gpl };
+PNAME(clkout_right_p4x12) = { sclk_mpll_user_r_div_2, sclk_apll_div_2,
+ div_gdr, div_gpr };
+PNAME(clkout_top_p4x12) = { fout_epll, fout_vpll, sclk_hdmi24m,
+ sclk_usbphy0, none, sclk_hdmiphy,
+ cdclk0, cdclk1, cdclk2, spdif_extclk,
+ aclk160, aclk133, aclk200, aclk100,
+ sclk_mfc, sclk_g3d, aclk400_mcuisp,
+ cam_a_pclk, cam_b_pclk, s_rxbyteclkhs0_2l,
+ s_rxbyteclkhs0_4l, rx_half_byte_clk_csis0,
+ rx_half_byte_clk_csis1, div_jpeg,
+ sclk_pwm_isp,
Re: [PATCH 1/3] ARM: MCPM: provide infrastructure to allow for MCPM loopback
Nicolas, On Mon, Jun 23, 2014 at 9:11 PM, Nicolas Pitre nicolas.pi...@linaro.org wrote: The kernel already has the responsibility to handle resources such as the CCI when hotplugging CPUs, during the booting of secondary CPUs, and when resuming from suspend/idle. It would be more coherent and less confusing if the CCI for the boot CPU (or cluster) was also initialized by the kernel rather than expecting the nit: wrap long line? firmware/bootloader to do it and only in that case. After all, the kernel has all the necessary code already and the bootloader shouldn't have to care at all. The CCI may be turned on only when the cache is off. Leveraging the CPU suspend code to loop back through the low-level MCPM entry point is all that is needed to properly turn on the CCI from the kernel by using the same code as for secondary boot. Let's provide a generic MCPM loopback function that can be invoked by backend initialization code to set things (CCI or similar) on the boot CPU just as it is done for the other CPUs. Signed-off-by: Nicolas Pitre n...@linaro.org --- arch/arm/common/mcpm_entry.c | 52 arch/arm/include/asm/mcpm.h | 16 ++ 2 files changed, 68 insertions(+) Thank you very much for posting! With your series I'm able to boot all 8 cores on exynos5420-peach-pit and exynos5800-peach-pi sitting on my desk. Tested-by: Doug Anderson diand...@chromium.org I will note that git yelled about whitespace damage on theis patch: # pwclient git-am 4406301 Applying patch #4406301 using 'git am' Description: [1/3] ARM: MCPM: provide infrastructure to allow for MCPM loopback Applying: ARM: MCPM: provide infrastructure to allow for MCPM loopback /b/tip/src/third_party/kernel/3.8/.git/rebase-apply/patch:51: trailing whitespace. /b/tip/src/third_party/kernel/3.8/.git/rebase-apply/patch:95: trailing whitespace. * to the MCPM low-level entry code before returning to the caller. warning: 2 lines add whitespace errors. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] clk: samsung: exynos4: Add missing CPU/DMC clock hierarchy
This patch adds missing definitions of clocks from CPU and DMC clock
domains, which are necessary to properly represent CLKOUT clock hierarchy
added in further patch.
Signed-off-by: Tomasz Figa t.f...@samsung.com
---
drivers/clk/samsung/clk-exynos4.c | 50 +++
1 file changed, 50 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index 4f150c9..f95ae6c 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -397,10 +397,15 @@ PNAME(mout_audio2_p4210) = { cdclk2, none,
sclk_hdmi24m,
sclk_epll, sclk_vpll, };
PNAME(mout_mixer_p4210)= { sclk_dac, sclk_hdmi, };
PNAME(mout_dac_p4210) = { sclk_vpll, sclk_hdmiphy, };
+PNAME(mout_pwi_p4210) = { xxti, xusbxti, sclk_hdmi24m, sclk_usbphy0,
+ sclk_usbphy1, sclk_hdmiphy, none,
+ sclk_epll, sclk_vpll };
/* Exynos 4x12-specific parent groups */
PNAME(mout_mpll_user_p4x12) = { fin_pll, sclk_mpll, };
PNAME(mout_core_p4x12) = { mout_apll, mout_mpll_user_c, };
+PNAME(mout_gdl_p4x12) = { mout_mpll_user_l, sclk_apll, };
+PNAME(mout_gdr_p4x12) = { mout_mpll_user_r, sclk_apll, };
PNAME(sclk_ampll_p4x12)= { mout_mpll_user_t, sclk_apll, };
PNAME(group1_p4x12)= { xxti, xusbxti, sclk_hdmi24m, sclk_usbphy0,
none, sclk_hdmiphy, mout_mpll_user_t,
@@ -418,6 +423,9 @@ PNAME(aclk_p4412) = { mout_mpll_user_t, sclk_apll, };
PNAME(mout_user_aclk400_mcuisp_p4x12) = {fin_pll, div_aclk400_mcuisp, };
PNAME(mout_user_aclk200_p4x12) = {fin_pll, div_aclk200, };
PNAME(mout_user_aclk266_gps_p4x12) = {fin_pll, div_aclk266_gps, };
+PNAME(mout_pwi_p4x12) = { xxti, xusbxti, sclk_hdmi24m, sclk_usbphy0,
+ none, sclk_hdmiphy, sclk_mpll,
+ sclk_epll, sclk_vpll };
/* fixed rate clocks generated outside the soc */
static struct samsung_fixed_rate_clock exynos4_fixed_rate_ext_clks[]
__initdata = {
@@ -451,6 +459,9 @@ static struct samsung_mux_clock exynos4_mux_clks[]
__initdata = {
MUX(0, mout_onenand1, mout_onenand1_p, SRC_TOP0, 0, 1),
MUX(CLK_SCLK_EPLL, sclk_epll, mout_epll_p, SRC_TOP0, 4, 1),
MUX(0, mout_onenand, mout_onenand_p, SRC_TOP0, 28, 1),
+
+ MUX(0, mout_dmc_bus, sclk_ampll_p4210, SRC_DMC, 4, 1),
+ MUX(0, mout_dphy, sclk_ampll_p4210, SRC_DMC, 8, 1),
};
/* list of mux clocks supported in exynos4210 soc */
@@ -459,6 +470,10 @@ static struct samsung_mux_clock exynos4210_mux_early[]
__initdata = {
};
static struct samsung_mux_clock exynos4210_mux_clks[] __initdata = {
+ MUX(0, mout_gdl, sclk_ampll_p4210, SRC_LEFTBUS, 0, 1),
+
+ MUX(0, mout_gdr, sclk_ampll_p4210, SRC_RIGHTBUS, 0, 1),
+
MUX(0, mout_aclk200, sclk_ampll_p4210, SRC_TOP0, 12, 1),
MUX(0, mout_aclk100, sclk_ampll_p4210, SRC_TOP0, 16, 1),
MUX(0, mout_aclk160, sclk_ampll_p4210, SRC_TOP0, 20, 1),
@@ -472,6 +487,7 @@ static struct samsung_mux_clock exynos4210_mux_clks[]
__initdata = {
MUX(0, mout_mipi1, group1_p4210, E4210_SRC_LCD1, 12, 4),
MUX(CLK_SCLK_MPLL, sclk_mpll, mout_mpll_p, SRC_CPU, 8, 1),
MUX(CLK_MOUT_CORE, mout_core, mout_core_p4210, SRC_CPU, 16, 1),
+ MUX(0, mout_hpm, mout_core_p4210, SRC_CPU, 20, 1),
MUX(CLK_SCLK_VPLL, sclk_vpll, sclk_vpll_p4210, SRC_TOP0, 8, 1),
MUX(CLK_MOUT_FIMC0, mout_fimc0, group1_p4210, SRC_CAM, 0, 4),
MUX(CLK_MOUT_FIMC1, mout_fimc1, group1_p4210, SRC_CAM, 4, 4),
@@ -503,10 +519,18 @@ static struct samsung_mux_clock exynos4210_mux_clks[]
__initdata = {
MUX(0, mout_spi0, group1_p4210, SRC_PERIL1, 16, 4),
MUX(0, mout_spi1, group1_p4210, SRC_PERIL1, 20, 4),
MUX(0, mout_spi2, group1_p4210, SRC_PERIL1, 24, 4),
+
+ MUX(0, mout_pwi, mout_pwi_p4210, SRC_DMC, 16, 4),
};
/* list of mux clocks supported in exynos4x12 soc */
static struct samsung_mux_clock exynos4x12_mux_clks[] __initdata = {
+ MUX(0, mout_mpll_user_l, mout_mpll_p, SRC_LEFTBUS, 4, 1),
+ MUX(0, mout_gdl, mout_gdl_p4x12, SRC_LEFTBUS, 0, 1),
+
+ MUX(0, mout_mpll_user_r, mout_mpll_p, SRC_RIGHTBUS, 4, 1),
+ MUX(0, mout_gdr, mout_gdr_p4x12, SRC_RIGHTBUS, 0, 1),
+
MUX(CLK_MOUT_MPLL_USER_C, mout_mpll_user_c, mout_mpll_user_p4x12,
SRC_CPU, 24, 1),
MUX(0, mout_aclk266_gps, aclk_p4412, SRC_TOP1, 4, 1),
@@ -531,6 +555,7 @@ static struct samsung_mux_clock exynos4x12_mux_clks[]
__initdata = {
MUX(CLK_SCLK_MPLL, sclk_mpll, mout_mpll_p, SRC_DMC, 12, 1),
MUX(CLK_SCLK_VPLL, sclk_vpll, mout_vpll_p, SRC_TOP0, 8, 1),
MUX(CLK_MOUT_CORE, mout_core, mout_core_p4x12, SRC_CPU, 16, 1),
+ MUX(0, mout_hpm, mout_core_p4x12, SRC_CPU, 20, 1),
MUX(CLK_MOUT_FIMC0, mout_fimc0, group1_p4x12, SRC_CAM, 0, 4),
MUX(CLK_MOUT_FIMC1, mout_fimc1, group1_p4x12, SRC_CAM, 4, 4),
Re: [PATCH] arm: exynos: Modify pm code to check for cortex A9 rather than the SoC
On Mon, Jun 16, 2014 at 09:37:14AM +0530, Abhilash Kesavan wrote:
Hi Kukjin,
On Fri, May 23, 2014 at 8:31 AM, Abhilash Kesavan a.kesa...@samsung.com
wrote:
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Do you have any comments on this patch ?
I do.
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index d10c351..6dd4a11 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -300,7 +300,7 @@ static int exynos_pm_suspend(void)
tmp = (S5P_USE_STANDBY_WFI0 | S5P_USE_STANDBY_WFE0);
__raw_writel(tmp, S5P_CENTRAL_SEQ_OPTION);
- if (!soc_is_exynos5250())
+ if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
exynos_cpu_save_register();
...
@@ -334,7 +334,7 @@ static void exynos_pm_resume(void)
if (exynos_pm_central_resume())
goto early_wakeup;
- if (!soc_is_exynos5250())
+ if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
exynos_cpu_restore_register();
It is invalid to check just the part number. The part number on its
own is meaningless without taking account of the implementor. Both
the implementor and the part number should be checked at each of these
sites.
Another point: exynos have taken it upon themselves to add code which
saves various ARM core registers. This is a bad idea, it brings us
back to the days where every platform did their own suspend implementations.
CPU level registers should be handled by CPU level code, not by platform
code. Is there a reason why this can't be added to the Cortex-A9
support code in proc-v7.S ?
@@ -353,7 +353,7 @@ static void exynos_pm_resume(void)
s3c_pm_do_restore_core(exynos_core_save,
ARRAY_SIZE(exynos_core_save));
- if (!soc_is_exynos5250())
+ if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
scu_enable(S5P_VA_SCU);
early_wakeup:
@@ -440,15 +440,18 @@ static int exynos_cpu_pm_notifier(struct
notifier_block *self,
case CPU_PM_ENTER:
if (cpu == 0) {
exynos_pm_central_suspend();
- exynos_cpu_save_register();
+ if (read_cpuid_part_number() ==
ARM_CPU_PART_CORTEX_A9)
+ exynos_cpu_save_register();
}
break;
case CPU_PM_EXIT:
if (cpu == 0) {
- if (!soc_is_exynos5250())
+ if (read_cpuid_part_number() ==
+ ARM_CPU_PART_CORTEX_A9) {
scu_enable(S5P_VA_SCU);
- exynos_cpu_restore_register();
+ exynos_cpu_restore_register();
+ }
exynos_pm_central_resume();
}
break;
And presumably with the CPU level code dealing with those registers,
you don't need the calls to save and restore these registers in this
notifier.
Which, by the way, is probably illegal to run as it runs in a read-
lock code path and with the SCU disabled. As you're calling
scu_enable() that means you're non-coherent with the other CPUs,
and therefore locks don't work.
I think this code is very broken and wrongly architected, and shows
that we're continuing to make the same mistakes that we made all
through the 2000s with platforms doing their own crap rather than
properly thinking about this stuff.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] Add support for Exynos clock output configuration
On all Exynos SoCs there is a dedicated CLKOUT pin that allows many of internal SoC clocks to be output from the SoC. The hardware structure of CLKOUT related clocks looks as follows: CMU |--- clock0 - | PMU | | | | several |--- clock1 - | mux | muxes | | + |--- CLKOUT dividers| ... | gate| and gates | | | |--- clockN - | | Since the block responsible for handling the pin is PMU, not CMU, a separate driver, that binds to PMU node is required and acquires all input clocks by standard DT clock look-up. This way we don't need any cross-IP block drivers and cross-driver register sharing or nodes for fake devices. To represent the PMU mux/gate clock, generic composite clock is registered. Tested on Odroid U3, with HSIC/USB hub using CLKOUT as reference clock, with some additional patches. Changes since v1: (http://www.spinics.net/lists/arm-kernel/msg333276.html) - rebased onto next-20140624, - fixed #clock-cells values in exynos5250.dtsi and exynos5420.dtsi, - temporarily removed ISP CLKOUT clocks on Exynos4x12, until ISP clock domain handling gets fixed in Exynos4 clock driver. Changes since RFC v1: (https://lkml.org/lkml/2014/5/15/506) - rebased onto v5 of Enable usbphy and hsotg for exynos4 series and current HEAD of samsung-clk tree, - added handling of suspend/resume in the driver, - added missing CPU clocks on Exynos4, - added CLK_SET_RATE_PARENT to CMU CLKOUT gates on Exynos4, - fixed bit field width on Exynos4, - added CLKOUT CMU registers of Exynos4 to save/restore list, - added CLK_SET_RATE_PARENT and CLK_SET_RATE_NO_REPARENT to clkout clock, - changed the binding to use 1-cell clock specifier to allow extension with further PMU clocks in future, if needed. Tomasz Figa (4): clk: samsung: exynos4: Add missing CPU/DMC clock hierarchy clk: samsung: exynos4: Add CLKOUT clock hierarchy clk: samsung: Add driver to control CLKOUT line on Exynos SoCs ARM: dts: exynos: Update PMU node with CLKOUT related data .../devicetree/bindings/arm/samsung/pmu.txt| 30 arch/arm/boot/dts/exynos4210.dtsi | 10 ++ arch/arm/boot/dts/exynos4x12.dtsi | 7 + arch/arm/boot/dts/exynos5250.dtsi | 3 + arch/arm/boot/dts/exynos5420.dtsi | 3 + drivers/clk/samsung/Makefile | 1 + drivers/clk/samsung/clk-exynos-clkout.c| 153 +++ drivers/clk/samsung/clk-exynos4.c | 166 - include/dt-bindings/clock/exynos4.h| 5 + 9 files changed, 374 insertions(+), 4 deletions(-) create mode 100644 drivers/clk/samsung/clk-exynos-clkout.c -- 1.9.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 3/3] ARM: exynos: activate the CCI on boot CPU/cluster with the MCPM loopback
Nicolas, On Mon, Jun 23, 2014 at 9:11 PM, Nicolas Pitre nicolas.pi...@linaro.org wrote: The Chromebook firmware doesn't enable the CCI for the boot cpu, and arguably it shouldn't have to either. Let's have the kernel handle the CCI on its own for the boot CPU the same way it does it for secondary CPUs by using the MCPM loopback. Signed-off-by: Nicolas Pitre n...@linaro.org --- arch/arm/mach-exynos/mcpm-exynos.c | 15 +++ 1 file changed, 15 insertions(+) Thank you very much for posting! With your series I'm able to boot all 8 cores on exynos5420-peach-pit and exynos5800-peach-pi sitting on my desk. Tested-by: Doug Anderson diand...@chromium.org -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: exynos: Modify pm code to check for cortex A9 rather than the SoC
On Tue, Jun 24, 2014 at 05:11:14PM +0100, Russell King - ARM Linux wrote: Another point: exynos have taken it upon themselves to add code which saves various ARM core registers. This is a bad idea, it brings us back to the days where every platform did their own suspend implementations. CPU level registers should be handled by CPU level code, not by platform code. Is there a reason why this can't be added to the Cortex-A9 support code in proc-v7.S ? BTW, Shawn Guo recently posted a patch to add the diagnostic register save/restore to proc-v7.S. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: exynos: Modify pm code to check for cortex A9 rather than the SoC
Hi Russell,
On 24.06.2014 18:11, Russell King - ARM Linux wrote:
On Mon, Jun 16, 2014 at 09:37:14AM +0530, Abhilash Kesavan wrote:
Hi Kukjin,
On Fri, May 23, 2014 at 8:31 AM, Abhilash Kesavan a.kesa...@samsung.com
wrote:
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Do you have any comments on this patch ?
I do.
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index d10c351..6dd4a11 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -300,7 +300,7 @@ static int exynos_pm_suspend(void)
tmp = (S5P_USE_STANDBY_WFI0 | S5P_USE_STANDBY_WFE0);
__raw_writel(tmp, S5P_CENTRAL_SEQ_OPTION);
- if (!soc_is_exynos5250())
+ if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
exynos_cpu_save_register();
...
@@ -334,7 +334,7 @@ static void exynos_pm_resume(void)
if (exynos_pm_central_resume())
goto early_wakeup;
- if (!soc_is_exynos5250())
+ if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
exynos_cpu_restore_register();
It is invalid to check just the part number. The part number on its
own is meaningless without taking account of the implementor. Both
the implementor and the part number should be checked at each of these
sites.
Just out of curiosity, are you aware of more than one implementor of
Cortex A9 on Exynos SoCs that would differ in having the need for save
and restore of those registers?
Another point: exynos have taken it upon themselves to add code which
saves various ARM core registers. This is a bad idea, it brings us
back to the days where every platform did their own suspend implementations.
CPU level registers should be handled by CPU level code, not by platform
code. Is there a reason why this can't be added to the Cortex-A9
support code in proc-v7.S ?
I agree that there is nothing platform specific in saving and restoring
those registers and that this should be probably handled by generic code.
However, when running in non-secure world, the only way to restore this
is to call a firmware operation, which is platform specific. Is there a
way to do something like this from proc-v7.S?
@@ -353,7 +353,7 @@ static void exynos_pm_resume(void)
s3c_pm_do_restore_core(exynos_core_save,
ARRAY_SIZE(exynos_core_save));
- if (!soc_is_exynos5250())
+ if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
scu_enable(S5P_VA_SCU);
early_wakeup:
@@ -440,15 +440,18 @@ static int exynos_cpu_pm_notifier(struct
notifier_block *self,
case CPU_PM_ENTER:
if (cpu == 0) {
exynos_pm_central_suspend();
- exynos_cpu_save_register();
+ if (read_cpuid_part_number() ==
ARM_CPU_PART_CORTEX_A9)
+ exynos_cpu_save_register();
}
break;
case CPU_PM_EXIT:
if (cpu == 0) {
- if (!soc_is_exynos5250())
+ if (read_cpuid_part_number() ==
+ ARM_CPU_PART_CORTEX_A9) {
scu_enable(S5P_VA_SCU);
- exynos_cpu_restore_register();
+ exynos_cpu_restore_register();
+ }
exynos_pm_central_resume();
}
break;
And presumably with the CPU level code dealing with those registers,
you don't need the calls to save and restore these registers in this
notifier.
Which, by the way, is probably illegal to run as it runs in a read-
lock code path and with the SCU disabled. As you're calling
scu_enable() that means you're non-coherent with the other CPUs,
and therefore locks don't work.
I don't see the read lock code path you mention. Could you elaborate on
this? By the way, other CPUs are still offline at this point.
Best regards,
Tomasz
--
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] ARM: dts: Add cros_ec to exynos5420-peach-pit and exynos5800-peach-pi
Tushar,
On Mon, Jun 23, 2014 at 11:43 PM, Tushar Behera trbli...@gmail.com wrote:
On 06/24/2014 02:19 AM, Doug Anderson wrote:
This adds cros_ec to exynos5420-peach-pit and exynos5800-peach-pi,
including:
* The keyboard
* The i2c tunnel
* The tps65090 under the i2c tunnel
* The battery under the i2c tunnel
To add extra motivation, it should be noted that tps65090 is one of
the things needed to get display-related FETs turned on for pit and
pi.
Note that this relies on a few outstanding changes:
* Needs (spi: s3c64xx: fix broken cs_gpios usage in the driver) and
(spi: s3c64xx: for DT platofrms always get the chipselect info from
DT node) to work properly and match the documented bindings. See
https://patchwork.kernel.org/patch/4346701/ and
https://patchwork.kernel.org/patch/4346711/
Signed-off-by: Doug Anderson diand...@chromium.org
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Along with the dependency patches on next-20140623, tested keyboard on
Peach-Pi board.
Tested-by: Tushar Behera tusha...@samsung.com
Some comments below.
---
Changes in v2:
- Now just one patch since mfd patch landed.
- Rebased to ToT linux-next
arch/arm/boot/dts/exynos5420-peach-pit.dts | 145
+
arch/arm/boot/dts/exynos5800-peach-pi.dts | 145
+
2 files changed, 290 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 7649982..581f385 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
+ regulators {
+ dcdc1 {
+ ti,enable-ext-control;
+ };
+ dcdc2 {
+ ti,enable-ext-control;
+ };
+ dcdc3 {
+ ti,enable-ext-control;
+ };
+ fet1 {
tps65090_fet1: fet1 { ?
+ regulator-name = vcd_led;
+ };
+ tps65090_fet2: fet2 {
I would suggest we add similar labels to fet1, fet3, fet4, fet5 and fet6
also. That way it would be easy to reference them in subsequent DT nodes.
Same comment for Peach-Pi dts file too.
OK. I added it to all the regulators in tps65090. That'll probably
be useful for Javier in his max77802 work.
-Doug
--
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 v3] ARM: dts: Add cros_ec to exynos5420-peach-pit and exynos5800-peach-pi
This adds cros_ec to exynos5420-peach-pit and exynos5800-peach-pi,
including:
* The keyboard
* The i2c tunnel
* The tps65090 under the i2c tunnel
* The battery under the i2c tunnel
To add extra motivation, it should be noted that tps65090 is one of
the things needed to get display-related FETs turned on for pit and
pi.
Note that this relies on a few outstanding changes:
* Needs (spi: s3c64xx: fix broken cs_gpios usage in the driver) and
(spi: s3c64xx: for DT platofrms always get the chipselect info from
DT node) to work properly and match the documented bindings. See
https://patchwork.kernel.org/patch/4346701/ and
https://patchwork.kernel.org/patch/4346711/
Signed-off-by: Doug Anderson diand...@chromium.org
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Tushar Behera tusha...@samsung.com
---
Changes in v3:
- Added aliases for tps65090 regulators as per Tushar.
Changes in v2:
- Now just one patch since mfd patch landed.
- Rebased to ToT linux-next
arch/arm/boot/dts/exynos5420-peach-pit.dts | 145 +
arch/arm/boot/dts/exynos5800-peach-pi.dts | 145 +
2 files changed, 290 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 7649982..b2f1237 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -25,6 +25,11 @@
google,pit, google,peach,samsung,exynos5420,
samsung,exynos5;
+ aliases {
+ /* Assign 20 so we don't get confused w/ builtin ones */
+ i2c20 = /spi@12d4/cros-ec@0/i2c-tunnel;
+ };
+
backlight {
compatible = pwm-backlight;
pwms = pwm 0 100 0;
@@ -87,6 +92,13 @@
pinctrl-0 = usb301_vbus_en;
enable-active-high;
};
+
+ vbat: fixed-regulator {
+ compatible = regulator-fixed;
+ regulator-name = vbat-supply;
+ regulator-boot-on;
+ regulator-always-on;
+ };
};
dp {
@@ -231,6 +243,20 @@
samsung,pin-drv = 0;
};
+ ec_irq: ec-irq {
+ samsung,pins = gpx1-5;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ tps65090_irq: tps65090-irq {
+ samsung,pins = gpx2-5;
+ samsung,pin-function = 0;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
dp_hpd_gpio: dp_hpd_gpio {
samsung,pins = gpx2-6;
samsung,pin-function = 0;
@@ -247,6 +273,19 @@
};
pinctrl_3 {
+ /* Drive SPI lines at x2 for better integrity */
+ spi2-bus {
+ samsung,pin-drv = 2;
+ };
+
+ /* Drive SPI chip select at x2 for better integrity */
+ ec_spi_cs: ec-spi-cs {
+ samsung,pins = gpb1-2;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 2;
+ };
+
usb300_vbus_en: usb300-vbus-en {
samsung,pins = gph0-0;
samsung,pin-function = 1;
@@ -266,6 +305,111 @@
status = okay;
};
+spi_2 {
+ status = okay;
+ num-cs = 1;
+ samsung,spi-src-clk = 0;
+ cs-gpios = gpb1 2 0;
+
+ cros_ec: cros-ec@0 {
+ compatible = google,cros-ec-spi;
+ interrupt-parent = gpx1;
+ interrupts = 5 0;
+ pinctrl-names = default;
+ pinctrl-0 = ec_spi_cs ec_irq;
+ reg = 0;
+ spi-max-frequency = 3125000;
+
+ controller-data {
+ samsung,spi-feedback-delay = 1;
+ };
+
+ i2c-tunnel {
+ compatible = google,cros-ec-i2c-tunnel;
+ #address-cells = 1;
+ #size-cells = 0;
+ google,remote-bus = 0;
+
+ battery: sbs-battery@b {
+ compatible = sbs,sbs-battery;
+ reg = 0xb;
+ sbs,poll-retry-count = 1;
+ sbs,i2c-retry-count = 2;
+ };
+
+ power-regulator@48 {
+ compatible = ti,tps65090;
+ reg = 0x48;
+
+ /*
+* Config irq to disable internal pulls
+* even though we run in polling mode.
+*/
+ pinctrl-names = default;
+ pinctrl-0 = tps65090_irq;
+
+ vsys1-supply = vbat;
+ vsys2-supply = vbat;
+
Re: [PATCH] arm: exynos: Modify pm code to check for cortex A9 rather than the SoC
On Tue, Jun 24, 2014 at 06:20:56PM +0200, Tomasz Figa wrote: Hi Russell, On 24.06.2014 18:11, Russell King - ARM Linux wrote: On Mon, Jun 16, 2014 at 09:37:14AM +0530, Abhilash Kesavan wrote: Hi Kukjin, On Fri, May 23, 2014 at 8:31 AM, Abhilash Kesavan a.kesa...@samsung.com wrote: Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com Do you have any comments on this patch ? I do. diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c index d10c351..6dd4a11 100644 --- a/arch/arm/mach-exynos/pm.c +++ b/arch/arm/mach-exynos/pm.c @@ -300,7 +300,7 @@ static int exynos_pm_suspend(void) tmp = (S5P_USE_STANDBY_WFI0 | S5P_USE_STANDBY_WFE0); __raw_writel(tmp, S5P_CENTRAL_SEQ_OPTION); - if (!soc_is_exynos5250()) + if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9) exynos_cpu_save_register(); ... @@ -334,7 +334,7 @@ static void exynos_pm_resume(void) if (exynos_pm_central_resume()) goto early_wakeup; - if (!soc_is_exynos5250()) + if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9) exynos_cpu_restore_register(); It is invalid to check just the part number. The part number on its own is meaningless without taking account of the implementor. Both the implementor and the part number should be checked at each of these sites. Just out of curiosity, are you aware of more than one implementor of Cortex A9 on Exynos SoCs that would differ in having the need for save and restore of those registers? That doesn't stop stuff changing in the future. We've been here before. Let's do the job properly if we're going to do the job at all. If people still whine about this, I will force a change to make it harder to do the wrong thing - I will get rid of the _part_number interface replacing it with one which always returns the implementor as well as the part number so both have to be checked. Another point: exynos have taken it upon themselves to add code which saves various ARM core registers. This is a bad idea, it brings us back to the days where every platform did their own suspend implementations. CPU level registers should be handled by CPU level code, not by platform code. Is there a reason why this can't be added to the Cortex-A9 support code in proc-v7.S ? I agree that there is nothing platform specific in saving and restoring those registers and that this should be probably handled by generic code. However, when running in non-secure world, the only way to restore this is to call a firmware operation, which is platform specific. Is there a way to do something like this from proc-v7.S? We never call firmware operations from assembly code. However, in exynos' case, it's not running in non-secure mode because it's happily reading and writing these registers with no issue. Platforms running in non-secure mode already have to ensure that various work-arounds are implemented in their firmware/boot loader, and this really is no different (we wouldn't need this code in the kernel in the first place if the firmware/boot loader would get its act together.) And presumably with the CPU level code dealing with those registers, you don't need the calls to save and restore these registers in this notifier. Which, by the way, is probably illegal to run as it runs in a read- lock code path and with the SCU disabled. As you're calling scu_enable() that means you're non-coherent with the other CPUs, and therefore locks don't work. I don't see the read lock code path you mention. Could you elaborate on this? By the way, other CPUs are still offline at this point. We get there from kernel/cpu_pm.c, when the notifier chain is called. The notifier chain is called while taking a read lock on cpu_pm_notifier_lock. If this is about the last CPU going down, then why the notifier? Why not put the code in exynos_suspend_enter() ? Why add this needless complexity? -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- 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] ARM: dts: Add cros_ec to exynos5420-peach-pit and exynos5800-peach-pi
Hello Doug,
On 06/24/2014 06:28 PM, Doug Anderson wrote:
Tushar,
On Mon, Jun 23, 2014 at 11:43 PM, Tushar Behera trbli...@gmail.com wrote:
On 06/24/2014 02:19 AM, Doug Anderson wrote:
This adds cros_ec to exynos5420-peach-pit and exynos5800-peach-pi,
including:
* The keyboard
* The i2c tunnel
* The tps65090 under the i2c tunnel
* The battery under the i2c tunnel
To add extra motivation, it should be noted that tps65090 is one of
the things needed to get display-related FETs turned on for pit and
pi.
Note that this relies on a few outstanding changes:
* Needs (spi: s3c64xx: fix broken cs_gpios usage in the driver) and
(spi: s3c64xx: for DT platofrms always get the chipselect info from
DT node) to work properly and match the documented bindings. See
https://patchwork.kernel.org/patch/4346701/ and
https://patchwork.kernel.org/patch/4346711/
Signed-off-by: Doug Anderson diand...@chromium.org
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Along with the dependency patches on next-20140623, tested keyboard on
Peach-Pi board.
Tested-by: Tushar Behera tusha...@samsung.com
Some comments below.
---
Changes in v2:
- Now just one patch since mfd patch landed.
- Rebased to ToT linux-next
arch/arm/boot/dts/exynos5420-peach-pit.dts | 145
+
arch/arm/boot/dts/exynos5800-peach-pi.dts | 145
+
2 files changed, 290 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 7649982..581f385 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
+ regulators {
+ dcdc1 {
+ ti,enable-ext-control;
+ };
+ dcdc2 {
+ ti,enable-ext-control;
+ };
+ dcdc3 {
+ ti,enable-ext-control;
+ };
+ fet1 {
tps65090_fet1: fet1 { ?
+ regulator-name = vcd_led;
+ };
+ tps65090_fet2: fet2 {
I would suggest we add similar labels to fet1, fet3, fet4, fet5 and fet6
also. That way it would be easy to reference them in subsequent DT nodes.
Same comment for Peach-Pi dts file too.
OK. I added it to all the regulators in tps65090. That'll probably
be useful for Javier in his max77802 work.
Thanks, in fact I did add both tps65090_dcdc1 and tps65090_dcdc2 labels to be
able to use these regulators as supply for some of the max77802 regulators.
Will rebase on top of this.
Best regards,
Javier
-Doug
--
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 07/10] regulator: Add driver for Maxim 77802 PMIC regulators
Hello Mark, On 06/23/2014 11:47 AM, Mark Brown wrote: On Mon, Jun 23, 2014 at 11:28:25AM +0200, Javier Martinez Canillas wrote: On 06/21/2014 10:40 PM, Mark Brown wrote: That's not really relevant here - I'm asking if the regulators get their own supplies rather than if anything uses them. Sorry if I keep misunderstanding your question but the regulators in this PMIC don't have a parent supply/regulator node. They should, I'm pretty sure the device does actually regulate one supply into another. Thanks a lot for the clarification. This was not evident to me when I read the PMIC datasheet and because both the max77xxx Chrome OS 3.8 and mainline max77686 drivers used a simplistic model of the power scheme. But Doug confirmed to me that some regulators on this PMIC do indeed use others regulators as a power supply so I'll change this in the next version of the patch-set. Best regards, Javier -- 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: sdhci_s3c_consider_clock scheduling while atomic - clk_round_rate
Hi Daniel, [adding Ulf, Chris and Mike to the discussion] On 24.06.2014 11:48, Daniel Drake wrote: sdhci_s3c_set_clock is called from sdhci_do_set_ios with interrupts disabled, and this calls into sdhci_s3c_consider_clock(). The patch mmc: sdhci-s3c: Cache bus clock rates addressed some scheduling while atomic in this function, but there are more issues here, seen while testing 3.16-rc2 on exynos4412: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:103 in_atomic(): 1, irqs_disabled(): 128, pid: 75, name: mmcqd/0 Preemption disabled at:[ (null)] (null) CPU: 0 PID: 75 Comm: mmcqd/0 Not tainted 3.16.0-rc2-00028-ge9fe7eb-dirty #77 [c0016140] (unwind_backtrace) from [c0011e14] (show_stack+0x10/0x14) [c0011e14] (show_stack) from [c05ce8a8] (dump_stack+0x84/0xc4) [c05ce8a8] (dump_stack) from [c05d2de0] (mutex_lock+0x1c/0x3c) [c05d2de0] (mutex_lock) from [c046214c] (clk_prepare_lock+0x6c/0xf4) [c046214c] (clk_prepare_lock) from [c04625ac] (clk_round_rate+0x10/0x2c) [c04625ac] (clk_round_rate) from [c0447628] (sdhci_s3c_set_clock+0x4c/0x1e8) [c0447628] (sdhci_s3c_set_clock) from [c0447818] (sdhci_cmu_set_clock+0x54/0x140) [c0447818] (sdhci_cmu_set_clock) from [c0443a38] (sdhci_do_set_ios+0x138/0x58c) [c0443a38] (sdhci_do_set_ios) from [c0443864] (sdhci_set_ios+0x28/0x34) clk_round_rate cannot be called here because it takes a mutex. sdhci_s3c_set_clock() also calls into clk_prepare_enable() which looks like it could trigger this problem too. Apparently this is related to generic sdhci code calling .set_clock() under spin_lock_irqsave(). For reference, see sdhci_do_set_ios() and sdhci_tasklet_finish(). Chris, Ulf, any suggestions? Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: exynos: Modify pm code to check for cortex A9 rather than the SoC
On 24.06.2014 18:30, Russell King - ARM Linux wrote: On Tue, Jun 24, 2014 at 06:20:56PM +0200, Tomasz Figa wrote: Hi Russell, On 24.06.2014 18:11, Russell King - ARM Linux wrote: On Mon, Jun 16, 2014 at 09:37:14AM +0530, Abhilash Kesavan wrote: Hi Kukjin, On Fri, May 23, 2014 at 8:31 AM, Abhilash Kesavan a.kesa...@samsung.com wrote: Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com Do you have any comments on this patch ? I do. diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c index d10c351..6dd4a11 100644 --- a/arch/arm/mach-exynos/pm.c +++ b/arch/arm/mach-exynos/pm.c @@ -300,7 +300,7 @@ static int exynos_pm_suspend(void) tmp = (S5P_USE_STANDBY_WFI0 | S5P_USE_STANDBY_WFE0); __raw_writel(tmp, S5P_CENTRAL_SEQ_OPTION); - if (!soc_is_exynos5250()) + if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9) exynos_cpu_save_register(); ... @@ -334,7 +334,7 @@ static void exynos_pm_resume(void) if (exynos_pm_central_resume()) goto early_wakeup; - if (!soc_is_exynos5250()) + if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9) exynos_cpu_restore_register(); It is invalid to check just the part number. The part number on its own is meaningless without taking account of the implementor. Both the implementor and the part number should be checked at each of these sites. Just out of curiosity, are you aware of more than one implementor of Cortex A9 on Exynos SoCs that would differ in having the need for save and restore of those registers? That doesn't stop stuff changing in the future. We've been here before. Let's do the job properly if we're going to do the job at all. I tend to disagree. The chance of a new Cortex A9 based SoC with different implementor code showing up is so close to zero that I don't see increasing of code complexity by adding yet another check justified. If people still whine about this, I will force a change to make it harder to do the wrong thing - I will get rid of the _part_number interface replacing it with one which always returns the implementor as well as the part number so both have to be checked. That might be actually a better option. Something like if (read_cpuid_impl_and_part() == ARM_CPU(impl, part)) or even if (ARM_CPU_IS(impl, part)) would keep the checks simple, while still checking both values. Another point: exynos have taken it upon themselves to add code which saves various ARM core registers. This is a bad idea, it brings us back to the days where every platform did their own suspend implementations. CPU level registers should be handled by CPU level code, not by platform code. Is there a reason why this can't be added to the Cortex-A9 support code in proc-v7.S ? I agree that there is nothing platform specific in saving and restoring those registers and that this should be probably handled by generic code. However, when running in non-secure world, the only way to restore this is to call a firmware operation, which is platform specific. Is there a way to do something like this from proc-v7.S? We never call firmware operations from assembly code. However, in exynos' case, it's not running in non-secure mode because it's happily reading and writing these registers with no issue. Current version of code, yes. However it handles only Exynos-based boards running in secure mode. For those running in non-secure mode, mainline does not support sleep yet. I already have patches to change this, which I was planning to post after eliminating last issue. The change set includes making this save/restore being executed only in secure mode. Platforms running in non-secure mode already have to ensure that various work-arounds are implemented in their firmware/boot loader, and this really is no different (we wouldn't need this code in the kernel in the first place if the firmware/boot loader would get its act together.) In ideal world (which I would be glad to be living in)... We both know that we can't fully rely on firmware. Firmware bugs are common and in many cases we can't do anything about it, because it already comes with the device and in many cases it is undesirable to change it or it can't be done at all. And presumably with the CPU level code dealing with those registers, you don't need the calls to save and restore these registers in this notifier. Which, by the way, is probably illegal to run as it runs in a read- lock code path and with the SCU disabled. As you're calling scu_enable() that means you're non-coherent with the other CPUs, and therefore locks don't work. I don't see the read lock code path you mention. Could you elaborate on this? By the way, other CPUs are still offline at this point. We get there from kernel/cpu_pm.c, when the notifier chain is called. The notifier chain is called while taking a read lock on
Re: mainline boot: 64 boots: 62 pass, 2 fail (v3.16-rc1-2-gebe0618)
On 6/23/2014 11:32 AM, Kevin Hilman wrote: On Sun, Jun 22, 2014 at 8:56 PM, Tushar Behera trbli...@gmail.com wrote: Adding linux-samsung-soc and linux-arm-kernel ML for wider audience. On 06/19/2014 04:12 PM, Tushar Behera wrote: On 06/19/2014 03:02 PM, Tushar Behera wrote: On 06/18/2014 09:22 AM, Kevin Hilman wrote: On Tue, Jun 17, 2014 at 8:26 PM, Tushar Behera trbli...@gmail.com wrote: On 06/17/2014 10:23 PM, Kevin Hilman wrote: Sachin, On Mon, Jun 16, 2014 at 11:16 PM, Kevin's boot bot khil...@linaro.org wrote: Tree/Branch: mainline Git describe: v3.16-rc1-2-gebe0618 Failed boot tests (console logs at the end) === exynos5420-arndale-octa: FAIL:arm-exynos_defconfig ste-snowball: FAIL:arm-u8500_defconfig FYI... these failures are getting more consistent on my octa board, but still not failing every time. Kevin Hi Kevin, Same here. Observation: If you soft-reset the board (through the jumpers) after getting this problem, the problem keeps repeating. But if you hard-reset the board (by removing the power cord), the problem doesn't occur during next iteration. I don't ever use the soft-reset, I only toggle the wall power. I don't ever actually remove the power cord though, I'm using a USB-controlled relay to toggle the wall power. Kevin Laura, We are getting following kernel panic [1] (not always, but quite regularly) while booting Arndale-Octa (based on Samsung's Exynos5420) board with upstream kernel. I haven't observed this issue with other boards yet. This issue is observed when I am booting with uImage + dtb (within roughly ~10 iterations). Some more information: The boot logs are provided in pastebin, okay[2] and failed[3]. In case of boot failures, I am getting a higher value for vm_total_pages (684424 in [3]). In case of successful boot on my board, it is always 521232 [2] on my board. I can confirm that reverting the Get rid of meminfo patch gets the Octa board booting reliably again for me also. In case it helps, some boot logs for failures from the last copule linux-next build/boot cycles can be seen here: http://armcloud.us/kernel-ci/next/next-20140623/arm-exynos_defconfig/boot-exynos5420-arndale-octa.log http://armcloud.us/kernel-ci/next/next-20140620/arm-exynos_defconfig/boot-exynos5420-arndale-octa.log Sorry, I missed this yesterday. I'm going to take a look. Thanks, Laura -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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/3] ARM: exynos: activate the CCI on boot CPU/cluster with the MCPM loopback
On Tue, 24 Jun 2014, Doug Anderson wrote: Thank you very much for posting! With your series I'm able to boot all 8 cores on exynos5420-peach-pit and exynos5800-peach-pi sitting on my desk. Tested-by: Doug Anderson diand...@chromium.org Thanks to all. I've submitted those patches, with minor nits fixed, to RMK's system as patches 8081 to 8083. 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 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators
Yuvaraj,
On Mon, Jun 23, 2014 at 3:45 AM, Yuvaraj Kumar C D yuvaraj...@gmail.com wrote:
This patch makes use of mmc_regulator_get_supply() to handle
the vmmc and vqmmc regulators.Also it moves the code handling
the these regulators to dw_mci_set_ios().It turned on the vmmc
and vqmmc during MMC_POWER_UP and MMC_POWER_ON,and turned off
during MMC_POWER_OFF.
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
---
drivers/mmc/host/dw_mmc.c | 71
++---
drivers/mmc/host/dw_mmc.h |2 ++
2 files changed, 36 insertions(+), 37 deletions(-)
Perhaps you could CC me on the whole series for the next version since
I was involved in privately reviewing previous versions?
Overall caveat for my review is that I'm nowhere near an SD/MMC expert.
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 1ac227c..f5cabce 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -937,6 +937,7 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
struct dw_mci_slot *slot = mmc_priv(mmc);
const struct dw_mci_drv_data *drv_data = slot-host-drv_data;
u32 regs;
+ int ret;
switch (ios-bus_width) {
case MMC_BUS_WIDTH_4:
@@ -975,16 +976,41 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
switch (ios-power_mode) {
case MMC_POWER_UP:
+ if ((!IS_ERR(mmc-supply.vmmc))
+ !test_bit(DW_MMC_CARD_POWERED, slot-flags))
{
+ ret = regulator_enable(mmc-supply.vmmc);
+ if (!ret)
+ set_bit(DW_MMC_CARD_POWERED, slot-flags);
+ }
As per below, I'm not sure why you'd want to turn on vqmmc and vmmc at
different times.
Also: if you fail to turn on either of the regulators it feels like
you should print a pretty nasty error message since your device will
almost certainly not work.
set_bit(DW_MMC_CARD_NEED_INIT, slot-flags);
regs = mci_readl(slot-host, PWREN);
regs |= (1 slot-id);
mci_writel(slot-host, PWREN, regs);
break;
case MMC_POWER_OFF:
+ if (!IS_ERR(mmc-supply.vqmmc)
+ test_bit(DW_MMC_IO_POWERED, slot-flags)) {
+ ret = regulator_disable(mmc-supply.vqmmc);
+ if (!ret)
+ clear_bit(DW_MMC_IO_POWERED, slot-flags);
+ }
+ if (!IS_ERR(mmc-supply.vmmc)
+ test_bit(DW_MMC_CARD_POWERED, slot-flags)) {
+ ret = regulator_disable(mmc-supply.vmmc);
+ if (!ret)
+ clear_bit(DW_MMC_CARD_POWERED, slot-flags);
+ }
regs = mci_readl(slot-host, PWREN);
regs = ~(1 slot-id);
mci_writel(slot-host, PWREN, regs);
break;
+ case MMC_POWER_ON:
+ if (!IS_ERR(mmc-supply.vqmmc)
+ !test_bit(DW_MMC_IO_POWERED, slot-flags)) {
+ ret = regulator_enable(mmc-supply.vqmmc);
+ if (!ret)
+ set_bit(DW_MMC_IO_POWERED, slot-flags);
+ }
default:
break;
}
@@ -2067,7 +2093,13 @@ static int dw_mci_init_slot(struct dw_mci *host,
unsigned int id)
mmc-f_max = freq[1];
}
- mmc-ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
+ /*if there are external regulators, get them*/
+ ret = mmc_regulator_get_supply(mmc);
+ if (ret == -EPROBE_DEFER)
+ goto err_setup_bus;
+
+ if (!mmc-ocr_avail)
+ mmc-ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
if (host-pdata-caps)
mmc-caps = host-pdata-caps;
@@ -2133,7 +2165,7 @@ static int dw_mci_init_slot(struct dw_mci *host,
unsigned int id)
err_setup_bus:
mmc_free_host(mmc);
- return -EINVAL;
+ return ret;
}
static void dw_mci_cleanup_slot(struct dw_mci_slot *slot, unsigned int id)
@@ -2375,24 +2407,6 @@ int dw_mci_probe(struct dw_mci *host)
}
}
- host-vmmc = devm_regulator_get_optional(host-dev, vmmc);
- if (IS_ERR(host-vmmc)) {
- ret = PTR_ERR(host-vmmc);
- if (ret == -EPROBE_DEFER)
- goto err_clk_ciu;
-
- dev_info(host-dev, no vmmc regulator found: %d\n, ret);
- host-vmmc = NULL;
- } else {
- ret = regulator_enable(host-vmmc);
- if (ret) {
- if (ret != -EPROBE_DEFER)
- dev_err(host-dev,
-
Re: [PATCH 2/3] mmc: dw_mmc: Dont cut off vqmmc and vmmc
Yuvaraj, On Mon, Jun 23, 2014 at 3:45 AM, Yuvaraj Kumar C D yuvaraj...@gmail.com wrote: On exynos 5250 and 5420 based boards which uses built-in CD# line for card detection.But unfortunately CD# line is on the same voltage rails as of I/O voltage rails.When we cut off vqmmc,the consequent card detection will break in these boards. Also if we let alone the vqmmc turned on when vmmc turned off, the card could have half way powered and this can damage the card.So this patch adds a check so that, if the board used the built-in card detection mechanism i.e through CDETECT, it will not turned down vqmmc and vmmc both. Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com --- drivers/mmc/host/dw_mmc.c | 23 +++ 1 file changed, 23 insertions(+) Yes, but... As I mentioned in our separate email thread about this you're now preventing mmc_power_cycle() from working properly. IMHO you need the patch I sent you back on April 24th (was it that long ago?). Due to the brokenness of exynos (and anyone else that powers CD off of vqmmc) you need to extend the MMC core to differentiate several different types of power off: * power off because no card is plugged in: you should keep your card on. * power off because you're power cycling: you should power off your card. * power off because the system is suspending: you should power off your card. ...the third bullet point is something I hadn't though of until just now and probably isn't addressed in my old patch... Also: as we've discussed privately: you could imagine someone designing an exynos5-based board where they've put the CD on a separate GPIO. On a system like this then all these hacks won't be necessary. --- Verbatim from my email about this topic on May 28th: There are two important cases to handle: 1. Properly power cycle both vmmc and vqmmc (at the same time!) in mmc_power_cycle(). 2. DON'T power off for mmc_power_off() unless it's part of mmc_power_cycle(). Specifically note that mmc_power_off() is called in a whole bunch of places other than mmc_power_cycle(). For instance, if we fail to probe a card we'll call mmc_power_off(). All of these _must_ not turn off power to card detect or else we won't be able to see future card insertions. Note that mmc_power_off() might be called on its own even when a card is inserted. Look at the end of mmc_rescan_try_freq(). It will be called if there are errors attaching a card. Rules to always remember: * On all boards you should turn on vmmc and vqmmc at the same time. It's illegal to have vqmmc on without vmmc and not good to have vmmc on without vqmmc. * On exynos you must ensure that vqmmc is on at all times, except during power cycling of a card. If vqmmc is not on you can't detect card insertions or removals since the card detect line won't be powered. * To handle errors, you must ensure that mmc_power_cycle() actually cycles power to the card. -- 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] devicetree: Add generic IOMMU device tree bindings
On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan wrote:
On 6/24/2014 2:18 AM, Will Deacon wrote:
On Sat, Jun 21, 2014 at 12:16:25AM +0100, Olav Haugan wrote:
We have multiple-master SMMUs and each master emits a variable number of
StreamIDs. However, we have to apply a mask (the ARM SMMU spec allows
for this) to the StreamIDs due to limited number of StreamID 2 Context
Bank entries in the SMMU. If my understanding is correct we would
represent this in the DT like this:
iommu {
#address-cells = 2;
#size-cells = 0;
};
master@a {
...
iommus = iommu StreamID0 MASK0,
iommu StreamID1 MASK1,
iommu StreamID2 MASK2;
};
Stupid question, but why not simply describe the masked IDs? What use does
the `raw' ID have to Linux?
We do describe the masked StreamID (SID) but we need to specify the mask
that the SMMU should apply to the incoming SIDs, right?
We have a bus master that emits 43 unique SIDs. However, we have only 40
SMMU_SMRn registers in the SMMU. So we need to mask out some of the
incoming SID bits so that the 43 SIDs can match one of 40 entries in the
SMR.
Hmm, so you're talking about stream matching, right? That doesn't belong in
the device-tree. I appreciate that the current driver does a terrible job at
allocating the SMRs (it's bloody difficult!), but we should try to improve
the dynamic behaviour instead of moving configuration of the SMMU out into
device-tree, where it's inflexible at best.
There have been patches previously posted by Andreas Herrmann helping here.
I'd be glad to see them revived.
Will
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: exynos: Modify pm code to check for cortex A9 rather than the SoC
On Tue, Jun 24, 2014 at 07:16:47PM +0200, Tomasz Figa wrote: I tend to disagree. The chance of a new Cortex A9 based SoC with different implementor code showing up is so close to zero that I don't see increasing of code complexity by adding yet another check justified. That's your opinion which I strongly disagree with. If people still whine about this, I will force a change to make it harder to do the wrong thing - I will get rid of the _part_number interface replacing it with one which always returns the implementor as well as the part number so both have to be checked. That might be actually a better option. Something like if (read_cpuid_impl_and_part() == ARM_CPU(impl, part)) or even if (ARM_CPU_IS(impl, part)) would keep the checks simple, while still checking both values. Indeed, but... Cortex is an ARM Ltd trademark, so I really doubt that we'll see a Cortex processor implemented by another party other than ARM. So, there's no need for ARM_CPU(impl, part). We never call firmware operations from assembly code. However, in exynos' case, it's not running in non-secure mode because it's happily reading and writing these registers with no issue. Current version of code, yes. However it handles only Exynos-based boards running in secure mode. For those running in non-secure mode, mainline does not support sleep yet. I already have patches to change this, which I was planning to post after eliminating last issue. The change set includes making this save/restore being executed only in secure mode. As Will has already pointed out, writing to the diagnostic register becomes a no-op in non-secure mode - it doesn't fault. So moving the saving and restoring of this register into generic code, where other platforms already require it, makes total sense. Of course, when you have to deal with it in non-secure mode, that's something that you have to deal with, but in secure mode, platform code should not have to worry about this level of detail. In ideal world (which I would be glad to be living in)... We both know that we can't fully rely on firmware. Firmware bugs are common and in many cases we can't do anything about it, because it already comes with the device and in many cases it is undesirable to change it or it can't be done at all. Yes, I'm aware of the crap situation there. That doesn't stop us talking about these aspects though and setting what we expect in the future - and changing the code to a better structure. We get there from kernel/cpu_pm.c, when the notifier chain is called. The notifier chain is called while taking a read lock on cpu_pm_notifier_lock. Your point. Thanks for explaining this. However this will be still running with just one CPU online. If this is about the last CPU going down, then why the notifier? Why not put the code in exynos_suspend_enter() ? Why add this needless complexity? This code is used by both system-wide suspend/resume and cpuidle paths. Daniel has moved this code to CPU PM notifier as a part of his Exynos cpuidle consolidation series to avoid code duplication, as this is the common point of both paths. To clarify, on suspend/resume path, the notifier is being called from syscore_ops registered in kernel/cpu_pm.c, while on cpuidle path, this is invoked from exynos_enter_core0_aftr() in drivers/cpuidle/cpuidle-exynos.c, which calls cpu_pm_enter(). ... which then goes on to call cpu_suspend(). So moving this stuff into the CPU level makes total sense rather than having every platform running in secure mode duplicating this functionality. Thanks for pointing that out and adding further justification to my assertion. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- 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/3] mmc: dw_mmc: Support voltage changes
Yuvaraj,
On Mon, Jun 23, 2014 at 3:45 AM, Yuvaraj Kumar C D yuvaraj...@gmail.com wrote:
From: Doug Anderson diand...@chromium.org
For UHS cards we need the ability to switch voltages from 3.3V to
1.8V. Add support to the dw_mmc driver to handle this. Note that
dw_mmc needs a little bit of extra code since the interface needs a
special bit programmed to the CMD register while CMD11 is progressing.
This means adding a few extra states to the state machine to track.
Signed-off-by: Doug Anderson diand...@chromium.org
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
---
drivers/mmc/host/dw_mmc.c | 145
+---
drivers/mmc/host/dw_mmc.h |5 +-
include/linux/mmc/dw_mmc.h |2 +
3 files changed, 142 insertions(+), 10 deletions(-)
I will note to other interested parties that in the ChromeOS tree we
never actually cleaned up the MMC voltage change stuff enough to make
use of this functionality to actually get UHS cards working (though
the code is exercised as part of WiFi).
@@ -254,6 +258,32 @@ static u32 dw_mci_prepare_command(struct mmc_host *mmc,
struct mmc_command *cmd)
else if (cmd-opcode != MMC_SEND_STATUS cmd-data)
cmdr |= SDMMC_CMD_PRV_DAT_WAIT;
+ if (cmd-opcode == SD_SWITCH_VOLTAGE) {
+ u32 clk_en_a;
+
+ /* Special bit makes CMD11 not die */
+ cmdr |= SDMMC_CMD_VOLT_SWITCH;
+
+ /* Change state to continue to handle CMD11 weirdness */
+ WARN_ON(slot-host-state != STATE_SENDING_CMD);
+ slot-host-state = STATE_SENDING_CMD11;
+
+ /*
+* We need to disable clock stop while doing voltage switch
+* according to 7.4.1.2 Voltage Switch Normal Scenario.
I think upstream hasn't tended to like the chapter number references,
though Grant really liked them locally.
+static int dw_mci_switch_voltage(struct mmc_host *mmc, struct mmc_ios *ios)
+{
+ struct dw_mci_slot *slot = mmc_priv(mmc);
+ struct dw_mci *host = slot-host;
+ u32 uhs;
+ u32 v18 = SDMMC_UHS_18V slot-id;
+ int min_uv, max_uv;
+ int ret;
+
+ /*
+* Program the voltage. Note that some instances of dw_mmc may use
+* the UHS_REG for this. For other instances (like exynos) the
UHS_REG
+* does no harm but you need to set the regulator directly. Try both.
I've only worked with exynos which doesn't use UHS_REG for anything,
so the setting of this bit was a best-guess. If anyone actually had a
chip that uses it then please comment / test.
--
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] devicetree: Add generic IOMMU device tree bindings
On Tuesday 24 June 2014 19:11:50 Will Deacon wrote:
On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan wrote:
On 6/24/2014 2:18 AM, Will Deacon wrote:
On Sat, Jun 21, 2014 at 12:16:25AM +0100, Olav Haugan wrote:
We have multiple-master SMMUs and each master emits a variable number of
StreamIDs. However, we have to apply a mask (the ARM SMMU spec allows
for this) to the StreamIDs due to limited number of StreamID 2 Context
Bank entries in the SMMU. If my understanding is correct we would
represent this in the DT like this:
iommu {
#address-cells = 2;
#size-cells = 0;
};
master@a {
...
iommus = iommu StreamID0 MASK0,
iommu StreamID1 MASK1,
iommu StreamID2 MASK2;
};
Stupid question, but why not simply describe the masked IDs? What use does
the `raw' ID have to Linux?
We do describe the masked StreamID (SID) but we need to specify the mask
that the SMMU should apply to the incoming SIDs, right?
We have a bus master that emits 43 unique SIDs. However, we have only 40
SMMU_SMRn registers in the SMMU. So we need to mask out some of the
incoming SID bits so that the 43 SIDs can match one of 40 entries in the
SMR.
Hmm, so you're talking about stream matching, right? That doesn't belong in
the device-tree. I appreciate that the current driver does a terrible job at
allocating the SMRs (it's bloody difficult!), but we should try to improve
the dynamic behaviour instead of moving configuration of the SMMU out into
device-tree, where it's inflexible at best.
There have been patches previously posted by Andreas Herrmann helping here.
I'd be glad to see them revived.
Note that there are areas where we have in the past decided that dynamic
configuration is just too hard for the kernel to do and that we're better
off putting the configuration into DT. Pinctrl and clocks are at least
partially in that category.
It's always best if you can get the kernel to do things in the ideal
way where that is possible, but getting there may be just not worth it.
I have no idea where it should be for SMMU, but it's something to consider:
if you can take reasonable shortcuts by reading parts of the configuration
from DT, you may just as well do that.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: DTS: correct the capability string for mmc0
Hi, On Mon, Jun 23, 2014 at 4:36 AM, Kukjin Kim kgene@samsung.com wrote: Naveen Krishna Chatradhi wrote: MMC capability for HS200 is parsed in mmc/core/host.c as dts string mmc-hs200-1_8v. This patch corrects the dts string for Exynos5420 based peach-pit and Exynos5800 based peach-pi boards. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com --- arch/arm/boot/dts/exynos5420-peach-pit.dts |2 +- arch/arm/boot/dts/exynos5800-peach-pi.dts |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts b/arch/arm/boot/dts/exynos5420- peach-pit.dts index 7649982..7dea480 100644 --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts @@ -173,7 +173,7 @@ status = okay; num-slots = 1; broken-cd; - caps2-mmc-hs200-1_8v; + mmc-hs200-1_8v; supports-highspeed; non-removable; card-detect-delay = 200; diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800- peach-pi.dts index 2c2c137..bb3ee76 100644 --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts @@ -171,7 +171,7 @@ status = okay; num-slots = 1; broken-cd; - caps2-mmc-hs200-1_8v; + mmc-hs200-1_8v; supports-highspeed; non-removable; card-detect-delay = 200; -- 1.7.9.5 Applied, thanks. As an FYI: this patch (while correct) will likely cause sporadic boot failures until Sonny and my patches land: * https://patchwork.kernel.org/patch/4323921/ mmc: dw_mmc: Make sure we don't get stuck when we get an error * https://patchwork.kernel.org/patch/4213211/ mmc: dw_mmc: change to use recommended reset procedure In the very least we got sporadic boot failures locally when we enabled hs200 and didn't have the don't get stuck patch. I will also note that it would have been nice had this patch title included the words exynos and/or pit/pi in it. -Doug -- 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] devicetree: Add generic IOMMU device tree bindings
On 6/24/2014 11:11 AM, Will Deacon wrote:
On Tue, Jun 24, 2014 at 06:57:44PM +0100, Olav Haugan wrote:
On 6/24/2014 2:18 AM, Will Deacon wrote:
On Sat, Jun 21, 2014 at 12:16:25AM +0100, Olav Haugan wrote:
We have multiple-master SMMUs and each master emits a variable number of
StreamIDs. However, we have to apply a mask (the ARM SMMU spec allows
for this) to the StreamIDs due to limited number of StreamID 2 Context
Bank entries in the SMMU. If my understanding is correct we would
represent this in the DT like this:
iommu {
#address-cells = 2;
#size-cells = 0;
};
master@a {
...
iommus = iommu StreamID0 MASK0,
iommu StreamID1 MASK1,
iommu StreamID2 MASK2;
};
Stupid question, but why not simply describe the masked IDs? What use does
the `raw' ID have to Linux?
We do describe the masked StreamID (SID) but we need to specify the mask
that the SMMU should apply to the incoming SIDs, right?
We have a bus master that emits 43 unique SIDs. However, we have only 40
SMMU_SMRn registers in the SMMU. So we need to mask out some of the
incoming SID bits so that the 43 SIDs can match one of 40 entries in the
SMR.
Hmm, so you're talking about stream matching, right? That doesn't belong in
the device-tree. I appreciate that the current driver does a terrible job at
allocating the SMRs (it's bloody difficult!), but we should try to improve
the dynamic behaviour instead of moving configuration of the SMMU out into
device-tree, where it's inflexible at best.
I am talking about SMMU_SMRn[MASK] register bits. This is not something
that can be dynamically detected at run-time. It is configuration at the
same level as the actual StreamIDs.
Thanks,
Olav Haugan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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/4] ARM: DTS: Add NTC thermistor nodes as child nodes to ADC
Naveen, On Tue, Jun 24, 2014 at 5:19 AM, Naveen Krishna Chatradhi ch.nav...@samsung.com wrote: Exynos5420 based Peach PIT and Exynos5800 based PI boards have 4 NTC thermistors to measure temperatures at various points on the board. IIO based ADC becomes the parent and NTC thermistors are the childs, via the HWMON interface. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Cc: Doug Anderson diand...@chromium.org --- This patch needs 1. MAX77802 PMIC device tree nodes (for ldo9) https://www.mail-archive.com/devicetree@vger.kernel.org/msg31430.html 2. Uses the DT documentation for NTC thermistors updated with vendor-prefix arch/arm/boot/dts/exynos5420-peach-pit.dts | 32 1 file changed, 32 insertions(+) * You forgot: status=okay for the ADC. One might question how this patch was tested. * Please also include this change for pi. * We just got through the painful process of sorting this .dts file. Please sort adc alphabetically. Kukjin: please confirm that you will keep an eye on patches and make sure that they are sorted OK. Other than those problems this seems to work fine to me. -Doug -- 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: mainline boot: 64 boots: 62 pass, 2 fail (v3.16-rc1-2-gebe0618)
On 6/24/2014 10:47 AM, Laura Abbott wrote: On 6/23/2014 11:32 AM, Kevin Hilman wrote: On Sun, Jun 22, 2014 at 8:56 PM, Tushar Behera trbli...@gmail.com wrote: Adding linux-samsung-soc and linux-arm-kernel ML for wider audience. On 06/19/2014 04:12 PM, Tushar Behera wrote: On 06/19/2014 03:02 PM, Tushar Behera wrote: On 06/18/2014 09:22 AM, Kevin Hilman wrote: On Tue, Jun 17, 2014 at 8:26 PM, Tushar Behera trbli...@gmail.com wrote: On 06/17/2014 10:23 PM, Kevin Hilman wrote: Sachin, On Mon, Jun 16, 2014 at 11:16 PM, Kevin's boot bot khil...@linaro.org wrote: Tree/Branch: mainline Git describe: v3.16-rc1-2-gebe0618 Failed boot tests (console logs at the end) === exynos5420-arndale-octa: FAIL:arm-exynos_defconfig ste-snowball: FAIL:arm-u8500_defconfig FYI... these failures are getting more consistent on my octa board, but still not failing every time. Kevin Hi Kevin, Same here. Observation: If you soft-reset the board (through the jumpers) after getting this problem, the problem keeps repeating. But if you hard-reset the board (by removing the power cord), the problem doesn't occur during next iteration. I don't ever use the soft-reset, I only toggle the wall power. I don't ever actually remove the power cord though, I'm using a USB-controlled relay to toggle the wall power. Kevin Laura, We are getting following kernel panic [1] (not always, but quite regularly) while booting Arndale-Octa (based on Samsung's Exynos5420) board with upstream kernel. I haven't observed this issue with other boards yet. This issue is observed when I am booting with uImage + dtb (within roughly ~10 iterations). Some more information: The boot logs are provided in pastebin, okay[2] and failed[3]. In case of boot failures, I am getting a higher value for vm_total_pages (684424 in [3]). In case of successful boot on my board, it is always 521232 [2] on my board. I can confirm that reverting the Get rid of meminfo patch gets the Octa board booting reliably again for me also. In case it helps, some boot logs for failures from the last copule linux-next build/boot cycles can be seen here: http://armcloud.us/kernel-ci/next/next-20140623/arm-exynos_defconfig/boot-exynos5420-arndale-octa.log http://armcloud.us/kernel-ci/next/next-20140620/arm-exynos_defconfig/boot-exynos5420-arndale-octa.log Sorry, I missed this yesterday. I'm going to take a look. Were all of http://pastebin.com/1iLaizuL http://pastebin.com/5tdDt4GL http://armcloud.us/kernel-ci/next/next-20140623/arm-exynos_defconfig/boot-exynos5420-arndale-octa.log http://armcloud.us/kernel-ci/next/next-20140620/arm-exynos_defconfig/boot-exynos5420-arndale-octa.log collected on the same type of board with the same amount of DRAM? I'm seeing a different amount of total pages across all those logs. All the logs have the same lowmem limit so it seems like the upper bound was being calculated incorrectly for passing to free_area_init_node. Nothing is immediately jumping out at me so can you boot up with a small debug patch? diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c index 659c75d..88eac1f 100644 --- a/arch/arm/mm/init.c +++ b/arch/arm/mm/init.c @@ -187,6 +187,8 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max_low, unsigned long zone_size[MAX_NR_ZONES], zhole_size[MAX_NR_ZONES]; struct memblock_region *reg; + pr_err(XXX min %lx max_low %lx max_high %lx\n, min, max_low, max_high); + __memblock_dump_all(); /* * initialise the zones. */ It would be helpful to do this across a few bootups to see if the values are actually consistent. I'll keep looking in the meantime. Thanks, Laura -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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/4] usb: host: xhci-plat: Add support to get PHYs
Hello.
On 06/10/2014 12:22 AM, Julius Werner wrote:
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 9ffecd5..453d89e 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1582,6 +1582,9 @@ struct xhci_hcd {
u32 port_status_u0;
/* Compliance Mode Timer Triggered every 2 seconds */
#define COMP_MODE_RCVRY_MSECS 2000
+ /* phys for the controller */
+ struct phy *phy2_gen;
+ struct phy *phy3_gen;
};
I don't think adding new variables here and restricting most of this
logic to xhci-plat.c (in the next patch) is the best way to do it.
Indeed.
There's no conceptual reason why other host controllers (e.g. xhci-pci
or even EHCI) could not have a similar need to tune their PHY after
reset. PHYs are universal to all host controllers.
There is already a 'phy' member in struct usb_hcd which I think is
mostly unused right now. I think it would be much less
confusing/redundant to reuse that member for this purpose (you could
still set it up from xhci_plat_probe(), and then call it from
hcd_bus_resume() or something like that).
That member has type 'struct usb_phy *' while here we have 'struct phy *'
-- feel the difference.
I have already tried adding 'struct phy *gen_phy' to 'struct usb_hcd',
however Greg wasn't eager to pick that up so far. Here's the last posting of
my patch:
http://marc.info/?l=linux-usbm=140145917506582
WBR, Sergei
--
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 0/3] MCPM: clarify boot CPU situation wrt CCI
Kevin, On Tue, Jun 24, 2014 at 8:35 AM, Kevin Hilman khil...@linaro.org wrote: - Leave mau_epll enabled http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/262259.html Can you drop your mau_epll one and instead pick just https://patchwork.kernel.org/patch/4333581/? I noticed that Tushar has only been pushing for that patch to be applied and I'm going to guess that the leave mau_epll enabled isn't needed. I just tested myself and confirmed that things are happy. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled
Tushar, On Thu, Jun 12, 2014 at 12:40 AM, Tushar Behera tusha...@samsung.com wrote: On Wed, Jun 11, 2014 at 10:20 PM, Kevin Hilman khil...@linaro.org wrote: Tushar Behera tusha...@samsung.com writes: When the output clock of AUDSS mux is disabled, we are getting kernel oops while doing a clk_get() on other clocks provided by AUDSS. Though user manual doesn't specify this dependency, we came across this issue while disabling the parent of AUDSS mux clocks. Keeping the parents of AUDSS mux always enabled fixes this issue. While this patch works (and fixes the boot problem for me), it seems like it's papering over the real problem. Thanks for testing. Seems like the right fix is actually modelling the clocks properly so that enabling a child clock ensures that the parent is also enabled. Patch 2/3 was to ensure we have proper clock tree defined for Exynos5420. While testing with audio disabled, that patch alone fixed the issue. But when audio was enabled (and hence I2S0 was trying to access the clocks), we got some kernel oops during late booting, hence I came up this solution. The solution might be a little half-baked because of the urgency to push the fix, but will try to dig more into the issue on Monday when I resume office. Which Monday were you referring to? ;) ...but in all seriousness do you have an official status update on this patch? It seems as if it's not needed and all you need is https://patchwork.kernel.org/patch/4333581/, but it would be nice to get an official confirmation. Thanks! -Doug -- 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/3] ARM: dts: Update the parent for Audss clocks in Exynos5420
Tushar, On Tue, Jun 10, 2014 at 10:32 PM, Tushar Behera tusha...@samsung.com wrote: Currently CLK_FOUT_EPLL was set as one of the parents of AUDSS mux. As per the user manual, it should be CLK_MAU_EPLL. The problem surfaced when the bootloader in Peach-pit board set the EPLL clock as the parent of AUDSS mux. While booting the kernel, we used to get a system hang during late boot if CLK_MAU_EPLL was disabled. Signed-off-by: Tushar Behera tusha...@samsung.com Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com Reported-by: Kevin Hilman khil...@linaro.org --- arch/arm/boot/dts/exynos5420.dtsi |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) I've tested this myself now as well. Tested-by: Doug Anderson diand...@chromium.org -- 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: [RFC 0/4] ARM: dts: exynos: Prepare Spring
Am 23.06.2014 03:21, schrieb Andreas Färber: The display goes dark unfortunately (drm bridge series not yet tested), but I am able to log in via ssh over USB ethernet adapter okay. Tracked this down to the dp-controller@145B node: The pinctrl seems irrelevant, only commenting out the whole node helps keep the display. That is, hdmi and fimd nodes don't interfere. Adding a pwm backlight node like on snow did not help. If it's supposed to work from GNOME's display brightness slider, it doesn't seem to work. The 3.8 tree had no backlight node at all. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- 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: [RFC 0/4] ARM: dts: exynos: Prepare Spring
Andreas, On Tue, Jun 24, 2014 at 4:18 PM, Andreas Färber afaer...@suse.de wrote: Am 23.06.2014 03:21, schrieb Andreas Färber: The display goes dark unfortunately (drm bridge series not yet tested), but I am able to log in via ssh over USB ethernet adapter okay. Tracked this down to the dp-controller@145B node: The pinctrl seems irrelevant, only commenting out the whole node helps keep the display. That is, hdmi and fimd nodes don't interfere. Adding Rahul from Samsung. I don't know that he's ever tested things on exynos5250-spring but he might be able to point you in the right direction. Adding a pwm backlight node like on snow did not help. If it's supposed to work from GNOME's display brightness slider, it doesn't seem to work. The 3.8 tree had no backlight node at all. I do know that we don't want the exynos pwm backlight for spring. On spring the backlight is controlled completely by the bridge chip which has a PWM on it. -Doug -- 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: [RFC 0/4] ARM: dts: exynos: Prepare Spring
On Tue, Jun 24, 2014 at 4:18 PM, Andreas Färber afaer...@suse.de wrote: Am 23.06.2014 03:21, schrieb Andreas Färber: The display goes dark unfortunately (drm bridge series not yet tested), but I am able to log in via ssh over USB ethernet adapter okay. Tracked this down to the dp-controller@145B node: The pinctrl seems irrelevant, only commenting out the whole node helps keep the display. That is, hdmi and fimd nodes don't interfere. Adding a pwm backlight node like on snow did not help. On this board, the backlight is driven by the Parade PS8622 DP-to-LVDS bridge (rather than a SoC PWM as on Snow). You need to ensure that the PS8622 GPIOs (Reset/Sleep) are correctly driven oh, it seems that the PS8622 DRM bridge driver is still in-flight : https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg32243.html If it's supposed to work from GNOME's display brightness slider, it doesn't seem to work. The 3.8 tree had no backlight node at all. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] i2c: exynos5: Properly use the noirq variants of suspend/resume
The original code for the exynos i2c controller registered for the
noirq variants. However during review feedback it was moved to
SIMPLE_DEV_PM_OPS without anyone noticing that it meant we were no
longer actually noirq (despite functions named
exynos5_i2c_suspend_noirq and exynos5_i2c_resume_noirq).
i2c controllers that might have wakeup sources on them seem to need to
resume at noirq time so that the individual drivers can actually read
the i2c bus to handle their wakeup.
NOTE: I took the original review feedback from Wolfram and added
poweroff, thaw, freeze, restore.
This patch has only been compile-tested since I don't have all the
patches needed to make my machine using this i2c driver actually
suspend/resume.
Signed-off-by: Doug Anderson diand...@chromium.org
---
Changes in v2:
- Added missing CONFIG_PM_SLEEP
drivers/i2c/busses/i2c-exynos5.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index 63d2292..348b1cd 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -789,8 +789,16 @@ static int exynos5_i2c_resume_noirq(struct device *dev)
}
#endif
-static SIMPLE_DEV_PM_OPS(exynos5_i2c_dev_pm_ops, exynos5_i2c_suspend_noirq,
-exynos5_i2c_resume_noirq);
+const struct dev_pm_ops exynos5_i2c_dev_pm_ops = {
+#ifdef CONFIG_PM_SLEEP
+ .suspend_noirq = exynos5_i2c_suspend_noirq,
+ .resume_noirq = exynos5_i2c_resume_noirq,
+ .freeze_noirq = exynos5_i2c_suspend_noirq,
+ .thaw_noirq = exynos5_i2c_resume_noirq,
+ .poweroff_noirq = exynos5_i2c_suspend_noirq,
+ .restore_noirq = exynos5_i2c_resume_noirq,
+#endif
+};
static struct platform_driver exynos5_i2c_driver = {
.probe = exynos5_i2c_probe,
--
2.0.0.526.g5318336
--
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: [RFC 0/4] ARM: dts: exynos: Prepare Spring
Vincent and Doug, Am 25.06.2014 01:44, schrieb Vincent Palatin: On Tue, Jun 24, 2014 at 4:18 PM, Andreas Färber afaer...@suse.de wrote: Am 23.06.2014 03:21, schrieb Andreas Färber: The display goes dark unfortunately (drm bridge series not yet tested), but I am able to log in via ssh over USB ethernet adapter okay. Tracked this down to the dp-controller@145B node: The pinctrl seems irrelevant, only commenting out the whole node helps keep the display. That is, hdmi and fimd nodes don't interfere. Adding a pwm backlight node like on snow did not help. On this board, the backlight is driven by the Parade PS8622 DP-to-LVDS bridge (rather than a SoC PWM as on Snow). You need to ensure that the PS8622 GPIOs (Reset/Sleep) are correctly driven oh, it seems that the PS8622 DRM bridge driver is still in-flight : https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg32243.html Yeah, that's the one I meant with drm bridge series above. :) Thanks for confirming. Cheers, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 10/11] ARM: EXYNOS: Add platform driver support for Exynos PMU.
On 24.06.2014 13:28, Pankaj Dubey wrote: On Tuesday, June 17 2014, Tomasz Figa wrote: On 10.05.2014 08:56, Pankaj Dubey wrote: [snip] + + ret = platform_driver_register(exynos_pmu_driver); + if (ret 0) + goto out; + + exynos_pmu_pdev = platform_device_register_simple(exynos-pmu, -1, + NULL, 0); Hmm, I don't see the point of making this a platform driver only to register respective platform device few lines below. If you take into account the patch for syscon I posted as a reply to patch 06/11, you will be able to make this a normal platform driver that binds to DT node directly and then register a syscon in probe function above. Well I updated PMU to be a syscon provider using your patch. It worked well. I have following two points to mention here: 1: For making PMU a normal platform driver, other than making PMU a syscon provider we need to change PMU's DT binding. Basically we need to remove syscon as second compatibility string. I hope this should not be an issue. I don't see the reason for this. Could you elaborate on this? I know that the way Linux currently handles multiple compatible strings is broken, but despite this, if you just make sure your platform driver registers before syscon platform driver, it should be fine. 2: I can see for your syscon patch Arnd has some comments, hopefully we can address his concern. Yes. I will get to it after sorting out few other things from my queue. Or you can do it if you want - the purpose of that RFC patch was just to show the idea I had in my mind. Best regards, Tomasz -- 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: mainline boot: 64 boots: 62 pass, 2 fail (v3.16-rc1-2-gebe0618)
Am 23.06.2014 20:32, schrieb Kevin Hilman: On Sun, Jun 22, 2014 at 8:56 PM, Tushar Behera trbli...@gmail.com wrote: Adding linux-samsung-soc and linux-arm-kernel ML for wider audience. On 06/19/2014 04:12 PM, Tushar Behera wrote: On 06/19/2014 03:02 PM, Tushar Behera wrote: On 06/18/2014 09:22 AM, Kevin Hilman wrote: On Tue, Jun 17, 2014 at 8:26 PM, Tushar Behera trbli...@gmail.com wrote: On 06/17/2014 10:23 PM, Kevin Hilman wrote: Sachin, On Mon, Jun 16, 2014 at 11:16 PM, Kevin's boot bot khil...@linaro.org wrote: Tree/Branch: mainline Git describe: v3.16-rc1-2-gebe0618 Failed boot tests (console logs at the end) === exynos5420-arndale-octa: FAIL:arm-exynos_defconfig ste-snowball: FAIL:arm-u8500_defconfig FYI... these failures are getting more consistent on my octa board, but still not failing every time. Kevin Hi Kevin, Same here. Observation: If you soft-reset the board (through the jumpers) after getting this problem, the problem keeps repeating. But if you hard-reset the board (by removing the power cord), the problem doesn't occur during next iteration. I don't ever use the soft-reset, I only toggle the wall power. I don't ever actually remove the power cord though, I'm using a USB-controlled relay to toggle the wall power. Kevin Laura, We are getting following kernel panic [1] (not always, but quite regularly) while booting Arndale-Octa (based on Samsung's Exynos5420) board with upstream kernel. I haven't observed this issue with other boards yet. This issue is observed when I am booting with uImage + dtb (within roughly ~10 iterations). Some more information: The boot logs are provided in pastebin, okay[2] and failed[3]. In case of boot failures, I am getting a higher value for vm_total_pages (684424 in [3]). In case of successful boot on my board, it is always 521232 [2] on my board. I can confirm that reverting the Get rid of meminfo patch gets the Octa board booting reliably again for me also. Confirming that the revert [1] fixes also the issue I was reporting for my Arndale Octa. I'm using zImage + dtb and had been resetting via J10. Regards, Andreas [1] https://github.com/afaerber/linux/commits/arndale-octa-next -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled
On 06/25/2014 04:29 AM, Doug Anderson wrote: Tushar, On Thu, Jun 12, 2014 at 12:40 AM, Tushar Behera tusha...@samsung.com wrote: On Wed, Jun 11, 2014 at 10:20 PM, Kevin Hilman khil...@linaro.org wrote: Tushar Behera tusha...@samsung.com writes: When the output clock of AUDSS mux is disabled, we are getting kernel oops while doing a clk_get() on other clocks provided by AUDSS. Though user manual doesn't specify this dependency, we came across this issue while disabling the parent of AUDSS mux clocks. Keeping the parents of AUDSS mux always enabled fixes this issue. While this patch works (and fixes the boot problem for me), it seems like it's papering over the real problem. Thanks for testing. Seems like the right fix is actually modelling the clocks properly so that enabling a child clock ensures that the parent is also enabled. Patch 2/3 was to ensure we have proper clock tree defined for Exynos5420. While testing with audio disabled, that patch alone fixed the issue. But when audio was enabled (and hence I2S0 was trying to access the clocks), we got some kernel oops during late booting, hence I came up this solution. The solution might be a little half-baked because of the urgency to push the fix, but will try to dig more into the issue on Monday when I resume office. Which Monday were you referring to? ;) Sorry that I couldn't get deeper into this issue. Thanks for reminding though. ...but in all seriousness do you have an official status update on this patch? It seems as if it's not needed and all you need is https://patchwork.kernel.org/patch/4333581/, but it would be nice to get an official confirmation. I have tested various scenarios with only patch 2/3, which seems to be sufficient for the time being. I have not encountered the older issue till now. I was thinking of testing a bit further, but given that you have already asked for, we can go ahead with only patch 2/3 right now. In case any further issue comes up, I will post patch 1/3 as per the review comments that I have got. Thanks! -Doug -- 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 -- Tushar Behera -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators
On 06/25/2014 03:00 AM, Doug Anderson wrote:
Yuvaraj,
On Mon, Jun 23, 2014 at 3:45 AM, Yuvaraj Kumar C D yuvaraj...@gmail.com
wrote:
This patch makes use of mmc_regulator_get_supply() to handle
the vmmc and vqmmc regulators.Also it moves the code handling
the these regulators to dw_mci_set_ios().It turned on the vmmc
and vqmmc during MMC_POWER_UP and MMC_POWER_ON,and turned off
during MMC_POWER_OFF.
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
---
drivers/mmc/host/dw_mmc.c | 71
++---
drivers/mmc/host/dw_mmc.h |2 ++
2 files changed, 36 insertions(+), 37 deletions(-)
Perhaps you could CC me on the whole series for the next version since
I was involved in privately reviewing previous versions?
Overall caveat for my review is that I'm nowhere near an SD/MMC expert.
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 1ac227c..f5cabce 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -937,6 +937,7 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
struct dw_mci_slot *slot = mmc_priv(mmc);
const struct dw_mci_drv_data *drv_data = slot-host-drv_data;
u32 regs;
+ int ret;
switch (ios-bus_width) {
case MMC_BUS_WIDTH_4:
@@ -975,16 +976,41 @@ static void dw_mci_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
switch (ios-power_mode) {
case MMC_POWER_UP:
+ if ((!IS_ERR(mmc-supply.vmmc))
+ !test_bit(DW_MMC_CARD_POWERED,
slot-flags)) {
+ ret = regulator_enable(mmc-supply.vmmc);
+ if (!ret)
+ set_bit(DW_MMC_CARD_POWERED, slot-flags);
MMC_CARD_POWERED? I didn't know why it needs.
+ }
As per below, I'm not sure why you'd want to turn on vqmmc and vmmc at
different times.
In my case, in order to prevent the H/W mis-operation, it turns on vqmmc and
vmmc at different times.
Also: if you fail to turn on either of the regulators it feels like
you should print a pretty nasty error message since your device will
almost certainly not work.
set_bit(DW_MMC_CARD_NEED_INIT, slot-flags);
regs = mci_readl(slot-host, PWREN);
regs |= (1 slot-id);
mci_writel(slot-host, PWREN, regs);
break;
case MMC_POWER_OFF:
+ if (!IS_ERR(mmc-supply.vqmmc)
+ test_bit(DW_MMC_IO_POWERED, slot-flags)) {
+ ret = regulator_disable(mmc-supply.vqmmc);
+ if (!ret)
+ clear_bit(DW_MMC_IO_POWERED, slot-flags);
+ }
+ if (!IS_ERR(mmc-supply.vmmc)
+ test_bit(DW_MMC_CARD_POWERED, slot-flags))
{
+ ret = regulator_disable(mmc-supply.vmmc);
+ if (!ret)
+ clear_bit(DW_MMC_CARD_POWERED, slot-flags);
+ }
regs = mci_readl(slot-host, PWREN);
regs = ~(1 slot-id);
mci_writel(slot-host, PWREN, regs);
break;
+ case MMC_POWER_ON:
+ if (!IS_ERR(mmc-supply.vqmmc)
+ !test_bit(DW_MMC_IO_POWERED, slot-flags)) {
+ ret = regulator_enable(mmc-supply.vqmmc);
+ if (!ret)
+ set_bit(DW_MMC_IO_POWERED, slot-flags);
+ }
default:
break;
}
@@ -2067,7 +2093,13 @@ static int dw_mci_init_slot(struct dw_mci *host,
unsigned int id)
mmc-f_max = freq[1];
}
- mmc-ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
+ /*if there are external regulators, get them*/
+ ret = mmc_regulator_get_supply(mmc);
+ if (ret == -EPROBE_DEFER)
+ goto err_setup_bus;
+
+ if (!mmc-ocr_avail)
+ mmc-ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
if (host-pdata-caps)
mmc-caps = host-pdata-caps;
@@ -2133,7 +2165,7 @@ static int dw_mci_init_slot(struct dw_mci *host,
unsigned int id)
err_setup_bus:
mmc_free_host(mmc);
- return -EINVAL;
+ return ret;
}
static void dw_mci_cleanup_slot(struct dw_mci_slot *slot, unsigned int id)
@@ -2375,24 +2407,6 @@ int dw_mci_probe(struct dw_mci *host)
}
}
- host-vmmc = devm_regulator_get_optional(host-dev, vmmc);
- if (IS_ERR(host-vmmc)) {
- ret = PTR_ERR(host-vmmc);
- if (ret == -EPROBE_DEFER)
- goto err_clk_ciu;
-
- dev_info(host-dev, no vmmc regulator found: %d\n, ret);
- host-vmmc = NULL;
- } else {
-
Re: [alsa-devel] [PATCH V2 1/2] ASoC: samsung: Add machine driver for Odroid X2/U3
On 06/18/2014 09:52 PM, Sylwester Nawrocki wrote:
This patch adds the sound subsystem driver for Odroid-X2 and
Odroid-U3 boards. The codec works in I2S master mode; there are
2 separate audio routing paths defined as there are differences
in the signal routing between the X2 and U3 boards, i.e. U3 uses
single jack for headphones and microphone.
Signed-off-by: Chen Zhen zhen1.c...@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
---
sound/soc/samsung/Kconfig |8 ++
sound/soc/samsung/Makefile|2 +
sound/soc/samsung/odroidx2_max98090.c | 191
+
3 files changed, 201 insertions(+)
create mode 100644 sound/soc/samsung/odroidx2_max98090.c
[ ... ]
+static int odroidx2_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params)
+{
+ struct snd_soc_pcm_runtime *rtd = substream-private_data;
+ struct snd_soc_dai *cpu_dai = rtd-cpu_dai;
+ struct snd_soc_dai *codec_dai = rtd-codec_dai;
+ int ret;
+
+ ret = snd_soc_dai_set_sysclk(codec_dai, 0, MAX98090_MCLK,
+ SND_SOC_CLOCK_IN);
+ if (ret 0) {
+ dev_err(codec_dai-dev,
+ Unable to switch to FLL1: %d\n, ret);
+ return ret;
+ }
+
+ /* Set the cpu DAI configuration in order to use CDCLK */
+ ret = snd_soc_dai_set_sysclk(cpu_dai, SAMSUNG_I2S_CDCLK,
+ 0, SND_SOC_CLOCK_OUT);
+ if (ret 0)
+ return ret;
+
While upstreaming sound-card driver for Snow board, I had a comment from
Mark to move this to probe, if possible. That way, the clock operations
would be done only once and this function and odroidx2_ops can be
removed altogether.
+ dev_dbg(codec_dai-dev, HiFi DAI %s params: channels: %d, rate: %d\n,
+ snd_pcm_stream_str(substream), params_channels(params),
+ params_rate(params));
+
+ return 0;
+}
+
+static struct snd_soc_ops odroidx2_ops = {
+ .hw_params = odroidx2_hw_params,
+};
+
[ ... ]
+
+ ret = snd_soc_register_card(card);
devm_snd_soc_register_card ?
+ if (ret) {
+ dev_err(pdev-dev, snd_soc_register_card failed: %d\n, ret);
+ goto err_put_cpu_n;
+ }
+
+ return 0;
+
+err_put_cpu_n:
+ of_node_put(odroidx2_dai[0].cpu_of_node);
+err_put_cod_n:
+ of_node_put(odroidx2_dai[0].codec_of_node);
+ return ret;
+}
+
+static int odroidx2_audio_remove(struct platform_device *pdev)
+{
+ struct snd_soc_card *card = platform_get_drvdata(pdev);
+
+ snd_soc_unregister_card(card);
This can be removed when devm_snd_soc_register_card is used.
--
Tushar Behera
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mmc: dw_mmc: use mmc_regulator_get_supply to handle regulators
Jaehoon,
On Tue, Jun 24, 2014 at 8:18 PM, Jaehoon Chung jh80.ch...@samsung.com wrote:
On 06/25/2014 03:00 AM, Doug Anderson wrote:
Yuvaraj,
On Mon, Jun 23, 2014 at 3:45 AM, Yuvaraj Kumar C D yuvaraj...@gmail.com
wrote:
This patch makes use of mmc_regulator_get_supply() to handle
the vmmc and vqmmc regulators.Also it moves the code handling
the these regulators to dw_mci_set_ios().It turned on the vmmc
and vqmmc during MMC_POWER_UP and MMC_POWER_ON,and turned off
during MMC_POWER_OFF.
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
---
drivers/mmc/host/dw_mmc.c | 71
++---
drivers/mmc/host/dw_mmc.h |2 ++
2 files changed, 36 insertions(+), 37 deletions(-)
Perhaps you could CC me on the whole series for the next version since
I was involved in privately reviewing previous versions?
Overall caveat for my review is that I'm nowhere near an SD/MMC expert.
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 1ac227c..f5cabce 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -937,6 +937,7 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
struct dw_mci_slot *slot = mmc_priv(mmc);
const struct dw_mci_drv_data *drv_data = slot-host-drv_data;
u32 regs;
+ int ret;
switch (ios-bus_width) {
case MMC_BUS_WIDTH_4:
@@ -975,16 +976,41 @@ static void dw_mci_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
switch (ios-power_mode) {
case MMC_POWER_UP:
+ if ((!IS_ERR(mmc-supply.vmmc))
+ !test_bit(DW_MMC_CARD_POWERED,
slot-flags)) {
+ ret = regulator_enable(mmc-supply.vmmc);
+ if (!ret)
+ set_bit(DW_MMC_CARD_POWERED, slot-flags);
MMC_CARD_POWERED? I didn't know why it needs.
I think the idea was to make sure that regulator enables/disables were
balanced. ...but if the mmc core does this for us then we probably
don't need to worry.
+ }
As per below, I'm not sure why you'd want to turn on vqmmc and vmmc at
different times.
In my case, in order to prevent the H/W mis-operation, it turns on vqmmc and
vmmc at different times.
OK! Can you explain more? What instance is one powered but not the other?
I know that we talked to an SD Card manufacturer who told us that
powering their IO lines without their main power rail was a bad thing
(and we in fact saw this causing problems on SD cards). I would guess
that means that you're either powering vmmc before vqmmc or that vqmmc
somehow doesn't directly enable pullups for IO lines.
If you need vmmc before vqmmc then I'm curious about why...
-Doug
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] clk: exynos-audss: Keep the parent of mout_audss always enabled
Tushar, On Tue, Jun 24, 2014 at 8:09 PM, Tushar Behera trbli...@gmail.com wrote: On 06/25/2014 04:29 AM, Doug Anderson wrote: Tushar, On Thu, Jun 12, 2014 at 12:40 AM, Tushar Behera tusha...@samsung.com wrote: On Wed, Jun 11, 2014 at 10:20 PM, Kevin Hilman khil...@linaro.org wrote: Tushar Behera tusha...@samsung.com writes: When the output clock of AUDSS mux is disabled, we are getting kernel oops while doing a clk_get() on other clocks provided by AUDSS. Though user manual doesn't specify this dependency, we came across this issue while disabling the parent of AUDSS mux clocks. Keeping the parents of AUDSS mux always enabled fixes this issue. While this patch works (and fixes the boot problem for me), it seems like it's papering over the real problem. Thanks for testing. Seems like the right fix is actually modelling the clocks properly so that enabling a child clock ensures that the parent is also enabled. Patch 2/3 was to ensure we have proper clock tree defined for Exynos5420. While testing with audio disabled, that patch alone fixed the issue. But when audio was enabled (and hence I2S0 was trying to access the clocks), we got some kernel oops during late booting, hence I came up this solution. The solution might be a little half-baked because of the urgency to push the fix, but will try to dig more into the issue on Monday when I resume office. Which Monday were you referring to? ;) Sorry that I couldn't get deeper into this issue. Thanks for reminding though. No problem. I know how it is. I was trying to be funny though sometimes that doesn't come through very well over email. ...but in all seriousness do you have an official status update on this patch? It seems as if it's not needed and all you need is https://patchwork.kernel.org/patch/4333581/, but it would be nice to get an official confirmation. I have tested various scenarios with only patch 2/3, which seems to be sufficient for the time being. I have not encountered the older issue till now. I was thinking of testing a bit further, but given that you have already asked for, we can go ahead with only patch 2/3 right now. In case any further issue comes up, I will post patch 1/3 as per the review comments that I have got. Sounds like a plan. Thanks for getting the original patch sent out so quickly after I reported it. Hopefully Kukjin will apply pack 2/3 soon (today?) -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4 10/11] ARM: EXYNOS: Add platform driver support for Exynos PMU.
Hi, On Wednesday, June 25 2014 Tomasz Figa write: On 24.06.2014 13:28, Pankaj Dubey wrote: On Tuesday, June 17 2014, Tomasz Figa wrote: On 10.05.2014 08:56, Pankaj Dubey wrote: [snip] + + ret = platform_driver_register(exynos_pmu_driver); + if (ret 0) + goto out; + + exynos_pmu_pdev = platform_device_register_simple(exynos-pmu, -1, + NULL, 0); Hmm, I don't see the point of making this a platform driver only to register respective platform device few lines below. If you take into account the patch for syscon I posted as a reply to patch 06/11, you will be able to make this a normal platform driver that binds to DT node directly and then register a syscon in probe function above. Well I updated PMU to be a syscon provider using your patch. It worked well. I have following two points to mention here: 1: For making PMU a normal platform driver, other than making PMU a syscon provider we need to change PMU's DT binding. Basically we need to remove syscon as second compatibility string. I hope this should not be an issue. I don't see the reason for this. Could you elaborate on this? Currently syscon driver is registered via postcore_initcall whereas exynos pmu has arch_initcall. So if we keep syscon as second compatibility in exynos pmu node, syscon will be registered first and hence only syscon will be probed. I know that the way Linux currently handles multiple compatible strings is broken, but despite this, if you just make sure your platform driver registers before syscon platform driver, it should be fine. Yes, this could be possible if I convert arch_initcall of exynos pmu to postcore_initcall. As after converting arch_initcall to postcore_initcall, syscon driver will not be probed for exynos pmu node. Also as exynos pmu driver will now register itself as syscon provider, I could not see any use of keeping second compatibility as syscon in exynos pmu node. Do you think it is still required? After removing syscon compatibility string from exynos pmu node, I have tested S2R as well as watchdog driver functionality, which is user of regmap handle of exynos pmu and both are working fine on exynos5250. 2: I can see for your syscon patch Arnd has some comments, hopefully we can address his concern. Yes. I will get to it after sorting out few other things from my queue. Or you can do it if you want - the purpose of that RFC patch was just to show the idea I had in my mind. OK, let me post exynos pmu v5, based on your patch, and then if time permits I will have a look in it. Best regards, Tomasz Thanks, Pankaj Dubey -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: exynos: Modify pm code to check for cortex A9 rather than the SoC
Hi Russell and Tomasz,
+Arnd
On Tue, Jun 24, 2014 at 9:41 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Jun 16, 2014 at 09:37:14AM +0530, Abhilash Kesavan wrote:
Hi Kukjin,
On Fri, May 23, 2014 at 8:31 AM, Abhilash Kesavan a.kesa...@samsung.com
wrote:
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Do you have any comments on this patch ?
I do.
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index d10c351..6dd4a11 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -300,7 +300,7 @@ static int exynos_pm_suspend(void)
tmp = (S5P_USE_STANDBY_WFI0 | S5P_USE_STANDBY_WFE0);
__raw_writel(tmp, S5P_CENTRAL_SEQ_OPTION);
- if (!soc_is_exynos5250())
+ if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
exynos_cpu_save_register();
...
@@ -334,7 +334,7 @@ static void exynos_pm_resume(void)
if (exynos_pm_central_resume())
goto early_wakeup;
- if (!soc_is_exynos5250())
+ if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
exynos_cpu_restore_register();
It is invalid to check just the part number. The part number on its
own is meaningless without taking account of the implementor. Both
the implementor and the part number should be checked at each of these
sites.
Thanks for pointing this out. I was not aware of the implementor id
check requirement.
Another point: exynos have taken it upon themselves to add code which
saves various ARM core registers. This is a bad idea, it brings us
back to the days where every platform did their own suspend implementations.
CPU level registers should be handled by CPU level code, not by platform
code. Is there a reason why this can't be added to the Cortex-A9
support code in proc-v7.S ?
@@ -353,7 +353,7 @@ static void exynos_pm_resume(void)
s3c_pm_do_restore_core(exynos_core_save,
ARRAY_SIZE(exynos_core_save));
- if (!soc_is_exynos5250())
+ if (read_cpuid_part_number() == ARM_CPU_PART_CORTEX_A9)
scu_enable(S5P_VA_SCU);
early_wakeup:
@@ -440,15 +440,18 @@ static int exynos_cpu_pm_notifier(struct
notifier_block *self,
case CPU_PM_ENTER:
if (cpu == 0) {
exynos_pm_central_suspend();
- exynos_cpu_save_register();
+ if (read_cpuid_part_number() ==
ARM_CPU_PART_CORTEX_A9)
+ exynos_cpu_save_register();
}
break;
case CPU_PM_EXIT:
if (cpu == 0) {
- if (!soc_is_exynos5250())
+ if (read_cpuid_part_number() ==
+ ARM_CPU_PART_CORTEX_A9) {
scu_enable(S5P_VA_SCU);
- exynos_cpu_restore_register();
+ exynos_cpu_restore_register();
+ }
exynos_pm_central_resume();
}
break;
And presumably with the CPU level code dealing with those registers,
you don't need the calls to save and restore these registers in this
notifier.
Regarding save/restore of these registers, I could send out a patch
cleaning these out once Shawn's patch gets merged. I'd need some help
testing it out on Exynos4 boards though. For now, is it OK if I just
update to the new function ?
Which, by the way, is probably illegal to run as it runs in a read-
lock code path and with the SCU disabled. As you're calling
scu_enable() that means you're non-coherent with the other CPUs,
and therefore locks don't work.
I think this code is very broken and wrongly architected, and shows
that we're continuing to make the same mistakes that we made all
through the 2000s with platforms doing their own crap rather than
properly thinking about this stuff.
I see that you have sent a patch out that ensures both part and
implementor number are checked. Currently, my patch has been applied
to the fixes branch of the arm-soc tree and I wanted to know how to
proceed (without it there is a crash on the 5420):
Should I request Arnd to drop it (if possible) and send out a new
patch using your updated function ?
Regards,
Abhilash
--
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/4] ARM: DTS: Add NTC thermistor nodes as child nodes to ADC
Doug, On 25 June 2014 03:24, Doug Anderson diand...@chromium.org wrote: Naveen, On Tue, Jun 24, 2014 at 5:19 AM, Naveen Krishna Chatradhi ch.nav...@samsung.com wrote: Exynos5420 based Peach PIT and Exynos5800 based PI boards have 4 NTC thermistors to measure temperatures at various points on the board. IIO based ADC becomes the parent and NTC thermistors are the childs, via the HWMON interface. Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com Cc: Doug Anderson diand...@chromium.org --- This patch needs 1. MAX77802 PMIC device tree nodes (for ldo9) https://www.mail-archive.com/devicetree@vger.kernel.org/msg31430.html 2. Uses the DT documentation for NTC thermistors updated with vendor-prefix arch/arm/boot/dts/exynos5420-peach-pit.dts | 32 1 file changed, 32 insertions(+) * You forgot: status=okay for the ADC. One might question how this patch was tested. Will correct it. * Please also include this change for pi. MAX77802 device node was not added for Peach_PI (exynos5800-peach-pi.dts). I guess, Javier have a plan to send. I will edit the commit message to remove Peach_PI for now. Also, we have few similar nodes on Peach PI and Peach PIT. Any plans or discussion on merging the common nodes ? * We just got through the painful process of sorting this .dts file. Please sort adc alphabetically. Kukjin: please confirm that you will keep an eye on patches and make sure that they are sorted OK. Other than those problems this seems to work fine to me. -Doug Thanks for the Review. -- Shine bright, (: Nav :) -- 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/4] usb: host: xhci-plat: Add support to get PHYs
HI Sergei,
On Wed, Jun 25, 2014 at 4:04 AM, Sergei Shtylyov
sergei.shtyl...@cogentembedded.com wrote:
Hello.
On 06/10/2014 12:22 AM, Julius Werner wrote:
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 9ffecd5..453d89e 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1582,6 +1582,9 @@ struct xhci_hcd {
u32 port_status_u0;
/* Compliance Mode Timer Triggered every 2 seconds */
#define COMP_MODE_RCVRY_MSECS 2000
+ /* phys for the controller */
+ struct phy *phy2_gen;
+ struct phy *phy3_gen;
};
I don't think adding new variables here and restricting most of this
logic to xhci-plat.c (in the next patch) is the best way to do it.
Indeed.
There's no conceptual reason why other host controllers (e.g. xhci-pci
or even EHCI) could not have a similar need to tune their PHY after
reset. PHYs are universal to all host controllers.
There is already a 'phy' member in struct usb_hcd which I think is
mostly unused right now. I think it would be much less
confusing/redundant to reuse that member for this purpose (you could
still set it up from xhci_plat_probe(), and then call it from
hcd_bus_resume() or something like that).
That member has type 'struct usb_phy *' while here we have 'struct phy *'
-- feel the difference.
I have already tried adding 'struct phy *gen_phy' to 'struct usb_hcd',
however Greg wasn't eager to pick that up so far. Here's the last posting of
my patch:
http://marc.info/?l=linux-usbm=140145917506582
Thanks for pointing to the patch, i have also been tracking this patch.
I will try to rework using this patch and post the relevant patches.
--
Best Regards
Vivek Gautam
Samsung RD Institute, Bangalore
India
--
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
